rfc1603.txt

著名的RFC文档,其中有一些文档是已经翻译成中文的的.

   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:

             [e-mail]

        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:

        -    Architecture
        -    Operations
        -    Security
        -    Network management
        -    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



             [e-mail]

   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:

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

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

   There is an increasing demand for BOF sessions at IETF meetings.
   Therefore the following rules apply for BOFs:

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

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

   -    A BOF may be held only once (ONE slot at one IETF Plenary
        meeting).

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

   -    BOFs are not permitted to meet three times.









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


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

   -    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:

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






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:

          [e-mail]

   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:

                    [e-mail]

3.2. Session venue