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

Versions: 00                                                            
Network Working Group                                         J. Klensin
Internet-Draft                                              June 6, 2004
Expires: December 5, 2004

                    Repurposing the STD Designation

Status of this Memo

   By submitting this Internet-Draft, I certify that any applicable
   patent or other IPR claims of which I am aware have been disclosed,
   and any of which I become aware will be disclosed, in accordance with
   RFC 3668.

   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 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

   The list of Internet-Draft Shadow Directories can be accessed at

   This Internet-Draft will expire on December 5, 2004.

Copyright Notice

   Copyright (C) The Internet Society (2004).  All Rights Reserved.


   Over the years, it has been repeatedly observed that the STD nnnn and
   BCP nnnn designation for IETF Standards has not worked well, either
   as a stable reference for external specifications or as a combined
   reference for multiple documents that are linked together into a
   single specification.  This document proposes two changes that have
   been discussed on and off for some time, but never written up or
   considered as specific proposals.  The first of these would assign a
   STD (or BCP) number to a specification when it enters the first level
   of the Standards Track (or is first designated as a BCP).  The second
   would turn STDs and BCPs into actual documents that describe what

Klensin                 Expires December 5, 2004                [Page 1]

Internet-Draft      Repurposing the STD Designation            June 2004

   they identify and their publication and change history.

Table of Contents

   1.   Introduction . . . . . . . . . . . . . . . . . . . . . . . .   3
   2.   Proposal Overview  . . . . . . . . . . . . . . . . . . . . .   4
   3.   A New Document Series  . . . . . . . . . . . . . . . . . . .   5
   4.   Content and Organization of an STD Document  . . . . . . . .   6
   5.   Transition . . . . . . . . . . . . . . . . . . . . . . . . .   7
   6.   Operational Issues . . . . . . . . . . . . . . . . . . . . .   8
   7.   References to STDs or References to RFCs . . . . . . . . . .   9
   8.   IANA Considerations  . . . . . . . . . . . . . . . . . . . .   9
   9.   Security Considerations  . . . . . . . . . . . . . . . . . .   9
   10.  Acknowledgements . . . . . . . . . . . . . . . . . . . . . .   9
   11.  References . . . . . . . . . . . . . . . . . . . . . . . . .  10
   11.1   Normative References . . . . . . . . . . . . . . . . . . .  10
   11.2   Informative References . . . . . . . . . . . . . . . . . .  10
        Author's Address . . . . . . . . . . . . . . . . . . . . . .  10
        Intellectual Property and Copyright Statements . . . . . . .  11

Klensin                 Expires December 5, 2004                [Page 2]

Internet-Draft      Repurposing the STD Designation            June 2004

1.  Introduction

   The "STD" and "BCP" labels are described in [RFC2026] as subseries of
   the RFC series, with their numbers being assigned when documents are
   published as Internet Standards or as BCPs.  Beyond those brief
   statements, the organization of the two series, the classification of
   documents as either belonging together as part of a single "STD"
   specification or as separate, have largely been a matter of oral
   tradition, with more of the decisions being made as part of the RFC
   indexing process than explicitly by the IESG as part of the standards
   process.  The intent has been to permit a stable reference to
   particular specifications and groups of documents making up a
   specification, a reference that survives replacement of one RFC with
   another, addition or deletion of RFCs from the collective
   specification, and so on.

   While the intentions are fairly clear and quite desirable, this
   document suggests that the system has never worked well, especially
   for STDs that comprise (or point to) several RFCs.  There is no
   easily-accessible audit track that specifies which documents were
   part of an STD at a particular time (which can be very important for
   determining what a specification that points to an STD actually means
   or requires).  The low level of involvement of the IESG in the
   classification process is probably several problems waiting to
   happen.  And the "do not assign an STD number until the specification
   reaches full Internet Standard" model is unrealistic in a world in
   which much of the Internet runs on Proposed Standards and in which
   the IETF only very rarely approves and publishes "Applicability
   Statement" documents (and, when it does publish them, has little idea
   what to do with them -- several documents that rationally fall into
   that category have been published as BCPs instead).

   This document is intended as a very specific supplement and addition
   to [WhatStandards] and is believed to be consistent with its general
   analysis and the issues it raises.  However, its emphasis is on a
   paper track and specific "benchmark" or "snapshot" documentation, not
   on web pages and bug tracking.  On the other hand, the ideas proposed
   here could provide some of the anchoring for the "label system" that
   is required by the suggestions of that document.

   The discussion and proposal that follows are written in terms of
   traditional standards track documents (Proposed, Draft, and Internet
   Standard).  Whether it should also be applied to BCPs needs further
   review: the applicability is fairly obvious, but it is not clear
   whether it is necessary enough to justify the extra trouble.

