RE: Last Call: <draft-farrresnickel-harassment-08.txt> (IETF Anti-Harassment Procedures) to Best Current Practice

[John C Klensin <[e-mail]>]

Hi.

I had decided to not comment further on this, but an issue arose
over the weekend that caused me to decide to go back and review
-08 and, when -09 appeared this morning, to look at it as well.
Apologies for lateness, but most of these comments would have
been impossible earlier.

First, I am still deeply troubled by the idea that the best way
to address harassment and similar problems is to create an
elaborate structure and rules that takes an 18 page document to
describe.  That doesn't make the problem any less important -- I
very much believe it is important -- but it says something about
the IETF at the present state of its evolution that we (and
particularly the IESG) find it necessary to develop this type of
formalized arrangement.

That said, quibbles aside, I think that this document has
converged on at least a local optimum in ways to do it.   There
may be other approaches that would be as good, but I have
doubts, again quibbles and the comments below aside, that it we
could do a lot better.

I hope the IESG will openly and carefully consider the comments
below, even if they result in no changes to this document,
rather than just pushing through something written by one
sitting AD and one former one, that can be seen as a supporting
document for policies the IESG has already announced and
published, and on which the IESG has already spent sufficient
time to be considered invested.  

(1) Given that the IETF is still supposed to be an organization
focused on Internet Engineering and that many of our procedures
are, IMO, very much dependent on the assumption that the huge
majority of participants have a network engineering (or
equivalent) background and primary interests (at least within
the IETF context), anyone who actively wants to serve as an
Ombudsperson is appropriately viewed with a certain amount of
skepticism by the rest of the community.  I am known as having a
suspicious nature, but I would even wonder about someone who
wanted an Ombudsperson appointment as a means of getting
training that could lead to qualification for some position
unrelated to the IETF.   I don't know of a better way to deal
with that then relying on the IETF Chair's discretion, but, if
only because the community has occasionally attracted characters
with strong opinions about how others should run their lives and
interests forcing them to do so, we all, including the IETF
Chair, need to be sensitive to that risk.

(2) While I would not expect to see actual problems, having the
IETF Chair able to remove an Ombudsperson "without explanation
to the community" is troubling and a potential source of abuse
(we have, of course, never had a situation in which an incoming
IETF Chair has or develops personality problems with someone who
got along perfectly well with a predecessor IETF Chair.  Never.
:-( ).  Obviously, the solution to that potential problem is not
disclosure to the community (the document seems right about
that), but there should be an obligation to disclose reasons to
at least the person being removed (with no obligation on that
person to keep those reasons confidential) and/or to the
Ombudsteam.   As usual, sunshine, or even the potential for
sunshine, it the IETF's ultimate best protection against the
perception of abuse.

(3) I continue to object in principle to mechanisms that may
concern or involve people who are active in the IETF but do not
regularly attend face to face meetings bein8g exercised by a
group that is chosen on condition of regular meeting attendance.
Nothing in this document or the Anti-Harassment Policy appears
to prevent a remote attendee/ participant from being a Subject,
Reporter, or Respondent.  For this particular set of Ombudsteam
roles in which people are called upon to make evaluations of the
behavior of others, the principle described in some areas as
"jury of his or her peers" interacts with remote participant and
participants.  If the IESG and the community have concluded that
f2f presence of the Ombudsteam is important, it would be useful,
especially to the perception that the IETF is welcoming to
people who do not attend meetings regularly, to include a
section or appendix explaining the reasons for that choice.

(4) While I strongly support the ability of the Ombudsteam to
initiate a recall procedure without collecting signatures (and
potentially disclosing otherwise-confidential material in that
process), I would encourage the IESG to encourage community
discussion of whether the need for that provision in this
document might be symptomatic of the recall procedure having
become to onerous to be useful.   I can only express the hope
that the IESG is sufficiently sensitive to community needs and
sufficiently confident of their own skills and roles to
encourage, rather than block, discussion of possible changes
that could make it easier to remove members of the IESG.

(5) draft-crocker-diversity-conduct is now in the Independent
Submission queue.  Some of its material, most obviously Section
2.2 of the -06 version, overlap with the present document and
the Anti-harassment policy and both supply additional
information and appear to recommend a somewhat different
approach. Neither document references the other. In reviewing
the record, I discovered that the IESG concluded that there was
"no conflict between this document and IETF work"
(https://datatracker.ietf.org/doc/conflict-review-crocker-diversity-conduct/),
a conclusion I find astonishing especially since the
draft-crocker piece is now in the RFC Editor queue and hence
appears to be on-track for being published first.  I believe
that, if both documents are to be published, the community would
be better served by having these documents published together
and having at least one reference and explanation of the
different perspectives in one (or both) of them.  

More generally, it is not an accident that "Non-satirical
commentary on IETF processes, procedures, and culture" was left
out of the discussion in Section 2 of RFC 4846.  I would support
an ISE decision to publish a document that was a critical
evaluation of an IETF policy if the IETF Stream were unwilling
to do so, but draft-crocker-diversity is not such a critique: if
the authors have points of disagreement with either this
document or the posted policy, they don't say so, nor do they
call out points of agreement and identify the supplemental or
complementary material.  IMO, we make progress by exposing
disagreements and having healthy discussions of them.  If we
cannot reach consensus, we facilitate progress and understanding
by documenting those differences of opinion.  I believe that the
IESG should retrieve the draft-crocker document from the
Independent Stream, encourage appropriate cross-referencing and
comments, and then publish both documents in the IETF Stream.
That would not only keep IETF policy discussions and documents
where they belong (in the IETF) but would illustrate to various
skeptics that, even when the IESG is heavily invested in a
document, they and the IETF remain open to other ideas. 

(For the record, I am taking absolutely no position here on the
editorial or substantive quality of the draft-crocker- document.)

Quibble: Some parts of Section 5.1 "understand that they are not
qualified in handling issues of harassment".  That is fine as a
presumption and will usually be true.  But it is not going to be
universally true, especially if some former Ombudsteam members
end up in WG Chair, AD, etc. roles.  "Presumed" would help a
lot.  An explanation that, even if they have the relevant
qualifications, using them to second-guess the Ombudsteam
(except possibly in an appeal process) is not desirable would be
even better.

best,
    john