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

[Bob Briscoe <[e-mail]>]

Gorry, Martin,

This was not easy, but I think I've sorted it and kept the sentences 
short. I wanted to lose the 'Networks sometimes do not trust' from 
Martin's proposal,
which I felt reintroduced the problem Gorry was trying to avoid, namely 
asserting this occurs sometimes, rather than often. I also took Gorry's 
theme one step further, and tried to move away from saying anything 
about users having a choice, because networks might make the choice for 
them:

             In particular, if networks do not trust end systems to 
identify which
             packets should be favoured, they assign packets to Diffserv 
classes
             themselves. However, the techniques available to such 
networks, like
             inspection of flow identifiers or deeper inspection of 
application
             signatures, do not always sit well with encryption of the 
layers above
             IP <xref target="RFC8404" format="default"/>. In these 
cases, users
             can have either privacy or Quality of Service (QoS), but 
not both.

Next email, I'll send (the XML with other changes too) to the RFC Editor.

Bob


On 03/11/2022 18:05, Martin Duke wrote:
> I'm fine with the substantive proposal here (and hereby approve them 
> all), though I don't like the really long sentences. how about:
>
> "Networks sometimes do not trust end systems to identify packets to be
> favored via Diffserv. They might instead inspect application flow 
> identifiers
> or signatures to assign Diffserv classes. However, this technique is not
> robust to encryption of layers above IP [RFC8404], which can result in
> a choice between privacy and Quality of Service (QoS)"
>
> This is a suggestion; if I've mangled it somehow, I preemptively 
> approve Bob's wordsmithing.
>
> On Thu, Nov 3, 2022 at 9:59 AM Bob Briscoe <[e-mail]> wrote:
>
>     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 '&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."
>     >>>>
>     >>>> 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 Briscoehttp://bobbriscoe.net/