IETF Logo Mail Archive

Re: Last Call: <draft-housley-rfc2050bis-01.txt> (The Internet Numbers Registry System) to Informational RFC

David Conrad <drc@virtualized.org> Sat, 11 May 2013 01:36 UTC

Return-Path: <drc@virtualized.org>
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 4FDDD21F8B38 for <ietf@ietfa.amsl.com>; Fri, 10 May 2013 18:36:24 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.599
X-Spam-Level:
X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599]
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 H0BhQObrkrnm for <ietf@ietfa.amsl.com>; Fri, 10 May 2013 18:36:18 -0700 (PDT)
Received: from trantor.virtualized.org (trantor.virtualized.org [199.48.134.42]) by ietfa.amsl.com (Postfix) with ESMTP id 7F50A21F8B33 for <ietf@ietf.org>; Fri, 10 May 2013 18:36:17 -0700 (PDT)
Received: from [10.0.1.4] (c-24-4-109-25.hsd1.ca.comcast.net [24.4.109.25]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: drc) by trantor.virtualized.org (Postfix) with ESMTPSA id DCD60170B7; Sat, 11 May 2013 01:36:16 +0000 (UTC)
Content-Type: text/plain; charset="us-ascii"
Mime-Version: 1.0 (Mac OS X Mail 6.3 \(1503\))
Subject: Re: Last Call: <draft-housley-rfc2050bis-01.txt> (The Internet Numbers Registry System) to Informational RFC
From: David Conrad <drc@virtualized.org>
In-Reply-To: <6.2.5.6.2.20130510103049.0ca25050@resistor.net>
Date: Fri, 10 May 2013 18:36:15 -0700
Content-Transfer-Encoding: quoted-printable
Message-Id: <D8079A6C-3A65-433E-8D12-5B53E645E48E@virtualized.org>
References: <20130416230618.31243.43068.idtracker@ietfa.amsl.com> <6.2.5.6.2.20130510103049.0ca25050@resistor.net>
To: SM <sm@resistor.net>
X-Mailer: Apple Mail (2.1503)
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: Sat, 11 May 2013 01:36:24 -0000

SM,

On May 10, 2013, at 11:40 AM, SM <sm@resistor.net> wrote:
> In Section 2:
> 
>  "As such, allocations must be made in accordance with the operational
>   needs of those running the networks that make use of these number
>   resources and by taking into consideration pool limitations at the
>   time of allocation."
> 
> The global IPv4 address pool is currently depleted.  

The IANA IPv4 free pool is exhausted (well, modulo blocks of addresses returned to IANA), yes.

> Two RIR regions are in IPv4 exhaustion phase.  There is a proposal in the RIPE region to remove "need" [1].  

Yes.

> I gather that this new version of the Internet Numbers Registry System looks towards a future where hosts are IPv6 accessible.  

Sure, but it is also looking towards the remaining few IPv4 allocations that will be made over the next few years.

> Given that the free IPv6 address pool is very large and that IP addresses are not free, what is the rationale for keeping allocations in accordance with operational needs?

The fact that the IPv6 address pool is very large does not remove the fact that it is a not an infinite resource and thus, constraints must be applied to allocation policy. Lacking those constraints, I'm sure you or I could come up with an allocation policy that would blow through the IPv6 free pool quite quickly. To date, the communities interested in IP addressing have established policies that dictate "operational needs" should be the primary constraint (as opposed to say constraining on geo-political boundaries, by ability to pay, etc). However, the second part of that sentence is saying that pool limitations at the time of allocation should also be taken into consideration.  Since _at this time_ the IPv6 free pool is quite large, it would follow that allocation policy constraints would be minimal (as I believe they are).

>  "Registration Accuracy: A core requirement of the Internet
>   Numbers Registry System is to maintain a registry of
>   allocations to ensure uniqueness and to provide accurate
>   registration information of those allocations in order to
>   meet a variety of operational requirements."
> 
> There isn't any mention of privacy [2] considerations in the draft.  

True. The document is documenting current practices and policies. At this point in time, I'm unaware of a global privacy practice or policy that is applicable to all levels of the Internet Numbers Registry System.

> Is it up to the IETF to set up a one-stop shop for personal data requests?

I suspect not, but I suspect it isn't up to the IETF to dictate global privacy policy either.

Regards,
-drc

v2.23.0 | Report a Bug | By Email