Draft: rfc9000

Commentary: Individual commits break this down , but this is all fairly prosaic stuff .. 
 Thanks for clarifying and for fixing the one awkward case .
Paragraph (version A):
An endpoint cannot determine the Source Connection ID from a packet
with a short header, therefore it cannot set the Destination
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
the result of moving to a new connection ID that was provided using a
NEW_CONNECTION_ID frame; see frame-new-connection-id.
Paragraph (version B):
An endpoint cannot determine the Source Connection ID from a packet
with a short header; therefore, it cannot set the Destination
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
the result of moving to a new connection ID that was provided using a
NEW_CONNECTION_ID frame; see frame-new-connection-id.
Paragraph (version A):
Note that Stateless Reset packets do not have any cryptographic
protection.
Paragraph (version B):
Note that Stateless Resets do not have any cryptographic protection.
Paragraph (version A):
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.
Paragraph (version A):
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.
Paragraph (version B):
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.
Paragraph (version B):
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.
Paragraph (version A):
Both DPLPMTUD and PMTUD send datagrams that are larger than the
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
fragmented or dropped BCP145.
Paragraph (version B):
Both DPLPMTUD and PMTUD send datagrams that are larger than the
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
fragmented or dropped RFC8085.
Paragraph (version A):
QUIC endpoints using PMTUD SHOULD validate ICMP messages to protect
from packet injection as specified in RFC8201 and Section 5.2 of
RFC8085.  This validation SHOULD use the quoted packet supplied in
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
ports BCP145 and, when possible, connection IDs to an active QUIC
session.  The endpoint SHOULD ignore all ICMP messages that fail
validation.
Paragraph (version B):
QUIC endpoints using PMTUD SHOULD validate ICMP messages to protect
from packet injection as specified in RFC8201 and Section 5.2 of
RFC8085.  This validation SHOULD use the quoted packet supplied in
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
ports RFC8085 and, when possible, connection IDs to an active QUIC
session.  The endpoint SHOULD ignore all ICMP messages that fail
validation.
Paragraph (version A):
In packet types that contain a Packet Number field, the least
significant two bits (those with a mask of 0x03) of byte 0 contain
the length of the packet number, encoded as an unsigned two-bit
integer that is one less than the length of the Packet Number
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.
Paragraph (version B):
In packet types that contain a Packet Number field, the least
significant two bits (those with a mask of 0x03) of byte 0 contain
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
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.
Paragraph (version A):
If an endpoint receives a NEW_CONNECTION_ID frame that repeats a
previously issued connection ID with a different Stateless Reset
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.
Paragraph (version B):
If an endpoint receives a NEW_CONNECTION_ID frame that repeats a
previously issued connection ID with a different Stateless Reset
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.
Paragraph (version A):
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.
Except for Initial and Stateless Reset packets, an endpoint only
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.
Paragraph (version B):
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.
Except for Initial packets and Stateless Resets, an endpoint only
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.