Re: Review of: Characterization of Proposed Standards

[Brian E Carpenter <[e-mail]>]

> A specification that reaches the status of Standard is assigned a
> number in the STD series while retaining its RFC number.

Unfortunately this is the entrance to a very enticing rat hole,
and a couple of small subsidiary rat holes as well.

First a small one: we should document the fact that an STD
is often a document set rather than a single RFC. Therefore,
a newly promoted Standard *either* gets a new STD number *or*
is associated with an existing STD number.

Second, the bigger one: a very confused situation is created
if part of a multi-RFC STD set is updated and thereby reverts
to Proposed Standard status. The only rational solution to
that is for the Proposed Standard document also to be associated
with the STD number. In practice, users don't care: they need to
know all the updates to a Standard, even if some of them are
only Proposed Standard.

Third, it needs to be specified that when multiple documents
form part of the same STD set, that is a decision made by the IETF,
not the RFC Editor.

(Barry - this is the downside of doing more than tinkering
with RFC 2026; you tend to drag in all its defects. In fact
a solution for this was spelled out in some detail in 2008
but didn't fly at that time:
http://tools.ietf.org/html/draft-carpenter-rfc2026-changes-02#section-3.2 )


Regards
   Brian

On 03/11/2013 11:18, Barry Leiba 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
>