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
