[Docs] [txt|pdf] [Tracker] [WG] [Email] [Diff1] [Diff2] [Nits]

Versions: 00 01 02 03 04 RFC 3844

Problem Statement                                         E. Davies, Ed.
Internet-Draft                                           Nortel Networks
Expires: April 25, 2004                                  J. Hofmann, Ed.
                                             Wissenschaftszentrum Berlin
                                                        October 26, 2003


                    IETF Problem Resolution Process
                   draft-ietf-problem-process-03.txt

Status of this Memo

   This document is an Internet-Draft and is in full conformance with
   all provisions of Section 10 of RFC2026.

   Internet-Drafts are working documents of the Internet Engineering
   Task Force (IETF), its areas, and its working groups. Note that other
   groups may also distribute working documents as Internet-Drafts.

   Internet-Drafts are draft documents valid for a maximum of six months
   and may be updated, replaced, or obsoleted by other documents at any
   time. It is inappropriate to use Internet-Drafts as reference
   material or to cite them other than as "work in progress."

   The list of current Internet-Drafts can be accessed at http://
   www.ietf.org/ietf/1id-abstracts.txt.

   The list of Internet-Draft Shadow Directories can be accessed at
   http://www.ietf.org/shadow.html.

   This Internet-Draft will expire on April 25, 2004.

Copyright Notice

   Copyright (C) The Internet Society (2003). All Rights Reserved.

Abstract

   This document suggests processes to address some of the problems
   identified in the IETF Problem Statement.

   This document decomposes each of the problems described in the
   problem statement into a few areas for improvement, categorizes them
   either as problems affecting the routine processes used to create
   standards or problems affecting the fundamental structure and
   practices of the IETF, and suggests ways to address the problems with
   the routine processes that can be implemented as soon as possible
   without disrupting other areas of the IETF processes.




Davies & Hofmann         Expires April 25, 2004                 [Page 1]

Internet-Draft          IETF Problem Resolution             October 2003


   A number of ways to handle development of solutions for the structure
   and practices problems have been proposed in previous versions of
   this draft, on the 'problems' mailing list and at an IETF 57 plenary
   session in Vienna during July 2003. This draft lists the various
   solutions that have been proposed but neither the working group nor
   the wider IETF has reached consensus on a recommendation for any of
   the proposals.

   In this situation, this draft has no alternative but to suggest that
   the search for structure and practices solutions is handed back to
   the control of the IESG.

Table of Contents

   1.    Introduction . . . . . . . . . . . . . . . . . . . . . . . .  3
   1.1   Acknowledgements . . . . . . . . . . . . . . . . . . . . . .  3
   1.2   Major Changes between Versions 01 and 02 . . . . . . . . . .  4
   1.3   Major Changes between Versions 02 and 03 . . . . . . . . . .  4
   2.    IETF Purpose and Core Values . . . . . . . . . . . . . . . .  5
   2.1   Non-Core Values  . . . . . . . . . . . . . . . . . . . . . .  5
   3.    Building on our Success  . . . . . . . . . . . . . . . . . .  6
   4.    Problem Decomposition  . . . . . . . . . . . . . . . . . . .  7
   4.1   Decomposition of Mission Problem . . . . . . . . . . . . . .  7
   4.2   Decomposition of the Engineering Practices Problem . . . . .  8
   4.3   Decomposition of the Complex Problems Problem  . . . . . . .  9
   4.4   Decomposition of the Standards Hierarchy Problem . . . . . .  9
   4.5   Decomposition of the Engagement Problem  . . . . . . . . . . 10
   4.6   Decomposition of the Management Scaling Problem  . . . . . . 10
   4.7   Decomposition of the Working Group Practices Problem . . . . 12
   4.8   Decomposition of the Preparedness Problem  . . . . . . . . . 12
   5.    Process Recommendations  . . . . . . . . . . . . . . . . . . 12
   5.1   Improvements to Routine Processes  . . . . . . . . . . . . . 13
   5.1.1 Suggestions to Improve WG Quality Processes  . . . . . . . . 14
   5.1.2 Suggestions to Increase the Use of Tools . . . . . . . . . . 15
   5.1.3 Suggestions to Improve Training  . . . . . . . . . . . . . . 15
   5.1.4 Suggestions to Increase WG Chair Communication . . . . . . . 15
   5.1.5 Suggestions to Improve Maintenance of Standards  . . . . . . 16
   5.2   Changing the Structure and Practices of the IETF . . . . . . 16
   6.    Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . 18
   7.    Security Considerations  . . . . . . . . . . . . . . . . . . 18
         Normative References . . . . . . . . . . . . . . . . . . . . 19
         Informative References . . . . . . . . . . . . . . . . . . . 19
         Authors' Addresses . . . . . . . . . . . . . . . . . . . . . 20
         Intellectual Property and Copyright Statements . . . . . . . 21







