Re: [MMUSIC] AD Review: draft-ietf-mmusic-t140-usage-data-channel

Adam Roach <adam@nostrum.com> Fri, 24 January 2020 12:08 UTC

Return-Path: <adam@nostrum.com>
X-Original-To: mmusic@ietfa.amsl.com
Delivered-To: mmusic@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BAE5F1200F6; Fri, 24 Jan 2020 04:08:38 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.405
X-Spam-Level:
X-Spam-Status: No, score=-1.405 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_INVALID=0.1, DKIM_SIGNED=0.1, KHOP_HELO_FCRDNS=0.275, T_SPF_HELO_PERMERROR=0.01, T_SPF_PERMERROR=0.01] autolearn=no autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=fail (1024-bit key) reason="fail (message has been altered)" header.d=nostrum.com
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 o8Us0gDRaUkp; Fri, 24 Jan 2020 04:08:37 -0800 (PST)
Received: from nostrum.com (raven-v6.nostrum.com [IPv6:2001:470:d:1130::1]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E1BCE1200F4; Fri, 24 Jan 2020 04:08:37 -0800 (PST)
Received: from Zephyrus.local (99-152-146-228.lightspeed.dllstx.sbcglobal.net [99.152.146.228]) (authenticated bits=0) by nostrum.com (8.15.2/8.15.2) with ESMTPSA id 00OC8TPL092775 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NO); Fri, 24 Jan 2020 06:08:31 -0600 (CST) (envelope-from adam@nostrum.com)
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=nostrum.com; s=default; t=1579867712; bh=cjuBfI7KPYkTk/kIN7GHLoXR8cMeZwXShCXCbcwy4qg=; h=Subject:To:References:From:Date:In-Reply-To; b=IhcrYE01lorh3gOw+HbDvfPJIrbRaZxTulvZqyBooO3LD6PObgU+JYuqavbKADqvj Epp02ajkrXt+ggm8WAV+eerjUeisfolHGRQX6b/s/juzjenVK9hyLb65eWsc3SB8xS UM0xud6LZuFv5QBxOQvoeNv+OrEdmQXz6grc8Qp4=
X-Authentication-Warning: raven.nostrum.com: Host 99-152-146-228.lightspeed.dllstx.sbcglobal.net [99.152.146.228] claimed to be Zephyrus.local
To: Christer Holmberg <christer.holmberg@ericsson.com>, "draft-ietf-mmusic-t140-usage-data-channel.all@ietf.org" <draft-ietf-mmusic-t140-usage-data-channel.all@ietf.org>, "mmusic@ietf.org" <mmusic@ietf.org>
References: <25e5fd92-84c2-fd6c-d497-3fcfa452967e@nostrum.com> <556B5E81-09BE-41E4-9A2C-E902E870F0E0@ericsson.com>
From: Adam Roach <adam@nostrum.com>
Message-ID: <715526dd-fa80-ea2b-5837-aa08193b7445@nostrum.com>
Date: Fri, 24 Jan 2020 06:08:24 -0600
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:60.0) Gecko/20100101 Thunderbird/60.9.1
MIME-Version: 1.0
In-Reply-To: <556B5E81-09BE-41E4-9A2C-E902E870F0E0@ericsson.com>
Content-Type: text/plain; charset="utf-8"; format="flowed"
Content-Transfer-Encoding: 8bit
Content-Language: en-US
Archived-At: <https://mailarchive.ietf.org/arch/msg/mmusic/H_FJZHoYnWPuz9pDJmtZIGIIpIg>
Subject: Re: [MMUSIC] AD Review: draft-ietf-mmusic-t140-usage-data-channel
X-BeenThere: mmusic@ietf.org
X-Mailman-Version: 2.1.29
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: Fri, 24 Jan 2020 12:08:39 -0000

On 1/24/20 05:30, Christer Holmberg wrote:
> Hi Adam,
>
> Thank You for the review!
>
> I have removed the comments where I agree and will modify as suggested without further discussion. Please see inline for the rest.
>         
>      ---------------------------------------------------------------------------
>         
>     
>      §4.1:
>      
>       >>  The offerer and answerer MAY include the priority attribute parameter
>       >>  and the label attribute parameter in the 'dcmap' attribute value.  If
>       >>  the offerer includes a label attribute parameter, the answerer MUST
>       >>  NOT change the value in the answer.
>      >
>      > This should be explicit about whether the answerer is allowed to add a label
>      > if the offerer did not. It should also be clear about whether the
>      > priority is allowed to be different in the answer than in the offer.
>
> If not explicitly included, the default value is 256, so there will always be a value (implicit or explicit). I guess we can point that out.
>
> Perhaps something like:
>
> OLD:
>
>     The offerer and answerer MAY include the priority attribute parameter
>     and the label attribute parameter in the 'dcmap' attribute value.  If
>     the offerer includes a label attribute parameter, the answerer MUST
>     NOT change the value in the answer.
>
> NEW:
>
>     The offerer and answerer MAY include the priority attribute parameter
>     and the label attribute parameter in the 'dcmap' attribute value.  As
>     defined in [I-D.ietf-mmusic-data-channel-sdpneg], in absence of the
>     attribute parameter an attribute parameter value of 256 is assumed.
>     The answerer MUST not change the value in the answer.


Sounds good to me.


>      
>      ---------------------------------------------------------------------------
>      
>      §4.1:
>      
>      >>  The offerer and answerer MUST NOT include the max-retr and max-time
>      >>  attribute parameters in the 'dcmap' attribute.
>      >
>      > Ideally, this would include text that indicates what a recipient of such
>      > messages would do (with the obvious choices being ignoring them or treating
>      > them as an error). I suggest the easiest thing to specify is that recipients
>      > of either attribute for a T.140 section MUST ignore them.
>
> Just to note:
>
> - The draft defines that the T.140 data channel is reliable.
> - max-retr and max-time are used to indicate that a data channel is partially reliable, so there would be a conflict.
>
> So, the question is whether it is ok to just ignore, or whether it is a protocol error and the m- line therefore should be rejected.
>
> If *both* attribute parameters are included in an offer (which would also create a conflict), draft-channel-sdpneg says that the offer must be rejected.


Given this last fact, it seems that the best approach would be to treat 
the presence of either parameter in this context as an error. The key 
here is that the behavior should be spelled out.


>      
>      ---------------------------------------------------------------------------
>      
>      §4.2:
>      
>       >>  An offerer and answerer MAY, in each offer and answer, include one or
>       >>  more SDP 'dcsa' attributes [I-D.ietf-mmusic-data-channel-sdpneg] in
>      >
>      > Since this appears to be restating behavior defined elsewhere, consider
>      > changing the normative "MAY" to a simple English "may".
>
> I suggest to use "can", because some reviewers don't want to use the normative words unless in capital letters.
>      


Sure; that works.

Thanks!

/a