idnits 2.17.1 draft-klensin-std-numbers-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: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- -- The draft header indicates that this document updates RFC1311, but the abstract doesn't seem to mention this, which it should. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year (Using the creation date from RFC1311, updated by this document, for RFC5378 checks: 1991-12-05) -- 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 (February 14, 2011) is 4820 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) -- Obsolete informational reference (is this intentional?): RFC 2629 (ref. '3') (Obsoleted by RFC 7749) Summary: 0 errors (**), 0 flaws (~~), 1 warning (==), 4 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group J. Klensin 3 Internet-Draft February 14, 2011 4 Updates: 1311, 2026 5 (if approved) 6 Intended status: BCP 7 Expires: August 18, 2011 9 STD Numbers and the IETF Standards Track 10 draft-klensin-std-numbers-01 12 Abstract 14 STD numbers are assigned to IETF Standards Track specifications in 15 order to provide a stable reference even when RFCs are revised and 16 the underlying documents change. However, the numbers are only 17 assigned when the specifications reach Full Standard maturity level, 18 significantly reducing their utility in the contemporary world in 19 which few specifications advance beyond the first standardization 20 maturity level. For that reason, one recent proposal suggested 21 eliminating the numbers entirely. This document argues that stable 22 references for Standards Track specifications are actually useful and 23 that the solution is not to abolish the numbers but to change the 24 point at which they are assigned. 26 Status of this Memo 28 This Internet-Draft is submitted in full conformance with the 29 provisions of BCP 78 and BCP 79. 31 Internet-Drafts are working documents of the Internet Engineering 32 Task Force (IETF). Note that other groups may also distribute 33 working documents as Internet-Drafts. The list of current Internet- 34 Drafts is at http://datatracker.ietf.org/drafts/current/. 36 Internet-Drafts are draft documents valid for a maximum of six months 37 and may be updated, replaced, or obsoleted by other documents at any 38 time. It is inappropriate to use Internet-Drafts as reference 39 material or to cite them other than as "work in progress." 41 This Internet-Draft will expire on August 18, 2011. 43 Copyright Notice 45 Copyright (c) 2011 IETF Trust and the persons identified as the 46 document authors. All rights reserved. 48 This document is subject to BCP 78 and the IETF Trust's Legal 49 Provisions Relating to IETF Documents 50 (http://trustee.ietf.org/license-info) in effect on the date of 51 publication of this document. Please review these documents 52 carefully, as they describe your rights and restrictions with respect 53 to this document. Code Components extracted from this document must 54 include Simplified BSD License text as described in Section 4.e of 55 the Trust Legal Provisions and are provided without warranty as 56 described in the Simplified BSD License. 58 Table of Contents 60 1. Introduction and Rationale . . . . . . . . . . . . . . . . . . 3 61 2. Proposal . . . . . . . . . . . . . . . . . . . . . . . . . . . 3 62 2.1. Changes to RFC 2026 . . . . . . . . . . . . . . . . . . . . 3 63 2.2. RFC 1311 Changes . . . . . . . . . . . . . . . . . . . . . 4 64 3. Transition . . . . . . . . . . . . . . . . . . . . . . . . . . 4 65 4. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 5 66 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 5 67 6. Security Considerations . . . . . . . . . . . . . . . . . . . . 5 68 7. References . . . . . . . . . . . . . . . . . . . . . . . . . . 5 69 7.1. Normative References . . . . . . . . . . . . . . . . . . . 5 70 7.2. Informative References . . . . . . . . . . . . . . . . . . 6 71 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 6 73 1. Introduction and Rationale 75 STD numbers [1] are assigned to IETF Standards Track specifications 76 in order to provide a stable reference even when RFCs are revised and 77 the underlying documents change. However, as specified in BCP 9 [1], 78 the numbers are only assigned when the specifications reach Full 79 Standard maturity level, significantly reducing their utility in the 80 contemporary world in which few specifications advance beyond the 81 first ("Proposed") standardization level. For that reason, an early 82 version of one recent proposal [2] suggested eliminating the numbers 83 entirely. The more recent version leaves the question open, but 84 poses the question as a choice between elimination of the STD numbers 85 and retaining the current system. 87 This document argues that stable references for Standards Track 88 specifications are actually useful and that the solution is neither 89 to abolish the numbers nor to retain the assignment only to Full 90 Standards specified in RFC 2026, but to change the point at which 91 they are assigned. 93 We note that similar stable references have proven to be very useful 94 in the BCP case and might be even more useful if better supported by 95 available tools (there are no provisions in xml2rfc (RFC 2629 et seq. 96 [3]) for easily constructing references to multiple-document BCPs or 97 STDs, nor does the current RFC Style Manual provide guidance as to 98 how such references should be laid out). 100 Note in Draft: The author strongly prefers a more comprehensive 101 solution to current perceived problems with maturity levels and STD 102 numbers, a solution such as that described in [4], but it seems 103 useful to get a narrowly-scoped proposal about STD numbers on the 104 table at this time. 106 2. Proposal 108 2.1. Changes to RFC 2026 110 Update RFC 2026, BCP 9, as follows: 112 Section 2.1, paragraph 5 113 Change: "Some RFCs document Internet Standards" 114 To: "Some RFCs document IETF Standards at various maturity 115 lavels". 117 Change the note: "(see section 4.1.3)" 118 To: "(see Section 4)" 120 Section 4 Add a new paragraph after the first paragraph of this 121 section ("Specifications that are intended to become...") that 122 reads: 124 A specification that reaches the status of Proposed Standard is 125 assigned a number in the STD series. It retains that STD number 126 as it progresses along the Standards Track (that progression 127 usually involves a change in RFC numbers). The STD number is also 128 retained when the relevant protocol is updated or replaced for 129 other reasons (see [5]). 131 Section 4.1.3 Remove the second paragraph, which begins "A 132 specification that reaches..." 134 2.2. RFC 1311 Changes 136 Informally, this document also updates the Informational RFC 1311 to 137 make it refer to all Standards Track documents. It may be useful to 138 replace RFC 1311 at some point, but that should not be a high- 139 priority task, nor should it block approval of the change suggested 140 in this document. 142 3. Transition 144 STD numbers are useful for documentation and other references. 145 Whether they are assigned or not does not change the actual status of 146 any given document. STD numbers have historically been assigned by 147 the RFC Editor and this document does not propose to change that 148 responsibility (even though, in the current multi-stream model for 149 RFCs, having them assigned by the Secretariat under IESG supervision 150 might make more sense). In the interest of avoiding both heavyweight 151 processes and the need for a period of concentrated effort, STD 152 numbers will be assigned only when: 154 1. A new Standards Track specification is published, at any maturity 155 level. 157 2. An update or replacement is published for a Standards track 158 specification for which an STD number has not already been 159 assigned, specifically including changes or grade or recycling in 160 grade. Authors, WGs, or ADs responsible for such specifications 161 are strongly encouraged to supply the RFC Editor with any desired 162 grouping information, i.e., the identification of specifications 163 that should also be assigned the same STD number. 165 3. On the request of any Area Director who concludes that assignment 166 of an STD number to a particular specification or group of 167 specifications would facilitate documentation, understanding of 168 the specification, or other uses. Especially when the number is 169 to be assigned to a group of specifications, Area Directors are 170 encouraged to seek community input on the decisions being made, 171 but neither such input nor a more formal Last Call are required 172 by this document. 174 This transition approach explicitly recognizes the principle that STD 175 numbers that would not be used need not be assigned and that not 176 assigning them does no harm. It prefers a "when approved" approach 177 for new specification and a "just in time" one for existing 178 specifications. 180 4. Acknowledgements 182 This document is an intellectual descendant of a NEWTRK WG 183 specification called "Identifying Standards Track Documents" [6]. It 184 differs from that specification largely by suggesting an even 185 lighter-weight transition process. The present work would not have 186 been possible without those earlier discussions. 188 5. IANA Considerations 190 [[Comment.1: RFC Editor: Please remove this section before 191 publication.]] 193 This memo includes no requests to or actions for IANA. 195 6. Security Considerations 197 This document affects an IETF administrative procedure and has no 198 direct effect on the Security of the Internet. However, better use 199 of stable identifiers for Standards Track document and related groups 200 of such documents may make critical information easier to find. 201 That, may, in turn, have positive security implications. 203 7. References 205 7.1. Normative References 207 [1] Bradner, S., "The Internet Standards Process -- Revision 3", 208 BCP 9, RFC 2026, October 1996. 210 7.2. Informative References 212 [2] Housley, R., Crocker, D., and E. Burger, "Reducing the Standards 213 Track to Two Maturity Levels", January 2011, . 216 [3] Rose, M., "Writing I-Ds and RFCs using XML", RFC 2629, 217 June 1999. 219 [4] Klensin, J., "Internet Standards Documentation (ISDs) and 220 Maturity Levels", July 2010, 221 . 223 [5] Postel, J., "Introduction to the STD Notes", RFC 1311, 224 March 1992. 226 [6] Klensin, J., "Identifying Standards Track Documents", 227 February 2006, 228 . 230 Author's Address 232 John C Klensin 233 1770 Massachusetts Ave, Ste 322 234 Cambridge, MA 02140 235 USA 237 Phone: +1 617 245 1457 238 Email: john+ietf@jck.com