[Docs] [txt|pdf] [Tracker] [Email] [Nits]

Versions: 00

Network Working Group                                         J. Klensin
Internet-Draft                                              July 5, 2010
Obsoletes: RFC1311
(if approved)
Updates: RFC2026, RFC3710,
RFC3967, RFC4897
(if approved)
Intended status: BCP
Expires: January 6, 2011


      Internet Standards Documentation (ISDs) and Maturity Levels
                        draft-klensin-isdbis-00

Abstract

   The current IETF standard-track maturity level definitions, including
   the assumption that most specification of successful protocols would
   advance rapidly to Internet Standard, the never-used automatic
   expiration mechanism, and the STD nnnn designation, have not worked
   well.  Users of IETF Standards have found it difficult to determine
   what standards were associated with others in groups, the actual
   status of specifications within a related group, and the level of
   interoperability testing and deployment and use for any given
   standard or set of features.  The community has rarely used the
   "requirement level" mechanism in recent years.  There is now an
   errata mechanism for published RFCs, but the errata lists do not
   provide authoritative, consensus-based, corrections to standards-
   track documents.  This document suggests that all of those issues are
   symptoms of a single system of interrelated issues and problems and
   proposes an integrated solution.

Status of this Memo

   This Internet-Draft is submitted in full conformance with the
   provisions of BCP 78 and BCP 79.

   Internet-Drafts are working documents of the Internet Engineering
   Task Force (IETF).  Note that other groups may also distribute
   working documents as Internet-Drafts.  The list of current Internet-
   Drafts is at http://datatracker.ietf.org/drafts/current/.

   Internet-Drafts are draft documents valid for a maximum of six months
   and may be updated, replaced, or obsoleted by other documents at any
   time.  It is inappropriate to use Internet-Drafts as reference
   material or to cite them other than as "work in progress."

   This Internet-Draft will expire on January 6, 2011.



Klensin                  Expires January 6, 2011                [Page 1]


Internet-Draft               ISD Definition                    July 2010


