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

Versions: 00 01 02 03 04 RFC 3844

 Internet-Draft                                     M. Wasserman, Editor
 Document: draft-ietf-problem-process-00.txt                  Wind River
 Expires:  November 2003                                        May 2003
 
                      IETF Problem Resolution Processes
 
    Status of this Memo
 
    This document is an Internet-Draft and is in full conformance with
    all provisions of Section 10 of RFC2026 [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.
 
    Abstract
 
    This document suggests processes to address 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
    those areas into longer-term and near-term problems, and suggests
    processes to address each area.
 
    Copyright Notice
 
    Copyright (C) The Internet Society (2001).  All Rights Reserved.
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
    Wasserman, Editor   Expires November 2003                        1
 
    IETF Problem Resolution Process                            May 2003
 
 
    Table of Contents
 
    Status of this Memo...............................................1
    Abstract..........................................................1
    Copyright Notice..................................................1
    Table of Contents.................................................2
    1       Introduction..............................................3
    2       IETF Core Values..........................................4
    2.1     Non-Core Values...........................................6
    3       Building on our Success...................................7
    4       Problem Decomposition.....................................9
    4.1     Decomposition of Mission Problem..........................9
    4.2     Decomposition of the Engineering Practices Problem........9
    4.3     Decomposition of the Complex Problems Problem............10
    4.4     Decomposition of the Engagement Problem..................10
    4.5     Decomposition of the Management Scaling Problem..........11
    4.6     Decomposition of the Decision Process Problem............13
    4.7     Decomposition of the Preparedness Problem................13
    5       Process Recommendations..................................15
    5.1     Near-Term Improvements...................................15
    5.1.1   Suggestions to Improve WG Quality Processes..............16
    5.1.2   Suggestions to Increase the Use of Tools.................17
    5.1.3   Suggestions to Improve Training..........................17
    5.1.4   Suggestions to Increase WG Chair Communication...........17
    5.2     Longer-term Improvements.................................17
    5.2.1   IETF Improvement Working Group...........................18
    5.2.1.1 Working Group Charter and Deliverables...................18
    5.2.1.2 Internal WG Management...................................19
    5.2.2   IETF Improvement WG Oversight............................19
    5.2.2.1 IESG-Directed Approach...................................20
    5.2.2.2 ISOC-Directed Approach...................................20
    5.2.3   IETF Improvement WG Chair Selection......................20
    6       Conclusion...............................................22
    7       Security Considerations..................................23
    8       Normative References.....................................23
    9       Informative References...................................23
    10      Acknowledgements.........................................23
    11      Editor's Contact Information.............................24
    12      Appendix A:  Suggested Charter for the Improvement WG....25
 
 
 
 
 
 
 
 
 
 
    Wasserman, Editor    Expires November 2003                       2
 
    IETF Problem Resolution Process                            May 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 [IETFPROB].
 
    This document begins with a discussion of the core values of the
    IETF and a reminder of the many good things about the IETF that we
    donÆt want to lose in the process of solving our problems.
 
    We then decompose each of the problems described in the problem
    statement into a few areas for improvement, and organize those
    areas for improvement into two categories:
 
         - Areas that can be addressed in the near-term, via discrete,
           minimally disruptive changes or improvements.
 
         - Areas that can only be addressed by longer-term efforts, via
           major changes to our organizational structure or 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 major, longer-term improvements are being
    considered and executed.
 
    Concrete suggestions are included for how we can begin or continue
    work on near-term improvements.
 
    The document then offers options for how to organize and manage our
    longer-term efforts.  The IETF, through the Problem Statement
    Working Group (problem WG) should consider these options and make
    decisions about how to organize and manage our longer-term
    improvements.
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
    Wasserman, Editor    Expires November 2003                       3
 
    IETF Problem Resolution Process                            May 2003
 
 2  IETF Core Values
 
    As we consider changes to 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.
 
    The IETF has a rich history and tradition, full of memorable quotes
    that capture our spirit and values.  Two of the most memorable are:
 
    "We reject kings, presidents and voting.  We believe in rough
    consensus and running code." -- Dave Clark
 
    "Be conservative in what you send, liberal in what you accept."
    -- Jon Postel
 
    At two IESG plenary meetings in 2002, the chair of the IETF, Harald
    Alvestrand, presented the purpose and core values of the IETF.
    These presentations were well received by the community and serve
    as a useful basis for a discussion of our purpose 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 purpose.
 
    At the following IESG plenary in Atlanta, Georgia in November 2002,
    five core values were presented [COREVAL]:
 
    "Cares for the Internet"
 
    As its name implies, the Internet Engineering Task Force (IETF)
    focuses on Internet-related activities.  We care about the
    Internet, and our standards work and operational activities are
    intended to improve the utility, scalability and availability of
    the Internet.
 
    The Internet isn't value-neutral, and neither is the IETF.  We want
    the Internet to be useful for communities that share our commitment
    to openness and fairness.  We embrace technical concepts such as
    decentralized control, edge-user empowerment and sharing of
    resources, because those concepts resonate with the core values of
    the IETF community. These concepts have little to do with the
    technology that's possible, and much to do with the technology that
    we choose to create.
 
    The IETF community also cares about making the Internet model a
    viable business proposition.  People who choose to offer Internet
    products and services that fit with our core values should be able
    to do so with maximum benefit and minimum amount of fuss.
 
    The IETF community wants the Internet to succeed because we believe
    that the existence of the Internet, and its influence on economics,
 
    Wasserman, Editor    Expires November 2003                       4
 
    IETF Problem Resolution Process                            May 2003
 
    communication and education, will help us to build a better human
    society.
 
    "Technically Competent"
 
    We pride ourselves on our technical competence, and our processes
    are intended to ensure the high technical quality and utility of
    our standards and other documents.
 
    "Open Process"
 
    Openness is a core attribute of the IETF. Our standards and other
    documents are developed in an open process, which allows us to
    achieve wide input and review.
 
    Anyone can participate in defining Internet standards in the IETF.
    We do not require corporate membership. We make final decisions on
    mailing lists, not at face-to-face meetings, so anyone with
    Internet access can contribute. All IETF documents are freely
    available, whether they are active working documents or finished
    specifications.  Individuals as well as working groups may submit
    Internet-Drafts for consideration as Internet standards.
 
    "Volunteer Core"
 
    With some honorable exceptions, the IETF community consists of
    people who are employed elsewhere, and much of our IETF work is
    directly related to the business of our employers.  However, many
    of us take on additional roles in the IETF, beyond those directly
    sponsored by our employers.  We participate in the IETF as
    individuals, because we want to work for the good of the Internet
    community and its inhabitants.
 
    The IETF community is committed to the continued success of the
    Internet, not to the continued success of the IETF itself.  The
    IETF is only worthwhile if it can effectively produce high quality,
    relavent standards that benefit the Internet.
 
    Openness and individual participation are two parts of an
    interlocking structure that is the strength of the IETF.  The
    openness permits all segments of the Internet community to
    participate, without demanding that they meet any qualifying
    criteria, such as belonging to a member company.  The individual
    participation allows us to focus on a wider set of "success
    criteria" than the health and well-being of our individual
    employers.
 
    Ultimately there is no conflict between the volunteer nature of the
    IETF and employer-sponsored participation, because we believe that
 
 
    Wasserman, Editor    Expires November 2003                       5
 
    IETF Problem Resolution Process                            May 2003
 
    the long-term survival and growth of the Internet benefits
    ourselves, our societies and our employers.
 
    "Rough Consensus and Running Code"
 
    It is an inherent part of the IETF culture that we base our
    decision making on rough consensus of the community, developed
    through open discussion.
 
    We also value running code as an indication of specification
    quality and completeness, and we require interoperable
    implementations for promotion in the standards process.
 
 2.1 Non-Core Values
 
    Understanding our core values also helps 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, Harald Alvestrand also
    presented the following "non-core values" [COREVAL]:
 
         - 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.
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
    Wasserman, Editor    Expires November 2003                       6
 
    IETF Problem Resolution Process                            May 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.
 
    It is important to consider that:
 
         - Good times hide problems;
         - Bad times hide successes.
 
    In good times, it is easy to succeed despite operational
    inefficiencies, so organizations tend to ignore operational
    problems and focus on successes.  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 fall into the trap of blaming our own organizational
    structure or processes for the effects of industry-wide changes,
    such as:
 
         - 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.
         - The commercialization of the Internet, which has drastically
           increased the financial impacts of standardization.
         - 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 effective.
    We should take this opportunity to develop the mechanisms and
    processes that we can use to continually improve our organizational
    effectiveness, both in good times and bad times.
 
    The IETF currently has a lot of valuable work underway, and care
    should be taken not to disrupt or delay that work while we address
    our organizational problems.
 
    Wasserman, Editor    Expires November 2003                       7
 
    IETF Problem Resolution Process                            May 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 IETF.  We should be
    careful not to alienate or disenfranchise our leaders and key
    contributors while making organizational or process changes.
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
    Wasserman, Editor    Expires November 2003                       8
 
    IETF Problem Resolution Process                            May 2003
 
 
 4  Problem Decomposition
 
    The problem statement document lists seven root cause problems
    currently facing the IETF:
 
       - Participants in the IETF do not share a common understanding
         of its mission
       - The IETF does not consistently use effective engineering
         practices
       - The IETF has difficulty handling large and/or complex problems
       - The IETF's workload exceeds the number of fully engaged
         participants
       - The IETF management structure is not matched to the current
         size and complexity of the IETF
       - Working group practices can make issue closure difficult
       - IETF participants and leaders are inadequately prepared for
         their roles
 
    Each of these problems can be decomposed into several areas for
    improvement, some of which can be addressed in the near-term while
    others require longer-term consideration.
 
    It is also important to note that the problem statement lists
    perceived problems.  Although all of these problems have been
    perceived by some groups of IETF participants, 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.  This is why it
    is important, as part of our problem resolution processes, to
    develop metrics and baselines that will allow us to judge the
    effectiveness of any organizational or process changes.
 
 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, we need to reach
    a common understanding of the mission and goals of the IETF.
    Although it should be possible to understand the mission and goals
    of the IETF with no disruption to our current processes, it would
    only be valuable as part of a longer-term 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 "customers" and understand how we serve them.  We also
    need to define our goals and priorities, and learn how to recognize
    and measure our own progress and success.
 
 4.2 Decomposition of the Engineering Practices Problem
 
    The IETF lacks effective engineering practices in three major
    areas:
 
         1. Effective mechanisms for issue tracking and/or document
            change control.
 
    Wasserman, Editor    Expires November 2003                       9
 
    IETF Problem Resolution Process                            May 2003
 
         2. Effective processes to ensure quality throughout the
            development of IETF work items, such as intermediate
            acceptance criteria or formal review processes.
         3. 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.
 
    Other areas concern the internal processes of IETF WGs, and would
    require documentation and adoption of effective engineering
    processes within IETF WGs.
 
    There is also a more fundamental issue with the IETF's engineering
    practices.  Although our current standards track contains three
    levels of maturity (Proposed Standard, Draft Standard and Full
    Standard), we do not have sufficient differentiation regarding the
    quality and completeness of documents required at each stage.  The
    bar is set very high for publication at Proposed Standard, and very
    few documents advance beyond this stage. [OPEN ISSUE: Do we have
    IETF consensus that this is a problem?]
 
    Although we should consider a longer-term process to revamp our
    standards-track document processes, this effort will be mutually
    dependent on the outcome of any IETF reorganization effort, as
    document approval is tightly tied to roles and responsibilities
    within the organization.
 
 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 that technology.  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
    problems could be alleviated by greater communication and
    coordination directly between the chairs of related WGs.
 
    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 Engagement Problem
 
    The engagement problem can be decomposed into two primary issues:
 
    Wasserman, Editor    Expires November 2003                      10
 
    IETF Problem Resolution Process                            May 2003
 
 
         - Too few people participate in the development and review of
           WG documents.
         - 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 possible 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.
 
    Also, when a document is returned by the IESG to the WG, clearer
    reasons could be given, with the goal of educating the WG to help
    them reach a speedy resolution.  Such education might also help
    document authors and editors to avoid similar mistakes in the
    future.  Today, individual IESG members are responsible for too
    many WGs and too many documents to spend adequate time providing
    detailed feedback and educating WGs and authors.  This problem
    should be considered in any IETF reorganization.
 
    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 stuck
    in AD review and/or IESG review for long periods with little
    feedback, or when the WG lacks consensus to progress its documents.
    In most cases, these problems could be identified by periodic
    reviews of WG progress, and corrective action could be taken on a
    case-by-case basis (take steps to progress the documents, narrow
    the charter of the WG, split the WG in two, disband the WG, etc.).
    These problems might also be addressed by optimizing our document
    publication processes to result in more timely publication of WG
    output.
 
 4.5 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 near-term solutions, but resolving the
    primary problem will require some type of IETF reorganization.
 
    There are three major areas for improvement that are grouped under
    this problem:
 
 
 
    Wasserman, Editor    Expires November 2003                      11
 
    IETF Problem Resolution Process                            May 2003
 
         - 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.
         - 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.
         - One or two people 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.  Any reorganization of the IETF should be done with a
    good understanding of the IETF's mission and core values.  Any
    reorganization needs to be carefully considered and planned, to
    avoid disrupting current work and to avoid damaging things about
    the IETF that are currently working well.
 
    In parallel with a longer-term IETF reorganization, however, some
    relief could be achieved by modifying IESG internal processes to
    remove the potential for one or two IESG members to block 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
    held, but it may not have resolved all of the issues in this area.
 
    To resolve the problems with the size of our leadership pool, we
    will need to examine, and perhaps modify, our current selection
    processes. IESG and IAB members are currently selected via the
    Nomcom process, and WG chairs are currently appointed by the
    "responsible AD" for each WG.
 
    The field of IESG candidates is sharply limited by the fact that
    serving on the IESG is nearly a full-time job.  If we reorganize to
    make our leadership roles realistic to pursue as part-time
    activities, that would widen the leadership selection pool.
 
    We may also need to modify our Nomcom processes so that IETF
    participants who are not part of the IETF leadership can have more
    visibility into the Nomcom process and more proportional input into
    leadership selection.  [OPEN ISSUE: Do we have consensus that these
    are real problems that need to be solved?]
 
    We may also want to reconsider the process that is used to select
    WG chairs. In particular, ADs could be encouraged to announce WG
    chair openings within their areas and/or to identify and develop
    more potential leaders.  [OPEN ISSUE: Is there IETF consensus that
    we have a problem in this area?]
 
 
    Wasserman, Editor    Expires November 2003                      12
 
    IETF Problem Resolution Process                            May 2003
 
 4.6 Decomposition of the Decision Process 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:
 
         - WG chairs may lack the skills and training to deal with
           common behavior problems that undermine or prevent
           consensus.
         - IETF participants are often unaware of how the IETF
           decision-making processes are intended to work.
 
    Both of these issues could be addressed through training or other
    educational resources.
 
 4.7 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 already an effort underway to improve WG chairs training
    and educational resources and to support ongoing development of
    experienced WG chairs.  This effort should be continued.
 
    The secretariat has traditionally supplied newcomer's training on
    Sunday afternoons, but due to personnel changes in the Secretariat,
    they will no longer be providing this training. Instead, this
    effort will be folded into the effort currently responsible for WG
    chairs training.
 
    Ongoing training for experienced attendees would also be valuable.
    Ned Freed, Allison Mankin and Thomas Narten provided some excellent
    training on the document process during the IESG plenary in
    December 2001 [DOCTRN].  Perhaps similar sessions could be planned
    to increase the awareness of IETF attendees regarding IETF
    processes, how to produce high quality IETF documents, IETF
    decision making processes, issues currently facing the IETF, etc.
 
 
 
    Wasserman, Editor    Expires November 2003                      13
 
    IETF Problem Resolution Process                            May 2003
 
    We should also consider developing a training program or developing
    other educational resources for document editors.
 
    It is also possible that some training could be valuable for IESG
    and IAB members, as they do not always come to their positions with
    experience or well-developed skills in all aspects of their jobs.
    Most of the IESG and IAB training is currently done through
    mentoring by experienced IESG and IAB members, but the IESG and IAB
    are encouraged to seek more formal training or development in any
    areas where their groups, as a whole, lacks experience and/or
    skills.
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
    Wasserman, Editor    Expires November 2003                      14
 
    IETF Problem Resolution Process                            May 2003
 
 
 5  Process Recommendations
 
    It is the overall recommendation of this document that we pursue
    near-term improvements to resolve IETF problems in parallel with
    longer-term efforts to reorganize the IETF and improve our
    standards processes.
 
    As part of this process, we should attempt to focus our near-term
    improvements on areas that are less likely to be substantially
    modified by our longer-term efforts, thus minimizing the likelihood
    of making our own efforts obsolete.
 
 5.1 Near-Term Improvements
 
    Many of the problems currently facing the IETF can be resolved, or
    mitigated, through near-term improvements to our current IETF
    organization and processes.  Many of these short-term 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 initial areas for improvement and focus on
    making improvements in those areas.
 
    In choosing which areas to pursue first, we should consider the
    following criteria:
 
         - We should address our most urgent, important problems.
         - The areas chosen should be cleanly separable, to allow
           multiple improvements to be carried out in parallel with
           minimal interference.
         - We should maximize the benefit vs. the cost of making the
           improvements (i.e. look for low hanging fruit).
         - As much as possible, we should focus on improvements that
           are less likely to be completely invalidated by a longer-
           term reorganization of our 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 that could
    benefit from short-term improvements, including:
 
         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 new and experienced IETF
            participants, new and experienced WG chairs, document
            editors and leaders.
         4. Improved communication between WG chairs to identify and
            resolve inter-WG and inter-area problems.
 
 
    Wasserman, Editor    Expires November 2003                      15
 
    IETF Problem Resolution Process                            May 2003
 
         5. Modify IESG-internal processes to make it impossible for one
            or two IESG members to block a document.
         6. Modify the WG chair selection processes to widen the group
            of people considered, and consider ways to develop more
            leaders for the IETF.
         7. Modify the Nomcom processes to include more visibility and
            more proportional input from participants that are not in
            leadership roles.
         8. 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 and 4 through immediate short-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 subsequent
    changes to the standards-track document 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 5 and 6.
 
    Area 7 is fairly likely to be impacted by a longer-term
    reorganization, and area 8 would require a substantial time
    commitment from IESG members, so it is not suggested that near-term
    improvements be pursued in these areas.
 
 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 quality processes used in IETF WGs, and
    to increase the effectiveness of IETF reviews at all levels.  This
    group should take an experimental, iterative approach to these
    improvements:
 
         - Identify and prioritize a set of promising proposals for
           improvement.
         - Figure out what each proposal is trying to improve (in
           measurable terms) and define a metric to measure performance
           in that area.
         - Determine the current level of performance against the
           defined metric.
         - Institute each change in a few representative WGs (on a
           volunteer basis).
         - Measure the results to determine if each change was
           successful.
         - Make successful changes available IETF-wide, by publishing
           them in BCP RFCs.
         - As necessary, train WG chairs and other participants on the
           how to implement the successful improvements in their WGs.
         - Repeat as necessary.
 
    [OPEN ISSUE: Should the Problem Statement WG propose a charter for
    this group, or leave that to the General AD and selected chair(s)?]
 
    Wasserman, Editor    Expires November 2003                      16
 
    IETF Problem Resolution Process                            May 2003
 
 
    A great deal of efficiency and synergy can be achieved by adopting
    common processes and tools 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 leaders
    and support those leaders in organizing tools-related 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.
 
 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.
 
 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, including 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.
 
    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.
 
 5.2 Longer-term Improvements
 
    There are two major areas where we should consider longer-term
    efforts to improve the IETF:
 
         - Organizational structure
         - IETF standards-track process
 
    Wasserman, Editor    Expires November 2003                      17
 
    IETF Problem Resolution Process                            May 2003
 
 
    These two areas cannot be completely decoupled, as the roles and
    responsibilities of the IETF leadership are largely defined in
    terms of the standards process, and vice versa.  Also, the
    standards-track process and the roles of IETF leadership are both
    largely defined within the same documents (RFC 2026 and RFC 2418).
 
    Therefore, a new organizational structure and any required changes
    to the standards-track process should be determined and enacted by
    a single WG, called the IETF Improvement WG (improve).  The WG is
    encouraged to work on these issues in parallel, where possible.
 
 5.2.1   IETF Improvement Working Group
 
    An IETF Improvement WG should be formed.  This group should be
    empowered to make changes to RFC 2026, RFC 2418, the Nomcom process
    and the charters of the IESG and IAB, as needed to enact a new
    organization and standards track processes.
 
 5.2.1.1 Working Group Charter and Deliverables
 
    The IETF Improvement WG will focus on two areas:
 
         - Improving the scalability and effectiveness of the IETF's
           organizational structure.
         - Improving the timeliness and utility of the IETF's standards
           track document processes.
 
    This WG will follow a two-phase process.  Phase Two tasks will not
    be started until the deliverables for Phase One have been completed
    by the WG and submitted for publication.
 
    Phase One: Understanding our Core Values and Our Mission
 
         In this phase, the WG will articulate and document the core
         values, mission, scope and goals of the IETF.  We will also
         learn how to recognize and measure the success of the IETF,
         and generate performance baselines that can be used to assess
         the success of later changes.
 
         Deliverables for Phase One include:
 
         - A document describing the core values of the IETF that
           should not be compromised as a result of the reorganization
           and process changes.  The core values section of this
           document may serve as a useful starting point for this work.
         - A document describing the mission, scope and goals of the
           IETF.
         - A document describing how the IETF can recognize and measure
           our own success.
         - A set of performance baselines that characterize the recent
           performance of the IETF.
 
 
 
    Wasserman, Editor    Expires November 2003                      18
 
    IETF Problem Resolution Process                            May 2003
 
    Phase Two: Organizing to Achieve our Mission and Goals without
    Compromising Our Core Values
 
         In this phase, the WG will document whatever improvements are
         needed to the IETF organization and processes to allow us to
         effectively achieve our mission and goals without compromising
         our core values.
 
         In this phase, the WG will:
 
         - Determine what approach will be used to identify, plan and
           execute the necessary improvements,
         - Scope and prioritize a set of improvements designed to
           increase the effectiveness of the IETF's organizational
           structure and processes,
         - Implement the improvements (most likely by publishing BCP
           RFCs), and
         - After a suitable time, reapply the metrics developed in
           Phase One to determine if the improvements have been
           successful.
 
    Although the IETF Improvement WG will ultimately be responsible for
    determining what improvements are required, it should be clear that
    this WG is empowered to make changes to the IETF organizational
    structure and processes, subject to approval by the appropriate
    oversight body (see below), such as:
 
         - Updates to RFC 2418, the Nomcom processes and the IESG and
           IAB charters (as needed) to define a more scaleable and
           effective organizational structure for the IETF.
         - Updates to RFC 2026 and other published processes to build
           an effective multi-level standards-track and to reflect any
           new organizational roles.
 
 5.2.1.2 Internal WG Management
 
    The IETF Improvement WG will be managed by the WG chair(s), using
    standard IETF practices and procedures, as defined in RFCs 2026 and
    2418 [RFC2026, RFC2418].
 
    To ensure that there is community consensus regarding the charter
    of this WG, the charter for the IETF Improvement WG will be
    developed within the Problem Statement WG and included in the final
    version of this document.  An initial charter proposal is included
    in Appendix A.
 
 5.2.2   IETF Improvement WG Oversight
 
    There is an open question regarding who should have oversight
    responsibility for the IETF Improvement WG, including management of
    the WG chairs and approving the output for publication by the RFC
    editor. The two primary options are an IESG-driven approach
    overseen by the General AD, or an ISOC-driven approach overseen by
 
 
    Wasserman, Editor    Expires November 2003                      19
 
    IETF Problem Resolution Process                            May 2003
 
    the ISOC President. These two proposals are further explained in
    the next two sections.
 
    The Problem Statement WG needs to decide which approach to
    recommend in this area.  It is our suggestion that the Problem
    Statement WG select the proposal that most closely approximates the
    consensus of the IETF, and tune that proposal to achieve rough IETF
    consensus.
 
 5.2.2.1 IESG-Directed Approach
 
    One possibility is that we could use the IETF WG and document
    processes defined in RFCs 2418 and 2026 [RFC2418, RFC2026] for the
    oversight of the IETF Improvement WG.
 
    In particular:
 
         - The WG would be formed in the General Area of the IETF, with
           the General AD serving as the "responsible AD".
         - The documents would be submitted to the IESG for approval
           and publication, according to the usual IETF processes.
         - If necessary, any appeals based on the processes or output
           of this WG would be handled according to the appeals
           procedures defined in RFCs 2418 and 2026.
 
 5.2.2.2 ISOC-Directed Approach
 
    Another approach would be to ask the ISOC President and the ISOC
    Board of Trustees (ISOC BoT) to assume responsibility for the
    oversight of the IETF Improvement WG, similar to our current
    Nominations Committee processes, as defined in RFC 2727 [RFC2727].
 
    In particular:
 
         - The WG would be formed outside of any IETF area, with the
           ISOC President serving as the equivalent of the "responsible
           AD".
         - The output of each phase would be presented at an open
           plenary during an IETF meeting, with IETF consensus on the
           output determined by the ISOC President.
         - After IETF consensus has been achieved on the output of each
           phase, the documents will be submitted to the ISOC BoT for
           approval and publication through the RFC editor.
         - This approach does not require an explicit appeals process,
           because an IETF Plenary is used as the basis for approval,
           and it is that body from which the IETF draws its authority.
           [OPEN ISSUE: Do we have consensus that a defined appeals
           process is not required for this option?]
 
 5.2.3   IETF Improvement WG Chair Selection
 
    Another open question is how the chairs for the IETF Improvement WG
    should be selected.  As with the organization and management of the
    WG, this document offers two choices:
 
    Wasserman, Editor    Expires November 2003                      20
 
    IETF Problem Resolution Process                            May 2003
 
 
         - The chair(s) of the WG could be selected by the "responsible
           AD", or equivalent -- either the General AD or the ISOC
           President.
         - The chair(s) of the WG could be selected by the Nominations
           Committee (Nomcom), or by a Nomcom-like group assembled for
           the purpose.
 
    Either method of chair selection could be applied to either method
    of WG oversight.
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
    Wasserman, Editor    Expires November 2003                      21
 
    IETF Problem Resolution Process                            May 2003
 
 
 6  Conclusion
 
    The IETF has problems, and we need to work to solve those problems,
    both via focused short-term improvements and via a longer-term
    effort to build an IETF structure 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 in harmony with our core values.
 
    Working together, we can fix the problems currently facing the IETF
    and make the IETF an even more effective, successful and fun place
    to work.
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
    Wasserman, Editor    Expires November 2003                      22
 
    IETF Problem Resolution Process                            May 2003
 
 
 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 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.
 
 8  Normative References
 
    [IETFPROB]
         E. Davies (ed.), "IETF Problem Statement", draft-ietf-problem-
         issue-statement-01.txt, May 2003
 
    [RFC2026]
         S. Bradner, "The Internet Standards Process -- Revision 3",
         RFC 2026, BCP9, October 1996
 
    [RFC2727]
         J. Galvin, "IAB and IESG Selection, Confirmation, and Recall
         Process: Operation of the Nominating and Recall Committees",
         RFC 2727, BCP 10, February 2000
 
    [RFC2418]
         S. Bradner, "IETF Working Group Guidelines and Procedures",
         RFC 2418, BCP 25, September 1998
 
 9  Informative References
 
    [COREVAL]
    http://www.ietf.org/proceedings/02nov/slides/plenary-2/sld4.htm
 
    [DOCTRN]
    http://www.ietf.org/proceedings/01dec/slides/plenary-3/index.html
 
 10 Acknowledgements
 
    The contents of this document were greatly influenced by members of
    the Problem Statement WG editorial team: Avri Doria, Dave Crocker,
    Elwyn Davies, Jeanette Hofmann, Melinda Shore, Rob Austein and
    Spencer Dawkins.
 
    The initial text for the core values section is largely based on
    presentations and messages authored by Harald Alvestrand.
 
    "Good times hide problems; Bad times hide successes" is taken from
    a presentation by Tom St. Dennis, the President and CEO of Wind
    River.
 
    The following people have provided useful feedback on early
    versions of this document: Randy Bush, Leslie Daigle.
 
 
    Wasserman, Editor    Expires November 2003                      23
 
    IETF Problem Resolution Process                            May 2003
 
 11 Editor's Contact Information
 
    Comments or questions regarding this document should be sent to:
 
    Margaret Wasserman
    Wind River
    10 Tara Blvd., Suite 330             Phone:  (603) 897-2067
    Nashua, NH  03062  USA               Email:  mrw@windriver.com
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
    Wasserman, Editor    Expires November 2003                      24
 
    IETF Problem Resolution Process                            May 2003
 
 
 12 Appendix A:  Suggested Charter for the Improvement WG
 
    IETF Improvement Working Group (improve)
 
    Chair(s): TBD, as described above.
 
    Area Director(s): TBD, as described above.
 
    Mailing List: TBD
 
    Description of the WG:
 
    The IETF Improvement WG is chartered to make improvements to the
    management structure and processes of the IETF to address the
    fundamental organizational and process problems described in the
    IETF Problem Statement (RFC XXXX), according to the process
    described in the IETF Problem Resolution Process (RFC XXXX).
 
    The IETF Improvement WG will focus on two areas:
 
         - Improving the scalability and effectiveness of the IETF's
            organizational structure.
         - Improving the timeliness and utility of the IETF's standards
            track document processes.
 
    This WG will follow a two-phase process.  Phase two tasks will not
    be started until the deliverables for Phase One have been completed
    by the WG and submitted for publication.
 
    Phase One: Understanding our Core Values and Our Mission
 
         In this phase, the WG will articulate and document the core
         values, mission, scope and goals of the IETF.  We will also
         learn how to recognize and measure the success of the IETF,
         and generate performance baselines that can be used to assess
         the success of later changes.
 
         The deliverables for Phase One include:
 
         - A document describing the core values of the IETF that
            should not be compromised as a result of the reorganization
            and process changes.
         - A document describing the mission, scope and goals of the
            IETF.
         - A document describing how the IETF can recognize and measure
            our own success.
         - A set of performance baselines that characterize the recent
            performance of the IETF.
 
    Phase Two: Organizing to Achieve our Mission and Goals without
    Compromising Our Core Values
 
 
 
    Wasserman, Editor    Expires November 2003                      25
 
    IETF Problem Resolution Process                            May 2003
 
         In this phase, the WG will document whatever improvements are
         needed to the IETF organization and processes to allow us to
         effectively achieve our mission and goals without compromising
         our core values.
 
         In this phase, the WG will:
 
         - Determine what approach will be used to identify, plan and
            execute the necessary improvements,
         - Scope and prioritize a set of improvements designed to
            increase the effectiveness of the IETF's organizational
            structure and processes,
         - Implement the improvements (most likely by publishing BCP
            RFCs), and
         - After a suitable time, reapply the metrics developed in
            Phase One to determine if the improvements have been
            successful.
 
    Goals and Milestones: TBD
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
    Wasserman, Editor    Expires November 2003                      26
 
    IETF Problem Resolution Process                            May 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 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.
 
    Wasserman, Editor    Expires November 2003                      27
 
    IETF Problem Resolution Process                            May 2003
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
    Wasserman, Editor    Expires November 2003                      28
 

Html markup produced by rfcmarkup 1.107, available from http://tools.ietf.org/tools/rfcmarkup/