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

From: Christer Holmberg <[email-masked]>
Date: Sat, 15 Oct 2016 21:18:33 +0000

Hi Paul,

Thanks for your review! Please see inline.

* Section 1:

> The following is present twice:
>
>    The Stream Control Transmission Protocol (SCTP) [RFC4960] is a
>    transport protocol used to establish associations between two
>    endpoints.
>
> I don't understand the point of including the following:
>
>    NOTE: TLS is designed to run on top of a byte-stream oriented
>    transport protocol providing a reliable, in-sequence delivery like
>    TCP.  [RFC6083] presents serious limitations with transporting TLS on
>    top of SCTP.  Therefore, defining a mechanism to negotiate media
>    streams transported using TLS on top of SCTP, i.e., 'SCTP/TLS', is
>    outside the scope of this specification.  In addition, defining a
>    mechanism to negotiate non-protected SCTP associations is also
>    outside the scope of this specification.
>
> This document doesn't discuss running *anything* in particular over SCTP, so why single out TLS over SCTP? 

The text seems to be a leftover from when the draft defined the O/A procedures DTLS-over-SCTP. I will remove it (except for the last sentence - see more below).

> There is something similar that would make sense to mention: that running SCTP over TCP presents serious limitation, since
> it forces ordering and reliability even on SCTP streams that don't want that. So it would be good to mention that TCP/DTLS/SCTP 
> is only intended as a fallback for use in situations where UDP is blocked.

I'll think of some text.

>OTOH, the following sentence:
>
>  In addition, defining a mechanism to negotiate non-protected SCTP associations is also
>    outside the scope of this specification.
>
> Is worth saying, though it needs rewording after removing the rest.

I'll think of something.

------

* Section 4.3:

>    NOTE: A mechanism on how to describe, and manage, individual SCTP
>    streams within an SCTP association, is outside the scope of this
>    specification.
>
> I think it would be helpful to make an informational reference to draft-ietf-mmusic-data-channel-sdpneg, since that is well along toward completion.

I can do that.

------

* Section 4.4:

