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

Versions: 00 01 02 03 04                                                
Network Working Group                                         J. Klensin
Internet-Draft                                               J. Loughney
Expires: September 7, 2006                                 March 6, 2006


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

Status of this Memo

   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 becomes
   aware will be disclosed, in accordance with Section 6 of BCP 79.

   Internet-Drafts are working documents of the Internet Engineering
   Task Force (IETF), its areas, and its working groups.  Note that
   other groups may also distribute working documents as Internet-
   Drafts.

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

   The list of current Internet-Drafts can be accessed at
   http://www.ietf.org/ietf/1id-abstracts.txt.

   The list of Internet-Draft Shadow Directories can be accessed at
   http://www.ietf.org/shadow.html.

   This Internet-Draft will expire on September 7, 2006.

Copyright Notice

   Copyright (C) The Internet Society (2006).

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
   Standards Track (or is first designated as a BCP).  The second would



Klensin & Loughney      Expires September 7, 2006               [Page 1]


Internet-Draft               ISD definition                   March 2006


   migrate the concept of STDs and BCPs numbering of RFCs into actual
   documents that detail what they identify, their publication
   information and their change history.  The document also specifies a
   set of minor standards process changes to accommodate and integrate
   the new style of doing things that is represented by the new document
   series.













































Klensin & Loughney      Expires September 7, 2006               [Page 2]


Internet-Draft               ISD definition                   March 2006


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  . . . . . . . . . .  6
     1.4.  Concepts, Generalities, and Specificity  . . . . . . . . .  7
   2.  Proposal Overview  . . . . . . . . . . . . . . . . . . . . . .  8
   3.  A New Document Series  . . . . . . . . . . . . . . . . . . . .  9
   4.  Publication and Formatting . . . . . . . . . . . . . . . . . . 10
   5.  Content and Organization of an ISD Document  . . . . . . . . . 11
   6.  Change Histories . . . . . . . . . . . . . . . . . . . . . . . 12
   7.  Procedure for New Standards and Associated ISDs  . . . . . . . 13
     7.1.  Replacement for RFC 2026, Section 6.1.1  . . . . . . . . . 14
     7.2.  Replacement for the third paragraph of RFC 2026,
           Section 6.1.2  . . . . . . . . . . . . . . . . . . . . . . 14
     7.3.  Insertion at the end of RFC 2026, Section 6.1.2  . . . . . 14
     7.4.  Replacement for first paragraph of RFC 2026 Section 
           6.1.3  . . . . . . . . . . . . . . . . . . . . . . . . . . 15
     7.5.  Updating of RFC 2026, Section 3.3  . . . . . . . . . . . . 15
   8.  Transition . . . . . . . . . . . . . . . . . . . . . . . . . . 15
   9.  Operational Issues . . . . . . . . . . . . . . . . . . . . . . 17
   10. References and Citations Involving ISDs  . . . . . . . . . . . 18
     10.1. References to ISDs or References to RFCs . . . . . . . . . 18
     10.2. References from ISDs . . . . . . . . . . . . . . . . . . . 19
       10.2.1.  Document References . . . . . . . . . . . . . . . . . 19
       10.2.2.  Errata and Corrections  . . . . . . . . . . . . . . . 19
     10.3. Citing an ISD  . . . . . . . . . . . . . . . . . . . . . . 20
   11. IANA Considerations  . . . . . . . . . . . . . . . . . . . . . 20
   12. Security Considerations  . . . . . . . . . . . . . . . . . . . 20
   13. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 20
   14. Changes from Previous Versions . . . . . . . . . . . . . . . . 21
   15. References . . . . . . . . . . . . . . . . . . . . . . . . . . 22
     15.1. Normative References . . . . . . . . . . . . . . . . . . . 22
     15.2. Informative References . . . . . . . . . . . . . . . . . . 22
   Appendix A.   Motivation and Historical Context  . . . . . . . . . 23
   Appendix A.1. Problem(s) . . . . . . . . . . . . . . . . . . . . . 23
   Appendix A.2. Periodic Reviews of Protocols are not Being
                 Carried Out  . . . . . . . . . . . . . . . . . . . . 24
   Appendix A.3. There is no Maintenance Team Responsible for a
                 Protocol . . . . . . . . . . . . . . . . . . . . . . 24
   Appendix B.   Notes on the Design  . . . . . . . . . . . . . . . . 24
   Appendix B.1. Comments, discussion notes, and proposed errata  . . 24
   Appendix B.2. Numbers versus Names . . . . . . . . . . . . . . . . 25
   Appendix B.3. Citations of Informative Material  . . . . . . . . . 25
   Appendix C.   Open Issues  . . . . . . . . . . . . . . . . . . . . 25
   Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 27



