idnits 2.17.00 (12 Aug 2021) /tmp/idnits25458/draft-kolkman-proposed-standards-clarified-00.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 -- The document date (August 02, 2013) is 3213 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- No issues found here. Summary: 1 error (**), 0 flaws (~~), 2 warnings (==), 1 comment (--). 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 Intended status: Informational S. Bradner 5 Expires: February 01, 2014 Harvard University 6 Turner 7 IECA, Inc. 8 August 02, 2013 10 Characterization of Proposed Standards 11 draft-kolkman-proposed-standards-clarified-00 13 Abstract 15 This document clarifies the description of the review performed on 16 and the maturity level of IETF Proposed Standard RFCs. 18 Status of this Memo 20 This Internet-Draft is submitted in full conformance with the 21 provisions of BCP 78 and BCP 79. 23 Internet-Drafts are working documents of the Internet Engineering 24 Task Force (IETF). Note that other groups may also distribute 25 working documents as Internet-Drafts. The list of current Internet- 26 Drafts is at http://datatracker.ietf.org/drafts/current/. 28 Internet-Drafts are draft documents valid for a maximum of six months 29 and may be updated, replaced, or obsoleted by other documents at any 30 time. It is inappropriate to use Internet-Drafts as reference 31 material or to cite them other than as "work in progress." 33 This Internet-Draft will expire on February 01, 2014. 35 Copyright Notice 37 Copyright (c) 2013 IETF Trust and the persons identified as the 38 document authors. All rights reserved. 40 This document is subject to BCP 78 and the IETF Trust's Legal 41 Provisions Relating to IETF Documents (http://trustee.ietf.org/ 42 license-info) in effect on the date of publication of this document. 43 Please review these documents carefully, as they describe your rights 44 and restrictions with respect to this document. Code Components 45 extracted from this document must include Simplified BSD License text 46 as described in Section 4.e of the Trust Legal Provisions and are 47 provided without warranty as described in the Simplified BSD License. 49 Table of Contents 51 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 2 52 2. IESG Reveiew of Proposed Standards . . . . . . . . . . . . . . 2 53 3. Characterization of Specification . . . . . . . . . . . . . . 2 54 3.1. Characterization of IETF Proposed Standard Specifications 2 55 3.2. Characteristics of Internet Standards . . . . . . . . . . 3 56 4. Security Considerations . . . . . . . . . . . . . . . . . . . 3 57 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 3 58 6. References . . . . . . . . . . . . . . . . . . . . . . . . . . 3 59 Appendix A. Acknowledgements . . . . . . . . . . . . . . . . . . . 4 60 Appendix B. Internet Draft Editing History . . . . . . . . . . . . 4 61 Appendix B.1. Version 00 . . . . . . . . . . . . . . . . . . . 4 62 Appendix B.2. Editors versioning info . . . . . . . . . . . . . 5 63 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 5 65 1. Introduction 67 [Editor Note: ietf@ietf.org is the mailing-list for discussing this 68 draft.] 70 In the two decades after publication of RFC 2026 [RFC2026] the IESG 71 has evolved its review processes of Proposed Standard RFCs and thus 72 RFC 2026 section 4.1.1 no longer accurately describes IETF Proposed 73 Standards. 75 This document updates the characterization of Proposed Standards but 76 does not speak to or alter the standard maintenance procedures from 77 RFC 2026 and RFC 6410 [RFC6410]. 79 2. IESG Reveiew of Proposed Standards 81 The entry-level maturity for the standards track is "Proposed 82 Standard". A specific action by the IESG is required to move a 83 specification onto the standards track at the "Proposed Standard" 84 level. 86 Initially it was assumed that most IETF technical specifications 87 would progress through a series of maturity stages starting with 88 Proposed Standard, then progressing to Draft Standard then, finally, 89 to Internet Standard (see RFC 2026 section 6). Over time, for a 90 number of reasons, this progression became less common. In response, 91 the IESG strengthened its review of Proposed Standards, basically 92 operating as if the Proposed Standard was the last chance for the 93 IESG to ensure the quality of the technology and the clarity of the 94 standards document. The result was that IETF Proposed Standards 95 approved over the last decade or more have had extensive review. 96 Because of this change in review assumptions, IETF Proposed Standards 97 should be considered to be at least as mature as final standards from 98 other standards development organizations. In fact, the IETF review 99 is more extensive than is done in other SDOs due to the cross-area 100 technical review performed by the IESG. 102 3. Characterization of Specification 104 Section 3.1 updates RFC 2026 Section 4.1.1. Section 3.2 is a verbatim 105 copy of the characterization of Internet Standards from RFC 2026 106 Section 4.1.3. 108 3.1. Characterization of IETF Proposed Standard Specifications 109 The entry-level maturity for the standards track is "Proposed 110 Standard". A specific action by the IESG is required to move a 111 specification onto the standards track at the "Proposed Standard" 112 level. 114 A Proposed Standard specification is stable, has resolved known 115 design choices, is well-understood, has received significant 116 community review, and appears to enjoy enough community interest to 117 be considered valuable. However, as with all technical standards, 118 further experience might result in a change or even retraction of the 119 specification in the future. 121 Usually, neither implementation nor operational experience is 122 required for the designation of a specification as a Proposed 123 Standard. However, such experience is highly desirable, and will 124 usually represent a strong argument in favor of a Proposed Standard 125 designation. 127 The IESG may require implementation and/or operational experience 128 prior to granting Proposed Standard status to a specification that 129 materially affects the core Internet protocols or that specifies 130 behavior that may have significant operational impact on the 131 Internet. 133 A Proposed Standard will have no known technical omissions with 134 respect to the requirements placed upon it. Proposed Standards are 135 of such quality that implementations can be deployed in the Internet. 136 However, as with all technical specifications, Proposed Standards may 137 be revised if problems are found or better solutions are identified, 138 when experiences with deploying implementations of such technologies 139 at scale is gathered. 141 3.2. Characteristics of Internet Standards 143 An Internet Standard is characterized by a high degree of technical 144 maturity and by a generally held belief that the specified protocol 145 or service provides significant benefit to the Internet community. 147 4. Security Considerations 149 This document does not directly affect the security of the Internet. 151 5. IANA Considerations 153 There are no actions for IANA. 155 6. References 157 [RFC2026] Bradner, S., "The Internet Standards Process -- Revision 158 3", BCP 9, RFC 2026, October 1996. 160 [RFC6410] Housley, R., Crocker, D. and E. Burger, "Reducing the 161 Standards Track to Two Maturity Levels", BCP 9, RFC 6410, 162 October 2011. 164 Appendix A. Acknowledgements 166 This document is inspired by a discussion at the open microphone 167 session during the technical plenary at IETF 87. Thanks for [to be 168 added] for motivation, input and review. 170 Appendix B. Internet Draft Editing History 172 This section is to assist reviewers of this document. It will be 173 removed at publication as RFC. 175 Appendix B.1. Version 00 177 Introduction and motivation 179 Verbatim copy from section 4.1.1 and 4.1.3 of [RFC2026] of the 180 Proposed and ant Internet Draft characterization into Section 3.1 and 181 Section 3.2 183 Modification of paragraphs of the Proposed Standards 184 characterization, namely: 186 OLD: 188 A Proposed Standard specification is generally stable, has resolved 189 known design choices, is believed to be well-understood, has received 190 significant community review, and appears to enjoy enough community 191 interest to be considered valuable. However, further experience 192 might result in a change or even retraction of the specification 193 before it advances. 195 NEW: 197 A Proposed Standard specification is stable, has resolved known 198 design choices, is well-understood, has received significant 199 community review, and appears to enjoy enough community interest to 200 be considered valuable. However, as with all technical standards, 201 further experience might result in a change or even retraction of the 202 specification in the future. 204 OLD: 206 A Proposed Standard should have no known technical omissions with 207 respect to the requirements placed upon it. However, the IESG may 208 waive this requirement in order to allow a specification to advance 209 to the Proposed Standard state when it is considered to be useful and 210 necessary (and timely) even with known technical omissions. 212 Implementors should treat Proposed Standards as immature 213 specifications. It is desirable to implement them in order to gain 214 experience and to validate, test, and clarify the specification. 215 However, since the content of Proposed Standards may be changed if 216 problems are found or better solutions are identified, deploying 217 implementations of such standards into a disruption-sensitive 218 environment is not recommended. 220 NEW: 222 A Proposed Standard will have no known technical omissions with 223 respect to the requirements placed upon it. Proposed Standards are 224 of such quality that implementations can be deployed in the Internet. 225 However, as with all technical specifications, Proposed Standards may 226 be revised if problems are found or better solutions are identified, 227 when experiences with deploying implementations of such technologies 228 at scale is gathered. 230 Appendix B.2. Editors versioning info 232 $Id: draft-kolkman-proposed-standards-clarified.xml 4 2013-08-02 233 04:42:37Z olaf $ 235 Authors' Addresses 237 Olaf Kolkman 238 Stichting NLnet Labs 239 Science Park 400 240 Amsterdam, 1098 XH 241 The Netherlands 243 Email: olaf@nlnetlabs.nl 244 URI: http://www.nlnetlabs.nl/ 246 Scott O. Bradner 247 Harvard University Information Technology 248 Innovation and Architecture 249 1350 Mass Ave., Room 760 250 Cambridge, MA 02138 251 United States of America 253 Phone: +1 617 495 3864 254 Email: sob@harvard.edu 255 URI: http://www.harvard.edu/huit 257 Sean Turner 258 IECA, Inc. 260 Email: turners@ieca.com