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
- Re: I-D Action: draft-moonesamy-rfc2050-historic-… David Conrad
- Re: I-D Action: draft-moonesamy-rfc2050-historic-… Brian E Carpenter
- Re: I-D Action: draft-moonesamy-rfc2050-historic-… Abdussalam Baryun
- Re: I-D Action: draft-moonesamy-rfc2050-historic-… S Moonesamy
- Re: I-D Action: draft-moonesamy-rfc2050-historic-… David Conrad
- Re: I-D Action: draft-moonesamy-rfc2050-historic-… John C Klensin
- Re: I-D Action: draft-moonesamy-rfc2050-historic-… Randy Bush
- Re: I-D Action: draft-moonesamy-rfc2050-historic-… David Conrad
- Re: I-D Action: draft-moonesamy-rfc2050-historic-… Dave Crocker
- Re: I-D Action: draft-moonesamy-rfc2050-historic-… Randy Bush
- Re: I-D Action: draft-moonesamy-rfc2050-historic-… David Conrad
- Re: I-D Action: draft-moonesamy-rfc2050-historic-… Randy Bush
- digressive rant on internet fiefdoms Randy Bush
- Re: I-D Action: draft-moonesamy-rfc2050-historic-… Brian E Carpenter
- Re: I-D Action: draft-moonesamy-rfc2050-historic-… Arturo Servin
- Re: I-D Action: draft-moonesamy-rfc2050-historic-… Abdussalam Baryun
- Re: I-D Action: draft-moonesamy-rfc2050-historic-… John C Klensin
- Re: I-D Action: draft-moonesamy-rfc2050-historic-… Lee Howard
- Re: I-D Action: draft-moonesamy-rfc2050-historic-… Abdussalam Baryun