I would also lean towards Martin's suggestion of editorial / hold for update.
On Wed, Mar 8, 2023 at 10:44 AM Zaheduzzaman Sarker <zaheduzzaman.sarker= 40ericsson....@dmarc.ietf.org> wrote: > Okej, let’s go for option 2. > > > > //Zahed > > > > > > On 2023-03-06, 11:52, "QUIC" <quic-boun...@ietf.org> wrote: > > > > Hi Zahed, > > > > To my understanding it was deliberately written to not ECN support > especially on the sending side, but also as Martin Thomson pointed out it > was always possible to claim that you are not reading it. I would note that > there are some interesting quirks to this, in that even if you don’t > support ECN you might receive an ACK with ECN reporting in, if there been > some erroneous remarking happening on the path. > > > > I do however still think there is an editorial level conflict in the text, > so that option 2) is what should be applied here rather than 1). > > > > Cheers > > > > Magnus > > > > *From: *Zaheduzzaman Sarker <zaheduzzaman.sar...@ericsson.com> > *Date: *Monday, 6 March 2023 at 09:58 > *To: *quic@ietf.org <quic@ietf.org> > *Cc: *David Schinazi <dschinazi.i...@gmail.com>, Vidhi Goel <vidhi_goel= > 40apple....@dmarc.ietf.org>, Martin Thomson <m...@lowentropy.net>, Magnus > Westerlund <magnus.westerl...@ericsson.com> > *Subject: *Re: [Technical Errata Reported] RFC9000 (7374) > > Hi all, > > > > Thanks for the discussions on this errata. This was useful. > > > > So to be there are two things here - > > > > 1. was there any deliberate decision on the original text based on the > facts at the time of publication? if yes, then we can “reject" the errata > as this implementation information is new in a sense that it happened after > the publication and was not available for consideration during the time of > publication. (see the first bullet > https://www.ietf.org/about/groups/iesg/statements/processing-errata-ietf-stream/ > ) > > > > 2. If this was simple an oversight at the time of publication then I would > say that we go for "hold for document update". > > > > > > From: QUIC <quic-boun...@ietf.org> on behalf of Martin Thomson < > m...@lowentropy.net> > > Date: Tuesday, 28 February 2023 at 01:23 > > To: quic@ietf.org <quic@ietf.org> > > 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 <i...@bobbriscoe.net> > > > > > > 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 > > > > >
