Subject: [Gen-art] Gen-ART review of draft-bonica-special-purpose-03

From: "Romascanu, Dan (Dan)" <[email-masked]>
Date: Thu, 20 Dec 2012 17:41:30 +0000

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)

---

From: Ronald Bonica <[email-masked]>
Date: Thu, 20 Dec 2012 21:45:38 +0000

Hi Dan,

Response inline.....

> -----Original Message-----
> From: Romascanu, Dan (Dan) [mailto:[email-masked]]
> Sent: Thursday, December 20, 2012 12:41 PM
> To: [email-masked]
> Cc: Ronald Bonica; Ralph Droms (rdroms)
> Subject: Gen-ART review of draft-bonica-special-purpose-03
> 
> 
> 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.

Thanks!

> 
> 
> Major issues:
> 
> Geoff Hunt pointed during the IETF Last Call that this document
> actually deals with two different categories of addresses:
> (see
> https://www.ietf.org/ibin/c5i?mid=6&rid=49&gid=0&k1=933&k2=66219&tid=13
> 56023982)
> 
> 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.

The later approach is taken in version-04

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

These are both useful recommendations, but beyond the scope of the current document, which is an instruction to IANA. This kind of advice should be in an OPSEC document.

> nothing about experimental assignments.

RFC 5735 doesn't make any recommendation. It reiterates a requirement stated in RFC 2860. Since the current document does not obsolete, update or in any way affect RFC 2860, there is no need to reiterate that long-standing requirement.

> corrected (probably February 1996)

Good Catch.