RFC 7776

IETF Anti-Harassment Procedures

📅 published March 2016, from ietf

RFC 7776: IETF Anti-Harassment Procedures ✨

Okay bestie, let's get into RFC 7776 💖. It's titled IETF Anti-Harassment Procedures, and it's a Best Current Practice (that's BCP 25 🌸) published in March 2016. It's from P. Resnick (Qualcomm Technologies, Inc.) and A. Farrel (Juniper Networks), and it's on the ISSN 2070-1721 🎀. This one is a big deal because it updates RFC 2418 and RFC 7437 🔥. It doesn't obsolete anything, so nothing gets retired here.

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. It also updates RFC 7437 by letting the Ombudsteam 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 had public review and has been approved for publication by the Internet Engineering Steering Group (IESG). More info on BCPs is in Section 2 of RFC 5741 📚.

For the current status of this document, any errata, and how to send feedback, check http://www.rfc-editor.org/info/rfc7776 🧚.

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, since 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 they 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

1. Introduction ✨

The IETF has general policies for handling disruptive behavior during IETF activities 💁‍♀️. [RFC7154] gives a set of guidelines for personal interaction in the IETF, and [RFC2418] and [RFC3934] explain how to deal with disruptive behavior that happens in IETF working group face-to-face meetings and on mailing lists.

There's also other problematic behavior that can be more personal and can happen during IETF activities (meetings, mailing list discussions, or social events). It doesn't directly disrupt working group progress, but it's still unacceptable between IETF Participants 😤. This sort of behavior is described in the IESG Statement "IETF Anti-Harassment Policy" [Policy], and our older working group guidelines and procedures just aren't built to handle it. So this document sets out procedures for dealing with that harassing behavior 🫶.

These procedures are meant to be used when other IETF policies and procedures don't apply or haven't worked 🙈.

Nothing in this document should be read as interfering with due process of law. It also doesn't release anyone from any contractual or corporate policies they might be under 💜.

2. Definitions ✨

The following terms are used in this document:

  • IETF Participant: Anyone who takes part in an IETF activity, including IETF support staff 🎀.
  • Reporter: An IETF Participant who reports potential harassment to an Ombudsperson 📣.
  • Respondent: An IETF Participant who is claimed to have engaged in harassing behavior 🫣.
  • 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 ⚖️.
  • Ombudsperson: A member of the Ombudsteam 🧚.
  • Lead Ombudsperson: The Ombudsperson assigned to be the primary contact person for a particular report of potential harassment 👑.
  • 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 it doesn't try to define further precisely which behavior falls under the procedures here 🤷‍♀️. It also doesn't try to list every possible attribute that might be the basis for harassment. The one thing it does note is that harassment may be targeted at an individual, directed at a specific group of people, or more generally impact a broader class of people 🌈.

This document is about 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 harassment can happen is when submitting to such conduct is made, either explicitly or implicitly, a term or condition of an individual's participation in IETF activities, or when it's used as a basis for decisions affecting that individual's relationship to the IETF 😭.

Generally, disruptive behavior that happens on an IETF general or working group mailing list, or during a face-to-face or virtual meeting of a working group or the IETF plenary, can be dealt with by our normal procedures. Harassing behavior is more appropriately handled by the procedures described here ✨. That said, there are plausible reasons to address behaviors that happen during working group meetings using these procedures. This document gives some guidance to people involved in these situations so they can decide how to handle particular incidents, but the final decision involves judgment and the guidance of the Ombudsteam 🧠.

Any definition of harassment prohibited by an applicable law can be subject to this set of procedures 🍓.

3. The Ombudsteam ✨

This section describes the role of the Ombudsteam: how Ombudspersons are appointed, their qualifications and training, how long they serve, any compensation the IETF gives them for their service, and how they can be removed from service 💼. The general operational procedures for the Ombudsteam are in Sections 4, 5, and 6.

3.1. Size of the Ombudsteam 🌷

The Ombudsteam SHALL comprise no fewer than three people. Now and then the size may dip below that number because of changes in membership, but the team will be rapidly brought back 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 workload, and the opinions of the seated Ombudsteam. The IETF Chair may also consider elements of diversity in making this decision 🌈.

3.3. Professional Advisors 💅

It's 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 💖.

3.4. Qualifications and Training 🎓

