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

Versions: 00 01 02 03

Network Working Group                                         S. Farrell
Internet-Draft                                    Trinity College Dublin
Intended status: Experimental                          December 14, 2012
Expires: June 17, 2013


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

Abstract

   This memo proposes an optional fast-track way to get from a working
   group document to IESG review that can be used for cases when working
   group chairs believe that there is running code that implements a
   working group Internet-Draft.  The basic idea is to do all of working
   group last call, IETF last call and area director review during the
   same two week period, to impose a higher barrier for comments that
   might block progress, and to require prompt action by authors in
   processing any changes arising from IETF last call.  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.  The intent is to run an RFC 3933 process experiment
   to test out this approach.  [[This draft is proposed by the author
   and not the IESG.]]

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 June 17, 2013.

Copyright Notice

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

   This document is subject to BCP 78 and the IETF Trust's Legal



Farrell                   Expires June 17, 2013                 [Page 1]


Internet-Draft           Running Code Fast Track           December 2012


   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
   3.  Fast-Track Processing  . . . . . . . . . . . . . . . . . . . .  4
   4.  Fast-Track Rules . . . . . . . . . . . . . . . . . . . . . . .  5
   5.  Relation to Current Processes  . . . . . . . . . . . . . . . .  7
   6.  IANA Considerations  . . . . . . . . . . . . . . . . . . . . .  8
   7.  Security Considerations  . . . . . . . . . . . . . . . . . . .  8
   8.  Acknowledgements . . . . . . . . . . . . . . . . . . . . . . .  8
   9.  Changes  . . . . . . . . . . . . . . . . . . . . . . . . . . .  9
     9.1.  -01 to -02 . . . . . . . . . . . . . . . . . . . . . . . .  9
     9.2.  -00 to -01 . . . . . . . . . . . . . . . . . . . . . . . .  9
   10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 10
     10.1. Normative References . . . . . . . . . . . . . . . . . . . 10
     10.2. Informative References . . . . . . . . . . . . . . . . . . 10
   Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 10



























Farrell                   Expires June 17, 2013                 [Page 2]


Internet-Draft           Running Code Fast Track           December 2012


1.  Introduction

   [[Comments and things to change in obvious ways are in double-square
   brackets like this.]]

   This draft proposes an [RFC3933] experiment to try help speed up the
   latter stages of some working group document and to improve quality
   indirectly thanks to the existence of running code.

   The idea here is not to save the universe, nor to boil any oceans.
   IETF working groups are still liable to sometimes take years to get
   to the point where this "fastrack" might apply.  So the overall
   saving in time may be modest.

   This experiment will run for one year from the date of issue of this
   RFC.

   We have established a wiki page at [[URL]] where experiences with
   this experiment can be recorded as the experiment runs.  The goal of
   that is to help with the evaluation of the experiment as it runs and
   at the end.  If the fast-track process is not used, then the
   experiment has also produced a result, and the wiki page will be
   fairly boring.


2.  Running Code

   Implementations developed during the production of an Internet-draft
   can indicate that a working group has had the opportunity to get
   early confirmation of its engineering choices.  This memo proposes an
   optional way to parallel process some final stage reviews when the
   working group management and area directors believe that the
   implementation can itself serve as a practical review of the
   engineering choices.

   Note that the existence of an open-source or other implementation is
   not by itself sufficient to ensure that the draft will pass IETF
   last-call or IESG review.  All other criteria for Proposed Standard
   or Experimental need to be met as usual.

   Note also that this experiment just needs an implementation that
   makes it possible for the WG chairs and responsible AD to verify (to
   the extent they choose) that the implementation matches the draft.
   There is no implication at all about the licensing related to an
   open- or closed-source implementation.  At one end of a spectrum it
   could be GPLv3, at another end, it could be code that's only made
   available on request.  This can ideally and perhaps most easily be
   achieved by publishing the code source under a license that permits



Farrell                   Expires June 17, 2013                 [Page 3]


Internet-Draft           Running Code Fast Track           December 2012


   the public at large to read, compile and run it, e.g. under a Free
   Software or Open Source license.  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.

   Fast-track processing will not be suitable for all drafts.  For
   example, a framework draft where an implementation won't by itself
   interoperate is probably not a good candidate.  In contrast, a "-bis"
   RFC that aims for Proposed Standard or Experimental is likely to be a
   fine candidate.

   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.

   While this proposal does not require that efforts be that ambitious,
   this is the spirit behind it: that early implementations and ongoing
   development and testing throughout the protocol work can
   significantly improve the quality of a protocol and of its
   specification.