Davies & Hofmann         Expires April 25, 2004                 [Page 2]

Internet-Draft          IETF Problem Resolution             October 2003


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].

   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 draft
   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 draft can only suggest, as some participants have
   proposed, that the IESG itself control the development of any
   solutions to the structural problems.

1.1 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.



Davies & Hofmann         Expires April 25, 2004                 [Page 3]

Internet-Draft          IETF Problem Resolution             October 2003


   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, Keith Moore.

1.2 Major Changes between Versions 01 and 02

   o  The commentary on the individual core values in Section 2 was
      removed.  This commentary was interesting but it did not appear to
      be relevant to the process proposal but was rather part of the
      solution process to the structural problems of the IETF.  It was
      also unbalancing the document, making the introductory text too
      long.

   o  The acknowledgements section was moved forwards to the
      introduction.

   o  At IETF 57 and on the mailing list, the WG decided that the
      proposal for a WG to address 'long-term' structural issues was
      inappropriate, but neither the WG at the meeting and on the
      mailing list since, nor the wider IETF in the plenary discussion
      at IETF 57 has been able to come to consensus on an acceptable
      alternative.  Accordingly the new version of the draft is only
      able to document this situation and propose that IETF stakeholders
      come up with some alternatives which can be debated, and hopefully
      one of them agreed on. The abstract, introduction, Section 5.2 and
      conclusion have been modified to reflect this state of affairs,
      and the Appendix which offered a proposed WG charter has been
      removed.

   o  In the light of comments about the change processes being
      potentially too slow, the descriptions of the problems as
      'near-term' and 'long(er)-term' have been replaced by 'routine'
      and 'structural' although 'near-term' is still used where it is
      appropriate to emphasize that immediate action can be taken.


1.3 Major Changes between Versions 02 and 03

   The draft now lists the various suggestions that have been floated as
   ways forward for the structural changes problems, documents the
   inability of the community to achieve consensus around any of these
   proposals and suggests that the problem is remitted to the control of
   the IESG.




Davies & Hofmann         Expires April 25, 2004                 [Page 4]

Internet-Draft          IETF Problem Resolution             October 2003


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.

   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.




Davies & Hofmann         Expires April 25, 2004                 [Page 5]

Internet-Draft          IETF Problem Resolution             October 2003


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.

   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.




Davies & Hofmann         Expires April 25, 2004                 [Page 6]

Internet-Draft          IETF Problem Resolution             October 2003


   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 judgments about the
   relative priority of the problems (apart from the first one):

   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



Davies & Hofmann         Expires April 25, 2004                 [Page 7]

Internet-Draft          IETF Problem Resolution             October 2003


   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
   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



Davies & Hofmann         Expires April 25, 2004                 [Page 8]

Internet-Draft          IETF Problem Resolution             October 2003


   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.

   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



Davies & Hofmann         Expires April 25, 2004                 [Page 9]

Internet-Draft          IETF Problem Resolution             October 2003


   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.

   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
   flag, 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



Davies & Hofmann         Expires April 25, 2004                [Page 10]

Internet-Draft          IETF Problem Resolution             October 2003


   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 four 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
      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 to people in formal or informal
   leadership positions. If additional leadership positions are needed
   for this purpose, the IESG should consider creating them.



Davies & Hofmann         Expires April 25, 2004                [Page 11]

Internet-Draft          IETF Problem Resolution             October 2003


   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.

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




Davies & Hofmann         Expires April 25, 2004                [Page 12]

Internet-Draft          IETF Problem Resolution             October 2003


   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
   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:



Davies & Hofmann         Expires April 25, 2004                [Page 13]

