Subject: [MMUSIC] WGLC on draft-ietf-mmusic-sctp-sdp-18

From: Flemming Andreasen <[email-masked]>
Date: Tue, 11 Oct 2016 14:53:04 -0400

Greetings MMUSIC

This is to announce a 2 week WGLC on the draft:

     https://www.ietf.org/id/draft-ietf-mmusic-sctp-sdp-18.txt

as Proposed Standard. Please review and provide any comments you may 
have on the document by Tuesday, October 25, 2016. Comments should be 
sent to the document authors and the MMUSIC WG list. If you review the 
document but do not have any comments, please send a note to that effect 
as well.

Thanks

-- Flemming (MMUSIC co-chair)

---

From: Barry Dingle <[email-masked]>
Date: Wed, 12 Oct 2016 09:04:43 +1100

Small editorial -

The second paragraph in the Introduction section is entirely repeated in
the start of the third paragraph.

Barry Dingle
Fixed - 03-9725-3937    Mob - 041-911-7578
Melbourne, Australia

On 12 October 2016 at 05:53, Flemming Andreasen <[email-masked]> wrote:

> as Proposed Standard. Please review and provide any comments you may have
> on the document by Tuesday, October 25, 2016. Comments should be sent to
> the document authors and the MMUSIC WG list. If you review the document but
> do not have any comments, please send a note to that effect as well.
>
> Thanks
>
> _______________________________________________
> mmusic mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/mmusic
>

---

From: Christer Holmberg <[email-masked]>
Date: Wed, 12 Oct 2016 06:01:29 +0000

Hi Barry,

>Small editorial -
>
>The second paragraph in the Introduction section is entirely repeated in the start of the third paragraph.

I’ll remove the second paragraph.

Thanks!

Regards,

Christer

On 12 October 2016 at 05:53, Flemming Andreasen <[email-masked]<mailto:[email-masked]>> wrote:
Greetings MMUSIC

as Proposed Standard. Please review and provide any comments you may have on the document by Tuesday, October 25, 2016. Comments should be sent to the document authors and the MMUSIC WG list. If you review the document but do not have any comments, please send a note to that effect as well.

Thanks

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

---

From: Paul Kyzivat <[email-masked]>
Date: Fri, 14 Oct 2016 15:13:02 -0400

I tried to do a reasonably thorough review of this document. I did find 
a bunch of stuff that needs some work. Most of it is editorial.

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

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.

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

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

* 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

* Section 5.3:

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

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

          Leading zeroes MUST NOT be used.

    Example:

          a=max-message-size:100000

* Section 6.3:

See comments on 5.3.

* Section 9.1:

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

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.

* Section 9.2:

I suggest s/discarded/ignored/

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

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.

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

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.

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

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

* Section 10.4:

Again the ordering seems wrong.

	Thanks,
	Paul

---

From: Juergen Stoetzer-Bradler <[email-masked]>
Date: Mon, 17 Oct 2016 16:34:32 +0200

Hello,

Have re-read the whole text and would have some comments as follows.

Thanks,
Juergen

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

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

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

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

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

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

On 11.10.2016 20:53, Flemming Andreasen wrote:
> as Proposed Standard. Please review and provide any comments you may have on the document by 
> Tuesday, October 25, 2016. Comments should be sent to the document authors and the MMUSIC WG list. 
> If you review the document but do not have any comments, please send a note to that effect as well.
>
> Thanks
>