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

[<[e-mail]>]

The forwarded message is the current review (for the IESG telechat) of
this draft.

Thanks,
--David


> -----Original Message-----
> From: Black, David
> Sent: Friday, January 08, 2010 7:33 PM
> To: Black, David; '[e-mail]'; '[e-mail]';
'[e-mail]';
> [e-mail]; '[e-mail]'; '[e-mail]'
> Cc: 'Jari Arkko'
> Subject: RE: Gen-ART review of draft-atlas-icmp-unnumbered-08
> 
> 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]
> > ----------------------------------------------------