Authors, This is another 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]
