Subject: [MMUSIC] Draft new version: SCTP-SDP-13

From: Christer Holmberg <[email-masked]>
Date: Wed, 4 Mar 2015 08:20:34 +0000

Hi,

I've submitted a new version of the SCTP-SDP draft.

The changes are mostly based on the review comments provided by the chairs, the DTLS comments provided by Roman, and the SDP attribute mux rule comments provided by Paul.

The authors believe the draft is ready for WGLC. From an editorial perspective we believe the draft is in good shape, and there are currently no technical open issues.

Also, it would be good if people took a look at the draft before Dallas, in case someone finds issues that we would need f2f time for in order to solve.

Thanks!

Regards,

Christer

---

From: Paul Kyzivat <[email-masked]>
Date: Wed, 04 Mar 2015 16:48:20 -0500

Christer,

The changes generally seem good. I have a couple more comments on the 
new version:

* Section 5.2:

            Applications MUST NOT use well-known port values, or port
            values that have been registered for specific purposes.

This seems to be boiler plate copied from other places. I don't think it 
makes sense here, for two reasons:

- it is ok for an application to use a port registered for a specific 
purpose if that application is also for that purpose. Similarly for well 
known ports. (This is also true when SCTP is the native transport.

- when the sctp is tunneled over UDP/TCP, the address/port of the 
UDP/TCP connection establishes a new namespace inside which the SCPT 
port is understood. Using well known or registered ports in this context 
is not conflicting with anything, and so should not be forbidden.

* Section 10.4:

    o  MUST, if the offerer is the 'active' endpoint, if the m- line
       proto value is 'TCP/DTLS/SCTP', and if a TCP connection used to
       carry the SCTP association has not yet been established (or if an
       existing TCP connection is to be re-established), initiate the
       establishing of the TCP connection;

    o  MUST, if an SCTP association associated with the m- line has not
       yet been established (or if an existing SCTP association is to be
       re-established), initiate the establishing of the SCTP
       association; and

    o  MUST, if the offerer is the 'active' endpoint, and if a DTLS
       connection associated with the m- line is to be established (or if
       an existing DTLS connection is to be re-established), initiate the
       establishing of the DTLS connection (by sending a ClientHello
       message).

    o  NOTE: If the m- line proto value is 'UDP/DTLS/SCTP' or 'TCP/DTLS/
       SCTP', the two actions above are performed in switch order, as the
       underlying DTLS connection needs to be established before the SCTP
       association can be established.

I don't understand what is meant by "switch order" above. Trying to 
figure it out, I infer:

- the first three of the above steps (assume they are numbered 1,2,3)
   must be performed in a well defined order.

- for proto SCTP only 2 is performed

- for proto 'SCTP/DTLS' the order is 2,3

- for protos 'UDP/DTLS/SCTP' and 'TCP/DTLS/SCTP' the order is 1,3,2

*If* my interpretation is what you intended, then maybe the text is ok 
as written. But I think it could be clarified, along the lines I just used.

	Thanks,
	Paul

On 3/4/15 3:20 AM, Christer Holmberg wrote:
> Hi,
>
> I’ve submitted a new version of the SCTP-SDP draft.
>
> The changes are mostly based on the review comments provided by the
> chairs, the DTLS comments provided by Roman, and the SDP attribute mux
> rule comments provided by Paul.
>
> The authors believe the draft is ready for WGLC. From an editorial
> perspective we believe the draft is in good shape, and there are
> currently no technical open issues.
>
> Also, it would be good if people took a look at the draft before Dallas,
> in case someone finds issues that we would need f2f time for in order to
> solve.
>
> Thanks!
>
> Regards,
>
> Christer
>
>
>
> _______________________________________________
> mmusic mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/mmusic
>

---

From: Christer Holmberg <[email-masked]>
Date: Thu, 5 Mar 2015 09:20:19 +0000

Hi Paul,

* Section 5.2:

> This seems to be boiler plate copied from other places. I don't think it makes sense here, for two reasons:
>
> - it is ok for an application to use a port registered for a specific purpose if that application is also for that purpose. 
> Similarly for well known ports. (This is also true when SCTP is the native transport.

True.

>- when the sctp is tunneled over UDP/TCP, the address/port of the UDP/TCP connection establishes a new namespace >inside which the SCPT port is understood. Using well known or registered ports in this context is not conflicting with >anything, and so should not be forbidden.

True.

So, my suggestion is to simply remove the statement.

-------------

* Section 10.4:

> I don't understand what is meant by "switch order" above. Trying to figure it out, I infer:
>
> *If* my interpretation is what you intended, then maybe the text is ok as 
> written. But I think it could be clarified, along the lines I just used.

Would the following be more clear to not talk about "switch order", and simply say:

    o  NOTE: If the m- line proto value is 'UDP/DTLS/SCTP' or 'TCP/DTLS/
       SCTP', the underlying DTLS connection needs to be established before
       the SCTP association can be established. 

Or, you want MORE text?

Regards,

Christer

On 3/4/15 3:20 AM, Christer Holmberg wrote:
> Also, it would be good if people took a look at the draft before 
> Dallas, in case someone finds issues that we would need f2f time for 
> in order to solve.
>
> Thanks!
>
> Regards,
>
> Christer
>
>
>

---

From: Paul Kyzivat <[email-masked]>
Date: Thu, 05 Mar 2015 09:33:40 -0500

> So, my suggestion is to simply remove the statement.

Agree.

Yes, that would work for me.

	Thanks,
	Paul