rfc2418.txt

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

   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.  IETF
   Plenary meetings are the primary venue for these face-to-face working
   group sessions, and it is common (though not required) that active
   "interim" face-to-face meetings, telephone conferences, or video
   conferences may also be held.  Interim meetings are subject to the
   same rules for advance notification, reporting, open participation,
   and process, which apply to other working group meetings.

   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

   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



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


   participants.  In determining the balance, the WG must ensure that
   its process does not serve to exclude contribution by email-only
   participants.  Decisions reached during a face-to-face meeting about
   topics or issues which have not been discussed on the mailing list,
   or are significantly different from previously arrived mailing list
   consensus MUST be reviewed on the mailing list.

   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
   facilitate schedule coordination for WGs requiring the same set of
   experts.

   The application for a WG session at an IETF meeting MUST be made to
   the IETF Secretariat at the address [e-mail].  Some Area
   Directors may want to coordinate WG sessions in their area and
   request that time slots be coordinated through them.  If this is the
   case it will be noted in the IETF meeting announcement. A WG
   scheduling request MUST contain:

   - The working group name and full title;
   - The amount of time requested;
   - The rough outline of the WG agenda that is expected to be covered;
   - The estimated number of people that will attend the WG session;
   - Related WGs that should not be scheduled for the same time slot(s);
     and
   - Optionally a request can be added for the WG session to be
     transmitted over the Internet in audio and video.

   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, or who, in the opinion of the Chair is
   disrupting the WG process.  The Chair should consult with the Area
   Director(s) if the individual persists in disruptive behavior.

   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.





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


   Many working group participants hold that mailing list discussion is
   the best place to consider and resolve issues and make decisions. The
   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.

   As with face-to-face sessions occasionally one or more individuals
   may engage in behavior on a mailing list which disrupts the WG's
   progress.  In these cases the Chair should attempt to discourage the
   behavior by communication directly with the offending individual
   rather than on the open mailing list.  If the behavior persists then
   the Chair must involve the Area Director in the issue.  As a last
   resort and after explicit warnings, the Area Director, with the
   approval of the IESG, may request that the mailing list maintainer
   block the ability of the offending individual to post to the mailing
   list. (If the mailing list software permits this type of operation.)
   Even if this is done, the individual must not be prevented from
   receiving messages posted to the list.  Other methods of mailing list
   control may be considered but must be approved by the AD(s) and the
   IESG.

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 a show of hands, humming, or any other means on
   which the WG agrees (by rough consensus, of course).  Note that 51%
   of the working group does not qualify as "rough consensus" and 99% is
   better than rough.  It is up to the Chair to determine if rough
   consensus has been reached.

   It can be particularly challenging to gauge the level of consensus on
   a mailing list.  There are two different cases where a working group
   may be trying to understand the level of consensus via a mailing list
   discussion. But in both cases the volume of messages on a topic is
   not, by itself, a good indicator of consensus since one or two
   individuals may be generating much of the traffic.

   In the case where a consensus which has been reached during a face-
   to-face meeting is being verified on a mailing list the people who
   were in the meeting and expressed agreement must be taken into
   account.  If there were 100 people in a meeting and only a few people



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


   on the mailing list disagree with the consensus of the meeting then
   the consensus should be seen as being verified.  Note that enough
   time should be given to the verification process for the mailing list
   readers to understand and consider any objections that may be raised
   on the list.  The normal two week last-call period should be
   sufficient for this.

   The other case is where the discussion has been held entirely over
   the mailing list.  The determination of the level of consensus may be
   harder to do in this case since most people subscribed to mailing
   lists do not actively participate in discussions on the list. It is
   left to the discretion of the working group chair how to evaluate the
   level of consensus.  The most common method used is for the working
   group chair to state what he or she believes to be the consensus view
   and. at the same time, requests comments from the list about the
   stated conclusion.

   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 decide 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;

   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;





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


   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

   Disputes are possible at various stages during the IETF process. As
   much as possible the process is designed so that compromises can be
   made, and genuine consensus achieved; however, there are times when
   even the most reasonable and knowledgeable people are unable to
   agree.  To achieve the goals of openness and fairness, such conflicts
   must be resolved by a process of open review and discussion.

   Formal procedures for requesting a review of WG, Chair, Area Director
   or IESG actions and conducting appeals are documented in The Internet
   Standards Process [1].

4. Working Group Termination

   Working groups are typically chartered to accomplish a specific task
   or tasks.  After the tasks are complete, the group will be disbanded.
   However, if a WG produces a Proposed or Draft Standard, the WG will
   frequently become dormant rather than disband (i.e., the WG will no
   longer conduct 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, or if the assumptions
   which that work was based have been modified in discussion or by
   experience, the Area Director, in consultation with the working group
   can either:

   1. Recharter to refocus its tasks,
   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 (see section 3.4).

5. Rechartering a Working Group

   Updated milestones are renegotiated with the Area Director and the
   IESG, as needed, and then are submitted to the IESG Secretariat:
   [e-mail].



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


   Rechartering (other than revising milestones) a working group follows
   the same procedures that the initial chartering does (see section 2).
   The revised charter must be submitted to the IESG and IAB for
   approval.  As with the initial chartering, the IESG may approve new
   charter as-is, it may request that changes be made in the new charter
   (including having the Working Group continue to use the old charter),
   or it may decline to approve the rechartered working group.  In the
   latter case, the working group is disbanded.

6. 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.  The Area
   Director must agree to the specific people performing the WG Chair,
   and Working Group Consultant roles, and they serve at the discretion
   of the Area Director.

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

   The Chair has the responsibility and the authority to make decisions,
   on behalf of the working group, regarding all matters of working
   group process and staffing, in conformance with the rules of the
   IETF.  The AD has the authority and the responsibility to assist in
   making those decisions at the request of the Chair or when