Network Working Group S. Bradner
Internet-Draft Harvard University
Expire in six months Editor
March 1997
IETF Working Group
Guidelines and Procedures
<draft-ietf-poisson-wg-guide-00.txt>
Status of this Memo
This document is an Internet-Draft. 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.''
To learn the current status of any Internet-Draft, please check the
``1id-abstracts.txt'' listing contained in the Internet-Drafts Shadow
Directories on ftp.is.co.za (Africa), nic.nordu.net (Europe),
munnari.oz.au (Pacific Rim), ds.internic.net (US East Coast), or
ftp.isi.edu (US West Coast).
Abstract
The Internet Engineering Task Force (IETF) has responsibility for
developing and reviewing specifications intended as Internet
Standards. IETF activities are organized into working groups (WGs).
This document describes the guidelines and procedures for formation
and operation of IETF working groups. It also describes the formal
relationship between IETF participants WG and the Internet
Engineering Steering Group (IESG) and the basic duties of IETF
participants, including WG Chairs, WG participants, and IETF Area
Directors.
Table of Contents
Status of this Memo
Abstract
1. Introduction
1.1. IETF approach to standardization
1.2. Roles within a Working Group
2. Working group formation
2.1. Criteria for formation
2.2. Charter
Bradner [Page 1]
Internet-Draft Working Group Guidelines March 1997
2.3. Charter review & approval
2.4. Birds of a feather (BOF)
3. Working Group Operation
3.1. Session planning
3.2. Session venue
3.3. Session management
3.4. Contention and appeals
4. Working Group Termination
5. Rechartering a Working Group
6. Staff Roles
6.1. WG Chair
6.2. WG Secretary
6.3. Document Editor
6.4. WG Facilitator
6.5. Design teams
6.6. Working Group Consultant
6.7. Area Director
7. Working Group Documents
7.1. Session documents
7.2. IETF meeting documents
7.3. Internet-Drafts (I-D)
7.4. Request For Comments (RFC)
7.5. Submission of documents
8. Review of documents
9. Security Considerations
10. Acknowledgments
11. References
12. Authors' Address
Appendix: Sample Working Group Charter
1. Introuction
The Internet, a loosely-organized international collaboration of
autonomous, interconnected networks, supports host-to-host
communication through voluntary adherence to open protocols and
procedures defined by Internet Standards. There are also many
isolated interconnected networks, which are not connected to the
global Internet but use the Internet Standards. Internet Standards
are developed in the Internet Engineering Task Force (IETF). This
document defines guidelines and procedures for IETF working groups.
The Internet Standards Process of the IETF is defined in [1]. The
organizations involved in the IETF Standards Process are described in
[2] as are the roles of specific individuals..
The IETF is a large, open community of network designers, operators,
vendors, users, and researchers concerned with the Internet and the
technology used on it. The primary activities of the IETF are
performed by committees known as working groups. There are currently
more than 70 working groups. ( See the IETF web page for a up-to-date
Bradner [Page 2]
Internet-Draft Working Group Guidelines March 1997
list of IETF Working Groups - http://www.ietf.org.) Working groups
tend to have a narrow focus and a lifetime bounded by the completion
of a specific set of tasks, although there are exceptions.
For management purposes, the IETF working groups are collected
together into areas, with each area having a separate focus. For
example, the security area deals with the development of security-
related technology. Each IETF area is managed by one or two Area
Directors. There are currently 8 areas in the IETF but the number
changes from time to time. (See the IETF web page for a list of the
current areas and for a list of which working groups are assigned to
which area.)
In many areas the Area Directors have formed an advisory group or
directorate. These comprise experienced members of the IETF and the
technical community represented by the area The specific name and
the details of the role for each group differs from area to area, but
the primary intent is that these groups assist the Area Director(s),
e.g., with the review of specifications produced in the area.
The IETF area directors are selected by a nominating committee, which
also selects an overall chair for the IETF. (See the IETF web page
for an up-to-date list of the IETF Area Directors and the IETF
Chair.) The nominations process is described in [3].
The area directors sitting as a body, along with the IETF Chair
comprise the Internet Engineering Steering Group (IESG). The IETF
Executive Director is an ex-officio participant of the IESG, as are
the IAB Chair and a designated Internet Architecture Board (IAB)
liaison. The IESG approves IETF Standards and approves the
publication of other IETF documents. (See [1].)
A small IETF Secretariat provides staff and administrative support
for the operation of the IETF.
There is no formal membership in the IETF. Participation is open to
all. This participation may be by on-line contribution, attendance
at face-to-face sessions, or both. Anyone from the Internet
community who has the time and interest is urged to participate in
IETF meetings and any of its on-line working group discussions.
Participation is by individual technical contributors, rather than by
formal representatives of organizations.
This document defines procedures and guidelines for formation and
operation of working groups in the IETF. It defines the relations of
working groups to other bodies within the IETF. The duties of working
group Chairs and Area Directors with respect to the operation of the
working group are also defined. The document uses the terms:
Bradner [Page 3]
Internet-Draft Working Group Guidelines March 1997
"shall", "will", "must" and "is required" where it describes steps in
the process that are essential, and uses: "suggested", "should" and
"may" are where guidelines are described that are not essential, but
are strongly recommended to help smooth WG operation.
1.1. IETF approach to standardization
Familiarity with The Internet Standards Process [1] is essential for
a complete understanding of the philosophy, procedures and guidelines
described in this document.
1.2. Roles within a Working Group
The Organizations Involved in the IETF Standards Process [2]
describes the roles of a number of individuals within a working
group, including the working group chair and the document editor.
These descriptions are expanded later in this document.
2. Working group formation
IETF working groups (WGs) are the primary mechanism for development
of IETF specifications and guidelines, many of which are intended as
standards or recommendations. A working group may be established at
the initiative of an Area Director or it may be initiated by an
individual or group of individuals. Anyone interested in creating an
IETF working group must obtain the advice and consent of the
appropriate IETF Area Director under whose direction the working
group would fall and must proceed through the formal steps detailed
in this section.
Working groups are typically created to address a specific problem or
to produce one or more specific deliverables (a guideline, standards
specification, etc.). Working groups are generally expected to be
short-lived in nature. Upon completion of its goals and achievement
of its objectives, the working group is terminated. A working group
may also be terminated for other reasons. (see sec x.y)
Alternatively with the concurrence of the IESG, Area Director, the WG
Chair, and the WG participants, the objectives or assignment of the
working group may be extended by modifying the working group's
charter through a rechartering process (sec x.y).
2.1. Criteria for formation
When determining whether it is appropriate to create a working group,
the Area Director and the IESG will consider several issues:
- Are the issues that the working group plans to address clear and
relevant to the Internet community?
- Are the goals specific and reasonably achievable, and achievable
within the time frame specified by the milestones?
- What are the risks and urgency of the work, to determine the level
of attention required?
- Do the working group's activities overlap with those of another
Bradner [Page 4]
Internet-Draft Working Group Guidelines March 1997
working group? If so, it may still be appropriate to create the
working group, but this question must be considered carefully by
the Area Directors as subdividing efforts often dilutes the
available technical expertise.
- Is there sufficient interest within the IETF in the working group's
topic with enough people willing to expend the effort to produce
the desired result (e.g., a protocol specification)? Working
groups require considerable effort, including management of the
working group process, editing of working group documents, and
contribution to the document text. IETF experience suggests that
these roles typically cannot all be handled by one person; a
minimum of four or five active participants are typically
required.
- Is there enough expertise within the IETF in the working group's
topic, and are those people interested in contributing in the
working group? - Does a base of interested consumers (end users)
appear to exist for the planned work? Consumer interest can be
measured by participation of end-users within the IETF process, as
well as by less direct means.
- Does the IETF have a reasonable role to play in the determination
of the technology? There are many Internet-related technologies
that may be interesting to IETF members but in some cases the IETF
may not be in a position to effect the course of the technology in
the "real world". For example, if the technology is being
developed by another standards body or an industry consortium.
- Are all intellectual property rights relevant to the proposed
working group's efforts issues resolved.
- Is the proposed work plan an open IETF effort or is it an attempt
to "bless" non-IETF technology where the effect of input from IETF
participants may be limited.
Considering the above criteria, the Area Director will decide whether
to pursue the formation of the group through the chartering process.
2.2. Charter
The formation of a working group requires a charter which is
primarily negotiated between a prospective working group Chair and
the relevant Area Director, although final approval is made by the
IESG with advice from the Internet Architecture Board (IAB). A
charter is a contract between a working group and the IETF to perform
a set of tasks. A charter:
1. Lists relevant administrative information for the working group;
2. Specifies the direction or objectives of the working group and
describes the approach that will be taken to achieve the goals;
and
3. Enumerates a set of milestones together with time frames for their
completion.
Bradner [Page 5]
Internet-Draft Working Group Guidelines March 1997
When the prospective Chair(s), the Area Director and the IESG
Secretary are satisfied with the charter form and content, it becomes
the basis for forming a working group. Note that an AD may require
the holding an exploratory Birds of a Feather (BOF) meeting, as
described below, to gage the level of support for a working group
before submitting the charter to the IESG and IAB for approval. Note
that the individuals proposed to fill the WG roles (see sec xx) must
be included in the charter when it is submitted for IESG
consideration.
Charters may be renegotiated periodically to reflect the current
status, organization or goals of the working group. (see sec x.y)
Hence, a charter is a contract between the IETF and the working group
which is committing to meet explicit milestones and delivering
specific "products".
Specifically, each charter consists of the following sections:
Working group name
A working group name should be reasonably descriptive or
identifiable. Additionally, the group shall define an acronym
(maximum 8 printable ASCII characters) to reference the group in
the IETF directories, mailing lists, and general documents.
Chair(s)
The working group may have one or more Chair(s) to perform the
administrative functions of the group. The email address(es) of
the Chair(s) shall be included. Generally a working group is
limited to two chairs.
Area and Area Director(s)
The name of the IETF area with which the working group is
affiliated and the name and electronic mail address of the
associated Area Director.
Area Advisor
If the area has two ADs one of them must be listed as the primary
contact for the working group.
Mailing list
It is required that an IETF working group have a general Internet
mailing list. Most of the work of an IETF working group will be
conducted that. The charter shall include:
1. The address to which a participant sends a subscription request
and the procedures to follow when subscribing,
2. The address to which a participant sends submissions and
special procedures, if any, and
3. The location of the mailing list archive. A message archive
must be maintained in a public place which can be accessed via
FTP or the web. The ability to retrieve from The address:
ietf-archive@ietf.org must be included on the mailing list.
NOTE: In keeping with the general IETF rule for openness the
membership of the mailing list must be must be made available.
Bradner [Page 6]
Internet-Draft Working Group Guidelines March 1997
Description of working group
The focus and intent of the group shall be set forth briefly. By
reading this section alone, an individual should be able to decide
whether this group is relevant to their own work. The first
paragraph must give a brief summary of the problem area, basis,
goal(s) and approach(es) planned for the working group. This
paragraph can be used as an overview of the working group's
effort.
To facilitate evaluation of the intended work and to provide on-
going guidance to the working group, the charter must describe the
problem being solved and must discuss objectives and expected
impact with respect to:
- Architecture
- Operations
- Security
- Network management
- Scaling
- Transition (where applicable)
Goals and milestones
The working group charter must establish a timetable for specific
work items. While this may be re-negotiated over time, the list of
milestones and dates facilitates the Area Director's tracking of
working group progress and status, and it is indispensable to
potential participants identifying the critical moments for input.
Milestones shall consist of deliverables that can be qualified as
showing specific achievement; e.g., "Internet-Draft finished" is
fine, but "discuss via email" is not. It is helpful to specify
milestones for every 3-6 months, so that progress can be gauged
easily. This milestone list is expected to be updated
periodically. (see sec xx)
An example of a WG charter is included as Appendix A.
2.3. Charter review & approval
Working groups often comprise technically competent participants who
are not familiar with the history of Internet architecture or IETF
processes. This can, unfortunately, lead to good working group
consensus about a bad design. To facilitate working group efforts,
an Area Director may assign a Consultant from among the ranks of
senior IETF participants. (Consultants are described in the section
of Staff Roles.) At the discretion of the AD, approval of a new WG
may be withheld in the absence of sufficient Consultant resources.
Once the Area Director (and the Area Directorate, as the AD deems
appropriate) has approved the working group charter, the charter is
submitted for review by the IAB and approval by the IESG. The IESG
may approve the charter as-is, it may request that changes be made in
the charter, or may decline to approve chartering of the working
Bradner [Page 7]
Internet-Draft Working Group Guidelines March 1997
group
The IESG remands the approved charter to the IESG Secretary who
records and enters the information into the IETF tracking database.
The working group is announced to the IETF mailing list by the IESG
Secretary.
2.4. Birds of a feather (BOF)
Often it is not clear whether an issue merits the formation of a
working group. To facilitate exploration of the issues the IETF
offers the possibility of a Birds of a Feather (BOF) session, as well
as the early formation of an email list for preliminary discussion.
In addition, a BOF may serve as a forum for a single presentation or
discussion, without any intent to form a working group.
A BOF is a session at an IETF meeting which permits "market research"
and technical "brainstorming". Any individual may request permission
to hold a BOF on a subject. The request must be filed with the
relevant Area Director who must approve a BOF before it can be
scheduled. The person who requests the BOF is usually appointed as
Chair of the BOF. The Chair of the BOF is also responsible for
providing a report on the outcome of the BOF. If the Area Director
approves the BOF is then scheduled by submitting a request to
agenda@ietf.org with copies to the area AD(s). A BOF description and
agenda are required before a BOF can be scheduled.
The AD may require the establishment of an open email list prior to
authorizing a BOF. This permits initial exchanges and sharing of
framework, vocabulary and approaches, in order to make the time spent
in the BOF more productive. The AD may require that a BOF be held,
prior to establishing a working group (see sec xx), and the AD may
require that there be a draft of the WG charter prior to holding a
BOF.
In general BOF may be held only once (ONE slot at one IETF Plenary
meeting). Under unusual circumstances an Area Director may, at their
discretion, allow a BOF to meet for a second time. BOFs are not
permitted to meet three times. Note that all other things being
equal, WGs will be given priority for meeting space over BOFs.
Usually the outcome of a BOF will be one of the following:
- There was enough interest and focus in the subject to warrant the
formation of a WG;
- The discussion came to a fruitful conclusion, with results to be
written down and published, however there is no need to establish
a WG; or
- There was not enough interest in the subject to warrant the
formation of a WG.
Bradner [Page 8]
Internet-Draft Working Group Guidelines March 1997
3. Working Group Operation
The IETF has basic requirements for open and fair participation and
for thorough consideration of technical alternatives. Within those
constraints, working groups are autonomous and each determines most
of the details of its own operation with respect to session
participation, reaching closure, etc. The core rule for operation is
that acceptance or agreement is achieved via working group "rough
consensus". WG participants should specifically note the
requirements for disclosure of conflicts of interest in [2].
A number of procedural questions and issues will arise over time, and
it is the function of the Working Group Chair to manage the group
process, keeping in mind that the overall purpose of the group is to
make progress towards reaching rough consensus in realizing the
working group's goals and objectives.
There are few hard and fast rules on organizing or conducting working
group activities, but a set of guidelines and practices have evolved
over time that have proven successful. These are listed here, with
actual choices typically determined by the working group participants
and the Chair.
3.1. Session planning
For coordinated, structured WG interactions, the Chair must publish a
draft agenda well in advance of the actual session. The agenda needs
to contain at least:
- The items for discussion;
- The estimated time necessary per item; and
- A clear indication of what documents the participants will need
to read before the session in order to be well prepared.
Publication shall include sending a copy to the working group mailing
list and to the IETF-Announce list. Notices for the IETF-Announce
list should be sent to: ietf-announce-post@ietf.org
All working group actions shall be taken in a public forum, and wide
participation is encouraged. A working group will conduct much of its
business via electronic mail distribution lists but may meet
periodically to discuss and review task status and progress, to
resolve specific issues and to direct future activities. It is
common, but not required, that a working group will meet at the
trimester IETF Plenary events. Additionally, interim sessions may be
scheduled for telephone conference, video teleconference, or for
face-to-face (physical) sessions.
All working group sessions (including those held outside of the IETF
meetings) shall be reported by making minutes available. These
minutes should include the agenda for the session, an account of the
Bradner [Page 9]
Internet-Draft Working Group Guidelines March 1997
discussion including any decisions made, and a list of attendees. The
Working Group Chair is responsible for insuring that session minutes
are written and distributed, though the actual task may be performed
by someone designated by the Working Group Chair. The minutes shall
be submitted in printable ASCII text for publication in the IETF
Proceedings, and for posting in the IETF Directories and are to be
sent to: minutes@ietf.org
3.2. Session venue
Each working group will determine the balance of email and face-to-
face sessions that is appropriate for achieving its milestones.
Electronic mail permits the widest participation; face-to-face
meetings often permit better focus and therefore can be more
efficient for reaching a consensus among a core of the working group
participants. In determining the balance, the WG must ensure that
its process does not serve to exclude contribution by email-only
participants. Also note that decisions reached during IETF meetings
are NOT final, but must be conveyed to the mailing list to verify WG
consensus.
IETF Meetings
If a WG needs a session at an IETF meeting, the Chair must apply for
time-slots as soon as the first announcement of that IETF meeting is
made by the IETF Secretariat to the WG-chairs list. Session time is
a scarce resource at IETF meetings, so placing requests early will
facilitate schedule coordination for WGs requiring the same set of
experts.
The application for a WG session at an IETF meeting shall be made to
the IETF Secretariat at the address agenda@ietf.org. Alternatively
some Area Directors may want to coordinate WG sessions in their area
and request that time slots be coordinated through them. If this is
the case it will be noted in the IETF meeting announcement. A WG
scheduling request must contain:
- The amount of time requested;
- The rough outline of the WG agenda that is expected to be
covered;
- The estimated number of people that will attend the WG session;
- Related WGs that must not be scheduled for the same time slot(s);
and
- Individuals whose attendance is desired.
NOTE: While open discussion and contribution is essential to working
group success, the Chair is responsible for ensuring forward
progress. When acceptable to the WG, the Chair may call for
restricted participation (but not restricted attendance!) at IETF
working group sessions for the purpose of achieving progress. The
Working Group Chair then has the authority to refuse to grant the
Bradner [Page 10]
Internet-Draft Working Group Guidelines March 1997
floor to any individual who is unprepared or otherwise covering
inappropriate material, or who, in the opinion of the Chair is
disrupting the WG process. The Chair should consult with the AD if
the individual persists in disruptive behavior.
On-line
It can be quite useful to conduct email exchanges in the same manner
as a face-to-face session, with published schedule and agenda, as
well as on-going summarization and consensus polling.
Many working group participants hold that mailing list discussion is
the best place to consider and resolve issues and make decisions.
Choice of operational style is made by the working group itself. It
is important to note, however, that Internet email discussion is
possible for a much wider base of interested persons than is
attendance at IETF meetings, due to the time and expense required to
attend.
As with face-to-face sessions occasionally one or more individuals
may engage in behavior on a mailing list which disrupts the WG's
progress. In these cases the Chair should attempt to discourage the
behavior by communication directly with the offending individual
rather than on the open mailing list. If the behavior persists then
the Chair must involve the AD in the issue. As a last resort and
after explicit warnings, the AD, with the approval of the IESG, may
request that the mailing list maintainer block the ability of the
offending individual to post to the mailing list. (If the mailing
list software permits this type of operation.) Even if this is done,
the individual must not be prevented from receiving messages posted
to the list.
3.3. Session management
Working groups make decisions through a "rough consensus" process.
IETF consensus does not require that all participants agree although
this is, of course, preferred. In general the dominant view of the
working group shall prevail. (However, it must be noted that
"dominance" is not to be determined on the basis of volume or
persistence, but rather a more general sense of agreement.) Consensus
can be determined by a show of hands, humming, or any other means on
which the WG agrees (by rough consensus, of course). Note that 51%
of the working group does not qualify as "rough consensus" and 99% is
better than rough. It is up to the Chair to determine that rough
consensus has been reached.
The challenge to managing working group sessions is to balance the
need for open and fair consideration of the issues against the need
to make forward progress. The working group, as a whole, has the
final responsibility for striking this balance. The Chair has the
Bradner [Page 11]
Internet-Draft Working Group Guidelines March 1997
responsibility for overseeing the process but may delegate direct
process management to a formally-designated Facilitator.
It is occasionally appropriate to revisit a topic, to re-evaluate
alternatives or to improve the group's understanding of a relevant
decision. However, unnecessary repeated discussions on issues can be
avoided if the Chair makes sure that the main arguments in the
discussion (and the outcome) are summarized and archived after a
discussion has come to conclusion. It is also good practice to note
important decisions/consensus reached by email in the minutes of the
next 'live' session, and to summarize briefly the decision-making
history in the final documents the WG produces.
To facilitate making forward progress, a Working Group Chair may wish
to decide to reject or defer the input from a member, based upon the
following criteria:
Old
The input pertains to a topic that already has been resolved and is
redundant with information previously available;
Minor
The input is new and pertains to a topic that has already been
resolved, but it is felt to be of minor import to the existing
decision;
Timing
The input pertains to a topic that the working group has not yet
opened for discussion; or
Scope
The input is outside of the scope of the working group charter.
3.4. Contention and appeals
Disputes are possible at various stages during the IETF process. As
much as possible the process is designed so that compromises can be
made, and genuine consensus achieved, however there are times when
even the most reasonable and knowledgeable people are unable to
agree. To achieve the goals of openness and fairness, such conflicts
must be resolved by a process of open review and discussion.
Formal procedures for requesting a review of WG, Chair, AD or IESG
actions and conducting appeals are documented in The Internet
Standards Process [1].
4. Working Group Termination
Working groups are typically chartered to accomplish a specific task
or tasks. After the tasks are complete, the group will be disbanded.
Bradner [Page 12]
Internet-Draft Working Group Guidelines March 1997
However if a WG produces a Proposed or Draft Standard, the WG will
become dormant rather than disband (i.e., the WG will no longer
conduct formal activities, but the mailing list will remain available
to review the work as it moves to Draft Standard and Standard
status.)
If, at some point, it becomes evident that a working group is unable
to complete the work outlined in the charter, or if the assumptions
which that work was based have been modified in discussion or by
experience, the Area Director, in consultation with the working group
can either:
1. Recharter to refocus its tasks,
2. Choose new Chair(s), or
3. Disband.
If the working group disagrees with the Area Director's choice, it
may appeal to the IESG.
5. Rechartering a Working Group
Updated milestones are re-negotiated with the Area Director and the
IESG, as needed, and then are submitted to the IESG Secretary: IESG-
secretary@ietf.org
Rechartering (other than revising milestones) a working group follows
the same procedures that the initial chartering does. (see section
xx) The revised charter must be submitted to the IESG for approval.
As with the initial chartering, the IESG may approve new charter as-
is, it may request that changes be made in the new charter, or it may
decline to approve the rechartered working group. In the latter case
the working group is disbanded.
6. Staff Roles
Working groups require considerable care and feeding. In addition to
general participation, successful working groups benefit from the
efforts of participants filling specific functional roles. The AD
must approve the specific people for each of these roles, and they
serve at the discretion of the AD.
6.1. WG Chair
The Working Group Chair is concerned with making forward progress
through a fair and open process, and has wide discretion in the
conduct of WG business. The Chair must ensure that a number of tasks
are performed, either directly or by others assigned to the tasks.
This encompasses at the very least the following:
Ensure WG process and content management
Bradner [Page 13]
Internet-Draft Working Group Guidelines March 1997
The Chair has ultimate responsibility for ensuring that a working
group achieves forward progress and meets its milestones. The Chair
is also responsible to ensure that the working group operates in an
open and fair manner. For some working groups, this can be
accomplished by having the Chair perform all management-related
activities. In other working groups -- particularly those with large
or divisive participation -- it is helpful to allocate process and/or
secretarial functions to other participants. Process management
pertains strictly to the style of working group interaction and not
to its content. It ensures fairness and detects redundancy. The
secretarial function encompasses document editing. It is quite
common for a working group to assign the task of specification Editor
to one or two participants. Often, they also are part of the design
team, described below.
Moderate the WG email list
The Chair should attempt to ensure that the discussions on this list
are relevant and that they converge to consensus agreements. The
Chair should make sure that discussions on the list are summarized
and that the outcome is well documented (to avoid repetition). The
Chair also may choose to schedule organized on-line "sessions" with
agenda and deliverables. These can be structured as true meetings,
conducted over the course of several days (to allow participation
across the Internet.) Organize, prepare and chair face-to-face & on-
line formal sessions
Plan WG Sessions
The Chair should plan and announce all WG sessions well in advance.
(See section xx)
Communicate results of sessions
The Chair and/or Secretary must ensure that minutes of a session are
taken and that an attendance list is circulated. (See section xx)
Immediately after a session, the WG Chair must immediately provide
the Area Director with a very short report (approximately one
paragraph, via email) on the session. This is used in an Area Report
as presented in the Proceedings of each IETF meeting.
Distribute the workload
Of course each WG will have participants who may not be able (or
want) to do any work at all. Most of the time the bulk of the work is
done by a few dedicated participants. It is the task of the Chair to
motivate enough experts to allow for a fair distribution of the
workload.
Document development
Working groups produce documents and documents need authors. The
Chair must make sure that authors of WG documents incorporate changes
Bradner [Page 14]
Internet-Draft Working Group Guidelines March 1997
as agreed to by the WG. (See section xx)
Document publication
The Chair and/or Document Editor will work with the RFC Editor to
ensure document conformance with RFC publication requirements and to
coordinate any editorial changes suggested by the RFC Editor. A
particular concern is that all participants are working from the same
version of a document at the same time.
Document implementations
Under the procedures described in [1] the Chair is responsible for
documenting the specific implementations which qualify the
specification for Draft or Internet Standard status along with
documentation about testing of the interoperation of these
implementations.
6.2. WG Secretary
Taking minutes and editing working group documents often is performed
by a specifically-designated participant or set of participants. In
this role, the Secretary's job is to record WG decisions, rather than
to perform basic specification.
6.3. Document Editor
Most IETF working groups focus their efforts on a document, or set of
documents, that capture the results of the group's work. A working
group generally designates a person or persons to serve as the Editor
for a particular document. The Document Editor is responsible for
ensuring that the contents of the document accurately reflect the
decisions that have been made by the working group.
As a general practice, the Working Group Chair and Document Editor
positions are filled by different individuals to help ensure that the
resulting documents accurately reflect the consensus of the working
group and that all processes are followed.
6.4. WG Facilitator
When meetings tend to become distracted or divisive, it often is
helpful to assign the task of "process management" to one
participant. Their job is to oversee the nature, rather than the
content, of participant interactions. That is, they attend to the
style of the discussion and to the schedule of the agenda, rather
than making direct technical contributions themselves.
6.5. Design teams
The majority of the detailed specification effort within a working
group may be done by self-selecting sub-groups, referred to as design
teams, with the (implicit or explicit) approval of the working group
and the explicit approval of the AD. The team may hold closed
Bradner [Page 15]
Internet-Draft Working Group Guidelines March 1997
sessions for conducting portions of the specification effort. In some
cases design teams are necessary to make forward progress when
preparing a document. All work conducted by a design team must be
available for review by all working group participants and the design
team must be responsive to the direction of the working group's
consensus.
6.6. Working Group Consultant
At the discretion of the AD, a Consultant may be assigned to a
working group. Consultants have specific technical background
appropriate to the WG and experience in Internet architecture and
IETF process.
6.7. Area Director
Area Directors are responsible for ensuring that working groups in
their area produce coherent, coordinated, architecturally consistent
and timely output as a contribution to the overall results of the
IETF.
7. Working Group Documents
7.1. Session documents
All relevant documents for a session (including the final agenda)
should be published and available at least two weeks before a session
starts.
7.2. IETF meeting documents
In preparing for an IETF meeting it is helpful to have ready access
to all documents that are being reviewed. Thus all documents which
will be under discussion in a working group session must be published
as Internet-Drafts before the session.
7.3. Internet-Drafts (I-D)
The Internet-Drafts directory is provided to working groups as a
resource for posting and disseminating in-process copies of working
group documents. This repository is replicated at various locations
around the Internet. It is encouraged that draft documents be posted
as soon as they become reasonably stable.
It is stressed here that Internet-Drafts are working documents and
have no official standards status whatsoever. They may, eventually,
turn into a standards-track document or they may sink from sight.
Internet-Drafts are submitted to: internet-drafts@ietf.org
The format of an Internet-Draft must be the same as for an RFC [2].
Further, an I-D must contain:
- Beginning, standard, boilerplate text which is provided by the
Bradner [Page 16]
Internet-Draft Working Group Guidelines March 1997
Secretariat;
- The I-D filename; and
- The expiration date for the I-D.
Complete specification of requirements for an Internet-Draft are
found in the file "1id-guidelines.txt" in the Internet-Drafts
directory at an Internet Repository site. The organization of the
Internet-Drafts directory is found in the file "1id-organization" in
the Internet-Drafts directory at an Internet Repository site. This
file also contains the rules for naming Internet-Drafts (See [1] for
more information about Internet-Drafts.)
7.4. Request For Comments (RFC)
The work of an IETF working group often results in publication of one
or more documents, as part of the Request For Comments (RFCs) [1]
series. This series is the archival publication record for the
Internet community. A document can be written by an individual in a
working group, by a group as a whole with a designated Editor, or by
others not involved with the IETF. The designated author need not be
the group Chair(s).
NOTE: The RFC series is a publication mechanism only and publication
does not determine the IETF status of a document. Status is
determined through separate, explicit status labels assigned by the
IESG on behalf of the IETF. In other words, the reader is reminded
that all Internet Standards are published as RFCs, but NOT all RFCs
specify standards. [4]
7.5. Submission of documents
When a WG decides that a document is ready for publication, the
following must be done:
- The version of the relevant document exactly as approved by the WG
must be in the Internet-Drafts directory;
- The relevant document must be formatted according to RFC rules
[5].
- The WG Chair sends email to the relevant Area Director, with a
copy to the IESG Secretary. The mail should contain the reference
to the document, and the action requested.
The IESG Secretary will acknowledge receipt of the email. Unless
returned to the WG for further development, progressing of the
document is then the responsibility of the IESG. After IESG
approval, responsibility for final disposition is the joint
responsibility of the RFC Editor and the WG Chair and the Document
Editor.
8. Review of documents
The IESG reviews all documents submitted for publication as RFCs.
Bradner [Page 17]
Internet-Draft Working Group Guidelines March 1997
Usually minimal IESG review is necessary in the case of a submission
from a WG intended as an Informational or Experimental RFC. More
extensive review is undertaken in the case of standards-track
documents.
Before the IESG makes a final decision on a standards-track document,
the IESG Secretary will issue a "Last-Call" to the IETF mailing list.
This Last Call will announce the intention of the IESG to consider
the document, and it will solicit final comments from the IETF within
a period of two weeks. It is important to note that a Last-Call is
intended as a brief, final check with the Internet community, to make
sure that no important concerns have been missed or misunderstood.
The Last-Call should not serve as a more general, in-depth review.
The IESG review takes into account responses to the Last-Call and
will lead to one of these possible conclusions:
1. The document is accepted as is for the status requested.
This fact will be announced by the IESG Secretary to the IETF
mailing list and to the RFC Editor.
2. The document is accepted as-is but not for the status requested.
This fact will be announced by the IESG Secretary to the IETF
mailing list and to the RFC Editor. (see [1] for more details)
2. Changes regarding content are suggested to the author(s)/WG.
Suggestions from the IESG must be clear and direct, so as to
facilitate working group and author correction of the
specification. If the author(s)/WG can explained to the
satisfaction of the IESG why the changes are not necessary, the
document will be accepted for publication as under point 1, above.
If the changes are made the revised document may be resubmitted
for IESG review.
3. The document is rejected.
Any document rejection will be accompanied by strong and thorough
arguments from the IESG. Although the IETF and working group
process is structured such that this alternative is not likely to
arise for documents coming from a working group the IESG has the
right and responsibility to reject documents that the IESG feels
are fatally flawed in some way.
If any individual or group of individuals feels that the review
treatment has been unfair, there is the opportunity to make a
procedural complaint. The mechanism for this type of complaints is
described in [1].
Bradner [Page 18]
Internet-Draft Working Group Guidelines March 1997
9. Security Considerations
This type of document does not have an impact on the security of
the network infrastructure or of applications.
10. Acknowledgments
This revision of this document relies heavily on the previous
version (RFC 1603) which was edited by Erik Huizer and Dave
Crocker. It will be reviewed by the poisson working group.
11. References
[1] Bradner, S. Ed., "The Internet Standards Process -- Revision 3",
RFC 2026, Harvard University, October 1996.
[2] Hovey, R., S. Bradner, "The Organizations involved in the IETF
Standards Process", RFC 2028, Digital Equipment Corp., Harvard
University, October 1996
[3] Gavin, J., "IAB and IESG Selection, Confirmation, and Recall
Process: Operation of the Nominating and Recall Committees", RFC
2027, CommerceNet, October 1996
[4] Huitema, C., J. Postel, S. Crocker, "Not all RFCs are Standards",
RFC 1796, INRIA, ISI, CyberCash, April 1995
[5] Postel, J., "Instructions to RFC Authors", RFC 1543,
USC/Information Sciences Institute, October 1996.
12. Authors' Address
Scott Bradner
Harvard University
1350 Mass Ave.
Cambridge MA
02138
USA
phone +1 617 495 3864
Appendix: Sample Working Group Charter
GOOD SAMPLE WG CHARTER TO BE SELECTED
Bradner [Page 19]
