idnits 2.17.1 draft-farrresnickel-harassment-08.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 (August 9, 2015) is 3180 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 August 9, 2015 7 Expires: February 10, 2016 9 IETF Anti-Harassment Procedures 10 draft-farrresnickel-harassment-08 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 February 10, 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 . . . . . . . 10 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 . . . . . . . . . . . . . . . . . . 17 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 for the legal system under the jurisdiction of which 108 any harassment takes place. Similarly, it does not release any 109 person from any contractual or corporate policies to which they may 110 be subject. 112 2. Definitions 114 The following terms are used in this document: 116 IETF Participant: Anyone who participates in an IETF activity, 117 including IETF support staff. 119 Reporter: An IETF Participant who reports potential harassment to 120 an Ombudsperson. 122 Respondent: An IETF Participant who is claimed to have engaged in 123 harassing behavior. 125 Ombudsteam: A group of people who have been selected to take 126 reports of potential harassment, evaluate them, and impose 127 appropriate actions and/or remedies to address the circumstances. 129 Ombudsperson: A member of the Ombudsteam. 131 Lead Ombudsperson: The Ombudsperson assigned to be the primary 132 contact person for a particular report of potential harassment. 134 Subject: An individual, group, or class of IETF Participant to 135 whom the potentially harassing behavior was directed or who might 136 be subject to the behavior. 138 The IESG statement on harassment [Policy] gives a general definition 139 of harassment as "unwelcome hostile or intimidating behavior -- in 140 particular speech and behavior that is sexually aggressive or 141 intimidates based on attributes like race, gender, religion, age, 142 color, national origin, ancestry, disability, sexual orientation, or 143 gender identity." This document adopts that general definition, but 144 does not attempt to further precisely define behavior that falls 145 under the set of procedures identified here, nor does it attempt to 146 list every possible attribute that might be the basis for harassment, 147 except to note that it may be targeted at an individual, directed at 148 a specific group of people, or more generally impact a broader class 149 of people. 151 This document concerns itself with harassment that has the purpose or 152 effect of unreasonably interfering with an individual's participation 153 in IETF activities or of creating an environment within the IETF that 154 would be intimidating, hostile, or offensive in such a situation. 155 One way in which harassment can occur is when submission to such 156 conduct is made either explicitly or implicitly a term or condition 157 of an individual's participation in IETF activities or is used as a 158 basis for decisions affecting that individual's relationship to the 159 IETF. 161 In general, disruptive behavior that occurs in the context of an IETF 162 general or working group mailing list, or happens in a face-to-face 163 or virtual meeting of a working group or the IETF plenary, can be 164 dealt with by our normal procedures, whereas harassing behavior is 165 more appropriately handled by the procedures described here. 166 However, there are plausible reasons to address behaviors that take 167 place during working-group meetings using these procedures. This 168 document gives some guidance to those involved in these situations in 169 order to decide how to handle particular incidents, but the final 170 decision will involve judgment and the guidance of the Ombudsteam. 172 Any definition of harassment prohibited by an applicable law can be 173 subject to this set of procedures. 175 3. The Ombudsteam 177 This section describes the role of the Ombudsteam in terms of the 178 appointment of Ombudspersons, their qualifications and training, the 179 length of the term of service, any compensation from the IETF for 180 their service, and how they may be removed from service. The general 181 operational procedures for the Ombudsteam are described in Section 4, 182 Section 5, and Section 6. 184 3.1. Size of the Ombudsteam 186 The Ombudsteam shall comprise no fewer than three people. From time 187 to time, the size may fall below that number owing to changes in 188 membership, but the team will be rapidly brought up to size through 189 new appointments. The team may be grown to a larger size as 190 described in Section 3.2 192 3.2. Appointing the Ombudsteam 194 The Ombudsteam is appointed by the IETF Chair. The appointment is 195 solely the responsibility of the IETF Chair who may choose to consult 196 with members of the IETF community. 198 The IETF Chair is encouraged to appoint at least some of the 199 Ombudsteam from within the IETF community. 201 The IETF Chair may choose to solicit nominations or advertise the 202 post. This is entirely at the discretion of the IETF Chair. 204 The IETF Chair is also free to decide to appoint more than three 205 Ombudspersons to the Ombudsteam. This may depend on the skillsets 206 available, the work load, and the opinions of the seated Ombudsteam. 207 Furthermore, the IETF Chair may consider elements of diversity in 208 making this decision. 210 3.3. Professional Advisors 212 It is recognized that the Ombudsteam may need to call on professional 213 services from external advisors for certain matters including legal 214 and Human Resources (HR) advice. The IETF (via the IASA) is 215 committed to funding such advice as needed. 217 3.4. Qualifications and Training 219 It is not expected that there will be candidates with all of the 220 necessary ombudsperson skills and training who also have a clear 221 understanding and familiarity with the IETF processes and culture. 222 The Chair might choose someone with a great deal of professional 223 experience evaluating and mediating harassment disputes, but little 224 exposure to the IETF, or could select someone with more exposure to 225 the IETF community, but without as much experience dealing with 226 issues of harassment. Since all of these attributes may be regarded 227 by the IETF Chair as essential for the team, the IETF is committed to 228 providing training (or funding for it) as deemed necessary for 229 appointed Ombudspersons. In determining the appropriate training, 230 the IETF chair and Ombudsteam shall take professional advice and will 231 consult with the IAOC with respect to the overall IETF budget. 233 3.5. Term of Service 235 An Ombudsperson shall be appointed for a two year term. That is, the 236 Ombudsperson is making a commitment to serve for two years. It is 237 understood, however, that circumstances may lead an Ombudsperson to 238 resign for personal or other reasons. See also Section 3.7. 240 If an Ombudsperson's term ends while they are acting as Lead 241 Ombudsperson for a report as described in Section 4, that 242 Ombudsperson's term shall be extended until the handling of that 243 report has been completed. 245 It is entirely at the discretion of the IETF Chair whether a serving 246 Ombudsperson is reappointed at the end of their term. Given the 247 sensitivity of, and training required for, this role and the ideal 248 being a lack of activity, it is likely the IETF chair may choose to 249 re-appoint a successful and still-willing Ombudsperson for a number 250 of two year terms. 252 3.6. Compensation 254 An Ombudsperson shall receive no compensation from the IETF for their 255 services. This includes, but is not limited to: 257 o IETF meeting fees 259 o Remuneration for time spent 261 o Out-of-pocket expenses (such as telephone charges) 263 o Travel or accommodation expenses 265 The IETF will, however, meet the costs of training when agreed to by 266 the IETF Chair as described in Section 3.4. 268 3.7. Removal 270 The IETF Chair may remove a serving Ombudsperson before the end of 271 their term without explanation to the community including during the 272 course of processing an active case. Such an action shall be 273 appealable as described in Section 3.8. 275 An Ombudsperson shall not be removed from service, even if their term 276 has expired, during the period that the IETF Chair is recused as 277 described in Section 7. Once the case that led to the Chair being 278 recused has been closed, normal processes resume. 280 3.8. Disputes with the IETF Chair regarding the Ombudsteam 282 If an individual should disagree with an action taken by the IETF 283 Chair regarding the appointment, removal, or management of an 284 Ombudsperson or the Ombudsteam, that person should first discuss the 285 issue with the IETF Chair directly. If the IETF Chair is unable to 286 resolve the issue, the dissatisfied party may appeal to the IESG as a 287 whole. The IESG shall then review the situation and attempt to 288 resolve it in a manner of its own choosing. The procedures of 289 Section 6.5.4 of [RFC2026] apply to this sort of appeal. 291 4. Handling Reports of Harassment 293 Any IETF Participant who believes that they have been harassed, or 294 that any other IETF Participant or group of IETF Participants has 295 been or may have been harassed, should bring the concern to the 296 attention of any serving Ombudsperson. This can be done by email to 297 ombuds@ietf.org, or can be done directly to a chosen Ombudsperson. 298 Direct contact information for the Ombudsteam, including the email 299 addresses to which "ombuds@ietf.org" is forwarded, can be found at 300 https://www.ietf.org/ombudsteam [OmbudsteamPages]. 302 All IETF Participants are encouraged to talk with the Ombudsteam if 303 they are uncomfortable or unsure about any behaviors. 305 When a Reporter brings an incident of potential harassment to the 306 attention of the Ombudsteam, a single Ombudsperson shall be 307 designated as the primary contact person (the Lead Ombudsperson) for 308 the report. When the Reporter contacts a single Ombudsperson, that 309 Ombudsperson shall be the Lead Ombudsperson for the report unless 310 mutually agreed between the Reporter and that Ombudsperson. 312 The Lead Ombudsperson may share any information regarding the report 313 with the rest of the Ombudsteam except when an Ombudsperson is 314 recused (see Section 7). If a Reporter believes that a member of the 315 Ombudsteam should recuse themself, they should make this known to the 316 Lead Ombudsperson as soon as possible. 318 The Lead Ombudsperson will discuss the events with the Reporter and 319 may give advice including recommendations on how the Reporter can 320 handle the issue on their own as well as strategies on how to prevent 321 the issue from arising again. The Lead Ombudsperson may also 322 indicate that the issue would be best handled using regular IETF 323 procedures (such as those for dealing with disruptive behavior) 324 outside the context of harassment, and in this case the Lead 325 Ombudsperson will provide assistance in using the relevant IETF 326 procedures. Otherwise, with agreement to proceed from the Subject 327 (or the Reporter if there is no individual Subject), the Ombudsteam 328 may initiate detailed investigation of the matter, and may 329 subsequently, after completing their investigation, impose a remedy 330 as described in Section 5. 332 4.1. Ombudsteam Operating Practices 334 The Ombudsteam is responsible for devising and documenting their 335 operating practices. These practices must be discussed with the IESG 336 and published in a publicly visible place (such as on the IETF web 337 site). Discussion with the IETF community is encouraged and, while 338 IETF consensus is not necessary, significant objections to the 339 processes that are not addressed should result in an appeal per 340 Section 6.5.3 of [RFC2026] and/or a recall petition against the IETF 341 Chair (and any of the rest of the IESG if appropriate) if they do not 342 address the concern. 344 The practices must include at least the following high-level 345 components: 347 o Each member of the Ombudsteam is expected to be present at the 348 majority of IETF meetings and to be available for face-to-face 349 discussions. The Ombudsteam is expected to arrange itself so that 350 there is coverage of every IETF meeting by at least one 351 Ombudsperson. 353 o The Ombudsteam shall strive to keep all information brought to it 354 in strict confidence. However, it is acknowledged that the 355 operation of the Ombudsteam will necessarily involve sharing of 356 information within the team, and may require that the parties to 357 the complaint (the Reporter, Respondent, and Subject) learn some 358 of the confidential information. The Ombudsteam is responsible 359 for documenting its expectations of when disclosures of 360 confidential information are likely to be made in the process and 361 to whom. Any electronic information (such as email messages) that 362 needs to be archived shall be encrypted before it is stored using 363 tools similar to those used by NomCom. 365 o When conducting a detailed investigation of the circumstances 366 regarding the complaint of harassment, the Ombudsteam may contact 367 the Respondent and request a meeting in person or by a voice call. 368 The Ombudsteam shall have contacted the Respondent and either 369 discussed the matter, or ascertained the Respondent's 370 unwillingness to cooperate, prior to deciding to impose a remedy 371 as described in Section 5. The Respondent is not obliged to 372 cooperate, but the Ombudsteam may consider failure to cooperate 373 when determining a remedy (Section 5). 375 o The Ombudsteam shall endeavor to complete its investigation in a 376 timely manner. 378 o Any individuals who make a good faith report of harassment or who 379 cooperate with an investigation shall not be subject to 380 retaliation for reporting, complaining, or cooperating, even if 381 the investigation, once completed, shows no harassment occurred. 382 Anti-retaliation is noted here to alleviate concerns individuals 383 may have with reference to reporting an incident they feel should 384 be reviewed or cooperating with an investigation. 386 o In all cases the Ombudsteam will strive to maintain 387 confidentiality for all parties including the very fact of contact 388 with the Ombudsteam. 390 o All reports (such as to Subject or Respondent) and all requests 391 for remedial action (such as to the IETF Secretariat) shall be in 392 writing. 394 o The Ombudsteam shall keep written records of their investigation 395 and any contacts or interviews such that there is material 396 available in the event of an appeal or legal action. Such records 397 shall be held securely and in confidence. 399 When investigating reports of harassment and determining remedies, it 400 is up to the Ombudsteam whether they choose to act as a body or 401 delegate duties to the Lead Ombudsperson. 403 5. Remedies 405 After examining the circumstances regarding the complaint of 406 harassment the Ombudsteam should prepare a brief summary of the 407 incident and their conclusions and discuss this with all parties. 408 The objective of this step is to make clear what the Ombudsteam has 409 concluded, and to make an attempt at getting all parties to reach 410 agreement. 412 If the Ombudsteam determines that harassment has taken place, the 413 Ombudsteam is expected to determine the next action. 415 o In some cases a mechanism or established IETF process may already 416 exist for handling the specific event. In these cases the 417 Ombudsteam may decide that the misbehavior is best handled with 418 the regular IETF procedures for dealing with disruptive behavior 419 and may assist the Reporter to bring the issue to the attention of 420 the working group chair or IESG member who can deal with the 421 incident. 423 o In other cases there is a spectrum of remedies that may be 424 appropriate to the circumstances. At one end of the spectrum, the 425 Ombudsteam might choose to discuss the situation with the 426 Respondent and come up with a plan such that there is no repeat of 427 the harassment. With the agreement of both parties, the 428 Ombudsteam can also help to mediate a conversation between the 429 Respondent and the Subject (or the Reporter if there is no 430 individual Subject) in order to address the issue. If mediation 431 fails then the Ombudsteam can decide to apply other remedies, 432 including those discussed here. 434 o At the other end of the spectrum the Ombudsteam could decide that 435 the Respondent is no longer permitted to participate in a 436 particular IETF activity, for example, ejecting them from a 437 meeting or requiring that the Respondent can no longer attend 438 future meetings. If the Respondent holds a management position in 439 the IETF, the remedies imposed may make it difficult or impossible 440 for them to perform the duties required of that position. Further 441 remedies may be applied to Respondents in IETF management 442 positions as described in Section 5.1. 444 o In determining the appropriate remedy, the Ombudsteam may 445 communicate with the Reporter, Subject, or Respondent in order to 446 assess the impact that the imposition of a remedy might have on 447 any of those parties. However, the Ombudsteam has ultimate 448 responsibility for the choice of remedy. 450 o In all cases, the Lead Ombudsperson informs the Respondent of the 451 decision and imposes the remedy as appropriate. In cases where 452 the remedy is removal from IETF activities, the Lead Ombudsperson 453 will confidentially notify the Secretariat in writing of the 454 remedy such that the Secretariat can take whatever logistical 455 actions are required to effect the remedy. Only the remedy itself 456 shall be disclosed to the Secretariat, not any information 457 regarding the nature of the harassment. 459 Where specific action is required to ensure that a remedy is realized 460 or enforced, the Ombudsteam will make a request in writing to the 461 IETF Secretariat and/or IETF Administrative Director (IAD) to take 462 action as appropriate. 464 5.1. Remedies for Respondents in IETF Positions 466 The remedies discussed earlier in this section are equally applicable 467 to all IETF participants regardless of role. 469 The Ombudsteam will want to be aware of the impact of remedies on the 470 ability of an individual to carry out their duties in IETF management 471 positions, but this should not dissuade the Ombudsteam from applying 472 remedies that they deem appropriate. Per Section 5.1, the Ombudsteam 473 is expected to apply proportionality and reasonableness, as well as 474 to consider the impact of the remedy on the Respondent. Per 475 Section 5, the Ombudsteam may communicate with the Respondent in 476 order to assess the impact that the remedy might have. 478 There may be cases where the Ombudsteam considers that it is 479 inappropriate for a Respondent to continue in their IETF management 480 position, that is where the desired remedy is to remove the 481 Respondent from their management position. The Ombudsteam cannot by 482 itself remove a Respondent who is in an IETF management position from 483 that position. However, the Ombudsteam can recommend the use the 484 existing mechanisms within the IETF process for the removal of people 485 from IETF management positions as follows: 487 o Many IETF management positions are appointed by the Nominating 488 Committee with confirmation from the IESG, IAB, or ISOC. 489 [RFC7437] describes the recall procedure for such appointments. 490 This document updates [RFC7437] by allowing the Ombudsteam to form 491 a recall petition on its own and without requiring 20 signatories 492 from the community. Such a petition shall be treated in all ways 493 like any other recall petition as described in [RFC7437]: that is, 494 the fact of the petition and its signatories (the Ombudsteam) 495 shall be announced to the IETF community, and a Recall Committee 496 Chair shall be appointed to complete the Recall Committee process. 497 It is expected that the Recall Committee will receive a briefing 498 from the Ombudsteam explaining why recall is considered an 499 appropriate remedy, but the Recall Committee is expected to 500 understand that their investigation as described in [RFC7437] is 501 not to re-evaluate the events of the harassment, and that they are 502 not qualified in handling issues of harassment. The Recall 503 Committee is subject to the same confidentiality requirements as 504 the Nominating Committee. 506 o Other IETF management positions are filled by appointment of the 507 IESG, the IAB, the ISOC Board, or the ISOC President. In such 508 cases the Ombudsteam may recommend to the appointing body that the 509 Respondent be removed from their position. It is expected that 510 the appointing body will take such a recommendation extremely 511 seriously and that it would be very unusual for the appointing 512 body to not act on the recommendation. It is not the intent that 513 the appointing body re-evaluate the events, and the appointing 514 body is expected to understand that they are not qualified in 515 handling issues of harassment. The appointing body is strongly 516 encouraged to discuss with the Ombudsteam in the event that they 517 feel removal from position is not the correct remedy. 519 o Many IETF management positions are filled through appointment by 520 an AD or by the ADs for an IETF Area. In such cases the 521 Ombudsteam may recommend to the AD in writing that the Respondent 522 be removed from their position. It is expected that the AD will 523 take such a recommendation extremely seriously and that it would 524 be very unusual for the AD to not act on the recommendation. It 525 is not the intent that the AD re-evaluate the events, and the AD 526 is expected to understand that they are not qualified in handling 527 issues of harassment and they must preserve confidentiality. The 528 AD is strongly encouraged to discuss with the Ombudsteam in the 529 event that the AD feels removal from position is not the correct 530 remedy. 532 o Some other IETF management positions are filled through 533 appointment by WG chairs. In such cases the Ombudsteam may make a 534 recommendation in writing to the responsible AD, and not direct to 535 the WG chairs, that the Respondent be removed from their position. 536 It is expected that the AD will take such a recommendation 537 extremely seriously and that it would be very unusual for the AD 538 to not act on the recommendation by working with the WG chairs to 539 remove the Respondent from their position. It is not the intent 540 that the AD or WG chairs re-evaluate the events, and the AD and WG 541 chairs are expected to understand that they are not qualified in 542 handling issues of harassment and that they must preserve 543 confidentiality. The AD is strongly encouraged to discuss with 544 the Ombudsteam in the event that they or the WG chairs feel 545 removal from position is not the correct remedy. 547 o In the event that an AD declines to act on the recommendation of 548 the Ombudsteam and fails to convince the Ombudsteam, the 549 Ombudsteam should raise the issue with the whole IESG while 550 continuing to attempt to retain confidentiality. The IESG may 551 choose to reorganize the responsibilities for working groups 552 within its own structure so that the conflicted AD is no longer in 553 the direct management path. 555 All such forced removals from management positions should be 556 considered by the Ombudsteam as acts of last resort. That is, before 557 a Respondent is recommended for removal, the Ombudsteam should 558 discuss the situation with the Respondent giving them ample 559 opportunity to understand what might happen and to step down of their 560 own volition. 562 As described in Section 4.1, the Ombudsteam is required to maintain 563 the highest degree of confidentiality. In recommending action as 564 described above, the Ombudsteam will clearly have to indicate that 565 some event has occurred that led to their recommendation, but it is 566 not expected that the Ombudsteam will need to divulge substantially 567 more information. It should be enough that the Ombudsteam explains 568 the severity of the situation, that they have considered other lesser 569 remedies, and that they deem the recommended remedy to be 570 appropriate. 572 In removing someone from their position it may become apparent to the 573 IETF community that the removal is a remedy recommended by the 574 Ombudsteam. However, revealing the underlying events should be 575 avoided as far as possible. 577 5.2. Purpose of Remedies 579 The purpose of the anti-harassment policy is to prevent all incidents 580 of harassment in the IETF. The set of procedures documented here 581 serves to provide a mechanism whereby any harassment that occurs can 582 be reported and handled both sympathetically and effectively. The 583 policy also sends a clear message that the IETF does not tolerate 584 harassment in any form. 586 However any remedy is imposed to try to make sure that the incident 587 does not escalate and to ensure that a similar situation is unlikely 588 to occur with the same Respondent in the future. 590 Because the handling of incidents of harassment (including the 591 imposition of remedies) is confidential, an imposed remedy cannot 592 itself serve as a deterrent to others, nor can it be used to "teach" 593 the community how to behave. ([RFC7154] gives guidelines for conduct 594 in the IETF.) Furthermore, a remedy is not to be imposed for the 595 purposes of retribution. However, the knowledge of the existence of 596 a range of remedies and of processes by which they can be applied 597 serves both as a statement of the IETF's seriousness in this matter, 598 and as a deterrent to potential offenders. 600 The Ombudsteam is expected to apply the above considerations, as well 601 as proportionality and reasonableness, in selecting a remedy. They 602 are asked to consider the impact of the remedy on the Respondent as 603 well as on the Subject. 605 6. Disputes with the Ombudsteam 607 If either the Subject (or the Reporter if there is no individual 608 Subject) or the Respondent is dissatisfied with the decision of the 609 Ombudsteam, the dissatisfied party should first contact the Lead 610 Ombudsperson and discuss the situation. If the issue cannot be 611 resolved through discussion with the Lead Ombudsperson, the issue may 612 be raised with the IETF Chair. 614 If necessary, the IETF Chair may recuse themself from any part of 615 this process (see Section 7) and request the IESG to select another 616 of its members to serve in this role. This IESG member is known as 617 the "delegated IESG member". 619 The IETF Chair (or the delegated IESG member if the Chair is recused) 620 will attempt to resolve the issue in discussion with the dissatisfied 621 party and the Lead Ombudsperson. If this further discussion does not 622 bring a satisfactory resolution, the Ombudsteam's decision may be 623 formally appealed. The appeal is strictly on the issue of whether 624 the Ombudsteam exercised due diligence in both their decision as to 625 whether harassment had taken place, as well as in their determination 626 of any appropriate remedy that was imposed. In particular, the 627 purpose of the appeal is not to re-investigate the circumstances of 628 the incident or to negotiate the severity of the remedy. 630 All elements of the appeal, including the fact of the appeal, will be 631 held in confidence, but will be recorded and held securely for future 632 reference. 634 The appeal will be evaluated by the IETF Chair (or the delegated IESG 635 member) and two other members of the IESG selected by the IETF Chair 636 (or the delegated IESG member) and confirmed by the appellant. This 637 Appeals Group shall convene as quickly as possible to evaluate and 638 determine the appeal. Where the impacts are immediate and related to 639 participation in an ongoing meeting, this shall happen in no more 640 than 24 hours after receiving the appeal. The Appeals Group may ask 641 the appellant and the Lead Ombudsperson for statements or other 642 information to consider. If the Appeals Group concludes that due 643 diligence was exercised by the Ombudsteam, this shall be reported to 644 the appellant and the matter is concluded. If the Appeals Group 645 finds that due diligence was not exercised, the Appeals Group shall 646 report this to the Ombudsteam, and consult with the Ombudsteam on how 647 to complete the due diligence. 649 Because of the need to keep the information regarding these matters 650 as confidential as possible, the Appeals Group's decision is final 651 with respect to the question of whether the Ombudsteam has used due 652 diligence in their decision. The only further recourse available is 653 to claim that the procedures themselves (i.e., the procedures 654 described in this document) are inadequate or insufficient to the 655 protection of the rights of all parties. Such a claim may be made in 656 an appeal to the Internet Society Board of Trustees, as described in 657 Section 6.5.3 of [RFC2026]. Again, even in this circumstance, the 658 particulars of the incident at hand will be held in confidence. 660 7. Conflicts of Interest 662 In the event of any conflict of interest, the conflicted person 663 (member of the Ombudsteam, member of the Appeals Group, IETF Chair, 664 etc.) is expected to recuse themselves. 666 A conflict of interest may arise if someone involved in the process 667 of handling a harassment report is in the role of Reporter, 668 Respondent, or Subject. Furthermore, a conflict of interest arises 669 if the person involved in the process of handling a harassment report 670 is closely associated personally or through affiliation with any of 671 the Reporter, Respondent, or Subject. 673 For the avoidance of doubt, recusal in this context means completely 674 stepping out of any advisory or decision-making part of any process 675 associated with handling a harassment report, remedy arising from a 676 harassment report, or appeal into the handling of a harassment 677 report. That means that a recused person has no more right to 678 participate in or witness the process than any other person from the 679 community in the same situation. For example, therefore, an 680 Ombudsperson subject to a complaint of harassment shall not be privy 681 to the deliberations of another Ombudsperson handling the report. 682 Nor would an IESG member who was party to an appeal be able to 683 witness the discussions of the Appeals Group. 685 In the event that there is an appeal and the IETF Chair is somehow 686 involved, the Chair will immediately recuse themself and the IESG 687 will select a single person to take the Chair's role in the appeal 688 process as described in Section 6. 690 8. Confidentiality 692 Throughout this document there are mentions of requirements to keep 693 information confidential. This section summarises those requirements 694 for clarity. 696 The Ombudsteam is expected to strive for confidentiality. 697 Confidentiality protects the Reporter, Subject, and Respondent in any 698 case of aledged harassment. It also protects witnesses or others 699 consulted by the Ombudsteam during their investigation. 701 The Ombudsteam will keep its email and other archival records in a 702 secure system and will not discuss details of any case beyond what is 703 necessary for executing a thorough investigation. 705 Third party receivers of output from the Ombudsteam (for example, ADs 706 or the IETF Secretariat who are asked to take action) are required to 707 keep such output confidential. 709 Participants in an investigation (Reporters, Subjects, Respondents, 710 and anyone interviewed by the Ombudsteam during an investigation) are 711 requested to keep the details of the events and investigation 712 confidential. 714 It is likely that members of the community will want to know more 715 when they have become aware of some details of a case of harassment. 716 The community is asked to show restraint and to trust the Ombudsteam. 717 This process is designed to provide remedies not punishment as 718 described in Section 5.2 and public discussion of the events or 719 remedies does not form part of this process. 721 9. IANA Considerations 723 This document makes no requests to IANA for action. 725 10. Security Considerations 727 "Human beings the world over need freedom and security that they may 728 be able to realize their full potential." -- Aung San Suu Kyi 730 11. Acknowledgements 732 The text in this document benefited from the lively discussion on the 733 ietf@ietf.org mailing list. Thanks to everyone who participated. 735 Specific changes to this document resulted from comments by 736 Abdussalam Baryun, Alessandro Vesely, S Moonesamy, Timothy B. 737 Terriberry, John Levine, Andrea Glorioso, Dave Crocker, John Leslie, 738 Linda Klieforth, Brian Carpenter, Mary Barnes, Richard Barnes, 739 Spencer Dawkins, Michael StJohns, Alissa Cooper, James Woodyatt, Tom 740 Taylor, Sam Hartman, Stewart Bryant, Stephen Farrell, and Nico 741 Williams. The authors would like to express their gratitude. 743 A design team comprising Linda Klieforth, Allison Mankin, Suresh 744 Krishnan, Pete Resnick, and Adrian Farrel was convened by the IETF 745 Chair (Jari Arkko) to address the issue of "Remedies for Respondents 746 in IETF Positions" and the text in Section 5.1. 748 The authors would like to thank Ines Robles for diligent shepherding 749 of this document and for tracking the many issues raised in and after 750 IETF last call. 752 Thanks to Greg Kapfer at ISOC, Ray Pelletier the IAD, Scott Bradner 753 and Lou Berger on the IAOC, and Scott Young and David Wilson of 754 Thompson Hine for considering the legal and insurance implications. 756 12. References 757 12.1. Normative References 759 [RFC2026] Bradner, S., "The Internet Standards Process -- Revision 760 3", BCP 9, RFC 2026, DOI 10.17487/RFC2026, October 1996, 761 . 763 [RFC2418] Bradner, S., "IETF Working Group Guidelines and 764 Procedures", BCP 25, RFC 2418, DOI 10.17487/RFC2418, 765 September 1998, . 767 [RFC3934] Wasserman, M., "Updates to RFC 2418 Regarding the 768 Management of IETF Mailing Lists", BCP 25, RFC 3934, 769 DOI 10.17487/RFC3934, October 2004, 770 . 772 [RFC7154] Moonesamy, S., Ed., "IETF Guidelines for Conduct", BCP 54, 773 RFC 7154, DOI 10.17487/RFC7154, March 2014, 774 . 776 [RFC7437] Kucherawy, M., Ed., "IAB, IESG, and IAOC Selection, 777 Confirmation, and Recall Process: Operation of the 778 Nominating and Recall Committees", BCP 10, RFC 7437, 779 DOI 10.17487/RFC7437, January 2015, 780 . 782 12.2. Informative References 784 [OmbudsteamPages] 785 IESG, "IETF Ombudsteam Web Pages", . 788 [Policy] IESG, "IETF Anti-Harassment Policy", 789 . 792 Authors' Addresses 794 Pete Resnick 795 Qualcomm Technologies, Inc. 796 5775 Morehouse Drive 797 San Diego, CA 92121 798 US 800 Phone: +1 858 651 4478 801 Email: presnick@qti.qualcomm.com 802 Adrian Farrel 803 Juniper Networks 805 Email: adrian@olddog.co.uk