Draft: draft-ietf-quic-transport

Commentary: 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 . 
 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 .
Paragraph (version A):
If the spin bit is enabled for the connection, the endpoint maintains
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.
Paragraph (version A):
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.
Paragraph (version A):
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.
Paragraph (version A):
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.
Paragraph (version B):
If the spin bit is enabled for the connection, the endpoint maintains
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.
Paragraph (version B):
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.
Paragraph (version B):
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.
Paragraph (version B):
An endpoint resets the spin value for a network path to zero when
changing the connection ID being used on that network path.