Re: [ietf-nomcom] Experiment in "full transparency"

John C Klensin <john-ietf@jck.com> Mon, 23 October 2017 23:17 UTC

Return-Path: <john-ietf@jck.com>
X-Original-To: ietf-nomcom@ietfa.amsl.com
Delivered-To: ietf-nomcom@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F2D8B13AC9E for <ietf-nomcom@ietfa.amsl.com>; Mon, 23 Oct 2017 16:17:22 -0700 (PDT)
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] autolearn=ham autolearn_force=no
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 6GKy7IuAHvDO; Mon, 23 Oct 2017 16:17:20 -0700 (PDT)
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 3065A13AB3E; Mon, 23 Oct 2017 16:17:20 -0700 (PDT)
Received: from [198.252.137.10] (helo=PSB) by bsa2.jck.com with esmtp (Exim 4.82 (FreeBSD)) (envelope-from <john-ietf@jck.com>) id 1e6lyA-000L6D-Qe; Mon, 23 Oct 2017 19:17:18 -0400
Date: Mon, 23 Oct 2017 19:17:11 -0400
From: John C Klensin <john-ietf@jck.com>
To: "Salz, Rich" <rsalz@akamai.com>
cc: NomComDiscussion <ietf-nomcom@ietf.org>, NomCom Chair 2017 <nomcom-chair-2017@ietf.org>
Message-ID: <70A26384995DDC19DC8E2CAC@PSB>
In-Reply-To: <5BDAF4B0-FE20-4940-B436-683209FAC9C9@akamai.com>
References: <6.2.5.6.2.20171016135236.12dcaa60@elandnews.com> <3E158B61-DCF7-485C-B350-DA14B2B8CBDA@akamai.com> <CAA=duU0aiLUzZAP3vmS2tTzxEinzc4hA0UFpd3_dprkjDHnqkg@mail.gmail.com> <FF365C9F-6CE1-41A5-82BB-F15CFB748492@akamai.com> <CAA=duU2k+8-+M2vj5Tk_czJA_VL0ZJ8Z8xhpo0zqu-JqY7mWNQ@mail.gmail.com> <8CB73C9E-9BF2-4252-A98A-D5AA1FE597DC@akamai.com> <DE6132DBB7813E23C606B56B@PSB> <5BDAF4B0-FE20-4940-B436-683209FAC9C9@akamai.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.10
X-SA-Exim-Mail-From: john-ietf@jck.com
X-SA-Exim-Scanned: No (on bsa2.jck.com); SAEximRunCond expanded to false
Archived-At: <https://mailarchive.ietf.org/arch/msg/ietf-nomcom/N_i2AzMLh-xby2S1BOBuqIwHtLc>
Subject: Re: [ietf-nomcom] Experiment in "full transparency"
X-BeenThere: ietf-nomcom@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: Discussions of possible revisions to the NomCom process <ietf-nomcom.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/ietf-nomcom>, <mailto:ietf-nomcom-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/ietf-nomcom/>
List-Post: <mailto:ietf-nomcom@ietf.org>
List-Help: <mailto:ietf-nomcom-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ietf-nomcom>, <mailto:ietf-nomcom-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 23 Oct 2017 23:17:23 -0000


--On Monday, October 23, 2017 20:07 +0000 "Salz, Rich"
<rsalz@akamai.com> wrote:

> John,
> 
> Thanks for the detailed and thoughtful response.
> 
>        "There is probably a good balance among those points of
> view, but I believe it is one the community should be
> discussing in an open way that addresses the actual choices,
> not by tweaking Nomcom membership without thinking through the
> likely consequences."
> 
> Yes.  I would like to help address this.  A bar BoF at 100, a
> real BoF at 101?  Thoughts on how to move forward?

While I tried to write a note that was as balanced as possible,
I've actually got strong opinions on the subject (including
questions you didn't raise) and so might not be the best person
to ask.  

In particular, I'd like to hear from Peter (explicitly copied in
case he isn't following the list) 

(a) what he and this year's Nomcom intend to do to allow
comments about how assorted bodies are working as a whole and
how particular appointments (or retirements) might affect that,
including advice about what criteria the Nomcom should use in
its  deliberations, and 
(b) how those comments and others that might reflect on liaisons
or other incumbent can be adequately secured to protect those
who make the comments from retaliation and other adverse
behavior.

In addition, there is a question that is much broader than the
issues you have raised.   The Nomcom model was designed at a
time when we could reasonably predict that most plausible
candidates would be personally known to a large fraction of the
Nomcom members and we could also predict that the volunteers for
the Nomcom would represent a good cross-section of the people
who were actually actively contributing to the IETF.   Obviously
if the Nomcom volunteer pool doesn't represent a good
cross-section of those doing work in the IETF, the random
selection process is statistically unlikely to yield such a
cross-section either.  It is fairly clear that, as the IETF has
evolved, the first assumption is no longer correct.   Many of us
believe the second isn't either.

There is an additional problem, which is that we have an
increasing number of active remote participants who are not only
not eligible to volunteer for the Nomcom but who are typically
not represented on it by people with similar concerns.  If, for
example, we had an IESG or IAOC candidate who was opposed to
either remote participation or to making adjustments needed to
make it work well (I am aware of no such candidates; if I were,
I'd find another example), it would be important, not just to
point that issue out to the Nomcom but for there to be someone
on the Nomcom to advocate for the importance of that as an issue
to be considered.   

In a way, that is just a generalization of your argument for
more liaisons and/or specially-appointed Nomcom members and
giving at least some of them a vote.   But it, and I think your
reasoning, also suggest that the IETF is no longer homogeneous
enough that random selection from a single Nomcom volunteer pool
is serving us well any more... and that argues for reconsidering
the whole process and model, not a discussion of incremental
patches.

best,
    john


So I have to