Network Working Group E. Davies, Ed. Request for Comments: 3844 Nortel Networks Category: Informational J. Hofmann, Ed. Wissenschaftszentrum Berlin August 2004 IETF Problem Resolution Process Status of this Memo This memo provides information for the Internet community. It does not specify an Internet standard of any kind. Distribution of this memo is unlimited. Copyright Notice Copyright (C) The Internet Society (2004).
AbstractThis Informational document records the history of discussions in the Problem WG during 2003 of how to resolve the problems described in the IETF Problem Statement. It decomposes each of the problems described into a few areas for improvement and categorizes them as either problems affecting the routine processes used to create standards or problems affecting the fundamental structure and practices of the IETF. Expeditious and non-disruptive solutions are proposed for the problems affecting routine processes. The document also lists suggested ways to handle the development of solutions for the structure and practices problems proposed in IETF discussions. Neither the working group nor the wider IETF has reached consensus on a recommendation for any of the proposals. This document therefore has no alternative but to suggest that the search for structure and practices solutions be handed back to the control of the IESG. While there was working group consensus on the processes for short- term and medium term improvements, there was no working group consensus on the proposals for longer-term improvements. This document therefore includes longer-term improvement proposals only as a matter of record; they must not be regarded as recommendations from the working group.
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 2 2. IETF Purpose and Core Values . . . . . . . . . . . . . . . . . 3 2.1. Non-Core Values . . . . . . . . . . . . . . . . . . . . 4 3. Building on our Success . . . . . . . . . . . . . . . . . . . 4 4. Problem Decomposition . . . . . . . . . . . . . . . . . . . . 5 4.1. Decomposition of Mission Problem . . . . . . . . . . . . 6 4.2. Decomposition of the Engineering Practices Problem . . . 7 4.3. Decomposition of the Complex Problems Problem . . . . . 7 4.4. Decomposition of the Standards Hierarchy Problem . . . . 8 4.5. Decomposition of the Engagement Problem . . . . . . . . 8 4.6. Decomposition of the Management Scaling Problem . . . . 9 4.7. Decomposition of the Working Group Practices Problem . . 11 4.8. Decomposition of the Preparedness Problem . . . . . . . 11 5. Process Recommendations . . . . . . . . . . . . . . . . . . . 11 5.1. Improvements to Routine Processes . . . . . . . . . . . 12 5.1.1. Suggestions to Improve WG Quality Processes . . 13 5.1.2. Suggestions to Increase the Use of Tools . . . . 14 5.1.3. Suggestions to Improve Training. . . . . . . . . 14 5.1.4. Suggestions to Increase WG Chair Communication . 14 5.1.5. Suggestions to Improve Maintenance of Standards. 15 5.2. Changing the Structure and Practices of the IETF . . . . 15 6. Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . 17 7. Security Considerations . . . . . . . . . . . . . . . . . . . 17 Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 18 Normative References . . . . . . . . . . . . . . . . . . . . . 18 Informative References . . . . . . . . . . . . . . . . . . . . 18 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 19 Full Copyright Statement . . . . . . . . . . . . . . . . . . . 20 1].
This document begins with an outline of what are currently thought to be the purpose and core values of the IETF, and it offers a reminder of the good things about the IETF that we don't want to lose in the process of solving our problems. Each of the problems described in the problem statement is analyzed and decomposed into a few areas for improvement. The areas for improvement appear to fall into two categories: o Areas that are essentially independent of the other problems and, hence, can be addressed immediately, via discrete, minimally disruptive changes or improvements to the 'routine' processes of the IETF. o Areas that are interdependent and are likely to affect structural matters that characterize the way in which the IETF operates. Addressing these areas will probably need a more integrated approach, as they may require actions such as fundamental changes to our organizational structure or standards-track processes. It is suggested that the IETF work on these two classes of improvements in parallel, so that we can enjoy some near-term benefits while more structural improvements are being carefully considered and executed. Concrete suggestions are included for how we can begin or continue work on the independent routine improvements. Due to lack of consensus, no firm suggestions are included on how to address the more structural changes that may be needed. The document lists the various proposals which have been considered by the working group and the wider IETF at the IETF 57 plenary session in Vienna, July 2003. This document can only suggest, as some participants have proposed, that the IESG itself control the development of any solutions to the structural problems.
At the IESG plenary in London in July 2002, it was stated that the purpose of the IETF is to "produce high quality, relevant, and timely technical standards for the Internet". Our organizational structure and processes should be judged by how well they help us to achieve that mission. At the following IESG plenary in Atlanta, Georgia in November 2002, five core values of the IETF were presented : "Cares for the Internet" "Technically Competent" "Open Process" "Volunteer Core" "Rough Consensus and Running Code" 8]: - The division into WGs and Areas - The three-step standards process - The ASCII format for RFCs and I-Ds - The format of IETF meetings - The structure of WG mailing lists - The powers of the IESG and IAB These things were designed to help us achieve our goals in a way that is consistent with our core values. If they are no longer effective, we can and should change them.
We are currently suffering difficult times in the IETF and throughout the communications industry. The IETF should be careful not to unjustly blame our own organizational structure or processes for the effects of industry-wide changes such as: o Economic issues in the global communications industry, which are causing increased scrutiny regarding expenses and return-on- investment. These same factors are causing job changes and uncertainty for many IETF participants. o The commercialization of the Internet, which has drastically increased the financial impacts of standardization. o The convergence of the datacom and telecom sectors of the communications industry, which has led to an influx of experienced people into the IETF with a different culture and industry perspective. Although it is important to recognize and correct the serious organizational problems currently facing the IETF, many of these problems have existed for years, and the IETF has been successful in spite of these issues. We should not overreact to these issues with sweeping revolutionary changes to the IETF structure and processes. Instead, we should focus on developing a culture of continuous operational improvement through which we can evolve our organizational structure and processes to make them more scalable and effective. We should take this opportunity to develop the mechanisms and processes that we can use to continually monitor and improve our organizational effectiveness, both in good times and bad times. The IETF currently has a large amount of valuable work underway, and care should be taken not to disrupt or delay that work while we address our organizational problems. The IETF is also fortunate to have a large number of extremely talented and dedicated individuals that serve in formal and informal leadership roles throughout the organization. We should be careful not to alienate or disenfranchise the IETF's key contributors and those who provide the driving force for the work while making organizational or process changes.
o Participants in the IETF do not share a common understanding of its mission; o The IETF does not consistently use effective engineering practices; o The IETF has difficulty handling large and/or complex problems; o The three stage standards hierarchy is not properly utilized; o The IETF's workload exceeds the number of fully engaged participants; o The IETF management structure is not matched to the current size and complexity of the IETF; o Working group practices can make issue closure difficult; and o IETF participants and leaders are inadequately prepared for their roles. Analysis of these problems indicates that they can be decomposed into several areas for improvement, some of which can be addressed immediately by independent actions while others require greater consideration and a more structured approach to a solution. It is also important to note that the problem statement lists problems that have been reported by some members of the IETF. Although all of these problems are believed to exist, not all of these problems are present in all parts of the IETF, and some of these problems may in fact be symptoms of other problems.
what is in-scope and out-of-scope for the organization. We will also need to define our goals and priorities, and learn how to recognize and measure our own progress and success. A continuing review of the mission and goals of the IETF needs to be undertaken to ensure that they remain aligned with technology developments as well as the needs of the industry in general and our stakeholders in particular. Once an understanding of the mission and goals of the IETF has been articulated, we should train new participants on those principles, so that they can become quickly acclimated to the IETF culture.
Today most communication between WG chairs, especially across area boundaries, goes through the IESG. Some inter-WG or inter-area communication problems could be alleviated by greater communication and coordination directly between the chairs of related WGs. There are some immediate efforts underway that are intended to increase communication between WG chairs. Other complex problems involve higher-level issues, such as unified architecture or highly-coordinated multi-area efforts. As part of any IETF reorganization, we should consider management structures that will allow us to achieve a better focus on architectural and cross-area issues.
o WG documents are not adequately reviewed by people outside of the originating WG. o People lose interest in longer-lived WGs, especially when protocols take a very long time to develop. When too few people, or people representing too few areas of expertise, review WG documents this can result in poor quality output. We need to find ways to increase the effectiveness of document review at all levels. Quality processes based entirely on a gatekeeper at the end, whether that gatekeeper is the IESG or a WG review board, tend to result in a lower focus on quality by other participants. So, it is likely that instituting better quality processes throughout document development, including acceptance criteria and review at several stages, would increase the focus of WG participants on document quality. When the interest of document editors or key contributors starts to lag, this can cause serious problems for a WG. This most often happens when WGs are floundering, or when charters are so loose that WGs lose focus. It also happens when WG documents get delayed in AD review and/or IESG review for long periods with little feedback, or when the WG lacks consensus to progress its documents. Improvements to our processes for chartering, tracking or managing WGs could help to alleviate many of these problems. We also need to better understand what motivates people to become deeply engaged in the IETF and to remain engaged. It is possible that expanding the number of formal leadership positions and/or coming up with more effective ways to acknowledge our top technical contributors could encourage more people to become, and remain, deeply engaged in IETF.
members, etc.). In its current form, there are very few people who could do a good job as an IESG member, and the huge time commitment and responsibilities of this role make it very difficult to find qualified people who are willing to serve on the IESG. o Current IESG members and other IETF leaders are overloaded. o The IETF selection processes have tended to select leaders (IESG, IAB and WG chairs) from the same small pool of people. The IETF needs to identify and develop additional leadership, and to delegate real authority and influence to a larger group. o The IETF is not effective at identifying and developing new leaders, and we lack sufficient recognition for the contributions of IETF participants. o One or two IESG members can block WG documents indefinitely (in AD review or IESG review). Some level of IETF reorganization is needed to improve in the first two areas. This should be undertaken as part of the structural improvement effort. In parallel with any more structural IETF reorganization, some relief could be achieved by modifying IESG internal processes to remove the potential for one or two IESG members to indefinitely delay a WG document, either on purpose or due to work overload. The I-D tracker has already resulted in some improvement in this area, as it has created visibility regarding how and why a document is being delayed, but it may not have resolved all of the issues in this area. The IESG may also be able to take near-term steps, with community visibility and agreement, to delegate more work to WG chairs, to directorates, to the IAB, or to other people in formal or informal leadership positions. If additional leadership positions are needed for this purpose, the IESG should consider creating them. The IESG could also help to expand the leadership pool of the IETF by actively seeking interested and qualified people for leadership positions, and by using more open processes for the selection of WG chairs and other influential positions.
this document. Ongoing efforts should continue, and new efforts should start as soon as there is IETF consensus that they are worthwhile. In our improvement processes, we should attempt to focus our near- term improvements on areas of routine that are less likely to be substantially modified by any proposed structural changes, thus minimizing the likelihood of double changes.
2. Increase the availability and use of issue tracking and document sharing/revision control software in the IETF. 3. Improve training and resources for IETF leaders and participants at all levels. 4. Improved communication between WG chairs to identify and resolve inter-WG and inter-area problems. 5. Consider IETF processes or structures to better maintain IETF standards. 6. Modify IESG-internal processes to make it impossible for one or two IESG members to indefinitely delay a document. 7. Modify IESG processes to delegate more responsibility to WG chairs, to directorates, to the IAB or to people in other formal or informal leadership positions. 8. Modify the WG chair selection processes to widen the group of people considered, and consider ways to develop more leaders for the IETF. 9. Initiate regular AD review of WG milestones and progress. Applying the criteria outlined above, it would make the most sense to address areas 1, 2, 3, 4, and 5 through immediate near-term efforts. These are high-priority issues, they are sufficiently separable to be pursued in parallel, they place minimal additional burden on the IESG, and they are the least likely to be affected by an IESG/IAB-level reorganization of the IETF, or by changes to the standards-track document maturity level classification and process. Specific recommendations for how to proceed in each of these areas are made in the following sections. The IESG should consider internal changes to address areas 6, 7, and 8. Area 9 would require a substantial time commitment from IESG members, so it is not suggested that near-term improvements be pursued in this area, unless the IESG believes that the near-term benefits would justify the effort.
output. This WG would be chartered to resolve the non-tools-related portions of the Engineering Practices problem (Section 4.2) the WG- related portions of the Engagement Problem (Section 4.5), and the non-training-related portions of the WG Practices problem (Section 4.7). A great deal of efficiency and synergy can be achieved by adopting common processes throughout an organization. However, it is a strength of the IETF that WG chairs are given a great deal of latitude to choose their own processes and tools, based on the size and nature of their WGs. So, in general, processes and tools should be made available to WGs and WG chairs, not forced upon them. Section 4.2). Section 4.8), and the training-related portions of the Mission Problem (Section 4.1) and the WG Practices problem (Section 4.7).
However, most of the responsibility for establishing effective chair-to-chair communications channels lies with the individual WG chairs. We should stop relying on the IESG to resolve inter-WG issues, and start communicating with each other directly regarding inter-WG issues. These efforts may help to alleviate the Complex Problems problem (Section 4.3), although a comprehensive solution to that problem would probably require some changes to the IETF management structures. Section 4.4). Section 4 the problems which might require such alterations include: o The Mission Problem (Section 4.1, ), o the Complex Problems problem (Section 4.3, , ), o the Standards Hierarchy problem (Section 4.4, ), o the Management Scaling problem (Section 4.6, , , ), and o The longer-term portions of the Engagement Problem (Section 4.5, ) (Additional references on each item indicate associated documents that may need to be updated as a result of this process.) Poorly thought through changes to these areas could result in irretrievable damage to the nature and effectiveness of the IETF, but it seems essential that the necessary changes are identified and accepted by the IETF community as quickly as possible. To achieve acceptance by the largest possible number of IETF stakeholders, as
many of them as possible should be involved in the development of the changes; the development and acceptance processes must be as open as possible in line with normal IETF principles. Development of the required changes under the aegis of a General Area Working Group was extensively debated and a proposal was floated in a previous version of this document. The proposal included a draft charter for the working group. This way forwards has now been rejected by the Problem working group because of the perceived slow progress of such groups, the difference in the nature of the problem from the usual technical problems solved by IETF working groups and the difficulty in achieving acceptance by all segments of the community for work driven by a small group. A proposal for coordination of the development of the structural changes by a 'Strategy and Answers Panel' composed of delegates from IESG, IAB, and ISOC plus a number of members from the wider IETF community (forming a small majority of the panel) selected using the nomcom selection process can be found in . The selection process was intended to create a panel which would represent the interests of the whole IETF community and so build solutions that would be acceptable to the whole community. This proposal has not received extensive support from the Problem working group either. Other proposals advanced in discussions are: o Delegation of the development of solutions to a team of 'wise men' appointed by the IESG. o Development of solutions by a design team with final approval by the IESG. o Development and implementation of the solutions by the IESG. Discussions of alternative processes on the mailing list, at the Problem WG meeting at IETF 57 and in the IETF 57 plenary did not reach a consensus. Indeed some contributors took the view that the problems could be overcome without (major) structural changes. Given the lack of consensus and the lack of additional responses to a previous appeal for alternative suggestions, this document has to fall back to asking the IESG to take responsibility for controlling the development of solutions to the structural problems identified where it believes they are necessary.
Section 3: Evolutionary rather than revolutionary proposals are more likely to be acceptable, and an orderly transition must be possible. Working together, we can resolve the problems currently facing the IETF and make the IETF an even more effective, successful, and fun place to work.
 Davies, E., "IETF Problem Statement", RFC 3774, May 2004.  Galvin, J., "IAB and IESG Selection, Confirmation, and Recall Process: Operation of the Nominating and Recall Committees", RFC 2727, February 2000.  Alvestrand, H., "An IESG charter", Work in Progress, April 2003.  Bradner, S., "The Internet Standards Process -- Revision 3", BCP 9, RFC 2026, October 1996.  Bradner, S., "IETF Working Group Guidelines and Procedures", BCP 25, RFC 2418, September 1998.  Internet Architecture Board and B. Carpenter, "Charter of the Internet Architecture Board (IAB)", BCP 39, RFC 2850, May 2000.  Harris, S., "The Tao of IETF - A Novice's Guide to the Internet Engineering Task Force", RFC 3160, August 2001.  IETF, "Minutes of IESG Plenary at IETF55, Atlanta, GA, USA", Nov 2002, <http://www.ietf.org/proceedings/02nov/slides/plenary- 2/sld4.htm>.  Davies, E., Doria, A., and J. Hofmann, "IETF Structural Problems Improvement Process", Work in Progress, September 2003.
Full Copyright Statement Copyright (C) The Internet Society (2004). 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- firstname.lastname@example.org. Acknowledgement Funding for the RFC Editor function is currently provided by the Internet Society.