> On 2. Mar 2023, at 22:01, Vidhi Goel <[email protected]> > wrote: > > 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? ... and also FreeBSD.
Best regards Michael > > 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 > >
