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

[Martin Duke <[e-mail]>]

LGTM

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 Briscoe                               http://bobbriscoe.net/
>
>