Network Working Group G. Huston Internet-Draft Telstra Expires: April 25, 2003 M. Rose Dover Beach Consulting, Inc. October 25, 2002 A Proposal to Improve IETF Productivity draft-huston-ietf-pact-00 Status of this Memo This document is an Internet-Draft and is in full conformance with all provisions of Section 10 of RFC2026. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet- Drafts. 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." The list of current Internet-Drafts can be accessed at http:// www.ietf.org/ietf/1id-abstracts.txt. The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. This Internet-Draft will expire on April 25, 2003. Copyright Notice Copyright (C) The Internet Society (2002). All Rights Reserved. Abstract The IETF standards process must exhibit four qualities (Predictability, Accountability, Competency, and Timeliness), which we term "the IETF Pact". Growth in the IETF's size and diversity challenges its ability to make progress in producing useful specifications. This proposal puts forward procedural changes that will improve the IETF PACT, without altering the IETF's philosophy or structure, and without requiring changes to the formal IETF standards process (cf., RFC 2026 [1]). Huston & Rose Expires April 25, 2003 [Page 1] Internet-Draft The IETF Pact October 2002 Table of Contents 1. The Problem . . . . . . . . . . . . . . . . . . . . . . . . 3 2. The IETF "PACT" . . . . . . . . . . . . . . . . . . . . . . 4 3. Working Group Operation . . . . . . . . . . . . . . . . . . 5 3.1 The "Utility Focus" model for WGs . . . . . . . . . . . . . 5 3.2 The "Short-term" model for WGs . . . . . . . . . . . . . . . 5 4. IETF Operation . . . . . . . . . . . . . . . . . . . . . . . 6 4.1 The "Area Focus" model for the IESG . . . . . . . . . . . . 6 4.1.1 Bounded Discussion . . . . . . . . . . . . . . . . . . . . . 6 4.1.2 Proportional Voting . . . . . . . . . . . . . . . . . . . . 7 4.1.3 Vote Explanations . . . . . . . . . . . . . . . . . . . . . 7 4.1.4 Status Reporting . . . . . . . . . . . . . . . . . . . . . . 8 4.2 The "Bounded Outcome" model for the IETF . . . . . . . . . . 8 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . 9 6. Security Considerations . . . . . . . . . . . . . . . . . . 10 References . . . . . . . . . . . . . . . . . . . . . . . . . 11 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . 11 A. Summary of Proposed Rules . . . . . . . . . . . . . . . . . 12 Full Copyright Statement . . . . . . . . . . . . . . . . . . 13 Huston & Rose Expires April 25, 2003 [Page 2] Internet-Draft The IETF Pact October 2002 1. The Problem Growth in the IETF's size and diversity challenge its ability to make progress in producing useful specifications. For example, Working Group (WG) efforts often take far too long, and the result of those efforts is sometimes not very useful to the Internet community. These difficulties are sometimes exacerbated by IESG procedures that introduce further delay and ambiguity to the process. This memo proposes seven procedural changes that will improve the Predictability, Accountability, Competency and Timeliness of the IETF ("the IETF Pact"), without altering the IETF's philosophy or structure, and without requiring changes to the formal IETF standards process (cf., RFC 2026 [1]). Huston & Rose Expires April 25, 2003 [Page 3] Internet-Draft The IETF Pact October 2002 2. The IETF "PACT" The IETF standards process must exhibit four qualities: Predictability: IETF efforts must not waste time and energy. For example, if the responsible AD has any issue with a Working Group (WG) document, these should be known to the WG long before the document is submitted to the IESG. IESG procedures for documents must be clear and consistent, and the status and progress of documents through the procedures must be visible to all. At any point, it must be clear what the next step is for a document and when that step will be taken. Accountability: Those holding IETF management positions necessarily wield considerable power and the IETF community needs to be able to know who has wielded it and when. Competency: The process must encourage the production of technically competent output; otherwise, we are left with a fair, expeditious, but useless process. Timeliness: Timeliness relates to relevance and quality and, as such, the IETF's work is sensitive to real-world needs. If the IETF process takes too long, the results will be irrelevant and other, less engineered solutions will emerge. Ultimately then, the Internet community will be less dependent on the IETF's work. Finally, longer WG processes often lead to work with less focus and clarity, and the resulting technical specifications are often confusing and laden with questionable features. This makes them more difficult to implement correctly and, again, less likely to have real-world utility. We now present a set of proposed changes to the way the IETF manages its working groups. Each change is presented in two parts: o a philosophy or rational for a change in the IETF's behavior; and, o a corresponding rule to be employed by the IESG. Finally, Appendix A summarizes the proposed rules. In considering these proposals, please keep in mind that the changes being presented do not change the way in which areas are managed according to RFC 2026 [1]; rather these are changes to the IESG management model, which the standards process purposefully leaves to the discretion of the IESG. Huston & Rose Expires April 25, 2003 [Page 4] Internet-Draft The IETF Pact October 2002 3. Working Group Operation An IETF working group is for engineering, rather than research or general discussion. Hence a WG must understand what problem it is solving, who will use the solution and how it will be used, and the WG must make near-term progress towards that solution. 3.1 The "Utility Focus" model for WGs An IETF working group charter is characterized as a contract between the WG and the IETF. As the IETF has grown larger and more diverse, and as the problems tackled by WGs have grown more ambitious, charters have sometimes become too vague to provide adequate guidance about the goals and scope of the WG. Accordingly, a WG charter must explicitly state: o what problems are to be solved or what specific benefits are intended from the work to be done; o who the intended beneficiaries are (also describing some examples of the use and effect that will accrue from using the capabilities provided by the WG's output); and, o where areas of difficulty are likely to be encountered. 3.2 The "Short-term" model for WGs If an effort requires more than 1.5 years to produce something that is ready for IETF last call, then it is not yet ready for the IETF. The effort must do its pre-standards work elsewhere and then come to the IETF when a solution is ready to be standardized. Accordingly, a WG gets no more than 18 months to have their first Internet-Draft (I-D) approved by the IESG; similarly, a WG gets no more than 12 months to have each succeeding document approved by the IESG. Huston & Rose Expires April 25, 2003 [Page 5] Internet-Draft The IETF Pact October 2002 4. IETF Operation The IESG must juggle two extremely difficult tasks: o technical oversight; and, o process management. It is essential to retain and support both of these tasks, while also balancing the need to make timely progress. After a document is given to the IESG for approval it can be difficult to ascertain the document's status and how it got there. The procedures that the IESG uses for voting are not well known, and the reasoning behind the IESG's votes are not published. Further, some of the procedures may result in a document being delayed, even if there is a strong consensus in the IESG for it to go forward. As a result, WG chairs and document editors often find themselves in "limbo", where they don't know what to do to move documents through the IETF system. Two complimentary changes can remedy the problem: o a greater emphasis on area focus; and, o a narrower emphasis on what gets evaluated during IETF last call. 4.1 The "Area Focus" model for the IESG Each area comprises considerable specialization. Although it is essential to have coordination and collaboration among the areas, it is equally important that the WGs in an area be allowed to focus on their own activities and have their consensus results published. Our philosophy is that whenever the IESG makes any decisions, all ADs get a voice, but no one AD gets a veto. In realizing this, several factors must be balanced. 4.1.1 Bounded Discussion It is essential that no AD be able to exercise a "pocket veto". Hence there needs to be a way, within the IESG, to override blockages by individual ADs. Accordingly, once a document is submitted to the IESG for approval, a formal request for further discussion may delay IESG voting on the document until no later than the next IESG meeting. (In other words, Huston & Rose Expires April 25, 2003 [Page 6] Internet-Draft The IETF Pact October 2002 there may be at most one request for discussion for the document and any AD may request it.) 4.1.2 Proportional Voting Responsible ADs are presumed to be expert in the work under review, both in terms of the technology and their WGs' history. In order to facilitate the efficiency of their work, they must have a disproportionate say in progressing a document. Accordingly, all IESG votes require a minimum of 55% of those voting "yes" to pass; further, the votes of the responsible ADs are weighted to 45% of all votes, with the remaining ADs combining to 55% of all votes. The voting proportions give extra weight to the votes of the Responsible ADs, but permit the remainder of the IESG to override them. For example, let's assume that there are 13 ADs voting and that 2 ADs are responsible for an area: if the two responsible ADs then passage requires ============================= ================================ both vote yes at least 2 other ADs to vote yes both vote no all other ADs to vote yes split (one yes, the other no) at least 7 other ADs to vote yes For example, if both routing ADs vote "yes", then it takes most of the other ADs voting "no" to defeat an action in the routing area. Naturally, the usual checks-and-balances apply, e.g., if an IESG member disapproves of an IESG action, they (like any other IETF member) are free to appeal to the IAB. 4.1.3 Vote Explanations In order to give WGs a constructive path towards resolving AD concerns, a WG must know precisely what those concerns are. Requiring publication of IESG rationale for rejecting a document helps ensure IESG accountability when a rejection occurs. Accordingly, if an IESG vote rejects a WG document, then the IESG must publish an explanation prior to the next IESG meeting. If no report is published in that timeframe, then the document is automatically approved. Huston & Rose Expires April 25, 2003 [Page 7] Internet-Draft The IETF Pact October 2002 4.1.4 Status Reporting WG documents do not materialize out of the ether -- WGs are granted charters by the IESG, and work under the guidance of an AD when producing their documents. As such, the IESG's decision process should presume a timely, favorable outcome for WG output. Accordingly, the IESG must publish regular reports identifying those actions they have not yet addressed and explaining why. At a minimum, the IESG must publish these reports no later than one month prior to each face-to-face IETF meeting. 4.2 The "Bounded Outcome" model for the IETF A document is developed as a sequence of design decisions, as a WG makes progress. Hence the resulting document typically is produced from a substantial number of group consensus assessments. This should create a very strong presumption of community approval for the document. Any document can be criticized for its choices. An IETF effort is designed to resolve engineering choices for one issue and then move to a new issue. It is not reasonable to permit arbitrary criticisms to be raised late in the process, derailing the incremental effort of a WG. It is always reasonable to raise fundamental engineering problems, but it is essential to distinguish these from matters of engineering aesthetics. In particular, the IETF Last Call and IESG review periods are not intended for second-guessing a WG's design choices -- the purpose of an IETF Last Call and IESG review is to focus on the overall viability of the document. Accordingly, When evaluating a document, the IESG should heed comments that identify fundamental engineering problems and should ignore comments that suggest better ways of solving the same problem. Huston & Rose Expires April 25, 2003 [Page 8] Internet-Draft The IETF Pact October 2002 5. IANA Considerations This memo does not create any new issues for the IANA. Huston & Rose Expires April 25, 2003 [Page 9] Internet-Draft The IETF Pact October 2002 6. Security Considerations To the extent that the proposed changes produce documents that are more timely and simpler, those documents, in theory, should contain fewer security holes. Huston & Rose Expires April 25, 2003 [Page 10] Internet-Draft The IETF Pact October 2002 References [1] Bradner, S., "The Internet Standards Process -- Revision 3", BCP 9, RFC 2026, October 1996. Authors' Addresses G. Huston Telstra 5/490 Northbourne Avenue Dickson, ACT 2602 AU EMail: gih@telstra.net Marshall T. Rose Dover Beach Consulting, Inc. POB 255268 Sacramento, CA 95865-5268 US Phone: +1 916 483 8878 EMail: mrose@dbc.mtview.ca.us Huston & Rose Expires April 25, 2003 [Page 11] Internet-Draft The IETF Pact October 2002 Appendix A. Summary of Proposed Rules Rule 1: A WG charter must explicitly state: * what problems are to be solved or what specific benefits are intended from the work to be done; * who the intended beneficiaries are (also describing some examples of the use and effect that will accrue from using the capabilities provided by the WG's output); and, * where areas of difficulty are likely to be encountered. Rule 2: A WG gets no more than 18 months to have their first I-D approved by the IESG; similarly, a WG gets no more than 12 months to have each succeeding document approved by the IESG. Rule 3: Once a document is submitted to the IESG for approval, a formal request for further discussion may delay IESG voting on the document until no later than the next IESG meeting. Rule 4: All IESG votes require a minimum of 55% of those voting "yes" to pass; further, the votes of the responsible ADs are weighted to 45% of all votes, with the remaining ADs combining to 55% of all votes. Rule 5: If an IESG vote rejects a WG document, then the IESG must publish an explanation prior to the next IESG meeting. If no report is published in that timeframe, then the document is automatically approved. Rule 6: The IESG must publish regular reports identifying those actions they have not yet addressed and explaining why. At a minimum, the IESG must publish these reports no later than one month prior to each face-to-face IETF meeting. Rule 7: When evaluating a document, the IESG should heed comments that identify fundamental engineering problems and should ignore comments that suggest better ways of solving the same problem. Huston & Rose Expires April 25, 2003 [Page 12] Internet-Draft The IETF Pact October 2002 Full Copyright Statement Copyright (C) The Internet Society (2002). All Rights Reserved. This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English. The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assigns. This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. Acknowledgement Funding for the RFC Editor function is currently provided by the Internet Society. Huston & Rose Expires April 25, 2003 [Page 13]