RE: LC comments on draft-cotton-rfc4020bis-01.txt

John C Klensin <john-ietf@jck.com> Sun, 29 September 2013 12:00 UTC

Return-Path: <john-ietf@jck.com>
X-Original-To: ietf@ietfa.amsl.com
Delivered-To: ietf@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E0A5921F9AFE for <ietf@ietfa.amsl.com>; Sun, 29 Sep 2013 05:00:28 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -103.269
X-Spam-Level:
X-Spam-Status: No, score=-103.269 tagged_above=-999 required=5 tests=[AWL=0.174, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, SUBJECT_FUZZY_TION=0.156, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KzFy9cRBgWbq for <ietf@ietfa.amsl.com>; Sun, 29 Sep 2013 05:00:23 -0700 (PDT)
Received: from bsa2.jck.com (ns.jck.com [70.88.254.51]) by ietfa.amsl.com (Postfix) with ESMTP id ECF7421F9A3B for <ietf@ietf.org>; Sun, 29 Sep 2013 05:00:20 -0700 (PDT)
Received: from localhost ([::1]) by bsa2.jck.com with esmtp (Exim 4.71 (FreeBSD)) (envelope-from <john-ietf@jck.com>) id 1VQFfd-000EQP-BL; Sun, 29 Sep 2013 08:00:17 -0400
X-Vipre-Scanned: 03323741002C310332388E-TDI
Date: Sun, 29 Sep 2013 08:00:16 -0400
From: John C Klensin <john-ietf@jck.com>
To: adrian@olddog.co.uk
Subject: RE: LC comments on draft-cotton-rfc4020bis-01.txt
Message-ID: <6F5019CA89A41031E63D7F23@[192.168.1.128]>
In-Reply-To: <058601cebcec$8f494310$addbc930$@olddog.co.uk>
References: <21727.1377804292@erosen-linux> <056701cebc9c$43ddea20$cb99be60$@olddog.co.uk> <49B48795E899E5803293CB67@[192.168.1.128]> <058601cebcec$8f494310$addbc930$@olddog.co.uk>
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
Cc: erosen@cisco.com, ietf@ietf.org
X-BeenThere: ietf@ietf.org
X-Mailman-Version: 2.1.12
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: Sun, 29 Sep 2013 12:00:29 -0000

--On Sunday, 29 September, 2013 09:19 +0100 Adrian Farrel
<adrian@olddog.co.uk> wrote:

> Hi John,
> 
> Thanks for the additions.
> 
>> Everything you say seems fine to me for the cases you are
>> focusing on, but I hope that any changes to 4020bis keep two
>> things in mind lest we find ourselves tangled in rules and
>> prohibiting some reasonable behavior (a subset of which is
>> used now).
> 
> 4020bis is certainly not intended to prohibit actions we do
> now. AFAICS it actually opens up more scope for early
> allocation that was not there before.
>...
> I am pretty sure that nothing in this document impacts on 5226
> at all except to define how early allocation works for certain
> allocation policies defined by 5226. You are correct that 5226
> is not a closed list. However we may observe that it is used
> in the significant majority of cases. I think that means that
> if some non-5226 policy is agreed by a WG and "the relevant
> approving bodies" together with IANA, then that policy needs
> to define its own early allocaiton procedure if one is wanted.
>...
> This document, therefore requires the WG chairs and the AD to
> be involved in the decision to do early allocation.

That was how I read the current version, so we are on the same
page.  Eric's note was considerably wider-ranging so, at you and
Michelle work on revisions, I just wanted to caution against
accidentally going too far in a direction that could be
construed as changing other things.   

>From my point of view, it would be a good thing to further
emphasize that a code point, once allocated through any process,
is, in a lot of cases, unlikely to be usable in the future for
anything else.   That is largely independent of whether the
allocation is identified as "early", "preliminary",
"provisional", "easy", or "final".  The current version is, I
think, good enough about that, but better would be, well, better.

thanks,
    john