Dear Anna, We have noted your approval on the AUTH48 status page (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]> 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]> > Sent: den 24 december 2025 19:16 > To: Anna Brunström <[email protected]>; [email protected]; > [email protected]; Andreas Kassler <[email protected]>; > [email protected] > Cc: [email protected]; [email protected]; [email protected]; > [email protected]; Gorry Fairhurst <[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.txt > https://www.rfc-editor.org/authors/rfc9897.html > https://www.rfc-editor.org/authors/rfc9897.pdf > > https://www.rfc-editor.org/authors/rfc9897-auth48diff.html > https://www.rfc-editor.org/authors/rfc9897-auth48rfcdiff.html (side by side) > https://www.rfc-editor.org/authors/rfc9897-diff.html > https://www.rfc-editor.org/authors/rfc9897-rfcdiff.html (side by side) > > Thank you, > Karen Moore > RFC Production Center > > >> On Dec 17, 2025, at 11:55 AM, Karen Moore <[email protected]> >> wrote: >> >> Dear Gorry, Markus, Stephen, and Veselin, >> >> Thank you for your replies. We have updated our files with Gorry’s >> suggestions and marked his approval. Note that we made “congestion control >> algorithm” lowercase for consistency and to match use in RFC 6356. >> >> We have also noted approvals for Markus, Stephen, and Veslin on the AUTH48 >> status page (https://www.rfc-editor.org/auth48/rfc9897). We now await >> approvals from Andreas and Anna. Once all approvals are recieved, we will >> ask IANA to make further updates to their registries to match the edited >> document. >> >> --FILES (please refresh)-- >> >> Updated XML file: >> https://www.rfc-editor.org/authors/rfc9897.xml >> >> Updated output files: >> https://www.rfc-editor.org/authors/rfc9897.txt >> https://www.rfc-editor.org/authors/rfc9897.pdf >> https://www.rfc-editor.org/authors/rfc9897.html >> >> Diff files showing all changes made during AUTH48: >> https://www.rfc-editor.org/authors/rfc9897-auth48diff.html >> https://www.rfc-editor.org/authors/rfc9897-auth48rfcdiff.html (side by side) >> >> Diff files showing all changes: >> https://www.rfc-editor.org/authors/rfc9897-diff.html >> https://www.rfc-editor.org/authors/rfc9897-rfcdiff.html (side by side) >> >> For the AUTH48 status of this document, please see: >> https://www.rfc-editor.org/auth48/rfc9897 >> >> Best regards, >> Karen Moore >> RFC Production Center >> >> >>> On Dec 17, 2025, at 1:31 AM, Gorry Fairhurst <[email protected]> wrote: >>> >>> I ahve read the latest revision, and have reviewed the changes noted below. >>> >>> I would like two to see two changes to the final text: >>> >>> 1 OLD: the order of packets within an >>> MP-DCCP connection MUST be known before assigning packets to subflows >>> in order to apply received Multipath Options in the correct order >>> NEW: >>> the order of packets within an >>> MP-DCCP connection MUST be known before assigning packets to subflows >>> to apply the received Multipath Options in the correct order >>> >>> - reason: there were rather to many uses of "order". >>> >>> 2) OLD (multiple): >>> Congestion Control procedure >>> NEW: >>> Congestion Control algorithm >>> - reason: This change aligns with other RFC current usage for describing a >>> method and the use in this specification. >>> >>> With these two requested changes, I approve the document. Many thanks for >>> completing this substatial piece of specification, >>> >>> Gorry >>> (WIT AD >>> >>> On 16/12/2025 22:04, Karen Moore wrote: >>>> --Resending with “AD” in the Subject line -- >>>> >>>> >>>> On Dec 16, 2025, at 1:59 PM, Karen Moore <[email protected]> >>>> wrote: >>>> >>>> Dear Markus and *Gorry (AD), >>>> >>>> Thank you for your reply. We have updated our files accordingly. Please >>>> review and let us know if any further changes are needed or if you approve >>>> the document in its current form. We will await approvals from each author >>>> before moving forward with publication. >>>> >>>> * Gorry, please review the changes within the following sections and let >>>> us know if you approve: >>>> >>>> - Section 1 (3rd paragraph) >>>> - New text added: Sections 3.2.1, 3.2.4, 3.2.5, 3.2.6, and 3.2.11 >>>> >>>> —FILES (please refresh)-- >>>> >>>> Updated XML file: >>>> https://www.rfc-editor.org/authors/rfc9897.xml >>>> >>>> Updated output files: >>>> https://www.rfc-editor.org/authors/rfc9897.txt >>>> https://www.rfc-editor.org/authors/rfc9897.pdf >>>> https://www.rfc-editor.org/authors/rfc9897.html >>>> >>>> Diff files showing all changes made during AUTH48: >>>> https://www.rfc-editor.org/authors/rfc9897-auth48diff.html >>>> https://www.rfc-editor.org/authors/rfc9897-auth48rfcdiff.html (side by >>>> side) >>>> >>>> Diff files showing all changes: >>>> https://www.rfc-editor.org/authors/rfc9897-diff.html >>>> https://www.rfc-editor.org/authors/rfc9897-rfcdiff.html (side by side) >>>> >>>> For the AUTH48 status of this document, please see: >>>> https://www.rfc-editor.org/auth48/rfc9897 >>>> >>>> Best regards, >>>> Karen Moore >>>> RFC Production Center >>>> >>>> >>>> >>>>>> On Dec 16, 2025, at 2:10 AM, <[email protected]> >>>>>> <[email protected]> wrote: >>>>>> >>>>>> Dear Karen, dear RFC editor team, >>>>>> >>>>>> With regard to 1) , I ask you to replace the occurrence of >>>>>> "man-in-the-middle" with "on-path attacker" >>>>>> >>>>>> With regard to 2), I ask you to remove RFC5280 from the list of >>>>>> Informative References >>>>>> >>>>>> With regard to 3), I agree with both proposals, but I have not yet >>>>>> identified the changes in the Diff. I therefore ask you to adopt your >>>>>> proposals. >>>>>> >>>>>> With regard to 4), I say thank you. >>>>>> >>>>>> >>>>>> Regarding the keywords you requested in the previous e-mail, I would >>>>>> like to mention that I cannot yet find them in the XML structure. >>>>>> >>>>>> >>>>>> Br >>>>>> >>>>>> Markus >>>>>> >>>>>> >>>>>> >>>>>>> -----Ursprüngliche Nachricht----- >>>>>>> Von: Karen Moore <[email protected]> >>>>>>> Gesendet: Donnerstag, 11. Dezember 2025 04:10 >>>>>>> An: Amend, Markus <[email protected]>; [email protected]; >>>>>>> [email protected]; [email protected]; >>>>>>> [email protected] >>>>>>> Cc: [email protected]; [email protected]; >>>>>>> [email protected]; >>>>>>> [email protected]; [email protected] >>>>>>> Betreff: Re: AUTH48: RFC-to-be 9897 <draft-ietf-tsvwg-multipath-dccp-24> >>>>>>> for your review >>>>>>> >>>>>>> Dear Markus, >>>>>>> >>>>>>> Thank you for ensuring consolidated feedback from your coauthors; we >>>>>>> appreciate the level of detail you put into your reply. We have updated >>>>>>> our >>>>>>> files accordingly (see links to the files below). We have a few >>>>>>> additional >>>>>>> questions. >>>>>>> >>>>>>> 1) With the addition of new text, there are two occurences of >>>>>>> “man-in-the- >>>>>>> middle”. Per the "Inclusive Language" portion of the online Style Guide >>>>>>> <https://ww/ >>>>>>> w.rfc- >>>>>>> editor.org%2Fstyleguide%2Fpart2%2F%23inclusive_language&data=05%7C0 >>>>>>> 2%7CMarkus.Amend%40telekom.de%7C29d2ebc7c7a443e69f1008de3862 >>>>>>> d243%7Cbde4dffc4b604cf68b04a5eeb25f5c4f%7C0%7C0%7C6390101942 >>>>>>> 62023565%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIl >>>>>>> YiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D >>>>>>> %7C0%7C%7C%7C&sdata=sC7IR05r%2B8QWtd5QqPmv4tmnWAWe%2BcO0 >>>>>>> ipF9s1mIOHY%3D&reserved=0>, please let us know if any changes are needed >>>>>>> to this term. Updates of this nature typically result in more precise >>>>>>> language, >>>>>>> which is helpful for readers. >>>>>>> >>>>>>> Section 3.2.4: >>>>>>> MP-DCCP protects against some man-in-the-middle attacks as further >>>>>>> outlined in Section 4. >>>>>>> >>>>>>> Section 3.2.6: >>>>>>> MP-DCCP protects against some man-in-the-middle attacks as further >>>>>>> outlined in Section 4. >>>>>>> >>>>>>> 2) We note that [RFC5280] is not cited in the text. Would you like to >>>>>>> add a >>>>>>> citation to the text or remove the reference entry from the Informative >>>>>>> References section? >>>>>>> >>>>>>> 3) We made the following instances of “length” uppercase. Please review >>>>>>> and >>>>>>> let us know if this is correct or if any further updates are needed in >>>>>>> the running >>>>>>> text.. >>>>>>> >>>>>>> >>>>>>>> If the term length refers to the Length data field of a header option, >>>>>>>> we >>>>>>>> >>>>>>> prefer the capitalisation of Length instead of length and ask you to >>>>>>> adopt this >>>>>>> >>>>>>> length of one byte --> Legth of one byte >>>>>>> a maximum length of 252 bytes --> a maximum Length of 252 bytes >>>>>>> >>>>>>> 4) FYI: We made the requested changes below as well as the IANA-related >>>>>>> updates to Tables 3, 5, 8, and 9. >>>>>>> >>>>>>> >>>>>>>> - The text "However the definition of a path management method, in >>>>>>>> which >>>>>>>> >>>>>>> sequence and when subflows are created" was changed to "However the >>>>>>> definition of a path management method, in which sequence and subflows >>>>>>> are created". The word "when" was removed, but I think this is a >>>>>>> mistake. >>>>>>> Perhaps if the word "and" is also be removed it can be ok, but we >>>>>>> rather prefer >>>>>>> to add "when" again. >>>>>>> >>>>>>>> - The sentence "DCCP defines that if the checksum fails, the receiving >>>>>>>> >>>>>>> endpoint..." is replaced by "If the checksum fails as defined by the >>>>>>> DCCP, the >>>>>>> receiving endpoint...". This changes the meaning of the sentence and we >>>>>>> suggest instead: >>>>>>> >>>>>>>> New: "As defined by DCCP, if the checksum fails, the receiving >>>>>>>> endpoint..." >>>>>>>> >>>>>>>> - The affiliation of an author has changed because the university has >>>>>>>> been >>>>>>>> >>>>>>> renamed. We ask you to replace for the author Veselin Rakocevic the >>>>>>> affiliation >>>>>>> from >>>>>>> >>>>>>>> OLD: City, University of London >>>>>>>> to >>>>>>>> NEW: City St George's, University of London >>>>>>>> >>>>>>> >>>>>>> --Files-- >>>>>>> Note that it may be necessary for you to refresh your browser to view >>>>>>> the >>>>>>> most recent version. Please review the document carefully to ensure >>>>>>> satisfaction as we do not make changes once it has been published as an >>>>>>> RFC. >>>>>>> >>>>>>> Please contact us with any further updates or with your approval of the >>>>>>> document in its current form. We will await approvals from each author >>>>>>> prior >>>>>>> to moving forward in the publication process. >>>>>>> >>>>>>> Updated XML file: >>>>>>> >>>>>>> https://www/ >>>>>>> .rfc- >>>>>>> editor.org%2Fauthors%2Frfc9897.xml&data=05%7C02%7CMarkus.Amend% >>>>>>> 40telekom.de%7C29d2ebc7c7a443e69f1008de3862d243%7Cbde4dffc4b60 >>>>>>> 4cf68b04a5eeb25f5c4f%7C0%7C0%7C639010194262050621%7CUnknow >>>>>>> n%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIl >>>>>>> AiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C0%7C%7C%7C&sd >>>>>>> ata=4HPdmcXXqy1VddLBzn10bOVe7ze2oAdq9ahIXEhFd4w%3D&reserved=0 >>>>>>> >>>>>>> Updated output files: >>>>>>> >>>>>>> https://www/ >>>>>>> .rfc- >>>>>>> editor.org%2Fauthors%2Frfc9897.txt&data=05%7C02%7CMarkus.Amend%4 >>>>>>> 0telekom.de%7C29d2ebc7c7a443e69f1008de3862d243%7Cbde4dffc4b604 >>>>>>> cf68b04a5eeb25f5c4f%7C0%7C0%7C639010194262062468%7CUnknown >>>>>>> %7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIl >>>>>>> AiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C0%7C%7C%7C&sd >>>>>>> ata=1OyWO%2FOk3ESi8fXOZyd11M%2FW4DY7B6bbjRLwzkXSJVw%3D&res >>>>>>> erved=0 >>>>>>> >>>>>>> https://www/ >>>>>>> .rfc- >>>>>>> editor.org%2Fauthors%2Frfc9897.pdf&data=05%7C02%7CMarkus.Amend% >>>>>>> 40telekom.de%7C29d2ebc7c7a443e69f1008de3862d243%7Cbde4dffc4b60 >>>>>>> 4cf68b04a5eeb25f5c4f%7C0%7C0%7C639010194262074159%7CUnknow >>>>>>> n%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIl >>>>>>> AiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C0%7C%7C%7C&sd >>>>>>> ata=6pJFnfGkJ1PhGeSNEAl6uOOZ09BB8vpfJQpIYu1Hhus%3D&reserved=0 >>>>>>> >>>>>>> https://www/ >>>>>>> .rfc- >>>>>>> editor.org%2Fauthors%2Frfc9897.html&data=05%7C02%7CMarkus.Amend >>>>>>> %40telekom.de%7C29d2ebc7c7a443e69f1008de3862d243%7Cbde4dffc4b6 >>>>>>> 04cf68b04a5eeb25f5c4f%7C0%7C0%7C639010194262085170%7CUnkno >>>>>>> wn%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCI >>>>>>> sIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C0%7C%7C%7C&s >>>>>>> data=I%2BvyQCqOl4PCWo6oTPexXGh2oVsxdHSiLHyv8VgztU8%3D&reserved >>>>>>> =0 >>>>>>> >>>>>>> Diff files showing all changes made during AUTH48: >>>>>>> >>>>>>> https://www/ >>>>>>> .rfc-editor.org%2Fauthors%2Frfc9897- >>>>>>> auth48diff.html&data=05%7C02%7CMarkus.Amend%40telekom.de%7C29d >>>>>>> 2ebc7c7a443e69f1008de3862d243%7Cbde4dffc4b604cf68b04a5eeb25f5c >>>>>>> 4f%7C0%7C0%7C639010194262096590%7CUnknown%7CTWFpbGZsb3d8 >>>>>>> eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOI >>>>>>> joiTWFpbCIsIldUIjoyfQ%3D%3D%7C0%7C%7C%7C&sdata=1rW%2F2QPTuFJx >>>>>>> rS0yv3fsAtVeAGgUgcMu3HMhZ1N5CzM%3D&reserved=0 >>>>>>> >>>>>>> https://www/ >>>>>>> .rfc-editor.org%2Fauthors%2Frfc9897- >>>>>>> auth48rfcdiff.html&data=05%7C02%7CMarkus.Amend%40telekom.de%7C2 >>>>>>> 9d2ebc7c7a443e69f1008de3862d243%7Cbde4dffc4b604cf68b04a5eeb25f >>>>>>> 5c4f%7C0%7C0%7C639010194262107718%7CUnknown%7CTWFpbGZsb3 >>>>>>> d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkF >>>>>>> OIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C0%7C%7C%7C&sdata=55t9Es9AmtI0 >>>>>>> 8AJb28NftRkiN1%2BtyWHSR%2FRj34GA4YU%3D&reserved=0 (side by side) >>>>>>> >>>>>>> Diff files showing all changes: >>>>>>> >>>>>>> https://www/ >>>>>>> .rfc-editor.org%2Fauthors%2Frfc9897- >>>>>>> diff.html&data=05%7C02%7CMarkus.Amend%40telekom.de%7C29d2ebc7c >>>>>>> 7a443e69f1008de3862d243%7Cbde4dffc4b604cf68b04a5eeb25f5c4f%7C0 >>>>>>> %7C0%7C639010194262119479%7CUnknown%7CTWFpbGZsb3d8eyJFbXB >>>>>>> 0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFp >>>>>>> bCIsIldUIjoyfQ%3D%3D%7C0%7C%7C%7C&sdata=lcZPpQWJ1o8j9xM0UUzB >>>>>>> mBCMULLhbphiXiRsJlAAj64%3D&reserved=0 >>>>>>> >>>>>>> https://www/ >>>>>>> .rfc-editor.org%2Fauthors%2Frfc9897- >>>>>>> rfcdiff.html&data=05%7C02%7CMarkus.Amend%40telekom.de%7C29d2ebc >>>>>>> 7c7a443e69f1008de3862d243%7Cbde4dffc4b604cf68b04a5eeb25f5c4f%7 >>>>>>> C0%7C0%7C639010194262141617%7CUnknown%7CTWFpbGZsb3d8eyJFb >>>>>>> XB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTW >>>>>>> FpbCIsIldUIjoyfQ%3D%3D%7C0%7C%7C%7C&sdata=MPJSQ3evKTVPXujzd5 >>>>>>> No7Qnni%2FHRadAqn8uUFRdFujY%3D&reserved=0 (side by side) >>>>>>> >>>>>>> For the AUTH48 status of this document, please see: >>>>>>> >>>>>>> https://www/ >>>>>>> .rfc- >>>>>>> editor.org%2Fauth48%2Frfc9897&data=05%7C02%7CMarkus.Amend%40tel >>>>>>> ekom.de%7C29d2ebc7c7a443e69f1008de3862d243%7Cbde4dffc4b604cf6 >>>>>>> 8b04a5eeb25f5c4f%7C0%7C0%7C639010194262153473%7CUnknown%7 >>>>>>> CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOi >>>>>>> JXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C0%7C%7C%7C&sdata= >>>>>>> 5XlvDM%2BF%2FpoDSIr%2BHjWKEWmi7MpRxohEU%2FLKHmOIOuc%3D&re >>>>>>> served=0 >>>>>>> >>>>>>> Best regards, >>>>>>> Karen Moore >>>>>>> RFC Production Center >>>>>>> >>>>>>> >>>>>>> >>>>>>>> On Dec 9, 2025, at 12:25 AM, >>>>>>>> >>>>>>> [email protected] wrote: >>>>>>> >>>>>>>> Dear RFC Editor team, Karen, Alice, >>>>>>>> >>>>>>>> I would like to apologise for the long response time, but we wanted to >>>>>>>> >>>>>>> ensure consolidated feedback. >>>>>>> >>>>>>>> Thank you very much for your already applied changes in >>>>>>>> >>>>>>> https://www/ >>>>>>> .rfc-editor.org%2Fauthors%2Frfc9897- >>>>>>> rfcdiff.html&data=05%7C02%7CMarkus.Amend%40telekom.de%7C29d2ebc >>>>>>> 7c7a443e69f1008de3862d243%7Cbde4dffc4b604cf68b04a5eeb25f5c4f%7 >>>>>>> C0%7C0%7C639010194262164193%7CUnknown%7CTWFpbGZsb3d8eyJFb >>>>>>> XB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTW >>>>>>> FpbCIsIldUIjoyfQ%3D%3D%7C0%7C%7C%7C&sdata=OVGAa2iSk2jsV%2ByK >>>>>>> RWbOFyFxpe7pv6raqLf0btCQ4HU%3D&reserved=0 we agree with, except for >>>>>>> three instances: >>>>>>> >>>>>>>> - The text "However the definition of a path management method, in >>>>>>>> which >>>>>>>> >>>>>>> sequence and when subflows are created" was changed to "However the >>>>>>> definition of a path management method, in which sequence and subflows >>>>>>> are created". The word "when" was removed, but I think this is a >>>>>>> mistake. >>>>>>> Perhaps if the word "and" is also be removed it can be ok, but we >>>>>>> rather prefer >>>>>>> to add "when" again. >>>>>>> >>>>>>>> - The sentence "DCCP defines that if the checksum fails, the receiving >>>>>>>> >>>>>>> endpoint..." is replaced by "If the checksum fails as defined by the >>>>>>> DCCP, the >>>>>>> receiving endpoint...". This changes the meaning of the sentence and we >>>>>>> suggest instead: >>>>>>> >>>>>>>> New: "As defined by DCCP, if the checksum fails, the receiving >>>>>>>> endpoint..." >>>>>>>> >>>>>>>> - The affiliation of an author has changed because the university has >>>>>>>> been >>>>>>>> >>>>>>> renamed. We ask you to replace for the author Veselin Rakocevic the >>>>>>> affiliation >>>>>>> from >>>>>>> >>>>>>>> OLD: City, University of London >>>>>>>> to >>>>>>>> NEW: City St George's, University of London >>>>>>>> >>>>>>>> >>>>>>>> For the <!-- [rfced] ... --> marked comments, you will find our joint >>>>>>>> answers >>>>>>>> >>>>>>> as follows and we will be happy to provide a final review of the >>>>>>> document >>>>>>> once they have been applied: >>>>>>> >>>>>>>> With regard to 1), we, the authors, agree with your change. >>>>>>>> >>>>>>>> Regarding 2), the authors propose the following keywords to be added: >>>>>>>> <keyword>dccp</keyword> >>>>>>>> <keyword>extensions</keyword> >>>>>>>> <keyword>multipath</keyword> >>>>>>>> <keyword>multihomed</keyword> >>>>>>>> <keyword>subflow</keyword> >>>>>>>> <keyword>concurrent</keyword> >>>>>>>> <keyword>simultaneous</keyword> >>>>>>>> <keyword>mobility</keyword> >>>>>>>> <keyword>mpdccp</keyword> >>>>>>>> <keyword>mp-dccp</keyword> >>>>>>>> >>>>>>>> With regard to 3), we, the authors, agree with your text proposal and >>>>>>>> ask >>>>>>>> >>>>>>> you to adopt it. >>>>>>> >>>>>>>> With regard to 4) we prefer our own proposal which better distinguish >>>>>>>> >>>>>>> between ATSSS and hybrid access use case: >>>>>>> >>>>>>>> In addition to the integration into DCCP services, implementers or >>>>>>>> future specifications could choose MP-DCCP for other use cases such >>>>>>>> as 3GPP 5G multi-access solutions (e.g., Access Traffic Steering, >>>>>>>> Switching, and Splitting (ATSSS) as specified in [TS23.501]) or >>>>>>>> hybrid access networks. ATSSS combines 3GPP and non-3GPP access >>>>>>>> >>>>>>> between the user equipment and an operator network, while hybrid access >>>>>>> combines fixed and cellular access between a residential gateway and an >>>>>>> operator network. >>>>>>> >>>>>>>> With regard to 5), we, the authors, agree with your text proposal and >>>>>>>> ask >>>>>>>> >>>>>>> you to adopt it. >>>>>>> >>>>>>>> With regard to 6), we, the authors, agree with your text proposal and >>>>>>>> ask >>>>>>>> >>>>>>> you to adopt it. >>>>>>> >>>>>>>> With regard to 7), we, the authors, agree with your text proposal and >>>>>>>> ask >>>>>>>> >>>>>>> you to adopt it. >>>>>>> >>>>>>>> With regard to 8), we, the authors, agree with your text proposal for >>>>>>>> all >>>>>>>> >>>>>>> Figures 7, 8, 22, 23 and ask you to adopt it. >>>>>>> >>>>>>>> With regard to 9), we, the authors, prefer to have lead text before the >>>>>>>> >>>>>>> Figures 6, 9, 11, 12, 13, 14, 19 according to: >>>>>>> >>>>>>>> - Fig 6: Please change the first two sentences in the first paragraph >>>>>>>> from >>>>>>>> >>>>>>>> Original: >>>>>>>> Some multipath options require confirmation from the remote peer (see >>>>>>>> >>>>>>> Table 4). Such options will be retransmitted by the sender until an >>>>>>> MP_CONFIRM is received or the confirmation of options is considered >>>>>>> irrelevant because the data contained in the options has already been >>>>>>> replaced >>>>>>> by newer information. >>>>>>> >>>>>>>> to NEW including a move of Figure 6: >>>>>>>> Some multipath options require confirmation from the remote peer (see >>>>>>>> >>>>>>> Table 4) for which MP_CONFIRM is specified. >>>>>>> >>>>>>>> >>>>>>>>>> Figure 6 >>>>>>>>>> >>>>>>>> Multipath options which require confirmation will be retransmitted by >>>>>>>> the >>>>>>>> >>>>>>> sender until an MP_CONFIRM is received or the confirmation of options is >>>>>>> considered irrelevant because the data contained in the options has >>>>>>> already >>>>>>> been replaced by newer information. >>>>>>> >>>>>>>> - Fig 9: Please move Figure 9 after the first sentence >>>>>>>> >>>>>>>> Original: >>>>>>>> Figure 9 >>>>>>>> The MP_JOIN option is used to add a new subflow to an existing MP-DCCP >>>>>>>> >>>>>>> connection and REQUIRES a successful establishment of the first subflow >>>>>>> using MP_KEY. The Connection Identifier (CI) is the one from the peer >>>>>>> host, >>>>>>> which ... >>>>>>> >>>>>>>> NEW: >>>>>>>> The MP_JOIN option is used to add a new subflow to an existing MP-DCCP >>>>>>>> >>>>>>> connection and REQUIRES a successful establishment of the first subflow >>>>>>> using MP_KEY. >>>>>>> >>>>>>>>>> Figure 9 >>>>>>>>>> >>>>>>>> The Connection Identifier (CI) is the one from the peer host, which ... >>>>>>>> >>>>>>>> - Fig 11: Please add the following guiding text and resolve the >>>>>>>> reference to >>>>>>>> >>>>>>> section 4 (Security Considerations) accordingly: >>>>>>> >>>>>>>> NEW: MP-DCCP protects against some man in the middle attacks as further >>>>>>>> >>>>>>> outlined in [Section 4]. The basis of this protection is laid by an >>>>>>> initial exchange >>>>>>> of keys during the MP-DCCP connection setup, for which MP_KEY is >>>>>>> introduced. >>>>>>> >>>>>>>> - Fig 12: Please add the following lead text and resolve the reference >>>>>>>> to >>>>>>>> >>>>>>> RFC4340 accordingly: >>>>>>> >>>>>>>> NEW: DCCP [RFC4340] defines a packet sequencing scheme that continues >>>>>>>> >>>>>>> to apply to the individual DCCP subflows within an MP-DCCP connection. >>>>>>> However, for the operation of MP-DCPP, the order of packets within an >>>>>>> MP- >>>>>>> DCCP connection MUST be known before assigning packets to subflows in >>>>>>> order to apply received multipath options in the correct order or to >>>>>>> recognise >>>>>>> whether delayed multipath options are obsolete. Therefore MP_SEQ is >>>>>>> introduced and can also be used to re-order data packets on the >>>>>>> receiver side. >>>>>>> >>>>>>>> - Fig 13: Please add the following guiding text and resolve the >>>>>>>> reference to >>>>>>>> >>>>>>> section 4 (Security Considerations) accordingly: >>>>>>> >>>>>>>> NEW: MP-DCCP protects against some man in the middle attacks as further >>>>>>>> >>>>>>> outlined in [Section 4]. Once an MP-DCCP connection has been >>>>>>> established, >>>>>>> the MP_HMAC option introduced here provides further protection based on >>>>>>> the key material exchanged with MP_KEY when the connection is >>>>>>> established. >>>>>>> >>>>>>>> - Fig 14: Please move Figure 14 after the first paragraph >>>>>>>> >>>>>>>> Original: >>>>>>>> Figure 14 >>>>>>>> The MP_RTT suboption is used to transmit RTT values and Age >>>>>>>> (represented >>>>>>>> >>>>>>> in milliseconds) that belong to the path over which this information is >>>>>>> transmitted. This information is useful for the receiving host to >>>>>>> calculate the >>>>>>> RTT difference between the subflows and to estimate whether missing data >>>>>>> has been lost. >>>>>>> >>>>>>>> NEW: >>>>>>>> The MP_RTT suboption is used to transmit RTT values and Age >>>>>>>> (represented >>>>>>>> >>>>>>> in milliseconds) that belong to the path over which this information is >>>>>>> transmitted. This information is useful for the receiving host to >>>>>>> calculate the >>>>>>> RTT difference between the subflows and to estimate whether missing data >>>>>>> has been lost. >>>>>>> >>>>>>>>>> Figure 14 >>>>>>>>>> >>>>>>>> - Fig 19: Please add the following lead text and resolve the reference >>>>>>>> to >>>>>>>> >>>>>>> RFC4340 accordingly: >>>>>>> >>>>>>>> NEW: The mechanism available in DCCP [RFC4340] for closing a connection >>>>>>>> >>>>>>> cannot give an indication for closing an MP-DCCP connection which >>>>>>> typically >>>>>>> contains several DCCP subflows and therefore one cannot conclude from >>>>>>> the >>>>>>> closing of a subflow to the closing of an MP-DCCP connection. This is >>>>>>> solved >>>>>>> by introducing MP_CLOSE. >>>>>>> >>>>>>>> With regard to 10), we, the authors, agree with your text proposal and >>>>>>>> ask >>>>>>>> >>>>>>> you to adopt it. >>>>>>> >>>>>>>> With regard to 11), we, the authors, agree with your second text >>>>>>>> proposal >>>>>>>> >>>>>>> introducing " hosts' " and ask you to adopt it. >>>>>>> >>>>>>>> With regard to 12), we, the authors, think it would be useful to >>>>>>>> change from >>>>>>>> >>>>>>> a bulleted list to an ordered list instead. In addition to your >>>>>>> suggestion, we >>>>>>> would like you to ask to change both lists, the one for the "basic >>>>>>> initial >>>>>>> handshaking" and the one describing the handshake for the "subsequent >>>>>>> subflows". >>>>>>> >>>>>>>> With regard to 13), we, the authors, agree with your text proposal for >>>>>>>> both >>>>>>>> >>>>>>> section 3.2.8 and 3.2.9 and ask you to adopt it. >>>>>>> >>>>>>>> With regard to 14), we, the authors, agree with your change. >>>>>>>> >>>>>>>> With regard to 15), we, the authors, agree with your text proposal and >>>>>>>> ask >>>>>>>> >>>>>>> you to adopt it. >>>>>>> >>>>>>>> With regard to 16), we, the authors, agree that "appropriate one" is >>>>>>>> not >>>>>>>> >>>>>>> necessary. However, we prefer a slightly different rephrasing and ask >>>>>>> you to >>>>>>> adopt the following: >>>>>>> >>>>>>>> NEW: In the case of path mobility (Section 3.11.1), only one path can >>>>>>>> be >>>>>>>> >>>>>>> used at a time and MUST have the highest available priority value. That >>>>>>> also >>>>>>> includes the prio numbers 1 and 2. >>>>>>> >>>>>>>> With regard to 17), we, the authors, agree with your text proposal and >>>>>>>> ask >>>>>>>> >>>>>>> you to adopt it. >>>>>>> >>>>>>>> With regard to 18), we, the authors, hope that the following sentence >>>>>>>> is >>>>>>>> >>>>>>> clearer and can be used instead: >>>>>>> >>>>>>>> NEW: Please note that the Key Data sent in DCCP-CloseReq will not be >>>>>>>> the >>>>>>>> >>>>>>> same as the Key Data sent in DCCP-Close as these originate from >>>>>>> different ends >>>>>>> of the connection >>>>>>> >>>>>>>> With regard to 19), we, the authors, agree with your text proposal and >>>>>>>> ask >>>>>>>> >>>>>>> you to adopt it. >>>>>>> >>>>>>>> With regard to 20), we, the authors, agree with your change. >>>>>>>> >>>>>>>> With regard to 21), we, the authors, propose to simply remove "own". >>>>>>>> >>>>>>>> With regard to 22), we, the authors, agree with your text proposal and >>>>>>>> ask >>>>>>>> >>>>>>> you to adopt it. >>>>>>> >>>>>>>> With regard to 23), we, the authors, agree with your text proposal and >>>>>>>> ask >>>>>>>> >>>>>>> you to adopt it. >>>>>>> >>>>>>>> With regard to 24), we, the authors, agree with your text proposal and >>>>>>>> ask >>>>>>>> >>>>>>> you to adopt it. >>>>>>> >>>>>>>> With regard to 25), we, the authors, agree with your text proposal and >>>>>>>> ask >>>>>>>> >>>>>>> you to adopt it. >>>>>>> >>>>>>>> With regard to 26), we, the authors, agree with your text proposal and >>>>>>>> ask >>>>>>>> >>>>>>> you to adopt it. >>>>>>> >>>>>>>> With regard to 27), we, the authors, agree with your text proposal and >>>>>>>> ask >>>>>>>> >>>>>>> you to adopt it. >>>>>>> >>>>>>>> With regard to 28), we, the authors, determined a typo and ask you to >>>>>>>> >>>>>>> replace wrong [RFC4043] with correct [RFC4340]. Please also remove the >>>>>>> bibliography entry of [RFC4043], as it is otherwise not used anywhere >>>>>>> else. >>>>>>> >>>>>>>> With regard to 29), we, the authors, agree with your text proposal in >>>>>>>> a) and >>>>>>>> >>>>>>> ask you to adopt it. Also we agree with your applied change described >>>>>>> in b). >>>>>>> >>>>>>>> With regard to 30), we, the authors, agree with your proposal to add a >>>>>>>> >>>>>>> reference link to the paper and ask you to adopt it. >>>>>>> >>>>>>>> With regard to 31), we, the authors, agree with your proposal in b) >>>>>>>> and ask >>>>>>>> >>>>>>> you to adopt it. For a) we answer as follows: >>>>>>> >>>>>>>> - CLOSED state vs. CLOSE state vs. CLOSING state >>>>>>>> According to >>>>>>>> >>>>>>> https://datat/ >>>>>>> racker.ietf.org%2Fdoc%2Fhtml%2Frfc4340%23section- >>>>>>> 4.3&data=05%7C02%7CMarkus.Amend%40telekom.de%7C29d2ebc7c7a44 >>>>>>> 3e69f1008de3862d243%7Cbde4dffc4b604cf68b04a5eeb25f5c4f%7C0%7C >>>>>>> 0%7C639010194262181212%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU >>>>>>> 1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIs >>>>>>> IldUIjoyfQ%3D%3D%7C0%7C%7C%7C&sdata=frUpY29Mj1uV2Cbal0oru5fj% >>>>>>> 2FxQ%2B4usRSrbk9bZMPGo%3D&reserved=0, there are the states CLOSED >>>>>>> and CLOSING, which we wanted to refer to consistently. Every occurrence >>>>>>> of >>>>>>> CLOSED and CLOSING is therefore OK from our point of view, while the >>>>>>> occurrence of CLOSE (we found it once in the text) should be CLOSED. >>>>>>> Otherwise, we found CLOSE as a suffix of MP_CLOSE and MP_FAST_CLOSE, >>>>>>> which does not describe a state but an action. >>>>>>> >>>>>>>> - Client and Server vs. client and server (as well as 'the client and >>>>>>>> the server') >>>>>>>> We prefer "Client and Server" >>>>>>>> >>>>>>>> - Congestion Control procedure vs. congestion control scheme >>>>>>>> We are fine if you replace congestion control scheme by Congestion >>>>>>>> Control >>>>>>>> >>>>>>> procedure >>>>>>> >>>>>>>> - "Fast Close" vs. fast close >>>>>>>> We are fine with your proposal to change "Fast Close" to "fast close" >>>>>>>> and ask >>>>>>>> >>>>>>> you to adopt it. >>>>>>> >>>>>>>> - Feature number 10 vs. feature number 10 >>>>>>>> We prefer any occurrence of feature number of Feature number to be >>>>>>>> >>>>>>> replaced with Feature Number according to IANA style >>>>>>> >>>>>>>> - Length vs. length >>>>>>>> If the term length refers to the Length data field of a header option, >>>>>>>> we >>>>>>>> >>>>>>> prefer the capitalisation of Length instead of length and ask you to >>>>>>> adopt this >>>>>>> >>>>>>>> - handshake procedure/process vs. handshaking procedure/process >>>>>>>> We prefer overall "handshake procedure" and ask you to adopt this. >>>>>>>> >>>>>>>> - Key Type vs. Key types vs. key type >>>>>>>> We generally prefer Key Type (singular) or Key Types (plural) and ask >>>>>>>> you to >>>>>>>> >>>>>>> adopt this. >>>>>>> >>>>>>>> - Multipath Capability vs. multipath capability >>>>>>>> We prefer in general multipath capability and ask you to adopt this. >>>>>>>> >>>>>>>> - Multipath feature vs. multipath feature >>>>>>>> We prefer Multipath Feature except for the occurrence in Appendix A >>>>>>>> where >>>>>>>> >>>>>>> it has a general meaning and is not referring to the Multipath Capable >>>>>>> Feature. >>>>>>> That is why we additionally suggest to replace in Appendix A "multipath >>>>>>> features" with "multipath characteristics". >>>>>>> >>>>>>>> - Multipath option vs. multipath option vs. MP option >>>>>>>> We prefer the general usage of Multipath Option (singular) or Multipath >>>>>>>> >>>>>>> Options (plural) and ask you to adopt this. >>>>>>> >>>>>>>> - Multipath Capable Feature vs. Multipath Capable feature vs. >>>>>>>> MP-Capable >>>>>>>> >>>>>>> feature vs. MP_CAPABLE feature >>>>>>> >>>>>>>> We prefer the general usage of "Multipath Capable Feature" and ask you >>>>>>>> to >>>>>>>> >>>>>>> adopt this. >>>>>>> >>>>>>>> - Nonce vs. nonce >>>>>>>> We prefer the general usage of "Nonce" and ask you to adopt this. >>>>>>>> >>>>>>>> - Plain Text Key (Table 5) vs. Plain text key (Table 9) >>>>>>>> We prefer the general usage of "Plain text Key" and ask you to adopt >>>>>>>> this. >>>>>>>> >>>>>>>> - Reset Code vs. reset code >>>>>>>> We prefer the general usage of "Reset Code" and ask you to adopt this. >>>>>>>> >>>>>>>> - Remove Address vs. Remove address (Tables 3 and 8) >>>>>>>> We prefer the general usage of "Remove Address" and ask you to adopt >>>>>>>> this. >>>>>>>> >>>>>>>> SHA256 vs. SHA-256 >>>>>>>> According to the terminology in RFC6234 we prefer to change SHA256 to >>>>>>>> >>>>>>> SHA-256 and ask you to adopt this. >>>>>>> >>>>>>>> With regard to 32), we, the authors, agree with your proposal in a) >>>>>>>> and c) >>>>>>>> >>>>>>> and ask you to adopt it. For b) we prefer Multipath DCCP without hyphen >>>>>>> and >>>>>>> ask you to adopt it. >>>>>>> >>>>>>>> With regard to 33), we, the authors, agree with your concern and ask >>>>>>>> you to >>>>>>>> >>>>>>> adopt the following: >>>>>>> >>>>>>>> Original: ... that updates the (traditionally asymmetric) connection- >>>>>>>> >>>>>>> establishment procedures for DCCP. >>>>>>> >>>>>>>> New: that updates the asymmetric connection-establishment procedures >>>>>>>> for >>>>>>>> >>>>>>> DCCP. >>>>>>> >>>>>>>> >>>>>>>> By the way, while editing the document, we noticed that >>>>>>>> >>>>>>> https://www/ >>>>>>> .rfc- >>>>>>> editor.org%2Fauth48%2Frfc9897&data=05%7C02%7CMarkus.Amend%40tel >>>>>>> ekom.de%7C29d2ebc7c7a443e69f1008de3862d243%7Cbde4dffc4b604cf6 >>>>>>> 8b04a5eeb25f5c4f%7C0%7C0%7C639010194262195396%7CUnknown%7 >>>>>>> CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOi >>>>>>> JXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C0%7C%7C%7C&sdata= >>>>>>> rZHoWUJ%2F0EUIgq3IjFcb%2BSoK%2FPLHPSLd8%2ByhfZraQBQ%3D&reserv >>>>>>> ed=0 is broken. >>>>>>> >>>>>>>> BR >>>>>>>> >>>>>>>> Markus & co-authors >>>>>>>> >>>>>>>> >>>>>>>>> -----Ursprüngliche Nachricht----- >>>>>>>>> Von: [email protected] <[email protected]> >>>>>>>>> Gesendet: Dienstag, 28. Oktober 2025 07:01 >>>>>>>>> An: Amend, Markus <[email protected]>; >>>>>>>>> [email protected]; [email protected]; >>>>>>>>> [email protected]; [email protected] >>>>>>>>> Cc: [email protected]; [email protected]; >>>>>>>>> [email protected]; >>>>>>>>> [email protected]; [email protected]; auth48archive@rfc- >>>>>>>>> >>>>>>> editor.org >>>>>>> >>>>>>>>> Betreff: Re: AUTH48: RFC-to-be 9897 >>>>>>>>> <draft-ietf-tsvwg-multipath-dccp-24> >>>>>>>>> for your review >>>>>>>>> >>>>>>>>> Authors, >>>>>>>>> >>>>>>>>> While reviewing this document during AUTH48, please resolve (as >>>>>>>>> >>>>>>> necessary) >>>>>>> >>>>>>>>> the following questions, which are also in the source file. >>>>>>>>> >>>>>>>>> 1) <!--[rfced] Please note that the title has been updated as >>>>>>>>> follows. The abbreviation has been expanded per Section 3.6 of >>>>>>>>> RFC 7322 ("RFC Style Guide"). Please review. >>>>>>>>> >>>>>>>>> Original: >>>>>>>>> DCCP Extensions for Multipath Operation with Multiple Addresses >>>>>>>>> >>>>>>>>> Current: >>>>>>>>> Datagram Congestion Control Protocol (DCCP) Extensions for >>>>>>>>> Multipath Operation with Multiple Addresses >>>>>>>>> --> >>>>>>>>> >>>>>>>>> >>>>>>>>> 2) <!-- [rfced] Please insert any keywords (beyond those that appear >>>>>>>>> in >>>>>>>>> the title) for use on >>>>>>>>> https://www/ >>>>>>>>> .rfc- >>>>>>>>> >>>>>>>>> >>>>>>> editor.org%2Fsearch&data=05%7C02%7CMarkus.Amend%40telekom.de%7C >>>>>>> >>>>>>>>> >>>>>>> 34f67a154541449bd12808de15e77765%7Cbde4dffc4b604cf68b04a5eeb2 >>>>>>> >>>>>>>>> >>>>>>> 5f5c4f%7C0%7C0%7C638972281329016204%7CUnknown%7CTWFpbGZsb >>>>>>> >>>>>>>>> >>>>>>> 3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsI >>>>>>> >>>>>>>>> >>>>>>> kFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C0%7C%7C%7C&sdata=BpyjDex8PS3 >>>>>>> >>>>>>>>> Nm16BAG1KlgLsb%2FkKPwMOOHbrqMf9UUU%3D&reserved=0. --> >>>>>>>>> >>>>>>>>> >>>>>>>>> 3) <!--[rfced] Please clarify what "This" refers to in the following >>>>>>>>> sentence - is it "These fundamentals"? >>>>>>>>> >>>>>>>>> Current: >>>>>>>>> This also applies to the DCCP sequencing scheme, which is >>>>>>>>> packet-based (Section 4.2 of [RFC4340]) and the principles for loss >>>>>>>>> and retransmission of features as described in more detail in >>>>>>>>> Section 6.6.3 of [RFC4340]. >>>>>>>>> >>>>>>>>> Perhaps: >>>>>>>>> These fundamentals also apply to the DCCP sequencing scheme, which is >>>>>>>>> packet-based (Section 4.2 of [RFC4340]), and to the principles for >>>>>>>>> loss and retransmission of features as described in more detail in >>>>>>>>> Section 6.6.3 of [RFC4340]. >>>>>>>>> --> >>>>>>>>> >>>>>>>>> >>>>>>>>> 4) <!--[rfced] Please clarify the latter part of this sentence, >>>>>>>>> specifically "between" and the slash ("/"). Is the intended >>>>>>>>> meaning that hybrid access networks combine access between the >>>>>>>>> user equipment "or" residential gateway "and" an operator network >>>>>>>>> (option A) or is it between the user equipment "and" a >>>>>>>>> residential gateway within an operator network (option B)? >>>>>>>>> >>>>>>>>> Original: >>>>>>>>> In addition to the integration into DCCP services, implementers or >>>>>>>>> future specification could choose MP-DCCP for other use cases like >>>>>>>>> 3GPP 5G multi-access solutions (e.g., Access Traffic Steering, >>>>>>>>> Switching, and Splitting (ATSSS) specified in [TS23.501]) or hybrid >>>>>>>>> access networks that either combine a 3GPP and a non-3GPP access or a >>>>>>>>> fixed and cellular access between user-equipment/residential gateway >>>>>>>>> and operator network. >>>>>>>>> >>>>>>>>> Perhaps A: >>>>>>>>> In addition to the integration into DCCP services, implementers or >>>>>>>>> future specifications could choose MP-DCCP for other use cases such >>>>>>>>> as 3GPP 5G multi-access solutions (e.g., Access Traffic Steering, >>>>>>>>> Switching, and Splitting (ATSSS) as specified in [TS23.501]) or >>>>>>>>> hybrid access networks that combine either 3GPP and non-3GPP access >>>>>>>>> or fixed and cellular access between the user equipment or >>>>>>>>> residential gateway and an operator network. >>>>>>>>> >>>>>>>>> or >>>>>>>>> Perhaps B: >>>>>>>>> In addition to the integration into DCCP services, implementers or >>>>>>>>> future specifications could choose MP-DCCP for other use cases such >>>>>>>>> as 3GPP 5G multi-access solutions (e.g., Access Traffic Steering, >>>>>>>>> Switching, and Splitting (ATSSS) as specified in [TS23.501]) or >>>>>>>>> hybrid access networks that combine either 3GPP and non-3GPP access >>>>>>>>> or fixed and cellular access between the user equipment and >>>>>>>>> residential gateway within an operator network. >>>>>>>>> --> >>>>>>>>> >>>>>>>>> >>>>>>>>> 5) <!--[rfced] Section 3.1: Would you like to add text to introduce >>>>>>>>> the numbered list that immediately follows Figure 4? >>>>>>>>> >>>>>>>>> Original: >>>>>>>>> 1. The Client indicates support for both MP-DCCP versions 1 and 0, >>>>>>>>> with a preference for version 1. >>>>>>>>> >>>>>>>>> 2. Server agrees on using MP-DCCP version 1 indicated by the first >>>>>>>>> value, and supplies its own preference list with the following >>>>>>>>> values. >>>>>>>>> >>>>>>>>> 3. MP-DCCP is then enabled between the Client and Server with >>>>>>>>> version 1. >>>>>>>>> >>>>>>>>> Perhaps: >>>>>>>>> This example illustrates the following: >>>>>>>>> >>>>>>>>> 1. The Client indicates support for both MP-DCCP versions 1 and 0, >>>>>>>>> with a preference for version 1. >>>>>>>>> >>>>>>>>> 2. The Server agrees on using MP-DCCP version 1 indicated by the first >>>>>>>>> value and supplies its own preference list with the following >>>>>>>>> values. >>>>>>>>> >>>>>>>>> 3. MP-DCCP is then enabled between the Client and Server with >>>>>>>>> version 1. >>>>>>>>> --> >>>>>>>>> >>>>>>>>> >>>>>>>>> 6) <!--[rfced] Table 4: May we update these IANA-registered >>>>>>>>> descriptions as >>>>>>>>> follows for clarity? If so, we will ask IANA to update the registry >>>>>>>>> accordingly. (Also, they will be updated in Table 8.) >>>>>>>>> >>>>>>>>> Original: >>>>>>>>> MP_OPT=7 MP_ADDADDR Advertise additional address(es)/port(s) >>>>>>>>> MP_OPT=8 MP_REMOVEADDR Remove address(es)/port(s) >>>>>>>>> >>>>>>>>> Perhaps: >>>>>>>>> MP_OPT=7 MP_ADDADDR Advertise one or more additional >>>>>>>>> addresses/ports >>>>>>>>> MP_OPT=8 MP_REMOVEADDR Remove one or more addresses/ports >>>>>>>>> --> >>>>>>>>> >>>>>>>>> >>>>>>>>> 7) <!--[rfced] May we rephrase this sentence for improved readability? >>>>>>>>> >>>>>>>>> Original: >>>>>>>>> This could happen if a datagram with MP_PRIO and a first MP_SEQ_1 >>>>>>>>> and another datagram with MP_ADDADDR and a second MP_SEQ_2 are >>>>>>>>> received in short succession. >>>>>>>>> >>>>>>>>> Perhaps: >>>>>>>>> This could happen if the following are received in short >>>>>>>>> succession: a datagram with MP_PRIO and a first MP_SEQ_1 and >>>>>>>>> another datagram with MP_ADDADDR and a second MP_SEQ_2. >>>>>>>>> --> >>>>>>>>> >>>>>>>>> >>>>>>>>> 8) <!--[rfced] Figure Titles >>>>>>>>> >>>>>>>>> a) Should the titles of Figures 7 and 8 include "MP_CONFIRM" >>>>>>>>> (instead of "MP-DCCP CONFIRM") to match the content in the >>>>>>>>> figures? >>>>>>>>> >>>>>>>>> Note that the running text refers to the procedure as "MP-DCCP >>>>>>>>> confirm" - should the running text be updated as well for consistency? >>>>>>>>> Please let us know if "MP_CONFIRM", "MP-DCCP CONFIRM", or other is >>>>>>>>> preferred. >>>>>>>>> >>>>>>>>> Current (Figure 7): >>>>>>>>> Example MP-DCCP CONFIRM Procedure >>>>>>>>> >>>>>>>>> Perhaps: >>>>>>>>> Example MP_CONFIRM Procedure >>>>>>>>> >>>>>>>>> ... >>>>>>>>> Current (Figure 8) >>>>>>>>> Example MP-DCCP CONFIRM Procedure with an Outdated Suboption >>>>>>>>> >>>>>>>>> Perhaps: >>>>>>>>> Example MP_CONFIRM Procedure with an Outdated Suboption >>>>>>>>> >>>>>>>>> >>>>>>>>> b) Should the title of Figure 22 perhaps be "Example MP_ADDADDR >>>>>>>>> Procedure" rather than "Example MP-DCCP ADDADDR Procedure" to match >>>>>>>>> the content in the figure? We note that "MP-DCCP ADDADDR" is not used >>>>>>>>> in the running text. >>>>>>>>> >>>>>>>>> Current: >>>>>>>>> Example MP-DCCP ADDADDR Procedure >>>>>>>>> >>>>>>>>> Perhaps: >>>>>>>>> Example MP_ADDADDR Procedure >>>>>>>>> >>>>>>>>> c) Should the title of Figure 23 perhaps be "Example MP_ADDADDR >>>>>>>>> Procedure" rather than "Example MP-DCCP REMOVEADDR Procedure" to >>>>>>>>> match >>>>>>>>> the content in the figure? We note that "MP-DCCP REMOVEADDR" is not >>>>>>>>> used in the running text. >>>>>>>>> >>>>>>>>> Current: >>>>>>>>> Example MP-DCCP REMOVEADDR Procedure >>>>>>>>> >>>>>>>>> Perhaps: >>>>>>>>> Example MP_REMOVEADDR Procedure >>>>>>>>> --> >>>>>>>>> >>>>>>>>> >>>>>>>>> 9) <!--[rfced] We note that Figures 9, 11, and 19 are listed first >>>>>>>>> within >>>>>>>>> their sections without any lead-in text. Is this intended, or >>>>>>>>> would you like to add a lead-in sentence for consistency with the >>>>>>>>> other sections? >>>>>>>>> --> >>>>>>>>> >>>>>>>>> >>>>>>>>> 10) <!--[rfced] Per RFCs 2119 and 8174, may we update "REQUIRES" to >>>>>>>>> "REQUIRED" for correctness as shown below? >>>>>>>>> >>>>>>>>> Original: >>>>>>>>> The MP_JOIN option is used to add a new subflow to an existing MP- >>>>>>>>> DCCP connection and REQUIRES a successful establishment of the first >>>>>>>>> subflow using MP_KEY. >>>>>>>>> >>>>>>>>> Perhaps: >>>>>>>>> The MP_JOIN option is used to add a new subflow to an existing MP- >>>>>>>>> DCCP connection, and a successful establishment of the first >>>>>>>>> subflow using MP_KEY is REQUIRED. >>>>>>>>> --> >>>>>>>>> >>>>>>>>> >>>>>>>>> 11) <!--[rfced] Please clarify this sentence, specifically "from the >>>>>>>>> both >>>>>>>>> hosts Key Data". >>>>>>>>> >>>>>>>>> Original: >>>>>>>>> Together with the derived key from the both hosts >>>>>>>>> Key Data described in Section 3.2.4, the Nonce value builds the basis >>>>>>>>> to calculate the HMAC used in the handshaking process as described in >>>>>>>>> Section 3.3 to avoid replay attacks. >>>>>>>>> >>>>>>>>> Perhaps: >>>>>>>>> Together with the derived key from both hosts that exchange >>>>>>>>> Key Data as described in Section 3.2.4, the Nonce value builds the >>>>>>>>> basis >>>>>>>>> to calculate the Hash-based Message Authentication Code (HMAC) used in >>>>>>>>> the handshaking process described in Section 3.3 to avoid replay >>>>>>>>> attacks. >>>>>>>>> >>>>>>>>> Or: >>>>>>>>> Together with the derived key from both hosts' >>>>>>>>> Key Data (as described in Section 3.2.4), the Nonce value builds the >>>>>>>>> basis >>>>>>>>> to calculate the Hash-based Message Authentication Code (HMAC) used in >>>>>>>>> the >>>>>>>>> handshaking process (as described in Section 3.3) to avoid replay >>>>>>>>> attacks. >>>>>>>>> --> >>>>>>>>> >>>>>>>>> >>>>>>>>> 12) <!--[rfced] In Section 3.2.6, the text refers to the >>>>>>>>> "second and third step" of the handshake, so should the list >>>>>>>>> in Section 3.3 be an ordered list instead of a bulleted list as >>>>>>>>> shown below? >>>>>>>>> >>>>>>>>> Section 3.2.6: >>>>>>>>> In addition, it provides authentication for subflows joining an >>>>>>>>> existing MP_DCCP connection, as described in the second and third >>>>>>>>> step of the handshake of a subsequent subflow in Section 3.3. >>>>>>>>> >>>>>>>>> Original (Section 3.3): >>>>>>>>> The basic initial handshake for the first subflow is as follows: >>>>>>>>> >>>>>>>>> * Host A sends a DCCP-Request with the MP-Capable feature Change >>>>>>>>> request and the MP_KEY option with a Host-specific CI-A and a KeyA >>>>>>>>> for each of the supported key types as described in Section 3.2.4. >>>>>>>>> CI-A is a unique identifier during the lifetime of an MP-DCCP >>>>>>>>> connection. >>>>>>>>> >>>>>>>>> * Host B sends a DCCP-Response with Confirm feature for MP-Capable >>>>>>>>> and the MP_Key option with a unique Host-specific CI-B and a >>>>>>>>> single Host-specific KeyB. The type of the key is chosen from the >>>>>>>>> list of supported types from the previous request. >>>>>>>>> >>>>>>>>> * Host A sends a DCCP-Ack to confirm the proper key exchange. >>>>>>>>> >>>>>>>>> * Host B sends a DCCP-Ack to complete the handshake and set both >>>>>>>>> connection ends to the OPEN state. >>>>>>>>> >>>>>>>>> Perhaps (Section 3.3): >>>>>>>>> The basic initial handshake for the first subflow is as follows: >>>>>>>>> >>>>>>>>> 1. Host A sends a DCCP-Request with the MP-Capable feature change >>>>>>>>> request and the MP_KEY option with a Host-specific CI-A and a KeyA >>>>>>>>> for each of the supported key types as described in Section 3.2.4. >>>>>>>>> CI-A is a unique identifier during the lifetime of an MP-DCCP >>>>>>>>> connection. >>>>>>>>> >>>>>>>>> 2. Host B sends a DCCP-Response with a Confirm feature for MP-Capable >>>>>>>>> and the MP_Key option with a unique Host-specific CI-B and a >>>>>>>>> single Host-specific KeyB. The type of the key is chosen from the >>>>>>>>> list of supported types from the previous request. >>>>>>>>> >>>>>>>>> 3. Host A sends a DCCP-Ack to confirm the proper key exchange. >>>>>>>>> >>>>>>>>> 4. Host B sends a DCCP-Ack to complete the handshake and set both >>>>>>>>> connection ends to the OPEN state. >>>>>>>>> --> >>>>>>>>> >>>>>>>>> >>>>>>>>> 13) <!--[rfced] May we reword this sentence for better readability as >>>>>>>>> shown below? Note that this sentence appears in Sections 3.2.8 >>>>>>>>> and 3.2.9. >>>>>>>>> >>>>>>>>> Original: >>>>>>>>> In the same way as for MP_JOIN, the key for the HMAC algorithm, in >>>>>>>>> the case of the message transmitted by Host A, will be d-KeyA, and >>>>>>>>> in the case of Host B, d-KeyB. >>>>>>>>> >>>>>>>>> Perhaps: >>>>>>>>> Similar to MP_JOIN, the key for the HMAC algorithm will be d-KeyA >>>>>>>>> when the message is transmitted by Host A and d-KeyB when >>>>>>>>> transmitted by Host B. >>>>>>>>> --> >>>>>>>>> >>>>>>>>> >>>>>>>>> 14) <!-- [rfced] FYI: For consistency with the other figures, we >>>>>>>>> fixed the >>>>>>>>> bit ruler on Figure 18. (We extended the right side of the box by one >>>>>>>>> space so that the placement of the final "1" is over the minus sign >>>>>>>>> rather than the plus sign.) Please let us know if this is not >>>>>>>>> accurate. >>>>>>>>> --> >>>>>>>>> >>>>>>>>> >>>>>>>>> 15) <!--[rfced] Section 3.2.10. Please confirm if "Cellular paths" >>>>>>>>> should >>>>>>>>> be singular in the first sentence below, as we note the singular >>>>>>>>> form in the sentence that follows as well as in use cases #2 and #3. >>>>>>>>> >>>>>>>>> Original: >>>>>>>>> 1. Setting Wi-Fi path to Primary and Cellular paths to Secondary. >>>>>>>>> In this case Wi-Fi will be used and Cellular will be used only >>>>>>>>> if the Wi-Fi path is congested or not available. >>>>>>>>> >>>>>>>>> Perhaps: >>>>>>>>> 1. Setting the Wi-Fi path to Primary and Cellular path to Secondary. >>>>>>>>> In this case, Wi-Fi will be used and Cellular will be used only >>>>>>>>> if the Wi-Fi path is congested or not available. >>>>>>>>> --> >>>>>>>>> >>>>>>>>> >>>>>>>>> 16) <!--[rfced] Please clarify "and MUST be the appropriate one" - is >>>>>>>>> "appropriate one" essential to the sentence, or could it be >>>>>>>>> reworded as "the path MUST have the highest available priority >>>>>>>>> value" as shown below? >>>>>>>>> >>>>>>>>> Original: >>>>>>>>> In the case of path mobility (Section 3.11.1), only one path can be >>>>>>>>> used at a time and MUST be the appropriate one that has the highest >>>>>>>>> available priority value including also the prio numbers 1 and 2. >>>>>>>>> >>>>>>>>> Perhaps: >>>>>>>>> In the case of path mobility (Section 3.11.1), only one path can be >>>>>>>>> used at a time, and the path MUST have the highest available >>>>>>>>> priority value that includes the prio numbers 1 and 2. >>>>>>>>> --> >>>>>>>>> >>>>>>>>> >>>>>>>>> 17) <!--[rfced] Please clarify "in by"; is the intended meaning >>>>>>>>> included >>>>>>>>> "in" or "by" the MP_CLOSE option? Also, should the second "must" >>>>>>>>> be "MUST"? >>>>>>>>> >>>>>>>>> Original: >>>>>>>>> To protect from unauthorized shutdown of a multi-path connection, >>>>>>>>> the selected Key Data of the peer host during the handshaking >>>>>>>>> procedure MUST be included in by the MP_CLOSE option and must be >>>>>>>>> validated by the peer host. >>>>>>>>> >>>>>>>>> Perhaps (if "in"): >>>>>>>>> To protect from unauthorized shutdown of a multipath connection, >>>>>>>>> the selected Key Data of the peer host MUST be included in the >>>>>>>>> MP_CLOSE option during the handshaking procedure and MUST be >>>>>>>>> validated by the peer host. >>>>>>>>> --> >>>>>>>>> >>>>>>>>> >>>>>>>>> 18) <!--[rfced] We are having trouble parsing this sentence. Please >>>>>>>>> clarify what items "between" refers to. >>>>>>>>> >>>>>>>>> Original: >>>>>>>>> Note, the Key Data is different between MP_CLOSE option carried >>>>>>>>> by DCCP-CloseReq or DCCP-Close. >>>>>>>>> --> >>>>>>>>> >>>>>>>>> >>>>>>>>> 19) <!--[rfced] Figure 20: May we change "Data TBD" to simply "Data", >>>>>>>>> as shown below? It is already explained directly below the figure: >>>>>>>>> "The Data field can carry any data..." >>>>>>>>> >>>>>>>>> We note that "TBD" is used for a different purpose (in Table 3) >>>>>>>>> to refer to the option length being "TBD" when the option type is >11. >>>>>>>>> >>>>>>>>> Original: >>>>>>>>> |0 0 1 0 1 1 1 0| var |0 0 0 0 1 0 1 1| Data TBD | >>>>>>>>> >>>>>>>>> Perhaps: >>>>>>>>> |0 0 1 0 1 1 1 0| var |0 0 0 0 1 0 1 1| Data | >>>>>>>>> --> >>>>>>>>> >>>>>>>>> >>>>>>>>> 20) <!--[rfced] FYI, in Figure 21, "DCCP-ACK" has been updated to >>>>>>>>> "DCCP-Ack" to match usage in the rest of the document. >>>>>>>>> --> >>>>>>>>> >>>>>>>>> >>>>>>>>> 21) <!--[rfced] What does "own" refer to in "own random nonce RA"? >>>>>>>>> >>>>>>>>> Original: >>>>>>>>> Additionally, an own random nonce RA is transmitted >>>>>>>>> with the MP_JOIN. >>>>>>>>> --> >>>>>>>>> >>>>>>>>> >>>>>>>>> 22) <!--[rfced] In Section 3.3, is "message" the "HMAC Message" and >>>>>>>>> "key" >>>>>>>>> the "Key" described in Section 3.2.6? If so, should these terms >>>>>>>>> be capitalized as shown below? Note that there is similar text in >>>>>>>>> the paragraph that follows (which refers to MP_JOIN(B)"). >>>>>>>>> >>>>>>>>> Original: >>>>>>>>> As specified in Section 3.2.6, the HMAC is calculated by taking the >>>>>>>>> leftmost 20 bytes from the SHA256 hash of a HMAC code created by >>>>>>>>> using the nonce received with MP_JOIN(A) and the local nonce RB as >>>>>>>>> message and the derived key described in Section 3.2.4 as key: >>>>>>>>> >>>>>>>>> Perhaps: >>>>>>>>> As specified in Section 3.2.6, the HMAC is calculated by taking the >>>>>>>>> leftmost 20 bytes from the SHA256 hash of an HMAC code that is >>>>>>>>> created by using both the nonce received with MP_JOIN(A) and the >>>>>>>>> local nonce RB as the Message and the derived key as the Key, as >>>>>>>>> described in Section 3.2.4: >>>>>>>>> --> >>>>>>>>> >>>>>>>>> >>>>>>>>> 23) <!--[rfced] May we reword this sentence for improved readability? >>>>>>>>> >>>>>>>>> Original: >>>>>>>>> The states transitioned when moving from the CLOSED to OPEN state >>>>>>>>> during the four-way handshake remain the same as for DCCP, but it is >>>>>>>>> no longer possible to transmit application data while in the REQUEST >>>>>>>>> state. >>>>>>>>> >>>>>>>>> Perhaps: >>>>>>>>> When the state moves from CLOSED to OPEN during the 4-way >>>>>>>>> handshake, the transitioned states remain the same as for DCCP, but >>>>>>>>> it is no longer possible to transmit application data while in the >>>>>>>>> REQUEST state. >>>>>>>>> --> >>>>>>>>> >>>>>>>>> >>>>>>>>> 24) <!--[rfced] Is "aspect of" essential to this sentence or may it be >>>>>>>>> >>>>>>> removed? >>>>>>> >>>>>>>>> Original: >>>>>>>>> Likewise, the host that wants to create the subflows is RECOMMENDED >>>>>>>>> to consider the aspect of available resources and the possible >>>>>>>>> gains. >>>>>>>>> >>>>>>>>> Perhaps: >>>>>>>>> Likewise, it is RECOMMENDED that the host that wants to create the >>>>>>>>> subflows considers the available resources and possible gains. >>>>>>>>> --> >>>>>>>>> >>>>>>>>> >>>>>>>>> 25) <!--[rfced] FYI: We added semicolons to this list for better >>>>>>>>> readability. Please let us know if you prefer otherwise. >>>>>>>>> >>>>>>>>> Original: >>>>>>>>> This can be a dynamic process further facilitated by the means of >>>>>>>>> DCCP and MP-DCCP defined options such as path preference using >>>>>>>>> MP-PRIO, adding or removing DCCP subflows using MP_REMOVEADDR, >>>>>>>>> MP_ADDADDR or DCCP- Close/DCCP-Reset and also path metrics such as >>>>>>>>> packet-loss-rate, CWND or RTT provided by the Congestion Control >>>>>>>>> Algorithm. >>>>>>>>> >>>>>>>>> Current: >>>>>>>>> This can be a dynamic process further facilitated by the means of >>>>>>>>> DCCP and MP-DCCP-defined options such as path preference using >>>>>>>>> MP-PRIO; adding or removing DCCP subflows using MP_REMOVEADDR, >>>>>>>>> MP_ADDADDR, or DCCP-Close/DCCP-Reset; and path metrics such as >>>>>>>>> packet loss rate, congestion window (CWND), or RTT provided by >>>>>>>>> the Congestion Control Algorithm. >>>>>>>>> --> >>>>>>>>> >>>>>>>>> >>>>>>>>> 26) <!--[rfced] Does "SHOULD" refer only to the first part of this >>>>>>>>> sentence? And does "if not available" refer to the "path >>>>>>>>> priority"? If so, may we rephrase the text as shown below for >>>>>>>>> clarity? >>>>>>>>> >>>>>>>>> Original: >>>>>>>>> This process SHOULD respect the path priority configured by the >>>>>>>>> MP_PRIO >>>>>>>>> suboption or if not available pick the most divergent source- >>>>>>>>> destination pair from the original used source-destination pair. >>>>>>>>> >>>>>>>>> Perhaps: >>>>>>>>> This process SHOULD respect the path priority configured by the >>>>>>>>> MP_PRIO suboption; otherwise, if the path priority is not >>>>>>>>> available, pick the most divergent source-destination pair from >>>>>>>>> the originally used source-destination pair. >>>>>>>>> --> >>>>>>>>> >>>>>>>>> >>>>>>>>> 27) <!-- [rfced] Should "Section 4" be "Section 3.6" where the >>>>>>>>> fallback >>>>>>>>> scenario is discussed? Note that this sentence occurs in Section 4. >>>>>>>>> >>>>>>>>> Current: >>>>>>>>> Depending on the security requirements, different Key Types can be >>>>>>>>> negotiated in the handshake procedure or must follow the fallback >>>>>>>>> scenario described in Section 4. >>>>>>>>> >>>>>>>>> Perhaps: >>>>>>>>> Depending on the security requirements, different Key Types can be >>>>>>>>> negotiated in the handshake procedure or must follow the fallback >>>>>>>>> scenario described in Section 3.6. >>>>>>>>> --> >>>>>>>>> >>>>>>>>> >>>>>>>>> 28) <!-- [rfced] We note that RFC 4043 does not contain Section 16. >>>>>>>>> Please >>>>>>>>> confirm which section should be referenced. >>>>>>>>> >>>>>>>>> Current: >>>>>>>>> DCCP already provides means to mitigate the potential impact of >>>>>>>>> middleboxes, in comparison to TCP (see Section 16 of [RFC4043]). >>>>>>>>> --> >>>>>>>>> >>>>>>>>> >>>>>>>>> 29) <!--[rfced] We have included some clarifications about the IANA >>>>>>>>> text >>>>>>>>> below. In addition, please review all of the IANA-related updates >>>>>>>>> carefully and let us know if any further updates are needed. >>>>>>>>> >>>>>>>>> a) FYI: We updated "auth." to "authentication" in Tables 3 and 8 >>>>>>>>> as there is enough space to write it out. We will ask IANA to update >>>>>>>>> the description in the "Multipath Options" registry accordingly. >>>>>>>>> >>>>>>>>> Original: >>>>>>>>> Hash-based message auth. code for MP-DCCP >>>>>>>>> >>>>>>>>> Current: >>>>>>>>> Hash-based message authentication code for MP-DCCP >>>>>>>>> >>>>>>>>> b) FYI: We have updated the headings in Tables 6 and 7 to match >>>>>>>>> the headings listed in the "Feature Numbers" and "MP-DCCP >>>>>>>>> Versions" registries, respectively >>>>>>>>> <https://ww/ >>>>>>>>> w.iana.org%2Fassignments%2Fdccp- >>>>>>>>> >>>>>>>>> >>>>>>> parameters%2F&data=05%7C02%7CMarkus.Amend%40telekom.de%7C34f6 >>>>>>> >>>>>>>>> >>>>>>> 7a154541449bd12808de15e77765%7Cbde4dffc4b604cf68b04a5eeb25f5c >>>>>>> >>>>>>>>> >>>>>>> 4f%7C0%7C0%7C638972281329036102%7CUnknown%7CTWFpbGZsb3d8 >>>>>>> >>>>>>>>> >>>>>>> eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOI >>>>>>> >>>>>>>>> >>>>>>> joiTWFpbCIsIldUIjoyfQ%3D%3D%7C0%7C%7C%7C&sdata=hXvyUPZU2vTlp7 >>>>>>> >>>>>>>>> 2sNtMFMb54YHY72YK3V22aq1RKNFA%3D&reserved=0>. >>>>>>>>> --> >>>>>>>>> >>>>>>>>> >>>>>>>>> 30) <!-- [rfced] We found the URL >>>>>>>>> >>>>>>>>> >>>>>>> <https://dl.a/ >>>>>>> %2F&data=05%7C02%7CMarkus.Amend%40telekom.de%7C29d2ebc7c7a44 >>>>>>> 3e69f1008de3862d243%7Cbde4dffc4b604cf68b04a5eeb25f5c4f%7C0%7C >>>>>>> 0%7C639010194262207054%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU >>>>>>> 1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIs >>>>>>> IldUIjoyfQ%3D%3D%7C0%7C%7C%7C&sdata=ThcUWeCngYzUieHZ%2BLq04 >>>>>>> eZGH%2Fa63LSRnzKBoo9FW1k%3D&reserved=0 >>>>>>> >>>>>>>>> >>>>>>> cm.org%2Fdoi%2F10.1145%2F2413176.2413178&data=05%7C02%7CMark >>>>>>> >>>>>>>>> >>>>>>> us.Amend%40telekom.de%7C34f67a154541449bd12808de15e77765%7Cb >>>>>>> >>>>>>>>> >>>>>>> de4dffc4b604cf68b04a5eeb25f5c4f%7C0%7C0%7C638972281329045189 >>>>>>> >>>>>>>>> >>>>>>> %7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAu >>>>>>> >>>>>>>>> >>>>>>> MDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C0%7C >>>>>>> >>>>>>>>> >>>>>>> %7C%7C&sdata=cnNyX5th1O%2BjzEHYDoTTkQA0Z48kjK2ygqecN1krlDY%3D >>>>>>> >>>>>>>>> &reserved=0> from the ACM >>>>>>>>> Digital Library. Would you like us to update this reference with >>>>>>>>> this URL as shown below? >>>>>>>>> >>>>>>>>> Current: >>>>>>>>> [OLIA] Khalili, R., Gast, N., Popovic, M., Upadhyay, U., and J. >>>>>>>>> Le Boudec, "MPTCP is not pareto-optimal: performance >>>>>>>>> issues and a possible solution", CoNEXT '12: Proceedings >>>>>>>>> of the 8th international conference on Emerging networking >>>>>>>>> experiments and technologies, pp. 1-12, December 2012. >>>>>>>>> >>>>>>>>> Perhaps: >>>>>>>>> [OLIA] Khalili, R., Gast, N., Popovic, M., Upadhyay, U., and J. >>>>>>>>> Le Boudec, "MPTCP is not pareto-optimal: performance >>>>>>>>> issues and a possible solution", CoNEXT '12: Proceedings >>>>>>>>> of the 8th international conference on Emerging networking >>>>>>>>> experiments and technologies, pp. 1-12, December 2012, >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>> <https://dl.a/ >>>>>>> %2F&data=05%7C02%7CMarkus.Amend%40telekom.de%7C29d2ebc7c7a44 >>>>>>> 3e69f1008de3862d243%7Cbde4dffc4b604cf68b04a5eeb25f5c4f%7C0%7C >>>>>>> 0%7C639010194262220560%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU >>>>>>> 1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIs >>>>>>> IldUIjoyfQ%3D%3D%7C0%7C%7C%7C&sdata=%2FI6bf2kCKkwW9TX5vq5M >>>>>>> dgNmbBGXxCjL07gxgVmbcYo%3D&reserved=0 >>>>>>> >>>>>>>>> >>>>>>> cm.org%2Fdoi%2F10.1145%2F2413176.2413178&data=05%7C02%7CMark >>>>>>> >>>>>>>>> >>>>>>> us.Amend%40telekom.de%7C34f67a154541449bd12808de15e77765%7Cb >>>>>>> >>>>>>>>> >>>>>>> de4dffc4b604cf68b04a5eeb25f5c4f%7C0%7C0%7C638972281329054131 >>>>>>> >>>>>>>>> >>>>>>> %7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAu >>>>>>> >>>>>>>>> >>>>>>> MDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C0%7C >>>>>>> >>>>>>>>> >>>>>>> %7C%7C&sdata=jnz%2F%2BAJ2RX9k3mFK2m%2FJIEtxjD7Z%2FBGAilOqZQ2L >>>>>>> >>>>>>>>> Do0%3D&reserved=0>. >>>>>>>>> --> >>>>>>>>> >>>>>>>>> >>>>>>>>> 31) <!-- [rfced] Terminology >>>>>>>>> >>>>>>>>> a) Throughout the text, the following terminology appears to be used >>>>>>>>> inconsistently. Please review these occurrences and let us know >>>>>>>>> if/how they >>>>>>>>> may be made consistent. >>>>>>>>> >>>>>>>>> CLOSED state vs. CLOSE state vs. CLOSING state >>>>>>>>> >>>>>>>>> Client and Server vs. client and server (as well as 'the client and >>>>>>>>> the server') >>>>>>>>> >>>>>>>>> Congestion Control procedure vs. congestion control scheme >>>>>>>>> [Note: Should the case be made the same for these terms?] >>>>>>>>> >>>>>>>>> "Fast Close" vs. fast close >>>>>>>>> [Note: Should the first mention in quotes be "fast close" >>>>>>>>> for consistency?] >>>>>>>>> >>>>>>>>> Feature number 10 vs. feature number 10 >>>>>>>>> Length vs. length >>>>>>>>> handshake procedure/process vs. handshaking procedure/process >>>>>>>>> Key Type vs. Key types vs. key type >>>>>>>>> Multipath Capability vs. multipath capability >>>>>>>>> Multipath feature vs. multipath feature >>>>>>>>> Multipath option vs. multipath option vs. MP option >>>>>>>>> >>>>>>>>> Multipath Capable Feature vs. Multipath Capable feature vs. MP-Capable >>>>>>>>> feature >>>>>>>>> vs. MP_CAPABLE feature >>>>>>>>> >>>>>>>>> Nonce vs. nonce >>>>>>>>> Plain Text Key (Table 5) vs. Plain text key (Table 9) >>>>>>>>> Reset Code vs. reset code >>>>>>>>> Remove Address vs. Remove address (Tables 3 and 8) >>>>>>>>> >>>>>>>>> SHA256 vs. SHA-256 >>>>>>>>> [Note: "SHA256" is consistent in this document; however, "SHA-256" is >>>>>>>>> hyphenated >>>>>>>>> in the running text and some descriptions in RFC 6234; are any updates >>>>>>>>> needed >>>>>>>>> in this document for consistency with that RFC?] >>>>>>>>> >>>>>>>>> b) FYI: We updated the following terms to the form on the right for >>>>>>>>> consistency: >>>>>>>>> >>>>>>>>> address ID -> Address ID >>>>>>>>> age -> Age >>>>>>>>> Change request -> change request (per all other RFCs) >>>>>>>>> DCCP Connections -> DCCP connections >>>>>>>>> four-way -> 4-way >>>>>>>>> host A -> Host A >>>>>>>>> IP Address -> IP address >>>>>>>>> key data -> Key Data >>>>>>>>> maximum segment lifetime -> Maximum Segment Lifetime >>>>>>>>> multi-path -> multipath >>>>>>>>> UDP Encapsulation -> UDP encapsulation (per RFC 6773) >>>>>>>>> NAT Traversal -> NAT traversal (per RFC 6773) >>>>>>>>> --> >>>>>>>>> >>>>>>>>> >>>>>>>>> 32) <!-- [rfced] Abbreviations >>>>>>>>> >>>>>>>>> a) FYI - We have added expansions for the following abbreviations >>>>>>>>> per Section 3.6 of RFC 7322 ("RFC Style Guide"). Please review each >>>>>>>>> expansion in the document carefully to ensure correctness. >>>>>>>>> >>>>>>>>> command-line interface (CLI) >>>>>>>>> congestion window (CWND) >>>>>>>>> Path MTU (PMTU) >>>>>>>>> pebibytes (PiBs) >>>>>>>>> Stream Control Transmission Protocol (SCTP) >>>>>>>>> >>>>>>>>> b) We note the following variations. Do you prefer the expansion to >>>>>>>>> contain the hyphen or no hyphen? >>>>>>>>> >>>>>>>>> Multipath-DCCP (MP-DCCP) vs. Multipath DCCP (MP-DCCP) >>>>>>>>> >>>>>>>>> c) As recommended in the Web Portion of the Style Guide >>>>>>>>> <https://ww/ >>>>>>>>> w.rfc- >>>>>>>>> >>>>>>>>> >>>>>>> editor.org%2Fstyleguide%2Fpart2%2F%23exp_abbrev&data=05%7C02%7C >>>>>>> >>>>>>>>> >>>>>>> Markus.Amend%40telekom.de%7C34f67a154541449bd12808de15e77765 >>>>>>> >>>>>>>>> >>>>>>> %7Cbde4dffc4b604cf68b04a5eeb25f5c4f%7C0%7C0%7C63897228132906 >>>>>>> >>>>>>>>> >>>>>>> 3391%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiI >>>>>>> >>>>>>>>> >>>>>>> wLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C >>>>>>> >>>>>>>>> >>>>>>> 0%7C%7C%7C&sdata=Y7scNs57ywBcUOO8n2DrBGcRBsrbxzBB%2FLE7rytCaf >>>>>>> >>>>>>>>> g%3D&reserved=0>, once an >>>>>>>>> abbreviation is introduced, the abbreviated form should be used >>>>>>>>> thereafter. Please consider if you would like to apply this style for >>>>>>>>> the following terms (i.e., replace the expansion with the abbreviated >>>>>>>>> form on the right): >>>>>>>>> >>>>>>>>> Connection Identifier -> CI >>>>>>>>> Multipath DCCP -> MP-DCCP >>>>>>>>> --> >>>>>>>>> >>>>>>>>> >>>>>>>>> 33) <!-- [rfced] Please review the "Inclusive Language" portion of >>>>>>>>> the online >>>>>>>>> Style Guide >>>>>>>>> <https://ww/ >>>>>>>>> w.rfc- >>>>>>>>> >>>>>>>>> >>>>>>> editor.org%2Fstyleguide%2Fpart2%2F%23inclusive_language&data=05%7C0 >>>>>>> >>>>>>>>> >>>>>>> 2%7CMarkus.Amend%40telekom.de%7C34f67a154541449bd12808de15e7 >>>>>>> >>>>>>>>> >>>>>>> 7765%7Cbde4dffc4b604cf68b04a5eeb25f5c4f%7C0%7C0%7C6389722813 >>>>>>> >>>>>>>>> >>>>>>> 29074991%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIl >>>>>>> >>>>>>>>> >>>>>>> YiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D >>>>>>> >>>>>>>>> >>>>>>> %7C0%7C%7C%7C&sdata=cscnUyO2vk1DQmdMOFOZvhx6gMR15iP6f7eCu >>>>>>> >>>>>>>>> 8fO49s%3D&reserved=0> >>>>>>>>> and let us know if any changes are needed. Updates of this nature >>>>>>>>> typically >>>>>>>>> result in more precise language, which is helpful for readers. >>>>>>>>> >>>>>>>>> For example, please consider whether "traditionally" should be >>>>>>>>> updated for >>>>>>>>> clarity. >>>>>>>>> >>>>>>>>> While the NIST website >>>>>>>>> <https://we/ >>>>>>>>> >>>>>>>>> >>>>>>> b.archive.org%2Fweb%2F20250214092458%2Fhttps%3A%2F%2Fwww.nist. >>>>>>> >>>>>>>>> gov%2Fnist-research- >>>>>>>>> >>>>>>>>> >>>>>>> library%2F&data=05%7C02%7CMarkus.Amend%40telekom.de%7C34f67a15 >>>>>>> >>>>>>>>> >>>>>>> 4541449bd12808de15e77765%7Cbde4dffc4b604cf68b04a5eeb25f5c4f%7 >>>>>>> >>>>>>>>> >>>>>>> C0%7C0%7C638972281329084470%7CUnknown%7CTWFpbGZsb3d8eyJFb >>>>>>> >>>>>>>>> >>>>>>> XB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTW >>>>>>> >>>>>>>>> >>>>>>> FpbCIsIldUIjoyfQ%3D%3D%7C0%7C%7C%7C&sdata=Whs0cet5uLqvtnmFS4l >>>>>>> >>>>>>>>> p%2FW%2Fp4CsBSEp5pUeiuWlLw%2Fc%3D&reserved=0 >>>>>>>>> nist-technical-series-publications-author-instructions#table1> >>>>>>>>> indicates that this term is potentially biased, it is also ambiguous. >>>>>>>>> "Tradition" is a subjective term, as it is not the same for everyone. >>>>>>>>> --> >>>>>>>>> >>>>>>>>> >>>>>>>>> Thank you. >>>>>>>>> >>>>>>>>> Karen Moore and Alice Russo >>>>>>>>> RFC Production Center >>>>>>>>> >>>>>>>>> >>>>>>>>> On Oct 27, 2025, [email protected] wrote: >>>>>>>>> >>>>>>>>> *****IMPORTANT***** >>>>>>>>> >>>>>>>>> Updated 2025/10/27 >>>>>>>>> >>>>>>>>> RFC Author(s): >>>>>>>>> -------------- >>>>>>>>> >>>>>>>>> Instructions for Completing AUTH48 >>>>>>>>> >>>>>>>>> Your document has now entered AUTH48. Once it has been reviewed and >>>>>>>>> approved by you and all coauthors, it will be published as an RFC. >>>>>>>>> If an author is no longer available, there are several remedies >>>>>>>>> available as listed in the FAQ >>>>>>>>> (https://ww/ >>>>>>>>> w.rfc- >>>>>>>>> >>>>>>>>> >>>>>>> editor.org%2Ffaq%2F&data=05%7C02%7CMarkus.Amend%40telekom.de%7 >>>>>>> >>>>>>>>> >>>>>>> C34f67a154541449bd12808de15e77765%7Cbde4dffc4b604cf68b04a5eeb >>>>>>> >>>>>>>>> >>>>>>> 25f5c4f%7C0%7C0%7C638972281329094139%7CUnknown%7CTWFpbGZs >>>>>>> >>>>>>>>> >>>>>>> b3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIs >>>>>>> >>>>>>>>> >>>>>>> IkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C0%7C%7C%7C&sdata=yS8vk075Pr >>>>>>> >>>>>>>>> gUh6i28%2F97rsn52kWyLEgkpc7bmSwnGQg%3D&reserved=0). >>>>>>>>> >>>>>>>>> You and you coauthors are responsible for engaging other parties >>>>>>>>> (e.g., Contributors or Working Group) as necessary before providing >>>>>>>>> your approval. >>>>>>>>> >>>>>>>>> Planning your review >>>>>>>>> --------------------- >>>>>>>>> >>>>>>>>> Please review the following aspects of your document: >>>>>>>>> >>>>>>>>> * RFC Editor questions >>>>>>>>> >>>>>>>>> Please review and resolve any questions raised by the RFC Editor >>>>>>>>> that have been included in the XML file as comments marked as >>>>>>>>> follows: >>>>>>>>> >>>>>>>>> <!-- [rfced] ... --> >>>>>>>>> >>>>>>>>> These questions will also be sent in a subsequent email. >>>>>>>>> >>>>>>>>> * Changes submitted by coauthors >>>>>>>>> >>>>>>>>> Please ensure that you review any changes submitted by your >>>>>>>>> coauthors. We assume that if you do not speak up that you >>>>>>>>> agree to changes submitted by your coauthors. >>>>>>>>> >>>>>>>>> * Content >>>>>>>>> >>>>>>>>> Please review the full content of the document, as this cannot >>>>>>>>> change once the RFC is published. Please pay particular attention to: >>>>>>>>> - IANA considerations updates (if applicable) >>>>>>>>> - contact information >>>>>>>>> - references >>>>>>>>> >>>>>>>>> * Copyright notices and legends >>>>>>>>> >>>>>>>>> Please review the copyright notice and legends as defined in >>>>>>>>> RFC 5378 and the Trust Legal Provisions >>>>>>>>> (TLP - >>>>>>>>> https://trust/ >>>>>>>>> ee.ietf.org%2Flicense- >>>>>>>>> >>>>>>>>> >>>>>>> info&data=05%7C02%7CMarkus.Amend%40telekom.de%7C34f67a1545414 >>>>>>> >>>>>>>>> >>>>>>> 49bd12808de15e77765%7Cbde4dffc4b604cf68b04a5eeb25f5c4f%7C0%7C >>>>>>> >>>>>>>>> >>>>>>> 0%7C638972281329103134%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU >>>>>>> >>>>>>>>> >>>>>>> 1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIs >>>>>>> >>>>>>>>> >>>>>>> IldUIjoyfQ%3D%3D%7C0%7C%7C%7C&sdata=jYmJhjGvE8Q%2FUmf0QreVat >>>>>>> >>>>>>>>> WqNeogHyoEw0VsXjW%2BPqk%3D&reserved=0). >>>>>>>>> >>>>>>>>> * Semantic markup >>>>>>>>> >>>>>>>>> Please review the markup in the XML file to ensure that elements of >>>>>>>>> content are correctly tagged. For example, ensure that <sourcecode> >>>>>>>>> and <artwork> are set correctly. See details at >>>>>>>>> >>>>>>>>> <https://aut/ >>>>>>>>> hors.ietf.org%2Frfcxml- >>>>>>>>> >>>>>>>>> >>>>>>> vocabulary&data=05%7C02%7CMarkus.Amend%40telekom.de%7C34f67a1 >>>>>>> >>>>>>>>> >>>>>>> 54541449bd12808de15e77765%7Cbde4dffc4b604cf68b04a5eeb25f5c4f% >>>>>>> >>>>>>>>> >>>>>>> 7C0%7C0%7C638972281329112128%7CUnknown%7CTWFpbGZsb3d8eyJF >>>>>>> >>>>>>>>> >>>>>>> bXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiT >>>>>>> >>>>>>>>> >>>>>>> WFpbCIsIldUIjoyfQ%3D%3D%7C0%7C%7C%7C&sdata=1W8OEzSMEo49hde >>>>>>> >>>>>>>>> FNk8b0%2FLzcKo%2F7%2Fy%2Bbp%2FYyyJPU5Q%3D&reserved=0>. >>>>>>>>> >>>>>>>>> * Formatted output >>>>>>>>> >>>>>>>>> Please review the PDF, HTML, and TXT files to ensure that the >>>>>>>>> formatted output, as generated from the markup in the XML file, is >>>>>>>>> reasonable. Please note that the TXT will have formatting >>>>>>>>> limitations compared to the PDF and HTML. >>>>>>>>> >>>>>>>>> >>>>>>>>> Submitting changes >>>>>>>>> ------------------ >>>>>>>>> >>>>>>>>> To submit changes, please reply to this email using 'REPLY ALL' as all >>>>>>>>> the parties CCed on this message need to see your changes. The parties >>>>>>>>> include: >>>>>>>>> >>>>>>>>> * your coauthors >>>>>>>>> >>>>>>>>> * [email protected] (the RPC team) >>>>>>>>> >>>>>>>>> * other document participants, depending on the stream (e.g., >>>>>>>>> IETF Stream participants are your working group chairs, the >>>>>>>>> responsible ADs, and the document shepherd). >>>>>>>>> >>>>>>>>> * [email protected], which is a new archival mailing list >>>>>>>>> to preserve AUTH48 conversations; it is not an active discussion >>>>>>>>> list: >>>>>>>>> >>>>>>>>> * More info: >>>>>>>>> >>>>>>>>> https://maila/ >>>>>>>>> rchive.ietf.org%2Farch%2Fmsg%2Fietf-announce%2Fyb6lpIGh- >>>>>>>>> >>>>>>>>> >>>>>>> 4Q9l2USxIAe6P8O4Zc&data=05%7C02%7CMarkus.Amend%40telekom.de% >>>>>>> >>>>>>>>> >>>>>>> 7C34f67a154541449bd12808de15e77765%7Cbde4dffc4b604cf68b04a5ee >>>>>>> >>>>>>>>> >>>>>>> b25f5c4f%7C0%7C0%7C638972281329121524%7CUnknown%7CTWFpbGZ >>>>>>> >>>>>>>>> >>>>>>> sb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiI >>>>>>> >>>>>>>>> >>>>>>> sIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C0%7C%7C%7C&sdata=WinHATdEh >>>>>>> >>>>>>>>> dQovFkGOUC8P749REPaoYR1%2FkQHv%2B7abtk%3D&reserved=0 >>>>>>>>> >>>>>>>>> * The archive itself: >>>>>>>>> >>>>>>>>> https://maila/ >>>>>>>>> >>>>>>>>> >>>>>>> rchive.ietf.org%2Farch%2Fbrowse%2Fauth48archive%2F&data=05%7C02%7 >>>>>>> >>>>>>>>> >>>>>>> CMarkus.Amend%40telekom.de%7C34f67a154541449bd12808de15e7776 >>>>>>> >>>>>>>>> >>>>>>> 5%7Cbde4dffc4b604cf68b04a5eeb25f5c4f%7C0%7C0%7C6389722813291 >>>>>>> >>>>>>>>> >>>>>>> 33709%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOi >>>>>>> >>>>>>>>> >>>>>>> IwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7 >>>>>>> >>>>>>>>> >>>>>>> C0%7C%7C%7C&sdata=Zh619HF0OTx8rFWoJ%2BCRBOI4H1gzLNwpjPC4Rrv >>>>>>> >>>>>>>>> RWms%3D&reserved=0 >>>>>>>>> >>>>>>>>> * Note: If only absolutely necessary, you may temporarily opt out >>>>>>>>> of the archiving of messages (e.g., to discuss a sensitive matter). >>>>>>>>> If needed, please add a note at the top of the message that you >>>>>>>>> have dropped the address. When the discussion is concluded, >>>>>>>>> [email protected] will be re-added to the CC list and >>>>>>>>> its addition will be noted at the top of the message. >>>>>>>>> >>>>>>>>> You may submit your changes in one of two ways: >>>>>>>>> >>>>>>>>> An update to the provided XML file >>>>>>>>> - OR - >>>>>>>>> An explicit list of changes in this format >>>>>>>>> >>>>>>>>> Section # (or indicate Global) >>>>>>>>> >>>>>>>>> OLD: >>>>>>>>> old text >>>>>>>>> >>>>>>>>> NEW: >>>>>>>>> new text >>>>>>>>> >>>>>>>>> You do not need to reply with both an updated XML file and an explicit >>>>>>>>> list of changes, as either form is sufficient. >>>>>>>>> >>>>>>>>> We will ask a stream manager to review and approve any changes that >>>>>>>>> >>>>>>> seem >>>>>>> >>>>>>>>> beyond editorial in nature, e.g., addition of new text, deletion of >>>>>>>>> text, >>>>>>>>> and technical changes. Information about stream managers can be found >>>>>>>>> >>>>>>> in >>>>>>> >>>>>>>>> the FAQ. Editorial changes do not require approval from a stream >>>>>>>>> manager. >>>>>>>>> >>>>>>>>> >>>>>>>>> Approving for publication >>>>>>>>> -------------------------- >>>>>>>>> >>>>>>>>> To approve your RFC for publication, please reply to this email >>>>>>>>> stating >>>>>>>>> that you approve this RFC for publication. Please use 'REPLY ALL', >>>>>>>>> as all the parties CCed on this message need to see your approval. >>>>>>>>> >>>>>>>>> >>>>>>>>> Files >>>>>>>>> ----- >>>>>>>>> >>>>>>>>> The files are available here: >>>>>>>>> >>>>>>>>> https://www/ >>>>>>>>> .rfc- >>>>>>>>> >>>>>>>>> >>>>>>> editor.org%2Fauthors%2Frfc9897.xml&data=05%7C02%7CMarkus.Amend% >>>>>>> >>>>>>>>> >>>>>>> 40telekom.de%7C34f67a154541449bd12808de15e77765%7Cbde4dffc4b6 >>>>>>> >>>>>>>>> >>>>>>> 04cf68b04a5eeb25f5c4f%7C0%7C0%7C638972281329146321%7CUnkno >>>>>>> >>>>>>>>> >>>>>>> wn%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCI >>>>>>> >>>>>>>>> >>>>>>> sIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C0%7C%7C%7C&s >>>>>>> >>>>>>>>> >>>>>>> data=IHIoddWaDVRaiInViKyo1MT3W76iELytFnS5TlOHVCg%3D&reserved=0 >>>>>>> >>>>>>>>> https://www/ >>>>>>>>> .rfc- >>>>>>>>> >>>>>>>>> >>>>>>> editor.org%2Fauthors%2Frfc9897.html&data=05%7C02%7CMarkus.Amend >>>>>>> >>>>>>>>> >>>>>>> %40telekom.de%7C34f67a154541449bd12808de15e77765%7Cbde4dffc4b >>>>>>> >>>>>>>>> >>>>>>> 604cf68b04a5eeb25f5c4f%7C0%7C0%7C638972281329157363%7CUnkno >>>>>>> >>>>>>>>> >>>>>>> wn%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCI >>>>>>> >>>>>>>>> >>>>>>> sIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C0%7C%7C%7C&s >>>>>>> >>>>>>>>> >>>>>>> data=gZTIy7dNXKu9gDgDdxx4GPxvnFc73FnosHh56emr71A%3D&reserved=0 >>>>>>> >>>>>>>>> https://www/ >>>>>>>>> .rfc- >>>>>>>>> >>>>>>>>> >>>>>>> editor.org%2Fauthors%2Frfc9897.pdf&data=05%7C02%7CMarkus.Amend% >>>>>>> >>>>>>>>> >>>>>>> 40telekom.de%7C34f67a154541449bd12808de15e77765%7Cbde4dffc4b6 >>>>>>> >>>>>>>>> >>>>>>> 04cf68b04a5eeb25f5c4f%7C0%7C0%7C638972281329167327%7CUnkno >>>>>>> >>>>>>>>> >>>>>>> wn%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCI >>>>>>> >>>>>>>>> >>>>>>> sIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C0%7C%7C%7C&s >>>>>>> >>>>>>>>> >>>>>>> data=Vn3pwzsdz%2FI0kwNbRcrIfjC0O3eQ8lRz8Dyojyobs7c%3D&reserved=0 >>>>>>> >>>>>>>>> https://www/ >>>>>>>>> .rfc- >>>>>>>>> >>>>>>>>> >>>>>>> editor.org%2Fauthors%2Frfc9897.txt&data=05%7C02%7CMarkus.Amend%4 >>>>>>> >>>>>>>>> >>>>>>> 0telekom.de%7C34f67a154541449bd12808de15e77765%7Cbde4dffc4b60 >>>>>>> >>>>>>>>> >>>>>>> 4cf68b04a5eeb25f5c4f%7C0%7C0%7C638972281329177120%7CUnknow >>>>>>> >>>>>>>>> >>>>>>> n%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIl >>>>>>> >>>>>>>>> >>>>>>> AiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C0%7C%7C%7C&sd >>>>>>> >>>>>>>>> >>>>>>> ata=6lBOuHpymJ%2F3Y0DlYS6b0GPs2pFsF%2BOobJSSSPj0MmI%3D&reserv >>>>>>> >>>>>>>>> ed=0 >>>>>>>>> >>>>>>>>> Diff file of the text: >>>>>>>>> >>>>>>>>> https://www/ >>>>>>>>> .rfc-editor.org%2Fauthors%2Frfc9897- >>>>>>>>> >>>>>>>>> >>>>>>> diff.html&data=05%7C02%7CMarkus.Amend%40telekom.de%7C34f67a154 >>>>>>> >>>>>>>>> >>>>>>> 541449bd12808de15e77765%7Cbde4dffc4b604cf68b04a5eeb25f5c4f%7C >>>>>>> >>>>>>>>> >>>>>>> 0%7C0%7C638972281329186742%7CUnknown%7CTWFpbGZsb3d8eyJFbX >>>>>>> >>>>>>>>> >>>>>>> B0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWF >>>>>>> >>>>>>>>> >>>>>>> pbCIsIldUIjoyfQ%3D%3D%7C0%7C%7C%7C&sdata=EjJGCV0QREiYbaySpisjRg >>>>>>> >>>>>>>>> gbGSE13QrF8LLU2AL3Kv0%3D&reserved=0 >>>>>>>>> >>>>>>>>> https://www/ >>>>>>>>> .rfc-editor.org%2Fauthors%2Frfc9897- >>>>>>>>> >>>>>>>>> >>>>>>> rfcdiff.html&data=05%7C02%7CMarkus.Amend%40telekom.de%7C34f67a1 >>>>>>> >>>>>>>>> >>>>>>> 54541449bd12808de15e77765%7Cbde4dffc4b604cf68b04a5eeb25f5c4f% >>>>>>> >>>>>>>>> >>>>>>> 7C0%7C0%7C638972281329195621%7CUnknown%7CTWFpbGZsb3d8eyJF >>>>>>> >>>>>>>>> >>>>>>> bXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiT >>>>>>> >>>>>>>>> >>>>>>> WFpbCIsIldUIjoyfQ%3D%3D%7C0%7C%7C%7C&sdata=etFLnas9CNj0YyhXJH >>>>>>> >>>>>>>>> PPVciMeRuECj7Ue0XYsJzWx8c%3D&reserved=0 (side by side) >>>>>>>>> >>>>>>>>> Diff of the XML: >>>>>>>>> >>>>>>>>> https://www/ >>>>>>>>> .rfc-editor.org%2Fauthors%2Frfc9897- >>>>>>>>> >>>>>>>>> >>>>>>> xmldiff1.html&data=05%7C02%7CMarkus.Amend%40telekom.de%7C34f67a >>>>>>> >>>>>>>>> >>>>>>> 154541449bd12808de15e77765%7Cbde4dffc4b604cf68b04a5eeb25f5c4f >>>>>>> >>>>>>>>> >>>>>>> %7C0%7C0%7C638972281329204385%7CUnknown%7CTWFpbGZsb3d8ey >>>>>>> >>>>>>>>> >>>>>>> JFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoi >>>>>>> >>>>>>>>> >>>>>>> TWFpbCIsIldUIjoyfQ%3D%3D%7C0%7C%7C%7C&sdata=wYgbW6gNLaBNU% >>>>>>> >>>>>>>>> 2FWtDFve4vQyKNUHs5xPAf5UWT4BHug%3D&reserved=0 >>>>>>>>> >>>>>>>>> >>>>>>>>> Tracking progress >>>>>>>>> ----------------- >>>>>>>>> >>>>>>>>> The details of the AUTH48 status of your document are here: >>>>>>>>> >>>>>>>>> https://www/ >>>>>>>>> .rfc- >>>>>>>>> >>>>>>>>> >>>>>>> editor.org%2Fauth48%2Frfc9897&data=05%7C02%7CMarkus.Amend%40tel >>>>>>> >>>>>>>>> >>>>>>> ekom.de%7C34f67a154541449bd12808de15e77765%7Cbde4dffc4b604cf6 >>>>>>> >>>>>>>>> >>>>>>> 8b04a5eeb25f5c4f%7C0%7C0%7C638972281329213194%7CUnknown%7 >>>>>>> >>>>>>>>> >>>>>>> CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOi >>>>>>> >>>>>>>>> >>>>>>> JXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C0%7C%7C%7C&sdata= >>>>>>> >>>>>>>>> >>>>>>> 9RTrRiS8FahV7sm9w%2F329KQ18pDus7Sr%2F08qouliRas%3D&reserved=0 >>>>>>> >>>>>>>>> Please let us know if you have any questions. >>>>>>>>> >>>>>>>>> Thank you for your cooperation, >>>>>>>>> >>>>>>>>> RFC Editor >>>>>>>>> >>>>>>>>> -------------------------------------- >>>>>>>>> RFC9897 (draft-ietf-tsvwg-multipath-dccp-24) >>>>>>>>> >>>>>>>>> Title : DCCP Extensions for Multipath Operation with Multiple >>>>>>>>> >>>>>>> Addresses >>>>>>> >>>>>>>>> Author(s) : M. Amend, Ed., A. Brunstrom, A. Kassler, V. Rakocevic, S. >>>>>>>>> Johnson >>>>>>>>> WG Chair(s) : Martin Duke, Zaheduzzaman Sarker >>>>>>>>> Area Director(s) : Gorry Fairhurst, Mike Bishop >>>>>>>>> >>>>>>>> >>>>>> >>>>> >>> >> > > 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]
