[Search] [txt|pdfized|bibtex] [Tracker] [WG] [Email] [Diff1] [Diff2] [Nits]
Versions: 00 01                                                         
Network Working Group                                           T. Hardie
Internet-Draft                                                     Editor
                                                             October 2003

     An Outline Proposal for the Means to Accomplish the IETF's Ends.


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.


Copyright Notice

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


Abstract

   This outline contains a short description of the IETF's core work
   and a description of structures and processes which might be used
   to accomplish it.  Many of the elements described are already in
   use either formally or informally. This document does, however,
   propose some new mechanisms to support the work of the IETF.  The
   IESG does not believe that this document is complete, nor has it
   decided on a course of action based on this or any other proposal.
   The IESG does hope that presenting an outline set of mechanisms,
   both old and new, will foster discussion. The IESG hopes community
   will consider both whether the mechanisms described here would meet
   the IETF's needs and, especially, whether the linkages among the
   abstracted functions it describes are adequate and complete.

Table of Contents

   The IETF community                           Section 1
   The IETF's work                              Section 2
        Investigation                           Section 2.1
        Development                             Section 2.2
        Review                                  Section 2.3
        Specification                           Section 2.4
        Assessment                              Section 2.5
        Reporting                               Section 2.6
        Maintenance                             Section 2.7
        Typical flows of activity               Section 2.8
   Working Group Structure and Activity         Section 3
        Specification Group.                    Section 3.1
        IANA Team                               Section 3.2
        Exploratory Group                       Section 3.3
        Investigative Group                     Section 3.4
        Working Group Activity                  Section 3.5
   Area Board Structure and Activity            Section 4
   CREW Structure and Activity                  Section 5
   IESG Structure and Activity                  Section 6
   Directorate Structure and Activity           Section 7
   IAB Structure and Activity                   Section 8
   The Nominating Committee                     Section 9
   Ombudsperson                                 Section 10
   Business Management and Staffing             Section 11
   External Relationships                       Section 12
   Document Series                              Section 13
   Change Process                               Section 14
   Educational Processes                        Section 15
   Security Considerations                      Section 16
   IANA Considerations                          Section 17
   Normative References                         Section 18
   References                                   Section 19
        Normative References                    Section 19.1
        Informative References                  Section 19.2
   Editor's Address                             Section 20



1. The IETF community.

   The IETF is a community of active participants dedicated to producing
   timely, high quality engineering work that describes protocols and
   practices. These protocols and practices are expected to have secure
   and scalable implementations.  They are also expected to be
   interoperable and widely deployed.  The protocols and practices we
   work on are either part of the infrastructure of the Internet or they
   run on top of that infrastructure.

   To foster interoperability and to further development, the IETF
   maintains public access to its specifications and public registries
   of its protocol parameters; it also encourages publication and
   registration by those who have private extensions that fit within
   the Internet framework.  Where interoperability is served by making
   this statement, the IETF designates specifications as Internet
   standards, reflecting the IETF community's belief that the
   specification is sufficiently advanced to allow for multiple,
   interoperable implementations and to support widespread deployment
   on the Internet.

   The document below puts forward a revised set of structures as the
   basis for change in the IETF; more importantly, though, it puts
   forward a set of ongoing activities while will allow the community
   to continue to adapt its behavior as new challenges arise.  In
   identifying these revisions and activities, the primary motivation
   has been to enhance the IETF community's ability to produce
   relevant, high-quality engineering work suitable for deployment on
   the Internet.

   The changes to the IETF's structure fall into five general
   categories: functional differentiation of roles and
   responsibilities; clarifications of how authority and
   responsibility are distributed, especially to working group chairs;
   a new set of named roles within the working group review process; a
   renewed focus on cross-area review as a core value of the IETF; and
   a change in the document series and its interlocking reference
   structure.

   It should be noted that the change in these structures is not meant
   to change the purpose, scope, or activities of the IETF; in
   protocol terms it is a change in syntax meant to clarify
   operations, rather than a change in the semantics of those
   operations.

<change bar>

   The IETF has traditionally been integrated in two different ways,
   one formal and one informal. The formal integration relates to the
   steps of the standards process and the precursor steps of working
   group formation and chartering.  The informal integration is an
   overlapping set of personal relationships that allows participants
   to identify skills, perspectives, or energy needed to complete the
   efforts identified in the formal processes.  During a period of
   rapid growth and a follow-on period of contraction, the second
   system been strained to the point of failure.  Though the IETF
   retains a large pool of skilled professionals with energy and
   needed perspectives, the overlap in personal networks is now not
   sufficient to associate those with the efforts the IETF has taken
   on.  This has led to delay, lowered quality, and frustration, both
   among those whose skills and perspectives are not appropriately
   connected to salient efforts and among those whose efforts have
   stalled for lack of energy or early input by those with relevant
   expertise.  These issues have been expressed in the problem
   statement working group, but a broad range of the symptoms
   expressed there derive from the same root cause: the IETF has
   scaled in the past using personal trust networks as a critical part
   of its infrastructure, and that system cannot meet the current
   need.

   This document proposes correcting that problem by shifting the
   IETF's existing practice toward one in which process plays a larger
   role.  This does not mean that individuals will not be able to
   contribute in a strongly varied set of ways; it means that IETF
   will move toward a system in which specific roles have well defined
   responsibilities, so that the IETF can train, recruit and fill
   those roles more effectively.  The current system, in which the
   individual's capacities are the primary gauge for the scope of the
   job occupied, makes for serious problems of scaling and succession.

