Subject: Mirja Kühlewind's No Objection on draft-ietf-6man-icmp-limits-07: (with COMMENT)

From: Mirja Kühlewind via Datatracker <[email-masked]>
Date: Tue, 10 Mar 2020 10:20:20 -0700

Mirja Kühlewind 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:
----------------------------------------------------------------------

Question(s):

In section 1 you say " New ICMPv6 code points are defined as an update to
[RFC4443]." Should this document actually update RFC4443?

And in section 2.2 you have:
"   [RFC8200] specifies that a destination host should send an
   "unrecognized next header type" when a Next Header value is
   unrecognized in a packet. This document extends this to allow
   intermediate nodes to send this same error for a packet that is
   discarded because the node does not recognize a Next Header type."
Does this document also update RFC8200?

Comment(s):

Editorial in Sec 5.3.1:
"      * Increasing prevalence of deep packet inspection in middleboxes.
        In particular, many intermediate nodes now parse network layer
        encapsulation protocols or transport layer protocols."
This sounds like DPI is a reason for longer headers but I think you only mean
DPI is a reason for in-network processing. Maybe you can clarify this!

Also I agree with Roman's points and the TSV-ART feedback (Thanks Bernard!)
that the security considerations section could be a bit more extensive and a
mentioning of PMTU discovery would be good as well. I saw that there was a
reply by the author to the TSV-ART review on March 5 but no updates submitted
yet.

---

From: Tom Herbert <[email-masked]>
Date: Thu, 12 Mar 2020 14:51:29 -0700

Hi Mirja,

Thanks for the review! Comments in-line.

Tom

> https://datatracker.ietf.org/doc/draft-ietf-6man-icmp-limits/
Is this appropriate for adding new ICMP codes?

> Does this document also update RFC8200?
A new code will be used instead of extending the existing one in
RFC8200, so maybe not?

> DPI is a reason for in-network processing. Maybe you can clarify this!
Trying to say that increased DPI in the network at intermediate nodes
is one thing driving "The trend towards longer and more complex
headers and header chains needing to be processed by end nodes, as
well as intermediate nodes". Is there a better work do word that?

> reply by the author to the TSV-ART review on March 5 but no updates submitted

Yes, will submit an update once IESG review it complete (which looks
like it is now).

>
>
>
> --------------------------------------------------------------------
> IETF IPv6 working group mailing list
> [email-masked]
> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
> --------------------------------------------------------------------