Internet DRAFT - draft-ietf-newtrk-proposals

draft-ietf-newtrk-proposals




 
   Network Working Group                                                
   Internet Draft                                              D. Black 
   Document: draft-ietf-newtrk-proposals-00.txt         EMC Corporation 
   Expires: January 2005                                   B. Carpenter 
                                                                    IBM 
                                                              July 2004 
    
    
                 Proposals for a New IETF Standards Track 
    
Status of this Memo 
    
   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 RFC 3668. 
    
   Internet-Drafts are working documents of the Internet Engineering 
   Task Force (IETF), its areas, and its working groups.  Note that      
   other groups may also distribute working documents as Internet-
   Drafts. 
    
   Internet-Drafts are draft documents valid for a maximum of six months 
   and may be updated, replaced, or obsoleted by other documents at any 
   time.  It is inappropriate to use Internet-Drafts as reference 
   material or to cite them other than as "work in progress." 
    
   The list of current Internet-Drafts can be accessed at 
        http://www.ietf.org/ietf/1id-abstracts.txt 
   The list of Internet-Draft Shadow Directories can be accessed at 
        http://www.ietf.org/shadow.html. 
    
Abstract 
    
   Discussions in the IETF's "problem" working group reached consensus 
   that the current IETF 3-stage standards track, as implemented, is not 
   working.  This draft proposes various alternative multi-step 
   standards tracks for debate in the "newtrk" working group. 











 
 
Black                   Expires - January 2005                [Page 1] 




               Proposals for a New IETF Standards Track        July 2004 
 
 
    
Table of Contents 
    
   1. Introduction...................................................2 
   2. Measuring success..............................................4 
   3. Some Proposals for New Standards Tracks........................4 
      3.1 Clean up our act - make current system work better.........4 
      3.2 No More Mr. Nice Guy - make current system work strictly...5 
      3.3 Prune......................................................6 
      3.4 Slash and Burn.............................................6 
      3.5 Declare Victory............................................6 
   4. Common ideas...................................................7 
      4.1 Snapshots..................................................7 
      4.2 Interoperability Register..................................8 
      4.3 Explicit Version Number....................................8 
      4.4 Better Process Documentation and Tracking..................8 
   5. Discussion of Pros and Cons....................................9 
   6. Security Considerations.......................................10 
   7. Acknowledgements..............................................10 
   8. Change log [RFC Editor to remove this section]................10 
   9. Appendix 1: Summary of Current IETF Standards Track...........11 
   10. Appendix 2: Specific example of "Prune"......................13 
      10.1 Alternate Standards Track Maturity Levels................14 
      10.2 Stable Snapshot..........................................14 
      10.3 Proposed Standard........................................15 
      10.4 Internet Standard........................................17 
      10.5 Minimum time in each stage...............................18 
   11. Informative References.......................................18 
   12. Authors' Addresses...........................................19 
    
1. Introduction 
    
   By way of preamble, note that this is a discussion document and not a 
   firm or fully worked out proposal. Once the "newtrk" working group 
   reaches consensus on the general direction to follow, this document 
   will have served its purpose and a revision or update of [RFC2026] 
   will be needed. 
    
   The consensus in the "problem" working group was that the current 
   IETF three stage standards track, described in RFC 2026 [RFC2026] and 
   summarized below in Appendix 1, is not working as originally 
   intended.  The problem statement document [RFC3774] says: 
    
      The current hierarchy of Proposed, Draft, and Full Standard 
      maturity levels for specifications is no longer being used in the 
      way that was envisioned when the stratification was originally 
      proposed.  In practice, the IETF currently has a one-step 
      standards process that subverts the IETF's preference for 
      demonstrating effectiveness through running code in multiple 
 
 
Black                   Expires - January 2005                [Page 2] 




               Proposals for a New IETF Standards Track        July 2004 
 
 
      interoperable implementations.  This compresses the process that 
      previously allowed specifications to mature as experience was 
      gained with actual implementations: 
    
   The document then goes on to list various observations including: 
    
      1/ Few documents actually progress after being published as 
         Proposed Standard (PS). 
    
      2/ There is a perception that the IESG raised the quality 
         requirement for approval as PS beyond the intention of 
         [RFC2026]. 
    
      3/ In spite of the raised quality requirement, running code is not 
         required to achieve PS status. 
    
      4/ There seems to be a reinforcing feedback loop involved: vendors 
         implement and deploy PS specifications, so increasingly the 
         IESG tries to make the PS documents better. 
    
      [RFC3774] concludes that the three-stage process is excessive. 
       
   An alternative interpretation of these observations is that a three-
   step standards process still operates, but the existing standards 
   levels have been shifted upwards so that PS is no longer the initial 
   step.  Vendors will often implement, and their customers deploy, 
   technology based on Internet Drafts as soon as they seem to be 
   stable.  Thus, Internet Drafts have, in effect, replaced PS as the 
   first stage of the IETF standards process, PS has become the second 
   stage, and Draft Standard (DS) the hard-to-achieve third stage. 
    
   But there are significant problems with using Internet Drafts as 
   standards documents.  Most importantly, Internet Drafts are not 
   stable, and their actual degree of instability varies widely. 
   Internet Drafts have short lifetimes with most of them being replaced 
   by new versions or expiring within a few months.  If a vendor decides 
   to implement from an Internet Draft they have to be sure that they 
   are implementing the same version of the Internet Draft as other 
   vendors with whom they want to interoperate.  Many examples show that 
   this is far from being the normal case.  Also, of course, Internet 
   Drafts tend to have bugs and gaps by their very nature. 
    
   It is widely felt that, since the publication of [RFC2026], the IESG 
   has progressively raised the bar for the publication of Proposed 
   Standard documents.  The current level of review, except for not 
   having a requirement for interoperable implementations, is close to 
   what is described for Draft Standard in [RFC2026]. Thus PS has, in 
   effect, replaced DS as the second stage in the IETF standards 
   process, with the first stage being an ill-defined choice of Internet 
 
 
