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