</change bar>

2.  The IETF's work.

   Prior to describing the structures used to carry out the IETF's
   activities, it may be useful to provide a short taxonomy of the
   kinds of work the IETF takes on.  The following list is not meant
   to be exhaustive, and it probably can be visualized best as a set
   of tasks that create a filter function--generating new ideas
   related to IP-based technologies, refining a subset of those in
   community dialog, and creating specifications for their
   implementation and use.

2.1  Investigation.

   This is usually limited to the investigation of known problems with
   the existing Internet infrastructure or protocol suite, rather than
   open-ended investigation.

2.2  Development.

   This encompasses both the development of infrastructure protocols
   and the development of protocols which the IETF believes meet a
   need for the Internet's users or operators which has previously not
   been met and for which an interoperable standard is critical or of
   very significant value.

2.3  Review.

   The IETF reviews protocols and practices which have been externally
   developed, provides commentary on these, and may choose to adopt
   them.

2.4  Specification.

   The IETF creates specifications of the protocols it has developed
   and of best practices which have been approved by community
   consensus.

2.5.  Assessment.

   The IETF assesses the maturity of its specifications.

2.6  Reporting.

   The IETF documents experiments and their results when those
   experiments relate to the IETF's core concerns.

2.7  Maintenance.

   The IETF maintains archives of its specifications, the parameters
   and values assigned to protocols it has developed, and, as noted
   above, the results of certain experiments.  It also attaches its
   assessments to specifications.

2.8  Typical flows of activity

   Below are a few examples of typical activity flows; these are not
   meant to be exhaustive, but they should serve to illustrate some of
   the variability in process required to achieve the IETF's goals.

2.8.1  IETF-sponsored Protocol Development

   Investigation--Development--Specification--Assessment--Maintenance

2.8.2 External Experiment

   Review--Reporting--Maintenance

2.8.3 External Protocol adopted by the IETF

   Review--Specification--Assessment--Maintenance

2.8.4 Assessment-derived Protocol Development

   Assessment--Development--Specification--Assessment--Maintenance

2.8.5 Externally derived Protocol Parameter

   Review--Maintenance.

<change bar>

   This section (2.x) is meant to describe the semantics of the
   operations before the document moves into syntax.  This is a
   100,000 foot view, and it is a big leap from there to the
   specifications below.  Nevertheless, including some abstract
   semantics seemed useful as a starting place.

</change bar>


3.  Working Group Structure and Activity.

   Working Groups are the fundamental organizational structure for
   participation in the IETF.  This document describes four types of
   Working Groups and examines how each fits into the work of the
   IETF.  These types are not immutable; the IETF can eliminate,
   increase, or change the number of types available as needs arise.
   These four fit well with common patterns of activity, but it should
   be noted that those patterns of activity may not fit neatly into
   these forms in the common case of a working group with multiple
   projects related to a single goal.  It will be common in that case
   for one project to be, say, in a specification phase and another
   under investigation.  As noted below, different types of groups may
   be chartered by different organizations within the IETF, and it is
   requirement in multi-project cases for the primary chartering
   organization to consult with those responsible for other areas when
   approving or extending a charter.  This is an extension of existing
   practice, in which the IESG and IAB consult on working group
   charter decisions.

   All working groups share certain core attributes: they will have a
   charter which describes the scope of the work and the tasks to be
   completed; they will have one or more identified Chairs who are
   responsible to the community for the group meeting the charter;
   they will maintain open, public records of their mailing list
   traffic, face-to-face meetings, and proposals.

<change bar>

   Note that maintaining a public record of proposals is a new
   requirement, as historically IETF Working Groups have used a naming
   convention for Internet Drafts to indicate which proposals were
   under active development by a Working Group.  Since Internet Drafts
   expire after six months, this record is not always available.  In
   order to maintain a consistent public record, the IETF would now
   require that any document accepted as work item will be made part
   of an archival series.  This series is described in Section 13,
   below.

   An added benefit of this change is that it reduces the likelihood
   that specifications which are incomplete will be published in the
   existing archival series when a Working Group fails to complete a
   work item.  This currently occurs fairly frequently when there is a
   desire to maintain a record of the work done even if it did not
   complete successfully.

</change bar>

3.1) Specification Group.

   Specification groups are chartered to develop documents which
   describe particular protocols or domain-specific best practices for
   use on the Internet.  These charters will normally contain a
   concise statement of the problem the Specification Group is
   tackling, the documents expected as the output of the group, and a
   set of dates by which each of the group's documents is expected.
   The development of requirements, use cases, or scenarios is out of
   scope for Specification Groups, as this work should be
   substantially complete by the time the group is chartered.  Note
   that this does not imply that specific documents addressing each of
   those points will be required prior to chartering a Specification
   Group, only that the problem statement and proposed work plan must
   be clear.

   Specification groups are chartered by the IESG in consultation with
   the community and management oversight is provided by the Area
   Directors for the Area in which they fall.

<change bar>

   The specification group is a narrower version of the existing
   Working Group, in that they will not take on use cases,
   requirements, or scenarios (Exploratory or Investigative Groups
   might be used to develop those where institutional support is
   required for that work).

</change bar>