Black                   Expires - January 2005                [Page 3] 




               Proposals for a New IETF Standards Track        July 2004 
 
 
   Draft.  So few specifications are now advanced to final Internet 
   Standard status that this stage has been, in practice, removed.  Few 
   specifications are promoted to the level requiring interoperability 
   (Draft Standard) and any revision of the IETF standards process 
   should try to correct that. 
    
2. Measuring success 
 
   There is a notorious problem in measuring the success of 
   organizational change: those who make the measurements are usually 
   impatient, and do so years before the changes have percolated through 
   the entire organization and actually affected results. Nevertheless, 
   we would be wise to have an idea of what we are looking for as a 
   result of the change process. Some very loose ideas on what we might 
   wish to measure are: 
    
     * Increase the interoperability of implementations of new 
       protocols on the Internet (how to measure?) 
     * Shorten the time from "adopted idea" to "stable spec" for 
       protocols from 2 years to 1 year (?) 
     * Reduce the number of man-hours required to document 
       interoperability and formally acknowledge that it exists 
       (no idea of what to put in the "from" and "to" fields....) 
     * Increase motivation of IETF participants to advance their  
       work along the standards track, and increase the  
       attractiveness of the IETF as a standards venue 
    
3. Some Proposals for New Standards Tracks 
    
   This section gives short summaries of a number of possible proposals 
   to resolve the above issues, by tuning or changing the standards 
   track process. The summaries are inevitably too short to capture all 
   details, so they certainly leave open issues. More suggestions are 
   welcome. The following section discusses pros and cons. 
    
3.1 Clean up our act - make current system work better 
    
   In this proposal there would be no significant change to [RFC2026], 
   but specific efforts would be made to fix the ways in which it is not 
   working. Three examples of such efforts have been documented: 
    
   [VAD] proposes a mechanism for advancement of "Valuable Antique 
   Documents" - essentially a lightweight committee mechanism for 
   upgrading the status of tried and proven specifications, typically 
   those that have been at Proposed Standard for many years, without the 
   pain of bringing the documents up to current standards. 
    


 
 
Black                   Expires - January 2005                [Page 4] 




               Proposals for a New IETF Standards Track        July 2004 
 
 
   [MDH] proposes a similar lightweight mechanism for moving 
   specifications that are the opposite of tried and proven rapidly to 
   Historic status. 
    
   [RSD] proposes that the IESG act of designating a specification as an 
   Internet Standard be recorded by a separate document that would 
   receive the STD designation, with the actual specification being 
   referred to only as an RFC.  Current Internet Standards carry both an 
   RFC number and an STD number.  A separate document provides an 
   opportunity for "appropriate qualifying notes" that could include the 
   current state of known interoperability (see Section 4.2 
   Interoperability Register, although [SWS] proposes a dynamically 
   maintained register), cautions about the stability, applicability, 
   etc. of a specification and even editorial comments to guide such as 
   protocol and system designers (e.g., a warning that a mechanism like 
   NAT, although widely implemented and deployed, is nonetheless 
   considered to be a "bad idea" due to its impact on end-to-end aspects 
   of the Internet). 
    
   A separate STD document would also provide a useful way of collecting 
   related specifications that comprise a single standard; for example, 
   it is not a simple exercise to determine the set of specifications 
   that currently constitutes TCP.  Once this separation of STD into a 
   separate document is performed, the resulting mechanism and its 
   benefits need not be restricted to Internet Standards; [RSD] proposes 
   applying it to all standards-track RFCs (Author's aside: it may be 
   wise to use a prefix other than STD in this case to avoid confusion 
   with current STD usage).  Separate STD documents could be maintained 
   as living web documents that can be updated as changes occur instead 
   of or in addition to archival documents that can only be superseded 
   by publication of a new document. 
    
   No doubt other mechanisms (and ongoing operational changes outside 
   the scope of the newtrk WG) could also help the current system (and 
   see Section 4.4 for some specific suggestions that apply to any of 
   the possible standards track structures). 
    