Klensin & Loughney      Expires September 7, 2006               [Page 3]


Internet-Draft               ISD definition                   March 2006


   Intellectual Property and Copyright Statements . . . . . . . . . . 28


















































Klensin & Loughney      Expires September 7, 2006               [Page 4]


Internet-Draft               ISD definition                   March 2006


1.  Introduction

1.1.  Status of This Version

   This 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 some changes suggested by
   the discussions at IETF 63 and thereafter, to keep it active and part
   of any discussions about the disposition of NEWTRK and its work
   items.

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 (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 "ISD" 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).



Klensin & Loughney      Expires September 7, 2006               [Page 5]


Internet-Draft               ISD definition                   March 2006


   Historically, the community and the IESG have not been heavily
   involved in the process of organizing and grouping standards-track
   documents by STD number.  In retrospect, some of the decisions have
   been, or should have been, controversial and have led to
   misunderstandings about what is implied by conformance to a standard.
   In addition, the "do not assign an STD number until the specification
   reaches full Internet Standard" model is unrealistic in a world in
   which much of the Internet runs on Proposed Standards and in which
   the IETF only very rarely approves and publishes "Applicability
   Statement" documents (and, when it does publish them, has little idea
   what to do with them -- several documents that rationally fall into
   that category have been published as BCPs instead).

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

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

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

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

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 [RFC3967] and elsewhere to a more flexible arrangement in which
      the relationships among various documents could be explicitly
      discussed and explained, rather than just being assigned simple
      and often somewhat inappropriate categories.



Klensin & Loughney      Expires September 7, 2006               [Page 6]


Internet-Draft               ISD definition                   March 2006


   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.
   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
      subjecting the community to the trauma of replace them) and to
      significantly improve on the problem of confusion between "RFC"
      and "Standard".

   [[anchor5: 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 on the assumption that no fundamental change in 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.]]

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

1.4.  Concepts, Generalities, and Specificity

   The reader will note that the current (and earlier) drafts of this
   document are partially conceptual materials and a framework to
   stimulate discussion by the community (including the IESG) with
   details to be filled in after that discussion.  It also includes what
   are believed to be enough specific proposal details to make the
   intent and concepts clear.  This leaves the draft in a state in which
   anyone who dislikes the idea or dislikes change in general can find
   ample areas for attack: the specific details can be nit-picked to
   death because they are always other ways to do things, the places
   where several alternatives are given can be attacked because the
   authors did not select one alternative, and the conceptual material
   and principles can be attacked because they are not specific enough
   and details of, e.g., specific XML schema and templates are not



Klensin & Loughney      Expires September 7, 2006               [Page 7]


Internet-Draft               ISD definition                   March 2006


   provided.  The authors believe that, if it is possible to consider
   this radical a change to the IETF standards process at all, the
   community should first agree on the general principles and design
   ideas associated with the change and then start working out details.
   Conversely, they believe that trying to elaborate all of the details
   without general consensus about the concepts and direction is likely
   to be a waste of time.  This document is written to facilitate
   discussion that might lead to such a consensus, with details supplied
   as the beginning of proof of concept, and should, preferably, be read
   in that light.


2.  Proposal Overview

   This document proposes that a new document series be created, called
   Internet Standards Documents ("ISD"s) and that these be real
   documents, separate from the underlying RFCs.  The documents would be
   managed under the direction of the IESG as part of the standards-
   specification process, rather than being simply pointers in indexes
   as, e.g., the STD series has been, or being the RFCs themselves with
   different file names or packaging.  It proposes that ISD documents be
   created and numbers assigned when specifications enter the formal
   standards track (Proposed Standard under the model described in RFC
   2026), or at IESG discretion, earlier, 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] and briefly discusses a transition strategy.

   Debate continues in the IETF about the proper threshold for Proposed
   Standards with regard to both protocol quality and document quality.
   Part of the problem is the use of a single, unqualified, label that
   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,



Klensin & Loughney      Expires September 7, 2006               [Page 8]


