Re: draft-misell-quic-bdp-token is asking for codepoints

[Christian Huitema <[e-mail]>]

On 1/21/2024 9:31 PM, Kazuho Oku wrote:
> 2024年1月22日(月) 7:59 Martin Thomson <[e-mail]>:
> 
>> 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