One document matched: draft-carpenter-newtrk-twostep-00.txt

Network Working Group                                       B. Carpenter
Internet-Draft                                                       IBM
Expires: December 3, 2005                                      June 2005


                     A two stage standards process
                   draft-carpenter-newtrk-twostep-00

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 BCP 79.

   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 December 3, 2005.

Copyright Notice

   Copyright (C) The Internet Society (2005).

Abstract

   This document proposes several changes of principle to the Internet
   standards process, especially a reduction from three to two stages in
   the standards track.









Carpenter               Expires December 3, 2005                [Page 1]

Internet-Draft                  Two stage                      June 2005


Table of Contents

   1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  3
   2.  Stage 1: Proposed Standard . . . . . . . . . . . . . . . . . .  3
   3.  Stage 2: Interoperable Standard  . . . . . . . . . . . . . . .  3
   4.  Stage 3: No stage three  . . . . . . . . . . . . . . . . . . .  4
   5.  Timing rules . . . . . . . . . . . . . . . . . . . . . . . . .  4
   6.  IS can reference PS  . . . . . . . . . . . . . . . . . . . . .  5
   7.  The STD designation, and updates . . . . . . . . . . . . . . .  5
   8.  Transitional arrangements  . . . . . . . . . . . . . . . . . .  5
   9.  Not excluded . . . . . . . . . . . . . . . . . . . . . . . . .  6
   10.   Housekeeping . . . . . . . . . . . . . . . . . . . . . . . .  6
   11.   Security Considerations  . . . . . . . . . . . . . . . . . .  6
   12.   IANA Considerations  . . . . . . . . . . . . . . . . . . . .  6
   13.   Acknowledgements . . . . . . . . . . . . . . . . . . . . . .  6
   14.   Informative References . . . . . . . . . . . . . . . . . . .  7
       Author's Address . . . . . . . . . . . . . . . . . . . . . . .  7
       Intellectual Property and Copyright Statements . . . . . . . .  8

































Carpenter               Expires December 3, 2005                [Page 2]

Internet-Draft                  Two stage                      June 2005


1.  Introduction

   This document proposes several changes of principle to the Internet
   standards process defined in [1].

   The background for this proposal is the published analysis of
   problems in the IETF [2], various discussions in the IETF's "New IETF
   Standards Track Discussion" (newtrk) working group, various largely
   expired drafts, and the author's personal experience.  The proposal
   is purely personal and specifically has not been discussed in the
   IESG.  It has little claim to originality (see Acknowledgements).

   The problems tackled by this proposal are those of clumsiness in the
   three-stage standards process, and related clumsiness in the clarity
   and useability of IETF standards.  This draft is deliberately short
   on rationale and explanation - the interested reader should study the
   above references and discussions carefully.

2.  Stage 1: Proposed Standard

   This is exactly as described in  [1].

3.  Stage 2: Interoperable Standard

   This is very similar to Draft Standard as described in  [1].  The
   name is changed partly to mark the change, partly because "Draft
   Standard" is sometimes confused with Internet-Draft, and partly to
   emphasise the IETF's value statement of "rough consensus and running
   code."

   The criteria for advancing from Proposed Standard to Interoperable
   Standard are roughly the same as the current criteria for moving to
   Draft Standard.  But two inconveniences in the present
   interoperability requirements have been encountered:
   1.  The objective is to validate that a specification contains only
       features that have been demonstrated to be interoperable.  The
       current text does not make it crystal clear that this, and not
       the availability of conformant implementations, is being
       demonstrated: the essential difference being that all features
       must be interoperable, not that all implementations must be shown
       to support all features.
   2.  The current text requires features that have not been
       demonstrated as interoperable to be removed from the
       specification.  This may cause an RFC to be updated, at a cost of
       many months delay, even if only one or two features have not been
       demonstrated to interoperate.  The proposed new text would also
       allow an RFC to be upgraded without change, even if some features
       had not been proved interoperable, as long as this fact was duly



Carpenter               Expires December 3, 2005                [Page 3]

Internet-Draft                  Two stage                      June 2005


       documented.

   Thus, this paragraph:

   "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."

   would be replaced by:

   "The requirement for at least two independent and interoperable
   implementations applies to each of the options and features of the
   specification considered individually.  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
   Interoperable Standard level only if those options or features are
   removed, or marked as untested for interoperability in a revised
   specification or in an external document."

4.  Stage 3: No stage three

   The final, rare, "Standard" stage is simply abolished.  The
   difference between the second and third stages isn't enough to
   justify the bureaucracy, and there is nothing negative about
   "Interoperable Standard" as the final state.

5.  Timing rules

   The minimum time at "Proposed Standard" would remain at six months.
   The highly theoretical rule about annual review of PS documents after
   two years would be dropped to a recommendation, and no review cycle
   would be mandated for IS documents.

   A discussion point is whether the current practice of heaving a sigh
   of relief after a WG gets its last draft published as PS is correct,
   or whether the process should require the WG to remain active until
   the six months at PS has expired, with a decision point then at which
   the Area Director and the WG Chair(s) decide whether to close the WG
   or start the process of upgrading to IS.

   It is proposed in any case that the six month (and two year) timer
   should start when the IESG approval announcement for a document is
   sent, not when the RFC is published.  As an adjunct to this, approved
   drafts should be parked in a special public directory while they are
   in the RFC queue, so that they are readily available to implementers.



