On Sat, Nov 2, 2013 at 7:43 PM, Olaf Kolkman <olaf(_at_)nlnetlabs(_dot_)nl>
wrote:
I observe this is mixing characterization with process. I have been very
careful to only touch the characterization in this document.
When I wrote the text in the draft I started from 6410 which says:
The characterization of an Internet Standard remains as described in
RFC 2026 [1], which says:
An Internet Standard is characterized by a high degree of
technical maturity and by a generally held belief that the
specified protocol or service provides significant benefit to the
Internet community.
That is the second sentence in the first paragraph from section 4.1.3 that
talks about Internet Standards. The first sentence is an introduction
sentence. Below is the full section from 2026 for reference:
4.1.3 Internet Standard
A specification for which significant implementation and successful
operational experience has been obtained may be elevated to the
Internet Standard level. An Internet Standard (which may simply be
referred to as a Standard) is characterized by a high degree of
technical maturity and by a generally held belief that the specified
protocol or service provides significant benefit to the Internet
community.
A specification that reaches the status of Standard is assigned a
number in the STD series while retaining its RFC number.
When I constructed the text in the draft I figured that the second paragraph
was more of a process detail that could be left out. While that first
sentence seems to be relevant for providing the context.
So really the question is whether the characterization is really out of sync
with 2026/6410?
Personally I feel your suggestions are rescoping the drafts purpose.
OK, well...
Dave's point was that it's a bad idea to duplicate the text, and I
agree with that.
6410 changed 2026 Section 4.1.3 and nullified Section 4.1.2. It made
no change to 4.1.1, and it said so (without duplicating text from it).
This document is changing Section 4.1.1.
This now means that in order to make sense of the Standards Track
maturity levels, which had previously been documented in RFC 2026
Section 4.1 and its subsections, one must now do this:
- Read 2026 and see that it's been updated.
- Replace Section 4.1.1 from this document.
- Get Section 4.1.3 by reading 6401 and 2026, and merging them.
If we want to leave it that way, we can... but if we do that, I agree
with Dave that we should NOT duplicate some of the text from 2026
Section 4.1.3, leaving out the changes that 6401 made.
Alternatively, my formulation (which isn't considering
characterization and process... it's consolidating the updates to a
particular section of 2026) means that one can do this:
- Read 2026 and see that it's been updated.
- Replace Sections 4.1.1 and 4.1.3 from this document.
That seems simpler.
I'm happy either way, though:
1. Using a change such as I've suggested.
2. Noting that this document does not change 2026 Section 4.1.3,
*without* copying text from it (much as 6410 does for Section 4.1.1).
Barry