[Search] [pdf|bibtex] [Tracker] [WG] [Email] [Diff1] [Diff2] [Nits]

Versions: 00 01 02 03 04                                                
Network Working Group                                         J. Klensin
Internet-Draft                                               J. Loughney
Expires: September 13, 2005                               March 12, 2005


                Internet Standards Documentation (ISDs)
               draft-ietf-newtrk-repurposing-isd-02.txt

Status of this Memo

   This document is an Internet-Draft and is subject to all provisions
   of Section 3 of RFC 3667.  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 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.

   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 September 13, 2005.

Copyright Notice

   Copyright (C) The Internet Society (2005).

Abstract

   It has been observed that the current IETF standard designations, STD
   nnnn and BCP nnnn designation, have not worked well.  Problems have
   been found when one of them is used either as a stable reference for
   external specifications or as a combined reference for multiple
   documents linked together into a single document.  This document
   proposes two changes to these designations.  The first of these
   changes would create a new document series and assign a new number



Klensin & Loughney     Expires September 13, 2005               [Page 1]


Internet-Draft    Internet Standards Documentation (ISDs)     March 2005


   and acronym to a specification when it enters the first level of the
   Standards Track (or is first designated as a BCP).  The second would
   migrate the concept of STDs and BCPs numbering of RFCs into actual
   documents that detail what they identify, their publication
   information and their change history.  The document also specifies a
   set of minor standards process changes to accommodate and integrate
   the new style of doing things that is represented by the new document
   series.

Table of Contents

   1.   Introduction . . . . . . . . . . . . . . . . . . . . . . . .   3
   2.   Proposal Overview  . . . . . . . . . . . . . . . . . . . . .   4
   3.   A New Document Series  . . . . . . . . . . . . . . . . . . .   5
   4.   Publication and Formatting . . . . . . . . . . . . . . . . .   6
   5.   Content and Organization of an ISD Document  . . . . . . . .   7
   6.   Transition . . . . . . . . . . . . . . . . . . . . . . . . .   8
   7.   Operational Issues . . . . . . . . . . . . . . . . . . . . .   9
   8.   References to ISDs or References to RFCs . . . . . . . . . .  10
   9.   References from ISDs . . . . . . . . . . . . . . . . . . . .  11
     9.1  Document References  . . . . . . . . . . . . . . . . . . .  11
     9.2  Errata and Corrections . . . . . . . . . . . . . . . . . .  11
   10.  IANA Considerations  . . . . . . . . . . . . . . . . . . . .  12
   11.  Security Considerations  . . . . . . . . . . . . . . . . . .  12
   12.  Acknowledgements . . . . . . . . . . . . . . . . . . . . . .  12
   13.  Changes from Previous Versions . . . . . . . . . . . . . . .  12
   14.  References . . . . . . . . . . . . . . . . . . . . . . . . .  13
     14.1   Normative References . . . . . . . . . . . . . . . . . .  13
     14.2   Informative References . . . . . . . . . . . . . . . . .  13
        Authors' Addresses . . . . . . . . . . . . . . . . . . . . .  14
   A.   Motivation and Historical Context  . . . . . . . . . . . . .  15
     A.1  Problem(s) . . . . . . . . . . . . . . . . . . . . . . . .  15
     A.2  Periodic Reviews of Protocols are not Being Carried Out  .  16
     A.3  There is no Maintenance Team Responsible for a Protocol  .  16
   B.   Notes on the Design  . . . . . . . . . . . . . . . . . . . .  16
     B.1  Comments, discussion notes, and proposed errata  . . . . .  16
     B.2  Numbers versus Names . . . . . . . . . . . . . . . . . . .  17
     B.3  Citations of Informative Material  . . . . . . . . . . . .  17
        Intellectual Property and Copyright Statements . . . . . . .  18












Klensin & Loughney     Expires September 13, 2005               [Page 2]


Internet-Draft    Internet Standards Documentation (ISDs)     March 2005


1.  Introduction

   The IETF has produced a large (and useful) body of work.  In many
   ways, the IETF has been a victim of its own (or at least of TCP/IP's)
   success.  As the standards which the IETF produces see wider
   deployment by parties outside of the IETF, the system of
   documentation and updating within the IETF causes some amount of
   confusion.

   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.  The purpose and
   organization of the STD series is defined in more detail in
   [RFC1311].  Beyond those brief statements, the organization of the
   two series and 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.  RFC1311, written before the
   standards process reforms of the 1992-1994 period (see, e.g.,
   [RFC1396] and [RFC1602]), assigns responsibility for defining the
   content of STD documents to the IAB, but was never updated to reflect
   the change to IESG responsibility for the standards track.  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 standard (identified by an STD number) at a particular
   time (which can be very important for determining what a
   specification that points to an STD actually means or requires).
   Historically, the community and the IESG have not been heavily
   involved in the process of organizing and grouping standards-track
   documents by STD number.  In retrospect, some of the decisions have
   been, or should have been, controversial and have led to
   misunderstandings about what is implied by conformance to a standard.
   In addition, 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).




