One document matched: draft-farrell-ft-01.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-01">
<front>
<title abbrev="Running Code Fast Track">A Fast-Track way to Proposed Standard 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 proposes an optional fast-track way to get from a working group
document to IESG review that can be used for cases when a working group chair
believes 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, and to
impose a higher barrier for comments that might block progress. The motivation
is to have the IETF process have a built-in reward for running code, consistent
with the IETF's overall philosophy of running code and rough consensus. This
version is solely proposed by the author (and not the IESG) to attempt to
ascertain if there is enough interest in this to warrant trying out the idea as
an RFC 3933 process experiment.


</t>
</abstract>
</front>

<middle>

<section title="Introduction">

<t>

This is draft is proposed by the author (and not the IESG) to
attempt to ascertain if there is enough interest in this to warrant trying out
the idea as an <xref target="RFC3933"/> experiment. If there is, 
then the experiment will run for one year from the date at which
this becomes an experimental RFC. If the fast-track process is
used in that time, the author intends to provide a summary of 
how that worked so the IETF can decide if it wants to adopt
this process or not. If the fast-track process is not used, then
the experiment has also produced a result, but no reporting is
required in that case.

</t>

<t>

The idea here is not to save the universe, nor to boil any oceans. IETF
working groups (WGs) 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>

</section>

<section title="Fast-Track Processing">


<t>

Sometimes, it can take a long time to get a Proposed Standard
produced in the IETF. This memo proposes an optional way to 
speed up the parts of the process that happen after a WG
has done its job by building a "reward" for having an 
implementation (ideally open-source) available into IETF processes.

</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 need to be met as usual, fast-track
processing merely aims to speed up the decision as to
whether those criteria have been met.

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

</t>

<t>
Fast-track processing will not be suitable for all drafts.
For exmaple, 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 is likely to be a fine
candidate.

</t>


<t>

There is probably no need to refer to <xref target="RFC2119"/>
here, but why not:-)

</t>

<t>

The basic idea is that a WG chair 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"/> apply, and
define the new "fast-track last call" state:

<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 [BCP9] process) will run in
parallel with the two-week IETF Last Call (IETF-LC) period.</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>
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. 

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

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

</list>

</t>

</section>

<section title="Fast-Track Rules">

<t>Some 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 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 should not be surprised by the chairs' choice to
use the fast-track process, ideally the WG 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 RFCs.</t>

<t>The fast-track process can be used for "bis" RFCs and
might well be quite suitable for those.</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 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 "Publicaiton 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>
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>
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.

</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
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
the normal expectation.  "The document is on a fast track," serves as a clear
and acceptable explanation in the case where the AD chooses not to ballot
"Yes".</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>

</section>

<section title="IANA Considerations">

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

</section>

<section title="Security Considerations">

<t>

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

</t>

</section>

<section title="Acknowledgements">

<t>
Thanks to the following folks who provided comments:

Brian Carpenter,
Elwyn Davies,
Barry Leiba,
Hector Santos,
Sean Turner,
S. Moonesamy,

</t>

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

</section>

<section title="Changes">

<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">
&RFC2119;
&RFC3933;
</references>

</back>
</rfc>