> IMO it is very unwise to restate the syntax of the m- line here. That is defined in 4566/4566bis, and this doesn't change that.
>
> Instead, I think this section should restrict itself to defining the values that may be used for the fields <media> <port> <proto> <fmt> defined in 4566. In particular:
>
> <media>: "application"
>
> <proto>: "UDP/DTLS/SCTP" or "TCP/DTLS/SCTP"
>
> <port>: UDP port number (for "UDP/DTLS/SCTP"), or
>         TCP port number (for ""UDP/DTLS/SCTP")
>
> <fmt>: a string denoting the association-usage, limited to the syntax
>       of a 'token' as defined in RFC4566.

Will do as suggested.

------

* Section 5.2:

> Rather than restate the general syntax of an attribute, please just define the parts that are unique to this attribute, in the style introduced in RFC4566bis. E.g.,
>
>    Name: sctp-port
>
>    Value: sctp-port-value
>
>    Usage Level: media
>
>    Charset Dependent: no
>
>    Mux Category: SPECIAL
>
>    Syntax:
>
>          sctp-port-value = 1*5<DIGIT defined in RFC4566>
>
>          The SCTP port range is between 0 and 65535 (both included).
>          Leading zeroes MUST NOT be used.
>
>    Example:
>
>          a=sctp-port:5000

Will do as suggested.

------

* Section 5.3:

> The qualification in the first paragraph is now redundant since the draft is now so qualified.

Just to verify that I understood the comment,  are you saying the first paragraph can be removed?

------

* Section 6.2:

> Rather than restate the general syntax of an attribute, please just define the parts that are unique to this attribute, in the style introduced in RFC4566bis. E.g.,
>
>    Name: max-message-size
>
>    Value: max-message-size-value
>
>    Usage Level: media
>
>    Charset Dependent: no
>
>    Mux Category: SPECIAL
>
>    Syntax:
>
>          max-message-size-value = 1*40<DIGIT defined in RFC4566>
>          *** Did you really want *40* here? ***

I don't remember where the number came from.

Any suggestion would be a reasonable number? Do we need to set a limit? As far as I remember, the standard does not define a max size.

>          Leading zeroes MUST NOT be used.
>
>    Example:
>
>          a=max-message-size:100000

Will do as suggested.

------

* Section 6.3:

> See comments on 5.3.

See reply above.

------

* Section 9.1:

> The following is redundant and can be removed: "In case of UDP/DTLS/SCTP and TCP/DTLS/SCTP".

Correct. I will remove it.

> Using "association/connection" invites confusion. Does the "/" mean OR?
>
> I suggest:
>
>    The SCTP association, DTLS association and TCP connection are
>    managed independently of each other.  Each can be re-established
>    without impacting others.

Looks good. I'll change as suggested.

------

* Section 9.2:

> I suggest s/discarded/ignored/

I'll change as suggested.

------

* Section 9.3:

> After reading this I remain confused about what triggers re-establishment. I *think* it is intended that this only be triggered 
> by an O/A where one side or the other has changed the port value. I'd like to see this stated more explicitly.

I'll take a look.

> The following:
>
>    As both SCTP endpoints take the 'active' role, this specification
>    does not define usage of the SDP 'setup' attribute [RFC4145] for
>    SCTP.
>
> may be confusing because 'setup' is used for the m-line. I suggest:
>
>    As both SCTP endpoints take the 'active' role, the SDP 'setup'
>    attribute [RFC4145] does not apply to SCTP association
>    establishment. However the 'setup' attribute does apply to
>    establishment of underlying DTLS associations and TCP connections.
>    (See below.)
>
> A similar change is appropriate for the 'connection' attribute.

I'll think of some text.

> The text "NOTE: In case of SCTP-over-DTLS" is redundant and can be removed.

Ok.

> The following wording is confusing (it seems circular):
>
>    When such SCTP association is re-established the
>    SCTP endpoints MUST use the procedures in this section for
>    establishing an SCTP association.
>
> I think this would be better stated:
>
>    The procedures in this section MUST be followed to re-establish the
>    SCTP association. This requires a new offer/answer exchange.

Ok.

------

* Section 10.2:

> Some offerers may not be capable of using 'actpass' because they aren't able to receive incoming connection 
> requests. While this might be resolved by using STUN or TURN I don't think this draft should assume that those 
> are required. I see no particular reason to prevent use of "active" or "passive", though it might be good to encourage 
> use of "actpass" when possible.

I agree. I'll change as suggested. 

------

* Section 10.3:

>    Once the answerer has sent the answer the answerer MUST, if an SCTP
>    association has yet not been established, or if an existing SCTP
>    association is to be re-established, initiate the establishment of
>    the SCTP association.
>
>    The answerer follows the procedures in [I-D.ietf-mmusic-dtls-sdp]
>    regarding the establishment/re-establishment of the DTLS association.
>
>    In the case of TCP/DTLS/SCTP, the answerer follows the procedures in
>    [RFC4145] regarding the establishment/re-establishment of the TCP
>    connection association.
>
> I think the order of presentation here is backward. It needs to be carried out bottom 
> to top, so I propose the order of these paragraphs be flipped. (Some wording tweaks 
> will also be required to handle the transitions properly.)

I'll look at it.

------

* Section 10.4:

>Again the ordering seems wrong.

I'll look at it.

------

Thanks!

Regards,

Christer

---

From: Christer Holmberg <[email-masked]>
Date: Sun, 16 Oct 2016 13:55:59 +0000

Hi,

I've created a pull request for the WGLC comments. The current changes are based on Paul's WGLC comments.

https://github.com/cdh4u/draft-sctp-sdp/pull/7

Regards,

Christer

-----Original Message-----
From: mmusic [mailto:[email-masked]] On Behalf Of Christer Holmberg
Sent: 16 October 2016 00:19
To: Paul Kyzivat <[email-masked]>; [email-masked]
Subject: Re: [MMUSIC] WGLC on draft-ietf-mmusic-sctp-sdp-18 - Paul's review

Hi Paul,

> There is something similar that would make sense to mention: that 
> running SCTP over TCP presents serious limitation, since it forces 
> ordering and reliability even on SCTP streams that don't want that. So it would be good to mention that TCP/DTLS/SCTP is only intended as a fallback for use in situations where UDP is blocked.

I'll think of some text.

I'll think of something.

------

I can do that.

------

Will do as suggested.

------

* Section 5.2:

> Rather than restate the general syntax of an attribute, please just 
> define the parts that are unique to this attribute, in the style 
> introduced in RFC4566bis. E.g.,
>
>    Name: sctp-port
>
>    Value: sctp-port-value
>
>    Usage Level: media
>
>    Charset Dependent: no
>
>    Mux Category: SPECIAL
>
>    Syntax:
>

Will do as suggested.

------

------

* Section 6.2:

> Rather than restate the general syntax of an attribute, please just 
> define the parts that are unique to this attribute, in the style 
> introduced in RFC4566bis. E.g.,
>
>    Name: max-message-size
>

Will do as suggested.

------

See reply above.

------

------

------

* Section 9.3:

> After reading this I remain confused about what triggers 
> re-establishment. I *think* it is intended that this only be triggered by an O/A where one side or the other has changed the port value. I'd like to see this stated more explicitly.

I'll take a look.

I'll think of some text.

Ok.

Ok.

------

* Section 10.2:

> Some offerers may not be capable of using 'actpass' because they 
> aren't able to receive incoming connection requests. While this might 
> be resolved by using STUN or TURN I don't think this draft should 
> assume that those are required. I see no particular reason to prevent use of "active" or "passive", though it might be good to encourage use of "actpass" when possible.

------

* Section 10.3:

> I think the order of presentation here is backward. It needs to be 
> carried out bottom to top, so I propose the order of these paragraphs 
> be flipped. (Some wording tweaks will also be required to handle the 
> transitions properly.)

I'll look at it.

------

I'll look at it.

------

Thanks!

Regards,

Christer

_______________________________________________
mmusic mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/mmusic

---

From: Paul Kyzivat <[email-masked]>
Date: Mon, 17 Oct 2016 13:04:18 -0400

Sounds good. You had one question:

> Any suggestion would be a reasonable number? Do we need to set a limit? As far as I remember, the standard does not define a max size.

I was thinking that this value is negotiable in DCEP, and if so that 
would have a field size that would limit this. But I can't find that in 
DCEP. So I guess it probably is fundamentally an SCTP issue. Somebody 
must know.

(I see that you went with simply '1*' in your update. That works 
syntactically, but I think it is worthwhile to resolve what the range of 
values is.

	Thanks,
	Paul

---

From: Christer Holmberg <[email-masked]>
Date: Mon, 17 Oct 2016 17:27:30 +0000

Hi,

...

> I was thinking that this value is negotiable in DCEP, and if so that would have a field size that would limit this. But
> I can't find that in DCEP. So I guess it probably is fundamentally an SCTP issue. Somebody must know.
>
> (I see that you went with simply '1*' in your update. That works syntactically, but I think it is worthwhile to resolve what the range of values is.

I was googling around a little, and as far as I know the SCTP standard does not define a max size. There may of course be other factors that limit the max size - which is why we define a way to indicate it to begin with :)

Regards,

Christer