Network Working Group J. Klensin Internet-Draft May 23, 2004 Expires: November 21, 2004 Valuable Antique Documents: A Model for Advancement draft-klensin-newtrk-antiques-00.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 21, 2004. Copyright Notice Copyright (C) The Internet Society (2004). All Rights Reserved. Abstract RFC 2026 and some of its predecessors require that Proposed and Draft Standards either advance in grade within a reasonable period of time or that they expire and be moved to Historic. That procedure has never been followed on a systematic basis. A new procedure has been proposed that would make that action easier for protocols that have not gotten any real acceptance. In the interest of symmetry, fairness, and an orderly attic, it is worth noting that there are a number of protocol descriptions which have been at less than Full Standard level for a long time but which have proven their value by the traditional criteria of multiple interoperable implementations Klensin Expires November 21, 2004 [Page 1] Internet-Draft Advancing Antiques May 2004 and wide deployment and use. This document provides a procedure for upgrading such documents to Full Standards without creating an unreasonable burden on authors purely to meet the needs of procedural rituals or placing an unreasonable load on groups charged with performing other tasks in the IETF. Table of Contents 1. Introduction and History . . . . . . . . . . . . . . . . . . . 3 2. Modified Advancement Model . . . . . . . . . . . . . . . . . . 4 3. Candidates for Advancement . . . . . . . . . . . . . . . . . . 4 4. Advancement of Individual Documents . . . . . . . . . . . . . 5 5. RFC Boilerplate . . . . . . . . . . . . . . . . . . . . . . . 6 6. Selection of the Commission . . . . . . . . . . . . . . . . . 6 7. Temporary Note to the Newtrk WG . . . . . . . . . . . . . . . 6 8. Security Considerations . . . . . . . . . . . . . . . . . . . 7 9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 7 10. Normative References . . . . . . . . . . . . . . . . . . . . 7 Author's Address . . . . . . . . . . . . . . . . . . . . . . . 7 Intellectual Property and Copyright Statements . . . . . . . . 8 Klensin Expires November 21, 2004 [Page 2] Internet-Draft Advancing Antiques May 2004 1. Introduction and History This document is intended to be read in conjunction with the proposal to use a "Commission for Protocol Obsolescence" to make recommendations to the IESG for downgrading or progressing documents on the IETF standards track [1] and is probably meaningless in its present form unless that proposal is adopted. The difference between the two is that the cited document focuses on downgrading -- retiring of a document to Historic -- while this one focuses on getting documents advanced when they describe protocols that have already proven their value, i.e., are "mature". That document notes that documents to retire descriptions of immature standards "require significant time and effort on the part of authors, area directors, and the RFC Editor" and that "no document should be required for an immature standard to be retired to Historic status". Using much the same reasoning, we suggest that, in many or most cases, no document (or, at most, only trivial modifications, should be required to advance a fully-mature standard whose usefulness has been widely demonstrated. Over the years, there have been many discussions in the IETF community about why documents never move beyond "Proposed" status even when they describe protocols that are obviously widely deployed and for which multiple interoperable implementations exist. Many reasons have been suggested, but at least the following seem to be significant: o Once a Proposed Standard protocol has been implemented and deployed, and the specification has proven, in practice, to be adequate to support multiple conforming implementations, it is extremely difficult to stimulate authors to produce revisions to the description to advance it in grade. Even if the authors can be convinced to do so, that may not be in the best interest of the IETF community: authors and editors who might do the document upgrading work might better be doing work with real, rather than procedural, impact. o Similarly, over the years, IETF requirements for standards-track documents and standards-track protocols have steadily increased, with new sections and levels of detail being required that were not required when the documents for some of our proven, mature, standards were written. While most or all of those additional requirements are justified for new protocols, retroactively imposing burdensome additional documentation requirements on proven protocols has been another disincentive to advancement of those protocols. o Even worse, from the standpoint of getting these documents advanced, there has been some history of second-guessing older Klensin Expires November 21, 2004 [Page 3] Internet-Draft Advancing Antiques May 2004 protocols in the light of more recent thinking. Specifically, if an attempt is made to advance a protocol that has been deployed and established for years, the question may be asked by the IESG or others as to whether it would be designed the same way today. If the answer is "no", or even "probably not", the protocol has often been rejected for advancement. This combination of circumstances sends a powerful message to authors, and that message is "do not even bother trying to advance the protocol". 2. Modified Advancement Model The IETF community has long claimed to believe, not only in "rough consensus and running code", but in interoperable implementations and deployment. The procedure outlined below is based on the assumption that the basic functional requirements for Draft and Full Standard outlined in RFC 2026 [2] are, for mature, deployed, and proven protocols, more important than documentation "nits" or procedural rituals. The empirical observation that a protocol has been widely deployed and used for many years without significant harm being done to the Internet is, in that context, more important than an extensive theoretical presentation of scaling or security issues. This model, and the specific suggestions that follow, depend critically on the community remembering and understanding that "Internet Standard" designates a protocol that is sufficiently specified to facilitate independent interoperable implementations, that is widely deployed, and that has been found significantly useful. It does not imply that the protocol is either recommended or required: when we had those categories, they were considered orthogonal to standards track maturity levels. It also depends critically on the community making the distinction between a mature, useful, and widely implemented and deployed protocol and a document of that protocol that may not be optimal under contemporary standards. It suggests that, for those cases, it is better to explicitly advance a protocol with a weak or incomplete specification than it is to pretend (even by omission) that the protocol is not, de facto, a Standard. 3. Candidates for Advancement The advancement procedure for mature standards has the following steps. These closely parallel the steps of [1] and are intended to use the same Commission. Having two separate bodies parse the collection of older standards track documents is almost certainly inefficient. Klensin Expires November 21, 2004 [Page 4] o In the process of its investigations as to whether documents should be reclassified as Historic according to RFC 2026, the Commission may identify some documents as likely candidates for treatment as "mature standards". The definition of those standards is as described above, i.e., in spite of being officially at Proposed or Draft levels, they are widely accepted in the community, widely deployed, and appear to be the beneficiaries of independent implementations. o For each such RFC, the Commission sends out a message to the IETF list and the lists deemed relevant, asking for comments on implementation experience and active usage. o Unless those reports cause the Commission to determine that the standards are, in fact, not mature, it will treat each one as discussed in the next section. 4. Advancement of Individual Documents While some other options are possible, and might be attractive, this document assumes that any advancement in grade will need to be considered individually and subjected to a formal IETF Last Call. The goal of the procedure outlined here is to avoid even more complicated procedures, time-consuming and frustrating document rewriting, etc., where possible. To the three alternatives listed under "Individual Decommissioning Procedure" in [1], this document adds "Advancement of Grade". The intent is to move all "mature" standards to Full Internet Standard unless there are significant and substantive reasons to not do so. Because of the requirements of RFC 2026, Proposed Standard documents for mature standards must be advanced in two steps, but the IESG is strongly encouraged to make the second of those steps completely pro forma, with no change in the published RFC. If the Commission recommends that a specification be advanced, and the community (as determined by the IESG) agrees, rewriting of the relevant RFC should be avoided to the extent possible. As suggested above, if the specification was good enough to support multiple independent implementations and wide deployment, then it is sufficient for an Internet Standard. If additional text is required, it should take the form of supplemental comments to be published either separately or as an appendix to an otherwise substantially identical RFC. If the Commission and community determine that the protocol is mature, contemporary standards for documentation and specification shall not be applied retroactively. The "Procedure" to be used is identical to that discussed in [1]. The "Evaluation Criteria" are those discussed above for determining whether or not a standard is mature. Put differently, those criteria are the ones listed for Internet Standard in RFC 2026, independent of judgments about document editorial quality. Klensin Expires November 21, 2004 [Page 5] Internet-Draft Advancing Antiques May 2004 5. RFC Boilerplate This document explicitly contemplates the advancement to Internet Standard of documents that would not pass muster for Proposed if first written today. It also contemplates the publication, as part of advancement of other documents that, similarly, would not meet today's criteria. The RFC Editor and IESG are encouraged to work out a suitable "boilerplate" statement that indicates that the documents describe mature specifications designated as Internet Standards because they represent common and established practice rather than because the documents are of the quality expected today for such Standards. 6. Selection of the Commission Since this procedure is expected to use the same Commission as in [1], whatever selection mechanism is specified in that document and its successors will apply here as well. 7. Temporary Note to the Newtrk WG While I didn't intend it when I agreed to write this draft, it became clear to me in doing so that, if viewed as an ongoing procedure rather than a one-time cleanup mechanism, it actually provides an alternate standards track mechanism. Viewed that way, we end up with the same maturity levels as in 2026, but two ways of getting past Proposed. One involved being very diligent about writing and upgrading documents, as 2026 more or less explicitly contemplates. The other involves producing Proposed Standard documents of sufficient quality to support interoperable implementations, getting them implemented and deployed widely enough to meet both the criteria for full Standard and a perhaps-somewhat-stronger standard of usefulness and then, after period of time long enough to establish the specification as common practice, just promoting the documents as written. While some of the language above contemplates documents of the quality and content that was considered acceptable a decade or two ago going to full Standard essentially unchanged, more recent Proposed Standard documents would presumably be more complete and meet contemporary criteria, thereby requiring fewer disclaimers. The document deliberately does not specify how elderly a document must be for this procedure to be invoked. While some guidelines might be possible and should be discussed, I am comfortable leaving that question to the discretion of the Commission, subject to the bounds set by RFC 2026. Klensin Expires November 21, 2004 [Page 6] Internet-Draft Advancing Antiques May 2004 8. Security Considerations See [1] which doesn't seem to have one of these sections either :-) 9. Acknowledgements This document arose out of a discussion of [1] that, in turn, led to this author's volunteering to put together an "advancement" discussion to match that one's downgrading. The contributors to that discussion, and especially the co-authors of the partner document (from whom many ideas and much text has been appropriated) are gratefully acknowledged. 10 Normative References [1] Alvestrand, H. and E. Lear, "Moving documents to Historic: A procedure", draft-alvestrand-newtrk-historical-00 (work in progress), March 2004. [2] Bradner, S., "The Internet Standards Process -- Revision 3", BCP 9, RFC 2026, October 1996. Author's Address John C Klensin 1770 Massachusetts Ave, #322 Cambridge, MA 02140 USA Phone: +1 617 491 5735 EMail: john-ietf@jck.com Klensin Expires November 21, 2004 [Page 7] Internet-Draft Advancing Antiques 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. Klensin Expires November 21, 2004 [Page 8]