idnits 2.17.1 draft-klensin-newtrk-std-repurposing-00.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 3667, Section 5.1 on line 14. -- Found old boilerplate from RFC 3978, Section 5.5 on line 477. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 454. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 461. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 467. ** Found boilerplate matching RFC 3978, Section 5.4, paragraph 1 (on line 483), which is fine, but *also* found old RFC 2026, Section 10.4C, paragraph 1 text on line 36. ** The document seems to lack an RFC 3978 Section 5.1 IPR Disclosure Acknowledgement -- however, there's a paragraph with a matching beginning. Boilerplate error? ** 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: By submitting this Internet-Draft, I certify that any applicable patent or other IPR claims of which I am aware have been disclosed, or will be disclosed, and any of which I become aware will be disclosed, in accordance with RFC 3668. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- == No 'Intended status' indicated for this document; assuming Proposed Standard Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. 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 6, 2004) is 7254 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. 'WhatStandards' == Outdated reference: A later version (-01) exists of draft-klensin-newtrk-antiques-00 -- Obsolete informational reference (is this intentional?): RFC 2223 (Obsoleted by RFC 7322) Summary: 6 errors (**), 0 flaws (~~), 3 warnings (==), 9 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group J. Klensin 3 Internet-Draft June 6, 2004 4 Expires: December 5, 2004 6 Repurposing the STD Designation 7 draft-klensin-newtrk-std-repurposing-00.txt 9 Status of this Memo 11 By submitting this Internet-Draft, I certify that any applicable 12 patent or other IPR claims of which I am aware have been disclosed, 13 and any of which I become aware will be disclosed, in accordance with 14 RFC 3668. 16 Internet-Drafts are working documents of the Internet Engineering 17 Task Force (IETF), its areas, and its working groups. Note that 18 other groups may also distribute working documents as 19 Internet-Drafts. 21 Internet-Drafts are draft documents valid for a maximum of six months 22 and may be updated, replaced, or obsoleted by other documents at any 23 time. It is inappropriate to use Internet-Drafts as reference 24 material or to cite them other than as "work in progress." 26 The list of current Internet-Drafts can be accessed at 27 http://www.ietf.org/ietf/1id-abstracts.txt. 29 The list of Internet-Draft Shadow Directories can be accessed at 30 http://www.ietf.org/shadow.html. 32 This Internet-Draft will expire on December 5, 2004. 34 Copyright Notice 36 Copyright (C) The Internet Society (2004). All Rights Reserved. 38 Abstract 40 Over the years, it has been repeatedly observed that the STD nnnn and 41 BCP nnnn designation for IETF Standards has not worked well, either 42 as a stable reference for external specifications or as a combined 43 reference for multiple documents that are linked together into a 44 single specification. This document proposes two changes that have 45 been discussed on and off for some time, but never written up or 46 considered as specific proposals. The first of these would assign a 47 STD (or BCP) number to a specification when it enters the first level 48 of the Standards Track (or is first designated as a BCP). The second 49 would turn STDs and BCPs into actual documents that describe what 50 they identify and their publication and change history. 52 Table of Contents 54 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 55 2. Proposal Overview . . . . . . . . . . . . . . . . . . . . . 4 56 3. A New Document Series . . . . . . . . . . . . . . . . . . . 5 57 4. Content and Organization of an STD Document . . . . . . . . 6 58 5. Transition . . . . . . . . . . . . . . . . . . . . . . . . . 7 59 6. Operational Issues . . . . . . . . . . . . . . . . . . . . . 8 60 7. References to STDs or References to RFCs . . . . . . . . . . 9 61 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . 9 62 9. Security Considerations . . . . . . . . . . . . . . . . . . 9 63 10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 9 64 11. References . . . . . . . . . . . . . . . . . . . . . . . . . 10 65 11.1 Normative References . . . . . . . . . . . . . . . . . . . 10 66 11.2 Informative References . . . . . . . . . . . . . . . . . . 10 67 Author's Address . . . . . . . . . . . . . . . . . . . . . . 10 68 Intellectual Property and Copyright Statements . . . . . . . 11 70 1. Introduction 72 The "STD" and "BCP" labels are described in [RFC2026] as subseries of 73 the RFC series, with their numbers being assigned when documents are 74 published as Internet Standards or as BCPs. Beyond those brief 75 statements, the organization of the two series, the classification of 76 documents as either belonging together as part of a single "STD" 77 specification or as separate, have largely been a matter of oral 78 tradition, with more of the decisions being made as part of the RFC 79 indexing process than explicitly by the IESG as part of the standards 80 process. The intent has been to permit a stable reference to 81 particular specifications and groups of documents making up a 82 specification, a reference that survives replacement of one RFC with 83 another, addition or deletion of RFCs from the collective 84 specification, and so on. 86 While the intentions are fairly clear and quite desirable, this 87 document suggests that the system has never worked well, especially 88 for STDs that comprise (or point to) several RFCs. There is no 89 easily-accessible audit track that specifies which documents were 90 part of an STD at a particular time (which can be very important for 91 determining what a specification that points to an STD actually means 92 or requires). The low level of involvement of the IESG in the 93 classification process is probably several problems waiting to 94 happen. And the "do not assign an STD number until the specification 95 reaches full Internet Standard" model is unrealistic in a world in 96 which much of the Internet runs on Proposed Standards and in which 97 the IETF only very rarely approves and publishes "Applicability 98 Statement" documents (and, when it does publish them, has little idea 99 what to do with them -- several documents that rationally fall into 100 that category have been published as BCPs instead). 102 This document is intended as a very specific supplement and addition 103 to [WhatStandards] and is believed to be consistent with its general 104 analysis and the issues it raises. However, its emphasis is on a 105 paper track and specific "benchmark" or "snapshot" documentation, not 106 on web pages and bug tracking. On the other hand, the ideas proposed 107 here could provide some of the anchoring for the "label system" that 108 is required by the suggestions of that document. 110 The discussion and proposal that follows are written in terms of 111 traditional standards track documents (Proposed, Draft, and Internet 112 Standard). Whether it should also be applied to BCPs needs further 113 review: the applicability is fairly obvious, but it is not clear 114 whether it is necessary enough to justify the extra trouble. 116 2. Proposal Overview 118 This document proposes that "STD"s be turned into real documents, 119 separate from the underlying RFCs and managed under the direction of 120 the IESG as part of the standards-specification process, rather than 121 being simply pointers in indexes (or the RFCs under different file 122 names or packaging). It proposes that STD documents be created and 123 numbers assigned when specifications enter the formal standards track 124 (Proposed Standard under the model described in RFC 2026) and that 125 the documents be used to track maturation, applicability 126 recommendations, and history of those specifications. It also 127 outlines the format of those documents, which is expected to be 128 different from the format of protocol specification documents and the 129 RFC series generally ([RFC2223], [rfc2223bis]) and briefly discusses 130 a transition strategy. 132 While it is debatable whether everything published as a Proposed 133 Standard today deserves, on the basis of quality of consensus or 134 implementations, that definition, these documents and the early 135 adoption of STD numbers may, on the one hand, help focus and 136 discussion on that point and will, on the other, permit the IESG to 137 attach appropriate qualifying notes as needed. For example, if the 138 community concluded that a specification should be published as a 139 Proposed Standard, but that potential implementers should be warned 140 that IETF confidence in its stability was lower than usual, these 141 documents would be an appropriate place to publish that type of 142 evaluation. Conversely, if interoperable implementations already 143 existed before the Proposed Standard was published, the corresponding 144 STD document would be an appropriate place to note that fact. 146 These documents, and documents authoritatively (normatively) 147 referenced from them, will become, essentially, the definitions of 148 standards. Consequently, any changes to them will occur only under 149 IESG authority and responsibility. The IESG may, at its discretion, 150 and with appropriate announcements to, and consultation of, the 151 community, delegate authority for some sections to groups responsible 152 for the ongoing maintenance of the standards, but may not relinquish 153 responsibility for the documents themselves. However, nothing in 154 this specification prohibits (or requires) IESG authorization of 155 placement of links in the STD documents that point to less formal and 156 less authoritative discussions of, or comments on, the relevant 157 standards should they deem that appropriate. 159 [[ Note in Draft: In plain English, if it makes sense to the 160 community to have an archive of comments, discussion, or proposed 161 errata on the documents, that is fine, and it would be useful for 162 these documents to identify the locations of those archives. But we 163 should be very careful that the contents of such archives are not 164 confused with the content of the specifications unless they go 165 through some sort of formal review and consensus process. The 166 description of that process above is deliberately open-ended and 167 flexible, as long as the IESG is willing to accept and maintain 168 formal responsibility for whatever appears on those pages and could 169 admit of some changes being made by, e.g., maintenance committees 170 should the community want to move in that direction. ]] 172 By extension from the above, the IESG will need to make 173 determinations, ideally after creating guidelines and getting 174 community review and assent to them, as to criteria (e.g., length, 175 importance, degree of discussion needed) by which authoritative 176 comments and qualifications about standards will be incorporated into 177 the STDs documents or issued as separate RFCs. 179 [[ Note in Draft: The author presumes that common sense will prevail 180 and that this document does not need to try to specify those 181 boundaries. If that assumption is not correct, we have other 182 problems that this type of specification cannot solve. ]] 184 If this proposal is accepted in principle, some additional sections 185 will be required to explicitly update RFC 2026. 187 3. A New Document Series 189 When the IESG agrees to move a document onto the standards track, it 190 either causes a new standard number ("STD number") to be assigned to 191 it, or classifies it as part of an existing standard and assigns that 192 number. If multiple, related, specifications are approved at the 193 same time, they may be assigned the same STD number. As those 194 documents are published as RFCs, the RFC may (and presumably usually 195 will) contain the standard number since it will constitute a stable 196 forward reference. This assignment of an STD number, and assignment 197 of a specification to it, results in a corresponding STD document 198 being created or updated, as described below. Following good sense 199 and existing precedent, the IESG may decide to include documents that 200 are not themselves on the standards track (e.g., Informational 201 documents explaining, or describing alternatives to, an agreed-upon 202 standard) in references from a STD document once that document is 203 defined by the assignment of a number. 205 Advancement of a document on the standards track, publication of 206 applicability statements, notes on errata or other issues of 207 sufficient and substantive importance to require alerting 208 implementers or the community will also result in modifications to 209 the relevant STD document. It is explicitly anticipated that 210 documents may be moved from one maturity level to another (i.e., 211 under the current system, to Draft, Full, or Historic, or from 212 Experimental to Proposed) by changing the STD document to identify 213 the new level and include any relevant notes as an alternative to 214 modifying the relevant RFC text and issuing new RFCs (and, of course, 215 modifying the STD document to reflect those changes). 217 Particular RFCs may move in and out of a STD (except for the 218 historical record) as one RFC replaces another. Because the STD 219 document is expected to contain prose, it will be possible to deal 220 with the long-standing issues of what "updates" means by identifying 221 the relevant sections or concepts. And, again because there is 222 descriptive prose present, the IESG will be able to deal 223 appropriately with the relationship between an old Full Standard and 224 a newer document, at a lower maturity level, that is intended to 225 replace it by specifying whatever they consider appropriate about 226 what the implementer or other reader should look at. 228 [[ Note in draft: Were either or both of the "Commission" (or 229 "attic-cleaning") drafts ([NewtrkHistoric], [NewtrkAntique]) to be 230 approved, the opportunities for using this STD model are obvious. 231 The relevant STD document could be used to quickly capture, not only 232 the fact that a document had been changed in status, but the date on 233 which that occurred and any useful information about the reason why 234 it was done -- using a much lighter-weight process than RFC 235 publication. However, this proposal is not tied to those in any way. 236 ]] 238 While RFCs are permanent, STD documents are expected to evolve and 239 incorporate changes over time. However, they are also expected to 240 include explicit change histories in order to make it possible for a 241 reader to examine a current STD document and determine the status of 242 the relevant standard at any particular previous time. And STD 243 number, once bound to a particular conceptual standard, is never 244 reused for a different concept. 246 4. Content and Organization of an STD Document 248 [[Note in draft: this section still needs a good deal of work, but it 249 is probably better to see if agreement can be reached on the 250 principles here before too much time is spent on details.]] 252 An STD document is expected to follow the general layout and 253 formatting conventions of an RFC (because the community is familiar 254 with them). The components listed below may appear, or are expected 255 to appear (required materials, even if only pro-forma, are identified 256 with asterisks). As with RFCs, additional sections may be included 257 as needed and appropriate. Note that STDs don't have authors: the 258 RFCs have authors, but the "author" of an STD would always be "IETF" 259 (or the historical "Network Working Group") so there is no 260 information in providing a name. A individual who had made a major 261 contribution to the STD document itself might be listed in an 262 Acknowledgement or as a Contributor. 264 Title.* It would be good for standards to have titles. As others 265 have pointed out, it would make them, especially those that 266 involve multiple RFCs, a lot easier to talk about. 267 Date.* This is the data the STD was last updated. Everything else 268 belongs in history or annotation. 269 Abstract.* As with the title, it would be good to have these for 270 standards, describing what the whole package does and not just 271 what individual RFCs do. 272 Maturity Level.* This is the maturity level for the STD as a whole. 273 Presumably it is the lowest maturity level of any of the 274 associated RFCs but, especially when one of the RFCs is intended 275 to replace an earlier, more mature one, and text is supplied below 276 that describes the situation, the IESG might decide to have it 277 reflect the maturity level associate with the least mature 278 document needed to form a full description of the standard. 279 Additional comments may be associated with this section; it need 280 not be just a label. If an STD is retired in its entirety, no 281 matter what maximum maturity level it reached earlier, this entry 282 may be "Historic" with optional descriptive text. 283 RFC list.* For each RFC that is currently associated with this STD, 284 the name, title, document date, and maturity level most recently 285 assigned and its date. Optionally, an abbreviated abstract, 286 applicability comments, errata, and other notes and commentary can 287 be associated with some or all of the RFCs. When there is a 288 non-obvious relationship among the various documents, it should be 289 described either here or in the applicability remarks below, as 290 appropriate (or in a separate section, if one is required). 291 Applicability Remarks about the standard. 292 Security Remarks about the standard. 293 History*. This section should define the entire record of changes to 294 the definition of the documents and applicability statements that 295 make up the standard, with dates identified. It should, in 296 particular, identify the point at which one document superceded or 297 updated another. 299 5. Transition 301 Obviously, there are many STD numbers assigned today that are not 302 associated with documents as described here. If this process is not 303 bootstrapped with those numbers, it probably won't work. So the 304 following approach, which can be applied more less mechanically, is 305 suggested: 307 o For each existing STD number, create a prototype STD document. 308 This step and the following one can be done from the existing 309 std-index being maintained by the RFC Editor. 310 o Populate that document with the list of RFCs now associated with 311 the STD and identify all of them as Internet Standards. 312 o Populate the title and abstract with the title and abstract of the 313 first RFC in the series. This won't be perfect, and in some 314 cases, won't be even close, but it is better than nothing (and 315 _much_ better than getting stuck waiting for someone to interpret 316 the RFCs and do a write-up. 317 o Omit any applicability, errata, or similar sections. 318 o Populate the History section with a note to the effect that the 319 Standard existed before the relevant date and the document is 320 initialized as of that date. 322 6. Operational Issues 324 There is a case to be made that creating this sort of document series 325 is additional work for the IESG. In practice, this author doesn't 326 believe it, at least to any significant degree. All of the relevant 327 information is created today. It is scattered in meeting minutes and 328 secretariat notes, protocol action notices, discussions about whether 329 to restart WGs to deal with problems, etc. Today that information, 330 much of it quite useful, gets lost or at least becomes quite 331 difficult to find. Conversely, these series should reduce workload 332 by considerably reducing the pressure to find editors to write or 333 rewrite RFCs whose purpose is ultimately "this document is just like 334 RFC xxxx, except that section 3.1.3 is removed to permit promoting 335 the specification to the next maturity level. The IESG can certainly 336 still insist on that procedure if it deems it necessary, but it 337 should also be possible to Last Call a revised STD document that 338 contains more or less that sentence and not touch the RFC at all. 339 And, if a WG responsible for creating or updating an STD document 340 can't come up with an appropriate title and abstract/brief 341 description, we are in a kind of trouble that goes well beyond any 342 procedural issues. 344 This document carefully does not specify the registry mechanism for 345 assigning new STD numbers, nor the publication and repository 346 mechanism for the documents. Either or both might sensibly be done 347 by the RFC Editor (that arrangement would certainly be consistent 348 with historical precedents), but, if only because the STD series in 349 this form would be a new task for them, it seems wise to leave this 350 question to the IETF administrative process to sort out as seems 351 appropriate in the broad administrative context. 353 7. References to STDs or References to RFCs 355 Before this proposal was generated, vendors who wished to specify 356 what they support, and potential customers who wished to specify what 357 they wanted to purchase, had a choice between referencing specific 358 RFCs (to get precision) or, for full standards, a specific STD number 359 (to get "the most current version"). Except for providing an "STD" 360 mechanism for referencing documents other than full Internet 361 Standards, this proposal does not change either of those options: 362 both are still free to use the existing forms. In the rare case in 363 which a vendor is deliberately attempting to confuse its potential 364 customers, this mechanism is not likely to help very much either. It 365 does, however, provide a third option, which is to specify the state 366 of an STD as of a particular date (even a date in the past or future) 367 or within a particular date range. So, whatever the referencing 368 issues are today, this certainly does not make them worse and almost 369 certainly makes them better. 371 8. IANA Considerations 373 This document does not anticipate any specific tasks for the IANA. 374 However, over time, it may be desirable to review and update the 375 descriptions of various registries to refer to STD numbers, rather 376 than RFC numbers, as the definitions or authority for those 377 registries. See also Section 6. 379 9. Security Considerations 381 This document specifies an administrative procedure for the IETF and 382 hence does not raise any new issues about the security of the 383 Internet. However, the availability of the type of document 384 described here may provide a convenient mechanism and repository of 385 vulnerabilities and other issues that are discovered after RFCs are 386 issued but that do not justify updating (or for which resources are 387 not available to update) the relevant RFC. Having an obvious place 388 to look for those notifications and discussions for standards-track 389 documents might enhance overall security somewhat. 391 10. Acknowledgements 393 The general ideas described here have been discussed on and off for 394 several years, but have never been turned into a public documents. 395 Thanks are due to several generations of IAB and IESG members and to 396 RFC Editor staff for helping to clarify the ideas and to identify 397 some variants that would or would not work. The ideas in this 398 specific presentation are, of course, those of the author and are one 399 with which some of the contributors might disagree. Pekka Savola 400 provided extensive and very useful comments on a preliminary version 401 of the initial draft. 403 11. References 405 11.1 Normative References 407 [RFC2026] Bradner, S., "The Internet Standards Process -- Revision 408 3", BCP 9, RFC 2026, October 1996. 410 [WhatStandards] 411 Loughney, J., "Standards, What Standards?", 412 draft-loughney-what-standards-01 (work in progress), 413 February 2004. 415 11.2 Informative References 417 [NewtrkAntique] 418 Klensin, J., "Valuable Antique Documents: A Model for 419 Advancement", draft-klensin-newtrk-antiques-00 (work in 420 progress), May 2004. 422 [NewtrkHistoric] 423 Alvestrand, H. and E. Lear, "Moving documents to Historic: 424 A procedure", draft-alvestrand-newtrk-historical-00 (work 425 in progress), March 2004. 427 [RFC2223] Postel, J. and J. Reynolds, "Instructions to RFC Authors", 428 RFC 2223, October 1997. 430 [rfc2223bis] 431 Reynolds, J. and R. Braden, "Instructions to Request for 432 Comments (RFC) Authors", draft-rfc-editor-rfc2223bis-07 433 (work in progress), August 2003. 435 Author's Address 437 John C Klensin 438 1770 Massachusetts Ave, #322 439 Cambridge, MA 02140 440 USA 442 Phone: +1 617 491 5735 443 EMail: john-ietf@jck.com 445 Intellectual Property Statement 447 The IETF takes no position regarding the validity or scope of any 448 Intellectual Property Rights or other rights that might be claimed to 449 pertain to the implementation or use of the technology described in 450 this document or the extent to which any license under such rights 451 might or might not be available; nor does it represent that it has 452 made any independent effort to identify any such rights. Information 453 on the procedures with respect to rights in RFC documents can be 454 found in BCP 78 and BCP 79. 456 Copies of IPR disclosures made to the IETF Secretariat and any 457 assurances of licenses to be made available, or the result of an 458 attempt made to obtain a general license or permission for the use of 459 such proprietary rights by implementers or users of this 460 specification can be obtained from the IETF on-line IPR repository at 461 http://www.ietf.org/ipr. 463 The IETF invites any interested party to bring to its attention any 464 copyrights, patents or patent applications, or other proprietary 465 rights that may cover technology that may be required to implement 466 this standard. Please address the information to the IETF at 467 ietf-ipr@ietf.org. 469 Disclaimer of Validity 471 This document and the information contained herein are provided on an 472 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 473 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 474 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 475 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 476 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 477 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 479 Copyright Statement 481 Copyright (C) The Internet Society (2004). This document is subject 482 to the rights, licenses and restrictions contained in BCP 78, and 483 except as set forth therein, the authors retain all their rights. 485 Acknowledgment 487 Funding for the RFC Editor function is currently provided by the 488 Internet Society.