Subject: Alvaro Retana's No Objection on draft-ietf-6man-icmp-limits-07: (with COMMENT)

From: Alvaro Retana via Datatracker <[email-masked]>
Date: Mon, 09 Mar 2020 08:32:19 -0700

Alvaro Retana has entered the following ballot position for
draft-ietf-6man-icmp-limits-07: No Objection

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)

Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html
for more information about IESG DISCUSS and COMMENT positions.

The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-6man-icmp-limits/

----------------------------------------------------------------------
COMMENT:
----------------------------------------------------------------------

(1) There are a couple of normative statements that left me wanting more
details.  For the cases below, I have these questions (to start with):  Are
there more details on how this is done?  Are the actions implementation
dependent?  Should these sentences even use rfc2119 keywords?  How can they be
normatively enforced?

   - §4.2: "The packet in the ICMP data SHOULD be validated to match the upper
   layer process or connection that generated the original packet."  What if
   the validation fails?

   - §4.2: "A host MAY modify its usage of protocol headers in subsequent
   packets to avoid repeated occurrences of the same error."

   - §4.2: "A host system SHOULD take appropriate action if it is creating
   packets with extension headers on behalf of the application."  What is an
   "appropriate action"?

(2) §4.2: "An error SHOULD be reported to an application if the application
enabled extension headers for its traffic."

What is an application in the context of this document?  I ask because
traditional applications (email, video) are probably not aware of the use (or
not) of extensions headers in their traffic -- but others (segment routing, for
example) probably are.

(3) §5.1: "...this specification RECOMMENDS the sending of ICMP errors even in
cases where a node might be discarding packets per a nonconformant behavior." 
Recommending conformance when nonconformant behavior already exists sounds a
little naïve to me.  It seems to me that using a lower case "RECOMMENDS" (BTW,
the actual keyword is "RECOMMENDED".) would achieve the same thing.

(4) §6: "The ICMP errors described in this document MAY be filtered by
firewalls in accordance with [RFC4890]."  s/MAY/may  In this case the text is
just making a statement of fact.

(5) Consider moving §5 closer to the beginning of the document.  Maybe it makes
more sense there.