Hi Karen, These changes are complete:
https://www.iana.org/assignments/dccp-parameters Thanks, and happy new year, Sabrina On Mon Jan 05 18:59:46 2026, [email protected] wrote: > 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] > > editor.org> 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]>; tsvwg- > >>> [email protected] <mailto:[email protected]>; auth48archive@rfc- > >>> editor.org <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] > >>>> editor.org <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] > >>>>>> editor.org <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:rfc-editor@rfc- > >>>>>>>>> editor.org>; [email protected] <mailto:[email protected]>; > >>>>>>>>> [email protected] <mailto:[email protected]>; > >>>>>>>>> [email protected] <mailto:[email protected]>; > >>>>>>>>> [email protected] <mailto:auth48archive@rfc- > >>>>>>>>> editor.org> > >>>>>>>>> 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:rfc-editor@rfc- > >>>>>>>>>>> editor.org> <[email protected] <mailto:rfc- > >>>>>>>>>>> [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:rfc-editor@rfc- > >>>>>>>>>>> editor.org>; [email protected] <mailto:tsvwg- > >>>>>>>>>>> [email protected]>; [email protected] <mailto:tsvwg- > >>>>>>>>>>> [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:rfc- > >>>>>>>>>>> [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:rfc-editor@rfc- > >>>>>>>>>>> editor.org> (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:auth48archive@rfc- > >>>>>>>>>>> editor.org>, 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:auth48archive@rfc- > >>>>>>>>>>> editor.org> 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]
