Dear Gorry and Mike, Could you please help us reach the authors of RFC-to-be 9897 (aka draft-ietf-tsvwg-multipath-dccp-24)? AUTH48 was initiated on October 27, 2025, but we have yet to hear from them. Reminders have been sent on a weekly basis, but it is unclear whether they are receiving the mail.
Best regards, Karen Moore RPC Production Center > On Dec 2, 2025, at 1:21 PM, Alice Russo via auth48archive > <[email protected]> wrote: > > 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 Nov 14, 2025, at 11:55 AM, Karen Moore <[email protected]> >>> wrote: >>> >>> 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 Nov 7, 2025, at 11:59 AM, Karen Moore <[email protected]> >>>> wrote: >>>> >>>> Authors, >>>> >>>> This is a reminder that we await your replies to our questions (see below) >>>> 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] > -- auth48archive mailing list -- [email protected] To unsubscribe send an email to [email protected]
