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.
---