Network Working Group J. Klensin Internet-Draft July 1, 2018 Updates: 1311, 2026 (if approved) Intended status: Best Current Practice Expires: January 2, 2019 STD Numbers and the IETF Standards Track draft-klensin-std-numbers-02 Abstract STD numbers are assigned to IETF Standards Track specifications in order to provide a stable reference even when RFCs are revised and the underlying documents change. However, the numbers are only assigned when the specifications reach Full Standard maturity level, significantly reducing their utility in the contemporary world in which few specifications advance beyond the first standardization maturity level. For that reason, one recent proposal suggested eliminating the numbers entirely. This document argues that stable references for Standards Track specifications are actually useful and that the solution is not to abolish the numbers but to change the point at which they are assigned. Status of This Memo This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet- Drafts is at https://datatracker.ietf.org/drafts/current/. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." This Internet-Draft will expire on January 2, 2019. Copyright Notice Copyright (c) 2018 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents Klensin Expires January 2, 2019 [Page 1] Internet-Draft STD Numbers July 2018 (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. Table of Contents 1. Introduction and Rationale . . . . . . . . . . . . . . . . . 2 2. Proposal . . . . . . . . . . . . . . . . . . . . . . . . . . 3 2.1. Changes to RFC 2026 . . . . . . . . . . . . . . . . . . . 3 2.2. RFC 1311 Changes . . . . . . . . . . . . . . . . . . . . 4 3. Transition . . . . . . . . . . . . . . . . . . . . . . . . . 4 4. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 5 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 5 6. Security Considerations . . . . . . . . . . . . . . . . . . . 5 7. References . . . . . . . . . . . . . . . . . . . . . . . . . 5 7.1. Normative References . . . . . . . . . . . . . . . . . . 5 7.2. Informative References . . . . . . . . . . . . . . . . . 5 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 6 1. Introduction and Rationale Note in Draft: With the exception of date, file name info, updated references, and this paragraph, this version of this I-D is identical to the one posted on 14 February 2011. In particular, to discussion of XML2RFC capabilities has not been updated to reflect new XML2RFC definitions and tools and terms like "recent" may need to be interpreted in the 2011 context. It is provided for the convenience of the "RFCplusplus" BOF at IETF 102 in support of the hypothesis that, if a set of new numbering series are a solution to the perceived problem, then overlaying those numbers on the archival RFC numbers is likely to be a more realistic experiment than the one outlined in the bOF proposal. STD numbers [1] are assigned to IETF Standards Track specifications in order to provide a stable reference even when RFCs are revised and the underlying documents change. However, as specified in BCP 9 [1], the numbers are only assigned when the specifications reach Full Standard maturity level, significantly reducing their utility in the contemporary world in which few specifications advance beyond the first ("Proposed") standardization level. For that reason, an early version of one recent proposal suggested eliminating the numbers entirely. The more recent version, approved and published as RFC 6410 [5], leaves the question open, but poses the question as a Klensin Expires January 2, 2019 [Page 2] Internet-Draft STD Numbers July 2018 choice between elimination of the STD numbers and retaining the current system. This document argues that stable references for Standards Track specifications are actually useful and that the solution is neither to abolish the numbers nor to retain the assignment only to Full Standards specified in RFC 2026, but to change the point at which they are assigned. We note that similar stable references have proven to be very useful in the BCP case and might be even more useful if better supported by available tools (there are no provisions in xml2rfc (RFC 2629 et seq. [3]) for easily constructing references to multiple-document BCPs or STDs, nor does the current RFC Style Manual provide guidance as to how such references should be laid out). Note in Draft: The author strongly prefers a more comprehensive solution to current perceived problems with maturity levels and STD numbers, a solution such as that described in [6], but it seems useful to get a narrowly-scoped proposal about STD numbers on the table at this time. 2. Proposal 2.1. Changes to RFC 2026 Update RFC 2026, BCP 9, as follows: Section 2.1, paragraph 5 Change: "Some RFCs document Internet Standards" To: "Some RFCs document IETF Standards at various maturity lavels". Change the note: "(see section 4.1.3)" To: "(see Section 4)" Section 4 Add a new paragraph after the first paragraph of this section ("Specifications that are intended to become...") that reads: A specification that reaches the status of Proposed Standard is assigned a number in the STD series. It retains that STD number as it progresses along the Standards Track (that progression usually involves a change in RFC numbers). The STD number is also retained when the relevant protocol is updated or replaced for other reasons (see [2]). Klensin Expires January 2, 2019 [Page 3] Internet-Draft STD Numbers July 2018 Section 4.1.3 Remove the second paragraph, which begins "A specification that reaches..." 2.2. RFC 1311 Changes Informally, this document also updates the Informational RFC 1311 to make it refer to all Standards Track documents. It may be useful to replace RFC 1311 at some point, but that should not be a high- priority task, nor should it block approval of the change suggested in this document. 3. Transition STD numbers are useful for documentation and other references. Whether they are assigned or not does not change the actual status of any given document. STD numbers have historically been assigned by the RFC Editor and this document does not propose to change that responsibility (even though, in the current multi-stream model for RFCs, having them assigned by the Secretariat under IESG supervision might make more sense). In the interest of avoiding both heavyweight processes and the need for a period of concentrated effort, STD numbers will be assigned only when: 1. A new Standards Track specification is published, at any maturity level. 2. An update or replacement is published for a Standards track specification for which an STD number has not already been assigned, specifically including changes or grade or recycling in grade. Authors, WGs, or ADs responsible for such specifications are strongly encouraged to supply the RFC Editor with any desired grouping information, i.e., the identification of specifications that should also be assigned the same STD number. 3. On the request of any Area Director who concludes that assignment of an STD number to a particular specification or group of specifications would facilitate documentation, understanding of the specification, or other uses. Especially when the number is to be assigned to a group of specifications, Area Directors are encouraged to seek community input on the decisions being made, but neither such input nor a more formal Last Call are required by this document. This transition approach explicitly recognizes the principle that STD numbers that would not be used need not be assigned and that not assigning them does no harm. It prefers a "when approved" approach for new specification and a "just in time" one for existing specifications. Klensin Expires January 2, 2019 [Page 4] Internet-Draft STD Numbers July 2018 4. Acknowledgements This document is an intellectual descendant of a NEWTRK WG specification called "Identifying Standards Track Documents" [4]. It differs from that specification largely by suggesting an even lighter-weight transition process. The present work would not have been possible without those earlier discussions. 5. IANA Considerations [[CREF1: RFC Editor: Please remove this section before publication.]] This memo includes no requests to or actions for IANA. 6. Security Considerations This document affects an IETF administrative procedure and has no direct effect on the Security of the Internet. However, better use of stable identifiers for Standards Track document and related groups of such documents may make critical information easier to find. That, may, in turn, have positive security implications. 7. References 7.1. Normative References [1] Bradner, S., "The Internet Standards Process -- Revision 3", BCP 9, RFC 2026, DOI 10.17487/RFC2026, October 1996, . 7.2. Informative References [2] Postel, J., "Introduction to the STD Notes", RFC 1311, DOI 10.17487/RFC1311, March 1992, . [3] Rose, M., "Writing I-Ds and RFCs using XML", RFC 2629, DOI 10.17487/RFC2629, June 1999, . [4] Klensin, J., "Identifying Standards Track Documents", February 2006, . [5] Housley, R., Crocker, D., and E. Burger, "Reducing the Standards Track to Two Maturity Levels", BCP 9, RFC 6410, DOI 10.17487/RFC6410, October 2011, . Klensin Expires January 2, 2019 [Page 5] Internet-Draft STD Numbers July 2018 [6] Klensin, J., "Internet Standards Documentation (ISDs) and Maturity Levels", July 2010, . Author's Address John C Klensin 1770 Massachusetts Ave, Ste 322 Cambridge, MA 02140 USA Phone: +1 617 245 1457 Email: john-ietf@jck.com Klensin Expires January 2, 2019 [Page 6]