< draft-ietf-poisson-wg-guide-02.txt   draft-ietf-poisson-wg-guide-03.txt >
Network Working Group S. Bradner Network Working Group S. Bradner
Internet-Draft Harvard University Internet-Draft Harvard University
Editor Editor
March 1998 August 1998
IETF Working Group IETF Working Group
Guidelines and Procedures Guidelines and Procedures
<draft-ietf-poisson-wg-guide-02.txt> <draft-ietf-poisson-wg-guide-03.txt>
Status of this Memo Status of this Memo
This document is an Internet-Draft. Internet-Drafts are working This document is an Internet-Draft. Internet-Drafts are working
documents of the Internet Engineering Task Force (IETF), its areas, documents of the Internet Engineering Task Force (IETF), its areas,
and its working groups. Note that other groups may also distribute and its working groups. Note that other groups may also distribute
working documents as Internet-Drafts. working documents as Internet-Drafts.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as ``work in progress.'' material or to cite them other than as ``work in progress.''
To learn the current status of any Internet-Draft, please check the To view the entire list of current Internet-Drafts, please check the
``1id-abstracts.txt'' listing contained in the Internet-Drafts Shadow "1id-abstracts.txt" listing contained in the Internet-Drafts Shadow
Directories on ftp.is.co.za (Africa), nic.nordu.net (Europe), Directories on ftp.is.co.za (Africa), ftp.nordu.net (Northern
munnari.oz.au (Pacific Rim), ds.internic.net (US East Coast), or Europe), ftp.nis.garr.it (Southern Europe), munnari.oz.au (Pacific
ftp.isi.edu (US West Coast). Rim), ftp.ietf.org (US East Coast), or ftp.isi.edu (US West Coast).
Abstract Abstract
The Internet Engineering Task Force (IETF) has responsibility for The Internet Engineering Task Force (IETF) has responsibility for
developing and reviewing specifications intended as Internet developing and reviewing specifications intended as Internet
Standards. IETF activities are organized into working groups (WGs). Standards. IETF activities are organized into working groups (WGs).
This document describes the guidelines and procedures for formation This document describes the guidelines and procedures for formation
and operation of IETF working groups. It also describes the formal and operation of IETF working groups. It also describes the formal
relationship between IETF participants WG and the Internet relationship between IETF participants WG and the Internet
Engineering Steering Group (IESG) and the basic duties of IETF Engineering Steering Group (IESG) and the basic duties of IETF
participants, including WG Chairs, WG participants, and IETF Area participants, including WG Chairs, WG participants, and IETF Area
skipping to change at page 2, line 4 skipping to change at page 2, line 4
Table of Contents Table of Contents
Status of this Memo.................................................1 Status of this Memo.................................................1
Abstract............................................................1 Abstract............................................................1
1. Introduction.....................................................2 1. Introduction.....................................................2
1.1. IETF approach to standardization.............................4 1.1. IETF approach to standardization.............................4
1.2. Roles within a Working Group.................................4 1.2. Roles within a Working Group.................................4
2. Working group formation..........................................4 2. Working group formation..........................................4
2.1. Criteria for formation.......................................4 2.1. Criteria for formation.......................................4
2.2. Charter......................................................5 2.2. Charter......................................................5
2.3. Charter review & approval....................................7 2.3. Charter review & approval....................................8
2.4. Birds of a feather (BOF).....................................8 2.4. Birds of a feather (BOF).....................................8
3. Working Group Operation..........................................9 3. Working Group Operation..........................................9
3.1. Session planning.............................................9 3.1. Session planning.............................................9
3.2. Session venue...............................................10 3.2. Session venue...............................................10
3.3. Session management..........................................11 3.3. Session management..........................................12
3.4. Contention and appeals......................................12 3.4. Contention and appeals......................................13
4. Working Group Termination.......................................13 4. Working Group Termination.......................................13
5. Rechartering a Working Group....................................13 5. Rechartering a Working Group....................................13
6. Staff Roles.....................................................13 6. Staff Roles.....................................................14
6.1. WG Chair....................................................14 6.1. WG Chair....................................................14
6.2. WG Secretary................................................15 6.2. WG Secretary................................................16
6.3. Document Editor.............................................15 6.3. Document Editor.............................................16
6.4. WG Facilitator..............................................16 6.4. WG Facilitator..............................................16
6.5. Design teams................................................16 6.5. Design teams................................................16
6.6. Working Group Consultant....................................16 6.6. Working Group Consultant....................................16
6.7. Area Director...............................................16 6.7. Area Director...............................................17
7. Working Group Documents.........................................16 7. Working Group Documents.........................................17
7.1. Session documents...........................................16 7.1. Session documents...........................................17
7.2. IETF meeting documents......................................16 7.2. IETF meeting documents......................................17
7.3. Internet-Drafts (I-D).......................................17 7.3. Internet-Drafts (I-D).......................................17
7.4. Request For Comments (RFC)..................................17 7.4. Request For Comments (RFC)..................................18
7.5. Working Group Last-Call.....................................17 7.5. Working Group Last-Call.....................................18
7.6. Submission of documents.....................................18 7.6. Submission of documents.....................................18
8. Review of documents.............................................18 8. Review of documents.............................................18
9. Security Considerations.........................................19 9. Security Considerations.........................................20
10. Acknowledgments................................................19 10. Acknowledgments................................................20
11. References.....................................................20 11. References.....................................................20
12. Authors' Address...............................................20 12. Authors' Address...............................................20
Appendix: Sample Working Group Charter............................21 Appendix: Sample Working Group Charter............................21
1. Introuction 1. Introuction
The Internet, a loosely-organized international collaboration of The Internet, a loosely-organized international collaboration of
autonomous, interconnected networks, supports host-to-host autonomous, interconnected networks, supports host-to-host
communication through voluntary adherence to open protocols and communication through voluntary adherence to open protocols and
procedures defined by Internet Standards. There are also many procedures defined by Internet Standards. There are also many
isolated interconnected networks, which are not connected to the isolated interconnected networks, which are not connected to the
skipping to change at page 8, line 19 skipping to change at page 8, line 19
good working group consensus about a bad design. To facilitate good working group consensus about a bad design. To facilitate
working group efforts, an Area Director may assign a Consultant from working group efforts, an Area Director may assign a Consultant from
among the ranks of senior IETF participants. (Consultants are among the ranks of senior IETF participants. (Consultants are
described in section 6.) At the discretion of the Area Director, described in section 6.) At the discretion of the Area Director,
approval of a new WG may be withheld in the absence of sufficient approval of a new WG may be withheld in the absence of sufficient
consultant resources. consultant resources.
Once the Area Director (and the Area Directorate, as the Area Once the Area Director (and the Area Directorate, as the Area
Director deems appropriate) has approved the working group charter, Director deems appropriate) has approved the working group charter,
the charter is submitted for review by the IAB and approval by the the charter is submitted for review by the IAB and approval by the
IESG. The IESG MAY approve the charter as-is, it MAY request that IESG. After a review period of at least a week the proposed charter
is posted to the IETF-announce mailing list as a public notice that
the formation of the working group is being considered. At the same
time the proposed charter is also posted to the "new-work" mailing
list. This mailing list has been created to let qualified
representatives from other standards organizations know about pending
IETF working groups. After another review period lasting at least a
week the IESG MAY approve the charter as-is, it MAY request that
changes be made in the charter, or MAY decline to approve chartering changes be made in the charter, or MAY decline to approve chartering
of the working group of the working group
If the IESG approves the formation of the working group it remands If the IESG approves the formation of the working group it remands
the approved charter to the IETF Secretariat who records and enters the approved charter to the IETF Secretariat who records and enters
the information into the IETF tracking database. The working group the information into the IETF tracking database. The working group
is announced to the IETF-announce mailing list by the IETF is announced to the IETF-announce a by the IETF Secretariat.
Secretariat.
2.4. Birds of a feather (BOF) 2.4. Birds of a feather (BOF)
Often it is not clear whether an issue merits the formation of a Often it is not clear whether an issue merits the formation of a
working group. To facilitate exploration of the issues the IETF working group. To facilitate exploration of the issues the IETF
offers the possibility of a Birds of a Feather (BOF) session, as well offers the possibility of a Birds of a Feather (BOF) session, as well
as the early formation of an email list for preliminary discussion. as the early formation of an email list for preliminary discussion.
In addition, a BOF may serve as a forum for a single presentation or In addition, a BOF may serve as a forum for a single presentation or
discussion, without any intent to form a working group. discussion, without any intent to form a working group.
A BOF is a session at an IETF meeting which permits "market research" A BOF is a session at an IETF meeting which permits "market research"
skipping to change at page 13, line 50 skipping to change at page 14, line 7
1. Recharter to refocus its tasks, 1. Recharter to refocus its tasks,
2. Choose new Chair(s), or 2. Choose new Chair(s), or
3. Disband. 3. Disband.
If the working group disagrees with the Area Director's choice, it If the working group disagrees with the Area Director's choice, it
may appeal to the IESG. (see section 3.4) may appeal to the IESG. (see section 3.4)
5. Rechartering a Working Group 5. Rechartering a Working Group
Updated milestones are re-negotiated with the Area Director and the Updated milestones are re-negotiated with the Area Director and the
IESG, as needed, and then are submitted to the IESG Secretary: iesg- IESG, as needed, and then are submitted to the IESG Secretariat:
secretary@ietf.org iesg-secretary@ietf.org
Rechartering (other than revising milestones) a working group follows Rechartering (other than revising milestones) a working group follows
the same procedures that the initial chartering does. (see section 2) the same procedures that the initial chartering does. (see section 2)
The revised charter must be submitted to the IESG and IAB for The revised charter must be submitted to the IESG and IAB for
approval. As with the initial chartering, the IESG may approve new approval. As with the initial chartering, the IESG may approve new
charter as-is, it may request that changes be made in the new charter charter as-is, it may request that changes be made in the new charter
(including having the Working Group continue to use the old charter), (including having the Working Group continue to use the old charter),
or it may decline to approve the rechartered working group. In the or it may decline to approve the rechartered working group. In the
latter case the working group is disbanded. latter case the working group is disbanded.
6. Staff Roles 6. Staff Roles
Working groups require considerable care and feeding. In addition to Working groups require considerable care and feeding. In addition to
general participation, successful working groups benefit from the general participation, successful working groups benefit from the
efforts of participants filling specific functional roles. The Area efforts of participants filling specific functional roles. The Area
Director must agree to the specific people performing the WG Chair, Director must agree to the specific people performing the WG Chair,
Document Editor and Working Group Consultant roles, and they serve at and Working Group Consultant roles, and they serve at the discretion
the discretion of the Area Director. of the Area Director.
6.1. WG Chair 6.1. WG Chair
The Working Group Chair is concerned with making forward progress The Working Group Chair is concerned with making forward progress
through a fair and open process, and has wide discretion in the through a fair and open process, and has wide discretion in the
conduct of WG business. The Chair must ensure that a number of tasks conduct of WG business. The Chair must ensure that a number of tasks
are performed, either directly or by others assigned to the tasks. are performed, either directly or by others assigned to the tasks.
This encompasses at the very least the following:
The Chair has the responsibility and the authority to make decisions,
on behalf of the working group, regarding all matters of working
group process and staffing, in conformance with the rules of the
IETF. The AD has the authority and the responsibility to assist in
making those decisions at the request of the Chair or when
circumstances warrant such an intervention.
The Chair's responsibility encompasses at least the following:
Ensure WG process and content management Ensure WG process and content management
The Chair has ultimate responsibility for ensuring that a working The Chair has ultimate responsibility for ensuring that a working
group achieves forward progress and meets its milestones. The Chair group achieves forward progress and meets its milestones. The Chair
is also responsible to ensure that the working group operates in an is also responsible to ensure that the working group operates in an
open and fair manner. For some working groups, this can be open and fair manner. For some working groups, this can be
accomplished by having the Chair perform all management-related accomplished by having the Chair perform all management-related
activities. In other working groups -- particularly those with large activities. In other working groups -- particularly those with large
or divisive participation -- it is helpful to allocate process and/or or divisive participation -- it is helpful to allocate process and/or
secretarial functions to other participants. Process management secretarial functions to other participants. Process management
skipping to change at page 15, line 19 skipping to change at page 15, line 30
Plan WG Sessions Plan WG Sessions
The Chair must plan and announce all WG sessions well in advance. The Chair must plan and announce all WG sessions well in advance.
(See section 3.1) (See section 3.1)
Communicate results of sessions Communicate results of sessions
The Chair and/or Secretary must ensure that minutes of a session are The Chair and/or Secretary must ensure that minutes of a session are
taken and that an attendance list is circulated. (See section 3.1) taken and that an attendance list is circulated. (See section 3.1)
Immediately after a session, the WG Chair MUST provide the Area Immediately after a session, the WG Chair MUST provide the Area
Director with a very short report (approximately one paragraph, via Director with a very short report (approximately one paragraph, via
email) on the session. This is used in an Area Report presented in email) on the session.
the Proceedings of each IETF meeting.
Distribute the workload Distribute the workload
Of course each WG will have participants who may not be able (or Of course each WG will have participants who may not be able (or
want) to do any work at all. Most of the time the bulk of the work is want) to do any work at all. Most of the time the bulk of the work is
done by a few dedicated participants. It is the task of the Chair to done by a few dedicated participants. It is the task of the Chair to
motivate enough experts to allow for a fair distribution of the motivate enough experts to allow for a fair distribution of the
workload. workload.
Document development Document development
Working groups produce documents and documents need authors. The Working groups produce documents and documents need authors. The
skipping to change at page 16, line 28 skipping to change at page 16, line 38
6.4. WG Facilitator 6.4. WG Facilitator
When meetings tend to become distracted or divisive, it often is When meetings tend to become distracted or divisive, it often is
helpful to assign the task of "process management" to one helpful to assign the task of "process management" to one
participant. Their job is to oversee the nature, rather than the participant. Their job is to oversee the nature, rather than the
content, of participant interactions. That is, they attend to the content, of participant interactions. That is, they attend to the
style of the discussion and to the schedule of the agenda, rather style of the discussion and to the schedule of the agenda, rather
than making direct technical contributions themselves. than making direct technical contributions themselves.
6.5. Design teams 6.5. Design teams
In some cases some of the detailed specification effort within a It is often useful, and perhaps inevitable, for a sub-group of a
working group may be done by sub-groups, referred to as design teams, working group to develop a proposal to solve a particular problem.
with the (implicit or explicit) approval of the working group and the Such a sub-group is called a design team. In order for a design team
explicit approval of the Area Director. Such a team may hold closed to remain small and agile, it is acceptable to have closed membership
sessions for conducting portions of the specification effort. All and private meetings. Design teams may range from an informal chat
work products of a design team must be available for review by all between people in a hallway to a formal set of expert volunteers that
working group participants. The design team must be responsive to the WG chair or AD appoints to attack a controversial problem. The
the direction of the working group's consensus and its output is output of a design team is always subject to approval, rejection or
subject to the approval of the working group. The duration of a modification by the WG as a whole.
design team effort is up to the working group chair(s) and the Area
Director(s).
6.6. Working Group Consultant 6.6. Working Group Consultant
At the discretion of the Area Director, a Consultant may be assigned At the discretion of the Area Director, a Consultant may be assigned
to a working group. Consultants have specific technical background to a working group. Consultants have specific technical background
appropriate to the WG and experience in Internet architecture and appropriate to the WG and experience in Internet architecture and
IETF process. IETF process.
6.7. Area Director 6.7. Area Director
Area Directors are responsible for ensuring that working groups in Area Directors are responsible for ensuring that working groups in
their area produce coherent, coordinated, architecturally consistent their area produce coherent, coordinated, architecturally consistent
and timely output as a contribution to the overall results of the and timely output as a contribution to the overall results of the
IETF. IETF.
7. Working Group Documents 7. Working Group Documents
7.1. Session documents 7.1. Session documents
All relevant documents for a session (including the final agenda) All relevant documents for a session should be published and
should be published and available as Internet-Drafts at least two available as Internet-Drafts at least two weeks before a session
weeks before a session starts. Any document which does not meet this starts. Any document which does not meet this publication deadline
pubication deadline can only be discussed in a working group session can only be discussed in a working group session with the specific
with the specific approval of the working group chair(s). approval of the working group chair(s). The final session agenda
should be posted to the working group mailing list at two weeks
before the session.
7.2. IETF meeting documents 7.2. IETF meeting documents
In preparing for an IETF meeting it is helpful to have ready access In preparing for an IETF meeting it is helpful to have ready access
to all documents that are being reviewed. Thus all documents which to all documents that are being reviewed. Thus all documents which
will be under discussion in a working group session must be published will be under discussion in a working group session must be published
as Internet-Drafts before the session. as Internet-Drafts before the session.
7.3. Internet-Drafts (I-D) 7.3. Internet-Drafts (I-D)
The Internet-Drafts directory is provided to working groups as a The Internet-Drafts directory is provided to working groups as a
resource for posting and disseminating in-process copies of working resource for posting and disseminating in-process copies of working
skipping to change at page 18, line 29 skipping to change at page 18, line 39
Call. The decision to issue a working group Last-Call is at the Call. The decision to issue a working group Last-Call is at the
discretion of the WG Chair working with the Area Director. A working discretion of the WG Chair working with the Area Director. A working
group Last-Call serves the same purpose within a working group that group Last-Call serves the same purpose within a working group that
an IESG Last-Call does in the broader IETF community. (See [1].) an IESG Last-Call does in the broader IETF community. (See [1].)
7.6 Submission of documents 7.6 Submission of documents
Once that a WG has determined that at least rough consensus exists Once that a WG has determined that at least rough consensus exists
within the WG for the advancement of a document the following must be within the WG for the advancement of a document the following must be
done: done:
- The version of the relevant document exactly as agreed to by the - The version of the relevant document exactly as agreed to by the
WG MUST be in the Internet-Drafts directory; WG MUST be in the Internet-Drafts directory;
- The relevant document MUST be formatted according to RFC rules - The relevant document MUST be formatted according to RFC rules
[5]. [5].
- The WG Chair MUST send email to the relevant Area Director. A - The WG Chair MUST send email to the relevant Area Director. A
copy of the request MUST be also sent to the IESG Secretary. The copy of the request MUST be also sent to the IESG Secretariat.
mail MUST contain the reference to the document's ID filename, and The mail MUST contain the reference to the document's ID filename,
the action requested. and the action requested.
Unless returned to the WG for further development, progressing of the Unless returned to the WG for further development, progressing of the
document is then the responsibility of the IESG. After IESG document is then the responsibility of the IESG. After IESG
approval, responsibility for final disposition is the joint approval, responsibility for final disposition is the joint
responsibility of the RFC Editor and the WG Chair and the Document responsibility of the RFC Editor, the WG Chair and the Document
Editor. Editor.
8. Review of documents 8. Review of documents
The IESG reviews all documents submitted for publication as RFCs. The IESG reviews all documents submitted for publication as RFCs.
Usually minimal IESG review is necessary in the case of a submission Usually minimal IESG review is necessary in the case of a submission
from a WG intended as an Informational or Experimental RFC. More from a WG intended as an Informational or Experimental RFC. More
extensive review is undertaken in the case of standards-track extensive review is undertaken in the case of standards-track
documents. documents.
Prior to the IESG beginning their deliberations, IETF Secretariat Prior to the IESG beginning their deliberations on standards-track
will issue a "Last-Call" to the IETF mailing list. (See [1]) This documents, IETF Secretariat will issue a "Last-Call" to the IETF
Last Call will announce the intention of the IESG to consider the mailing list. (See [1]) This Last Call will announce the intention
document, and it will solicit final comments from the IETF within a of the IESG to consider the document, and it will solicit final
period of two weeks. It is important to note that a Last-Call is comments from the IETF within a period of two weeks. It is important
intended as a brief, final check with the Internet community, to make to note that a Last-Call is intended as a brief, final check with the
sure that no important concerns have been missed or misunderstood. Internet community, to make sure that no important concerns have been
The Last-Call should not serve as a more general, in-depth review. missed or misunderstood. The Last-Call should not serve as a more
general, in-depth review.
The IESG review takes into account responses to the Last-Call and The IESG review takes into account responses to the Last-Call and
will lead to one of these possible conclusions: will lead to one of these possible conclusions:
1. The document is accepted as is for the status requested. 1. The document is accepted as is for the status requested.
This fact will be announced by the IETF Secretariat to the IETF This fact will be announced by the IETF Secretariat to the IETF
mailing list and to the RFC Editor. mailing list and to the RFC Editor.
2. The document is accepted as-is but not for the status requested. 2. The document is accepted as-is but not for the status requested.
This fact will be announced by the IETF Secretariat to the IETF This fact will be announced by the IETF Secretariat to the IETF
mailing list and to the RFC Editor. (see [1] for more details) mailing list and to the RFC Editor. (see [1] for more details)
 End of changes. 22 change blocks. 
60 lines changed or deleted 74 lines changed or added

This html diff was produced by rfcdiff 1.48. The latest version is available from http://tools.ietf.org/tools/rfcdiff/