Re: [MMUSIC] I-D Action: draft-ietf-mmusic-msrp-usage-data-channel-11.txt

Jose M Recio <jose@ch3m4.com> Wed, 14 August 2019 12:07 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 8791A120137 for <mmusic@ietfa.amsl.com>; Wed, 14 Aug 2019 05:07:31 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.7
X-Spam-Level:
X-Spam-Status: No, score=-2.7 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, URIBL_BLOCKED=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=TlmoWjo5; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=aslsHxOK
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 wse-zci-6vJz for <mmusic@ietfa.amsl.com>; Wed, 14 Aug 2019 05:07:28 -0700 (PDT)
Received: from out4-smtp.messagingengine.com (out4-smtp.messagingengine.com [66.111.4.28]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AA17C12010F for <mmusic@ietf.org>; Wed, 14 Aug 2019 05:07:28 -0700 (PDT)
Received: from compute2.internal (compute2.nyi.internal [10.202.2.42]) by mailout.nyi.internal (Postfix) with ESMTP id B6F0E21B24; Wed, 14 Aug 2019 08:07:27 -0400 (EDT)
Received: from mailfrontend1 ([10.202.2.162]) by compute2.internal (MEProxy); Wed, 14 Aug 2019 08:07:27 -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=fm1; bh=o GOGHvtpGYu1B33QKXRQGt8F8vNKiK63txf1/uYoVX0=; b=TlmoWjo5cf3/Z7por fKazgptrlb0AyLHJU446wFSwfKwV5sa5xZ47cFzv4D79q/oFgLfChq8ikkkPV0yz rTjcqzn4wuB7OPlpeLvvDHoUpHyUhFzNSbcEZDphgKOP6WvZCsFR7gp8E0WMV1aC SayyGA7PjW1FIk+crztYtRWzfUUBKp0f3/5cO7fa8iK1rZIRYedeHe4unB1ae90K LTqCQHag2F1NDHm07cKjeTfpxIK08gs4X6jOcQBrqwm02iAk3YEepb6c6ezZjqj5 LD3yaeRApZc8bKIcup6i+2/g4pyPtmfdiFWjLINd6Gu2sgOdoOApgu06oohGuRSG BRxTQ==
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=fm3; bh=oGOGHvtpGYu1B33QKXRQGt8F8vNKiK63txf1/uYoV X0=; b=aslsHxOKndpZkHBmlzqWabH7m6ytFvP6kNU58XJsKTlHHZA6ZTh5LFcoF T6ciy4+/slY/FmnrteFnuDjmqPrSn6WPfQ8PGl+rPmTigqb1V/OUkWQicJGcnSlR b4rgYNzf0DN9SLRjWFewDbrWhvk32gGi4B6fXBoyhci3XJ2yPfLAg0XBMecufN9D vYvy0raKRXU3rS9ARGS1w0crO6F1rTHD4+vgsIThQdjyMaT9Ge1gBu4rXSnz0gY2 n6greBp8rWxoKw9296PoduRB9M4ATyPw+SgM2uvU9RccCQOafA05TNWRD+3a7f+y C2+U6u9Cttx1HvRqzVwPAOUawyRqg==
X-ME-Sender: <xms:fvlTXZSQ1M9Av0lxC1w32QF3DtG9rITSAYaTkzsUGSvpQtHg_0tmLg>
X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgeduvddruddvkedggeegucetufdoteggodetrfdotf fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfqfgfvpdfurfetoffkrfgpnffqhgen uceurghilhhouhhtmecufedttdenucesvcftvggtihhpihgvnhhtshculddquddttddmne cujfgurhepuffvfhfhkffffgggjggtgfesthekredttdefjeenucfhrhhomheplfhoshgv ucfoucftvggtihhouceojhhoshgvsegthhefmhegrdgtohhmqeenucffohhmrghinhepgh hithhhuhgsrdgtohhmnecukfhppedufeekrdejhedrleefrdegfeenucfrrghrrghmpehm rghilhhfrhhomhepjhhoshgvsegthhefmhegrdgtohhmnecuvehluhhsthgvrhfuihiivg eptd
X-ME-Proxy: <xmx:fvlTXUbm5VvSd_K3WCXvU0uc4t837jY5vI9BZ3W3js3kfa0ELiDmgg> <xmx:fvlTXdiZP06HFtMYfFfE2E0_LFFynvh_NaSCOpmBh8-dk06YofnE6Q> <xmx:fvlTXZjoY1AcL6yKD90yWTyG_M725aGtYGrLroWJOqXhziybk2_TvQ> <xmx:f_lTXWVTyOylrx2RjD5B0ApkTDko7dZp676oy9dPPEWoj6r1cGg4fw>
Received: from [192.168.0.102] (unknown [138.75.93.43]) by mail.messagingengine.com (Postfix) with ESMTPA id AB2B18005C; Wed, 14 Aug 2019 08:07:25 -0400 (EDT)
To: Christer Holmberg <christer.holmberg@ericsson.com>, "mmusic@ietf.org" <mmusic@ietf.org>
References: <7384E828-FC0E-448A-ADA2-F2D44395089B@ericsson.com>
From: Jose M Recio <jose@ch3m4.com>
Message-ID: <0bc43455-c178-a0b3-d187-1f3f6c57ddcb@ch3m4.com>
Date: Wed, 14 Aug 2019 20:07:22 +0800
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.9.1
MIME-Version: 1.0
In-Reply-To: <7384E828-FC0E-448A-ADA2-F2D44395089B@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/RRkXaeXW0oO3kwLtFUYNcrhWOdg>
Subject: Re: [MMUSIC] I-D Action: draft-ietf-mmusic-msrp-usage-data-channel-11.txt
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: Wed, 14 Aug 2019 12:07:31 -0000


On 11/08/19 18:05, Christer Holmberg wrote:
>      >> But, are the data channel endpoints still going to insert the path(s) in the MSRP messages?
>      >
>      > I think nothing prevents endpoints to format From-Path and To-Path in
>      > MSRP messages as required by the application, for example, as defined by
>      > RCS specifications.
>      
>      Sure, but this draft needs to define what the endpoints do.
The draft does not need to impose any requirements on how the endpoints 
form the MSRP messages. This is defined by the MSRP RFCs, RCS specs, or 
others.

>      > If the other endpoint is not a GW or is a GW acting as B2BUA, those
>      > fields would be processed as defined by MSRP and the application using
>      > the protocol.
>      >
>      > If the other endpoint is a GW providing transport interworking, there's
>      > no reason for look at MSRP messages. It should be restricted to
>      > transport interworking. How transport is established it's not defined by
>      > the draft, it just says that path attributes should not be used for that
>      > purpose.
>      
>      Let's forget GWs for a moment, and focus on the data channel. A data channel endpoint does not know whether the peer is a GW, so there needs to be generic procedures.
What I tried to explain (unsuccesfully) is that MSRP processing is not 
affected in endpoints implementing this draft, it is the same if the 
endpoint is either a gateway or another endpoint.

>      > I believe an implementor can find this, I can add a short paragraph to
>      > clarify in next revision that would essentially replicate what it's
>      > already in RFC4975, what do you think?
>      
>      We need text that describes how the MSRP messages are created/encoded. We can simply refer to 4975 if that works, but it needs to be clear whether to e.g., use
>      received path attributes and create To/From-paths etc.
I agree with that, I think referring back to 4975 is enough, and it 
would make  behavior more clear.
>      >> Also, section 6 says: "Path attributes SHALL NOT be used for transport level interworking." What is meant by that?
>      > My understanding is that it means that the URI fields (IP, port, etc) should not be used for the purposes of establishing the transport
>      > towards the endpoint.
>      
>      Well, that is not clear to me :)
This is more clear in the new revision with your suggestion on gateway 
procedures, please take a look.

