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