I haven't reviewed the draft in question here, but on the general IANA allocation question, we should absolutely be encouraging provisional registrations to avoid conflicts. That was one of the main motivations for the "varint ALL the things" effort back in the day. As long as the codepoints are using the 4 or 8-byte encoding and seem random enough, we should approve without question. Thanks to the authors for switching to a longer encoding in their -02, by the way. It makes sense to slightly defend the 2-byte encodings, and avoid 1-byte and 2-byte for drafts unless we have a good reason to need them.
David On Mon, Jan 22, 2024 at 9:09 AM Gorry Fairhurst <[email protected]> wrote: > On 22/01/2024 13:57, Lucas Pardue wrote: > > Hi folks, > > For the context of this email, I have no particular opinion about this > draft. Using a larger codepoint seems better for early stage work. > > Zooming out a bit: we've now gathered a bit of experience for people > trying to use QUIC codepoints. The guidance in RFC 9000 is correct and > IANA designated experts are applying it well. However, there's a bit of a > gap in explaining the sort of pattern of evolution Christian and Kazuho > describe. I have a task to try and document that better (on the quicwg.org > page for now) so that there's a bit more clarity and consistency. I'll send > a draft for review once I have something. > > Cheers > Lucas > > And from my side are planning an update for the BDP Frame draft, which > should be ready soon. We don't expect any early allocation at this time. > > Best wishes, > > Gorry > > > On Mon, Jan 22, 2024, at 12:09, Q Misell wrote: > > Hi all, > > This appears to have caused quite the controversy. > > > 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?" > > Indeed it does, I somehow managed to completely miss that. I shall update > to an 8-byte codepoint in this case. > > > Again, if the presumption here is that this is going to be deployed, > then a code point would help and a provisional registration would help with > collision avoidance. > > That is entirely the reason for my request. Given that there are plentiful > codepoints I though registration prudent to remove the possibility of a > clash. > > Thanks, > Q Misell > ------------------------------ > > Any statements contained in this email are personal to the author and are > not necessarily the statements of the company unless specifically stated. > AS207960 Cyfyngedig, having a registered office at 13 Pen-y-lan Terrace, > Caerdydd, Cymru, CF23 9EU, trading as Glauca Digital, is a company > registered in Wales under № 12417574 > <https://find-and-update.company-information.service.gov.uk/company/12417574>, > LEI 875500FXNCJPAPF3PD10. ICO register №: ZA782876 > <https://ico.org.uk/ESDWebPages/Entry/ZA782876>. UK VAT №: GB378323867. > EU VAT №: EU372013983. Turkish VAT №: 0861333524. South Korean VAT №: > 522-80-03080. AS207960 Ewrop OÜ, having a registered office at Lääne-Viru > maakond, Tapa vald, Porkuni küla, Lossi tn 1, 46001, trading as Glauca > Digital, is a company registered in Estonia under № 16755226. Estonian VAT > №: EE102625532. Glauca Digital and the Glauca logo are registered > trademarks in the UK, under № UK00003718474 and № UK00003718468, > respectively. > > > On Mon, 22 Jan 2024 at 07:55, Marten Seemann <[email protected]> > wrote: > > I agree with Kazuho and Christian. There were doubts raised on this list > regarding the proposed protocol mechanism, and I'm surprised to see a > request for a provisional registration at this point, and for an individual > draft. This only seems justified if there's intent for internet-scale > deployment by multiple QUIC stacks. If that's the case, I'd like to learn > more about it. > > In any case, allocating a (somewhat) scarce 2-byte code point before > adoption seems premature to me, especially since this draft will likely go > through a couple of revisions (and therefore code points). Using an 8 byte > code point, as Christian and Kazuho suggested, would be the strictly better > choice. > > On Mon, 22 Jan 2024 at 14:28, Christian Huitema <[email protected]> > wrote: > > > > On 1/21/2024 9:43 PM, Martin Thomson wrote: > > On Mon, Jan 22, 2024, at 16:31, Kazuho Oku wrote: > >> 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's encouragement that Q might take or not, but - as a designated > expert - I can't really say "no" on that basis. > > > >> 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. > > > > Again, if the presumption here is that this is going to be deployed, > then a code point would help and a provisional registration would help with > collision avoidance. This hasn't been discussed in this group, so the risk > of collision is perhaps higher. > > > > I haven't asked if the intent was to deploy this tweak, but we don't use > that as a condition of registration. > > > >>From my perspective, I would prefer if drafts that are seeking > deployment choose and register provisional code points. And that drafts > that are just ideas keep their code points set to 0xTBD. It's a tiny bit > of clerical work to support a deployment, but it means that we don't have > one rule for people who are discussing IETF drafts and one for everyone > else. > > > > The purpose of the BDP drafts is to manage paths with large bandwidth > delay products, and skip the O(log2(BDP/IW10)) RTT required for ramping > up the CWND to the desired value. There is really zero reason to > allocate sort code points for that. > > -- Christian Huitema > > > >
