On 17/12/20 01:08, Christian Huitema wrote:
[...]
Our document requires specifications to spell out the interoperability
requirements, because quite too often speficiations specify things
they need not.
For example, the QUIC spec specifies sequence numbers start at 0.
*That* is an over specification. Because sequence numbers need not
start at zero.
QUIC does not mandate that sequence numbers start at 0.
Section 5.1.1 of draft-ietf-quic-transport-29 says:
" The sequence number of the
initial connection ID is 0. If the preferred_address transport
parameter is sent, the sequence number of the supplied connection ID
is 1.
"
Later in the same section, it says:
" The sequence number on
each newly-issued connection ID MUST increase by 1. "
OTOH, with respect to connection I-Ds, Section 5.1.1 says:
"Each
endpoint selects connection IDs using an implementation-specific (and
perhaps deployment-specific) method which will allow packets with
that connection ID to be routed back to the endpoint and to be
identified by the endpoint upon receipt.
Connection IDs MUST NOT contain any information that can be used by
an external observer (that is, one that does not cooperate with the
issuer) to correlate them with other connection IDs for the same
connection. As a trivial example, this means the same connection ID
MUST NOT be issued more than once on the same connection."
But then, the next section ("5.1.1. Issuing Connection IDs") talks
about randomized connection IDs:
The connection
ID randomly selected by the client in the Initial packet and any
connection ID provided by a Retry packet are not assigned sequence
numbers unless a server opts to retain them as its initial connection
ID.
So yes: sequence numbers seem to be over-specified, and connection-ids
seem to be under-specified.
What am I missing?
Thanks,
--
Fernando Gont
SI6 Networks
e-mail: fgont@xxxxxxxxxxxxxxx
PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492
--
last-call mailing list
last-call@xxxxxxxx
https://www.ietf.org/mailman/listinfo/last-call
