idnits 2.17.1 draft-klensin-std-numbers-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: ---------------------------------------------------------------------------- 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. -- The draft header indicates that this document updates RFC2026, 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 (July 1, 2018) is 2126 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 (==), 5 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group J. Klensin 3 Internet-Draft July 1, 2018 4 Updates: 1311, 2026 (if approved) 5 Intended status: Best Current Practice 6 Expires: January 2, 2019 8 STD Numbers and the IETF Standards Track 9 draft-klensin-std-numbers-02 11 Abstract 13 STD numbers are assigned to IETF Standards Track specifications in 14 order to provide a stable reference even when RFCs are revised and 15 the underlying documents change. However, the numbers are only 16 assigned when the specifications reach Full Standard maturity level, 17 significantly reducing their utility in the contemporary world in 18 which few specifications advance beyond the first standardization 19 maturity level. For that reason, one recent proposal suggested 20 eliminating the numbers entirely. This document argues that stable 21 references for Standards Track specifications are actually useful and 22 that the solution is not to abolish the numbers but to change the 23 point at which they are assigned. 25 Status of This Memo 27 This Internet-Draft is submitted in full conformance with the 28 provisions of BCP 78 and BCP 79. 30 Internet-Drafts are working documents of the Internet Engineering 31 Task Force (IETF). Note that other groups may also distribute 32 working documents as Internet-Drafts. The list of current Internet- 33 Drafts is at https://datatracker.ietf.org/drafts/current/. 35 Internet-Drafts are draft documents valid for a maximum of six months 36 and may be updated, replaced, or obsoleted by other documents at any 37 time. It is inappropriate to use Internet-Drafts as reference 38 material or to cite them other than as "work in progress." 40 This Internet-Draft will expire on January 2, 2019. 42 Copyright Notice 44 Copyright (c) 2018 IETF Trust and the persons identified as the 45 document authors. All rights reserved. 47 This document is subject to BCP 78 and the IETF Trust's Legal 48 Provisions Relating to IETF Documents 49 (https://trustee.ietf.org/license-info) in effect on the date of 50 publication of this document. Please review these documents 51 carefully, as they describe your rights and restrictions with respect 52 to this document. Code Components extracted from this document must 53 include Simplified BSD License text as described in Section 4.e of 54 the Trust Legal Provisions and are provided without warranty as 55 described in the Simplified BSD License. 57 Table of Contents 59 1. Introduction and Rationale . . . . . . . . . . . . . . . . . 2 60 2. Proposal . . . . . . . . . . . . . . . . . . . . . . . . . . 3 61 2.1. Changes to RFC 2026 . . . . . . . . . . . . . . . . . . . 3 62 2.2. RFC 1311 Changes . . . . . . . . . . . . . . . . . . . . 4 63 3. Transition . . . . . . . . . . . . . . . . . . . . . . . . . 4 64 4. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 5 65 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 5 66 6. Security Considerations . . . . . . . . . . . . . . . . . . . 5 67 7. References . . . . . . . . . . . . . . . . . . . . . . . . . 5 68 7.1. Normative References . . . . . . . . . . . . . . . . . . 5 69 7.2. Informative References . . . . . . . . . . . . . . . . . 5 70 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 6 72 1. Introduction and Rationale 74 Note in Draft: With the exception of date, file name info, updated 75 references, and this paragraph, this version of this I-D is identical 76 to the one posted on 14 February 2011. In particular, to discussion 77 of XML2RFC capabilities has not been updated to reflect new XML2RFC 78 definitions and tools and terms like "recent" may need to be 79 interpreted in the 2011 context. It is provided for the convenience 80 of the "RFCplusplus" BOF at IETF 102 in support of the hypothesis 81 that, if a set of new numbering series are a solution to the 82 perceived problem, then overlaying those numbers on the archival RFC 83 numbers is likely to be a more realistic experiment than the one 84 outlined in the bOF proposal. 86 STD numbers [1] are assigned to IETF Standards Track specifications 87 in order to provide a stable reference even when RFCs are revised and 88 the underlying documents change. However, as specified in BCP 9 [1], 89 the numbers are only assigned when the specifications reach Full 90 Standard maturity level, significantly reducing their utility in the 91 contemporary world in which few specifications advance beyond the 92 first ("Proposed") standardization level. For that reason, an early 93 version of one recent proposal suggested eliminating the numbers 94 entirely. The more recent version, approved and published as RFC 95 6410 [5], leaves the question open, but poses the question as a 96 choice between elimination of the STD numbers and retaining the 97 current system. 99 This document argues that stable references for Standards Track 100 specifications are actually useful and that the solution is neither 101 to abolish the numbers nor to retain the assignment only to Full 102 Standards specified in RFC 2026, but to change the point at which 103 they are assigned. 105 We note that similar stable references have proven to be very useful 106 in the BCP case and might be even more useful if better supported by 107 available tools (there are no provisions in xml2rfc (RFC 2629 et seq. 108 [3]) for easily constructing references to multiple-document BCPs or 109 STDs, nor does the current RFC Style Manual provide guidance as to 110 how such references should be laid out). 112 Note in Draft: The author strongly prefers a more comprehensive 113 solution to current perceived problems with maturity levels and STD 114 numbers, a solution such as that described in [6], but it seems 115 useful to get a narrowly-scoped proposal about STD numbers on the 116 table at this time. 118 2. Proposal 120 2.1. Changes to RFC 2026 122 Update RFC 2026, BCP 9, as follows: 124 Section 2.1, paragraph 5 125 Change: "Some RFCs document Internet Standards" 126 To: "Some RFCs document IETF Standards at various maturity 127 lavels". 129 Change the note: "(see section 4.1.3)" 130 To: "(see Section 4)" 132 Section 4 Add a new paragraph after the first paragraph of this 133 section ("Specifications that are intended to become...") that 134 reads: 136 A specification that reaches the status of Proposed Standard is 137 assigned a number in the STD series. It retains that STD number 138 as it progresses along the Standards Track (that progression 139 usually involves a change in RFC numbers). The STD number is also 140 retained when the relevant protocol is updated or replaced for 141 other reasons (see [2]). 143 Section 4.1.3 Remove the second paragraph, which begins "A 144 specification that reaches..." 146 2.2. RFC 1311 Changes 148 Informally, this document also updates the Informational RFC 1311 to 149 make it refer to all Standards Track documents. It may be useful to 150 replace RFC 1311 at some point, but that should not be a high- 151 priority task, nor should it block approval of the change suggested 152 in this document. 154 3. Transition 156 STD numbers are useful for documentation and other references. 157 Whether they are assigned or not does not change the actual status of 158 any given document. STD numbers have historically been assigned by 159 the RFC Editor and this document does not propose to change that 160 responsibility (even though, in the current multi-stream model for 161 RFCs, having them assigned by the Secretariat under IESG supervision 162 might make more sense). In the interest of avoiding both heavyweight 163 processes and the need for a period of concentrated effort, STD 164 numbers will be assigned only when: 166 1. A new Standards Track specification is published, at any maturity 167 level. 169 2. An update or replacement is published for a Standards track 170 specification for which an STD number has not already been 171 assigned, specifically including changes or grade or recycling in 172 grade. Authors, WGs, or ADs responsible for such specifications 173 are strongly encouraged to supply the RFC Editor with any desired 174 grouping information, i.e., the identification of specifications 175 that should also be assigned the same STD number. 177 3. On the request of any Area Director who concludes that assignment 178 of an STD number to a particular specification or group of 179 specifications would facilitate documentation, understanding of 180 the specification, or other uses. Especially when the number is 181 to be assigned to a group of specifications, Area Directors are 182 encouraged to seek community input on the decisions being made, 183 but neither such input nor a more formal Last Call are required 184 by this document. 186 This transition approach explicitly recognizes the principle that STD 187 numbers that would not be used need not be assigned and that not 188 assigning them does no harm. It prefers a "when approved" approach 189 for new specification and a "just in time" one for existing 190 specifications. 192 4. Acknowledgements 194 This document is an intellectual descendant of a NEWTRK WG 195 specification called "Identifying Standards Track Documents" [4]. It 196 differs from that specification largely by suggesting an even 197 lighter-weight transition process. The present work would not have 198 been possible without those earlier discussions. 200 5. IANA Considerations 202 [[CREF1: RFC Editor: Please remove this section before publication.]] 204 This memo includes no requests to or actions for IANA. 206 6. Security Considerations 208 This document affects an IETF administrative procedure and has no 209 direct effect on the Security of the Internet. However, better use 210 of stable identifiers for Standards Track document and related groups 211 of such documents may make critical information easier to find. 212 That, may, in turn, have positive security implications. 214 7. References 216 7.1. Normative References 218 [1] Bradner, S., "The Internet Standards Process -- Revision 219 3", BCP 9, RFC 2026, DOI 10.17487/RFC2026, October 1996, 220 . 222 7.2. Informative References 224 [2] Postel, J., "Introduction to the STD Notes", RFC 1311, 225 DOI 10.17487/RFC1311, March 1992, 226 . 228 [3] Rose, M., "Writing I-Ds and RFCs using XML", RFC 2629, 229 DOI 10.17487/RFC2629, June 1999, 230 . 232 [4] Klensin, J., "Identifying Standards Track Documents", 233 February 2006, . 236 [5] Housley, R., Crocker, D., and E. Burger, "Reducing the 237 Standards Track to Two Maturity Levels", BCP 9, RFC 6410, 238 DOI 10.17487/RFC6410, October 2011, 239 . 241 [6] Klensin, J., "Internet Standards Documentation (ISDs) and 242 Maturity Levels", July 2010, 243 . 245 Author's Address 247 John C Klensin 248 1770 Massachusetts Ave, Ste 322 249 Cambridge, MA 02140 250 USA 252 Phone: +1 617 245 1457 253 Email: john-ietf@jck.com