Problem Statement WG                                     Spencer Dawkins
INTERNET DRAFT                                                 MCSR Labs
23 June  2003                                         Charles E. Perkins
                                                   Nokia Research Center

                   Two Stage Standardization Approach

                  draft-dawkins-pstmt-twostage-00.txt


Status of This Memo

   This document is a submission to the problem-statment Working Group
   of the Internet Engineering Task Force (IETF).  Comments should be
   submitted to the problem-statment@alvestrand.no mailing list.

   Distribution of this memo is unlimited.

   This document is an Internet-Draft and is in full conformance with
   all provisions of Section 10 of RFC2026.  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

1. Abstract

   This specification points out the (obvious) distinction between the
   RFC 2026 Standards Track as documented and the IETF standards track
   as practiced, and proposes a two-step standard track, with judicious
   use of Experimental RFCs, as an alternative.












Dawkins, Perkins           Expires 23 December  2003            [Page i]


Internet Draft          Two Stage Standardization          23 June  2003


2. Problem Statement

   RFC 2026 specifies a three-stage standards process, but relatively
   few standards-track specifications advance beyond Proposed Standard.
   In practice, the IETF has a one-step standards process that is
   vulnerable at both ends of the spectrum:

    -  Admission to "Proposed Standard" is a heavier burden than
       originally envisioned.  Protocol developers may be required to
       specify a complete system, not an interface, in order for their
       specification to be approved as a Proposed Standard.

    -  In spite of this, "Proposed Standard" still does not require
       implementation or deployment experience, so that the IETF's
       "rough consensus and running code" guiding principle has only
       half a chance to be effective.


3. Why Is This A Problem?

   In theory, Proposed Standard is an entry to the standards track.
   In practice, relatively few specifications even advance to Draft
   Standard, and the periodic IESG review of "immature" standards
   described in section 6.2 of RFC 2026 is unknown.  The Internet
   runs on Proposed Standards, some of which are more than 25 years
   old, covering critical aspects of routing, congestion control, and
   security.

   Our use of a "one-step" standards process has these effects:

    -  Our documented process isn't what we use in practice.  This
       disconnect gives us many opportunities for miscommunication and
       mistrust, and doesn't decrease the number of times specifications
       are returned to working groups for rework.

    -  Consumers of IETF specifications have learned to disregard our
       process.  RFC 2026 recommends in clear language that Draft
       Standard, not Proposed Standard, is the proper maturity level for
       widespread deployment.  If vendors believed us, they would be
       left far behind in the marketplace.

    -  Newcomers to the IETF don't understand our process or the ad hoc
       adjustments we've made to accommodate current practice.  For
       example, the Transport Area routinely cycles proposed changes
       to TCP congestion control through Experimental status before
       approval as a Proposed Standard - a reasonable requirement, but
       one not described in RFC 2026.





Dawkins, Perkins           Expires 23 December  2003           [Page ii]


Internet Draft          Two Stage Standardization          23 June  2003


4. One Way of Solving the Problem

   One way of solving the problem is to collapse the "standards track"
   to two steps, Proposed Specification and Internet Standard.  This
   reflects current practice, while making advancing a Proposed
   Specification somewhat more attractive (since Internet Standard is
   only one leap away).

   If it were up to the proposal authors, we would "lower the bar"
   for Proposed Standard, to its original intent - a designation for
   a specification with stable text, some implementation experience,
   and little or no deployment experience.  We recognize that we
   have trained industry to implement and deploy Proposed Standards,
   so instead we propose more active use of Experimental status
   specifications as a "step toward IETF standardization" that does not
   include the word "Standard" in the document status designation, in
   any form.

   Our suggestion is to delete section 4.1.3 of RFC 2026, and rewrite
   sections 4.1.1, 4.1.2, and 4.2.1 of RFC 2026, as follows (other
   edits are required for consistency, but these edits describe what is
   actually proposed):

   4.1.1 Proposed Specification

   The entry-level maturity for the standards track is "Proposed
   Specification".  A specific action by the IESG is required to
   move a specification onto the standards track at the "Proposed
   Specification" level.

   A Proposed 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.

   Neither implementation nor operational experience is absolutely
   required for the designation of a specification as a Proposed
   Specification.  However, such experience is highly desirable, and
   will usually represent a strong argument in favor of designation as a
   Proposed Specification.

   The IESG may require implementation and/or operational experience
   prior to granting Proposed Specification status to a specification
   that materially affects the core Internet protocols or that specifies
   behavior that may have significant operational impact on the
   Internet.  CEP opinion:  two implementations, supporting all mandated
   features, should ALWAYS be REQUIRED for Proposed Specification.



