Re: Updating BCP 10 -- NomCom

Eric Burger <eburger@cs.georgetown.edu> Thu, 08 January 2015 19:20 UTC

Return-Path: <mep27rym@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 56F061A9004 for <ietf@ietfa.amsl.com>; Thu, 8 Jan 2015 11:20:08 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Level:
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FREEMAIL_FROM=0.001, 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 rvDNHN3dwbcP for <ietf@ietfa.amsl.com>; Thu, 8 Jan 2015 11:20:04 -0800 (PST)
Received: from mail-qg0-x232.google.com (mail-qg0-x232.google.com [IPv6:2607:f8b0:400d:c04::232]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1DECF1A8F50 for <ietf@ietf.org>; Thu, 8 Jan 2015 11:20:04 -0800 (PST)
Received: by mail-qg0-f50.google.com with SMTP id z60so4165698qgd.9 for <ietf@ietf.org>; Thu, 08 Jan 2015 11:20:03 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=sender:content-type:mime-version:subject:from:in-reply-to:date :message-id:references:to; bh=wM/HaWu0RIiunYG6x8ktSm4M+u3enRSJ3Vs+XyZSgj0=; b=Ta198F9jUGjnVqKVxb9TjzePa3b3ubmvuJwiDSLh/bcE4GYSVgk1TDi/T4o3Fpk/JG +A3fLCyxDW0tZNNRJvw+Cc8fAAU8ETJ9EvAPFSusnVDNMvU2e+J0iWxzEMsdxo1AJtfF sO9I+lbaK1sTfRYNqXJNPgnSQjyD2WZa1VM2AiJQtjcflXAoDT87wALvAQk1PY6yR8me h63sDOY8UCDBEC/3JhUnlluKWIem2EVVvq5yoBqkAh0in/IQf1W1pT6nMi4Cpec3q+AA RVRtzVqJmmSIeluPs0jHDezuDOJfzSx+zcRMyXpgjDYLtEfrLgneC8VEafNXV621Bq2A dRLQ==
X-Received: by 10.140.101.135 with SMTP id u7mr17819256qge.2.1420744802536; Thu, 08 Jan 2015 11:20:02 -0800 (PST)
Received: from [172.22.6.156] ([12.21.1.100]) by mx.google.com with ESMTPSA id r2sm4834741qah.1.2015.01.08.11.20.00 for <ietf@ietf.org> (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Thu, 08 Jan 2015 11:20:01 -0800 (PST)
Sender: Eric Burger <mep27rym@gmail.com>
Content-Type: multipart/signed; boundary="Apple-Mail=_0F80FE97-94D7-4689-AC41-4BE613A89285"; protocol="application/pgp-signature"; micalg="pgp-sha1"
Mime-Version: 1.0 (Mac OS X Mail 8.1 \(1993\))
Subject: Re: Updating BCP 10 -- NomCom
X-Pgp-Agent: GPGMail 2.5b4
From: Eric Burger <eburger@cs.georgetown.edu>
In-Reply-To: <54AED784.2070402@gmail.com>
Date: Thu, 08 Jan 2015 14:19:59 -0500
Message-Id: <07F5F42A-1BEA-410D-B280-4925664E2E29@cs.georgetown.edu>
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>
To: ietf <ietf@ietf.org>
X-Mailer: Apple Mail (2.1993)
Archived-At: <http://mailarchive.ietf.org/arch/msg/ietf/EU08C4B15PTIdraGumK2vqHiewM>
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, 08 Jan 2015 19:20:08 -0000

> On Jan 8, 2015, at 2:16 PM, Brian E Carpenter <brian.e.carpenter@gmail.com> wrote:
[…]
> 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.
> 
> 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?

Here is a hypothetical that gives the answer. 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 <change>nomcom ask people in the community</change> to comment?

My answer is Yes. As the liaison is part of the community, there is no reason not to ask the liaison to comment,

> 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.

Being around for discussions is quite different than digging into the deep, dark backgrounds of candidates or doing the work of the nomcom (doing or being at interviews, etc.). I believe that was the original question.