Re: Updating BCP 10 -- NomCom

Brian E Carpenter <brian.e.carpenter@gmail.com> Fri, 09 January 2015 22:40 UTC

Return-Path: <brian.e.carpenter@gmail.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 7F6411A00AD for <ietf@ietfa.amsl.com>; Fri, 9 Jan 2015 14:40:07 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.999
X-Spam-Level:
X-Spam-Status: No, score=-3.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DIET_1=0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, GB_I_INVITATION=-2, SPF_PASS=-0.001] 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 0C5JuDR0cnNp for <ietf@ietfa.amsl.com>; Fri, 9 Jan 2015 14:40:03 -0800 (PST)
Received: from mail-pa0-x234.google.com (mail-pa0-x234.google.com [IPv6:2607:f8b0:400e:c03::234]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 270C41A0277 for <ietf@ietf.org>; Fri, 9 Jan 2015 14:40:03 -0800 (PST)
Received: by mail-pa0-f52.google.com with SMTP id eu11so20954976pac.11 for <ietf@ietf.org>; Fri, 09 Jan 2015 14:40:02 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:organization:user-agent:mime-version:to:cc :subject:references:in-reply-to:content-type :content-transfer-encoding; bh=d8Uhvt/4OplLnT+XeIGMl096fKszwvoVZfSsYPbziGI=; b=wXkdat/aJRR6ww3x00YwM59biQUUJ2lrNama29N6M6ydpszAvXKV8sBSJQyT7lPmQG TR1/FOAHnUAkRyqX21kmM73nbfGvw+inmcH6pXX5r4TVsorXGzCRX7/on4vQK8tuSw+5 JLinNZWXaRwu0Lyyy8HEDbSFQ+SgZwCfrI9+Ixw1m/Zby45OcJBE1gonQlAUv40oh8h7 lqADdeNZOQFQqSpXtyqwQcqZtZ3a5JhzL9ZR1piV5zWHFT99v01Vbb2yAZ04h4XOaVXb drTKkCp6vMQkmS7degybKUebO/IPelMVwtyxKlTJJebHpYFl5P1naCqz08unCr5QN3gh jxOg==
X-Received: by 10.70.96.8 with SMTP id do8mr27281040pdb.154.1420843202416; Fri, 09 Jan 2015 14:40:02 -0800 (PST)
Received: from ?IPv6:2406:e007:5167:1:28cc:dc4c:9703:6781? ([2406:e007:5167:1:28cc:dc4c:9703:6781]) by mx.google.com with ESMTPSA id se3sm7962960pbc.24.2015.01.09.14.39.59 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 09 Jan 2015 14:40:01 -0800 (PST)
Message-ID: <54B058DB.2080900@gmail.com>
Date: Sat, 10 Jan 2015 11:40:27 +1300
From: Brian E Carpenter <brian.e.carpenter@gmail.com>
Organization: University of Auckland
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.3.0
MIME-Version: 1.0
To: John C Klensin <john-ietf@jck.com>, Eric Burger <eburger@cs.georgetown.edu>
Subject: Re: Updating BCP 10 -- NomCom
References: <CAL0qLwZk=k-CWLte_ChK9f1kzLwMOTRyi7AwFa8fLjBsextBcA@mail.gmail.com> <D54C3DE17A3E5C7B032F6FB4@JcK-HP8200.jck.com> <BC1A05C1-6198-4325-8F46-8E5AB9D0DFCF@cs.georgetown.edu> <20038FAABC32083290783A97@JcK-HP8200.jck.com> <F3782236-1AF7-4F9C-8A15-2F9CC8BC8795@cs.georgetown.edu> <54AED784.2070402@gmail.com> <7E337D9D196B4A5AFF3D263A@JcK-HP8200.jck.com>
In-Reply-To: <7E337D9D196B4A5AFF3D263A@JcK-HP8200.jck.com>
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit
Archived-At: <http://mailarchive.ietf.org/arch/msg/ietf/swLvkKUcZLS27okShtUGxkF96yA>
Cc: ietf <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, 09 Jan 2015 22:40:07 -0000

Hi John,

On 10/01/2015 10:45, John C Klensin wrote:
> 
> 
> --On Friday, January 09, 2015 08:16 +1300 Brian E Carpenter
> <brian.e.carpenter@gmail.com> wrote:
> 
>>> As serving on nomcom in a liaison role in the past, I have to
>>> *agree* with you 1,000%. The liaisons should have a voice in
>>> the needs of their respective home groups, but should not be
>>> deciding who nomcom serves up. That means they do not have a
>>> burning need to be in the weeds of per-candidate nomcom stuff.
>>
>> My only Nomcom experience is also as ISOC liaison, some years
>> ago now, and I certainly agree that guidance about the limits
>> on a liaison's role would be of value. However, there's also a
>> practical aspect: if only certain information and certain
>> parts of the discussions are open to the liaisons, there will
>> be very clumsy discussions where a point has to be put on hold
>> until the relevant liaison can be consulted.
> 
> We seem to now be having two separate discussions that are
> getting confusingly (at least to me) intermixed.  

Fair comment. But the current BCP does indeed appear to give
the liaisons two distinct jobs bundled under one name. If we are
just going to tinker with the text, we should probably make that much
more explicit than it is now. Or we should separate the two jobs.

> One has to do
> with instructions the liaising bodies give their liaisons and
> what sorts of comments the liaisons are expected to make.   I
> had every reason to believe that was under control when I first
> commented in this thread.  Russ's note and comments from others
> have reinforced that impression.

Agreed.

> I'm not even concerned about liaisons exerting undue or
> inappropriate influence.  As Mike StJohns more or less pointed
> out, if the Nomcom Chair cannot control any tendencies in that
> direction, we probably have much more serious problems.
> Similarly, and borrowing further from him, I'm not wild about
> liaisons participating in _candidate_ interviews, but not
> particularly concerned about it either, especially if a
> candidate can ask for another interviewer.
> 
> All of the about are related, in one way or another, to
> information flow _to_ the Nomcom, _from_ the liaison.
> 
> I'm concerned about information flow in the other direction.  It
> has to do with, e.g., liaison participation in actual
> discussions of individual candidates, particularly in ways that
> would expose them to community comments about those candidates
> and information about (or that might permit the identification
> of) those who made them.  My instinct -- driven by several
> recent discussions and observations-- is that it is in the
> interest of the community and high-quality Nomcom
> decision-making to isolate the liaisons from community comments
> on candidates on the same basis and to the same degree that
> random members of the community are isolated.

That's a defensible viewpoint, but my observation is that it is
incompatible with several of the line items in
http://tools.ietf.org/html/rfc7437#section-4.7, especially the
first one:

   Liaisons are responsible for ensuring the nominating committee in
   general and the Chair in particular execute their assigned duties in
   the best interests of the IETF community.

At least when I was ISOC liaison, the ISOC Board definitely wanted to
be reassured that I had observed the Nomcom to execute the correct
process in an unbiased manner. But that gets hard to do if there
are parts of the materials or discussion that the liaison cannot
observe personally.

> To illustrate with two extreme scenarios, if I were a relatively
> junior member of the community, I might be quite concerned about
> criticizing some individuals, especially incumbents, because of
> fear of retaliation from that individual or their cronies.
> Whatever concerns I might have would be reinforced if I knew
> that one of the colleagues of those incumbents was going to be
> reading my comments, would know who originated them, and might
> react in ways I would find uncomfortable.  If I were a more
> senior member, similar considerations would apply, especially if
> what I wanted to tell the Nomcom was that the Ixx[x] was
> <negative-expletive> and that I considered the candidate a major
> part of the problem.  If the Nomcom has gotten more positive
> feedback and wants to check things out, they should --I'd argue
> that they would be falling down on the job if they didn't do so.
> On the other hand, I don't think the liaison should have any
> special access to express such an opinion nor be in a position
> to volunteer any opinion about the quality of my advice because
> he or she had seen my comments.

Which suggests to me that at a minimum we need to write down
more explicit limits on the liaisons than 'no vote'.

> 
> Against that background, I think the answers to your
> hypothetical scenario is fairly obvious, but...
>  
>> Just to test where people think the limit should be, here's a
>> hypothetical. The Nomcom has got feedback that nominee X has
>> been consistently obstructive in resolving disputes and is
>> always unwilling to compromise. Nomcom doesn't know whether
>> this is valid. Should the liaison be asked to comment?
> 
> I think that, if the Nomcom needs validity data of that sort,
> they should reach out -- to the chair of the relevant body if he
> or she is not a candidate and maybe even if they are, to
> selected people who have served with the candidate, and others
> as appropriate.  

I agree, and I agree that in such a case the liaison's input should
not be given extra weight (so SHOULD occur through the normal
process and not as a liaison communication).

> I note that, as bodies become more open about
> their deliberations (as the IESG has clearly been recently), the
> range of people who might reasonably be asked expands.  They can
> do so without compromising confidentiality: "we have heard that
> X might have been obstructive" or "we are concerned whether Y's
> obvious personality quirks might be a source of problems" do not
> appear me to do so in any way.  Is is reasonable to ask the
> liaison because the liaison is a member of the relevant group
> who might have insights?  Sure.   Is it appropriate to ask the
> liaison for a formal opinion _as liaison_ and give the answer
> special weight as a result?  IMO, almost certainly not.  Just
> posing the question in that context is an invitation to
> inappropriate or disproportionate influence even if the fault
> lies with the Nomcom and not the liaison.
> 
> IMO, maintaining a clear boundary in this area becomes more
> important as Nomcoms (and the community) evolve so that the
> Nomcoms are more dependent on questionnaires, interviews, and
> feedback rather than Nomcom member personal knowledge of
> candidates and their history and behavior.

Agreed.

>> BTW there is another aspect of the liaison role: acting as
>> part of the checks and balances, by being able to assure the
>> confirming bodies that Nomcom has followed correct and
>> unbiased procedure. To that extent, liaisons do need to
>> witness discussions, without influencing them.
>> http://tools.ietf.org/html/rfc7437#section-4.7 actually places
>> several specific duties on liaisons that effectively require
>> them to track Nomcom discussion quite closely.
> 
> And there I believe that the costs of having the liaisons in the
> dual role you describe outweigh the advantages.  We have enough
> difficulties with confirming bodies second-guessing the Nomcom
> -- a check I would not eliminate even though I have seen some of
> the invocations of it as problematic -- to not also need the
> liaisons _from_ bodies some or all of whose members are
> appointed to the Nomcom to also act as either auditors and
> witnesses or representatives/liaisons from the Nomcom back to
> those bodies.  If the confirming bodies need to as questions
> about how the Nomcom worked at the candidate level, let the ask
> the Nomcom Chair or, if necessary, meet with the Nomcom and ask
> questions of a group, not of an individual who is inherently in
> the middle.   The dual role also creates a unique
> opportunity/incentive for abuse (even though I have no reason to
> believe it has ever occurred) which involves liaisons who want
> to influence Nomcom outcomes being barred from doing that by
> instructions from their own bodies, the Nomcom Chair, etc.,
> turning around and expressing opinions of the results by
> reporting back that the procedures were questionable.
> 
> If we need an auditing function for Nomcom's following
> procedures -- beyond the Chair and former Chair-- we really need
> to figure out another way to do that.  

Well, that is the choice: remove many of the liaison duties specified
in RFC 7437 and limit the liaison's view of the Nomcom accordingly,
or leave those duties in place but add some more specific restrictions
on the liaison's participation.

   Brian

> And we should also note
> that we have no such auditing mechanism for, e.g., the IAOC
> which, because of the way some of its membership is appointed,
> is much less inherently accountable to the community.   That is
> _not_ a criticism of the IAOC, merely an observation of where we
> are putting out concerns and energy.
> 
>      john
> 
>