An Acceptable Use Policy for New ICMP Types and Codes
draft-shore-icmp-aup-12

The latest version cleans things up even further. Thanks!

I am now reduced to a few minor Comments that I will leave for the authors and responsible AD to debate. No need to come back to me unless you want to.

===

Continuing with Section 2.1.1. You have

   From a more pragmatic
   perspective, some of the key characteristics of ICMP do not support
   using it as a routing protocol.  Those include...

I wonder whether the issue is the word "support" or the generality of the statement you make about "a routing protocol". It is clear to me that, not withstanding all of the characteristics of ICMP, RPL is a routing protocol.

I would suggest either:
s/do not support using it as/make it a less than ideal choice for/
or
s/as a routing protocol/as a routing protocol in the Internet/

(or both)

---

And continuing the conversation about 2.1.2. You have
   
   RPL...
   ... the expansion of its acronym appears
   to be an actual general routing protocol.

This "appears" is really annoying me. We, in the IETF, have access to the RFCs and can look them up. RPL *is* a routing protocol.

I suggest replacing the whole paragraph as...

   RPL, the IPv6 Routing protocol for low-power and lossy networks (see
   [RFC6550]) uses ICMP as a transport.  In this regard it is an exception among the
   ICMP message types.  Note that, although RPL is an IP routing protocol, it is not
   deployed on the general Internet, but is limited to specific, contained networks.

I have absolutely no objection to this document.  The only comment I have is that (modulo Pete's comment) I think it should be Standards Track (an Applicability Statement), and not BCP.  It's not worth arguing about it and holding anything up for that, but I'll note that, as it was last called as BCP, the IESG can decide to change the status without causing any delay to the document.

Thanks for addressing my DISCUSS points.

Was odd to see photuris dredged up here. Since it lost out to isakmp / IKE around 1996 I'm not sure that  it's illustrative of much with respect to ICMP except as a side channel into the inner-workings of the ipsec working-group.

I find on revisiting this that I'm somewhat unsatisfied with the ontology described in section 4 (something it admits to). the premise of and AUP hinges in fact no there being appropriate or inappropriate actions.

I doubt this is really discuss-worthy however.

I have no objection to the publication of this draft, if this is the stick to keep bad ideas about extending ICMP away.

Benoit has told me that this *does* have reasonable consensus.

I have no objection to publishing this draft, but the current discussions taking place during IESG Evaluation seem to identify changes that would be very helpful if the document reflected at least some of them.

- I'm not sure that AUP is a good term here really

- I guess discussion of Brian's discuss might sort out
this comment but I didn't find the acceptable uses
described at the top of section 2 clear.

- Would it be worth adding something to the security
considerations that e.g. new ICMP stuff needs to 
consider how ICMP can be abused (e.g. [1])?

   [1] https://www.nordu.net/articles/smurf.html

The text is considerably improved since I last looked at it.