GENWiki

Premier IT Outsourcing and Support Services within the UK

User Tools

Site Tools


rfc:bcp:bcp25

Table of Contents

[Note that this file is a concatenation of more than one RFC.]

Network Working Group S. Bradner Request for Comments: 2418 Editor Obsoletes: 1603 Harvard University BCP: 25 September 1998 Category: Best Current Practice

                         IETF Working Group
                     Guidelines and Procedures

Status of this Memo

 This document specifies an Internet Best Current Practices for the
 Internet Community, and requests discussion and suggestions for
 improvements.  Distribution of this memo is unlimited.

Copyright Notice

 Copyright (C) The Internet Society (1998).  All Rights Reserved.

Abstract

 The Internet Engineering Task Force (IETF) has responsibility for
 developing and reviewing specifications intended as Internet
 Standards. IETF activities are organized into working groups (WGs).
 This document describes the guidelines and procedures for formation
 and operation of IETF working groups. It also describes the formal
 relationship between IETF participants WG and the Internet
 Engineering Steering Group (IESG) and the basic duties of IETF
 participants, including WG Chairs, WG participants, and IETF Area
 Directors.

Table of Contents

 Abstract .........................................................  1
 1. Introduction ..................................................  2
   1.1. IETF approach to standardization ..........................  4
   1.2. Roles within a Working Group ..............................  4
 2. Working group formation .......................................  4
   2.1. Criteria for formation ....................................  4
   2.2. Charter ...................................................  6
   2.3. Charter review & approval .................................  8
   2.4. Birds of a feather (BOF) ..................................  9
 3. Working Group Operation ....................................... 10
   3.1. Session planning .......................................... 11
   3.2. Session venue ............................................. 11
   3.3. Session management ........................................ 13
   3.4. Contention and appeals .................................... 15

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

 4. Working Group Termination ..................................... 15
 5. Rechartering a Working Group .................................. 15
 6. Staff Roles ................................................... 16
   6.1. WG Chair .................................................. 16
   6.2. WG Secretary .............................................. 18
   6.3. Document Editor ........................................... 18
   6.4. WG Facilitator ............................................ 18
   6.5. Design teams .............................................. 19
   6.6. Working Group Consultant .................................. 19
   6.7. Area Director ............................................. 19
 7. Working Group Documents ....................................... 19
   7.1. Session documents ......................................... 19
   7.2. Internet-Drafts (I-D) ..................................... 19
   7.3. Request For Comments (RFC) ................................ 20
   7.4. Working Group Last-Call ................................... 20
   7.5. Submission of documents ................................... 21
 8. Review of documents ........................................... 21
 9. Security Considerations ....................................... 22
 10. Acknowledgments .............................................. 23
 11. References ................................................... 23
 12. Editor's Address ............................................. 23
 Appendix:  Sample Working Group Charter .......................... 24
 Full Copyright Statement ......................................... 26

