Re: AD Evaluation comments on : draft-ietf-grow-rfc1519bis-02.txt

[Geoff Huston <[e-mail]>]

uuuuusssshhhhhpppp!

(loud sucking noise of pulling this mail back - it was meant for the GROW 
mailing list - sorry for the noise - jet lag barin fade :-))

    Geoff


At 08:24 AM 8/11/2005, Geoff Huston wrote:
>Hi,
>
>In the WG meeting this morning there was a request to share the AD's 
>evaulation 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.
>
>---