Change:
number field is encoded in Packet Number Length field.  See packet-encoding for details. <del> Packets with a short header always include a 1-RTT protected payload. </del> <ins> 1-RTT packets always include a 1-RTT protected payload. </ins> The header form bit and the connection ID field of a short header packet are version-independent.  The remaining fields are specific to the selected QUIC version.  See QUIC-INVARIANTS for details on how packets from different versions of QUIC are interpreted. <del> 17.3.1. </del> <ins> 17.4. </ins> <del> The latency spin bit enables passive latency monitoring from observation points on the network path throughout the duration of a connection.  The server reflects the spin value received, while the client 'spins' it after one RTT.  On-path observers can measure the time between two spin bit toggle events to estimate the end-to-end RTT of a connection. </del> <ins> The latency spin bit, which is defined for 1-RTT packets (packet- 1rtt), enables passive latency monitoring from observation points on the network path throughout the duration of a connection.  The server reflects the spin value received, while the client 'spins' it after one RTT.  On-path observers can measure the time between two spin bit toggle events to estimate the end-to-end RTT of a connection. </ins> <del> The spin bit is only present in the short packet header, since it is possible to measure the initial RTT of a connection by observing the </del> <ins> The spin bit is only present in 1-RTT packets, since it is possible to measure the initial RTT of a connection by observing the </ins> handshake.  Therefore, the spin bit is available after version negotiation and connection establishment are completed.  On-path measurement and use of the latency spin bit is further discussed in QUIC-MANAGEABILITY. <del> The spin bit is an OPTIONAL feature of QUIC.  A QUIC stack that chooses to support the spin bit MUST implement it as specified in this section. </del> <ins> The spin bit is an OPTIONAL feature of this version of QUIC.  A QUIC stack that chooses to support the spin bit MUST implement it as specified in this section. </ins> Each endpoint unilaterally decides if the spin bit is enabled or disabled for a connection.  Implementations MUST allow administrators

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.