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.
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.
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.
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 develops, and, as noted
above, the results of its experiments. It also maintains attaches
its assessments to those 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.
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.
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.
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 11,
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.
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.
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).
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 1.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 2, for a description of
the Area Boards.
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.
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.
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.
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.
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.
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 2, 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.
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.
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.
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.
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).
This makes the working group responsible for the first stage of
cross-area review.
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.
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
Working Group Chair 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. If there a multiple Working Group Chairs for a single
group, the Chairs may choose who will sit on the Board by any
method that is mutually agreeable, but, in general, it is preferred
that a Chair that has not previously served be given precedence
over one who has. A Chair or chair(s) may also choose to propose
that another contributing participant of their working group take
the role; this is subject to the approval of the Area Board by
majority vote. If a single individual serves as Working Group
chair to multiple groups, that individual may serve only on behalf
of one of those groups, and may not nominated another member of the
working group under the replacement rules. 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.
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.
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.
Note that the area board makes recommendations to the RFC Editor on
Informational or Experimental documents--not to the IESG.
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.
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.
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
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.
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
5 for discussion of directorates and their functions.
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.
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).
This eliminates the Executive Director as ex-officio member, since
that is a position associated with a specific contractor
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.
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.
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).
This diminishes the IESG role in the day-to-day administration
of the contracted services.
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.
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.
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.
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.
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.
As noted above, C.S. is a new series, meant to be
the archival equivalent of draft-ietf-wgname.
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 1.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.
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.
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.
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.
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.