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

[Karen Moore <[e-mail]>]

Hello Bob,

Thanks for the updated files; these changes are now reflected in our files. Within the XML file, we have responded to your new notes with “[RFC Editor 3]” (all of your updates are agreeable). Below are responses to your comments within this email.

Notes:
1) For "[DCttH19]”, we updated the URL from "https://bobbriscoe.net/pubs.html#DCttH_TR” to "https://bobbriscoe.net/projects/latency/dctth_journal_draft20190726.pdf”. 

2) We added “Burstiness” as a keyword for this document and have asked for it to be added to 9330 as well.

3) Acknowledging the proposed rephrase of text in Section 5.1; will have Martin approve it.

4) Acknowledging that the set of 3 changes for “mark” or “marking” is agreeable.

FILES
(Please refresh)

The updated XML file is here:
 https://www.rfc-editor.org/authors/rfc9331.xml

The updated output files are here:
 https://www.rfc-editor.org/authors/rfc9331.txt
 https://www.rfc-editor.org/authors/rfc9331.pdf
 https://www.rfc-editor.org/authors/rfc9331.html

These diff files show all changes made during AUTH48:
 https://www.rfc-editor.org/authors/rfc9331-auth48diff.html
 https://www.rfc-editor.org/authors/rfc9331-rfcdiff.html (side by side)

These diff files show changes made during the last editing round:
 https://www.rfc-editor.org/authors/rfc9331-lastdiff.html
 https://www.rfc-editor.org/authors/rfc9331-lastrfcdiff.html (side by side)

This diff file shows all changes made to date:
 https://www.rfc-editor.org/authors/rfc9331-diff.html

Please contact us with any further updates or with your approval of the document in its current form.  We will await approvals from each author and the AD prior to moving forward in the publication process.

For the AUTH48 status of this document, please see:
 https://www.rfc-editor.org/auth48/rfc9331

Best regards,

RFC Editor/kc

