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]> wrote:
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/)
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]> on behalf of
Martin Thomson <[email protected]>
> Date: Tuesday, 28 February 2023 at 01:23
> To: [email protected] <[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]>
> >
> > 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 Briscoehttp://bobbriscoe.net/
