[auth48] Re: [AD] Re: AUTH48: RFC-to-be 9897 <draft-ietf-tsvwg-multipath-dccp-24> for your review

[[e-mail]]

General

Dear RFC Editor team,

I approve the latest revision of the document with Gorry’s amendments.

Kind Regards,
Stephen



General
From: [e-mail] <[e-mail]>
Sent: Wednesday, 17 December 2025 09:45
To: [e-mail]; [e-mail]; Stephen Johnson (TUD2 R) <[e-mail]>; [e-mail]; [e-mail]; [e-mail]
Cc: [e-mail]; [e-mail]; [e-mail]; [e-mail]
Subject: AW: [AD] Re: AUTH48: RFC-to-be 9897 <draft-ietf-tsvwg-multipath-dccp-24> for your review

Dear Karen, dear RFC Editor team,

With Gorry's request, I also approve the document.

I would ask my co-authors to also give their approval if they have no further concerns.

Br

Markus

Von: Gorry Fairhurst <[e-mail]<mailto:[e-mail]>>
Gesendet: Mittwoch, 17. Dezember 2025 10:32
An: Karen Moore <[e-mail]<mailto:[e-mail]>>; Amend, Markus <[e-mail]<mailto:[e-mail]>>; [e-mail]<mailto:[e-mail]>; [e-mail]<mailto:[e-mail]>; [e-mail]<mailto:[e-mail]>; [e-mail]<mailto:[e-mail]>
Cc: [e-mail]<mailto:[e-mail]>; [e-mail]<mailto:[e-mail]>; [e-mail]<mailto:[e-mail]>; [e-mail]<mailto:[e-mail]>
Betreff: Re: [AD] Re: AUTH48: RFC-to-be 9897 <draft-ietf-tsvwg-multipath-dccp-24> for your review

I ahve read the latest revision, and have reviewed the changes noted below.

I would like two to see two changes to the final text:

1 OLD:

 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

NEW:

 the order of packets within an

   MP-DCCP connection MUST be known before assigning packets to subflows

   to apply the received Multipath Options in the correct order
- reason: there were rather to many uses of "order".

2) OLD (multiple):

Congestion Control procedure
NEW:

Congestion Control algorithm
- reason: This change aligns with other RFC current usage for describing a method and the use in this specification.

With these two requested changes, I approve the document. Many thanks for completing this substatial piece of specification,

