Re: NomCom procedures revision
John C Klensin <john-ietf@jck.com> Sat, 29 August 2015 13:52 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 81FE41B2AD7 for <ietf@ietfa.amsl.com>; Sat, 29 Aug 2015 06:52:20 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.91
X-Spam-Level:
X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 Qm9IJ9ZNFd5G for <ietf@ietfa.amsl.com>; Sat, 29 Aug 2015 06:52:19 -0700 (PDT)
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 D0EC11A90E7 for <ietf@ietf.org>; Sat, 29 Aug 2015 06:52:18 -0700 (PDT)
Received: from [198.252.137.10] (helo=JcK-HP8200.jck.com) by bsa2.jck.com with esmtp (Exim 4.82 (FreeBSD)) (envelope-from <john-ietf@jck.com>) id 1ZVgYK-000JIx-4G; Sat, 29 Aug 2015 09:52:16 -0400
Date: Sat, 29 Aug 2015 09:52:11 -0400
From: John C Klensin <john-ietf@jck.com>
To: Joel Halpern <jmh@joelhalpern.com>, 'ietf' <ietf@ietf.org>
Subject: Re: NomCom procedures revision
Message-ID: <8BCE6324E528B2121EFE760F@JcK-HP8200.jck.com>
In-Reply-To: <55E0DC42.2020303@joelhalpern.com>
References: <CAL0qLwYJzFZT=OgWqiiTw-n6mvb3PPusRtArmPs_d4_qpLfmpg@mail.gmail.com> <CADnDZ8_KsNP=_nwp2wrckXtHF8ZSxrQTvf9UKbAMpt68BiiCFA@mail.gmail.c om> <CAL0qLwbhhqG1qoHbBrymPQrU31qjswPAhdeJBqVdRj2L4AR80A@mail.gmail.com> <55E0426A.3000800@alvestrand.no> <55E063DC.3020503@dcrocker.net> <087d01d0e1db$a5b0f6f0$f112e4d0$@olddog.co.uk> <55E0DC42.2020303@joelhalpern.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: <http://mailarchive.ietf.org/arch/msg/ietf/qv239k_MrVn7_f-_HcKd7I2ZLLU>
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: <https://mailarchive.ietf.org/arch/browse/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, 29 Aug 2015 13:52:20 -0000
--On Friday, August 28, 2015 18:10 -0400 Joel Halpern <jmh@joelhalpern.com> wrote: > I was a bit confused by this discussion. By 3777, the chair > establishes the voting procedure. By assumption, he > establishes it before it is needed. > > A sensible chair will establish procedures that the committee > is comfortable with. Since it is the chair who will > administer whatever proecedures are used, it eh committee does > not trust the chair to establsih them, why would the committee > trust the chair to adminsiter them? > > I would hate to have an overly strict rule on voting > procedures, and a couple of nomcom members get into a typical > IETF dispute about the best answer, and thereby hang the work > of the nomcom. > > Why is this being made more complex, with strict priority, > strict rules on adoption, etc? I agree with Joel and would like to, once again, suggest that the IETF seems to have developed a tendency toward solving problems that are extremely uncommon or don't exist at all (perhaps "because we can") and doing so by developing complex and prescriptive rules. We almost never get those rules right, often because Murphy's Law predicts that the next time some set of rules is really needed will be due to some case, or involve some issue, that the rules didn't exactly predict. Instead, let's assume that the leaders, chairs, etc., whom we appoint are competent and responsible adults who will exercise reasonable discretion and make decisions in the best interests of the IETF when that counts. If that assumption turns out to be incorrect, let's try to fix that, rather than seeing if we can transform broad discretion into robot-like rule-driven behavior. So, for me, the right "rule" is "let the Chair decide". If we have to concentrate on cases where that might go wrong, concentrate on whether the mechanisms for the voting (sic) members of the Nomcom can overrule or remove the Chair, not on making the procedures rigid or trying to specify what happens in rare cases. FWIW, I have something of the same reaction toward qualification formulae. Every time we allow an interim meeting and allow it to behave exactly as a f2f one does, including making decisions that will supposedly be ratified on the mailing list; every time we replace rough consensus and discretion with rigid decision rules; and perhaps even every time a Nomcom concludes that it needs to develop and use complex questionnaires for which, inevitably, responses are at least partially a function of how much the candidate (or her company) wants the job, rather than relying on Nomcom member knowledge of the community and who might make the best candidate, we move away from really being able to justify the assumption that attending a bunch of meetings is the only reasonable qualification for serving on the Nomcom --no matter how those meetings are counted. As some who, like Brian, is doing a significant percentage of meetings remotely but who has enough background and ongoing involvement with the IETF that I think I have at least as much perspective as a relative newcomer who has attended a year's worth of meetings but never written an I-D, chaired a WG, or really contributed to a discussion, I'm coming to the conclusion that it is at least as important to have active participants with recent remote participation experience on the Nomcom (and probably on the IESG) as it is to have participants with recent meeting experience. The kind of adjustments Brian and others have suggested may help, but I think the real issue is that we need not just to allow for fewer recent f2f meetings but to consider remote participation experience a real asset (while, ideally, pushing back on Nomcom membership by what Marshall Rose referred to a Go-ers, rather than Do-ers, no matter how many f2f (or remote) meetings they attend. best, john
- NomCom procedures revision Murray S. Kucherawy
- Re: NomCom procedures revision Joe Hildebrand
- Re: NomCom procedures revision Murray S. Kucherawy
- Re: NomCom procedures revision Randy Bush
- Re: NomCom procedures revision Abdussalam Baryun
- Re: NomCom procedures revision Murray S. Kucherawy
- Re: NomCom procedures revision Harald Alvestrand
- Re: NomCom procedures revision Dave Crocker
- Re: NomCom procedures revision Tony Hansen
- Re: NomCom procedures revision Brian E Carpenter
- RE: NomCom procedures revision Adrian Farrel
- Re: NomCom procedures revision Joel Halpern
- Re: NomCom procedures revision Mary Barnes
- Re: NomCom procedures revision Loa Andersson
- Re: NomCom procedures revision John C Klensin
- Re: NomCom procedures revision Brian E Carpenter
- Re: NomCom procedures revision Lixia Zhang
- Re: NomCom procedures revision John C Klensin
- Re: NomCom procedures revision Harald Alvestrand
- Re: NomCom procedures revision Brian E Carpenter
- Re: NomCom procedures revision John C Klensin
- Re: NomCom procedures revision Brian E Carpenter
- Re: NomCom procedures revision Murray S. Kucherawy
- Re: NomCom procedures revision Brian E Carpenter
- Re: NomCom procedures revision Melinda Shore
- Re: NomCom procedures revision Samuel Weiler