Characterization of Proposed Standards

Internet Engineering Task Force (IETF)                        O. Kolkman
Request for Comments: 7127                                    NLnet Labs
BCP: 9                                                        S. Bradner
Updates: <a href="./rfc2026">2026</a>                                         Harvard University
Category: Best Current Practice                                S. Turner
ISSN: 2070-1721                                               IECA, Inc.
                                                            January 2014


                 <span class="h1">Characterization of Proposed Standards</span>

Abstract

   <a href="./rfc2026">RFC 2026</a> describes the review performed by the Internet Engineering
   Steering Group (IESG) on IETF Proposed Standard RFCs and
   characterizes the maturity level of those documents.  This document
   updates <a href="./rfc2026">RFC 2026</a> by providing a current and more accurate
   characterization of Proposed Standards.

Status of This Memo

   This memo documents an Internet Best Current Practice.

   This document is a product of the Internet Engineering Task Force
   (IETF).  It has been approved for publication by the Internet
   Engineering Steering Group (IESG).  Further information on BCPs is
   available in <a href="./rfc5741#section-2">Section 2 of RFC 5741</a>.

   Information about the current status of this document, any errata,
   and how to provide feedback on it may be obtained at
   <a href="https://www.rfc-editor.org/info/rfc7127">http://www.rfc-editor.org/info/rfc7127</a>.

