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

Versions: 00 01 02                                                      
Network Working Group                                         J. Klensin
Internet-Draft                                           August 15, 2010
Updates: 1311, 2026
(if approved)
Intended status: BCP
Expires: February 16, 2011


                STD Numbers and the IETF Standards Track
                   draft-klensin-std-numbers-00.txt

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 to Full, or even Draft, Standard.
   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 February 16, 2011.

Copyright Notice

   Copyright (c) 2010 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 February 16, 2011               [Page 1]


Internet-Draft                 STD Numbers                   August 2010


   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 February 16, 2011               [Page 2]


Internet-Draft                 STD Numbers                   August 2010


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, 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 to Full, or even Draft, Standard.
   For that reason, one recent proposal [2] 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.

   During the discussion of the document that proposed to eliminate
   these numbers [2] at IETF 78, there appeared to be little support for
   keeping STD numbers in their current form (assigned only to Full
   Standards).  There was no discussion of assigning them earlier
   because that option was not listed in the subject I-D.  That may have
   been a serious omission since 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 RFC documents IETF Standards at various maturity
      lavels".

      Change the note: "(see section 4.1.3)"
      To: "(see Section 4)"





Klensin                 Expires February 16, 2011               [Page 3]


Internet-Draft                 STD Numbers                   August 2010


   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 February 16, 2011               [Page 4]


Internet-Draft                 STD Numbers                   August 2010


       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 "just in time" approach
   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 February 16, 2011               [Page 5]


Internet-Draft                 STD Numbers                   August 2010


7.2.  Informative References

   [2]  Housley, R., "Reducing the Standards Track to Two Maturity
        Levels", June 2010, <https://datatracker.ietf.org/doc/
        draft-housley-two-maturity-levels/>.

   [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,
        <https://datatracker.ietf.org/doc/draft-klensin-isdbis/>.

   [5]  Postel, J., "Introduction to the STD Notes", RFC 1311,
        March 1992.

   [6]  Klensin, J., "Identifying Standards Track Documents",
        February 2006,
        <https://datatracker.ietf.org/doc/draft-ietf-newtrk-docid/>.


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 February 16, 2011               [Page 6]