Last Call Review of draft-bonica-special-purpose-05
review-bonica-special-purpose-05-genart-lc-romascanu-2013-01-08-00

Request Review of draft-bonica-special-purpose
Requested rev. no specific revision (document currently at 07)
Type Last Call Review
Team General Area Review Team (Gen-ART) (genart)
Deadline 2013-01-08
Requested 2012-11-29
Authors Michelle Cotton, Leo Vegoda, Ron Bonica, Brian Haberman
Draft last updated 2013-01-08
Completed reviews Genart Last Call review of -05 by Dan Romascanu (diff)
Assignment Reviewer Dan Romascanu
State Completed
Review review-bonica-special-purpose-05-genart-lc-romascanu-2013-01-08
Reviewed rev. 05 (document currently at 07)
Review result Ready
Review completed: 2013-01-08

Review
review-bonica-special-purpose-05-genart-lc-romascanu-2013-01-08

I am the assigned Gen-ART reviewer for this draft. For background on Gen-ART, please see the FAQ at

<

http://wiki.tools.ietf.org/area/gen/trac/wiki/GenArtfaq>.

Please resolve these comments along with any other Last Call comments you may receive.

Document: draft-bonica-special-purpose-03
Reviewer: Dan Romascanu
Review Date: 12/20/12
IETF LC End Date: 01/02/13
IESG Telechat date: 01/10/13

Summary:

This is a well written, clear, and aparently simple document. It instructs IANA to restructure its IPv4 and IPv6 Special-Purpose Address Registries, updates the RFCs that define the current structure of the IPv4 and IPv6 Special-Purpose Address Registries, and obsoletes the RFCs that currently document the Special-Use IPv4 and IPv6 addresses. During the IETF Last Call one major issue was raised, and this issue needs to be clarified before the IESG decides how to proceed with this document. A small number of minor issues and editorial comments can be easily resolved. 


Major issues:

Geoff Hunt pointed during the IETF Last Call that this document actually deals with two different categories of addresses: 
- address reservations for which the functionality should be included in the IP stacks
- special purpose assignments for which special treatment should be configurable by the IP stacks

(see 

https://www.ietf.org/ibin/c5i?mid=6&rid=49&gid=0&k1=933&k2=66219&tid=1356023982

) 

In its current form the content of the new registry documented by the I-D does not make a distinction between the two categories. There are two solutions to overcome this, one would be to define separate registries, the other to add a field to the current tables that makes the distinction between the two. 

Minor issues:

1. The Security Considerations section in RFC 5156 which is obsoleted by this document included: 

   Filtering the invalid routing prefixes listed in this document should
   improve the security of networks.

This has not been taken upon by the new I-D, although it looked like a useful recommendation. 

Similarly RFC 5735 included warning text about the unexpected usage of special purposes addresses which was not carried over in this document. 

2. RFC 5735 included in the IANA consideration section the following recommendation: 

   As required by [RFC2860], the IANA will also make necessary
   experimental assignments of IPv4 addresses, also in consultation with
   the Regional Internet Registries.

There is no such recommendation in the new proposal, actually there is nothing about experimental assignments. 

Nits/editorial comments:

In Table 11 Allocation Date is stated as February 196 - needs to be corrected (probably February 1996)