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

RIchard Ejzak <richard.ejzak@gmail.com> Mon, 22 April 2019 21:06 UTC

Return-Path: <richard.ejzak@gmail.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 7EEBE120098 for <mmusic@ietfa.amsl.com>; Mon, 22 Apr 2019 14:06:50 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2
X-Spam-Level:
X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.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 bFf_787qq98a for <mmusic@ietfa.amsl.com>; Mon, 22 Apr 2019 14:06:48 -0700 (PDT)
Received: from mail-it1-x136.google.com (mail-it1-x136.google.com [IPv6:2607:f8b0:4864:20::136]) (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 18939120073 for <mmusic@ietf.org>; Mon, 22 Apr 2019 14:06:48 -0700 (PDT)
Received: by mail-it1-x136.google.com with SMTP id q19so2296102itk.3 for <mmusic@ietf.org>; Mon, 22 Apr 2019 14:06:48 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=subject:to:references:from:message-id:date:user-agent:mime-version :in-reply-to:content-transfer-encoding:content-language; bh=n6dmhK+Mm9wgLINuPOMl/0XgkV/lxf1fLD2EH2WfEh8=; b=bTY8VnnbHt9FcV6AFwGfc3/fpTIjX3S9L+DP5fnBV8gITUwXgBuNeimJ5IoSqF/Sjm GWOcknRdtVHdMD78wg+YBeXNgPOqRRxpDiA2+olivuS+eTJlFtEDoHlX4Gl2sSBhG4g/ ZlS9Q1djdpVJSUvGMoQ2hv5YCPLwdVly830DGtPRJXK8l+enW2kpGZnhpfIdUhGTva6A AspGUcUl9PM8NPRjsu+JLagFV/WbkzskPEvAkp139mwigQho6t11SWVPokW630bD6+p6 vORDqKE3/KWcGHLxP7laeojRAd3HoagyhTBq8tiGC3HI2lQao2nfCQHpI18L1rdHGbkw QcjA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-transfer-encoding :content-language; bh=n6dmhK+Mm9wgLINuPOMl/0XgkV/lxf1fLD2EH2WfEh8=; b=gh4ZDpPV393v/bNn4sGrCgmmF+BTccZmikY3sx0wvJHfDB+ZNmuUm/btXtYMry9kCM AV63H3DMwJQAWCDzBagfgdmXX+HGsZ5thRr0aAaD8Z3m4e+2RRRa73UpD1I9KQ9f2Vo0 T/gupXD7v0lQKoiCxohrLUtE6YJcjlzHTSSPKmAIxLgioS6mTKV86hXxNsfc/TJyvzsA wBRK1+IGx8l3+24NunMc5wkxLmc9g4737fz1XjpQKHAcuH/58TjdXfUdVn/BxQG0W8TR Pw07JZ5IodRVfVt2xSLtVLnLXkJ42rGN8EcJojVTubt/KkOTwOZXfw7qpcEZmdCoEr/N IYyA==
X-Gm-Message-State: APjAAAUbpzdiV0AaMQBz6nL7bOTUwxwHlzTy64IAcTqg2nSMtMlGsqoG J0sJW7BsG6cnWjIoYXfbZxcF9Knm
X-Google-Smtp-Source: APXvYqygfNGA6hXmx80KswRXWE3NI6DgIrFhZ5F308batmCl4rqtSCcMWv2IRYEP1xjxaDBkur1zCg==
X-Received: by 2002:a24:3288:: with SMTP id j130mr185320ita.104.1555967207303; Mon, 22 Apr 2019 14:06:47 -0700 (PDT)
Received: from [192.168.1.130] ([71.194.253.108]) by smtp.gmail.com with ESMTPSA id w184sm6604069ita.9.2019.04.22.14.06.46 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 22 Apr 2019 14:06:46 -0700 (PDT)
To: Christer Holmberg <christer.holmberg@ericsson.com>, Jose M Recio <jose@ch3m4.com>, "mmusic@ietf.org" <mmusic@ietf.org>
References: <61D3ED98-04FA-4746-BCDE-37BD38907803@ericsson.com> <bc4535ee-7d65-e35e-5e9e-604446bf9d0f@ch3m4.com> <E24A4C62-CBCB-47F0-973F-0BF253AC4A31@ericsson.com>
From: RIchard Ejzak <richard.ejzak@gmail.com>
Message-ID: <6e4edb12-936d-62b5-b4ff-e05b6d117e75@gmail.com>
Date: Mon, 22 Apr 2019 13:12:48 -0500
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: <E24A4C62-CBCB-47F0-973F-0BF253AC4A31@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/mlLRylOphEecq_yQ-NCE9zcViEg>
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 21:06:51 -0000

Hi,

Since I wrote the original text, I should probably reply...

I agree with Christer that the CEMA attribute is not needed.  It was 
originally included to make it clear that the path attribute could not 
be used to establish the data channel.  But this is obvious for this new 
type of transport.  RFC7977 (WebSocket transport for MSRP) handles this 
very nicely by using an .invalid domain name in the path attribute.  I 
suggest adopting this approach for dc.

Richard


On 4/22/19 3:32 PM, Christer Holmberg wrote:
> Hi,
>
>>> 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.
>    
> I think we first need to think whether it is needed.
>
> Keep in mind (and that should probably better described in the document) that the normal MSRP routing procedures don't apply. The MSRP messages will be routed in the data channel, which is established between the SIP peers (or whatever signaling protocol is used). I guess proxies and application servers can look at the top-most path attribute, but that is not going to be the primary routing input. I don't think the draft says anything about that - it just seems to assume that the data channel will end up in the intended MSRP peer.
>
> If there then is a gateway that forwards the MSRP messages towards a legacy MSRP endpoint it may use CEMA, but that's a separate thing.
>
>>> 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.
>    
> But the transport establishment of a data channel does not use CEMA.
>
> Maybe there is a reason for all of this (it's such a long time since I looked at it), but it needs to be clear why we mandate certain things.
>
> Regards,
>
> Christer
>
>
>    
>      
>      _______________________________________________
>      mmusic mailing list
>      mmusic@ietf.org
>      https://www.ietf.org/mailman/listinfo/mmusic
>      
>
> _______________________________________________
> mmusic mailing list
> mmusic@ietf.org
> https://www.ietf.org/mailman/listinfo/mmusic