Dear Anna and Andreas, We do not believe we have heard from you regarding this document's readiness for publication. Please review the files below and let us know if any updates are needed or if the document is ready for publication.
Once both approvals are received, we will ask IANA to update their registries accordingly before moving forward with the publication process. https://www.rfc-editor.org/authors/rfc9897.xml https://www.rfc-editor.org/authors/rfc9897.txt https://www.rfc-editor.org/authors/rfc9897.html https://www.rfc-editor.org/authors/rfc9897.pdf https://www.rfc-editor.org/authors/rfc9897-auth48diff.html https://www.rfc-editor.org/authors/rfc9897-auth48rfcdiff.html (side by side) https://www.rfc-editor.org/authors/rfc9897-diff.html https://www.rfc-editor.org/authors/rfc9897-rfcdiff.html (side by side) Thank you, Karen Moore RFC Production Center > On Dec 17, 2025, at 11:55 AM, Karen Moore <[email protected]> wrote: > > Dear Gorry, Markus, Stephen, and Veselin, > > Thank you for your replies. We have updated our files with Gorry’s > suggestions and marked his approval. Note that we made “congestion control > algorithm” lowercase for consistency and to match use in RFC 6356. > > We have also noted approvals for Markus, Stephen, and Veslin on the AUTH48 > status page (https://www.rfc-editor.org/auth48/rfc9897). We now await > approvals from Andreas and Anna. Once all approvals are recieved, we will ask > IANA to make further updates to their registries to match the edited document. > > --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 17, 2025, at 1:31 AM, Gorry Fairhurst <[email protected]> wrote: >> >> 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 <[email protected]> >>> 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, <[email protected]> >>>>> <[email protected]> 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 <[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]
