Change:
14. The QUIC packet size includes the QUIC header and protected payload, <del> but not the UDP or IP header. </del> <ins> but not the UDP or IP headers. </ins> <del> A client MUST expand the payload of all UDP datagrams carrying Initial packets to at least 1200 bytes, by adding PADDING frames to the Initial packet or by coalescing the Initial packet; see packet- coalesce.  Sending a UDP datagram of this size ensures that the network path from the client to the server supports a reasonable Maximum Transmission Unit (MTU).  Padding datagrams also helps reduce the amplitude of amplification attacks caused by server responses toward an unverified client address; see address-validation. </del> <ins> QUIC depends upon a minimum IP packet size of at least 1280 bytes. This is the IPv6 minimum size RFC8200 and is also supported by most modern IPv4 networks.  Assuming the minimum IP header size, this results in a QUIC maximum packet size of 1232 bytes for IPv6 and 1252 bytes for IPv4. The QUIC maximum packet size is the largest size of QUIC packet that can be sent across a network path using a single packet.  Any maximum packet size larger than 1200 bytes can be discovered using Path Maximum Transmission Unit Discovery (PMTUD; see pmtud) or Datagram Packetization Layer PMTU Discovery (DPLPMTUD; see dplpmtud). </ins> Enforcement of the max_udp_payload_size transport parameter (transport-parameter-definitions) might act as an additional limit on <del> packet size.  Exceeding this limit can be avoided once the value is known.  However, prior to learning the value of the transport parameter, endpoints risk datagrams being lost if they send packets larger than 1200 bytes. </del> <ins> the maximum packet size.  A sender can avoid exceeding this limit, once the value is known.  However, prior to learning the value of the transport parameter, endpoints risk datagrams being lost if they send packets larger than the smallest allowed maximum packet size of 1200 bytes. A client MUST expand the payload of all UDP datagrams carrying Initial packets to at least the smallest allowed maximum packet size (1200 bytes) by adding PADDING frames to the Initial packet or by coalescing the Initial packet; see packet-coalesce.  Sending a UDP datagram of this size ensures that the network path from the client to the server supports a reasonable Path Maximum Transmission Unit (PMTU).  This also helps reduce the amplitude of amplification attacks caused by server responses toward an unverified client address; see address-validation. </ins> Datagrams containing Initial packets MAY exceed 1200 bytes if the client believes that the network path and peer both support the size

Discussion:
This is with some minor additional changes: Reflow. Move the odd text about using Handshake back where it belongs. Make the language about how to construct a probe less prescriptive. Mention 1200 when referring to the "smallest allowed maximum packet size" so it is clear what that means.
NAME I went with "PMTU probe packet", which is an IP packet. Let me know if that makes sense.
OK - There are already "IP packets" and "QUIC packets" - so some other term works fro me.
A top-level comment on the term "probing": In Section: Probing a New Path: A packet containing only probing frames is a "probing packet", and a packet containing any other frame is a "non-probing packet". Please be sure that "probe" can not be confused with "probing" in PLPMTUD.
In the subsection on “Packet Size {#packet-size}”, I think the blocks of text describe two things. There is some general guidance on size, and there are specific instructions for the size of the initial packet. I’d suggest we do try to separate these two, it would make it much easier for someone to understand the size constraints for forming the initial packet.
Regarding the sizing of Initial packets, see . I checked the text for probing and we have "PMTUD probe" in one case and "probing packet" elsewhere. It's not ideal, but I didn't see any cases that were clearly busted. I don't have a good idea for alternative labels, but would welcome suggestions.
It turns out that coordinating the publication of all the documents is a real challenge. Right now, DPLPMTUD depends on QUIC, which is fine, but it turns out that this is a problem for other things that depend on DPLPMTUD who now transitively depend on QUIC. QUIC could adopt the DPLPMTUD text that is specific to QUIC and loosen this dependency chain. The text changes are relatively modest, see . While this could be editorial, I think that this will require a consensus call. The nature of the changes is such that it should be treated as design. Also, I think that there are substantive changes required.

So from an AD perspective, draft-ietf-tsvwg-datagram-plpmtud is currently blocking another document (URL) from being published that has a missref on it. Except for this question of QUIC I am ready to approve draft-ietf-tsvwg-datagram-plpmtud. To me it is also clear that integration of DPLPMTUD done in the QUIC WG will result in less editorial clarity issues that potentially could make an future implementer uncertain. As can already been seen in the PR there a few question that potentially can improve the operation and not unnecessary restrict the operation of DPLPMTUD. From my perspective it looks like the core is a set of minor editorial issues to resolve that will make the DPLPMTUD be clearer and resolve the missref issue and function as well as keeping it in the TSVWG document would. If a little bit more effort is invested after the first step then there is potential for additional improvements.