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
+1 (508) 293-7953 FAX: +1 (508) 293-7786
[email protected] Mobile: +1 (978) 394-7754
----------------------------------------------------
_______________________________________________
Gen-art mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/gen-art
