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. 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
