Re: [auth48] [AD] Re: [C350] AUTH48: RFC-to-be 9331 <draft-ietf-tsvwg-ecn-l4s-id-29> for your review

[Bob Briscoe <[e-mail]>]

RFC Editor/kc/ar,

Thank you for all your edits, finding my inconsistencies and errors.

Before getting to the nitty-gritty, a question...

Q1) Surely it's questionable to place <bcp14> around quoted normative 
keywords, because quotes negate the 'normativeness' (normativity?) of 
these keywords. I'm thinking particularly of sentences quoted from other 
RFCs that are normative in that RFC, but not in this one.
    For instance, if someone were to write automated compliance checking 
software, they would not expect to have to comply with keywords in quotes.
    If you agree, there are more than a dozen occurrences in quotes that 
will need reverting.

I have attached new XML:
* with updates where I felt sure (including a justifying comment),
* and comments asking you to update if appropriate, where I didn't feel 
confident enough to override your edits (or where there were bulk edits 
to make, which were best left to you).

I did the edits in two stages:
* a->b taking your 32 points in your XML (a) and responding within the 
XML (b)
* b->c checking through the diff and reacting where I disagreed (72 
cases, including 6 where I noticed improvements should be made to our 
original text).
I have attached diff a->c as well as a->b & b->c.
For the lists, I've also attached a diff between our -29 submission as 
approved by the IESG and my latest ('c').

I have been as liberal as possible. I only intervened where I felt the 
meaning had been incorrectly changed or clarity reduced.

You do not need to read this email any further, because the following 
only summarizes everything I have written into the attached XML.
But the summaries below might help you plan how to process the XML faster.

I've answered all 32 points that you had tagged [rfced] within the XML. 
The listing below is the first line of each point (as a rough exec 
summary) followed by my 1-line STATUS categorization of each.
These are NOT the full explanations, which are within the XML, tagged 
[BB]. This is just designed so you can see there are only two STATUSes:
13 "OK"                                                  = I've accepted 
what you've done.
19 "if agreeable to editor, no further action required." = Please check 
my attempt to do as asked.
________
32 Total

Following those 32 cases are a further 71 cases where I felt the new 
text needed reverting or rephrasing (including 6 cases where I noticed a 
problem with our original text).
Again I've only given:
* the first line (NOT the whole explanation, which is in the XML)
* and a corresponding STATUS line, summarized here:
53 include "no further action required" in some form.
    But pls check the new text, esp. those tagged "if agreeable".
18 ask you for further edits.
    These can be found quickly by searching for the word "please".
________
71 Total

Summary listings follow:


    32 RFC-Editor points (responses commented fully within the XML)

