idnits 2.17.1 draft-ietf-newtrk-proposals-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 912. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 896. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 902. ** The document seems to lack an RFC 3978 Section 5.1 IPR Disclosure Acknowledgement -- however, there's a paragraph with a matching beginning. Boilerplate error? ** This document has an original RFC 3978 Section 5.4 Copyright Line, instead of the newer IETF Trust Copyright according to RFC 4748. ** This document has an original RFC 3978 Section 5.5 Disclaimer, instead of the newer disclaimer which includes the IETF Trust according to RFC 4748. ** The document seems to lack an RFC 3979 Section 5, para. 1 IPR Disclosure Acknowledgement -- however, there's a paragraph with a matching beginning. Boilerplate error? ** The document uses RFC 3667 boilerplate or RFC 3978-like boilerplate instead of verbatim RFC 3978 boilerplate. After 6 May 2005, submission of drafts without verbatim RFC 3978 boilerplate is not accepted. The following non-3978 patterns matched text found in the document. That text should be removed or replaced: By submitting this Internet-Draft, 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 : ---------------------------------------------------------------------------- ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) 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 (July 2004) is 7223 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 -- No information found for draft-loughney - is the name correct? Summary: 7 errors (**), 0 flaws (~~), 3 warnings (==), 7 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group 3 Internet Draft D. Black 4 Document: draft-ietf-newtrk-proposals-00.txt EMC Corporation 5 Expires: January 2005 B. Carpenter 6 IBM 7 July 2004 9 Proposals for a New IETF Standards Track 11 Status of this Memo 13 By submitting this Internet-Draft, each author represents that any 14 applicable patent or other IPR claims of which he or she is aware 15 have been or will be disclosed, and any of which he or she becomes 16 aware will be disclosed, in accordance with Section 6 of 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 Internet- 21 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 30 The list of Internet-Draft Shadow Directories can be accessed at 31 http://www.ietf.org/shadow.html. 33 Abstract 35 Discussions in the IETF's "problem" working group reached consensus 36 that the current IETF 3-stage standards track, as implemented, is not 37 working. This draft proposes various alternative multi-step 38 standards tracks for debate in the "newtrk" working group. 40 Table of Contents 42 1. Introduction...................................................2 43 2. Measuring success..............................................4 44 3. Some Proposals for New Standards Tracks........................4 45 3.1 Clean up our act - make current system work better.........4 46 3.2 No More Mr. Nice Guy - make current system work strictly...5 47 3.3 Prune......................................................6 48 3.4 Slash and Burn.............................................6 49 3.5 Declare Victory............................................6 50 4. Common ideas...................................................7 51 4.1 Snapshots..................................................7 52 4.2 Interoperability Register..................................8 53 4.3 Explicit Version Number....................................8 54 4.4 Better Process Documentation and Tracking..................8 55 5. Discussion of Pros and Cons....................................9 56 6. Security Considerations.......................................10 57 7. Acknowledgements..............................................10 58 8. Change log [RFC Editor to remove this section]................10 59 9. Appendix 1: Summary of Current IETF Standards Track...........11 60 10. Appendix 2: Specific example of "Prune"......................13 61 10.1 Alternate Standards Track Maturity Levels................14 62 10.2 Stable Snapshot..........................................14 63 10.3 Proposed Standard........................................15 64 10.4 Internet Standard........................................17 65 10.5 Minimum time in each stage...............................18 66 11. Informative References.......................................18 67 12. Authors' Addresses...........................................19 69 1. Introduction 71 By way of preamble, note that this is a discussion document and not a 72 firm or fully worked out proposal. Once the "newtrk" working group 73 reaches consensus on the general direction to follow, this document 74 will have served its purpose and a revision or update of [RFC2026] 75 will be needed. 77 The consensus in the "problem" working group was that the current 78 IETF three stage standards track, described in RFC 2026 [RFC2026] and 79 summarized below in Appendix 1, is not working as originally 80 intended. The problem statement document [RFC3774] says: 82 The current hierarchy of Proposed, Draft, and Full Standard 83 maturity levels for specifications is no longer being used in the 84 way that was envisioned when the stratification was originally 85 proposed. In practice, the IETF currently has a one-step 86 standards process that subverts the IETF's preference for 87 demonstrating effectiveness through running code in multiple 88 interoperable implementations. This compresses the process that 89 previously allowed specifications to mature as experience was 90 gained with actual implementations: 92 The document then goes on to list various observations including: 94 1/ Few documents actually progress after being published as 95 Proposed Standard (PS). 97 2/ There is a perception that the IESG raised the quality 98 requirement for approval as PS beyond the intention of 99 [RFC2026]. 101 3/ In spite of the raised quality requirement, running code is not 102 required to achieve PS status. 104 4/ There seems to be a reinforcing feedback loop involved: vendors 105 implement and deploy PS specifications, so increasingly the 106 IESG tries to make the PS documents better. 108 [RFC3774] concludes that the three-stage process is excessive. 110 An alternative interpretation of these observations is that a three- 111 step standards process still operates, but the existing standards 112 levels have been shifted upwards so that PS is no longer the initial 113 step. Vendors will often implement, and their customers deploy, 114 technology based on Internet Drafts as soon as they seem to be 115 stable. Thus, Internet Drafts have, in effect, replaced PS as the 116 first stage of the IETF standards process, PS has become the second 117 stage, and Draft Standard (DS) the hard-to-achieve third stage. 119 But there are significant problems with using Internet Drafts as 120 standards documents. Most importantly, Internet Drafts are not 121 stable, and their actual degree of instability varies widely. 122 Internet Drafts have short lifetimes with most of them being replaced 123 by new versions or expiring within a few months. If a vendor decides 124 to implement from an Internet Draft they have to be sure that they 125 are implementing the same version of the Internet Draft as other 126 vendors with whom they want to interoperate. Many examples show that 127 this is far from being the normal case. Also, of course, Internet 128 Drafts tend to have bugs and gaps by their very nature. 130 It is widely felt that, since the publication of [RFC2026], the IESG 131 has progressively raised the bar for the publication of Proposed 132 Standard documents. The current level of review, except for not 133 having a requirement for interoperable implementations, is close to 134 what is described for Draft Standard in [RFC2026]. Thus PS has, in 135 effect, replaced DS as the second stage in the IETF standards 136 process, with the first stage being an ill-defined choice of Internet 137 Draft. So few specifications are now advanced to final Internet 138 Standard status that this stage has been, in practice, removed. Few 139 specifications are promoted to the level requiring interoperability 140 (Draft Standard) and any revision of the IETF standards process 141 should try to correct that. 143 2. Measuring success 145 There is a notorious problem in measuring the success of 146 organizational change: those who make the measurements are usually 147 impatient, and do so years before the changes have percolated through 148 the entire organization and actually affected results. Nevertheless, 149 we would be wise to have an idea of what we are looking for as a 150 result of the change process. Some very loose ideas on what we might 151 wish to measure are: 153 * Increase the interoperability of implementations of new 154 protocols on the Internet (how to measure?) 155 * Shorten the time from "adopted idea" to "stable spec" for 156 protocols from 2 years to 1 year (?) 157 * Reduce the number of man-hours required to document 158 interoperability and formally acknowledge that it exists 159 (no idea of what to put in the "from" and "to" fields....) 160 * Increase motivation of IETF participants to advance their 161 work along the standards track, and increase the 162 attractiveness of the IETF as a standards venue 164 3. Some Proposals for New Standards Tracks 166 This section gives short summaries of a number of possible proposals 167 to resolve the above issues, by tuning or changing the standards 168 track process. The summaries are inevitably too short to capture all 169 details, so they certainly leave open issues. More suggestions are 170 welcome. The following section discusses pros and cons. 172 3.1 Clean up our act - make current system work better 174 In this proposal there would be no significant change to [RFC2026], 175 but specific efforts would be made to fix the ways in which it is not 176 working. Three examples of such efforts have been documented: 178 [VAD] proposes a mechanism for advancement of "Valuable Antique 179 Documents" - essentially a lightweight committee mechanism for 180 upgrading the status of tried and proven specifications, typically 181 those that have been at Proposed Standard for many years, without the 182 pain of bringing the documents up to current standards. 184 [MDH] proposes a similar lightweight mechanism for moving 185 specifications that are the opposite of tried and proven rapidly to 186 Historic status. 188 [RSD] proposes that the IESG act of designating a specification as an 189 Internet Standard be recorded by a separate document that would 190 receive the STD designation, with the actual specification being 191 referred to only as an RFC. Current Internet Standards carry both an 192 RFC number and an STD number. A separate document provides an 193 opportunity for "appropriate qualifying notes" that could include the 194 current state of known interoperability (see Section 4.2 195 Interoperability Register, although [SWS] proposes a dynamically 196 maintained register), cautions about the stability, applicability, 197 etc. of a specification and even editorial comments to guide such as 198 protocol and system designers (e.g., a warning that a mechanism like 199 NAT, although widely implemented and deployed, is nonetheless 200 considered to be a "bad idea" due to its impact on end-to-end aspects 201 of the Internet). 203 A separate STD document would also provide a useful way of collecting 204 related specifications that comprise a single standard; for example, 205 it is not a simple exercise to determine the set of specifications 206 that currently constitutes TCP. Once this separation of STD into a 207 separate document is performed, the resulting mechanism and its 208 benefits need not be restricted to Internet Standards; [RSD] proposes 209 applying it to all standards-track RFCs (Author's aside: it may be 210 wise to use a prefix other than STD in this case to avoid confusion 211 with current STD usage). Separate STD documents could be maintained 212 as living web documents that can be updated as changes occur instead 213 of or in addition to archival documents that can only be superseded 214 by publication of a new document. 216 No doubt other mechanisms (and ongoing operational changes outside 217 the scope of the newtrk WG) could also help the current system (and 218 see Section 4.4 for some specific suggestions that apply to any of 219 the possible standards track structures). 221 3.2 No More Mr. Nice Guy - make current system work strictly 223 This proposal would confirm the intention of [RFC2026] and implement 224 strict operational procedures to make it work. This would mean: 226 * reducing the strictness of IESG review for PS to a defined 227 minimum, 228 * enforcing the two year "dwell time" at PS by automatically 229 demoting PS documents to Historic if no interoperability 230 evidence is offered after two years or unless active work on a 231 revised specification is under way, and 232 * introducing a similar "dwell time" for DS to be considered for 233 Internet Standard status or die (back to PS for another two 234 years?). 236 The dwell time could be adjusted from its current value of two years. 238 3.3 Prune 240 The number of standards levels is pruned to two (we could call them 241 Draft Standard and Internet Standard). The threshold for DS would be 242 roughly what PS is today (stricter than PS in [RFC2026] but not 243 requiring proof of interoperability). The threshold for IS would be a 244 minimum period at DS, plus evidence of interoperability and 245 reasonable deployment experience. On the other hand, documents should 246 not be allowed to sit indefinitely at DS, so a dwell time would have 247 to be enforced. The two levels could also be called Proposed 248 Standard and Internet Standard. 250 An interoperability register (Section 4.2) would be created to track 251 the evidence of interoperability. 253 This could be combined with some form of Snapshot (Section 4.1) to 254 provide an initial level with better stability than an arbitrary 255 Internet-Draft. 257 Specific proposals can be found in Appendix 2 (with Snapshot) and 258 [TSS] (without Snapshot, but the [WGS] Snapshot proposal is intended 259 to be complementary to [TSS]). 261 3.4 Slash and Burn 263 The number of levels is reduced to one, called Internet Standard. 264 The threshold would be roughly the same as for Proposed Standard 265 today (roughly what is described in [RFC2026] for Draft Standard, but 266 *without* the interoperability requirement). 268 This could be combined with some form of Snapshot (Section 4.1) to 269 provide an initial level with better stability than an arbitrary 270 Internet-Draft. 272 3.5 Declare Victory 274 Instead of making changes, just revise [RFC2026] to document current 275 practice, including the observations from [RFC3774] (See Section 1). 276 The revised document would elevate the requirements for Proposed 277 Standard from those documented in [RFC2026] in addition to stating 278 that many important protocols never advance to Draft Standard and 279 that Internet Standard is rarely used. The current requirement for 280 review after a 2-year "dwell time" at a standards level would be 281 changed to a recommendation. 283 4. Common ideas 285 The ideas in this section can probably be combined with various of 286 the proposals above. 288 4.1 Snapshots 290 It seems inevitable that there will be a noticeable time lag from 291 when a working group believes that a specification is done until it 292 gets finally published, whatever changes are made to the standards 293 track. Mechanically, the processes of IETF Last Call, IESG review, 294 IANA action if needed, and RFC Editor action will take time, even if 295 no issues are found that need to be referred back to the WG. During 296 this wait, early implementers need to know which version of the 297 document to work from. Also, WGs may reach intermediate stages in 298 developing a complex specification when it is useful for all trial 299 implementations to be using the same version. For these two reasons, 300 a snapshot mechanism has been suggested, in at least two variants: 302 a) Working Group Snapshot. In this model WGs are authorized to 303 declare (by WG rough consensus, possibly including a Last Call) 304 that a particular draft is a WG Snapshot. No IESG or even Area 305 Director approval would be required - this would be a simple 306 statement to the world that the WG has declared a snapshot, along 307 with a statement of the purpose for which the snapshot was 308 declared. As far as implementers are concerned, 'caveat emptor' 309 applies. The only procedural issue is that an Internet Draft that 310 has been declared a WG Snapshot could get a life extension beyond 311 the normal six months, even if a later version number is 312 published. A specific proposal is in [WGS]. 314 b) IETF Stable Snapshot. Similar, but AD or IESG approval in some 315 form is required, entailing at least a WG Last Call on the draft 316 before it becomes a Snapshot. A lightweight cross-area technical 317 review (lighter than [RFC2026] intended even for PS) would be 318 made. A specific proposal envisaging an affirmative approval 319 mechanism is in Appendix 2. An "approve by default" process has 320 also been suggested in which specifications nominated for this 321 level by a WG would be approved in the absence of specific 322 technical objections during an IETF-wide Last Call. 324 There are a variety of options in the possible level (depth and 325 cross-area breadth) of technical review that could be part of 326 declaring a Snapshot; the required level could vary based on the 327 stated purpose of the snapshot. 329 When IETF Stable Snapshot is combined with mechanisms that eliminate 330 a standards level (e.g., Prune in Section 3.3, Slash and Burn in 331 Section 3.4), it is possible to use the name "Proposed Standard" for 332 IETF Stable Snapshot. 334 None of the current Snapshot proposals contain new measures for 335 retiring snapshots. It is unclear whether allowing Snapshots to 336 expire (as Internet Drafts do) is an effective impetus for 337 implementers to move on to a subsequent stable version (which may 338 contain significant technical improvements). Higher levels of 339 approval (e.g., IESG) for a Snapshot may make this more difficult to 340 accomplish. 342 4.2 Interoperability Register 344 In this idea, a separate "Interoperability and Deployment Register" 345 would be maintained by the IETF Secretariat. This would be a public 346 record of demonstrated interoperability and deployment experience. 347 Either the IESG, or better perhaps a special IETF Interoperability 348 Committee, would approve the publication of such a record. A 349 specification would get a gold star when it had such a public record. 350 Note that this idea of a registry is separable and could be used with 351 any of the proposals. [SWS] discusses this issue further. 353 4.3 Explicit Version Number 355 Recycling at the same standards level is an important and useful 356 aspect of the IETF standards process. Formalizing the notion of a 357 version number (essentially the number of times a specification has 358 been reissued as an RFC at the same level) could be a useful addition 359 to the process, as opposed to the current situation where version 360 numbers are left to the judgment of specification authors. 362 4.4 Better Process Documentation and Tracking 364 All documents (Internet Drafts, RFCs) get a formal system of tracking 365 issues, known implementations of individual features, known problems, 366 statements of determination of stability, etc. The 'stable snapshot' 367 state described in Section 4.1 would become just one of the kinds of 368 annotations that a working group can give to a document during its 369 development. 371 All documents must have a mailing list for discussion of the 372 document, with an archive of the mail on the mailing list. The 373 mailing archive should be enabled for advanced searching capability. 374 All RFCs and Internet Drafts (even old ones!) should include the URLs 375 of the web pages that give additional information about the document. 376 The STATUS OF THIS MEMO section should be updated to make the ways 377 the status can change be clearer. 379 This additional information should be in a standard format that 380 includes an issue list, errata, proposed changes, known 381 implementations, pointers to IPR statements. Implementation and 382 interoperability testing information should be added incrementally 383 such that the result will be adequate for an "implementation and 384 interoperability report", i.e., construction of these should start 385 much earlier, and include information such as implementation of 386 particular features, interoperability testing for individual 387 features, and statements about independent licensing of known IPR. 389 There should be a formal process for updating this information, with 390 clear responsibility and processes for adding to it and changing it, 391 and review process for objecting to changes that others deem 392 inappropriate. The current de facto process is that the WG mailing 393 list remains open, additions to the list are discussed on the list, 394 and the former WG chair, area director, document editor(s), or 395 person(s) appointed by any of those reviews additions before adding 396 them to the errata, although the fact that the RFC Editor maintains 397 errata for RFCs does not seem to be widely known. 399 5. Discussion of Pros and Cons 401 At this writing, there appears to be consensus in the WG that 402 regardless of the number of formal stages in the standards track, 403 there will be multiple reviews of specifications by the IESG - that 404 is to say, corrected or improved specifications will certainly be 405 produced, reviewed and approved regardless of exactly how they are 406 labeled. It is important to remember this consensus when considering 407 the following discussion. 409 Clean Up Our Act 410 + should eliminate dross and avoid pointless rewrites 411 - does nothing to simplify the process 413 No More Mr. Nice Guy 414 + reduces ambiguity and process black holes 415 - insensitive to social aspects, may demotivate 416 - does nothing to simplify the process 418 Prune 419 + reduces bureaucracy and terminology 421 Slash And Burn 422 + reduces bureaucracy more 424 Declare Victory 425 + avoids introducing confusion outside IETF about IETF standards 426 process and states 427 - ignores problem statement and does nothing to improve process 428 Snapshots 429 + avoid industry FUD and random implementation choices 430 - may end up as a class of de facto standards 432 Interoperability Register 433 + increase clarity about interoperability 434 - new work for the IETF, new committee 436 Better Process Documentation and Tracking 437 + central accessible place for important info 438 - additional work to get that info into a central accessible place 439 and maintain the result 441 6. Security Considerations 443 This document relates to IETF process, not any particular technology, 444 thus it raises no particular security concerns. We may note that 445 security requirements currently seem to be the source of the most 446 conflicts over whether a specification is "good enough", so we must 447 expect that a change in requirements criteria will in effect have a 448 security impact on the Internet. 450 7. Acknowledgements 452 Substantial text was taken directly from an earlier draft by Scott 453 Bradner. Ideas were lifted from mailing list discussions. Comments 454 and contributions were made by Grump, Lars-Erik Jonsson, John 455 Klensin, Larry Masinter, and other members of the newtrk WG. 457 8. Change log [RFC Editor to remove this section] 459 May 2004 - first version as draft-black-newtrk-proposals-00.txt 461 July 2004 - second version as draft-ietf-newtrk-proposals-00.txt 462 - added section on measuring success 463 - added section to separate out separable components 464 - added "clean up our act" section 465 - added idea for "approve by default" mechanism to IETF Stable 466 Snapshot 467 - added some discussion of use of WG Last Call for snapshots 468 - added possibility of using "Proposed Standard" for IETF Stable 469 Snapshot; edit Prune to allow DS name as lower standard level 470 - added "explicit version number" section 471 - added "better process documentation and tracking" section 472 - pros and cons section partly filled in 473 - minor editorial revisions 475 9. Appendix 1: Summary of Current IETF Standards Track 477 Section 4.1 [RFC2026] defines the stages on the IETF standards track 478 as follows: 480 4.1 Standards Track Maturity Levels 482 Internet specifications go through stages of development, testing, 483 and acceptance. Within the Internet Standards Process, these 484 stages are formally labeled "maturity levels". 486 This section describes the maturity levels and the expected 487 characteristics of specifications at each level. 489 4.1.1 Proposed Standard 491 The entry-level maturity for the standards track is "Proposed 492 Standard". A specific action by the IESG is required to move a 493 specification onto the standards track at the "Proposed Standard" 494 level. 496 A Proposed Standard specification is generally stable, has 497 resolved known design choices, is believed to be well-understood, 498 has received significant community review, and appears to enjoy 499 enough community interest to be considered valuable. However, 500 further experience might result in a change or even retraction of 501 the specification before it advances. 503 Usually, neither implementation nor operational experience is 504 required for the designation of a specification as a Proposed 505 Standard. However, such experience is highly desirable, and will 506 usually represent a strong argument in favor of a Proposed 507 Standard designation. 509 The IESG may require implementation and/or operational experience 510 prior to granting Proposed Standard status to a specification that 511 materially affects the core Internet protocols or that specifies 512 behavior that may have significant operational impact on the 513 Internet. 515 A Proposed Standard should have no known technical omissions with 516 respect to the requirements placed upon it. However, the IESG may 517 waive this requirement in order to allow a specification to 518 advance to the Proposed Standard state when it is considered to be 519 useful and necessary (and timely) even with known technical 520 omissions. 522 Implementors should treat Proposed Standards as immature 523 specifications. It is desirable to implement them in order to 524 gain experience and to validate, test, and clarify the 525 specification. However, since the content of Proposed Standards 526 may be changed if problems are found or better solutions are 527 identified, deploying implementations of such standards into a 528 disruption-sensitive environment is not recommended. 530 4.1.2 Draft Standard 532 A specification from which at least two independent and 533 interoperable implementations from different code bases have been 534 developed, and for which sufficient successful operational 535 experience has been obtained, may be elevated to the "Draft 536 Standard" level. For the purposes of this section 537 "interoperable" means to be functionally equivalent or 538 interchangeable components of the system or process in which they 539 are used. If patented or otherwise controlled technology is 540 required for implementation, the separate implementations must 541 also have resulted from separate exercise of the licensing 542 process. Elevation to Draft Standard is a major advance in 543 status, indicating a strong belief that the specification is 544 mature and will be useful. 546 The requirement for at least two independent and interoperable 547 implementations applies to all of the options and features of the 548 specification. In cases in which one or more options or features 549 have not been demonstrated in at least two interoperable 550 implementations, the specification may advance to the Draft 551 Standard level only if those options or features are removed. 553 The Working Group chair is responsible for documenting the 554 specific implementations which qualify the specification for Draft 555 or Internet Standard status along with documentation about testing 556 of the interoperation of these implementations. The documentation 557 must include information about the support of each of the 558 individual options and features. This documentation should be 559 submitted to the Area Director with the protocol action request. 561 A Draft Standard must be well-understood and known to be quite 562 stable, both in its semantics and as a basis for developing an 563 implementation. A Draft Standard may still require additional or 564 more widespread field experience, since it is possible for 565 implementations based on Draft Standard specifications to 566 demonstrate unforeseen behavior when subjected to large-scale use 567 in production environments. 569 A Draft Standard is normally considered to be a final 570 specification, and changes are likely to be made only to solve 571 specific problems encountered. In most circumstances, it is 572 reasonable for vendors to deploy implementations of Draft 573 Standards into a disruption sensitive environment. 575 4.1.3 Internet Standard 577 A specification for which significant implementation and 578 successful operational experience has been obtained may be 579 elevated to the Internet Standard level. An Internet Standard 580 (which may simply be referred to as a Standard) is characterized 581 by a high degree of technical maturity and by a generally held 582 belief that the specified protocol or service provides significant 583 benefit to the Internet community. 585 A specification that reaches the status of Standard is assigned a 586 number in the STD series while retaining its RFC number. 588 10. Appendix 2: Specific example of "Prune" 590 Scott Bradner originally proposed this alternate IETF standards track 591 with a new stage inserted before Proposed Standard, combining Draft 592 Standard and Internet Standard and retaining Proposed Standard as it 593 has evolved over the years. 595 Part of the problem we have been seeing with getting timely 596 publication of IETF specifications is that once people start 597 implementing the technology it often seems counterproductive to 598 dedicate effort to finishing off the documents. If implementations 599 of Internet Drafts achieve success in the marketplace, as they did 600 with MPLS, it may seem that it is not worth spending time tweaking 601 successive generations of Internet Drafts in order to get something 602 the IESG is willing to publish as a Proposed Standard then, if that 603 achieves widespread success in the market, fiddle with the document 604 again and do the bookkeeping needed to get it published as a Draft 605 Standard. The prerequisites for getting something published as an 606 Internet Standard seem to many people to be fuzzy at best. In 607 addition, the current standards track steps did not do much to 608 encourage early implementations, which are the best way to check to 609 see that a specification is clear enough for implementers to use. 610 This alternate set of stages tries to encourage vendors to implement 611 specifications and the comments with the descriptions of each stage 612 attempt to provide guidance for the IESG in implementing reviews for 613 each stage. 615 RFC 2026 would have to be revised in order to put any change of this 616 type into effect. That could be done by replacing RFC 2026 itself 617 with a whole new document or by writing a short document that updates 618 the standards track part of RFC 2026. 620 10.1 Alternate Standards Track Maturity Levels 622 Internet specifications go through stages of development, testing, 623 and acceptance. Within the Internet Standards Process, these stages 624 are formally labeled "maturity levels". 626 This section describes a set of alternate maturity levels and the 627 expected characteristics of specifications at each level. 629 10.2 Stable Snapshot 631 The entry-level maturity for the standards track is "Stable 632 Snapshot". A specific action by the IESG is required to move a 633 specification onto the standards track at the "Stable Snapshot" 634 level. 636 A Stable Snapshot specification is generally stable, has resolved 637 known design choices, is believed to be well-understood, has received 638 significant community review, and appears to enjoy enough community 639 interest to be considered valuable. However, further experience 640 might result in a change or even retraction of the specification 641 before it advances. 643 A Stable Snapshot should have no known technical omissions with 644 respect to the requirements placed upon it. Any such omissions must 645 be noted in the document. No such omission can endanger the security 646 or stability of the Internet or of networks where the technology 647 might be used. 649 Implementers should treat Stable Snapshots as immature, pre-standard, 650 specifications. It is desirable to implement them in order to gain 651 experience and to validate, test, and clarify the specification. 652 However, since the content of Stable Snapshots will be changed if 653 problems are found or better solutions are identified, and will be 654 changed as the technology is finalized, deploying implementations of 655 such technologies into a disruption-sensitive environment is not 656 recommended. 658 Commentary: 660 This stage is designed to institutionalize and encourage the 661 current practice of vendors implementing from Internet Drafts 662 while providing a way that a working group can indicate that 663 they feel that a technology is stable enough to be so implemented 664 and to provide a long-lived, unlike Internet Drafts, snapshot that 665 the vendors can implement. Having vendors implement technology is 666 an important quality check and meets the "running code" 667 requirement of our motto. We want to encourage implementations 668 whenever we can but this does need to be balanced with some level 669 of maturity and stability of the protocol. 671 This is almost the same definition as RFC 2026 has for Proposed 672 Standard. The major difference is that some of the technical 673 requirements might not have yet been met. This is OK as long as 674 any such holes in the specification are carefully noted in the 675 document, except that there needs to be a complete enough security 676 component so as to not endanger the networks where the technology 677 is to be used, and that the technology not endanger the wellbeing 678 of the network it will be run on. The exact guidelines for 679 the level of security required for a Stable Snapshot will evolve 680 over time. 682 In reviewing an Internet Draft for publication as a Stable 683 Snapshot the IESG only needs to be sure that the working group has 684 a reason to think that the technology is at a mature enough level 685 that implementers can start to play with it and that the minimum 686 security and 'health of the net' requirements have been met. The 687 IESG should not try to ensure that the text is clear and 688 unambiguous, the vendors will find that out while implementing and 689 provide feedback to the working group. The IESG should not do a 690 careful technology review as a precondition for publication as a 691 Stable Snapshot. This process should be lightweight, not taking 692 too much time on the part of the IESG or effort on the part of the 693 working group and authors. 695 The name, "Stable Snapshot" was chosen to clearly indicate that 696 this is a pre-standard stage and to ensure that marketing people 697 cannot easily misrepresent the status but there may be a better 698 name that accomplishes the same goals. 700 10.3 Proposed Standard 702 A Proposed Standard specification is generally stable, has resolved 703 known design choices, is believed to be well-understood, has received 704 significant community review, and appears to enjoy enough community 705 interest to be considered valuable. 707 Usually, neither implementation nor operational experience is 708 required for the designation of a specification as a Proposed 709 Standard. However, such experience is highly desirable, and will 710 usually represent a strong argument in favor of a Proposed Standard 711 designation. 713 Generally some documented level of implementation and/or operational 714 experience is required prior to granting Proposed Standard status. 715 However, the IESG may waive this requirement in order to allow a 716 specification to advance to the Proposed Standard state when it is 717 considered to be useful and necessary (and timely) even without any 718 known implementations. 720 A Proposed Standard should have no known technical omissions with 721 respect to the requirements placed upon it. 723 Implementers should treat Proposed Standards as stable, but perhaps 724 not final, specifications. A Proposed Standard must be well- 725 understood and known to be quite stable, both in its semantics and as 726 a basis for developing an implementation. A Proposed Standard may 727 still require additional or more widespread field experience, since 728 it is possible for implementations based on Proposed Standard 729 specifications to demonstrate unforeseen behavior when subjected to 730 large-scale use in production environments. 732 Commentary: 734 The requirements for publication as a Proposed Standard are mostly 735 the same as currently in RFC 2026 for Proposed Standard with the 736 addition of a requirement for at least some implementation 737 experience. 739 The IESG review for Proposed Standard could stay just like it is. 740 The IESG should do the same careful technical review and a review 741 to ensure that the language of the document is clear and precise 742 as it has been doing for quite a while. 744 Because most specifications for which publication as a Proposed 745 Standard is requested will have been implemented I would expect 746 that the IESG review will generally take less effort since the 747 implementers experience will have uncovered unclear language and 748 some or all technical issues, at least for the parts of the 749 specification that had been implemented. 751 There should be some documentation to show that there has been at 752 least one implementation of a specification before the IESG 753 authorizes the publication of the specification as a Proposed 754 Standard. But the documentation does not need to be so detailed 755 that it shows which individual options have been implemented. A 756 list of the names of people or companies who have said they had 757 implemented the specification should be sufficient. 759 Before adoption of a new description of Proposed Standard the IPR- 760 related aspects should be revisited in list of the work in the IPR 761 working group but that is not done here. 763 10.4 Internet Standard 765 A specification from which at least two independent and interoperable 766 implementations from different code bases have been developed, and 767 for which sufficient successful operational experience has been 768 obtained, may be elevated to the "Internet Standard" level. For the 769 purposes of this section, "interoperable" means to be functionally 770 equivalent or interchangeable components of the system or process in 771 which they are used. If patented or otherwise controlled technology 772 is required for implementation, the separate implementations must 773 also have resulted from separate exercise of the licensing process. 774 Elevation to Internet Standard is a major advance in status, 775 indicating a strong belief that the specification is mature and will 776 be useful. 778 The requirement for at least two independent and interoperable 779 implementations applies to all of the options and features of the 780 specification. In cases in which one or more options or features 781 have not been demonstrated in at least two interoperable 782 implementations, the specification may advance to the Internet 783 Standard level only if those options or features are removed. 785 The Working Group chair is responsible for documenting the specific 786 implementations which qualify the specification for Draft or Internet 787 Standard status along with documentation about testing of the 788 interoperation of these implementations. The documentation must 789 include information about the support of each of the individual 790 options and features. This documentation should be submitted to the 791 Area Director with the protocol action request. 793 A Internet Standard (which may simply be referred to as a Standard) 794 must be well-understood and known to be stable, both in its semantics 795 and as a basis for developing an implementation. An Internet 796 Standard is characterized by a high degree of technical maturity and 797 by a generally held belief that the specified protocol or service 798 provides significant benefit to the Internet community. 800 An Internet Standard is considered to be a final specification, and 801 changes should only be made to solve specific problems encountered. 803 Commentary: 805 The description here is a combination of the descriptions of Draft 806 Standard and Internet Standard in RFC 2026. 808 One issue we have had over the years is just what does a working 809 group chair have to do to show multiple implementations of the 810 base specification and all of the features. I have always felt 811 that a simple spread sheet showing each feature, how many vendors 812 claim to have the feature, and a checkbox to indicate that two or 813 more vendors claim that they have tested implementations of the 814 feature, would be just fine. But this turns out to be quite 815 complex in some cases (see the Implementer's report for http 1.1 816 as an example). It is not cleare if this turns out to be actually 817 too much of an effort or just seems like too much of an effort. 818 It still seems like about the right thing but the barrier to 819 reach Internet Standard should be just as high as it needs to be 820 but no higher. 822 Since, in reality, there was little difference between the 823 requirements in RFC 2026 for Draft Standard and Internet Standard, 824 mostly a need to show market acceptance in some way, there seems 825 to be no technical reason to preserve the different labels. 827 10.5 Minimum time in each stage. 829 It seems that there needs to be a minimum time that a document must 830 sit at a stage before it can move onward (as is the case in RFC 2026) 831 just to be sure that any problems are uncovered. 833 It is unclear how to figure out the ideal time so it is suggested 834 that 6 months would be enough (as long as the rest of the 835 requirements for the next level have been met). 837 11. Informative References 839 [MDH] Alvestrand, H. and E. Lear, "Moving documents to Historic: A 840 procedure", draft-alvestrand-newtrk-historical-00 (work in 841 progress) 843 [RFC2026] Bradner, S. Ed., "The Internet Standards Process -- 844 Revision 3," October 1996, RFC 2026 846 [RFC3774] Davies, E. Ed., "IETF Problem Statement," May 2004, 847 RFC 3774 849 [TSS] Dawkins, S., et. al., "Two Stage Standardization," work in 850 progress, draft-dawkins-pstmt-twostage-02.txt 852 [WGS] Dawkins, S., et al, "Working Group Snapshot (WGS)," work in 853 progress, draft-dawkins-newtrk-wgs-00.txt 855 [VAD] Klensin, J., "Valuable Antique Documents: A Model for 856 Advancement", draft-klensin-newtrk-antiques-00.txt (work in 857 progress) 859 [RSD] Klensin, J., "Repurposing the STD Designation", draftdraft 860 klensin-newtrk-std-repurposing-00.txt (work in progress) 862 [SWS] Loughney, J., "Standards, What Standards?", draft-loughney 863 what-standards-01.txt, (work in progress) 865 12. Authors' Addresses 867 David L. Black 868 EMC Corporation 869 176 South Street 870 Hopkinton, MA 01748 871 Email: black_david@emc.com 873 Brian E. Carpenter 874 IBM Zurich Research Laboratory 875 Saeumerstrasse 4 / Postfach 876 8803 Rueschlikon 877 Switzerland 878 Email: brc@zurich.ibm.com 880 Intellectual Property Statement 882 The IETF takes no position regarding the validity or scope of any 883 Intellectual Property Rights or other rights that might be claimed to 884 pertain to the implementation or use of the technology described in 885 this document or the extent to which any license under such rights 886 might or might not be available; nor does it represent that it has 887 made any independent effort to identify any such rights. Information 888 on the IETF's procedures with respect to rights in IETF Documents can 889 be found in BCP 78 and BCP 79. 891 Copies of IPR disclosures made to the IETF Secretariat and any 892 assurances of licenses to be made available, or the result of an 893 attempt made to obtain a general license or permission for the use of 894 such proprietary rights by implementers or users of this 895 specification can be obtained from the IETF on-line IPR repository at 896 http://www.ietf.org/ipr. 898 The IETF invites any interested party to bring to its attention any 899 copyrights, patents or patent applications, or other proprietary 900 rights that may cover technology that may be required to implement 901 this standard. Please address the information to the IETF at 902 ietf-ipr@ietf.org. 904 Disclaimer of Validity 906 This document and the information contained herein are provided on an 907 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 908 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 909 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 910 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 911 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 912 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 914 Copyright Statement 916 Copyright (C) The Internet Society (2004). This document is subject 917 to the rights, licenses and restrictions contained in BCP 78, and 918 except as set forth therein, the authors retain all their rights. 920 Acknowledgment 922 Funding for the RFC Editor function is currently provided by the 923 Internet Society.