Authors, Regarding your document in AUTH48 state (https://www.rfc-editor.org/authors/rfc9897.html), this is a reminder that we await your reply to the questions below (same as [1]), as well as the proposed IANA updates in [2].
[1] https://mailarchive.ietf.org/arch/msg/auth48archive/GQKj_4dsRi_lSZecM2iKhXy-IYU/ [2] https://mailarchive.ietf.org/arch/msg/auth48archive/hzU5A0zD9E2vIKanGmJU5mw4Zzc/ Thank you. Alice Russo RFC Production Center > On Nov 21, 2025, at 11:22 AM, Karen Moore <[email protected]> wrote: > > 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]
