Re: [MMUSIC] I-D Action: draft-ietf-mmusic-msrp-usage-data-channel-10.txt - Comment on msrp-cema attribute

Jose M Recio <jose@ch3m4.com> Mon, 22 April 2019 13:24 UTC

Return-Path: <jose@ch3m4.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 986DF120025 for <mmusic@ietfa.amsl.com>; Mon, 22 Apr 2019 06:24:07 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.701
X-Spam-Level:
X-Spam-Status: No, score=-2.701 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=ch3m4.com header.b=k7bj4a43; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=T20BkJZn
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 s6hquW93LgBx for <mmusic@ietfa.amsl.com>; Mon, 22 Apr 2019 06:24:05 -0700 (PDT)
Received: from out3-smtp.messagingengine.com (out3-smtp.messagingengine.com [66.111.4.27]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9493F120074 for <mmusic@ietf.org>; Mon, 22 Apr 2019 06:24:05 -0700 (PDT)
Received: from compute2.internal (compute2.nyi.internal [10.202.2.42]) by mailout.nyi.internal (Postfix) with ESMTP id 9DBE922040 for <mmusic@ietf.org>; Mon, 22 Apr 2019 09:24:04 -0400 (EDT)
Received: from mailfrontend2 ([10.202.2.163]) by compute2.internal (MEProxy); Mon, 22 Apr 2019 09:24:04 -0400
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ch3m4.com; h= subject:to:references:from:message-id:date:mime-version :in-reply-to:content-type:content-transfer-encoding; s=fm3; bh=0 YIIcdKKuudMtfWTU9GCMzLfz9o9yd7wVy86bmkolmA=; b=k7bj4a43oJZMF4fbE h/ItKA2EbWxw7+DoYRtH5VGF9wDiBkihKj3wH9j6nRW+qIAnAdy9wyvUH7KpfJBp tG3RuHGkCE0H5qbqXSysXRGglGbepPPJFHG9kfc+jc0YNBh6GyqlT3/ZcrltvwEF HCUVLAzOYi7ATvAlR9NYzLZbXyWztLmd2XvaMx31dO/2yQcuzT3FC94lJIT9Qwwc ExAee71jsiM06Mpah32hXwuQHyfU2rRs/HeDKQfQ3ZTCo9nBq1lCJirPTogzDGZl rZYg+xGPXl9CJ2hfE4n7KJuP0Zh7iG4FOw62k8DYZMYNR4hZ1HUeE6XaGfWxelYU xH92g==
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=content-transfer-encoding:content-type :date:from:in-reply-to:message-id:mime-version:references :subject:to:x-me-proxy:x-me-proxy:x-me-sender:x-me-sender :x-sasl-enc; s=fm2; bh=0YIIcdKKuudMtfWTU9GCMzLfz9o9yd7wVy86bmkol mA=; b=T20BkJZnq9zDZim65ZrFocjAOJNoQMZkPjUj/OKKPD/AqKgu1nBNTZtxL Ke80+BEfTq6xeBWya6mRCiDw5NnKSrNn4g2ifUA4x5wG3P+GctlegbhHmWzNIOAS xHAGc4r3z31eyM5/lR2rVgm0iTFVecWpC8CcVaAxL/RyzpzQ0WninJKf5vOoGmNs E1qPetxfKlDCbPoVXGNqw6Jlp6IfFasPAwT/Mi5aeywTvGfvPB1LXdKUR3Q6Hlds k2/irS4UTZj9HfRN3jLnWNq/z33OyjGN6J73i/FS8+/8x3jEPCUS9USniLainqNd BP1oXEgNHfekZzz4E2p0u0sOZVuSw==
X-ME-Sender: <xms:dMC9XLVm0kuVo8jWn6daC90XjWk5d0jWEb7qeglhIT8NNU1PGiqIPg>
X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgeduuddrgeeigdeitdcutefuodetggdotefrodftvf curfhrohhfihhlvgemucfhrghsthforghilhdpqfgfvfdpuffrtefokffrpgfnqfghnecu uegrihhlohhuthemuceftddtnecunecujfgurhepuffvfhfhkffffgggjggtgfesthejre dttdefjeenucfhrhhomheplfhoshgvucfoucftvggtihhouceojhhoshgvsegthhefmheg rdgtohhmqeenucfkphepieeirdeliedrvddtgedrudegjeenucfrrghrrghmpehmrghilh hfrhhomhepjhhoshgvsegthhefmhegrdgtohhmnecuvehluhhsthgvrhfuihiivgeptd
X-ME-Proxy: <xmx:dMC9XPBqAfXZvkvlYXlt8pQyaR2mztwKJC9ElErzPXYGSxlB3oof5w> <xmx:dMC9XGFO35yMhdIiCFlDj23fCrQhcmrCzL6ZB6IZLJnNkcwenWj-6Q> <xmx:dMC9XDe0jSNhcf_w3NIlM6utRHEWMhtvbXXWcuaisuG8QYkeBJEjrQ> <xmx:dMC9XHSTx0gqPWZsn_J7fkP-OGKlKNXjxoUc8Eokri6EAyY6cPWjJQ>
Received: from [192.168.1.187] (unknown [66.96.204.147]) by mail.messagingengine.com (Postfix) with ESMTPA id 77A9910319 for <mmusic@ietf.org>; Mon, 22 Apr 2019 09:24:03 -0400 (EDT)
To: mmusic@ietf.org
References: <61D3ED98-04FA-4746-BCDE-37BD38907803@ericsson.com>
From: Jose M Recio <jose@ch3m4.com>
Message-ID: <bc4535ee-7d65-e35e-5e9e-604446bf9d0f@ch3m4.com>
Date: Mon, 22 Apr 2019 21:24:01 +0800
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.6.1
MIME-Version: 1.0
In-Reply-To: <61D3ED98-04FA-4746-BCDE-37BD38907803@ericsson.com>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 7bit
Content-Language: en-GB
Archived-At: <https://mailarchive.ietf.org/arch/msg/mmusic/VloycqFyZ-iJ3OYtXJichJM-o-4>
Subject: Re: [MMUSIC] I-D Action: draft-ietf-mmusic-msrp-usage-data-channel-10.txt - Comment on msrp-cema attribute
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: Mon, 22 Apr 2019 13:24:07 -0000

On 22/4/19 6:36 PM, Christer Holmberg wrote:
> First, in general, I don't want attributes to be "assumed". If an extension (CEMA in this case) mandates an attribute to be included, it shall be included.

I can rewrite so the attribute is always there. I think the intention is 
to make using legacy MSRP stacks (that may not be supporting CEMA) 
transparently use data transport.

Any comments from the list?

> Second, I am not sure I understand the text on "ensuring that the data channel is not established using the path attribute". How would you establish a data channel using the path attribute?

The way I understand this is "make sure path attribute is ignored for 
setting up the transport".

This is also connected to CEMA being assumed. I believe the overall 
intention of the paragraph is that transport establishment must always 
use CEMA, even if the attribute is not there, and path should never be 
used. So, for data channel transport, CEMA is not optional, as RFC6714 
says. Maybe a rewriting making this more clear is needed.