Network Working Group J. Klensin Internet-Draft Intended status: Informational S. Bradner Expires: August 2, 2011 Harvard University January 29, 2011 Restoring Proposed Standard to Its Intended Use draft-bradner-restore-proposed-00.txt Abstract Restore the very low bar for Proposed Standard described in RFC 2026 (BCP 9) Status of this Memo This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet- Drafts is at http://datatracker.ietf.org/drafts/current/. 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." This Internet-Draft will expire on August 2, 2011. Copyright Notice Copyright (c) 2011 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. Klensin & Bradner Expires August 2, 2011 [Page 1] Internet-Draft Restore Proposed Standard January 2011 Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Discussion List . . . . . . . . . . . . . . . . . . . . . . . . 4 3. Remedy . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4 4. Schedule . . . . . . . . . . . . . . . . . . . . . . . . . . . 5 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 5 6. Security Considerations . . . . . . . . . . . . . . . . . . . . 5 7. References . . . . . . . . . . . . . . . . . . . . . . . . . . 6 7.1. Normative References . . . . . . . . . . . . . . . . . . . 6 7.2. Informative References . . . . . . . . . . . . . . . . . . 6 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 6 Klensin & Bradner Expires August 2, 2011 [Page 2] Internet-Draft Restore Proposed Standard January 2011 1. Introduction Few IETF technologies progress beyond Proposed Standard. This has been identified as a problem for quite a while [RFC3774]. A number of proposals have been made to fix this problem. Some of the proposals would change the number of stages in the IETF standards process and/or reduce the requirements to progress a technology along the standards track. But there is no reason to believe that any of these proposals would actually result in a significant change to the percentage of authors or working groups undertaking the effort to progress their documents. On the other hand there is reason to believe that the current stringent review given by the IESG to documents proposed for publication as Proposed Standard RFCs at contributes to the reluctance of authors and working groups working on progressing their documents. The current level of review means that most implementers consider Proposed Standard documents as "finished" and ready for implementation and deployment. If a technology is widely deployed there is, naturally, less incentive to continue to work on it, even to update the specification to reflect changes made during implementation. Instead the incentive is to move on to other development efforts. It should also be noted that, in many cases, Internet Drafts have taken on the role that the IETF Standards Process reserved for Proposed Standard starting with the first time that the process was written down [RFC1310]. Internet Drafts are implemented on the basis of working drafts and the technology is deployed, sometimes into production networks, due, in part, to the delay introduced in the IESG review process for Proposed Standard documents. Reducing the number of stages in the standards track or changing the requirements for advancement will likely have little or no effect as long as the IESG continues its current level of review for Proposed Standard. Thus, restoring the original IETF concept of the applicability and completeness of Proposed Standards is a prerequisite to considering any of these proposals. RFC 2026 (BCP 9), Section 4.1 [RFC2026] intended a very low bar for Proposed Standard, essentially that the text be clear enough that the community could examine the protocol, develop trial implementations, and begin testing both the protocol and the specification text. The relevant text in 2026 says specifically: A Proposed Standard 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, Klensin & Bradner Expires August 2, 2011 [Page 3] Internet-Draft Restore Proposed Standard January 2011 further experience might result in a change or even retraction of the specification before it advances. Usually, neither implementation nor operational experience is required for the designation of a specification as a Proposed Standard. [...] A Proposed Standard should have no known technical omissions with respect to the requirements placed upon it. [...] In the years subsequent to the publication of RFC 2026, the actual IESG review for Proposed Standard has evolved to require a very high quality level of protocol completeness and specification and editorial quality. It is common for working groups, and then those groups in conjunction with various ADs, to spend weeks or months refining small editorial or technical points, requiring extensive security and other analyses, and so on, even though the underlying specification is clear enough for implementation and testing and there are no obvious technical defects. The length and difficulty of that process then contributes to a vicious cycle. As the bar to publishing a Proposed Standards becomes higher, the combination of market pressures and WG exhaustion results in fewer documents advancing beyond Proposed Standard and more of the Internet running on Proposed Standards. Conversely, as more of the Internet runs on Proposed Standards and fewer documents advance from that level, the IESG and the community perceive pressure to achieve perfection in Proposed Standard documents, leading to a higher bar to publication. That situation helps no one and hurts the Internet and the IETF and its reputation. 2. Discussion List [[anchor2: RFC Editor: Please remove this section.]] Until and unless the General Area AD designates another location, this proposal should be discussed on the general IETF mailing list. 3. Remedy No changes are required to RFC 2026 or other established procedural documents to break the cycle described above and restore the threshold for publishing a specification at Proposed Standard to its intended level. However, because the IESG perceives community Klensin & Bradner Expires August 2, 2011 [Page 4] Internet-Draft Restore Proposed Standard January 2011 support for a high level of specification and editorial quality in Proposed Standards, some reasonable level of community consensus and a target date may be needed to accomplish the goal of faster and lighter weight Proposed Standard processing (consistent with RFC 2026). This document is intended to act as a focus for that consensus- building discussion. Nothing in this document alters the IESG's authority, as specified in RFC 2026, to impose additional requirements, particularly demonstration implementation or testing requirements, in exceptional circumstances on specifications intended as Proposed Standards. However, the intent of this document is to restore the use of such additional requirements to truly exceptional circumstances. 4. Schedule Upon the approval of this document, the IESG will designate a target date, not more than 90 days in the future, after which documents entering the standards track will be processed strictly as intended in RFC 2026. In other words, unless exceptional circumstances apply, the criteria for approval of a Proposed Standard will be stricted those outlined in RFC 2026 (and quoted in Section 1 above). The IESG is authorized and encouraged, but not required, to revise the boilerplate text for newly-published Proposed Standard specifications to indicate that they do not indicate IETF endorsement of specification quality or desirability, only that the specifications are considered adequate for study, implementation, and testing. Similarly, the IESG may specify boilerplate for Security Considerations and other required RFC sections that notes that those sections in Proposed Standards should not be expected to be complete and comprehensive. 5. IANA Considerations [[anchor5: RFC Editor: Please remove this section before publication.]] This memo includes no requests to or actions for IANA. 6. Security Considerations This document should, if effective, lead to Proposed Standards that Klensin & Bradner Expires August 2, 2011 [Page 5] Internet-Draft Restore Proposed Standard January 2011 are published sooner and that are much more clear about their status and the status of whatever evaluations are performed. Other than the side-effects of that change, this document should have no consequences for the security of the Internet. 7. References 7.1. Normative References [RFC2026] Bradner, S., "The Internet Standards Process -- Revision 3", BCP 9, RFC 2026, October 1996. 7.2. Informative References [RFC1310] Chapin, A., "The Internet Standards Process", RFC 1310, March 1992. [RFC3774] Davies, E., "IETF Problem Statement", RFC 3774, May 2004. Authors' Addresses John C Klensin 1770 Massachusetts Ave, Ste 322 Cambridge, MA 02140 USA Phone: +1 617 245 1457 Email: john-ietf@jck.com Scott Bradner Harvard University 29 Oxford St Cambridge, MA 02138 USA Phone: +1 617 495 3864 Email: sob@harvard.edu Klensin & Bradner Expires August 2, 2011 [Page 6]