Copyright Notice

   Copyright (c) 2010 IETF Trust and the persons identified as the
   document authors.  All rights reserved.

   This document is subject to BCP 78 and the IETF Trust's Legal
   Provisions Relating to IETF Documents
   (http://trustee.ietf.org/license-info) in effect on the date of
   publication of this document.  Please review these documents
   carefully, as they describe your rights and restrictions with respect
   to this document.  Code Components extracted from this document must
   include Simplified BSD License text as described in Section 4.e of
   the Trust Legal Provisions and are provided without warranty as
   described in the Simplified BSD License.

   This document may contain material from IETF Documents or IETF
   Contributions published or made publicly available before November
   10, 2008.  The person(s) controlling the copyright in some of this
   material may not have granted the IETF Trust the right to allow
   modifications of such material outside the IETF Standards Process.
   Without obtaining an adequate license from the person(s) controlling
   the copyright in such materials, this document may not be modified
   outside the IETF Standards Process, and derivative works of it may
   not be created outside the IETF Standards Process, except to format
   it for publication as an RFC or to translate it into languages other
   than English.

























Klensin                  Expires January 6, 2011                [Page 2]


Internet-Draft               ISD Definition                    July 2010


Table of Contents

   1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  5
     1.1.  Status of This Version . . . . . . . . . . . . . . . . . .  5
     1.2.  Present Status in the IETF and the Role of this
           Proposal . . . . . . . . . . . . . . . . . . . . . . . . .  5
     1.3.  This Proposal and the Standards Track  . . . . . . . . . .  7
   2.  Proposal Overview  . . . . . . . . . . . . . . . . . . . . . .  8
   3.  A New Document Series  . . . . . . . . . . . . . . . . . . . . 10
   4.  Publication and Formatting . . . . . . . . . . . . . . . . . . 11
   5.  Content and Organization of an ISD Document  . . . . . . . . . 12
   6.  Requirements . . . . . . . . . . . . . . . . . . . . . . . . . 13
   7.  Change Histories . . . . . . . . . . . . . . . . . . . . . . . 15
   8.  Relation To and Future of Existing Maturity Levels . . . . . . 16
   9.  Procedure for New Standards and Associated ISDs  . . . . . . . 16
     9.1.  Replacement for RFC 2026, Section 6.1.1  . . . . . . . . . 16
     9.2.  Replacement for the third paragraph of RFC 2026,
           Section 6.1.2  . . . . . . . . . . . . . . . . . . . . . . 17
     9.3.  Insertion at the end of RFC 2026, Section 6.1.2  . . . . . 17
     9.4.  Replacement for first paragraph of RFC 2026 Section 
           6.1.3  . . . . . . . . . . . . . . . . . . . . . . . . . . 17
     9.5.  Updating of RFC 2026, Section 3.3  . . . . . . . . . . . . 18
   10. Transition and Workload Analysis . . . . . . . . . . . . . . . 18
     10.1. Transition Model for Legacy Documents  . . . . . . . . . . 18
     10.2. IESG and Community Workload  . . . . . . . . . . . . . . . 20
   11. References and Citations Involving ISDs  . . . . . . . . . . . 22
     11.1. References to ISDs or References to RFCs . . . . . . . . . 22
     11.2. References from ISD Documents  . . . . . . . . . . . . . . 22
       11.2.1.  Document References . . . . . . . . . . . . . . . . . 22
       11.2.2.  Errata and Corrections  . . . . . . . . . . . . . . . 23
     11.3. Citing an ISD  . . . . . . . . . . . . . . . . . . . . . . 23
   12. IANA Considerations  . . . . . . . . . . . . . . . . . . . . . 23
   13. Security Considerations  . . . . . . . . . . . . . . . . . . . 24
   14. Contributor  . . . . . . . . . . . . . . . . . . . . . . . . . 24
   15. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 24
   16. Changes from Previous Versions . . . . . . . . . . . . . . . . 25
   17. References . . . . . . . . . . . . . . . . . . . . . . . . . . 25
     17.1. Normative References . . . . . . . . . . . . . . . . . . . 25
     17.2. Informative References . . . . . . . . . . . . . . . . . . 26
   Appendix A.   Motivation and Historical Context  . . . . . . . . . 26
   Appendix A.1. Problem(s) . . . . . . . . . . . . . . . . . . . . . 26
   Appendix A.2. Periodic Reviews of Protocols are not Being
                 Carried Out  . . . . . . . . . . . . . . . . . . . . 28
   Appendix A.3. There is no Maintenance Team Responsible for a
                 Protocol . . . . . . . . . . . . . . . . . . . . . . 28
   Appendix A.4. Implementers and those Using Standards in
                 Procurement Do Not Know What to Reference  . . . . . 28
   Appendix A.5. A Mechanism is Needed to Supply Stable



Klensin                  Expires January 6, 2011                [Page 3]


Internet-Draft               ISD Definition                    July 2010


                 References to Standards  to other Bodies,
                 Sometimes Well Before the RFCs are Published . . . . 28
   Appendix B.   Notes on the Design  . . . . . . . . . . . . . . . . 28
   Appendix B.1. Comments, discussion notes, and proposed errata  . . 29
   Appendix B.2. Numbers versus Names . . . . . . . . . . . . . . . . 29
   Appendix B.3. Citations of Informative Material  . . . . . . . . . 29
   Appendix C.   Open Issues  . . . . . . . . . . . . . . . . . . . . 29
   Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 31











































Klensin                  Expires January 6, 2011                [Page 4]


Internet-Draft               ISD Definition                    July 2010


1.  Introduction

1.1.  Status of This Version

   [[anchor3: RFC Editor: This subsection should have been revised and
   removed to a background discussion elsewhere in the document,
   probably to the "Motivation and Historical Context" appendix, by the
   time it reaches you.]]

   The original ISD (originally "Internet Standards Documents") proposal
   was last actively discussed in the NEWTRK WG at IETF 63 in August
   2005.  Private discussions of it have continued and at least some
   people (in addition to the author(s)) seem to believe it sheds light
   on some important issues and may be a useful proposal.  So it is
   being reissued at this time, with extensive changes suggested by the
   discussions at IETF 63 and in the subsequent months and years, to
   reactivate it and contribute to a new set of discussions of these
   issues in the weeks leading up to IETF 78.

   While it started with the NEWTRK ISD proposal, this document reflects
   an expanded understanding of the problems and argues strongly for a
   comprehensive approach to them in preference to a strategy of
   applying small patches that may not provide any useful results.

1.2.  Present Status in the IETF and the Role of this Proposal

   The IETF has produced a large (and useful) body of work.  In many
   ways, the IETF has been a victim of its own success and that of the
   Internet As the standards which the IETF produces have seen wider
   deployment by parties outside of the IETF development communty, the
   system of documentation and updating within the RFC Series has caused
   some amount of confusion.  RFC 2026 [RFC2026] contains provisions
   that were expected to give the community useful information about the
   maturity level and requirement level for particular standards and to
   identify sets of documents that conceptually made up a single
   standard.  Some of those provisions have been used too little in the
   last decade or so to make them consistently useful; others have
   proven to have insufficient granularity.

   The "STD" label is described as part of the Internet Standards
   Process [RFC2026].  It identifies a subseries of the RFC series, with
   their numbers being assigned when documents are published as Internet
   Standards.  The purpose and organization of the STD series is defined
   in more detail in the formal introduction to that collection
   [RFC1311].  Beyond those brief statements, the organization of the
   series has largely been a matter of oral tradition.  Documents are
   formally treated as independent of each other unless they are
   associated with a single "STD" number.  Those numbers do not convey



Klensin                  Expires January 6, 2011                [Page 5]


Internet-Draft               ISD Definition                    July 2010


   nearly as much information as needed and that is only in part because
   they are assigned only to Full Standards.  Even at the Full Standard
   level, many of the grouping decisions have been made as part of the
   RFC indexing process, rather than explicitly by the IESG as part of
   the standards process and some may be controversial.  RFC 1311,
   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 not
   published them in a consistent way -- several documents that
   rationally fall into that category have been published as BCPs
   instead).

   This document provides mechanisms for an audit trail 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 the
   three standards track maturity levels defined in RFC 2026 (Proposed,
   Draft, and Internet Standard).  If either the number of names for
   those levels change in the future, the need for effective and
   descriptive grouping mechanism and narrative descriptions of status
   will not change.



Klensin                  Expires January 6, 2011                [Page 6]


Internet-Draft               ISD Definition                    July 2010


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

   Early 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.
   [[anchor5: Note in Draft: this section needs updating.  If those
   examples are still needed, they will need to be updated.]]

