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

Jose M Recio <jose@ch3m4.com> Tue, 12 May 2020 07:58 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 2F0BF3A0CBA for <mmusic@ietfa.amsl.com>; Tue, 12 May 2020 00:58:51 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.097
X-Spam-Level:
X-Spam-Status: No, score=-2.097 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, HTML_MESSAGE=0.001, 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=PSDnUqTX; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=Dt84BfbV
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 08FgsY3MnSoa for <mmusic@ietfa.amsl.com>; Tue, 12 May 2020 00:58:49 -0700 (PDT)
Received: from out1-smtp.messagingengine.com (out1-smtp.messagingengine.com [66.111.4.25]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0E5B63A0CB9 for <mmusic@ietf.org>; Tue, 12 May 2020 00:58:48 -0700 (PDT)
Received: from compute4.internal (compute4.nyi.internal [10.202.2.44]) by mailout.nyi.internal (Postfix) with ESMTP id 0B8825C0166; Tue, 12 May 2020 03:58:48 -0400 (EDT)
Received: from mailfrontend1 ([10.202.2.162]) by compute4.internal (MEProxy); Tue, 12 May 2020 03:58:48 -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; s=fm3; bh=NO28CqRyS4nmUz4WzIndtJispjO YxsoJ/aBR2HEULCU=; b=PSDnUqTXc2Znz9SdTO7Vm624rtvH+RCW7lS5KIzXLZo t1J6ONcc2uGBjlmvA7I95zhitn+qJRR/uq7fCy/Ust/1CWv3udlsKeOf/KVJs3xU MwQ/D4Uj2siyTAveZXukJjehZ6l1tmggsdYbp15JoZ3cG5bYzs6Pq3srL45yaiZU IbFZxKE+JVgNB3vNLxoHjJN8xf8rrIlgJY/bcH6CQUADyZDxE3QRFCstF/mTS3kg 937t5zCsIatn542r0GqJMEkLYjNmSXdhEjgNRC/egkTwI9wgMUw2ua5Lhuo6XfKO XwSWaLprvrm06nDehLmXo+TcQgWyTEtZ+RcbQCrJlHQ==
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=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=NO28Cq RyS4nmUz4WzIndtJispjOYxsoJ/aBR2HEULCU=; b=Dt84BfbVkZs7RyAYLacRX5 RRrjeZymKfAg86Te0qz4Pso3YfeoWWXohND1mUI9o8om2tQ6sfVUqYdp6+31uaRJ Ryi2ZJrBct7A/KuK5xFPNbe/jWM9976O4hp9p+rIwjeL1R0CVod6JAcJZYTSniUi I/Zb41wxvemDbaSKh5LN3ukeRHb0ZuSxReYp4eb5sqqhBY5kuy+20JlSttl0bThq P26LpZvfeLvILkQEK43h2AcyJzbX2RLFt4tc+QV3NisMkHZ2ZFWL7RsOCyaCGAve ZwqJWfJ3R+B6TqY3Ra+LJ6ybziKSknzN5Kkd5jmWuyCMXmBnlRWF36dkA4YZFxXA ==
X-ME-Sender: <xms:N1e6XjtboWby5Fz7O12b5DErcyzpHiyBjWPP2MUB28hhl95pFSPWMQ>
X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgeduhedrledugdduvdehucetufdoteggodetrfdotf fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfqfgfvpdfurfetoffkrfgpnffqhgen uceurghilhhouhhtmecufedttdenucesvcftvggtihhpihgvnhhtshculddquddttddmne cujfgurhepuffvfhfhkffffgggjggtsegrtderredtfeehnecuhfhrohhmpeflohhsvgcu ofcutfgvtghiohcuoehjohhsvgestghhfehmgedrtghomheqnecuggftrfgrthhtvghrnh epveelgffhveduudeggfejgefgudefheefteetueegledtfeffudejgffhhfeffedunecu ffhomhgrihhnpehivghtfhdrohhrghenucfkphepvdejrddutdegrddugeefrddvtdegne cuvehluhhsthgvrhfuihiivgeptdenucfrrghrrghmpehmrghilhhfrhhomhepjhhoshgv segthhefmhegrdgtohhm
X-ME-Proxy: <xmx:N1e6Xkf2BDchN487IfocZZkAnbNW3IwPPbZDEmFbM4FjGOwKgQQaSA> <xmx:N1e6Xmz-NHXXt6oKRdBcxPCTy-mt6dzKFV4eGNw3w4oJkgDpZfH72A> <xmx:N1e6XiPImPwKo2mRCjCGu75G9SwmGHC556nuEvjrxsKgOUh0cP3xpA> <xmx:OFe6XmLSTdNq9U3xKvU33frQDF_2z93Zh6ELpDRFelTUevgjzEi1mQ>
Received: from [192.168.0.102] (unknown [27.104.143.204]) by mail.messagingengine.com (Postfix) with ESMTPA id 59DEB3280063; Tue, 12 May 2020 03:58:46 -0400 (EDT)
To: Christer Holmberg <christer.holmberg@ericsson.com>, "mmusic@ietf.org" <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> <ef5b4ef8-4063-e38e-d300-185a933cc3dc@ch3m4.com> <AM7PR07MB7012D222A4AF5FD13FCC8C3793A00@AM7PR07MB7012.eurprd07.prod.outlook.com>
From: Jose M Recio <jose@ch3m4.com>
Message-ID: <a3210a85-e69d-2bfc-a802-7649c70a6534@ch3m4.com>
Date: Tue, 12 May 2020 15:58:44 +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: <AM7PR07MB7012D222A4AF5FD13FCC8C3793A00@AM7PR07MB7012.eurprd07.prod.outlook.com>
Content-Type: multipart/alternative; boundary="------------8915A4FCB4C3A71EC12430DB"
Content-Language: en-US
Archived-At: <https://mailarchive.ietf.org/arch/msg/mmusic/HduI3wZTlkhk1TWgFr9ihrUV2oY>
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: Tue, 12 May 2020 07:58:51 -0000

Agreed, my worry was not being concise enough.


On 10/05/20 21:29, Christer Holmberg wrote:
> Hi,
>
> ...
>
> >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.
>
> I would prefer my solution (I have no problem if it can be simplfied), 
> because the problem with "SHALL NOT" is that you CAN NOT use the path 
> for routing - even if you wanted to :)
>
> Usage of the path for routing is simply not defined when using a data 
> channel (as the MSRP messages will be sent over the data channel).
>
> Regards,
>
> Christer
>
>
>
> 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
>
> _______________________________________________
> mmusic mailing list
> mmusic@ietf.org
> https://www.ietf.org/mailman/listinfo/mmusic