Re: Updating BCP 10 -- NomCom

Brian E Carpenter <> Thu, 08 January 2015 19:16 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id A19821A9024 for <>; Thu, 8 Jan 2015 11:16:01 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2
X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id nv-QmMspuERT for <>; Thu, 8 Jan 2015 11:15:59 -0800 (PST)
Received: from ( [IPv6:2607:f8b0:400e:c03::229]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 1CA0A1A8FD5 for <>; Thu, 8 Jan 2015 11:15:59 -0800 (PST)
Received: by with SMTP id rd3so13546834pab.0 for <>; Thu, 08 Jan 2015 11:15:58 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; 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=aIuwic6nTB8I/+b5QQlgPe8tGyzty1q5WKoUrqdAL0c=; b=FXBetVIOQy3UCXBSu056ZiBC1Q2hU/vyoO4KqMp/A6L+1sQYPlh9XKBz3LT9WJe9J1 4sG52yART2+W8INbLBOi2FK5W4+X02mcP6oSCwGzbK+5dACAXDYHIfGktvjksmc0Uksh FpJi5DNxL3AH93D6LqdF16s31Ue3QNS+rviKb5LiMQb+02bahCry0uwElXHSxEKIg3Mn 8IJhsCkgNu1233XffVpCH7yzPw79vEWT9NkWWx/NvtXLHo1UBeqz98IvfmyZ42uAosFG 94QEh5LIrzOQ5XXF5NZo5YHkFXNhckniM9VJjTbR9mRAInmrTjGwQljKWWveFZnLdKxe 5cSw==
X-Received: by with SMTP id z6mr17705053pdm.82.1420744558282; Thu, 08 Jan 2015 11:15:58 -0800 (PST)
Received: from ?IPv6:2406:e007:4640:1:28cc:dc4c:9703:6781? ([2406:e007:4640:1:28cc:dc4c:9703:6781]) by with ESMTPSA id v4sm5103560pbs.10.2015. (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 08 Jan 2015 11:15:57 -0800 (PST)
Message-ID: <>
Date: Fri, 09 Jan 2015 08:16:20 +1300
From: Brian E Carpenter <>
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: Eric Burger <>, Klensin John <>
Subject: Re: Updating BCP 10 -- NomCom
References: <> <> <> <> <>
In-Reply-To: <>
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 7bit
Archived-At: <>
Cc: ietf <>
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: IETF-Discussion <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Thu, 08 Jan 2015 19:16:01 -0000

On 09/01/2015 06:26, Eric Burger wrote:
>> On Jan 8, 2015, at 11:32 AM, John C Klensin <> wrote:
>> --On Thursday, January 08, 2015 11:08 -0500 Eric Burger
>> <> wrote:
>>>> On Jan 8, 2015, at 10:59 AM, John C Klensin
>>> ....
>>> Likewise, no matter how legalistic we become, a person with an
>>> agenda will have an agenda.
>> Unquestionably.  And, again, I don't want to see us attempt
>> fine-grained rules in this area, only discussion and better
>> calibration of community expectations than, e.g., the second you
>> cite above provides.
>> For example and in the hope of being a bit less vague, I
>> personally see no need for liaisons to sit in on candidate
>> interviews, to see supposedly-confidential candidate
>> questionnaires, to see community input about particular
>> candidates, or to participate in Nomcom discussions or be
>> exposed to correspondence about particular candidates or
>> candidate choice rankings.  And I see some disadvantages to the
>> quality and breadth of input the Nomcom is likely to receive to
>> their doing so. Do you disagree?
>> best,
>>    john
> 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.

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?

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. actually places several
specific duties on liaisons that effectively require them to track
Nomcom discussion quite closely.