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

John C Klensin <john-ietf@jck.com> Sun, 29 September 2013 00:36 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 C037B21E813C for <ietf@ietfa.amsl.com>; Sat, 28 Sep 2013 17:36:44 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -103.211
X-Spam-Level:
X-Spam-Status: No, score=-103.211 tagged_above=-999 required=5 tests=[AWL=0.232, 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 EIgz5qcl+lzR for <ietf@ietfa.amsl.com>; Sat, 28 Sep 2013 17:36:36 -0700 (PDT)
Received: from bsa2.jck.com (ns.jck.com [70.88.254.51]) by ietfa.amsl.com (Postfix) with ESMTP id 52B6221E8132 for <ietf@ietf.org>; Sat, 28 Sep 2013 17:36:36 -0700 (PDT)
Received: from localhost ([::1]) by bsa2.jck.com with esmtp (Exim 4.71 (FreeBSD)) (envelope-from <john-ietf@jck.com>) id 1VQ4zu-000C9o-4U; Sat, 28 Sep 2013 20:36:30 -0400
X-Vipre-Scanned: 00C02FA5002C3100C030F2-TDI
Date: Sat, 28 Sep 2013 20:36:28 -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: <49B48795E899E5803293CB67@[192.168.1.128]>
In-Reply-To: <056701cebc9c$43ddea20$cb99be60$@olddog.co.uk>
References: <21727.1377804292@erosen-linux> <056701cebc9c$43ddea20$cb99be60$@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 00:36:44 -0000

--On Saturday, 28 September, 2013 23:44 +0100 Adrian Farrel
<adrian@olddog.co.uk> wrote:

> Hi,
> 
> I am working with Michelle on responses and updates after IETF
> last call. Most of the issues give rise to relatively easy
> changes, and Michelle can handle them in a new revision with a
> note saying what has changed and why.
> 
> But Eric's email gives rise to a wider and more difficult
> point on which I want to comment.
>...
> This is, indeed, the fundamental issue. And it is sometimes
> called "squatting".
>...
> The way we have handled this in the past is by partitioning
> our code spaces and assigning each part an allocation policy.
> There is a good spectrum of allocation policies available in
> RFC 5226, but it is up to working group consensus (backed by
> IETF consensus) to assign the allocation policy when the
> registry is created, and to vary that policy at any time.
>...
> The early allocation thing was created to "blur the edges."
> That is, to cover the case where exactly the case that Eric
> describes arises, but where the registries require publication
> of a document (usually an RFC). The procedures were documented
> in RFC 4020, but that was almost in the nature of an
> experiment. The document in hand is attempting to tighten up
> the rules so that IANA knows how to handle early allocations.
>...

Adrian,

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

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

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

thanks,
   john