Hi Dan, Response inline.....
> -----Original Message----- > From: Romascanu, Dan (Dan) [mailto:[email protected]] > Sent: Thursday, December 20, 2012 12:41 PM > To: [email protected] > Cc: Ronald Bonica; Ralph Droms (rdroms) > Subject: Gen-ART review of draft-bonica-special-purpose-03 > > > 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. Thanks! > > > 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=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 > > 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. 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. > > 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. 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. > > Nits/editorial comments: > > In Table 11 Allocation Date is stated as February 196 - needs to be > corrected (probably February 1996) > Good Catch. > _______________________________________________ Gen-art mailing list [email protected] https://www.ietf.org/mailman/listinfo/gen-art
