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