3.2) IANA Team.

   IANA Teams are Working Groups with very restricted charters,
   composed of tasks that arise periodically in the extension or
   maintenance of an existing standard.  These teams may, for example,
   serve as the review groups for IANA registries which require IETF
   consensus for registration (and as working groups they may issue
   last calls or otherwise request input from the broader community).
   They may also serve as technical communities for review of
   proposals which build upon an existing core technology, in cases
   where that extension has been defined as a part of the core
   protocol.  Though it is theoretically possible for an IANA team to
   be in place concurrently with a specification group related to the
   same protocol or technology, this should arise only when there is
   no overlap in scope.

   Because the work of the IANA team is episodic in nature, it is
   particularly important that it have a core group of committed
   participants and that its Chair or Chair(s) be able to solicit
   review from specific individuals; see below, Section 3.5, for
   further discussion of this point.  IANA Teams are chartered by the
   Area Board for the Area in which they fall, in consultation with
   the community, and management oversight is provided by the Area
   Directors for that Area. See below, Section 4, for a description of
   the Area Boards.

<change bar>

   This is a new type of group, subsuming some work currently taken on
   by the IANA review teams and extending it to work done by
   subject-matter experts and directorates.  Originally, this document
   proposed that these be called "maintenance teams", but it became
   clear that this constituted an attractive nuisance.  Calling them
   IANA teams eliminates that attraction and fits the core of the
   role.  In particular, it eliminates the possibility of extension by
   an IANA team for a protocol not explicitly designed for such
   extension.  Again, the line has to be somewhere, and this got moved
   into a fairly conservative place.

   It should be noted that it should not be presumed that every
   Specification Group will be succeeded by an IANAe team.  These
   should be chartered only if the technical work requires this type
   of effort.  Note also that IANA teams are chartered by the Area
   Board.  The underlying theory here is that new work (taken on by an
   S.G, for example) requires extensive cross-area review, but that
   the decision on whether existing work will require this type of
   maintenance is best handled by subject matter experts.

</change bar>

3.3) Exploratory group

   Exploratory groups are relatively informal groups which carry on
   discussions about work which might require the attention of the
   IETF.  These groups are essentially self-organizing in the early
   stages, as those interested in a particular topic or work item
   informally identify others with similar interests.  Those
   organizing an exploratory group may at some point decide to open
   the discussion to the IETF community as whole, typically by holding
   a meeting at one of the IETF meetings sessions.

   Doing so requires that the organizers provide details of how they
   meet the basic Working Group requirements: where the archival
   record of their discussions will be kept, an agenda describing the
   scope of the discussion for the meeting, and a Chair or Chairs
   responsible for running the meeting.  Exploratory groups may
   develop use cases, scenarios, or requirements documents as part of
   their internal efforts to determine whether the work is ready for
   standardization or a focused investigative activity.  Since
   exploratory groups do not have work plans approved by the IETF
   community, their proposals are not expected to be archival, but
   should be published as Internet Drafts so they are available for
   public review.  Approval of proposals for exploratory groups to
   meet at IETF meetings may be given by the IESG, the IAB, or by any
   four members of the Area Board of the area in which work will take
   place.  See below, Section 4, for a description of the Area Board.
   Where there is contention over resources at an IETF meeting, the
   Secretariat will prefer proposals by date of the confirmed proposal
   while balancing the needs of different Areas.

<change bar>

   The IESG has historically approved BoFs after consulting the IAB
   and discussing the scope with the proposers.  Since the right to
   propose work is one of the most fundamental aspects of openness,
   eliminating the restriction that the IESG be the single approver of
   exploratory groups is an important method for distributing power
   into the organization.  It is equally important, of course, for the
   IESG to be able to approve them as the predecessors to new work.
   By distributing that right, this mechanism eliminates both the
   possibility that the IESG will be a choke point and the perception
   that it is one.  This also eliminates the "max two BoFs" rule, by
   allowing continued sponsorship.  It is expected, though, that it
   would get harder and harder to get sponsors when the work isn't
   becoming a specification group or an investigative group.

</change bar>


3.4) Investigative Group

   The IRTF (Internet Research Task Force) has research groups which
   are focused on long term research related to the Internet.  It has
   the writ to explore topics which may or may not admit of solutions.
   There are, however, cases where the IETF is considering a proposal
   for work and is not yet sure that the proposal is workable within
   the context of the Internet architecture.  Investigative Groups are
   short term task forces set up to explore proposals and determine
   whether or not the work proposed merits further specification and
   standardization.  These groups are chartered by the IAB and
   management oversight is provided by one or more domain experts
   within the IAB, who will coordinate their work with the Area
   Directors and Board(s) for the appropriate areas.  These groups
   should not produce specifications, but they may produce documents
   describing use cases, requirements, or scenarios which motivate
   work and help delineate its scope.

<change bar>

   This mechanism is new and the management structure is new.  It is
   expected that these will be fairly rare, but there are cases where
   continued investigation of a problem space is warranted but should
   take place within the context of a strong focus on the Internet
   Architecture.  A large part of the effort in an Investigative Group
   is likely to focus on how to get to an appropriate scope for a
   Specification Group from an initial proposal.

</change bar>