It's not expected that there will be candidates who have all of the necessary Ombudsperson skills and training and also a clear understanding and familiarity with 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 less experience dealing with harassment issues. Since the IETF Chair may regard all of these attributes as essential for the team, the IETF is committed to providing training (or funding for it) as deemed necessary for appointed Ombudspersons 🧚‍♀️. When working out the appropriate training, the IETF Chair and Ombudsteam SHALL take professional advice and will consult with the IETF Administrative Oversight Committee (IAOC) about 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's understood, though, that life happens, so an Ombudsperson may 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. So no one gets yeeted mid-case. 🫶

It is entirely at the discretion of the IETF Chair whether a serving Ombudsperson is reappointed at the end of their term. Given how sensitive this role is, and how much training it takes, plus the ideal being a lack of activity (iykyk 🙈), the IETF Chair may well choose to reappoint a successful and still-willing Ombudsperson for a number of two-year terms. Main character stability ✨

3.6. Compensation

An Ombudsperson shall receive no compensation from the IETF for their services. This includes, but is not limited to:

  • IETF meeting fees
  • Remuneration for time spent
  • Out-of-pocket expenses (such as telephone charges)
  • Travel or accommodation expenses

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 explaining themselves 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. Recusal protection, bestie 🛡️🌸

3.8. Disputes with the IETF Chair Regarding the Ombudsteam

If an individual disagrees with an action taken by the IETF Chair regarding the appointment, removal, or management of an Ombudsperson or the Ombudsteam, that person should first talk it out with the IETF Chair directly. If the IETF Chair can't resolve it, 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. Escalation ladder, but make it cute 🪜💜

  1. 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 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 is about the formal duties of the Ombudsteam, 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. Consent is everything 🫶💖

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 talk through 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 to keep it from happening 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. In that 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. You're in control of your own case, periodt 💅🦋

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

The practices MUST include at least the following high-level components:

  • 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. 🧚
  • 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 MUST be encrypted before it is stored, using tools similar to those used by the Nominating Committee (NomCom). 🔐
  • 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). 📞
  • The Ombudsteam shall endeavor to complete its investigation in a timely manner. ⏰
  • 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 ease any worries individuals may have about reporting an incident they feel should be reviewed or cooperating with an investigation. Nobody gets punished for speaking up 🛡️💜
  • In all cases, the Ombudsteam will strive to maintain confidentiality for all parties, including the very fact of contact with the Ombudsteam. 🤫
  • 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. 📝
  • 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 ✨

okay so after the Ombudsteam has looked at everything about the harassment complaint, they should write up a brief summary of what happened and what they concluded, then talk it through with all the parties 🫶 the whole point is to be super clear about where the Ombudsteam landed and to try to get everyone on the same page 💖

If the Ombudsteam decides that harassment did happen, they're expected to figure out what happens next 👑

  • Sometimes there's already a mechanism or an established IETF process for the exact thing that went down 🌸 In that case, the Ombudsteam may decide the misbehavior is best handled through the regular IETF procedures for disruptive behavior, and may help the Reporter bring it to the attention of the WG Chair or IESG member who can deal with the incident 🦋
  • There's a whole spectrum of remedies that could fit, depending on the situation 🌈 At the gentle end, the Ombudsteam might talk things through with the Respondent and come up with a plan so there's 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's no individual Subject) to address the issue. If mediation fails, the Ombudsteam can decide to apply other remedies, including those discussed here.
  • At the other end of the spectrum, the Ombudsteam could decide the Respondent is no longer permitted to take part in a particular IETF activity 😬 like ejecting them from a meeting, or requiring that they can no longer attend future meetings, to make sure the reported harassment can't continue or escalate. If the Respondent holds a management position in the IETF, these remedies may make it really hard or impossible for them to do the duties that come with that position. Further remedies may be applied to Respondents in IETF management positions, as described in Section 5.1. 💀
  • When picking the remedy, the Ombudsteam may talk with the Reporter, Subject, or Respondent to see what kind of impact the remedy might have on any of them 💜 But the Ombudsteam has ultimate responsibility for the choice of remedy, so the final call is theirs 👑
  • In all cases, the Lead Ombudsperson tells the Respondent about the decision and imposes the remedy as appropriate 📣 When the remedy is removal from IETF activities, the Lead Ombudsperson will confidentially notify the Secretariat in writing, so the Secretariat can take whatever logistical actions are needed to make it happen. Only the remedy itself shall be disclosed to the Secretariat, not any information about the nature of the harassment 🤐

