Change:
14.3.1. <del> Endpoints that rely on the destination connection ID for routing QUIC packets are likely to require that the connection ID be included in PMTU probe packets to route any resulting ICMP messages (icmp-pmtud) back to the correct endpoint.  However, only long header packets (long-header) contain source connection IDs, and long header packets are not decrypted or acknowledged by the peer once the handshake is complete.  One way to construct a PMTU probe is to coalesce (see </del> <ins> Endpoints that rely on the destination connection ID for routing incoming QUIC packets are likely to require that the connection ID be included in PMTU probe packets to route any resulting ICMP messages (icmp-pmtud) back to the correct endpoint.  However, only long header packets (long-header) contain source connection IDs, and long header packets are not decrypted or acknowledged by the peer once the handshake is complete. One way to construct a probe for the path MTU is to coalesce (see </ins> packet-coalesce) a Handshake packet (packet-handshake) with a short header packet in a single UDP datagram.  If the UDP datagram reaches the endpoint, the Handshake packet will be ignored, but the short <del> header packet will be acknowledged.  If the UDP datagram elicits an ICMP message, that message will likely contain the source connection ID within the quoted portion of the UDP datagram. </del> <ins> header packet will be acknowledged.  If the UDP datagram causes an ICMP message to be sent, the first part of the datagram will be quoted in that message.  If the the source connection ID is within the quoted portion of the UDP datagram, that could be used for routing. </ins> 15.

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