Re: NEW_CONNECTION_ID sequence numbers

[Ian Swett <[e-mail]>]

I think a short clarification would be helpful, since I can see this being
misread by others, but I have no opinion of whether it's an errata or not.

On Wed, Jan 5, 2022 at 8:37 AM Mirja Kuehlewind <mirja.kuehlewind=
[e-mail]> wrote:

> If we want to keep a record we could also create an errata and ask the AD
> to set it into “held for document update” state…
>
>
>
>
>
> *From: *QUIC <[e-mail]> on behalf of Kazuho Oku <
> [e-mail]>
> *Date: *Wednesday, 5. January 2022 at 07:21
> *To: *Martin Thomson <[e-mail]>
> *Cc: *IETF QUIC WG <[e-mail]>
> *Subject: *Re: NEW_CONNECTION_ID sequence numbers
>
>
>
> Martin, thank you for bringing the issue to the list.
>
>
>
> 2022年1月5日(水) 14:57 Martin Thomson <[e-mail]>:
>
> Hey,
>
> I discovered a problem in my implementation of NEW_CONNECTION_ID that
> quicly didn't like.  I was always skipping sequence number 1, even when
> there was no preferred address, which caused quicly to think that I was
> exceeding the limits it set.
>
> Kazuho, Jana, and I all agree that my code was wrong, but I found it
> pretty hard to clearly identify how this was specified in the spec.  Here's
> what it says:
>
> >  The sequence number of the initial connection ID is 0. If the
> preferred_address transport parameter is sent, the sequence number of the
> supplied connection ID is 1.
> >
> > Additional connection IDs are communicated to the peer using
> NEW_CONNECTION_ID frames (Section 19.15). The sequence number on each newly
> issued connection ID MUST increase by 1.
>
> -- https://quicwg.org/base-drafts/rfc9000.html#name-issuing-connection-ids
> <https://protect2.fireeye.com/v1/url?k=31323334-501d5122-313273af-454445555731-2a7ac3727495dfff&q=1&e=2924cc42-2683-482a-9fc8-11e09e03a8df&u=https%3A%2F%2Fquicwg.org%2Fbase-drafts%2Frfc9000.html%23name-issuing-connection-ids>
>
> Is it abundantly clear that I'm wrong based on this?  Did I miss a clearer
> piece of text elsewhere?  Or, should we be looking to open an erratum?
>
>
>
> I think that the cited text is the only place that discusses this, and
> regarding the text we have now, it seems to me that it clearly *implies*
> that if preferred_address TP is omitted, then the CID(seqnum=1) should be
> carried by a NEW_CONNECTION_ID frame.
>
>
>
> If we were to skip CID(seqnum=1) when preferred_address TP is omitted,
> then we would have not used a clause like "if the preferred_address
> transport parameter is sent." Instead, we would have omitted the if clause
> or said like "regardless of preferred_address transport parameter being
> sent."
>
>
>
> Therefore, my personal view is that an erratum is *not* required. However,
> I agree generally that implications are a source of confusion. If we are to
> revise the spec, this is one place that we can do better.
>
>
>
> Anyways. Even if we are to conclude that an erratum is unnecessary, it is
> always good to keep a record of how potentially confusing text should be
> read (or be improved in the next revision). To that respect, I appreciate
> your bringing this issue to the list regardless of how we would conclude.
>
>
>
>
> Cheers,
> Martin
>
>
>
> --
>
> Kazuho Oku
>