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

From: Jari Arkko <[email-masked]>
Date: Tue, 1 Sep 2015 16:23:16 +0300

I wanted to thank the design team and the editors for
good work. I’m very happy with this version.

I did, however, have a couple of editorial nits that I wanted
to bring up.

Section 5:

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.  If the Respondent holds a management position ...

I’d suggest adding a sentence here about the purpose of the remedy,
even if there’s a whole section about it later. For instance: “… no
longer attend future meetings as a way to ensure that  a serious
harassment can not continue. If the Respondent … "

Section 5.1:
  o  In the event that an AD declines to act on the recommendation of
      the Ombudsteam and fails to convince the Ombudsteam, 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 groups
      within its own structure so that the conflicted AD is no longer in
      the direct management path.

Where does “declines to act” refer to? The previous bullet item, where
an AD is expected to follow the advice of the ombudsteam? I that case
“conflicted” is probably the wrong term. Or maybe I don’t understand
what you are trying to say here. If the AD disagrees with the
recommendation from the ombudsteam, there could be various
reasons for it, from being conflicted somehow to mere
disagreement etc.

Please clarify.

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

This text could perhaps be modified to also account for the fact that
not only are these removals last resort in the above sense, but also
in the sense that not all situations require removal/stepping down.

Jari

---

From: Mark Nottingham <[email-masked]>
Date: Thu, 3 Sep 2015 12:43:05 +1000

One nit:

"""
Nothing in this document should be taken to interfere with the due process of law for the legal system under the jurisdiction of which any harassment takes place.
"""

I think it's a bit broader than that; depending on the specifics, sometimes where it occurs doesn't matter. I'd suggest just "…due process of law."

> On 1 Sep 2015, at 12:45 am, The IESG <[email-masked]> wrote:
> 
> This document has been in last call previously, and one issue in particular
> caused concern. A design team was  created in May 2015 to address this
> issue, and the document has also otherwise been updated. See further
> below for a detailed list of changes and history.
> 
> The sponsoring Area Director believes a new formal last call is needed
> to ensure that the resulting document matches the community's
> expectations on this important topic.
> 
> The sponsoring Area Director also believes that this is a topic where
> it is important to have an official IETF policy. Policies relating to
> human behaviour can be difficult topics to deal with, particularly
> in the all-cases-fully-specified manner that we are accustomed in
> our technical work. However, policies can be also be updated
> if later experience proves they have issues.
> 
> The IESG plans to make a decision in the next few weeks, and solicits
> final comments on this action. Please send substantive comments to the
> [email-masked] mailing lists by 2015-09-21. Exceptionally, comments may be
> sent to [email-masked] instead. In either case, please retain the
> beginning of the Subject line to allow automated sorting.
> 
> - 'IETF Anti-Harassment Procedures'
>  <draft-farrresnickel-harassment-08.txt> as Best Current Practice
> 
> The file can be obtained via
> https://datatracker.ietf.org/doc/draft-farrresnickel-harassment/
> 
> Changes since the previous last call can be seen via
> https://tools.ietf.org/rfcdiff?url1=draft-farrresnickel-harassment-05.txt&url2=draft-farrresnickel-harassment-08.txt
> 
> Adrian Farrel, one of the document editors stated this as a summary
> of the changes on the IETF list (the email is copied below and originally
> from http://www.ietf.org/mail-archive/web/ietf/current/msg94129.html):
> 
> ----
> 
> After some very fruitful mail exchanges on and off the list and some detailed
> discussions face-to-face in Prague, we have produced a new revision of the 
> anti-harassment process document.
> 
> Some of the changes are quite large. Others are small, but subtle. I 
> recommend reading the whole document, but if you want to look only
> at changes, I suggest you diff against -05, the version that was updated
> after IETF last call and went to the IESG for evaluation
> 
> In checking to see what changes were made and whether they addressed 
> your comments, please bear in mind that there were a lot of comments 
> made in a conversational manner and it was quite hard to round them 
> up and determine exactly what changes needed to be made. Ines did a 
> great job helping as Shepherd, but if we have missed something you 
> said, it is not because we are ignoring you: it's just that we lost the 
> point amongst other comments and discussions.
> 
> Additionally, I'd ask you to think about whether what we have is "good 
> enough" to act as a starting point. I'm conscious that we have been 
> debating having this piece of process for a long time and that my 
> personal preference is to get something going (a beta release?) and 
> then tune it as we go forwards. In the light of that I know that 
> consensus on some parts of the document may be a little rough. 
> This mainly happens when the opinions on an issue are very 
> divergent and not easily brought together. I hope that we have 
> done a good job at building bridges, but will not be surprised 
> or upset if some of you are not happy.
> 
> I'm responsible for most of the edits in this round (with 
> assistance from multiple people) so please blame me 
> (and complain about me to Pete) for any nonsense.
> 
> As to process, I suggest that this document needs to be
> taken around for another IETF last call, but I leave that
> to Jari as the responsible AD.
> 
> Thanks,
> Adrian
> 
> ------
> 
> In summary...
> 
> Abstract: clarify the nature of updates to existing RFCs.
> 
> Introduction: s/interpersonal/personal/
> 
> Definitions: Clarify that the definition of harassment is deliberately not
> a closed list.
> 
> Definitions: Add a paragraph (loosely based on the IEEE's equivalent
> policy) to scope when harassment applies within the IETF.
> 
> Definitions: Add a clause recommended by our lawyers about applicable law.
> 
> Ombudsteam: Clarify "recompense" to mean "compensation from the IETF".
> 
> Term of Service: Add paragraph for when an Ombudsperson's term ends 
> while they are acting as Lead Ombudsperson .
> 
> Term of Service: Add a note about likelihood of reappointment.
> 
> Compensation: Clarify "recompense" to mean "compensation from the IETF".
> 
> Removal: Expand the times that an Ombudsperson can be removed.
> 
> Handling Reports: Fix email address and URL.
> 
> Handling Reports: Clarify that remedies are imposed only after 
> completing investigations.
> 
> Operating Practices: Expand on confidentiality expectations.
> 
> Operating Practices: Clarify that the Respondent is contacted and 
> given an opportunity to interact before a remedy is imposed.
> 
> Operating Practices: Add when the Ombudsteam must commit things to writing.
> 
> Remedies: Add that mediation ned not be an end point.
> 
> Remedies: Show how remedies may be actioned through the Secretariat or IAD.
> 
> Remedies for Respondents in IETF Positions: Add substantial new section.
> 
> Purpose of Remedies: Expand on the details and theme of "not as 
> punishment" remedies.
> 
> Confidentiality: Add new section to describe expectations.
> 
> Acknowledgements: What a lot of you have helped with this document!
> 

