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

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

I'd be happy with either.

I've just submitted draft-ejzak-mmusic-data-channel-sdpneg using the term "data channel" in the text, but the SDP is still aligned with the sctp-sdp draft.

Keith 

> -----Original Message-----
> From: mmusic [mailto:[e-mail]] On Behalf Of 
> Paul Kyzivat
> Sent: 14 February 2014 19:42
> To: [e-mail]
> Subject: Re: [MMUSIC] I-D Action: 
> draft-ietf-mmusic-sctp-sdp-06.txt - Christer's initial comments
> 
> On 2/14/14 1:40 PM, DRAGE, Keith (Keith) wrote:
> > Would agree to changing webrtc-data channel to something 
> more generic.
> 
> A couple of possibilities that would WFM:
> 
> - sctp-data-channel (or sctp-datachannel)
> - data-channel (or datachannel)
> 
> The latter is appealing, but may be *too* generic.
> 
> 	Thanks,
> 	Paul
> 
> > 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
> >>
> > _______________________________________________
> > mmusic mailing list
> > [e-mail]
> > https://www.ietf.org/mailman/listinfo/mmusic
> >
> 
> _______________________________________________
> mmusic mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/mmusic
>