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