Re: Updating BCP 10 -- NomCom ELEGIBILITY

John C Klensin <john-ietf@jck.com> Fri, 09 January 2015 23:47 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 175801A1AEC for <ietf@ietfa.amsl.com>; Fri, 9 Jan 2015 15:47:31 -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 H7NeXEE91zvr for <ietf@ietfa.amsl.com>; Fri, 9 Jan 2015 15:47:29 -0800 (PST)
Received: from bsa2.jck.com (bsa2.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 84FDD1A008F for <ietf@ietf.org>; Fri, 9 Jan 2015 15:47:29 -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 1Y9jH2-000M2f-IC; Fri, 09 Jan 2015 18:47:24 -0500
Date: Fri, 09 Jan 2015 18:47:13 -0500
From: John C Klensin <john-ietf@jck.com>
To: Stephen Farrell <stephen.farrell@cs.tcd.ie>, Michael Richardson <mcr+ietf@sandelman.ca>, ietf <ietf@ietf.org>
Subject: Re: Updating BCP 10 -- NomCom ELEGIBILITY
Message-ID: <88F7D1E537E92B5DF73DAAA1@JcK-HP8200.jck.com>
In-Reply-To: <54B0552F.7030500@cs.tcd.ie>
References: <CAL0qLwZk=k-CWLte_ChK9f1kzLwMOTRyi7AwFa8fLjBsextBcA@mail.gmail.com> <9772.1420830216@sandelman.ca> <C16511B20BECBD8B66C19316@JcK-HP8200.jck.com> <54B0552F.7030500@cs.tcd.ie>
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/zEVjMdm_KUp0OuPqGtwa6P-PlKs>
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 23:47:31 -0000


--On Friday, January 09, 2015 22:24 +0000 Stephen Farrell
<stephen.farrell@cs.tcd.ie> 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