GENWiki

Premier IT Outsourcing and Support Services within the UK

User Tools

Site Tools

Problem, Formatting or Query -  Send Feedback

Was this page helpful?-10+1


rfc:rfc1603

Network Working Group E. Huizer Request for Comments: 1603 SURFnet bv Category: Informational D. Crocker

                                                Silicon Graphics, Inc.
                                                            March 1994
                         IETF Working Group
                     Guidelines and Procedures

Status of this Memo

 This memo provides information for the Internet community.  This memo
 does not specify an Internet standard of any kind.  Distribution of
 this memo is unlimited.

Abstract

 The Internet Engineering Task Force (IETF) has responsibility for
 developing and reviewing specifications intended as Internet
 Standards. IETF activities are organized into working groups (WGs).
 This document describes the guidelines and procedures for formation
 and operation of IETF working groups. It describes the formal
 relationship between IETF participants WG and the Internet
 Engineering Steering Group (IESG). The basic duties of IETF
 participants, including WG Chair and IESG Area Directors are defined.

Table of Contents

 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. INTRODUCTION

 This document defines guidelines and procedures for Internet
 Engineering Task Force working groups.  The Internet is a loosely-
 organized international collaboration of autonomous, interconnected
 networks; it supports host-to-host communication through voluntary
 adherence to open protocols and procedures defined by Internet
 Standards, a collection of which are commonly known as "the TCP/IP
 protocol suite". The Internet Standards Process is defined in [1].
 Development and review of potential Internet Standards from all
 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 the
 technology used on it. The IETF is managed by its Internet
 Engineering Steering Group (IESG) whose membership includes an IETF
 Chair, responsible for oversight of general IETF operations, and Area
 Directors, each of whom is responsible for a set of IETF activities
 and working groups. The IETF Executive Director and IESG Secretary
 are ex-officio participants, as are the IAB Chair and a designated
 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 name
 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. An
 advisory group is formed by an Area Director (AD) and comprises
 experienced members of the IETF and technical community represented
 by the area.  A small IETF Secretariat provides staff and
 administrative support for the operation of the IETF.
 The primary activities of the IETF are performed by committees 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.
 There is no formal membership in the IETF.  Participation is open to
 all.  This participation may be by on-line contribution, attendance
 at face-to-face sessions, or both.  Anyone from the Internet
 community who has the time and interest is urged to participate in
 IETF meetings and any of its on-line working group discussions.
 Participation is by individual technical contributors, rather than by
 formal representatives of organizations.
 This document defines procedures and guidelines for formation and
 operation of working groups in the IETF. It defines the relations of
 working groups to other bodies within the IETF. The duties of working
 group Chairs and Area Directors with respect to the operation of the
 working group are also defined.  The document uses: "shall", "will",
 "must" and "is required" where it describes steps in the process that
 are essential, and uses: "suggested", "should" and "may" are where
 guidelines are described that are not essential, but are strongly
 recommended to help smooth WG operation.

1.1. IETF approach to standardization

 The reader is encouraged to study The Internet Standards Process [1].
 Familiarity with this document is essential for a complete
 understanding of the philosophy, procedures and guidelines described
 in this document.
 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.
   ...

Huizer & Crocker [Page 3] RFC 1603 IETF Working Group Guidelines March 1994

   "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
   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 due to the copy-and-paste function of a 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

Huizer & Crocker [Page 4] RFC 1603 IETF Working Group Guidelines March 1994

 Cerf [7] from whom we borrowed the description of the IETF; and Greg
 Vaudreuil and Steve Coya who provided several paragraphs.  Also, John
 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) FORMATION

 IETF working groups (WGs) are the primary mechanism for development
 of IETF specifications and guidelines, many of which are intended as
 standards or recommendations. A working group may be established at
 the initiative of an Area Director (AD) or it may be initiated by an
 individual or group of individuals. Anyone interested in creating an
 IETF working group must obtain the advice and consent of the
 appropriate IETF Area Director under whose direction the working
 group would fall and must proceed through the formal steps detailed
 in this section.
 A working group is typically created to address a specific problem or
 produce a deliverable (a guideline, standards specification, etc.)
 and is expected to be short-lived in nature.  Upon completion of its
 goals and achievement of its objectives, the working group as a unit
 is terminated. Alternatively at the discretion of the IESG, Area
 Director, the WG Chair and the WG participants, the objectives or
 assignment of the working group may be extended by enhancing or
 modifying the working group's charter.

2.1. Criteria for formation

 When determining whether it is appropriate to create a working group,
 the Area Director and the IESG will consider several issues:
  1. Are the issues that the working group plans to address clear

and relevant for the Internet community?

  1. Are the goals specific and reasonably achievable, and

