Internet-Draft R. Housley Updates: 2026 (if approved) Vigil Security Intended Status: BCP 19 June 2010 Expires: 19 December 2010 Reducing the Standards Track to Two Maturity Levels draft-housley-two-maturity-levels-00.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. 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) 2010 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 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. Housley [Page 1] INTERNET DRAFT June 2010 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. The proposed changes are designed to simplify the process and reduce impediments to standards progression while preserving the benefits of the IETF engineering approach. During May 2010, the Internet Engineering Steering Group (IESG) discussed the possible ways of reducing impediments to standards progression. The IESG mad the following observations: o Since many documents are published as Proposed Standard and never advances to a higher maturity level, the initial publication receives much more scrutiny that is call for by RFC 2026 [1]. o When implementation reports are developed, protocols are improved by removing the complexity associated with features that are not used in practice. The intent is to provide an environment where the IETF community gets a "second bite at the apple" so that "good enough" documents are published as soon as rough consensus is achieved. Further, subsequent revisions to the document should easier, with advancement in maturity level being based on achieving interoperable implementations. 2. The First Maturity Level: Proposed Standard The requirements for Proposed Standard are unchanged; they remain exactly as specified in RFC 2026 [1]. 3. The Second Maturity Level 2: Interoperable Standard This maturity level is very similar to Draft Standard as specified in RFC 2026 [1]. The name is changed for two reasons. First, the new name properly places the focus on interoperability. Second, the change avoids confusion between "Draft Standard" and "Internet- Draft". The criteria for advancing from Proposed Standard to Interoperable Standard are roughly the same as the current criteria for moving to Draft Standard. Along with documentation of interoperability testing, the documentation must include information about the support of each of Housley [Page 2] INTERNET DRAFT June 2010 the individual options and features. Guidance on documenting the specific implementations which qualify the specification Interoperable Standard status is provided in RFC 5657 [2]. This documentation should be submitted to the Area Director (AD) with the protocol action request, which is described in Section 6 of RFC 2026 [1]. 4. No Third Maturity Level The final "Standard" maturity level is simply abolished. The benefit associated with third maturity level has proven insufficient to justify the effort associated with document progression. The "Interoperable Standard" becomes the final maturity level. 5. Timing Requirements The requirement for six months between "Proposed Standard" and "Interoperable Standard" is removed. If an interoperability report is provided with the initial protocol action request, then the document can be approved directly at the Interoperable Standard maturity level without first being approved at the Proposed Standard maturity level. In practice the annual review of Proposed Standard documents after two years 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. 6. Downward References Permitted Interoperable Standards are allowed to make normative references to Proposed Standards. The current rule prohibiting "down references" is a major cause of stagnation in the advancement of documents. This change allows an Interoperable Standard to reference features that have not been formally agreed to be demonstrably interoperable. This change enables expeditious promotion of Proposed Standard documents to Interoperable Standard documents by removing a significant impediment. Down references to Internet-Draft documents continue to be prohibited. 7. 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, a Standard is obsoleted by a Proposed Standard, causing great confusion about the specification that ought to be implemented. Further, the assignment of an STD number offers little Housley [Page 3] INTERNET DRAFT June 2010 value. As a result, the STD numbering system is abandoned. 8. Transition to a Standards Track with Two Maturity Levels On the day these changes are published as a BCP, all existing Draft Standard and Standard documents automatically get reclassified as Interoperable Standard documents. Corresponding changes would be made to the RFC Index and other features of the RFC Editor web site. Also, the STD index will be marked historic. 9. Security Considerations This document does not directly affect the security of the Internet. 10. IANA Considerations This document requests no action by the IANA. {{{ RFC Editor: Please delete this section before publication. }}} 11. Acknowledgements A two-stage 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. In May 2010, the IESG discussed the topic at length and came to the conclusion that the current situation was becoming more and more difficult. This proposal takes ideas from the IESG discussion as well as many of these prior proposals. 12. Informative References [1] Bradner, S., "The Internet Standards Process -- Revision 3", BCP 9, RFC 2026, October 1996. [2] Dusseault, L., and R. Sparks, "Guidance on Interoperation and Implementation Reports for Advancement to Draft Standard", BCP 9, RFC 5657, September 2009. Housley [Page 4] INTERNET DRAFT June 2010 Author's Address Russell Housley Vigil Security, LLC 918 Spring Knoll Drive Herndon, VA 20170 USA Email: housley@vigilsec.com Housley [Page 5]