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

Dave Crocker <dhc@dcrocker.net> Sun, 13 January 2013 00:34 UTC

Return-Path: <dhc@dcrocker.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 B818121F8941 for <ietf@ietfa.amsl.com>; Sat, 12 Jan 2013 16:34:20 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.449
X-Spam-Level:
X-Spam-Status: No, score=-6.449 tagged_above=-999 required=5 tests=[AWL=0.150, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4]
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 V+TpjmF2wPzw for <ietf@ietfa.amsl.com>; Sat, 12 Jan 2013 16:34:19 -0800 (PST)
Received: from sbh17.songbird.com (sbh17.songbird.com [72.52.113.17]) by ietfa.amsl.com (Postfix) with ESMTP id 7B61621F8936 for <ietf@ietf.org>; Sat, 12 Jan 2013 16:34:19 -0800 (PST)
Received: from [192.168.1.66] (76-218-9-215.lightspeed.sntcca.sbcglobal.net [76.218.9.215]) (authenticated bits=0) by sbh17.songbird.com (8.13.8/8.13.8) with ESMTP id r0D0YIAR011353 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT) for <ietf@ietf.org>; Sat, 12 Jan 2013 16:34:19 -0800
Message-ID: <50F20102.80800@dcrocker.net>
Date: Sat, 12 Jan 2013 16:34:10 -0800
From: Dave Crocker <dhc@dcrocker.net>
Organization: Brandenburg InternetWorking
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130107 Thunderbird/17.0.2
MIME-Version: 1.0
To: IETF discussion list <ietf@ietf.org>
Subject: Re: I-D Action: draft-moonesamy-rfc2050-historic-00.txt
References: <20130112085109.7357.35960.idtracker@ietfa.amsl.com> <50F12E80.8080007@gmail.com> <6D2D2975-A47A-4A0B-A11F-D7C73FE22EDD@virtualized.org> <03E877D7862B38284128680C@JcK-HP8200.jck.com> <BBAC97B5-C633-4034-818D-5E9755012FF8@virtualized.org>
In-Reply-To: <BBAC97B5-C633-4034-818D-5E9755012FF8@virtualized.org>
Content-Type: text/plain; charset="ISO-8859-1"; format="flowed"
Content-Transfer-Encoding: 7bit
X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.0 (sbh17.songbird.com [72.52.113.17]); Sat, 12 Jan 2013 16:34:19 -0800 (PST)
X-BeenThere: ietf@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
Reply-To: dcrocker@bbiw.net
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:34:20 -0000

On 1/12/2013 4:19 PM, David Conrad wrote:
> 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.


The document's abstract declares the document's purposes to be:

    This document describes the registry system for the distribution of
    globally unique Internet address space and registry operations.
    ...
    This document describes the IP assignment policies currently used by
    the Regional Registries to implement the guidelines developed by the
    IANA. The guidelines and these policies are subject to revision at
    the direction of the IANA.


Unless I'm misunderstanding something, there's a simple issue here that 
should be resolved through a simple question:  Does the document still 
satisfy either of these purposes sufficiently and accurately.  My 
understanding from this thread (and elsewhere) is that the answer is no. 
  By definition, the document's role is therefore Historic and it only 
makes sense to make this official.

If there is content in the document that happens to still be useful, it 
should be extracted and published separately, so that no reader will 
suffer confusion and think that the remainder of the document remains 
applicable.

d/

ps.  A replacement document that /is/ sufficient to the current Internet 
would be a service to the community.

-- 
  Dave Crocker
  Brandenburg InternetWorking
  bbiw.net