achievable within the time frame specified by the

      milestones?
  1. What are the risks and urgency of the work, to determine the

level of attention required?

  1. Do the working group's activities overlap with those of

another working group? If so, it may still be appropriate to

      create the working group, but this question must be
      considered carefully by the Area Directors as subdividing
      efforts often dilutes the available technical expertise.

Huizer & Crocker [Page 5] RFC 1603 IETF Working Group Guidelines March 1994

  1. Is there sufficient interest and expertise in the working

group's topic with at least several people willing to expend

      the effort to produce the desired result (e.g., a protocol
      specification)?  Working groups require considerable effort,
      including management of the working group process, editing
      of working group documents, and contribution to the document
      text.  IETF experience suggests that these roles typically
      cannot all be handled by one person; four or five active
      participants are typically required.
  1. Does a base of interested consumers (end users) appear to

exist for the planned work? Consumer interest can be

      measured by participation of end-users within the IETF
      process, as well as by less direct means.
 Considering the above criteria, the Area Director will decide whether
 to pursue the formation of the group through the chartering process.

2.2. Charter

 The formation of a working group requires a charter which is
 primarily negotiated between a prospective working group Chair and
 the relevant Area Director, although final approval is made by the
 IESG and all charters are reviewed by the Internet Architecture Board
 (IAB).  A charter is a contract between a working group and the IETF
 to perform a set of tasks.  A charter:
 1.   Lists relevant administrative aspects of the working group;
 2.   Specifies the direction or objectives of the working group
      and describes the approach that will be taken to achieve the
      goals; and
 3.   Enumerates a set of milestones together with time frames for
      their completion.
 When the prospective Chair, the Area Director and the IESG Secretary
 are satisfied with the charter form and content, it becomes the basis
 for forming a working group. The AD may require an initial draft of a
 charter to be available prior to holding an exploratory Birds of a
 Feather (BOF) meeting, as described below.
 Charters may be renegotiated periodically to reflect the current
 status, organization or goals of the working group. Hence, a charter
 is a contract between the IETF and the working group which is
 committing to meet explicit milestones and delivering concrete
 "products".

Huizer & Crocker [Page 6] RFC 1603 IETF Working Group Guidelines March 1994

 Specifically, each charter consists of 6 sections:
 Working group name
      A working group name should be reasonably descriptive or
      identifiable. Additionally, the group shall define an
      acronym (maximum 8 printable ASCII characters) to reference
      the group in the IETF directories, mailing lists, and
      general documents.
 Chair(s)
      The working group may have one or two Chair(s) to perform
      the administrative functions of the group. The email
      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 is
      affiliated and the name and electronic mail address of the
      associated Area Director.
 Mailing list
      It is required that an IETF working group have a general
      Internet mailing list.  Most of the work of an IETF working
      group will be conducted that.
      The charter shall include:
           The address to which a participant sends a
           subscription request and the procedures to follow when
           subscribing,
           The address to which a participant sends submissions
           and special procedures, if any, and
           The location of the mailing list archive, if any.
      A message archive should be maintained in a public place
      which can be accessed via FTP. The ability to retrieve from
      the archive via electronic mail requests also is
      recommended. Additionally, the address:
           ietf-archive@cnri.reston.va.us
      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 on
      a host directly connected to the IP Internet to facilitate
      use of the SMTP expansion command (EXPN) and to allow mail
      archive access via FTP, gopher and the like in keeping with
      the general IETF rule for openness. If this is not possible,
      the message archive and membership of the list must be made
      available to those who request it by sending a message to
      the list-request alias.
 Description of working group
 The focus and intent of the group shall be set forth briefly. By
 reading this section alone, an individual should be able to decide
 whether this group is relevant to their own work. The first paragraph
 must give a brief summary of the problem area, basis, goal(s) and
 approach(es) planned for the working group.  This paragraph will
 frequently be used as an overview of the working group's effort.
 The terms "they", "them" and "their" are used in this document as
 third-person singular pronouns.
      To facilitate evaluation of the intended work and to provide
      on-going guidance to the working group, the charter shall
      describe the problem being solved and shall discuss
      objectives and expected impact with respect to:
  1. Architecture
  2. Operations
  3. Security
  4. Network management
  5. Transition (where applicable)
 Goals and milestones
      The working group charter must establish a timetable for
      work. While this may be re-negotiated over time, the list
      of milestones and dates facilitates the Area Director's
      tracking of working group progress and status, and it is
      indispensable to potential participants identifying the
      critical moments for input. Milestones shall consist of
      deliverables that can be qualified as showing specific
      achievement; e.g., "Internet-Draft finished" is fine, but
      "discuss via email" is not. It is helpful to specify
      milestones for every 3-6 months, so that progress can be
      gauged easily.  This milestone list is expected to be
      updated periodically. Updated milestones are re-negotiated
      with the Area Director and the IESG, as needed, and then are
      submitted to the IESG Secretary:

