IETF Anti-Harassment Procedures
draft-farrresnickel-harassment-10

I am balloting ABSTAIN on this document because I did not manage to find time to provide my thoughts when the document was being developed and discussed in the community. I do regret that. It seems inappropriate to hold it up at this stage and given how much discussion has taken place.

When discussions about developing an anti-harassment policy first began I was in favor of the idea for two reasons. First, I thought we could improve the experience of attending IETF meetings by having a trusted person or people whom attendees could talk to and possibly strategize with if the attendees had experienced harassment. Second, I thought it was important to establish publicly the expectation that all attendees be treated with dignity, decency, and respect. The IESG policy accomplishes the second of these goals and this document seems aimed at accomplishing the first, among other things.

I do not believe the document accomplishes the first goal, however. This is because the procedures as outlined turn what could have been the key incremental improvement -- having a trusted person for attendees to talk to -- into a legalistic pile of process and communications that I believe will deter victims of harassment from making use of the system at all. When I have a sensitive incident to report, I want to report it to a single person whom I trust. I do not want to have to agree a priori to having that information shared with a team of three people, nor do I want to be re-directed to some other person who I perhaps trust less. I do not want the person to whom I report it to write it down. I just want to talk it through with the person. Then, if we both agree that some further course of action is warranted, I want to be involved in deciding what course of action I am comfortable with, and I want to continue to be involved in deciding whether to proceed at every step of the way, including steps that involve informing ADs, the secretariat, and other parties. I want to reserve the right to change my mind at any time. The problem with the document as written is that it severely disenfranchises the victim of the harassment, to the point where I expect that most victims would be afraid to actually make use of the procedures outlined in the document. Being harassed can be scary. The policies outlined in the document have utterly failed to account for that.

Furthermore, the document in sections 5.1 and 6 contemplates all manner of scenarios that may or may not come to pass and specifies detailed procedures for how to handle them. In practice I expect that there are probably scenarios we haven't thought of that will arise, while the ones for which detailed procedures have been specified might never get used. I wish we could have started with an incremental approach that achieves the two goals stated above, and then checked in after some implementation experience to see where the gaps are and what needs beefing up procedurally. Instead we are going from no process to an over-specified process without any implementation experience to build on.

I hope I'm wrong about the potential utility of the process specified in the document, but I cannot support it as written.

I'm sorry to move from a yes ballot to an abstain on this one
but I think the text has disimproved and some problematic
changes have been made since I last reviewed this a while
back for -05. I'm entirely happy that the authors have been
trying to handle the usual diverse IETF participant input
so me moving to abstain is just one of those things and 
does not mean I think the ombudsteam process being 
established is flawed. The document has ended up with
sufficient flaws though that me abstaining and getting out 
of the way is the better path.

My last discuss text (prior to abstaining is below).

START last-discuss-text

I've chatted (via IM) with Pete about the -10 version and I
cleared point 3, we agreed that point 2 is for Jari to go and
check with the lawyers, (or to decide to not do that) and we
developed a set of OLD/NEW changes for points 1, 4 and 5.
My plan is to move to a yes if all of those go my way, but to
an abstain if not (with the relevant remaining discuss points 
turned into comments). 

(1) section 2: calling out creating an environment that is
intimidating as a form of harassment goes too far I think.
It is in the nature of the IETF to be intimidating to non
engineers or to less qualified engineers. Feeling intimidated
because one is ignorant and where nobody is trying to do harm
is something that is ok. Trying to intimidate is not ok,
attempting to intimidate because someone is young, old, etc.
is not ok, but that was already stated. 
IM with Pete suggested this OLD/NEW which'd work for me
if the authors are ok with it:
OLD:

  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.

NEW:
   This document concerns itself with harassment that has the purpose or
   effect of unreasonably interfering with an individual's participation
   in IETF activities or harassment which creates an environment within the IETF that
   would be intimidating, hostile, or offensive.

(2) section 2, last para: I do not want the IETF to be
subject to all the laws of all countries all at once. 
This seems to assert that and that there is IETF
consensus for that assertion. I don't believe either
is true and believe this sentence should be deleted.
There are some possibly relevant laws in some countries that
are such that the IETF can't reasonably ask me to agree with
those.  Put another way: I read this as saying that we're asserting
that at any given time the IETF will have consensus on the 
relevance of every applicable law everywhere. I do not think 
such an IETF consensus exists or can exist.
In an IM chat with Pete, we ended up figuring expressing this
point like this might help "We don’t want the ombuds to have 
to figure out which of all possible laws in the world are applicable, 
and this sentence doesn’t add anything really, since the ombuds 
get to decide how to handle any complaint, whether it falls 
under any definition or not. So let’s just strike the sentence."
So this one is now for Jari to ask Lawyer: given the above
interpretation, wouldn't it be better to remove the sentence
since it could do harm and not match IETF consensus if included?

(3) cleared

