| Internet Engineering Task Force | P. Resnick |
| Internet-Draft | Qualcomm Technologies, Inc. |
| BCP: 25 | A. Farrel |
| Updates: 2418 (if approved) | Juniper Networks |
| Intended status: Best Current Practice | April 29, 2014 |
| Expires: October 31, 2014 |
IETF Anti-Harassment Procedures
draft-farrresnickel-harassment-02
IETF participants must not engage in harassment while at IETF meetings, virtual meetings, social events, or on mailing lists. This document lays out procedures for managing and enforcing this policy.
This version of this document is provided as a continued point for discussion and does not represent the firm opinions of the authors. Furthermore, the ideas presented in this document have not been fully discussed and reviewed by the IESG.
This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet-Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress."
This Internet-Draft will expire on October 31, 2014.
Copyright (c) 2014 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.
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, often more interpersonal, behavior 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 on an "IETF Anti-Harassment 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 for the legal system under the jurisdiction of which any harassment takes place. Similarly, it does not release any person from any contractual or corporate policies to which they may be subject.
The following terms are used in this document:
The IESG statement on harassment http://www.ietf.org/iesg/statement/ietf-anti-harassment-policy.html defines harassment as "unwelcome hostile or intimidating behavior, in particular speech and behavior that is sexually aggressive or intimidates based on attributes like race, gender, religion, age, color, national origin, ancestry, disability, sexual orientation, or gender identity." This document adopts that definition and does not attempt to further precisely define behavior that falls under the set of procedures identified here except to note that it may be targeted at an individual, directed at a specific group of people, or more generally impacting a broader class of people. 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 that is interpersonal is more easily 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.
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 recompense for their service, and how they may be removed from service. The general operational procedures for the Ombudsteam are described in Section 4, Section 5, and Section 6.
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
The Ombudsteam is appointed by the IETF Chair. The appointment is solely the responsibility of the IETF Chair although the Chair may choose to consult with the IESG, the IAB, and with the ISOC Board of Trustees. Furthermore, the IETF Chair may take opinion from the 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 skillsets available, the work load, and the opinions of the seated Ombudsteam. Furthermore, the IETF Chair may consider elements of diversity in making this decision.
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 is committed to funding such advice on an "as needed" basis.
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 an appointment, the IETF is committed to provide funding for necessary training for appointed Ombudspersons. In determining the appropriate training, the IETF chair and Ombudsteam shall take professional advice.
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.
It is entirely at the discretion of the IETF Chair whether a serving Ombudsperson is reappointed at the end of their term.
An Ombudsperson shall receive no recompense for their services. This includes, but is not limited to:
The IETF will, however, meet the costs of training when agreed to by the IETF Chair as described in Section 3.4.
The IETF Chair may remove a serving Ombudsperson before the end of their term without explanation to the community. Such an action shall be appealable as described in Section 6.
An Ombudsperson shall not be removed from service, even if their term has expired, if the IETF Chair is recused as described in Section 7.
If an individual should disagree with an action taken by the IETF Chair regarding the appointment, removal, or management of the Ombudsperson, 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.
Any IETF participant who believes that they or other IETF participants have been harassed or may have been harassed may bring the concern to the attention of any serving Ombudsperson. This can be done by email to "ombudsteam@ietf.org", or can be done directly to a chosen Ombudsperson. Direct contact information for the Ombudsteam, including the email addresses to which "ombudsteam@ietf.org" is forwarded, can be found at https://www.ietf.org/ombudsteam.
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 mutually agreed between the Reporter and that Ombudsperson.
The Lead Ombudsperson may share any 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, they should make this known to the Lead Ombudsperson as soon as possible.
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 detailed investigation of the matter, and may subsequently impose a remedy as described in Section 5.
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 objection to the processes that are not addressed should result in an RFC 2026 Section 6.5.3 appeal and/or a recall petition against the IETF Chair (and the rest of the IESG if appropriate) if they do not address the concern.
The practices must include at least the following high-level components:
When investigating reports and determining remedies, it is up to the Ombudsteam whether they choose to act as a body or delegate duties to the Lead Ombudsperson.
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.
It is understood that the purpose of a remedy is not punishment. That is, the remedy is imposed in order to rectify the situation (to "put things right"), 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.
A remedy is not to be imposed for the purposes of retribution or as a deterrent to others. It is also not intended to teach the community how to behave - there is RFC 7154 for that. The Ombudsteam are expected to apply considerations of proportionality and reasonableness in selecting a remedy, and are asked to consider the impact of the remedy on the Respondent as well as on the Subject.
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.
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 in both 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.
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.
In the event of any conflict of interest, the conflicted person (member of the Obmudsteam, member of the Appeals Group, IETF Chair, etc.) is expected to recuse themselves.
A conflict of interest may arise is 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, therefore, 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 and the IESG will select a single person to take the Chair's role in the appeal process.
"Human beings the world over need freedom and security that they may be able to realize their full potential." -- Aung San Suu Kyi
| [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. |
| [RFC3934] | Wasserman, M., "Updates to RFC 2418 Regarding the Management of IETF Mailing Lists", BCP 25, RFC 3934, October 2004. |
| [RFC7154] | Moonesamy, S., "IETF Guidelines for Conduct", BCP 54, RFC 7154, March 2014. |
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, Spencer Dawkins, and Michael StJohns. The authors would like to express their gratitude.
This Appendix to be removed before publication as an RFC.
This Appendix is used to track issues that have been raised for discussion, but which the authors have not yet addressed.