Huizer & Crocker [Page 8] RFC 1603 IETF Working Group Guidelines March 1994

           IESG-secretary@cnri.reston.va.us
 An example of a WG charter is in Appendix A.

2.3. Charter review & approval

 Working groups often comprise technically competent participants who
 are not familiar with the history of Internet architecture or IETF
 processes.  This can, unfortunately, lead to good working group
 consensus about a bad design.  To facilitate working group efforts,
 an Area Director may assign an Area Consultant from among the ranks
 of senior IETF participants.  (Area Consultants are described in the
 section of Staff Roles.)  At the discretion of the AD, approval of a
 new WG may be withheld in the absence of sufficient Consultant
 resources.
 Once the Area Director (and the Area Directorate, as the AD deems
 appropriate) has approved the working group charter, the charter is
 submitted for review by the IAB and approval by the Internet
 Engineering Steering Group using the criteria described previously.
 The Internet Architecture Board (IAB) will review the charter of the
 proposed WG to determine the relationship of the proposed work to the
 overall architecture of the Internet Protocol Suite.
 The approved charter is submitted to the IESG Secretary who records
 and enters the information into the IETF tracking database and
 returns the charter in a form formatted by the database.  The working
 group is announced to the IETF mailing list by the IESG Secretary.

2.4. Birds of a feather (BOF)

 Often it is not clear whether an issue merits the formation of a
 working group. To facilitate exploration of the issues the IETF
 offers the possibility of a Birds of a Feather (BOF) session, as well
 as the early formation of an email list for preliminary discussion.
 Alternatively, a BOF may serve as a forum for a single presentation
 or discussion, without any intent to form a working group.
 A BOF is a session at an IETF meeting which permits "market research"
 and technical "brainstorming".  Any individual may request permission
 to hold a BOF on a subject. The request must be filed with the
 relevant Area Director. 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.

Huizer & Crocker [Page 9] RFC 1603 IETF Working Group Guidelines March 1994

 The AD may require the conduct of email discussion, prior to
 authorizing a BOF.  This permits initial exchanges and sharing of
 framework, vocabulary and approaches, in order to make the time spent
 in the BOF more productive.  The AD may require that a BOF be held,
 prior to establishing a working group, and the AD may require that
 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:
  1. There was enough interest and focus in the subject to

warrant the formation of a WG;

  1. The discussion came to a fruitful conclusion, with results

to be written down and published, however there is no need

      to establish a WG; or
  1. 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 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.
  1. 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 IESG
      Secretary for inclusion in the Proceedings.
  1. A BOF may be held only once (ONE slot at one IETF Plenary

meeting).

  1. Under unusual circumstances an Area Director may, at their

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.
  1. BOFs are not permitted to meet three times.

Huizer & Crocker [Page 10] RFC 1603 IETF Working Group Guidelines March 1994

  1. A BOF may be held for single-event discussion, or may pursue

creation of normal IETF working groups for on-going

      interactions and discussions. When the request for a BOF
      comes from a formally-constituted group, rather than from an
      individual, the rules governing the handling of the request
      are the same as for all other BOFs and working groups.
  1. When necessary, WGs will be given priority for meeting space

over BOFs.

3. WORKING GROUP OPERATION

 The IETF has basic requirements for open and fair participation and
 for thorough consideration of technical alternatives.  Within those
 constraints, working groups are autonomous and each determines most
 of the details of its own operation with respect to session
 participation, reaching closure, etc. The core rule for operation is
 that acceptance or agreement is achieved via working group "rough
 consensus".
 A number of procedural questions and issues will arise over time, and
 it is the function of the Working Group Chair to manage the group
 process, keeping in mind that the overall purpose of the group is to
 make progress towards reaching rough consensus in realizing the
 working group's goals and objectives.
 There are few hard and fast rules on organizing or conducting working
 group activities, but a set of guidelines and practices have evolved
 over time that have proven successful. These are listed here, with
 actual choices typically determined by the working group participants
 and the Chair.

3.1. Session planning

 For coordinated, structured WG interactions, the Chair must publish a
 draft agenda well in advance of the actual session. The agenda needs
 to contain at least:
  1. The items for discussion;
  1. The estimated time necessary per item; and
  1. A clear indication of what documents the participants will

need to read before the session in order to be well

      prepared.

