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

["Carlos Pignataro (cpignata)" <[e-mail]>]

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
> [e-mail]
> https://www.ietf.org/mailman/listinfo/tig-diagnostics
>