Hello Magnus,
AFAIK, linux, Windows, Mac - all support reading ECN bits on received packets. Could you let me know which OS doesn’t support this? Vidhi > On Feb 28, 2023, at 4:31 AM, Magnus Westerlund > <[email protected]> wrote: > > Hi, > > I support Martin’s proposed way forward with this errata. The reality here is > that we in no way could force ECN reporting due to the state of difficulties > to access the ECN bits on received packets on some OS, and from user space > QUIC implementations so that was never the intention. So I think this is only > an editorial issue of not appear conflicting in the text. > > Cheers > > Magnus > > From: QUIC <[email protected]> on behalf of Martin Thomson > <[email protected]> > Date: Tuesday, 28 February 2023 at 01:23 > To: [email protected] <[email protected]> > Subject: Re: [Technical Errata Reported] RFC9000 (7374) > > This change would not hurt if we were actively editing, but I don't think it > is necessary. Not implementing ECN is a great way to ensure that ECN > markings are unavailable to an endpoint. Bob is right that we create > confusion by making a distinction in one place and not the other, but it > doesn't really change the meaning. > > I suggest that we reassign this to Editorial and mark it Hold for Document > Update. > > On Tue, Feb 28, 2023, at 10:04, RFC Errata System 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/eid7374 > > > > -------------------------------------- > > Type: Technical > > Reported by: Bob Briscoe <[email protected]> > > > > Section: 13.4.1 > > > > Original Text > > ------------- > > If an > > endpoint does not implement ECN support or does not have access to > > received ECN fields, it does not report ECN counts for packets it > > receives. > > > > Even if an endpoint does not set an ECT field in packets it sends, > > the endpoint MUST provide feedback about ECN markings it receives, if > > these are accessible. > > > > Corrected Text > > -------------- > > If an > > endpoint does not have access to > > received ECN fields, it does not report ECN counts for packets it > > receives. > > > > Even if an endpoint does not set an ECT field in packets it sends, > > the endpoint MUST provide feedback about ECN markings it receives, if > > these are accessible. > > > > Notes > > ----- > > In the second sentence, the only allowed exception to "MUST provide > > feedback about received ECN markings" is inaccessibility. The first > > sentence contradicts this by allowing two exceptions: inaccessibility > > and just "not implementing ECN support". > > > > If "not implementing ECN support" was really intended to be an allowed > > exception, the capitalized "MUST" would have been pointless. > > > > Therefore it is proposed that the words "does not implement ECN support > > or " are deleted from the first paragraph. > > > > 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