3.5) Working Group Activity.

   All Working Groups are open to participation by anyone, no matter
   whether the group is a Specification Group, an Exploratory Group,
   an IANA Team, or Investigative Group.  Anyone may join a Working
   Group mailing list at any time, and anyone may provide technical
   commentary as input to a Working Group at any time. A subset of
   those participating in the Working Group commit to taking on
   specific roles: Working Group Chair, document editor, or technical
   analyst.  Each of the participants taking one of these special
   roles will be identified on the working group pages and in
   documents produced during their tenure.

   Working Group Chairs are responsible for the Working Group meeting
   its charter, and they have broad powers to accomplish this task.
   They may select specific document editors, replace document editors
   who are not meeting established milestones, and assign analysis
   tasks to the working group's technical analysts.  Most importantly,
   they are responsible for determining whether work is sufficiently
   advanced to be forwarded for community review as complete.  This
   means that they both gauge whether the Working Group has achieved
   rough consensus on a document and provide a written technical
   assessment of the work.  The working group Chair or Chairs may
   decline to forward a document for community review whenever they
   believe it is technically incomplete, incorrect, or does not
   reflect the Working Group's consensus.  They must do so by stating
   the basis of that decision in a written message to the group.  This
   decision is subject to appeal along the established appeal chain.
   Because of the power inherent in this role, the same individual
   must never serve as both Chair and document editor for the same
   working group.  The responsibilities of a Working Group Chair to
   the Working Group and Area Board (See Section 4, below) represent a
   significant outlay of time and energy.  Chairs should expect to
   spend about one day a week on these activities, though the actual
   amount may vary from week to week.

<change bar>

   This description of a Working Group's Chair role adds a substantial
   technical role as technical reviewer, strengthens the ability of
   the Chair to hire and fire within the group, and formalizes the
   custom that a Working Group Chair should not be a document editor.
   The "provide a written technical assessment of the work" is also
   intended to take the place of the AD doing the write-up on a
   document.

</change bar>

   Document editors are responsible for merging the contributions of
   the Working Group members into a coherent specification.
   Typically, they are substantial contributors of text to the final
   document, but they must be able to integrate the work of others in
   order to reflect the view of the group.

<change bar>

   This text moves away from the concept of author to the concepts of
   editor/contributor.  This may provide an opportunity to recognize
   more folks involved in creating a spec, but it may also weaken the
   recognition to those holding the pen.  Watching this carefully will
   be required.

</change bar>

   There are two types of technical analysts; those associated with a
   Working Group effort and those outside the Working Group, whose
   views are solicited as an early indication of the likely results of
   broader community review.  For the second, see below, Section 5, for
   a description of the CREW (Committed reviewers of early work).

<change bar>

This makes the working group responsible for the first stage of
cross-area review.

</change bar

   For the first, a Working Group's technical analysts are volunteers
   who have agreed to read the documents produced for the Working
   Group: mailing list, minutes of meetings, chartered drafts.  For
   each chartered document, the technical analysts agree to provide
   public feedback within the time frames set out by the Chair
   (i.e. if a two week Working Group last call is issued, within two
   weeks).  This is not a vote; it is a public review of the
   document's incorporated engineering decisions, specificity of
   language, or record of working group discussion.  This review
   function is so central to the role that early drafts of this
   document described the role as "technical reviewer".  Feedback on
   those drafts, however, noted that "reviewer" could be taken to mean
   a critical role separate from creative contributions.  Working
   technical analysts are expected to "send text" when reviewing
   documents--that is, they are expected to be consistent contributors
   to the documents.

   Technical analysts who consistently do not provide feedback within
   the timeframes set out may be dropped by the application of a
   consistent policy set by the Working Group Chair(s).  This does not
   in any way bar future technical contributions; it simply means that
   they are no longer identified as someone who has committed to take
   on that work.  An individual may also at any time resign from this
   role, and any who has done so may volunteer again at any time.
   Anyone who has been dropped from this role may take it up again
   with the approval of the Chair.

   In assessing the ability of the IETF to meet a particular charter,
   the chartering body may ask for the names of those proposed as
   Chairs, document editors, and technical analysts.  Similarly, those
   with management oversight may ask for a current list of these
   participants in order to assess the energy and expertise available
   for the existing or new work.  This does not privilege the
   contributions of these participants, however, as all Working Group
   contributors will normally serve as contributors and document
   reviewers, and anyone may raise a technical issue with the work
   produced by a Working Group.

<change bar>

   The role and function of the technical reviewers is a formalization
   of the stuckee role, and much of the text of this section is lifted
   from the stuckee draft.  The aim here is to ensure that in-depth
   technical review occurs by encouraging specific individuals to put
   their names to such a review.

</change bar>

   Typically, the work of the Working Group is done by the exchange of
   contributions and reviews by email.  Working Groups also commonly
   hold face-to-face meetings at IETF meetings, and they may hold
   conference calls either of the whole group or specific sub-groups.
   All Working Group activity which does not take place on a mailing
   list must be minuted within a reasonable period and is subject to
   confirmation on the mailing list.


