Review of: draft-farrresnickel-harassment-06

Dave Crocker <dhc@dcrocker.net> Wed, 11 March 2015 17:08 UTC

Return-Path: <dhc@dcrocker.net>
X-Original-To: ietf@ietfa.amsl.com
Delivered-To: ietf@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 686F81A0451 for <ietf@ietfa.amsl.com>; Wed, 11 Mar 2015 10:08:38 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.157
X-Spam-Level:
X-Spam-Status: No, score=-0.157 tagged_above=-999 required=5 tests=[BAYES_50=0.8, FILL_THIS_FORM_FRAUD_PHISH=0.334, FORM_FRAUD=0.999, RCVD_IN_DNSWL_MED=-2.3, T_FILL_THIS_FORM_SHORT=0.01] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Y6heGOgpRvJ5 for <ietf@ietfa.amsl.com>; Wed, 11 Mar 2015 10:08:32 -0700 (PDT)
Received: from sbh17.songbird.com (sbh17.songbird.com [72.52.113.17]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6EEF11A0404 for <ietf@ietf.org>; Wed, 11 Mar 2015 10:08:32 -0700 (PDT)
Received: from [192.168.1.87] (76-218-8-156.lightspeed.sntcca.sbcglobal.net [76.218.8.156]) (authenticated bits=0) by sbh17.songbird.com (8.13.8/8.13.8) with ESMTP id t2BH8STW020946 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Wed, 11 Mar 2015 10:08:31 -0700
Message-ID: <5500768B.1000302@dcrocker.net>
Date: Wed, 11 Mar 2015 10:08:27 -0700
From: Dave Crocker <dhc@dcrocker.net>
Organization: Brandenburg InternetWorking
User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.5.0
MIME-Version: 1.0
To: draft-farrresnickel-harassment@tools.ietf.org
Subject: Review of: draft-farrresnickel-harassment-06
Content-Type: text/plain; charset="windows-1252"
Content-Transfer-Encoding: 8bit
X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.0 (sbh17.songbird.com [72.52.113.66]); Wed, 11 Mar 2015 10:08:32 -0700 (PDT)
Archived-At: <http://mailarchive.ietf.org/arch/msg/ietf/dsatIHgoqnApa6wixOj9AdEBKu0>
Cc: IETF Discussion <ietf@ietf.org>
X-BeenThere: ietf@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
Reply-To: dcrocker@bbiw.net
List-Id: IETF-Discussion <ietf.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/ietf>, <mailto:ietf-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/ietf/>
List-Post: <mailto:ietf@ietf.org>
List-Help: <mailto:ietf-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ietf>, <mailto:ietf-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 11 Mar 2015 17:08:38 -0000

Summary:

This documents defines harassment and establishes IETF policies and
practices regarding it.  It is an essential effort.

   1.  The document's language appears to repeatedly confuse harassment
actions with other forms of interpersonal difficulties.  It needs to
draw a bright line about the handling of harassment, versus complaints
of harassment deemed to be something else.

       All discussion of harassment, itself, needs to invoke a
perspective that it is a unilateral -- not bilateral -- action.  That is
harassment is essentially an offense against the community.  The Subject
is in no way a contributor to the problem nor, really, a contributor to
its remedy.  Given them a voice about the remedy is different from
holding them responsible for negotiating it or otherwise being treated
as any part of the cause.

   2.  The document constrains itself to classic, formal harassment.
That is, actions against protected classes.  It should expand its scope
to cover other forms of unilateral attack, often called bullying.  The
view that the IETF already has policies and procedures against such
behavior is objectively incorrect.  Further, the IETF has no pattern of
practice against such behavior.  Quite the contrary.  Worse, an
environment that tolerates -- or even promotes -- such behaviors lays a
foundation for the offense of harassment.

   3.  The mechanisms for choosing and training the Ombudteam and for
handling appeals should be considered and explained more carefully.  The
current text appears to have significant problems about these topics.



Detailed Comments:


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

Although this document does not assert use of the IETF's normative terms
(RFC 2119), it should refrain from using the reserved words.  Those
words are so thoroughly ingrained in IETF culture and conversation,
non-normative use of them invites confusion.  Note the nicely-convenient
suggestions in:

     https://tools.ietf.org/html/draft-hansen-nonkeywords-non2119-02

However, given that the document really does make normative assertions,
it ought to use the vocabulary common to the IETF for this.


In any event, I suggest an even more forceful and active-voiced opening
sentence:

     The IETF does not tolerate harassment at IETF meetings, virtual
meetings, social events, or on mailing lists.  This document defines
harassment and lays out procedures for managing and enforcing this policy.


> 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, often more interpersonal, 
> behavior 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

Long, somewhat awkward sentence.  Shorter and simpler is better:

   However in the context of IETF activities (meetings, mailing list
discussions, or social events) there is other problematic behavior,
which is often more personal. Even if it does not directly disrupt working
group progress, it is nonetheless unacceptable behavior among IETF
Participants.


> in the IESG Statement on an "IETF Anti-Harassment Policy" [1], is
> not

Folks, as a consensus document of this type, the core of the topic needs
to be fully contained in this document and not rely on definition or other
specification from another IETF group, such as the IESG. If it needs to
draw from an external document, then it should be one from experts, such
as Stewart Bryant suggests.

However since this is a normative specification it ought to include the
definitional text directly, even if it cites an expert definition.
.
The IESG does not define harassment.

Worse, with this document's use of a citation through a URL to a web
page, the IESG could choose to change the definition whenever it wants.

For a consensus document like this, the community MUST be the authority
on definition of harassment or else its adoption of a standard, legal
definition.



As for the definition in the IESG page:

      Harassment is 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.

The language here covers classic protected classes, but not other forms
of personally hostile behavior that serves to intimidate or coerce other
participants, as outlined in Section 2.2 of:

     https://tools.ietf.org/html/draft-crocker-diversity-conduct-02

In a culture with a very long history of actively tolerating and
occasionally encouraging personally offensive behavior and, worse,
behavior designed to intimidate participants -- and especially an
organization
with such a poor track-record for holding accountable those who
indulge in such behaviors -- the exclusion of this larger class of crippling
behaviors means that we are essentially addressing only symptoms and not
a root problem.

In practical terms an environment that ignores ingrained patterns of
intimidation behavior can do little of significance about behaviors
against identified classes.

Lest there by any misunderstanding of the above:  hostile actions
against protected classes have to be stopped; but so do patterns of
hostile actions
against others.  A culture that persists with the latter maintains a
foundation that breeds the former.


> easily dealt with by our previously existing working group
> guidelines

To anticipate a rejoinder to my pressing for a broader scope:  Nothing
in our current documents or practices easily deals with bullying, either.



> 2. Definitions
> 
> 
> The following terms are used in this document:
...
> The IESG statement on harassment [2] gives a general definition of 
> harassment as "unwelcome hostile or intimidating behavior -- in 
> particular speech and behavior that is sexually aggressive or 
> intimidates based on attributes like race, gender, religion, age, 
> color, national origin, ancestry, disability, sexual orientation, or 
> gender identity."  This document adopts that general definition, but

Follow the definitions format for the term.  Just provide a definition
and/or cite an expert definition.

 It is not necessary to cite the IESG effort at all.  It's actually
distracting to cite it.


> 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.  In general, disruptive behavior that occurs
> in the context of an IETF general or working group mailing list, or
> happens
> 
> 
> 
> Resnick & Farrel        Expires September 6, 2015               [Page
> 3]
> 
> 
> Internet-Draft         Anti-Harassment Procedures             March
> 2015
> 
> 
> 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

As worded, this creates an anomaly that probably isn't intended. The
focus on 'disruptive' ignores bullying behavior, if it doesn't happen to
be perceived as disruptive. So intimidation that doesn't invoke a
protected class is OK, as long as it doesn't bother anyone but the Subject?


> harassing behavior that is interpersonal 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.

What does that sentence mean?


> 
> 3. The Ombudsteam

The document should first state what an Ombudsteam is, in terms of
responsibilities and authorities.  The mechanics are important, but less so.


> 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 recompense for their service, and 
> how they may be removed from service.  The general operational 
> procedures for the Ombudsteam are described in Section 4, Section 5, 
> and Section 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

may -> might


> 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.

Since there are multiple members, I suggest appointing through multiple
sources, to get a degree of heterogeneity of organizational affiliations
and accountabilities.




> 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 IAOC with respect to the overall IETF budget.

As phrased, this defers the question of training.

The nature of this work is far outside the experience base of typical
IETF participants.  (Not all, of course, but many and probably most and
maybe nearly all.)  Good intentions and a logical mind are not enough,
nor is basic management training.  This topic is a difficult specialty.

Relying on spontaneous, real-time training, by random members of other
members, when there is a complaint to handle, creates a process that is
far too ad hoc for something this sensitive and this important.

So I strongly suggest mandating some basic, appropriate professional
training for anyone placed on the team who is not certified or extremely
experienced with this sort of work.

Again: having taken a management course or having supervised some folk
is not enough; this is a specialty, even within Human Resources and it
is common for this topic to be handled quite badly, even by HR folk.  As
an example, it is common to try to treat this as a disagreement or
misunderstanding between equals, rather than as a direct and often
illegal act of aggression by one against another.



> 3.6. Recompense
> 
> 
> An Ombudsperson shall receive no recompense for their services.
> This includes, but is not limited to:
...
> o  Travel or accommodation expenses
> 
> The IETF will, however, meet the costs of training when agreed to by 
> the IETF Chair as described in Section 3.4.

Given possible, additional (and spontaneous) travel for ad hoc meetings,
This effectively excludes all but the most well-funded participants.



> 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.

Why no appeal sequence above that?

The IETF Chair and the IESG form a collaborative unit.  While the IESG
is certainly capable of deciding against the Chair, its direct and
on-going affiliation with the Chair creates a degree of conflict of
interest.

It's probably OK to leave the IESG in the appeal chain, but it seems
problematic for it to be the only recourse.


> 
> 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, may bring the concern to the 
> attention of any serving Ombudsperson.  This can be done by email to 
> "ombudsteam@ietf.org" [3], or can be done directly to a chosen 
> Ombudsperson.  Direct contact information for the Ombudsteam, 
> including the email addresses to which "ombudsteam@ietf.org" is 
> forwarded, can be found at https://www.ietf.org/ombudsteam .
> 
> When a Reporter brings an incident of potential harassment to the

  potential -> existing or potential


> attention of the Ombudsteam, a single Ombudsperson shall be

So, the use of 'shall' sounds normative...


> 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 
> mutually agreed between the Reporter and that Ombudsperson.
> 
> 
> 
> Resnick & Farrel        Expires September 6, 2015               [Page
> 6]
> 
> 
> Internet-Draft         Anti-Harassment Procedures             March
> 2015
> 
> 
> The Lead Ombudsperson may share any information regarding the report

Is 'may' meant to be normative?

(Yes this is pedantic, but again, we have established practice in the
IETF for normative language.  Is there a reason to ignore it?)


> 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, they should make this known to
> the Lead Ombudsperson as soon as possible.

Seems like the need for recusal is independent of whether the person
chooses to do it themself.  That's merely one path towards recusal.

Instead:

   should recuse themself, -> should be recused,

Recusal also probably should be discussed in its own subsection, rather
than as a side comment in the sub-section on reporting harassment.


> 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

Handle the issue on their own?  Really?  Harassment?

This line of thinking is entirely inappropriate.

It is like saying that when someone reports that they've been beaten up
the police may give advice including recommendations on how the
complainant can handle the issue on their own.

My guess is that there is confusion between 'harassment' and
'disagreement' or confusing between a complaint of harassment that is
legitimate, versus one that is not.

That is, an essential part of processing a complaint of harassment is to
determine whether harassment occurred.  If it is determined not to have
been harassment, it's possible that the complainant can and should
pursue other avenues on their own.

If, however, harassment has taken place, it is probably illegal in many
jurisdictions to counsel that they handle it on their own.  In any
event, it is entirely inappropriate.  In fact, it essentially repeats
the harassment, by providing explicit institutional failure to deal with it.


> 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

If you mean that this isn't harassment and therefore needs to be handled
in some other fashion then say so explicitly, including the the basis
for that assessment.


> procedures.  Otherwise, with agreement to proceed from the Subject 
> (or the Reporter if there is no individual Subject), the Ombudsteam 
> may initiate detailed investigation of the matter, and may 
> subsequently impose a remedy as described in Section 5.
> 
> 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 objection to the 
> processes that are not addressed should result in an [RFC2026] 
> Section 6.5.3 appeal and/or a recall petition against the IETF Chair 
> (and the rest of the IESG if appropriate) if they do not address the 
> concern.

The 'should' here is odd.  I believe the intent is to declare that
appeal is permitted according to RFC 2026.

It's possible that there is (also?) an intent to impose on the IESG a
requirement that it attend to 'significant objection' in a responsive
manner?  That certainly would be reasonable to have in this document.


> The practices must include at least the following high-level 
> components:
> 
> 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.

Coverage?

Perhaps what is meant is that there must be at least one Ombudsperson at
every IETF meeting, in person, to be available for hearing reports and
that the community must be informed of who is available and how to
contact them?


> All information brought to the Ombudsteam shall be kept in strict 
> confidence.  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 NomCom.

Is that sufficient protection?  Consider who can see NomCom messages.
Is similar exposure for this information acceptable?


> 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.

" and request a meeting in person or by a voice call." seems like
unnecessary detail.


> 
> Resnick & Farrel        Expires September 6, 2015               [Page
> 7]
> 
> 
> Internet-Draft         Anti-Harassment Procedures             March
> 2015
> 
> 
> The Respondent is not obliged to cooperate, but the Ombudsteam may 
> consider failure to cooperate when determining a remedy (Section 5).
> 
> The Ombudsteam shall endeavor to complete its investigation in a 
> timely manner.
> 
> 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.

Is retaliation acceptable when the report was not in good faith?  Is it
acceptable when they do not cooperate?

(Yes, I mean the question seriously, given how the draft has been worded.)


> Anti-retaliation is noted here to alleviate concerns individuals may
> have with reference to reporting an incident they feel should be
> reviewed or cooperating with an investigation.
> 
> In all cases the Ombudsteam will strive to maintain confidentiality
> for all parties including the very fact of contact with the
> Ombudsteam.
> 
> 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
...
> If the Ombudsteam determines that harassment has taken place, the 
> Ombudsteam is expected to determine the next action.
> 
> In some cases a mechanism or established IETF process may already 
> exist for handling the specific event.

Huh??  For harassment???


> In these cases the Ombudsteam may decide that the misbehavior is best
> handled with the regular IETF procedures for dealing with disruptive
> behavior

Again, this confuses 'misbehavior' or 'conflict' with 'harassment'.


> and may assist the Reporter to bring the issue to the attention of 
> the working group chair or IESG member who can deal with the 
> incident.
> 
> 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
> 
> 
> 
> Resnick & Farrel        Expires September 6, 2015               [Page
> 8]
> 
> 
> Internet-Draft         Anti-Harassment Procedures             March
> 2015
> 
> 
> 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.

In no circumstances is "mediation" in any way appropriate or relevant in
a case of actual harassment.  Again, the document is confusing
harassment with various forms of interpersonal difficulties.

     Harassment is an attack by one person against one or more others in
a protected class.

     Bullying is an attack by one person to intimidate one or more others.

Under no circumstances do either of these warrant 'mediation', any more
than someone who had beaten another person up warrants mediation.


> 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.  (The Ombudsteam
> can not impose that a Respondent who is in a IETF management position
> be removed from that position.  There are existing mechanisms within
> IETF process for the removal of people from IETF management positions
> that may be used as necessary.)

This course of remedy appears to confuse disruptive behavior with
harassment, presumably thinking that the harassment is only relevant to
the attacked person.



> 5.1. 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.

Actually, the policy does not do that.  Effective enforcement of the
policy does that.


> 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.

"Does not escalate"? Not sure what that means.

In any event, I think the intent here is more along the lines of:

   ...to make sure that the harassment is immediately terminated and to
ensure that a similar behavior does not recur.

Harassment is not situational. Also the "with the same respondent in the
future" implies that it would be OK for harassment to occur with someone
else.  I suspect you don't intend that...



> 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
> 
> 
> 
> Resnick & Farrel        Expires September 6, 2015               [Page
> 9]
> 
> 
> Internet-Draft         Anti-Harassment Procedures             March
> 2015
> 
> 
> 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.

While the details of a harassment case must not be made public, it could
be reasonable and useful for a sanitized summary to be reported.

This accomplishes two things.

     First, it provides some instruction to the community that the
policy is serious.  For real serious, not just good intentions with no
teeth.

     Second, it permits a degree of community oversight.

Both of these are important benefits and are currently entirely lacking.


> 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

{insert repeated concern for the 'themself' perspective.}


> 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 in both 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.

So a dispute about the assessed facts or a dispute about the remedy are
out of scope for appeal???


> 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.

By whom?  Under what circumstances?  With access permitted by whom?


> The appeal will be evaluated by the IETF Chair (or the delegated
> IESG

   will be evaluated by an Appeals Group, comprising the IETF Chair...

> 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

This gives three IESG members access to detailed information about the
complaint.  Again, this will be a group of people with little-to-no
training in the handling of such matters.

Is this the proper set of folk for handling an appeal on this sort of
matter?



> 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.

A complaint against an IESG member would seem to require recusal by
everyone on the IESG.


> For the avoidance of doubt, recusal in this context means completely

  Delete: " For the avoidance of doubt"


> 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

That's not quite what the paragraph's first sentence says or means.  It
explicitly lists two limitations but does not preclude hearing details
of the case.




-- 
Dave Crocker
Brandenburg InternetWorking
bbiw.net