Klensin & Loughney     Expires September 13, 2005               [Page 3]


Internet-Draft    Internet Standards Documentation (ISDs)     March 2005


   This document creates a paper track and specific "benchmark"
   documentation for Internet Standards.  While the documents it
   specifies may assist in the creation of dynamic web pages, or may be
   linked to bug tracking systems, those are not its primary intent.

   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.

   Appendix A describes some of the specific IETF issues, identified
   during 2004, that led to the development of this specification.

   Prototype examples of the type of documents contemplated here appear
   in [ISD-Examples1] and, to a lesser extent, [ISD-Examples-Process].
   Those examples are just examples; they are not part of this
   specification or definition.

   [[Note in Draft (RFC Editor to remove this paragraph before
   publication and after setting "Updates"): This document is intended
   to update RFC 2026 with regard to Last Calls and how the standards
   process is documented, RFC 3710 with regard to the IESG's list of
   responsibilities and procedures, and RFC 3967 on references.  It
   obsoletes RFC 1311 on the STD document series; that document should
   be moved to Historic when this one is approved.  ]]

2.  Proposal Overview

   This document proposes that a new document series be created, called
   Internet Standards Documents ("ISD"s) and that these be real
   documents, separate from the underlying RFCs.  The documents would be
   managed under the direction of the IESG as part of the
   standards-specification process, rather than being simply pointers in
   indexes as, e.g., the STD series has been, or being the RFCs
   themselves with different file names or packaging.  It proposes that
   ISD 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.

   Debate continues in the IETF about the proper threshold for Proposed
   Standards with regard to both protocol quality and document quality.
   Part of the problem is the use of a single, unqualified, label that



Klensin & Loughney     Expires September 13, 2005               [Page 4]


Internet-Draft    Internet Standards Documentation (ISDs)     March 2005


   may not be a good match to all situations.  The documents proposed
   here will allow more flexibility by permitting 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.

   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.  The starting point
   and minimum descriptive and qualifying text for new standards will be
   the text of the Protocol Action Notice.

3.  A New Document Series

   When the IESG agrees to move a document onto the standards track, it
   either causes a new Internet Standard number ("ISD number") and name
   or acronym ("ISD name") to be assigned to it, or classifies it as
   part of an existing standard and assigns that number and name.  If
   multiple, related, specifications are approved at the same time, they
   may be assigned the same ISD number and name.  As those documents are
   published as RFCs, the RFC may (and presumably usually will) contain
   the standard number and name since it will constitute a stable
   forward reference.  This assignment of an ISD number and name, and
   assignment of a specification to it, results in a corresponding ISD
   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.,



Klensin & Loughney     Expires September 13, 2005               [Page 5]


Internet-Draft    Internet Standards Documentation (ISDs)     March 2005


   Informational documents explaining, or describing alternatives to, an
   agreed-upon standard) in references from a ISD document once that
   document is defined by the assignment of a name and 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 ISD 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
   Experimental to Proposed) by changing the ISD 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 ISD document to reflect those changes).

   Particular RFCs may move in and out of a ISD (except for the
   historical record) as one RFC replaces another.  Because the ISD
   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.

   While RFCs are permanent, ISD 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 ISD document and determine the status of
   the relevant standard at any particular previous time.  An ISD number
   or name, once bound to a particular conceptual standard, is never
   reused for a different concept.

4.  Publication and Formatting

   ISDs constitute an entirely new document series, to be managed
   directly by the IESG as part of its management of the standards
   process.  ISDs are not to be published as part of the RFC series.
   The basic source format an ISD will be XML, conforming to an
   appropriate and IESG-designated, Document Type Definition (DTD).  For
   archival and external reference purposes, the formal archival form of
   the ISD will be ASCII text.  However, it is anticipated that web
   pages with embedded links will also be generated from the XML and
   made accessible from the IETF home page.

   Draft versions of ISDs or proposals for updating them may be posted



Klensin & Loughney     Expires September 13, 2005               [Page 6]


