Network Working Group T. Hardie Internet-Draft Qualcomm, Inc. June 2003 A proposal describing categories of IETF documents: unbaked, baking, baked, eaten, and boiled. draft-hardie-category-descriptions-00.txt Status of this Memo 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. Copyright Notice Copyright (C) The Internet Society (2003). All Rights Reserved. Abstract Over time, the document series associated with the IETF has grown and changed. One such change is the increase in the use of secondary markers to identify when documents fit specific categories and, especially, when they are or are not the product of specific IETF processes. The author believes that these secondary markers have largely failed but that the distinctions they were meant to draw remain valuable. A new set of category labels is proposed to re-emphasize these distinctions. The formal categories proposed are Internet Note, Candidate Specification, Proposed IETF Standard, Confirmed IETF Standard, and External Internet Engineering Document. These may be informally understood as ideas which are unbaked, baking, baked, eaten, and boiled. 1. Introduction. In recent discussions of reform in the IETF, a consensus seems to be emerging that the fundamental categories used by long time IETF participants to understand the document series remain valuable, but that the indicators used to delineate those categories have ceased to be sufficient as markers for those outside the process. To test that consensus, the author has put together this very flammable straw proposal to determine whether there is agreement on the categories underneath today's terms. A set of entirely disposable formal names is also proposed, for the benefit of those who would otherwise feel hungry when entering the discussion. Note that the term RFC is not used in either the formal or informal names; this does not imply anything about the author's view of the RFC series, but reflects the authors attempt to get at the categories underlying the current series. 2. Unbaked/Internet Note. The community needs a document series which has a very low barrier to entry and which can be used to float ideas, make proposals, comment on existing specifications, or carry on a public dialog on some topic of interest to the community. This function is currently carried out in the Internet Drafts series, with a common secondary marker of draft-. 3. Baking/Candidate Specification. The community needs a document series for those items which it has taken on as candidates for IETF specifications. These documents might be the product of working groups or they might be the product of some other IETF standards process. This function is currently carried out in the Internet Drafts series, commonly using a a secondary marker of draft-ietf, draft-iab, or draft-irtf. The author personally believes that making Candidate Specifications archival would be valuable for the community, as it would increase the ability of engineers working on related problems to identify work already attempted within the IETF and would eliminate the temptation to publish imperfect work through other channels in order to retain a record of it. 4. Baked/Proposed IETF Standard. The community needs a category to identify those specifications which it believes are reasonably complete. Documents in this category would still be subject to update or abandonment if experience with implementation or deployment showed flaws in the original design or specification. Nominally, this maps to current standards track documents, with a secondary marker of "Proposed Standard". In practice, the bar for the current category has been raised through experience that specifications rarely move beyond it, which has created a self-fulfilling prophecy for later documents advancing. In the author's opinion, supporting documents for specifications (e.g. requirements documents) and documents describing best current practices belong in this category, as the community considers them "baked" when published. 5. Eaten/Confirmed IETF Standard. The informal name for this category derives from the phrase "eating one's own dog food" which means to use one's own product. Substantively, it means that the community has used this specification and found it good. This maps onto the current standards track with secondary markers of "Draft Standard" and "Full standard". The author personally believes that the collapse of those categories to a single category is appropriate and in line with the emerging consensus. 6. Boiled/External Internet Engineering Document. The community needs an archival document series for technnically reviewed documents which relate to the work of Internet engineering but do not fit into the current set of IETF standards. These documents might describe proposed experiments, indicate the results of experiments conducted, describe alternate views of engineering trade-offs made by a working group or other IETF standards process, contain reflections on existing protocols, or, indeed, take on any other task within the broader discipline of Internet Engineering. This category maps broadly onto the current "Informational" and "Experimental" categories of RFCs, with the caveat that some documents currently using those markers are actually supporting documents for the standards in the categories "baked" or "eaten". 7. Conclusions. The author does not know when to let go of a metaphor. Other than that, this document is not meant to draw conclusions, but to elicit comments on whether there is a broader agreement on the underlying categories currently understood by the IETF community. 8. IANA Considerations. There are no IANA actions described in this document. 9. Security Considerations. Were the community to change formal category names for its document series, it would need to ensure that this did not create an opportunity for a generalized "downgrade attack", through confusion over the new categories. 10. Normative References Bradner, Scott. "Internet Standards Process -- Revision 3". RFC2026. 11. Non-Normative References None. 12. Acknowledgements. Leslie Daigle supplied the original "baked, unbaked, baking, and boiled" formulation, which the author then augmented and beat to death. 13. Authors' Addresses Ted Hardie Qualcomm, Inc. 675 Campbell Technology Parkway Suite 200 Campbell, CA U.S.A. EMail: hardie@qualcomm.com Full Copyright Statement Copyright (C) The Internet Society (2003). All Rights Reserved. This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English. The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assigns. This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS 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. Acknowledgement Funding for the RFC Editor function is currently provided by the Internet Society.