Re: [tig-diagnostics] draft-shore-icmp-aup-01

"Carlos Pignataro (cpignata)" <cpignata@cisco.com> Thu, 06 September 2012 09:14 UTC

Return-Path: <cpignata@cisco.com>
X-Original-To: tig-diagnostics@ietfa.amsl.com
Delivered-To: tig-diagnostics@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C801021F8526 for <tig-diagnostics@ietfa.amsl.com>; Thu, 6 Sep 2012 02:14:46 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -110.599
X-Spam-Level:
X-Spam-Status: No, score=-110.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dhD1VxPrzakH for <tig-diagnostics@ietfa.amsl.com>; Thu, 6 Sep 2012 02:14:45 -0700 (PDT)
Received: from rcdn-iport-5.cisco.com (rcdn-iport-5.cisco.com [173.37.86.76]) by ietfa.amsl.com (Postfix) with ESMTP id 97D6521F84DF for <tig-diagnostics@ietf.org>; Thu, 6 Sep 2012 02:14:32 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=4575; q=dns/txt; s=iport; t=1346922872; x=1348132472; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=3CDwbMTCS22VQCvN/ehXjlYAaFJdfuUdvn665SMOUjA=; b=gvmYCIFygciPKQYlg4EAp1jPiXNFZHgWW3lquP6N0OnXiQnHQqEsbgrj 2gl9+0xQkJGrUGrzCH3dT7z/7i9P629teuUvtWemEEeXdNZwdYEKpUq2Z tdL/0KA90W0JePBxEDEiUXdkEQ3fznuGFcfSlil11lZll5nK4rOaD6MIs 8=;
X-Files: signature.asc : 203
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: Av8EAPtoSFCtJV2Z/2dsb2JhbABFux+BB4IgAQEBAwEBAQEPATQCJQsFCwIBCA44JwslAQEEDgUJBQ0Hh2UGC5pEkQiPEosRhWVgA45igSCFV44zgWeCYw
X-IronPort-AV: E=Sophos; i="4.80,379,1344211200"; d="asc'?scan'208"; a="118816407"
Received: from rcdn-core-2.cisco.com ([173.37.93.153]) by rcdn-iport-5.cisco.com with ESMTP; 06 Sep 2012 09:14:32 +0000
Received: from xhc-aln-x13.cisco.com (xhc-aln-x13.cisco.com [173.36.12.87]) by rcdn-core-2.cisco.com (8.14.5/8.14.5) with ESMTP id q869EWui031491 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Thu, 6 Sep 2012 09:14:32 GMT
Received: from xmb-aln-x02.cisco.com ([169.254.5.253]) by xhc-aln-x13.cisco.com ([173.36.12.87]) with mapi id 14.02.0298.004; Thu, 6 Sep 2012 04:14:31 -0500
From: "Carlos Pignataro (cpignata)" <cpignata@cisco.com>
To: Ronald Bonica <rbonica@juniper.net>
Thread-Topic: [tig-diagnostics] draft-shore-icmp-aup-01
Thread-Index: Ac2Ktm/P6S0b7V/lRvupRDBu4ypcXwBRYOQA
Date: Thu, 6 Sep 2012 09:14:30 +0000
Message-ID: <D310CAAB-419A-45D4-A83C-D07D1300BAFA@cisco.com>
References: <13205C286662DE4387D9AF3AC30EF456D782C5873F@EMBX01-WF.jnpr.net>
In-Reply-To: <13205C286662DE4387D9AF3AC30EF456D782C5873F@EMBX01-WF.jnpr.net>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: yes
X-MS-TNEF-Correlator:
x-originating-ip: [10.21.105.244]
x-tm-as-product-ver: SMEX-10.2.0.1135-7.000.1014-19166.005
x-tm-as-result: No--51.234800-8.000000-31
x-tm-as-user-approved-sender: No
x-tm-as-user-blocked-sender: No
Content-Type: multipart/signed; boundary="Apple-Mail=_EC36F272-EEA7-4935-A68C-02EEEBDA8946"; protocol="application/pgp-signature"; micalg=pgp-sha1
MIME-Version: 1.0
Cc: "tig-diagnostics@ietf.org" <tig-diagnostics@ietf.org>
Subject: Re: [tig-diagnostics] draft-shore-icmp-aup-01
X-BeenThere: tig-diagnostics@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: <tig-diagnostics.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/tig-diagnostics>, <mailto:tig-diagnostics-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/tig-diagnostics>
List-Post: <mailto:tig-diagnostics@ietf.org>
List-Help: <mailto:tig-diagnostics-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/tig-diagnostics>, <mailto:tig-diagnostics-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 06 Sep 2012 09:14:46 -0000