3.2 No More Mr. Nice Guy - make current system work strictly 
    
   This proposal would confirm the intention of [RFC2026] and implement 
   strict operational procedures to make it work.  This would mean: 
    
      * reducing the strictness of IESG review for PS to a defined 
         minimum, 
      * enforcing the two year "dwell time" at PS by automatically 
         demoting PS documents to Historic if no interoperability 
         evidence is offered after two years or unless active work on a 
         revised specification is under way, and  
      * introducing a similar "dwell time" for DS to be considered for 
 
 
Black                   Expires - January 2005                [Page 5] 




               Proposals for a New IETF Standards Track        July 2004 
 
 
         Internet Standard status or die (back to PS for another two 
         years?). 
    
   The dwell time could be adjusted from its current value of two years. 
    
3.3 Prune 
    
   The number of standards levels is pruned to two (we could call them 
   Draft Standard and Internet Standard). The threshold for DS would be 
   roughly what PS is today (stricter than PS in [RFC2026] but not 
   requiring proof of interoperability). The threshold for IS would be a 
   minimum period at DS, plus evidence of interoperability and 
   reasonable deployment experience. On the other hand, documents should 
   not be allowed to sit indefinitely at DS, so a dwell time would have 
   to be enforced.  The two levels could also be called Proposed 
   Standard and Internet Standard. 
    
   An interoperability register (Section 4.2) would be created to track 
   the evidence of interoperability. 
    
   This could be combined with some form of Snapshot (Section 4.1) to 
   provide an initial level with better stability than an arbitrary 
   Internet-Draft. 
    
   Specific proposals can be found in Appendix 2 (with Snapshot) and 
   [TSS] (without Snapshot, but the [WGS] Snapshot proposal is intended 
   to be complementary to [TSS]).  
    
3.4 Slash and Burn 
    
   The number of levels is reduced to one, called Internet Standard.   
   The threshold would be roughly the same as for Proposed Standard 
   today (roughly what is described in [RFC2026] for Draft Standard, but 
   *without* the interoperability requirement). 
    
   This could be combined with some form of Snapshot (Section 4.1) to 
   provide an initial level with better stability than an arbitrary 
   Internet-Draft. 
    
3.5 Declare Victory 
    
   Instead of making changes, just revise [RFC2026] to document current 
   practice, including the observations from [RFC3774] (See Section 1).  
   The revised document would elevate the requirements for Proposed 
   Standard from those documented in [RFC2026] in addition to stating 
   that many important protocols never advance to Draft Standard and 
   that Internet Standard is rarely used.  The current requirement for 
   review after a 2-year "dwell time" at a standards level would be 
   changed to a recommendation. 
 
 
Black                   Expires - January 2005                [Page 6] 




               Proposals for a New IETF Standards Track        July 2004 
 
 
4. Common ideas 
    
   The ideas in this section can probably be combined with various of 
   the proposals above. 
 
4.1 Snapshots 
    
   It seems inevitable that there will be a noticeable time lag from 
   when a working group believes that a specification is done until it 
   gets finally published, whatever changes are made to the standards 
   track. Mechanically, the processes of IETF Last Call, IESG review, 
   IANA action if needed, and RFC Editor action will take time, even if 
   no issues are found that need to be referred back to the WG. During 
   this wait, early implementers need to know which version of the 
   document to work from. Also, WGs may reach intermediate stages in 
   developing a complex specification when it is useful for all trial 
   implementations to be using the same version. For these two reasons, 
   a snapshot mechanism has been suggested, in at least two variants: 
    
   a) Working Group Snapshot. In this model WGs are authorized to 
      declare (by WG rough consensus, possibly including a Last Call) 
      that a particular draft is a WG Snapshot.  No IESG or even Area 
      Director approval would be required - this would be a simple 
      statement to the world that the WG has declared a snapshot, along 
      with a statement of the purpose for which the snapshot was 
      declared. As far as implementers are concerned, 'caveat emptor' 
      applies. The only procedural issue is that an Internet Draft that 
      has been declared a WG Snapshot could get a life extension beyond 
      the normal six months, even if a later version number is 
      published.  A specific proposal is in [WGS]. 
    
   b) IETF Stable Snapshot. Similar, but AD or IESG approval in some 
      form is required, entailing at least a WG Last Call on the draft 
      before it becomes a Snapshot.  A lightweight cross-area technical 
      review (lighter than [RFC2026] intended even for PS) would be 
      made.  A specific proposal envisaging an affirmative approval 
      mechanism is in Appendix 2.  An "approve by default" process has 
      also been suggested in which specifications nominated for this 
      level by a WG would be approved in the absence of specific 
      technical objections during an IETF-wide Last Call. 
    
   There are a variety of options in the possible level (depth and 
   cross-area breadth) of technical review that could be part of 
   declaring a Snapshot; the required level could vary based on the 
   stated purpose of the snapshot. 
    
   When IETF Stable Snapshot is combined with mechanisms that eliminate 
   a standards level (e.g., Prune in Section 3.3, Slash and Burn in 

 
 
Black                   Expires - January 2005                [Page 7] 




               Proposals for a New IETF Standards Track        July 2004 
 
 
   Section 3.4), it is possible to use the name "Proposed Standard" for 
   IETF Stable Snapshot. 
    
   None of the current Snapshot proposals contain new measures for 
   retiring snapshots.  It is unclear whether allowing Snapshots to 
   expire (as Internet Drafts do) is an effective impetus for 
   implementers to move on to a subsequent stable version (which may 
   contain significant technical improvements).  Higher levels of 
   approval (e.g., IESG) for a Snapshot may make this more difficult to 
   accomplish. 
    
