idnits 2.17.00 (12 Aug 2021) /tmp/idnits45130/draft-hardie-category-descriptions-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Looks like you're using RFC 2026 boilerplate. This must be updated to follow RFC 3978/3979, as updated by RFC 4748. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- ** Missing expiration date. The document expiration date should appear on the first and last page. == No 'Intended status' indicated for this document; assuming Proposed Standard == The page length should not exceed 58 lines per page, but there was 1 longer page, the longest (page 1) being 233 lines Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** There are 7 instances of too long lines in the document, the longest one being 3 characters in excess of 72. ** There is 1 instance of lines with control characters in the document. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (June 2003) is 6908 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) No issues found here. Summary: 4 errors (**), 0 flaws (~~), 3 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 Network Working Group T. Hardie 2 Internet-Draft Qualcomm, Inc. 3 June 2003 5 A proposal describing categories of IETF documents: 6 unbaked, baking, baked, eaten, and boiled. 7 draft-hardie-category-descriptions-00.txt 9 Status of this Memo 11 This document is an Internet-Draft and is in full conformance with 12 all provisions of Section 10 of RFC2026. 14 Internet-Drafts are working documents of the Internet Engineering 15 Task Force (IETF), its areas, and its working groups. Note that 16 other groups may also distribute working documents as Internet- 17 Drafts. 19 Internet-Drafts are draft documents valid for a maximum of six months 20 and may be updated, replaced, or obsoleted by other documents at any 21 time. It is inappropriate to use Internet-Drafts as reference 22 material or to cite them other than as "work in progress." 24 The list of current Internet-Drafts can be accessed at http:// 25 www.ietf.org/ietf/1id-abstracts.txt. 27 The list of Internet-Draft Shadow Directories can be accessed at 28 http://www.ietf.org/shadow.html. 30 Copyright Notice 32 Copyright (C) The Internet Society (2003). All Rights Reserved. 34 Abstract 36 Over time, the document series associated with the IETF has grown 37 and changed. One such change is the increase in the use of 38 secondary markers to identify when documents fit specific 39 categories and, especially, when they are or are not the product 40 of specific IETF processes. The author believes that these 41 secondary markers have largely failed but that the distinctions 42 they were meant to draw remain valuable. A new set of category 43 labels is proposed to re-emphasize these distinctions. The formal 44 categories proposed are Internet Note, Candidate Specification, 45 Proposed IETF Standard, Confirmed IETF Standard, and External 46 Internet Engineering Document. These may be informally understood 47 as ideas which are unbaked, baking, baked, eaten, and boiled. 49 1. Introduction. 51 In recent discussions of reform in the IETF, a consensus seems to 52 be emerging that the fundamental categories used by long time IETF 53 participants to understand the document series remain valuable, but 54 that the indicators used to delineate those categories have ceased 55 to be sufficient as markers for those outside the process. To test 56 that consensus, the author has put together this very flammable 57 straw proposal to determine whether there is agreement on the 58 categories underneath today's terms. A set of entirely disposable 59 formal names is also proposed, for the benefit of those who would 60 otherwise feel hungry when entering the discussion. Note that the 61 term RFC is not used in either the formal or informal names; this 62 does not imply anything about the author's view of the RFC series, 63 but reflects the authors attempt to get at the categories underlying 64 the current series. 66 2. Unbaked/Internet Note. 68 The community needs a document series which has a very low barrier 69 to entry and which can be used to float ideas, make proposals, 70 comment on existing specifications, or carry on a public dialog 71 on some topic of interest to the community. This function 72 is currently carried out in the Internet Drafts series, with a 73 common secondary marker of draft-. 75 3. Baking/Candidate Specification. 77 The community needs a document series for those items which it has 78 taken on as candidates for IETF specifications. These documents 79 might be the product of working groups or they might be the product 80 of some other IETF standards process. This function is currently 81 carried out in the Internet Drafts series, commonly using a a 82 secondary marker of draft-ietf, draft-iab, or draft-irtf. The 83 author personally believes that making Candidate Specifications 84 archival would be valuable for the community, as it would increase 85 the ability of engineers working on related problems to identify 86 work already attempted within the IETF and would eliminate the 87 temptation to publish imperfect work through other channels in 88 order to retain a record of it. 90 4. Baked/Proposed IETF Standard. 92 The community needs a category to identify those specifications 93 which it believes are reasonably complete. Documents in this 94 category would still be subject to update or abandonment if 95 experience with implementation or deployment showed flaws in the 96 original design or specification. Nominally, this maps to current 97 standards track documents, with a secondary marker of "Proposed 98 Standard". In practice, the bar for the current category has been 99 raised through experience that specifications rarely move beyond 100 it, which has created a self-fulfilling prophecy for later 101 documents advancing. In the author's opinion, supporting documents 102 for specifications (e.g. requirements documents) and documents 103 describing best current practices belong in this category, as 104 the community considers them "baked" when published. 106 5. Eaten/Confirmed IETF Standard. 108 The informal name for this category derives from the phrase "eating 109 one's own dog food" which means to use one's own product. 110 Substantively, it means that the community has used this 111 specification and found it good. This maps onto the current 112 standards track with secondary markers of "Draft Standard" and 113 "Full standard". The author personally believes that the collapse 114 of those categories to a single category is appropriate and 115 in line with the emerging consensus. 117 6. Boiled/External Internet Engineering Document. 119 The community needs an archival document series for technnically 120 reviewed documents which relate to the work of Internet engineering 121 but do not fit into the current set of IETF standards. These 122 documents might describe proposed experiments, indicate the results 123 of experiments conducted, describe alternate views of engineering 124 trade-offs made by a working group or other IETF standards process, 125 contain reflections on existing protocols, or, indeed, take on any 126 other task within the broader discipline of Internet Engineering. 127 This category maps broadly onto the current "Informational" and 128 "Experimental" categories of RFCs, with the caveat that some 129 documents currently using those markers are actually supporting 130 documents for the standards in the categories "baked" or "eaten". 132 7. Conclusions. 134 The author does not know when to let go of a metaphor. Other than 135 that, this document is not meant to draw conclusions, but to elicit 136 comments on whether there is a broader agreement on the underlying 137 categories currently understood by the IETF community. 139 8. IANA Considerations. 141 There are no IANA actions described in this document. 143 9. Security Considerations. 145 Were the community to change formal category names for its document 146 series, it would need to ensure that this did not create an opportunity 147 for a generalized "downgrade attack", through confusion over the 148 new categories. 150 10. Normative References 152 Bradner, Scott. "Internet Standards Process -- Revision 3". RFC2026. 154 11. Non-Normative References 156 None. 158 12. Acknowledgements. 160 Leslie Daigle supplied the original "baked, unbaked, baking, and boiled" 161 formulation, which the author then augmented and beat to death. 163 13. Authors' Addresses 165 Ted Hardie 166 Qualcomm, Inc. 167 675 Campbell Technology Parkway 168 Suite 200 169 Campbell, CA 170 U.S.A. 172 EMail: hardie@qualcomm.com 174 Full Copyright Statement 176 Copyright (C) The Internet Society (2003). All Rights Reserved. 178 This document and translations of it may be copied and furnished to 179 others, and derivative works that comment on or otherwise explain it 180 or assist in its implementation may be prepared, copied, published 181 and distributed, in whole or in part, without restriction of any 182 kind, provided that the above copyright notice and this paragraph are 183 included on all such copies and derivative works. However, this 184 document itself may not be modified in any way, such as by removing 185 the copyright notice or references to the Internet Society or other 186 Internet organizations, except as needed for the purpose of 187 developing Internet standards in which case the procedures for 188 copyrights defined in the Internet Standards process must be 189 followed, or as required to translate it into languages other than 190 English. 192 The limited permissions granted above are perpetual and will not be 193 revoked by the Internet Society or its successors or assigns. 195 This document and the information contained herein is provided on an 196 "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING 197 TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING 198 BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION 199 HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF 200 MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 202 Acknowledgement 204 Funding for the RFC Editor function is currently provided by the 205 Internet Society.