Hi Ron,

Thanks for following up on this document. Please see inline.

On Sep 4, 2012, at 12:00 PM, Ronald Bonica wrote:

> Melinda, Carlos,
> 
> Thanks very much for posting this draft. It looks pretty good and I would like to see it progress after some discussion on this mailing list.
> 
> The following are a few comments:
> 
> Header
> ======
> The header doesn't specify an intended status. I think that the intended status should be BCP, because we are offering advice to the IETF regarding future work.

+1.

> 
> Abstract
> ========
> The abstract refers to "Some recent proposals". However, by the time that this draft is published, nobody will remember what those proposals were. So, I recommend replacing the Abstract with the following text:
> 
> "This memo provides guidelines for the future enhancement of ICMP. Specifically, this memo defines the problem space in which ICMP is an appropriate solution. It also pre-empts the enhancement of ICMP for purposes outside of that problem space."
> 

One question: are these 'enhancements' of ICMP or 'extensions' of ICMP? Or simply applications/uses?

> Introduction
> ============
> This section can be deleted. Section 2.0 provides a much better introduction.
> 
> Acceptable use policy
> =====================
> - Rename this section to INTRODUCTION
> - Replace the first two paragraphs with the following:
> 
> "The following bullet points describe the problem space in which ICMP is an appropriate solution:
> 
> - add the following bullet point: "To test connectivity between two points on the Internet". (You need this one to explain echo and echo reply.)
> 
> - Add some text that says "You can enhance ICMP as much as you want, either by adding new codes or by adding ICMP extensions, but only so long as the extension serves the purposes listed above.
> 

One potential approach is to go back to the early definitions of ICMPv4|6, in which there is a high-level taxonomy of ICMP error messages and ICMP query messages -- with the latter further split in requests and replies. Note how things like Router Discovery are not OAM. RFC1470 describes ICMP as to monitor/debug IP networks; but redirect is not.

> Classification of existing message types
> ========================================
> - The enumeration of existing message types is distracting. Even worse, somebody is going to point to one of the totally undocumented ICMPv4 codes and ask you how you know what it was supposed to do.
> 
> I would replace the list with a bold assertion that *most* existing ICMP messages fall within the three categories listed above.
> 

This also makes sense.

> New Section
> ===========
> After your discussion of the management and control plane, please add a new section that enumerates management and control functions that ICMP should not assume. Make a point of saying that the list is not exhaustive. The list should include:
> 
> - probing routers to discover router state (like SNMP GET)
> - reporting anomalies other than failure to forward a packet (like SNMP TRAPS and NOTIFICATIONS)
> - distributing off-link routing information (like OSPF)

The offlink is a good modifier. Where is RPL in this?

Thanks,

-- Carlos.

> - <can you think of more>
> 
> --------------------------
> Ron Bonica
> vcard:       www.bonica.org/ron/ronbonica.vcf
> 
> 
> _______________________________________________
> tig-diagnostics mailing list
> tig-diagnostics@ietf.org
> https://www.ietf.org/mailman/listinfo/tig-diagnostics
>