Internet-Draft    Internet Standards Documentation (ISDs)     March 2005


   as Internet-Drafts.  Such posting will generally be required in
   conjunction with Last Calls unless the IESG devises an alternate
   procedure.  Since current Internet-Draft format requirements are
   based on RFC formats and requirements, posting drafts for ISDs as
   Internet-Drafts may require some extensions to the Internet-Draft
   posting rules.

   ISDs will be identified by a name and the combination of a
   serially-assigned standard number and a date with resolution in days.
   The numbers for ISDs and those for STDs (see [RFC1311]) are not
   expected to be synchronized.

5.  Content and Organization of an ISD Document

   An ISD 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 ISDs don't have authors: the
   RFCs have authors, but the "author" of an ISD would always be "IETF"
   (or the historical "Network Working Group") so there is no
   information in providing an author or editor name.  A individual who
   had made a major contribution to the ISD document itself might be
   listed in an Acknowledgement or as a Contributor.

   Title.* It is desirable for standards to have titles as well as
      numbers and acronyms (names).  As others have pointed out, it
      would make them, especially those that involve multiple RFCs, a
      lot easier to talk about.  For example, by common usage, the
      "name" of an ISD might be "SMTP" with a title of "Simple Mail
      Transfer Protocol".
   Standard Acronym and Number* The ISD will be associated with both an
      abbreviated name or acronym that is descriptive of the standard
      and a standard number, the latter of which will be
      serially-assigned.
   Date.* This is the date the ISD was last updated.  Everything else
      belongs in history or annotation.  This date will specify a day,
      not just a month.
   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, Implementations, and Applicability Level*
      ISDs as a whole do not have maturity levels in the traditional
      sense.  At the same time, it is useful for the ISD to have a
      section that provides information about implementation,
      interoperability, and deployment experience.  If some of the
      normatively-referenced RFCs are intended to replace earlier, more



Klensin & Loughney     Expires September 13, 2005               [Page 7]


Internet-Draft    Internet Standards Documentation (ISDs)     March 2005


      mature ones, the ISD would normally be expected to describe and
      explain that situation.  If an ISD is retired in its entirety, no
      matter what maturity levels are associated with its individual
      documents, this entry may be "Historic" with optional additional
      descriptive text.
   RFC list.* For each RFC that is currently associated with this ISD,
      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.  Any remarks about
      applicability that seem useful or appropriate, as authorized.
   Security Remarks about the standard.  Any authorized remarks about
      the security implications or considerations of the standard that
      are not completely reflected in the component RFCs.
   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 superseded or
      updated another.

6.  Transition

   Obviously, we now have many full Internet Standards, with STD numbers
   assigned and packaging defined by those numbers, that are not
   associated with documents as described here.  We have even more
   documents at Proposed or Draft Standard levels that do not have
   either documents of this type or grouping.  Some of those documents
   should almost certainly be bound to existing packages defined by STD
   numbers.  If this process is not bootstrapped by issuing ISDs for
   those documents, it probably won't work.  So the following approach,
   which can be applied more less mechanically, is suggested:

   o  For each existing STD number, assign a name or acronym and create
      a prototype ISD document.  Reuse of the STD numbers as ISD numbers
      would save some time and avoid some confusion.  This step and the
      management of titles and abstracts, as discussed below, 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 ISD and identify all of them as Internet Standards.
   o  For each existing Proposed or Draft Standard, generate a template
      document and assign a name and number.  Exceptions should be made
      and documents grouped when it is obvious and uncontroversial that
      several documents belong together and someone can be found to do



Klensin & Loughney     Expires September 13, 2005               [Page 8]


Internet-Draft    Internet Standards Documentation (ISDs)     March 2005


      the work.  Initial assignments and drafts should be created on an
      area basis, preferably by directorates or specially-selected
      committees, coordinating with any reclassification efforts to
      avoid duplicate work.
   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 but include,
      for convenience, links to the RFC Editor's errata page where
      applicable.
   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.
   o  As these documents are created, and to avoid having to create all
      of them at once, modify the official rfc-index and other indices
      and web pages under IETF control to indicate either the name and
      number of the ISD document or that the relevant document is still
      under construction.
   o  It will be important to preserve the STD numbers and index for
      some time, perhaps indefinitely, because some references exist to
      them.  However, it will not be necessary to expand that list.
      Absorbing the STD numbering space into the ISD series will further
      aid in locating appropriate information.

