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

[[e-mail]]

Dear Med,

Thank you for your comments, which we will be incorporating into a new version -15 shortly.  Your editorial comments in particular can be rectified quickly.

As for your comment (1), I personally agree, but that was the result of a lengthy discussion about moving the document to PS: https://mailarchive.ietf.org/arch/msg/tsvwg/yK0P2XuAEABfW_SeHfmDLNBjLhk/.
We are now a year later and perhaps views have changed, possibly also because MP-QUIC has evolved.

Gorry, what is your view here, as the document is now with you for write-up.


Br

Markus
> -----Original Message-----
> From: [e-mail]
> <[e-mail]>
> Sent: Donnerstag, 28. März 2024 15:19
> To: Gorry Fairhurst <[e-mail]>; [e-mail]
> Cc: [e-mail]
> Subject: RE: [tsvwg] WGLC concluded for draft-ietf-tsvwg-multipath-dccp as
> PS
> 
> 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%7C459ff
> 18746c34b
> >
> 661b8b08dc41c72d5a%7C90c7a20af34b40bfbc48b9253b6f5d20%7C0%7C
> 0%7C638457
> >
> 570918853685%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiL
> CJQIjoiV2luM
> >
> zIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C0%7C%7C%7C&sdata=jOwmVR3e
> RDhbPXHkA
> > 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.