Re: [MMUSIC] WGLC on draft-ietf-mmusic-msrp-usage-data-channel-16

Jose M Recio <jose@ch3m4.com> Sun, 10 May 2020 06:22 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 7B4123A00D8 for <mmusic@ietfa.amsl.com>; Sat, 9 May 2020 23:22:25 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.098
X-Spam-Level:
X-Spam-Status: No, score=-2.098 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=0.001, 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=dInChyCa; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=gK5W6mI7
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 5hDjlsiRFt-7 for <mmusic@ietfa.amsl.com>; Sat, 9 May 2020 23:22:22 -0700 (PDT)
Received: from out5-smtp.messagingengine.com (out5-smtp.messagingengine.com [66.111.4.29]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 09A173A00D3 for <mmusic@ietf.org>; Sat, 9 May 2020 23:22:21 -0700 (PDT)
Received: from compute4.internal (compute4.nyi.internal [10.202.2.44]) by mailout.nyi.internal (Postfix) with ESMTP id 525FE5C0077 for <mmusic@ietf.org>; Sun, 10 May 2020 02:22:21 -0400 (EDT)
Received: from mailfrontend2 ([10.202.2.163]) by compute4.internal (MEProxy); Sun, 10 May 2020 02:22:21 -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=t kQlXhrOgaJXFkLUZF9uhC9YG1sbVi64ZREgJnqP/ns=; b=dInChyCaSJtR3jWUS eS2UecifIrPxv8r1Mqg4uHcqvIrNtIq9cnQu5+sQ7eN9WULT9nU4mS159K14oJEm /4Zt0baSaVbkTabvJBOnD7mWJ1TDV9fxo8uH98aoykrhVJokmENY5FEupzme0Oov TOtCzFwGofY4r9Km7VvMXO3qzeivvbS7nhSkEkCadhuqJt7LyUdHGxOCZ4wQ9Yuf IqOvAlg3ySWSoEgY0agybU3zXtsdvX37G4b2WWoHZggLDLSUGx2xK3zFvwLA8fQb /E8oOD3ZM624zQZqIkujOkde8k6KGwPYimZsaHF3zyxv8hpxKFqDcRrlAC07XtjL juf1Q==
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=tkQlXhrOgaJXFkLUZF9uhC9YG1sbVi64ZREgJnqP/ ns=; b=gK5W6mI728sdq6qhKpRIkS0PkFJA5g4Zg2aWvDFBsa3ks5Xmb774ph/ta K6aG/prUrOOMs8Nm1uoF4mXIdSX4+j0iazrphhcMkjTbSX6j6ji6KqniJhrp/gXp Fw6/T5KBfD/K7vI+8yx3C8jJHKE1yfHo0we3fCHZH0JgDa51ugp29+nmfc/2/YHE C5/lUqxzhwqxIbRZ4VzczHaRBmULA9XhnS9hvH2jvCIbv+fYK6+tVqlVkS/Vcd2+ Hg3swHxfC+G1TNoksavukYNqNPnCSxFOHs+YZ0a8+Y8TMq7WtdyeAZu3oVTqGCsj FaPHMo3Yh/RMsApnHWcw8X1TcAGSg==
X-ME-Sender: <xms:nJ23Xi1wDSrpvAZIS1iDF9ApEAZ00ftZeJSTs4K6WowwioBIrXEl-Q>
X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgeduhedrkeejgdduvdcutefuodetggdotefrodftvf curfhrohhfihhlvgemucfhrghsthforghilhdpqfgfvfdpuffrtefokffrpgfnqfghnecu uegrihhlohhuthemuceftddtnecunecujfgurhepuffvfhfhkffffgggjggtgfesthejre dttdefjeenucfhrhhomheplfhoshgvucfoucftvggtihhouceojhhoshgvsegthhefmheg rdgtohhmqeenucggtffrrghtthgvrhhnpeeljeekkeeuffeiueegjefhffehkeehuefgtd euheegleekveegieevleegudekudenucffohhmrghinhepihgvthhfrdhorhhgpdhgihht hhhusgdrtghomhenucfkphepvdejrddutdegrddugeefrddvtdegnecuvehluhhsthgvrh fuihiivgeptdenucfrrghrrghmpehmrghilhhfrhhomhepjhhoshgvsegthhefmhegrdgt ohhm
X-ME-Proxy: <xmx:nJ23XsoAj8CALjFf5yhfYBjAgHi83hN81cS5Hu4g07VYCnK3Rj6-0A> <xmx:nJ23Xqjce3gOasnxpjY5T4QCo0qTJehm5FigwLN0MnV1FqiSrEWMsg> <xmx:nJ23XglDj2NoIfiTylZ_jsTp-qHWagcNWUgeS7WgNhPzW_WQqW1g3g> <xmx:nZ23Xu6xFuNSvOxYqEmsulGE_yv6_bktB_IICnPWj_JOhoq2lqz8Ag>
Received: from [192.168.0.102] (unknown [27.104.143.204]) by mail.messagingengine.com (Postfix) with ESMTPA id 0BFDB3066259 for <mmusic@ietf.org>; Sun, 10 May 2020 02:22:19 -0400 (EDT)
To: mmusic@ietf.org
References: <HE1PR07MB4426ADA1E4B1D696A48BA9A98DA40@HE1PR07MB4426.eurprd07.prod.outlook.com> <66bc33b6-8a66-1da3-93c0-e7ddc31cc605@alum.mit.edu> <2F549E6E-1250-426F-8602-99CB44C84365@ericsson.com>
From: Jose M Recio <jose@ch3m4.com>
Message-ID: <ef5b4ef8-4063-e38e-d300-185a933cc3dc@ch3m4.com>
Date: Sun, 10 May 2020 14:22:09 +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: <2F549E6E-1250-426F-8602-99CB44C84365@ericsson.com>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 7bit
Content-Language: en-US
Archived-At: <https://mailarchive.ietf.org/arch/msg/mmusic/ydNtOpjx41PPbhlaEFZjrg12kwA>
Subject: Re: [MMUSIC] WGLC on draft-ietf-mmusic-msrp-usage-data-channel-16
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: Sun, 10 May 2020 06:22:27 -0000

About #5, as Christer comments, path is not to be used for transport 
negotiation or routing over the data channel. But path is still used by 
MSRP endpoints for a number of procedures, and can be negotiated as 
specified in 4.4

Underlying all this are historical reasons: original MSRP used path used 
to negotiate tranport, but that created problems, so CEMA 
(https://tools.ietf.org/html/rfc6714) was specified, but keeping path 
for other uses.

Previous draft versions included wording about CEMA, but that was found 
very confusing, so agreement was to concisely state that path is not to 
be used for routing or transport negotiation, implicitly assuming 
implementors would know that path can still be included and used for 
other purposes.

We could even simplify Christer's suggestion:

"The path attribute SHALL NOT be used for transport negotiation. MSRP 
endpoints communicating over a data channel can specify and use path 
attribute for other purposes, as specified by RFC4975."

If that is still confusing, I will take Christer wording.

All other changes in 
https://github.com/josemrecio/draft-msrp-data-channel/pull/13, I have 
also updated the examples.


On 08/05/20 03:33, Christer Holmberg wrote:
> Hi Paul,
>
> Thank You for the comments! Please see inline.
>
> ---
>      
>>     1) NIT:
>>     
>>     In Section 3.1, in the table, the value for Label has a lot of white
>>     space between "See" and "Section 4.3". It would look better with a
>>     single space.
>    
> That's a bug. Will be fixed.
>
> ---
>
>>     2) MINOR ISSUE:
>>     
>>     In section 4.1, the abnf says:
>>     
>>         transport  /= "dc" / 1*ALPHANUM
>>     
>>     The /= means this is an added alternative to what is present in RFC4975.
>>     Hence it is equivalent to:
>>     
>>         transport = "tcp" / 1*ALPHANUM / "dc" / 1*ALPHANUM
>>     
>>     What you should really have is just:
>>     
>>         transport  /= "dc"
>   
> Will modify as suggested.
>
> ---
>
>>     3) NIT:
>>     
>>     Section 4.4 says:
>>     
>>         An offerer and answerer MUST include a dcsa attribute for the
>>         following MSRP-specific SDP attributes:
>>     
>>     I suggest: s/for the/for each of the/
> Will modify as suggested.
>      
>>     Similarly, where it says:
>>     
>>         An offerer and answerer MAY include a dcsa attribute for the
>>     
>>     I suggest: s/for the/for any of the/
>    
> Will modify as suggested.
>
> ---
>    
>>     4) QUESTION:
>>     
>>     Does section 4.6 this mean it is an error to use SDP to close the
>>     DTLS/SCTP association (via m=0) without all the added SDP attributes to
>>     close each data channel?
>>
>>     Could it not be implied that closing the association implicitly closes
>>     all the data channels?
>    
> The procedures follow what is defined in Section 6.6.1 of draft-ietf-mmusic-data-channel-sdpneg.
>
> Whether closing the SCTP association, without explicitly closing the data channel(s) first, is an "error", or just "something one should not do",  I think should have been specified in draft-ietf-mmusic-data-channel-sdpneg.
>
> ---
>
>>     5) QUESTION:
>>     
>>     The example in section 4.8 includes use of the "path" attribute. How
>>     does that square with the following in section 4.4:
>>     
>>         The path attribute SHALL NOT be used for transport negotiation.
>>     
>>     I guess you mean that some usages of path are ok and others are not.
>>     Could you be more explicit about this?
> I have got the same questions from others too, so I guess it needs to be clarified.
>
> As the MSRP messages will be "routed" on the established data channel, the path attribute won't be used for routing.
>
> Maybe something like this:
>
> "When MSRP messages are transported on a data channel, the "path" attribute is not used for routing of the messages. Because of that an MSRP endpoint
> can set the MSRP-URI authority value of the "path" attribute at its own discretion. However, when an MSRP endpoint receives an MSRP message on
> a data channel it MUST still check the MSRP-URI in the To-Path of the MSRP message, as described in [RFC4975]."
>
> ---
>
>>     6) ISSUE:
>>     
>>     Section 7.1 registers "MSRP" as if it was a totally new websocket
>>     protocol name, but it isn't. It is already registered as a websocket
>>     protocol referencing RFC7977.
> True.
>
> That shows for how long we have been working on this document, because when we started RFC 7977 didn't exist...
>
>>     I think you instead need to specify that the existing registration be updated.
> Something like:
>
> 7.1.  Subprotocol Identifier MSRP
>
>     NOTE to RFC Editor: Please replace "XXXX" with the number of this
>     RFC.
>
>     This document adds a reference to RFC XXXX for the subprotocol identifier "msrp" in
>     the "WebSocket Subprotocol Name Registry".
>
> ---
>
> Regards,
>
> Christer
>
>
>   
>
> _______________________________________________
> mmusic mailing list
> mmusic@ietf.org
> https://www.ietf.org/mailman/listinfo/mmusic