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

[Christian Groves <[e-mail]>]

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 )


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.


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.

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

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".

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


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
> [e-mail]
> https://www.ietf.org/mailman/listinfo/mmusic
>