As per Relevance of the word director, we have this rfc below:
Network Working Group S.
Request for Comments: 2418
Obsoletes: 1603 Harvard
BCP: 25 September 1998
Category: Best Current
IETF Working
Guidelines and
Status of this
This document specifies an Internet Best Current Practices for
Internet Community, and requests discussion and suggestions
improvements. Distribution of this memo is unlimited
Copyright
Copyright (C) The Internet Society (1998). All Rights Reserved
The Internet Engineering Task Force (IETF) has responsibility
developing and reviewing specifications intended as
Standards. IETF activities are organized into working groups (WGs).
This document describes the guidelines and procedures for
and operation of IETF working groups. It also describes the
relationship between IETF participants WG and the
Engineering Steering Group (IESG) and the basic duties of
participants, including WG Chairs, WG participants, and IETF
Directors
Table of
Abstract ......................................................... 1
1. Introduction .................................................. 2
1.1. IETF approach to standardization .......................... 4
1.2. Roles within a Working Group .............................. 4
2. Working group formation ....................................... 4
2.1. Criteria for formation .................................... 4
2.2. Charter ................................................... 6
2.3. Charter review & approval ................................. 8
2.4. Birds of a feather (BOF) .................................. 9
3. Working Group Operation ....................................... 10
3.1. Session planning .......................................... 11
3.2. Session venue ............................................. 11
3.3. Session management ........................................ 13
3.4. Contention and appeals .................................... 15
Bradner Best Current Practice [Page 1]
RFC 2418 Working Group Guidelines September 1998
4. Working Group Termination ..................................... 15
5. Rechartering a Working Group .................................. 15
6. Staff Roles ................................................... 16
6.1. WG Chair .................................................. 16
6.2. WG Secretary .............................................. 18
6.3. Document Editor ........................................... 18
6.4. WG Facilitator ............................................ 18
6.5. Design teams .............................................. 19
6.6. Working Group Consultant .................................. 19
6.7. Area Director ............................................. 19
7. Working Group Documents ....................................... 19
7.1. Session documents ......................................... 19
7.2. Internet-Drafts (I-D) ..................................... 19
7.3. Request For Comments (RFC) ................................ 20
7.4. Working Group Last-Call ................................... 20
7.5. Submission of documents ................................... 21
8. Review of documents ........................................... 21
9. Security Considerations ....................................... 22
10. Acknowledgments .............................................. 23
11. References ................................................... 23
12. Editor's Address ............................................. 23
Appendix: Sample Working Group Charter .......................... 24
Full Copyright Statement ......................................... 26
1.
The Internet, a loosely-organized international collaboration
autonomous, interconnected networks, supports host-to-
communication through voluntary adherence to open protocols
procedures defined by Internet Standards. There are also
isolated interconnected networks, which are not connected to
global Internet but use the Internet Standards. Internet
are developed in the Internet Engineering Task Force (IETF).
document defines guidelines and procedures for IETF working groups
The Internet Standards Process of the IETF is defined in [1].
organizations involved in the IETF Standards Process are described
[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
technology used on it. The primary activities of the IETF
performed by committees known as working groups. There are
more than 100 working groups. (See the IETF web page for an up-to
date list of IETF Working Groups - http://www.ietf.org.)
groups tend to have a narrow focus and a lifetime bounded by
completion of a specific set of tasks, although there are exceptions
Bradner Best Current Practice [Page 2]
RFC 2418 Working Group Guidelines September 1998
For management purposes, the IETF working groups are
together into areas, with each area having a separate focus.
example, the security area deals with the development of security
related technology. Each IETF area is managed by one or two
Directors (ADs). There are currently 8 areas in the IETF but
number changes from time to time. (See the IETF web page for a
of the current areas, the Area Directors for each area, and a list
which working groups are assigned to each area.)
In many areas, the Area Directors have formed an advisory group
directorate. These comprise experienced members of the IETF and
technical community represented by the area. The specific name
the details of the role for each group differ from area to area,
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,
also selects an overall chair for the IETF. The nominations
is described in [3].
The area directors sitting as a body, along with the IETF Chair
comprise the Internet Engineering Steering Group (IESG). The
Executive Director is an ex-officio participant of the IESG, as
the IAB Chair and a designated Internet Architecture Board (IAB
liaison. The IESG approves IETF Standards and approves
publication of other IETF documents. (See [1].)
A small IETF Secretariat provides staff and administrative
for the operation of the IETF
There is no formal membership in the IETF. Participation is open
all. This participation may be by on-line contribution,
at face-to-face sessions, or both. Anyone from the
community who has the time and interest is urged to participate
IETF meetings and any of its on-line working group discussions
Participation is by individual technical contributors, rather than
formal representatives of organizations
This document defines procedures and guidelines for the formation
operation of working groups in the IETF. It defines the relations
working groups to other bodies within the IETF. The duties of
group Chairs and Area Directors with respect to the operation of
working group are also defined. When used in this document the
words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD",
"SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" are to
interpreted as described in RFC 2119 [6]. RFC 2119 defines the
of these key words to help make the intent of standards
documents as clear as possible. The same key words are used in
Bradner Best Current Practice [Page 3]
RFC 2418 Working Group Guidelines September 1998
document to help smooth WG operation and reduce the chance
confusion about the processes
1.1. IETF approach to
Familiarity with The Internet Standards Process [1] is essential
a complete understanding of the philosophy, procedures and
described in this document
1.2. Roles within a Working
The document, "Organizations Involved in the IETF Standards Process
[2] describes the roles of a number of individuals within a
group, including the working group chair and the document editor
These descriptions are expanded later in this document
2. Working group
IETF working groups (WGs) are the primary mechanism for
of IETF specifications and guidelines, many of which are intended
be standards or recommendations. A working group may be
at the initiative of an Area Director or it may be initiated by
individual or group of individuals. Anyone interested in creating
IETF working group MUST obtain the advice and consent of the
Area Director(s) in whose area the working group would fall and
proceed through the formal steps detailed in this section
Working groups are typically created to address a specific problem
to produce one or more specific deliverables (a guideline,
specification, etc.). Working groups are generally expected to
short-lived in nature. Upon completion of its goals and
of its objectives, the working group is terminated. A working
may also be terminated for other reasons (see section 4).
Alternatively, with the concurrence of the IESG, Area Director,
WG Chair, and the WG participants, the objectives or assignment
the working group may be extended by modifying the working group'
charter through a rechartering process (see section 5).
2.1. Criteria for
When determining whether it is appropriate to create a working group
the Area Director(s) and the IESG will consider several issues
- Are the issues that the working group plans to address clear
relevant to the Internet community
- Are the goals specific and reasonably achievable, and
within a reasonable time frame
Bradner Best Current Practice [Page 4]
RFC 2418 Working Group Guidelines September 1998
- What are the risks and urgency of the work, to determine the
of effort required
- Do the working group's activities overlap with those of
working group? If so, it may still be appropriate to create
working group, but this question must be considered carefully
the Area Directors as subdividing efforts often dilutes
available technical expertise
- Is there sufficient interest within the IETF in the
group's topic with enough people willing to expend the effort
produce the desired result (e.g., a protocol specification)?
Working groups require considerable effort, including
of the working group process, editing of working group documents
and contributing to the document text. IETF experience
that these roles typically cannot all be handled by one person;
minimum of four or five active participants in the
positions are typically required in addition to a minimum of
or two dozen people that will attend the working group
and contribute on the mailing list. NOTE: The interest must
broad enough that a working group would not be seen as merely
activity of a single vendor
- Is there enough expertise within the IETF in the working group'
topic, and are those people interested in contributing in
working group
- Does a base of interested consumers (end-users) appear to
for the planned work? Consumer interest can be measured
participation of end-users within the IETF process, as well as
less direct means
- Does the IETF have a reasonable role to play in the
of the technology? There are many Internet-related
that may be interesting to IETF members but in some cases the
may not be in a position to effect the course of the technology
the "real world". This can happen, for example, if the
is being developed by another standards body or an
consortium
- Are all known intellectual property rights relevant to
proposed working group's efforts issues understood
- Is the proposed work plan an open IETF effort or is it an
to "bless" non-IETF technology where the effect of input from
participants may be limited
Bradner Best Current Practice [Page 5]
RFC 2418 Working Group Guidelines September 1998
- Is there a good understanding of any existing work that
relevant to the topics that the proposed working group is
pursue? This includes work within the IETF and elsewhere
- Do the working group's goals overlap with known work in
standards body, and if so is adequate liaison in place
Considering the above criteria, the Area Director(s), using his
her best judgement, will decide whether to pursue the formation
the group through the chartering process
2.2.
The formation of a working group requires a charter which
primarily negotiated between a prospective working group Chair
the relevant Area Director(s), although final approval is made by
IESG with advice from the Internet Architecture Board (IAB).
charter is a contract between a working group and the IETF to
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
describes the approach that will be taken to achieve the goals
3. Enumerates a set of milestones together with time frames for
completion
When the prospective Chair(s), the Area Director and the
Secretariat are satisfied with the charter form and content,
becomes the basis for forming a working group. Note that an
Director MAY require holding an exploratory Birds of a Feather (BOF
meeting, as described below, to gage the level of support for
working group before submitting the charter to the IESG and IAB
approval
Charters may be renegotiated periodically to reflect the
status, organization or goals of the working group (see section 5).
Hence, a charter is a contract between the IETF and the working
which is committing to meet explicit milestones and
specific "products".
Specifically, each charter consists of the following sections
Working group
A working group name should be reasonably descriptive
identifiable. Additionally, the group shall define an
(maximum 8 printable ASCII characters) to reference the group
the IETF directories, mailing lists, and general documents
Bradner Best Current Practice [Page 6]
RFC 2418 Working Group Guidelines September 1998
Chair(s
The working group may have one or more Chairs to perform
administrative functions of the group. The email address(es)
the Chair(s) shall be included. Generally, a working group
limited to two chairs
Area and Area Director(s
The name of the IETF area with which the working group
affiliated and the name and electronic mail address of
associated Area Director(s).
Responsible Area
The Area Director who acts as the primary IESG contact for
working group
Mailing
An IETF working group MUST have a general Internet mailing list
Most of the work of an IETF working group will be conducted on
mailing list. The working group charter MUST include
1. The address to which a participant sends a subscription
and the procedures to follow when subscribing
2. The address to which a participant sends submissions
special procedures, if any,
3. The location of the mailing list archive. A message
MUST be maintained in a public place which can be accessed
FTP or via the web
As a service to the community, the IETF Secretariat operates
mailing list archive for working group mailing lists. In
to take advantage of this service, working group mailing
MUST include the address "wg_acronym-archive@lists.ietf.org
(where "wg_acronym" is the working group acronym) in
mailing list in order that a copy of all mailing list
be recorded in the Secretariat's archive. Those archives
located at ftp://ftp.ietf.org/ietf-mail-archive.
robustness, WGs SHOULD maintain an additional archive
from that maintained by the Secretariat
Description of working
The focus and intent of the group shall be set forth briefly.
reading this section alone, an individual should be able to
whether this group is relevant to their own work. The
paragraph must give a brief summary of the problem area, basis
goal(s) and approach(es) planned for the working group.
paragraph can be used as an overview of the working group'
Bradner Best Current Practice [Page 7]
RFC 2418 Working Group Guidelines September 1998
effort
To facilitate evaluation of the intended work and to provide on
going guidance to the working group, the charter must describe
problem being solved and should discuss objectives and
impact with respect to
-
-
-
- Network
-
- Transition (where applicable
Goals and
The working group charter MUST establish a timetable for
work items. While this may be renegotiated over time, the list
milestones and dates facilitates the Area Director's tracking
working group progress and status, and it is indispensable
potential participants identifying the critical moments for input
Milestones shall consist of deliverables that can be qualified
showing specific achievement; e.g., "Internet-Draft finished"
fine, but "discuss via email" is not. It is helpful to
milestones for every 3-6 months, so that progress can be
easily. This milestone list is expected to be
periodically (see section 5).
An example of a WG charter is included as Appendix A
2.3. Charter review &
Proposed working groups often comprise technically
participants who are not familiar with the history of
architecture or IETF processes. This can, unfortunately, lead
good working group consensus about a bad design. To
working group efforts, an Area Director may assign a Consultant
among the ranks of senior IETF participants. (Consultants
described in section 6.) At the discretion of the Area Director
approval of a new WG may be withheld in the absence of
consultant resources
Once the Area Director (and the Area Directorate, as the
Director deems appropriate) has approved the working group charter
the charter is submitted for review by the IAB and approval by
IESG. After a review period of at least a week the proposed
is posted to the IETF-announce mailing list as a public notice
the formation of the working group is being considered. At the
time the proposed charter is also posted to the "new-work"
Bradner Best Current Practice [Page 8]
RFC 2418 Working Group Guidelines September 1998
list. This mailing list has been created to let
representatives from other standards organizations know about
IETF working groups. After another review period lasting at least
week the IESG MAY approve the charter as-is, it MAY request
changes be made in the charter, or MAY decline to approve
of the working
If the IESG approves the formation of the working group it
the approved charter to the IETF Secretariat who records and
the information into the IETF tracking database. The working
is announced to the IETF-announce a by the IETF Secretariat
2.4. Birds of a Feather (BOF
Often it is not clear whether an issue merits the formation of
working group. To facilitate exploration of the issues the
offers the possibility of a Birds of a Feather (BOF) session, as
as the early formation of an email list for preliminary discussion
In addition, a BOF may serve as a forum for a single presentation
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
to hold a BOF on a subject. The request MUST be filed with a
Area Director who must approve a BOF before it can be scheduled.
person who requests the BOF may be asked to serve as Chair of
BOF
The Chair of the BOF is also responsible for providing a report
the outcome of the BOF. If the Area Director approves, the BOF
then scheduled by submitting a request to agenda@ietf.org with
to the Area Director(s). A BOF description and agenda are
before a BOF can be scheduled
Available time for BOFs is limited, and BOFs are held at
discretion of the ADs for an area. The AD(s) may require
assurances before authorizing a BOF. For example
- The Area Director MAY require the establishment of an open
list prior to authorizing a BOF. This permits initial
and sharing of framework, vocabulary and approaches, in order
make the time spent in the BOF more productive
- The Area Director MAY require that a BOF be held, prior
establishing a working group (see section 2.2).
- The Area Director MAY require that there be a draft of the
charter prior to holding a BOF
Bradner Best Current Practice [Page 9]
RFC 2418 Working Group Guidelines September 1998
- The Area Director MAY require that a BOF not be held until
Internet-Draft describing the proposed technology has
published so it can be used as a basis for discussion in the BOF
In general, a BOF on a particular topic is held only once (ONE
at one IETF Plenary meeting). Under unusual circumstances
Directors may, at their discretion, allow a BOF to meet for a
time. BOFs are not permitted to meet three times. Note that
other things being equal, WGs will be given priority for
space over BOFs. Also, occasionally BOFs may be held for
purposes than to discuss formation of a working group
Usually the outcome of a BOF will be one of the following
- There was enough interest and focus in the subject to warrant
formation of a WG
- While there was a reasonable level of interest expressed in
BOF some other criteria for working group formation was not
(see section 2.1).
- The discussion came to a fruitful conclusion, with results to
written down and published, however there is no need to
a WG;
- There was not enough interest in the subject to warrant
formation of a WG
3. Working Group
The IETF has basic requirements for open and fair participation
for thorough consideration of technical alternatives. Within
constraints, working groups are autonomous and each determines
of the details of its own operation with respect to
participation, reaching closure, etc. The core rule for operation
that acceptance or agreement is achieved via working group "
consensus". WG participants should specifically note
requirements for disclosure of conflicts of interest in [2].
A number of procedural questions and issues will arise over time,
it is the function of the Working Group Chair(s) to manage the
process, keeping in mind that the overall purpose of the group is
make progress towards reaching rough consensus in realizing
working group's goals and objectives
There are few hard and fast rules on organizing or conducting
group activities, but a set of guidelines and practices has
over time that have proven successful. These are listed here,
Bradner Best Current Practice [Page 10]
RFC 2418 Working Group Guidelines September 1998
actual choices typically determined by the working group
and the Chair(s).
3.1. Session
For coordinated, structured WG interactions, the Chair(s)
publish a draft agenda well in advance of the actual session.
agenda should contain at least
- The items for discussion
- The estimated time necessary per item;
- A clear indication of what documents the participants will need
read before the session in order to be well prepared
Publication of the working group agenda shall include sending a
of the agenda to the working group mailing list and
agenda@ietf.org
All working group actions shall be taken in a public forum, and
participation is encouraged. A working group will conduct much of
business via electronic mail distribution lists but may
periodically to discuss and review task status and progress,
resolve specific issues and to direct future activities.
Plenary meetings are the primary venue for these face-to-face
group sessions, and it is common (though not required) that
"interim" face-to-face meetings, telephone conferences, or
conferences may also be held. Interim meetings are subject to
same rules for advance notification, reporting, open participation
and process, which apply to other working group meetings
All working group sessions (including those held outside of the
meetings) shall be reported by making minutes available.
minutes should include the agenda for the session, an account of
discussion including any decisions made, and a list of attendees.
Working Group Chair is responsible for insuring that session
are written and distributed, though the actual task may be
by someone designated by the Working Group Chair. The minutes
be submitted in printable ASCII text for publication in the
Proceedings, and for posting in the IETF Directories and are to
sent to: minutes@ietf.
3.2. Session
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-
meetings often permit better focus and therefore can be
efficient for reaching a consensus among a core of the working
Bradner Best Current Practice [Page 11]
RFC 2418 Working Group Guidelines September 1998
participants. In determining the balance, the WG must ensure
its process does not serve to exclude contribution by email-
participants. Decisions reached during a face-to-face meeting
topics or issues which have not been discussed on the mailing list
or are significantly different from previously arrived mailing
consensus MUST be reviewed on the mailing list
IETF
If a WG needs a session at an IETF meeting, the Chair must apply
time-slots as soon as the first announcement of that IETF meeting
made by the IETF Secretariat to the WG-chairs list. Session time
a scarce resource at IETF meetings, so placing requests early
facilitate schedule coordination for WGs requiring the same set
experts
The application for a WG session at an IETF meeting MUST be made
the IETF Secretariat at the address agenda@ietf.org. Some
Directors may want to coordinate WG sessions in their area
request that time slots be coordinated through them. If this is
case it will be noted in the IETF meeting announcement. A
scheduling request MUST contain
- The working group name and full title
- 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 should not be scheduled for the same time slot(s);
- Optionally a request can be added for the WG session to
transmitted over the Internet in audio and video
NOTE: While open discussion and contribution is essential to
group success, the Chair is responsible for ensuring
progress. When acceptable to the WG, the Chair may call
restricted participation (but not restricted attendance!) at
working group sessions for the purpose of achieving progress.
Working Group Chair then has the authority to refuse to grant
floor to any individual who is unprepared or otherwise
inappropriate material, or who, in the opinion of the Chair
disrupting the WG process. The Chair should consult with the
Director(s) if the individual persists in disruptive behavior
On-
It can be quite useful to conduct email exchanges in the same
as a face-to-face session, with published schedule and agenda,
well as on-going summarization and consensus polling
Bradner Best Current Practice [Page 12]
RFC 2418 Working Group Guidelines September 1998
Many working group participants hold that mailing list discussion
the best place to consider and resolve issues and make decisions.
choice of operational style is made by the working group itself.
is important to note, however, that Internet email discussion
possible for a much wider base of interested persons than
attendance at IETF meetings, due to the time and expense required
attend
As with face-to-face sessions occasionally one or more
may engage in behavior on a mailing list which disrupts the WG'
progress. In these cases the Chair should attempt to discourage
behavior by communication directly with the offending
rather than on the open mailing list. If the behavior persists
the Chair must involve the Area Director in the issue. As a
resort and after explicit warnings, the Area Director, with
approval of the IESG, may request that the mailing list
block the ability of the offending individual to post to the
list. (If the mailing list software permits this type of operation.)
Even if this is done, the individual must not be prevented
receiving messages posted to the list. Other methods of mailing
control may be considered but must be approved by the AD(s) and
IESG
3.3. Session
Working groups make decisions through a "rough consensus" process
IETF consensus does not require that all participants agree
this is, of course, preferred. In general, the dominant view of
working group shall prevail. (However, it must be noted
"dominance" is not to be determined on the basis of volume
persistence, but rather a more general sense of agreement.)
can be determined by a show of hands, humming, or any other means
which the WG agrees (by rough consensus, of course). Note that 51%
of the working group does not qualify as "rough consensus" and 99%
better than rough. It is up to the Chair to determine if
consensus has been reached
It can be particularly challenging to gauge the level of consensus
a mailing list. There are two different cases where a working
may be trying to understand the level of consensus via a mailing
discussion. But in both cases the volume of messages on a topic
not, by itself, a good indicator of consensus since one or
individuals may be generating much of the traffic
In the case where a consensus which has been reached during a face
to-face meeting is being verified on a mailing list the people
were in the meeting and expressed agreement must be taken
account. If there were 100 people in a meeting and only a few
Bradner Best Current Practice [Page 13]
RFC 2418 Working Group Guidelines September 1998
on the mailing list disagree with the consensus of the meeting
the consensus should be seen as being verified. Note that
time should be given to the verification process for the mailing
readers to understand and consider any objections that may be
on the list. The normal two week last-call period should
sufficient for this
The other case is where the discussion has been held entirely
the mailing list. The determination of the level of consensus may
harder to do in this case since most people subscribed to
lists do not actively participate in discussions on the list. It
left to the discretion of the working group chair how to evaluate
level of consensus. The most common method used is for the
group chair to state what he or she believes to be the consensus
and. at the same time, requests comments from the list about
stated conclusion
The challenge to managing working group sessions is to balance
need for open and fair consideration of the issues against the
to make forward progress. The working group, as a whole, has
final responsibility for striking this balance. The Chair has
responsibility for overseeing the process but may delegate
process management to a formally-designated Facilitator
It is occasionally appropriate to revisit a topic, to re-
alternatives or to improve the group's understanding of a
decision. However, unnecessary repeated discussions on issues can
avoided if the Chair makes sure that the main arguments in
discussion (and the outcome) are summarized and archived after
discussion has come to conclusion. It is also good practice to
important decisions/consensus reached by email in the minutes of
next 'live' session, and to summarize briefly the decision-
history in the final documents the WG produces
To facilitate making forward progress, a Working Group Chair may
to decide to reject or defer the input from a member, based upon
following criteria
The input pertains to a topic that already has been resolved and
redundant with information previously available
The input is new and pertains to a topic that has already
resolved, but it is felt to be of minor import to the
decision
Bradner Best Current Practice [Page 14]
RFC 2418 Working Group Guidelines September 1998
The input pertains to a topic that the working group has not
opened for discussion;
The input is outside of the scope of the working group charter
3.4. Contention and
Disputes are possible at various stages during the IETF process.
much as possible the process is designed so that compromises can
made, and genuine consensus achieved; however, there are times
even the most reasonable and knowledgeable people are unable
agree. To achieve the goals of openness and fairness, such
must be resolved by a process of open review and discussion
Formal procedures for requesting a review of WG, Chair, Area
or IESG actions and conducting appeals are documented in The
Standards Process [1].
4. Working Group
Working groups are typically chartered to accomplish a specific
or tasks. After the tasks are complete, the group will be disbanded
However, if a WG produces a Proposed or Draft Standard, the WG
frequently become dormant rather than disband (i.e., the WG will
longer conduct formal activities, but the mailing list will
available to review the work as it moves to Draft Standard
Standard status.)
If, at some point, it becomes evident that a working group is
to complete the work outlined in the charter, or if the
which that work was based have been modified in discussion or
experience, the Area Director, in consultation with the working
can either
1. Recharter to refocus its tasks
2. Choose new Chair(s),
3. Disband
If the working group disagrees with the Area Director's choice,
may appeal to the IESG (see section 3.4).
5. Rechartering a Working
Updated milestones are renegotiated with the Area Director and
IESG, as needed, and then are submitted to the IESG Secretariat
iesg-secretary@ietf.org
Bradner Best Current Practice [Page 15]
RFC 2418 Working Group Guidelines September 1998
Rechartering (other than revising milestones) a working group
the same procedures that the initial chartering does (see section 2).
The revised charter must be submitted to the IESG and IAB
approval. As with the initial chartering, the IESG may approve
charter as-is, it may request that changes be made in the new
(including having the Working Group continue to use the old charter),
or it may decline to approve the rechartered working group. In
latter case, the working group is disbanded
6. Staff
Working groups require considerable care and feeding. In addition
general participation, successful working groups benefit from
efforts of participants filling specific functional roles. The
Director must agree to the specific people performing the WG Chair
and Working Group Consultant roles, and they serve at the
of the Area Director
6.1. WG
The Working Group Chair is concerned with making forward
through a fair and open process, and has wide discretion in
conduct of WG business. The Chair must ensure that a number of
are performed, either directly or by others assigned to the tasks
The Chair has the responsibility and the authority to make decisions
on behalf of the working group, regarding all matters of
group process and staffing, in conformance with the rules of
IETF. The AD has the authority and the responsibility to assist
making those decisions at the request of the Chair or
circumstances warrant such an intervention
The Chair's responsibility encompasses at least the following
Ensure WG process and content
The Chair has ultimate responsibility for ensuring that a
group achieves forward progress and meets its milestones.
Chair is also responsible to ensure that the working
operates in an open and fair manner. For some working groups
this can be accomplished by having the Chair perform
management-related activities. In other working groups --
particularly those with large or divisive participation -- it
helpful to allocate process and/or secretarial functions to
participants. Process management pertains strictly to the
of working group interaction and not to its content. It
fairness and detects redundancy. The secretarial
encompasses document editing. It is quite common for a
Bradner Best Current Practice [Page 16]
RFC 2418 Working Group Guidelines September 1998
group to assign the task of specification Editor to one or
participants. Sometimes, they also are part of the design team
described below
Moderate the WG email
The Chair should attempt to ensure that the discussions on
list are relevant and that they converge to consensus agreements
The Chair should make sure that discussions on the list
summarized and that the outcome is well documented (to
repetition). The Chair also may choose to schedule organized on
line "sessions" with agenda and deliverables. These can
structured as true meetings, conducted over the course of
days (to allow participation across the Internet).
Organize, prepare and chair face-to-face and on-line
sessions
Plan WG
The Chair must plan and announce all WG sessions well in
(see section 3.1).
Communicate results of
The Chair and/or Secretary must ensure that minutes of a
are taken and that an attendance list is circulated (see
3.1).
Immediately after a session, the WG Chair MUST provide the
Director with a very short report (approximately one paragraph
via email) on the session
Distribute the
Of course, each WG will have participants who may not be able (
want) to do any work at all. Most of the time the bulk of the
is done by a few dedicated participants. It is the task of
Chair to motivate enough experts to allow for a fair
of the workload
Document
Working groups produce documents and documents need authors.
Chair must make sure that authors of WG documents
changes as agreed to by the WG (see section 6.3).
Bradner Best Current Practice [Page 17]
RFC 2418 Working Group Guidelines September 1998
Document
The Chair and/or Document Editor will work with the RFC Editor
ensure document conformance with RFC publication requirements [5]
and to coordinate any editorial changes suggested by the
Editor. A particular concern is that all participants are
from the same version of a document at the same time
Document
Under the procedures described in [1], the Chair is
for documenting the specific implementations which qualify
specification for Draft or Internet Standard status along
documentation about testing of the interoperation of
implementations
6.2. WG
Taking minutes and editing working group documents often is
by a specifically-designated participant or set of participants.
this role, the Secretary's job is to record WG decisions, rather
to perform basic specification
6.3. Document
Most IETF working groups focus their efforts on a document, or set
documents, that capture the results of the group's work. A
group generally designates a person or persons to serve as the
for a particular document. The Document Editor is responsible
ensuring that the contents of the document accurately reflect
decisions that have been made by the working group
As a general practice, the Working Group Chair and Document
positions are filled by different individuals to help ensure that
resulting documents accurately reflect the consensus of the
group and that all processes are followed
6.4. WG
When meetings tend to become distracted or divisive, it often
helpful to assign the task of "process management" to
participant. Their job is to oversee the nature, rather than
content, of participant interactions. That is, they attend to
style of the discussion and to the schedule of the agenda,
than making direct technical contributions themselves
Bradner Best Current Practice [Page 18]
RFC 2418 Working Group Guidelines September 1998
6.5. Design
It is often useful, and perhaps inevitable, for a sub-group of
working group to develop a proposal to solve a particular problem
Such a sub-group is called a design team. In order for a design
to remain small and agile, it is acceptable to have closed
and private meetings. Design teams may range from an informal
between people in a hallway to a formal set of expert volunteers
the WG chair or AD appoints to attack a controversial problem.
output of a design team is always subject to approval, rejection
modification by the WG as a whole
6.6. Working Group
At the discretion of the Area Director, a Consultant may be
to a working group. Consultants have specific technical
appropriate to the WG and experience in Internet architecture
IETF process
6.7. Area
Area Directors are responsible for ensuring that working groups
their area produce coherent, coordinated, architecturally
and timely output as a contribution to the overall results of
IETF
7. Working Group
7.1. Session
All relevant documents to be discussed at a session should
published and available as Internet-Drafts at least two weeks
a session starts. Any document which does not meet this
deadline can only be discussed in a working group session with
specific approval of the working group chair(s). Since it
important that working group members have adequate time to review
documents, granting such an exception should only be done
unusual conditions. The final session agenda should be posted to
working group mailing list at least two weeks before the session
sent at that time to agenda@ietf.org for publication on the IETF
site
7.2. Internet-Drafts (I-D
The Internet-Drafts directory is provided to working groups as
resource for posting and disseminating in-process copies of
group documents. This repository is replicated at various
around the Internet. It is encouraged that draft documents be
Bradner Best Current Practice [Page 19]
RFC 2418 Working Group Guidelines September 1998
as soon as they become reasonably stable
It is stressed here that Internet-Drafts are working documents
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.
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
Secretariat on their web site and in the ftp directory
- The I-D filename;
- The expiration date for the I-D
Complete specification of requirements for an Internet-Draft
found in the file "1id-guidelines.txt" in the Internet-
directory at an Internet Repository site. The organization of
Internet-Drafts directory is found in the file "1id-organization"
the Internet-Drafts directory at an Internet Repository site.
file also contains the rules for naming Internet-Drafts. (See [1]
for more information about Internet-Drafts.)
7.3. Request For Comments (RFC
The work of an IETF working group often results in publication of
or more documents, as part of the Request For Comments (RFCs) [1]
series. This series is the archival publication record for
Internet community. A document can be written by an individual in
working group, by a group as a whole with a designated Editor, or
others not involved with the IETF
NOTE: The RFC series is a publication mechanism only and
does not determine the IETF status of a document. Status
determined through separate, explicit status labels assigned by
IESG on behalf of the IETF. In other words, the reader is
that all Internet Standards are published as RFCs, but NOT all
specify standards [4].
7.4. Working Group Last-
When a WG decides that a document is ready for publication it may
submitted to the IESG for consideration. In most cases
determination that a WG feels that a document is ready
publication is done by the WG Chair issuing a working group Last
Call. The decision to issue a working group Last-Call is at
discretion of the WG Chair working with the Area Director. A
group Last-Call serves the same purpose within a working group
Bradner Best Current Practice [Page 20]
RFC 2418 Working Group Guidelines September 1998
an IESG Last-Call does in the broader IETF community (see [1]).
7.5. Submission of
Once that a WG has determined at least rough consensus exists
the WG for the advancement of a document the following must be done
- The version of the relevant document exactly as agreed to by the
MUST be in the Internet-Drafts directory
- The relevant document MUST be formatted according to section 7.3.
- The WG Chair MUST send email to the relevant Area Director. A
of the request MUST be also sent to the IESG Secretariat. The
MUST contain the reference to the document's ID filename, and
action requested. The copy of the message to the IESG
is to ensure that the request gets recorded by the Secretariat
that they can monitor the progress of the document through
process
Unless returned by the IESG 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
joint responsibility of the RFC Editor, the WG Chair and the
Editor
8. Review of
The IESG reviews all documents submitted for publication as RFCs
Usually minimal IESG review is necessary in the case of a
from a WG intended as an Informational or Experimental RFC.
extensive review is undertaken in the case of standards-
documents
Prior to the IESG beginning their deliberations on standards-
documents, IETF Secretariat will issue a "Last-Call" to the
mailing list (see [1]). This Last Call will announce the intention
the IESG to consider the document, and it will solicit final
from the IETF within a period of two weeks. It is important to
that a Last-Call is intended as a brief, final check with
Internet community, to make sure that no important concerns have
missed or misunderstood. The Last-Call should not serve as a
general, in-depth review
The IESG review takes into account responses to the Last-Call
will lead to one of these possible conclusions
Bradner Best Current Practice [Page 21]
RFC 2418 Working Group Guidelines September 1998
1. The document is accepted as is for the status requested
This fact will be announced by the IETF Secretariat to the
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 IETF Secretariat to the
mailing list and to the RFC Editor (see [1] for more details).
3. Changes regarding content are suggested to the author(s)/WG
Suggestions from the IESG must be clear and direct, so as
facilitate working group and author correction of
specification. If the author(s)/WG can explain to
satisfaction of the IESG why the changes are not necessary,
document will be accepted for publication as under point 1, above
If the changes are made the revised document may be
for IESG review
4. Changes are suggested by the IESG and a change in status
recommended
The process described above for 3 and 2 are followed in
order
5. The document is rejected
Any document rejection will be accompanied by specific
thorough arguments from the IESG. Although the IETF and
group process is structured such that this alternative is
likely to arise for documents coming from a working group,
IESG has the right and responsibility to reject documents that
IESG feels are fatally flawed in some way
If any individual or group of individuals feels that the
treatment has been unfair, there is the opportunity to make
procedural complaint. The mechanism for this type of complaints
described in [1].
9. Security
Documents describing IETF processes, such as this one, do not have
impact on the security of the network infrastructure or of
applications
It should be noted that all IETF working groups are required
examine and understand the security implications of any
they develop. This analysis must be included in any resulting
in a Security Considerations section. Note that merely noting
significant security hole is no longer sufficient. IETF
technologies should not add insecurity to the environment in
they are run
Bradner Best Current Practice [Page 22]
RFC 2418 Working Group Guidelines September 1998
10.
This revision of this document relies heavily on the previous
(RFC 1603) which was edited by Erik Huizer and Dave Crocker. It
been reviewed by the Poisson Working Group
11.
[1] Bradner, S., Editor, "The Internet Standards Process --
3", BCP 9, RFC 2026, October 1996.
[2] Hovey, R., and S. Bradner, "The Organizations involved in
IETF Standards Process", BCP 11, RFC 2028, October 1996.
[3] Gavin, J., "IAB and IESG Selection, Confirmation, and
Process: Operation of the Nominating and Recall Committees",
10, RFC 2282, February 1998.
[4] Huitema, C., J. Postel, S. Crocker, "Not all RFCs are Standards",
RFC 1796, April 1995.
[5] Postel, J., and J. Reynolds, "Instructions to RFC Authors",
2223, October 1997.
[6] Bradner, S., "Key words for use in RFCs to Indicate
Level", BCP 14, RFC 2119, March 1997.
12. Editor's
Scott
Harvard
1350 Mass Ave
Cambridge
02138
Phone +1 617 495 3864
EMail: sob@harvard.
Bradner Best Current Practice [Page 23]
RFC 2418 Working Group Guidelines September 1998
Appendix: Sample Working Group
Working Group Name
IP Telephony (iptel
IETF Area
Transport
Chair(s):
Jonathan Rosenberg
Transport Area Director(s):
Scott Bradner
Allyn Romanow
Responsible Area Director
Allyn Romanow
Mailing Lists
General Discussion:iptel@lists.research.bell-labs.
To Subscribe: iptel-request@lists.research.bell-labs.
Archive: http://www.bell-labs.com/mailing-lists/
Description of Working Group
Before Internet telephony can become a widely deployed service,
number of protocols must be deployed. These include signaling
capabilities exchange, but also include a number of "peripheral
protocols for providing related services
The primary purpose of this working group is to develop two
supportive protocols and a frameword document. They are
1. Call Processing Syntax. When a call is setup between
endpoints, the signaling will generally pass through several
(such as an H.323 gatekeeper) which are responsible for forwarding
redirecting, or proxying the signaling messages. For example, a
may make a call to j.doe@bigcompany.com. The signaling message
initiate the call will arrive at some server at bigcompany.
server can inform the caller that the callee is busy, forward
call initiation request to another server closer to the user, or
the call completely (among other possibilities). It is very
to allow the callee to provide input to this process, guiding
server in its decision on how to act. This can enable a wide
of advanced personal mobility and call agent services
Bradner Best Current Practice [Page 24]
RFC 2418 Working Group Guidelines September 1998
Such preferences can be expressed in a call processing syntax,
can be authored by the user (or generated automatically by
tool), and then uploaded to the server. The group will develop
syntax, and specify means of securely transporting and extending it
The result will be a single standards track RFC
2. In addition, the group will write a service model document,
describes the services that are enabled by the call
syntax, and discusses how the syntax can be used. This document
result in a single RFC
3. Gateway Attribute Distribution Protocol. When making a
between an IP host and a PSTN user, a telephony gateway must be used
The selection of such gateways can be based on many criteria
including client expressed preferences, service provider preferences
and availability of gateways, in addition to destination
number. Since gateways outside of the hosts' administrative
might be used, a protocol is required to allow gateways in
domains to distribute their attributes (such as PSTN connectivity
supported codecs, etc.) to entities in other domains which must
a selection of a gateway. The protocol must allow for scalable
bandwidth efficient, and very secure transmission of
attributes. The group will investigate and design a protocol for
purpose, generate an Internet Draft, and advance it to RFC
appropriate
Goals and Milestones
May 98 Issue first Internet-Draft on service
Jul 98 Submit framework ID to IESG for publication as an RFC
Aug 98 Issue first Internet-Draft on Call Processing
Oct 98 Submit Call processing syntax to IESG for
as a Proposed Standard
Dec 98 Achieve consensus on basics of gateway
distribution
Jan 99 Submit Gateway Attribute Distribution protocol to
for consideration as a RFC (info, exp, stds track
Bradner Best Current Practice [Page 25]
RFC 2418 Working Group Guidelines September 1998
Full Copyright
Copyright (C) The Internet Society (1998). All Rights Reserved
This document and translations of it may be copied and furnished
others, and derivative works that comment on or otherwise explain
or assist in its implementation may be prepared, copied,
and distributed, in whole or in part, without restriction of
kind, provided that the above copyright notice and this paragraph
included on all such copies and derivative works. However,
document itself may not be modified in any way, such as by
the copyright notice or references to the Internet Society or
Internet organizations, except as needed for the purpose
developing Internet standards in which case the procedures
copyrights defined in the Internet Standards process must
followed, or as required to translate it into languages other
English
The limited permissions granted above are perpetual and will not
revoked by the Internet Society or its successors or assigns
This document and the information contained herein is provided on
"AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET
TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED,
BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES
MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE
Bradner Best Current Practice [Page 26]
if you see any problems within the linking, don't worry be happy,
this is version 0.1 of the Relevance System and you gotta expect some crappy subroutines sometimes,
just be content we did not write this in Java, which would have made this "bigger and better" HAHAHHA.
RFC documents can be found at I.E.T.F.
Relevance System Copyright © 2002 Spectrum WorldResearch
other technical nosh by ServerMasters Corporation
collaboration of BobX
