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

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


                Internet Standards Documentation (ISDs)
               draft-ietf-newtrk-repurposing-isd-00.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 March 25, 2005.

Copyright Notice

   Copyright (C) The Internet Society (2004).

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
   and acronym to a specification when it enters the first level of the



Klensin & Loughney       Expires March 25, 2005                 [Page 1]


Internet-Draft    Internet Standards Documentation (ISDs) September 2004


   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.

Table of Contents

   1.   Introduction . . . . . . . . . . . . . . . . . . . . . . . .   3
   2.   Problem(s) . . . . . . . . . . . . . . . . . . . . . . . . .   4
   3.   Periodic Reviews of Protocols are not Being Carried Out  . .   5
   4.   There is no Maintenance Team Responsible for a Protocol  . .   5
   5.   Proposal Overview  . . . . . . . . . . . . . . . . . . . . .   5
   6.   A New Document Series  . . . . . . . . . . . . . . . . . . .   7
   7.   Content and Organization of an ISD Document  . . . . . . . .   8
   8.   Transition . . . . . . . . . . . . . . . . . . . . . . . . .   9
   9.   Operational Issues . . . . . . . . . . . . . . . . . . . . .  10
   10.  References to ISDs or References to RFCs . . . . . . . . . .  11
   11.  IANA Considerations  . . . . . . . . . . . . . . . . . . . .  11
   12.  Security Considerations  . . . . . . . . . . . . . . . . . .  12
   13.  Acknowledgements . . . . . . . . . . . . . . . . . . . . . .  12
   14.  Changes from Previous Versions . . . . . . . . . . . . . . .  12
   15.  References . . . . . . . . . . . . . . . . . . . . . . . . .  13
   15.1   Normative References . . . . . . . . . . . . . . . . . . .  13
   15.2   Informative References . . . . . . . . . . . . . . . . . .  13
        Authors' Addresses . . . . . . . . . . . . . . . . . . . . .  13
        Intellectual Property and Copyright Statements . . . . . . .  15

























Klensin & Loughney       Expires March 25, 2005                 [Page 2]


Internet-Draft    Internet Standards Documentation (ISDs) September 2004


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).  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 to create a paper track and specific
   "benchmark" or "snapshot" documentation for Internet Standards, not
   on web pages and bug tracking.



Klensin & Loughney       Expires March 25, 2005                 [Page 3]


Internet-Draft    Internet Standards Documentation (ISDs) September 2004


   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.

2.  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?




Klensin & Loughney       Expires March 25, 2005                 [Page 4]


Internet-Draft    Internet Standards Documentation (ISDs) September 2004


   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.

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

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

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



Klensin & Loughney       Expires March 25, 2005                 [Page 5]


Internet-Draft    Internet Standards Documentation (ISDs) September 2004


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

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



Klensin & Loughney       Expires March 25, 2005                 [Page 6]


Internet-Draft    Internet Standards Documentation (ISDs) September 2004


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

   [[Note in draft: Numbers versus Names.  There are advantages to names
   or acronyms (easier to remember as long as there are not too many of
   them, more human friendly) and to numbers (very precise and
   language-independent).  The choice between the two does not seem to
   be worth the amount of energy it will take.  Consequently, this
   version of the document recommends assigning both a number and a name
   (acronym or other string).]]

6.  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.,
   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 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



Klensin & Loughney       Expires March 25, 2005                 [Page 7]


Internet-Draft    Internet Standards Documentation (ISDs) September 2004


   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 ISD model are obvious.
   The relevant ISD 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, 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.

7.  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 would be good 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.
   Date.* This is the data the ISD 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.





Klensin & Loughney       Expires March 25, 2005                 [Page 8]


Internet-Draft    Internet Standards Documentation (ISDs) September 2004


   Maturity Level.* This is the maturity level for the ISD 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 in
      the ISD 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 ISD 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 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.

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



Klensin & Loughney       Expires March 25, 2005                 [Page 9]


Internet-Draft    Internet Standards Documentation (ISDs) September 2004


   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
      the work.  Initial assignments and drafts should be created on an
      area basis, preferably by directorates or specially-selected
      committees, coordinates 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.
   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.

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



Klensin & Loughney       Expires March 25, 2005                [Page 10]


Internet-Draft    Internet Standards Documentation (ISDs) September 2004


   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.

   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.

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

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



Klensin & Loughney       Expires March 25, 2005                [Page 11]


Internet-Draft    Internet Standards Documentation (ISDs) September 2004


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

13.  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
   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".

14.  Changes from Previous Versions

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

   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.

15.  References





Klensin & Loughney       Expires March 25, 2005                [Page 12]


Internet-Draft    Internet Standards Documentation (ISDs) September 2004


15.1  Normative References

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

15.2  Informative References

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

   [NewtrkHistoric]
              Alvestrand, H. and E. Lear, "Getting rid of the cruft: A
              procedure to deprecate old standards",
              draft-alvestrand-newtrk-cruft-01 (work in progress),
              September 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.

   [rfc2223bis]
              Reynolds, J. and R. Braden, "Instructions to Request for
              Comments (RFC) Authors", draft-rfc-editor-rfc2223bis-07
              (work in progress), 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




Klensin & Loughney       Expires March 25, 2005                [Page 13]


Internet-Draft    Internet Standards Documentation (ISDs) September 2004


   John A Loughney
   Itamerenkatu 11-13
   Helsinki,   00180
   Finland

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












































Klensin & Loughney       Expires March 25, 2005                [Page 14]


Internet-Draft    Internet Standards Documentation (ISDs) September 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
   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 (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.


Acknowledgment

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




Klensin & Loughney       Expires March 25, 2005                [Page 15]