Network Working Group J. Klensin Internet-Draft J. Loughney Expires: September 13, 2005 March 12, 2005 Internet Standards Documentation (ISDs) draft-ietf-newtrk-repurposing-isd-02.txt Status of this Memo This document is an Internet-Draft and is subject to all provisions of Section 3 of RFC 3667. By submitting this Internet-Draft, each author represents that any applicable patent or other IPR claims of which he or she is aware have been or will be disclosed, and any of which he or she become aware will be disclosed, in accordance with RFC 3668. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet-Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt. The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. This Internet-Draft will expire on September 13, 2005. Copyright Notice Copyright (C) The Internet Society (2005). Abstract It has been observed that the current IETF standard designations, STD nnnn and BCP nnnn designation, have not worked well. Problems have been found when one of them is used either as a stable reference for external specifications or as a combined reference for multiple documents linked together into a single document. This document proposes two changes to these designations. The first of these changes would create a new document series and assign a new number Klensin & Loughney Expires September 13, 2005 [Page 1] Internet-Draft Internet Standards Documentation (ISDs) March 2005 and acronym to a specification when it enters the first level of the Standards Track (or is first designated as a BCP). The second would migrate the concept of STDs and BCPs numbering of RFCs into actual documents that detail what they identify, their publication information and their change history. The document also specifies a set of minor standards process changes to accommodate and integrate the new style of doing things that is represented by the new document series. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Proposal Overview . . . . . . . . . . . . . . . . . . . . . 4 3. A New Document Series . . . . . . . . . . . . . . . . . . . 5 4. Publication and Formatting . . . . . . . . . . . . . . . . . 6 5. Content and Organization of an ISD Document . . . . . . . . 7 6. Transition . . . . . . . . . . . . . . . . . . . . . . . . . 8 7. Operational Issues . . . . . . . . . . . . . . . . . . . . . 9 8. References to ISDs or References to RFCs . . . . . . . . . . 10 9. References from ISDs . . . . . . . . . . . . . . . . . . . . 11 9.1 Document References . . . . . . . . . . . . . . . . . . . 11 9.2 Errata and Corrections . . . . . . . . . . . . . . . . . . 11 10. IANA Considerations . . . . . . . . . . . . . . . . . . . . 12 11. Security Considerations . . . . . . . . . . . . . . . . . . 12 12. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 12 13. Changes from Previous Versions . . . . . . . . . . . . . . . 12 14. References . . . . . . . . . . . . . . . . . . . . . . . . . 13 14.1 Normative References . . . . . . . . . . . . . . . . . . 13 14.2 Informative References . . . . . . . . . . . . . . . . . 13 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . 14 A. Motivation and Historical Context . . . . . . . . . . . . . 15 A.1 Problem(s) . . . . . . . . . . . . . . . . . . . . . . . . 15 A.2 Periodic Reviews of Protocols are not Being Carried Out . 16 A.3 There is no Maintenance Team Responsible for a Protocol . 16 B. Notes on the Design . . . . . . . . . . . . . . . . . . . . 16 B.1 Comments, discussion notes, and proposed errata . . . . . 16 B.2 Numbers versus Names . . . . . . . . . . . . . . . . . . . 17 B.3 Citations of Informative Material . . . . . . . . . . . . 17 Intellectual Property and Copyright Statements . . . . . . . 18 Klensin & Loughney Expires September 13, 2005 [Page 2] Internet-Draft Internet Standards Documentation (ISDs) March 2005 1. Introduction The IETF has produced a large (and useful) body of work. In many ways, the IETF has been a victim of its own (or at least of TCP/IP's) success. As the standards which the IETF produces see wider deployment by parties outside of the IETF, the system of documentation and updating within the IETF causes some amount of confusion. The "STD" and "BCP" labels are described in [RFC2026] as subseries of the RFC series, with their numbers being assigned when documents are published as Internet Standards or as BCPs. The purpose and organization of the STD series is defined in more detail in [RFC1311]. Beyond those brief statements, the organization of the two series and the classification of documents as either belonging together as part of a single "STD" specification or as separate, have largely been a matter of oral tradition, with more of the decisions being made as part of the RFC indexing process than explicitly by the IESG as part of the standards process. RFC1311, written before the standards process reforms of the 1992-1994 period (see, e.g., [RFC1396] and [RFC1602]), assigns responsibility for defining the content of STD documents to the IAB, but was never updated to reflect the change to IESG responsibility for the standards track. The intent has been to permit a stable reference to particular specifications and groups of documents making up a specification, a reference that survives replacement of one RFC with another, addition or deletion of RFCs from the collective specification, and so on. While the intentions are fairly clear and quite desirable, this document suggests that the system has never worked well, especially for STDs that comprise (or point to) several RFCs. There is no easily-accessible audit track that specifies which documents were part of an standard (identified by an STD number) at a particular time (which can be very important for determining what a specification that points to an STD actually means or requires). Historically, the community and the IESG have not been heavily involved in the process of organizing and grouping standards-track documents by STD number. In retrospect, some of the decisions have been, or should have been, controversial and have led to misunderstandings about what is implied by conformance to a standard. In addition, the "do not assign an STD number until the specification reaches full Internet Standard" model is unrealistic in a world in which much of the Internet runs on Proposed Standards and in which the IETF only very rarely approves and publishes "Applicability Statement" documents (and, when it does publish them, has little idea what to do with them -- several documents that rationally fall into that category have been published as BCPs instead). Klensin & Loughney Expires September 13, 2005 [Page 3] Internet-Draft Internet Standards Documentation (ISDs) March 2005 This document creates a paper track and specific "benchmark" documentation for Internet Standards. While the documents it specifies may assist in the creation of dynamic web pages, or may be linked to bug tracking systems, those are not its primary intent. The discussion and proposal that follows are written in terms of traditional standards track documents (Proposed, Draft, and Internet Standard). Whether it should also be applied to BCPs needs further review: the applicability is fairly obvious, but it is not clear whether it is necessary enough to justify the extra trouble. Appendix A describes some of the specific IETF issues, identified during 2004, that led to the development of this specification. Prototype examples of the type of documents contemplated here appear in [ISD-Examples1] and, to a lesser extent, [ISD-Examples-Process]. Those examples are just examples; they are not part of this specification or definition. [[Note in Draft (RFC Editor to remove this paragraph before publication and after setting "Updates"): This document is intended to update RFC 2026 with regard to Last Calls and how the standards process is documented, RFC 3710 with regard to the IESG's list of responsibilities and procedures, and RFC 3967 on references. It obsoletes RFC 1311 on the STD document series; that document should be moved to Historic when this one is approved. ]] 2. Proposal Overview This document proposes that a new document series be created, called Internet Standards Documents ("ISD"s) and that these be real documents, separate from the underlying RFCs. The documents would be managed under the direction of the IESG as part of the standards-specification process, rather than being simply pointers in indexes as, e.g., the STD series has been, or being the RFCs themselves with different file names or packaging. It proposes that ISD documents be created and numbers assigned when specifications enter the formal standards track (Proposed Standard under the model described in RFC 2026) and that the documents be used to track maturation, applicability recommendations, and history of those specifications. It also outlines the format of those documents, which is expected to be different from the format of protocol specification documents and the RFC series generally ([RFC2223], [rfc2223bis]) and briefly discusses a transition strategy. Debate continues in the IETF about the proper threshold for Proposed Standards with regard to both protocol quality and document quality. Part of the problem is the use of a single, unqualified, label that Klensin & Loughney Expires September 13, 2005 [Page 4] Internet-Draft Internet Standards Documentation (ISDs) March 2005 may not be a good match to all situations. The documents proposed here will allow more flexibility by permitting the IESG to attach appropriate qualifying notes as needed. For example, if the community concluded that a specification should be published as a Proposed Standard, but that potential implementers should be warned that IETF confidence in its stability was lower than usual, these documents would be an appropriate place to publish that type of evaluation. Conversely, if interoperable implementations already existed before the Proposed Standard was published, the corresponding STD document would be an appropriate place to note that fact. These documents, and documents authoritatively (normatively) referenced from them, will become, essentially, the definitions of standards. Consequently, any changes to them will occur only under IESG authority and responsibility. The IESG may, at its discretion, and with appropriate announcements to, and consultation of, the community, delegate authority for some sections to groups responsible for the ongoing maintenance of the standards, but may not relinquish responsibility for the documents themselves. However, nothing in this specification prohibits (or requires) IESG authorization of placement of links in the STD documents that point to less formal and less authoritative discussions of, or comments on, the relevant standards should they deem that appropriate. By extension from the above, the IESG will need to make determinations, ideally after creating guidelines and getting community review and assent to them, as to criteria (e.g., length, importance, degree of discussion needed) by which authoritative comments and qualifications about standards will be incorporated into the STDs documents or issued as separate RFCs. The starting point and minimum descriptive and qualifying text for new standards will be the text of the Protocol Action Notice. 3. A New Document Series When the IESG agrees to move a document onto the standards track, it either causes a new Internet Standard number ("ISD number") and name or acronym ("ISD name") to be assigned to it, or classifies it as part of an existing standard and assigns that number and name. If multiple, related, specifications are approved at the same time, they may be assigned the same ISD number and name. As those documents are published as RFCs, the RFC may (and presumably usually will) contain the standard number and name since it will constitute a stable forward reference. This assignment of an ISD number and name, and assignment of a specification to it, results in a corresponding ISD document being created or updated, as described below. Following good sense and existing precedent, the IESG may decide to include documents that are not themselves on the standards track (e.g., Klensin & Loughney Expires September 13, 2005 [Page 5] Internet-Draft Internet Standards Documentation (ISDs) March 2005 Informational documents explaining, or describing alternatives to, an agreed-upon standard) in references from a ISD document once that document is defined by the assignment of a name and number. Advancement of a document on the standards track, publication of applicability statements, notes on errata or other issues of sufficient and substantive importance to require alerting implementers or the community will also result in modifications to the relevant ISD document. It is explicitly anticipated that documents may be moved from one maturity level to another (i.e., under the current system, to Draft, Full, or Historic, or from Experimental to Proposed) by changing the ISD document to identify the new level and include any relevant notes as an alternative to modifying the relevant RFC text and issuing new RFCs (and, of course, modifying the ISD document to reflect those changes). Particular RFCs may move in and out of a ISD (except for the historical record) as one RFC replaces another. Because the ISD document is expected to contain prose, it will be possible to deal with the long-standing issues of what "updates" means by identifying the relevant sections or concepts. And, again because there is descriptive prose present, the IESG will be able to deal appropriately with the relationship between an old Full Standard and a newer document, at a lower maturity level, that is intended to replace it by specifying whatever they consider appropriate about what the implementer or other reader should look at. While RFCs are permanent, ISD documents are expected to evolve and incorporate changes over time. However, they are also expected to include explicit change histories in order to make it possible for a reader to examine a current ISD document and determine the status of the relevant standard at any particular previous time. An ISD number or name, once bound to a particular conceptual standard, is never reused for a different concept. 4. Publication and Formatting ISDs constitute an entirely new document series, to be managed directly by the IESG as part of its management of the standards process. ISDs are not to be published as part of the RFC series. The basic source format an ISD will be XML, conforming to an appropriate and IESG-designated, Document Type Definition (DTD). For archival and external reference purposes, the formal archival form of the ISD will be ASCII text. However, it is anticipated that web pages with embedded links will also be generated from the XML and made accessible from the IETF home page. Draft versions of ISDs or proposals for updating them may be posted Klensin & Loughney Expires September 13, 2005 [Page 6] Internet-Draft Internet Standards Documentation (ISDs) March 2005 as Internet-Drafts. Such posting will generally be required in conjunction with Last Calls unless the IESG devises an alternate procedure. Since current Internet-Draft format requirements are based on RFC formats and requirements, posting drafts for ISDs as Internet-Drafts may require some extensions to the Internet-Draft posting rules. ISDs will be identified by a name and the combination of a serially-assigned standard number and a date with resolution in days. The numbers for ISDs and those for STDs (see [RFC1311]) are not expected to be synchronized. 5. Content and Organization of an ISD Document An ISD document is expected to follow the general layout and formatting conventions of an RFC (because the community is familiar with them). The components listed below may appear, or are expected to appear (required materials, even if only pro-forma, are identified with asterisks). As with RFCs, additional sections may be included as needed and appropriate. Note that ISDs don't have authors: the RFCs have authors, but the "author" of an ISD would always be "IETF" (or the historical "Network Working Group") so there is no information in providing an author or editor name. A individual who had made a major contribution to the ISD document itself might be listed in an Acknowledgement or as a Contributor. Title.* It is desirable for standards to have titles as well as numbers and acronyms (names). As others have pointed out, it would make them, especially those that involve multiple RFCs, a lot easier to talk about. For example, by common usage, the "name" of an ISD might be "SMTP" with a title of "Simple Mail Transfer Protocol". Standard Acronym and Number* The ISD will be associated with both an abbreviated name or acronym that is descriptive of the standard and a standard number, the latter of which will be serially-assigned. Date.* This is the date the ISD was last updated. Everything else belongs in history or annotation. This date will specify a day, not just a month. Abstract.* As with the title, it would be good to have these for standards, describing what the whole package does and not just what individual RFCs do. Maturity, Implementations, and Applicability Level* ISDs as a whole do not have maturity levels in the traditional sense. At the same time, it is useful for the ISD to have a section that provides information about implementation, interoperability, and deployment experience. If some of the normatively-referenced RFCs are intended to replace earlier, more Klensin & Loughney Expires September 13, 2005 [Page 7] Internet-Draft Internet Standards Documentation (ISDs) March 2005 mature ones, the ISD would normally be expected to describe and explain that situation. If an ISD is retired in its entirety, no matter what maturity levels are associated with its individual documents, this entry may be "Historic" with optional additional descriptive text. RFC list.* For each RFC that is currently associated with this ISD, the name, title, document date, and maturity level most recently assigned and its date. Optionally, an abbreviated abstract, applicability comments, errata, and other notes and commentary can be associated with some or all of the RFCs. When there is a non-obvious relationship among the various documents, it should be described either here or in the applicability remarks below, as appropriate (or in a separate section, if one is required). Applicability Remarks about the standard. Any remarks about applicability that seem useful or appropriate, as authorized. Security Remarks about the standard. Any authorized remarks about the security implications or considerations of the standard that are not completely reflected in the component RFCs. History*. This section should define the entire record of changes to the definition of the documents and applicability statements that make up the standard, with dates identified. It should, in particular, identify the point at which one document superseded or updated another. 6. Transition Obviously, we now have many full Internet Standards, with STD numbers assigned and packaging defined by those numbers, that are not associated with documents as described here. We have even more documents at Proposed or Draft Standard levels that do not have either documents of this type or grouping. Some of those documents should almost certainly be bound to existing packages defined by STD numbers. If this process is not bootstrapped by issuing ISDs for those documents, it probably won't work. So the following approach, which can be applied more less mechanically, is suggested: o For each existing STD number, assign a name or acronym and create a prototype ISD document. Reuse of the STD numbers as ISD numbers would save some time and avoid some confusion. This step and the management of titles and abstracts, as discussed below, can be done from the existing std-index being maintained by the RFC Editor. o Populate that document with the list of RFCs now associated with the ISD and identify all of them as Internet Standards. o For each existing Proposed or Draft Standard, generate a template document and assign a name and number. Exceptions should be made and documents grouped when it is obvious and uncontroversial that several documents belong together and someone can be found to do Klensin & Loughney Expires September 13, 2005 [Page 8] Internet-Draft Internet Standards Documentation (ISDs) March 2005 the work. Initial assignments and drafts should be created on an area basis, preferably by directorates or specially-selected committees, coordinating with any reclassification efforts to avoid duplicate work. o Populate the title and abstract with the title and abstract of the first RFC in the series. This won't be perfect, and in some cases, won't be even close, but it is better than nothing (and _much_ better than getting stuck waiting for someone to interpret the RFCs and do a write-up. o Omit any applicability, errata, or similar sections but include, for convenience, links to the RFC Editor's errata page where applicable. o Populate the History section with a note to the effect that the Standard existed before the relevant date and the document is initialized as of that date. o As these documents are created, and to avoid having to create all of them at once, modify the official rfc-index and other indices and web pages under IETF control to indicate either the name and number of the ISD document or that the relevant document is still under construction. o It will be important to preserve the STD numbers and index for some time, perhaps indefinitely, because some references exist to them. However, it will not be necessary to expand that list. Absorbing the STD numbering space into the ISD series will further aid in locating appropriate information. 7. Operational Issues There is a case to be made that creating this sort of document series is additional work for the IESG. In practice, the authors don't believe it, at least to any significant degree. All of the relevant information is created today. It is scattered in meeting minutes and secretariat notes, protocol action notices, discussions about whether to restart WGs to deal with problems, etc. Today that information, much of it quite useful, gets lost or at least becomes quite difficult to find. Conversely, these series should reduce workload by considerably reducing the pressure to find editors to write or rewrite RFCs whose purpose is ultimately "this document is just like RFC xxxx, except that section 3.1.3 is removed to permit promoting the specification to the next maturity level". The IESG can certainly still insist on that procedure if it deems it necessary, but it should also be possible to Last Call a revised ISD that contains more or less that sentence and not touch the RFC at all. And, if a WG responsible for creating or updating an ISD can't come up with an appropriate title and abstract/brief description, we are in a kind of trouble that goes well beyond any procedural issues. For a new specification document intended to be processed onto the Klensin & Loughney Expires September 13, 2005 [Page 9] Internet-Draft Internet Standards Documentation (ISDs) March 2005 standards track (including non-procedural BCPs), responsibility for preparing a draft of a new or revised ISD and advising on whether the standards-track document will require a new ISD number or become part of an existing ISD lies with the relevant WG or other submitter. The IESG will issue a Last Call that includes the proposed ISD text along with the substantive document(s). They will then modify the ISD text as needed based on input during Last Call and internal discussions. In general, the new or revised ISD will be issued at the same time as (or replacing) the Protocol Action Notice, referencing the approved Internet-Draft and containing copies of any RFC Editor instructions. That material would then be replaced in the ISD when the relevant documents are published. The ISD document is intended to become the repository for the substantive content of Protocol Action Notices and for IESG statements and qualifications about what they are approving. This will include any "known defects" or "this must be fixed when the document is advanced to the next maturity level" statements. It is the intent of this specification that all substantive or normative changes to an ISD be the result of IETF consensus, i.e., that the change be made only after a Last Call and IESG review and approval. However, more flexibility and less formality is appropriate for at least some non-normative changes, commentary, etc. The IESG is tasked with specifying and documenting the types of changes that do not require Last Calls or IESG approval, and the processes for making those changes. This document carefully does not specify the registry mechanism for assigning new ISD numbers, nor the details of publication and repository mechanisms for the documents although it specifies some requirements for them (see Section 4). Either or both might sensibly be done by the RFC Editor (that arrangement would certainly be consistent with historical precedents), but, if only because the ISD series would be a new task for them, it seems wise to leave this question to the IETF administrative process to sort out as seems appropriate in the broad administrative context. Regardless of what organizational arrangements are responsible for updating and maintaining these documents, and in spite of their containing a cumulative change history, they should be treated as archival -- at least as archival as the RFC series. 8. References to ISDs or References to RFCs Before this proposal was generated, vendors who wished to specify what they support, and potential customers who wished to specify what they wanted to purchase, had a choice between referencing specific Klensin & Loughney Expires September 13, 2005 [Page 10] Internet-Draft Internet Standards Documentation (ISDs) March 2005 RFCs (to get precision) or, for full standards, a specific STD number (to get "the most current version"). Except for providing an "ISD" mechanism for referencing documents other than full Internet Standards, this proposal does not change either of those options: both are still free to use the existing forms. In the rare case in which a vendor is deliberately attempting to confuse its potential customers, this mechanism is not likely to help very much either. It does, however, provide a third option, which is to specify the state of an STD as of a particular date (even a date in the past or future) or within a particular date range. So, whatever the referencing issues are today, this certainly does not make them worse and almost certainly makes them better. It should also be noted that other Standardization bodies have had difficulties when referencing RFCs. It is not always clear whether an RFC or an STD should be referenced. When a reference is made, there can be problems when the RFC that is referenced becomes updated or obsoleted. 9. References from ISDs 9.1 Document References An ISD can be thought of as anchored in one of more "base documents" -- RFCs that, in combination, specify the technical content of the standard itself. These based documents must be standards-track technical specifications or operational or Applicability Statement BCPs (i.e., not IETF-process BCPs, see [Standing-Docs]). All references to base documents are, essentially by definition, normative and must follow the traditional rules of the RFC Editor for stability of references (see, e.g., [RFC2223]) as modified by [RFC3967]. However, an ISD may reference, informationally, any document or material felt to be helpful in understanding the standard or its context. References to, and discussion of, base documents may, and normally will, associate standards-track maturity levels with those documents. The underlying RFCs themselves are no longer considered to have such maturity levels. 9.2 Errata and Corrections Errata and other corrections that represent IETF consensus (i.e., based on an IESG, or IESG-delegated, determination after Last Call) are normative and identified in a way that distinguishes them from suggested errata or changes that are not known to represent IETF consensus. The latter may still be included in the ISD document as informative material under the general "felt to be helpful" provision Klensin & Loughney Expires September 13, 2005 [Page 11] Internet-Draft Internet Standards Documentation (ISDs) March 2005 of the previous section. 10. IANA Considerations This document does not anticipate any specific tasks for the IANA. However, over time, it may be desirable to review and update the descriptions of various registries to refer to ISD numbers, rather than RFC numbers, as the definitions or authority for those registries. See also Section 7. 11. Security Considerations This document specifies an administrative procedure for the IETF and hence does not raise any new issues about the security of the Internet. However, the availability of the type of document described here may provide a convenient mechanism and repository of vulnerabilities and other issues that are discovered after RFCs are issued but that do not justify updating (or for which resources are not available to update) the relevant RFC. Having an obvious place to look for those notifications and discussions for standards-track documents might enhance overall security somewhat. 12. Acknowledgements The general ideas described here have been discussed on and off for several years, but have never been turned into public documents. Thanks are due to several generations of IAB and IESG members and to RFC Editor staff for helping to clarify the ideas and to identify some variants that would or would not work. The ideas in this specific presentation are, of course, those of the author and are one with which some of the contributors might disagree. Pekka Savola provided extensive and very useful comments on a preliminary version of the initial draft. Harald Alvestrand, Bob Braden, and several others made comments on the first posted draft that resulted in important clarifications. Discussions during and after IETF 60 led to further changes and the consolidation of the previous relevant documents. Bob Braden suggested not trying to reuse the term "STD", and provided new term "ISD". Additional helpful comments and corrections were provided by Pekka Savola and Scott Bradner. 13. Changes from Previous Versions [[Note in Draft: This section is to be removed before RFC publication]] Klensin & Loughney Expires September 13, 2005 [Page 12] Internet-Draft Internet Standards Documentation (ISDs) March 2005 Version 00. This version replaces and consolidates the previous documents "Repurposing the STD Designation" (draft-klensin-newtrk-std-repurposing-00.txt, 6 June 2004) and "Standards, What Standards?" (draft-loughney-what-standards-01.txt, February 2004). It also includes a number of editorial clarifications and a few more details than its predecessors. The tone is still somewhat informal and conversational; if general consensus is reached on the ideas, that should be corrected, in both the text and the abstract, in a subsequent draft. Version 01. This version incorporates the changes and clarifications discussed in a meeting of the NEWTRK WG at IETF 61 (Washington, DC, USA, November 2004) and on the mailing list in the subsequent weeks. While some outstanding issues and possible issues remain, the document has been considerably tightened up and a number of previous loose ends documented. In the process, some of the conversational text in the previous versions (see above) has been edited into a more formal form. Most of the "why is this justified and being done" material has been moved to an appendix in order to facilitate eventually turning the Internet-Draft into a permanent IETF process specification. Version 02. This version incorporates the changes and clarifications discussed in the NEWTRK WG meeting at IETF 62 (Minneapolis, MN, USA, March 2005). All non-editorial "notes in draft" have been resolved, and those that discuss design choices have been removed to an appendix. 14. References 14.1 Normative References [RFC2026] Bradner, S., "The Internet Standards Process -- Revision 3", BCP 9, RFC 2026, October 1996. [RFC3967] Bush, R. and T. Narten, "Clarifying when Standards Track Documents may Refer Normatively to Documents at a Lower Level", BCP 97, RFC 3967, December 2004. 14.2 Informative References [ISD-Examples-Process] Bradner, S., "Sample ISD for the IETF Standards Process", Internet-Draft draft-ietf-newtrk-sample-isd-00, October 2004. [ISD-Examples1] Klensin, J., "Internet Standards Documentation (ISDs) - Examples", Internet-Draft draft-ietf-newtrk-sample-isd-00, Klensin & Loughney Expires September 13, 2005 [Page 13] Internet-Draft Internet Standards Documentation (ISDs) March 2005 October 2004. [RFC1311] Postel, J., "Introduction to the STD Notes", RFC 1311, March 1992. [RFC1396] Crocker, S., "The Process for Organization of Internet Standards Working Group (POISED)", RFC 1396, January 1993. [RFC1602] Huitema, C. and P. Gross, "The Internet Standards Process -- Revision 2", RFC 1602, March 1994. [RFC2223] Postel, J. and J. Reynolds, "Instructions to RFC Authors", RFC 2223, October 1997. [RFC3774] Davies, E., "IETF Problem Statement", RFC 3774, May 2004. [Standing-Docs] Klensin, J., "Standing Documents Describing IETF Processes and Operations", Internet-Draft draft-ietf-newtrk-sd-00, February 2004. [rfc2223bis] Reynolds, J. and R. Braden, "Instructions to Request for Comments (RFC) Authors", Internet-Draft draft-rfc-editor-rfc2223bis-07, August 2003. Authors' Addresses John C Klensin 1770 Massachusetts Ave, #322 Cambridge, MA 02140 USA Phone: +1 617 491 5735 Email: john-ietf@jck.com John A Loughney Itamerenkatu 11-13 Helsinki, 00180 Finland Phone: +358 5 04836242 Email: john.loughney@nokia.com Klensin & Loughney Expires September 13, 2005 [Page 14] Internet-Draft Internet Standards Documentation (ISDs) March 2005 Appendix A. Motivation and Historical Context Appendix A.1 Problem(s) The following problems are excerpted from Section 2.4 of the IETF Problem statement [RFC3774]. o Relatively few specifications are now progressed beyond Proposed Standard (PS) to Draft Standard (DS) level, and even fewer to Full Standard (FS). o There is no formal bug reporting or tracking system in place for IETF specifications. o The periodic review of protocols at PS and DS levels specified in are not being carried out, allowing protocols to persist in these lower maturity levels for extended periods of time, whereas the process would normally expect them to progress or be relegated to Historic status. o No individual or body is given the task of 'maintaining' a specification after the original WG has closed down. Specifications are generally only updated when a need for a new version is perceived. No attempt is normally made to correct bugs in the specification (whether they affect operation or not) and the specification is not updated to reflect parts of the specification that have fallen into disuse or were, in fact, never implemented. This is in part because the current procedures would require a standard to revert to the PS maturity level even when specification maintenance is carried out which can be demonstrated to have no or minimal effect on an existing protocol at DS or FS level. o Few Specifications Progress Beyond Proposed Standard. The IETF, as of late, does not have a good track record of moving protocols beyond Proposed Standard. In fact, the goal of most Working Groups is to produce a set of RFCs and then shut down. Working groups that do this are considered to have succeeded. There are only a handful of long-lived working groups, such as IPv6, whose charters include progressing standards beyond Proposed Standards. Occasionally, new working groups need to be spun up to make sense of the existing set of RFCS, such as tcpm (TCP Maintenance). o There is no Formal Bug Reporting or Tracking System. Bugs in a specification can be found at any point. There have been bugs found even in Full Standards. How do we ensure correctness in our own standards? This document does not take a stand on the issue of the relevance of the current standards track. It does note that at any given moment, a standard may be undergoing work to progress the document to another level. We discuss the problems identified in more detail below. Klensin & Loughney Expires September 13, 2005 [Page 15] Internet-Draft Internet Standards Documentation (ISDs) March 2005 Appendix A.2 Periodic Reviews of Protocols are not Being Carried Out Many protocols suffer from benign neglect. The working group charged with developing the protocol becomes dormant or is shut down. The principal authors of the specification may no longer be involved in the IETF. Further development of the protocol may even be officially discouraged. Other standards development organizations (SDOs) may consider extensions or modification to the protocols. This causes problems for parties interested in the technology, as it becomes unclear as to exactly what specifies a particular protocol. Additionally, it makes it hard to track errors in or updates to a specification or protocol. Appendix A.3 There is no Maintenance Team Responsible for a Protocol Specifications are generally only updated when a need for a new version is perceived. No attempt is normally made to correct bugs in the specification (whether they affect operation or not) and the specification is not updated to reflect parts of the specification that have fallen into disuse or were, in fact, never implemented. This is in part because the current procedures would require a standard to revert to the PS maturity level even when specification maintenance is carried out which can be demonstrated to have no or minimal effect on an existing protocol at DS or FS level. Appendix B. Notes on the Design In the process of developing this specification, several notes and comment were made about tradeoffs. Those notes appear below, essentially unedited. They are not a normative part of the specification. Appendix B.1 Comments, discussion notes, and proposed errata If makes sense to the community to have an archive of comments, discussion, or proposed errata on the documents, that is fine, and it would be useful for these documents to identify the locations of those archives. But we should be very careful that the contents of such archives are not confused with the content of the specifications unless they go through some sort of formal review and consensus process. The description of that process in the specification is deliberately open-ended and flexible. If the IESG is willing to accept and maintain formal responsibility for whatever appears in ISD documents, they could include some non-normative changes being made by, e.g., maintenance committees should the community want to move in that direction. Klensin & Loughney Expires September 13, 2005 [Page 16] Internet-Draft Internet Standards Documentation (ISDs) March 2005 Appendix B.2 Numbers versus Names There was an extended debate in the Working Group as to whether ISDs were better identified by acronyms or serial numbers. There are advantages to names or acronyms and and to numbers. The former are easier to remember as long as there are not too many of them and are usually more human friendly. The latter are very precise and language-independent. The choice between the two did not appear to be worth the amount of energy it would have taken to reach consensus, if even that were possible. Consequently, the document recommends assigning both a number and a name (acronym or other string) to each ISD. Appendix B.3 Citations of Informative Material There is discussion in Section 9.1 about the inclusion of informative (non-normative) material, but no specific guidance is given about what material is and is not appropriate, other than that it is "felt to be helpful". The apparent ambiguity is deliberate, relying on good sense and the requirement that substantive changes to ISDs must be Last Called in the IETF, rather than an attempt to make specific rules that would probably be inappropriate for some future situation. Klensin & Loughney Expires September 13, 2005 [Page 17] Internet-Draft Internet Standards Documentation (ISDs) March 2005 Intellectual Property Statement The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79. Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr. The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org. Disclaimer of Validity This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. Copyright Statement Copyright (C) The Internet Society (2005). This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights. Acknowledgment Funding for the RFC Editor function is currently provided by the Internet Society. Klensin & Loughney Expires September 13, 2005 [Page 18]