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

Christian Groves <Christian.Groves@nteczone.com> Thu, 26 November 2015 22:56 UTC

Return-Path: <Christian.Groves@nteczone.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 13E1D1B2AF9 for <mmusic@ietfa.amsl.com>; Thu, 26 Nov 2015 14:56:21 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 0.9
X-Spam-Level:
X-Spam-Status: No, score=0.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, J_CHICKENPOX_14=0.6, J_CHICKENPOX_15=0.6, MANGLED_LIST=2.3, RCVD_IN_DNSWL_LOW=-0.7] autolearn=no
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 tt2LZPc3Dp5A for <mmusic@ietfa.amsl.com>; Thu, 26 Nov 2015 14:56:19 -0800 (PST)
Received: from cserver5.myshophosting.com (cserver5.myshophosting.com [175.107.161.1]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 708131B2AF8 for <mmusic@ietf.org>; Thu, 26 Nov 2015 14:56:19 -0800 (PST)
Received: from ppp118-209-49-23.lns20.mel4.internode.on.net ([118.209.49.23]:49562 helo=[192.168.1.22]) by cserver5.myshophosting.com with esmtpsa (TLSv1:DHE-RSA-AES128-SHA:128) (Exim 4.86) (envelope-from <Christian.Groves@nteczone.com>) id 1a25Sa-002RZD-5S; Fri, 27 Nov 2015 09:56:16 +1100
To: Juergen Stoetzer-Bradler <Juergen.Stoetzer-Bradler@alcatel-lucent.com>, mmusic@ietf.org
References: <BBE9739C2C302046BD34B42713A1E2A22E88D533@ESESSMB105.ericsson.se> <565654BA.3050802@nteczone.com> <56570542.5070906@alcatel-lucent.com>
From: Christian Groves <Christian.Groves@nteczone.com>
Message-ID: <56578E09.40000@nteczone.com>
Date: Fri, 27 Nov 2015 09:56:09 +1100
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: <56570542.5070906@alcatel-lucent.com>
Content-Type: text/plain; charset="utf-8"; format="flowed"
Content-Transfer-Encoding: 7bit
X-AntiAbuse: This header was added to track abuse, please include it with any abuse report
X-AntiAbuse: Primary Hostname - cserver5.myshophosting.com
X-AntiAbuse: Original Domain - ietf.org
X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12]
X-AntiAbuse: Sender Address Domain - nteczone.com
X-Get-Message-Sender-Via: cserver5.myshophosting.com: authenticated_id: christian.groves@nteczone.com
X-Authenticated-Sender: cserver5.myshophosting.com: christian.groves@nteczone.com
X-Source:
X-Source-Args:
X-Source-Dir:
Archived-At: <http://mailarchive.ietf.org/arch/msg/mmusic/QuTSmju5ovmItGIqjYx20F5oMLo>
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: Thu, 26 Nov 2015 22:56:21 -0000

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