Subject: Re: [MMUSIC] WGLC on draft-ietf-mmusic-sctp-sdp-18 - Juergen's comments

From: Christer Holmberg <[email-masked]>
Date: Mon, 17 Oct 2016 18:20:52 +0000

Hi Juergen,

Thanks for your comments! Please see inline.

>* Section 3, terminology: The "SCTP transport address" is mentioned. Would this still be 
> needed in the draft, given that SCTP-over-IP is now out of scope?

I think we can remove it.

>* Sec 4.1: The paragraph right after the "m=" line mentions the 'UDP' and 'TCP' proto values. 
>As far as I see the UDP related proto value is IANA registered only with lower case letters, 'udp'. 
>Would therefore propose to replace 'UDP' with 'udp'.

Note that draft-ietf-bfcpbis-rfc4583bis-16.txt defines similar values for BFCP, with upper case letters.

I'd prefer to keep the upper case. It looks better that way.

> * Sec 5.1: The last sentence specifies: "Usage of the SDP 'sctp-port' attribute with other proto values
> is not specified, and MUST be discarded if received." On the other hand, section 6.1 (within the note) 
> mentions for the "max-message-size" attribute that "Usage of the attribute with other proto values 
> needs to be defined in a separate specification." In section 5.1, should this draft actually require the 
> "sctp-port" attribute being discarded if associated with m-line with proto values other than 
> UDP/DTLS/SCTP or TCP/DTLS/SCTP? As per my understanding it would actually be up to the (other) 
> document(s), which specify such other proto values. (Especially as SCTP-over-IP is not within the scope anymore.)

I guess I could replace the text in section 5.1 with a similar note.

>* Sec 6.1: This section introduces the "max-message-size" attribute and specifies: "The attribute can be associated
> with an m- line to indicate the maximum message size (indicated in bytes) that an SCTP endpoint is willing to receive
> on the SCTP association associated with the m-line."
> Would propose to explicitly add "... to indicate the maximum SCTP user message size ...". Admittedly, it seems pretty 
> clear in the given context that "message size" refers to the "SCTP user message size". However, explicitly adding "SCTP user" 
> might help to unambiguously differentiate this message size  from e.g. the maximum DTLS payload size, or from application 
> level protocol message sizes (like e.g. MSRP message sizes or MSRP message chunk sizes). Similarly, Would propose to extend
> the first sentence of the second paragraph like "... must assume that larger SCTP user messages ...".

I'll modify as suggested, by adding "user".

> * Sections 9 and 10: I am still struggling with the usages of "re-establishment" / "re-establish" / "re-established".
>These terms are used several times in sections 9 and 10.

While it may not be related to your issue, please note the pull request which modifies sections 9 and 10 quite a bit.

>For me in (almost) all cases these usages seem to refer to a situation, where a _new_ SCTP association
> (or DTLS association or TCP connection) is (to be) established either _after_ a previous corresponding 
> association or connection had been closed, or which is meant to replace a previously established and 
> still existing association or connection. In a way I am quite generally unsure what exactly the notion 
> of "re-establishment" means in such situations. For me a "re-establishment" e.g. of an SCTP association 
> would be a concept where an SCTP association is established, where it then fails, and where it is then 
> established again with the same transport address (or here SCTP port) values. However, even in this 
> case, strictly speaking, a new SCTP association is actually established, which replaces the old one. 
> But at least in case where new transport protocol parameters (like new SCTP ports) are used, I cannot 
> really think of a "re-establishment". For me this would always be an "establishment of a new" association.
> Given that I'd actually like to propose avoiding the term "re-establishment" (and its various grammatical 
> derivatives) as much a possible. 

I hear what you are saying, and I'll see what I can do.

>* Sec 15.3: This creates the new IANA registry of the "fmt" values for the UDP/DTLS/SCTP and TCP/DTLS/SCTP proto 
> values. And it introduces the "fmt" value "webrtc-datachannel". In the table the reference to draft-ietf-rtcweb-data-protocol 
> is given. But that draft doesn't introduce any SDP information elements, especially not this "fmt" value. As per my 
> understanding the present draft-ietf-mmusic-sctp-sdp itself introduces the "fmt" value "webrtc-datachannel". Would 
> therefore propose to replace "draft-ietf-rtcweb-data-protocol" with "draft-ietf-mmusic-sctp-sdp".

I hear what you are saying.

But, I think we somewhere need to have a reference to draft-ietf-rtcweb-data-protocol, because otherwise readers have no clue what the value is used for.

Regards,

Christer

---

From: Juergen Stoetzer-Bradler <[email-masked]>
Date: Tue, 18 Oct 2016 10:40:44 +0200

Hi Christer,

Thanks for your feedback.
I've added some additional remarks below.

Best regards,
Juergen

> I'd prefer to keep the upper case. It looks better that way.
[Juergen] Ok. I see your point.

> I hear what you are saying, and I'll see what I can do.
[Juergen] Just had a look at sections 9 and 10 of your pull request. The changes look fine to me.
Regarding the usage of "re-establishment", I am not native English speaker. Thus I realize that I 
better be careful here.
It is just that this term so far for me has always been associated with the concept of "restoration 
of something or some state, which previously had already been there and which then had vanished at 
some point in the past".

> But, I think we somewhere need to have a reference to draft-ietf-rtcweb-data-protocol, because otherwise readers have no clue what the value is used for.
[Juergen] I see your point and quite agree that draft-ietf-rtcweb-data-protocol should also be 
referenced. Would it be acceptable to reference both drafts?
(draft-ietf-rtcweb-data-protocol defining the protocol stack and procedures to be used on the media 
plane and "webrtc-datachannel" being the associated SDP <fmt> value to be used in related SDP 
m-lines as introduced in draft-ietf-mmusic-sctp-sdp.)

---

From: Christer Holmberg <[email-masked]>
Date: Tue, 18 Oct 2016 09:19:08 +0000

Hi,

…

[Juergen] I see your point and quite agree that draft-ietf-rtcweb-data-protocol should also be referenced. Would it be acceptable to reference both drafts?
(draft-ietf-rtcweb-data-protocol defining the protocol stack and procedures to be used on the media plane and "webrtc-datachannel" being the associated SDP <fmt> value to be used in related SDP m-lines as introduced in draft-ietf-mmusic-sctp-sdp.)

In the pull request both drafts are now referenced.

Regards,

Christer

---

From: Juergen Stoetzer-Bradler <[email-masked]>
Date: Tue, 18 Oct 2016 11:24:35 +0200

Hi Christer,

Thanks! The updates in your today's pull request look all good to me.

Best regards,
Juergen

On 18.10.2016 11:19, Christer Holmberg wrote:
> (draft-ietf-rtcweb-data-protocol defining the protocol stack and procedures to be used on the 
> media plane and "webrtc-datachannel" being the associated SDP <fmt> value to be used in related 
> SDP m-lines as introduced in draft-ietf-mmusic-sctp-sdp.)
>
>