Carpenter               Expires December 3, 2005                [Page 4]

Internet-Draft                  Two stage                      June 2005


6.  IS can reference PS

   Interoperable Standards would be allowed to make normative references
   to Proposed Standards.  The current rule prohibiting "down
   references" is a major cause of stickiness in the publication
   process.  This change would, in theory, allow an Interoperable
   Standard to call out features that have not been formally agreed to
   be demonstrably interoperable.  But it's a matter of common sense -
   if we want to be able to promote PS documents expeditiously, we have
   to allow this form of down reference.  (It is not proposed to allow
   down references to Internet-Drafts.)

7.  The STD designation, and updates

   Presently, an STD designation and number is only given to a document
   (or document set) at the full Standard level.  This can cause extreme
   confusion when a full Standard is technically obsoleted by a Proposed
   Standard.  What is an implementer to do?

   One option is to simply abolish the STD designation, which is little
   used anyway.

   The alternative is to assign the STD designation (and number) to a
   document (or document set) at PS level; if a PS is promoted to IS,
   its STD number goes with it; if an IS is obsoleted by a PS, the STD
   number reverts to the PS.  In any case, this function (assigning
   documents to specific STD designations) would be an IETF (WG or IESG)
   matter and not an RFC Editor action as today.

8.  Transitional arrangements

   On the day these changes enter service, all existing DS and Standard
   RFCs would be automatically reclassified as Interoperable Standard
   RFCs.  Corresponding changes would be made to the RFC Index and
   various features of the RFC Editor site and any other RFC
   repositories displaying the status of RFCs.

   If and only if the STD designation is retained, all existing STD
   designations will be applied as follows:
   1.  If the old Standard has not been obsoleted, it is now an IS with
       the same STD designation.
   2.  If the old Standard has been obsoleted, the STD designation goes
       to the document(s) that obsoleted it, which may be PS, IS or a
       mixture.
   3.  If the old Standard has been updated, the STD designation is
       added to the document(s) that updated it, which may be PS, IS or
       a mixture.




Carpenter               Expires December 3, 2005                [Page 5]

Internet-Draft                  Two stage                      June 2005


   4.  The IESG would designate a team or teams to rapidly classify all
       PS and IS documents not assigned an STD designation by the above
       process into new STD designations.

   (If the STD designation is abolished, these steps would be
   unnecessary, but various cleanings up of the RFC Index and the RFC
   Editor web site would be needed to remove all references to STD.)

9.  Not excluded

   The above changes have been constructed in such a way that they do
   not exclude the notions of WG Snapshots (drafts declared to be in a
   stable state by the WG), Stable Snapshots (drafts declared to be in a
   stable state with IESG agreement) or Internet Standards Documentation
   (ISDs, external descriptors of a set of RFCs as a single
   standard)[3].

10.  Housekeeping

   Obviously, [1] will need considerable editing in addition to the
   above changes, for example to remove the intellectual property
   material which is already obsolete.  Also, [4], which defined the STD
   designation, should be obsoleted.  (Even if the STD designation is
   retained, it should be fully described in the replacement for [1].)

   An unrelated housekeeping item is to clarify that, occasionally, the
   IESG may decide to approve a document for immediate publication as
   Historic (rather than Informational), when it is desired to publish
   it for the record but it is already overtaken by events.

11.  Security Considerations

   This document does not directly affect the security of the Internet.

12.  IANA Considerations

   This document requests no action by the IANA.

13.  Acknowledgements

   A two-stage standards track proposal was made Spencer Dawkins,
   Charlie Perkins and Dave Crocker in 2003, which also contained a
   version of the WG Snapshot proposal.  Another variant including
   Stable Snapshots was made by Scott Bradner in 2004.  Comments on the
   present draft by Spencer Dawkins are gratefully acknowledged.

   This document was produced using the xml2rfc tool[5].




Carpenter               Expires December 3, 2005                [Page 6]

Internet-Draft                  Two stage                      June 2005


14.  Informative References

   [1]  Bradner, S., "The Internet Standards Process -- Revision 3",
        BCP 9, RFC 2026, October 1996.

   [2]  Davies, E., "IETF Problem Statement", RFC 3774, May 2004.

   [3]  Klensin, J. and J. Loughney, "Internet Standards Documentation
        (ISDs)", draft-ietf-newtrk-repurposing-isd-03 (work in
        progress), April 2005.

   [4]  Postel, J., "Introduction to the STD Notes", RFC 1311,
        March 1992.

   [5]  Rose, M., "Writing I-Ds and RFCs using XML", RFC 2629,
        June 1999.


Author's Address

   Brian Carpenter
   IBM
   48 Avenue Giuseppe Motta
   1211 Geneva 2,
   Switzerland

   Email: brc@zurich.ibm.com
























Carpenter               Expires December 3, 2005                [Page 7]

Internet-Draft                  Two stage                      June 2005


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 (2005).  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.




Carpenter               Expires December 3, 2005                [Page 8]