rfc2418.txt

RFC 的详细文档！

   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 working



Bradner                  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 1998


6.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 Documents

7.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 [e-mail] 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 posted



Bradner                  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: [e-mail]

   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 that



Bradner                  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