Where specific action is needed to make sure a remedy is realized or enforced, the Ombudsteam will make a request in writing to the IETF Secretariat and/or the IETF Administrative Director (IAD) to take action as appropriate 🧚

5.1. Remedies for Respondents in IETF Positions

the remedies we just talked about are equally applicable to all IETF Participants, no matter what role they have 🫶

the Ombudsteam will want to be aware of how a remedy affects someone's ability to do their duties in IETF management positions, but that shouldn't stop them from applying remedies they think are appropriate 💅 Per Section 5, the Ombudsteam is expected to apply proportionality and reasonableness, and to consider the impact of the remedy on the Respondent. Per Section 4.1, the Ombudsteam may communicate with the Respondent to assess the impact the remedy might have 🌷

sometimes it might be inappropriate for a Respondent to keep their IETF management position, meaning the remedy the Ombudsteam wants is removing them from that position 😭 Here's the tea: the Ombudsteam can't remove a Respondent who's in an IETF management position all by itself 🙅‍♀️ But it can recommend existing mechanisms within the IETF process for removing people from IETF management positions, like this:

  • Lots of IETF management positions are appointed by the NomCom with confirmation from the IESG, IAB, or ISOC. [RFC7437] describes the recall procedure for those appointments. This document updates [RFC7437] by letting the Ombudsteam form a recall petition on its own, without needing 20 signatories from the community 🎀 Such a petition shall be treated in all ways like any other recall petition described in [RFC7437]: 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's expected that the Recall Committee will get a briefing from the Ombudsteam explaining why recall is considered an appropriate remedy 📋
  • Other IETF management positions are filled by appointment from the IESG, the IAB, the ISOC Board, or the ISOC President. In those cases, the Ombudsteam may recommend to the appointing body that the Respondent be removed from their position 🧡
  • Many IETF management positions are filled through appointment by an AD or by the ADs for an IETF Area. In those cases, the Ombudsteam may recommend in writing to those ADs that the Respondent be removed from their position ✍️
  • Some other IETF management positions are filled through appointment by WG Chairs. In those cases, the Ombudsteam may make a written recommendation 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's expected that the person or body responsible for removing someone from an IETF management position will take the Ombudsteam's recommendation extremely seriously, and that it would be very unusual for them to not act on it 🥹 It is not the intent that this person or body try to reinvestigate the circumstances of the harassment. They're expected to understand that they aren't qualified to evaluate or handle harassment issues 🙈 They must seek to preserve confidentiality. If the person or body feels removal from the position isn't the correct remedy, they must discuss their concern with the Ombudsteam 💬

If an AD declines to follow the Ombudsteam's recommendation, and the AD fails to convince the Ombudsteam of the reasons for that, the Ombudsteam should raise the issue with the whole IESG, while still trying to keep things confidential 🔒 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 forced removals from management positions must be considered by the Ombudsteam as acts of last resort 🚨 That means before a Respondent is recommended for removal, the Ombudsteam should consider other possible remedies and should talk through the situation with the Respondent, giving them plenty of 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. When recommending action like the above, the Ombudsteam will clearly have to indicate that some event occurred that led to the recommendation, but it's not expected that they'll need to divulge a lot more information. It should be enough that the Ombudsteam explains how severe the situation is, that they've considered other, lesser remedies, and that they deem the recommended remedy appropriate 🧠

When someone is removed from their position, it may become apparent to the IETF community that the removal was a remedy recommended by the Ombudsteam. Even so, revealing the underlying events should be avoided as far as possible 🤫

5.2. Purpose of Remedies

okay the purpose of the anti-harassment policy is to prevent all incidents of harassment in the IETF 💜 The procedures in this document give a way for any harassment that does happen to be reported and handled both sympathetically and effectively 🫶 The policy also sends a super clear message that the IETF does not tolerate harassment in any form 📣

However, any remedy is imposed to try to make sure the incident doesn't escalate, and to make a similar situation unlikely to happen again with the same Respondent in the future 🦋

Because handling harassment incidents (including imposing remedies) is confidential, an imposed remedy can't itself serve as a deterrent to others, and it can't 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 🚫 Still, knowing that a range of remedies exists, and that there are processes for applying them, shows how seriously the IETF takes this, and serves as a deterrent to potential offenders 🛡️

