INTERNET-DRAFT R. Housley Updates: 2026 (if approved) Vigil Security Intended Status: BCP D. Crocker Brandenburg InternetWorking E. Burger Georgetown University Expires: 1 March 2012 1 September 2011 Reducing the Standards Track to Two Maturity Levels <draft-housley-two-maturity-levels-09.txt> Abstract This document proposes several changes to the Internet Engineering Task Force (IETF) Standards Process defined in RFC 2026, primarily a reduction from three standards track maturity levels to two. {{ RFC Editor: please change "proposes several changes to the" to "updates the". }} Status of this Memo This Internet-Draft is submitted to IETF in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet-Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http://www.ietf.org/1id-abstracts.html The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html Copyright Notice Copyright (c) 2011 IETF Trust and the persons identified as the document authors. All rights reserved. Housley, Crocker, and Burger [Page 1]
INTERNET-DRAFT June 2011 This document is subject to BCP 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. 1. Introduction This document proposes several changes to the Internet Standards Process defined in RFC 2026 [1]. In recent years, the Internet Engineering Task Force (IETF) has witnessed difficulty in advancing documents through the maturity levels: Proposed Standard, Draft Standard, and finally Standard. These changes are designed to simplify the Standards Process and reduce impediments to standards progression while preserving the most important benefits of the IETF engineering approach. In addition, the requirement for annual review of standards-track documents that have not reached the top of the maturity ladder is removed from the Internet Standards Process. {{ RFC Editor: please change "proposes several changes to the" to "changes the". }} Over the years, there have been many proposals for refining the Internet Standards Process to reduce impediments to standards progression. During May 2010, the Internet Engineering Steering Group (IESG) discussed many of these proposals. Then, a plenary discussion at IETF 78 in July 2010 demonstrated significant support for transition from a three-tier maturity ladder to one with two tiers. In the Internet Standards Process, experience with a Proposed Standard is expected to motivate revisions that clarify, modify, enhance, or remove features. However, in recent years, the vast majority of standards track documents are published as Proposed Standards and never advance to a higher maturity level. Very few specifications have advanced on the maturity ladder in the last decade. Changing the Internet Standards Process from three maturity levels to two is intended to create an environment where lessons from implementation and deployment experience are used to improve specifications. The primary aspect of this change is to revise the requirements for advancement beyond Proposed Standard. RFC 2026 [1] requires a report that documents interoperability between at least two implementations from different code bases as an interim step ("Draft Standard") before a specification can be advanced further to the third and final maturity level ("Standard") based on widespread deployment and use. Housley, Crocker, and Burger [Page 2]
INTERNET-DRAFT June 2011 In contrast, this document measures interoperability through widespread deployment of multiple implementations from different code bases, thus condensing the two separate metrics into one. The result of this change is expected to be maturity level advancement based on achieving widespread deployment of quality specifications, while at the same time, incorporating lessons from implementation and deployment experience, and recognizing that protocols are improved by removing complexity associated with unused features. In RFC 2026 [1], widespread deployment is essentially the metric used for advancement from Draft Standard to Standard. The use of this same metric for advancement beyond Proposed Standard means that there is no longer a useful distinction between the top two tiers of the maturity ladder. Thus, the maturity ladder is reduced to two tiers. In addition, RFC 2026 [1] requires annual review of specifications that have not achieved the top maturity level. This review is no longer required. 2. Two Maturity Levels This document, once approved, replaces the three-tier maturity ladder defined in RFC 2026 [1] with a two-tier maturity ladder. Specifications become Internet Standards through a set of two maturity levels known as the "standards track". These maturity levels are "Proposed Standard" and "Internet Standard". {{ RFC Editor: please change "This document, once approved, replaces" to "This document replaces". }} 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. 2.1. The First Maturity Level: Proposed Standard The stated requirements for Proposed Standard are not changed; they remain exactly as specified in RFC 2026 [1]. No new requirements are introduced; no existing published requirements are relaxed. Housley, Crocker, and Burger [Page 3]
INTERNET-DRAFT June 2011 2.2. The Second Maturity Level: Internet Standard This maturity level is a merger of Draft Standard and Standard as specified in RFC 2026 [1]. The chosen name avoids confusion between "Draft Standard" and "Internet-Draft". 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. The criteria for advancing from Proposed Standard to Internet Standard are confirmed by the IESG in an IETF-wide Last Call of at least four weeks. 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 patented or otherwise controlled technology is required for implementation, the implementations demonstrate at least two 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. As stated in RFC 2026 [1], 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. No changes are made to Section 6.1.2 of RFC 2026 [1]. Housley, Crocker, and Burger [Page 4]
INTERNET-DRAFT June 2011 2.3. Transition to a Standards Track with Two Maturity Levels Any protocol or service that is currently at the Proposed Standard maturity level remains so. Any protocol or service that is currently at the Standard maturity level shall be immediately reclassified as an Internet Standard. Any protocol or service that is currently at the abandoned Draft Standard maturity level will retain that classification, absent explicit actions. Two possible actions are available: (1) A Draft Standard may be reclassified as an Internet Standard as soon as the criteria in Section 2.2 are satisfied. (2) At any time after two years from the approval of this document as a BCP, the IESG may choose to reclassify any Draft Standard document as Proposed Standard. 3. Removed Requirements 3.1. Removal of Requirement for Annual Review In practice the annual review of Proposed Standard and Draft Standard documents after two years called for in RFC 2026 [1] has not taken place. Lack of this review has not revealed any ill effects on the Internet Standards Process. As a result, the requirement for this review is dropped. No review cycle is imposed on standards track documents at any maturity level. 3.2. Requirement for Interoperability Testing Reporting Testing for interoperability is a long tradition in the development of Internet protocols and remains important for reliable deployment of services. The IETF Standards Process no longer requires a formal interoperability report, recognizing that deployment and use is sufficient to show interoperability. Although no longer required by the IETF Standards Processes, RFC 5657 [2] can be helpful for efforts to conduct interoperability testing. 4. Security Considerations This document does not directly affect the security of the Internet. Housley, Crocker, and Burger [Page 5]
INTERNET-DRAFT June 2011 5. IANA Considerations This document requests no action by the IANA. {{ RFC Editor: Please delete this section before publication. }} 6. Acknowledgements A two-tier standards track proposal has been proposed many times. Spencer Dawkins, Charlie Perkins, and Dave Crocker made a proposal in 2003. Another proposal was made by Scott Bradner in 2004. Another proposal was made by Brian Carpenter in June 2005. Another proposal was made by Ran Atkinson in 2006. This document takes ideas from many of these prior proposals; it also incorporates ideas from the IESG discussion in May 2010, the IETF 78 plenary discussion in July 2010, and yet another proposal submitted by Spencer Dawkins, Dave Crocker, Eric Burger, and Peter Saint-Andre in November 2010. 7. References 7.1. Normative References [1] Bradner, S., "The Internet Standards Process -- Revision 3", RFC 2026, October 1996. 7.2. Informative References [2] Dusseault, L., and R. Sparks, "Guidance on Interoperation and Implementation Reports for Advancement to Draft Standard", RFC 5657, September 2009. Author's Address Russell Housley Vigil Security, LLC Email: housley@vigilsec.com Dave Crocker Brandenburg InternetWorking Email: dcrocker@bbiw.net Eric W. Burger Georgetown University Email: eburger@standardstrack.com URI: http://www.standardstrack.com Housley, Crocker, and Burger [Page 6]
