Re: Updating BCP 10 -- NomCom ELEGIBILITY

Michael Richardson <mcr@sandelman.ca> Sat, 10 January 2015 23:37 UTC

Return-Path: <mcr@sandelman.ca>
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 C82A31A0231 for <ietf@ietfa.amsl.com>; Sat, 10 Jan 2015 15:37:56 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.911
X-Spam-Level:
X-Spam-Status: No, score=-1.911 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001, 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 Qt4r7B8HomPv for <ietf@ietfa.amsl.com>; Sat, 10 Jan 2015 15:37:55 -0800 (PST)
Received: from tuna.sandelman.ca (tuna.sandelman.ca [209.87.249.19]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 14EAB1A0076 for <ietf@ietf.org>; Sat, 10 Jan 2015 15:37:55 -0800 (PST)
Received: from sandelman.ca (obiwan.sandelman.ca [IPv6:2607:f0b0:f:2::247]) by tuna.sandelman.ca (Postfix) with ESMTP id EB5102002A for <ietf@ietf.org>; Sat, 10 Jan 2015 18:43:28 -0500 (EST)
Received: by sandelman.ca (Postfix, from userid 179) id 57E4F637FE; Sat, 10 Jan 2015 18:37:54 -0500 (EST)
Received: from sandelman.ca (localhost [127.0.0.1]) by sandelman.ca (Postfix) with ESMTP id 4230363745 for <ietf@ietf.org>; Sat, 10 Jan 2015 18:37:54 -0500 (EST)
From: Michael Richardson <mcr@sandelman.ca>
To: ietf <ietf@ietf.org>
Subject: Re: Updating BCP 10 -- NomCom ELEGIBILITY
In-Reply-To: <C16511B20BECBD8B66C19316@JcK-HP8200.jck.com>
References: <CAL0qLwZk=k-CWLte_ChK9f1kzLwMOTRyi7AwFa8fLjBsextBcA@mail.gmail.com> <9772.1420830216@sandelman.ca> <C16511B20BECBD8B66C19316@JcK-HP8200.jck.com>
X-Mailer: MH-E 8.6; nmh 1.3-dev; GNU Emacs 24.4.2
X-Face: $\n1pF)h^`}$H>Hk{L"x@)JS7<%Az}5RyS@k9X%29-lHB$Ti.V>2bi.~ehC0; <'$9xN5Ub# z!G,p`nR&p7Fz@^UXIn156S8.~^@MJ*mMsD7=QFeq%AL4m<nPbLgmtKK-5dC@#:k
Date: Sat, 10 Jan 2015 18:37:54 -0500
Message-ID: <2280.1420933074@sandelman.ca>
Sender: mcr@sandelman.ca
Archived-At: <http://mailarchive.ietf.org/arch/msg/ietf/4OIm74igsJdtfKIETtn_fh-exkk>
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: <http://www.ietf.org/mail-archive/web/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, 10 Jan 2015 23:37:56 -0000

John C Klensin <john-ietf@jck.com> wrote:
    >> Note that I have avoided counting "remote attendance" activities
    >> specifically, because that would require us to figure out who attended
    >> and register them, etc. and I don't think we are ready for that yet.

    > I am very sympathetic to (my interpretation of) SM's concern that there
    > are people who participate sufficiently remotely that it is clear that
    > the have more knowledge of the type one would like on the Nomcom then
    > lots of community members who are eligible under the 3/5 in person
    > rule.  I agree with you that his formulation isn't quite right and that

Note: it is really impossible at this stage of remote attendance for nomcom
      to operate with more than 1 remote selecting member.  In effect, all
      of the interviewers really have got to be at the Third Meeting in
      person. (And it's not just about technology, it's also about time
      zones and informal dinners, and all the other things that our
      technology fails at.)
      So the person who is always remote, makes a very poor nomcom member.

    > Where I disagree with Stephen is that I don't want bodies who have
    > members selected by the Nomcom to be able to specific Nomcom membership
    > criteria or to delegate that job to some purpose-specific committee.
    > Even if the actual risks are low, the optics are terrible and the
    > normal community consensus procedures should be involved.  But maybe
    > requiring an update to the BCP but avoiding a requirement to open the
    > base specification would respond to part --I think the most important
    > part, but he may disagree-- of that concern.

So I avoided mentioning remote attendance at all for the simple reason that I
think that when we figure it out, and start registering (some?) people, that
we would absolutely need to put out an UPDATES BCP about it.

So, I think we are in complete agreement; I wonder who objects and why?

-- 
]               Never tell me the odds!                 | ipv6 mesh networks [ 
]   Michael Richardson, Sandelman Software Works        | network architect  [ 
]     mcr@sandelman.ca  http://www.sandelman.ca/        |   ruby on rails    [