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

<Black_David@emc.com> Sun, 27 December 2009 23:03 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 3254E3A68DF for <gen-art@core3.amsl.com>; Sun, 27 Dec 2009 15:03:23 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -5.338
X-Spam-Level:
X-Spam-Status: No, score=-5.338 tagged_above=-999 required=5 tests=[AWL=1.261, 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 J78sn1jCiS5P for <gen-art@core3.amsl.com>; Sun, 27 Dec 2009 15:03:22 -0800 (PST)
Received: from mexforward.lss.emc.com (mexforward.lss.emc.com [128.222.32.20]) by core3.amsl.com (Postfix) with ESMTP id E96793A6919 for <gen-art@ietf.org>; Sun, 27 Dec 2009 15:03:21 -0800 (PST)
Received: from hop04-l1d11-si02.isus.emc.com (HOP04-L1D11-SI02.isus.emc.com [10.254.111.55]) by mexforward.lss.emc.com (Switch-3.3.2/Switch-3.1.7) with ESMTP id nBRN2xm8023599 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sun, 27 Dec 2009 18:02:59 -0500
Received: from mailhub.lss.emc.com (numailhub.lss.emc.com [10.254.144.16]) by hop04-l1d11-si02.isus.emc.com (RSA Interceptor); Sun, 27 Dec 2009 18:02:50 -0500
Received: from corpussmtp3.corp.emc.com (corpussmtp3.corp.emc.com [10.254.169.196]) by mailhub.lss.emc.com (Switch-3.4.2/Switch-3.3.2mp) with ESMTP id nBRN2oKE002408; Sun, 27 Dec 2009 18:02:50 -0500
Received: from CORPUSMX80B.corp.emc.com ([10.254.89.203]) by corpussmtp3.corp.emc.com with Microsoft SMTPSVC(6.0.3790.3959); Sun, 27 Dec 2009 18:02:49 -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, 27 Dec 2009 18:02:49 -0500
Message-ID: <C2D311A6F086424F99E385949ECFEBCB012C42D8@CORPUSMX80B.corp.emc.com>
In-Reply-To: <C2D311A6F086424F99E385949ECFEBCB012C42D7@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/7AZERU2gAAFNnjA=
References: <C2D311A6F086424F99E385949ECFEBCB012C42D7@CORPUSMX80B.corp.emc.com>
From: Black_David@emc.com
To: Black_David@emc.com, alia.atlas@bt.com, rbonica@juniper.net, cpignata@cisco.com, naiming@cisco.com, gen-art@ietf.org
X-OriginalArrivalTime: 27 Dec 2009 23:02:49.0778 (UTC) FILETIME=[B634A920:01CA8748]
X-EMM-EM: Active
Cc: jari.arkko@piuha.net, Black_David@emc.com
Subject: Re: [Gen-art] 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: Sun, 27 Dec 2009 23:03:23 -0000

And the draft needs a new email address for JR:

Your message did not reach some or all of the intended recipients.

      Subject:	Gen-ART review of draft-atlas-icmp-unnumbered-08
      Sent:	12/27/2009 5:53 PM

The following recipient(s) cannot be reached:

      jrrivers@cisco.com on 12/27/2009 5:54 PM
            The e-mail system was unable to deliver the message, but did
not report a specific reason.  Check the address and try again.  If it
still fails, contact your system administrator.
            < sj-inbound-d.cisco.com #5.0.0 smtp; 5.1.0 - Unknown
address error 550-'5.1.1 <jrrivers@cisco.com>... User unknown' (delivery
attempts: 0)>


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
> ----------------------------------------------------