Re: [MMUSIC] Éric Vyncke's No Objection on draft-ietf-mmusic-msrp-usage-data-channel-23: (with COMMENT)

["Eric Vyncke (evyncke)" <[e-mail]>]

Hello Christer,

Thank you for your quick reply. I sincerely believe that your suggestions will make the document better: so, go for it ! 😊

OTOH, I still read ‘SCTP streams’ in section 5.4 “Data Framing” in the -23 revision that is balloted. So, I am a little puzzled here... Again, COMMENTs are non blocking

Regards and thank you for your work

-éric

From: Christer Holmberg <[e-mail]>
Date: Monday, 3 August 2020 at 21:58
To: The IESG <[e-mail]>, Eric Vyncke <[e-mail]>
Cc: "[e-mail]" <[e-mail]>, "[e-mail]" <[e-mail]>, "[e-mail]" <[e-mail]>, Bo Burman <[e-mail]>
Subject: Re: Éric Vyncke's No Objection on draft-ietf-mmusic-msrp-usage-data-channel-23: (with COMMENT)

Hi,

Thank You for the review! Please see inline.

== COMMENTS ==

-- Section 1 --
>"Compared to WebSockets, which provide...", I found no references to back up
>all claims about WebRTC (e.g., nothing about "telemetry"). Adding some
>informative references would help the reader.

This is probably old text, because I can't remember having written it.

Also, I think the text is out of date, because we no longer need to tell people that browsers support WebRTC.

Perhaps we could remove the second part of the paragraph, on only keep the first part:

   "Compared to WebSockets, which provide a message passing protocol to

   applications with no direct access to TCP or TLS sockets, data

   channels provide a low latency transport, leverage NAT-aware

   connectivity and security features of WebRTC."
After all, this document does not define the data channel mechanism (it only defines a usage), so we don't need to go into details regarding the differences to other transport mechanisms.

---

-- Section 4.1 --
>Out of curiosity, what does "dc" stands for ? Data-channel ? While not
>required, a short explanation would be nice to the reader.

I suggest:

OLD:

   "This document extends the MSRP URI syntax [RFC4975] by defining the

   new transport parameter value "dc":"
NEW:

   "This document extends the MSRP URI syntax [RFC4975] by defining the

   new transport parameter value "dc" (an abbreviation of data channel):"
---


-- Section 4.8 --
>It is nice to have an example but using IPv4 in an example in 2020... humm....
>a little bit outdated ? ;-)

I will replace the IPv4 addresses with IPv6 addresses.

---

-- Section 5.4 --
>The rest of the document is about 'data channel' but this section uses 'SCTP
>stream'. AFAIK, they are the same in the WebRTC world but some consistent
>language would be better (as I am not a WebRTC expert, I can be wrong). Should
>SCTP be an informative reference?

Section 5.4 does not use 'SCTP stream'. Are you referring to Section 5.2?

Section 5.4 does use 'SCTP association'. But, we need to use that, because we are explaining that one needs to establish an SCTP association before a data channel can be established.

Regarding the usage of 'SCTP stream' in Section 5.2, I guess we could replace that with "data channel".

---

Regards,

Christer