Re: Review of: Characterization of Proposed Standards

[Barry Leiba <[e-mail]>]

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 <[e-mail]> 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