rfc2418.txt

RFC 的详细文档！

   Considering the above criteria, the Area Director(s), using his or
   her best judgement, 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(s), although final approval is made by the
   IESG with advice from 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 information for 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(s), the Area Director and the IETF
   Secretariat are satisfied with the charter form and content, it
   becomes the basis for forming a working group. Note that an Area
   Director MAY require holding an exploratory Birds of a Feather (BOF)
   meeting, as described below, to gage the level of support for a
   working group before submitting the charter to the IESG and IAB for
   approval.

   Charters may be renegotiated periodically to reflect the current
   status, organization or goals of the working group (see section 5).
   Hence, a charter is a contract between the IETF and the working group
   which is committing to meet explicit milestones and delivering
   specific "products".

   Specifically, each charter consists of the following 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.



Bradner                  Best Current Practice                  [Page 6]

RFC 2418                Working Group Guidelines          September 1998


   Chair(s)
      The working group may have one or more Chairs to perform the
      administrative functions of the group. The email address(es) of
      the Chair(s) shall be included.  Generally, a working group is
      limited to two chairs.

   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(s).

   Responsible Area Director
      The Area Director who acts as the primary IESG contact for the
      working group.

   Mailing list
      An IETF working group MUST have a general Internet mailing list.
      Most of the work of an IETF working group will be conducted on the
      mailing list. The working group charter MUST include:

      1. The address to which a participant sends a subscription request
         and the procedures to follow when subscribing,

      2. The address to which a participant sends submissions and
         special procedures, if any, and

      3. The location of the mailing list archive. A message archive
         MUST be maintained in a public place which can be accessed via
         FTP or via the web.

         As a service to the community, the IETF Secretariat operates a
         mailing list archive for working group mailing lists. In order
         to take advantage of this service, working group mailing lists
         MUST include the address "[e-mail]"
         (where "wg_acronym" is the working group acronym) in the
         mailing list in order that a copy of all mailing list messages
         be recorded in the Secretariat's archive.  Those archives are
         located at ftp://ftp.ietf.org/ietf-mail-archive.  For
         robustness, WGs SHOULD maintain an additional archive separate
         from that maintained by the Secretariat.

   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 can be used as an overview of the working group's



Bradner                  Best Current Practice                  [Page 7]

RFC 2418                Working Group Guidelines          September 1998


      effort.

      To facilitate evaluation of the intended work and to provide on-
      going guidance to the working group, the charter must describe the
      problem being solved and should discuss objectives and expected
      impact with respect to:

         - Architecture
         - Operations
         - Security
         - Network management
         - Scaling
         - Transition (where applicable)

   Goals and milestones
      The working group charter MUST establish a timetable for specific
      work items.  While this may be renegotiated 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 (see section 5).

      An example of a WG charter is included as Appendix A.

2.3. Charter review & approval

   Proposed 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 a Consultant from
   among the ranks of senior IETF participants.  (Consultants are
   described in section 6.)  At the discretion of the Area Director,
   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 Area
   Director deems appropriate) has approved the working group charter,
   the charter is submitted for review by the IAB and approval by the
   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



Bradner                  Best Current Practice                  [Page 8]

RFC 2418                Working Group Guidelines          September 1998


   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
   of the working group

   If the IESG approves the formation of the working group it remands
   the approved charter to the IETF Secretariat who records and enters
   the information into the IETF tracking database.  The working group
   is announced to the IETF-announce a by the IETF Secretariat.

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.
   In addition, 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 a relevant
   Area Director who must approve a BOF before it can be scheduled. The
   person who requests the BOF may be asked to serve as Chair of the
   BOF.

   The Chair of the BOF is also responsible for providing a report on
   the outcome of the BOF.  If the Area Director approves, the BOF is
   then scheduled by submitting a request to [e-mail] with copies
   to the Area Director(s). A BOF description and agenda are required
   before a BOF can be scheduled.

   Available time for BOFs is limited, and BOFs are held at the
   discretion of the ADs for an area.  The AD(s) may require additional
   assurances before authorizing a BOF.  For example,

    - The Area Director MAY require the establishment of an open email
      list 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 Area Director MAY require that a BOF be held, prior to
      establishing a working group (see section 2.2).

    - The Area Director MAY require that there be a draft of the WG
      charter prior to holding a BOF.



Bradner                  Best Current Practice                  [Page 9]

RFC 2418                Working Group Guidelines          September 1998


    - The Area Director MAY require that a BOF not be held until an
      Internet-Draft describing the proposed technology has been
      published so it can be used as a basis for discussion in the BOF.

   In general, a BOF on a particular topic is held only once (ONE slot
   at one IETF Plenary meeting). Under unusual circumstances Area
   Directors may, at their discretion, allow a BOF to meet for a second
   time. BOFs are not permitted to meet three times.  Note that all
   other things being equal, WGs will be given priority for meeting
   space over BOFs.  Also, occasionally BOFs may be held for other
   purposes than to discuss formation of a working group.

   Usually the outcome of a BOF will be one of the following:

    - There was enough interest and focus in the subject to warrant the
      formation of a WG;

    - While there was a reasonable level of interest expressed in the
      BOF some other criteria for working group formation was not met
      (see section 2.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

    - There was not enough interest in the subject to warrant the
      formation of a WG.

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".  WG participants should specifically note the
   requirements for disclosure of conflicts of interest in [2].

   A number of procedural questions and issues will arise over time, and
   it is the function of the Working Group Chair(s) 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 has evolved
   over time that have proven successful. These are listed here, with



Bradner                  Best Current Practice                 [Page 10]

RFC 2418                Working Group Guidelines          September 1998


   actual choices typically determined by the working group participants
   and the Chair(s).

3.1. Session planning

   For coordinated, structured WG interactions, the Chair(s) MUST
   publish a draft agenda well in advance of the actual session. The
   agenda should contain at least:

   - The items for discussion;
   - The estimated time necessary per item; and
   - A clear indication of what documents the participants will need to
     read before the session in order to be well prepared.

   Publication of the working group agenda shall include sending a copy
   of the agenda to the working group mailing list and to
   [e-mail].