Huizer & Crocker [Page 11] RFC 1603 IETF Working Group Guidelines March 1994

 Publication shall include sending a copy to the working group mailing
 list and to the IETF-Announce list.  Notices for the IETF-Announce
 list should be sent to:
        ietf-announce-post@cnri.reston.va.us
 All working group actions shall be taken in a public forum, and wide
 participation is encouraged.   A working group will conduct much of
 its business via electronic mail distribution lists but may meet
 periodically to discuss and review task status and progress, to
 resolve specific issues and to direct future activities. It is
 common, but not required, that a working group will meet at the
 trimester IETF Plenary events. Additionally, interim sessions may be
 scheduled for telephone conference, video teleconference, or for
 face-to-face (physical) sessions.
 All working group sessions (including those held outside of the IETF
 meetings) shall be reported by making minutes available.  These
 minutes should include the agenda for the session, an account of the
 discussion including any decisions made, and a list of attendees. The
 Working Group Chair is responsible for insuring that session minutes
 are written and distributed, though the actual task may be performed
 by someone designated by the Working Group Chair. The minutes shall
 be submitted in printable ASCII text for publication in the IETF
 Proceedings, and for posting in the IETF Directories and are to be
 sent to:
                  minutes@cnri.reston.va.us

3.2. Session venue

 Each working group will determine the balance of email and face-to-
 face sessions that is appropriate for achieving its milestones.
 Electronic mail permits the widest participation; face-to-face
 meetings often permit better focus and therefore can be more
 efficient for reaching a consensus among a core of the working group
 participants.  In determining the balance, the WG must ensure that
 its process does not serve to exclude contribution by email-only
 participants.  Also note that decisions reached during IETF meetings
 are NOT final, but must be conveyed to the mailing list to verify WG
 consensus.

IETF Meetings

 If a WG needs a session at an IETF meeting, the Chair must apply for
 time-slots as soon as the first announcement of that IETF meeting is
 made by the IETF Secretariat to the WG-chairs list.  Session time is
 a scarce resource at IETF meetings, so placing requests early will

Huizer & Crocker [Page 12] RFC 1603 IETF Working Group Guidelines March 1994

 facilitate schedule coordination for WGs requiring the same set of
 experts.
 The application for a WG session at an IETF meeting shall be made to
 the IETF Secretariat.  Alternatively some Area Directors may want to
 coordinate WG sessions in their area and request that time slots be
 coordinated through them.  After receiving all requests for time
 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 the
 area. After approval it will be sent to the IETF Secretariat.
 An application must contain:
  1. The amount of time requested;
  1. The rough outline of the WG agenda that is expected to be

covered;

  1. The estimated number of people that will attend the WG

session;

  1. Related WGs that must not be scheduled for the same time

slot(s); and

  1. Individuals whose attendance is desired.
 The Secretariat allots time slots on the basis of the session-agenda
 made by the Area Director(s). If the proposed session- agenda for an
 area does not fit into the IETF meeting-agenda, the IETF Secretariat
 will adjust it to fit, after consulting the Area Director(s) and the
 relevant chairs.  The Secretariat will then form a draft session-
 agenda and distribute it among the Working Group Chairs for final
 approval.
 NOTE:  While open discussion and contribution is essential to working
 group success, the Chair is responsible for ensuring forward
 progress.  When acceptable to the WG, the Chair may call for
 restricted participation (but not restricted attendance!) at IETF
 working group sessions for the purpose of achieving progress. The
 Working Group Chair then has the authority to refuse to grant the
 floor to any individual who is unprepared or otherwise covering
 inappropriate material.

On-line

 It can be quite useful to conduct email exchanges in the same manner
 as a face-to-face session, with published schedule and agenda, as
 well as on-going summarization and consensus polling.

Huizer & Crocker [Page 13] RFC 1603 IETF Working Group Guidelines March 1994

 Many working group participants hold that mailing list discussion is
 the best place to consider and resolve issues and make decisions.
 Choice of operational style is made by the working group itself.  It
 is important to note, however, that Internet email discussion is
 possible for a much wider base of interested persons than is
 attendance at IETF meetings, due to the time and expense required to
 attend.

3.3. Session management

 Working groups make decisions through a "rough consensus" process.
 IETF consensus does not require that all participants agree although
 this is, of course, preferred.  In general the dominant view of the
 working group shall prevail.  (However, it must be noted that
 "dominance" is not to be determined on the basis of volume or
 persistence, but rather a more general sense of agreement.)
 Consensus can be determined by balloting, humming, or any other means
 on which the WG agrees (by rough consensus, of course).
 The challenge to managing working group sessions is to balance the
 need for open and fair consideration of the issues against the need
 to make forward progress.  The working group, as a whole, has the
 final responsibility for striking this balance.  The Chair has the
 responsibility for overseeing the process but may delegate direct
 process management to a formally-designated Facilitator.
 It is occasionally appropriate to revisit a topic, to re-evaluate
 alternatives or to improve the group's understanding of a relevant
 decision.  However, unnecessary repeated discussions on issues can be
 avoided if the Chair makes sure that the main arguments in the
 discussion (and the outcome) are summarized and archived after a
 discussion has come to conclusion. It is also good practice to note
 important decisions/consensus reached by email in the minutes of the
 next 'live' session, and to summarize briefly the decision-making
 history in the final documents the WG produces.
 To facilitate making forward progress, a Working Group Chair may wish
 to direct a discussion to reject or defer the input from a member,
 based upon the following criteria:
 Old
   The input pertains to a topic that already has been resolved
   and is redundant with information previously available;

