Re: Updating BCP 10 -- NomCom

John C Klensin <> Thu, 08 January 2015 15:59 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id 1507E1A6F01 for <>; Thu, 8 Jan 2015 07:59:48 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.61
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 ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id FhBDlB-szXkw for <>; Thu, 8 Jan 2015 07:59:46 -0800 (PST)
Received: from ( []) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 3FC651A8A92 for <>; Thu, 8 Jan 2015 07:59:46 -0800 (PST)
Received: from [] ( by with esmtp (Exim 4.82 (FreeBSD)) (envelope-from <>) id 1Y9FUu-000HQN-Vn; Thu, 08 Jan 2015 10:59:44 -0500
Date: Thu, 08 Jan 2015 10:59:36 -0500
From: John C Klensin <>
To: "Murray S. Kucherawy" <>, ietf <>
Subject: Re: Updating BCP 10 -- NomCom
Message-ID: <>
In-Reply-To: <>
References: <>
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-Scanned: No (on; SAEximRunCond expanded to false
Archived-At: <>
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 15:59:48 -0000

--On Wednesday, January 07, 2015 09:03 -0800 "Murray S.
Kucherawy" <> wrote:

> The first change I'd like to propose is that the IAOC Liaison
> to the NomCom be codified.  It's currently only an unwritten
> common practice.

I think that is fine.  However, while I continue to be generally
opposed to firm rules, I think the whole role of the liaisons
needs work.  Because of the potential for damaging existing
working relationships, the presence of the liaisons (or
particular people in liaison roles) may have chilling effects on
whether the Nomcom gets input and how candid that input actually
is. In addition, liaisons might well be assumed to be biased in
favor of retaining a status quo that works for them.  Some
assurances to the community that, e.g., liaisons were expected
to answer questions and provide general advice about roles but
that they would be at least as isolated from input about, and
internal Nomcom discussion of, specific candidates as ordinary
participants in the IETF might, in that regard, be both helpful
to a Nomcom trying to solicit input and to general impressions
about the integrity of the process.