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