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

Christer Holmberg <christer.holmberg@ericsson.com> Sun, 10 May 2020 13:29 UTC

Return-Path: <christer.holmberg@ericsson.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 0C2DA3A0982 for <mmusic@ietfa.amsl.com>; Sun, 10 May 2020 06:29:15 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.101
X-Spam-Level:
X-Spam-Status: No, score=-2.101 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.001, 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_H2=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=ericsson.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 S5BFAvWq4k-9 for <mmusic@ietfa.amsl.com>; Sun, 10 May 2020 06:29:12 -0700 (PDT)
Received: from EUR04-HE1-obe.outbound.protection.outlook.com (mail-eopbgr70047.outbound.protection.outlook.com [40.107.7.47]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B06473A097E for <mmusic@ietf.org>; Sun, 10 May 2020 06:29:11 -0700 (PDT)
ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=fngZ/tC4Uv5mZaNTmnOwNnSFqeA1ior11OK0k00N5wUeoN0GZ+kTQtY54C3zqnnfrXVSgB4I51N6mnmGj+sOm1fv5aQOC96ooVdOUd0BZDrUWnVefykblY65TWUv2qc2JYTsEnHUVfCqZIxzASSwBLU1oTYj40DXMMSZK0EeMDBmDESxIHbcAnVbJst7L1wsf+dAKriz8inDv6Gpa9WXppeHAXLIT45gNC7SktFrt3vGQeiv9tm46UsYVLO9jxJ0E5nimPqx+qGFuTlpW2jX7WQ5Z++NHh3is7UGigXVXDkQVktUyvoYx6dHhZaxr5toNzUA2CwXkdSWvEQBfVOI4g==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=FwC9p4h17m7iCAbS8dAa04pHfD1/eyLk8TMRMZPXlqM=; b=AQ9Mwsv0e0ZvGidLoOqm4leGuT1Pax/rkSs7+o+gxngUpQ1iY/QjS8pkK3O/pzF0U6dn2f4bBHDaxivKQgbfWBv9MZfzJ4eQxJnexREzUzMLIkLZ87Z7349ZbR3HuejN7Z2pMd8cm5pKsNZQuC65nAaoVA8hxJSASF5cTsVmr6xv/WQaYZXIpAMQidh/tDHMjQSgvdNolvAyJ/BHZCOI23Pb2UJnuBg5fn0lLT5K4kurtjTUjeoSONLc7M5X/w8ZKpbf0zLKZAi2eybhm4UwymXQ4i1gKMuh8qMuBZKvZzVAfB3D/W1aHxFp4w/E8cmNufuRlnjC9iISmDTB8HlNkw==
ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=ericsson.com; dmarc=pass action=none header.from=ericsson.com; dkim=pass header.d=ericsson.com; arc=none
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ericsson.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=FwC9p4h17m7iCAbS8dAa04pHfD1/eyLk8TMRMZPXlqM=; b=nypaVomKwMGE/uKrO3ymdXWZI8RznQbsSGrLf9aSYwV1mEwlOVcqaf6J4n88fAOfbv2B/FVrv6E5SV3oADytf3EOpHD0PgqDJCj49QQCT/zOOoeP5I0dZJOYhNmBUQ3jZZEbFq6+ALzMucXTtXmB1VcKc39Y42pMgAb1oC3cZJQ=
Received: from AM7PR07MB7012.eurprd07.prod.outlook.com (2603:10a6:20b:1bc::19) by AM7PR07MB6771.eurprd07.prod.outlook.com (2603:10a6:20b:1bd::21) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3000.14; Sun, 10 May 2020 13:29:07 +0000
Received: from AM7PR07MB7012.eurprd07.prod.outlook.com ([fe80::7529:b51f:5fb4:62b9]) by AM7PR07MB7012.eurprd07.prod.outlook.com ([fe80::7529:b51f:5fb4:62b9%5]) with mapi id 15.20.3000.016; Sun, 10 May 2020 13:29:07 +0000
From: Christer Holmberg <christer.holmberg@ericsson.com>
To: Jose M Recio <jose@ch3m4.com>, "mmusic@ietf.org" <mmusic@ietf.org>
Thread-Topic: [MMUSIC] WGLC on draft-ietf-mmusic-msrp-usage-data-channel-16
Thread-Index: AdYjuWxe8jgvP3HuS5indZrl5qmwswAz05MAAA2vHYAAdPeWgAAO04pa
Date: Sun, 10 May 2020 13:29:07 +0000
Message-ID: <AM7PR07MB7012D222A4AF5FD13FCC8C3793A00@AM7PR07MB7012.eurprd07.prod.outlook.com>
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>
In-Reply-To: <ef5b4ef8-4063-e38e-d300-185a933cc3dc@ch3m4.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
authentication-results: ch3m4.com; dkim=none (message not signed) header.d=none;ch3m4.com; dmarc=none action=none header.from=ericsson.com;
x-originating-ip: [188.127.223.154]
x-ms-publictraffictype: Email
x-ms-office365-filtering-correlation-id: 01cd9a03-5c42-40e5-06b4-08d7f4e61de2
x-ms-traffictypediagnostic: AM7PR07MB6771:
x-microsoft-antispam-prvs: <AM7PR07MB67710529179BC40526EA1EB593A00@AM7PR07MB6771.eurprd07.prod.outlook.com>
x-ms-oob-tlc-oobclassifiers: OLM:9508;
x-forefront-prvs: 039975700A
x-ms-exchange-senderadcheck: 1
x-microsoft-antispam: BCL:0;
x-microsoft-antispam-message-info: P/veQJ3tGH7MbZx2qmDOqE+H6pbzQMefhQcnvNa7Pn6qEgoXeSkSbGpl4PYFE0olkOWPlYS4lU6deo+GDF9DxestYRdxDeWmnuE37+P5kHVz9QeAgGiv0rcvhsyIbuwhpTUk4MxHsuHlD7ZKnl8iIyPkG60WSK5B/nVS8/1Lf34FcV36E/X5KXJ72VcbBf8XKR8jiX10j/5U7Uxg0HF4koGh9qJhYQJBwowE/QEDTDGfi33geNDDENLNh1rWt2S7pdeX3YzXtM+dH+NZzm8rS8Uzo0FCU6UQXx0TsEjvMA7+sGEmnAHPfseql2gT7NXvyhYRVgJo9Jc/j3lmOx10wFX+yU+jM45E14PXhUM2HqUD6Nl5ho13hHxxB6QHdVa03LB48XfVoSd7eJMX2qkOnbJxq9cCsWtOYRHkvkUvLQ2V5JxUS7OUICm0pY5iKesLja5MSSOPv92Lv01F7mjnAatvJ4Na8kmWuadPZyHoSIOjwQO1kjKAevk1QXE9FqxFwcN8fGBXxIKULFCOURwj/h4ycrl+E7Vp8MLi0lH4tm9E6c3bOgDbUwAwhMLynjeDYN9nykKfi9Y/itYmHHR8yj4jsi9nJ+c1j4S2dKRmpaM=
x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:AM7PR07MB7012.eurprd07.prod.outlook.com; PTR:; CAT:NONE; SFTY:; SFS:(4636009)(136003)(396003)(366004)(376002)(39860400002)(346002)(33430700001)(55016002)(19627405001)(9686003)(8676002)(110136005)(71200400001)(44832011)(6506007)(33656002)(7696005)(166002)(316002)(33440700001)(5660300002)(53546011)(186003)(26005)(966005)(8936002)(66476007)(52536014)(478600001)(76116006)(66946007)(66446008)(66556008)(86362001)(2906002)(64756008); DIR:OUT; SFP:1101;
x-ms-exchange-antispam-messagedata: 1c55y5Uvd0YRd9uX9gUSH6vAuI7TWXe+M8jiQr78Ja1SmLBBlbFMo5QVj4DuejQB8LnA9LeY1B2QN8ldOWNHy0ekqoQpB0iUVUtUEuQZGAXld06yzJoWf7TAgYArw/ehgDgNbSQriJhz1sYh87mCxP+8kSjp3oA/Vhynd/6H1X/4A+QDo9UIZto+BFdqOcUN8qYbnsQmZkdtqgWlfp7LIGxEFNcsJXXfEkkJ28ppbjcfADjdoHfddC+V995ON+LWPoFu4AF5ks/c7XGrwz4ciFmCOjeNfjVNfT9IfAUE1/tno0KVD8ZcsdxdYSTlbetOTQBFz00anFqkPVXSRPxZm3M1YdJSQsrw51VhqV8ezsuzBxesph0zt+AtAAHjN5ry7O0dj9udgc7yoVoaap7idu7vZssXy54pjLt4x1lykDYdIXvyJJnUAwvAnst15JQya6vv12pFRSOFt5IEv1nbwRgSA9n1XLieR/KeFZhO7/WMtAISuhVvW02Mtk0BcJF2
x-ms-exchange-transport-forked: True
Content-Type: multipart/alternative; boundary="_000_AM7PR07MB7012D222A4AF5FD13FCC8C3793A00AM7PR07MB7012eurp_"
MIME-Version: 1.0
X-OriginatorOrg: ericsson.com
X-MS-Exchange-CrossTenant-Network-Message-Id: 01cd9a03-5c42-40e5-06b4-08d7f4e61de2
X-MS-Exchange-CrossTenant-originalarrivaltime: 10 May 2020 13:29:07.5718 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 92e84ceb-fbfd-47ab-be52-080c6b87953f
X-MS-Exchange-CrossTenant-mailboxtype: HOSTED
X-MS-Exchange-CrossTenant-userprincipalname: DwEGzqZdCqQiXaSmY29UEElMHnue1XmpJKYdmAxYvkZ547QWHxZbuastfUDA1g5KiY3oKi5VLnqN+fCQODOpu+uppqHBGFBT/IvqlF8H4mo=
X-MS-Exchange-Transport-CrossTenantHeadersStamped: AM7PR07MB6771
Archived-At: <https://mailarchive.ietf.org/arch/msg/mmusic/MBcEeXxZigv_CU0Xsj_rH5o2Wx4>
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 13:29:15 -0000

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