4.2 Interoperability Register 
    
   In this idea, a separate "Interoperability and Deployment Register" 
   would be maintained by the IETF Secretariat. This would be a public 
   record of demonstrated interoperability and deployment experience. 
   Either the IESG, or better perhaps a special IETF Interoperability 
   Committee, would approve the publication of such a record.  A 
   specification would get a gold star when it had such a public record. 
   Note that this idea of a registry is separable and could be used with 
   any of the proposals. [SWS] discusses this issue further. 
    
4.3 Explicit Version Number 
    
   Recycling at the same standards level is an important and useful 
   aspect of the IETF standards process.  Formalizing the notion of a 
   version number (essentially the number of times a specification has 
   been reissued as an RFC at the same level) could be a useful addition 
   to the process, as opposed to the current situation where version 
   numbers are left to the judgment of specification authors. 
    
4.4 Better Process Documentation and Tracking 
    
   All documents (Internet Drafts, RFCs) get a formal system of tracking 
   issues, known implementations of individual features, known problems, 
   statements of determination of stability, etc.  The 'stable snapshot' 
   state described in Section 4.1 would become just one of the kinds of 
   annotations that a working group can give to a document during its 
   development. 
     
   All documents must have a mailing list for discussion of the 
   document, with an archive of the mail on the mailing list. The 
   mailing archive should be enabled for advanced searching capability.  
   All RFCs and Internet Drafts (even old ones!) should include the URLs 
   of the web pages that give additional information about the document. 
   The STATUS OF THIS MEMO section should be updated to make the ways 
   the status can change be clearer. 
    

 
 
Black                   Expires - January 2005                [Page 8] 




               Proposals for a New IETF Standards Track        July 2004 
 
 
   This additional information should be in a standard format that 
   includes an issue list, errata, proposed changes, known 
   implementations, pointers to IPR statements.  Implementation and 
   interoperability testing information should be added incrementally 
   such that the result will be adequate for an "implementation and 
   interoperability report", i.e., construction of these should start 
   much earlier, and include information such as implementation of 
   particular features, interoperability testing for individual 
   features, and statements about independent licensing of known IPR. 
    
   There should be a formal process for updating this information, with 
   clear responsibility and processes for adding to it and changing it, 
   and review process for objecting to changes that others deem 
   inappropriate. The current de facto process is that the WG mailing 
   list remains open, additions to the list are discussed on the list, 
   and the former WG chair, area director, document editor(s), or 
   person(s) appointed by any of those reviews additions before adding 
   them to the errata, although the fact that the RFC Editor maintains 
   errata for RFCs does not seem to be widely known. 
    
5. Discussion of Pros and Cons 
    
   At this writing, there appears to be consensus in the WG that 
   regardless of the number of formal stages in the standards track, 
   there will be multiple reviews of specifications by the IESG - that 
   is to say, corrected or improved specifications will certainly be 
   produced, reviewed and approved regardless of exactly how they are 
   labeled. It is important to remember this consensus when considering 
   the following discussion. 
    
   Clean Up Our Act 
   + should eliminate dross and avoid pointless rewrites 
   - does nothing to simplify the process 
    
   No More Mr. Nice Guy 
   + reduces ambiguity and process black holes 
   - insensitive to social aspects, may demotivate 
   - does nothing to simplify the process 
    
   Prune 
   + reduces bureaucracy and terminology 
    
   Slash And Burn 
   + reduces bureaucracy more 
    
   Declare Victory 
   + avoids introducing confusion outside IETF about IETF standards 
      process and states 
   - ignores problem statement and does nothing to improve process 
 
 
Black                   Expires - January 2005                [Page 9] 




               Proposals for a New IETF Standards Track        July 2004 
 
 
    
   Snapshots 
   + avoid industry FUD and random implementation choices 
   - may end up as a class of de facto standards 
    
   Interoperability Register 
   + increase clarity about interoperability 
   - new work for the IETF, new committee 
    
   Better Process Documentation and Tracking 
   + central accessible place for important info 
   - additional work to get that info into a central accessible place 
      and maintain the result 
    
6. Security Considerations 
    
   This document relates to IETF process, not any particular technology, 
   thus it raises no particular security concerns. We may note that 
   security requirements currently seem to be the source of the most 
   conflicts over whether a specification is "good enough", so we must 
   expect that a change in requirements criteria will in effect have a 
   security impact on the Internet. 
    
