Network Working Group Internet Engineering Steering Group IESG
INTERNET-DRAFT Erik Huizer
SURFnet bv
December 1992
D. Crocker
Silicon Graphics, Inc.
June 1993
IETF Working Group
Guidelines and Procedures
Status of this Memo,
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. Internet Drafts may be updated, replaced, or obsoleted by
other documents at any time. It is not appropriate to use
Internet Drafts as reference material or to cite them other than
as a ``working draft'' or ``work in progress.''
Please check the 1id-abstracts.txt listing contained in the
internet-drafts Shadow Directories on nic.ddn.mil, nnsc.nsf.net,
nic.nordu.net, ftp.nisc.sri.com, or munnari.oz.au to learn the
current status of any Internet Draft.
When finalized the draft document will be submitted to the RFC
editor as an informational document. Distribution of this memo is
unlimited. Please send comments to the author.
Abstract
ABSTRACT
The Internet Engineering Task Force (IETF) has the primary
responsibility for the development developing and review of potential specifications
intended as Internet
Standards from all sources. The Standards. IETF is activities are organized
into Working Groups (WG). This document describes the guidelines
and procedures for formation and operation of an IETF Working Group.
Groups. It describes the formal relationship between a WG and the
Internet Engineering and Steering Group (IESG). The basic duties
of a WG chair and an IESG Area Director are defined.
Contents
Introduction
Acknowledgements
WG formation
Charter
Review
IESG 1
The expiration date of charter
Announcement this Internet Draft is December 1993.
TABLE OF CONTENTS
1. INTRODUCTION
1.1. IETF Approach to Standardization
1.2. Acknowledgments
2. GROUP PROCESS
2.1. Working Group Purpose & Scope
2.2. Wg Policies And Procedures
2.3. Birds of a Of A Feather sessions (BOFs) (Bof)
2.4. WG meetings
WG policies and procedures
Document procedures
Internet-Drafts
RFCs
Progression of documents Formation
Criteria for Formation
Charter
Charter Review of documents & Approval
2.5. Working Group Sessions
2.6. Termination of a Of A WG
3. MANAGEMENT
3.1. WG chair duties
AD duties
Security Considerations
Authors address
References
Appendix: Chair Duties
3.2. Area Director Duties
3.3. Contention And Appeals Overview
4. DOCUMENT PROCEDURES
4.1. Internet Drafts
4.2. Request For Comments (RFC)
4.3. Submission Of Documents
4.4. Review Of Documents
5. SECURITY CONSIDERATIONS
6. REFERENCES
7. AUTHORS ADDRESS
APPENDIX: Sample Working Group charter
Introduction
-----------
1. INTRODUCTION
This document defines guidelines and procedures for Internet
Engineering Task Force Working Groups. The Internet, a loosely-organized loosely-
organized international collaboration of autonomous,
interconnected networks, supports host-to-host communication
through voluntary adherence to open protocols and procedures
IESG 2
defined by Internet Standards, a collection of which are commonly
known as "the TCP/IP protocol suite". The Internet Standards
Process is defined in RFC 1310bis [1]. The primary
responsibility for the development and review of potential
Internet Standards from all sources is delegated conducted by the Internet
Society [2] to the Internet
Engineering Task Force (IETF). The goals, structures and
procedures of the IETF can be found in it's charter [3].
The Internet Engineering Task Force is chaired by the IETF Chair and
managed by its Internet Engineering Steering Group (IESG). The IETF is a large large, open community of network designers,
operators, vendors, and researchers concerned with the Internet
and the Internet protocol
suite. It technology used on it. The IETF is organized around a set of technical areas, each managed by
one or two technical Area Directors (AD). In addition to the its
Internet Engineering Steering Group (IESG) whose membership
includes an IETF
Chairman, the Area Directors make up the IESG membership. Each Area
Director has primary responsibility Chair, responsible for one area oversight of Internet
engineering activity, general IETF
operations, and hence Area Directors, each of whom is responsible for a subset
set of the IETF Working
Groups. activities and working groups. At present there are eight
10 areas, though this the number may change and purview of Areas changes over
time:
<<ARE THESE THESE EXACT NAMES OF THE AREAS??>>
1) Applications
2) User Services
2) Applications
3) Service Applications
4) Transport Services
5) Internet Services
4)
6) Routing
5)
7) Network Management
6)
8) Operational requirements
7) Requirements
9) Security
8) Transport and Services
Each Area has
10) Standards & Processes
Most Areas have an advisory group, called the Area Directorate Directorate,
to support assist the Area Directors a.o. Directors, e.g., with the review of documents
specifications produced in the area. The Area Directorate is
formed by the Area Director(s) from senior members of Working Groups
(WG) within the area.
community represented by the Area. A small IETF Secretariat
provides staff and administrative support for the operation of
the IETF.
The primary work of the IETF is performed by subcommittees known
as Working Groups. There are currently more than 60 of these.
Working Groups tend to have a narrow focus and a lifetime bounded
by completion of a specific task, although there are exceptions.
Membership in the IETF is established simply by the fact of
participation in its activities. This participation may be by on-
line contribution, attendance at face-to-face sessions, or both.
No formal rules govern this membership. Any member of the
Internet community with the time and interest is urged to attend IETF meetings and to
IESG 3
participate actively in one or
more IETF Working Groups. 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 words like: "shall", "will", "must" and "is required" where
it describes steps in the process that are essential. Words like
"suggested", "should" and "may" are used where guidelines are
described that are not essential, but are strongly recommended to
help smooth WG operation.
1.1. IETF Approach to Standardization
The reader is encouraged to read the The IETF Charter [3] and the RFC on
the The
Internet Standards process Process [1]. Familiarity with these documents
is essential for an a complete understanding of the philosophy,
procedures and guidelines described in this document.
Acknowledgements The goals
of the process are summarized in [1]:
In general, an Internet Standard is a specification that is
stable and well-understood, is technically competent, has
multiple, independent, and interoperable implementations
with operational experience, enjoys significant public
support, and is recognizably useful in some or all parts of
the Internet.
...
In outline, the process of creating an Internet Standard is
straightforward: a specification undergoes a period of
development and several iterations of review by the Internet
community and perhaps revision based upon experience, is
adopted as a Standard by the appropriate body (see below),
and is published.
In practice, the process is somewhat more complicated, due
to (1) the number and type of possible sources for
specifications; (2) the need to prepare and revise a
specification in a manner that preserves the interests of
all of the affected parties; (3) the importance of
establishing widespread community agreement on its technical
IESG 4
content; and (4) the difficulty of evaluating the utility of
a particular specification for the Internet community.
...
These procedures are explicitly aimed at developing and
adopting generally-accepted practices. Thus, a candidate
for Internet standardization is implemented and tested for
correct operation and interoperability by multiple,
independent parties, and utilized in increasingly demanding
environments, before it can be adopted as an Internet
Standard.
The IETF standardization process has been marked by informality.
As the community of participation has grown it has become
necessary to document procedures, while continuing to avoid
unnecessary bureaucracy. This goals of this balancing act are
summarized in [1] as:
The procedures that are described here provide a great deal
of flexibility to adapt to the wide variety of circumstances
that occur in the Internet standardization process.
Experience has shown this flexibility to be vital in
achieving the following goals for Internet standardization:
* high quality,
* prior implementation and testing,
* openness and fairness, and
* timeliness.
1.2. Acknowledgments
Much of this document is largely due to the copy-and-paste function of a
wordprocessor.Several
word processor. Several passages have been taken from the
documents cited in the reference section. The POISED WG provided
discussion and comments. Three people deserve special mention, as
especially large chunks of their documents have been integrated
into this one: Vint Cerf [8] from whom I we borrowed the
description of the IETF. And Greg Vaudreuil and Steve Coya [9]
who provided several paragraphs and
detailed feedback. paragraphs. All the errors you'll find are
probably mine. ours.
IESG 5
2. GROUP PROCESS
2.1. Working Group formation
---------------------- Purpose & Scope
IETF Working Groups working groups (WGs) are the primary mechanism for the
development of IETF protocols, standards, specifications and guidelines, many of which
are intended as standards or recommendations. A Working working Group may
be established under at the direction instigation of an Area Director (AD), or
its creation may be initiated by an individual, individual or group of
individuals. Anyone interested in creating an IETF Working Group working group
must consult with obtain the advise and consent of the appropriate IETF Area
Director under whose direction the Working
Group working group would fall, to confirm that creating a Working Group is
appropriate. fall.
A Working Group working group is typically created to address a specific
problem or produce a specific deliverable (document, RFC, (guideline, standard,
etc.), and is expected to be short lived short-lived in nature. Upon
completion of its goals and achievement of its objectives, the Working Group
working group as a unit is terminated. Alternatively, at the
discretion of the Area Director and the Working Group working group chair and
membership, the objectives or assignment of the Working Group working group may
be extended by enhancing or adding to modifying the Working
Group's working group's
statement of objectives
2.2. Wg Policies And Procedures
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 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.
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 no 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. Some of these
IESG 6
are listed here, with actual choices typically determined by the
working group members and the chair.
1. For face-to-face sessions, the chair should publish a
draft WG-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. The documents should be publicly
available (preferably as Internet drafts; see next
section) with information needed to access them.
2. All relevant documents for a session (including the
final agenda) should be published and available at least
two weeks before the session starts.
3. It is strongly suggested that the WG chair makes sure
that an anonymous FTP directory be available for the
upcoming session. All relevant documents (including the
final WG-agenda and the minutes of the last session)
should be placed in this directory. This has the
advantage that all participants can ftp all files in
this directory and thus make sure they have all relevant
documents. Also, it will be helpful to provide
electronic mail- based retrieval for those documents.
4. While open discussion and contribution is essential to
working group success, the chair is responsible for
ensuring forward progress. As appropriate it may be
acceptable to have restricted participation (not
attendance!) at IETF working group sessions for the
purpose of achieving progress. The working group chair
usually has the authority to refuse to grant the floor
to any individual who is unprepared or otherwise
covering inappropriate material.
5. The detailed specification effort within a working group
may be assigned to self-selecting sub-groups, called
Design Teams. They may hold closed sessions for
conducting 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
IESG 7
members and the DT must be responsive to the direction
of the working group's "rough" consensus.
6. Many working group participants hold that mailing list
discussion is the best place to consider and resolve
issues and make decisions, while others maintain that
such work should be accomplished primarily at IETF
meetings. 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
wide base of interested persons than is attendance at
IETF meetings, due to the time and expense required to
attend.
7. 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.
8. Consensus can be determined by balloting, humming, or
any other means the WG agrees on (by rough consensus, of
course). IETF consensus does not require that all
members 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.)
9. It is occasionally appropriate to re-visit 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 E-mail in the minutes of
the next 'live' session, and to briefly summarise
decision making history in the final documents the WG
produces.
10. To facilitate making forward progress, a working
group chair may wish to direct a discussion to reject
the input from a member, based upon the following
criteria:
(old) The input pertains to a topic that already
IESG 8
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;
or
(not yet) The input pertains to a topic that the
working group has not yet opened for
discussion.
2.3. Birds Of A Feather (Bof)
For an individual, or small group of individuals, it is often not
clear if the issue(s) at hand merit the formation of a WG. To
alleviate this problem 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.
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 has to
be filed with the relevant Area Director. 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.
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;
- There was not enough interest in the subject to warrant
the formation of a WG.
There is an increasing demand for BOF sessions at IETF meetings.
Therefore the following rules apply for BOFs:
1. All BOFs wishing to meet during an IETF meeting must
have the approval of the appropriate Area Director. The
Secretariat will NOT schedule or allocate time slots
without the explicit approval of the Area Director.
IESG 9
2. The purpose of a BOF is to conduct a single, brief
discussion or to ascertain interest and establish goals
for a working group. All BOF organizers are required to
submit a brief written report of what transpired during
the BOF session together with a roster of attendees to
the IETF Secretariat for inclusion in the proceedings.
3. A BOF may be held only once (ONE slot at one IETF
Plenary meeting).
4. Under unusual circumstances an Area Director can, at
his/her discretion, allow a BOF to meet for a second
time. Typically (though not a requirement) this is to
develop a charter to be submitted to the IESG.
5. BOFs are not permitted to meet three times.
6. Non-IETF groups wishing to participate in IETF meetings
may hold a BOF for single-event discussion, or may
pursue creation of normal IETF working groups for on-
going interactions and discussions. The rules governing
such BOFs are the same as for all other IETF BOFs and
working groups.
7. When necessary, IETF WGs will be given priority for
meeting space over IETF BOFs.
2.4. WG Formation
Criteria for Formation
When determining if creating a Working Group working group is appropriate, the
Area Director will consider several issues:
o
- Are the issues that the Working Group working group plans to address important?
o Does
clear and relevant for the work that Internet community?
- Are the WG intends to undertake fit in with goals specific and reasonably achievable, and
achievable within the
Architecture as understood time frame specified by the IESG/IAB.
o Does
milestones?
- Do the Working Group's working group's activities overlap with those of
another
Working Group? working group? If so, it may still be
appropriate to create another
Working Group, working group, but this
question must be considered carefully by the Area Director
IESG 10
Directors as subdividing efforts often dilutes the
available technical expertise.
o
- Are there several people clearly interested in the Working Group's
working group's topic and willing to expend the effort
to produce a the desired result (such as
an RFC)? (e.g., a protocol
specification)? Working Groups groups require considerable manpower:
effort: a chairman chair is needed to run meetings, sessions, an editor to edit authors' submissions,
maintain the working document(s), and
authors contributors to actually
write the text. IETF experience suggests that these
roles typically cannot all be handled by one person, person;
four or five active members are typically required. If
the necessary manpower staffing is lacking, the person interested
in creating the Working Group working group might consider actually
writing the RFC specification alone and submitting it for
review, rather than attempting to create a Working Group. working
group.
- Does a base of interested consumers appear to exist for
the planned work? Consumer interest can be measured by
participation of end-users within the IETF process, as
well as less direct indications.
Considering the above criterion, criteria, the Area Director will decide
whether to pursue the formation of the group through the
chartering process.
Charter
The formation of a Working Group working group requires an approved statement of
direction or objectives along with establishing a charter which is
negotiated between a prospective working group chair and the
relevant Area Director and which:
1) Lists relevant administrative aspects of the Working Group which involves working
group, such as identifying the WG Chair or co-Chairs,
the WG secretary (which can (who may also be the WG chair), and the
creation
addresses of a the mailing list. This information is included in list and any archive.
2) Specifies the Working
Group Charter.
The content direction or objectives of the charter document is negotiated between a prospective
Working Group chair working
group and describes the relevant Area Director. The work statement
must explain the general purpose of approach that will be taken to
achieve the group, define its technical
scope, enumerate goals; and
3) Enumerates a set of goals and milestones together with
time frames for their completion, completion.
3) Lists the milestones and document various administrative
points. dates for intermediate goals,
and
IESG 11
When both the prospective Working Group chair and the Area Director are
satisfied with the charter text, it becomes the basis for forming
a Working Group. working group. The charter document may be similarly
renegotiated or modified at any time during the course of the Working
Group's
working group's effort to reflect the changing goals of the
group.
Each charter consists of five sections. These sections include
information about the Working Group (the name, the chairmen,
objectives, goals and milestones, and the mailing lists. The goals and
milestones
Charters are part of the IETF tracking system, and are designed to
allow a degree of project management reviewed and support. approved by the IESG. They may change be re
negotiated periodically to reflect the current status or status,
organization or goals of the
Working Group. working group. Hence, a working
group charter is a contract between the IETF and the working
group which is committing to meeting explicit milestones and
delivering concrete "products".
Specifically, each charter consists of five sections:
1. Working Group Name:
A Working Group working group name should be reasonable reasonably descriptive or
identifiable. Additionally, the group needs to shall define an
acronym (maximum 8 character printable ASCII acronym characters) to reference
the group in the IETF directories, mailing lists, and
general documents.
2. Working Group Chair(s):
The Working Group working group may have one or two chair(s) to perform
the administrative functions of the group. It The chair(s)
shall be reachable by Email.
3. Area and Area Director(s)
The name of the IETF area with which the working group is strongly suggested that
these individuals have Internet
affiliated and the name and electronic mail addresses.
3. address of the
associated Area Director.
4. Working Group Description:
In one to two paragraphs, the focus and intent of the group should
shall be set forth. 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 basis, goal(s) and approach(es) planned
for the working group. This paragraph will frequently be
used as an overview of the working group's effort.
Recognizing the importance of security and network
management in the Internet Architecture, this description of
IESG 12
the work of the group must specifically address the impact in terms
of security and
management.
4. the work on these two issues.
5. Goals and Milestones:
The Working Group should, after the first meeting, be able to working group charter must establish a timetable for
work. While this may change be re-negotiated over time, the list
of milestones and dates facilitate facilitates the Area Director's
tracking of Working Group working group progress and status, and it is
indispensable to potential participants to be able to identify identifying the
critical moments for input. Milestones should shall consist of
deliverables that can be qualified as such, such; e.g. 'Internet-draft 'Internet-
draft finished' is fine, but 'discuss via E-mail' is not.
This milestone list is expected to be updated periodically.
Updated milestones should be submitted along are re-negotiated with meeting minutes the Area Director
and the IESG, as needed and then are submitted to the IETF
Secretariat
(iesg-secretary@cnri.reston.va.us).
5.
ietfadm@cnri.reston.va.us
6. Mailing Lists:
Most of the work of an IETF Working Group working group is conducted on
Internet
Mail exploder mailing lists. It is required that an IETF Working Group working
group have a general discussion list. An individual needs to
be designated as the list service postmaster, usually
through the a list-request alias mechanism. A message archive
should be maintained in a public place which can be accessed
via FTP. The address
IETF-archive@cnri.reston.va.us
should
shall be included on the mailing list.
Note: Retrieval from the
archive via electronic mail requests also is recommended.
NOTE: It is strongly suggested that the mailing list be on an a
host directly connected to the IP host, Internet to facilitate use of
the SMTP expansion command (EXPN) and to allow access via FTP to
the mail archives. If this is not possible, the message archive
and membership of the list must be made available to those who make such a
request it by sending a message to the list-request alias. The
list maintainer or archiver need not be the Working Group
chairman working group chair
or secretary, but may be a member of the Working Group working group itself.
An example of a WG charter can be found is in appendix A.
IESG 13
Charter Review & Approval
Once the Area Director has approved the Working Group charter,
the charter is submitted to the Internet Engineering and Steering
Group and Internet Architecture Board for review and approval.
The IESG will primarily consider if whether :
- the WG has no overlap with WGs in other areas;
- there There is sufficient expertise in the IETF to review produce the
desired results of the WG;
- There is a good indication that the intended user
population wants this work;
- The risks and urgency of the work are specified, to
determine the level of attention required, and
- The extent to which the work will affect an installed
base of users is taken into account.
- The WG has overlap with WGs in other areas;
- Related work by other groups will be affected or will be
sufficiently coordinated with the work of this group
The Internet Architecture Board (IAB) will review the charter of
the proposed WG to see whether determine the relationship of the proposed
work is relevant to the overall architecture of the Internet Protocol Suite.
The approved charter is submitted to the IESG secretary (currently at
CNRI) Secretary who
records and enters the information into the IETF tracking
database and returns the charter in a form formatted by the
database.
Using this reformatted charter, the Working Group The working group is announced by the
Birds of a Feather (BOF)
For an individual, or small group of individuals, it is often not clear
if the issue(s) at hand merit the formation of a WG. To alleviate this
problem IESG Secretary
to the IETF offers the possibility of a Birds of a Feather (BOF)
session.
A BOF is a session at an IETF where a brainstorm type of discussion is
held on a subject proposed mailing list, by the chair(s) of the BOF. Any individual
(or IESG secretary.
2.5. Working Group Sessions
All working group of individuals) can request permission to hold a BOF on a
certain subject. The request has to be filed with the relevant Area
Director. 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.
Usually the outcome of a BOF will be one of the following:
- There was enough interest in the subject to warrant the formation of
a WG;
- The discussion came to a fruitful conclusion, the results will actions shall be
written down public, and published as a RFC. There is no need to establish
a WG;
- There was not enough interest in the subject to warrant the
formation wide participation
encouraged. A working group will conduct much of a WG.
There is an increasing demand for BOF sessions at IETF meetings.
Therefore as a rule it is not allowed to have multiple BOF sessions on
the same subject at IETF meetings.
Working Group Meetings
---------------------
The Working Group is expected to its business
via electronic mail distribution lists, but may meet periodically
to discuss and review task status and progress, and to direct
future activities. It is
expected, common, but not required that every Working Group a working
group will meet at the trimester IETF plenary sessions. meetings.
Additionally, interim meetings are
encouraged by sessions may be scheduled for telephone
conference, video teleconference, or by actual face to face meetings. Meetings should
sessions.
As noted in the earlier section on Working Group Policies and
IESG 14
Procedures, 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 consensus and
ensuring consensus among a core of the working group members.
Sessions must be publicized as widely as
possible, by announcing their and well in advance and must
take place at a convenient location. The time and location on the Working Group
mailing list etc. When a meeting is held outside of an IETF session,
the WG meeting should a
session must be announced to on the working group mailing list,
through any other mechanisms that are appropriate, and must
include the IETF mailing list too. list:
ietf@cnri.reston.va.us
All Working Group working group sessions (also the ones (including those held outside of the
IETF
sessions) should meetings) shall be reported by making minutes available.
These minutes should include the agenda for the meeting, session, an
account of the discussion including any decisions made, and a
list of attendees. The Working
Group working group chair is responsible for
insuring that meeting session minutes are written and distributed, though
the actual task may be performed by the
Working Group working group secretary
or someone designated by the Working Group 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.
If a WG wants to meet needs a session at an IETF meeting, it has to apply for a
timeslot. In order to be efficient with allocation of sparse time-
slots, and in order to coordinate as well as possible WGs that require
more or less the same subset of experts (such that these experts do not
waste time due to gaps between meetings), the WG chair needs to must apply
for a meeting at an IETF to the secretariat, one or more 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 meeting session at an IETF meeting needs to shall be made
to the IETF secretariat, and it needs to contain:
- the amount of time requested;
- the rough outline of the agenda that is expected to be covered;
- the estimated number of people that will attend the WG meeting.
The secretariat will form a draft agenda and distribute it among the
wg-chairs for approval. secretariat. Alternatively some Area Directors may
want to coordinate WG meetings sessions in their area and request that timeslots
time slots be coordinated through them. After receiving all
requests for timeslots time slots by WGs in the area, the Area Director(s)
form a draft agenda session-agenda for their area, which will be send is then sent to
the WG chairs of the area. After approval it will be send sent to the
IETF secretariat.
An application must contain:
- The secretariat allots amount of time requested;
- The rough outline of the WG-agenda that is expected to
be covered;
IESG 15
- The estimated number of people that will attend the timeslots WG
session;
- Related wgs that must not be scheduled for the same time
slot(s).
The Secretariat allots time slots on the basis of the session-
agenda made by the Area Director(s). director(s). If the proposed session-
agenda for an area does not fit into the IETF meeting agenda, meeting-agenda, the
IETF secretariat will adjust it to fit, after consulting the Area Director(s)
director(s) and the relevant chairs.
WG policies and procedures
-------------------------
All Working Group actions should be public, and wide participation
encouraged. Announcements of meeting dates and time must be sent to the
Working Group mailing list and to mdavies@cnri.reston.va.us a
reasonable time before the meeting.
All Working Groups are autonomous, and each may have their own policies
and procedures with respect to meeting participation, reaching closure,
etc. Generally, acceptance or agreement is achieved via Working Group
consensus, though some Working Groups may decide that a simple
majority, significant majority (two thirds) or unanimous agreement is
required. A number of procedural questions and issues have risen over
time, and it is the function of the Working Group chair to manage this
process, keeping in mind that the overall purpose of the group is to
make progress towards realizing the Working Group's goals and
objectives.
There are no 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. Some of these "topics" are
listed here. Note that the choice of options is typically determined by
the Working Group members and the chairman.
1. The chair is encouraged to publish Secretariat will then
form a draft agenda well in advance of
the actual meeting. The agenda needs to contain at least:
- items for discussion;
- estimated time necessary per item;
- clear indication of what documents the participants will need to
read before the meeting in order to be well prepared. The
documents should be publicly available (preferably as Internet-
drafts, see next section) session-agenda and distribute it among the "where and how to get them"
should be indicated.
2. All relevant documents wg-chairs
for a meeting (including the final agenda)
should be published and available at least two weeks before the
meeting starts.
3. It is strongly suggested that the approval.
2.6. Termination Of A WG chair creates an anonymous FTP
directory specially for the upcoming meeting. All relevant documents
(including the final agenda and the minutes of the last meeting)
should be placed in this directory. This has the advantage that all
participants can just ftp all files in this directory and thus make
sure they have all relevant documents.
4. After a period of open meetings, the
Working Group chair may hold
executive (closed) meetings of the Working Group consisting of the
authors of a particular document and any serious reviewers. This is
often necessary groups are typically chartered to make forward progress preparing accomplish a final document.
All work conducted in executive session must be made available for
5. It is acceptable to have restricted participation (not attendance!)
at IETF Working Group meetings for the purpose of achieving
progress. The Working Group chairman usually has the authority to
refuse to grant the floor to any unprepared individual.
6. Many Working Group participants hold that mailing list discussion is
the place to resolve issues and make decisions, while others
maintain specific
task. After that such should be accomplished only at IETF meetings.
Resolution and acceptance within the Working Group task is resolved by
the Working Group.
7. Consensus can be determined by balloting, humming, or any other
means complete, the WG group will agree on (by consensus of course).
8. Repeated discussions on the same issues over E-mail can be avoided disbanded.
However, if the chair makes sure that after a discussion has come to a
conclusion, the main arguments in the discussion (and the outcome)
are summarized and archived. It is also good practice to note
important decisions/consensus reached by E-mail in the minutes of
the next 'live' meeting.
Document procedures
-------------------
Internet Drafts
The IETF provides the Internet Drafts directories are provided to the
Working Groups as a resource to post and disseminate early copies of
any and all documents of the Working Group. This common repository is
available to all interested persons to facilitate wide review and
comment. It is encouraged that draft documents be posted as soon as
they become reasonably stable.
It is stressed here that Internet Drafts are drafts and have no
official status whatsoever.
Request For Comments (RFC)
The work of an IETF Working Group usually results in the publication of
one or more Request For Comments Documents (RFCs) [4]. This series of
documents are the journal of record for the internet community. A
document can be written by an individual in the Working Group or by the
group as a whole with a designated editor. The designated author need
not be the group chair(s).
Note: The reader is reminded that all Internet Standards are published
as RFCs, but NOT all RFCs specify standards!
For a description on the various subseries of RFCs the reader is
referred to [1,5,6,7].
Submission of documents
When a WG decides that a working document is ready for progression to
RFC, the following has to be done:
- The relevant document as approved by the WG has to be results in the
Internet-Drafts directory;
- The relevant document has to be formatted according to RFC-rules
(see RFC-1111 [4]).
- The WG chair sends an E-mail, containing the reference to the
document, and the request that it be progressed as an
(Informational, experimental, prototype or proposed STD) RFC to the
Area Director(s), with a cc: to the IESG Secretary.
The Area Director(s) will acknowledge receipt of the E-mail. From then
onwards the progressing of the document is the responsibility of the
IESG.
Review of documents
In case the submission is intended for Informational only no review is
necessary. However if Proposed Standard, the
WG or the RFC editor thinks that a review is
appropriate the AD can be asked to provide a review. In case of
submission as an Experimental, Prototype or Standards RFC, the document will always be reviewed by the IESG. The review can either be done by
the AD and other IESG members or by independent (i.e. not having been
part of go dormant rather than disband (i.e., the WG in question) reviewers from the Area Directorate.
Before making a final decision on a document, the IESG 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.
The review will lead to one of three possible conclusions:
1- The document is accepted as is; This fact will be announced by the
IESG to no
longer conduct formal activities, but the IETF mailing list and to the RFC Editor. Publication is
then further handled between the RFC editor and the author(s).
2- One or more changes regarding content are suggested to the
author(s)/WG. Once the author(s)/WG has made these changes or has
argued
membership will remain available to review the satisfaction of the reviewers why the change(s) is/are
not necessary, the document will be accepted for publication work as
under point 1 above.
3- The document is rejected; This will need strong and good
argumentation from the reviewers. The whole process is structured
such that this situation is not likely it moves
to arise for documents coming
from a Working Group. After all the intents of the document would
already have been described in the WG charter, Draft Standard and this has already
been reviewed Standard status).
If, at the outstart of the WG.
If any individual or group of individuals feels that the review
treatment has been unfair, there is the possibility to make a
procedural complaint. The mechanism for procedural complaints is
described in the Charter of the IETF [3].
Termination of a WG
-------------------
Working Groups are typically chartered to accomplish a specific task.
After that task is complete, the group will be disbanded. If after a
meeting a few times, some point, it becomes evident that the group a Working Group is
unable to complete the work outlined in the charter, the group,
in consultation with its Area Director can either either:
1) recharter Recharter to refocus on a smaller task,
2) choose Choose new chair(s), or
3) disband.
In those situations where Disband.
When the Working Group working group chairperson and the Area Director disagree
about the steps required to refocus the group or the need to
disband the group, the IESG will make a determination with input
from the Area Director and the Working Group working group chair(s). Major
changes will need a review from the IAB.
IESG 16
3. MANAGEMENT
3.1. WG chair duties
-------------- Chair Duties
The Working Group chair(s) have wide discretion in the conduct of
business. The WG chair has to make sure that the WG operates in a
reasonably efficient and effective way towards reaching the goals
and results described in the WG charter. This very general
description encompasses at the very least the following detailed
tasks:
- Moderate the WG distribution list; list
The chair makes sure should attempt to ensure that the discussions on
this list are relevant and that they converge. The chair makes
should make sure that discussions on the list are summarized
and that the outcome is well documented (to avoid
repeats).
repetition). The chair also may choose to schedule
organized on-line "session" with agenda and deliverables.
- Organize, prepare and chair face-to-face meetings; sessions
The chair plans should plan and announces the meeting announce sessions well in advance (see advance.
(See section on WG meetings Sessions for exact procedures). procedures.) The
chair makes should make sure that relevant documents and the final agenda
WG-agenda are ready at least 2 weeks in advance of the meeting. The Chair makes sure minutes are
taken, and that an attendance list is circulated.
session. It is strongly suggested that the WG chair creates
an anonymous FTP directory
specially for the upcoming meeting. working group's
documents. All relevant documents should be placed in this
directory.
- Communicate results of meeting; session
The chair makes sure must ensure that minutes of the meeting session are taken. taken
and that an attendance list is circulated. After screening
the minutes the final version will be send sent to the Area
Director(s) and the IETF secretariat, in time for
publication in the IETF proceedings. The WG chair provides should
provide the Area Directors with a very short report (preferably via E-mail) (via E-
mail) on the meeting session directly after the meeting took it takes place. These
reports will be used for the Area Report as presented in the
proceedings of each IETF meeting.
- Distribute the work; work
Of course each WG will contain a lot of participants that have members who may not be able to
(or want to) do any work at all. Most of the time the bulk
IESG 17
of the work is done by a few experts. dedicated members. It is the tasks
task of the chair to motivate enough experts to allow for a
fair distribution of the workload.
- Progress documents. documents
The chair will make sure that authors of WG documents
incorporate changes as discussed by the WG. Once a document
is approved by the WG the chair reports to the Area
Director(s) and the IESG secretary. The chair indicates (per
E-mail) which document has been approved, and asks the IESG
to review it for publication as an RFC (specify
experimental, proposed STD Experimental, Proposed
STD, etc.). The Area Director will acknowledge
the receipt of
the E-mail, and from then on the action is on the responsibility of
the IESG. See the section on review Review of documents Documents for
possible further involvement of the chair in document progressing. progressing
documents.
3.2. Area Director duties
------------------- Duties
The Area Directors are responsible for a ensuring that working
groups in their area produce coherent, coordinated and
architecturally consistent output from the Working Groups in
their area as a contribution to the overall results of the IETF.
This very general description encompasses at the very least the following
detailed tasks related to the Working Groups:
- Coordination of WGs; WGs
The Area Director(s) director(s) coordinate the work done by the various
WGs within (and sometimes even outside) the relevant Area.
The Director(s) try to coordinate meetings sessions in such a way
that experts can attend the relevant meetings sessions with a minimum
of overlap and gaps between meetings. sessions. (See section on WG meetings
sessions for details)
- Reporting; Reporting
The Area Director(s) report on to the IETF on progress in the Area to the IETF.
Area.
- Reviewing; Reviewing
The Area Directors may appoint independent reviewers for prior
to document
reviewing. approval. The Area Director(s) track the
IESG 18
progress of documents from the Area through the IESG review
process, and report back on this to the WG Chair(s).
- Progress tracking; tracking
The Area Directors track and manage the progress of the
various WGs with the aid of a regular status report
generated by the IESG secretary. The Area Directors directors forward
this regular status reports on documents and milestones made
by the IESG Secretary to the WG chairs. This in turn helps
the chairs to manage their WGs.
- Area Directorate; Directorate
The Area Director Director(s) chairs the Area Directorate. He is They are
responsible for regular meetings sessions of the directorate.
Security Considerations
----------------------
3.3. Contention And Appeals Overview
Formal procedures for requesting review and conducting appeals
are documented in The Internet Standards Process [1]. A brief
summary is provided, here.
In fact, the IETF approach to reviews and appeals is quite
simple: When an IETF member feels that matters have not been
conducted properly, they should state their concern to a member
of IETF management. In other words, the process relies upon
those who have concerns raising them. If the result is not
satisfactory, there are several levels of appeal available, to
ensure that review is possible by a number of people uninvolved
in the matter in question.
Reviews and appeals step through three levels:
- Area
This includes the Working Group review and Area Director
review. No appeal should come to the IESG before the Area
Director has reviewed the point of contention.
- IESG
If the offended party is not happy with the Area-level
review, then they may bring them to the IESG chair and the
Area Director for Standards Management. The IESG chair has to
be in this loop on this. The IESG chair and the Standards
IESG 19
Area Director will bring the issue before the IESG for
discussion and take the resolution back to the parties.
- IAB
If the offended party is still not happy with the outcome at
the IESG level, then they may take their concern to the IAB.
Concerns entail either a disagreement with technical decisions by
the working group or with the process by which working group
business has been conducted. Technical disagreements may be
about specific details or about basic approach. When an issue
pertains to preference, it should be resolved within the working
group. When a matter pertains to the technical adequacy of a
decision, review is encouraged whenever the perceived deficiency
is noted. For matters having to do with preference, working
group rough consensus will dominate.
When a matter pertains to working group process, it is important
that those with a concern be clear about the manner in which the
process was not open or fair and that they be willing to discuss
the issue openly and directly. In turn, the IETF management will
make every effort to understand how the process was conducted,
what deficiencies were present (if any) and how the matter should
be corrected. The IETF functions on the good will and mutual
respect of its members; continued success requires continued
attention to working group process.
4. DOCUMENT PROCEDURES
4.1. Internet Drafts
The Internet Drafts directory is provided to working groups as a
resource for posting and disseminating early 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 status whatsoever. They may, eventually,
turn into a standards-track document or they may sink from sight.
IESG 20
4.2. Request For Comments (RFC)
The work of an IETF working group usually results in publication
of one or more documents, published as a Request For Comments
(RFCs) [4]. This series is the journal of 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 IETF. In other words, the reader is reminded
that all Internet Standards are published as RFCs, but NOT all
RFCs specify standards!
For a description on the various subseries of RFCs the reader is
referred to [1,5,6,7].
4.3. Submission Of Documents
When a WG decides that a working document is ready for
publication, the following must be done:
- The relevant document as approved by the WG must be in
the Internet-Drafts directory;
- The relevant document must be formatted according to RFC-
rules (see RFC-1111 [4]).
- The WG chair sends email to the relevant Area
Director(s), with a copy to the IESG Secretary. The
mail should contain the reference to the document, and
the request that it be progressed as an Informational,
Experimental, Prototype or standards-track (Proposed,
Draft or Full -- STD) RFC.
The Area Director(s) will acknowledge receipt of the E-mail. From
then onwards the progressing of the document is the
responsibility of the IESG.
4.4. Review Of Documents
In case the submission is intended as an Informational RFC only
IESG 21
no review is necessary. However if the WG or the RFC editor
thinks that a review is appropriate, the AD may be asked to
provide one. In case of submission as an Experimental RFC, the
document will always be reviewed by the IESG. This review can
either be done by the AD and other IESG members or the IESG may
ask for an independent reviewer (i.e., by someone not part of the
WG in question) from the Area Directorate or elsewhere.
A review will lead to one of three possible conclusions:
1. The document is accepted as is.
This fact will be announced by the IESG to the IETF
mailing list and to the RFC Editor. Publication is then
further handled between the RFC editor and the
author(s).
2. Changes regarding content are suggested to the
author(s)/WG.
Suggestions must be clear and direct, so as to
facilitate working group and author correction of the
specification. Once the author(s)/WG have made these
changes or have explained to the satisfaction of the
reviewers why the changes are not necessary, the
document will be accepted for publication as under point
1, above.
3. The document is rejected.
This will need strong and thorough arguments from the
reviewers. The whole IETF and working group process is
structured such that this alternative is not likely to
arise for documents coming from a Working Group. After
all, the intentions of the document will already have
been described in the WG charter, and reviewed at the
start of the WG.
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 procedural complaints is
described in the section on Contention and Appeal.
Before making a final decision on a standards-track document, the
IESG 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,
IESG 22
to make sure that no important concerns have missed or
misunderstood. Last Call cannot serve as a more general, in-
depth review.
5. SECURITY CONSIDERATIONS
Security issues are not addressed in this memo.
References
----------
[1] RFC1310bis
[2] Charter
6. REFERENCES
[1]RFC1310bis, The Internet Standards Process
[2]Charter Internet Society
[3] New
[3]New charter IETF
[4] RFC
[4]RFC 1111 Request for Comments on Request for Comments, J.
Postel, August 1990.
[5] RFC
[5]RFC 1150 F.Y.I. on F.Y.I., G. Malkin and J. Reynolds, March
1990
[6] RFC
[6]RFC 1311 Introduction to the Standards Notes, ed. J. Postel,
March 1992.
[7] RFC
[7]RFC 1360 IAB Official Protocol Standards, ed. J. Postel,
Sept. 1992.
[8] RFC
[8]RFC 1160, The Internet Activities Board, V.Cerf, may 1990
(This should be OBE by [3] by the time this gets published)
[9] Guidelines
[9]Guidelines to Working Group Chair(s), S. Coya, IESG
distribution only.
Authors address
---------------
7. AUTHORS ADDRESS
Erik Huizer
SURFnet bv
P.O. Box 19035
3501 DA Utrecht
The Netherlands Phone: +31 30 310290
3501 DA Utrecht Fax: +31 30 340903
The Netherlands Email: Erik Huizer@SURFnet.nl
Appendix:
Erik.Huizer@SURFnet.nl
IESG 23
Dave Crocker
Silicon Graphics, Inc.
2011 N. Shoreline Blvd. Phone: +1 415 390 1804
P.O. Box 7311 Fax: +1 415 962 8404
Mountain View, CA 94039 Email: dcrocker@sgi.com
APPENDIX: Sample Working Group charter
------------------------------------
MIME-MHS Interworking (mimemhs)
Integrated Directory Services (ids)
Charter
Chair(s):
Steve Thompson <sjt@gateway.ssw.com>
OSI Integration
Chris Weider <clw@merit.edu>
Tim Howes <tim@umich.edu>
User Services Area Director(s)
Erik Huizer <huizer@surfnet.nl>
Dave Piscitello <dave@sabre.bellcore.com>
Joyce Reynolds <jkrey@isi.edu>
Mailing lists:
General Discussion:mime-mhs@surfnet.nl Discussion:ids@merit.edu
To Subscribe: mime-mhs-request@surfnet.nl ids-request@merit.edu
Archive: merit.edu:~/pub/ids-archive
Description of Working Group:
MIME, (Multipurpose Internet Mail Extensions) currently an Internet
Draft,
The Integrated Directory Services Working Group (IDS) is expected
chartered to become an Internet Proposed Standard. MIME
redefines facilitate the format integration and interoperability of message bodies to allow multi-part textual
current and
non-textual message bodies future directory services into a unified directory
service. This work will unite directory services based on a
heterogeneous set of directory services protocols (X.500,
WHOIS++, etc.). In addition to be represented specifying technical requirements
for the integration, the IDS Group will also contribute to the
administrative and exchanged without loss maintenance issues of directory service
offerings by publishing guidelines on directory data integrity,
maintenance, security, and privacy and legal issues for users and
administrators of information. With directories. IDS will also assume
IESG 24
responsibility for the introduction completion of MIME as a Proposed Standard
it is now possible the outstanding Directory
Information Services Infrastructure (DISI) Internet-Drafts, which
are all specific to define mappings between RFC-822 content-types the X.500 protocol, and
X.400 body parts. for the maintenance
of FYI 11, ``A catalog of available X.500 implementations''. IDS
will need to liase with the groups working on development and
deployment of the various directory service protocols.
The MIME-MHS Interworking IDS Working Group is chartered
to develop these mappings, providing an emphasis on both interworking
between Internet and MHS mail environments a combined effort of the Applications
Area and also on tunneling
through these environments. These mappings will be made in the context User Services Area of an RFC-1148bis environment. the IETF.
Goals and Milestones:
Jan 92 Post
Ongoing Track emerging directory service protocols to
specify standards for interoperation with existing
protocols.
Ongoing Liase with groups working on deployment and
development of directory services to locate and
fix interoperability problems.
Ongoing Identify unfilled needs of directory service
offerers, administrators, and users.
Mar 93 Submit to the IESG the DISI ``Advanced Usages of
X.500'' paper as an Internet Draft describing MIME-MHS Interworking.
Jan 92 Post informational document.
Mar 93 Submit to the IESG the DISI ``X.500 Pilot
Project Catalog'' paper as an Internet Draft describing informational
document.
Mar 93 Submit to the ``core'' set IESG the 1993 revision of FYI 11,
``A catalog of
Registered conversions available X.500 implementations''
as an informational document.
Mar 93 Submit as an Internet-Draft a ``Specifications
for bodyparts. interoperability between WHOIS++ and X.500''.
Jul 92 93 Submit as an Internet-Draft a completed document ``Guide to
administering a directory service'', which covers
data integrity, maintenance, privacy and legal
issues, and security.
Jul 93 Submit as an Internet-Draft a ``Catalog of
available WHOIS++ implementations''.
Nov 93 Submit to the IESG the ``Specifications for
interoperability between WHOIS++ and X.500'' as a
standards document.
IESG describing MIME-MHS
Interworking 25
Nov 93 Submit as an Internet-Draft a Proposed Standard.
Jul 92 ``User's guide to
directory services on the Internet''.
Mar 94 Submit to the ``core'' bodyparts document IESG the ``Guide to administering
a directory service'' as an informational
document.
Mar 94 Submit to the IESG the 1994 revision of FYI 11.
Mar 94 Submit to the IESG the ``Catalog of available
WHOIS++ implementations'' as a
Proposed Standard. an informational
document.