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

[Gorry Fairhurst <[e-mail]>]

On 28/03/2024 14:36, [e-mail] wrote:
> 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.
Med, this was very helpful, thanks.
>
> 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.

+1 with this being something that was discussed as we moved to PS.  It's 
a two part statement, about current status and about the implications of 
changes (if any) proposed for example in QUIC.

Markus: I am content with the other improvements, and if you as editors 
can include these, a new rev can be made before  our AD reviews - that 
might avoid these points re-appearing.

Gorry

>
> 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>.
+ good note, please replace this with a reference to RFC 9293.
>>
>> 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.