> On Dec 14, 2022, at 3:57 PM, Bob Briscoe <[e-mail]> wrote:
> 
> Karen,
> I've written each of my comments tagged [BB3] below into the attached XML, and altered it accordingly as well, except the [DCttH19] reference, which I have left for you.
> 
> On 13/12/2022 02:30, Karen Moore wrote:
>> Hi Bob and Martin (AD)*,
>> 
>> Thank you for the updated XML file (and the diffs); we have updated our files accordingly (links to the files are further down in the email).  We have added comments to the items marked as “BB2” in the XML file (to note that we agree with all of your edits - searchable as "[RFC Editor 2]"). Below are some additional notes to address the comments within this email, plus one new question (see #9).
>> 
>> Notes:
>> 1) We have asked for RFC-to-be 9330 to be reflect "[SCReAM-LS4]” instead of  "[SCReAM]”
>> 2) Updates made to the expansions are agreeable
>> 3) This is agreeable: “per application-flow”
>> 4) Regarding the use of <bcp14> tags, thank you for posing your questions to the RSWG
>> 5) This is agreeable: <<DOCSIS doesn't need a reference, just as LTE and 5G don't. They are names of technologies.>>
>> 6) This is agreeable: <<I didn't add a citation for RoCEv2...I just expanded RDMA…>>
>> 7) This is agreeable: <<TCP Prague -> Prague>>
>> 8) We will seek AD approval for item #74 (it’s included in the portion for Martin below)
>> 9) Regarding "[DCttH19]", if possible, please provide a URL for
>> the published document, rather than to a portion of the
>> publications page on a personal site.
>> 
>> Original:
>>   [DCttH19]  De Schepper, K., Bondarenko, O., Tilmans, O., and B.
>>              Briscoe, "`Data Centre to the Home': Ultra-Low Latency for
>>              All", Updated RITE project Technical Report , July 2019,
>>              <https://bobbriscoe.net/pubs.html#DCttH_TR>.
> 
> [BB3] I'm afraid that is the only instance of that report on the web. We can't really file it on arXiv now, because it is an earlier version of the one we have now filed on arXiv [L4Seval22].
> Unfortunately, the Jul'19 draft is the only version with the specific experiments discussed where the [DCttH19] citation is used, which is why we kept it, and didn't update this instance to [L4Seval22].
> 
> A more specific URL to the citation is: https://bobbriscoe.net/pubs.html#DeSchepper19a
> Or the specific URL of the PDF is: https://bobbriscoe.net/projects/latency/dctth_journal_draft20190726.pdf
> 
>> 
>> ----------
>> *Martin, please review the following updates to Sections 5.1, 5.4.2, and 7.2 and Appendices A.1.4  and C.1 and let us know if you approve.  The changes are highlighted below and can also be reviewed here: https://www.rfc-editor.org/authors/rfc9331-auth48diff.html
>> 
>> 1) 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
>> 
>> 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) Section 5.1 - rephrased
>> 
>> Old:
>>     Once disabled, all packets of all ECN codepoints will receive Classic treatment
>>     and ECT(1) packets MUST be treated as if they were Not-ECT.
>>    New:
>>    Once disabled, ECT(1) packets MUST be treated as if they were
>>    Not-ECT, then all packets of all ECN codepoints will receive
>>    treatment compatible with Classic congestion control.
> 
> [BB3] I met with the co-authors of the 3 drafts last night, and they suggested that this would be clearer without the last clause at all, i.e.
> 
> Proposed:
>   Once disabled, ECT(1) packets MUST be treated as if they were
>   Not-ECT.
> 
> 
> 
>> 
>> 3) Section 5.4.2 -  replaced “Layer-4” with “transport-layer”
>> 
>> Old:
>>    At a node with per-flow queueing (e.g. FQ-CoDel [RFC8290]), the L4S
>>    identifier could complement the Layer-4 flow ID as a further level of
>>    flow granularity (i.e. Not-ECT and ECT(0) queued separately from
>>    ECT(1) and CE packets).
>> 
>> New:
>>    At a node with per-flow queuing (e.g., FQ-CoDel [RFC8290]), the L4S
>>    identifier could complement the transport-layer flow ID as a further
>>    level of flow granularity (i.e., Not-ECT and ECT(0) queued separately
>>    from ECT(1) and CE packets).
>> 
>> 4) Section 7.2 -  replaced “EWMA” with “average”
>> 
>> Old:
>>    Originally, this was due to a bug in the initialization of the
>>    congestion EWMA in the Linux implementation of TCP Prague.
>> 
>> New:
>>    Originally, this was due to a bug in the initialization of the
>>    congestion average in the Linux implementation of TCP Prague.
>> 
>> 5) Appendix A.1.4 - rephrased, including the removal of “MUST”
>> 
>> Old:
>>    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”.
>> 
>> New:
>>    In the particular case of DCTCP, the DCTCP
>>    specification [RFC8257] states that "A DCTCP sender MUST react to loss episodes in
>>    the same way as conventional TCP,…".  To ensure any Scalable congestion control
>>    is safe to deploy over the public Internet, Item 3 of Section 4.3 in the present spec
>>    does not require precisely the same response as Reno TCP, but it does require a
>>    response that will coexist safely with Classic congestion controls like Reno.
>> 
>> 6)  Appendix A.1.4 - rephrased
>> 
>> Old:
>>    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.
>> 
>> New:
>>    One approach is to react only to the drop
>>    signal (e.g., by halving the CWND); another approach is to react to both
>>    signals, which reduces CWND by more than half. A compromise
>>    between these two has been proposed where the loss response is adjusted to
>>    result in a halving when combined with any ECN response earlier in the same
>>    round.
>> 
>> 7) Throughout the text:
>> Changed “ECN” to “IP-ECN”
> 
> [BB3] @Martin, it was not quite 'throughout' -- only where it referred to the ECN field in the IP header (to distinguish for instance from the ECN flags in the TCP header).
> 
> [BB3] 75. While reviewing RFC-to-be 9332, we thought of another keyword for all three L4S drafts. I've added it to RFC-to-be 9331.
> Please also add the keyword 'Burstiness' to RFC-to-be 9330.
> 
> [BB3] 76. My co-authors have also suggested a further set of 3 changes, where the word 'mark' or 'marking' has been inadvertently used for initially setting the ECN field, when 'ECN marking' is defined as the network changing the ECN field to CE. I've applied the following three changes to the XML:
> 
> if packets originally marked ECT(0)
> -> if packets originally set to ECT(0)
> 
> mis-marked bursty traffic
> -> mis-identified bursty traffic
> 
> if the most recent ECT packet in the same flow had been marked ECT(0)
> -> if the most recent ECT packet in the same flow had been set to ECT(0)
> 
> There are no incorrect instances of 'mark' in RFC-to-be 9330.
> For RFC-to-be 9332, I'll deal with this issue when I send my first review email shortly.
> 
> FILES
> I've attached edited XML rfc9331g.xml
> And an rfcdiff from your latest (rfc9331f)
> 
> Thank you again,
> 
> 
> 
> Bob
> 
>> 
>> --------
>> FILES
>> (Please refresh)
>> 
>> The updated XML file is here:
>>  https://www.rfc-editor.org/authors/rfc9331.xml
>> 
>> The updated output files are here:
>>  https://www.rfc-editor.org/authors/rfc9331.txt
>>  https://www.rfc-editor.org/authors/rfc9331.pdf
>>  https://www.rfc-editor.org/authors/rfc9331.html
>> 
>> These diff files show all changes made during AUTH48:
>>  https://www.rfc-editor.org/authors/rfc9331-auth48diff.html
>>  https://www.rfc-editor.org/authors/rfc9331-rfcdiff.html (side by side)
>> 
>> These diff files show changes made during the last editing round:
>>  https://www.rfc-editor.org/authors/rfc9331-lastdiff.html
>>  https://www.rfc-editor.org/authors/rfc9331-lastrfcdiff.html (side by side)
>> 
>> This diff file shows all changes made to date:
>>  https://www.rfc-editor.org/authors/rfc9331-diff.html
>> 
>> Please contact us with any further updates or with your approval of the document in its current form.  We will await approvals from each author prior to moving forward in the publication process.
>> 
>> For the AUTH48 status of this document, please see:
>> https://www.rfc-editor.org/auth48/rfc9331
>> 
>> Thank you,
>> 
>> RFC Editor/kc
>> 
>> 
>>> On Dec 11, 2022, at 2:18 PM, Bob Briscoe <[e-mail]> wrote:
>>> 
>>> Karen, See [BB2] inline.
>>> 
>>> On 01/12/2022 23:51, Karen Moore wrote:
>>>> Hello Bob,
>>>> 
>>>> Thank you for your detailed review and comments.  In the XML file, we have removed the questions that were marked “[rfced]” as we believe these have all been addressed (except for two, which need AD approval).  We replied to each of the comments marked with “[BB]” - you can search on “[RFC Editor]” to see our responses.  Most indicate that we agree with your edits ("[RFC Editor] Ok - agreeable"). Below, please see the list of items where an action was taken.  Should you have any questions or need clarification on anything, please let us know.
>>>> 
>>>> Note that there are some updates that will need AD approval; we will seek approval once you have had a chance to review this round of edits.
>>>> 
>>>> -------------------------
>>>> RFC Editor Actions:
>>> [BB] Thank you. All AOK, except the three with responses below...
>>> 
>>>> 1) reverted the first expansions of "DCTCP" and "DualQ". Expanded both on the next mentions  (used "Dual Queue Coupled AQM" per 9330 (instead of "Dual Queue (DualQ) Coupled AQM”). Please let us know if any further changes are needed.
>>>> 2) reverted the expansions for “SCReAM", “SCTP", and “DCCP" and added citations for “SCTP" and “DCCP".
>>>> 3) reverted "[SCReAM]" to "[SCReAM-LS4]” throughout.
>>> [BB2] Pls could you make RFC9330 consistent with this (if only to avoid it causing a diff in the terminology section).
>>> 
>>>> 4) reverted the following expansions to be consistent with RFC-to-be 9330. If any further changes are desired, please let us know.
>>>> 
>>>>  AQM (in the intro)
>>>>  RED
>>>>  FQ-CoDel
>>>>  PIE
>>>>  VPN
>>>>  ABE
>>>>  ACK
>>>>  RACK
>>>>  DupACK
>>>>  TRILL
>>>>  AH
>>>>  ESP
>>>>  CDN
>>>>  Ex-ToS
>>>>  DOCSIS
>>>>  RoCEv2
>>>>  A2DTCP
>>>>  VCP
>>>> 
>>>> Kept:
>>>>  LDAP (expanded in 9330)
>>>>  VoIP (expanded in 9330)
>>> [BB2] Sorry, I should have been clearer when I said "consistent with RFC9330". I meant:
>>> * For technologies that most readers know by their abbreviations, I have avoided expansion where it would make a sentence unreasonably long or complex, and instead  expansion is either deferred to a later sentence, referred to via citation, or both.
>>> * For a technology that is only mentioned in passing, I have expanded, rather than using a citation.
>>> * Excessive expansion of abbreviations tends to be more of an issue in the Abstract/Introduction. Later in a doc, I've used expansion more liberally.
>>> 
>>> Specifically:
>>> AQM is already expanded in the abstract.
>>> 
>>> I've re-expanded the following:
>>> RED
>>> VPN
>>> ACK
>>> RACK
>>> DupACK
>>> CDN
>>> Ex-ToS
>>> DOCSIS
>>> RoCEv2
>>> A2DTCP
>>> VCP
>>> 
>>> And I've explained the rest via their citations:
>>> FQ-CoDel
>>> PIE
>>> ABE
>>> TRILL
>>> AH
>>> ESP
>>> 
>>> STATUS2: No further action if agreeable to the RFC Editor.
>>> 
>>> 
>>>> 5) re: "(Relentless, SCReAM, etc.)”,  we asked for 9330 to be updated to match.
>>>> 6) removal of "uses the ECN field as an identifier” is agreeable. We have asked for the same update to be made in RFC-to-be 9330.
>>>> 7) removed the <blockquote> tags around the quote that is 4 lines.
>>>> 8) reverted the comma after “Whereas” (current: “Whereas, in the Classic Approach,…”).
>>>> 9) reverted the second hyphen in "'per-application flow” (current: “per-application-flow”).
>>> [BB2] My co-author, Greg, pointed out that when before the noun it should be 'per
>>> application-flow queues', where 'per' is not hyphenated as in 'per person quotas'
>>> but 'application-flow' is hyphenated as a compound adjective.
>>> 
>>> STATUS2: No further action if agreeable to the RFC Editor.
>>> 
>>>> 10) reverted the change made to the IANA URL in Section 8.  IANA prefers that we point to the top-level registry rather than the subregistry (so the document now reflects "https://www.iana.org/assignments/dscp-registry” instead of "https://www.iana.org/assignments/dscp-registry/#ecn-field”).
>>>> 11) fyi - we are ok with including <tfoot> in Table 2.
>>>> 12) reverted RFCs 9330 and 9332 to informative references.
>>>> 13) fixed the output of the I-Ds in the Informative References section.
>>>> 
>>>> --------------------------------------------
>>>> Additional Questions/Clarifications:
>>>> 1) Regarding the comment below, our practice is to place <bcp14> tags around each normative keyword, whether they are in quotes or not.  For normative keywords within a quote from another RFC, we use the tags even if BCP 14 text is not used in the main document.  Given this, we have not made any further changes to the XML.
>>> [BB2] Yes, I can see that it is the RFC Editor's practice. But I'm asking whether it is a correct practice :|
>>> 
>>> Nonetheless, this is a wider question that applies to all RFCs, not just this one. So it shouldn't hold up this RFC. I've raised it on the RSWG list instead.
>>> 
>>>>> [BB] 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.
>>>> 2 a) Would it be correct to add "[DOCSIS-QPROT]” as a reference for “DOCSIS” (in A.1.8)?
>>> [BB2] Nope.
>>> Anyway, DOCSIS doesn't need a reference, just as LTE and 5G don't. They are names of technologies.
>>> 
>>>> b) Would you like to add a citation for “RoCEv2”? Also, we assume that “RDMA” does not need to be added back since it is part of “RoCEv2” when expanded; please review.
>>>> 
>>>> Current:
>>>>    As mentioned above, hardware implementations of loss recovery using
>>>>    DupACK counting exist (e.g., some implementations of RoCEv2).
>>> 72. [BB2] I didn't add a citation for RoCEv2, 'cos it's just mentioned in passing. Anyway we would really want a citation for the hardware implementation of loss recovery in RoCEv2, and there isn't one (it's proprietary). I just expanded RDMA, without mentioning the abbreviation, like you had done earlier.
>>> 
>>> Finally, I noticed some need for additional editing, two of which I've pasted below.
>>> They can also be found already written into the attached XML, and annotated with comments tagged with [BB2] and ending with 'STATUS2':
>>> I've identified that #74 will require AD approval, 'cos it's disambiguating normative text.
>>> 
>>> 73. [BB2] TCP Prague -> Prague
>>> (the cited draft used to be solely for TCP, but it was generalized to all transport protocols at -01)
>>> STATUS2: No further action if agreeable to the RFC Editor.
>>> 
>>> 74. [BB2] Original:
>>>     Once disabled, all packets of all ECN codepoints will receive Classic treatment
>>>     and ECT(1) packets MUST be treated as if they were Not-ECT.
>>> 
>>> I realized that 'Classic treatment' could ambiguously be read as 'Classic ECN treatment',
>>> which would be confusing for the Not-ECT codepoint.
>>> So I've clarified that it's '...treatment compatible with Classic congestion control'.
>>> I've also switch the two parts of the sentence, so the normative statement is first, because
>>> the original first part was just a consequence of the normative part.
>>> STATUS2: No further action if agreeable to the RFC Editor and the AD.
>>> 
>>> There are also a couple of minor editorial changes you can find in the attached diff (using rfcdiff relative to txt compiled from your most recent xml which I've called rfc9331d.xml).
>>> 
>>> For the archive, I've also attached a diff relative to the draft-29 approved by the IESG.
>>> 
>>> Cheers
>>> 
>>> 
>>> Bob
>>> 
>>>> 
>>>> The updated XML file is here:
>>>>  https://www.rfc-editor.org/authors/rfc9331.xml
>>>> 
>>>> The updated output files are here:
>>>>  https://www.rfc-editor.org/authors/rfc9331.txt
>>>>  https://www.rfc-editor.org/authors/rfc9331.pdf
>>>>  https://www.rfc-editor.org/authors/rfc9331.html
>>>> 
>>>> This diff file shows all changes made during AUTH48:
>>>>  https://www.rfc-editor.org/authors/rfc9331-auth48diff.html
>>>> 
>>>> This diff file shows all changes made to date:
>>>>  https://www.rfc-editor.org/authors/rfc9331-diff.html
>>>> 
>>>> Note that it may be necessary for you to refresh your browser to view the most recent version. Please review the document carefully to ensure satisfaction as we do not make changes once it has been published as an RFC.
>>>> 
>>>> Please contact us with any further updates or with your approval of the document in its current form.  We will await approvals from each author prior to moving forward in the publication process.
>>>> 
>>>> For the AUTH48 status of this document, please see:
>>>>  https://www.rfc-editor.org/auth48/rfc9331
>>>> 
>>>> Thank you,
>>>> 
>>>> RFC Editor/kc
>>>> 
>>>> 
>>>>> On Nov 25, 2022, at 10:18 AM, Bob Briscoe <[e-mail]> wrote:
>>>>> 
>>>>> 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 on
>>>>>> https://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 Briscoe
>>>>> http://bobbriscoe.net/
>>>>> <rfc9331c.xml><rfc9331c-DIFF-a.html><rfc9331b-DIFF-a.html><rfc9331c-DIFF-b.html><rfc9331c-DIFF-draft-ietf-tsvwg-ecn-l4s-id-29.html>
>>> -- 
>>> ________________________________________________________________
>>> Bob Briscoe                               http://bobbriscoe.net/
>>> <rfc9331e.xml><rfc9331e-from-d.diff.html><rfc9331e-from-draft-ietf-tsvwg-ecn-l4s-id-29.diff.html>
> 
> -- 
> ________________________________________________________________
> Bob Briscoe                               http://bobbriscoe.net/
> <rfc9331g.xml><rfc9331g-from-f.diff.html>