Original text:
7.  QUIC connections are closed either by expiration of an idle timeout or by an explicit indication of the application that a connection should be closed (immediate close).  While data could still be send keep-alives messages.  See {#resumption-v-keepalive} for further guidance. <del> 8. </del>  QUIC exposes some information to the network in the unencrypted part of the header, either before the encryption context is established, Connection IDs), the short header exposes at most only a single Connection ID. <del> 8.1. </del>  QUIC supports a server-generated Connection ID, transmitted to the client during connection establishment (see Section 6.1 of QUIC). The best way to obscure an encoding is to appear random to observers, which is most rigorously achieved with encryption. <del> 8.2. </del>  While sufficiently robust connection ID generation schemes will mitigate linkability issues, they do not provide full protection. migrations to attempt to increase the number of simultaneous migrations at a given time, or through other means. <del> 8.3. </del>  QUIC provides a Server Retry packet that can be sent by a server in response to the Client Initial packet.  The server may choose a new that the load balancer will redirect the next Client Initial packet to a different server in that pool. <del> 9. </del>  Versioning in QUIC may change the protocol's behavior completely, except for the meaning of a few header fields that have been declared specification QUIC-TLS.  This split is performed to enable light- weight versioning with different cryptographic handshakes. <del> 10. </del>  QUIC provides integrity protection for its version negotiation process.  This process assumes that the set of versions that a server version in Version Negotiation packets, then the old version is no longer accepted. <del> 11. </del>  This document has no actions for IANA. <del> 12. </del>  See the security considerations in QUIC and QUIC-TLS; the security considerations for the underlying transport protocol are relevant for connection SHOULD fail to allow the application to explicitly handle fallback to a less-secure alternative.  See fallback. <del> 13. </del>  This work is partially supported by the European Commission under Horizon 2020 grant agreement no. 688421 Measurement and Architecture

Reviewer comments:
addresses issue
I think the applicability draft may benefit from exploring connection migration strategies as described in: URL
Do we also need to say anything about use of 0-byte CID? See quicwg/base-drafts
The transport draft already says:
addressed by PR and one more sentence
I don’t see any text related to connection migration on that PR.
sorry wrong PR; should be and is already merged
good modulo typos

Revised text:
7. <ins> QUIC supports connection migration.  Even if lower-layer addresses (usually the 4-tuple of IP addresses and ports) changes, QUIC packets can still be associated with an existing connection based on the Connection ID (see also section connid) in the QUIC header, if present.  This supports cases where address information changes due to e.g.  NAT rebinding or change of the local interface.  Currently QUIC only supports failover cases.  Only one "path" can be used at a time, and as soon as the new path is validated all traffic will be switched over to the next path. 8. </ins> QUIC connections are closed either by expiration of an idle timeout or by an explicit indication of the application that a connection should be closed (immediate close).  While data could still be send keep-alives messages.  See {#resumption-v-keepalive} for further guidance.  <ins> 9. </ins> QUIC exposes some information to the network in the unencrypted part of the header, either before the encryption context is established, Connection IDs), the short header exposes at most only a single Connection ID.  <ins> 9.1. </ins> QUIC supports a server-generated Connection ID, transmitted to the client during connection establishment (see Section 6.1 of QUIC). The best way to obscure an encoding is to appear random to observers, which is most rigorously achieved with encryption.  <ins> 9.2. </ins> While sufficiently robust connection ID generation schemes will mitigate linkability issues, they do not provide full protection. migrations to attempt to increase the number of simultaneous migrations at a given time, or through other means.  <ins> 9.3. </ins> QUIC provides a Server Retry packet that can be sent by a server in response to the Client Initial packet.  The server may choose a new that the load balancer will redirect the next Client Initial packet to a different server in that pool.  <ins> 10. </ins> Versioning in QUIC may change the protocol's behavior completely, except for the meaning of a few header fields that have been declared specification QUIC-TLS.  This split is performed to enable light- weight versioning with different cryptographic handshakes.  <ins> 11. </ins> QUIC provides integrity protection for its version negotiation process.  This process assumes that the set of versions that a server version in Version Negotiation packets, then the old version is no longer accepted.  <ins> 12. </ins> This document has no actions for IANA.  <ins> 13. </ins> See the security considerations in QUIC and QUIC-TLS; the security considerations for the underlying transport protocol are relevant for connection SHOULD fail to allow the application to explicitly handle fallback to a less-secure alternative.  See fallback.  <ins> 14. </ins> This work is partially supported by the European Commission under Horizon 2020 grant agreement no. 688421 Measurement and Architecture