Internet-Draft          IETF Problem Resolution             October 2003


   1.  Improve WG quality processes and the effectiveness of document
       reviews at all levels.

   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



Davies & Hofmann         Expires April 25, 2004                [Page 14]

Internet-Draft          IETF Problem Resolution             October 2003


   (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
   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 possible 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 given them opportunities to establish communication
   channels. These efforts include WG chair socials and training
   sessions for experienced WG chairs. These efforts should be
   continued.




Davies & Hofmann         Expires April 25, 2004                [Page 15]

Internet-Draft          IETF Problem Resolution             October 2003


   The IESG could help to promote chair-to-chair communication by
   encouraging direct communication between WG chairs when multi-WG
   issues arise.

   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



Davies & Hofmann         Expires April 25, 2004                [Page 16]

Internet-Draft          IETF Problem Resolution             October 2003


   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 [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



Davies & Hofmann         Expires April 25, 2004                [Page 17]

Internet-Draft          IETF Problem Resolution             October 2003


   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.

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



Davies & Hofmann         Expires April 25, 2004                [Page 18]

Internet-Draft          IETF Problem Resolution             October 2003


   have an affect on the quality of the IETF's security- related work,
   there are no specific security-related issues raised in this
   document.

Normative References

   [1]  Davies, E., "IETF Problem Statement",
        draft-ietf-problem-issue-statement-05 (work in progress), Oct
        2003.

   [2]  Galvin, J., "IAB and IESG Selection, Confirmation, and Recall
        Process: Operation of the Nominating and Recall Committees", RFC
        2727, Feb 2000.

Informative References

   [3]  Alvestrand, H., "An IESG charter", draft-iesg-charter-03 (work
        in progress), Apr 2003.

   [4]  Bradner, S., "The Internet Standards Process -- Revision 3", RFC
        2026, Oct 1996.

   [5]  Bradner, S., "IETF Working Group Guidelines and Procedures", BCP
        25, RFC 2418, September 1998.

   [6]  Carpenter, B., "Charter of the Internet Architecture Board
        (IAB)", 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", draft-davies-structural-rev-process-00
        (work in progress), September 2003.













Davies & Hofmann         Expires April 25, 2004                [Page 19]

Internet-Draft          IETF Problem Resolution             October 2003


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         Expires April 25, 2004                [Page 20]

Internet-Draft          IETF Problem Resolution             October 2003


Intellectual Property Statement

   The IETF takes no position regarding the validity or scope of any
   intellectual property 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; neither does it represent that it
   has made any effort to identify any such rights. Information on the
   IETF's procedures with respect to rights in standards-track and
   standards-related documentation can be found in BCP-11. Copies of
   claims of rights made available for publication 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 implementors or users of this specification can
   be obtained from the IETF Secretariat.

   The IETF invites any interested party to bring to its attention any
   copyrights, patents or patent applications, or other proprietary
   rights which may cover technology that may be required to practice
   this standard. Please address the information to the IETF Executive
   Director.


Full Copyright Statement

   Copyright (C) The Internet Society (2003). All Rights Reserved.

   This document and translations of it may be copied and furnished to
   others, and derivative works that comment on or otherwise explain it
   or assist in its implementation may be prepared, copied, published
   and distributed, in whole or in part, without restriction of any
   kind, provided that the above copyright notice and this paragraph are
   included on all such copies and derivative works. However, this
   document itself may not be modified in any way, such as by removing
   the copyright notice or references to the Internet Society or other
   Internet organizations, except as needed for the purpose of
   developing Internet standards in which case the procedures for
   copyrights defined in the Internet Standards process must be
   followed, or as required to translate it into languages other than
   English.

   The limited permissions granted above are perpetual and will not be
   revoked by the Internet Society or its successors or assignees.

   This document and the information contained herein is provided on an
   "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
   TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
   BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION



Davies & Hofmann         Expires April 25, 2004                [Page 21]

Internet-Draft          IETF Problem Resolution             October 2003


   HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
   MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.


Acknowledgement

   Funding for the RFC Editor function is currently provided by the
   Internet Society.











































Davies & Hofmann         Expires April 25, 2004                [Page 22]


Html markup produced by rfcmarkup 1.109, available from https://tools.ietf.org/tools/rfcmarkup/