idnits 2.17.1 draft-kolkman-proposed-standards-clarified-06.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 (November 04, 2013) is 3823 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 06, 2014 S. Turner 7 IECA, Inc. 8 November 04, 2013 10 Characterization of Proposed Standards 11 draft-kolkman-proposed-standards-clarified-06 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 06, 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 . . . . . . . . . . . . . . . . . . . 4 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. Version 05->06 . . . . . . . . . . . . . . . . . 8 71 Appendix B.8. Editors versioning info . . . . . . . . . . . . . 9 72 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 9 74 1. Introduction 76 [Editor Note: ietf@ietf.org is the mailing-list for discussing this 77 draft.] 79 In the two decades after publication of RFC 2026 [RFC2026] the IETF 80 has evolved its review processes of Proposed Standard RFCs and thus 81 RFC 2026 section 4.1.1 no longer accurately describes IETF Proposed 82 Standards. 84 This document only updates the characterization of Proposed Standards 85 from RFC2026 Section 4.1.1 and does not speak to or alter the 86 procedures for the maintenance of Standards Track documents from RFC 87 2026 and RFC 6410 [RFC6410]. For complete understanding of the 88 requirements for standardization those documents should be read in 89 conjunction with this document. 91 2. IETF Review of Proposed Standards 93 The entry-level maturity for the standards track is "Proposed 94 Standard". A specific action by the IESG is required to move a 95 specification onto the standards track at the "Proposed Standard" 96 level. 98 Initially it was intended that most IETF technical specifications 99 would progress through a series of maturity stages starting with 100 Proposed Standard, then progressing to Draft Standard then, finally, 101 to Internet Standard (see RFC 2026 section 6). For a number of 102 reasons this progression is not common. Many Proposed Standards are 103 actually deployed on the Internet and used extensively, as stable 104 protocols. This proves the point that the community often deems it 105 unnecessary to upgrade a specification to Internet Standard. Actual 106 practice has been that full progression through the sequence of 107 standards levels is typically quite rare, and most popular IETF 108 protocols remain at Proposed Standard. Over time, the IETF has 109 developed a more extensive review process. 111 IETF Proposed Standards documents have been subject to open 112 development and review by the Internet technical community, generally 113 including a number of formal cross-discipline reviews including, 114 specifically, a security review. This is further strengthened in 115 many cases by implementations and even the presence of interoperable 116 code. Hence IETF Proposed Standards are of such quality that they 117 are ready for the usual market-based product development and 118 deployment efforts into the Internet. 120 3. Characterization of Specifications 122 The text in the following section replaces RFC 2026 Section 4.1.1. 123 Section 3.2 is a verbatim copy of the characterization of Internet 124 Standards from RFC 2026 Section 4.1.3 and is provided for convenient 125 reference. The text only provides the characterization, process 126 issues for Draft and Internet standards are described in RFC2026 and 127 its updates, specifically RFC6410. 129 3.1. Characterization of IETF Proposed Standard Specifications 131 The entry-level maturity for the standards track is "Proposed 132 Standard". A specific action by the IESG is required to move a 133 specification onto the standards track at the "Proposed Standard" 134 level. 136 A Proposed Standard specification is stable, has resolved known 137 design choices and has received significant community review, and 138 appears to enjoy enough community interest to be considered valuable. 140 Usually, neither implementation nor operational experience is 141 required for the designation of a specification as a Proposed 142 Standard. However, such experience is highly desirable, and will 143 usually represent a strong argument in favor of a Proposed Standard 144 designation. 146 The IESG may require implementation and/or operational experience 147 prior to granting Proposed Standard status to a specification that 148 materially affects the core Internet protocols or that specifies 149 behavior that may have significant operational impact on the 150 Internet. 152 A Proposed Standard will have no known technical omissions with 153 respect to the requirements placed upon it. Proposed Standards are 154 of such quality that implementations can be deployed in the Internet. 155 However, as with all technical specifications, Proposed Standards may 156 be revised if problems are found or better solutions are identified, 157 when experiences with deploying implementations of such technologies 158 at scale is gathered. 160 3.2. Characteristics of Internet Standards 161 A specification for which significant implementation and successful 162 operational experience has been obtained may be elevated to the 163 Internet Standard level. An Internet Standard (which may simply be 164 referred to as a Standard) is characterized by a high degree of 165 technical maturity and by a generally held belief that the specified 166 protocol or service provides significant benefit to the Internet 167 community. 169 4. Further Considerations 171 Occasionally the IETF may choose to publish as Proposed Standard a 172 document that contains areas of known limitations or challenges. In 173 such cases any known issues with the document will be clearly and 174 prominently communicated in the document, for example in the 175 abstract, the introduction, or a separate section or statement. 177 5. Security Considerations 179 This document does not directly affect the security of the Internet. 181 6. IANA Considerations 183 There are no actions for IANA. 185 7. References 187 [RFC2026] Bradner, S., "The Internet Standards Process -- Revision 188 3", BCP 9, RFC 2026, October 1996. 190 [RFC6410] Housley, R., Crocker, D. and E. Burger, "Reducing the 191 Standards Track to Two Maturity Levels", BCP 9, RFC 6410, 192 October 2011. 194 Appendix A. Acknowledgements 196 This document is inspired by a discussion at the open microphone 197 session during the technical plenary at IETF 87. Thanks to, in 198 alphabetical order: Jari Arkko, Carsten Bormann, Scott Brim, Spencer 199 Dawkins, Randy Bush, Benoit Claise, Dave Cridland, Adrian Farrel, 200 Stephen Farrel, Subramanian Moonesamy, and Pete Resnick for 201 motivation, input, and review. 203 John Klensin and Dave Crocker have provided significant 204 contributions. 206 Appendix B. Internet Draft Notes and RFC Editor Instructions 208 This section is to assist reviewers of this document. 210 [Editor Note: Please remove this section and its subsections at 211 publication] 213 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 312 Refinement of the abstract text based on input by Dave Crocker and 313 Pete Resnick 315 In Section 2 Crocker suggested: 317 OLD: 319 Over time, for a number of reasons, this progression became less 320 common. In response, the IETF strengthened its review of Proposed 321 Standards, basically operating as if the Proposed Standard was the 322 last chance for the IETF to ensure the quality of the technology and 323 the clarity of the Standard Track document. The result was that IETF 324 Proposed Standards approved over the last decade or more have had 325 extensive reviews. 327 NEW: 329 For a number of reasons this progression is not common. Many 330 Proposed Standards are actually deployed on the Internet and used 331 extensively, as stable protocols. This proves the point that the 332 community often deems it unnecessary to upgrade a specification to 333 Internet Standard. Actual practice has been that full progression 334 through the sequence of standards levels is typically quite rare, and 335 most popular IETF protocols remain at Proposed Standard. Over time, 336 the IETF has developed a more extensive review process. 338 In the same section the comparisson with other SDOs triggered quite 339 some comments from the IESG. The following replacement was suggested 340 by Crocker, the reference to security review was based on the ballot 341 write-up by S. Farrel, the text also addresses Claise's point made in 342 his ballot write-up. 344 OLD: 346 Because of this change in review assumptions, IETF Proposed Standards 347 should be considered to be at least as mature as final standards from 348 other standards development organizations. The IETF review is 349 possibly more extensive than that done in most other SDOs owing to 350 the cross-area technical review performed by the IETF, exemplified by 351 technical review by the full IESG at the last stage of specification 352 development. That position is further strengthened by the common 353 presence of interoperable running code and implementation before 354 publication as a Proposed Standard. 356 NEW: 358 IETF Proposed Standards documents have been subject to open 359 development and review by the Internet technical community, generally 360 including a number of formal cross-discipline reviews including, 361 specifically, a security review. This is further strengthened in 362 many cases by implementations and even the presence of interoperable 363 code. Hence IETF Proposed Standards are of such quality that they 364 are ready for the usual market-based product development and 365 deployment efforts into the Internet. 367 In section Section 3.1: 369 OLD: 371 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. Version 05->06 395 OLD (in section Section 3: 397 The text in the following section replaces RFC 2026 Section 4.1.1. 398 Section 3.2 is a verbatim copy of the characterization of Internet 399 Standards from RFC 2026 Section 4.1.3 and is provided for convenient 400 reference. 402 NEW: 404 The text in the following section replaces RFC 2026 Section 4.1.1. 405 Section 3.2 is a verbatim copy of the characterization of Internet 406 Standards from RFC 2026 Section 4.1.3 and is provided for convenient 407 reference. The text only provides the characterization, process 408 issues for Draft and Internet standards are described in RFC2028 and 409 its updates, specifically RFC6410. 411 OLD (in section Section 4: 413 While less mature specifications will usually be published as 414 Informational or Experimental RFCs, the IETF may publish a Proposed 415 Standard that still contains areas for improvement or certain 416 uncertainties about whether the best engineering choices are made. 417 In those cases that fact will be clearly and prominently communicated 418 in the document e.g. in the abstract, the introduction, or a 419 separate section or statement. 421 NEW: 423 Occasionally the IETF may choose to publish as Proposed Standard a 424 document that contains areas of known limitations or challenges. In 425 such cases any known issues with the document will be clearly and 426 prominently communicated in the document, for example in the 427 abstract, the introduction, or a separate section or statement. 429 Appendix B.8. Editors versioning info 431 $Id: draft-kolkman-proposed-standards-clarified.xml 21 2013-11-04 432 19:37:28Z olaf $ 434 Authors' Addresses 436 Olaf Kolkman 437 Stichting NLnet Labs 438 Science Park 400 439 Amsterdam, 1098 XH 440 The Netherlands 442 Email: olaf@nlnetlabs.nl 443 URI: http://www.nlnetlabs.nl/ 445 Scott O. Bradner 446 Harvard University Information Technology 447 Innovation and Architecture 448 1350 Mass Ave., Room 760 449 Cambridge, MA 02138 450 United States of America 452 Phone: +1 617 495 3864 453 Email: sob@harvard.edu 454 URI: http://www.harvard.edu/huit 456 Sean Turner 457 IECA, Inc. 459 Email: turners@ieca.com