Re: Updating BCP 10 -- NomCom ELEGIBILITY

Loa Andersson <> Sat, 10 January 2015 03:53 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id 2B5871A7D80 for <>; Fri, 9 Jan 2015 19:53:40 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.91
X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, T_RP_MATCHES_RCVD=-0.01] autolearn=ham
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id AaKKkPL5FaG0 for <>; Fri, 9 Jan 2015 19:53:37 -0800 (PST)
Received: from ( []) (using TLSv1.1 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id CE0AC1A7D81 for <>; Fri, 9 Jan 2015 19:53:36 -0800 (PST)
Received: from [] (unknown []) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) (Authenticated sender: by (Postfix) with ESMTPSA id EDFCD180159D for <>; Sat, 10 Jan 2015 04:53:33 +0100 (CET)
Message-ID: <>
Date: Sat, 10 Jan 2015 11:53:29 +0800
From: Loa Andersson <>
User-Agent: Mozilla/5.0 (Windows NT 6.2; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.3.0
MIME-Version: 1.0
Subject: Re: Updating BCP 10 -- NomCom ELEGIBILITY
References: <> <> <> <> <>
In-Reply-To: <>
Content-Type: text/plain; charset=windows-1252; format=flowed
Content-Transfer-Encoding: 7bit
Archived-At: <>
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: IETF-Discussion <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Sat, 10 Jan 2015 03:53:40 -0000


My concern about "remote" is not so much about elegibility, as if we
actually require that the NomCom members attend the meetings while they
are on the NomCom. Maybe "require" in that sentence should be "strongle
expect", but you get my drift.


On 2015-01-10 07:47, John C Klensin wrote:
> --On Friday, January 09, 2015 22:24 +0000 Stephen Farrell
> <> wrote:
>> On 09/01/15 22:10, John C Klensin wrote:
>>> 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.
>> Even if an update to the BCP were needed, I'd still like
>> this idea. And I guess someone could just write an I-D
>> that updates section x.y.z only.
>> My concern is only that x.y.z could get out of date quickly
>> in the next few years if (as I hope) we get better and
>> better at the remote thing (and not having been in Hawaii,
>> that was better than I expected, though hardly any fun
>> at all).
> Having done several meetings remotely in the last few years, in
> at least two of which I had to play a leadership role (most
> recently that of a remote WG co-chair), I think it is getting
> better rather quickly.  I would also agree with "no fun at all"
> and suggest that there have been enough nasty glitches that we
> are going to need to keep paying attention to the subject,
> practicing, and learning what works and doesn't as we go along.
>> But probably better to figure out what continued eligibilty
>> rules we'd like now, and then think about how those might
>> evolve before we write x.y.z. At that point we should know
>> better if my concern is worth worrying about or not.
> I think we are on the same page or close to it.
> The other remote participation issue that would need to be
> sorted out for Nomcom eligibility and service is that my
> impression is that the Nomcom depends a lot on f2f or at least
> on having enough members present at key meetings to staff
> interviews, etc.  "Has been participating remotely, but can
> promise to physically attend several meetings in a row if
> selected" would be a rather different requirement from "Has been
> participating remotely and intends to participate remotely in
> the Nomcom".  Michael and others who have been more directly
> involved might want to reflect on that difference and the
> feasibility of the second, but that might evolve with remote
> participation arrangements too and I'm pretty sure we aren't
> ready to make decisions about it now.
>      john


Loa Andersson                        email:
Senior MPLS Expert                
Huawei Technologies (consultant)     phone: +46 739 81 21 64