Change:
ports RFC8085 and, when possible, connection IDs to an active QUIC session. <del> Further validation can also be provided: An IPv4 endpoint could set the Don't Fragment (DF) bit on a small proportion of packets, so that most invalid ICMP messages arrive when there are no DF packets outstanding, and can therefore be identified as spurious. An endpoint could store additional information from the IP or UDP headers to use for validation (for example, the IP ID or UDP checksum). </del> The endpoint SHOULD ignore all ICMP messages that fail validation. <del> An endpoint MUST NOT increase PMTU based on ICMP messages.  Any reduction in the QUIC maximum packet size MAY be provisional until </del> <ins> An endpoint MUST NOT increase PMTU based on ICMP messages; see Section 3, clause 6 of DPLPMTUD.  Any reduction in the QUIC maximum packet size in response to ICMP messages MAY be provisional until </ins> QUIC's loss detection algorithm determines that the quoted packet has actually been lost.

Discussion:
A few minor tweaks based on review of the latest DPLPMTUD draft. If I never have to type DPLPMTUD ever again, I'll be happy.
These comments relate only to the PMTU text in -24, relative to the current DPLPMTUD text as that now progresses to WGLC. /This can also be used to construct PMTU probes (see Section 14.3.1). / Is this necessary? Or can padding frames be used to make (PL)PMTU probes?. My confusion here may be linked to not understanding the intent of 14.3.1 /Further validation can also be provided: o An IPv4 endpoint could set the Don't Fragment (DF) bit on a small proportion of packets, so that most invalid ICMP messages arrive when there are no DF packets outstanding, and can therefore be identified as spurious. o An endpoint could store additional information from the IP or UDP headers to use for validation (for example, the IP ID or UDP checksum)./ I suggest the above text is spurious, since the checks advocated in DPLPMTUD and the QUIC fields provide a way to detect this. While it is possible too toggle the DF field, I do no think the IETF should endorse this, because it can have other side effects and this is not the place to propose that method. /An endpoint MUST NOT increase PMTU based on ICMP messages. / DPLPMTUD already specifies. This has always been the case, so please either delete or cite DPLPMTUD or the two core IP specs. Section 14.3.1 I didn’t understand section 14.3.1. Maybe that isn’t good since I do understand PMTUD and PLPMTUD. Perhaps this section requires some reworking to explain the goal.
Tentatively marking this as editoral; if something design-y pops up when processing please ping.
Let me see if I can break this down a little. cc NAME for his opinion of these. : The first and last comment relates to the section on using coalescing to help the routing of ICMP messages. I had no difficulty reading this section, though I might suggest one tweak: The "further validation" text: DF is currently mandated, but this text pre-dates that requirement.

We should drop that clause. And the other clause is a little lame. I'd be happy dropping all of the quoted text. Citing DPLPMTUDTD is sensible and we should do that.
Thanks, LG