Network Working Group J. Klensin Internet-Draft Expires: August 24, 2006 S. Dawkins Futurewei Technologies February 20, 2006 Cleaning the Attic II: Promoting Marketplace-approved Standards draft-ietf-newtrk-promotion-00.txt 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 August 24, 2006. Copyright Notice Copyright (C) The Internet Society (2006). Abstract Historically, Internet Standards have been characterized by three primary criteria: the specifications are stable, implementations of them have been demonstrated to be interoperable, and they have achieved sufficient deployment to be considered useful. The IETF has developed specific rules for determining whether those criteria have been met, but the rules and their implementation have sometimes not adequately reflected those underlying criteria. The result has been Klensin & Dawkins Expires August 24, 2006 [Page 1] Internet-Draft Promoting Marketplace Standards February 2006 that the application of the rules has not resulted in STDs for all protocols that meet the underlying criteria. This document proposes a process experiment to reclassify standards-track documents whose interoperability and utility have been demonstrated by the fact of deployment and use in products being used by Internet users. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Documentation of Known Issues . . . . . . . . . . . . . . . . 4 3. Definition of the Alternate Approval Path . . . . . . . . . . 4 3.1. Enabling Document . . . . . . . . . . . . . . . . . . . . 5 3.2. Review, Processing, and Approval . . . . . . . . . . . . . 6 3.2.1. Last Call Procedure . . . . . . . . . . . . . . . . . 6 3.2.2. Preservation of Intent . . . . . . . . . . . . . . . . 7 4. The Experiment Itself . . . . . . . . . . . . . . . . . . . . 7 4.1. IESG Workload . . . . . . . . . . . . . . . . . . . . . . 7 4.2. Approval Process for this Experiment . . . . . . . . . . . 8 4.3. Discussion of Experimental Issues . . . . . . . . . . . . 8 5. Security Considerations . . . . . . . . . . . . . . . . . . . 8 6. References . . . . . . . . . . . . . . . . . . . . . . . . . . 9 6.1. Normative References . . . . . . . . . . . . . . . . . . . 9 6.2. Informative References . . . . . . . . . . . . . . . . . . 9 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 10 Intellectual Property and Copyright Statements . . . . . . . . . . 11 Klensin & Dawkins Expires August 24, 2006 [Page 2] Internet-Draft Promoting Marketplace Standards February 2006 1. Introduction Historically, Internet Standards have been characterized by three primary criteria: o the specifications are stable, o implementations of them have been demonstrated to be interoperable, and o the implementations have achieved sufficient deployment to be considered useful (historically, "useful" has been judged by decisions to implement and use the protocol, not by the subjective judgment, taste, or preferences of some group). The IETF has developed specific rules for determining whether those criteria have been met. They include the rules in [RFC2026] for each maturity level as well as provisions for regular review and timeouts of Proposed and Draft Standards. But those rules and procedures have tended to become substitutes for the criteria themselves: specifications that are widely deployed and quite mature have not been advanced because of the particular rules that have been established for their advancement and people's responses to those rules. Following in the footsteps of the recent process to reclassify obviously obsolete standards (see [decruft]), this document proposes a process experiment [RFC3933] to reclassify standards-track documents whose interoperability and utility have been demonstrated by the fact of deployment and use in products being used by Internet users. The experiment is intended as an alternate path to the one specified in RFC 2026, not a replacement for it, and is applicable only if a number of fairly stringent criteria are met. For these documents, the experiment also modifies the details of the "downreferencing" procedure specified in [RFC3967] to permit substitution of explicit comments in the enabling document. While the mechanism proposed here is fairly formal (although not as formal as that called for in RFC 2026), it is worth noting that many documents developed before the IETF came into being, or in the IETF's early days, were classified as Internet Standards by informal processes that focused more on the above criteria than on specific rules about documents and procedures such as moving through clear "Proposed" and "Draft Standard" stages. There is a clear trade-off between being practical about solving current issues versus being dogmatic about the ideal policy one might prefer in an ideal world. For protocols that have been widely deployed and proven useful via that deployment, the experiment proposed here is intended to shift the balance implied in that trade- off toward the practical. Klensin & Dawkins Expires August 24, 2006 [Page 3] Internet-Draft Promoting Marketplace Standards February 2006 2. Documentation of Known Issues Clearly, some of the specifications that qualify under the criteria outlined above would not qualify, even for Proposed Standard, under rules in use today. They lack now-required RFC sections, extensive analysis of security and internationalization issues, and so on. However, for specifications that are appropriate for consideration under this process described here, the marketplace has decided that those issues are not critical. That marketplace decision should properly take precedence over determinations made solely inside the IETF unless there is IETF community consensus that the specification and its implementations poses an actual and substantial danger (not merely a theoretical risk or a preference for a different model). If it is the consensus of the IETF community, as determined by the IESG using the usual mechanisms, that there are issues with the specification, or if the criteria applicable to RFCs moving along the conventional (i.e., RFC 2026) path are not met or now-required sections do not appear, those issues may be noted in a section of the enabling document (see Section 3.1) with the title of "Outstanding Issues". That section might note, for example, that insufficient security analysis has been done, that the protocol is not properly internationalized, that some parts of the protocol have been better tested and more widely deployed than others, that the protocol has typically been deployed at "less than Internet scale", and so on. However, if the protocol is in use and has been significantly deployed, the intent of this effort is to document those issues and move on, rather than to artificially hold it at a maturity level more appropriate to specifications that have not yet been implemented or deployed. 3. Definition of the Alternate Approval Path Any member (or group of members) of the IETF community (identified as "the proposer" below) may propose that a protocol specification be reclassified as an Internet Standard if the following minimum criteria are met. 1. The RFC documenting the specification, or the last-published RFC if there are more than one, was published at least three years earlier. 2. There is sufficient evidence of implementation, adoption, and use to make interoperability of the protocol and marketplace interest obvious. 3. The proposer is willing to generate an "enabling document" as described below. Klensin & Dawkins Expires August 24, 2006 [Page 4] Internet-Draft Promoting Marketplace Standards February 2006 Once an enabling document is generated, it will be submitted to the IAD. The IESG will initiate a review process as described below. [[anchor3: Note in Draft: The experiment proposed here is an administrative procedure for upgrading documents. While IESG review of a Last Call is a necessary part of the process, as described below, there is no requirement for a pre-Last-Call AD or IESG review of the enabling document(s).]] 3.1. Enabling Document A proposal to advance a specification to Internet Standard under the model described here is made in the form of an "enabling document". That enabling document will be an Internet-Draft suitable for eventual publication as an RFC. It MUST supply the information required below. It may either reference one or more existing RFCs that will make up the Standard, or MAY be a new document that is intended to obsolete the relevant older ones. If a new document is developed, it must reflect the spirit and intent of the experiment. Specifically, it may not introduce features that are not described in the original RFC(s) unless it clearly shows that they are as widely implemented as the original specification and have been implemented for at least three years. In addition, the description of those features must derive from text that can be shown to have been tested by independent implementations and deployment, even if it was not previously published in the RFC series. Enabling documents must contain 1. A discussion of deployment of the specification adequate to demonstrate that interoperable implementations exist and have been deployed in a reasonable variety of networks. 2. A discussion of whether or not all features of the specification are believed to be demonstrated by the deployed implementations. Features that may be less deployed and tested than others should be identified to the extent reasonably possible. 3. A discussion of how the experience with the specification relates to current requirements for standards-track advancement of protocols that are less obviously mature. Except for the first, the intent of these sections is not to require new analysis or developments, but merely to document whatever the current status actually is. As a crude example, statements such as "While no extensive internationalization analysis of this protocol has been performed and it therefore cannot be presumed to work with non-ASCII characters", or "While no extensive security analysis of this protocol has ever been performed and documented and hence some Klensin & Dawkins Expires August 24, 2006 [Page 5] Internet-Draft Promoting Marketplace Standards February 2006 caution should be used, no significant problems have appeared so far in actual practice" or "The security analysis of this protocol has not been reviewed or updated since 1991" would be considered acceptable in an enabling document. By contrast, were they to appear in a document moving along the RFC 2026 Standards Track, we presume that the actual analysis and potentially protocol changes would be required before approval. 3.2. Review, Processing, and Approval From the standpoint of document processing, enabling documents are, with the exceptions noted here, ordinary Internet Drafts submitted to the IESG for standards-track processing. They are subject to a two or four-week Last Call depending on whether they originate from WGs or from a Proposer as an individual submission. There are two important differences, one of procedure and the other of principle. 3.2.1. Last Call Procedure As mentioned above, there is no pre-Last Call AD or IESG review of enabling documents. When an enabling document is ready, and has been posted as an I-D, the proposer may request that an IETF Last Call be initiated by request to the IESG Secretary or other individual designated by the IESG and announced to the community. The person receiving the enabling document will cause the completeness of the enabling document to be checked and will verify that the three-year requirement has been met, then the Secretariat will issue the IETF Last Call. When the Last Call completes, the IESG will evaluate community consensus about the enabling document and promotion of the relevant specifications. That evaluation will follow the intent of this document (see below), i.e., the imposition of additional technical, procedural, or other requirements other than documentation of deployment and status information is considered inappropriate. The assumption of both the Last Call and IESG consensus review is that any protocol specification that has been around for several years, that has been deployed, and for which serious problem have not appeared in actual practice "in the wild" should be promoted to Internet Standard. Other decisions or actions require either a demonstration that the claims made in the enabling document are not correct or strong community consensus that the protocol should not be promoted to Internet Standard despite wide deployment. Klensin & Dawkins Expires August 24, 2006 [Page 6] Internet-Draft Promoting Marketplace Standards February 2006 3.2.2. Preservation of Intent The procedure, and procedural experiment, proposed here is deliberately fragile. If the IETF community generally, and the IESG in particular, are not, in practice, willing to recognize the criteria and principles outlined at the beginning of this document and conclude that the marketplace makes decisions about protocol and specification quality that are less stringent than we might impose according to our normal procedures, then the experiment will fail (if, indeed, it is initiated). The procedure remains fragile even if the principles are accepted. If nit-picking during Last Call is confused with legitimate concerns about a protocol, or if IESG members impose requirements above and beyond the clear intent of this document to keep such requirements minimal, then the procedure will rapidly deteriorate into uselessness, if only by discouraging potential proposers from writing enabling documents. Extended arguments about how much deployment is sufficient, or details of document quality, would be likely to have similar effects. Experimental success ultimately requires that the community, as a community, decide that identification and promotion of widely- deployed protocols, in recognition of marketplace decisions, is worth doing. 4. The Experiment Itself 4.1. IESG Workload To the extent to which this experiment encourages efforts to advance documents that otherwise would continue to rest in the purgatory of resting indefinitely in Proposed (or even Draft) Standard while RFC 2026 insists that they be re-identified as historic and abandoned, the effort will increase the number of specifications the IESG needs to evaluate and hence IESG workload. On the other hand, the load on the IESG should be considerably less that for a protocol proposal advancing along the normal RFC 2026 path: there is no evaluation of protocol quality, no IESG evaluation of document quality, and no need to carefully review the description of the protocol and its possible impact: each of those normal tasks would constitute second-guessing a decision that has already been made in the marketplace. The workload should be equivalent to, or less than, that encountered in the "decruft" process and leads to a more productive end -- identification of successful protocols rather than formally retiring those to which no one has paid attention in recent years. If the IESG, and the community, are not willing to take on this level of Klensin & Dawkins Expires August 24, 2006 [Page 7] Internet-Draft Promoting Marketplace Standards February 2006 effort, then the IETF standards process is in great difficulty indeed. 4.2. Approval Process for this Experiment To be initiated, this experiment must be approved according to the model in RFC 3933. The IESG and community should note that it effectively makes a significant change to RFC 2026's definitions of maturity levels and the procedures for attaining them by providing a fast-track procedure for protocols that have already proven themselves by marketplace-based criteria. This experiment should not be approved if the community believes that such criteria, and marketplace decisions, are irrelevant or that the IETF community in general and the IESG in particular have a level of wisdom about the quality of IETF-developed protocols that outweighs any possible marketplace action or deployment. It should be noted in that regard that the procedure described here is applicable only to protocol documents that the IETF or its predecessors, through its normal processes, have already put on the standards track. In particular, it cannot be used to turn something that has gained marketplace deployment by marketing efforts alone, without IETF involvement and approval, into an Internet Standard. 4.3. Discussion of Experimental Issues It is recommended that the experiment run for one year. During that period, it will be important to track several measurements of success and utility. Those include the number of documents that are actually proposed for advancement, the number of attempts that are successful and unsuccessful, and whether there is any pattern to the Proposers of successful and unsuccessful enabling documents. We would encourage the IESG to also be sensitive to the time investment that is required, both in absolute terms and in comparison to reviews of documents being advanced using the normal procedure. We would also encourage the community as a whole to track conformance to the intent of the issues raised in Section 3.2.2. If a Proposer generates three or more consecutive enabling documents that fail to gain community consensus, the IESG may adopt restrictions on additional submissions from that proposer, require endorsements prior to submission by that proposer, or, in their discretion, adopt other measures to ameliorate either denial of service attacks (intentional or unintentional) or outbreaks of stupidity. 5. Security Considerations Klensin & Dawkins Expires August 24, 2006 [Page 8] Internet-Draft Promoting Marketplace Standards February 2006 This document addresses IETF procedures and hence does not raise new security issues of its own. However, it is explicitly intended to permit protocol specification documents to advance to Internet Standard without the level of security analysis typically required for new documents. The enabling document is expected to warn the reader of actual security risks and problems that have been identifed in practice and to note the level of analysis that has been done, but not to go any further. 6. References 6.1. Normative References [RFC2026] Bradner, S., "The Internet Standards Process -- Revision 3", BCP 9, RFC 2026, October 1996. [RFC3933] Klensin, J. and S. Dawkins, "A Model for IETF Process Experiments", BCP 93, RFC 3933, November 2004. [RFC3967] Bush, R. and T. Narten, "Clarifying when Standards Track Documents may Refer Normatively to Documents at a Lower Level", BCP 97, RFC 3967, December 2004. 6.2. Informative References [decruft] Lear, E. and H. Alvestrand, "Getting rid of the cruft: Report from an experiment in identifying and reclassifying obsolete standards documents", draft-ietf-newtrk-decruft-experiment-03 (work in progress), January 2006. This document has been approved as a BCP and is awaiting publication. Klensin & Dawkins Expires August 24, 2006 [Page 9] Internet-Draft Promoting Marketplace Standards February 2006 Authors' Addresses John C Klensin 1770 Massachusetts Ave, #322 Cambridge, MA 02140 USA Phone: +1 617 491 5735 Email: john-ietf@jck.com Spencer Dawkins Futurewei Technologies 1547 Rivercrest Blvd. Allen, TX 75002 USA Phone: +1 214 755 3870 Email: spencer@mcsr-labs.org Klensin & Dawkins Expires August 24, 2006 [Page 10] Internet-Draft Promoting Marketplace Standards February 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. Klensin & Dawkins Expires August 24, 2006 [Page 11]