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

<Black_David@emc.com> Mon, 18 January 2010 00:17 UTC

Return-Path: <Black_David@emc.com>
X-Original-To: gen-art@core3.amsl.com
Delivered-To: gen-art@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 848A73A685F for <gen-art@core3.amsl.com>; Sun, 17 Jan 2010 16:17:27 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -5.849
X-Spam-Level:
X-Spam-Status: No, score=-5.849 tagged_above=-999 required=5 tests=[AWL=0.750, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QQolxUXigtHC for <gen-art@core3.amsl.com>; Sun, 17 Jan 2010 16:17:26 -0800 (PST)
Received: from mexforward.lss.emc.com (mexforward.lss.emc.com [128.222.32.20]) by core3.amsl.com (Postfix) with ESMTP id E3E8E3A67B3 for <gen-art@ietf.org>; Sun, 17 Jan 2010 16:17:25 -0800 (PST)
Received: from hop04-l1d11-si01.isus.emc.com (HOP04-L1D11-SI01.isus.emc.com [10.254.111.54]) by mexforward.lss.emc.com (Switch-3.3.2/Switch-3.1.7) with ESMTP id o0I0HLR3028224 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sun, 17 Jan 2010 19:17:21 -0500
Received: from mailhub.lss.emc.com (nagas.lss.emc.com [10.254.144.15]) by hop04-l1d11-si01.isus.emc.com (RSA Interceptor); Sun, 17 Jan 2010 19:17:16 -0500
Received: from corpussmtp5.corp.emc.com (corpussmtp5.corp.emc.com [128.221.166.229]) by mailhub.lss.emc.com (Switch-3.4.2/Switch-3.3.2mp) with ESMTP id o0I0HGis008070; Sun, 17 Jan 2010 19:17:16 -0500
Received: from CORPUSMX80B.corp.emc.com ([10.254.89.203]) by corpussmtp5.corp.emc.com with Microsoft SMTPSVC(6.0.3790.3959); Sun, 17 Jan 2010 19:17:15 -0500
X-MimeOLE: Produced By Microsoft Exchange V6.5
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
Date: Sun, 17 Jan 2010 19:17:14 -0500
Message-ID: <C2D311A6F086424F99E385949ECFEBCB015C5713@CORPUSMX80B.corp.emc.com>
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
Thread-Topic: Gen-ART review of draft-atlas-icmp-unnumbered-08
Thread-Index: AcpuMW71OqFxLssPSI24NB2FQif/7AZERU2gAmAM2SABxC7awA==
From: Black_David@emc.com
To: mary.barnes@nortel.com
X-OriginalArrivalTime: 18 Jan 2010 00:17:15.0683 (UTC) FILETIME=[96C46F30:01CA97D3]
X-EMM-EM: Active
Cc: gen-art@ietf.org, Black_David@emc.com
Subject: [Gen-art] FW: Gen-ART review of draft-atlas-icmp-unnumbered-08
X-BeenThere: gen-art@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: "GEN-ART: General Area Review Team" <gen-art.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/gen-art>, <mailto:gen-art-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/gen-art>
List-Post: <mailto:gen-art@ietf.org>
List-Help: <mailto:gen-art-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/gen-art>, <mailto:gen-art-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 18 Jan 2010 00:17:27 -0000

Mary,

Despite the -08 number in the subject line, this is actually the
Gen-ART review of the -09 version - it's fine.

Thanks,
--David


-----Original Message-----
From: Black, David 
Sent: Friday, January 08, 2010 7:33 PM
To: Black, David; 'alia.atlas@bt.com'; 'rbonica@juniper.net';
'cpignata@cisco.com'; jrrivers@yahoo.com; 'naiming@cisco.com';
'gen-art@ietf.org'
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: alia.atlas@bt.com; rbonica@juniper.net; cpignata@cisco.com;
jrrivers@cisco.com; naiming@cisco.com;
> 'gen-art@ietf.org'
> 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
> +1 (508) 293-7953             FAX: +1 (508) 293-7786
> black_david@emc.com        Mobile: +1 (978) 394-7754
> ----------------------------------------------------