Re: [MMUSIC] draft-ejzak-mmusic-data-channel-sdpneg and draft-ejzak-mmusic-msrp-usage-data-channel

Hello Christian,

Thank you for your comments.
Please see my remarks inserted below.

Thanks,
Juergen

On 12.11.2014 04:17, Christian Groves wrote:
> Hello
>
> I had a chance to look over the latest draft in more details. Some comments/questions:
>
> 5.1.1.1: To enforce the text about dcmap-opt the ABNF could be updated:
>    dcmap-opt       = ordering-opt / subprotocol-opt / label-opt
>                      / ( maxretr-opt / maxtime-opt )

[Juergen] Actually, I am not sure if this would formally prevent maxretr-opt and maxtime-opt  from 
both being present simultaneously, as we would still have
     dcmap-value = dcmap-stream-id [ SP dcmap-opt *(";" dcmap-opt) ]
(allowing an arbitrary number of "dcmap-opt").
My understanding of RFC 5234's definition of "alternation" has so far been that
      dcmap-opt = ordering-opt / subprotocol-opt / label-opt / maxretr-opt / maxtime-opt
and
     dcmap-opt = ordering-opt / subprotocol-opt / label-opt / ( maxretr-opt / maxtime-opt )
are actually equivalent.
Right now don't see a "compact" way of strengthening the actual ABNF rules without having to list 
all possible parameter combinations and permutations.

>
>
> 5.1.1.3: I think you can remove the "action item". draft-ietf-rtcweb-data-protocol indicates "The 
> protocol field is to ease cross-application interoperation("federation") by identifying the user 
> data being passed with an IANA-registered string ('WebSocket Subprotocol Name Registry' defined in 
> [RFC6455]). I wouldn't see the out of band method using a different registry.

[Juergen] Agree.

>
>
> 5.1.1.4. max-retr parameter: This draft seems to use the absence of the "max-retr" parameter to 
> indicate the use of a reliable channel It also indicates a default value of "unbounded". 
> draft-ietf-rtcweb-data-protocol indicates "For reliable Data Channels this field MUST be set to 0 
> on the sending side and MUST be ignored on the receiving side."
> To better align with the data channel protocol i'd suggest changing the of 5.1.1.4 to indicate 
> that "The max-retr parameter is optional with the default value equal to 0 indicating that no 
> retramsmission is used.

[Juergen] Our current intention is that the absence of "max-retr" and "max-time" in the a=dcmap 
attribute value would indicate a reliable data channel, similar as channel types 
"DATA_CHANNEL_RELIABLE" and "DATA_CHANNEL_RELIABLE_UNORDERED" in DCEP's DATA_CHANNEL_OPEN message.
And that "max-retr=0" would actually indicate a partial reliable data channel with the maximal 
number of retransmissions set to zero (similar to DATA_CHANNEL_PARTIAL_RELIABLE_REXMIT(_UNORDERED) 
and "Reliability Parameter" = 0 in the DATA_CHANNEL_OPEN message).
If we kept this semantic of "max-retr=0", then a default value equal to 0 would result in an a=dcmap 
attribute without "max-retr" parameter actually indicating a correspondingly partial reliable data 
channel, such that then the data channel would actually not be reliable as far as I understand.

>
> Also is the term "unreliable" appropriate given that the data channel protocol talks about 
> "partial reliability"?

[Juergen] Agree. We should replace "unreliable" with "partially reliable" throughout the document.

>
> 5.1.1.5 similar to 5.1.1.4 I think it would be better to talk about specific behaviour when the 
> parameter is omitted rather than saying "unbounded".

[Juergen] Agree. We should make this case more explicit and e.g. refer to RFC 4960 and say:
"The max-time parameter is optional. If the max-time parameter is not present, then the generic SCTP 
retransmission timing rules apply as specified in [RFC 4960]."

Similarly in 5.1.1.4; there we could e.g. say:
"The max-retr parameter is optional. If the max-retr parameter is not present, then the maximal 
number of retransmissions is determined as per the generic SCTP retransmission rules as specified in 
[RFC 4960]."

Would you agree to this?

>
> 6. Example: In the examples a=dcmap:0 subprotocol="BFCP";label="BGCP" lines. Is the B<G>CP for the 
> label intentional?

