Hi Bob, On the first bullet I agree that you can’t make that determination. I don’t really think this aspect came up, as the focus was getting implementing ECN as simple as possible in those endpoints that are able without making the endpoints that don’t implement ECN bit reading being non-compliant. As discussed before, there are several barriers between someone wanting to implement an QUIC stack and supporting reading of the ECN bits, where choice of language is one, and its integration with the networking layer used.
So the editorial issue is that the text in inconsistent and not clear enough for you to not have these questions. Cheers Magnus From: QUIC <[email protected]> on behalf of Bob Briscoe <[email protected]> Date: Monday, 20 March 2023 at 13:38 To: Ian Swett <[email protected]>, Zaheduzzaman Sarker <[email protected]> Cc: Magnus Westerlund <[email protected]>, [email protected] <[email protected]>, David Schinazi <[email protected]>, Vidhi Goel <[email protected]>, Martin Thomson <[email protected]> Subject: Re: [Technical Errata Reported] RFC9000 (7374) As the original reporter of this erratum, I'm fine with Editorial/Hold for update. Nonetheless, I don't really see why an edit that disambiguates two conflicting technical requirements is "editorial", rather than "technical". I reported this, because: * It makes it hard to implement telemetry to find problems with ECN traversal over network paths, when some (non-compliant) remote peers show the same symptoms as a path problem. * I wondered whether these non-compliant peers had just misunderstood this ambiguity in the spec. Quoting from https://www.ietf.org/about/groups/iesg/statements/processing-errata-ietf-stream/ : Technical errata are expected to be things that would likely cause significant misunderstandings of the technical specification and might result in faulty implementations if they are not corrected. Editorial errata are, as the name implies, editorial - for example, typos, missing commas, etc. The only reason I'm fine with "Editorial" is that the technical/editorial classification only affects who the original erratum report is sent to. That's happened now. So I don't believe changing it to editorial now will affect how the erratum is understood or handled in future. Bob On 14/03/2023 00:56, Ian Swett wrote: I would also lean towards Martin's suggestion of editorial / hold for update. On Wed, Mar 8, 2023 at 10:44 AM Zaheduzzaman Sarker <[email protected]<mailto:[email protected]>> wrote: Okej, let’s go for option 2. //Zahed On 2023-03-06, 11:52, "QUIC" <[email protected]<mailto:[email protected]>> 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 <[email protected]<mailto:[email protected]>> Date: Monday, 6 March 2023 at 09:58 To: [email protected]<mailto:[email protected]> <[email protected]<mailto:[email protected]>> Cc: David Schinazi <[email protected]<mailto:[email protected]>>, Vidhi Goel <[email protected]<mailto:[email protected]>>, Martin Thomson <[email protected]<mailto:[email protected]>>, Magnus Westerlund <[email protected]<mailto:[email protected]>> 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 <[email protected]<mailto:[email protected]>> on behalf > of Martin Thomson <[email protected]<mailto:[email protected]>> > Date: Tuesday, 28 February 2023 at 01:23 > To: [email protected]<mailto:[email protected]> <[email protected]<mailto:[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]<mailto:[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 -- ________________________________________________________________ Bob Briscoe http://bobbriscoe.net/<https://protect2.fireeye.com/v1/url?k=31323334-501d5122-313273af-454445555731-b0108c2709550a3a&q=1&e=f0998499-08a7-441a-93fb-2a27b2b3095a&u=http%3A%2F%2Fbobbriscoe.net%2F>
