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