Dear Karen, dear RFC editor team, With regard to 1) , I ask you to replace the occurrence of "man-in-the-middle" with "on-path attacker"
With regard to 2), I ask you to remove RFC5280 from the list of Informative References With regard to 3), I agree with both proposals, but I have not yet identified the changes in the Diff. I therefore ask you to adopt your proposals. With regard to 4), I say thank you. Regarding the keywords you requested in the previous e-mail, I would like to mention that I cannot yet find them in the XML structure. Br Markus > -----Ursprüngliche Nachricht----- > Von: Karen Moore <[email protected]> > Gesendet: Donnerstag, 11. Dezember 2025 04:10 > An: Amend, Markus <[email protected]>; [email protected]; > [email protected]; [email protected]; > [email protected] > Cc: [email protected]; [email protected]; [email protected]; > [email protected]; [email protected] > Betreff: Re: AUTH48: RFC-to-be 9897 <draft-ietf-tsvwg-multipath-dccp-24> > for your review > > Dear Markus, > > Thank you for ensuring consolidated feedback from your coauthors; we > appreciate the level of detail you put into your reply. We have updated our > files accordingly (see links to the files below). We have a few additional > questions. > > 1) With the addition of new text, there are two occurences of “man-in-the- > middle”. Per the "Inclusive Language" portion of the online Style Guide > <https://ww/ > w.rfc- > editor.org%2Fstyleguide%2Fpart2%2F%23inclusive_language&data=05%7C0 > 2%7CMarkus.Amend%40telekom.de%7C29d2ebc7c7a443e69f1008de3862 > d243%7Cbde4dffc4b604cf68b04a5eeb25f5c4f%7C0%7C0%7C6390101942 > 62023565%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIl > YiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D > %7C0%7C%7C%7C&sdata=sC7IR05r%2B8QWtd5QqPmv4tmnWAWe%2BcO0 > ipF9s1mIOHY%3D&reserved=0>, please let us know if any changes are needed > to this term. Updates of this nature typically result in more precise > language, > which is helpful for readers. > > Section 3.2.4: > MP-DCCP protects against some man-in-the-middle attacks as further > outlined in Section 4. > > Section 3.2.6: > MP-DCCP protects against some man-in-the-middle attacks as further > outlined in Section 4. > > 2) We note that [RFC5280] is not cited in the text. Would you like to add a > citation to the text or remove the reference entry from the Informative > References section? > > 3) We made the following instances of “length” uppercase. Please review and > let us know if this is correct or if any further updates are needed in the > running > text.. > > > If the term length refers to the Length data field of a header option, we > prefer the capitalisation of Length instead of length and ask you to adopt > this > > length of one byte --> Legth of one byte > a maximum length of 252 bytes --> a maximum Length of 252 bytes > > 4) FYI: We made the requested changes below as well as the IANA-related > updates to Tables 3, 5, 8, and 9. > > > - The text "However the definition of a path management method, in which > sequence and when subflows are created" was changed to "However the > definition of a path management method, in which sequence and subflows > are created". The word "when" was removed, but I think this is a mistake. > Perhaps if the word "and" is also be removed it can be ok, but we rather > prefer > to add "when" again. > > > > - The sentence "DCCP defines that if the checksum fails, the receiving > endpoint..." is replaced by "If the checksum fails as defined by the DCCP, the > receiving endpoint...". This changes the meaning of the sentence and we > suggest instead: > > New: "As defined by DCCP, if the checksum fails, the receiving endpoint..." > > > > - The affiliation of an author has changed because the university has been > renamed. We ask you to replace for the author Veselin Rakocevic the > affiliation > from > > OLD: City, University of London > > to > > NEW: City St George's, University of London > > > --Files-- > Note that it may be necessary for you to refresh your browser to view the > most recent version. Please review the document carefully to ensure > satisfaction as we do not make changes once it has been published as an RFC. > > Please contact us with any further updates or with your approval of the > document in its current form. We will await approvals from each author prior > to moving forward in the publication process. > > Updated XML file: > > https://www/ > .rfc- > editor.org%2Fauthors%2Frfc9897.xml&data=05%7C02%7CMarkus.Amend% > 40telekom.de%7C29d2ebc7c7a443e69f1008de3862d243%7Cbde4dffc4b60 > 4cf68b04a5eeb25f5c4f%7C0%7C0%7C639010194262050621%7CUnknow > n%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIl > AiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C0%7C%7C%7C&sd > ata=4HPdmcXXqy1VddLBzn10bOVe7ze2oAdq9ahIXEhFd4w%3D&reserved=0 > > Updated output files: > > https://www/ > .rfc- > editor.org%2Fauthors%2Frfc9897.txt&data=05%7C02%7CMarkus.Amend%4 > 0telekom.de%7C29d2ebc7c7a443e69f1008de3862d243%7Cbde4dffc4b604 > cf68b04a5eeb25f5c4f%7C0%7C0%7C639010194262062468%7CUnknown > %7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIl > AiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C0%7C%7C%7C&sd > ata=1OyWO%2FOk3ESi8fXOZyd11M%2FW4DY7B6bbjRLwzkXSJVw%3D&res > erved=0 > > https://www/ > .rfc- > editor.org%2Fauthors%2Frfc9897.pdf&data=05%7C02%7CMarkus.Amend% > 40telekom.de%7C29d2ebc7c7a443e69f1008de3862d243%7Cbde4dffc4b60 > 4cf68b04a5eeb25f5c4f%7C0%7C0%7C639010194262074159%7CUnknow > n%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIl > AiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C0%7C%7C%7C&sd > ata=6pJFnfGkJ1PhGeSNEAl6uOOZ09BB8vpfJQpIYu1Hhus%3D&reserved=0 > > https://www/ > .rfc- > editor.org%2Fauthors%2Frfc9897.html&data=05%7C02%7CMarkus.Amend > %40telekom.de%7C29d2ebc7c7a443e69f1008de3862d243%7Cbde4dffc4b6 > 04cf68b04a5eeb25f5c4f%7C0%7C0%7C639010194262085170%7CUnkno > wn%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCI > sIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C0%7C%7C%7C&s > data=I%2BvyQCqOl4PCWo6oTPexXGh2oVsxdHSiLHyv8VgztU8%3D&reserved > =0 > > Diff files showing all changes made during AUTH48: > > https://www/ > .rfc-editor.org%2Fauthors%2Frfc9897- > auth48diff.html&data=05%7C02%7CMarkus.Amend%40telekom.de%7C29d > 2ebc7c7a443e69f1008de3862d243%7Cbde4dffc4b604cf68b04a5eeb25f5c > 4f%7C0%7C0%7C639010194262096590%7CUnknown%7CTWFpbGZsb3d8 > eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOI > joiTWFpbCIsIldUIjoyfQ%3D%3D%7C0%7C%7C%7C&sdata=1rW%2F2QPTuFJx > rS0yv3fsAtVeAGgUgcMu3HMhZ1N5CzM%3D&reserved=0 > > https://www/ > .rfc-editor.org%2Fauthors%2Frfc9897- > auth48rfcdiff.html&data=05%7C02%7CMarkus.Amend%40telekom.de%7C2 > 9d2ebc7c7a443e69f1008de3862d243%7Cbde4dffc4b604cf68b04a5eeb25f > 5c4f%7C0%7C0%7C639010194262107718%7CUnknown%7CTWFpbGZsb3 > d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkF > OIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C0%7C%7C%7C&sdata=55t9Es9AmtI0 > 8AJb28NftRkiN1%2BtyWHSR%2FRj34GA4YU%3D&reserved=0 (side by side) > > Diff files showing all changes: > > https://www/ > .rfc-editor.org%2Fauthors%2Frfc9897- > diff.html&data=05%7C02%7CMarkus.Amend%40telekom.de%7C29d2ebc7c > 7a443e69f1008de3862d243%7Cbde4dffc4b604cf68b04a5eeb25f5c4f%7C0 > %7C0%7C639010194262119479%7CUnknown%7CTWFpbGZsb3d8eyJFbXB > 0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFp > bCIsIldUIjoyfQ%3D%3D%7C0%7C%7C%7C&sdata=lcZPpQWJ1o8j9xM0UUzB > mBCMULLhbphiXiRsJlAAj64%3D&reserved=0 > > https://www/ > .rfc-editor.org%2Fauthors%2Frfc9897- > rfcdiff.html&data=05%7C02%7CMarkus.Amend%40telekom.de%7C29d2ebc > 7c7a443e69f1008de3862d243%7Cbde4dffc4b604cf68b04a5eeb25f5c4f%7 > C0%7C0%7C639010194262141617%7CUnknown%7CTWFpbGZsb3d8eyJFb > XB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTW > FpbCIsIldUIjoyfQ%3D%3D%7C0%7C%7C%7C&sdata=MPJSQ3evKTVPXujzd5 > No7Qnni%2FHRadAqn8uUFRdFujY%3D&reserved=0 (side by side) > > For the AUTH48 status of this document, please see: > > https://www/ > .rfc- > editor.org%2Fauth48%2Frfc9897&data=05%7C02%7CMarkus.Amend%40tel > ekom.de%7C29d2ebc7c7a443e69f1008de3862d243%7Cbde4dffc4b604cf6 > 8b04a5eeb25f5c4f%7C0%7C0%7C639010194262153473%7CUnknown%7 > CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOi > JXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C0%7C%7C%7C&sdata= > 5XlvDM%2BF%2FpoDSIr%2BHjWKEWmi7MpRxohEU%2FLKHmOIOuc%3D&re > served=0 > > Best regards, > Karen Moore > RFC Production Center > > > > On Dec 9, 2025, at 12:25 AM, > [email protected] wrote: > > > > Dear RFC Editor team, Karen, Alice, > > > > I would like to apologise for the long response time, but we wanted to > ensure consolidated feedback. > > > > Thank you very much for your already applied changes in > https://www/ > .rfc-editor.org%2Fauthors%2Frfc9897- > rfcdiff.html&data=05%7C02%7CMarkus.Amend%40telekom.de%7C29d2ebc > 7c7a443e69f1008de3862d243%7Cbde4dffc4b604cf68b04a5eeb25f5c4f%7 > C0%7C0%7C639010194262164193%7CUnknown%7CTWFpbGZsb3d8eyJFb > XB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTW > FpbCIsIldUIjoyfQ%3D%3D%7C0%7C%7C%7C&sdata=OVGAa2iSk2jsV%2ByK > RWbOFyFxpe7pv6raqLf0btCQ4HU%3D&reserved=0 we agree with, except for > three instances: > > > > - The text "However the definition of a path management method, in which > sequence and when subflows are created" was changed to "However the > definition of a path management method, in which sequence and subflows > are created". The word "when" was removed, but I think this is a mistake. > Perhaps if the word "and" is also be removed it can be ok, but we rather > prefer > to add "when" again. > > > > - The sentence "DCCP defines that if the checksum fails, the receiving > endpoint..." is replaced by "If the checksum fails as defined by the DCCP, the > receiving endpoint...". This changes the meaning of the sentence and we > suggest instead: > > New: "As defined by DCCP, if the checksum fails, the receiving endpoint..." > > > > - The affiliation of an author has changed because the university has been > renamed. We ask you to replace for the author Veselin Rakocevic the > affiliation > from > > OLD: City, University of London > > to > > NEW: City St George's, University of London > > > > > > For the <!-- [rfced] ... --> marked comments, you will find our joint > > answers > as follows and we will be happy to provide a final review of the document > once they have been applied: > > > > With regard to 1), we, the authors, agree with your change. > > > > Regarding 2), the authors propose the following keywords to be added: > > <keyword>dccp</keyword> > > <keyword>extensions</keyword> > > <keyword>multipath</keyword> > > <keyword>multihomed</keyword> > > <keyword>subflow</keyword> > > <keyword>concurrent</keyword> > > <keyword>simultaneous</keyword> > > <keyword>mobility</keyword> > > <keyword>mpdccp</keyword> > > <keyword>mp-dccp</keyword> > > > > With regard to 3), we, the authors, agree with your text proposal and ask > you to adopt it. > > > > With regard to 4) we prefer our own proposal which better distinguish > between ATSSS and hybrid access use case: > > 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. ATSSS combines 3GPP and non-3GPP access > between the user equipment and an operator network, while hybrid access > combines fixed and cellular access between a residential gateway and an > operator network. > > > > With regard to 5), we, the authors, agree with your text proposal and ask > you to adopt it. > > > > With regard to 6), we, the authors, agree with your text proposal and ask > you to adopt it. > > > > With regard to 7), we, the authors, agree with your text proposal and ask > you to adopt it. > > > > With regard to 8), we, the authors, agree with your text proposal for all > Figures 7, 8, 22, 23 and ask you to adopt it. > > > > With regard to 9), we, the authors, prefer to have lead text before the > Figures 6, 9, 11, 12, 13, 14, 19 according to: > > > > - Fig 6: Please change the first two sentences in the first paragraph from > > > > Original: > > Some multipath options require confirmation from the remote peer (see > Table 4). Such options will be retransmitted by the sender until an > MP_CONFIRM is received or the confirmation of options is considered > irrelevant because the data contained in the options has already been replaced > by newer information. > > > > to NEW including a move of Figure 6: > > Some multipath options require confirmation from the remote peer (see > Table 4) for which MP_CONFIRM is specified. > > > >>> Figure 6 > > > > Multipath options which require confirmation will be retransmitted by the > sender until an MP_CONFIRM is received or the confirmation of options is > considered irrelevant because the data contained in the options has already > been replaced by newer information. > > > > - Fig 9: Please move Figure 9 after the first sentence > > > > Original: > > Figure 9 > > 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. The Connection Identifier (CI) is the one from the peer host, > which ... > > > > NEW: > > 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. > >>> Figure 9 > > The Connection Identifier (CI) is the one from the peer host, which ... > > > > - Fig 11: Please add the following guiding text and resolve the reference to > section 4 (Security Considerations) accordingly: > > NEW: MP-DCCP protects against some man in the middle attacks as further > outlined in [Section 4]. The basis of this protection is laid by an initial > exchange > of keys during the MP-DCCP connection setup, for which MP_KEY is > introduced. > > > > - Fig 12: Please add the following lead text and resolve the reference to > RFC4340 accordingly: > > NEW: DCCP [RFC4340] defines a packet sequencing scheme that continues > to apply to the individual DCCP subflows within an MP-DCCP connection. > However, for the operation of MP-DCPP, the order of packets within an MP- > DCCP connection MUST be known before assigning packets to subflows in > order to apply received multipath options in the correct order or to recognise > whether delayed multipath options are obsolete. Therefore MP_SEQ is > introduced and can also be used to re-order data packets on the receiver side. > > > > - Fig 13: Please add the following guiding text and resolve the reference to > section 4 (Security Considerations) accordingly: > > NEW: MP-DCCP protects against some man in the middle attacks as further > outlined in [Section 4]. Once an MP-DCCP connection has been established, > the MP_HMAC option introduced here provides further protection based on > the key material exchanged with MP_KEY when the connection is established. > > > > - Fig 14: Please move Figure 14 after the first paragraph > > > > Original: > > Figure 14 > > The MP_RTT suboption is used to transmit RTT values and Age (represented > in milliseconds) that belong to the path over which this information is > transmitted. This information is useful for the receiving host to calculate > the > RTT difference between the subflows and to estimate whether missing data > has been lost. > > > > NEW: > > The MP_RTT suboption is used to transmit RTT values and Age (represented > in milliseconds) that belong to the path over which this information is > transmitted. This information is useful for the receiving host to calculate > the > RTT difference between the subflows and to estimate whether missing data > has been lost. > >>> Figure 14 > > > > - Fig 19: Please add the following lead text and resolve the reference to > RFC4340 accordingly: > > NEW: The mechanism available in DCCP [RFC4340] for closing a connection > cannot give an indication for closing an MP-DCCP connection which typically > contains several DCCP subflows and therefore one cannot conclude from the > closing of a subflow to the closing of an MP-DCCP connection. This is solved > by introducing MP_CLOSE. > > > > With regard to 10), we, the authors, agree with your text proposal and ask > you to adopt it. > > > > With regard to 11), we, the authors, agree with your second text proposal > introducing " hosts' " and ask you to adopt it. > > > > With regard to 12), we, the authors, think it would be useful to change from > a bulleted list to an ordered list instead. In addition to your suggestion, we > would like you to ask to change both lists, the one for the "basic initial > handshaking" and the one describing the handshake for the "subsequent > subflows". > > > > With regard to 13), we, the authors, agree with your text proposal for both > section 3.2.8 and 3.2.9 and ask you to adopt it. > > > > With regard to 14), we, the authors, agree with your change. > > > > With regard to 15), we, the authors, agree with your text proposal and ask > you to adopt it. > > > > With regard to 16), we, the authors, agree that "appropriate one" is not > necessary. However, we prefer a slightly different rephrasing and ask you to > adopt the following: > > NEW: In the case of path mobility (Section 3.11.1), only one path can be > used at a time and MUST have the highest available priority value. That also > includes the prio numbers 1 and 2. > > > > With regard to 17), we, the authors, agree with your text proposal and ask > you to adopt it. > > > > With regard to 18), we, the authors, hope that the following sentence is > clearer and can be used instead: > > NEW: Please note that the Key Data sent in DCCP-CloseReq will not be the > same as the Key Data sent in DCCP-Close as these originate from different ends > of the connection > > > > With regard to 19), we, the authors, agree with your text proposal and ask > you to adopt it. > > > > With regard to 20), we, the authors, agree with your change. > > > > With regard to 21), we, the authors, propose to simply remove "own". > > > > With regard to 22), we, the authors, agree with your text proposal and ask > you to adopt it. > > > > With regard to 23), we, the authors, agree with your text proposal and ask > you to adopt it. > > > > With regard to 24), we, the authors, agree with your text proposal and ask > you to adopt it. > > > > With regard to 25), we, the authors, agree with your text proposal and ask > you to adopt it. > > > > With regard to 26), we, the authors, agree with your text proposal and ask > you to adopt it. > > > > With regard to 27), we, the authors, agree with your text proposal and ask > you to adopt it. > > > > With regard to 28), we, the authors, determined a typo and ask you to > replace wrong [RFC4043] with correct [RFC4340]. Please also remove the > bibliography entry of [RFC4043], as it is otherwise not used anywhere else. > > > > With regard to 29), we, the authors, agree with your text proposal in a) and > ask you to adopt it. Also we agree with your applied change described in b). > > > > With regard to 30), we, the authors, agree with your proposal to add a > reference link to the paper and ask you to adopt it. > > > > With regard to 31), we, the authors, agree with your proposal in b) and ask > you to adopt it. For a) we answer as follows: > > > > - CLOSED state vs. CLOSE state vs. CLOSING state > > According to > https://datat/ > racker.ietf.org%2Fdoc%2Fhtml%2Frfc4340%23section- > 4.3&data=05%7C02%7CMarkus.Amend%40telekom.de%7C29d2ebc7c7a44 > 3e69f1008de3862d243%7Cbde4dffc4b604cf68b04a5eeb25f5c4f%7C0%7C > 0%7C639010194262181212%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU > 1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIs > IldUIjoyfQ%3D%3D%7C0%7C%7C%7C&sdata=frUpY29Mj1uV2Cbal0oru5fj% > 2FxQ%2B4usRSrbk9bZMPGo%3D&reserved=0, there are the states CLOSED > and CLOSING, which we wanted to refer to consistently. Every occurrence of > CLOSED and CLOSING is therefore OK from our point of view, while the > occurrence of CLOSE (we found it once in the text) should be CLOSED. > Otherwise, we found CLOSE as a suffix of MP_CLOSE and MP_FAST_CLOSE, > which does not describe a state but an action. > > > > - Client and Server vs. client and server (as well as 'the client and the > > server') > > We prefer "Client and Server" > > > > - Congestion Control procedure vs. congestion control scheme > > We are fine if you replace congestion control scheme by Congestion Control > procedure > > > > - "Fast Close" vs. fast close > > We are fine with your proposal to change "Fast Close" to "fast close" and > > ask > you to adopt it. > > > > - Feature number 10 vs. feature number 10 > > We prefer any occurrence of feature number of Feature number to be > replaced with Feature Number according to IANA style > > > > - Length vs. length > > If the term length refers to the Length data field of a header option, we > prefer the capitalisation of Length instead of length and ask you to adopt > this > > > > - handshake procedure/process vs. handshaking procedure/process > > We prefer overall "handshake procedure" and ask you to adopt this. > > > > - Key Type vs. Key types vs. key type > > We generally prefer Key Type (singular) or Key Types (plural) and ask you to > adopt this. > > > > - Multipath Capability vs. multipath capability > > We prefer in general multipath capability and ask you to adopt this. > > > > - Multipath feature vs. multipath feature > > We prefer Multipath Feature except for the occurrence in Appendix A where > it has a general meaning and is not referring to the Multipath Capable > Feature. > That is why we additionally suggest to replace in Appendix A "multipath > features" with "multipath characteristics". > > > > - Multipath option vs. multipath option vs. MP option > > We prefer the general usage of Multipath Option (singular) or Multipath > Options (plural) and ask you to adopt this. > > > > - Multipath Capable Feature vs. Multipath Capable feature vs. MP-Capable > feature vs. MP_CAPABLE feature > > We prefer the general usage of "Multipath Capable Feature" and ask you to > adopt this. > > > > - Nonce vs. nonce > > We prefer the general usage of "Nonce" and ask you to adopt this. > > > > - Plain Text Key (Table 5) vs. Plain text key (Table 9) > > We prefer the general usage of "Plain text Key" and ask you to adopt this. > > > > - Reset Code vs. reset code > > We prefer the general usage of "Reset Code" and ask you to adopt this. > > > > - Remove Address vs. Remove address (Tables 3 and 8) > > We prefer the general usage of "Remove Address" and ask you to adopt this. > > > > SHA256 vs. SHA-256 > > According to the terminology in RFC6234 we prefer to change SHA256 to > SHA-256 and ask you to adopt this. > > > > With regard to 32), we, the authors, agree with your proposal in a) and c) > and ask you to adopt it. For b) we prefer Multipath DCCP without hyphen and > ask you to adopt it. > > > > With regard to 33), we, the authors, agree with your concern and ask you to > adopt the following: > > Original: ... that updates the (traditionally asymmetric) connection- > establishment procedures for DCCP. > > > > New: that updates the asymmetric connection-establishment procedures for > DCCP. > > > > > > By the way, while editing the document, we noticed that > https://www/ > .rfc- > editor.org%2Fauth48%2Frfc9897&data=05%7C02%7CMarkus.Amend%40tel > ekom.de%7C29d2ebc7c7a443e69f1008de3862d243%7Cbde4dffc4b604cf6 > 8b04a5eeb25f5c4f%7C0%7C0%7C639010194262195396%7CUnknown%7 > CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOi > JXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C0%7C%7C%7C&sdata= > rZHoWUJ%2F0EUIgq3IjFcb%2BSoK%2FPLHPSLd8%2ByhfZraQBQ%3D&reserv > ed=0 is broken. > > > > BR > > > > Markus & co-authors > > > >> -----Ursprüngliche Nachricht----- > >> Von: [email protected] <[email protected]> > >> Gesendet: Dienstag, 28. Oktober 2025 07:01 > >> An: Amend, Markus <[email protected]>; > >> [email protected]; [email protected]; > >> [email protected]; [email protected] > >> Cc: [email protected]; [email protected]; [email protected]; > >> [email protected]; [email protected]; auth48archive@rfc- > editor.org > >> Betreff: Re: AUTH48: RFC-to-be 9897 <draft-ietf-tsvwg-multipath-dccp-24> > >> for your review > >> > >> 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%2Fsearch&data=05%7C02%7CMarkus.Amend%40telekom.de%7C > >> > 34f67a154541449bd12808de15e77765%7Cbde4dffc4b604cf68b04a5eeb2 > >> > 5f5c4f%7C0%7C0%7C638972281329016204%7CUnknown%7CTWFpbGZsb > >> > 3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsI > >> > kFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C0%7C%7C%7C&sdata=BpyjDex8PS3 > >> Nm16BAG1KlgLsb%2FkKPwMOOHbrqMf9UUU%3D&reserved=0. --> > >> > >> > >> 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://ww/ > >> w.iana.org%2Fassignments%2Fdccp- > >> > parameters%2F&data=05%7C02%7CMarkus.Amend%40telekom.de%7C34f6 > >> > 7a154541449bd12808de15e77765%7Cbde4dffc4b604cf68b04a5eeb25f5c > >> > 4f%7C0%7C0%7C638972281329036102%7CUnknown%7CTWFpbGZsb3d8 > >> > eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOI > >> > joiTWFpbCIsIldUIjoyfQ%3D%3D%7C0%7C%7C%7C&sdata=hXvyUPZU2vTlp7 > >> 2sNtMFMb54YHY72YK3V22aq1RKNFA%3D&reserved=0>. > >> --> > >> > >> > >> 30) <!-- [rfced] We found the URL > >> > <https://dl.a/ > %2F&data=05%7C02%7CMarkus.Amend%40telekom.de%7C29d2ebc7c7a44 > 3e69f1008de3862d243%7Cbde4dffc4b604cf68b04a5eeb25f5c4f%7C0%7C > 0%7C639010194262207054%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU > 1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIs > IldUIjoyfQ%3D%3D%7C0%7C%7C%7C&sdata=ThcUWeCngYzUieHZ%2BLq04 > eZGH%2Fa63LSRnzKBoo9FW1k%3D&reserved=0 > >> > cm.org%2Fdoi%2F10.1145%2F2413176.2413178&data=05%7C02%7CMark > >> > us.Amend%40telekom.de%7C34f67a154541449bd12808de15e77765%7Cb > >> > de4dffc4b604cf68b04a5eeb25f5c4f%7C0%7C0%7C638972281329045189 > >> > %7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAu > >> > MDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C0%7C > >> > %7C%7C&sdata=cnNyX5th1O%2BjzEHYDoTTkQA0Z48kjK2ygqecN1krlDY%3D > >> &reserved=0> 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.a/ > %2F&data=05%7C02%7CMarkus.Amend%40telekom.de%7C29d2ebc7c7a44 > 3e69f1008de3862d243%7Cbde4dffc4b604cf68b04a5eeb25f5c4f%7C0%7C > 0%7C639010194262220560%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU > 1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIs > IldUIjoyfQ%3D%3D%7C0%7C%7C%7C&sdata=%2FI6bf2kCKkwW9TX5vq5M > dgNmbBGXxCjL07gxgVmbcYo%3D&reserved=0 > >> > cm.org%2Fdoi%2F10.1145%2F2413176.2413178&data=05%7C02%7CMark > >> > us.Amend%40telekom.de%7C34f67a154541449bd12808de15e77765%7Cb > >> > de4dffc4b604cf68b04a5eeb25f5c4f%7C0%7C0%7C638972281329054131 > >> > %7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAu > >> > MDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C0%7C > >> > %7C%7C&sdata=jnz%2F%2BAJ2RX9k3mFK2m%2FJIEtxjD7Z%2FBGAilOqZQ2L > >> Do0%3D&reserved=0>. > >> --> > >> > >> > >> 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://ww/ > >> w.rfc- > >> > editor.org%2Fstyleguide%2Fpart2%2F%23exp_abbrev&data=05%7C02%7C > >> > Markus.Amend%40telekom.de%7C34f67a154541449bd12808de15e77765 > >> > %7Cbde4dffc4b604cf68b04a5eeb25f5c4f%7C0%7C0%7C63897228132906 > >> > 3391%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiI > >> > wLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C > >> > 0%7C%7C%7C&sdata=Y7scNs57ywBcUOO8n2DrBGcRBsrbxzBB%2FLE7rytCaf > >> g%3D&reserved=0>, 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://ww/ > >> w.rfc- > >> > editor.org%2Fstyleguide%2Fpart2%2F%23inclusive_language&data=05%7C0 > >> > 2%7CMarkus.Amend%40telekom.de%7C34f67a154541449bd12808de15e7 > >> > 7765%7Cbde4dffc4b604cf68b04a5eeb25f5c4f%7C0%7C0%7C6389722813 > >> > 29074991%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIl > >> > YiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D > >> > %7C0%7C%7C%7C&sdata=cscnUyO2vk1DQmdMOFOZvhx6gMR15iP6f7eCu > >> 8fO49s%3D&reserved=0> > >> 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://we/ > >> > b.archive.org%2Fweb%2F20250214092458%2Fhttps%3A%2F%2Fwww.nist. > >> gov%2Fnist-research- > >> > library%2F&data=05%7C02%7CMarkus.Amend%40telekom.de%7C34f67a15 > >> > 4541449bd12808de15e77765%7Cbde4dffc4b604cf68b04a5eeb25f5c4f%7 > >> > C0%7C0%7C638972281329084470%7CUnknown%7CTWFpbGZsb3d8eyJFb > >> > XB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTW > >> > FpbCIsIldUIjoyfQ%3D%3D%7C0%7C%7C%7C&sdata=Whs0cet5uLqvtnmFS4l > >> p%2FW%2Fp4CsBSEp5pUeiuWlLw%2Fc%3D&reserved=0 > >> 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://ww/ > >> w.rfc- > >> > editor.org%2Ffaq%2F&data=05%7C02%7CMarkus.Amend%40telekom.de%7 > >> > C34f67a154541449bd12808de15e77765%7Cbde4dffc4b604cf68b04a5eeb > >> > 25f5c4f%7C0%7C0%7C638972281329094139%7CUnknown%7CTWFpbGZs > >> > b3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIs > >> > IkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C0%7C%7C%7C&sdata=yS8vk075Pr > >> gUh6i28%2F97rsn52kWyLEgkpc7bmSwnGQg%3D&reserved=0). > >> > >> 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://trust/ > >> ee.ietf.org%2Flicense- > >> > info&data=05%7C02%7CMarkus.Amend%40telekom.de%7C34f67a1545414 > >> > 49bd12808de15e77765%7Cbde4dffc4b604cf68b04a5eeb25f5c4f%7C0%7C > >> > 0%7C638972281329103134%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU > >> > 1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIs > >> > IldUIjoyfQ%3D%3D%7C0%7C%7C%7C&sdata=jYmJhjGvE8Q%2FUmf0QreVat > >> WqNeogHyoEw0VsXjW%2BPqk%3D&reserved=0). > >> > >> * 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://aut/ > >> hors.ietf.org%2Frfcxml- > >> > vocabulary&data=05%7C02%7CMarkus.Amend%40telekom.de%7C34f67a1 > >> > 54541449bd12808de15e77765%7Cbde4dffc4b604cf68b04a5eeb25f5c4f% > >> > 7C0%7C0%7C638972281329112128%7CUnknown%7CTWFpbGZsb3d8eyJF > >> > bXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiT > >> > WFpbCIsIldUIjoyfQ%3D%3D%7C0%7C%7C%7C&sdata=1W8OEzSMEo49hde > >> FNk8b0%2FLzcKo%2F7%2Fy%2Bbp%2FYyyJPU5Q%3D&reserved=0>. > >> > >> * 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://maila/ > >> rchive.ietf.org%2Farch%2Fmsg%2Fietf-announce%2Fyb6lpIGh- > >> > 4Q9l2USxIAe6P8O4Zc&data=05%7C02%7CMarkus.Amend%40telekom.de% > >> > 7C34f67a154541449bd12808de15e77765%7Cbde4dffc4b604cf68b04a5ee > >> > b25f5c4f%7C0%7C0%7C638972281329121524%7CUnknown%7CTWFpbGZ > >> > sb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiI > >> > sIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C0%7C%7C%7C&sdata=WinHATdEh > >> dQovFkGOUC8P749REPaoYR1%2FkQHv%2B7abtk%3D&reserved=0 > >> > >> * The archive itself: > >> > >> https://maila/ > >> > rchive.ietf.org%2Farch%2Fbrowse%2Fauth48archive%2F&data=05%7C02%7 > >> > CMarkus.Amend%40telekom.de%7C34f67a154541449bd12808de15e7776 > >> > 5%7Cbde4dffc4b604cf68b04a5eeb25f5c4f%7C0%7C0%7C6389722813291 > >> > 33709%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOi > >> > IwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7 > >> > C0%7C%7C%7C&sdata=Zh619HF0OTx8rFWoJ%2BCRBOI4H1gzLNwpjPC4Rrv > >> RWms%3D&reserved=0 > >> > >> * 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%2Fauthors%2Frfc9897.xml&data=05%7C02%7CMarkus.Amend% > >> > 40telekom.de%7C34f67a154541449bd12808de15e77765%7Cbde4dffc4b6 > >> > 04cf68b04a5eeb25f5c4f%7C0%7C0%7C638972281329146321%7CUnkno > >> > wn%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCI > >> > sIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C0%7C%7C%7C&s > >> > data=IHIoddWaDVRaiInViKyo1MT3W76iELytFnS5TlOHVCg%3D&reserved=0 > >> > >> https://www/ > >> .rfc- > >> > editor.org%2Fauthors%2Frfc9897.html&data=05%7C02%7CMarkus.Amend > >> > %40telekom.de%7C34f67a154541449bd12808de15e77765%7Cbde4dffc4b > >> > 604cf68b04a5eeb25f5c4f%7C0%7C0%7C638972281329157363%7CUnkno > >> > wn%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCI > >> > sIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C0%7C%7C%7C&s > >> > data=gZTIy7dNXKu9gDgDdxx4GPxvnFc73FnosHh56emr71A%3D&reserved=0 > >> > >> https://www/ > >> .rfc- > >> > editor.org%2Fauthors%2Frfc9897.pdf&data=05%7C02%7CMarkus.Amend% > >> > 40telekom.de%7C34f67a154541449bd12808de15e77765%7Cbde4dffc4b6 > >> > 04cf68b04a5eeb25f5c4f%7C0%7C0%7C638972281329167327%7CUnkno > >> > wn%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCI > >> > sIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C0%7C%7C%7C&s > >> > data=Vn3pwzsdz%2FI0kwNbRcrIfjC0O3eQ8lRz8Dyojyobs7c%3D&reserved=0 > >> > >> https://www/ > >> .rfc- > >> > editor.org%2Fauthors%2Frfc9897.txt&data=05%7C02%7CMarkus.Amend%4 > >> > 0telekom.de%7C34f67a154541449bd12808de15e77765%7Cbde4dffc4b60 > >> > 4cf68b04a5eeb25f5c4f%7C0%7C0%7C638972281329177120%7CUnknow > >> > n%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIl > >> > AiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C0%7C%7C%7C&sd > >> > ata=6lBOuHpymJ%2F3Y0DlYS6b0GPs2pFsF%2BOobJSSSPj0MmI%3D&reserv > >> ed=0 > >> > >> Diff file of the text: > >> > >> https://www/ > >> .rfc-editor.org%2Fauthors%2Frfc9897- > >> > diff.html&data=05%7C02%7CMarkus.Amend%40telekom.de%7C34f67a154 > >> > 541449bd12808de15e77765%7Cbde4dffc4b604cf68b04a5eeb25f5c4f%7C > >> > 0%7C0%7C638972281329186742%7CUnknown%7CTWFpbGZsb3d8eyJFbX > >> > B0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWF > >> > pbCIsIldUIjoyfQ%3D%3D%7C0%7C%7C%7C&sdata=EjJGCV0QREiYbaySpisjRg > >> gbGSE13QrF8LLU2AL3Kv0%3D&reserved=0 > >> > >> https://www/ > >> .rfc-editor.org%2Fauthors%2Frfc9897- > >> > rfcdiff.html&data=05%7C02%7CMarkus.Amend%40telekom.de%7C34f67a1 > >> > 54541449bd12808de15e77765%7Cbde4dffc4b604cf68b04a5eeb25f5c4f% > >> > 7C0%7C0%7C638972281329195621%7CUnknown%7CTWFpbGZsb3d8eyJF > >> > bXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiT > >> > WFpbCIsIldUIjoyfQ%3D%3D%7C0%7C%7C%7C&sdata=etFLnas9CNj0YyhXJH > >> PPVciMeRuECj7Ue0XYsJzWx8c%3D&reserved=0 (side by side) > >> > >> Diff of the XML: > >> > >> https://www/ > >> .rfc-editor.org%2Fauthors%2Frfc9897- > >> > xmldiff1.html&data=05%7C02%7CMarkus.Amend%40telekom.de%7C34f67a > >> > 154541449bd12808de15e77765%7Cbde4dffc4b604cf68b04a5eeb25f5c4f > >> > %7C0%7C0%7C638972281329204385%7CUnknown%7CTWFpbGZsb3d8ey > >> > JFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoi > >> > TWFpbCIsIldUIjoyfQ%3D%3D%7C0%7C%7C%7C&sdata=wYgbW6gNLaBNU% > >> 2FWtDFve4vQyKNUHs5xPAf5UWT4BHug%3D&reserved=0 > >> > >> > >> Tracking progress > >> ----------------- > >> > >> The details of the AUTH48 status of your document are here: > >> > >> https://www/ > >> .rfc- > >> > editor.org%2Fauth48%2Frfc9897&data=05%7C02%7CMarkus.Amend%40tel > >> > ekom.de%7C34f67a154541449bd12808de15e77765%7Cbde4dffc4b604cf6 > >> > 8b04a5eeb25f5c4f%7C0%7C0%7C638972281329213194%7CUnknown%7 > >> > CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOi > >> > JXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C0%7C%7C%7C&sdata= > >> > 9RTrRiS8FahV7sm9w%2F329KQ18pDus7Sr%2F08qouliRas%3D&reserved=0 > >> > >> 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]