7.  Operational Issues

   There is a case to be made that creating this sort of document series
   is additional work for the IESG.  In practice, the authors don'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 ISD that
   contains more or less that sentence and not touch the RFC at all.
   And, if a WG responsible for creating or updating an ISD 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.

   For a new specification document intended to be processed onto the



Klensin & Loughney     Expires September 13, 2005               [Page 9]


Internet-Draft    Internet Standards Documentation (ISDs)     March 2005


   standards track (including non-procedural BCPs), responsibility for
   preparing a draft of a new or revised ISD and advising on whether the
   standards-track document will require a new ISD number or become part
   of an existing ISD lies with the relevant WG or other submitter.  The
   IESG will issue a Last Call that includes the proposed ISD text along
   with the substantive document(s).  They will then modify the ISD text
   as needed based on input during Last Call and internal discussions.
   In general, the new or revised ISD will be issued at the same time as
   (or replacing) the Protocol Action Notice, referencing the approved
   Internet-Draft and containing copies of any RFC Editor instructions.
   That material would then be replaced in the ISD when the relevant
   documents are published.

   The ISD document is intended to become the repository for the
   substantive content of Protocol Action Notices and for IESG
   statements and qualifications about what they are approving.  This
   will include any "known defects" or "this must be fixed when the
   document is advanced to the next maturity level" statements.

   It is the intent of this specification that all substantive or
   normative changes to an ISD be the result of IETF consensus, i.e.,
   that the change be made only after a Last Call and IESG review and
   approval.  However, more flexibility and less formality is
   appropriate for at least some non-normative changes, commentary, etc.
   The IESG is tasked with specifying and documenting the types of
   changes that do not require Last Calls or IESG approval, and the
   processes for making those changes.

   This document carefully does not specify the registry mechanism for
   assigning new ISD numbers, nor the details of publication and
   repository mechanisms for the documents although it specifies some
   requirements for them (see Section 4).  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 ISD
   series 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.

   Regardless of what organizational arrangements are responsible for
   updating and maintaining these documents, and in spite of their
   containing a cumulative change history, they should be treated as
   archival -- at least as archival as the RFC series.

8.  References to ISDs 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



Klensin & Loughney     Expires September 13, 2005              [Page 10]


Internet-Draft    Internet Standards Documentation (ISDs)     March 2005


   RFCs (to get precision) or, for full standards, a specific STD number
   (to get "the most current version").  Except for providing an "ISD"
   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.

   It should also be noted that other Standardization bodies have had
   difficulties when referencing RFCs.  It is not always clear whether
   an RFC or an STD should be referenced.  When a reference is made,
   there can be problems when the RFC that is referenced becomes updated
   or obsoleted.

9.  References from ISDs

9.1  Document References

   An ISD can be thought of as anchored in one of more "base documents"
   -- RFCs that, in combination, specify the technical content of the
   standard itself.  These based documents must be standards-track
   technical specifications or operational or Applicability Statement
   BCPs (i.e., not IETF-process BCPs, see [Standing-Docs]).  All
   references to base documents are, essentially by definition,
   normative and must follow the traditional rules of the RFC Editor for
   stability of references (see, e.g., [RFC2223]) as modified by
   [RFC3967].  However, an ISD may reference, informationally, any
   document or material felt to be helpful in understanding the standard
   or its context.

   References to, and discussion of, base documents may, and normally
   will, associate standards-track maturity levels with those documents.
   The underlying RFCs themselves are no longer considered to have such
   maturity levels.

9.2  Errata and Corrections

   Errata and other corrections that represent IETF consensus (i.e.,
   based on an IESG, or IESG-delegated, determination after Last Call)
   are normative and identified in a way that distinguishes them from
   suggested errata or changes that are not known to represent IETF
   consensus.  The latter may still be included in the ISD document as
   informative material under the general "felt to be helpful" provision



Klensin & Loughney     Expires September 13, 2005              [Page 11]


Internet-Draft    Internet Standards Documentation (ISDs)     March 2005


   of the previous section.

10.  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 ISD numbers, rather
   than RFC numbers, as the definitions or authority for those
   registries.  See also Section 7.

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

12.  Acknowledgements

   The general ideas described here have been discussed on and off for
   several years, but have never been turned into 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
   of the initial draft.  Harald Alvestrand, Bob Braden, and several
   others made comments on the first posted draft that resulted in
   important clarifications.  Discussions during and after IETF 60 led
   to further changes and the consolidation of the previous relevant
   documents.  Bob Braden suggested not trying to reuse the term "STD",
   and provided new term "ISD".  Additional helpful comments and
   corrections were provided by Pekka Savola and Scott Bradner.

