Change:
Individual commits break this down, but this is all fairly prosaic stuff..
Thanks for clarifying and for fixing the one awkward case.

Discussion:
as sending a Stateless Reset. An endpoint cannot determine the Source Connection ID from a packet <del> with a short header, therefore it cannot set the Destination </del> <ins> with a short header; therefore, it cannot set the Destination </ins> Connection ID in the Stateless Reset.  The Destination Connection ID will therefore differ from the value used in previous packets.  A random Destination Connection ID makes the connection ID appear to be

against all previous values, but a duplicate value MAY be treated as a connection error of type PROTOCOL_VIOLATION. <del> Note that Stateless Reset packets do not have any cryptographic protection. </del> <ins> Note that Stateless Resets do not have any cryptographic protection. </ins> 10.3.3.

sufficient to prevent looping.  In the event of a loop, this results in packets eventually being too small to trigger a response. <del> An endpoint can remember the number of Stateless Reset packets that it has sent and stop generating new Stateless Reset packets once a limit is reached.  Using separate limits for different remote addresses will ensure that Stateless Reset packets can be used to close connections when other peers or connections have exhausted limits. A Stateless Reset packet that is smaller than 41 bytes might be identifiable as a Stateless Reset packet by an observer, depending upon the length of the peer's connection IDs.  Conversely, not sending a Stateless Reset packet in response to a small packet might result in Stateless Reset packets not being useful in detecting cases of broken connections where only very small packets are sent; such failures might only be detected by other means, such as timers. </del> <ins> An endpoint can remember the number of Stateless Resets that it has sent and stop generating new Stateless Resets once a limit is reached.  Using separate limits for different remote addresses will ensure that Stateless Resets can be used to close connections when other peers or connections have exhausted limits. A Stateless Reset that is smaller than 41 bytes might be identifiable as a Stateless Reset by an observer, depending upon the length of the peer's connection IDs.  Conversely, not sending a Stateless Reset in response to a small packet might result in Stateless Resets not being useful in detecting cases of broken connections where only very small packets are sent; such failures might only be detected by other means, such as timers. </ins> 11.

current maximum datagram size, referred to as PMTU probes.  All QUIC packets that are not sent in a PMTU probe SHOULD be sized to fit within the maximum datagram size to avoid the datagram being <del> fragmented or dropped BCP145. </del> <ins> fragmented or dropped RFC8085. </ins> If a QUIC endpoint determines that the PMTU between any pair of local and remote IP addresses cannot support the smallest allowed maximum

the payload of an ICMP message to associate the message with a corresponding transport connection (see Section 4.6.1 of DPLPMTUD). ICMP message validation MUST include matching IP addresses and UDP <del> ports BCP145 and, when possible, connection IDs to an active QUIC </del> <ins> ports RFC8085 and, when possible, connection IDs to an active QUIC </ins> session.  The endpoint SHOULD ignore all ICMP messages that fail validation.

In packet types that contain a Packet Number field, the least significant two bits (those with a mask of 0x03) of byte 0 contain <del> the length of the packet number, encoded as an unsigned two-bit integer that is one less than the length of the Packet Number </del> <ins> the length of the Packet Number field, encoded as an unsigned two- bit integer that is one less than the length of the Packet Number </ins> field in bytes.  That is, the length of the Packet Number field is the value of this field plus one.  These bits are protected using header protection; see Section 5.4 of QUIC-TLS.

This field is 1 to 4 bytes long.  The packet number is protected using header protection; see Section 5.4 of QUIC-TLS.  The length <del> of the packet number field is encoded in the Packet Number Length </del> <ins> of the Packet Number field is encoded in the Packet Number Length </ins> bits of byte 0; see above. This is the payload of the packet - containing a sequence of

If an endpoint receives a NEW_CONNECTION_ID frame that repeats a previously issued connection ID with a different Stateless Reset <del> Token or a different sequence number, or if a sequence number is used for different connection IDs, the endpoint MAY treat that receipt as a connection error of type PROTOCOL_VIOLATION. </del> <ins> Token field value or a different Sequence Number field value, or if a sequence number is used for different connection IDs, the endpoint MAY treat that receipt as a connection error of type PROTOCOL_VIOLATION. </ins> The Retire Prior To field applies to connection IDs established during connection setup and the preferred_address transport

The Source and Destination Connection ID fields are the primary means of protection against an off-path attack during the handshake; see validate-handshake.  These are required to match those set by a peer. <del> Except for Initial and Stateless Reset packets, an endpoint only </del> <ins> Except for Initial packets and Stateless Resets, an endpoint only </ins> accepts packets that include a Destination Connection ID field that matches a value the endpoint previously chose.  This is the only protection offered for Version Negotiation packets.