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/