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

[Alanna Paloma <[e-mail]>]

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.  For our understanding, what British style manual are you using? 

> 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).

> 3) XML coding
> 
> Shouldn't '--' be replaced with – in the XML, which would produce '--' in the txt but a correct n-width dash in the HTML and PDF?
> (I had inconsistently used — 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.


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).

...
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)

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>