Huizer & Crocker [Page 14] RFC 1603 IETF Working Group Guidelines March 1994

 Minor
   The input is new and pertains to a topic that has already
   been resolved, but it is felt to be of minor import to the
   existing decision;
 Timing
   The input pertains to a topic that the working group has not
   yet opened for discussion; or
 Scope
   The input is outside of the scope of the working group
   charter.

3.4. Contention and appeals overview

 In the course of group design processes, strife happens.  Strife and
 contention are particularly likely when working groups comprise many
 constituencies.  On the other hand differences in view are vital to
 the success of the IETF and healthy debate is encouraged.  Sometimes
 debates degenerate into something akin to warfare.  For these
 circumstances, the IETF has an extensive review and appeals process.
 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 participant 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 four levels, each in turn:
 WG Chair
   An appeal must begin with the management closest to the
   operation of the working group, even if the concern applies
   to their own handling of working group process.

Huizer & Crocker [Page 15] RFC 1603 IETF Working Group Guidelines March 1994

 Area
   If discussion and review with the WG Chair do not produce a
   satisfactory result, the complainant may bring their concern
   to the cognizant Area Director.
 IESG
   If a concerned party is not satisfied with the results of
   the area-level review, then they may bring the matter to the
   IESG Chair and the Area Director for Standards & Processes.
   The IESG Chair and the Standards & Processes AD will bring
   the issue before the full IESG for an additional review and
   will report the resolution back to the parties.
 IAB
   The IAB provides a final opportunity to appeal the results
   of previous reviews.   If a concerned party does not accept
   the outcome of the IESG review, then they may take their
   concern to the IAB, by contacting the IAB Chair.
 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
 participants; continued success requires continued attention to
 working group process.

4. WORKING GROUP TERMINATION

 Working groups are typically chartered to accomplish a specific task.
 After that task is complete, the group will be disbanded.  However if
 a WG produces a Proposed or Draft Standard, the WG will become
 dormant rather than disband (i.e., the WG will no longer conduct

Huizer & Crocker [Page 16] RFC 1603 IETF Working Group Guidelines March 1994

 formal activities, but the mailing list will remain available to
 review the work as it moves to Draft Standard and Standard status.)
 If, at some point, it becomes evident that a working group is unable
 to complete the work outlined in the charter, the group, in
 consultation with its Area Director can either:
 1.   Recharter to refocus on a smaller task,
 2.   Choose new Chair(s), or
 3.   Disband.
 If the working group disagrees with the Area Director's choice, it
 may appeal to the IESG.

5. STAFF ROLES

 Working groups require considerable care and feeding.  In addition to
 general participation, successful working groups benefit from the
 efforts of participants filling specific functional roles.

5.1. WG Chair

 The Working Group Chair is concerned with making forward progress
 through a fair and open process, and has wide discretion in the
 conduct of WG business.  The Chair must ensure that a number of tasks
 are performed, either directly or by others assigned to the tasks.
 This encompasses at the very least the following:
 Ensure WG process and content management
   The Chair has ultimate responsibility for ensuring that a
   working group achieves forward progress and meets its
   milestones.  For some working groups, this can be
   accomplished by having the Chair perform all management-
   related activities.  In other working groups -- particularly
   those with large or divisive participation -- it is helpful
   to allocate process and/or secretarial functions to other
   participants.  Process management pertains strictly to the
   style of working group interaction and not to its content.
   It ensures fairness and detects redundancy.  The secretarial
   function encompasses document editing.  It is quite common
   for a working group to assign the task of specification
   Editor to one or two participants.  Often, they also are
   part of the design team, described below.