Internet-Draft               ISD definition                   March 2006


   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 STDs documents or issued as separate RFCs.  The starting point
   and minimum descriptive and qualifying text for new standards will be
   the text of the Protocol Action Notice.


3.  A New Document Series

   When the IESG agrees to move a document onto the standards track, it
   either causes a new Internet Standard number ("ISD number") and name
   or acronym ("ISD name") to be assigned to it, or classifies it as
   part of an existing standard and assigns that number and name.  If
   multiple, related, specifications are approved at the same time, they
   may be assigned the same ISD number and name.  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 7).  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



Klensin & Loughney      Expires September 7, 2006               [Page 9]


Internet-Draft               ISD definition                   March 2006


   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, notes on errata or other issues of
   sufficient and substantive importance to require alerting
   implementers or the community will also result in modifications to
   the relevant ISD document.  It is explicitly anticipated that
   documents may be moved from one maturity level to another (i.e.,
   under the current system, to Draft, Full, or Historic, or from
   Experimental to Proposed) by changing the ISD document to identify
   the new level and include any relevant notes as an alternative to
   modifying the relevant RFC text and issuing new RFCs (and, of course,
   modifying the ISD document to reflect those changes).

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

   While RFCs are permanent, ISD documents are expected to evolve and
   incorporate changes over time.  However, they are also expected to
   include explicit change histories, or a method of easily and
   accurately generating such histories (see Section 6 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.



Klensin & Loughney      Expires September 7, 2006              [Page 10]


Internet-Draft               ISD definition                   March 2006


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


5.  Content and Organization of an ISD Document

   An ISD document is expected to follow the general layout and
   formatting conventions of an RFC (because the community is familiar
   with them).  The components listed below may appear, or are expected
   to appear (required materials, even if only pro-forma, are identified
   with asterisks).  As with RFCs, additional sections may be included
   as needed and appropriate.  Note that ISDs don't have authors: the
   RFCs have authors, but the "author" of an ISD would always be "IETF"
   (or the historical "Network Working Group") so there is no
   information in providing an author or editor name.  A individual who
   had made a major contribution to the ISD document itself might be
   listed in an Acknowledgement or as a Contributor.

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



Klensin & Loughney      Expires September 7, 2006              [Page 11]


Internet-Draft               ISD definition                   March 2006


   Standard Acronym and Number* The ISD will be associated with both an
      abbreviated name or acronym that is descriptive of the standard
      and a standard number, the latter of which will be serially-
      assigned.
   Date.* This is the date the ISD was last updated.  Everything else
      belongs in history or annotation.  This date will specify a day,
      not just a month.
   Abstract.* As with the title, it would be good to have these for
      standards, describing what the whole package does and not just
      what individual RFCs do.
   Maturity, Implementations, and Applicability Level*
      ISDs as a whole do not have maturity levels in the traditional
      sense.  At the same time, it is useful for the ISD to have a
      section that provides information about implementation,
      interoperability, and deployment experience.  If some of the
      normatively-referenced RFCs are intended to replace earlier, more
      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 6 for
      further discussion.


6.  Change Histories

   [[anchor9: The question of what should be in the Change History
   section, how it should be organized and presented, etc., and how
   burdensome that would become has been one of the several sources of
   controversies about ISDs.  This section is a placeholder for that



Klensin & Loughney      Expires September 7, 2006              [Page 12]


Internet-Draft               ISD definition                   March 2006


   discussion, since the ISD concept depends only on having some
   reliable method for determining history and, more important, the
   status of a particular standard at any particular present or previous
   time.  The material in the rest of the section should be read more as
   a placeholder and beginning of a discussion rather than as a
   definitive final proposal.]]

   One key goal of the ISD concept is to be able to have someone using a
   standard for reference or procurement purposes be able to identify
   the exact status and content of that standard at any particular time.
   The requirement for a "history" section above reflects that goal, not
   a desire to specifically identify changes that are not substantive.
   The "history" 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.

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


7.  Procedure for New Standards and Associated ISDs

   [[Note in Draft: This section, and some of the added details in the
   next one, are supplied as a strawman to facilitate discussion and in
   response to several complaints that the document does not contain
   sufficient detail about what is intended that the IESG can evaluate
   it.  The material below provides specific proposed changes to RFC
   2026, making it more clear what the ISD model does to the existing
   Standards Track model.  This section does not identify all of the
   changes that approval of this proposal should require to RFC 2026; as
   indicated in the Introduction, if this proposal is adopted, it should
   be followed immediately by a thorough review and replacement of RFC
   2026 itself.  Considerable changes can be made to this section, and
   those details, without changing the basic principles and concepts of
   this specification and the WG and, if appropriate, the IESG are
   encouraged to make such changes as appropriate.]]

   The current model for processing standards track documents is
   described in section 6 of [RFC2026].  In particular, section 6.1.1
   specifies the model for initiating a standards action.  This
   specification can be seen as replacing selected sections of RFC 2026



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


Internet-Draft               ISD definition                   March 2006


   with something similar to the following, using terminology developed
   above:

7.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 first be described in a draft ISD.  That draft
   will update any previous ISD 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.  That draft ISD 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, that permits useful community review, after which a
   recommendation for action may be initiated.

   A standards action is initiated by a recommendation by the IETF
   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.

7.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 both the text of the ISD and that of any documents and
   materials normatively referenced from it, 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.

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



Klensin & Loughney      Expires September 7, 2006              [Page 14]


Internet-Draft               ISD definition                   March 2006


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

7.4.  Replacement for first paragraph of RFC 2026 Section 6.1.3

   If a standards action is approved, the IESG incorporates any Protocol
   Action text into the ISD and publishes it (updating or superceding
   any previous version), using mechanisms of its choice.  It also sends
   a notice to the RFC Editor to publish any new or revised
   specification as RFCs.  The ISD will reference new or revised
   technical specifications in their Internet-Draft form until the
   RFC(s) are actually published, at which point the ISD 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 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.

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


8.  Transition

   Obviously, we now have many full Internet Standards, with STD numbers



Klensin & Loughney      Expires September 7, 2006              [Page 15]


Internet-Draft               ISD definition                   March 2006


   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  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 is 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 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.
   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. [[anchor15: 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 has
      usually been considered reasonable (no categorization system will
      ever satisfy everyone all of the time).  Having the RFC Editor
      perform that role might be an appropriate way to move forward with
      existing standards-track documents, resources and priorities
      permitting.]]  Initial assignments and drafts should be created on
      an area basis, preferably by directorates or specially-selected
      committees, coordinating with any reclassification efforts to
      avoid duplicate work.  Populate the title and abstract of these
      template documents 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).  As the IESG deems appropriate, this step may be
      deferred for some or all of the relevant RFCs until either they



