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

[Karen Moore <[e-mail]>]

Hi Bob,

Thank you for the note. Indeed, this is a big document, so please take your time for the review. We’ll be here whenever you are ready! 

Best regards,

RFC Editor/kc

> On 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/
>