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

[Paul Kyzivat <[e-mail]>]

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
>