summaryrefslogtreecommitdiff
path: root/doc/rfc/rfc7776.txt
blob: 91ad3021f6b1caf0565e87fe9a819c7608922692 (plain) (blame)
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
195
196
197
198
199
200
201
202
203
204
205
206
207
208
209
210
211
212
213
214
215
216
217
218
219
220
221
222
223
224
225
226
227
228
229
230
231
232
233
234
235
236
237
238
239
240
241
242
243
244
245
246
247
248
249
250
251
252
253
254
255
256
257
258
259
260
261
262
263
264
265
266
267
268
269
270
271
272
273
274
275
276
277
278
279
280
281
282
283
284
285
286
287
288
289
290
291
292
293
294
295
296
297
298
299
300
301
302
303
304
305
306
307
308
309
310
311
312
313
314
315
316
317
318
319
320
321
322
323
324
325
326
327
328
329
330
331
332
333
334
335
336
337
338
339
340
341
342
343
344
345
346
347
348
349
350
351
352
353
354
355
356
357
358
359
360
361
362
363
364
365
366
367
368
369
370
371
372
373
374
375
376
377
378
379
380
381
382
383
384
385
386
387
388
389
390
391
392
393
394
395
396
397
398
399
400
401
402
403
404
405
406
407
408
409
410
411
412
413
414
415
416
417
418
419
420
421
422
423
424
425
426
427
428
429
430
431
432
433
434
435
436
437
438
439
440
441
442
443
444
445
446
447
448
449
450
451
452
453
454
455
456
457
458
459
460
461
462
463
464
465
466
467
468
469
470
471
472
473
474
475
476
477
478
479
480
481
482
483
484
485
486
487
488
489
490
491
492
493
494
495
496
497
498
499
500
501
502
503
504
505
506
507
508
509
510
511
512
513
514
515
516
517
518
519
520
521
522
523
524
525
526
527
528
529
530
531
532
533
534
535
536
537
538
539
540
541
542
543
544
545
546
547
548
549
550
551
552
553
554
555
556
557
558
559
560
561
562
563
564
565
566
567
568
569
570
571
572
573
574
575
576
577
578
579
580
581
582
583
584
585
586
587
588
589
590
591
592
593
594
595
596
597
598
599
600
601
602
603
604
605
606
607
608
609
610
611
612
613
614
615
616
617
618
619
620
621
622
623
624
625
626
627
628
629
630
631
632
633
634
635
636
637
638
639
640
641
642
643
644
645
646
647
648
649
650
651
652
653
654
655
656
657
658
659
660
661
662
663
664
665
666
667
668
669
670
671
672
673
674
675
676
677
678
679
680
681
682
683
684
685
686
687
688
689
690
691
692
693
694
695
696
697
698
699
700
701
702
703
704
705
706
707
708
709
710
711
712
713
714
715
716
717
718
719
720
721
722
723
724
725
726
727
728
729
730
731
732
733
734
735
736
737
738
739
740
741
742
743
744
745
746
747
748
749
750
751
752
753
754
755
756
757
758
759
760
761
762
763
764
765
766
767
768
769
770
771
772
773
774
775
776
777
778
779
780
781
782
783
784
785
786
787
788
789
790
791
792
793
794
795
796
797
798
799
800
801
802
803
804
805
806
807
808
809
810
811
812
813
814
815
816
817
818
819
820
821
822
823
824
825
826
827
828
829
830
831
832
833
834
835
836
837
838
839
840
841
842
843
844
845
846
847
848
849
850
851
852
853
854
855
856
857
858
859
860
861
862
863
864
865
866
867
868
869
870
871
872
873
874
875
876
877
878
879
880
881
882
883
884
885
886
887
888
889
890
891
892
893
894
895
896
897
898
899
900
901
902
903
904
905
906
907
908
909
910
911
912
913
914
915
916
917
918
919
920
921
922
923
924
925
926
927
928
929
930
931
932
933
934
935
936
937
938
939
940
941
942
943
944
945
946
947
948
949
950
951
952
953
954
955
956
957
958
959
960
961
962
963
964
965
966
967
968
969
970
971
972
973
974
975
976
977
978
979
980
981
982
983
984
985
986
987
988
989
990
991
992
993
994
995
996
997
998
999
1000
1001
1002
1003
1004
1005
1006
1007
1008
1009
1010
1011
Internet Engineering Task Force (IETF)                        P. Resnick
Request for Comments: 7776                   Qualcomm Technologies, Inc.
BCP: 25                                                        A. Farrel
Updates: 2418, 7437                                     Juniper Networks
Category: Best Current Practice                               March 2016
ISSN: 2070-1721


                    IETF Anti-Harassment Procedures

Abstract

   IETF Participants must not engage in harassment while at IETF
   meetings, virtual meetings, or social events or while participating
   in mailing lists.  This document lays out procedures for managing and
   enforcing this policy.

   This document updates RFC 2418 by defining new working group
   guidelines and procedures.  This document updates RFC 7437 by
   allowing the Ombudsteam to form a recall petition without further
   signatories.