--
Mark Nottingham   https://www.mnot.net/

---

From: "Adrian Farrel" <[email-masked]>
Date: Thu, 3 Sep 2015 08:15:38 +0100

Hi Mark,

I think I'm inclined to agree, but I will need to go back to counsel on this because this is text from them.

Cheers,
Adrian

> One nit:
> 
> """
> Nothing in this document should be taken to interfere with the due process of
> law for the legal system under the jurisdiction of which any harassment takes
> place.
> """
> 
> I think it's a bit broader than that; depending on the specifics, sometimes where
> it occurs doesn't matter. I'd suggest just "…due process of law."

---

From: John C Klensin <[email-masked]>
Date: Tue, 22 Sep 2015 15:07:24 -0400

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

---

From: Dave Crocker <[email-masked]>
Date: Wed, 23 Sep 2015 08:05:53 -0700

On 9/22/2015 12:07 PM, John C Klensin wrote:
> https://datatracker.ietf.org/doc/conflict-review-crocker-diversity-conduct/),
...
>  I believe

There is much that I agree with in John's posting, but this isn't one of
them.

This independent document is independent.  It is a discussion piece by a
couple of IETF participants.

The other document is a product of the IETF and it is intended to become
part of the formal IETF administrative structure.

If it takes work to understand the very considerable importance this
difference means, in terms of role and handling of an independent
document, then please do that work.

One of the less-pleasant bits of education I received throughout the
/seven months/ it has taken to get through the 'Independent' stream
process is that it is far from independent.  There seems to be a common
view that documents on that stream must be meaningfully subservient to
the IETF, rather than actually providing independent input to it.

I won't distract this thread further with details about the multiple
conceptual problems that afflicted the handling of this document, other
than to ask that no one try to impose further restrictions on a document
that really is intended to be /independent/.

d/
-- 
Dave Crocker
Brandenburg InternetWorking
bbiw.net

---

From: John C Klensin <[email-masked]>
Date: Wed, 23 Sep 2015 23:07:55 -0400

Dave,

I offered an opinion based on some considerable history and
perspective drawn from discussions about what (independent of
the IETF) the RFC Editor should publish that go back at least to
the early 1990s as well as the discussions that went into RFC
4844 and 4846.  The IESG and ISE will do whatever they decide is
appropriate.   I don't think turning this into a debate is a
good use of anyone's time, nor do I think either of us is likely
to persuade the other, so this note is merely an attempt to
clarify my view of the issue in the light of your note.

The ISE is appointed as the lead of an editorial acquisition and
decision process within the boundaries of a particular,
presumably coherent, series of documents.  RFC 4846 gives
examples of what the scope of the independent submission series
is about and includes.  It was not intended to be an exclusive
list and, if Nevil decides to change or interpret policies in a
way that expands the list, I will defend his right to do so
(even though I may also explain why I think expansions in
certain directions would be a bad idea).

Against that backdrop, I note that, at least as far as I know,
the process that is now known as the Independent Stream has
never published a (non-satirical) commentary on an IETF process
or even an informational, editorial, or opinion document about
how the IETF should operate.  I think there are good reasons for
that, at least unless the piece is a real critique of IETF
decisions.  

