Network Working Group E. Davies, Ed. Internet-Draft Folly Consulting Intended status: Informational October 23, 2006 Expires: April 26, 2007 Moving Forwards with IETF Process Evolution draft-davies-pesci-initial-considerations-03 Status of this Memo By submitting this Internet-Draft, each author represents that any applicable patent or other IPR claims of which he or she is aware have been or will be disclosed, and any of which he or she becomes aware will be disclosed, in accordance with Section 6 of BCP 79. 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 26, 2007. Copyright Notice Copyright (C) The Internet Society (2006). Abstract This document provides a summary of previously identified problems with the Internet Engineering Task Force (IETF) process for developing standards and other specifications; and then identifies a set of goals to aim at, and guidelines that should be followed during any activity seeking to revise and update this process. It does not propose specific changes to the process, which should be the subject of future documents. Davies Expires April 26, 2007 [Page 1] Internet-Draft PESCI Goals and Guidelines October 2006 Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 1.1. Guidelines and Goals . . . . . . . . . . . . . . . . . . . 3 1.2. Principles, Policy, Process and Procedure . . . . . . . . 3 1.3. About This Document . . . . . . . . . . . . . . . . . . . 5 2. Background reading . . . . . . . . . . . . . . . . . . . . . . 5 3. Short problem analysis . . . . . . . . . . . . . . . . . . . . 6 4. Goals and Guidelines for IETF Process Change Activities . . . 7 4.1. Goals . . . . . . . . . . . . . . . . . . . . . . . . . . 8 4.2. Guidelines for Process Change Activities . . . . . . . . . 8 5. Next Steps . . . . . . . . . . . . . . . . . . . . . . . . . . 9 6. Security Considerations . . . . . . . . . . . . . . . . . . . 9 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 10 9. Informative References . . . . . . . . . . . . . . . . . . . . 10 Appendix A. PESCI Announcement . . . . . . . . . . . . . . . . . 11 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 13 Intellectual Property and Copyright Statements . . . . . . . . . . 15 Davies Expires April 26, 2007 [Page 2] Internet-Draft PESCI Goals and Guidelines October 2006 1. Introduction This document provides a summary of previously identified problems with the Internet Engineering Task Force (IETF) process for developing standards and other specifications (referred to as the IETF standards development process in this document); and then identifies a set of goals to aim at, and guidelines that should be followed during any activity seeking to revise and update this process. It also provides a reading list of the diverse material that currently defines and discusses the various parts of this process. It does not propose specific changes to the process, which should be the subject of future documents. It has been produced by a design team (the PESCI design team) selected by the IETF Chair and is submitted to the IETF community for discussion. The IETF almost continually debates its own process and this is in many ways a healthy sign of its openness. However, the debate is often inconclusive. The goals and guidelines set out in this document represent an application of the IETF's Principles on specification development and decision making appropriate to making changes to the IETF standards development process. 1.1. Guidelines and Goals The IETF has previously come to the conclusion that the IETF standards development process suffers from a number of problems as summarized in Section 3. In defining an activity to improve the IETF standards development process, the activity needs to have a clear goal or goals in ameliorating some part of these problems. Besides the basic goal of process improvement, the activity should also aim at a number of general goals applicable to the way in which the improvement is defined and implemented. Because it is an IETF activity, the activity itself and its results should follow the general principles and policies which underlie the operation of the IETF. Although the IETF has a Mission Statement [RFC3935], the principles on which the IETF operates are mostly part of the unwritten lore of the organization, and the PESCI design team created a set of principles out of their collective experience of the way in which the IETF operates. This set has been used to inform the creation of a set of goals and guidelines applicable to any activity which seeks to improve the IETF standards development process: Section 4, which documents this set of goals and guidelines, provides the results of this work. 1.2. Principles, Policy, Process and Procedure Before going on to discuss process problems and guidelines for change activities we should be clear about what we mean by "process", and Davies Expires April 26, 2007 [Page 3] Internet-Draft PESCI Goals and Guidelines October 2006 some of the other "P" words which will be used in the document. Principles A set of statements that sets out how the IETF will approach its work and carry out its mission. Collectively they set the organization's ethos. These include such things as requiring that development of documents and organizational matters are as far as possible open with "rough consensus and running code" as an operating principle. When the PESCI design team started work no such set of statements existed, and the team created a set based on their collective understanding of how the IETF functions. These statements are not incorporated in this document but may be published separately, possibly as part of a revision of the Tao of the Internet. Policy An agreement on what the IETF sets out to accomplish. At the highest level this is incorporated in the IETF Mission Statement[RFC3935]. This is refined in the "constitutions" (usually known as "charters" in the IETF) for the various component bodies which provide the organisation of the IETF (listed in Section 2), but these documents are not confined to policy matters. Overall IETF policy and the constitutions of the bodies are adopted by establishing strong IETF consensus. Process Descriptions of the methods and mechanisms by which the IETF works. These must be visible to all the IETF participants; core pieces of the existing process are contained in the IESG charter and the IAB charter together with the definition of the IETF Standards Track in [RFC2026]. Additions or modifications to IETF processes are verified by establishing an IETF (rough) consensus, but normally, the specification of the process should be developed under the aegis of the body or bodies that will oversee the operation of the process. The process category covers area descriptions, large proportions of the material in RFC2026 and the mechanisms used to handle Intellectual Property Rights (IPR) disclosures [RFC3979], as well as (for instance) the IAB document on liaisons [RFC4053]. Procedures The "nuts and bolts" of the execution of the process. The I-D tracker, the tools team work, the liaison statements document - even the IPR trust agreement - belong in this category. Davies Expires April 26, 2007 [Page 4] Internet-Draft PESCI Goals and Guidelines October 2006 Procedures are normally developed by the people doing the work, and documented and published as these bodies feel it appropriate. 1.3. About This Document This document was produced by the PESCI design team selected by the IETF Chair and is published here as a record of discussion. PESCI stands for Process Evolution Committee of the IETF and is in the IETF's naming tradition as a successor of the earlier POISSON working group. The membership of the design team is listed in the Acknowledgements and the original announcement of PESCI is given as an Appendix. PESCI had no special status in the IETF process; it was simply the group of people who produced this document under the leadership of the IETF Chair. 2. Background reading The primary objective of the IETF process is to support the IETF Mission Statement, [RFC3935]. Readers should be familiar with that document. The early phase of the current round of process discussions led to a problem statement [RFC3774]. A general overview of current and draft process documents can be found in [I-D.carpenter-procdoc-roadmap]. At the time of writing, two process related working groups exist: newtrk (New IETF Standards Track Discussion) and ipr (Intellectual Property Rights). Their charters, mailing lists, etc., may be found via http://www.ietf.org/html.charters/wg-dir.html#General%20Area. The organisations involved in the IETF standards process are discussed in [RFC2028]. Information about the constitutions, purposes, and policy of the main IETF bodies involved in these processes can be found in: o The Internet Architecture Board(IAB) Charter[RFC2850] o The Internet Engineering Steering Group (IESG) Charter[RFC3710] o The Nominating and Recall Committee (NOMCOM)[RFC3777] o Request For Comments (RFC) Editor: See the RFC Editor web pages including RFC Editor Purpose description (http://www.rfc-editor.org/DOCUMENTS/purpose.html) and some procedures in [RFC3932] o The memorandum of understanding under which the Internet Assigned Numbers Authority (IANA)) operates is in [RFC2860]; the processes and procedures as they affect IETF relationships to IANA are currently under discussion and will be the subject of the "techspec" BOF in November 2005 (see Section 3). Davies Expires April 26, 2007 [Page 5] Internet-Draft PESCI Goals and Guidelines October 2006 o The mission of the Internet Research Task Force (IRTF) is described on its web page (http://www.irtf.org/), and the policies and procedures for the IRTF are in [RFC2014] o Liaisons with external bodies are conducted through the IAB (see [RFC4052] and [RFC4053]) In the last two years or so, a major effort has been made to update the IETF's administrative structure, creating the IAOC, the IETF Administrative Support Activity (IASA), and appointing the IETF Administrative Director (IAD) (see [RFC4071] for details of these bodies). This should not be confused with process change, although its goal is to improve support for the process. Additionally, the former and present IETF Chairs, and the IESG have taken steps to improve procedures and their transparency. The Tools team and the Education team are busy, many improvements have been made in details of IESG document processing and shepherding, and the IESG has made a number of efforts to improve the transparency of its discussions. Such efforts are valuable, but orthogonal to process change as such. However, they are part of the response to the problem statement [RFC3774]. 3. Short problem analysis The PESCI team reviewed earlier [RFC3774] and recent discussion of IETF process problems. This generated the following list of problems that seem to affect the development of standards and other specifications (following the remit of the design team described in Section 1) and that appear to be potentially soluble. 1. Timeliness of IETF output 2. Lack of clarity about authority and delegation 3. Variable quality of output from WGs * At least 30% of drafts attract IESG "DISCUSS" comments even after IETF Last Call. * Unsolved issue of adequate cross-area review earlier in the process. 4. IESG overload, which leads to subsidiary problems * bottleneck effect * too little steering * perception issues and them/us mentality * burnout * potential lack of candidates 5. Lack of a "career path" for IESG members - "dropped in, overworked and chopped off" * there is no form of apprenticeship for Area Directors (ADs) Davies Expires April 26, 2007 [Page 6] Internet-Draft PESCI Goals and Guidelines October 2006 * ADs are trained "on the job" leading to lower effectiveness early in their terms * lack of any sort of formal recognition or role for "emeritus" ADs * potential to lose both experience and capability of ex-ADs 6. Binary nature of appeal/recall process * there is a disincentive to "go nuclear" leading to festering problems * appeals are very time consuming for IESG (and maybe also for IAB) * the IESG judge and jury problem for process issues 7. Difficulties which the IETF has in dealing with complex problems (architectural issues are hard to handle in the current IESG/ area/working group structure) 8. Failures to follow through on the standards advancement process, generally poor maintenance of standards and slow progress of standards Newtrk issues are in scope for the process change but we should allow Newtrk to work - there maybe some opportunities to provide input to newtrk through the principles we propose here. 9. Authority and decision mechanisms for parameter assignments (IANA considerations). 10. Lack of a coherent set of documents defining the IETF processes. Issues that are to be considered under the "techspec" banner are out of scope for PESCI. The scope of techspec includes resolving concerns regarding lack of visibility into RFC Editor state, copy- editing, and excessive author changes in AUTH48. There was a techspec BOF at IETF 64 in Vancouver. (see discussion list archive at http://www1.ietf.org/mail-archive/web/techspec/current/). IPR issues have their own WG (ipr) and have been thoroughly reviewed. 4. Goals and Guidelines for IETF Process Change Activities This section lists specific goals and guidelines for any activity seeking to change the IETF standards development process. An effort has been made to write these very briefly and in self-explanatory words. Many existing documents, including [RFC3774] and those cited in [I-D.carpenter-procdoc-roadmap], have been consulted, as well as recent mailing list discussions and private communications. An intermediate output was a set of IETF Principles that is not reproduced here but may be published separately. Davies Expires April 26, 2007 [Page 7] Internet-Draft PESCI Goals and Guidelines October 2006 4.1. Goals Any activity which seeks to change the IETF standards development process needs to have a well-defined aim of ameliorating some part of the problems set out in Section 3 or identified subsequently. The activity should also aim to satisfy a number of goals identified here that should allow the changes to provide maximum improvement with minimum disruption. When designing new processes, it should be borne in mind that process changes that require major structural changes within the IETF may have wide-scale impact on the operation of the IETF: evolutionary change may be more effective than revolutionary change. G1. Ameliorate a well-defined part of the process problem space. G2. Preserve those parts of the process that work reasonably well today, unless they block other necessary changes. G3. Make changes that seem certain to improve those parts of the process that work less well. G4. Avoid changes that would require unrealistic resources or behaviours. G5. Protect the continuity of ongoing IETF work. G6. As far as possible, minimize simultaneous changes that may interfere with each other. G7. Avoid "thrashing" by repeated changes in the same area. G8. Try to explicitly estimate the impact of changes before making them, and try to measure whether the expectations were met after making the change. G9. Acknowledge that some refinement of the initial proposals may be needed after trials. To this end try to work expeditiously to provide a nearly right solution that delivers most of the gains rather than refining the solutions endlessly before any implementation (in line with the IETF's usual way of developing standards). 4.2. Guidelines for Process Change Activities Any activity for developing, approving and implementing changes to IETF standards development process needs to operate in line with the general principles of the IETF. This section presents a number of guidelines developed from these principles that should apply to any such activity. They deal with how any proposed changes to the IETF processes for developing standards and other specifications should be developed and authorized by the IETF community. These guidelines appear to be broadly in line with our current process for development activities, and similar principles should be true of any future process. Davies Expires April 26, 2007 [Page 8] Internet-Draft PESCI Goals and Guidelines October 2006 P1. Changes to the IETF process must themselves be agreed by an open process approved by the IETF community. P2. The process for developing and agreeing these changed processes must itself be the subject of IETF rough consensus. P3. The development process must incorporate taking advice from * the IESG, the IAB, the IAOC, and the Working Group chairs * legal advisors P4. When the proposed changes have been fully documented, "buy-in" or more formal assent to the changed processes needs to be obtained as follows: * Any negative comments from the Working Group chairs must be seriously considered. * Formal consent must be obtained from the IESG, the IAB, and the IAOC. * Acceptance must be obtained from the ISOC board. P5. The development and authorisation of the changed processes must ensure that the IESG is not required itself to develop the new processes. 5. Next Steps The remit of the PESCI design team did not extend to determining what IETF standards development process activities should be undertaken. However the team encourages members of the community to produce proposals for such activities in line with the above goals and guidelines. 6. Security Considerations This document has no direct impact on the security of the Internet. However, a smooth and efficient IETF process is necessary to deal rapidly with emerging security threats. Also, a badly designed process may be subject to social denial of service attacks that could damage both the IETF and indirectly the Internet itself. We should also note that the change process (and the evaluation of potential change) is itself vulnerable to social DoS. 7. IANA Considerations This document does not require action by the IANA. However, IANA activities do form part of the IETF process and process changes may affect IANA. Davies Expires April 26, 2007 [Page 9] Internet-Draft PESCI Goals and Guidelines October 2006 8. Acknowledgements The members of the PESCI team at the time this document was written were: Harald Alvestrand Scott Brim Brian Carpenter Elwyn Davies Adrian Farrel Michael Richardson This document was produced using the xml2rfc tool[RFC2629] and edited with the xxe editor plug-in. 9. Informative References [I-D.carpenter-procdoc-roadmap] Carpenter, B., "The IETF Process: an Informal Guide", draft-carpenter-procdoc-roadmap-05 (work in progress), August 2006. [RFC2014] Weinrib, A. and J. Postel, "IRTF Research Group Guidelines and Procedures", BCP 8, RFC 2014, October 1996. [RFC2026] Bradner, S., "The Internet Standards Process -- Revision 3", BCP 9, RFC 2026, October 1996. [RFC2028] Hovey, R. and S. Bradner, "The Organizations Involved in the IETF Standards Process", BCP 11, RFC 2028, October 1996. [RFC2629] Rose, M., "Writing I-Ds and RFCs using XML", RFC 2629, June 1999. [RFC2850] Internet Architecture Board and B. Carpenter, "Charter of the Internet Architecture Board (IAB)", BCP 39, RFC 2850, May 2000. [RFC2860] Carpenter, B., Baker, F., and M. Roberts, "Memorandum of Understanding Concerning the Technical Work of the Internet Assigned Numbers Authority", RFC 2860, June 2000. [RFC3710] Alvestrand, H., "An IESG charter", RFC 3710, February 2004. [RFC3774] Davies, E., "IETF Problem Statement", RFC 3774, May 2004. Davies Expires April 26, 2007 [Page 10] Internet-Draft PESCI Goals and Guidelines October 2006 [RFC3777] Galvin, J., "IAB and IESG Selection, Confirmation, and Recall Process: Operation of the Nominating and Recall Committees", BCP 10, RFC 3777, June 2004. [RFC3932] Alvestrand, H., "The IESG and RFC Editor Documents: Procedures", BCP 92, RFC 3932, October 2004. [RFC3935] Alvestrand, H., "A Mission Statement for the IETF", BCP 95, RFC 3935, October 2004. [RFC3979] Bradner, S., "Intellectual Property Rights in IETF Technology", BCP 79, RFC 3979, March 2005. [RFC4052] Daigle, L. and Internet Architecture Board, "IAB Processes for Management of IETF Liaison Relationships", BCP 102, RFC 4052, April 2005. [RFC4053] Trowbridge, S., Bradner, S., and F. Baker, "Procedures for Handling Liaison Statements to and from the IETF", BCP 103, RFC 4053, April 2005. [RFC4071] Austein, R. and B. Wijnen, "Structure of the IETF Administrative Support Activity (IASA)", BCP 101, RFC 4071, April 2005. Appendix A. PESCI Announcement To: IETF Announcement list From: IETF Chair Date: Fri, 16 Sep 2005 11:21:18 -0400 Subject: IETF Process Evolution There has been quite a bit of community discussion of IETF process change in recent months. Obviously, process changes must obtain rough consensus in the IETF and follow the procedures in place (principally RFC 2026 today). However, past experience has shown that general discussion of IETF process change on the main IETF list, or in a normal working group, rapidly tends towards divergent opinions with consensus being extremely hard and slow to establish. On the other hand, we have experience that discussion of simply formulated principles and of consistent process proposals can be constructive and convergent. This note describes a method of starting the next phase of IETF process change, possibly including updating the change process itself. Davies Expires April 26, 2007 [Page 11] Internet-Draft PESCI Goals and Guidelines October 2006 As IETF Chair, I intend to lead a short term design team, to be known as PESCI (Process Evolution Study Committee of the IETF). I will request PESCI to - review recent discussions on IETF process changes - identify a concise set of goals and principles for process change - publish these for comment and seek IETF debate and rough consensus The target is to have a draft of goals and principles by IETF64. The next steps will depend on the agreed goals and principles after this debate. It is very likely that we will need a process that will generate a consistent set of proposals and a sequence for implementing them, with target dates. It is also likely that the first proposal will be a new process for process change. And it's a given that open discussion and rough consensus, in accordance with IETF principles, will be required. A non-binding proposal for the next steps is appended to this message. Given the short time until the next IETF, the team will have to start very soon and work quite intensively. If you would like to volunteer for the PESCI team or nominate someone to serve on it, please send me email immediately. I want to create the team within a week. Brian Carpenter IETF Chair N.B. The open discussion list will be pesci-discuss@ietf.org, but it hasn't yet been created at the time of sending this message. ----- Possible next steps after the PESCI goals and principles are agreed: - decide whether to renew the PESCI design team (assumed below) or use an alternative discussion forum - consider various process change proposals from any source - reach a team consensus on a consistent set of proposals and a sequence for implementing them, with target dates. All proposals must embed the principle of rough IETF consensus and must provide an appeal mechanism. - one of the proposals, likely the first, may be a proposal for a new process for process change - post the proposals as Internet-Drafts intended for publication as BCPs - seek IETF-wide rough consensus on these drafts Davies Expires April 26, 2007 [Page 12] Internet-Draft PESCI Goals and Guidelines October 2006 - legal considerations, IASA financial considerations, and considerations of practicality raised by current or past Area Directors, WG Chairs and the like will be given special consideration. If IETF consensus appears to be for a proposal which is legally, financially or practically unacceptable, PESCI will need to convince the community to change its mind. To enable this, as relevant, the ADs, IAB members, and IAOC members including the IAD will be asked to provide personal input specifically on the feasibility of implementing the proposed process changes as they affect their specific roles. - forward proposals for approval as BCPs* and acceptance by the ISOC Board. Until such time as the new process for process change has been approved, the proposals will be submitted directly to the General Area Director and the approval body will be the IESG. However, the IESG members' principal chance to comment on and influence the proposals is prior to their forwarding for approval. *An alternative would be to use the mechanism described in RFC 3933, if consensus was weak. In particular, this can be used to experiment with the practicality of ideas. Additional conditions for PESCI's work - a subsidiary goal is to end up with a clearly defined and interlocked set of process documents, rather than a patchwork of updates to existing documents - PESCI will provide an open mailing list where discussion with the community will be encouraged. It will issue regular (monthly?) progress reports and generally operate as transparently as possible. Discussion in IETF plenary sessions is also expected. - nothing in this proposal prevents ongoing operational improvements within the current process. Davies Expires April 26, 2007 [Page 13] Internet-Draft PESCI Goals and Guidelines October 2006 Author's Address Elwyn Davies (editor) Folly Consulting Soham, UK Phone: +44 7889 488 335 Fax: Email: elwynd@dial.pipex.com URI: Davies Expires April 26, 2007 [Page 14] Internet-Draft PESCI Goals and Guidelines October 2006 Full Copyright Statement Copyright (C) The Internet Society (2006). This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights. This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM 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. Intellectual Property The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79. Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr. The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org. Acknowledgment Funding for the RFC Editor function is provided by the IETF Administrative Support Activity (IASA). Davies Expires April 26, 2007 [Page 15]