Network Working Group                                        Ted. Hardie
Internet-Draft                           Panasonic Wireless Research Lab
Intended status: BCP                                  September 15, 2010
Expires: March 19, 2011


              Proposed mechanics for document advancement
                   draft-hardie-advance-mechanics-00

Abstract

   The IETF has maintained a three-stage standards track for some time,
   with basic mechanics set out in RFC 2026 [RFC2026].  The mechanics as
   described, however, are not currently used in practice and
   advancement along the standards track is both unusual and more
   difficult than many IETF participants find reasonable.  This document
   proposes an update to those mechanics, in the interest of improving
   the overall functioning of the IETF.  It is compatible with, but does
   not require, a move to a two-stage standards track.

Requirements Language

   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
   "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
   document are to be interpreted as described in RFC 2119 [RFC2119].

Status of this Memo

   This Internet-Draft is submitted in full conformance with the
   provisions of BCP 78 and BCP 79.

   Internet-Drafts are working documents of the Internet Engineering
   Task Force (IETF).  Note that other groups may also distribute
   working documents as Internet-Drafts.  The list of current Internet-
   Drafts is at http://datatracker.ietf.org/drafts/current/.

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

   This Internet-Draft will expire on March 19, 2011.

Copyright Notice

   Copyright (c) 2010 IETF Trust and the persons identified as the
   document authors.  All rights reserved.




Hardie                   Expires March 19, 2011                 [Page 1]