3.  Fast-Track Processing

   The basic idea is that Working Group (WG) chairs can choose to
   progress a WG draft on the "fast-track" in some circumstances.

   When a document is being progressed on the fast-track, the following
   changes from [BCP9] and current IETF practices apply, and define the
   new "fast-track last call" state:

   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.  Only comments that would be "DISCUSS-worthy" according to the
       IESG Discuss Criteria [DCRIT] need be handled during last call.



Farrell                   Expires June 17, 2013                 [Page 4]


Internet-Draft           Running Code Fast Track           December 2012


       Other comments can be handled or not, at the authors/editors
       discretion.

   3.  Authors need to make any changes required within two weeks of the
       end of IETF-LC.  If not, then the document is returned to the WG.

   4.  The document must either be returned to the WG, or else enter
       IESG review within two weeks of the end of fast-track last-call.
       The responsible AD for the WG concerned makes the decision as to
       whether changes are required and whether or not those have been
       completed.  If significant change or extended discussion is
       required or changes are not complete within two weeks after the
       end of fast-track last call, then the draft should be returned to
       the WG by the responsible AD.  If the responsbile AD does not act
       at the end of this two week period, then the IESG Secretary
       should ensure that the draft enters IESG evaluation and is
       scheduled for the next relevant telechat.

   5.  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.  Again, this should happen within two weeks
       of the end of fast-track last-call in the case where the document
       is not returned to the WG.

   6.  Given the fast-track processing, the responsible AD is not
       expected to (but of course can) ballot "Yes" for the document.
       Draft progression during and after IESG review is otherwise
       unaffected, so a "Yes" ballot is needed from some AD.

   7.  The IETF last call announcement message should say that the draft
       in question is following the fast-track process and refer to this
       RFC.

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


4.  Fast-Track Rules

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





Farrell                   Expires June 17, 2013                 [Page 5]


Internet-Draft           Running Code Fast Track           December 2012


   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 implementation or if
        the implementation is unavailable or does not implement the
        draft sufficiently closely then the document needs to be
        returned to the WG.  This only requires one implementation, not
        two, and the WG chairs and responsible AD decide themselves how
        much validation is required for this.

   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.



Farrell                   Expires June 17, 2013                 [Page 6]


Internet-Draft           Running Code Fast Track           December 2012


   11.  WG chairs initiate the process by sending a mail to the IESG-
        secretariat with the usual "Publication Requested" materials,
        but also highlighting that the fast-track last-call process is
        being triggered.  That mail also ought also contain a pointer to
        the relevant implementatation.  The responsible AD should also
        be copied on this message.

   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.  This one is not a "rule" but where a WG chair indicates in
        advance (e.g. in WG milestone text) that a work item is planned
        for fast-track processing, then the IESG and IAOC ought to try
        to accomodate requests for space and other logistics to support
        this at IETF meetings.  Of course, what is possible will depend
        on the venue and on resources available and required, but the
        goal of the IETF ought be to try to help the WG to get the
        document to the point where fast-track processing can be done,
        which implies helping the WG with efforts to develop such an
        implementation (ideally open-source) if that is how the WG have
        chosen to proceed.

   14.  Another "non-rule": 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:






Farrell                   Expires June 17, 2013                 [Page 7]


Internet-Draft           Running Code Fast Track           December 2012


   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.

   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.


6.  IANA Considerations

   [[To be removed, there aren't any.]]


7.  Security Considerations

   Since this is proposed by a security AD something is clearly needed
   here.  A WG chair and author could collude to launch an attack on the
   WG's AD by proposing a draft with code containing a trojan.  Not much
   fun or profit for anyone there though:-)


8.  Acknowledgements

   Thanks to the following folks who provided comments: Brian Carpenter,
   Elwyn Davies, Martin Duerst, Ted Hardie, Barry Leiba, Marc Petit-



Farrell                   Expires June 17, 2013                 [Page 8]


Internet-Draft           Running Code Fast Track           December 2012


   Huguenin, Hector Santos, Sean Turner, S. Moonesamy,

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

   [[If I left someone out who'd like to be there, please let me know.]]


9.  Changes

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

9.1.  -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.2.  -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).





Farrell                   Expires June 17, 2013                 [Page 9]


Internet-Draft           Running Code Fast Track           December 2012


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

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 June 17, 2013                [Page 10]


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