Hi Zahed, We are unable to verify this erratum that the submitter marked as editorial, so we changed the Type 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/).
For discussion about this report, please see: https://mailarchive.ietf.org/arch/msg/quic/aL-OJjRgFTGG3ieNrl7q56xBKuk/ You may review the report at: https://www.rfc-editor.org/errata/eid8106 Information on how to verify errata reports can be found at: https://www.rfc-editor.org/how-to-verify/ Further information on errata can be found at: https://www.rfc-editor.org/errata.php Best regards, RFC Editor/rv > On Sep 17, 2024, at 12:00 AM, RFC Errata System <rfc-edi...@rfc-editor.org> > 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/eid8106 > > -------------------------------------- > Type: Editorial > Reported by: Lars Eggert <l...@eggert.org> > > Section: 13.2.1 > > Original Text > ------------- > Every packet SHOULD be acknowledged at least once, and ack-eliciting > packets MUST be acknowledged at least once within the maximum delay > an endpoint communicated using the max_ack_delay transport parameter; > > > Corrected Text > -------------- > Every packet SHOULD be acknowledged at least once, and ack-eliciting > packets MUST be acknowledged at least once. All acknowledgments MUST > occur within the maximum delay an endpoint communicated using the > max_ack_delay transport parameter; > > > Notes > ----- > The original text can be read as if it were OK to only ACK once within the > max_ack_delay, and not always. > > Instructions: > ------------- > This erratum is currently posted as "Reported". (If it is spam, it > will be removed shortly by the RFC Production Center.) Please > use "Reply All" to discuss whether it should be verified or > rejected. When a decision is reached, the verifying party > will 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 > Stream : IETF > Verifying Party : IESG >
