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