Klensin                 Expires December 5, 2004                [Page 3]

Internet-Draft      Repurposing the STD Designation            June 2004

2.  Proposal Overview

   This document proposes that "STD"s be turned into real documents,
   separate from the underlying RFCs and managed under the direction of
   the IESG as part of the standards-specification process, rather than
   being simply pointers in indexes (or the RFCs under different file
   names or packaging).  It proposes that STD documents be created and
   numbers assigned when specifications enter the formal standards track
   (Proposed Standard under the model described in RFC 2026) and that
   the documents be used to track maturation, applicability
   recommendations, and history of those specifications.  It also
   outlines the format of those documents, which is expected to be
   different from the format of protocol specification documents and the
   RFC series generally ([RFC2223], [rfc2223bis]) and briefly discusses
   a transition strategy.

   While it is debatable whether everything published as a Proposed
   Standard today deserves, on the basis of quality of consensus or
   implementations, that definition, these documents and the early
   adoption of STD numbers may, on the one hand, help focus and
   discussion on that point and will, on the other, permit the IESG to
   attach appropriate qualifying notes as needed.  For example, if the
   community concluded that a specification should be published as a
   Proposed Standard, but that potential implementers should be warned
   that IETF confidence in its stability was lower than usual, these
   documents would be an appropriate place to publish that type of
   evaluation.  Conversely, if interoperable implementations already
   existed before the Proposed Standard was published, the corresponding
   STD document would be an appropriate place to note that fact.

   These documents, and documents authoritatively (normatively)
   referenced from them, will become, essentially, the definitions of
   standards.  Consequently, any changes to them will occur only under
   IESG authority and responsibility.  The IESG may, at its discretion,
   and with appropriate announcements to, and consultation of, the
   community, delegate authority for some sections to groups responsible
   for the ongoing maintenance of the standards, but may not relinquish
   responsibility for the documents themselves.  However, nothing in
   this specification prohibits (or requires) IESG authorization of
   placement of links in the STD documents that point to less formal and
   less authoritative discussions of, or comments on, the relevant
   standards should they deem that appropriate.

   [[ Note in Draft: In plain English, if it makes sense to the
   community to have an archive of comments, discussion, or proposed
   errata on the documents, that is fine, and it would be useful for
   these documents to identify the locations of those archives.  But we
   should be very careful that the contents of such archives are not

Klensin                 Expires December 5, 2004                [Page 4]

Internet-Draft      Repurposing the STD Designation            June 2004

   confused with the content of the specifications unless they go
   through some sort of formal review and consensus process.  The
   description of that process above is deliberately open-ended and
   flexible, as long as the IESG is willing to accept and maintain
   formal responsibility for whatever appears on those pages and could
   admit of some changes being made by, e.g., maintenance committees
   should the community want to move in that direction.  ]]

   By extension from the above, the IESG will need to make
   determinations, ideally after creating guidelines and getting
   community review and assent to them, as to criteria (e.g., length,
   importance, degree of discussion needed) by which authoritative
   comments and qualifications about standards will be incorporated into
   the STDs documents or issued as separate RFCs.

   [[ Note in Draft:  The author presumes that common sense will prevail
   and that this document does not need to try to specify those
   boundaries.  If that assumption is not correct, we have other
   problems that this type of specification cannot solve.  ]]

   If this proposal is accepted in principle, some additional sections
   will be required to explicitly update RFC 2026.

