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

[Kazuho Oku <[e-mail]>]

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.
>
> Before I do, I'm inviting Q and the working group to discuss this idea.
>
> Cheers,
> Martin
>
>

-- 
Kazuho Oku