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

David Conrad <drc@virtualized.org> Sun, 13 January 2013 00:19 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 5655521F899D for <ietf@ietfa.amsl.com>; Sat, 12 Jan 2013 16:19:46 -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 SAHJIMHL4l+v for <ietf@ietfa.amsl.com>; Sat, 12 Jan 2013 16:19:45 -0800 (PST)
Received: from trantor.virtualized.org (trantor.virtualized.org [199.48.134.42]) by ietfa.amsl.com (Postfix) with ESMTP id 9804421F8941 for <ietf@ietf.org>; Sat, 12 Jan 2013 16:19:45 -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 C3289170AD; Sun, 13 Jan 2013 00:19:44 +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: <03E877D7862B38284128680C@JcK-HP8200.jck.com>
Date: Sat, 12 Jan 2013 16:19:43 -0800
Content-Transfer-Encoding: quoted-printable
Message-Id: <BBAC97B5-C633-4034-818D-5E9755012FF8@virtualized.org>
References: <20130112085109.7357.35960.idtracker@ietfa.amsl.com> <50F12E80.8080007@gmail.com> <6D2D2975-A47A-4A0B-A11F-D7C73FE22EDD@virtualized.org> <03E877D7862B38284128680C@JcK-HP8200.jck.com>
To: John C Klensin <john-ietf@jck.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: Sun, 13 Jan 2013 00:19:46 -0000

John,

On Jan 12, 2013, at 2:21 PM, John C Klensin <john-ietf@jck.com> wrote:
> However, I don't think the
> section of 2860 that you cite helps very much because there is
> another way to read it.  

As you know, there are many in both high and low places who choose the interpretation of 2860 that best fits their particular interests, regardless of the intent of that document (or, from personal experience, efforts to try to explain history or reality).  As such, I'll repeat: I do not believe it useful or helpful to go down that particular rat hole.

The more relevant bit:

> The IETF still has responsibility for the technical
> specification of addresses and the policies that narrowly
> implies; other policy issues, including the models for
> allocations of addresses to those who will use them, belong to
> others.  

I believe RFC 2050 does (and did) _not_ address "technical specifications of addresses", but rather documented (past tense) the then "best current practice" of policies associated with the operational deployment of those addresses for a short period around 1995 or so.

The Internet has moved on. The IETF still has the responsibility to define address technical specifications (e.g., an IPv6 address is 128 bits long), however I do not believe the IETF now has the responsibility to define operational deployment policy or processes (if it ever did).

As such, I think it perfectly appropriate to move RFC 2050 to "historic" since, in fact, it actually is.

> If Jon were participating in this conversation today, I'm quite
> sure that he would be saying that it is much more important for
> the RIRs and the IETF to work together to get the best result
> for the Internet rather than putting energy into trying to
> legislate or enforce a boundary

I doubt anyone rational would disagree with this, but I don't think that's the topic of discussion.  The issue, as I understand it, is that RFC 2050 is outdated and historic and its status should be made to reflect that truth.

Regards,
-drc