Re: [MMUSIC] WGLC for draft-ietf-mmusic-data-channel-sdpneg

[Juergen Stoetzer-Bradler <[e-mail]>]

Hello Christian,

Thanks much for having reviewed the document and for all your comments.
Please see my replies below.

Best regards,
Juergen


On 26.11.2015 01:39, Christian Groves wrote:
> Hello Juergen, all,
>
> I have reviewed the document and I don't think there are any major issues preventing it from going 
> forward. My comments below:
>
> General: Double check acronyms are spelled out on first use, e.g. SCTP, SDP
[Juergen] Thanks, will do this.
> General: Sometimes "subprotocol" is used, sometimes "sub-protocol" I guess we should be consistent.
[Juergen] Ok, will make this consistent.
>
> Sect.1: The 2nd sentence seems confusing. I propose to reword "RTCWeb allows applications to use 
> data channels. It RTCWeb defines an in-band DCEP however other in-band or out-of-band protocols 
> may be used for establishing datachannels.
[Juergen] Thanks. This is clearer.
>
> Sect.5.1.1: (defined in Section 4 ), this should probably be section 3?
[Juergen] That's right. Will correct this.
>
> Sect.5.1.1 1st para last sentence: Reliability is now two parameters: max-retr & max-time
[Juergen] Indeed, would propose to replace "reliability" with "maximal number of retransmissions, 
maximal retransmission time, ...".
>
> Sect.5.1.1 1st para last sentence: Priority is not defined by the syntax however its part of DCEP. 
> Do we need to add this?
[Juergen] Indeed, that's missing. Would propose to extend the 'dcmap-opt' ABNF rule correspondingly:

    dcmap-opt       = ordering-opt / subprotocol-opt / label-opt
                      / maxretr-opt / maxtime-opt / priority-opt
                      ; Either only maxretr-opt or maxtime-opt
                      ; is present.

With 'priority-opt' being

    priority-opt    = "priority=" priority-value
    priority-value  = "0" / integer
                      ; unsigned integer value indicating the priority of the data channel
                      ; less than 2^16
                      ; derived from 'Priority' of
                      ; [I-D.ietf-rtcweb-data-protocol]

And would further propose to add a new sub section after current 5.1.1.8 (ordered Parameter) as follows:

5.1.1.8 priority Parameter
The 'priority' parameter indicates the data channel's priority
relative to the  priorities of other data channels, which may
additionally exist over the same SCTP association.
The 'priority' parameter maps to the 'Priority' parameter defined in
[I-D.ietf-rtcweb-data-protocol]. The 'priority' parameter is optional.
In the absence of this parameter "priority=256" is assumed.

>
> Sect.5.1.1.1: "maxretr-value" should we actually add an ABNF value for this? The referred to draft 
> doesn't have ABNF. Its a 2 byte integer
[Juergen] Agree. How about:

    maxretr-value   = "0" / integer
                      ; number of retransmissions
                      ; less than 2^32
                      ; derived from 'Reliability Parameter' of
                      ; [I-D.ietf-rtcweb-data-protocol]

>
> Sect.5.1.1.1: "maxtime-value" should we actually add an ABNF value for this? The referred to draft 
> doesn't have ABNF. Its a 2 byte integer
[Juergen] Agree. Similar as above, this could be

    maxtime-value   = "0" / integer
                      ; milliseconds
                      ; less than 2^32
                      ; derived from 'Reliability Parameter' of
                      ; [I-D.ietf-rtcweb-data-protocol]


>
> Sect.5.1.1.1: The example for a=dcmap:4, wouldn't this be invalid as it contains both the max-time 
> and max-retr parameters?
[Juergen] Yes, indeed. One of both parameters needs to be removed. As the preceding example for 
a=dcmap:3 contains the max-retr parameter I'd propose to remove the max-retr parameter from the 
a=dcmap:4 line.
>
> Sect.5.2.3, pg.14, 7th bullet: "Closes any created data channels for which the expected "a=dcmap:" 
> and "a=dcsa:" attributes  are not present in the SDP answer." Should this also refer to section 
> 5.2.4 on closure?
[Juergen] Agree. Will add a reference to section 5.2.4.
>
> Sect.5.2.5: The miscellaneous section doesn't explicitly cover the case when a=dcmap is missing 
> but a=dsca is included. I take it that its an error. Should we add this?
[Juergen] Good point. I would also consider this as an error. Agree to add related text, e.g.:

