Return-Path: X-Original-To: auth48archive@mail2.ietf.org Delivered-To: auth48archive@mail2.ietf.org Received: from localhost (localhost [127.0.0.1]) by mail2.ietf.org (Postfix) with ESMTP id 38EBBA07C41B for ; Mon, 29 Dec 2025 13:20:23 -0800 (PST) X-Virus-Scanned: amavisd-new at ietf.org X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: mail2.ietf.org (amavisd-new); dkim=pass (2048-bit key) header.d=staff-rfc-editor-org.20230601.gappssmtp.com Received: from mail2.ietf.org ([166.84.6.31]) by localhost (mail2.ietf.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qRqUTuHvT-vn for ; Mon, 29 Dec 2025 13:20:21 -0800 (PST) Received: from mail-yx1-xb134.google.com (mail-yx1-xb134.google.com [IPv6:2607:f8b0:4864:20::b134]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature ECDSA (P-256) server-digest SHA256) (No client certificate requested) by mail2.ietf.org (Postfix) with ESMTPS id 01222A07C3B7 for ; Mon, 29 Dec 2025 13:20:16 -0800 (PST) Received: by mail-yx1-xb134.google.com with SMTP id 956f58d0204a3-6420c08f886so11517853d50.3 for ; Mon, 29 Dec 2025 13:20:16 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=staff-rfc-editor-org.20230601.gappssmtp.com; s=20230601; t=1767043216; x=1767648016; darn=rfc-editor.org; h=to:references:message-id:content-transfer-encoding:cc:date :in-reply-to:from:subject:mime-version:from:to:cc:subject:date :message-id:reply-to; bh=tkLZFwPtK5m3XV7S4AE6iW0zKDofhOxVyKg2+0N80QE=; b=v7i5zh782BFLW7fBvp89OzUnOgvziBu8E6eE6ZfzuTvceeNaIk7GbE4+m9Z35uTC/V PyaRCAa3J+YMzMAyA1ld+VtAyaiweqcwPytu4RnolfiJfzFW953wOACJ3s/gHfCDRMaQ FkIwfY2vFrrwFXHeiCyjKdnvamRowKhVyEBiOekgyA6WTM5eTWfWb9784cZmB36sLK2Q lXgDUdH2FDBn/xs1sGqv2q+WLRWXMvjnb8GO4V2+2vlJrCdjKFHAlesWWsscWPx+0slf WANQMB2pGiqatB806yxiscdikM3rHFdv0XrWPFTOzUMLtOMlYV84vWei47J8HK4+qrbZ pGAQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1767043216; x=1767648016; h=to:references:message-id:content-transfer-encoding:cc:date :in-reply-to:from:subject:mime-version:x-gm-gg:x-gm-message-state :from:to:cc:subject:date:message-id:reply-to; bh=tkLZFwPtK5m3XV7S4AE6iW0zKDofhOxVyKg2+0N80QE=; b=Xo3FpdVEXxxCsCpMBbGY+upWue/Ip5+X+azbDncW3S66nBxCutTcGimQHczBQ4wV7n BezyhyLdJQlyd6yrNWsKeqSOmVdDhcoJD9r7mXzN3X7RLdx3fBVyWEzKLCG6tJxFBNgR Y+kK7vT1MPRnwVQvKrNLvcLfPp5ExGv7kSJ0uy461RQTvB9iDbvDrrJOyC/CMb8Spv2T mALaIOTCuSsTtJ3XbgV0h4Ig1Jw1ifqFrg/5XYRe6EJZK525CMyo2Z/TsuGedW1Kk0lz 9rhLiuUtbhqDs7gotbgZUsWQmiMbfVRmf79rC1nldXupZwNpZ515kpoy4dGMNMWW8CDg dN1Q== X-Forwarded-Encrypted: i=1; AJvYcCWkVlrHOeUjV1+a+rPoY6IJNyYmKBpNSFddsWsWGVFZtAuG8vWIg+3xjz7R0ZwnobFkdbZu12lu0AEc5iF0@rfc-editor.org X-Gm-Message-State: AOJu0YxvifI3EOYnd5F/DTtQSrupGxn4fjXooc8VcIxUKEQzf9Tqm93E omlMpYKfc4xJnsiuEvjcqg3Mh7VuMyVburZKEOktmBbCB6ubV1KJLNioKAdK84bRo2DvjA== X-Gm-Gg: AY/fxX6Rg+aIk//WM3dpQK3BKjjvraY8p3QNskjFixWpnTwPKdLIm1ByCAuMNPyBNS0 B0AVSiPweOA/YnLNApxLL6uzCy5/2j0m05ktMkita6L9Q1vyJ6BmtJtpsVf4Z3DQYf5oF5TYwrR avCo/eITQQXdqvUuy81sA4/pnd/aMOgU8oZkC2OwL3dZa3M1Xg1NdbxlWD4sLTjEULPeJ9rxuEG 3H8qgKtWOkr1MZ3Zi2uzhz4YmlU5NkNVLBiRZusBkeulVKMIFodOl7DWTHHdqjj8dn/kTz4mle+ q2FiNBxgUJ+KHz2YLNWsSslGqbYTLiK2WWNy9Laj9NaLOSIeZHN/KMOFlIE6Ix7MCUNqOLQlVe1 Q/ihVZoCeddj2Y5UtQcZ7WYgMwkyqgRjon7r2kxn/Weu/mymY4CBAQOGaXAAwldAPh4sm4fE29V 8Mgeuj/YYISwz4FoeOzf5pTR1377ksnfofsXndQz6Q1hWvjsc8 X-Google-Smtp-Source: AGHT+IHrNf6g6/tbS3IRo9bOUTXPfb0f7t1t8kzwH9Vo61GbC+Qrhmy3rNpam26wWc3vSc5nVsV0sw== X-Received: by 2002:a05:690e:1486:b0:63f:ba88:e8ee with SMTP id 956f58d0204a3-6466a85a863mr25806846d50.21.1767043215996; Mon, 29 Dec 2025 13:20:15 -0800 (PST) Received: from smtpclient.apple ([2600:1700:3681:d010:91a8:e754:ac6b:90d2]) by smtp.gmail.com with ESMTPSA id 956f58d0204a3-6466a81d4e4sm15271380d50.0.2025.12.29.13.20.14 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Mon, 29 Dec 2025 13:20:15 -0800 (PST) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 16.0 \(3826.700.81\)) From: Karen Moore In-Reply-To: Date: Mon, 29 Dec 2025 13:20:03 -0800 Content-Transfer-Encoding: quoted-printable Message-Id: <220A494C-A996-4899-AAD0-1D685BE709A2@staff.rfc-editor.org> References: <20251028060126.43615C000BCA@rfcpa.rfc-editor.org> <3E95FCC3-21F5-48F1-A434-D41589B2F2E3@staff.rfc-editor.org> <10124948-3693-4DE1-BA29-BF1123AFE1D8@staff.rfc-editor.org> <606b3ae1-2c64-4400-b650-cc389bb3d75e@erg.abdn.ac.uk> <679EBCC2-300E-4A48-960E-5AF5812B6887@staff.rfc-editor.org> <498B1F43-1883-4306-A20A-A78BC40EDF82@staff.rfc-editor.org> To: =?utf-8?Q?Anna_Brunstr=C3=B6m?= , Andreas Kassler , "Markus.Amend@telekom.de" , "veselin.rakocevic.1@city.ac.uk" , "stephen.h.johnson@bt.com" X-Mailer: Apple Mail (2.3826.700.81) Message-ID-Hash: IBFHJY5QNZ4GPPYVMEDTC52BP6URVU3P X-Message-ID-Hash: IBFHJY5QNZ4GPPYVMEDTC52BP6URVU3P X-MailFrom: kmoore@staff.rfc-editor.org X-Mailman-Rule-Misses: dmarc-mitigation; no-senders; approved; emergency; loop; banned-address; member-moderation; nonmember-moderation; administrivia; implicit-dest; max-recipients; max-size; news-moderation; no-subject; digests; suspicious-header CC: "rfc-editor@rfc-editor.org" , "tsvwg-ads@ietf.org" , "tsvwg-chairs@ietf.org" , "auth48archive@rfc-editor.org" , Gorry Fairhurst X-Mailman-Version: 3.3.9rc6 Precedence: list Subject: =?utf-8?q?=5Bauth48=5D_Re=3A_AUTH48=3A_RFC-to-be_9897_=3Cdraft-ietf-tsvwg-mu?= =?utf-8?q?ltipath-dccp-24=3E_for_your_review?= List-Id: "Archiving AUTH48 exchanges between the RFC Production Center, the authors, and other related parties" Archived-At: List-Archive: List-Help: List-Owner: List-Post: List-Subscribe: List-Unsubscribe: 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=E2=80=AFAM, Anna Brunstr=C3=B6m = wrote: >=20 > Dear Karen, >=20 > Thanks for the, as always, great editing work. I have no further = updates and approve the document. >=20 > I hope you are all having a nice holiday season and best wishes for a = happy 2026! >=20 > Anna >=20 > -----Original Message----- > From: Karen Moore > Sent: den 24 december 2025 19:16 > To: Anna Brunstr=C3=B6m ; = stephen.h.johnson@bt.com; Markus.Amend@telekom.de; Andreas Kassler = ; veselin.rakocevic.1@city.ac.uk > Cc: rfc-editor@rfc-editor.org; tsvwg-ads@ietf.org; = tsvwg-chairs@ietf.org; auth48archive@rfc-editor.org; Gorry Fairhurst = > Subject: Re: AUTH48: RFC-to-be 9897 = for your review >=20 > Dear Anna and Andreas, >=20 > 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. >=20 > Once both approvals are received, we will ask IANA to update their = registries accordingly before moving forward with the publication = process. >=20 > 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 >=20 > 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) >=20 > Thank you, > Karen Moore > RFC Production Center >=20 >=20 >> On Dec 17, 2025, at 11:55=E2=80=AFAM, Karen Moore = wrote: >>=20 >> Dear Gorry, Markus, Stephen, and Veselin, >>=20 >> Thank you for your replies. We have updated our files with Gorry=E2=80= =99s suggestions and marked his approval. Note that we made = =E2=80=9Ccongestion control algorithm=E2=80=9D lowercase for consistency = and to match use in RFC 6356. >>=20 >> 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. >>=20 >> --FILES (please refresh)-- >>=20 >> Updated XML file: >> https://www.rfc-editor.org/authors/rfc9897.xml >>=20 >> 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 >>=20 >> 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) >>=20 >> 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) >>=20 >> For the AUTH48 status of this document, please see: >> https://www.rfc-editor.org/auth48/rfc9897 >>=20 >> Best regards, >> Karen Moore >> RFC Production Center >>=20 >>=20 >>> On Dec 17, 2025, at 1:31=E2=80=AFAM, Gorry Fairhurst = wrote: >>>=20 >>> I ahve read the latest revision, and have reviewed the changes noted = below. >>>=20 >>> I would like two to see two changes to the final text: >>>=20 >>> 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 >>>=20 >>> - reason: there were rather to many uses of "order". >>>=20 >>> 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. >>>=20 >>> With these two requested changes, I approve the document. Many = thanks for completing this substatial piece of specification, >>>=20 >>> Gorry >>> (WIT AD >>>=20 >>> On 16/12/2025 22:04, Karen Moore wrote: >>>> --Resending with =E2=80=9CAD=E2=80=9D in the Subject line -- >>>>=20 >>>>=20 >>>> On Dec 16, 2025, at 1:59=E2=80=AFPM, Karen Moore = wrote: >>>>=20 >>>> Dear Markus and *Gorry (AD), >>>>=20 >>>> 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. >>>>=20 >>>> * Gorry, please review the changes within the following sections = and let us know if you approve: >>>>=20 >>>> - Section 1 (3rd paragraph) >>>> - New text added: Sections 3.2.1, 3.2.4, 3.2.5, 3.2.6, and 3.2.11 >>>>=20 >>>> =E2=80=94FILES (please refresh)-- >>>>=20 >>>> Updated XML file: >>>> https://www.rfc-editor.org/authors/rfc9897.xml >>>>=20 >>>> 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 >>>>=20 >>>> 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) >>>>=20 >>>> 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) >>>>=20 >>>> For the AUTH48 status of this document, please see: >>>> https://www.rfc-editor.org/auth48/rfc9897 >>>>=20 >>>> Best regards, >>>> Karen Moore >>>> RFC Production Center >>>>=20 >>>>=20 >>>>=20 >>>>>> On Dec 16, 2025, at 2:10=E2=80=AFAM, = wrote: >>>>>>=20 >>>>>> Dear Karen, dear RFC editor team, >>>>>>=20 >>>>>> With regard to 1) , I ask you to replace the occurrence of = "man-in-the-middle" with "on-path attacker" >>>>>>=20 >>>>>> With regard to 2), I ask you to remove RFC5280 from the list of = Informative References >>>>>>=20 >>>>>> 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. >>>>>>=20 >>>>>> With regard to 4), I say thank you. >>>>>>=20 >>>>>>=20 >>>>>> 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. >>>>>>=20 >>>>>>=20 >>>>>> Br >>>>>>=20 >>>>>> Markus >>>>>>=20 >>>>>>=20 >>>>>>=20 >>>>>>> -----Urspr=C3=BCngliche Nachricht----- >>>>>>> Von: Karen Moore >>>>>>> Gesendet: Donnerstag, 11. Dezember 2025 04:10 >>>>>>> An: Amend, Markus ; = andreas.kassler@kau.se; >>>>>>> veselin.rakocevic.1@city.ac.uk; anna.brunstrom@kau.se; >>>>>>> stephen.h.johnson@bt.com >>>>>>> Cc: rfc-editor@rfc-editor.org; tsvwg-ads@ietf.org; = tsvwg-chairs@ietf.org; >>>>>>> gorry@erg.abdn.ac.uk; auth48archive@rfc-editor.org >>>>>>> Betreff: Re: AUTH48: RFC-to-be 9897 = >>>>>>> for your review >>>>>>>=20 >>>>>>> Dear Markus, >>>>>>>=20 >>>>>>> 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. >>>>>>>=20 >>>>>>> 1) With the addition of new text, there are two occurences of = =E2=80=9Cman-in-the- >>>>>>> middle=E2=80=9D. Per the "Inclusive Language" portion of the = online Style Guide >>>>>>> >>>>>> w.rfc- >>>>>>> = editor.org%2Fstyleguide%2Fpart2%2F%23inclusive_language&data=3D05%7C0 >>>>>>> 2%7CMarkus.Amend%40telekom.de%7C29d2ebc7c7a443e69f1008de3862 >>>>>>> d243%7Cbde4dffc4b604cf68b04a5eeb25f5c4f%7C0%7C0%7C6390101942 >>>>>>> 62023565%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIl >>>>>>> = YiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D >>>>>>> %7C0%7C%7C%7C&sdata=3DsC7IR05r%2B8QWtd5QqPmv4tmnWAWe%2BcO0 >>>>>>> ipF9s1mIOHY%3D&reserved=3D0>, 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. >>>>>>>=20 >>>>>>> Section 3.2.4: >>>>>>> MP-DCCP protects against some man-in-the-middle attacks as = further >>>>>>> outlined in Section 4. >>>>>>>=20 >>>>>>> Section 3.2.6: >>>>>>> MP-DCCP protects against some man-in-the-middle attacks as = further >>>>>>> outlined in Section 4. >>>>>>>=20 >>>>>>> 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? >>>>>>>=20 >>>>>>> 3) We made the following instances of =E2=80=9Clength=E2=80=9D = uppercase. Please review and >>>>>>> let us know if this is correct or if any further updates are = needed in the running >>>>>>> text.. >>>>>>>=20 >>>>>>>=20 >>>>>>>> If the term length refers to the Length data field of a header = option, we >>>>>>>>=20 >>>>>>> prefer the capitalisation of Length instead of length and ask = you to adopt this >>>>>>>=20 >>>>>>> length of one byte --> Legth of one byte >>>>>>> a maximum length of 252 bytes --> a maximum Length of 252 bytes >>>>>>>=20 >>>>>>> 4) FYI: We made the requested changes below as well as the = IANA-related >>>>>>> updates to Tables 3, 5, 8, and 9. >>>>>>>=20 >>>>>>>=20 >>>>>>>> - The text "However the definition of a path management method, = in which >>>>>>>>=20 >>>>>>> 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. >>>>>>>=20 >>>>>>>> - The sentence "DCCP defines that if the checksum fails, the = receiving >>>>>>>>=20 >>>>>>> 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: >>>>>>>=20 >>>>>>>> New: "As defined by DCCP, if the checksum fails, the receiving = endpoint..." >>>>>>>>=20 >>>>>>>> - The affiliation of an author has changed because the = university has been >>>>>>>>=20 >>>>>>> renamed. We ask you to replace for the author Veselin Rakocevic = the affiliation >>>>>>> from >>>>>>>=20 >>>>>>>> OLD: City, University of London >>>>>>>> to >>>>>>>> NEW: City St George's, University of London >>>>>>>>=20 >>>>>>>=20 >>>>>>> --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. >>>>>>>=20 >>>>>>> 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. >>>>>>>=20 >>>>>>> Updated XML file: >>>>>>>=20 >>>>>>> https://www/ >>>>>>> .rfc- >>>>>>> editor.org%2Fauthors%2Frfc9897.xml&data=3D05%7C02%7CMarkus.Amend% >>>>>>> 40telekom.de%7C29d2ebc7c7a443e69f1008de3862d243%7Cbde4dffc4b60 >>>>>>> 4cf68b04a5eeb25f5c4f%7C0%7C0%7C639010194262050621%7CUnknow >>>>>>> n%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIl >>>>>>> AiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C0%7C%7C%7C&sd >>>>>>> ata=3D4HPdmcXXqy1VddLBzn10bOVe7ze2oAdq9ahIXEhFd4w%3D&reserved=3D0 >>>>>>>=20 >>>>>>> Updated output files: >>>>>>>=20 >>>>>>> https://www/ >>>>>>> .rfc- >>>>>>> editor.org%2Fauthors%2Frfc9897.txt&data=3D05%7C02%7CMarkus.Amend%4= >>>>>>> 0telekom.de%7C29d2ebc7c7a443e69f1008de3862d243%7Cbde4dffc4b604 >>>>>>> cf68b04a5eeb25f5c4f%7C0%7C0%7C639010194262062468%7CUnknown >>>>>>> %7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIl >>>>>>> AiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C0%7C%7C%7C&sd >>>>>>> ata=3D1OyWO%2FOk3ESi8fXOZyd11M%2FW4DY7B6bbjRLwzkXSJVw%3D&res >>>>>>> erved=3D0 >>>>>>>=20 >>>>>>> https://www/ >>>>>>> .rfc- >>>>>>> editor.org%2Fauthors%2Frfc9897.pdf&data=3D05%7C02%7CMarkus.Amend% >>>>>>> 40telekom.de%7C29d2ebc7c7a443e69f1008de3862d243%7Cbde4dffc4b60 >>>>>>> 4cf68b04a5eeb25f5c4f%7C0%7C0%7C639010194262074159%7CUnknow >>>>>>> n%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIl >>>>>>> AiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C0%7C%7C%7C&sd >>>>>>> ata=3D6pJFnfGkJ1PhGeSNEAl6uOOZ09BB8vpfJQpIYu1Hhus%3D&reserved=3D0 >>>>>>>=20 >>>>>>> https://www/ >>>>>>> .rfc- >>>>>>> editor.org%2Fauthors%2Frfc9897.html&data=3D05%7C02%7CMarkus.Amend >>>>>>> %40telekom.de%7C29d2ebc7c7a443e69f1008de3862d243%7Cbde4dffc4b6 >>>>>>> 04cf68b04a5eeb25f5c4f%7C0%7C0%7C639010194262085170%7CUnkno >>>>>>> wn%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCI >>>>>>> sIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C0%7C%7C%7C&s >>>>>>> data=3DI%2BvyQCqOl4PCWo6oTPexXGh2oVsxdHSiLHyv8VgztU8%3D&reserved >>>>>>> =3D0 >>>>>>>=20 >>>>>>> Diff files showing all changes made during AUTH48: >>>>>>>=20 >>>>>>> https://www/ >>>>>>> .rfc-editor.org%2Fauthors%2Frfc9897- >>>>>>> auth48diff.html&data=3D05%7C02%7CMarkus.Amend%40telekom.de%7C29d >>>>>>> 2ebc7c7a443e69f1008de3862d243%7Cbde4dffc4b604cf68b04a5eeb25f5c >>>>>>> 4f%7C0%7C0%7C639010194262096590%7CUnknown%7CTWFpbGZsb3d8 >>>>>>> = eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOI >>>>>>> joiTWFpbCIsIldUIjoyfQ%3D%3D%7C0%7C%7C%7C&sdata=3D1rW%2F2QPTuFJx >>>>>>> rS0yv3fsAtVeAGgUgcMu3HMhZ1N5CzM%3D&reserved=3D0 >>>>>>>=20 >>>>>>> https://www/ >>>>>>> .rfc-editor.org%2Fauthors%2Frfc9897- >>>>>>> auth48rfcdiff.html&data=3D05%7C02%7CMarkus.Amend%40telekom.de%7C2 >>>>>>> 9d2ebc7c7a443e69f1008de3862d243%7Cbde4dffc4b604cf68b04a5eeb25f >>>>>>> 5c4f%7C0%7C0%7C639010194262107718%7CUnknown%7CTWFpbGZsb3 >>>>>>> = d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkF >>>>>>> OIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C0%7C%7C%7C&sdata=3D55t9Es9AmtI0 >>>>>>> 8AJb28NftRkiN1%2BtyWHSR%2FRj34GA4YU%3D&reserved=3D0 (side by = side) >>>>>>>=20 >>>>>>> Diff files showing all changes: >>>>>>>=20 >>>>>>> https://www/ >>>>>>> .rfc-editor.org%2Fauthors%2Frfc9897- >>>>>>> diff.html&data=3D05%7C02%7CMarkus.Amend%40telekom.de%7C29d2ebc7c >>>>>>> 7a443e69f1008de3862d243%7Cbde4dffc4b604cf68b04a5eeb25f5c4f%7C0 >>>>>>> %7C0%7C639010194262119479%7CUnknown%7CTWFpbGZsb3d8eyJFbXB >>>>>>> = 0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFp >>>>>>> bCIsIldUIjoyfQ%3D%3D%7C0%7C%7C%7C&sdata=3DlcZPpQWJ1o8j9xM0UUzB >>>>>>> mBCMULLhbphiXiRsJlAAj64%3D&reserved=3D0 >>>>>>>=20 >>>>>>> https://www/ >>>>>>> .rfc-editor.org%2Fauthors%2Frfc9897- >>>>>>> rfcdiff.html&data=3D05%7C02%7CMarkus.Amend%40telekom.de%7C29d2ebc >>>>>>> 7c7a443e69f1008de3862d243%7Cbde4dffc4b604cf68b04a5eeb25f5c4f%7 >>>>>>> C0%7C0%7C639010194262141617%7CUnknown%7CTWFpbGZsb3d8eyJFb >>>>>>> = XB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTW >>>>>>> FpbCIsIldUIjoyfQ%3D%3D%7C0%7C%7C%7C&sdata=3DMPJSQ3evKTVPXujzd5 >>>>>>> No7Qnni%2FHRadAqn8uUFRdFujY%3D&reserved=3D0 (side by side) >>>>>>>=20 >>>>>>> For the AUTH48 status of this document, please see: >>>>>>>=20 >>>>>>> https://www/ >>>>>>> .rfc- >>>>>>> editor.org%2Fauth48%2Frfc9897&data=3D05%7C02%7CMarkus.Amend%40tel >>>>>>> ekom.de%7C29d2ebc7c7a443e69f1008de3862d243%7Cbde4dffc4b604cf6 >>>>>>> 8b04a5eeb25f5c4f%7C0%7C0%7C639010194262153473%7CUnknown%7 >>>>>>> CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOi >>>>>>> JXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C0%7C%7C%7C&sdata=3D >>>>>>> 5XlvDM%2BF%2FpoDSIr%2BHjWKEWmi7MpRxohEU%2FLKHmOIOuc%3D&re >>>>>>> served=3D0 >>>>>>>=20 >>>>>>> Best regards, >>>>>>> Karen Moore >>>>>>> RFC Production Center >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>>> On Dec 9, 2025, at 12:25=E2=80=AFAM, >>>>>>>>=20 >>>>>>> Markus.Amend=3D40telekom.de@dmarc.ietf.org wrote: >>>>>>>=20 >>>>>>>> Dear RFC Editor team, Karen, Alice, >>>>>>>>=20 >>>>>>>> I would like to apologise for the long response time, but we = wanted to >>>>>>>>=20 >>>>>>> ensure consolidated feedback. >>>>>>>=20 >>>>>>>> Thank you very much for your already applied changes in >>>>>>>>=20 >>>>>>> https://www/ >>>>>>> .rfc-editor.org%2Fauthors%2Frfc9897- >>>>>>> rfcdiff.html&data=3D05%7C02%7CMarkus.Amend%40telekom.de%7C29d2ebc >>>>>>> 7c7a443e69f1008de3862d243%7Cbde4dffc4b604cf68b04a5eeb25f5c4f%7 >>>>>>> C0%7C0%7C639010194262164193%7CUnknown%7CTWFpbGZsb3d8eyJFb >>>>>>> = XB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTW >>>>>>> FpbCIsIldUIjoyfQ%3D%3D%7C0%7C%7C%7C&sdata=3DOVGAa2iSk2jsV%2ByK >>>>>>> RWbOFyFxpe7pv6raqLf0btCQ4HU%3D&reserved=3D0 we agree with, = except for >>>>>>> three instances: >>>>>>>=20 >>>>>>>> - The text "However the definition of a path management method, = in which >>>>>>>>=20 >>>>>>> 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. >>>>>>>=20 >>>>>>>> - The sentence "DCCP defines that if the checksum fails, the = receiving >>>>>>>>=20 >>>>>>> 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: >>>>>>>=20 >>>>>>>> New: "As defined by DCCP, if the checksum fails, the receiving = endpoint..." >>>>>>>>=20 >>>>>>>> - The affiliation of an author has changed because the = university has been >>>>>>>>=20 >>>>>>> renamed. We ask you to replace for the author Veselin Rakocevic = the affiliation >>>>>>> from >>>>>>>=20 >>>>>>>> OLD: City, University of London >>>>>>>> to >>>>>>>> NEW: City St George's, University of London >>>>>>>>=20 >>>>>>>>=20 >>>>>>>> For the marked comments, you will find our = joint answers >>>>>>>>=20 >>>>>>> as follows and we will be happy to provide a final review of the = document >>>>>>> once they have been applied: >>>>>>>=20 >>>>>>>> With regard to 1), we, the authors, agree with your change. >>>>>>>>=20 >>>>>>>> Regarding 2), the authors propose the following keywords to be = added: >>>>>>>> dccp >>>>>>>> extensions >>>>>>>> multipath >>>>>>>> multihomed >>>>>>>> subflow >>>>>>>> concurrent >>>>>>>> simultaneous >>>>>>>> mobility >>>>>>>> mpdccp >>>>>>>> mp-dccp >>>>>>>>=20 >>>>>>>> With regard to 3), we, the authors, agree with your text = proposal and ask >>>>>>>>=20 >>>>>>> you to adopt it. >>>>>>>=20 >>>>>>>> With regard to 4) we prefer our own proposal which better = distinguish >>>>>>>>=20 >>>>>>> between ATSSS and hybrid access use case: >>>>>>>=20 >>>>>>>> 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 >>>>>>>>=20 >>>>>>> between the user equipment and an operator network, while hybrid = access >>>>>>> combines fixed and cellular access between a residential gateway = and an >>>>>>> operator network. >>>>>>>=20 >>>>>>>> With regard to 5), we, the authors, agree with your text = proposal and ask >>>>>>>>=20 >>>>>>> you to adopt it. >>>>>>>=20 >>>>>>>> With regard to 6), we, the authors, agree with your text = proposal and ask >>>>>>>>=20 >>>>>>> you to adopt it. >>>>>>>=20 >>>>>>>> With regard to 7), we, the authors, agree with your text = proposal and ask >>>>>>>>=20 >>>>>>> you to adopt it. >>>>>>>=20 >>>>>>>> With regard to 8), we, the authors, agree with your text = proposal for all >>>>>>>>=20 >>>>>>> Figures 7, 8, 22, 23 and ask you to adopt it. >>>>>>>=20 >>>>>>>> With regard to 9), we, the authors, prefer to have lead text = before the >>>>>>>>=20 >>>>>>> Figures 6, 9, 11, 12, 13, 14, 19 according to: >>>>>>>=20 >>>>>>>> - Fig 6: Please change the first two sentences in the first = paragraph from >>>>>>>>=20 >>>>>>>> Original: >>>>>>>> Some multipath options require confirmation from the remote = peer (see >>>>>>>>=20 >>>>>>> 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. >>>>>>>=20 >>>>>>>> to NEW including a move of Figure 6: >>>>>>>> Some multipath options require confirmation from the remote = peer (see >>>>>>>>=20 >>>>>>> Table 4) for which MP_CONFIRM is specified. >>>>>>>=20 >>>>>>>>=20 >>>>>>>>>> Figure 6 >>>>>>>>>>=20 >>>>>>>> Multipath options which require confirmation will be = retransmitted by the >>>>>>>>=20 >>>>>>> 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. >>>>>>>=20 >>>>>>>> - Fig 9: Please move Figure 9 after the first sentence >>>>>>>>=20 >>>>>>>> Original: >>>>>>>> Figure 9 >>>>>>>> The MP_JOIN option is used to add a new subflow to an existing = MP-DCCP >>>>>>>>=20 >>>>>>> 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 ... >>>>>>>=20 >>>>>>>> NEW: >>>>>>>> The MP_JOIN option is used to add a new subflow to an existing = MP-DCCP >>>>>>>>=20 >>>>>>> connection and REQUIRES a successful establishment of the first = subflow >>>>>>> using MP_KEY. >>>>>>>=20 >>>>>>>>>> Figure 9 >>>>>>>>>>=20 >>>>>>>> The Connection Identifier (CI) is the one from the peer host, = which ... >>>>>>>>=20 >>>>>>>> - Fig 11: Please add the following guiding text and resolve the = reference to >>>>>>>>=20 >>>>>>> section 4 (Security Considerations) accordingly: >>>>>>>=20 >>>>>>>> NEW: MP-DCCP protects against some man in the middle attacks as = further >>>>>>>>=20 >>>>>>> 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. >>>>>>>=20 >>>>>>>> - Fig 12: Please add the following lead text and resolve the = reference to >>>>>>>>=20 >>>>>>> RFC4340 accordingly: >>>>>>>=20 >>>>>>>> NEW: DCCP [RFC4340] defines a packet sequencing scheme that = continues >>>>>>>>=20 >>>>>>> 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. >>>>>>>=20 >>>>>>>> - Fig 13: Please add the following guiding text and resolve the = reference to >>>>>>>>=20 >>>>>>> section 4 (Security Considerations) accordingly: >>>>>>>=20 >>>>>>>> NEW: MP-DCCP protects against some man in the middle attacks as = further >>>>>>>>=20 >>>>>>> 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. >>>>>>>=20 >>>>>>>> - Fig 14: Please move Figure 14 after the first paragraph >>>>>>>>=20 >>>>>>>> Original: >>>>>>>> Figure 14 >>>>>>>> The MP_RTT suboption is used to transmit RTT values and Age = (represented >>>>>>>>=20 >>>>>>> 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. >>>>>>>=20 >>>>>>>> NEW: >>>>>>>> The MP_RTT suboption is used to transmit RTT values and Age = (represented >>>>>>>>=20 >>>>>>> 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. >>>>>>>=20 >>>>>>>>>> Figure 14 >>>>>>>>>>=20 >>>>>>>> - Fig 19: Please add the following lead text and resolve the = reference to >>>>>>>>=20 >>>>>>> RFC4340 accordingly: >>>>>>>=20 >>>>>>>> NEW: The mechanism available in DCCP [RFC4340] for closing a = connection >>>>>>>>=20 >>>>>>> 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. >>>>>>>=20 >>>>>>>> With regard to 10), we, the authors, agree with your text = proposal and ask >>>>>>>>=20 >>>>>>> you to adopt it. >>>>>>>=20 >>>>>>>> With regard to 11), we, the authors, agree with your second = text proposal >>>>>>>>=20 >>>>>>> introducing " hosts' " and ask you to adopt it. >>>>>>>=20 >>>>>>>> With regard to 12), we, the authors, think it would be useful = to change from >>>>>>>>=20 >>>>>>> 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". >>>>>>>=20 >>>>>>>> With regard to 13), we, the authors, agree with your text = proposal for both >>>>>>>>=20 >>>>>>> section 3.2.8 and 3.2.9 and ask you to adopt it. >>>>>>>=20 >>>>>>>> With regard to 14), we, the authors, agree with your change. >>>>>>>>=20 >>>>>>>> With regard to 15), we, the authors, agree with your text = proposal and ask >>>>>>>>=20 >>>>>>> you to adopt it. >>>>>>>=20 >>>>>>>> With regard to 16), we, the authors, agree that "appropriate = one" is not >>>>>>>>=20 >>>>>>> necessary. However, we prefer a slightly different rephrasing = and ask you to >>>>>>> adopt the following: >>>>>>>=20 >>>>>>>> NEW: In the case of path mobility (Section 3.11.1), only one = path can be >>>>>>>>=20 >>>>>>> used at a time and MUST have the highest available priority = value. That also >>>>>>> includes the prio numbers 1 and 2. >>>>>>>=20 >>>>>>>> With regard to 17), we, the authors, agree with your text = proposal and ask >>>>>>>>=20 >>>>>>> you to adopt it. >>>>>>>=20 >>>>>>>> With regard to 18), we, the authors, hope that the following = sentence is >>>>>>>>=20 >>>>>>> clearer and can be used instead: >>>>>>>=20 >>>>>>>> NEW: Please note that the Key Data sent in DCCP-CloseReq will = not be the >>>>>>>>=20 >>>>>>> same as the Key Data sent in DCCP-Close as these originate from = different ends >>>>>>> of the connection >>>>>>>=20 >>>>>>>> With regard to 19), we, the authors, agree with your text = proposal and ask >>>>>>>>=20 >>>>>>> you to adopt it. >>>>>>>=20 >>>>>>>> With regard to 20), we, the authors, agree with your change. >>>>>>>>=20 >>>>>>>> With regard to 21), we, the authors, propose to simply remove = "own". >>>>>>>>=20 >>>>>>>> With regard to 22), we, the authors, agree with your text = proposal and ask >>>>>>>>=20 >>>>>>> you to adopt it. >>>>>>>=20 >>>>>>>> With regard to 23), we, the authors, agree with your text = proposal and ask >>>>>>>>=20 >>>>>>> you to adopt it. >>>>>>>=20 >>>>>>>> With regard to 24), we, the authors, agree with your text = proposal and ask >>>>>>>>=20 >>>>>>> you to adopt it. >>>>>>>=20 >>>>>>>> With regard to 25), we, the authors, agree with your text = proposal and ask >>>>>>>>=20 >>>>>>> you to adopt it. >>>>>>>=20 >>>>>>>> With regard to 26), we, the authors, agree with your text = proposal and ask >>>>>>>>=20 >>>>>>> you to adopt it. >>>>>>>=20 >>>>>>>> With regard to 27), we, the authors, agree with your text = proposal and ask >>>>>>>>=20 >>>>>>> you to adopt it. >>>>>>>=20 >>>>>>>> With regard to 28), we, the authors, determined a typo and ask = you to >>>>>>>>=20 >>>>>>> replace wrong [RFC4043] with correct [RFC4340]. Please also = remove the >>>>>>> bibliography entry of [RFC4043], as it is otherwise not used = anywhere else. >>>>>>>=20 >>>>>>>> With regard to 29), we, the authors, agree with your text = proposal in a) and >>>>>>>>=20 >>>>>>> ask you to adopt it. Also we agree with your applied change = described in b). >>>>>>>=20 >>>>>>>> With regard to 30), we, the authors, agree with your proposal = to add a >>>>>>>>=20 >>>>>>> reference link to the paper and ask you to adopt it. >>>>>>>=20 >>>>>>>> With regard to 31), we, the authors, agree with your proposal = in b) and ask >>>>>>>>=20 >>>>>>> you to adopt it. For a) we answer as follows: >>>>>>>=20 >>>>>>>> - CLOSED state vs. CLOSE state vs. CLOSING state >>>>>>>> According to >>>>>>>>=20 >>>>>>> https://datat/ >>>>>>> racker.ietf.org%2Fdoc%2Fhtml%2Frfc4340%23section- >>>>>>> 4.3&data=3D05%7C02%7CMarkus.Amend%40telekom.de%7C29d2ebc7c7a44 >>>>>>> 3e69f1008de3862d243%7Cbde4dffc4b604cf68b04a5eeb25f5c4f%7C0%7C >>>>>>> 0%7C639010194262181212%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU >>>>>>> = 1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIs >>>>>>> IldUIjoyfQ%3D%3D%7C0%7C%7C%7C&sdata=3DfrUpY29Mj1uV2Cbal0oru5fj% >>>>>>> 2FxQ%2B4usRSrbk9bZMPGo%3D&reserved=3D0, 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. >>>>>>>=20 >>>>>>>> - Client and Server vs. client and server (as well as 'the = client and the server') >>>>>>>> We prefer "Client and Server" >>>>>>>>=20 >>>>>>>> - Congestion Control procedure vs. congestion control scheme >>>>>>>> We are fine if you replace congestion control scheme by = Congestion Control >>>>>>>>=20 >>>>>>> procedure >>>>>>>=20 >>>>>>>> - "Fast Close" vs. fast close >>>>>>>> We are fine with your proposal to change "Fast Close" to "fast = close" and ask >>>>>>>>=20 >>>>>>> you to adopt it. >>>>>>>=20 >>>>>>>> - Feature number 10 vs. feature number 10 >>>>>>>> We prefer any occurrence of feature number of Feature number to = be >>>>>>>>=20 >>>>>>> replaced with Feature Number according to IANA style >>>>>>>=20 >>>>>>>> - Length vs. length >>>>>>>> If the term length refers to the Length data field of a header = option, we >>>>>>>>=20 >>>>>>> prefer the capitalisation of Length instead of length and ask = you to adopt this >>>>>>>=20 >>>>>>>> - handshake procedure/process vs. handshaking procedure/process >>>>>>>> We prefer overall "handshake procedure" and ask you to adopt = this. >>>>>>>>=20 >>>>>>>> - Key Type vs. Key types vs. key type >>>>>>>> We generally prefer Key Type (singular) or Key Types (plural) = and ask you to >>>>>>>>=20 >>>>>>> adopt this. >>>>>>>=20 >>>>>>>> - Multipath Capability vs. multipath capability >>>>>>>> We prefer in general multipath capability and ask you to adopt = this. >>>>>>>>=20 >>>>>>>> - Multipath feature vs. multipath feature >>>>>>>> We prefer Multipath Feature except for the occurrence in = Appendix A where >>>>>>>>=20 >>>>>>> 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". >>>>>>>=20 >>>>>>>> - Multipath option vs. multipath option vs. MP option >>>>>>>> We prefer the general usage of Multipath Option (singular) or = Multipath >>>>>>>>=20 >>>>>>> Options (plural) and ask you to adopt this. >>>>>>>=20 >>>>>>>> - Multipath Capable Feature vs. Multipath Capable feature vs. = MP-Capable >>>>>>>>=20 >>>>>>> feature vs. MP_CAPABLE feature >>>>>>>=20 >>>>>>>> We prefer the general usage of "Multipath Capable Feature" and = ask you to >>>>>>>>=20 >>>>>>> adopt this. >>>>>>>=20 >>>>>>>> - Nonce vs. nonce >>>>>>>> We prefer the general usage of "Nonce" and ask you to adopt = this. >>>>>>>>=20 >>>>>>>> - 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. >>>>>>>>=20 >>>>>>>> - Reset Code vs. reset code >>>>>>>> We prefer the general usage of "Reset Code" and ask you to = adopt this. >>>>>>>>=20 >>>>>>>> - Remove Address vs. Remove address (Tables 3 and 8) >>>>>>>> We prefer the general usage of "Remove Address" and ask you to = adopt this. >>>>>>>>=20 >>>>>>>> SHA256 vs. SHA-256 >>>>>>>> According to the terminology in RFC6234 we prefer to change = SHA256 to >>>>>>>>=20 >>>>>>> SHA-256 and ask you to adopt this. >>>>>>>=20 >>>>>>>> With regard to 32), we, the authors, agree with your proposal = in a) and c) >>>>>>>>=20 >>>>>>> and ask you to adopt it. For b) we prefer Multipath DCCP without = hyphen and >>>>>>> ask you to adopt it. >>>>>>>=20 >>>>>>>> With regard to 33), we, the authors, agree with your concern = and ask you to >>>>>>>>=20 >>>>>>> adopt the following: >>>>>>>=20 >>>>>>>> Original: ... that updates the (traditionally asymmetric) = connection- >>>>>>>>=20 >>>>>>> establishment procedures for DCCP. >>>>>>>=20 >>>>>>>> New: that updates the asymmetric connection-establishment = procedures for >>>>>>>>=20 >>>>>>> DCCP. >>>>>>>=20 >>>>>>>>=20 >>>>>>>> By the way, while editing the document, we noticed that >>>>>>>>=20 >>>>>>> https://www/ >>>>>>> .rfc- >>>>>>> editor.org%2Fauth48%2Frfc9897&data=3D05%7C02%7CMarkus.Amend%40tel >>>>>>> ekom.de%7C29d2ebc7c7a443e69f1008de3862d243%7Cbde4dffc4b604cf6 >>>>>>> 8b04a5eeb25f5c4f%7C0%7C0%7C639010194262195396%7CUnknown%7 >>>>>>> CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOi >>>>>>> JXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C0%7C%7C%7C&sdata=3D >>>>>>> rZHoWUJ%2F0EUIgq3IjFcb%2BSoK%2FPLHPSLd8%2ByhfZraQBQ%3D&reserv >>>>>>> ed=3D0 is broken. >>>>>>>=20 >>>>>>>> BR >>>>>>>>=20 >>>>>>>> Markus & co-authors >>>>>>>>=20 >>>>>>>>=20 >>>>>>>>> -----Urspr=C3=BCngliche Nachricht----- >>>>>>>>> Von: rfc-editor@rfc-editor.org >>>>>>>>> Gesendet: Dienstag, 28. Oktober 2025 07:01 >>>>>>>>> An: Amend, Markus ; >>>>>>>>> anna.brunstrom@kau.se; andreas.kassler@kau.se; >>>>>>>>> veselin.rakocevic.1@city.ac.uk; stephen.h.johnson@bt.com >>>>>>>>> Cc: rfc-editor@rfc-editor.org; tsvwg-ads@ietf.org; = tsvwg-chairs@ietf.org; >>>>>>>>> gorry@erg.abdn.ac.uk; gorry@erg.abdn.ac.uk; auth48archive@rfc- >>>>>>>>>=20 >>>>>>> editor.org >>>>>>>=20 >>>>>>>>> Betreff: Re: AUTH48: RFC-to-be 9897 = >>>>>>>>> for your review >>>>>>>>>=20 >>>>>>>>> Authors, >>>>>>>>>=20 >>>>>>>>> While reviewing this document during AUTH48, please resolve = (as >>>>>>>>>=20 >>>>>>> necessary) >>>>>>>=20 >>>>>>>>> the following questions, which are also in the source file. >>>>>>>>>=20 >>>>>>>>> 1) >>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>> 2) >>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>> 3) >>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>> 4) >>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>> 5) >>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>> 6) >>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>> 7) >>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>> 8) >>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>> 9) >>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>> 10) >>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>> 11) >>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>> 12) >>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>> 13) >>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>> 14) >>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>> 15) >>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>> 16) >>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>> 17) >>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>> 18) >>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>> 19) >>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>> 20) >>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>> 21) >>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>> 22) >>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>> 23) >>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>> 24) >>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>> 25) >>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>> 26) >>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>> 27) >>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>> 28) >>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>> 29) >>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>> 30) >>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>> 31) >>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>> 32) >>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>> 33) >>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>> Thank you. >>>>>>>>>=20 >>>>>>>>> Karen Moore and Alice Russo >>>>>>>>> RFC Production Center >>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>> On Oct 27, 2025, rfc-editor@rfc-editor.org wrote: >>>>>>>>>=20 >>>>>>>>> *****IMPORTANT***** >>>>>>>>>=20 >>>>>>>>> Updated 2025/10/27 >>>>>>>>>=20 >>>>>>>>> RFC Author(s): >>>>>>>>> -------------- >>>>>>>>>=20 >>>>>>>>> Instructions for Completing AUTH48 >>>>>>>>>=20 >>>>>>>>> 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- >>>>>>>>>=20 >>>>>>>>>=20 >>>>>>> editor.org%2Ffaq%2F&data=3D05%7C02%7CMarkus.Amend%40telekom.de%7 >>>>>>>=20 >>>>>>>>>=20 >>>>>>> C34f67a154541449bd12808de15e77765%7Cbde4dffc4b604cf68b04a5eeb >>>>>>>=20 >>>>>>>>>=20 >>>>>>> 25f5c4f%7C0%7C0%7C638972281329094139%7CUnknown%7CTWFpbGZs >>>>>>>=20 >>>>>>>>>=20 >>>>>>> b3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIs >>>>>>>=20 >>>>>>>>>=20 >>>>>>> IkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C0%7C%7C%7C&sdata=3DyS8vk075Pr >>>>>>>=20 >>>>>>>>> gUh6i28%2F97rsn52kWyLEgkpc7bmSwnGQg%3D&reserved=3D0). >>>>>>>>>=20 >>>>>>>>> You and you coauthors are responsible for engaging other = parties >>>>>>>>> (e.g., Contributors or Working Group) as necessary before = providing >>>>>>>>> your approval. >>>>>>>>>=20 >>>>>>>>> Planning your review >>>>>>>>> --------------------- >>>>>>>>>=20 >>>>>>>>> Please review the following aspects of your document: >>>>>>>>>=20 >>>>>>>>> * RFC Editor questions >>>>>>>>>=20 >>>>>>>>> Please review and resolve any questions raised by the RFC = Editor >>>>>>>>> that have been included in the XML file as comments marked as >>>>>>>>> follows: >>>>>>>>>=20 >>>>>>>>> >>>>>>>>>=20 >>>>>>>>> These questions will also be sent in a subsequent email. >>>>>>>>>=20 >>>>>>>>> * Changes submitted by coauthors >>>>>>>>>=20 >>>>>>>>> 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. >>>>>>>>>=20 >>>>>>>>> * Content >>>>>>>>>=20 >>>>>>>>> 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 >>>>>>>>>=20 >>>>>>>>> * Copyright notices and legends >>>>>>>>>=20 >>>>>>>>> Please review the copyright notice and legends as defined in >>>>>>>>> RFC 5378 and the Trust Legal Provisions >>>>>>>>> (TLP - >>>>>>>>> https://trust/ >>>>>>>>> ee.ietf.org%2Flicense- >>>>>>>>>=20 >>>>>>>>>=20 >>>>>>> info&data=3D05%7C02%7CMarkus.Amend%40telekom.de%7C34f67a1545414 >>>>>>>=20 >>>>>>>>>=20 >>>>>>> 49bd12808de15e77765%7Cbde4dffc4b604cf68b04a5eeb25f5c4f%7C0%7C >>>>>>>=20 >>>>>>>>>=20 >>>>>>> 0%7C638972281329103134%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU >>>>>>>=20 >>>>>>>>>=20 >>>>>>> = 1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIs >>>>>>>=20 >>>>>>>>>=20 >>>>>>> IldUIjoyfQ%3D%3D%7C0%7C%7C%7C&sdata=3DjYmJhjGvE8Q%2FUmf0QreVat >>>>>>>=20 >>>>>>>>> WqNeogHyoEw0VsXjW%2BPqk%3D&reserved=3D0). >>>>>>>>>=20 >>>>>>>>> * Semantic markup >>>>>>>>>=20 >>>>>>>>> Please review the markup in the XML file to ensure that = elements of >>>>>>>>> content are correctly tagged. For example, ensure that = >>>>>>>>> and are set correctly. See details at >>>>>>>>>=20 >>>>>>>>> >>>>>>>> hors.ietf.org%2Frfcxml- >>>>>>>>>=20 >>>>>>>>>=20 >>>>>>> vocabulary&data=3D05%7C02%7CMarkus.Amend%40telekom.de%7C34f67a1 >>>>>>>=20 >>>>>>>>>=20 >>>>>>> 54541449bd12808de15e77765%7Cbde4dffc4b604cf68b04a5eeb25f5c4f% >>>>>>>=20 >>>>>>>>>=20 >>>>>>> 7C0%7C0%7C638972281329112128%7CUnknown%7CTWFpbGZsb3d8eyJF >>>>>>>=20 >>>>>>>>>=20 >>>>>>> = bXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiT >>>>>>>=20 >>>>>>>>>=20 >>>>>>> WFpbCIsIldUIjoyfQ%3D%3D%7C0%7C%7C%7C&sdata=3D1W8OEzSMEo49hde >>>>>>>=20 >>>>>>>>> FNk8b0%2FLzcKo%2F7%2Fy%2Bbp%2FYyyJPU5Q%3D&reserved=3D0>. >>>>>>>>>=20 >>>>>>>>> * Formatted output >>>>>>>>>=20 >>>>>>>>> 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. >>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>> Submitting changes >>>>>>>>> ------------------ >>>>>>>>>=20 >>>>>>>>> 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: >>>>>>>>>=20 >>>>>>>>> * your coauthors >>>>>>>>>=20 >>>>>>>>> * rfc-editor@rfc-editor.org (the RPC team) >>>>>>>>>=20 >>>>>>>>> * other document participants, depending on the stream (e.g., >>>>>>>>> IETF Stream participants are your working group chairs, the >>>>>>>>> responsible ADs, and the document shepherd). >>>>>>>>>=20 >>>>>>>>> * auth48archive@rfc-editor.org, which is a new archival = mailing list >>>>>>>>> to preserve AUTH48 conversations; it is not an active = discussion >>>>>>>>> list: >>>>>>>>>=20 >>>>>>>>> * More info: >>>>>>>>>=20 >>>>>>>>> https://maila/ >>>>>>>>> rchive.ietf.org%2Farch%2Fmsg%2Fietf-announce%2Fyb6lpIGh- >>>>>>>>>=20 >>>>>>>>>=20 >>>>>>> 4Q9l2USxIAe6P8O4Zc&data=3D05%7C02%7CMarkus.Amend%40telekom.de% >>>>>>>=20 >>>>>>>>>=20 >>>>>>> 7C34f67a154541449bd12808de15e77765%7Cbde4dffc4b604cf68b04a5ee >>>>>>>=20 >>>>>>>>>=20 >>>>>>> b25f5c4f%7C0%7C0%7C638972281329121524%7CUnknown%7CTWFpbGZ >>>>>>>=20 >>>>>>>>>=20 >>>>>>> sb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiI >>>>>>>=20 >>>>>>>>>=20 >>>>>>> sIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C0%7C%7C%7C&sdata=3DWinHATdEh >>>>>>>=20 >>>>>>>>> dQovFkGOUC8P749REPaoYR1%2FkQHv%2B7abtk%3D&reserved=3D0 >>>>>>>>>=20 >>>>>>>>> * The archive itself: >>>>>>>>>=20 >>>>>>>>> https://maila/ >>>>>>>>>=20 >>>>>>>>>=20 >>>>>>> = rchive.ietf.org%2Farch%2Fbrowse%2Fauth48archive%2F&data=3D05%7C02%7 >>>>>>>=20 >>>>>>>>>=20 >>>>>>> CMarkus.Amend%40telekom.de%7C34f67a154541449bd12808de15e7776 >>>>>>>=20 >>>>>>>>>=20 >>>>>>> 5%7Cbde4dffc4b604cf68b04a5eeb25f5c4f%7C0%7C0%7C6389722813291 >>>>>>>=20 >>>>>>>>>=20 >>>>>>> 33709%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOi >>>>>>>=20 >>>>>>>>>=20 >>>>>>> IwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7 >>>>>>>=20 >>>>>>>>>=20 >>>>>>> C0%7C%7C%7C&sdata=3DZh619HF0OTx8rFWoJ%2BCRBOI4H1gzLNwpjPC4Rrv >>>>>>>=20 >>>>>>>>> RWms%3D&reserved=3D0 >>>>>>>>>=20 >>>>>>>>> * 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, >>>>>>>>> auth48archive@rfc-editor.org will be re-added to the CC list = and >>>>>>>>> its addition will be noted at the top of the message. >>>>>>>>>=20 >>>>>>>>> You may submit your changes in one of two ways: >>>>>>>>>=20 >>>>>>>>> An update to the provided XML file >>>>>>>>> - OR - >>>>>>>>> An explicit list of changes in this format >>>>>>>>>=20 >>>>>>>>> Section # (or indicate Global) >>>>>>>>>=20 >>>>>>>>> OLD: >>>>>>>>> old text >>>>>>>>>=20 >>>>>>>>> NEW: >>>>>>>>> new text >>>>>>>>>=20 >>>>>>>>> You do not need to reply with both an updated XML file and an = explicit >>>>>>>>> list of changes, as either form is sufficient. >>>>>>>>>=20 >>>>>>>>> We will ask a stream manager to review and approve any changes = that >>>>>>>>>=20 >>>>>>> seem >>>>>>>=20 >>>>>>>>> beyond editorial in nature, e.g., addition of new text, = deletion of text, >>>>>>>>> and technical changes. Information about stream managers can = be found >>>>>>>>>=20 >>>>>>> in >>>>>>>=20 >>>>>>>>> the FAQ. Editorial changes do not require approval from a = stream manager. >>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>> Approving for publication >>>>>>>>> -------------------------- >>>>>>>>>=20 >>>>>>>>> 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. >>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>> Files >>>>>>>>> ----- >>>>>>>>>=20 >>>>>>>>> The files are available here: >>>>>>>>>=20 >>>>>>>>> https://www/ >>>>>>>>> .rfc- >>>>>>>>>=20 >>>>>>>>>=20 >>>>>>> editor.org%2Fauthors%2Frfc9897.xml&data=3D05%7C02%7CMarkus.Amend% >>>>>>>=20 >>>>>>>>>=20 >>>>>>> 40telekom.de%7C34f67a154541449bd12808de15e77765%7Cbde4dffc4b6 >>>>>>>=20 >>>>>>>>>=20 >>>>>>> 04cf68b04a5eeb25f5c4f%7C0%7C0%7C638972281329146321%7CUnkno >>>>>>>=20 >>>>>>>>>=20 >>>>>>> wn%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCI >>>>>>>=20 >>>>>>>>>=20 >>>>>>> sIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C0%7C%7C%7C&s >>>>>>>=20 >>>>>>>>>=20 >>>>>>> data=3DIHIoddWaDVRaiInViKyo1MT3W76iELytFnS5TlOHVCg%3D&reserved=3D0= >>>>>>>=20 >>>>>>>>> https://www/ >>>>>>>>> .rfc- >>>>>>>>>=20 >>>>>>>>>=20 >>>>>>> editor.org%2Fauthors%2Frfc9897.html&data=3D05%7C02%7CMarkus.Amend >>>>>>>=20 >>>>>>>>>=20 >>>>>>> %40telekom.de%7C34f67a154541449bd12808de15e77765%7Cbde4dffc4b >>>>>>>=20 >>>>>>>>>=20 >>>>>>> 604cf68b04a5eeb25f5c4f%7C0%7C0%7C638972281329157363%7CUnkno >>>>>>>=20 >>>>>>>>>=20 >>>>>>> wn%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCI >>>>>>>=20 >>>>>>>>>=20 >>>>>>> sIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C0%7C%7C%7C&s >>>>>>>=20 >>>>>>>>>=20 >>>>>>> data=3DgZTIy7dNXKu9gDgDdxx4GPxvnFc73FnosHh56emr71A%3D&reserved=3D0= >>>>>>>=20 >>>>>>>>> https://www/ >>>>>>>>> .rfc- >>>>>>>>>=20 >>>>>>>>>=20 >>>>>>> editor.org%2Fauthors%2Frfc9897.pdf&data=3D05%7C02%7CMarkus.Amend% >>>>>>>=20 >>>>>>>>>=20 >>>>>>> 40telekom.de%7C34f67a154541449bd12808de15e77765%7Cbde4dffc4b6 >>>>>>>=20 >>>>>>>>>=20 >>>>>>> 04cf68b04a5eeb25f5c4f%7C0%7C0%7C638972281329167327%7CUnkno >>>>>>>=20 >>>>>>>>>=20 >>>>>>> wn%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCI >>>>>>>=20 >>>>>>>>>=20 >>>>>>> sIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C0%7C%7C%7C&s >>>>>>>=20 >>>>>>>>>=20 >>>>>>> data=3DVn3pwzsdz%2FI0kwNbRcrIfjC0O3eQ8lRz8Dyojyobs7c%3D&reserved=3D= 0 >>>>>>>=20 >>>>>>>>> https://www/ >>>>>>>>> .rfc- >>>>>>>>>=20 >>>>>>>>>=20 >>>>>>> editor.org%2Fauthors%2Frfc9897.txt&data=3D05%7C02%7CMarkus.Amend%4= >>>>>>>=20 >>>>>>>>>=20 >>>>>>> 0telekom.de%7C34f67a154541449bd12808de15e77765%7Cbde4dffc4b60 >>>>>>>=20 >>>>>>>>>=20 >>>>>>> 4cf68b04a5eeb25f5c4f%7C0%7C0%7C638972281329177120%7CUnknow >>>>>>>=20 >>>>>>>>>=20 >>>>>>> n%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIl >>>>>>>=20 >>>>>>>>>=20 >>>>>>> AiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C0%7C%7C%7C&sd >>>>>>>=20 >>>>>>>>>=20 >>>>>>> ata=3D6lBOuHpymJ%2F3Y0DlYS6b0GPs2pFsF%2BOobJSSSPj0MmI%3D&reserv >>>>>>>=20 >>>>>>>>> ed=3D0 >>>>>>>>>=20 >>>>>>>>> Diff file of the text: >>>>>>>>>=20 >>>>>>>>> https://www/ >>>>>>>>> .rfc-editor.org%2Fauthors%2Frfc9897- >>>>>>>>>=20 >>>>>>>>>=20 >>>>>>> diff.html&data=3D05%7C02%7CMarkus.Amend%40telekom.de%7C34f67a154 >>>>>>>=20 >>>>>>>>>=20 >>>>>>> 541449bd12808de15e77765%7Cbde4dffc4b604cf68b04a5eeb25f5c4f%7C >>>>>>>=20 >>>>>>>>>=20 >>>>>>> 0%7C0%7C638972281329186742%7CUnknown%7CTWFpbGZsb3d8eyJFbX >>>>>>>=20 >>>>>>>>>=20 >>>>>>> = B0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWF >>>>>>>=20 >>>>>>>>>=20 >>>>>>> pbCIsIldUIjoyfQ%3D%3D%7C0%7C%7C%7C&sdata=3DEjJGCV0QREiYbaySpisjRg >>>>>>>=20 >>>>>>>>> gbGSE13QrF8LLU2AL3Kv0%3D&reserved=3D0 >>>>>>>>>=20 >>>>>>>>> https://www/ >>>>>>>>> .rfc-editor.org%2Fauthors%2Frfc9897- >>>>>>>>>=20 >>>>>>>>>=20 >>>>>>> rfcdiff.html&data=3D05%7C02%7CMarkus.Amend%40telekom.de%7C34f67a1 >>>>>>>=20 >>>>>>>>>=20 >>>>>>> 54541449bd12808de15e77765%7Cbde4dffc4b604cf68b04a5eeb25f5c4f% >>>>>>>=20 >>>>>>>>>=20 >>>>>>> 7C0%7C0%7C638972281329195621%7CUnknown%7CTWFpbGZsb3d8eyJF >>>>>>>=20 >>>>>>>>>=20 >>>>>>> = bXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiT >>>>>>>=20 >>>>>>>>>=20 >>>>>>> WFpbCIsIldUIjoyfQ%3D%3D%7C0%7C%7C%7C&sdata=3DetFLnas9CNj0YyhXJH >>>>>>>=20 >>>>>>>>> PPVciMeRuECj7Ue0XYsJzWx8c%3D&reserved=3D0 (side by side) >>>>>>>>>=20 >>>>>>>>> Diff of the XML: >>>>>>>>>=20 >>>>>>>>> https://www/ >>>>>>>>> .rfc-editor.org%2Fauthors%2Frfc9897- >>>>>>>>>=20 >>>>>>>>>=20 >>>>>>> xmldiff1.html&data=3D05%7C02%7CMarkus.Amend%40telekom.de%7C34f67a >>>>>>>=20 >>>>>>>>>=20 >>>>>>> 154541449bd12808de15e77765%7Cbde4dffc4b604cf68b04a5eeb25f5c4f >>>>>>>=20 >>>>>>>>>=20 >>>>>>> %7C0%7C0%7C638972281329204385%7CUnknown%7CTWFpbGZsb3d8ey >>>>>>>=20 >>>>>>>>>=20 >>>>>>> = JFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoi >>>>>>>=20 >>>>>>>>>=20 >>>>>>> TWFpbCIsIldUIjoyfQ%3D%3D%7C0%7C%7C%7C&sdata=3DwYgbW6gNLaBNU% >>>>>>>=20 >>>>>>>>> 2FWtDFve4vQyKNUHs5xPAf5UWT4BHug%3D&reserved=3D0 >>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>> Tracking progress >>>>>>>>> ----------------- >>>>>>>>>=20 >>>>>>>>> The details of the AUTH48 status of your document are here: >>>>>>>>>=20 >>>>>>>>> https://www/ >>>>>>>>> .rfc- >>>>>>>>>=20 >>>>>>>>>=20 >>>>>>> editor.org%2Fauth48%2Frfc9897&data=3D05%7C02%7CMarkus.Amend%40tel >>>>>>>=20 >>>>>>>>>=20 >>>>>>> ekom.de%7C34f67a154541449bd12808de15e77765%7Cbde4dffc4b604cf6 >>>>>>>=20 >>>>>>>>>=20 >>>>>>> 8b04a5eeb25f5c4f%7C0%7C0%7C638972281329213194%7CUnknown%7 >>>>>>>=20 >>>>>>>>>=20 >>>>>>> CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOi >>>>>>>=20 >>>>>>>>>=20 >>>>>>> JXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C0%7C%7C%7C&sdata=3D >>>>>>>=20 >>>>>>>>>=20 >>>>>>> 9RTrRiS8FahV7sm9w%2F329KQ18pDus7Sr%2F08qouliRas%3D&reserved=3D0 >>>>>>>=20 >>>>>>>>> Please let us know if you have any questions. >>>>>>>>>=20 >>>>>>>>> Thank you for your cooperation, >>>>>>>>>=20 >>>>>>>>> RFC Editor >>>>>>>>>=20 >>>>>>>>> -------------------------------------- >>>>>>>>> RFC9897 (draft-ietf-tsvwg-multipath-dccp-24) >>>>>>>>>=20 >>>>>>>>> Title : DCCP Extensions for Multipath Operation with Multiple >>>>>>>>>=20 >>>>>>> Addresses >>>>>>>=20 >>>>>>>>> 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 >>>>>>>>>=20 >>>>>>>>=20 >>>>>>=20 >>>>>=20 >>>=20 >>=20 >=20 > N=C3=A4r du skickar e-post till Karlstads universitet behandlar vi = dina personuppgifter. > When you send an e-mail to Karlstad University, we will process your = personal data.