1.3.  This Proposal and the Standards Track

   This document is, explicitly, a proposal for changes to the IETF
   Standards Track and associated procedures, not a proposal for, e.g.,
   a supplemental document series with informational and perhaps
   informal value.  If approved, it would

   o  Eliminate and replace the STD numbering series with a formal
      mechanism for identifying standards that is more suited to today's
      realities and IETF procedures.

   o  Change the rigid sequencing of the RFC 2026 standards maturity
      level category levels and the "downreferencing" problem discussed
      in several contexts [RFC3967] [RFC4897] to a more flexible
      arrangement in which the relationships among various documents
      could be explained, rather than just being assigned simple and
      often somewhat inappropriate categories.

   o  Improve on the use of the "Obsoletes" and "Updates" categories,
      which are used inconsistently in many cases (leading to confusion
      and periodic debates about what they mean), with a mechanism for
      systematic description and finer classification.

   o  Provide an alternate mechanism for expressing the properties of
      "Applicability Statements" (AS) and recommendations for use (the
      "requirement levels" of Section 3.3 of RFC 2026) without
      eliminating the availability of formal ASs as an alternate model.

   o  Eliminate the use of the BCP category for Applicability Statements
      and other information about the status of standards-track
      documents, including any implementation or interoperability
      reports that are published as RFCs.  The BCP category would remain
      available for its other purposes.

   o  Change the IETF's current environment in which RFC numbers are the
      general identifier used for standards.  Instead, RFC numbers would
      return to their original role as serial document identifiers.
      That would both help clarify the role of those numbers (without



Klensin                  Expires January 6, 2011                [Page 7]


Internet-Draft               ISD Definition                    July 2010


      subjecting the community to the trauma of replace them) and to
      significantly improve on the problem of confusion between "RFC"
      and "Standard".

   [[anchor7: The changes are significant enough that, were this
   document approved either in text or just as a series of concepts,
   such approval should almost certainly be immediately followed by
   revision and replacement of RFC 2026.  The document is, however,
   written as an update to RFC 2026 on the assumption that no
   fundamental change is being made to the role of the IESG with regard
   to, e.g., approval of standards.  Were such changes made, the
   document would need to be updated although perhaps not
   significantly.]]

   [[If approved]] This document updates 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 and 4897 on references.  It obsoletes the description of the STD
   document series in RFC 1311.


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.  It also specifies
   that, for trivial cases --standards whose specification consists of
   only a single RFC, that are at the first level ("Proposed") with no
   need for narrative history or additional explanations-- an ISD number
   might identify the RFC itself rather than a separate ISD document.
   The documents would be managed under the direction of the IESG as
   part of the standards-specification process.  In general, they would
   not be 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 numbers be assigned when specifications enter
   the formal standards track (Proposed Standard under the model
   described in RFC 2026), or at IESG discretion, earlier, that actual
   documents be created as needed, and that the documents be used to
   track maturation, applicability recommendations, and history of those
   specifications.

   To aid in transition and reduce the likelihood of time-wasting
   bureaucracy, separate ISD documents are optional for simple
   specifications at the entry level to the standards track (i.e.,
   "Proposed Standards").  In those cases, the ISD number will simply
   identify an individual RFC.

   When separate ISD documents are created, this specification outlines



Klensin                  Expires January 6, 2011                [Page 8]


Internet-Draft               ISD Definition                    July 2010


   the format of those documents and variations on it.  That format is
   different from the format of protocol specification documents and the
   RFC series generally [RFC2223] [RFC2223bis].

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

   Because these documents can be linked to documents at any stage of
   development, ISD identifying information can be created at any time
   the IESG concludes that is appropriate.  In particular, if a stable
   identifier for a standard is needed, e.g., for referencing by another
   organization, an ISD may be created and an identifier assigned before
   RFC publication and either before or after formal Protocol Actions
   are taken on some or all of the associated base RFC documents.
   Agreements on the circumstances under which that would be appropriate
   are not the subject of this document.

   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 ISD documents.  If an ISD document is created, the starting point
   and minimum descriptive and qualifying text for new standards will be



Klensin                  Expires January 6, 2011                [Page 9]


Internet-Draft               ISD Definition                    July 2010


   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
   determines whether the document should become part of an existing
   group of standards or starts a new one.  If it is new, it causes a
   new Internet Standard number ("ISD number") and name ("ISD name") to
   be assigned to it.  If multiple, related, specifications are approved
   at the same time, they may be assigned the same ISD number and name.
   More broadly, the ISD will be the basis of the Standards Action
   itself: For standards-track, and standards-track-related, documents,
   the ISD itself is the subject of an IETF Last Call, carrying with it
   the normatively-referenced documents.  The ISD and those documents
   are approved together or not at all (see Section 9).  Multi-draft
   Last Calls have become common in recent years, so this does not
   require new mechanisms.

   Assignment of an ISD number and name, and assignment of a
   specification to it, usually 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 name and number.

   When documents are introduced into, or advanced on, the standards
   track, this specification anticipates that preparation (or revision)
   of the relevant ISD document will be the responsibility of the WG
   (for WG-produced documents) or document authors (for other types of
   submissions) but leaves it to the IESG to work out and adapt
   procedures as they find appropriate and efficient.

   Advancement of a document on the standards track, publication of
   applicability statements, other issues of sufficient and substantive
   importance to require alerting implementers or the community will
   also result in modifications to the relevant ISD document.  Errata
   and corrections to existing RFCs will require incorporation into the
   ISD and IETF Last Call only if the IESG concludes that they are
   sufficiently important to justify that level of determination and
   reporting of community consensus.  The existing errata mechanism will
   be unchanged for more ordinary changes.  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 even from
   Experimental to Proposed) by changing the ISD document (or issuing a
   new ISD document) to identify the new level and include any relevant



