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
>
>