Re: [MMUSIC] AD Evaluation of draft-ietf-mmusic-data-channel-sdpneg-20

Bo Burman <bo.burman@ericsson.com> Fri, 14 December 2018 14:32 UTC

Return-Path: <bo.burman@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 75D66124BE5 for <mmusic@ietfa.amsl.com>; Fri, 14 Dec 2018 06:32:29 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -5.76
X-Spam-Level:
X-Spam-Status: No, score=-5.76 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-1.46, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_MED=-2.3, 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 header.b=Ck76b+5g; dkim=pass (1024-bit key) header.d=ericsson.com header.b=WtN+/kQ1
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 S2_yI91ewCIw for <mmusic@ietfa.amsl.com>; Fri, 14 Dec 2018 06:32:26 -0800 (PST)
Received: from sessmg23.ericsson.net (sessmg23.ericsson.net [193.180.251.45]) (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 02458127133 for <mmusic@ietf.org>; Fri, 14 Dec 2018 06:32:25 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; d=ericsson.com; s=mailgw201801; c=relaxed/simple; q=dns/txt; i=@ericsson.com; t=1544797944; x=1547389944; h=From:Sender:Reply-To:Subject:Date:Message-ID:To:CC:MIME-Version:Content-Type: Content-Transfer-Encoding:Content-ID:Content-Description:Resent-Date:Resent-From: Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:In-Reply-To:References:List-Id: List-Help:List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive; bh=m5iDvhWmeYoYDotySy7Qt6M6jNXxqMFtj8zIVg9Yv88=; b=Ck76b+5gPM863BAl3vHJ622hAi6B2+QSNuBjm5OySJ1heTFlFr8rzPrYS7LqaEL3 ex4kDJyHFW5Qk5BdXACcw0AWfWRSclGkT4js/+vgLdsTpAQTmPd/bxmXZRSMUgq4 BOK1OxZUkGaLZnA5RDhksgJkvLI+HzRrIxEsk1p77Vg=;
X-AuditID: c1b4fb2d-d9dff7000000062f-3d-5c13bef89929
Received: from ESESSMB501.ericsson.se (Unknown_Domain [153.88.183.119]) by sessmg23.ericsson.net (Symantec Mail Security) with SMTP id D4.D7.01583.8FEB31C5; Fri, 14 Dec 2018 15:32:24 +0100 (CET)
Received: from ESESSMB502.ericsson.se (153.88.183.163) by ESESSMB501.ericsson.se (153.88.183.162) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1466.3; Fri, 14 Dec 2018 15:32:23 +0100
Received: from EUR03-DB5-obe.outbound.protection.outlook.com (153.88.183.157) by ESESSMB502.ericsson.se (153.88.183.163) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1466.3 via Frontend Transport; Fri, 14 Dec 2018 15:32:23 +0100
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=m5iDvhWmeYoYDotySy7Qt6M6jNXxqMFtj8zIVg9Yv88=; b=WtN+/kQ1tiP1nRY/ZEcJWFZKWy274tpzi4FEtY6JQpe9ogv7AFKhAPkiMd9shpw3EJfxPtLWBGjFlocYRrViJbKGr3TBgswiKGnCYPdOnxEFJOszhGDxnnPgkKQ6r25YnrWpjCRh8/CglhZ0SgOjq6weNS6RNDtVhn+ZgwRuwv0=
Received: from HE1PR07MB3259.eurprd07.prod.outlook.com (10.170.246.26) by HE1PR07MB4379.eurprd07.prod.outlook.com (20.176.167.28) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.1446.9; Fri, 14 Dec 2018 14:32:22 +0000
Received: from HE1PR07MB3259.eurprd07.prod.outlook.com ([fe80::14f3:1aae:ebb4:b875]) by HE1PR07MB3259.eurprd07.prod.outlook.com ([fe80::14f3:1aae:ebb4:b875%3]) with mapi id 15.20.1425.021; Fri, 14 Dec 2018 14:32:22 +0000
From: Bo Burman <bo.burman@ericsson.com>
To: Ben Campbell <ben@nostrum.com>, "Roni Even (A)" <roni.even@huawei.com>
CC: Paul Kyzivat <pkyzivat@alum.mit.edu>, "mmusic@ietf.org" <mmusic@ietf.org>
Thread-Topic: [MMUSIC] AD Evaluation of draft-ietf-mmusic-data-channel-sdpneg-20
Thread-Index: AQHUhdftNI4iq3W1C0ujfR8J7MoMZaVkBooAgAA1owCADsqsoIAGYbtwgAB4sgCABIZx8A==
Date: Fri, 14 Dec 2018 14:32:22 +0000
Message-ID: <HE1PR07MB3259FAE35515639B4661793A8DA10@HE1PR07MB3259.eurprd07.prod.outlook.com>
References: <E028869C-2FE4-44D1-985B-7B3FD58D352A@nostrum.com> <C454212D-B8FF-4E21-B6ED-67EB6BB96A88@nostrum.com> <1eb405ee-e9ab-d428-a472-7cad77ecfacc@alum.mit.edu> <1830A336-9C4A-4ACD-8988-681AE7F6F095@nostrum.com> <HE1PR07MB3259F2F781B584F67059E33E8DAA0@HE1PR07MB3259.eurprd07.prod.outlook.com> <6E58094ECC8D8344914996DAD28F1CCD18C90C8C@DGGEMM506-MBX.china.huawei.com> <35194BC6-3AC4-4D81-9ABF-F04437F1F754@nostrum.com>
In-Reply-To: <35194BC6-3AC4-4D81-9ABF-F04437F1F754@nostrum.com>
Accept-Language: sv-SE, en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
authentication-results: spf=none (sender IP is ) smtp.mailfrom=bo.burman@ericsson.com;
x-originating-ip: [192.176.1.94]
x-ms-publictraffictype: Email
x-microsoft-exchange-diagnostics: 1; HE1PR07MB4379; 6:db32xCPQQ86WshH8+VY78rmq44YE3kEtaXTS7a4LRsq+wVYNsQvEjp0P5kLB2pkywxPZJlKCEKQcr+0K3KPtuJwV57iSFWxsXLeFF7baElqF/CBsK62pmIrJJT2dLhezZO29gCTdjwns7SrIShjCbCCwTSeh58GlnoIZnI1syQfioleHHDyzY9rO+RWnKkhKMoBwWZqSH2E7j1Y1yp8AqPyxRXTL3vFcZ1Wjra9SdMJC0+2+XW25fzJ3o9dCT9rf0IMv6CklpTuOm+BbNYXiAW97rSgbOrx+MUi1iVQocUxZKDYfEC3RvTymdjVOjPEvEEwMsth0f95EVCrjZyWYB9+Y4/ppTouW4DSHLLY5G+hNZRLfinGE3rh5vPIzkMoiE6oGFaCNdQ/CTHmn4PmbvdKc4+IgsGOdQlaYuYfCfRndljOJ/7UifXmwuFzUrFqo4zoVMc2ctYJHJlcAz9hXCA==; 5:vrnF1LMu5MBUwsLqCGVniYTPrOQ/Ubux31Qa9mn7+IYAjufgkTFAMZwL3f5TUC0bMA+mZjDqyALASOPZLB/1uPXo37X0inF6lPjYHwWEjOVabb4G/NfwlRHsqYKYW5zTof4amvb/0MtpgIjNriwK6s1miIQVgePRY8Ua8vwFrGw=; 7:XAdEA2QEpNGohR/1VuYYS+Nd+kI7F8yHlNggi2xfcNE07kdNRPOkRF50d5gtnr7ipmbHBWqJ0UxkXS7J2GigCXWJqCgz/GdNJpd84cqQYYog+BQk+SdUWXT8VRdUaxccRPbQ8NzDw6GTY5UA7TQ4aQ==
x-ms-exchange-antispam-srfa-diagnostics: SOS;
x-ms-office365-filtering-correlation-id: 39f8d2c8-ace6-4b52-e542-08d661d0f59c
x-microsoft-antispam: BCL:0; PCL:0; RULEID:(2390118)(7020095)(4652040)(8989299)(4534185)(4627221)(201703031133081)(201702281549075)(8990200)(5600074)(711020)(2017052603328)(7153060)(7193020); SRVR:HE1PR07MB4379;
x-ms-traffictypediagnostic: HE1PR07MB4379:
x-microsoft-antispam-prvs: <HE1PR07MB4379ED34E1F3542DFC6D93238DA10@HE1PR07MB4379.eurprd07.prod.outlook.com>
x-ms-exchange-senderadcheck: 1
x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(8211001083)(3230021)(999002)(6040522)(2401047)(8121501046)(5005006)(3002001)(10201501046)(3231475)(944501520)(52105112)(93006095)(93001095)(148016)(149066)(150057)(6041310)(20161123558120)(201703131423095)(201702281528075)(20161123555045)(201703061421075)(201703061406153)(20161123560045)(20161123562045)(20161123564045)(201708071742011)(7699051)(76991095); SRVR:HE1PR07MB4379; BCL:0; PCL:0; RULEID:; SRVR:HE1PR07MB4379;
x-forefront-prvs: 08864C38AC
x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(346002)(136003)(376002)(366004)(396003)(39860400002)(13464003)(189003)(199004)(93886005)(105586002)(102836004)(446003)(966005)(8676002)(2906002)(66066001)(186003)(7696005)(5660300001)(6246003)(76176011)(33656002)(97736004)(86362001)(26005)(14454004)(11346002)(54906003)(44832011)(478600001)(476003)(305945005)(110136005)(71190400001)(81166006)(74316002)(6436002)(7736002)(68736007)(4326008)(6506007)(256004)(25786009)(9686003)(99286004)(229853002)(8936002)(81156014)(53936002)(53546011)(106356001)(14444005)(316002)(71200400001)(55016002)(6306002)(486006)(3846002)(6116002); DIR:OUT; SFP:1101; SCL:1; SRVR:HE1PR07MB4379; H:HE1PR07MB3259.eurprd07.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; MX:1; A:1;
received-spf: None (protection.outlook.com: ericsson.com does not designate permitted sender hosts)
x-microsoft-antispam-message-info: 4TyOT6G2b3+Syy28DU0a2VLr9QP7ThKaXnsfFiWqjm4fogpQeQigXCI88FjQT+Uc0Fk13x88PsKKhxEHSjaWRR6FIKAu22NMGjCroGRxu1ArwVKgBztYhrbYXxo44xpnbqoukPf4bwtMGNgoLGaTJAaAFxalyhbqHOIizt2JZIlVGn1tDejXdqbQgGxPdtz/eQPN7pTumHEmOEwPZnUV6xK6nZYqbWBQx5wpxiN6HJi/GVU5InXxu8is5uoaD/qksGTE+PJUhFPqH+IeYgVBttJsLEp0zGDMhzbC7OTDafqKtADk2qAJ0yZYG2X4tN99
spamdiagnosticoutput: 1:99
spamdiagnosticmetadata: NSPM
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
MIME-Version: 1.0
X-MS-Exchange-CrossTenant-Network-Message-Id: 39f8d2c8-ace6-4b52-e542-08d661d0f59c
X-MS-Exchange-CrossTenant-originalarrivaltime: 14 Dec 2018 14:32:22.0745 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 92e84ceb-fbfd-47ab-be52-080c6b87953f
X-MS-Exchange-Transport-CrossTenantHeadersStamped: HE1PR07MB4379
X-OriginatorOrg: ericsson.com
X-Brightmail-Tracker: H4sIAAAAAAAAA02Sa0hTYRjHec9lO2qj41R8MAybhCZ5L9oHsYtFMws0QzKUWnpQcU7ZWZr1 ZVR2cYVHm6DTmMFSU8oQb400W8MIkdmF8pKluaBlmoS0vNa2s6Bvv+f//N//874PL4WL9WQQ VaBUMyqlXCEReBP1J3vLIn8P+GXFdK4JpIYbw0JpbcssIW19NEhKfw5ZiX2EbP3HIia7Ypkn ZUbjMibTP7YRqcQp74RcRlFQyqiiE89459/TF5b0xJ8ft3CYBt2Mq0ReFNC7YLaqG69E3pSY tiAw1zsQX/xC8PT+AsEXRgxM2imhqyBoDofhL98wvlODgWVuzBPwGcEQ1064kgV0OBj6ppCL /ekjsNjYK3AxTh8De9MS7mI/Og0am5eEvOc4/GmYduqUkzNA98DHJRP0dlg197stIjoLOOuq gJ/VicNCd487x4veC5oPQ5iLER0MnxwfCX5WIEzYDBj/UhqMT6w4zwFgn90geX8m3K4eEfJ6 CFS8v0zyHAyvDVr3MoB+J4CrHTrENyJhsbbWE3QMHMvLJG8aRWDVrHlORwD3ts0zuRB0Ayse 3gptt2YI/sAYDpz+DeJQjP6/2+qdG8DpHdBhiublbaDTzgj17g34wst6G9GEiDYUwDIsW5QX Fx/FqApyWLZYGaVk1J3I+WOeda1G9qH2uf1mRFNIskl07aFflpiUl7LlRWYEFC7xF2VUOCVR rrz8AqMqPq06p2BYM9pCEZJA0ZrYN0tM58nVTCHDlDCqf12M8grSoIgw28F0n4JWzZ7iFnNv Q3ZVcNqs7+p82VkyRa4N6dptsoY6rvfj2sRXEy9SKpp6w+9mXoymNhKor+ujramXlNydzM0T J0zWHMfz9PFBadjkSnjd4kpoNTqUrK7Jjj3ac0A6Lx+brM7euSCbsR+u+96cFDI9SCbZh9eU ipHkWAnB5stjI3AVK/8LTZ7Cri0DAAA=
Archived-At: <https://mailarchive.ietf.org/arch/msg/mmusic/BSAt5xxse9mo7FHeJSQ_0SXT-jo>
Subject: Re: [MMUSIC] AD Evaluation of draft-ietf-mmusic-data-channel-sdpneg-20
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: Fri, 14 Dec 2018 14:32:29 -0000

Roni,

Please go ahead and make the changes suggested by Ben below and submit a new version at your earliest convenience.

Thanks
/Bo
MMUSIC co-chair

-----Original Message-----
From: Ben Campbell <ben@nostrum.com> 
Sent: den 11 december 2018 18:25
To: Roni Even (A) <roni.even@huawei.com>
Cc: Bo Burman <bo.burman@ericsson.com>; Paul Kyzivat <pkyzivat@alum.mit.edu>; mmusic@ietf.org
Subject: Re: [MMUSIC] AD Evaluation of draft-ietf-mmusic-data-channel-sdpneg-20

As a reminder, my concern was that the draft contains language that assumes a specification will exist. For example, §6 says:

"The detailed offer/answer procedures for the dcsa attribute are
   dependent on the associated sub-protocol.  A sub-protocol
   specification MUST define the offer/answer procedures for the dsca
   attribute (if applicable) associated with the sub-protocol."

If it is possible to register a data-channel sub-protocol without a spec, then the text that assumes a spec will exist needs to be revised. I understand the desire to share the websocket subprotocol registry, but the need for documented offer/answer procedures suggests that FCFS is not the right policy for data-channel subprotocols.

For the record, I would be okay with it if the wg decides to stick with FCFS, but the text would need to change in a few places to remove the assumptions that a spec would exist. We would, of course, have to accept the idea of a data-channel subprotocol with no documented offer/answer considerations. That might be okay if we allow private-use protocols and just want to avoid collisions.

Thanks!

Ben.

> On Dec 11, 2018, at 4:15 AM, Roni Even (A) <roni.even@huawei.com> wrote:
> 
> Hi Bo,
> I am not sure I understand the issue. According to section 9.1
> 
> A subprotocol may simultaneously be defined for data channel
>   transport and for Websocket transport.  In such a case the
>   "Subprotocol Definition" and "Reference" cells in the subprotocol's
>   row of the IANA "WebSocket Subprotocol Name Registry" table should
>   contain two entries.  One entry in each of these cells should refer
>   to the Websocket related subprotocol specification, and the other
>   entry should refer to the data channel related subprotocol
>   specification.
> 
> This applies to the msrp case if it was registered also for data channel.
> 
> I am not sure what we will have with a second registry is it only for data channel usage and we will not register it also in the web socket registry?
> 
> 
> 
> Roni
> 
> -----Original Message-----
> From: mmusic [mailto:mmusic-bounces@ietf.org] On Behalf Of Bo Burman
> Sent: Friday, December 07, 2018 10:55 AM
> To: Ben Campbell; Paul Kyzivat
> Cc: mmusic@ietf.org
> Subject: Re: [MMUSIC] AD Evaluation of draft-ietf-mmusic-data-channel-sdpneg-20
> 
> When looking at the now expired draft-ietf-mmusic-msrp-usage-data-channel, I think the content clearly hints that at least for MSRP, a tag without further specification would simply not achieve interoperable implementations. I believe the same would be valid for many other subprotocols. Therefore, I share Ben's concern that FCFS doesn't seem generally sufficient.
> 
> /Bo (as individual)
> 
> -----Original Message-----
> From: mmusic <mmusic-bounces@ietf.org> On Behalf Of Ben Campbell
> Sent: den 27 november 2018 23:53
> To: Paul Kyzivat <pkyzivat@alum.mit.edu>
> Cc: mmusic@ietf.org
> Subject: Re: [MMUSIC] AD Evaluation of draft-ietf-mmusic-data-channel-sdpneg-20
> 
> 
> 
>> On Nov 27, 2018, at 1:40 PM, Paul Kyzivat <pkyzivat@alum.mit.edu> wrote:
>> 
>> On 11/26/18 5:32 PM, Ben Campbell wrote:
>> 
>>>> §9.1: What is the rational for sharing the websocket subprotocol registry rather than creating a new one for data channels? The websocket subprotocol name registry has a policy of “First Come First Served”. This draft seems to state requirements for subprotocol specifications, but FCFS does not require specifications.
>> 
>> IIRC this choice was made by the rtcweb wg. I don't recall how it was made.
>> 
>> It is my impression there is an expectation that many websocket protocols could also be used over data channels in order to get multiplexing of the socket.
> 
> I can accept that the reason might be “because that was what the WG wanted”, but isn’t there still a mismatch with the registration policy? This draft seems to expect subprotocol specifications -- is FCFS acceptable?
> 
>> 
>> 	Thanks,
>> 	Paul
>> 
>> _______________________________________________
>> 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