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.