Re: What is a "management position? [Last Call: <draft-farrresnickel-harassment-05.txt> (IETF Anti-Harassment Procedures) to Best Current Practice]

John C Klensin <john-ietf@jck.com> Fri, 20 March 2015 21:46 UTC

Return-Path: <john-ietf@jck.com>
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 288E91A9073 for <ietf@ietfa.amsl.com>; Fri, 20 Mar 2015 14:46:23 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.61
X-Spam-Level:
X-Spam-Status: No, score=-2.61 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, T_RP_MATCHES_RCVD=-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 4CkMdJ05ZJq5 for <ietf@ietfa.amsl.com>; Fri, 20 Mar 2015 14:46:21 -0700 (PDT)
Received: from bsa2.jck.com (ns.jck.com [70.88.254.51]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 56B361A906C for <ietf@ietf.org>; Fri, 20 Mar 2015 14:46:21 -0700 (PDT)
Received: from [198.252.137.35] (helo=JcK-HP8200.jck.com) by bsa2.jck.com with esmtp (Exim 4.82 (FreeBSD)) (envelope-from <john-ietf@jck.com>) id 1YZ4kC-0003jo-47; Fri, 20 Mar 2015 17:46:16 -0400
Date: Fri, 20 Mar 2015 17:46:11 -0400
From: John C Klensin <john-ietf@jck.com>
To: Jari Arkko <jari.arkko@piuha.net>
Subject: Re: What is a "management position? [Last Call: <draft-farrresnickel-harassment-05.txt> (IETF Anti-Harassment Procedures) to Best Current Practice]
Message-ID: <92FC37287A9D7FA1656E2601@JcK-HP8200.jck.com>
In-Reply-To: <965AA861-EAB8-4DCE-BB9B-9D02BE63AE68@piuha.net>
References: <5503914A.7060209@gmail.com> <5503BF22.5020902@gmail.com> <2AE2D092-C32A-46EB-88CA-71366965F4D7@cisco.com> <5505D873.1040203@gmail.com> <CAL0qLwbQf_2WUn8PrUXCMy_3w6tt+iJw0tyF=gUojA5fwRXJNg@mail.gmail.com> <550736E0.6080101@dcrocker.net> <20150316203250.GJ2179@mx1.yitter.info> <55073F22.6000606@dcrocker.net> <20150316204616.GK2179@mx1.yitter.info> <55074AC1.9080500@dcrocker.net> <20150316214620.GO2179@mx1.yitter.info> <550751AC.7090108@dcrocker.net> <55075EBA.4000905@gmail.com> <5509BB58.4060307@qti.qualcomm.com> <4BFAD9B9A5E18EA3882318BA@JcK-HP8200.jck.com> <965AA861-EAB8-4DCE-BB9B-9D02BE63AE68@piuha.net>
X-Mailer: Mulberry/4.0.8 (Win32)
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
X-SA-Exim-Connect-IP: 198.252.137.35
X-SA-Exim-Mail-From: john-ietf@jck.com
X-SA-Exim-Scanned: No (on bsa2.jck.com); SAEximRunCond expanded to false
Archived-At: <http://mailarchive.ietf.org/arch/msg/ietf/O__UTRrtqYL7LtfG9pUrSyqm6h8>
Cc: Pete Resnick <presnick@qti.qualcomm.com>, IETF Discussion List <ietf@ietf.org>
X-BeenThere: ietf@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
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: Fri, 20 Mar 2015 21:46:23 -0000


--On Friday, March 20, 2015 13:23 -0500 Jari Arkko
<jari.arkko@piuha.net> wrote:

> I agree with the points from Scott, Christian, and you John
> that it is possible that confidentiality is not maintained on
> a case involving a continuously bad actor. (Assuming we get to
> such a bad situation to begin with, which I hope we wont.)
> 
> My question to you though is what effect do you believe that
> observation should have on our procedures? Are you suggesting
> that they should not by default be confidential?

I think the draft outlines a process that should, in the hands
of the right people with the right professional skills (see
Mike's comments) work rather well for careless or insensitive
offenders who do things in the IETF that, on reflection, they
can be persuaded they should not be doing.  I thing a
confidential process is completely consistent with that.

If that fails, I think, first, that the neutral "respondent" is
no longer appropriate and we should be using terms like
"offender".    Whether "offender" gets qualified with terms like
"persistent", "obstinate about the correctness of his or her
behavior", "unrepentant" or other words may or may not be
relevant depending on the particular issues (and, by the way,
those applicable/local laws). Because of that I think we get
into a process, whether it involves the Ombudsteam, Recall, Post
Rights actions, and/or something else, that involves either
preventing another repetition whether the offender agrees or not
or protecting the community from the effects and consequences of
the offender's behavior, typically both.

To a considerable extent, I believe that once that line is
crossed, the presumption must be that the harassment is
interfering with the IETF getting work done and we are all
victims.

At that point, I think the most important role of the Ombudsteam
(one that, by the way, requires an even higher level of
professionalism than the "normal" case) is to work with
Reporter-victims, and, when appropriate, with the IESG and
potentially Counsel on behalf of community-victims to determine
whether the advantages of taking further steps --steps in which
confidentiality is ultimately not going to be possible and may
be less desirable-- to the community and individual victims
exceed the disadvantages of, e.g., risking disclosure of victim
identities, community gossip. etc.   I think we need to accept
something that others have said in different ways: when we start
doing things like blocking someone's ability to participate, it
better be done via and open process with the guarantees that
only openness at critical stages can bring.

   best,
   john