4. Area Board Structure and Activity

   Each Area Board consists of at least the Area Directors and one
   representative per group in the Area; current IAB members who have
   served as Area Directors or Working Group Chairs in the Area may
   choose to serve or may decline to serve at their own discretion.
   The Chairs of each group choose who will sit on the Board for their
   group, and they may make their choice by any method that is
   mutually agreeable.  Chairs may serve on the Area Board as the
   representatives of the groups they chair (and this may initially be
   common) but, in general, it is preferred that another member of the
   group whose qualifications fit them to the review tasks of the Area
   Board be selected.  In cases where a chair does serve as Area Board
   member, if a single individual serves as Working Group chair to
   multiple groups, that individual may serve only on behalf of one of
   those groups.  Other members may be included for one year terms
   after nomination by four current members and approval by majority
   vote.

   Each Board will have one Board Secretary, tasked with setting
   agendas, arranging for minutes, and communicating results of the
   Board's work.  The Area Directors for the salient Area will solicit
   candidates for this office from among the Board's members.  The
   Area Directors will forward a nominee to the Board, which may
   confirm or decline the candidate by majority vote.  Area Directors
   may not serve as Board Secretaries of their own area, but may
   fulfill their functions during short periods in which the role is
   vacant.  Board Secretaries will normally serve one year terms, but
   the office may become vacant early if the incumbent's place on the
   Board lapses and is not renewed.

<change bar>

  This is all new.  Part of the theory is to move some of those in the
  Area into roles closer to that of an AD, as prep for their taking on
  that role and/or as relief to the ADs. A main part of the theory,
  though, is that the value of the IETF is in cross-area review and
  consultation; this provides a new locus of review and consultation.
  Concerns expressed that the Working Group chairs may not be the best
  folks to hold these roles have been addressed by having Chairs
  capable of nominating replacements without soliciting three other
  nominations and by allowing their nominees to serve with majority
  vote.

</change bar>

   The Area Board has five main functions: it considers the need for
   IANA teams within its area and charters them in consultation with
   the community; it reviews Experimental and Informational documents
   forwarded by the Area Director from the RFC Editor and makes
   recommendations about their disposition to the RFC Editor; it
   manages educational and mentoring programs specific to its area;
   its members may approve the scheduling of an Exploratory Group
   meeting ; and its members may recommend that a particular document
   not produced within the IETF be considered as a candidate for
   standardization.  It is also consulted by the IAB during the
   chartering of an Investigative Group and by the IESG during the
   chartering of a Specification Group.

<change bar>

   Note that the area board makes recommendations to the RFC Editor on
   Informational or Experimental documents--not to the IESG.

</change bar>

   For the review of documents, larger Boards may and should consider
   forming small teams with expertise in specific areas, so that a
   ready team of reviewers is available for related documents.  Where
   a document is not obviously associated with such a team, the Board
   Secretary should ask for volunteers to review the document, setting
   a minimum of four reviewers.  If a Board has fewer than four
   members, the whole Board should review all documents referred to
   it.

   Any four members of an Area Board may recommend that a document
   produced outside the IETF Working Group process be considered for
   standardization.  The four members will commonly form or be part of
   an expertise-specific review team within the Board, but this is not
   required.

<change bar>

   New stuff, but along the lines of formalizing the core groups of
   existing areas; the hope is that by increasing recognition and
   responsibility for these roles that support for them can be
   increased.

</change bar>

   Each Area Board is expected to carry out its activities largely
   through mailing lists which are closed to external subscription but
   maintain public archives.  The Board Secretary may schedule
   teleconferences to handle issues which require in-depth or
   real-time discussion.  Minutes from those meetings will be posted
   to the public mailing list.  These teleconferences may be supported
   with IETF funds if the mechanisms to support them are not readily
   available among the members. Each Area Board is also expected to
   have a public meeting at each IETF to discuss the work of the Area
   and solicit input on its direction from the community

<change bar>

   This is intended to work as a cross between an Area open meeting
   and a mini-plenary; giving opportunities for concerns to be raised
   but also opportunities for cross-group fertilization and input.

</change bar>

5.) CREW structure and activity.

   The CREW (Committed Reviewers of Early Work) is composed of
   individuals who volunteer to provide early technical review of
   documents for Working Groups in which they are not active
   participants.  Anyone who is serving or has served as a technical
   analyst, document editor, or working group chair may volunteer to
   serve as a CREW participant by providing a short description of her
   or his technical areas of interest and agreeing to provide reviews
   on request.  A CREW participant may decline any specific request
   for a review, but will be removed from the rolls of active
   participants if he or she refuses three successive requests without
   accepting a request, completes no reviews in a specific calendar
   year, or fails on two occasions in a single year to complete
   reviews which she or he has agreed to provide.  Anyone completing
   five reviews in a single calendar year is immune to removal for
   that year, even if they decline further requests.  The IETF
   secretariat will provide in the appropriate formats an electronic
   listing of reviewers along with their stated areas of interest and
   copies of their previous reviews; it will also provide a mailing
   list for the whole set of CREW participants, for use by those
   working groups generally soliciting input rather than issuing a
   targeted request.

   The aim of this activity is to provide early access to a broader
   community review of the work and an early gauge of the impact of
   the Working Group's choices on other groups and areas.  It is
   expected that Working Group Chairs will solicit input from CREW
   participants early in the development phase of documents, and they
   may continue to solicit input over successive drafts.  The input of
   CREW participants is not automatically privileged over the input of
   Working Group members, but Chairs may request changes to meet the
   review comments when they believe that the expertise or perspective
   contained in the review is not adequately represented by the
   Working Group participants.

   When a group is proposed, the chartering body may include
   requirements for external review by those with specific technical
   areas of expertise.  The Chairs are responsible for determining
   that these requirements have been met; they may meet them by
   soliciting review by the CREW or, where available, through review
   by a directorate or relevant maintenance team.  See below, Section
   7 for discussion of directorates and their functions.

   Whether the CREW should have internal structure or should serve
   only as a pool of committed reviewers is a matter under active
   discussion.  There are clear advantages to building review teams
   which have experienced reviewers coaching new CREW members on the
   points most likely to be useful in a cross-area review.  A strictly
   pool-based approach seems likely, in contrast, to make it easier
   for individual members of the CREW to manage their load, by making
   it possible to decide to accept or decline a review request on
   a strictly individual basis.

   As an initial step, it is proposed that the Chair of the IETF and
   the Chair of the IAB jointly appoint a Crew Director, with the
   intent that the Crew Director's initial function will be to help
   staff the Crew and spread the load among the members.  The Crew
   Director will, however, monitor the success of the pool-based
   approach and may implement internal structures to the Crew to
   improve efficiency with the consent of the IAB Chair and the IETF
   Chair.  Further changes to the CREW may also be undertaken through
   any of the general change process mechanisms set out below.

