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> Sat, 14 March 2015 18:54 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 0A7B41A00FE; Sat, 14 Mar 2015 11:54:51 -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 XdoOk_PVZ8HM; Sat, 14 Mar 2015 11:54:49 -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 8A8371A00CA; Sat, 14 Mar 2015 11:54:49 -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 1YWrCq-000LpP-PB; Sat, 14 Mar 2015 14:54:40 -0400
Date: Sat, 14 Mar 2015 14:54:36 -0400
From: John C Klensin <john-ietf@jck.com>
To: joel jaeggli <joelja@bogus.com>, Brian E Carpenter <brian.e.carpenter@gmail.com>, Spencer Dawkins <spencerdawkins.ietf@gmail.com>, Pete Resnick <presnick@qti.qualcomm.com>, Sam Hartman <hartmans-ietf@mit.edu>
Subject: Re: What is a "management position? [Last Call: <draft-farrresnickel-harassment-05.txt> (IETF Anti-Harassment Procedures) to Best Current Practice]
Message-ID: <FA06C6BE8A6E8722000B590C@JcK-HP8200.jck.com>
In-Reply-To: <55046AB2.5050602@bogus.com>
References: <20150116152211.25947.49086.idtracker@ietfa.amsl.com> <20150117174430.9A0471ACE15@ietfa.amsl.com> <20150306163724.GA32205@verdi> <tsl385im2yp.fsf@mit.edu> <781553AA-EA2C-4057-9888-491C80A780DA@piuha.net> <54FE045D.3080606@qti.qualcomm.com> <tslr3sxep1l.fsf@mit.edu> <54FE6297.4090008@qti.qualcomm.com> <tslzj7i2wid.fsf@mit.edu> <55019E72.4090004@qti.qualcomm.com> <tslfv9a2t6p.fsf@mit.edu> <36671C44-DE53-4AC9-B8EA-465BF97B2FDB@piuha.net> <tsly4n0zo6g.fsf@mit.edu> <550350C4.9040201@qti.qualcomm.com> <5503914A.7060209@gmail.com> <5503BF22.5020902@gmail.com> <55046AB2.5050602@bogus.com>
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/v--rT7XAs-ilVvLBWBDisu-pSoU>
Cc: IETF Discussion List <ietf@ietf.org>, iesg@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: Sat, 14 Mar 2015 18:54:51 -0000


--On Saturday, March 14, 2015 10:06 -0700 joel jaeggli
<joelja@bogus.com> wrote:

>> For the recallable positions, the situation is much more
>> tricky because a recall petition needs 20 signatories and is
>> announced. Let's get real : if that happens, the
>> confidentiality *will* be breached.
> 
> I don't think we can know that a priori.
> 
> Our previous experiment with the recall process involved
> unavailability, not some causal condition. I don't think
> there's particular merit in spelling out how a recall will be
> iniatiated, as that is dictated by circumstances and the power
> to do is vested in nomcom qualified individuals

Joel,

First, we've had no previous experience with the "recall
process".  The example I assure you are referring to was one in
which commitments to sign had been collected and it was clear
that the recall process would be initiated if the individual
involved did not resign, but he did.   I'm aware of another case
or two in which it was made clear to the person involved that
signature commitments were being collected and that led to a
change in behavior and/or a resignation.  At no point was the
ISOC President handed petitions and asked to hand them to the
Secretariat for verification and to appoint a Recall Committee
Chair. 

More important to Brian's point about confidentiality, you
didn't read quite far enough.  The paragraph immediately after
the one you quoted (from RFC 7437) reads:

	"The petition and its signatories must be announced to
	the IETF community."
	
Since the petition has to disclose the justification for the
recall and that petition has to be announced, confidentiality
about the target and the issue is, as far as I can tell, public
at that point.  Whether the situation can be kept private during
the signature-gathering process is an issue of things that can
be kept secret at the earlier stage if 20 people with no
obligation of secrecy know about it is interesting, but not
ultimately important.   I suppose the Secretariat could
"announce" the petition by saying "Lo, a petition has been
received and here are the people who signed it" without
disclosing either the target name or the justification, but I'd
guess the community would have a lot of trouble with that.  At a
minimum, I'd assume there would be an immediate effort to find
out who gave the Secretariat those instructions followed by an
appeal.

So, referring back to my earlier note, the recall process lacks
confidentiality about what is going on (although not about the
Recall Committee's investigation once it starts), is guaranteed
to be slow enough to cause damage to the community and the
successful functioning of the IESG, and generally is not
appropriate (at least without modification) to a situation in
which the Ombudsteam has already investigated the situation,
found that there was a problem, tried to cure the problem
through discussion and counseling, concluded that it has failed,
and concluded that significant restrictions or removal from a
position are appropriate.

best,
    john