Original text:
handshake packet from the server indicates the willingness of the server to communicate with the client. <del> The QUIC header optionally contains a connection ID which can be used as additional entropy beyond the 5-tuple, if needed.  The QUIC handshake needs to be observed in order to understand whether the connection ID is present and what length it has.  However, connection IDs may be renegotiated during after the handshake, and this renegotiation is not visible to the path.  Using the connection ID as a flow key field for stateful treatment of flows may therefore cause undetectable and unrecoverable loss of state in the middle of a connection.  Use of connection IDs is specifically discouraged for NAT applications. If a NAT hits an operational limit, it is recommended to rather drop the initial packets of a flow (see also sec-filtering), which potentially triggers a fallback to TCP, than using the connection ID to muliplex mulitple connections on the same IP address port pair which risks connectivity breakage later, in case the connection ID changes. </del>  4.3.

Reviewer comments:
Comment from PR from NAME on UDP policing: "This is recommending something that relies on the 4-tuple, but particularly if there's another NAT involved, the 4-tuple may not be stable. So this puts connections in a situation where the handshake completes, they use the connection for a bit, a NAT rebind occurs, and then the connection is blackholed. There are defenses against this problem, but this seems like a fairly dangerous recommendation."
LG, some editorial comments.

Revised text:
handshake packet from the server indicates the willingness of the server to communicate with the client.  <ins> The QUIC header optionally contains a connection ID which could provide additional entropy beyond the 5-tuple.  The QUIC handshake needs to be observed in order to understand whether the connection ID is present and what length it has.  However, connection IDs may be renegotiated after the handshake, and this renegotiation is not visible to the path.  Therefore using the connection ID as a flow key field for stateful treatment of flows is not recommended as connection ID changes will cause undetectable and unrecoverable loss of state in the middle of a connection.  Specially, the use of the connection ID for functions that require state to make a forwarding decison is not viable as it will break connectivity or at minimum cause long timeout-based delays before this problem is detected by the endpoints and the connection can potentially be re-established. QUIC endpoints support address migration and a QUIC connection can survive a change of the IP address or ports by mapping the connection ID, if present, to an existing connection.  Ideally a new connection ID is used at the same time when the address/port changes to avoid linkability.  As new connection IDs belonging to the same connection are not known to on-path devices, network devices are not able to map QUIC connections after a 4-tuple change.  As such, when the 4-tuple changes, stateful devices lose their state and break connectivity if state is required for forwarding, while the endpoints would otherwise survive such a change. Use of connection IDs is specifically discouraged for NAT applications.  If a NAT hits an operational limit, it is recommended to rather drop the initial packets of a flow (see also sec- filtering), which potentially triggers a fallback to TCP, than using the connection ID to muliplex mulitple connections on the same IP address port pair which risks connectivity breakage later, in case the connection ID changes. </ins> 4.3.