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

From: Éric Vyncke via Datatracker <[email-masked]>
Date: Mon, 03 Aug 2020 08:59:15 -0700

Éric Vyncke has entered the following ballot position for
draft-ietf-mmusic-msrp-usage-data-channel-23: No Objection

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)

Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html
for more information about IESG DISCUSS and COMMENT positions.

The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-mmusic-msrp-usage-data-channel/

----------------------------------------------------------------------
COMMENT:
----------------------------------------------------------------------

Thank you for the work put into this document esp. for the new authors as it
appears that this document had a rough ride.

Please find below a couple of non-blocking COMMENTs.

I hope that this helps to improve the document,

Regards,

-éric

== 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.

-- 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.

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

-- 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?

---

From: Christer Holmberg <[email-masked]>
Date: Mon, 3 Aug 2020 19:57:27 +0000

Hi,

Thank You for the review! Please see inline.

== COMMENTS ==

-- Section 1 --

>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 --

>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 --

>a little bit outdated ? ;-)

I will replace the IPv4 addresses with IPv6 addresses.

---

-- Section 5.4 --

>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

---

From: "Eric Vyncke (evyncke)" <[email-masked]>
Date: Mon, 3 Aug 2020 20:22:39 +0000

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 <[email-masked]>
Date: Monday, 3 August 2020 at 21:58
To: The IESG <[email-masked]>, Eric Vyncke <[email-masked]>
Cc: "[email-masked]" <[email-masked]>, "[email-masked]" <[email-masked]>, "[email-masked]" <[email-masked]>, Bo Burman <[email-masked]>
Subject: Re: Éric Vyncke's No Objection on draft-ietf-mmusic-msrp-usage-data-channel-23: (with COMMENT)

Hi,

== COMMENTS ==

-- Section 1 --

---

-- Section 4.1 --

I suggest:

OLD:

-- Section 4.8 --

---

-- Section 5.4 --

---

Regards,

Christer

---

From: Christer Holmberg <[email-masked]>
Date: Tue, 4 Aug 2020 18:09:04 +0000

Hi,

>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...

Sorry, my mistake :) I will do the change in Section 5.4.

BTW, "SCTP stream" is used also in Section 4.5. But, that should not be changed, because the text refers to the SCTP stream identifier.

>Again, COMMENTs are non blocking

I know, but you made good comments :)

Regards,

Christer

Hi,

== COMMENTS ==

-- Section 1 --

---

-- Section 4.1 --

I suggest:

OLD:

NEW:

---

-- Section 4.8 --

---

-- Section 5.4 --

---

Regards,

Christer