The Ombudsteam is expected to apply the considerations above, as well as proportionality and reasonableness, when selecting a remedy 🌈 They're asked to consider the impact of the remedy on the Respondent as well as on the Subject ✨

6. Disputes with the Ombudsteam ✨

okay bestie, so say the Subject (or the Reporter, if there's no individual Subject) or the Respondent isn't happy with what the Ombudsteam decided 🥺. The vibe is that they should first chat with the Lead Ombudsperson and talk it through. 💬 If that doesn't fix things, the issue can be taken to the IETF Chair. 👑

If needed, the IETF Chair can step back from any part of this process (more on that in Section 7) 🙅‍♀️ and ask the IESG to pick another of its members to take over. That person is called the "delegated IESG member" 🎀.

The IETF Chair (or the delegated IESG member, if the Chair has stepped back) will try to sort it out by talking with the unhappy party and the Lead Ombudsperson 🫶. If that still doesn't land, the Ombudsteam's decision can be formally appealed. 📜 But the appeal is strictly about one thing: did the Ombudsteam exercise due diligence? That covers both the call on whether harassment happened and how they picked the remedy 🔍. The appeal is NOT a chance to re-investigate what happened or haggle over how severe the remedy is 🙅‍♀️💅.

Everything about the appeal, including the fact that it was filed, stays confidential 🤫. It also gets recorded and stored securely for future reference 🗂️.

The appeal gets evaluated by the IETF Chair (or the delegated IESG member), plus two other IESG members picked by the Chair (or the delegated IESG member) and confirmed by the appellant. This group is called the Appeals Group 👯‍♀️. They shall convene as quickly as possible to look at the appeal and decide it. If the impacts are immediate and tied to taking part in a meeting that's currently happening, they have to do it within 24 hours of getting the appeal ⏰😭. The Appeals Group may ask the appellant and the Lead Ombudsperson for statements or other info to look at 📝.

If the Appeals Group decides the Ombudsteam did use due diligence, they tell the appellant, and that's the end of it ✅. If they find the due diligence was NOT there 😬, the Appeals Group reports that back to the Ombudsteam and consults with them on how to finish the due diligence 🛠️.

Because the goal is keeping everything as confidential as possible, the Appeals Group's decision is FINAL on whether the Ombudsteam used due diligence in its decision. 🔒 The only further option left is to claim that the procedures themselves (that is, the procedures described in this document) are inadequate or insufficient to protect the rights of all parties 🧐. That claim can be made in an appeal to the Internet Society Board of Trustees, as described in Section 6.5.3 of [RFC2026]. Even then, the particulars of the incident stay confidential 🤐💖.

7. Conflicts of Interest ✨

if there's any conflict of interest, the conflicted person (a member of the Ombudsteam, a member of the Appeals Group, the IETF Chair, and so on) is expected to recuse themselves 🙅‍♀️. No drama, just step aside 💅.

A conflict of interest can come up if someone who's involved in handling a harassment report is also the Reporter, the Respondent, or the Subject 😳. A conflict also exists if the person handling the report is closely tied to any of the Reporter, Respondent, or Subject, either personally or through an affiliation 🫣.

Just so we're clear 💯, recusal here means completely stepping out of any advisory or decision-making part of any process tied to handling a harassment report, a remedy that came from a harassment report, or an appeal into the handling of a harassment report 🚪. That means a recused person has no more right to take part in or watch the process than anyone else in the community in the same situation 👀. For example, an Ombudsperson who is the subject of a harassment complaint shall not be privy to the deliberations of another Ombudsperson handling the report 🙈. And an IESG member who was party to an appeal can't sit in on the Appeals Group's discussions either ❌.

If there's 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 🤫

This document keeps bringing up requirements to keep information confidential 🔐. This section gathers all of those in one spot so it's easy to find 🧚.

The Ombudsteam is expected to strive for confidentiality 💜. Confidentiality protects the Reporter, the Subject, and the Respondent in any case of alleged harassment 🫶. It also protects witnesses and anyone else the Ombudsteam consults during an 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's needed to run 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 that 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 the investigation confidential 🤍.

Real talk: members of the community will probably want to know more once they've heard some details about a harassment case 👀. The community is asked to show restraint and trust the Ombudsteam 🙏. This process is designed to provide remedies, not punishment (see Section 5.2), and public discussion of the events or remedies is not 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>.

[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 took part 🥰.

Specific changes to this document came 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 made up of 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 🌈🦋

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
📦 where this page comes from