Internet DRAFT - draft-farrell-ft
draft-farrell-ft
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]
