idnits 2.17.1 draft-housley-two-maturity-levels-09.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- -- The draft header indicates that this document updates RFC2026, but the abstract doesn't seem to directly say this. It does mention RFC2026 though, so this could be OK. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year (Using the creation date from RFC2026, updated by this document, for RFC5378 checks: 1995-09-12) -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (1 September 2011) is 4593 days in the past. Is this intentional? Checking references for intended status: Best Current Practice ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) No issues found here. Summary: 0 errors (**), 0 flaws (~~), 1 warning (==), 3 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 INTERNET-DRAFT R. Housley 3 Updates: 2026 (if approved) Vigil Security 4 Intended Status: BCP D. Crocker 5 Brandenburg InternetWorking 6 E. Burger 7 Georgetown University 8 Expires: 1 March 2012 1 September 2011 10 Reducing the Standards Track to Two Maturity Levels 11 13 Abstract 15 This document proposes several changes to the Internet Engineering 16 Task Force (IETF) Standards Process defined in RFC 2026, primarily a 17 reduction from three standards track maturity levels to two. 19 {{ RFC Editor: please change "proposes several changes to the" to 20 "updates the". }} 22 Status of this Memo 24 This Internet-Draft is submitted to IETF in full conformance with the 25 provisions of BCP 78 and BCP 79. 27 Internet-Drafts are working documents of the Internet Engineering 28 Task Force (IETF), its areas, and its working groups. Note that other 29 groups may also distribute working documents as Internet-Drafts. 31 Internet-Drafts are draft documents valid for a maximum of six months 32 and may be updated, replaced, or obsoleted by other documents at any 33 time. It is inappropriate to use Internet-Drafts as reference 34 material or to cite them other than as "work in progress." 36 The list of current Internet-Drafts can be accessed at 37 http://www.ietf.org/1id-abstracts.html 39 The list of Internet-Draft Shadow Directories can be accessed at 40 http://www.ietf.org/shadow.html 42 Copyright Notice 44 Copyright (c) 2011 IETF Trust and the persons identified as the 45 document authors. All rights reserved. 47 This document is subject to BCP 78 and the IETF Trust's Legal 48 Provisions Relating to IETF Documents 49 (http://trustee.ietf.org/license-info) in effect on the date of 50 publication of this document. Please review these documents 51 carefully, as they describe your rights and restrictions with respect 52 to this document. 54 1. Introduction 56 This document proposes several changes to the Internet Standards 57 Process defined in RFC 2026 [1]. In recent years, the Internet 58 Engineering Task Force (IETF) has witnessed difficulty in advancing 59 documents through the maturity levels: Proposed Standard, Draft 60 Standard, and finally Standard. These changes are designed to 61 simplify the Standards Process and reduce impediments to standards 62 progression while preserving the most important benefits of the IETF 63 engineering approach. In addition, the requirement for annual review 64 of standards-track documents that have not reached the top of the 65 maturity ladder is removed from the Internet Standards Process. 67 {{ RFC Editor: please change "proposes several changes to the" to 68 "changes the". }} 70 Over the years, there have been many proposals for refining the 71 Internet Standards Process to reduce impediments to standards 72 progression. During May 2010, the Internet Engineering Steering 73 Group (IESG) discussed many of these proposals. Then, a plenary 74 discussion at IETF 78 in July 2010 demonstrated significant support 75 for transition from a three-tier maturity ladder to one with two 76 tiers. 78 In the Internet Standards Process, experience with a Proposed 79 Standard is expected to motivate revisions that clarify, modify, 80 enhance, or remove features. However, in recent years, the vast 81 majority of standards track documents are published as Proposed 82 Standards and never advance to a higher maturity level. Very few 83 specifications have advanced on the maturity ladder in the last 84 decade. Changing the Internet Standards Process from three maturity 85 levels to two is intended to create an environment where lessons from 86 implementation and deployment experience are used to improve 87 specifications. 89 The primary aspect of this change is to revise the requirements for 90 advancement beyond Proposed Standard. RFC 2026 [1] requires a report 91 that documents interoperability between at least two implementations 92 from different code bases as an interim step ("Draft Standard") 93 before a specification can be advanced further to the third and final 94 maturity level ("Standard") based on widespread deployment and use. 96 In contrast, this document measures interoperability through 97 widespread deployment of multiple implementations from different code 98 bases, thus condensing the two separate metrics into one. 100 The result of this change is expected to be maturity level 101 advancement based on achieving widespread deployment of quality 102 specifications, while at the same time, incorporating lessons from 103 implementation and deployment experience, and recognizing that 104 protocols are improved by removing complexity associated with unused 105 features. 107 In RFC 2026 [1], widespread deployment is essentially the metric used 108 for advancement from Draft Standard to Standard. The use of this 109 same metric for advancement beyond Proposed Standard means that there 110 is no longer a useful distinction between the top two tiers of the 111 maturity ladder. Thus, the maturity ladder is reduced to two tiers. 113 In addition, RFC 2026 [1] requires annual review of specifications 114 that have not achieved the top maturity level. This review is no 115 longer required. 117 2. Two Maturity Levels 119 This document, once approved, replaces the three-tier maturity ladder 120 defined in RFC 2026 [1] with a two-tier maturity ladder. 121 Specifications become Internet Standards through a set of two 122 maturity levels known as the "standards track". These maturity 123 levels are "Proposed Standard" and "Internet Standard". 125 {{ RFC Editor: please change "This document, once approved, replaces" 126 to "This document replaces". }} 128 A specification may be, and indeed, is likely to be, revised as it 129 advances from Proposed Standard to Internet Standard. When a revised 130 specification is proposed for advancement to Internet Standard, the 131 IESG shall determine the scope and significance of the changes to the 132 specification, and, if necessary and appropriate, modify the 133 recommended action. Minor revisions and the removal of unused 134 features are expected, but a significant revision may require that 135 the specification accumulate more experience at Proposed Standard 136 before progressing. 138 2.1. The First Maturity Level: Proposed Standard 140 The stated requirements for Proposed Standard are not changed; they 141 remain exactly as specified in RFC 2026 [1]. No new requirements are 142 introduced; no existing published requirements are relaxed. 144 2.2. The Second Maturity Level: Internet Standard 146 This maturity level is a merger of Draft Standard and Standard as 147 specified in RFC 2026 [1]. The chosen name avoids confusion between 148 "Draft Standard" and "Internet-Draft". 150 The characterization of an Internet Standard remains as described in 151 RFC 2026 [1], which says: 153 An Internet Standard is characterized by a high degree of 154 technical maturity and by a generally held belief that the 155 specified protocol or service provides significant benefit 156 to the Internet community. 158 The criteria for advancing from Proposed Standard to Internet 159 Standard are confirmed by the IESG in an IETF-wide Last Call of at 160 least four weeks. The request for reclassification is sent to the 161 IESG along with an explanation of how the criteria have been met. 162 The criteria are: 164 (1) There are at least two independent interoperating implementations 165 with widespread deployment and successful operational experience. 167 (2) There are no errata against the specification that would cause a 168 new implementation to fail to interoperate with deployed ones. 170 (3) There are no unused features in the specification that greatly 171 increase implementation complexity. 173 (4) If patented or otherwise controlled technology is required for 174 implementation, the implementations demonstrate at least two 175 separate and successful uses of the licensing process. 177 After review and consideration of significant errata, the IESG will 178 perform an IETF-wide Last Call of at least four weeks on the 179 requested reclassification. If there is consensus for 180 reclassification, the RFC will be reclassified without publication of 181 a new RFC. 183 As stated in RFC 2026 [1], in a timely fashion after the expiration 184 of the Last Call period, the IESG shall make its final determination 185 and notify the IETF of its decision via electronic mail to the IETF 186 Announce mailing list. No changes are made to Section 6.1.2 of RFC 187 2026 [1]. 189 2.3. Transition to a Standards Track with Two Maturity Levels 191 Any protocol or service that is currently at the Proposed Standard 192 maturity level remains so. 194 Any protocol or service that is currently at the Standard maturity 195 level shall be immediately reclassified as an Internet Standard. 197 Any protocol or service that is currently at the abandoned Draft 198 Standard maturity level will retain that classification, absent 199 explicit actions. Two possible actions are available: 201 (1) A Draft Standard may be reclassified as an Internet Standard as 202 soon as the criteria in Section 2.2 are satisfied. 204 (2) At any time after two years from the approval of this document as 205 a BCP, the IESG may choose to reclassify any Draft Standard 206 document as Proposed Standard. 208 3. Removed Requirements 210 3.1. Removal of Requirement for Annual Review 212 In practice the annual review of Proposed Standard and Draft Standard 213 documents after two years called for in RFC 2026 [1] has not taken 214 place. Lack of this review has not revealed any ill effects on the 215 Internet Standards Process. As a result, the requirement for this 216 review is dropped. No review cycle is imposed on standards track 217 documents at any maturity level. 219 3.2. Requirement for Interoperability Testing Reporting 221 Testing for interoperability is a long tradition in the development 222 of Internet protocols and remains important for reliable deployment 223 of services. The IETF Standards Process no longer requires a formal 224 interoperability report, recognizing that deployment and use is 225 sufficient to show interoperability. 227 Although no longer required by the IETF Standards Processes, RFC 5657 228 [2] can be helpful for efforts to conduct interoperability testing. 230 4. Security Considerations 232 This document does not directly affect the security of the Internet. 234 5. IANA Considerations 236 This document requests no action by the IANA. 238 {{ RFC Editor: Please delete this section before publication. }} 240 6. Acknowledgements 242 A two-tier standards track proposal has been proposed many times. 243 Spencer Dawkins, Charlie Perkins, and Dave Crocker made a proposal in 244 2003. Another proposal was made by Scott Bradner in 2004. Another 245 proposal was made by Brian Carpenter in June 2005. Another proposal 246 was made by Ran Atkinson in 2006. This document takes ideas from 247 many of these prior proposals; it also incorporates ideas from the 248 IESG discussion in May 2010, the IETF 78 plenary discussion in July 249 2010, and yet another proposal submitted by Spencer Dawkins, Dave 250 Crocker, Eric Burger, and Peter Saint-Andre in November 2010. 252 7. References 254 7.1. Normative References 256 [1] Bradner, S., "The Internet Standards Process -- Revision 3", 257 RFC 2026, October 1996. 259 7.2. Informative References 261 [2] Dusseault, L., and R. Sparks, "Guidance on Interoperation and 262 Implementation Reports for Advancement to Draft Standard", 263 RFC 5657, September 2009. 265 Author's Address 267 Russell Housley 268 Vigil Security, LLC 269 Email: housley@vigilsec.com 271 Dave Crocker 272 Brandenburg InternetWorking 273 Email: dcrocker@bbiw.net 275 Eric W. Burger 276 Georgetown University 277 Email: eburger@standardstrack.com 278 URI: http://www.standardstrack.com