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