3.  A New Document Series

   When the IESG agrees to move a document onto the standards track, it
   either causes a new standard number ("STD number") to be assigned to
   it, or classifies it as part of an existing standard and assigns that
   number.  If multiple, related, specifications are approved at the
   same time, they may be assigned the same STD number.  As those
   documents are published as RFCs, the RFC may (and presumably usually
   will) contain the standard number since it will constitute a stable
   forward reference.  This assignment of an STD number, and assignment
   of a specification to it, results in a corresponding STD document
   being created or updated, as described below.  Following good sense
   and existing precedent, the IESG may decide to include documents that
   are not themselves on the standards track (e.g., Informational
   documents explaining, or describing alternatives to, an agreed-upon
   standard) in references from a STD document once that document is
   defined by the assignment of a number.

   Advancement of a document on the standards track, publication of
   applicability statements, notes on errata or other issues of
   sufficient and substantive importance to require alerting
   implementers or the community will also result in modifications to
   the relevant STD document.  It is explicitly anticipated that
   documents may be moved from one maturity level to another (i.e.,
   under the current system, to Draft, Full, or Historic, or from

Klensin                 Expires December 5, 2004                [Page 5]

Internet-Draft      Repurposing the STD Designation            June 2004

   Experimental to Proposed) by changing the STD document to identify
   the new level and include any relevant notes as an alternative to
   modifying the relevant RFC text and issuing new RFCs (and, of course,
   modifying the STD document to reflect those changes).

   Particular RFCs may move in and out of a STD (except for the
   historical record) as one RFC replaces another.  Because the STD
   document is expected to contain prose, it will be possible to deal
   with the long-standing issues of what "updates" means by identifying
   the relevant sections or concepts.  And, again because there is
   descriptive prose present, the IESG will be able to deal
   appropriately with the relationship between an old Full Standard and
   a newer document, at a lower maturity level, that is intended to
   replace it by specifying whatever they consider appropriate about
   what the implementer or other reader should look at.

   [[ Note in draft: Were either or both of the "Commission" (or
   "attic-cleaning") drafts ([NewtrkHistoric], [NewtrkAntique]) to be
   approved, the opportunities for using this STD model are obvious.
   The relevant STD document could be used to quickly capture, not only
   the fact that a document had been changed in status, but the date on
   which that occurred and any useful information about the reason why
   it was done -- using a much lighter-weight process than RFC
   publication.  However, this proposal is not tied to those in any way.

   While RFCs are permanent, STD documents are expected to evolve and
   incorporate changes over time.  However, they are also expected to
   include explicit change histories in order to make it possible for a
   reader to examine a current STD document and determine the status of
   the relevant standard at any particular previous time.  And STD
   number, once bound to a particular conceptual standard, is never
   reused for a different concept.

4.  Content and Organization of an STD Document

   [[Note in draft: this section still needs a good deal of work, but it
   is probably better to see if agreement can be reached on the
   principles here before too much time is spent on details.]]

   An STD document is expected to follow the general layout and
   formatting conventions of an RFC (because the community is familiar
   with them).  The components listed below may appear, or are expected
   to appear (required materials, even if only pro-forma, are identified
   with asterisks).  As with RFCs, additional sections may be included
   as needed and appropriate.  Note that STDs don't have authors: the
   RFCs have authors, but the "author" of an STD would always be "IETF"
   (or the historical "Network Working Group") so there is no

Klensin                 Expires December 5, 2004                [Page 6]

Internet-Draft      Repurposing the STD Designation            June 2004

   information in providing a name.  A individual who had made a major
   contribution to the STD document itself might be listed in an
   Acknowledgement or as a Contributor.

   Title.* It would be good for standards to have titles.  As others
      have pointed out, it would make them, especially those that
      involve multiple RFCs, a lot easier to talk about.
   Date.* This is the data the STD was last updated.  Everything else
      belongs in history or annotation.
   Abstract.* As with the title, it would be good to have these for
      standards, describing what the whole package does and not just
      what individual RFCs do.
   Maturity Level.* This is the maturity level for the STD as a whole.
      Presumably it is the lowest maturity level of any of the
      associated RFCs but, especially when one of the RFCs is intended
      to replace an earlier, more mature one, and text is supplied below
      that describes the situation, the IESG might decide to have it
      reflect the maturity level associate with the least mature
      document needed to form a full description of the standard.
      Additional comments may be associated with this section; it need
      not be just a label.  If an STD is retired in its entirety, no
      matter what maximum maturity level it reached earlier, this entry
      may be "Historic" with optional descriptive text.
   RFC list.* For each RFC that is currently associated with this STD,
      the name, title, document date, and maturity level most recently
      assigned and its date.  Optionally, an abbreviated abstract,
      applicability comments, errata, and other notes and commentary can
      be associated with some or all of the RFCs.  When there is a
      non-obvious relationship among the various documents, it should be
      described either here or in the applicability remarks below, as
      appropriate (or in a separate section, if one is required).
   Applicability Remarks about the standard.
   Security Remarks about the standard.
   History*.  This section should define the entire record of changes to
      the definition of the documents and applicability statements that
      make up the standard, with dates identified.  It should, in
      particular, identify the point at which one document superceded or
      updated another.

5.  Transition

   Obviously, there are many STD numbers assigned today that are not
   associated with documents as described here.  If this process is not
   bootstrapped with those numbers, it probably won't work.  So the
   following approach, which can be applied more less mechanically, is

Klensin                 Expires December 5, 2004                [Page 7]

Internet-Draft      Repurposing the STD Designation            June 2004

   o  For each existing STD number, create a prototype STD document.
      This step and the following one can be done from the existing
      std-index being maintained by the RFC Editor.
   o  Populate that document with the list of RFCs now associated with
      the STD and identify all of them as Internet Standards.
   o  Populate the title and abstract with the title and abstract of the
      first RFC in the series.  This won't be perfect, and in some
      cases, won't be even close, but it is better than nothing (and
      _much_ better than getting stuck waiting for someone to interpret
      the RFCs and do a write-up.
   o  Omit any applicability, errata, or similar sections.
   o  Populate the History section with a note to the effect that the
      Standard existed before the relevant date and the document is
      initialized as of that date.

6.  Operational Issues

   There is a case to be made that creating this sort of document series
   is additional work for the IESG.  In practice, this author doesn't
   believe it, at least to any significant degree.  All of the relevant
   information is created today.  It is scattered in meeting minutes and
   secretariat notes, protocol action notices, discussions about whether
   to restart WGs to deal with problems, etc.  Today that information,
   much of it quite useful, gets lost or at least becomes quite
   difficult to find.  Conversely, these series should reduce workload
   by considerably reducing the pressure to find editors to write or
   rewrite RFCs whose purpose is ultimately "this document is just like
   RFC xxxx, except that section 3.1.3 is removed to permit promoting
   the specification to the next maturity level.  The IESG can certainly
   still insist on that procedure if it deems it necessary, but it
   should also be possible to Last Call a revised STD document that
   contains more or less that sentence and not touch the RFC at all.
   And, if a WG responsible for creating or updating an STD document
   can't come up with an appropriate title and abstract/brief
   description, we are in a kind of trouble that goes well beyond any
   procedural issues.

   This document carefully does not specify the registry mechanism for
   assigning new STD numbers, nor the publication and repository
   mechanism for the documents.  Either or both might sensibly be done
   by the RFC Editor (that arrangement would certainly be consistent
   with historical precedents), but, if only because the STD series in
   this form would be a new task for them, it seems wise to leave this
   question to the IETF administrative process to sort out as seems
   appropriate in the broad administrative context.

Klensin                 Expires December 5, 2004                [Page 8]

Internet-Draft      Repurposing the STD Designation            June 2004

7.  References to STDs or References to RFCs

   Before this proposal was generated, vendors who wished to specify
   what they support, and potential customers who wished to specify what
   they wanted to purchase, had a choice between referencing specific
   RFCs (to get precision) or, for full standards, a specific STD number
   (to get "the most current version").  Except for providing an "STD"
   mechanism for referencing documents other than full Internet
   Standards, this proposal does not change either of those options:
   both are still free to use the existing forms.  In the rare case in
   which a vendor is deliberately attempting to confuse its potential
   customers, this mechanism is not likely to help very much either.  It
   does, however, provide a third option, which is to specify the state
   of an STD as of a particular date (even a date in the past or future)
   or within a particular date range.  So, whatever the referencing
   issues are today, this certainly does not make them worse and almost
   certainly makes them better.

8.  IANA Considerations

   This document does not anticipate any specific tasks for the IANA.
   However, over time, it may be desirable to review and update the
   descriptions of various registries to refer to STD numbers, rather
   than RFC numbers, as the definitions or authority for those
   registries.  See also Section 6.

9.  Security Considerations

   This document specifies an administrative procedure for the IETF and
   hence does not raise any new issues about the security of the
   Internet.  However, the availability of the type of document
   described here may provide a convenient mechanism and repository of
   vulnerabilities and other issues that are discovered after RFCs are
   issued but that do not justify updating (or for which resources are
   not available to update) the relevant RFC.  Having an obvious place
   to look for those notifications and discussions for standards-track
   documents might enhance overall security somewhat.

10.  Acknowledgements

   The general ideas described here have been discussed on and off for
   several years, but have never been turned into a public documents.
   Thanks are due to several generations of IAB and IESG members and to
   RFC Editor staff for helping to clarify the ideas and to identify
   some variants that would or would not work.  The ideas in this
   specific presentation are, of course, those of the author and are one
   with which some of the contributors might disagree.  Pekka Savola
   provided extensive and very useful comments on a preliminary version

Klensin                 Expires December 5, 2004                [Page 9]

Internet-Draft      Repurposing the STD Designation            June 2004

   of the initial draft.

11.  References

11.1  Normative References

   [RFC2026]  Bradner, S., "The Internet Standards Process -- Revision
              3", BCP 9, RFC 2026, October 1996.

              Loughney, J., "Standards, What Standards?",
              draft-loughney-what-standards-01 (work in progress),
              February 2004.

11.2  Informative References

              Klensin, J., "Valuable Antique Documents: A Model for
              Advancement", draft-klensin-newtrk-antiques-00 (work in
              progress), May 2004.

              Alvestrand, H. and E. Lear, "Moving documents to Historic:
              A procedure", draft-alvestrand-newtrk-historical-00 (work
              in progress), March 2004.

   [RFC2223]  Postel, J. and J. Reynolds, "Instructions to RFC Authors",
              RFC 2223, October 1997.

              Reynolds, J. and R. Braden, "Instructions to Request for
              Comments (RFC) Authors", draft-rfc-editor-rfc2223bis-07
              (work in progress), August 2003.

Author's Address

   John C Klensin
   1770 Massachusetts Ave, #322
   Cambridge, MA  02140

   Phone: +1 617 491 5735
   EMail: john-ietf@jck.com

Klensin                 Expires December 5, 2004               [Page 10]

Internet-Draft      Repurposing the STD Designation            June 2004

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

   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

Disclaimer of Validity

   This document and the information contained herein are provided on an

Copyright Statement

   Copyright (C) The Internet Society (2004).  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.


   Funding for the RFC Editor function is currently provided by the
   Internet Society.

Klensin                 Expires December 5, 2004               [Page 11]