Internet-Draft                    MDTLS                   September 2010


   This document is subject to BCP 78 and the IETF Trust's Legal
   Provisions Relating to IETF Documents
   (http://trustee.ietf.org/license-info) in effect on the date of
   publication of this document.  Please review these documents
   carefully, as they describe your rights and restrictions with respect
   to this document.  Code Components extracted from this document must
   include Simplified BSD License text as described in Section 4.e of
   the Trust Legal Provisions and are provided without warranty as
   described in the Simplified BSD License.


Table of Contents

   1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . . . 3
   2.  Document processing . . . . . . . . . . . . . . . . . . . . . . 3
   3.  Mechanics for moving from Proposed to Draft . . . . . . . . . . 3
   4.  Guidance for Objections . . . . . . . . . . . . . . . . . . . . 4
   5.  Mechanics for moving to Full Standard . . . . . . . . . . . . . 5
   6.  Workload  . . . . . . . . . . . . . . . . . . . . . . . . . . . 5
   7.  IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 5
   8.  Security Considerations . . . . . . . . . . . . . . . . . . . . 5
   9.  Acknowledgements  . . . . . . . . . . . . . . . . . . . . . . . 5
   10. References  . . . . . . . . . . . . . . . . . . . . . . . . . . 6
     10.1.  Normative References . . . . . . . . . . . . . . . . . . . 6
     10.2.  Informative References . . . . . . . . . . . . . . . . . . 6
   Author's Address  . . . . . . . . . . . . . . . . . . . . . . . . . 6

























Hardie                   Expires March 19, 2011                 [Page 2]


Internet-Draft                    MDTLS                   September 2010


1.  Introduction

   The IETF has maintained a three-stage standards track for some time,
   with basic mechanics set out in RFC 2026 [RFC2026].  The mechanics as
   described, however, are not currently used in practice and
   advancement along the standards track is both unusual and more
   difficult than many IETF participants find reasonable.  This document
   proposes an update to those mechanics, in the interest of improving
   the overall functioning of the IETF by aligning advancement along the
   standards track with the current document processing model.


2.  Document processing

   In practice, IETF document processing has evolved to a model which
   can be described as "objection based processing".  A document put
   forward by an author team advances from the relevant working group to
   IETF consideration after all objections from within the working group
   have been considered.  The IETF Last Call is, in practice, a way for
   the larger community to object to a document or elements within it.
   IESG document processing is, fundamentally, a process by which a
   sponsor resolves any objections raised by other area directors;
   though the term used is "discuss" and some delegation occurs (to
   document shepherds or review teams), the basic model is clear.

   This document proposes using this model for the advancement of
   documents along the standards track.  Rather than requiring specific
   actions to advance, it proposes instead to test for objections to
   advancement at specific intervals.  Documents for which no objections
   to advancement are present or for which the objections can be met
   advance.  Those that have objections that cannot be met must be
   revised and re-issued at the baseline level before they can advance.

   While this might seem to run the risk of advancing documents too
   early, in practice the current methods for assessing Proposed
   standards are sufficiently stringent that they match earlier Draft
   reasonably well.  It is also relatively clear that the energy to
   object can always be found in the IETF, even when the energy to
   sponsor or shepherd a document is absent.  By using objection based
   processing with auto advancement, we move with, rather than against,
   the methods currently at the heart of IETF mechanics.


3.  Mechanics for moving from Proposed to Draft

   All documents which are published as Proposed Standard RFCs shall be
   entered in queue for advancement to Draft Standard, with automatic
   advancement to take place two years from the issue date of the RFC.



Hardie                   Expires March 19, 2011                 [Page 3]


Internet-Draft                    MDTLS                   September 2010


   A "Last Call for Objections to Advancement" must be issued 4 weeks
   prior to advancement.  If no objections are received, the document
   advances.

   If objections are received, the IESG issues a call for a document
   shepherd willing to work for resolution of the objections and
   advancement.  If no document shepherd comes forward, the objections
   are automatically sustained and the document remains at Proposed
   Standard.  If more than one volunteer steps forward, the relevant
   area directors select from among them.  An Area Director may serve as
   shepherd for advancement, but there is no requirement that the AD do
   so.  If a document shepherd is available, he or she works to resolve
   the objections.

   If the objections are withdrawn, the document gets a new "Last Call"
   and then moves forward as above.  If they are not withdrawn, the
   document shepherd may request consideration by the IESG of whether
   the objections merit holding the document at Proposed.  If the IESG
   sustains the objections, the document remains at Proposed.  If the
   IESG is in favor of advancement, the document advances.  This is
   subject to appeal per the usual process.

   If a new document must be prepared to meet the objections, it must
   recycle at Proposed Standard and the clock for automatic advancement
   starts again.


4.  Guidance for Objections

   Those who are entering errata for a published RFC should indicate
   whether they believe the issue raised is sufficient to block
   advancement.  The collected errata which have been so flagged are
   considered as objections at the Last Call period.  Auto-posting of
   these as a response to the "Last Call" for Objections to Advancement
   might be worthwhile, in order to indicate the issues already raised
   to others considering objections

   Objections based on ongoing work to prepare a replacement document
   should generally be upheld, especially when that work is taking place
   within an IETF working group, but they are not automatic

   Objections must be sent to the IETF main list in response to the last
   call if they are not listed errata.  Any individual who has been
   banned from the IETF main list may not post an objection, and
   repeated frivolous objections should be considered grounds for
   removal of posting rights.





Hardie                   Expires March 19, 2011                 [Page 4]


Internet-Draft                    MDTLS                   September 2010


5.  Mechanics for moving to Full Standard

   The mechanics for moving to Full are the same as those for moving to
   Draft, except that the clock runs for five years from the initial
   publication as Proposed Standard.


6.  Workload

   The current system is effectively a single-stage standards process
   for almost all documents.  Any proposal to restore a multi-stage
   standards process adds to the workload of those involved in the
   document processing.  This proposal attempt to manage that workload
   by allowing documents with no objections to pass without further
   effort.  It also attempts to spread the load of managing objections
   to the community, by using document shepherds from outside the IESG
   in the common case.  If no document shepherd from the community is
   available, documents do stall, but this is a feature, not a bug.  If
   there are objections to advancement and no one willing to counter
   them or work through them, community disinterest should be taken as
   upholding the objection.

   It would be possible to combine this procedure with a reduction in
   the number of standards levels.  This would further reduce the
   workload if the advancement from stage two to stage three attracts
   significant objections.


7.  IANA Considerations

   This document makes no request of IANA.


8.  Security Considerations

   This document has no direct implications for protocol security.  If
   the broader Internet community is judging protocol maturity based on
   standards level, there is some risk that changing the mechanism by
   which documents advance along the standards track may require that
   judgement to change.


9.  Acknowledgements

   Jon Peterson, Russ Housley, and April Marine were kind enough to read
   a draft of this document.  Their good nature should not be taken as
   supporting this proposal however, and all errors are the
   responsibility of the author.



Hardie                   Expires March 19, 2011                 [Page 5]


Internet-Draft                    MDTLS                   September 2010


10.  References

10.1.  Normative References

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

   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
              Requirement Levels", BCP 14, RFC 2119, March 1997.

10.2.  Informative References


Author's Address

   Ted Hardie
   Panasonic Wireless Research Lab
   10900 Tantau Ave.
   Cupertino, California  95014
   USA

   Phone: +1-408-628-5864
   Email: ted.ietf@gmail.com




























Hardie                   Expires March 19, 2011                 [Page 6]