7. Acknowledgements 
    
   Substantial text was taken directly from an earlier draft by Scott 
   Bradner. Ideas were lifted from mailing list discussions. Comments 
   and contributions were made by Grump, Lars-Erik Jonsson, John 
   Klensin, Larry Masinter, and other members of the newtrk WG. 
    
8. Change log [RFC Editor to remove this section] 
 
   May 2004 - first version as draft-black-newtrk-proposals-00.txt 
    
   July 2004 - second version as draft-ietf-newtrk-proposals-00.txt 
    - added section on measuring success 
    - added section to separate out separable components 
    - added "clean up our act" section 
    - added idea for "approve by default" mechanism to IETF Stable 
         Snapshot 
    - added some discussion of use of WG Last Call for snapshots 
    - added possibility of using "Proposed Standard" for IETF Stable 
         Snapshot; edit Prune to allow DS name as lower standard level 
    - added "explicit version number" section 
    - added "better process documentation and tracking" section  
    - pros and cons section partly filled in 
    - minor editorial revisions 
    

 
 
Black                   Expires - January 2005               [Page 10] 




               Proposals for a New IETF Standards Track        July 2004 
 
 
9. Appendix 1: Summary of Current IETF Standards Track 
    
   Section 4.1 [RFC2026] defines the stages on the IETF standards track 
   as follows: 
    
   4.1 Standards Track Maturity Levels 
    
      Internet specifications go through stages of development, testing, 
      and acceptance.  Within the Internet Standards Process, these 
      stages are formally labeled "maturity levels". 
    
    
      This section describes the maturity levels and the expected 
      characteristics of specifications at each level. 
    
   4.1.1 Proposed Standard 
    
      The entry-level maturity for the standards track is "Proposed 
      Standard".  A specific action by the IESG is required to move a 
      specification onto the standards track at the "Proposed Standard" 
      level. 
    
      A Proposed Standard specification is generally stable, has 
      resolved known design choices, is believed to be well-understood, 
      has received significant community review, and appears to enjoy 
      enough community interest to be considered valuable.  However, 
      further experience might result in a change or even retraction of 
      the specification before it advances. 
    
      Usually, neither implementation nor operational experience is 
      required for the designation of a specification as a Proposed 
      Standard.  However, such experience is highly desirable, and will 
      usually represent a strong argument in favor of a Proposed 
      Standard designation. 
    
      The IESG may require implementation and/or operational experience 
      prior to granting Proposed Standard status to a specification that 
      materially affects the core Internet protocols or that specifies 
      behavior that may have significant operational impact on the 
      Internet. 
    
      A Proposed Standard should have no known technical omissions with 
      respect to the requirements placed upon it.  However, the IESG may 
      waive this requirement in order to allow a specification to 
      advance to the Proposed Standard state when it is considered to be 
      useful and necessary (and timely) even with known technical 
      omissions. 
    
      Implementors should treat Proposed Standards as immature 
 
 
Black                   Expires - January 2005               [Page 11] 




               Proposals for a New IETF Standards Track        July 2004 
 
 
      specifications.  It is desirable to implement them in order to 
      gain experience and to validate, test, and clarify the 
      specification.  However, since the content of Proposed Standards 
      may be changed if problems are found or better solutions are 
      identified, deploying implementations of such standards into a 
      disruption-sensitive environment is not recommended. 
    
   4.1.2 Draft Standard 
    
      A specification from which at least two independent and 
      interoperable implementations from different code bases have been 
      developed, and for which sufficient successful operational 
      experience has been obtained, may be elevated to the "Draft 
      Standard" level.  For the purposes of this section 
      "interoperable" means to be functionally equivalent or 
      interchangeable components of the system or process in which they 
      are used.  If patented or otherwise controlled technology is 
      required for implementation, the separate implementations must 
      also have resulted from separate exercise of the licensing 
      process.  Elevation to Draft Standard is a major advance in 
      status, indicating a strong belief that the specification is 
      mature and will be useful. 
    
      The requirement for at least two independent and interoperable 
      implementations applies to all of the options and features of the 
      specification.  In cases in which one or more options or features 
      have not been demonstrated in at least two interoperable 
      implementations, the specification may advance to the Draft 
      Standard level only if those options or features are removed. 
    
      The Working Group chair is responsible for documenting the 
      specific implementations which qualify the specification for Draft 
      or Internet Standard status along with documentation about testing 
      of the interoperation of these implementations.  The documentation 
      must include information about the support of each of the 
      individual options and features.  This documentation should be 
      submitted to the Area Director with the protocol action request. 
    
      A Draft Standard must be well-understood and known to be quite 
      stable, both in its semantics and as a basis for developing an 
      implementation.  A Draft Standard may still require additional or 
      more widespread field experience, since it is possible for 
      implementations based on Draft Standard specifications to 
      demonstrate unforeseen behavior when subjected to large-scale use 
      in production environments. 
    
      A Draft Standard is normally considered to be a final 
      specification, and changes are likely to be made only to solve 
      specific problems encountered.  In most circumstances, it is 
 
 
