idnits 2.17.1 draft-ietf-newtrk-repurposing-isd-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** It looks like you're using RFC 3978 boilerplate. You should update this to the boilerplate described in the IETF Trust License Policy document (see https://trustee.ietf.org/license-info), which is required now. -- Found old boilerplate from RFC 3978, Section 5.1.a on line 16. -- Found old boilerplate from RFC 3978, Section 5.5 on line 645. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 622. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 629. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 635. ** The document seems to lack an RFC 3978 Section 5.1 IPR Disclosure Acknowledgement. ** This document has an original RFC 3978 Section 5.4 Copyright Line, instead of the newer IETF Trust Copyright according to RFC 4748. ** This document has an original RFC 3978 Section 5.5 Disclaimer, instead of the newer disclaimer which includes the IETF Trust according to RFC 4748. ** The document uses RFC 3667 boilerplate or RFC 3978-like boilerplate instead of verbatim RFC 3978 boilerplate. After 6 May 2005, submission of drafts without verbatim RFC 3978 boilerplate is not accepted. The following non-3978 patterns matched text found in the document. That text should be removed or replaced: This document is an Internet-Draft and is subject to all provisions of Section 3 of RFC 3667. By submitting this Internet-Draft, each author represents that any applicable patent or other IPR claims of which he or she is aware have been or will be disclosed, and any of which he or she becomes aware will be disclosed, in accordance with Section 6 of BCP 79. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- == No 'Intended status' indicated for this document; assuming Proposed Standard Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (September 24, 2004) is 7155 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) == Outdated reference: A later version (-01) exists of draft-klensin-newtrk-antiques-00 -- Obsolete informational reference (is this intentional?): RFC 1602 (Obsoleted by RFC 2026) -- Obsolete informational reference (is this intentional?): RFC 2223 (Obsoleted by RFC 7322) Summary: 5 errors (**), 0 flaws (~~), 3 warnings (==), 9 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group J. Klensin 3 Internet-Draft J. Loughney 4 Expires: March 25, 2005 September 24, 2004 6 Internet Standards Documentation (ISDs) 7 draft-ietf-newtrk-repurposing-isd-00.txt 9 Status of this Memo 11 This document is an Internet-Draft and is subject to all provisions 12 of section 3 of RFC 3667. By submitting this Internet-Draft, each 13 author represents that any applicable patent or other IPR claims of 14 which he or she is aware have been or will be disclosed, and any of 15 which he or she become aware will be disclosed, in accordance with 16 RFC 3668. 18 Internet-Drafts are working documents of the Internet Engineering 19 Task Force (IETF), its areas, and its working groups. Note that 20 other groups may also distribute working documents as 21 Internet-Drafts. 23 Internet-Drafts are draft documents valid for a maximum of six months 24 and may be updated, replaced, or obsoleted by other documents at any 25 time. It is inappropriate to use Internet-Drafts as reference 26 material or to cite them other than as "work in progress." 28 The list of current Internet-Drafts can be accessed at 29 http://www.ietf.org/ietf/1id-abstracts.txt. 31 The list of Internet-Draft Shadow Directories can be accessed at 32 http://www.ietf.org/shadow.html. 34 This Internet-Draft will expire on March 25, 2005. 36 Copyright Notice 38 Copyright (C) The Internet Society (2004). 40 Abstract 42 It has been observed that the current IETF standard designations, STD 43 nnnn and BCP nnnn designation, have not worked well. Problems have 44 been found when one of them is used either as a stable reference for 45 external specifications or as a combined reference for multiple 46 documents linked together into a single document. This document 47 proposes two changes to these designations. The first of these 48 changes would create a new document series and assign a new number 49 and acronym to a specification when it enters the first level of the 50 Standards Track (or is first designated as a BCP). The second would 51 migrate the concept of STDs and BCPs numbering of RFCs into actual 52 documents that detail what they identify, their publication 53 information and their change history. 55 Table of Contents 57 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 58 2. Problem(s) . . . . . . . . . . . . . . . . . . . . . . . . . 4 59 3. Periodic Reviews of Protocols are not Being Carried Out . . 5 60 4. There is no Maintenance Team Responsible for a Protocol . . 5 61 5. Proposal Overview . . . . . . . . . . . . . . . . . . . . . 5 62 6. A New Document Series . . . . . . . . . . . . . . . . . . . 7 63 7. Content and Organization of an ISD Document . . . . . . . . 8 64 8. Transition . . . . . . . . . . . . . . . . . . . . . . . . . 9 65 9. Operational Issues . . . . . . . . . . . . . . . . . . . . . 10 66 10. References to ISDs or References to RFCs . . . . . . . . . . 11 67 11. IANA Considerations . . . . . . . . . . . . . . . . . . . . 11 68 12. Security Considerations . . . . . . . . . . . . . . . . . . 12 69 13. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 12 70 14. Changes from Previous Versions . . . . . . . . . . . . . . . 12 71 15. References . . . . . . . . . . . . . . . . . . . . . . . . . 13 72 15.1 Normative References . . . . . . . . . . . . . . . . . . . 13 73 15.2 Informative References . . . . . . . . . . . . . . . . . . 13 74 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . 13 75 Intellectual Property and Copyright Statements . . . . . . . 15 77 1. Introduction 79 The IETF has produced a large (and useful) body of work. In many 80 ways, the IETF has been a victim of its own (or at least of TCP/IP's) 81 success. As the standards which the IETF produces see wider 82 deployment by parties outside of the IETF, the system of 83 documentation and updating within the IETF causes some amount of 84 confusion. 86 The "STD" and "BCP" labels are described in [RFC2026] as subseries of 87 the RFC series, with their numbers being assigned when documents are 88 published as Internet Standards or as BCPs. The purpose and 89 organization of the STD series is defined in more detail in 90 [RFC1311]. Beyond those brief statements, the organization of the 91 two series and the classification of documents as either belonging 92 together as part of a single "STD" specification or as separate, have 93 largely been a matter of oral tradition, with more of the decisions 94 being made as part of the RFC indexing process than explicitly by the 95 IESG as part of the standards process. RFC1311, written before the 96 standards process reforms of the 1992-1994 period (see, e.g., 97 [RFC1396] and [RFC1602]), assigns responsibility for defining the 98 content of STD documents to the IAB, but was never updated to reflect 99 the change to IESG responsibility for the standards track. The 100 intent has been to permit a stable reference to particular 101 specifications and groups of documents making up a specification, a 102 reference that survives replacement of one RFC with another, addition 103 or deletion of RFCs from the collective specification, and so on. 105 While the intentions are fairly clear and quite desirable, this 106 document suggests that the system has never worked well, especially 107 for STDs that comprise (or point to) several RFCs. There is no 108 easily-accessible audit track that specifies which documents were 109 part of an standard (identified by an STD number) at a particular 110 time (which can be very important for determining what a 111 specification that points to an STD actually means or requires). The 112 low level of involvement of the IESG in the classification process is 113 probably several problems waiting to happen. And the "do not assign 114 an STD number until the specification reaches full Internet Standard" 115 model is unrealistic in a world in which much of the Internet runs on 116 Proposed Standards and in which the IETF only very rarely approves 117 and publishes "Applicability Statement" documents (and, when it does 118 publish them, has little idea what to do with them -- several 119 documents that rationally fall into that category have been published 120 as BCPs instead). 122 This document is intended to create a paper track and specific 123 "benchmark" or "snapshot" documentation for Internet Standards, not 124 on web pages and bug tracking. 126 The discussion and proposal that follows are written in terms of 127 traditional standards track documents (Proposed, Draft, and Internet 128 Standard). Whether it should also be applied to BCPs needs further 129 review: the applicability is fairly obvious, but it is not clear 130 whether it is necessary enough to justify the extra trouble. 132 2. Problem(s) 134 The following problems are excerpted from Section 2.4 of the IETF 135 Problem statement [RFC3774]. 137 o Relatively few specifications are now progressed beyond Proposed 138 Standard (PS) to Draft Standard (DS) level, and even fewer to Full 139 Standard (FS). 140 o There is no formal bug reporting or tracking system in place for 141 IETF specifications. 142 o The periodic review of protocols at PS and DS levels specified in 143 are not being carried out, allowing protocols to persist in these 144 lower maturity levels for extended periods of time, whereas the 145 process would normally expect them to progress or be relegated to 146 Historic status. 147 o No individual or body is given the task of 'maintaining' a 148 specification after the original WG has closed down. 149 Specifications are generally only updated when a need for a new 150 version is perceived. No attempt is normally made to correct bugs 151 in the specification (whether they affect operation or not) and 152 the specification is not updated to reflect parts of the 153 specification that have fallen into disuse or were, in fact, never 154 implemented. This is in part because the current procedures would 155 require a standard to revert to the PS maturity level even when 156 specification maintenance is carried out which can be demonstrated 157 to have no or minimal effect on an existing protocol at DS or FS 158 level. 159 o Few Specifications Progress Beyond Proposed Standard. 160 The IETF, as of late, does not have a good track record of moving 161 protocols beyond Proposed Standard. In fact, the goal of most 162 Working Groups is to produce a set of RFCs and then shut down. 163 Working groups that do this are considered to have succeeded. 164 There are only a handful of long-lived working groups, such as 165 IPv6, whose charters include progressing standards beyond Proposed 166 Standards. Occasionally, new working groups need to be spun up to 167 make sense of the existing set of RFCS, such as tcpm (TCP 168 Maintenance). 169 o There is no Formal Bug Reporting or Tracking System. 170 Bugs in a specification can be found at any point. There have 171 been bugs found even in Full Standards. How do we ensure 172 correctness in our own standards? 174 This document does not take a stand on the issue of the relevance of 175 the current standards track. It does note that at any given moment, 176 a standard may be undergoing work to progress the document to another 177 level. We discuss the problems identified in more detail below. 179 3. Periodic Reviews of Protocols are not Being Carried Out 181 Many protocols suffer from benign neglect. The working group charged 182 with developing the protocol becomes dormant or is shut down. The 183 principal authors of the specification may no longer be involved in 184 the IETF. Further development of the protocol may even be officially 185 discouraged. 187 Other standards development organizations (SDOs) may consider 188 extensions or modification to the protocols. This causes problems 189 for parties interested in the technology, as it becomes unclear as to 190 exactly what specifies a particular protocol. Additionally, it makes 191 it hard to track errors in or updates to a specification or protocol. 193 4. There is no Maintenance Team Responsible for a Protocol 195 Specifications are generally only updated when a need for a new 196 version is perceived. No attempt is normally made to correct bugs in 197 the specification (whether they affect operation or not) and the 198 specification is not updated to reflect parts of the specification 199 that have fallen into disuse or were, in fact, never implemented. 200 This is in part because the current procedures would require a 201 standard to revert to the PS maturity level even when specification 202 maintenance is carried out which can be demonstrated to have no or 203 minimal effect on an existing protocol at DS or FS level. 205 5. Proposal Overview 207 This document proposes that a new document series be created, called 208 Internet Standards Documents ("ISD"s) and that these be real 209 documents, separate from the underlying RFCs. The documents would be 210 managed under the direction of the IESG as part of the 211 standards-specification process, rather than being simply pointers in 212 indexes as, e.g., the STD series has been, or being the RFCs 213 themselves with different file names or packaging. It proposes that 214 ISD documents be created and numbers assigned when specifications 215 enter the formal standards track (Proposed Standard under the model 216 described in RFC 2026) and that the documents be used to track 217 maturation, applicability recommendations, and history of those 218 specifications. It also outlines the format of those documents, 219 which is expected to be different from the format of protocol 220 specification documents and the RFC series generally ([RFC2223], 221 [rfc2223bis]) and briefly discusses a transition strategy. 223 Debate continues in the IETF about the proper threshold for Proposed 224 Standards with regard to both protocol quality and document quality. 225 Part of the problem is the use of a single, unqualified, label that 226 may not be a good match to all situations. The documents proposed 227 here will allow more flexibility by permitting the IESG to attach 228 appropriate qualifying notes as needed. For example, if the 229 community concluded that a specification should be published as a 230 Proposed Standard, but that potential implementers should be warned 231 that IETF confidence in its stability was lower than usual, these 232 documents would be an appropriate place to publish that type of 233 evaluation. Conversely, if interoperable implementations already 234 existed before the Proposed Standard was published, the corresponding 235 STD document would be an appropriate place to note that fact. 237 These documents, and documents authoritatively (normatively) 238 referenced from them, will become, essentially, the definitions of 239 standards. Consequently, any changes to them will occur only under 240 IESG authority and responsibility. The IESG may, at its discretion, 241 and with appropriate announcements to, and consultation of, the 242 community, delegate authority for some sections to groups responsible 243 for the ongoing maintenance of the standards, but may not relinquish 244 responsibility for the documents themselves. However, nothing in 245 this specification prohibits (or requires) IESG authorization of 246 placement of links in the STD documents that point to less formal and 247 less authoritative discussions of, or comments on, the relevant 248 standards should they deem that appropriate. 250 [[ Note in Draft: In plain English, if it makes sense to the 251 community to have an archive of comments, discussion, or proposed 252 errata on the documents, that is fine, and it would be useful for 253 these documents to identify the locations of those archives. But we 254 should be very careful that the contents of such archives are not 255 confused with the content of the specifications unless they go 256 through some sort of formal review and consensus process. The 257 description of that process above is deliberately open-ended and 258 flexible, as long as the IESG is willing to accept and maintain 259 formal responsibility for whatever appears on those pages and could 260 admit of some changes being made by, e.g., maintenance committees 261 should the community want to move in that direction. ]] 263 By extension from the above, the IESG will need to make 264 determinations, ideally after creating guidelines and getting 265 community review and assent to them, as to criteria (e.g., length, 266 importance, degree of discussion needed) by which authoritative 267 comments and qualifications about standards will be incorporated into 268 the STDs documents or issued as separate RFCs. The starting point 269 and minimum descriptive and qualifying text for new standards will be 270 the text of the Protocol Action Notice. 272 If this proposal is accepted in principle, some additional sections 273 will be required to explicitly update RFC 2026. 275 [[Note in draft: Numbers versus Names. There are advantages to names 276 or acronyms (easier to remember as long as there are not too many of 277 them, more human friendly) and to numbers (very precise and 278 language-independent). The choice between the two does not seem to 279 be worth the amount of energy it will take. Consequently, this 280 version of the document recommends assigning both a number and a name 281 (acronym or other string).]] 283 6. A New Document Series 285 When the IESG agrees to move a document onto the standards track, it 286 either causes a new Internet Standard number ("ISD number") and name 287 or acronym ("ISD name") to be assigned to it, or classifies it as 288 part of an existing standard and assigns that number and name. If 289 multiple, related, specifications are approved at the same time, they 290 may be assigned the same ISD number and name. As those documents are 291 published as RFCs, the RFC may (and presumably usually will) contain 292 the standard number and name since it will constitute a stable 293 forward reference. This assignment of an ISD number and name, and 294 assignment of a specification to it, results in a corresponding ISD 295 document being created or updated, as described below. Following 296 good sense and existing precedent, the IESG may decide to include 297 documents that are not themselves on the standards track (e.g., 298 Informational documents explaining, or describing alternatives to, an 299 agreed-upon standard) in references from a ISD document once that 300 document is defined by the assignment of a number. 302 Advancement of a document on the standards track, publication of 303 applicability statements, notes on errata or other issues of 304 sufficient and substantive importance to require alerting 305 implementers or the community will also result in modifications to 306 the relevant ISD document. It is explicitly anticipated that 307 documents may be moved from one maturity level to another (i.e., 308 under the current system, to Draft, Full, or Historic, or from 309 Experimental to Proposed) by changing the ISD document to identify 310 the new level and include any relevant notes as an alternative to 311 modifying the relevant RFC text and issuing new RFCs (and, of course, 312 modifying the ISD document to reflect those changes). 314 Particular RFCs may move in and out of a ISD (except for the 315 historical record) as one RFC replaces another. Because the ISD 316 document is expected to contain prose, it will be possible to deal 317 with the long-standing issues of what "updates" means by identifying 318 the relevant sections or concepts. And, again because there is 319 descriptive prose present, the IESG will be able to deal 320 appropriately with the relationship between an old Full Standard and 321 a newer document, at a lower maturity level, that is intended to 322 replace it by specifying whatever they consider appropriate about 323 what the implementer or other reader should look at. 325 [[ Note in draft: Were either or both of the "Commission" (or 326 "attic-cleaning") drafts ([NewtrkHistoric], [NewtrkAntique]) to be 327 approved, the opportunities for using this ISD model are obvious. 328 The relevant ISD document could be used to quickly capture, not only 329 the fact that a document had been changed in status, but the date on 330 which that occurred and any useful information about the reason why 331 it was done -- using a much lighter-weight process than RFC 332 publication. However, this proposal is not tied to those in any way. 333 ]] 335 While RFCs are permanent, ISD documents are expected to evolve and 336 incorporate changes over time. However, they are also expected to 337 include explicit change histories in order to make it possible for a 338 reader to examine a current ISD document and determine the status of 339 the relevant standard at any particular previous time. An ISD number 340 or name, once bound to a particular conceptual standard, is never 341 reused for a different concept. 343 7. Content and Organization of an ISD Document 345 An ISD document is expected to follow the general layout and 346 formatting conventions of an RFC (because the community is familiar 347 with them). The components listed below may appear, or are expected 348 to appear (required materials, even if only pro-forma, are identified 349 with asterisks). As with RFCs, additional sections may be included 350 as needed and appropriate. Note that ISDs don't have authors: the 351 RFCs have authors, but the "author" of an ISD would always be "IETF" 352 (or the historical "Network Working Group") so there is no 353 information in providing an author or editor name. A individual who 354 had made a major contribution to the ISD document itself might be 355 listed in an Acknowledgement or as a Contributor. 357 Title.* It would be good for standards to have titles as well as 358 numbers and acronyms (names). As others have pointed out, it 359 would make them, especially those that involve multiple RFCs, a 360 lot easier to talk about. 361 Date.* This is the data the ISD was last updated. Everything else 362 belongs in history or annotation. 363 Abstract.* As with the title, it would be good to have these for 364 standards, describing what the whole package does and not just 365 what individual RFCs do. 367 Maturity Level.* This is the maturity level for the ISD as a whole. 368 Presumably it is the lowest maturity level of any of the 369 associated RFCs but, especially when one of the RFCs is intended 370 to replace an earlier, more mature one, and text is supplied in 371 the ISD that describes the situation, the IESG might decide to 372 have it reflect the maturity level associate with the least mature 373 document needed to form a full description of the standard. 374 Additional comments may be associated with this section; it need 375 not be just a label. If an ISD is retired in its entirety, no 376 matter what maximum maturity level it reached earlier, this entry 377 may be "Historic" with optional descriptive text. 378 RFC list.* For each RFC that is currently associated with this ISD, 379 the name, title, document date, and maturity level most recently 380 assigned and its date. Optionally, an abbreviated abstract, 381 applicability comments, errata, and other notes and commentary can 382 be associated with some or all of the RFCs. When there is a 383 non-obvious relationship among the various documents, it should be 384 described either here or in the applicability remarks below, as 385 appropriate (or in a separate section, if one is required). 386 Applicability Remarks about the standard. Any remarks about 387 applicability that seem useful or appropriate, as authorized. 388 Security Remarks about the standard. Any authorized remarks about 389 the security implications or considerations of the standard that 390 are not completely reflected in the component RFCs. 391 History*. This section should define the entire record of changes to 392 the definition of the documents and applicability statements that 393 make up the standard, with dates identified. It should, in 394 particular, identify the point at which one document superseded or 395 updated another. 397 8. Transition 399 Obviously, we now have many full Internet Standards, with STD numbers 400 assigned and packaging defined by those numbers, that are not 401 associated with documents as described here. We have even more 402 documents at Proposed or Draft Standard levels that do not have 403 either documents of this type or grouping. Some of those documents 404 should almost certainly be bound to existing packages defined by STD 405 numbers. If this process is not bootstrapped by issuing ISDs for 406 those documents, it probably won't work. So the following approach, 407 which can be applied more less mechanically, is suggested: 409 o For each existing STD number, assign a name or acronym and create 410 a prototype ISD document. Reuse of the STD numbers as ISD numbers 411 would save some time and avoid some confusion. This step and the 412 management of titles and abstracts, as discussed below, can be 413 done from the existing std-index being maintained by the RFC 414 Editor. 416 o Populate that document with the list of RFCs now associated with 417 the ISD and identify all of them as Internet Standards. 418 o For each existing Proposed or Draft Standard, generate a template 419 document and assign a name and number. Exceptions should be made 420 and documents grouped when it is obvious and uncontroversial that 421 several documents belong together and someone can be found to do 422 the work. Initial assignments and drafts should be created on an 423 area basis, preferably by directorates or specially-selected 424 committees, coordinates with any reclassification efforts to avoid 425 duplicate work. 426 o Populate the title and abstract with the title and abstract of the 427 first RFC in the series. This won't be perfect, and in some 428 cases, won't be even close, but it is better than nothing (and 429 _much_ better than getting stuck waiting for someone to interpret 430 the RFCs and do a write-up. 431 o Omit any applicability, errata, or similar sections. 432 o Populate the History section with a note to the effect that the 433 Standard existed before the relevant date and the document is 434 initialized as of that date. 435 o As these documents are created, and to avoid having to create all 436 of them at once, modify the official rfc-index and other indices 437 and web pages under IETF control to indicate either the name and 438 number of the ISD document or that the relevant document is still 439 under construction. 440 o It will be important to preserve the STD numbers and index for 441 some time, perhaps indefinitely, because some references exist to 442 them. However, it will not be necessary to expand that list. 443 Absorbing the STD numbering space into the ISD series will further 444 aid in locating appropriate information. 446 9. Operational Issues 448 There is a case to be made that creating this sort of document series 449 is additional work for the IESG. In practice, the authors doesn't 450 believe it, at least to any significant degree. All of the relevant 451 information is created today. It is scattered in meeting minutes and 452 secretariat notes, protocol action notices, discussions about whether 453 to restart WGs to deal with problems, etc. Today that information, 454 much of it quite useful, gets lost or at least becomes quite 455 difficult to find. Conversely, these series should reduce workload 456 by considerably reducing the pressure to find editors to write or 457 rewrite RFCs whose purpose is ultimately "this document is just like 458 RFC xxxx, except that section 3.1.3 is removed to permit promoting 459 the specification to the next maturity level". The IESG can 460 certainly still insist on that procedure if it deems it necessary, 461 but it should also be possible to Last Call a revised ISD that 462 contains more or less that sentence and not touch the RFC at all. 463 And, if a WG responsible for creating or updating an ISD can't come 464 up with an appropriate title and abstract/brief description, we are 465 in a kind of trouble that goes well beyond any procedural issues. 467 This document carefully does not specify the registry mechanism for 468 assigning new STD numbers, nor the publication and repository 469 mechanism for the documents. Either or both might sensibly be done 470 by the RFC Editor (that arrangement would certainly be consistent 471 with historical precedents), but, if only because the STD series in 472 this form would be a new task for them, it seems wise to leave this 473 question to the IETF administrative process to sort out as seems 474 appropriate in the broad administrative context. 476 Regardless of what organizational arrangements are responsible for 477 updating and maintaining these documents, and in spite of their 478 containing a cumulative change history, they should be treated as 479 archival -- at least as archival as the RFC series. 481 10. References to ISDs or References to RFCs 483 Before this proposal was generated, vendors who wished to specify 484 what they support, and potential customers who wished to specify what 485 they wanted to purchase, had a choice between referencing specific 486 RFCs (to get precision) or, for full standards, a specific STD number 487 (to get "the most current version"). Except for providing an "ISD" 488 mechanism for referencing documents other than full Internet 489 Standards, this proposal does not change either of those options: 490 both are still free to use the existing forms. In the rare case in 491 which a vendor is deliberately attempting to confuse its potential 492 customers, this mechanism is not likely to help very much either. It 493 does, however, provide a third option, which is to specify the state 494 of an STD as of a particular date (even a date in the past or future) 495 or within a particular date range. So, whatever the referencing 496 issues are today, this certainly does not make them worse and almost 497 certainly makes them better. 499 It should also be noted that other Standardization bodies have had 500 difficulties when referencing RFCs. It is not always clear whether 501 an RFC or an STD should be referenced. When a reference is made, 502 there can be problems when the RFC that is referenced becomes updated 503 or obsoleted. 505 11. IANA Considerations 507 This document does not anticipate any specific tasks for the IANA. 508 However, over time, it may be desirable to review and update the 509 descriptions of various registries to refer to ISD numbers, rather 510 than RFC numbers, as the definitions or authority for those 511 registries. See also Section 9. 513 12. Security Considerations 515 This document specifies an administrative procedure for the IETF and 516 hence does not raise any new issues about the security of the 517 Internet. However, the availability of the type of document 518 described here may provide a convenient mechanism and repository of 519 vulnerabilities and other issues that are discovered after RFCs are 520 issued but that do not justify updating (or for which resources are 521 not available to update) the relevant RFC. Having an obvious place 522 to look for those notifications and discussions for standards-track 523 documents might enhance overall security somewhat. 525 13. Acknowledgements 527 The general ideas described here have been discussed on and off for 528 several years, but have never been turned into a public documents. 529 Thanks are due to several generations of IAB and IESG members and to 530 RFC Editor staff for helping to clarify the ideas and to identify 531 some variants that would or would not work. The ideas in this 532 specific presentation are, of course, those of the author and are one 533 with which some of the contributors might disagree. Pekka Savola 534 provided extensive and very useful comments on a preliminary version 535 of the initial draft. Harald Alvestrand, Bob Braden, and several 536 others made comments on the first posted draft that resulted in 537 important clarifications. Discussions during and after IETF 60 led 538 to further changes and the consolidation of the previous relevant 539 documents. Bob Braden suggested not trying to reuse the term "STD", 540 and provided new term "ISD". 542 14. Changes from Previous Versions 544 [[Note in Draft: This section is to be removed before RFC 545 publication]] 547 Version 00. This version replaces and consolidates the previous 548 documents "Repurposing the STD Designation" 549 (draft-klensin-newtrk-std-repurposing-00.txt, 6 June 2004) and 550 "Standards, What Standards?" 551 (draft-loughney-what-standards-01.txt, February 2004). It also 552 includes a number of editorial clarifications and a few more 553 details than its predecessors. The tone is still somewhat 554 informal and conversational; if general consensus is reached on 555 the ideas, that should be corrected, in both the text and the 556 abstract, in a subsequent draft. 558 15. References 559 15.1 Normative References 561 [RFC2026] Bradner, S., "The Internet Standards Process -- Revision 562 3", BCP 9, RFC 2026, October 1996. 564 15.2 Informative References 566 [NewtrkAntique] 567 Klensin, J., "Valuable Antique Documents: A Model for 568 Advancement", draft-klensin-newtrk-antiques-00 (work in 569 progress), September 2004. 571 [NewtrkHistoric] 572 Alvestrand, H. and E. Lear, "Getting rid of the cruft: A 573 procedure to deprecate old standards", 574 draft-alvestrand-newtrk-cruft-01 (work in progress), 575 September 2004. 577 [RFC1311] Postel, J., "Introduction to the STD Notes", RFC 1311, 578 March 1992. 580 [RFC1396] Crocker, S., "The Process for Organization of Internet 581 Standards Working Group (POISED)", RFC 1396, January 1993. 583 [RFC1602] Huitema, C. and P. Gross, "The Internet Standards Process 584 -- Revision 2", RFC 1602, March 1994. 586 [RFC2223] Postel, J. and J. Reynolds, "Instructions to RFC Authors", 587 RFC 2223, October 1997. 589 [RFC3774] Davies, E., "IETF Problem Statement", RFC 3774, May 2004. 591 [rfc2223bis] 592 Reynolds, J. and R. Braden, "Instructions to Request for 593 Comments (RFC) Authors", draft-rfc-editor-rfc2223bis-07 594 (work in progress), August 2003. 596 Authors' Addresses 598 John C Klensin 599 1770 Massachusetts Ave, #322 600 Cambridge, MA 02140 601 USA 603 Phone: +1 617 491 5735 604 EMail: john-ietf@jck.com 605 John A Loughney 606 Itamerenkatu 11-13 607 Helsinki, 00180 608 Finland 610 Phone: +358 5 04836242 611 EMail: john.loughney@nokia.com 613 Intellectual Property Statement 615 The IETF takes no position regarding the validity or scope of any 616 Intellectual Property Rights or other rights that might be claimed to 617 pertain to the implementation or use of the technology described in 618 this document or the extent to which any license under such rights 619 might or might not be available; nor does it represent that it has 620 made any independent effort to identify any such rights. Information 621 on the procedures with respect to rights in RFC documents can be 622 found in BCP 78 and BCP 79. 624 Copies of IPR disclosures made to the IETF Secretariat and any 625 assurances of licenses to be made available, or the result of an 626 attempt made to obtain a general license or permission for the use of 627 such proprietary rights by implementers or users of this 628 specification can be obtained from the IETF on-line IPR repository at 629 http://www.ietf.org/ipr. 631 The IETF invites any interested party to bring to its attention any 632 copyrights, patents or patent applications, or other proprietary 633 rights that may cover technology that may be required to implement 634 this standard. Please address the information to the IETF at 635 ietf-ipr@ietf.org. 637 Disclaimer of Validity 639 This document and the information contained herein are provided on an 640 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 641 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 642 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 643 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 644 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 645 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 647 Copyright Statement 649 Copyright (C) The Internet Society (2004). This document is subject 650 to the rights, licenses and restrictions contained in BCP 78, and 651 except as set forth therein, the authors retain all their rights. 653 Acknowledgment 655 Funding for the RFC Editor function is currently provided by the 656 Internet Society.