Internet Engineering Task Force (IETF) O. KolkmanRequest for Comments: 7127 NLnet LabsBCP: 9 S. BradnerUpdates:2026 Harvard UniversityCategory: Best Current Practice S. TurnerISSN: 2070-1721 IECA, Inc. January 2014Characterization of Proposed StandardsAbstractRFC 2026 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 updatesRFC 2026 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 inSection 2 of RFC 5741. Information about the current status of this document, any errata, and how to provide feedback on it may be obtained athttp://www.rfc-editor.org/info/rfc7127.Copyright Notice Copyright (c) 2014 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject toBCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) 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.Kolkman, et al. Best Current Practice [Page 1]
RFC 7127 Characterization of Proposed Standards January 2014Table of Contents1. Introduction . . . . . . . . . . . . . . . . . . . . . . . .22. IETF Review of Proposed Standards . . . . . . . . . . . . . .23. Characterization of Specifications . . . . . . . . . . . . .3 3.1. Characterization of IETF Proposed Standard Specifications 33.2. Characteristics of Internet Standards . . . . . . . . . .44. Further Considerations . . . . . . . . . . . . . . . . . . .45. Security Considerations . . . . . . . . . . . . . . . . . . .46. Normative References . . . . . . . . . . . . . . . . . . . .4Appendix A. Acknowledgements . . . . . . . . . . . . . . . . . .51. Introduction In the two decades after publication ofRFC 2026 [RFC2026], the IETF has evolved its review processes of Proposed Standard RFCs, and thusSection 4.1.1 of RFC 2026 no longer accurately describes IETF Proposed Standards. This document only updates the characterization of Proposed Standards fromSection 4.1.1 of RFC 2026 and does not speak to or alter the procedures for the maintenance of Standards Track documents fromRFC2026 andRFC 6410 [RFC6410]. For complete understanding of the requirements for standardization, those documents should be read in conjunction with this document.2. IETF Review of Proposed Standards 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 (seeSection 6 of RFC 2026). 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.Kolkman, et al. Best Current Practice [Page 2]
RFC 7127 Characterization of Proposed Standards January 2014 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.3. Characterization of Specifications The text in the following section replacesSection 4.1.1 of RFC 2026.Section 3.2 is a verbatim copy of the characterization of Internet Standards fromSection 4.1.3 of RFC 2026 and is provided for convenient reference. The text only provides the characterization; process issues for Draft and Internet Standards are described inRFC2026 and its updates, specificallyRFC 6410.3.1. Characterization of IETF Proposed Standard Specifications 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.Kolkman, et al. Best Current Practice [Page 3]
RFC 7127 Characterization of Proposed Standards January 20143.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.4. Further Considerations 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.5. Security Considerations This document does not directly affect the security of the Internet.6. Normative References [RFC2026] Bradner, S., "The Internet Standards Process -- Revision 3",BCP 9,RFC 2026, October 1996. [RFC6410] Housley, R., Crocker, D., and E. Burger, "Reducing the Standards Track to Two Maturity Levels",BCP 9,RFC 6410, October 2011.Kolkman, et al. Best Current Practice [Page 4]
RFC 7127 Characterization of Proposed Standards January 2014Appendix A. Acknowledgements 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: olaf@nlnetlabs.nl URI:http://www.nlnetlabs.nl/ 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: sob@harvard.edu URI:http://www.harvard.edu/huit Sean Turner IECA, Inc. EMail: turners@ieca.comKolkman, et al. Best Current Practice [Page 5]
Datatracker
RFC 7127
RFC - Best Current Practice
| Document | Document type | RFC - Best Current Practice January 2014 Report errata UpdatesRFC 2026 Wasdraft-kolkman-proposed-standards-clarified (individual in gen area) | |
|---|---|---|---|
| Select version | |||
| Compare versions | |||
| Authors | Olaf Kolkman,Scott O. Bradner,Sean Turner Email authors | ||
| RFC stream |   | ||
| Other formats |