Re: I-D Action: draft-moonesamy-rfc2050-historic-00.txt

David Conrad <drc@virtualized.org> Sat, 12 January 2013 19: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 4FDDA21F87BA for <ietf@ietfa.amsl.com>; Sat, 12 Jan 2013 11:36:44 -0800 (PST)
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 ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qzkCxC1c3dl1 for <ietf@ietfa.amsl.com>; Sat, 12 Jan 2013 11:36:43 -0800 (PST)
Received: from trantor.virtualized.org (trantor.virtualized.org [199.48.134.42]) by ietfa.amsl.com (Postfix) with ESMTP id 6ED0821F87A9 for <ietf@ietf.org>; Sat, 12 Jan 2013 11:36:43 -0800 (PST)
Received: from [10.0.1.13] (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 D8E80170A7; Sat, 12 Jan 2013 19:36:41 +0000 (UTC)
Content-Type: text/plain; charset="us-ascii"
Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\))
Subject: Re: I-D Action: draft-moonesamy-rfc2050-historic-00.txt
From: David Conrad <drc@virtualized.org>
In-Reply-To: <50F12E80.8080007@gmail.com>
Date: Sat, 12 Jan 2013 11:36:40 -0800
Content-Transfer-Encoding: quoted-printable
Message-Id: <6D2D2975-A47A-4A0B-A11F-D7C73FE22EDD@virtualized.org>
References: <20130112085109.7357.35960.idtracker@ietfa.amsl.com> <50F12E80.8080007@gmail.com>
To: Brian E Carpenter <brian.e.carpenter@gmail.com>
X-Mailer: Apple Mail (2.1499)
Cc: IETF discussion list <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, 12 Jan 2013 19:36:44 -0000

Brian,

On Jan 12, 2013, at 1:36 AM, Brian E Carpenter <brian.e.carpenter@gmail.com> wrote:
> I object to making RFC 2050 historic without retaining at least the
> content of its Section 1 as an IETF BCP.

Which part of section 1 do you think has any relevance to the IETF as a BCP?

> While the IETF did formally hand over details of address
> allocation policy to IANA, we did so knowing that the RIRs
> themselves, and IANA, considered themselves bound by RFC 2050
> (see the list of authors of that document).

As one of those authors, I will state that I believe that RFC 2050 should be moved to historic (actually should have been moved quite some time ago).

- RFC 2050 was an attempt to document the _then current_ policies and processes of the RIRs. An RFC was chosen because there was no other viable publication mechanism that would reach the relevant communities. The Internet has changed a bit since 1996.  RFC 2050 documents the "Best Current Practice" of the then Internet registries for a very brief window -- RIR policies had already changed from what was documented in RFC 2050 by the time it had gotten through the IESG gauntlet.

- RFC 2050 explicitly discusses allocation policy of IPv4. IPv4 allocation is largely over. The vast majority of RFC 2050 is not particularly relevant to IPv6. Address allocation policies are and have been defined within the address consuming communities which have (reasonably) robust, open, and transparent mechanisms by which anyone can contribute. The IPv6 allocation framework has been defined in other RFCs.

- RFC 2050 discusses allocating IPv4 addresses to RIRs, ISPs, and end users for operational purposes and is unrelated to meeting the technical protocol standardization needs of the IETF.

> An update of RFC 2050, within the scope set by the IETF-IANA
> MoU, would be reasonable.

No, since addressing is _explicitly_ declared out of scope of that MoU, see section 4.3 of RFC 2860:

  "Two particular assigned spaces present policy issues in addition
   to the technical considerations specified by the IETF: the assignment
   of domain names, and the assignment of IP address blocks. These
   policy issues are outside the scope of this MOU."

I don't think it is particularly useful or helpful to try to assert that the IETF did "formally hand over" address allocation to IANA since, as you know, there are lots of folks who have, do, and will claim address allocation, as an operational matter, was never the IETF's to "hand over". What might be useful/helpful is to try to identify the portions of RFC 2050 that have any relevance to the IETF and verify that those portions are covered elsewhere.

Regards,
-drc