Re: [auth48] [AD] [C350] AUTH48: RFC-to-be 9331 <draft-ietf-tsvwg-ecn-l4s-id-29> for your review
Bob Briscoe <ietf@bobbriscoe.net> Sat, 17 December 2022 15:16 UTC
Return-Path: <ietf@bobbriscoe.net>
X-Original-To: auth48archive@ietfa.amsl.com
Delivered-To: auth48archive@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 086F1C15170E; Sat, 17 Dec 2022 07:16:34 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.096
X-Spam-Level:
X-Spam-Status: No, score=-2.096 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, NICE_REPLY_A=-0.001, RCVD_IN_ZEN_BLOCKED_OPENDNS=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, URIBL_DBL_BLOCKED_OPENDNS=0.001, URIBL_ZEN_BLOCKED_OPENDNS=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=bobbriscoe.net
Received: from mail.ietf.org ([50.223.129.194]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YsFkEtcqsi1U; Sat, 17 Dec 2022 07:16:29 -0800 (PST)
Received: from mail-ssdrsserver2.hostinginterface.eu (mail-ssdrsserver2.hostinginterface.eu [185.185.85.90]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 29BFCC14F740; Sat, 17 Dec 2022 07:16:28 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=bobbriscoe.net; s=default; h=In-Reply-To:From:References:Cc:To:Subject: MIME-Version:Date:Message-ID:Content-Type:Sender:Reply-To: Content-Transfer-Encoding:Content-ID:Content-Description:Resent-Date: Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:List-Id: List-Help:List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive; bh=qlZhBrp7bP3H4OG/nzF+zR89RLWD+8LpP8TtFt/bN+Q=; b=gnTFBu1mh1xHrLhxx1+96ROBsm c6Vq+A24uyAGkqJ/O5bOyMirKzuAwS57813PYQObGHn/loFbk+GzUiB/nbvWY+9FrDPCa9/WoHHQO ryN8Ut14OQbhOHgkmzJV2OGSybHFEb33zYcsi5Wkb1HKdatmCUSFfFrh2Cr7ExXeg1gc20VQ3LTvA iPIE/PQatjDrvhf1mi8rIrRkjPIMr3pzHfHNpsM9TTxnnQ38IPaiah1/OwTALLwGLxbSXhiQ4Tv4i /WpLF7YpW2h7XrAOlvBkyK1BhkfKbpqZMzjW+69FEIrQQpZH4flVBw9WB7TCMbRUmD5oZ0kV0KTEx pIMT5mIQ==;
Received: from 67.153.238.178.in-addr.arpa ([178.238.153.67]:51670 helo=[192.168.1.11]) by ssdrsserver2.hostinginterface.eu with esmtpsa (TLS1.2) tls TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (Exim 4.95) (envelope-from <ietf@bobbriscoe.net>) id 1p6YvT-00DCEW-Sj; Sat, 17 Dec 2022 15:16:25 +0000
Content-Type: multipart/alternative; boundary="------------HZSHG0aiO5hE79XzMG04fetD"
Message-ID: <7076c4f4-b5eb-3296-a29b-b98b80eabe81@bobbriscoe.net>
Date: Sat, 17 Dec 2022 15:16:23 +0000
MIME-Version: 1.0
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:102.0) Gecko/20100101 Thunderbird/102.4.2
Content-Language: en-GB
To: Martin Duke <martin.h.duke@gmail.com>, Karen Moore <kmoore@amsl.com>
Cc: koen.de_schepper@nokia.com, RFC Editor <rfc-editor@rfc-editor.org>, tsvwg-ads@ietf.org, tsvwg-chairs@ietf.org, Wesley Eddy <wes@mti-systems.com>, auth48archive@rfc-editor.org
References: <20221118225755.C83CB1BA478D@rfcpa.amsl.com> <a61ae0a0-019c-e3d1-d243-d77c3e64dcdf@bobbriscoe.net> <DFE467B3-241C-4A23-86EB-518619F03CF0@amsl.com> <6bbde9e2-9e61-d66e-7211-cd528b5a7058@bobbriscoe.net> <0017CE18-C8EB-4D03-8B37-A72725A76C08@amsl.com> <40606c92-0f6e-9839-1610-c29943fd257a@bobbriscoe.net> <B1CA1A45-E763-43B2-8A92-BA63FFCC532B@amsl.com> <40c20415-8d0c-9218-7993-eb152fa3f378@bobbriscoe.net> <486253F1-D6E4-48FA-AD27-3311F7F3B79F@amsl.com> <CAM4esxSq8D_=GGE1Wq3X-+fvGmz1uy6HXNi7fXbJvgzjFw89pg@mail.gmail.com>
From: Bob Briscoe <ietf@bobbriscoe.net>
In-Reply-To: <CAM4esxSq8D_=GGE1Wq3X-+fvGmz1uy6HXNi7fXbJvgzjFw89pg@mail.gmail.com>
X-AntiAbuse: This header was added to track abuse, please include it with any abuse report
X-AntiAbuse: Primary Hostname - ssdrsserver2.hostinginterface.eu
X-AntiAbuse: Original Domain - rfc-editor.org
X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12]
X-AntiAbuse: Sender Address Domain - bobbriscoe.net
X-Get-Message-Sender-Via: ssdrsserver2.hostinginterface.eu: authenticated_id: in@bobbriscoe.net
X-Authenticated-Sender: ssdrsserver2.hostinginterface.eu: in@bobbriscoe.net
X-Source:
X-Source-Args:
X-Source-Dir:
Archived-At: <https://mailarchive.ietf.org/arch/msg/auth48archive/IDQfIO5ZeghlH5fpZm4ArsTztuE>
Subject: Re: [auth48] [AD] [C350] AUTH48: RFC-to-be 9331 <draft-ietf-tsvwg-ecn-l4s-id-29> for your review
X-BeenThere: auth48archive@rfc-editor.org
X-Mailman-Version: 2.1.39
Precedence: list
List-Id: "Archiving AUTH48 exchanges between the RFC Production Center, the authors, and other related parties" <auth48archive.rfc-editor.org>
List-Unsubscribe: <https://mailman.rfc-editor.org/mailman/options/auth48archive>, <mailto:auth48archive-request@rfc-editor.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/auth48archive/>
List-Post: <mailto:auth48archive@rfc-editor.org>
List-Help: <mailto:auth48archive-request@rfc-editor.org?subject=help>
List-Subscribe: <https://mailman.rfc-editor.org/mailman/listinfo/auth48archive>, <mailto:auth48archive-request@rfc-editor.org?subject=subscribe>
X-List-Received-Date: Sat, 17 Dec 2022 15:16:34 -0000
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.
>
> (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.
>
> Other than that, it looks fine.
[BB] Thanks
Bob
>
> On Fri, Dec 16, 2022 at 10:44 AM Karen Moore <kmoore@amsl.com> wrote:
>
> Hi Bob and Martin*,
>
> Thanks for providing your approval; we have noted it on the AUTH48
> status page for this document. We now await approvals from Martin
> and Koen.
>
> *Martin, this is a reminder that we await your approval for the
> changes made in Sections 5.1, 5.4.2, and 7.2 and Appendices A.1.4
> and C.1. The changes are highlighted below and can also be viewed
> here: https://www.rfc-editor.org/authors/rfc9331-auth48diff.html.
> Note that since our original call for your approval (on 12/12/2),
> the authors updated #2 further, and the note for #7 was clarified
> further .
>
> 1) FYI, we have updated this document with the changes shown
> in the -30 file sent by the authors. The diff from the approved I-D
> is here:
> https://www.rfc-editor.org/authors/draft-ietf-tsvwg-ecn-l4s-id-29-30-rfcdiff.html
>
> Please review and let us know if you approve the change
> in Appendix C.1 (the paragraph starts with "At the time of writing").
>
> 2) Section 5.1 - rephrased
>
> Old:
> 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.
>
> New:
> Once disabled, ECT(1) packets MUST be treated as if they were
> Not-ECT.
>
> 3) Section 5.4.2 - replaced “Layer-4” with “transport-layer”
>
> Old:
> At a node with per-flow queueing (e.g. FQ-CoDel [RFC8290]), the L4S
> identifier could complement the Layer-4 flow ID as a further
> level of
> flow granularity (i.e. Not-ECT and ECT(0) queued separately from
> ECT(1) and CE packets).
>
> New:
> At a node with per-flow queuing (e.g., FQ-CoDel [RFC8290]), the L4S
> identifier could complement the transport-layer flow ID as a further
> level of flow granularity (i.e., Not-ECT and ECT(0) queued
> separately
> from ECT(1) and CE packets).
>
> 4) Section 7.2 - replaced “EWMA” with “average”
>
> Old:
> Originally, this was due to a bug in the initialization of the
> congestion EWMA in the Linux implementation of TCP Prague.
>
> New:
> Originally, this was due to a bug in the initialization of the
> congestion average in the Linux implementation of TCP Prague.
>
> 5) Appendix A.1.4 - rephrased, including the removal of “MUST”
>
> Old:
> In the particular case of DCTCP, the DCTCP
> specification [RFC8257] states that "It is RECOMMENDED that an
> implementation deal with loss episodes in the same way as
> conventional TCP." For safe deployment, Section 4.3 requires any
> specification of a scalable congestion control for the public
> Internet to define the above requirement as a "MUST”.
>
> New:
> In the particular case of DCTCP, the DCTCP
> specification [RFC8257] states that "A DCTCP sender MUST react
> to loss episodes in
> the same way as conventional TCP,…". To ensure any Scalable
> congestion control
> is safe to deploy over the public Internet, Item 3 of Section
> 4.3 in the present spec
> does not require precisely the same response as Reno TCP, but it
> does require a
> response that will coexist safely with Classic congestion
> controls like Reno.
>
> 6) Appendix A.1.4 - rephrased
>
> Old:
> At least one implementation reacts
> only to the drop signal (e.g., by halving the CWND) and at least
> another DCTCP implementation reacts to both signals (e.g., by
> halving the CWND due to the drop and also further reducing the CWND
> based on the proportion of marked packet). A third approach for the
> public Internet has been proposed that adjusts the loss response to
> result in a halving when combined with the ECN response.
>
> New:
> One approach is to react only to the drop
> signal (e.g., by halving the CWND); another approach is to react
> to both
> signals, which reduces CWND by more than half. A compromise
> between these two has been proposed where the loss response is
> adjusted to
> result in a halving when combined with any ECN response earlier
> in the same
> round.
>
> 7) Changed “ECN” to “IP-ECN” only where it referred to the ECN
> field in the IP header (to distinguish for instance from the ECN
> flags in the TCP header).
>
> --------
> 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 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 approvals from
> each author 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 Dec 16, 2022, at 9:59 AM, Bob Briscoe <ietf@bobbriscoe.net>
> wrote:
> >
> > Karen,
> >
> > Thank you. I approve the latest XML.
> >
> >
> > Bob
> >
> > On 16/12/2022 00:26, Karen Moore wrote:
> >> Hello Bob,
> >>
> >> Thanks for the updated files; these changes are now reflected
> in our files. Within the XML file, we have responded to your new
> notes with “[RFC Editor 3]” (all of your updates are agreeable).
> Below are responses to your comments within this email.
> >>
> >> Notes:
> >> 1) For "[DCttH19]”, we updated the URL from
> "https://bobbriscoe.net/pubs.html#DCttH_TR” to
> "https://bobbriscoe.net/projects/latency/dctth_journal_draft20190726.pdf”.
> >>
> >> 2) We added “Burstiness” as a keyword for this document and
> have asked for it to be added to 9330 as well.
> >>
> >> 3) Acknowledging the proposed rephrase of text in Section 5.1;
> will have Martin approve it.
> >>
> >> 4) Acknowledging that the set of 3 changes for “mark” or
> “marking” is agreeable.
> >>
> >> 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 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
> approvals from each author and the AD 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 Dec 14, 2022, at 3:57 PM, Bob Briscoe <ietf@bobbriscoe.net>
> wrote:
> >>>
> >>> Karen,
> >>> I've written each of my comments tagged [BB3] below into the
> attached XML, and altered it accordingly as well, except the
> [DCttH19] reference, which I have left for you.
> >>>
> >>> On 13/12/2022 02:30, Karen Moore wrote:
> >>>> Hi Bob and Martin (AD)*,
> >>>>
> >>>> Thank you for the updated XML file (and the diffs); we have
> updated our files accordingly (links to the files are further down
> in the email). We have added comments to the items marked as
> “BB2” in the XML file (to note that we agree with all of your
> edits - searchable as "[RFC Editor 2]"). Below are some additional
> notes to address the comments within this email, plus one new
> question (see #9).
> >>>>
> >>>> Notes:
> >>>> 1) We have asked for RFC-to-be 9330 to be reflect
> "[SCReAM-LS4]” instead of "[SCReAM]”
> >>>> 2) Updates made to the expansions are agreeable
> >>>> 3) This is agreeable: “per application-flow”
> >>>> 4) Regarding the use of <bcp14> tags, thank you for posing
> your questions to the RSWG
> >>>> 5) This is agreeable: <<DOCSIS doesn't need a reference, just
> as LTE and 5G don't. They are names of technologies.>>
> >>>> 6) This is agreeable: <<I didn't add a citation for
> RoCEv2...I just expanded RDMA…>>
> >>>> 7) This is agreeable: <<TCP Prague -> Prague>>
> >>>> 8) We will seek AD approval for item #74 (it’s included in
> the portion for Martin below)
> >>>> 9) Regarding "[DCttH19]", if possible, please provide a URL for
> >>>> the published document, rather than to a portion of the
> >>>> publications page on a personal site.
> >>>>
> >>>> Original:
> >>>> [DCttH19] De Schepper, K., Bondarenko, O., Tilmans, O., and B.
> >>>> Briscoe, "`Data Centre to the Home': Ultra-Low
> Latency for
> >>>> All", Updated RITE project Technical Report ,
> July 2019,
> >>>> <https://bobbriscoe.net/pubs.html#DCttH_TR>.
> >>> [BB3] I'm afraid that is the only instance of that report on
> the web. We can't really file it on arXiv now, because it is an
> earlier version of the one we have now filed on arXiv [L4Seval22].
> >>> Unfortunately, the Jul'19 draft is the only version with the
> specific experiments discussed where the [DCttH19] citation is
> used, which is why we kept it, and didn't update this instance to
> [L4Seval22].
> >>>
> >>> A more specific URL to the citation is:
> https://bobbriscoe.net/pubs.html#DeSchepper19a
> >>> Or the specific URL of the PDF is:
> https://bobbriscoe.net/projects/latency/dctth_journal_draft20190726.pdf
> >>>
> >>>> ----------
> >>>> *Martin, please review the following updates to Sections 5.1,
> 5.4.2, and 7.2 and Appendices A.1.4 and C.1 and let us know if
> you approve. The changes are highlighted below and can also be
> reviewed here:
> https://www.rfc-editor.org/authors/rfc9331-auth48diff.html
> >>>>
> >>>> 1) FYI, we have updated this document with the changes shown
> >>>> in the -30 file sent by the authors. The diff from the
> approved I-D
> >>>> is here:
> >>>>
> https://www.rfc-editor.org/authors/draft-ietf-tsvwg-ecn-l4s-id-29-30-rfcdiff.html
> >>>>
> >>>> Please review and let us know if you approve the change
> >>>> in Appendix C.1 (the paragraph starts with "At the time of
> writing").
> >>>>
> >>>> 2) Section 5.1 - rephrased
> >>>>
> >>>> Old:
> >>>> 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.
> >>>> New:
> >>>> Once disabled, 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.
> >>> [BB3] I met with the co-authors of the 3 drafts last night,
> and they suggested that this would be clearer without the last
> clause at all, i.e.
> >>>
> >>> Proposed:
> >>> Once disabled, ECT(1) packets MUST be treated as if they were
> >>> Not-ECT.
> >>>
> >>>
> >>>
> >>>> 3) Section 5.4.2 - replaced “Layer-4” with “transport-layer”
> >>>>
> >>>> Old:
> >>>> At a node with per-flow queueing (e.g. FQ-CoDel
> [RFC8290]), the L4S
> >>>> identifier could complement the Layer-4 flow ID as a
> further level of
> >>>> flow granularity (i.e. Not-ECT and ECT(0) queued
> separately from
> >>>> ECT(1) and CE packets).
> >>>>
> >>>> New:
> >>>> At a node with per-flow queuing (e.g., FQ-CoDel
> [RFC8290]), the L4S
> >>>> identifier could complement the transport-layer flow ID as
> a further
> >>>> level of flow granularity (i.e., Not-ECT and ECT(0) queued
> separately
> >>>> from ECT(1) and CE packets).
> >>>>
> >>>> 4) Section 7.2 - replaced “EWMA” with “average”
> >>>>
> >>>> Old:
> >>>> Originally, this was due to a bug in the initialization of the
> >>>> congestion EWMA in the Linux implementation of TCP Prague.
> >>>>
> >>>> New:
> >>>> Originally, this was due to a bug in the initialization of the
> >>>> congestion average in the Linux implementation of TCP Prague.
> >>>>
> >>>> 5) Appendix A.1.4 - rephrased, including the removal of “MUST”
> >>>>
> >>>> Old:
> >>>> In the particular case of DCTCP, the DCTCP
> >>>> specification [RFC8257] states that "It is RECOMMENDED that an
> >>>> implementation deal with loss episodes in the same way as
> >>>> conventional TCP." For safe deployment, Section 4.3
> requires any
> >>>> specification of a scalable congestion control for the public
> >>>> Internet to define the above requirement as a "MUST”.
> >>>>
> >>>> New:
> >>>> In the particular case of DCTCP, the DCTCP
> >>>> specification [RFC8257] states that "A DCTCP sender MUST
> react to loss episodes in
> >>>> the same way as conventional TCP,…". To ensure any
> Scalable congestion control
> >>>> is safe to deploy over the public Internet, Item 3 of
> Section 4.3 in the present spec
> >>>> does not require precisely the same response as Reno TCP,
> but it does require a
> >>>> response that will coexist safely with Classic congestion
> controls like Reno.
> >>>>
> >>>> 6) Appendix A.1.4 - rephrased
> >>>>
> >>>> Old:
> >>>> At least one implementation reacts
> >>>> only to the drop signal (e.g., by halving the CWND) and at
> least
> >>>> another DCTCP implementation reacts to both signals (e.g., by
> >>>> halving the CWND due to the drop and also further reducing
> the CWND
> >>>> based on the proportion of marked packet). A third
> approach for the
> >>>> public Internet has been proposed that adjusts the loss
> response to
> >>>> result in a halving when combined with the ECN response.
> >>>>
> >>>> New:
> >>>> One approach is to react only to the drop
> >>>> signal (e.g., by halving the CWND); another approach is to
> react to both
> >>>> signals, which reduces CWND by more than half. A compromise
> >>>> between these two has been proposed where the loss
> response is adjusted to
> >>>> result in a halving when combined with any ECN response
> earlier in the same
> >>>> round.
> >>>>
> >>>> 7) Throughout the text:
> >>>> Changed “ECN” to “IP-ECN”
> >>> [BB3] @Martin, it was not quite 'throughout' -- only where it
> referred to the ECN field in the IP header (to distinguish for
> instance from the ECN flags in the TCP header).
> >>>
> >>> [BB3] 75. While reviewing RFC-to-be 9332, we thought of
> another keyword for all three L4S drafts. I've added it to
> RFC-to-be 9331.
> >>> Please also add the keyword 'Burstiness' to RFC-to-be 9330.
> >>>
> >>> [BB3] 76. My co-authors have also suggested a further set of 3
> changes, where the word 'mark' or 'marking' has been inadvertently
> used for initially setting the ECN field, when 'ECN marking' is
> defined as the network changing the ECN field to CE. I've applied
> the following three changes to the XML:
> >>>
> >>> if packets originally marked ECT(0)
> >>> -> if packets originally set to ECT(0)
> >>>
> >>> mis-marked bursty traffic
> >>> -> mis-identified bursty traffic
> >>>
> >>> if the most recent ECT packet in the same flow had been marked
> ECT(0)
> >>> -> if the most recent ECT packet in the same flow had been set
> to ECT(0)
> >>>
> >>> There are no incorrect instances of 'mark' in RFC-to-be 9330.
> >>> For RFC-to-be 9332, I'll deal with this issue when I send my
> first review email shortly.
> >>>
> >>> FILES
> >>> I've attached edited XML rfc9331g.xml
> >>> And an rfcdiff from your latest (rfc9331f)
> >>>
> >>> Thank you again,
> >>>
> >>>
> >>>
> >>> Bob
> >>>
> >>>> --------
> >>>> 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 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
> approvals from each author prior to moving forward in the
> publication process.
> >>>>
> >>>> For the AUTH48 status of this document, please see:
> >>>> https://www.rfc-editor.org/auth48/rfc9331
> >>>>
> >>>> Thank you,
> >>>>
> >>>> RFC Editor/kc
> >>>>
> >>>>
> >>>>> On Dec 11, 2022, at 2:18 PM, Bob Briscoe
> <ietf@bobbriscoe.net> wrote:
> >>>>>
> >>>>> Karen, See [BB2] inline.
> >>>>>
> >>>>> On 01/12/2022 23:51, Karen Moore wrote:
> >>>>>> Hello Bob,
> >>>>>>
> >>>>>> Thank you for your detailed review and comments. In the
> XML file, we have removed the questions that were marked “[rfced]”
> as we believe these have all been addressed (except for two, which
> need AD approval). We replied to each of the comments marked with
> “[BB]” - you can search on “[RFC Editor]” to see our responses.
> Most indicate that we agree with your edits ("[RFC Editor] Ok -
> agreeable"). Below, please see the list of items where an action
> was taken. Should you have any questions or need clarification on
> anything, please let us know.
> >>>>>>
> >>>>>> Note that there are some updates that will need AD
> approval; we will seek approval once you have had a chance to
> review this round of edits.
> >>>>>>
> >>>>>> -------------------------
> >>>>>> RFC Editor Actions:
> >>>>> [BB] Thank you. All AOK, except the three with responses
> below...
> >>>>>
> >>>>>> 1) reverted the first expansions of "DCTCP" and "DualQ".
> Expanded both on the next mentions (used "Dual Queue Coupled AQM"
> per 9330 (instead of "Dual Queue (DualQ) Coupled AQM”). Please let
> us know if any further changes are needed.
> >>>>>> 2) reverted the expansions for “SCReAM", “SCTP", and “DCCP"
> and added citations for “SCTP" and “DCCP".
> >>>>>> 3) reverted "[SCReAM]" to "[SCReAM-LS4]” throughout.
> >>>>> [BB2] Pls could you make RFC9330 consistent with this (if
> only to avoid it causing a diff in the terminology section).
> >>>>>
> >>>>>> 4) reverted the following expansions to be consistent with
> RFC-to-be 9330. If any further changes are desired, please let us
> know.
> >>>>>>
> >>>>>> AQM (in the intro)
> >>>>>> RED
> >>>>>> FQ-CoDel
> >>>>>> PIE
> >>>>>> VPN
> >>>>>> ABE
> >>>>>> ACK
> >>>>>> RACK
> >>>>>> DupACK
> >>>>>> TRILL
> >>>>>> AH
> >>>>>> ESP
> >>>>>> CDN
> >>>>>> Ex-ToS
> >>>>>> DOCSIS
> >>>>>> RoCEv2
> >>>>>> A2DTCP
> >>>>>> VCP
> >>>>>>
> >>>>>> Kept:
> >>>>>> LDAP (expanded in 9330)
> >>>>>> VoIP (expanded in 9330)
> >>>>> [BB2] Sorry, I should have been clearer when I said
> "consistent with RFC9330". I meant:
> >>>>> * For technologies that most readers know by their
> abbreviations, I have avoided expansion where it would make a
> sentence unreasonably long or complex, and instead expansion is
> either deferred to a later sentence, referred to via citation, or
> both.
> >>>>> * For a technology that is only mentioned in passing, I have
> expanded, rather than using a citation.
> >>>>> * Excessive expansion of abbreviations tends to be more of
> an issue in the Abstract/Introduction. Later in a doc, I've used
> expansion more liberally.
> >>>>>
> >>>>> Specifically:
> >>>>> AQM is already expanded in the abstract.
> >>>>>
> >>>>> I've re-expanded the following:
> >>>>> RED
> >>>>> VPN
> >>>>> ACK
> >>>>> RACK
> >>>>> DupACK
> >>>>> CDN
> >>>>> Ex-ToS
> >>>>> DOCSIS
> >>>>> RoCEv2
> >>>>> A2DTCP
> >>>>> VCP
> >>>>>
> >>>>> And I've explained the rest via their citations:
> >>>>> FQ-CoDel
> >>>>> PIE
> >>>>> ABE
> >>>>> TRILL
> >>>>> AH
> >>>>> ESP
> >>>>>
> >>>>> STATUS2: No further action if agreeable to the RFC Editor.
> >>>>>
> >>>>>
> >>>>>> 5) re: "(Relentless, SCReAM, etc.)”, we asked for 9330 to
> be updated to match.
> >>>>>> 6) removal of "uses the ECN field as an identifier” is
> agreeable. We have asked for the same update to be made in
> RFC-to-be 9330.
> >>>>>> 7) removed the <blockquote> tags around the quote that is 4
> lines.
> >>>>>> 8) reverted the comma after “Whereas” (current: “Whereas,
> in the Classic Approach,…”).
> >>>>>> 9) reverted the second hyphen in "'per-application flow”
> (current: “per-application-flow”).
> >>>>> [BB2] My co-author, Greg, pointed out that when before the
> noun it should be 'per
> >>>>> application-flow queues', where 'per' is not hyphenated as
> in 'per person quotas'
> >>>>> but 'application-flow' is hyphenated as a compound adjective.
> >>>>>
> >>>>> STATUS2: No further action if agreeable to the RFC Editor.
> >>>>>
> >>>>>> 10) reverted the change made to the IANA URL in Section 8.
> IANA prefers that we point to the top-level registry rather than
> the subregistry (so the document now reflects
> "https://www.iana.org/assignments/dscp-registry” instead of
> "https://www.iana.org/assignments/dscp-registry/#ecn-field”).
> >>>>>> 11) fyi - we are ok with including <tfoot> in Table 2.
> >>>>>> 12) reverted RFCs 9330 and 9332 to informative references.
> >>>>>> 13) fixed the output of the I-Ds in the Informative
> References section.
> >>>>>>
> >>>>>> --------------------------------------------
> >>>>>> Additional Questions/Clarifications:
> >>>>>> 1) Regarding the comment below, our practice is to place
> <bcp14> tags around each normative keyword, whether they are in
> quotes or not. For normative keywords within a quote from another
> RFC, we use the tags even if BCP 14 text is not used in the main
> document. Given this, we have not made any further changes to the
> XML.
> >>>>> [BB2] Yes, I can see that it is the RFC Editor's practice.
> But I'm asking whether it is a correct practice :|
> >>>>>
> >>>>> Nonetheless, this is a wider question that applies to all
> RFCs, not just this one. So it shouldn't hold up this RFC. I've
> raised it on the RSWG list instead.
> >>>>>
> >>>>>>> [BB] Surely it's questionable to place <bcp14> around
> quoted normative keywords, because quotes negate the
> 'normativeness' (normativity?) of these keywords. I'm thinking
> particularly of sentences quoted from other RFCs that are
> normative in that RFC, but not in this one. For instance, if
> someone were to write automated compliance checking software, they
> would not expect to have to comply with keywords in quotes. If you
> agree, there are more than a dozen occurrences in quotes that will
> need reverting.
> >>>>>> 2 a) Would it be correct to add "[DOCSIS-QPROT]” as a
> reference for “DOCSIS” (in A.1.8)?
> >>>>> [BB2] Nope.
> >>>>> Anyway, DOCSIS doesn't need a reference, just as LTE and 5G
> don't. They are names of technologies.
> >>>>>
> >>>>>> b) Would you like to add a citation for “RoCEv2”? Also, we
> assume that “RDMA” does not need to be added back since it is part
> of “RoCEv2” when expanded; please review.
> >>>>>>
> >>>>>> Current:
> >>>>>> As mentioned above, hardware implementations of loss
> recovery using
> >>>>>> DupACK counting exist (e.g., some implementations of
> RoCEv2).
> >>>>> 72. [BB2] I didn't add a citation for RoCEv2, 'cos it's just
> mentioned in passing. Anyway we would really want a citation for
> the hardware implementation of loss recovery in RoCEv2, and there
> isn't one (it's proprietary). I just expanded RDMA, without
> mentioning the abbreviation, like you had done earlier.
> >>>>>
> >>>>> Finally, I noticed some need for additional editing, two of
> which I've pasted below.
> >>>>> They can also be found already written into the attached
> XML, and annotated with comments tagged with [BB2] and ending with
> 'STATUS2':
> >>>>> I've identified that #74 will require AD approval, 'cos it's
> disambiguating normative text.
> >>>>>
> >>>>> 73. [BB2] TCP Prague -> Prague
> >>>>> (the cited draft used to be solely for TCP, but it was
> generalized to all transport protocols at -01)
> >>>>> STATUS2: No further action if agreeable to the RFC Editor.
> >>>>>
> >>>>> 74. [BB2] Original:
> >>>>> 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 realized that 'Classic treatment' could ambiguously be
> read as 'Classic ECN treatment',
> >>>>> which would be confusing for the Not-ECT codepoint.
> >>>>> So I've clarified that it's '...treatment compatible with
> Classic congestion control'.
> >>>>> I've also switch the two parts of the sentence, so the
> normative statement is first, because
> >>>>> the original first part was just a consequence of the
> normative part.
> >>>>> STATUS2: No further action if agreeable to the RFC Editor
> and the AD.
> >>>>>
> >>>>> There are also a couple of minor editorial changes you can
> find in the attached diff (using rfcdiff relative to txt compiled
> from your most recent xml which I've called rfc9331d.xml).
> >>>>>
> >>>>> For the archive, I've also attached a diff relative to the
> draft-29 approved by the IESG.
> >>>>>
> >>>>> Cheers
> >>>>>
> >>>>>
> >>>>> Bob
> >>>>>
> >>>>>> 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
> >>>>>>
> >>>>>> This diff file shows all changes made during AUTH48:
> >>>>>> https://www.rfc-editor.org/authors/rfc9331-auth48diff.html
> >>>>>>
> >>>>>> This diff file shows all changes made to date:
> >>>>>> https://www.rfc-editor.org/authors/rfc9331-diff.html
> >>>>>>
> >>>>>> Note that it may be necessary for you to refresh your
> browser to view the most recent version. Please review the
> document carefully to ensure satisfaction as we do not make
> changes once it has been published as an RFC.
> >>>>>>
> >>>>>> Please contact us with any further updates or with your
> approval of the document in its current form. We will await
> approvals from each author prior to moving forward in the
> publication process.
> >>>>>>
> >>>>>> For the AUTH48 status of this document, please see:
> >>>>>> https://www.rfc-editor.org/auth48/rfc9331
> >>>>>>
> >>>>>> Thank you,
> >>>>>>
> >>>>>> RFC Editor/kc
> >>>>>>
> >>>>>>
> >>>>>>> On Nov 25, 2022, at 10:18 AM, Bob Briscoe
> <ietf@bobbriscoe.net> wrote:
> >>>>>>>
> >>>>>>> RFC Editor/kc/ar,
> >>>>>>>
> >>>>>>> Thank you for all your edits, finding my inconsistencies
> and errors.
> >>>>>>>
> >>>>>>> Before getting to the nitty-gritty, a question...
> >>>>>>>
> >>>>>>> Q1) Surely it's questionable to place <bcp14> around
> quoted normative keywords, because quotes negate the
> 'normativeness' (normativity?) of these keywords. I'm thinking
> particularly of sentences quoted from other RFCs that are
> normative in that RFC, but not in this one.
> >>>>>>> For instance, if someone were to write automated
> compliance checking software, they would not expect to have to
> comply with keywords in quotes.
> >>>>>>> If you agree, there are more than a dozen occurrences
> in quotes that will need reverting.
> >>>>>>>
> >>>>>>> I have attached new XML:
> >>>>>>> * with updates where I felt sure (including a justifying
> comment),
> >>>>>>> * and comments asking you to update if appropriate, where
> I didn't feel confident enough to override your edits (or where
> there were bulk edits to make, which were best left to you).
> >>>>>>>
> >>>>>>> I did the edits in two stages:
> >>>>>>> * a->b taking your 32 points in your XML (a) and
> responding within the XML (b)
> >>>>>>> * b->c checking through the diff and reacting where I
> disagreed (72 cases, including 6 where I noticed improvements
> should be made to our original text).
> >>>>>>> I have attached diff a->c as well as a->b & b->c.
> >>>>>>> For the lists, I've also attached a diff between our -29
> submission as approved by the IESG and my latest ('c').
> >>>>>>>
> >>>>>>> I have been as liberal as possible. I only intervened
> where I felt the meaning had been incorrectly changed or clarity
> reduced.
> >>>>>>>
> >>>>>>> You do not need to read this email any further, because
> the following only summarizes everything I have written into the
> attached XML.
> >>>>>>> But the summaries below might help you plan how to process
> the XML faster.
> >>>>>>>
> >>>>>>> I've answered all 32 points that you had tagged [rfced]
> within the XML. The listing below is the first line of each point
> (as a rough exec summary) followed by my 1-line STATUS
> categorization of each.
> >>>>>>> These are NOT the full explanations, which are within the
> XML, tagged [BB]. This is just designed so you can see there are
> only two STATUSes:
> >>>>>>> 13 "OK" = I've accepted what
> you've done.
> >>>>>>> 19 "if agreeable to editor, no further action required." =
> Please check my attempt to do as asked.
> >>>>>>> ________
> >>>>>>> 32 Total
> >>>>>>>
> >>>>>>> Following those 32 cases are a further 71 cases where I
> felt the new text needed reverting or rephrasing (including 6
> cases where I noticed a problem with our original text).
> >>>>>>> Again I've only given:
> >>>>>>> * the first line (NOT the whole explanation, which is in
> the XML)
> >>>>>>> * and a corresponding STATUS line, summarized here:
> >>>>>>> 53 include "no further action required" in some form.
> >>>>>>> But pls check the new text, esp. those tagged "if
> agreeable".
> >>>>>>> 18 ask you for further edits.
> >>>>>>> These can be found quickly by searching for the word
> "please".
> >>>>>>> ________
> >>>>>>> 71 Total
> >>>>>>>
> >>>>>>> Summary listings follow:
> >>>>>>> 32 RFC-Editor points (responses commented fully within the
> XML)
> >>>>>>>
> >>>>>>> 1:<!--[rfced] FYI, we have updated this document with the
> changes shown
> >>>>>>> 2:<!--[rfced] FYI, the title has been updated as follows as
> >>>>>>> 3:<!--[rfced] Please insert any keywords (beyond those
> that appear in the
> >>>>>>> 4:<!--[rfced] Is the intention to include both "many" and
> "(most?)" in
> >>>>>>> 5:<!--[rfced] We note the use of <tt> and <em> within this
> document.
> >>>>>>> 6:<!--[rfced] RFC 2309 has been obsoleted by RFC 7567. May
> we add a note
> >>>>>>> 7:<!--[rfced] Would it be correct to move the RFC 3649
> citation after
> >>>>>>> 8:<!--[rfced] Terminology section:
> >>>>>>> 9:<!--[rfced] "Experimental" (capitalized) can be used to
> refer to the
> >>>>>>> 10:<!--[rfced] RFC 4960 has been obsoleted by RFC 9260.
> May we add a note
> >>>>>>> 11:<!--[rfced] Please review whether any of the notes in
> this document should be
> >>>>>>> 12:<!--[rfced] For clarity, should RFC 3168 be added as a
> reference here?
> >>>>>>> 13:<!--[rfced] Per RFC 5865, should "Voice-Admit" be
> "VOICE-ADMIT" (1 instance)?
> >>>>>>> 14:<!--[rfced] FYI, we changed "to an L4S identifier" to
> "of an L4S identifier"
> >>>>>>> 15:<!--[rfced] Does "not necessarily completely regularly"
> mean "not
> >>>>>>> 16:<!--[rfced] Please clarify what "that" refers to in the
> following:
> >>>>>>> 17:<!--[rfced] RFC 3168 only mentions "ECT(0)" and "ECT(1)",
> >>>>>>> 18:<!--[rfced] The following quote is not a direct quote
> from RFC 8257.
> >>>>>>> 19:<!--[rfced] A "third approach" is mentioned here. Will
> it be clear to
> >>>>>>> 20:<!--[rfced] Since there are multiple expansions for "CDN",
> >>>>>>> 21:<!--[rfced] We added "its" for clarity and rephrased
> "ex-ToS byte" to
> >>>>>>> 22:<!--[rfced] Since there is typically a space between
> the digit and unit of
> >>>>>>> 23:<!--[rfced] Would you like to add "in item 4 of Section
> 4.3"
> >>>>>>> 24:<!--[rfced] FYI: We removed "for RDMA" from this
> sentence since
> >>>>>>> 25:<!--[rfced] May the following sentence be rephrased for
> clarity
> >>>>>>> 26:<!--[rfced] Is the spacing intentional for
> "150,151,152" or should
> >>>>>>> 27:<!--[rfced] Is "to cater for" accurate wording here, or
> would
> >>>>>>> 28:<!--[rfced] Usage of 'round' in 'work-rounds', 'safe
> way round', and
> >>>>>>> 29:<!--[rfced] FYI, as per the mail from Bob Briscoe on
> 2022-09-12, British English
> >>>>>>> 30:<!--[rfced] Throughout the text, the following
> terminology appears to be used
> >>>>>>> 31:<!--[rfced] Please review the "Inclusive Language"
> portion of the online
> >>>>>>> 32:<!--[rfced] We see a number of author-inserted comments
> in the XML file of
> >>>>>>>
> >>>>>>> 1: STATUS: OK.
> >>>>>>> 2: STATUS: OK.
> >>>>>>> 3: STATUS: If agreeable to editor, no further action
> required.
> >>>>>>> 4: STATUS: If agreeable to editor, no further action
> required.
> >>>>>>> 5: STATUS: If agreeable to editor, no further action
> required.
> >>>>>>> 6: STATUS: OK.
> >>>>>>> 7: STATUS: If agreeable to editor, no further action
> required.
> >>>>>>> 8: STATUS: OK (assuming nothing has been changed here
> yet, which I believe to be so).
> >>>>>>> 9: STATUS: If agreeable to editor, no further action
> required.
> >>>>>>> 10: STATUS: If agreeable to editor, no further action
> required.
> >>>>>>> 11: STATUS: If agreeable to editor, no further action
> required.
> >>>>>>> 12: STATUS: OK
> >>>>>>> 13: STATUS: If agreeable to editor, no further action
> required.
> >>>>>>> 14: STATUS: If agreeable to editor, no further action
> required.
> >>>>>>> 15: STATUS: If agreeable to editor, no further action
> required.
> >>>>>>> 16: STATUS: If agreeable to editor, no further action
> required.
> >>>>>>> 17: STATUS: Done.
> >>>>>>> 18: STATUS: If agreeable to editor, no further action
> required. This changes commentary on normative text (tho' not the
> normative text itself), so you might want to ask for AD approval.
> >>>>>>> 19: STATUS: If agreeable to editor, no further action
> required.
> >>>>>>> 20: STATUS: OK.
> >>>>>>> 21: STATUS: OK.
> >>>>>>> 22: STATUS: OK.
> >>>>>>> 23: STATUS: If agreeable to editor, no further action
> required. But please closely check all my new xref's.
> >>>>>>> 24: STATUS: OK.
> >>>>>>> 25: STATUS: Reverted. If agreeable to editor, no further
> action required.
> >>>>>>> 26: STATUS: OK.
> >>>>>>> 27: STATUS: If agreeable to editor, no further action
> required.
> >>>>>>> 28: STATUS: If agreeable to editor, no further action
> required. But open to further discussion.
> >>>>>>> 29: STATUS: OK.
> >>>>>>> 30: STATUS: If agreeable to editor, no further action
> required.
> >>>>>>> 31: STATUS: OK.
> >>>>>>> 32: STATUS: OK.
> >>>>>>> My 71 disagreements warranting a mention (commented fully
> within the XML)
> >>>>>>>
> >>>>>>> 1:<!--[BB] Reverted to 'delay under load',which was
> intended, 'cos it has a different meaning to 'delay under a load'
> >>>>>>> 2:<!--[BB] Reverted to 'delay ... is sub-millisecond on
> average', 'cos 'delay ... is a sub-millisecond' doesn't make sense.
> >>>>>>> 3:<!--[BB] I haven't reverted DCTCP / DualQ to their
> abbreviated forms, with their expansions
> >>>>>>> 4:<!--[BB] I've reverted to 'Data Center TCP' without a
> hyphen and spelled the US way,
> >>>>>>> 5:<!--[BB] I've removed the commas around 'while
> waiting...' because the the intended meaning was
> >>>>>>> 6:<!--[BB] I've reverted to 'a different issue that needs
> to be addressed, but separately...'
> >>>>>>> 7:<!--[BB] Given AQM has been expanded here, I've removed
> the initial 'The', because 'Management'
> >>>>>>> 8:<!--[BB] It seems like all the experience from having
> just edited the previous draft in this
> >>>>>>> 9:<!--[BB] SCReAM citations:
> >>>>>>> 10:<!--[BB] The addition of 'or' would have been more
> appropriate than 'and'.
> >>>>>>> 11:<!--[BB] I think 'an increasing level..., the
> longer...' is hard to read without the comma.
> >>>>>>> 12:<!--[BB] aka -> a.k.a.
> https://www.chicagomanualofstyle.org/qanda/data/faq/topics/Abbreviations/faq0099.html
> >>>>>>> 13:<!--[BB] Pls revert expansions, consistent with
> RFC-to-be 9330.
> >>>>>>> 14:<!--[BB] I believe I'm right in saying that FQ is used
> for per-flow queuing but not
> >>>>>>> 15:<!--[BB] Removal of 'etc.' was because three examples
> other than Prague were listed above.
> >>>>>>> 16:<!--[BB] The addition of 'uses the ECN field as an
> identifier' is not relevant here,
> >>>>>>> 17:<!--[BB] This meant that Classic ECN as a whole is
> applicable to v4 & v6.
> >>>>>>> 18:<!--[BB] 'this' meant the relaxation, not the ABE spec.
> >>>>>>> 19:<!--[BB] Accurate is not capitalized (2 occurrences),
> because it refers to the requirements for accurate ECN feedback,
> >>>>>>> 20:<!--[BB] Removal of 'with' from 'all other factors
> being equal': pls see discussion in RFC-to-be 9330 XML.
> >>>>>>> 21:<!--[BB] Addition of 'further' reverted from 'further
> rationale' (5 occurrences), because there is no other rationale in
> each of these items.
> >>>>>>> 22:<!--[BB] Citation of Reno [RFC5681] reverted to its
> original position after 'standard Reno',
> >>>>>>> 23:<!--[BB] Given this is a deeply controversial subject,
> I'm slightly concerned that selecting only one of the three
> quotations for a
> >>>>>>> 24:<!--[BB] ID expanded on first use of 'flow identifier'
> (as was suggested for RFC 9330).
> >>>>>>> 25:<!--[BB] I don't see why one of the commas that
> bracketed off 'in the Classic approach' has been removed;
> >>>>>>> 26:<!--[BB] Addition of 'further' reverted from 'further
> rationale', because there is only assertion, not rationale, here.
> >>>>>>> 27:<!--[BB] Removing the second hyphen in 'separate queues
> per-application flow' has changed the meaning
> >>>>>>> 28:<!--[BB] I've removed the added 'if it' from:
> >>>>>>> 29:<!--[BB] I noticed our 'for example' in parentheses
> followed an e.g. for unexpected combinations,
> >>>>>>> 30:<!--[BB] Removed the added 'the' from 'and [the] CE
> indicates' 'cos it no longer makes sense,
> >>>>>>> 31:<!--[BB] Surely adding 'on' slightly obstructs the
> reader's flow for no benefit.
> >>>>>>> 32:<!--[BB] The second 'them' is good, but surely adding
> the opening subclause ('for such packets') slightly
> >>>>>>> 33:<!--[BB] I noticed that our own text was ambiguous;
> 'The two can be combined...'
> >>>>>>> 34:<!--[BB] The edit to 'Layer 4' made me notice
> 'transport-layer' would be more consistent with the rest of the
> document.
> >>>>>>> 35:<!--[BB] Rather than changing 'other incoming
> interface(s)' to 'another incoming interface(s)',
> >>>>>>> 36:<!--[BB] The demotion of ';' to ',' made me think it
> would be more readable to enumerate
> >>>>>>> 37:<!--[BB] Originally, this said:
> >>>>>>> 38:<!--[BB] It isn't worth saying EWMA specifically if it
> has to be expanded. So I've
> >>>>>>> 39:<!--[BB] The addition of 'and' could imply that both
> can be used together (which is impossible).
> >>>>>>> 40:<!--[BB] I noticed that we had said 'The 01 codepoint
> is specified...', when we meant
> >>>>>>> 41:<!--[BB] I noticed that the registry URL was
> https://www.iana.org/assignments/dscp-registry/
> >>>>>>> 42:<!--[BB] Suggested briefer tags for AccECN, ECN++ and
> QPROT to mirror the common names used for each.
> >>>>>>> 43:<!--[BB] Please revert RFC 9330 and RFC 9332 to
> informative references. The WG discussed
> >>>>>>> 44:<!--[BB] I notice that the URLs of some I-Ds in the txt
> output are to specific versions
> >>>>>>> 45:<!--[BB] The added commit ID was far behind (Jun'22).
> Updated commit ID and date to latest (20-Nov-22).
> >>>>>>> 46:<!--[BB] Reverted addition of 'see', because the
> parenthesis wasn't intended to refer
> >>>>>>> 47:<!--[BB] As earlier, reverted to keep the distinction
> between accurate ECN feedback and the specific AccECN scheme.
> >>>>>>> 48:<!--[BB] 'shared' had been altered to 'share'. 'shared'
> was intended as the subjunctive mood,
> >>>>>>> 49:<!--[BB] The addition of 'the' to 'CE marking' has been
> reverted, because the outcome is
> >>>>>>> 50:<!--[BB] I noticed 'presuming the AQM behaviours known
> at the time of writing' could be
> >>>>>>> 51:<!--[BB] I've temporarily commented out this
> construction, and replaced it with a <tfoot>,
> >>>>>>> 52:<!--[BB] I've reverted 'was' back to 'were', because
> our real problem here was 'will'
> >>>>>>> 53:<!--[BB] 'The speed-of-loss recovery' was not what was
> intended. Readers would probably
> >>>>>>> 54:<!--[BB] I think one can say 'a factor of x longer'
> (the original) or 'x times longer',
> >>>>>>> 55:<!--[BB] 'Slow start' is the well-known name of a phase
> of the TCP algorithm.
> >>>>>>> 56:<!--[BB] The change to 'might be arriving' is
> definitely not what was intended,
> >>>>>>> 57:<!--[BB] The change from 'supported' to 'supports'
> doesn't fit with the earlier 'would support'.
> >>>>>>> 58:<!--[BB] The later change from comma to semicolon made
> me realize there could just be a sentence split here.
> >>>>>>> 59:<!--[BB] Changing 'there will be no problem' to 'it
> will not be a problem' weakens
> >>>>>>> 60:<!--[BB] Although 'reduce the congestion window' would
> be correct, it makes the reader
> >>>>>>> 61:<!--[BB] The addition of 'a' is technically correct
> before 'flow(s)', but it makes the
> >>>>>>> 62:<!--[BB] There has already been discussion of 'in [the]
> future' on the list. To cut to the chase,
> >>>>>>> 63:<!--[BB] The addition of a hyphen in 'low-link
> capacities' has changed the meaning to 'the capacities of low links'!
> >>>>>>> 64:<!--[BB] The addition of quotes round 'Not-ECT' is
> inconsistent with every other occurrence of
> >>>>>>> 65:<!--[BB] Given this discussion includes TCP, I've
> disambiguated to IP-ECN field, because there are ECN flags in the
> TCP header.
> >>>>>>> 66:<!--[BB] The change from the subjunctive 'once use ...
> had' (for an unlikely eventuality) to 'once use ... have been'
> >>>>>>> 67:<!--[BB] I think one can say 'the following categories'
> (the original) or 'the categories described below',
> >>>>>>> 68:<!--[BB] Upper-cased 'Paragraph' for consistency with
> automated xref rendering.
> >>>>>>> 69:<!--[BB] See earlier re. accurate ECN feedback, vs.
> AccECN feedback.
> >>>>>>> 70:<!--[BB] The added hyphen in 'Less-severe congestion'
> looks incorrect, and CMS agrees.
> >>>>>>> 71:<!--[BB] 'I noticed I had written 'also' incorrectly in
> 'Bob Briscoe was [also] partly funded'.
> >>>>>>>
> >>>>>>> 1:STATUS: Reverted. If agreeable to editor, no further
> action required.
> >>>>>>> 2:STATUS: Reverted. If agreeable to editor, no further
> action required.
> >>>>>>> 3:STATUS: Please revert.
> >>>>>>> 4:STATUS: Reverted. If agreeable to editor, no further
> action required.
> >>>>>>> 5:STATUS: Reverted. If agreeable to editor, no further
> action required.
> >>>>>>> 6:STATUS: Reverted. If agreeable to editor, no further
> action required.
> >>>>>>> 7:STATUS: If agreeable to editor, no further action required.
> >>>>>>> 8:STATUS: Please revert the expansions, and add citations
> instead where necessary.
> >>>>>>> 9:STATUS: Please revert all the SCReAM edits, if agreeable
> to the editor.
> >>>>>>> 10:STATUS: Rephrased. If agreeable to editor, no further
> action required.
> >>>>>>> 11:STATUS: Please explain the need to remove the comma, or
> otherwise revert.
> >>>>>>> 12:STATUS: If agreeable to editor, no further action required.
> >>>>>>> 13:STATUS: Please revert expansions.
> >>>>>>> 14:STATUS: Reverted. If agreeable to editor, no further
> action required.
> >>>>>>> 15:STATUS: Reverted to 'etc.' Please also revert in
> RFC-to-be 9330.
> >>>>>>> 16:STATUS: Reverted. If agreeable to editor, no further
> action required. Please also mirror in RFC-to-be 9330.
> >>>>>>> 17:STATUS: Rephrased. If agreeable to editor, no further
> action required.
> >>>>>>> 18:STATUS: Rephrased. If agreeable to editor, no further
> action required.
> >>>>>>> 19:STATUS: Reverted. No further action required.
> >>>>>>> 20:STATUS: Reverted. No further action required.
> >>>>>>> 21:STATUS: Reverted. If agreeable to editor, no further
> action required.
> >>>>>>> 22:STATUS: Reverted. If agreeable to editor, no further
> action required.
> >>>>>>> 23:STATUS: Please review whether all 3 quotes can be
> treated the same, either blockquoting all or none.
> >>>>>>> 24:STATUS: If agreeable to editor, no further action required.
> >>>>>>> 25:STATUS: Please explain the need to remove the comma, or
> otherwise revert.
> >>>>>>> 26:STATUS: Reverted. If agreeable to editor, no further
> action required.
> >>>>>>> 27:STATUS: Please explain the need for removal of the
> hyphen, or otherwise revert.
> >>>>>>> 28:STATUS: Reverted. If agreeable to editor, no further
> action required. Otherwise, we're open to better suggestions (for
> 2 occurrences of the same phrasing).
> >>>>>>> 29:STATUS: Rephrased. If agreeable to editor, no further
> action required.
> >>>>>>> 30:STATUS: Reverted. If agreeable to editor, no further
> action required.
> >>>>>>> 31:STATUS: Reverted. Please explain the need to add 'on'
> and revert back if appropriate.
> >>>>>>> 32:STATUS: Reverted the addition of the subclause. Please
> explain the need to add this subclause and revert back if appropriate.
> >>>>>>> 33:STATUS: If agreeable to editor, no further action required.
> >>>>>>> 34:STATUS: If agreeable to editor, no further action required.
> >>>>>>> 35:STATUS: Rephrased. If agreeable to editor, no further
> action required.
> >>>>>>> 36:STATUS: Rephrased. If agreeable to editor, no further
> action required.
> >>>>>>> 37:STATUS: Rephrased. If agreeable to editor, no further
> action required.
> >>>>>>> 38:STATUS: Rephrased. If agreeable to editor, no further
> action required.
> >>>>>>> 39:STATUS: Rephrased. If agreeable to editor, no further
> action required.
> >>>>>>> 40:STATUS: Rephrased. If agreeable to editor, no further
> action required.
> >>>>>>> 41:STATUS: Made registry URL more specific. If agreeable
> to editor, no further action required.
> >>>>>>> 42:STATUS: Suggested change to citation tags. If agreeable
> to editor, no further action required.
> >>>>>>> 43:STATUS: Please revert, or justify this non-editorial
> change.
> >>>>>>> 44:STATUS: Editor might wish to investigate the cause of
> this inconsistency.
> >>>>>>> 45:STATUS: Updated reference. If agreeable to editor, no
> further action required.
> >>>>>>> 46:STATUS: Reverted. If agreeable to editor, no further
> action required.
> >>>>>>> 47:STATUS: Reverted. If agreeable to editor, no further
> action required.
> >>>>>>> 48:STATUS: Rephrased. If agreeable to editor, no further
> action required.
> >>>>>>> 49:STATUS: Reverted. If agreeable to editor, no further
> action required.
> >>>>>>> 50:STATUS: Rephrased. If agreeable to editor, no further
> action required.
> >>>>>>> 51:STATUS: This form can be deleted if alternative is
> agreeable to the editor.
> >>>>>>> 52:STATUS: Reverted and rephrased. If agreeable to editor,
> no further action required.
> >>>>>>> 53:STATUS: Rephrased. No further action required.
> >>>>>>> 54:STATUS: Rephrased. If agreeable to editor, no further
> action required.
> >>>>>>> 55:STATUS: Reverted 'slow and start'. If agreeable to
> editor, no further action required.
> >>>>>>> 56:STATUS: Reverted. Please explain why the original
> wasn't acceptable, so we can work out an alternative if necessary.
> >>>>>>> 57:STATUS: Rephrased. If agreeable to editor, no further
> action required.
> >>>>>>> 58:STATUS: Split sentence into two. If agreeable to
> editor, no further action required.
> >>>>>>> 59:STATUS: Reverted. Please explain the need for the
> change and revert back if appropriate.
> >>>>>>> 60:STATUS: Reverted. No further action required.
> >>>>>>> 61:STATUS: Rephrased. If agreeable to editor, no further
> action required.
> >>>>>>> 62:STATUS: Reverted (2 occurrences). If agreeable to
> editor, no further action required.
> >>>>>>> 63:STATUS: Reverted. No further action required.
> >>>>>>> 64:STATUS: Reverted. Please explain the need for the
> change and revert back if appropriate.
> >>>>>>> 65:STATUS: Disambiguated ECN to IP-ECN throughout. No
> further action required.
> >>>>>>> 66:STATUS: Rephrased. If agreeable to editor, no further
> action required.
> >>>>>>> 67:STATUS: Rephrased. If agreeable to editor, no further
> action required.
> >>>>>>> 68:STATUS: Upper-cased 'Paragraph'. If agreeable to
> editor, no further action required.
> >>>>>>> 69:STATUS: Reverted. No further action required.
> >>>>>>> 70:STATUS: Reverted. If agreeable to editor, no further
> action required.
> >>>>>>> 71:STATUS: No further action required.
> >>>>>>>
> >>>>>>> Regards
> >>>>>>>
> >>>>>>>
> >>>>>>> Bob
> >>>>>>>
> >>>>>>> On 18/11/2022 22:57, rfc-editor@rfc-editor.org wrote:
> >>>>>>>> Authors, AD*,
> >>>>>>>>
> >>>>>>>> *Martin, please see #1.
> >>>>>>>>
> >>>>>>>> While reviewing this document during AUTH48, please
> resolve (as necessary) the
> >>>>>>>> following questions, which are also in the XML file.
> >>>>>>>>
> >>>>>>>> 1) <!--[rfced] FYI, we have updated this document with
> the changes shown
> >>>>>>>> in the -30 file sent by the authors. The diff from the
> approved I-D
> >>>>>>>> is here:
> >>>>>>>>
> >>>>>>>>
> https://www.rfc-editor.org/authors/draft-ietf-tsvwg-ecn-l4s-id-29-30-rfcdiff.html
> >>>>>>>>
> >>>>>>>>
> >>>>>>>> *[AD] Martin, Please review and let us know if you
> approve the change
> >>>>>>>> in Appendix C.1 (the paragraph starts with "At the time
> of writing").
> >>>>>>>> -->
> >>>>>>>>
> >>>>>>>>
> >>>>>>>> 2) <!--[rfced] FYI, the title has been updated as follows as
> >>>>>>>> requested in Bob's mail 2022-11-03 regarding RFC-to-be 9330.
> >>>>>>>> The short title has been updated as well. Please review and
> >>>>>>>> let us know if you would like any further changes.
> >>>>>>>>
> >>>>>>>> Title
> >>>>>>>> Original:
> >>>>>>>> Explicit Congestion Notification (ECN) Protocol for
> >>>>>>>> Very Low Queuing Delay (L4S)
> >>>>>>>>
> >>>>>>>> Current:
> >>>>>>>> The Explicit Congestion Notification (ECN) Protocol for
> >>>>>>>> Low Latency, Low Loss, and Scalable Throughput (L4S)
> >>>>>>>>
> >>>>>>>>
> >>>>>>>> Short Title (appears in the running header of the PDF)
> >>>>>>>> Original:
> >>>>>>>> L4S ECN Protocol for V Low Queuing Delay
> >>>>>>>>
> >>>>>>>> Current:
> >>>>>>>> ECN Protocol for L4S
> >>>>>>>> -->
> >>>>>>>>
> >>>>>>>>
> >>>>>>>> 3) <!-- [rfced] Please insert any keywords (beyond those
> that appear in the
> >>>>>>>> title) for use on
> >>>>>>>> https://www.rfc-editor.org/search
> >>>>>>>> . -->
> >>>>>>>>
> >>>>>>>>
> >>>>>>>> 4) <!--[rfced] Is the intention to include both "many"
> and "(most?)" in
> >>>>>>>> the following, or should one be deleted?
> >>>>>>>> Or, rephrase as "many (perhaps most) Internet applications"
> >>>>>>>>
> >>>>>>>> Original:
> >>>>>>>> Latency is becoming the critical performance factor
> for many (most?)
> >>>>>>>> Internet applications, e.g. interactive web, web
> services, voice,
> >>>>>>>> conversational video, interactive video, interactive
> remote presence,
> >>>>>>>> instant messaging, online gaming, remote desktop,
> cloud-based
> >>>>>>>> applications & services, and remote control of
> machinery and
> >>>>>>>> industrial processes.
> >>>>>>>> -->
> >>>>>>>>
> >>>>>>>>
> >>>>>>>> 5) <!--[rfced] We note the use of <tt> and <em> within
> this document.
> >>>>>>>> FYI, <tt> yields fixed-width font in the HTML and PDF
> outputs.
> >>>>>>>> In the text output, <em> yields an underscore before and
> after.
> >>>>>>>> In the HTML and PDF outputs, <em> yields italics.
> >>>>>>>>
> >>>>>>>> Please review carefully and let us know if the output is
> acceptable or
> >>>>>>>> if any updates are desired.
> >>>>>>>> -->
> >>>>>>>>
> >>>>>>>>
> >>>>>>>> 6) <!--[rfced] RFC 2309 has been obsoleted by RFC 7567.
> May we add a note
> >>>>>>>> about this relationship as follows?
> >>>>>>>>
> >>>>>>>> Original:
> >>>>>>>> However, RED [RFC2309] and other algorithms from the
> 1990s were
> >>>>>>>> sensitive to their configuration and hard to set
> correctly.
> >>>>>>>>
> >>>>>>>> Perhaps:
> >>>>>>>> However, RED [RFC2309] (which has been obsoleted
> >>>>>>>> by [RFC7567]) and other algorithms from the 1990s were
> >>>>>>>> sensitive to their configuration and hard to set
> correctly.
> >>>>>>>> -->
> >>>>>>>>
> >>>>>>>>
> >>>>>>>> 7) <!--[rfced] Would it be correct to move the RFC 3649
> citation after
> >>>>>>>> "congestion control"?
> >>>>>>>>
> >>>>>>>> Original:
> >>>>>>>> Given regular broadband bit-rates over WAN distances are
> >>>>>>>> already [RFC3649] beyond the scaling range of Reno
> congestion
> >>>>>>>> control, 'less unscalable' Cubic [RFC8312] and Compound
> >>>>>>>> [I-D.sridharan-tcpm-ctcp] variants of TCP have been
> successfully
> >>>>>>>> deployed.
> >>>>>>>>
> >>>>>>>> Perhaps:
> >>>>>>>> Given that regular broadband bitrates over WAN
> distances are
> >>>>>>>> already beyond the scaling range of Reno congestion
> >>>>>>>> control [RFC3649], 'less unscalable' CUBIC [RFC8312]
> and Compound
> >>>>>>>> [CTCP] variants of TCP have been successfully deployed.
> >>>>>>>> -->
> >>>>>>>>
> >>>>>>>>
> >>>>>>>> 8) <!--[rfced] Terminology section:
> >>>>>>>> Due to your note that these definitions "should be
> identical" to the ones
> >>>>>>>> in Section 3 of RFC-to-be 9330, we have updated these
> definitions to match
> >>>>>>>> the current text in RFC-to-be 9330, with the exceptions
> noted below.
> >>>>>>>> (If any changes are requested for this document,
> RFC-to-be 9330 will be also
> >>>>>>>> updated.)
> >>>>>>>>
> >>>>>>>> Please refer to this diff file (comparing the relevant
> sections in the
> >>>>>>>> current 9330 and current 9331):
> >>>>>>>>
> >>>>>>>>
> https://www.rfc-editor.org/authors/rfc9330_vs_9331_term_diff.html
> >>>>>>>>
> >>>>>>>>
> >>>>>>>> a) For "Classic Congestion Control", should this document
> be updated to
> >>>>>>>> match the definition in 9330? They are significantly
> different.
> >>>>>>>>
> >>>>>>>> b) For "Scalable Congestion Control", should the "This
> maintains the same
> >>>>>>>> degree..." sentence be removed from this document (in
> order to match 9330)?
> >>>>>>>> The only difference is this one sentence.
> >>>>>>>> -->
> >>>>>>>>
> >>>>>>>>
> >>>>>>>> 9) <!--[rfced] "Experimental" (capitalized) can be used
> to refer to the
> >>>>>>>> status of an RFC (or the intended status of a document).
> >>>>>>>> Here, it seems it refers to the packet marking treatment,
> so it
> >>>>>>>> remains lowercase. (FYI, the word "track" has been
> removed in several
> >>>>>>>> instances in this document, as "Experimental track" is
> typically referred
> >>>>>>>> to as "Experimental status" or simply "Experimental".)
> >>>>>>>> Also, may the repetition of "treatment" be avoided as
> follows?
> >>>>>>>>
> >>>>>>>> Original:
> >>>>>>>> The L4S treatment is an experimental track alternative
> packet
> >>>>>>>> treatment to the Classic ECN treatment in [RFC3168], ...
> >>>>>>>>
> >>>>>>>> Current:
> >>>>>>>> The L4S treatment is an experimental alternative
> packet marking
> >>>>>>>> treatment to the Classic ECN treatment in [RFC3168], ...
> >>>>>>>>
> >>>>>>>> Option A:
> >>>>>>>> The L4S treatment is an experimental alternative
> packet marking
> >>>>>>>> to the Classic ECN treatment in [RFC3168], ...
> >>>>>>>>
> >>>>>>>> Option B (if it's necessary to mention Experimental status):
> >>>>>>>> L4S ECN (which is specified in this Experimental RFC)
> is an
> >>>>>>>> alternative packet marking treatment to the Classic
> ECN treatment
> >>>>>>>> in [RFC3168], ...
> >>>>>>>> -->
> >>>>>>>>
> >>>>>>>>
> >>>>>>>> 10) <!--[rfced] RFC 4960 has been obsoleted by RFC 9260.
> May we add a note
> >>>>>>>> about this relationship as follows and add RFC 9260 to
> the Informative
> >>>>>>>> References?
> >>>>>>>>
> >>>>>>>> Original:
> >>>>>>>> SCTP: A suitable ECN feedback mechanism for SCTP could
> add a chunk
> >>>>>>>> to report the number of received CE marks (as
> described in a long-
> >>>>>>>> expired draft [I-D.stewart-tsvwg-sctpecn] or as
> sketched out in
> >>>>>>>> Appendix A of the now obsolete second standards
> track
> >>>>>>>> specification of SCTP [RFC4960]).
> >>>>>>>>
> >>>>>>>> Perhaps:
> >>>>>>>> SCTP: A suitable ECN feedback mechanism for SCTP could
> add a chunk
> >>>>>>>> to report the number of received CE marks (as
> described in a long-
> >>>>>>>> expired document [SCTP-ECN] or as sketched out
> in Appendix A
> >>>>>>>> of the second Standards Track specification of
> SCTP [RFC4960],
> >>>>>>>> which has been obsoleted by [RFC9260]).
> >>>>>>>>
> >>>>>>>> Or (as "the second Standards Track specification" seems
> necessary):
> >>>>>>>> SCTP: A suitable ECN feedback mechanism for SCTP could
> add a chunk
> >>>>>>>> to report the number of received CE marks (as
> described in a long-
> >>>>>>>> expired document [SCTP-ECN] or as sketched out
> in Appendix A
> >>>>>>>> of SCTP [RFC4960], which has been obsoleted by
> [RFC9260]).
> >>>>>>>> -->
> >>>>>>>>
> >>>>>>>>
> >>>>>>>> 11) <!--[rfced] 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
> >>>>>>>> ).
> >>>>>>>> -->
> >>>>>>>>
> >>>>>>>>
> >>>>>>>> 12) <!--[rfced] For clarity, should RFC 3168 be added as
> a reference here?
> >>>>>>>>
> >>>>>>>> Original:
> >>>>>>>> * Drop Tail: Coexistence between L4S and Classic
> flows is not in
> >>>>>>>> doubt where the bottleneck does not support any
> form of ECN,
> >>>>>>>> which has remained by far the most prevalent
> case since the ECN
> >>>>>>>> RFC was published in 2001.
> >>>>>>>>
> >>>>>>>> Perhaps:
> >>>>>>>> * Drop Tail: Coexistence between L4S and Classic
> flows is not in
> >>>>>>>> doubt where the bottleneck does not support any
> form of ECN,
> >>>>>>>> which has remained by far the most prevalent
> case since the ECN
> >>>>>>>> spec [RFC3168] was published in 2001.
> >>>>>>>> -->
> >>>>>>>>
> >>>>>>>>
> >>>>>>>> 13) <!--[rfced] Per RFC 5865, should "Voice-Admit" be
> "VOICE-ADMIT" (1 instance)?
> >>>>>>>>
> >>>>>>>> Original:
> >>>>>>>> specific Diffserv codepoints that indicate traffic
> with limited
> >>>>>>>> burstiness such as the EF (Expedited Forwarding
> [RFC3246]),
> >>>>>>>> Voice-Admit [RFC5865] or proposed NQB (Non-Queue-Building
> >>>>>>>> [I-D.ietf-tsvwg-nqb]) service classes or equivalent
> >>>>>>>> local-use DSCPs (see [I-D.briscoe-tsvwg-l4s-diffserv]).
> >>>>>>>>
> >>>>>>>> Perhaps:
> >>>>>>>> specific Diffserv codepoints that indicate traffic
> with limited
> >>>>>>>> burstiness such as EF [RFC3246], VOICE-ADMIT [RFC5865], or
> >>>>>>>> proposed Non-Queue-Building (NQB) [NQB-PHB] service
> classes or
> >>>>>>>> equivalent Local-use DSCPs (see [L4S-DIFFSERV]).
> >>>>>>>> -->
> >>>>>>>>
> >>>>>>>>
> >>>>>>>> 14) <!--[rfced] FYI, we changed "to an L4S identifier" to
> "of an L4S identifier"
> >>>>>>>> for clarity. Please review whether that changes the
> intended meaning.
> >>>>>>>>
> >>>>>>>> Original:
> >>>>>>>> In order to include non-L4S packets in the L queue, a
> network node
> >>>>>>>> MUST NOT alter Not-ECT or ECT(0) in the IP-ECN field
> to an L4S
> >>>>>>>> identifier.
> >>>>>>>>
> >>>>>>>> Current:
> >>>>>>>> In order to include non-L4S packets in the L queue, a
> network node
> >>>>>>>> MUST NOT alter Not-ECT or ECT(0) in the IP-ECN field
> of an L4S
> >>>>>>>> identifier.
> >>>>>>>> -->
> >>>>>>>>
> >>>>>>>>
> >>>>>>>> 15) <!--[rfced] Does "not necessarily completely
> regularly" mean "not
> >>>>>>>> necessarily on a regular basis"?
> >>>>>>>>
> >>>>>>>> Original:
> >>>>>>>> Nonetheless, an application can be considered safe
> enough if
> >>>>>>>> it paces packets out (not necessarily completely
> regularly)
> >>>>>>>> such that its maximum instantaneous rate from packet to
> >>>>>>>> packet stays well below a typical broadband access rate.
> >>>>>>>>
> >>>>>>>> Perhaps:
> >>>>>>>> Nonetheless, an application can be considered safe
> enough if
> >>>>>>>> it paces packets out (not necessarily on a regular basis)
> >>>>>>>> such that its maximum instantaneous rate from packet to
> >>>>>>>> packet stays well below a typical broadband access rate.
> >>>>>>>> -->
> >>>>>>>>
> >>>>>>>>
> >>>>>>>> 16) <!--[rfced] Please clarify what "that" refers to in
> the following:
> >>>>>>>>
> >>>>>>>> Original:
> >>>>>>>> However, queuing delay in the L queue will probably
> rise to that
> >>>>>>>> controlled by the Classic (drop-based) AQM.
> >>>>>>>> -->
> >>>>>>>>
> >>>>>>>>
> >>>>>>>> 17) <!--[rfced] RFC 3168 only mentions "ECT(0)" and "ECT(1)",
> >>>>>>>> not "ECT0" and "ECT1". Should this sentence be updated?
> >>>>>>>>
> >>>>>>>> Original:
> >>>>>>>> Defining ECT(1) as the L4S identifier introduces a
> difference between
> >>>>>>>> the effects of ECT0 and ECT1 that RFC 3168 previously
> defined as
> >>>>>>>> distinct but with equivalent effect.
> >>>>>>>> -->
> >>>>>>>>
> >>>>>>>>
> >>>>>>>> 18) <!--[rfced] The following quote is not a direct quote
> from RFC 8257.
> >>>>>>>> Please let us know how this text be updated for accuracy.
> >>>>>>>>
> >>>>>>>> Original:
> >>>>>>>> In the particular case of DCTCP, the DCTCP
> >>>>>>>> specification [RFC8257] states that "It is RECOMMENDED
> that an
> >>>>>>>> implementation deal with loss episodes in the same way as
> >>>>>>>> conventional TCP." For safe deployment, Section 4.3
> requires any
> >>>>>>>> specification of a scalable congestion control for the
> public
> >>>>>>>> Internet to define the above requirement as a "MUST".
> >>>>>>>>
> >>>>>>>> Perhaps you intended to quote this sentence in Section
> 3.5 of RFC 8257?
> >>>>>>>>
> >>>>>>>> A DCTCP sender MUST react to loss episodes in the same
> way as
> >>>>>>>> conventional TCP, including fast retransmit and fast
> recovery
> >>>>>>>> algorithms, as specified in [RFC5681].
> >>>>>>>> -->
> >>>>>>>>
> >>>>>>>>
> >>>>>>>> 19) <!--[rfced] A "third approach" is mentioned here.
> Will it be clear to
> >>>>>>>> readers what the first and second approaches are? Please
> clarify.
> >>>>>>>>
> >>>>>>>> Original:
> >>>>>>>> Even though a bottleneck is L4S capable, it might
> still become
> >>>>>>>> overloaded and have to drop packets. In this case, the
> sender may
> >>>>>>>> receive a high proportion of packets marked with the
> CE bit set and
> >>>>>>>> also experience loss. Current DCTCP implementations
> each react
> >>>>>>>> differently to this situation. At least one
> implementation reacts
> >>>>>>>> only to the drop signal (e.g., by halving the CWND)
> and at least
> >>>>>>>> another DCTCP implementation reacts to both signals
> (e.g., by
> >>>>>>>> halving the CWND due to the drop and also further
> reducing the CWND
> >>>>>>>> based on the proportion of marked packet). A third
> approach for the
> >>>>>>>> public Internet has been proposed that adjusts the
> loss response to
> >>>>>>>> result in a halving when combined with the ECN response.
> >>>>>>>>
> >>>>>>>> Perhaps:
> >>>>>>>> [...] Current DCTCP implementations each react
> differently
> >>>>>>>> to this situation. One approach (used by at least one
> implementation)
> >>>>>>>> is to react only to the drop signal (e.g., by halving
> the CWND);
> >>>>>>>> another approach (used by at least one implementation)
> is to
> >>>>>>>> react to both signals [...]. A third approach for the
> public
> >>>>>>>> Internet has been proposed ...
> >>>>>>>> -->
> >>>>>>>>
> >>>>>>>>
> >>>>>>>> 20) <!--[rfced] Since there are multiple expansions for
> "CDN",
> >>>>>>>> is "Content Delivery Network" correct here?
> >>>>>>>>
> >>>>>>>> Original:
> >>>>>>>> This allows for the possibility that the operator of
> an L4S
> >>>>>>>> sender (e.g. a CDN) might prefer to test out-of-band for
> >>>>>>>> signs of Classic ECN AQMs,...
> >>>>>>>>
> >>>>>>>> Current:
> >>>>>>>> This allows for the possibility that the operator of
> an L4S
> >>>>>>>> sender (e.g., a Content Delivery Network (CDN)) might
> prefer
> >>>>>>>> to test out-of-band for signs of Classic ECN AQMs,...
> >>>>>>>> -->
> >>>>>>>>
> >>>>>>>>
> >>>>>>>> 21) <!--[rfced] We added "its" for clarity and rephrased
> "ex-ToS byte" to
> >>>>>>>> "former Type-of-Service (ToS) byte" in order to include the
> >>>>>>>> expansion of "ToS". Please let us know if you prefer
> otherwise.
> >>>>>>>>
> >>>>>>>> Original:
> >>>>>>>> Also, not changing codepoint avoids the risk of being
> >>>>>>>> flipped to a different path by a load balancer or
> multipath routing
> >>>>>>>> that hashes on the whole of the ex-ToS byte
> (unfortunately still a
> >>>>>>>> common pathology).
> >>>>>>>>
> >>>>>>>> Current:
> >>>>>>>> Also, not changing its codepoint avoids the risk of being
> >>>>>>>> flipped to a different path by a load balancer or
> multipath routing
> >>>>>>>> that hashes on the whole of the former Type-of-Service
> (ToS) byte (which is
> >>>>>>>> unfortunately still a common pathology).
> >>>>>>>> -->
> >>>>>>>>
> >>>>>>>>
> >>>>>>>> 22) <!--[rfced] Since there is typically a space between
> the digit and unit of
> >>>>>>>> measure, is it acceptable to insert spacing in the
> following functions?
> >>>>>>>>
> >>>>>>>> Original:
> >>>>>>>> rtt_virt = max(rtt, 25ms)
> >>>>>>>>
> >>>>>>>> rtt_virt = rtt + 10ms
> >>>>>>>>
> >>>>>>>> Perhaps:
> >>>>>>>> rtt_virt = max(rtt, 25 ms)
> >>>>>>>>
> >>>>>>>> rtt_virt = rtt + 10 ms
> >>>>>>>> -->
> >>>>>>>>
> >>>>>>>>
> >>>>>>>> 23) <!--[rfced] Would you like to add "in item 4 of
> Section 4.3"
> >>>>>>>> so the reader knows where this particular wording came from?
> >>>>>>>>
> >>>>>>>> Original:
> >>>>>>>> Therefore, rather than requiring strict
> RTT-independence, the
> >>>>>>>> wording says "as independent of RTT as possible without
> >>>>>>>> compromising stability or utilization".
> >>>>>>>>
> >>>>>>>> Perhaps:
> >>>>>>>> Therefore, rather than requiring strict
> RTT-independence, the
> >>>>>>>> wording in item 4 of Section 4.3 is "as independent of
> RTT as
> >>>>>>>> possible without compromising stability or utilization".
> >>>>>>>> -->
> >>>>>>>>
> >>>>>>>>
> >>>>>>>> 24) <!--[rfced] FYI: We removed "for RDMA" from this
> sentence since
> >>>>>>>> "RDMA" is included in the expansion of "RoCEv2"; please
> let us
> >>>>>>>> know any concerns.
> >>>>>>>>
> >>>>>>>> Original:
> >>>>>>>> As mentioned above, hardware implementations of loss
> recovery using
> >>>>>>>> DupACK counting exist (e.g. some implementations of
> RoCEv2 for
> >>>>>>>> RDMA).
> >>>>>>>>
> >>>>>>>> Current:
> >>>>>>>> As mentioned above, hardware implementations of loss
> recovery using
> >>>>>>>> DupACK counting exist (e.g., some implementations of
> Remote Direct
> >>>>>>>> Memory Access over Converged Ethernet version 2 (RoCEv2).
> >>>>>>>> -->
> >>>>>>>>
> >>>>>>>>
> >>>>>>>> 25) <!--[rfced] May the following sentence be rephrased
> for clarity
> >>>>>>>> (specifically, "every 8x scaling of Cubic's flow rate")?
> >>>>>>>>
> >>>>>>>> Original:
> >>>>>>>> Even when out of its Reno-compatibility mode, every 8x
> scaling of
> >>>>>>>> Cubic's flow rate leads to 2x more acceleration delay.
> >>>>>>>>
> >>>>>>>> Perhaps:
> >>>>>>>> Even when out of its Reno-compatibility mode, if
> CUBIC's flow
> >>>>>>>> rate scales by 8 times, it leads to 2 times more
> acceleration delay.
> >>>>>>>> -->
> >>>>>>>>
> >>>>>>>>
> >>>>>>>> 26) <!--[rfced] Is the spacing intentional for
> "150,151,152" or should
> >>>>>>>> spacing be added for consistency?
> >>>>>>>>
> >>>>>>>> Original:
> >>>>>>>> For example consider N=3, and consider the sequence of
> >>>>>>>> packets 100, 101, 102, 103,... and imagine that packets
> >>>>>>>> 150,151,152 from later in the flow are injected as
> follows:
> >>>>>>>> 100, 150, 151, 101, 152, 102, 103... If this were late
> >>>>>>>> reordering,
> >>>>>>>>
> >>>>>>>> Perhaps:
> >>>>>>>> For example, consider N=3, and consider the sequence of
> >>>>>>>> packets 100, 101, 102, 103,... Imagine that packets
> >>>>>>>> 150, 151, 152 from later in the flow are injected as
> follows:
> >>>>>>>> 100, 150, 151, 101, 152, 102, 103,... If this were late
> >>>>>>>> reordering, even one packet arriving out of...
> >>>>>>>> -->
> >>>>>>>>
> >>>>>>>>
> >>>>>>>> 27) <!--[rfced] Is "to cater for" accurate wording here,
> or would
> >>>>>>>> "to handle" or "as it does not allow for" or otherwise be
> more clear?
> >>>>>>>>
> >>>>>>>> Original:
> >>>>>>>> However, in some VPN implementations the maximum
> anti-replay window
> >>>>>>>> is insufficient to cater for a large delay difference
> at prevailing
> >>>>>>>> packet rates.
> >>>>>>>>
> >>>>>>>> Perhaps:
> >>>>>>>> However, in some VPN implementations, the maximum
> anti-replay window
> >>>>>>>> is insufficient to handle a large delay difference at
> >>>>>>>> prevailing packet rates.
> >>>>>>>> -->
> >>>>>>>>
> >>>>>>>>
> >>>>>>>> 28) <!--[rfced] Usage of 'round' in 'work-rounds', 'safe
> way round', and
> >>>>>>>> 'passed correctly round' reads oddly for those not
> familiar with this
> >>>>>>>> British variant of 'around'. Please consider updating the
> phrases for
> >>>>>>>> readability.
> >>>>>>>> For example:
> >>>>>>>> alternative work-arounds
> >>>>>>>> the safe way around
> >>>>>>>> passed correctly around
> >>>>>>>> -->
> >>>>>>>>
> >>>>>>>>
> >>>>>>>> 29) <!--[rfced] FYI, as per the mail from Bob Briscoe on
> 2022-09-12, British English
> >>>>>>>> spelling has been selected by the authors. Specifically,
> he wrote:
> >>>>>>>> "(Oxford variant with -ize, -ization but -yse)"
> >>>>>>>> So, we have updated the document accordingly, changing
> instances of
> >>>>>>>> "neutralise", "standardisation", etc.
> >>>>>>>> -->
> >>>>>>>>
> >>>>>>>>
> >>>>>>>> 30) <!-- [rfced] Throughout the text, the following
> terminology appears to be used
> >>>>>>>> inconsistently. Please review these occurrences and let
> us know if/how
> >>>>>>>> they may be made consistent.
> >>>>>>>>
> >>>>>>>> queue per flow vs. per-flow queue
> >>>>>>>> [Note: is "queue per flow" the same as "per-flow
> queue"?
> >>>>>>>> If so, we will use the latter form.]
> >>>>>>>>
> >>>>>>>>
> >>>>>>>> TCP-Reno-friendly (2 instances) vs. Reno-friendly
> >>>>>>>> [Note: should these terms be the same, or are they
> different?
> >>>>>>>> Section 1.2 mentions that "Reno-friendly" replaces
> "TCP-friendly"
> >>>>>>>>
> >>>>>>>> Also, should "Reno-compatibility mode" be "Reno-friendly
> mode"?
> >>>>>>>> [The former term does not appear in RFC-to-be 9330.]
> >>>>>>>>
> >>>>>>>> FYI, we used the latter forms below to match use in the
> companion
> >>>>>>>> document or referenced RFCs:
> >>>>>>>>
> >>>>>>>> Cubic -> CUBIC (per RFC 8312)
> >>>>>>>> Coupled DualQ AQM -> DualQ Coupled AQM
> >>>>>>>> Scalable -> scalable (but capitalized when part of a term)
> >>>>>>>> -->
> >>>>>>>>
> >>>>>>>>
> >>>>>>>> 31) <!-- [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.
> >>>>>>>> -->
> >>>>>>>>
> >>>>>>>>
> >>>>>>>> 32) <!--[rfced] We see a number of author-inserted
> comments in the XML file of
> >>>>>>>> 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.
> >>>>>>>> -->
> >>>>>>>>
> >>>>>>>>
> >>>>>>>> Thank you.
> >>>>>>>>
> >>>>>>>> RFC Editor/kc/ar
> >>>>>>>>
> >>>>>>>>
> >>>>>>>> On Nov 18, 2022,
> >>>>>>>> rfc-editor@rfc-editor.org
> >>>>>>>> wrote:
> >>>>>>>>
> >>>>>>>> *****IMPORTANT*****
> >>>>>>>>
> >>>>>>>> Updated 2022/11/18
> >>>>>>>>
> >>>>>>>> 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
> >>>>>>>>
> >>>>>>>> *
> >>>>>>>> rfc-editor@rfc-editor.org
> >>>>>>>> (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).
> >>>>>>>>
> >>>>>>>> *
> >>>>>>>> auth48archive@rfc-editor.org
> >>>>>>>> , 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,
> >>>>>>>> auth48archive@rfc-editor.org
> >>>>>>>> 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/rfc9331.xml
> >>>>>>>>
> >>>>>>>> https://www.rfc-editor.org/authors/rfc9331.html
> >>>>>>>>
> >>>>>>>> https://www.rfc-editor.org/authors/rfc9331.pdf
> >>>>>>>>
> >>>>>>>> https://www.rfc-editor.org/authors/rfc9331.txt
> >>>>>>>>
> >>>>>>>>
> >>>>>>>> Diff file of the text:
> >>>>>>>> https://www.rfc-editor.org/authors/rfc9331-diff.html
> >>>>>>>>
> >>>>>>>> https://www.rfc-editor.org/authors/rfc9331-rfcdiff.html
> >>>>>>>> (side by side)
> >>>>>>>>
> >>>>>>>> Diff of the XML:
> >>>>>>>> https://www.rfc-editor.org/authors/rfc9331-xmldiff1.html
> >>>>>>>>
> >>>>>>>>
> >>>>>>>> [removed extraneous links]
> >>>>>>>>
> >>>>>>>> Tracking progress
> >>>>>>>> -----------------
> >>>>>>>>
> >>>>>>>> The details of the AUTH48 status of your document are here:
> >>>>>>>> https://www.rfc-editor.org/auth48/rfc9331
> >>>>>>>>
> >>>>>>>>
> >>>>>>>> Please let us know if you have any questions.
> >>>>>>>>
> >>>>>>>> Thank you for your cooperation,
> >>>>>>>>
> >>>>>>>> RFC Editor
> >>>>>>>>
> >>>>>>>> --------------------------------------
> >>>>>>>> RFC9331 (draft-ietf-tsvwg-ecn-l4s-id-29)
> >>>>>>>>
> >>>>>>>> Title : The Explicit Congestion Notification
> (ECN) Protocol for Low Latency, Low Loss, and Scalable Throughput
> (L4S)
> >>>>>>>> Author(s) : K. De Schepper, B. Briscoe, Ed.
> >>>>>>>> WG Chair(s) : Gorry Fairhurst, David L. Black,
> Marten Seemann
> >>>>>>>>
> >>>>>>>> Area Director(s) : Martin Duke, Zaheduzzaman Sarker
> >>>>>>>>
> >>>>>>> --
> >>>>>>>
> ________________________________________________________________
> >>>>>>> Bob Briscoe
> >>>>>>> http://bobbriscoe.net/
> >>>>>>>
> <rfc9331c.xml><rfc9331c-DIFF-a.html><rfc9331b-DIFF-a.html><rfc9331c-DIFF-b.html><rfc9331c-DIFF-draft-ietf-tsvwg-ecn-l4s-id-29.html>
> >>>>> --
> >>>>> ________________________________________________________________
> >>>>> Bob Briscoe http://bobbriscoe.net/
> >>>>>
> <rfc9331e.xml><rfc9331e-from-d.diff.html><rfc9331e-from-draft-ietf-tsvwg-ecn-l4s-id-29.diff.html>
> >>> --
> >>> ________________________________________________________________
> >>> Bob Briscoe http://bobbriscoe.net/
> >>> <rfc9331g.xml><rfc9331g-from-f.diff.html>
> >
> > --
> > ________________________________________________________________
> > Bob Briscoe http://bobbriscoe.net/
> >
>
--
________________________________________________________________
Bob Briscoehttp://bobbriscoe.net/
- [auth48] [C350] AUTH48: RFC-to-be 9331 <draft-iet… rfc-editor
- [auth48] [AD] Re: [C350] AUTH48: RFC-to-be 9331 <… rfc-editor
- Re: [auth48] [AD] Re: [C350] AUTH48: RFC-to-be 93… Bob Briscoe
- Re: [auth48] [AD] Re: [C350] AUTH48: RFC-to-be 93… Martin Duke
- Re: [auth48] [AD] [C350] AUTH48: RFC-to-be 9331 <… Karen Moore
- Re: [auth48] [AD] Re: [C350] AUTH48: RFC-to-be 93… Bob Briscoe
- Re: [auth48] [AD] [C350] AUTH48: RFC-to-be 9331 <… Karen Moore
- Re: [auth48] [AD] [C350] AUTH48: RFC-to-be 9331 <… Karen Moore
- Re: [auth48] [AD] [C350] AUTH48: RFC-to-be 9331 <… Bob Briscoe
- Re: [auth48] [AD] [C350] AUTH48: RFC-to-be 9331 <… Karen Moore
- Re: [auth48] [AD] [C350] AUTH48: RFC-to-be 9331 <… Bob Briscoe
- [auth48] [AD] [C350] AUTH48: RFC-to-be 9331 <draf… Karen Moore
- Re: [auth48] [AD] [C350] AUTH48: RFC-to-be 9331 <… Bob Briscoe
- Re: [auth48] [AD] [C350] AUTH48: RFC-to-be 9331 <… Karen Moore
- Re: [auth48] [AD] [C350] AUTH48: RFC-to-be 9331 <… Bob Briscoe
- [auth48] [AD] [C350] AUTH48: RFC-to-be 9331 <draf… Karen Moore
- Re: [auth48] [AD] [C350] AUTH48: RFC-to-be 9331 <… Martin Duke
- Re: [auth48] [AD] [C350] AUTH48: RFC-to-be 9331 <… Bob Briscoe
- Re: [auth48] [AD] [C350] AUTH48: RFC-to-be 9331 <… Martin Duke
- Re: [auth48] [AD] [C350] AUTH48: RFC-to-be 9331 <… Bob Briscoe
- Re: [auth48] [AD] [C350] AUTH48: RFC-to-be 9331 <… Gorry Fairhurst
- Re: [auth48] [AD] [C350] AUTH48: RFC-to-be 9331 <… Bob Briscoe
- Re: [auth48] [AD] [C350] AUTH48: RFC-to-be 9331 <… Martin Duke
- Re: [auth48] [AD] [C350] AUTH48: RFC-to-be 9331 <… Martin Duke
- Re: [auth48] [AD] [C350] AUTH48: RFC-to-be 9331 <… Bob Briscoe
- Re: [auth48] [AD] [C350] AUTH48: RFC-to-be 9331 <… Bob Briscoe
- Re: [auth48] [AD] [C350] AUTH48: RFC-to-be 9331 <… Koen De Schepper (Nokia)
- Re: [auth48] [AD] [C350] AUTH48: RFC-to-be 9331 <… Bob Briscoe
- Re: [auth48] [AD] [C350] AUTH48: RFC-to-be 9331 <… Karen Moore
- Re: [auth48] [AD] [C350] AUTH48: RFC-to-be 9331 <… Martin Duke
- Re: [auth48] [AD] [C350] AUTH48: RFC-to-be 9331 <… Karen Moore
- [auth48] [C350] AUTH48: RFC-to-be 9331 <draft-iet… Karen Moore
- Re: [auth48] [C350] AUTH48: RFC-to-be 9331 <draft… Bob Briscoe