Network Working Group S. Dawkins Internet-Draft Inet Technologies, Inc. Expires: November 19, 2004 D. Crocker Brandenburg Internetworking C. Perkins Nokia Research Center May 21, 2004 Two Stage Standardization draft-dawkins-pstmt-twostage-02.txt Status of this Memo By submitting this Internet-Draft, I certify that any applicable patent or other IPR claims of which I am aware have been disclosed, and any of which I 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 November 19, 2004. Copyright Notice Copyright (C) The Internet Society (2004). All Rights Reserved. Abstract RFC 2026 specifies a three-stage Standards Track. As currently practiced, IETF standards track documents typically attain only the first stage. This proposal discusses the problems caused by the disparity between documented procedures and actual practice, and proposes a two-step standard track. Dawkins, et al. Expires November 19, 2004 [Page 1] Internet-Draft Two Stage Standardization May 2004 Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 2. The Problems . . . . . . . . . . . . . . . . . . . . . . . . . 4 3. A Hybrid Solution . . . . . . . . . . . . . . . . . . . . . . 5 3.1 Proposed Standard (PS) . . . . . . . . . . . . . . . . . . 5 3.2 Internet Standard (IS) . . . . . . . . . . . . . . . . . . 5 4. Formal Editing Changes . . . . . . . . . . . . . . . . . . . . 6 4.1 [RFC2026-4.1.1] Proposed Standard . . . . . . . . . . . . 6 4.2 [RFC2026-4.1.3] Internet Standard . . . . . . . . . . . . 6 4.3 [RFC2026-6.2] Advancing in the Standards Track . . . . . . 7 5. Discussion . . . . . . . . . . . . . . . . . . . . . . . . . . 8 5.1 Proposed Standard . . . . . . . . . . . . . . . . . . . . 8 5.2 Internet Standard . . . . . . . . . . . . . . . . . . . . 8 6. Relationship With Other Proposals . . . . . . . . . . . . . . 9 7. Security Considerations . . . . . . . . . . . . . . . . . . . 10 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 10 A. References . . . . . . . . . . . . . . . . . . . . . . . . . . 11 Intellectual Property and Copyright Statements . . . . . . . . 12 Dawkins, et al. Expires November 19, 2004 [Page 2] Internet-Draft Two Stage Standardization May 2004 1. Introduction RFC 2026 specifies a three-stage standards process. In theory, Proposed Standard is an entry to the standards track. In practice relatively few specifications ever advance even to the second stage, Draft Standard. Furthermore, the periodic IESG review of "immature" standards that is called for in section 6.2 of RFC 2026 seldom happens. Consequently the Internet runs on Proposed Standards, some of which are more than 25 years old, covering critical aspects of routing, congestion control, and security. This results in vulnerability at both ends of the spectrum: 1. Admission to "Proposed Standard" carries a heavier burden than originally envisioned, because responsible reviewers realize this is probably their last chance to identify problems with the specification, and try to ôthink of everything that could go wrongö. This thought exercise causes standards track work to be less timely. The protracted development cycle often causes productive engineers to lose interest and/or their opportunity to remain involved. 2. In spite of this, advancing to "Proposed Standard" still does not require implementation or deployment experience, so that the IETF's "rough consensus and running code" guiding principle isn't given a chance to be effective. Discussion venue: Online discussion of this draft should take place on the newtrk@lists.uoregon.edu mailing list. Dawkins, et al. Expires November 19, 2004 [Page 3] Internet-Draft Two Stage Standardization May 2004 2. The Problems Current IETF standards management has a number of harmful properties: 1. Our documented process isn't what we use in practice. This disparity creates opportunities for miscommunication, which in turn creates opportunities for mistrust. 2. Basing the review for Proposed Standard on a thought exercise instead of implementation and deployment experience encourages "late surprises" in the process. The desire for perfection drives reviewers to agonize over warnings and clarity. Whether a specification will be returned to a working group for rework is unpredictable, and the time required for approval is highly variable. 3. Consumers of IETF specifications have learned to disregard our formal process. RFC 2026 recommends in clear language that Draft Standard, not Proposed Standard, is the proper maturity level for widespread deployment. Any vendor that waits for this status is left far behind in the marketplace (in most cases, infinitely far behind). 4. Newcomers to the IETF have no written document to explain the ad hoc adjustments we've made to accommodate current practice. For example, the Transport Area routinely cycles proposed changes to TCP congestion control through Experimental status before approval as a Proposed Standard - a reasonable practice, but one not described in RFC 2026. 5. We are almost assured that the IETF inventory of standards contains specifications which do not reflect the corresponding protocols in use on the Internet today, because the protocols require modifications to the Proposed Standard specification based on implementation or deployment experience, or simply because some of these "standard" protocols may not be used at all. Dawkins, et al. Expires November 19, 2004 [Page 4] Internet-Draft Two Stage Standardization May 2004 3. A Hybrid Solution This current proposal merges a previous proposal by two of the current authors [DAWK], with one suggested by Scott Bradner [BRAD]. The resulting recipe for labeling IETF standards track documents includes some additional seasoning. A two-stage standards process is suggested, and Draft Standard status is dropped. 3.1 Proposed Standard (PS) The IETF process would retain current Proposed Standard rules, with the following modifications: 1. All specifications must have least one implementation that has been tested under the circumstances that represent its intended use. 2. A fixed, 36-month time limit exists for all Proposed Standards. By the end of that time the specification must be re-processed for PS status, or it must be processed for the next standards level, or it will be moved to Historic status. 3. PS specifications receive a STD number, or are added to an existing STD. 3.2 Internet Standard (IS) This is essentially the same as current full Standard. The specification must have attained a significant degree of community acceptance. In other words, it must have demonstrated that it is deployed and useful in the real world. Dawkins, et al. Expires November 19, 2004 [Page 5] Internet-Draft Two Stage Standardization May 2004 4. Formal Editing Changes This proposal would be put into effect by making the following formal changes to official IETF process and procedures specifications. Specifically: o Delete section 4.1.2 of [STD] o Rewrite sections 4.1.1 and 4.1.3 of [STD], according to text provided later this section o Rewrite the last paragraph of section 6.2 of [STD] o Remove references to Draft Standard from [STD] o Perform other edits required for consistency 4.1 [RFC2026-4.1.1] Proposed Standard The entry-level maturity for the IETF standards track is "Proposed Standard". A specific action by the IESG is required to move a specification onto the standards track at the "Proposed Standard" level. A Proposed Standard is generally stable, has resolved known design choices, is believed to be well understood, has received significant community review, and appears to enjoy enough community interest to be considered valuable. However, further experience may well result in a change of the specification before it advances, or even perhaps a retraction. Implementation experience is required for the designation of a specification as a Proposed Standard. The specification must have least one implementation that has been tested under the circumstances that represent its intended use. This experience will usually represent a strong argument in favor of designation as a Proposed Standard. A Proposed Standard should have no known technical omissions with respect to the requirements placed upon it. However, the IESG may waive this requirement in order to allow a specification to advance to the Proposed Standard state when it is considered useful and necessary (and timely) even with known technical omissions. A specification that reaches the status of Proposed Standard is assigned a number in the STD series. 4.2 [RFC2026-4.1.3] Internet Standard A specification may be elevated to the Internet Standard level, when the specification has been significantly deployed and used over the Internet. Dawkins, et al. Expires November 19, 2004 [Page 6] Internet-Draft Two Stage Standardization May 2004 An Internet Standard is characterized by a high degree of technical maturity and by a generally held belief that the specified protocol or service provides significant benefit to the Internet community. A specification that reaches the status of Internet Standard retains its STD number, but is given a new RFC number. The Working Group chair is responsible for documenting the community adoption and use of the specification. An Internet Standard must be well understood and known to be quite stable, both in its semantics and as a basis for developing an implementation. An Internet Standard is normally considered a final specification, and changes are likely to be made only to solve specific problems encountered. In most circumstances, it is reasonable for vendors to deploy implementations of Internet Standards into a disruption sensitive environment. 4.3 [RFC2026-6.2] Advancing in the Standards Track From the time it is assigned Proposed Standard status, a specification has thirty-six (36) months to achieve the status of Internet Standard. If it fails to achieve IS status, it will automatically be moved to the status of Historic. This reclassification to Historic status shall be communicated to the IETF by electronic mail to the IETF Announce mailing list. Alternatively, a specification may be renewed as Proposed Standard, if it again satisfies the usual requirements for that status. Dawkins, et al. Expires November 19, 2004 [Page 7] Internet-Draft Two Stage Standardization May 2004 5. Discussion This proposal seeks to capture, specify and refine current practise in the IETF, by making its formal labeling actions more streamlined. It makes implementation history required for all Proposed Standards, eliminates Draft Standard and calls for Internet Standard status to be based strictly upon community adoption and use. The suggested scheme uses these labels: PS: IETF-wide technical approval IS: Internet community production deployment and use Simplistically this means that PS is the goal for community technical evaluation and IS is the goal for operations community adoption. 5.1 Proposed Standard The status of Proposed Standard is the entry-level standards label, resulting from IETF-wide technical review and approval. Many Proposed Standards documents already reflect implementation and testing history, because this improves both the technical quality and the credibility of the work. The new process requires "running code" for all PS specifications. However only one implementation is required. Therefore the requirement for PS is not as demanding as the current Draft Standard. In order to keep the IETF inventory from having unused and/or buggy specifications, documents are allowed to reside at PS for only a limited time. 5.2 Internet Standard The Internet Standard label is assigned to a specification that has received the convincing demonstration of community support, namely community use. Hence the label is not assigned due to technical evaluation, but rather by virtue of demonstrated utility. Hence the requirements for achieving IS status are to have been at PS and then to receive community rough consensus that the specification has established a track record of significant usefulness to the community. Dawkins, et al. Expires November 19, 2004 [Page 8] Internet-Draft Two Stage Standardization May 2004 6. Relationship With Other Proposals This proposal touches the topic area for [LOUG], which focuses on improving our ability to describe what documents make up a standard. We like many of the ideas in [LOUG], and our proposal will significantly increase the number of STDs assigned, and will likely increase the need for [LOUG], or something like it. But [LOUG] is orthogonal to this proposal. We continue to hope for adoption of some variant of the "Working Group Snapshot"/"Stable Snap Shot" mechanism described in [BRAD] and [DAWK], but that mechanism is also orthogonal to this proposal. Dawkins, et al. Expires November 19, 2004 [Page 9] Internet-Draft Two Stage Standardization May 2004 7. Security Considerations This document contains no text with security issues, except perhaps the security of the IETF standards process. Authors' Addresses Spencer Dawkins Inet Technologies, Inc. 1547 Rivercrest Blvd. Allen, TX 75002 USA Phone: +1.469.330.3616 EMail: spencer@mcsr-labs.org Dave Crocker Brandenburg Internetworking 675 Spruce Dr. Sunnyvale, CA 94086 USA Phone: +1.408.246.8253 EMail: dcrocker@brandenburg.com Charles E. Perkins Nokia Research Center Communications Systems Lab 313 Fairchild Drive Mountain View, CA 94043 USA Phone: +1.650.625.2986 EMail: charles.perkins@nokia.com Dawkins, et al. Expires November 19, 2004 [Page 10] Internet-Draft Two Stage Standardization May 2004 Appendix A. References Informative [BRAD]: Bradner, S., "An Idea for an Alternate IETF Standards Track", draft-bradner-ietf-stds-trk-00.txt, July 2003. [DAWK]: Dawkins, S., C. E. Perkins, "Two Stage Standardization Approach", draft-dawkins-pstmt-twostage-00.txt, June 2003. [LOUG]: Loughney, J., "Standards, What Standards?", draft-loughney-what-standards-01.txt, February 2004. Normative [STD]: Bradner, S., "The Internet Standards Process -- Revision 3", RFC 2026, October 1996. Dawkins, et al. Expires November 19, 2004 [Page 11] Internet-Draft Two Stage Standardization May 2004 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 (2004). 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. Dawkins, et al. Expires November 19, 2004 [Page 12]