circumstances warrant such an intervention.   The Chair's responsibility encompasses at 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.  The      Chair is also responsible to ensure that the working group      operates in an open and fair manner.  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 workingBradner                  Best Current Practice                 [Page 16]RFC 2418                Working Group Guidelines          September 1998      group to assign the task of specification Editor to one or two      participants.  Sometimes, they also are part of the design team,      described below.   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 can be      structured as true meetings, conducted over the course of several      days (to allow participation across the Internet).      Organize, prepare and chair face-to-face and on-line formal      sessions.   Plan WG Sessions      The Chair must plan and announce all WG sessions well in advance      (see section 3.1).   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 section      3.1).      Immediately after a session, the WG Chair MUST provide the Area      Director with a very short report (approximately one paragraph,      via email) on the session.   Distribute the workload      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 must make sure that authors of WG documents incorporate      changes as agreed to by the WG (see section 6.3).Bradner                  Best Current Practice                 [Page 17]RFC 2418                Working Group Guidelines          September 1998   Document publication      The Chair and/or Document Editor will work with the RFC Editor to      ensure document conformance with RFC publication requirements [5]      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.   Document implementations      Under the procedures described in [1], the Chair is responsible      for documenting the specific implementations which qualify the      specification for Draft or Internet Standard status along with      documentation about testing of the interoperation of these      implementations.6.2. WG Secretary   Taking minutes and editing working group documents often is performed   by a specifically-designated participant or set of participants.  In   this role, the Secretary's job is to record WG decisions, rather than   to perform basic specification.6.3. Document Editor   Most IETF working groups focus their efforts on a document, or set of   documents, that capture the results of the group's work.  A working   group generally designates a person or persons to serve as the Editor   for a particular document.  The Document Editor is responsible for   ensuring that the contents of the document accurately reflect the   decisions that have been made by the working group.   As a general practice, the Working Group Chair and Document Editor   positions are filled by different individuals to help ensure that the   resulting documents accurately reflect the consensus of the working   group and that all processes are followed.6.4. 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.Bradner                  Best Current Practice                 [Page 18]RFC 2418                Working Group Guidelines          September 19986.5. Design teams   It is often useful, and perhaps inevitable, for a sub-group of a   working group to develop a proposal to solve a particular problem.   Such a sub-group is called a design team.  In order for a design team   to remain small and agile, it is acceptable to have closed membership   and private meetings.  Design teams may range from an informal chat   between people in a hallway to a formal set of expert volunteers that   the WG chair or AD appoints to attack a controversial problem.  The   output of a design team is always subject to approval, rejection or   modification by the WG as a whole.6.6. Working Group Consultant   At the discretion of the Area Director, a Consultant may be assigned   to a working group.  Consultants have specific technical background   appropriate to the WG and experience in Internet architecture and   IETF process.6.7. 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.7.  Working Group Documents7.1. Session documents   All relevant documents to be discussed at a session should be   published and available as Internet-Drafts at least two weeks before   a session starts.  Any document which does not meet this publication   deadline can only be discussed in a working group session with the   specific approval of the working group chair(s).  Since it is   important that working group members have adequate time to review all   documents, granting such an exception should only be done under   unusual conditions.  The final session agenda should be posted to the   working group mailing list at least two weeks before the session and   sent at that time to agenda@ietf.org for publication on the IETF web   site.7.2. Internet-Drafts (I-D)   The Internet-Drafts directory is provided to working groups as a   resource for posting and disseminating in-process copies of working   group documents. This repository is replicated at various locations   around the Internet. It is encouraged that draft documents be postedBradner                  Best Current Practice                 [Page 19]RFC 2418                Working Group Guidelines          September 1998   as soon as they become reasonably stable.   It is stressed here that Internet-Drafts are working documents 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@ietf.org   The format of an Internet-Draft must be the same as for an RFC [2].   Further, an I-D must contain:   - Beginning, standard, boilerplate text which is provided by the     Secretariat on their web site and in the ftp directory;   - The I-D filename; and   - 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.  The organization of the   Internet-Drafts directory is found in the file "1id-organization" in   the Internet-Drafts directory at an Internet Repository site.  This   file also contains the rules for naming Internet-Drafts.  (See [1]   for more information about Internet-Drafts.)7.3. Request For Comments (RFC)   The work of an IETF working group often results in publication of one   or more documents, as part of the Request For Comments (RFCs) [1]   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.   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 [4].7.4. Working Group Last-Call   When a WG decides that a document is ready for publication it may be   submitted to the IESG for consideration. In most cases the   determination that a WG feels that a document is ready for   publication is done by the WG Chair issuing a working group Last-   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   group Last-Call serves the same purpose within a working group thatBradner                  Best Current Practice                 [Page 20]RFC 2418                Working Group Guidelines          September 1998   an IESG Last-Call does in the broader IETF community (see [1]).7.5. Submission of documents   Once that a WG has determined at least rough consensus exists within   the WG for the advancement of a document the following must be done:   - The version of the relevant document exactly as agreed to by the WG     MUST be in the Internet-Drafts directory.   - The relevant document MUST be formatted according to section 7.3.   - The WG Chair MUST send email to the relevant Area Director.  A copy     of the request MUST be also sent to the IESG Secretariat.  The mail     MUST contain the reference to the document's ID filename, and the     action requested.  The copy of the message to the IESG Secretariat     is to ensure that the request gets recorded by the Secretariat so     that they can monitor the progress of the document through the     process.   Unless returned by the IESG to the WG for further development,   progressing of the document is then the responsibility of the IESG.   After IESG approval, responsibility for final disposition is the   joint responsibility of the RFC Editor, the WG Chair and the Document   Editor.8. Review of documents   The IESG reviews all documents submitted for publication as RFCs.   Usually minimal IESG review is necessary in the case of a submission   from a WG intended as an Informational or Experimental RFC. More   extensive review is undertaken in the case of standards-track   documents.   Prior to the IESG beginning their deliberations on standards-track   documents, IETF Secretariat will issue a "Last-Call" to the IETF   mailing list (see [1]). This Last Call will announce the intention of   the IESG to consider the document, and it will solicit final comments   from the IETF within a period of two weeks.  It is important to note   that a Last-Call is intended as a brief, final check with the   Internet community, to make sure that no important concerns have been   missed or misunderstood. The Last-Call should not serve as a more