Re: grow: draft of new RFC1519 replacement
Pekka Savola <pekkas@netcore.fi> Tue, 26 April 2005 18:02 UTC
Received: from darkwing.uoregon.edu (root@darkwing.uoregon.edu [128.223.142.13]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA01216 for <grow-archive@lists.ietf.org>; Tue, 26 Apr 2005 14:02:09 -0400 (EDT)
Received: from darkwing.uoregon.edu (majordom@localhost [127.0.0.1]) by darkwing.uoregon.edu (8.13.4/8.13.4) with ESMTP id j3QHwvj4021306; Tue, 26 Apr 2005 10:58:57 -0700 (PDT)
Received: (from majordom@localhost) by darkwing.uoregon.edu (8.13.4/8.13.4/Submit) id j3QHwvUk021304; Tue, 26 Apr 2005 10:58:57 -0700 (PDT)
Received: from netcore.fi (netcore.fi [193.94.160.1]) by darkwing.uoregon.edu (8.13.4/8.13.4) with ESMTP id j3QHwtCk021142 for <grow@lists.uoregon.edu>; Tue, 26 Apr 2005 10:58:56 -0700 (PDT)
Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id j3QHwlG28228; Tue, 26 Apr 2005 20:58:47 +0300
Date: Tue, 26 Apr 2005 20:58:47 +0300
From: Pekka Savola <pekkas@netcore.fi>
To: Vince Fuller <vaf@cisco.com>
cc: grow@lists.uoregon.edu
Subject: Re: grow: draft of new RFC1519 replacement
In-Reply-To: <20050412203713.GA10692@vaf-lnx1.cisco.com>
Message-ID: <Pine.LNX.4.61.0504262053080.28111@netcore.fi>
References: <20050411170200.GA11870@vaf-lnx1.cisco.com> <Pine.LNX.4.61.0504120957010.3431@netcore.fi> <20050412165344.GA6652@vaf-lnx1.cisco.com> <Pine.LNX.4.61.0504122040050.16404@netcore.fi> <20050412183725.GA8539@vaf-lnx1.cisco.com> <Pine.LNX.4.61.0504122156050.17411@netcore.fi> <20050412203713.GA10692@vaf-lnx1.cisco.com>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset="US-ASCII"; format="flowed"
Sender: owner-grow@lists.uoregon.edu
Precedence: bulk
On Tue, 12 Apr 2005, Vince Fuller wrote: >> The key word here is, I believe, "was". 10 years of operational >> experience, 99.99% of deployment, etc. has hopefully made the food >> fights moot.. and now all that remains is cleaning up the results. > > Maybe. In the past 12 years, the IETF world has become ever more politicized > and vendor-oriented. Nowadays, it seems like it takes years to make even the > simplest of changes to a standards-track document. And given sensitivities > regarding the relevance (or lack thereof) of IPv6, a re-issued CIDR spec would > seem a nice target for controversy. After having lived through that once, I > think I can safely speak for Tony when I say that neither of us want to go > through it again. Well, you could already be under the fire, if folks bring up that CIDR was only designed as a short-mid term solution and this document should be more clearly advocating v6 instead ;-). I think the stuff I propose below is rather straightforward spring cleaning. >> I've not done extensive review of the documents, but based on quick >> look at them, I doubt more than 1-2 pages of added text (at maximum) >> would be required to include the vital bits of the other, >> should-be-Historic documents. Maybe about one paragraph each, >> describing why it is no longer relevant. > > As I said many times to the early reviewers of this document, I welcome > suggested text :-) OK. I did a quick study of relevant related RFCs. See the text suggestion below. I think the main documents which could result in some debate are those currently on standards track, RFC 1517 and RFC 1518. The former is applicability statement which no longer seems relevant but if needed, the relevant bits could also be folded in this document (one paragraph). RFC 1518 does not seem appropriate for standards track anymore, but otherwise has still some valid material. While section 3 of this memo already provides a summary of this, and a document like RFC 3221 already describes most of the same issues, maybe this should just be reclassified Informational instead (though I'd be OK with historic as well). ================= (to be added at the end of section 1) 1.1. Status of Various CIDR Documents This memo Obsoletes and requests reclassifying as Historic the following RFCs, with reasons described in Section 1.1.1: 1467, 1481, 1482, 1517, 1520, 1817, 1878, 2036. This memo Updates and requests reclassifying RFC 1518 as Historic, as described in Section 1.1.2. 1.1.1. Historic CIDR Documents RFC 1467: Status of CIDR Deployment in the Internet This Informational RFC describes the status of CIDR deployment as of 1993. In 2005, CIDR has already thoroughly deployed, and this status note only provides a historical data point. RFC 1481: IAB Recommendation for an Intermediate Strategy to Address the Issue of Scaling This very short Informational RFC just describes the IAB's endorsement of CIDR architecture for scaling issues. As the goal of this note has already been achieved, this political note is only of historical value. RFC 1482: Aggregation Support in the NSFNET Policy-Based Routing Database This Informational RFC describes NSFNET's plans for support of route aggregation, as specified by CIDR. As NSFNET has long since ceased to exist and CIDR has been been ubiquitously deployed, this note has only historical relevance. RFC 1517: Applicability Statement for the Implementation of Classless Inter-Domain Routing (CIDR) This Standards Track RFC summarily describes in which cases CIDR is required and in which cases (strongly) recommended. CIDR has been thoroughly deployed and implemented, so the cases where CIDR is not required are practically only a historical matter. RFC 1520: Exchanging Routing Information Across Provider Boundaries in the CIDR Environment This Informational RFC describes transition scenarios where CIDR is not fully supported for inter-provider routing information exchanges. As CIDR has been thoroughly deployed in such scenarios, this note nowadays has only historical value. RFC 1817: CIDR and Classful Routing This Informational RFC describes the implication of CIDR as of 1995, notes that soon formerly-classful addresses would be allocated using CIDR mechanisms, and describes the use of a default route for non-CIDR aware sites. As CIDR has been thoroughly deployed, this note is only of historical relevance. RFC 1878: Variable Length Subnet Table For IPv4 This Informational RFC just provides precalculated subnet masks and the number of addresses for each. While this may have been valuable when the variable-length subnet masking was a new concept, Section 2.1 of this memo should be sufficient now and this memo has only historical value now. RFC 2036: Observations on the use of Components of the Class A Address Space within the Internet This Informational RFC describes the issues with making classless allocations from previously-classful address space. As CIDR has been deployoed throughout the Internet, and these classless allocations have been made for over half a dozen years, this memo has now only historical value. 1.1.2. An Informational Address Allocation Document RFC 1518: An Architecture for IP Address Allocation with CIDR This Standards Track RFC describes routing and address aggregation considerations at length. [I-D.draft-ietf-grow-rfc1519bis] summarizes these considerations in Section 3. As address assignment considerations now mainly belong to RIRs, having a Standards Track document on the subject does not seem appropriate anymore.[RFC3221] also describes much the same issues from the routing system perspective. Hence we request that this memo Updates RFC 1518 and RFC 1518 is reclassied as Historic. ================ -- Pekka Savola "You each name yourselves king, yet the Netcore Oy kingdom bleeds." Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings _________________________________________________________________ web user interface: http://darkwing.uoregon.edu/~llynch/grow.html web archive: http://darkwing.uoregon.edu/~llynch/grow/
- grow: draft of new RFC1519 replacement Vince Fuller
- Re: grow: draft of new RFC1519 replacement Pekka Savola
- Re: grow: draft of new RFC1519 replacement Vince Fuller
- Re: grow: draft of new RFC1519 replacement Pekka Savola
- Re: grow: draft of new RFC1519 replacement Vince Fuller
- Re: grow: draft of new RFC1519 replacement Pekka Savola
- Re: grow: draft of new RFC1519 replacement Vince Fuller
- Re: grow: draft of new RFC1519 replacement Vince Fuller
- Re: grow: draft of new RFC1519 replacement vijay gill
- Re: grow: draft of new RFC1519 replacement David Meyer
- Re: grow: draft of new RFC1519 replacement Joe Abley
- Re: grow: draft of new RFC1519 replacement David Meyer
- Re: grow: draft of new RFC1519 replacement Danny McPherson
- Re: grow: draft of new RFC1519 replacement Pekka Savola
- Re: grow: draft of new RFC1519 replacement Geoff Huston
- Re: grow: draft of new RFC1519 replacement Vince Fuller
- Re: grow: draft of new RFC1519 replacement Pekka Savola
- grow: draft of new RFC1519 replacement - version … Vince Fuller