idnits 2.17.1 draft-klensin-newtrk-antiques-01.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** It looks like you're using RFC 3978 boilerplate. You should update this to the boilerplate described in the IETF Trust License Policy document (see https://trustee.ietf.org/license-info), which is required now. -- Found old boilerplate from RFC 3978, Section 5.1.a on line 15. -- Found old boilerplate from RFC 3978, Section 5.5 on line 364. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 341. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 348. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 354. ** The document seems to lack an RFC 3978 Section 5.1 IPR Disclosure Acknowledgement. ** This document has an original RFC 3978 Section 5.4 Copyright Line, instead of the newer IETF Trust Copyright according to RFC 4748. ** This document has an original RFC 3978 Section 5.5 Disclaimer, instead of the newer disclaimer which includes the IETF Trust according to RFC 4748. ** The document uses RFC 3667 boilerplate or RFC 3978-like boilerplate instead of verbatim RFC 3978 boilerplate. After 6 May 2005, submission of drafts without verbatim RFC 3978 boilerplate is not accepted. The following non-3978 patterns matched text found in the document. That text should be removed or replaced: This document is an Internet-Draft and is subject to all provisions of Section 3 of RFC 3667. 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. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- == No 'Intended status' indicated for this document; assuming Proposed Standard == The page length should not exceed 58 lines per page, but there was 9 longer pages, the longest (page 7) being 67 lines == It seems as if not all pages are separated by form feeds - found 0 form feeds but 9 pages Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) 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 (September 24, 2004) is 7147 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) -- Possible downref: Normative reference to a draft: ref. '1' -- No information found for draft-ietf-newtrk-repurposing-isd-00b - is the name correct? -- Possible downref: Normative reference to a draft: ref. '2' Summary: 6 errors (**), 0 flaws (~~), 4 warnings (==), 10 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 Network Working Group J. Klensin 2 Internet-Draft September 24, 2004 3 Expires: March 25, 2005 5 Valuable Antique Documents: A Model for Advancement 6 draft-klensin-newtrk-antiques-01.txt 8 Status of this Memo 10 This document is an Internet-Draft and is subject to all provisions 11 of section 3 of RFC 3667. By submitting this Internet-Draft, each 12 author represents that any applicable patent or other IPR claims of 13 which he or she is aware have been or will be disclosed, and any of 14 which he or she become aware will be disclosed, in accordance with 15 RFC 3668. 17 Internet-Drafts are working documents of the Internet Engineering 18 Task Force (IETF), its areas, and its working groups. Note that 19 other groups may also distribute working documents as 20 Internet-Drafts. 22 Internet-Drafts are draft documents valid for a maximum of six months 23 and may be updated, replaced, or obsoleted by other documents at any 24 time. It is inappropriate to use Internet-Drafts as reference 25 material or to cite them other than as "work in progress." 27 The list of current Internet-Drafts can be accessed at 28 http://www.ietf.org/ietf/1id-abstracts.txt. 30 The list of Internet-Draft Shadow Directories can be accessed at 31 http://www.ietf.org/shadow.html. 33 This Internet-Draft will expire on March 25, 2005. 35 Copyright Notice 37 Copyright (C) The Internet Society (2004). 39 Abstract 41 RFC 2026 and some of its predecessors require that Proposed and Draft 42 Standards either advance in grade within a reasonable period of time 43 or that they expire and be moved to Historic. That procedure has 44 never been followed on a systematic basis. A new procedure has been 45 proposed that would make that action easier for protocols that have 46 not gotten any real acceptance. In the interest of symmetry, 47 fairness, and an orderly attic, it is worth noting that there are a 48 number of protocol descriptions which have been at less than Full 49 Standard level for a long time but which have proven their value by 50 the traditional criteria of multiple interoperable implementations 51 and wide deployment and use. 53 This document provides a procedure for upgrading such documents to 54 Full Standards without creating an unreasonable burden on authors 55 purely to meet the needs of procedural rituals or placing an 56 unreasonable load on groups charged with performing other tasks in 57 the IETF. 59 Table of Contents 61 1. Introduction and History . . . . . . . . . . . . . . . . . . . 3 62 2. Modified Advancement Model . . . . . . . . . . . . . . . . . . 4 63 3. Candidates for Advancement . . . . . . . . . . . . . . . . . . 5 64 4. Advancement of Individual Documents . . . . . . . . . . . . . 5 65 5. RFC Boilerplate . . . . . . . . . . . . . . . . . . . . . . . 6 66 6. Selection of the Committee . . . . . . . . . . . . . . . . . . 6 67 7. Temporary Note to the Newtrk WG . . . . . . . . . . . . . . . 6 68 8. Security Considerations . . . . . . . . . . . . . . . . . . . 7 69 9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 7 70 10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 7 71 10.1 Normative References . . . . . . . . . . . . . . . . . . . . 7 72 10.2 Informative References . . . . . . . . . . . . . . . . . . . 8 73 Author's Address . . . . . . . . . . . . . . . . . . . . . . . 8 74 Intellectual Property and Copyright Statements . . . . . . . . 9 76 1. Introduction and History 78 This document is intended to be read in conjunction with the proposal 79 to use an "Historical Standards Committee" to make recommendations to 80 the IESG for downgrading or progressing documents on the IETF 81 standards track [1] and is probably meaningless in its present form 82 unless that proposal is adopted. The difference between the two is 83 that the cited document focuses on downgrading -- retiring of a 84 document to Historic -- while this one focuses on getting documents 85 advanced when they describe protocols that have already proven their 86 value, i.e., are "mature". 88 That document notes that documents to retire descriptions of immature 89 standards "require significant time and effort on the part of 90 authors, area directors, and the RFC Editor" and that "no document 91 should be required for an immature standard to be retired". Using 92 much the same reasoning, we suggest that, in many or most cases, no 93 document (or, at most, only trivial modifications, should be required 94 to advance a fully-mature standard whose usefulness has been widely 95 demonstrated. 97 If the proposal to generate a new set of Internet Standard Documents 98 (ISDs) ([2]) is adopted, those documents could easily be used to 99 perform the type of upgrading suggested here, or to describe why it 100 was not appropriate for a given specification even if it was widely 101 deployed. 103 Over the years, there have been many discussions in the IETF 104 community about why documents never move beyond "Proposed" status 105 even when they describe protocols that are obviously widely deployed 106 and for which multiple interoperable implementations exist (see 107 Section 2.4 of the IETF Problem Statement [4] for additional 108 discussion). Many reasons have been suggested, but at least the 109 following seem to be significant: 111 o Once a Proposed Standard protocol has been implemented and 112 deployed, and the specification has proven, in practice, to be 113 adequate to support multiple conforming implementations, it is 114 often extremely difficult to stimulate authors to produce 115 revisions to the description to advance it in grade. Even if the 116 authors can be convinced to do so, that may not be in the best 117 interest of the IETF community: authors and editors who might do 118 the document upgrading work might better be doing work with real, 119 rather than procedural, impact. 120 o Similarly, over the years, IETF requirements for standards-track 121 documents and standards-track protocols have steadily increased, 122 with new sections and levels of detail being required that were 123 not required when the documents for some of our proven, mature, 124 standards were written. While most or all of those additional 125 requirements are justified for new protocols, retroactively 126 imposing burdensome additional documentation requirements on 127 proven protocols has been another disincentive to advancement of 128 those protocols. 129 o Even worse, from the standpoint of getting these documents 130 advanced, there has been some history of second-guessing older 131 protocols in the light of more recent thinking. Specifically, if 132 an attempt is made to advance a protocol that has been deployed 133 and established for years, the question may be asked by the IESG 134 or others as to whether it would be designed the same way today. 135 If the answer is "no", or even "probably not", the protocol has 136 often been rejected for advancement. 138 This combination of circumstances sends a powerful message to 139 authors, and that message is "do not even bother trying to advance 140 the protocol". 142 2. Modified Advancement Model 144 The IETF community has long claimed to believe, not only in "rough 145 consensus and running code", but in interoperable implementations and 146 deployment. The procedure outlined below is based on the assumption 147 that the basic functional requirements for Draft and Full Standard 148 outlined in RFC 2026 [3] are, for mature, deployed, and proven 149 protocols, more important than documentation "nits" or procedural 150 rituals. The empirical observation that a protocol has been widely 151 deployed and used for many years without significant harm being done 152 to the Internet is, in that context, more important than an extensive 153 theoretical presentation of scaling or security issues. 155 This model, and the specific suggestions that follow, depend 156 critically on the community remembering and understanding that 157 "Internet Standard" designates a protocol that is sufficiently 158 specified to facilitate independent interoperable implementations, 159 that is widely deployed, and that has been found significantly 160 useful. It does not imply, and has never officially implied, that 161 the protocol is either recommended or required: when we had those 162 categories, they were considered orthogonal to standards track 163 maturity levels. 165 It also depends critically on the community making the distinction 166 between a mature, useful, and widely implemented and deployed 167 protocol and a document of that protocol that may not be optimal 168 under contemporary standards. It suggests that, for those cases, it 169 is better to explicitly advance a protocol with a weak or incomplete 170 specification than it is to pretend (even by omission) that the 171 protocol is not, de facto, a Standard. 173 3. Candidates for Advancement 175 The advancement procedure for mature standards has the following 176 steps. These closely parallel the steps of [1] and are intended to 177 use the same review process and committee (the "Historical Standards 178 Committee" in that document, henceforth simply "the Committee" in 179 this one). Having two separate bodies parse the collection of older 180 standards track documents is almost certainly inefficient. 182 o In the process of its investigations as to whether documents 183 should be reclassified as Historic according to RFC 2026, the 184 Committee may identify some documents as likely candidates for 185 treatment as "mature standards". The definition of those 186 standards is as described above, i.e., in spite of being 187 officially at Proposed or Draft levels, they are widely accepted 188 in the community, widely deployed, and appear to be the 189 beneficiaries of independent implementations. 190 o For each such RFC, the Committee sends out a message to the IETF 191 list and the lists deemed relevant, asking for comments on 192 implementation experience and active usage. 193 o Unless those reports cause the Committee to determine that the 194 standards are, in fact, not mature, it will treat each one as 195 discussed in the next section. 197 4. Advancement of Individual Documents 199 While some other options are possible, and might be attractive, this 200 document assumes that any advancement in grade will need to be 201 considered individually and subjected to a formal IETF Last Call. 202 The goal of the procedure outlined here is to avoid even more 203 complicated procedures, time-consuming and frustrating document 204 rewriting, etc., where possible. 206 To the three alternatives listed under "Individual Decommissioning 207 Procedure" in [1], this document adds "Advancement of Grade". The 208 intent is to move all "mature" standards to (full) Internet Standard 209 unless there are significant and substantive reasons to not do so. 210 Because of the requirements of RFC 2026, Proposed Standard documents 211 for mature standards must be advanced in two steps, but the IESG is 212 strongly encouraged to make the second of those steps completely pro 213 forma, with no change in the published RFC. 215 If the Committee recommends that a specification be advanced, and the 216 community (as determined by the IESG) agrees, rewriting of the 217 relevant RFC should be avoided to the extent possible. As suggested 218 above, if the specification was good enough to support multiple 219 independent implementations and wide deployment, then it is 220 sufficient for an Internet Standard. If additional text is required, 221 it should take the form of supplemental comments to be published 222 either separately, e.g., as part of an update to the relevant 223 Internet Standard Document (ISD) (see [2] , or as an appendix to an 224 otherwise substantially identical RFC. If the Committee and 225 community determine that the protocol is mature, contemporary 226 standards for documentation and specification shall not be applied 227 retroactively. 229 The "Procedure" to be used is identical to that discussed in [1]. 230 The "Evaluation Criteria" are those discussed above for determining 231 whether or not a standard is mature. Put differently, those criteria 232 are the ones listed for Internet Standard in RFC 2026, independent of 233 judgments about document editorial quality. 235 5. RFC Boilerplate 237 This document explicitly contemplates the advancement to Internet 238 Standard of documents that would not pass muster for Proposed if 239 first written today. It also contemplates the publication, as part 240 of advancement of other documents that, similarly, would not meet 241 today's criteria. If RFCs actually need to be reissued, the RFC 242 Editor and IESG are encouraged to work out a suitable "boilerplate" 243 statement that indicates that the documents describe mature 244 specifications designated as Internet Standards because they 245 represent common and established practice rather than because the 246 documents are of the quality expected today for such Standards. Of 247 course, if the upgrade is done by producing or modifying ISD text, 248 such special RFC boilerplate would not be necessary and any 249 qualifying text could be placed in the ISD. 251 6. Selection of the Committee 253 Since this procedure is expected to use the same Committee as in [1], 254 whatever selection mechanism is specified in that document and its 255 successors will apply here as well. 257 7. Temporary Note to the Newtrk WG 259 [[Note in draft: this section to be removed before RFC publication, 260 if the document gets that far.]] 262 While I didn't intend it when I agreed to write this draft, it became 263 clear to me in doing so that, if viewed as an ongoing procedure 264 rather than a one-time cleanup mechanism, it actually provides an 265 alternate standards track mechanism. Viewed that way, we end up with 266 the same maturity levels as in 2026, but two ways of getting past 267 Proposed. One involves being very diligent about writing and 268 upgrading documents, as 2026 more or less explicitly contemplates. 270 The other involves producing Proposed Standard documents of 271 sufficient quality to support interoperable implementations, getting 272 them implemented and deployed widely enough to meet both the criteria 273 for full Standard and a perhaps-somewhat-stronger standard of 274 usefulness and then, after a period of time long enough to establish 275 the specification as common practice, just promoting the documents as 276 written. While some of the language above contemplates documents of 277 the quality and content that was considered acceptable a decade or 278 two ago going to full Standard essentially unchanged, more recent 279 Proposed Standard documents would presumably be more complete and 280 meet contemporary criteria, thereby requiring fewer disclaimers. 282 The document deliberately does not specify how elderly a document 283 must be for this procedure to be invoked. While some guidelines 284 might be possible and should be discussed, I am comfortable leaving 285 that question to the discretion of the Committee, subject to the 286 bounds set by RFC 2026. 288 8. Security Considerations 290 See [1] which doesn't seem to have one of these sections either :-) 292 9. Acknowledgements 294 This document arose out of a discussion of [1] that, in turn, led to 295 this author's volunteering to put together an "advancement" 296 discussion to match that one's downgrading. The contributors to that 297 discussion, and especially the co-authors of the partner document 298 (from whom many ideas and much text has been appropriated) are 299 gratefully acknowledged, as are the useful discussions during IETF 300 60. 302 10. References 304 10.1 Normative References 306 [1] Alvestrand, H. and E. Lear, "Getting rid of the cruft: A 307 procedure to deprecate old standards", 308 draft-alvestrand-newtrk-cruft-01 (work in progress), September 309 2004. 311 [2] Klensin, J. and J. Loughney, "Internet Standards Documentation 312 (ISDs)", draft-ietf-newtrk-repurposing-isd-00b (work in 313 progress), September 2004. 315 [3] Bradner, S., "The Internet Standards Process -- Revision 3", BCP 316 9, RFC 2026, October 1996. 318 10.2 Informative References 320 [4] Davies, E., "IETF Problem Statement", RFC 3774, May 2004. 322 Author's Address 324 John C Klensin 325 1770 Massachusetts Ave, #322 326 Cambridge, MA 02140 327 USA 329 Phone: +1 617 491 5735 330 EMail: john-ietf@jck.com 332 Intellectual Property Statement 334 The IETF takes no position regarding the validity or scope of any 335 Intellectual Property Rights or other rights that might be claimed to 336 pertain to the implementation or use of the technology described in 337 this document or the extent to which any license under such rights 338 might or might not be available; nor does it represent that it has 339 made any independent effort to identify any such rights. Information 340 on the procedures with respect to rights in RFC documents can be 341 found in BCP 78 and BCP 79. 343 Copies of IPR disclosures made to the IETF Secretariat and any 344 assurances of licenses to be made available, or the result of an 345 attempt made to obtain a general license or permission for the use of 346 such proprietary rights by implementers or users of this 347 specification can be obtained from the IETF on-line IPR repository at 348 http://www.ietf.org/ipr. 350 The IETF invites any interested party to bring to its attention any 351 copyrights, patents or patent applications, or other proprietary 352 rights that may cover technology that may be required to implement 353 this standard. Please address the information to the IETF at 354 ietf-ipr@ietf.org. 356 Disclaimer of Validity 358 This document and the information contained herein are provided on an 359 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 360 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 361 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 362 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 363 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 364 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 366 Copyright Statement 368 Copyright (C) The Internet Society (2004). This document is subject 369 to the rights, licenses and restrictions contained in BCP 78, and 370 except as set forth therein, the authors retain all their rights. 372 Acknowledgment 374 Funding for the RFC Editor function is currently provided by the 375 Internet Society.