Re: NomCom procedures revision

Brian E Carpenter <brian.e.carpenter@gmail.com> Sun, 30 August 2015 21:20 UTC

Return-Path: <brian.e.carpenter@gmail.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 B57591AC3AB for <ietf@ietfa.amsl.com>; Sun, 30 Aug 2015 14:20:52 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2
X-Spam-Level:
X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=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 GbAfVmj37Ac7 for <ietf@ietfa.amsl.com>; Sun, 30 Aug 2015 14:20:51 -0700 (PDT)
Received: from mail-pa0-x229.google.com (mail-pa0-x229.google.com [IPv6:2607:f8b0:400e:c03::229]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 197CA1A92FC for <ietf@ietf.org>; Sun, 30 Aug 2015 14:20:51 -0700 (PDT)
Received: by pabzx8 with SMTP id zx8so116685169pab.1 for <ietf@ietf.org>; Sun, 30 Aug 2015 14:20:50 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=subject:to:references:from:organization:message-id:date:user-agent :mime-version:in-reply-to:content-type:content-transfer-encoding; bh=iV7MrScjIuMNZ3HCgi2Fn6nFRohHVxuuYZPrT52A2dM=; b=vRCz4s1fHASrhyTyxKZ+fPXbzQnwqFFhxyTLhvh8mo568ONFYD4Z/EiseZtY+sfa2G m1sq7MhdJPqQNkZj4KvW+RUuTzmV969fBpEphwDP838LALC8fAWA+uvWgmw/1/u9KVkr 4ybzhYBnSMz1q4cSyskSaCXztiHD69+Q2wdtu0lgNrClBtiVEd1n9LA69qTpzFhXbihl UMbHqwh8mJe2wM+C6VvtjQhXavloi5ZKh4GQamuaKUncpyOkFzAp8pHsq5uipuXs9dsE fi2/d0yI1Ts7w/zuMciBvXAAT7kFf1cZUPlzuMf791MvJ7GSslXGFE4BdTOJHZgtBDRh pJ7w==
X-Received: by 10.66.190.168 with SMTP id gr8mr32663402pac.22.1440969650702; Sun, 30 Aug 2015 14:20:50 -0700 (PDT)
Received: from [172.27.6.155] ([131.203.238.122]) by smtp.gmail.com with ESMTPSA id df2sm12237057pad.19.2015.08.30.14.20.47 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Sun, 30 Aug 2015 14:20:49 -0700 (PDT)
Subject: Re: NomCom procedures revision
To: John C Klensin <john-ietf@jck.com>, ietf <ietf@ietf.org>
References: <CAL0qLwYJzFZT=OgWqiiTw-n6mvb3PPusRtArmPs_d4_qpLfmpg@mail.gmail.com> <55E0D5E5.6030802@gmail.com> <55E1714C.6070602@pi.nu> <55E21442.3030008@gmail.com> <46DC3DDD2AB9558580D99D5B@JcK-HP8200.jck.com>
From: Brian E Carpenter <brian.e.carpenter@gmail.com>
Organization: University of Auckland
Message-ID: <55E373AE.9040705@gmail.com>
Date: Mon, 31 Aug 2015 09:20:46 +1200
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.2.0
MIME-Version: 1.0
In-Reply-To: <46DC3DDD2AB9558580D99D5B@JcK-HP8200.jck.com>
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit
Archived-At: <http://mailarchive.ietf.org/arch/msg/ietf/XFGJAFK_BERZX9_Ng3MFxrpowfk>
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: Sun, 30 Aug 2015 21:20:52 -0000

On 30/08/2015 11:05, John C Klensin wrote:
> 
> 
> --On Sunday, August 30, 2015 08:21 +1200 Brian E Carpenter
> <brian.e.carpenter@gmail.com> wrote:
> 
>> ...
>> I'm sympathetic to both your points, but I'm also keen to keep
>> the rule as simple as possible, for various reasons (especially
>> simplicity in verification).
>>
>> One way out is to decouple this question from RFC7437bis by
>> designing an RFC3933 Process Experiment (i.e. try out an
>> alternative qualification rule for a couple of years,
>> reverting to the current rule afterwards by default).
> 
> This may be too radical but, in the spirit of allowing people to
> apply discretion, let me success such a process experiment based
> on the principle that the reason for Nomcom-volunteer
> qualification rules is to be sure that the selecting members of
> the Nomcom have a reasonable understanding of the IETF and how
> it works.   For the purpose of this experiment, 
> 
> (1) Anyone meeting the current requirements is automatically
> qualified to volunteer, just as they are today.
> 
> (2) Anyone inclined to serve on the Nomcom and willing to meet
> whatever requirements for attendance and participation during
> the Nomcom's term apply for the Nomcom of interest may submit
> his or her name and a very brief statement of qualifications
> (or, more specifically, why they believe they are qualified) to
> the Nomcom Chair.   The Chair and previous Chair will consider
> all such applications and may, based on their personal
> discretion and the "reasonable understanding" principle may be
> added to the volunteer pool.  When the Chair publishes the list
> of volunteers, those who submitted a statement of qualifications
> will be included along with their statements and the decision of
> the Chair and prior Chair.  Egregiously silly decisions may be
> objected to following the usual procedures.
> 
> That experimental model has three important properties: it
> involves no new filtering rules, it may allow some people onto
> the Nomcom whom everyone would agree have an adequate knowledge
> of the IETF but who do not qualify on meeting counts alone, and
> it allows us to accumulate information about who actually
> volunteers and asks for an exception and what their claimed
> qualifications are.  Put differently, it may help us tell
> whether we have an actual problem or only a theoretical one.

I decided to sleep on it, and the result is that I'm quite attracted
by this idea. Maybe we should have three "gatekeepers" instead of
two, but since the random selection process makes the final cut,
it doesn't seem that personal bias could be a major factor anyway.

We could add a list of *suggested* criteria such as RFC authorship,
active WG contributions, remote participation.

    Brian