Copyright Notice

   Copyright (c) 2014 IETF Trust and the persons identified as the
   document authors.  All rights reserved.

   This document is subject to <a href="https://www.rfc-editor.org/bcp/bcp78">BCP 78</a> and the IETF Trust's Legal
   Provisions Relating to IETF Documents
   (<a href="http://trustee.ietf.org/license-info">http://trustee.ietf.org/license-info</a>) in effect on the date of
   publication of this document.  Please review these documents
   carefully, as they describe your rights and restrictions with respect
   to this document.  Code Components extracted from this document must
   include Simplified BSD License text as described in Section 4.e of
   the Trust Legal Provisions and are provided without warranty as
   described in the Simplified BSD License.





<span class="grey">Kolkman, et al.           Best Current Practice                 [Page 1]</span>

<span id="page-2" ></span>
<span class="grey"><a href="./rfc7127">RFC 7127</a>         Characterization of Proposed Standards     January 2014</span>


Table of Contents

   <a href="#section-1">1</a>.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . .   <a href="#page-2">2</a>
   <a href="#section-2">2</a>.  IETF Review of Proposed Standards . . . . . . . . . . . . . .   <a href="#page-2">2</a>
   <a href="#section-3">3</a>.  Characterization of Specifications  . . . . . . . . . . . . .   <a href="#page-3">3</a>
     3.1.  Characterization of IETF Proposed Standard Specifications   3
     <a href="#section-3.2">3.2</a>.  Characteristics of Internet Standards . . . . . . . . . .   <a href="#page-4">4</a>
   <a href="#section-4">4</a>.  Further Considerations  . . . . . . . . . . . . . . . . . . .   <a href="#page-4">4</a>
   <a href="#section-5">5</a>.  Security Considerations . . . . . . . . . . . . . . . . . . .   <a href="#page-4">4</a>
   <a href="#section-6">6</a>.  Normative References  . . . . . . . . . . . . . . . . . . . .   <a href="#page-4">4</a>
   <a href="#appendix-A">Appendix A</a>.  Acknowledgements . . . . . . . . . . . . . . . . . .   <a href="#page-5">5</a>

<span class="h2"><a class="selflink" id="section-1" href="#section-1">1</a>.  Introduction</span>

   In the two decades after publication of <a href="./rfc2026">RFC 2026</a> [<a href="./rfc2026" title=""The Internet Standards Process -- Revision 3"">RFC2026</a>], the IETF
   has evolved its review processes of Proposed Standard RFCs, and thus
   <a href="./rfc2026#section-4.1.1">Section 4.1.1 of RFC 2026</a> no longer accurately describes IETF
   Proposed Standards.

   This document only updates the characterization of Proposed Standards
   from <a href="./rfc2026#section-4.1.1">Section 4.1.1 of RFC 2026</a> and does not speak to or alter the
   procedures for the maintenance of Standards Track documents from <a href="./rfc2026">RFC</a>
   <a href="./rfc2026">2026</a> and <a href="./rfc6410">RFC 6410</a> [<a href="./rfc6410" title=""Reducing the Standards Track to Two Maturity Levels"">RFC6410</a>].  For complete understanding of the
   requirements for standardization, those documents should be read in
   conjunction with this document.

<span class="h2"><a class="selflink" id="section-2" href="#section-2">2</a>.  IETF Review of Proposed Standards</span>

   The entry-level maturity for the standards track is "Proposed
   Standard".  A specific action by the IESG is required to move a
   specification onto the Standards Track at the "Proposed Standard"
   level.

   Initially it was intended that most IETF technical specifications
   would progress through a series of maturity stages starting with
   Proposed Standard, then progressing to Draft Standard, then finally
   to Internet Standard (see <a href="./rfc2026#section-6">Section 6 of RFC 2026</a>).  For a number of
   reasons this progression is not common.  Many Proposed Standards are
   actually deployed on the Internet and used extensively, as stable
   protocols.  This proves the point that the community often deems it
   unnecessary to upgrade a specification to Internet Standard.  Actual
   practice has been that full progression through the sequence of
   standards levels is typically quite rare, and most popular IETF
   protocols remain at Proposed Standard.  Over time, the IETF has
   developed a more extensive review process.






<span class="grey">Kolkman, et al.           Best Current Practice                 [Page 2]</span>

<span id="page-3" ></span>
<span class="grey"><a href="./rfc7127">RFC 7127</a>         Characterization of Proposed Standards     January 2014</span>


   IETF Proposed Standards documents have been subject to open
   development and review by the Internet technical community, generally
   including a number of formal cross-discipline reviews and,
   specifically, a security review.  This is further strengthened in
   many cases by implementations and even the presence of interoperable
   code.  Hence, IETF Proposed Standards are of such quality that they
   are ready for the usual market-based product development and
   deployment efforts into the Internet.

<span class="h2"><a class="selflink" id="section-3" href="#section-3">3</a>.  Characterization of Specifications</span>

   The text in the following section replaces <a href="./rfc2026#section-4.1.1">Section 4.1.1 of RFC 2026</a>.
   <a href="#section-3.2">Section 3.2</a> is a verbatim copy of the characterization of Internet
   Standards from <a href="./rfc2026#section-4.1.3">Section 4.1.3 of RFC 2026</a> and is provided for
   convenient reference.  The text only provides the characterization;
   process issues for Draft and Internet Standards are described in <a href="./rfc2026">RFC</a>
   <a href="./rfc2026">2026</a> and its updates, specifically <a href="./rfc6410">RFC 6410</a>.

<span class="h3"><a class="selflink" id="section-3.1" href="#section-3.1">3.1</a>.  Characterization of IETF Proposed Standard Specifications</span>

   The entry-level maturity for the standards track is "Proposed
   Standard".  A specific action by the IESG is required to move a
   specification onto the standards track at the "Proposed Standard"
   level.

   A Proposed Standard specification is stable, has resolved known
   design choices, has received significant community review, and
   appears to enjoy enough community interest to be considered valuable.

   Usually, neither implementation nor operational experience is
   required for the designation of a specification as a Proposed
   Standard.  However, such experience is highly desirable and will
   usually represent a strong argument in favor of a Proposed Standard
   designation.

   The IESG may require implementation and/or operational experience
   prior to granting Proposed Standard status to a specification that
   materially affects the core Internet protocols or that specifies
   behavior that may have significant operational impact on the
   Internet.

   A Proposed Standard will have no known technical omissions with
   respect to the requirements placed upon it.  Proposed Standards are
   of such quality that implementations can be deployed in the Internet.
   However, as with all technical specifications, Proposed Standards may
   be revised if problems are found or better solutions are identified,
   when experiences with deploying implementations of such technologies
   at scale is gathered.



<span class="grey">Kolkman, et al.           Best Current Practice                 [Page 3]</span>

<span id="page-4" ></span>
<span class="grey"><a href="./rfc7127">RFC 7127</a>         Characterization of Proposed Standards     January 2014</span>


<span class="h3"><a class="selflink" id="section-3.2" href="#section-3.2">3.2</a>.  Characteristics of Internet Standards</span>

   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.

<span class="h2"><a class="selflink" id="section-4" href="#section-4">4</a>.  Further Considerations</span>

   Occasionally, the IETF may choose to publish as Proposed Standard a
   document that contains areas of known limitations or challenges.  In
   such cases, any known issues with the document will be clearly and
   prominently communicated in the document, for example, in the
   abstract, the introduction, or a separate section or statement.

<span class="h2"><a class="selflink" id="section-5" href="#section-5">5</a>.  Security Considerations</span>

   This document does not directly affect the security of the Internet.

<span class="h2"><a class="selflink" id="section-6" href="#section-6">6</a>.  Normative References</span>

   [<a id="ref-RFC2026">RFC2026</a>]  Bradner, S., "The Internet Standards Process -- Revision
              3", <a href="https://www.rfc-editor.org/bcp/bcp9">BCP 9</a>, <a href="./rfc2026">RFC 2026</a>, October 1996.

   [<a id="ref-RFC6410">RFC6410</a>]  Housley, R., Crocker, D., and E. Burger, "Reducing the
              Standards Track to Two Maturity Levels", <a href="https://www.rfc-editor.org/bcp/bcp9">BCP 9</a>, <a href="./rfc6410">RFC 6410</a>,
              October 2011.





















<span class="grey">Kolkman, et al.           Best Current Practice                 [Page 4]</span>

<span id="page-5" ></span>
<span class="grey"><a href="./rfc7127">RFC 7127</a>         Characterization of Proposed Standards     January 2014</span>


<span class="h2"><a class="selflink" id="appendix-A" href="#appendix-A">Appendix A</a>.  Acknowledgements</span>

   This document is inspired by a discussion at the open microphone
   session during the technical plenary at IETF 87.  Thanks to, in
   alphabetical order, Jari Arkko, Carsten Bormann, Scott Brim, Randy
   Bush, Benoit Claise, Dave Cridland, Spencer Dawkins, Adrian Farrel,
   Stephen Farrell, Subramanian Moonesamy, and Pete Resnick for
   motivation, input, and review.

   John Klensin and Dave Crocker have provided significant
   contributions.

Authors' Addresses

   Olaf Kolkman
   Stichting NLnet Labs
   Science Park 400
   Amsterdam  1098 XH
   The Netherlands

   EMail: [email protected]
   URI:   <a href="http://www.nlnetlabs.nl/">http://www.nlnetlabs.nl/</a>


   Scott O. Bradner
   Harvard University Information Technology
   Innovation and Architecture
   8 Story St., Room 5014
   Cambridge, MA  02138
   United States of America

   Phone: +1 617 495 3864
   EMail: [email protected]
   URI:   <a href="http://www.harvard.edu/huit">http://www.harvard.edu/huit</a>


   Sean Turner
   IECA, Inc.

   EMail: [email protected]











Kolkman, et al.           Best Current Practice                 [Page 5]