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