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= [email protected]> 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 <[email protected]> on behalf of Kazuho Oku < > [email protected]> > *Date: *Wednesday, 5. January 2022 at 07:21 > *To: *Martin Thomson <[email protected]> > *Cc: *IETF QUIC WG <[email protected]> > *Subject: *Re: NEW_CONNECTION_ID sequence numbers > > > > Martin, thank you for bringing the issue to the list. > > > > 2022年1月5日(水) 14:57 Martin Thomson <[email protected]>: > > 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 >
