-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 David: > 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 think this is a good idea. It required a fairly significant update to the document. I did it in version -03. > 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? These three IANA registries require IETF Review. In fact, that is already documented at the two URLs that you provide above. > 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." Okay. I added "public policy development processes" to the end of the sentence. > 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." Okay. I dropped the duplicate "unicast." I added "public policy development processes" to the end of the sentence. > 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." Okay. I dropped the duplicate "unicast." I added "public policy development processes" to the end of the sentence. > 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. This section is completely replaced with the establishment of the special-purpose AS number registry. > 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? How about: Network operators should take care that special-purpose numbers and addresses are used on the public Internet in a manner that is consistent with their reserved purpose. Russ -----BEGIN PGP SIGNATURE----- Version: GnuPG/MacGPG2 v2.0.18 (Darwin) Comment: GPGTools - http://gpgtools.org iEYEARECAAYFAlLj3y8ACgkQiuTu0PWcEcs+nACgiuaf753yizBeTJlXMUxLuw98 f3gAn2/A/rVLdg+Hic5fbGzSeLcNtXxW =dmaF -----END PGP SIGNATURE-----