



Network Working Group                                       J.C. Klensin
Internet-Draft                                             18 March 2026
Updates: 1311, 2026 (if approved)                                       
Intended status: Best Current Practice                                  
Expires: 19 September 2026


                STD Numbers and the IETF Standards Track
                      draft-klensin-std-numbers-03

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 Internet 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 proposal, more than a decade
   ago, suggested eliminating the numbers entirely.  Others, including
   more recent ones, have suggested eliminating maturity levels
   entirely, in part as a way to solve the numbering problem.  This
   document argues that stable references for Standards Track
   specifications are actually useful and that the solution is not to
   abolish the numbers or maturity levels but to change the point at
   which they are assigned.

Note

   This note is to be removed before publishing as an RFC.

   With the exception of date, file name info, updated references, this
   note, a bit of (still incomplete) updating to reflect current
   conventions, and some reorganization to take advantage of RFCXMLv3
   norms, the current version of this document is substantially
   identical to draft-klensin-std-numbers-02, posted 1 July 2018.  If it
   is to go anywhere, it will need more cosmetic work.

   That 2018 version, in turn, was, with similar corrections for naming
   and I-D conventions, identical to draft-klensin-std-numbers-01,
   posted on 14 February 2011.  In particular, the discussions of
   XML2RFC (now RFCXML) capabilities has not been updated to reflect new
   definitions and tools and terms like "recent" may need to be
   interpreted in the 2011 context.  The draft is provided for the
   convenience of discussion during the "Gendispatch" BOF at IETF 124 in
   support of the hypothesis that, if the assignment of STD numbers only
   to Internet Standards is a problem, simply assigning those number to
   RFCs at lower maturity levels would be a far less painful process



Klensin                 Expires 19 September 2026               [Page 1]

Internet-Draft                 STD Numbers                    March 2026


   than eliminating the concept of maturity levels and everything that
   would require in terms of adjustments to tools, metadata,
   descriptions of the IETF process, and so on.

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 19 September 2026.

Copyright Notice

   Copyright (c) 2026 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 (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 Revised BSD License text as
   described in Section 4.e of the Trust Legal Provisions and are
   provided without warranty as described in the Revised BSD License.

Table of Contents

   1.  Introduction and Rationale  . . . . . . . . . . . . . . . . .   3
   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  . . . . . . . . . . . . . . . . .   6



Klensin                 Expires 19 September 2026               [Page 2]

Internet-Draft                 STD Numbers                    March 2026


   Author's Address  . . . . . . . . . . . . . . . . . . . . . . . .   6

1.  Introduction and Rationale

   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 [4], leaves the question open, but poses the question as a
   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 that changes to the RFCXML vocabulary [5] in
   recent years, such as the addition of the <referencegroup> element,
   facilitate references to documents that are part of a numbered set.

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:




Klensin                 Expires 19 September 2026               [Page 3]

Internet-Draft                 STD Numbers                    March 2026


      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]).

   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.

   2026 Note: If we believe that RFC 1311 has been adequately replaced
   by the current description of IETF processes and the RFC Series on
   IETF web pages, it may be appropriate to drop this subsection (and
   ask the IETF to declare 1311 as Historic) and/or to suggest an update
   to those web pages.

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 or RFC Production
   Center 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.



Klensin                 Expires 19 September 2026               [Page 4]

Internet-Draft                 STD Numbers                    March 2026


   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.

4.  Acknowledgements

   This document is an intellectual descendant of a NEWTRK WG
   specification called "Identifying Standards Track Documents" [3].  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.

   Posting of the current version was stimulated by an expected
   discussion of a document by Brian Carpenter titled "Some Anachronisms
   in IETF Standards Process Documents" during the GENDISPATCH session
   at IETF 124, a document that, once again, proposes elimination of
   maturity levels.

5.  IANA Considerations


   // 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




Klensin                 Expires 19 September 2026               [Page 5]

Internet-Draft                 STD Numbers                    March 2026


   [1]        Bradner, S., "The Internet Standards Process -- Revision
              3", BCP 9, RFC 2026, DOI 10.17487/RFC2026, October 1996,
              <https://www.rfc-editor.org/info/rfc2026>.

7.2.  Informative References

   [2]        Postel, J., "Introduction to the STD Notes", RFC 1311,
              DOI 10.17487/RFC1311, March 1992,
              <https://www.rfc-editor.org/info/rfc1311>.

   [3]        Klensin, J.C., "Identifying Standards Track Documents", 23
              February 2006, <https://datatracker.ietf.org/doc/draft-
              ietf-newtrk-docid/>.

   [4]        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,
              <https://www.rfc-editor.org/info/rfc6410>.

   [5]        IETF, "RFCXML vocabulary reference", March 2026,
              <https://authors.ietf.org/en/rfcxml-vocabulary>.

Author's Address

   John C Klensin
   1770 Massachusetts Ave, Ste 322
   Cambridge, MA 02140
   United States of America
   Email: john-ietf@jck.com






















Klensin                 Expires 19 September 2026               [Page 6]
