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/search. -->
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://www.iana.org/assignments/dccp-parameters/>.
-->
30) <!-- [rfced] We found the URL
<https://dl.acm.org/doi/10.1145/2413176.2413178> 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.acm.org/doi/10.1145/2413176.2413178>.
-->
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://www.rfc-editor.org/styleguide/part2/#exp_abbrev>, 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://www.rfc-editor.org/styleguide/part2/#inclusive_language>
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://web.archive.org/web/20250214092458/https://www.nist.gov/nist-research-library/
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://www.rfc-editor.org/faq/).
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://trustee.ietf.org/license-info).
* 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://authors.ietf.org/rfcxml-vocabulary>.
* 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://mailarchive.ietf.org/arch/msg/ietf-announce/yb6lpIGh-4Q9l2USxIAe6P8O4Zc
* The archive itself:
https://mailarchive.ietf.org/arch/browse/auth48archive/
* 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/authors/rfc9897.xml
https://www.rfc-editor.org/authors/rfc9897.html
https://www.rfc-editor.org/authors/rfc9897.pdf
https://www.rfc-editor.org/authors/rfc9897.txt
Diff file of the text:
https://www.rfc-editor.org/authors/rfc9897-diff.html
https://www.rfc-editor.org/authors/rfc9897-rfcdiff.html (side by side)
Diff of the XML:
https://www.rfc-editor.org/authors/rfc9897-xmldiff1.html
Tracking progress
-----------------
The details of the AUTH48 status of your document are here:
https://www.rfc-editor.org/auth48/rfc9897
Please let us know if you have any questions.
Thank you for your cooperation,
RFC Editor
--------------------------------------
RFC9897 (draft-ietf-tsvwg-multipath-dccp-24)
Title : DCCP Extensions for Multipath Operation with Multiple
Addresses
Author(s) : M. Amend, Ed., A. Brunstrom, A. Kassler, V. Rakocevic, S.
Johnson
WG Chair(s) : Martin Duke, Zaheduzzaman Sarker
Area Director(s) : Gorry Fairhurst, Mike Bishop
--
auth48archive mailing list -- [email protected]
To unsubscribe send an email to [email protected]
