[Docs] [txt|pdf|xml] [Tracker] [Email] [Diff1] [Diff2] [Nits]

Versions: 00 01 02 03

Network Working Group                                         S. Farrell
Internet-Draft                                    Trinity College Dublin
Intended status: Experimental                            January 6, 2013
Expires: July 10, 2013


               A Fast-Track way to RFC with Running Code
                          draft-farrell-ft-03

Abstract

   This memo describes an optional, fast-track way to progress a working
   group document to IESG review.  It is provided as a process
   experiment as defined in RFC 3933 for use when working group chairs
   believe that there is running code that implements a working group
   Internet-Draft.  The motivation is to have the IETF process
   explicitly consider running code, consistent with the IETF's overall
   philosophy of running code and rough consensus.

   In this process all of working group last call, IETF last call, and
   Area Director review are carried out in the same two week period.
   Only comments that meet IESG Discuss criteria need to be addressed
   during this stage, and authors are required to make any changes
   within two weeks.

   This experiment will run for one year.

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 July 10, 2013.

Copyright Notice

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



Farrell                   Expires July 10, 2013                 [Page 1]

Internet-Draft           Running Code Fast Track            January 2013


   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.


Table of Contents

   1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  3
   2.  Running Code . . . . . . . . . . . . . . . . . . . . . . . . .  3
     2.1.  Running Code with this Experiment  . . . . . . . . . . . .  4
   3.  Fast-Track Processing  . . . . . . . . . . . . . . . . . . . .  5
   4.  Guidance and Rules for the Fast-Track Process  . . . . . . . .  6
   5.  Relation to Current Processes  . . . . . . . . . . . . . . . .  8
   6.  IANA Considerations  . . . . . . . . . . . . . . . . . . . . .  9
   7.  Security Considerations  . . . . . . . . . . . . . . . . . . .  9
   8.  Acknowledgements . . . . . . . . . . . . . . . . . . . . . . .  9
   9.  Changes  . . . . . . . . . . . . . . . . . . . . . . . . . . .  9
     9.1.  -02 to -03 . . . . . . . . . . . . . . . . . . . . . . . .  9
     9.2.  -01 to -02 . . . . . . . . . . . . . . . . . . . . . . . . 10
     9.3.  -00 to -01 . . . . . . . . . . . . . . . . . . . . . . . . 10
   10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 10
     10.1. Normative References . . . . . . . . . . . . . . . . . . . 10
     10.2. Informative References . . . . . . . . . . . . . . . . . . 11
   Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 11
























Farrell                   Expires July 10, 2013                 [Page 2]

Internet-Draft           Running Code Fast Track            January 2013


1.  Introduction

   This memo documents a process experiment in accordance with
   [RFC3933].  The purpose of the experiment is to speed up the
   progression of certain working group documents in the latter stages
   of the process.  The decision to use this process experiment will
   rest with the working group chairs backed up by their Area Director,
   and will be dependent on the chairs' belief that there is running
   code for the protocol or protocol extensions described in the draft.

   In summary, this experiment collapses three stages of the publication
   process to run concurrently: working group last call, AD review, and
   IETF last call.  Additionally, the experiment will only require
   issues raised during these three stages to be addressed if they meet
   the IESG's Discuss criteria.  The former is not formally a process
   change, although it is a change to the normal conventions.  The
   latter is a process change and requires this experiment to be run
   under the auspices of [RFC3933].

   It is understood that the savings in time for the end-to-end delivery
   of a proposed standard or experimental RFC may be modest, however,
   the modifications to normal IETF process will also serve as an
   indication of the importance that the IETF places in running code.
   The spirit behind this experiment is that early implementations and
   ongoing development and testing throughout the protocol work can
   significantly improve the quality of a protocol and of its
   specification.

   Fast-track processing will not be suitable for all drafts.  For
   example, a framework draft will not be a good candidate because
   implementations of such documents are not, of themselves,
   interoperable.  In contrast, a "-bis" RFC that aims for Proposed
   Standard or Experimental is likely to be a fine candidate.

   A wiki page at [[URL]] will be used to log experiences with this
   experiment.  The wiki will help with the evaluation of the
   experiment.

   This experiment will run for one year from the date of issue of this
   RFC.  At the end of the year, the IESG will evaluate whether to
   propose a permanent change in the IETF's processes.  If this fast-
   track process is not used, then the experiment will nevertheless have
   produced a result.


2.  Running Code

   Implementations developed during the production of an Internet-draft



Farrell                   Expires July 10, 2013                 [Page 3]

