I agree with you Martin, the description seems OK and we just need to update the summery table. Hence I would treat this as and editorial.
//Zahed > On 28 Feb 2023, at 01:20, Martin Thomson <[email protected]> wrote: > > 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://protect2.fireeye.com/v1/url?k=31323334-501d5122-313273af-454445555731-c47e1ac6344bc121&q=1&e=5722dba9-080d-4ef1-bf26-6f58bcbe69ed&u=https%3A%2F%2Fquicwg.org%2Fbase-drafts%2Frfc9000.html%23section-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 >>>
smime.p7s
Description: S/MIME cryptographic signature
