idnits 2.17.1 draft-farrresnickel-harassment-10.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year (Using the creation date from RFC2418, updated by this document, for RFC5378 checks: 1997-03-25) -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (November 3, 2015) is 3097 days in the past. Is this intentional? Checking references for intended status: Best Current Practice ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) ** Obsolete normative reference: RFC 7437 (Obsoleted by RFC 8713) Summary: 1 error (**), 0 flaws (~~), 1 warning (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Internet Engineering Task Force P. Resnick 3 Internet-Draft Qualcomm Technologies, Inc. 4 BCP: 25 A. Farrel 5 Updates: 2418, 7437 (if approved) Juniper Networks 6 Intended status: Best Current Practice November 3, 2015 7 Expires: May 6, 2016 9 IETF Anti-Harassment Procedures 10 draft-farrresnickel-harassment-10 12 Abstract 14 IETF Participants must not engage in harassment while at IETF 15 meetings, virtual meetings, social events, or on mailing lists. This 16 document lays out procedures for managing and enforcing this policy. 18 This document updates RFC 2418 by defining new Working Group 19 guidelines and procedures. This document updates RFC 7437 by 20 allowing the Ombudsteam to form a recall petition without further 21 signatories. 23 Status of This Memo 25 This Internet-Draft is submitted in full conformance with the 26 provisions of BCP 78 and BCP 79. 28 Internet-Drafts are working documents of the Internet Engineering 29 Task Force (IETF). Note that other groups may also distribute 30 working documents as Internet-Drafts. The list of current Internet- 31 Drafts is at http://datatracker.ietf.org/drafts/current/. 33 Internet-Drafts are draft documents valid for a maximum of six months 34 and may be updated, replaced, or obsoleted by other documents at any 35 time. It is inappropriate to use Internet-Drafts as reference 36 material or to cite them other than as "work in progress." 38 This Internet-Draft will expire on May 6, 2016. 40 Copyright Notice 42 Copyright (c) 2015 IETF Trust and the persons identified as the 43 document authors. All rights reserved. 45 This document is subject to BCP 78 and the IETF Trust's Legal 46 Provisions Relating to IETF Documents 47 (http://trustee.ietf.org/license-info) in effect on the date of 48 publication of this document. Please review these documents 49 carefully, as they describe your rights and restrictions with respect 50 to this document. Code Components extracted from this document must 51 include Simplified BSD License text as described in Section 4.e of 52 the Trust Legal Provisions and are provided without warranty as 53 described in the Simplified BSD License. 55 Table of Contents 57 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 58 2. Definitions . . . . . . . . . . . . . . . . . . . . . . . . . 3 59 3. The Ombudsteam . . . . . . . . . . . . . . . . . . . . . . . 4 60 3.1. Size of the Ombudsteam . . . . . . . . . . . . . . . . . 4 61 3.2. Appointing the Ombudsteam . . . . . . . . . . . . . . . . 5 62 3.3. Professional Advisors . . . . . . . . . . . . . . . . . . 5 63 3.4. Qualifications and Training . . . . . . . . . . . . . . . 5 64 3.5. Term of Service . . . . . . . . . . . . . . . . . . . . . 5 65 3.6. Compensation . . . . . . . . . . . . . . . . . . . . . . 6 66 3.7. Removal . . . . . . . . . . . . . . . . . . . . . . . . . 6 67 3.8. Disputes with the IETF Chair regarding the Ombudsteam . . 6 68 4. Handling Reports of Harassment . . . . . . . . . . . . . . . 7 69 4.1. Ombudsteam Operating Practices . . . . . . . . . . . . . 8 70 5. Remedies . . . . . . . . . . . . . . . . . . . . . . . . . . 9 71 5.1. Remedies for Respondents in IETF Positions . . . . . . . 11 72 5.2. Purpose of Remedies . . . . . . . . . . . . . . . . . . . 13 73 6. Disputes with the Ombudsteam . . . . . . . . . . . . . . . . 13 74 7. Conflicts of Interest . . . . . . . . . . . . . . . . . . . . 14 75 8. Confidentiality . . . . . . . . . . . . . . . . . . . . . . . 15 76 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 16 77 10. Security Considerations . . . . . . . . . . . . . . . . . . . 16 78 11. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 16 79 12. References . . . . . . . . . . . . . . . . . . . . . . . . . 16 80 12.1. Normative References . . . . . . . . . . . . . . . . . . 16 81 12.2. Informative References . . . . . . . . . . . . . . . . . 17 82 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 17 84 1. Introduction 86 The IETF has general policies for managing disruptive behavior in the 87 context of IETF activities. In particular, [RFC7154] provides a set 88 of guidelines for personal interaction in the IETF, and [RFC2418] and 89 [RFC3934] give guidelines for how to deal with disruptive behavior 90 that occurs in the context of IETF working group face-to-face 91 meetings and on mailing lists. 93 However, there is other problematic behavior that may be more 94 personal and that can occur in the context of IETF activities 95 (meetings, mailing list discussions, or social events) that does not 96 directly disrupt working group progress, but nonetheless is 97 unacceptable behavior between IETF Participants. This sort of 98 behavior, described in the IESG Statement on an "IETF Anti-Harassment 99 Policy" [Policy], is not easily dealt with by our previously existing 100 working group guidelines and procedures. Therefore, this document 101 sets forth procedures to deal with such harassing behavior. 103 These procedures are intended to be used when other IETF policies and 104 procedures do not apply or have been ineffective. 106 Nothing in this document should be taken to interfere with the due 107 process of law. Similarly, it does not release any person from any 108 contractual or corporate policies to which they may be subject. 110 2. Definitions 112 The following terms are used in this document: 114 IETF Participant: Anyone who participates in an IETF activity, 115 including IETF support staff. 117 Reporter: An IETF Participant who reports potential harassment to 118 an Ombudsperson. 120 Respondent: An IETF Participant who is claimed to have engaged in 121 harassing behavior. 123 Ombudsteam: A group of people who have been selected to take 124 reports of potential harassment, evaluate them, and impose 125 appropriate actions and/or remedies to address the circumstances. 127 Ombudsperson: A member of the Ombudsteam. 129 Lead Ombudsperson: The Ombudsperson assigned to be the primary 130 contact person for a particular report of potential harassment. 132 Subject: An individual, group, or class of IETF Participant to 133 whom the potentially harassing behavior was directed or who might 134 be subject to the behavior. 136 The IESG statement on harassment [Policy] gives a general definition 137 of harassment as "unwelcome hostile or intimidating behavior -- in 138 particular speech and behavior that is sexually aggressive or 139 intimidates based on attributes like race, gender, religion, age, 140 color, national origin, ancestry, disability, sexual orientation, or 141 gender identity." This document adopts that general definition, but 142 does not attempt to further precisely define behavior that falls 143 under the set of procedures identified here, nor does it attempt to 144 list every possible attribute that might be the basis for harassment, 145 except to note that it may be targeted at an individual, directed at 146 a specific group of people, or more generally impact a broader class 147 of people. 149 This document concerns itself with harassment that has the purpose or 150 effect of unreasonably interfering with an individual's participation 151 in IETF activities or of creating an environment within the IETF that 152 would be intimidating, hostile, or offensive in such a situation. 153 One way in which harassment can occur is when submission to such 154 conduct is made either explicitly or implicitly a term or condition 155 of an individual's participation in IETF activities or is used as a 156 basis for decisions affecting that individual's relationship to the 157 IETF. 159 In general, disruptive behavior that occurs in the context of an IETF 160 general or working group mailing list, or happens in a face-to-face 161 or virtual meeting of a working group or the IETF plenary, can be 162 dealt with by our normal procedures, whereas harassing behavior is 163 more appropriately handled by the procedures described here. 164 However, there are plausible reasons to address behaviors that take 165 place during working-group meetings using these procedures. This 166 document gives some guidance to those involved in these situations in 167 order to decide how to handle particular incidents, but the final 168 decision will involve judgment and the guidance of the Ombudsteam. 170 Any definition of harassment prohibited by an applicable law can be 171 subject to this set of procedures. 173 3. The Ombudsteam 175 This section describes the role of the Ombudsteam in terms of the 176 appointment of Ombudspersons, their qualifications and training, the 177 length of the term of service, any compensation from the IETF for 178 their service, and how they may be removed from service. The general 179 operational procedures for the Ombudsteam are described in Section 4, 180 Section 5, and Section 6. 182 3.1. Size of the Ombudsteam 184 The Ombudsteam shall comprise no fewer than three people. From time 185 to time, the size may fall below that number owing to changes in 186 membership, but the team will be rapidly brought up to size through 187 new appointments. The team may be grown to a larger size as 188 described in Section 3.2 190 3.2. Appointing the Ombudsteam 192 The Ombudsteam is appointed by the IETF Chair. The appointment is 193 solely the responsibility of the IETF Chair who may choose to consult 194 with members of the IETF community. 196 The IETF Chair is encouraged to appoint at least some of the 197 Ombudsteam from within the IETF community. 199 The IETF Chair may choose to solicit nominations or advertise the 200 post. This is entirely at the discretion of the IETF Chair. 202 The IETF Chair is also free to decide to appoint more than three 203 Ombudspersons to the Ombudsteam. This may depend on the skillsets 204 available, the work load, and the opinions of the seated Ombudsteam. 205 Furthermore, the IETF Chair may consider elements of diversity in 206 making this decision. 208 3.3. Professional Advisors 210 It is recognized that the Ombudsteam may need to call on professional 211 services from external advisors for certain matters including legal 212 and Human Resources (HR) advice. The IETF (via the IASA) is 213 committed to funding such advice as needed. 215 3.4. Qualifications and Training 217 It is not expected that there will be candidates with all of the 218 necessary ombudsperson skills and training who also have a clear 219 understanding and familiarity with the IETF processes and culture. 220 The Chair might choose someone with a great deal of professional 221 experience evaluating and mediating harassment disputes, but little 222 exposure to the IETF, or could select someone with more exposure to 223 the IETF community, but without as much experience dealing with 224 issues of harassment. Since all of these attributes may be regarded 225 by the IETF Chair as essential for the team, the IETF is committed to 226 providing training (or funding for it) as deemed necessary for 227 appointed Ombudspersons. In determining the appropriate training, 228 the IETF chair and Ombudsteam shall take professional advice and will 229 consult with the IAOC with respect to the overall IETF budget. 231 3.5. Term of Service 233 An Ombudsperson shall be appointed for a two year term. That is, the 234 Ombudsperson is making a commitment to serve for two years. It is 235 understood, however, that circumstances may lead an Ombudsperson to 236 resign for personal or other reasons. See also Section 3.7. 238 If an Ombudsperson's term ends while they are acting as Lead 239 Ombudsperson for a report as described in Section 4, that 240 Ombudsperson's term shall be extended until the handling of that 241 report has been completed. 243 It is entirely at the discretion of the IETF Chair whether a serving 244 Ombudsperson is reappointed at the end of their term. Given the 245 sensitivity of, and training required for, this role and the ideal 246 being a lack of activity, it is likely the IETF chair may choose to 247 re-appoint a successful and still-willing Ombudsperson for a number 248 of two year terms. 250 3.6. Compensation 252 An Ombudsperson shall receive no compensation from the IETF for their 253 services. This includes, but is not limited to: 255 o IETF meeting fees 257 o Remuneration for time spent 259 o Out-of-pocket expenses (such as telephone charges) 261 o Travel or accommodation expenses 263 The IETF will, however, meet the costs of training when agreed to by 264 the IETF Chair as described in Section 3.4. 266 3.7. Removal 268 The IETF Chair may remove a serving Ombudsperson before the end of 269 their term without explanation to the community including during the 270 course of processing an active case. Such an action shall be 271 appealable as described in Section 3.8. 273 An Ombudsperson shall not be removed from service, even if their term 274 has expired, during the period that the IETF Chair is recused as 275 described in Section 7. Once the case that led to the Chair being 276 recused has been closed, normal processes resume. 278 3.8. Disputes with the IETF Chair regarding the Ombudsteam 280 If an individual should disagree with an action taken by the IETF 281 Chair regarding the appointment, removal, or management of an 282 Ombudsperson or the Ombudsteam, that person should first discuss the 283 issue with the IETF Chair directly. If the IETF Chair is unable to 284 resolve the issue, the dissatisfied party may appeal to the IESG as a 285 whole. The IESG shall then review the situation and attempt to 286 resolve it in a manner of its own choosing. The procedures of 287 Section 6.5.4 of [RFC2026] apply to this sort of appeal. 289 4. Handling Reports of Harassment 291 Any IETF Participant who believes that they have been harassed, or 292 that any other IETF Participant or group of IETF Participants has 293 been or may have been harassed, should bring the concern to the 294 attention of any serving Ombudsperson. This can be done by email to 295 ombuds@ietf.org, or can be done directly to a chosen Ombudsperson. 296 Direct contact information for the members of the Ombudsteam, 297 including the email addresses to which "ombuds@ietf.org" is 298 forwarded, can be found at https://www.ietf.org/ombudsteam 299 [OmbudsteamPages]. 301 All IETF Participants are encouraged to talk with the Ombudsteam if 302 they are uncomfortable or unsure about any behaviors. Though much of 303 this document relates to the formal duties of the Ombudsteam, it 304 should be understood that an important function of the Ombudsteam is 305 to provide confidential advice and counsel for any IETF Participant 306 regarding issues of harassment. The Ombudsteam will not commence a 307 formal investiagtion of any potential incident of harassment without 308 agreement by the Reporter and Subject. 310 When a Reporter brings an incident of potential harassment to the 311 attention of the Ombudsteam, a single Ombudsperson shall be 312 designated as the primary contact person (the Lead Ombudsperson) for 313 the report. When the Reporter contacts a single Ombudsperson, that 314 Ombudsperson shall be the Lead Ombudsperson for the report unless 315 mutually agreed between the Reporter and that Ombudsperson. 317 Information conveyed by the Reporter should be kept in confidence by 318 the Lead Ombudsperson to the greatest extent possible. When 319 necessary (for example, in the course of a formal investigation), the 320 Lead Ombudsperson may share information regarding the report with the 321 rest of the Ombudsteam except when an Ombudsperson is recused (see 322 Section 7). If a Reporter believes that a member of the Ombudsteam 323 should recuse themself, they should make this known to the Lead 324 Ombudsperson as soon as possible. See Section 4.1 for further 325 discussion of the confidentiality requirements of the Ombudsteam. 327 The Lead Ombudsperson will discuss the events with the Reporter and 328 may give advice including recommendations on how the Reporter can 329 handle the issue on their own as well as strategies on how to prevent 330 the issue from arising again. The Lead Ombudsperson may also 331 indicate that the issue would be best handled using regular IETF 332 procedures (such as those for dealing with disruptive behavior) 333 outside the context of harassment, and in this case the Lead 334 Ombudsperson will provide assistance in using the relevant IETF 335 procedures. Otherwise, with agreement to proceed from the Subject 336 (or the Reporter if there is no individual Subject), the Ombudsteam 337 may initiate detailed investigation of the matter, and may 338 subsequently, after completing their investigation, impose a remedy 339 as described in Section 5. The Subject can withdraw their agreement 340 to proceed at any time. 342 4.1. Ombudsteam Operating Practices 344 The Ombudsteam is responsible for devising and documenting their 345 operating practices. These practices must be discussed with the IESG 346 and published in a publicly visible place (such as on the IETF web 347 site). Discussion with the IETF community is encouraged and, while 348 IETF consensus is not necessary, significant objections to the 349 processes that are not addressed should result in an appeal per 350 Section 6.5.3 of [RFC2026] and/or a recall petition against the IETF 351 Chair (and any of the rest of the IESG if appropriate) if they do not 352 address the concern. 354 The practices must include at least the following high-level 355 components: 357 o Each member of the Ombudsteam is expected to be present at the 358 majority of IETF meetings and to be available for face-to-face 359 discussions. The Ombudsteam is expected to arrange itself so that 360 there is coverage of every IETF meeting by at least one 361 Ombudsperson. 363 o The Ombudsteam shall strive to keep all information brought to it 364 in strict confidence. However, it is acknowledged that the 365 operation of the Ombudsteam may involve sharing of information 366 within the team, and may require that the parties to the complaint 367 (the Reporter, Respondent, and Subject) learn some of the 368 confidential information. The Ombudsteam is responsible for 369 documenting its expectations of when disclosures of confidential 370 information are likely to be made in the process and to whom. Any 371 electronic information (such as email messages) that needs to be 372 archived shall be encrypted before it is stored using tools 373 similar to those used by NomCom. 375 o When conducting a detailed investigation of the circumstances 376 regarding the complaint of harassment, the Ombudsteam may contact 377 the Respondent and request a meeting in person or by a voice call. 378 The Ombudsteam shall have contacted the Respondent and either 379 discussed the matter, or ascertained the Respondent's 380 unwillingness to cooperate, prior to deciding to impose a remedy 381 as described in Section 5. The Respondent is not obliged to 382 cooperate, but the Ombudsteam may consider failure to cooperate 383 when determining a remedy (Section 5). 385 o The Ombudsteam shall endeavor to complete its investigation in a 386 timely manner. 388 o Any individuals who make a good faith report of harassment or who 389 cooperate with an investigation shall not be subject to 390 retaliation for reporting, complaining, or cooperating, even if 391 the investigation, once completed, shows no harassment occurred. 392 Anti-retaliation is noted here to alleviate concerns individuals 393 may have with reference to reporting an incident they feel should 394 be reviewed or cooperating with an investigation. 396 o In all cases the Ombudsteam will strive to maintain 397 confidentiality for all parties including the very fact of contact 398 with the Ombudsteam. 400 o The results of investigations as reported to the Subject or 401 Respondent, and all requests for remedial action (such as to the 402 IETF Secretariat) shall be in writing. 404 o The Ombudsteam shall keep written records of their investigation 405 and any contacts or interviews such that there is material 406 available in the event of an appeal or legal action. Such records 407 shall be held securely and in confidence. 409 When investigating reports of harassment and determining remedies, it 410 is up to the Ombudsteam whether they choose to act as a body or 411 delegate duties to the Lead Ombudsperson. 413 5. Remedies 415 After examining the circumstances regarding the complaint of 416 harassment the Ombudsteam should prepare a brief summary of the 417 incident and their conclusions and discuss this with all parties. 418 The objective of this step is to make clear what the Ombudsteam has 419 concluded, and to make an attempt at getting all parties to reach 420 agreement. 422 If the Ombudsteam determines that harassment has taken place, the 423 Ombudsteam is expected to determine the next action. 425 o In some cases a mechanism or established IETF process may already 426 exist for handling the specific event. In these cases the 427 Ombudsteam may decide that the misbehavior is best handled with 428 the regular IETF procedures for dealing with disruptive behavior 429 and may assist the Reporter to bring the issue to the attention of 430 the working group chair or IESG member who can deal with the 431 incident. 433 o In other cases there is a spectrum of remedies that may be 434 appropriate to the circumstances. At one end of the spectrum, the 435 Ombudsteam might choose to discuss the situation with the 436 Respondent and come up with a plan such that there is no repeat of 437 the harassment. With the agreement of both parties, the 438 Ombudsteam can also help to mediate a conversation between the 439 Respondent and the Subject (or the Reporter if there is no 440 individual Subject) in order to address the issue. If mediation 441 fails then the Ombudsteam can decide to apply other remedies, 442 including those discussed here. 444 o At the other end of the spectrum the Ombudsteam could decide that 445 the Respondent is no longer permitted to participate in a 446 particular IETF activity, for example, ejecting them from a 447 meeting or requiring that the Respondent can no longer attend 448 future meetings to ensure that the reported harassment can not 449 continue or escalate. If the Respondent holds a management 450 position in the IETF, the remedies imposed may make it difficult 451 or impossible for them to perform the duties required of that 452 position. Further remedies may be applied to Respondents in IETF 453 management positions as described in Section 5.1. 455 o In determining the appropriate remedy, the Ombudsteam may 456 communicate with the Reporter, Subject, or Respondent in order to 457 assess the impact that the imposition of a remedy might have on 458 any of those parties. However, the Ombudsteam has ultimate 459 responsibility for the choice of remedy. 461 o In all cases, the Lead Ombudsperson informs the Respondent of the 462 decision and imposes the remedy as appropriate. In cases where 463 the remedy is removal from IETF activities, the Lead Ombudsperson 464 will confidentially notify the Secretariat in writing of the 465 remedy such that the Secretariat can take whatever logistical 466 actions are required to effect the remedy. Only the remedy itself 467 shall be disclosed to the Secretariat, not any information 468 regarding the nature of the harassment. 470 Where specific action is required to ensure that a remedy is realized 471 or enforced, the Ombudsteam will make a request in writing to the 472 IETF Secretariat and/or IETF Administrative Director (IAD) to take 473 action as appropriate. 475 5.1. Remedies for Respondents in IETF Positions 477 The remedies discussed earlier in this section are equally applicable 478 to all IETF participants regardless of role. 480 The Ombudsteam will want to be aware of the impact of remedies on the 481 ability of an individual to carry out their duties in IETF management 482 positions, but this should not dissuade the Ombudsteam from applying 483 remedies that they deem appropriate. Per Section 5, the Ombudsteam 484 is expected to apply proportionality and reasonableness, as well as 485 to consider the impact of the remedy on the Respondent. Per 486 Section 4.1, the Ombudsteam may communicate with the Respondent in 487 order to assess the impact that the remedy might have. 489 There may be cases where the Ombudsteam considers that it is 490 inappropriate for a Respondent to continue in their IETF management 491 position, that is where the desired remedy is to remove the 492 Respondent from their management position. The Ombudsteam cannot by 493 itself remove a Respondent who is in an IETF management position from 494 that position. However, the Ombudsteam can recommend the use the 495 existing mechanisms within the IETF process for the removal of people 496 from IETF management positions as follows: 498 o Many IETF management positions are appointed by the Nominating 499 Committee with confirmation from the IESG, IAB, or ISOC. 500 [RFC7437] describes the recall procedure for such appointments. 501 This document updates [RFC7437] by allowing the Ombudsteam to form 502 a recall petition on its own and without requiring 20 signatories 503 from the community. Such a petition shall be treated in all ways 504 like any other recall petition as described in [RFC7437]: that is, 505 the fact of the petition and its signatories (the Ombudsteam) 506 shall be announced to the IETF community, and a Recall Committee 507 Chair shall be appointed to complete the Recall Committee process. 508 It is expected that the Recall Committee will receive a briefing 509 from the Ombudsteam explaining why recall is considered an 510 appropriate remedy. 512 o Other IETF management positions are filled by appointment of the 513 IESG, the IAB, the ISOC Board, or the ISOC President. In such 514 cases the Ombudsteam may recommend to the appointing body that the 515 Respondent be removed from their position. 517 o Many IETF management positions are filled through appointment by 518 an AD or by the ADs for an IETF Area. In such cases the 519 Ombudsteam may recommend to those ADs in writing that the 520 Respondent be removed from their position. 522 o Some other IETF management positions are filled through 523 appointment by WG chairs. In such cases the Ombudsteam may make a 524 recommendation in writing to the responsible AD (that is, not 525 directly to the WG chairs) that the Respondent be removed from 526 their position. 528 In each of the cases listed here, the person or body responsible for 529 removing someone from an IETF management position is expected to take 530 a recommendation from the Ombudsteam extremely seriously and that it 531 would be very unusual for them to not act on the recommendation. It 532 is not the intent that the person or body attempt to reinvestigate 533 the circumstances of the harassment. They are expected to understand 534 that they are not qualified in evaluating or handling issues of 535 harassment. They must seek to preserve confidentiality. If the 536 person or body feels removal from position is not the correct remedy 537 they must discuss their concern with the Ombudsteam. 539 In the event that an AD declines to follow the recommendation of the 540 Ombudsteam, and if the AD fails to convince the Ombudsteam of the 541 reasons for this, the Ombudsteam should raise the issue with the 542 whole IESG while continuing to attempt to retain confidentiality. 543 The IESG may choose to reorganize the responsibilities for working 544 groups within its own structure so that the AD concerned is no longer 545 in the direct management path. 547 All such forced removals from management positions must be considered 548 by the Ombudsteam as acts of last resort. That is, before a 549 Respondent is recommended for removal, the Ombudsteam should consider 550 other possible remedies and should discuss the situation with the 551 Respondent giving them ample opportunity to understand what might 552 happen and to step down of their own volition. 554 As described in Section 4.1, the Ombudsteam is required to maintain 555 the highest degree of confidentiality. In recommending action as 556 described above, the Ombudsteam will clearly have to indicate that 557 some event has occurred that led to their recommendation, but it is 558 not expected that the Ombudsteam will need to divulge substantially 559 more information. It should be enough that the Ombudsteam explains 560 the severity of the situation, that they have considered other lesser 561 remedies, and that they deem the recommended remedy to be 562 appropriate. 564 In removing someone from their position it may become apparent to the 565 IETF community that the removal is a remedy recommended by the 566 Ombudsteam. However, revealing the underlying events should be 567 avoided as far as possible. 569 5.2. Purpose of Remedies 571 The purpose of the anti-harassment policy is to prevent all incidents 572 of harassment in the IETF. The set of procedures documented here 573 serves to provide a mechanism whereby any harassment that occurs can 574 be reported and handled both sympathetically and effectively. The 575 policy also sends a clear message that the IETF does not tolerate 576 harassment in any form. 578 However any remedy is imposed to try to make sure that the incident 579 does not escalate and to ensure that a similar situation is unlikely 580 to occur with the same Respondent in the future. 582 Because the handling of incidents of harassment (including the 583 imposition of remedies) is confidential, an imposed remedy cannot 584 itself serve as a deterrent to others, nor can it be used to "teach" 585 the community how to behave. ([RFC7154] gives guidelines for conduct 586 in the IETF.) Furthermore, a remedy is not to be imposed for the 587 purposes of retribution. However, the knowledge of the existence of 588 a range of remedies and of processes by which they can be applied 589 serves both as a statement of the IETF's seriousness in this matter, 590 and as a deterrent to potential offenders. 592 The Ombudsteam is expected to apply the above considerations, as well 593 as proportionality and reasonableness, in selecting a remedy. They 594 are asked to consider the impact of the remedy on the Respondent as 595 well as on the Subject. 597 6. Disputes with the Ombudsteam 599 If either the Subject (or the Reporter if there is no individual 600 Subject) or the Respondent is dissatisfied with the decision of the 601 Ombudsteam, the dissatisfied party should first contact the Lead 602 Ombudsperson and discuss the situation. If the issue cannot be 603 resolved through discussion with the Lead Ombudsperson, the issue may 604 be raised with the IETF Chair. 606 If necessary, the IETF Chair may recuse themself from any part of 607 this process (see Section 7) and request the IESG to select another 608 of its members to serve in this role. This IESG member is known as 609 the "delegated IESG member". 611 The IETF Chair (or the delegated IESG member if the Chair is recused) 612 will attempt to resolve the issue in discussion with the dissatisfied 613 party and the Lead Ombudsperson. If this further discussion does not 614 bring a satisfactory resolution, the Ombudsteam's decision may be 615 formally appealed. The appeal is strictly on the issue of whether 616 the Ombudsteam exercised due diligence in both their decision as to 617 whether harassment had taken place, as well as in their determination 618 of any appropriate remedy that was imposed. In particular, the 619 purpose of the appeal is not to re-investigate the circumstances of 620 the incident or to negotiate the severity of the remedy. 622 All elements of the appeal, including the fact of the appeal, will be 623 held in confidence, but will be recorded and held securely for future 624 reference. 626 The appeal will be evaluated by the IETF Chair (or the delegated IESG 627 member) and two other members of the IESG selected by the IETF Chair 628 (or the delegated IESG member) and confirmed by the appellant. This 629 Appeals Group shall convene as quickly as possible to evaluate and 630 determine the appeal. Where the impacts are immediate and related to 631 participation in an ongoing meeting, this shall happen in no more 632 than 24 hours after receiving the appeal. The Appeals Group may ask 633 the appellant and the Lead Ombudsperson for statements or other 634 information to consider. If the Appeals Group concludes that due 635 diligence was exercised by the Ombudsteam, this shall be reported to 636 the appellant and the matter is concluded. If the Appeals Group 637 finds that due diligence was not exercised, the Appeals Group shall 638 report this to the Ombudsteam, and consult with the Ombudsteam on how 639 to complete the due diligence. 641 Because of the need to keep the information regarding these matters 642 as confidential as possible, the Appeals Group's decision is final 643 with respect to the question of whether the Ombudsteam has used due 644 diligence in their decision. The only further recourse available is 645 to claim that the procedures themselves (i.e., the procedures 646 described in this document) are inadequate or insufficient to the 647 protection of the rights of all parties. Such a claim may be made in 648 an appeal to the Internet Society Board of Trustees, as described in 649 Section 6.5.3 of [RFC2026]. Again, even in this circumstance, the 650 particulars of the incident at hand will be held in confidence. 652 7. Conflicts of Interest 654 In the event of any conflict of interest, the conflicted person 655 (member of the Ombudsteam, member of the Appeals Group, IETF Chair, 656 etc.) is expected to recuse themselves. 658 A conflict of interest may arise if someone involved in the process 659 of handling a harassment report is in the role of Reporter, 660 Respondent, or Subject. Furthermore, a conflict of interest arises 661 if the person involved in the process of handling a harassment report 662 is closely associated personally or through affiliation with any of 663 the Reporter, Respondent, or Subject. 665 For the avoidance of doubt, recusal in this context means completely 666 stepping out of any advisory or decision-making part of any process 667 associated with handling a harassment report, remedy arising from a 668 harassment report, or appeal into the handling of a harassment 669 report. That means that a recused person has no more right to 670 participate in or witness the process than any other person from the 671 community in the same situation. For example, therefore, an 672 Ombudsperson subject to a complaint of harassment shall not be privy 673 to the deliberations of another Ombudsperson handling the report. 674 Nor would an IESG member who was party to an appeal be able to 675 witness the discussions of the Appeals Group. 677 In the event that there is an appeal and the IETF Chair is somehow 678 involved, the Chair will immediately recuse themself and the IESG 679 will select a single person to take the Chair's role in the appeal 680 process as described in Section 6. 682 8. Confidentiality 684 Throughout this document there are mentions of requirements to keep 685 information confidential. This section summarises those requirements 686 for clarity. 688 The Ombudsteam is expected to strive for confidentiality. 689 Confidentiality protects the Reporter, Subject, and Respondent in any 690 case of aledged harassment. It also protects witnesses or others 691 consulted by the Ombudsteam during their investigation. 693 The Ombudsteam will keep its email and other archival records in a 694 secure system and will not discuss details of any case beyond what is 695 necessary for executing a thorough investigation. 697 Third party receivers of output from the Ombudsteam (for example, ADs 698 or the IETF Secretariat who are asked to take action) are required to 699 keep such output confidential. 701 Participants in an investigation (Reporters, Subjects, Respondents, 702 and anyone interviewed by the Ombudsteam during an investigation) are 703 requested to keep the details of the events and investigation 704 confidential. 706 It is likely that members of the community will want to know more 707 when they have become aware of some details of a case of harassment. 708 The community is asked to show restraint and to trust the Ombudsteam. 709 This process is designed to provide remedies not punishment as 710 described in Section 5.2 and public discussion of the events or 711 remedies does not form part of this process. 713 9. IANA Considerations 715 This document makes no requests to IANA for action. 717 10. Security Considerations 719 "Human beings the world over need freedom and security that they may 720 be able to realize their full potential." -- Aung San Suu Kyi 722 11. Acknowledgements 724 The text in this document benefited from the lively discussion on the 725 ietf@ietf.org mailing list. Thanks to everyone who participated. 727 Specific changes to this document resulted from comments by 728 Abdussalam Baryun, Alessandro Vesely, S Moonesamy, Timothy B. 729 Terriberry, John Levine, Andrea Glorioso, Dave Crocker, John Leslie, 730 Linda Klieforth, Brian Carpenter, Mary Barnes, Richard Barnes, 731 Spencer Dawkins, Michael StJohns, Alissa Cooper, James Woodyatt, Tom 732 Taylor, Sam Hartman, Stewart Bryant, Stephen Farrell, Nico Williams, 733 Mark Nottingham, and Jari Arkko. The authors would like to express 734 their gratitude. 736 A design team comprising Linda Klieforth, Allison Mankin, Suresh 737 Krishnan, Pete Resnick, and Adrian Farrel was convened by the IETF 738 Chair (Jari Arkko) to address the issue of "Remedies for Respondents 739 in IETF Positions" and the text in Section 5.1. 741 The authors would like to thank Ines Robles for diligent shepherding 742 of this document and for tracking the many issues raised in and after 743 IETF last call. 745 Thanks to Greg Kapfer at ISOC, Ray Pelletier the IAD, Scott Bradner 746 and Lou Berger on the IAOC, and Scott Young and David Wilson of 747 Thompson Hine for considering the legal and insurance implications. 749 12. References 751 12.1. Normative References 753 [RFC2026] Bradner, S., "The Internet Standards Process -- Revision 754 3", BCP 9, RFC 2026, DOI 10.17487/RFC2026, October 1996, 755 . 757 [RFC2418] Bradner, S., "IETF Working Group Guidelines and 758 Procedures", BCP 25, RFC 2418, DOI 10.17487/RFC2418, 759 September 1998, . 761 [RFC3934] Wasserman, M., "Updates to RFC 2418 Regarding the 762 Management of IETF Mailing Lists", BCP 25, RFC 3934, 763 DOI 10.17487/RFC3934, October 2004, 764 . 766 [RFC7154] Moonesamy, S., Ed., "IETF Guidelines for Conduct", BCP 54, 767 RFC 7154, DOI 10.17487/RFC7154, March 2014, 768 . 770 [RFC7437] Kucherawy, M., Ed., "IAB, IESG, and IAOC Selection, 771 Confirmation, and Recall Process: Operation of the 772 Nominating and Recall Committees", BCP 10, RFC 7437, 773 DOI 10.17487/RFC7437, January 2015, 774 . 776 12.2. Informative References 778 [OmbudsteamPages] 779 IESG, "IETF Ombudsteam Web Pages", . 782 [Policy] IESG, "IETF Anti-Harassment Policy", 783 . 786 Authors' Addresses 788 Pete Resnick 789 Qualcomm Technologies, Inc. 790 5775 Morehouse Drive 791 San Diego, CA 92121 792 US 794 Phone: +1 858 651 4478 795 Email: presnick@qti.qualcomm.com 797 Adrian Farrel 798 Juniper Networks 800 Email: adrian@olddog.co.uk