1. Introduction

 The Internet, a loosely-organized international collaboration of
 autonomous, interconnected networks, supports host-to-host
 communication through voluntary adherence to open protocols and
 procedures defined by Internet Standards.  There are also many
 isolated interconnected networks, which are not connected to the
 global Internet but use the Internet Standards. Internet Standards
 are developed in the Internet Engineering Task Force (IETF).  This
 document defines guidelines and procedures for IETF working groups.
 The Internet Standards Process of the IETF is defined in [1]. The
 organizations involved in the IETF Standards Process are described in
 [2] as are the roles of specific individuals.
 The IETF is a large, open community of network designers, operators,
 vendors, users, and researchers concerned with the Internet and the
 technology used on it. The primary activities of the IETF are
 performed by committees known as working groups. There are currently
 more than 100 working groups. (See the IETF web page for an up-to-
 date list of IETF Working Groups - http://www.ietf.org.) Working
 groups tend to have a narrow focus and a lifetime bounded by the
 completion of a specific set of tasks, although there are exceptions.

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

 For management purposes, the IETF working groups are collected
 together into areas, with each area having a separate focus.  For
 example, the security area deals with the development of security-
 related technology.  Each IETF area is managed by one or two Area
 Directors (ADs).  There are currently 8 areas in the IETF but the
 number changes from time to time.  (See the IETF web page for a list
 of the current areas, the Area Directors for each area, and a list of
 which working groups are assigned to each area.)
 In many areas, the Area Directors have formed an advisory group or
 directorate.  These comprise experienced members of the IETF and the
 technical community represented by the area.  The specific name and
 the details of the role for each group differ from area to area, but
 the primary intent is that these groups assist the Area Director(s),
 e.g., with the review of specifications produced in the area.
 The IETF area directors are selected by a nominating committee, which
 also selects an overall chair for the IETF.  The nominations process
 is described in [3].
 The area directors sitting as a body, along with the IETF Chair,
 comprise the Internet Engineering Steering Group (IESG). The IETF
 Executive Director is an ex-officio participant of the IESG, as are
 the IAB Chair and a designated Internet Architecture Board (IAB)
 liaison.  The IESG approves IETF Standards and approves the
 publication of other IETF documents.  (See [1].)
 A small IETF Secretariat provides staff and administrative support
 for the operation of the IETF.
 There is no formal membership in the IETF.  Participation is open to
 all.  This participation may be by on-line contribution, attendance
 at face-to-face sessions, or both.  Anyone from the Internet
 community who has the time and interest is urged to participate in
 IETF meetings and any of its on-line working group discussions.
 Participation is by individual technical contributors, rather than by
 formal representatives of organizations.
 This document defines procedures and guidelines for the formation and
 operation of working groups in the IETF. It defines the relations of
 working groups to other bodies within the IETF. The duties of working
 group Chairs and Area Directors with respect to the operation of the
 working group are also defined.  When used in this document the key
 words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD",
 "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" are to be
 interpreted as described in RFC 2119 [6].  RFC 2119 defines the use
 of these key words to help make the intent of standards track
 documents as clear as possible.  The same key words are used in this

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

 document to help smooth WG operation and reduce the chance for
 confusion about the processes.

1.1. IETF approach to standardization

 Familiarity with The Internet Standards Process [1] is essential for
 a complete understanding of the philosophy, procedures and guidelines
 described in this document.

1.2. Roles within a Working Group

 The document, "Organizations Involved in the IETF Standards Process"
 [2] describes the roles of a number of individuals within a working
 group, including the working group chair and the document editor.
 These descriptions are expanded later in this document.

2. Working group formation

 IETF working groups (WGs) are the primary mechanism for development
 of IETF specifications and guidelines, many of which are intended to
 be standards or recommendations. A working group may be established
 at the initiative of an Area Director or it may be initiated by an
 individual or group of individuals. Anyone interested in creating an
 IETF working group MUST obtain the advice and consent of the IETF
 Area Director(s) in whose area the working group would fall and MUST
 proceed through the formal steps detailed in this section.
 Working groups are typically created to address a specific problem or
 to produce one or more specific deliverables (a guideline, standards
 specification, etc.).  Working groups are generally expected to be
 short-lived in nature.  Upon completion of its goals and achievement
 of its objectives, the working group is terminated. A working group
 may also be terminated for other reasons (see section 4).
 Alternatively, with the concurrence of the IESG, Area Director, the
 WG Chair, and the WG participants, the objectives or assignment of
 the working group may be extended by modifying the working group's
 charter through a rechartering process (see section 5).

2.1. Criteria for formation

 When determining whether it is appropriate to create a working group,
 the Area Director(s) and the IESG will consider several issues:
  1. Are the issues that the working group plans to address clear and

relevant to the Internet community?

  1. Are the goals specific and reasonably achievable, and achievable

within a reasonable time frame?

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

  1. What are the risks and urgency of the work, to determine the level

of effort required?

  1. Do the working group's activities overlap with those of another

working group? If so, it may still be appropriate to create the

    working group, but this question must be considered carefully by
    the Area Directors as subdividing efforts often dilutes the
    available technical expertise.
  1. Is there sufficient interest within the IETF in the working

group's topic with enough people willing to expend the effort to

    produce the desired result (e.g., a protocol specification)?
    Working groups require considerable effort, including management
    of the working group process, editing of working group documents,
    and contributing to the document text.  IETF experience suggests
    that these roles typically cannot all be handled by one person; a
    minimum of four or five active participants in the management
    positions are typically required in addition to a minimum of one
    or two dozen people that will attend the working group meetings
    and contribute on the mailing list.  NOTE: The interest must be
    broad enough that a working group would not be seen as merely the
    activity of a single vendor.
  1. Is there enough expertise within the IETF in the working group's

topic, and are those people interested in contributing in the

    working group?
  1. Does a base of interested consumers (end-users) appear to exist

for the planned work? Consumer interest can be measured by

    participation of end-users within the IETF process, as well as by
    less direct means.
  1. Does the IETF have a reasonable role to play in the determination

of the technology? There are many Internet-related technologies

    that may be interesting to IETF members but in some cases the IETF
    may not be in a position to effect the course of the technology in
    the "real world".  This can happen, for example, if the technology
    is being developed by another standards body or an industry
    consortium.
  1. Are all known intellectual property rights relevant to the

proposed working group's efforts issues understood?

  1. Is the proposed work plan an open IETF effort or is it an attempt

to "bless" non-IETF technology where the effect of input from IETF

    participants may be limited?

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

  1. Is there a good understanding of any existing work that is

relevant to the topics that the proposed working group is to

    pursue?  This includes work within the IETF and elsewhere.
  1. Do the working group's goals overlap with known work in another

standards body, and if so is adequate liaison in place?

 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 "wg_acronym-archive@lists.ietf.org"
       (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:
  1. Architecture
  2. Operations
  3. Security
  4. Network management
  5. Scaling
  6. 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 agenda@ietf.org 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,
  1. 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.
  1. The Area Director MAY require that a BOF be held, prior to

establishing a working group (see section 2.2).

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

  1. 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:
  1. There was enough interest and focus in the subject to warrant the

formation of a WG;

  1. 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).
  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
  1. 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:
  1. The items for discussion;
  2. The estimated time necessary per item; and
  3. 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
 agenda@ietf.org.
 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: minutes@ietf.org

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 agenda@ietf.org.  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:
  1. The working group name and full title;
  2. The amount of time requested;
  3. The rough outline of the WG agenda that is expected to be covered;
  4. The estimated number of people that will attend the WG session;
  5. Related WGs that should not be scheduled for the same time slot(s);

and

  1. 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:
 iesg-secretary@ietf.org.

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
 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 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 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: 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:
  1. Beginning, standard, boilerplate text which is provided by the

Secretariat on their web site and in the ftp directory;

  1. The I-D filename; and
  2. 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:
  1. The version of the relevant document exactly as agreed to by the WG

MUST be in the Internet-Drafts directory.

  1. The relevant document MUST be formatted according to section 7.3.
  1. 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
 general, in-depth review.
 The IESG review takes into account responses to the Last-Call and
 will lead to one of these possible conclusions:

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

 1. The document is accepted as is for the status requested.
    This fact will be announced by the IETF Secretariat to the IETF
    mailing list and to the RFC Editor.
 2. The document is accepted as-is but not for the status requested.
    This fact will be announced by the IETF Secretariat to the IETF
    mailing list and to the RFC Editor (see [1] for more details).
 3. Changes regarding content are suggested to the author(s)/WG.
    Suggestions from the IESG must be clear and direct, so as to
    facilitate working group and author correction of the
    specification.  If the author(s)/WG can explain to the
    satisfaction of the IESG why the changes are not necessary, the
    document will be accepted for publication as under point 1, above.
    If the changes are made the revised document may be resubmitted
    for IESG review.
 4. Changes are suggested by the IESG and a change in status is
    recommended.
    The process described above for 3 and 2 are followed in that
    order.
 5. The document is rejected.
    Any document rejection will be accompanied by specific and
    thorough arguments from the IESG. Although the IETF and working
    group process is structured such that this alternative is not
    likely to arise for documents coming from a working group, the
    IESG has the right and responsibility to reject documents that the
    IESG feels are fatally flawed in some way.
    If any individual or group of individuals feels that the review
    treatment has been unfair, there is the opportunity to make a
    procedural complaint. The mechanism for this type of complaints is
    described in [1].

9. Security Considerations

 Documents describing IETF processes, such as this one, do not have an
 impact on the security of the network infrastructure or of Internet
 applications.
 It should be noted that all IETF working groups are required to
 examine and understand the security implications of any technology
 they develop.  This analysis must be included in any resulting RFCs
 in a Security Considerations section.  Note that merely noting a
 significant security hole is no longer sufficient.  IETF developed
 technologies should not add insecurity to the environment in which
 they are run.

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

10. Acknowledgments

 This revision of this document relies heavily on the previous version
 (RFC 1603) which was edited by Erik Huizer and Dave Crocker.  It has
 been reviewed by the Poisson Working Group.

11. References

 [1] Bradner, S., Editor, "The Internet Standards Process -- Revision
     3", BCP 9, RFC 2026, October 1996.
 [2] Hovey, R., and S. Bradner, "The Organizations involved in the
     IETF Standards Process", BCP 11, RFC 2028, October 1996.
 [3] Gavin, J., "IAB and IESG Selection, Confirmation, and Recall
     Process: Operation of the Nominating and Recall Committees", BCP
     10, RFC 2282, February 1998.
 [4] Huitema, C., J. Postel, S. Crocker, "Not all RFCs are Standards",
     RFC 1796, April 1995.
 [5] Postel, J., and J. Reynolds, "Instructions to RFC Authors", RFC
     2223, October 1997.
 [6] Bradner, S., "Key words for use in RFCs to Indicate Requirement
     Level", BCP 14, RFC 2119, March 1997.

12. Editor's Address

 Scott Bradner
 Harvard University
 1350 Mass Ave.
 Cambridge MA
 02138
 USA
 Phone +1 617 495 3864
 EMail: sob@harvard.edu

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

 Appendix:  Sample Working Group Charter
 Working Group Name:
      IP Telephony (iptel)
 IETF Area:
      Transport Area
 Chair(s):
      Jonathan Rosenberg <jdrosen@bell-labs.com>
 Transport Area Director(s):
      Scott Bradner <sob@harvard.edu>
      Allyn Romanow <allyn@mci.net>
 Responsible Area Director:
      Allyn Romanow <allyn@mci.net>
 Mailing Lists:
      General Discussion:iptel@lists.research.bell-labs.com
      To Subscribe: iptel-request@lists.research.bell-labs.com
      Archive: http://www.bell-labs.com/mailing-lists/siptel
 Description of Working Group:
 Before Internet telephony can become a widely deployed service, a
 number of protocols must be deployed. These include signaling and
 capabilities exchange, but also include a number of "peripheral"
 protocols for providing related services.
 The primary purpose of this working group is to develop two such
 supportive protocols and a frameword document. They are:
 1. Call Processing Syntax. When a call is setup between two
 endpoints, the signaling will generally pass through several servers
 (such as an H.323 gatekeeper) which are responsible for forwarding,
 redirecting, or proxying the signaling messages. For example, a user
 may make a call to j.doe@bigcompany.com. The signaling message to
 initiate the call will arrive at some server at bigcompany. This
 server can inform the caller that the callee is busy, forward the
 call initiation request to another server closer to the user, or drop
 the call completely (among other possibilities). It is very desirable
 to allow the callee to provide input to this process, guiding the
 server in its decision on how to act. This can enable a wide variety
 of advanced personal mobility and call agent services.

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

 Such preferences can be expressed in a call processing syntax, which
 can be authored by the user (or generated automatically by some
 tool), and then uploaded to the server. The group will develop this
 syntax, and specify means of securely transporting and extending it.
 The result will be a single standards track RFC.
 2. In addition, the group will write a service model document, which
 describes the services that are enabled by the call processing
 syntax, and discusses how the syntax can be used. This document will
 result in a single RFC.
 3. Gateway Attribute Distribution Protocol. When making a call
 between an IP host and a PSTN user, a telephony gateway must be used.
 The selection of such gateways can be based on many criteria,
 including client expressed preferences, service provider preferences,
 and availability of gateways, in addition to destination telephone
 number.  Since gateways outside of the hosts' administrative domain
 might be used, a protocol is required to allow gateways in remote
 domains to distribute their attributes (such as PSTN connectivity,
 supported codecs, etc.) to entities in other domains which must make
 a selection of a gateway. The protocol must allow for scalable,
 bandwidth efficient, and very secure transmission of these
 attributes. The group will investigate and design a protocol for this
 purpose, generate an Internet Draft, and advance it to RFC as
 appropriate.
 Goals and Milestones:
 May 98    Issue first Internet-Draft on service framework
 Jul 98    Submit framework ID to IESG for publication as an RFC.
 Aug 98    Issue first Internet-Draft on Call Processing Syntax
 Oct 98    Submit Call processing syntax to IESG for consideration
           as a Proposed Standard.
 Dec 98    Achieve consensus on basics of gateway attribute
           distribution protocol
 Jan 99    Submit Gateway Attribute Distribution protocol to IESG
           for consideration as a RFC (info, exp, stds track TB

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

Full Copyright Statement

 Copyright (C) The Internet Society (1998).  All Rights Reserved.
 This document and translations of it may be copied and furnished to
 others, and derivative works that comment on or otherwise explain it
 or assist in its implementation may be prepared, copied, published
 and distributed, in whole or in part, without restriction of any
 kind, provided that the above copyright notice and this paragraph are
 included on all such copies and derivative works.  However, this
 document itself may not be modified in any way, such as by removing
 the copyright notice or references to the Internet Society or other
 Internet organizations, except as needed for the purpose of
 developing Internet standards in which case the procedures for
 copyrights defined in the Internet Standards process must be
 followed, or as required to translate it into languages other than
 English.
 The limited permissions granted above are perpetual and will not be
 revoked by the Internet Society or its successors or assigns.
 This document and the information contained herein is provided on an
 "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
 TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
 BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
 HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
 MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.

Bradner Best Current Practice [Page 26]

Network Working Group M. Wasserman Request for Comments: 3934 ThingMagic Updates: 2418 October 2004 BCP: 94 Category: Best Current Practice

 Updates to RFC 2418 Regarding the Management of IETF Mailing Lists

Status of this Memo

 This document specifies an Internet Best Current Practices for the
 Internet Community, and requests discussion and suggestions for
 improvements.  Distribution of this memo is unlimited.

Copyright Notice

 Copyright (C) The Internet Society (2004).

Abstract

 This document is an update to RFC 2418 that gives WG chairs explicit
 responsibility for managing WG mailing lists.  In particular, it
 gives WG chairs the authority to temporarily suspend the mailing list
 posting privileges of disruptive individuals.

Table of Contents

 1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  2
 2.  Specific Changes to RFC 2418 . . . . . . . . . . . . . . . . .  2
 3.  Security Considerations  . . . . . . . . . . . . . . . . . . .  3
 4.  Acknowledgements . . . . . . . . . . . . . . . . . . . . . . .  3
 5.  References . . . . . . . . . . . . . . . . . . . . . . . . . .  3
     5.1.  Normative References . . . . . . . . . . . . . . . . . .  3
     5.2.  Informative References . . . . . . . . . . . . . . . . .  3
 6.  Author's Address . . . . . . . . . . . . . . . . . . . . . . .  4
 7.  Full Copyright Statement . . . . . . . . . . . . . . . . . . .  5

Wasserman Best Current Practice [Page 1] RFC 3934 Mailing List Management Update October 2004

1. Introduction

 As written, RFC 2418 [RFC2418] gives WG chairs more authority to
 manage face-to-face discussions than to manage mailing list
 discussions.  In face-to-face meetings, the WG chair 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."  However,
 RFC 2418 does not give the WG Chair the authority to suspend the
 mailing list posting privileges of an individual who is similarly
 disrupting WG mailing list discussions.  RFC 2418 explicitly requires
 full IESG approval for this action.
 This document is an update to RFC 2418, section 3.2.  It gives WG
 chairs the authority to temporarily suspend the posting privileges of
 disruptive individuals without IESG approval.

2. Specific Changes to RFC 2418

 The following paragraphs supersede the last paragraph of RFC 2418,
 section 3.2:
 As in face-to-face sessions, occasionally one or more individuals may
 engage in behavior on a mailing list that, in the opinion of the WG
 chair, is disruptive to the WG process.  Unless the disruptive
 behavior is severe enough that it must be stopped immediately, the WG
 chair should attempt to discourage the disruptive behavior by
 communicating directly with the offending individual.  If the
 behavior persists, the WG chair should send at least one public
 warning on the WG mailing list.  As a last resort and typically after
 one or more explicit warnings and consultation with the responsible
 Area Director, the WG chair may suspend the mailing list posting
 privileges of the disruptive individual for a period of not more than
 30 days.  Even while posting privileges are suspended, the individual
 must not be prevented from receiving messages posted to the list.
 Like all other WG chair decisions, any suspension of posting
 privileges is subject to appeal, as described in RFC 2026 [RFC2026].
 This mechanism is intended to permit a WG chair to suspend posting
 privileges of a disruptive individual for a short period of time.
 This mechanism does not permit WG chairs to suspend an individual's
 posting privileges for a period longer than 30 days regardless of the
 type or severity of the disruptive incident.  However, further
 disruptive behavior by the same individual will be considered
 separately and may result in further warnings or suspensions.  Other
 methods of mailing list control, including longer suspensions, must

Wasserman Best Current Practice [Page 2] RFC 3934 Mailing List Management Update October 2004

 be carried out in accordance with other IETF-approved procedures.
 See BCP 83 [RFC3683] for one set of procedures already defined and
 accepted by the community.

3. Security Considerations

 This document describes a modification to the IETF process for
 managing mailing list discussions.  It has no security
 considerations.

4. Acknowledgements

 This document reflects a discussion that was held on the MPOWR
 mailing list in December 2003 and January 2004.  In particular, the
 following people contributed ideas that influenced this document:
 Harald Alvestrand, Dave Crocker, James Kempf, and John Klensin.
 This document was written with the xml2rfc tool described in RFC 2629
 [RFC2629].

5. References

5.1. Normative References

 [RFC2026]  Bradner, S., "The Internet Standards Process -- Revision
            3", BCP 9, RFC 2026, October 1996.
 [RFC2418]  Bradner, S., "IETF Working Group Guidelines and
            Procedures", BCP 25, RFC 2418, September 1998.

5.2. Informative References

 [RFC2629]  Rose, M., "Writing I-Ds and RFCs using XML", RFC 2629,
            June 1999.
 [RFC3683]  Rose, M., "A Practice for Revoking Posting Rights to IETF
            Mailing Lists", BCP 83, RFC 3683, March 2004.

Wasserman Best Current Practice [Page 3] RFC 3934 Mailing List Management Update October 2004

6. Author's Address

 Margaret Wasserman
 ThingMagic
 One Broadway, 14th Floor
 Cambridge, MA  02142
 USA
 Phone: +1 617 758 4177
 EMail: margaret@thingmagic.com
 URI:   http://www.thingmagic.com/

Wasserman Best Current Practice [Page 4] RFC 3934 Mailing List Management Update October 2004

7. Full Copyright Statement

 Copyright (C) The Internet Society (2004).
 This document is subject to the rights, licenses and restrictions
 contained in BCP 78, and at www.rfc-editor.org, and except as set
 forth therein, the authors retain all their rights.
 This document and the information contained herein are provided on an
 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.

Intellectual Property

 The IETF takes no position regarding the validity or scope of any
 Intellectual Property Rights or other rights that might be claimed to
 pertain to the implementation or use of the technology described in
 this document or the extent to which any license under such rights
 might or might not be available; nor does it represent that it has
 made any independent effort to identify any such rights.  Information
 on the ISOC's procedures with respect to rights in ISOC Documents can
 be found in BCP 78 and BCP 79.
 Copies of IPR disclosures made to the IETF Secretariat and any
 assurances of licenses to be made available, or the result of an
 attempt made to obtain a general license or permission for the use of
 such proprietary rights by implementers or users of this
 specification can be obtained from the IETF on-line IPR repository at
 http://www.ietf.org/ipr.
 The IETF invites any interested party to bring to its attention any
 copyrights, patents or patent applications, or other proprietary
 rights that may cover technology that may be required to implement
 this standard.  Please address the information to the IETF at ietf-
 ipr@ietf.org.

Acknowledgement

 Funding for the RFC Editor function is currently provided by the
 Internet Society.

Wasserman Best Current Practice [Page 5]

Internet Engineering Task Force (IETF) P. Resnick Request for Comments: 7776 Qualcomm Technologies, Inc. BCP: 25 A. Farrel Updates: 2418, 7437 Juniper Networks Category: Best Current Practice March 2016 ISSN: 2070-1721

                  IETF Anti-Harassment Procedures

Abstract

 IETF Participants must not engage in harassment while at IETF
 meetings, virtual meetings, or social events or while participating
 in mailing lists.  This document lays out procedures for managing and
 enforcing this policy.
 This document updates RFC 2418 by defining new working group
 guidelines and procedures.  This document updates RFC 7437 by
 allowing the Ombudsteam to form a recall petition without further
 signatories.

Status of This Memo

 This memo documents an Internet Best Current Practice.
 This document is a product of the Internet Engineering Task Force
 (IETF).  It represents the consensus of the IETF community.  It has
 received public review and has been approved for publication by the
 Internet Engineering Steering Group (IESG).  Further information on
 BCPs is available in Section 2 of RFC 5741.
 Information about the current status of this document, any errata,
 and how to provide feedback on it may be obtained at
 http://www.rfc-editor.org/info/rfc7776.

Resnick & Farrel Best Current Practice [Page 1] RFC 7776 Anti-Harassment Procedures March 2016

Copyright Notice

 Copyright (c) 2016 IETF Trust and the persons identified as the
 document authors.  All rights reserved.
 This document is subject to BCP 78 and the IETF Trust's Legal
 Provisions Relating to IETF Documents
 (http://trustee.ietf.org/license-info) in effect on the date of
 publication of this document.  Please review these documents
 carefully, as they describe your rights and restrictions with respect
 to this document.  Code Components extracted from this document must
 include Simplified BSD License text as described in Section 4.e of
 the Trust Legal Provisions and are provided without warranty as
 described in the Simplified BSD License.

Table of Contents

 1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . .   3
 2.  Definitions . . . . . . . . . . . . . . . . . . . . . . . . .   3
 3.  The Ombudsteam  . . . . . . . . . . . . . . . . . . . . . . .   5
   3.1.  Size of the Ombudsteam  . . . . . . . . . . . . . . . . .   5
   3.2.  Appointing the Ombudsteam . . . . . . . . . . . . . . . .   5
   3.3.  Professional Advisors . . . . . . . . . . . . . . . . . .   5
   3.4.  Qualifications and Training . . . . . . . . . . . . . . .   6
   3.5.  Term of Service . . . . . . . . . . . . . . . . . . . . .   6
   3.6.  Compensation  . . . . . . . . . . . . . . . . . . . . . .   6
   3.7.  Removal . . . . . . . . . . . . . . . . . . . . . . . . .   7
   3.8.  Disputes with the IETF Chair Regarding the Ombudsteam . .   7
 4.  Handling Reports of Harassment  . . . . . . . . . . . . . . .   7
   4.1.  Ombudsteam Operating Practices  . . . . . . . . . . . . .   8
 5.  Remedies  . . . . . . . . . . . . . . . . . . . . . . . . . .  10
   5.1.  Remedies for Respondents in IETF Positions  . . . . . . .  11
   5.2.  Purpose of Remedies . . . . . . . . . . . . . . . . . . .  13
 6.  Disputes with the Ombudsteam  . . . . . . . . . . . . . . . .  14
 7.  Conflicts of Interest . . . . . . . . . . . . . . . . . . . .  15
 8.  Confidentiality . . . . . . . . . . . . . . . . . . . . . . .  15
 9.  Security Considerations . . . . . . . . . . . . . . . . . . .  16
 10. References  . . . . . . . . . . . . . . . . . . . . . . . . .  16
   10.1.  Normative References . . . . . . . . . . . . . . . . . .  16
   10.2.  Informative References . . . . . . . . . . . . . . . . .  17
 Acknowledgements  . . . . . . . . . . . . . . . . . . . . . . . .  17
 Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .  18

Resnick & Farrel Best Current Practice [Page 2] RFC 7776 Anti-Harassment Procedures March 2016

1. Introduction

 The IETF has general policies for managing disruptive behavior in the
 context of IETF activities.  In particular, [RFC7154] provides a set
 of guidelines for personal interaction in the IETF, and [RFC2418] and
 [RFC3934] give guidelines for how to deal with disruptive behavior
 that occurs in the context of IETF working group face-to-face
 meetings and on mailing lists.
 However, there is other problematic behavior that may be more
 personal and that can occur in the context of IETF activities
 (meetings, mailing list discussions, or social events) that does not
 directly disrupt working group progress but nonetheless is
 unacceptable behavior between IETF Participants.  This sort of
 behavior, described in the IESG Statement "IETF Anti-Harassment
 Policy" [Policy], is not easily dealt with by our previously existing
 working group guidelines and procedures.  Therefore, this document
 sets forth procedures to deal with such harassing behavior.
 These procedures are intended to be used when other IETF policies and
 procedures do not apply or have been ineffective.
 Nothing in this document should be taken to interfere with the due
 process of law.  Similarly, it does not release any person from any
 contractual or corporate policies to which they may be subject.

2. Definitions

 The following terms are used in this document:
 o  IETF Participant: Anyone who participates in an IETF activity,
    including IETF support staff.
 o  Reporter: An IETF Participant who reports potential harassment to
    an Ombudsperson.
 o  Respondent: An IETF Participant who is claimed to have engaged in
    harassing behavior.
 o  Ombudsteam: A group of people who have been selected to take
    reports of potential harassment, evaluate them, and impose
    appropriate actions and/or remedies to address the circumstances.
 o  Ombudsperson: A member of the Ombudsteam.
 o  Lead Ombudsperson: The Ombudsperson assigned to be the primary
    contact person for a particular report of potential harassment.

Resnick & Farrel Best Current Practice [Page 3] RFC 7776 Anti-Harassment Procedures March 2016

 o  Subject: An individual, group, or class of IETF Participant to
    whom the potentially harassing behavior was directed or who might
    be subject to the behavior.
 The IESG Statement on harassment [Policy] gives a general definition
 of harassment as:
    unwelcome hostile or intimidating behavior -- in particular,
    speech or behavior that is sexually aggressive or intimidates
    based on attributes such as race, gender, religion, age, color,
    national origin, ancestry, disability, sexual orientation, or
    gender identity.
 This document adopts that general definition but does not attempt to
 further precisely define behavior that falls under the set of
 procedures identified here, nor does it attempt to list every
 possible attribute that might be the basis for harassment, except to
 note that it may be targeted at an individual, directed at a specific
 group of people, or more generally impact a broader class of people.
 This document concerns itself with harassment that has the purpose or
 effect of unreasonably interfering with an individual's participation
 in IETF activities or of creating an environment within the IETF that
 would be intimidating, hostile, or offensive in such a situation.
 One way in which harassment can occur is when submission to such
 conduct is made, either explicitly or implicitly, a term or condition
 of an individual's participation in IETF activities or is used as a
 basis for decisions affecting that individual's relationship to the
 IETF.
 In general, disruptive behavior that occurs in the context of an IETF
 general or working group mailing list, or happens in a face-to-face
 or virtual meeting of a working group or the IETF plenary, can be
 dealt with by our normal procedures, whereas harassing behavior is
 more appropriately handled by the procedures described here.
 However, there are plausible reasons to address behaviors that take
 place during working group meetings using these procedures.  This
 document gives some guidance to those involved in these situations in
 order to decide how to handle particular incidents, but the final
 decision will involve judgment and the guidance of the Ombudsteam.
 Any definition of harassment prohibited by an applicable law can be
 subject to this set of procedures.

Resnick & Farrel Best Current Practice [Page 4] RFC 7776 Anti-Harassment Procedures March 2016

3. The Ombudsteam

 This section describes the role of the Ombudsteam in terms of the
 appointment of Ombudspersons, their qualifications and training, the
 length of the term of service, any compensation from the IETF for
 their service, and how they may be removed from service.  The general
 operational procedures for the Ombudsteam are described in Sections
 4, 5, and 6.

3.1. Size of the Ombudsteam

 The Ombudsteam shall comprise no fewer than three people.  From time
 to time, the size may fall below that number owing to changes in
 membership, but the team will be rapidly brought up to size through
 new appointments.  The team may be grown to a larger size as
 described in Section 3.2

3.2. Appointing the Ombudsteam

 The Ombudsteam is appointed by the IETF Chair.  The appointment is
 solely the responsibility of the IETF Chair, who may choose to
 consult with members of the IETF community.
 The IETF Chair is encouraged to appoint at least some of the
 Ombudsteam from within the IETF community.
 The IETF Chair may choose to solicit nominations or advertise the
 post.  This is entirely at the discretion of the IETF Chair.
 The IETF Chair is also free to decide to appoint more than three
 Ombudspersons to the Ombudsteam.  This may depend on the skill sets
 available, the work load, and the opinions of the seated Ombudsteam.
 Furthermore, the IETF Chair may consider elements of diversity in
 making this decision.

3.3. Professional Advisors

 It is recognized that the Ombudsteam may need to call on professional
 services from external advisors for certain matters, including legal
 and Human Resources (HR) advice.  The IETF (via the IETF
 Administrative Support Activity (IASA)) is committed to funding such
 advice as needed.

Resnick & Farrel Best Current Practice [Page 5] RFC 7776 Anti-Harassment Procedures March 2016

3.4. Qualifications and Training

 It is not expected that there will be candidates with all of the
 necessary Ombudsperson skills and training who also have a clear
 understanding and familiarity with the IETF processes and culture.
 The Chair might choose someone with a great deal of professional
 experience evaluating and mediating harassment disputes but little
 exposure to the IETF or could select someone with more exposure to
 the IETF community but without as much experience dealing with issues
 of harassment.  Since all of these attributes may be regarded by the
 IETF Chair as essential for the team, the IETF is committed to
 providing training (or funding for it) as deemed necessary for
 appointed Ombudspersons.  In determining the appropriate training,
 the IETF Chair and Ombudsteam shall take professional advice and will
 consult with the IETF Administrative Oversight Committee (IAOC) with
 respect to the overall IETF budget.

3.5. Term of Service

 An Ombudsperson shall be appointed for a two-year term.  That is, the
 Ombudsperson is making a commitment to serve for two years.  It is
 understood, however, that circumstances may lead an Ombudsperson to
 resign for personal or other reasons.  See also Section 3.7.
 If an Ombudsperson's term ends while they are acting as Lead
 Ombudsperson for a report as described in Section 4, that
 Ombudsperson's term shall be extended until the handling of that
 report has been completed.
 It is entirely at the discretion of the IETF Chair whether a serving
 Ombudsperson is reappointed at the end of their term.  Given the
 sensitivity of, and training required for, this role and the ideal
 being a lack of activity, it is likely the IETF Chair may choose to
 reappoint a successful and still-willing Ombudsperson for a number of
 two-year terms.

3.6. Compensation

 An Ombudsperson shall receive no compensation from the IETF for their
 services.  This includes, but is not limited to:
 o  IETF meeting fees
 o  Remuneration for time spent
 o  Out-of-pocket expenses (such as telephone charges)
 o  Travel or accommodation expenses

Resnick & Farrel Best Current Practice [Page 6] RFC 7776 Anti-Harassment Procedures March 2016

 The IETF will, however, meet the costs of training when agreed to by
 the IETF Chair as described in Section 3.4.

3.7. Removal

 The IETF Chair may remove a serving Ombudsperson before the end of
 their term without explanation to the community, including during the
 course of processing an active case.  Such an action shall be
 appealable as described in Section 3.8.
 An Ombudsperson shall not be removed from service, even if their term
 has expired, during the period that the IETF Chair is recused as
 described in Section 7.  Once the case that led to the Chair being
 recused has been closed, normal processes resume.

3.8. Disputes with the IETF Chair Regarding the Ombudsteam

 If an individual should disagree with an action taken by the IETF
 Chair regarding the appointment, removal, or management of an
 Ombudsperson or the Ombudsteam, that person should first discuss the
 issue with the IETF Chair directly.  If the IETF Chair is unable to
 resolve the issue, the dissatisfied party may appeal to the IESG as a
 whole.  The IESG shall then review the situation and attempt to
 resolve it in a manner of its own choosing.  The procedures of
 Section 6.5.4 of [RFC2026] apply to this sort of appeal.

4. Handling Reports of Harassment

 Any IETF Participant who believes that they have been harassed, or
 that any other IETF Participant or group of IETF Participants has
 been or may have been harassed, should bring the concern to the
 attention of any serving Ombudsperson.  This can be done by email to
 ombuds@ietf.org or can be done directly to a chosen Ombudsperson.
 Direct contact information for the members of the Ombudsteam,
 including the email addresses to which mail to ombuds@ietf.org is
 forwarded, can be found at <https://www.ietf.org/ombudsteam>
 [OmbudsteamPages].
 All IETF Participants are encouraged to talk with the Ombudsteam if
 they are uncomfortable or unsure about any behaviors.  Though much of
 this document relates to the formal duties of the Ombudsteam, it
 should be understood that an important function of the Ombudsteam is
 to provide confidential advice and counsel for any IETF Participant
 regarding issues of harassment.  The Ombudsteam will not commence a
 formal investigation of any potential incident of harassment without
 agreement by the Reporter and Subject.

Resnick & Farrel Best Current Practice [Page 7] RFC 7776 Anti-Harassment Procedures March 2016

 When a Reporter brings an incident of potential harassment to the
 attention of the Ombudsteam, a single Ombudsperson shall be
 designated as the primary contact person (the Lead Ombudsperson) for
 the report.  When the Reporter contacts a single Ombudsperson, that
 Ombudsperson shall be the Lead Ombudsperson for the report unless the
 Reporter and Ombudsperson mutually agree to select another Lead
 Ombudsperson.
 Information conveyed by the Reporter should be kept in confidence by
 the Lead Ombudsperson to the greatest extent possible.  When
 necessary (for example, in the course of a formal investigation), the
 Lead Ombudsperson may share information regarding the report with the
 rest of the Ombudsteam except when an Ombudsperson is recused (see
 Section 7).  If a Reporter believes that a member of the Ombudsteam
 should recuse themself, the Reporter should make this known to the
 Lead Ombudsperson as soon as possible.  See Section 4.1 for further
 discussion of the confidentiality requirements of the Ombudsteam.
 The Lead Ombudsperson will discuss the events with the Reporter and
 may give advice, including recommendations on how the Reporter can
 handle the issue on their own as well as strategies on how to prevent
 the issue from arising again.  The Lead Ombudsperson may also
 indicate that the issue would be best handled using regular IETF
 procedures (such as those for dealing with disruptive behavior)
 outside the context of harassment, and in this case, the Lead
 Ombudsperson will provide assistance in using the relevant IETF
 procedures.  Otherwise, with agreement to proceed from the Subject
 (or the Reporter if there is no individual Subject), the Ombudsteam
 may initiate a detailed investigation of the matter and may
 subsequently, after completing their investigation, impose a remedy
 as described in Section 5.  The Subject can withdraw their agreement
 to proceed at any time.

4.1. Ombudsteam Operating Practices

 The Ombudsteam is responsible for devising and documenting their
 operating practices.  These practices must be discussed with the IESG
 and published in a publicly visible place (such as on the IETF web
 site).  Discussion with the IETF community is encouraged and, while
 IETF consensus is not necessary, significant objections to the
 processes that are not addressed should result in an appeal per
 Section 6.5.3 of [RFC2026] and/or a recall petition against the IETF
 Chair (and any of the rest of the IESG if appropriate) if they do not
 address the concern.

Resnick & Farrel Best Current Practice [Page 8] RFC 7776 Anti-Harassment Procedures March 2016

 The practices must include at least the following high-level
 components:
 o  Each member of the Ombudsteam is expected to be present at the
    majority of IETF meetings and to be available for face-to-face
    discussions.  The Ombudsteam is expected to arrange itself so that
    there is coverage of every IETF meeting by at least one
    Ombudsperson.
 o  The Ombudsteam shall strive to keep all information brought to it
    in strict confidence.  However, it is acknowledged that the
    operation of the Ombudsteam may involve sharing of information
    within the team and may require that the parties to the complaint
    (the Reporter, Respondent, and Subject) learn some of the
    confidential information.  The Ombudsteam is responsible for
    documenting its expectations of when disclosures of confidential
    information are likely to be made in the process and to whom.  Any
    electronic information (such as email messages) that needs to be
    archived shall be encrypted before it is stored using tools
    similar to those used by the Nominating Committee (NomCom).
 o  When conducting a detailed investigation of the circumstances
    regarding the complaint of harassment, the Ombudsteam may contact
    the Respondent and request a meeting in person or by a voice call.
    The Ombudsteam shall have contacted the Respondent and either
    discussed the matter or ascertained the Respondent's unwillingness
    to cooperate prior to deciding to impose a remedy as described in
    Section 5.  The Respondent is not obliged to cooperate, but the
    Ombudsteam may consider failure to cooperate when determining a
    remedy (Section 5).
 o  The Ombudsteam shall endeavor to complete its investigation in a
    timely manner.
 o  Any individuals who make a good faith report of harassment or who
    cooperate with an investigation shall not be subject to
    retaliation for reporting, complaining, or cooperating, even if
    the investigation, once completed, shows no harassment occurred.
    Anti-retaliation is noted here to alleviate concerns individuals
    may have with reporting an incident they feel should be reviewed
    or cooperating with an investigation.
 o  In all cases, the Ombudsteam will strive to maintain
    confidentiality for all parties, including the very fact of
    contact with the Ombudsteam.

Resnick & Farrel Best Current Practice [Page 9] RFC 7776 Anti-Harassment Procedures March 2016

 o  The results of investigations as reported to the Subject or
    Respondent and all requests for remedial action (such as to the
    IETF Secretariat) shall be in writing.
 o  The Ombudsteam shall keep written records of their investigation
    and any contacts or interviews such that there is material
    available in the event of an appeal or legal action.  Such records
    shall be held securely and in confidence.
 When investigating reports of harassment and determining remedies, it
 is up to the Ombudsteam whether they choose to act as a body or
 delegate duties to the Lead Ombudsperson.

5. Remedies

 After examining the circumstances regarding the complaint of
 harassment, the Ombudsteam should prepare a brief summary of the
 incident and their conclusions and discuss this with all parties.
 The objective of this step is to make clear what the Ombudsteam has
 concluded and to make an attempt at getting all parties to reach
 agreement.
 If the Ombudsteam determines that harassment has taken place, the
 Ombudsteam is expected to determine the next action.
 o  In some cases, a mechanism or established IETF process may already
    exist for handling the specific event.  In these cases, the
    Ombudsteam may decide that the misbehavior is best handled with
    the regular IETF procedures for dealing with disruptive behavior
    and may assist the Reporter to bring the issue to the attention of
    the WG Chair or IESG member who can deal with the incident.
 o  In other cases, there is a spectrum of remedies that may be
    appropriate to the circumstances.  At one end of the spectrum, the
    Ombudsteam might choose to discuss the situation with the
    Respondent and come up with a plan such that there is no repeat of
    the harassment.  With the agreement of both parties, the
    Ombudsteam can also help to mediate a conversation between the
    Respondent and the Subject (or the Reporter if there is no
    individual Subject) in order to address the issue.  If mediation
    fails, then the Ombudsteam can decide to apply other remedies,
    including those discussed here.
 o  At the other end of the spectrum, the Ombudsteam could decide that
    the Respondent is no longer permitted to participate in a
    particular IETF activity, for example, ejecting them from a
    meeting or requiring that the Respondent can no longer attend
    future meetings to ensure that the reported harassment cannot

Resnick & Farrel Best Current Practice [Page 10] RFC 7776 Anti-Harassment Procedures March 2016

    continue or escalate.  If the Respondent holds a management
    position in the IETF, the remedies imposed may make it difficult
    or impossible for them to perform the duties required of that
    position.  Further remedies may be applied to Respondents in IETF
    management positions as described in Section 5.1.
 o  In determining the appropriate remedy, the Ombudsteam may
    communicate with the Reporter, Subject, or Respondent in order to
    assess the impact that the imposition of a remedy might have on
    any of those parties.  However, the Ombudsteam has ultimate
    responsibility for the choice of remedy.
 o  In all cases, the Lead Ombudsperson informs the Respondent of the
    decision and imposes the remedy as appropriate.  In cases where
    the remedy is removal from IETF activities, the Lead Ombudsperson
    will confidentially notify the Secretariat in writing of the
    remedy such that the Secretariat can take whatever logistical
    actions are required to effect the remedy.  Only the remedy itself
    shall be disclosed to the Secretariat, not any information
    regarding the nature of the harassment.
 Where specific action is required to ensure that a remedy is realized
 or enforced, the Ombudsteam will make a request in writing to the
 IETF Secretariat and/or IETF Administrative Director (IAD) to take
 action as appropriate.

5.1. Remedies for Respondents in IETF Positions

 The remedies discussed earlier in this section are equally applicable
 to all IETF Participants regardless of role.
 The Ombudsteam will want to be aware of the impact of remedies on the
 ability of an individual to carry out their duties in IETF management
 positions, but this should not dissuade the Ombudsteam from applying
 remedies that they deem appropriate.  Per Section 5, the Ombudsteam
 is expected to apply proportionality and reasonableness, as well as
 to consider the impact of the remedy on the Respondent.  Per
 Section 4.1, the Ombudsteam may communicate with the Respondent in
 order to assess the impact that the remedy might have.
 There may be cases where the Ombudsteam considers that it is
 inappropriate for a Respondent to continue in their IETF management
 position, that is, where the desired remedy is to remove the
 Respondent from their management position.  The Ombudsteam cannot by
 itself remove a Respondent who is in an IETF management position from
 that position.  However, the Ombudsteam can recommend the use of
 existing mechanisms within the IETF process for the removal of people
 from IETF management positions as follows:

Resnick & Farrel Best Current Practice [Page 11] RFC 7776 Anti-Harassment Procedures March 2016

 o  Many IETF management positions are appointed by the NomCom with
    confirmation from the IESG, IAB, or ISOC.  [RFC7437] describes the
    recall procedure for such appointments.  This document updates
    [RFC7437] by allowing the Ombudsteam to form a recall petition on
    its own and without requiring 20 signatories from the community.
    Such a petition shall be treated in all ways like any other recall
    petition as described in [RFC7437]: that is, the fact of the
    petition and its signatories (the Ombudsteam) shall be announced
    to the IETF community, and a Recall Committee Chair shall be
    appointed to complete the Recall Committee process.  It is
    expected that the Recall Committee will receive a briefing from
    the Ombudsteam explaining why recall is considered an appropriate
    remedy.
 o  Other IETF management positions are filled by appointment of the
    IESG, the IAB, the ISOC Board, or the ISOC President.  In such
    cases, the Ombudsteam may recommend to the appointing body that
    the Respondent be removed from their position.
 o  Many IETF management positions are filled through appointment by
    an AD or by the ADs for an IETF Area.  In such cases, the
    Ombudsteam may recommend to those ADs in writing that the
    Respondent be removed from their position.
 o  Some other IETF management positions are filled through
    appointment by WG Chairs.  In such cases, the Ombudsteam may make
    a recommendation in writing to the responsible AD (that is, not
    directly to the WG Chairs) that the Respondent be removed from
    their position.
 In each of the cases listed here, it is expected that the person or
 body responsible for removing someone from an IETF management
 position will take a recommendation from the Ombudsteam extremely
 seriously and that it would be very unusual for them to not act on
 the recommendation.  It is not the intent that the person or body
 attempt to reinvestigate the circumstances of the harassment.  They
 are expected to understand that they are not qualified in evaluating
 or handling issues of harassment.  They must seek to preserve
 confidentiality.  If the person or body feels removal from position
 is not the correct remedy, they must discuss their concern with the
 Ombudsteam.
 In the event that an AD declines to follow the recommendation of the
 Ombudsteam, and if the AD fails to convince the Ombudsteam of the
 reasons for this, the Ombudsteam should raise the issue with the
 whole IESG while continuing to attempt to retain confidentiality.
 The IESG may choose to reorganize the responsibilities for working

Resnick & Farrel Best Current Practice [Page 12] RFC 7776 Anti-Harassment Procedures March 2016

 groups within its own structure so that the AD concerned is no longer
 in the direct management path.
 All such forced removals from management positions must be considered
 by the Ombudsteam as acts of last resort.  That is, before a
 Respondent is recommended for removal, the Ombudsteam should consider
 other possible remedies and should discuss the situation with the
 Respondent, giving them ample opportunity to understand what might
 happen and to step down of their own volition.
 As described in Section 4.1, the Ombudsteam is required to maintain
 the highest degree of confidentiality.  In recommending action as
 described above, the Ombudsteam will clearly have to indicate that
 some event has occurred that led to their recommendation, but it is
 not expected that the Ombudsteam will need to divulge substantially
 more information.  It should be enough that the Ombudsteam explains
 the severity of the situation, that they have considered other lesser
 remedies, and that they deem the recommended remedy to be
 appropriate.
 In removing someone from their position, it may become apparent to
 the IETF community that the removal is a remedy recommended by the
 Ombudsteam.  However, revealing the underlying events should be
 avoided as far as possible.

5.2. Purpose of Remedies

 The purpose of the anti-harassment policy is to prevent all incidents
 of harassment in the IETF.  The set of procedures documented here
 serves to provide a mechanism whereby any harassment that occurs can
 be reported and handled both sympathetically and effectively.  The
 policy also sends a clear message that the IETF does not tolerate
 harassment in any form.
 However, any remedy is imposed to try to make sure that the incident
 does not escalate and to ensure that a similar situation is unlikely
 to occur with the same Respondent in the future.
 Because the handling of incidents of harassment (including the
 imposition of remedies) is confidential, an imposed remedy cannot
 itself serve as a deterrent to others, nor can it be used to "teach"
 the community how to behave.  ([RFC7154] gives guidelines for conduct
 in the IETF.)  Furthermore, a remedy is not to be imposed for the
 purposes of retribution.  However, the knowledge of the existence of
 a range of remedies and of processes by which they can be applied
 serves both as a statement of the IETF's seriousness in this matter
 and as a deterrent to potential offenders.

Resnick & Farrel Best Current Practice [Page 13] RFC 7776 Anti-Harassment Procedures March 2016

 The Ombudsteam is expected to apply the above considerations, as well
 as proportionality and reasonableness, in selecting a remedy.  They
 are asked to consider the impact of the remedy on the Respondent as
 well as on the Subject.

6. Disputes with the Ombudsteam

 If either the Subject (or the Reporter if there is no individual
 Subject) or the Respondent is dissatisfied with the decision of the
 Ombudsteam, the dissatisfied party should first contact the Lead
 Ombudsperson and discuss the situation.  If the issue cannot be
 resolved through discussion with the Lead Ombudsperson, the issue may
 be raised with the IETF Chair.
 If necessary, the IETF Chair may recuse themself from any part of
 this process (see Section 7) and request the IESG to select another
 of its members to serve in this role.  This IESG member is known as
 the "delegated IESG member".
 The IETF Chair (or the delegated IESG member if the Chair is recused)
 will attempt to resolve the issue in discussion with the dissatisfied
 party and the Lead Ombudsperson.  If this further discussion does not
 bring a satisfactory resolution, the Ombudsteam's decision may be
 formally appealed.  The appeal is strictly on the issue of whether
 the Ombudsteam exercised due diligence both in their decision as to
 whether harassment had taken place as well as in their determination
 of any appropriate remedy that was imposed.  In particular, the
 purpose of the appeal is not to re-investigate the circumstances of
 the incident or to negotiate the severity of the remedy.
 All elements of the appeal, including the fact of the appeal, will be
 held in confidence but will be recorded and held securely for future
 reference.
 The appeal will be evaluated by the IETF Chair (or the delegated IESG
 member) and two other members of the IESG selected by the IETF Chair
 (or the delegated IESG member) and confirmed by the appellant.  This
 Appeals Group shall convene as quickly as possible to evaluate and
 determine the appeal.  Where the impacts are immediate and related to
 participation in an ongoing meeting, this shall happen in no more
 than 24 hours after receiving the appeal.  The Appeals Group may ask
 the appellant and the Lead Ombudsperson for statements or other
 information to consider.  If the Appeals Group concludes that due
 diligence was exercised by the Ombudsteam, this shall be reported to
 the appellant, and the matter is concluded.  If the Appeals Group
 finds that due diligence was not exercised, the Appeals Group shall
 report this to the Ombudsteam and consult with the Ombudsteam on how
 to complete the due diligence.

Resnick & Farrel Best Current Practice [Page 14] RFC 7776 Anti-Harassment Procedures March 2016

 Because of the need to keep the information regarding these matters
 as confidential as possible, the Appeals Group's decision is final
 with respect to the question of whether the Ombudsteam has used due
 diligence in their decision.  The only further recourse available is
 to claim that the procedures themselves (i.e., the procedures
 described in this document) are inadequate or insufficient to the
 protection of the rights of all parties.  Such a claim may be made in
 an appeal to the Internet Society Board of Trustees, as described in
 Section 6.5.3 of [RFC2026].  Again, even in this circumstance, the
 particulars of the incident at hand will be held in confidence.

7. Conflicts of Interest

 In the event of any conflict of interest, the conflicted person
 (member of the Ombudsteam, member of the Appeals Group, IETF Chair,
 etc.) is expected to recuse themselves.
 A conflict of interest may arise if someone involved in the process
 of handling a harassment report is in the role of Reporter,
 Respondent, or Subject.  Furthermore, a conflict of interest arises
 if the person involved in the process of handling a harassment report
 is closely associated personally or through affiliation with any of
 the Reporter, Respondent, or Subject.
 For the avoidance of doubt, recusal in this context means completely
 stepping out of any advisory or decision-making part of any process
 associated with handling a harassment report, remedy arising from a
 harassment report, or appeal into the handling of a harassment
 report.  That means that a recused person has no more right to
 participate in or witness the process than any other person from the
 community in the same situation.  For example, an Ombudsperson
 subject to a complaint of harassment shall not be privy to the
 deliberations of another Ombudsperson handling the report.  Nor would
 an IESG member who was party to an appeal be able to witness the
 discussions of the Appeals Group.
 In the event that there is an appeal and the IETF Chair is somehow
 involved, the Chair will immediately recuse themself, and the IESG
 will select a single person to take the Chair's role in the appeal
 process as described in Section 6.

8. Confidentiality

 Throughout this document, there are mentions of requirements to keep
 information confidential.  This section summarizes those requirements
 for clarity.

Resnick & Farrel Best Current Practice [Page 15] RFC 7776 Anti-Harassment Procedures March 2016

 The Ombudsteam is expected to strive for confidentiality.
 Confidentiality protects the Reporter, Subject, and Respondent in any
 case of alleged harassment.  It also protects witnesses or others
 consulted by the Ombudsteam during their investigation.
 The Ombudsteam will keep its email and other archival records in a
 secure system and will not discuss details of any case beyond what is
 necessary for executing a thorough investigation.
 Third-party receivers of output from the Ombudsteam (for example, ADs
 or the IETF Secretariat who are asked to take action) are required to
 keep such output confidential.
 Participants in an investigation (Reporters, Subjects, Respondents,
 and anyone interviewed by the Ombudsteam during an investigation) are
 requested to keep the details of the events and investigation
 confidential.
 It is likely that members of the community will want to know more
 when they have become aware of some details of a case of harassment.
 The community is asked to show restraint and to trust the Ombudsteam.
 This process is designed to provide remedies not punishment, as
 described in Section 5.2, and public discussion of the events or
 remedies does not form part of this process.

9. Security Considerations

 "Human beings the world over need freedom and security that they may
 be able to realize their full potential." -- Aung San Suu Kyi

10. References

10.1. Normative References

 [RFC2026]  Bradner, S., "The Internet Standards Process -- Revision
            3", BCP 9, RFC 2026, DOI 10.17487/RFC2026, October 1996,
            <http://www.rfc-editor.org/info/rfc2026>.
 [RFC2418]  Bradner, S., "IETF Working Group Guidelines and
            Procedures", BCP 25, RFC 2418, DOI 10.17487/RFC2418,
            September 1998, <http://www.rfc-editor.org/info/rfc2418>.
 [RFC3934]  Wasserman, M., "Updates to RFC 2418 Regarding the
            Management of IETF Mailing Lists", BCP 25, RFC 3934,
            DOI 10.17487/RFC3934, October 2004,
            <http://www.rfc-editor.org/info/rfc3934>.

Resnick & Farrel Best Current Practice [Page 16] RFC 7776 Anti-Harassment Procedures March 2016

 [RFC7154]  Moonesamy, S., Ed., "IETF Guidelines for Conduct", BCP 54,
            RFC 7154, DOI 10.17487/RFC7154, March 2014,
            <http://www.rfc-editor.org/info/rfc7154>.
 [RFC7437]  Kucherawy, M., Ed., "IAB, IESG, and IAOC Selection,
            Confirmation, and Recall Process: Operation of the
            Nominating and Recall Committees", BCP 10, RFC 7437,
            DOI 10.17487/RFC7437, January 2015,
            <http://www.rfc-editor.org/info/rfc7437>.

10.2. Informative References

 [OmbudsteamPages]
            IESG, "Reporting Potential Harassment",
            <https://www.ietf.org/ombudsteam>.
 [Policy]   IESG, "IETF Anti-Harassment Policy",
            <https://www.ietf.org/iesg/statement/
            ietf-anti-harassment-policy.html>.

Acknowledgements

 The text in this document benefited from the lively discussion on the
 ietf@ietf.org mailing list.  Thanks to everyone who participated.
 Specific changes to this document resulted from comments by
 Abdussalam Baryun, Alessandro Vesely, S. Moonesamy, Timothy
 B. Terriberry, John Levine, Andrea Glorioso, Dave Crocker, John
 Leslie, Linda Klieforth, Brian Carpenter, Mary Barnes, Richard
 Barnes, Spencer Dawkins, Michael StJohns, Alissa Cooper, James
 Woodyatt, Tom Taylor, Sam Hartman, Stewart Bryant, Stephen Farrell,
 Nico Williams, Mark Nottingham, and Jari Arkko.  The authors would
 like to express their gratitude.
 A design team comprising Linda Klieforth, Allison Mankin, Suresh
 Krishnan, Pete Resnick, and Adrian Farrel was convened by the IETF
 Chair (Jari Arkko) to address the issue of "Remedies for Respondents
 in IETF Positions" and the text in Section 5.1.
 The authors would like to thank Ines Robles for diligent shepherding
 of this document and for tracking the many issues raised in and after
 IETF last call.
 Thanks to Greg Kapfer at ISOC, Ray Pelletier (the IAD), Scott Bradner
 and Lou Berger on the IAOC, and Scott Young and David Wilson of
 Thompson Hine for considering the legal and insurance implications.

Resnick & Farrel Best Current Practice [Page 17] RFC 7776 Anti-Harassment Procedures March 2016

Authors' Addresses

 Pete Resnick
 Qualcomm Technologies, Inc.
 5775 Morehouse Drive
 San Diego, CA  92121
 United States
 Phone: +1 858 651 4478
 Email: presnick@qti.qualcomm.com
 Adrian Farrel
 Juniper Networks
 Email: adrian@olddog.co.uk

Resnick & Farrel Best Current Practice [Page 18]

Internet Engineering Task Force (IETF) P. Resnick Request for Comments: 8716 Episteme Technology Consulting LLC BCP: 25 A. Farrel Updates: 7776 Old Dog Consulting Category: Best Current Practice February 2020 ISSN: 2070-1721

Update to the IETF Anti-Harassment Procedures for the Replacement of the

    IETF Administrative Oversight Committee (IAOC) with the IETF
                         Administration LLC

Abstract

 The IETF Anti-Harassment Procedures are described in RFC 7776.
 The IETF Administrative Oversight Committee (IAOC) has been replaced
 by the IETF Administration LLC, and the IETF Administrative Director
 has been replaced by the IETF LLC Executive Director.  This document
 updates RFC 7776 to amend these terms.
 RFC 7776 contained updates to RFC 7437.  RFC 8713 has incorporated
 those updates, so this document also updates RFC 7776 to remove those
 updates.

Status of This Memo

 This memo documents an Internet Best Current Practice.
 This document is a product of the Internet Engineering Task Force
 (IETF).  It represents the consensus of the IETF community.  It has
 received public review and has been approved for publication by the
 Internet Engineering Steering Group (IESG).  Further information on
 BCPs is available in Section 2 of RFC 7841.
 Information about the current status of this document, any errata,
 and how to provide feedback on it may be obtained at
 https://www.rfc-editor.org/info/rfc8716.

Copyright Notice

 Copyright (c) 2020 IETF Trust and the persons identified as the
 document authors.  All rights reserved.
 This document is subject to BCP 78 and the IETF Trust's Legal
 Provisions Relating to IETF Documents
 (https://trustee.ietf.org/license-info) in effect on the date of
 publication of this document.  Please review these documents
 carefully, as they describe your rights and restrictions with respect
 to this document.  Code Components extracted from this document must
 include Simplified BSD License text as described in Section 4.e of
 the Trust Legal Provisions and are provided without warranty as
 described in the Simplified BSD License.

Table of Contents

 1.  Introduction
 2.  Changes to RFC 7776
   2.1.  Changes to Section 3.4
   2.2.  Changes to Section 5
   2.3.  Changes to References to RFC 7437
     2.3.1.  Changes to Metadata
     2.3.2.  Changes to the Abstract
     2.3.3.  Changes to Section 5.1
 3.  IANA Considerations
 4.  Security Considerations
 5.  References
   5.1.  Normative References
   5.2.  Informative References
 Acknowledgements
 Authors' Addresses

1. Introduction

 The IETF Anti-Harassment Procedures are described in RFC 7776
 [RFC7776].  Those procedures include direction for the IETF Chair and
 Ombudsteam to take advice from the IETF Administrative Oversight
 Committee (IAOC) with respect to the budget available for training.
 The IAOC has been replaced by the IETF Administration LLC, and the
 IETF Administrative Director has been replaced by the IETF LLC
 Executive Director.  This document updates RFC 7776 to amend these
 terms and to update a reference.
 RFC 7776 contained updates to [RFC7437].  [RFC8713] has incorporated
 those updates, so this document also updates RFC 7776 to remove those
 updates.
 This document makes no other changes to the procedures described in
 RFC 7776.

2. Changes to RFC 7776

2.1. Changes to Section 3.4

 Section 3.4 of [RFC7776] is about the qualifications and training of
 the Ombudsteam.  The last paragraph of that section is replaced as
 follows:
 OLD
 |  In determining the appropriate training, the IETF Chair and
 |  Ombudsteam shall take professional advice and will consult with
 |  the IETF Administrative Oversight Committee (IAOC) with respect to
 |  the overall IETF budget.
 NEW
 |  In determining the appropriate training, the IETF Chair and
 |  Ombudsteam shall take professional advice and will consult with
 |  the IETF Administration LLC with respect to the overall IETF
 |  budget.
 END

2.2. Changes to Section 5

 Section 5 of [RFC7776] is about remedies available to the Ombudsteam.
 The last paragraph of that section is replaced as follows:
 OLD
 |  Where specific action is required to ensure that a remedy is
 |  realized or enforced, the Ombudsteam will make a request in
 |  writing to the IETF Secretariat and/or IETF Administrative
 |  Director (IAD) to take action as appropriate.
 NEW
 |  Where specific action is required to ensure that a remedy is
 |  realized or enforced, the Ombudsteam will make a request in
 |  writing to the IETF Secretariat and/or IETF LLC Executive Director
 |  to take action as appropriate.
 END

2.3. Changes to References to RFC 7437

 RFC 7776 updated RFC 7437 [RFC7437] by allowing the Ombudsteam to
 form a recall petition.  This document does not change any of the
 associated processes.  However, during the process of documenting the
 replacement of the IAOC by the IETF Administration LLC, RFC 7437 has
 been obsoleted by [RFC8713], and as part of that work, [RFC8713] has
 included the update from RFC 7776.
 This document updates RFC 7776 to remove the update of RFC 7437.

2.3.1. Changes to Metadata

 The following change is made to the metadata at the head of
 [RFC7776]:
 OLD
 |  Updates: 2418, 7437
 NEW
 |  Updates: 2418
 END

2.3.2. Changes to the Abstract

 The following change is made to text in the Abstract of [RFC7776]:
 DELETE
 |  This document updates RFC 7437 by allowing the Ombudsteam to form
 |  a recall petition without further signatories.
 END

2.3.3. Changes to Section 5.1

 The following change is made to text in Section 5.1 of [RFC7776]:
 OLD
 |  *  Many IETF management positions are appointed by the NomCom with
 |     confirmation from the IESG, IAB, or ISOC.  [RFC7437] describes
 |     the recall procedure for such appointments.  This document
 |     updates [RFC7437] by allowing the Ombudsteam to form a recall
 |     petition on its own and without requiring 20 signatories from
 |     the community.  Such a petition shall be treated in all ways
 |     like any other recall petition as described in [RFC7437]: that
 |     is, the fact of the petition and its signatories (the
 |     Ombudsteam) shall be announced to the IETF community, and a
 |     Recall Committee Chair shall be appointed to complete the
 |     Recall Committee process.  It is expected that the Recall
 |     Committee will receive a briefing from the Ombudsteam
 |     explaining why recall is considered an appropriate remedy.
 NEW
 |  *  The Ombudsteam may form a recall petition on its own without
 |     requiring signatures from the community as described in
 |     [RFC8713].
 END

3. IANA Considerations

 This document has no IANA actions.

4. Security Considerations

 This document has no implications for Internet security.

5. References

5.1. Normative References

 [RFC7776]  Resnick, P. and A. Farrel, "IETF Anti-Harassment
            Procedures", BCP 25, RFC 7776, DOI 10.17487/RFC7776, March
            2016, <https://www.rfc-editor.org/info/rfc7776>.
 [RFC8713]  Kucherawy, M., Ed., Hinden, R., Ed., and J. Livingood,
            Ed., "IAB, IESG, and IETF LLC Selection, Confirmation, and
            Recall Process: Operation of the IETF Nominating and
            Recall Committees", BCP 10, RFC 8713,
            DOI 10.17487/RFC8713, February 2020,
            <https://www.rfc-editor.org/info/rfc8713>.

5.2. Informative References

 [RFC7437]  Kucherawy, M., Ed., "IAB, IESG, and IAOC Selection,
            Confirmation, and Recall Process: Operation of the
            Nominating and Recall Committees", BCP 10, RFC 7437,
            DOI 10.17487/RFC7437, January 2015,
            <https://www.rfc-editor.org/info/rfc7437>.

Acknowledgements

 Thanks to Jason Livingood for suggesting the need for this document.
 Subramanian Moonesamy, Sean Turner, Jon Peterson, Roman Danyliw, and
 Barry Leiba raised useful points during their reviews of this work.

Authors' Addresses

 Pete Resnick
 Episteme Technology Consulting LLC
 503 West Indiana Avenue
 Urbana, Illinois 61801-4941
 United States of America
 Phone: +1 217 337 1905
 Email: resnick@episteme.net
 Adrian Farrel
 Old Dog Consulting
 Email: adrian@olddog.co.uk
/data/webs/external/dokuwiki/data/pages/rfc/bcp/bcp25.txt · Last modified: 2020/02/27 17:56 by 127.0.0.1

Donate Powered by PHP Valid HTML5 Valid CSS Driven by DokuWiki