Subject: [MMUSIC] WGLC for draft-ietf-mmusic-sctp-sdp-14

From: Flemming Andreasen <[email-masked]>
Date: Tue, 10 Mar 2015 14:09:02 -0400

This is to announce a 2 week Working Group Last Call for

              draft-ietf-mmusic-sctp-sdp-14

as Proposed Standard. Please review and provide any comments you may 
have on the document by Tuesday, March 24, 2015. 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

Draft Info:

    SCTP (Stream Control Transmission Protocol) is a transport protocol
    used to establish associations between two endpoints.

    This specification describes how to describe SCTP associations using
    the Session Description Protocol (SDP), and defines the following new
    SDP Media Description protocol identifiers (proto values):'SCTP',
    'SCTP/DTLS', 'UDP/DTLS/SCTP' and 'TCP/DTLS/SCTP'.

    The specification also describes how to use the new proto values
    together with the SDP Offer/Answer mechanism in order to negotiate
    and establish SCTP associations, and how to indicate the SCTP
    application usage.

---

From: Paul Kyzivat <[email-masked]>
Date: Tue, 10 Mar 2015 15:32:16 -0400

I've had my say. I'm happy.

	Thanks,
	Paul

On 3/10/15 2:09 PM, Flemming Andreasen wrote:
> _______________________________________________
> mmusic mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/mmusic
>

---

From: Magnus Westerlund <[email-masked]>
Date: Fri, 13 Mar 2015 11:34:15 +0100

WG,

I have reviewed this draft and have some comments.

1. Section 1:
   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 SCTP
   on top of TLS.  Therefore, defining a mechanism to negotiate media
   streams transported using SCTP on top of TLS is outside the scope of
   this specification.

Isn't this all written backward. Shouldn't this paragraph talk about TLS
on top of SCTP? I also think you need to reference the actual
specification for TLS over SCTP, i.e RFC 3436. My impression is that
this paragraph should say 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 [RFC3436].  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.

2. Section 4.3:

   [RFC4566] defines that specifications defining new proto values must
   define the rules by which their media format (fmt) namespace is
   managed.  Use of an existing MIME subtype for the format is
   encouraged.  If no MIME subtype exists, it is recommended that a
   suitable one is registered through the IETF process [RFC6838]
   [RFC4289] by production of, or reference to, a standards-track RFC
   that defines the transport protocol for the format.

I get very confused by this paragraph, it looks by a quote from RFC4566
on something that applies on this format, however, I fail to find any
text in RFC4566 that relates to "Use of an existing MIME subtype for the
format is encouraged."

So is this a rule that applies for these protos? Considering how the fmt
string is defined, usage of MIME types are not give, and can also
collide with the created registrations.

So what is the intention with the paragraph?

3.  Section 4.4.2:

Indentation error for tcp-port

4. Section 4.4.2:

What is the definition of port and token?

Assuming that it is the SDP token, I think you need the lines:

token = <As defined in RFC4566>
port  = <As defined in RFC4566>

5. Section 5.1:

The attribute can be associated with an SDP media description (m-
   line) with a 'UDP/DTLS/SCTP' or a 'TCP/DTLS/SCTP' proto value, in
   which case the m- line port value indicates the port of the
   underlying transport-layer protocol (UDP or TCP), on which SCTP is
   carried, and the 'sctp-port' value indicates the SCTP port.

Shouldn't the "which" in "in which case the m- line port" be a "that",
as that part is necessary, while the next which can actually be removed
without changing the actual meaning of the sentence.

6. Section 6.2:

       max-message-size-attr =  "a=max-message-size:" max-message-size
       max-message-size      =  1*DIGIT

I have to wonder why max-message-size doesn't have an upper boundary in
the number of digits it can contain. What I can read out of the SCTP
specification, there are actually no upperbound for the SCTP messages.
But, I would think that we actually want parsers to have a chance of
saying no, there is an error here and refuse to parse further. I suggest
that max-message-size = 1*40DIGIT. That allows for messages which
requires more than 132 bits to be specified as an unsigned integer.

Otherwise, I will want to test your parsers by giving them an SDP which
in this field contains a base64 encoded binary linux distribution. If
they can't at least successfully parse it they are not spec compliant ;-).

7. Section 9.3.3:

   If the underlying transport protocol is modified, the endpoints MUST
   establish a new DTLS connection.  In such case the 'active/passive'
   status of the endpoints will again be determined following the
   procedures in [RFC4145], and the new status will be used to determine
   the (D)TLS roles of the endpoints associated with the new DTLS
   connection.

I don't understand what "modified" in the above paragraph actually
included.

So, I would assume switching from UDP/DTLS/SCTP to TCP/DTLS/SCTP is
modified.

I also can believe that changing the port or address for the UDP/TCP is
such a modification.

But, what about updating ICE candidates?
What happens if new candidate pairs are promoted?

8. Section 10.2:

   o  MUST, if the m- line proto value is 'SCTP/DTLS', 'UDP/DTLS/SCTP'
      or 'TCP/DTLS/SCTP', associate an SDP setup attribute, with an
      'actpass' value, with the m- line (see Section 9.3);

Why is "actpass" required? There is nothing in Section 9.3 that causes a
situation that requires the offerer to use actpass.

9. section 10.2 and Section 10.3:

What about 'holdconn'. It must at least be possible to give in an
answer. Per RFC 4145 it appears legal to offer also.

10. Section 13.1:

You must fix the indentation issues in the examples.

11. Section 14.:

   This specification does not introduce new security considerations in
   addition to those defined in the specifications listed above.

I don't believe this. You are specifying two protocol combinations that
aren't specified in any of the referenced drafts: "UDP/DTLS/SCTP" and
"TCP/DTLS/SCTP". At a minimum this requires consideration of any
security issues in [I-D.ietf-tsvwg-sctp-dtls-encaps].

I also would prefer if you actually had done the work to summarize all
the more significant issues for the combinations that this document
specifies.

Cheers

Magnus Westerlund

-- 

Magnus Westerlund

----------------------------------------------------------------------
Services, Media and Network features, Ericsson Research EAB/TXM
----------------------------------------------------------------------
Ericsson AB                 | Phone  +46 10 7148287
Färögatan 6                 | Mobile +46 73 0949079
SE-164 80 Stockholm, Sweden | mailto: [email-masked]
----------------------------------------------------------------------