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
AbstractIETF 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.
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. 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
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.
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.
4, 5, and 6. Section 3.2
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.
The IETF will, however, meet the costs of training when agreed to by the IETF Chair as described in Section 3.4. 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. Section 6.5.4 of [RFC2026] apply to this sort of appeal. 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.
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. 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.
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.
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.
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. 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:
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
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. 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.
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. 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.
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. Section 6.
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. [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>.
[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>. [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>. 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.