Subject: Re: [Editorial Errata Reported] RFC9000 (6811)

From: Chris Smiley <[email-masked]>
Date: Wed, 9 Feb 2022 14:38:48 -0800

Greetings,

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/eid6811

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 Jan 5, 2022, at 5:51 PM, RFC Errata System <[email-masked]> 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/eid6811
> 
> --------------------------------------
> Type: Editorial
> Reported by: Martin Thomson <[email-masked]>
> 
> Section: 5.1.1
> 
> Original Text
> -------------
>                                         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.  
> 
> Corrected Text
> --------------
>                                         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.  The sequence number for NEW_CONNECTION_ID frames starts at 2
>   when the preferred_address transport parameter is sent and 1
>   otherwise.
> 
>   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.
> 
> Notes
> -----
> It is not sufficiently clear that the (implied) sequence number for the preferred_address transport parameter is taken from the sequence only when the transport parameter is present.
> 
> The original text might be read to imply that the first NEW_CONNECTION_ID frame always starts with 2, though maybe only at a server.  The proposed addition is much more explicit.
> 
> 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
>