Network Working Group B. Carpenter (ed) Internet-Draft IBM Expires: December 11, 2006 June 9, 2006 Questions about the standards track draft-carpenter-newtrk-questions-00 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 December 11, 2006. Copyright Notice Copyright (C) The Internet Society (2006). Abstract This document sets out some thoughts about three possible directions for further work on the evolution of the IETF standards track. Its purpose is to stimulate community discussion leading to a choice between these three directions. Carpenter (ed) Expires December 11, 2006 [Page 1] Internet-Draft Questions about the standards track June 2006 Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Focus on document relationships . . . . . . . . . . . . . . . 4 3. Focus on maturity levels . . . . . . . . . . . . . . . . . . . 6 4. Discussion . . . . . . . . . . . . . . . . . . . . . . . . . . 6 5. Security Considerations . . . . . . . . . . . . . . . . . . . 7 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 7 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 7 8. Change log [RFC Editor: please remove this section] . . . . . 7 9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 8 9.1. Normative References . . . . . . . . . . . . . . . . . . . 8 9.2. Informative References . . . . . . . . . . . . . . . . . . 8 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 9 Intellectual Property and Copyright Statements . . . . . . . . . . 10 Carpenter (ed) Expires December 11, 2006 [Page 2] Internet-Draft Questions about the standards track June 2006 1. Introduction BCP 9 [RFC2026] is the current definition of the IETF standards track. For some years there has been concern in the IETF that the three stages of the standards track are no longer well adapted to current conditions. One version of the statement of this problem is in [RFC3774] which says: "2.4. Three Stage Standards Hierarchy not properly Utilized The current hierarchy of Proposed, Draft, and Full Standard maturity levels for specifications is no longer being used in the way that was envisioned when the stratification was originally proposed. In practice, the IETF currently has a one-step standards process that subverts the IETF's preference for demonstrating effectiveness through running code in multiple interoperable implementations. This compresses the process that previously allowed specifications to mature as experience was gained with actual implementations: o Relatively few specifications are now progressed beyond Proposed Standard (PS) to Draft Standard (DS) level, and even fewer to Full Standard (FS)." (etc.) It is important that the concern is not viewed only as a matter internal to the IETF. The IETF's output is of no value unless it is useful to a much wider community: implementors, vendors, service providers, and directly or indirectly for the whole user community. Therefore, the comprehensibility and useability of IETF specifications for all these stakeholders is at issue. This broad perspective, and not the IETF's internal workings, should be our first concern. This point seems to have been missed in the drafting of [RFC3774], which is rather focussed on the mechanics of the IETF, but is implicit in the IETF Mission Statement [RFC3935]. Some time ago, the New IETF Standards Track Discussion (newtrk) WG was set up to tackle this problem. Its charter says in part: "The goal of this working group is to agree on a revised IETF Standards Track, to replace the standards track described in RFC 2026. The working group will also decide on a process path forward. "The disparity between the documented IETF standards process and what is used in practice can cause confusion on the part of those people or organizations that use IETF technologies... "The goal of this working group is to agree on a revised IETF Carpenter (ed) Expires December 11, 2006 [Page 3] Internet-Draft Questions about the standards track June 2006 Standards Track, taking into consideration the above points, to replace the standards track described in RFC 2026. The working group will also decide on a process for making forward progress... "As part of a revised standards track process, the group will also explore the creation of a new series of short IESG-approved IETF documents to describe and define IETF technology standards. These documents should be able to be used to define the IETF understanding of what constituted a specific IETF standard at particular points in time." This draft will not attempt to recapitulate the history of discussions in newtrk. However, they have not yet led to a set of proposals which have both solid WG support and seem likely to rapidly reach IETF consensus and IESG approval. There are undoubtedly differences of opinion about how this situation arose and who is to blame. This draft avoids that discussion. Its goal is to set out three distinct ways forward and to stimulate constructive discussion in the community (not just in the WG) about which is the best choice for the future. The three possible ways forward are: 1. Agree that, apart from day to day efforts to improve efficiency, the problems with the existing standards track are not serious enough to justify the effort needed to make substantial changes. Conclude that [RFC3774] exagerrated the problem and we only need to make a relatively minor set of clarifications to BCP 9 [RFC2026]. 2. Focus on the issue of document relationships, or as the newtrk charter currently says "the creation of a new series of short IESG-approved IETF documents to describe and define IETF technology standards." 3. Focus on the three-stage standards track, or as the newtrk charter currently says "agree on a revised IETF Standards Track... to replace the standards track described in RFC 2026." The next two sections expand somewhat on the latter two alternatives. 2. Focus on document relationships Today, users of IETF standards have no way to unambiguously identify the complete current set of specifications for a given standard. In particular, there is no effective structured document identification scheme and no systematic approach to documenting the relationship between various parts and versions of a standard. This issue is best illustrated by example. Perhaps the most Carpenter (ed) Expires December 11, 2006 [Page 4] Internet-Draft Questions about the standards track June 2006 fundamental example is Internet Protocol version 4. Consider a hypothetical programmer on a desert island, with a computer and an electricity supply, but no information except the indexed corpus of RFCs and their external normative references. How can this programmer implement IPv4 interoperably? The index will suggest starting with RFC 791 (a Standard), updated by RFC 1349 (a Proposed Standard, i.e. of lower status, so how can it have priority?). The index then tells our programmer that RFC 1349 was obsoleted by RFC 2474 (another Proposed Standard). It then indicates that RFC 2474 was updated by RFC 3168 (Proposed Standard) and by RFC 3260 (Informational). Only by reading RFC 2474 will our programmer know to consult RFC 2475 (Informational). And nowhere in this process is she led to a much more important reference: RFC 1122 "Requirements for Internet Hosts - Communication Layers" (a Standard), which itself has been updated by RFC 1349 (again) and RFC 4379 (17 years later). We will stop the trail here, but it should be clear that our isolated programmer is unlikely to determine which RFCs she needs to follow to build an interoperable IPv4 stack. Other examples abound. What is the set of documents needed to fully specify TCP or SMTP? How does an implementor of FTP know that the appropriate reference for ASCII is RFC 20? Among more modern protocols, where does a SIP or MPLS implementor look for the complete set of relevant specifications? All is not hopeless. An IPv4 implementor who starts with RFC 1122 and its updates has a better chance than one who starts with RFC 791, at least until having to tackle DHCP. An IPv6 implementor can start with RFC 4294 (IPv6 Node Requirements). An IPv4 router implementor can start with RFC 1812 (Requirements for IP Version 4 Routers). But these are exceptions produced with great effort. In the general case, implementors need to be experts in the baroque structure of the corpus of RFCs as much as in the technology itself. This is a cost to the community, directly resulting from the IETF's piecemeal approach. At least two lines of attack on this problem have been pursued in the newtrk WG. To avoid this document interfering in newtrk's due process, only a very brief overview is given here. The first approach is known as Internet Standards Documents (ISDs). Conceptually, an ISD defines what a given standard is and which RFCs (of any maturity level) form part of that standard. In this model, an ISD equivalent of RFC 4294 would actually be *the* IPv6 standard, for example. The other, simpler, approach is an XML model for describing a set of associated RFCs, without otherwise affecting the concept of what a Carpenter (ed) Expires December 11, 2006 [Page 5] Internet-Draft Questions about the standards track June 2006 standard actually is. These documents would be known as Set of RFC Documents (SRDs). In effect, they are a boost to the existing indexing mechanisms for RFCs. Obviously, the introduction of any such mechanism would create a new document series and, in some cases, extra work. In other cases the work is already done but in other forms (e.g. Applicability Statement RFCs, or external white papers). As with any change of practice in the IETF, we would need all WG chairs, and the IESG, to sign on and to manage the necessary work. The community needs to decide whether the benefits outweigh these costs. 3. Focus on maturity levels The current three stage standards track is perceived to be under-used and to have specific problems that make some aspects of it unrealistic. (It should be noted that the number of stages in the standards track does not affect the time taken to move a draft through the approval process and to publish it, so the problem under discussion is distinct from the issues of the time taken to obtain IESG approval and RFC publication.) This is the topic that the newtrk WG tackled initially. Proposals have been made over several years for reducing the standards track from three to two stages or even one stage, for adding a WG Snapshot option, and for related clarification of the implementation report requirement (a.k.a. the "running code" requirement) for advancement in the standards track. All of these changes are relatively simple to define, but no consensus has emerged in the WG as to which of them is preferable. It seems to be generally agreed that the requirement in BCP 9 [RFC2026] for regular review of Proposed Standards and Draft Standards to see if they are ready for advancement is unrealistic, with so many such RFCs on the books. Even the exercise in de- classifying unused Proposed Standards [RFC4450] proved to be a lot of work, needing several rounds of community review. The community needs to decide whether the problems in this area are in fact grievous enough to be tackled in priority, or whether they are relatively benign. 4. Discussion Clearly a case can be made for all three of the approaches mentioned. We could shrug our shoulders and perform a maintenance update of BCP Carpenter (ed) Expires December 11, 2006 [Page 6] Internet-Draft Questions about the standards track June 2006 9 [RFC2026]. We could make a concerted effort to choose between a two-stage and a one-stage replacement for the three-stage standards track. We could set that question aside and make a concerted effort to agree on a standards-description recipe. However, experience strongly suggests that we *do* need to make a choice as a community between these three alternatives, and (assuming effort can be found) charter work on only one of them with clear goals and realistic milestone dates. It seems likely that if we choose to charter work on the standards description effort, formal adjustments to the three-stage standards track could be made at a later stage if the community wanted. It also seems likely that a maintenance update of BCP 9 will be needed anyway, but this should not be confused with the major question: do we embark first on the standards track update, the standards description effort, or neither? Community discussion is invited, in the first instance at ietf@ietf.org. 5. Security Considerations This document has no security implications for the Internet. 6. IANA Considerations This document requires no action by the IANA. 7. Acknowledgements In drafting this document, previous discussions within the IESG were reviewed. Discussion with, among others, the current newtrk Chair, Scott Bradner, and John Klensin are gratefully acknowledged. This document was produced using the xml2rfc tool[RFC2629]. 8. Change log [RFC Editor: please remove this section] draft-carpenter-newtrk-questions-00: original version, 2006-06-09 9. References Carpenter (ed) Expires December 11, 2006 [Page 7] Internet-Draft Questions about the standards track June 2006 9.1. Normative References [RFC2026] Bradner, S., "The Internet Standards Process -- Revision 3", BCP 9, RFC 2026, October 1996. 9.2. Informative References [RFC2629] Rose, M., "Writing I-Ds and RFCs using XML", RFC 2629, June 1999. [RFC3774] Davies, E., "IETF Problem Statement", RFC 3774, May 2004. [RFC3935] Alvestrand, H., "A Mission Statement for the IETF", BCP 95, RFC 3935, October 2004. [RFC4450] Lear, E. and H. Alvestrand, "Getting Rid of the Cruft: Report from an Experiment in Identifying and Reclassifying Obsolete Standards Documents", RFC 4450, March 2006. Carpenter (ed) Expires December 11, 2006 [Page 8] Internet-Draft Questions about the standards track June 2006 Author's Address Brian Carpenter (ed) IBM 8 Chemin de Blandonnet 1214 Vernier, Switzerland Email: brc@zurich.ibm.com Carpenter (ed) Expires December 11, 2006 [Page 9] Internet-Draft Questions about the standards track June 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. Carpenter (ed) Expires December 11, 2006 [Page 10]