Re: [auth48] [AD] [C350] AUTH48: RFC-to-be 9331 <draft-ietf-tsvwg-ecn-l4s-id-29> for your review

[Martin Duke <[e-mail]>]

Approved.

On Mon, Jan 9, 2023 at 12:08 PM Karen Moore <[e-mail]> wrote:

> Hi Bob, Koen, and Martin (AD)*,
>
> Thank you for your replies.  Our files have been updated to reflect Bob’s
> changes, and we have removed the hyphen from one 1 instance of “mis-use”
> per Koen’s suggestion.  We have not made any further changes in regard to
> “P12”; if you would like to, please let us know. We also noted Koen’s
> approval of the document on the AUTH48 status page.
>
> *Martin, please review the expansions that were added in Sections 1, 1.1,
> 1.3, 6.1, and 6.2 and let us know if you approve or if any further edits
> are needed.  You can view the changes here:
> https://www.rfc-editor.org/authors/rfc9331-lastdiff.html.
>
> --------
> FILES
> (Please refresh)
>
> The updated XML file is here:
> https://www.rfc-editor.org/authors/rfc9331.xml
>
> The updated output files are here:
> https://www.rfc-editor.org/authors/rfc9331.txt
> https://www.rfc-editor.org/authors/rfc9331.pdf
> https://www.rfc-editor.org/authors/rfc9331.html
>
> These diff files show all changes made during AUTH48:
> https://www.rfc-editor.org/authors/rfc9331-auth48diff.html
> https://www.rfc-editor.org/authors/rfc9331-rfcdiff.html (side by side)
>
> These diff files show only changes made during the last editing round:
> https://www.rfc-editor.org/authors/rfc9331-lastdiff.html
> https://www.rfc-editor.org/authors/rfc9331-lastrfcdiff.html (side by side)
>
> This diff file shows all changes made to date:
> https://www.rfc-editor.org/authors/rfc9331-diff.html
>
> Please contact us with any further updates or with your approval of the
> document in its current form.  We will await approval from Martin prior to
> moving forward in the publication process.
>
> For the AUTH48 status of this document, please see:
> https://www.rfc-editor.org/auth48/rfc9331
>
> Best regards,
>
> RFC Editor/kc
>
>
> > On Jan 9, 2023, at 6:51 AM, Bob Briscoe <[e-mail]> wrote:
> >
> > Koen,
> >
> > I agree with 'misuse',
> >
> > PI2 wasn't forgotten; it's more a question of whether it should be
> included in a list of AQM methods that predated this draft. I didn't think
> it should....
> > ...When looked at one way, it should, and I imagine you're wanting to
> give PI2 the same status as the other AQMs. But the position of PI2
> relative to DualPI2 is probably a source of confusion for most people, so I
> think it's best to rely on the explanation later in this draft, otherwise,
> introducing PI2 here before the explanation will  cause most readers to get
> confused, or at minimum, to do a double-take.
> >
> >
> > Bob
> >
> > On 08/01/2023 14:35, Koen De Schepper (Nokia) wrote:
> >> Hi Bob, Karen,
> >>
> >> I just did a read throughout the whole document again and I saw only
> following nits which could be added/changed:
> >>
> >> Didn’t we forgot to mention PI2 in this list?
> >>    More recent state-of-the-art AQM methods, such as Flow Queue CoDel
> [RFC8290],
> >>    Proportional Integral controller Enhanced (PIE) [RFC8033],
> Proportional Integral Improved with a square [PI2] or Adaptive RED
> [ARED01], ...
> >>
> >> Mis-use -> misuse? Intentionally or was it a hyphen leftover from a
> line-wrap?
> >>    Approaches to assure the integrity of signals using the new
> >>    identifier are introduced in Appendix C.1.  See the security
> >>    considerations in the L4S architecture [RFC9330] for further
> >>    discussion of mis-use of the identifier, as well as extensive
> >>    discussion of policing rate and latency in regard to L4S.
> >>
> >> I’ll let you sort out the acronym expansion (as I don’t have a strong
> preference). So independent of the acceptance of the above nits and acronym
> settlement, I can already approve this document.
> >>
> >> Thanks,
> >> Koen.
> >>
> >> From: Bob Briscoe <[e-mail]>
> >> Sent: Saturday, January 7, 2023 6:25 PM
> >> To: Martin Duke <[e-mail]>; Karen Moore <[e-mail]
> >
> >> Cc: Gorry Fairhurst <[e-mail]>; Koen De Schepper (Nokia)<
> [e-mail]>; RFC Editor <
> [e-mail]>; [e-mail]; [e-mail];
> Wesley Eddy <[e-mail]>; [e-mail]
> >> Subject: Re: [AD] [C350] AUTH48: RFC-to-be 9331
> <draft-ietf-tsvwg-ecn-l4s-id-29> for your review
> >>
> >> Martin and Karen,
> >>
> >> I've re-expanded the remaining abbreviations in the att'd XML, as I
> said I would in my email below:
> >>     rfc9331j.xml
> >> Also, I've att'd the diff from Karen's latest edit (which I've denoted
> as "rfc9331i"):
> >>     rfc9331j-from-i.diff.html
> >>
> >>
> >> Bob
> >>
> >> On 07/01/2023 16:35, Bob Briscoe wrote:
> >> Martin (and Karen,)
> >>
> >> On 06/01/2023 18:47, Martin Duke wrote:
> >> Bob,
> >>
> >> In case this was lost in the holiday shuffle, the ball is in your court.
> >>
> >> [BB3] Thanks. I had read all the emails, but it wasn't clear to me that
> I had been given the edit token on ecn-l4s-id.
> >> I will set to re-expanding some abbreviations in the XML now. This is
> the approach I shall take:
> >>
> >> For the example list of transport protocols in the intro, I will go
> back to the RFC Editor's first approach of expanding the "non-core"
> protocol names, instead of including citations for DCCP and SCTP (which are
> cited later when each protocol is actually discussed).
> >>
> >> 1. Intro.
> >>
> >>
> >> CURRENT:
> >>    The transport wire protocol, e.g., TCP,
> >>    QUIC, SCTP [RFC4960], DCCP [RFC4340], or RTP/RTCP, is orthogonal
> (and
> >>    therefore not suitable for distinguishing L4S from Classic packets).
> >>
> >> PROPOSED:
> >>    The transport wire protocol, e.g., TCP,
> >>    QUIC, the Stream Control Transmission Protocol (SCTP), the Datagram
> >>    Congestion Control Protocol (DCCP), and RTP/RTCP, is orthogonal (and
> >>    therefore not suitable for distinguishing L4S from Classic packets).
> >>
> >>  1.1. Latency, Loss, and Scaling Problems
> >>
> >>
> >> For the list of AQMs, I'll take a similar approach to that you've just
> approved for the DualQ draft, except RED has already been expanded at this
> point. Specifically:
> >>
> >> CURRENT:
> >>    However, Random Early Detection (RED) and other algorithms from the
> 1990s were sensitive...
> >> ...
> >>    More recent state-of-the-art AQM methods, such as FQ-CoDel
> [RFC8290],
> >>    PIE [RFC8033], or Adaptive RED [ARED01],...
> >> ...
> >>    This was useful because per-flow queuing (FQ) ....
> >>
> >> PROPOSED:
> >>    However, Random Early Detection (RED) and other algorithms from the
> 1990s were sensitive...
> >> ...
> >>    More recent state-of-the-art AQM methods, such as Flow Queue CoDel
> [RFC8290],
> >>    Proportional Integral controller Enhanced (PIE) [RFC8033], or
> Adaptive RED [ARED01], ...
> >> ...
> >>    This was useful because per-flow queuing (FQ) ...
> >>
> >> Deeper into the Document
> >>
> >>
> >> I'll add back expansions of EH, ESP, TRILL etc.
> >>
> >>
> >> Bob
> >>
> >>
> >>
> >> On Wed, Dec 28, 2022 at 10:24 AM Martin Duke <[e-mail]>
> wrote:
> >> I'm sympathetic to the desire to keep sentences brisk, but I find the
> idea that these acronyms are stashed in the references list to be
> reader-hostile. Would it be too much to ask for a short glossary just after
> the introduction to spell these out?
> >>
> >> On Thu, Dec 22, 2022 at 4:27 PM Bob Briscoe <[e-mail]>
> wrote:
> >> Gorry,
> >>
> >> On 22/12/2022 09:20, Gorry Fairhurst wrote:
> >> On 21/12/2022 21:46, Bob Briscoe wrote:
> >> Martin,
> >>
> >> On 20/12/2022 19:24, Martin Duke wrote:
> >>
> >>
> >> On Sat, Dec 17, 2022 at 7:16 AM Bob Briscoe <[e-mail]>
> wrote:
> >> Martin,
> >>
> >> On 16/12/2022 23:22, Martin Duke wrote:
> >> There is a lot of email about this; pardon me if it's been thoroughly
> discussed:
> >>
> >> (1) I don't understand why we edited out introducing acronyms on first
> use:
> >> DCTCP, FQ-Codel, PIE, TRILL, EH, ESP
> >>
> >> [BB] We persuaded the RFC Editor to expand or not on a case-by-case
> basis rather than following an "expand-on-first-use" rule too rigidly.
> >> Before the RFC Editor process, we had judged that these particular ones
> were:
> >> * better known by their abbreviation than their expansion
> >> * easily look-up-able for anyone interested in the expansion, via the
> title of the reference cited beside them
> >> * and they were within a sentence that was already long, so an
> (unnecessary) expansion would make it overly long and complicated.
> >>
> >> In the case of DCTCP, it's expansion adds important context, but the
> first use is in an already complex sentence. So, at the first use it says
> "the DCTCP/DualQ solution described below", and it is expanded in the next
> para.
> >>
> >> Also, FQ is expanded elsewhere 'cos it's meaning is important, but
> CoDel is only expanded in the cited title of its reference.
> >>
> >> OK, you've clearly thought through the sequencing here. I'm not going
> to insist on first-use, but I do think these acronym expansions should be
> somewhere in the document, either in a glossary or in subsequent use, as
> you've done with DCTCP.
> >>
> >> [BB2] Does "somewhere in the document" include in the title of a
> reference cited where the abbreviation is first used (e.g. DCCP [RFC4340])?
> >> I've tried to only do this where the expansion isn't central to
> understanding the document, and expanding it on first use subtracts from
> the sense of the sentence.
> >>
> >>
> >> Bob
> >> Before a draft leaves the TSVWG, we would normally check that all
> acronyms are expanded on their first use within the body of the text (the
> abstract is treated separately and needs to have its own definitions). I
> still think this is an important, rather than requiring readers to consult
> another document to understand if they have correctly interpreted an
> acronym.
> >>
> >>
> >> [BB] We're not saying anyone has to consult another document - just
> consult the title of the reference cited in /this/ document. And this is
> only for any abbreviation that:
> >> 1. is known by it's abbreviation (by those familiar with it)
> >> 2. would make a sentence in the intro hard to follow if all
> abbreviations were expanded
> >> 3. is only mentioned in passing so it isn't necessary for understanding
> the document.
> >>
> >>
> >> On this document, I leave it to Martin to decide whether there is
> reason to do otherwise.
> >>
> >>
> >> [BB] Yup.
> >> Thanks
> >>
> >>
> >> Bob
> >>
> >>
> >> Gorry
> >>
> >> (TSVWG Co-Chair)
> >>
> >>
> >>
> >>
> >>
> >> (2) This edit in Sec 5.1 seems non-cosmetic.
> >> In case unforeseen problems arise with the L4S experiment, it MUST be
> >>    possible to configure an L4S implementation to disable the L4S
> >>    treatment.  Once disabled, all packets of all ECN codepoints will
> >>    receive Classic treatment, and ECT(1) packets MUST be treated as if
> they
> >>    were Not-ECT.
> >> I agree that the original text was ambiguously worded, but the
> common-sense reading of the original (given that this is a section about
> network nodes) is that ECT(1) would
> >> go in the ECT(0) queue and be marked CE in accordance with the RFC 3168
> rules. The new text is different. I can see advantages to the new rule but
> I wonder if we have
> >> consensus for this change?
> >>
> >> [BB] Yes, but common sense might be in short supply. "Classic
> treatment" could be incorrectly taken to mean "Classic ECN treatment".
> >> This sentence went through an intermediate version, which you might
> prefer because it stays closer to the original:
> >>
> >> In case unforeseen problems arise with the L4S experiment, it MUST be
> >>    possible to configure an L4S implementation to disable the L4S
> >>    treatment.  Once disabled, all packets of all ECN codepoints will
> >>    receive Classic treatment, and ECT(1) packets MUST be treated as if
> they
> >>    were Not-ECT, then all packets of all ECN codepoints will
> >>    receive treatment compatible with Classic congestion control.
> >>
> >> But, in the most recent edits, I asked the RFC Editor to take out the
> final clause completely at the suggestion of my co-authors.
> >> We can leave it in if you'd rather.
> >>
> >> I think I ave misinterpreted the diff. This is fine as-is.
> >>
> >>
> >> --
> >> ________________________________________________________________
> >> Bob Briscoe                               http://bobbriscoe.net/
> >>
> >>
> >>
> >>
> >> --
> >> ________________________________________________________________
> >> Bob Briscoe                               http://bobbriscoe.net/
> >>
> >>
> >> --
> >> ________________________________________________________________
> >> Bob Briscoe                               http://bobbriscoe.net/
> >>
> >>
> >> --
> >> ________________________________________________________________
> >> Bob Briscoe                               http://bobbriscoe.net/
> >
> > --
> > ________________________________________________________________
> > Bob Briscoe
> > http://bobbriscoe.net/
>
>