Internet-Draft           Running Code Fast Track            January 2013


   can indicate that a working group has had the opportunity to get
   early confirmation of its engineering choices.

   Sometimes, protocol proposals come from prototype implementations.
   At other times, as protocols are developed implementations are
   developed alongside the documents.  In both of these situations, the
   feedback between the implementation experience -- the running code --
   and the protocol development benefits both the protocol and the
   implementations.

   Protocol developers that have implementations to work with often do
   interoperability testing during the development process.  Such
   testing can involve anything from small-scale, one-on-one testing to
   interoperability events, in person or online.  These uncover bugs in
   implementations, but also often uncover errors, omissions, and lack
   of clarity in the protocols and their specifications.

2.1.  Running Code with this Experiment

   This memo describes a way to fast-track some final stage reviews for
   a working group draft when the working group management and area
   directors believe that the existence of one or more implementations
   serve as a practical review of the engineering choices made by the
   working group.

   This experiment needs an implementation that matches the
   specification contained in the draft.  It is up to the WG chairs and
   responsible AD to satisfy themselves on this point within the normal
   bounds of trust and without any implication about the licensing
   related to an open- or closed-source implementation.  At one end of a
   spectrum the source code of the implementation could be available as
   GPLv3: publishing the code source under a license that permits the
   public at large to read, compile and run it (e.g., under a Free
   Software or Open Source license) removes all ambiguity about the
   existence of the implementation.  At the other end of the spectrum, a
   public statement by an employee of a known vendor, or the publication
   of an interop report from multiple implementers, can give sufficient
   confidence.  In all cases the WG chairs and AD do need to be able to
   say why they consider the implementation is appropriate for fast-
   track processing.

   Note that the existence of an implementation is not sufficient to
   ensure that the draft will automatically pass working group or IETF
   last call, nor that it will receive IESG approval.







Farrell                   Expires July 10, 2013                 [Page 4]

Internet-Draft           Running Code Fast Track            January 2013


3.  Fast-Track Processing

   This section describes the process for fast-track progression of a
   working group draft as a series of changes to [BCP9] processes and
   current IETF practices.

   1.  Any Working Group Last Call (WGLC) or Area Director (AD) review
       (which are routinely done, though not part of the formal [BCP9]
       process) will run in parallel with the two-week IETF Last Call
       (IETF-LC) period.

   2.  The IETF last call announcement message must say that the draft
       in question is following the fast-track process and refer to this
       RFC.  The following boilerplate is suggested:

          This document is being processed using the fast-track process
          described in RFC xxxx.

          [[RFC Editor: please replace xxxx with the number of this RFC
          and remove this note.]]

   3.  The draft itself should note (e.g. in the introduction) that it
       has been fast-track processed and reference this RFC.

   4.  Only comments that would be "DISCUSS-worthy" according to the
       IESG Discuss Criteria [DCRIT] need be handled during last call.
       Other comments can be handled or not, at the authors/editors
       discretion.

   5.  The responsible AD for the WG concerned makes the decision as to
       whether changes are required as a result of review comments, and
       determines whether or not those have been completed.  If
       significant change or extended discussion is required, or if
       changes are not complete within two weeks after the end of fast-
       track last call, then the draft is returned to the WG by the
       responsible AD and the document is withdrawn from the experiment.

   6.  As soon as the responsible AD has confirmed that the authors/
       editors have made any changes required as a result of fast-track
       last-call, then the document should enter IESG review and be
       placed on the next IESG telechat agenda that is more than one
       week in the future.

   7.  Given the reduced time associated with fast-track processing, the
       responsible AD may not have time to carry out sufficient review
       prior to IESG evaluation to be confident in balloting "Yes" for
       the document.  Draft progression during and after IESG review is
       otherwise unaffected, so a "Yes" ballot is needed from some AD.



Farrell                   Expires July 10, 2013                 [Page 5]

Internet-Draft           Running Code Fast Track            January 2013


   8.  If at any point in the fast-track process the responsbile AD does
       not act in a timely fashion then the IESG Secretary should ensure
       that the draft enters IESG evaluation and is scheduled for the
       the soonest IESG telechat that is more than one week after the
       end of the two-week post-IETF LC period.  That is, if the
       responsible AD does not act, then the default action applies
       which is that the draft enters IESG evaluation and is placed on
       the earliest IESG telechat.


