GENWiki

Premier IT Outsourcing and Support Services within the UK

User Tools

Site Tools


rfc:rfc3844

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]:
  1. The division into WGs and Areas
  2. The three-step standards process
  3. The ASCII format for RFCs and I-Ds
  4. The format of IETF meetings
  5. The structure of WG mailing lists
  6. 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]

/data/webs/external/dokuwiki/data/pages/rfc/rfc3844.txt · Last modified: 2004/08/23 19:02 (external edit)