As per Relevance of the word director, we have this rfc below:
Network Working Group E.
Request for Comments: 1603 SURFnet
Category: Informational D.
Silicon Graphics, Inc
March 1994
IETF Working
Guidelines and
Status of this
This memo provides information for the Internet community. This
does not specify an Internet standard of any kind. Distribution
this memo is unlimited
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 describes the
relationship between IETF participants WG and the
Engineering Steering Group (IESG). The basic duties of
participants, including WG Chair and IESG Area Directors are defined
Table of
1. INTRODUCTION.............................................. 2
1.1. IETF approach to standardization........................ 3
1.2. Acknowledgments......................................... 4
2. WORKING GROUP (WG) FORMATION.............................. 5
2.1. Criteria for formation.................................. 5
2.2. Charter................................................. 6
2.3. Charter review & approval............................... 9
2.4. Birds of a feather (BOF)................................ 9
3. WORKING GROUP OPERATION................................... 11
3.1. Session planning........................................ 11
3.2. Session venue........................................... 12
3.3. Session management...................................... 14
3.4. Contention and appeals overview......................... 15
4. WORKING GROUP TERMINATION................................. 16
5. STAFF ROLES............................................... 17
5.1. WG Chair................................................ 17
5.2. WG Editor/Secretary..................................... 19
5.3. WG Facilitator.......................................... 19
5.4. Design teams............................................ 19
Huizer & Crocker [Page 1]
RFC 1603 IETF Working Group Guidelines March 1994
5.5. Area Consultant......................................... 19
5.6. Area Director........................................... 20
5.7. Area Directorate........................................ 21
6. WORKING GROUP DOCUMENTS................................... 21
6.1. Session documents....................................... 21
6.2. IETF meeting document archive........................... 21
6.3. Internet-Drafts (I-D)................................... 23
6.4. Request For Comments (RFC).............................. 24
6.5. Submission of documents................................. 24
6.6. Review of documents..................................... 25
7. SECURITY CONSIDERATIONS................................... 26
8. REFERENCES................................................ 26
9. AUTHORS' ADDRESSES........................................ 27
APPENDIX: SAMPLE WORKING GROUP CHARTER........................ 28
1.
This document defines guidelines and procedures for
Engineering Task Force working groups. The Internet is a loosely
organized international collaboration of autonomous,
networks; it supports host-to-host communication through
adherence to open protocols and procedures defined by
Standards, a collection of which are commonly known as "the TCP/
protocol suite". The Internet Standards Process is defined in [1].
Development and review of potential Internet Standards from
sources is conducted by the Internet Engineering Task Force (IETF).
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 IETF is managed by its
Engineering Steering Group (IESG) whose membership includes an
Chair, responsible for oversight of general IETF operations, and
Directors, each of whom is responsible for a set of IETF
and working groups. The IETF Executive Director and IESG
are ex-officio participants, as are the IAB Chair and a
Internet Architecture Board (IAB) member. At present there are 10
areas, though the number and purview of areas changes over time
User Services (USV
Applications (APP
Service Applications (SAP
Transport Services (TSV
Internet (INT
Routing (RTG
Network Management (MGT
Operational Requirements (OPS
Security (SEC
Standards & Processes (STD
Huizer & Crocker [Page 2]
RFC 1603 IETF Working Group Guidelines March 1994
Most areas have an advisory group or directorate. The specific
and the details of the role for each group differs from area to area
but the primary intent is that the group assist the Area Director
e.g., with the review of specifications produced in the area.
advisory group is formed by an Area Director (AD) and
experienced members of the IETF and technical community
by the area. A small IETF Secretariat provides staff
administrative support for the operation of the IETF
The primary activities of the IETF are performed by committees
as working groups. There are currently more than 60 of these
Working groups tend to have a narrow focus and a lifetime bounded
completion of a specific task, although there are exceptions
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 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. The document uses: "shall", "will",
"must" and "is required" where it describes steps in the process
are essential, and uses: "suggested", "should" and "may" are
guidelines are described that are not essential, but are
recommended to help smooth WG operation
1.1. IETF approach to
The reader is encouraged to study The Internet Standards Process [1].
Familiarity with this document is essential for a
understanding of the philosophy, procedures and guidelines
in this document
The goals of the process are summarized in [1]:
"In general, an Internet Standard is a specification that
stable and well-understood, is technically competent,
multiple, independent, and interoperable
with operational experience, enjoys significant
support, and is recognizably useful in some or all parts
the Internet
...
Huizer & Crocker [Page 3]
RFC 1603 IETF Working Group Guidelines March 1994
"In outline, the process of creating an Internet Standard
straightforward: a specification undergoes a period
development and several iterations of review by the
community and perhaps revision based upon experience,
adopted as a Standard by the appropriate body (see below),
and is published
"In practice, the process is somewhat more complicated,
to (1) the number and type of possible sources
specifications; (2) the need to prepare and revise
specification in a manner that preserves the interests
all of the affected parties; (3) the importance
establishing widespread community agreement on its
content; and (4) the difficulty of evaluating the utility
a particular specification for the Internet community
...
"These procedures are explicitly aimed at developing
adopting generally-accepted practices. Thus, a
for Internet standardization is implemented and tested
correct operation and interoperability by multiple
independent parties, and utilized in increasingly
environments, before it can be adopted as an
Standard."
The IETF standardization process has been marked by informality.
the community of participation has grown it has become necessary
document procedures, while continuing to avoid
bureaucracy. This goals of this balancing act are summarized in [1]
as
"The procedures that are described here provide a great
of flexibility to adapt to the wide variety of
that occur in the Internet standardization process
Experience has shown this flexibility to be vital
achieving the following goals for Internet standardization
* high quality
* prior implementation and testing
* openness and fairness,
* timeliness."
1.2.
Much of this document is due to the copy-and-paste function of a
processor. Several passages have been taken from the documents
in the reference section. The POISED WG provided discussion
comments. Three people deserve special mention, as especially
chunks of their documents have been integrated into this one:
Huizer & Crocker [Page 4]
RFC 1603 IETF Working Group Guidelines March 1994
Cerf [7] from whom we borrowed the description of the IETF; and
Vaudreuil and Steve Coya who provided several paragraphs. Also,
Stewart and Steve Crocker did a truly stellar job of proof-reading
However, all the errors you'll find are probably ours
2. WORKING GROUP (WG)
IETF working groups (WGs) are the primary mechanism for
of IETF specifications and guidelines, many of which are intended
standards or recommendations. A working group may be established
the initiative of an Area Director (AD) 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
appropriate IETF Area Director under whose direction the
group would fall and must proceed through the formal steps
in this section
A working group is typically created to address a specific problem
produce a deliverable (a guideline, standards specification, etc.)
and is expected to be short-lived in nature. Upon completion of
goals and achievement of its objectives, the working group as a
is terminated. Alternatively at the discretion of the IESG,
Director, the WG Chair and the WG participants, the objectives
assignment of the working group may be extended by enhancing
modifying the working group's charter
2.1. Criteria for
When determining whether it is appropriate to create a working group
the Area Director and the IESG will consider several issues
- Are the issues that the working group plans to address
and relevant for the Internet community
- Are the goals specific and reasonably achievable,
achievable within the time frame specified by
milestones
- What are the risks and urgency of the work, to determine
level of attention required
- Do the working group's activities overlap with those
another working group? If so, it may still be appropriate
create the working group, but this question must
considered carefully by the Area Directors as
efforts often dilutes the available technical expertise
Huizer & Crocker [Page 5]
RFC 1603 IETF Working Group Guidelines March 1994
- Is there sufficient interest and expertise in the
group's topic with at least several people willing to
the effort to produce the desired result (e.g., a
specification)? Working groups require considerable effort
including management of the working group process,
of working group documents, and contribution to the
text. IETF experience suggests that these roles
cannot all be handled by one person; four or five
participants are typically required
- Does a base of interested consumers (end users) appear
exist for the planned work? Consumer interest can
measured by participation of end-users within the
process, as well as by less direct means
Considering the above criteria, the Area Director will decide
to pursue the formation of 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, although final approval is made by
IESG and all charters are reviewed by the Internet Architecture
(IAB). A charter is a contract between a working group and the
to perform a set of tasks. A charter
1. Lists relevant administrative aspects of the working group
2. Specifies the direction or objectives of the working
and describes the approach that will be taken to achieve
goals;
3. Enumerates a set of milestones together with time frames
their completion
When the prospective Chair, the Area Director and the IESG
are satisfied with the charter form and content, it becomes the
for forming a working group. The AD may require an initial draft of
charter to be available prior to holding an exploratory Birds of
Feather (BOF) meeting, as described below
Charters may be renegotiated periodically to reflect the
status, organization or goals of the working group. Hence, a
is a contract between the IETF and the working group which
committing to meet explicit milestones and delivering
"products".
Huizer & Crocker [Page 6]
RFC 1603 IETF Working Group Guidelines March 1994
Specifically, each charter consists of 6 sections
Working group
A working group name should be reasonably descriptive
identifiable. Additionally, the group shall define
acronym (maximum 8 printable ASCII characters) to
the group in the IETF directories, mailing lists,
general documents
Chair(s
The working group may have one or two Chair(s) to
the administrative functions of the group. The
address(es) of the Chair(s) shall be included
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
Mailing
It is required that an IETF working group have a
Internet mailing list. Most of the work of an IETF
group will be conducted that
The charter shall include
The address to which a participant sends
subscription request and the procedures to follow
subscribing
The address to which a participant sends
and special procedures, if any,
The location of the mailing list archive, if any
A message archive should be maintained in a public
which can be accessed via FTP. The ability to retrieve
the archive via electronic mail requests also
recommended. Additionally, the address
ietf-archive@cnri.reston.va.
shall be included on the mailing list
Huizer & Crocker [Page 7]
RFC 1603 IETF Working Group Guidelines March 1994
NOTE: It is strongly suggested that the mailing list be
a host directly connected to the IP Internet to
use of the SMTP expansion command (EXPN) and to allow
archive access via FTP, gopher and the like in keeping
the general IETF rule for openness. If this is not possible
the message archive and membership of the list must be
available to those who request it by sending a message
the list-request alias
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 first
must give a brief summary of the problem area, basis, goal(s)
approach(es) planned for the working group. This paragraph
frequently be used as an overview of the working group's effort
The terms "they", "them" and "their" are used in this document
third-person singular pronouns
To facilitate evaluation of the intended work and to
on-going guidance to the working group, the charter
describe the problem being solved and shall
objectives and expected impact with respect to
-
-
-
- Network
- Transition (where applicable
Goals and
The working group charter must establish a timetable
work. While this may be re-negotiated over time, the
of milestones and dates facilitates the Area Director'
tracking of working group progress and status, and it
indispensable to potential participants identifying
critical moments for input. Milestones shall consist
deliverables that can be qualified as showing
achievement; e.g., "Internet-Draft finished" is fine,
"discuss via email" is not. It is helpful to
milestones for every 3-6 months, so that progress can
gauged easily. This milestone list is expected to
updated periodically. Updated milestones are re-
with the Area Director and the IESG, as needed, and then
submitted to the IESG Secretary
Huizer & Crocker [Page 8]
RFC 1603 IETF Working Group Guidelines March 1994
IESG-secretary@cnri.reston.va.
An example of a WG charter is in Appendix A
2.3. Charter review &
Working groups often comprise technically competent participants
are not familiar with the history of Internet architecture or
processes. This can, unfortunately, lead to good working
consensus about a bad design. To facilitate working group efforts
an Area Director may assign an Area Consultant from among the
of senior IETF participants. (Area Consultants are described in
section of Staff Roles.) At the discretion of the AD, approval of
new WG may be withheld in the absence of sufficient
resources
Once the Area Director (and the Area Directorate, as the AD
appropriate) has approved the working group charter, the charter
submitted for review by the IAB and approval by the
Engineering Steering Group using the criteria described previously
The Internet Architecture Board (IAB) will review the charter of
proposed WG to determine the relationship of the proposed work to
overall architecture of the Internet Protocol Suite
The approved charter is submitted to the IESG Secretary who
and enters the information into the IETF tracking database
returns the charter in a form formatted by the database. The
group is announced to the IETF mailing list by the IESG Secretary
2.4. Birds of a feather (BOF
Often it is not clear whether an issue merits the formation of
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
Alternatively, a BOF may serve as a forum for a single
or discussion, without any intent to form a working group
A BOF is a session at an IETF meeting which permits "market research
and technical "brainstorming". Any individual may request
to hold a BOF on a subject. The request must be filed with
relevant Area Director. The person who requests the BOF is
appointed as Chair of the BOF. The Chair of the BOF is
responsible for providing a report on the outcome of the BOF
Huizer & Crocker [Page 9]
RFC 1603 IETF Working Group Guidelines March 1994
The AD may require the conduct of email discussion, prior
authorizing a BOF. This permits initial exchanges and sharing
framework, vocabulary and approaches, in order to make the time
in the BOF more productive. The AD may require that a BOF be held
prior to establishing a working group, and the AD may require
there be a draft of the WG charter prior to holding a BOF
Usually the outcome of a BOF will be one of the following
- There was enough interest and focus in the subject
warrant the formation of a WG
- The discussion came to a fruitful conclusion, with
to be written down and published, however there is no
to establish a WG;
- There was not enough interest in the subject to warrant
formation of a WG
There is an increasing demand for BOF sessions at IETF meetings
Therefore the following rules apply for BOFs
- All BOFs must have the approval of the appropriate
Director. The Secretariat will NOT schedule or allocate
slots without the explicit approval of the Area Director
- The purpose of a BOF is to conduct a single,
discussion or to ascertain interest and establish goals
a working group. All BOF organizers are required to submit
brief written report of what transpired during the
session together with a roster of attendees to the
Secretary for inclusion in the Proceedings
- A BOF may be held only once (ONE slot at one IETF
meeting).
- Under unusual circumstances an Area Director may, at
discretion, allow a BOF to meet for a second time.
(though not a requirement) this is to develop a charter
be submitted to the IESG
- BOFs are not permitted to meet three times
Huizer & Crocker [Page 10]
RFC 1603 IETF Working Group Guidelines March 1994
- A BOF may be held for single-event discussion, or may
creation of normal IETF working groups for on-
interactions and discussions. When the request for a
comes from a formally-constituted group, rather than from
individual, the rules governing the handling of the
are the same as for all other BOFs and working groups
- When necessary, WGs will be given priority for meeting
over BOFs
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".
A number of procedural questions and issues will arise over time,
it is the function of the Working Group Chair 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 have
over time that have proven successful. These are listed here,
actual choices typically determined by the working group
and the Chair
3.1. Session
For coordinated, structured WG interactions, the Chair must publish
draft agenda well in advance of the actual session. The agenda
to contain at least
- The items for discussion
- The estimated time necessary per item;
- A clear indication of what documents the participants
need to read before the session in order to be
prepared
Huizer & Crocker [Page 11]
RFC 1603 IETF Working Group Guidelines March 1994
Publication shall include sending a copy to the working group
list and to the IETF-Announce list. Notices for the IETF-
list should be sent to
ietf-announce-post@cnri.reston.va.
All working group actions shall be taken in a public forum, and
participation is encouraged. A working group will conduct much
its 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. It
common, but not required, that a working group will meet at
trimester IETF Plenary events. Additionally, interim sessions may
scheduled for telephone conference, video teleconference, or
face-to-face (physical) sessions
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@cnri.reston.va.
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
participants. In determining the balance, the WG must ensure
its process does not serve to exclude contribution by email-
participants. Also note that decisions reached during IETF
are NOT final, but must be conveyed to the mailing list to verify
consensus
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
Huizer & Crocker [Page 12]
RFC 1603 IETF Working Group Guidelines March 1994
facilitate schedule coordination for WGs requiring the same set
experts
The application for a WG session at an IETF meeting shall be made
the IETF Secretariat. Alternatively some Area Directors may want
coordinate WG sessions in their area and request that time slots
coordinated through them. After receiving all requests for
slots by WGs in the area, the Area Director(s) form a draft session
agenda for their area, which is then sent to the WG chairs of
area. After approval it will be sent to the IETF Secretariat
An application must contain
- The amount of time requested
- The rough outline of the WG agenda that is expected to
covered
- The estimated number of people that will attend the
session
- Related WGs that must not be scheduled for the same
slot(s);
- Individuals whose attendance is desired
The Secretariat allots time slots on the basis of the session-
made by the Area Director(s). If the proposed session- agenda for
area does not fit into the IETF meeting-agenda, the IETF
will adjust it to fit, after consulting the Area Director(s) and
relevant chairs. The Secretariat will then form a draft session
agenda and distribute it among the Working Group Chairs for
approval
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
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
Huizer & Crocker [Page 13]
RFC 1603 IETF Working Group Guidelines March 1994
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
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.)
Consensus can be determined by balloting, humming, or any other
on which the WG agrees (by rough consensus, of course).
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 direct a discussion to reject or defer the input from a member
based upon the following criteria
The input pertains to a topic that already has been
and is redundant with information previously available
Huizer & Crocker [Page 14]
RFC 1603 IETF Working Group Guidelines March 1994
The input is new and pertains to a topic that has
been resolved, but it is felt to be of minor import to
existing decision
The input pertains to a topic that the working group has
yet opened for discussion;
The input is outside of the scope of the working
charter
3.4. Contention and appeals
In the course of group design processes, strife happens. Strife
contention are particularly likely when working groups comprise
constituencies. On the other hand differences in view are vital
the success of the IETF and healthy debate is encouraged.
debates degenerate into something akin to warfare. For
circumstances, the IETF has an extensive review and appeals process
Formal procedures for requesting review and conducting appeals
documented in The Internet Standards Process [1]. A brief summary
provided, here
In fact the IETF approach to reviews and appeals is quite simple
When an IETF participant feels that matters have not been
properly, they should state their concern to a member of
management. In other words, the process relies upon those who
concerns raising them. If the result is not satisfactory, there
several levels of appeal available, to ensure that review is
by a number of people uninvolved in the matter in question
Reviews and appeals step through four levels, each in turn
WG
An appeal must begin with the management closest to
operation of the working group, even if the concern
to their own handling of working group process
Huizer & Crocker [Page 15]
RFC 1603 IETF Working Group Guidelines March 1994
If discussion and review with the WG Chair do not produce
satisfactory result, the complainant may bring their
to the cognizant Area Director
If a concerned party is not satisfied with the results
the area-level review, then they may bring the matter to
IESG Chair and the Area Director for Standards & Processes
The IESG Chair and the Standards & Processes AD will
the issue before the full IESG for an additional review
will report the resolution back to the parties
The IAB provides a final opportunity to appeal the
of previous reviews. If a concerned party does not
the outcome of the IESG review, then they may take
concern to the IAB, by contacting the IAB Chair
Concerns entail either a disagreement with technical decisions by
working group or with the process by which working group business
been conducted. Technical disagreements may be about
details or about basic approach. When an issue pertains
preference, it should be resolved within the working group. When
matter pertains to the technical adequacy of a decision, review
encouraged whenever the perceived deficiency is noted. For
having to do with preference, working group rough consensus
dominate
When a matter pertains to working group process, it is important
those with a concern be clear about the manner in which the
was not open or fair and that they be willing to discuss the
openly and directly. In turn, the IETF management will make
effort to understand how the process was conducted, what
were present (if any) and how the matter should be corrected.
IETF functions on the good will and mutual respect of
participants; continued success requires continued attention
working group process
4. WORKING GROUP
Working groups are typically chartered to accomplish a specific task
After that task is complete, the group will be disbanded. However
a WG produces a Proposed or Draft Standard, the WG will
dormant rather than disband (i.e., the WG will no longer
Huizer & Crocker [Page 16]
RFC 1603 IETF Working Group Guidelines March 1994
formal activities, but the mailing list will remain available
review the work as it moves to Draft Standard and Standard status.)
If, at some point, it becomes evident that a working group is
to complete the work outlined in the charter, the group,
consultation with its Area Director can either
1. Recharter to refocus on a smaller task
2. Choose new Chair(s),
3. Disband
If the working group disagrees with the Area Director's choice,
may appeal to the IESG
5. STAFF
Working groups require considerable care and feeding. In addition
general participation, successful working groups benefit from
efforts of participants filling specific functional roles
5.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
This encompasses at the very least the following
Ensure WG process and content
The Chair has ultimate responsibility for ensuring that
working group achieves forward progress and meets
milestones. For some working groups, this can
accomplished by having the Chair perform all management
related activities. In other working groups --
those with large or divisive participation -- it is
to allocate process and/or secretarial functions to
participants. Process management pertains strictly to
style of working group interaction and not to its content
It ensures fairness and detects redundancy. The
function encompasses document editing. It is quite
for a working group to assign the task of
Editor to one or two participants. Often, they also
part of the design team, described below
Huizer & Crocker [Page 17]
RFC 1603 IETF Working Group Guidelines March 1994
Moderate the WG email
The Chair should attempt to ensure that the discussions
this list are relevant and that they converge to
agreements. The Chair should make sure that discussions
the list are summarized and that the outcome is
documented (to avoid repetition). The Chair also may
to schedule organized on-line "sessions" with agenda
deliverables. These are structured as true meetings
conducted over the course of several days (to
participation across the Internet.) Participants
expected to allocate time to the meeting, usually in
range of 1-2 hours per day of the "meeting".
Organize, prepare and chair face-to-face & on-line formal
The Chair should plan and announce sessions well in advance
(See section on Session Planning for exact procedures.)
Communicate results of
The Chair and/or Secretary must ensure that minutes of
session are taken and that an attendance list is circulated
See the section on Session Documents for
procedures
Immediately after a session, the WG Chair must
provide the Area Director with a very short
(approximately one paragraph, via email) on the session
This is used in an Area Report as presented in
Proceedings of each IETF meeting
Distribute the
Of course each WG will have participants who may not be
(or want) to do any work at all. Most of the time the
of the work is done by a few dedicated participants. It
the task of the Chair to motivate enough experts to
for a fair distribution of the workload
Document
Working groups produce documents and documents need authors
The Chair will make sure that authors of WG
incorporate changes as discussed by the WG. See the
on Session Documents for details procedures
Huizer & Crocker [Page 18]
RFC 1603 IETF Working Group Guidelines March 1994
Document
The Chair and/or Secretary will work with the RFC Editor
ensure document conformance with RFC
requirements and to coordinate any editorial
suggested by the RFC Editor. A particular concern is
all participants are working from the same version of
document at the same time
5.2. WG Editor/
Taking minutes and editing working group documents often is
by a specifically-designated participant or set of participants.
this role, the Editor's job is to record WG decisions, rather than
perform basic specification
5.3. 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
5.4. Design
The majority of the detailed specification effort within a
group may be done by self-selecting sub-groups, called design teams
with the (implicit or explicit) approval of the working group.
team may hold closed sessions for conducting portions of
specification effort. In some cases design teams are necessary
make forward progress when preparing a document. All work
by a design team must be available for review by all working
participants and the design team must be responsive to the
of the working group's consensus
5.5. Area
At the discretion of the AD, a Consultant may be assigned to
working group. Consultants are senior participants in the
community. They have technical background appropriate to the WG
experience in Internet architecture and IETF process
Huizer & Crocker [Page 19]
RFC 1603 IETF Working Group Guidelines March 1994
5.6. 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. This very general description encompasses at the very
these detailed tasks related to working groups
Area
The Area Director determines activities appropriate to
area. This may include initiating working groups directly
rather than waiting for proposals from IETF participants
Coordination of
The Area Director coordinates the work done by the
WGs within (and sometimes even outside) the relevant area
IETF Meeting
The Director tries to coordinate sessions in such a way
experts can attend the relevant sessions with a minimum
overlap and gaps between sessions. (See section on
sessions for details.)
The Area Director reports to the IETF on progress in
area
The Area Director may appoint independent reviewers prior
document approval. The Area Director tracks the progress
documents from the area through the IESG review process,
report back on this to the WG Chair(s).
Progress
The Area Director tracks and manages the progress of
various WGs with the aid of a regular status report
documents and milestones that is generated by the
Secretary. The Area Director forwards this report to the
chairs. This in turn helps the chairs to manage their WGs
Huizer & Crocker [Page 20]
RFC 1603 IETF Working Group Guidelines March 1994
5.7. Area
An area directorate consists of senior members of the
community and are appointed by the Area Director who then tasks
with technical oversight and review of specific area activities.
Area Director chairs the directorate. At the request of the AD
directorate members conduct specification reviews and may be
as Area Consultants, to provide architectural assistance
6. WORKING GROUP
6.1. Session
All relevant documents for a session (including the final agenda
should be published and available at least two weeks before a
starts
It is strongly suggested that the WG Chair make sure that
anonymous FTP directory be available for the upcoming session.
relevant documents (including the final agenda and the minutes of
last session) should be placed in this directory. This has
advantage that all participants can FTP all files in this
and thus make sure they have all relevant documents. Also, it will
helpful to provide electronic mail-based retrieval for
documents
6.2. IETF meeting document
In preparing for an IETF meeting it is helpful to have ready
to all documents that are being reviewed. While documents usually
placed in the internet-drafts Internet Repository or in
respective working group archives or just published in some mail
lists, there are just too many things to browse or read through
Also, many documents are modified immediately before a meeting
The InterNIC Directory and Database Services provides a current
ietf-docs archive to enable people to get all documents that
relevant for the up-coming IETF meeting. This document database
be removed two weeks after the IETF meeting
The completeness of this archive depends on the authors and
group chairs submitting the documents. Each WG Chair is requested
submit the agenda to this archive
Structure of the archive
On ds.internic.net documents will be stored under the
working group name under the appropriate area name in the directory
Huizer & Crocker [Page 21]
RFC 1603 IETF Working Group Guidelines March 1994
/pub/current-ietf-
Each area will also have a directory called bof where a document
be discussed in a BOF meeting will be placed. At the area level
directory called plenary will be created to hold documents
presentation material related to a plenary session. Any
conflicts will be resolved by the InterNIC's administrator and
submitter will be informed via electronic mail. Example
/pub/current-ietf-docs/app/
/pub/current-ietf-docs/int/
Access via anonymous FTP
Anonymous FTP to ds.internic.net and change directory
/pub/current-ietf-docs
and browse and get the document of interest
Access via gopher
Connect to gopher.internic.net and select the menu item
4. InterNIC Directory and Database Services (AT&T)/
and then the menu item
3. Documents to be reviewed at the ***
One may use the public-access gopher client by
telnet gopher.internic.
Submission of documents via anonymous FTP
FTP to ds.internic.net and login as anonymous. Change directory to
/incoming/current-ietf-
Put the document using the following filename convention
..<filename
e.g.:
plenary.mondayVGs.
app.osids.
app.osids.internic-talk-VGs.
Huizer & Crocker [Page 22]
RFC 1603 IETF Working Group Guidelines March 1994
Note that the names of areas and working groups are their
short-form acronyms
Submission of documents via electronic mail
Send mail
admin@ds.internic.
with the following subject line
IETF - ..<filename
e.g.:
IETF - app.osids.
NOTE: Instead of sending a fresh copy of an already
document, you may ask the InterNIC's administrators to create a
to an existing internet-draft/RFC/
NOTE: If you do not remember your area or working group acronym
the file /ftp/ietf/1wg-summary.txt from ds.internic.net via
FTP
6.3. Internet-Drafts (I-D
The Internet-Drafts directory is provided to working groups as
resource for posting and disseminating early copies of working
documents. This repository is replicated at various locations
the Internet. It is encouraged that draft documents be posted as
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@cnri.reston.va.
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
the Secretariat
- The I-D filename;
Huizer & Crocker [Page 23]
RFC 1603 IETF Working Group Guidelines March 1994
- The expiration date for the I-D
Complete specification of requirements for an Internet-Draft
found in the file
1id-guidelines.
in the internet-drafts directory at an Internet Repository site
6.4. Request For Comments (RFC
The work of an IETF working group usually results in publication
one or more documents, as part of the Request For Comments (RFCs) [2]
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. The designated author need not
the group Chair(s).
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
For a description on the various categories of RFCs the reader
referred to [1, 4, 5, 6].
6.5. Submission of
When a WG decides that a document is ready for publication,
following must be done
- The version of the relevant document as approved by the
must be in the Internet-Drafts directory
- The relevant document must be formatted according to
rules [2].
- The WG Chair sends email to the relevant Area Director,
a copy to the IESG Secretary. The mail should contain
reference to the document, and the request that it
progressed as an Informational, Experimental, Prototype
standards-track (Proposed, Draft or Internet Standard) RFC
The IESG Secretary will acknowledge receipt of the email.
returned to the WG for further development, progressing of
Huizer & Crocker [Page 24]
RFC 1603 IETF Working Group Guidelines March 1994
document is then the responsibility of the IESG. After
approval, responsibility for final disposition is the
responsibility of the RFC Editor and the WG Chair and Editor
6.6. Review of
Usually in case of a submission intended as an Informational
Experimental RFC minimal review is necessary. However, if the WG
the RFC Editor thinks that an extensive review is appropriate,
Area Director may be asked to conduct one. This review may either
done by the AD and other IESG participants or the IESG may ask for
independent review (e.g., 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 Secretary to
IETF mailing list and to the RFC Editor. Publication is
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
working group and author correction of the specification
Once the author(s)/WG have made these changes or
explained to the satisfaction of the reviewers why
changes are not necessary, the document will be accepted
publication as under point 1, above
3. The document is rejected
This will need strong and thorough arguments from
reviewers. The whole IETF and working group process
structured such that this alternative is not likely to
for documents coming from a working group. After all,
intentions of the document will already have been
in the WG charter, and reviewed at the start of the WG
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 procedural complaints
described in the section on Contention and Appeal
Before the IESG makes a final decision on a standards-track document
the IESG Secretary will issue a "Last Call" to the IETF mailing list
This Last Call will announce the intention of the IESG to
Huizer & Crocker [Page 25]
RFC 1603 IETF Working Group Guidelines March 1994
the document, and it will solicit final comments from the IETF
a period of two weeks. It is important to note that a Last Call
intended as a brief, final check with the Internet community, to
sure that no important concerns have been missed or misunderstood
The Last Call cannot serve as a more general, in-depth review
7. SECURITY
Security issues are not discussed in this memo
8.
[1] Internet Architecture Board and Internet Engineering
Group, "The Internet Standards Process -- Revision 2", RFC 1602,
IAB, IESG, March 1994.
[2] Postel, J., "Instructions to RFC Authors", RFC 1543,
USC/Information Sciences Institute, October 1993.
[3] Malkin, G., and J. Reynolds, "F.Y.I. on F.Y.I. - Introduction
the F.Y.I. Notes", RFC 1150, Proteon, USC/Information
Institute, March 1990.
[4] Postel, J., Editor, "Introduction to the STD Notes", RFC 1311,
USC/Information Sciences Institute, March 1992.
[5] Postel, J., Editor, "Internet Official Protocol Standards",
1, RFC 1600, IAB, March 1994.
[6] Cerf, V., "The Internet Activities Board", RFC 1160, NRI,
1990.
Huizer & Crocker [Page 26]
RFC 1603 IETF Working Group Guidelines March 1994
9. AUTHORS'
Erik
SURFnet
P.O. Box 19035
3501 DA
The
Phone: +31 30 310290
Fax: +31 30 340903
EMail: Erik.Huizer@SURFnet.
Dave
Silicon Graphics, Inc
2011 N. Shoreline Blvd
P.O. Box 7311
Mountain View, CA 94039
Phone: +1 415 390 1804
Fax: +1 415 962 8404
EMail: dcrocker@sgi.
Huizer & Crocker [Page 27]
RFC 1603 IETF Working Group Guidelines March 1994
APPENDIX: SAMPLE WORKING GROUP
Multiparty Multimedia Session Control (mmusic
Chair(s):
Eve Schooler
Abel Weinrib
Transport Area Director(s
Allison Mankin
Mailing lists
General Discussion:confctrl@isi.
To Subscribe: confctrl-request@isi.
Archive: venera.isi.edu:~/confctrl/confcrtl.
Description of Working Group
The demand for Internet teleconferencing has arrived, yet
infrastructure to support this demand is barely in place
Multimedia session control, defined as the management
coordination of multiple sessions and their multiple users
multiple media (e.g., audio, video), is one component of
infrastructure. The Multiparty Multimedia Session
Working Group is chartered to design and specify a protocol
perform these functions
The protocol will provide negotiation for session membership
underlying communication topology and media configuration.
particular, the protocol will support a user initiating
multimedia multiparty session with other users ("calling"
users) over the Internet by allowing a
application on one workstation to explicitly rendezvous
teleconferencing applications running on remote workstations
Defining a standard protocol will enable session-
interoperability between different
implementations
The focus of the working group is to design a session
protocol that is tailored to support tightly-
conferences. The MBONE currently carries primarily loosely
controlled sessions, i.e., sessions with little to no
among members and with no arbitration facility, security,
coordination of quality-of-service options for time-
media. Users may learn of available sessions using the "sd
utility or other out of band mechanisms (e.g., email). However
Huizer & Crocker [Page 28]
RFC 1603 IETF Working Group Guidelines March 1994
there is clearly also a need for tightly-controlled sessions
provide mechanisms for directly contacting other users
initiate a session and for negotiating conference parameters
as membership, media encodings and encryption keys. In addition
these sessions should support renegotiation during a session,
example to add or delete members or change the media encoding
It is possible that the protocol will, in the limiting case,
support loosely-controlled sessions
The main goal of the working group will be to specify the
control protocol for use within teleconferencing software
the Internet. The working group will focus on the aspects of
session control problem that are well understood, while
an eye on evolving research issues. Toward this end, the
group has made an inventory of existing conferencing systems
their session control protocols. The working group will
the requirements of the existing prototypes as a basis for
protocol development. The working group will iteratively
the protocol based on implementation and operational experience
Furthermore, the working group will coordinate with other
related to multimedia conferencing, such as directory
for cataloguing users and conferences, the RTP and RTCP
developed by the Audio/Video Transport Working Group,
reservation and management at the network level, and schemes
multicast address allocation
Goals and Milestones
May 93 Hold an on-line working group meeting to
the conference control framework, the
terminology, a functional taxonomy and
different conversational styles
requirements on session protocols
Jun 93 Submit the Conference Session Control Protocol
the IESG for consideration as an
Protocol
Aug 93 Post an Internet-Draft describing the
Control Requirements
Nov 93 Post an Internet-Draft of the Session
Protocol
Mar 94 Submit a revised Internet-Draft based
implementation experience
Huizer & Crocker [Page 29]
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
