Original text:
connection ID. If the spin bit is enabled for the connection, the endpoint maintains <del> a spin value and sets the spin bit in the short header to the currently stored value when a packet with a short header is sent out. The spin value is initialized to 0 in the endpoint at connection start.  Each endpoint also remembers the highest packet number seen from its peer on the connection. When a server receives a short header packet that increments the highest packet number seen by the server from the client, it sets the spin value to be equal to the spin bit in the received packet. When a client receives a short header packet that increments the highest packet number seen by the client from the server, it sets the spin value to the inverse of the spin bit in the received packet. An endpoint resets its spin value to zero when sending the first packet of a given connection with a new connection ID.  This reduces the risk that transient spin bit state can be used to link flows across connection migration or ID change. </del>  With this mechanism, the server reflects the spin value received, while the client 'spins' it after one RTT.  On-path observers can

Reviewer comments:
This binds the spin-bit state to a network path, which aligns with intent better than the existing language. It's more words, but it is far less ambiguous.
NAME sanity check please? I'll merge this soon either way.
This is likely a case of "we know what we meant," but.... Section 17.3.1 says that the spin bit can be enabled/disabled on a per-connection or per-CID basis, and that: However, a literal reading of this suggests that a client which sets the spin bit on a per-connection basis will revert the spin bit on the main path to zero whenever it uses a new CID to probe on an alternate path. It also has implications for an implementation that uses many active CIDs at once. One resolution is that the current state of the spin bit is maintained on a per-CID basis, and that the CID begins at zero for each CID. However, for the client using many CIDs at once, that then begs the question of which of the peer's CIDs are being reflected back to it. I think that what we actually mean here is two-fold: The current state of the spin bit is maintained on a per-path basis, and is initialized to zero for each path. The current state of the spin bit is reset to zero whenever the CID being used on a path changes, no matter how frequently that is.
I think what you summarize in the bullets is indeed what was intended. NAME

Revised text:
connection ID. If the spin bit is enabled for the connection, the endpoint maintains  <ins> a spin value for each network path and sets the spin bit in the short header to the currently stored value when a packet with a short header is sent on that path.  The spin value is initialized to 0 in the endpoint for each network path.  Each endpoint also remembers the highest packet number seen from its peer on each path. When a server receives a short header packet that increases the highest packet number seen by the server from the client on a given network path, it sets the spin value for that path to be equal to the spin bit in the received packet. When a client receives a short header packet that increases the highest packet number seen by the client from the server on a given network path, it sets the spin value for that path to the inverse of the spin bit in the received packet. An endpoint resets the spin value for a network path to zero when changing the connection ID being used on that network path. </ins> With this mechanism, the server reflects the spin value received, while the client 'spins' it after one RTT.  On-path observers can