Network Working Group J. Loughney Internet-Draft Nokia Expires: September 6, 2006 S. Dawkins Futurewei March 5, 2006 A Single-Stage Standards Process draft-loughney-newtrk-one-size-fits-all-01 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 6, 2006. Copyright Notice Copyright (C) The Internet Society (2006). Abstract This document proposes several changes of principle to the Internet standards process, specifically a reduction from three stages to a single stage in the standards track. This does not effect the Informational, Experimental or BCP designations. Loughney & Dawkins Expires September 6, 2006 [Page 1] Internet-Draft Single stage March 2006 Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Stage 1: IETF-Approved Standard . . . . . . . . . . . . . . . . 4 3. No higher stages . . . . . . . . . . . . . . . . . . . . . . . 4 4. No timing rules . . . . . . . . . . . . . . . . . . . . . . . . 4 5. No 'down references' within IETF-Approved Standards . . . . . . 4 6. The STD designation, and updates . . . . . . . . . . . . . . . 4 7. Interoperability Reports . . . . . . . . . . . . . . . . . . . 5 8. Transitional arrangements . . . . . . . . . . . . . . . . . . . 5 9. Not excluded . . . . . . . . . . . . . . . . . . . . . . . . . 6 10. Housekeeping . . . . . . . . . . . . . . . . . . . . . . . . . 6 11. Security Considerations . . . . . . . . . . . . . . . . . . . . 6 12. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 7 13. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 7 14. Informative References . . . . . . . . . . . . . . . . . . . . 7 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 8 Intellectual Property and Copyright Statements . . . . . . . . . . 9 Loughney & Dawkins Expires September 6, 2006 [Page 2] Internet-Draft Single stage March 2006 1. Introduction This document proposes several changes of principle to the Internet standards process defined in [1]. The background for this proposal is the published analysis of problems in the IETF [2], various discussions in the IETF's "New IETF Standards Track Discussion" (newtrk) working group, various largely expired drafts, and the authors' personal experiences. It has little claim to originality (see Acknowledgements). The problems tackled by this proposal are those of clumsiness in the three-stage standards process, and related clumsiness in the clarity and useability of IETF standards. Additionally, this draft proposes 'truth in advertising' with respect to how the IETF manages the standardization process in most cases. Working Groups are generally chartered to develop standards and then close down once the their charter is fufilled. Only a handfull of Working Groups contain any references to progressing documents Draft or Full Standard status. The IESG does not enforce section 6.2 of [1], which states that the IESG should review the status of any standard that has not reached Internet Standard status and has remained unchanged for 24 months. This draft is deliberately short on rationale and explanation - the interested reader should study the above references and discussions carefully. Should readers require additional rationale, the authors may add text to future revisions. Additionally, a small analysis of the current status of the RFC Index shows that there are 66 Full Standards, which includes 10 that are obsoleted, resulting in 56 Full Stanards. 91 Draft Standards which includes 37 that are obsoleted, resulting in 54 Draft Standards. Finally, there are 838 proposed standards, which includes 227 that are obsoleted, resulting in 611 Proposed Standards. Ensuring that all the Proposed Standards progress up the Standards Track would seem to be a large task. During recent (March 2006) discussions, Eliot Lear did a quick review of how many RFC's have progressed along the standards track. By RFC, not by STD (obviously): Status 1999 2000 2001 2002 2003 2004 2005 ------------------------------------------------------------- PS 102 119 71 105 103 131 169 DRAFT 6 6 2 4 7 7 3 STD 3(*) 2 0 8* 3 0 1 (*) 3 in 1999 were SMIv2 6 in 2002 were SNMP Eliot commented that these "are rough based on 10 minutes of Loughney & Dawkins Expires September 6, 2006 [Page 3] Internet-Draft Single stage March 2006 scripting." These should give a quick idea of the current status of the Standards Track. 2. Stage 1: IETF-Approved Standard This is exactly as described for "Proposed Standard" in [1]. 3. No higher stages The higher stages, "Draft Standard" and "Standard", are simply abolished. These stages are achieved by so few specifications that there is no justification for keeping them, and there is nothing negative about "IETF-Approved Standard" as the final state. Should revisions be required, the document can be resubmitted as an Internet Draft and be assigned a new RFC number upon document approval. The authors note that this roughly corresponds to the current process in practice. 4. No timing rules Since there is no higher stage, all text requiring periodic reviews will be removed from the replacement for [1]. This draft is deliberately short on rationale and explanation - the interested reader should study the above references and discussions carefully. Should readers require additional rationale, the authors may add text to future revisions. 5. No 'down references' within IETF-Approved Standards Since all IETF-Approved Standards are at the same stage of maturity, there is no concept of specifications at a higher stage referencing specifications at a lower stage. (It is not proposed to allow down references to Internet-Drafts.) 6. The STD designation, and updates Presently, an STD designation and number is only given to a document (or document set) at the full Standard level. This can cause extreme confusion when a full Standard is technically obsoleted by a Proposed Standard. What is an implementer to do? What documents should be normatively referenced by other organizations? Loughney & Dawkins Expires September 6, 2006 [Page 4] Internet-Draft Single stage March 2006 One option is to simply abolish the STD designation, which is little used anyway. The alternative is to assign the STD designation (and number) to a IETF-Approved Standard document, or set of IETF-Approved Standard documents which are related. In any case, this function (assigning documents to specific STD designations) would be an IETF (WG or IESG) matter and not an RFC Editor action as today. 7. Interoperability Reports Although only a minority of IETF standards-track specifications have achieved Draft Standard or Internet Standard status, interoperability reports have been provided for specifications that have achieved this status. Knowing that a protocol specification is clear enough to allow interoperable implementations is valuable. It is not our intention to ignore valuable information. The IETF community is encouraged to continue to perform interoperability testing, and to report results for this testing. In fact, interoperability reports should be considered a sign that an Internet draft as reached a certain level of maturity, and should be considered during IETF Last call. A better automated tool and place to report these results would be required in order to ensure that protocols undergo some level of interoperability testing. At this time, interoperability reports are provided to the IESG and are available from http://www.ietf.org/IESG/implementation.html. One alternative would be to include interoperability reports as part of an ISD [3], but the current practice meets this need. Again, the authors note that the IETF does not manage or certify interoperability testing of its standards. The IETF relies on interoperability reports from the community. This document in no way changes this, it simply decouples document status from interoperability reports. There is a proposal [4] to handle in a more formal manner interop reports. This would provide a good basis to ensure a one-step standards process was effective. 8. Transitional arrangements On the day these changes enter service, all existing standards-track RFCs would be automatically reclassified as IETF-Approved Standard RFCs. Corresponding changes would be made to the RFC Index and various features of the RFC Editor site and any other RFC Loughney & Dawkins Expires September 6, 2006 [Page 5] Internet-Draft Single stage March 2006 repositories displaying the status of RFCs. If and only if the STD designation is retained, all existing STD designations will be applied as follows: 1. If the old Standard has not been obsoleted, it is now an IS with the same STD designation. 2. If the old Standard has been obsoleted, the STD designation goes to the document(s) that obsoleted it. 3. If the old Standard has been updated, the STD designation is added to the document(s) that updated it. 4. The IESG would designate a team or teams to rapidly classify all standards-track documents not assigned an STD designation by the above process into new STD designations. (If the STD designation is abolished, these steps would be unnecessary, but various cleanings up of the RFC Index and the RFC Editor web site would be needed to remove all references to STD.) 9. Not excluded The above changes have been constructed in such a way that they do not exclude the notions of WG Snapshots (drafts declared to be in a stable state by the WG), Stable Snapshots (drafts declared to be in a stable state with IESG agreement) or Internet Standards Documentation (ISDs, external descriptors of a set of RFCs as a single standard)[3]. 10. Housekeeping Obviously, [1] will need considerable editing in addition to the above changes, for example to remove the intellectual property material which is already obsolete. Also, [5], which defined the STD designation, should be obsoleted. (Even if the STD designation is retained, it should be fully described in the replacement for [1].) An unrelated housekeeping item is to clarify that, occasionally, the IESG may decide to approve a document for immediate publication as Historic (rather than Informational), when it is desired to publish it for the record but it is already overtaken by events. 11. Security Considerations This document does not directly affect the security of the Internet. Loughney & Dawkins Expires September 6, 2006 [Page 6] Internet-Draft Single stage March 2006 12. IANA Considerations This document requests no action by the IANA. 13. Acknowledgements Although this document proposes a single stage standards track, it draws heavily from previous two-stage proposals by Spencer Dawkins, Charlie Perkins, Dave Crocker, Scott Bradner, and Brian Carpenter, and discussions of those proposals in the Newtrk working group. This document was produced using the xml2rfc tool[6]. 14. Informative References [1] Bradner, S., "The Internet Standards Process -- Revision 3", BCP 9, RFC 2026, October 1996. [2] Davies, E., "IETF Problem Statement", RFC 3774, May 2004. [3] Klensin, J. and J. Loughney, "Internet Standards Documentation (ISDs)", draft-ietf-newtrk-repurposing-isd-03 (work in progress), April 2005. [4] Masinter, L., "Formalizing IETF Interoperability Reporting", draft-ietf-newtrk-interop-reports-00 (work in progress), October 2005. [5] Postel, J., "Introduction to the STD Notes", RFC 1311, March 1992. [6] Rose, M., "Writing I-Ds and RFCs using XML", RFC 2629, June 1999. Loughney & Dawkins Expires September 6, 2006 [Page 7] Internet-Draft Single stage March 2006 Authors' Addresses John Loughney Nokia Itamerenkatu 11-13 Helsinki, 00180 Finland Phone: +358504836242 Email: john.loughney@nokia.com Spencer Dawkins Futurewei Technologies 1547 Rivercrest Blvd. Allen, TX 75002 USA Phone: +1 469 229 5397 Email: spencer@mcsr-labs.org Loughney & Dawkins Expires September 6, 2006 [Page 8] Internet-Draft Single stage 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. Loughney & Dawkins Expires September 6, 2006 [Page 9]