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
Attachment:
signature.asc
Description: Message signed with OpenPGP using GPGMail