[Search] [txt|pdf|bibtex] [Tracker] [WG] [Email] [Nits]

Versions: 00                                                            
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]