Re: Last Call: <draft-bonica-special-purpose-03.txt> (Special-Purpose Address Registries) to Best Current Practice

Geoff Huston <gih@apnic.net> Fri, 30 November 2012 00:15 UTC

Return-Path: <gih@apnic.net>
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 AAC5521F8AA0 for <ietf@ietfa.amsl.com>; Thu, 29 Nov 2012 16:15:17 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.6
X-Spam-Level:
X-Spam-Status: No, score=-102.6 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id t2X54Bajt5V7 for <ietf@ietfa.amsl.com>; Thu, 29 Nov 2012 16:15:17 -0800 (PST)
Received: from asmtp.apnic.net (asmtp.apnic.net [IPv6:2001:dc0:2001:11::199]) by ietfa.amsl.com (Postfix) with ESMTP id C9A4421F8AA1 for <ietf@ietf.org>; Thu, 29 Nov 2012 16:15:16 -0800 (PST)
Received: from [IPv6:2001:388:1000:110:bc95:1f16:d3c8:240f] (unknown [IPv6:2001:388:1000:110:bc95:1f16:d3c8:240f]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by asmtp.apnic.net (Postfix) with ESMTP id 4E9F3B6745; Fri, 30 Nov 2012 10:15:15 +1000 (EST)
Subject: Re: Last Call: <draft-bonica-special-purpose-03.txt> (Special-Purpose Address Registries) to Best Current Practice
Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\))
Content-Type: text/plain; charset="iso-8859-1"
From: Geoff Huston <gih@apnic.net>
In-Reply-To: <50B7F2BA.9000600@qti.qualcomm.com>
Date: Fri, 30 Nov 2012 11:15:15 +1100
Content-Transfer-Encoding: quoted-printable
Message-Id: <1D916C75-C75D-4DF7-95E4-4787D6904A03@apnic.net>
References: <20121129205534.8983.43593.idtracker@ietfa.amsl.com> <7C5BEF8A-70E1-4E96-BC5C-7D2D43E09A58@apnic.net> <50B7F2BA.9000600@qti.qualcomm.com>
To: Pete Resnick <presnick@qti.qualcomm.com>
X-Mailer: Apple Mail (2.1499)
Cc: 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: Fri, 30 Nov 2012 00:15:17 -0000

On 30/11/2012, at 10:41 AM, Pete Resnick <presnick@qti.qualcomm.com> wrote:

> Like Randy, I am completely agnostic on the question of dividing the registries vs. adding an attribute to the registries to distinguish between reservations and other special uses. But one comment on the other item in your message:
> 
> On 11/29/12 4:26 PM, Geoff Huston wrote:
> 
>> I also disagree with the approach to publish the intended contents of this special purpose registry as an RFC ans the registry itself is the intended mode of authoritatively describing those resources that have been assigned for special purposes. Obviously any RFC will age out and drift away from the registry, and the need to constantly publish updating RFCs to ensure that the latest RFC is reasonably close to the registry contents seems to me to be counter-productive at best.
>>   
> 
> I think (hope) you've misinterpreted this. The document serves two purposes: To define the registries (section 2.1, which is really the BCPish part of this document)

And I was saying that I would prefer to see protocol address plan reservations not be included in the special purpose registry.


> and to populate the registries with initial values (sections 2.2 and 2.3).

Some time ago there was value in this "initial population" concept to sort some of the claims of special purpose address assignments, but I thought that we were over it and the draft restates what is already n the registry.


> 2.1 is the real content of the documentthat will live on, get updated, etc., whereas 2.2 and 2.3 are probably better as an appendix, and I don't think there's any expectation that those sections ought to be kept up to date with future RFCs to match the registry. (Indeed, it might be nice if 2.2 and 2.3 were removed before publication, but that's not been our practice.)

Personally the removal before publication of the registry contents would be something I would support.

> 
> Does that allay your concern?
> 


no - as I would prefer to see protocol address plan reservations not be included in the special purpose registry. The IPv4 address plan reservations appear to be 0/8, 127/8 and  240/4. The others appear to be various forms of special prupose assignments. In IPv6 I see reservations for ::1/128, ::/128 as far as I can tell - the remainder are reasonably seen as Special Purpose Assignments I would suggest.

regards,

  Geoff