Re: NomCom procedures revision
Joel Halpern <jmh@joelhalpern.com> Fri, 28 August 2015 22:10 UTC
Return-Path: <jmh@joelhalpern.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 3832B1B2E51 for <ietf@ietfa.amsl.com>; Fri, 28 Aug 2015 15:10:14 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.602
X-Spam-Level:
X-Spam-Status: No, score=-2.602 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] 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 NJ28qVgJ6mzv for <ietf@ietfa.amsl.com>; Fri, 28 Aug 2015 15:10:13 -0700 (PDT)
Received: from maila2.tigertech.net (maila2.tigertech.net [208.80.4.152]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 299E11B2E4A for <ietf@ietf.org>; Fri, 28 Aug 2015 15:10:13 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1]) by maila2.tigertech.net (Postfix) with ESMTP id B8282240445; Fri, 28 Aug 2015 15:10:12 -0700 (PDT)
X-Virus-Scanned: Debian amavisd-new at maila2.tigertech.net
Received: from Joels-MacBook-Pro.local (209-255-163-147.ip.mcleodusa.net [209.255.163.147]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by maila2.tigertech.net (Postfix) with ESMTPSA id 563BD2403A9; Fri, 28 Aug 2015 15:10:12 -0700 (PDT)
Subject: Re: NomCom procedures revision
To: 'ietf' <ietf@ietf.org>
References: <CAL0qLwYJzFZT=OgWqiiTw-n6mvb3PPusRtArmPs_d4_qpLfmpg@mail.gmail.com> <CADnDZ8_KsNP=_nwp2wrckXtHF8ZSxrQTvf9UKbAMpt68BiiCFA@mail.gmail.com> <CAL0qLwbhhqG1qoHbBrymPQrU31qjswPAhdeJBqVdRj2L4AR80A@mail.gmail.com> <55E0426A.3000800@alvestrand.no> <55E063DC.3020503@dcrocker.net> <087d01d0e1db$a5b0f6f0$f112e4d0$@olddog.co.uk>
From: Joel Halpern <jmh@joelhalpern.com>
Message-ID: <55E0DC42.2020303@joelhalpern.com>
Date: Fri, 28 Aug 2015 18:10:10 -0400
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:38.0) Gecko/20100101 Thunderbird/38.2.0
MIME-Version: 1.0
In-Reply-To: <087d01d0e1db$a5b0f6f0$f112e4d0$@olddog.co.uk>
Content-Type: text/plain; charset="utf-8"; format="flowed"
Content-Transfer-Encoding: 7bit
Archived-At: <http://mailarchive.ietf.org/arch/msg/ietf/b7rDaxd6KxWmJd4y0uYKgmD22l8>
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: Fri, 28 Aug 2015 22:10:14 -0000
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? Yours, Joel On 8/28/15 5:51 PM, Adrian Farrel wrote: >> On 8/28/2015 4:13 AM, Harald Alvestrand wrote: >>> Once established, this procedure >>> cannot be altered until the current nominating committee is >>> dissolved. >>> >>> A) It turns out that voting mechanisms are *tricky* beasts. The idea >>> that a nomcom will make them 100% right on the first try is a Bad Idea. >> >> That assertion would seem to run contrary to the process rigidity you >> are proposing above. > > Indeed. > One would hope that a NomCom that discovers it is really unhappy with its voting mechanism can use exactly that voting mechanism to agree to make changes. > > Adrian > >
- 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