Authors, This is a friendly reminder that we await your replies to our questions as well as the separate email on 10/28/25 regarding IANA.
The files are available here: https://www.rfc-editor.org/authors/rfc9897.xml https://www.rfc-editor.org/authors/rfc9897.html https://www.rfc-editor.org/authors/rfc9897.pdf https://www.rfc-editor.org/authors/rfc9897.txt Diff file of the text: https://www.rfc-editor.org/authors/rfc9897-diff.html https://www.rfc-editor.org/authors/rfc9897-rfcdiff.html (side by side) Diff of the XML: https://www.rfc-editor.org/authors/rfc9897-xmldiff1.html Best regards, Karen Moore RFC Production Center > On Oct 27, 2025, at 11:01 PM, [email protected] wrote: > > Authors, > > While reviewing this document during AUTH48, please resolve (as necessary) > the following questions, which are also in the source file. > > 1) <!--[rfced] Please note that the title has been updated as > follows. The abbreviation has been expanded per Section 3.6 of > RFC 7322 ("RFC Style Guide"). Please review. > > Original: > DCCP Extensions for Multipath Operation with Multiple Addresses > > Current: > Datagram Congestion Control Protocol (DCCP) Extensions for > Multipath Operation with Multiple Addresses > --> > > > 2) <!-- [rfced] Please insert any keywords (beyond those that appear in > the title) for use on https://www.rfc-editor.org/search. --> > > > 3) <!--[rfced] Please clarify what "This" refers to in the following > sentence - is it "These fundamentals"? > > Current: > This also applies to the DCCP sequencing scheme, which is > packet-based (Section 4.2 of [RFC4340]) and the principles for loss > and retransmission of features as described in more detail in > Section 6.6.3 of [RFC4340]. > > Perhaps: > These fundamentals also apply to the DCCP sequencing scheme, which is > packet-based (Section 4.2 of [RFC4340]), and to the principles for > loss and retransmission of features as described in more detail in > Section 6.6.3 of [RFC4340]. > --> > > > 4) <!--[rfced] Please clarify the latter part of this sentence, > specifically "between" and the slash ("/"). Is the intended > meaning that hybrid access networks combine access between the > user equipment "or" residential gateway "and" an operator network > (option A) or is it between the user equipment "and" a > residential gateway within an operator network (option B)? > > Original: > In addition to the integration into DCCP services, implementers or > future specification could choose MP-DCCP for other use cases like > 3GPP 5G multi-access solutions (e.g., Access Traffic Steering, > Switching, and Splitting (ATSSS) specified in [TS23.501]) or hybrid > access networks that either combine a 3GPP and a non-3GPP access or a > fixed and cellular access between user-equipment/residential gateway > and operator network. > > Perhaps A: > In addition to the integration into DCCP services, implementers or > future specifications could choose MP-DCCP for other use cases such > as 3GPP 5G multi-access solutions (e.g., Access Traffic Steering, > Switching, and Splitting (ATSSS) as specified in [TS23.501]) or > hybrid access networks that combine either 3GPP and non-3GPP access > or fixed and cellular access between the user equipment or > residential gateway and an operator network. > > or > Perhaps B: > In addition to the integration into DCCP services, implementers or > future specifications could choose MP-DCCP for other use cases such > as 3GPP 5G multi-access solutions (e.g., Access Traffic Steering, > Switching, and Splitting (ATSSS) as specified in [TS23.501]) or > hybrid access networks that combine either 3GPP and non-3GPP access > or fixed and cellular access between the user equipment and > residential gateway within an operator network. > --> > > > 5) <!--[rfced] Section 3.1: Would you like to add text to introduce > the numbered list that immediately follows Figure 4? > > Original: > 1. The Client indicates support for both MP-DCCP versions 1 and 0, > with a preference for version 1. > > 2. Server agrees on using MP-DCCP version 1 indicated by the first > value, and supplies its own preference list with the following > values. > > 3. MP-DCCP is then enabled between the Client and Server with > version 1. > > Perhaps: > This example illustrates the following: > > 1. The Client indicates support for both MP-DCCP versions 1 and 0, > with a preference for version 1. > > 2. The Server agrees on using MP-DCCP version 1 indicated by the first > value and supplies its own preference list with the following > values. > > 3. MP-DCCP is then enabled between the Client and Server with > version 1. > --> > > > 6) <!--[rfced] Table 4: May we update these IANA-registered descriptions as > follows for clarity? If so, we will ask IANA to update the registry > accordingly. (Also, they will be updated in Table 8.) > > Original: > MP_OPT=7 MP_ADDADDR Advertise additional address(es)/port(s) > MP_OPT=8 MP_REMOVEADDR Remove address(es)/port(s) > > Perhaps: > MP_OPT=7 MP_ADDADDR Advertise one or more additional addresses/ports > MP_OPT=8 MP_REMOVEADDR Remove one or more addresses/ports > --> > > > 7) <!--[rfced] May we rephrase this sentence for improved readability? > > Original: > This could happen if a datagram with MP_PRIO and a first MP_SEQ_1 > and another datagram with MP_ADDADDR and a second MP_SEQ_2 are > received in short succession. > > Perhaps: > This could happen if the following are received in short > succession: a datagram with MP_PRIO and a first MP_SEQ_1 and > another datagram with MP_ADDADDR and a second MP_SEQ_2. > --> > > > 8) <!--[rfced] Figure Titles > > a) Should the titles of Figures 7 and 8 include "MP_CONFIRM" > (instead of "MP-DCCP CONFIRM") to match the content in the > figures? > > Note that the running text refers to the procedure as "MP-DCCP > confirm" - should the running text be updated as well for consistency? > Please let us know if "MP_CONFIRM", "MP-DCCP CONFIRM", or other is > preferred. > > Current (Figure 7): > Example MP-DCCP CONFIRM Procedure > > Perhaps: > Example MP_CONFIRM Procedure > > ... > Current (Figure 8) > Example MP-DCCP CONFIRM Procedure with an Outdated Suboption > > Perhaps: > Example MP_CONFIRM Procedure with an Outdated Suboption > > > b) Should the title of Figure 22 perhaps be "Example MP_ADDADDR > Procedure" rather than "Example MP-DCCP ADDADDR Procedure" to match > the content in the figure? We note that "MP-DCCP ADDADDR" is not used > in the running text. > > Current: > Example MP-DCCP ADDADDR Procedure > > Perhaps: > Example MP_ADDADDR Procedure > > c) Should the title of Figure 23 perhaps be "Example MP_ADDADDR > Procedure" rather than "Example MP-DCCP REMOVEADDR Procedure" to match > the content in the figure? We note that "MP-DCCP REMOVEADDR" is not > used in the running text. > > Current: > Example MP-DCCP REMOVEADDR Procedure > > Perhaps: > Example MP_REMOVEADDR Procedure > --> > > > 9) <!--[rfced] We note that Figures 9, 11, and 19 are listed first within > their sections without any lead-in text. Is this intended, or > would you like to add a lead-in sentence for consistency with the > other sections? > --> > > > 10) <!--[rfced] Per RFCs 2119 and 8174, may we update "REQUIRES" to > "REQUIRED" for correctness as shown below? > > Original: > The MP_JOIN option is used to add a new subflow to an existing MP- > DCCP connection and REQUIRES a successful establishment of the first > subflow using MP_KEY. > > Perhaps: > The MP_JOIN option is used to add a new subflow to an existing MP- > DCCP connection, and a successful establishment of the first > subflow using MP_KEY is REQUIRED. > --> > > > 11) <!--[rfced] Please clarify this sentence, specifically "from the both > hosts Key Data". > > Original: > Together with the derived key from the both hosts > Key Data described in Section 3.2.4, the Nonce value builds the basis > to calculate the HMAC used in the handshaking process as described in > Section 3.3 to avoid replay attacks. > > Perhaps: > Together with the derived key from both hosts that exchange > Key Data as described in Section 3.2.4, the Nonce value builds the basis > to calculate the Hash-based Message Authentication Code (HMAC) used in > the handshaking process described in Section 3.3 to avoid replay attacks. > > Or: > Together with the derived key from both hosts' > Key Data (as described in Section 3.2.4), the Nonce value builds the basis > to calculate the Hash-based Message Authentication Code (HMAC) used in the > handshaking process (as described in Section 3.3) to avoid replay attacks. > --> > > > 12) <!--[rfced] In Section 3.2.6, the text refers to the > "second and third step" of the handshake, so should the list > in Section 3.3 be an ordered list instead of a bulleted list as > shown below? > > Section 3.2.6: > In addition, it provides authentication for subflows joining an > existing MP_DCCP connection, as described in the second and third > step of the handshake of a subsequent subflow in Section 3.3. > > Original (Section 3.3): > The basic initial handshake for the first subflow is as follows: > > * Host A sends a DCCP-Request with the MP-Capable feature Change > request and the MP_KEY option with a Host-specific CI-A and a KeyA > for each of the supported key types as described in Section 3.2.4. > CI-A is a unique identifier during the lifetime of an MP-DCCP > connection. > > * Host B sends a DCCP-Response with Confirm feature for MP-Capable > and the MP_Key option with a unique Host-specific CI-B and a > single Host-specific KeyB. The type of the key is chosen from the > list of supported types from the previous request. > > * Host A sends a DCCP-Ack to confirm the proper key exchange. > > * Host B sends a DCCP-Ack to complete the handshake and set both > connection ends to the OPEN state. > > Perhaps (Section 3.3): > The basic initial handshake for the first subflow is as follows: > > 1. Host A sends a DCCP-Request with the MP-Capable feature change > request and the MP_KEY option with a Host-specific CI-A and a KeyA > for each of the supported key types as described in Section 3.2.4. > CI-A is a unique identifier during the lifetime of an MP-DCCP > connection. > > 2. Host B sends a DCCP-Response with a Confirm feature for MP-Capable > and the MP_Key option with a unique Host-specific CI-B and a > single Host-specific KeyB. The type of the key is chosen from the > list of supported types from the previous request. > > 3. Host A sends a DCCP-Ack to confirm the proper key exchange. > > 4. Host B sends a DCCP-Ack to complete the handshake and set both > connection ends to the OPEN state. > --> > > > 13) <!--[rfced] May we reword this sentence for better readability as > shown below? Note that this sentence appears in Sections 3.2.8 > and 3.2.9. > > Original: > In the same way as for MP_JOIN, the key for the HMAC algorithm, in > the case of the message transmitted by Host A, will be d-KeyA, and > in the case of Host B, d-KeyB. > > Perhaps: > Similar to MP_JOIN, the key for the HMAC algorithm will be d-KeyA > when the message is transmitted by Host A and d-KeyB when > transmitted by Host B. > --> > > > 14) <!-- [rfced] FYI: For consistency with the other figures, we fixed the > bit ruler on Figure 18. (We extended the right side of the box by one > space so that the placement of the final "1" is over the minus sign > rather than the plus sign.) Please let us know if this is not accurate. > --> > > > 15) <!--[rfced] Section 3.2.10. Please confirm if "Cellular paths" should > be singular in the first sentence below, as we note the singular > form in the sentence that follows as well as in use cases #2 and #3. > > Original: > 1. Setting Wi-Fi path to Primary and Cellular paths to Secondary. > In this case Wi-Fi will be used and Cellular will be used only > if the Wi-Fi path is congested or not available. > > Perhaps: > 1. Setting the Wi-Fi path to Primary and Cellular path to Secondary. > In this case, Wi-Fi will be used and Cellular will be used only > if the Wi-Fi path is congested or not available. > --> > > > 16) <!--[rfced] Please clarify "and MUST be the appropriate one" - is > "appropriate one" essential to the sentence, or could it be > reworded as "the path MUST have the highest available priority > value" as shown below? > > Original: > In the case of path mobility (Section 3.11.1), only one path can be > used at a time and MUST be the appropriate one that has the highest > available priority value including also the prio numbers 1 and 2. > > Perhaps: > In the case of path mobility (Section 3.11.1), only one path can be > used at a time, and the path MUST have the highest available > priority value that includes the prio numbers 1 and 2. > --> > > > 17) <!--[rfced] Please clarify "in by"; is the intended meaning included > "in" or "by" the MP_CLOSE option? Also, should the second "must" > be "MUST"? > > Original: > To protect from unauthorized shutdown of a multi-path connection, > the selected Key Data of the peer host during the handshaking > procedure MUST be included in by the MP_CLOSE option and must be > validated by the peer host. > > Perhaps (if "in"): > To protect from unauthorized shutdown of a multipath connection, > the selected Key Data of the peer host MUST be included in the > MP_CLOSE option during the handshaking procedure and MUST be > validated by the peer host. > --> > > > 18) <!--[rfced] We are having trouble parsing this sentence. Please > clarify what items "between" refers to. > > Original: > Note, the Key Data is different between MP_CLOSE option carried > by DCCP-CloseReq or DCCP-Close. > --> > > > 19) <!--[rfced] Figure 20: May we change "Data TBD" to simply "Data", > as shown below? It is already explained directly below the figure: > "The Data field can carry any data..." > > We note that "TBD" is used for a different purpose (in Table 3) > to refer to the option length being "TBD" when the option type is >11. > > Original: > |0 0 1 0 1 1 1 0| var |0 0 0 0 1 0 1 1| Data TBD | > > Perhaps: > |0 0 1 0 1 1 1 0| var |0 0 0 0 1 0 1 1| Data | > --> > > > 20) <!--[rfced] FYI, in Figure 21, "DCCP-ACK" has been updated to > "DCCP-Ack" to match usage in the rest of the document. > --> > > > 21) <!--[rfced] What does "own" refer to in "own random nonce RA"? > > Original: > Additionally, an own random nonce RA is transmitted > with the MP_JOIN. > --> > > > 22) <!--[rfced] In Section 3.3, is "message" the "HMAC Message" and "key" > the "Key" described in Section 3.2.6? If so, should these terms > be capitalized as shown below? Note that there is similar text in > the paragraph that follows (which refers to MP_JOIN(B)"). > > Original: > As specified in Section 3.2.6, the HMAC is calculated by taking the > leftmost 20 bytes from the SHA256 hash of a HMAC code created by > using the nonce received with MP_JOIN(A) and the local nonce RB as > message and the derived key described in Section 3.2.4 as key: > > Perhaps: > As specified in Section 3.2.6, the HMAC is calculated by taking the > leftmost 20 bytes from the SHA256 hash of an HMAC code that is > created by using both the nonce received with MP_JOIN(A) and the > local nonce RB as the Message and the derived key as the Key, as > described in Section 3.2.4: > --> > > > 23) <!--[rfced] May we reword this sentence for improved readability? > > Original: > The states transitioned when moving from the CLOSED to OPEN state > during the four-way handshake remain the same as for DCCP, but it is > no longer possible to transmit application data while in the REQUEST > state. > > Perhaps: > When the state moves from CLOSED to OPEN during the 4-way > handshake, the transitioned states remain the same as for DCCP, but > it is no longer possible to transmit application data while in the > REQUEST state. > --> > > > 24) <!--[rfced] Is "aspect of" essential to this sentence or may it be > removed? > > Original: > Likewise, the host that wants to create the subflows is RECOMMENDED > to consider the aspect of available resources and the possible > gains. > > Perhaps: > Likewise, it is RECOMMENDED that the host that wants to create the > subflows considers the available resources and possible gains. > --> > > > 25) <!--[rfced] FYI: We added semicolons to this list for better > readability. Please let us know if you prefer otherwise. > > Original: > This can be a dynamic process further facilitated by the means of > DCCP and MP-DCCP defined options such as path preference using > MP-PRIO, adding or removing DCCP subflows using MP_REMOVEADDR, > MP_ADDADDR or DCCP- Close/DCCP-Reset and also path metrics such as > packet-loss-rate, CWND or RTT provided by the Congestion Control > Algorithm. > > Current: > This can be a dynamic process further facilitated by the means of > DCCP and MP-DCCP-defined options such as path preference using > MP-PRIO; adding or removing DCCP subflows using MP_REMOVEADDR, > MP_ADDADDR, or DCCP-Close/DCCP-Reset; and path metrics such as > packet loss rate, congestion window (CWND), or RTT provided by > the Congestion Control Algorithm. > --> > > > 26) <!--[rfced] Does "SHOULD" refer only to the first part of this > sentence? And does "if not available" refer to the "path > priority"? If so, may we rephrase the text as shown below for > clarity? > > Original: > This process SHOULD respect the path priority configured by the MP_PRIO > suboption or if not available pick the most divergent source- > destination pair from the original used source-destination pair. > > Perhaps: > This process SHOULD respect the path priority configured by the > MP_PRIO suboption; otherwise, if the path priority is not > available, pick the most divergent source-destination pair from > the originally used source-destination pair. > --> > > > 27) <!-- [rfced] Should "Section 4" be "Section 3.6" where the fallback > scenario is discussed? Note that this sentence occurs in Section 4. > > Current: > Depending on the security requirements, different Key Types can be > negotiated in the handshake procedure or must follow the fallback > scenario described in Section 4. > > Perhaps: > Depending on the security requirements, different Key Types can be > negotiated in the handshake procedure or must follow the fallback > scenario described in Section 3.6. > --> > > > 28) <!-- [rfced] We note that RFC 4043 does not contain Section 16. Please > confirm which section should be referenced. > > Current: > DCCP already provides means to mitigate the potential impact of > middleboxes, in comparison to TCP (see Section 16 of [RFC4043]). > --> > > > 29) <!--[rfced] We have included some clarifications about the IANA text > below. In addition, please review all of the IANA-related updates > carefully and let us know if any further updates are needed. > > a) FYI: We updated "auth." to "authentication" in Tables 3 and 8 > as there is enough space to write it out. We will ask IANA to update > the description in the "Multipath Options" registry accordingly. > > Original: > Hash-based message auth. code for MP-DCCP > > Current: > Hash-based message authentication code for MP-DCCP > > b) FYI: We have updated the headings in Tables 6 and 7 to match > the headings listed in the "Feature Numbers" and "MP-DCCP > Versions" registries, respectively > <https://www.iana.org/assignments/dccp-parameters/>. > --> > > > 30) <!-- [rfced] We found the URL > <https://dl.acm.org/doi/10.1145/2413176.2413178> from the ACM > Digital Library. Would you like us to update this reference with > this URL as shown below? > > Current: > [OLIA] Khalili, R., Gast, N., Popovic, M., Upadhyay, U., and J. > Le Boudec, "MPTCP is not pareto-optimal: performance > issues and a possible solution", CoNEXT '12: Proceedings > of the 8th international conference on Emerging networking > experiments and technologies, pp. 1-12, December 2012. > > Perhaps: > [OLIA] Khalili, R., Gast, N., Popovic, M., Upadhyay, U., and J. > Le Boudec, "MPTCP is not pareto-optimal: performance > issues and a possible solution", CoNEXT '12: Proceedings > of the 8th international conference on Emerging networking > experiments and technologies, pp. 1-12, December 2012, > <https://dl.acm.org/doi/10.1145/2413176.2413178>. > --> > > > 31) <!-- [rfced] Terminology > > a) 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. > > CLOSED state vs. CLOSE state vs. CLOSING state > > Client and Server vs. client and server (as well as 'the client and the > server') > > Congestion Control procedure vs. congestion control scheme > [Note: Should the case be made the same for these terms?] > > "Fast Close" vs. fast close > [Note: Should the first mention in quotes be "fast close" > for consistency?] > > Feature number 10 vs. feature number 10 > Length vs. length > handshake procedure/process vs. handshaking procedure/process > Key Type vs. Key types vs. key type > Multipath Capability vs. multipath capability > Multipath feature vs. multipath feature > Multipath option vs. multipath option vs. MP option > > Multipath Capable Feature vs. Multipath Capable feature vs. MP-Capable > feature > vs. MP_CAPABLE feature > > Nonce vs. nonce > Plain Text Key (Table 5) vs. Plain text key (Table 9) > Reset Code vs. reset code > Remove Address vs. Remove address (Tables 3 and 8) > > SHA256 vs. SHA-256 > [Note: "SHA256" is consistent in this document; however, "SHA-256" is > hyphenated > in the running text and some descriptions in RFC 6234; are any updates > needed > in this document for consistency with that RFC?] > > b) FYI: We updated the following terms to the form on the right for > consistency: > > address ID -> Address ID > age -> Age > Change request -> change request (per all other RFCs) > DCCP Connections -> DCCP connections > four-way -> 4-way > host A -> Host A > IP Address -> IP address > key data -> Key Data > maximum segment lifetime -> Maximum Segment Lifetime > multi-path -> multipath > UDP Encapsulation -> UDP encapsulation (per RFC 6773) > NAT Traversal -> NAT traversal (per RFC 6773) > --> > > > 32) <!-- [rfced] Abbreviations > > a) FYI - We have added expansions for the following abbreviations > per Section 3.6 of RFC 7322 ("RFC Style Guide"). Please review each > expansion in the document carefully to ensure correctness. > > command-line interface (CLI) > congestion window (CWND) > Path MTU (PMTU) > pebibytes (PiBs) > Stream Control Transmission Protocol (SCTP) > > b) We note the following variations. Do you prefer the expansion to > contain the hyphen or no hyphen? > > Multipath-DCCP (MP-DCCP) vs. Multipath DCCP (MP-DCCP) > > c) As recommended in the Web Portion of the Style Guide > <https://www.rfc-editor.org/styleguide/part2/#exp_abbrev>, once an > abbreviation is introduced, the abbreviated form should be used > thereafter. Please consider if you would like to apply this style for > the following terms (i.e., replace the expansion with the abbreviated > form on the right): > > Connection Identifier -> CI > Multipath DCCP -> MP-DCCP > --> > > > 33) <!-- [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. > > For example, please consider whether "traditionally" should be updated for > clarity. > > While the NIST website > <https://web.archive.org/web/20250214092458/https://www.nist.gov/nist-research-library/ > nist-technical-series-publications-author-instructions#table1> > indicates that this term is potentially biased, it is also ambiguous. > "Tradition" is a subjective term, as it is not the same for everyone. > --> > > > Thank you. > > Karen Moore and Alice Russo > RFC Production Center > > > On Oct 27, 2025, [email protected] wrote: > > *****IMPORTANT***** > > Updated 2025/10/27 > > 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 > > * [email protected] (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). > > * [email protected], 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, > [email protected] 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/rfc9897.xml > https://www.rfc-editor.org/authors/rfc9897.html > https://www.rfc-editor.org/authors/rfc9897.pdf > https://www.rfc-editor.org/authors/rfc9897.txt > > Diff file of the text: > https://www.rfc-editor.org/authors/rfc9897-diff.html > https://www.rfc-editor.org/authors/rfc9897-rfcdiff.html (side by side) > > Diff of the XML: > https://www.rfc-editor.org/authors/rfc9897-xmldiff1.html > > > Tracking progress > ----------------- > > The details of the AUTH48 status of your document are here: > https://www.rfc-editor.org/auth48/rfc9897 > > Please let us know if you have any questions. > > Thank you for your cooperation, > > RFC Editor > > -------------------------------------- > RFC9897 (draft-ietf-tsvwg-multipath-dccp-24) > > Title : DCCP Extensions for Multipath Operation with Multiple > Addresses > Author(s) : M. Amend, Ed., A. Brunstrom, A. Kassler, V. Rakocevic, S. > Johnson > WG Chair(s) : Martin Duke, Zaheduzzaman Sarker > Area Director(s) : Gorry Fairhurst, Mike Bishop > -- auth48archive mailing list -- [email protected] To unsubscribe send an email to [email protected]
