Network Working Group E. Davies, Ed. Internet-Draft Folly Consulting Expires: April 19, 2006 October 16, 2005 Goals and Principles for IETF Process Evolution draft-davies-pesci-initial-considerations-00 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 19, 2006. Copyright Notice Copyright (C) The Internet Society (2005). Abstract This document identifies a set of goals and principles for the next stages in revising and updating the Internet Engineering Task Force (IETF) process for developing standards and other specifications. It does not propose specific changes to the process, which should be the subject of future documents. It suggests a strawman for the way in which process changes could be specified and identifies some initial target areas for process change. Davies Expires April 19, 2006 [Page 1] Internet-Draft PESCI Principles October 2005 Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 1.1. Principles, Policy, Process and Procedure . . . . . . . . 3 1.2. About This Document . . . . . . . . . . . . . . . . . . . 4 2. Background reading . . . . . . . . . . . . . . . . . . . . . . 4 3. Short problem analysis . . . . . . . . . . . . . . . . . . . . 5 4. High Level Goals and Principles of IETF Process Change . . . . 7 4.1. Goals . . . . . . . . . . . . . . . . . . . . . . . . . . 7 4.1.1. Desired Outcomes . . . . . . . . . . . . . . . . . . . 7 4.1.2. Change Management Guidelines . . . . . . . . . . . . . 8 4.2. Principles to be Considered . . . . . . . . . . . . . . . 9 4.2.1. Development and Authorisation of the Changed Processes . . . . . . . . . . . . . . . . . . . . . . 9 4.2.2. The Content of the Changed Processes . . . . . . . . . 10 4.2.3. Management and Leadership in the Changed Processes . . 10 4.2.4. Individual Participants . . . . . . . . . . . . . . . 11 4.2.5. Protocol Parameter Assignments . . . . . . . . . . . . 12 4.2.6. Areas . . . . . . . . . . . . . . . . . . . . . . . . 12 4.2.7. Working Groups . . . . . . . . . . . . . . . . . . . . 12 4.2.8. Extended Review . . . . . . . . . . . . . . . . . . . 13 5. The Arena for Change . . . . . . . . . . . . . . . . . . . . . 13 5.1. Components Not Considered for Major Change in this Document . . . . . . . . . . . . . . . . . . . . . . . . . 13 5.2. Components Considered for Major Change in the Document . . 15 6. Next Steps . . . . . . . . . . . . . . . . . . . . . . . . . . 18 6.1. Change Process Proposal . . . . . . . . . . . . . . . . . 18 6.2. Immediate Tasks for the Change Process . . . . . . . . . . 19 7. Security Considerations . . . . . . . . . . . . . . . . . . . 19 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 19 9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 20 10. Informative References . . . . . . . . . . . . . . . . . . . . 20 Appendix A. Raw principles . . . . . . . . . . . . . . . . . . . 21 A.1. General . . . . . . . . . . . . . . . . . . . . . . . . . 21 A.2. Management and Leadership . . . . . . . . . . . . . . . . 22 A.3. Documents (may change after techspec BOF) . . . . . . . . 23 A.4. Intellectual Property . . . . . . . . . . . . . . . . . . 24 A.5. Protocol Parameter Assignments . . . . . . . . . . . . . . 24 A.6. Working Groups . . . . . . . . . . . . . . . . . . . . . . 24 A.7. Other . . . . . . . . . . . . . . . . . . . . . . . . . . 24 Appendix B. PESCI Announcement . . . . . . . . . . . . . . . . . 24 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 27 Intellectual Property and Copyright Statements . . . . . . . . . . 28 Davies Expires April 19, 2006 [Page 2] Internet-Draft PESCI Principles October 2005 1. Introduction This document identifies a set of goals and principles for the next stages in revising and updating the Internet Engineering Task Force (IETF) process for developing standards and other specifications. It does not propose specific changes to the process, which should be the subject of future documents. It does, however, suggest a strawman for the way in which the process changes could be specified and identifies some areas of current IETF process that appear to be the most urgently in need of improvement in the light of problems previously identified. It has been produced by a design team selected by the IETF Chair and is submitted to the IETF community for discussion, modification, and hopefully approval. 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. This document attempts to set the scene for focused work to change only those specific aspects of the IETF process that need change, by identifying goals and principles that can be expressed simply and can potentially reach consensus in the community. 1.1. Principles, Policy, Process and Procedure Before going on to discuss process change we should be clear about what we mean by "process", and 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 and "rough consensus and running code" as an operating principle. This document attempts to capture a large subset of these principles relevant to the issue of process changes (see Section 4.2). 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. Davies Expires April 19, 2006 [Page 3] Internet-Draft PESCI Principles October 2005 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. Procedures are normally developed by the people doing the work, and documented and published as these bodies feel it appropriate. 1.2. About This Document This document was produced by the PESCI design team selected by the IETF Chair and is submitted to the IETF community for discussion, modification, and hopefully expeditious approval. 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 has no special status in the IETF process; it is simply the group of people who produced this document under the leadership of the IETF Chair. Discussion of this draft is welcomed on the pesci-discuss@ietf.org list (join via https://www1.ietf.org/mailman/listinfo/pesci-discuss). 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. Davies Expires April 19, 2006 [Page 4] Internet-Draft PESCI Principles October 2005 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). 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 Davies Expires April 19, 2006 [Page 5] Internet-Draft PESCI Principles October 2005 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) * 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 loose 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) 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- Davies Expires April 19, 2006 [Page 6] Internet-Draft PESCI Principles October 2005 editing, and excessive author changes in AUTH48. There is to be 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. High Level Goals and Principles of IETF Process Change This section lists specific goals and principles of changing the IETF process for developing standards and other specifications. 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. In this section the team has concentrated on goals and principles that specifically concern change to the process. However, in some cases this is hard to do (for example, when it seems that a basic principle is only partly implemented by today's process). The team expects more refinement and tighter focus in this section as a result of community discussion. 4.1. Goals Goals for changing the IETF processes can be separated into o targets for the end point of the change ( Section 4.1.1), and o guidelines that should be followed during the creation of the new processes and the transition needed to put the approved processes into use (Section 4.1.2). 4.1.1. Desired Outcomes G1. Identify and document improvements and additions to the existing processes for developing standards and other specifications to enable the IETF to be more effective and efficient in the performance of its mission. To this end, define and document processes which will: 1. Provide an environment in which the mission of the IETF can be carried out efficiently and effectively including, but not limited to, provision of tools, communication mechanisms and meetings that will take the mission forwards. 2. Deliver, in a timely manner, a set of accurate, consistent, usable, maintainable, coordinated, and relevant documents that describe Davies Expires April 19, 2006 [Page 7] Internet-Draft PESCI Principles October 2005 + the architectural principles of the Internet + the protocols over which the IETF asserts ownership + additions and extensions developed within the IETF for protocols not owned by the IETF + any necessary supporting information and practices. 3. React in a timely fashion to events from internal and external sources that affect the Internet as a whole and the document development process. 4. Maintain the quality of IETF output both initially and over the entire lifetime of a protocol. 5. Deliver visibility of the process to all participants, together with adequate protections against abuse of the process by any participant. 6. Maintain metrics which will allow the efficiency and effectiveness of the processes to be monitored. 7. Provide effective coordination between the various component structures defined by the process (such as the current IAB and the IESG) and the individual participants in the IETF. 8. Provide a transition path and continuity in the process of change, both as regards the processes themselves and the protocols owned. 4.1.2. Change Management Guidelines 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. 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. Changes to processes should err towards the maintenance of stability. G5. Avoid changes that would require unrealistic resources or behaviours. G6. Protect the continuity of ongoing IETF work. G7. As far as possible, minimize simultaneous changes that may interfere with each other. G8. Avoid "thrashing" by repeated changes in the same area. G9. Try to explicitly estimate the impact of changes before making them, and try to measure whether the expectations were met after making the change. G10. 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 Davies Expires April 19, 2006 [Page 8] Internet-Draft PESCI Principles October 2005 standards). 4.2. Principles to be Considered When developing, approving and implementing the changes to IETF standards development processes there are a number of principles that should be borne in mind. In developing the set of principles listed in this section the design team took into account a much longer list of "raw principles" (currently in Appendix A) . This work tries to abstract from this data the true principles that should be taken into account. However we would urge both the community and the developers of the changed processes to look critically at these "principles", but accept that perfection is impossible (_rough_ consensus is the aim): o If good and sufficient reason to reject or modify any of them can be found, such change should not be a taboo subject. o The principles, except for those in Section 4.2.1, provide guidance not constraints or requirements: it is up to the developers of the changed processes and the community to decide _how_ these principles should affect the change process or be enshrined in the resulting changed processes. o Each principle will be applicable to only a part of the process changes: if a principle is applicable to some part of the process changes, the aim should be improvement along the dimension given by the principle. Aiming for completeness or perfection in one cut, even on a single principle, is likely to seriously delay design of the changed processes. We have endeavoured to keep any element of "solutionism" out of these principles. 4.2.1. Development and Authorisation of the Changed Processes This group of principles deals 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 principles appear to be required by our current process, and similar principles should be true of any future process. 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 Davies Expires April 19, 2006 [Page 9] Internet-Draft PESCI Principles October 2005 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. P6. The revised process should be documented in a new set of coherent and comprehensive documents, rather than updates to the existing ad hoc set. 4.2.2. The Content of the Changed Processes This section contains principles relating to what should and should not be in the revised processes. A minimalist approach is taken to give the authors of change maximum freedom to do the right thing. P7. New process rules should be flexible enough to allow unusual cases to be handled according to common sense. P8. Parts of the existing process that have proved impractical should be improved or removed. P9. The number of steps in the document approval process must be kept to a minimum subject to adequate review and approval being carried out. P10. Document quality criteria, decision criteria, and procedures that support the process should be publicly documented. P11. A complete complaints, conciliation, and appeals process for each decision process should be documented. 4.2.3. Management and Leadership in the Changed Processes The IETF prides itself on being a technically led organization (i.e., our leaders are primarily technologists, rather than managers) with open processes which can, whenever possible, be challenged by participants if they feel there has been a miscarriage. This is a major part of the IETF ethos and altering it would change the IETF fundamentally. However, if the standards development process is to be effective, people, process, and technical management skills are also required. Finding enough technically skilled participants, who also have these management skills, to populate the leadership positions is challenging. At present the management of the standards development process is mostly carried out by WG chairs under the supervision of ADs with the members of the IAB primarily in the role of technical consultants and policy setters. The cadre of ADs is Davies Expires April 19, 2006 [Page 10] Internet-Draft PESCI Principles October 2005 relatively small and the work that they do is so different in character from that of WG chairs that it is difficult for participants to acquire the skills needed for the AD task other than by doing it: this can make new ADs relatively inefficient. P12. All decisions are subject to appeal using the procedures documented in the processes. P13. Management and leadership of the standards process should be predominantly carried out by people who are technically competent in the area in which they are leading, and the processes should ensure that people in leadership positions remain knowledgeable about the state of the art (and beyond) in their areas of responsibility. At the highest levels, overall architectural awareness of the Internet become at least as important as technical expertise in a particular speciality. P14. The processes should ensure that it is possible for IETF participants to acquire or hone the particular skills needed for management and leadership positions in the IETF before taking on these positions, for example by forms of apprenticeship. "On the job" training is valuable but we should try to give it in such a way that leaders are as productive as possible as soon as they are appointed. P15. The processes should seek to give opportunities to as many people as possible to participate in management of the process outside the narrow technical confines of a single working group, in order to increase the pool of people available for choosing leaders. P16. The processes should ensure that, so far as is possible, the pool of skills and experience developed by those in leadership and management positions remains available to the IETF and continues to be seen to be valued whilst giving these leaders a period to refresh their skill in the technical arena. P17. Selection of IETF leaders and managers should be by a competence based process which is, subject to the needs of individual confidentiality, open and independently verifiable. P18. Leadership positions should be defined such that the workload is compatible with other employment and personal life. Very few leadership positions should require effective full time work. P19. The amount of work needed to select the IETF leaders and managers should not be disproportionate. To this end the number of posts involved should not be allowed to grow without limit and the size of the selection panel should be constrained. 4.2.4. Individual Participants The IETF is extremely unusual in that it has no formal membership. Participants are self-selecting and involvement is by the individual's choice. There is no formal mechanism for outside Davies Expires April 19, 2006 [Page 11] Internet-Draft PESCI Principles October 2005 corporate entities to affect IETF decisions, although there are arrangements for exchange of "liaisons" with other recognised standardisation organisations. P20. IETF processes should make it as easy as possible for individuals to participate fully in standards development work with no discrimination on the basis of race, religion, nationality, country of residence, gender, sexual orientation or disability. P21. Official IETF work is carried out exclusively in the English language. P22. Individual participants need not physically attend any meetings to participate in standards development work. 4.2.5. Protocol Parameter Assignments This section contains principles which relate to the way in which IANA registries are established and the processes by which additional values can be registered. P23. The IETF functions of the IANA must be under IETF control. 4.2.6. Areas Areas have become a fundamental structuring mechanism for IETF work since the Kobe reorganization. Area Directors (ADs) are at the moment the central focus of management and technical expertise in the IETF. P24. The IETF needs a wide breadth of expertise in its participants and those who supervise its processes. Providing a number of more concentrated foci for that expertise (which might be called "specialities") allows participants to discuss their interests with like minded people. P25. Besides experts in particular areas, it is important that the IETF also takes an architectural view and encourages participants who are able to work at the overall architectural level both to direct the standards development work in the IESG ambit; and to set technical guidelines internally, monitor technical developments in the research and commercial world out side the IETF and interact with external groups. P26. Areas must not become isolated "silos" in which work is carried out in isolation from other specialities. 4.2.7. Working Groups The chartered Working Group (WG) normally led by two WG co-chairs is the way in which the IETF organizes units work. It has proved a Davies Expires April 19, 2006 [Page 12] Internet-Draft PESCI Principles October 2005 durable structure and when working well appears to be an effective way of doing standards development. P27. WG Chairs are responsible for ensuring that WGs execute their charters, meet their milestones, and produce deliverables that are ready for publication. P28. WGs should be primarily responsible for the quality of their output, and for obtaining and responding to cross-area and other external review. 4.2.8. Extended Review The SIRS experiment and the General Area review team have shown the value of extended, cross-area review of documents. Currently most such review is carried out too late in the document life cycle for best effectiveness. P29. It is essential that standards documents are not developed in isolation and that the effects of a particular proposal on other areas needs to be taken into account through consultancy and review by people outside the particular speciality developing the standards. P30. Extended review, and review in general, should be carried out starting as early as possible in the life cycle of the document. P31. Documents should not be presented for approval outside a working group until after successful cross-area review. P32. The new processes should provide means to ensure that cross-area review can be carried out effectively. 5. The Arena for Change The IETF operates through a number of organizational components, some of which have been relatively stable (such as the IAB and the IESG) as regards their functions and processes since the Kobe reorganization in 1992 while others (such as IAOC and IASA) have a more recent genesis. The design team looked at the various bodies to see how standards development process change should or ought to affect the components. In some cases major structural change as a result of these changes is either inappropriate or out of scope. The rest of this section considers the various components divided into those areas that it appears should be maintained with only peripheral changes and those areas that might be more heavily affected by any proposed process changes. 5.1. Components Not Considered for Major Change in this Document In drawing up the high level goals and principles presented in Davies Expires April 19, 2006 [Page 13] Internet-Draft PESCI Principles October 2005 Section 4 we consider that there are a number of fixed points in the overall organisation and operation of the IETF that are either outside our control, have served it well or have been recently put in place and are unlikely to need wholesale change. This group has not considered changes that would involve changing the responsibilities of these bodies but some of their responsibilities and interactions with other bodies may need modification as part of the process changes. ISOC ISOC acts as IETF's legal parent and guarantor. This process is not at liberty to change the relationship between ISOC and IETF. The ISOC board acts as court of final approval for some processes (such as appointments to IAB) and backstop for appeals in all processes. This should not change although it might be appropriate to consider the route by which appeals and approvals reach the ISOC board. Their seal of approval will be needed on any major process changes that may result from this effort. IAB The main function of the IAB is architectural oversight of developments in the Internet. This includes monitoring standards development work to ensure that it does not adversely impact the existing Internet, setting guidelines for architectural aspects of development, helping to determine what new working groups should be chartered, keeping a watching brief on technical developments outside the IETF, and providing statements on such developments as appropriate. The IAB currently acts as the second line of appeal for decisions of the IESG on standards development and other matters. This function is not an ideal fit with the general architectural remit of the IAB: the competencies of the IAB members do not necessarily equip them to deal with the process appeals that come to them from the IESG. Some of the members of the IAB may consider them a distraction from their architectural role. IAOC/IAD/IASA The administrative functions of the IETF are now handled by these structures. They are recently in place and until they have been given chance to "bed in" it would be inappropriate (and costly) to alter these structures and their internal relationships. However this does not say that what the administrative function does cannot be altered. The changed processes will almost certainly require some additional or changed functions from the administrative functions. Davies Expires April 19, 2006 [Page 14] Internet-Draft PESCI Principles October 2005 IRTF The Internet Research Task Force (IRTF) will continue to exist in parallel with the IETF and sharing many of the administrative functions. The documents that it produces add a small amount to the document approval and processing load. RFC Editor The RFC Editor provides the back end processing for all documents from approval to publication. The techspec BOF is considering how this process can be improved and it will not be considered further here. IANA The Internet Assigned Numbers Authority provides all the registry facilities for IETF protocols according to criteria and guidelines laid down by the IETF. IANA is likely to continue in existence. The processes which need to be carried out to establish and maintain these registries can be considered as part of the process changes. 5.2. Components Considered for Major Change in the Document The following components are structures that have served the IETF well, and are likely to be part of whatever structure is suggested by the effort which follows on from the publication of this document. However, the ways in which they are put together and how responsibility is divided amongst them may need to change as part of this process. Likewise, this should not be seen as constraining the changes that may be suggested: alternative or additional structures could take on part of the functions that are needed. IESG The IESG is central to the processes of standards development in the IETF. The steering role of the IESG in acceptance of new work, formation, and chartering of WGs, monitoring of WGs, and final stages of document processing seems to be appropriate, as it is essential to coordinate these functions. This does not imply that the IESG must be solely responsible for final cross-area review. The problems which the IESG is seen to encounter in these jobs appear to be related to the amount of work involved especially in reviewing documents. This is at least partially due to a lack of technical assistance for most ADs giving them no easy way to delegate parts of this work and making it difficult for them to operate "management by exception". Another area where process changes might lead to greater confidence in the standards development process is the Davies Expires April 19, 2006 [Page 15] Internet-Draft PESCI Principles October 2005 degree of self-regulation which the IESG exercises: in many process related disputes the IESG is expected to act as judge and jury on actions in which it is itself involved. Areas The partition of expertise in standards development into a number of areas appears to be a useful way of providing foci for participants and structure for an extremely wide technical field. Currently there is only informal recognition that not all areas are born equal. The cross-area role of the security ADs and the interaction of the transport standards with most higher and lower layer standards means that the "out- of-area" loads on the security and transport area ADs are highly significant and there is little formal support for them in carrying out this extra work. Operations work is also a key cross-area function. The effect of the current rigid structuring of work into areas is something which has not been much considered. It is possible that the way in which the IESG is made up of ADs, basically two per area, with the ADs managing the working groups exacerbates some of the IETF's problems: * Management "fan-out" constraint: The management capacity of the area ADs artificially limits the amount of work that can be carried out in an area - an active area might really need more working groups than can be realistically handled by the fixed set of ADs. However, any increase of management capacity that might result from process changes should not inhibit critical assessment of any proposed new work both as to value and its likely effect on the overall architectural cohesiveness of the IETF work. * Management "fan-in" overload: The number of working groups is expanded to and often beyond the point at which two ADs can successfully manage and review the output of those working groups on their own, but there is little formal delegation of such work which could possibly reduce this overload. * ADs are primarily specialists: The concentration on area specialisms may lead NOMCOM to appoint people who are primarily specialists to AD positions rather than those with an over-arching architectural view. This may lead to the overall attitude of the IESG de-emphasising architectural effectiveness. * Area Workload Imbalance: Areas are not born equal. The appointment of the same number of ADs in all areas leads to even greater overload in some areas. Davies Expires April 19, 2006 [Page 16] Internet-Draft PESCI Principles October 2005 * Areas can be a straitjacket: If some work naturally falls across speciality boundaries it may be difficult to fit it into the area model so that it either gets distorted to fit the model or does not get carried out at all (in the IETF). It is conceivable that this at least part of the reason why the IETF does not seem to be good at solving complex problems. * Area silos raise the stakes on cross-area review: Working groups and their participants effectively live in a single speciality environment. Cross speciality working does not come naturally so that cross-area review becomes more of a big deal paradoxically making it more difficult to ensure it is done just when the need for it is greatest. The current area directorates are fairly informal organisations and are, in most cases, not formally involved in the management process (MIB doctors and the general area reviewing team are exceptions). They could be a much bigger resource for ADs and specialities. IETF Chair The IETF Chair also currently wears the hats of chair of the IESG and AD of the General Area. This multiplicity of jobs can lead to an overlap of roles and conflicting skills requirements in the single holder of the posts. Serious consideration should be given to splitting the posts between two (or more) people. Working Groups Working Groups appear at base to be a successful way of carrying out an agreed charter of standards or other development work. The main areas for concern here are ensuring high quality output and maintaining momentum over the period of development, particularly in the later stages when the creative work is essentially finished and the work is mainly polishing. Active management by supervisors together with more rigorous and earlier review of documents seems to be required. Taking work through from initial standardisation to full standard appears to be difficult to achieve, The newtrk group may have some input here. NOMCOM The NOMCOM provides the means of selecting leaders and the volunteer managers for the IETF. The process by which this is performed is time consuming and could be considered onerous for participants, but it is vital that the process remains as open as possible and endeavours to keep the IETF Davies Expires April 19, 2006 [Page 17] Internet-Draft PESCI Principles October 2005 as free of undue external influences as possible. Changes to these processes should ensure that overlaps of role (as regards those performing the selection and the leaders being selected) do not arise and that the workload of the NOMCOM does not get out of hand. 6. Next Steps What the PESCI design team propose should be done next: We believe that an early proposal is needed for a new process for developing changes to the IETF processes especially in the area of developing standards documentation and other specifications. This proposed new process o would be used by all individuals, design teams, and working groups who wish to propose changes or additions to IETF processes, o should involve consultation with the IESG, the IAB, the IAOC, the Working Group chairs, and IETF participants generally, but o must avoid requiring the IESG to develop the new processes or micromanage this process of development and approval. The new proposals, both for the change process and any resulting changed processes, should be implemented as a matter of urgency and should be handled expeditiously by the existing approvals and publishing process. 6.1. Change Process Proposal We propose that the design team model is the most effective way of engineering process changes. Within the context of the existing IETF process, this could be arranged by constituting a set of design teams with appropriate oversight and the charter of carrying out process change. The design teams would operate within these charters: the overseers would invite design team members to participate, but alternative teams could offer solutions if they feel they have better solutions. The teams should function with an open discussion list, in the same way that the PESCI committee has done. The result of the committee should be tested against the IETF consensus in the normal fashion; we believe that if there is clear IETF consensus that the proposal makes sense, the IESG (and the ISOC Board of Trustees) will respect that consensus and approve of it. Davies Expires April 19, 2006 [Page 18] Internet-Draft PESCI Principles October 2005 6.2. Immediate Tasks for the Change Process Assuming that the model suggested in Section 6.1 is adopted, the following process change task appears to be the most urgent one, and a team should start on this as soon as possible. The most important single management role in the IETF at the moment is that of the IESG, including the role of IETF Chair. This should therefore also receive the most scrutiny. It's unreasonable to ask people to grade their own performance, or to attempt to perform a role at full speed while having to review how it could be done otherwise. Therefore, a review of the roles the IESG has should be rooted outside the IESG - while asking current and former IESG members for information and advice at every opportunity. This should include: o Creating a list of the tasks that currently gate on the IESG o Identifying any additional related tasks that might be appropriate to improve efficiency and effectiveness o Making proposals for discarding or restructuring the existing tasks in combination with the new tasks o Making a proposal for grouping those tasks into separate task groups that can be assigned to different bodies at need. o Developing a proposal for how the standards development work of the IETF should be partitioned to provide optimum efficiency while allowing the IETF to take on all appropriate work. o Developing a suggestion for an initial set of bodies for handling those tasks in the new work partitioning scheme, including, if appropriate, a restructuring of the IESG. o Describing the process by which the set of bodies gets modified. o Describing how members of the proposed bodies get selected, replaced, and (if needed) removed. 7. 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. 8. IANA Considerations This document does not require action by the IANA. However, IANA Davies Expires April 19, 2006 [Page 19] Internet-Draft PESCI Principles October 2005 activities do form part of the IETF process and process changes may affect IANA. 9. 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. 10. Informative References [I-D.carpenter-procdoc-roadmap] Carpenter, B., "The IETF Process: a Roadmap", draft-carpenter-procdoc-roadmap-02 (work in progress), October 2005. [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, Davies Expires April 19, 2006 [Page 20] Internet-Draft PESCI Principles October 2005 February 2004. [RFC3774] Davies, E., "IETF Problem Statement", RFC 3774, May 2004. [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. Raw principles This Appendix is a laundry list of items, not all of which can properly be called principles. Some of them are indeed basic principles, others simply reflect current practice, and yet others summarize recent proposals for change. The purpose of the list was to act as raw material for PESCI in searching for general principles for changing the IETF process, and it is presented here as a matter of record. A.1. General R1. The IETF works by an open process and by rough consensus, and this also applies to process changes. But the IETF also observes experiments and running code with interest, and this should also apply to process changes. Davies Expires April 19, 2006 [Page 21] Internet-Draft PESCI Principles October 2005 R2. The IETF works in areas where it has, or can find, technical competence. R3. The IETF depends on a volunteer core of active participants. R4. Membership of the IETF or of its WGs is not fee based, nor organizationally defined, but is based upon self-identification and active participation by individuals. R5. There is a question of principle of how the IETF, which only recognizes individuals, deals with technical input that comes from another standards organization, i.e. does it get extra weight because it represents collective thinking from a peer group? R6. While the IETF needs clear process rules for the normal cases, there should be enough flexibility to allow unusual cases to be handled according to common sense. We apply personal judgment and only codify when we're certain. (But we do codify who can make personal judgements.) R7. Parts of the process that have proved impractical should be removed or made optional. A.2. Management and Leadership R8. The IETF recognizes leadership positions and grants power of decision to the leaders, but decisions are subject to appeal. R9. The leaders may and should delegate power and responsibility, so long as this is made public and remains subject to appeal. R10. Appeals stop at the IAB and exceptionally the ISOC Board. As a fact of life, there are decisions that can't be *effectively* appealed. But dissent, complaint, and appeal are a consequence of the IETF's nature and should be regarded as normal events. R11. Decision criteria and processes should be publicly documented. R12. Leadership positions are for fixed terms (although we have no formal term limits). R13. People should cycle through leadership positions rather than making them a career. [klensin proposal] Stints of more than four years should be considered exceptional. R14. Leadership positions should be defined such that the workload is compatible with other employment and personal life. Very few leadership positions should require effective full time work. R15. It is important to develop future leaders within the active community. R16. A community process is used to select the leadership. Question: can we devise something better than the random selection of NOMCOM members? R17. The primary consideration in selecting the leadership is personal ability to do the job. (Employer consent to execute the workload is close behind.) Davies Expires April 19, 2006 [Page 22] Internet-Draft PESCI Principles October 2005 R18. Leaders are empowered to make the judgement that rough consensus has been demonstrated. Absent formal membership, there are no formal rules for consensus. R19. The technical leadership is subdivided into * The ADs, assembled as the IESG * [klensin proposal] The Review Panel * The IAB * The IETF Chair * The WG Chairs (appointed by the ADs) R20. The IAB is responsible for architectural oversight, which should include supporting ADs in their guidance and direction roles. R21. [carpenter proposal] It is desirable to separate the role of the IETF Chair from that of chairing the IESG. (Note to ADs: not because I don't like you; indeed it isn't obvious which of the two jobs I'd pick in free space - BC) A.3. Documents (may change after techspec BOF) R22. IETF documents often start as personal drafts, may become WG drafts, and are approved for permanent publication by a leadership body independent of the WG or individuals that produced them. R23. IETF documents belong to the community, not to their authors. But authorship is recognized and valued, as are lesser contributions than full authorship. R24. Technical quality and correctness is the primary criterion for reaching consensus about documents. R25. IETF specifications are not considered to be satisfactory standards until interoperable independent implementations have been demonstrated. (This is the embodiment of the "running code" slogan.) But (on legal advice) the IETF doesn't take responsibility for interop tests and doesn't certify interoperability. R26. IETF specifications may be published as Informational, Experimental, Standards Track, or Best Current Practice. R27. IETF processes are currently published as Best Current Practice. R28. Useful information that is neither a specification nor a process may be published as Informational. R29. Obsolete or deprecated specifications and processes may be downgraded to Historic. R30. The standards track should distinguish specifications that have been demonstrated to interoperate. R31. Standards Track and Best Current Practice documents must be subject to IETF wide rough consensus (Last Call process). WG rough consensus is normally sufficient for other documents. Davies Expires April 19, 2006 [Page 23] Internet-Draft PESCI Principles October 2005 R32. Substantive changes made after a document leaves a WG must be referred back to the WG. R33. The IETF determines requirements for publication and archival of its documents. A.4. Intellectual Property R34. TBD A.5. Protocol Parameter Assignments P35. TBD A.6. Working Groups R36. WGs should be primarily responsible for the quality of their output, and therefore for obtaining early review; the leadership should act as a quality backstop. R37. WGs should be primarily responsible for assessing negative impact of their work on the Internet as a whole, and therefore for obtaining cross-area review; the leadership should act as a cross-area backstop. R38. Early review of documents is more effective in dealing with major problems than late review. R39. ADs are responsible for guiding the formation and chartering of WGs, for giving them direction as necessary, and for terminating them. R40. WG Chairs are responsible for ensuring that WGs execute their charters, meet their milestones, and produce deliverables that are ready for publication. R41. ADs are responsible for arranging backstop review and final document approval. A.7. Other R42. [klensin proposal] It is desirable to separate the work of WG and process management, including "steering" of the IETF, from the work of final review of documents. Appendix B. 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 Davies Expires April 19, 2006 [Page 24] Internet-Draft PESCI Principles October 2005 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. 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. ----- Davies Expires April 19, 2006 [Page 25] Internet-Draft PESCI Principles October 2005 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 - 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. Davies Expires April 19, 2006 [Page 26] Internet-Draft PESCI Principles October 2005 - nothing in this proposal prevents ongoing operational improvements within the current process. Davies Expires April 19, 2006 [Page 27] Internet-Draft PESCI Principles October 2005 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 19, 2006 [Page 28] Internet-Draft PESCI Principles October 2005 Intellectual Property Statement 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. Disclaimer of Validity 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. Copyright Statement Copyright (C) The Internet Society (2005). 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. Acknowledgment Funding for the RFC Editor function is currently provided by the Internet Society. Davies Expires April 19, 2006 [Page 29]