Klensin & Loughney      Expires September 7, 2006              [Page 16]


Internet-Draft               ISD definition                   March 2006


      come up for revision or volunteers are found.
   o  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, 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  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 technical or operational BCP documents; those
      documents are expected to be absorbed into, or referenced from,
      the ISD series.  IETF Procedural BCPs are not covered in this
      document.


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

   For a new specification document intended to be processed onto the
   standards track (including non-procedural BCPs), responsibility for
   preparing a draft of a new or revised ISD and advising on whether the
   standards-track document will require a new ISD number or become part
   of an existing ISD lies with the relevant WG or other submitter.  The
   IESG will issue a Last Call that includes the proposed ISD text along
   with the substantive document(s).  They will then modify the ISD text
   as needed based on input during Last Call and internal discussions.



Klensin & Loughney      Expires September 7, 2006              [Page 17]


Internet-Draft               ISD definition                   March 2006


   In general, the new or revised ISD will be issued at the same time as
   (or replacing) the Protocol Action Notice, referencing the approved
   Internet-Draft and containing copies of any RFC Editor instructions.
   That material would then be replaced in the ISD when the relevant
   documents are published.

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

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

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

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


10.  References and Citations Involving ISDs

10.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 full standards, a specific STD number
   (in an attempt 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



Klensin & Loughney      Expires September 7, 2006              [Page 18]


Internet-Draft               ISD definition                   March 2006


   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.

10.2.  References from ISDs

10.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, see [Standing-Docs]).  All
   references to base documents are, essentially by definition,
   normative and must follow the traditional rules of the RFC Editor for
   stability of references (see, e.g., [RFC2223]) as modified by
   [RFC3967].  However, an ISD may reference, informationally, any
   document or material felt to be helpful in understanding the standard
   or its context.

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

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






Klensin & Loughney      Expires September 7, 2006              [Page 19]


Internet-Draft               ISD definition                   March 2006


10.3.  Citing an ISD

   Once ISDs 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.  And URI references to document locations may
   be added if required (or permitted by author preference) by the
   relevant publication.


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.


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