If you, as author, or Nevil, as ISE, concludes that the document
in question is not about IETF processes at all and that it is
completely independent of both draft-farrresnickel-harassment
and/or the current anti-harassment policy, I will separately
point out that the RFC Series has never before, at least in my
recollection, published a (non-satirical) document in sociology,
organizational behavior, personnel management, or, for that
matter, a book review of a romance novel.  There may be (and
probably are) pieces that overlap into one or more of those
areas but I don't believe there are any that do not contain at
least a major element connected specifically to computer
networking.

If Nevil decides to expand the series into any of those other
areas, I hope he will choose to discuss the decision with his
editorial board (of which, in the interest of full disclosure,
I'm a member), the IAB and/or RSOC, and the community.  That
discussion would, I hope, be about the expansion of scope and
the precedents it sets for the series and his successors, not
about a particular paper even though, in practice, it takes a
paper to start the discussion.  And, again, if he decides to
make the expansion, I will support his right to do so.

None of the above has anything to do with whether the
Independent Submission Editor is "independent" or not.  I have
not seen any issue of actual or attempted IETF (or IESG) control
in this particular case and have vigorously fought every attempt
at such control I've seen in the last two decades (RFC 4846 is,
to some small extent a symptom, especially given suggestions at
the time that all parts of the RFC Editor function be put
directly under IESG control).  In this particular case, I
believe the IESG should have spoken up and said "yes, there is
overlap, hold publication until the IETF policy documents are
resolved".  They didn't exercise even that much control (the
exact opposite of efforts at too much control).  Had they said
so, 4846 quite deliberately allows the ISE to say "thanks, but I
have my reasons and I'm not going to do that".  I think the
community expects that anyone who would hold the ISE role would
use that authority only very carefully and in clear or extreme
circumstances, but it is a key part of "independent".  Your
experience and perspective obviously differ.

best,
    john

--On Wednesday, September 23, 2015 08:05 -0700 Dave Crocker
<[email-masked]> wrote:

>> 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.
> 
> 
> There is much that I agree with in John's posting, but this
> isn't one of them.
> 
> This independent document is independent.  It is a discussion
> piece by a couple of IETF participants.
> 
> The other document is a product of the IETF and it is intended
> to become part of the formal IETF administrative structure.
> 
> If it takes work to understand the very considerable
> importance this difference means, in terms of role and
> handling of an independent document, then please do that work.
> 
> One of the less-pleasant bits of education I received
> throughout the /seven months/ it has taken to get through the
> 'Independent' stream process is that it is far from
> independent.  There seems to be a common view that documents
> on that stream must be meaningfully subservient to the IETF,
> rather than actually providing independent input to it.
> 
> I won't distract this thread further with details about the
> multiple conceptual problems that afflicted the handling of
> this document, other than to ask that no one try to impose
> further restrictions on a document that really is intended to
> be /independent/.
> 
> 
> d/

---

From: Jari Arkko <[email-masked]>
Date: Wed, 23 Sep 2015 23:28:29 -0400

I need to read John’s other comments with more time, but just
wanted to agree with Dave about the role of independent submissions.
It is a feature that they do not have to be synchronised with
IETF works.

Jari

---

From: Donald Eastlake <[email-masked]>
Date: Wed, 23 Sep 2015 23:44:27 -0400

Hi John,

On Wed, Sep 23, 2015 at 11:07 PM, John C Klensin <[email-masked]> wrote:
> ... I will separately

While I would agree with much of what you say, in my opinion RFC 4144,
which was published 10 years ago this month, is, to a significant
extent, about organizational behavior.

Thanks,
Donald
=============================
 Donald E. Eastlake 3rd   +1-508-333-2270 (cell)
 155 Beaver Street, Milford, MA 01757 USA
 [email-masked]

---

From: Dave Crocker <[email-masked]>
Date: Wed, 23 Sep 2015 21:12:13 -0700

On 9/23/2015 8:44 PM, Donald Eastlake wrote:
> While I would agree with much of what you say, in my opinion RFC 
> 4144, which was published 10 years ago this month, is, to a 
> significant extent, about organizational behavior.

Don, thanks for reminding us that the RFC channel has a long history of
being flexible about circulating comments on a wider variety of topics
than folks seem to think.

I believe it should matter far less whether a particular type of content
has ever been published as an RFC and far more about whether the content
is 'relevant' to the community and responsibly written. We should make a
point of erring in the direction of permission, rather than stricture,
to encourage open and diverse exploration of "relevant" issues.

And I see that the first sentence of the above paragraph is almost the
wording at http://www.rfc-editor.org/indsubs.html:

> The independent submission stream allows RFC publication for some 
> documents that are outside the official IETF/IAB/IRTF process but
> are relevant to the Internet community and achieve reasonable levels
> of technical and editorial quality.

(That process documents about the Independent stream emphasize
"technical" content ought to be viewed more as an unfortunate efficiency
hack that was taken when the texts were generated, than a Procrustean
stricture against 'non-technical' content.)

d/

ps. For reference, in the wonderfully formal and narrow terms that the
IETF has come to rely on, when considering matters of what it calls
'process', our draft is in fact /not/ a process document.  Under
different scenarios, it might have been turned into one, but in its
current form and through the Independent Stream, it is as I earlier
described, a commentary by some folk involved in the IETF.