Huizer & Crocker [Page 17] RFC 1603 IETF Working Group Guidelines March 1994

 Moderate the WG email list
   The Chair should attempt to ensure that the discussions on
   this list are relevant and that they converge to consensus
   agreements. The Chair should make sure that discussions on
   the list are summarized and that the outcome is well
   documented (to avoid repetition).  The Chair also may choose
   to schedule organized on-line "sessions" with agenda and
   deliverables.  These are structured as true meetings,
   conducted over the course of several days (to allow
   participation across the Internet.)  Participants are
   expected to allocate time to the meeting, usually in the
   range of 1-2 hours per day of the "meeting".
 Organize, prepare and chair face-to-face & on-line formal sessions
   The Chair should plan and announce sessions well in advance.
   (See section on Session Planning for exact procedures.)
 Communicate results of sessions
   The Chair and/or Secretary must ensure that minutes of a
   session are taken and that an attendance list is circulated.
   See the section on Session Documents for detailed
   procedures.
   Immediately after a session, the WG Chair must immediately
   provide the Area Director with a very short report
   (approximately one paragraph, via email) on the session.
   This is used in an Area Report as presented in the
   Proceedings of each IETF meeting.
 Distribute the work
   Of course each WG will have participants who may not be able
   (or want) to do any work at all. Most of the time the bulk
   of the work is done by a few dedicated participants. It is
   the task of the Chair to motivate enough experts to allow
   for a fair distribution of the workload.
 Document development
   Working groups produce documents and documents need authors.
   The Chair will make sure that authors of WG documents
   incorporate changes as discussed by the WG.  See the section
   on Session Documents for details procedures.

Huizer & Crocker [Page 18] RFC 1603 IETF Working Group Guidelines March 1994

 Document publication
   The Chair and/or Secretary will work with the RFC Editor to
   ensure document conformance with RFC publication
   requirements and to coordinate any editorial changes
   suggested by the RFC Editor.  A particular concern is that
   all participants are working from the same version of a
   document at the same time.

5.2. WG Editor/Secretary

 Taking minutes and editing working group documents often is performed
 by a specifically-designated participant or set of participants.  In
 this role, the Editor's job is to record WG decisions, rather than to
 perform basic specification.

5.3. WG Facilitator

 When meetings tend to become distracted or divisive, it often is
 helpful to assign the task of "process management" to one
 participant.  Their job is to oversee the nature, rather than the
 content, of participant interactions.  That is, they attend to the
 style of the discussion and to the schedule of the agenda, rather
 than making direct technical contributions themselves.

5.4. Design teams

 The majority of the detailed specification effort within a working
 group may be done by self-selecting sub-groups, called design teams,
 with the (implicit or explicit) approval of the working group.  The
 team may hold closed sessions for conducting portions of the
 specification effort. In some cases design teams are necessary to
 make forward progress when preparing a document.  All work conducted
 by a design team must be available for review by all working group
 participants and the design team must be responsive to the direction
 of the working group's consensus.

5.5. Area Consultant

 At the discretion of the AD, a Consultant may be assigned to a
 working group.  Consultants are senior participants in the IETF
 community.  They have technical background appropriate to the WG and
 experience in Internet architecture and IETF process.

Huizer & Crocker [Page 19] RFC 1603 IETF Working Group Guidelines March 1994

5.6. Area Director

 Area Directors are responsible for ensuring that working groups in
 their area produce coherent, coordinated, architecturally consistent
 and timely output as a contribution to the overall results of the
 IETF. This very general description encompasses at the very least
 these detailed tasks related to working groups:
 Area planning
   The Area Director determines activities appropriate to the
   area.  This may include initiating working groups directly,
   rather than waiting for proposals from IETF participants.
 Coordination of WGs
   The Area Director coordinates the work done by the various
   WGs within (and sometimes even outside) the relevant area.
 IETF Meeting Schedule
   The Director tries to coordinate sessions in such a way that
   experts can attend the relevant sessions with a minimum of
   overlap and gaps between sessions. (See section on WG
   sessions for details.)
 Reporting
   The Area Director reports to the IETF on progress in the
   area.
 Reviewing
   The Area Director may appoint independent reviewers prior to
   document approval. The Area Director tracks the progress of
   documents from the area through the IESG review process, and
   report back on this to the WG Chair(s).
 Progress tracking
   The Area Director tracks and manages the progress of the
   various WGs with the aid of a regular status report on
   documents and milestones that is generated by the IESG
   Secretary. The Area Director forwards this report to the WG
   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 Directorate

 An area directorate consists of senior members of the technical
 community and are appointed by the Area Director who then tasks them
 with technical oversight and review of specific area activities.  An
 Area Director chairs the directorate.  At the request of the AD,
 directorate members conduct specification reviews and may be assigned
 as Area Consultants, to provide architectural assistance.

6. WORKING GROUP DOCUMENTS

