One document matched: draft-farrell-ft-01.txt
Differences from draft-farrell-ft-00.txt
Network Working Group S. Farrell
Internet-Draft Trinity College Dublin
Intended status: Experimental December 3, 2012
Expires: June 6, 2013
A Fast-Track way to Proposed Standard with Running Code
draft-farrell-ft-01
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 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.
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 6, 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 6, 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. Fast-Track Processing . . . . . . . . . . . . . . . . . . . . . 3
3. Fast-Track Rules . . . . . . . . . . . . . . . . . . . . . . . 5
4. Relation to Current Processes . . . . . . . . . . . . . . . . . 6
5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 7
6. Security Considerations . . . . . . . . . . . . . . . . . . . . 7
7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 7
8. Changes . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7
8.1. -00 to -01 . . . . . . . . . . . . . . . . . . . . . . . . 7
9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 8
9.1. Normative References . . . . . . . . . . . . . . . . . . . 8
9.2. Informative References . . . . . . . . . . . . . . . . . . 8
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 8
Farrell Expires June 6, 2013 [Page 2]
Internet-Draft Running Code Fast Track December 2012
1. Introduction
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 [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.
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.
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.
2. Fast-Track Processing
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.
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.
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.
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"
Farrell Expires June 6, 2013 [Page 3]
Internet-Draft Running Code Fast Track December 2012
RFC that aims for Proposed Standard is likely to be a fine candidate.
There is probably no need to refer to [RFC2119] here, but why not:-)
The basic idea is that a WG chair 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] 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.
Other comments can be handled or not, at the authors/editors
discretion.
3. 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.
4. 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.
5. 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.
Farrell Expires June 6, 2013 [Page 4]
Internet-Draft Running Code Fast Track December 2012
3. 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 for fast-track processing.
2. Where there are two or more WG chairs, all need to agree to
fast-track processing.
3. 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.
4. The fast-track process only applies to IETF WG documents that
are intended to become Proposed Standard RFCs.
5. The fast-track process can be used for "bis" RFCs and might well
be quite suitable for those.
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
Farrell Expires June 6, 2013 [Page 5]
Internet-Draft Running Code Fast Track December 2012
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 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.
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.
4. 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 6, 2013 [Page 6]
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 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 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".
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.
5. IANA Considerations
[[To be removed, there aren't any.]]
6. 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:-)
7. Acknowledgements
Thanks to the following folks who provided comments: Brian Carpenter,
Elwyn Davies, Barry Leiba, Hector Santos, Sean Turner, S. Moonesamy,
[[If I left someone out who'd like to be there, please let me know.]]
8. Changes
8.1. -00 to -01
Farrell Expires June 6, 2013 [Page 7]
Internet-Draft Running Code Fast Track December 2012
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.
9. References
9.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>.
9.2. Informative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC3933] Klensin, J. and S. Dawkins, "A Model for IETF Process
Experiments", BCP 93, RFC 3933, November 2004.
Farrell Expires June 6, 2013 [Page 8]
Internet-Draft Running Code Fast Track December 2012
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 6, 2013 [Page 9]
| PAFTECH AB 2003-2026 | 2026-04-24 04:25:40 |