Gorry
(WIT AD

On 16/12/2025 22:04, Karen Moore wrote:

--Resending with “AD” in the Subject line --





On Dec 16, 2025, at 1:59 PM, Karen Moore <[e-mail]><mailto:[e-mail]> wrote:



Dear Markus and *Gorry (AD),



Thank you for your reply.  We have updated our files accordingly. Please review and let us know if any further changes are needed or if you approve the document in its current form. We will await approvals from each author before moving forward with publication.



* Gorry, please review the changes within the following sections and let us know if you approve:



- Section 1 (3rd paragraph)

- New text added: Sections 3.2.1, 3.2.4, 3.2.5, 3.2.6, and 3.2.11



—FILES (please refresh)--



Updated XML file:

https://www.rfc-editor.org/authors/rfc9897.xml



Updated output files:

https://www.rfc-editor.org/authors/rfc9897.txt

https://www.rfc-editor.org/authors/rfc9897.pdf

https://www.rfc-editor.org/authors/rfc9897.html



Diff files showing all changes made during AUTH48:

https://www.rfc-editor.org/authors/rfc9897-auth48diff.html

https://www.rfc-editor.org/authors/rfc9897-auth48rfcdiff.html (side by side)



Diff files showing all changes:

https://www.rfc-editor.org/authors/rfc9897-diff.html

https://www.rfc-editor.org/authors/rfc9897-rfcdiff.html (side by side)



For the AUTH48 status of this document, please see:

https://www.rfc-editor.org/auth48/rfc9897



Best regards,

Karen Moore

RFC Production Center





On Dec 16, 2025, at 2:10 AM, <[e-mail]><mailto:[e-mail]> <[e-mail]><mailto:[e-mail]> wrote:



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 <[e-mail]><mailto:[e-mail]>

Gesendet: Donnerstag, 11. Dezember 2025 04:10

An: Amend, Markus <[e-mail]><mailto:[e-mail]>; [e-mail]<mailto:[e-mail]>;

[e-mail]<mailto:[e-mail]>; [e-mail]<mailto:[e-mail]>;

[e-mail]<mailto:[e-mail]>

Cc: [e-mail]<mailto:[e-mail]>; [e-mail]<mailto:[e-mail]>; [e-mail]<mailto:[e-mail]>;

[e-mail]<mailto:[e-mail]>; [e-mail]<mailto:[e-mail]>

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/<https://ww/w.rfc-editor.org%2Fstyleguide%2Fpart2%2F%23inclusive_language&data=05%7C02%7CMarkus.Amend%40telekom.de%7C29d2ebc7c7a443e69f1008de3862d243%7Cbde4dffc4b604cf68b04a5eeb25f5c4f%7C0%7C0%7C639010194262023565%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C0%7C%7C%7C&sdata=sC7IR05r%2B8QWtd5QqPmv4tmnWAWe%2BcO0ipF9s1mIOHY%3D&reserved=0>

w.rfc-<https://ww/w.rfc-editor.org%2Fstyleguide%2Fpart2%2F%23inclusive_language&data=05%7C02%7CMarkus.Amend%40telekom.de%7C29d2ebc7c7a443e69f1008de3862d243%7Cbde4dffc4b604cf68b04a5eeb25f5c4f%7C0%7C0%7C639010194262023565%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C0%7C%7C%7C&sdata=sC7IR05r%2B8QWtd5QqPmv4tmnWAWe%2BcO0ipF9s1mIOHY%3D&reserved=0>

editor.org%2Fstyleguide%2Fpart2%2F%23inclusive_language&data=05%7C0<https://ww/w.rfc-editor.org%2Fstyleguide%2Fpart2%2F%23inclusive_language&data=05%7C02%7CMarkus.Amend%40telekom.de%7C29d2ebc7c7a443e69f1008de3862d243%7Cbde4dffc4b604cf68b04a5eeb25f5c4f%7C0%7C0%7C639010194262023565%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C0%7C%7C%7C&sdata=sC7IR05r%2B8QWtd5QqPmv4tmnWAWe%2BcO0ipF9s1mIOHY%3D&reserved=0>

2%7CMarkus.Amend%40telekom.de%7C29d2ebc7c7a443e69f1008de3862<https://ww/w.rfc-editor.org%2Fstyleguide%2Fpart2%2F%23inclusive_language&data=05%7C02%7CMarkus.Amend%40telekom.de%7C29d2ebc7c7a443e69f1008de3862d243%7Cbde4dffc4b604cf68b04a5eeb25f5c4f%7C0%7C0%7C639010194262023565%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C0%7C%7C%7C&sdata=sC7IR05r%2B8QWtd5QqPmv4tmnWAWe%2BcO0ipF9s1mIOHY%3D&reserved=0>

d243%7Cbde4dffc4b604cf68b04a5eeb25f5c4f%7C0%7C0%7C6390101942<https://ww/w.rfc-editor.org%2Fstyleguide%2Fpart2%2F%23inclusive_language&data=05%7C02%7CMarkus.Amend%40telekom.de%7C29d2ebc7c7a443e69f1008de3862d243%7Cbde4dffc4b604cf68b04a5eeb25f5c4f%7C0%7C0%7C639010194262023565%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C0%7C%7C%7C&sdata=sC7IR05r%2B8QWtd5QqPmv4tmnWAWe%2BcO0ipF9s1mIOHY%3D&reserved=0>

62023565%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIl<https://ww/w.rfc-editor.org%2Fstyleguide%2Fpart2%2F%23inclusive_language&data=05%7C02%7CMarkus.Amend%40telekom.de%7C29d2ebc7c7a443e69f1008de3862d243%7Cbde4dffc4b604cf68b04a5eeb25f5c4f%7C0%7C0%7C639010194262023565%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C0%7C%7C%7C&sdata=sC7IR05r%2B8QWtd5QqPmv4tmnWAWe%2BcO0ipF9s1mIOHY%3D&reserved=0>

YiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D<https://ww/w.rfc-editor.org%2Fstyleguide%2Fpart2%2F%23inclusive_language&data=05%7C02%7CMarkus.Amend%40telekom.de%7C29d2ebc7c7a443e69f1008de3862d243%7Cbde4dffc4b604cf68b04a5eeb25f5c4f%7C0%7C0%7C639010194262023565%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C0%7C%7C%7C&sdata=sC7IR05r%2B8QWtd5QqPmv4tmnWAWe%2BcO0ipF9s1mIOHY%3D&reserved=0>

%7C0%7C%7C%7C&sdata=sC7IR05r%2B8QWtd5QqPmv4tmnWAWe%2BcO0<https://ww/w.rfc-editor.org%2Fstyleguide%2Fpart2%2F%23inclusive_language&data=05%7C02%7CMarkus.Amend%40telekom.de%7C29d2ebc7c7a443e69f1008de3862d243%7Cbde4dffc4b604cf68b04a5eeb25f5c4f%7C0%7C0%7C639010194262023565%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C0%7C%7C%7C&sdata=sC7IR05r%2B8QWtd5QqPmv4tmnWAWe%2BcO0ipF9s1mIOHY%3D&reserved=0>

ipF9s1mIOHY%3D&reserved=0><https://ww/w.rfc-editor.org%2Fstyleguide%2Fpart2%2F%23inclusive_language&data=05%7C02%7CMarkus.Amend%40telekom.de%7C29d2ebc7c7a443e69f1008de3862d243%7Cbde4dffc4b604cf68b04a5eeb25f5c4f%7C0%7C0%7C639010194262023565%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C0%7C%7C%7C&sdata=sC7IR05r%2B8QWtd5QqPmv4tmnWAWe%2BcO0ipF9s1mIOHY%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,

Markus.Amend=[e-mail]<mailto:Markus.Amend=[e-mail]> 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: [e-mail]<mailto:[e-mail]> <[e-mail]><mailto:[e-mail]>

Gesendet: Dienstag, 28. Oktober 2025 07:01

An: Amend, Markus <[e-mail]><mailto:[e-mail]>;

[e-mail]<mailto:[e-mail]>; [e-mail]<mailto:[e-mail]>;

[e-mail]<mailto:[e-mail]>; [e-mail]<mailto:[e-mail]>

Cc: [e-mail]<mailto:[e-mail]>; [e-mail]<mailto:[e-mail]>; [e-mail]<mailto:[e-mail]>;

[e-mail]<mailto:[e-mail]>; [e-mail]<mailto:[e-mail]>; 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, [e-mail]<mailto:[e-mail]> 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



*  [e-mail]<mailto:[e-mail]> (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).



*  [e-mail]<mailto:[e-mail]>, 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,

    [e-mail]<mailto:[e-mail]> 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