Re: [Technical Errata Reported] RFC9000 (7578)

Zaheduzzaman Sarker <zahed.sarker.ietf@gmail.com> Fri, 22 September 2023 14:25 UTC

MIME-Version: 1.0
References: <20230730183455.3C3F3CD7D1@rfcpa.amsl.com>
In-Reply-To: <20230730183455.3C3F3CD7D1@rfcpa.amsl.com>
From: Zaheduzzaman Sarker <zahed.sarker.ietf@gmail.com>
Date: Fri, 22 Sep 2023 16:25:25 +0200
Message-ID: <CAEh=tcd73A=rkO7ij=mDM+_+FtQGsaqzGJ_UJpL+nVUx=du3=w@mail.gmail.com>
Subject: Re: [Technical Errata Reported] RFC9000 (7578)
To: quic@ietf.org
Cc: jri.ietf@gmail.com, mt@lowentropy.net, Martin Duke <martin.h.duke@gmail.com>, Matt Joras <matt.joras@gmail.com>, Lucas Pardue <lucaspardue.24.7@gmail.com>, Marten Seemann <martenseemann@gmail.com>, RFC Errata System <rfc-editor@rfc-editor.org>
Content-Type: multipart/alternative; boundary="000000000000bbf8fc0605f36135"
Archived-At: <https://mailarchive.ietf.org/arch/msg/quic/LKUi4IgK6umN9v5mHCPjzeDp4DY>
Precedence: list

Hi all,

Observing the email thread discussions  (
https://mailarchive.ietf.org/arch/msg/quic/oR4kxGKY6mjtPC1CZegY1ED4beg/), I
see we are agreeing with the issues, however, we couldn't reached to any
resolution. It also appears that with QUIC version 1, things are not
completely broken.

With this, my recommendation is that we change the errata state to "Hold
for Document Update". Please let me know if you think otherwise. In that
case, please share your view points and lead the discussions to find a
resolution.

//Zahed

On Sun, Jul 30, 2023 at 8:35 PM RFC Errata System <rfc-editor@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/eid7578
>
> --------------------------------------
> Type: Technical
> Reported by: Marten Seemann <martenseemann@gmail.com>
>
> Section: 17.2.1
>
> Original Text
> -------------
>                                                        Where QUIC
>    might be multiplexed with other protocols (see [RFC7983]), servers
>    SHOULD set the most significant bit of this field (0x40) to 1 so that
>    Version Negotiation packets appear to have the Fixed Bit field.
>
> Corrected Text
> --------------
>                                                        Unless the
>    server has out-of-band knowledge that clients are not
>    demultiplexing QUIC with other protocols (see [RFC7983]), it
>    SHOULD set the most significant bit of this field (0x40) to 1 so that
>    Version Negotiation packets appear to have the Fixed Bit field.
>
> Notes
> -----
> Unless operating in a tightly controlled environment, the server has no
> way of knowing what other protocols the client might be demultiplexing on
> the same UDP socket. According to the demultiplexing logic defined in RFC
> 9443, Version Negotiation packets with 0x40 set to 0 would be misclassified
> as RTP/RTCP.
>
> 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
>
>

[Technical Errata Reported] RFC9000 (7578) RFC Errata System
Re: [Technical Errata Reported] RFC9000 (7578) Zaheduzzaman Sarker