<change bar>

   Very SIR-like (SIRS), obviously, but with an aim to leave
   participation more open.  The SIR mechanism seemed very unlikely to
   garner potential implementors, while a more open mechanism seemed
   likely to allow both for more senior reviewers and the work of
   first timers actually working on implementations.

</change bar>

6) IESG Structure and Activity

   Briefly, the Internet Engineering Steering Group (IESG) is the
   group responsible for the IETF standards process.  A BCP containing
   a detailed description of its charter, is expected as part of the
   ongoing definition of IETF roles.  Its current charter is discussed
   in (IESG-CHARTER), but this is not a normative description.

   The IESG has the following members: the IETF Chair, who also
   functions as the General Area Director when this area is active;
   the Area Directors for the IETF Areas; and the IAB Chair, as an
   ex-officio member.  The IETF Chair and the Area Directors are
   selected by the IETF NomCom according to the procedures of BCP 10
   (NOMCOM).

<change bar>

  This eliminates the Executive Director as ex-officio member, since
  that is a position associated with a specific contractor

</change bar>

   The IESG also has liaisons, who are members of the IESG mailing
   list and may attend all IESG meetings. The Liaison positions exist
   to facilitate the work of the IETF by expediting communication with
   other entities involved in the IETF process; which positions to
   have is decided by the IESG. The liaisons are selected as
   appropriate by the bodies they represent. At the time of this
   writing, the liaisons present represent the following bodies: the
   RFC Editor; the IANA; and the IAB.  In addition, members of the
   IETF Secretariat are subscribed to the mailing list and present in
   the IESG meetings as needed in order to serve as a support
   function.

   Decisions of the IESG are made by the IETF Chair and the Area
   Directors. All IESG members can participate in the IESG's
   discussions.

   The IESG charters and terminates Specification Groups, selects the
   Chairs of Specification Groups and IANA Teams, and monitors their
   progress.  While an Area's Directors and Board are the primary
   engine of coordination within the Area, the IESG is responsible for
   coordination across areas.  It is also responsible, in consultation
   with the IETF community, for the creation and termination of Areas.
   As noted elsewhere, technical review of documents is done within
   Working Groups and may be done by directorates or the CREW.  The
   IESG is, however, responsible for the final technical assessment of
   all IETF specifications and the final decision to advance them as
   IETF standards.  It also assigns review of candidates for
   publication outside the Standards track to specific Area Boards.

   The IESG may divide the work of final assessment for documents
   intended to be standards in any way which is consonant with its
   charter and with this document.  As of this writing, the IESG plans
   to use a team-based approach. According to that plan, documents
   forwarded as candidates for standardization are assigned to a team
   by the IETF Chair in consultation with the responsible Area
   Director.  After assignment, the document is placed on the team
   agenda for a specific week, and each member of the team is
   responsible for providing an assessment of the document and reading
   the reviews provided by the working group technical analysts, CREW,
   and working group chairs by that date.  A member of the team may,
   however, request that the document be deferred for a single
   meeting.

   Team members record positions on the standardization of a document
   in ways similar to that described in the current informational
   charter (IESG-CHARTER), in that a member may choose to
   raise no objection, may discuss an issue, and may approve.  They
   may not, however, abstain for any reason; if a member would need to
   recuse herself or himself from reviewing a document, the other
   reviewer for that area should provide the review.  Note that this
   internal plan does not change the appeals process, so that any
   decision of the IESG appealed to the IESG is automatically
   considered by the full IESG.

<change bar>

    This is meant to make the IESG a manageable job again without
   removing the final cross-area assessment.  Note that the emphasis
   on early cross-area review by the CREW is critical to making this
   work, as is the Area Board review of non-Standards track documents.
   This focuses on the IESG as _final_ technical assessment team, but
   stresses the existence and importance of other review.  It also
   leaves open the idea that an AD may "provide an assessment" by
   asking someone else to do that review if that is the best way to
   get one done; that, unfortunately, requires a personal network that
   is not specified here, but remains one of the ways forward.

   It otherwise gives strong emphasis to the specification Working
   Groups and cross-area coordination.  Unlike other proposals, this
   does not split the function of the IESG into document review and
   technical leadership, but leaves the IESG pretty much as it is
   currently constituted as the technical leadership team.  Note also
   the increased power given to Working Group Chairs above means that
   the IESG will no longer have the sole authority to block; moving
   the Chairs to use that new power when appropriate will take a
   culture change.

</change bar>

  The IESG has responsibility for the administration of IETF
  logistics, including operation of the Internet-Draft and Candidate
  Specification document series, as well as the IETF meeting event.
  As noted elsewhere, the actual administration is delegated to the
  Business Manager and Secretariat (see below, Section 11).