>      Anyway, my suggestion is that we focus on getting the data channel interface text done first, and then we can look at the gateway section.
>
>      It would also be useful to have to XML (or whatever format you use to edit the document) on GitHub, so that one can suggest changes directly without having to explain
>      them in e-mails. It is very convenient from my experience :)
Agree, I have uploaded the xml document to this github repo:
https://github.com/josemrecio/draft-msrp-data-channel

I have already created a work in progress version 13 with your comments 
on gateway procedures.

>      Regards,
>
>      Christer
>
>     
>
>
>
>      > On 18/07/19 17:18, Christer Holmberg wrote:
>      >> Hi,
>      >>
>      >> If think there is a bigger question here, that MAY have to be clarified ietf-mmusic-data-channel-sdpneg:
>      >>
>      >> To my understanding, the SDP dcsa attribute is used to provide information that is needed to operate the protocol (MSRP in this case) on the data channel - between the data channel endpoints.
>      >>
>      >> Now, if the data channel peer is a GW, and you need to provide some information (path attributes etc in the case of MSRP) for what happens beyond the GW, is the dcsa attribute really intended for that?
>      >>
>      >> So, if the data channel peer is an MSRP GW, using legacy MSRP on the "other side", is the dcsa attribute the correct mechanism to provide the GW with whatever information is are needed on the "other side"?
>      >>
>      >> Regards,
>      >>
>      >> Christer
>      >>
>      >>
>      >>
>      >>
>      >>
>      >>
>      >>
>      >>
>      >>
>      >>
>      >>
>      >> On 13/07/2019, 15.24, "mmusic on behalf of Makaraju, Raju (Nokia - US/Naperville)" <mmusic-bounces@ietf.org on behalf of raju.makaraju@nokia.com> wrote:
>      >>
>      >>       >[JM] Draft covers either direct connection to an endpoint or direct connection to a gateway. As middleboxes are out of scope in the connection using >data channel, then CEMA is out of scope. This short explanation currently appears as justification for saying that CEMA is out of scope. I can remove >the explanation and just state that CEMA is out of scope.
>      >>       [Raju] I agree with that.
>      >>
>      >>       > For example, if the GW is implemented on an SBC, it can use CEMA towars the inside network, using a non-dc transport. But not towards endpoints
>      >>       >using data channel transport.
>      >>       [Raju] Let's please make this clear in the draft.
>      >>
>      >>       >[JM] I agree for RCS should be like that. Would mandating this restrict applicability for other applications?
>      >>       [Raju] I agree that such design limitation should only be for RCS (self-imposed), but not for other applications.
>      >>
>      >>       Thanks
>      >>       Raju
>      >>
>      >>       -----Original Message-----
>      >>       From: mmusic <mmusic-bounces@ietf.org> On Behalf Of Jose M Recio
>      >>       Sent: Tuesday, July 9, 2019 8:23 AM
>      >>       To: mmusic@ietf.org
>      >>       Subject: Re: [MMUSIC] I-D Action:
>      >> draft-ietf-mmusic-msrp-usage-data-channel-11.txt
>      >>
>      >>
>      >>       On 9/7/19 10:57 AM, Makaraju, Raju (Nokia - US/Naperville) wrote:
>      >>       > Do we need to make any further clarifications for the references to CEMA?
>      >>       > Section 5.1.1.2 has a sentence that is a little awkward, but seems to be saying the CEMA is out of scope.
>      >>
>      >>       [JM] Draft covers either direct connection to an endpoint or direct connection to a gateway. As middleboxes are out of scope in the connection using data channel, then CEMA is out of scope. This short explanation currently appears as justification for saying that CEMA is out of scope. I can remove the explanation and just state that CEMA is out of scope.
>      >>
>      >>       > But in section 6 for gateway function it mentions CEMA can be used.
>      >>
>      >>       [JM] Draft supports gateways providing transport level interworking between MSRP endpoints using different transport protocols. CEMA can't be used towards the endpoints using data channel transport, but the GW could use CEMA to interwork with endpoints using other protocols.
>      >>
>      >>       For example, if the GW is implemented on an SBC, it can use CEMA towars the inside network, using a non-dc transport. But not towards endpoints using data channel transport.
>      >>
>      >>       > My understanding is I think section 6 suggests to use CEMA equivalent procedures without CEMA attributes!
>      >>
>      >>       [JM] GW can use CEMA with endpoints using non-dc transports. This can be removed, but I think it would make the GW transport interwork option too restrictive. The B2BUA GW would not be affected.
>      >>
>      >>       > Also, in section 6 should we add a further statement that the gateway assumes one MSRP data channel instance and one sub-protocol per SIP dialog as RCS mandates that a single SIP session/dialog has only one MSRP m= line?
>      >>       >
>      >>       [JM] I agree for RCS should be like that. Would mandating this restrict applicability for other applications?
>      >>
>      >>       > Thanks
>      >>       > Raju
>      >>       >
>      >>       >
>      >>       > -----Original Message-----
>      >>       > From: mmusic <mmusic-bounces@ietf.org> On Behalf Of
>      >>       > internet-drafts@ietf.org
>      >>       > Sent: Saturday, June 1, 2019 11:22 PM
>      >>       > To: i-d-announce@ietf.org
>      >>       > Cc: mmusic@ietf.org
>      >>       > Subject: [MMUSIC] I-D Action:
>      >>       > draft-ietf-mmusic-msrp-usage-data-channel-11.txt
>      >>       >
>      >>       >
>      >>       > A New Internet-Draft is available from the on-line Internet-Drafts directories.
>      >>       > This draft is a work item of the Multiparty Multimedia Session Control WG of the IETF.
>      >>       >
>      >>       >          Title           : MSRP over Data Channels
>      >>       >          Authors         : Keith Drage
>      >>       >                            Maridi R. Makaraju (Raju)
>      >>       >                            Juergen Stoetzer-Bradler
>      >>       >                            Richard Ejzak
>      >>       >                            Jerome Marcon
>      >>       >                            Jose M. Recio
>      >>       > 	Filename        : draft-ietf-mmusic-msrp-usage-data-channel-11.txt
>      >>       > 	Pages           : 19
>      >>       > 	Date            : 2019-06-01
>      >>       >
>      >>       > Abstract:
>      >>       >     This document specifies how the Message Session Relay Protocol (MSRP)
>      >>       >     can be instantiated as a data channel sub-protocol, using the SDP
>      >>       >     offer/answer exchange-based generic data channel negotiation
>      >>       >     framework.  Two network configurations are documented: a WebRTC end-
>      >>       >     to-end configuration (connecting two MSRP over data channel
>      >>       >     endpoints), and a gateway configuration (connecting an MSRP over data
>      >>       >     channel endpoint with an MSRP over TCP or TLS endpoint).
>      >>       >
>      >>       >
>      >>       > The IETF datatracker status page for this draft is:
>      >>       > https://datatracker.ietf.org/doc/draft-ietf-mmusic-msrp-usage-data-cha
>      >>       > nnel/
>      >>       >
>      >>       > There are also htmlized versions available at:
>      >>       > https://tools.ietf.org/html/draft-ietf-mmusic-msrp-usage-data-channel-
>      >>       > 11
>      >>       > https://datatracker.ietf.org/doc/html/draft-ietf-mmusic-msrp-usage-dat
>      >>       > a-channel-11
>      >>       >
>      >>       > A diff from the previous version is available at:
>      >>       > https://www.ietf.org/rfcdiff?url2=draft-ietf-mmusic-msrp-usage-data-ch
>      >>       > annel-11
>      >>       >
>      >>       >
>      >>       > Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org.
>      >>       >
>      >>       > Internet-Drafts are also available by anonymous FTP at:
>      >>       > ftp://ftp.ietf.org/internet-drafts/
>      >>       >
>      >>       > _______________________________________________
>      >>       > 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
>      >>
>      >>       _______________________________________________
>      >>       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
>      >>
>      >>
>      
>      
>