Black                   Expires - January 2005               [Page 12] 




               Proposals for a New IETF Standards Track        July 2004 
 
 
      reasonable for vendors to deploy implementations of Draft 
      Standards into a disruption sensitive environment. 
    
    
   4.1.3 Internet Standard 
    
      A specification for which significant implementation and 
      successful operational experience has been obtained may be 
      elevated to the Internet Standard level.  An Internet Standard 
      (which may simply be referred to as a Standard) is characterized 
      by a high degree of technical maturity and by a generally held 
      belief that the specified protocol or service provides significant 
      benefit to the Internet community. 
    
      A specification that reaches the status of Standard is assigned a 
      number in the STD series while retaining its RFC number. 
    
10. Appendix 2: Specific example of "Prune" 
    
   Scott Bradner originally proposed this alternate IETF standards track 
   with a new stage inserted before Proposed Standard, combining Draft 
   Standard and Internet Standard and retaining Proposed Standard as it  
   has evolved over the years. 
    
   Part of the problem we have been seeing with getting timely 
   publication of IETF specifications is that once people start 
   implementing the technology it often seems counterproductive to 
   dedicate effort to finishing off the documents.  If implementations 
   of Internet Drafts achieve success in the marketplace, as they did 
   with MPLS, it may seem that it is not worth spending time tweaking 
   successive generations of Internet Drafts in order to get something 
   the IESG is willing to publish as a Proposed Standard then, if that 
   achieves widespread success in the market, fiddle with the document 
   again and do the bookkeeping needed to get it published as a Draft 
   Standard.  The prerequisites for getting something published as an 
   Internet Standard seem to many people to be fuzzy at best.  In 
   addition, the current standards track steps did not do much to 
   encourage early implementations, which are the best way to check to 
   see that a specification is clear enough for implementers to use. 
   This alternate set of stages tries to encourage vendors to implement 
   specifications and the comments with the descriptions of each stage 
   attempt to provide guidance for the IESG in implementing reviews for 
   each stage. 
    
   RFC 2026 would have to be revised in order to put any change of this 
   type into effect.  That could be done by replacing RFC 2026 itself 
   with a whole new document or by writing a short document that updates 
   the standards track part of RFC 2026. 
    
 
 
Black                   Expires - January 2005               [Page 13] 




               Proposals for a New IETF Standards Track        July 2004 
 
 
    
10.1 Alternate Standards Track Maturity Levels 
    
   Internet specifications go through stages of development, testing, 
   and acceptance.  Within the Internet Standards Process, these stages 
   are formally labeled "maturity levels". 
    
   This section describes a set of alternate maturity levels and the 
   expected characteristics of specifications at each level. 
    
10.2 Stable Snapshot 
    
   The entry-level maturity for the standards track is "Stable 
   Snapshot".  A specific action by the IESG is required to move a 
   specification onto the standards track at the "Stable Snapshot" 
   level. 
    
   A Stable Snapshot specification is generally stable, has resolved 
   known design choices, is believed to be well-understood, has received 
   significant community review, and appears to enjoy enough community 
   interest to be considered valuable.  However, further experience 
   might result in a change or even retraction of the specification 
   before it advances. 
    
   A Stable Snapshot should have no known technical omissions with 
   respect to the requirements placed upon it.  Any such omissions must 
   be noted in the document.  No such omission can endanger the security 
   or stability of the Internet or of networks where the technology 
   might be used. 
    
   Implementers should treat Stable Snapshots as immature, pre-standard, 
   specifications.  It is desirable to implement them in order to gain 
   experience and to validate, test, and clarify the specification.  
   However, since the content of Stable Snapshots will be changed if 
   problems are found or better solutions are identified, and will be   
   changed as the technology is finalized, deploying implementations of   
   such technologies into a disruption-sensitive environment is not   
   recommended. 
    
      Commentary: 
    
      This stage is designed to institutionalize and encourage the 
      current practice of vendors implementing from Internet Drafts 
      while providing a way that a working group can indicate that 
      they feel that a technology is stable enough to be so implemented 
      and to provide a long-lived, unlike Internet Drafts, snapshot that 
      the vendors can implement.  Having vendors implement technology is 
      an important quality check and meets the "running code" 
      requirement of our motto.  We want to encourage implementations 
 
 
Black                   Expires - January 2005               [Page 14] 




               Proposals for a New IETF Standards Track        July 2004 
 
 
      whenever we can but this does need to be balanced with some level 
      of maturity and stability of the protocol. 
    
      This is almost the same definition as RFC 2026 has for Proposed 
      Standard.  The major difference is that some of the technical 
      requirements might not have yet been met.  This is OK as long as 
      any such holes in the specification are carefully noted in the 
      document, except that there needs to be a complete enough security 
      component so as to not endanger the networks where the technology 
      is to be used, and that the technology not endanger the wellbeing 
      of the network it will be run on.  The exact guidelines for 
      the level of security required for a Stable Snapshot will evolve 
      over time. 
    
    
      In reviewing an Internet Draft for publication as a Stable 
      Snapshot the IESG only needs to be sure that the working group has 
      a reason to think that the technology is at a mature enough level 
      that implementers can start to play with it and that the minimum 
      security and 'health of the net' requirements have been met.  The 
      IESG should not try to ensure that the text is clear and 
      unambiguous, the vendors will find that out while implementing and 
      provide feedback to the working group. The IESG should not do a 
      careful technology review as a precondition for publication as a 
      Stable Snapshot.  This process should be lightweight, not taking 
      too much time on the part of the IESG or effort on the part of the 
      working group and authors. 
    
      The name, "Stable Snapshot" was chosen to clearly indicate that 
      this is a pre-standard stage and to ensure that marketing people 
      cannot easily misrepresent the status but there may be a better 
      name that accomplishes the same goals. 
    
