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

[Bob Briscoe <[e-mail]>]

Gorry,

Your suggested text seems do-able. I'll write it in, then leave Martin 
to decide.


Bob

On 03/11/2022 09:22, Gorry Fairhurst wrote:
> Bob, I'm aware this is AUTH48, so the AD decides, and that's the way 
> it should be, but I did say soemthing and I think it could be clearer 
> so see [GF] below.
>
> On 03/11/2022 00:14, Bob Briscoe wrote:
>> Gorry, See [BB3]
>>
>> On 02/11/2022 21:50, Gorry Fairhurst wrote:
>>> 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.
>>>
>>> Martin,
>>>
>>> I hope "networks often use"  and the later "Diffserv doesn't always 
>>> sit well with encryption of the layers above" in the same para can 
>>> not be used to imply IETF consensus. I'm not convinced a para is 
>>> necessary to criticise diffserv in favour of L4S and if kept I still 
>>> hold with my comment that this seems para is something we need to 
>>> carefully check.
>>
>> [BB3] I think you're not saying that this text is technically 
>> incorrect, just that you'd rather it wasn't stated. As explained 
>> before, the purpose of this whole section was to justify why the IETF 
>> needs to assign an experimental codepoint in the IP header for L4S, 
>> by explaining what is different from the various technologies that 
>> we've already got that attempt to address similar problems.
>>
>> The reason for this latest change was purely editorial, because 
>> "where networks assign packets to Diffserv classes" was in the wrong 
>> position in the logical flow (as explained above under 'Reason').
>>
>> Would it help to change 'networks often use' to 'networks tend to 
>> use'? I chose 'often' 'cos I thought it was synonymous with 'tend 
>> to'. But if we go with 'tend to', then this, and the later "Diffserv 
>> doesn't always sit well with encryption of the layers above" would be 
>> no different to the text on this point resulting from the WG 
>> processing of this draft (introduced in draft-07 in Oct 2020).
>>
>>
>> Bob
>>
>>
> [GF] I am saying that I am unconfortable with any text infering what 
> networks "typically" or are "allowed" to do, unless that has been a 
> focus of the WG. This particular topic is sensitive to some in the IETF.
>
> Mea culpa, I should have been expressive earlier and have made a 
> suggestion then, SORRY!
>
> **IF** some change is possible, I'd recommend a more neutral tone of 
> voice, so that instead of saying this often/typically/whatever is 
> done. That is, describe the actual implication, without discussing its 
> prevelence or implying good/bad practice in this document.
>
> e.g. for this para I would have suggested something like:
>
>     "Networks that do not trust the end systems to identify the set of 
> that packets should be favoured over others are unable to use packet 
> inspection of application flow identifiers or deeper inspection of 
> application signatures to assign packets to Diffserv classes when this 
> information is encrypted. In this case, Diffserv does not sit well 
> with encryption of the layers above IP [RFC8404], which can result in 
> a choice between privacy and Quality of Service (QoS)"
>
> Please consider and liaise with others if it is OK to make any 
> improvements - I do not have a formal role, so the AD is responsible 
> for approving any change.
>
> ver best wishes,
>
> Gorry
>
>>>
>>> Best wishes,
>>> Gorry
>>>> 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 '®' 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."
>>>>
>>>> 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/