Klensin                  Expires January 6, 2011               [Page 10]


Internet-Draft               ISD Definition                    July 2010


   notes as an alternative to modifying the relevant RFC text and
   issuing new RFCs.

   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, or a method of easily and
   accurately generating such histories (see Section 7) 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 of an ISD will be XML, conforming to an
   appropriate and IESG-designated schema.  For archival and external
   reference purposes, the formal archival form of the ISD will be ASCII
   text generated from the XML.  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
   as Internet-Drafts.  Such posting will generally be required in
   conjunction with Last Calls, especially for documents that replace or
   update others, 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.

   As mentioned above, 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 generally not expected to be synchronized.



Klensin                  Expires January 6, 2011               [Page 11]


Internet-Draft               ISD Definition                    July 2010


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 as described in Section 6.  As with RFCs, additional
   sections may be included as needed and appropriate.  Note that ISDs
   don't have authors: the RFCs have authors, but, because an ISD is a
   summary of IETF consensus, if there were an "author" of an ISD, it
   would always be "IETF" or perhaps the IESG or Secretariat.

   The items shown with asterisks are required if an actual ISD document
   is produced at all (see Section 6).

   The Working Group or individual that prepares an ISD draft prior to
   initiation of an IETF Last Call is expected to supply the information
   described below.  The IESG may, as part of Standards Track
   processing, modify that material, perhaps as the result of the Last
   Call process or to include additional information about, or
   qualifications on, an approval action.


   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



Klensin                  Expires January 6, 2011               [Page 12]


Internet-Draft               ISD Definition                    July 2010


      normatively-referenced RFCs are intended to replace earlier, more
      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, directly or indirectly, 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.  See Section 7 for
      further discussion.


6.  Requirements

   The intention of this specification is to require ISDs only when they
   provide enough significant information to be worth the effort and to
   make them optional (and discouraged) otherwise.  Consequently:

   1.  If a specification at Proposed Standard consists of a single
       document and the IESG or WG sees no need to attach additional
       information or comments, no separate ISD document is needed and
       the ISD number will point simply to the RFC.  This approach
       should be appropriate for a large fraction of the existing
       Proposed Standards until such time as they are revised or
       updated.

   2.  If an existing specification consists of several documents bound
       together in some obvious way (such as an existing assignment of a
       STD number), the ISD by default will consist only of the required



Klensin                  Expires January 6, 2011               [Page 13]


Internet-Draft               ISD Definition                    July 2010


       information identified above, including a list of RFCs.

       Historical note: This is a degenerate case that should be
       generated automatically, essentially equivalent to the "Set of
       RFC Documents" (SRD) proposal made during the NEWTRK effort
       [SRD-Proposal].

   3.  It may be appropriate to generate a separate ISD document if the
       IESG wishes to add annotation material or make information in a
       Protocol Action statement or evaluation record more easily
       available to readers than has been traditional for RFCs.  Whether
       to do this or not is at the discretion of the IESG although,
       obviously, the IESG may delegate the work of generating the text
       to someone else, e.g., a document shepherd or WG Chair.

   4.  It may be appropriate to generate a separate ISD document when a
       new specification updates or replaces an older one in a way that
       may make a description the relationships beneficial to the
       reader.  Whether to provide that information in an ISD document,
       as part of the text of the new document, or in some combination
       should be at the discretion of the author, WG, or IESG.

   5.  When a standards-track specification is published that consists
       of several separate RFCs that logically form parts of a single
       document, either an ISD document is required to describe the
       relationships or one of the documents must contain a "road map"
       with that information, ideally with a skeletal ISD document that
       points to it.

   6.  An ISD document is required for a specification newly being moved
       to Draft Standard or otherwise requiring an interoperability
       report.  The ISD should either contain a summary of, and link to,
       that interoperability report or be a way to publish its content.

   7.  An ISD document is required for a specification newly being moved
       to Internet Standard or otherwise requiring a analysis of
       deployment and utility.  The ISD should either contain a summary
       of, and link to, such a report or the report itself.

   8.  An ISD document is required to support Applicability Statement or
       "requirements" level information for a technical specification
       when that information does not appear in the technical
       specification document itself.  The ISD document may either
       contain the relevant information or provide a pointer to an RFC
       that contains it.

   9.  An ISD document is required if a substantive error is discovered
       in the document of a specification, a decision is made to not



Klensin                  Expires January 6, 2011               [Page 14]


Internet-Draft               ISD Definition                    July 2010


       reissue the specification, and it is necessary to document
       consensus agreement about the correction.  This provision does
       not replace the "RFC Errata" system for less critical changes or
       corrections.

   In summary, while ISD numbers are assigned any time documents enter
   the standards track (and retroactively to documents on the standards
   track when this specification is adopted), ISD documents are optional
   for any existing specification and for new specifications at the
   level now known as "Proposed Standard" unless the document involves
   complex relationships.  They are required for new documents for which
   interoperability reports or deployment and utility analyses are
   required (in today's vocabulary, documents moving to "Draft Standard"
   or "Internet Standard").  They are optional for all other standards-
   track specifications but strongly recommended, especially for new (or
   newly-revised) documents when their use would add clarity.

   The level of detail required in those ISD documents should be
   determined by good sense and the balance between more information,
   timeliness, and resources.  In general, more information is better,
   but timely documents completed within resource constraints are also
   better.  Because the documents are an integral part of standards-
   track specifications, the required judgments are left to the IESG as
   the evaluator of community consensus.


