Last Call Review of draft-iana-special-ipv4-registry-

Request Review of draft-iana-special-ipv4-registry
Requested rev. no specific revision (document currently at 02)
Type Last Call Review
Team Security Area Directorate (secdir)
Deadline 2009-06-17
Requested 2009-06-05
Draft last updated 2009-06-16
Completed reviews Secdir Last Call review of -?? by Yaron Sheffer
Assignment Reviewer Yaron Sheffer
State Completed
Review review-iana-special-ipv4-registry-secdir-lc-sheffer-2009-06-16
Review completed: 2009-06-16


I have reviewed this document as part of the security directorate's
ongoing effort to review all IETF documents being processed by the IESG.  These
comments were written primarily for the benefit of the security area directors. 
Document editors and WG chairs should treat these comments just like any other
last call comments.


This document consists of a directive to IANA on creating and managing
an IPv4 Special Purpose Address registry. It took me some time to realize this
document is about all of two hundred fifty six IP addresses. It sure seems to
be a lot of effort for very few addresses.






The document is
missing a reference to [rfc3330bis] (which should be Normative). Does "[date]"
refer to this document’s publication date?



The document is
copied from RFC 4773, in places a bit too verbatim. In particular it mentions
"scoped, local, or private contexts", which rarely apply to IPv4.
Today even link-local IPv4 addresses are usually treated as error indications,




I would have been much happier with a Security Considerations section
that said there are no such considerations. The current text includes:


"This registry is intended to provide an
authoritative source of information regarding the currency and intended purpose
of IPv4 Special Purpose address blocks that are designated from the
IANA-administered IPv4 Special Purpose address pool.  This is a small step
towards the creation of a comprehensive registry framework that can be used as
a trust point for commencing a chain of address validation."


I am not aware of specified mechanisms to securely allocate, deallocate
and query the ownership and status of IP addresses. Perhaps it’s just my
ignorance, but if any such mechanisms exist, they should be referenced from the
document. In the absence of such security mechanisms, the above paragraph doesn’t
make sense to me, in particular when the scope current is just 256 addresses.




 S/MIME cryptographic signature