10.3 Proposed Standard 
    
   A Proposed Standard specification is generally stable, has resolved 
   known design choices, is believed to be well-understood, has received 
   significant community review, and appears to enjoy enough community 
   interest to be considered valuable. 
    
   Usually, neither implementation nor operational experience is 
   required for the designation of a specification as a Proposed 
   Standard.  However, such experience is highly desirable, and will 
   usually represent a strong argument in favor of a Proposed Standard 
   designation. 
    
   Generally some documented level of implementation and/or operational 
   experience is required prior to granting Proposed Standard status. 
   However, the IESG may waive this requirement in order to allow a 
 
 
Black                   Expires - January 2005               [Page 15] 




               Proposals for a New IETF Standards Track        July 2004 
 
 
   specification to advance to the Proposed Standard state when it is 
   considered to be useful and necessary (and timely) even without any 
   known implementations. 
    
   A Proposed Standard should have no known technical omissions with 
   respect to the requirements placed upon it. 
    
   Implementers should treat Proposed Standards as stable, but perhaps 
   not final, specifications.  A Proposed Standard must be well- 
   understood and known to be quite stable, both in its semantics and as 
   a basis for developing an implementation.  A Proposed Standard may 
   still require additional or more widespread field experience, since 
   it is possible for implementations based on Proposed Standard 
   specifications to demonstrate unforeseen behavior when subjected to 
   large-scale use in production environments. 
    
      Commentary: 
    
      The requirements for publication as a Proposed Standard are mostly 
      the same as currently in RFC 2026 for Proposed Standard with the 
      addition of a requirement for at least some implementation 
      experience. 
    
      The IESG review for Proposed Standard could stay just like it is. 
      The IESG should do the same careful technical review and a review 
      to ensure that the language of the document is clear and precise 
      as it has been doing for quite a while. 
    
      Because most specifications for which publication as a Proposed 
      Standard is requested will have been implemented I would expect 
      that the IESG review will generally take less effort since the 
      implementers experience will have uncovered unclear language and 
      some or all technical issues, at least for the parts of the 
      specification that had been implemented. 
    
      There should be some documentation to show that there has been at 
      least one implementation of a specification before the IESG 
      authorizes the publication of the specification as a Proposed 
      Standard.  But the documentation does not need to be so detailed 
      that it shows which individual options have been implemented.  A 
      list of the names of people or companies who have said they had 
      implemented the specification should be sufficient. 
    
      Before adoption of a new description of Proposed Standard the IPR- 
      related aspects should be revisited in list of the work in the IPR 
      working group but that is not done here. 
    
    

 
 
Black                   Expires - January 2005               [Page 16] 




               Proposals for a New IETF Standards Track        July 2004 
 
 
10.4 Internet Standard 
    
   A specification from which at least two independent and interoperable 
   implementations from different code bases have been developed, and 
   for which sufficient successful operational experience has been 
   obtained, may be elevated to the "Internet Standard" level.  For the 
   purposes of this section, "interoperable" means to be functionally 
   equivalent or interchangeable components of the system or process in 
   which they are used.  If patented or otherwise controlled technology 
   is required for implementation, the separate implementations must 
   also have resulted from separate exercise of the licensing process. 
   Elevation to Internet Standard is a major advance in status, 
   indicating a strong belief that the specification is mature and will 
   be useful. 
    
   The requirement for at least two independent and interoperable 
   implementations applies to all of the options and features of the 
   specification.  In cases in which one or more options or features 
   have not been demonstrated in at least two interoperable 
   implementations, the specification may advance to the Internet 
   Standard level only if those options or features are removed. 
    
   The Working Group chair is responsible for documenting the specific 
   implementations which qualify the specification for Draft or Internet 
   Standard status along with documentation about testing of the 
   interoperation of these implementations.  The documentation must 
   include information about the support of each of the individual 
   options and features.  This documentation should be submitted to the 
   Area Director with the protocol action request. 
    
   A Internet Standard (which may simply be referred to as a Standard) 
   must be well-understood and known to be stable, both in its semantics 
   and as a basis for developing an implementation.  An Internet 
   Standard is characterized by a high degree of technical maturity and 
   by a generally held belief that the specified protocol or service 
   provides significant benefit to the Internet community. 
    
   An Internet Standard is considered to be a final specification, and 
   changes should only be made to solve specific problems encountered. 
    
    
      Commentary: 
    
      The description here is a combination of the descriptions of Draft 
      Standard and Internet Standard in RFC 2026. 
    
      One issue we have had over the years is just what does a working 
      group chair have to do to show multiple implementations of the 
      base specification and all of the features.  I have always felt 
 
 