4.  Guidance and Rules for the Fast-Track Process

   Some guidance and rules associated with this new fast-track are as
   follows:

   1.   Only a WG chair can choose to propose a draft from her WG that
        is aimed for Proposed Standard or Experimental for fast-track
        processing.

   2.   Where there are two or more WG chairs, all need to agree to
        fast-track processing.

   3.   The WG and responsible AD ought not be surprised by the chairs'
        choice to use the fast-track process, ideally the WG and
        responsible AD ought to be aware that this is the plan from
        early in the development of the draft concerned.

   4.   The fast-track process only applies to IETF WG documents that
        are intended to become Proposed Standard or Experimental RFCs.
        The fast-track process can be used for "bis" RFCs and might well
        be quite suitable for those.

   5.   Working Group Last Call is often used as a tool for the chairs
        to ascertain that there is rough consensus in the working group
        for what's in the draft.  For a fast-tracked document, the
        chairs need to be equally confident about rough consensus.

   6.   An implementation of the draft (ideally open-source) is required
        for fast-track last-call.  If there is no such implementation or
        if the WG chairs and responsible AD are not satisfied of the
        existence of an implementation, then the draft is not suitable
        for this process.  In any case, if the implementation does not
        implement the draft sufficiently closely or does not implement
        all mandatory functions, then the draft is not suitable for this
        process.  This only requires one implementation, not two, and
        the WG chairs and responsible AD decide themselves how much
        validation is required for this.




Farrell                   Expires July 10, 2013                 [Page 6]

Internet-Draft           Running Code Fast Track            January 2013


   7.   An AD can choose to accept the word of a WG chair that the
        implementation is available and sufficiently accurate, or an AD
        might choose to confirm this herself or via a third-party.

   8.   A document can only be proposed on the fast-track once.  That
        is, if the document comes back to the WG after having been
        proposed on the fast-track, then fast-track processing cannot be
        proposed again if that draft is to be progressed subsequently.

   9.   If an IPR declaration happens at any time after a draft has
        started fast-track processing, including after IESG processing,
        then the draft is returned to the WG in all cases and has used
        up its "go" at fast-track processing.  This does represent a
        potential denial of service attack on the draft authors, but it
        is public and can happen already in any case.

   10.  WG chairs ought to provide sufficient notice to the responsible
        AD that they will be using the fast-track last-call process and
        should ensure that the AD has sufficient time to carry out a
        review of the draft during fast-track last call.  However, if
        the responsible AD is not responsive, the the WG chairs should
        go ahead and start the process.

   11.  WG chairs initiate the process described in this document by
        issuing a "Publication Request" through the datatracker or by
        email to the Secretariat.  A shepherd write-up must be supplied
        and must mention the use of this fast-track last-call process
        with reference to this document, and must contain a description
        of the relevant implementation with a pointer where possible.
        Furthermore, the WG chairs must send an email to the responsible
        AD with a clear and unambiguous title such as "Fast Track
        Publication Request Issued for draft-foo" to ensure that the AD
        is aware that the process has started.

   12.  The timers associated with fast-track processing do increase the
        burden on cross-area review teams.  At present such reviews are
        supposed to be done during IETF LC, but some useful reviews are
        not received until after the end of IETF LC.  As is currently
        the case, the responsible AD and IESG will have to deal with
        such reviews as they are received.  In addition, WG chairs can
        in any case ask for early review if desired.  A part of the
        experiment here will be to see if fast-track processing
        significantly impacts on these reviews.

   13.  Arriving at a position where fast-track processing can commence
        may require coding sessions, interop events, or demos.  Where a
        work item is identified on a working group charter as a
        candidate for fast-track processing (e.g. in WG milestone text)



Farrell                   Expires July 10, 2013                 [Page 7]

Internet-Draft           Running Code Fast Track            January 2013


        the working group chairs may request the IESG for room space at
        an IETF meeting in order to advance the status of
        implementations.  Where possible, the IESG and IAOC should
        accommodate such requests within the limitations of other calls
        on meeting space and budgetary issues.

   14.  If the timers (IETF LC or the two-weeks after IETF LC for fixing
        things) co-incide with a major holiday period or IETF meeting
        then the responsible AD can add a week or two as appropriate.
        As this is an experiment we may learn more about good timer
        values as the experiment is run.  WG chairs should be
        accomodating where such timer extensions are chosen by the
        responsible AD.


