One document matched: draft-farrell-ft-03.xml

<?xml version="1.0" encoding="US-ASCII"?>
<!DOCTYPE rfc SYSTEM "rfc2629.dtd" [
<!ENTITY RFC2119 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.2119.xml">
<!ENTITY RFC3933 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.3933.xml">
]>

<?xml-stylesheet type='text/xsl' href='rfc2629.xslt' ?>

<?rfc strict="yes" ?>
<?rfc toc="yes"?>
<?rfc tocdepth="4"?>
<?rfc symrefs="yes"?>
<?rfc sortrefs="yes" ?>
<?rfc compact="yes" ?>
<?rfc subcompact="no" ?>

<rfc category="exp" ipr="trust200902" submissionType="independent" docName="draft-farrell-ft-03">
<front>
<title abbrev="Running Code Fast Track">A Fast-Track way to RFC with Running Code</title>

<author fullname="Stephen Farrell" initials="S." 
surname="Farrell">
<organization>Trinity College Dublin</organization>
<address>
<postal>
<street></street>
<city>Dublin</city>
<region></region>
<code>2</code>
<country>Ireland</country>
</postal>
<phone>+353-1-896-2354</phone>
<email>stephen.farrell@cs.tcd.ie</email>
</address>
</author>

<date/>

<area>IETF</area>

<workgroup>Network Working Group</workgroup>
<keyword>fast-track process</keyword>

<abstract>
<t>

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.

</t>

<t>

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.

</t>

<t>

This experiment will run for one year.

</t>

</abstract>
</front>

<middle>

<section title="Introduction">

<t>

   This memo documents a process experiment in accordance with 
<xref target="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.

</t>
<t>

   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 
<xref target="RFC3933"/>.

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

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

</t>
<t>

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

</t>
<t>

   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.

</t>


<!--
<t>

This draft proposes an 
<xref target="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. 

</t>

<t>

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. 

</t>
-->

<!--
<t>

However, the author thinks that this is taking the IETF in the
right direction and so is worth a look. This approach might also help with
recent cases where smaller open-source software groups have found the IETF
process difficult for various reasons. 

</t>

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

</t>

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

</t>

-->

</section>

<section title="Running Code">

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

</t>
<t>

   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.

</t>
<t>

   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.

</t>

<section title="Running Code with this Experiment">

<t>

   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.

</t>
<t>

   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.

</t>
<t>

   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.

</t>

</section>

<!--

<t>

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. 

</t>

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

<t>

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

</t>

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

</t>

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

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

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

-->

</section>

<section title="Fast-Track Processing">


<t>

   This section describes the process for fast-track progression of a
   working group draft as a series of changes to <xref target="BCP9"/> processes and
   current IETF practices. 

</t>

<!--

<t>

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

</t>

<t>

When a document is being progressed on the fast-track, the
following changes from <xref target="BCP9"/> and current
IETF practices apply, and
define the new "fast-track last call" state:

</t>

-->

<t>
<list style="numbers">

<t>Any Working Group Last Call (WGLC) or Area Director (AD) review (which are
routinely done, though not part of the formal <xref target="BCP9"/> process) will run in
parallel with the two-week IETF Last Call (IETF-LC) period.</t> 

<t>
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:
<list style="empty">
<t>
          This document is being processed using the fast-track process
          described in RFC xxxx.
</t>
<t>
       [[RFC Editor: please replace xxxx with the number of this RFC and
        remove this note.]]
</t>
</list>
</t>
<t>The draft itself should note (e.g. in the introduction) 
that it has been fast-track processed and reference this
RFC. </t>

<t>Only comments that would be "DISCUSS-worthy" according to the IESG Discuss
Criteria <xref target="DCRIT"/> need be handled during last call. Other
comments can be handled or not, at the authors/editors discretion.</t>

<!--

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

-->

<t>

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.

</t>

<!--

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

-->

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

<t>

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.

</t>

<t>

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.

</t>

</list>

</t>

</section>

<section title="Guidance and Rules for the Fast-Track Process">

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

<list style="numbers">

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

<t>Where there are two or more WG chairs, all need to agree
to fast-track processing.</t>

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

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

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

<!--

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

-->

<t>

 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.

</t>

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

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

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

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


<!--

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

-->

<t>

 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.

</t>

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

<!--

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

-->

<t>

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

</t>

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

</t>

</list>

</t>

</section>

<section title="Relation to Current Processes">

<t>

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:

</t>

<t>
<list style="symbols">

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

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

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

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

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

</t>

</list>
</t>

<t>

However, incorporating the IESG "DISCUSS" criteria
into the IETF process as this experiment does, is a
change to <xref target="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.

</t>



</section>

<section title="IANA Considerations">

<t>

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

</t>

</section>

<section title="Security Considerations">

<t>

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.

</t>

</section>

<section title="Acknowledgements">

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

</t>

<t>

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

</t>

<t>All silliness, in this draft anyway, of course remains the 
sole responsibility of the author.</t>

</section>

<section title="Changes">

<t>[[RFC editor: please remove this section before publication.]]</t>

<section title="-02 to -03">

<t>
<list style="symbols">
<t>A thorough set of AD review comments were handled.</t>

</list>
</t>

</section>

<section title="-01 to -02">

<t>
<list style="symbols">

<t>Fast-track draft can be aiming for experimental as well as PS.</t>

<t>Added text about marking LC and RFC</t>

<t>Added text about a wiki for the experiment.</t>

<t>Did an editorial pass over the lot and added clarifying text suggested
by various folks</t>

</list>
</t>


</section>

<section title="-00 to -01">

<t>
<list style="symbols">

<t>Changed target to experimental RFC.</t>

<t>Added 1 year experimental period.</t>

<t>Clarified that this is just for WG's and
only the "responsible AD" is discussed.</t>

<t>Clarified that this is just for WGs and
PS RFCs, but including -bis RFCs.</t>

<t>Added a rule about late IPR declarations.</t>

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

<t>Noted cross-area review issue.</t>

<t>Added a section about relation to existing
process(es).</t>

<t>Various other on and off list comments
handled.</t>

</list>
</t>


</section>

</section>


</middle>

<back>
<references title="Normative References">

      <reference anchor='BCP9'>
          <front>
<title abbrev='Internet Standards Process'>The Internet Standards Process -- Revision 3</title> <author initials='S.' surname='Bradner' fullname='Scott O. Bradner'/>
            <date year='1996' month='October' />
          </front>
          <seriesInfo name='BCP' value='9' />
          <seriesInfo name='RFC' value='2026' />
          <seriesInfo name='RFC' value='6410' />
      </reference>

	<reference anchor="DCRIT"
		target="https://www.ietf.org/iesg/statement/discuss-criteria.html">
		<front> <title>Discuss Criteria in IESG Review</title>
			<author surname="IESG" fullname="The IESG"/>
			<date year="2007" month="July" />
		</front>
	</reference>

</references>

<references title="Informative References">
&RFC3933;
</references>

</back>
</rfc>