Network Working Group S. Farrell
Internet-Draft Trinity College Dublin
Intended status: Standards Track December 1, 2012
Expires: June 4, 2013
A Fast-Track way to Proposed Standard with Running Code
draft-farrell-ft-00
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 open-source 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
offer a reward for running code, consistent with the IETF's overall
philosophy of running code and rough consensus. This version is an
initial draft 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 4, 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
Provisions Relating to IETF Documents
Farrell Expires June 4, 2013 [Page 1]
Internet-Draft Running Code Fast Track December 2012
(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 . . . . . . . . . . . . . . . . . . . . . . . 4
4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 5
5. Security Considerations . . . . . . . . . . . . . . . . . . . . 5
6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 5
7. References . . . . . . . . . . . . . . . . . . . . . . . . . . 5
7.1. Normative References . . . . . . . . . . . . . . . . . . . 5
7.2. Informative References . . . . . . . . . . . . . . . . . . 5
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 5
Farrell Expires June 4, 2013 [Page 2]
Internet-Draft Running Code Fast Track December 2012
1. Introduction
This is an initial draft 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 [RFC3933] experiment.
The idea here is not to save the universe, nor to boil any oceans.
WG's are still liable to sometimes take years to get to the point
where this "fastrack" might apply. 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 working group (WG) has
done its job as a "reward" for having an open-source implementation
available at that time.
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. Working group last call (WGLC), IETF last call (IETF-LC) and Area
Director (AD) review all run in parallel over the same two-week
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. After fast-track last-call, the document must either be returned
to the WG, or else enter IESG review as soon as any changes
required are made. The relevant AD makes the decision as to
whether changes are required and when those are completed
sufficiently to move to the next stage.
Farrell Expires June 4, 2013 [Page 3]
Internet-Draft Running Code Fast Track December 2012
4. As soon as the authors/editors have made any changes required as
a result of fast-track last-call, then the document will enter
IESG review and will be automatically placed on the next IESG
telechat agenda.
5. Given the fast-track processing, the relevant AD is not expected
to (but of course can) ballot "Yes" for the document. Draft
progression after IESG review is otherwise unaffected, so a "Yes"
ballot is needed from some AD.
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 working
group 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. An open-source implementation of the draft 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. Note: this only requires one implementation, not two.
4. 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.
5. 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 normal processing must be used if that
draft is to be progressed subsequently.
6. WG chairs ought to provide sufficient notice to the relevant 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.
7. This one is not a "rule" but where a WG chair indicates 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
Farrell Expires June 4, 2013 [Page 4]
Internet-Draft Running Code Fast Track December 2012
to get the document to the point where fast-track processing can
be done, which implies helping the WG with efforts to develop the
open-source implementation required.
4. IANA Considerations
[[To be removed, there aren't any.]]
5. 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:-)
6. Acknowledgements
Sean Turner provided some useful changes to an earlier version.
[[More later is this is dead-on-arrival.]]
7. References
7.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>.
7.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 4, 2013 [Page 5]
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 4, 2013 [Page 6]