idnits 2.17.1 draft-ietf-newtrk-repurposing-isd-03.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 on line 14. -- Found old boilerplate from RFC 3978, Section 5.5 on line 1024. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 1001. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 1008. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 1014. ** 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. 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 : ---------------------------------------------------------------------------- == There are 2 instances of lines with non-RFC2606-compliant FQDNs in the document. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (April 22, 2005) is 6943 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: 3 errors (**), 0 flaws (~~), 3 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: October 24, 2005 April 22, 2005 6 Internet Standards Documentation (ISDs) 7 draft-ietf-newtrk-repurposing-isd-03.txt 9 Status of this Memo 11 By submitting this Internet-Draft, each author represents that any 12 applicable patent or other IPR claims of which he or she is aware 13 have been or will be disclosed, and any of which he or she becomes 14 aware will be disclosed, in accordance with Section 6 of BCP 79. 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 Internet- 19 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 October 24, 2005. 34 Copyright Notice 36 Copyright (C) The Internet Society (2005). 38 Abstract 40 It has been observed that the current IETF standard designations, STD 41 nnnn and BCP nnnn designation, have not worked well. Problems have 42 been found when one of them is used either as a stable reference for 43 external specifications or as a combined reference for multiple 44 documents linked together into a single document. This document 45 proposes two changes to these designations. The first of these 46 changes would create a new document series and assign a new number 47 and acronym to a specification when it enters the first level of the 48 Standards Track (or is first designated as a BCP). The second would 49 migrate the concept of STDs and BCPs numbering of RFCs into actual 50 documents that detail what they identify, their publication 51 information and their change history. The document also specifies a 52 set of minor standards process changes to accommodate and integrate 53 the new style of doing things that is represented by the new document 54 series. 56 Table of Contents 58 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 59 2. Proposal Overview . . . . . . . . . . . . . . . . . . . . . . 4 60 3. A New Document Series . . . . . . . . . . . . . . . . . . . . 5 61 4. Publication and Formatting . . . . . . . . . . . . . . . . . . 6 62 5. Content and Organization of an ISD Document . . . . . . . . . 7 63 6. Procedure for New Standards and Associated ISDs . . . . . . . 8 64 6.1 Replacement for RFC 2026, Section 6.1.1 . . . . . . . . . 9 65 6.2 Replacement for the third paragraph of RFC 2026, 66 Section 6.1.2 . . . . . . . . . . . . . . . . . . . . . . 9 67 6.3 Insertion at the end of RFC 2026, Section 6.1.2 . . . . . 10 68 6.4 Replacement for first paragraph of RFC 2026 Section 69 6.1.3 . . . . . . . . . . . . . . . . . . . . . . . . . . 10 70 7. Transition . . . . . . . . . . . . . . . . . . . . . . . . . . 10 71 8. Operational Issues . . . . . . . . . . . . . . . . . . . . . . 12 72 9. References and Citations Involving ISDs . . . . . . . . . . . 13 73 9.1 References to ISDs or References to RFCs . . . . . . . . . 13 74 9.2 References from ISDs . . . . . . . . . . . . . . . . . . . 14 75 9.2.1 Document References . . . . . . . . . . . . . . . . . 14 76 9.2.2 Errata and Corrections . . . . . . . . . . . . . . . . 14 77 9.3 Citing an ISD . . . . . . . . . . . . . . . . . . . . . . 14 78 10. IANA Considerations . . . . . . . . . . . . . . . . . . . . 15 79 11. Security Considerations . . . . . . . . . . . . . . . . . . 15 80 12. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 15 81 13. Changes from Previous Versions . . . . . . . . . . . . . . . 15 82 14. References . . . . . . . . . . . . . . . . . . . . . . . . . 16 83 14.1 Normative References . . . . . . . . . . . . . . . . . . . 16 84 14.2 Informative References . . . . . . . . . . . . . . . . . . 16 85 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 17 86 A. Motivation and Historical Context . . . . . . . . . . . . . . 18 87 A.1 Problem(s) . . . . . . . . . . . . . . . . . . . . . . . . 18 88 A.2 Periodic Reviews of Protocols are not Being Carried Out . 19 89 A.3 There is no Maintenance Team Responsible for a Protocol . 19 90 B. Notes on the Design . . . . . . . . . . . . . . . . . . . . . 19 91 B.1 Comments, discussion notes, and proposed errata . . . . . 19 92 B.2 Numbers versus Names . . . . . . . . . . . . . . . . . . . 20 93 B.3 Citations of Informative Material . . . . . . . . . . . . 20 94 C. Open Issues . . . . . . . . . . . . . . . . . . . . . . . . . 20 95 Intellectual Property and Copyright Statements . . . . . . . . 22 97 1. Introduction 99 The IETF has produced a large (and useful) body of work. In many 100 ways, the IETF has been a victim of its own (or at least of TCP/IP's) 101 success. As the standards which the IETF produces see wider 102 deployment by parties outside of the IETF, the system of 103 documentation and updating within the IETF causes some amount of 104 confusion. 106 The "STD" and "BCP" labels are described in [RFC2026] as subseries of 107 the RFC series, with their numbers being assigned when documents are 108 published as Internet Standards or as BCPs. The purpose and 109 organization of the STD series is defined in more detail in 110 [RFC1311]. Beyond those brief statements, the organization of the 111 two series and the classification of documents as either belonging 112 together as part of a single "ISD" specification or as separate, have 113 largely been a matter of oral tradition, with more of the decisions 114 being made as part of the RFC indexing process than explicitly by the 115 IESG as part of the standards process. RFC1311, written before the 116 standards process reforms of the 1992-1994 period (see, e.g., 117 [RFC1396] and [RFC1602]), assigns responsibility for defining the 118 content of STD documents to the IAB, but was never updated to reflect 119 the change to IESG responsibility for the standards track. The 120 intent has been to permit a stable reference to particular 121 specifications and groups of documents making up a specification, a 122 reference that survives replacement of one RFC with another, addition 123 or deletion of RFCs from the collective specification, and so on. 125 While the intentions are fairly clear and quite desirable, this 126 document suggests that the system has never worked well, especially 127 for STDs that comprise (or point to) several RFCs. There is no 128 easily-accessible audit track that specifies which documents were 129 part of an standard (identified by an STD number) at a particular 130 time (which can be very important for determining what a 131 specification that points to an STD actually means or requires). 132 Historically, the community and the IESG have not been heavily 133 involved in the process of organizing and grouping standards-track 134 documents by STD number. In retrospect, some of the decisions have 135 been, or should have been, controversial and have led to 136 misunderstandings about what is implied by conformance to a standard. 137 In addition, the "do not assign an STD number until the specification 138 reaches full Internet Standard" model is unrealistic in a world in 139 which much of the Internet runs on Proposed Standards and in which 140 the IETF only very rarely approves and publishes "Applicability 141 Statement" documents (and, when it does publish them, has little idea 142 what to do with them -- several documents that rationally fall into 143 that category have been published as BCPs instead). 145 This document creates a paper track and specific "benchmark" 146 documentation for Internet Standards. While the documents it 147 specifies may assist in the creation of dynamic web pages, or may be 148 linked to bug tracking systems, those are not its primary intent. 150 The discussion and proposal that follows are written in terms of 151 traditional standards track documents (Proposed, Draft, and Internet 152 Standard). Whether it should also be applied to BCPs needs further 153 review: the applicability is fairly obvious, but it is not clear 154 whether it is necessary enough to justify the extra trouble. 156 Appendix A describes some of the specific IETF issues, identified 157 during 2004, that led to the development of this specification. 159 Prototype examples of the type of documents contemplated here appear 160 in [ISD-Examples1] and, to a lesser extent, [ISD-Examples-Process]. 161 Those examples are just examples; they are not part of this 162 specification or definition. 164 [[Note in Draft (RFC Editor to remove this paragraph before 165 publication and after setting "Updates"): This document is intended 166 to update RFC 2026 with regard to Last Calls and how the standards 167 process is documented, RFC 3710 with regard to the IESG's list of 168 responsibilities and procedures, and RFC 3967 on references. It 169 obsoletes RFC 1311 on the STD document series; that document should 170 be moved to Historic when this one is approved. ]] 172 2. Proposal Overview 174 This document proposes that a new document series be created, called 175 Internet Standards Documents ("ISD"s) and that these be real 176 documents, separate from the underlying RFCs. The documents would be 177 managed under the direction of the IESG as part of the standards- 178 specification process, rather than being simply pointers in indexes 179 as, e.g., the STD series has been, or being the RFCs themselves with 180 different file names or packaging. It proposes that ISD documents be 181 created and numbers assigned when specifications enter the formal 182 standards track (Proposed Standard under the model described in RFC 183 2026) and that the documents be used to track maturation, 184 applicability recommendations, and history of those specifications. 185 It also outlines the format of those documents, which is expected to 186 be different from the format of protocol specification documents and 187 the RFC series generally ([RFC2223], [rfc2223bis]) and briefly 188 discusses a transition strategy. 190 Debate continues in the IETF about the proper threshold for Proposed 191 Standards with regard to both protocol quality and document quality. 192 Part of the problem is the use of a single, unqualified, label that 193 may not be a good match to all situations. The documents proposed 194 here will allow more flexibility by permitting the IESG to attach 195 appropriate qualifying notes as needed. For example, if the 196 community concluded that a specification should be published as a 197 Proposed Standard, but that potential implementers should be warned 198 that IETF confidence in its stability was lower than usual, these 199 documents would be an appropriate place to publish that type of 200 evaluation. Conversely, if interoperable implementations already 201 existed before the Proposed Standard was published, the corresponding 202 STD document would be an appropriate place to note that fact. 204 These documents, and documents authoritatively (normatively) 205 referenced from them, will become, essentially, the definitions of 206 standards. Consequently, any changes to them will occur only under 207 IESG authority and responsibility. The IESG may, at its discretion, 208 and with appropriate announcements to, and consultation of, the 209 community, delegate authority for some sections to groups responsible 210 for the ongoing maintenance of the standards, but may not relinquish 211 responsibility for the documents themselves. However, nothing in 212 this specification prohibits (or requires) IESG authorization of 213 placement of links in the STD documents that point to less formal and 214 less authoritative discussions of, or comments on, the relevant 215 standards should they deem that appropriate. 217 By extension from the above, the IESG will need to make 218 determinations, ideally after creating guidelines and getting 219 community review and assent to them, as to criteria (e.g., length, 220 importance, degree of discussion needed) by which authoritative 221 comments and qualifications about standards will be incorporated into 222 the STDs documents or issued as separate RFCs. The starting point 223 and minimum descriptive and qualifying text for new standards will be 224 the text of the Protocol Action Notice. 226 3. A New Document Series 228 When the IESG agrees to move a document onto the standards track, it 229 either causes a new Internet Standard number ("ISD number") and name 230 or acronym ("ISD name") to be assigned to it, or classifies it as 231 part of an existing standard and assigns that number and name. If 232 multiple, related, specifications are approved at the same time, they 233 may be assigned the same ISD number and name. More broadly, the ISD 234 will be the basis of the Standards Action itself: For standards- 235 track, and standards-track-related, documents, the ISD itself is the 236 subject of an IETF Last Call, carrying with it the normatively- 237 referenced documents. The ISD and those documents are approved 238 together or not at all (see Section 6). This assignment of an ISD 239 number and name, and assignment of a specification to it, results in 240 a corresponding ISD document being created or updated, as described 241 below. Following good sense and existing precedent, the IESG may 242 decide to include documents that are not themselves on the standards 243 track (e.g., Informational documents explaining, or describing 244 alternatives to, an agreed-upon standard) in references from a ISD 245 document once that document is defined by the assignment of a name 246 and number. 248 When documents are introduced into, or advanced on, the standards 249 track, this specification anticipates that preparation (or revision) 250 of the relevant ISD document will be the responsibility of the WG 251 (for WG-produced documents) or document authors (for other types of 252 submissions) but leaves it to the IESG to work out and adapt 253 procedures as they find appropriate and efficient. 255 Advancement of a document on the standards track, publication of 256 applicability statements, notes on errata or other issues of 257 sufficient and substantive importance to require alerting 258 implementers or the community will also result in modifications to 259 the relevant ISD document. It is explicitly anticipated that 260 documents may be moved from one maturity level to another (i.e., 261 under the current system, to Draft, Full, or Historic, or from 262 Experimental to Proposed) by changing the ISD document to identify 263 the new level and include any relevant notes as an alternative to 264 modifying the relevant RFC text and issuing new RFCs (and, of course, 265 modifying the ISD document to reflect those changes). 267 Particular RFCs may move in and out of a ISD (except for the 268 historical record) as one RFC replaces another. Because the ISD 269 document is expected to contain prose, it will be possible to deal 270 with the long-standing issues of what "updates" means by identifying 271 the relevant sections or concepts. And, again because there is 272 descriptive prose present, the IESG will be able to deal 273 appropriately with the relationship between an old Full Standard and 274 a newer document, at a lower maturity level, that is intended to 275 replace it by specifying whatever they consider appropriate about 276 what the implementer or other reader should look at. 278 While RFCs are permanent, ISD documents are expected to evolve and 279 incorporate changes over time. However, they are also expected to 280 include explicit change histories in order to make it possible for a 281 reader to examine a current ISD document and determine the status of 282 the relevant standard at any particular previous time. An ISD number 283 or name, once bound to a particular conceptual standard, is never 284 reused for a different concept. 286 4. Publication and Formatting 288 ISDs constitute an entirely new document series, to be managed 289 directly by the IESG as part of its management of the standards 290 process. ISDs are not to be published as part of the RFC series. 291 The basic source format an ISD will be XML, conforming to an 292 appropriate and IESG-designated, schema. For archival and external 293 reference purposes, the formal archival form of the ISD will be ASCII 294 text. However, it is anticipated that web pages with embedded links 295 will also be generated from the XML and made accessible from the IETF 296 home page. 298 Draft versions of ISDs or proposals for updating them may be posted 299 as Internet-Drafts. Such posting will generally be required in 300 conjunction with Last Calls unless the IESG devises an alternate 301 procedure. Since current Internet-Draft format requirements are 302 based on RFC formats and requirements, posting drafts for ISDs as 303 Internet-Drafts may require some extensions to the Internet-Draft 304 posting rules. 306 As mentioned above, ISDs will be identified by a name and the 307 combination of a serially-assigned standard number and a date with 308 resolution in days. The numbers for ISDs and those for STDs (see 309 [RFC1311]) are generally not expected to be synchronized. 311 5. Content and Organization of an ISD Document 313 An ISD document is expected to follow the general layout and 314 formatting conventions of an RFC (because the community is familiar 315 with them). The components listed below may appear, or are expected 316 to appear (required materials, even if only pro-forma, are identified 317 with asterisks). As with RFCs, additional sections may be included 318 as needed and appropriate. Note that ISDs don't have authors: the 319 RFCs have authors, but the "author" of an ISD would always be "IETF" 320 (or the historical "Network Working Group") so there is no 321 information in providing an author or editor name. A individual who 322 had made a major contribution to the ISD document itself might be 323 listed in an Acknowledgement or as a Contributor. 325 The Working Group or individual that prepares an ISD draft prior to 326 initiation of an IETF Last Call is expected to supply the information 327 described below. The IESG may, as part of Standards Track 328 processing, modify that material, perhaps as the result of the Last 329 Call process or to include additional information about, or 330 qualifications on, an approval action. 332 Title.* It is desirable for standards to have titles as well as 333 numbers and acronyms (names). As others have pointed out, it 334 would make them, especially those that involve multiple RFCs, a 335 lot easier to talk about. For example, by common usage, the 336 "name" of an ISD might be "SMTP" with a title of "Simple Mail 337 Transfer Protocol". 338 Standard Acronym and Number* The ISD will be associated with both an 339 abbreviated name or acronym that is descriptive of the standard 340 and a standard number, the latter of which will be serially- 341 assigned. 342 Date.* This is the date the ISD was last updated. Everything else 343 belongs in history or annotation. This date will specify a day, 344 not just a month. 345 Abstract.* As with the title, it would be good to have these for 346 standards, describing what the whole package does and not just 347 what individual RFCs do. 348 Maturity, Implementations, and Applicability Level* 349 ISDs as a whole do not have maturity levels in the traditional 350 sense. At the same time, it is useful for the ISD to have a 351 section that provides information about implementation, 352 interoperability, and deployment experience. If some of the 353 normatively-referenced RFCs are intended to replace earlier, more 354 mature ones, the ISD would normally be expected to describe and 355 explain that situation. If an ISD is retired in its entirety, no 356 matter what maturity levels are associated with its individual 357 documents, this entry may be "Historic" with optional additional 358 descriptive text. 359 RFC list.* For each RFC that is currently associated with this ISD, 360 the name, title, document date, and maturity level most recently 361 assigned and its date. Optionally, an abbreviated abstract, 362 applicability comments, errata, and other notes and commentary can 363 be associated with some or all of the RFCs. When there is a non- 364 obvious relationship among the various documents, it should be 365 described either here or in the applicability remarks below, as 366 appropriate (or in a separate section, if one is required). 367 Applicability Remarks about the standard. Any remarks about 368 applicability that seem useful or appropriate, as authorized. 369 Security Remarks about the standard. Any authorized remarks about the 370 security implications or considerations of the standard that are 371 not completely reflected in the component RFCs. 372 History*. This section should define the entire record of changes to 373 the definition of the documents and applicability statements that 374 make up the standard, with dates identified. It should, in 375 particular, identify the point at which one document superseded or 376 updated another. 378 6. Procedure for New Standards and Associated ISDs 380 [[Note in Draft: This section, and some of the added details in the 381 next one, are supplied as a strawman to facilitate discussion and in 382 response to several complaints that the document does not contain 383 sufficient detail about what is intended that the IESG can evaluate 384 it. The material below provides specific proposed changes to RFC 385 2026, making it more clear what the ISD model does to the existing 386 Standards Track model. Considerable changes can be made to this 387 section, and those details, without changing the basic principles of 388 this specification and the IESG is encouraged to make such changes as 389 appropriate.]] 391 The current model for processing standards track documents is 392 described in section 6 of [RFC2026]. In particular, section 6.1.1 393 specifies the model for initiating a standards action. This 394 specification can be seen as replacing selected sections of RFC 2026 395 with something similar to the following, using terminology developed 396 above: 398 6.1 Replacement for RFC 2026, Section 6.1.1 400 Initiation of Action 402 A specification that is intended to enter or advance in the Internet 403 standards track shall first be described in a draft ISD. That draft 404 will update any previous ISD for the same base standard. It will 405 contain normative references to the RFCs and other specifications 406 that define the details of the standard, including explanatory text 407 for any changes or qualifications. That draft ISD shall be posted as 408 an Internet-Draft (see section 2.2 of RFC 2026) even if the 409 underlying RFCs have not changed since their publication. It shall 410 remain as an Internet-Draft for a period of time, not less than two 411 weeks, that permits useful community review, after which a 412 recommendation for action may be initiated. 414 A standards action is initiated by a recommendation by the IETF 415 Working group responsible for a specification to its Area Director, 416 copied to the IETF Secretariat or, in the case of a specification not 417 associated with a Working Group, a recommendation by an individual to 418 the IESG. 420 6.2 Replacement for the third paragraph of RFC 2026, Section 6.1.2 422 The IESG will send notice to the IETF of the pending IESG 423 consideration of the document(s) to permit a final review by the 424 general Internet community. This "Last-Call" notification shall be 425 via electronic mail to the IETF Announce mailing list. The Last-Call 426 will cover both the text of the ISD and that of any documents and 427 materials normatively referenced from it, noting especially those 428 documents that have changed or that otherwise deserve special 429 consideration by the community. Comments on a Last-Call shall be 430 accepted from anyone, and should be sent as directed in the Last-Call 431 announcement. 433 6.3 Insertion at the end of RFC 2026, Section 6.1.2 435 If, as a result of the Last-Call, the IESG determines that revisions 436 or modifications are needed, it may request that the submitter modify 437 either the underlying specification document(s) or the text 438 describing them in the ISD, as it deems appropriate. 439 [[Note in draft: We anticipate that some fraction of the document 440 adjustments that are now handled by notes from the IESG to the RFC 441 Editor, especially those that document restrictions on the use or 442 applicability of protocols, will be handled by adjusting ISD text 443 instead. However, this provision is designed primarily to avoid 444 holding up the processing of a new specification that modifies an 445 existing standard with Last Call comments about the text that 446 describes the existing standard.]] 448 6.4 Replacement for first paragraph of RFC 2026 Section 6.1.3 450 If a standards action is approved, the IESG incorporates any Protocol 451 Action text into the ISD and publishes it (updating or superceding 452 any previous version), using mechanisms of its choice. It also sends 453 a notice to the RFC Editor to publish any new or revised 454 specification as RFCs. The ISD will reference new or revised 455 technical specifications in their Internet-Draft form until the 456 RFC(s) are actually published, at which point the ISD will be updated 457 as an administrative procedure (i.e., without a requirement for a 458 further Last-Call or IESG action). Any documents previously posted 459 as Internet-Drafts shall be removed from the Internet-Drafts 460 directory when they are published in ISD or RFC form. All Protocol 461 Action notices, and notices sent to the RFC Editor or IETF 462 administrative entities, in conjunction with a Standards Action shall 463 be copied to the IETF. 465 [[Note in Draft: A review of the rest of section 6.1.3 and all of 6.2 466 through 6.4 of RFC 2026 indicates that they are ripe for updating. 467 Since most of the reasons for that are unrelated to this document, 468 proposed revisions are not included here. However, any revision of 469 6.2, 6.3, or 6.4 should clarify the difference between revising an 470 ISD and revising the underlying RFCs, favoring the former when 471 possible for smaller changes. The procedures outlined in those 472 sections are not affected by this document; only the particular 473 specifications being referenced or changes are (and that only in some 474 cases).]] 476 7. Transition 478 Obviously, we now have many full Internet Standards, with STD numbers 479 assigned and packaging defined by those numbers, that are not 480 associated with documents as described here. We have even more 481 documents at Proposed or Draft Standard levels that do not have 482 either documents of this type or grouping. Some of those documents 483 should almost certainly be bound to existing packages defined by STD 484 numbers. If this process is not bootstrapped by issuing ISDs for 485 those documents, it probably won't work. So the following approach, 486 which can be applied more less mechanically, is suggested: 488 o Alter the templates for the RFC Index and similar documents to 489 contain provisions for an ISD reference element 490 o For all documents now identified as Standards Track, and for non- 491 procedural BCPs, insert an indication that an ISD is pending. 492 Depending on IESG decisions and available of resources within the 493 community, some standards-track RFCs, and hence the associated 494 standards, might remain in "ISD pending" state for an extended 495 period. 496 o For each existing STD number, assign a name or acronym and create 497 a prototype ISD document. Reuse of the STD numbers as ISD numbers 498 would save some time and avoid some confusion, but such binding is 499 not required (see Section 4). For documents that have been 500 assigned STD numbers, this step and the management of titles and 501 abstracts, as discussed below, can be done from the existing std- 502 index being maintained by the RFC Editor. These prototype 503 documents should be populated with the list of RFCs now associated 504 with the STD number. All of them should be identified as Internet 505 Standards. 506 o For each existing Proposed or Draft Standard, generate a template 507 document and assign a name and number. Exceptions should be made 508 and documents grouped when it is obvious and uncontroversial that 509 several documents belong together and someone can be found to do 510 the work. Initial assignments and drafts should be created on an 511 area basis, preferably by directorates or specially-selected 512 committees, coordinating with any reclassification efforts to 513 avoid duplicate work. Populate the title and abstract of these 514 template documents with the title and abstract of the first RFC in 515 the series. This won't be perfect, and in some cases, won't be 516 even close, but it is better than nothing (and _much_ better than 517 getting stuck waiting for someone to interpret the RFCs and do a 518 write-up). As the IESG deems appropriate, this step may be 519 deferred for some or all of the relevant RFCs until either they 520 come up for revision or volunteers are found. 521 o For both the existing full standards and for documents associated 522 with RFCs at a lower maturity level, omit any applicability, 523 errata, or similar sections but include, for convenience and non- 524 normatively, links to the RFC Editor's errata page where 525 applicable. 526 o Again for all of these template documents, populate the History 527 section with a note to the effect that the Standard existed before 528 the relevant date and the document is initialized as of that date. 530 o It will be important to preserve the STD numbers and index for 531 some time, perhaps indefinitely, because some references exist to 532 them. However, it will not be necessary to expand that list. 534 8. Operational Issues 536 There is a case to be made that creating this sort of document series 537 is additional work for the IESG. In practice, the authors don't 538 believe it, at least to any significant degree. All of the relevant 539 information is created today. It is scattered in meeting minutes and 540 secretariat notes, protocol action notices, discussions about whether 541 to restart WGs to deal with problems, etc. Today that information, 542 much of it quite useful, gets lost or at least becomes quite 543 difficult to find. Conversely, these series should reduce workload 544 by considerably reducing the pressure to find editors to write or 545 rewrite RFCs whose purpose is ultimately "this document is just like 546 RFC xxxx, except that section 3.1.3 is removed to permit promoting 547 the specification to the next maturity level". The IESG can 548 certainly still insist on that procedure if it deems it necessary, 549 but it should also be possible to Last Call a revised ISD that 550 contains more or less that sentence and not touch the RFC at all. 551 And, if a WG responsible for creating or updating an ISD can't come 552 up with an appropriate title and abstract/brief description, we are 553 in a kind of trouble that goes well beyond any procedural issues. 555 For a new specification document intended to be processed onto the 556 standards track (including non-procedural BCPs), responsibility for 557 preparing a draft of a new or revised ISD and advising on whether the 558 standards-track document will require a new ISD number or become part 559 of an existing ISD lies with the relevant WG or other submitter. The 560 IESG will issue a Last Call that includes the proposed ISD text along 561 with the substantive document(s). They will then modify the ISD text 562 as needed based on input during Last Call and internal discussions. 563 In general, the new or revised ISD will be issued at the same time as 564 (or replacing) the Protocol Action Notice, referencing the approved 565 Internet-Draft and containing copies of any RFC Editor instructions. 566 That material would then be replaced in the ISD when the relevant 567 documents are published. 569 The ISD document is intended to become the repository for the 570 substantive content of Protocol Action Notices and for IESG 571 statements and qualifications about what they are approving. This 572 will include any "known defects" or "this must be fixed when the 573 document is advanced to the next maturity level" statements. 575 It is the intent of this specification that all substantive or 576 normative changes to an ISD be the result of IETF consensus, i.e., 577 that the change be made only after a Last Call and IESG review and 578 approval. However, more flexibility and less formality is 579 appropriate for at least some non-normative changes, commentary, etc. 580 The IESG is tasked with specifying and documenting the types of 581 changes that do not require Last Calls or IESG approval, and the 582 processes for making those changes. 584 This document carefully does not specify the registry mechanism for 585 assigning new ISD numbers, nor the details of publication and 586 repository mechanisms for the documents, although it specifies some 587 requirements for them (see Section 4). Either or both might sensibly 588 be done by the RFC Editor (that arrangement would certainly be 589 consistent with historical precedents), but, if only because the ISD 590 series would be a new task for them, it seems wise to leave this 591 question to the IETF administrative process to sort out as seems 592 appropriate in the broad administrative context. 594 Regardless of what organizational arrangements are responsible for 595 updating and maintaining these documents, and in spite of their 596 containing a cumulative change history, they should be treated as 597 archival -- at least as archival as the RFC series. 599 9. References and Citations Involving ISDs 601 9.1 References to ISDs or References to RFCs 603 Before this proposal was generated, vendors who wished to specify 604 what they support, and potential customers who wished to specify what 605 they wanted to purchase, had a choice between referencing specific 606 RFCs (to get precision) or, for full standards, a specific STD number 607 (to get "the most current version"). Except for providing an "ISD" 608 mechanism for referencing documents other than full Internet 609 Standards, this proposal does not change either of those options: 610 both are still free to use the existing forms. In the rare case in 611 which a vendor is deliberately attempting to confuse its potential 612 customers, this mechanism is not likely to help very much either. It 613 does, however, provide a third option, which is to specify the state 614 of an ISD (and hence a Standard) as of a particular date (even a date 615 in the past or future) or within a particular date range. So, 616 whatever the referencing issues are today, this certainly does not 617 make them worse and almost certainly makes them better. 619 It should also be noted that other Standardization bodies have had 620 difficulties when referencing RFCs. It is not always clear whether 621 an RFC or an STD should be referenced. When a reference is made, 622 there can be problems when the RFC that is referenced becomes updated 623 or obsoleted. 625 9.2 References from ISDs 627 9.2.1 Document References 629 An ISD can be thought of as anchored in one of more "base documents" 630 -- RFCs that, in combination, specify the technical content of the 631 standard itself. These base documents must be standards-track 632 technical specifications or operational or Applicability Statement 633 BCPs (i.e., not IETF-process BCPs, see [Standing-Docs]). All 634 references to base documents are, essentially by definition, 635 normative and must follow the traditional rules of the RFC Editor for 636 stability of references (see, e.g., [RFC2223]) as modified by 637 [RFC3967]. However, an ISD may reference, informationally, any 638 document or material felt to be helpful in understanding the standard 639 or its context. 641 References to, and discussion of, base documents may, and normally 642 will, associate standards-track maturity levels with those documents. 643 The underlying RFCs themselves are no longer considered to have such 644 maturity levels. 646 9.2.2 Errata and Corrections 648 Errata and other corrections that represent IETF consensus (i.e., 649 based on an IESG, or IESG-delegated, determination after Last Call) 650 are normative and identified in a way that distinguishes them from 651 suggested errata or changes that are not known to represent IETF 652 consensus. The latter may still be included in the ISD document as 653 informative material under the general "felt to be helpful" provision 654 of the previous subsection. 656 9.3 Citing an ISD 658 Once ISDs become available for a given IETF-produced Standard, 659 references to those standards are expected to take one of the 660 following forms, depending on the needs of the authors and the 661 standards of the publication in which the reference appears. 663 1. Internet Engineering Task Force (IETF), ISD-TITLE (Internet 664 Standard ISD NNNN), as of YYYY.MM.DD 665 2. Internet Engineering Task Force (IETF), "ISD-TITLE" (Internet 666 Standard ISD NNNN), as of YYYY.MM.DD, specifically as described 667 in RFC-AUTHOR, "RFC-TITLE", RFC NNNN, DATE. 668 The substitutions for the capitalized strings should be obvious. If 669 an RFC reference appears, as in the second form, it may be repeated 670 for each relevant RFC. And URI references to document locations may 671 be added if required (or permitted by author preference) by the 672 relevant publication. 674 10. IANA Considerations 676 This document does not anticipate any specific tasks for the IANA. 677 However, over time, it may be desirable to review and update the 678 descriptions of various registries to refer to ISD numbers, rather 679 than RFC numbers, as the definitions or authority for those 680 registries. See also Section 8. 682 11. Security Considerations 684 This document specifies an administrative procedure for the IETF and 685 hence does not raise any new issues about the security of the 686 Internet. However, the availability of the type of document 687 described here may provide a convenient mechanism and repository of 688 vulnerabilities and other issues that are discovered after RFCs are 689 issued but that do not justify updating (or for which resources are 690 not available to update) the relevant RFC. Having an obvious place 691 to look for those notifications and discussions for standards-track 692 documents might enhance overall security somewhat. 694 12. Acknowledgements 696 The general ideas described here have been discussed on and off for 697 several years, but have never been turned into public documents. 698 Thanks are due to several generations of IAB and IESG members and to 699 RFC Editor staff for helping to clarify the ideas and to identify 700 some variants that would or would not work. The ideas in this 701 specific presentation are, of course, those of the author and are one 702 with which some of the contributors might disagree. Pekka Savola 703 provided extensive and very useful comments on a preliminary version 704 of the initial draft. Harald Alvestrand, Bob Braden, and several 705 others made comments on the first posted draft that resulted in 706 important clarifications. Discussions during and after IETF 60 led 707 to further changes and the consolidation of the previous relevant 708 documents. Bob Braden suggested not trying to reuse the term "STD", 709 and provided new term "ISD". Additional helpful comments and 710 corrections were provided by Pekka Savola and Scott Bradner. 712 13. Changes from Previous Versions 714 [[Note in Draft: This section is to be removed before RFC 715 publication]] 717 Version 00. This version replaces and consolidates the previous 718 documents "Repurposing the STD Designation" 719 (draft-klensin-newtrk-std-repurposing-00.txt, 6 June 2004) and 720 "Standards, What Standards?" 721 (draft-loughney-what-standards-01.txt, February 2004). It also 722 includes a number of editorial clarifications and a few more 723 details than its predecessors. The tone is still somewhat 724 informal and conversational; if general consensus is reached on 725 the ideas, that should be corrected, in both the text and the 726 abstract, in a subsequent draft. 727 Version 01. This version incorporates the changes and clarifications 728 discussed in a meeting of the NEWTRK WG at IETF 61 (Washington, 729 DC, USA, November 2004) and on the mailing list in the subsequent 730 weeks. While some outstanding issues and possible issues remain, 731 the document has been considerably tightened up and a number of 732 previous loose ends documented. In the process, some of the 733 conversational text in the previous versions (see above) has been 734 edited into a more formal form. Most of the "why is this 735 justified and being done" material has been moved to an appendix 736 in order to facilitate eventually turning the Internet-Draft into 737 a permanent IETF process specification. 738 Version 02. This version incorporates the changes and clarifications 739 discussed in the NEWTRK WG meeting at IETF 62 (Minneapolis, MN, 740 USA, March 2005). All previous non-editorial "notes in draft" 741 have been resolved, and those that discuss design choices have 742 been removed to appendices. 743 Version 03. This version produced in response to mailing list 744 comments, suggestions by a few IESG members, and a general review. 745 Material has been added to specify reference formats (at least one 746 of the authors regrets the fact that this was never done for RFCs) 747 and to fill in various other details to facilitate discussion. A 748 new section, titled "Procedure for New Standards and Associated 749 ISDs" has been added and new text has been added to the section on 750 Transition, to better clarify intent and outline possible ways 751 forward. An additional new appendix has been added to list 752 outstanding issues and placeholders; readers are encouraged to 753 examine it before complaining about what is or is not present. 755 14. References 757 14.1 Normative References 759 [RFC2026] Bradner, S., "The Internet Standards Process -- Revision 760 3", BCP 9, RFC 2026, October 1996. 762 [RFC3967] Bush, R. and T. Narten, "Clarifying when Standards Track 763 Documents may Refer Normatively to Documents at a Lower 764 Level", BCP 97, RFC 3967, December 2004. 766 14.2 Informative References 768 [ISD-Examples-Process] 769 Bradner, S., "Sample ISD for the IETF Standards Process", 770 draft-ietf-newtrk-sample-isd-00 (work in progress), 771 October 2004. 773 [ISD-Examples1] 774 Klensin, J., "Internet Standards Documentation (ISDs) - 775 Examples", draft-ietf-newtrk-sample-isd-00 (work in 776 progress), October 2004. 778 [RFC1311] Postel, J., "Introduction to the STD Notes", RFC 1311, 779 March 1992. 781 [RFC1396] Crocker, S., "The Process for Organization of Internet 782 Standards Working Group (POISED)", RFC 1396, January 1993. 784 [RFC1602] Huitema, C. and P. Gross, "The Internet Standards Process 785 -- Revision 2", RFC 1602, March 1994. 787 [RFC2223] Postel, J. and J. Reynolds, "Instructions to RFC Authors", 788 RFC 2223, October 1997. 790 [RFC3774] Davies, E., "IETF Problem Statement", RFC 3774, May 2004. 792 [Standing-Docs] 793 Klensin, J., "Standing Documents Describing IETF Processes 794 and Operations", draft-ietf-newtrk-sd-00 (work in 795 progress), February 2004. 797 [rfc2223bis] 798 Reynolds, J. and R. Braden, "Instructions to Request for 799 Comments (RFC) Authors", draft-rfc-editor-rfc2223bis-07 800 (work in progress), August 2003. 802 Authors' Addresses 804 John C Klensin 805 1770 Massachusetts Ave, #322 806 Cambridge, MA 02140 807 USA 809 Phone: +1 617 491 5735 810 Email: john-ietf@jck.com 811 John A Loughney 812 Itamerenkatu 11-13 813 Helsinki, 00180 814 Finland 816 Phone: +358 5 04836242 817 Email: john.loughney@nokia.com 819 Appendix A. Motivation and Historical Context 821 Appendix A.1 Problem(s) 823 The following problems are excerpted from Section 2.4 of the IETF 824 Problem statement [RFC3774]. 826 o Relatively few specifications are now progressed beyond Proposed 827 Standard (PS) to Draft Standard (DS) level, and even fewer to Full 828 Standard (FS). 829 o There is no formal bug reporting or tracking system in place for 830 IETF specifications. 831 o The periodic review of protocols at PS and DS levels specified in 832 are not being carried out, allowing protocols to persist in these 833 lower maturity levels for extended periods of time, whereas the 834 process would normally expect them to progress or be relegated to 835 Historic status. 836 o No individual or body is given the task of 'maintaining' a 837 specification after the original WG has closed down. 838 Specifications are generally only updated when a need for a new 839 version is perceived. No attempt is normally made to correct bugs 840 in the specification (whether they affect operation or not) and 841 the specification is not updated to reflect parts of the 842 specification that have fallen into disuse or were, in fact, never 843 implemented. This is in part because the current procedures would 844 require a standard to revert to the PS maturity level even when 845 specification maintenance is carried out which can be demonstrated 846 to have no or minimal effect on an existing protocol at DS or FS 847 level. 848 o Few Specifications Progress Beyond Proposed Standard. 849 The IETF, as of late, does not have a good track record of moving 850 protocols beyond Proposed Standard. In fact, the goal of most 851 Working Groups is to produce a set of RFCs and then shut down. 852 Working groups that do this are considered to have succeeded. 853 There are only a handful of long-lived working groups, such as 854 IPv6, whose charters include progressing standards beyond Proposed 855 Standards. Occasionally, new working groups need to be spun up to 856 make sense of the existing set of RFCS, such as tcpm (TCP 857 Maintenance). 859 o There is no Formal Bug Reporting or Tracking System. 860 Bugs in a specification can be found at any point. There have 861 been bugs found even in Full Standards. How do we ensure 862 correctness in our own standards? 864 This document does not take a stand on the issue of the relevance of 865 the current standards track. It does note that at any given moment, 866 a standard may be undergoing work to progress the document to another 867 level. We discuss the problems identified in more detail below. 869 Appendix A.2 Periodic Reviews of Protocols are not Being Carried Out 871 Many protocols suffer from benign neglect. The working group charged 872 with developing the protocol becomes dormant or is shut down. The 873 principal authors of the specification may no longer be involved in 874 the IETF. Further development of the protocol may even be officially 875 discouraged. 877 Other standards development organizations (SDOs) may consider 878 extensions or modification to the protocols. This causes problems 879 for parties interested in the technology, as it becomes unclear as to 880 exactly what specifies a particular protocol. Additionally, it makes 881 it hard to track errors in or updates to a specification or protocol. 883 Appendix A.3 There is no Maintenance Team Responsible for a Protocol 885 Specifications are generally only updated when a need for a new 886 version is perceived. No attempt is normally made to correct bugs in 887 the specification (whether they affect operation or not) and the 888 specification is not updated to reflect parts of the specification 889 that have fallen into disuse or were, in fact, never implemented. 890 This is in part because the current procedures would require a 891 standard to revert to the PS maturity level even when specification 892 maintenance is carried out which can be demonstrated to have no or 893 minimal effect on an existing protocol at DS or FS level. 895 Appendix B. Notes on the Design 897 In the process of developing this specification, several notes and 898 comment were made about tradeoffs. Those notes appear below, 899 essentially unedited. They are not a normative part of the 900 specification. 902 Appendix B.1 Comments, discussion notes, and proposed errata 904 If makes sense to the community to have an archive of comments, 905 discussion, or proposed errata on the documents, that is fine, and it 906 would be useful for these documents to identify the locations of 907 those archives. But we should be very careful that the contents of 908 such archives are not confused with the content of the specifications 909 unless they go through some sort of formal review and consensus 910 process. The description of that process in the specification is 911 deliberately open-ended and flexible. If the IESG is willing to 912 accept and maintain formal responsibility for whatever appears in ISD 913 documents, they could include some non-normative changes being made 914 by, e.g., maintenance committees should the community want to move in 915 that direction. 917 Appendix B.2 Numbers versus Names 919 There was an extended debate in the Working Group as to whether ISDs 920 were better identified by acronyms or serial numbers. There are 921 advantages to names or acronyms and and to numbers. The former are 922 easier to remember as long as there are not too many of them and are 923 usually more human friendly. The latter are very precise and 924 language-independent. The choice between the two did not appear to 925 be worth the amount of energy it would have taken to reach consensus, 926 if even that were possible. Consequently, the document recommends 927 assigning both a number and a name (acronym or other string) to each 928 ISD. 930 Appendix B.3 Citations of Informative Material 932 There is discussion in Section 9.2.1 about the inclusion of 933 informative (non-normative) material, but no specific guidance is 934 given about what material is and is not appropriate, other than that 935 it is "felt to be helpful". The apparent ambiguity is deliberate, 936 relying on good sense and the requirement that substantive changes to 937 ISDs must be Last Called in the IETF, rather than an attempt to make 938 specific rules that would probably be inappropriate for some future 939 situation. 941 Appendix C. Open Issues 943 [[Note in Draft: The RFC Editor should remove this section prior to 944 publication.]] 946 The following issues are still open, or were raised too late in the 947 editing cycle to be addressed in this draft. 949 ISD Authors 950 The introduction to Section 5 indicates that ISDs do not have 951 authors and that any author, editor, or contributor information 952 should be put into an Acknowledgements or Contributors section. A 953 recent suggestion was made on the NEWTRK mailing list to the 954 effect that listing authorship might motivate people to create 955 these documents, especially for standards-track documents that 956 existed prior to the introduction of ISDs. The arguments against 957 this remain that (i) the possibility that giving ISDs authors 958 would detract from credit for the authors and editors of the 959 substantive (normally RFC) documents themselves and (ii) that the 960 responsible "author" for an ISD should properly be the IETF 961 itself. But this issue needs to be resolved. 963 Level of Specification 964 The authors of this document, with what appears to be the general 965 agreement of the NEWTRK WG, deliberately did not specify a number 966 of details, preferring instead to give the IESG the option of 967 making choices it found comfortable and adjusting those choices as 968 experience developed. It is clear, at least to the authors, that 969 ISDs will not succeed unless they have enthusiastic IESG support, 970 and quibbling about essentially arbitrary details is not a good 971 way to obtain that support or to determine whether it exists. 972 However, it is probable that the community and the IESG will 973 discover some topics that should be specified in precise detail 974 and others that should be specified in even less detail than now 975 appears above. This item is inserted here as a placeholder to 976 note that the question of level of detail is still, intentionally, 977 unresolved. 979 Strawman details 980 Version -02 of this draft specification contains details in 981 Section 6, Section 9.3 and elsewhere that need to be checked and 982 verified as what is wanted. Much of that burden falls more 983 appropriately on the IESG than on the community. 985 Additional rationale 986 In addition, draft -02 contains several notes in draft that 987 explain tentative design choices. Those will be moved to the 988 appropriate appendix, or, if appropriate, dropped, in the next 989 draft. Having them inline now would appear to facilitate 990 efficient review. 992 Intellectual Property Statement 994 The IETF takes no position regarding the validity or scope of any 995 Intellectual Property Rights or other rights that might be claimed to 996 pertain to the implementation or use of the technology described in 997 this document or the extent to which any license under such rights 998 might or might not be available; nor does it represent that it has 999 made any independent effort to identify any such rights. Information 1000 on the procedures with respect to rights in RFC documents can be 1001 found in BCP 78 and BCP 79. 1003 Copies of IPR disclosures made to the IETF Secretariat and any 1004 assurances of licenses to be made available, or the result of an 1005 attempt made to obtain a general license or permission for the use of 1006 such proprietary rights by implementers or users of this 1007 specification can be obtained from the IETF on-line IPR repository at 1008 http://www.ietf.org/ipr. 1010 The IETF invites any interested party to bring to its attention any 1011 copyrights, patents or patent applications, or other proprietary 1012 rights that may cover technology that may be required to implement 1013 this standard. Please address the information to the IETF at 1014 ietf-ipr@ietf.org. 1016 Disclaimer of Validity 1018 This document and the information contained herein are provided on an 1019 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 1020 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 1021 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 1022 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 1023 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 1024 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 1026 Copyright Statement 1028 Copyright (C) The Internet Society (2005). This document is subject 1029 to the rights, licenses and restrictions contained in BCP 78, and 1030 except as set forth therein, the authors retain all their rights. 1032 Acknowledgment 1034 Funding for the RFC Editor function is currently provided by the 1035 Internet Society.