5.  Relation to Current Processes

   The main effect of this experiment on the formal process is to add
   some timers and default actions, to encourage particular choices and
   to provide a new lever that WG chairs can pull in appropriate
   circumstances.  Mostly, the mechanics are not actually process
   changes, and are already available options:

   o  There is no process requirement for Working Group Last Call.
      Whether and when a working group document is ready for publication
      to be requested is up to the judgment of the working group chairs,
      based on discussion and rough consensus.

   o  The responsible Area Director can decide how much, if any,
      document review to do before requesting Last Call.  An AD who
      wishes to do her review in parallel with Last Call is always free
      to make that choice.

   o  There is no requirement that the responsible AD ballot "Yes",
      though that is current practice.  "The document is being fast-
      tracked," serves as a clear and acceptable explanation in the case
      where the responsible AD chooses not to ballot "Yes" at the start
      of IESG evaluation.

   o  While this experiment seeks to improve outcomes by encouraging
      implementation before a draft becomes an RFC, there is of course
      no requirement for an implementation to exist for a draft to
      become a Proposed Standard or Experimental track RFC and this
      experiment is explicitly not intended to move the IETF process
      towards such a requirement.  This is intended to be and remain an
      optional part of the IETF process, even if the experiment is
      successful.




Farrell                   Expires July 10, 2013                 [Page 8]

Internet-Draft           Running Code Fast Track            January 2013


   o  This memo itself has no impact on appeal processes.  However, in
      considering an appeal that relates to a document that has been
      fast-track processed, the relevant judge (WG chair, AD, IESG or
      IAB as appropriate) should consider the requirements posited here.

   However, incorporating the IESG "DISCUSS" criteria into the IETF
   process as this experiment does, is a change to [BCP9].  It may also
   be the case that having a draft appear on an IESG telechat with no
   area director having reviewed the draft is also a process change.


6.  IANA Considerations

   [[This document makes no requests for IANA action.  This section may
   be removed before publication as an RFC.]]


7.  Security Considerations

   This experiment might create new ways in which IETF particpants can
   game the IETF process.  The mitigation is that this is a time-limited
   experiment so any damage during the experiment will be limted, and
   the IETF will be able to evaluate any such gaming at the end of the
   experiment.


8.  Acknowledgements

   Thanks to the following folks who provided comments: Brian Carpenter,
   Elwyn Davies, Martin Duerst, Ted Hardie, Barry Leiba, Marc Petit-
   Huguenin, Hector Santos, Sean Turner, S. Moonesamy,

   Adrian Farrel carried out a thorough AD review prior to IETF last
   call and suggested many good improvements to the text.

   All silliness, in this draft anyway, of course remains the sole
   responsibility of the author.


9.  Changes

   [[RFC editor: please remove this section before publication.]]

9.1.  -02 to -03

   o  A thorough set of AD review comments were handled.





Farrell                   Expires July 10, 2013                 [Page 9]

Internet-Draft           Running Code Fast Track            January 2013


9.2.  -01 to -02

   o  Fast-track draft can be aiming for experimental as well as PS.

   o  Added text about marking LC and RFC

   o  Added text about a wiki for the experiment.

   o  Did an editorial pass over the lot and added clarifying text
      suggested by various folks

9.3.  -00 to -01

   o  Changed target to experimental RFC.

   o  Added 1 year experimental period.

   o  Clarified that this is just for WG's and only the "responsible AD"
      is discussed.

   o  Clarified that this is just for WGs and PS RFCs, but including
      -bis RFCs.

   o  Added a rule about late IPR declarations.

   o  Added a 2-week timer for authors to make changes after last-call,
      and other changes to try emphasise that speed is important here
      based on offlist comments that there wasn't a significant real
      difference in what might happen during/after last-call compared to
      now.

   o  Noted cross-area review issue.

   o  Added a section about relation to existing process(es).

   o  Various other on and off list comments handled.


10.  References

10.1.  Normative References

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

   [DCRIT]    IESG, "Discuss Criteria in IESG Review", July 2007, <https
              ://www.ietf.org/iesg/statement/discuss-criteria.html>.




Farrell                   Expires July 10, 2013                [Page 10]

Internet-Draft           Running Code Fast Track            January 2013


10.2.  Informative References

   [RFC3933]  Klensin, J. and S. Dawkins, "A Model for IETF Process
              Experiments", BCP 93, RFC 3933, November 2004.


Author's Address

   Stephen Farrell
   Trinity College Dublin
   Dublin,   2
   Ireland

   Phone: +353-1-896-2354
   Email: stephen.farrell@cs.tcd.ie




































Farrell                   Expires July 10, 2013                [Page 11]


Html markup produced by rfcmarkup 1.109, available from https://tools.ietf.org/tools/rfcmarkup/