Two Stage Standardization Approach
draft-dawkins-pstmt-twostage-02

Versions: 00 01 02                                                      
Network Working Group                                         S. Dawkins
Internet-Draft                                   Inet Technologies, Inc.
Expires: November 19, 2004                                    D. Crocker
                                             Brandenburg Internetworking
                                                              C. Perkins
                                                   Nokia Research Center
                                                            May 21, 2004


                       Two Stage Standardization
                  draft-dawkins-pstmt-twostage-02.txt

Status of this Memo

   By submitting this Internet-Draft, I certify that any applicable
   patent or other IPR claims of which I am aware have been disclosed,
   and any of which I become aware will be disclosed, in accordance with
   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.

   This Internet-Draft will expire on November 19, 2004.

Copyright Notice

   Copyright (C) The Internet Society (2004).  All Rights Reserved.

Abstract

   RFC 2026 specifies a three-stage Standards Track.  As currently
   practiced, IETF standards track documents typically attain only the
   first stage.  This proposal discusses the problems caused by the
   disparity between documented procedures and actual practice, and
   proposes a two-step standard track.




Dawkins, et al.        Expires November 19, 2004                [Page 1]


Internet-Draft         Two Stage Standardization                May 2004


Table of Contents

   1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  3
   2.  The Problems . . . . . . . . . . . . . . . . . . . . . . . . .  4
   3.  A Hybrid Solution  . . . . . . . . . . . . . . . . . . . . . .  5
     3.1   Proposed Standard (PS) . . . . . . . . . . . . . . . . . .  5
     3.2   Internet Standard (IS) . . . . . . . . . . . . . . . . . .  5
   4.  Formal Editing Changes . . . . . . . . . . . . . . . . . . . .  6
     4.1   [RFC2026-4.1.1] Proposed Standard  . . . . . . . . . . . .  6
     4.2   [RFC2026-4.1.3] Internet Standard  . . . . . . . . . . . .  6
     4.3   [RFC2026-6.2] Advancing in the Standards Track . . . . . .  7
   5.  Discussion . . . . . . . . . . . . . . . . . . . . . . . . . .  8
     5.1   Proposed Standard  . . . . . . . . . . . . . . . . . . . .  8
     5.2   Internet Standard  . . . . . . . . . . . . . . . . . . . .  8
   6.  Relationship With Other Proposals  . . . . . . . . . . . . . .  9
   7.  Security Considerations  . . . . . . . . . . . . . . . . . . . 10
       Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 10
   A.  References . . . . . . . . . . . . . . . . . . . . . . . . . . 11
       Intellectual Property and Copyright Statements . . . . . . . . 12
































Dawkins, et al.        Expires November 19, 2004                [Page 2]


Internet-Draft         Two Stage Standardization                May 2004


1.  Introduction

   RFC 2026 specifies a three-stage standards process.  In theory,
   Proposed Standard is an entry to the standards track.  In practice
   relatively few specifications ever advance even to the second stage,
   Draft Standard.  Furthermore, the periodic IESG review of "immature"
   standards that is called for in section 6.2 of RFC 2026 seldom
   happens.  Consequently the Internet runs on Proposed Standards, some
   of which are more than 25 years old, covering critical aspects of
   routing, congestion control, and security.

   This results in vulnerability at both ends of the spectrum:
   1.  Admission to "Proposed Standard" carries a heavier burden than
       originally envisioned, because responsible reviewers realize this
       is probably their last chance to identify problems with the
       specification, and try to ôthink of everything that could go
       wrongö.  This thought exercise causes standards track work to be
       less timely.  The protracted development cycle often causes
       productive engineers to lose interest and/or their opportunity to
       remain involved.
   2.  In spite of this, advancing to "Proposed Standard" still does not
       require implementation or deployment experience, so that the
       IETF's "rough consensus and running code" guiding principle isn't
       given a chance to be effective.

   Discussion venue:  Online discussion of this draft should take place
   on the newtrk@lists.uoregon.edu mailing list.
























Dawkins, et al.        Expires November 19, 2004                [Page 3]


Internet-Draft         Two Stage Standardization                May 2004


