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

[Martin Duke <[e-mail]>]

Changes in -30 LGTM

On Tue, Nov 22, 2022 at 8:54 AM Bob Briscoe <[e-mail]> wrote:

> Hi,
>
> Thanks for all the edits. As it's taking a while to work through it all,
> I thought I had better ack your email, so you know we're still alive.
>
> Bob
>
> On 18/11/2022 22:57, [e-mail] 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, [e-mail] 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
> >
> >    *  [e-mail] (the RPC team)
> >
> >    *  other document participants, depending on the stream (e.g.,
> >       IETF Stream participants are your working group chairs, the
> >       responsible ADs, and the document shepherd).
> >
> >    *  [e-mail], which is a new archival mailing list
> >       to preserve AUTH48 conversations; it is not an active discussion
> >       list:
> >
> >      *  More info:
> >
> https://mailarchive.ietf.org/arch/msg/ietf-announce/yb6lpIGh-4Q9l2USxIAe6P8O4Zc
> >
> >      *  The archive itself:
> >         https://mailarchive.ietf.org/arch/browse/auth48archive/
> >
> >      *  Note: If only absolutely necessary, you may temporarily opt out
> >         of the archiving of messages (e.g., to discuss a sensitive
> matter).
> >         If needed, please add a note at the top of the message that you
> >         have dropped the address. When the discussion is concluded,
> >         [e-mail] will be re-added to the CC list and
> >         its addition will be noted at the top of the message.
> >
> > You may submit your changes in one of two ways:
> >
> > An update to the provided XML file
> > — OR —
> > An explicit list of changes in this format
> >
> > Section # (or indicate Global)
> >
> > OLD:
> > old text
> >
> > NEW:
> > new text
> >
> > You do not need to reply with both an updated XML file and an explicit
> > list of changes, as either form is sufficient.
> >
> > We will ask a stream manager to review and approve any changes that seem
> > beyond editorial in nature, e.g., addition of new text, deletion of text,
> > and technical changes.  Information about stream managers can be found in
> > the FAQ.  Editorial changes do not require approval from a stream
> manager.
> >
> >
> > Approving for publication
> > --------------------------
> >
> > To approve your RFC for publication, please reply to this email stating
> > that you approve this RFC for publication.  Please use ‘REPLY ALL’,
> > as all the parties CCed on this message need to see your approval.
> >
> >
> > Files
> > -----
> >
> > The files are available here:
> >    https://www.rfc-editor.org/authors/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/
>
>