Re: Updating BCP 10 -- NomCom

John C Klensin <john-ietf@jck.com> Sat, 10 January 2015 01:04 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 35A761A1B13 for <ietf@ietfa.amsl.com>; Fri, 9 Jan 2015 17:04:03 -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 SXnHdE1Qg4pX for <ietf@ietfa.amsl.com>; Fri, 9 Jan 2015 17:04:00 -0800 (PST)
Received: from bsa2.jck.com (ns.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 DDEBA1A19F2 for <ietf@ietf.org>; Fri, 9 Jan 2015 17:03:59 -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 1Y9kT5-000Msw-5P; Fri, 09 Jan 2015 20:03:55 -0500
Date: Fri, 09 Jan 2015 20:03:43 -0500
From: John C Klensin <john-ietf@jck.com>
To: Michael StJohns <mstjohns@comcast.net>, Brian E Carpenter <brian.e.carpenter@gmail.com>, Eric Burger <eburger@cs.georgetown.edu>
Subject: Re: Updating BCP 10 -- NomCom
Message-ID: <0FED15FDDDEF0AC670A8197B@JcK-HP8200.jck.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> <F3782236-1AF7-4F9C-8A15-2F9CC8BC8795@cs.georgetown.edu> <54AED784.2070402@gmail.com> <7E337D9D196B4A5AFF3D263A@JcK-HP8200.jck.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/mYuMq5Zdl-DNxExTGDwJ1m86FAU>
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: Sat, 10 Jan 2015 01:04:03 -0000


--On Friday, January 09, 2015 17:07 -0500 Michael StJohns
<mstjohns@comcast.net>; wrote:

>> 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
>...
> Silly me... I assumed that the confidentiality rules covered
> this issue.  :-)

I actually as less concerned about leaks than about another
problem.  For leaks, I think the confidentiality rules do apply
and that, if a liaison decided to break them it is probably no
worse than a voting Nomcom member doing so... and we have other
problems.  See below.
>...
> The old saw is that "two can keep a secret if one is dead".
> With the Nomcom statutorily 10 voting members plus the chair
> and past chair that participate in all discussions, I'm not
> sure we're ever going to get a guarantee of secrecy with
> respect to those discussions.  Adding in the 4 liaisons
> doesn't - IMO - materially add to the problem.

Agreed.

>...

One place where that old saw leads is something I can best
illustrate by example.  In the last few years, I've made the
observation several times, not always in jest, that one of the
advantages of running one's own mail servers on one's own
premises is that it acts as a barrier against secret subpoenas.
"Klensin, you are required to supply copies of all of Klensin's
email and not tell Klensin we asked/told you" fails all sorts of
laugh tests in ways that similar instructions to third parties
do not.

I'm going to pick on the IESG for obvious reasons, but similar
issues might apply to the IOAC and some contracts and, with more
indirection, to IAB or even ISOC.  Suppose the liaison gets
unwelcome criticism of one of his (or her) colleagues and/or by
implication, most or all of IESG for not spotting and preventing
particular behavior.  First, the inhibiting effects of the
latter are obvious because, directly or indirectly, the liaison
him/herself is being criticized.  Even without that, there is
the concern that the criticism could cause the liaison's future
(or even current) behavior toward the person submitting the
comment to change in negative ways.  Such a change requires no
violation of the confidentiality policy because nothing about
the Nomcom's discussion has been disclosed to anyone else.   The
confidentiality rules would not be violated even if the liaison,
on some future date, made comments as part of an IESG review of
some document that comments from the person who had made
comments to the Nomcom should be discounted or that the person
didn't have the IETF's or Internet's best interests as
priorities.

I also want to stress again that the use of "chilling effects"
in my first comment about this was very specific.  I'm far less
concerned about actual bad behavior --within the confidentiality
rules or outside them-- than I am about perceptions,
appearances, and consequential negative impact on the range of
comments and information available to the Nomcom.  My concerns
about bad behavior aren't zero, but they are less significant.
I think avoiding those chilling effects is important enough to
make it worth reviewing, and possibly revising, our expectations
about Nomcom - Liaison interactions and flow of information back
to the Liaisons, not just getting more of those expectations
clarified (which I agree with others is also important).

> Ultimately, we're trying to program the behavior of humans.
> And that's somewhat more difficult than programming the
> behavior of cats.

True, but I think this is a red herring.  I don't think the
confidentiality rules need revising or more policing.  I don't
think anyone needs to be reprogrammed or that doing so is really
feasible.  I do believe that the perception of information flow
back to the liaisons inhibits the NomCom from receiving candid
input that it might otherwise receive and find useful.  And I
believe that situation could be improved by a community decision
to isolate liaisons from candidate-specific input from the
community and documenting that decision -- a change that would
require no [re]programming of humans at all, only some
relatively small changes in Nomcom operational procedures.

>     Maybe we just eliminate the cats and
> eliminate the de jure liaison functions but provide a
> mechanism for the Nomcom to reach out if necessary to the
> origanizations on a more ad hoc basis.

Certainly a plausible alternative.

best,
    john