2.  The Problems

   Current IETF standards management has a number of harmful properties:

   1.  Our documented process isn't what we use in practice.  This
       disparity creates opportunities for miscommunication, which in
       turn creates opportunities for mistrust.
   2.  Basing the review for Proposed Standard on a thought exercise
       instead of implementation and deployment experience encourages
       "late surprises" in the process.  The desire for perfection
       drives reviewers to agonize over warnings and clarity.  Whether a
       specification will be returned to a working group for rework is
       unpredictable, and the time required for approval is highly
       variable.
   3.  Consumers of IETF specifications have learned to disregard our
       formal process.  RFC 2026 recommends in clear language that Draft
       Standard, not Proposed Standard, is the proper maturity level for
       widespread deployment.  Any vendor that waits for this status is
       left far behind in the marketplace (in most cases, infinitely far
       behind).
   4.  Newcomers to the IETF have no written document to explain 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 practice, but one
       not described in RFC 2026.
   5.  We are almost assured that the IETF inventory of standards
       contains specifications which do not reflect the corresponding
       protocols in use on the Internet today, because the protocols
       require modifications to the Proposed Standard specification
       based on implementation or deployment experience, or simply
       because some of these "standard" protocols may not be used at
       all.


















Dawkins, et al.        Expires November 19, 2004                [Page 4]


Internet-Draft         Two Stage Standardization                May 2004


3.  A Hybrid Solution

   This current proposal merges a previous proposal by two of the
   current authors [DAWK], with one suggested by Scott Bradner [BRAD].
   The resulting recipe for labeling IETF standards track documents
   includes some additional seasoning.

   A two-stage standards process is suggested, and Draft Standard status
   is dropped.

3.1  Proposed Standard (PS)

   The IETF process would retain current Proposed Standard rules, with
   the following modifications:
   1.  All specifications must have least one implementation that has
       been tested under the circumstances that represent its intended
       use.
   2.  A fixed, 36-month time limit exists for all Proposed Standards.
       By the end of that time the specification must be re-processed
       for PS status, or it must be processed for the next standards
       level, or it will be moved to Historic status.
   3.  PS specifications receive a STD number, or are added to an
       existing STD.

3.2  Internet Standard (IS)

   This is essentially the same as current full Standard.  The
   specification must have attained a significant degree of community
   acceptance.

   In other words, it must have demonstrated that it is deployed and
   useful in the real world.



















Dawkins, et al.        Expires November 19, 2004                [Page 5]


Internet-Draft         Two Stage Standardization                May 2004


4.  Formal Editing Changes

   This proposal would be put into effect by making the following formal
   changes to official IETF process and procedures specifications.
   Specifically:

   o  Delete section 4.1.2 of [STD]
   o  Rewrite sections 4.1.1 and 4.1.3 of [STD], according to text
      provided later this section
   o  Rewrite the last paragraph of section 6.2 of [STD]
   o  Remove references to Draft Standard from [STD]
   o  Perform other edits required for consistency

4.1  [RFC2026-4.1.1] Proposed Standard

   The entry-level maturity for the IETF 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 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 may well result
   in a change of the specification before it advances, or even perhaps
   a retraction.

   Implementation experience is required for the designation of a
   specification as a Proposed Standard.  The specification must have
   least one implementation that has been tested under the circumstances
   that represent its intended use.  This experience will usually
   represent a strong argument in favor of designation as a Proposed
   Standard.

   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 useful and
   necessary (and timely) even with known technical omissions.

   A specification that reaches the status of Proposed Standard is
   assigned a number in the STD series.

4.2  [RFC2026-4.1.3] Internet Standard

   A specification may be elevated to the Internet Standard level, when
   the specification has been significantly deployed and used over the
   Internet.



Dawkins, et al.        Expires November 19, 2004                [Page 6]


Internet-Draft         Two Stage Standardization                May 2004


   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.

   A specification that reaches the status of Internet Standard retains
   its STD number, but is given a new RFC number.

   The Working Group chair is responsible for documenting the community
   adoption and use of the specification.

   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 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.3  [RFC2026-6.2] Advancing in the Standards Track

   From the time it is assigned Proposed Standard status, a
   specification has thirty-six (36) months to achieve the status of
   Internet Standard.  If it fails to achieve IS status, it will
   automatically be moved to the status of Historic.  This
   reclassification to Historic status shall be communicated to the IETF
   by electronic mail to the IETF Announce mailing list.  Alternatively,
   a specification may be renewed as Proposed Standard, if it again
   satisfies the usual requirements for that status.





















