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, . [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]