idnits 2.17.1 draft-kolkman-proposed-standards-clarified-05.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: ---------------------------------------------------------------------------- == The page length should not exceed 58 lines per page, but there was 1 longer page, the longest (page 2) being 60 lines Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. 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 (October 31, 2013) is 3830 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: 1 error (**), 0 flaws (~~), 2 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group O. Kolkman 3 Internet-Draft NLnet Labs 4 Updates: 2026 (if approved) S. Bradner 5 Intended status: Best Current Practice Harvard University 6 Expires: May 02, 2014 S. Turner 7 IECA, Inc. 8 October 31, 2013 10 Characterization of Proposed Standards 11 draft-kolkman-proposed-standards-clarified-05 13 Abstract 15 RFC 2026 describes the review performed by the IESG on IETF Proposed 16 Standard RFCs and characterizes the maturity level of those 17 documents. This document updates RFC 2026 by providing a current and 18 more accurate characterization of Proposed Standards. 20 Status of this Memo 22 This Internet-Draft is submitted in full conformance with the 23 provisions of BCP 78 and BCP 79. 25 Internet-Drafts are working documents of the Internet Engineering 26 Task Force (IETF). Note that other groups may also distribute 27 working documents as Internet-Drafts. The list of current Internet- 28 Drafts is at http://datatracker.ietf.org/drafts/current/. 30 Internet-Drafts are draft documents valid for a maximum of six months 31 and may be updated, replaced, or obsoleted by other documents at any 32 time. It is inappropriate to use Internet-Drafts as reference 33 material or to cite them other than as "work in progress." 35 This Internet-Draft will expire on May 02, 2014. 37 Copyright Notice 39 Copyright (c) 2013 IETF Trust and the persons identified as the 40 document authors. All rights reserved. 42 This document is subject to BCP 78 and the IETF Trust's Legal 43 Provisions Relating to IETF Documents (http://trustee.ietf.org/ 44 license-info) in effect on the date of publication of this document. 45 Please review these documents carefully, as they describe your rights 46 and restrictions with respect to this document. Code Components 47 extracted from this document must include Simplified BSD License text 48 as described in Section 4.e of the Trust Legal Provisions and are 49 provided without warranty as described in the Simplified BSD License. 51 Table of Contents 53 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 2 54 2. IETF Review of Proposed Standards . . . . . . . . . . . . . . 2 55 3. Characterization of Specifications . . . . . . . . . . . . . . 3 56 3.1. Characterization of IETF Proposed Standard Specifications 3 57 3.2. Characteristics of Internet Standards . . . . . . . . . . 3 58 4. Further Considerations . . . . . . . . . . . . . . . . . . . . 4 59 5. Security Considerations . . . . . . . . . . . . . . . . . . . 4 60 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 4 61 7. References . . . . . . . . . . . . . . . . . . . . . . . . . . 4 62 Appendix A. Acknowledgements . . . . . . . . . . . . . . . . . . . 4 63 Appendix B. Internet Draft Notes and RFC Editor Instructions . . . 4 64 Appendix B.1. Version 00 . . . . . . . . . . . . . . . . . . . 5 65 Appendix B.2. Version 00->01 . . . . . . . . . . . . . . . . . 6 66 Appendix B.3. Version 01->02 . . . . . . . . . . . . . . . . . 6 67 Appendix B.4. Version 02->03 . . . . . . . . . . . . . . . . . 6 68 Appendix B.5. Version 03->04 . . . . . . . . . . . . . . . . . 6 69 Appendix B.6. Version 04->05 . . . . . . . . . . . . . . . . . 6 70 Appendix B.7. Editors versioning info . . . . . . . . . . . . . 8 71 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 8 73 1. Introduction 75 [Editor Note: ietf@ietf.org is the mailing-list for discussing this 76 draft.] 78 In the two decades after publication of RFC 2026 [RFC2026] the IETF 79 has evolved its review processes of Proposed Standard RFCs and thus 80 RFC 2026 section 4.1.1 no longer accurately describes IETF Proposed 81 Standards. 83 This document only updates the characterization of Proposed Standards 84 from RFC2026 Section 4.1.1 and does not speak to or alter the 85 procedures for the maintenance of Standards Track documents from RFC 86 2026 and RFC 6410 [RFC6410]. For complete understanding of the 87 requirements for standardization those documents should be read in 88 conjunction with this document. 90 2. IETF Review of Proposed Standards 92 The entry-level maturity for the standards track is "Proposed 93 Standard". A specific action by the IESG is required to move a 94 specification onto the standards track at the "Proposed Standard" 95 level. 97 Initially it was intended that most IETF technical specifications 98 would progress through a series of maturity stages starting with 99 Proposed Standard, then progressing to Draft Standard then, finally, 100 to Internet Standard (see RFC 2026 section 6). For a number of 101 reasons this progression is not common. Many Proposed Standards are 102 actually deployed on the Internet and used extensively, as stable 103 protocols. This proves the point that the community often deems it 104 unnecessary to upgrade a specification to Internet Standard. Actual 105 practice has been that full progression through the sequence of 106 standards levels is typically quite rare, and most popular IETF 107 protocols remain at Proposed Standard. Over time, the IETF has 108 developed a more extensive review process. 110 IETF Proposed Standards documents have been subject to open 111 development and review by the Internet technical community, generally 112 including a number of formal cross-discipline reviews including, 113 specifically, a security review. This is further strengthened in 114 many cases by implementations and even the presence of interoperable 115 code. Hence IETF Proposed Standards are of such quality that they 116 are ready for the usual market-based product development and 117 deployment efforts into the Internet. 119 3. Characterization of Specifications 121 The text in the following section replaces RFC 2026 Section 4.1.1. 122 Section 3.2 is a verbatim copy of the characterization of Internet 123 Standards from RFC 2026 Section 4.1.3 and is provided for convenient 124 reference. 126 3.1. Characterization of IETF Proposed Standard Specifications 128 The entry-level maturity for the standards track is "Proposed 129 Standard". A specific action by the IESG is required to move a 130 specification onto the standards track at the "Proposed Standard" 131 level. 133 A Proposed Standard specification is stable, has resolved known 134 design choices and has received significant community review, and 135 appears to enjoy enough community interest to be considered valuable. 137 Usually, neither implementation nor operational experience is 138 required for the designation of a specification as a Proposed 139 Standard. However, such experience is highly desirable, and will 140 usually represent a strong argument in favor of a Proposed Standard 141 designation. 143 The IESG may require implementation and/or operational experience 144 prior to granting Proposed Standard status to a specification that 145 materially affects the core Internet protocols or that specifies 146 behavior that may have significant operational impact on the 147 Internet. 149 A Proposed Standard will have no known technical omissions with 150 respect to the requirements placed upon it. Proposed Standards are 151 of such quality that implementations can be deployed in the Internet. 152 However, as with all technical specifications, Proposed Standards may 153 be revised if problems are found or better solutions are identified, 154 when experiences with deploying implementations of such technologies 155 at scale is gathered. 157 3.2. Characteristics of Internet Standards 158 A specification for which significant implementation and successful 159 operational experience has been obtained may be elevated to the 160 Internet Standard level. An Internet Standard (which may simply be 161 referred to as a Standard) is characterized by a high degree of 162 technical maturity and by a generally held belief that the specified 163 protocol or service provides significant benefit to the Internet 164 community. 166 4. Further Considerations 168 While less mature specifications will usually be published as 169 Informational or Experimental RFCs, the IETF may publish a Proposed 170 Standard that still contains areas for improvement or certain 171 uncertainties about whether the best engineering choices are made. 172 In those cases that fact will be clearly and prominently communicated 173 in the document e.g. in the abstract, the introduction, or a 174 separate section or statement. 176 5. Security Considerations 178 This document does not directly affect the security of the Internet. 180 6. IANA Considerations 182 There are no actions for IANA. 184 7. References 186 [RFC2026] Bradner, S., "The Internet Standards Process -- Revision 187 3", BCP 9, RFC 2026, October 1996. 189 [RFC6410] Housley, R., Crocker, D. and E. Burger, "Reducing the 190 Standards Track to Two Maturity Levels", BCP 9, RFC 6410, 191 October 2011. 193 Appendix A. Acknowledgements 195 This document is inspired by a discussion at the open microphone 196 session during the technical plenary at IETF 87. Thanks to, in 197 alphabetical order: Jari Arkko, Carsten Bormann, Scott Brim, Spencer 198 Dawkins, Randy Bush, Benoit Claise, Dave Cridland, Adrian Farrel, 199 Stephen Farrel, Subramanian Moonesamy, and Pete Resnick for 200 motivation, input, and review. 202 John Klensin and Dave Crocker have provided significant 203 contributions. 205 Appendix B. Internet Draft Notes and RFC Editor Instructions 207 This section is to assist reviewers of this document. 209 [Editor Note: Please remove this section and its subsections at 210 publication] 212 Appendix B.1. Version 00 214 Introduction and motivation 216 Verbatim copy from section 4.1.1 and 4.1.3 of [RFC2026] of the 217 Proposed and ant Internet Draft characterization into Section 3.1 and 218 Section 3.2 220 Modification of paragraphs of the Proposed Standards 221 characterization, namely: 223 OLD: 225 A Proposed Standard specification is generally stable, has resolved 226 known design choices, is believed to be well-understood, has received 227 significant community review, and appears to enjoy enough community 228 interest to be considered valuable. However, further experience 229 might result in a change or even retraction of the specification 230 before it advances. 232 NEW: 234 A Proposed Standard specification is stable, has resolved known 235 design choices, is well-understood, has received significant 236 community review, and appears to enjoy enough community interest to 237 be considered valuable. However, as with all technical standards, 238 further experience might result in a change or even retraction of the 239 specification in the future. 241 OLD: 243 A Proposed Standard should have no known technical omissions with 244 respect to the requirements placed upon it. However, the IESG may 245 waive this requirement in order to allow a specification to advance 246 to the Proposed Standard state when it is considered to be useful and 247 necessary (and timely) even with known technical omissions. 249 Implementors should treat Proposed Standards as immature 250 specifications. It is desirable to implement them in order to gain 251 experience and to validate, test, and clarify the specification. 252 However, since the content of Proposed Standards may be changed if 253 problems are found or better solutions are identified, deploying 254 implementations of such standards into a disruption-sensitive 255 environment is not recommended. 257 NEW: 259 A Proposed Standard will have no known technical omissions with 260 respect to the requirements placed upon it. Proposed Standards are 261 of such quality that implementations can be deployed in the Internet. 262 However, as with all technical specifications, Proposed Standards may 263 be revised if problems are found or better solutions are identified, 264 when experiences with deploying implementations of such technologies 265 at scale is gathered. 267 Appendix B.2. Version 00->01 269 Added "Updates 2026" and added Sean's initial" 271 Copied the whole characterization paragraph for Internet Standards 272 from 2026, instead of only the line that is the actual 273 characterization itself. 275 Added the Further Consideration section based on discussion on the 276 mailinglist. 278 Appendix B.3. Version 01->02 280 Sharpened the 2nd paragraph of the Introduction to be clear that the 281 scope of the update is limited to section 4.1.1. and that this 282 document should not be read stand-alone. 284 Refined the "Further Considerations" Sections to express that as part 285 of the process less mature specs are sometimes approved as Proposed 286 Standards but that in those cases the documents should clearly 287 indicate that. 289 Minor editorial nits, and corrections. 291 Appendix B.4. Version 02->03 293 Changed a number of occurances where IESG review was used to the 294 intended IETF review. 296 Appendix B.5. Version 03->04 298 s/In fact, the IETF review is more extensive than that done in most 299 other SDOs/The IETF review is possibly more extensive than that done 300 in most other SDOs/ 302 Minor spelling and style errors. 304 Appendix B.6. Version 04->05 306 Comments from the IESG are in: http://datatracker.ietf.org/doc/draft- 307 kolkman-proposed-standards-clarified/ballot/ 309 Crocker's comment are in http://www.ietf.org/mail-archive/web/ietf/ 310 current/msg83488.html 311 Refinement of the abstract text based on input by Dave Crocker and 312 Pete Resnick 314 In Section 2 Crocker suggested: 316 OLD: 318 Over time, for a number of reasons, this progression became less 319 common. In response, the IETF strengthened its review of Proposed 320 Standards, basically operating as if the Proposed Standard was the 321 last chance for the IETF to ensure the quality of the technology and 322 the clarity of the Standard Track document. The result was that IETF 323 Proposed Standards approved over the last decade or more have had 324 extensive reviews. 326 NEW: 328 For a number of reasons this progression is not common. Many 329 Proposed Standards are actually deployed on the Internet and used 330 extensively, as stable protocols. This proves the point that the 331 community often deems it unnecessary to upgrade a specification to 332 Internet Standard. Actual practice has been that full progression 333 through the sequence of standards levels is typically quite rare, and 334 most popular IETF protocols remain at Proposed Standard. Over time, 335 the IETF has developed a more extensive review process. 337 In the same section the comparisson with other SDOs triggered quite 338 some comments from the IESG. The following replacement was suggested 339 by Crocker, the reference to security review was based on the ballot 340 write-up by S. Farrel, the text also addresses Claise's point made in 341 his ballot write-up. 343 OLD: 345 Because of this change in review assumptions, IETF Proposed Standards 346 should be considered to be at least as mature as final standards from 347 other standards development organizations. The IETF review is 348 possibly more extensive than that done in most other SDOs owing to 349 the cross-area technical review performed by the IETF, exemplified by 350 technical review by the full IESG at the last stage of specification 351 development. That position is further strengthened by the common 352 presence of interoperable running code and implementation before 353 publication as a Proposed Standard. 355 NEW: 357 IETF Proposed Standards documents have been subject to open 358 development and review by the Internet technical community, generally 359 including a number of formal cross-discipline reviews including, 360 specifically, a security review. This is further strengthened in 361 many cases by implementations and even the presence of interoperable 362 code. Hence IETF Proposed Standards are of such quality that they 363 are ready for the usual market-based product development and 364 deployment efforts into the Internet. 366 In section Section 3.1: 368 OLD: 370 design choices, is well-understood, has received significant 372 NEW: 374 design choices and has received significant 376 RATIONALE: see Crocker's review. 378 In Section 4: 380 OLD: 382 the IETF may, on occasion, publish a specification that still 383 contains areas 385 NEW: 387 the IETF may publish a Proposed Standard that still contains 389 FURTHER: 391 Minor spelling and style errors 393 Appendix B.7. Editors versioning info 395 $Id: draft-kolkman-proposed-standards-clarified.xml 18 2013-10-31 396 08:05:25Z olaf $ 398 Authors' Addresses 400 Olaf Kolkman 401 Stichting NLnet Labs 402 Science Park 400 403 Amsterdam, 1098 XH 404 The Netherlands 406 Email: olaf@nlnetlabs.nl 407 URI: http://www.nlnetlabs.nl/ 408 Scott O. Bradner 409 Harvard University Information Technology 410 Innovation and Architecture 411 1350 Mass Ave., Room 760 412 Cambridge, MA 02138 413 United States of America 415 Phone: +1 617 495 3864 416 Email: sob@harvard.edu 417 URI: http://www.harvard.edu/huit 419 Sean Turner 420 IECA, Inc. 422 Email: turners@ieca.com