7.  Change Histories

   A goal for the ISD concept --highly desirable but not required-- is
   to be able to have someone using a standard for reference or
   procurement purposes to be able to identify the exact status and
   content of that standard at any particular time.  The desire for a
   "history" section above reflects that goal, not a desire to
   specifically identify changes that are not substantive.  If "history"
   information is supplied, the requirement could be realized in any of
   several ways, including, in no particular order:


   1.  Retaining an explicit thread of previous versions of the ISD and
       keeping those documents permanently and easily available.

   2.  Using carefully-designed XML markup to identify changes and
       permit generating either the current ISD document or a snapshot
       as of any particular date by an appropriate directive.

   3.  Including an explicit narrative history in the ISD itself, with
       only the current version being considered relevant.




Klensin                  Expires January 6, 2011               [Page 15]


Internet-Draft               ISD Definition                    July 2010


   Of course, there may be other possibilities and those listed above
   are not mutually-exclusive.


8.  Relation To and Future of Existing Maturity Levels

   This document is written on the assumption that the Maturity Levels
   described in RFC 2026 will remain unchanged and that, with respect to
   those levels, ISDs will simply be a recording and referencing
   mechanism for the relevant interoperability and deployment and
   utility reports.  However, once sufficient experience has been
   accumulated with ISDs and the system is working smoothly, the IETF
   may consider whether to retire the formal Maturity Levels entirely in
   favor of ISDs containing one or both of those reports and decoupling
   document updates for documentation quality from advancement in
   maturity level.


9.  Procedure for New Standards and Associated ISDs

   This document changes the Standards-track processing model of RFC
   2026 to reflect these new ISD numbers and, where appropriate, ISD
   documents.  The spirit of the 2026 model is not changed although
   introduction of ISDs may evolve into such changes in the future (see
   Section 8).

