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

"Adrian Farrel" <adrian@olddog.co.uk> Sun, 29 September 2013 08:19 UTC

Return-Path: <adrian@olddog.co.uk>
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 4A52D21F88FB for <ietf@ietfa.amsl.com>; Sun, 29 Sep 2013 01:19:23 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.465
X-Spam-Level:
X-Spam-Status: No, score=-2.465 tagged_above=-999 required=5 tests=[AWL=-0.022, BAYES_00=-2.599, SUBJECT_FUZZY_TION=0.156]
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 QtvhqJYii8dW for <ietf@ietfa.amsl.com>; Sun, 29 Sep 2013 01:19:17 -0700 (PDT)
Received: from asmtp1.iomartmail.com (asmtp1.iomartmail.com [62.128.201.248]) by ietfa.amsl.com (Postfix) with ESMTP id EB5FD21F958A for <ietf@ietf.org>; Sun, 29 Sep 2013 01:19:12 -0700 (PDT)
Received: from asmtp1.iomartmail.com (localhost.localdomain [127.0.0.1]) by asmtp1.iomartmail.com (8.13.8/8.13.8) with ESMTP id r8T8J41j008241; Sun, 29 Sep 2013 09:19:05 +0100
Received: from 950129200 (dsl-sp-81-140-15-32.in-addr.broadbandscope.com [81.140.15.32]) (authenticated bits=0) by asmtp1.iomartmail.com (8.13.8/8.13.8) with ESMTP id r8T8J3Yo008232 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Sun, 29 Sep 2013 09:19:04 +0100
From: Adrian Farrel <adrian@olddog.co.uk>
To: 'John C Klensin' <john-ietf@jck.com>
References: <21727.1377804292@erosen-linux> <056701cebc9c$43ddea20$cb99be60$@olddog.co.uk> <49B48795E899E5803293CB67@[192.168.1.128]>
In-Reply-To: <49B48795E899E5803293CB67@[192.168.1.128]>
Subject: RE: LC comments on draft-cotton-rfc4020bis-01.txt
Date: Sun, 29 Sep 2013 09:19:03 +0100
Message-ID: <058601cebcec$8f494310$addbc930$@olddog.co.uk>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
X-Mailer: Microsoft Outlook 14.0
Thread-Index: AQIRyVFflXoVAlWm13dSfbaQZWkhFAFDzQa1Aimk4DGZOtkZ4A==
Content-Language: en-gb
Cc: erosen@cisco.com, ietf@ietf.org
X-BeenThere: ietf@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
Reply-To: adrian@olddog.co.uk
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 08:19:23 -0000

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.

> (1) RFC 5226 provides, as you put it, "a good spectrum of
> allocation policies" but a WG (or other entity creating a
> registry) can specify variations on them and, if necessary,
> completely different strategies and methods.  As long as they
> are acceptable to IANA and whatever approving bodies are
> relevant, 5226 is not a closed list.  In particular, more than
> one registry definition process has discovered that the 5226
> language describing the role of a Designated Expert and the
> various publication models are not quite right for their needs.

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.

> (2) We've discovered in several WGs and registries that early
> allocation is just the wrong thing to do, often for reasons that
> overlap some of Eric's concerns.  I don't see that as a problem
> as long as 4020bis remains clear that early allocation is an
> option that one can choose and, if one does, this is how it
> works rather than appearing to recommend its broad use.

Quite true.
This document, therefore requires the WG chairs and the AD to be involved in the
decision to do early allocation.

Adrian