Re: Sam's text and way forward on the last call of draft-farrresnickel-harassment-05.txt

Eliot Lear <lear@cisco.com> Thu, 19 March 2015 13:40 UTC

Return-Path: <lear@cisco.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 3ADBF1A8A7E for <ietf@ietfa.amsl.com>; Thu, 19 Mar 2015 06:40:47 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -14.511
X-Spam-Level:
X-Spam-Status: No, score=-14.511 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, USER_IN_DEF_DKIM_WL=-7.5] 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 keno-OPF0mhD for <ietf@ietfa.amsl.com>; Thu, 19 Mar 2015 06:40:42 -0700 (PDT)
Received: from rcdn-iport-8.cisco.com (rcdn-iport-8.cisco.com [173.37.86.79]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7DB031A8A7C for <ietf@ietf.org>; Thu, 19 Mar 2015 06:40:42 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=3952; q=dns/txt; s=iport; t=1426772442; x=1427982042; h=message-id:date:from:mime-version:to:subject:references: in-reply-to; bh=RuyLmWiLpZieMGatbUHI+zXJUgO95RwGLujxcMtS9oI=; b=PxBjpw/bSXv+Zhy8Vu5bkkgq4XmKnblPWKqATs4NOMiI9FW4MSPiXm+a eg1fC8qQe1uO4q4uiyYn2sCMejMhGAg8ZOQk16NZF9nEcQJcaMjUhecVU Ruy8fRrpPQ/p2fZ9B3c0YYDMMKIWcnCqzrKjYLYx5kTBseSkCh79G1mYf E=;
X-Files: signature.asc : 486
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: A0AZBQCqaeJU/5NdJa1bgwaEL8UuAoEYQwEBAQEBAXyEDQEBBCNCExELGAkWCwICCQMCAQIBRQYBDAgBARCIGbcolw0BAQEBAQEBAwEBAQEBAQEbiwyEH1WCaIFCBZESgS6CI4QMhk+MPiKCMoE9PYJ0AQEB
X-IronPort-AV: E=Sophos;i="5.11,430,1422921600"; d="asc'?scan'208";a="404722289"
Received: from rcdn-core-11.cisco.com ([173.37.93.147]) by rcdn-iport-8.cisco.com with ESMTP; 19 Mar 2015 13:40:40 +0000
Received: from [10.86.249.152] (bxb-vpn3-408.cisco.com [10.86.249.152]) by rcdn-core-11.cisco.com (8.14.5/8.14.5) with ESMTP id t2JDecR4028643; Thu, 19 Mar 2015 13:40:39 GMT
Message-ID: <550AD1D5.8060404@cisco.com>
Date: Thu, 19 Mar 2015 14:40:37 +0100
From: Eliot Lear <lear@cisco.com>
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:31.0) Gecko/20100101 Thunderbird/31.5.0
MIME-Version: 1.0
To: Jari Arkko <jari.arkko@piuha.net>, IETF Discussion List <ietf@ietf.org>
Subject: Re: Sam's text and way forward on the last call of draft-farrresnickel-harassment-05.txt
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> <B714CBFE-5D3D-4293-91C2-534A3437EB24@piuha.net>
In-Reply-To: <B714CBFE-5D3D-4293-91C2-534A3437EB24@piuha.net>
Content-Type: multipart/signed; micalg="pgp-sha1"; protocol="application/pgp-signature"; boundary="ewTmunfeofJt0uPxp3Et44KRBgeRgFPkO"
Archived-At: <http://mailarchive.ietf.org/arch/msg/ietf/6VvE5fmMHFP0iCeDHME5C9hk3vI>
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: Thu, 19 Mar 2015 13:40:47 -0000

Hi Jari,

I've been following this discussion for some time, and while I agree
that it is important to protect people from harassment, it is also
important for the community to be able to hold decision makers
accountable for their decisions.  This draft puts too much power in the
hands of people who are not appointed by the community.  While I truly
do understand the need to scale the function of the AD, this is a case
where I believe the community expects them to take responsibility for
excluding someone from some or all of our processes.  I am happy for the
ombudsman team to have responsibility for providing you guidance, but
the decision to exclude someone or not should be exclusively in the
hands of someone who cannot be recalled.

To that end...

On 3/19/15 11:03 AM, Jari Arkko wrote:
> I wanted to recap where we are with respect to the topic
> of incidents handled by the ombudsteam affecting roles
> that people have in the IETF.
>
> First off, I think we have broad agreement that we need
> to deal with this better than version -06 of the document
> does, and that misbehaving leadership needs to be
> removed. The debate has been about the specific
> mechanics of doing that, and clearly -06 was not up
> to the task, as well as leaving a bad impression.
> I’m sorry. We are now in the process of seeing how to
> correct that.
>
> I would like to get to the specific proposals. Sam
> suggested one way of dealing with this, copied below.
>
> I personally like this text. There are some variations of
> the general approach, I think Pete argued for a similar
> treatment of WG chairs and nomcom-appointed
> positions. I could live with that as well.
>
> However, there is clearly another class of approaches
> to solving this. We could specify the mechanics of
> ombudsteam initiating or running the recall process,
> or providing the ombudsteam the authority to terminate
> appointments. I think this type of an approach is also
> possible, but would tie into our nomcom and recall
> processes in a quite close manner. The details would
> have to be specified, and of course, the resulting system
> should still be workable, safe, etc. from overall IETF
> perspective. Does anyone have a proposal in this
> space, or believe we should take this path?
>
> Or are there other approaches not listed in this
> e-mail?

Yes.  The change here would be that the lead ombudsman may recommend
corrective action, but that person must do so to an area director who is
in an appropriate position of authority to rectify the matter, up to and
including excluding someone from an activity.

In the case where an area director, IAB member, or IAOC member stands
accused or has a conflict of interest, they must remove themselves from
the proceedings.

In this way, accountability to the community for the function is
directly maintained.  To be clear, this balances confidentiality against
accountability,  Both are important.

Eliot