Problem Statement WG Spencer Dawkins INTERNET DRAFT MCSR Labs 23 June 2003 Charles E. Perkins Nokia Research Center Two Stage Standardization Approach draft-dawkins-pstmt-twostage-00.txt Status of This Memo This document is a submission to the problem-statment Working Group of the Internet Engineering Task Force (IETF). Comments should be submitted to the problem-statment@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 1. Abstract This specification points out the (obvious) distinction between the RFC 2026 Standards Track as documented and the IETF standards track as practiced, and proposes a two-step standard track, with judicious use of Experimental RFCs, as an alternative. Dawkins, Perkins Expires 23 December 2003 [Page i]
Internet Draft Two Stage Standardization 23 June 2003 2. Problem Statement RFC 2026 specifies a three-stage standards process, but relatively few standards-track specifications advance beyond Proposed Standard. In practice, the IETF has a one-step standards process that is vulnerable at both ends of the spectrum: - Admission to "Proposed Standard" is a heavier burden than originally envisioned. Protocol developers may be required to specify a complete system, not an interface, in order for their specification to be approved as a Proposed Standard. - In spite of this, "Proposed Standard" still does not require implementation or deployment experience, so that the IETF's "rough consensus and running code" guiding principle has only half a chance to be effective. 3. Why Is This A Problem? In theory, Proposed Standard is an entry to the standards track. In practice, relatively few specifications even advance to Draft Standard, and the periodic IESG review of "immature" standards described in section 6.2 of RFC 2026 is unknown. The Internet runs on Proposed Standards, some of which are more than 25 years old, covering critical aspects of routing, congestion control, and security. Our use of a "one-step" standards process has these effects: - Our documented process isn't what we use in practice. This disconnect gives us many opportunities for miscommunication and mistrust, and doesn't decrease the number of times specifications are returned to working groups for rework. - Consumers of IETF specifications have learned to disregard our process. RFC 2026 recommends in clear language that Draft Standard, not Proposed Standard, is the proper maturity level for widespread deployment. If vendors believed us, they would be left far behind in the marketplace. - Newcomers to the IETF don't understand our process or 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 requirement, but one not described in RFC 2026. Dawkins, Perkins Expires 23 December 2003 [Page ii]
Internet Draft Two Stage Standardization 23 June 2003 4. One Way of Solving the Problem One way of solving the problem is to collapse the "standards track" to two steps, Proposed Specification and Internet Standard. This reflects current practice, while making advancing a Proposed Specification somewhat more attractive (since Internet Standard is only one leap away). If it were up to the proposal authors, we would "lower the bar" for Proposed Standard, to its original intent - a designation for a specification with stable text, some implementation experience, and little or no deployment experience. We recognize that we have trained industry to implement and deploy Proposed Standards, so instead we propose more active use of Experimental status specifications as a "step toward IETF standardization" that does not include the word "Standard" in the document status designation, in any form. Our suggestion is to delete section 4.1.3 of RFC 2026, and rewrite sections 4.1.1, 4.1.2, and 4.2.1 of RFC 2026, as follows (other edits are required for consistency, but these edits describe what is actually proposed): 4.1.1 Proposed Specification The entry-level maturity for the standards track is "Proposed Specification". A specific action by the IESG is required to move a specification onto the standards track at the "Proposed Specification" level. A Proposed Specification 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 might result in a change or even retraction of the specification before it advances. Neither implementation nor operational experience is absolutely required for the designation of a specification as a Proposed Specification. However, such experience is highly desirable, and will usually represent a strong argument in favor of designation as a Proposed Specification. The IESG may require implementation and/or operational experience prior to granting Proposed Specification status to a specification that materially affects the core Internet protocols or that specifies behavior that may have significant operational impact on the Internet. CEP opinion: two implementations, supporting all mandated features, should ALWAYS be REQUIRED for Proposed Specification. Dawkins, Perkins Expires 23 December 2003 [Page iii]
Internet Draft Two Stage Standardization 23 June 2003 A Proposed Specification 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 Specification state when it is considered to be useful and necessary (and timely) even with known technical omissions. Implementors should treat a Proposed Specification as an immature specification. Implementation provides experience and validates, tests, and clarifies the specification. Since the content of Proposed Specification may be changed if problems are found or better solutions are identified, deploying implementations of such standards into a disruption-sensitive environment is not recommended. 4.1.2 Internet Standard A specification may be elevated to the Internet Standard level, when - at least two independent and interoperable implementations of all protocol features, from different code bases, have been developed from the specification, and - significant implementation and successful operational experience has been obtained. For the purposes of this section, "interoperable" means to be functionally equivalent or interchangeable components of the system or process in which they are used. If patented or otherwise controlled technology is required for implementation, the separate implementations must also have resulted from separate exercise of the licensing process. An Internet Standard (which may simply be referred to as a 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 Standard is assigned a number in the STD series while retaining its RFC number. The requirement for at least two independent and interoperable implementations applies to all of the options and features of the specification. In cases in which one or more options or features have not been demonstrated in at least two interoperable implementations, the specification may advance to the Internet Standard level only if those options or features are removed. The Working Group chair is responsible for documenting the specific implementations which qualify the specification for Internet Standard Dawkins, Perkins Expires 23 December 2003 [Page iv]
Internet Draft Two Stage Standardization 23 June 2003 status along with documentation about testing of the interoperation of these implementations. The documentation must include information about the support of each of the individual options and features. This documentation should be submitted to the Area Director with the protocol action request. (see Section 6) 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 to be 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.2.1 Experimental The "Experimental" designation typically denotes a specification that is stable enough to implement, but may not be part of a complete system (yet), and may not reflect substantial implementation or deployment experience. Such a specification is published for the general advancement of the Internet technical community, including implementors who wish to obtain implementation and deployment experience with the protocol described by the specification. It can also serve as an archival record of the work, subject only to editorial considerations and to verification that there has been adequate coordination with the standards process (see below). An Experimental specification may be the output of an organized Internet research effort (e.g., a Research Group of the IRTF), an IETF Working Group, or an individual contribution. "Adequate coordination with the standards process" may take the form of publication notes pointing out problematic aspects of the specification as published, as described in section 4.2.3. Experimental specifications have NO standards-track status, although Experimental specifications may move to Proposed Specification status when they meet the criteria described in section 4.1.1 of this memo. CEP observation: A working charter could, however, have publication of an Experimental Standard to be a milestone on the way towards completion of a Proposed Specification. Protocol developers who have observed the need for deployment experience in the past are encouraged to publish Experimental specifications. Dawkins, Perkins Expires 23 December 2003 [Page v]
Internet Draft Two Stage Standardization 23 June 2003 5. If This is the Wrong Way to Solve the Problem There are other ways to design a standards track for the IETF. Instead of cycling through many proposals, the General Area Director should assign this problem (if not this draft) to a Short Term Problem Resolution working group (as proposed by draft-ietf-problem-process-01.txt). 6. Security Considerations If security continues to be the last thing protocol developers think about, Experimental specifications are likely to reflect this. This is preferable to blocking specifications while protocol developers who aren't specialists in, for instance, key exchange protocols try to come up with acceptable security considerations before a specification can be published. 7. Authors Contact Information Spencer Dawkins Mobile Communications and Security Research Labs 1547 Rivercrest Blvd. Allen, TX 75002 spencer@mcsr-labs.org Tel: +1 214 755 3870 Charles E. Perkins Communications Systems Lab Nokia Research Center 313 Fairchild Drive Mountain View, California 94043 USA Phone: +1-650 625-2986 EMail: charliep@iprg.nokia.com Fax: +1 650 625-2502 Dawkins, Perkins Expires 23 December 2003 [Page vi]