13.  Changes from Previous Versions

   [[Note in Draft: This section is to be removed before RFC
   publication]]







Klensin & Loughney     Expires September 13, 2005              [Page 12]


Internet-Draft    Internet Standards Documentation (ISDs)     March 2005


   Version 00.  This version replaces and consolidates the previous
      documents "Repurposing the STD Designation"
      (draft-klensin-newtrk-std-repurposing-00.txt, 6 June 2004) and
      "Standards, What Standards?"
      (draft-loughney-what-standards-01.txt, February 2004).  It also
      includes a number of editorial clarifications and a few more
      details than its predecessors.  The tone is still somewhat
      informal and conversational; if general consensus is reached on
      the ideas, that should be corrected, in both the text and the
      abstract, in a subsequent draft.
   Version 01.  This version incorporates the changes and clarifications
      discussed in a meeting of the NEWTRK WG at IETF 61 (Washington,
      DC, USA, November 2004) and on the mailing list in the subsequent
      weeks.  While some outstanding issues and possible issues remain,
      the document has been considerably tightened up and a number of
      previous loose ends documented.  In the process, some of the
      conversational text in the previous versions (see above) has been
      edited into a more formal form.  Most of the "why is this
      justified and being done" material has been moved to an appendix
      in order to facilitate eventually turning the Internet-Draft into
      a permanent IETF process specification.
   Version 02.  This version incorporates the changes and clarifications
      discussed in the NEWTRK WG meeting at IETF 62 (Minneapolis, MN,
      USA, March 2005).  All non-editorial "notes in draft" have been
      resolved, and those that discuss design choices have been removed
      to an appendix.

14.  References

14.1  Normative References

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

   [RFC3967]  Bush, R. and T. Narten, "Clarifying when Standards Track
              Documents may Refer Normatively to Documents at a Lower
              Level", BCP 97, RFC 3967, December 2004.

14.2  Informative References

   [ISD-Examples-Process]
              Bradner, S., "Sample ISD for the IETF Standards Process",
              Internet-Draft draft-ietf-newtrk-sample-isd-00, October
              2004.

   [ISD-Examples1]
              Klensin, J., "Internet Standards Documentation (ISDs) -
              Examples", Internet-Draft draft-ietf-newtrk-sample-isd-00,



Klensin & Loughney     Expires September 13, 2005              [Page 13]


Internet-Draft    Internet Standards Documentation (ISDs)     March 2005


              October 2004.

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

   [RFC1396]  Crocker, S., "The Process for Organization of Internet
              Standards Working Group (POISED)", RFC 1396, January 1993.

   [RFC1602]  Huitema, C. and P. Gross, "The Internet Standards Process
              -- Revision 2", RFC 1602, March 1994.

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

   [RFC3774]  Davies, E., "IETF Problem Statement", RFC 3774, May 2004.

   [Standing-Docs]
              Klensin, J., "Standing Documents Describing IETF Processes
              and Operations", Internet-Draft draft-ietf-newtrk-sd-00,
              February 2004.

   [rfc2223bis]
              Reynolds, J. and R. Braden, "Instructions to Request for
              Comments (RFC) Authors",
              Internet-Draft draft-rfc-editor-rfc2223bis-07, August
              2003.


Authors' Addresses

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

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


   John A Loughney
   Itamerenkatu 11-13
   Helsinki,   00180
   Finland

   Phone: +358 5 04836242
   Email: john.loughney@nokia.com





Klensin & Loughney     Expires September 13, 2005              [Page 14]


Internet-Draft    Internet Standards Documentation (ISDs)     March 2005


Appendix A.  Motivation and Historical Context

