FWIW, I think that this is correct, but I consider it only editorial. The table only exists to summarize information presented in prose.
A client cannot retire connection IDs unless it has received some. The connection ID it gets from the server during the handshake doesn't count, it needs a NEW_CONNECTION_ID frame. > A client MUST NOT send 0-RTT packets once it starts processing 1-RTT packets > from the server. This means that 0-RTT packets cannot contain any response to > frames from 1-RTT packets. -- https://quicwg.org/base-drafts/rfc9000.html#section-17.2.3-7 That is, NEW_CONNECTION_ID can only be sent in 1-RTT packets by a server (a server cannot send 0-RTT) and a client is forbidden from sending 0-RTT after processing 1-RTT, so there is no valid way for a client to send RETIRE_CONNECTION_ID in 0-RTT. That is, the prose is correct, but the table is not. On Tue, Feb 28, 2023, at 09:27, Chris Smiley wrote: > Greetings Zaheduzzaman, > > We are unable to verify this erratum that the submitter marked as editorial. > Please note that we have changed the “Type” of the following errata > report to “Technical”. As Stream Approver, please review and set the > Status and Type accordingly (see the definitions at > https://www.rfc-editor.org/errata-definitions/). > > You may review the report at: > https://www.rfc-editor.org/errata/eid7365 > > Please see https://www.rfc-editor.org/how-to-verify/ for further > information on how to verify errata reports. > > Further information on errata can be found at: > https://www.rfc-editor.org/errata.php. > > Thank you. > > RFC Editor/cs > > >> On Feb 22, 2023, at 10:52 PM, RFC Errata System <[email protected]> >> wrote: >> >> The following errata report has been submitted for RFC9000, >> "QUIC: A UDP-Based Multiplexed and Secure Transport". >> >> -------------------------------------- >> You may review the report below and at: >> https://www.rfc-editor.org/errata/eid7365 >> >> -------------------------------------- >> Type: Editorial >> Reported by: yongboy <[email protected]> >> >> Section: 12.4. >> >> Original Text >> ------------- >> | 0x19 | RETIRE_CONNECTION_ID | Section 19.16 | __01 | | >> >> Corrected Text >> -------------- >> | 0x19 | RETIRE_CONNECTION_ID | Section 19.16 | ___1 | | >> >> Notes >> ----- >> Based on the context and section 12.5 ending says: >> >> Note that it is not possible to send the following frames in 0-RTT >> packets for various reasons: ACK, CRYPTO, HANDSHAKE_DONE, NEW_TOKEN, >> PATH_RESPONSE, and RETIRE_CONNECTION_ID. A server MAY treat receipt >> of these frames in 0-RTT packets as a connection error of type >> PROTOCOL_VIOLATION. >> >> So, I think the RETIRE_CONNECTION_ID frame should not appear in the 0-RTT >> packet, only contained in the 1-RTT package. >> >> Instructions: >> ------------- >> This erratum is currently posted as "Reported". If necessary, please >> use "Reply All" to discuss whether it should be verified or >> rejected. When a decision is reached, the verifying party >> can log in to change the status and edit the report, if necessary. >> >> -------------------------------------- >> RFC9000 (draft-ietf-quic-transport-34) >> -------------------------------------- >> Title : QUIC: A UDP-Based Multiplexed and Secure Transport >> Publication Date : May 2021 >> Author(s) : J. Iyengar, Ed., M. Thomson, Ed. >> Category : PROPOSED STANDARD >> Source : QUIC >> Area : Transport >> Stream : IETF >> Verifying Party : IESG >>
