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

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

Hello Christian,

Thanks for further feedback.
As you propose, I'll add the "priority" parameter to one or two of the examples in section 5.1.1.1
and will reformulate the sentence after figure 2 correspondingly.

Thanks,
Juergen

On 26.11.2015 23:56, Christian Groves wrote:
> Hello Juergen,
>
> Thanks for the updates. Please see my responses below.
>
> Regards, Christian
>
> ..snip..
>>>
>>> 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, ...".
> [CNG] OK
>>>
>>> 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.
>>
> [CNG] The proposal is OK for me. Perhaps it would be worth adding the priority parameter to one of 
> the examples?
>
>>>
>>> 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]
> [CNG] OK
>>
>>>
>>> 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]
> [CNG] OK
>>
>>>
>>> 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.
> [CNG] OK
>>>
>>> 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.
> [CNG] OK
>>>
>>> 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'.
> [CNG] OK
>>
>>>
>>> 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 
>> ..."?
> [CNG] How about avoiding "must" or "should" by saying the " ... The offerer closes the data or 
> BFCP ..."? That's descriptive of the example.
>
> ..snip..