SDP offer or answer has no "a=dcmap:" attributes but has "a=dcsa:" attributes
* This is considered an error case. In this case the receiver of such an
   SDP offer or answer SHOULD ignore the "a=dcsa:" attributes and SHOULD
   process the SDP offer or answer as per above case 'SDP offer has no
   "a=dcmap:" attributes' or case 'SDP answer has no "a=dcmap:" attributes'.

>
> Sect.6 1st para under fig.2: "So, the offerer should  close the ..." is this really a "MUST 
> close"? There is text about reusing a data channel but does it apply in this case when no previous 
> data channel has been extablished?
[Juergen] Quite agree. As per the corresponding description in section 5.2.3 ("The agent receiving 
such an SDP answer performs the following:  o  Closes any created data channels for which the 
expected "a=dcmap:" and "a=dcsa:" attributes are not present in the SDP answer.") the SDP offerer in 
example 2 actually must close the data channel with SCTP stream id 0.
As the text in the paragraph after figure 2 is just focused on example 2, should we actually say 
"...the offerer MUST close the data channel for BFCP ...", or rather "... the offerer must close ..."?
>
> Sect.6 bottom pg.18: "Continuing on the earlier example in Figure 1" Is this a continuation of 
> figure 2? The text below figure 3 indicates that MSRP SCTP stream ID 2 is removed. This is example 2.
[Juergen] Yes, you are right. This needs to be changed to "The above example is a continuation of 
the example in Figure 2".
>
> Sect.8.2.2: DCSA appropriate values. Now defined in sect. 5.1.2.1
[Juergen] Indeed. Will change this to section 5.1.2.1.
>
> Sect.11.2: There are no usages of RFCs 4975, 4976, 5547, 6135 and 6714 in the document. These can 
> be deleted.
[Juergen] Agree. Will delete these MSRP related references.
>
> Sect.11.2: There are no usages of RFC6455 and I-D.ietf-rtcweb-jsep the document other than in the 
> changes section. These can be deleted.
[Juergen] Agree. Will also delete these.
>
> Minor editorials: Sent offline to author.
>
> Regards, Christian
>
> On 25/11/2015 8:52 PM, Bo Burman wrote:
>>
>> This is to announce a 4 week Working Group Last Call for
>>
>> draft-ietf-mmusic-data-channel-sdpneg-06
>>
>> as proposed standard.
>>
>> Please review and provide any comments you may have on the document by Wednesday, December 23, 
>> 2015. Comments should be sent to the document authors and the MMUSIC WG list. If you review the 
>> document but do not have any comments, please send a note to that effect as well.
>>
>> Please also forward this WGLC call to any other interested parties who may be able to review the 
>> draft, asking them to also direct their comments to the authors and the list as above.
>>
>> Thank you!
>>
>>         Bo Burman (MMUSIC co-chair)
>>
>> Draft information:
>>
>> This draft is a work item of the Multiparty Multimedia Session Control Working Group of the IETF.
>>
>>         Title           : SDP-based Data Channel Negotiation
>>
>> Authors : Keith Drage
>>
>> Maridi R. Makaraju (Raju)
>>
>> Juergen Stoetzer-Bradler
>>
>> Richard Ejzak
>>
>>                           Jerome Marcon
>>
>>                 Filename        : draft-ietf-mmusic-data-channel-sdpneg-06.txt
>>
>>                 Pages           : 37
>>
>>                 Date            : 2015-10-19
>>
>> 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 in-band Data Channel Establishment
>>
>>    Protocol (DCEP) or using some out-of-band non-DCEP protocol. This
>>
>>    document specifies how the SDP offer/answer exchange can be used to
>>
>>    achieve such an out-of-band non-DCEP 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.
>>
>> The IETF datatracker status page for this draft is:
>>
>> https://datatracker.ietf.org/doc/draft-ietf-mmusic-data-channel-sdpneg/
>>
>> There's also a htmlized version available at:
>>
>> https://tools.ietf.org/html/draft-ietf-mmusic-data-channel-sdpneg-06
>>
>> A diff from the previous version is available at:
>>
>> https://www.ietf.org/rfcdiff?url2=draft-ietf-mmusic-data-channel-sdpneg-06
>>
>> Internet-Drafts are also available by anonymous FTP at:
>>
>> ftp://ftp.ietf.org/internet-drafts/
>>
>>
>>
>> _______________________________________________
>> mmusic mailing list
>> [e-mail]
>> https://www.ietf.org/mailman/listinfo/mmusic
>