1:<!--[rfced] FYI, we have updated this document with the changes shown
2:<!--[rfced] FYI, the title has been updated as follows as
3:<!--[rfced] Please insert any keywords (beyond those that appear in the
4:<!--[rfced] Is the intention to include both "many" and "(most?)" in
5:<!--[rfced] We note the use of <tt> and <em> within this document.
6:<!--[rfced] RFC 2309 has been obsoleted by RFC 7567. May we add a note
7:<!--[rfced] Would it be correct to move the RFC 3649 citation after
8:<!--[rfced] Terminology section:
9:<!--[rfced] "Experimental" (capitalized) can be used to refer to the
10:<!--[rfced] RFC 4960 has been obsoleted by RFC 9260. May we add a note
11:<!--[rfced] Please review whether any of the notes in this document 
should be
12:<!--[rfced] For clarity, should RFC 3168 be added as a reference here?
13:<!--[rfced] Per RFC 5865, should "Voice-Admit" be "VOICE-ADMIT" (1 
instance)?
14:<!--[rfced] FYI, we changed "to an L4S identifier" to "of an L4S 
identifier"
15:<!--[rfced] Does "not necessarily completely regularly" mean "not
16:<!--[rfced] Please clarify what "that" refers to in the following:
17:<!--[rfced] RFC 3168 only mentions "ECT(0)" and "ECT(1)",
18:<!--[rfced] The following quote is not a direct quote from RFC 8257.
19:<!--[rfced] A "third approach" is mentioned here. Will it be clear to
20:<!--[rfced] Since there are multiple expansions for "CDN",
21:<!--[rfced] We added "its" for clarity and rephrased "ex-ToS byte" to
22:<!--[rfced] Since there is typically a space between the digit and 
unit of
23:<!--[rfced] Would you like to add "in item 4 of Section 4.3"
24:<!--[rfced] FYI: We removed "for RDMA" from this sentence since
25:<!--[rfced] May the following sentence be rephrased for clarity
26:<!--[rfced] Is the spacing intentional for "150,151,152" or should
27:<!--[rfced] Is "to cater for" accurate wording here, or would
28:<!--[rfced] Usage of 'round' in 'work-rounds', 'safe way round', and
29:<!--[rfced] FYI, as per the mail from Bob Briscoe on 2022-09-12, 
British English
30:<!--[rfced] Throughout the text, the following terminology appears to 
be used
31:<!--[rfced] Please review the "Inclusive Language" portion of the online
32:<!--[rfced] We see a number of author-inserted comments in the XML 
file of

1:   STATUS: OK.
2:   STATUS: OK.
3:   STATUS: If agreeable to editor, no further action required.
4:   STATUS: If agreeable to editor, no further action required.
5:   STATUS: If agreeable to editor, no further action required.
6:   STATUS: OK.
7:   STATUS: If agreeable to editor, no further action required.
8:   STATUS: OK (assuming nothing has been changed here yet, which I 
believe to be so).
9:   STATUS: If agreeable to editor, no further action required.
10:   STATUS: If agreeable to editor, no further action required.
11:   STATUS: If agreeable to editor, no further action required.
12:   STATUS: OK
13:   STATUS: If agreeable to editor, no further action required.
14:   STATUS: If agreeable to editor, no further action required.
15:   STATUS: If agreeable to editor, no further action required.
16:   STATUS: If agreeable to editor, no further action required.
17:   STATUS: Done.
18:   STATUS: If agreeable to editor, no further action required. This 
changes commentary on normative text (tho' not the normative text 
itself), so you might want to ask for AD approval.
19:   STATUS: If agreeable to editor, no further action required.
20:   STATUS: OK.
21:   STATUS: OK.
22:   STATUS: OK.
23:   STATUS: If agreeable to editor, no further action required. But 
please closely check all my new xref's.
24:   STATUS: OK.
25:   STATUS: Reverted. If agreeable to editor, no further action required.
26:   STATUS: OK.
27:   STATUS: If agreeable to editor, no further action required.
28:   STATUS: If agreeable to editor, no further action required. But 
open to further discussion.
29:   STATUS: OK.
30:   STATUS: If agreeable to editor, no further action required.
31:   STATUS: OK.
32:   STATUS: OK.


    My 71 disagreements warranting a mention (commented fully within the
    XML)

1:<!--[BB] Reverted to 'delay under load',which was intended, 'cos it 
has a different meaning to 'delay under a load'
2:<!--[BB] Reverted to 'delay ... is sub-millisecond on average', 'cos 
'delay ... is a sub-millisecond' doesn't make sense.
3:<!--[BB] I haven't reverted DCTCP / DualQ to their abbreviated forms, 
with their expansions
4:<!--[BB] I've reverted to 'Data Center TCP' without a hyphen and 
spelled the US way,
5:<!--[BB] I've removed the commas around 'while waiting...' because the 
the intended meaning was
6:<!--[BB] I've reverted to 'a different issue that needs to be 
addressed, but separately...'
7:<!--[BB] Given AQM has been expanded here, I've removed the initial 
'The', because 'Management'
8:<!--[BB] It seems like all the experience from having just edited the 
previous draft in this
9:<!--[BB] SCReAM citations:
10:<!--[BB] The addition of 'or' would have been more appropriate than 
'and'.
11:<!--[BB] I think 'an increasing level..., the longer...' is hard to 
read without the comma.
12:<!--[BB] aka -> a.k.a. 
https://www.chicagomanualofstyle.org/qanda/data/faq/topics/Abbreviations/faq0099.html
13:<!--[BB] Pls revert expansions, consistent with RFC-to-be 9330.
14:<!--[BB] I believe I'm right in saying that FQ is used for per-flow 
queuing but not
15:<!--[BB] Removal of 'etc.' was because three examples other than 
Prague were listed above.
16:<!--[BB] The addition of 'uses the ECN field as an identifier' is not 
relevant here,
17:<!--[BB] This meant that Classic ECN as a whole is applicable to v4 & v6.
18:<!--[BB] 'this' meant the relaxation, not the ABE spec.
19:<!--[BB] Accurate is not capitalized (2 occurrences), because it 
refers to the requirements for accurate ECN feedback,
20:<!--[BB] Removal of 'with' from 'all other factors being equal': pls 
see discussion in RFC-to-be 9330 XML.
21:<!--[BB] Addition of 'further' reverted from 'further rationale' (5 
occurrences), because there is no other rationale in each of these items.
22:<!--[BB] Citation of Reno [RFC5681] reverted to its original position 
after 'standard Reno',
23:<!--[BB] Given this is a deeply controversial subject, I'm slightly 
concerned that selecting only one of the three quotations for a
24:<!--[BB] ID expanded on first use of 'flow identifier' (as was 
suggested for RFC 9330).
25:<!--[BB] I don't see why one of the commas that bracketed off 'in the 
Classic approach' has been removed;
26:<!--[BB] Addition of 'further' reverted from 'further rationale', 
because there is only assertion, not rationale, here.
27:<!--[BB] Removing the second hyphen in 'separate queues 
per-application flow' has changed the meaning
28:<!--[BB] I've removed the added 'if it' from:
29:<!--[BB] I noticed our 'for example' in parentheses followed an e.g. 
for unexpected combinations,
30:<!--[BB] Removed the added 'the' from 'and [the] CE indicates' 'cos 
it no longer makes sense,
31:<!--[BB] Surely adding 'on' slightly obstructs the reader's flow for 
no benefit.
32:<!--[BB] The second 'them' is good, but surely adding the opening 
subclause ('for such packets') slightly
33:<!--[BB] I noticed that our own text was ambiguous; 'The two can be 
combined...'
34:<!--[BB] The edit to 'Layer 4' made me notice 'transport-layer' would 
be more consistent with the rest of the document.
35:<!--[BB] Rather than changing 'other incoming interface(s)' to 
'another incoming interface(s)',
36:<!--[BB] The demotion of ';' to ',' made me think it would be more 
readable to enumerate
37:<!--[BB] Originally, this said:
38:<!--[BB] It isn't worth saying EWMA specifically if it has to be 
expanded. So I've
39:<!--[BB] The addition of 'and' could imply that both can be used 
together (which is impossible).
40:<!--[BB] I noticed that we had said 'The 01 codepoint is 
specified...', when we meant
41:<!--[BB] I noticed that the registry URL was 
https://www.iana.org/assignments/dscp-registry/
42:<!--[BB] Suggested briefer tags for AccECN, ECN++ and QPROT to mirror 
the common names used for each.
43:<!--[BB] Please revert RFC 9330 and RFC 9332 to informative 
references. The WG discussed
44:<!--[BB] I notice that the URLs of some I-Ds in the txt output are to 
specific versions
45:<!--[BB] The added commit ID was far behind (Jun'22). Updated commit 
ID and date to latest (20-Nov-22).
46:<!--[BB] Reverted addition of 'see', because the parenthesis wasn't 
intended to refer
47:<!--[BB] As earlier, reverted to keep the distinction between 
accurate ECN feedback and the specific AccECN scheme.
48:<!--[BB] 'shared' had been altered to 'share'. 'shared' was intended 
as the subjunctive mood,
49:<!--[BB] The addition of 'the' to 'CE marking' has been reverted, 
because the outcome is
50:<!--[BB] I noticed 'presuming the AQM behaviours known at the time of 
writing' could be
51:<!--[BB] I've temporarily commented out this construction, and 
replaced it with a <tfoot>,
52:<!--[BB] I've reverted 'was' back to 'were', because our real problem 
here was 'will'
53:<!--[BB] 'The speed-of-loss recovery' was not what was intended. 
Readers would probably
54:<!--[BB] I think one can say 'a factor of x longer' (the original) or 
'x times longer',
55:<!--[BB] 'Slow start' is the well-known name of a phase of the TCP 
algorithm.
56:<!--[BB] The change to 'might be arriving' is definitely not what was 
intended,
57:<!--[BB] The change from 'supported' to 'supports' doesn't fit with 
the earlier 'would support'.
58:<!--[BB] The later change from comma to semicolon made me realize 
there could just be a sentence split here.
59:<!--[BB] Changing 'there will be no problem' to 'it will not be a 
problem' weakens
60:<!--[BB] Although 'reduce the congestion window' would be correct, it 
makes the reader
61:<!--[BB] The addition of 'a' is technically correct before 'flow(s)', 
but it makes the
62:<!--[BB] There has already been discussion of 'in [the] future' on 
the list. To cut to the chase,
63:<!--[BB] The addition of a hyphen in 'low-link capacities' has 
changed the meaning to 'the capacities of low links'!
64:<!--[BB] The addition of quotes round 'Not-ECT' is inconsistent with 
every other occurrence of
65:<!--[BB] Given this discussion includes TCP, I've disambiguated to 
IP-ECN field, because there are ECN flags in the TCP header.
66:<!--[BB] The change from the subjunctive 'once use ... had' (for an 
unlikely eventuality) to 'once use ... have been'
67:<!--[BB] I think one can say 'the following categories' (the 
original) or 'the categories described below',
68:<!--[BB] Upper-cased 'Paragraph' for consistency with automated xref 
rendering.
69:<!--[BB] See earlier re. accurate ECN feedback, vs. AccECN feedback.
70:<!--[BB] The added hyphen in 'Less-severe congestion' looks 
incorrect, and CMS agrees.
71:<!--[BB] 'I noticed I had written 'also' incorrectly in 'Bob Briscoe 
was [also] partly funded'.

1:STATUS: Reverted. If agreeable to editor, no further action required.
2:STATUS: Reverted. If agreeable to editor, no further action required.
3:STATUS: Please revert.
4:STATUS: Reverted. If agreeable to editor, no further action required.
5:STATUS: Reverted. If agreeable to editor, no further action required.
6:STATUS: Reverted. If agreeable to editor, no further action required.
7:STATUS: If agreeable to editor, no further action required.
8:STATUS: Please revert the expansions, and add citations instead where 
necessary.
9:STATUS: Please revert all the SCReAM edits, if agreeable to the editor.
10:STATUS: Rephrased. If agreeable to editor, no further action required.
11:STATUS: Please explain the need to remove the comma, or otherwise revert.
12:STATUS: If agreeable to editor, no further action required.
13:STATUS: Please revert expansions.
14:STATUS: Reverted. If agreeable to editor, no further action required.
15:STATUS: Reverted to 'etc.' Please also revert in RFC-to-be 9330.
16:STATUS: Reverted. If agreeable to editor, no further action required. 
Please also mirror in RFC-to-be 9330.
17:STATUS: Rephrased. If agreeable to editor, no further action required.
18:STATUS: Rephrased. If agreeable to editor, no further action required.
19:STATUS: Reverted. No further action required.
20:STATUS: Reverted. No further action required.
21:STATUS: Reverted. If agreeable to editor, no further action required.
22:STATUS: Reverted. If agreeable to editor, no further action required.
23:STATUS: Please review whether all 3 quotes can be treated the same, 
either blockquoting all or none.
24:STATUS: If agreeable to editor, no further action required.
25:STATUS: Please explain the need to remove the comma, or otherwise revert.
26:STATUS: Reverted. If agreeable to editor, no further action required.
27:STATUS: Please explain the need for removal of the hyphen, or 
otherwise revert.
28:STATUS: Reverted. If agreeable to editor, no further action required. 
Otherwise, we're open to better suggestions (for 2 occurrences of the 
same phrasing).
29:STATUS: Rephrased. If agreeable to editor, no further action required.
30:STATUS: Reverted. If agreeable to editor, no further action required.
31:STATUS: Reverted. Please explain the need to add 'on' and revert back 
if appropriate.
32:STATUS: Reverted the addition of the subclause. Please explain the 
need to add this subclause and revert back if appropriate.
33:STATUS: If agreeable to editor, no further action required.
34:STATUS: If agreeable to editor, no further action required.
35:STATUS: Rephrased. If agreeable to editor, no further action required.
36:STATUS: Rephrased. If agreeable to editor, no further action required.
37:STATUS: Rephrased. If agreeable to editor, no further action required.
38:STATUS: Rephrased. If agreeable to editor, no further action required.
39:STATUS: Rephrased. If agreeable to editor, no further action required.
40:STATUS: Rephrased. If agreeable to editor, no further action required.
41:STATUS: Made registry URL more specific. If agreeable to editor, no 
further action required.
42:STATUS: Suggested change to citation tags. If agreeable to editor, no 
further action required.
43:STATUS: Please revert, or justify this non-editorial change.
44:STATUS: Editor might wish to investigate the cause of this inconsistency.
45:STATUS: Updated reference. If agreeable to editor, no further action 
required.
46:STATUS: Reverted. If agreeable to editor, no further action required.
47:STATUS: Reverted. If agreeable to editor, no further action required.
48:STATUS: Rephrased. If agreeable to editor, no further action required.
49:STATUS: Reverted. If agreeable to editor, no further action required.
50:STATUS: Rephrased. If agreeable to editor, no further action required.
51:STATUS: This form can be deleted if alternative is agreeable to the 
editor.
52:STATUS: Reverted and rephrased. If agreeable to editor, no further 
action required.
53:STATUS: Rephrased. No further action required.
54:STATUS: Rephrased. If agreeable to editor, no further action required.
55:STATUS: Reverted 'slow and start'. If agreeable to editor, no further 
action required.
56:STATUS: Reverted. Please explain why the original wasn't acceptable, 
so we can work out an alternative if necessary.
57:STATUS: Rephrased. If agreeable to editor, no further action required.
58:STATUS: Split sentence into two. If agreeable to editor, no further 
action required.
59:STATUS: Reverted. Please explain the need for the change and revert 
back if appropriate.
60:STATUS: Reverted. No further action required.
61:STATUS: Rephrased. If agreeable to editor, no further action required.
62:STATUS: Reverted (2 occurrences). If agreeable to editor, no further 
action required.
63:STATUS: Reverted. No further action required.
64:STATUS: Reverted. Please explain the need for the change and revert 
back if appropriate.
65:STATUS: Disambiguated ECN to IP-ECN throughout. No further action 
required.
66:STATUS: Rephrased. If agreeable to editor, no further action required.
67:STATUS: Rephrased. If agreeable to editor, no further action required.
68:STATUS: Upper-cased 'Paragraph'. If agreeable to editor, no further 
action required.
69:STATUS: Reverted. No further action required.
70:STATUS: Reverted. If agreeable to editor, no further action required.
71:STATUS: No further action required.

Regards


Bob

On 18/11/2022 22:57, [e-mail] wrote:
> Authors, AD*,
>
> *Martin, please see #1.
>
> While reviewing this document during AUTH48, please resolve (as necessary) the
> following questions, which are also in the XML file.
>
> 1) <!--[rfced] FYI, we have updated this document with the changes shown
> in the -30 file sent by the authors. The diff from the approved I-D
> is here:
> https://www.rfc-editor.org/authors/draft-ietf-tsvwg-ecn-l4s-id-29-30-rfcdiff.html
>
> *[AD] Martin, Please review and let us know if you approve the change
> in Appendix C.1 (the paragraph starts with "At the time of writing").
> -->
>
>
> 2) <!--[rfced] FYI, the title has been updated as follows as
> requested in Bob's mail 2022-11-03 regarding RFC-to-be 9330.
> The short title has been updated as well. Please review and
> let us know if you would like any further changes.
>
> Title
> Original:
>     Explicit Congestion Notification (ECN) Protocol for
>     Very Low Queuing Delay (L4S)
>
> Current:
>     The Explicit Congestion Notification (ECN) Protocol for
>     Low Latency, Low Loss, and Scalable Throughput (L4S)
>
>
> Short Title (appears in the running header of the PDF)
> Original:
>     L4S ECN Protocol for V Low Queuing Delay
>
> Current:
>     ECN Protocol for L4S
> -->
>
>
> 3) <!-- [rfced] Please insert any keywords (beyond those that appear in the
> title) for use onhttps://www.rfc-editor.org/search. -->
>
>
> 4) <!--[rfced] Is the intention to include both "many" and "(most?)" in
> the following, or should one be deleted?
> Or, rephrase as "many (perhaps most) Internet applications"
>
> Original:
>     Latency is becoming the critical performance factor for many (most?)
>     Internet applications, e.g. interactive web, web services, voice,
>     conversational video, interactive video, interactive remote presence,
>     instant messaging, online gaming, remote desktop, cloud-based
>     applications & services, and remote control of machinery and
>     industrial processes.
> -->
>
>
> 5) <!--[rfced] We note the use of <tt> and <em> within this document.
> FYI, <tt> yields fixed-width font in the HTML and PDF outputs.
> In the text output, <em> yields an underscore before and after.
> In the HTML and PDF outputs, <em> yields italics.
>
> Please review carefully and let us know if the output is acceptable or
> if any updates are desired.
> -->	
>
>
> 6) <!--[rfced] RFC 2309 has been obsoleted by RFC 7567. May we add a note
> about this relationship as follows?
>
> Original:
>     However, RED [RFC2309] and other algorithms from the 1990s were
>     sensitive to their configuration and hard to set correctly.
>
> Perhaps:
>     However, RED [RFC2309] (which has been obsoleted
>     by [RFC7567]) and other algorithms from the 1990s were
>     sensitive to their configuration and hard to set correctly.
> -->
>
>
> 7) <!--[rfced] Would it be correct to move the RFC 3649 citation after
> "congestion control"?
>
> Original:
>     Given regular broadband bit-rates over WAN distances are
>     already [RFC3649] beyond the scaling range of Reno congestion
>     control, 'less unscalable' Cubic [RFC8312] and Compound
>     [I-D.sridharan-tcpm-ctcp] variants of TCP have been successfully
>     deployed.
>
> Perhaps:
>     Given that regular broadband bitrates over WAN distances are
>     already beyond the scaling range of Reno congestion
>     control [RFC3649], 'less unscalable' CUBIC [RFC8312] and Compound
>     [CTCP] variants of TCP have been successfully deployed.
> -->
>
>
> 8) <!--[rfced] Terminology section:
> Due to your note that these definitions "should be identical" to the ones
> in Section 3 of RFC-to-be 9330, we have updated these definitions to match
> the current text in RFC-to-be 9330, with the exceptions noted below.
> (If any changes are requested for this document, RFC-to-be 9330 will be also
> updated.)
>
> Please refer to this diff file (comparing the relevant sections in the
> current 9330 and current 9331):
> https://www.rfc-editor.org/authors/rfc9330_vs_9331_term_diff.html
>
> a) For "Classic Congestion Control", should this document be updated to
> match the definition in 9330? They are significantly different.
>
> b) For "Scalable Congestion Control", should the "This maintains the same
> degree..." sentence be removed from this document (in order to match 9330)?
> The only difference is this one sentence.
> -->
>
>
> 9) <!--[rfced] "Experimental" (capitalized) can be used to refer to the
> status of an RFC (or the intended status of a document).
> Here, it seems it refers to the packet marking treatment, so it
> remains lowercase. (FYI, the word "track" has been removed in several
> instances in this document, as "Experimental track" is typically referred
> to as "Experimental status" or simply "Experimental".)
> Also, may the repetition of "treatment" be avoided as follows?
>
> Original:
>     The L4S treatment is an experimental track alternative packet
>     treatment to the Classic ECN treatment in [RFC3168], ...
>
> Current:
>     The L4S treatment is an experimental alternative packet marking
>     treatment to the Classic ECN treatment in [RFC3168], ...
>
> Option A:
>     The L4S treatment is an experimental alternative packet marking
>     to the Classic ECN treatment in [RFC3168], ...
>
> Option B (if it's necessary to mention Experimental status):
>     L4S ECN (which is specified in this Experimental RFC) is an
>     alternative packet marking treatment to the Classic ECN treatment
>     in [RFC3168], ...
> -->
>
>
> 10) <!--[rfced] RFC 4960 has been obsoleted by RFC 9260. May we add a note
> about this relationship as follows and add RFC 9260 to the Informative
> References?
>
> Original:
>     SCTP: A suitable ECN feedback mechanism for SCTP could add a chunk
>           to report the number of received CE marks (as described in a long-
>           expired draft [I-D.stewart-tsvwg-sctpecn] or as sketched out in
>           Appendix A of the now obsolete second standards track
>           specification of SCTP [RFC4960]).
>
> Perhaps:
>     SCTP: A suitable ECN feedback mechanism for SCTP could add a chunk
>           to report the number of received CE marks (as described in a long-
>           expired document [SCTP-ECN] or as sketched out in Appendix A
>           of the second Standards Track specification of SCTP [RFC4960],
>           which has been obsoleted by [RFC9260]).
>
> Or (as "the second Standards Track specification" seems necessary):
>     SCTP: A suitable ECN feedback mechanism for SCTP could add a chunk
>           to report the number of received CE marks (as described in a long-
>           expired document [SCTP-ECN] or as sketched out in Appendix A
>           of SCTP [RFC4960], which has been obsoleted by [RFC9260]).
> -->
>
>
> 11) <!--[rfced] Please review whether any of the notes in this document should be
> in the <aside> element. It is defined as "a container for content that is
> semantically less important or tangential to the content that surrounds it"
> (https://authors.ietf.org/en/rfcxml-vocabulary#aside).
> -->	
>
>
> 12) <!--[rfced] For clarity, should RFC 3168 be added as a reference here?
>
> Original:
>        *  Drop Tail: Coexistence between L4S and Classic flows is not in
>           doubt where the bottleneck does not support any form of ECN,
>           which has remained by far the most prevalent case since the ECN
>           RFC was published in 2001.
>
> Perhaps:
>        *  Drop Tail: Coexistence between L4S and Classic flows is not in
>           doubt where the bottleneck does not support any form of ECN,
>           which has remained by far the most prevalent case since the ECN
>           spec [RFC3168] was published in 2001.
> -->
>
>
> 13) <!--[rfced] Per RFC 5865, should "Voice-Admit" be "VOICE-ADMIT" (1 instance)?
>
> Original:
>     specific Diffserv codepoints that indicate traffic with limited
>     burstiness such as the EF (Expedited Forwarding [RFC3246]),
>     Voice-Admit [RFC5865] or proposed NQB (Non-Queue-Building
>     [I-D.ietf-tsvwg-nqb]) service classes or equivalent
>     local-use DSCPs (see [I-D.briscoe-tsvwg-l4s-diffserv]).
>
> Perhaps:
>     specific Diffserv codepoints that indicate traffic with limited
>     burstiness such as EF [RFC3246], VOICE-ADMIT [RFC5865], or
>     proposed Non-Queue-Building (NQB) [NQB-PHB] service classes or
>     equivalent Local-use DSCPs (see [L4S-DIFFSERV]).
> -->
>
>
> 14) <!--[rfced] FYI, we changed "to an L4S identifier" to "of an L4S identifier"
> for clarity. Please review whether that changes the intended meaning.
>
> Original:
>     In order to include non-L4S packets in the L queue, a network node
>     MUST NOT alter Not-ECT or ECT(0) in the IP-ECN field to an L4S
>     identifier.
>
> Current:
>     In order to include non-L4S packets in the L queue, a network node
>     MUST NOT alter Not-ECT or ECT(0) in the IP-ECN field of an L4S
>     identifier.
> -->
>
>
> 15) <!--[rfced] Does "not necessarily completely regularly" mean "not
> necessarily on a regular basis"?
>
> Original:
>     Nonetheless, an application can be considered safe enough if
>     it paces packets out (not necessarily completely regularly)
>     such that its maximum instantaneous rate from packet to
>     packet stays well below a typical broadband access rate.
>
> Perhaps:
>     Nonetheless, an application can be considered safe enough if
>     it paces packets out (not necessarily on a regular basis)
>     such that its maximum instantaneous rate from packet to
>     packet stays well below a typical broadband access rate.
> -->
>
>
> 16) <!--[rfced] Please clarify what "that" refers to in the following:
>
> Original:
>     However, queuing delay in the L queue will probably rise to that
>     controlled by the Classic (drop-based) AQM.
> -->
>
>
> 17) <!--[rfced] RFC 3168 only mentions "ECT(0)" and "ECT(1)",
> not "ECT0" and "ECT1". Should this sentence be updated?
>
> Original:
>     Defining ECT(1) as the L4S identifier introduces a difference between
>     the effects of ECT0 and ECT1 that RFC 3168 previously defined as
>     distinct but with equivalent effect.
> -->
>
>
> 18) <!--[rfced] The following quote is not a direct quote from RFC 8257.
> Please let us know how this text be updated for accuracy.
>
> Original:
>     In the particular case of DCTCP, the DCTCP
>     specification [RFC8257] states that "It is RECOMMENDED that an
>     implementation deal with loss episodes in the same way as
>     conventional TCP."  For safe deployment, Section 4.3 requires any
>     specification of a scalable congestion control for the public
>     Internet to define the above requirement as a "MUST".
>
> Perhaps you intended to quote this sentence in Section 3.5 of RFC 8257?
>
>     A DCTCP sender MUST react to loss episodes in the same way as
>     conventional TCP, including fast retransmit and fast recovery
>     algorithms, as specified in [RFC5681].
> -->
>
>
> 19) <!--[rfced] A "third approach" is mentioned here. Will it be clear to
> readers what the first and second approaches are? Please clarify.
>
> Original:
>     Even though a bottleneck is L4S capable, it might still become
>     overloaded and have to drop packets. In this case, the sender may
>     receive a high proportion of packets marked with the CE bit set and
>     also experience loss. Current DCTCP implementations each react
>     differently to this situation. At least one implementation reacts
>     only to the drop signal (e.g., by halving the CWND) and at least
>     another DCTCP implementation reacts to both signals (e.g., by
>     halving the CWND due to the drop and also further reducing the CWND
>     based on the proportion of marked packet). A third approach for the
>     public Internet has been proposed that adjusts the loss response to
>     result in a halving when combined with the ECN response.
>
> Perhaps:
>     [...]  Current DCTCP implementations each react differently
>     to this situation. One approach (used by at least one implementation)
>     is to react only to the drop signal (e.g., by halving the CWND);
>     another approach (used by at least one implementation) is to
>     react to both signals [...].  A third approach for the public
>     Internet has been proposed ...
> -->	
>
>
> 20) <!--[rfced] Since there are multiple expansions for "CDN",
> is "Content Delivery Network" correct here?
>
> Original:
>     This allows for the possibility that the operator of an L4S
>     sender (e.g. a CDN) might prefer to test out-of-band for
>     signs of Classic ECN AQMs,...
>
> Current:
>     This allows for the possibility that the operator of an L4S
>     sender (e.g., a Content Delivery Network (CDN)) might prefer
>     to test out-of-band for signs of Classic ECN AQMs,...
> -->
>
>
> 21) <!--[rfced] We added "its" for clarity and rephrased "ex-ToS byte" to
> "former Type-of-Service (ToS) byte" in order to include the
> expansion of "ToS". Please let us know if you prefer otherwise.
>
> Original:
>     Also, not changing codepoint avoids the risk of being
>     flipped to a different path by a load balancer or multipath routing
>     that hashes on the whole of the ex-ToS byte (unfortunately still a
>     common pathology).
>
> Current:
>     Also, not changing its codepoint avoids the risk of being
>     flipped to a different path by a load balancer or multipath routing
>     that hashes on the whole of the former Type-of-Service (ToS) byte (which is
>     unfortunately still a common pathology).
> -->
>
>
> 22) <!--[rfced] Since there is typically a space between the digit and unit of
> measure, is it acceptable to insert spacing in the following functions?
>
> Original:
>     rtt_virt = max(rtt, 25ms)
>
>     rtt_virt = rtt + 10ms
>
> Perhaps:
>     rtt_virt = max(rtt, 25 ms)
>
>     rtt_virt = rtt + 10 ms
> -->
>
>
> 23) <!--[rfced] Would you like to add "in item 4 of Section 4.3"
> so the reader knows where this particular wording came from?
>
> Original:
>     Therefore, rather than requiring strict RTT-independence, the
>     wording says "as independent of RTT as possible without
>     compromising stability or utilization".
>
> Perhaps:
>     Therefore, rather than requiring strict RTT-independence, the
>     wording in item 4 of Section 4.3 is "as independent of RTT as
>     possible without compromising stability or utilization".
> -->
>
>
> 24) <!--[rfced] FYI: We removed "for RDMA" from this sentence since
> "RDMA" is included in the expansion of "RoCEv2"; please let us
> know any concerns.
>
> Original:
>     As mentioned above, hardware implementations of loss recovery using
>     DupACK counting exist (e.g. some implementations of RoCEv2 for
>     RDMA).
>
> Current:
>     As mentioned above, hardware implementations of loss recovery using
>     DupACK counting exist (e.g., some implementations of Remote Direct
>     Memory Access over Converged Ethernet version 2 (RoCEv2).
> -->
>
>
> 25) <!--[rfced] May the following sentence be rephrased for clarity
> (specifically, "every 8x scaling of Cubic's flow rate")?
>
> Original:
>     Even when out of its Reno-compatibility mode, every 8x scaling of
>     Cubic's flow rate leads to 2x more acceleration delay.
>
> Perhaps:
>     Even when out of its Reno-compatibility mode, if CUBIC's flow
>     rate scales by 8 times, it leads to 2 times more acceleration delay.
> -->
>
>
> 26) <!--[rfced] Is the spacing intentional for "150,151,152" or should
> spacing be added for consistency?
>
> Original:
>     For example consider N=3, and consider the sequence of
>     packets 100, 101, 102, 103,... and imagine that packets
>     150,151,152 from later in the flow are injected as follows:
>     100, 150, 151, 101, 152, 102, 103... If this were late
>     reordering,
>
> Perhaps:
>     For example, consider N=3, and consider the sequence of
>     packets 100, 101, 102, 103,... Imagine that packets
>     150, 151, 152 from later in the flow are injected as follows:
>     100, 150, 151, 101, 152, 102, 103,... If this were late
>     reordering, even one packet arriving out of...
> -->
>
>
> 27) <!--[rfced] Is "to cater for" accurate wording here, or would
> "to handle" or "as it does not allow for" or otherwise be more clear?
>
> Original:
>     However, in some VPN implementations the maximum anti-replay window
>     is insufficient to cater for a large delay difference at prevailing
>     packet rates.
>
> Perhaps:
>     However, in some VPN implementations, the maximum anti-replay window
>     is insufficient to handle a large delay difference at
>     prevailing packet rates.
> -->
>
>
> 28) <!--[rfced] Usage of 'round' in 'work-rounds', 'safe way round', and
> 'passed correctly round' reads oddly for those not familiar with this
> British variant of 'around'. Please consider updating the phrases for
> readability.
> For example:
> alternative work-arounds
> the safe way around
> passed correctly around
> -->
>
>
> 29) <!--[rfced] FYI, as per the mail from Bob Briscoe on 2022-09-12, British English
> spelling has been selected by the authors. Specifically, he wrote:
> "(Oxford variant with -ize, -ization but -yse)"
> So, we have updated the document accordingly, changing instances of
> "neutralise", "standardisation", etc.
> -->
>
>
> 30) <!-- [rfced] Throughout the text, the following terminology appears to be used
> inconsistently. Please review these occurrences and let us know if/how
> they may be made consistent.
>
>   queue per flow vs. per-flow queue
>        [Note: is "queue per flow" the same as "per-flow queue"?
>         If so, we will use the latter form.]
>
>
>   TCP-Reno-friendly (2 instances) vs. Reno-friendly
>        [Note: should these terms be the same, or are they different?
>        Section 1.2 mentions that "Reno-friendly" replaces "TCP-friendly"
>
>   Also, should "Reno-compatibility mode" be "Reno-friendly mode"?
>       [The former term does not appear in RFC-to-be 9330.]
>
> FYI, we used the latter forms below to match use in the companion
> document or referenced RFCs:
>
>   Cubic -> CUBIC (per RFC 8312)
>   Coupled DualQ AQM -> DualQ Coupled AQM
>   Scalable -> scalable (but capitalized when part of a term)
> -->
>
>
> 31) <!-- [rfced] Please review the "Inclusive Language" portion of the online
> Style Guide<https://www.rfc-editor.org/styleguide/part2/#inclusive_language>  
> and let us know if any changes are needed. Note that our script did not flag
> any words in particular, but this should still be reviewed as a best practice.
> -->
>
>
> 32) <!--[rfced] We see a number of author-inserted comments in the XML file of
> this document. We are unsure if these have been resolved. Please review
> and let us know if these can be deleted or if they need to be addressed.
> -->
>
>
> Thank you.
>
> RFC Editor/kc/ar
>
>
> On Nov 18, 2022,[e-mail]  wrote:
>
> *****IMPORTANT*****
>
> Updated 2022/11/18
>
> RFC Author(s):
> --------------
>
> Instructions for Completing AUTH48
>
> Your document has now entered AUTH48.  Once it has been reviewed and
> approved by you and all coauthors, it will be published as an RFC.
> If an author is no longer available, there are several remedies
> available as listed in the FAQ (https://www.rfc-editor.org/faq/).
>
> You and you coauthors are responsible for engaging other parties
> (e.g., Contributors or Working Group) as necessary before providing
> your approval.
>
> Planning your review
> ---------------------
>
> Please review the following aspects of your document:
>
> *  RFC Editor questions
>
>    Please review and resolve any questions raised by the RFC Editor
>    that have been included in the XML file as comments marked as
>    follows:
>
>    <!-- [rfced] ... -->
>
>    These questions will also be sent in a subsequent email.
>
> *  Changes submitted by coauthors
>
>    Please ensure that you review any changes submitted by your
>    coauthors.  We assume that if you do not speak up that you
>    agree to changes submitted by your coauthors.
>
> *  Content
>
>    Please review the full content of the document, as this cannot
>    change once the RFC is published.  Please pay particular attention to:
>    - IANA considerations updates (if applicable)
>    - contact information
>    - references
>
> *  Copyright notices and legends
>
>    Please review the copyright notice and legends as defined in
>    RFC 5378 and the Trust Legal Provisions
>    (TLP –https://trustee.ietf.org/license-info/).
>
> *  Semantic markup
>
>    Please review the markup in the XML file to ensure that elements of
>    content are correctly tagged.  For example, ensure that <sourcecode>
>    and <artwork> are set correctly.  See details at
>    <https://authors.ietf.org/rfcxml-vocabulary>.
>
> *  Formatted output
>
>    Please review the PDF, HTML, and TXT files to ensure that the
>    formatted output, as generated from the markup in the XML file, is
>    reasonable.  Please note that the TXT will have formatting
>    limitations compared to the PDF and HTML.
>
>
> Submitting changes
> ------------------
>
> To submit changes, please reply to this email using ‘REPLY ALL’ as all
> the parties CCed on this message need to see your changes. The parties
> include:
>
>    *  your coauthors
>
>    *[e-mail]  (the RPC team)
>
>    *  other document participants, depending on the stream (e.g.,
>       IETF Stream participants are your working group chairs, the
>       responsible ADs, and the document shepherd).
>
>    *[e-mail], which is a new archival mailing list
>       to preserve AUTH48 conversations; it is not an active discussion
>       list:
>
>      *  More info:
>         https://mailarchive.ietf.org/arch/msg/ietf-announce/yb6lpIGh-4Q9l2USxIAe6P8O4Zc
>
>      *  The archive itself:
>         https://mailarchive.ietf.org/arch/browse/auth48archive/
>
>      *  Note: If only absolutely necessary, you may temporarily opt out
>         of the archiving of messages (e.g., to discuss a sensitive matter).
>         If needed, please add a note at the top of the message that you
>         have dropped the address. When the discussion is concluded,
>         [e-mail]  will be re-added to the CC list and
>         its addition will be noted at the top of the message.
>
> You may submit your changes in one of two ways:
>
> An update to the provided XML file
> — OR —
> An explicit list of changes in this format
>
> Section # (or indicate Global)
>
> OLD:
> old text
>
> NEW:
> new text
>
> You do not need to reply with both an updated XML file and an explicit
> list of changes, as either form is sufficient.
>
> We will ask a stream manager to review and approve any changes that seem
> beyond editorial in nature, e.g., addition of new text, deletion of text,
> and technical changes.  Information about stream managers can be found in
> the FAQ.  Editorial changes do not require approval from a stream manager.
>
>
> Approving for publication
> --------------------------
>
> To approve your RFC for publication, please reply to this email stating
> that you approve this RFC for publication.  Please use ‘REPLY ALL’,
> as all the parties CCed on this message need to see your approval.
>
>
> Files
> -----
>
> The files are available here:
>    https://www.rfc-editor.org/authors/rfc9331.xml
>    https://www.rfc-editor.org/authors/rfc9331.html
>    https://www.rfc-editor.org/authors/rfc9331.pdf
>    https://www.rfc-editor.org/authors/rfc9331.txt
>
> Diff file of the text:
>    https://www.rfc-editor.org/authors/rfc9331-diff.html
>    https://www.rfc-editor.org/authors/rfc9331-rfcdiff.html  (side by side)
>
> Diff of the XML:
>    https://www.rfc-editor.org/authors/rfc9331-xmldiff1.html
>
> [removed extraneous links]
>
> Tracking progress
> -----------------
>
> The details of the AUTH48 status of your document are here:
>    https://www.rfc-editor.org/auth48/rfc9331
>
> Please let us know if you have any questions.
>
> Thank you for your cooperation,
>
> RFC Editor
>
> --------------------------------------
> RFC9331 (draft-ietf-tsvwg-ecn-l4s-id-29)
>
> Title            : The Explicit Congestion Notification (ECN) Protocol for Low Latency, Low Loss, and Scalable Throughput (L4S)
> Author(s)        : K. De Schepper, B. Briscoe, Ed.
> WG Chair(s)      : Gorry Fairhurst, David L. Black, Marten Seemann
>
> Area Director(s) : Martin Duke, Zaheduzzaman Sarker

-- 
________________________________________________________________
Bob Briscoehttp://bobbriscoe.net/