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

["DRAGE, Keith (Keith)" <[e-mail]>]

Would agree to changing webrtc-data channel to something more generic.

Keith

> -----Original Message-----
> From: mmusic [mailto:[e-mail]] On Behalf Of 
> Christer Holmberg
> Sent: 14 February 2014 09:21
> To: Christian Groves; [e-mail]
> Subject: Re: [MMUSIC] I-D Action: 
> draft-ietf-mmusic-sctp-sdp-06.txt - Christer's initial comments
> 
> Hi Christian,
> 
> > 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.
> 
> Correct. 
> 
> My comment was not on multiple apps per SCTP association 
> (which I agree was the main focus of your e-mail), but simply 
> on the example :)
> 
> > 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?
> 
> No. Only if you want interoperability with a browser.
> 
> BUT, even if there are no browser involved, you can still use 
> the webrtc-datachannel if you want. The name should probably 
> be changed to something more generic, though.
> 
> Regards,
> 
> Christer
> 
> 
> 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
> >
> 
> _______________________________________________
> mmusic mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/mmusic
>