9.1.  Replacement for RFC 2026, Section 6.1.1

   Initiation of Action

   A specification that is intended to enter or advance in the Internet
   standards track shall be described in a draft ISD document unless it
   is a standalone single-document specification with no prior ISD
   document entering the standard track at the first ("Proposed
   Standard") level, in which case preparation of a draft ISD document
   is at the discretion of the author, any relevant WG, and the
   responsible Area Director.  Any draft ISD document will update any
   previous ISD document for the same base standard.  It will contain
   normative references to the RFCs and other specifications that define
   the details of the standard, including explanatory text for any
   changes or qualifications.  Such a draft ISD document shall be posted
   as an Internet-Draft (see section 2.2 of RFC 2026) even if the
   underlying RFCs have not changed since their publication.  It shall
   remain as an Internet-Draft for a period of time, not less than two
   weeks, to permit useful community review, after which a
   recommendation for action may be initiated.

   A standards action is initiated by a recommendation by the IETF



Klensin                  Expires January 6, 2011               [Page 16]


Internet-Draft               ISD Definition                    July 2010


   Working group responsible for a specification to its Area Director,
   copied to the IETF Secretariat or, in the case of a specification not
   associated with a Working Group, a recommendation by an individual to
   the IESG.

9.2.  Replacement for the third paragraph of RFC 2026, Section 6.1.2

   The IESG will send notice to the IETF of the pending IESG
   consideration of the document(s) to permit a final review by the
   general Internet community.  This "Last-Call" notification shall be
   via electronic mail to the IETF Announce mailing list.  The Last-Call
   will cover the text of any relevant documents and materials including
   the text of the draft ISD document if one exists, noting especially
   those documents that have changed or that otherwise deserve special
   consideration by the community.  Comments on a Last-Call shall be
   accepted from anyone, and should be sent as directed in the Last-Call
   announcement.

9.3.  Insertion at the end of RFC 2026, Section 6.1.2

   If, as a result of the Last-Call, the IESG determines that revisions
   or modifications are needed, it may request that the submitter modify
   either the underlying specification document(s) or the text
   describing them in the ISD, as it deems appropriate.

   [[Note in draft: We anticipate that some fraction of the document
   adjustments that are now handled by notes from the IESG to the RFC
   Editor, especially those that document restrictions on the use or
   applicability of protocols, will be handled by adjusting ISD text
   instead.  However, this provision is designed primarily to avoid
   holding up the processing of a new specification that modifies an
   existing standard with Last Call comments about the text that
   describes the existing standard.  (It may be useful to edit and
   retain some portion of this note in the final version of this
   document.)]]

9.4.  Replacement for first paragraph of RFC 2026 Section 6.1.3

   If a standards action is approved, the IESG may incorporate any
   Protocol Action text into the ISD document if one exists (and, may,
   at its discretion, generate an ISD document to record that Protocol
   Action text) and publishes it (updating or superceding any previous
   version), using mechanisms of its choice.  An ISD number is assigned
   to the specification at the time of the Protocol Action if one had
   not be assigned earlier.  The IESG also sends a notice to the RFC
   Editor to publish any new or revised specifications as RFCs.  The ISD
   document, if one is generated, will be issued at the same time as the
   Protocol Action and will reference new or revised technical



Klensin                  Expires January 6, 2011               [Page 17]


Internet-Draft               ISD Definition                    July 2010


   specifications in their Internet-Draft form until the RFC(s) are
   actually published, at which point the ISD document will be updated
   as an administrative procedure (i.e., without a requirement for a
   further Last-Call or IESG action).  Any documents previously posted
   as Internet-Drafts shall be removed from the Internet-Drafts
   directory when they are published in ISD document or RFC form.  All
   Protocol Action notices, and notices sent to the RFC Editor or IETF
   administrative entities, in conjunction with a Standards Action shall
   be copied to the IETF.

9.5.  Updating of RFC 2026, Section 3.3

   Section 3.3 of RFC 2026 specifies Requirement and recommendation
   levels for standards-track documents.  It, too, will need updating in
   the light of provisions associated with how those concepts can be
   expressed in ISDs and, in particular, for Applicability Statements
   that are embedded in an ISD rather than being published as separate
   RFCs.  However, the intent should be clear from this document and
   that updating should probably be performed as part of a complete
   review and rewrite of RFC 2026, rather than being "Updated" by
   inclusion in this document.

   [[Note in Draft: A review of the rest of section 6.1.3 and all of 6.2
   through 6.4 of RFC 2026 indicates that they are ripe for updating.
   Since most of the reasons for that are unrelated to this document,
   proposed revisions are not included here.  However, any revision of
   6.2, 6.3, or 6.4 should clarify the difference between revising an
   ISD document and revising the underlying RFCs, favoring the former
   when possible for smaller changes.  The procedures outlined in those
   sections are not affected by this document; only the particular
   specifications being referenced or changes are (and that only in some
   cases).]]


10.  Transition and Workload Analysis

10.1.  Transition Model for Legacy Documents

   Obviously, we now have many full Internet Standards, with STD numbers
   assigned and packaging defined by those numbers, that are not
   associated with ISD 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 and a large number of
   documents for which interoperability reports and deployment analyses
   are not readily available.  Some of those documents should almost
   certainly be bound to existing packages defined by STD numbers.  If
   this process is not bootstrapped by issuing at least ISD numbers for
   those documents, it probably won't work.  So the following approach,



Klensin                  Expires January 6, 2011               [Page 18]


Internet-Draft               ISD Definition                    July 2010


   which can be applied more less mechanically, is suggested:


   o  Alter the templates for the RFC Index and similar documents to
      contain provisions for an ISD reference element

   o  For all documents now identified as Standards Track, and for non-
      procedural BCPs, insert an indication that an ISD document is, or
      may be, pending.  Depending on IESG decisions and available of
      resources within the community, some standards-track RFCs, and
      hence the associated standards, might remain in "ISD pending"
      state for an extended period.

   o  For each existing STD number, assign a name or acronym and, unless
      the STD number applies to a single RFC, create a prototype ISD
      document.  Reuse of the STD numbers as ISD numbers would save some
      time and avoid some confusion, but such binding is not required
      (see Section 4).  For documents that have been assigned STD
      numbers, 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.  These prototype documents should be
      populated with the list of RFCs now associated with the STD
      number.  All of them should be identified as Internet Standards.
      Again, prototype ISD documents are not required for Internet
      Standards defined by a single RFC unless someone prepares such a
      document and the IESG concludes that it is desirable for clarity.

   o  For each existing Proposed or Draft Standard, assign an ISD name
      and number.  Exceptions should be made and documents grouped (and
      an ISD document generated for the group) when it is obvious and
      uncontroversial that several documents belong together and someone
      can be found to do the work.
      [[anchor16: It is noted, without necessarily making a
      recommendation, that grouping has historically been performed by
      the RFC Editor rather than the IESG and that the assignments have
      usually been considered reasonable (no categorization system will
      ever satisfy everyone all of the time).  If resources are
      available within the RFC Editor function, having the RFC Editor
      perform that role might be an appropriate way to move forward with
      existing standards-track documents, resources and priorities
      permitting.]]

      In the interest of a smooth and rapid transition, ISD documents
      should generally be generated for legacy documents only when the
      base RFCs are revised or some other reason (e.g., a substantive
      correction requiring documentation of consensus for the change or
      creation of an interoperability report) exists.  It would defeat
      the intent of this proposal if creation of ISD documents became a



Klensin                  Expires January 6, 2011               [Page 19]


Internet-Draft               ISD Definition                    July 2010


      priority in its own right, competing with other IETF work.

   o  Where ISD template documents are created, for both the existing
      full standards and for documents associated with RFCs at a lower
      maturity level, omit any applicability, errata, or similar
      sections but include, for convenience and non-normatively, links
      to the RFC Editor's errata page where applicable.

   o  Again for all of these template documents, omit the History
      section or populate it with a note to the effect that the Standard
      existed before the relevant date and the document is initialized
      as of that date.

   o  It will be important to preserve the STD numbers and index
      indefinitely, because some references exist to them.  However,
      that list will not be expanded, i.e., STD numbers will not be
      assigned to new documents.  Similarly, no further BCP numbers will
      be assigned to protocol specifications or operational BCP
      documents that supplement technical specifications; those
      documents are expected to be absorbed into, or referenced from,
      the ISD series.  IETF Procedural BCPs and BCPs that specify best
      technical or operational practices independent of particular
      technical specifications that define protocols are not covered in
      this document.

10.2.  IESG and Community Workload

   During the review of the NEWTRK document that preceeded this one,
   some people argued that creating this sort of document series is
   additional work for the IESG.  That should not be the case in
   practice, especially with changes incorporated into this
   specification to make ISD documents optional in many circumstances.
   Even when the IESG or others decide to create ISD documents and
   include extensive background or historical information in them, 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, ISD documents
   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.  Or, especially for simple specifications at Proposed Standard,
   it can choose to dispense with an ISD document entirely.  When a



Klensin                  Expires January 6, 2011               [Page 20]


Internet-Draft               ISD Definition                    July 2010


   document is being advanced and requires, e.g., an interoperability
   report, if a WG or individual submitter responsible for creating or
   updating the specification cannot cannot come up with an appropriate
   title and abstract/brief description to capture that report in an ISD
   document, 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
   standards track (including non-procedural BCPs), responsibility for
   advising on whether the standards-track document will require a new
   ISD number or should become part of an existing ISD and for either
   demonstrating that an ISD document is not needed or for preparing a
   draft of a new or revised ISD and lies with the relevant WG or other
   submitter.  The IESG will issue a Last Call that includes any
   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 text
   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.

   Where they exist and are used, ISD documents are 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.




Klensin                  Expires January 6, 2011               [Page 21]


Internet-Draft               ISD Definition                    July 2010


   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.


11.  References and Citations Involving ISDs

11.1.  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 Internet Standards, a specific STD
   number (in an attempt to get "the most current version").  For other
   than full standards, the RFC numbers were the only choice.  Except
   for providing stable numbers mechanism for referencing all standards-
   track specifications, not just 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 ISD (and hence a
   Standard) 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.2.  References from ISD Documents

11.2.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 base documents must be standards-track
   technical specifications or operational or Applicability Statement
   BCPs (i.e., not IETF Process BCPs [RFC2026] or other types of
   documents).  All references to base documents are, essentially by
   definition, normative and must follow the traditional rules of the
   RFC Editor for stability of references [RFC2223] [RFC2223bis] and
   subsequent modifications for IETF Track documents [RFC3967]
   [RFC4897].  However, an ISD may reference, informationally, any



Klensin                  Expires January 6, 2011               [Page 22]


Internet-Draft               ISD Definition                    July 2010


   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.
   Underlying RFCs associated with complete (non-template) ISD documents
   are no longer considered to have such maturity levels.

11.2.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
   of the previous subsection.

11.3.  Citing an ISD

   [[anchor21: Note in Draft: As this document progresses, this
   subsection should be reviewed and updated as needed by the RFC Series
   Editor (RSE) and applicable Citation Committees.]]

   Once ISD numbers become available for a given IETF-produced Standard,
   references to those standards are expected to take one of the
   following forms, depending on the needs of the authors and the
   standards of the publication in which the reference appears.


   1.  Internet Engineering Task Force (IETF), ISD-TITLE (Internet
       Standard ISD NNNN), as of YYYY.MM.DD

   2.  Internet Engineering Task Force (IETF), "ISD-TITLE" (Internet
       Standard ISD NNNN), as of YYYY.MM.DD, specifically as described
       in RFC-AUTHOR, "RFC-TITLE", RFC NNNN, DATE.

   The substitutions for the capitalized strings should be obvious.  If
   an RFC reference appears, as in the second form, it may be repeated
   for each relevant RFC.  URI references to document locations and the
   ISSN for the RFC Series may be added if required (or permitted by
   author preference) by the relevant publication.


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



Klensin                  Expires January 6, 2011               [Page 23]


Internet-Draft               ISD Definition                    July 2010


   descriptions of various registries to refer to ISD numbers, rather
   than RFC numbers, as the definitions or authority for those
   registries.  See also Section 10.2.


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


14.  Contributor

   John A Loughney served as co-editor of the predecessor document
   developed by the NEWTRK WG.  While there are parts of this version
   with which he might disagree and for which he bears no
   responsibility, it would have been impossible without his text and
   other contributions.


15.  Acknowledgements

   The general ideas described here have been discussed on and off for
   several years, but had never been turned into public documents prior
   to the work of the NEWTRK WG around 2005.  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 ones 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.

   Despite favorable treatment from the NEWTRK WG, the IESG concluded in
   the last half of 2005 and first half of 2006 that the proposal would



Klensin                  Expires January 6, 2011               [Page 24]


Internet-Draft               ISD Definition                    July 2010


   result in too much additional work for its members (there were also
   some other considerations) and declined to let the community consider
   the work.  Without IESG backing, there was little likelihood or
   either clear community consensus or of successful implementation, so
   the work was dropped along with other NEWTRK efforts.  Several of the
   participants in the WG believe that the IESG's conclusion was in
   error and that, one some transition period was over, the ISD proposal
   might actually reduce IESG workload.  In any event, this draft
   reflects several comments and ideas developed during those
   discussions; the efforts of both the IESG at the time and the
   community are greatly appreciated.

   This version is based upon, and succeeds, the NEWTRK Working Group
   draft, draft-ietf-newtrk-repurposing-isd, and includes much of its
   text.  Contributions from the many discussions and participants in
   that WG are gratefully acknowledged.


16.  Changes from Previous Versions

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


   Version 00  This version of the document is the successor to
      draft-ietf-newtrk-repurposing-isd-04, posted in March 2006.
      Anyone interested in long-term change history should refer to that
      draft.

      The NEWTRK document focused on replacing the STD and BCP numbers
      with a more general and narrative approach.  The 2010 version of
      the specification explicitly expands the standards track part of
      that change into the basis for a comprehensive overhaul of the
      "maturity level" and "requirements level" mechanisms and drops the
      connection to BCPs.  Section 1.4 of the NEWTRK document on
      "Concepts, Generality, and Specificity" has been removed.


17.  References

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



Klensin                  Expires January 6, 2011               [Page 25]


Internet-Draft               ISD Definition                    July 2010


   [RFC4897]  Klensin, J. and S. Hartman, "Handling Normative References
              to Standards-Track Documents", BCP 97, RFC 4897,
              June 2007.

17.2.  Informative References

   [ISD-Examples-Process]
              Bradner, S., "Sample ISD for the IETF Standards Process",
              draft-ietf-newtrk-sample-isd-00 (work in progress),
              October 2004.

   [ISD-Examples1]
              Klensin, J., "Internet Standards Documentation (ISDs) -
              Examples", draft-ietf-newtrk-sample-isd-00 (work in
              progress), 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.

   [RFC2223bis]
              RFC Editor, "RFC Style Guide", November 2008,
              <http://www.rfc-editor.org/styleguide.html>.

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

   [SRD-Proposal]
              Otis, D. and J. Leslie, "XML structure for Set of RFC
              Descriptors", October 2005, <https://datatracker.ietf.org/
              doc/draft-otis-newtrk-rfc-set/>.


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





