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

[Gorry Fairhurst <[e-mail]>]

On 03/11/2022 23:39, Martin Duke wrote:
> LGTM
>
I agree, this approach resolves the issue - thank you for putting in the 
extra time to complete this.

Gorry

> On Thu, Nov 3, 2022 at 4:35 PM Bob Briscoe <[e-mail]> wrote:
>
>     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/
>