idnits 2.17.1 draft-black-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 3667, Section 5.1 on line 15. -- Found old boilerplate from RFC 3978, Section 5.5 on line 677. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 661. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 667. ** 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, I certify that any applicable patent or other IPR claims of which I am aware have been disclosed, or will be disclosed, and any of which I become aware will be disclosed, in accordance with RFC 3668. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- == No 'Intended status' indicated for this document; assuming Proposed Standard == The page length should not exceed 58 lines per page, but there was 1 longer page, the longest (page 1) being 705 lines 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.) ** There is 1 instance of too long lines in the document, the longest one being 1 character in excess of 72. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year == Line 449 has weird spacing: '... of the pro...' -- 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 (May 2004) is 7285 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) No issues found here. Summary: 8 errors (**), 0 flaws (~~), 4 warnings (==), 6 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 Network Working Group 2 Internet Draft D. Black 3 Document: draft-black-newtrk-proposals-00.txt EMC Corporation 4 Expires: November 2004 B. Carpenter 5 IBM 6 May 2004 8 Proposals for a New IETF Standards Track 10 Status of this Memo 12 By submitting this Internet-Draft, I certify that any applicable 13 patent or other IPR claims of which I am aware have been disclosed, 14 and any of which I become aware will be disclosed, in accordance with 15 RFC 3668. 17 Internet-Drafts are working documents of the Internet Engineering 18 Task Force (IETF), its areas, and its working groups. Note that 19 other groups may also distribute working documents as Internet- 20 Drafts. 22 Internet-Drafts are draft documents valid for a maximum of six months 23 and may be updated, replaced, or obsoleted by other documents at any 24 time. It is inappropriate to use Internet-Drafts as reference 25 material or to cite them other than as "work in progress." 27 The list of current Internet-Drafts can be accessed at 28 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 Abstract 34 Discussions in the IETF's "problem" working group reached consensus 35 that the current IETF 3-stage standards track, as implemented, is not 36 working. This draft proposes various alternative multi-step 37 standards tracks for debate in the "newtrk" working group. 39 Table of Contents 41 1. Introduction 2 42 2. Some Proposals for New Standards Tracks 3 43 2.1 No More Mr. Nice Guy - make the current system work 3 44 2.2 Prune 4 45 2.3 Slash and Burn 4 46 2.4 Placeholder for another idea... 5 47 2.5 Snapshot 5 48 3. Discussion of Pros and Cons 5 49 4. Security Considerations 5 50 5. Acknowledgements 5 51 6. Appendix 1: Summary of Current IETF Standards Track 5 52 7. Appendix 2: Specific example of "Prune" 8 53 7.1 Alternate Standards Track Maturity Levels 9 54 7.2 Stable Snapshot 9 55 7.3 Proposed Standard 10 56 7.4 Internet Standard 12 57 7.5 Minimum time in each stage. 13 58 8. Informative References 13 59 9. Authors' Addresses 13 61 1. Introduction 63 By way of preamble, note that this is a discussion document and not a 64 firm or fully worked out proposal. Once the "newtrk" working group 65 reaches consensus on the general direction to follow, this document 66 will have served its purpose and a revision or update of [RFC2026] 67 will be needed. 69 The consensus in the "problem" working group was that the current 70 IETF three stage standards track, described in RFC 2026 [RFC2026] and 71 summarized below in Appendix 1, is not working as originally 72 intended. The problem statement document [RFC3774] says: 74 The current hierarchy of Proposed, Draft, and Full Standard 75 maturity levels for specifications is no longer being used in the 76 way that was envisioned when the stratification was originally 77 proposed. In practice, the IETF currently has a one-step 78 standards process that subverts the IETF's preference for 79 demonstrating effectiveness through running code in multiple 80 interoperable implementations. This compresses the process that 81 previously allowed specifications to mature as experience was 82 gained with actual implementations: 84 The document then goes on to list various observations including: 86 1/ Few documents actually progress after being published as 87 Proposed Standard (PS). 89 2/ There is a perception that the IESG raised the quality 90 requirement for approval as PS beyond the intention of 91 [RFC2026]. 93 3/ In spite of the raised quality requirement, running code is not 94 required to achieve PS status. 96 4/ There seems to be a reinforcing feedback loop involved: vendors 97 implement and deploy PS specifications, so increasingly the 98 IESG tries to make the PS documents better. 100 [RFC3774] concludes that the three-stage process is excessive. 102 An alternative interpretation of these observations is that a three- 103 step standards process still operates, but the existing standards 104 levels have been shifted upwards so that PS is no longer the initial 105 step. Vendors will often implement, and their customers deploy, 106 technology based on Internet Drafts as soon as they seem to be 107 stable. Thus, Internet Drafts have, in effect, replaced PS as the 108 first stage of the IETF standards process, PS has become the second 109 stage, and Draft Standard (DS) the hard-to-achieve third stage. 111 But there are significant problems with using Internet Drafts as 112 standards documents. Most importantly, Internet Drafts are not 113 stable, and their actual degree of instability varies widely. 114 Internet Drafts have short lifetimes with most of them being replaced 115 by new versions or expiring within a few months. If a vendor decides 116 to implement from an Internet Draft they have to be sure that they 117 are implementing the same version of the Internet Draft as other 118 vendors with whom they want to interoperate. Many examples show that 119 this is far from being the normal case. Also, of course, Internet 120 Drafts tend to have bugs and gaps by their very nature. 122 Objectively, over time, the IESG has raised the bar for the 123 publication of Proposed Standard documents. The current level of 124 review, except for not having a requirement for interoperable 125 implementations, is close to what is described for Draft Standard in 126 [RFC2026]. Thus PS has, in effect, replaced DS as the second stage in 127 the IETF standards process, with the first stage being an ill-defined 128 choice of Internet Draft. So few specifications are now advanced to 129 final Internet Standard status that this stage has been, in practice, 130 removed. Few specifications are promoted to the level requiring 131 interoperability (Draft Standard) and any revision of the IETF 132 standards process should try to correct that. 134 2. Some Proposals for New Standards Tracks 136 This section gives a short summary of a number of possible proposals 137 to resolve the above issues by tuning or changing the standards track 138 process. More suggestions are welcome. The following section 139 discusses pros and cons. 141 2.1 No More Mr. Nice Guy - make the current system work 143 This proposal would confirm the intention of [RFC2026] and implement 144 strict operational procedures to make it work. This would mean: 146 * reducing the strictness of IESG review for PS to a defined 147 minimum, 148 * enforcing the two year "dwell time" at PS by automatically 149 demoting PS documents to Historic if no interoperability 150 evidence is offered after two years or unless active work on a 151 revised specification is under way, and 152 * introducing a similar "dwell time" for DS to be considered for 153 Internet Standard status or die (back to PS for another two 154 years?). 156 The dwell time could be adjusted from its current value of two years. 158 2.2 Prune 160 The number of standards levels is pruned to two (we could call them 161 Proposed Standard and Internet Standard). The threshold for PS would 162 be roughly as today (stricter than in [RFC2026] but not requiring 163 proof of interoperability). The threshold for IS would be a minimum 164 period at PS, plus evidence of interoperability and reasonable 165 deployment experience. 167 This could be combined with some form of Snapshot (Section 2.5) to 168 provide an initial level with better stability than an arbitrary 169 Internet-Draft. 171 Specific proposals can be found in Appendix 2 (with Snapshot) and 172 [TSS] (without Snapshot, but the [WGS] Snapshot proposal is intended 173 to be complementary to [TSS]). 175 2.3 Slash and Burn 177 The number of levels is reduced to one, called Internet Standard. 178 The threshold would be roughly the same as for Proposed Standard 179 today (roughly what is described in [RFC2026] for Draft Standard, but 180 *without* the interoperability requirement). 182 In addition, a separate "Interoperability and Deployment Register" 183 would be maintained by the IETF Secretariat. This would be a public 184 record of demonstrated interoperability and deployment experience. 185 Either the IESG, or better perhaps a special IETF Interoperability 186 Committee, would approve the publication of such a record. An 187 Internet Standard would get a gold star when it had such a public 188 record. 190 This could be combined with some form of Snapshot (Section 2.5) to 191 provide an initial level with better stability than an arbitrary 192 Internet-Draft. 194 2.4 Placeholder for another idea ... 196 2.5 Snapshot 198 It seems inevitable that there will be a noticeable time lag from 199 when a working group believes that a specification is done until it 200 gets finally published, whatever changes are made to the standards 201 track. Mechanically, the processes of IETF Last Call, IESG review, 202 IANA action if needed, and RFC Editor action will take time, even if 203 no issues are found that need to be referred back to the WG. During 204 this wait, early implementers need to know which version of the 205 document to work from. Also, WGs may reach intermediate stages in 206 developing a complex specification when it is useful for all trial 207 implementations to be using the same version. For these two reasons, 208 a snapshot mechanism has been suggested, in at least two variants: 210 a) Working Group Snapshot. In this model WGs are authorized to 211 declare (by WG rough consensus) that a particular draft is a WG 212 Snapshot. No IESG or even Area Director approval would be 213 required - this would be a simple statement to the world that the 214 WG has declared a snapshot, along with a statement of the purpose 215 for which the snapshot was declared. As far as implementers are 216 concerned, 'caveat emptor' applies. The only procedural issue is 217 that an Internet Draft that has been declared a WG Snapshot could 218 get a life extension beyond the normal six months, even if a later 219 version number is published. A specific proposal is in [WGS]. 221 b) IETF Stable Snapshot. Similar, but AD or IESG approval is 222 required. A lightweight cross-area technical review (lighter 223 than [RFC2026] intended even for PS) would be made. A specific 224 proposal is in Appendix 2. 226 There are a variety of options in the possible level (depth and cross- 227 area breadth) of technical review that could be part of declaring a 228 Snapshot; the required level could vary based on the stated purpose 229 of the snapshot. 231 None of the current Snapshot proposals contain new measures for 232 retiring snapshots. It is unclear whether allowing Snapshots to 233 expire (as Internet Drafts do) is an effective impetus for 234 implementers to move on to a subsequent stable version (which may 235 contain significant technical improvements). Higher levels of 236 approval (e.g., IESG) for a Snapshot may make this more difficult to 237 accomplish. 239 3. Discussion of Pros and Cons 241 This section will be filled in after initial discussion on the 242 working group mailing list. 244 4. Security Considerations 246 This document relates to IETF process, not any particular technology, 247 thus it raises no particular security concerns. 249 5. Acknowledgements 251 Substantial text was taken directly from an earlier draft by Scott 252 Bradner. Ideas were lifted from mailing list discussions. Comments 253 and contributions were made by . 255 6. Appendix 1: Summary of Current IETF Standards Track 257 Section 4.1 [RFC2026] defines the stages on the IETF standards track 258 as follows: 260 4.1 Standards Track Maturity Levels 262 Internet specifications go through stages of development, testing, 263 and acceptance. Within the Internet Standards Process, these 264 stages are formally labeled "maturity levels". 266 This section describes the maturity levels and the expected 267 characteristics of specifications at each level. 269 4.1.1 Proposed Standard 271 The entry-level maturity for the standards track is "Proposed 272 Standard". A specific action by the IESG is required to move a 273 specification onto the standards track at the "Proposed Standard" 274 level. 276 A Proposed Standard specification is generally stable, has 277 resolved known design choices, is believed to be well-understood, 278 has received significant community review, and appears to enjoy 279 enough community interest to be considered valuable. However, 280 further experience might result in a change or even retraction of 281 the specification before it advances. 283 Usually, neither implementation nor operational experience is 284 required for the designation of a specification as a Proposed 285 Standard. However, such experience is highly desirable, and will 286 usually represent a strong argument in favor of a Proposed 287 Standard designation. 289 The IESG may require implementation and/or operational experience 290 prior to granting Proposed Standard status to a specification that 291 materially affects the core Internet protocols or that specifies 292 behavior that may have significant operational impact on the 293 Internet. 295 A Proposed Standard should have no known technical omissions with 296 respect to the requirements placed upon it. However, the IESG may 297 waive this requirement in order to allow a specification to 298 advance to the Proposed Standard state when it is considered to be 299 useful and necessary (and timely) even with known technical 300 omissions. 302 Implementors should treat Proposed Standards as immature 303 specifications. It is desirable to implement them in order to 304 gain experience and to validate, test, and clarify the 305 specification. However, since the content of Proposed Standards 306 may be changed if problems are found or better solutions are 307 identified, deploying implementations of such standards into a 308 disruption-sensitive environment is not recommended. 310 4.1.2 Draft Standard 312 A specification from which at least two independent and 313 interoperable implementations from different code bases have been 314 developed, and for which sufficient successful operational 315 experience has been obtained, may be elevated to the "Draft 316 Standard" level. For the purposes of this section 317 "interoperable" means to be functionally equivalent or 318 interchangeable components of the system or process in which they 319 are used. If patented or otherwise controlled technology is 320 required for implementation, the separate implementations must 321 also have resulted from separate exercise of the licensing 322 process. Elevation to Draft Standard is a major advance in 323 status, indicating a strong belief that the specification is 324 mature and will be useful. 326 The requirement for at least two independent and interoperable 327 implementations applies to all of the options and features of the 328 specification. In cases in which one or more options or features 329 have not been demonstrated in at least two interoperable 330 implementations, the specification may advance to the Draft 331 Standard level only if those options or features are removed. 333 The Working Group chair is responsible for documenting the 334 specific implementations which qualify the specification for Draft 335 or Internet Standard status along with documentation about testing 336 of the interoperation of these implementations. The documentation 337 must include information about the support of each of the 338 individual options and features. This documentation should be 339 submitted to the Area Director with the protocol action request. 341 A Draft Standard must be well-understood and known to be quite 342 stable, both in its semantics and as a basis for developing an 343 implementation. A Draft Standard may still require additional or 344 more widespread field experience, since it is possible for 345 implementations based on Draft Standard specifications to 346 demonstrate unforeseen behavior when subjected to large-scale use 347 in production environments. 349 A Draft Standard is normally considered to be a final 350 specification, and changes are likely to be made only to solve 351 specific problems encountered. In most circumstances, it is 352 reasonable for vendors to deploy implementations of Draft 353 Standards into a disruption sensitive environment. 355 4.1.3 Internet Standard 357 A specification for which significant implementation and 358 successful operational experience has been obtained may be 359 elevated to the Internet Standard level. An Internet Standard 360 (which may simply be referred to as a Standard) is characterized 361 by a high degree of technical maturity and by a generally held 362 belief that the specified protocol or service provides significant 363 benefit to the Internet community. 365 A specification that reaches the status of Standard is assigned a 366 number in the STD series while retaining its RFC number. 368 7. Appendix 2: Specific example of "Prune" 370 Scott Bradner originally proposed this alternate IETF standards track 371 with a new stage inserted before Proposed Standard, combining Draft 372 Standard and Internet Standard and retaining Proposed Standard as it 373 has evolved over the years. 375 Part of the problem we have been seeing with getting timely 376 publication of IETF specifications is that once people start 377 implementing the technology it often seems counterproductive to 378 dedicate effort to finishing off the documents. If implementations 379 of Internet Drafts achieve success in the marketplace, as they did 380 with MPLS, it may seem that it is not worth spending time tweaking 381 successive generations of Internet Drafts in order to get something 382 the IESG is willing to publish as a Proposed Standard then, if that 383 achieves widespread success in the market, fiddle with the document 384 again and do the bookkeeping needed to get it published as a Draft 385 Standard. The prerequisites for getting something published as an 386 Internet Standard seem to many people to be fuzzy at best. In 387 addition, the current standards track steps did not do much to 388 encourage early implementations, which are the best way to check to 389 see that a specification is clear enough for implementers to use. 390 This alternate set of stages tries to encourage vendors to implement 391 specifications and the comments with the descriptions of each stage 392 attempt to provide guidance for the IESG in implementing reviews for 393 each stage. 395 RFC 2026 would have to be revised in order to put any change of this 396 type into effect. That could be done by replacing RFC 2026 itself 397 with a whole new document or by writing a short document that updates 398 the standards track part of RFC 2026. 400 7.1 Alternate Standards Track Maturity Levels 402 Internet specifications go through stages of development, testing, 403 and acceptance. Within the Internet Standards Process, these stages 404 are formally labeled "maturity levels". 406 This section describes a set of alternate maturity levels and the 407 expected characteristics of specifications at each level. 409 7.2 Stable Snapshot 411 The entry-level maturity for the standards track is "Stable 412 Snapshot". A specific action by the IESG is required to move a 413 specification onto the standards track at the "Stable Snapshot" 414 level. 416 A Stable Snapshot specification is generally stable, has resolved 417 known design choices, is believed to be well-understood, has received 418 significant community review, and appears to enjoy enough community 419 interest to be considered valuable. However, further experience 420 might result in a change or even retraction of the specification 421 before it advances. 423 A Stable Snapshot should have no unknown technical omissions with 424 respect to the requirements placed upon it. Any such omissions must 425 be noted in the document. No such omission can endanger the security 426 or stability of the Internet or of networks where the technology 427 might be used. 429 Implementers should treat Stable Snapshots as immature, pre-standard, 430 specifications. It is desirable to implement them in order to gain 431 experience and to validate, test, and clarify the specification. 432 However, since the content of Stable Snapshots will be changed if 433 problems are found or better solutions are identified, and will be 434 changed as the technology is finalized, deploying implementations of 435 such technologies into a disruption-sensitive environment is not 436 recommended. 438 Commentary: 440 This stage is designed to institutionalize and encourage the 441 current practice of vendors implementing from Internet Drafts 442 while providing a way that a working group can indicate that 443 they feel that a technology is stable enough to be so implemented 444 and to provide a long-lived, unlike Internet Drafts, snapshot that 445 the vendors can implement. Having vendors implement technology is 446 an important quality check and meets the "running code" 447 requirement of our motto. We want to encourage implementations 448 whenever we can but this does need to be balanced with some level 449 of maturity and stability of the protocol. 451 This is almost the same definition as RFC 2026 has for Proposed 452 Standard. The major difference is that some of the technical 453 requirements might not have yet been met. This is OK as long as 454 any such holes in the specification are carefully noted in the 455 document, except that there needs to be a complete enough security 456 component so as to not endanger the networks where the technology 457 is to be used, and that the technology not endanger the wellbeing 458 of the network it will be run on. The exact guidelines for 459 the level of security required for a Stable Snapshot will evolve 460 over time. 462 In reviewing an Internet Draft for publication as a Stable 463 Snapshot the IESG only needs to be sure that the working group has 464 a reason to think that the technology is at a mature enough level 465 that implementers can start to play with it and that the minimum 466 security and 'health of the net' requirements have been met. The 467 IESG should not try to ensure that the text is clear and 468 unambiguous, the vendors will find that out while implementing and 469 provide feedback to the working group. The IESG should not do a 470 careful technology review as a precondition for publication as a 471 Stable Snapshot. This process should be lightweight, not taking 472 too much time on the part of the IESG or effort on the part of the 473 working group and authors. 475 The name, "Stable Snapshot" was chosen to clearly indicate that 476 this is a pre-standard stage and to ensure that marketing people 477 cannot easily misrepresent the status but there may be a better 478 name that accomplishes the same goals. 480 7.3 Proposed Standard 482 A Proposed Standard specification is generally stable, has resolved 483 known design choices, is believed to be well-understood, has received 484 significant community review, and appears to enjoy enough community 485 interest to be considered valuable. 487 Usually, neither implementation nor operational experience is 488 required for the designation of a specification as a Proposed 489 Standard. However, such experience is highly desirable, and will 490 usually represent a strong argument in favor of a Proposed Standard 491 designation. 493 Generally some documented level of implementation and/or operational 494 experience is required prior to granting Proposed Standard status. 495 However, the IESG may waive this requirement in order to allow a 496 specification to advance to the Proposed Standard state when it is 497 considered to be useful and necessary (and timely) even without any 498 known implementations. 500 A Proposed Standard should have no known technical omissions with 501 respect to the requirements placed upon it. 503 Implementers should treat Proposed Standards as stable, but perhaps 504 not final, specifications. A Proposed Standard must be well- 505 understood and known to be quite stable, both in its semantics and as 506 a basis for developing an implementation. A Proposed Standard may 507 still require additional or more widespread field experience, since 508 it is possible for implementations based on Proposed Standard 509 specifications to demonstrate unforeseen behavior when subjected to 510 large-scale use in production environments. 512 Commentary: 514 The requirements for publication as a Proposed Standard are mostly 515 the same as currently in RFC 2026 for Proposed Standard with the 516 addition of a requirement for at least some implementation 517 experience. 519 The IESG review for Proposed Standard could stay just like it is. 520 The IESG should do the same careful technical review and a review 521 to ensure that the language of the document is clear and precise 522 as it has been doing for quite a while. 524 Because most specifications for which publication as a Proposed 525 Standard is requested will have been implemented I would expect 526 that the IESG review will generally take less effort since the 527 implementers experience will have uncovered unclear language and 528 some or all technical issues, at least for the parts of the 529 specification that had been implemented. 531 There should be some documentation to show that there has been at 532 least one implementation of a specification before the IESG 533 authorizes the publication of the specification as a Proposed 534 Standard. But the documentation does not need to be so detailed 535 that it shows which individual options have been implemented. A 536 list of the names of people or companies who have said they had 537 implemented the specification should be sufficient. 539 Before adoption of a new description of Proposed Standard the IPR- 540 related aspects should be revisited in list of the work in the IPR 541 working group but I have not done that here. 543 7.4 Internet Standard 545 A specification from which at least two independent and interoperable 546 implementations from different code bases have been developed, and 547 for which sufficient successful operational experience has been 548 obtained, may be elevated to the "Internet Standard" level. For the 549 purposes of this section, "interoperable" means to be functionally 550 equivalent or interchangeable components of the system or process in 551 which they are used. If patented or otherwise controlled technology 552 is required for implementation, the separate implementations must 553 also have resulted from separate exercise of the licensing process. 554 Elevation to Internet Standard is a major advance in status, 555 indicating a strong belief that the specification is mature and will 556 be useful. 558 The requirement for at least two independent and interoperable 559 implementations applies to all of the options and features of the 560 specification. In cases in which one or more options or features 561 have not been demonstrated in at least two interoperable 562 implementations, the specification may advance to the Internet 563 Standard level only if those options or features are removed. 565 The Working Group chair is responsible for documenting the specific 566 implementations which qualify the specification for Draft or Internet 567 Standard status along with documentation about testing of the 568 interoperation of these implementations. The documentation must 569 include information about the support of each of the individual 570 options and features. This documentation should be submitted to the 571 Area Director with the protocol action request. 573 A Internet Standard (which may simply be referred to as a Standard) 574 must be well-understood and known to be stable, both in its semantics 575 and as a basis for developing an implementation. An Internet 576 Standard is characterized by a high degree of technical maturity and 577 by a generally held belief that the specified protocol or service 578 provides significant benefit to the Internet community. 580 An Internet Standard is considered to be a final specification, and 581 changes should only be made to solve specific problems encountered. 583 Commentary: 585 The description here is a combination of the descriptions of Draft 586 Standard and Internet Standard in RFC 2026. 588 One issue we have had over the years is just what does a working 589 group chair have to do to show multiple implementations of the 590 base specification and all of the features. I have always felt 591 that a simple spread sheet showing each feature, how many vendors 592 claim to have the feature, and a checkbox to indicate that two or 593 more vendors claim that they have tested implementations of the 594 feature, would be just fine. But this turns out to be quite 595 complex in some cases (see the Implementer's report for http 1.1 596 as an example). It is not cleare if this turns out to be actually 597 too much of an effort or just seems like too much of an effort. 598 It still seems like about the right thing but the barrier to 599 reach Internet Standard should be just as high as it needs to be 600 but no higher. 602 Since, in reality, there was little difference between the 603 requirements in RFC 2026 for Draft Standard and Internet Standard, 604 mostly a need to show market acceptance in some way, there seems 605 to be no technical reason to preserve the different labels. 607 7.5 Minimum time in each stage. 609 It seems that there needs to be a minimum time that a document must 610 sit at a stage before it can move onward (as is the case in RFC 2026) 611 just to be sure that any problems are uncovered. 613 It is unclear how to figure out the ideal time so it is suggested 614 that 6 months would be enough (as long as the rest of the 615 requirements for the next level have been met). 617 8. Informative References 619 [RFC2026] Bradner, S. Ed., "The Internet Standards Process -- 620 Revision 3," October 1996, RFC 2026 622 [RFC3774] Davies, E. Ed., "IETF Problem Statement," May 2004, 623 RFC 3774 625 [TSS] Dawkins, S., et. al., "Two Stage Standardization," work in 626 progress, draft-dawkins-pstmt-twostage-02.txt 628 [WGS] Dawkins, S., et al, "Working Group Snapshot (WGS)," work in 629 progress, draft-dawkins-newtrk-wgs-00.txt 631 9. Authors' Addresses 633 David Black 634 EMC Corporation 635 176 South Street 636 Hopkinton, MA 01748 637 Email: black_david@emc.com 639 Brian E. Carpenter 640 IBM Zurich Research Laboratory 641 Saeumerstrasse 4 / Postfach 642 8803 Rueschlikon 643 Switzerland 644 Email: brc@zurich.ibm.com 645 Intellectual Property Statement 647 The IETF takes no position regarding the validity or scope of any 648 Intellectual Property Rights or other rights that might be claimed to 649 pertain to the implementation or use of the technology described in 650 this document or the extent to which any license under such rights 651 might or might not be available; nor does it represent that it has 652 made any independent effort to identify any such rights. Information 653 on the IETF's procedures with respect to rights in IETF Documents can 654 be found in BCP 78 and BCP 79. 656 Copies of IPR disclosures made to the IETF Secretariat and any 657 assurances of licenses to be made available, or the result of an 658 attempt made to obtain a general license or permission for the use of 659 such proprietary rights by implementers or users of this 660 specification can be obtained from the IETF on-line IPR repository at 661 http://www.ietf.org/ipr. 663 The IETF invites any interested party to bring to its attention any 664 copyrights, patents or patent applications, or other proprietary 665 rights that may cover technology that may be required to implement 666 this standard. Please address the information to the IETF at 667 ietf-ipr@ietf.org. 669 Disclaimer of Validity 671 This document and the information contained herein are provided on an 672 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 673 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 674 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 675 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 676 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 677 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 679 Copyright Statement 681 Copyright (C) The Internet Society (2004). This document is subject 682 to the rights, licenses and restrictions contained in BCP 78, and 683 except as set forth therein, the authors retain all their rights. 685 Acknowledgment 687 Funding for the RFC Editor function is currently provided by the 688 Internet Society.