Klensin                  Expires January 6, 2011               [Page 26]


Internet-Draft               ISD Definition                    July 2010


   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 takes the position that many of the problems identified
   about are inherent in the design of the current standards track and
   its relevance to many protocols in the contemporary world and
   suggests that a comprehensive revision is necessary.  We discuss the
   problems identified in more detail below.




Klensin                  Expires January 6, 2011               [Page 27]


Internet-Draft               ISD Definition                    July 2010


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 A.4.  Implementers and those Using Standards in Procurement Do
               Not Know What to Reference

   [[anchor34: ??? ... to be supplied ???]]

Appendix A.5.  A Mechanism is Needed to Supply Stable References to
               Standards  to other Bodies, Sometimes Well Before the
               RFCs are Published

   [[anchor36: ??? ... to be supplied ???]]


Appendix B.  Notes on the Design

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

   [[anchor38: Note in Draft: the list that follows has not yet been
   updated from the NEWTRK version and may not be consistent with the
   normative part of the text.  It may be best to just delete it before



Klensin                  Expires January 6, 2011               [Page 28]


Internet-Draft               ISD Definition                    July 2010


   publication.]]

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

   If it makes sense to the community to have an archive of comments,
   discussion, or proposed errata on the documents, that is fine.  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.

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


Appendix C.  Open Issues

   [[anchor43: Note in Draft: the list that follows has not yet been
   updated from the NEWTRK version.  It may not be consistent with the
   normative part of the text: that text resolves some of the issues and
   makes others irrelevant.  It may be best to just delete it before



Klensin                  Expires January 6, 2011               [Page 29]


Internet-Draft               ISD Definition                    July 2010


   publication.]]

   The following issues are still open, or were raised too late in the
   editing cycle to be addressed in this draft.


   ISD Authors

      The introduction to Section 5 indicates that ISDs do not have
      authors and that any author, editor, or contributor information
      should be put into an Acknowledgements or Contributors section.  A
      recent suggestion was made on the NEWTRK mailing list to the
      effect that listing authorship might motivate people to create
      these documents, especially for standards-track documents that
      existed prior to the introduction of ISDs.  The arguments against
      this remain that (i) the possibility that giving ISDs authors
      would detract from credit for the authors and editors of the
      substantive (normally RFC) documents themselves and (ii) that the
      responsible "author" for an ISD should properly be the IETF
      itself.  But this issue needs to be resolved.


   Level of Specification

      The authors of this document, with what appears to be the general
      agreement of the NEWTRK WG, deliberately did not specify a number
      of details, preferring instead to give the IESG the option of
      making choices it found comfortable and adjusting those choices as
      experience developed.  It is clear, at least to the authors, that
      ISDs will not succeed unless they have enthusiastic IESG support,
      and quibbling about essentially arbitrary details is not a good
      way to obtain that support or to determine whether it exists.
      However, it is probable that the community and the IESG will
      discover some topics that should be specified in precise detail
      and others that should be specified in even less detail than now
      appears above.  This item is inserted here as a placeholder to
      note that the question of level of detail is still, intentionally,
      unresolved.


   Strawman details

      This draft specification contains details in Section 9,
      Section 11.3 and elsewhere that need to be checked and verified as
      what is wanted.  Much of that burden falls more appropriately on
      the IESG than on the community.





Klensin                  Expires January 6, 2011               [Page 30]


Internet-Draft               ISD Definition                    July 2010


   Additional rationale

      In addition, this draft contains several notes in draft that
      explain tentative design choices.  Those will be moved to the
      appropriate appendix, or, if appropriate, dropped, in the next
      draft.  Having them inline now would appear to facilitate
      efficient review.


Author's Address

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

   Phone: +1 617 245 1457
   Email: john-ietf@jck.com

































Klensin                  Expires January 6, 2011               [Page 31]


Html markup produced by rfcmarkup 1.129b, available from https://tools.ietf.org/tools/rfcmarkup/