Re: [tsvwg] Warren Kumari's No Objection on draft-ietf-tsvwg-ecn-encap-guidelines-21: (with COMMENT)

[Bob Briscoe <[e-mail]>]

Warren, pls see [BB2]

On 01/12/2023 01:07, Bob Briscoe wrote:
> Warren, Thanks for your review - see [BB]
>
> On 30/11/2023 00:03, Warren Kumari via Datatracker wrote:
>> Warren Kumari has entered the following ballot position for
>> draft-ietf-tsvwg-ecn-encap-guidelines-21: No Objection
>>
>> When responding, please keep the subject line intact and reply to all
>> email addresses included in the To and CC lines. (Feel free to cut this
>> introductory paragraph, however.)
>>
>>
>> Please refer tohttps://www.ietf.org/about/groups/iesg/statements/handling-ballot-positions/  
>> for more information about how to handle DISCUSS and COMMENT positions.
>>
>>
>> The document, along with other ballot positions, can be found here:
>> https://datatracker.ietf.org/doc/draft-ietf-tsvwg-ecn-encap-guidelines/
>>
>>
>>
>> ----------------------------------------------------------------------
>> COMMENT:
>> ----------------------------------------------------------------------
>>
>> Thank you for this document, and to Tim Wicinski for the OpsDir review
>> (https://datatracker.ietf.org/doc/review-ietf-tsvwg-ecn-encap-guidelines-20-opsdir-lc-wicinski-2023-10-31/).
>>
>> I think that it would have been helpful for the Abstract to be more specific
>> about the "Updates" - "This document is included in BCP 89 and updates the
>> advice to subnetwork designers about ECN in RFC 3819." -- how does it update
>> the advice? What has changed from RFC3819? The purpose of this is to help
>> readers of the abstract understand what changed / where to focus their
>> attention, and this seems to boil down to "read the whole document".
>
> [BB] PROPOSED:
> This document is included in BCP 89 and*the whole document*  updates the
> *single paragraph of*  advice to subnetwork designers about ECN in RFC 3819.
>
> Let me know if this is still not sufficient.
>
> (FYI, that single para in 3819 was:
>
>     Another possible approach to flow control in the subnet would be to
>     work with TCP Explicit Congestion Notification (ECN) semantics
>     [RFC3168  <https://www.rfc-editor.org/rfc/rfc3168>] through utilizing explicit congestion indicators in subnet
>     frames.  Routers at the edges of the subnet, rather than shaping,
>     would set the explicit congestion bit in those IP packets that are
>     received in subnet frames that have an ECN indication.  Nodes in the
>     subnet would need to implement an active queue management protocol
>     that marks subnet frames instead of dropping them.
> )

[BB2] Replacing my own proposal (following an offlist suggestion by the 
doc shepherd):

    This document is included in BCP 89 and updates the *single
    paragraph of *advice to subnetwork designers about ECN *in section
    13 of* RFC 3819*, by replacing it with a reference to the whole of
    this document*.



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

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