<change bar>

   This diminishes the IESG role in the day-to-day administration
   of the contracted services.

</change bar>

7) Directorate Structure and Activity

   Directorates are groups of subject-matter experts convened by one
   or more Area Directors to serve as a resource related to their
   subject.  They may give advice to the Area Director or to Working
   Groups which solicit their input.  Like comments from the CREW,
   comments from a Directorate may be considered by the Working Group
   Chair or Area Director as the basis for requirements to update a
   document, but it is the responsibility of the Chair or Area
   Director to impose those requirements.  The names of the members of
   a Directorate should be public, and any comments which become the
   basis of requirements should be recorded either in the Working
   Group archives or by the Area Director in the notes associated with
   a document.

8) IAB Structure and Activity

   The Charter of the IAB is set out in RFC 2850 (IAB-CHARTER).  This
   document updates that document by naming the IAB as the body which
   charters investigative groups, as a group which may schedule
   Exploratory Group meetings, and by designating its members as
   potential participants in Area Boards.  It also specifies that the
   the IAB, with the IESG, votes to confirm a candidate as
   Ombudsperson (See Section 10, below for a description of the
   Ombudsperson's role).

9) The Nominating Committee.

   The NomCom selects the members of the IESG and IAB according to the
   system set out in (NOMCOM).  This document does not update those
   mechanisms, but it does introduce new responsibilities for the
   individuals serving on the IESG and IAB and so should be considered
   by the NomCom in its deliberations.  This document also introduces
   a new role for NomCom in carrying out the public solicitation of
   potential candidates for Ombudsperson.  This system is different
   from the closed review of potential candidates for IAB and IESG,
   both in that the nominations must be public and in that the
   confirmation is carried out jointly by the IETF and IAB.  See
   below, section 10, for more details.

10) Ombudsperson.

   The Ombudsperson acts to help ensure that IETF mechanisms are not
   abused by providing independent oversight of IETF processes.  Any
   IETF participant may request that the Ombudsperson review the
   public record of a Working Group, Area Board, IETF, or IESG
   decision to determine whether the IETF processes functioned
   correctly.  The Ombudsperson has no power to conduct
   investigations, but she or he may, at her or his discretion,
   request time on the agenda of any body outside the NomCom in order
   to put forward the concerns raised.  If this is not sufficient to
   resolve issues, the Ombudsperson will help the participant to
   understand the appeals process.  It remains the responsibility of
   the concerned individual to file the appeal.

   Public nominations for candidates to serve for a year in the role
   of Ombudsperson are solicited by the NomCom Chair two months prior
   to the Fall IETF meeting.  The NomCom discusses the candidacies on
   its closed list, and makes a nomination two weeks prior to the Fall
   IETF meeting.  A candidate must be confirmed by majority vote of
   the IESG and IAB during their joint meeting. If the candidate
   proposed by the NomCom is not confirmed, the NomCom must propose a
   new candidate.  The sitting Ombudsperson remains in office until a
   candidate has been confirmed or, if that individual cannot serve,
   the NomCom Chair serves in this role until confirmation is
   complete.  If an Ombudsperson leaves during the course of the one
   year term, the NomCom will nominate a replacement to serve the
   remainder of the term plus one year.

<change bar>

   This is a role clearly desired by the community, but the scope of
   the role has not been clear. In putting together text, the most
   important aspect of the role seemed to the right to "be heard" and
   that the right to have access to any agenda was therefor key.
   Investigative powers, on the other hand, seemed likely to be
   problematic so this document sticks to the public record as the
   source of information.

</change bar>

11) Business management and staffing.

  The IETF is largely a volunteer organization, but it does maintain
  contracts with a number of external organizations who provide
  support or other services.  Work on updating the mechanisms by which
  those relationships are managed is ongoing.  This document assumes
  that whatever mechanisms emerge, the business management role inside
  the IETF will have no necessary connection to the IETF standards
  process and so the day to day work of managing the contracts by
  which support services are provided will not necessarily fall to
  those with any specific role in the standards process.

<change bar>

   This section originally outlined a new role, essentially a a
   professional able to take on the "task requester" position of
   managing contracts.  Since there is work going on to update those
   mechanisms, this section shifted to document the core assumption
   that the new mechanism would not presume that the same people
   managing the standards process managed the business relationships.
   That seems both likely to help us in reducing the load on those
   managing the standards process and likely to reduce the set of
   skills required for those roles.  Hopefully, both of those changes
   will increase the pool of those able to serve.

</change bar>

12) External relationships.

   The responsibility for handling external relations rests with the
   IAB, as described in the IAB Charter (IAB-CHARTER). However, when
   technical cooperation is required, it is essential that the work be
   coordinated with the relevant Areas. This often means that an Area
   Director or Board participant will function in a liaison role with
   other organizations.  The IAB may decide, however, to appoint
   others to those tasks whenever it believes that this is more
   appropriate.

13) Document Series.

   The requirement that Working Group documents be archival implies
   the creation of a new document series outside the current Internet
   Draft series.  This series, called Candidate Specifications, is
   intended to be relatively lightweight in publication.  The Chair of
   the salient Working Group must approve publication of the initial
   version of any Candidate Specification, but it may be updated by
   the Document Editor as required.  Candidate Specifications may have
   normative references to any document, including Internet Drafts.

