Change:
We've not been capitalizing this in the main spec; so nor should this document. I've fixed those cases that I've touched in my upcoming PR, but it's going to need more work to clean up properly.
Yep, will do that after we merged the PRs. Thanks!

Discussion:
of 15 seconds, but recommends larger values, or omitting keepalive entirely. <del> By using a Connection ID, QUIC is designed to be robust to NAT </del> <ins> By using a connection ID, QUIC is designed to be robust to NAT </ins> address rebinding after a timeout.  However, this only helps if one endpoint maintains availability at the address its peer uses, and the peer is the one to send after the timeout occurs.

QUIC supports connection migration by the client.  If a lower-layer address changes, a QUIC endpoint can still associate packets with an <del> existing connection using the Destination Connection ID field (see </del> <ins> existing connection using the Destination connection ID field (see </ins> also connid) in the QUIC header, unless a zero-length value is used. This supports cases where address information changes, such as NAT rebinding, intentional change of the local interface, or based on an

connection IDs), the short header exposes at most only a single connection ID. <del> Aside from the Destination Connection ID field of the first packets </del> <ins> Aside from the destination connection ID field of the first packets </ins> sent by clients, the connection ID can be zero length.  This is a choice that is made by each endpoint individually. An endpoint that selects a zero-length connection ID will receive <del> packets with a zero-length Destination Connection ID.  The endpoint </del> <ins> packets with a zero-length destination connection ID.  The endpoint </ins> needs to use other information, such as its IP address and port number to identify which connection is referred to.  An endpoint can choose to use the source IP address and port on datagrams, but this

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 <del> Connection ID in that packet and the client will retry by sending another Client Initial packet with the server-selected Connection ID. </del> <ins> connection ID in that packet and the client will retry by sending another Client Initial packet with the server-selected connection ID. </ins> This mechanism can be used to redirect a connection to a different server, e.g. due to performance reasons or when servers in a server pool are upgraded gradually, and therefore may support different versions of QUIC.  In this case, it is assumed that all servers belonging to a certain pool are served in cooperation with load <del> balancers that forward the traffic based on the Connection ID.  A server can choose the Connection ID in the Server Retry packet such </del> <ins> balancers that forward the traffic based on the connection ID.  A server can choose the connection ID in the Server Retry packet such </ins> that the load balancer will redirect the next Client Initial packet to a different server in that pool.  Alternatively the load balancer can directly offer a Retry services as further described in QUIC-LB.