Re: Updating BCP 10 -- NomCom ELEGIBILITY

John C Klensin <john-ietf@jck.com> Fri, 09 January 2015 22:10 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 371561A0076 for <ietf@ietfa.amsl.com>; Fri, 9 Jan 2015 14:10:37 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.61
X-Spam-Level:
X-Spam-Status: No, score=-2.61 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, 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 YE1r4Ujf9ExR for <ietf@ietfa.amsl.com>; Fri, 9 Jan 2015 14:10:35 -0800 (PST)
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 27CDA1A0039 for <ietf@ietf.org>; Fri, 9 Jan 2015 14:10:35 -0800 (PST)
Received: from [198.252.137.35] (helo=JcK-HP8200.jck.com) by bsa2.jck.com with esmtp (Exim 4.82 (FreeBSD)) (envelope-from <john-ietf@jck.com>) id 1Y9hlJ-000Lqs-4P; Fri, 09 Jan 2015 17:10:33 -0500
Date: Fri, 09 Jan 2015 17:10:22 -0500
From: John C Klensin <john-ietf@jck.com>
To: Michael Richardson <mcr+ietf@sandelman.ca>, ietf <ietf@ietf.org>
Subject: Re: Updating BCP 10 -- NomCom ELEGIBILITY
Message-ID: <C16511B20BECBD8B66C19316@JcK-HP8200.jck.com>
In-Reply-To: <9772.1420830216@sandelman.ca>
References: <CAL0qLwZk=k-CWLte_ChK9f1kzLwMOTRyi7AwFa8fLjBsextBcA@mail.gmail.com> <9772.1420830216@sandelman.ca>
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.35
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/cHCbdBTJxLOZ8GYmpVKCapeZjNQ>
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: Fri, 09 Jan 2015 22:10:37 -0000


--On Friday, January 09, 2015 14:03 -0500 Michael Richardson
<mcr+ietf@sandelman.ca> wrote:

>...
> I don't think SM's proposal does the right thing.
> My concern is primarily about people who enter our culture,
> and then for some reason are unable to travel. (Could be
> health, could be inability to get VISAs, could be funding,
> could be children) 
> 
> So I would keep the 3/5 in-person meetings to *become* nomcom 
> eligible.  
> 
> Once eligible, the rules for remaining eligible would be
> different. I would propose something like having *contributed*
> to at least two meetings in the past four.  We could come up
> with complex or simple rules on what it means to contribute,
> we could automated it, and we can discuss all the ways that
> various rules could be gamed. My ideas for contribution would
> include:
>...

I like this.  A lot.

> 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 we aren't ready to
formulate a good rule.  I've also suggested before that, if
someone is going to participate remotely, rather than
attending/lurking remotely, we really need to have them
registered for one of the same reasons we require attendees to
register -- knowing who is influencing standards development is
an important part of an open standardization process and just
can't be done remotely.  But we haven't done that, so the "not
ready" part of your comment is correct.

Let me suggest another way to deal with that combination of
conclusions, which is, IMO, consistent with the above and part
of Stephen's ideas/comments.  Let's assume in this revision
that, longer-term, there may be multiple ways to become Nomcom
eligible, not just a single formula.  Let's adopt something like
your "become eligible and retain eligible" formulation as method
#1.   Then let's be sure that the document can be "updated" by
some possible future thing that lays out remote participation
rules and conventions (again, I don't care about lurkers and
personally think we need to preserve the ability to lurk
anonymously) by specifying criteria for _them_ to be Nomcom
eligible.   

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.

    john