[Juergen] That's a typo. Should have been 'label="BFCP"'. We'll correct this.

>
>
> Regards, Christian
>
>
>
>
> On 28/10/2014 1:39 AM, DRAGE, Keith (Keith) wrote:
>> Based on the discussion on list over the last few days, I have submitted revised versions of the 
>> two SDP negotiation over data channel drafts as follows:
>>
>> A new version of I-D, draft-ejzak-mmusic-data-channel-sdpneg-02.txt
>> has been successfully submitted by Keith Drage and posted to the IETF repository.
>>
>> Name:        draft-ejzak-mmusic-data-channel-sdpneg
>> Revision:    02
>> Title:        SDP-based "SCTP over DTLS" data channel negotiation
>> Document date:    2014-10-27
>> Group:        Individual Submission
>> Pages:        22
>> URL: http://www.ietf.org/internet-drafts/draft-ejzak-mmusic-data-channel-sdpneg-02.txt
>> Status: https://datatracker.ietf.org/doc/draft-ejzak-mmusic-data-channel-sdpneg/
>> Htmlized: http://tools.ietf.org/html/draft-ejzak-mmusic-data-channel-sdpneg-02
>> Diff: http://www.ietf.org/rfcdiff?url2=draft-ejzak-mmusic-data-channel-sdpneg-02
>>
>> Abstract:
>>     The Real-Time Communication in WEB-browsers (RTCWeb) working group is
>>     charged to provide protocols to support direct interactive rich
>>     communications using audio, video, and data between two peers' web-
>>     browsers.  For the support of data communication, the RTCWeb working
>>     group has in particular defined the concept of bi-directional data
>>     channels over SCTP, where each data channel might be used to
>>     transport other protocols, called sub-protocols.  Data channel setup
>>     can be done using either the internal in-band band (also referred to
>>     as 'internal' for the rest of the document) WebRTC Data Channel
>>     Establishment Protocol or some external out-of-band simply referred
>>     to as 'external negotiation' in the rest of the document . This
>>     document specifies how the SDP offer/answer exchange can be used to
>>     achieve such an external negotiation.  Even though data channels are
>>     designed for RTCWeb use initially they may be used by other protocols
>>     like, but not limited to, the CLUE protocol.  This document is
>>     intended to be used wherever data channels are used.
>>
>>
>> A new version of I-D, draft-ejzak-mmusic-msrp-usage-data-channel-01.txt
>> has been successfully submitted by Keith Drage and posted to the IETF repository.
>>
>> Name:        draft-ejzak-mmusic-msrp-usage-data-channel
>> Revision:    01
>> Title:        MSRP over SCTP/DTLS data channels
>> Document date:    2014-10-27
>> Group:        Individual Submission
>> Pages:        11
>> URL: http://www.ietf.org/internet-drafts/draft-ejzak-mmusic-msrp-usage-data-channel-01.txt
>> Status: https://datatracker.ietf.org/doc/draft-ejzak-mmusic-msrp-usage-data-channel/
>> Htmlized: http://tools.ietf.org/html/draft-ejzak-mmusic-msrp-usage-data-channel-01
>> Diff: http://www.ietf.org/rfcdiff?url2=draft-ejzak-mmusic-msrp-usage-data-channel-01
>>
>> Abstract:
>>     This document specifies how the Message Session Relay Protocol (MSRP)
>>     can be instantiated as a data channel sub-protocol, using the the SDP
>>     offer/answer exchange-based external negotiation defined in
>>     [I-D.ejzak-mmusic-data-channel-sdpneg].  Two network configurations
>>     are documented: a WebRTC end-to-end configuration (connecting two
>>     MSRP over data channel endpoints), and a gateway configuration
>>     (connecting an MSRP over data channel endpoint with an MSRP over TCP
>>     endpoint).
>> _______________________________________________
>> mmusic mailing list
>> mmusic@ietf.org
>> https://www.ietf.org/mailman/listinfo/mmusic
>>
>
> _______________________________________________
> mmusic mailing list
> mmusic@ietf.org
> https://www.ietf.org/mailman/listinfo/mmusic
>
>

-- 
JSB_email_signature