Internet Draft J. Loughney Document: draft-loughney-what-standards-01.txt Nokia Expires: August 2004 February 2004 Standards, What Standards? Status of this Memo This document is an Internet-Draft and is in full conformance with all provisions of Section 10 of RFC2026 [1]. 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. Abstract This document proposes a split between the RFC number of a specification and the label for a protocol or protocol set. The Problem Working Group identified problems with the way in which the IETF manages the document series. This document discusses some of the problems caused by the current state of affairs and suggests some improvements. Loughney Expires - August 2004 [Page 1] Standards, What Standards? February 2004 Table of Contents 1. Introduction..................................................3 1.1 The Problem(s)............................................3 2. Further Analysis of Identified Problems.......................4 2.1 Few Specifications Progress Beyond Proposed Standard......4 2.2 There is no Formal Bug Reporting or Tracking System.......4 2.3 Periodic Reviews of Protocols are not Being Carried Out...4 2.4 There is no Maintenance Team Responsible for a Protocol...5 3. Suggested Solution............................................5 3.1 Mock Example..............................................5 3.2 Open Issues...............................................6 4. Simple Example Based on an Existing Standard..................6 5. Security Considerations.......................................7 6. IANA Considerations...........................................7 References.......................................................7 Acknowledgments..................................................7 Author's Addresses...............................................7 Appendix A - A Pathological Example..............................7 Loughney Expires - August 2004 [Page 2] Standards, What Standards? February 2004 1. Introduction The IETF has produced a large (and useful) body of work. In many ways, the IETF has been a victim of its own (or at least of IP's) success. It is reasonable to expect that as standards see deployment and uses not envisioned by the original authors, bugs will be found or clarification will be needed. Additionally, as the standards with the IETF produces see wider deployment by parties outside of the IETF, the system of documentation and updating within the IETF may cause some amount of confusion. There may be different expectations of what IETF standards may mean. Vendors often implement protocols based upon drafts; a proposed standard is seen as adequate enough for ensuring interoperability; any bugs found in the specification can be handled by code updates. Other Standards Development Organizations may require Draft Standard status, at a minimum, for referencing in their documentations. Government Agencies, however, may take the standards levels literally and assume only Full Standards can be considered as true standards. Finally, the RFC numbering scheme does not lend itself for easily tracking development on a specific protocol or protocol area. There isn't any relationship between RFC numbers, so often one must rely on the RFC Editor's search engine to find all relevant standards on a specific protocol. See Appendix A for a pathological example. 1.1 The Problem(s) The following problems are excerpted from Section 2.4 of the IETF Problem statement [PROB]. 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 [1] 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. Loughney Expires - August 2004 [Page 3] Standards, What Standards? February 2004 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. This document does not take a stand on the issue of the relevance of the current standards track, but to note that in any given moment, a standard may be on-going work to progress the document. 2. Further Analysis of Identified Problems This section looks in greater detail the affects of the problems listed in section 1. Many of these issues are interlinked or compound each other. 2.1 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. 2.2 There is no Formal Bug Reporting or Tracking System Bugs in a specification can be found at any point. There have been bugs found in even in Full Standards. How do we ensure the correctness in our own standards? 2.3 Periodic Reviews of Protocols are not Being Carried Out Many protocols suffer from benign neglect. The working group charged with developing the protocol has gone dormant or 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. Loughney Expires - August 2004 [Page 4] Standards, What Standards? February 2004 Other 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 or update in a specification or protocol. 2.4 There is no Maintenance Team Responsible for a Protocol Specifications are generally only updated when a need for a new version is perceived. No attempt is normally made to correct bugs in the specification (whether they affect operation or not) and the specification is not updated to reflect parts of the specification that have fallen into disuse or were, in fact, never implemented. This is in part because the current procedures would require a standard to revert to the PS maturity level even when specification maintenance is carried out which can be demonstrated to have no or minimal effect on an existing protocol at DS or FS level. 3. Suggested Solution This document proposes a simple solution that provides a label for a specification that is separate from the RFC Number. This label should be the protocol name. This document would authorize an additional link on the IETF main page, which would provide a link to the listing of specification labels. 3.1 Mock Example In this section we provide a fictitious example, known as the Foo MIB. Note that three versions of the Foo MIB have been made RFCs 4120, 4560 and 7890. RFC 4560 was a flawed attempt to do what 7890 did, which reached wide deployment before the flaw was discovered. The specification label listing for "Ethernet MIB" could say: Standard last updated: July 1, 2004 Stable IETF 1 Mult Deployed Known tech recommend impl impl widely harmful RFC 4120 Y N Y Y Y N RFC 4560 Y N Y Y Y Y RFC 7890 Y Y Y N N N Draft-foo-bis N N Y N N N The IETF recommends deployment of RFC 4120. The IETF recommends implementation of RFC 7890. Loughney Expires - August 2004 [Page 5] Standards, What Standards? February 2004 The IETF recommends experimentation with draft-foo-bis. The IETF recommends against implementing RFC 4560. Important errata known for RFC 4120, 4560 and 7890 are: One could imagine a team or an appointed expert in charge of gathering experience with the documents. As implementation reports and deployment experience gathers, the "scorecard" - but NOT the RFCs - would be updated. Other documents, rather than referring to a specific RFC, would, when possible, refer to the protocol label. 3.2 Open Issues In order to populate the label system work, there would need to be a web location for this registry. This would require some amount of work on the IETF Secretariat's part. In addition, experts and/or maintenance teams would need to be formed. Most likely document authors and work group chairs would be possible candidates. A reasonable proposal would be to have an expert or set of experts for specific protocols appointed by Area Directors, at least in a trial phase. One should note that the IETF already has a precedent set for protocol experts in the form of IANA designated experts. A reasonable next step would be to produce a web-based example based upon this proposal. 4. Simple Example Based on an Existing Standard SCTP has been chosen because it is a relatively new protocol but also because the author is familiar with it. Stream Control Transmission Protocol Stable IETF 1 Mult Deployed Known tech recommend impl impl widely harmful RFC 2960 Y Y Y Y N N RFC 3309 Y Y Y Y N N Imp Guide [1] N N Y Y N N Add IP [2] N N Y Y N N PR-SCTP [3] N N Y Y N N [1] draft-ietf-tsvwg-sctpimpguide-10.txt Loughney Expires - August 2004 [Page 6] Standards, What Standards? February 2004 [2] draft-ietf-tsvwg-addip-sctp-08.txt [3] draft-ietf-tsvwg-prsctp-03.txt Information References: RFC 3257 Stream Control Transmission Protocol Applicability Statement RFC 3286 An Introduction to the Stream Control Transmission Protocol (SCTP) The IETF recommends implementing RFC 2960 with the updated checksum coverage documented in RFC 3309. draft-ietf-tsvwg-sctpimpguide contains updated information found during conformance tests. 5. Security Considerations This document in and of itself does not of itself have security implications. 6. IANA Considerations Currently there are no IANA implications. However, should this solution be deployed, there may be a need to link the specification label with the IANA registry for a particular protocol. References [2026] Bradner, S., "The Internet Standards Process -- Revision 3", BCP 9, RFC 2026, October 1996. Acknowledgments The author would like to thank Harald Alvestrand for making the author the 'designated expert' on this particular topic. The author wants to thank John Klensen for warning that there may be dragons ahead. Thanks to Spencer Dawkins, Jordi Palet Martinez, Keith Moore and Mike Pierce for reading & commenting. Author's Addresses John Loughney Nokia Email: john.loughney@nokia.com Appendix A - A Pathological Example Loughney Expires - August 2004 [Page 7] Standards, What Standards? February 2004 TCP has been a wildly successful protocol by any measure. One of the benefits of TCP has been that it has enabled interoperable services running on top of it, irrespective of the layers below it. This success has come at a price. For example there have been discussions on the e2e mailing list about what is TCP (http://www.postel.org/pipermail/end2end- interest/). This has resulted in a new working group being formed to, essentially, clean up the set of TCP standards. Using the RFC Editor's page, (http://www.rfc-editor.org/cgi- bin/rfcsearch.pl), my first search retured: "Based on your search of [tcp] in the Title field 93 matches were found." Then, a second search: "Based on your search of [Transmission Control Protocol] in the Title field 13 matches were found." This points to a fact that there are a large number of RFCs at least partly related to TCP. Loughney Expires - August 2004 [Page 8]