Re: [auth48] [AD] [C350] AUTH48: RFC-to-be 9330 <draft-ietf-tsvwg-l4s-arch-20> for your review

[Alice Russo <[e-mail]>]

Bob, Martin,

* Martin (as AD), please review and let us know if you approve the changes shown in the files below (and described by Bob below). This diff file (https://www.rfc-editor.org/authors/rfc9330-lastrfcdiff.html) shows the recent changes, including in S6.4.5 the addition of the term "standards-compliant".

Bob,
Thank you for sending the revised XML. The updated files are here (please refresh):
  https://www.rfc-editor.org/authors/rfc9330.html
  https://www.rfc-editor.org/authors/rfc9330.txt
  https://www.rfc-editor.org/authors/rfc9330.pdf
  https://www.rfc-editor.org/authors/rfc9330.xml

This diff file shows all changes from the approved I-D:
  https://www.rfc-editor.org/authors/rfc9330-diff.html
  https://www.rfc-editor.org/authors/rfc9330-rfcdiff.html (side by side)

This diff file shows the changes made during AUTH48 thus far:
  https://www.rfc-editor.org/authors/rfc9330-auth48diff.html

This diff file shows only the changes since the last posted version:
  https://www.rfc-editor.org/authors/rfc9330-lastrfcdiff.html

Re:
> There is also an unbalanced parenthesis in the title of RFC8034 in the RFC XML Bibliography:
> https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8034.xml
> It has not yet caused any lasting problems, because the title of the RFC itself is correct, and it is not currently referenced by any other RFCs.

Thank you for bringing this to our attention. This missing parenthesis is not present on the RFC itself; it was an error in the metadata. This has been corrected, and the correction will soon be propagated to the bib.ietf.org file.

We will wait to hear from you again and from your coauthors
before continuing the publication process. This page shows 
the AUTH48 status of your document:
  https://www.rfc-editor.org/auth48/rfc9330

Thank you.
RFC Editor/ar

> On Nov 3, 2022, at 5:45 PM, Bob Briscoe <[e-mail]> wrote:
> 
> Alice, Martin,
> 
> I've attached the XML of the new edits I promised below, to correct technically misleading statements that the co-authors found during our final read-throughs.
> I guess Martin will need to approve all these.
> 
> Sorry about these further edits, but this draft was first written 7 years ago, and when reading text that we've all read so many times before, it's so easy to miss where it's become inconsistent with changes to the other L4S drafts. I've provided rationale for some of the changes below. Others should be obvious from the diff wrt your previous draft (att'd).
> 
> Ist para of Intro:
> Made list of use cases more consistent with those in the use cases section, and added Wi-Fi, which had been omitted from both.
> 
> CURRENT:
>    Queuing in access
>    network bottlenecks is typically configured to cause overall network
>    delay to roughly double during a long-running flow, relative to
>    expected base (unloaded) path delay [BufferSize].
> PROPOSED:
>    A Classic AQM in an
>    access network bottleneck is typically configured to buffer the
>    sawteeth of lone flows, which can cause peak overall network delay to
>    roughly double during a long-running flow, relative to expected base
>    (unloaded) path delay [BufferSize].
> 
> Rationale:
> It wasn't clear that this was referring to AQM, not tail drop. And we added precision to the technical scenario description (lone flow and peak delay).
> 
> 
> CURRENT:
>        To protect against unresponsive traffic taking advantage of the
>        prioritization of the L4S queue and starving the Classic queue,
>        it is advisable for the priority to be conditional,
> PROPOSED:
>        To protect against the prioritization of persistent L4S traffic 
>        deadlocking the Classic queue for a while in some implementations,
>        it is advisable for the priority to be conditional,
> Ratonale:
> The reason for needing conditional priority had been changed in the DualQ draft in the past year, given better understanding through experimentation. This edit makes l4s-arch consistent.
> See https://datatracker.ietf.org/doc/html/draft-ietf-tsvwg-aqm-dualq-coupled-25#section-4.2.2
> 
> CURRENT:
>        Then, both queues introduce the same
>        intensity of drop (not shown in the figure).
> PROPOSED:
>        The trade-offs with different
>        approaches are discussed in Section 4.2.3 of the DualQ spec
>        [RFCYYY1] (none are shown in the figure here).
> 
> Rationale: The same drop in both queues is only one approach. Since this was written in l4s-arch, others have been proposed, and written up in DualQ draft.
> 
> 6.4. Deployment Considerations
> CURRENT  : 
>     L4S involves both end systems and the network
> PROPOSED: 
>     L4S involves both the network and end systems
> Rationale: It wasn't intended to necessarily mean both the end-systems at this point.
> 
> in the references in  l4s-arch, we noticed new proposed titles with expanded abbreviations for the other two L4S drafts. This creates some redundancy, that we've proposed to remove below:
> 
> CURRENT:
>     Explicit Congestion Notification (ECN) Protocol for Very Low Queuing Delay (L4S)
> PROPOSED BY RFC-EDITOR:
>     Explicit Congestion Notification (ECN) Protocol for Very Low Queuing Delay (Low Latency, Low Loss, and Scalable Throughput (L4S))
> PROPOSED BY CO-AUTHORS:
>     Explicit Congestion Notification (ECN) Protocol for Low Latency, Low Loss, and Scalable Throughput (L4S)
> 
> CURRENT:
> DualQ Coupled AQMs for Low Latency, Low Loss and Scalable Throughput (L4S)
> PROPOSED BY RFC-EDITOR:
> Dual Queue (DualQ) Coupled Active Queue Management (AQM) for Low Latency, Low Loss, and Scalable Throughput (L4S)/
> PROPOSED BY CO-AUTHORS:
> Dual Queue Coupled Active Queue Management (AQM) Algorithms for Low Latency, Low Loss, and Scalable Throughput (L4S)
> 
> There is also an unbalanced parenthesis in the title of RFC8034 in the RFC XML Bibliography:
> https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8034.xml
> It has not yet caused any lasting problems, because the title of the RFC itself is correct, and it is not currently referenced by any other RFCs.
> 
> 
> Regards
> 
> 
> Bob, on behalf of the co-authors.
> 
> 
> On 02/11/2022 23:37, Bob Briscoe wrote:
>> @Greg & @Alice, See [BB2] inline re. Ⓡ
>> 
>> But first, @Alice,
>> 
>> Thank you for the latest updates.
>> In parallel to your edits, my co-authors and I have been doing a final read through. We found some technically misleading statements. I had prepared edits based on Alanna's last XML. But now you've sent an update, I'll rebase from that instead... and check it at the same time - mañana now.
>> 
>> 
>> On 02/11/2022 21:32, Alice Russo wrote:
>>> Bob, Martin (as AD),
>>> 
>>> *Martin, please review and let us know if you approve the change in Section 5.2.
>>> Specifically:
>>> Original:
>>>       In particular, because networks tend not to trust end systems to
>>>       identify which packets should be favoured over others, where
>>>       networks assign packets to Diffserv classes they tend to use
>>>       packet inspection of application flow identifiers or deeper
>>>       inspection of application signatures. 
>>> 
>>> Current:
>>>       In particular, networks often use packet inspection of application
>>>       flow identifiers or deeper inspection of application signatures to
>>>       assign packets to Diffserv classes, because they tend not to trust
>>>       end systems to identify which packets should be favoured over
>>>       others.  
>>> 
>>> >From Bob:
>>> 
>>>> Reason: This is an explanation of why networks prefer to themselves assign packets to Diffserv classes, so restricting it to "where networks assign packets to Diffserv classes" was inappropriate.
>>>> 
>>> My apologies for the delayed reply. Thank you for sending the updated XML file.
>>> The revised files are here (please refresh):
>>>   
>>> https://www.rfc-editor.org/authors/rfc9330.html
>>> 
>>>   
>>> https://www.rfc-editor.org/authors/rfc9330.txt
>>> 
>>>   
>>> https://www.rfc-editor.org/authors/rfc9330.pdf
>>> 
>>>   
>>> https://www.rfc-editor.org/authors/rfc9330.xml
>>> 
>>> 
>>> This diff file shows all changes from the approved I-D:
>>>   
>>> https://www.rfc-editor.org/authors/rfc9330-diff.html
>>> 
>>>   
>>> https://www.rfc-editor.org/authors/rfc9330-rfcdiff.html
>>>  (side by side)
>>> 
>>> This diff file shows the changes made during AUTH48 thus far:
>>>   
>>> https://www.rfc-editor.org/authors/rfc9330-auth48diff.html
>>> 
>>> 
>>> This diff file shows only the changes since the last posted version:
>>>   
>>> https://www.rfc-editor.org/authors/rfc9330-lastrfcdiff.html
>>> 
>>> 
>>> 
>>> Re:
>>> 
>>>> [RFCYYY2] & [RFCYYY1]: I've presumed that the new expansion of L4S will be used in their titles and therefore their references.
>>>> 
>>> Yes; correct.
>>> 
>>> 
>>> Re:
>>> 
>>>> DOCSIS(R) not DOCSIS(r) isn't it?
>>>> BTW, I originally used '&reg;' in the XML, but I presume it was removed for a good reason (?).
>>>> 
>>> That's fine. We had relied on the citation library, which uses "(r)" (https://datatracker.ietf.org/doc/bibxml3/reference.I-D.briscoe-docsis-q-protection.xml
>>> ).
>>> Regarding the title of draft-briscoe-docsis-q-protection, we note that "DOCSIS" has appeared in the titles of several RFCs without the ® symbol. We note _The Chicago Manual of Style_ (8.153 Trademarks) states these symbols should be left out:
>>> "Although the symbols ® and ™ (for registered and unregistered trademarks, respectively) often accompany trademark names on product packaging and in promotional material, there is no legal requirement to use these symbols, and they should be omitted wherever possible."
>>> 
>> 
>> [BB2] When the ISE was consulting with the CableLabs Counsel about how to assign copyright of pseudocode and text in that draft that was copied from a DOCSIS spec., the Counsel also explained that CableLabs asks that Ⓡ is suffixed to 'DOCSIS' on first use. The ISE interpreted 'first use' as 'in the title'. If it is taken out, I guess my co-author, Greg White, from CableLabs will have to approve it. I would add that there is an entry in the Terminology section of that draft that says:
>>    DOCSIS:  Data Over Cable System Interface Specification.  "DOCSIS" is
>>       a registered trademark of Cable Television Laboratories, Inc.
>>       ("CableLabs").
>> 
>> 
>> 
>> Bob
>> 
>> 
>>> Re:
>>> 
>>>> 'over specified'
>>>> This still seems wrong to me (and others I've consulted with). Could you pls provide rationale for this and why it should not be 'over-specified'? 
>>>> 
>>> Agree; reverted to "over-specified".
>>> 
>>> We will wait to hear from you again and from your coauthors
>>> before continuing the publication process. This page shows 
>>> the AUTH48 status of your document:
>>>   
>>> https://www.rfc-editor.org/auth48/rfc9330
>>> 
>>> 
>>> Thank you.
>>> RFC Editor/ar
>>> 
>>> 
>>>> On Oct 28, 2022, at 5:35 AM, Bob Briscoe <[e-mail]>
>>>>  wrote:
>>>> 
>>>> Alanna,
>>>> 
>>>> Assuming my most recent changes (in the attached XML) are uncontroversial, I believe there is just one outstanding disagreement ('over specify', which I have left for you to change if you agree with me).
>>>> I've also attached two diffs: i) wrt your last XML and ii) wrt the previously submitted draft-20.
>>>> 
>>>> Pls see [BB] inline for numerous responses.
>>>> 
>>>> On 26/10/2022 00:28, Alanna Paloma wrote:
>>>> 
>>>>> Hi Bob,
>>>>> 
>>>>> 
>>>>> 
>>>>>> 1) US-English Punctuation
>>>>>> 
>>>>>> As well as all my errors that you have found (for which many thanks), I notice some alterations that I would categorize as translations into US English punctuation.
>>>>>> I've let them all pass where the US English is at least not incorrect in British English. However, the following (a-d) are definitely incorrect in British English:
>>>>>> 
>>>>>> 
>>>>> We have not made these updates.  While the RFCs may use British spelling (when it’s used consistently), we generally follow the RFC Style Guide and Chicago Manual of Style.  
>>>>> 
>>>> [BB] I won't pursue this any further. You've reverted to semi-colons where it had become ambiguous, which was my main concern. And you've balanced commas around qualifying clauses, which makes me happier. Serial commas and commas after 'e.g.' or 'i.e.' still create internal inconsistency with the British spellings, thus making it look like I don't know how to punctuate British English properly (given my name is on this as editor). However, from discussing offline, I've discovered that the preference for punctuation consistency across RFCs over internal consistency is a fairly recent change of policy. No matter how controversial, I understand that this isn't the place to fight the RFC Editor's style policy. 
>>>> 
>>>> 
>>>>> For our understanding, what British style manual are you using? 
>>>>> 
>>>> [BB] As I said, I intended not to question any edits that are merely questions of style. I only raised points that I believe are universally considered incorrect in British English whatever the style (or at least near-universally). 
>>>> 
>>>> I have read Fowler's Modern English Usage, so I guess one could say I follow that. Plus I check StackExchange for latest advice and trends. Nonetheless, Fowler himself preferred the serial comma but recognized that he was out on a limb, admitting that "many other [British] publishers" omit it. AFAIK, the OUP is the only major British publisher that requires it, which is why Brits call it the Oxford comma.
>>>> 
>>>> 
>>>>>> 2) Expansions of Abbreviations
>>>>>> 
>>>>>> The editor has expanded protocol abbreviations on first use as a universal rule. However, I would argue that each case has to be treated on its merits, rather than applying a universal style rule.
>>>>>> 
>>>>>> 
>>>>> We have reverted these expansions. Note that we have added corresponding references at the first occurrences of “SCTP” and “DCCP” (RFC 4960 and 4340, respectively).
>>>>> 
>>>> [BB] Thank you. Adding citations is a useful compromise.
>>>> Nonetheless, it looks odd to have citations for only these two but not TCP and QUIC. So I have added citations for them too (they were already cited, so they're not new refs).
>>>> 
>>>> 
>>>>>> 3) XML coding
>>>>>> 
>>>>>> Shouldn't '--' be replaced with &ndash; in the XML, which would produce '--' in the txt but a correct n-width dash in the HTML and PDF?
>>>>>> (I had inconsistently used &mdash; or a single hyphen, but it's fine to instead use n-dashes consistently)
>>>>>> 
>>>>>> 
>>>>> RFCs use the character HYPHEN-MINUS (decimal 45; U+002D). They do not use en dash (U+2013) or em dash (U+2014). In general, non-ASCII characters are not used for punctuation.
>>>>> 
>>>> [BB] Understood. Fair enough.
>>>> 
>>>> 
>>>>> Additionally, to improve clarity, may we update this sentence in Section 1.1 as follows?
>>>>> 
>>>>> Current:
>>>>>   Having described the architecture, Section 6 clarifies its
>>>>>   applicability, that is, the applications and use cases that motivated
>>>>>   the design, the challenges applying the architecture to various link
>>>>>   technologies, and various incremental deployment models, including
>>>>>   the two main deployment topologies, different sequences for
>>>>>   incremental deployment, and various interactions with preexisting
>>>>>   approaches.  
>>>>> 
>>>>> Perhaps:
>>>>>   After the architecture has been described, Section 6 clarifies its 
>>>>>   applicability by describing the applications and use cases that motivated 
>>>>>   the design, the challenges applying the architecture to various link 
>>>>>   technologies, and various incremental deployment models (including
>>>>>   the two main deployment topologies, different sequences for
>>>>>   incremental deployment, and various interactions with preexisting 
>>>>>   approaches).
>>>>> 
>>>>> 
>>>> [BB] Yes, that's better. I've included it in the XML for you.
>>>> 
>>>> 
>>>>> ...
>>>>> The files have been posted here (please refresh):
>>>>>  
>>>>> 
>>>>> https://www.rfc-editor.org/authors/rfc9330.txt
>>>>> 
>>>>> 
>>>>>  
>>>>> 
>>>>> https://www.rfc-editor.org/authors/rfc9330.pdf
>>>>> 
>>>>> 
>>>>>  
>>>>> 
>>>>> https://www.rfc-editor.org/authors/rfc9330.html
>>>>> 
>>>>> 
>>>>>  
>>>>> 
>>>>> https://www.rfc-editor.org/authors/rfc9330.xml
>>>>> 
>>>>> 
>>>>> 
>>>>> The relevant diff files are posted here:
>>>>>  
>>>>> 
>>>>> https://www.rfc-editor.org/authors/rfc9330-diff.html
>>>>> 
>>>>>  (comprehensive diff)
>>>>>  
>>>>> 
>>>>> https://www.rfc-editor.org/authors/rfc9330-auth48diff.html
>>>>> 
>>>>>  (all AUTH48 changes)
>>>>>  
>>>>> 
>>>>> https://www.rfc-editor.org/authors/rfc9330-lastdiff.html
>>>>> 
>>>>>  (htmlwdiff diff between last version and this)
>>>>>  
>>>>> 
>>>>> https://www.rfc-editor.org/authors/rfc9330-lastrfcdiff.html
>>>>>  (rfcdiff between last version and this)
>>>>> 
>>>> [BB] On reading the diff over again, I've made a few minor editorial changes that you will see in my new XML and new diff (attached). I've highlighted one or two below that require some explanation.
>>>> 
>>>> Abstract: 
>>>> CURRENT:
>>>>     ...transition away from congestion control algorithms that cause 
>>>>     substantial queuing delay to a new class of congestion controls...
>>>> PROPOSED:
>>>>     ...transition away from congestion control algorithms that cause 
>>>>     substantial queuing delay and instead adopt a new class of congestion controls...
>>>> Reason: 
>>>> The reader could otherwise easily start misreading it as "...cause queuing delay to a new class of congestion controls..." then stumble when the end of the sentence becomes incompatible
>>>> 
>>>> I've capitalized the 2nd occurrence of Accurate ECN, which I think is better, even though I argued against the first one.
>>>> * 1st occurrence: more accurate ECN feedback for TCP (AccECN)
>>>> * 2nd occurrence: For TCP transports, Accurate ECN (AccECN) feedback
>>>> Reasoning: with the TCP part at the start, the abbreviation for the whole concept (including its applicability solely to TCP) can be     written directly after the two words that form the abbreviation.
>>>> But, pls feel free to alter if you think fit.
>>>> 
>>>> CURRENT:
>>>>     a flow of non-ECN or ECT(0) packets
>>>> 
>>>> PROPOSED:
>>>>     a flow of Not-ECT or ECT(0) packets
>>>> REASONING: One more occurrence where it refers to the codepoint.
>>>> 
>>>> CURRENT (which was my newly proposed text but, on reflection, it was still not right):
>>>>       In particular, where networks assign packets to Diffserv classes,
>>>>       they tend to use packet inspection of application flow identifiers
>>>>       or deeper inspection of application signatures, because networks
>>>>       tend not to trust end systems to identify which packets should be
>>>>       favoured over others.
>>>> 
>>>> PROPOSED
>>>>       In particular, networks often use packet inspection of application flow 
>>>>       identifiers or deeper inspection of application signatures to assign 
>>>>       packets to Diffserv classes, because they tend not to trust end 
>>>>       systems to identify which packets should be favoured over others.
>>>> 
>>>> Reason: This is an explanation of why networks prefer to themselves assign packets to Diffserv classes, so restricting it to "where networks assign packets to Diffserv classes" was inappropriate.
>>>> 
>>>> 'over specified'
>>>> This still seems wrong to me (and others I've consulted with). Could you pls provide rationale for this and why it should not be 'over-specified'? 
>>>> I've left it for you to change if you agree with me.
>>>> 
>>>> Here's the my comment about this that I've now removed from the XML:
>>>>        <!-- [BB] 'Over specified' as 2 separate words looks like 'over' is a 
>>>>              preposition, which seems very wrong. However, I can't find 
>>>>              'overspecify' or 'over-specify' in a formal dictionary. Nonetheless, 
>>>>              surely it is a well-understood frequently invented compound, much as 
>>>>              'over-thank' or 'over-freeze' would be, even though they are not 
>>>>              dictionary words either. So, as such, wouldn't it either be written 
>>>>              hyphenated or as one word, never as two?
>>>>              
>>>> https://en.wiktionary.org/wiki/overspecify
>>>> 
>>>>              
>>>> https://www.yourdictionary.com/overspecify
>>>> 
>>>>              
>>>>              STATUS: PENDING editor decision (strongly prefer to revert please).
>>>>         -->
>>>> 
>>>> [RFCYYY2] & [RFCYYY1]: I've presumed that the new expansion of L4S will be used in their titles and therefore their references.
>>>> 
>>>> DOCSIS(R) not DOCSIS(r) isn't it?
>>>> BTW, I originally used '&reg;' in the XML, but I presume it was removed for a good reason (?).
>>>> 
>>>> CURRENT:
>>>>     random acts of kindness might occur.
>>>> PROPOSED:
>>>>     random acts of kindness might arise.
>>>> Reason: For this newly added ending, I felt (IMO) 'arise' is a slightly more fitting choice of word.
>>>> 
>>>> I also removed the remaining [rfced] and [BB] comments from the XML.
>>>> 
>>>> Regards
>>>> 
>>>> 
>>>> Bob
>>>> 
>>>> 
>>>>> Please see the AUTH48 status page for this document here:
>>>>>   
>>>>> 
>>>>> https://www.rfc-editor.org/auth48/rfc9330
>>>>> 
>>>>> 
>>>>> 
>>>>> Best regards,
>>>>> RFC Editor/ap
>>>>> 
>>>>> 
>>>>> 
>>>>>> On Oct 21, 2022, at 7:56 AM, Bob Briscoe <[e-mail]>
>>>>>> 
>>>>>>  wrote:
>>>>>> 
>>>>>> Alanna,
>>>>>> 
>>>>>> Thank you for finding all my errors, and apologies for the delay replying. 
>>>>>> 
>>>>>> I have written all my responses to your '[rfced]' comments within the XML (except one inline below, which was invalid within an XML comment).
>>>>>> Where necessary, I have tried to fix any new problems within the XML source directly, and added a comment tagged '[BB]' explaining my reasoning.
>>>>>> I have also attached a side-by-side diff wrt the latest RFC9330 XML that you sent me, just FYI.
>>>>>> 
>>>>>> In general, I have avoided reverting changes I disagree with, preferring to ask you to revert them (in case you have a good reason not to). But where I was sure of myself, I have reverted some, and explained my reasoning in a comment.
>>>>>> I have ended each comment with one of the following status lines, to make it clear what I am expecting to be done:
>>>>>> 
>>>>>> 03: STATUS: no further action required.
>>>>>> 38: STATUS: if agreeable to editor, no further action required.
>>>>>> 12: STATUS: PENDING editor decision.
>>>>>> 01: STATUS: PENDING editor suggestion. 
>>>>>> 01: STATUS: PENDING editor check of corrected reference.
>>>>>> 02: STATUS: PENDING re-check by the editor.
>>>>>> =======
>>>>>> 57: Total
>>>>>> 
>>>>>> Multiple Occurrences
>>>>>> 
>>>>>> There follow comments that apply to multiple occurrences, which I have left for you to action. 
>>>>>> 
>>>>>> 1) US-English Punctuation
>>>>>> 
>>>>>> As well as all my errors that you have found (for which many thanks), I notice some alterations that I would categorize as translations into US English punctuation.
>>>>>> I've let them all pass where the US English is at least not incorrect in British English. However, the following (a-d) are definitely incorrect in British English:
>>>>>> 
>>>>>> 1a) The use of the "Oxford comma" is consistent with US English, but not British English (whether Oxford variant spelling or not).
>>>>>> By Oxford comma, I mean a comma before the last element of a list, e.g. 
>>>>>>     home, small enterprise, or mobile
>>>>>> whereas in British English this is considered incorrect, not just unusual, and the correct form is
>>>>>>     home, small enterprise or mobile
>>>>>> 
>>>>>> I would appreciate the following cases being reverted back to British English:
>>>>>> 	• ...home, small enterprise, or mobile
>>>>>> 	• ...cloud-based applications, and video-assisted remote control of machinery and industrial processes
>>>>>> 	• ...low latency, low loss, and scalable Internet service.
>>>>>> 	• Last para of §1.1 Document Road Map (2 occurrences)
>>>>>> 	• ...[BBR-CON-CTRL], and the L4S variant of SCReAM
>>>>>> 	• ...'packet', and 'flow'.
>>>>>> 	• ...enterprise, or campus
>>>>>> 	• ...'burst policing', or 'queue protection'
>>>>>> 	• ...new service, product, and application opportunities.
>>>>>> 	• ...(adaptive) video streaming, and...
>>>>>> 	• ...senders, receivers, and networks
>>>>>> 	• ...real-time (RTP, RMCAT), and
>>>>>> 	• ...line of sight wireless, or satellite
>>>>>> 	• ...due to electrical interference, and...
>>>>>> 	• ...households, businesses, or mobile users
>>>>>> 	• ...receiver, sender, or network
>>>>>> 	• ...applicability, pros, and cons
>>>>>> 	• ...Pete Heist, and Martin Duke
>>>>>> 	• ...Roman Danyliw, and Éric Vyncke
>>>>>> 
>>>>>> 1b) Commas have been added after 'e.g.' and 'i.e.' This is inconsistent with the British English spelling and grammar of the rest of the document, only being correct in US English.
>>>>>> 
>>>>>> 
>>>>>> https://english.stackexchange.com/questions/16172/should-i-always-use-a-comma-after-e-g-or-i-e
>>>>>> 
>>>>>> 
>>>>>> 
>>>>>> 1c) I used semicolons to divide up lists of phrases, some of which include a comma within the phrase. These semicolons have been converted to commas, which is perhaps a US-english tendency, whereas I believe that the semi-colon is used less sparingly in British English. The result is less comprehensible, whether for US or British English readers. So I would have thought it best to have left well alone in these cases.
>>>>>> 
>>>>>> 1d) I notice a number of constructions with a qualifying clause for a particular case like this  "yada yada yada, but in particular case X, bippety bippety boo."
>>>>>> In British English this would always be punctuated as "yada yada yada but, in particular case X, bippety bippety boo."
>>>>>> 
>>>>>> 2) Expansions of Abbreviations
>>>>>> 
>>>>>> The editor has expanded protocol abbreviations on first use as a universal rule. However, I would argue that each case has to be treated on its merits, rather than applying a universal style rule.
>>>>>> Such expansions can make a sentence impenetrable. So, where the protocols are generally known by their abbreviation, especially where they are only mentioned in passing as examples, expansion is counterproductive. Also, where a citation is given for a well-known abbreviation, those (unusual) readers who don't recognize the abbreviation can resort to looking up the expansion in the references section.
>>>>>> 3) XML coding
>>>>>> 
>>>>>> Shouldn't '--' be replaced with &ndash; in the XML, which would produce '--' in the txt but a correct n-width dash in the HTML and PDF?
>>>>>> (I had inconsistently used &mdash; or a single hyphen, but it's fine to instead use n-dashes consistently)
>>>>>> 
>>>>>> Pls also see one response to Q15a) tagged [BB] inline.
>>>>>> 
>>>>>> On 20/10/2022 22:36, Alanna Paloma wrote:
>>>>>> 
>>>>>> 
>>>>>>> Authors,
>>>>>>> 
>>>>>>> Please note that the following queries remain unanswered. They can also be viewed in the XML file. 
>>>>>>> 
>>>>>>> 2) <!-- [rfced] Please insert any keywords (beyond those that appear in the
>>>>>>> title) for use on 
>>>>>>> 
>>>>>>> 
>>>>>>> https://www.rfc-editor.org/search
>>>>>>> 
>>>>>>> 
>>>>>>> . -->
>>>>>>> 
>>>>>>> 
>>>>>>> 3) <!--[rfced] We see "L4S" expanded in various ways within this document
>>>>>>> and related documents. Please let us know what the preferred expansion
>>>>>>> is, and we will update this document (title, abstract, and so forth)
>>>>>>> to use that expansion.
>>>>>>> 
>>>>>>> A)  Low Latency, Low Loss, Scalable Throughput (L4S) (original title)
>>>>>>> B)  Low queuing Latency, Low Loss, and Scalable throughput (L4S) (original abstract)
>>>>>>> C)  Low-Latency, Low-Loss Scalable throughput (L4S) (Terminology section and [ECN-L4S])
>>>>>>> D)  low latency, low loss and scalable throughput (L4S) [ECN-L4S]
>>>>>>> E)  Low Latency, Low Loss, Scalable throughput (L4S) [ECN-L4S]  
>>>>>>> 
>>>>>>> In references: 
>>>>>>>    Low Latency Low Loss Scalable throughput (L4S) (RFC 8311) 
>>>>>>>    Low Loss, Low Latency for Scalable throughput (L4S) (RFC 8298)
>>>>>>>    Low Latency, Low Loss and Scalable (L4S) [DualPI2Linux]
>>>>>>> -->
>>>>>>> 
>>>>>>> 
>>>>>>> 4) <!--[rfced] May the first sentence of the abstract be updated 
>>>>>>> to use the expansion selected for the first instance of "L4S"?
>>>>>>> 
>>>>>>> Original:
>>>>>>>   This document describes the L4S architecture, which enables Internet
>>>>>>>   applications to achieve Low queuing Latency, Low Loss, and Scalable
>>>>>>>   throughput (L4S). 
>>>>>>> 
>>>>>>> Perhaps (depending on your answer to the preceding question):
>>>>>>>   This document describes the Low-Latency, Low-Loss Scalable throughput 
>>>>>>>   (L4S) architecture, which enables Internet applications to achieve 
>>>>>>>   those goals.
>>>>>>> -->
>>>>>>> 
>>>>>>> 
>>>>>>> 5) <!--[rfced] We see a number of author-inserted comments in the XML file for
>>>>>>> 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.
>>>>>>> -->
>>>>>>> 
>>>>>>> 
>>>>>>> 6) <!--[rfced] Should "not-ECT" be updated to "non-ECT" (3 instances)?
>>>>>>> 
>>>>>>> Original:
>>>>>>>   In addition, ECT(0) and not-
>>>>>>>   ECT packets could potentially be classified into a separate flow-
>>>>>>>   queue from ECT(1) and CE packets to avoid them mixing if they
>>>>>>>   share a common flow-identifier (e.g. in a VPN).
>>>>>>>   ...    
>>>>>>>   If they already treat ECN traffic as Not-ECT,
>>>>>>>   they can merely treat L4S traffic as Not-ECT too.
>>>>>>> -->   
>>>>>>> 
>>>>>>> 
>>>>>>> 7) <!--[rfced] Note that we have expanded "NIC" as "Network Interface Centre".
>>>>>>> Please review.
>>>>>>> 
>>>>>>> Original:
>>>>>>>   For example,
>>>>>>>   some data-centre networks are designed with the bottleneck in the
>>>>>>>   hypervisor or host NICs, while others bottleneck at the top-of-rack
>>>>>>>   switch (both the output ports facing hosts and those facing the
>>>>>>>   core).
>>>>>>> 
>>>>>>> Currently:
>>>>>>>   For example,
>>>>>>>   some data-centre networks are designed with the bottleneck in the
>>>>>>>   hypervisor or host Network Interface Centres (NICs), while others
>>>>>>>   bottleneck at the top-of-rack switch (both the output ports facing
>>>>>>>   hosts and those facing the core).
>>>>>>> 
>>>>>>> Related note:
>>>>>>> As per the mail from Bob Briscoe on 2022-09-12, British English spelling 
>>>>>>> has been selected. "(Oxford variant with -ize, -ization but -yse)"
>>>>>>> -->   
>>>>>>> 
>>>>>>> 
>>>>>>> 8) <!--[rfced] We note that "flow ID" (2 instances) and "flow identifier" (4 instances) 
>>>>>>> are both used in this document. For consistency, may we expand "flow ID" 
>>>>>>> to "flow identifier", or should it be expanded as something else, e.g., 
>>>>>>> "flow identification"?
>>>>>>> 
>>>>>>> Original:
>>>>>>>   However, per-flow rate control is not
>>>>>>>   usually deployed as a security mechanism, because an active attacker
>>>>>>>   can just shard its traffic over more flow IDs if the rate of each is
>>>>>>>   restricted.
>>>>>>>   ...
>>>>>>>   For instance, L4S support has been added to FQ-CoDel, which classifies
>>>>>>>   by application flow ID in the network.
>>>>>>> -->
>>>>>>> 
>>>>>>> 
>>>>>>> 9) <!--[rfced] May we update "not-registered" to "unregistered" in the 
>>>>>>> sentence below?
>>>>>>> 
>>>>>>> Original:
>>>>>>>   Such local arrangements
>>>>>>>   would only require simple registered/not-registered packet
>>>>>>>   classification, rather than the managed, application-specific traffic
>>>>>>>   policing against customer-specific traffic contracts that Diffserv
>>>>>>>   uses.
>>>>>>> 
>>>>>>> Perhaps:
>>>>>>>   Such local arrangements
>>>>>>>   would only require simple registered/unregistered packet
>>>>>>>   classification, rather than the managed, application-specific traffic
>>>>>>>   policing against customer-specific traffic contracts that Diffserv
>>>>>>>   uses.
>>>>>>> -->   
>>>>>>> 
>>>>>>> 
>>>>>>> 10) <!--[rfced] In the sentence below, does "self-restraint" limit the rate?
>>>>>>> For clarity, may we update this sentence as suggested?
>>>>>>> 
>>>>>>> Original:
>>>>>>>   Like the Classic service, the L4S service relies on self-restraint -
>>>>>>>   limiting rate in response to congestion.
>>>>>>> 
>>>>>>> Perhaps:
>>>>>>>   Like the Classic service, the L4S service relies on self-restraint to 
>>>>>>>   limit the rate in response to congestion.
>>>>>>> -->   
>>>>>>> 
>>>>>>> 
>>>>>>> 11) <!--[rfced] Regarding the short name for the reference draft-ietf-tsvwg-ecn-l4s-id,
>>>>>>> we note that RFC 8311 cited it as [ENC-L4S], and we have used the same 
>>>>>>> citation in this document. However, in text you refer to it as 
>>>>>>> "the L4S ECN spec". So, would you like us to change the citation to [L4S-ECN]
>>>>>>> accordingly? For example:
>>>>>>> 
>>>>>>> Current:  the L4S ECN spec [ECN-L4S]
>>>>>>> Perhaps:  the L4S ECN spec [L4S-ECN]
>>>>>>> -->
>>>>>>> 
>>>>>>> 
>>>>>>> 12) <!-- [rfced] We see an "October 2021" version of this document at the URL
>>>>>>> provided. Would you like the cite "October 2021" rather than "July 2021"?
>>>>>>> 
>>>>>>> Original:
>>>>>>>   [BDPdata]  Briscoe, B., "PI2 Parameters", Technical Report TR-BB-
>>>>>>>              2021-001 arXiv:2107.01003 [cs.NI], July 2021,
>>>>>>>              
>>>>>>> 
>>>>>>> 
>>>>>>> <https://arxiv.org/abs/2107.01003>
>>>>>>> 
>>>>>>> 
>>>>>>> .
>>>>>>> -->
>>>>>>> 
>>>>>>> 
>>>>>>> 13) <!-- [rfced] FYI, we have updated this reference as follows
>>>>>>> in keeping with the guidance on citing public code repositories
>>>>>>> in the "Web Portion of the Style Guide", specifically
>>>>>>> 
>>>>>>> 
>>>>>>> 
>>>>>>> <https://www.rfc-editor.org/styleguide/part2/#ref_repo>
>>>>>>> 
>>>>>>> 
>>>>>>> .
>>>>>>> 
>>>>>>> For this reference, it seems the intent is to cite the specific
>>>>>>> commit rather than the repository as a whole. (Because there doesn't
>>>>>>> seem to be a search by commit, we have left the commit-specific URL.)
>>>>>>> 
>>>>>>> Original:                 
>>>>>>>   [FQ_CoDel_Thresh]
>>>>>>>              Høiland-Jørgensen, T., "fq_codel: generalise ce_threshold
>>>>>>>              marking for subset of traffic", Linux Patch Commit ID:
>>>>>>>              dfcb63ce1de6b10b, 20 October 2021,
>>>>>>>              
>>>>>>> 
>>>>>>> 
>>>>>>> <https://git.kernel.org/pub/scm/linux/kernel/git/netdev/
>>>>>>>              net-next.git/commit/?id=dfcb63ce1de6b10b>
>>>>>>> 
>>>>>>> 
>>>>>>> .
>>>>>>> 
>>>>>>> Updated:                 
>>>>>>>   [FQ_CoDel_Thresh]
>>>>>>>              "fq_codel: generalise ce_threshold marking for subset of
>>>>>>>              traffic", commit dfcb63ce1de6b10ba98dee928f9463f37e5a5512,
>>>>>>>              October 2020,
>>>>>>>              
>>>>>>> 
>>>>>>> 
>>>>>>> <https://git.kernel.org/pub/scm/linux/kernel/git/netdev/
>>>>>>>              net-next.git/commit/?id=dfcb63ce1de6b10b>
>>>>>>> 
>>>>>>> 
>>>>>>> .
>>>>>>> -->
>>>>>>> 
>>>>>>> 
>>>>>>> 14) <!-- [rfced] This reference includes text that is not in English. Would it be
>>>>>>> helpful to readers to include a translation in parentheses? If so, please 
>>>>>>> provide that. 
>>>>>>> 
>>>>>>> Current: 
>>>>>>>   [Raaen14]  Raaen, K. and T-M. Grønli, "Latency Thresholds for
>>>>>>>              Usability in Games: A Survey", Norsk IKT-konferanse for
>>>>>>>              forskning og utdanning, 2014,
>>>>>>>              
>>>>>>> 
>>>>>>> 
>>>>>>> <http://ojs.bibsys.no/index.php/NIK/article/view/9/6>
>>>>>>> 
>>>>>>> 
>>>>>>> .
>>>>>>> -->
>>>>>>> 
>>>>>>> 
>>>>>>> 15) <!-- [rfced] Formatting
>>>>>>> 
>>>>>>> a) Regarding the format of Figure 3 ("Example L4S Deployment Sequence"), it
>>>>>>> remains in an artwork element as in the submitted XML file. It could be
>>>>>>> formatted as a table element, in which case, the three lines in all caps would
>>>>>>> each be in a separate row. Please let us know if you'd like us to change
>>>>>>> Figure 3 to a table.
>>>>>>> 
>>>>>>> 
>>>>>>> 
>>>>>> [BB] I gave all my responses within the XML, except I couldn't draw the tables below, because double hyphens are not allowed within XML comments.
>>>>>> They should be viewed with a fixed-width font.
>>>>>> 
>>>>>> I don't think it would be as comprehensible for the lines in all caps to be shown in separate rows. I tried some variants (below), but the current one is still the least worst.
>>>>>> So please leave it as-is, unless you can produce an example that looks better than all of the variants below.
>>>>>> Reasoning:
>>>>>> * The LESS PREFERRED#1 variant is perhaps even more clunky than the CURRENT version, and I suspect it wouldn't be easy to produce in XML anyway.
>>>>>> * The LESS PREFERRED#2 variant tends to confuse the eye into separating the capitalized line from the numbered row it belongs to.
>>>>>> 
>>>>>>      STATUS: PENDING RFC Editor decision.
>>>>>>  
>>>>>> CURRENT:
>>>>>>    +-+--------------------+----------------------+---------------------+
>>>>>>    | | Servers or proxies |      Access link     |             Clients |
>>>>>>    +-+--------------------+----------------------+---------------------+
>>>>>>    |0| DCTCP (existing)   |                      |    DCTCP (existing) |
>>>>>>    +-+--------------------+----------------------+---------------------+
>>>>>>    |1|                    |Add L4S AQM downstream|                     |
>>>>>>    | |       WORKS DOWNSTREAM FOR CONTROLLED DEPLOYMENTS/TRIALS        |
>>>>>>    +-+--------------------+----------------------+---------------------+
>>>>>>    |2| Upgrade DCTCP to   |                      |Replace DCTCP feedb'k|
>>>>>>    | | TCP Prague         |                      |         with AccECN |
>>>>>>    | |                 FULLY     WORKS     DOWNSTREAM                  |
>>>>>>    +-+--------------------+----------------------+---------------------+
>>>>>>    | |                    |                      |    Upgrade DCTCP to |
>>>>>>    |3|                    | Add L4S AQM upstream |          TCP Prague |
>>>>>>    | |                    |                      |                     |
>>>>>>    | |              FULLY WORKS UPSTREAM AND DOWNSTREAM                |
>>>>>>    +-+--------------------+----------------------+---------------------+
>>>>>> 
>>>>>> LESS PREFERRED#1:
>>>>>>    +-+--------------------+----------------------+---------------------+
>>>>>>    | | Servers or proxies |      Access link     |             Clients |
>>>>>>    +-+--------------------+----------------------+---------------------+
>>>>>>    |0| DCTCP (existing)   |                      |    DCTCP (existing) |
>>>>>>    +-+--------------------+----------------------+---------------------+
>>>>>>    |1|                    |Add L4S AQM downstream|                     |
>>>>>>    | |                                                                 |
>>>>>>    | |       WORKS DOWNSTREAM FOR CONTROLLED DEPLOYMENTS/TRIALS        |
>>>>>>    +-+--------------------+----------------------+---------------------+
>>>>>>    |2| Upgrade DCTCP to   |                      |Replace DCTCP feedb'k|
>>>>>>    | | TCP Prague         |                      |         with AccECN |
>>>>>>    | |                                                                 |
>>>>>>    | |                 FULLY     WORKS     DOWNSTREAM                  |
>>>>>>    +-+--------------------+----------------------+---------------------+
>>>>>>    | |                    |                      |    Upgrade DCTCP to |
>>>>>>    |3|                    | Add L4S AQM upstream |          TCP Prague |
>>>>>>    | |                                                                 |
>>>>>>    | |              FULLY WORKS UPSTREAM AND DOWNSTREAM                |
>>>>>>    +-+--------------------+----------------------+---------------------+
>>>>>> 
>>>>>> LESS PREFERRED#2:
>>>>>>    +-+--------------------+----------------------+---------------------+
>>>>>>    | | Servers or proxies |      Access link     |             Clients |
>>>>>>    +-+--------------------+----------------------+---------------------+
>>>>>>    |0| DCTCP (existing)   |                      |    DCTCP (existing) |
>>>>>>    +-+--------------------+----------------------+---------------------+
>>>>>>    |1|                    |Add L4S AQM downstream|                     |
>>>>>>    | +--------------------+----------------------+---------------------+
>>>>>>    | |       WORKS DOWNSTREAM FOR CONTROLLED DEPLOYMENTS/TRIALS        |
>>>>>>    +-+--------------------+----------------------+---------------------+
>>>>>>    |2| Upgrade DCTCP to   |                      |Replace DCTCP feedb'k|
>>>>>>    | | TCP Prague         |                      |         with AccECN |
>>>>>>    | +--------------------+----------------------+---------------------+
>>>>>>    | |                 FULLY     WORKS     DOWNSTREAM                  |
>>>>>>    +-+--------------------+----------------------+---------------------+
>>>>>>    | |                    |                      |    Upgrade DCTCP to |
>>>>>>    |3|                    | Add L4S AQM upstream |          TCP Prague |
>>>>>>    | +--------------------+----------------------+---------------------+
>>>>>>    | |              FULLY WORKS UPSTREAM AND DOWNSTREAM                |
>>>>>>    +-+--------------------+----------------------+---------------------+
>>>>>> 
>>>>>> 
>>>>>>  
>>>>>> 
>>>>>> 
>>>>>> 
>>>>>> 
>>>>>>> b) Please review the use of <em> in this document and let us know if any 
>>>>>>> updates are needed.  
>>>>>>> 
>>>>>>> c) 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
>>>>>>> 
>>>>>>> 
>>>>>>> ).  -->
>>>>>>> 
>>>>>>> 
>>>>>>> 16) <!-- [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.
>>>>>>> -->
>>>>>>> 
>>>>>>> 
>>>>>>> Thank you.
>>>>>>> 
>>>>>>> RFC Editor/ap
>>>>>>> 
>>>>>>> 
>>>>>>> 
>>>>>>> 
>>>>>>>> On Oct 20, 2022, at 1:58 PM, [e-mail]
>>>>>>>> 
>>>>>>>> 
>>>>>>>>  wrote:
>>>>>>>> 
>>>>>>>> NOTE: A new number has been assigned for this RFC-to-be.
>>>>>>>> 
>>>>>>>> (Previous mails used 9324; the number is now 9330.)
>>>>>>>> 
>>>>>>>> 
>>>>>>>> *****IMPORTANT*****
>>>>>>>> 
>>>>>>>> Updated 2022/10/20
>>>>>>>> 
>>>>>>>> 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/rfc9330.xml
>>>>>>>> 
>>>>>>>> 
>>>>>>>> 
>>>>>>>>   
>>>>>>>> 
>>>>>>>> 
>>>>>>>> https://www.rfc-editor.org/authors/rfc9330.html
>>>>>>>> 
>>>>>>>> 
>>>>>>>> 
>>>>>>>>   
>>>>>>>> 
>>>>>>>> 
>>>>>>>> https://www.rfc-editor.org/authors/rfc9330.pdf
>>>>>>>> 
>>>>>>>> 
>>>>>>>> 
>>>>>>>>   
>>>>>>>> 
>>>>>>>> 
>>>>>>>> https://www.rfc-editor.org/authors/rfc9330.txt
>>>>>>>> 
>>>>>>>> 
>>>>>>>> 
>>>>>>>> 
>>>>>>>> Diff file of the text:
>>>>>>>>   
>>>>>>>> 
>>>>>>>> 
>>>>>>>> https://www.rfc-editor.org/authors/rfc9330-diff.html
>>>>>>>> 
>>>>>>>> 
>>>>>>>> 
>>>>>>>>   
>>>>>>>> 
>>>>>>>> 
>>>>>>>> https://www.rfc-editor.org/authors/rfc9330-rfcdiff.html
>>>>>>>> 
>>>>>>>> 
>>>>>>>>  (side by side)
>>>>>>>> 
>>>>>>>> 
>>>>>>>> All changes since AUTH48 started:
>>>>>>>>   
>>>>>>>> 
>>>>>>>> 
>>>>>>>> https://www.rfc-editor.org/authors/rfc9330-auth48diff.html
>>>>>>>> 
>>>>>>>> 
>>>>>>>> 
>>>>>>>> 
>>>>>>>> Only the most recent changes (new RFC number assigned):
>>>>>>>>   
>>>>>>>> 
>>>>>>>> 
>>>>>>>> https://www.rfc-editor.org/authors/rfc9330-lastrfcdiff.html
>>>>>>>> 
>>>>>>>> 
>>>>>>>> 
>>>>>>>> 
>>>>>>>> Tracking progress
>>>>>>>> -----------------
>>>>>>>> 
>>>>>>>> The details of the AUTH48 status of your document are here:
>>>>>>>>   
>>>>>>>> 
>>>>>>>> 
>>>>>>>> https://www.rfc-editor.org/auth48/rfc9330
>>>>>>>> 
>>>>>>>> 
>>>>>>>> 
>>>>>>>> 
>>>>>>>> Please let us know if you have any questions.  
>>>>>>>> 
>>>>>>>> Thank you for your cooperation,
>>>>>>>> 
>>>>>>>> RFC Editor
>>>>>>>> 
>>>>>>>> --------------------------------------
>>>>>>>> RFC9330 (draft-ietf-tsvwg-l4s-arch-20)
>>>>>>>> 
>>>>>>>> Title            : Low Latency, Low Loss, Scalable Throughput (L4S) Internet Service: Architecture
>>>>>>>> Author(s)        : B. Briscoe, Ed., K. De Schepper, M. Bagnulo, G. White
>>>>>>>> WG Chair(s)      : Gorry Fairhurst, David L. Black, Marten Seemann
>>>>>>>> 
>>>>>>>> Area Director(s) : Martin Duke, Zaheduzzaman Sarker
>>>>>>>> 
>>>>>>>> 
>>>>>>>> 
>>>>>>>> 
>>>>>>>> 
>>>>>> -- 
>>>>>> ________________________________________________________________
>>>>>> Bob Briscoe                               
>>>>>> 
>>>>>> 
>>>>>> http://bobbriscoe.net/
>>>>>> 
>>>>>> 
>>>>>> <rfc9330c.xml><rfc9330c-DIFF-a.html>
>>>>>> 
>>>>>> 
>>>> -- 
>>>> ________________________________________________________________
>>>> Bob Briscoe                               
>>>> 
>>>> http://bobbriscoe.net/
>>>> 
>>>> <rfc9330e.xml><rfc9330e-DIFF-d.html><rfc9330e-DIFF-draft-20.html>
>>>> 
>> 
>> -- 
>> ________________________________________________________________
>> Bob Briscoe                               
>> http://bobbriscoe.net/
> 
> -- 
> ________________________________________________________________
> Bob Briscoe                               
> http://bobbriscoe.net/
> <rfc9330g.xml><rfc9330g-DIFF-f.html>