idnits 2.17.1 draft-kolkman-proposed-standards-clarified-01.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 13, 2013) is 3877 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- 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: Informational Harvard University 6 Expires: March 15, 2014 S. Turner 7 IECA, Inc. 8 September 13, 2013 10 Characterization of Proposed Standards 11 draft-kolkman-proposed-standards-clarified-01 13 Abstract 15 This document clarifies the description of the review performed on 16 and the maturity level of IETF Proposed Standard RFCs and updates RFC 17 2026 19 Status of this Memo 21 This Internet-Draft is submitted in full conformance with the 22 provisions of BCP 78 and BCP 79. 24 Internet-Drafts are working documents of the Internet Engineering 25 Task Force (IETF). Note that other groups may also distribute 26 working documents as Internet-Drafts. The list of current Internet- 27 Drafts is at http://datatracker.ietf.org/drafts/current/. 29 Internet-Drafts are draft documents valid for a maximum of six months 30 and may be updated, replaced, or obsoleted by other documents at any 31 time. It is inappropriate to use Internet-Drafts as reference 32 material or to cite them other than as "work in progress." 34 This Internet-Draft will expire on March 15, 2014. 36 Copyright Notice 38 Copyright (c) 2013 IETF Trust and the persons identified as the 39 document authors. All rights reserved. 41 This document is subject to BCP 78 and the IETF Trust's Legal 42 Provisions Relating to IETF Documents (http://trustee.ietf.org/ 43 license-info) in effect on the date of publication of this document. 44 Please review these documents carefully, as they describe your rights 45 and restrictions with respect to this document. Code Components 46 extracted from this document must include Simplified BSD License text 47 as described in Section 4.e of the Trust Legal Provisions and are 48 provided without warranty as described in the Simplified BSD License. 50 Table of Contents 52 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 2 53 2. IESG Reveiew of Proposed Standards . . . . . . . . . . . . . . 2 54 3. Characterization of Specification . . . . . . . . . . . . . . 2 55 3.1. Characterization of IETF Proposed Standard Specifications 3 56 3.2. Characteristics of Internet Standards . . . . . . . . . . 3 57 4. Further Considerations . . . . . . . . . . . . . . . . . . . . 3 58 5. Security Considerations . . . . . . . . . . . . . . . . . . . 4 59 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 4 60 7. References . . . . . . . . . . . . . . . . . . . . . . . . . . 4 61 Appendix A. Acknowledgements . . . . . . . . . . . . . . . . . . . 4 62 Appendix B. Internet Draft Editing History . . . . . . . . . . . . 4 63 Appendix B.1. Version 00 . . . . . . . . . . . . . . . . . . . 4 64 Appendix B.2. Version 00->01 . . . . . . . . . . . . . . . . . 5 65 Appendix B.3. Editors versioning info . . . . . . . . . . . . . 5 66 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 5 68 1. Introduction 70 [Editor Note: ietf@ietf.org is the mailing-list for discussing this 71 draft.] 73 In the two decades after publication of RFC 2026 [RFC2026] the IESG 74 has evolved its review processes of Proposed Standard RFCs and thus 75 RFC 2026 section 4.1.1 no longer accurately describes IETF Proposed 76 Standards. 78 This document updates the characterization of Proposed Standards from 79 RFC2026 but does not speak to or alter the standard maintenance 80 procedures from RFC 2026 and RFC 6410 [RFC6410]. 82 2. IESG Reveiew of Proposed Standards 84 The entry-level maturity for the standards track is "Proposed 85 Standard". A specific action by the IESG is required to move a 86 specification onto the standards track at the "Proposed Standard" 87 level. 89 Initially it was assumed that most IETF technical specifications 90 would progress through a series of maturity stages starting with 91 Proposed Standard, then progressing to Draft Standard then, finally, 92 to Internet Standard (see RFC 2026 section 6). Over time, for a 93 number of reasons, this progression became less common. In response, 94 the IESG strengthened its review of Proposed Standards, basically 95 operating as if the Proposed Standard was the last chance for the 96 IESG to ensure the quality of the technology and the clarity of the 97 standards document. The result was that IETF Proposed Standards 98 approved over the last decade or more have had extensive review. 99 Because of this change in review assumptions, IETF Proposed Standards 100 should be considered to be at least as mature as final standards from 101 other standards development organizations. In fact, the IETF review 102 is more extensive than is done in other SDOs due to the cross-area 103 technical review performed by the IESG. 105 3. Characterization of Specification 107 Section 3.1 updates RFC 2026 Section 4.1.1. Section 3.2 is a verbatim 108 copy of the characterization of Internet Standards from RFC 2026 109 Section 4.1.3. 111 3.1. Characterization of IETF Proposed Standard Specifications 113 The entry-level maturity for the standards track is "Proposed 114 Standard". A specific action by the IESG is required to move a 115 specification onto the standards track at the "Proposed Standard" 116 level. 118 A Proposed Standard specification is stable, has resolved known 119 design choices, is well-understood, has received significant 120 community review, and appears to enjoy enough community interest to 121 be considered valuable. However, as with all technical standards, 122 further experience might result in a change or even retraction of the 123 specification in the future. 125 Usually, neither implementation nor operational experience is 126 required for the designation of a specification as a Proposed 127 Standard. However, such experience is highly desirable, and will 128 usually represent a strong argument in favor of a Proposed Standard 129 designation. 131 The IESG may require implementation and/or operational experience 132 prior to granting Proposed Standard status to a specification that 133 materially affects the core Internet protocols or that specifies 134 behavior that may have significant operational impact on the 135 Internet. 137 A Proposed Standard will have no known technical omissions with 138 respect to the requirements placed upon it. Proposed Standards are 139 of such quality that implementations can be deployed in the Internet. 140 However, as with all technical specifications, Proposed Standards may 141 be revised if problems are found or better solutions are identified, 142 when experiences with deploying implementations of such technologies 143 at scale is gathered. 145 3.2. Characteristics of Internet Standards 147 A specification for which significant implementation and successful 148 operational experience has been obtained may be elevated to the 149 Internet Standard level. An Internet Standard (which may simply be 150 referred to as a Standard) is characterized by a high degree of 151 technical maturity and by a generally held belief that the specified 152 protocol or service provides significant benefit to the Internet 153 community. 155 4. Further Considerations 156 While commonly less mature specifications will be published as 157 Informational or Experimental RFCs, the IETF may, in exceptional 158 cases, publish a specification that does not match the 159 characterizations above as a Proposed Standard. In those cases that 160 fact will be clearly communicated on the front page of the RFC e.g. 161 means of an IESG statement. 163 5. Security Considerations 165 This document does not directly affect the security of the Internet. 167 6. IANA Considerations 169 There are no actions for IANA. 171 7. References 173 [RFC2026] Bradner, S., "The Internet Standards Process -- Revision 174 3", BCP 9, RFC 2026, October 1996. 176 [RFC6410] Housley, R., Crocker, D. and E. Burger, "Reducing the 177 Standards Track to Two Maturity Levels", BCP 9, RFC 6410, 178 October 2011. 180 Appendix A. Acknowledgements 182 This document is inspired by a discussion at the open microphone 183 session during the technical plenary at IETF 87. Thanks for John 184 Klensin [to be added] for motivation, input and review. 186 Appendix B. Internet Draft Editing History 188 This section is to assist reviewers of this document. It will be 189 removed at publication as RFC. 191 Appendix B.1. Version 00 193 Introduction and motivation 195 Verbatim copy from section 4.1.1 and 4.1.3 of [RFC2026] of the 196 Proposed and ant Internet Draft characterization into Section 3.1 and 197 Section 3.2 199 Modification of paragraphs of the Proposed Standards 200 characterization, namely: 202 OLD: 204 A Proposed Standard specification is generally stable, has resolved 205 known design choices, is believed to be well-understood, has received 206 significant community review, and appears to enjoy enough community 207 interest to be considered valuable. However, further experience 208 might result in a change or even retraction of the specification 209 before it advances. 211 NEW: 213 A Proposed Standard specification is stable, has resolved known 214 design choices, is well-understood, has received significant 215 community review, and appears to enjoy enough community interest to 216 be considered valuable. However, as with all technical standards, 217 further experience might result in a change or even retraction of the 218 specification in the future. 220 OLD: 222 A Proposed Standard should have no known technical omissions with 223 respect to the requirements placed upon it. However, the IESG may 224 waive this requirement in order to allow a specification to advance 225 to the Proposed Standard state when it is considered to be useful and 226 necessary (and timely) even with known technical omissions. 228 Implementors should treat Proposed Standards as immature 229 specifications. It is desirable to implement them in order to gain 230 experience and to validate, test, and clarify the specification. 231 However, since the content of Proposed Standards may be changed if 232 problems are found or better solutions are identified, deploying 233 implementations of such standards into a disruption-sensitive 234 environment is not recommended. 236 NEW: 238 A Proposed Standard will have no known technical omissions with 239 respect to the requirements placed upon it. Proposed Standards are 240 of such quality that implementations can be deployed in the Internet. 241 However, as with all technical specifications, Proposed Standards may 242 be revised if problems are found or better solutions are identified, 243 when experiences with deploying implementations of such technologies 244 at scale is gathered. 246 Appendix B.2. Version 00->01 248 Added "Updates 2026" and added Sean's initial" 250 Copied the whole characterization pararaph for Internet Standards 251 from 2026, instead of only the line that is the actual 252 characterization itself. 254 Added the Further Consideration section based on discussion on the 255 mailinglist. 257 Appendix B.3. Editors versioning info 259 $Id: draft-kolkman-proposed-standards-clarified.xml 6 2013-09-13 260 12:48:48Z olaf $ 262 Authors' Addresses 263 Olaf Kolkman 264 Stichting NLnet Labs 265 Science Park 400 266 Amsterdam, 1098 XH 267 The Netherlands 269 Email: olaf@nlnetlabs.nl 270 URI: http://www.nlnetlabs.nl/ 272 Scott O. Bradner 273 Harvard University Information Technology 274 Innovation and Architecture 275 1350 Mass Ave., Room 760 276 Cambridge, MA 02138 277 United States of America 279 Phone: +1 617 495 3864 280 Email: sob@harvard.edu 281 URI: http://www.harvard.edu/huit 283 Sean Turner 284 IECA, Inc. 286 Email: turners@ieca.com