<?xml version="1.0" encoding="US-ASCII"?>
<!DOCTYPE rfc SYSTEM "rfc2629.dtd">
<?rfc toc="yes"?>
<?rfc tocompact="yes"?>
<?rfc tocdepth="3"?>
<?rfc tocindent="yes"?>
<?rfc symrefs="yes"?>
<?rfc sortrefs="yes"?>
<?rfc comments="yes"?>
<?rfc inline="yes"?>
<?rfc compact="yes"?>
<?rfc subcompact="no"?>
<rfc category="bcp" docName="draft-hardie-advance-mechanics-00"
     ipr="trust200902">
  <front>
    <title abbrev="MDTLS">Proposed mechanics for document advancement</title>

    <author fullname="Ted Hardie" initials="Ted" surname="Hardie">
      <organization>Panasonic Wireless Research Lab</organization>

      <address>
        <postal>
          <street>10900 Tantau Ave.</street>

          <city>Cupertino</city>

          <code>95014</code>

          <region>California</region>

          <country>USA</country>
        </postal>

        <phone>+1-408-628-5864</phone>

        <email>ted.ietf@gmail.com</email>
      </address>
    </author>

    <date day="15" month="September" year="2010" />

    <keyword>BCP</keyword>

    <keyword>Draft</keyword>

    <abstract>
      <t>The IETF has maintained a three-stage standards track for some time,
      with basic mechanics set out in <xref target="RFC2026">RFC 2026</xref>.
      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.</t>
    </abstract>

    <note title="Requirements Language">
      <t>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 <xref
      target="RFC2119">RFC 2119</xref>.</t>
    </note>
  </front>

  <middle>
    <section title="Introduction">
      <t>The IETF has maintained a three-stage standards track for some time,
      with basic mechanics set out in <xref target="RFC2026">RFC 2026</xref>.
      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.</t>
    </section>

    <section title="Document processing">
      <t>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.</t>

      <t>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.</t>

      <t>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.</t>
    </section>

    <section title="Mechanics for moving from Proposed to Draft">
      <t>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. A
      "Last Call for Objections to Advancement" must be issued 4 weeks prior
      to advancement. If no objections are received, the document
      advances.</t>

      <t>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.</t>

      <t>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.</t>

      <t>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.</t>
    </section>

    <section title="Guidance for Objections">
      <t>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</t>

      <t>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</t>

      <t>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.</t>
    </section>

    <section title="Mechanics for moving to Full Standard">
<t>
       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. 
</t>
    </section>

    <section title="Workload">
      <t>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.</t>

      <t>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.</t>
    </section>

    <section anchor="IANA" title="IANA Considerations">
      <t>This document makes no request of IANA.</t>
    </section>

    <section anchor="Security" title="Security Considerations">
      <t>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.</t>
    </section>

    <section anchor="Acknowledgements" title="Acknowledgements">
      <t>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.</t>
    </section>
  </middle>

  <back>
    <references title="Normative References">
      <?rfc include="reference.RFC.2119"?>

      <?rfc include="reference.RFC.2026"?>
    </references>

    <references title="Informative References"></references>
  </back>
</rfc>