Klensin & Loughney      Expires September 7, 2006              [Page 20]


Internet-Draft               ISD definition                   March 2006


   specific presentation are, of course, those of the author and are one
   with which some of the contributors might disagree.  Pekka Savola
   provided extensive and very useful comments on a preliminary version
   of the initial draft.  Harald Alvestrand, Bob Braden, and several
   others made comments on the first posted draft that resulted in
   important clarifications.  Discussions during and after IETF 60 led
   to further changes and the consolidation of the previous relevant
   documents.  Bob Braden suggested not trying to reuse the term "STD",
   and provided new term "ISD".  Additional helpful comments and
   corrections were provided by Pekka Savola and Scott Bradner.


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.
   Version 01. This version incorporates the changes and clarifications
      discussed in a meeting of the NEWTRK WG at IETF 61 (Washington,
      DC, USA, November 2004) and on the mailing list in the subsequent
      weeks.  While some outstanding issues and possible issues remain,
      the document has been considerably tightened up and a number of
      previous loose ends documented.  In the process, some of the
      conversational text in the previous versions (see above) has been
      edited into a more formal form.  Most of the "why is this
      justified and being done" material has been moved to an appendix
      in order to facilitate eventually turning the Internet-Draft into
      a permanent IETF process specification.
   Version 02. This version incorporates the changes and clarifications
      discussed in the NEWTRK WG meeting at IETF 62 (Minneapolis, MN,
      USA, March 2005).  All previous non-editorial "notes in draft"
      have been resolved, and those that discuss design choices have
      been removed to appendices.
   Version 03. This version produced in response to mailing list
      comments, suggestions by a few IESG members, and a general review.
      Material has been added to specify reference formats (at least one
      of the authors regrets the fact that this was never done for RFCs)
      and to fill in various other details to facilitate discussion.  A



Klensin & Loughney      Expires September 7, 2006              [Page 21]


Internet-Draft               ISD definition                   March 2006


      new section, titled "Procedure for New Standards and Associated
      ISDs" has been added and new text has been added to the section on
      Transition, to better clarify intent and outline possible ways
      forward.  An additional new appendix has been added to list
      outstanding issues and placeholders; readers are encouraged to
      examine it before complaining about what is or is not present.


15.  References

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

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

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

   [Standing-Docs]
              Klensin, J., "Standing Documents Describing IETF Processes
              and Operations", draft-ietf-newtrk-sd-00 (work in



Klensin & Loughney      Expires September 7, 2006              [Page 22]


Internet-Draft               ISD definition                   March 2006


              progress), February 2004.


Appendix A.  Motivation and Historical Context

Appendix A.1.  Problem(s)

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

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

   This document does not take a stand on the issue of the relevance of



Klensin & Loughney      Expires September 7, 2006              [Page 23]


Internet-Draft               ISD definition                   March 2006


   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.

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

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

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

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

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


Appendix B.  Notes on the Design

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

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

   If makes sense to the community to have an archive of comments,
   discussion, or proposed errata on the documents, that is fine, and it
   would be useful for these documents to identify the locations of
   those archives.  But we should be very careful that the contents of
   such archives are not confused with the content of the specifications
   unless they go through some sort of formal review and consensus
   process.  The description of that process in the specification is
   deliberately open-ended and flexible.  If the IESG is willing to



Klensin & Loughney      Expires September 7, 2006              [Page 24]


Internet-Draft               ISD definition                   March 2006


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

   [[Note in Draft: The RFC Editor should remove this section prior to
   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



Klensin & Loughney      Expires September 7, 2006              [Page 25]


Internet-Draft               ISD definition                   March 2006


      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
      Version -02 of this draft specification contains details in
      Section 7, Section 10.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.

   Additional rationale
      In addition, draft -02 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.



















Klensin & Loughney      Expires September 7, 2006              [Page 26]


Internet-Draft               ISD definition                   March 2006


Authors' Addresses

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

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


   John A Loughney
   Itamerenkatu 11-13
   Helsinki,   00180
   Finland

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

































Klensin & Loughney      Expires September 7, 2006              [Page 27]


Internet-Draft               ISD definition                   March 2006


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 (2006).  This document is subject
   to the rights, licenses and restrictions contained in BCP 78, and
   except as set forth therein, the authors retain all their rights.


Acknowledgment

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




Klensin & Loughney      Expires September 7, 2006              [Page 28]