INTERNET-DRAFT R. Housley Updates: 2026 (if approved) Vigil Security Intended Status: BCP D. Crocker Brandenburg InternetWorking E. Burger Georgetown University Expires: 24 July 2011 24 January 2011 Reducing the Standards Track to Two Maturity Levels draft-housley-two-maturity-levels-03.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 IETF standards track maturity levels to two. {{ RFC Editor: please change "proposes several changes to the" to "changes 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. This document is subject to BCP 78 and the IETF Trust's Legal Housley, Crocker, and Burger [Page 1] INTERNET-DRAFT January 2011 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 IETF Standards Process and reduce impediments to standards progression while preserving the most important benefits of the IETF engineering approach. {{ 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 current environment, many documents are published as Proposed Standards and never advance to a higher maturity level. In addition, IETF working groups and IESG members providing much more scrutiny than is called for by RFC 2026 [1] prior to publication as Proposed Standard. One desired outcome is to provide an environment where the IETF community is able to publish Proposed Standards as soon as rough consensus is achieved. Similarly, subsequent revisions to the documents ought to be easier to publish, whether the document is advancing on the maturity ladder or not. Maturity level advancement ought to be based on achieving widespread deployment of quality specifications. Further, protocols are improved by removing complexity associated with features that are not used in practice. 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. The benefit associated with a third maturity level has proven insufficient to Housley, Crocker, and Burger [Page 2] INTERNET-DRAFT January 2011 justify the effort associated with document progression. The two maturity levels are Proposed Standard and Internet Standard. {{ RFC Editor: please change "This document, once approved, replaces" to "This document replaces". }} Experience with a Proposed Standard often leads to revisions that clarify, modify, enhance, or remove features. Review of revisions to a Proposed Standard that is submitted for publication at the same maturity level is generally limited to the changes. Reconsideration of the portions that were previously approved for publication as a Proposed Standard requires evidence that the unchanged features are causing harm to the Internet. A specification shall remain at the Proposed Standard maturity level for at least six (6) months before consideration for advancement to the Internet Standard maturity level. 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]. Various influences have made publishing a Proposed Standard much harder than the stated requirements in RFC 2026. The intention of the two-tier maturity ladder is to restore the requirements for Proposed Standard from RFC 2026. No new requirements are introduced; no existing published requirements are relaxed. 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 Housley, Crocker, and Burger [Page 3] INTERNET-DRAFT January 2011 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: * There are a significant number of implementations with successful operational experience. * There are no unresolved errata against the specification that would cause a new implementation to fail to interoperate with deployed ones. * There are no unused features in the specification that greatly increase implementation complexity. 3. 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. 4. Downward References Permitted Internet Standards are allowed to make normative references to Proposed Standards. The rules that make references to documents at lower maturity levels are a major cause of stagnation in the advancement of documents. This change allows an Internet Standard to freely reference features in any standards track RFC. The intent of this change is to enable expeditious promotion of Proposed Standards to Internet Standards. Downward references to Informational documents are allowed using the procedure specified in RFC 3967 [2]. Downward references to Internet-Draft documents continue to be prohibited. 5. Open Question Regarding STD Numbers Under current practice, a STD number is assigned only when a document (or document set) reaches the full Standard maturity level. In several situations, an RFC that has reached the full Standard maturity level has been obsoleted by a RFC at Proposed Standard Housley, Crocker, and Burger [Page 4] INTERNET-DRAFT January 2011 maturity level, causing great confusion about which specification ought to be implemented. During the IETF 78 plenary discussion, several people advocated abandoning STD numbers. These people felt that the confusion associated with these numbers out weights their value. Other people felt that the ability to assign one number to a collection of Internet Standards was very valuable. This document makes no change to the current STD practice; however, this topic deserves further discussion by the whole community. 6. Security Considerations This document does not directly affect the security of the Internet. 7. IANA Considerations This document requests no action by the IANA. {{ RFC Editor: Please delete this section before publication. }} 8. 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. 9. Normative References [1] Bradner, S., "The Internet Standards Process -- Revision 3", BCP 9, RFC 2026, October 1996. [2] Bush, R., and T. Narten, "Clarifying when Standards Track Documents may Refer Normatively to Documents at a Lower Level", BCP 97, RFC 3967, December 2004. Author's Address Russell Housley Vigil Security, LLC Email: housley@vigilsec.com Housley, Crocker, and Burger [Page 5] INTERNET-DRAFT January 2011 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]