summaryrefslogtreecommitdiff
path: root/doc/rfc/rfc3844.txt
diff options
context:
space:
mode:
Diffstat (limited to 'doc/rfc/rfc3844.txt')
-rw-r--r--doc/rfc/rfc3844.txt1123
1 files changed, 1123 insertions, 0 deletions
diff --git a/doc/rfc/rfc3844.txt b/doc/rfc/rfc3844.txt
new file mode 100644
index 0000000..01a7935
--- /dev/null
+++ b/doc/rfc/rfc3844.txt
@@ -0,0 +1,1123 @@
+
+
+
+
+
+
+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).
+
+Abstract
+
+ This 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.
+
+
+
+
+
+
+
+Davies & Hofmann Informational [Page 1]
+
+RFC 3844 IETF Problem Resolution Process August 2004
+
+
+Table of Contents
+
+ 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. Introduction
+
+ This document suggests processes to address several problems facing
+ the Internet Engineering Task Force (IETF) that have been described
+ in the IETF Problem Statement [1].
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Davies & Hofmann Informational [Page 2]
+
+RFC 3844 IETF Problem Resolution Process August 2004
+
+
+ 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.
+
+2. IETF Purpose and Core Values
+
+ As we consider how to address the problems with the IETF processes
+ and organizational structure, it is important to keep in mind the
+ things about the IETF that we don't want to change -- our sense of
+ purpose, and the core values that give the IETF its unique identity.
+
+ At two IESG plenary meetings in 2002, the chair of the IETF, gave
+ presentations outlining his view of the purpose and core values of
+ the IETF which may serve as a useful basis for focusing on our
+ mission and core values.
+
+
+
+
+Davies & Hofmann Informational [Page 3]
+
+RFC 3844 IETF Problem Resolution Process August 2004
+
+
+ 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 [8]:
+
+ "Cares for the Internet"
+ "Technically Competent"
+ "Open Process"
+ "Volunteer Core"
+ "Rough Consensus and Running Code"
+
+2.1. Non-Core Values
+
+ Understanding our core values will also help us to understand the
+ long-standing features of the IETF that we can change without
+ compromising our values or sacrificing our unique identity.
+
+ During the November 2002 IESG Plenary, the IETF chair also presented
+ the following "non-core values" [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.
+
+3. Building on our Success
+
+ While focusing on our operational problems, we shouldn't forget that
+ the IETF is a very successful organization. We are responsible for
+ some of the most widely used communications standards in the world,
+ and we have contributed to the creation and growth of the Internet,
+ one of the greatest technical and social achievements of our time.
+
+ In good times, it is easy to succeed despite operational
+ inefficiencies, so organizations tend to ignore operational problems
+ and focus on their success. In bad times, organizations can become
+ overly critical of their own structure and processes, blaming the
+ organization for problems that are actually caused by outside forces.
+
+
+
+Davies & Hofmann Informational [Page 4]
+
+RFC 3844 IETF Problem Resolution Process August 2004
+
+
+ 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.
+
+4. Problem Decomposition
+
+ The problem statement document lists seven root cause problems
+ currently facing the IETF, without making any judgements about the
+ relative priority of the problems (apart from the first one):
+
+
+
+
+
+Davies & Hofmann Informational [Page 5]
+
+RFC 3844 IETF Problem Resolution Process August 2004
+
+
+ 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.
+
+4.1. Decomposition of Mission Problem
+
+ In order to determine the best organization and processes for the
+ IETF to fulfill its mission and achieve its goals, the organization
+ needs to articulate a common understanding of its current mission and
+ goals. Although it should be possible to reach an understanding of
+ the mission and goals of the IETF as an independent action, with no
+ disruption to current processes, this effort would be most valuable
+ as part of an effort to align the organization and priorities of the
+ IETF with its mission.
+
+ As part of understanding our mission, the IETF will need to identify
+ our stakeholders and understand how we serve them. We will need to
+ define the scope of the IETF, so that it is possible to determine
+
+
+
+
+
+Davies & Hofmann Informational [Page 6]
+
+RFC 3844 IETF Problem Resolution Process August 2004
+
+
+ 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.
+
+4.2. Decomposition of the Engineering Practices Problem
+
+ The IETF lacks effective engineering practices in four major areas:
+
+ 1. Failure to clearly define the scope of the work, engineering
+ trade-offs and acceptance criteria for each project.
+
+ 2. Lack of effective mechanisms for issue tracking and/or document
+ change control.
+
+ 3. Lack of effective processes to ensure quality throughout the
+ development of IETF work items, such as intermediate acceptance
+ criteria or formal review processes.
+
+ 4. Sufficient focus on milestones, and recognition or rewards for
+ individuals or groups that achieve timely, high quality
+ execution.
+
+ Some of these areas (issue tracking and revision control) would
+ require that tools are made available to WG chairs and editors, and
+ that IETF participants (at various levels) are educated in how to use
+ them.
+
+ The other areas concern the formation and process management of IETF
+ WGs, and would require documentation and adoption of effective
+ engineering processes within IETF WGs.
+
+4.3. Decomposition of the Complex Problems Problem
+
+ The IETF has effective mechanisms for dealing with well-defined
+ problems of limited scope. These problems are well handled in IETF
+ WGs, where experts in a given technology can convene and solve the
+ problems specific to one technology area. However, we are much less
+ effective at resolving complex problems that affect more than one
+ IETF WG or area.
+
+
+
+Davies & Hofmann Informational [Page 7]
+
+RFC 3844 IETF Problem Resolution Process August 2004
+
+
+ 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.
+
+4.4. Decomposition of the Standards Hierarchy Problem
+
+ There are several problems with the IETF's three-track standards
+ process. These problems can be grouped as follows:
+
+ o The three standards-track steps are not used effectively within
+ the IETF.
+
+ o The IETF standards-track is not well understood by the users of
+ IETF standards.
+
+ o The current standards process does not make it easy for users to
+ locate a set of related documents, such as an architectural
+ framework and associated protocols.
+
+ o The IETF does not have an effective way to maintain IETF
+ standards.
+
+ Major changes to the standards-track should only be considered as
+ part of an integrated structural review process that includes an
+ understanding of our mission and goals.
+
+ However, there may be immediate changes that we could make to better
+ maintain current IETF standards, or to make them more accessible to
+ users.
+
+4.5. Decomposition of the Engagement Problem
+
+ The engagement problem can be decomposed into three primary issues:
+
+ o Some WGs do not have sufficient participation, and WG documents
+ are often produced by very small groups of people, perhaps with
+ limited expertise in some relevant areas.
+
+
+
+
+
+Davies & Hofmann Informational [Page 8]
+
+RFC 3844 IETF Problem Resolution Process August 2004
+
+
+ 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.
+
+4.6. Decomposition of the Management Scaling Problem
+
+ There are several issues grouped into the concept that the management
+ structure of the IETF is not well matched to the size and complexity
+ of the organization. One or two of these problems might be addressed
+ by immediate solutions, but resolving the primary problem will
+ require some type of IETF reorganization.
+
+ There are five major areas for improvement that are grouped under
+ this problem:
+
+ o The current organization of the IETF does not scale. IESG members
+ are running too many WGs, reviewing too many documents, etc. Most
+ IESG members have dozens of direct reports (WG chairs, directorate
+
+
+
+Davies & Hofmann Informational [Page 9]
+
+RFC 3844 IETF Problem Resolution Process August 2004
+
+
+ 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.
+
+
+
+
+
+
+
+
+
+Davies & Hofmann Informational [Page 10]
+
+RFC 3844 IETF Problem Resolution Process August 2004
+
+
+4.7. Decomposition of the Working Group Practices Problem
+
+ Although "rough consensus" is considered a core value of the IETF,
+ consensus-based decision making works best in smaller groups with a
+ common viewpoint and common goals. Somehow we need to resolve the
+ apparent conflict between our core values regarding rough consensus,
+ and our desire to be an effective organization with several thousand
+ participants.
+
+ Although consensus-based decision making has some inherent issues,
+ there are some problems in the IETF that exacerbate these issues:
+
+ o WG chairs may lack the skills and training to deal with common
+ behavior problems that undermine or prevent consensus.
+
+ o IETF participants are often unaware of how the IETF decision-
+ making processes are intended to work.
+
+ o WG chairs and participants often lack good conflict resolution
+ skills.
+
+ Each of these issues could be addressed through training or other
+ educational resources.
+
+4.8. Decomposition of the Preparedness Problem
+
+ The IETF could benefit from training and educational resources that
+ increase the preparedness of IETF participants and leaders at all
+ levels.
+
+ The IETF currently has formal training programs for new attendees and
+ for new working group chairs. However, our current training programs
+ could use some improvement. There are also several other groups who
+ could benefit from training or other forms of development (web
+ tutorials, on-line resources, references, mentoring, etc.), including
+ continuing attendees, experienced WG chairs, document editors and
+ IESG members.
+
+ There is an effort underway to improve the IETF's internal education
+ programs, and we recommend that it be continued.
+
+5. Process Recommendations
+
+ It is the overall recommendation of this document that we pursue
+ near-term improvements to resolve IETF problems of routine in
+ parallel with an integrated effort to reorganize the IETF and improve
+ our standards processes. None of the efforts suggested in this
+ document should be blocked pending the completion and publication of
+
+
+
+Davies & Hofmann Informational [Page 11]
+
+RFC 3844 IETF Problem Resolution Process August 2004
+
+
+ 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.
+
+5.1. Improvements to Routine Processes
+
+ Many of the problems currently facing the IETF can be resolved, or
+ mitigated, through near-term improvements to our current IETF
+ organization and routine processes. Many of these improvements are
+ completely separable, and there is no reason to aggregate these
+ efforts into a single IETF WG. It is also unnecessary that all of
+ these changes be directed by the (already overworked) IESG.
+
+ However, in order to prevent the chaos and confusion that could be
+ caused by trying to change everything at once, it is recommended that
+ we choose a few high priority areas for improvement and focus on
+ making improvements in those areas.
+
+ In choosing which areas to pursue first, we should consider the
+ following criteria:
+
+ o We should address our most urgent, important problems.
+
+ o The areas chosen should be cleanly separable, to allow multiple
+ improvements to be carried out in parallel with minimal
+ interference.
+
+ o We should maximize the benefit vs. the cost of making the
+ improvements (i.e., look for low hanging fruit).
+
+ o As much as possible, we should focus on improvements that are less
+ likely to be completely invalidated by an overhaul of the IETF
+ management structure. This might be accomplished by focusing on
+ improvements at the WG and participant levels, rather than at the
+ IESG/IAB level.
+
+ In the sections above, we have identified several areas of routine
+ that could benefit from near-term improvements, including:
+
+ 1. Improve WG quality processes and the effectiveness of document
+ reviews at all levels.
+
+
+
+
+
+Davies & Hofmann Informational [Page 12]
+
+RFC 3844 IETF Problem Resolution Process August 2004
+
+
+ 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.
+
+5.1.1. Suggestions to Improve WG Quality Processes
+
+ A working group should be formed in the General Area of the IETF to
+ oversee improvements to the WG quality processes, including: The WG
+ (re-)chartering process, the quality processes used by IETF WGs, and
+ the effectiveness of IETF reviews at all levels. It should be the
+ goal of this WG to improve the quality and timeliness of WG work
+
+
+
+Davies & Hofmann Informational [Page 13]
+
+RFC 3844 IETF Problem Resolution Process August 2004
+
+
+ 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.
+
+5.1.2. Suggestions to Increase the Use of Tools
+
+ Ideally, the proliferation of tools within the IETF would be
+ accomplished via grass-roots efforts, organized by participants
+ within the IETF. One example of this type of effort is the recent
+ adoption of Jabber for use during IETF meetings.
+
+ However, it is also possible that the IESG could designate functional
+ leaders for specific tools-related efforts and support those leaders
+ in organizing those efforts. It also might be helpful for the IETF
+ to set-aside some technical and systems resources, to make useful
+ tools available to WGs and participants throughout the IETF.
+
+ These efforts should resolve the tools-related portions of the
+ Engineering Practices problem (Section 4.2).
+
+5.1.3. Suggestions to Improve Training
+
+ The current WG chairs and newcomer's training efforts should be
+ continued and expanded as appropriate to cover training for other
+ groups. This effort is expected to address the Preparedness problem
+ (Section 4.8), and the training-related portions of the Mission
+ Problem (Section 4.1) and the WG Practices problem (Section 4.7).
+
+5.1.4. Suggestions to Increase WG Chair Communication
+
+ Some efforts are already underway to allow WG chairs to meet each
+ other, and to give them opportunities to establish communication
+ channels. These efforts include WG chair socials and training
+ sessions for experienced WG chairs. These efforts should be
+ continued.
+
+ The IESG could help to promote chair-to-chair communication by
+ encouraging direct communication between WG chairs when multi-WG
+ issues arise.
+
+
+
+Davies & Hofmann Informational [Page 14]
+
+RFC 3844 IETF Problem Resolution Process August 2004
+
+
+ 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.
+
+5.1.5. Suggestions to Improve Maintenance of Standards
+
+ The IETF should consider proposals to improve the way that IETF
+ standards are maintained. It might be possible for the IESG to
+ document and implement a mechanism to maintain IETF standards without
+ the need for a WG to enact this change.
+
+ This effort should address the maintenance-related portions of the
+ Standards Hierarchy problem (Section 4.4).
+
+5.2. Changing the Structure and Practices of the IETF
+
+ A significant number of the issues that were identified in the IETF
+ Problem Statement appear to require alterations to the structure of
+ the IETF and/or the core practices which effectively characterize the
+ IETF. From the analysis in Section 4 the problems which might
+ require such alterations include:
+
+ o The Mission Problem (Section 4.1, [7]),
+
+ o the Complex Problems problem (Section 4.3, [3], [6]),
+
+ o the Standards Hierarchy problem (Section 4.4, [4]),
+
+ o the Management Scaling problem (Section 4.6, [6], [3], [2]), and
+
+ o The longer-term portions of the Engagement Problem (Section 4.5,
+ [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
+
+
+
+Davies & Hofmann Informational [Page 15]
+
+RFC 3844 IETF Problem Resolution Process August 2004
+
+
+ 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 [9]. 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.
+
+
+
+Davies & Hofmann Informational [Page 16]
+
+RFC 3844 IETF Problem Resolution Process August 2004
+
+
+6. Conclusion
+
+ The IETF has problems, and we need to work to solve those problems,
+ both via focused immediate improvements and possibly via an
+ integrated effort to build an IETF organizational structure and
+ develop processes that can better handle our current size and
+ complexity.
+
+ However, the IETF is also an effective organization with a long
+ tradition of excellence, and core values that we don't want to
+ compromise in the course of improving our organization and processes.
+ So, any major changes undertaken in the IETF should include an
+ articulation of the IETF's mission and our core values, so that we
+ can ensure that we build an organization that can carry out our
+ mission working in line with our core values.
+
+ The Problem WG has not been able to come to a consensus on a process
+ that could address the structural changes that may or may not be
+ needed. This is perhaps in line with previous experience of the
+ discussion of high level concepts in the IETF - the organization is
+ in general much better at discussion of and achieving consensus on
+ detailed concrete proposals. This document has little alternative
+ but to suggest that the IESG control the development of solutions to
+ any of the structural problems where they feel that changes are
+ necessary.
+
+ In the meantime, this should not be seen as gating discussions on
+ actual solutions for these problems - for example, the active
+ discussions that are in progress on alternatives to the current
+ maturity level system for IETF standards. Authors of solutions
+ should bear in mind the points made in 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.
+
+7. Security Considerations
+
+ This document contains suggestions for processes that the IETF could
+ use to resolve process-related and organizational problems with the
+ IETF. Although the structure and quality of the IETF's processes may
+ have an affect on the quality of the IETF's security-related work,
+ there are no specific security-related issues raised in this
+ document.
+
+
+
+
+
+Davies & Hofmann Informational [Page 17]
+
+RFC 3844 IETF Problem Resolution Process August 2004
+
+
+Acknowledgements
+
+ The contents of this document were greatly influenced by members of
+ the Problem Statement WG editorial team: Rob Austein, Dave Crocker,
+ Elwyn Davies, Spencer Dawkins, Avri Doria, Jeanette Hofmann, Melinda
+ Shore, and Margaret Wasserman.
+
+ Previous versions of this document were edited by Margaret Wasserman,
+ who was responsible for the original structuring of the solution.
+
+ In addition to the editorial team, the following people have provided
+ useful feedback on earlier versions of this document: Harald
+ Alvestrand, Randy Bush, Brian Carpenter, Leslie Daigle, James Kempf,
+ John Klensin, John Loughney, and Keith Moore.
+
+Normative References
+
+ [1] Davies, E., "IETF Problem Statement", RFC 3774, May 2004.
+
+ [2] Galvin, J., "IAB and IESG Selection, Confirmation, and Recall
+ Process: Operation of the Nominating and Recall Committees", RFC
+ 2727, February 2000.
+
+Informative References
+
+ [3] Alvestrand, H., "An IESG charter", Work in Progress, April 2003.
+
+ [4] Bradner, S., "The Internet Standards Process -- Revision 3", BCP
+ 9, RFC 2026, October 1996.
+
+ [5] Bradner, S., "IETF Working Group Guidelines and Procedures", BCP
+ 25, RFC 2418, September 1998.
+
+ [6] Internet Architecture Board and B. Carpenter, "Charter of the
+ Internet Architecture Board (IAB)", BCP 39, RFC 2850, May 2000.
+
+ [7] Harris, S., "The Tao of IETF - A Novice's Guide to the Internet
+ Engineering Task Force", RFC 3160, August 2001.
+
+ [8] IETF, "Minutes of IESG Plenary at IETF55, Atlanta, GA, USA", Nov
+ 2002, <http://www.ietf.org/proceedings/02nov/slides/plenary-
+ 2/sld4.htm>.
+
+ [9] Davies, E., Doria, A., and J. Hofmann, "IETF Structural Problems
+ Improvement Process", Work in Progress, September 2003.
+
+
+
+
+
+
+Davies & Hofmann Informational [Page 18]
+
+RFC 3844 IETF Problem Resolution Process August 2004
+
+
+Authors' Addresses
+
+ Elwyn B. Davies (editor)
+ Nortel Networks
+ Harlow Laboratories
+ London Road
+ Harlow, Essex CM17 9NA
+ UK
+
+ Phone: +44 1279 405 498
+ EMail: elwynd@nortelnetworks.com
+
+
+ Jeanette Hofmann (editor)
+ Wissenschaftszentrum Berlin
+ Reichpietschufer 50
+ Berlin 10785
+ Germany
+
+ Phone: +49 30 25491 288
+ EMail: jeanette@wz-berlin.de
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Davies & Hofmann Informational [Page 19]
+
+RFC 3844 IETF Problem Resolution Process August 2004
+
+
+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-
+ ipr@ietf.org.
+
+Acknowledgement
+
+ Funding for the RFC Editor function is currently provided by the
+ Internet Society.
+
+
+
+
+
+
+
+
+
+Davies & Hofmann Informational [Page 20]
+