6.1. Session documents

 All relevant documents for a session (including the final agenda)
 should be published and available at least two weeks before a session
 starts.
 It is strongly suggested that the WG Chair make sure that an
 anonymous FTP directory be available for the upcoming session.  All
 relevant documents (including the final 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.

6.2. IETF meeting document archive

 In preparing for an IETF meeting it is helpful to have ready access
 to all documents that are being reviewed. While documents usually are
 placed in the internet-drafts Internet Repository or in the
 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 are
 relevant for the up-coming IETF meeting.  This document database will
 be removed two weeks after the IETF meeting.
 The completeness of this archive depends on the authors and working
 group chairs submitting the documents.  Each WG Chair is requested to
 submit the agenda to this archive.
 Structure of the archive:
 On ds.internic.net documents will be stored under the appropriate
 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-docs
 Each area will also have a directory called bof where a document to
 be discussed in a BOF meeting will be placed.  At the area level a
 directory called plenary will be created to hold documents or
 presentation material related to a plenary session.  Any filename
 conflicts will be resolved by the InterNIC's administrator and the
 submitter will be informed via electronic mail.  Example:
        /pub/current-ietf-docs/app/osids
        /pub/current-ietf-docs/int/sip
 Access via anonymous FTP:
 Anonymous FTP to ds.internic.net and change directory to
        /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 *** IETF
 One may use the public-access gopher client by:
        telnet gopher.internic.net
 Submission of documents via anonymous FTP:
 FTP to ds.internic.net and login as anonymous.  Change directory to:
        /incoming/current-ietf-docs
 Put the document using the following filename convention,
        <area>.<wgname>.<filename>
 e.g.:
        plenary.mondayVGs.ps
        app.osids.agenda
        app.osids.internic-talk-VGs.ps

Huizer & Crocker [Page 22] RFC 1603 IETF Working Group Guidelines March 1994

 Note that the names of areas and working groups are their official
 short-form acronyms,
 Submission of documents via electronic mail:
 Send mail to
        admin@ds.internic.net
 with the following subject line:
        IETF - <area>.<wgname>.<filename>
 e.g.:
        IETF - app.osids.agenda
 NOTE:  Instead of sending a fresh copy of an already available
 document, you may ask the InterNIC's administrators to create a link
 to an existing internet-draft/RFC/ID
 NOTE:  If you do not remember your area or working group acronym get
 the file /ftp/ietf/1wg-summary.txt from ds.internic.net via anonymous
 FTP.

6.3. Internet-Drafts (I-D)

 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 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.us
 The format of an Internet-Draft must be the same as for an RFC [2].
 Further, an I-D must contain:
  1. Beginning, standard, boilerplate text which is provided by

the Secretariat;

  1. The I-D filename; and

Huizer & Crocker [Page 23] RFC 1603 IETF Working Group Guidelines March 1994

  1. The expiration date for the I-D.
 Complete specification of requirements for an Internet-Draft are
 found in the file:
        1id-guidelines.txt
 in the internet-drafts directory at an Internet Repository site.

6.4. Request For Comments (RFC)

 The work of an IETF working group usually results in publication of
 one or more documents, as part of the Request For Comments (RFCs) [2]
 series. This series is the archival publication record for the
 Internet community. A document can be written by an individual in a
 working group, by a group as a whole with a designated Editor, or by
 others not involved with the IETF. The designated author need not be
 the group Chair(s).
 NOTE:  The RFC series is a publication mechanism only and publication
 does not determine the IETF status of a document.  Status is
 determined through separate, explicit status labels assigned by the
 IESG on behalf of the IETF.  In other words, the reader is reminded
 that all Internet Standards are published as RFCs, but NOT all RFCs
 specify standards.
 For a description on the various categories of RFCs the reader is
 referred to [1, 4, 5, 6].

6.5. Submission of documents

 When a WG decides that a document is ready for publication, the
 following must be done:
  1. The version of the relevant document as approved by the WG

must be in the Internet-Drafts directory;

  1. The relevant document must be formatted according to RFC

rules [2].

  1. The WG Chair sends email to the relevant Area Director, with

a copy to the IESG Secretary. The mail should contain the

      reference to the document, and the request that it be
      progressed as an Informational, Experimental, Prototype or
      standards-track (Proposed, Draft or Internet Standard) RFC.
 The IESG Secretary will acknowledge receipt of the email.  Unless
 returned to the WG for further development, progressing of the

Huizer & Crocker [Page 24] RFC 1603 IETF Working Group Guidelines March 1994

 document is then the responsibility of the IESG.  After IESG
 approval, responsibility for final disposition is the joint
 responsibility of the RFC Editor and the WG Chair and Editor.

6.6. Review of documents

 Usually in case of a submission intended as an Informational or
 Experimental RFC minimal review is necessary. However, if the WG or
 the RFC Editor thinks that an extensive review is appropriate, the
 Area Director may be asked to conduct one. This review may either be
 done by the AD and other IESG participants or the IESG may ask for an
 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 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 the IESG makes a final decision on a standards-track document,
 the IESG Secretary will issue a "Last Call" to the IETF mailing list.
 This Last Call will announce the intention of the IESG to consider

Huizer & Crocker [Page 25] RFC 1603 IETF Working Group Guidelines March 1994

 the document, and it will solicit final comments from the IETF within
 a period of two weeks.  It is important to note that a Last Call is
 intended as a brief, final check with the Internet community, to make
 sure that no important concerns have been missed or misunderstood.
 The Last Call cannot serve as a more general, in-depth review.

7. SECURITY CONSIDERATIONS

 Security issues are not discussed in this memo.

8. REFERENCES

 [1] Internet Architecture Board and Internet Engineering Steering
     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 to
     the F.Y.I. Notes", RFC 1150, Proteon, USC/Information Sciences
     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", STD
     1, RFC 1600, IAB, March 1994.
 [6] Cerf, V., "The Internet Activities Board", RFC 1160, NRI, May
     1990.

Huizer & Crocker [Page 26] RFC 1603 IETF Working Group Guidelines March 1994

9. AUTHORS' ADDRESSES

     Erik Huizer
     SURFnet bv
     P.O. Box 19035
     3501 DA  Utrecht
     The Netherlands
     Phone: +31 30 310290
     Fax: +31 30 340903
     EMail: Erik.Huizer@SURFnet.nl
     Dave Crocker
     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.com

Huizer & Crocker [Page 27] RFC 1603 IETF Working Group Guidelines March 1994

APPENDIX: SAMPLE WORKING GROUP CHARTER

     Multiparty Multimedia Session Control (mmusic)
      Charter
      Chair(s):
          Eve Schooler  <schooler@isi.edu>
          Abel Weinrib  <abel@bellcore.com>
      Transport Area Director(s)
          Allison Mankin  <mankin@cmf.nrl.navy.mil>
      Mailing lists:
          General Discussion:confctrl@isi.edu
          To Subscribe:      confctrl-request@isi.edu
          Archive:           venera.isi.edu:~/confctrl/confcrtl.mail
     Description of Working Group:
     The demand for Internet teleconferencing has arrived, yet an
     infrastructure to support this demand is barely in place.
     Multimedia session control, defined as the management and
     coordination of multiple sessions and their multiple users in
     multiple media (e.g., audio, video), is one component of the
     infrastructure.  The Multiparty Multimedia Session Control
     Working Group is chartered to design and specify a protocol to
     perform these functions.
     The protocol will provide negotiation for session membership,
     underlying communication topology and media configuration.  In
     particular, the protocol will support a user initiating a
     multimedia multiparty session with other users ("calling" other
     users) over the Internet by allowing a teleconferencing
     application on one workstation to explicitly rendezvous with
     teleconferencing applications running on remote workstations.
     Defining a standard protocol will enable session-level
     interoperability between different teleconferencing
     implementations.
     The focus of the working group is to design a session negotiation
     protocol that is tailored to support tightly-controlled
     conferences.  The MBONE currently carries primarily loosely-
     controlled sessions, i.e., sessions with little to no interaction
     among members and with no arbitration facility, security, or
     coordination of quality-of-service options for time-critical
     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 that
     provide mechanisms for directly contacting other users to
     initiate a session and for negotiating conference parameters such
     as membership, media encodings and encryption keys.  In addition,
     these sessions should support renegotiation during a session, for
     example to add or delete members or change the media encoding.
     It is possible that the protocol will, in the limiting case, also
     support loosely-controlled sessions.
     The main goal of the working group will be to specify the session
     control protocol for use within teleconferencing software over
     the Internet.  The working group will focus on the aspects of the
     session control problem that are well understood, while keeping
     an eye on evolving research issues.  Toward this end, the working
     group has made an inventory of existing conferencing systems and
     their session control protocols.  The working group will document
     the requirements of the existing prototypes as a basis for the
     protocol development.  The working group will iteratively refine
     the protocol based on implementation and operational experience.
     Furthermore, the working group will coordinate with other efforts
     related to multimedia conferencing, such as directory services
     for cataloguing users and conferences, the RTP and RTCP protocols
     developed by the Audio/Video Transport Working Group, resource
     reservation and management at the network level, and schemes for
     multicast address allocation.
     Goals and Milestones:
          May 93     Hold an on-line working group meeting to discuss
                     the conference control framework, the relevant
                     terminology, a functional taxonomy and how
                     different conversational styles place
                     requirements on session protocols.
          Jun 93     Submit the Conference Session Control Protocol to
                     the IESG for consideration as an Experimental
                     Protocol.
          Aug 93     Post an Internet-Draft describing the Session
                     Control Requirements.
          Nov 93     Post an Internet-Draft of the Session Control
                     Protocol.
          Mar 94     Submit a revised Internet-Draft based on
                     implementation experience.

Huizer & Crocker [Page 29]

/data/webs/external/dokuwiki/data/pages/rfc/rfc1603.txt · Last modified: 1994/03/23 01:33 (external edit)