idnits 2.17.1 draft-ietf-newtrk-repurposing-isd-02.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 16. -- Found old boilerplate from RFC 3978, Section 5.5 on line 810. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 787. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 794. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 800. ** 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 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 (March 12, 2005) is 6985 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) -- Duplicate reference: draft-ietf-newtrk-sample-isd, mentioned in 'ISD-Examples1', was also mentioned in 'ISD-Examples-Process'. -- Obsolete informational reference (is this intentional?): RFC 1602 (Obsoleted by RFC 2026) -- Obsolete informational reference (is this intentional?): RFC 2223 (Obsoleted by RFC 7322) Summary: 5 errors (**), 0 flaws (~~), 2 warnings (==), 10 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group J. Klensin 3 Internet-Draft J. Loughney 4 Expires: September 13, 2005 March 12, 2005 6 Internet Standards Documentation (ISDs) 7 draft-ietf-newtrk-repurposing-isd-02.txt 9 Status of this Memo 11 This document is an Internet-Draft and is subject to all provisions 12 of Section 3 of RFC 3667. By submitting this Internet-Draft, each 13 author represents that any applicable patent or other IPR claims of 14 which he or she is aware have been or will be disclosed, and any of 15 which he or she become aware will be disclosed, in accordance with 16 RFC 3668. 18 Internet-Drafts are working documents of the Internet Engineering 19 Task Force (IETF), its areas, and its working groups. Note that 20 other groups may also distribute working documents as 21 Internet-Drafts. 23 Internet-Drafts are draft documents valid for a maximum of six months 24 and may be updated, replaced, or obsoleted by other documents at any 25 time. It is inappropriate to use Internet-Drafts as reference 26 material or to cite them other than as "work in progress." 28 The list of current Internet-Drafts can be accessed at 29 http://www.ietf.org/ietf/1id-abstracts.txt. 31 The list of Internet-Draft Shadow Directories can be accessed at 32 http://www.ietf.org/shadow.html. 34 This Internet-Draft will expire on September 13, 2005. 36 Copyright Notice 38 Copyright (C) The Internet Society (2005). 40 Abstract 42 It has been observed that the current IETF standard designations, STD 43 nnnn and BCP nnnn designation, have not worked well. Problems have 44 been found when one of them is used either as a stable reference for 45 external specifications or as a combined reference for multiple 46 documents linked together into a single document. This document 47 proposes two changes to these designations. The first of these 48 changes would create a new document series and assign a new number 49 and acronym to a specification when it enters the first level of the 50 Standards Track (or is first designated as a BCP). The second would 51 migrate the concept of STDs and BCPs numbering of RFCs into actual 52 documents that detail what they identify, their publication 53 information and their change history. The document also specifies a 54 set of minor standards process changes to accommodate and integrate 55 the new style of doing things that is represented by the new document 56 series. 58 Table of Contents 60 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 61 2. Proposal Overview . . . . . . . . . . . . . . . . . . . . . 4 62 3. A New Document Series . . . . . . . . . . . . . . . . . . . 5 63 4. Publication and Formatting . . . . . . . . . . . . . . . . . 6 64 5. Content and Organization of an ISD Document . . . . . . . . 7 65 6. Transition . . . . . . . . . . . . . . . . . . . . . . . . . 8 66 7. Operational Issues . . . . . . . . . . . . . . . . . . . . . 9 67 8. References to ISDs or References to RFCs . . . . . . . . . . 10 68 9. References from ISDs . . . . . . . . . . . . . . . . . . . . 11 69 9.1 Document References . . . . . . . . . . . . . . . . . . . 11 70 9.2 Errata and Corrections . . . . . . . . . . . . . . . . . . 11 71 10. IANA Considerations . . . . . . . . . . . . . . . . . . . . 12 72 11. Security Considerations . . . . . . . . . . . . . . . . . . 12 73 12. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 12 74 13. Changes from Previous Versions . . . . . . . . . . . . . . . 12 75 14. References . . . . . . . . . . . . . . . . . . . . . . . . . 13 76 14.1 Normative References . . . . . . . . . . . . . . . . . . 13 77 14.2 Informative References . . . . . . . . . . . . . . . . . 13 78 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . 14 79 A. Motivation and Historical Context . . . . . . . . . . . . . 15 80 A.1 Problem(s) . . . . . . . . . . . . . . . . . . . . . . . . 15 81 A.2 Periodic Reviews of Protocols are not Being Carried Out . 16 82 A.3 There is no Maintenance Team Responsible for a Protocol . 16 83 B. Notes on the Design . . . . . . . . . . . . . . . . . . . . 16 84 B.1 Comments, discussion notes, and proposed errata . . . . . 16 85 B.2 Numbers versus Names . . . . . . . . . . . . . . . . . . . 17 86 B.3 Citations of Informative Material . . . . . . . . . . . . 17 87 Intellectual Property and Copyright Statements . . . . . . . 18 89 1. Introduction 91 The IETF has produced a large (and useful) body of work. In many 92 ways, the IETF has been a victim of its own (or at least of TCP/IP's) 93 success. As the standards which the IETF produces see wider 94 deployment by parties outside of the IETF, the system of 95 documentation and updating within the IETF causes some amount of 96 confusion. 98 The "STD" and "BCP" labels are described in [RFC2026] as subseries of 99 the RFC series, with their numbers being assigned when documents are 100 published as Internet Standards or as BCPs. The purpose and 101 organization of the STD series is defined in more detail in 102 [RFC1311]. Beyond those brief statements, the organization of the 103 two series and the classification of documents as either belonging 104 together as part of a single "STD" specification or as separate, have 105 largely been a matter of oral tradition, with more of the decisions 106 being made as part of the RFC indexing process than explicitly by the 107 IESG as part of the standards process. RFC1311, written before the 108 standards process reforms of the 1992-1994 period (see, e.g., 109 [RFC1396] and [RFC1602]), assigns responsibility for defining the 110 content of STD documents to the IAB, but was never updated to reflect 111 the change to IESG responsibility for the standards track. The 112 intent has been to permit a stable reference to particular 113 specifications and groups of documents making up a specification, a 114 reference that survives replacement of one RFC with another, addition 115 or deletion of RFCs from the collective specification, and so on. 117 While the intentions are fairly clear and quite desirable, this 118 document suggests that the system has never worked well, especially 119 for STDs that comprise (or point to) several RFCs. There is no 120 easily-accessible audit track that specifies which documents were 121 part of an standard (identified by an STD number) at a particular 122 time (which can be very important for determining what a 123 specification that points to an STD actually means or requires). 124 Historically, the community and the IESG have not been heavily 125 involved in the process of organizing and grouping standards-track 126 documents by STD number. In retrospect, some of the decisions have 127 been, or should have been, controversial and have led to 128 misunderstandings about what is implied by conformance to a standard. 129 In addition, the "do not assign an STD number until the specification 130 reaches full Internet Standard" model is unrealistic in a world in 131 which much of the Internet runs on Proposed Standards and in which 132 the IETF only very rarely approves and publishes "Applicability 133 Statement" documents (and, when it does publish them, has little idea 134 what to do with them -- several documents that rationally fall into 135 that category have been published as BCPs instead). 137 This document creates a paper track and specific "benchmark" 138 documentation for Internet Standards. While the documents it 139 specifies may assist in the creation of dynamic web pages, or may be 140 linked to bug tracking systems, those are not its primary intent. 142 The discussion and proposal that follows are written in terms of 143 traditional standards track documents (Proposed, Draft, and Internet 144 Standard). Whether it should also be applied to BCPs needs further 145 review: the applicability is fairly obvious, but it is not clear 146 whether it is necessary enough to justify the extra trouble. 148 Appendix A describes some of the specific IETF issues, identified 149 during 2004, that led to the development of this specification. 151 Prototype examples of the type of documents contemplated here appear 152 in [ISD-Examples1] and, to a lesser extent, [ISD-Examples-Process]. 153 Those examples are just examples; they are not part of this 154 specification or definition. 156 [[Note in Draft (RFC Editor to remove this paragraph before 157 publication and after setting "Updates"): This document is intended 158 to update RFC 2026 with regard to Last Calls and how the standards 159 process is documented, RFC 3710 with regard to the IESG's list of 160 responsibilities and procedures, and RFC 3967 on references. It 161 obsoletes RFC 1311 on the STD document series; that document should 162 be moved to Historic when this one is approved. ]] 164 2. Proposal Overview 166 This document proposes that a new document series be created, called 167 Internet Standards Documents ("ISD"s) and that these be real 168 documents, separate from the underlying RFCs. The documents would be 169 managed under the direction of the IESG as part of the 170 standards-specification process, rather than being simply pointers in 171 indexes as, e.g., the STD series has been, or being the RFCs 172 themselves with different file names or packaging. It proposes that 173 ISD documents be created and numbers assigned when specifications 174 enter the formal standards track (Proposed Standard under the model 175 described in RFC 2026) and that the documents be used to track 176 maturation, applicability recommendations, and history of those 177 specifications. It also outlines the format of those documents, 178 which is expected to be different from the format of protocol 179 specification documents and the RFC series generally ([RFC2223], 180 [rfc2223bis]) and briefly discusses a transition strategy. 182 Debate continues in the IETF about the proper threshold for Proposed 183 Standards with regard to both protocol quality and document quality. 184 Part of the problem is the use of a single, unqualified, label that 185 may not be a good match to all situations. The documents proposed 186 here will allow more flexibility by permitting the IESG to attach 187 appropriate qualifying notes as needed. For example, if the 188 community concluded that a specification should be published as a 189 Proposed Standard, but that potential implementers should be warned 190 that IETF confidence in its stability was lower than usual, these 191 documents would be an appropriate place to publish that type of 192 evaluation. Conversely, if interoperable implementations already 193 existed before the Proposed Standard was published, the corresponding 194 STD document would be an appropriate place to note that fact. 196 These documents, and documents authoritatively (normatively) 197 referenced from them, will become, essentially, the definitions of 198 standards. Consequently, any changes to them will occur only under 199 IESG authority and responsibility. The IESG may, at its discretion, 200 and with appropriate announcements to, and consultation of, the 201 community, delegate authority for some sections to groups responsible 202 for the ongoing maintenance of the standards, but may not relinquish 203 responsibility for the documents themselves. However, nothing in 204 this specification prohibits (or requires) IESG authorization of 205 placement of links in the STD documents that point to less formal and 206 less authoritative discussions of, or comments on, the relevant 207 standards should they deem that appropriate. 209 By extension from the above, the IESG will need to make 210 determinations, ideally after creating guidelines and getting 211 community review and assent to them, as to criteria (e.g., length, 212 importance, degree of discussion needed) by which authoritative 213 comments and qualifications about standards will be incorporated into 214 the STDs documents or issued as separate RFCs. The starting point 215 and minimum descriptive and qualifying text for new standards will be 216 the text of the Protocol Action Notice. 218 3. A New Document Series 220 When the IESG agrees to move a document onto the standards track, it 221 either causes a new Internet Standard number ("ISD number") and name 222 or acronym ("ISD name") to be assigned to it, or classifies it as 223 part of an existing standard and assigns that number and name. If 224 multiple, related, specifications are approved at the same time, they 225 may be assigned the same ISD number and name. As those documents are 226 published as RFCs, the RFC may (and presumably usually will) contain 227 the standard number and name since it will constitute a stable 228 forward reference. This assignment of an ISD number and name, and 229 assignment of a specification to it, results in a corresponding ISD 230 document being created or updated, as described below. Following 231 good sense and existing precedent, the IESG may decide to include 232 documents that are not themselves on the standards track (e.g., 233 Informational documents explaining, or describing alternatives to, an 234 agreed-upon standard) in references from a ISD document once that 235 document is defined by the assignment of a name and number. 237 Advancement of a document on the standards track, publication of 238 applicability statements, notes on errata or other issues of 239 sufficient and substantive importance to require alerting 240 implementers or the community will also result in modifications to 241 the relevant ISD document. It is explicitly anticipated that 242 documents may be moved from one maturity level to another (i.e., 243 under the current system, to Draft, Full, or Historic, or from 244 Experimental to Proposed) by changing the ISD document to identify 245 the new level and include any relevant notes as an alternative to 246 modifying the relevant RFC text and issuing new RFCs (and, of course, 247 modifying the ISD document to reflect those changes). 249 Particular RFCs may move in and out of a ISD (except for the 250 historical record) as one RFC replaces another. Because the ISD 251 document is expected to contain prose, it will be possible to deal 252 with the long-standing issues of what "updates" means by identifying 253 the relevant sections or concepts. And, again because there is 254 descriptive prose present, the IESG will be able to deal 255 appropriately with the relationship between an old Full Standard and 256 a newer document, at a lower maturity level, that is intended to 257 replace it by specifying whatever they consider appropriate about 258 what the implementer or other reader should look at. 260 While RFCs are permanent, ISD documents are expected to evolve and 261 incorporate changes over time. However, they are also expected to 262 include explicit change histories in order to make it possible for a 263 reader to examine a current ISD document and determine the status of 264 the relevant standard at any particular previous time. An ISD number 265 or name, once bound to a particular conceptual standard, is never 266 reused for a different concept. 268 4. Publication and Formatting 270 ISDs constitute an entirely new document series, to be managed 271 directly by the IESG as part of its management of the standards 272 process. ISDs are not to be published as part of the RFC series. 273 The basic source format an ISD will be XML, conforming to an 274 appropriate and IESG-designated, Document Type Definition (DTD). For 275 archival and external reference purposes, the formal archival form of 276 the ISD will be ASCII text. However, it is anticipated that web 277 pages with embedded links will also be generated from the XML and 278 made accessible from the IETF home page. 280 Draft versions of ISDs or proposals for updating them may be posted 281 as Internet-Drafts. Such posting will generally be required in 282 conjunction with Last Calls unless the IESG devises an alternate 283 procedure. Since current Internet-Draft format requirements are 284 based on RFC formats and requirements, posting drafts for ISDs as 285 Internet-Drafts may require some extensions to the Internet-Draft 286 posting rules. 288 ISDs will be identified by a name and the combination of a 289 serially-assigned standard number and a date with resolution in days. 290 The numbers for ISDs and those for STDs (see [RFC1311]) are not 291 expected to be synchronized. 293 5. Content and Organization of an ISD Document 295 An ISD document is expected to follow the general layout and 296 formatting conventions of an RFC (because the community is familiar 297 with them). The components listed below may appear, or are expected 298 to appear (required materials, even if only pro-forma, are identified 299 with asterisks). As with RFCs, additional sections may be included 300 as needed and appropriate. Note that ISDs don't have authors: the 301 RFCs have authors, but the "author" of an ISD would always be "IETF" 302 (or the historical "Network Working Group") so there is no 303 information in providing an author or editor name. A individual who 304 had made a major contribution to the ISD document itself might be 305 listed in an Acknowledgement or as a Contributor. 307 Title.* It is desirable for standards to have titles as well as 308 numbers and acronyms (names). As others have pointed out, it 309 would make them, especially those that involve multiple RFCs, a 310 lot easier to talk about. For example, by common usage, the 311 "name" of an ISD might be "SMTP" with a title of "Simple Mail 312 Transfer Protocol". 313 Standard Acronym and Number* The ISD will be associated with both an 314 abbreviated name or acronym that is descriptive of the standard 315 and a standard number, the latter of which will be 316 serially-assigned. 317 Date.* This is the date the ISD was last updated. Everything else 318 belongs in history or annotation. This date will specify a day, 319 not just a month. 320 Abstract.* As with the title, it would be good to have these for 321 standards, describing what the whole package does and not just 322 what individual RFCs do. 323 Maturity, Implementations, and Applicability Level* 324 ISDs as a whole do not have maturity levels in the traditional 325 sense. At the same time, it is useful for the ISD to have a 326 section that provides information about implementation, 327 interoperability, and deployment experience. If some of the 328 normatively-referenced RFCs are intended to replace earlier, more 329 mature ones, the ISD would normally be expected to describe and 330 explain that situation. If an ISD is retired in its entirety, no 331 matter what maturity levels are associated with its individual 332 documents, this entry may be "Historic" with optional additional 333 descriptive text. 334 RFC list.* For each RFC that is currently associated with this ISD, 335 the name, title, document date, and maturity level most recently 336 assigned and its date. Optionally, an abbreviated abstract, 337 applicability comments, errata, and other notes and commentary can 338 be associated with some or all of the RFCs. When there is a 339 non-obvious relationship among the various documents, it should be 340 described either here or in the applicability remarks below, as 341 appropriate (or in a separate section, if one is required). 342 Applicability Remarks about the standard. Any remarks about 343 applicability that seem useful or appropriate, as authorized. 344 Security Remarks about the standard. Any authorized remarks about 345 the security implications or considerations of the standard that 346 are not completely reflected in the component RFCs. 347 History*. This section should define the entire record of changes to 348 the definition of the documents and applicability statements that 349 make up the standard, with dates identified. It should, in 350 particular, identify the point at which one document superseded or 351 updated another. 353 6. Transition 355 Obviously, we now have many full Internet Standards, with STD numbers 356 assigned and packaging defined by those numbers, that are not 357 associated with documents as described here. We have even more 358 documents at Proposed or Draft Standard levels that do not have 359 either documents of this type or grouping. Some of those documents 360 should almost certainly be bound to existing packages defined by STD 361 numbers. If this process is not bootstrapped by issuing ISDs for 362 those documents, it probably won't work. So the following approach, 363 which can be applied more less mechanically, is suggested: 365 o For each existing STD number, assign a name or acronym and create 366 a prototype ISD document. Reuse of the STD numbers as ISD numbers 367 would save some time and avoid some confusion. This step and the 368 management of titles and abstracts, as discussed below, can be 369 done from the existing std-index being maintained by the RFC 370 Editor. 371 o Populate that document with the list of RFCs now associated with 372 the ISD and identify all of them as Internet Standards. 373 o For each existing Proposed or Draft Standard, generate a template 374 document and assign a name and number. Exceptions should be made 375 and documents grouped when it is obvious and uncontroversial that 376 several documents belong together and someone can be found to do 377 the work. Initial assignments and drafts should be created on an 378 area basis, preferably by directorates or specially-selected 379 committees, coordinating with any reclassification efforts to 380 avoid duplicate work. 381 o Populate the title and abstract with the title and abstract of the 382 first RFC in the series. This won't be perfect, and in some 383 cases, won't be even close, but it is better than nothing (and 384 _much_ better than getting stuck waiting for someone to interpret 385 the RFCs and do a write-up. 386 o Omit any applicability, errata, or similar sections but include, 387 for convenience, links to the RFC Editor's errata page where 388 applicable. 389 o Populate the History section with a note to the effect that the 390 Standard existed before the relevant date and the document is 391 initialized as of that date. 392 o As these documents are created, and to avoid having to create all 393 of them at once, modify the official rfc-index and other indices 394 and web pages under IETF control to indicate either the name and 395 number of the ISD document or that the relevant document is still 396 under construction. 397 o It will be important to preserve the STD numbers and index for 398 some time, perhaps indefinitely, because some references exist to 399 them. However, it will not be necessary to expand that list. 400 Absorbing the STD numbering space into the ISD series will further 401 aid in locating appropriate information. 403 7. Operational Issues 405 There is a case to be made that creating this sort of document series 406 is additional work for the IESG. In practice, the authors don't 407 believe it, at least to any significant degree. All of the relevant 408 information is created today. It is scattered in meeting minutes and 409 secretariat notes, protocol action notices, discussions about whether 410 to restart WGs to deal with problems, etc. Today that information, 411 much of it quite useful, gets lost or at least becomes quite 412 difficult to find. Conversely, these series should reduce workload 413 by considerably reducing the pressure to find editors to write or 414 rewrite RFCs whose purpose is ultimately "this document is just like 415 RFC xxxx, except that section 3.1.3 is removed to permit promoting 416 the specification to the next maturity level". The IESG can 417 certainly still insist on that procedure if it deems it necessary, 418 but it should also be possible to Last Call a revised ISD that 419 contains more or less that sentence and not touch the RFC at all. 420 And, if a WG responsible for creating or updating an ISD can't come 421 up with an appropriate title and abstract/brief description, we are 422 in a kind of trouble that goes well beyond any procedural issues. 424 For a new specification document intended to be processed onto the 425 standards track (including non-procedural BCPs), responsibility for 426 preparing a draft of a new or revised ISD and advising on whether the 427 standards-track document will require a new ISD number or become part 428 of an existing ISD lies with the relevant WG or other submitter. The 429 IESG will issue a Last Call that includes the proposed ISD text along 430 with the substantive document(s). They will then modify the ISD text 431 as needed based on input during Last Call and internal discussions. 432 In general, the new or revised ISD will be issued at the same time as 433 (or replacing) the Protocol Action Notice, referencing the approved 434 Internet-Draft and containing copies of any RFC Editor instructions. 435 That material would then be replaced in the ISD when the relevant 436 documents are published. 438 The ISD document is intended to become the repository for the 439 substantive content of Protocol Action Notices and for IESG 440 statements and qualifications about what they are approving. This 441 will include any "known defects" or "this must be fixed when the 442 document is advanced to the next maturity level" statements. 444 It is the intent of this specification that all substantive or 445 normative changes to an ISD be the result of IETF consensus, i.e., 446 that the change be made only after a Last Call and IESG review and 447 approval. However, more flexibility and less formality is 448 appropriate for at least some non-normative changes, commentary, etc. 449 The IESG is tasked with specifying and documenting the types of 450 changes that do not require Last Calls or IESG approval, and the 451 processes for making those changes. 453 This document carefully does not specify the registry mechanism for 454 assigning new ISD numbers, nor the details of publication and 455 repository mechanisms for the documents although it specifies some 456 requirements for them (see Section 4). Either or both might sensibly 457 be done by the RFC Editor (that arrangement would certainly be 458 consistent with historical precedents), but, if only because the ISD 459 series would be a new task for them, it seems wise to leave this 460 question to the IETF administrative process to sort out as seems 461 appropriate in the broad administrative context. 463 Regardless of what organizational arrangements are responsible for 464 updating and maintaining these documents, and in spite of their 465 containing a cumulative change history, they should be treated as 466 archival -- at least as archival as the RFC series. 468 8. References to ISDs or References to RFCs 470 Before this proposal was generated, vendors who wished to specify 471 what they support, and potential customers who wished to specify what 472 they wanted to purchase, had a choice between referencing specific 473 RFCs (to get precision) or, for full standards, a specific STD number 474 (to get "the most current version"). Except for providing an "ISD" 475 mechanism for referencing documents other than full Internet 476 Standards, this proposal does not change either of those options: 477 both are still free to use the existing forms. In the rare case in 478 which a vendor is deliberately attempting to confuse its potential 479 customers, this mechanism is not likely to help very much either. It 480 does, however, provide a third option, which is to specify the state 481 of an STD as of a particular date (even a date in the past or future) 482 or within a particular date range. So, whatever the referencing 483 issues are today, this certainly does not make them worse and almost 484 certainly makes them better. 486 It should also be noted that other Standardization bodies have had 487 difficulties when referencing RFCs. It is not always clear whether 488 an RFC or an STD should be referenced. When a reference is made, 489 there can be problems when the RFC that is referenced becomes updated 490 or obsoleted. 492 9. References from ISDs 494 9.1 Document References 496 An ISD can be thought of as anchored in one of more "base documents" 497 -- RFCs that, in combination, specify the technical content of the 498 standard itself. These based documents must be standards-track 499 technical specifications or operational or Applicability Statement 500 BCPs (i.e., not IETF-process BCPs, see [Standing-Docs]). All 501 references to base documents are, essentially by definition, 502 normative and must follow the traditional rules of the RFC Editor for 503 stability of references (see, e.g., [RFC2223]) as modified by 504 [RFC3967]. However, an ISD may reference, informationally, any 505 document or material felt to be helpful in understanding the standard 506 or its context. 508 References to, and discussion of, base documents may, and normally 509 will, associate standards-track maturity levels with those documents. 510 The underlying RFCs themselves are no longer considered to have such 511 maturity levels. 513 9.2 Errata and Corrections 515 Errata and other corrections that represent IETF consensus (i.e., 516 based on an IESG, or IESG-delegated, determination after Last Call) 517 are normative and identified in a way that distinguishes them from 518 suggested errata or changes that are not known to represent IETF 519 consensus. The latter may still be included in the ISD document as 520 informative material under the general "felt to be helpful" provision 521 of the previous section. 523 10. IANA Considerations 525 This document does not anticipate any specific tasks for the IANA. 526 However, over time, it may be desirable to review and update the 527 descriptions of various registries to refer to ISD numbers, rather 528 than RFC numbers, as the definitions or authority for those 529 registries. See also Section 7. 531 11. Security Considerations 533 This document specifies an administrative procedure for the IETF and 534 hence does not raise any new issues about the security of the 535 Internet. However, the availability of the type of document 536 described here may provide a convenient mechanism and repository of 537 vulnerabilities and other issues that are discovered after RFCs are 538 issued but that do not justify updating (or for which resources are 539 not available to update) the relevant RFC. Having an obvious place 540 to look for those notifications and discussions for standards-track 541 documents might enhance overall security somewhat. 543 12. Acknowledgements 545 The general ideas described here have been discussed on and off for 546 several years, but have never been turned into public documents. 547 Thanks are due to several generations of IAB and IESG members and to 548 RFC Editor staff for helping to clarify the ideas and to identify 549 some variants that would or would not work. The ideas in this 550 specific presentation are, of course, those of the author and are one 551 with which some of the contributors might disagree. Pekka Savola 552 provided extensive and very useful comments on a preliminary version 553 of the initial draft. Harald Alvestrand, Bob Braden, and several 554 others made comments on the first posted draft that resulted in 555 important clarifications. Discussions during and after IETF 60 led 556 to further changes and the consolidation of the previous relevant 557 documents. Bob Braden suggested not trying to reuse the term "STD", 558 and provided new term "ISD". Additional helpful comments and 559 corrections were provided by Pekka Savola and Scott Bradner. 561 13. Changes from Previous Versions 563 [[Note in Draft: This section is to be removed before RFC 564 publication]] 565 Version 00. This version replaces and consolidates the previous 566 documents "Repurposing the STD Designation" 567 (draft-klensin-newtrk-std-repurposing-00.txt, 6 June 2004) and 568 "Standards, What Standards?" 569 (draft-loughney-what-standards-01.txt, February 2004). It also 570 includes a number of editorial clarifications and a few more 571 details than its predecessors. The tone is still somewhat 572 informal and conversational; if general consensus is reached on 573 the ideas, that should be corrected, in both the text and the 574 abstract, in a subsequent draft. 575 Version 01. This version incorporates the changes and clarifications 576 discussed in a meeting of the NEWTRK WG at IETF 61 (Washington, 577 DC, USA, November 2004) and on the mailing list in the subsequent 578 weeks. While some outstanding issues and possible issues remain, 579 the document has been considerably tightened up and a number of 580 previous loose ends documented. In the process, some of the 581 conversational text in the previous versions (see above) has been 582 edited into a more formal form. Most of the "why is this 583 justified and being done" material has been moved to an appendix 584 in order to facilitate eventually turning the Internet-Draft into 585 a permanent IETF process specification. 586 Version 02. This version incorporates the changes and clarifications 587 discussed in the NEWTRK WG meeting at IETF 62 (Minneapolis, MN, 588 USA, March 2005). All non-editorial "notes in draft" have been 589 resolved, and those that discuss design choices have been removed 590 to an appendix. 592 14. References 594 14.1 Normative References 596 [RFC2026] Bradner, S., "The Internet Standards Process -- Revision 597 3", BCP 9, RFC 2026, October 1996. 599 [RFC3967] Bush, R. and T. Narten, "Clarifying when Standards Track 600 Documents may Refer Normatively to Documents at a Lower 601 Level", BCP 97, RFC 3967, December 2004. 603 14.2 Informative References 605 [ISD-Examples-Process] 606 Bradner, S., "Sample ISD for the IETF Standards Process", 607 Internet-Draft draft-ietf-newtrk-sample-isd-00, October 608 2004. 610 [ISD-Examples1] 611 Klensin, J., "Internet Standards Documentation (ISDs) - 612 Examples", Internet-Draft draft-ietf-newtrk-sample-isd-00, 613 October 2004. 615 [RFC1311] Postel, J., "Introduction to the STD Notes", RFC 1311, 616 March 1992. 618 [RFC1396] Crocker, S., "The Process for Organization of Internet 619 Standards Working Group (POISED)", RFC 1396, January 1993. 621 [RFC1602] Huitema, C. and P. Gross, "The Internet Standards Process 622 -- Revision 2", RFC 1602, March 1994. 624 [RFC2223] Postel, J. and J. Reynolds, "Instructions to RFC Authors", 625 RFC 2223, October 1997. 627 [RFC3774] Davies, E., "IETF Problem Statement", RFC 3774, May 2004. 629 [Standing-Docs] 630 Klensin, J., "Standing Documents Describing IETF Processes 631 and Operations", Internet-Draft draft-ietf-newtrk-sd-00, 632 February 2004. 634 [rfc2223bis] 635 Reynolds, J. and R. Braden, "Instructions to Request for 636 Comments (RFC) Authors", 637 Internet-Draft draft-rfc-editor-rfc2223bis-07, August 638 2003. 640 Authors' Addresses 642 John C Klensin 643 1770 Massachusetts Ave, #322 644 Cambridge, MA 02140 645 USA 647 Phone: +1 617 491 5735 648 Email: john-ietf@jck.com 650 John A Loughney 651 Itamerenkatu 11-13 652 Helsinki, 00180 653 Finland 655 Phone: +358 5 04836242 656 Email: john.loughney@nokia.com 658 Appendix A. Motivation and Historical Context 660 Appendix A.1 Problem(s) 662 The following problems are excerpted from Section 2.4 of the IETF 663 Problem statement [RFC3774]. 665 o Relatively few specifications are now progressed beyond Proposed 666 Standard (PS) to Draft Standard (DS) level, and even fewer to Full 667 Standard (FS). 668 o There is no formal bug reporting or tracking system in place for 669 IETF specifications. 670 o The periodic review of protocols at PS and DS levels specified in 671 are not being carried out, allowing protocols to persist in these 672 lower maturity levels for extended periods of time, whereas the 673 process would normally expect them to progress or be relegated to 674 Historic status. 675 o No individual or body is given the task of 'maintaining' a 676 specification after the original WG has closed down. 677 Specifications are generally only updated when a need for a new 678 version is perceived. No attempt is normally made to correct bugs 679 in the specification (whether they affect operation or not) and 680 the specification is not updated to reflect parts of the 681 specification that have fallen into disuse or were, in fact, never 682 implemented. This is in part because the current procedures would 683 require a standard to revert to the PS maturity level even when 684 specification maintenance is carried out which can be demonstrated 685 to have no or minimal effect on an existing protocol at DS or FS 686 level. 687 o Few Specifications Progress Beyond Proposed Standard. 688 The IETF, as of late, does not have a good track record of moving 689 protocols beyond Proposed Standard. In fact, the goal of most 690 Working Groups is to produce a set of RFCs and then shut down. 691 Working groups that do this are considered to have succeeded. 692 There are only a handful of long-lived working groups, such as 693 IPv6, whose charters include progressing standards beyond Proposed 694 Standards. Occasionally, new working groups need to be spun up to 695 make sense of the existing set of RFCS, such as tcpm (TCP 696 Maintenance). 697 o There is no Formal Bug Reporting or Tracking System. 698 Bugs in a specification can be found at any point. There have 699 been bugs found even in Full Standards. How do we ensure 700 correctness in our own standards? 702 This document does not take a stand on the issue of the relevance of 703 the current standards track. It does note that at any given moment, 704 a standard may be undergoing work to progress the document to another 705 level. We discuss the problems identified in more detail below. 707 Appendix A.2 Periodic Reviews of Protocols are not Being Carried Out 709 Many protocols suffer from benign neglect. The working group charged 710 with developing the protocol becomes dormant or is shut down. The 711 principal authors of the specification may no longer be involved in 712 the IETF. Further development of the protocol may even be officially 713 discouraged. 715 Other standards development organizations (SDOs) may consider 716 extensions or modification to the protocols. This causes problems 717 for parties interested in the technology, as it becomes unclear as to 718 exactly what specifies a particular protocol. Additionally, it makes 719 it hard to track errors in or updates to a specification or protocol. 721 Appendix A.3 There is no Maintenance Team Responsible for a Protocol 723 Specifications are generally only updated when a need for a new 724 version is perceived. No attempt is normally made to correct bugs in 725 the specification (whether they affect operation or not) and the 726 specification is not updated to reflect parts of the specification 727 that have fallen into disuse or were, in fact, never implemented. 728 This is in part because the current procedures would require a 729 standard to revert to the PS maturity level even when specification 730 maintenance is carried out which can be demonstrated to have no or 731 minimal effect on an existing protocol at DS or FS level. 733 Appendix B. Notes on the Design 735 In the process of developing this specification, several notes and 736 comment were made about tradeoffs. Those notes appear below, 737 essentially unedited. They are not a normative part of the 738 specification. 740 Appendix B.1 Comments, discussion notes, and proposed errata 742 If makes sense to the community to have an archive of comments, 743 discussion, or proposed errata on the documents, that is fine, and it 744 would be useful for these documents to identify the locations of 745 those archives. But we should be very careful that the contents of 746 such archives are not confused with the content of the specifications 747 unless they go through some sort of formal review and consensus 748 process. The description of that process in the specification is 749 deliberately open-ended and flexible. If the IESG is willing to 750 accept and maintain formal responsibility for whatever appears in ISD 751 documents, they could include some non-normative changes being made 752 by, e.g., maintenance committees should the community want to move in 753 that direction. 755 Appendix B.2 Numbers versus Names 757 There was an extended debate in the Working Group as to whether ISDs 758 were better identified by acronyms or serial numbers. There are 759 advantages to names or acronyms and and to numbers. The former are 760 easier to remember as long as there are not too many of them and are 761 usually more human friendly. The latter are very precise and 762 language-independent. The choice between the two did not appear to 763 be worth the amount of energy it would have taken to reach consensus, 764 if even that were possible. Consequently, the document recommends 765 assigning both a number and a name (acronym or other string) to each 766 ISD. 768 Appendix B.3 Citations of Informative Material 770 There is discussion in Section 9.1 about the inclusion of informative 771 (non-normative) material, but no specific guidance is given about 772 what material is and is not appropriate, other than that it is "felt 773 to be helpful". The apparent ambiguity is deliberate, relying on 774 good sense and the requirement that substantive changes to ISDs must 775 be Last Called in the IETF, rather than an attempt to make specific 776 rules that would probably be inappropriate for some future situation. 778 Intellectual Property Statement 780 The IETF takes no position regarding the validity or scope of any 781 Intellectual Property Rights or other rights that might be claimed to 782 pertain to the implementation or use of the technology described in 783 this document or the extent to which any license under such rights 784 might or might not be available; nor does it represent that it has 785 made any independent effort to identify any such rights. Information 786 on the procedures with respect to rights in RFC documents can be 787 found in BCP 78 and BCP 79. 789 Copies of IPR disclosures made to the IETF Secretariat and any 790 assurances of licenses to be made available, or the result of an 791 attempt made to obtain a general license or permission for the use of 792 such proprietary rights by implementers or users of this 793 specification can be obtained from the IETF on-line IPR repository at 794 http://www.ietf.org/ipr. 796 The IETF invites any interested party to bring to its attention any 797 copyrights, patents or patent applications, or other proprietary 798 rights that may cover technology that may be required to implement 799 this standard. Please address the information to the IETF at 800 ietf-ipr@ietf.org. 802 Disclaimer of Validity 804 This document and the information contained herein are provided on an 805 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 806 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 807 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 808 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 809 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 810 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 812 Copyright Statement 814 Copyright (C) The Internet Society (2005). This document is subject 815 to the rights, licenses and restrictions contained in BCP 78, and 816 except as set forth therein, the authors retain all their rights. 818 Acknowledgment 820 Funding for the RFC Editor function is currently provided by the 821 Internet Society.