Black                   Expires - January 2005               [Page 17] 




               Proposals for a New IETF Standards Track        July 2004 
 
 
      that a simple spread sheet showing each feature, how many vendors 
      claim to have the feature, and a checkbox to indicate that two or 
      more vendors claim that they have tested implementations of the 
      feature, would be just fine.  But this turns out to be quite 
      complex in some cases (see the Implementer's report for http 1.1 
      as an example).  It is not cleare if this turns out to be actually 
      too much of an effort or just seems like too much of an effort.  
      It still seems like about the right thing but the barrier to 
      reach Internet Standard should be just as high as it needs to be 
      but no higher. 
    
    
      Since, in reality, there was little difference between the 
      requirements in RFC 2026 for Draft Standard and Internet Standard, 
      mostly a need to show market acceptance in some way, there seems 
      to be no technical reason to preserve the different labels. 
    
10.5 Minimum time in each stage. 
    
   It seems that there needs to be a minimum time that a document must 
   sit at a stage before it can move onward (as is the case in RFC 2026) 
   just to be sure that any problems are uncovered. 
    
   It is unclear how to figure out the ideal time so it is suggested 
   that 6 months would be enough (as long as the rest of the 
   requirements for the next level have been met). 
    
    
11. Informative References 
    
   [MDH]  Alvestrand, H. and E. Lear, "Moving documents to Historic: A 
      procedure", draft-alvestrand-newtrk-historical-00 (work in 
      progress) 
    
   [RFC2026] Bradner, S. Ed., "The Internet Standards Process -- 
      Revision 3," October 1996, RFC 2026 
    
   [RFC3774] Davies, E. Ed., "IETF Problem Statement," May 2004, 
      RFC 3774 
    
   [TSS] Dawkins, S., et. al., "Two Stage Standardization," work in 
      progress, draft-dawkins-pstmt-twostage-02.txt 
    
   [WGS] Dawkins, S., et al, "Working Group Snapshot (WGS)," work in 
      progress, draft-dawkins-newtrk-wgs-00.txt 
    
   [VAD] Klensin, J., "Valuable Antique Documents: A Model for 
      Advancement", draft-klensin-newtrk-antiques-00.txt (work in 
      progress) 
 
 
Black                   Expires - January 2005               [Page 18] 




               Proposals for a New IETF Standards Track        July 2004 
 
 
    
   [RSD] Klensin, J., "Repurposing the STD Designation", draftdraft 
      klensin-newtrk-std-repurposing-00.txt (work in progress) 
    
   [SWS] Loughney, J., "Standards, What Standards?", draft-loughney 
      what-standards-01.txt, (work in progress) 
    
12. Authors' Addresses 
    
      David L. Black 
      EMC Corporation 
      176 South Street 
      Hopkinton, MA 01748 
      Email: black_david@emc.com 
    
      Brian E. Carpenter 
      IBM Zurich Research Laboratory 
      Saeumerstrasse 4 / Postfach 
      8803 Rueschlikon 
      Switzerland 
      Email: brc@zurich.ibm.com 
    
Intellectual Property Statement 
    
   The IETF takes no position regarding the validity or scope of any 
   Intellectual Property Rights or other rights that might be claimed to 
   pertain to the implementation or use of the technology described in 
   this document or the extent to which any license under such rights 
   might or might not be available; nor does it represent that it has 
   made any independent effort to identify any such rights. Information 
   on the IETF's procedures with respect to rights in IETF Documents can 
   be found in BCP 78 and BCP 79. 
    
   Copies of IPR disclosures made to the IETF Secretariat and any 
   assurances of licenses to be made available, or the result of an 
   attempt made to obtain a general license or permission for the use of 
   such proprietary rights by implementers or users of this 
   specification can be obtained from the IETF on-line IPR repository at 
   http://www.ietf.org/ipr. 
    
   The IETF invites any interested party to bring to its attention any 
   copyrights, patents or patent applications, or other proprietary 
   rights that may cover technology that may be required to implement 
   this standard. Please address the information to the IETF at 
   ietf-ipr@ietf.org. 




 
 
Black                   Expires - January 2005               [Page 19] 




               Proposals for a New IETF Standards Track        July 2004 
 
 
Disclaimer of Validity 
    
   This document and the information contained herein are provided on an   
   "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 
   OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 
   ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 
   INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 
   INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 
   WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 
    
Copyright Statement 
    
   Copyright (C) The Internet Society (2004). This document is subject 
   to the rights, licenses and restrictions contained in BCP 78, and 
   except as set forth therein, the authors retain all their rights. 
    
Acknowledgment 
    
   Funding for the RFC Editor function is currently provided by the 
   Internet Society. 
    




























 
 
Black                   Expires - January 2005               [Page 20]