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
- [ietf-nomcom] Experiment in "full transparency" S Moonesamy
- Re: [ietf-nomcom] Experiment in "full transparenc… Salz, Rich
- Re: [ietf-nomcom] Experiment in "full transparenc… Andrew G. Malis
- Re: [ietf-nomcom] Experiment in "full transparenc… Andrew G. Malis
- Re: [ietf-nomcom] Experiment in "full transparenc… Salz, Rich
- Re: [ietf-nomcom] Experiment in "full transparenc… Andrew G. Malis
- Re: [ietf-nomcom] Experiment in "full transparenc… Salz, Rich
- Re: [ietf-nomcom] Experiment in "full transparenc… S Moonesamy
- Re: [ietf-nomcom] Experiment in "full transparenc… John C Klensin
- Re: [ietf-nomcom] Experiment in "full transparenc… James Galvin
- Re: [ietf-nomcom] Experiment in "full transparenc… Salz, Rich
- Re: [ietf-nomcom] Experiment in "full transparenc… Salz, Rich
- Re: [ietf-nomcom] Experiment in "full transparenc… John C Klensin
- Re: [ietf-nomcom] Experiment in "full transparenc… Peter Yee
- Re: [ietf-nomcom] Experiment in "full transparenc… Salz, Rich
- Re: [ietf-nomcom] Experiment in "full transparenc… Stephen Farrell
- Re: [ietf-nomcom] Experiment in "full transparenc… Salz, Rich
- Re: [ietf-nomcom] Experiment in "full transparenc… John C Klensin
- Re: [ietf-nomcom] Experiment in "full transparenc… Stephen Farrell
- Re: [ietf-nomcom] Experiment in "full transparenc… S Moonesamy
- Re: [ietf-nomcom] Experiment in "full transparenc… Stephen Farrell
- Re: [ietf-nomcom] Experiment in "full transparenc… Spencer Dawkins at IETF