Re: [tsvwg] WGLC concluded for draft-ietf-tsvwg-multipath-dccp as PS

[[e-mail]]

Hi Gorry, all,

The authors asked me to check if I have any comments about the changes made since last time I reviewed the document. So, I went and read -14. 

I have only minor editorial comments and one comment about this note:

(1)

   The specification of scheduling for concurrent multipath and related
   the congestion control algorithms and re-ordering methods for use in
   the general Internet are outside the scope of this document.  If, and
   when, the IETF specifies a method for concurrent usage of multiple
   paths for the general Internet, the framework specified in this
   document could be used to provide an IETF recommended method for MP-
   DCCP.

I still don't understand why this note is imposed here while there is no such restriction on draft-ietf-quic-multipath or MPTCP. I think we need to be consistent here especially that the design in the document mirrors what is in RFC 8684.

(2) Editorial:

* s/[RFC4340]/(RFC 4340): citations are not allowed in the abstract.
* I would delete this sentence from the abstract because the applicability it UDP/plain IP is discussed in separate individual I-Ds:

   Compared to the existing multipath
   protocols, such as MPTCP, MP-DCCP provides specific support for non-
   TCP user traffic (e.g., UDP or plain IP).

* I would also delete this one as it is redundant with the sentence right before:

   Multipath DCCP provides the ability to
   simultaneously use multiple paths between peers.  

* I'm not sure I would keep the para with in the main text: 

   MP-DCCP was first suggested in the context of the 3GPP ..

* s/ proposes a lightweight encapsulation for DCCP/ proposes an
   encapsulation for DCCP

* s/it/MP-DCCP (many occurrences in 1.1)

* Consider deleting Table 1 as this is redundant with the IANA section. If you keep it, make sure "10" is tagged a suggested value  + add a note to IANA to update it.

* Idem for Table 2.

* s/[RFC4340] Section 6/Section 6 of [RFC4340]

* s/The fields used by the the multipath option/The fields used by the multipath option

* s/Cellular due to e.g. cost reasons/Cellular due to, e.g., cost reasons

* s/In the case of path mobility Section 3.11.1/In the case of path mobility (Section 3.11.1)

* s/A MP_SEQ Section 3.2.5 MUST be/A MP_SEQ (Section 3.2.5) MUST be

* s/Contrary to a MP_FAST_CLOSE Section 3.2.3/Contrary to a MP_FAST_CLOSE (Section 3.2.3)

* s/the MP_KEY option with an Host-specific/the MP_KEY option with a Host-specific

* broken formatting 

OLD: 
  * an identifier (id 2) for
   the new IP address which is used as a reference in subsequent control
   exchanges. * the IP address of the new path (A2_IP) * A pair of
   octets specifying the port number associated with this IP address.

NEW:
  * an identifier (id 2) for  the new IP address which is used as a reference in subsequent control
   exchanges. 

  * the IP address of the new path (A2_IP)

  * A pair of octets specifying the port number associated with this IP address.

* The same issue with other parts:

   The following options MUST be included in a packet carrying
   MP_ADDADDR: * the leftmost 20 bytes of the HMAC(A) generated during
   the initial handshaking procedure described in Section 3.3 and
   Section 3.2.6 * the MP_SEQ option with the sequence number (seqno 12)
   for this message according to Section 3.2.5.

   Host B acknowledges receipt of the MP_ADDADDR message with a DCCP-Ack
   containing the MP_CONFIRM option.  The parameters supplied in this
   response are as follows: * an MP_CONFIRM containing the MP_SEQ number
   (seqno 12) of the packet carrying the option that we are confirming
   together with the MP_ADDADDR option * the leftmost 20 bytes of the
   HMAC(B) generated during the initial handshaking procedure
   Section 3.3

   etc.

* 

* Move these to be listed as normative (please check other entries as well): 

   [RFC4086]  Eastlake 3rd, D., Schiller, J., and S. Crocker,
              "Randomness Requirements for Security", BCP 106, RFC 4086,
              DOI 10.17487/RFC4086, June 2005,
              <https://www.rfc-editor.org/rfc/rfc4086>.

   [RFC6234]  Eastlake 3rd, D. and T. Hansen, "US Secure Hash Algorithms
              (SHA and SHA-based HMAC and HKDF)", RFC 6234,
              DOI 10.17487/RFC6234, May 2011,
              <https://www.rfc-editor.org/rfc/rfc6234>.

   [RFC8126]  Cotton, M., Leiba, B., and T. Narten, "Guidelines for
              Writing an IANA Considerations Section in RFCs", BCP 26,
              RFC 8126, DOI 10.17487/RFC8126, June 2017,
              <https://www.rfc-editor.org/rfc/rfc8126>.

   [RFC8174]  Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
              2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
              May 2017, <https://www.rfc-editor.org/rfc/rfc8174>.

* This one was obsoleted by RFC9293

   [RFC0793]  Postel, J., "Transmission Control Protocol", RFC 793,
              DOI 10.17487/RFC0793, September 1981,
              <https://www.rfc-editor.org/rfc/rfc793>.


Cheers,
Med

> -----Message d'origine-----
> De : tsvwg <[e-mail]> De la part de Gorry Fairhurst
> Envoyé : lundi 11 mars 2024 13:31
> À : [e-mail]
> Cc : [e-mail]
> Objet : [tsvwg] WGLC concluded for draft-ietf-tsvwg-multipath-dccp as
> PS
> 
> The WGLC fordraft-ietf-tsvwg-multipath-dccp has concluded.
> 
> See:https://eur03.safelinks.protection.outlook.com/?url=https%3A%2F%2F
> datatracker.ietf.org%2Fdoc%2Fdraft-ietf-tsvwg-multipath-
> dccp%2F&data=05%7C02%7Cmohamed.boucadair%40orange.com%7C459ff18746c34b
> 661b8b08dc41c72d5a%7C90c7a20af34b40bfbc48b9253b6f5d20%7C0%7C0%7C638457
> 570918853685%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luM
> zIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C0%7C%7C%7C&sdata=jOwmVR3eRDhbPXHkA
> vTdPSspyNGr2S%2B6IZZEOmzJg%2FE%3D&reserved=0
> 
> There was WG consensus to adopt as a PS (07/2023).
> 
> This WGLC in 02/2024 received reviews by: Kevin Smith, read and ready
> Franisco Fontes, read and ready Hang, read and ready Chris Box, ready
> and review comments
> 
> Issues were raised during the WGLC requiring a revised ID, but there
> were no WGLC comments indicating that this document was not ready for
> publication. Editors, please prepare an updated revision.
> 
> The document will now be reviewed by me as the document shepherd with
> the intention of preparing a writeup for publication as PS.
> 
> Best wishes,
> Gorry
> (TSVWG Co-Chair)

____________________________________________________________________________________________________________
Ce message et ses pieces jointes peuvent contenir des informations confidentielles ou privilegiees et ne doivent donc
pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce message par erreur, veuillez le signaler
a l'expediteur et le detruire ainsi que les pieces jointes. Les messages electroniques etant susceptibles d'alteration,
Orange decline toute responsabilite si ce message a ete altere, deforme ou falsifie. Merci.

This message and its attachments may contain confidential or privileged information that may be protected by law;
they should not be distributed, used or copied without authorisation.
If you have received this email in error, please notify the sender and delete this message and its attachments.
As emails may be altered, Orange is not liable for messages that have been modified, changed or falsified.
Thank you.