Dawkins, Perkins          Expires 23 December  2003           [Page iii]


Internet Draft          Two Stage Standardization          23 June  2003


   A Proposed Specification 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 Specification state when it is considered
   to be useful and necessary (and timely) even with known technical
   omissions.

   Implementors should treat a Proposed Specification as an immature
   specification.  Implementation provides experience and validates,
   tests, and clarifies the specification.  Since the content of
   Proposed Specification 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 Internet Standard

   A specification may be elevated to the Internet Standard level, when

    -  at least two independent and interoperable implementations of all
       protocol features, from different code bases, have been developed
       from the specification, and

    -  significant implementation and successful operational experience
       has been obtained.

   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.

   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.

   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 Internet Standard



Dawkins, Perkins           Expires 23 December  2003           [Page iv]


Internet Draft          Two Stage Standardization          23 June  2003


   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.  (see Section 6)

   An Internet Standard must be well-understood and known to be quite
   stable, both in its semantics and as a basis for developing an
   implementation.

   An Internet 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
   reasonable for vendors to deploy implementations of Internet
   Standards into a disruption sensitive environment.

   4.2.1 Experimental

   The "Experimental" designation typically denotes a specification that
   is stable enough to implement, but may not be part of a complete
   system (yet), and may not reflect substantial implementation or
   deployment experience.  Such a specification is published for the
   general advancement of the Internet technical community, including
   implementors who wish to obtain implementation and deployment
   experience with the protocol described by the specification.  It
   can also serve as an archival record of the work, subject only to
   editorial considerations and to verification that there has been
   adequate coordination with the standards process (see below).  An
   Experimental specification may be the output of an organized Internet
   research effort (e.g., a Research Group of the IRTF), an IETF Working
   Group, or an individual contribution.

   "Adequate coordination with the standards process" may take the
   form of publication notes pointing out problematic aspects of the
   specification as published, as described in section 4.2.3.

   Experimental specifications have NO standards-track status, although
   Experimental specifications may move to Proposed Specification status
   when they meet the criteria described in section 4.1.1 of this memo.
   CEP observation:  A working charter could, however, have publication
   of an Experimental Standard to be a milestone on the way towards
   completion of a Proposed Specification.

   Protocol developers who have observed the need for deployment
   experience in the past are encouraged to publish Experimental
   specifications.






Dawkins, Perkins           Expires 23 December  2003            [Page v]


Internet Draft          Two Stage Standardization          23 June  2003


5. If This is the Wrong Way to Solve the Problem

   There are other ways to design a standards track for the IETF.
   Instead of cycling through many proposals, the General Area
   Director should assign this problem (if not this draft) to a
   Short Term Problem Resolution working group (as proposed by
   draft-ietf-problem-process-01.txt).


6. Security Considerations

   If security continues to be the last thing protocol developers think
   about, Experimental specifications are likely to reflect this.

   This is preferable to blocking specifications while protocol
   developers who aren't specialists in, for instance, key exchange
   protocols try to come up with acceptable security considerations
   before a specification can be published.


7. Authors Contact Information

   Spencer Dawkins
   Mobile Communications and Security Research Labs
   1547 Rivercrest Blvd.
   Allen, TX 75002
   spencer@mcsr-labs.org
   Tel:  +1 214 755 3870


   Charles E. Perkins
   Communications Systems Lab
   Nokia Research Center
   313 Fairchild Drive
   Mountain View, California 94043
   USA
   Phone:  +1-650 625-2986
   EMail:  charliep@iprg.nokia.com
   Fax:  +1 650 625-2502













Dawkins, Perkins           Expires 23 December  2003           [Page vi]