idnits 2.17.1 draft-farrresnickel-harassment-06.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 (March 5, 2015) is 3339 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 572 -- Looks like a reference, but probably isn't: '2' on line 575 -- Looks like a reference, but probably isn't: '3' on line 578 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 March 5, 2015 7 Expires: September 6, 2015 9 IETF Anti-Harassment Procedures 10 draft-farrresnickel-harassment-06 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 September 6, 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 . . . . . . . . . . . . . . . . . . 5 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. Purpose of Remedies . . . . . . . . . . . . . . . . . . . 9 69 6. Disputes with the Ombudsteam . . . . . . . . . . . . . . . . 10 70 7. Conflicts of Interest . . . . . . . . . . . . . . . . . . . . 11 71 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 12 72 9. Security Considerations . . . . . . . . . . . . . . . . . . . 12 73 10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 12 74 11. References . . . . . . . . . . . . . . . . . . . . . . . . . 12 75 11.1. Normative References . . . . . . . . . . . . . . . . . . 12 76 11.2. URIs . . . . . . . . . . . . . . . . . . . . . . . . . . 12 77 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 13 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 harassment, evaluate them, and impose 121 appropriate actions and/or remedies to address the circumstances. 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] gives a general definition of 133 harassment as "unwelcome hostile or intimidating behavior -- in 134 particular speech and behavior that is sexually aggressive or 135 intimidates based on attributes like race, gender, religion, age, 136 color, national origin, ancestry, disability, sexual orientation, or 137 gender identity." This document adopts that general definition, but 138 does not attempt to further precisely define behavior that falls 139 under the set of procedures identified here, nor does it attempt to 140 list every possible attribute that might be the basis for harassment, 141 except to note that it may be targeted at an individual, directed at 142 a specific group of people, or more generally impact a broader class 143 of people. In general, disruptive behavior that occurs in the 144 context of an IETF general or working group mailing list, or happens 145 in a face-to-face or virtual meeting of a working group or the IETF 146 plenary, can be dealt with by our normal procedures, whereas 147 harassing behavior that is interpersonal is more appropriately 148 handled by the procedures described here. However, there are 149 plausible reasons to address behaviors that take place during 150 working-group meetings using these procedures. This document gives 151 some guidance to those involved in these situations in order to 152 decide how to handle particular incidents, but the final decision 153 will involve judgment and the guidance of the Ombudsteam. 155 Any definition of harassment prohibited by an applicable law can be 156 subject to this set of procedures. 158 3. The Ombudsteam 160 This section describes the role of the Ombudsteam in terms of the 161 appointment of Ombudspersons, their qualifications and training, the 162 length of the term of service, any recompense for their service, and 163 how they may be removed from service. The general operational 164 procedures for the Ombudsteam are described in Section 4, Section 5, 165 and Section 6. 167 3.1. Size of the Ombudsteam 169 The Ombudsteam shall comprise no fewer than three people. From time 170 to time, the size may fall below that number owing to changes in 171 membership, but the team will be rapidly brought up to size through 172 new appointments. The team may be grown to a larger size as 173 described in Section 3.2 175 3.2. Appointing the Ombudsteam 177 The Ombudsteam is appointed by the IETF Chair. The appointment is 178 solely the responsibility of the IETF Chair who may choose to consult 179 with members of the IETF community. 181 The IETF Chair is encouraged to appoint at least some of the 182 Ombudsteam from within the IETF community. 184 The IETF Chair may choose to solicit nominations or advertise the 185 post. This is entirely at the discretion of the IETF Chair. 187 The IETF Chair is also free to decide to appoint more than three 188 Ombudspersons to the Ombudsteam. This may depend on the skillsets 189 available, the work load, and the opinions of the seated Ombudsteam. 190 Furthermore, the IETF Chair may consider elements of diversity in 191 making this decision. 193 3.3. Professional Advisors 195 It is recognized that the Ombudsteam may need to call on professional 196 services from external advisors for certain matters including legal 197 and Human Resources (HR) advice. The IETF is committed to funding 198 such advice on an "as needed" basis. 200 3.4. Qualifications and Training 202 It is not expected that there will be candidates with all of the 203 necessary ombudsperson skills and training who also have a clear 204 understanding and familiarity with the IETF processes and culture. 205 The Chair might choose someone with a great deal of professional 206 experience evaluating and mediating harassment disputes, but little 207 exposure to the IETF, or could select someone with more exposure to 208 the IETF community, but without as much experience dealing with 209 issues of harassment. Since all of these attributes may be regarded 210 by the IETF Chair as essential for the team, the IETF is committed to 211 providing training (or funding for it) as deemed necessary for 212 appointed Ombudspersons. In determining the appropriate training, 213 the IETF chair and Ombudsteam shall take professional advice and will 214 consult with the IAOC with respect to the overall IETF budget. 216 3.5. Term of Service 218 An Ombudsperson shall be appointed for a two year term. That is, the 219 Ombudsperson is making a commitment to serve for two years. It is 220 understood, however, that circumstances may lead an Ombudsperson to 221 resign for personal or other reasons. See also Section 3.7. 223 If an Ombudsperson's term ends while they are acting as Lead 224 Ombudsperson for a report as described in Section 4, that 225 Ombudsperson's term shall be extended until the handling of that 226 report has been completed. 228 It is entirely at the discretion of the IETF Chair whether a serving 229 Ombudsperson is reappointed at the end of their term. Given the 230 sensitivity of, and training required for, this role and the ideal 231 being a lack of activity, it is likely the IETF chair may choose to 232 re-appoint a successful and still-willing ombudsperson for a number 233 of two year terms. 235 3.6. Recompense 237 An Ombudsperson shall receive no recompense for their services. This 238 includes, but is not limited to: 240 o IETF meeting fees 241 o Remuneration for time spent 243 o Out-of-pocket expenses (such as telephone charges) 245 o Travel or accommodation expenses 247 The IETF will, however, meet the costs of training when agreed to by 248 the IETF Chair as described in Section 3.4. 250 3.7. Removal 252 The IETF Chair may remove a serving Ombudsperson before the end of 253 their term without explanation to the community. Such an action 254 shall be appealable as described in Section 3.8. 256 An Ombudsperson shall not be removed from service, even if their term 257 has expired, during the period that the IETF Chair is recused as 258 described in Section 7. Once the case that led to the Chair being 259 recused has been closed, normal processes resume. 261 3.8. Disputes with the IETF Chair regarding the Ombudsteam 263 If an individual should disagree with an action taken by the IETF 264 Chair regarding the appointment, removal, or management of an 265 Ombudsperson or the Ombudsteam, that person should first discuss the 266 issue with the IETF Chair directly. If the IETF Chair is unable to 267 resolve the issue, the dissatisfied party may appeal to the IESG as a 268 whole. The IESG shall then review the situation and attempt to 269 resolve it in a manner of its own choosing. The procedures of 270 Section 6.5.4 of [RFC2026] apply to this sort of appeal. 272 4. Handling Reports of Harassment 274 Any IETF Participant who believes that they have been harassed, or 275 that any other IETF Participant or group of IETF Participants has 276 been or may have been harassed, may bring the concern to the 277 attention of any serving Ombudsperson. This can be done by email to 278 "ombudsteam@ietf.org" [3], or can be done directly to a chosen 279 Ombudsperson. Direct contact information for the Ombudsteam, 280 including the email addresses to which "ombudsteam@ietf.org" is 281 forwarded, can be found at https://www.ietf.org/ombudsteam . 283 When a Reporter brings an incident of potential harassment to the 284 attention of the Ombudsteam, a single Ombudsperson shall be 285 designated as the primary contact person (the Lead Ombudsperson) for 286 the report. When the Reporter contacts a single Ombudsperson, that 287 Ombudsperson shall be the Lead Ombudsperson for the report unless 288 mutually agreed between the Reporter and that Ombudsperson. 290 The Lead Ombudsperson may share any information regarding the report 291 with the rest of the Ombudsteam except when an Ombudsperson is 292 recused (see Section 7). If a Reporter believes that a member of the 293 Ombudsteam should recuse themself, they should make this known to the 294 Lead Ombudsperson as soon as possible. 296 The Lead Ombudsperson will discuss the events with the Reporter and 297 may give advice including recommendations on how the Reporter can 298 handle the issue on their own as well as strategies on how to prevent 299 the issue from arising again. The Lead Ombudsperson may also 300 indicate that the issue would be best handled using regular IETF 301 procedures (such as those for dealing with disruptive behavior) 302 outside the context of harassment, and in this case the Lead 303 Ombudsperson will provide assistance in using the relevant IETF 304 procedures. Otherwise, with agreement to proceed from the Subject 305 (or the Reporter if there is no individual Subject), the Ombudsteam 306 may initiate detailed investigation of the matter, and may 307 subsequently impose a remedy as described in Section 5. 309 4.1. Ombudsteam Operating Practices 311 The Ombudsteam is responsible for devising and documenting their 312 operating practices. These practices must be discussed with the IESG 313 and published in a publicly visible place (such as on the IETF web 314 site). Discussion with the IETF community is encouraged and, while 315 IETF consensus is not necessary, significant objection to the 316 processes that are not addressed should result in an [RFC2026] 317 Section 6.5.3 appeal and/or a recall petition against the IETF Chair 318 (and the rest of the IESG if appropriate) if they do not address the 319 concern. 321 The practices must include at least the following high-level 322 components: 324 Each member of the Ombudsteam is expected to be present at the 325 majority of IETF meetings and to be available for face-to-face 326 discussions. The Ombudsteam is expected to arrange itself so that 327 there is coverage of every IETF meeting by at least one 328 Ombudsperson. 330 All information brought to the Ombudsteam shall be kept in strict 331 confidence. Any electronic information (such as email messages) 332 that needs to be archived shall be encrypted before it is stored 333 using tools similar to those used by NomCom. 335 When conducting a detailed investigation of the circumstances 336 regarding the complaint of harassment, the Ombudsteam may contact 337 the Respondent and request a meeting in person or by a voice call. 339 The Respondent is not obliged to cooperate, but the Ombudsteam may 340 consider failure to cooperate when determining a remedy 341 (Section 5). 343 The Ombudsteam shall endeavor to complete its investigation in a 344 timely manner. 346 Any individuals who make a good faith report of harassment or who 347 cooperate with an investigation shall not be subject to 348 retaliation for reporting, complaining, or cooperating, even if 349 the investigation, once completed, shows no harassment occurred. 350 Anti-retaliation is noted here to alleviate concerns individuals 351 may have with reference to reporting an incident they feel should 352 be reviewed or cooperating with an investigation. 354 In all cases the Ombudsteam will strive to maintain 355 confidentiality for all parties including the very fact of contact 356 with the Ombudsteam. 358 When investigating reports of harassment and determining remedies, it 359 is up to the Ombudsteam whether they choose to act as a body or 360 delegate duties to the Lead Ombudsperson. 362 5. Remedies 364 After examining the circumstances regarding the complaint of 365 harassment the Ombudsteam should prepare a brief summary of the 366 incident and their conclusions and discuss this with all parties. 367 The objective of this step is to make clear what the Ombudsteam has 368 concluded, and to make an attempt at getting all parties to reach 369 agreement. 371 If the Ombudsteam determines that harassment has taken place, the 372 Ombudsteam is expected to determine the next action. 374 In some cases a mechanism or established IETF process may already 375 exist for handling the specific event. In these cases the 376 Ombudsteam may decide that the misbehavior is best handled with 377 the regular IETF procedures for dealing with disruptive behavior 378 and may assist the Reporter to bring the issue to the attention of 379 the working group chair or IESG member who can deal with the 380 incident. 382 In other cases there is a spectrum of remedies that may be 383 appropriate to the circumstances. At one end of the spectrum, the 384 Ombudsteam might choose to discuss the situation with the 385 Respondent and come up with a plan such that there is no repeat of 386 the harassment. With the agreement of both parties, the 387 Ombudsteam can also help to mediate a conversation between the 388 Respondent and the Subject (or the Reporter if there is no 389 individual Subject) in order to address the issue. 391 At the other end of the spectrum the Ombudsteam could decide that 392 the Respondent is no longer permitted to participate in a 393 particular IETF activity, for example, ejecting them from a 394 meeting or requiring that the Respondent can no longer attend 395 future meetings. (The Ombudsteam can not impose that a Respondent 396 who is in a IETF management position be removed from that 397 position. There are existing mechanisms within IETF process for 398 the removal of people from IETF management positions that may be 399 used as necessary.) 401 In determining the appropriate remedy, the Ombudsteam may 402 communicate with the Reporter, Subject, or Respondent in order to 403 assess the impact that the imposition of a remedy might have on 404 any of those parties. However, the Ombudsteam has ultimate 405 responsibility for the choice of remedy. 407 In all cases, the Lead Ombudsperson informs the Respondent of the 408 decision and imposes the remedy as appropriate. In cases where 409 the remedy is removal from IETF activities, the Lead Ombudsperson 410 will confidentially notify the Secretariat of the remedy such that 411 the Secretariat can take whatever logistical actions are required 412 to effect the remedy. Only the remedy itself shall be disclosed 413 to the Secretariat, not any information regarding the nature of 414 the harassment. 416 5.1. Purpose of Remedies 418 The purpose of the anti-harassment policy is to prevent all incidents 419 of harassment in the IETF. The set of procedures documented here 420 serves to provide a mechanism whereby any harassment that occurs can 421 be reported and handled both sympathetically and effectively. The 422 policy also sends a clear message that the IETF does not tolerate 423 harassment in any form. 425 However any remedy is imposed to try to make sure that the incident 426 does not escalate and to ensure that a similar situation is unlikely 427 to occur with the same Respondent in the future. 429 Because the handling of incidents of harassment (including the 430 imposition of remedies) is confidential, an imposed remedy cannot 431 itself serve as a deterrent to others, nor can it be used to "teach" 432 the community how to behave. ([RFC7154] gives guidelines for conduct 433 in the IETF.) Furthermore, a remedy is not to be imposed for the 434 purposes of retribution. However, the knowledge of the existence of 435 a range of remedies and of processes by which they can be applied 436 serves both as a statement of the IETF's seriousness in this matter, 437 and as a deterrent to potential offenders. 439 The Ombudsteam is expected to apply the above considerations, as well 440 as proportionality and reasonableness, in selecting a remedy. They 441 are asked to consider the impact of the remedy on the Respondent as 442 well as on the Subject. 444 6. Disputes with the Ombudsteam 446 If either the Subject (or the Reporter if there is no individual 447 Subject) or the Respondent is dissatisfied with the decision of the 448 Ombudsteam, the dissatisfied party should first contact the Lead 449 Ombudsperson and discuss the situation. If the issue cannot be 450 resolved through discussion with the Lead Ombudsperson, the issue may 451 be raised with the IETF Chair. 453 If necessary, the IETF Chair may recuse themself from any part of 454 this process (see Section 7) and request the IESG to select another 455 of its members to serve in this role. This IESG member is known as 456 the "delegated IESG member". 458 The IETF Chair (or the delegated IESG member if the Chair is recused) 459 will attempt to resolve the issue in discussion with the dissatisfied 460 party and the Lead Ombudsperson. If this further discussion does not 461 bring a satisfactory resolution, the Ombudsteam's decision may be 462 formally appealed. The appeal is strictly on the issue of whether 463 the Ombudsteam exercised due diligence in both their decision as to 464 whether harassment had taken place, as well as in their determination 465 of any appropriate remedy that was imposed. In particular, the 466 purpose of the appeal is not to re-investigate the circumstances of 467 the incident or to negotiate the severity of the remedy. 469 All elements of the appeal, including the fact of the appeal, will be 470 held in confidence, but will be recorded and held securely for future 471 reference. 473 The appeal will be evaluated by the IETF Chair (or the delegated IESG 474 member) and two other members of the IESG selected by the IETF Chair 475 (or the delegated IESG member) and confirmed by the appellant. This 476 Appeals Group shall convene as quickly as possible to evaluate and 477 determine the appeal. Where the impacts are immediate and related to 478 participation in an ongoing meeting, this shall happen in no more 479 than 24 hours after receiving the appeal. The Appeals Group may ask 480 the appellant and the Lead Ombudsperson for statements or other 481 information to consider. If the Appeals Group concludes that due 482 diligence was exercised by the Ombudsteam, this shall be reported to 483 the appellant and the matter is concluded. If the Appeals Group 484 finds that due diligence was not exercised, the Appeals Group shall 485 report this to the Ombudsteam, and consult with the Ombudsteam on how 486 to complete the due diligence. 488 Because of the need to keep the information regarding these matters 489 as confidential as possible, the Appeals Group's decision is final 490 with respect to the question of whether the Ombudsteam has used due 491 diligence in their decision. The only further recourse available is 492 to claim that the procedures themselves (i.e., the procedures 493 described in this document) are inadequate or insufficient to the 494 protection of the rights of all parties. Such a claim may be made in 495 an appeal to the Internet Society Board of Trustees, as described in 496 Section 6.5.3 of [RFC2026]. Again, even in this circumstance, the 497 particulars of the incident at hand will be held in confidence. 499 7. Conflicts of Interest 501 In the event of any conflict of interest, the conflicted person 502 (member of the Ombudsteam, member of the Appeals Group, IETF Chair, 503 etc.) is expected to recuse themselves. 505 A conflict of interest may arise if someone involved in the process 506 of handling a harassment report is in the role of Reporter, 507 Respondent, or Subject. Furthermore, a conflict of interest arises 508 if the person involved in the process of handling a harassment report 509 is closely associated personally or through affiliation with any of 510 the Reporter, Respondent, or Subject. 512 For the avoidance of doubt, recusal in this context means completely 513 stepping out of any advisory or decision-making part of any process 514 associated with handling a harassment report, remedy arising from a 515 harassment report, or appeal into the handling of a harassment 516 report. That means that a recused person has no more right to 517 participate in or witness the process than any other person from the 518 community in the same situation. For example, therefore, an 519 Ombudsperson subject to a complaint of harassment shall not be privy 520 to the deliberations of another Ombudsperson handling the report. 521 Nor would an IESG member who was party to an appeal be able to 522 witness the discussions of the Appeals Group. 524 In the event that there is an appeal and the IETF Chair is somehow 525 involved, the Chair will immediately recuse themself and the IESG 526 will select a single person to take the Chair's role in the appeal 527 process as described in Section 6. 529 8. IANA Considerations 531 None. 533 9. Security Considerations 535 "Human beings the world over need freedom and security that they may 536 be able to realize their full potential." -- Aung San Suu Kyi 538 10. Acknowledgements 540 The text in this document benefited from the lively discussion on the 541 ietf@ietf.org mailing list. Thanks to everyone who participated. 543 Specific changes to this document resulted from comments by 544 Abdussalam Baryun, Alessandro Vesely, S Moonesamy, Timothy B. 545 Terriberry, John Levine, Andrea Glorioso, Dave Crocker, John Leslie, 546 Linda Klieforth, Brian Carpenter, Mary Barnes, Spencer Dawkins, 547 Michael StJohns, Alissa Cooper, James Woodyatt, and Stephen Farrell. 548 The authors would like to express their gratitude. 550 The authors would also like to acknowledge the legal review provided 551 by Scott Young and David Wilson from Thompson Hine LLP. 553 11. References 555 11.1. Normative References 557 [RFC2026] Bradner, S., "The Internet Standards Process -- Revision 558 3", BCP 9, RFC 2026, October 1996. 560 [RFC2418] Bradner, S., "IETF Working Group Guidelines and 561 Procedures", BCP 25, RFC 2418, September 1998. 563 [RFC3934] Wasserman, M., "Updates to RFC 2418 Regarding the 564 Management of IETF Mailing Lists", BCP 25, RFC 3934, 565 October 2004. 567 [RFC7154] Moonesamy, S., "IETF Guidelines for Conduct", BCP 54, RFC 568 7154, March 2014. 570 11.2. URIs 572 [1] https://www.ietf.org/iesg/statement/ietf-anti-harassment- 573 policy.html 575 [2] https://www.ietf.org/iesg/statement/ietf-anti-harassment- 576 policy.html 578 [3] mailto:ombudsteam@ietf.org 580 Authors' Addresses 582 Pete Resnick 583 Qualcomm Technologies, Inc. 584 5775 Morehouse Drive 585 San Diego, CA 92121 586 US 588 Phone: +1 858 651 4478 589 Email: presnick@qti.qualcomm.com 591 Adrian Farrel 592 Juniper Networks 594 Email: adrian@olddog.co.uk