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

Ronald Bonica <rbonica@juniper.net> Tue, 04 September 2012 16:03 UTC

Return-Path: <rbonica@juniper.net>
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 8F96411E80A3 for <tig-diagnostics@ietfa.amsl.com>; Tue, 4 Sep 2012 09:03:07 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -106.599
X-Spam-Level:
X-Spam-Status: No, score=-106.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, 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 w8ec1LSG0h3Q for <tig-diagnostics@ietfa.amsl.com>; Tue, 4 Sep 2012 09:03:06 -0700 (PDT)
Received: from exprod7og119.obsmtp.com (exprod7og119.obsmtp.com [64.18.2.16]) by ietfa.amsl.com (Postfix) with ESMTP id BF0BD11E808A for <tig-diagnostics@ietf.org>; Tue, 4 Sep 2012 09:03:06 -0700 (PDT)
Received: from P-EMHUB02-HQ.jnpr.net ([66.129.224.36]) (using TLSv1) by exprod7ob119.postini.com ([64.18.6.12]) with SMTP ID DSNKUEYmOkLJJEey/UMoSukg11EEwAByJ4Ea@postini.com; Tue, 04 Sep 2012 09:03:06 PDT
Received: from P-CLDFE01-HQ.jnpr.net (172.24.192.59) by P-EMHUB02-HQ.jnpr.net (172.24.192.36) with Microsoft SMTP Server (TLS) id 8.3.213.0; Tue, 4 Sep 2012 09:00:44 -0700
Received: from p-emfe02-wf.jnpr.net (172.28.145.25) by p-cldfe01-hq.jnpr.net (172.24.192.59) with Microsoft SMTP Server (TLS) id 14.1.355.2; Tue, 4 Sep 2012 09:00:44 -0700
Received: from EMBX01-WF.jnpr.net ([fe80::1914:3299:33d9:e43b]) by p-emfe02-wf.jnpr.net ([fe80::c126:c633:d2dc:8090%11]) with mapi; Tue, 4 Sep 2012 12:00:44 -0400
From: Ronald Bonica <rbonica@juniper.net>
To: "tig-diagnostics@ietf.org" <tig-diagnostics@ietf.org>
Date: Tue, 4 Sep 2012 12:00:42 -0400
Thread-Topic: draft-shore-icmp-aup-01
Thread-Index: Ac2Ktm/P6S0b7V/lRvupRDBu4ypcXw==
Message-ID: <13205C286662DE4387D9AF3AC30EF456D782C5873F@EMBX01-WF.jnpr.net>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
acceptlanguage: en-US
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Subject: [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: Tue, 04 Sep 2012 16:03:07 -0000

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.

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

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.

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.

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)
- <can you think of more>

--------------------------
Ron Bonica
vcard:       www.bonica.org/ron/ronbonica.vcf