Appendix A.1  Problem(s)

   The following problems are excerpted from Section 2.4 of the IETF
   Problem statement [RFC3774].

   o  Relatively few specifications are now progressed beyond Proposed
      Standard (PS) to Draft Standard (DS) level, and even fewer to Full
      Standard (FS).
   o  There is no formal bug reporting or tracking system in place for
      IETF specifications.
   o  The periodic review of protocols at PS and DS levels specified in
      are not being carried out, allowing protocols to persist in these
      lower maturity levels for extended periods of time, whereas the
      process would normally expect them to progress or be relegated to
      Historic status.
   o  No individual or body is given the task of 'maintaining' a
      specification after the original WG has closed down.
      Specifications are generally only updated when a need for a new
      version is perceived.  No attempt is normally made to correct bugs
      in the specification (whether they affect operation or not) and
      the specification is not updated to reflect parts of the
      specification that have fallen into disuse or were, in fact, never
      implemented.  This is in part because the current procedures would
      require a standard to revert to the PS maturity level even when
      specification maintenance is carried out which can be demonstrated
      to have no or minimal effect on an existing protocol at DS or FS
      level.
   o  Few Specifications Progress Beyond Proposed Standard.
      The IETF, as of late, does not have a good track record of moving
      protocols beyond Proposed Standard.  In fact, the goal of most
      Working Groups is to produce a set of RFCs and then shut down.
      Working groups that do this are considered to have succeeded.
      There are only a handful of long-lived working groups, such as
      IPv6, whose charters include progressing standards beyond Proposed
      Standards.  Occasionally, new working groups need to be spun up to
      make sense of the existing set of RFCS, such as tcpm (TCP
      Maintenance).
   o  There is no Formal Bug Reporting or Tracking System.
      Bugs in a specification can be found at any point.  There have
      been bugs found even in Full Standards.  How do we ensure
      correctness in our own standards?

   This document does not take a stand on the issue of the relevance of
   the current standards track.  It does note that at any given moment,
   a standard may be undergoing work to progress the document to another
   level.  We discuss the problems identified in more detail below.



Klensin & Loughney     Expires September 13, 2005              [Page 15]


Internet-Draft    Internet Standards Documentation (ISDs)     March 2005


Appendix A.2  Periodic Reviews of Protocols are not Being Carried Out

   Many protocols suffer from benign neglect.  The working group charged
   with developing the protocol becomes dormant or is shut down.  The
   principal authors of the specification may no longer be involved in
   the IETF.  Further development of the protocol may even be officially
   discouraged.

   Other standards development organizations (SDOs) may consider
   extensions or modification to the protocols.  This causes problems
   for parties interested in the technology, as it becomes unclear as to
   exactly what specifies a particular protocol.  Additionally, it makes
   it hard to track errors in or updates to a specification or protocol.

Appendix A.3  There is no Maintenance Team Responsible for a Protocol

   Specifications are generally only updated when a need for a new
   version is perceived.  No attempt is normally made to correct bugs in
   the specification (whether they affect operation or not) and the
   specification is not updated to reflect parts of the specification
   that have fallen into disuse or were, in fact, never implemented.
   This is in part because the current procedures would require a
   standard to revert to the PS maturity level even when specification
   maintenance is carried out which can be demonstrated to have no or
   minimal effect on an existing protocol at DS or FS level.

Appendix B.  Notes on the Design

   In the process of developing this specification, several notes and
   comment were made about tradeoffs.  Those notes appear below,
   essentially unedited.  They are not a normative part of the
   specification.

Appendix B.1  Comments, discussion notes, and proposed errata

   If 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 confused with the content of the specifications
   unless they go through some sort of formal review and consensus
   process.  The description of that process in the specification is
   deliberately open-ended and flexible.  If the IESG is willing to
   accept and maintain formal responsibility for whatever appears in ISD
   documents, they could include some non-normative changes being made
   by, e.g., maintenance committees should the community want to move in
   that direction.




Klensin & Loughney     Expires September 13, 2005              [Page 16]


Internet-Draft    Internet Standards Documentation (ISDs)     March 2005


Appendix B.2  Numbers versus Names

   There was an extended debate in the Working Group as to whether ISDs
   were better identified by acronyms or serial numbers.  There are
   advantages to names or acronyms and and to numbers.  The former are
   easier to remember as long as there are not too many of them and are
   usually more human friendly.  The latter are very precise and
   language-independent.  The choice between the two did not appear to
   be worth the amount of energy it would have taken to reach consensus,
   if even that were possible.  Consequently, the document recommends
   assigning both a number and a name (acronym or other string) to each
   ISD.

Appendix B.3  Citations of Informative Material

   There is discussion in Section 9.1 about the inclusion of informative
   (non-normative) material, but no specific guidance is given about
   what material is and is not appropriate, other than that it is "felt
   to be helpful".  The apparent ambiguity is deliberate, relying on
   good sense and the requirement that substantive changes to ISDs must
   be Last Called in the IETF, rather than an attempt to make specific
   rules that would probably be inappropriate for some future situation.





























Klensin & Loughney     Expires September 13, 2005              [Page 17]


Internet-Draft    Internet Standards Documentation (ISDs)     March 2005


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 (2005).  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 & Loughney     Expires September 13, 2005              [Page 18]