On Sat, Nov 2, 2013 at 7:43 PM, Olaf Kolkman <olaf@xxxxxxxxxxxx> 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