<change bar>

   As noted above, C.S. is a new series, meant to be
   the archival equivalent of draft-ietf-wgname.

</change bar>

   When a Specification Group believes that a Candidate Specification
   is ready to be considered for status as an IETF standard, its Chair
   completes the technical analysis described in Section 3.5 above and
   requests community review in an IETF Last Call.  Following the
   completion of that Last Call, the IESG conducts a final review and
   either advances the document to Initial Standard or provides public
   feedback to the Working Group on issues raised during the IESG's
   review.  An Initial Standard must have normative references only to
   archival documents, but this may include specific versions of
   Candidate Specifications.

   After an Initial Standard has been implemented and in use for six
   months, it may progress to Full Standard by demonstrating that
   there exist two interoperable implementations of every required
   feature of the specification.  A Full Standard must have normative
   references only to archival documents, and it is preferred that
   these be at least at the level of Initial Standard or its
   equivalent.  This requirement may be waived by the IESG if the
   archival document referenced is considered stable in the aspect
   referenced by the Full Standard.

<change bar>

   By keeping this as a 3 stage process but with a lower initial
   requirements and a dropped requirement for lock step movement of
   normative references, we may be able to keep useful elements of the
   existing three stage system while improving the ability to move
   forward in a reasonable amount of time.  Getting to Full and
   proving interoperability should be valuable, and reducing external
   dependencies may help us do that more often.

</change bar>

14) Change process

   As before, the IETF may choose to update its processes by forming a
   working group that will consider the needs or advantages of
   specific changes.  A simplified mechanism is, however, presented
   here as a method for the adoption of new processes.  Any member of
   an Area Board may propose that the Area Board consider a new
   process for adoption by the IETF as a whole.  Such a proposal must
   be documented as an Internet Draft, and should indicate clearly the
   working of the proposal and the current documents which it updates
   or obsoletes.  If a two-thirds majority of that Area Board concurs
   that the IETF should consider the new or updated process, the Board
   Secretary for that Board notes the action to the IESG.

   The Area Directors for the Areas that have not considered the
   process must then request that the process be considered by the
   other Area Boards.  Other Area Boards then consider the document
   and vote on whether it should be approved; a two thirds majority is
   required in each case to approve.  If all Area Boards approve the
   document, the process it documents becomes part of the IETF
   process.  If a majority approve the document, but not all approve
   it, the Area Director for the General Area should strongly consider
   the formation of a Specification Team to propose new processes in
   the area; the Area Director for the General Area may also, however,
   recommend to the IAB that an Investigative Team be formed to
   consider the question.

<change bar>

   All new, and designed to create a change process that has a low bar
   for proposal, a reasonable bar for full-fledged consideration, and
   a fairly high bar for change.  Note, however, that every single
   Area Director could be against the proposal and it could still
   pass.  Note also that a single Area objecting to a proposal can
   stall it in this process, but cannot stall it in the working group
   process, so there are two separate ways forward.

</change bar>


15) Educational processes

   As noted above, each Area Board has responsibility for educational
   processes supporting its Area.  There is, however, also a need for
   a set of educational process which are more general (generally,
   orientation meetings for newcomers to the IETF or newcomers to
   specific roles in the IETF).  Therefore, the General area will
   maintain a set of ongoing working groups, essentially maintenance
   teams, charged with managing, developing, and delivering those
   cross-area educational programs which are needed and appropriate.
   The exact set of those teams may vary at any one time but shall
   consist at least of one dedicated to the general orientation of
   newcomers to the IETF and one dedicated to the orientation of those
   taking on new roles as Chairs, members of Area Boards, technical
   reviewers, and members of the CREW.

16. Security Considerations.

   Any change to organizational structure creates risk that attackers
   will be able to game the new system in ways they could not game the old.

17. IANA Considerations.

   This document does contain any actions for IANA.

18. Acknowledgments.

   This document lifts ideas, text, and explanations from a variety
   of sources, not always with their prior knowledge or consent.  The
   work of Dave Crocker, Brian Carpenter, and the participants in the
   SiRS experiment informs the section on the CREW.  The work of the
   problem statement working group and the solutions mailing list have
   both been instrumental in identifying scope and potential improvements.
   The Genera Area Directorate has given early comments on the work;
   Spencer Dawkins, in particular, provided extensive feedback.  Leslie
   Daigle, John Klensin, April Marine, James Kempf, Melinda Shore, and
   Rob Austein also provided comments on early drafts.

19. References

19.1 Normative References

   Galvin, J. "IAB and IESG Selection, Confirmation, and Recall
     Process: Operation of the Nominating and Recall Committees".
     BCP 10. (NOMCOM)

   Carpenter, B. ed. "Charter of the Internet Architecture Board".
     BCP 39. (IAB-CHARTER).

19.2 Non-Normative References

   Alvestrand, H. "An IESG Charter" draft-iesg-charter-03.txt
     (IESG-CHARTER)

   Carpenter, B. et al. "Careful Additional Review of Documents (CARD)
     by Senior IETF Reviewers (SIRS)"
     draft-carpenter-solution-sirs-01.txt (SIRS)

20. Editor's Address

    Ted Hardie
    Qualcomm, Inc.
    675 Campbell Technology Parkway
    Suite 200
    Campbell, CA
    U.S.A.

    EMail: hardie@qualcomm.com


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

    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.

Acknowledgment

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