Solutions Mailing List Spencer Dawkins INTERNET DRAFT MCSR Labs 8 October 2003 Charles E. Perkins Nokia Research Center Dave Crocker Brandenburg InternetWorking Two Stage Standardization draft-dawkins-pstmt-twostage-01.txt STATUS OF THIS MEMO This document is a submission to the Solutions Mailing List, which is not an official mailing list of the Internet Engineering Task Force, but is the best place weÆve found to discuss process change proposals. Comments should be submitted to the solutions@alvestrand.no mailing list. Distribution of this memo is unlimited. This document is an Internet-Draft and is in full conformance with all provisions of Section 10 of RFC2026. 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 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. This proposal also defines an optional, pre-standards label for use within working groups. The proposal is intended to streamline the IETF standardization process, and to provide clear benefits for each stage. 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: * 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. * 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. 1.1. The Problems Current IETF standards management has a number of harmful properties: * Our documented process isn't what we use in practice. This disparity creates many opportunities for miscommunication, which in turn can produce mistrust. * 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. * 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ö * 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. * 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 based on implementation or deployment experience, or simply because ôstandardö protocols may not used at all. Because of the delays, implementers often cannot wait for even the first formal standards track specification approval of Proposed Standard before they begin to implement. This leads to a variety of problems. * The version of the specification that is used may be immature, and may change markedly between revisions. * Different implementers may choose different revisions of the specification as a basis for development. * When a Proposed Standard needs to be revised, it can take years for the revision to be published even for very minor repairs. Then it is quite difficult for vendors and other standards organizations (i.e., the IETFÆs ôcustomersö) to know what the real protocol specification is, and they may be forced to specify known bugs as part of systems to be built, even when the bugs are well known to the ôcustomerö. * The "running code" component of the IETF culture clearly means that it is good to base a standard on implementation history. The implementation results need to be discussed and documented in order for this history to have its greatest value. 1.2. A Hybrid Solution This current proposal merges the previous one 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. Bradner essentially proposes a new label that primarily serves to move the IETF process one to the 'left' of the current labels. A concern with this proposal is that it will only buy us some time, without actually fixing any underlying problems or changing anyone's motivations to do better. It permits quicker issuance of early-stage specifications, but with significantly less review. The synthesized variant, proposed here, also adds a new label, but it also makes some changes to Proposed and it removes Draft. Mostly, it seeks to capture existing practise, with some features intended to encourage revision and progress along the track. 2. PROPOSAL -- TWO-STAGES AND A LABEL A two-stage standards process is suggested, and a new working group action is defined. The working group action is not needed in all cases before a specification is standardized, but it can be quite useful to facilitate the progress of working group documents. Draft Standard status is dropped. 2.1. Working Group Snapshot (WGS) The Working Group Snapshot (WGS) label can be affixed to an Internet-Draft, for working group synchronization. It is pointedly not an IETF standards label. Rather it is an optional part of the working group development process, permitting the working group to synchronize on a particular version of a draft. A WGS is an Internet-Draft that a) Achieves ôrough consensusö based on a Working Group Last Call b) May receive IESG comment A working group can issue a WGS at any time, and does so by notifying the IESG of their intention to issue a WGS as the *next* revision of an Internet-Draft. The IESG has up to 1 month to supply additional text that is added to an "IESG Comments" section of the document. It may not delay or veto issuance of a WGS. Therefore, IESG involvement is not for "approval" but rather to permit formal, outside comments to be affixed to the draft. The document is subject to all normal I-D rules. When a WGS specification needs more time, active effort on it will usually result in changes to the specification being needed, with a resulting new version of the document, and (possibly) another working group decision to assign it WGS status. COMMENT: This label augments the current situation with I- Ds. It imposes minimal delay, permits vendors to be better coordinated, and permits IESG review and comment. The label makes clear that the specification is a WG product, not an IETF product, and it does not imply long-term stability to the specification. The use of a non-archival version (I-D) and the resulting 9-month time limit on that version should encourage folks to revise and progress the specification. COMMENT: It is worth considering extending the I-D time- limit to 9 months. This will be more convenient for WGS documents and will have no substantive effect on other I-Ds. 2.2. Proposed Standard (PS) The IETF process would retain current Proposed Standard rules, with the following modifications: a) All specifications must have least one implementation that has been tested under the circumstances that represent its intended use. b) 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. c) PS specifications receive an STD number, or are added to an existing STD 2.3. 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. 3. FORMAL EDITING CHANGES This proposal would be put into effect by making the following formal changes to official IETF process and procedures specifications. Specifically: * Add text to the end of section 7.2 of [GUIDE], according to text provided later in this section * Delete section 4.1.3 of [STD] * Rewrite sections 4.1.1 and 4.1.2 of [STD], according to text provided later this section * Rewrite the last paragraph of section 6.2 of [STD]. * Remove references to Draft Standard from [STD] * Perform other edits required for consistency 3.1. [RFC2418- 7.2] Internet-Drafts (I-D) A working group may wish to synchronize its activities according to particular versions of its Internet-Drafts. The label "Working Group Snapshot" (WGS) may be affixed to an Internet-Draft, for this purpose. The label does not indicate that the Internet Draft is ready for widespread deployment. A WGS is an Internet-Draft that a) Achieves ôrough consensusö based on a Working Group Last Call b) May receive IESG comment A working group can issue a WGS at any time, and does so by notifying the IESG of their intention to issue a WGS as the *next* revision of an Internet-Draft. The IESG has up to 1 month to supply additional text that is added to an "IESG Comments" section of the document. It may not delay or veto issuance of a WGS. Therefore, the IESG review is not an "approval" step but rather it is a step permitting formal, outside comments to be affixed to the draft. The document is subject to all normal I-D rules, except that the time before deletion is extended to be 9 months. 3.2. [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. 3.3. [RFC2026-4.1.2] Internet Standard A specification may be elevated to the Internet Standard level, when the specification has been significantly deployed and used over the Internet. 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. 3.4. [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. 4. DISCUSSION This proposal seeks to capture, specify and refine current practise in the IETF, by making its formal labeling actions more streamlined. It defines a new label for use within working groups, 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. Because candidate specifications for Proposed Standard already frequently reflect implementation experience, making that experience be required for all specifications is deemed a minimal change. The reason for making this minimal change is to ensure that all IETF standards track documents reflect running code. One reason that specifications do not advance to Draft Standard is the considerable effort required to provide technical documentation of sufficient interoperability testing. Because the community has demonstrated such a reluctance to seek this status, it is removed. It is expected that elimination of this step, as well as the proposed adjustments to the criteria for Internet Standard, will make this label appealing to seek and to require only modest effort. The suggested scheme has labels that represent: WGS: Working group project management milestone PS: IETF-wide technical approval IS: Internet community production deployment and use Simplistically this means that WGS is the goal for working group internal coordination, PS is the goal for community technical evaluation, and IS is the goal for operations community adoption. 4.1. WGS This proposal extends the de facto status of "working group document" and the de facto occurrence of implementations based on Internet-Draft specifications, by permitting working groups to declare that a specification has achieved a developmental milestone. In particular, this will permit working group participants, and the rest of industry, to coordinate their development and testing efforts. However working group documents need to be kept formally fluid (unstable) in case major changes are needed. This is accomplished by giving the specification no formal IETF-wide status and by not publishing it as an RFC. If folks want to record the specification for posterity, even if itÆs not acceptable as a Proposed Standard, then they can issue it as an Informational RFC. Working groups are provided a formal and public means of circulating their work for technical evaluation, before it is complete. The process to achieve this is streamlined, which is balanced by imparting no IETF-wide status to the document and issuing it only through the non-archival Internet-Drafts process. 4.2. PS 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. 4.3. IS 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. 5. SECURITY CONSIDERATIONS This document contains to text with security issues, except perhaps the security of the IETF standards process. 6. 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 Normative [GUIDE] Bradner, S., "Working Group Guidelines", RFC 2418, September 1998 [STD] Bradner, S., "The Internet Standards Process -- Revision 3", RFC 2026, October 1996. 7. AUTHOR CONTACT INFORMATION Spencer Dawkins Mobile Communications and Security Research Labs 1547 Rivercrest Blvd. Allen, TX 75002 Email: spencer@mcsr-labs.org Phone: +1.214.755.3870 Charles E. Perkins Communications Systems Lab Nokia Research Center 313 Fairchild Drive Mountain View, California 94043 Email: charles.perkins@nokia.com Phone: +1.650.625.2986 Fax: +1.650.625.2502 Dave Crocker Brandenburg InternetWorking 675 Spruce Dr. Sunnyvale, CA 94086 Email: dcrocker@brandenburg.com Tel: +1.408.246.8253