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". //Zahed > On 3 Mar 2023, at 21:17, Vidhi Goel <[email protected]> > wrote: > > The errata filed has nothing to do with forcing any implementation to > implement ECN. It is about the ambiguity between “an endpoint is allowed not > to implement ECN support unconditionally” vs “an endpoint in allowed not to > implement ECN ONLY when the fields are not accessible” > > And I am fine with reassigning it to Editorial & Hold. I just want to make > sure we are not misinterpreting the errata. Also, reg. the accessibility of > ECN bits, the current reality is that most OSes support it. > > Vidhi > >> On Mar 3, 2023, at 10:31 AM, David Schinazi <[email protected] >> <mailto:[email protected]>> wrote: >> >> As much as we all love ECN, implementation will not be willed into existence >> via some IETF MUSTs. Let's keep track of properties as they exist in >> reality, not as we would like them to exist. >> +1 to editorial / hold for update. >> >> David >> >> On Fri, Mar 3, 2023 at 5:42 AM Lucas Pardue <[email protected] >> <mailto:[email protected]>> wrote: >>> (wearing no hats) >>> >>> There seems to be a broad assumption here that QUIC is being conveyed over >>> UDP. Since RFC 9000 shipped, there's been activity in the MASQUE WG to >>> support UDP tunneling over HTTP, of which one manifestation is >>> QUIC-over-QUIC. While possible to add support for ECN as an extension to >>> this, it doesn't exist today. >>> >>> That's just one example. I find the current text (and the proposed text) >>> suitably generic enough to highlight the reality that, for the purposes of >>> QUIC, ECN cannot be fully depended on to be available. >>> >>> Editorial + hold for update sounds good to me. >>> >>> Cheers, >>> Lucas >>> >>> On Fri, Mar 3, 2023 at 1:02 PM Michael Tuexen >>> <[email protected] >>> <mailto:[email protected]>> wrote: >>>> > On 3. Mar 2023, at 11:37, Magnus Westerlund >>>> > <[email protected] >>>> > <mailto:[email protected]>> wrote: >>>> > >>>> > Hi Vidhi, >>>> > So on Windows 5 years ago was not that easy to do it bi-directionally. >>>> > I think reading was the hard part there, it was easy to set, but hard to >>>> > read on a per packet basis. Then there has been the question of what >>>> > rights you needed to have to access the bits, and finally there is even >>>> > an implementation language problem. For example I looked into Go a >>>> > couple of years ago which at that time had no support in its network >>>> > libraries to access the ECN bits. I know the situation has improved, but >>>> > that doesn’t change the previous >>>> When using the socket API, the way to handle the ECN bits is via CMSGs. So >>>> you can get/set this for each sent/received UDP packet. I don't think >>>> you need special privileges for that. >>>> Whether you have access to this functionality in libraries of specific >>>> programming languages is not tied to operating systems, but to these >>>> libraries. >>>> >>>> Best regards >>>> Michael >>>> > rough consensus. I would love to make it clear that reading ECN bit >>>> > really should be implemented. But an errata is not the tool to change >>>> > the existing consensus. Thus, I think the right way forward here is to >>>> > mark this editorial and hold for update. >>>> > I think the ECN part should be reviewed when we do a QUIC v1 bis, or >>>> > the next QUIC version. >>>> > Cheers >>>> > Magnus >>>> > From: QUIC <[email protected] <mailto:[email protected]>> on >>>> > behalf of Vidhi Goel <[email protected] >>>> > <mailto:[email protected]>> >>>> > Date: Thursday, 2 March 2023 at 22:01 >>>> > To: Magnus Westerlund <[email protected] >>>> > <mailto:[email protected]>> >>>> > Cc: Martin Thomson <[email protected] <mailto:[email protected]>>, >>>> > [email protected] <mailto:[email protected]> <[email protected] >>>> > <mailto:[email protected]>> >>>> > Subject: Re: [Technical Errata Reported] RFC9000 (7374) >>>> > Hello Magnus, >>>> > AFAIK, linux, Windows, Mac - all support reading ECN bits on received >>>> > packets. Could you let me know which OS doesn’t support this? >>>> > Vidhi >>>> > >>>> > >>>> > On Feb 28, 2023, at 4:31 AM, Magnus Westerlund >>>> > <[email protected] >>>> > <mailto:[email protected]>> wrote: >>>> > 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] <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 >>>> >>>> >
smime.p7s
Description: S/MIME cryptographic signature
