Oh, and, of course, if we use my suggestion below, this document will have to "update" 6410 as well as 2026. Barry On Sat, Nov 2, 2013 at 6:18 PM, Barry Leiba <barryleiba@xxxxxxxxxxxx> wrote: >> On the Sec 3.2 point, I think Olaf is getting somewhere in his reply: make >> this the definitive source, which should eliminate the issue of duplication >> and also merge in the 6410 stuff. I'll work up text on the plane (en route >> to EWR now. > > OK, so... > > Here's what I suggest, which has us explicitly replacing all of the > definitions of Proposed Standard and Internet Standard from both 2026 > and 6410. This leaves us with the new document being the definitive > place, and there's no duplication. > > Abstract > > OLD > RFC 2026 describes the review performed by the IESG on IETF Proposed > Standard RFCs and characterizes the maturity level of those > documents. This document updates RFC 2026 by providing a current and > more accurate characterization of Proposed Standards. > NEW > RFC 2026 describes the review performed by the IESG on IETF Standards > Track RFCs and characterizes the maturity level of those documents. > RFC 6410 updates those characterizations. This document updates RFCs > 2026 and 6410 by providing a current and more accurate characterization > of Proposed Standard, and merging the changes made to Internet Standard > by RFC 6410. > END > > 1. Introduction > > OLD > This document only updates the characterization of Proposed Standards > from RFC2026 Section 4.1.1 and does not speak to or alter the > procedures for the maintenance of Standards Track documents from RFC > 2026 and RFC 6410 [RFC6410]. For complete understanding of the > requirements for standardization those documents should be read in > conjunction with this document. > NEW > This document only updates the characterization of Proposed Standards > from RFC2026 Section 4.1.1 and merges the changes made to RFC 2026 > Section 4.1.3 by RFC 6410. While this document now provides a complete > current characterization of the Standards Track maturity levels, for a > complete understanding of the requirements for standardization it is > necessary to read RFCs 2026 and 6410 in conjunction with this document. > END > > 3. Characterization of Specifications > > OLD > The text in the following section replaces RFC 2026 Section 4.1.1. > Section 3.2 is a verbatim copy of the characterization of Internet > Standards from RFC 2026 Section 4.1.3 and is provided for convenient > reference. > NEW > Internet specifications go through stages of development, testing, > and acceptance. Within the Internet Standards Process, there are > two stages, formally labeled "maturity levels" in the "Standards > Track". These maturity levels are "Proposed Standard" and > "Internet Standard". > > This section describes the maturity levels and the expected > characteristics of specifications at each level. It replaces > Section 4.1 of RFC 2026, and its subsections, and Sections 2, > 2.1, and 2.2 of RFC 6410. > > A specification may be, and indeed, is likely to be, revised as it > advances from Proposed Standard to Internet Standard. When a revised > specification is proposed for advancement to Internet Standard, the > IESG shall determine the scope and significance of the changes to the > specification, and, if necessary and appropriate, modify the > recommended action. Minor revisions and the removal of unused > features are expected, but a significant revision may require that > the specification accumulate more experience at Proposed Standard > before progressing. > END > > OLD > 3.2. Characteristics of Internet Standards > > 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. > NEW > 3.2. Characterization of IETF Internet Standard Specifications > > 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. > > The IESG, in an IETF-wide Last Call of at least four weeks, confirms > that a document advances from Proposed Standard to Internet Standard. > The request for reclassification is sent to the IESG along with an > explanation of how the criteria have been met. The criteria are: > > (1) There are at least two independent interoperating implementations > with widespread deployment and successful operational experience. > > (2) There are no errata against the specification that would cause a > new implementation to fail to interoperate with deployed ones. > > (3) There are no unused features in the specification that greatly > increase implementation complexity. > > (4) If the technology required to implement the specification > requires patented or otherwise controlled technology, then the > set of implementations must demonstrate at least two independent, > separate and successful uses of the licensing process. > > After review and consideration of significant errata, the IESG will > perform an IETF-wide Last Call of at least four weeks on the > requested reclassification. If there is consensus for > reclassification, the RFC will be reclassified without publication of > a new RFC. > > In a timely fashion after the expiration of the Last Call period, the > IESG shall make its final determination and notify the IETF of its > decision via electronic mail to the IETF Announce mailing list. See > Section 6.1.2 of RFC 2026. > > A specification that reaches the status of Standard is assigned a > number in the STD series while retaining its RFC number. > END > > -- > Barry