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

[Bob Briscoe <[e-mail]>]

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

-- 
________________________________________________________________
Bob Briscoehttp://bobbriscoe.net/