(4) 5.1, 2nd last para: respect has to be earned it's not ok to 
just say "ombudsteam => correct" for such a new construct. I 
think this kind of text might be enough to be problematic 
if/when someone goes to court and claims these are unfair 
procedures.
A suggested OLD/NEW:
OLD:
   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.
NEW
    As the Ombudsteam function is seen to be improving the IETF 
   and gains the respect of participants over time, 
   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.

(5) 5.2: purpose "is to prevent all" - that's nonsense, there
is no point in setting an impossible purpose.  The purpose
surely is to minimise harassment and the impact if harassment
has occurred? If this BCP makes such impossible claims, and
if someone does ever end up in court, I would expect that
this BCP could not be defended. That seems like a bad
plan to me. 
The following change would however fix this:
OLD
is to prevent all
NEW
is to deal with and discourage

END last-discuss-text, old non-discuss comments are 
below here.

(I didn't check -10 against these comments - I'm fine to chat
more about them if the authors want but I suspect we'd all
prefer to get this out the door instead.)

Some of my comments on the changed text here are close to
discusses, but I think if we resolve the discusses then we'll
hopefully also fix what needs fixing below.

- intro, 2nd last para: I'd prefer s/intended/only intended/
I do think we should ensure that the ombudsteam can't get out
of control, to the extent any formalism would help there.

- section 2, 3rd last para: What is the sentence starting
with "One way..." supposed to mean? Are you trying to get at
situations where someone demands favours of some kind (e.g.
sexual?) in return for doing what they ought in any case do?
I don't think it's useful to be unclear like that.

- 3.5: Say if someone refuses to accept that a report has
been dealt with for 5 years. Does the lead ombudsbeing
continue to be part of the team for all of that time? Do they
only handle the existing "case"? Is there no way to hand off
and finally free our poor ombudsbeing in such a case? (There
will be reporters who don't want to let go, and that could be
a problem for team members.) Just extending the term isn't a
good plan I believe.

- 4.1: The respondent is not obliged to co-operate is a
tautology and should be omitted. "May consider failure to
co-operate" sounds a bit too threatening and is it really
needed or useful here? 

- 4.1: All reports in writing? Why? I think that's a detail
for the ombudsteam and they ought be allowed to decide that a
word in the ear is the most effective thing to do. I of
course agree that all reports of substance need to be dealt
with in writing, but even in that case, I don't think you
mean that the reporter has to use writing to report.

- 5.1: Why does 5.1 say "Per section 5.1"? 

- 5.1: The two places you say that folks are not qualified
are not needed (recall ctte and appointing body) and are I
think counterproductive. Any such set of IETFers is actually
reasonably likely to have some qualified folks and some not.
(And for everyone to believe themselves qualified.) I think
you want to say that (over time) we ought (grow to) respect
the ombudsteam decisions which is a good goal, (over time)
but one that can only be reached (over time) with good
demonstrated performance and respect can't just be declared
to be required.

- 5.1: The AD specific bullet is odd.  What if the remedy is
to be applied to an IAB programme lead or liaison manager or
directorate secretary? I think you could generalise, but at
that point it's probably so obvious as to not need saying.
Maybe delete that bullet.

- 5.1, the last-resort bit: this is good but I think s/should
consider/must consider/ is needed there. I can't see there
being a case where the ombudsbeing wouldn't consider a lesser
remedy and if they ever get to the last resort they really
had better have documented (internally) that they did
consider lesser remedies.

- section 8: this is not only a summary, the last point
was not previously made. I didn't check all the others.

comments on text previously reviewed:

- section 2: the term "potential harrassment" is weird, esp
in "reports potential harrassment" - this would allow a
reporter Bob to say that Charlie might be able to harrass
Alice. That is always true.

- 3.1: The 1st and 2nd sentences here contradict one another.
Rewording can fix, e.g. s/shall/ought/ and s/will rapidly/
should rapidly/

- 3.2: "may consider elements of diversity" is bogus. Of
course the IETF chair can do that. If we want the IETF chair
to do so, we should say they ought, not that they may. Strike
this or s/may/ought/

- section 4: Will normal web access logs to related web pages
be kept? Maybe this'd be better on another domain?

- 4.1: The ombudsteam set their own procedures but if the
community are unhappy with those the only recourse is the
(never used) recall for the IETF chair? That's not going to
happen. I think you're missing a middle step where the IETF
chair should fire the ombudsteam if the community don't
accept team practices and the team don't fix those in
response.

- 4.1: This dives into too much detail in a number of ways.
Let the team figure out those details.  E.g., saying "do like
nomcom" is a bit strong here, I'd allow the team to decide
that. They could e.g.  prefer to use some kind of
whistleblower technology and no email at all. (The statement
isn't entirely broken as-is, but is also not needed.) One
could maybe say that the team need to be at least as careful
as nomcom should be.

- 4.1: The shall in "shall not be subject to retaliation" is
wishful thinking. Nobody can control that. I think you want
to say that good-faith reports ought not by themselves be
considered a negative and that this is something on which the
IETF has consensus.