idnits 2.17.1 draft-ietf-newtrk-repurposing-isd-04.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 1183. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 1160. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 1167. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 1173. ** 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 (March 6, 2006) is 6623 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: September 7, 2006 March 6, 2006 6 Internet Standards Documentation (ISDs) 7 draft-ietf-newtrk-repurposing-isd-04.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 September 7, 2006. 34 Copyright Notice 36 Copyright (C) The Internet Society (2006). 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 . . . . . . . . . . . . . . . . . . . . . . . . . 5 59 1.1. Status of This Version . . . . . . . . . . . . . . . . . . 5 60 1.2. Present Status in the IETF and the Role of this 61 Proposal . . . . . . . . . . . . . . . . . . . . . . . . . 5 62 1.3. This Proposal and the Standards Track . . . . . . . . . . 6 63 1.4. Concepts, Generalities, and Specificity . . . . . . . . . 7 64 2. Proposal Overview . . . . . . . . . . . . . . . . . . . . . . 8 65 3. A New Document Series . . . . . . . . . . . . . . . . . . . . 9 66 4. Publication and Formatting . . . . . . . . . . . . . . . . . . 10 67 5. Content and Organization of an ISD Document . . . . . . . . . 11 68 6. Change Histories . . . . . . . . . . . . . . . . . . . . . . . 12 69 7. Procedure for New Standards and Associated ISDs . . . . . . . 13 70 7.1. Replacement for RFC 2026, Section 6.1.1 . . . . . . . . . 14 71 7.2. Replacement for the third paragraph of RFC 2026, 72 Section 6.1.2 . . . . . . . . . . . . . . . . . . . . . . 14 73 7.3. Insertion at the end of RFC 2026, Section 6.1.2 . . . . . 14 74 7.4. Replacement for first paragraph of RFC 2026 Section 75 6.1.3 . . . . . . . . . . . . . . . . . . . . . . . . . . 15 76 7.5. Updating of RFC 2026, Section 3.3 . . . . . . . . . . . . 15 77 8. Transition . . . . . . . . . . . . . . . . . . . . . . . . . . 15 78 9. Operational Issues . . . . . . . . . . . . . . . . . . . . . . 17 79 10. References and Citations Involving ISDs . . . . . . . . . . . 18 80 10.1. References to ISDs or References to RFCs . . . . . . . . . 18 81 10.2. References from ISDs . . . . . . . . . . . . . . . . . . . 19 82 10.2.1. Document References . . . . . . . . . . . . . . . . . 19 83 10.2.2. Errata and Corrections . . . . . . . . . . . . . . . 19 84 10.3. Citing an ISD . . . . . . . . . . . . . . . . . . . . . . 20 85 11. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 20 86 12. Security Considerations . . . . . . . . . . . . . . . . . . . 20 87 13. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 20 88 14. Changes from Previous Versions . . . . . . . . . . . . . . . . 21 89 15. References . . . . . . . . . . . . . . . . . . . . . . . . . . 22 90 15.1. Normative References . . . . . . . . . . . . . . . . . . . 22 91 15.2. Informative References . . . . . . . . . . . . . . . . . . 22 92 Appendix A. Motivation and Historical Context . . . . . . . . . 23 93 Appendix A.1. Problem(s) . . . . . . . . . . . . . . . . . . . . . 23 94 Appendix A.2. Periodic Reviews of Protocols are not Being 95 Carried Out . . . . . . . . . . . . . . . . . . . . 24 96 Appendix A.3. There is no Maintenance Team Responsible for a 97 Protocol . . . . . . . . . . . . . . . . . . . . . . 24 98 Appendix B. Notes on the Design . . . . . . . . . . . . . . . . 24 99 Appendix B.1. Comments, discussion notes, and proposed errata . . 24 100 Appendix B.2. Numbers versus Names . . . . . . . . . . . . . . . . 25 101 Appendix B.3. Citations of Informative Material . . . . . . . . . 25 102 Appendix C. Open Issues . . . . . . . . . . . . . . . . . . . . 25 103 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 27 104 Intellectual Property and Copyright Statements . . . . . . . . . . 28 106 1. Introduction 108 1.1. Status of This Version 110 This proposal was last actively discussed in the NEWTRK WG at IETF 63 111 in August 2005. Private discussions of it have continued and at 112 least some people (in addition to the author(s)) seem to believe it 113 sheds light on some important issues and may be a useful proposal. 114 So it is being reissued at this time, with some changes suggested by 115 the discussions at IETF 63 and thereafter, to keep it active and part 116 of any discussions about the disposition of NEWTRK and its work 117 items. 119 1.2. Present Status in the IETF and the Role of this Proposal 121 The IETF has produced a large (and useful) body of work. In many 122 ways, the IETF has been a victim of its own (or at least of TCP/IP's) 123 success. As the standards which the IETF produces see wider 124 deployment by parties outside of the IETF, the system of 125 documentation and updating within the IETF causes some amount of 126 confusion. 128 The "STD" and "BCP" labels are described in [RFC2026] as subseries of 129 the RFC series, with their numbers being assigned when documents are 130 published as Internet Standards or as BCPs. The purpose and 131 organization of the STD series is defined in more detail in 132 [RFC1311]. Beyond those brief statements, the organization of the 133 two series and the classification of documents as either belonging 134 together as part of a single "ISD" specification or as separate, have 135 largely been a matter of oral tradition, with more of the decisions 136 being made as part of the RFC indexing process than explicitly by the 137 IESG as part of the standards process. RFC1311, written before the 138 standards process reforms of the 1992-1994 period (see, e.g., 139 [RFC1396] and [RFC1602]), assigns responsibility for defining the 140 content of STD documents to the IAB, but was never updated to reflect 141 the change to IESG responsibility for the standards track. The 142 intent has been to permit a stable reference to particular 143 specifications and groups of documents making up a specification, a 144 reference that survives replacement of one RFC with another, addition 145 or deletion of RFCs from the collective specification, and so on. 147 While the intentions are fairly clear and quite desirable, this 148 document suggests that the system has never worked well, especially 149 for STDs that comprise (or point to) several RFCs. There is no 150 easily-accessible audit track that specifies which documents were 151 part of an standard (identified by an STD number) at a particular 152 time (which can be very important for determining what a 153 specification that points to an STD actually means or requires). 155 Historically, the community and the IESG have not been heavily 156 involved in the process of organizing and grouping standards-track 157 documents by STD number. In retrospect, some of the decisions have 158 been, or should have been, controversial and have led to 159 misunderstandings about what is implied by conformance to a standard. 160 In addition, the "do not assign an STD number until the specification 161 reaches full Internet Standard" model is unrealistic in a world in 162 which much of the Internet runs on Proposed Standards and in which 163 the IETF only very rarely approves and publishes "Applicability 164 Statement" documents (and, when it does publish them, has little idea 165 what to do with them -- several documents that rationally fall into 166 that category have been published as BCPs instead). 168 This document creates a paper track and specific "benchmark" 169 documentation for Internet Standards. While the documents it 170 specifies may assist in the creation of dynamic web pages, or may be 171 linked to bug tracking systems, those are not its primary intent. 173 The discussion and proposal that follows are written in terms of 174 traditional standards track documents (Proposed, Draft, and Internet 175 Standard). Whether it should also be applied to BCPs needs further 176 review: the applicability is fairly obvious, but it is not clear 177 whether it is necessary enough to justify the extra trouble. 179 Appendix A describes some of the specific IETF issues, identified 180 during 2004, that led to the development of this specification. 182 Prototype examples of the type of documents contemplated here appear 183 in [ISD-Examples1] and, to a lesser extent, [ISD-Examples-Process]. 184 Those examples are just examples; they are not part of this 185 specification or definition. 187 1.3. This Proposal and the Standards Track 189 This document is, explicitly, a proposal for changes to the IETF 190 Standards Track and associated procedures, not a proposal for, e.g., 191 a supplemental document series with informational and perhaps 192 informal value. If approved, it would 194 o Eliminate and replace the STD numbering series with a formal 195 mechanism for identifying standards that is more suited to today's 196 realities and IETF procedures. 197 o Change the rigid sequencing of the RFC 2026 standards maturity 198 level category levels and the "downreferencing" problem discussed 199 in [RFC3967] and elsewhere to a more flexible arrangement in which 200 the relationships among various documents could be explicitly 201 discussed and explained, rather than just being assigned simple 202 and often somewhat inappropriate categories. 204 o Provide an alternate mechanism for expressing the properties of 205 "Applicability Statements" (AS) and recommendations for use (the 206 "requirement levels" of Section 3.3 of RFC 2026) without 207 eliminating the availability of formal ASs as an alternate model. 208 o Eliminate the use of the BCP category for Applicability Statements 209 and other information about the status of standards-track 210 documents, including any implementation or interoperability 211 reports that are published as RFCs. 212 o Change the IETF's current environment in which RFC numbers are the 213 general identifier used for standards. Instead, RFC numbers would 214 return to their original role as serial document identifiers. 215 That would both help clarify the role of those numbers (without 216 subjecting the community to the trauma of replace them) and to 217 significantly improve on the problem of confusion between "RFC" 218 and "Standard". 220 [[anchor5: The changes are significant enough that, were this 221 document approved either in text or just as a series of concepts, 222 such approval should almost certainly be immediately followed by 223 revision and replacement of RFC 2026. The document is, however, 224 written on the assumption that no fundamental change in being made to 225 the role of the IESG with regard to, e.g., approval of standards. 226 Were such changes made, the document would need to be updated 227 although perhaps not significantly.]] 229 [[Note in Draft (RFC Editor to remove this paragraph before 230 publication and after setting "Updates"): This document is intended 231 to update RFC 2026 with regard to Last Calls and how the standards 232 process is documented, RFC 3710 with regard to the IESG's list of 233 responsibilities and procedures, and RFC 3967 on references. It 234 obsoletes RFC 1311 on the STD document series; that document should 235 be moved to Historic when this one is approved. ]] 237 1.4. Concepts, Generalities, and Specificity 239 The reader will note that the current (and earlier) drafts of this 240 document are partially conceptual materials and a framework to 241 stimulate discussion by the community (including the IESG) with 242 details to be filled in after that discussion. It also includes what 243 are believed to be enough specific proposal details to make the 244 intent and concepts clear. This leaves the draft in a state in which 245 anyone who dislikes the idea or dislikes change in general can find 246 ample areas for attack: the specific details can be nit-picked to 247 death because they are always other ways to do things, the places 248 where several alternatives are given can be attacked because the 249 authors did not select one alternative, and the conceptual material 250 and principles can be attacked because they are not specific enough 251 and details of, e.g., specific XML schema and templates are not 252 provided. The authors believe that, if it is possible to consider 253 this radical a change to the IETF standards process at all, the 254 community should first agree on the general principles and design 255 ideas associated with the change and then start working out details. 256 Conversely, they believe that trying to elaborate all of the details 257 without general consensus about the concepts and direction is likely 258 to be a waste of time. This document is written to facilitate 259 discussion that might lead to such a consensus, with details supplied 260 as the beginning of proof of concept, and should, preferably, be read 261 in that light. 263 2. Proposal Overview 265 This document proposes that a new document series be created, called 266 Internet Standards Documents ("ISD"s) and that these be real 267 documents, separate from the underlying RFCs. The documents would be 268 managed under the direction of the IESG as part of the standards- 269 specification process, rather than being simply pointers in indexes 270 as, e.g., the STD series has been, or being the RFCs themselves with 271 different file names or packaging. It proposes that ISD documents be 272 created and numbers assigned when specifications enter the formal 273 standards track (Proposed Standard under the model described in RFC 274 2026), or at IESG discretion, earlier, and that the documents be used 275 to track maturation, applicability recommendations, and history of 276 those specifications. It also outlines the format of those 277 documents, which is expected to be different from the format of 278 protocol specification documents and the RFC series generally 279 [RFC2223] and briefly discusses a transition strategy. 281 Debate continues in the IETF about the proper threshold for Proposed 282 Standards with regard to both protocol quality and document quality. 283 Part of the problem is the use of a single, unqualified, label that 284 may not be a good match to all situations. The documents proposed 285 here will allow more flexibility by permitting the IESG to attach 286 appropriate qualifying notes as needed. For example, if the 287 community concluded that a specification should be published as a 288 Proposed Standard, but that potential implementers should be warned 289 that IETF confidence in its stability was lower than usual, these 290 documents would be an appropriate place to publish that type of 291 evaluation. Conversely, if interoperable implementations already 292 existed before the Proposed Standard was published, the corresponding 293 ISD document would be an appropriate place to note that fact. 295 These documents, and documents authoritatively (normatively) 296 referenced from them, will become, essentially, the definitions of 297 standards. Consequently, any changes to them will occur only under 298 IESG authority and responsibility. The IESG may, at its discretion, 299 and with appropriate announcements to, and consultation of, the 300 community, delegate authority for some sections to groups responsible 301 for the ongoing maintenance of the standards, but may not relinquish 302 responsibility for the documents themselves. However, nothing in 303 this specification prohibits (or requires) IESG authorization of 304 placement of links in the STD documents that point to less formal and 305 less authoritative discussions of, or comments on, the relevant 306 standards should they deem that appropriate. 308 Because these documents can be linked to documents at any stage of 309 development, ISD identifying information can be created at any time 310 the IESG concludes that is appropriate. In particular, if a stable 311 identifier for a standard is needed, e.g., for referencing by another 312 organization, an ISD may be created and an identifier assigned before 313 RFC publication and either before or after formal Protocol Actions 314 are taken on some or all of the associated base RFC documents. 315 Agreements on the circumstances under which that would be appropriate 316 are not the subject of this document. 318 By extension from the above, the IESG will need to make 319 determinations, ideally after creating guidelines and getting 320 community review and assent to them, as to criteria (e.g., length, 321 importance, degree of discussion needed) by which authoritative 322 comments and qualifications about standards will be incorporated into 323 the STDs documents or issued as separate RFCs. The starting point 324 and minimum descriptive and qualifying text for new standards will be 325 the text of the Protocol Action Notice. 327 3. A New Document Series 329 When the IESG agrees to move a document onto the standards track, it 330 either causes a new Internet Standard number ("ISD number") and name 331 or acronym ("ISD name") to be assigned to it, or classifies it as 332 part of an existing standard and assigns that number and name. If 333 multiple, related, specifications are approved at the same time, they 334 may be assigned the same ISD number and name. More broadly, the ISD 335 will be the basis of the Standards Action itself: For standards- 336 track, and standards-track-related, documents, the ISD itself is the 337 subject of an IETF Last Call, carrying with it the normatively- 338 referenced documents. The ISD and those documents are approved 339 together or not at all (see Section 7). This assignment of an ISD 340 number and name, and assignment of a specification to it, results in 341 a corresponding ISD document being created or updated, as described 342 below. Following good sense and existing precedent, the IESG may 343 decide to include documents that are not themselves on the standards 344 track (e.g., Informational documents explaining, or describing 345 alternatives to, an agreed-upon standard) in references from a ISD 346 document once that document is defined by the assignment of a name 347 and number. 349 When documents are introduced into, or advanced on, the standards 350 track, this specification anticipates that preparation (or revision) 351 of the relevant ISD document will be the responsibility of the WG 352 (for WG-produced documents) or document authors (for other types of 353 submissions) but leaves it to the IESG to work out and adapt 354 procedures as they find appropriate and efficient. 356 Advancement of a document on the standards track, publication of 357 applicability statements, notes on errata or other issues of 358 sufficient and substantive importance to require alerting 359 implementers or the community will also result in modifications to 360 the relevant ISD document. It is explicitly anticipated that 361 documents may be moved from one maturity level to another (i.e., 362 under the current system, to Draft, Full, or Historic, or from 363 Experimental to Proposed) by changing the ISD document to identify 364 the new level and include any relevant notes as an alternative to 365 modifying the relevant RFC text and issuing new RFCs (and, of course, 366 modifying the ISD document to reflect those changes). 368 Particular RFCs may move in and out of a ISD (except for the 369 historical record) as one RFC replaces another. Because the ISD 370 document is expected to contain prose, it will be possible to deal 371 with the long-standing issues of what "Updates" means by identifying 372 the relevant sections or concepts. And, again because there is 373 descriptive prose present, the IESG will be able to deal 374 appropriately with the relationship between an old Full Standard and 375 a newer document, at a lower maturity level, that is intended to 376 replace it by specifying whatever they consider appropriate about 377 what the implementer or other reader should look at. 379 While RFCs are permanent, ISD documents are expected to evolve and 380 incorporate changes over time. However, they are also expected to 381 include explicit change histories, or a method of easily and 382 accurately generating such histories (see Section 6 in order to make 383 it possible for a reader to examine a current ISD document and 384 determine the status of the relevant standard at any particular 385 previous time. An ISD number or name, once bound to a particular 386 conceptual standard, is never reused for a different concept. 388 4. Publication and Formatting 390 ISDs constitute an entirely new document series, to be managed 391 directly by the IESG as part of its management of the standards 392 process. ISDs are not to be published as part of the RFC series. 394 The basic source format of an ISD will be XML, conforming to an 395 appropriate and IESG-designated, schema. For archival and external 396 reference purposes, the formal archival form of the ISD will be ASCII 397 text. However, it is anticipated that web pages with embedded links 398 will also be generated from the XML and made accessible from the IETF 399 home page. 401 Draft versions of ISDs or proposals for updating them may be posted 402 as Internet-Drafts. Such posting will generally be required in 403 conjunction with Last Calls unless the IESG devises an alternate 404 procedure. Since current Internet-Draft format requirements are 405 based on RFC formats and requirements, posting drafts for ISDs as 406 Internet-Drafts may require some extensions to the Internet-Draft 407 posting rules. 409 As mentioned above, ISDs will be identified by a name and the 410 combination of a serially-assigned standard number and a date with 411 resolution in days. The numbers for ISDs and those for STDs (see 412 [RFC1311]) are generally not expected to be synchronized. 414 5. Content and Organization of an ISD Document 416 An ISD document is expected to follow the general layout and 417 formatting conventions of an RFC (because the community is familiar 418 with them). The components listed below may appear, or are expected 419 to appear (required materials, even if only pro-forma, are identified 420 with asterisks). As with RFCs, additional sections may be included 421 as needed and appropriate. Note that ISDs don't have authors: the 422 RFCs have authors, but the "author" of an ISD would always be "IETF" 423 (or the historical "Network Working Group") so there is no 424 information in providing an author or editor name. A individual who 425 had made a major contribution to the ISD document itself might be 426 listed in an Acknowledgement or as a Contributor. 428 The Working Group or individual that prepares an ISD draft prior to 429 initiation of an IETF Last Call is expected to supply the information 430 described below. The IESG may, as part of Standards Track 431 processing, modify that material, perhaps as the result of the Last 432 Call process or to include additional information about, or 433 qualifications on, an approval action. 435 Title.* It is desirable for standards to have titles as well as 436 numbers and acronyms (names). As others have pointed out, it 437 would make them, especially those that involve multiple RFCs, a 438 lot easier to talk about. For example, by common usage, the 439 "name" of an ISD might be "SMTP" with a title of "Simple Mail 440 Transfer Protocol". 442 Standard Acronym and Number* The ISD will be associated with both an 443 abbreviated name or acronym that is descriptive of the standard 444 and a standard number, the latter of which will be serially- 445 assigned. 446 Date.* This is the date the ISD was last updated. Everything else 447 belongs in history or annotation. This date will specify a day, 448 not just a month. 449 Abstract.* As with the title, it would be good to have these for 450 standards, describing what the whole package does and not just 451 what individual RFCs do. 452 Maturity, Implementations, and Applicability Level* 453 ISDs as a whole do not have maturity levels in the traditional 454 sense. At the same time, it is useful for the ISD to have a 455 section that provides information about implementation, 456 interoperability, and deployment experience. If some of the 457 normatively-referenced RFCs are intended to replace earlier, more 458 mature ones, the ISD would normally be expected to describe and 459 explain that situation. If an ISD is retired in its entirety, no 460 matter what maturity levels are associated with its individual 461 documents, this entry may be "Historic" with optional additional 462 descriptive text. 463 RFC list.* For each RFC that is currently associated with this ISD, 464 the name, title, document date, and maturity level most recently 465 assigned and its date. Optionally, an abbreviated abstract, 466 applicability comments, errata, and other notes and commentary can 467 be associated with some or all of the RFCs. When there is a non- 468 obvious relationship among the various documents, it should be 469 described either here or in the applicability remarks below, as 470 appropriate (or in a separate section, if one is required). 471 Applicability Remarks about the standard. Any remarks about 472 applicability that seem useful or appropriate, as authorized. 473 Security Remarks about the standard. Any authorized remarks about the 474 security implications or considerations of the standard that are 475 not completely reflected in the component RFCs. 476 History*. This section should define, directly or indirectly, the 477 entire record of changes to the definition of the documents and 478 applicability statements that make up the standard, with dates 479 identified. It should, in particular, identify the point at which 480 one document superseded or updated another. See Section 6 for 481 further discussion. 483 6. Change Histories 485 [[anchor9: The question of what should be in the Change History 486 section, how it should be organized and presented, etc., and how 487 burdensome that would become has been one of the several sources of 488 controversies about ISDs. This section is a placeholder for that 489 discussion, since the ISD concept depends only on having some 490 reliable method for determining history and, more important, the 491 status of a particular standard at any particular present or previous 492 time. The material in the rest of the section should be read more as 493 a placeholder and beginning of a discussion rather than as a 494 definitive final proposal.]] 496 One key goal of the ISD concept is to be able to have someone using a 497 standard for reference or procurement purposes be able to identify 498 the exact status and content of that standard at any particular time. 499 The requirement for a "history" section above reflects that goal, not 500 a desire to specifically identify changes that are not substantive. 501 The "history" requirement could be realized in any of several ways, 502 including, in no particular order: 504 1. Retaining an explicit thread of previous versions of the ISD and 505 keeping those documents permanently and easily available. 506 2. Using carefully-designed XML markup to identify changes and 507 permit generating either the current ISD document or a snapshot 508 as of any particular date by an appropriate directive. 509 3. Including an explicit narrative history in the ISD itself, with 510 only the current version being considered relevant. 512 Of course, there may be other possibilities and those listed above 513 are not mutually-exclusive. 515 7. Procedure for New Standards and Associated ISDs 517 [[Note in Draft: This section, and some of the added details in the 518 next one, are supplied as a strawman to facilitate discussion and in 519 response to several complaints that the document does not contain 520 sufficient detail about what is intended that the IESG can evaluate 521 it. The material below provides specific proposed changes to RFC 522 2026, making it more clear what the ISD model does to the existing 523 Standards Track model. This section does not identify all of the 524 changes that approval of this proposal should require to RFC 2026; as 525 indicated in the Introduction, if this proposal is adopted, it should 526 be followed immediately by a thorough review and replacement of RFC 527 2026 itself. Considerable changes can be made to this section, and 528 those details, without changing the basic principles and concepts of 529 this specification and the WG and, if appropriate, the IESG are 530 encouraged to make such changes as appropriate.]] 532 The current model for processing standards track documents is 533 described in section 6 of [RFC2026]. In particular, section 6.1.1 534 specifies the model for initiating a standards action. This 535 specification can be seen as replacing selected sections of RFC 2026 536 with something similar to the following, using terminology developed 537 above: 539 7.1. Replacement for RFC 2026, Section 6.1.1 541 Initiation of Action 543 A specification that is intended to enter or advance in the Internet 544 standards track shall first be described in a draft ISD. That draft 545 will update any previous ISD for the same base standard. It will 546 contain normative references to the RFCs and other specifications 547 that define the details of the standard, including explanatory text 548 for any changes or qualifications. That draft ISD shall be posted as 549 an Internet-Draft (see section 2.2 of RFC 2026) even if the 550 underlying RFCs have not changed since their publication. It shall 551 remain as an Internet-Draft for a period of time, not less than two 552 weeks, that permits useful community review, after which a 553 recommendation for action may be initiated. 555 A standards action is initiated by a recommendation by the IETF 556 Working group responsible for a specification to its Area Director, 557 copied to the IETF Secretariat or, in the case of a specification not 558 associated with a Working Group, a recommendation by an individual to 559 the IESG. 561 7.2. Replacement for the third paragraph of RFC 2026, Section 6.1.2 563 The IESG will send notice to the IETF of the pending IESG 564 consideration of the document(s) to permit a final review by the 565 general Internet community. This "Last-Call" notification shall be 566 via electronic mail to the IETF Announce mailing list. The Last-Call 567 will cover both the text of the ISD and that of any documents and 568 materials normatively referenced from it, noting especially those 569 documents that have changed or that otherwise deserve special 570 consideration by the community. Comments on a Last-Call shall be 571 accepted from anyone, and should be sent as directed in the Last-Call 572 announcement. 574 7.3. Insertion at the end of RFC 2026, Section 6.1.2 576 If, as a result of the Last-Call, the IESG determines that revisions 577 or modifications are needed, it may request that the submitter modify 578 either the underlying specification document(s) or the text 579 describing them in the ISD, as it deems appropriate. 580 [[Note in draft: We anticipate that some fraction of the document 581 adjustments that are now handled by notes from the IESG to the RFC 582 Editor, especially those that document restrictions on the use or 583 applicability of protocols, will be handled by adjusting ISD text 584 instead. However, this provision is designed primarily to avoid 585 holding up the processing of a new specification that modifies an 586 existing standard with Last Call comments about the text that 587 describes the existing standard.]] 589 7.4. Replacement for first paragraph of RFC 2026 Section 6.1.3 591 If a standards action is approved, the IESG incorporates any Protocol 592 Action text into the ISD and publishes it (updating or superceding 593 any previous version), using mechanisms of its choice. It also sends 594 a notice to the RFC Editor to publish any new or revised 595 specification as RFCs. The ISD will reference new or revised 596 technical specifications in their Internet-Draft form until the 597 RFC(s) are actually published, at which point the ISD will be updated 598 as an administrative procedure (i.e., without a requirement for a 599 further Last-Call or IESG action). Any documents previously posted 600 as Internet-Drafts shall be removed from the Internet-Drafts 601 directory when they are published in ISD or RFC form. All Protocol 602 Action notices, and notices sent to the RFC Editor or IETF 603 administrative entities, in conjunction with a Standards Action shall 604 be copied to the IETF. 606 7.5. Updating of RFC 2026, Section 3.3 608 Section 3.3 of RFC 2026 specifies Requirement and recommendation 609 levels for standards-track documents. It, too, will need updating in 610 the light of provisions associated with how those concepts can be 611 expressed in ISDs and, in particular, for Applicability Statements 612 that are embedded in an ISD rather than being published as separate 613 RFCs. However, that updating should probably be performed as part of 614 a complete review and rewrite of RFC 2026, rather than being 615 "Updated" by inclusion in this document. 617 [[Note in Draft: A review of the rest of section 6.1.3 and all of 6.2 618 through 6.4 of RFC 2026 indicates that they are ripe for updating. 619 Since most of the reasons for that are unrelated to this document, 620 proposed revisions are not included here. However, any revision of 621 6.2, 6.3, or 6.4 should clarify the difference between revising an 622 ISD and revising the underlying RFCs, favoring the former when 623 possible for smaller changes. The procedures outlined in those 624 sections are not affected by this document; only the particular 625 specifications being referenced or changes are (and that only in some 626 cases).]] 628 8. Transition 630 Obviously, we now have many full Internet Standards, with STD numbers 631 assigned and packaging defined by those numbers, that are not 632 associated with documents as described here. We have even more 633 documents at Proposed or Draft Standard levels that do not have 634 either documents of this type or grouping. Some of those documents 635 should almost certainly be bound to existing packages defined by STD 636 numbers. If this process is not bootstrapped by issuing ISDs for 637 those documents, it probably won't work. So the following approach, 638 which can be applied more less mechanically, is suggested: 640 o Alter the templates for the RFC Index and similar documents to 641 contain provisions for an ISD reference element 642 o For all documents now identified as Standards Track, and for non- 643 procedural BCPs, insert an indication that an ISD is pending. 644 Depending on IESG decisions and available of resources within the 645 community, some standards-track RFCs, and hence the associated 646 standards, might remain in "ISD pending" state for an extended 647 period. 648 o For each existing STD number, assign a name or acronym and create 649 a prototype ISD document. Reuse of the STD numbers as ISD numbers 650 would save some time and avoid some confusion, but such binding is 651 not required (see Section 4). For documents that have been 652 assigned STD numbers, this step and the management of titles and 653 abstracts, as discussed below, can be done from the existing std- 654 index being maintained by the RFC Editor. These prototype 655 documents should be populated with the list of RFCs now associated 656 with the STD number. All of them should be identified as Internet 657 Standards. 658 o For each existing Proposed or Draft Standard, generate a template 659 document and assign a name and number. Exceptions should be made 660 and documents grouped when it is obvious and uncontroversial that 661 several documents belong together and someone can be found to do 662 the work. [[anchor15: It is noted, without necessarily making a 663 recommendation, that grouping has historically been performed by 664 the RFC Editor rather than the IESG and that the assignments has 665 usually been considered reasonable (no categorization system will 666 ever satisfy everyone all of the time). Having the RFC Editor 667 perform that role might be an appropriate way to move forward with 668 existing standards-track documents, resources and priorities 669 permitting.]] Initial assignments and drafts should be created on 670 an area basis, preferably by directorates or specially-selected 671 committees, coordinating with any reclassification efforts to 672 avoid duplicate work. Populate the title and abstract of these 673 template documents with the title and abstract of the first RFC in 674 the series. This won't be perfect, and in some cases, won't be 675 even close, but it is better than nothing (and _much_ better than 676 getting stuck waiting for someone to interpret the RFCs and do a 677 write-up). As the IESG deems appropriate, this step may be 678 deferred for some or all of the relevant RFCs until either they 679 come up for revision or volunteers are found. 680 o For both the existing full standards and for documents associated 681 with RFCs at a lower maturity level, omit any applicability, 682 errata, or similar sections but include, for convenience and non- 683 normatively, links to the RFC Editor's errata page where 684 applicable. 685 o Again for all of these template documents, populate the History 686 section with a note to the effect that the Standard existed before 687 the relevant date and the document is initialized as of that date. 688 o It will be important to preserve the STD numbers and index 689 indefinitely, because some references exist to them. However, 690 that list will not be expanded, i.e., STD numbers will not be 691 assigned to new documents. Similarly, no further BCP numbers will 692 be assigned to technical or operational BCP documents; those 693 documents are expected to be absorbed into, or referenced from, 694 the ISD series. IETF Procedural BCPs are not covered in this 695 document. 697 9. Operational Issues 699 There is a case to be made that creating this sort of document series 700 is additional work for the IESG. In practice, the authors don't 701 believe it, at least to any significant degree. All of the relevant 702 information is created today. It is scattered in meeting minutes and 703 secretariat notes, protocol action notices, discussions about whether 704 to restart WGs to deal with problems, etc. Today that information, 705 much of it quite useful, gets lost or at least becomes quite 706 difficult to find. Conversely, these series should reduce workload 707 by considerably reducing the pressure to find editors to write or 708 rewrite RFCs whose purpose is ultimately "this document is just like 709 RFC xxxx, except that section 3.1.3 is removed to permit promoting 710 the specification to the next maturity level". The IESG can 711 certainly still insist on that procedure if it deems it necessary, 712 but it should also be possible to Last Call a revised ISD that 713 contains more or less that sentence and not touch the RFC at all. 714 And, if a WG responsible for creating or updating an ISD can't come 715 up with an appropriate title and abstract/brief description, we are 716 in a kind of trouble that goes well beyond any procedural issues. 718 For a new specification document intended to be processed onto the 719 standards track (including non-procedural BCPs), responsibility for 720 preparing a draft of a new or revised ISD and advising on whether the 721 standards-track document will require a new ISD number or become part 722 of an existing ISD lies with the relevant WG or other submitter. The 723 IESG will issue a Last Call that includes the proposed ISD text along 724 with the substantive document(s). They will then modify the ISD text 725 as needed based on input during Last Call and internal discussions. 727 In general, the new or revised ISD will be issued at the same time as 728 (or replacing) the Protocol Action Notice, referencing the approved 729 Internet-Draft and containing copies of any RFC Editor instructions. 730 That material would then be replaced in the ISD when the relevant 731 documents are published. 733 The ISD document is intended to become the repository for the 734 substantive content of Protocol Action Notices and for IESG 735 statements and qualifications about what they are approving. This 736 will include any "known defects" or "this must be fixed when the 737 document is advanced to the next maturity level" statements. 739 It is the intent of this specification that all substantive or 740 normative changes to an ISD be the result of IETF consensus, i.e., 741 that the change be made only after a Last Call and IESG review and 742 approval. However, more flexibility and less formality is 743 appropriate for at least some non-normative changes, commentary, etc. 744 The IESG is tasked with specifying and documenting the types of 745 changes that do not require Last Calls or IESG approval, and the 746 processes for making those changes. 748 This document carefully does not specify the registry mechanism for 749 assigning new ISD numbers, nor the details of publication and 750 repository mechanisms for the documents, although it specifies some 751 requirements for them (see Section 4). Either or both might sensibly 752 be done by the RFC Editor (that arrangement would certainly be 753 consistent with historical precedents), but, if only because the ISD 754 series would be a new task for them, it seems wise to leave this 755 question to the IETF administrative process to sort out as seems 756 appropriate in the broad administrative context. 758 Regardless of what organizational arrangements are responsible for 759 updating and maintaining these documents, and in spite of their 760 containing a cumulative change history, they should be treated as 761 archival -- at least as archival as the RFC series. 763 10. References and Citations Involving ISDs 765 10.1. References to ISDs or References to RFCs 767 Before this proposal was generated, vendors who wished to specify 768 what they support, and potential customers who wished to specify what 769 they wanted to purchase, had a choice between referencing specific 770 RFCs (to get precision) or, for full standards, a specific STD number 771 (in an attempt to get "the most current version"). Except for 772 providing an "ISD" mechanism for referencing documents other than 773 full Internet Standards, this proposal does not change either of 774 those options: both are still free to use the existing forms. In the 775 rare case in which a vendor is deliberately attempting to confuse its 776 potential customers, this mechanism is not likely to help very much 777 either. It does, however, provide a third option, which is to 778 specify the state of an ISD (and hence a Standard) as of a particular 779 date (even a date in the past or future) or within a particular date 780 range. So, whatever the referencing issues are today, this certainly 781 does not make them worse and almost certainly makes them better. 783 It should also be noted that other Standardization bodies have had 784 difficulties when referencing RFCs. It is not always clear whether 785 an RFC or an STD should be referenced. When a reference is made, 786 there can be problems when the RFC that is referenced becomes updated 787 or obsoleted. 789 10.2. References from ISDs 791 10.2.1. Document References 793 An ISD can be thought of as anchored in one of more "base documents" 794 -- RFCs that, in combination, specify the technical content of the 795 standard itself. These base documents must be standards-track 796 technical specifications or operational or Applicability Statement 797 BCPs (i.e., not IETF-process BCPs, see [Standing-Docs]). All 798 references to base documents are, essentially by definition, 799 normative and must follow the traditional rules of the RFC Editor for 800 stability of references (see, e.g., [RFC2223]) as modified by 801 [RFC3967]. However, an ISD may reference, informationally, any 802 document or material felt to be helpful in understanding the standard 803 or its context. 805 References to, and discussion of, base documents may, and normally 806 will, associate standards-track maturity levels with those documents. 807 The underlying RFCs themselves are no longer considered to have such 808 maturity levels. 810 10.2.2. Errata and Corrections 812 Errata and other corrections that represent IETF consensus (i.e., 813 based on an IESG, or IESG-delegated, determination after Last Call) 814 are normative and identified in a way that distinguishes them from 815 suggested errata or changes that are not known to represent IETF 816 consensus. The latter may still be included in the ISD document as 817 informative material under the general "felt to be helpful" provision 818 of the previous subsection. 820 10.3. Citing an ISD 822 Once ISDs become available for a given IETF-produced Standard, 823 references to those standards are expected to take one of the 824 following forms, depending on the needs of the authors and the 825 standards of the publication in which the reference appears. 827 1. Internet Engineering Task Force (IETF), ISD-TITLE (Internet 828 Standard ISD NNNN), as of YYYY.MM.DD 829 2. Internet Engineering Task Force (IETF), "ISD-TITLE" (Internet 830 Standard ISD NNNN), as of YYYY.MM.DD, specifically as described 831 in RFC-AUTHOR, "RFC-TITLE", RFC NNNN, DATE. 832 The substitutions for the capitalized strings should be obvious. If 833 an RFC reference appears, as in the second form, it may be repeated 834 for each relevant RFC. And URI references to document locations may 835 be added if required (or permitted by author preference) by the 836 relevant publication. 838 11. IANA Considerations 840 This document does not anticipate any specific tasks for the IANA. 841 However, over time, it may be desirable to review and update the 842 descriptions of various registries to refer to ISD numbers, rather 843 than RFC numbers, as the definitions or authority for those 844 registries. See also Section 9. 846 12. Security Considerations 848 This document specifies an administrative procedure for the IETF and 849 hence does not raise any new issues about the security of the 850 Internet. However, the availability of the type of document 851 described here may provide a convenient mechanism and repository of 852 vulnerabilities and other issues that are discovered after RFCs are 853 issued but that do not justify updating (or for which resources are 854 not available to update) the relevant RFC. Having an obvious place 855 to look for those notifications and discussions for standards-track 856 documents might enhance overall security somewhat. 858 13. Acknowledgements 860 The general ideas described here have been discussed on and off for 861 several years, but have never been turned into public documents. 862 Thanks are due to several generations of IAB and IESG members and to 863 RFC Editor staff for helping to clarify the ideas and to identify 864 some variants that would or would not work. The ideas in this 865 specific presentation are, of course, those of the author and are one 866 with which some of the contributors might disagree. Pekka Savola 867 provided extensive and very useful comments on a preliminary version 868 of the initial draft. Harald Alvestrand, Bob Braden, and several 869 others made comments on the first posted draft that resulted in 870 important clarifications. Discussions during and after IETF 60 led 871 to further changes and the consolidation of the previous relevant 872 documents. Bob Braden suggested not trying to reuse the term "STD", 873 and provided new term "ISD". Additional helpful comments and 874 corrections were provided by Pekka Savola and Scott Bradner. 876 14. Changes from Previous Versions 878 [[Note in Draft: This section is to be removed before RFC 879 publication]] 881 Version 00. This version replaces and consolidates the previous 882 documents "Repurposing the STD Designation" 883 (draft-klensin-newtrk-std-repurposing-00.txt, 6 June 2004) and 884 "Standards, What Standards?" 885 (draft-loughney-what-standards-01.txt, February 2004). It also 886 includes a number of editorial clarifications and a few more 887 details than its predecessors. The tone is still somewhat 888 informal and conversational; if general consensus is reached on 889 the ideas, that should be corrected, in both the text and the 890 abstract, in a subsequent draft. 891 Version 01. This version incorporates the changes and clarifications 892 discussed in a meeting of the NEWTRK WG at IETF 61 (Washington, 893 DC, USA, November 2004) and on the mailing list in the subsequent 894 weeks. While some outstanding issues and possible issues remain, 895 the document has been considerably tightened up and a number of 896 previous loose ends documented. In the process, some of the 897 conversational text in the previous versions (see above) has been 898 edited into a more formal form. Most of the "why is this 899 justified and being done" material has been moved to an appendix 900 in order to facilitate eventually turning the Internet-Draft into 901 a permanent IETF process specification. 902 Version 02. This version incorporates the changes and clarifications 903 discussed in the NEWTRK WG meeting at IETF 62 (Minneapolis, MN, 904 USA, March 2005). All previous non-editorial "notes in draft" 905 have been resolved, and those that discuss design choices have 906 been removed to appendices. 907 Version 03. This version produced in response to mailing list 908 comments, suggestions by a few IESG members, and a general review. 909 Material has been added to specify reference formats (at least one 910 of the authors regrets the fact that this was never done for RFCs) 911 and to fill in various other details to facilitate discussion. A 912 new section, titled "Procedure for New Standards and Associated 913 ISDs" has been added and new text has been added to the section on 914 Transition, to better clarify intent and outline possible ways 915 forward. An additional new appendix has been added to list 916 outstanding issues and placeholders; readers are encouraged to 917 examine it before complaining about what is or is not present. 919 15. References 921 15.1. Normative References 923 [RFC2026] Bradner, S., "The Internet Standards Process -- Revision 924 3", BCP 9, RFC 2026, October 1996. 926 [RFC3967] Bush, R. and T. Narten, "Clarifying when Standards Track 927 Documents may Refer Normatively to Documents at a Lower 928 Level", BCP 97, RFC 3967, December 2004. 930 15.2. Informative References 932 [ISD-Examples-Process] 933 Bradner, S., "Sample ISD for the IETF Standards Process", 934 draft-ietf-newtrk-sample-isd-00 (work in progress), 935 October 2004. 937 [ISD-Examples1] 938 Klensin, J., "Internet Standards Documentation (ISDs) - 939 Examples", draft-ietf-newtrk-sample-isd-00 (work in 940 progress), October 2004. 942 [RFC1311] Postel, J., "Introduction to the STD Notes", RFC 1311, 943 March 1992. 945 [RFC1396] Crocker, S., "The Process for Organization of Internet 946 Standards Working Group (POISED)", RFC 1396, January 1993. 948 [RFC1602] Huitema, C. and P. Gross, "The Internet Standards Process 949 -- Revision 2", RFC 1602, March 1994. 951 [RFC2223] Postel, J. and J. Reynolds, "Instructions to RFC Authors", 952 RFC 2223, October 1997. 954 [RFC3774] Davies, E., "IETF Problem Statement", RFC 3774, May 2004. 956 [Standing-Docs] 957 Klensin, J., "Standing Documents Describing IETF Processes 958 and Operations", draft-ietf-newtrk-sd-00 (work in 959 progress), February 2004. 961 Appendix A. Motivation and Historical Context 963 Appendix A.1. Problem(s) 965 The following problems are excerpted from Section 2.4 of the IETF 966 Problem statement [RFC3774]. 968 o Relatively few specifications are now progressed beyond Proposed 969 Standard (PS) to Draft Standard (DS) level, and even fewer to Full 970 Standard (FS). 971 o There is no formal bug reporting or tracking system in place for 972 IETF specifications. 973 o The periodic review of protocols at PS and DS levels specified in 974 are not being carried out, allowing protocols to persist in these 975 lower maturity levels for extended periods of time, whereas the 976 process would normally expect them to progress or be relegated to 977 Historic status. 978 o No individual or body is given the task of 'maintaining' a 979 specification after the original WG has closed down. 980 Specifications are generally only updated when a need for a new 981 version is perceived. No attempt is normally made to correct bugs 982 in the specification (whether they affect operation or not) and 983 the specification is not updated to reflect parts of the 984 specification that have fallen into disuse or were, in fact, never 985 implemented. This is in part because the current procedures would 986 require a standard to revert to the PS maturity level even when 987 specification maintenance is carried out which can be demonstrated 988 to have no or minimal effect on an existing protocol at DS or FS 989 level. 990 o Few Specifications Progress Beyond Proposed Standard. 991 The IETF, as of late, does not have a good track record of moving 992 protocols beyond Proposed Standard. In fact, the goal of most 993 Working Groups is to produce a set of RFCs and then shut down. 994 Working groups that do this are considered to have succeeded. 995 There are only a handful of long-lived working groups, such as 996 IPv6, whose charters include progressing standards beyond Proposed 997 Standards. Occasionally, new working groups need to be spun up to 998 make sense of the existing set of RFCS, such as tcpm (TCP 999 Maintenance). 1000 o There is no Formal Bug Reporting or Tracking System. 1001 Bugs in a specification can be found at any point. There have 1002 been bugs found even in Full Standards. How do we ensure 1003 correctness in our own standards? 1005 This document does not take a stand on the issue of the relevance of 1006 the current standards track. It does note that at any given moment, 1007 a standard may be undergoing work to progress the document to another 1008 level. We discuss the problems identified in more detail below. 1010 Appendix A.2. Periodic Reviews of Protocols are not Being Carried Out 1012 Many protocols suffer from benign neglect. The working group charged 1013 with developing the protocol becomes dormant or is shut down. The 1014 principal authors of the specification may no longer be involved in 1015 the IETF. Further development of the protocol may even be officially 1016 discouraged. 1018 Other standards development organizations (SDOs) may consider 1019 extensions or modification to the protocols. This causes problems 1020 for parties interested in the technology, as it becomes unclear as to 1021 exactly what specifies a particular protocol. Additionally, it makes 1022 it hard to track errors in or updates to a specification or protocol. 1024 Appendix A.3. There is no Maintenance Team Responsible for a Protocol 1026 Specifications are generally only updated when a need for a new 1027 version is perceived. No attempt is normally made to correct bugs in 1028 the specification (whether they affect operation or not) and the 1029 specification is not updated to reflect parts of the specification 1030 that have fallen into disuse or were, in fact, never implemented. 1031 This is in part because the current procedures would require a 1032 standard to revert to the PS maturity level even when specification 1033 maintenance is carried out which can be demonstrated to have no or 1034 minimal effect on an existing protocol at DS or FS level. 1036 Appendix B. Notes on the Design 1038 In the process of developing this specification, several notes and 1039 comment were made about tradeoffs. Those notes appear below, 1040 essentially unedited. They are not a normative part of the 1041 specification. 1043 Appendix B.1. Comments, discussion notes, and proposed errata 1045 If makes sense to the community to have an archive of comments, 1046 discussion, or proposed errata on the documents, that is fine, and it 1047 would be useful for these documents to identify the locations of 1048 those archives. But we should be very careful that the contents of 1049 such archives are not confused with the content of the specifications 1050 unless they go through some sort of formal review and consensus 1051 process. The description of that process in the specification is 1052 deliberately open-ended and flexible. If the IESG is willing to 1053 accept and maintain formal responsibility for whatever appears in ISD 1054 documents, they could include some non-normative changes being made 1055 by, e.g., maintenance committees should the community want to move in 1056 that direction. 1058 Appendix B.2. Numbers versus Names 1060 There was an extended debate in the Working Group as to whether ISDs 1061 were better identified by acronyms or serial numbers. There are 1062 advantages to names or acronyms and and to numbers. The former are 1063 easier to remember as long as there are not too many of them and are 1064 usually more human friendly. The latter are very precise and 1065 language-independent. The choice between the two did not appear to 1066 be worth the amount of energy it would have taken to reach consensus, 1067 if even that were possible. Consequently, the document recommends 1068 assigning both a number and a name (acronym or other string) to each 1069 ISD. 1071 Appendix B.3. Citations of Informative Material 1073 There is discussion in Section 10.2.1 about the inclusion of 1074 informative (non-normative) material, but no specific guidance is 1075 given about what material is and is not appropriate, other than that 1076 it is "felt to be helpful". The apparent ambiguity is deliberate, 1077 relying on good sense and the requirement that substantive changes to 1078 ISDs must be Last Called in the IETF, rather than an attempt to make 1079 specific rules that would probably be inappropriate for some future 1080 situation. 1082 Appendix C. Open Issues 1084 [[Note in Draft: The RFC Editor should remove this section prior to 1085 publication.]] 1087 The following issues are still open, or were raised too late in the 1088 editing cycle to be addressed in this draft. 1090 ISD Authors 1091 The introduction to Section 5 indicates that ISDs do not have 1092 authors and that any author, editor, or contributor information 1093 should be put into an Acknowledgements or Contributors section. A 1094 recent suggestion was made on the NEWTRK mailing list to the 1095 effect that listing authorship might motivate people to create 1096 these documents, especially for standards-track documents that 1097 existed prior to the introduction of ISDs. The arguments against 1098 this remain that (i) the possibility that giving ISDs authors 1099 would detract from credit for the authors and editors of the 1100 substantive (normally RFC) documents themselves and (ii) that the 1101 responsible "author" for an ISD should properly be the IETF 1102 itself. But this issue needs to be resolved. 1104 Level of Specification 1105 The authors of this document, with what appears to be the general 1106 agreement of the NEWTRK WG, deliberately did not specify a number 1107 of details, preferring instead to give the IESG the option of 1108 making choices it found comfortable and adjusting those choices as 1109 experience developed. It is clear, at least to the authors, that 1110 ISDs will not succeed unless they have enthusiastic IESG support, 1111 and quibbling about essentially arbitrary details is not a good 1112 way to obtain that support or to determine whether it exists. 1113 However, it is probable that the community and the IESG will 1114 discover some topics that should be specified in precise detail 1115 and others that should be specified in even less detail than now 1116 appears above. This item is inserted here as a placeholder to 1117 note that the question of level of detail is still, intentionally, 1118 unresolved. 1120 Strawman details 1121 Version -02 of this draft specification contains details in 1122 Section 7, Section 10.3 and elsewhere that need to be checked and 1123 verified as what is wanted. Much of that burden falls more 1124 appropriately on the IESG than on the community. 1126 Additional rationale 1127 In addition, draft -02 contains several notes in draft that 1128 explain tentative design choices. Those will be moved to the 1129 appropriate appendix, or, if appropriate, dropped, in the next 1130 draft. Having them inline now would appear to facilitate 1131 efficient review. 1133 Authors' Addresses 1135 John C Klensin 1136 1770 Massachusetts Ave, #322 1137 Cambridge, MA 02140 1138 USA 1140 Phone: +1 617 491 5735 1141 Email: john-ietf@jck.com 1143 John A Loughney 1144 Itamerenkatu 11-13 1145 Helsinki, 00180 1146 Finland 1148 Phone: +358 5 04836242 1149 Email: john.loughney@nokia.com 1151 Intellectual Property Statement 1153 The IETF takes no position regarding the validity or scope of any 1154 Intellectual Property Rights or other rights that might be claimed to 1155 pertain to the implementation or use of the technology described in 1156 this document or the extent to which any license under such rights 1157 might or might not be available; nor does it represent that it has 1158 made any independent effort to identify any such rights. Information 1159 on the procedures with respect to rights in RFC documents can be 1160 found in BCP 78 and BCP 79. 1162 Copies of IPR disclosures made to the IETF Secretariat and any 1163 assurances of licenses to be made available, or the result of an 1164 attempt made to obtain a general license or permission for the use of 1165 such proprietary rights by implementers or users of this 1166 specification can be obtained from the IETF on-line IPR repository at 1167 http://www.ietf.org/ipr. 1169 The IETF invites any interested party to bring to its attention any 1170 copyrights, patents or patent applications, or other proprietary 1171 rights that may cover technology that may be required to implement 1172 this standard. Please address the information to the IETF at 1173 ietf-ipr@ietf.org. 1175 Disclaimer of Validity 1177 This document and the information contained herein are provided on an 1178 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 1179 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 1180 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 1181 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 1182 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 1183 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 1185 Copyright Statement 1187 Copyright (C) The Internet Society (2006). This document is subject 1188 to the rights, licenses and restrictions contained in BCP 78, and 1189 except as set forth therein, the authors retain all their rights. 1191 Acknowledgment 1193 Funding for the RFC Editor function is currently provided by the 1194 Internet Society.