Status of This Memo

   This memo documents an Internet Best Current Practice.

   This document is a product of the Internet Engineering Task Force
   (IETF).  It represents the consensus of the IETF community.  It has
   received public review and has been approved for publication by the
   Internet Engineering Steering Group (IESG).  Further information on
   BCPs is available in Section 2 of RFC 5741.

   Information about the current status of this document, any errata,
   and how to provide feedback on it may be obtained at
   http://www.rfc-editor.org/info/rfc7776.
















Resnick & Farrel          Best Current Practice                 [Page 1]
^L
RFC 7776               Anti-Harassment Procedures             March 2016


Copyright Notice

   Copyright (c) 2016 IETF Trust and the persons identified as the
   document authors.  All rights reserved.

   This document is subject to BCP 78 and the IETF Trust's Legal
   Provisions Relating to IETF Documents
   (http://trustee.ietf.org/license-info) in effect on the date of
   publication of this document.  Please review these documents
   carefully, as they describe your rights and restrictions with respect
   to this document.  Code Components extracted from this document must
   include Simplified BSD License text as described in Section 4.e of
   the Trust Legal Provisions and are provided without warranty as
   described in the Simplified BSD License.

Table of Contents

   1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . .   3
   2.  Definitions . . . . . . . . . . . . . . . . . . . . . . . . .   3
   3.  The Ombudsteam  . . . . . . . . . . . . . . . . . . . . . . .   5
     3.1.  Size of the Ombudsteam  . . . . . . . . . . . . . . . . .   5
     3.2.  Appointing the Ombudsteam . . . . . . . . . . . . . . . .   5
     3.3.  Professional Advisors . . . . . . . . . . . . . . . . . .   5
     3.4.  Qualifications and Training . . . . . . . . . . . . . . .   6
     3.5.  Term of Service . . . . . . . . . . . . . . . . . . . . .   6
     3.6.  Compensation  . . . . . . . . . . . . . . . . . . . . . .   6
     3.7.  Removal . . . . . . . . . . . . . . . . . . . . . . . . .   7
     3.8.  Disputes with the IETF Chair Regarding the Ombudsteam . .   7
   4.  Handling Reports of Harassment  . . . . . . . . . . . . . . .   7
     4.1.  Ombudsteam Operating Practices  . . . . . . . . . . . . .   8
   5.  Remedies  . . . . . . . . . . . . . . . . . . . . . . . . . .  10
     5.1.  Remedies for Respondents in IETF Positions  . . . . . . .  11
     5.2.  Purpose of Remedies . . . . . . . . . . . . . . . . . . .  13
   6.  Disputes with the Ombudsteam  . . . . . . . . . . . . . . . .  14
   7.  Conflicts of Interest . . . . . . . . . . . . . . . . . . . .  15
   8.  Confidentiality . . . . . . . . . . . . . . . . . . . . . . .  15
   9.  Security Considerations . . . . . . . . . . . . . . . . . . .  16
   10. References  . . . . . . . . . . . . . . . . . . . . . . . . .  16
     10.1.  Normative References . . . . . . . . . . . . . . . . . .  16
     10.2.  Informative References . . . . . . . . . . . . . . . . .  17
   Acknowledgements  . . . . . . . . . . . . . . . . . . . . . . . .  17
   Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .  18









Resnick & Farrel          Best Current Practice                 [Page 2]
^L
RFC 7776               Anti-Harassment Procedures             March 2016


1.  Introduction

   The IETF has general policies for managing disruptive behavior in the
   context of IETF activities.  In particular, [RFC7154] provides a set
   of guidelines for personal interaction in the IETF, and [RFC2418] and
   [RFC3934] give guidelines for how to deal with disruptive behavior
   that occurs in the context of IETF working group face-to-face
   meetings and on mailing lists.

   However, there is other problematic behavior that may be more
   personal and that can occur in the context of IETF activities
   (meetings, mailing list discussions, or social events) that does not
   directly disrupt working group progress but nonetheless is
   unacceptable behavior between IETF Participants.  This sort of
   behavior, described in the IESG Statement "IETF Anti-Harassment
   Policy" [Policy], is not easily dealt with by our previously existing
   working group guidelines and procedures.  Therefore, this document
   sets forth procedures to deal with such harassing behavior.

   These procedures are intended to be used when other IETF policies and
   procedures do not apply or have been ineffective.

   Nothing in this document should be taken to interfere with the due
   process of law.  Similarly, it does not release any person from any
   contractual or corporate policies to which they may be subject.

2.  Definitions

   The following terms are used in this document:

   o  IETF Participant: Anyone who participates in an IETF activity,
      including IETF support staff.

   o  Reporter: An IETF Participant who reports potential harassment to
      an Ombudsperson.

   o  Respondent: An IETF Participant who is claimed to have engaged in
      harassing behavior.

   o  Ombudsteam: A group of people who have been selected to take
      reports of potential harassment, evaluate them, and impose
      appropriate actions and/or remedies to address the circumstances.

   o  Ombudsperson: A member of the Ombudsteam.

   o  Lead Ombudsperson: The Ombudsperson assigned to be the primary
      contact person for a particular report of potential harassment.




Resnick & Farrel          Best Current Practice                 [Page 3]
^L
RFC 7776               Anti-Harassment Procedures             March 2016


   o  Subject: An individual, group, or class of IETF Participant to
      whom the potentially harassing behavior was directed or who might
      be subject to the behavior.

   The IESG Statement on harassment [Policy] gives a general definition
   of harassment as:

      unwelcome hostile or intimidating behavior -- in particular,
      speech or behavior that is sexually aggressive or intimidates
      based on attributes such as race, gender, religion, age, color,
      national origin, ancestry, disability, sexual orientation, or
      gender identity.

   This document adopts that general definition but does not attempt to
   further precisely define behavior that falls under the set of
   procedures identified here, nor does it attempt to list every
   possible attribute that might be the basis for harassment, except to
   note that it may be targeted at an individual, directed at a specific
   group of people, or more generally impact a broader class of people.

   This document concerns itself with harassment that has the purpose or
   effect of unreasonably interfering with an individual's participation
   in IETF activities or of creating an environment within the IETF that
   would be intimidating, hostile, or offensive in such a situation.
   One way in which harassment can occur is when submission to such
   conduct is made, either explicitly or implicitly, a term or condition
   of an individual's participation in IETF activities or is used as a
   basis for decisions affecting that individual's relationship to the
   IETF.

   In general, disruptive behavior that occurs in the context of an IETF
   general or working group mailing list, or happens in a face-to-face
   or virtual meeting of a working group or the IETF plenary, can be
   dealt with by our normal procedures, whereas harassing behavior is
   more appropriately handled by the procedures described here.
   However, there are plausible reasons to address behaviors that take
   place during working group meetings using these procedures.  This
   document gives some guidance to those involved in these situations in
   order to decide how to handle particular incidents, but the final
   decision will involve judgment and the guidance of the Ombudsteam.

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








Resnick & Farrel          Best Current Practice                 [Page 4]
^L
RFC 7776               Anti-Harassment Procedures             March 2016


3.  The Ombudsteam

   This section describes the role of the Ombudsteam in terms of the
   appointment of Ombudspersons, their qualifications and training, the
   length of the term of service, any compensation from the IETF for
   their service, and how they may be removed from service.  The general
   operational procedures for the Ombudsteam are described in Sections
   4, 5, and 6.

3.1.  Size of the Ombudsteam

   The Ombudsteam shall comprise no fewer than three people.  From time
   to time, the size may fall below that number owing to changes in
   membership, but the team will be rapidly brought up to size through
   new appointments.  The team may be grown to a larger size as
   described in Section 3.2

3.2.  Appointing the Ombudsteam

   The Ombudsteam is appointed by the IETF Chair.  The appointment is
   solely the responsibility of the IETF Chair, who may choose to
   consult with members of the IETF community.

   The IETF Chair is encouraged to appoint at least some of the
   Ombudsteam from within the IETF community.

   The IETF Chair may choose to solicit nominations or advertise the
   post.  This is entirely at the discretion of the IETF Chair.

   The IETF Chair is also free to decide to appoint more than three
   Ombudspersons to the Ombudsteam.  This may depend on the skill sets
   available, the work load, and the opinions of the seated Ombudsteam.
   Furthermore, the IETF Chair may consider elements of diversity in
   making this decision.

3.3.  Professional Advisors

   It is recognized that the Ombudsteam may need to call on professional
   services from external advisors for certain matters, including legal
   and Human Resources (HR) advice.  The IETF (via the IETF
   Administrative Support Activity (IASA)) is committed to funding such
   advice as needed.









Resnick & Farrel          Best Current Practice                 [Page 5]
^L
RFC 7776               Anti-Harassment Procedures             March 2016


3.4.  Qualifications and Training

   It is not expected that there will be candidates with all of the
   necessary Ombudsperson skills and training who also have a clear
   understanding and familiarity with the IETF processes and culture.
   The Chair might choose someone with a great deal of professional
   experience evaluating and mediating harassment disputes but little
   exposure to the IETF or could select someone with more exposure to
   the IETF community but without as much experience dealing with issues
   of harassment.  Since all of these attributes may be regarded by the
   IETF Chair as essential for the team, the IETF is committed to
   providing training (or funding for it) as deemed necessary for
   appointed Ombudspersons.  In determining the appropriate training,
   the IETF Chair and Ombudsteam shall take professional advice and will
   consult with the IETF Administrative Oversight Committee (IAOC) with
   respect to the overall IETF budget.

3.5.  Term of Service

   An Ombudsperson shall be appointed for a two-year term.  That is, the
   Ombudsperson is making a commitment to serve for two years.  It is
   understood, however, that circumstances may lead an Ombudsperson to
   resign for personal or other reasons.  See also Section 3.7.

   If an Ombudsperson's term ends while they are acting as Lead
   Ombudsperson for a report as described in Section 4, that
   Ombudsperson's term shall be extended until the handling of that
   report has been completed.

   It is entirely at the discretion of the IETF Chair whether a serving
   Ombudsperson is reappointed at the end of their term.  Given the
   sensitivity of, and training required for, this role and the ideal
   being a lack of activity, it is likely the IETF Chair may choose to
   reappoint a successful and still-willing Ombudsperson for a number of
   two-year terms.

3.6.  Compensation

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

   o  IETF meeting fees

   o  Remuneration for time spent

   o  Out-of-pocket expenses (such as telephone charges)

   o  Travel or accommodation expenses



Resnick & Farrel          Best Current Practice                 [Page 6]
^L
RFC 7776               Anti-Harassment Procedures             March 2016


   The IETF will, however, meet the costs of training when agreed to by
   the IETF Chair as described in Section 3.4.

3.7.  Removal

   The IETF Chair may remove a serving Ombudsperson before the end of
   their term without explanation to the community, including during the
   course of processing an active case.  Such an action shall be
   appealable as described in Section 3.8.

   An Ombudsperson shall not be removed from service, even if their term
   has expired, during the period that the IETF Chair is recused as
   described in Section 7.  Once the case that led to the Chair being
   recused has been closed, normal processes resume.

3.8.  Disputes with the IETF Chair Regarding the Ombudsteam

   If an individual should disagree with an action taken by the IETF
   Chair regarding the appointment, removal, or management of an
   Ombudsperson or the Ombudsteam, that person should first discuss the
   issue with the IETF Chair directly.  If the IETF Chair is unable to
   resolve the issue, the dissatisfied party may appeal to the IESG as a
   whole.  The IESG shall then review the situation and attempt to
   resolve it in a manner of its own choosing.  The procedures of
   Section 6.5.4 of [RFC2026] apply to this sort of appeal.

4.  Handling Reports of Harassment

   Any IETF Participant who believes that they have been harassed, or
   that any other IETF Participant or group of IETF Participants has
   been or may have been harassed, should bring the concern to the
   attention of any serving Ombudsperson.  This can be done by email to
   ombuds@ietf.org or can be done directly to a chosen Ombudsperson.
   Direct contact information for the members of the Ombudsteam,
   including the email addresses to which mail to ombuds@ietf.org is
   forwarded, can be found at <https://www.ietf.org/ombudsteam>
   [OmbudsteamPages].

   All IETF Participants are encouraged to talk with the Ombudsteam if
   they are uncomfortable or unsure about any behaviors.  Though much of
   this document relates to the formal duties of the Ombudsteam, it
   should be understood that an important function of the Ombudsteam is
   to provide confidential advice and counsel for any IETF Participant
   regarding issues of harassment.  The Ombudsteam will not commence a
   formal investigation of any potential incident of harassment without
   agreement by the Reporter and Subject.





Resnick & Farrel          Best Current Practice                 [Page 7]
^L
RFC 7776               Anti-Harassment Procedures             March 2016


   When a Reporter brings an incident of potential harassment to the
   attention of the Ombudsteam, a single Ombudsperson shall be
   designated as the primary contact person (the Lead Ombudsperson) for
   the report.  When the Reporter contacts a single Ombudsperson, that
   Ombudsperson shall be the Lead Ombudsperson for the report unless the
   Reporter and Ombudsperson mutually agree to select another Lead
   Ombudsperson.

   Information conveyed by the Reporter should be kept in confidence by
   the Lead Ombudsperson to the greatest extent possible.  When
   necessary (for example, in the course of a formal investigation), the
   Lead Ombudsperson may share information regarding the report with the
   rest of the Ombudsteam except when an Ombudsperson is recused (see
   Section 7).  If a Reporter believes that a member of the Ombudsteam
   should recuse themself, the Reporter should make this known to the
   Lead Ombudsperson as soon as possible.  See Section 4.1 for further
   discussion of the confidentiality requirements of the Ombudsteam.

   The Lead Ombudsperson will discuss the events with the Reporter and
   may give advice, including recommendations on how the Reporter can
   handle the issue on their own as well as strategies on how to prevent
   the issue from arising again.  The Lead Ombudsperson may also
   indicate that the issue would be best handled using regular IETF
   procedures (such as those for dealing with disruptive behavior)
   outside the context of harassment, and in this case, the Lead
   Ombudsperson will provide assistance in using the relevant IETF
   procedures.  Otherwise, with agreement to proceed from the Subject
   (or the Reporter if there is no individual Subject), the Ombudsteam
   may initiate a detailed investigation of the matter and may
   subsequently, after completing their investigation, impose a remedy
   as described in Section 5.  The Subject can withdraw their agreement
   to proceed at any time.

4.1.  Ombudsteam Operating Practices

   The Ombudsteam is responsible for devising and documenting their
   operating practices.  These practices must be discussed with the IESG
   and published in a publicly visible place (such as on the IETF web
   site).  Discussion with the IETF community is encouraged and, while
   IETF consensus is not necessary, significant objections to the
   processes that are not addressed should result in an appeal per
   Section 6.5.3 of [RFC2026] and/or a recall petition against the IETF
   Chair (and any of the rest of the IESG if appropriate) if they do not
   address the concern.







Resnick & Farrel          Best Current Practice                 [Page 8]
^L
RFC 7776               Anti-Harassment Procedures             March 2016


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

   o  Each member of the Ombudsteam is expected to be present at the
      majority of IETF meetings and to be available for face-to-face
      discussions.  The Ombudsteam is expected to arrange itself so that
      there is coverage of every IETF meeting by at least one
      Ombudsperson.

   o  The Ombudsteam shall strive to keep all information brought to it
      in strict confidence.  However, it is acknowledged that the
      operation of the Ombudsteam may involve sharing of information
      within the team and may require that the parties to the complaint
      (the Reporter, Respondent, and Subject) learn some of the
      confidential information.  The Ombudsteam is responsible for
      documenting its expectations of when disclosures of confidential
      information are likely to be made in the process and to whom.  Any
      electronic information (such as email messages) that needs to be
      archived shall be encrypted before it is stored using tools
      similar to those used by the Nominating Committee (NomCom).

   o  When conducting a detailed investigation of the circumstances
      regarding the complaint of harassment, the Ombudsteam may contact
      the Respondent and request a meeting in person or by a voice call.
      The Ombudsteam shall have contacted the Respondent and either
      discussed the matter or ascertained the Respondent's unwillingness
      to cooperate prior to deciding to impose a remedy as described in
      Section 5.  The Respondent is not obliged to cooperate, but the
      Ombudsteam may consider failure to cooperate when determining a
      remedy (Section 5).

   o  The Ombudsteam shall endeavor to complete its investigation in a
      timely manner.

   o  Any individuals who make a good faith report of harassment or who
      cooperate with an investigation shall not be subject to
      retaliation for reporting, complaining, or cooperating, even if
      the investigation, once completed, shows no harassment occurred.
      Anti-retaliation is noted here to alleviate concerns individuals
      may have with reporting an incident they feel should be reviewed
      or cooperating with an investigation.

   o  In all cases, the Ombudsteam will strive to maintain
      confidentiality for all parties, including the very fact of
      contact with the Ombudsteam.






Resnick & Farrel          Best Current Practice                 [Page 9]
^L
RFC 7776               Anti-Harassment Procedures             March 2016


   o  The results of investigations as reported to the Subject or
      Respondent and all requests for remedial action (such as to the
      IETF Secretariat) shall be in writing.

   o  The Ombudsteam shall keep written records of their investigation
      and any contacts or interviews such that there is material
      available in the event of an appeal or legal action.  Such records
      shall be held securely and in confidence.

   When investigating reports of harassment and determining remedies, it
   is up to the Ombudsteam whether they choose to act as a body or
   delegate duties to the Lead Ombudsperson.

5.  Remedies

   After examining the circumstances regarding the complaint of
   harassment, the Ombudsteam should prepare a brief summary of the
   incident and their conclusions and discuss this with all parties.
   The objective of this step is to make clear what the Ombudsteam has
   concluded and to make an attempt at getting all parties to reach
   agreement.

   If the Ombudsteam determines that harassment has taken place, the
   Ombudsteam is expected to determine the next action.

   o  In some cases, a mechanism or established IETF process may already
      exist for handling the specific event.  In these cases, the
      Ombudsteam may decide that the misbehavior is best handled with
      the regular IETF procedures for dealing with disruptive behavior
      and may assist the Reporter to bring the issue to the attention of
      the WG Chair or IESG member who can deal with the incident.

   o  In other cases, there is a spectrum of remedies that may be
      appropriate to the circumstances.  At one end of the spectrum, the
      Ombudsteam might choose to discuss the situation with the
      Respondent and come up with a plan such that there is no repeat of
      the harassment.  With the agreement of both parties, the
      Ombudsteam can also help to mediate a conversation between the
      Respondent and the Subject (or the Reporter if there is no
      individual Subject) in order to address the issue.  If mediation
      fails, then the Ombudsteam can decide to apply other remedies,
      including those discussed here.

   o  At the other end of the spectrum, the Ombudsteam could decide that
      the Respondent is no longer permitted to participate in a
      particular IETF activity, for example, ejecting them from a
      meeting or requiring that the Respondent can no longer attend
      future meetings to ensure that the reported harassment cannot



Resnick & Farrel          Best Current Practice                [Page 10]
^L
RFC 7776               Anti-Harassment Procedures             March 2016


      continue or escalate.  If the Respondent holds a management
      position in the IETF, the remedies imposed may make it difficult
      or impossible for them to perform the duties required of that
      position.  Further remedies may be applied to Respondents in IETF
      management positions as described in Section 5.1.

   o  In determining the appropriate remedy, the Ombudsteam may
      communicate with the Reporter, Subject, or Respondent in order to
      assess the impact that the imposition of a remedy might have on
      any of those parties.  However, the Ombudsteam has ultimate
      responsibility for the choice of remedy.

   o  In all cases, the Lead Ombudsperson informs the Respondent of the
      decision and imposes the remedy as appropriate.  In cases where
      the remedy is removal from IETF activities, the Lead Ombudsperson
      will confidentially notify the Secretariat in writing of the
      remedy such that the Secretariat can take whatever logistical
      actions are required to effect the remedy.  Only the remedy itself
      shall be disclosed to the Secretariat, not any information
      regarding the nature of the harassment.

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

5.1.  Remedies for Respondents in IETF Positions

   The remedies discussed earlier in this section are equally applicable
   to all IETF Participants regardless of role.

   The Ombudsteam will want to be aware of the impact of remedies on the
   ability of an individual to carry out their duties in IETF management
   positions, but this should not dissuade the Ombudsteam from applying
   remedies that they deem appropriate.  Per Section 5, the Ombudsteam
   is expected to apply proportionality and reasonableness, as well as
   to consider the impact of the remedy on the Respondent.  Per
   Section 4.1, the Ombudsteam may communicate with the Respondent in
   order to assess the impact that the remedy might have.

   There may be cases where the Ombudsteam considers that it is
   inappropriate for a Respondent to continue in their IETF management
   position, that is, where the desired remedy is to remove the
   Respondent from their management position.  The Ombudsteam cannot by
   itself remove a Respondent who is in an IETF management position from
   that position.  However, the Ombudsteam can recommend the use of
   existing mechanisms within the IETF process for the removal of people
   from IETF management positions as follows:



Resnick & Farrel          Best Current Practice                [Page 11]
^L
RFC 7776               Anti-Harassment Procedures             March 2016


   o  Many IETF management positions are appointed by the NomCom with
      confirmation from the IESG, IAB, or ISOC.  [RFC7437] describes the
      recall procedure for such appointments.  This document updates
      [RFC7437] by allowing the Ombudsteam to form a recall petition on
      its own and without requiring 20 signatories from the community.
      Such a petition shall be treated in all ways like any other recall
      petition as described in [RFC7437]: that is, the fact of the
      petition and its signatories (the Ombudsteam) shall be announced
      to the IETF community, and a Recall Committee Chair shall be
      appointed to complete the Recall Committee process.  It is
      expected that the Recall Committee will receive a briefing from
      the Ombudsteam explaining why recall is considered an appropriate
      remedy.

   o  Other IETF management positions are filled by appointment of the
      IESG, the IAB, the ISOC Board, or the ISOC President.  In such
      cases, the Ombudsteam may recommend to the appointing body that
      the Respondent be removed from their position.

   o  Many IETF management positions are filled through appointment by
      an AD or by the ADs for an IETF Area.  In such cases, the
      Ombudsteam may recommend to those ADs in writing that the
      Respondent be removed from their position.

   o  Some other IETF management positions are filled through
      appointment by WG Chairs.  In such cases, the Ombudsteam may make
      a recommendation in writing to the responsible AD (that is, not
      directly to the WG Chairs) that the Respondent be removed from
      their position.

   In each of the cases listed here, it is expected that the person or
   body responsible for removing someone from an IETF management
   position will take a recommendation from the Ombudsteam extremely
   seriously and that it would be very unusual for them to not act on
   the recommendation.  It is not the intent that the person or body
   attempt to reinvestigate the circumstances of the harassment.  They
   are expected to understand that they are not qualified in evaluating
   or handling issues of harassment.  They must seek to preserve
   confidentiality.  If the person or body feels removal from position
   is not the correct remedy, they must discuss their concern with the
   Ombudsteam.

   In the event that an AD declines to follow the recommendation of the
   Ombudsteam, and if the AD fails to convince the Ombudsteam of the
   reasons for this, the Ombudsteam should raise the issue with the
   whole IESG while continuing to attempt to retain confidentiality.
   The IESG may choose to reorganize the responsibilities for working




Resnick & Farrel          Best Current Practice                [Page 12]
^L
RFC 7776               Anti-Harassment Procedures             March 2016


   groups within its own structure so that the AD concerned is no longer
   in the direct management path.

   All such forced removals from management positions must be considered
   by the Ombudsteam as acts of last resort.  That is, before a
   Respondent is recommended for removal, the Ombudsteam should consider
   other possible remedies and should discuss the situation with the
   Respondent, giving them ample opportunity to understand what might
   happen and to step down of their own volition.

   As described in Section 4.1, the Ombudsteam is required to maintain
   the highest degree of confidentiality.  In recommending action as
   described above, the Ombudsteam will clearly have to indicate that
   some event has occurred that led to their recommendation, but it is
   not expected that the Ombudsteam will need to divulge substantially
   more information.  It should be enough that the Ombudsteam explains
   the severity of the situation, that they have considered other lesser
   remedies, and that they deem the recommended remedy to be
   appropriate.

   In removing someone from their position, it may become apparent to
   the IETF community that the removal is a remedy recommended by the
   Ombudsteam.  However, revealing the underlying events should be
   avoided as far as possible.

5.2.  Purpose of Remedies

   The purpose of the anti-harassment policy is to prevent all incidents
   of harassment in the IETF.  The set of procedures documented here
   serves to provide a mechanism whereby any harassment that occurs can
   be reported and handled both sympathetically and effectively.  The
   policy also sends a clear message that the IETF does not tolerate
   harassment in any form.

   However, any remedy is imposed to try to make sure that the incident
   does not escalate and to ensure that a similar situation is unlikely
   to occur with the same Respondent in the future.

   Because the handling of incidents of harassment (including the
   imposition of remedies) is confidential, an imposed remedy cannot
   itself serve as a deterrent to others, nor can it be used to "teach"
   the community how to behave.  ([RFC7154] gives guidelines for conduct
   in the IETF.)  Furthermore, a remedy is not to be imposed for the
   purposes of retribution.  However, the knowledge of the existence of
   a range of remedies and of processes by which they can be applied
   serves both as a statement of the IETF's seriousness in this matter
   and as a deterrent to potential offenders.




Resnick & Farrel          Best Current Practice                [Page 13]
^L
RFC 7776               Anti-Harassment Procedures             March 2016


   The Ombudsteam is expected to apply the above considerations, as well
   as proportionality and reasonableness, in selecting a remedy.  They
   are asked to consider the impact of the remedy on the Respondent as
   well as on the Subject.

6.  Disputes with the Ombudsteam

   If either the Subject (or the Reporter if there is no individual
   Subject) or the Respondent is dissatisfied with the decision of the
   Ombudsteam, the dissatisfied party should first contact the Lead
   Ombudsperson and discuss the situation.  If the issue cannot be
   resolved through discussion with the Lead Ombudsperson, the issue may
   be raised with the IETF Chair.

   If necessary, the IETF Chair may recuse themself from any part of
   this process (see Section 7) and request the IESG to select another
   of its members to serve in this role.  This IESG member is known as
   the "delegated IESG member".

   The IETF Chair (or the delegated IESG member if the Chair is recused)
   will attempt to resolve the issue in discussion with the dissatisfied
   party and the Lead Ombudsperson.  If this further discussion does not
   bring a satisfactory resolution, the Ombudsteam's decision may be
   formally appealed.  The appeal is strictly on the issue of whether
   the Ombudsteam exercised due diligence both in their decision as to
   whether harassment had taken place as well as in their determination
   of any appropriate remedy that was imposed.  In particular, the
   purpose of the appeal is not to re-investigate the circumstances of
   the incident or to negotiate the severity of the remedy.

   All elements of the appeal, including the fact of the appeal, will be
   held in confidence but will be recorded and held securely for future
   reference.

   The appeal will be evaluated by the IETF Chair (or the delegated IESG
   member) and two other members of the IESG selected by the IETF Chair
   (or the delegated IESG member) and confirmed by the appellant.  This
   Appeals Group shall convene as quickly as possible to evaluate and
   determine the appeal.  Where the impacts are immediate and related to
   participation in an ongoing meeting, this shall happen in no more
   than 24 hours after receiving the appeal.  The Appeals Group may ask
   the appellant and the Lead Ombudsperson for statements or other
   information to consider.  If the Appeals Group concludes that due
   diligence was exercised by the Ombudsteam, this shall be reported to
   the appellant, and the matter is concluded.  If the Appeals Group
   finds that due diligence was not exercised, the Appeals Group shall
   report this to the Ombudsteam and consult with the Ombudsteam on how
   to complete the due diligence.



Resnick & Farrel          Best Current Practice                [Page 14]
^L
RFC 7776               Anti-Harassment Procedures             March 2016


   Because of the need to keep the information regarding these matters
   as confidential as possible, the Appeals Group's decision is final
   with respect to the question of whether the Ombudsteam has used due
   diligence in their decision.  The only further recourse available is
   to claim that the procedures themselves (i.e., the procedures
   described in this document) are inadequate or insufficient to the
   protection of the rights of all parties.  Such a claim may be made in
   an appeal to the Internet Society Board of Trustees, as described in
   Section 6.5.3 of [RFC2026].  Again, even in this circumstance, the
   particulars of the incident at hand will be held in confidence.

7.  Conflicts of Interest

   In the event of any conflict of interest, the conflicted person
   (member of the Ombudsteam, member of the Appeals Group, IETF Chair,
   etc.) is expected to recuse themselves.

   A conflict of interest may arise if someone involved in the process
   of handling a harassment report is in the role of Reporter,
   Respondent, or Subject.  Furthermore, a conflict of interest arises
   if the person involved in the process of handling a harassment report
   is closely associated personally or through affiliation with any of
   the Reporter, Respondent, or Subject.

   For the avoidance of doubt, recusal in this context means completely
   stepping out of any advisory or decision-making part of any process
   associated with handling a harassment report, remedy arising from a
   harassment report, or appeal into the handling of a harassment
   report.  That means that a recused person has no more right to
   participate in or witness the process than any other person from the
   community in the same situation.  For example, an Ombudsperson
   subject to a complaint of harassment shall not be privy to the
   deliberations of another Ombudsperson handling the report.  Nor would
   an IESG member who was party to an appeal be able to witness the
   discussions of the Appeals Group.

   In the event that there is an appeal and the IETF Chair is somehow
   involved, the Chair will immediately recuse themself, and the IESG
   will select a single person to take the Chair's role in the appeal
   process as described in Section 6.

8.  Confidentiality

   Throughout this document, there are mentions of requirements to keep
   information confidential.  This section summarizes those requirements
   for clarity.





Resnick & Farrel          Best Current Practice                [Page 15]
^L
RFC 7776               Anti-Harassment Procedures             March 2016


   The Ombudsteam is expected to strive for confidentiality.
   Confidentiality protects the Reporter, Subject, and Respondent in any
   case of alleged harassment.  It also protects witnesses or others
   consulted by the Ombudsteam during their investigation.

   The Ombudsteam will keep its email and other archival records in a
   secure system and will not discuss details of any case beyond what is
   necessary for executing a thorough investigation.

   Third-party receivers of output from the Ombudsteam (for example, ADs
   or the IETF Secretariat who are asked to take action) are required to
   keep such output confidential.

   Participants in an investigation (Reporters, Subjects, Respondents,
   and anyone interviewed by the Ombudsteam during an investigation) are
   requested to keep the details of the events and investigation
   confidential.

   It is likely that members of the community will want to know more
   when they have become aware of some details of a case of harassment.
   The community is asked to show restraint and to trust the Ombudsteam.
   This process is designed to provide remedies not punishment, as
   described in Section 5.2, and public discussion of the events or
   remedies does not form part of this process.

9.  Security Considerations

   "Human beings the world over need freedom and security that they may
   be able to realize their full potential." -- Aung San Suu Kyi

10.  References

10.1.  Normative References

   [RFC2026]  Bradner, S., "The Internet Standards Process -- Revision
              3", BCP 9, RFC 2026, DOI 10.17487/RFC2026, October 1996,
              <http://www.rfc-editor.org/info/rfc2026>.

   [RFC2418]  Bradner, S., "IETF Working Group Guidelines and
              Procedures", BCP 25, RFC 2418, DOI 10.17487/RFC2418,
              September 1998, <http://www.rfc-editor.org/info/rfc2418>.

   [RFC3934]  Wasserman, M., "Updates to RFC 2418 Regarding the
              Management of IETF Mailing Lists", BCP 25, RFC 3934,
              DOI 10.17487/RFC3934, October 2004,
              <http://www.rfc-editor.org/info/rfc3934>.





Resnick & Farrel          Best Current Practice                [Page 16]
^L
RFC 7776               Anti-Harassment Procedures             March 2016


   [RFC7154]  Moonesamy, S., Ed., "IETF Guidelines for Conduct", BCP 54,
              RFC 7154, DOI 10.17487/RFC7154, March 2014,
              <http://www.rfc-editor.org/info/rfc7154>.

   [RFC7437]  Kucherawy, M., Ed., "IAB, IESG, and IAOC Selection,
              Confirmation, and Recall Process: Operation of the
              Nominating and Recall Committees", BCP 10, RFC 7437,
              DOI 10.17487/RFC7437, January 2015,
              <http://www.rfc-editor.org/info/rfc7437>.

10.2.  Informative References

   [OmbudsteamPages]
              IESG, "Reporting Potential Harassment",
              <https://www.ietf.org/ombudsteam>.

   [Policy]   IESG, "IETF Anti-Harassment Policy",
              <https://www.ietf.org/iesg/statement/
              ietf-anti-harassment-policy.html>.

Acknowledgements

   The text in this document benefited from the lively discussion on the
   ietf@ietf.org mailing list.  Thanks to everyone who participated.

   Specific changes to this document resulted from comments by
   Abdussalam Baryun, Alessandro Vesely, S. Moonesamy, Timothy
   B. Terriberry, John Levine, Andrea Glorioso, Dave Crocker, John
   Leslie, Linda Klieforth, Brian Carpenter, Mary Barnes, Richard
   Barnes, Spencer Dawkins, Michael StJohns, Alissa Cooper, James
   Woodyatt, Tom Taylor, Sam Hartman, Stewart Bryant, Stephen Farrell,
   Nico Williams, Mark Nottingham, and Jari Arkko.  The authors would
   like to express their gratitude.

   A design team comprising Linda Klieforth, Allison Mankin, Suresh
   Krishnan, Pete Resnick, and Adrian Farrel was convened by the IETF
   Chair (Jari Arkko) to address the issue of "Remedies for Respondents
   in IETF Positions" and the text in Section 5.1.

   The authors would like to thank Ines Robles for diligent shepherding
   of this document and for tracking the many issues raised in and after
   IETF last call.

   Thanks to Greg Kapfer at ISOC, Ray Pelletier (the IAD), Scott Bradner
   and Lou Berger on the IAOC, and Scott Young and David Wilson of
   Thompson Hine for considering the legal and insurance implications.





Resnick & Farrel          Best Current Practice                [Page 17]
^L
RFC 7776               Anti-Harassment Procedures             March 2016


Authors' Addresses

   Pete Resnick
   Qualcomm Technologies, Inc.
   5775 Morehouse Drive
   San Diego, CA  92121
   United States

   Phone: +1 858 651 4478
   Email: presnick@qti.qualcomm.com


   Adrian Farrel
   Juniper Networks

   Email: adrian@olddog.co.uk



































Resnick & Farrel          Best Current Practice                [Page 18]
^L