Okej, let’s go for option 2. //Zahed
On 2023-03-06, 11:52, "QUIC" <[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]> Date: Monday, 6 March 2023 at 09:58 To: [email protected] <[email protected]> Cc: David Schinazi <[email protected]>, Vidhi Goel <[email protected]>, Martin Thomson <[email protected]>, Magnus Westerlund <[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/ <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 > > <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
smime.p7s
Description: S/MIME cryptographic signature
