On 1/21/2024 9:31 PM, Kazuho Oku wrote:
2024年1月22日(月) 7:59 Martin Thomson <[email protected]>:
https://datatracker.ietf.org/doc/html/draft-misell-quic-bdp-token
IANA has received a formal request related to this draft. As far as I can
tell, this is a different spelling of draft-kuhn-quic-bdpframe-extension,
just with real code points specified. The value chosen takes two bytes to
encode, which is fine.
Regarding the code point, doesn't RFC 9000 section 22.1.2 state that 4-byte
or 8-byte code points should be used unless it is "especially sensitive to
having a longer encoding?" My feeling is that transport parameters and
error codes are not sensitive, as they are used only once per the lifetime
of a connection.
That said, I wonder if it is necessary to request a provisional
registration for every individual draft. My experience has been that drafts
submitted to the working group are discussed and revised. Then, as they
mature, code points are fixed and registered.
Generally speaking I think sending CC-related signals from the client is an
idea worth exploring. At the same time, I am concerned that the design in
the current form might have privacy concerns, as CC-related properties from
the servers will be sent in clear when the client attempts to resume. This
can become a vector for correlating connections, as in the past we have
discussed that it would make sense for servers to issue multiple tokens for
one connection (in which case those tokens are likely to contain the same
properties).
To paraphrase, my hope is that we will have something like this
standardized with changes, and the question is if there is a need for
provisional registration before doing that.
The draft is reasonably clear about how it operates. It differs from
draft-kuhn-quic-bdpframe-extension in that it uses NEW_TOKEN to
communicate. I don't see why implementations that operated this way
couldn't interoperate. That is, as far as interoperation is concretely
necessary in this case, which is to say "not really".
As an expert on the registry, I've been asked to review this
registration. The fact that I think this is a bad idea is not a sufficient
reason to reject the registration. So I plan to let IANA know to go ahead.
What Kazuho said. The multipath draft, for example, was rewritten to use
an 8 bytes transport parameter (62 bits, 52 random and 8 bits for the
draft version) and four bytes frame types (22 bits random as a prefix
and 8 bits for individual frame types). I would expect registrants to do
the same, especially for individual drafts. If I was in your shoes, I
would ask them to stick to these lengths and explain which random
generation process they used to produce the values.
-- Christian Huitema
