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 <[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/eid7578 > > -------------------------------------- > Type: Technical > Reported by: Marten Seemann <[email protected]> > > 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 > >
