idnits 2.17.1 draft-farrresnickel-harassment-05.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 (January 6, 2015) is 3398 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) -- Looks like a reference, but probably isn't: '1' on line 542 -- Looks like a reference, but probably isn't: '2' on line 545 -- Looks like a reference, but probably isn't: '3' on line 548 Summary: 0 errors (**), 0 flaws (~~), 1 warning (==), 5 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 (if approved) Juniper Networks 6 Intended status: Best Current Practice January 6, 2015 7 Expires: July 6, 2015 9 IETF Anti-Harassment Procedures 10 draft-farrresnickel-harassment-05 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. 20 Status of This Memo 22 This Internet-Draft is submitted in full conformance with the 23 provisions of BCP 78 and BCP 79. 25 Internet-Drafts are working documents of the Internet Engineering 26 Task Force (IETF). Note that other groups may also distribute 27 working documents as Internet-Drafts. The list of current Internet- 28 Drafts is at http://datatracker.ietf.org/drafts/current/. 30 Internet-Drafts are draft documents valid for a maximum of six months 31 and may be updated, replaced, or obsoleted by other documents at any 32 time. It is inappropriate to use Internet-Drafts as reference 33 material or to cite them other than as "work in progress." 35 This Internet-Draft will expire on July 10, 2015. 37 Copyright Notice 39 Copyright (c) 2015 IETF Trust and the persons identified as the 40 document authors. All rights reserved. 42 This document is subject to BCP 78 and the IETF Trust's Legal 43 Provisions Relating to IETF Documents 44 (http://trustee.ietf.org/license-info) in effect on the date of 45 publication of this document. Please review these documents 46 carefully, as they describe your rights and restrictions with respect 47 to this document. Code Components extracted from this document must 48 include Simplified BSD License text as described in Section 4.e of 49 the Trust Legal Provisions and are provided without warranty as 50 described in the Simplified BSD License. 52 Table of Contents 54 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 55 2. Definitions . . . . . . . . . . . . . . . . . . . . . . . . . 3 56 3. The Ombudsteam . . . . . . . . . . . . . . . . . . . . . . . 4 57 3.1. Size of the Ombudsteam . . . . . . . . . . . . . . . . . 4 58 3.2. Appointing the Ombudsteam . . . . . . . . . . . . . . . . 4 59 3.3. Professional Advisors . . . . . . . . . . . . . . . . . . 4 60 3.4. Qualifications and Training . . . . . . . . . . . . . . . 5 61 3.5. Term of Service . . . . . . . . . . . . . . . . . . . . . 5 62 3.6. Recompense . . . . . . . . . . . . . . . . . . . . . . . 5 63 3.7. Removal . . . . . . . . . . . . . . . . . . . . . . . . . 6 64 3.8. Disputes with the IETF Chair regarding the Ombudsteam . . 6 65 4. Handling Reports of Harassment . . . . . . . . . . . . . . . 6 66 4.1. Ombudsteam Operating Practices . . . . . . . . . . . . . 7 67 5. Remedies . . . . . . . . . . . . . . . . . . . . . . . . . . 8 68 5.1. Remedy is Not Punishment . . . . . . . . . . . . . . . . 9 69 6. Disputes with the Ombudsteam . . . . . . . . . . . . . . . . 9 70 7. Conflicts of Interest . . . . . . . . . . . . . . . . . . . . 11 71 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 11 72 9. Security Considerations . . . . . . . . . . . . . . . . . . . 11 73 10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 11 74 11. References . . . . . . . . . . . . . . . . . . . . . . . . . 12 75 11.1. Normative References . . . . . . . . . . . . . . . . . . 12 76 11.2. URIs . . . . . . . . . . . . . . . . . . . . . . . . . . 12 77 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 12 79 1. Introduction 81 The IETF has general policies for managing disruptive behavior in the 82 context of IETF activities. In particular, [RFC7154] provides a set 83 of guidelines for personal interaction in the IETF, and [RFC2418] and 84 [RFC3934] give guidelines for how to deal with disruptive behavior 85 that occurs in the context of IETF working group face-to-face 86 meetings and on mailing lists. 88 However, there is other problematic, often more interpersonal, 89 behavior that can occur in the context of IETF activities (meetings, 90 mailing list discussions, or social events) that does not directly 91 disrupt working group progress, but nonetheless is unacceptable 92 behavior between IETF Participants. This sort of behavior, described 93 in the IESG Statement on an "IETF Anti-Harassment Policy" [1], is not 94 easily dealt with by our previously existing working group guidelines 95 and procedures. Therefore, this document sets forth procedures to 96 deal with such harassing behavior. These procedures are intended to 97 be used when other IETF policies and procedures do not apply or have 98 been ineffective. 100 Nothing in this document should be taken to interfere with the due 101 process of law for the legal system under the jurisdiction of which 102 any harassment takes place. Similarly, it does not release any 103 person from any contractual or corporate policies to which they may 104 be subject. 106 2. Definitions 108 The following terms are used in this document: 110 IETF Participant: Anyone who participates in an IETF activity, 111 including IETF support staff. 113 Reporter: An IETF Participant who reports potential harassment to 114 an Ombudsperson. 116 Respondent: An IETF Participant who is claimed to have engaged in 117 harassing behavior. 119 Ombudsteam: A group of people who have been selected to take 120 reports of potential harassement, evaluate them, and impose 121 appropriate actions and/or remedies to address the circumstance. 123 Ombudsperson: A member of the Ombudsteam. 125 Lead Ombudsperson: The Ombudsperson assigned to be the primary 126 contact person for a particular report of potential harassment. 128 Subject: An individual, group, or class of IETF Participant to 129 whom the potentially harassing behavior was directed or who might 130 be subject to the behavior. 132 The IESG statement on harassment [2] defines harassment as "unwelcome 133 hostile or intimidating behavior, in particular speech and behavior 134 that is sexually aggressive or intimidates based on attributes like 135 race, gender, religion, age, color, national origin, ancestry, 136 disability, sexual orientation, or gender identity." This document 137 adopts that definition and does not attempt to further precisely 138 define behavior that falls under the set of procedures identified 139 here except to note that it may be targeted at an individual, 140 directed at a specific group of people, or more generally impacting a 141 broader class of people. In general, disruptive behavior that occurs 142 in the context of an IETF general or working group mailing list, or 143 happens in a face-to-face or virtual meeting of a working group or 144 the IETF plenary, can be dealt with by our normal procedures, whereas 145 harassing behavior that is interpersonal is more easily handled by 146 the procedures described here. However, there are plausible reasons 147 to address behaviors that take place during working-group meetings 148 using these procedures. This document gives some guidance to those 149 involved in these situations in order to decide how to handle 150 particular incidents, but the final decision will involve judgment 151 and the guidance of the Ombudsteam. 153 3. The Ombudsteam 155 This section describes the role of the Ombudsteam in terms of the 156 appointment of Ombudspersons, their qualifications and training, the 157 length of the term of service, any recompense for their service, and 158 how they may be removed from service. The general operational 159 procedures for the Ombudsteam are described in Section 4, Section 5, 160 and Section 6. 162 3.1. Size of the Ombudsteam 164 The Ombudsteam shall comprise no fewer than three people. From time 165 to time, the size may fall below that number owing to changes in 166 membership, but the team will be rapidly brought up to size through 167 new appointments. The team may be grown to a larger size as 168 described in Section 3.2 170 3.2. Appointing the Ombudsteam 172 The Ombudsteam is appointed by the IETF Chair. The appointment is 173 solely the responsibility of the IETF Chair who may choose to consult 174 with members of the IETF community. 176 The IETF Chair is encouraged to appoint at least some of the 177 Ombudsteam from within the IETF community. 179 The IETF Chair may choose to solicit nominations or advertise the 180 post. This is entirely at the discretion of the IETF Chair. 182 The IETF Chair is also free to decide to appoint more than three 183 Ombudspersons to the Ombudsteam. This may depend on the skillsets 184 available, the work load, and the opinions of the seated Ombudsteam. 185 Furthermore, the IETF Chair may consider elements of diversity in 186 making this decision. 188 3.3. Professional Advisors 190 It is recognized that the Ombudsteam may need to call on professional 191 services from external advisors for certain matters including legal 192 and Human Resources (HR) advice. The IETF is committed to funding 193 such advice on an "as needed" basis. 195 3.4. Qualifications and Training 197 It is not expected that there will be candidates with all of the 198 necessary ombudsperson skills and training who also have a clear 199 understanding and familiarity with the IETF processes and culture. 200 The Chair might choose someone with a great deal of professional 201 experience evaluating and mediating harassment disputes, but little 202 exposure to the IETF, or could select someone with more exposure to 203 the IETF community, but without as much experience dealing with 204 issues of harassment. Since all of these attributes may be regarded 205 by the IETF Chair as essential for the team, the IETF is committed to 206 providing training (or funding for it) as deemed necessary for 207 appointed Ombudspersons. In determining the appropriate training, 208 the IETF chair and Ombudsteam shall take professional advice and will 209 consult with the IAOC with respect to the overall IETF budget. 211 3.5. Term of Service 213 An Ombudsperson shall be appointed for a two year term. That is, the 214 Ombudsperson is making a commitment to serve for two years. It is 215 understood, however, that circumstances may lead an Ombudsperson to 216 resign for personal or other reasons. See also Section 3.7. 218 It is entirely at the discretion of the IETF Chair whether a serving 219 Ombudsperson is reappointed at the end of their term. 221 3.6. Recompense 223 An Ombudsperson shall receive no recompense for their services. This 224 includes, but is not limited to: 226 o IETF meeting fees 228 o Remuneration for time spent 230 o Out-of-pocket expenses (such as telephone charges) 232 o Travel or accommodation expenses 234 The IETF will, however, meet the costs of training when agreed to by 235 the IETF Chair as described in Section 3.4. 237 3.7. Removal 239 The IETF Chair may remove a serving Ombudsperson before the end of 240 their term without explanation to the community. Such an action 241 shall be appealable as described in Section 3.8. 243 An Ombudsperson shall not be removed from service, even if their term 244 has expired, during the period that the IETF Chair is recused as 245 described in Section 7. Once the case that led to the Chair being 246 recused has been closed, normal processes resume. 248 3.8. Disputes with the IETF Chair regarding the Ombudsteam 250 If an individual should disagree with an action taken by the IETF 251 Chair regarding the appointment, removal, or management of an 252 Ombudsperson or the Ombudsteam, that person should first discuss the 253 issue with the IETF Chair directly. If the IETF Chair is unable to 254 resolve the issue, the dissatisfied party may appeal to the IESG as a 255 whole. The IESG shall then review the situation and attempt to 256 resolve it in a manner of its own choosing. The procedures of 257 Section 6.5.4 of [RFC2026] apply to this sort of appeal. 259 4. Handling Reports of Harassment 261 Any IETF Participant who believes that they have been harassed, or 262 that any other IETF Participant or group of IETF Participants has 263 been or may have been harassed, may bring the concern to the 264 attention of any serving Ombudsperson. This can be done by email to 265 "ombudsteam@ietf.org" [3], or can be done directly to a chosen 266 Ombudsperson. Direct contact information for the Ombudsteam, 267 including the email addresses to which "ombudsteam@ietf.org" is 268 forwarded, can be found at https://www.ietf.org/ombudsteam . 270 When a Reporter brings an incident of potential harassment to the 271 attention of the Ombudsteam, a single Ombudsperson shall be 272 designated as the primary contact person (the Lead Ombudsperson) for 273 the report. When the Reporter contacts a single Ombudsperson, that 274 Ombudsperson shall be the Lead Ombudsperson for the report unless 275 mutually agreed between the Reporter and that Ombudsperson. 277 The Lead Ombudsperson may share any information regarding the report 278 with the rest of the Ombudsteam except when an Ombudsperson is 279 recused (see Section 7). If a Reporter believes that a member of the 280 Ombudsteam should recuse themself, they should make this known to the 281 Lead Ombudsperson as soon as possible. 283 The Lead Ombudsperson will discuss the events with the Reporter and 284 may give advice including recommendations on how the Reporter can 285 handle the issue on their own as well as strategies on how to prevent 286 the issue from arising again. The Lead Ombudsperson may also 287 indicate that the issue would be best handled using regular IETF 288 procedures (such as those for dealing with disruptive behavior) 289 outside the context of harassment, and in this case the Lead 290 Ombudsperson will provide assistance in using the relevant IETF 291 procedures. Otherwise, with agreement to proceed from the Subject 292 (or the Reporter if there is no individual Subject), the Ombudsteam 293 may initiate detailed investigation of the matter, and may 294 subsequently impose a remedy as described in Section 5. 296 4.1. Ombudsteam Operating Practices 298 The Ombudsteam is responsible for devising and documenting their 299 operating practices. These practices must be discussed with the IESG 300 and published in a publicly visible place (such as on the IETF web 301 site). Discussion with the IETF community is encouraged and, while 302 IETF consensus is not necessary, significant objection to the 303 processes that are not addressed should result in an RFC 2026 304 Section 6.5.3 appeal and/or a recall petition against the IETF Chair 305 (and the rest of the IESG if appropriate) if they do not address the 306 concern. 308 The practices must include at least the following high-level 309 components: 311 Each member of the Ombudsteam is expected to be present at the 312 majority of IETF meetings and to be available for face-to-face 313 discussions. The Ombudsteam is expected to arrange itself so that 314 there is coverage of every IETF meeting by at least one 315 Ombudsperson. 317 All information brought to the Ombudsteam shall be kept in strict 318 confidence. Any electronic information (such as email messages) 319 that needs to be archived shall be encrypted before it is stored 320 using tools similar to those used by NomCom. 322 When conducting a detailed investigation of the circumstances 323 regarding the complaint of harassment, the Ombudsteam may contact 324 the Respondent and request a meeting in person or by a voice call. 325 The Respondent is not obliged to cooperate, but the Ombudsteam may 326 consider failure to cooperate when determining a remedy 327 (Section 5). 329 The Ombudsteam shall endeavor to complete its investigation in a 330 timely manner. 332 Any individuals who make a good faith report of harassment or who 333 cooperate with an investigation shall not be subject to 334 retaliation for reporting, complaining, or cooperating, even if 335 the investigation, once completed, shows no harassment occurred. 336 Anti-retaliation is noted here to alleviate concerns individuals 337 may have with reference to reporting an incident they feel should 338 be reviewed. 340 In all cases the Ombudsteam will strive to maintain 341 confidentiality for all parties including the very fact of contact 342 with the Ombudsteam. 344 When investigating reports and determining remedies, it is up to the 345 Ombudsteam whether they choose to act as a body or delegate duties to 346 the Lead Ombudsperson. 348 5. Remedies 350 After examining the circumstances regarding the complaint of 351 harassment the Ombudsteam should prepare a brief summary of the 352 incident and their conclusions and discuss this with all parties. 353 The objective of this step is to make clear what the Ombudsteam has 354 concluded, and to make an attempt at getting all parties to reach 355 agreement. 357 If the Ombudsteam determines that harassment has taken place, the 358 Ombudsteam is expected to determine the next action. 360 In some cases a mechanism or established IETF process may already 361 exist for handling the specific event. In these cases the 362 Ombudsteam may decide that the misbehavior is best handled with 363 the regular IETF procedures for dealing with disruptive behavior 364 and may assist the Reporter to bring the issue to the attention of 365 the working group chair or IESG member who can deal with the 366 incident. 368 In other cases there is a spectrum of remedies that may be 369 appropriate to the circumstances. At one end of the spectrum, the 370 Ombudsteam might choose to discuss the situation with the 371 Respondent and come up with a plan such that there is no repeat of 372 the harassment. With the agreement of both parties, the 373 Ombudsteam can also help to mediate a conversation between the 374 Respondent and the Subject (or the Reporter if there is no 375 individual Subject) in order to address the issue. 377 At the other end of the spectrum the Ombudsteam could decide that 378 the Respondent is no longer permitted to participate in a 379 particular IETF activity, for example, ejecting them from a 380 meeting or requiring that the Respondent can no longer attend 381 future meetings. (The Ombudsteam can recommend, but can not 382 impose, that a Respondent who is in a IETF management position be 383 removed from that position. There are existing mechanisms within 384 IETF process for the removal of people from IETF management 385 positions that may be used as necessary.) 387 In determining the appropriate remedy, the Ombudsteam may 388 communicate with the Reporter, Subject, or Respondent in order to 389 assess the impact that the imposition of a remedy might have on 390 any of those parties. However, the Ombudsteam has ultimate 391 responsibility for the choice of remedy. 393 In all cases, the Lead Ombudsperson informs the Respondent of the 394 decision and imposes the remedy as appropriate. In cases where 395 the remedy is removal from IETF activities, the Lead Ombudsperson 396 will confidentially notify the Secretariat of the remedy such that 397 the Secretariat can take whatever logistical actions are required 398 to effect the remedy. Only the remedy itself shall be disclosed 399 to the Secretariat, not any information regarding the nature of 400 the harassment. 402 5.1. Remedy is Not Punishment 404 It is understood that the purpose of a remedy is not punishment. 405 That is, the remedy is imposed solely to try to make sure that the 406 incident does not escalate and to ensure that a similar situation is 407 unlikely to occur with the same Respondent in the future. 409 A remedy is not to be imposed for the purposes of retribution or as a 410 deterrent to others. It is also not intended to teach the community 411 how to behave - please see RFC 7154 for guidelines for conduct in the 412 IETF. The Ombudsteam are expected to apply considerations of 413 proportionality and reasonableness in selecting a remedy, and are 414 asked to consider the impact of the remedy on the Respondent as well 415 as on the Subject. 417 6. Disputes with the Ombudsteam 419 If either the Subject (or the Reporter if there is no individual 420 Subject) or the Respondent is dissatisfied with the decision of the 421 Ombudsteam, the dissatisfied party should first contact the Lead 422 Ombudsperson and discuss the situation. If the issue cannot be 423 resolved through discussion with the Lead Ombudsperson, the issue may 424 be raised with the IETF Chair. 426 If necessary, the IETF Chair may recuse themself from any part of 427 this process (see Section 7) and request the IESG to select another 428 of its members to serve in this role. This IESG member is known as 429 the "delegated IESG member". 431 The IETF Chair (or the delegated IESG member if the Chair is recused) 432 will attempt to resolve the issue in discussion with the dissatisfied 433 party and the Lead Ombudsperson. If this further discussion does not 434 bring a satisfactory resolution, the Ombudsteam's decision may be 435 formally appealed. The appeal is strictly on the issue of whether 436 the Ombudsteam exercised due diligence in both their decision as to 437 whether harassment had taken place, as well as in their determination 438 of any appropriate remedy that was imposed. In particular, the 439 purpose of the appeal is not to re-investigate the circumstances of 440 the incident or to negotiate the severity of the remedy. 442 All elements of the appeal, including the fact of the appeal, will be 443 held in confidence, but will be recorded and held securely for future 444 reference. 446 The appeal will be evaluated by the IETF Chair (or the delegated IESG 447 member) and two other members of the IESG selected by the IETF Chair 448 (or the delegated IESG member) and confirmed by the appellant. This 449 Appeals Group shall convene as quickly as possible to evaluate and 450 determine the appeal. Where the impacts are immediate and related to 451 participation in an ongoing meeting, this shall happen in no more 452 than 24 hours after receiving the appeal. The Appeals Group may ask 453 the appellant and the Lead Ombudsperson for statements or other 454 information to consider. If the Appeals Group concludes that due 455 diligence was exercised by the Ombudsteam, this shall be reported to 456 the appellant and the matter is concluded. If the Appeals Group 457 finds that due diligence was not exercised, the Appeals Group shall 458 report this to the Ombudsteam, and consult with the Ombudsteam on how 459 to complete the due diligence. 461 Because of the need to keep the information regarding these matters 462 as confidential as possible, the Appeals Group's decision is final 463 with respect to the question of whether the Ombudsteam has used due 464 diligence in their decision. The only further recourse available is 465 to claim that the procedures themselves (i.e., the procedures 466 described in this document) are inadequate or insufficient to the 467 protection of the rights of all parties. Such a claim may be made in 468 an appeal to the Internet Society Board of Trustees, as described in 469 Section 6.5.3 of [RFC2026]. Again, even in this circumstance, the 470 particulars of the incident at hand will be held in confidence. 472 7. Conflicts of Interest 474 In the event of any conflict of interest, the conflicted person 475 (member of the Obmudsteam, member of the Appeals Group, IETF Chair, 476 etc.) is expected to recuse themselves. 478 A conflict of interest may arise if someone involved in the process 479 of handling a harassment report is in the role of Reporter, 480 Respondent, or Subject. Furthermore, a conflict of interest arises 481 if the person involved in the process of handling a harassment report 482 is closely associated personally or through affiliation with any of 483 the Reporter, Respondent, or Subject. 485 For the avoidance of doubt, recusal in this context means completely 486 stepping out of any advisory or decision-making part of any process 487 associated with handling a harassment report, remedy arising from a 488 harassment report, or appeal into the handling of a harassment 489 report. That means that a recused person has no more right to 490 participate in or witness the process than any other person from the 491 community in the same situation. For example, therefore, an 492 Ombudsperson subject to a complaint of harassment shall not be privy 493 to the deliberations of another Ombudsperson handling the report. 494 Nor would an IESG member who was party to an appeal be able to 495 witness the discussions of the Appeals Group. 497 In the event that there is an appeal and the IETF Chair is somehow 498 involved, the Chair will immediately recuse themself and the IESG 499 will select a single person to take the Chair's role in the appeal 500 process as described in Section 6. 502 8. IANA Considerations 504 None. 506 9. Security Considerations 508 "Human beings the world over need freedom and security that they may 509 be able to realize their full potential." -- Aung San Suu Kyi 511 10. Acknowledgements 513 The text in this document benefited from the lively discussion on the 514 ietf@ietf.org mailing list. Thanks to everyone who participated. 516 Specific changes to this document resulted from comments by 517 Abdussalam Baryun, Alessandro Vesely, S Moonesamy, Timothy B. 518 Terriberry, John Levine, Andrea Glorioso, Dave Crocker, John Leslie, 519 Linda Klieforth, Brian Carpenter, Mary Barnes, Spencer Dawkins, 520 Michael StJohns, and Alissa Cooper. The authors would like to 521 express their gratitude. 523 11. References 525 11.1. Normative References 527 [RFC2026] Bradner, S., "The Internet Standards Process -- Revision 528 3", BCP 9, RFC 2026, October 1996. 530 [RFC2418] Bradner, S., "IETF Working Group Guidelines and 531 Procedures", BCP 25, RFC 2418, September 1998. 533 [RFC3934] Wasserman, M., "Updates to RFC 2418 Regarding the 534 Management of IETF Mailing Lists", BCP 25, RFC 3934, 535 October 2004. 537 [RFC7154] Moonesamy, S., "IETF Guidelines for Conduct", BCP 54, RFC 538 7154, March 2014. 540 11.2. URIs 542 [1] http://www.ietf.org/iesg/statement/ietf-anti-harassment- 543 policy.html 545 [2] http://www.ietf.org/iesg/statement/ietf-anti-harassment- 546 policy.html 548 [3] mailto:ombudsteam@ietf.org 550 Authors' Addresses 552 Pete Resnick 553 Qualcomm Technologies, Inc. 554 5775 Morehouse Drive 555 San Diego, CA 92121 556 US 558 Phone: +1 858 651 4478 559 Email: presnick@qti.qualcomm.com 561 Adrian Farrel 562 Juniper Networks 564 Email: adrian@olddog.co.uk