Re: Last Call: <draft-housley-number-registries-02.txt> (Internet Number

Hi Russ,

A few comments/suggestions on your draft:

Overall:  

I'm a bit uncomfortable with specifying the contents of registries within RFCs 
these days as they can become out of date even before they're published.  For 
example, it's likely there's going to be a reservation of IPv6 space for LISP 
EID prefixes in the near future but (I suspect) after your draft is published 
as an RFC.  Perhaps it would make more sense to reference IANA registries 
instead of listing the contents of what would be in those registries in the 
draft text, e.g., pointing to 
http://www.iana.org/assignments/iana-ipv4-special-registry/iana-ipv4-special-registry.xml
 for IPv4 and 
http://www.iana.org/assignments/iana-ipv6-special-registry/iana-ipv6-special-registry.xhtml
 for IPv6 (and creating a special purpose registry for AS numbers)?

I find it curious that when talking about top-level domains, the criteria 
(according to RFC 6761) for reservation is "Standards Action" or "IESG 
Approval" but when talking about reserving Internet Number resources, the 
criteria is "IETF Review".  Any idea why there is a discrepancy?

Specific comments:

Section 2.1, second paragraph:

   The allocation and registration functions for all non-reserved AS
   numbers are handled by the Internet Numbers Registry System in
   accordance with policies developed by the Regional Internet
   Registries (RIRs).

I might suggest:

"The allocation and registration functions for all non-reserved AS numbers are 
currently handled by the Internet Numbers Registry System in accordance with 
policies developed via the Regional Internet Registries' (RIRs) public policy 
development processes."

Section 2.2, first paragraph:

   The allocation and registration functions for all non-reserved
   globally unique unicast IPv4 unicast addresses are handled by the
   Internet Numbers Registry System in accordance with policies
   developed by the Regional Internet Registries (RIRs).

Similar to the previous suggestion (dropping a redundant 'unicast'):

"The allocation and registration functions for all non-reserved globally unique 
unicast IPv4 addresses are currently handled by the Internet Numbers Registry 
System in accordance with policies developed via the RIRs' public policy 
development processes."

Section 2.3, second paragraph:

   The allocation and registration functions for all non-reserved
   globally unique unicast IPv6 unicast addresses are handled by the
   Internet Numbers Registry System in accordance with policies
   developed by the Regional Internet Registries (RIRs).

Similar to the previous suggestion (also dropping a redundant 'unicast'):

"The allocation and registration functions for all non-reserved globally unique 
unicast IPv6 addresses are currently handled by the Internet Numbers Registry 
System in accordance with policies developed via the RIRs' public policy 
development processes."

Section 3:

The parenthetical "(e.g., anycast)" may be a bit confusing/ambiguous.  What 
most people today think of anycast (i.e., "shared unicast") don't generally 
need to be treated specially by the Internet Numbers Registry System or the 
IETF.  I'd recommend just dropping the parenthetical.

Section 4:

While the statement there is truthful, perhaps should there be some mention of 
the potential implications of reserved space in the context of trying to 
identify sources of badness that are using reserved addresses or ASes?  E.g., 
perhaps recommending that care should be taken by operators to ensure that 
traffic sourced and/or destined to reserved addresses/ASNs is appropriate?

Hope this helps.

Regards,
-drc

signature.asc
Description: Message signed with OpenPGP using GPGMail