grow: AD Evaluation comments on : draft-ietf-grow-rfc1519bis-02.txt
Geoff Huston <gih@apnic.net> Mon, 07 November 2005 22:03 UTC
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EZF4z-0003MR-Az for grow-archive@megatron.ietf.org; Mon, 07 Nov 2005 17:03:05 -0500
Received: from mailapps.uoregon.edu (mailapps.uoregon.edu [128.223.142.45]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA10728 for <grow-archive@lists.ietf.org>; Mon, 7 Nov 2005 17:02:39 -0500 (EST)
Received: from mailapps.uoregon.edu (IDENT:U2FsdGVkX18VFvdPtCOVwL9QtPkFSwM9Q7BwntVNRaM@localhost [127.0.0.1]) by mailapps.uoregon.edu (8.13.4/8.13.4) with ESMTP id jA7LmUEf014331; Mon, 7 Nov 2005 13:48:30 -0800
Received: (from majordom@localhost) by mailapps.uoregon.edu (8.13.4/8.13.4/Submit) id jA7LmU29014330; Mon, 7 Nov 2005 13:48:30 -0800
Received: from kahuna.telstra.net (kahuna.telstra.net [203.50.0.6]) by mailapps.uoregon.edu (8.13.4/8.13.4) with ESMTP id jA7LmTuw014326 for <grow@lists.uoregon.edu>; Mon, 7 Nov 2005 13:48:30 -0800
Received: from gihm3.apnic.net (kahuna.telstra.net [203.50.0.6]) by kahuna.telstra.net (8.12.3/8.11.3) with ESMTP id jA7LmDXt014030; Tue, 8 Nov 2005 08:48:16 +1100 (EST) (envelope-from gih@apnic.net)
Message-Id: <6.2.0.14.2.20051108084745.02ae6658@localhost>
X-Mailer: QUALCOMM Windows Eudora Version 6.2.0.14
Date: Tue, 08 Nov 2005 08:48:09 +1100
To: grow@lists.uoregon.edu
From: Geoff Huston <gih@apnic.net>
Subject: grow: AD Evaluation comments on : draft-ietf-grow-rfc1519bis-02.txt
Cc: David Meyer <dmm@1-4-5.net>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format="flowed"
Sender: owner-grow@lists.uoregon.edu
Precedence: bulk
Hi, In the WG meeting this morning there was a request to share the AD's evaluation comments on draft-ietf-grow-rfc1519bis-02.txt with the Working Group. We've checked with the AD on the procedure here, and we're happy to forward these comments on to the mailing list. These comments have already been passed to the document authors and the document is being worked on by the authors to respond to these comments. Thanks, Geoff & Dave ------------------------------------------------------------------------------------------------------------------------- --- The IANA makes allocations from this pool to Regional Internet Registries, as required. These allocations are made in contiguous bit-aligned blocks of 2^24 addresses (a.k.a. /8 prefixes). I don't believe it is a good idea to describe this at this level of detail, I believe it is intended for informational purposes but this draft is standards track and it is not intended to limit the flexibility of the IANA/registry interaction into only giving /8s. --- The RIRs, in turn, allocate or assign smaller address blocks to Local Internet Registries (LIRs) or Internet Service Providers (ISPs). These entities may make direct use of the assignment (as would commonly be the case for an ISP) or may make further sub-allocations of addresses to their customers. For most regional registries (geoff please correct me if I am wrong), they only deal with LIRs. They treat ISPs and all their other customers the same and call them LIRs. Basically, RIRs allocate or assign address space to LIRs, which in turn can be ISPs, large corporations or whatever other entitity that has the money and is willing to obey the rule of being an LIR. --- In practice, prefixes of length shorter than 8 are not allocated or assigned though routes to such short prefixes may exist in routing tables if or when aggressive aggregation is performed. Never say never, I would refrain from comments like this, we never know whether a large DSL/cable or whatever provider might actually get a /7. I would simply drop this line and I admit that this one is a bit of a nitpick. --- To this end, it is recommended that mechanisms to facilitate such migration, such as dynamic host address assignment using [RFC2131]) be deployed wherever possible, and that additional protocol work be done to develop improved technology for renumbering. Probably add a few more references to documents that can help here and expand the text a little bit. --- I don't think the following sentence is constructed particularly well: Also, since the routing cost associated with assigning a multi-homed site out of a service provider's address space is no greater than the old method of sequential number assignment by a central authority, it makes sense to assign all end-site address space out of blocks allocated to service providers. I know what you are trying to say but I was first reading it such that the registries have different blocks of address space for customers that are a service provider and other customers and that there is really no need to do this. It is meant that one can as well assign address space to an enduser who multihomes from it's provider instead of getting an assignment from the registry. However, I am not sure whether I agree as the provider of the enduser probably doesn't like this situation when the customer leaves as it can easily end up receiving traffic that was intended for the former customer due to filtering and failures somewhere in the Internet. --- typo & perhaps some editorial work needed: If, for some reason, the provider were to use an obsolete IGP that doesn't support classless routing or variable-length subnets, then then explicit routes all /24s will ^^^^^^^^^ ---- Use example network range where possible ---- I would prefer to not give any examples on how to do classless in-addr for >/24 delegations and use the reference earlier in this section. I think showing the problem is fine, I would leave the solution completely to the referenced rfc to avoid duplication and people immitating the example without reading the reference. ---- While: 8. Analysis of CIDR's effect on global routing state is an interesting chapter, I am not sure whether it is a good idea to refer to pictures that cannot be in the document. In addition, it is a bit more of an opinion piece than exact science . I would be inclined to drop it but understand that this is just one opinion. ---- Output from: idnits 1.72 draft-ietf-grow-rfc1519bis-02.txt: Checking nits according to http://www.ietf.org/ID-Checklist.html : * The document seems to lack an Introduction section. * The document seems to lack an IANA Considerations section. Checking conformance with RFC 3978/3979 boilerplate... the boilerplate looks good. Checking nits according to http://www.ietf.org/ietf/1id-guidelines.txt : Nothing found here (but these checks does not cover all of 1id-guidelines.txt yet). Miscellaneous warnings: - Line 90 has weird spacing: '...classes of ne...' Run idnits with the --verbose option for more detailed information. --- _________________________________________________________________ web user interface: http://darkwing.uoregon.edu/~llynch/grow.html web archive: http://darkwing.uoregon.edu/~llynch/grow/
- grow: AD Evaluation comments on : draft-ietf-grow… Geoff Huston