idnits 2.17.00 (12 Aug 2021) /tmp/idnits24400/draft-kolkman-proposed-standards-clarified-04.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 17, 2013) is 3137 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: April 18, 2014 S. Turner 7 IECA, Inc. 8 October 17, 2013 10 Characterization of Proposed Standards 11 draft-kolkman-proposed-standards-clarified-04 13 Abstract 15 RFC 2026 describes the review performed by the IESG on IETF Proposed 16 Standard RFCs and states the maturity level of those documents. This 17 document clarifies those descriptions and updates RFC 2026 by 18 providing a new 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 April 18, 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 Specification . . . . . . . . . . . . . . 3 56 3.1. Characterization of IETF Proposed Standard Specifications 3 57 3.2. Characteristics of Internet Standards . . . . . . . . . . 4 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 . . . 5 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. Editors versioning info . . . . . . . . . . . . . 6 70 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 6 72 1. Introduction 74 [Editor Note: ietf@ietf.org is the mailing-list for discussing this 75 draft.] 77 In the two decades after publication of RFC 2026 [RFC2026] the IETF 78 has evolved its review processes of Proposed Standard RFCs and thus 79 RFC 2026 section 4.1.1 no longer accurately describes IETF Proposed 80 Standards. 82 This document exclusively updates the characterization of Proposed 83 Standards from RFC2026 Section 4.1.1 and does not speak to or alter 84 the procedures for the maintenance of Standards Track documents from 85 RFC 2026 and RFC 6410 [RFC6410]. For complete understanding of the 86 requirements for standardization those documents should be read in 87 conjunction with this document. 89 2. IETF Review of Proposed Standards 91 The entry-level maturity for the standards track is "Proposed 92 Standard". A specific action by the IESG is required to move a 93 specification onto the standards track at the "Proposed Standard" 94 level. 96 Initially it was assumed that most IETF technical specifications 97 would progress through a series of maturity stages starting with 98 Proposed Standard, then progressing to Draft Standard then, finally, 99 to Internet Standard (see RFC 2026 section 6). Over time, for a 100 number of reasons, this progression became less common. In response, 101 the IETF strengthened its review of Proposed Standards, basically 102 operating as if the Proposed Standard was the last chance for the 103 IETF to ensure the quality of the technology and the clarity of the 104 Standard Track document. The result was that IETF Proposed Standards 105 approved over the last decade or more have had extensive reviews. 106 Because of this change in review assumptions, IETF Proposed Standards 107 should be considered to be at least as mature as final standards from 108 other standards development organizations. The IETF review is 109 possibly more extensive than that done in most other SDOs owing to 110 the cross-area technical review performed by the IETF, exemplified by 111 technical review by the full IESG at the last stage of specification 112 development. That position is further strengthened by the common 113 presence of interoperable running code and implementation before 114 publication as a Proposed Standard. 116 3. Characterization of Specification 118 Section 3.1 of this document replaces RFC 2026 Section 4.1.1. Section 119 3.2 is a verbatim copy of the characterization of Internet Standards 120 from RFC 2026 Section 4.1.3 and is provided for convenient reference. 122 3.1. Characterization of IETF Proposed Standard Specifications 124 The entry-level maturity for the standards track is "Proposed 125 Standard". A specific action by the IESG is required to move a 126 specification onto the standards track at the "Proposed Standard" 127 level. 129 A Proposed Standard specification is stable, has resolved known 130 design choices, is well-understood, has received significant 131 community review, and appears to enjoy enough community interest to 132 be considered valuable. 134 Usually, neither implementation nor operational experience is 135 required for the designation of a specification as a Proposed 136 Standard. However, such experience is highly desirable, and will 137 usually represent a strong argument in favor of a Proposed Standard 138 designation. 140 The IESG may require implementation and/or operational experience 141 prior to granting Proposed Standard status to a specification that 142 materially affects the core Internet protocols or that specifies 143 behavior that may have significant operational impact on the 144 Internet. 146 A Proposed Standard will have no known technical omissions with 147 respect to the requirements placed upon it. Proposed Standards are 148 of such quality that implementations can be deployed in the Internet. 149 However, as with all technical specifications, Proposed Standards may 150 be revised if problems are found or better solutions are identified, 151 when experiences with deploying implementations of such technologies 152 at scale is gathered. 154 3.2. Characteristics of Internet Standards 156 A specification for which significant implementation and successful 157 operational experience has been obtained may be elevated to the 158 Internet Standard level. An Internet Standard (which may simply be 159 referred to as a Standard) is characterized by a high degree of 160 technical maturity and by a generally held belief that the specified 161 protocol or service provides significant benefit to the Internet 162 community. 164 4. Further Considerations 166 While less mature specifications will usually be published as 167 Informational or Experimental RFCs, the IETF may, on occasion, 168 publish a specification that still contains areas for improvement or 169 certain uncertainties about whether the best engineering choices are 170 made. In those cases that fact will be clearly and prominently 171 communicated in the document e.g. in the abstract, the introduction, 172 or a separate section or statement. 174 5. Security Considerations 176 This document does not directly affect the security of the Internet. 178 6. IANA Considerations 180 There are no actions for IANA. 182 7. References 184 [RFC2026] Bradner, S., "The Internet Standards Process -- Revision 185 3", BCP 9, RFC 2026, October 1996. 187 [RFC6410] Housley, R., Crocker, D. and E. Burger, "Reducing the 188 Standards Track to Two Maturity Levels", BCP 9, RFC 6410, 189 October 2011. 191 Appendix A. Acknowledgements 193 This document is inspired by a discussion at the open microphone 194 session during the technical plenary at IETF 87. Thanks to, in 195 alphabetical order: Jari Arkko, Carsten Bormann, Scott Brim, Spencer 196 Dawkins, Randy Bush, Benoit Claise, Dave Cridland, Adrian Farrel, 197 John Klensin, Subramanian Moonesamy for motivation, input, and 198 review. 200 Appendix B. Internet Draft Notes and RFC Editor Instructions 202 This section is to assist reviewers of this document. 204 [Editor Note: Please remove this section and its subsections at 205 publication] 207 Appendix B.1. Version 00 209 Introduction and motivation 211 Verbatim copy from section 4.1.1 and 4.1.3 of [RFC2026] of the 212 Proposed and ant Internet Draft characterization into Section 3.1 and 213 Section 3.2 215 Modification of paragraphs of the Proposed Standards 216 characterization, namely: 218 OLD: 220 A Proposed Standard specification is generally stable, has resolved 221 known design choices, is believed to be well-understood, has received 222 significant community review, and appears to enjoy enough community 223 interest to be considered valuable. However, further experience 224 might result in a change or even retraction of the specification 225 before it advances. 227 NEW: 229 A Proposed Standard specification is stable, has resolved known 230 design choices, is well-understood, has received significant 231 community review, and appears to enjoy enough community interest to 232 be considered valuable. However, as with all technical standards, 233 further experience might result in a change or even retraction of the 234 specification in the future. 236 OLD: 238 A Proposed Standard should have no known technical omissions with 239 respect to the requirements placed upon it. However, the IESG may 240 waive this requirement in order to allow a specification to advance 241 to the Proposed Standard state when it is considered to be useful and 242 necessary (and timely) even with known technical omissions. 244 Implementors should treat Proposed Standards as immature 245 specifications. It is desirable to implement them in order to gain 246 experience and to validate, test, and clarify the specification. 247 However, since the content of Proposed Standards may be changed if 248 problems are found or better solutions are identified, deploying 249 implementations of such standards into a disruption-sensitive 250 environment is not recommended. 252 NEW: 254 A Proposed Standard will have no known technical omissions with 255 respect to the requirements placed upon it. Proposed Standards are 256 of such quality that implementations can be deployed in the Internet. 257 However, as with all technical specifications, Proposed Standards may 258 be revised if problems are found or better solutions are identified, 259 when experiences with deploying implementations of such technologies 260 at scale is gathered. 262 Appendix B.2. Version 00->01 264 Added "Updates 2026" and added Sean's initial" 266 Copied the whole characterization paragraph for Internet Standards 267 from 2026, instead of only the line that is the actual 268 characterization itself. 270 Added the Further Consideration section based on discussion on the 271 mailinglist. 273 Appendix B.3. Version 01->02 275 Sharpened the 2nd paragraph of the Introduction to be clear that the 276 scope of the update is limited to section 4.1.1. and that this 277 document should not be read stand-alone. 279 Refined the "Further Considerations" Sections to express that as part 280 of the process less mature specs are sometimes approved as Proposed 281 Standards but that in those cases the documents should clearly 282 indicate that. 284 Minor editorial nits, and corrections. 286 Appendix B.4. Version 02->03 288 Changed a number of occurances where IESG review was used to the 289 intended IETF review. 291 Appendix B.5. Version 03->04 293 s/In fact, the IETF review is more extensive than that done in most 294 other SDOs/The IETF review is possibly more extensive than that done 295 in most other SDOs/ 297 Minor spelling and style errors 299 Appendix B.6. Editors versioning info 301 $Id: draft-kolkman-proposed-standards-clarified.xml 16 2013-10-17 302 13:22:30Z olaf $ 304 Authors' Addresses 305 Olaf Kolkman 306 Stichting NLnet Labs 307 Science Park 400 308 Amsterdam, 1098 XH 309 The Netherlands 311 Email: olaf@nlnetlabs.nl 312 URI: http://www.nlnetlabs.nl/ 314 Scott O. Bradner 315 Harvard University Information Technology 316 Innovation and Architecture 317 1350 Mass Ave., Room 760 318 Cambridge, MA 02138 319 United States of America 321 Phone: +1 617 495 3864 322 Email: sob@harvard.edu 323 URI: http://www.harvard.edu/huit 325 Sean Turner 326 IECA, Inc. 328 Email: turners@ieca.com