Dawkins, et al.        Expires November 19, 2004                [Page 7]


Internet-Draft         Two Stage Standardization                May 2004


5.  Discussion

   This proposal seeks to capture, specify and refine current practise
   in the IETF, by making its formal labeling actions more streamlined.
   It makes implementation history required for all Proposed Standards,
   eliminates Draft Standard and calls for Internet Standard status to
   be based strictly upon community adoption and use.

   The suggested scheme uses these labels:
   PS: IETF-wide technical approval
   IS: Internet community production deployment and use

   Simplistically this means that PS is the goal for community technical
   evaluation and IS is the goal for operations community adoption.

5.1  Proposed Standard

   The status of Proposed Standard is the entry-level standards label,
   resulting from IETF-wide technical review and approval.  Many
   Proposed Standards documents already reflect implementation and
   testing history, because this improves both the technical quality and
   the credibility of the work.  The new process requires "running code"
   for all PS specifications.  However only one implementation is
   required.  Therefore the requirement for PS is not as demanding as
   the current Draft Standard.

   In order to keep the IETF inventory from having unused and/or buggy
   specifications, documents are allowed to reside at PS for only a
   limited time.

5.2  Internet Standard

   The Internet Standard label is assigned to a specification that has
   received the convincing demonstration of community support, namely
   community use.  Hence the label is not assigned due to technical
   evaluation, but rather by virtue of demonstrated utility.

   Hence the requirements for achieving IS status are to have been at PS
   and then to receive community rough consensus that the specification
   has established a track record of significant usefulness to the
   community.










Dawkins, et al.        Expires November 19, 2004                [Page 8]


Internet-Draft         Two Stage Standardization                May 2004


6.  Relationship With Other Proposals

   This proposal touches the topic area for [LOUG], which focuses on
   improving our ability to describe what documents make up a standard.
   We like many of the ideas in [LOUG], and our proposal will
   significantly increase the number of STDs assigned, and will likely
   increase the need for [LOUG], or something like it.  But [LOUG] is
   orthogonal to this proposal.

   We continue to hope for adoption of some variant of the "Working
   Group Snapshot"/"Stable Snap Shot" mechanism described in [BRAD] and
   [DAWK], but that mechanism is also orthogonal to this proposal.







































Dawkins, et al.        Expires November 19, 2004                [Page 9]


Internet-Draft         Two Stage Standardization                May 2004


7.  Security Considerations

   This document contains no text with security issues, except perhaps
   the security of the IETF standards process.


Authors' Addresses

   Spencer Dawkins
   Inet Technologies, Inc.
   1547 Rivercrest Blvd.
   Allen, TX  75002
   USA

   Phone: +1.469.330.3616
   EMail: spencer@mcsr-labs.org


   Dave Crocker
   Brandenburg Internetworking
   675 Spruce Dr.
   Sunnyvale, CA  94086
   USA

   Phone: +1.408.246.8253
   EMail: dcrocker@brandenburg.com


   Charles E. Perkins
   Nokia Research Center
   Communications Systems Lab
   313 Fairchild Drive
   Mountain View, CA  94043
   USA

   Phone: +1.650.625.2986
   EMail: charles.perkins@nokia.com














Dawkins, et al.        Expires November 19, 2004               [Page 10]


Internet-Draft         Two Stage Standardization                May 2004


Appendix A.  References

   Informative
   [BRAD]: Bradner, S., "An Idea for an Alternate IETF Standards Track",
      draft-bradner-ietf-stds-trk-00.txt, July 2003.
   [DAWK]: Dawkins, S., C.  E.  Perkins, "Two Stage Standardization
      Approach", draft-dawkins-pstmt-twostage-00.txt, June 2003.
   [LOUG]: Loughney, J., "Standards, What Standards?",
      draft-loughney-what-standards-01.txt, February 2004.

   Normative
   [STD]: Bradner, S., "The Internet Standards Process -- Revision 3",
      RFC 2026, October 1996.






































Dawkins, et al.        Expires November 19, 2004               [Page 11]


Internet-Draft         Two Stage Standardization                May 2004


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 procedures with respect to rights in RFC 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.


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.




Dawkins, et al.        Expires November 19, 2004               [Page 12]