Re: [MMUSIC] I-D Action: draft-ietf-mmusic-sctp-sdp-06.txt - Christer's initial comments

[Christian Groves <[e-mail]>]

Hello Christer,

I'm not assuming the use of webrtc-data channel. The issue would apply 
to any "app" being used multiple times in an SCTP association.

Are you suggesting any time that you want to use multiple instances of 
an "app" that you must use "webrtc-datachannel" even if there are no web 
browsers involved?

Regards, Christian

On 14/02/2014 5:56 PM, Christer Holmberg wrote:
> Hi Christian,
>
> A comment, based on your example. I don't think we would indicate "clue" in the sctpmap attribute. We would indicate "webrtc-datachannel", in order to be able to interwork with browsers. Then, on that webrtc-datachannel, we would run the CLUE protocol (which we would negotiate e.g. using the DCP, Richard's draft, or some other mechanism).
>
> Regards,
>
> Christer
>
> -----Original Message-----
> From: mmusic [mailto:[e-mail]] On Behalf Of Christian Groves
> Sent: 14. helmikuuta 2014 1:49
> To: [e-mail]
> Subject: Re: [MMUSIC] I-D Action: draft-ietf-mmusic-sctp-sdp-06.txt - Christer's initial comments
>
> Hello,
>
> Some further comments:
>
> Section 11.1 (Editorial) - 11.1 The first paragraph regarding 'sctpmap'
> attribute appears to be repeated.
>
> Section 4.1 (Technical): I see the draft has removed the using using "bfcp" and "t38" as values for the "App" field under one m-line. However that also removes any hint about multiple a=sctpmaps being used under one m-line. For example should there be one a=sctpmap per 'fmt' or could there be zero or more a=sctpmaps per 'fmt' in the m-line? If think this should be clarified.
>
> General: There was a discussion on the CLUE mailing list whether there could be multiple CLUE protocol instances per SCTP association. We couldn't identify a use case but couldn't rule it out either. I assume this would apply to other "apps" also.
> For example something like:
> m=application 54111 DTLS/SCTP 5000
> c=IN IP4 79.97.215.79
> a=sctpmap:5000 clue max-message-size=100000 streams=1
> a=sctpmap:5000 clue max-message-size=100000 streams=1
> a=sctpmap:5000 clue max-message-size=100000 streams=1 Do we need a "label" to uniquely identify a particular 'app' instance?
> i.e. Similar to the optional label that draft-ietf-rtcweb-data-protocol uses.
> e.g. a=sctpmap:5000 clue max-message-size=100000 streams=1 label1
> a=sctpmap:5000 clue max-message-size=100000 streams=1 label2
> a=sctpmap:5000 clue max-message-size=100000 streams=1 label3
>
> Regards, Christian
>
>
> On 14/02/2014 7:57 AM, Christer Holmberg wrote:
>> Hi,
>> I gave some comments off-line to Salvatore, which have been addressed
>> in the new version.
>> Some additional comments. I do realize some are pure editorial, but
>> rather to write then down in some notes I put them directly into the
>> e-mail J *Section 1:*
>> *------------*
>> *Q1**(EDITORIAL)**:*
>> The text says:
>> "Since
>> no-one so far has implemented SCTP over TLS, due to some serious
>> limitations described in [RFC6083], this document does not make use of
>> TLS over SCTP as described in RFC3436 [RFC3436]."
>> I suggest to simply say something like:
>> "As described in [RFC6083], there are limitations associated with
>> implementing SCTP over TLS. For that reason, SCTP over TLS is outside
>> the scope of this document."
>> *Q2**(EDITORIAL)**:*
>> The text says:
>> "Additionally, this document specifies the use of the 'setup' and
>> 'connection' SDP attributes to establish SCTP associations. These
>> attributes were defined in RFC4145 [RFC4145] for TCP. This document
>> discusses their use with SCTP."
>> I suggest to remove the last sentence, as it only repeats what is said
>> in the first sentence.
>> *Section 3:*
>> *------------*
>> *Q3 (EDITORIAL):*
>> The text says:
>> "This document defines three new values for the 'proto' field: 'SCTP',
>> 'SCTP/DTLS' and 'DTLS/SCTP'."
>> I would suggest to say:
>> "This document defines three new *protocol identifier* values for the
>> 'proto' field: 'SCTP', 'SCTP/DTLS' and 'DTLS/SCTP'."
>> .because, you use "protocol identifier" terminology later.
>> *Q4 (CLARIFICATION):*
>> The text says:
>> "An 'm' line that specifies 'SCTP' or 'SCTP/DTLS' or 'DTLS/SCTP' MUST
>> further qualify the application-layer protocol using an fmt
>> identifier."
>> I do understand what you are trying to say, but I think the "qualify"
>> word is a little confusing.
>> Maybe something like:
>> "An 'm' line that specifies 'SCTP' or 'SCTP/DTLS' or 'DTLS/SCTP' MUST
>> further include an fmt value that identifies the application-layer
>> protocol carried on top of the SCTP association."
>> *Section 4.1:*
>> *--------------*
>> *Q5 (TECHNICAL):*
>> The text says:
>> "For the payload type assignments the "a=sctpmap:"
>> attribute (see Section 5.1) SHOULD be used to map from a port number
>> to a media encoding name that identifies the payload format
>> transported by the association or the actual application protocol
>> running on top of it."
>> It is very difficult for me to parse this, and figure out the
>> semantics of the sctpmap attribute.
>> First, what do you mean by "media encoding name"?
>> Second, when you talk about "application protocol", I assume you refer
>> to the SCTP protocol?
>> Third, the text say SHOULD. When is it ok to not use the sctpmap
>> attribute?
>> *Section **5**:*
>> *------------*
>> *Q6 (EDITORIAL):*
>> I suggest to rename section 5 to "SDP sctpmap attribute", rename
>> section 5.1 to "General", and add a new section 5.2 named "ABNF".
>> *Q7 (TECHNICAL):*
>> The text says:
>> "The sctpmap MUST include the app parameter indicating the application
>> running on top of the association."
>> This is fine if the sctpmap attribute maps to an application. But,
>> what if the sctpmap attribute maps to a "media encoding" or "payload"?
>> *Q8 **(EDITORIAL):*
>> The text says:
>> "The sctpmap line should also contain the max-message-size parameter
>> indicating the maximum message size, in bytes, the endpoint is willing
>> to accept."
>> I suggest to replace "accept" with "receive on the associated SCTP
>> association".
>> *Q9 (EDITORIAL):*
>> The text says:
>> "The peer should assume that larger message will be rejected by the
>> endpoint, though it is up to the endpoint decide the appropriate
>> behaviour."
>> I suggest to either remove this paragraph, OR replace it with a
>> sentence saying that a peer must/should not send messages bigger than
>> the indicated max value.
>> *Q10 (CLARIFICATION):*
>> The text says:
>> "If the parameter is not present, the implementation should provide a
>> default, with a suggested value of 64K."
>> I don't understand "suggested". If the default value is 64K the text
>> should specify (rather than suggest) that.
>> The same comment applies to the stream parameter, described later in
>> the section.
>> *Q11 (CLARIFICATION):*
>> The text says:
>> "It may also provide the stream parameter to specify the initial
>> number of incoming streams to be supported by each side of the
>> association."
>> First, to be consistent with previous text, I suggest to replace "It
>> may also provide" with "The sctpmap line may also contain"
>> Second, I don't understand "incoming streams to be supported by each
>> side of the association". Doesn't each peer indicate the number of
>> streams it is willing to receive? Then, we can always recommend that
>> the peer indicates the same number of streams, if possible.
>> *Q12 (EDITORIAL):*
>> The text that follows the ABNF should be put into a separate "SDP
>> Offer/Answer Procedures" section.
>> *Section 7:*
>> *------------*
>> *Q13 (EDITORIAL):*
>> Please don't talk about re-INVITEs, or other SIP messages. Simply talk
>> about offers and answers.
>> *Q14 (EDITORIAL):*
>> The text says:
>> "It is worth to underline that when using SCTP on top of DTLS,.."
>> To have consistent terminology, please say "SCTP over DTLS".
>> That's all for now! :)
>> Regards,
>> Christer
>> -----Alkuperäinen viesti-----
>> Lähettäjä: mmusic [mailto:[e-mail]] Puolesta
>> [e-mail]
>> Lähetetty: 13. helmikuuta 2014 16:21
>> Vastaanottaja: [e-mail]
>> Kopio: [e-mail]
>> Aihe: [MMUSIC] I-D Action: draft-ietf-mmusic-sctp-sdp-06.txt A New
>> Internet-Draft is available from the on-line Internet-Drafts
>> directories.
>> This draft is a work item of the Multiparty Multimedia Session Control
>> Working Group of the IETF.
>> Title : Stream Control Transmission Protocol (SCTP)-Based Media
>> Transport in the Session Description Protocol (SDP) Authors :
>> Salvatore Loreto Gonzalo Camarillo Filename :
>> draft-ietf-mmusic-sctp-sdp-06.txt Pages : 14 Date : 2014-02-13
>> Abstract:
>> SCTP (Stream Control Transmission Protocol) is a transport protocol
>> used to establish associations between two endpoints. This document
>> describes how to express media transport over SCTP in SDP (Session
>> Description Protocol). This document defines the 'SCTP', 'SCTP/DTLS'
>> and 'DTLS/SCTP' protocol identifiers for SDP.
>> The IETF datatracker status page for this draft is:
>> https://datatracker.ietf.org/doc/draft-ietf-mmusic-sctp-sdp/
>> There's also a htmlized version available at:
>> http://tools.ietf.org/html/draft-ietf-mmusic-sctp-sdp-06
>> A diff from the previous version is available at:
>> http://www.ietf.org/rfcdiff?url2=draft-ietf-mmusic-sctp-sdp-06
>> Please note that it may take a couple of minutes from the time of
>> submission until the htmlized version and diff are available at
>> tools.ietf.org.
>> Internet-Drafts are also available by anonymous FTP at:
>> ftp://ftp.ietf.org/internet-drafts/
>> _______________________________________________
>> mmusic mailing list
>> [e-mail] <mailto:[e-mail]>
>> https://www.ietf.org/mailman/listinfo/mmusic
>>
>>
>> _______________________________________________
>> mmusic mailing list
>> [e-mail]
>> https://www.ietf.org/mailman/listinfo/mmusic
> _______________________________________________
> mmusic mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/mmusic
>