Re: Updating BCP 10 -- NomCom

John C Klensin <john-ietf@jck.com> Sat, 10 January 2015 08:30 UTC

Return-Path: <john-ietf@jck.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 059F91A9029 for <ietf@ietfa.amsl.com>; Sat, 10 Jan 2015 00:30:29 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.61
X-Spam-Level:
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 mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oL3wn7KtNds3 for <ietf@ietfa.amsl.com>; Sat, 10 Jan 2015 00:30:26 -0800 (PST)
Received: from bsa2.jck.com (bsa2.jck.com [70.88.254.51]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A00571A8702 for <ietf@ietf.org>; Sat, 10 Jan 2015 00:30:26 -0800 (PST)
Received: from [198.252.137.35] (helo=JcK-HP8200.jck.com) by bsa2.jck.com with esmtp (Exim 4.82 (FreeBSD)) (envelope-from <john-ietf@jck.com>) id 1Y9rR9-000O2w-DQ; Sat, 10 Jan 2015 03:30:23 -0500
Date: Sat, 10 Jan 2015 03:30:11 -0500
From: John C Klensin <john-ietf@jck.com>
To: Eliot Lear <lear@cisco.com>, Michael Richardson <mcr+ietf@sandelman.ca>, ietf <ietf@ietf.org>
Subject: Re: Updating BCP 10 -- NomCom
Message-ID: <EDF194B98AD70FF3A2198040@JcK-HP8200.jck.com>
In-Reply-To: <54B0DC8F.8050003@cisco.com>
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> <20150108185452.CA6B81A8AF9@ietfa.amsl.com> <874.1420827627@sandelman.ca> <54B0DC8F.8050003@cisco.com>
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-Connect-IP: 198.252.137.35
X-SA-Exim-Mail-From: john-ietf@jck.com
X-SA-Exim-Scanned: No (on bsa2.jck.com); SAEximRunCond expanded to false
Archived-At: <http://mailarchive.ietf.org/arch/msg/ietf/RwNIFIQkKdkiy-s4h28IJngd-2Y>
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: Sat, 10 Jan 2015 08:30:29 -0000


--On Saturday, January 10, 2015 09:02 +0100 Eliot Lear
<lear@cisco.com> wrote:


> It seems to me that pragmatism needs to be kept in mind.  For
> one, I'd like to know if there has been an actual problem
> where someone (or better yet someoneS) has actually withheld
> commentary because of risk of retribution due to a liaison
> reading the content. 

"Retribution" might be a little strong, but, yes, I've been told
of a couple of such cases, including this year.  It would be
unfair to those who told me to identify either the people or the
details, so you will either have to take me word for it or
assume that I'm making it up, as you prefer.

One of the problems with this sort of thing is that, while it
would be possible for someone to write the Nomcom Chair, or
informally tell a Nomcom member or two, that they have not
commented and why, the far more likely reaction, especially in
an environment in which everyone is busy, is for the individuals
to simply say "I don't have time for this, especially with the
risks I think might be involved" to themselves and move on.

FWIW, I don't really think reports that the liaisons were handy
and therefore used to do things that, in a more perfect world,
voting members would have done is very helpful to understanding
what is necessary.  It may mean that other properties of the
existing model don't match the workload and we need to
restructure the Nomcom in other ways.  I note that, when the
current Nomcom model was set up, the IESG was at about a dozen
members as compared to fifteen today and we've added an IAOC
appointment, which adds not only another slot but a completely
different organizational profile that has to be considered.   If
we are suffering from a scaling problem, using liaisons to patch
around it may be the best solution available to Nomcom chairs,
but may not be optimal for the community.

> On top of that, I wonder if NOMCOM 
> chairs could comment if they ever felt that a liaison behaved
> inappropriately.  That is- is there really a problem to fix?
> If not, let's please not add process to deal with nonexistent
> problems.  If something becomes a problem we have the means to
> address it.

While I think information about that would be helpful, I want to
again stress that I'm not really very concerned about violations
of confidentiality, unreasonable attempts to exert inappropriate
influence (even any of those that could not be controlled), etc.
I am worried about chilling effects on input, and that goes back
to the comments above about whether or not a Nomcom chair would
even be aware of specific instances of that situation.

    john