Hi Martin, Thanks for sending this change along. We have rolled it into the current versions (see links below). We have also updated the AUTH48 status page to include your approval. Once we hear approval from Gorry, this document will be ready to move forward in the publication process.
The files have been posted here (please refresh): https://www.rfc-editor.org/authors/rfc9743.txt https://www.rfc-editor.org/authors/rfc9743.pdf https://www.rfc-editor.org/authors/rfc9743.html https://www.rfc-editor.org/authors/rfc9743.xml The relevant diff files have been posted here (please refresh): https://www.rfc-editor.org/authors/rfc9743-diff.html (comprehensive diff) https://www.rfc-editor.org/authors/rfc9743-rfcdiff.html (comprehensive side by side) https://www.rfc-editor.org/authors/rfc9743-auth48diff.html (AUTH48 changes only) https://www.rfc-editor.org/authors/rfc9743-auth48rfcdiff.html (AUTH48 changes in side by side) Please contact us with any further updates/questions/comments you may have. We will await approvals from each of the parties listed on the AUTH48 status page prior to moving forward to publication. The AUTH48 status page for this document is available here: https://www.rfc-editor.org/auth48/rfc9743 Thank you. RFC Editor/mf > On Mar 4, 2025, at 1:18 PM, Martin Duke <martin.h.d...@gmail.com> wrote: > > One nit: > In Section 5.2.1, please replace "not TCP friendly" with "not Reno friendly". > > Whether or not you concur with the change, I approve publication. > > I messed with my gmail filters and appear to be getting your email again. > > Martin > > On Tue, Mar 4, 2025 at 11:36 AM Megan Ferguson > <mfergu...@staff.rfc-editor.org> wrote: > Hi Gorry (and Martin) and Zahed, > > Thanks for your careful review, guidance, and replies thus far. > > We have updated according to your replies. Please review the files carefully > as we have made slight tweaks where necessary and we do not make changes > after publication. > > The files have been posted here (please refresh): > https://www.rfc-editor.org/authors/rfc9743.txt > https://www.rfc-editor.org/authors/rfc9743.pdf > https://www.rfc-editor.org/authors/rfc9743.html > https://www.rfc-editor.org/authors/rfc9743.xml > > The relevant diff files have been posted here (please refresh): > https://www.rfc-editor.org/authors/rfc9743-diff.html (comprehensive diff) > https://www.rfc-editor.org/authors/rfc9743-rfcdiff.html (comprehensive > side by side) > https://www.rfc-editor.org/authors/rfc9743-auth48diff.html (AUTH48 changes > only) > https://www.rfc-editor.org/authors/rfc9743-auth48rfcdiff.html (AUTH48 > changes in side by side) > > Please contact us with any further updates/questions/comments you may have. > > We will await approvals from each of the parties listed on the AUTH48 status > page prior to moving forward to publication. > > The AUTH48 status page for this document is available here: > > https://www.rfc-editor.org/auth48/rfc9743 > > Thank you. > > RFC Editor/mf > > > > On Mar 1, 2025, at 2:42 AM, Gorry Fairhurst <go...@erg.abdn.ac.uk> wrote: > > > > Thanks for doing this - It is good to get this precise as a BCP, and we > > have replies to your questions (see below), and also a few extra requests. > > > > Martin and I have coordinated, but he'll chime-in if there any additional > > requests. > > > > Best wishes, > > Gorry > > > > --- > > > > Authors and *AD, > > > > While reviewing this document during AUTH48, please resolve (as necessary) > > the following questions, which are also in the XML file. > > > > 1) <!--[rfced] *ADs - As this document obsoletes RFC 5033, should it be > > added to BCP 133? We have updated as such; please let us know > > any objections. --> > > > > GF> I think it ought to be added to it. > > > > 2) <!--[rfced] While we understand RFC 5033 was published > > with some of the text we are questioning below, the questions and > > edits are aimed at making the text as correct and useful to the reader > > as possible. Please review carefully. > > > > In addition, this document is in the current RFC format (a major change was > > made in 2019), so various updates have been made in the source file. > > Details are here: https://www.rfc-editor.org/pubprocess/how-we-update. > > --> > > > > > > 3) <!-- [rfced] Please insert any keywords (beyond those that appear in > > the title) for use on https://www.rfc-editor.org/search. > > --> > > > > GF> I suggest adding: Transport, CC. > > > > 4) <!--[rfced] Might this update to the Abstract be of interest? It > > attempts to reduce redundancy and reorganize the sentences > > slightly. > > > > Original: > > > > This document replaces RFC 5033, which discusses the principles and > > guidelines for standardizing new congestion control algorithms. It > > seeks to ensure that proposed congestion control algorithms operate > > without harm and efficiently alongside other algorithms in the global > > Internet. It emphasizes the need for comprehensive testing and > > validation to prevent adverse interactions with existing flows. This > > document provides a framework for the development and assessment of > > congestion control mechanisms, promoting stability across diverse > > network environments. It obsoletes RFC5033 to reflect changes in > > the congestion control landscape. > > > > Perhaps: > > > > RFC 5033 discusses the principles and guidelines for standardizing > > new congestion control algorithms. This document obsoletes RFC > > 5033 to reflect changes in the congestion control landscape by > > providing a framework for the development and assessment of > > congestion control mechanisms, promoting stability across diverse > > work environments. This document aims to describe ways that > > proposed congestion control algorithms can operate both without > > harm and efficiently alongside other algorithms in the global > > Internet. It emphasizes the need for comprehensive testing and > > validation to prevent adverse interactions with existing flows. > > --> > > > > GF> I think this doesn't precisely capture what was intended, would this be > > acceptable: > > > > RFC 5033 discusses the principles and guidelines for standardizing > > new congestion control algorithms. This document obsoletes RFC > > 5033 to reflect changes in the congestion control landscape by > > providing a framework for the development and assessment of > > congestion control mechanisms, promoting stability across diverse > > network paths. > > The document seeks to ensure that proposed congestion control algorithms > > operate > > efficiently and without harm when used in the global > > Internet. It emphasizes the need for comprehensive testing and > > validation to prevent adverse interactions with existing flows. > > -- > > > > 5) <!-- [rfced] We note that [HRX08] states it was published in 2008. May > > we update the text below accordingly? > > > > Original: > > CUBIC was documented in a research publication in 2007 [HRX08], and > > was then adopted as the default congestion control algorithm for > > the TCP implementation in Linux. > > > > Perhaps: > > CUBIC was documented in a research publication in 2008 [HRX08], and > > was then adopted as the default congestion control algorithm for > > the TCP implementation in Linux. > > --> > > GF> OK: Please do align with the reference. > > --- > > 6) <!--[rfced] Would one of the following suggestions be agreeable in > > order to clarify this document's journey? > > > > Original: > > It was already used in a significant fraction of TCP connections over > > the Internet before being documented in an Informational > > Internet-Draft in 2015, published as an Informational RFC in 2017 as > > [RFC8312] and then as a Proposed Standard in 2023 [RFC9438]. > > > > Perhaps A: > > It was already used in a significant > > fraction of TCP connections over the Internet before being published as an > > Informational RFC in 2017 as [RFC8312] and then as a Proposed > > Standard in 2023 [RFC9438]. > > > > Perhaps B: > > It was already used in a significant fraction of TCP connections over > > the Internet before being documented in an Internet-Draft in 2015, > > and published as an Informational RFC in 2017 as [RFC8312] > > and then as a Proposed Standard in 2023 [RFC9438]. > > > > --> > > GF> Option B (above) seems correct. > > --- > > 7) <!--[rfced] Note that we have removed "IRTF" from the following text. > > It doesn't appear to us that an IRTF RG adopted this draft (we > > see the first two versions as individual submissions and the last > > as an IETF document). Please review. > > > > Original: > > It was described in an IRTF Internet-Draft in 2018, and that > > Internet-Draft is regularly updated to document the > > evolving versions of the algorithm [BBR-draft]. > > > > Current: > > It was described in an Internet-Draft in 2018, which has been > > regularly updated to document the evolving versions of the algorithm > > [BBR]. > > --> > > GF> I think this doesn't precisely capture what was intended, would this be > > acceptable: > > BBR was described in an Internet-Draft in 2018 and was first presented > > in the IRTF internet congestion control research group. > > It has since been > > regularly updated to document the evolving versions of the algorithm > > [BBR]. > > > > --- > > > > 8) <!-- [rfced] May we update the third bullet below for consistency with > > the other bulleted items? > > > > Original: > > > > Nevertheless, a specification for a congestion control algorithm > > provides a number of advantages: > > > > * It can help implementers, operators, and other interested parties > > develop a shared understanding of how the algorithm works and how > > it is expected to behave in various scenarios and configurations. > > > > * It can help potential contributors understand the algorithm, which > > can make it easier for them to suggest improvements and/or > > identify limitations. Furthermore, the specification can help > > multiple contributors align on a consensus change to the > > algorithm. > > > > * A specification that is accessible to anyone can circumvent the > > issue that some implementers may be unable to read open source > > reference implementations due to the constraints of some open > > source licenses. > > > > Perhaps: > > > > > > Nevertheless, a specification for a congestion control algorithm > > provides a number of advantages: > > > > ... > > > > * It can help (by being accessible to anyone) to circumvent the issue that > > some implementers may be unable to read open-source reference > > implementations due to the constraints of some open-source licenses. > > > > --> > > GF> OK > > --- > > 9) <!--[rfced] Might this update reduce redundancy? > > > > Original: > > Evidence of results is normally considered by the working group in > > deciding if a specification is ready for publication and ought to be > > documented in any request for the working group to publish the > > specification. > > > > Perhaps: > > Any request for a working group to consider a specification for > > publication ought to document evidence of results. > > > > --> > > GF> That doesn't capture it, we suggest: > > > > When a working group is seeking to decide if a proposed > > specification is ready for publication, it will normaly consider > > evidence of results. This ought to be > > documented in any request from the working group to publish the > > specification. > > --- > > > > 10) <!--[rfced] May we make this update for accuracy/clarity? > > > > Original: > > Publication might occur without multiple implementations if a single > > implementation is widely used, open source, and shown to have > > positive impact on the Internet, particularly if the target status is > > Experimental. > > > > Perhaps: > > A congestion control algorithm without multiple implementations > > might still be published as an RFC if a single implementation is > > widely used, open source, and shown to have a positive impact on > > the Internet, particularly if the target status is Experimental. > > --> > > GF> OK. > > > > --- > > > > 11) <!--[rfced] Please carefully review our updates to Section 3.2. As > > much of this section is about RFCs themselves and the publication > > process, we have made a number of changes to attempt to improve > > clarity and to align the style of terminology with past RFCs and > > in-house guidance on such topics. Please let us know any > > objections or further updates to be made. > > --> > > > > GF> Your update looks good to me. > > --- > > 12) <!--[rfced] This text left us wondering what happens to algorithms > > that are not targeted at general use? What status can they seek? > > Perhaps further info would be helpful to the reader? > > > > Original: > > Congestion control algorithms without empirical evidence of > > Internet-scale deployment MUST seek Experimental status, unless they > > are not targeted at general use. > > > > --> > > GF> Please add this after the original text: > > > > NEW: > > Algorithms not targeted at general use do not require internet-scale data. > > > > --- > > 13) <!--[rfced] In the following, we assume that RFC 4614 should remain as > > the cited document even though it has been obsoleted. > > Please note that we have added mention of the obsoleting document > > as well as an Informative References entry for the ease of the > > reader. > > Original: > > Section 4 of [RFC4614] provides other examples of extensions that were > > considered experimental when the specification was > > published. > > > > Current: > > Section 4 of [RFC4614] provides other examples of extensions that were > > considered experimental when the specification was > > published (note that [RFC4614] has since been obsoleted by > > [RFC7414]). > > --> > > > > GF> We suggest replacing the current text by > > NEW: > > Section 4 of [RFC7414] provides other examples of extensions that were > > considered experimental when the specification was > > published. > > --- > > > > 14) <!-- [rfced] > > > > Original: > > In evaluating a new proposal for use in a controlled environment, > > the IETF needs to understand the usage, e.g., how the usage is > > scoped to the controlled environment, whether the algorithm will > > share resources with Internet traffic, and consider what could > > happen if used in a protocol that is bridged across an Internet > > path. > > > > Perhaps: > > In evaluating a new proposal for use in a controlled environment, > > the IETF community needs to understand the usage (e.g., how the usage is > > scoped to the controlled environment), whether the algorithm will > > share resources with Internet traffic, and what could > > happen if used in a protocol that is bridged across an Internet > > path. > > > > --> > > GF> OK. > > --- > > 15) <!--[rfced] Does the suggested text capture your intended meaning? > > > > Original: > > Instead, the community will use these evaluations as an input when > > considering whether to progress the proposed algorithm. > > > > Perhaps: > > Instead, the community will use these evaluations as an input when > > considering whether to progress the proposed algorithm specification > > in the publication process. > > --> > > GF> OK. > > > > 16) <!-- [rfced] We were unable to find "Reno" explicitly mentioned in RFC > > 5681 as seen in the text below: > > > > Original: > > > > The standards-track Reno [RFC5681] and CUBIC [RFC9438] > > congestion control algorithms send at progressively higher rates > > until a First-In First-Out (FIFO) buffer completely fills... > > > > However, it does appear in RFCs 5681 and 6582 in the reference > > below. Should the reference to RFC 5681 be adjusted to [FF96]? [FF96] > > is now available at this URL: > > https://dl.acm.org/doi/10.1145/235160.235162 > > > >> From RFC 5681: > > > > [FF96] Fall, K. and S. Floyd, "Simulation-based Comparisons of > > Tahoe, Reno and SACK TCP", Computer Communication Review, > > July 1996, ftp://ftp.ee.lbl.gov/papers/sacks.ps.Z. > > > >> From RFC 6582: > > > > "For the typical implementation of the TCP fast recovery algorithm > > described in [RFC5681] (first implemented in the 1990 BSD Reno > > release, and referred to as the "Reno algorithm" in [FF96])..." > > > > --> > > GF> Please don't change the reference. I believe the method specified in > > RFC5681 is widely known in the community as "Reno". We ought to refer to it > > as such. > > --- > > > > 17) <!-- [rfced] FYI - We have reworked the text below into a bulleted > > list for ease of the reader and updated to use didactic > > caps. Please review and let us know any objections. > > > > Original: > > > > Among the AQM techniques that might have an impact on a proposed > > congestion control algorithm are Flow Queue CoDel (FQ-CoDel) > > [RFC8290]; Proportional Integral Controller Enhanced (PIE) [RFC8033]; > > and Low Latency, Low Loss, and Scalable Throughput (L4S) [RFC9332]. > > > > Current: > > > > Some of the AQM techniques that might have an impact on a proposed > > congestion control algorithm include: > > > > * Flow Queue CoDel (FQ-CoDel) [RFC8290]; > > > > * Proportional Integral controller Enhanced (PIE) [RFC8033]; and > > > > * Low Latency, Low Loss, and Scalable Throughput (L4S) [RFC9332]. > > > > --> > > GF> OK, thanks. > > > > --- > > 18) <!-- [rfced] We note that ECT is most often expanded to "ECN-Capable > > Transport (ECT)" (as was done in normative reference RFC 9902). > > Would you like to update this expansion to match the usage in > > RFC 9902? > > > > Original: > > A proposed congestion control algorithm that sets one of the two > > Explicit Congestion Transport (ECT) codepoints in the IP header can > > gain the benefits of receiving Explicit Congestion Notification (ECN) > > Congestion Experienced (CE) signals from an on-path AQM [RFC8087]. > > > > Perhaps: > > A proposed congestion control algorithm that sets one of the two > > ECN-Capable Transport (ECT) codepoints in the IP header can gain the > > benefits of receiving Explicit Congestion Notification-Congestion > > Experienced (ECN-CE) signals from an on-path AQM [RFC8087]. > > > > --> > > GF> OK. > > > > 19) <!-- [rfced] FYI - For readability, we have reformatted the text below > > to read as a bulleted list. Please review and let us know any objections. > > > > Original: > > > > As an example from an Experimental RFC, performance with misbehaving > > nodes and outside attackers is discussed in Sections 9.4, 9.5, and > > 9.6 of [RFC4782]. This includes discussion of misbehaving senders > > and receivers; collusion between misbehaving routers; misbehaving > > middleboxes; and the potential use of Quick- Start to attack routers > > or to tie up available Quick-Start bandwidth. > > > > Current: > > > > As an example from an Experimental RFC, performance with misbehaving > > nodes and outside attackers is discussed in Sections 9.4, 9.5, and > > 9.6 of [RFC4782]. This includes discussion of: > > > > * misbehaving senders and receivers; > > > > * collusion between misbehaving routers; > > > > * misbehaving middleboxes; and > > > > * the potential use of Quick-Start to attack routers or to tie up > > available Quick-Start bandwidth. > > > > --> > > GF> The porposed change is OK. > > > > 20) <!-- [rfced] We had the following additional questions related to > > references and citations in the document: > > > > a.) [BUFFERBLOAT] Would you like to use the following URL for this > > reference (as this URL has a DOI and an open access PDF)? > > > > https://dl.acm.org/doi/10.1145/2063166.2071893 > > > > GF> Yes, please use this. > > > > b.) FYI - We have added the following RFCs to the Informative > > References section, as they are included in the text but were not > > cited as references. > > > > RFC 9293 > > RFC 4340 > > RFC 9260 > > RFC 9000 > > RFC 8257 > > > > --> > > > > GF> Thanks, OK. > > > > 21) <!--[rfced] Note that we have cut the "Evolution of RFC5033bis" > > section. Generally, change logs only exist in published RFCs in > > obsoleting documents as a "Changes Since RFC ####" section, which > > highlights the substantive changes that took place between the > > last published RFC and this one (i.e., mentions errata addressed or > > a security consideration that has changed, etc.). If the section > > should be kept, may we suggest something like: > > > > Perhaps: > > Changes Since RFC 5033 > > > > * Harmonized the "proposed congestion control algorithm" > > > > * Examined BCP 14 keywords and consistency with other RFCs > > > > * Added text on constrained environments/limited domains and circuit > > breakers and aligned with other RFCs > > > > * Added discussion of real-time protocols, short flows, AQM response, > > multipath transports > > > > * Listed properties of wired networks > > > > * Added sections addressing IoT and Multicast (noting this is out of scope) > > > > * Rewrote the "Document Status" section > > > > * Added improved first sentence of Abstract and Introduction > > > > * Reorganized central sections of the document > > > > * Added QUIC, other congestion control standards > > > > * Added wireless environments > > > > * Aligned motivation for this work with the CCWG charter > > > > * Refined discussion of Quick-Start > > > > * Included updated text suggested by Dave Taht > > > > * Added criterion for bufferbloat > > > > * Mentioned CUBIC and BBR as motivation > > > > --> > > GF> Thanks, I think this ought to be reduced. > > > > I suggest a shortened key changes section, as below > > > > NEW: > > > > Key Changes Since RFC 5033 > > > > * Examined BCP 14 keywords and consistency with other RFCs > > > > * Rewrote the "Document Status" section > > > > * Added QUIC, other more recent congestion control standards > > > > * Aligned motivation for this work with the CCWG charter > > > > * Refined discussion of Quick-Start > > > > * Added criterion for bufferbloat > > > > * Added text on constrained environments/limited domains and circuit > > breakers and aligned with other RFCs > > > > * Added discussion of real-time protocols, short flows, AQM response, > > multipath transports > > > > * Listed properties of wired and wireless networks > > > > * Added sections addressing IoT and Multicast (noting this is out of scope) > > > > --- > > > > 22) <!--[rfced] We note that there are a number of instances in which an > > algorithm or a proposed algorithm takes on human abilities. > > Please review the text with this in mind and let us know if any > > updates should be made. Some examples below (not exhaustive): > > > > Original: > > A proposed congestion control algorithm SHOULD explore... > > > > Perhaps: > > A proposal for a congestion control algorithm SHOULD explore... > > > > Original: > > A proposed congestion control algorithm ought not to presume... > > > > Perhaps: > > Authors of a proposed congestion control algorithm ought not to presume... > > > > Original: > > A proposed congestion control algorithm MUST clearly explain any > > deviations from [RFC2914] and [RFC7141]. > > > > Perhaps: > > A proposal for a congestion control algorithm MUST clearly explain any > > deviations from [RFC2914] and [RFC7141]. > > --> > > GF> All of these changes are OK. > > --- > > 23) <!-- [rfced] FYI - We have added expansions for abbreviations upon > > first use per Section 3.6 of RFC 7322 ("RFC Style Guide"). Please > > review each expansion in the document carefully to ensure > > correctness. > > > > Explicit Congestion Notification (ECN) Multipath TCP (MPTCP) > > --> > > GF> Thanks, OK. > > > > 24) <!-- [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. Updates of this > > nature typically result in more precise language, which is > > helpful for readers. > > > > Note that our script did not flag any words in particular, but this > > should still be reviewed as a best practice. --> > > > > GF> OK. > > > > Thank you. > > > > RFC Editor/kf/mf > > > > --- > > > > Additional issues > > > > ** Note: in 5.1.4: This change seems wrong. The proposer to the IETF needs > > to describe evaluation to advance a proposal. However, the specification > > when completed does NOT need to specify/document this, but might refer to a > > document that does this. > > > > ORIGINAL: > > the proposal should explore how the capacity is > > PROPOSED by RFC-ED: > > > > the specification should explore how the capacity > > > > GF> Please modify > > NEW: > > the evaluation should explore how the capacity > > ---- > > ** /on/of/. > > PROPOSED by RFC-ED: > > Specifications on congestion control algorithms > > NEW: > > Specifications of congestion control algorithms > > GF> Is this new text acceptable? > > --- > > ** /Sec 3.1 > > GF> "the Internet scale" sounds wrong to my ears. I don't care about the > > hyphen, but please lose the "the". > > OLD > > (within a limited domain or at Internet-scale) > > NEW > > (within a limited domain or at the Internet scale) > > --- > > ** Sec 5.1.2 > > GF> We prefer we avoid lower case should: > > OLD > > A congestion control algorithm should try to avoid maintaining excessive > > queues in the network. > > NEW > > A congestion control algorithm ought to try to avoid maintaining > > excessive queues in the network. > > --- > > ** Sec 5.1.2 > > GF> The grammar is now broken in a new sentence. I suggest this change > > OLD > > The Standards Track RFCs [RFC5681] and [RFC9438] describing the Reno and > > CUBIC congestion control algorithms (respectively) send at progressively > > higher rates until a First In, First Out (FIFO) buffer completely fills; > > then packet losses occur. > > NEW > > The Standards Track RFCs [RFC5681] and [RFC9438] describe the Reno and > > CUBIC congestion control algorithms (respectively), which send at > > progressively higher rates until a First In, First Out (FIFO) buffer > > completely fills; then packet losses occur. > > --- > > ** Sec 7.4 > > GF> Avoid lower-case "may" > > OLD > > Congestion control algorithms still may need to share the path with other > > flows with different constraints. > > NEW > > Congestion control algorithms still might need to share the path with other > > flows with different constraints. > > --- > > ** Sec 7.8 > > GF> The 'algorithm' doesn't need to consider anything, the designer does: > > > > OLD > > A proposed congestion control algorithm SHOULD consider how it would > > perform in the presence of transient events such as a sudden onset of > > congestion, a routing change, or a mobility event. > > NEW > > A proposal for a congestion control algorithm SHOULD consider how it would > > perform in the presence of transient events such as a sudden onset of > > congestion, a routing change, or a mobility event. > > --- > > END. > > > > *****IMPORTANT***** > > > > Updated 2025/02/26 > > > > 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-edi...@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/rfc9743.xml > > https://www.rfc-editor.org/authors/rfc9743.html > > https://www.rfc-editor.org/authors/rfc9743.pdf > > https://www.rfc-editor.org/authors/rfc9743.txt > > > > Diff file of the text: > > https://www.rfc-editor.org/authors/rfc9743-diff.html > > https://www.rfc-editor.org/authors/rfc9743-rfcdiff.html (side by side) > > > > Diff of the XML: https://www.rfc-editor.org/authors/rfc9743-xmldiff1.html > > > > > > Tracking progress > > ----------------- > > > > The details of the AUTH48 status of your document are here: > > https://www.rfc-editor.org/auth48/rfc9743 > > > > Please let us know if you have any questions. > > Thank you for your cooperation, > > > > RFC Editor > > > > -------------------------------------- > > RFC9743 (draft-ietf-ccwg-rfc5033bis-08) > > > > Title : Specifying New Congestion Control Algorithms > > Author(s) : M. Duke, G. Fairhurst > > WG Chair(s) : Eric Kinnear, Reese Enghardt > > > > Area Director(s) : Zaheduzzaman Sarker, Francesca Palombini > > > > > > > -- auth48archive mailing list -- auth48archive@rfc-editor.org To unsubscribe send an email to auth48archive-le...@rfc-editor.org
