Re: Updating BCP 10 -- NomCom ELEGIBILITY

Stephen Farrell <stephen.farrell@cs.tcd.ie> Fri, 09 January 2015 22:24 UTC

Return-Path: <stephen.farrell@cs.tcd.ie>
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 11EC01A0277 for <ietf@ietfa.amsl.com>; Fri, 9 Jan 2015 14:24:54 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.91
X-Spam-Level:
X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, 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 ZIPRfE6UzH1X for <ietf@ietfa.amsl.com>; Fri, 9 Jan 2015 14:24:51 -0800 (PST)
Received: from mercury.scss.tcd.ie (mercury.scss.tcd.ie [134.226.56.6]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id F2D3D1A0193 for <ietf@ietf.org>; Fri, 9 Jan 2015 14:24:50 -0800 (PST)
Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id 33D8FBF12; Fri, 9 Jan 2015 22:24:49 +0000 (GMT)
X-Virus-Scanned: Debian amavisd-new at scss.tcd.ie
Received: from mercury.scss.tcd.ie ([127.0.0.1]) by localhost (mercury.scss.tcd.ie [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6it5lTZcP6PR; Fri, 9 Jan 2015 22:24:48 +0000 (GMT)
Received: from [10.87.48.73] (unknown [86.46.19.241]) by mercury.scss.tcd.ie (Postfix) with ESMTPSA id 2124EBEBB; Fri, 9 Jan 2015 22:24:48 +0000 (GMT)
Message-ID: <54B0552F.7030500@cs.tcd.ie>
Date: Fri, 09 Jan 2015 22:24:47 +0000
From: Stephen Farrell <stephen.farrell@cs.tcd.ie>
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.3.0
MIME-Version: 1.0
To: John C Klensin <john-ietf@jck.com>, Michael Richardson <mcr+ietf@sandelman.ca>, ietf <ietf@ietf.org>
Subject: Re: Updating BCP 10 -- NomCom ELEGIBILITY
References: <CAL0qLwZk=k-CWLte_ChK9f1kzLwMOTRyi7AwFa8fLjBsextBcA@mail.gmail.com> <9772.1420830216@sandelman.ca> <C16511B20BECBD8B66C19316@JcK-HP8200.jck.com>
In-Reply-To: <C16511B20BECBD8B66C19316@JcK-HP8200.jck.com>
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit
Archived-At: <http://mailarchive.ietf.org/arch/msg/ietf/Jzk5OzqzEiPahwvvYOarOGUy5qY>
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:24:54 -0000


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).

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.

S.