Change:
connection ID. If the spin bit is enabled for the connection, the endpoint maintains <del> 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 </del> <ins> a spin value for each network path and sets the spin bit in the packet header to the currently stored value when a 1-RTT packet is sent on that path.  The spin value is initialized to 0 in the endpoint for each network path.  Each endpoint also remembers the </ins> highest packet number seen from its peer on each path. <del> 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. </del> <ins> When a server receives a 1-RTT 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. </ins> <del> 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. </del> <ins> When a client receives a 1-RTT 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. </ins> An endpoint resets the spin value for a network path to zero when changing the connection ID being used on that network path.

Discussion:
This PR restructures 17.3 to be aligned with 17.2. Note that while the diff seems to show whole paragraphs changed in the section, all I've done is replaced with . Note that I've not replaced all uses of . I've retained it where it is used alongside , for symmetry. This still touches more text than I had hoped, but it makes the structure of Section 17 clearer.
NAME Thanks for the note. I've updated the tls doc, but I've left most uses of as they are. I've retained them for symmetry, since in all the ones I've retained, it appears alongside .
While the transport draft talks a lot about "1-RTT packets", the term is not defined. We also have a sentence that seem to imply that a long-header variant of 1-RTT packets might exist (URL). We refer to the packet less frequently as "short header packets" or "packet with a short header." As a resolution, I think we might want to change the title of section 17.3 from "Short Header Packets" to "1-RTT Packets". Rest of the text can remain the same, as the first sentence of that section says that it is the only type of short header packet that we define.
Update: I think we might want to make corresponding changes to the TLS draft. Re TLS draft, I think we can replace all the occurrences of "short header packet(s)", "packet(s) with (a) short header" in the TLS draft with "1-RTT packet(s)", as well making necessary changes to table 1.This looks good. The actual changes are much smaller than the diff appears, and I think the symmetry with 17.2 helps readability despite the extra layer.