Barry Leiba's No Objection on draft-ietf-6man-icmp-limits-07: (with COMMENT)

[Barry Leiba via Datatracker <[e-mail]>]

Barry Leiba 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:
----------------------------------------------------------------------

The correct intended status in the header is “Proposed Standard”.

— Abstract —

   Network nodes may discard packets if they are unable to process
   protocol headers of packets due to processing constraints or limits.

May they discard packets if they are unable to process protocol headers of
*other* packets?  Or are you talking about the protocol headers of the packets
being discarded?  The latter, yes?  So, “if they are unable to process those
packets’ protocol headers” (or “of those packets”).

   When such packets are dropped, the sender receives no indication so
   it cannot take action to address the cause of discarded packets.

This sounds like the reason it receives no indication is to prevent it from
taking action. I would say, “receives no indication, thus it cannot”.

— Section 1 —

   New ICMPv6 code points are defined as an update to [RFC4443].

The document header does not say that this “updates” 4443.  Do you maybe mean
“as an extension to RFC4443”?

— Section 1.1 —
RFC 8200 does not capitalize “extension header” nor “upper-layer header”; is
there a reason you do in this document?  Shouldn’t this be consistent with 8200?

— Section 1.3 —
Éric already got this: Please use the new BCP 14 boilerplate and add a
normative reference to RFC8174.

— Section 3.2 —

         This error is sent in response to a node dropping a packet
         because the aggregate header chain exceeds the processing
         limits of a node.

I’m confused, so maybe I just am not understanding:  this says that Destination
Unreachable / headers too long is sent *not* by the note that dropped the
packet, but *in response* to that node?  What an I missing?  Should this maybe
say this instead?:

NEW
         This error response is sent when a node drops a packet
         because the aggregate header chain exceeds the processing
         limits of the node.
END