Original text:
4.7.  It is expected that any QoS handling in the network, e.g. based on use of DiffServ Code Points (DSCPs) RFC2475 as well as Equal-Cost Multi-Path (ECMP) routing, is applied on a per flow-basis (and not exact recovery mechanism is used and therefore reordering tolerance should be considered as unknown. <del> 4.8. </del>  QUIC Connection IDs are opaque byte fields that are expressed consistently across all QUIC versions QUIC-INVARIANTS, see rebinding. timeout on UDP NATs might be tempting in light of this property, but not all QUIC server deployments will be robust to rebinding. <del> 4.8.1. </del>  NATs sometimes hit an operational limit where they exhaust available public IP addresses and ports, and must evict flows from their violates the best common practice to avoid "port overloading" as described in RFC4787. <del> 4.8.2. </del>  Concealing client address changes in order to simplify operational routing issues will mask important signals that drive security to the attacker address and thus allow an observer to break the connection. <del> 4.9. </del>  RFC4787 describes possible packet filtering behaviors that relate to NATs.  Though the guidance there holds, a particularly unwise

Reviewer comments:
addresses
Should this ID have some mention of ICMP, because support for ICMP with UDP is a known issue for many stacks, and QUIC seems to have thought this through and we can pass that on. So, I think some mention of the use of ICMP would be helpful - at least to refer to the appropriate sections in the QUIC transport spect
I would think this would be handled by the QUIC implementation transparently and therefore it's not in the applicability statement that is directed at application designers who rather use an existing QUIC library. Or what exactly is the advise you would like to see here?
Actually, I was suggesting somewhere just to say something about ICMP because some endpoints didn't traditionally pass ICMP to UDP - this could be manageability rather than applicability?: "QUIC stacks can be designed to receive and safely utilise received ICMP messages when these are provided by the endpoint (e.g to assist PMTUD), but do not rely upon them to function."
Okay, let me think we anything like this belongs. I believe, as you say, manageability might make more sense.
We merged the PR as it seems uncontroversial but I leave the issue open for now, so we don't forget to mention this new section in the meeting.

Revised text:
4.7. <ins> Datagram Packetization Layer PMTU Discovery (PLPMTUD) can be used by QUIC to probe for the supported PMTU.  PLPMTUD optionally uses ICMP messages (e.g., IPv6 Packet Too Big messages).  Given known attacks with the use of ICMP messages, the use of PLPMTUD in QUIC has been designed to safely use but not rely on receiving ICMP feedback (see Section 14.2.1. of QUIC-TRANSPORT). Networks are recommended to forward these ICMP messages and retain as much of the original packet as possible without exceeding the minimum MTU for the IP version when generating ICMP messages as recommended in RFC1812 and RFC4443. 4.8. </ins> It is expected that any QoS handling in the network, e.g. based on use of DiffServ Code Points (DSCPs) RFC2475 as well as Equal-Cost Multi-Path (ECMP) routing, is applied on a per flow-basis (and not exact recovery mechanism is used and therefore reordering tolerance should be considered as unknown.  <ins> 4.9. </ins> QUIC Connection IDs are opaque byte fields that are expressed consistently across all QUIC versions QUIC-INVARIANTS, see rebinding. timeout on UDP NATs might be tempting in light of this property, but not all QUIC server deployments will be robust to rebinding.  <ins> 4.9.1. </ins> NATs sometimes hit an operational limit where they exhaust available public IP addresses and ports, and must evict flows from their violates the best common practice to avoid "port overloading" as described in RFC4787.  <ins> 4.9.2. </ins> Concealing client address changes in order to simplify operational routing issues will mask important signals that drive security to the attacker address and thus allow an observer to break the connection.  <ins> 4.10. </ins> RFC4787 describes possible packet filtering behaviors that relate to NATs.  Though the guidance there holds, a particularly unwise