Network Working Group J. Klensin
Internet-Draft February 14, 2011
Updates: 1311, 2026
(if approved)
Intended status: BCP
Expires: August 18, 2011
STD Numbers and the IETF Standards Track
draft-klensin-std-numbers-01
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 http://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 August 18, 2011.
Copyright Notice
Copyright (c) 2011 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
Klensin Expires August 18, 2011 [Page 1]
Internet-Draft STD Numbers February 2011
Provisions Relating to IETF Documents
(http://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 . . . . . . . . . . . . . . . . . . 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
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 6
Klensin Expires August 18, 2011 [Page 2]
Internet-Draft STD Numbers February 2011
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 [2] suggested eliminating the numbers
entirely. The more recent version 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 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 [4], 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)"
Klensin Expires August 18, 2011 [Page 3]
Internet-Draft STD Numbers February 2011
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 [5]).
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
Klensin Expires August 18, 2011 [Page 4]
Internet-Draft STD Numbers February 2011
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" [6]. 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
[[Comment.1: 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, October 1996.
Klensin Expires August 18, 2011 [Page 5]
Internet-Draft STD Numbers February 2011
7.2. Informative References
[2] Housley, R., Crocker, D., and E. Burger, "Reducing the Standards
Track to Two Maturity Levels", January 2011, .
[3] Rose, M., "Writing I-Ds and RFCs using XML", RFC 2629,
June 1999.
[4] Klensin, J., "Internet Standards Documentation (ISDs) and
Maturity Levels", July 2010,
.
[5] Postel, J., "Introduction to the STD Notes", RFC 1311,
March 1992.
[6] Klensin, J., "Identifying Standards Track Documents",
February 2006,
.
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 August 18, 2011 [Page 6]