Dear IANA, Happy new year!
Please make the following updates at <https://www.iana.org/assignments/dccp-parameters/> to match the edited document at <https://www.rfc-editor.org/authors/rfc9897-diff.html>. 1) Under the "Multipath Options” registry, please update the descriptions as follows: OLD: MP_OPT=5 MP_HMAC Hash-based message auth. code for MP-DCCP MP_OPT=7 MP_ADDADDR Advertise additional address(es)/port(s) MP_OPT=8 MP_REMOVEADDR Remove address(es)/port(s) NEW: MP_OPT=5 MP_HMAC Hash-based message authentication code for MP-DCCP MP_OPT=7 MP_ADDADDR Advertise one or more additional addresses/ports MP_OPT=8 MP_REMOVEADDR Remove one or more addresses/ports 2) Under the "Multipath Key Type” registry, uppercase “key”: OLD: 0 Plain Text Plain text key NEW: 0 Plain Text Plain text Key Thank you! Karen Moore RFC Production Center > On Jan 5, 2026, at 10:47 AM, Karen Moore <[email protected]> wrote: > > Hi Andreas, > > Thank you for your reply. We have noted your approval on the AUTH48 status > page (https://www.rfc-editor.org/auth48/rfc9897). As we now have all author > approvals, we will ask IANA to update their registries to match the edited > document. We will inform you when the updates are complete. > > Happy new year! > > Best regards, > Karen Moore > RFC Production Center > >> On Dec 30, 2025, at 12:18 AM, Andreas Kassler <[email protected]> wrote: >> >> Hi, >> Thanks also from my side for the editing. I have no further comments and >> also approve it. >> Best, Andreas Kassler >> >> On 2025-12-29, 22:20, "Karen Moore" <[email protected] >> <mailto:[email protected]>> wrote: >> >> >> Dear Anna, >> >> >> We have noted your approval on the AUTH48 status page >> (https://www.rfc-editor.org/auth48/rfc9897 >> <https://www.rfc-editor.org/auth48/rfc9897>). We now await approval of the >> document from Andreas. >> >> >> Wishing you a happy new year! >> >> >> Karen Moore >> RPC Production Center >> >> >>> On Dec 29, 2025, at 1:23 AM, Anna Brunström <[email protected] >>> <mailto:[email protected]>> wrote: >>> >>> Dear Karen, >>> >>> Thanks for the, as always, great editing work. I have no further updates >>> and approve the document. >>> >>> I hope you are all having a nice holiday season and best wishes for a happy >>> 2026! >>> >>> Anna >>> >>> -----Original Message----- >>> From: Karen Moore <[email protected] >>> <mailto:[email protected]>> >>> Sent: den 24 december 2025 19:16 >>> To: Anna Brunström <[email protected] <mailto:[email protected]>>; >>> [email protected] <mailto:[email protected]>; >>> [email protected] <mailto:[email protected]>; Andreas Kassler >>> <[email protected] <mailto:[email protected]>>; >>> [email protected] <mailto:[email protected]> >>> Cc: [email protected] <mailto:[email protected]>; >>> [email protected] <mailto:[email protected]>; [email protected] >>> <mailto:[email protected]>; [email protected] >>> <mailto:[email protected]>; Gorry Fairhurst >>> <[email protected] <mailto:[email protected]>> >>> Subject: Re: AUTH48: RFC-to-be 9897 <draft-ietf-tsvwg-multipath-dccp-24> >>> for your review >>> >>> 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.xml> >>> https://www.rfc-editor.org/authors/rfc9897.txt >>> <https://www.rfc-editor.org/authors/rfc9897.txt> >>> https://www.rfc-editor.org/authors/rfc9897.html >>> <https://www.rfc-editor.org/authors/rfc9897.html> >>> https://www.rfc-editor.org/authors/rfc9897.pdf >>> <https://www.rfc-editor.org/authors/rfc9897.pdf> >>> >>> https://www.rfc-editor.org/authors/rfc9897-auth48diff.html >>> <https://www.rfc-editor.org/authors/rfc9897-auth48diff.html> >>> https://www.rfc-editor.org/authors/rfc9897-auth48rfcdiff.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-diff.html> >>> https://www.rfc-editor.org/authors/rfc9897-rfcdiff.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] >>>> <mailto:[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 >>>> <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 >>>> <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.txt> >>>> https://www.rfc-editor.org/authors/rfc9897.pdf >>>> <https://www.rfc-editor.org/authors/rfc9897.pdf> >>>> https://www.rfc-editor.org/authors/rfc9897.html >>>> <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-auth48diff.html> >>>> https://www.rfc-editor.org/authors/rfc9897-auth48rfcdiff.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-diff.html> >>>> https://www.rfc-editor.org/authors/rfc9897-rfcdiff.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 >>>> <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] >>>>> <mailto:[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] >>>>>> <mailto:[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 >>>>>> <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.txt> >>>>>> https://www.rfc-editor.org/authors/rfc9897.pdf >>>>>> <https://www.rfc-editor.org/authors/rfc9897.pdf> >>>>>> https://www.rfc-editor.org/authors/rfc9897.html >>>>>> <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-auth48diff.html> >>>>>> https://www.rfc-editor.org/authors/rfc9897-auth48rfcdiff.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-diff.html> >>>>>> https://www.rfc-editor.org/authors/rfc9897-rfcdiff.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 >>>>>> <https://www.rfc-editor.org/auth48/rfc9897> >>>>>> >>>>>> Best regards, >>>>>> Karen Moore >>>>>> RFC Production Center >>>>>> >>>>>> >>>>>> >>>>>>>> On Dec 16, 2025, at 2:10 AM, <[email protected] >>>>>>>> <mailto:[email protected]>> <[email protected] >>>>>>>> <mailto:[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] >>>>>>>>> <mailto:[email protected]>> >>>>>>>>> Gesendet: Donnerstag, 11. Dezember 2025 04:10 >>>>>>>>> An: Amend, Markus <[email protected] >>>>>>>>> <mailto:[email protected]>>; [email protected] >>>>>>>>> <mailto:[email protected]>; >>>>>>>>> [email protected] >>>>>>>>> <mailto:[email protected]>; [email protected] >>>>>>>>> <mailto:[email protected]>; >>>>>>>>> [email protected] <mailto:[email protected]> >>>>>>>>> Cc: [email protected] <mailto:[email protected]>; >>>>>>>>> [email protected] <mailto:[email protected]>; [email protected] >>>>>>>>> <mailto:[email protected]>; >>>>>>>>> [email protected] <mailto:[email protected]>; >>>>>>>>> [email protected] <mailto:[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] >>>>>>>>> <mailto:[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] <mailto:[email protected]> >>>>>>>>>>> <[email protected] <mailto:[email protected]>> >>>>>>>>>>> Gesendet: Dienstag, 28. Oktober 2025 07:01 >>>>>>>>>>> An: Amend, Markus <[email protected] >>>>>>>>>>> <mailto:[email protected]>>; >>>>>>>>>>> [email protected] <mailto:[email protected]>; >>>>>>>>>>> [email protected] <mailto:[email protected]>; >>>>>>>>>>> [email protected] >>>>>>>>>>> <mailto:[email protected]>; [email protected] >>>>>>>>>>> <mailto:[email protected]> >>>>>>>>>>> Cc: [email protected] <mailto:[email protected]>; >>>>>>>>>>> [email protected] <mailto:[email protected]>; >>>>>>>>>>> [email protected] <mailto:[email protected]>; >>>>>>>>>>> [email protected] <mailto:[email protected]>; >>>>>>>>>>> [email protected] <mailto:[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/ <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/ <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] >>>>>>>>>>> <mailto:[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] <mailto:[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] >>>>>>>>>>> <mailto:[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] <mailto:[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 >>>>>>>>>>> >>>>>>>>>> >>>>>>>> >>>>>>> >>>>> >>>> >>> >>> När du skickar e-post till Karlstads universitet behandlar vi dina >>> personuppgifter<https://www.kau.se/gdpr> <https://www.kau.se/gdpr>>. >>> When you send an e-mail to Karlstad University, we will process your >>> personal data<https://www.kau.se/en/gdpr> <https://www.kau.se/en/gdpr>>. >> >> >> >> >> >> När du skickar e-post till Karlstads universitet behandlar vi dina >> personuppgifter<https://www.kau.se/gdpr>. >> When you send an e-mail to Karlstad University, we will process your >> personal data<https://www.kau.se/en/gdpr>. > -- auth48archive mailing list -- [email protected] To unsubscribe send an email to [email protected]
