I agree that a short clarification would be helpful. I did not implement this, but I would have used logic that resulted in a situation similar to Martin's, as it is non-intuitive to me that a connection ID of "1" has a special meaning in an initial connection and a different one if sent in a NEW_CONNECTION_ID. Kazuho's text makes clear why my intuition is wrong, but it is pretty subtle to expect an implementer to catch.
regards, Ted Hardie On Wed, Jan 5, 2022 at 2:22 PM Ian Swett <ianswett= [email protected]> wrote: > 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 >> >
