Network Working Group J. Klensin
Internet-Draft February 23, 2006
Expires: August 27, 2006
Identifying Standards Track Documents
draft-ietf-newtrk-docid-00.txt
Status of this Memo
By submitting this Internet-Draft, each author represents that any
applicable patent or other IPR claims of which he or she is aware
have been or will be disclosed, and any of which he or she becomes
aware will be disclosed, in accordance with Section 6 of BCP 79.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as Internet-
Drafts.
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."
The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html.
This Internet-Draft will expire on August 27, 2006.
Copyright Notice
Copyright (C) The Internet Society (2006).
Abstract
In the present Internet Standards Process, stable identifiers for
standards, as distinct from documents (for which RFC numbers are
sufficient), has become problematic because proportionately few
documents reach Full Standard and are assigned STD numbers. Several
proposals have been introduced into NEWTRK to address this problem,
but only in the context of trying to resolve a number of other
issues. In the hope of making some progress on this dimension, this
document proposes a change to the standards-track document identifier
system only.
Klensin Expires August 27, 2006 [Page 1]
Internet-Draft Standards Track IDs February 2006
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. A Different STD Model . . . . . . . . . . . . . . . . . . . . . 3
2.1. Assignment of Standards Identifiers . . . . . . . . . . . . 3
2.2. Format of a Standards Identifier . . . . . . . . . . . . . 4
2.3. Category-qualifiers . . . . . . . . . . . . . . . . . . . . 4
2.3.1. Proposed Standard, identifier: "ps" . . . . . . . . . . 4
2.3.2. Draft Standard, identifier: "ds" . . . . . . . . . . . 4
2.3.3. Internet Standard, identifier: "is" . . . . . . . . . . 4
2.3.4. Working Draft, identifier: "wd" . . . . . . . . . . . . 5
2.3.5. Updating and Obsoleting . . . . . . . . . . . . . . . . 5
3. Transition . . . . . . . . . . . . . . . . . . . . . . . . . . 5
4. Security Considerations . . . . . . . . . . . . . . . . . . . . 6
5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 6
6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 6
7. References . . . . . . . . . . . . . . . . . . . . . . . . . . 7
7.1. Normative References . . . . . . . . . . . . . . . . . . . 7
7.2. Informative References . . . . . . . . . . . . . . . . . . 7
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 8
Intellectual Property and Copyright Statements . . . . . . . . . . 9
Klensin Expires August 27, 2006 [Page 2]
Internet-Draft Standards Track IDs February 2006
1. Introduction
In the present Internet Standards Process, stable identifiers for
standards, as distinct from documents (for which RFC numbers are
sufficient), has become problematic because proportionately few
documents reach Full Standard and are assigned STD numbers. Several
proposals have been introduced into NEWTRK to address this issue
(e.g., [ISD-Proposal], [SRD-Proposal], but only in the context of
trying to resolve a number of other problems.
The current practice in the IETF, as specified in [RFC2026] is to
assign two identifiers to a standards-track specification. The first
of these is an RFC number that identifies the document itself, the
section is an STD number that identifies the standard. However, STD
numbers are assigned only to (full) Internet Standards. Few
specifications reach that level, leaving something of a gap for
stable references, especially those needed by other bodies. This
document proposes to slightly alter the STD designation to reduce or
eliminate this problem.
2. A Different STD Model
In the current (RFC 2026) model, STD numbers are assigned only when a
specification reaches Internet Standard. Independent of the many
concerns that have been expressed about how few documents reach that
stage and efforts to change the number of definitions of the stages,
this late assignment makes specifications hard to reference and track
through the standards process. This document proposes to assign them
much earlier, to qualify the numbers, and to place the assignments
completely under IESG control.
As with RFC numbers, the numerical portion of Standards Identifiers
are never reused. If a Standard is retired, so it its number.
2.1. Assignment of Standards Identifiers
Standards Identifiers will be assigned by the IETF Secretariat, under
IESG supervision, no later than the time a specification is approved
by the IESG as a Proposed Standard. The Identifier will be included
in the Protocol Action announcement.
At its discretion when circumstances seem to justify it, the IESG may
cause a Standards Identifier to assigned to an evolving document that
has not yet achieved community consensus. This would most commonly
be done when a stable identifier was needed during the review and
approval process that would carry forward to the Standard.
Klensin Expires August 27, 2006 [Page 3]
Internet-Draft Standards Track IDs February 2006
2.2. Format of a Standards Identifier
A Standards Identifier will consist of a short alphabetic code to
distinguish it from other types of identifiers, a number to identify
a particular standard, and an alphabetic category-qualifier (see the
next subsection). The current alphabetic code is "STD". This
document is agnostic on whether that code should be retained or a new
one developed and used. (See Section 3, below.
2.3. Category-qualifiers
Each Standards Identifier will contain a category qualifier that
indicates its level of maturity and community consensus. To the
extent feasible, the IETF will discourage the use of Standards
Identifiers without the category qualifier. The IETF should develop
and maintain a document that explains the category qualifiers and
provides any desired disclaimers, boilerplate, and other handwaving.
The initial version of that document will consist of the explanation
below for the pre-consensus Category Identifier and the cited
sections of RFC 2026 for the other ones. The document will be
included, either in whole or by reference, in indexes or lists of
standards as the community considers appropriate with the IESG making
the final determination. The categories and category identifiers are
as follows. [[anchor5: Note in Draft: Someone else can probably come
up with a better set of codes or symbols. Suggestions welcome.]]
2.3.1. Proposed Standard, identifier: "ps"
Until a better writeup, and appropriate disclaimers and warnings, are
produced and approved according to the usual process for procedural
materials, the explanation for this category will be textually
identical to Section 4.1.1 of RFC 2026.
2.3.2. Draft Standard, identifier: "ds"
Until a better writeup, and appropriate disclaimers and warnings, are
produced and approved according to the usual process for procedural
materials, the explanation for this category will be textually
identical to Section 4.1.2 of RFC 2026.
2.3.3. Internet Standard, identifier: "is"
Until a better writeup, and appropriate disclaimers and warnings
(presumably few in this case other than "Standardization does not
imply a recommendation about appropriateness for any purpose"), are
produced and approved according to the usual process for procedural
materials, the explanation for this category will be textually
identical to Section 4.1.3 of RFC 2026.
Klensin Expires August 27, 2006 [Page 4]
Internet-Draft Standards Track IDs February 2006
2.3.4. Working Draft, identifier: "wd"
This Category Identifier is reserved for Internet Drafts that have
not achieved community consensus but for which the IESG concludes
that a stable identifier should be assigned, as above. Such
identifiers must not be issued and hence this Category Identifier
must not be used, until an appropriate disclaimer paragraph is
developed by the community, reviewed by IETF Counsel, and rough
consensus about its text achieved. [[anchor10: Note in draft: Given
many discussions, it seems reasonable to provide for this category
and option. Its presence in this proposal is not a recommendation
for its use.]]
2.3.4.1. Historical Standard: "hs"
This Category Identifier is reserved for specifications that were
previously assigned Standards Identifiers but that have been changed,
by community consensus to "Historic" or formally designated as "Not
Recommended".
2.3.5. Updating and Obsoleting
If a specification at a given level is replaced by another
specification at the same or a higher level, the Standards Identifier
is moved to point to the newer document rather than the older one and
the Category Identifier adjusted as needed. In this case, the older
document will no longer have a Standards Identifier.
If a specification is produced whose intention is to replace a
specification at a higher level, the Standards Identifier number will
be associated with both specifications, using different Category
Identifiers as appropriate.
3. Transition
1. If the STD prefix is retained, the first stage of implementation
of this proposal is to assign the Category Identifier of "is" to
all existing STD numbers as they appear in indexes and other
accessible locations. If it is not, a new prefix and, at the
discretion of the IESG, a new number sequence, should be assigned
to all existing Internet Standards.
2. For existing documents in "Proposed Standard" or "Draft Standard"
categories, the RFC Editor, who have experience in assigning STD
numbers, should assign numbers and Category Identifiers to all
relevant documents. By mutual consent, the RFC Editor may be
advised in this role by one or more individuals designated by the
IAB or IESG. Where there are questions as to whether two
Klensin Expires August 27, 2006 [Page 5]
Internet-Draft Standards Track IDs February 2006
documents should be assigned the same Standard Identifier number
or whether they should be assigned different numbers, separate
numbers should be assigned to favor efficiency over extended
debate. [[anchor13: Note in Draft: We could make this as
complicated as we like, but I suggest that doing it quickly and
in a way that is no worse than current practice is the right
balance.]]
3. When new specifications are processed, the IESG will decide what
Standards Identifiers will be associated to them, including
whether to use an existing identifier or assign a new one as part
of the standards-approval process. Working Groups or other
proposers of standards-track documents should make
recommendations for action to the IESG.
4. Security Considerations
This document addresses IETF procedures and hence does not raise new
security issues of its own.
5. IANA Considerations
This document does not imply or require any actions from IANA.
[[anchor16: RFC Editor: This section should be removed on
publication.]]
6. Acknowledgements
The production of this document was inspired by a combination of
NEWTRK discussions and a series of suggestions by Stephen Hayes and
others about early adoption of stable identifiers. The
identification system is loosely based on the system used by ISO/IEC
JTC1. In their model, numbers are assigned to prospective standards
at the time they are formally accepted as "Committee Drafts". The
numbers are preserved through to adoption of International Standards,
but prefixed at each stage by a category identifier for categories
such as "Committee Draft" (CD), "Draft International Standard" (DIS),
and so on. ISO also uses a much finer-grained "stage" system [ISO-
Stages], but there does not seem to be a need to take the IETF into
that level of formality.
7. References
Klensin Expires August 27, 2006 [Page 6]
Internet-Draft Standards Track IDs February 2006
7.1. Normative References
[RFC2026] Bradner, S., "The Internet Standards Process -- Revision
3", BCP 9, RFC 2026, October 1996.
7.2. Informative References
[ISD-Proposal]
Klensin, J. and J. Loughney, "Internet Standards
Documentation (ISDs)", draft-newtrk-repurposing-isd-04
(work in progress), February 2005.
[ISO-Stages]
International Organization for Standardization,
"International harmonized stage codes", February 2006,
<http://www.iso.org/iso/en/widepages/stagetable.html>.
[SRD-Proposal]
Otis, D. and J. Leslie, "XML structure for Set of RFC
Descriptors", draft-otis-newtrk-rfc-set-02 (work in
progress), October 2005.
Klensin Expires August 27, 2006 [Page 7]
Internet-Draft Standards Track IDs February 2006
Author's Address
John C Klensin
1770 Massachusetts Ave, #322
Cambridge, MA 02140
USA
Phone: +1 617 491 5735
Email: john-ietf@jck.com
Klensin Expires August 27, 2006 [Page 8]
Internet-Draft Standards Track IDs February 2006
Intellectual Property Statement
The IETF takes no position regarding the validity or scope of any
Intellectual Property Rights or other rights that might be claimed to
pertain to the implementation or use of the technology described in
this document or the extent to which any license under such rights
might or might not be available; nor does it represent that it has
made any independent effort to identify any such rights. Information
on the procedures with respect to rights in RFC documents can be
found in BCP 78 and BCP 79.
Copies of IPR disclosures made to the IETF Secretariat and any
assurances of licenses to be made available, or the result of an
attempt made to obtain a general license or permission for the use of
such proprietary rights by implementers or users of this
specification can be obtained from the IETF on-line IPR repository at
http://www.ietf.org/ipr.
The IETF invites any interested party to bring to its attention any
copyrights, patents or patent applications, or other proprietary
rights that may cover technology that may be required to implement
this standard. Please address the information to the IETF at
ietf-ipr@ietf.org.
Disclaimer of Validity
This document and the information contained herein are provided on an
"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Copyright Statement
Copyright (C) The Internet Society (2006). This document is subject
to the rights, licenses and restrictions contained in BCP 78, and
except as set forth therein, the authors retain all their rights.
Acknowledgment
Funding for the RFC Editor function is currently provided by the
Internet Society.
Klensin Expires August 27, 2006 [Page 9]
