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

Juergen Stoetzer-Bradler <Juergen.Stoetzer-Bradler@alcatel-lucent.com> Mon, 30 November 2015 12:56 UTC

Return-Path: <juergen.stoetzer-bradler@alcatel-lucent.com>
X-Original-To: mmusic@ietfa.amsl.com
Delivered-To: mmusic@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EFB1E1A8A5A for <mmusic@ietfa.amsl.com>; Mon, 30 Nov 2015 04:56:07 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.512
X-Spam-Level:
X-Spam-Status: No, score=-1.512 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, J_CHICKENPOX_14=0.6, J_CHICKENPOX_15=0.6, MANGLED_LIST=2.3, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id A9Gt-6nwc93I for <mmusic@ietfa.amsl.com>; Mon, 30 Nov 2015 04:56:06 -0800 (PST)
Received: from smtp-fr.alcatel-lucent.com (fr-hpida-esg-02.alcatel-lucent.com [135.245.210.21]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CB2591A89F1 for <mmusic@ietf.org>; Mon, 30 Nov 2015 04:56:05 -0800 (PST)
Received: from fr712usmtp2.zeu.alcatel-lucent.com (unknown [135.239.2.42]) by Websense Email Security Gateway with ESMTPS id 111E3843F14D5; Mon, 30 Nov 2015 12:56:01 +0000 (GMT)
Received: from FR712WXCHHUB03.zeu.alcatel-lucent.com (fr712wxchhub03.zeu.alcatel-lucent.com [135.239.2.74]) by fr712usmtp2.zeu.alcatel-lucent.com (GMO) with ESMTP id tAUCtiK6031139 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Mon, 30 Nov 2015 13:55:58 +0100
Received: from [135.224.222.110] (135.239.27.40) by FR712WXCHHUB03.zeu.alcatel-lucent.com (135.239.2.74) with Microsoft SMTP Server (TLS) id 14.3.195.1; Mon, 30 Nov 2015 13:55:55 +0100
To: Christian Groves <Christian.Groves@nteczone.com>, <mmusic@ietf.org>
References: <BBE9739C2C302046BD34B42713A1E2A22E88D533@ESESSMB105.ericsson.se> <565654BA.3050802@nteczone.com> <56570542.5070906@alcatel-lucent.com> <56578E09.40000@nteczone.com>
From: Juergen Stoetzer-Bradler <Juergen.Stoetzer-Bradler@alcatel-lucent.com>
Message-ID: <565C4759.90500@alcatel-lucent.com>
Date: Mon, 30 Nov 2015 13:55:53 +0100
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.3.0
MIME-Version: 1.0
In-Reply-To: <56578E09.40000@nteczone.com>
Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha-256; boundary="------------ms080203000706020508010602"
X-Originating-IP: [135.239.27.40]
Archived-At: <http://mailarchive.ietf.org/arch/msg/mmusic/K7yQplfoQSn-7JFw516GeBpeYto>
Subject: Re: [MMUSIC] WGLC for draft-ietf-mmusic-data-channel-sdpneg
X-BeenThere: mmusic@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Multiparty Multimedia Session Control Working Group <mmusic.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/mmusic>, <mailto:mmusic-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/mmusic/>
List-Post: <mailto:mmusic@ietf.org>
List-Help: <mailto:mmusic-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/mmusic>, <mailto:mmusic-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 30 Nov 2015 12:56:08 -0000

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