Subject: Re: [MMUSIC] Draft new version: draft-ietf-mmusic-sctp-sdp-08

From: Paul Kyzivat <[email-masked]>
Date: Mon, 01 Dec 2014 17:05:51 -0500

Christer,

Here are some comments on the new version:

Section 4.3:

Using MIME subtypes on the m-line doesn't really work well. The value 
doesn't really define a data format - it defines a discipline for 
choosing and using stream ids, and possibly a format for each one. I 
think that all of the first paragraph should be deleted, with the 
exception of the first sentence.

Section 5.1:

IMO 5000 is a bad choice for the default port value. It falls in the 
middle of the registered port list. It isn't currently registered (I 
don't know why) but it potentially could. I suggest that a number 
outside of the registered port range (>49151) would be safest. To avoid 
being arbitrary, I suggest 65535 - the largest possible 16 bit number.

Section 6.2:

I don't understand why sctpmap-attr is defined, since it isn't 
referenced anywhere. I think it is a holdover from when there was an 
sctpmap attribute.

It seems that what is being done here is to define the syntax of a=fmtp 
for all fmt values that might be used with sctp. I don't think that is 
kosher. I think fmtp needs to be defined for webrtc-datachannel, and 
again for each other application-usage that wants to use it.

It is unpleasant to expect all application-usages to do this. But the 
alternative is to go back to defining a special attribute for 
max-message-size. Perhaps:

      Attribute name: sctp-attr
      Attribute value: sctp-attr-value
      Attribute Syntax:

      sctp-attr-value = association-usage [max-message-size]
      max-message-size  =  "max-message-size" EQUALS 1*DIGIT

Section 8:

I think something probably needs to be said about 
sendonly/recvonly/inactive. I'm not sure what. Maybe they shouldn't be 
used at all. Or maybe they can make some sort of sense.

Section 9:

The NOTE seems inadequate. If SCTP is being used in an environment that 
does gating based on SDP, then multihoming probably won't work. None of 
the negotiated alternative addresses will get their gates opened. So 
maybe more needs to be said about this.

Section 10.1:

The last paragraph about NATs references RFC6951. Wouldn't it be clearer 
if it simply referenced DTLS/SCTP defined in this draft?

Section 10.2:

This isn't quite true is it? ICE is defined to work over DTLS/SCTP. 
While the emphasis is on those cases where the SCTP is bundled with 
SRTP, it should work just fine without bundle.

	Thanks,
	Paul

On 11/28/14 9:07 AM, Christer Holmberg wrote:
> Hi,
>
> I’ve submitted a new version of the SCTP-SDP draft. There has been quite
> big editorial changes from the previous version. New stuff, including
> the SDP Offer/Answer procedures, have been added.
>
> I have yet NOT changed the proto values (e.g ‘DTLS/SCTP’ ->
> ‘UDP/DTLS/SCTP’). In Honolulu there was a generic discussion regarding
> that, whether to use “DTLS” or “TLS” etc, and I’d like to see some
> documented outcome regarding that before changing.
>
> There are currently two open issue (of which one is related to the proto
> values) documented in the draft.
>
> Regards,
>
> Christer
>
>
>
> _______________________________________________
> mmusic mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/mmusic
>