Re: Review of: Characterization of Proposed Standards

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 




Barry,



[skipping to the core of the suggested changes]

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

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.

—Olaf



Attachment: signature.asc
Description: Message signed with OpenPGP using GPGMail


[Index of Archives]     [IETF Annoucements]     [IETF]     [IP Storage]     [Yosemite News]     [Linux SCTP]     [Linux Newbies]     [Fedora Users]