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
