Re: [Gen-art] Gen-ART review of draft-atlas-icmp-unnumbered-08

[<[e-mail]>]

The -09 version of this draft is a satisfactory response to the concerns
raised in the Gen-ART review of the -08 version.

I had also suggested that a definition of a "numbered interface" be
added, but it's reasonable to assume that an implementer of this
draft understands that concept.

Many thanks to Carlos for making the changes.

Thanks,
--David


> -----Original Message-----
> From: Black, David
> Sent: Sunday, December 27, 2009 5:53 PM
> To: [e-mail]; [e-mail]; [e-mail];
[e-mail]; [e-mail];
> '[e-mail]'
> Cc: Jari Arkko; Black, David
> Subject: Gen-ART review of draft-atlas-icmp-unnumbered-08
> 
> I have been selected as the General Area Review Team (Gen-ART)
> reviewer for this draft (for background on Gen-ART, please see
> http://www.alvestrand.no/ietf/gen/art/gen-art-FAQ.html).
> 
> Please resolve these comments along with any other Last Call
> comments you may receive.
> 
> Document: draft-atlas-icmp-unnumbered-08
> Reviewer: David L. Black
> Review Date: December 27, 2009
> IETF LC End Date: January 1, 2010
> 
> Summary:
> This draft is on the right track, but has open issues, described
> in the review.
> 
> Comments:
> The draft defines an extension to ICMP messages that allows additional
> network interface information to be provided with some ICMP messages.
> The information may be an ifIndex, an IP address, an Interface Name
> and/or an MTU.
> 
> The one open issue in this review involves the use of ifIndex to
> identify an interface.  The motivating use cases in section 3
> involve traceroute, ACL-caused-blockage, and the need to determine the
> MTU - those use cases are "public" in the sense that they clearly
> encompass use of the ICMP messages by other than the network operator
> whose device generated those messages.
> 
> In this context, IP address, Interface Name and MTU are all clearly
> useful, but I am concerned about ifIndex.  An ifIndex is effectively
> private to the SNMP management infrastructure of the network operator.
> Determining what interface an ifIndex designates generally involves
> SNMP access that a network operator may be reluctant to grant to
> outsiders due to the level of detail that such access may expose.
> 
> I suspect that the ifIndex could be *very* useful to an ifIndex-
> enhanced traceroute issued from a network operator's management
station
> as alluded to in paragraphs 3-5 of Section 6 (Security
Considerations).
> My open issue is that I should have to go all the way down to the
latter
> part of the Security Considerations section in order to find the
> motivations for and intended usage of one of the major features of
this
> extension.
> 
> I suggest adding a Section 3.3 to discuss use of ifIndex with ICMP and
> network management tools (e.g., enhanced traceroute plus an SNMP
manager)
> by a network operator to debug his/her own network.  This new section
> should also contain some sort of warning that ifIndex information may
> not be available to other than the network operator's management
> applications (with a pointer to the Security Considerations section).
> 
> Nits:
> - Section 2: "o  that interface is numbered"  Please add a definition
> 	of "numbered" for an interface.
> - Section 4.1: Explain what a C-Type is.  A few words and a reference
> 	to Section 8 of RFC 4884 should suffice.
> - Section 5.4: This appears to be poorly stated:
>    A single instance of IP Address information MAY be included only in
>    the following circumstances:
> 
>    Included in what?  I presume an Interface Information Object.
Also,
>    MAY ... only is poor usage of RFC 2119 terminology.  Here's an
attempt
>    at better phrasing:
> 
>    When an Interface Information Object contains an IP Address, one of
>    the following two conditions MUST be true:
> 
> idnits 2.11.15 did not find any nits.
> 
> Thanks,
> --David
> ----------------------------------------------------
> David L. Black, Distinguished Engineer
> EMC Corporation, 176 South St., Hopkinton, MA  01748
> [phone]             FAX: [phone]
> [e-mail]        Mobile: [phone]
> ----------------------------------------------------