From nobody Tue Aug 1 07:14:17 2017 Return-Path: X-Original-To: mmusic@ietf.org Delivered-To: mmusic@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id A67AE132170; Tue, 1 Aug 2017 07:14:16 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: Cc: mmusic@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.58.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <150159685641.9518.6501445763330125242@ietfa.amsl.com> Date: Tue, 01 Aug 2017 07:14:16 -0700 Archived-At: Subject: [MMUSIC] I-D Action: draft-ietf-mmusic-sdp-uks-00.txt X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.22 List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 01 Aug 2017 14:14:16 -0000 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 : Unknown Key Share Attacks on uses of Transport Layer Security with the Session Description Protocol (SDP) Authors : Martin Thomson Eric Rescorla Filename : draft-ietf-mmusic-sdp-uks-00.txt Pages : 13 Date : 2017-07-31 Abstract: Unknown key-share attacks on the use of Datagram Transport Layer Security for the Secure Real-Time Transport Protocol (DTLS-SRTP) and its use with Web Real-Time Communications (WebRTC) identity assertions are described. Simple mitigation techniques are defined. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-mmusic-sdp-uks/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-mmusic-sdp-uks-00 https://datatracker.ietf.org/doc/html/draft-ietf-mmusic-sdp-uks-00 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/ From nobody Sat Aug 5 10:41:52 2017 Return-Path: X-Original-To: mmusic@ietf.org Delivered-To: mmusic@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 7B1DB131E9F; Sat, 5 Aug 2017 10:41:50 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: Cc: mmusic@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.58.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <150195491034.18679.17690781303903818798@ietfa.amsl.com> Date: Sat, 05 Aug 2017 10:41:50 -0700 Archived-At: Subject: [MMUSIC] I-D Action: draft-ietf-mmusic-dtls-sdp-28.txt X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.22 List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 05 Aug 2017 17:41:50 -0000 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 : Using the SDP Offer/Answer Mechanism for DTLS Authors : Christer Holmberg Roman Shpount Filename : draft-ietf-mmusic-dtls-sdp-28.txt Pages : 25 Date : 2017-08-05 Abstract: This document defines the SDP offer/answer procedures for negotiating and establishing a DTLS association. The document also defines the criteria for when a new DTLS association must be established. The document updates RFC 5763 and RFC 7345, by replacing common SDP offer/answer procedures with a reference to this specification. This document defines a new SDP media-level attribute, 'tls-id'. This document also defines how the 'tls-id' attribute can be used for negotiating and establishing a TLS connection, in conjunction with the procedures in RFC 4145 and RFC 8122. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-mmusic-dtls-sdp/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-mmusic-dtls-sdp-28 https://datatracker.ietf.org/doc/html/draft-ietf-mmusic-dtls-sdp-28 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-mmusic-dtls-sdp-28 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/ From nobody Sat Aug 5 10:46:17 2017 Return-Path: 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 15E8D127058; Sat, 5 Aug 2017 10:46:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.221 X-Spam-Level: X-Spam-Status: No, score=-4.221 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=ham autolearn_force=no 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 AfoiaI9r6H4S; Sat, 5 Aug 2017 10:46:05 -0700 (PDT) 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 406DE131D2F; Sat, 5 Aug 2017 10:46:04 -0700 (PDT) X-AuditID: c1b4fb2d-857ff70000005f66-8f-5986045aba65 Received: from ESESSHC003.ericsson.se (Unknown_Domain [153.88.183.27]) by sessmg23.ericsson.net (Symantec Mail Security) with SMTP id C7.0D.24422.A5406895; Sat, 5 Aug 2017 19:46:02 +0200 (CEST) Received: from ESESSMB109.ericsson.se ([169.254.9.91]) by ESESSHC003.ericsson.se ([153.88.183.27]) with mapi id 14.03.0352.000; Sat, 5 Aug 2017 19:46:02 +0200 From: Christer Holmberg To: Christer Holmberg , Paul Kyzivat , Ben Campbell CC: "draft-ietf-mmusic-dtls-sdp.all@ietf.org" , General Area Review Team , IETF MMUSIC WG Thread-Topic: Draft new version: draft-dtls-sdp-28 [was: [Gen-art] Gen-ART Last Call review of draft-ietf-mmusic-dtls-sdp-27] Thread-Index: AdMOElgDjbG0VDPRRw6f37D7Aw8Jow== Date: Sat, 5 Aug 2017 17:46:02 +0000 Message-ID: <7594FB04B1934943A5C02806D1A2204B4CCADF58@ESESSMB109.ericsson.se> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [153.88.183.149] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFvrCLMWRmVeSWpSXmKPExsUyM2K7tG4US1ukwd51FhbzO0+zW+y4u4PN 4uqrzywWU5c/ZrFYseEAqwOrx9/3H5g8liz5yeQxa+cTlgDmKC6blNSczLLUIn27BK6MZfPf shTM86y4dqSbtYFxjXsXIyeHhICJxNpVr1lAbCGBI4wSV1p4uxi5gOxFjBKvr+xl6mLk4GAT sJDo/qcNUiMiUCex9eMTVpAaZoFVjBLrWxsYQWqEBaokLszJgaiplzj3eC0bSFhEQE/i9ERd kDCLgIrE8ikT2UBsXgFfiR2n34GtZRQQk/h+ag0TiM0sIC5x68l8JojTBCSW7DnPDGGLSrx8 /I8VwlaSWHt4OwvIeGYBTYn1u/QhWhUlpnQ/ZIcYLyhxcuYTlgmMwrOQTJ2F0DELSccsJB0L GFlWMYoWpxYX56YbGeulFmUmFxfn5+nlpZZsYgTGxcEtv3V3MK5+7XiIUYCDUYmHl/NDa6QQ a2JZcWXuIUYJDmYlEd4Xv4BCvCmJlVWpRfnxRaU5qcWHGKU5WJTEeR32XYgQEkhPLEnNTk0t SC2CyTJxcEo1MDa8W/DPSe6Y+Dr+pw9EYqSmXWc9MsEz9EltV6Ku5c2GiRcKMmfJbdxYIcNS dfH0/k3Pc2x4ozy2LH5dxBrGxRV9XuOQwBfzs1tfH52XFb16y5JSp82OVxI8f+7R5DyyNNn2 QuKVvhyXhsWZ5wI/X9are/D4XP6WTSv6jV2Ur+do955Uf3uDkVeJpTgj0VCLuag4EQAWxK9y hwIAAA== Archived-At: Subject: [MMUSIC] Draft new version: draft-dtls-sdp-28 [was: [Gen-art] Gen-ART Last Call review of draft-ietf-mmusic-dtls-sdp-27] X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 05 Aug 2017 17:46:09 -0000 SGksDQoNCkJhc2VkIG9uIHRoZSBnZW4tYXJ0IGNvbW1lbnRzIGJ5IFBhdWwsIEkgaGF2ZSBtZXJn ZWQgdGhlIFBSIGFuZCBzdWJtaXR0ZWQgYSBuZXcgdmVyc2lvbiAoLTI4KSBvZiBkcmFmdC1kdGxz LXNkcC4NCg0KTm90ZSB0aGF0IHRoZSBkcmFmdCBub3cgcmVwbGFjZXMgdGhlIHJlZmVyZW5jZSB0 byBSRkMgNDU3MiB3aXRoaW4gUkZDIDU3NjMgdG8gYSByZWZlcmVuY2UgdG8gUkZDIDgxMjIuDQoN ClJlZ2FyZHMsDQoNCkNocmlzdGVyDQoNCi0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQpGcm9t OiBDaHJpc3RlciBIb2xtYmVyZyBbbWFpbHRvOmNocmlzdGVyLmhvbG1iZXJnQGVyaWNzc29uLmNv bV0gDQpTZW50OiAzMSBKdWx5IDIwMTcgMTk6MjANClRvOiBQYXVsIEt5eml2YXQgPHBreXppdmF0 QGFsdW0ubWl0LmVkdT47IEJlbiBDYW1wYmVsbCA8YmVuQG5vc3RydW0uY29tPg0KQ2M6IGRyYWZ0 LWlldGYtbW11c2ljLWR0bHMtc2RwLmFsbEBpZXRmLm9yZzsgR2VuZXJhbCBBcmVhIFJldmlldyBU ZWFtIDxnZW4tYXJ0QGlldGYub3JnPjsgSUVURiBNTVVTSUMgV0cgPG1tdXNpY0BpZXRmLm9yZz4N ClN1YmplY3Q6IFJFOiBbR2VuLWFydF0gR2VuLUFSVCBMYXN0IENhbGwgcmV2aWV3IG9mIGRyYWZ0 LWlldGYtbW11c2ljLWR0bHMtc2RwLTI3DQoNClBSIHVwZGF0ZWQuDQoNClJlZ2FyZHMsDQoNCkNo cmlzdGVyDQoNCi0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQpGcm9tOiBQYXVsIEt5eml2YXQg W21haWx0bzpwa3l6aXZhdEBhbHVtLm1pdC5lZHVdDQpTZW50OiAzMSBKdWx5IDIwMTcgMTg6MDMN ClRvOiBDaHJpc3RlciBIb2xtYmVyZyA8Y2hyaXN0ZXIuaG9sbWJlcmdAZXJpY3Nzb24uY29tPjsg QmVuIENhbXBiZWxsIDxiZW5Abm9zdHJ1bS5jb20+DQpDYzogZHJhZnQtaWV0Zi1tbXVzaWMtZHRs cy1zZHAuYWxsQGlldGYub3JnOyBHZW5lcmFsIEFyZWEgUmV2aWV3IFRlYW0gPGdlbi1hcnRAaWV0 Zi5vcmc+OyBJRVRGIE1NVVNJQyBXRyA8bW11c2ljQGlldGYub3JnPg0KU3ViamVjdDogUmU6IFtH ZW4tYXJ0XSBHZW4tQVJUIExhc3QgQ2FsbCByZXZpZXcgb2YgZHJhZnQtaWV0Zi1tbXVzaWMtZHRs cy1zZHAtMjcNCg0KT24gNy8zMS8xNyA0OjA1IEFNLCBDaHJpc3RlciBIb2xtYmVyZyB3cm90ZToN Cj4gSGkgUGF1bCwNCj4gDQo+Pj4gUFIgY3JlYXRlZDoNCj4+Pg0KPj4+IGh0dHBzOi8vZ2l0aHVi LmNvbS9jZGg0dS9kcmFmdC1kdGxzLXNkcC9wdWxsLzM0DQo+Pg0KPj4gVGhpcyBsZWF2ZXMgUkZD NTc2MyBpbiBhbiBpbmNvbnNpc3RlbnQgc3RhdGU6DQo+PiAtIHRoZSByZWZlcmVuY2UgdG8gODEy MiBpbiBzZWN0aW9uIDUgaXNuJ3QgYmFja2VkIHVwIHdpdGggYW4gZW50cnkgaW4gDQo+PiB0aGUg cmVmZXJlbmNlcyBzZWN0aW9uDQo+IA0KPiBJbiB0aGUgUFIsIEkgRE8gYWRkIDgxMjIgdG8gdGhl IHJlZmVyZW5jZSBzZWN0aW9uIG9mIDU3NjMgOikNCg0KT2gsIHNvcnJ5Lg0KDQo+PiAtIHRoZXJl IGlzIHN0aWxsIGEgcmVmZXJlbmNlIHRvIDQ1NzIgaW4gdGhlIGludHJvZHVjdGlvbi4NCj4gDQo+ IEkgY291bGQgYWRkIGEgc3RhdGVtZW50LCBzYXlpbmcgdGhhdCB0aGUgcmVmZXJlbmNlIGluIHRo ZSBJbnRyb2R1Y3Rpb24gaXMgdXBkYXRlZC4NCg0KVGhhdCB3b3JrcyBmb3IgbWUuDQoNCglUaGFu a3MsDQoJUGF1bA0KDQo+IFJlZ2FyZHMsDQo+IA0KPiBDaHJpc3Rlcg0KPiANCj4gDQo+IA0KPiAN Cj4gT3RoZXJ3aXNlIGxvb2tzIHJpZ2h0Lg0KPiANCj4gCVRoYW5rcywNCj4gCVBhdWwNCj4gDQo+ PiBSZWdhcmRzLA0KPj4NCj4+IENocmlzdGVyDQo+Pg0KPj4gLS0tLS1PcmlnaW5hbCBNZXNzYWdl LS0tLS0NCj4+IEZyb206IENocmlzdGVyIEhvbG1iZXJnIFttYWlsdG86Y2hyaXN0ZXIuaG9sbWJl cmdAZXJpY3Nzb24uY29tXQ0KPj4gU2VudDogMjkgSnVseSAyMDE3IDIzOjM4DQo+PiBUbzogUGF1 bCBLeXppdmF0IDxwa3l6aXZhdEBhbHVtLm1pdC5lZHU+OyBCZW4gQ2FtcGJlbGwgDQo+PiA8YmVu QG5vc3RydW0uY29tPg0KPj4gQ2M6IGRyYWZ0LWlldGYtbW11c2ljLWR0bHMtc2RwLmFsbEBpZXRm Lm9yZzsgR2VuZXJhbCBBcmVhIFJldmlldyBUZWFtIA0KPj4gPGdlbi1hcnRAaWV0Zi5vcmc+OyBJ RVRGIE1NVVNJQyBXRyA8bW11c2ljQGlldGYub3JnPg0KPj4gU3ViamVjdDogUkU6IFtHZW4tYXJ0 XSBHZW4tQVJUIExhc3QgQ2FsbCByZXZpZXcgb2YNCj4+IGRyYWZ0LWlldGYtbW11c2ljLWR0bHMt c2RwLTI3DQo+Pg0KPj4gSGksDQo+Pg0KPj4+Pj4+PiBSZWdhcmRpbmcgdGhlIHJlZmVyZW5jZSB0 byBSRkMgNDU3MiwgdGhlIG5ldyB0ZXh0IGluIHNlY3Rpb24NCj4+Pj4+Pj4gMTAuMi4xIHJlZmVy ZW5jZXMgUkZDIDQ1NzIuIFdlIGVhcmxpZXIgYWdyZWVkIHdlIHdlcmUgbm90IGdvaW5nIHRvIHVw ZGF0ZSB0aGF0IHRleHQsIGFuZCBrZWVwIGFuIGluZm9ybWF0aXZlIHJlZmVyZW5jZSB0byBSRkMg NDU3Mi4NCj4+Pj4+Pg0KPj4+Pj4+IE9LLCBJIGd1ZXNzIEkgcmVtZW1iZXIgdGhhdCBub3cuIElz IGl0IGNvbnNpZGVyZWQgYWNjZXB0YWJsZSB0byANCj4+Pj4+PiBpc3N1ZSBhIG5ldyBkb2N1bWVu dCB3aXRoIGEgcmVmZXJlbmNlIHRvIGFuIG9ic29sZXRlIGRvY3VtZW50IHdoZW4gaXQgaXNuJ3Qg dG8gaGlnaGxpZ2h0IGEgZGlmZmVyZW5jZSBmcm9tIHRoZSBjdXJyZW50IGRvY3VtZW50Pw0KPj4+ Pj4+DQo+Pj4+Pj4gU2luY2UgdGhpcyBpcyBhIHJldmlldyBmb3IgdGhlIHRlbGVjb25mZXJlbmNl LCBJJ2xsIGp1c3QgbGVhdmUgdGhhdCBmb3IgdGhlIElFU0cgZm9sayB0byBkZWNpZGUuDQo+Pj4+ Pg0KPj4+Pj4gQXMgZmFyIGFzIEkga25vdywgdGhlcmXigJlzIG5vIGhhcmQgYW5kIGZhc3QgcnVs ZSBhYm91dCB0aGlzLiBJdCANCj4+Pj4+IHJlYWxseSBkZXBlbmRzIG9uIHdoZXRoZXIgdGhlIGRp ZmZlcmVuY2UgYmV0d2VlbiB0aGUgbmV3IGFuZCANCj4+Pj4+IG9ic29sZXRlIGRlcGVuZGVuY2ll cyBhcmUgbWF0ZXJpYWwgdG8gdGhlIGRyYWZ0LiBJIGRvIHRoaW5rIHdlIChpLmUuDQo+Pj4+PiB0 aGUgSUVTRykgd291bGQgZmF2b3IgcmVmZXJlbmNpbmcgdGhlIG5ldyBSRkMsIGJ1dCB3b3VsZCBi ZSBvcGVuIA0KPj4+Pj4gdG8gYXJndW1lbnRzIGFib3V0IHdoeSBhIFdHIGNob3NlIHRvIHJlZmVy ZW5jZSB0aGUgb2Jzb2xldGUgDQo+Pj4+PiB2ZXJzaW9uDQo+Pj4+Pg0KPj4+Pj4gRG9lcyBhbnlv bmUgcmVjYWxsIHRoZSByZWFzb25pbmcgaW4gdGhpcyBpbnN0YW5jZT8NCj4+Pj4NCj4+Pj4gSnVz dCB0byBtYWtlIHN1cmUgd2UgYXJlIG9uIHRoZSBzYW1lIHBhZ2UsIHRoZXJlIGFyZSBUV08gcmVm ZXJlbmNlcyB0byBSRkMgNDU3MiBpbiB0aGUgZHJhZnQuDQo+Pj4+DQo+Pj4+IFRoZSBGSVJTVCBy ZWZlcmVuY2UgaXMgaW4gc2VjdGlvbiA4LCB3aGVyZSBpdCBpcyB1c2VkIHRvIHJlZmVyZW5jZSAN Cj4+Pj4gYW4gZXhhbXBsZSBpbiBSRkMgNDU3Mi4gVGhlIHNhbWUgZXhhbXBsZSBleGlzdHMgaW4g UkZDIDgxMjIsIHNvIHdlIGNhbiBjaGFuZ2UgdGhhdCByZWZlcmVuY2UuDQo+Pj4+DQo+Pj4+IFRo ZSBTRUNPTkQgcmVmZXJlbmNlIGlzIGluIHNlY3Rpb24gMTAuMi4xLCBhcyBwYXJ0IG9mIHRoZSB1 cGRhdGVkIA0KPj4+PiB0ZXh0IGZvciBSRkMgNTc2My4gTm93LCBSRkMgNTc2MyByZWZlcmVuY2Vz IFJGQyA0NTcyIGluIDQgDQo+Pj4+IGRpZmZlcmVuY2UgcGxhY2VzLCBzbyBpZiB3ZSBjaGFuZ2Ug dGhlID5yZWZlcmVuY2UgdG8gUkZDIDgxMjIgaW4gDQo+Pj4+IHRoZSB0ZXh0IHVwZGF0ZWQgYnkg dGhlIGRyYWZ0IHdlIHdvdWxkIGFsc28gaGF2ZSB0byBkbyBpdCBpbiBldmVyeSBvdGhlciBwbGFj ZS4gVGhhdCB3YXMgdGhlIHJlYXNvbiB3ZSBkZWNpZGVkIG5vdCB0byBkbyBpdCAoSSBoYXZlIG5v IHByb2JsZW0gZG9pbmcgaXQgdGhhdCdzIHdoYXQgSUVTRyB3YW50cywgdGhvdWdoKS4NCj4+Pg0K Pj4+IFRoYW5rcyBmb3IgcG9pbnRpbmcgdGhhdCBvdXQuIEkganVzdCBsb29rZWQgYXQgdGhhdCB0 byBzaXplIHVwIHRoZSANCj4+PiBzaXR1YXRpb24uIE9mIHRob3NlIGZvdXIgcmVmZXJlbmNlcywg dGhyZWUgb2YgdGhlbSBhcmUgaW4gc2VjdGlvbiA1IA0KPj4+IGFuZCB3aWxsIGFsbCBiZSByZXBs YWNlZCBieSB0aGUgbmV3IHRleHQgaW4gdGhpcyBkb2N1bWVudC4gVGhlIHJlbWFpbmluZyByZWZl cmVuY2UgaXMgc2ltcGx5IGEgZ2VuZXJhbCBvbmUgaW4gdGhlIGludHJvZHVjdGlvbi4gQW5kIHRo ZW4gaW4gYWRkaXRpb24gdGhlcmUgaXMgdGhlIGFjdHVhbCByZWZlcmVuY2UgdGV4dCBpbiB0aGUg bm9ybWF0aXZlIHJlZmVyZW5jZXMuDQo+Pj4NCj4+PiBJU1RNIHRoYXQgaXQgd291bGQgYmUgc3Vm ZmljaWVudCB0byB1cGRhdGUgdGhlIHJlZmVyZW5jZSBpbiB0aGUgbmV3IA0KPj4+IHRleHQgZm9y IHNlY3Rpb24gNSBhbmQgdGhlbiBhZGQgYSBnZW5lcmFsIHN0YXRlbWVudCB0byB1cGRhdGUgYWxs IHJlZmVyZW5jZXMgdG8gNDU3MiB0byByZWZlciB0byA4MTIyLg0KPj4+DQo+Pj4gQnV0IGFnYWlu LCB0aGlzIGlzIHJlYWxseSBhbiBJRVNHIGlzc3VlIGF0IHRoaXMgcG9pbnQuDQo+Pg0KPj4gT3Is IHdlIGNvdWxkIGp1c3QgZ28gYWhlYWQgYW5kIGRvIGl0IDopDQo+Pg0KPj4gUmVnYXJkcywNCj4+ DQo+PiBDaHJpc3Rlcg0KPj4NCj4+Pg0KPj4+DQo+Pj4NCj4+Pj4+IC0tLS0tT3JpZ2luYWwgTWVz c2FnZS0tLS0tDQo+Pj4+PiBGcm9tOiBDaHJpc3RlciBIb2xtYmVyZyBbbWFpbHRvOmNocmlzdGVy LmhvbG1iZXJnQGVyaWNzc29uLmNvbV0NCj4+Pj4+IFNlbnQ6IDI5IEp1bHkgMjAxNyAwMTowNw0K Pj4+Pj4gVG86IFBhdWwgS3l6aXZhdCA8cGt5eml2YXRAYWx1bS5taXQuZWR1PjsgDQo+Pj4+PiBk cmFmdC1pZXRmLW1tdXNpYy1kdGxzLXNkcC5hbGxAaWV0Zi5vcmcNCj4+Pj4+IENjOiBHZW5lcmFs IEFyZWEgUmV2aWV3IFRlYW0gPGdlbi1hcnRAaWV0Zi5vcmc+OyBJRVRGIE1NVVNJQyBXRyANCj4+ Pj4+IDxtbXVzaWNAaWV0Zi5vcmc+DQo+Pj4+PiBTdWJqZWN0OiBSRTogW0dlbi1hcnRdIEdlbi1B UlQgTGFzdCBDYWxsIHJldmlldyBvZg0KPj4+Pj4gZHJhZnQtaWV0Zi1tbXVzaWMtZHRscy1zZHAt MjcgSGkgUGF1bCwgVGhhbmtzIGZvciB0aGUgcmV2aWV3LiBJJ2xsIA0KPj4+Pj4gZml4IHJlZmVy ZW5jZXMuDQo+Pj4+PiBSZWdhcmRzLA0KPj4+Pj4gQ2hyaXN0ZXINCj4+Pj4+IC0tLS0tT3JpZ2lu YWwgTWVzc2FnZS0tLS0tDQo+Pj4+PiBGcm9tOiBQYXVsIEt5eml2YXQgW21haWx0bzpwa3l6aXZh dEBhbHVtLm1pdC5lZHVdDQo+Pj4+PiBTZW50OiAyOCBKdWx5IDIwMTcgMDQ6MDENCj4+Pj4+IFRv OiBkcmFmdC1pZXRmLW1tdXNpYy1kdGxzLXNkcC5hbGxAaWV0Zi5vcmcNCj4+Pj4+IENjOiBHZW5l cmFsIEFyZWEgUmV2aWV3IFRlYW0gPGdlbi1hcnRAaWV0Zi5vcmc+OyBJRVRGIE1NVVNJQyBXRyAN Cj4+Pj4+IDxtbXVzaWNAaWV0Zi5vcmc+DQo+Pj4+PiBTdWJqZWN0OiBbR2VuLWFydF0gR2VuLUFS VCBMYXN0IENhbGwgcmV2aWV3IG9mDQo+Pj4+PiBkcmFmdC1pZXRmLW1tdXNpYy1kdGxzLXNkcC0y NyBJIGFtIHRoZSBhc3NpZ25lZCBHZW4tQVJUIHJldmlld2VyIGZvciB0aGlzIGRyYWZ0LiBUaGUg R2VuZXJhbCBBcmVhIFJldmlldyBUZWFtIChHZW4tQVJUKSByZXZpZXdzIGFsbCBJRVRGIGRvY3Vt ZW50cyBiZWluZyBwcm9jZXNzZWQgYnkgdGhlIElFU0cgZm9yIHRoZSBJRVRGIENoYWlyLiBQbGVh c2Ugd2FpdCBmb3IgZGlyZWN0aW9uIGZyb20geW91ciBkb2N1bWVudCBzaGVwaGVyZCBvciBBRCBi ZWZvcmUgcG9zdGluZyBhIG5ldyB2ZXJzaW9uIG9mIHRoZSBkcmFmdC4gRm9yIG1vcmUgaW5mb3Jt YXRpb24sIHBsZWFzZSBzZWUgdGhlIEZBUSBhdCA84oCLaHR0cDovL3dpa2kudG9vbHMuaWV0Zi5v cmcvYXJlYS9nZW4vdHJhYy93aWtpL0dlbkFydGZhcT4uDQo+Pj4+PiBEb2N1bWVudDogZHJhZnQt aWV0Zi1tbXVzaWMtZHRscy1zZHAtMjcNCj4+Pj4+IFJldmlld2VyOiBQYXVsIEt5eml2YXQNCj4+ Pj4+IFJldmlldyBEYXRlOiAyMDE3LTA3LTA3DQo+Pj4+PiBJRVRGIExDIEVuZCBEYXRlOiAyMDE3 LTA3LTI0DQo+Pj4+PiBJRVNHIFRlbGVjaGF0IGRhdGU6IDIwMTctMDgtMTUNCj4+Pj4+IFN1bW1h cnk6DQo+Pj4+PiBUaGlzIGRyYWZ0IGlzIGJhc2ljYWxseSByZWFkeSBmb3IgcHVibGljYXRpb24s IGJ1dCBoYXMgbml0cyB0aGF0IHNob3VsZCBiZSBmaXhlZCBiZWZvcmUgcHVibGljYXRpb24uDQo+ Pj4+PiAoVGhlc2Ugbml0cyB3ZXJlIHJlcG9ydGVkIGJ5IElkTml0cy4gSSBhcG9sb2dpemUgZm9y IG5vdCBub3RpY2luZyANCj4+Pj4+IHRoZXNlIGR1cmluZyBteSBMYXN0IENhbGwgcmV2aWV3LikN Cj4+Pj4+IElzc3VlczoNCj4+Pj4+IE1ham9yOiAwDQo+Pj4+PiBNaW5vcjogMA0KPj4+Pj4gTml0 czogIDINCj4+Pj4+ICgxKSBOSVQ6IFVudXNlZCBSZWZlcmVuY2U6ICdSRkM1MjQ1JyBpcyBkZWZp bmVkIG9uIGxpbmUgMTA2NSwgYnV0IA0KPj4+Pj4gbm8gZXhwbGljaXQgcmVmZXJlbmNlIHdhcyBm b3VuZCBpbiB0aGUgdGV4dCBUaGlzIGlzIG5vdyByZWR1bmRhbnQgYmVjYXVzZSBhbGwgdGhlIHJl ZmVyZW5jZXMgaW4gdGhlIHRleHQgaGF2ZSBiZWVuIGNoYW5nZWQgdG8gZHJhZnQtaWV0Zi1pY2Ut cmZjNTI0NWJpcy4NCj4+Pj4+ICgyKSBOSVQ6IE9ic29sZXRlIGluZm9ybWF0aW9uYWwgcmVmZXJl bmNlIChpcyB0aGlzIGludGVudGlvbmFsPyk6DQo+Pj4+PiBSRkMNCj4+Pj4+IDQ1NzIgVGhpcyBp cyBub3cgb2Jzb2xldGUgYmVjYXVzZSBpdCBoYXMgYmVlbiByZXBsYWNlZCBieSBSRkM4MTIyLiBU aGlzIGRyYWZ0IHNob3VsZCBub3cgYmUgcmVmZXJlbmNpbmcgdGhhdC4NCj4+Pj4NCj4+Pg0KPj4N Cj4gDQoNCg== From nobody Sat Aug 5 10:52:44 2017 Return-Path: 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 DEE6812711E for ; Sat, 5 Aug 2017 10:52:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.22 X-Spam-Level: X-Spam-Status: No, score=-4.22 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=ham autolearn_force=no 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 8peFV6upTsUH for ; Sat, 5 Aug 2017 10:52:38 -0700 (PDT) Received: from sessmg22.ericsson.net (sessmg22.ericsson.net [193.180.251.58]) (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 66857127058 for ; Sat, 5 Aug 2017 10:52:38 -0700 (PDT) X-AuditID: c1b4fb3a-803ff70000001b2f-ee-598605e40e00 Received: from ESESSHC005.ericsson.se (Unknown_Domain [153.88.183.33]) by sessmg22.ericsson.net (Symantec Mail Security) with SMTP id 6A.68.06959.4E506895; Sat, 5 Aug 2017 19:52:36 +0200 (CEST) Received: from ESESSMB109.ericsson.se ([169.254.9.91]) by ESESSHC005.ericsson.se ([153.88.183.33]) with mapi id 14.03.0352.000; Sat, 5 Aug 2017 19:52:35 +0200 From: Christer Holmberg To: Taylor Brandstetter , mmusic WG Thread-Topic: [MMUSIC] draft-ietf-mmusic-msid-16 is out of sync with WebRTC 1.0 Thread-Index: AQHTBm6OjKP34wvtAEWe0i7hxd9CSqJ2GenA Date: Sat, 5 Aug 2017 17:52:35 +0000 Message-ID: <7594FB04B1934943A5C02806D1A2204B4CCADFB5@ESESSMB109.ericsson.se> References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [153.88.183.149] Content-Type: multipart/alternative; boundary="_000_7594FB04B1934943A5C02806D1A2204B4CCADFB5ESESSMB109erics_" MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFmphkeLIzCtJLcpLzFFi42KZGbFdUfcJa1ukQdMdAYvLKx6yWkxd/pjF gcljwaZSjyVLfjIFMEVx2aSk5mSWpRbp2yVwZdxqn8BYMCun4sjWKewNjEsyuxg5OSQETCSu vdvCDGILCRxhlHh7h7eLkQvIXsQo8XrFCvYuRg4ONgELie5/2iA1IgJeEku+vAKrFxYIkGic +IUJIh4ocWbHC1YI20jizb+1YHEWARWJG/+fsIHYvAK+Ei07prJAzJ/OKLGrcSvYIE6g5idz VoLZjAJiEt9PrQFrZhYQl7j1ZD4TxKECEkv2nGeGsEUlXj7+xwphK0msPbydBeROZoF8iVWN LhC7BCVOznzCMoFReBaSSbMQqmYhqYIIa0qs36UPUa0oMaX7ITuErSHROmcuO7L4Akb2VYyi xanFxbnpRkZ6qUWZycXF+Xl6eaklmxiBcXNwy2+rHYwHnzseYhTgYFTi4Y360BopxJpYVlyZ e4hRgoNZSYT3xS+gEG9KYmVValF+fFFpTmrxIUZpDhYlcV6HfRcihATSE0tSs1NTC1KLYLJM HJxSDYwM96pe8nRwifb3Bsf9zDurbM1//Latyokt6UKFLp8y5kjckxe771cSe+jMXduJuUaX Ck5xLK3+UHh0oXSMs76qD3PEBYmbqz63N2j8tolq+H2z872D0k/uCMcCY7PUW9KrhMOjnvMz t51iL3Z/vLdTiePWWf9Vs8LqJnz84zVVqui7RjZ7hRJLcUaioRZzUXEiAFbWSbyXAgAA Archived-At: Subject: Re: [MMUSIC] draft-ietf-mmusic-msid-16 is out of sync with WebRTC 1.0 X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 05 Aug 2017 17:52:41 -0000 --_000_7594FB04B1934943A5C02806D1A2204B4CCADFB5ESESSMB109erics_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SGksDQoNCk5vdGhpbmcgcHJldmVudHMgdXMgZnJvbSBkb2luZyBjaGFuZ2VzIHRvIGEgZHJhZnQs IGV2ZW4gaWYgaXTigJlzIGFscmVhZHkgaW4gdGhlIFJGQyBlZGl0b3LigJlzIHF1ZXVlLiBUaGUg cXVlc3Rpb24gaXMgd2hldGhlciB3ZSBjb25zaWRlciB0aGUgY2hhbmdlIGVzc2VudGlhbCBlbm91 Z2ggYXQgdGhhdCBzdGFnZS4NCg0KUmVnYXJkcywNCg0KQ2hyaXN0ZXINCg0KRnJvbTogbW11c2lj IFttYWlsdG86bW11c2ljLWJvdW5jZXNAaWV0Zi5vcmddIE9uIEJlaGFsZiBPZiBUYXlsb3IgQnJh bmRzdGV0dGVyDQpTZW50OiAyNyBKdWx5IDIwMTcgMDI6MjMNClRvOiBtbXVzaWMgV0cgPG1tdXNp Y0BpZXRmLm9yZz4NClN1YmplY3Q6IFJlOiBbTU1VU0lDXSBkcmFmdC1pZXRmLW1tdXNpYy1tc2lk LTE2IGlzIG91dCBvZiBzeW5jIHdpdGggV2ViUlRDIDEuMA0KDQpQaW5nLiBIYXJhbGQgKHRoZSBh dXRob3Igb2YgdGhpcyBkb2N1bWVudCkgaXMgb24gc2FiYmF0aWNhbCwgc28gSSdkIGFwcHJlY2lh dGUgc29tZSBndWlkYW5jZSBmcm9tIHNvbWVvbmUgZWxzZSBmYW1pbGlhciB3aXRoIElFVEYgcHJv Y2Vzc2VzLiBJdCdzIGFscmVhZHkgaW4gdGhlIFJGQyBlZGl0b3IgcXVldWUsIHdoaWNoIHNlZW1z IGxpa2UgYSBwcm9ibGVtLg0KDQpPbiBUaHUsIEp1bCAyMCwgMjAxNyBhdCA2OjQxIFBNLCBUYXls b3IgQnJhbmRzdGV0dGVyIDxkZWFkYmVlZkBnb29nbGUuY29tPG1haWx0bzpkZWFkYmVlZkBnb29n bGUuY29tPj4gd3JvdGU6DQpJbiB0aGUgY3VycmVudCBzdGF0ZSBvZiBXZWJSVEMgMS4wLCB0cmFj ayBJRHMgYXJlIG5vdCBndWFyYW50ZWVkIHRvIGJlIHN5bW1ldHJpY2FsIGJldHdlZW4gdGhlIHNl bmRpbmcgYW5kIHJlY2VpdmluZyBQZWVyQ29ubmVjdGlvbi4gVGhpcyBpcyBiZWNhdXNlICJhZGRU cmFjayIgbm90IG9ubHkgY3JlYXRlcyBhbiBSdHBTZW5kZXIsIGJ1dCBhIHdob2xlIFJ0cFRyYW5z Y2VpdmVyLCB3aGljaCBoYXMgYW4gUnRwUmVjZWl2ZXIsIHdoaWNoIGhhcyBhIE1lZGlhU3RyZWFt VHJhY2sgd2l0aCBhIGdlbmVyYXRlZCBJRC4gU28gaWYgImFkZFRyYWNrIiBpcyBjYWxsZWQsIGFu ZCBhIHJlbW90ZSBkZXNjcmlwdGlvbiBpcyBzZXQgbGF0ZXIsIGl0J3MgdGhlIE1JRCB0aGF0IGNv cnJlbGF0ZXMgdGhlICJtPSIgc2VjdGlvbiB3aXRoIHRoZSB0cmFjaywgbm90IHRoZSB0cmFjayBJ RCwgYW5kIHRoZSB0cmFjayBJRCBpbiBTRFAgaXMgZWZmZWN0aXZlbHkgaWdub3JlZC4NCg0KVGhp cyBpcyBhbGwgcmVsYXRlZCB0byB0aGUgImVhcmx5IG1lZGlhIiBmdW5jdGlvbmFsaXR5LCBhbmQg aXMgZXhwbGFpbmVkIGZ1cnRoZXIgaW4gYSBibG9nIHBvc3QgYnkgSmFuLUl2YXI7IHNlZSB0aGUg IkNvcnJlbGF0ZSBieSB0cmFuc2NlaXZlci5taWQiIHNlY3Rpb246IGh0dHBzOi8vYmxvZy5tb3pp bGxhLm9yZy93ZWJydGMvdGhlLWV2b2x1dGlvbi1vZi13ZWJydGMvDQoNClNvLCB0aGUgcXVlc3Rp b24gYmVjYW1lICJ3aHkgc2lnbmFsIHRyYWNrIElEcyBhdCBhbGw/IiBUaGlzIHdhcyBicm91Z2h0 IHVwIGluIGEgTWF5IHZpcnR1YWwgaW50ZXJpbSAoaHR0cHM6Ly93d3cudzMub3JnLzIwMTEvMDQv d2VicnRjL3dpa2kvTWF5XzJfMjAxNyksIGFuZCB3ZSBkZWNpZGVkIHRvIGludmVzdGlnYXRlIHJl bW92aW5nIHRoZW0uIFRvIG15IGtub3dsZWRnZSB0aGlzIHRvcGljIGhhc24ndCBiZWVuIGJyb3Vn aHQgdXAgb24gdGhpcyBtYWlsaW5nIGxpc3QgeWV0Lg0KDQpJcyB0aGlzIHNvbWV0aGluZyBzdGls bCB3b3J0aCBjb25zaWRlcmluZywgb3IgaXMgaXQgdG9vIGxhdGU/ICJhPW1zaWQiIHdvdWxkIHN3 aXRjaCB0byBvbmx5IGNvbnRhaW5pbmcgdGhlIHN0cmVhbSBJRCwgbm90IHRoZSB0cmFjayBJRC4g SW1wbGVtZW50ZXJzIHdvdWxkIHByZXN1bWFibHkgaGF2ZSBhIHRyYW5zaXRpb25hbCBwZXJpb2Qg d2hlcmUgdGhleSBzdXBwb3J0IHBhcnNpbmcgYm90aCBmb3JtcyBvZiAiYT1tc2lkIiwgYWZ0ZXIg d2hpY2ggdGhleSBzdGFydCBnZW5lcmF0aW5nIHRoZSBuZXcgZm9ybWF0LCBhcyB3ZSd2ZSBkb25l IGZvciBvdGhlciB0aGluZ3MuDQoNClRoZSBiZW5lZml0cyBhcmUgdGhhdCB0aGUgU0RQIHdvdWxk IGJlIHNsaWdodGx5IHNtYWxsZXIsIGFuZCB0aGUgY29tcGxleGl0eSBvZiB0aGUgc3RhbmRhcmRz IGNvdWxkIGJlIHNsaWdodGx5IHJlZHVjZWQuIFRoZSBkb3duc2lkZSBpcyB0aGF0IG1vcmUgYXBw bGljYXRpb25zIHRoYXQgcmVseSBvbiB0cmFjayBJRHMgd291bGQgbmVlZCB0byBiZSB1cGRhdGVk ICh0aG91Z2ggbWFueSB3aWxsIG5lZWQgdG8gYmUgdXBkYXRlZCBhbnl3YXkpLg0KDQpSZWdhcmRs ZXNzIG9mIHRoZSBvdXRjb21lIG9mIHRoaXMgZGVjaXNpb24sICJtbXVzaWMtbXNpZCIgcmVhbGx5 IG91Z2h0IHRvIGJlIHVwZGF0ZWQgYmVmb3JlIHB1YmxpY2F0aW9uLiBJdCdzIGJlZW4gb3V0IG9m IHN5bmMgd2l0aCBXZWJSVEMgMS4wIGZvciBhYm91dCBhIHllYXI7IGhlcmUncyB0aGUgZmlyc3Qg ZWRpdG9yJ3MgZHJhZnQgdGhhdCBicm9rZSB0aGUgdHJhY2sgSUQgc3ltbWV0cnk6IGh0dHBzOi8v dzNjLmdpdGh1Yi5pby93ZWJydGMtcGMvYXJjaGl2ZXMvMjAxNjA3MjIvd2VicnRjLmh0bWwNCg0K --_000_7594FB04B1934943A5C02806D1A2204B4CCADFB5ESESSMB109erics_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 IkNhbWJyaWEgTWF0aCI7DQoJcGFub3NlLTE6MiA0IDUgMyA1IDQgNiAzIDIgNDt9DQpAZm9udC1m YWNlDQoJe2ZvbnQtZmFtaWx5OkNhbGlicmk7DQoJcGFub3NlLTE6MiAxNSA1IDIgMiAyIDQgMyAy IDQ7fQ0KLyogU3R5bGUgRGVmaW5pdGlvbnMgKi8NCnAuTXNvTm9ybWFsLCBsaS5Nc29Ob3JtYWws IGRpdi5Nc29Ob3JtYWwNCgl7bWFyZ2luOjBjbTsNCgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJ Zm9udC1zaXplOjEyLjBwdDsNCglmb250LWZhbWlseToiVGltZXMgTmV3IFJvbWFuIixzZXJpZjt9 DQphOmxpbmssIHNwYW4uTXNvSHlwZXJsaW5rDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCglj b2xvcjpibHVlOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0KYTp2aXNpdGVkLCBzcGFu Lk1zb0h5cGVybGlua0ZvbGxvd2VkDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgljb2xvcjpw dXJwbGU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQpzcGFuLkVtYWlsU3R5bGUxNw0K CXttc28tc3R5bGUtdHlwZTpwZXJzb25hbC1yZXBseTsNCglmb250LWZhbWlseToiQ2FsaWJyaSIs c2Fucy1zZXJpZjsNCgljb2xvcjojMUY0OTdEO30NCi5Nc29DaHBEZWZhdWx0DQoJe21zby1zdHls ZS10eXBlOmV4cG9ydC1vbmx5Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIixzYW5zLXNlcmlmOw0K CW1zby1mYXJlYXN0LWxhbmd1YWdlOkVOLVVTO30NCkBwYWdlIFdvcmRTZWN0aW9uMQ0KCXtzaXpl OjYxMi4wcHQgNzkyLjBwdDsNCgltYXJnaW46NzIuMHB0IDcyLjBwdCA3Mi4wcHQgNzIuMHB0O30N CmRpdi5Xb3JkU2VjdGlvbjENCgl7cGFnZTpXb3JkU2VjdGlvbjE7fQ0KLS0+PC9zdHlsZT48IS0t W2lmIGd0ZSBtc28gOV0+PHhtbD4NCjxvOnNoYXBlZGVmYXVsdHMgdjpleHQ9ImVkaXQiIHNwaWRt YXg9IjEwMjYiIC8+DQo8L3htbD48IVtlbmRpZl0tLT48IS0tW2lmIGd0ZSBtc28gOV0+PHhtbD4N CjxvOnNoYXBlbGF5b3V0IHY6ZXh0PSJlZGl0Ij4NCjxvOmlkbWFwIHY6ZXh0PSJlZGl0IiBkYXRh PSIxIiAvPg0KPC9vOnNoYXBlbGF5b3V0PjwveG1sPjwhW2VuZGlmXS0tPg0KPC9oZWFkPg0KPGJv ZHkgbGFuZz0iRU4tR0IiIGxpbms9ImJsdWUiIHZsaW5rPSJwdXJwbGUiPg0KPGRpdiBjbGFzcz0i V29yZFNlY3Rpb24xIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNp emU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xv cjojMUY0OTdEO21zby1mYXJlYXN0LWxhbmd1YWdlOkVOLVVTIj5IaSw8bzpwPjwvbzpwPjwvc3Bh bj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBw dDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3 RDttc28tZmFyZWFzdC1sYW5ndWFnZTpFTi1VUyI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9w Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9u dC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0Q7bXNv LWZhcmVhc3QtbGFuZ3VhZ2U6RU4tVVMiPk5vdGhpbmcgcHJldmVudHMgdXMgZnJvbSBkb2luZyBj aGFuZ2VzIHRvIGEgZHJhZnQsIGV2ZW4gaWYgaXTigJlzIGFscmVhZHkgaW4gdGhlIFJGQyBlZGl0 b3LigJlzIHF1ZXVlLiBUaGUgcXVlc3Rpb24gaXMgd2hldGhlciB3ZSBjb25zaWRlcg0KIHRoZSBj aGFuZ2UgZXNzZW50aWFsIGVub3VnaCBhdCB0aGF0IHN0YWdlLjxvOnA+PC9vOnA+PC9zcGFuPjwv cD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2Zv bnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEO21z by1mYXJlYXN0LWxhbmd1YWdlOkVOLVVTIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZh bWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RDttc28tZmFy ZWFzdC1sYW5ndWFnZTpFTi1VUyI+UmVnYXJkcyw8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWls eTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RDttc28tZmFyZWFz dC1sYW5ndWFnZTpFTi1VUyI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1 b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0Q7bXNvLWZhcmVhc3QtbGFu Z3VhZ2U6RU4tVVMiPkNocmlzdGVyPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+PGEgbmFtZT0iX01haWxFbmRDb21wb3NlIj48c3BhbiBzdHlsZT0iZm9udC1zaXpl OjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6 IzFGNDk3RDttc28tZmFyZWFzdC1sYW5ndWFnZTpFTi1VUyI+PG86cD4mbmJzcDs8L286cD48L3Nw YW4+PC9hPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxiPjxzcGFuIGxhbmc9IkVOLVVTIiBz dHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNh bnMtc2VyaWYiPkZyb206PC9zcGFuPjwvYj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQt c2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmIj4g bW11c2ljIFttYWlsdG86bW11c2ljLWJvdW5jZXNAaWV0Zi5vcmddDQo8Yj5PbiBCZWhhbGYgT2Yg PC9iPlRheWxvciBCcmFuZHN0ZXR0ZXI8YnI+DQo8Yj5TZW50OjwvYj4gMjcgSnVseSAyMDE3IDAy OjIzPGJyPg0KPGI+VG86PC9iPiBtbXVzaWMgV0cgJmx0O21tdXNpY0BpZXRmLm9yZyZndDs8YnI+ DQo8Yj5TdWJqZWN0OjwvYj4gUmU6IFtNTVVTSUNdIGRyYWZ0LWlldGYtbW11c2ljLW1zaWQtMTYg aXMgb3V0IG9mIHN5bmMgd2l0aCBXZWJSVEMgMS4wPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+UGluZy4gSGFyYWxkICh0aGUgYXV0aG9yIG9mIHRoaXMgZG9jdW1lbnQpIGlz IG9uIHNhYmJhdGljYWwsIHNvIEknZCBhcHByZWNpYXRlIHNvbWUgZ3VpZGFuY2UgZnJvbSBzb21l b25lIGVsc2UgZmFtaWxpYXIgd2l0aCBJRVRGIHByb2Nlc3Nlcy4gSXQncyBhbHJlYWR5IGluIHRo ZSBSRkMgZWRpdG9yIHF1ZXVlLCB3aGljaCBzZWVtcyBsaWtlIGEgcHJvYmxlbS48bzpwPjwvbzpw PjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9v OnA+PC9wPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPk9uIFRodSwgSnVsIDIwLCAyMDE3 IGF0IDY6NDEgUE0sIFRheWxvciBCcmFuZHN0ZXR0ZXIgJmx0OzxhIGhyZWY9Im1haWx0bzpkZWFk YmVlZkBnb29nbGUuY29tIiB0YXJnZXQ9Il9ibGFuayI+ZGVhZGJlZWZAZ29vZ2xlLmNvbTwvYT4m Z3Q7IHdyb3RlOjxvOnA+PC9vOnA+PC9wPg0KPGJsb2NrcXVvdGUgc3R5bGU9ImJvcmRlcjpub25l O2JvcmRlci1sZWZ0OnNvbGlkICNDQ0NDQ0MgMS4wcHQ7cGFkZGluZzowY20gMGNtIDBjbSA2LjBw dDttYXJnaW4tbGVmdDo0LjhwdDttYXJnaW4tcmlnaHQ6MGNtIj4NCjxkaXY+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj5JbiB0aGUgY3VycmVudCBzdGF0ZSBvZiBXZWJSVEMgMS4wLCB0cmFjayBJRHMg YXJlIG5vdCBndWFyYW50ZWVkIHRvIGJlIHN5bW1ldHJpY2FsIGJldHdlZW4gdGhlIHNlbmRpbmcg YW5kIHJlY2VpdmluZyBQZWVyQ29ubmVjdGlvbi4gVGhpcyBpcyBiZWNhdXNlICZxdW90O2FkZFRy YWNrJnF1b3Q7IG5vdCBvbmx5IGNyZWF0ZXMgYW4gUnRwU2VuZGVyLCBidXQgYSB3aG9sZSBSdHBU cmFuc2NlaXZlciwgd2hpY2ggaGFzIGFuIFJ0cFJlY2VpdmVyLA0KIHdoaWNoIGhhcyBhIE1lZGlh U3RyZWFtVHJhY2sgd2l0aCBhIGdlbmVyYXRlZCBJRC4gU28gaWYgJnF1b3Q7YWRkVHJhY2smcXVv dDsgaXMgY2FsbGVkLCBhbmQgYSByZW1vdGUgZGVzY3JpcHRpb24gaXMgc2V0IGxhdGVyLCBpdCdz IHRoZSBNSUQgdGhhdCBjb3JyZWxhdGVzIHRoZSAmcXVvdDttPSZxdW90OyBzZWN0aW9uIHdpdGgg dGhlIHRyYWNrLCBub3QgdGhlIHRyYWNrIElELCBhbmQgdGhlIHRyYWNrIElEIGluIFNEUCBpcyBl ZmZlY3RpdmVseSBpZ25vcmVkLjxvOnA+PC9vOnA+PC9wPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+VGhpcyBpcyBhbGwgcmVsYXRlZCB0byB0aGUgJnF1b3Q7ZWFybHkgbWVkaWEmcXVv dDsgZnVuY3Rpb25hbGl0eSwgYW5kIGlzIGV4cGxhaW5lZCBmdXJ0aGVyIGluIGEgYmxvZyBwb3N0 IGJ5IEphbi1JdmFyOyBzZWUgdGhlICZxdW90O0NvcnJlbGF0ZSBieSB0cmFuc2NlaXZlci5taWQm cXVvdDsgc2VjdGlvbjombmJzcDs8YSBocmVmPSJodHRwczovL2Jsb2cubW96aWxsYS5vcmcvd2Vi cnRjL3RoZS1ldm9sdXRpb24tb2Ytd2VicnRjLyIgdGFyZ2V0PSJfYmxhbmsiPmh0dHBzOi8vYmxv Zy5tb3ppbGxhLm9yZy93ZWJydGMvdGhlLWV2b2x1dGlvbi1vZi13ZWJydGMvPC9hPjxvOnA+PC9v OnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8 L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5TbywgdGhlIHF1 ZXN0aW9uIGJlY2FtZSAmcXVvdDt3aHkgc2lnbmFsIHRyYWNrIElEcyBhdCBhbGw/JnF1b3Q7IFRo aXMgd2FzIGJyb3VnaHQgdXAgaW4gYSBNYXkgdmlydHVhbCBpbnRlcmltICg8YSBocmVmPSJodHRw czovL3d3dy53My5vcmcvMjAxMS8wNC93ZWJydGMvd2lraS9NYXlfMl8yMDE3IiB0YXJnZXQ9Il9i bGFuayI+aHR0cHM6Ly93d3cudzMub3JnLzIwMTEvMDQvd2VicnRjL3dpa2kvTWF5XzJfMjAxNzwv YT4pLCBhbmQNCiB3ZSBkZWNpZGVkIHRvIGludmVzdGlnYXRlIHJlbW92aW5nIHRoZW0uIFRvIG15 IGtub3dsZWRnZSB0aGlzIHRvcGljIGhhc24ndCBiZWVuIGJyb3VnaHQgdXAgb24gdGhpcyBtYWls aW5nIGxpc3QgeWV0LjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj5JcyB0aGlzIHNvbWV0aGluZyBzdGlsbCB3b3J0aCBjb25zaWRlcmluZywgb3Ig aXMgaXQgdG9vIGxhdGU/ICZxdW90O2E9bXNpZCZxdW90OyB3b3VsZCBzd2l0Y2ggdG8gb25seSBj b250YWluaW5nIHRoZSBzdHJlYW0gSUQsIG5vdCB0aGUgdHJhY2sgSUQuIEltcGxlbWVudGVycyB3 b3VsZCBwcmVzdW1hYmx5IGhhdmUgYSB0cmFuc2l0aW9uYWwgcGVyaW9kIHdoZXJlIHRoZXkgc3Vw cG9ydCBwYXJzaW5nIGJvdGggZm9ybXMgb2YgJnF1b3Q7YT1tc2lkJnF1b3Q7LA0KIGFmdGVyIHdo aWNoIHRoZXkgc3RhcnQgZ2VuZXJhdGluZyB0aGUgbmV3IGZvcm1hdCwgYXMgd2UndmUgZG9uZSBm b3Igb3RoZXIgdGhpbmdzLjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj5UaGUgYmVuZWZpdHMgYXJlIHRoYXQgdGhlIFNEUCB3b3VsZCBiZSBzbGln aHRseSBzbWFsbGVyLCBhbmQgdGhlIGNvbXBsZXhpdHkgb2YgdGhlIHN0YW5kYXJkcyBjb3VsZCBi ZSBzbGlnaHRseSByZWR1Y2VkLiBUaGUgZG93bnNpZGUgaXMgdGhhdCBtb3JlIGFwcGxpY2F0aW9u cyB0aGF0IHJlbHkgb24gdHJhY2sgSURzIHdvdWxkIG5lZWQgdG8gYmUgdXBkYXRlZCAodGhvdWdo IG1hbnkgd2lsbCBuZWVkIHRvIGJlDQogdXBkYXRlZCBhbnl3YXkpLjxvOnA+PC9vOnA+PC9wPg0K PC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+ DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5SZWdhcmRsZXNzIG9mIHRoZSBv dXRjb21lIG9mIHRoaXMgZGVjaXNpb24sICZxdW90O21tdXNpYy1tc2lkJnF1b3Q7IHJlYWxseSBv dWdodCB0byBiZSB1cGRhdGVkIGJlZm9yZSBwdWJsaWNhdGlvbi4gSXQncyBiZWVuIG91dCBvZiBz eW5jIHdpdGggV2ViUlRDIDEuMCBmb3IgYWJvdXQgYSB5ZWFyOyBoZXJlJ3MgdGhlIGZpcnN0IGVk aXRvcidzIGRyYWZ0IHRoYXQgYnJva2UgdGhlIHRyYWNrIElEIHN5bW1ldHJ5OiZuYnNwOzxhIGhy ZWY9Imh0dHBzOi8vdzNjLmdpdGh1Yi5pby93ZWJydGMtcGMvYXJjaGl2ZXMvMjAxNjA3MjIvd2Vi cnRjLmh0bWwiIHRhcmdldD0iX2JsYW5rIj5odHRwczovL3czYy5naXRodWIuaW8vd2VicnRjLXBj L2FyY2hpdmVzLzIwMTYwNzIyL3dlYnJ0Yy5odG1sPC9hPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+ DQo8L2Rpdj4NCjwvYmxvY2txdW90ZT4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86 cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9ib2R5Pg0KPC9odG1sPg0K --_000_7594FB04B1934943A5C02806D1A2204B4CCADFB5ESESSMB109erics_-- From nobody Tue Aug 8 09:11:30 2017 Return-Path: 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 A968013241C for ; Tue, 8 Aug 2017 09:11:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.2 X-Spam-Level: X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no 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 RsFoaLsQ0Z4y for ; Tue, 8 Aug 2017 09:11:26 -0700 (PDT) Received: from alum-mailsec-scanner-1.mit.edu (alum-mailsec-scanner-1.mit.edu [18.7.68.12]) by ietfa.amsl.com (Postfix) with ESMTP id 210A11326B1 for ; Tue, 8 Aug 2017 09:11:25 -0700 (PDT) X-AuditID: 1207440c-c4bff70000000b4f-c7-5989e2ad7dfe Received: from outgoing-alum.mit.edu (OUTGOING-ALUM.MIT.EDU [18.7.68.33]) (using TLS with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by alum-mailsec-scanner-1.mit.edu (Symantec Messaging Gateway) with SMTP id AE.16.02895.DA2E9895; Tue, 8 Aug 2017 12:11:25 -0400 (EDT) Received: from PaulKyzivatsMBP.localdomain (c-24-62-227-142.hsd1.ma.comcast.net [24.62.227.142]) (authenticated bits=0) (User authenticated as pkyzivat@ALUM.MIT.EDU) by outgoing-alum.mit.edu (8.13.8/8.12.4) with ESMTP id v78GBOpx004979 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT) for ; Tue, 8 Aug 2017 12:11:24 -0400 To: mmusic@ietf.org References: <7594FB04B1934943A5C02806D1A2204B4CCADF58@ESESSMB109.ericsson.se> From: Paul Kyzivat Message-ID: <0d4c8602-0057-cafb-4c33-e6e72c963b60@alum.mit.edu> Date: Tue, 8 Aug 2017 12:11:23 -0400 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:52.0) Gecko/20100101 Thunderbird/52.2.1 MIME-Version: 1.0 In-Reply-To: <7594FB04B1934943A5C02806D1A2204B4CCADF58@ESESSMB109.ericsson.se> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 8bit X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFnrPIsWRmVeSWpSXmKPExsUixO6iqLv2UWekwfVHghZTlz9mcWD0WLLk J1MAYxSXTUpqTmZZapG+XQJXRvf+G+wFNy0qjt9rYWxg3KPXxcjJISFgIrF54kWmLkYuDiGB HUwSzTNfQTnfmCR+z7jNDOIIC7QzSmyfB+JwcogICEvMePuXDcQWEvCV+Nq6ACzOJqAlMefQ f5YuRg4OXgF7iVk/0kDCLAIqElvnrAUrERVIk5jx/TqYzSsgKHFy5hMWEJtTwE/i6Pd9rCA2 s4CZxLzND5khbHGJW0/mM0HY8hLNW2czT2Dkn4WkfRaSlllIWmYhaVnAyLKKUS4xpzRXNzcx M6c4NVm3ODkxLy+1SNdQLzezRC81pXQTIyQseXYwflsnc4hRgINRiYf3xp7OSCHWxLLiytxD jJIcTEqivJu0gUJ8SfkplRmJxRnxRaU5qcWHGCU4mJVEeBlOAeV4UxIrq1KL8mFS0hwsSuK8 qkvU/YQE0hNLUrNTUwtSi2CyMhwcShK8/x8ANQoWpaanVqRl5pQgpJk4OEGG8wANF3oIMry4 IDG3ODMdIn+KUZfj18ytX5iEWPLy81KlxHmvghQJgBRllObBzYGlk1eM4kBvCfOaglTxAFMR 3KRXQEuYgJZE+IItKUlESEk1MOq/r81k4sprj01NnmseI/sq7NfTOzvfdZ/YqG9lcP1A+DQ2 95XVAYEZPUX6H+RzP6qr1nuZyO77z5635Qvvo39M3+f2PXXXempWVpdymfXB/9DSR+GezfuX lyUVbtwV6M6lciLVrfhQ1P6VPruFFSJmR2Rc8DWbd+LiyvU9vp8Yd9yJr8k/rMRSnJFoqMVc VJwIAJy14GACAwAA Archived-At: Subject: Re: [MMUSIC] Draft new version: draft-dtls-sdp-28 [was: [Gen-art] Gen-ART Last Call review of draft-ietf-mmusic-dtls-sdp-27] X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 08 Aug 2017 16:11:28 -0000 Looks good to me. Thanks, Paul On 8/5/17 1:46 PM, Christer Holmberg wrote: > Hi, > > Based on the gen-art comments by Paul, I have merged the PR and submitted a new version (-28) of draft-dtls-sdp. > > Note that the draft now replaces the reference to RFC 4572 within RFC 5763 to a reference to RFC 8122. > > Regards, > > Christer > > -----Original Message----- > From: Christer Holmberg [mailto:christer.holmberg@ericsson.com] > Sent: 31 July 2017 19:20 > To: Paul Kyzivat ; Ben Campbell > Cc: draft-ietf-mmusic-dtls-sdp.all@ietf.org; General Area Review Team ; IETF MMUSIC WG > Subject: RE: [Gen-art] Gen-ART Last Call review of draft-ietf-mmusic-dtls-sdp-27 > > PR updated. > > Regards, > > Christer > > -----Original Message----- > From: Paul Kyzivat [mailto:pkyzivat@alum.mit.edu] > Sent: 31 July 2017 18:03 > To: Christer Holmberg ; Ben Campbell > Cc: draft-ietf-mmusic-dtls-sdp.all@ietf.org; General Area Review Team ; IETF MMUSIC WG > Subject: Re: [Gen-art] Gen-ART Last Call review of draft-ietf-mmusic-dtls-sdp-27 > > On 7/31/17 4:05 AM, Christer Holmberg wrote: >> Hi Paul, >> >>>> PR created: >>>> >>>> https://github.com/cdh4u/draft-dtls-sdp/pull/34 >>> >>> This leaves RFC5763 in an inconsistent state: >>> - the reference to 8122 in section 5 isn't backed up with an entry in >>> the references section >> >> In the PR, I DO add 8122 to the reference section of 5763 :) > > Oh, sorry. > >>> - there is still a reference to 4572 in the introduction. >> >> I could add a statement, saying that the reference in the Introduction is updated. > > That works for me. > > Thanks, > Paul > >> Regards, >> >> Christer >> >> >> >> >> Otherwise looks right. >> >> Thanks, >> Paul >> >>> Regards, >>> >>> Christer >>> >>> -----Original Message----- >>> From: Christer Holmberg [mailto:christer.holmberg@ericsson.com] >>> Sent: 29 July 2017 23:38 >>> To: Paul Kyzivat ; Ben Campbell >>> >>> Cc: draft-ietf-mmusic-dtls-sdp.all@ietf.org; General Area Review Team >>> ; IETF MMUSIC WG >>> Subject: RE: [Gen-art] Gen-ART Last Call review of >>> draft-ietf-mmusic-dtls-sdp-27 >>> >>> Hi, >>> >>>>>>>> Regarding the reference to RFC 4572, the new text in section >>>>>>>> 10.2.1 references RFC 4572. We earlier agreed we were not going to update that text, and keep an informative reference to RFC 4572. >>>>>>> >>>>>>> OK, I guess I remember that now. Is it considered acceptable to >>>>>>> issue a new document with a reference to an obsolete document when it isn't to highlight a difference from the current document? >>>>>>> >>>>>>> Since this is a review for the teleconference, I'll just leave that for the IESG folk to decide. >>>>>> >>>>>> As far as I know, there’s no hard and fast rule about this. It >>>>>> really depends on whether the difference between the new and >>>>>> obsolete dependencies are material to the draft. I do think we (i.e. >>>>>> the IESG) would favor referencing the new RFC, but would be open >>>>>> to arguments about why a WG chose to reference the obsolete >>>>>> version >>>>>> >>>>>> Does anyone recall the reasoning in this instance? >>>>> >>>>> Just to make sure we are on the same page, there are TWO references to RFC 4572 in the draft. >>>>> >>>>> The FIRST reference is in section 8, where it is used to reference >>>>> an example in RFC 4572. The same example exists in RFC 8122, so we can change that reference. >>>>> >>>>> The SECOND reference is in section 10.2.1, as part of the updated >>>>> text for RFC 5763. Now, RFC 5763 references RFC 4572 in 4 >>>>> difference places, so if we change the >reference to RFC 8122 in >>>>> the text updated by the draft we would also have to do it in every other place. That was the reason we decided not to do it (I have no problem doing it that's what IESG wants, though). >>>> >>>> Thanks for pointing that out. I just looked at that to size up the >>>> situation. Of those four references, three of them are in section 5 >>>> and will all be replaced by the new text in this document. The remaining reference is simply a general one in the introduction. And then in addition there is the actual reference text in the normative references. >>>> >>>> ISTM that it would be sufficient to update the reference in the new >>>> text for section 5 and then add a general statement to update all references to 4572 to refer to 8122. >>>> >>>> But again, this is really an IESG issue at this point. >>> >>> Or, we could just go ahead and do it :) >>> >>> Regards, >>> >>> Christer >>> >>>> >>>> >>>> >>>>>> -----Original Message----- >>>>>> From: Christer Holmberg [mailto:christer.holmberg@ericsson.com] >>>>>> Sent: 29 July 2017 01:07 >>>>>> To: Paul Kyzivat ; >>>>>> draft-ietf-mmusic-dtls-sdp.all@ietf.org >>>>>> Cc: General Area Review Team ; IETF MMUSIC WG >>>>>> >>>>>> Subject: RE: [Gen-art] Gen-ART Last Call review of >>>>>> draft-ietf-mmusic-dtls-sdp-27 Hi Paul, Thanks for the review. I'll >>>>>> fix references. >>>>>> Regards, >>>>>> Christer >>>>>> -----Original Message----- >>>>>> From: Paul Kyzivat [mailto:pkyzivat@alum.mit.edu] >>>>>> Sent: 28 July 2017 04:01 >>>>>> To: draft-ietf-mmusic-dtls-sdp.all@ietf.org >>>>>> Cc: General Area Review Team ; IETF MMUSIC WG >>>>>> >>>>>> Subject: [Gen-art] Gen-ART Last Call review of >>>>>> draft-ietf-mmusic-dtls-sdp-27 I am the assigned Gen-ART reviewer for this draft. The General Area Review Team (Gen-ART) reviews all IETF documents being processed by the IESG for the IETF Chair. Please wait for direction from your document shepherd or AD before posting a new version of the draft. For more information, please see the FAQ at <​http://wiki.tools.ietf.org/area/gen/trac/wiki/GenArtfaq>. >>>>>> Document: draft-ietf-mmusic-dtls-sdp-27 >>>>>> Reviewer: Paul Kyzivat >>>>>> Review Date: 2017-07-07 >>>>>> IETF LC End Date: 2017-07-24 >>>>>> IESG Telechat date: 2017-08-15 >>>>>> Summary: >>>>>> This draft is basically ready for publication, but has nits that should be fixed before publication. >>>>>> (These nits were reported by IdNits. I apologize for not noticing >>>>>> these during my Last Call review.) >>>>>> Issues: >>>>>> Major: 0 >>>>>> Minor: 0 >>>>>> Nits: 2 >>>>>> (1) NIT: Unused Reference: 'RFC5245' is defined on line 1065, but >>>>>> no explicit reference was found in the text This is now redundant because all the references in the text have been changed to draft-ietf-ice-rfc5245bis. >>>>>> (2) NIT: Obsolete informational reference (is this intentional?): >>>>>> RFC >>>>>> 4572 This is now obsolete because it has been replaced by RFC8122. This draft should now be referencing that. >>>>> >>>> >>> >> > > _______________________________________________ > mmusic mailing list > mmusic@ietf.org > https://www.ietf.org/mailman/listinfo/mmusic > From nobody Tue Aug 8 09:52:48 2017 Return-Path: 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 831C51324D5 for ; Tue, 8 Aug 2017 09:52:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.2 X-Spam-Level: X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no 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 NYk_4FgNsIgW for ; Tue, 8 Aug 2017 09:52:43 -0700 (PDT) Received: from rfc-editor.org (rfc-editor.org [4.31.198.49]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 221E8132139 for ; Tue, 8 Aug 2017 09:52:43 -0700 (PDT) Received: by rfc-editor.org (Postfix, from userid 30) id 7B757B80E45; Tue, 8 Aug 2017 09:52:31 -0700 (PDT) To: schulzrinne@cs.columbia.edu, anup@netscape.com, robla@real.com, ben@nostrum.com, aamelnikov@fastmail.fm, adam@nostrum.com, bo.burman@ericsson.com, fandreas@cisco.com X-PHP-Originating-Script: 30:errata_mail_lib.php From: RFC Errata System Cc: persgray@gmail.com, mmusic@ietf.org, rfc-editor@rfc-editor.org Content-Type: text/plain; charset=UTF-8 Message-Id: <20170808165231.7B757B80E45@rfc-editor.org> Date: Tue, 8 Aug 2017 09:52:31 -0700 (PDT) Archived-At: Subject: [MMUSIC] [Technical Errata Reported] RFC2326 (5079) X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 08 Aug 2017 16:52:46 -0000 The following errata report has been submitted for RFC2326, "Real Time Streaming Protocol (RTSP)". -------------------------------------- You may review the report below and at: http://www.rfc-editor.org/errata/eid5079 -------------------------------------- Type: Technical Reported by: Vadim Zhukov Section: 10.8 Original Text ------------- S->C: GET_PARAMETER rtsp://example.com/fizzle/foo RTSP/1.0 CSeq: 431 Content-Type: text/parameters Session: 12345678 Content-Length: 15 packets_received jitter Corrected Text -------------- S->C: GET_PARAMETER rtsp://example.com/fizzle/foo RTSP/1.0 CSeq: 431 Content-Type: text/parameters Session: 12345678 Content-Length: 24 packets_received jitter Notes ----- The Content-Length value is wrong, it should be either 24 (as proposed) or 26, depending on end-of-line marker used for message content. Instructions: ------------- This erratum is currently posted as "Reported". If necessary, please use "Reply All" to discuss whether it should be verified or rejected. When a decision is reached, the verifying party can log in to change the status and edit the report, if necessary. -------------------------------------- RFC2326 (no draft string recorded) -------------------------------------- Title : Real Time Streaming Protocol (RTSP) Publication Date : April 1998 Author(s) : H. Schulzrinne, A. Rao, R. Lanphier Category : PROPOSED STANDARD Source : Multiparty Multimedia Session Control RAI Area : Real-time Applications and Infrastructure Stream : IETF Verifying Party : IESG From nobody Tue Aug 8 13:10:27 2017 Return-Path: X-Original-To: mmusic@ietf.org Delivered-To: mmusic@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id B39591329AF; Tue, 8 Aug 2017 13:10:26 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: Rich Salz To: Cc: draft-ietf-mmusic-dtls-sdp.all@ietf.org, ietf@ietf.org, mmusic@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.58.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <150222302662.12343.4196075098931297625@ietfa.amsl.com> Date: Tue, 08 Aug 2017 13:10:26 -0700 Archived-At: Subject: [MMUSIC] Secdir telechat review of draft-ietf-mmusic-dtls-sdp-28 X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.22 List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 08 Aug 2017 20:10:27 -0000 Reviewer: Rich Salz Review result: Ready Issues I raised in the -22 review have been addressed, and a quick read showed nothing new to complain about :) From nobody Tue Aug 8 14:11:43 2017 Return-Path: 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 6D9661325CD; Tue, 8 Aug 2017 14:11:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.22 X-Spam-Level: X-Spam-Status: No, score=-4.22 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no 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 Ja05cenR89oE; Tue, 8 Aug 2017 14:11:39 -0700 (PDT) Received: from sessmg22.ericsson.net (sessmg22.ericsson.net [193.180.251.58]) (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 E36241325EB; Tue, 8 Aug 2017 14:11:38 -0700 (PDT) X-AuditID: c1b4fb3a-81bff70000001b2f-a1-598a2908b63a Received: from ESESSHC018.ericsson.se (Unknown_Domain [153.88.183.72]) by sessmg22.ericsson.net (Symantec Mail Security) with SMTP id A8.A2.06959.8092A895; Tue, 8 Aug 2017 23:11:36 +0200 (CEST) Received: from ESESSMB109.ericsson.se ([169.254.9.91]) by ESESSHC018.ericsson.se ([153.88.183.72]) with mapi id 14.03.0352.000; Tue, 8 Aug 2017 23:11:36 +0200 From: Christer Holmberg To: Rich Salz , "secdir@ietf.org" CC: "draft-ietf-mmusic-dtls-sdp.all@ietf.org" , "ietf@ietf.org" , "mmusic@ietf.org" Thread-Topic: Secdir telechat review of draft-ietf-mmusic-dtls-sdp-28 Thread-Index: AQHTEIJhHC/9q3fc0USxdaOFO/icVqJ69OJg Date: Tue, 8 Aug 2017 21:11:36 +0000 Message-ID: <7594FB04B1934943A5C02806D1A2204B4CCB48D9@ESESSMB109.ericsson.se> References: <150222302662.12343.4196075098931297625@ietfa.amsl.com> In-Reply-To: <150222302662.12343.4196075098931297625@ietfa.amsl.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [153.88.183.154] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFupkkeLIzCtJLcpLzFFi42KZGbHdQ5dDsyvS4EmjvsWOuzvYLJ5tnM9i MXX5YxaL/1s6WSw+LHzI4sDqMfnIAmaPJUt+MgUwRXHZpKTmZJalFunbJXBlnFxdWdDFWjH/ yRLGBsYfLF2MnBwSAiYSD7d/ZOpi5OIQEjjCKLHq1zdWCGcRo8T3XRfZuxg5ONgELCS6/2mD NIgIuEps6/3MDFLDLLAQqObsJ0aQhLCAi8SF22eZYIr+bnvKCGEbSWxYeA3MZhFQkVjwdSHY Zl4BX4lzD1aAxYUEnCXu3t3OCmJzAs15snwRWA2jgJjE91NrwGYyC4hL3HoynwniagGJJXvO M0PYohIvH/9jhbCVJBbd/swEcjOzgKbE+l36EK2KElO6H7JDrBWUODnzCcsERtFZSKbOQuiY haRjFpKOBYwsqxhFi1OLi3PTjYz0Uosyk4uL8/P08lJLNjECI+jglt9WOxgPPnc8xCjAwajE w3tmSWekEGtiWXFl7iFGCQ5mJRFeM42uSCHelMTKqtSi/Pii0pzU4kOM0hwsSuK8DvsuRAgJ pCeWpGanphakFsFkmTg4pRoYtR/M5lqew9SXYXpO2cYzNfOMyneOuua0V/q+ffLqpa/FP7PO vfF7Vv22fPna/GV61/cetD9WcWPvL6tVfs+YCha0MXpdv20vtOkQ94+3obPf7BKborZyr2ut u5CDyppoXkvZO/1Tkhc+X7lazlmv0Pn7u5jrp2bJGM2qLbhq1JNxsFK70FlViaU4I9FQi7mo OBEAdNkJaJwCAAA= Archived-At: Subject: Re: [MMUSIC] Secdir telechat review of draft-ietf-mmusic-dtls-sdp-28 X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 08 Aug 2017 21:11:41 -0000 VGhhbmtzLCBSaWNoISA6KQ0KDQpSZWdhcmRzLA0KDQpDaHJpc3Rlcg0KDQotLS0tLU9yaWdpbmFs IE1lc3NhZ2UtLS0tLQ0KRnJvbTogUmljaCBTYWx6IFttYWlsdG86cnNhbHpAYWthbWFpLmNvbV0g DQpTZW50OiAwOCBBdWd1c3QgMjAxNyAyMjoxMA0KVG86IHNlY2RpckBpZXRmLm9yZw0KQ2M6IGRy YWZ0LWlldGYtbW11c2ljLWR0bHMtc2RwLmFsbEBpZXRmLm9yZzsgaWV0ZkBpZXRmLm9yZzsgbW11 c2ljQGlldGYub3JnDQpTdWJqZWN0OiBTZWNkaXIgdGVsZWNoYXQgcmV2aWV3IG9mIGRyYWZ0LWll dGYtbW11c2ljLWR0bHMtc2RwLTI4DQoNClJldmlld2VyOiBSaWNoIFNhbHoNClJldmlldyByZXN1 bHQ6IFJlYWR5DQoNCklzc3VlcyBJIHJhaXNlZCBpbiB0aGUgLTIyIHJldmlldyBoYXZlIGJlZW4g YWRkcmVzc2VkLCBhbmQgYSBxdWljayByZWFkIHNob3dlZCBub3RoaW5nIG5ldyB0byBjb21wbGFp biBhYm91dCA6KQ0KDQoNCg== From nobody Fri Aug 11 11:07:29 2017 Return-Path: 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 287E3132197; Fri, 11 Aug 2017 11:07:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.201 X-Spam-Level: X-Spam-Status: No, score=-4.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham autolearn_force=no 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 3KMyCVXYJq1c; Fri, 11 Aug 2017 11:07:22 -0700 (PDT) Received: from alum-mailsec-scanner-2.mit.edu (alum-mailsec-scanner-2.mit.edu [18.7.68.13]) by ietfa.amsl.com (Postfix) with ESMTP id 63A791320B5; Fri, 11 Aug 2017 11:07:22 -0700 (PDT) X-AuditID: 1207440d-a07ff70000000c0c-93-598df25932ea Received: from outgoing-alum.mit.edu (OUTGOING-ALUM.MIT.EDU [18.7.68.33]) (using TLS with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by alum-mailsec-scanner-2.mit.edu (Symantec Messaging Gateway) with SMTP id 9B.57.03084.952FD895; Fri, 11 Aug 2017 14:07:21 -0400 (EDT) Received: from PaulKyzivatsMBP.localdomain (c-24-62-227-142.hsd1.ma.comcast.net [24.62.227.142]) (authenticated bits=0) (User authenticated as pkyzivat@ALUM.MIT.EDU) by outgoing-alum.mit.edu (8.13.8/8.12.4) with ESMTP id v7BI7K5h030628 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Fri, 11 Aug 2017 14:07:21 -0400 From: Paul Kyzivat To: draft-ietf-mmusic-dtls-sdp.all@ietf.org Cc: General Area Review Team , IETF MMUSIC WG Message-ID: <63e0453a-7f75-7e8c-e3b5-73fafadc0308@alum.mit.edu> Date: Fri, 11 Aug 2017 14:07:20 -0400 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:52.0) Gecko/20100101 Thunderbird/52.2.1 MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 8bit X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFvrMIsWRmVeSWpSXmKPExsUixO6iqBv5qTfS4PkeHYsdd3ewWVx99ZnF YuryxywOzB5LlvxkCmCM4rJJSc3JLEst0rdL4Mq4Nuclc8ErlorHq2cyNzD+Ye5i5OSQEDCR 2HjtBVsXIxeHkMAOJolX39+yQzgPmSTmTv3JBFLFJqAlMefQfxYQW1jAUuLM7lOMILaIgLZE x+Q2VhCbWSBK4vjnJWD1vAL2Esubz4LVswioShy5fw/MFhVIk5jx/TozRI2gxMmZT1gges0k 5m1+yAxhi0vcejKfCcKWl2jeOpt5AiPfLCQts5C0zELSMgtJywJGllWMcok5pbm6uYmZOcWp ybrFyYl5ealFukZ6uZkleqkppZsYISHJu4Px/zqZQ4wCHIxKPLwVZ3sjhVgTy4orcw8xSnIw KYnyJvgAhfiS8lMqMxKLM+KLSnNSiw8xSnAwK4nw8r0FyvGmJFZWpRblw6SkOViUxHnVlqj7 CQmkJ5akZqemFqQWwWRlODiUJHgZPgI1ChalpqdWpGXmlCCkmTg4QYbzAA1vAKnhLS5IzC3O TIfIn2I05mj6sOULE8evmVu/MAmx5OXnpUqJ80p/ACoVACnNKM2DmwZLK68YxYGeE+YNBxnI A0xJcPNeAa1iAlrV5wO2qiQRISXVwJjFy5DRbPGVNX5SE0PZ77z02uj06j8aJ5lDG7Sus1UK 7yx/7XVvR7nvqth1ky/OLXcOEXdeLXD22cZpd396cT5fHRwTVZNwax3vKe2g6a/lld1XqVf2 rUreJbeIfWf6w3OL6hayrqmxLDz4WzYiqv3WJEF36X3/JVWWPNy2kCn82JStglefOimxFGck GmoxFxUnAgDheHFwBgMAAA== Archived-At: Subject: [MMUSIC] Telechat review of draft-ietf-mmusic-dtls-sdp-28 X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 11 Aug 2017 18:07:24 -0000 I am the assigned Gen-ART reviewer for this draft. The General Area Review Team (Gen-ART) reviews all IETF documents being processed by the IESG for the IETF Chair. Please wait for direction from your document shepherd or AD before posting a new version of the draft. For more information, please see the FAQ at <​http://wiki.tools.ietf.org/area/gen/trac/wiki/GenArtfaq>. Document: draft-ietf-mmusic-dtls-sdp-28 Reviewer: Paul Kyzivat Review Date: 2017-07-07 IETF LC End Date: 2017-07-24 IESG Telechat date: 2017-08-17 Summary: This draft is ready for publication as a Standards Track RFC. From nobody Fri Aug 11 14:19:16 2017 Return-Path: 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 1DDE8132439; Fri, 11 Aug 2017 14:19:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.221 X-Spam-Level: X-Spam-Status: No, score=-4.221 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=ham autolearn_force=no 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 GwW9v8bzMkzu; Fri, 11 Aug 2017 14:19:08 -0700 (PDT) Received: from sessmg22.ericsson.net (sessmg22.ericsson.net [193.180.251.58]) (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 A4B57132413; Fri, 11 Aug 2017 14:19:07 -0700 (PDT) X-AuditID: c1b4fb3a-9e1d49c0000051a3-10-598e1f492b79 Received: from ESESSHC002.ericsson.se (Unknown_Domain [153.88.183.24]) by sessmg22.ericsson.net (Symantec Mail Security) with SMTP id B0.62.20899.94F1E895; Fri, 11 Aug 2017 23:19:06 +0200 (CEST) Received: from ESESSMB109.ericsson.se ([169.254.9.91]) by ESESSHC002.ericsson.se ([153.88.183.24]) with mapi id 14.03.0352.000; Fri, 11 Aug 2017 23:18:27 +0200 From: Christer Holmberg To: Paul Kyzivat , "draft-ietf-mmusic-dtls-sdp.all@ietf.org" CC: General Area Review Team , IETF MMUSIC WG Thread-Topic: Telechat review of draft-ietf-mmusic-dtls-sdp-28 Thread-Index: AQHTEsywJTg4Sc8bwkavmNiA57T2YqJ/qTpg Date: Fri, 11 Aug 2017 21:18:27 +0000 Message-ID: <7594FB04B1934943A5C02806D1A2204B4CCB942D@ESESSMB109.ericsson.se> References: <63e0453a-7f75-7e8c-e3b5-73fafadc0308@alum.mit.edu> In-Reply-To: <63e0453a-7f75-7e8c-e3b5-73fafadc0308@alum.mit.edu> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [153.88.183.154] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFmphkeLIzCtJLcpLzFFi42KZGbFdQtdLvi/S4FyixY67O9gsrr76zGIx dfljFosVGw6wOrB4/H3/gcljyZKfTAFMUVw2Kak5mWWpRfp2CVwZrQ8+sRXM4qrYem41awPj D84uRk4OCQETic2LXrB0MXJxCAkcYZRYM7+TCcJZzCjR9nsLYxcjBwebgIVE9z9tkLiIQCOj ROP0/cwg3cwCwRJ7929jBLGFBWwlZjXfYgWxRQTsJN6fvg5lG0m0TmljAbFZBFQlJp9/AdbL K+ArcXPDGXYQW0jAXuLTvi6wGk4BB4m3X9eB2YwCYhLfT61hgtglLnHryXwmiKsFJJbsOc8M YYtKvHz8jxXCVpJYdPszE8jNzAKaEut36UO0KkpM6X7IDrFWUOLkzCcsExhFZyGZOguhYxaS jllIOhYwsqxiFC1OLS7OTTcy0kstykwuLs7P08tLLdnECIybg1t+W+1gPPjc8RCjAAejEg+v rVBfpBBrYllxZe4hRgkOZiURXi4ZoBBvSmJlVWpRfnxRaU5q8SFGaQ4WJXFeh30XIoQE0hNL UrNTUwtSi2CyTBycUg2MObWumrM3OqlNz15dKeL5u21qloAW60sJ8/7oldXvi7Sz1/AtSL9Q vqpIOtHy1JI610SG2/nHJ6ZFLTj4dsWDCXM+dzycOOO61u2zPzqFFnArcUjJJbHdSUu9wDr1 8MT5RxK5pmjxijttbL28XZSf+Uis86bHWlyxa9LcXzHw5PBP1XVmMilTYinOSDTUYi4qTgQA 9KRM15cCAAA= Archived-At: Subject: Re: [MMUSIC] Telechat review of draft-ietf-mmusic-dtls-sdp-28 X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 11 Aug 2017 21:19:10 -0000 VGhhbmsgWW91LCBQYXVsISA6KQ0KDQpSZWdhcmRzLA0KDQpDaHJpc3Rlcg0KDQotLS0tLU9yaWdp bmFsIE1lc3NhZ2UtLS0tLQ0KRnJvbTogUGF1bCBLeXppdmF0IFttYWlsdG86cGt5eml2YXRAYWx1 bS5taXQuZWR1XSANClNlbnQ6IDExIEF1Z3VzdCAyMDE3IDIwOjA3DQpUbzogZHJhZnQtaWV0Zi1t bXVzaWMtZHRscy1zZHAuYWxsQGlldGYub3JnDQpDYzogR2VuZXJhbCBBcmVhIFJldmlldyBUZWFt IDxnZW4tYXJ0QGlldGYub3JnPjsgSUVURiBNTVVTSUMgV0cgPG1tdXNpY0BpZXRmLm9yZz4NClN1 YmplY3Q6IFRlbGVjaGF0IHJldmlldyBvZiBkcmFmdC1pZXRmLW1tdXNpYy1kdGxzLXNkcC0yOA0K DQpJIGFtIHRoZSBhc3NpZ25lZCBHZW4tQVJUIHJldmlld2VyIGZvciB0aGlzIGRyYWZ0LiBUaGUg R2VuZXJhbCBBcmVhIFJldmlldyBUZWFtIChHZW4tQVJUKSByZXZpZXdzIGFsbCBJRVRGIGRvY3Vt ZW50cyBiZWluZyBwcm9jZXNzZWQgYnkgdGhlIElFU0cgZm9yIHRoZSBJRVRGIENoYWlyLiBQbGVh c2Ugd2FpdCBmb3IgZGlyZWN0aW9uIGZyb20geW91ciBkb2N1bWVudCBzaGVwaGVyZCBvciBBRCBi ZWZvcmUgcG9zdGluZyBhIG5ldyB2ZXJzaW9uIG9mIHRoZSBkcmFmdC4gRm9yIG1vcmUgaW5mb3Jt YXRpb24sIHBsZWFzZSBzZWUgdGhlIEZBUSBhdCA84oCLaHR0cDovL3dpa2kudG9vbHMuaWV0Zi5v cmcvYXJlYS9nZW4vdHJhYy93aWtpL0dlbkFydGZhcT4uDQoNCkRvY3VtZW50OiBkcmFmdC1pZXRm LW1tdXNpYy1kdGxzLXNkcC0yOA0KUmV2aWV3ZXI6IFBhdWwgS3l6aXZhdA0KUmV2aWV3IERhdGU6 IDIwMTctMDctMDcNCklFVEYgTEMgRW5kIERhdGU6IDIwMTctMDctMjQNCklFU0cgVGVsZWNoYXQg ZGF0ZTogMjAxNy0wOC0xNw0KDQpTdW1tYXJ5Og0KDQpUaGlzIGRyYWZ0IGlzIHJlYWR5IGZvciBw dWJsaWNhdGlvbiBhcyBhIFN0YW5kYXJkcyBUcmFjayBSRkMuDQoNCg== From nobody Fri Aug 11 14:48:08 2017 Return-Path: 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 1F1EC1243F3 for ; Fri, 11 Aug 2017 14:48:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.129 X-Spam-Level: X-Spam-Status: No, score=-1.129 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, HTML_OBFUSCATE_05_10=0.26, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_SORBS_SPAM=0.5, T_SPF_PERMERROR=0.01] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=telurix-com.20150623.gappssmtp.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 AEPgHY2zoVQV for ; Fri, 11 Aug 2017 14:48:06 -0700 (PDT) Received: from mail-pf0-x229.google.com (mail-pf0-x229.google.com [IPv6:2607:f8b0:400e:c00::229]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2A2DE1326B5 for ; Fri, 11 Aug 2017 14:47:32 -0700 (PDT) Received: by mail-pf0-x229.google.com with SMTP id t86so20504368pfe.2 for ; Fri, 11 Aug 2017 14:47:32 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=telurix-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=i7THcM+3BsC6NJccRFJISPyCaoO7HdAxRfRP8mdblkQ=; b=bBdzaqGOWKh1HTVeyZsVw1vTZFXDK7u/b+8PDJKYQCoLRVbBJsrZCjJaR5Mr2uc0we sMIiPL+JXa5614OmwNpYUPEaH49Id2RT46rigQmnzysn46yMBd1dPPjKgAbY0eyWdiPD UlOR+vpRhY6tnA37Op6BdRgAIt4MiOTfFGiPZacwhUZ3swYnQLrGWRFDJRrjnhrpqCkY ffBWtjJhO2AuTRzIxbnuL7Igr9tNeZ9QuOzjCN52ZOIwns84Gbs90JmxWeD0sdcjBrEI se1SQXd5GKMlaJNUeHzA0mxG7uM46FHHpq0FV30vyc8MUYJK5RZi0D6sbJsilwJfuwtz PogQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=i7THcM+3BsC6NJccRFJISPyCaoO7HdAxRfRP8mdblkQ=; b=oO+wh0/ZZSQht6Qk87dXqFLqZ+Jq8kRgSCEZ5xO1Ugu5g6lgV3lFSZ1KXlEIzS8hjC YSD3USNEZ5NRQA3ZYitolGHHkg021bPyeHuNtfKziVPSXdgeEE+NXAsZgsMdKgJD6T87 FGEV9CSIzaVdZ0SXp4dxM9DRbSPdPF6+bJMUdu8M4xdODpAMU2TNIGipSqhl4bV6pdif 3OeFfvcei13NE0w6UdaQZ5aNlRkoZoJtRorcT4kpgBHYK6NMjKr58ozwroBAopgcKA/6 XtiutoS93Z+tZPktDUCemCZkHNtEoUOaGUueWgp828XT5oEtEOekzdvmArC8FwxrUs9p nD2A== X-Gm-Message-State: AHYfb5gZw2dt3TFDL86h4MJwU+pPjTI3DvCp/zaXHPWMEfsIxNMu4arJ 9fmVVaK5x8dgVb8l X-Received: by 10.84.254.76 with SMTP id a12mr19990749pln.439.1502488051764; Fri, 11 Aug 2017 14:47:31 -0700 (PDT) Received: from mail-pg0-f42.google.com (mail-pg0-f42.google.com. [74.125.83.42]) by smtp.gmail.com with ESMTPSA id c7sm3190245pfg.29.2017.08.11.14.47.30 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 11 Aug 2017 14:47:31 -0700 (PDT) Received: by mail-pg0-f42.google.com with SMTP id l64so20018915pge.5; Fri, 11 Aug 2017 14:47:30 -0700 (PDT) X-Received: by 10.98.220.134 with SMTP id c6mr17977699pfl.253.1502488050706; Fri, 11 Aug 2017 14:47:30 -0700 (PDT) MIME-Version: 1.0 Received: by 10.100.133.150 with HTTP; Fri, 11 Aug 2017 14:47:30 -0700 (PDT) In-Reply-To: <63e0453a-7f75-7e8c-e3b5-73fafadc0308@alum.mit.edu> References: <63e0453a-7f75-7e8c-e3b5-73fafadc0308@alum.mit.edu> From: Roman Shpount Date: Fri, 11 Aug 2017 17:47:30 -0400 X-Gmail-Original-Message-ID: Message-ID: To: Paul Kyzivat Cc: draft-ietf-mmusic-dtls-sdp.all@ietf.org, General Area Review Team , IETF MMUSIC WG Content-Type: multipart/alternative; boundary="94eb2c14fc208ab0f60556814241" Archived-At: Subject: Re: [MMUSIC] Telechat review of draft-ietf-mmusic-dtls-sdp-28 X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 11 Aug 2017 21:48:08 -0000 --94eb2c14fc208ab0f60556814241 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Thank you! _____________ Roman Shpount On Fri, Aug 11, 2017 at 2:07 PM, Paul Kyzivat wrote= : > I am the assigned Gen-ART reviewer for this draft. The General Area Revie= w > Team (Gen-ART) reviews all IETF documents being processed by the IESG for > the IETF Chair. Please wait for direction from your document shepherd or = AD > before posting a new version of the draft. For more information, please s= ee > the FAQ at <=E2=80=8Bhttp://wiki.tools.ietf.org/area/gen/trac/wiki/GenArt= faq>. > > Document: draft-ietf-mmusic-dtls-sdp-28 > Reviewer: Paul Kyzivat > Review Date: 2017-07-07 > IETF LC End Date: 2017-07-24 > IESG Telechat date: 2017-08-17 > > Summary: > > This draft is ready for publication as a Standards Track RFC. > > _______________________________________________ > mmusic mailing list > mmusic@ietf.org > https://www.ietf.org/mailman/listinfo/mmusic > --94eb2c14fc208ab0f60556814241 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Thank you!

_= ____________
Roman Shpount

On Fri, Aug 11, 2017 at 2:07 PM, Paul Kyziva= t <pkyzivat@alum.mit.edu> wrote:
I am the assigned Gen-ART reviewer for this draft. The General A= rea Review Team (Gen-ART) reviews all IETF documents being processed by the= IESG for the IETF Chair. Please wait for direction from your document shep= herd or AD before posting a new version of the draft. For more information,= please see the FAQ at <=E2=80=8Bhttp://wi= ki.tools.ietf.org/area/gen/trac/wiki/GenArtfaq>.

Document: draft-ietf-mmusic-dtls-sdp-28
Reviewer: Paul Kyzivat
Review Date: 2017-07-07
IETF LC End Date: 2017-07-24
IESG Telechat date: 2017-08-17

Summary:

This draft is ready for publication as a Standards Track RFC.

_______________________________________________
mmusic mailing list
mmusic@ietf.org https://www.ietf.org/mailman/listinfo/mmusic

--94eb2c14fc208ab0f60556814241-- From nobody Mon Aug 14 03:09:56 2017 Return-Path: X-Original-To: mmusic@ietf.org Delivered-To: mmusic@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 01AA41320E3; Mon, 14 Aug 2017 03:09:54 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: Alexey Melnikov To: "The IESG" Cc: draft-ietf-mmusic-dtls-sdp@ietf.org, mmusic-chairs@ietf.org, fandreas@cisco.com, mmusic@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.58.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <150270539396.388.11652057713765142260.idtracker@ietfa.amsl.com> Date: Mon, 14 Aug 2017 03:09:53 -0700 Archived-At: Subject: [MMUSIC] Alexey Melnikov's Discuss on draft-ietf-mmusic-dtls-sdp-28: (with DISCUSS and COMMENT) X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.22 List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 14 Aug 2017 10:09:54 -0000 Alexey Melnikov has entered the following ballot position for draft-ietf-mmusic-dtls-sdp-28: Discuss When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-mmusic-dtls-sdp/ ---------------------------------------------------------------------- DISCUSS: ---------------------------------------------------------------------- This is a fine document, but I have one [hopefully easy to answer] question and a couple of other minor ones: In Section 5.1. General Endpoints MUST support the cipher suites as defined in [RFC8122]. I don't see any ciphers specified in that RFC. Can you clarify what you mean? ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- 8. TLS Considerations NOTE: Even though the SDP 'connection' attribute can be used to indicate whether a new TLS connection is to be established, the unique combination of SDP 'tls-id' attribute values can be used to identity a TLS connection. The unique value can be used e.g., within TLS protocol extensions to differentiate between multiple TLS connections and correlate those connections with specific offer/ answer exchanges. Are any such extensions defined or in the process of being standardized? If an offerer or answerer receives an offer/answer with conflicting attribute values, the offerer/answerer MUST process the offer/answer as misformed. I think a pointer to document and section where such handling is specified would be useful here. From nobody Mon Aug 14 10:15:43 2017 Return-Path: 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 839281323AA; Mon, 14 Aug 2017 10:15:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.221 X-Spam-Level: X-Spam-Status: No, score=-4.221 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=ham autolearn_force=no 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 TNJHZMPLkbf7; Mon, 14 Aug 2017 10:15:38 -0700 (PDT) Received: from sessmg22.ericsson.net (sessmg22.ericsson.net [193.180.251.58]) (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 1D1F813226B; Mon, 14 Aug 2017 10:15:37 -0700 (PDT) X-AuditID: c1b4fb3a-617ff700000051a3-b0-5991dab723d5 Received: from ESESSHC015.ericsson.se (Unknown_Domain [153.88.183.63]) by sessmg22.ericsson.net (Symantec Mail Security) with SMTP id 9D.20.20899.7BAD1995; Mon, 14 Aug 2017 19:15:36 +0200 (CEST) Received: from ESESSMB109.ericsson.se ([169.254.9.91]) by ESESSHC015.ericsson.se ([153.88.183.63]) with mapi id 14.03.0352.000; Mon, 14 Aug 2017 19:15:35 +0200 From: Christer Holmberg To: Alexey Melnikov , The IESG CC: "draft-ietf-mmusic-dtls-sdp@ietf.org" , "mmusic-chairs@ietf.org" , "fandreas@cisco.com" , "mmusic@ietf.org" Thread-Topic: Alexey Melnikov's Discuss on draft-ietf-mmusic-dtls-sdp-28: (with DISCUSS and COMMENT) Thread-Index: AQHTFOV68X30Tj0Q70ioXxnaK3+eB6KEE5Dg Date: Mon, 14 Aug 2017 17:15:34 +0000 Message-ID: <7594FB04B1934943A5C02806D1A2204B4CCBD405@ESESSMB109.ericsson.se> References: <150270539396.388.11652057713765142260.idtracker@ietfa.amsl.com> In-Reply-To: <150270539396.388.11652057713765142260.idtracker@ietfa.amsl.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [153.88.183.148] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFprAIsWRmVeSWpSXmKPExsUyM2K7ve6OWxMjDfrWsVrsf3+IyeL/xPms Fu8v6FrM+DOR2eL8zvVMFlOXP2ZxYPOY8nsjq8fOUwfYPJYs+ckUwBzFZZOSmpNZllqkb5fA lbHs/j+mgi+iFTfWTWFtYFwj2sXIySEhYCIx88IR9i5GLg4hgSOMEqf3trBCOIsZJbat6mbq YuTgYBOwkOj+pw1iigi4STy87ghSwixwg1Hix+SZbCCDhAVSJZ6f/soOYosIpEmsaN/KBmEb SSy+sYsRxGYRUJV4/rYLrIZXwFdi8s0/bCAzhQR8JJY+BTM5gcL35oiAVDAKiEl8P7WGCcRm FhCXuPVkPhPEyQISS/acZ4awRSVePv7HCmErSTQuecIKMoZZQFNi/S59iFZFiSndD6GWCkqc nPmEZQKj6CwkU2chdMxC0jELSccCRpZVjKLFqcXFuelGRnqpRZnJxcX5eXp5qSWbGIHxdHDL b6sdjAefOx5iFOBgVOLhTTk2MVKINbGsuDL3EKMEB7OSCG9SO1CINyWxsiq1KD++qDQntfgQ ozQHi5I4r8O+CxFCAumJJanZqakFqUUwWSYOTqkGRoecBNvlCVvL3UUNvgRmLtjyZJv7qfKi qOrax9P6YlXnPzBVVLTqlLobYLNn4kbRyfvk9nqucPhseObJkXVL7V9G9iY+dXZt+RMgX7lV 96XTtj/d109/mr//2H/fuZpHeIVnMLw4fr11ssSF6ZHx2xkmMazZku+xe27gh5lMotMKHFXk p612LFBiKc5INNRiLipOBADBAoOGowIAAA== Archived-At: Subject: Re: [MMUSIC] Alexey Melnikov's Discuss on draft-ietf-mmusic-dtls-sdp-28: (with DISCUSS and COMMENT) X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 14 Aug 2017 17:15:41 -0000 SGkgQWxleGV5LA0KDQpUaGFuayBZb3UgZm9yIHRoZSByZXZpZXchIFBsZWFzZSBzZWUgaW5saW5l Lg0KDQotLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tDQpESVNDVVNTOg0KLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLQ0KDQo+VGhpcyBpcyBh IGZpbmUgZG9jdW1lbnQsIGJ1dCBJIGhhdmUgb25lIFtob3BlZnVsbHkgZWFzeSB0byBhbnN3ZXJd IHF1ZXN0aW9uIGFuZCBhIGNvdXBsZSBvZiBvdGhlciBtaW5vciBvbmVzOg0KPg0KPkluIFNlY3Rp b24gNS4xLiAgR2VuZXJhbA0KPg0KPiAgIEVuZHBvaW50cyBNVVNUIHN1cHBvcnQgdGhlIGNpcGhl ciBzdWl0ZXMgYXMgZGVmaW5lZCBpbiBbUkZDODEyMl0uDQo+DQo+SSBkb24ndCBzZWUgYW55IGNp cGhlcnMgc3BlY2lmaWVkIGluIHRoYXQgUkZDLiBDYW4geW91IGNsYXJpZnkgd2hhdCB5b3UgbWVh bj8NCg0KSXQgcmVmZXJzIHRvIHRoZSB0ZXh0IGFib3V0IGhhc2ggZnVuY3Rpb25zIGluIHNlY3Rp b24gNSBvZiA4MTIyLg0KDQpQZXJoYXBzIEkgc2hvdWxkIHNheSAiaGFzaCBmdW5jdGlvbnMiIGlu c3RlYWQ/DQoNCi0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0NCkNPTU1FTlQ6DQotLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tDQoNCj44LiAg VExTIENvbnNpZGVyYXRpb25zDQo+DQo+ICAgTk9URTogRXZlbiB0aG91Z2ggdGhlIFNEUCAnY29u bmVjdGlvbicgYXR0cmlidXRlIGNhbiBiZSB1c2VkIHRvDQo+ICAgaW5kaWNhdGUgd2hldGhlciBh IG5ldyBUTFMgY29ubmVjdGlvbiBpcyB0byBiZSBlc3RhYmxpc2hlZCwgdGhlDQo+ICAgdW5pcXVl IGNvbWJpbmF0aW9uIG9mIFNEUCAndGxzLWlkJyBhdHRyaWJ1dGUgdmFsdWVzIGNhbiBiZSB1c2Vk IHRvDQo+ICAgaWRlbnRpdHkgYSBUTFMgY29ubmVjdGlvbi4gIFRoZSB1bmlxdWUgdmFsdWUgY2Fu IGJlIHVzZWQgZS5nLiwgd2l0aGluDQo+ICAgVExTIHByb3RvY29sIGV4dGVuc2lvbnMgdG8gZGlm ZmVyZW50aWF0ZSBiZXR3ZWVuIG11bHRpcGxlIFRMUw0KPiAgIGNvbm5lY3Rpb25zIGFuZCBjb3Jy ZWxhdGUgdGhvc2UgY29ubmVjdGlvbnMgd2l0aCBzcGVjaWZpYyBvZmZlci8NCj4gICBhbnN3ZXIg ZXhjaGFuZ2VzLg0KPg0KPiBBcmUgYW55IHN1Y2ggZXh0ZW5zaW9ucyBkZWZpbmVkIG9yIGluIHRo ZSBwcm9jZXNzIG9mIGJlaW5nIHN0YW5kYXJkaXplZD8NCg0KTWFydGluIFQgaGFzIHdyaXR0ZW4g dGhlIGZvbGxvd2luZyBkcmFmdCwgd2hpY2ggd2FzIHJlY2VudGx5IFdHIGFkb3B0ZWQ6DQoNCmh0 dHBzOi8vdG9vbHMuaWV0Zi5vcmcvaWQvZHJhZnQtaWV0Zi1tbXVzaWMtc2RwLXVrcy0wMC50eHQN Cg0KSG93ZXZlciwgd2UgZGlkIG5vdCB3YW50IHRvIGNyZWF0ZSBhIE1JU1JFRiBieSByZWZlcmVu Y2luZyBpdCBpbiBkcmFmdC1kdGxzLXNkcC4NCg0KPiAgIElmIGFuIG9mZmVyZXIgb3IgYW5zd2Vy ZXIgcmVjZWl2ZXMgYW4gb2ZmZXIvYW5zd2VyIHdpdGggY29uZmxpY3RpbmcNCj4gICBhdHRyaWJ1 dGUgdmFsdWVzLCB0aGUgb2ZmZXJlci9hbnN3ZXJlciBNVVNUIHByb2Nlc3MgdGhlIG9mZmVyL2Fu c3dlcg0KPiAgIGFzIG1pc2Zvcm1lZC4NCj4NCj4gSSB0aGluayBhIHBvaW50ZXIgdG8gZG9jdW1l bnQgYW5kIHNlY3Rpb24gd2hlcmUgc3VjaCBoYW5kbGluZyBpcyBzcGVjaWZpZWQgd291bGQgYmUg dXNlZnVsIGhlcmUuDQoNClRoZXJlIGlzIG5vIHNpbmdsZSBzb2x1dGlvbiBkZWZpbmVkIChpdCBv ZnRlbiBkZXBlbmRzIG9uIHRoZSBhdHRyaWJ1dGUpLCBhbmQgd2Ugbm9ybWFsbHkgdHJ5IHRvIHNw ZWNpZnkgc3VjaCBwcm9jZWR1cmVzLCBhcyB0aGV5IG1heSB2YXJ5IGRlcGVuZGluZyBvbiBpbXBs ZW1lbnRhdGlvbiwgdXNlLWNhc2UgZXRjLg0KDQpSZWdhcmRzLA0KDQpDaHJpc3Rlcg0KDQo= From nobody Mon Aug 14 11:30:40 2017 Return-Path: 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 321861323B5; Mon, 14 Aug 2017 11:30:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.72 X-Spam-Level: X-Spam-Status: No, score=-2.72 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=fastmail.fm header.b=ALyLEIq7; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=S8HtRSNb 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 3NRCqH_7uT9w; Mon, 14 Aug 2017 11:30:34 -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 62E8A132399; Mon, 14 Aug 2017 11:30:34 -0700 (PDT) Received: from compute7.internal (compute7.nyi.internal [10.202.2.47]) by mailout.nyi.internal (Postfix) with ESMTP id D2B2D20B86; Mon, 14 Aug 2017 14:30:33 -0400 (EDT) Received: from web5 ([10.202.2.215]) by compute7.internal (MEProxy); Mon, 14 Aug 2017 14:30:33 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=fastmail.fm; h= cc:content-transfer-encoding:content-type:date:from:in-reply-to :message-id:mime-version:references:subject:to:x-me-sender :x-me-sender:x-sasl-enc; s=fm1; bh=XIEFlV8G2SuqKJDOejquaOzUPf7qQ 4wOciF/Z/LODFA=; b=ALyLEIq7hJ6UCMXQM4pqk3TxCxbl/U0GqmvWCusBZy2mc e3+uIpy/kGR32gZrFbe88ZpGtfJiG2k13jXIuJbXqP5XHTFlZY+UH9HYKgisgWdp JdI1Acm0zYityFxFWxCHc6g68grLgSmKfXNqUAbyAeD6eSNlimGAG3puBUvkEsB3 x/lTIODsGzc0ynCqe0qrED9N8yLlaF6Vsu7HuzYfmHJTaW61JI4dbVNAxBFb0CL9 zLEZSF/k1G8H8W9ON5WTNTW8cvQ+jZL7piEvJ6DmbqoTs08PAHZWgn+CpHXE/aPg u4svbKWA52c6g17aaPISx/GCAObivZgSEC9qkyFDg== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:content-transfer-encoding:content-type :date:from:in-reply-to:message-id:mime-version:references :subject:to:x-me-sender:x-me-sender:x-sasl-enc; s=fm1; bh=XIEFlV 8G2SuqKJDOejquaOzUPf7qQ4wOciF/Z/LODFA=; b=S8HtRSNb18z/OaRs3+9IaV eXQr9/1eA9hQ2EeP0jU3LVAChzeWVMyaMT2fV7ITg7eyJNL4dz25mA84LuLoc97B /+ruFAdDUdtQtDKTrBqdlnrj/QvFmMnW7XRd9kFnLB2oLYXRE77UzqABJJM7Bqzi snxnzwZPGLlcbw0FMH6aqrc3IrKOA0k1mldhD52+UZtD8JlYsvfiEMnORy3ruPWe OQS98lx9T0qyIz2RFlMJPPWrN3x8Sl37cMoR+T6h3N6B87kE1bhD6KBOF/lfJ5Xj 05AI5YF2L9doc8X1DDlRMqmqsR9fQ0inZNnIUWAfLB4lZMba+A/Qnj//8w/jQ+ZQ == X-ME-Sender: Received: by mailuser.nyi.internal (Postfix, from userid 99) id AFCAE9E264; Mon, 14 Aug 2017 14:30:33 -0400 (EDT) Message-Id: <1502735433.156078.1073168264.1934670C@webmail.messagingengine.com> From: Alexey Melnikov To: Christer Holmberg , The IESG Cc: draft-ietf-mmusic-dtls-sdp@ietf.org, mmusic-chairs@ietf.org, fandreas@cisco.com, mmusic@ietf.org MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="utf-8" X-Mailer: MessagingEngine.com Webmail Interface - ajax-ff6d44b3 References: <150270539396.388.11652057713765142260.idtracker@ietfa.amsl.com> <7594FB04B1934943A5C02806D1A2204B4CCBD405@ESESSMB109.ericsson.se> In-Reply-To: <7594FB04B1934943A5C02806D1A2204B4CCBD405@ESESSMB109.ericsson.se> Date: Mon, 14 Aug 2017 19:30:33 +0100 Archived-At: Subject: Re: [MMUSIC] Alexey Melnikov's Discuss on draft-ietf-mmusic-dtls-sdp-28: (with DISCUSS and COMMENT) X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 14 Aug 2017 18:30:36 -0000 Hi Christer, On Mon, Aug 14, 2017, at 06:15 PM, Christer Holmberg wrote: > Hi Alexey, > > Thank You for the review! Please see inline. > > ---------------------------------------------------------------------- > DISCUSS: > ---------------------------------------------------------------------- > > >This is a fine document, but I have one [hopefully easy to answer] question and a couple of other minor ones: > > > >In Section 5.1. General > > > > Endpoints MUST support the cipher suites as defined in [RFC8122]. > > > >I don't see any ciphers specified in that RFC. Can you clarify what you mean? > > It refers to the text about hash functions in section 5 of 8122. > > Perhaps I should say "hash functions" instead? Yes, these are different things :-). > ---------------------------------------------------------------------- > COMMENT: > ---------------------------------------------------------------------- > > >8. TLS Considerations > > > > NOTE: Even though the SDP 'connection' attribute can be used to > > indicate whether a new TLS connection is to be established, the > > unique combination of SDP 'tls-id' attribute values can be used to > > identity a TLS connection. The unique value can be used e.g., within > > TLS protocol extensions to differentiate between multiple TLS > > connections and correlate those connections with specific offer/ > > answer exchanges. > > > > Are any such extensions defined or in the process of being standardized? > > Martin T has written the following draft, which was recently WG adopted: > > https://tools.ietf.org/id/draft-ietf-mmusic-sdp-uks-00.txt I suggest you add an Informative reference to this draft. Such reference will not delay publication, but might still be useful to readers. > However, we did not want to create a MISREF by referencing it in > draft-dtls-sdp. > > > If an offerer or answerer receives an offer/answer with conflicting > > attribute values, the offerer/answerer MUST process the offer/answer > > as misformed. > > > > I think a pointer to document and section where such handling is specified would be useful here. > > There is no single solution defined (it often depends on the attribute), > and we normally try to specify such procedures, as they may vary > depending on implementation, use-case etc. Ok. I was hoping there was a single prescribed behaviour in this case. Best Regards, Alexey From nobody Tue Aug 15 05:29:09 2017 Return-Path: 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 1EF681241FC for ; Tue, 15 Aug 2017 05:29:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); domainkeys=pass (1024-bit key) header.from=ietf@kuehlewind.net header.d=kuehlewind.net 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 LvWPoVTGYkW1 for ; Tue, 15 Aug 2017 05:29:05 -0700 (PDT) Received: from kuehlewind.net (kuehlewind.net [83.169.45.111]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DDC56120721 for ; Tue, 15 Aug 2017 05:29:02 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=default; d=kuehlewind.net; b=iK/u7F70fwigGb7PbGSmOZxxTb+MELZSepitW1YyckF2CrO+sFfG378F5hLU3JBqPiAskSklqGbepEVl6VoJZXl8PPjW1dprX3+PixxiiuHUg4BudZMadT8winYzzwx4CmuIgJB+BeO+HT4C3AKWiHqvuhB5ISTT+XTvWPHiNiU=; h=Received:Received:Content-Type:Mime-Version:Subject:From:In-Reply-To:Date:Cc:Content-Transfer-Encoding:Message-Id:References:To:X-Mailer:X-PPP-Message-ID:X-PPP-Vhost; Received: (qmail 28386 invoked from network); 15 Aug 2017 14:29:00 +0200 Received: from p5dec2e26.dip0.t-ipconnect.de (HELO ?192.168.178.33?) (93.236.46.38) by kuehlewind.net with ESMTPSA (DHE-RSA-AES256-SHA encrypted, authenticated); 15 Aug 2017 14:29:00 +0200 Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) From: "Mirja Kuehlewind (IETF)" In-Reply-To: <63e0453a-7f75-7e8c-e3b5-73fafadc0308@alum.mit.edu> Date: Tue, 15 Aug 2017 14:28:58 +0200 Cc: IETF MMUSIC WG Content-Transfer-Encoding: quoted-printable Message-Id: <5A87CC8D-77F7-4517-AB79-3A717866A623@kuehlewind.net> References: <63e0453a-7f75-7e8c-e3b5-73fafadc0308@alum.mit.edu> To: Paul Kyzivat X-Mailer: Apple Mail (2.3273) X-PPP-Message-ID: <20170815122900.28381.78105@lvps83-169-45-111.dedicated.hosteurope.de> X-PPP-Vhost: kuehlewind.net Archived-At: Subject: Re: [MMUSIC] [Gen-art] Telechat review of draft-ietf-mmusic-dtls-sdp-28 X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 15 Aug 2017 12:29:08 -0000 Thanks for all the reviews on this draft! > Am 11.08.2017 um 20:07 schrieb Paul Kyzivat : >=20 > I am the assigned Gen-ART reviewer for this draft. The General Area = Review Team (Gen-ART) reviews all IETF documents being processed by the = IESG for the IETF Chair. Please wait for direction from your document = shepherd or AD before posting a new version of the draft. For more = information, please see the FAQ at = <=E2=80=8Bhttp://wiki.tools.ietf.org/area/gen/trac/wiki/GenArtfaq>. >=20 > Document: draft-ietf-mmusic-dtls-sdp-28 > Reviewer: Paul Kyzivat > Review Date: 2017-07-07 > IETF LC End Date: 2017-07-24 > IESG Telechat date: 2017-08-17 >=20 > Summary: >=20 > This draft is ready for publication as a Standards Track RFC. >=20 > _______________________________________________ > Gen-art mailing list > Gen-art@ietf.org > https://www.ietf.org/mailman/listinfo/gen-art From nobody Tue Aug 15 07:47:25 2017 Return-Path: X-Original-To: mmusic@ietf.org Delivered-To: mmusic@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id C4E641321EB; Tue, 15 Aug 2017 07:47:23 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: =?utf-8?q?Mirja_K=C3=BChlewind?= To: "The IESG" Cc: draft-ietf-mmusic-dtls-sdp@ietf.org, mmusic-chairs@ietf.org, fandreas@cisco.com, mmusic@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.58.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <150280844371.21102.10635571599929348708.idtracker@ietfa.amsl.com> Date: Tue, 15 Aug 2017 07:47:23 -0700 Archived-At: Subject: [MMUSIC] =?utf-8?q?Mirja_K=C3=BChlewind=27s_Discuss_on_draft-ietf?= =?utf-8?q?-mmusic-dtls-sdp-28=3A_=28with_DISCUSS_and_COMMENT=29?= X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.22 List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 15 Aug 2017 14:47:24 -0000 Mirja Kühlewind has entered the following ballot position for draft-ietf-mmusic-dtls-sdp-28: Discuss When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-mmusic-dtls-sdp/ ---------------------------------------------------------------------- DISCUSS: ---------------------------------------------------------------------- This is nothing big and should be easy to fix: On section 7.1, of course... "If DTLS is transported on top of a connection-oriented transport protocol (e.g., TCP or SCTP), where all IP packets are acknowledged, all DTLS packets associated with a previous DTLS association MUST be acknowledged (or timed out) before a new DTLS association can be established on the same instance of that transport (5-tuple)." I don't think this would be necessary for QUIC. The point here is, I believe, not the fact that TCP and SCTP are connection-oriented, but that re-transmissions cannot be easily distinguished from the original packet. So the point is rather the use of a reliable protocol that retransmits in a specific way. However, why would you use DTLS with TCP instead of TLS? And I also don't think you want to use DTLS with QUIC because it has it's own crypto. I guess the recommendation should rather be that reliable transports should use TLS, and if DTLS is needed a new DTLS connection can only be established if there is not retransmission ambiguity which is always the case when all outstanding packets are ack'ed or considered lost (timed out). Or am I missing the point? ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- A couple mostly editorial comments: - Probably a nit: In section 3.2 'must' is used while in section 3.3 'MUST' is used. I would assume that both sections should probably use the same. - in sec 5.1: "Because of this, if an unordered transport is used for the DTLS association, a new transport (3-tuple) must be allocated by at least one of the endpoints so that DTLS packets can be de-multiplexed." Why is this a 3-tuple (instead of a 5-tuple)? I guess you talk about the source address, source port, transport 3-tuple? May say this more explicitly. Also the word of the use transport is confusing to me here because it's used for the transport protocol as well as for the transport 'connection' (if a connection-oriented transport protocol is used). Maybe s/new transport/new flow/? Moreover, there should probably be a 'MUST' here instead of 'must'! - sec 5.2:"In addition, the offerer MUST insert in the offer an SDP 'tls-id' attribute with a unique attribute value." Is that a MUST or rather a SHOULD? The rest of the text reads like this should be a SHOULD. - Shouldn't this document cite RFC6347 normatively, e.g. here (sec 5.3): "... the answerer MUST initiate a DTLS handshake by sending a DTLS ClientHello message towards the offerer." - I would like to see more discussion about linkability based on the introduction of the "tls-id" in the security considerations section. From nobody Tue Aug 15 09:04:53 2017 Return-Path: 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 445BA13234C for ; Tue, 15 Aug 2017 09:04:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=rtfm-com.20150623.gappssmtp.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 DG_83elTM0dQ for ; Tue, 15 Aug 2017 09:04:49 -0700 (PDT) Received: from mail-yw0-x236.google.com (mail-yw0-x236.google.com [IPv6:2607:f8b0:4002:c05::236]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AEA7A1321F1 for ; Tue, 15 Aug 2017 09:04:49 -0700 (PDT) Received: by mail-yw0-x236.google.com with SMTP id l82so7295292ywc.2 for ; Tue, 15 Aug 2017 09:04:49 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=rtfm-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=+kROL3GDN6bRs3irbE41Tk7lr9Q6ZwNcKBF53S9ZUoc=; b=A3ksTdhBAvhMVO14e/hdtxossLSRE9nIjHR+/LWlLP2VNcJBHY5XMdUuwl56ca/aLW 8oKIAoym/4VI5KrkWL64atz1HSM2K6MU3Z5xPwb2TmLyVnhefsgR0fPbGw96Ax0UJ8vR 0utqQFascu8aQVcV4hok/I1qfr+jhxWuc5MgeJqIVZlcqQrNEWj3AYplZjOelCRsXh20 kYfqokgbSB3Y7W5IOMzsfyfS8TaiEzyWWX8Sm52UfN70GS+0idkdkjr9p9Ksw+Zy4ChQ NjWK9cjXafRpfEJeLcGJ4S40D9CSYxlHbgI6TsP8GIVE+5FLjUwyMuRn/Suciz7lrwjB v5Yw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=+kROL3GDN6bRs3irbE41Tk7lr9Q6ZwNcKBF53S9ZUoc=; b=nPtTHtOKVAoY+jOwEaBMxCTcoZTa8aXwf8q/0CRVR4rq278twoWpthI9wthtbz8Lf2 qZ0moeMEb3OR4rD7rGHEVsOvoCKylMwGm9xXpywzh1SVwozVPwBOE/ynfmI/WSVBmFcV UauqLPX8gmQ1cWb+Bu6xM2VYBX3UXIcP8WcBE13Ixb2b9ocIG4qrOHukGGmWc3RmFY3i WoEVpzYyUpleW4qT7BShYmpeCZIzUdQI2yTjfSghWPYJE3AoVmYj1wWpYZmLq/9DhdL3 8iMXRQ1dHyayZNPTmyrtmRg9o+0soCCqtvM9JrtPSKDBKHQ4oYkk0mJ+NLmeXIUo/TbG FKLA== X-Gm-Message-State: AHYfb5gFvIusS7luuEe+znwRYyuViPdMqZTyDU2NXWMtMfek9b8Dsna2 SpOMLEl2gl6xmxJZC+E2St2DmBljtIvt X-Received: by 10.129.172.21 with SMTP id k21mr24975885ywh.321.1502813088932; Tue, 15 Aug 2017 09:04:48 -0700 (PDT) MIME-Version: 1.0 Received: by 10.13.218.130 with HTTP; Tue, 15 Aug 2017 09:04:08 -0700 (PDT) In-Reply-To: <150280844371.21102.10635571599929348708.idtracker@ietfa.amsl.com> References: <150280844371.21102.10635571599929348708.idtracker@ietfa.amsl.com> From: Eric Rescorla Date: Tue, 15 Aug 2017 09:04:08 -0700 Message-ID: To: =?UTF-8?Q?Mirja_K=C3=BChlewind?= Cc: The IESG , draft-ietf-mmusic-dtls-sdp@ietf.org, mmusic-chairs@ietf.org, Flemming Andreasen , mmusic WG Content-Type: multipart/alternative; boundary="f4030436885e5489830556ccf00d" Archived-At: Subject: Re: [MMUSIC] =?utf-8?q?Mirja_K=C3=BChlewind=27s_Discuss_on_draft-iet?= =?utf-8?q?f-mmusic-dtls-sdp-28=3A_=28with_DISCUSS_and_COMMENT=29?= X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 15 Aug 2017 16:04:52 -0000 --f4030436885e5489830556ccf00d Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Tue, Aug 15, 2017 at 7:47 AM, Mirja K=C3=BChlewind wrote: > Mirja K=C3=BChlewind has entered the following ballot position for > draft-ietf-mmusic-dtls-sdp-28: Discuss > > When responding, please keep the subject line intact and reply to all > email addresses included in the To and CC lines. (Feel free to cut this > introductory paragraph, however.) > > > Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html > for more information about IESG DISCUSS and COMMENT positions. > > > The document, along with other ballot positions, can be found here: > https://datatracker.ietf.org/doc/draft-ietf-mmusic-dtls-sdp/ > > > > ---------------------------------------------------------------------- > DISCUSS: > ---------------------------------------------------------------------- > > This is nothing big and should be easy to fix: > > On section 7.1, of course... > "If DTLS is transported on top of a connection-oriented transport > protocol (e.g., TCP or SCTP), where all IP packets are acknowledged, > Incidentally, this text is not true, because IP packets are not necessarily acknowledged. It is upper-level PDUs which are acknowledged. > all DTLS packets associated with a previous DTLS association MUST be > acknowledged (or timed out) before a new DTLS association can be > established on the same instance of that transport (5-tuple)." > I don't think this would be necessary for QUIC. The point here is, I > believe, > not the fact that TCP and SCTP are connection-oriented, but that > re-transmissions cannot be easily distinguished from the original packet. > So > the point is rather the use of a reliable protocol that retransmits in a > specific way. However, why would you use DTLS with TCP instead of TLS? ICE can switch-hit between UDP and TCP (sometimes mid-connection) and the consensus was that it was much easier to run the same protocol over the channel below (i.e., DTLS) rather than try to switch between TLS and DTLS. And I > also don't think you want to use DTLS with QUIC because it has it's own > crypto. > Quite possibly, but in that case this whole document just won't apply to QUIC. > I guess the recommendation should rather be that reliable transports > should use > TLS, and if DTLS is needed a new DTLS connection can only be established = if > there is not retransmission ambiguity which is always the case when all > outstanding packets are ack'ed or considered lost (timed out). It's not just retransmission ambiguity but also reordering. That said, I'm not sure this text is going down a useful line, and I'll take a look at that in my review. -Ekr Or am I missing > the point? > > > ---------------------------------------------------------------------- > COMMENT: > ---------------------------------------------------------------------- > > A couple mostly editorial comments: > - Probably a nit: In section 3.2 'must' is used while in section 3.3 > 'MUST' is > used. I would assume that both sections should probably use the same. > > - in sec 5.1: "Because of > this, if an unordered transport is used for the DTLS association, a > new transport (3-tuple) must be allocated by at least one of the > endpoints so that DTLS packets can be de-multiplexed." > Why is this a 3-tuple (instead of a 5-tuple)? I guess you talk about the > source > address, source port, transport 3-tuple? May say this more explicitly. > Also > the word of the use transport is confusing to me here because it's used > for the > transport protocol as well as for the transport 'connection' (if a > connection-oriented transport protocol is used). Maybe s/new transport/ne= w > flow/? Moreover, there should probably be a 'MUST' here instead of 'must'= ! > > - sec 5.2:"In addition, the offerer MUST insert in the > offer an SDP 'tls-id' attribute with a unique attribute value." > Is that a MUST or rather a SHOULD? The rest of the text reads like this > should > be a SHOULD. > > - Shouldn't this document cite RFC6347 normatively, e.g. here (sec 5.3): > "... the answerer MUST initiate a DTLS handshake by sending a > DTLS ClientHello message towards the offerer." > > - I would like to see more discussion about linkability based on the > introduction of the "tls-id" in the security considerations section. > > > --f4030436885e5489830556ccf00d Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


On Tue, Aug 15, 2017 at 7:47 AM, Mirja K=C3=BChlewind <ietf@kuehlewi= nd.net> wrote:
Mirja K=C3= =BChlewind has entered the following ballot position for
draft-ietf-mmusic-dtls-sdp-28: Discuss

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)


Please refer to https://www.ietf.org/iesg/<= wbr>statement/discuss-criteria.html
for more information about IESG DISCUSS and COMMENT positions.


The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/dr= aft-ietf-mmusic-dtls-sdp/



-----------------------------------------------------------------= -----
DISCUSS:
-----------------------------------------------------------------= -----

This is nothing big and should be easy to fix:

On section 7.1, of course...
"If DTLS is transported on top of a connection-oriented transport
=C2=A0 =C2=A0protocol (e.g., TCP or SCTP), where all IP packets are acknowl= edged,

Incidentally, this text is not t= rue, because IP packets are not necessarily
acknowledged. It is u= pper-level PDUs which are acknowledged.

=C2=A0
=C2=A0 =C2=A0all DTLS packets associated with a previous DTLS association M= UST be
=C2=A0 =C2=A0acknowledged (or timed out) before a new DTLS association can = be
=C2=A0 =C2=A0established on the same instance of that transport (5-tuple).&= quot;
I don't think this would be necessary for QUIC. The point here is, I be= lieve,
not the fact that TCP and SCTP are connection-oriented, but that
re-transmissions cannot be easily distinguished from the original packet. S= o
the point is rather the use of a reliable protocol that retransmits in a specific way. However, why would you use DTLS with TCP instead of TLS?

ICE can switch-hit between UDP and TCP (someti= mes mid-connection) and the
consensus was that it was much easier= to run the same protocol over the
channel below (i.e., DTLS) rat= her than try to switch between TLS and DTLS.


<= /div>
And I
also don't think you want to use DTLS with QUIC because it has it's= own crypto.

Quite possibly, but in tha= t case this whole document just won't apply to QUIC.

=C2=A0
I guess the recommendation should rather be that reliable transports should= use
TLS, and if DTLS is needed a new DTLS connection can only be established if=
there is not retransmission ambiguity which is always the case when all
outstanding packets are ack'ed or considered lost (timed out).=C2=A0

It's not just retransmission ambiguity bu= t also reordering. That said, I'm not sure
this text is going= down a useful line, and I'll take a look at that in my review.

-Ekr

= Or am I missing
the point?


-----------------------------------------------------------------= -----
COMMENT:
-----------------------------------------------------------------= -----

A couple mostly editorial comments:
- Probably a nit: In section 3.2 'must' is used while in section 3.= 3 'MUST' is
used. I would assume that both sections should probably use the same.

- in sec 5.1: "Because of
=C2=A0 =C2=A0this, if an unordered transport is used for the DTLS associati= on, a
=C2=A0 =C2=A0new transport (3-tuple) must be allocated by at least one of t= he
=C2=A0 =C2=A0endpoints so that DTLS packets can be de-multiplexed." Why is this a 3-tuple (instead of a 5-tuple)? I guess you talk about the so= urce
address, source port, transport 3-tuple? May say this more explicitly.=C2= =A0 Also
the word of the use transport is confusing to me here because it's used= for the
transport protocol as well as for the transport 'connection' (if a<= br> connection-oriented transport protocol is used). Maybe s/new transport/new<= br> flow/? Moreover, there should probably be a 'MUST' here instead of = 'must'!

- sec 5.2:"In addition, the offerer MUST insert in the
=C2=A0 =C2=A0offer an SDP 'tls-id' attribute with a unique attribut= e value."
Is that a MUST or rather a SHOULD? The rest of the text reads like this sho= uld
be a SHOULD.

- Shouldn't this document cite RFC6347 normatively, e.g. here (sec 5.3)= :
"... the answerer MUST initiate a DTLS handshake by sending a
=C2=A0 =C2=A0DTLS ClientHello message towards the offerer."

- I would like to see more discussion about linkability based on the
introduction of the "tls-id" in the security considerations secti= on.



--f4030436885e5489830556ccf00d-- From nobody Tue Aug 15 09:39:42 2017 Return-Path: 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 8C17412426E for ; Tue, 15 Aug 2017 09:39:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); domainkeys=pass (1024-bit key) header.from=ietf@kuehlewind.net header.d=kuehlewind.net 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 CGV8Gx5rtp3t for ; Tue, 15 Aug 2017 09:39:32 -0700 (PDT) Received: from kuehlewind.net (kuehlewind.net [83.169.45.111]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3122D132043 for ; Tue, 15 Aug 2017 09:39:32 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=default; d=kuehlewind.net; b=asZWCRJXhHUnYfW/LyD/ZW2lcxrlBcnCntGZgI8l85Pr2e7zhfbDVsd9RQQ7AxyUTPz34Tk5QX4KdQ4lU0qUCvEc6C4VLLFtt36T4qu//M0QCSGyKMY27fyi1t0aoB9vHhUwlb4Bwc+YRFDPxH+90oylAx6de3ry8pfpfamcxS4=; h=Received:Received:Content-Type:Mime-Version:Subject:From:In-Reply-To:Date:Cc:Content-Transfer-Encoding:Message-Id:References:To:X-Mailer:X-PPP-Message-ID:X-PPP-Vhost; Received: (qmail 26436 invoked from network); 15 Aug 2017 18:32:48 +0200 Received: from p5dec2e26.dip0.t-ipconnect.de (HELO ?192.168.178.33?) (93.236.46.38) by kuehlewind.net with ESMTPSA (DHE-RSA-AES256-SHA encrypted, authenticated); 15 Aug 2017 18:32:46 +0200 Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) From: "Mirja Kuehlewind (IETF)" In-Reply-To: Date: Tue, 15 Aug 2017 18:32:46 +0200 Cc: The IESG , draft-ietf-mmusic-dtls-sdp@ietf.org, mmusic-chairs@ietf.org, Flemming Andreasen , mmusic WG Content-Transfer-Encoding: quoted-printable Message-Id: <8CB35BF7-2533-4BE0-8608-EFEC3430FE2D@kuehlewind.net> References: <150280844371.21102.10635571599929348708.idtracker@ietfa.amsl.com> To: Eric Rescorla X-Mailer: Apple Mail (2.3273) X-PPP-Message-ID: <20170815163247.26427.6809@lvps83-169-45-111.dedicated.hosteurope.de> X-PPP-Vhost: kuehlewind.net Archived-At: Subject: Re: [MMUSIC] =?utf-8?q?Mirja_K=C3=BChlewind=27s_Discuss_on_draft-iet?= =?utf-8?q?f-mmusic-dtls-sdp-28=3A_=28with_DISCUSS_and_COMMENT=29?= X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 15 Aug 2017 16:39:34 -0000 Hi Ekr, thanks for you quick reply. See below. > Am 15.08.2017 um 18:04 schrieb Eric Rescorla : >=20 >=20 >=20 > On Tue, Aug 15, 2017 at 7:47 AM, Mirja K=C3=BChlewind = wrote: > Mirja K=C3=BChlewind has entered the following ballot position for > draft-ietf-mmusic-dtls-sdp-28: Discuss >=20 > When responding, please keep the subject line intact and reply to all > email addresses included in the To and CC lines. (Feel free to cut = this > introductory paragraph, however.) >=20 >=20 > Please refer to = https://www.ietf.org/iesg/statement/discuss-criteria.html > for more information about IESG DISCUSS and COMMENT positions. >=20 >=20 > The document, along with other ballot positions, can be found here: > https://datatracker.ietf.org/doc/draft-ietf-mmusic-dtls-sdp/ >=20 >=20 >=20 > ---------------------------------------------------------------------- > DISCUSS: > ---------------------------------------------------------------------- >=20 > This is nothing big and should be easy to fix: >=20 > On section 7.1, of course... > "If DTLS is transported on top of a connection-oriented transport > protocol (e.g., TCP or SCTP), where all IP packets are = acknowledged, >=20 > Incidentally, this text is not true, because IP packets are not = necessarily > acknowledged. It is upper-level PDUs which are acknowledged. Right! Good catch! >=20 > =20 > all DTLS packets associated with a previous DTLS association MUST = be > acknowledged (or timed out) before a new DTLS association can be > established on the same instance of that transport (5-tuple)." > I don't think this would be necessary for QUIC. The point here is, I = believe, > not the fact that TCP and SCTP are connection-oriented, but that > re-transmissions cannot be easily distinguished from the original = packet. So > the point is rather the use of a reliable protocol that retransmits in = a > specific way. However, why would you use DTLS with TCP instead of TLS? >=20 > ICE can switch-hit between UDP and TCP (sometimes mid-connection) and = the > consensus was that it was much easier to run the same protocol over = the > channel below (i.e., DTLS) rather than try to switch between TLS and = DTLS. >=20 >=20 > And I > also don't think you want to use DTLS with QUIC because it has it's = own crypto. >=20 > Quite possibly, but in that case this whole document just won't apply = to QUIC. Yes. >=20 > =20 > I guess the recommendation should rather be that reliable transports = should use > TLS, and if DTLS is needed a new DTLS connection can only be = established if > there is not retransmission ambiguity which is always the case when = all > outstanding packets are ack'ed or considered lost (timed out).=20 >=20 > It's not just retransmission ambiguity but also reordering. That said, = I'm not sure > this text is going down a useful line, and I'll take a look at that in = my review. Right! Thanks! >=20 > -Ekr >=20 > Or am I missing > the point? >=20 >=20 > ---------------------------------------------------------------------- > COMMENT: > ---------------------------------------------------------------------- >=20 > A couple mostly editorial comments: > - Probably a nit: In section 3.2 'must' is used while in section 3.3 = 'MUST' is > used. I would assume that both sections should probably use the same. >=20 > - in sec 5.1: "Because of > this, if an unordered transport is used for the DTLS association, a > new transport (3-tuple) must be allocated by at least one of the > endpoints so that DTLS packets can be de-multiplexed." > Why is this a 3-tuple (instead of a 5-tuple)? I guess you talk about = the source > address, source port, transport 3-tuple? May say this more explicitly. = Also > the word of the use transport is confusing to me here because it's = used for the > transport protocol as well as for the transport 'connection' (if a > connection-oriented transport protocol is used). Maybe s/new = transport/new > flow/? Moreover, there should probably be a 'MUST' here instead of = 'must'! >=20 > - sec 5.2:"In addition, the offerer MUST insert in the > offer an SDP 'tls-id' attribute with a unique attribute value." > Is that a MUST or rather a SHOULD? The rest of the text reads like = this should > be a SHOULD. >=20 > - Shouldn't this document cite RFC6347 normatively, e.g. here (sec = 5.3): > "... the answerer MUST initiate a DTLS handshake by sending a > DTLS ClientHello message towards the offerer." >=20 > - I would like to see more discussion about linkability based on the > introduction of the "tls-id" in the security considerations section. >=20 >=20 >=20 From nobody Tue Aug 15 10:59:08 2017 Return-Path: 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 C166D132143 for ; Tue, 15 Aug 2017 10:59:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.388 X-Spam-Level: X-Spam-Status: No, score=-1.388 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_SORBS_SPAM=0.5, T_SPF_PERMERROR=0.01, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=telurix-com.20150623.gappssmtp.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 w79S__sgjqPN for ; Tue, 15 Aug 2017 10:59:04 -0700 (PDT) Received: from mail-pg0-x229.google.com (mail-pg0-x229.google.com [IPv6:2607:f8b0:400e:c05::229]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B25BF120713 for ; Tue, 15 Aug 2017 10:59:04 -0700 (PDT) Received: by mail-pg0-x229.google.com with SMTP id y129so9898354pgy.4 for ; Tue, 15 Aug 2017 10:59:04 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=telurix-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=UXqcMuaIN8B29OCXMQdVzYDxkbDZvbBuaPTNc6y0UC8=; b=lxlMSfnc5YGUL13TpsoA4HrMSNKyZe0slae5/cR5KFVEVpRGFjmy49e+SvrnGfTQJd mMfLC7BtvAv/vdOM8V2I5dd7MXW0kf858r0K4lnLQ/eQAdnmZbLh7RTDkDzEIHaymyIw BqhJf11VJRog2IFJnBRst/LUwZmEd+c2WsfOfUw1ox31CHP7DHYRhr6EpabIg2PlX7OP uNqszANazBYpQG4LkE98jlaG8Blk7MIwcJIlw7KfZEViFekUmaT92qy+svZD2gsZUlSj 7q/8gxWYL/Rk79oV1bbc3URvb7q0+Nbmg9R5S6TxlzrUBpGNL22JqWhRlLFCQqhaUT8x txWg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=UXqcMuaIN8B29OCXMQdVzYDxkbDZvbBuaPTNc6y0UC8=; b=Q7AoSmo9VqOFhcP8AZSP0WAJsD1MLG1WmwkrEjr0mqrIQTIFMcFa+rJXHBCmCEF/lK C2cG7pCh2td9rGjK54JHg+CrFEPLl1S3wmKJLuIxjf8ia68BO2IdLFo9/HxawK/RkxkV 0MjT0UVGGXuk2z2tks8ccen2PLaFUNsxqjZQr78JhFIYDqEMtxadVWKMa+gT9no/Tw6K 0GvnkAUu6cK+olgHtPfQkPkANKUfCiw14rKXgCn7FjbzBuDsr1aSWjjxRv51K3T7vViB kNxBEZkmggPXXpzvQwB2jU43atwPRaSu2qjfaGHVIKa+vmpS5a11tfbZ8SMXNlryoymM wIug== X-Gm-Message-State: AHYfb5j9udpU9mngid4OFy14yXWvhLfw+HDrGtmodxwCP0zS7roABubm +jGlGg59iBlxU+dZ X-Received: by 10.98.65.220 with SMTP id g89mr28697513pfd.122.1502819944277; Tue, 15 Aug 2017 10:59:04 -0700 (PDT) Received: from mail-pg0-f54.google.com (mail-pg0-f54.google.com. [74.125.83.54]) by smtp.gmail.com with ESMTPSA id p62sm17566600pfg.66.2017.08.15.10.59.02 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 15 Aug 2017 10:59:02 -0700 (PDT) Received: by mail-pg0-f54.google.com with SMTP id l64so9889127pge.5; Tue, 15 Aug 2017 10:59:02 -0700 (PDT) X-Received: by 10.98.81.130 with SMTP id f124mr22454997pfb.152.1502819942427; Tue, 15 Aug 2017 10:59:02 -0700 (PDT) MIME-Version: 1.0 Received: by 10.100.133.150 with HTTP; Tue, 15 Aug 2017 10:59:01 -0700 (PDT) In-Reply-To: <150280844371.21102.10635571599929348708.idtracker@ietfa.amsl.com> References: <150280844371.21102.10635571599929348708.idtracker@ietfa.amsl.com> From: Roman Shpount Date: Tue, 15 Aug 2017 13:59:01 -0400 X-Gmail-Original-Message-ID: Message-ID: To: =?UTF-8?Q?Mirja_K=C3=BChlewind?= Cc: The IESG , draft-ietf-mmusic-dtls-sdp@ietf.org, mmusic-chairs@ietf.org, lemming Andreasen , "mmusic@ietf.org" Content-Type: multipart/alternative; boundary="94eb2c1111c4d4721c0556ce8866" Archived-At: Subject: Re: [MMUSIC] =?utf-8?q?Mirja_K=C3=BChlewind=27s_Discuss_on_draft-iet?= =?utf-8?q?f-mmusic-dtls-sdp-28=3A_=28with_DISCUSS_and_COMMENT=29?= X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 15 Aug 2017 17:59:07 -0000 --94eb2c1111c4d4721c0556ce8866 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Tue, Aug 15, 2017 at 10:47 AM, Mirja K=C3=BChlewind wrote: > Mirja K=C3=BChlewind has entered the following ballot position for > draft-ietf-mmusic-dtls-sdp-28: Discuss > > On section 7.1, of course... > "If DTLS is transported on top of a connection-oriented transport > protocol (e.g., TCP or SCTP), where all IP packets are acknowledged, > all DTLS packets associated with a previous DTLS association MUST be > acknowledged (or timed out) before a new DTLS association can be > established on the same instance of that transport (5-tuple)." > I don't think this would be necessary for QUIC. The point here is, I > believe, > not the fact that TCP and SCTP are connection-oriented, but that > re-transmissions cannot be easily distinguished from the original packet. > So > the point is rather the use of a reliable protocol that retransmits in a > specific way. However, why would you use DTLS with TCP instead of TLS? An= d > I > also don't think you want to use DTLS with QUIC because it has it's own > crypto. > I guess the recommendation should rather be that reliable transports > should use > TLS, and if DTLS is needed a new DTLS connection can only be established = if > there is not retransmission ambiguity which is always the case when all > outstanding packets are ack'ed or considered lost (timed out). Or am I > missing > the point? > This whole section was added because of RFC6083 (DTLS over SCTP, not to be confused with SCTP over DTLS). I am not sure if anybody implemented DTLS over SCTP with SDP based negotiation so this language is highly theoretical. The issue is that DTLS over SCTP as it is defined in RFC6083 is not compatible with DTLS over UDP. Essentially RFC6083 removes re-transmission logic from DTLS stack and uses re-transmission logic in SCTP. It also states that a single SCTP association should be reused for multiple DTLS associations and DTLS association cannot span across multiple underlying transports. The intention of this text was to say that for DTLS over SCTP implementation should use different procedures since it is, essentially, different DTLS (without re-transmission logic). We have tried to generalize the language, but I am not sure the result is quite clear. My preference at the time was not cover DTLS over SCTP in this draft at all. Since EKR is reviewing this, and since he is one of RFC6083 authors, he can probably suggest a better language. This text does not apply to DTLS over TCP. DTLS over TCP is primarily used for ICE TCP candidates. In this case transport is still treated as unreliable un-ordered for two reasons: a. ICE can switch between candidates and transports, so when switch from UDP to TCP candidate pair occurs DTLS still needs to handle re-transmission or out of order packets. Even switching between two TCP candidates can result in un-ordered packet delivery. b. DTLS over TCP is often single hop, where TCP connection is terminated by SBC and UDP being used on the other leg. DTLS association in this cases continues to be end-to-end and will have to deal with re-transmission and out of order packets. I do not think we even though about QUIC here but most likely QUIC will not be used used with DTLS. > - in sec 5.1: "Because of > this, if an unordered transport is used for the DTLS association, a > new transport (3-tuple) must be allocated by at least one of the > endpoints so that DTLS packets can be de-multiplexed." > Why is this a 3-tuple (instead of a 5-tuple)? I guess you talk about the > source > address, source port, transport 3-tuple? May say this more explicitly. > Also > the word of the use transport is confusing to me here because it's used > for the > transport protocol as well as for the transport 'connection' (if a > connection-oriented transport protocol is used). Maybe s/new transport/ne= w > flow/? Moreover, there should probably be a 'MUST' here instead of 'must'= ! > Each end point allocates a 3-tuple for connection (transport/address /port). Connections are disambiguated using 5 tuple (transport/source address/source port/destination address/destination port). We can make this more explicit. - sec 5.2:"In addition, the offerer MUST insert in the > offer an SDP 'tls-id' attribute with a unique attribute value." > Is that a MUST or rather a SHOULD? The rest of the text reads like this > should > be a SHOULD. > Implementations compliant with this specification MUST insert tls-id in offers and respond with answer with tls-id if tls-id was present in the offer. This is how end points indicate that they support this specification= . Regards, _____________ Roman Shpount --94eb2c1111c4d4721c0556ce8866 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
On Tue, Aug 15, 2017 at 10:47 AM, Mirja K=C3=BChlewind <ietf@kuehle= wind.net> wrote:
Mirja K=C3=BChlewind has en= tered the following ballot position for
draft-ietf-mmusic-dtls-sdp-28: Discuss

On section 7.1, of course...
"If DTLS is transported on top of a connection-oriented transport
=C2=A0 =C2=A0protocol (e.g., TCP or SCTP), where all IP packets are acknowl= edged,
=C2=A0 =C2=A0all DTLS packets associated with a previous DTLS association M= UST be
=C2=A0 =C2=A0acknowledged (or timed out) before a new DTLS association can = be
=C2=A0 =C2=A0established on the same instance of that transport (5-tuple).&= quot;
I don't think this would be necessary for QUIC. The point here is, I be= lieve,
not the fact that TCP and SCTP are connection-oriented, but that
re-transmissions cannot be easily distinguished from the original packet. S= o
the point is rather the use of a reliable protocol that retransmits in a specific way. However, why would you use DTLS with TCP instead of TLS? And = I
also don't think you want to use DTLS with QUIC because it has it's= own crypto.
I guess the recommendation should rather be that reliable transports should= use
TLS, and if DTLS is needed a new DTLS connection can only be established if=
there is not retransmission ambiguity which is always the case when all
outstanding packets are ack'ed or considered lost (timed out).=C2=A0 Or= am I missing
the point?

This whole section was added= because of RFC6083=C2=A0 (DTLS over SCTP, not to be confused with SCTP ove= r DTLS). I am not sure if anybody implemented DTLS over SCTP with SDP based= negotiation so this language is highly theoretical. The issue is that DTLS= over SCTP as it is defined in RFC6083 is not compatible with DTLS over UDP= . Essentially RFC6083 removes re-transmission logic from DTLS stack and use= s re-transmission logic in SCTP. It also states that a single SCTP associat= ion should be reused for multiple DTLS associations and DTLS association ca= nnot span across multiple underlying transports. The intention of this text= was to say that for DTLS over SCTP implementation should use different pro= cedures since it is, essentially, different DTLS (without re-transmission l= ogic). We have tried to generalize the language, but I am not sure the resu= lt is quite clear. My preference at the time was not cover DTLS over SCTP i= n this draft at all. Since EKR=C2=A0 is reviewing this, and since he is one= of RFC6083 authors, he can probably suggest a better language.=C2=A0
=

This text does not apply to DTLS over TCP. DTLS over TC= P is primarily used for ICE TCP candidates. In this case transport is still= treated as unreliable un-ordered for two reasons:

a. ICE can switch between candidates and transports, so when switch from U= DP to TCP candidate pair occurs DTLS still needs to handle re-transmission = or out of order packets. Even switching between two TCP candidates can resu= lt in un-ordered packet delivery.

b. DTLS over TCP= is often single hop, where TCP connection is terminated by SBC and UDP bei= ng used on the other leg. DTLS association in this cases continues to be en= d-to-end and will have to deal with re-transmission and out of order packet= s.

I do not think we even though about QUIC here b= ut most likely QUIC will not be used used with DTLS.

=C2=A0
- in sec 5= .1: "Because of
=C2=A0 =C2=A0this, if an unordered transport is used for the DTLS associati= on, a
=C2=A0 =C2=A0new transport (3-tuple) must be allocated by at least one of t= he
=C2=A0 =C2=A0endpoints so that DTLS packets can be de-multiplexed." Why is this a 3-tuple (instead of a 5-tuple)? I guess you talk about the so= urce
address, source port, transport 3-tuple? May say this more explicitly.=C2= =A0 Also
the word of the use transport is confusing to me here because it's used= for the
transport protocol as well as for the transport 'connection' (if a<= br> connection-oriented transport protocol is used). Maybe s/new transport/new<= br> flow/? Moreover, there should probably be a 'MUST' here instead of = 'must'!

Each end point allocate= s a 3-tuple for connection (transport/address /port). Connections are disam= biguated using 5 tuple (transport/source address/source port/destination ad= dress/destination port). We can make this more explicit.

- sec 5.2:"In addi= tion, the offerer MUST insert in the
=C2=A0 =C2=A0offer an SDP 'tls-id' attribute with a unique attribut= e value."
Is that a MUST or rather a SHOULD? The rest of the text reads like this sho= uld
be a SHOULD.
=C2=A0
Implementations complian= t with this specification MUST insert tls-id in offers and respond with ans= wer with tls-id if tls-id was present in the offer. This is how end points = indicate that they support this specification.

Reg= ards,
_____________
Roman Shpou= nt
=C2=A0
--94eb2c1111c4d4721c0556ce8866-- From nobody Tue Aug 15 12:17:09 2017 Return-Path: X-Original-To: mmusic@ietf.org Delivered-To: mmusic@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 1BCB8132250; Tue, 15 Aug 2017 12:17:03 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: Warren Kumari To: "The IESG" Cc: draft-ietf-mmusic-dtls-sdp@ietf.org, mmusic-chairs@ietf.org, fandreas@cisco.com, mmusic@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.58.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <150282462301.21008.14070100104601564151.idtracker@ietfa.amsl.com> Date: Tue, 15 Aug 2017 12:17:03 -0700 Archived-At: Subject: [MMUSIC] Warren Kumari's No Objection on draft-ietf-mmusic-dtls-sdp-28: (with COMMENT) X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.22 List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 15 Aug 2017 19:17:03 -0000 Warren Kumari has entered the following ballot position for draft-ietf-mmusic-dtls-sdp-28: No Objection When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-mmusic-dtls-sdp/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- This falls well into the "This is outside my area of expertise" part of: This ballot position may be interpreted as "This is outside my area of expertise or have no cycles", in that you exercise the ability to move a document forward on the basis of trust towards the other ADs. :-) From nobody Tue Aug 15 12:54:19 2017 Return-Path: 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 513CA1200F3; Tue, 15 Aug 2017 12:54:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.22 X-Spam-Level: X-Spam-Status: No, score=-4.22 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no 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 nLGvjLqkRew6; Tue, 15 Aug 2017 12:54:09 -0700 (PDT) Received: from sesbmg22.ericsson.net (sesbmg22.ericsson.net [193.180.251.48]) (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 7BACA1321EB; Tue, 15 Aug 2017 12:54:08 -0700 (PDT) X-AuditID: c1b4fb30-57fff70000005897-c1-5993515e1b9b Received: from ESESSHC007.ericsson.se (Unknown_Domain [153.88.183.39]) by sesbmg22.ericsson.net (Symantec Mail Security) with SMTP id F2.28.22679.E5153995; Tue, 15 Aug 2017 21:54:06 +0200 (CEST) Received: from ESESSMB109.ericsson.se ([169.254.9.91]) by ESESSHC007.ericsson.se ([153.88.183.39]) with mapi id 14.03.0352.000; Tue, 15 Aug 2017 21:54:05 +0200 From: Christer Holmberg To: Warren Kumari , The IESG CC: "draft-ietf-mmusic-dtls-sdp@ietf.org" , "mmusic-chairs@ietf.org" , "fandreas@cisco.com" , "mmusic@ietf.org" Thread-Topic: Warren Kumari's No Objection on draft-ietf-mmusic-dtls-sdp-28: (with COMMENT) Thread-Index: AQHTFfsVRfnOMpgkAUKOijUD6AD7XqKF1JjQ Date: Tue, 15 Aug 2017 19:54:04 +0000 Message-ID: <7594FB04B1934943A5C02806D1A2204B4CCBF6B4@ESESSMB109.ericsson.se> References: <150282462301.21008.14070100104601564151.idtracker@ietfa.amsl.com> In-Reply-To: <150282462301.21008.14070100104601564151.idtracker@ietfa.amsl.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [153.88.183.154] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFprMIsWRmVeSWpSXmKPExsUyM2K7um5c4ORIg433lSz+T5zPavH+gq7F jD8TmS3O71zPZDF1+WMWi8PHLjM5sHlM+b2R1WPJkp9MHrdv/GEPYI7isklJzcksSy3St0vg yth47Q17QRN/xfapL9kbGC/wdTFyckgImEjMPXqYsYuRi0NI4AijxObOw6wQzmJGidObprB3 MXJwsAlYSHT/0wZpEBGwl7i8ZRMbSA2zwA1GiR+TZ7KBJIQFYiT2/FvOBFEUK7FowgtWCNtI 4uTt/SwgNouAqsSZRReZQWxeAV+JhZuOgvUKCfhJtG7dwghicwr4S9x6cxjMZhQQk/h+ag3Y TGYBcYlbT+YzQVwtILFkz3lmCFtU4uXjf6wQtpLEotufmUBuZhbQlFi/Sx+iVVFiSvdDdoi1 ghInZz5hmcAoOgvJ1FkIHbOQdMxC0rGAkWUVo2hxanFSbrqRkV5qUWZycXF+nl5easkmRmBU Hdzy22AH48vnjocYBTgYlXh46xwmRwqxJpYVV+YeYpTgYFYS4T32ZlKkEG9KYmVValF+fFFp TmrxIUZpDhYlcV7HfRcihATSE0tSs1NTC1KLYLJMHJxSDYxLnh97FlN8S3zWDJ+XaxZd1GDp vBgvdd3o+R7J0xfqdAqY/8Yt2u67MlQlXGZx9pdPR05W3dK9cCP33/O1X6dXPTdcW+Kd/eVD oPi27RurDTqCGv4r6Kb4Z5s21QpEa0hmt0899HgPv8g+TlOjZ7+ibv7nzBR98HDamsbfT+v2 7mhytg55p71AiaU4I9FQi7moOBEA4Pbmb6YCAAA= Archived-At: Subject: Re: [MMUSIC] Warren Kumari's No Objection on draft-ietf-mmusic-dtls-sdp-28: (with COMMENT) X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 15 Aug 2017 19:54:11 -0000 SW4gb3RoZXIgQURzIHdlIHRydXN0IDopDQoNClRoYW5rcyENCg0KUmVnYXJkcywNCg0KQ2hyaXN0 ZXINCg0KLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCkZyb206IFdhcnJlbiBLdW1hcmkgW21h aWx0bzp3YXJyZW5Aa3VtYXJpLm5ldF0gDQpTZW50OiAxNSBBdWd1c3QgMjAxNyAyMToxNw0KVG86 IFRoZSBJRVNHIDxpZXNnQGlldGYub3JnPg0KQ2M6IGRyYWZ0LWlldGYtbW11c2ljLWR0bHMtc2Rw QGlldGYub3JnOyBtbXVzaWMtY2hhaXJzQGlldGYub3JnOyBmYW5kcmVhc0BjaXNjby5jb207IG1t dXNpY0BpZXRmLm9yZw0KU3ViamVjdDogV2FycmVuIEt1bWFyaSdzIE5vIE9iamVjdGlvbiBvbiBk cmFmdC1pZXRmLW1tdXNpYy1kdGxzLXNkcC0yODogKHdpdGggQ09NTUVOVCkNCg0KV2FycmVuIEt1 bWFyaSBoYXMgZW50ZXJlZCB0aGUgZm9sbG93aW5nIGJhbGxvdCBwb3NpdGlvbiBmb3INCmRyYWZ0 LWlldGYtbW11c2ljLWR0bHMtc2RwLTI4OiBObyBPYmplY3Rpb24NCg0KV2hlbiByZXNwb25kaW5n LCBwbGVhc2Uga2VlcCB0aGUgc3ViamVjdCBsaW5lIGludGFjdCBhbmQgcmVwbHkgdG8gYWxsIGVt YWlsIGFkZHJlc3NlcyBpbmNsdWRlZCBpbiB0aGUgVG8gYW5kIENDIGxpbmVzLiAoRmVlbCBmcmVl IHRvIGN1dCB0aGlzIGludHJvZHVjdG9yeSBwYXJhZ3JhcGgsIGhvd2V2ZXIuKQ0KDQoNClBsZWFz ZSByZWZlciB0byBodHRwczovL3d3dy5pZXRmLm9yZy9pZXNnL3N0YXRlbWVudC9kaXNjdXNzLWNy aXRlcmlhLmh0bWwNCmZvciBtb3JlIGluZm9ybWF0aW9uIGFib3V0IElFU0cgRElTQ1VTUyBhbmQg Q09NTUVOVCBwb3NpdGlvbnMuDQoNCg0KVGhlIGRvY3VtZW50LCBhbG9uZyB3aXRoIG90aGVyIGJh bGxvdCBwb3NpdGlvbnMsIGNhbiBiZSBmb3VuZCBoZXJlOg0KaHR0cHM6Ly9kYXRhdHJhY2tlci5p ZXRmLm9yZy9kb2MvZHJhZnQtaWV0Zi1tbXVzaWMtZHRscy1zZHAvDQoNCg0KDQotLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tDQpDT01NRU5UOg0KLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLQ0KDQpUaGlzIGZhbGxzIHdlbGwgaW50byB0aGUg IlRoaXMgaXMgb3V0c2lkZSBteSBhcmVhIG9mIGV4cGVydGlzZSIgcGFydCBvZjoNClRoaXMgYmFs bG90IHBvc2l0aW9uIG1heSBiZSBpbnRlcnByZXRlZCBhcyAiVGhpcyBpcyBvdXRzaWRlIG15IGFy ZWEgb2YgZXhwZXJ0aXNlIG9yIGhhdmUgbm8gY3ljbGVzIiwgaW4gdGhhdCB5b3UgZXhlcmNpc2Ug dGhlIGFiaWxpdHkgdG8gbW92ZSBhIGRvY3VtZW50IGZvcndhcmQgb24gdGhlIGJhc2lzIG9mIHRy dXN0IHRvd2FyZHMgdGhlIG90aGVyIEFEcy4gOi0pDQoNCg0K From nobody Tue Aug 15 16:07:02 2017 Return-Path: X-Original-To: mmusic@ietf.org Delivered-To: mmusic@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id E449B132439; Tue, 15 Aug 2017 16:07:01 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: Eric Rescorla To: "The IESG" Cc: draft-ietf-mmusic-dtls-sdp@ietf.org, mmusic-chairs@ietf.org, fandreas@cisco.com, mmusic@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.58.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <150283842189.12471.16276554513202805910.idtracker@ietfa.amsl.com> Date: Tue, 15 Aug 2017 16:07:01 -0700 Archived-At: Subject: [MMUSIC] Eric Rescorla's Discuss on draft-ietf-mmusic-dtls-sdp-28: (with DISCUSS and COMMENT) X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.22 List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 15 Aug 2017 23:07:02 -0000 Eric Rescorla has entered the following ballot position for draft-ietf-mmusic-dtls-sdp-28: Discuss When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-mmusic-dtls-sdp/ ---------------------------------------------------------------------- DISCUSS: ---------------------------------------------------------------------- 1. Assuming I understand this document correctly, it conflicts with the guidance in JSEP. Specifically, S 4 says: No default value is defined for the SDP 'tls-id' attribute. Implementations that wish to use the attribute MUST explicitly include it in SDP offers and answers. If an offer or answer does not contain a 'tls-id' attribute (this could happen if the offerer or answerer represents an existing implementation that has not been updated to support the 'tls-id' attribute), unless there is another mechanism to explicitly indicate that a new DTLS association is to be established, a modification of one or more of the following characteristics MUST be treated as an indication that an endpoint wants to establish a new DTLS association: o DTLS setup role; or o fingerprint set; or o local transport parameters; or o ICE ufrag value This seems to say that if there is no tls-id attribute, then an ICE restart (which necessitates a ufrag change) requires a DTLS restart. JSEP isn't incredibly clear on this point, but 5.7.3 seems to say that tls-id neeed not be present: * tls-id value, which MUST be set according to [I-D.ietf-mmusic-dtls-sdp], Section 5. If this is a re-offer and the tls-id value is different from that presently in use, the DTLS connection is not being continued and the remote description MUST be part of an ICE restart, together with new ufrag and password values. If this is an answer, the tls-id value, if present, MUST be the same as in the offer. I believe that the first sentence is in error, as we clearly can't have JSEP implementations requiring that tls-id be present. ... o If the remote DTLS fingerprint has been changed or the tls-id has changed, tear down the DTLS connection. This includes the case when the PeerConnection state is "have-remote-pranswer". If a DTLS connection needs to be torn down but the answer does not indicate an ICE restart or, in the case of "have-remote-pranswer", new ICE credentials, an error MUST be generated. If an ICE restart is performed without a change in tls-id or fingerprint, then the same DTLS connection is continued over the new ICE channel. I think the best interpretation of this is that if tls-id is not present (and hence unchanged) then ICE restart does not cause DTLS restart. This is also my memory of the consensus in RTCWEB. In any case, these two documents clearly must match. 2. S 4 says: The mux category [I-D.ietf-mmusic-sdp-mux-attributes] for the 'tls- id' attribute is 'IDENTICAL', which means that the attribute value must be identical across all media descriptions being multiplexed [I-D.ietf-mmusic-sdp-bundle-negotiation]. This is not actually what JSEP requires: different categories. To avoid unnecessary duplication when bundling, attributes of category IDENTICAL or TRANSPORT MUST NOT be repeated in bundled m= sections, repeating the guidance from [I-D.ietf-mmusic-sdp-bundle-negotiation], Section 8.1. This includes I suspect this is old text. 3. S 7.1 says: If DTLS is transported on top of a connection-oriented transport protocol (e.g., TCP or SCTP), where all IP packets are acknowledged, This is incorrect, because none of these protocols ack all IP packets. all DTLS packets associated with a previous DTLS association MUST be acknowledged (or timed out) before a new DTLS association can be established on the same instance of that transport (5-tuple). More generally, I'm not sure that this is useful, because the required semantic isn't *acknowledged* but rather that the receiver can appropriately demux. So, say you just stop sending DTLS on connection A and start sending on B, what's the delimiter, given that you don't require close_notify here? IIRC, we just decided to punt on this whole thing. Does anyone try to have successive connections over the same transport, even when it's connection oriented? 4. The demux instructions seem to have gotten lost from 6.7.1. At minimum these need a reference to RFC 7983. ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- S 5.1. media session immediately (see [RFC8122]). Note that it is permissible to wait until the other side's fingerprint(s) has been received before establishing the connection; however, this may have undesirable latency effects. I agree that it's permissible, but why would you do this? This does not seem like helpful guidance. S 10. Please do something about the "NEW" constructions. I literally had to pull these into ediff to know what had changed. That's not useful to people. I'm not a fan of this construction in general, but at minimum you need to explain what has changed. S 9. Regardless of the previous existence of a DTLS association, the SDP 'setup' attribute MUST be included according to the rules defined in [RFC4145] and if ICE is used, ICE restart MUST be initiated. What is the rationale for this rule? From nobody Tue Aug 15 16:59:01 2017 Return-Path: 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 5C75C13267B for ; Tue, 15 Aug 2017 16:58:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.888 X-Spam-Level: X-Spam-Status: No, score=-1.888 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, T_SPF_PERMERROR=0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=telurix-com.20150623.gappssmtp.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 yHllY-ER1TYY for ; Tue, 15 Aug 2017 16:58:56 -0700 (PDT) Received: from mail-pg0-x22d.google.com (mail-pg0-x22d.google.com [IPv6:2607:f8b0:400e:c05::22d]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C8924132677 for ; Tue, 15 Aug 2017 16:58:56 -0700 (PDT) Received: by mail-pg0-x22d.google.com with SMTP id u5so15002939pgn.0 for ; Tue, 15 Aug 2017 16:58:56 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=telurix-com.20150623.gappssmtp.com; s=20150623; h=mime-version:from:date:message-id:subject:to:cc; bh=2rs40pZ9XNPWv26VPcAogtlrmf6NEkhMTo17/QYpPeE=; b=jKKxGVxlIfMcezOQ4CNYgA6JiGovIJQ8IDTaAYhCQcnSQMPihtUXeS+z7JgLwor7hi zen4+PTz/xsT4rhWap/bqCf6wWuBaYALBTQnkuOkYi4yBUHqm+Xiuk5rx3JP9w830hSK pU6KlZLRkr9ZFZ/zcK5H/ARNB32zuIexdDXPuoYE7u3O/Mr9wxR6sPGTE7Vtfh24bGXz xrLP1dbcBKOHiWmHGXK8ZQShuO2ZK7B273G43Kif+79NfuahtTp4MPNjEUK5vIIL+BOA 3y1ohnZJdZd/Bd7apl1PXpZFjwlSRm8dArP/vG9MwXfQczmJYmk/T4vfut5uc2ANLfSm lSGQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:from:date:message-id:subject:to:cc; bh=2rs40pZ9XNPWv26VPcAogtlrmf6NEkhMTo17/QYpPeE=; b=gw8q0fNf5zMmivuyWGUXa/oAUormkuE3k7Ge0K6/tGR5MklzMpqH9Bh78DcEEk5paO RBVu4xHQWZVr3sOMUZxRwL0jLxOP6KPnmiSTwlARrXfnEZBZ/LolOVkCkIDN/N29u/c3 eaYsdEGfhpiKNiZRCnstm7LE9Qp5n1Tu8O3jZUT+mAPvCpRxmsCf2mdNkrC4pLrjAwzH u5wp1oPL8DwpzB1mztMxBKJ5I5lVPS+9FU6sQmWTEnEhJuCAzK97MPb/DFbryfPxz8Xr zjWq5wLWpVtYXQRW6NhzjQXcuDTJk34Gv6LQqpNFse59sORLbxdvMYqUuCSfQ73ex6ub ROAg== X-Gm-Message-State: AHYfb5iAtDRLU0o+Ci7gP1bd4aI2Y7RZZPHSuz8CHRF0L/Xo27nNq1Ro DE5V6mP2fDMJMD7L X-Received: by 10.84.229.77 with SMTP id d13mr32818372pln.164.1502841536371; Tue, 15 Aug 2017 16:58:56 -0700 (PDT) Received: from mail-pg0-f52.google.com (mail-pg0-f52.google.com. [74.125.83.52]) by smtp.gmail.com with ESMTPSA id s14sm18680164pfj.124.2017.08.15.16.58.55 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 15 Aug 2017 16:58:55 -0700 (PDT) Received: by mail-pg0-f52.google.com with SMTP id i12so14930741pgr.3; Tue, 15 Aug 2017 16:58:55 -0700 (PDT) X-Received: by 10.101.69.142 with SMTP id o14mr28762516pgq.242.1502841535016; Tue, 15 Aug 2017 16:58:55 -0700 (PDT) MIME-Version: 1.0 Received: by 10.100.133.150 with HTTP; Tue, 15 Aug 2017 16:58:54 -0700 (PDT) From: Roman Shpount Date: Tue, 15 Aug 2017 19:58:54 -0400 X-Gmail-Original-Message-ID: Message-ID: To: Eric Rescorla Cc: The IESG , draft-ietf-mmusic-dtls-sdp@ietf.org, mmusic-chairs@ietf.org, lemming Andreasen , "mmusic@ietf.org" Content-Type: multipart/alternative; boundary="089e082219b4d937050556d38ffa" Archived-At: Subject: Re: [MMUSIC] Eric Rescorla's Discuss on draft-ietf-mmusic-dtls-sdp-28: (with DISCUSS and COMMENT) X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 15 Aug 2017 23:58:59 -0000 --089e082219b4d937050556d38ffa Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Eric, Thank you for your comments. On Tue, Aug 15, 2017 at 7:07 PM, Eric Rescorla wrote: > 1. Assuming I understand this document correctly, it conflicts with > the guidance in JSEP. Specifically, S 4 says: > > No default value is defined for the SDP 'tls-id' attribute. > Implementations that wish to use the attribute MUST explicitly > include it in SDP offers and answers. If an offer or answer does not > contain a 'tls-id' attribute (this could happen if the offerer or > answerer represents an existing implementation that has not been > updated to support the 'tls-id' attribute), unless there is another > mechanism to explicitly indicate that a new DTLS association is to be > established, a modification of one or more of the following > characteristics MUST be treated as an indication that an endpoint > wants to establish a new DTLS association: > > o DTLS setup role; or > > o fingerprint set; or > > o local transport parameters; or > > o ICE ufrag value > > This seems to say that if there is no tls-id attribute, then an ICE resta= rt > (which necessitates a ufrag change) requires a DTLS restart. JSEP isn't > incredibly clear on this point, but 5.7.3 seems to say that tls-id > neeed not be present: > > * tls-id value, which MUST be set according to > [I-D.ietf-mmusic-dtls-sdp], Section 5. If this is a re-offer > and the tls-id value is different from that presently in use, > the DTLS connection is not being continued and the remote > description MUST be part of an ICE restart, together with new > ufrag and password values. If this is an answer, the tls-id > value, if present, MUST be the same as in the offer. > > I believe that the first sentence is in error, as we clearly > can't have JSEP implementations requiring that tls-id be present. > > ... > > o If the remote DTLS fingerprint has been changed or the tls-id has > changed, tear down the DTLS connection. This includes the case > when the PeerConnection state is "have-remote-pranswer". If a > DTLS connection needs to be torn down but the answer does not > indicate an ICE restart or, in the case of "have-remote-pranswer", > new ICE credentials, an error MUST be generated. If an ICE > restart is performed without a change in tls-id or fingerprint, > then the same DTLS connection is continued over the new ICE > channel. > > I think the best interpretation of this is that if tls-id is not present > (and hence unchanged) then ICE restart does not cause DTLS restart. > This is also my memory of the consensus in RTCWEB. In any case, these > two documents clearly must match. > In regard to ICE ufrag change without tls-id we just have to make a choice. Both choices are bad since they both cause things to break when one side would initiate new DTLS association and another side would not. I would agree that not starting DTLS association on ICE restart is slightly safer. In any case, tls-id is needed to avoid this ambiguity. For anything compliant with the new draft, tls-di must be present. > 2. S 4 says: > > The mux category [I-D.ietf-mmusic-sdp-mux-attributes] for the 'tls- > id' attribute is 'IDENTICAL', which means that the attribute value > must be identical across all media descriptions being multiplexed > [I-D.ietf-mmusic-sdp-bundle-negotiation]. > > This is not actually what JSEP requires: > > different categories. To avoid unnecessary duplication when > bundling, attributes of category IDENTICAL or TRANSPORT MUST NOT be > repeated in bundled m=3D sections, repeating the guidance from > [I-D.ietf-mmusic-sdp-bundle-negotiation], Section 8.1. This includes > > I suspect this is old text. > This is old text and should be corrected 3. S 7.1 says: > If DTLS is transported on top of a connection-oriented transport > protocol (e.g., TCP or SCTP), where all IP packets are acknowledged, > > This is incorrect, because none of these protocols ack all IP packets. > > > all DTLS packets associated with a previous DTLS association MUST be > acknowledged (or timed out) before a new DTLS association can be > established on the same instance of that transport (5-tuple). > > More generally, I'm not sure that this is useful, because the > required semantic isn't *acknowledged* but rather that the receiver > can appropriately demux. So, say you just stop sending DTLS on > connection A and start sending on B, what's the delimiter, given > that you don't require close_notify here? IIRC, we just decided to > punt on this whole thing. Does anyone try to have successive > connections over the same transport, even when it's connection oriented? > Please see my comment to Mirja K=C3=BChlewind regarding this. This text is = here because somebody thought this draft should cover DTLS-over-SCTP. Since you are one of the authors of RFC6083, can you suggest what is appropriate here for DTLS-over-SCTP implementations? My preference would be not to cover DTLS-over-SCTP in this draft and limit it to only DTLS over UDP or TCP. 4. The demux instructions seem to have gotten lost from 6.7.1. At minimum > these need a reference to RFC 7983. > We will add the reference to ICE considerations section. > S 5.1. > media session immediately (see [RFC8122]). Note that it is > permissible to wait until the other side's fingerprint(s) has been > received before establishing the connection; however, this may have > undesirable latency effects. > > I agree that it's permissible, but why would you do this? This does > not seem like helpful guidance. > There are implementations that do this to avoid unauthenticated media. S 10. > Please do something about the "NEW" constructions. I literally had to > pull these into ediff to know what had changed. That's not useful to > people. I'm not a fan of this construction in general, but at minimum > you need to explain what has changed. > This is the best we came up with so far. If you have a better option, please suggest. > S 9. > Regardless of the > previous existence of a DTLS association, the SDP 'setup' attribute > MUST be included according to the rules defined in [RFC4145] and if > ICE is used, ICE restart MUST be initiated. > > What is the rationale for this rule? > This just restates the requirement from https://tools.ietf.org/html/rfc5245#section-12.5 . Not doing so breaks third party call control, since in this case it is not known if this offer is intended for an existing connection or to establish connection with a new end point. Regards, ______________ Roman Shpount --089e082219b4d937050556d38ffa Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Eric,
=

Thank you for your comments.

=
On Tue, Aug 15, 2017 at 7:07 PM, Eric Resc= orla <ekr@rtfm.com> wrote:
1. Assuming I understand this document correctly, it conflic= ts with
the guidance in JSEP. Specifically, S 4 says:

=C2=A0 =C2=A0No default value is defined for the SDP 'tls-id' attri= bute.
=C2=A0 =C2=A0Implementations that wish to use the attribute MUST explicitly=
=C2=A0 =C2=A0include it in SDP offers and answers.=C2=A0 If an offer or ans= wer does not
=C2=A0 =C2=A0contain a 'tls-id' attribute (this could happen if the= offerer or
=C2=A0 =C2=A0answerer represents an existing implementation that has not be= en
=C2=A0 =C2=A0updated to support the 'tls-id' attribute), unless the= re is another
=C2=A0 =C2=A0mechanism to explicitly indicate that a new DTLS association i= s to be
=C2=A0 =C2=A0established, a modification of one or more of the following =C2=A0 =C2=A0characteristics MUST be treated as an indication that an endpo= int
=C2=A0 =C2=A0wants to establish a new DTLS association:

=C2=A0 =C2=A0o=C2=A0 DTLS setup role; or

=C2=A0 =C2=A0o=C2=A0 fingerprint set; or

=C2=A0 =C2=A0o=C2=A0 local transport parameters; or

=C2=A0 =C2=A0o=C2=A0 ICE ufrag value

This seems to say that if there is no tls-id attribute, then an ICE restart=
(which necessitates a ufrag change) requires a DTLS restart. JSEP isn't=
incredibly clear on this point, but 5.7.3 seems to say that tls-id
neeed not be present:

=C2=A0 =C2=A0 =C2=A0 *=C2=A0 tls-id value, which MUST be set according to =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0[I-D.ietf-mmusic-dtls-sdp], Section 5.=C2= =A0 If this is a re-offer
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0and the tls-id value is different from th= at presently in use,
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0the DTLS connection is not being continue= d and the remote
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0description MUST be part of an ICE restar= t, together with new
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0ufrag and password values.=C2=A0 If this = is an answer, the tls-id
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0value, if present, MUST be the same as in= the offer.

I believe that the first sentence is in error, as we clearly
can't have JSEP implementations requiring that tls-id be present.

=C2=A0 =C2=A0...

=C2=A0 =C2=A0o=C2=A0 If the remote DTLS fingerprint has been changed or the= tls-id has
=C2=A0 =C2=A0 =C2=A0 changed, tear down the DTLS connection.=C2=A0 This inc= ludes the case
=C2=A0 =C2=A0 =C2=A0 when the PeerConnection state is "have-remote-pra= nswer".=C2=A0 If a
=C2=A0 =C2=A0 =C2=A0 DTLS connection needs to be torn down but the answer d= oes not
=C2=A0 =C2=A0 =C2=A0 indicate an ICE restart or, in the case of "have-= remote-pranswer",
=C2=A0 =C2=A0 =C2=A0 new ICE credentials, an error MUST be generated.=C2=A0= If an ICE
=C2=A0 =C2=A0 =C2=A0 restart is performed without a change in tls-id or fin= gerprint,
=C2=A0 =C2=A0 =C2=A0 then the same DTLS connection is continued over the ne= w ICE
=C2=A0 =C2=A0 =C2=A0 channel.

I think the best interpretation of this is that if tls-id is not present (and hence unchanged) then ICE restart does not cause DTLS restart.
This is also my memory of the consensus in RTCWEB. In any case, these
two documents clearly must match.

In re= gard to ICE ufrag change without tls-id we just have to make a choice. Both= choices are bad since they both cause things to break when one side would = initiate new DTLS association and another side would not. I would agree tha= t not starting DTLS association on ICE restart is slightly safer.=C2=A0 In = any case, tls-id is needed to avoid this ambiguity. For anything compliant = with the new draft, tls-di must be present.
=C2=A0
2. S 4 says:

=C2=A0 =C2=A0The mux category [I-D.ietf-mmusic-sdp-mux-attributes] for= the 'tls-
=C2=A0 =C2=A0id' attribute is 'IDENTICAL', which means that the= attribute value
=C2=A0 =C2=A0must be identical across all media descriptions being multiple= xed
=C2=A0 =C2=A0[I-D.ietf-mmusic-sdp-bundle-negotiation].

This is not actually what JSEP requires:

=C2=A0 =C2=A0different categories.=C2=A0 To avoid unnecessary duplication w= hen
=C2=A0 =C2=A0bundling, attributes of category IDENTICAL or TRANSPORT MUST N= OT be
=C2=A0 =C2=A0repeated in bundled m=3D sections, repeating the guidance from=
=C2=A0 =C2=A0[I-D.ietf-mmusic-sdp-bundle-negotiation], Section 8.1.=C2= =A0 This includes

I suspect this is old text.

This is old= text and should be corrected=C2=A0

3. S 7.1 says:
=C2=A0 =C2=A0If DTLS is transported on top of a connection-oriented transpo= rt
=C2=A0 =C2=A0protocol (e.g., TCP or SCTP), where all IP packets are acknowl= edged,

This is incorrect, because none of these protocols ack all IP packets.


=C2=A0 =C2=A0all DTLS packets associated with a previous DTLS association M= UST be
=C2=A0 =C2=A0acknowledged (or timed out) before a new DTLS association can = be
=C2=A0 =C2=A0established on the same instance of that transport (5-tuple).<= br>
More generally, I'm not sure that this is useful, because the
required semantic isn't *acknowledged* but rather that the receiver
can appropriately demux. So, say you just stop sending DTLS on
connection A and start sending on B, what's the delimiter, given
that you don't require close_notify here? IIRC, we just decided to
punt on this whole thing. Does anyone try to have successive
connections over the same transport, even when it's connection oriented= ?

=C2=A0
Please see my commen= t to Mirja K=C3=BChlewind regarding this. This text is here because somebod= y thought this draft should cover DTLS-over-SCTP. Since you are one of the = authors of=C2=A0RFC6083, = can you suggest what is appropriate here for DTLS-over-SCTP implementations= ? My preference would be not to cover DTLS-over-SCTP in this draft and limi= t it to only DTLS over UDP or TCP.


4. The demux instructio= ns seem to have gotten lost from 6.7.1. At minimum
these need a reference to RFC 7983.

We = will add the reference to ICE considerations section.
=C2=A0
S 5.1.
=C2=A0 =C2=A0media session immediately (see [RFC8122]).=C2=A0 Note that it = is
=C2=A0 =C2=A0permissible to wait until the other side's fingerprint(s) = has been
=C2=A0 =C2=A0received before establishing the connection; however, this may= have
=C2=A0 =C2=A0undesirable latency effects.

I agree that it's permissible, but why would you do this? This does
not seem like helpful guidance.

There a= re implementations that do this to avoid unauthenticated media.
<= br>
S 10.
Please do something about the "NEW" constructions. I literally ha= d to
pull these into ediff to know what had changed. That's not useful to people. I'm not a fan of this construction in general, but at minimum you need to explain what has changed.

T= his is the best we came up with so far. If you have a better option, please= suggest.
=C2=A0
S 9.
=C2=A0 =C2=A0Regardless of the
=C2=A0 =C2=A0previous existence of a DTLS association, the SDP 'setup&#= 39; attribute
=C2=A0 =C2=A0MUST be included according to the rules defined in [RFC4145] a= nd if
=C2=A0 =C2=A0ICE is used, ICE restart MUST be initiated.

What is the rationale for this rule?

Th= is just restates the requirement from=C2=A0https://tools.ietf.org/html/rfc5245#section-12= .5 . Not doing so breaks third party call control, since in this case i= t is not known if this offer is intended for an existing connection or to e= stablish connection with a new end point.

Regards,=
______________
Roman Shpount
--089e082219b4d937050556d38ffa-- From nobody Tue Aug 15 17:10:10 2017 Return-Path: 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 A07211323C4 for ; Tue, 15 Aug 2017 17:10:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, URIBL_BLOCKED=0.001] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=rtfm-com.20150623.gappssmtp.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 PwmqijbN7qAr for ; Tue, 15 Aug 2017 17:10:01 -0700 (PDT) Received: from mail-yw0-x230.google.com (mail-yw0-x230.google.com [IPv6:2607:f8b0:4002:c05::230]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 543151323B0 for ; Tue, 15 Aug 2017 17:09:58 -0700 (PDT) Received: by mail-yw0-x230.google.com with SMTP id p68so13925861ywg.0 for ; Tue, 15 Aug 2017 17:09:58 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=rtfm-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=gm0CMASDVghIaM/Jk1JA+vgAY7uJhOGdyzE1IaA6QSA=; b=XJ/obmqVr+41trhzl7dYnoDit638mn2U571lts2Cx5KljarJf9cEdzlfaJRvsPLZBU VeKmRRncI4MvKiGshN2PrrtvmzDxcHCAFklpCg/OOLeV3NcjGWGgPT9uoc4iRV47Ac0R sAfvK04At9m/ELhDHCuKbsRDTMZzp2B4C2/5nq43f8JallzzAg8R83GCvBPYqEeLGpcR CsgqxyuQJyVnGwOw/rURur6jHw9D5szo12HfFydFfDUE8S8BTCCE9ihTVTdTmEi+xayd 13iQE2zEnMmqwgV8+zYuQiQ+wCEyGgGmgmkIhpZ3bL72g4IVYgPQbCJx7uM7lno4Dl7h hVRQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=gm0CMASDVghIaM/Jk1JA+vgAY7uJhOGdyzE1IaA6QSA=; b=hPJ1kzx+kmop6Yy1kbwsrYDz34s3ke7pX7yMHI1pLIBaDYf51H29fdjYScM+CCw9fG Y8YdPlKgTE+5VVCOics3m3mDlIHKOYAH7Uu4RfZNFiYgnVjL/kB8rQjaZ3bk5uqaYvKG 2LHtlmXRvULtWw9bXr0Wnkqt6WMvCtxToqNT+XRloXrcnwPSafYt5rq8gH5p0eydrHhL QgyM0mW3gXCVcW5Vz4KL5p83TM7EZQP7FIbSO9jPuagk9aZf/DRKyQj+tvB0Fy7oGukb ByKJfsJmhZuJTR8HQAMBtf2rgI3vMDG2bqYyp1dedtRCHm3xI8wrpppKuD/dOBx+WrBu +DdA== X-Gm-Message-State: AHYfb5gE4xTB1UE8Yr5CZ6LFo7DQCTTRV/rnye5ki+iBZIxMaCE/IR6P EGagby7djj/bjsUQBL/IsGXVCFv8zIAC X-Received: by 10.129.165.150 with SMTP id c144mr24124061ywh.19.1502842197591; Tue, 15 Aug 2017 17:09:57 -0700 (PDT) MIME-Version: 1.0 Received: by 10.13.218.130 with HTTP; Tue, 15 Aug 2017 17:09:16 -0700 (PDT) In-Reply-To: References: From: Eric Rescorla Date: Tue, 15 Aug 2017 17:09:16 -0700 Message-ID: To: Roman Shpount Cc: The IESG , draft-ietf-mmusic-dtls-sdp@ietf.org, mmusic-chairs@ietf.org, lemming Andreasen , "mmusic@ietf.org" , Justin Uberti , Cullen Jennings Content-Type: multipart/alternative; boundary="94eb2c128e3c576e160556d3b712" Archived-At: Subject: Re: [MMUSIC] Eric Rescorla's Discuss on draft-ietf-mmusic-dtls-sdp-28: (with DISCUSS and COMMENT) X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 16 Aug 2017 00:10:04 -0000 --94eb2c128e3c576e160556d3b712 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable +Juberti, Cullen On Tue, Aug 15, 2017 at 4:58 PM, Roman Shpount wrote: > Eric, > > Thank you for your comments. > > On Tue, Aug 15, 2017 at 7:07 PM, Eric Rescorla wrote: > >> 1. Assuming I understand this document correctly, it conflicts with >> the guidance in JSEP. Specifically, S 4 says: >> >> No default value is defined for the SDP 'tls-id' attribute. >> Implementations that wish to use the attribute MUST explicitly >> include it in SDP offers and answers. If an offer or answer does not >> contain a 'tls-id' attribute (this could happen if the offerer or >> answerer represents an existing implementation that has not been >> updated to support the 'tls-id' attribute), unless there is another >> mechanism to explicitly indicate that a new DTLS association is to be >> established, a modification of one or more of the following >> characteristics MUST be treated as an indication that an endpoint >> wants to establish a new DTLS association: >> >> o DTLS setup role; or >> >> o fingerprint set; or >> >> o local transport parameters; or >> >> o ICE ufrag value >> >> This seems to say that if there is no tls-id attribute, then an ICE >> restart >> (which necessitates a ufrag change) requires a DTLS restart. JSEP isn't >> incredibly clear on this point, but 5.7.3 seems to say that tls-id >> neeed not be present: >> >> * tls-id value, which MUST be set according to >> [I-D.ietf-mmusic-dtls-sdp], Section 5. If this is a re-offer >> and the tls-id value is different from that presently in use, >> the DTLS connection is not being continued and the remote >> description MUST be part of an ICE restart, together with new >> ufrag and password values. If this is an answer, the tls-id >> value, if present, MUST be the same as in the offer. >> >> I believe that the first sentence is in error, as we clearly >> can't have JSEP implementations requiring that tls-id be present. >> >> ... >> >> o If the remote DTLS fingerprint has been changed or the tls-id has >> changed, tear down the DTLS connection. This includes the case >> when the PeerConnection state is "have-remote-pranswer". If a >> DTLS connection needs to be torn down but the answer does not >> indicate an ICE restart or, in the case of "have-remote-pranswer", >> new ICE credentials, an error MUST be generated. If an ICE >> restart is performed without a change in tls-id or fingerprint, >> then the same DTLS connection is continued over the new ICE >> channel. >> >> I think the best interpretation of this is that if tls-id is not present >> (and hence unchanged) then ICE restart does not cause DTLS restart. >> This is also my memory of the consensus in RTCWEB. In any case, these >> two documents clearly must match. >> > > In regard to ICE ufrag change without tls-id we just have to make a > choice. Both choices are bad since they both cause things to break when o= ne > side would initiate new DTLS association and another side would not. I > would agree that not starting DTLS association on ICE restart is slightly > safer. In any case, tls-id is needed to avoid this ambiguity. For anythi= ng > compliant with the new draft, tls-di must be present. > I agree that going forward we need this. My sense is that the JSEP version is better, but I've CCed Cullen and Justin to see what they think. > > 3. S 7.1 says: >> If DTLS is transported on top of a connection-oriented transport >> protocol (e.g., TCP or SCTP), where all IP packets are acknowledged, >> >> This is incorrect, because none of these protocols ack all IP packets. >> >> >> all DTLS packets associated with a previous DTLS association MUST be >> acknowledged (or timed out) before a new DTLS association can be >> established on the same instance of that transport (5-tuple). >> >> More generally, I'm not sure that this is useful, because the >> required semantic isn't *acknowledged* but rather that the receiver >> can appropriately demux. So, say you just stop sending DTLS on >> connection A and start sending on B, what's the delimiter, given >> that you don't require close_notify here? IIRC, we just decided to >> punt on this whole thing. Does anyone try to have successive >> connections over the same transport, even when it's connection oriented? >> > > > Please see my comment to Mirja K=C3=BChlewind regarding this. This text i= s here > because somebody thought this draft should cover DTLS-over-SCTP. Since yo= u > are one of the authors of RFC6083, can you suggest what is appropriate > here for DTLS-over-SCTP implementations? My preference would be not to > cover DTLS-over-SCTP in this draft and limit it to only DTLS over UDP or > TCP. > I agree with you. I don't think it's helpful to cover this here. Is this a question for the WG. > S 5.1. >> media session immediately (see [RFC8122]). Note that it is >> permissible to wait until the other side's fingerprint(s) has been >> received before establishing the connection; however, this may have >> undesirable latency effects. >> >> I agree that it's permissible, but why would you do this? This does >> not seem like helpful guidance. >> > > There are implementations that do this to avoid unauthenticated media. > Fair enough. S 10. >> Please do something about the "NEW" constructions. I literally had to >> pull these into ediff to know what had changed. That's not useful to >> people. I'm not a fan of this construction in general, but at minimum >> you need to explain what has changed. >> > > This is the best we came up with so far. If you have a better option, > please suggest. > Please provide a summary of what's changed. > >> S 9. >> Regardless of the >> previous existence of a DTLS association, the SDP 'setup' attribute >> MUST be included according to the rules defined in [RFC4145] and if >> ICE is used, ICE restart MUST be initiated. >> >> What is the rationale for this rule? >> > > This just restates the requirement from https://tools.ietf.org/ > html/rfc5245#section-12.5 . Not doing so breaks third party call control, > since in this case it is not known if this offer is intended for an > existing connection or to establish connection with a new end point. > A citation here would help. -Ekr > > Regards, > ______________ > Roman Shpount > --94eb2c128e3c576e160556d3b712 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
+Juberti, Cullen

On Tue, Aug 15, 2017 at 4:58 PM, Roman Shpount <roman@= telurix.com> wrote:
Eri= c,

Thank you for your comments.
On Tue, Aug 15, 2= 017 at 7:07 PM, Eric Rescorla <ekr@rtfm.com> wrote:
1. Assuming I understand this docum= ent correctly, it conflicts with
the guidance in JSEP. Specifically, S 4 says:

=C2=A0 =C2=A0No default value is defined for the SDP 'tls-id' attri= bute.
=C2=A0 =C2=A0Implementations that wish to use the attribute MUST explicitly=
=C2=A0 =C2=A0include it in SDP offers and answers.=C2=A0 If an offer or ans= wer does not
=C2=A0 =C2=A0contain a 'tls-id' attribute (this could happen if the= offerer or
=C2=A0 =C2=A0answerer represents an existing implementation that has not be= en
=C2=A0 =C2=A0updated to support the 'tls-id' attribute), unless the= re is another
=C2=A0 =C2=A0mechanism to explicitly indicate that a new DTLS association i= s to be
=C2=A0 =C2=A0established, a modification of one or more of the following =C2=A0 =C2=A0characteristics MUST be treated as an indication that an endpo= int
=C2=A0 =C2=A0wants to establish a new DTLS association:

=C2=A0 =C2=A0o=C2=A0 DTLS setup role; or

=C2=A0 =C2=A0o=C2=A0 fingerprint set; or

=C2=A0 =C2=A0o=C2=A0 local transport parameters; or

=C2=A0 =C2=A0o=C2=A0 ICE ufrag value

This seems to say that if there is no tls-id attribute, then an ICE restart=
(which necessitates a ufrag change) requires a DTLS restart. JSEP isn't=
incredibly clear on this point, but 5.7.3 seems to say that tls-id
neeed not be present:

=C2=A0 =C2=A0 =C2=A0 *=C2=A0 tls-id value, which MUST be set according to =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0[I-D.ietf-mmusic-dtls-sdp], Section 5.=C2= =A0 If this is a re-offer
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0and the tls-id value is different from th= at presently in use,
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0the DTLS connection is not being continue= d and the remote
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0description MUST be part of an ICE restar= t, together with new
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0ufrag and password values.=C2=A0 If this = is an answer, the tls-id
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0value, if present, MUST be the same as in= the offer.

I believe that the first sentence is in error, as we clearly
can't have JSEP implementations requiring that tls-id be present.

=C2=A0 =C2=A0...

=C2=A0 =C2=A0o=C2=A0 If the remote DTLS fingerprint has been changed or the= tls-id has
=C2=A0 =C2=A0 =C2=A0 changed, tear down the DTLS connection.=C2=A0 This inc= ludes the case
=C2=A0 =C2=A0 =C2=A0 when the PeerConnection state is "have-remote-pra= nswer".=C2=A0 If a
=C2=A0 =C2=A0 =C2=A0 DTLS connection needs to be torn down but the answer d= oes not
=C2=A0 =C2=A0 =C2=A0 indicate an ICE restart or, in the case of "have-= remote-pranswer",
=C2=A0 =C2=A0 =C2=A0 new ICE credentials, an error MUST be generated.=C2=A0= If an ICE
=C2=A0 =C2=A0 =C2=A0 restart is performed without a change in tls-id or fin= gerprint,
=C2=A0 =C2=A0 =C2=A0 then the same DTLS connection is continued over the ne= w ICE
=C2=A0 =C2=A0 =C2=A0 channel.

I think the best interpretation of this is that if tls-id is not present (and hence unchanged) then ICE restart does not cause DTLS restart.
This is also my memory of the consensus in RTCWEB. In any case, these
two documents clearly must match.

In regard to ICE ufrag change without tls-id we just have to make a = choice. Both choices are bad since they both cause things to break when one= side would initiate new DTLS association and another side would not. I wou= ld agree that not starting DTLS association on ICE restart is slightly safe= r.=C2=A0 In any case, tls-id is needed to avoid this ambiguity. For anythin= g compliant with the new draft, tls-di must be present.

I agree that going forward we need thi= s. My sense is that the JSEP version is better,
but I've CCed= Cullen and Justin to see what they think.


=C2=A0

3. S 7.1 says:
=C2=A0 =C2=A0If DTLS is transported on top of a connection-oriented transpo= rt
=C2=A0 =C2=A0protocol (e.g., TCP or SCTP), where all IP packets are acknowl= edged,

This is incorrect, because none of these protocols ack all IP packets.


=C2=A0 =C2=A0all DTLS packets associated with a previous DTLS association M= UST be
=C2=A0 =C2=A0acknowledged (or timed out) before a new DTLS association can = be
=C2=A0 =C2=A0established on the same instance of that transport (5-tuple).<= br>
More generally, I'm not sure that this is useful, because the
required semantic isn't *acknowledged* but rather that the receiver
can appropriately demux. So, say you just stop sending DTLS on
connection A and start sending on B, what's the delimiter, given
that you don't require close_notify here? IIRC, we just decided to
punt on this whole thing. Does anyone try to have successive
connections over the same transport, even when it's connection oriented= ?

=C2=A0
Please see my= comment to Mirja K=C3=BChlewind regarding this. This text is here because = somebody thought this draft should cover DTLS-over-SCTP. Since you are one = of the authors of=C2=A0RF= C6083, can you suggest what is appropriate here for DTLS-over-SCTP implemen= tations? My preference would be not to cover DTLS-over-SCTP in this draft a= nd limit it to only DTLS over UDP or TCP.

I agree with you. I don't think it's = helpful to cover this here. Is this a question for the
WG.
<= div>
=C2=A0
=
S= 5.1.
=C2=A0 =C2=A0media session immediately (see [RFC8122]).=C2=A0 Note that it = is
=C2=A0 =C2=A0permissible to wait until the other side's fingerprint(s) = has been
=C2=A0 =C2=A0received before establishing the connection; however, this may= have
=C2=A0 =C2=A0undesirable latency effects.

I agree that it's permissible, but why would you do this? This does
not seem like helpful guidance.

= There are implementations that do this to avoid unauthenticated media.

Fair enough.
=

S 10.
Please do something about the "NEW" constructions. I literally ha= d to
pull these into ediff to know what had changed. That's not useful to people. I'm not a fan of this construction in general, but at minimum you need to explain what has changed.

This is the best we came up with so far. If you have a better option,= please suggest.

Pl= ease provide a summary of what's changed.


=
=C2=A0
S 9.
=C2=A0 =C2=A0Regardless of the
=C2=A0 =C2=A0previous existence of a DTLS association, the SDP 'setup&#= 39; attribute
=C2=A0 =C2=A0MUST be included according to the rules defined in [RFC4145] a= nd if
=C2=A0 =C2=A0ICE is used, ICE restart MUST be initiated.

What is the rationale for this rule?

=
This just restates the requirement from=C2=A0https://tools.ietf.or= g/html/rfc5245#section-12.5 . Not doing so breaks third party call= control, since in this case it is not known if this offer is intended for = an existing connection or to establish connection with a new end point.

A citation here would = help.

-Ekr
=C2=A0

Regards,
______________
Roman Shpount

--94eb2c128e3c576e160556d3b712-- From nobody Wed Aug 16 16:06:39 2017 Return-Path: X-Original-To: mmusic@ietf.org Delivered-To: mmusic@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 9514F132480; Wed, 16 Aug 2017 16:06:31 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: Adam Roach To: "The IESG" Cc: draft-ietf-mmusic-dtls-sdp@ietf.org, mmusic-chairs@ietf.org, fandreas@cisco.com, mmusic@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.58.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <150292479151.11986.12302184246173787021.idtracker@ietfa.amsl.com> Date: Wed, 16 Aug 2017 16:06:31 -0700 Archived-At: Subject: [MMUSIC] Adam Roach's Discuss on draft-ietf-mmusic-dtls-sdp-28: (with DISCUSS and COMMENT) X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.22 List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 16 Aug 2017 23:06:32 -0000 Adam Roach has entered the following ballot position for draft-ietf-mmusic-dtls-sdp-28: Discuss When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-mmusic-dtls-sdp/ ---------------------------------------------------------------------- DISCUSS: ---------------------------------------------------------------------- Section 5.4 says: NOTE: A new DTLS association can be established based on changes in either an SDP offer or answer. When communicating with legacy endpoints, an offerer can receive an answer that includes the same fingerprint set and setup role. A new DTLS association MUST still be established if such an answer was received as a response to an offer which requested the establishment of a new DTLS association. Unless I've misunderstood something important, this isn't going to work with legacy implementations, unless you also specify that an "offer which requested the establishment of a new DTLS association" must also change something else that the legacy answerer will recognize as requiring a new DTLS association. For example, if I send a re-offer with a changed tls-id but the same fingerprint, setup, and transport, the far end will have no reason to think it needs to establish a new DTLS association. So I'll sit there waiting for a new association to be established, and the remote side will never send one. This doesn't seem backwards-compatible. At the very least, more text needs to be added explaining how this is intended to work. ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- I agree with the core assertion of EKR's DISCUSS: this document needs to be aligned with JSEP. I think we're going to need a little additional work figuring out which document needs to change where they disagree. In addition to those areas he highlights in his DISCUSS, the following text is also in conflict: DTLS-SDP: "the offerer and answerer generate their own local 'tls-id' attribute values, and the combination of both values identify the DTLS association." JSEP: "If this is an answer, the tls-id value, if present, MUST be the same as in the offer." I would think the long-form title of this document should include "TLS," to reflect that it also contains TLS-related procedures. Section 1: "...but currently there is no way..." will not age well once this is an RFC. Suggest "...previously, there was no way..." or somesuch. Section 2 uses RFC 2119 boilerplate, and then the very next sentence uses a non-normative "must." I would strongly recommend moving to RFC 8174 boilerplate. The conventional name for DTLS-SRTP is "DTLS-SRTP" -- please change replace "SRTP-DTLS" with "DTLS-SRTP" everywhere it appears. The last paragraph in section 5.4 starts with "NOTE" (which implementors frequently read as non-normative) and then contains a normative statement. Suggest removing "NOTE:" Please expand the following acronyms upon first use and in the title; see https://www.rfc-editor.org/materials/abbrev.expansion.txt for guidance. - SDP - Session Description Protocol - DTLS - Datagram Transport Layer Security - TLS - Transport Layer Security - ICE - Interactive Connectivity Establishment - SCTP - Stream Control Transmission Protocol - SRTP - Secure Realtime Transport Protocol - UDPTL - UDP Transport Layer From nobody Thu Aug 17 13:55:13 2017 Return-Path: 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 6610A13263E for ; Thu, 17 Aug 2017 13:55:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.388 X-Spam-Level: X-Spam-Status: No, score=-1.388 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_SORBS_SPAM=0.5, T_SPF_PERMERROR=0.01, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=telurix-com.20150623.gappssmtp.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 wa5-e30PuqOG for ; Thu, 17 Aug 2017 13:55:01 -0700 (PDT) Received: from mail-pg0-x22c.google.com (mail-pg0-x22c.google.com [IPv6:2607:f8b0:400e:c05::22c]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3C664126B6E for ; Thu, 17 Aug 2017 13:55:00 -0700 (PDT) Received: by mail-pg0-x22c.google.com with SMTP id i12so50309820pgr.3 for ; Thu, 17 Aug 2017 13:55:00 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=telurix-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=A47IUfqz7mv2Zu/VS1Ylga6PlnjjPx0uib1qHfzyl+E=; b=XmGCPPrcmHhMtJ38EbnmVOUy68j89+TjyAC7qXhwmLuxMXj1nCAZDHTESGAKKkaxwr g06F9f8pp2EO2CkdcyTu8mqSFy9r0WL+Dcx/03vzEmkXiRf0v9uj/p06iU6aeucx6uyq Olw/IhLTSnHaJYBkipTCNNedvNnT6EzkR7LLYFGCD/x/hZV/X2WfTw44Y/wDszrf6sL8 KLfHBeQ5Y5frrjE32vMMOFF5zi1JDI+Bpqa3JGKkDTFyrHiGfi3z3nKgNX5eI3rH1DV8 Q0RrFbs5iKvXEfD0sOA0oMxWuhc51CnPZFD0DvehqhKSpr7Q9MHlMtjtARZ0s09HsEss fkRQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=A47IUfqz7mv2Zu/VS1Ylga6PlnjjPx0uib1qHfzyl+E=; b=nqTRWkQLw2vzlGI3EpOpwp4fplTqXBxLetLp4ROvGdpFhSOVfiIOsvxf9tbZWHeQa7 X5mzJ1N0J3JAV0kyuwEggp31tzrVBrPLcMEATBtVYjSWG8SGAvvLCO6HfNDeHgsFOWWR e7NCjNYdBFN+vNnDNueTLSMZV5EjA7nBb9i6pFqVbIlVrp4KFoXWRTSHuPhBz8fhFjZy DzCPcXDAo3rpS7ad9fFZHUXWCvJsiRfzWRB3utelaocAYml25KXK7ifOf6M3C5qLFu16 l1lzaX93RsB1LecYrKS0hJ3FcQXD6EOWM5VOHK+V14jyV7R8N6BaNMpDWUyY1eQ/YOEs VlXg== X-Gm-Message-State: AHYfb5i+i8ehIdZia00mV4MFyz71m3RcI4cMFn9Dwrl8RYFbsigvW7Os gUwHvhWS+a102g62 X-Received: by 10.98.211.73 with SMTP id q70mr6407649pfg.285.1503003299644; Thu, 17 Aug 2017 13:54:59 -0700 (PDT) Received: from mail-pg0-f41.google.com (mail-pg0-f41.google.com. [74.125.83.41]) by smtp.gmail.com with ESMTPSA id a22sm4907754pfj.94.2017.08.17.13.54.59 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 17 Aug 2017 13:54:59 -0700 (PDT) Received: by mail-pg0-f41.google.com with SMTP id t80so22684370pgb.5; Thu, 17 Aug 2017 13:54:59 -0700 (PDT) X-Received: by 10.84.231.193 with SMTP id g1mr7081689pln.213.1503003298847; Thu, 17 Aug 2017 13:54:58 -0700 (PDT) MIME-Version: 1.0 Received: by 10.100.191.8 with HTTP; Thu, 17 Aug 2017 13:54:58 -0700 (PDT) In-Reply-To: <150292479151.11986.12302184246173787021.idtracker@ietfa.amsl.com> References: <150292479151.11986.12302184246173787021.idtracker@ietfa.amsl.com> From: Roman Shpount Date: Thu, 17 Aug 2017 16:54:58 -0400 X-Gmail-Original-Message-ID: Message-ID: To: Adam Roach Cc: The IESG , draft-ietf-mmusic-dtls-sdp@ietf.org, mmusic-chairs@ietf.org, lemming Andreasen , "mmusic@ietf.org" Content-Type: multipart/alternative; boundary="f403045fdd96b963a60556f9397b" Archived-At: Subject: Re: [MMUSIC] Adam Roach's Discuss on draft-ietf-mmusic-dtls-sdp-28: (with DISCUSS and COMMENT) X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 17 Aug 2017 20:55:03 -0000 --f403045fdd96b963a60556f9397b Content-Type: text/plain; charset="UTF-8" On Wed, Aug 16, 2017 at 7:06 PM, Adam Roach wrote: > Section 5.4 says: > > NOTE: A new DTLS association can be established based on changes in > either an SDP offer or answer. When communicating with legacy > endpoints, an offerer can receive an answer that includes the same > fingerprint set and setup role. A new DTLS association MUST still be > established if such an answer was received as a response to an offer > which requested the establishment of a new DTLS association. > > Unless I've misunderstood something important, this isn't going to work > with > legacy implementations, unless you also specify that an "offer which > requested > the establishment of a new DTLS association" must also change something > else > that the legacy answerer will recognize as requiring a new DTLS > association. > For example, if I send a re-offer with a changed tls-id but the same > fingerprint, setup, and transport, the far end will have no reason to > think it > needs to establish a new DTLS association. So I'll sit there waiting for a > new > association to be established, and the remote side will never send one. > > This doesn't seem backwards-compatible. At the very least, more text needs > to > be added explaining how this is intended to work. > The intention was to specify that an offering party sends an offer with new value of tls-id, it can get back an answer without tls-id, unchanged remote fingerprint values and setup role . In this case new DTLS association MUST be established. As you have correctly mentioned, tls-id can be changed with no changes in fingerprints, but current specification requires changing the transport parameters whenever tls-id is changed. The transport parameter change should cause new DTLS association to be established, even if remote is a legacy end point. In this case, even if remote legacy end point responds with existing fingerprints, transport parameters and setup role, it is safer to assume that new DTLS association should be established. > I agree with the core assertion of EKR's DISCUSS: this document needs to be > aligned with JSEP. I think we're going to need a little additional work > figuring out which document needs to change where they disagree. In > addition to > those areas he highlights in his DISCUSS, the following text is also in > conflict: > > DTLS-SDP: "the offerer and answerer generate their own local 'tls-id' > attribute > values, and the combination of both values identify the DTLS association." > > JSEP: "If this is an answer, the tls-id value, if present, MUST be the > same as > in the offer." > JSEP needs to be adjusted in this case. Specification does not work if tls-id is reflected in the answer. Different tls-id in the answer are used to disambiguate multiple DTLS associations in case of forking. _____________ Roman Shpount --f403045fdd96b963a60556f9397b Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
On Wed, Aug 16, 2017 at 7:06= PM, Adam Roach <adam@nostrum.com> wrote:
Se= ction 5.4 says:

=C2=A0 =C2=A0NOTE: A new DTLS association can be established based on chang= es in
=C2=A0 =C2=A0either an SDP offer or answer.=C2=A0 When communicating with l= egacy
=C2=A0 =C2=A0endpoints, an offerer can receive an answer that includes the = same
=C2=A0 =C2=A0fingerprint set and setup role.=C2=A0 A new DTLS association M= UST still be
=C2=A0 =C2=A0established if such an answer was received as a response to an= offer
=C2=A0 =C2=A0which requested the establishment of a new DTLS association.
Unless I've misunderstood something important, this isn't going to = work with
legacy implementations, unless you also specify that an "offer which r= equested
the establishment of a new DTLS association" must also change somethin= g else
that the legacy answerer will recognize as requiring a new DTLS association= .
For example, if I send a re-offer with a changed tls-id but the same
fingerprint, setup, and transport, the far end will have no reason to think= it
needs to establish a new DTLS association. So I'll sit there waiting fo= r a new
association to be established, and the remote side will never send one.

This doesn't seem backwards-compatible. At the very least, more text ne= eds to
be added explaining how this is intended to work.

=
The intention was to specify that an offering party sends an off= er with new value of tls-id, it can get back an answer without tls-id, unch= anged remote fingerprint values and setup role . In this case new DTLS asso= ciation MUST be established.

As you have correctly= mentioned, tls-id can be changed with no changes in fingerprints, but curr= ent specification requires changing the transport parameters whenever tls-i= d is changed. The transport parameter change should cause new DTLS associat= ion to be established, even if remote is a legacy end point. In this case, = even if remote legacy end point responds with existing fingerprints, transp= ort parameters and setup role, it is safer to assume that new DTLS associat= ion should be established.
=C2=A0
I agree with the core assertion of EKR's DISCUS= S: this document needs to be
aligned with JSEP. I think we're going to need a little additional work=
figuring out which document needs to change where they disagree. In additio= n to
those areas he highlights in his DISCUSS, the following text is also in
conflict:

DTLS-SDP: "the offerer and answerer generate their own local 'tls-= id' attribute
values, and the combination of both values identify the DTLS association.&q= uot;

JSEP: "If this is an answer, the tls-id value, if present, MUST be the= same as
in the offer."

JSEP needs to be ad= justed in this case. Specification does not work if tls-id is reflected in = the answer. Different tls-id in the answer are used to disambiguate multipl= e DTLS associations in case of forking.
=C2=A0
__________= ___
Roman Shpount
=C2=A0
--f403045fdd96b963a60556f9397b-- From nobody Thu Aug 17 15:51:27 2017 Return-Path: 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 55A83132659; Thu, 17 Aug 2017 15:51:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.878 X-Spam-Level: X-Spam-Status: No, score=-1.878 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, T_SPF_HELO_PERMERROR=0.01, T_SPF_PERMERROR=0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no 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 8SC165PpEW0v; Thu, 17 Aug 2017 15:51:24 -0700 (PDT) Received: from nostrum.com (raven-v6.nostrum.com [IPv6:2001:470:d:1130::1]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 998EE132395; Thu, 17 Aug 2017 15:51:24 -0700 (PDT) Received: from Svantevit.roach.at (cpe-70-122-154-80.tx.res.rr.com [70.122.154.80]) (authenticated bits=0) by nostrum.com (8.15.2/8.15.2) with ESMTPSA id v7HMpJhp099785 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NO); Thu, 17 Aug 2017 17:51:20 -0500 (CDT) (envelope-from adam@nostrum.com) X-Authentication-Warning: raven.nostrum.com: Host cpe-70-122-154-80.tx.res.rr.com [70.122.154.80] claimed to be Svantevit.roach.at To: Roman Shpount Cc: draft-ietf-mmusic-dtls-sdp@ietf.org, mmusic-chairs@ietf.org, lemming Andreasen , The IESG , "mmusic@ietf.org" References: <150292479151.11986.12302184246173787021.idtracker@ietfa.amsl.com> From: Adam Roach Message-ID: Date: Thu, 17 Aug 2017 17:51:18 -0500 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:52.0) Gecko/20100101 Thunderbird/52.2.1 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/alternative; boundary="------------36744851602A55792755D7D7" Content-Language: en-US Archived-At: Subject: Re: [MMUSIC] Adam Roach's Discuss on draft-ietf-mmusic-dtls-sdp-28: (with DISCUSS and COMMENT) X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 17 Aug 2017 22:51:26 -0000 This is a multi-part message in MIME format. --------------36744851602A55792755D7D7 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit On 8/17/17 3:54 PM, Roman Shpount wrote: > On Wed, Aug 16, 2017 at 7:06 PM, Adam Roach > wrote: > > Section 5.4 says: > > NOTE: A new DTLS association can be established based on changes in > either an SDP offer or answer. When communicating with legacy > endpoints, an offerer can receive an answer that includes the same > fingerprint set and setup role. A new DTLS association MUST > still be > established if such an answer was received as a response to an > offer > which requested the establishment of a new DTLS association. > > Unless I've misunderstood something important, this isn't going to > work with > legacy implementations, unless you also specify that an "offer > which requested > the establishment of a new DTLS association" must also change > something else > that the legacy answerer will recognize as requiring a new DTLS > association. > For example, if I send a re-offer with a changed tls-id but the same > fingerprint, setup, and transport, the far end will have no reason > to think it > needs to establish a new DTLS association. So I'll sit there > waiting for a new > association to be established, and the remote side will never send > one. > > This doesn't seem backwards-compatible. At the very least, more > text needs to > be added explaining how this is intended to work. > > > The intention was to specify that an offering party sends an offer > with new value of tls-id, it can get back an answer without tls-id, > unchanged remote fingerprint values and setup role . In this case new > DTLS association MUST be established. > > As you have correctly mentioned, tls-id can be changed with no changes > in fingerprints, but current specification requires changing the > transport parameters whenever tls-id is changed. The transport > parameter change should cause new DTLS association to be established, > even if remote is a legacy end point. In this case, even if remote > legacy end point responds with existing fingerprints, transport > parameters and setup role, it is safer to assume that new DTLS > association should be established. Ah, okay. This makes sense. Perhaps add a bit of text to that effect (e.g., "A new DTLS will still be established if such an answer was received as a response to an offer which requested the establishment of a new DTLS association, as the transport parameters will have been changed in the offer.") Clearing my DISCUSS. > JSEP needs to be adjusted in this case. Specification does not work if > tls-id is reflected in the answer. Different tls-id in the answer are > used to disambiguate multiple DTLS associations in case of forking. That was my assumption too. /a --------------36744851602A55792755D7D7 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit
On 8/17/17 3:54 PM, Roman Shpount wrote:
On Wed, Aug 16, 2017 at 7:06 PM, Adam Roach <adam@nostrum.com> wrote:
Section 5.4 says:

   NOTE: A new DTLS association can be established based on changes in
   either an SDP offer or answer.  When communicating with legacy
   endpoints, an offerer can receive an answer that includes the same
   fingerprint set and setup role.  A new DTLS association MUST still be
   established if such an answer was received as a response to an offer
   which requested the establishment of a new DTLS association.

Unless I've misunderstood something important, this isn't going to work with
legacy implementations, unless you also specify that an "offer which requested
the establishment of a new DTLS association" must also change something else
that the legacy answerer will recognize as requiring a new DTLS association.
For example, if I send a re-offer with a changed tls-id but the same
fingerprint, setup, and transport, the far end will have no reason to think it
needs to establish a new DTLS association. So I'll sit there waiting for a new
association to be established, and the remote side will never send one.

This doesn't seem backwards-compatible. At the very least, more text needs to
be added explaining how this is intended to work.

The intention was to specify that an offering party sends an offer with new value of tls-id, it can get back an answer without tls-id, unchanged remote fingerprint values and setup role . In this case new DTLS association MUST be established.

As you have correctly mentioned, tls-id can be changed with no changes in fingerprints, but current specification requires changing the transport parameters whenever tls-id is changed. The transport parameter change should cause new DTLS association to be established, even if remote is a legacy end point. In this case, even if remote legacy end point responds with existing fingerprints, transport parameters and setup role, it is safer to assume that new DTLS association should be established.

Ah, okay. This makes sense. Perhaps add a bit of text to that effect (e.g., "A new DTLS will still be established if such an answer was received as a response to an offer which requested the establishment of a new DTLS association, as the transport parameters will have been changed in the offer.")

Clearing my DISCUSS.

JSEP needs to be adjusted in this case. Specification does not work if tls-id is reflected in the answer. Different tls-id in the answer are used to disambiguate multiple DTLS associations in case of forking.

That was my assumption too.

/a
--------------36744851602A55792755D7D7-- From nobody Thu Aug 17 15:53:06 2017 Return-Path: X-Original-To: mmusic@ietf.org Delivered-To: mmusic@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 9EF8413267F; Thu, 17 Aug 2017 15:53:05 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: Adam Roach To: "The IESG" Cc: draft-ietf-mmusic-dtls-sdp@ietf.org, mmusic-chairs@ietf.org, fandreas@cisco.com, mmusic@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.58.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <150301038555.14103.1567567703984434290.idtracker@ietfa.amsl.com> Date: Thu, 17 Aug 2017 15:53:05 -0700 Archived-At: Subject: [MMUSIC] Adam Roach's No Objection on draft-ietf-mmusic-dtls-sdp-28: (with COMMENT) X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.22 List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 17 Aug 2017 22:53:06 -0000 Adam Roach has entered the following ballot position for draft-ietf-mmusic-dtls-sdp-28: No Objection When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-mmusic-dtls-sdp/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- Thanks for the quick answer to my DISCUSS. I agree with the core assertion of EKR's DISCUSS: this document needs to be aligned with JSEP. I think we're going to need a little additional work figuring out which document needs to change where they disagree. In addition to those areas he highlights in his DISCUSS, the following text is also in conflict: DTLS-SDP: "the offerer and answerer generate their own local 'tls-id' attribute values, and the combination of both values identify the DTLS association." JSEP: "If this is an answer, the tls-id value, if present, MUST be the same as in the offer." [Note: this does appear to be an issue in JSEP rather than this document] I would think the long-form title of this document should include "TLS," to reflect that it also contains TLS-related procedures. Section 1: "...but currently there is no way..." will not age well once this is an RFC. Suggest "...previously, there was no way..." or somesuch. Section 2 uses RFC 2119 boilerplate, and then the very next sentence uses a non-normative "must." I would strongly recommend moving to RFC 8174 boilerplate. The conventional name for DTLS-SRTP is "DTLS-SRTP" -- please change replace "SRTP-DTLS" with "DTLS-SRTP" everywhere it appears. The last paragraph in section 5.4 starts with "NOTE" (which implementors frequently read as non-normative) and then contains a normative statement. Suggest removing "NOTE:" Please expand the following acronyms upon first use and in the title; see https://www.rfc-editor.org/materials/abbrev.expansion.txt for guidance. - SDP - Session Description Protocol - DTLS - Datagram Transport Layer Security - TLS - Transport Layer Security - ICE - Interactive Connectivity Establishment - SCTP - Stream Control Transmission Protocol - SRTP - Secure Realtime Transport Protocol - UDPTL - UDP Transport Layer From nobody Wed Aug 23 02:39:02 2017 Return-Path: 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 7F32913293C; Wed, 23 Aug 2017 02:39:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.22 X-Spam-Level: X-Spam-Status: No, score=-4.22 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no 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 2pD6Coe6rEXg; Wed, 23 Aug 2017 02:38:58 -0700 (PDT) Received: from sesbmg23.ericsson.net (sesbmg23.ericsson.net [193.180.251.37]) (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 CD5FA132BE1; Wed, 23 Aug 2017 02:38:54 -0700 (PDT) X-AuditID: c1b4fb25-d31059c000005333-e3-599d4d2c7370 Received: from ESESSHC001.ericsson.se (Unknown_Domain [153.88.183.21]) by sesbmg23.ericsson.net (Symantec Mail Security) with SMTP id 22.83.21299.C2D4D995; Wed, 23 Aug 2017 11:38:52 +0200 (CEST) Received: from ESESSMB109.ericsson.se ([169.254.9.194]) by ESESSHC001.ericsson.se ([153.88.183.21]) with mapi id 14.03.0352.000; Wed, 23 Aug 2017 11:38:29 +0200 From: Christer Holmberg To: Adam Roach , The IESG CC: "draft-ietf-mmusic-dtls-sdp@ietf.org" , "mmusic-chairs@ietf.org" , "fandreas@cisco.com" , "mmusic@ietf.org" Thread-Topic: Adam Roach's No Objection on draft-ietf-mmusic-dtls-sdp-28: (with COMMENT) Thread-Index: AQHTF6uY+fnArxR5YU+2MrlLLf27GqKRybkA Date: Wed, 23 Aug 2017 09:38:28 +0000 Message-ID: References: <150301038555.14103.1567567703984434290.idtracker@ietfa.amsl.com> In-Reply-To: <150301038555.14103.1567567703984434290.idtracker@ietfa.amsl.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.7.4.170508 x-originating-ip: [153.88.183.146] Content-Type: text/plain; charset="iso-8859-1" Content-ID: <3D2469791294DA4AA26F1C10CA63293B@ericsson.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFtrKIsWRmVeSWpSXmKPExsUyM2K7qK6O79xIg33HxC32/F3EbvF/4nxW i/cXdC1m/JnIbHF+53omi6nLH7M4sHlM+b2R1WPJkp9MHrN2PmEJYI7isklJzcksSy3St0vg ylh98wZrwVmRivmru5gaGB8IdDFyckgImEjsmXGLCcQWEjjCKLH0s3cXIxeQvYRR4tqUp8xd jBwcbAIWEt3/tEFqRASsJU43n2QGqWEWuMEo8WPyTDaQhLBApMTJB62MEEVREs+ez4GyjSRO /jvPDGKzCKhKTL5yEMzmBRr06cFaFojFvhIt+/6DHcEp4Cex8/BqsDijgJjE91NrwOLMAuIS t57MZ4I4WkBiyR6ImRICohIvH/9jBblTVEBP4t1+T4iwksSPDZdYIFr1JG5MncIGUsIMtHbr rWyIsLbEsoWvoa4RlDg58wnLBEbxWUiWzULSPQuhexaS7llIuhcwsq5iFC1OLU7KTTcy1kst ykwuLs7P08tLLdnECIzMg1t+q+5gvPzG8RCjAAejEg9vicXcSCHWxLLiytxDjBIczEoivLu9 gEK8KYmVValF+fFFpTmpxYcYpTlYlMR5HfddiBASSE8sSc1OTS1ILYLJMnFwSjUwhoaYJHPZ eLR17mV3zpncGrjIRW6F6kSPVLkmptiDzaeYN30vyOc/Exo+X7X3SfzJeROTLp3ffdz6YSPT WTsOLePEY2ab5D9FfrrDcXw3g807nsDDj41esqfwZOQ/flzW+TR8d5N+29xHh35nLLjCbsDk zNjyRiTuR9uEBX6NeVtrFerrRGWUWIozEg21mIuKEwH1iodFyAIAAA== Archived-At: Subject: Re: [MMUSIC] Adam Roach's No Objection on draft-ietf-mmusic-dtls-sdp-28: (with COMMENT) X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 23 Aug 2017 09:39:00 -0000 Hi Adam, Thanks for your review! I see that you cleared your DISCUSS, but suggested some clarification text. We will look into that. >---------------------------------------------------------------------- >COMMENT: >---------------------------------------------------------------------- > >Thanks for the quick answer to my DISCUSS. > >I agree with the core assertion of EKR's DISCUSS: this document needs to >be >aligned with JSEP. I think we're going to need a little additional work >figuring out which document needs to change where they disagree. In >addition to >those areas he highlights in his DISCUSS, the following text is also in >conflict: > >DTLS-SDP: "the offerer and answerer generate their own local 'tls-id' >attribute >values, and the combination of both values identify the DTLS association." > >JSEP: "If this is an answer, the tls-id value, if present, MUST be the >same as >in the offer." > >[Note: this does appear to be an issue in JSEP rather than this document] Correct. >I would think the long-form title of this document should include "TLS," >to >reflect that it also contains TLS-related procedures. The issue is that the document doesn=B9t really define the O/A procedures for TLS. It simply adds the usage of the tls-id attribute to the existing procedures defined elsewhere. >Section 1: "...but currently there is no way..." will not age well once >this is >an RFC. Suggest "...previously, there was no way..." or somesuch. I will modify as suggested. >Section 2 uses RFC 2119 boilerplate, and then the very next sentence uses >a >non-normative "must." I would strongly recommend moving to RFC 8174 >boilerplate. I will change the boilerplate. >The conventional name for DTLS-SRTP is "DTLS-SRTP" -- please change >replace >"SRTP-DTLS" with "DTLS-SRTP" everywhere it appears. I will modify as suggested. >The last paragraph in section 5.4 starts with "NOTE" (which implementors >frequently read as non-normative) and then contains a normative statement. >Suggest removing "NOTE:" I will remove =B3NOTE:=B2. >Please expand the following acronyms upon first use and in the title; >see https://www.rfc-editor.org/materials/abbrev.expansion.txt for >guidance. > > - SDP - Session Description Protocol > - DTLS - Datagram Transport Layer Security > - TLS - Transport Layer Security > - ICE - Interactive Connectivity Establishment > - SCTP - Stream Control Transmission Protocol > - SRTP - Secure Realtime Transport Protocol > - UDPTL - UDP Transport Layer I=B9ll fix that. Thanks! Regards, Christer From nobody Wed Aug 23 03:02:53 2017 Return-Path: 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 BB203132BEC; Wed, 23 Aug 2017 03:02:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.221 X-Spam-Level: X-Spam-Status: No, score=-4.221 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=ham autolearn_force=no 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 IMlZRSDngn6v; Wed, 23 Aug 2017 03:02:43 -0700 (PDT) Received: from sesbmg23.ericsson.net (sesbmg23.ericsson.net [193.180.251.37]) (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 3785E132BE2; Wed, 23 Aug 2017 03:02:40 -0700 (PDT) X-AuditID: c1b4fb25-967ff70000005333-8f-599d52bffb1e Received: from ESESSHC022.ericsson.se (Unknown_Domain [153.88.183.84]) by sesbmg23.ericsson.net (Symantec Mail Security) with SMTP id 6E.B8.21299.FB25D995; Wed, 23 Aug 2017 12:02:39 +0200 (CEST) Received: from ESESSMB109.ericsson.se ([169.254.9.194]) by ESESSHC022.ericsson.se ([153.88.183.84]) with mapi id 14.03.0352.000; Wed, 23 Aug 2017 12:02:38 +0200 From: Christer Holmberg To: Roman Shpount , Eric Rescorla CC: The IESG , "draft-ietf-mmusic-dtls-sdp@ietf.org" , "mmusic-chairs@ietf.org" , lemming Andreasen , "mmusic@ietf.org" Thread-Topic: [MMUSIC] Eric Rescorla's Discuss on draft-ietf-mmusic-dtls-sdp-28: (with DISCUSS and COMMENT) Thread-Index: AQHTFiJ4U9eZ+Q1EiEiv1X0BiX5SzqKR04uA Date: Wed, 23 Aug 2017 10:02:37 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.7.4.170508 x-originating-ip: [153.88.183.18] Content-Type: text/plain; charset="iso-8859-1" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFjrIIsWRmVeSWpSXmKPExsUyM2J7iO7+oLmRBgvv8lr8nzif1WLF63Ps Fu8v6FrM+DOR2eL8zvVMFlOXP2axmHFhKrMDu8eU3xtZPZYs+cnkMflxG7PHrSkFASxRXDYp qTmZZalF+nYJXBkdtxuZCz6wVPye08nWwPiEuYuRk0NCwETi0fGtQDYXh5DAEUaJz3//sEM4 SxglDs08zdrFyMHBJmAh0f1PG6RBRMBZoqv3HitIDbPAe0aJfav3s4AkhAVyJK6cfMsGUZQr cXJ9DzOEbSSx4nAzmM0ioCrxuP04E4jNK2AtMXVXLzuILSQQILHh/FlWEJtTIFBi5+MjYHMY BcQkvp9aA1bPLCAucevJfCaIqwUkluw5D/WBqMTLx//A7hQV0JN4t98TIqwo8fHVPkaIVj2J G1OnsEHY1hJrV25jgbC1JZYtfM0McY6gxMmZT1gmMIrPQrJtFpL2WUjaZyFpn4WkfQEj6ypG 0eLU4qTcdCNjvdSizOTi4vw8vbzUkk2MwIg9uOW36g7Gy28cDzEKcDAq8fCWWMyNFGJNLCuu zD3EKMHBrCTCW+8PFOJNSaysSi3Kjy8qzUktPsQozcGiJM7ruO9ChJBAemJJanZqakFqEUyW iYNTqoGxTNjnVI/N72vC2+d5NQtEdFokLpbRkbV/JJ69PHI/1+Qt6/oD6xWWFqhPZVFL/CUl HbAuUWfOf7ejO2vPnWHSmXdKY5d1d88cppjD+zatFffd0iPvlqq2JsfvGUPaopPyN9fMXePS /4d555cdf8W/3bxz6rG6Sfv6iDR5w9rDKe7MnoxWIkpKLMUZiYZazEXFiQAJ3urX1AIAAA== Archived-At: Subject: Re: [MMUSIC] Eric Rescorla's Discuss on draft-ietf-mmusic-dtls-sdp-28: (with DISCUSS and COMMENT) X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 23 Aug 2017 10:02:46 -0000 Hi Ekr, Thanks for your comments! We=B9ll deal with the JSEP alignment issue separately, and Roman has addressed your other comments. A few additions from me below. >> S 10. >> Please do something about the "NEW" constructions. I literally had to >> pull these into ediff to know what had changed. That's not useful to >> people. I'm not a fan of this construction in general, but at minimum >> you need to explain what has changed. >> > This is the best we came up with so far. If you have a better option, >please suggest. We can add a few words about what has been changed. Regards, Christer From nobody Wed Aug 23 11:30:29 2017 Return-Path: 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 961EC132C58; Wed, 23 Aug 2017 11:30:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.88 X-Spam-Level: X-Spam-Status: No, score=-1.88 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, T_SPF_HELO_PERMERROR=0.01, T_SPF_PERMERROR=0.01] autolearn=ham autolearn_force=no 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 aaskFP9eSnW1; Wed, 23 Aug 2017 11:30:26 -0700 (PDT) Received: from nostrum.com (raven-v6.nostrum.com [IPv6:2001:470:d:1130::1]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B94AD132C5B; Wed, 23 Aug 2017 11:30:25 -0700 (PDT) Received: from Orochi.local (99-152-146-228.lightspeed.dllstx.sbcglobal.net [99.152.146.228]) (authenticated bits=0) by nostrum.com (8.15.2/8.15.2) with ESMTPSA id v7NIUGMP043182 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NO); Wed, 23 Aug 2017 13:30:17 -0500 (CDT) (envelope-from adam@nostrum.com) X-Authentication-Warning: raven.nostrum.com: Host 99-152-146-228.lightspeed.dllstx.sbcglobal.net [99.152.146.228] claimed to be Orochi.local To: Christer Holmberg , The IESG Cc: "draft-ietf-mmusic-dtls-sdp@ietf.org" , "mmusic-chairs@ietf.org" , "fandreas@cisco.com" , "mmusic@ietf.org" References: <150301038555.14103.1567567703984434290.idtracker@ietfa.amsl.com> From: Adam Roach Message-ID: Date: Wed, 23 Aug 2017 13:30:10 -0500 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:52.0) Gecko/20100101 Thunderbird/52.3.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Content-Language: en-US Archived-At: Subject: Re: [MMUSIC] Adam Roach's No Objection on draft-ietf-mmusic-dtls-sdp-28: (with COMMENT) X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 23 Aug 2017 18:30:29 -0000 On 8/23/17 04:38, Christer Holmberg wrote: > >> I would think the long-form title of this document should include "TLS," >> to >> reflect that it also contains TLS-related procedures. > The issue is that the document doesn¹t really define the O/A procedures > for TLS. It simply adds the usage of the tls-id attribute to the existing > procedures defined elsewhere. Right, so make that clear. I note that simply adding "and Identification of TLS Connections" to the end is ambiguous (since it makes it sound like it defines O/A for TLS), but you can fix this by reversing the existing title; e.g., something like: "Establishing Datagram Transport Layer Security (DTLS) Using the Session Description Protocol (SDP) Offer/Answer Mechanism and Identification of Transport Layer Security (TLS) Connections in SDP" /a From nobody Wed Aug 23 23:14:42 2017 Return-Path: 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 9966A13203D; Wed, 23 Aug 2017 23:14:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.221 X-Spam-Level: X-Spam-Status: No, score=-4.221 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=ham autolearn_force=no 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 OZqPnCL6t5vI; Wed, 23 Aug 2017 23:14:38 -0700 (PDT) Received: from sesbmg22.ericsson.net (sesbmg22.ericsson.net [193.180.251.48]) (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 B84C3126E64; Wed, 23 Aug 2017 23:14:37 -0700 (PDT) X-AuditID: c1b4fb30-96f7a9c000005897-5b-599e6ecb1202 Received: from ESESSHC012.ericsson.se (Unknown_Domain [153.88.183.54]) by sesbmg22.ericsson.net (Symantec Mail Security) with SMTP id A8.7D.22679.BCE6E995; Thu, 24 Aug 2017 08:14:35 +0200 (CEST) Received: from ESESSMB109.ericsson.se ([169.254.9.194]) by ESESSHC012.ericsson.se ([153.88.183.54]) with mapi id 14.03.0352.000; Thu, 24 Aug 2017 08:14:33 +0200 From: Christer Holmberg To: Adam Roach , The IESG CC: "draft-ietf-mmusic-dtls-sdp@ietf.org" , "mmusic-chairs@ietf.org" , "fandreas@cisco.com" , "mmusic@ietf.org" Thread-Topic: Adam Roach's No Objection on draft-ietf-mmusic-dtls-sdp-28: (with COMMENT) Thread-Index: AQHTF6uY+fnArxR5YU+2MrlLLf27GqKRybkAgABhHACAAPhCgA== Date: Thu, 24 Aug 2017 06:14:32 +0000 Message-ID: References: <150301038555.14103.1567567703984434290.idtracker@ietfa.amsl.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.7.4.170508 x-originating-ip: [153.88.183.19] Content-Type: text/plain; charset="euc-kr" Content-ID: <392876932E464D49A8E8B73DF4CA19BD@ericsson.com> Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFtrOIsWRmVeSWpSXmKPExsUyM2K7me7pvHmRBl+P2Fjs+buI3eL/xPms Fu8v6FrM+DOR2eL8zvVMFlOXP2ZxYPOY8nsjq8eSJT+ZPGbtfMISwBzFZZOSmpNZllqkb5fA lfH/v0BBF2fF4xn9rA2Mbzi6GDk5JARMJOa8uszYxcjFISRwhFHiUU8flLOEUeL2sybWLkYO DjYBC4nuf9ogDSIC1hKnm08yg9QwC9xglPgxeSYbSEJYIFLi5INWRoiiKIlnz+cwgvSKCDhJ LOmyBQmzCKhKPJk8hxXE5gWaM+HzXhaIXVsYJdZ3TQPr5RSwl5i36RITiM0oICbx/dQaMJtZ QFzi1pP5TBBXC0gs2XOeGcIWlXj5+B/YnaICehLv9ntChBUl2p82MEK0akl8+bGPDcK2ljhz ZQaUrSgxpfshO8Q9ghInZz5hmcAoPgvJtllI2mchaZ+FpH0WkvYFjKyrGEWLU4uTctONjPRS izKTi4vz8/TyUks2MQKj8+CW3wY7GF8+dzzEKMDBqMTDq5Y9L1KINbGsuDL3EKMEB7OSCO/V NKAQb0piZVVqUX58UWlOavEhRmkOFiVxXsd9FyKEBNITS1KzU1MLUotgskwcnFINjG6F1hJv FjBfUEuudOkT+j5tUa35rll/zlxuidjQe+9se97/75m/ZvT05Vxz/vNggWrvY8lSy581OWUW et9+7rIKmnKnjuV7yk6Tx2xbm/aGFi/9tWGT3NWbG7Tnu9eX8tzhXHMh+6GukBHbrNT/Xn/n eUyexDshxX3PxQfJ0ysZJmyaY9zZIqzEUpyRaKjFXFScCACFlKeZygIAAA== Archived-At: Subject: Re: [MMUSIC] Adam Roach's No Objection on draft-ietf-mmusic-dtls-sdp-28: (with COMMENT) X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 24 Aug 2017 06:14:40 -0000 SGksDQoNCj4+Pkkgd291bGQgdGhpbmsgdGhlIGxvbmctZm9ybSB0aXRsZSBvZiB0aGlzIGRvY3Vt ZW50IHNob3VsZCBpbmNsdWRlICJUTFMsIg0KPj4+IHRvDQo+Pj4gcmVmbGVjdCB0aGF0IGl0IGFs c28gY29udGFpbnMgVExTLXJlbGF0ZWQgcHJvY2VkdXJlcy4NCj4+IFRoZSBpc3N1ZSBpcyB0aGF0 IHRoZSBkb2N1bWVudCBkb2Vzbqn2dCByZWFsbHkgZGVmaW5lIHRoZSBPL0EgcHJvY2VkdXJlcw0K Pj4gZm9yIFRMUy4gSXQgc2ltcGx5IGFkZHMgdGhlIHVzYWdlIG9mIHRoZSB0bHMtaWQgYXR0cmli dXRlIHRvIHRoZQ0KPj5leGlzdGluZw0KPj4gcHJvY2VkdXJlcyBkZWZpbmVkIGVsc2V3aGVyZS4N Cj4NCj5SaWdodCwgc28gbWFrZSB0aGF0IGNsZWFyLiBJIG5vdGUgdGhhdCBzaW1wbHkgYWRkaW5n ICJhbmQgSWRlbnRpZmljYXRpb24NCj5vZiBUTFMgQ29ubmVjdGlvbnMiIHRvIHRoZSBlbmQgaXMg YW1iaWd1b3VzIChzaW5jZSBpdCBtYWtlcyBpdCBzb3VuZA0KPmxpa2UgaXQgZGVmaW5lcyBPL0Eg Zm9yIFRMUyksIGJ1dCB5b3UgY2FuIGZpeCB0aGlzIGJ5IHJldmVyc2luZyB0aGUNCj5leGlzdGlu ZyB0aXRsZTsgZS5nLiwgc29tZXRoaW5nIGxpa2U6ICJFc3RhYmxpc2hpbmcgRGF0YWdyYW0gVHJh bnNwb3J0DQo+TGF5ZXIgU2VjdXJpdHkgKERUTFMpIFVzaW5nIHRoZSBTZXNzaW9uIERlc2NyaXB0 aW9uIFByb3RvY29sIChTRFApDQo+T2ZmZXIvQW5zd2VyIE1lY2hhbmlzbSBhbmQgSWRlbnRpZmlj YXRpb24gb2YgVHJhbnNwb3J0IExheWVyIFNlY3VyaXR5DQo+KFRMUykgQ29ubmVjdGlvbnMgaW4g U0RQIg0KDQpXb3JrcyBmb3IgbWUuDQoNClJlZ2FyZHMsDQoNCkNocmlzdGVyDQoNCg== From nobody Thu Aug 24 00:57:25 2017 Return-Path: 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 1DCFF132C19; Thu, 24 Aug 2017 00:57:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.221 X-Spam-Level: X-Spam-Status: No, score=-4.221 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=ham autolearn_force=no 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 2SWEmI0eGhR6; Thu, 24 Aug 2017 00:57:21 -0700 (PDT) Received: from sesbmg23.ericsson.net (sesbmg23.ericsson.net [193.180.251.37]) (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 31D441321ED; Thu, 24 Aug 2017 00:57:19 -0700 (PDT) X-AuditID: c1b4fb25-967ff70000005333-8f-599e86dd6549 Received: from ESESSHC011.ericsson.se (Unknown_Domain [153.88.183.51]) by sesbmg23.ericsson.net (Symantec Mail Security) with SMTP id BB.10.21299.DD68E995; Thu, 24 Aug 2017 09:57:18 +0200 (CEST) Received: from ESESSMB109.ericsson.se ([169.254.9.194]) by ESESSHC011.ericsson.se ([153.88.183.51]) with mapi id 14.03.0352.000; Thu, 24 Aug 2017 09:57:17 +0200 From: Christer Holmberg To: Adam Roach , The IESG , Eric Rescorla CC: "draft-ietf-mmusic-dtls-sdp@ietf.org" , "mmusic-chairs@ietf.org" , "fandreas@cisco.com" , "mmusic@ietf.org" Thread-Topic: Adam Roach's No Objection on draft-ietf-mmusic-dtls-sdp-28: (with COMMENT) - PULL REQUEST Thread-Index: AQHTHK6aKje8VlpvCEK0oVdpesEGKA== Date: Thu, 24 Aug 2017 07:57:17 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.7.4.170508 x-originating-ip: [153.88.183.147] Content-Type: text/plain; charset="us-ascii" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFlrOIsWRmVeSWpSXmKPExsUyM2K7se69tnmRBlNnc1rs+buI3eL/xPms Fiten2O3eH9B12LGn4nMFud3rmeymLr8MYsDu8eU3xtZPZYs+cnkMWvnExaPyY/bmANYorhs UlJzMstSi/TtErgyjl/Zylwwn7Fiz4uH7A2MNV2MHBwSAiYSr95HdzFycQgJHGGUaHzRwQ7h LGGUOHPoDTtIEZuAhUT3P+0uRk4OEYFoiac7njGB1DAL3GCU+DF5JhtIQlggQ2LflX52iKJM iYZrm1ghbD2JHau2gtksAqoST/ZfBKvhFbCW6LuxgBHEZhQQk/h+ag0TiM0sIC5x68l8MFtC QEBiyZ7zzBC2qMTLx/9YQe4RBZr5br8nxP1KEtO2pkF06kgs2P2JDcK2llj6eS7URG2JZQtf M0NsFZQ4OfMJywRG0VlIls1C0j4LSfssJO2zkLQvYGRdxShanFqclJtuZKyXWpSZXFycn6eX l1qyiREYfQe3/FbdwXj5jeMhRgEORiUe3sfZ8yKFWBPLiitzDzFKcDArifCGVQCFeFMSK6tS i/Lji0pzUosPMUpzsCiJ8zruuxAhJJCeWJKanZpakFoEk2Xi4JRqYJQInhHk+EDpruaJfxvi IyIytHNyF17aZZrd+/6G6IG7Pb3vOldn2N9eMPn5nhDO9f1/HQNktORksxWm5U0Q+fuy/IOl 0feLj8oubJD0ErzZ9e5t1HSOPXpTTHbsT6s/1b3qUmqX+XeJlz9eRK4KY1G7+8bhxC3VrZyn 6p7NmfRl6WLvGq5bhxWUWIozEg21mIuKEwH8b0gJugIAAA== Archived-At: Subject: Re: [MMUSIC] Adam Roach's No Objection on draft-ietf-mmusic-dtls-sdp-28: (with COMMENT) - PULL REQUEST X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 24 Aug 2017 07:57:23 -0000 Hi, Based on the COMMENTs from Adam and Ekr, I have created a pull request: https://github.com/cdh4u/draft-dtls-sdp/pull/35 Regards, Christer From nobody Thu Aug 24 10:48:28 2017 Return-Path: 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 5BD94124B18; Thu, 24 Aug 2017 10:48:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.88 X-Spam-Level: X-Spam-Status: No, score=-1.88 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, T_SPF_HELO_PERMERROR=0.01, T_SPF_PERMERROR=0.01] autolearn=unavailable autolearn_force=no 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 xQQHi0hoXaEQ; Thu, 24 Aug 2017 10:48:21 -0700 (PDT) Received: from nostrum.com (raven-v6.nostrum.com [IPv6:2001:470:d:1130::1]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E9383120721; Thu, 24 Aug 2017 10:48:15 -0700 (PDT) Received: from [10.0.1.63] (cpe-66-25-7-22.tx.res.rr.com [66.25.7.22]) (authenticated bits=0) by nostrum.com (8.15.2/8.15.2) with ESMTPSA id v7OHm51x085040 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NO); Thu, 24 Aug 2017 12:48:06 -0500 (CDT) (envelope-from ben@nostrum.com) X-Authentication-Warning: raven.nostrum.com: Host cpe-66-25-7-22.tx.res.rr.com [66.25.7.22] claimed to be [10.0.1.63] Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) From: Ben Campbell In-Reply-To: Date: Thu, 24 Aug 2017 12:48:05 -0500 Cc: Christer Holmberg , The IESG , "draft-ietf-mmusic-dtls-sdp@ietf.org" , "mmusic-chairs@ietf.org" , Flemming Andreasen , "mmusic@ietf.org" Content-Transfer-Encoding: quoted-printable Message-Id: <8EB6BD4A-26A9-4F98-A57A-FCCFC3F6AC97@nostrum.com> References: <150301038555.14103.1567567703984434290.idtracker@ietfa.amsl.com> To: Adam Roach X-Mailer: Apple Mail (2.3273) Archived-At: Subject: Re: [MMUSIC] Adam Roach's No Objection on draft-ietf-mmusic-dtls-sdp-28: (with COMMENT) X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 24 Aug 2017 17:48:22 -0000 > On Aug 23, 2017, at 1:30 PM, Adam Roach wrote: >=20 > On 8/23/17 04:38, Christer Holmberg wrote: >>=20 >>> I would think the long-form title of this document should include = "TLS," >>> to >>> reflect that it also contains TLS-related procedures. >> The issue is that the document doesn=C2=B9t really define the O/A = procedures >> for TLS. It simply adds the usage of the tls-id attribute to the = existing >> procedures defined elsewhere. >=20 > Right, so make that clear. I note that simply adding "and = Identification of TLS Connections" to the end is ambiguous (since it = makes it sound like it defines O/A for TLS), but you can fix this by = reversing the existing title; e.g., something like: "Establishing = Datagram Transport Layer Security (DTLS) Using the Session Description = Protocol (SDP) Offer/Answer Mechanism and Identification of Transport = Layer Security (TLS) Connections in SDP=E2=80=9D Wow, that=E2=80=99s petty cumbersome as a title=E2=80=94it=E2=80=99s = pretty much an abstract. Does it need that much detail? From nobody Thu Aug 24 10:52:49 2017 Return-Path: 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 1CF7B132113 for ; Thu, 24 Aug 2017 10:52:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.88 X-Spam-Level: X-Spam-Status: No, score=-1.88 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, T_SPF_HELO_PERMERROR=0.01, T_SPF_PERMERROR=0.01] autolearn=ham autolearn_force=no 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 rYs-qFf3h-op for ; Thu, 24 Aug 2017 10:52:46 -0700 (PDT) Received: from nostrum.com (raven-v6.nostrum.com [IPv6:2001:470:d:1130::1]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 971FD120721 for ; Thu, 24 Aug 2017 10:52:46 -0700 (PDT) Received: from Orochi.local (99-152-146-228.lightspeed.dllstx.sbcglobal.net [99.152.146.228]) (authenticated bits=0) by nostrum.com (8.15.2/8.15.2) with ESMTPSA id v7OHqi7O085900 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NO); Thu, 24 Aug 2017 12:52:45 -0500 (CDT) (envelope-from adam@nostrum.com) X-Authentication-Warning: raven.nostrum.com: Host 99-152-146-228.lightspeed.dllstx.sbcglobal.net [99.152.146.228] claimed to be Orochi.local To: Ben Campbell Cc: Christer Holmberg , The IESG , "draft-ietf-mmusic-dtls-sdp@ietf.org" , "mmusic-chairs@ietf.org" , Flemming Andreasen , "mmusic@ietf.org" References: <150301038555.14103.1567567703984434290.idtracker@ietfa.amsl.com> <8EB6BD4A-26A9-4F98-A57A-FCCFC3F6AC97@nostrum.com> From: Adam Roach Message-ID: <9cdb8f3b-eb9b-f478-ecb0-2095cdba2484@nostrum.com> Date: Thu, 24 Aug 2017 12:52:38 -0500 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:52.0) Gecko/20100101 Thunderbird/52.3.0 MIME-Version: 1.0 In-Reply-To: <8EB6BD4A-26A9-4F98-A57A-FCCFC3F6AC97@nostrum.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Content-Language: en-US Archived-At: Subject: Re: [MMUSIC] Adam Roach's No Objection on draft-ietf-mmusic-dtls-sdp-28: (with COMMENT) X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 24 Aug 2017 17:52:48 -0000 On 8/24/17 12:48, Ben Campbell wrote: >> On Aug 23, 2017, at 1:30 PM, Adam Roach wrote: >> >> On 8/23/17 04:38, Christer Holmberg wrote: >>>> I would think the long-form title of this document should include "TLS," >>>> to >>>> reflect that it also contains TLS-related procedures. >>> The issue is that the document doesn¹t really define the O/A procedures >>> for TLS. It simply adds the usage of the tls-id attribute to the existing >>> procedures defined elsewhere. >> Right, so make that clear. I note that simply adding "and Identification of TLS Connections" to the end is ambiguous (since it makes it sound like it defines O/A for TLS), but you can fix this by reversing the existing title; e.g., something like: "Establishing Datagram Transport Layer Security (DTLS) Using the Session Description Protocol (SDP) Offer/Answer Mechanism and Identification of Transport Layer Security (TLS) Connections in SDP” > Wow, that’s petty cumbersome as a title—it’s pretty much an abstract. Does it need that much detail? > It's the result of taking a reasonably short title ("Establishing DLTS using the SDP Offer/Answer Mechanism and Identification of TLS Connections in SDP") and applying RFC Editor policies of acronym expansion to it. If you can think of some shorter way to say it, that'd be great -- but if I'm perusing a list of titles for something TLS-related and come across one that mentions only DTLS, I'd skip over it. The original title seems like a genuine flaw. /a From nobody Thu Aug 24 11:02:50 2017 Return-Path: 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 D368E13202D; Thu, 24 Aug 2017 11:02:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.88 X-Spam-Level: X-Spam-Status: No, score=-1.88 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, T_SPF_HELO_PERMERROR=0.01, T_SPF_PERMERROR=0.01] autolearn=unavailable autolearn_force=no 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 GO4KlZKmYaDd; Thu, 24 Aug 2017 11:02:47 -0700 (PDT) Received: from nostrum.com (raven-v6.nostrum.com [IPv6:2001:470:d:1130::1]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A1DE1132113; Thu, 24 Aug 2017 11:02:47 -0700 (PDT) Received: from [10.0.1.63] (cpe-66-25-7-22.tx.res.rr.com [66.25.7.22]) (authenticated bits=0) by nostrum.com (8.15.2/8.15.2) with ESMTPSA id v7OI2gHx087666 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NO); Thu, 24 Aug 2017 13:02:42 -0500 (CDT) (envelope-from ben@nostrum.com) X-Authentication-Warning: raven.nostrum.com: Host cpe-66-25-7-22.tx.res.rr.com [66.25.7.22] claimed to be [10.0.1.63] Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) From: Ben Campbell In-Reply-To: <9cdb8f3b-eb9b-f478-ecb0-2095cdba2484@nostrum.com> Date: Thu, 24 Aug 2017 13:02:41 -0500 Cc: "draft-ietf-mmusic-dtls-sdp@ietf.org" , "mmusic-chairs@ietf.org" , "mmusic@ietf.org" , Flemming Andreasen , The IESG , Christer Holmberg Content-Transfer-Encoding: quoted-printable Message-Id: <83BCB0B5-0F74-43A2-9EF1-1D04EF4F9A0E@nostrum.com> References: <150301038555.14103.1567567703984434290.idtracker@ietfa.amsl.com> <8EB6BD4A-26A9-4F98-A57A-FCCFC3F6AC97@nostrum.com> <9cdb8f3b-eb9b-f478-ecb0-2095cdba2484@nostrum.com> To: Adam Roach X-Mailer: Apple Mail (2.3273) Archived-At: Subject: Re: [MMUSIC] Adam Roach's No Objection on draft-ietf-mmusic-dtls-sdp-28: (with COMMENT) X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 24 Aug 2017 18:02:49 -0000 > On Aug 24, 2017, at 12:52 PM, Adam Roach wrote: >=20 > On 8/24/17 12:48, Ben Campbell wrote: >>> On Aug 23, 2017, at 1:30 PM, Adam Roach wrote: >>>=20 >>> On 8/23/17 04:38, Christer Holmberg wrote: >>>>> I would think the long-form title of this document should include = "TLS," >>>>> to >>>>> reflect that it also contains TLS-related procedures. >>>> The issue is that the document doesn=C2=B9t really define the O/A = procedures >>>> for TLS. It simply adds the usage of the tls-id attribute to the = existing >>>> procedures defined elsewhere. >>> Right, so make that clear. I note that simply adding "and = Identification of TLS Connections" to the end is ambiguous (since it = makes it sound like it defines O/A for TLS), but you can fix this by = reversing the existing title; e.g., something like: "Establishing = Datagram Transport Layer Security (DTLS) Using the Session Description = Protocol (SDP) Offer/Answer Mechanism and Identification of Transport = Layer Security (TLS) Connections in SDP=E2=80=9D >> Wow, that=E2=80=99s petty cumbersome as a title=E2=80=94it=E2=80=99s = pretty much an abstract. Does it need that much detail? >>=20 >=20 > It's the result of taking a reasonably short title ("Establishing DLTS = using the SDP Offer/Answer Mechanism and Identification of TLS = Connections in SDP") and applying RFC Editor policies of acronym = expansion to it. If you can think of some shorter way to say it, that'd = be great -- but if I'm perusing a list of titles for something = TLS-related and come across one that mentions only DTLS, I'd skip over = it. The original title seems like a genuine flaw. Here=E2=80=99s a sacrificial proposal from the _much_ more general side: = =20 =E2=80=9CDTLS and TLS considerations in the SDP Offer/Answer = Mechanism=E2=80=9D=20 =E2=80=A6 with appropriate acronym expansions of course. That may be too = expansive, but we do have the abstract to narrow the focus. Some = alternatives: =20 =E2=80=9CDTLS and TLS Session Management in the SDP Offer/Answer = Mechanism=E2=80=9D=20 =E2=80=9CDTLS and TLS Security Association Management in the SDP = Offer/Answer Mechanism=E2=80=9D=20 Ben.= From nobody Thu Aug 24 11:53:24 2017 Return-Path: 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 603FA13213F; Thu, 24 Aug 2017 11:53:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.88 X-Spam-Level: X-Spam-Status: No, score=-1.88 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, T_SPF_HELO_PERMERROR=0.01, T_SPF_PERMERROR=0.01] autolearn=unavailable autolearn_force=no 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 7jwZKL_EHgo7; Thu, 24 Aug 2017 11:53:16 -0700 (PDT) Received: from nostrum.com (raven-v6.nostrum.com [IPv6:2001:470:d:1130::1]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 798381320CF; Thu, 24 Aug 2017 11:53:16 -0700 (PDT) Received: from Orochi.local (99-152-146-228.lightspeed.dllstx.sbcglobal.net [99.152.146.228]) (authenticated bits=0) by nostrum.com (8.15.2/8.15.2) with ESMTPSA id v7OIr9Af096294 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NO); Thu, 24 Aug 2017 13:53:10 -0500 (CDT) (envelope-from adam@nostrum.com) X-Authentication-Warning: raven.nostrum.com: Host 99-152-146-228.lightspeed.dllstx.sbcglobal.net [99.152.146.228] claimed to be Orochi.local To: Ben Campbell Cc: "draft-ietf-mmusic-dtls-sdp@ietf.org" , "mmusic-chairs@ietf.org" , "mmusic@ietf.org" , Flemming Andreasen , The IESG , Christer Holmberg References: <150301038555.14103.1567567703984434290.idtracker@ietfa.amsl.com> <8EB6BD4A-26A9-4F98-A57A-FCCFC3F6AC97@nostrum.com> <9cdb8f3b-eb9b-f478-ecb0-2095cdba2484@nostrum.com> <83BCB0B5-0F74-43A2-9EF1-1D04EF4F9A0E@nostrum.com> From: Adam Roach Message-ID: Date: Thu, 24 Aug 2017 13:53:03 -0500 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:52.0) Gecko/20100101 Thunderbird/52.3.0 MIME-Version: 1.0 In-Reply-To: <83BCB0B5-0F74-43A2-9EF1-1D04EF4F9A0E@nostrum.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Content-Language: en-US Archived-At: Subject: Re: [MMUSIC] Adam Roach's No Objection on draft-ietf-mmusic-dtls-sdp-28: (with COMMENT) X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 24 Aug 2017 18:53:17 -0000 On 8/24/17 13:02, Ben Campbell wrote: >> On Aug 24, 2017, at 12:52 PM, Adam Roach wrote: >> >> On 8/24/17 12:48, Ben Campbell wrote: >>>> On Aug 23, 2017, at 1:30 PM, Adam Roach wrote: >>>> >>>> On 8/23/17 04:38, Christer Holmberg wrote: >>>>>> I would think the long-form title of this document should include "TLS," >>>>>> to >>>>>> reflect that it also contains TLS-related procedures. >>>>> The issue is that the document doesn¹t really define the O/A procedures >>>>> for TLS. It simply adds the usage of the tls-id attribute to the existing >>>>> procedures defined elsewhere. >>>> Right, so make that clear. I note that simply adding "and Identification of TLS Connections" to the end is ambiguous (since it makes it sound like it defines O/A for TLS), but you can fix this by reversing the existing title; e.g., something like: "Establishing Datagram Transport Layer Security (DTLS) Using the Session Description Protocol (SDP) Offer/Answer Mechanism and Identification of Transport Layer Security (TLS) Connections in SDP” >>> Wow, that’s petty cumbersome as a title—it’s pretty much an abstract. Does it need that much detail? >>> >> It's the result of taking a reasonably short title ("Establishing DLTS using the SDP Offer/Answer Mechanism and Identification of TLS Connections in SDP") and applying RFC Editor policies of acronym expansion to it. If you can think of some shorter way to say it, that'd be great -- but if I'm perusing a list of titles for something TLS-related and come across one that mentions only DTLS, I'd skip over it. The original title seems like a genuine flaw. > Here’s a sacrificial proposal from the _much_ more general side: > > “DTLS and TLS considerations in the SDP Offer/Answer Mechanism” > > … with appropriate acronym expansions of course. I have no problem with that. /a From nobody Fri Aug 25 01:45:53 2017 Return-Path: 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 96F101320DC for ; Fri, 25 Aug 2017 01:45:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.22 X-Spam-Level: X-Spam-Status: No, score=-4.22 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no 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 94Y5UWt7BFs8 for ; Fri, 25 Aug 2017 01:45:49 -0700 (PDT) Received: from sesbmg23.ericsson.net (sesbmg23.ericsson.net [193.180.251.37]) (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 13E0F120720 for ; Fri, 25 Aug 2017 01:45:48 -0700 (PDT) X-AuditID: c1b4fb25-94fff70000005333-c1-599fe3bbbc54 Received: from ESESSHC003.ericsson.se (Unknown_Domain [153.88.183.27]) by sesbmg23.ericsson.net (Symantec Mail Security) with SMTP id DE.F3.21299.BB3EF995; Fri, 25 Aug 2017 10:45:47 +0200 (CEST) Received: from [147.214.160.108] (153.88.183.153) by smtps.internal.ericsson.com (153.88.183.27) with Microsoft SMTP Server (TLS) id 14.3.352.0; Fri, 25 Aug 2017 10:45:46 +0200 To: , , , , , CC: , References: <20170808165231.7B757B80E45@rfc-editor.org> From: Magnus Westerlund Message-ID: <195f8cfb-9ee4-a13d-3703-cc51844899cd@ericsson.com> Date: Fri, 25 Aug 2017 10:45:29 +0200 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.3.0 MIME-Version: 1.0 In-Reply-To: <20170808165231.7B757B80E45@rfc-editor.org> Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha-256; boundary="------------ms020806010700040807070800" X-Originating-IP: [153.88.183.153] X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFtrOIsWRmVeSWpSXmKPExsUyM2K7tO7ux/MjDT7s4bPY//4Qk8Wev4vY LeZ3nma3eH9B12Lq8scsFq97TzJbXPqn4sDuMeX3RlaPr7cOMnnsPHWAzWPnrLvsHkuW/GTy mLXzCUsAWxSXTUpqTmZZapG+XQJXxqQXC5gL7npU7N96m6mBcYFjFyMnh4SAicSL5T+Yuhi5 OIQEjjBKHJg6lRHC2cIoseP/EnaQKmEBB4lpEy4ygyREBKYxSqyY9pUNJMEsoC3RtWcdC4gt JGAucfPcAlYQm03AQuLmj0awGl4Be4kfHQfABrEIqEocnDkBzBYViJH4eekRC0SNoMTJmU/A bE6g3iX7joCdxCzQzShx/9AsJogF2hINTR2sEHcrSVyfd51lAqPALCT9s5D1zAI70Fbiztzd zLOgjl228DWULS7R9GUlK4RtLTHj10E2CFtRYkr3Q3YI21Ti9dGPjBC2kcS7PY3sCxg5VzGK FqcWJ+WmGxnrpRZlJhcX5+fp5aWWbGIERuHBLb9VdzBefuN4iFGAg1GJh9fl+PxIIdbEsuLK 3EOMKkBzHm1YfYFRiiUvPy9VSYQ31RQozZuSWFmVWpQfX1Sak1p8iFGag0VJnNdx34UIIYH0 xJLU7NTUgtQimCwTB6dUA2OapUHIxFcrfk1k23231UX9RcY1J7sr+UUfF74PSM/k3dsps2BN iHTdvlneIVHnsov/HuGwzT9gLd9w8exj+aBe22uNf7fGvrprJnXycOGm/ZvskvXV3vm0Zrto H6q3MH8zr2XioZQtF+r5YwsbjzZnttmLbbiesrO2rks1uC3K54Cb3m6vSCWW4oxEQy3mouJE AO5Y+9TKAgAA Archived-At: Subject: Re: [MMUSIC] [Technical Errata Reported] RFC2326 (5079) X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 25 Aug 2017 08:45:51 -0000 --------------ms020806010700040807070800 Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: quoted-printable Content-Language: en-GB Hi, Thanks for reporting, however considering how many issues there are in=20 RFC 2326, and why RFC 7826 was produced, I frankly don't know if its=20 worth accepting this errata or not. The errata is clearly right in that the RFC is wrong. If one follows the = format for text/parameters defined in RTSP 2.0:=20 https://datatracker.ietf.org/doc/rfc7826/ then there should be CRLF at=20 the end of each line, and there are no EOF marker. Thus the length=20 should be: 26. So maybe with that edit it is simplest to accept it. Cheers Magnus Westerlund Den 2017-08-08 kl. 18:52, skrev RFC Errata System: > The following errata report has been submitted for RFC2326, > "Real Time Streaming Protocol (RTSP)". > > -------------------------------------- > You may review the report below and at: > http://www.rfc-editor.org/errata/eid5079 > > -------------------------------------- > Type: Technical > Reported by: Vadim Zhukov > > Section: 10.8 > > Original Text > ------------- > S->C: GET_PARAMETER rtsp://example.com/fizzle/foo RTSP/1.0 > CSeq: 431 > Content-Type: text/parameters > Session: 12345678 > Content-Length: 15 > > packets_received > jitter > > Corrected Text > -------------- > S->C: GET_PARAMETER rtsp://example.com/fizzle/foo RTSP/1.0 > CSeq: 431 > Content-Type: text/parameters > Session: 12345678 > Content-Length: 24 > > packets_received > jitter > > Notes > ----- > The Content-Length value is wrong, it should be either 24 (as proposed)= or 26, depending on end-of-line marker used for message content. > > Instructions: > ------------- > This erratum is currently posted as "Reported". If necessary, please > use "Reply All" to discuss whether it should be verified or > rejected. When a decision is reached, the verifying party > can log in to change the status and edit the report, if necessary. > > -------------------------------------- > RFC2326 (no draft string recorded) > -------------------------------------- > Title : Real Time Streaming Protocol (RTSP) > Publication Date : April 1998 > Author(s) : H. Schulzrinne, A. Rao, R. Lanphier > Category : PROPOSED STANDARD > Source : Multiparty Multimedia Session Control RAI > Area : Real-time Applications and Infrastructure > Stream : IETF > Verifying Party : IESG > > _______________________________________________ > mmusic mailing list > mmusic@ietf.org > https://www.ietf.org/mailman/listinfo/mmusic --=20 Magnus Westerlund ---------------------------------------------------------------------- Media Technologies, Ericsson Research ---------------------------------------------------------------------- Ericsson AB | Phone +46 10 7148287 Torshamnsgatan 23 | Mobile +46 73 0949079 SE-164 80 Stockholm, Sweden | mailto: magnus.westerlund@ericsson.com ---------------------------------------------------------------------- --------------ms020806010700040807070800 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME-kryptografisk signatur MIAGCSqGSIb3DQEHAqCAMIACAQExDzANBglghkgBZQMEAgEFADCABgkqhkiG9w0BBwEAAKCC DLkwggX7MIID46ADAgECAhEA75oIXW3eBHJH2u7brn5gnDANBgkqhkiG9w0BAQUFADA6MREw DwYDVQQKDAhFcmljc3NvbjElMCMGA1UEAwwcRXJpY3Nzb24gTkwgSW5kaXZpZHVhbCBDQSB2 MjAeFw0xNTAxMjMwODUwNTdaFw0xODAxMjMwODUwNTdaMHAxETAPBgNVBAoMCEVyaWNzc29u MRowGAYDVQQDDBFNYWdudXMgV2VzdGVybHVuZDEtMCsGCSqGSIb3DQEJARYebWFnbnVzLndl c3Rlcmx1bmRAZXJpY3Nzb24uY29tMRAwDgYDVQQFEwdlcmFtc3dkMIIBIjANBgkqhkiG9w0B AQEFAAOCAQ8AMIIBCgKCAQEAkULrp/ViIWFfDbY2Ycew0bXJc2In2WNQbPORLyFXNpRhjhmg ot5P/0w90T4HY0H6QayjIPK6qIGt1DBXwkq/QHoRsFZiDK9JDnk2WUDcqbJaHqMXvkhj4Jl4 KvonZ31T3NF/8OlcEjumVc8AUA6iccOeUva3TvL/EOqY3f4bsem4ER3KAcY/lTPWivSY+/Aw vS64JjaANOHVhZ0LUj10JTe9CpdXB+1nMpqLFYkjse/2ahQuKyaBKhKJs35pSYijh3Ln+vMv YUNEna2LjHvkCPVo5Oihylxjmd1OSDXND7125tgo/kB08RtaJ9u6PNw0CoUgA+d23UzVzlYg aSJbhwIDAQABo4IBxDCCAcAwSAYDVR0fBEEwPzA9oDugOYY3aHR0cDovL2NybC50cnVzdC50 ZWxpYS5jb20vZXJpY3Nzb25ubGluZGl2aWR1YWxjYXYyLmNybDCBggYIKwYBBQUHAQEEdjB0 MCgGCCsGAQUFBzABhhxodHRwOi8vb2NzcDIudHJ1c3QudGVsaWEuY29tMEgGCCsGAQUFBzAC hjxodHRwOi8vY2EudHJ1c3QudGVsaWFzb25lcmEuY29tL2VyaWNzc29ubmxpbmRpdmlkdWFs Y2F2Mi5jZXIwKQYDVR0RBCIwIIEebWFnbnVzLndlc3Rlcmx1bmRAZXJpY3Nzb24uY29tMFUG A1UdIAROMEwwSgYMKwYBBAGCDwIDAQESMDowOAYIKwYBBQUHAgEWLGh0dHBzOi8vcmVwb3Np dG9yeS50cnVzdC50ZWxpYXNvbmVyYS5jb20vQ1BTMB0GA1UdJQQWMBQGCCsGAQUFBwMEBggr BgEFBQcDAjAdBgNVHQ4EFgQUwff+Y5pMEPJX7xortCv8deSKeQEwHwYDVR0jBBgwFoAUsQ3K 1Ea3r4YCwy9vBsoOdnF/SzcwDgYDVR0PAQH/BAQDAgWgMA0GCSqGSIb3DQEBBQUAA4ICAQBy rk0JhGgu9Fd/0Fg1cMhSa882HMQZWQLT1V4PFQpU6t2an8xaqT5JsxOpuxb+WxwpKG+UDbzQ cWgcb/DPW3Mc0AvhTFII1qAYf6Smkq6SOD/8TACjH+dy7JrbcNYJcTlVNBlC/V/C+waICkER wuMC/8QjXs0ExJekAD3i/3GUok9WnvEHsohIL04qk1lbvJN4WGHCHFercX11Ch+UjStHwtyw zyFWi64CqD48kKqPwEne3Lj7ozxzuwCCaJI9fmCQgLfSL+UcDgEb7cQucMAnB/Zxlz6U6ohd PRlQHaLevAYD2UK+BlhZKLAv/DNUz0nk6fx4CiJF5DIRteUdzGoeGcnWMWO9hv5PkEJC1WkZ gYXZ/91HMUjsYUuy5/EsmkqvkCalRudoqe6Pex3A34iFGNvDhI3fCrbvmRS4FARPse5D8BLu e/PIvAPNUC7xl8UcfnTNVgy5ITzWNiY9hIrbAzfPbTXyZSIdMD+HTNg33ziMbu2Iry/2eS1X /whXkApnQNpHplvzf1xMEeNPlDKtL8OOg+9y4ESdn27EKxeeaaFXsrhb3z1woIjQxXINft5W EPXWnks/YBCvrLTH8kRCLZgH17zDxb+MLqKj1XUQtBKgDhb+VswJM6GF+dDeBJoEYjvLR1Sx l5yfaRj0F7HYkjRUwyehwSHgTVqtgnT9QjCCBrYwggSeoAMCAQICEQCgDMvMm5mY7OI6cPR8 wcBZMA0GCSqGSIb3DQEBBQUAMDcxFDASBgNVBAoMC1RlbGlhU29uZXJhMR8wHQYDVQQDDBZU ZWxpYVNvbmVyYSBSb290IENBIHYxMB4XDTE0MDUyNzA3NDYyMVoXDTI0MDUyNzA3NDYyMVow OjERMA8GA1UECgwIRXJpY3Nzb24xJTAjBgNVBAMMHEVyaWNzc29uIE5MIEluZGl2aWR1YWwg Q0EgdjIwggIiMA0GCSqGSIb3DQEBAQUAA4ICDwAwggIKAoICAQDaulPrX0iWU5+JOOqjddx4 Gnl17DJhklkoXOgOSBMhW6FzGVt5RR7KPv+rjt2YpbwdoqWSYa4VPkS/72vuQoWsvz2avWWX hPTdNzrB3zs5cJO7sKIyd+LRy4l/8kKK4iPm+Q18XyGF0xTuc5WS3WiMScJSxEKdIOP8xehB raHZabrGh9OxQHC4iBHkzD0YF3J/vBqBTr7blRzYf1h3j5a7qVIHCPfz+eCE175mResXDQRI 7LvMiZtVaqitBl0oAJiJyeBmvEujBNsIEgUQ6JcQFG5ny0EazLywv7clwb7izvLgoXc6SFrd 0D7TGJtkdldVJtMwDYXpyFMGAijT6uf8h2kuPIwrDgQFNEyIQZ4q52ZpRGwugC6sMxgHEDGj A/CxX9aC5Vi1EMRJiOGF6gV3T+V5yHDHSBBeQbVAXm8wSTDBfXQwdro/AXqET0mG6Rpe4q2F GBaauE8qHEO6qR3WAEgvjVfFU2k6xZx1qmvwhkXadxh6ZIMXzgb6WpjivLnR0GEKNrgN2DXd vo+6eAt45Bhvmeka2TrJDxMLWiBy8QYgNeNXYQsuREnDsjWo6wF0LqbA5769om9nn/uJzmzx b3nT1iHue5co9J93ta06kxiASHvcIzZwAOjKnmk0vR3IT7Qbzq2of3E1s18xo8DM9D91Cak0 Nq+RALtdv1uZKQIDAQABo4IBuDCCAbQwgYoGCCsGAQUFBwEBBH4wfDAtBggrBgEFBQcwAYYh aHR0cDovL29jc3AudHJ1c3QudGVsaWFzb25lcmEuY29tMEsGCCsGAQUFBzAChj9odHRwOi8v cmVwb3NpdG9yeS50cnVzdC50ZWxpYXNvbmVyYS5jb20vdGVsaWFzb25lcmFyb290Y2F2MS5j ZXIwEgYDVR0TAQH/BAgwBgEB/wIBADBVBgNVHSAETjBMMEoGDCsGAQQBgg8CAwEBAjA6MDgG CCsGAQUFBwIBFixodHRwczovL3JlcG9zaXRvcnkudHJ1c3QudGVsaWFzb25lcmEuY29tL0NQ UzBLBgNVHR8ERDBCMECgPqA8hjpodHRwOi8vY3JsLTMudHJ1c3QudGVsaWFzb25lcmEuY29t L3RlbGlhc29uZXJhcm9vdGNhdjEuY3JsMB0GA1UdJQQWMBQGCCsGAQUFBwMCBggrBgEFBQcD BDAOBgNVHQ8BAf8EBAMCAQYwHQYDVR0OBBYEFLENytRGt6+GAsMvbwbKDnZxf0s3MB8GA1Ud IwQYMBaAFPCPWTgAs/WPmpYM1ev6e6oX6BMSMA0GCSqGSIb3DQEBBQUAA4ICAQBuByBsr6x3 PZBCsmGbcSZ/XL+0tnVMblInoJgL1Bh3PiRicgdo8l+6cvWp/ArBwMYNwSNyrvY9IewyaV8n 65c5oN+l2JDUuzrdANVKnYxha7ZyCEiPmY98sB2bnZgxfJLXQYoRwI7pOOwfyoP2fCYVCd+x hsfysYiIl4ORzE3TpeppQ2yWkyBBmoHUXJh97ue6+bJ2fqnVUoOVMVnYYEtvsz67v7w2z3fv dcy04/RnoylxSenxADi1tY9iIydHMgyOu3dfzsxU8AivMGG4aKStsCfUEyg0LlkbhqMrdnes s3e1qAEueSRNASLfpFwyRmzmiuNh9onzuhER2yYhK/6IeCs4HQHrPhkY8JUmhtmdL2uErOZW Os38FQhGWHWXI0g6SgdDObU0GEHju0MkDziOhm+BVwPZKN7B7wD7OPj6vlLVo6d8vLGK9byw hEfXjxLIC3Qhtu5lJPTgIo5Bup+aBBjiJ/u9BfqryqZpudnWfG+wxC327rpNAq2OKdFsR92w behSZD3mSSAemDVwGB2Yu0XHQYyyYfpWsGyGEyRSHKFhRwJdINPzWLI89wy4Wc+PgqyekkEm Jqe6g4XSQFj4mqtwvqhP4dg2QCcKM/bh62RwfM7GeSS/LFGe84KmJjTDfvT8c2rK8nEyZ/em OtwCGXQ6tZCByMNLxeDwU1TGbTGCAxcwggMTAgEBME8wOjERMA8GA1UECgwIRXJpY3Nzb24x JTAjBgNVBAMMHEVyaWNzc29uIE5MIEluZGl2aWR1YWwgQ0EgdjICEQDvmghdbd4Eckfa7tuu fmCcMA0GCWCGSAFlAwQCAQUAoIIBmTAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqG SIb3DQEJBTEPFw0xNzA4MjUwODQ1MjlaMC8GCSqGSIb3DQEJBDEiBCAD1956G6mTClGbdf62 l4XJP+/7xD5xHm+5R1l7TIliGDBeBgkrBgEEAYI3EAQxUTBPMDoxETAPBgNVBAoMCEVyaWNz c29uMSUwIwYDVQQDDBxFcmljc3NvbiBOTCBJbmRpdmlkdWFsIENBIHYyAhEA75oIXW3eBHJH 2u7brn5gnDBgBgsqhkiG9w0BCRACCzFRoE8wOjERMA8GA1UECgwIRXJpY3Nzb24xJTAjBgNV BAMMHEVyaWNzc29uIE5MIEluZGl2aWR1YWwgQ0EgdjICEQDvmghdbd4Eckfa7tuufmCcMGwG CSqGSIb3DQEJDzFfMF0wCwYJYIZIAWUDBAEqMAsGCWCGSAFlAwQBAjAKBggqhkiG9w0DBzAO BggqhkiG9w0DAgICAIAwDQYIKoZIhvcNAwICAUAwBwYFKw4DAgcwDQYIKoZIhvcNAwICASgw DQYJKoZIhvcNAQEBBQAEggEAF3+wHxVAVXLQTQbGBV5iXatPtx5QWcTHzLm9RTGz3c604u1z +OyK/LCKf78mpaP2KQG14ZqriDwvGgZtDCxwraPFvJGcKqKF0sdFIUSaQX2DMhqSbCQRTBzB NuevJ0awuVYX5UUv5Wk8LoNlWml18afyhv17/Yp8GtOcl0RH6ng5pCJr7POPuGQ7YRW7FmhH Q1V5yYP13qoeCoSsiINkoDTQJyHguCeJbdgdDwfsqUCRihIChpq2YYgErwMpkvvtdcysT/dJ WheTEvFAk53Qz9B7NsTwYAR8eWJD+B94CqJIMBQWA5VIkB0d/RAb9FqwlK5vXWyOJV95n2gR 5+jv2AAAAAAAAA== --------------ms020806010700040807070800-- From nobody Fri Aug 25 04:05:26 2017 Return-Path: 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 20FC6132713; Fri, 25 Aug 2017 04:05:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.219 X-Spam-Level: X-Spam-Status: No, score=-4.219 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no 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 KY5vVq4Cm77y; Fri, 25 Aug 2017 04:05:16 -0700 (PDT) Received: from sessmg22.ericsson.net (sessmg22.ericsson.net [193.180.251.58]) (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 73F9C132707; Fri, 25 Aug 2017 04:05:15 -0700 (PDT) X-AuditID: c1b4fb3a-617ff700000051a3-fc-59a0046994d8 Received: from ESESSHC017.ericsson.se (Unknown_Domain [153.88.183.69]) by sessmg22.ericsson.net (Symantec Mail Security) with SMTP id 99.DA.20899.96400A95; Fri, 25 Aug 2017 13:05:13 +0200 (CEST) Received: from ESESSMB109.ericsson.se ([169.254.9.194]) by ESESSHC017.ericsson.se ([153.88.183.69]) with mapi id 14.03.0352.000; Fri, 25 Aug 2017 13:05:13 +0200 From: Christer Holmberg To: Eric Rescorla , Roman Shpount CC: The IESG , "draft-ietf-mmusic-dtls-sdp@ietf.org" , "mmusic-chairs@ietf.org" , lemming Andreasen , "mmusic@ietf.org" , Justin Uberti , Cullen Jennings Thread-Topic: [MMUSIC] Eric Rescorla's Discuss on draft-ietf-mmusic-dtls-sdp-28: (with DISCUSS and COMMENT) Thread-Index: AQHTFiJ4U9eZ+Q1EiEiv1X0BiX5SzqKF+f8AgA8PuoA= Date: Fri, 25 Aug 2017 11:05:12 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.7.4.170508 x-originating-ip: [153.88.183.17] Content-Type: multipart/alternative; boundary="_000_D5C5DFA420425christerholmbergericssoncom_" MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFrrJIsWRmVeSWpSXmKPExsUyM2K7q24my4JIg7bpUhb/J85ntVjx+hy7 xfsLuhYdk9ksZvyZyGyxdaqQxfmd65kspi5/zGIx48JUZgdOjym/N7J6LNhU6rFkyU8mj8mP 25g9bk0pCGCN4rJJSc3JLEst0rdL4Mo4e34de8G8NYwVl7vmsjUwXpnA2MXIwSEhYCJx5X5h FyMXh5DAEUaJ+TN7GCGcJYwS61cdYQEpYhOwkOj+p93FyMkhIuAscaLtBRtIDbPATiaJNWtW sIAkhAVyJK6cfMsGUZQrcXJ9DzOEbSXRcOkEWJxFQFViz5ROMJtXwFri/5qHYL1CAtMZJab9 lgCxOQUCJW6/mcUOYjMKiEl8P7WGCcRmFhCXuPVkPpgtISAgsWTPeWYIW1Ti5eN/rCB3igro Sbzb7wnxl6LE8n45iM4EiQmtBxkhtgpKnJz5hGUCo+gsJENnISmbhaQMIq4ncWPqFDYIW1ti 2cLXzBC2rsSMf4egaqwl3j47xIqsZgEjxypG0eLU4uLcdCMjvdSizOTi4vw8vbzUkk2MwAg/ uOW31Q7Gg88dDzEKcDAq8fDyvZofKcSaWFZcmXuIUYKDWUmEVwSYHoR4UxIrq1KL8uOLSnNS iw8xSnOwKInzOuy7ECEkkJ5YkpqdmlqQWgSTZeLglGpgTH/g62Cz5B+DQc2yTRkctokLy1// //RbUmnuDYUZbqZv9lVcaW+ZvaejIof1HfNkcb0e2+XmXjWznJpF1t57ueeQL+vqM1um+kwy j5/NOtP4i4FolTVTdng5w4sbRlIbI3aYrpX+mLNzzb9Ntw8arZ+y7e6vc8yeh+IfcWo1uff+ dw18t3C5ghJLcUaioRZzUXEiACpwXxrsAgAA Archived-At: Subject: Re: [MMUSIC] Eric Rescorla's Discuss on draft-ietf-mmusic-dtls-sdp-28: (with DISCUSS and COMMENT) X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 25 Aug 2017 11:05:19 -0000 --_000_D5C5DFA420425christerholmbergericssoncom_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Cullen/Justin, do you have some input on this? Regards, Christer From: Eric Rescorla > Date: Wednesday 16 August 2017 at 03:09 To: Roman Shpount > Cc: "iesg@ietf.org" >, "draft-ietf-mmusic-dtls-sdp@ietf.org" >, "mmusic-chairs@ietf.org= " >, Flemming Andreas= en >, "mmusic@ietf.org" >, Justin Uberti= >, Cullen Jennings > Subject: Re: [MMUSIC] Eric Rescorla's Discuss on draft-ietf-mmusic-dtls-sdp= -28: (with DISCUSS and COMMENT) Resent-From: > Resent-To: Christer Holmberg > Resent-Date: Wednesday 16 August 2017 at 03:10 +Juberti, Cullen On Tue, Aug 15, 2017 at 4:58 PM, Roman Shpount > wrote: Eric, Thank you for your comments. On Tue, Aug 15, 2017 at 7:07 PM, Eric Rescorla > wrote: 1. Assuming I understand this document correctly, it conflicts with the guidance in JSEP. Specifically, S 4 says: No default value is defined for the SDP 'tls-id' attribute. Implementations that wish to use the attribute MUST explicitly include it in SDP offers and answers. If an offer or answer does not contain a 'tls-id' attribute (this could happen if the offerer or answerer represents an existing implementation that has not been updated to support the 'tls-id' attribute), unless there is another mechanism to explicitly indicate that a new DTLS association is to be established, a modification of one or more of the following characteristics MUST be treated as an indication that an endpoint wants to establish a new DTLS association: o DTLS setup role; or o fingerprint set; or o local transport parameters; or o ICE ufrag value This seems to say that if there is no tls-id attribute, then an ICE restart (which necessitates a ufrag change) requires a DTLS restart. JSEP isn't incredibly clear on this point, but 5.7.3 seems to say that tls-id neeed not be present: * tls-id value, which MUST be set according to [I-D.ietf-mmusic-dtls-sdp], Section 5. If this is a re-offer and the tls-id value is different from that presently in use, the DTLS connection is not being continued and the remote description MUST be part of an ICE restart, together with new ufrag and password values. If this is an answer, the tls-id value, if present, MUST be the same as in the offer. I believe that the first sentence is in error, as we clearly can't have JSEP implementations requiring that tls-id be present. ... o If the remote DTLS fingerprint has been changed or the tls-id has changed, tear down the DTLS connection. This includes the case when the PeerConnection state is "have-remote-pranswer". If a DTLS connection needs to be torn down but the answer does not indicate an ICE restart or, in the case of "have-remote-pranswer", new ICE credentials, an error MUST be generated. If an ICE restart is performed without a change in tls-id or fingerprint, then the same DTLS connection is continued over the new ICE channel. I think the best interpretation of this is that if tls-id is not present (and hence unchanged) then ICE restart does not cause DTLS restart. This is also my memory of the consensus in RTCWEB. In any case, these two documents clearly must match. In regard to ICE ufrag change without tls-id we just have to make a choice.= Both choices are bad since they both cause things to break when one side w= ould initiate new DTLS association and another side would not. I would agre= e that not starting DTLS association on ICE restart is slightly safer. In = any case, tls-id is needed to avoid this ambiguity. For anything compliant = with the new draft, tls-di must be present. I agree that going forward we need this. My sense is that the JSEP version = is better, but I've CCed Cullen and Justin to see what they think. 3. S 7.1 says: If DTLS is transported on top of a connection-oriented transport protocol (e.g., TCP or SCTP), where all IP packets are acknowledged, This is incorrect, because none of these protocols ack all IP packets. all DTLS packets associated with a previous DTLS association MUST be acknowledged (or timed out) before a new DTLS association can be established on the same instance of that transport (5-tuple). More generally, I'm not sure that this is useful, because the required semantic isn't *acknowledged* but rather that the receiver can appropriately demux. So, say you just stop sending DTLS on connection A and start sending on B, what's the delimiter, given that you don't require close_notify here? IIRC, we just decided to punt on this whole thing. Does anyone try to have successive connections over the same transport, even when it's connection oriented? Please see my comment to Mirja K=FChlewind regarding this. This text is her= e because somebody thought this draft should cover DTLS-over-SCTP. Since yo= u are one of the authors of RFC6083, can you suggest what is appropriate he= re for DTLS-over-SCTP implementations? My preference would be not to cover = DTLS-over-SCTP in this draft and limit it to only DTLS over UDP or TCP. I agree with you. I don't think it's helpful to cover this here. Is this a = question for the WG. S 5.1. media session immediately (see [RFC8122]). Note that it is permissible to wait until the other side's fingerprint(s) has been received before establishing the connection; however, this may have undesirable latency effects. I agree that it's permissible, but why would you do this? This does not seem like helpful guidance. There are implementations that do this to avoid unauthenticated media. Fair enough. S 10. Please do something about the "NEW" constructions. I literally had to pull these into ediff to know what had changed. That's not useful to people. I'm not a fan of this construction in general, but at minimum you need to explain what has changed. This is the best we came up with so far. If you have a better option, pleas= e suggest. Please provide a summary of what's changed. S 9. Regardless of the previous existence of a DTLS association, the SDP 'setup' attribute MUST be included according to the rules defined in [RFC4145] and if ICE is used, ICE restart MUST be initiated. What is the rationale for this rule? This just restates the requirement from https://tools.ietf.org/html/rfc5245= #section-12.5 . Not doing so breaks third party call control, since in this= case it is not known if this offer is intended for an existing connection = or to establish connection with a new end point. A citation here would help. -Ekr Regards, ______________ Roman Shpount --_000_D5C5DFA420425christerholmbergericssoncom_ Content-Type: text/html; charset="iso-8859-1" Content-ID: Content-Transfer-Encoding: quoted-printable
Cullen/Justin, do you have some input on this?

Regards,

Christer

From: Eric Rescorla <ekr@rtfm.com>
Date: Wednesday 16 August 2017 at 0= 3:09
To: Roman Shpount <roman@telurix.com>
Cc: "iesg@ietf.org" <iesg@i= etf.org>, "draft-ietf-mmusic-dtls-sdp@ietf.org" <draft-ietf-mmusic-dtls-sdp@ietf.org>= ;, "mmusic-chairs@ietf.org= " <mmusic-chairs@ietf.org= >, Flemming Andreasen <fand= reas@cisco.com>, "mmusic@iet= f.org" <mmusic@ietf.org>, Justin Ube= rti <juberti@google.com>, C= ullen Jennings <fluffy@cisco.com= >
Subject: Re: [MMUSIC] Eric Rescorla= 's Discuss on draft-ietf-mmusic-dtls-sdp-28: (with DISCUSS and COMMENT)
Resent-From: <alias-bounces@ietf.org>
Resent-To: Christer Holmberg <christer.holmberg@ericsson.= com>
Resent-Date: Wednesday 16 August 20= 17 at 03:10

+Juberti, Cullen

On Tue, Aug 15, 2017 at 4:58 PM, Roman Shpount <= span dir=3D"ltr"> <roman@telurix.co= m> wrote:
Eric,

Thank you for your comments.

On Tue, Aug 15, 2017 at 7:07 PM, Eric Rescorla <ekr@rtfm.com= > wrote:
1. Assuming I understand this document correctly, it conflicts with
the guidance in JSEP. Specifically, S 4 says:

   No default value is defined for the SDP 'tls-id' attribute.    Implementations that wish to use the attribute MUST explicitly=
   include it in SDP offers and answers.  If an offer or ans= wer does not
   contain a 'tls-id' attribute (this could happen if the offerer= or
   answerer represents an existing implementation that has not be= en
   updated to support the 'tls-id' attribute), unless there is an= other
   mechanism to explicitly indicate that a new DTLS association i= s to be
   established, a modification of one or more of the following    characteristics MUST be treated as an indication that an endpo= int
   wants to establish a new DTLS association:

   o  DTLS setup role; or

   o  fingerprint set; or

   o  local transport parameters; or

   o  ICE ufrag value

This seems to say that if there is no tls-id attribute, then an ICE restart=
(which necessitates a ufrag change) requires a DTLS restart. JSEP isn't
incredibly clear on this point, but 5.7.3 seems to say that tls-id
neeed not be present:

      *  tls-id value, which MUST be set according to          [I-D.ietf-mmusic-dtls-sdp], Section 5.&nb= sp; If this is a re-offer
         and the tls-id value is different from th= at presently in use,
         the DTLS connection is not being continue= d and the remote
         description MUST be part of an ICE restar= t, together with new
         ufrag and password values.  If this = is an answer, the tls-id
         value, if present, MUST be the same as in= the offer.

I believe that the first sentence is in error, as we clearly
can't have JSEP implementations requiring that tls-id be present.

   ...

   o  If the remote DTLS fingerprint has been changed or the= tls-id has
      changed, tear down the DTLS connection.  This inc= ludes the case
      when the PeerConnection state is "have-remote-pra= nswer".  If a
      DTLS connection needs to be torn down but the answer d= oes not
      indicate an ICE restart or, in the case of "have-= remote-pranswer",
      new ICE credentials, an error MUST be generated. = If an ICE
      restart is performed without a change in tls-id or fin= gerprint,
      then the same DTLS connection is continued over the ne= w ICE
      channel.

I think the best interpretation of this is that if tls-id is not present (and hence unchanged) then ICE restart does not cause DTLS restart.
This is also my memory of the consensus in RTCWEB. In any case, these
two documents clearly must match.

In regard to ICE ufrag change without tls-id we just have to make a ch= oice. Both choices are bad since they both cause things to break when one s= ide would initiate new DTLS association and another side would not. I would= agree that not starting DTLS association on ICE restart is slightly safer.  In any case, tls-id is needed to a= void this ambiguity. For anything compliant with the new draft, tls-di must= be present.

I agree that going forward we need this. My sense is that the JSEP ver= sion is better,
but I've CCed Cullen and Justin to see what they think.


 

3. S 7.1 says:
   If DTLS is transported on top of a connection-oriented transpo= rt
   protocol (e.g., TCP or SCTP), where all IP packets are acknowl= edged,

This is incorrect, because none of these protocols ack all IP packets.


   all DTLS packets associated with a previous DTLS association M= UST be
   acknowledged (or timed out) before a new DTLS association can = be
   established on the same instance of that transport (5-tuple).<= br>
More generally, I'm not sure that this is useful, because the
required semantic isn't *acknowledged* but rather that the receiver
can appropriately demux. So, say you just stop sending DTLS on
connection A and start sending on B, what's the delimiter, given
that you don't require close_notify here? IIRC, we just decided to
punt on this whole thing. Does anyone try to have successive
connections over the same transport, even when it's connection oriented?

 
Please see my comment to Mirja K=FChlewind regarding this. This text i= s here because somebody thought this draft should cover DTLS-over-SCTP. Sin= ce you are one of the authors of RFC6083, can you suggest what is appropriate here for DTLS-over-SCTP implementations? My preference woul= d be not to cover DTLS-over-SCTP in this draft and limit it to only DTLS ov= er UDP or TCP.

I agree with you. I don't think it's helpful to cover this here. Is th= is a question for the
WG.

 
S 5.1.
   media session immediately (see [RFC8122]).  Note that it = is
   permissible to wait until the other side's fingerprint(s) has = been
   received before establishing the connection; however, this may= have
   undesirable latency effects.

I agree that it's permissible, but why would you do this? This does
not seem like helpful guidance.
There are implementations that do this to avoid unauthenticated media.=

Fair enough.


S 10.
Please do something about the "NEW" constructions. I literally ha= d to
pull these into ediff to know what had changed. That's not useful to
people. I'm not a fan of this construction in general, but at minimum
you need to explain what has changed.
This is the best we came up with so far. If you have a better option, = please suggest.

Please provide a summary of what's changed.


 
S 9.
   Regardless of the
   previous existence of a DTLS association, the SDP 'setup' attr= ibute
   MUST be included according to the rules defined in [RFC4145] a= nd if
   ICE is used, ICE restart MUST be initiated.

What is the rationale for this rule?
This just restates the requirement from https://tools.ietf.or= g/html/rfc5245#section-12.5 . Not doing so breaks third party call= control, since in this case it is not known if this offer is intended for an existing connection or to establish conne= ction with a new end point.

A citation here would help.

-Ekr
 

Regards,
______________
Roman Shpount

 --_000_D5C5DFA420425christerholmbergericssoncom_-- From nobody Fri Aug 25 05:55:22 2017 Return-Path: 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 ED0B8132946; Fri, 25 Aug 2017 05:55:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.22 X-Spam-Level: X-Spam-Status: No, score=-4.22 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no 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 FgXxdHedgZXr; Fri, 25 Aug 2017 05:55:14 -0700 (PDT) Received: from sessmg22.ericsson.net (sessmg22.ericsson.net [193.180.251.58]) (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 6223F1323A6; Fri, 25 Aug 2017 05:55:13 -0700 (PDT) X-AuditID: c1b4fb3a-5ffff700000051a3-ea-59a01e2f9c45 Received: from ESESSHC015.ericsson.se (Unknown_Domain [153.88.183.63]) by sessmg22.ericsson.net (Symantec Mail Security) with SMTP id 43.43.20899.F2E10A95; Fri, 25 Aug 2017 14:55:11 +0200 (CEST) Received: from ESESSMB109.ericsson.se ([169.254.9.194]) by ESESSHC015.ericsson.se ([153.88.183.63]) with mapi id 14.03.0352.000; Fri, 25 Aug 2017 14:55:11 +0200 From: Christer Holmberg To: Adam Roach , Ben Campbell CC: "draft-ietf-mmusic-dtls-sdp@ietf.org" , "mmusic-chairs@ietf.org" , "mmusic@ietf.org" , "Flemming Andreasen" , The IESG Thread-Topic: Adam Roach's No Objection on draft-ietf-mmusic-dtls-sdp-28: (with COMMENT) Thread-Index: AQHTF6uY+fnArxR5YU+2MrlLLf27GqKRybkAgABhHACAAYaTgIAAAUUAgAACz4CAAA4TgIABYdMA Date: Fri, 25 Aug 2017 12:55:10 +0000 Message-ID: References: <150301038555.14103.1567567703984434290.idtracker@ietfa.amsl.com> <8EB6BD4A-26A9-4F98-A57A-FCCFC3F6AC97@nostrum.com> <9cdb8f3b-eb9b-f478-ecb0-2095cdba2484@nostrum.com> <83BCB0B5-0F74-43A2-9EF1-1D04EF4F9A0E@nostrum.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.7.4.170508 x-originating-ip: [153.88.183.20] Content-Type: text/plain; charset="euc-kr" Content-ID: <9D1266B0FEF0514197C8CD14D8A0CA04@ericsson.com> Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFtrHIsWRmVeSWpSXmKPExsUyM2K7va6+3IJIg50vFCz2/F3EbjG/8zS7 xf+J81kt3l/QtZjxZyKzxfmd65kspi5/zOLA7jHl90ZWjyVLfjJ5zNr5hCWAOYrLJiU1J7Ms tUjfLoEr48Sfl6wFH8Qr/kzbytLAuEC8i5GTQ0LARKL57DamLkYuDiGBI4wSO2btZoFwljBK dHVdZe1i5OBgE7CQ6P6nDdIgIuAo8fdbE1gNs8AnRomf65ewgiSEBSIlTj5oZYQoipJ49nwO nD13/WewGhYBVYmu14uZQWxeAWuJQ88PskIs62CWmHB2O1gRp4C9xP2p75lAbEYBMYnvp9aA 2cwC4hK3nsxngjhbQGLJnvPMELaoxMvH/8AOFRXQk3i33xMirChxdfpyqFYtiS8/9rFB2NYS i68tZ4SwFSWmdD9kh7hHUOLkzCcsExjFZyHZNgtJ+ywk7bOQtM9C0r6AkXUVo2hxanFxbrqR kV5qUWZycXF+nl5easkmRmCsHtzy22oH48HnjocYBTgYlXh4X3ItiBRiTSwrrsw9xCjBwawk wusuCxTiTUmsrEotyo8vKs1JLT7EKM3BoiTO67DvQoSQQHpiSWp2ampBahFMlomDU6qB0bhx xjtBM6/nXu/3tv8QY1u+9cu1s8+2MJ5jW3E966u2QHQin5u9zKL+Y3ce7Lf5809Oi3PL5UNC ue/vtXu2mX0KZTmaq5d29GLXhRMngg5d5NTY1qb784vXxWxBlWecJy2cOC2aXqhHXnn2/+N7 TyPZxWe6PZd/2fW+ozOjx2Kl6KSn96ZWeCmxFGckGmoxFxUnAgBy6kRg0QIAAA== Archived-At: Subject: Re: [MMUSIC] Adam Roach's No Objection on draft-ietf-mmusic-dtls-sdp-28: (with COMMENT) X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 25 Aug 2017 12:55:16 -0000 SGksDQoNCg0KT24gMjQvMDgvMTcgMjE6NTMsICJBZGFtIFJvYWNoIiA8YWRhbUBub3N0cnVtLmNv bT4gd3JvdGU6DQoNCj5PbiA4LzI0LzE3IDEzOjAyLCBCZW4gQ2FtcGJlbGwgd3JvdGU6DQo+Pj4g T24gQXVnIDI0LCAyMDE3LCBhdCAxMjo1MiBQTSwgQWRhbSBSb2FjaCA8YWRhbUBub3N0cnVtLmNv bT4gd3JvdGU6DQo+Pj4NCj4+PiBPbiA4LzI0LzE3IDEyOjQ4LCBCZW4gQ2FtcGJlbGwgd3JvdGU6 DQo+Pj4+PiBPbiBBdWcgMjMsIDIwMTcsIGF0IDE6MzAgUE0sIEFkYW0gUm9hY2ggPGFkYW1Abm9z dHJ1bS5jb20+IHdyb3RlOg0KPj4+Pj4NCj4+Pj4+IE9uIDgvMjMvMTcgMDQ6MzgsIENocmlzdGVy IEhvbG1iZXJnIHdyb3RlOg0KPj4+Pj4+PiBJIHdvdWxkIHRoaW5rIHRoZSBsb25nLWZvcm0gdGl0 bGUgb2YgdGhpcyBkb2N1bWVudCBzaG91bGQgaW5jbHVkZQ0KPj4+Pj4+PiJUTFMsIg0KPj4+Pj4+ PiB0bw0KPj4+Pj4+PiByZWZsZWN0IHRoYXQgaXQgYWxzbyBjb250YWlucyBUTFMtcmVsYXRlZCBw cm9jZWR1cmVzLg0KPj4+Pj4+IFRoZSBpc3N1ZSBpcyB0aGF0IHRoZSBkb2N1bWVudCBkb2Vzbqn2 dCByZWFsbHkgZGVmaW5lIHRoZSBPL0ENCj4+Pj4+PnByb2NlZHVyZXMNCj4+Pj4+PiBmb3IgVExT LiBJdCBzaW1wbHkgYWRkcyB0aGUgdXNhZ2Ugb2YgdGhlIHRscy1pZCBhdHRyaWJ1dGUgdG8gdGhl DQo+Pj4+Pj5leGlzdGluZw0KPj4+Pj4+IHByb2NlZHVyZXMgZGVmaW5lZCBlbHNld2hlcmUuDQo+ Pj4+PiBSaWdodCwgc28gbWFrZSB0aGF0IGNsZWFyLiBJIG5vdGUgdGhhdCBzaW1wbHkgYWRkaW5n ICJhbmQNCj4+Pj4+SWRlbnRpZmljYXRpb24gb2YgVExTIENvbm5lY3Rpb25zIiB0byB0aGUgZW5k IGlzIGFtYmlndW91cyAoc2luY2UgaXQNCj4+Pj4+bWFrZXMgaXQgc291bmQgbGlrZSBpdCBkZWZp bmVzIE8vQSBmb3IgVExTKSwgYnV0IHlvdSBjYW4gZml4IHRoaXMgYnkNCj4+Pj4+cmV2ZXJzaW5n IHRoZSBleGlzdGluZyB0aXRsZTsgZS5nLiwgc29tZXRoaW5nIGxpa2U6ICJFc3RhYmxpc2hpbmcN Cj4+Pj4+RGF0YWdyYW0gVHJhbnNwb3J0IExheWVyIFNlY3VyaXR5IChEVExTKSBVc2luZyB0aGUg U2Vzc2lvbg0KPj4+Pj5EZXNjcmlwdGlvbiBQcm90b2NvbCAoU0RQKSBPZmZlci9BbnN3ZXIgTWVj aGFuaXNtIGFuZCBJZGVudGlmaWNhdGlvbg0KPj4+Pj5vZiBUcmFuc3BvcnQgTGF5ZXIgU2VjdXJp dHkgKFRMUykgQ29ubmVjdGlvbnMgaW4gU0RQobENCj4+Pj4gV293LCB0aGF0oa9zIHBldHR5IGN1 bWJlcnNvbWUgYXMgYSB0aXRsZaGqaXShr3MgcHJldHR5IG11Y2ggYW4gYWJzdHJhY3QuDQo+Pj4+ RG9lcyBpdCBuZWVkIHRoYXQgbXVjaCBkZXRhaWw/DQo+Pj4+DQo+Pj4gSXQncyB0aGUgcmVzdWx0 IG9mIHRha2luZyBhIHJlYXNvbmFibHkgc2hvcnQgdGl0bGUgKCJFc3RhYmxpc2hpbmcgRExUUw0K Pj4+dXNpbmcgdGhlIFNEUCBPZmZlci9BbnN3ZXIgTWVjaGFuaXNtIGFuZCBJZGVudGlmaWNhdGlv biBvZiBUTFMNCj4+PkNvbm5lY3Rpb25zIGluIFNEUCIpIGFuZCBhcHBseWluZyBSRkMgRWRpdG9y IHBvbGljaWVzIG9mIGFjcm9ueW0NCj4+PmV4cGFuc2lvbiB0byBpdC4gSWYgeW91IGNhbiB0aGlu ayBvZiBzb21lIHNob3J0ZXIgd2F5IHRvIHNheSBpdCwgdGhhdCdkDQo+Pj5iZSBncmVhdCAtLSBi dXQgaWYgSSdtIHBlcnVzaW5nIGEgbGlzdCBvZiB0aXRsZXMgZm9yIHNvbWV0aGluZw0KPj4+VExT LXJlbGF0ZWQgYW5kIGNvbWUgYWNyb3NzIG9uZSB0aGF0IG1lbnRpb25zIG9ubHkgRFRMUywgSSdk IHNraXAgb3Zlcg0KPj4+aXQuIFRoZSBvcmlnaW5hbCB0aXRsZSBzZWVtcyBsaWtlIGEgZ2VudWlu ZSBmbGF3Lg0KPj4gSGVyZaGvcyBhIHNhY3JpZmljaWFsIHByb3Bvc2FsIGZyb20gdGhlIF9tdWNo XyBtb3JlIGdlbmVyYWwgc2lkZToNCj4+DQo+PiAgICAgIKGwRFRMUyBhbmQgVExTIGNvbnNpZGVy YXRpb25zIGluIHRoZSBTRFAgT2ZmZXIvQW5zd2VyIE1lY2hhbmlzbaGxDQo+Pg0KPj4goaYgd2l0 aCBhcHByb3ByaWF0ZSBhY3JvbnltIGV4cGFuc2lvbnMgb2YgY291cnNlLg0KPg0KPkkgaGF2ZSBu byBwcm9ibGVtIHdpdGggdGhhdC4NCg0KDQqhsEluIHRoZSBtZWNoYW5pc22hsSBzb3VuZHMgYSBs aXR0bGUgc3RyYW5nZSBpbiBteSBlYXJzLCBzbyBJIHN1Z2dlc3Q6DQoNCqGwU0RQIE9mZmVyL0Fu c3dlciBjb25zaWRlcmF0aW9ucyBmb3IgRFRMUyBhbmQgVExTobENCg0KUmVnYXJkcywNCg0KQ2hy aXN0ZXINCg0K From nobody Fri Aug 25 07:36:05 2017 Return-Path: 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 4DAF5132BF1; Fri, 25 Aug 2017 07:35:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.879 X-Spam-Level: X-Spam-Status: No, score=-1.879 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, T_SPF_HELO_PERMERROR=0.01, T_SPF_PERMERROR=0.01, URIBL_BLOCKED=0.001] autolearn=unavailable autolearn_force=no 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 q0oStuY1vVK0; Fri, 25 Aug 2017 07:35:56 -0700 (PDT) Received: from nostrum.com (raven-v6.nostrum.com [IPv6:2001:470:d:1130::1]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id F0BB213295C; Fri, 25 Aug 2017 07:35:55 -0700 (PDT) Received: from [10.0.1.63] (cpe-66-25-7-22.tx.res.rr.com [66.25.7.22]) (authenticated bits=0) by nostrum.com (8.15.2/8.15.2) with ESMTPSA id v7PEZi9W099694 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NO); Fri, 25 Aug 2017 09:35:46 -0500 (CDT) (envelope-from ben@nostrum.com) X-Authentication-Warning: raven.nostrum.com: Host cpe-66-25-7-22.tx.res.rr.com [66.25.7.22] claimed to be [10.0.1.63] Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) From: Ben Campbell In-Reply-To: Date: Fri, 25 Aug 2017 09:35:45 -0500 Cc: Adam Roach , "draft-ietf-mmusic-dtls-sdp@ietf.org" , "mmusic-chairs@ietf.org" , "mmusic@ietf.org" , Flemming Andreasen , The IESG Content-Transfer-Encoding: quoted-printable Message-Id: <2560A40F-0B45-407B-AB75-B4E901DF77D7@nostrum.com> References: <150301038555.14103.1567567703984434290.idtracker@ietfa.amsl.com> <8EB6BD4A-26A9-4F98-A57A-FCCFC3F6AC97@nostrum.com> <9cdb8f3b-eb9b-f478-ecb0-2095cdba2484@nostrum.com> <83BCB0B5-0F74-43A2-9EF1-1D04EF4F9A0E@nostrum.com> To: Christer Holmberg X-Mailer: Apple Mail (2.3273) Archived-At: Subject: Re: [MMUSIC] Adam Roach's No Objection on draft-ietf-mmusic-dtls-sdp-28: (with COMMENT) X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 25 Aug 2017 14:35:57 -0000 > On Aug 25, 2017, at 7:55 AM, Christer Holmberg = wrote: >=20 > Hi, >=20 >=20 > On 24/08/17 21:53, "Adam Roach" wrote: >=20 >> On 8/24/17 13:02, Ben Campbell wrote: >>>> On Aug 24, 2017, at 12:52 PM, Adam Roach wrote: >>>>=20 >>>> On 8/24/17 12:48, Ben Campbell wrote: >>>>>> On Aug 23, 2017, at 1:30 PM, Adam Roach wrote: >>>>>>=20 >>>>>> On 8/23/17 04:38, Christer Holmberg wrote: >>>>>>>> I would think the long-form title of this document should = include >>>>>>>> "TLS," >>>>>>>> to >>>>>>>> reflect that it also contains TLS-related procedures. >>>>>>> The issue is that the document doesn=C2=B9t really define the = O/A >>>>>>> procedures >>>>>>> for TLS. It simply adds the usage of the tls-id attribute to the >>>>>>> existing >>>>>>> procedures defined elsewhere. >>>>>> Right, so make that clear. I note that simply adding "and >>>>>> Identification of TLS Connections" to the end is ambiguous (since = it >>>>>> makes it sound like it defines O/A for TLS), but you can fix this = by >>>>>> reversing the existing title; e.g., something like: "Establishing >>>>>> Datagram Transport Layer Security (DTLS) Using the Session >>>>>> Description Protocol (SDP) Offer/Answer Mechanism and = Identification >>>>>> of Transport Layer Security (TLS) Connections in SDP=E2=80=9D >>>>> Wow, that=E2=80=99s petty cumbersome as a title=E2=80=95it=E2=80=99s= pretty much an abstract. >>>>> Does it need that much detail? >>>>>=20 >>>> It's the result of taking a reasonably short title ("Establishing = DLTS >>>> using the SDP Offer/Answer Mechanism and Identification of TLS >>>> Connections in SDP") and applying RFC Editor policies of acronym >>>> expansion to it. If you can think of some shorter way to say it, = that'd >>>> be great -- but if I'm perusing a list of titles for something >>>> TLS-related and come across one that mentions only DTLS, I'd skip = over >>>> it. The original title seems like a genuine flaw. >>> Here=E2=80=99s a sacrificial proposal from the _much_ more general = side: >>>=20 >>> =E2=80=9CDTLS and TLS considerations in the SDP Offer/Answer = Mechanism=E2=80=9D >>>=20 >>> =E2=80=A6 with appropriate acronym expansions of course. >>=20 >> I have no problem with that. >=20 >=20 > =E2=80=9CIn the mechanism=E2=80=9D sounds a little strange in my ears, = so I suggest: >=20 > =E2=80=9CSDP Offer/Answer considerations for DTLS and TLS=E2=80=9D WFM, and even saves 2 more words :-) =20 It will of course need expansions for SDP, DTLS, and TLS, but I assume = you plan that. >=20 > Regards, >=20 > Christer From nobody Fri Aug 25 07:41:08 2017 Return-Path: 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 B03AA132BF7 for ; Fri, 25 Aug 2017 07:41:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.879 X-Spam-Level: X-Spam-Status: No, score=-1.879 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, T_SPF_HELO_PERMERROR=0.01, T_SPF_PERMERROR=0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no 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 zKZj-EVUpkuS for ; Fri, 25 Aug 2017 07:41:04 -0700 (PDT) Received: from nostrum.com (raven-v6.nostrum.com [IPv6:2001:470:d:1130::1]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B02D8132BF6 for ; Fri, 25 Aug 2017 07:41:04 -0700 (PDT) Received: from [10.0.1.63] (cpe-66-25-7-22.tx.res.rr.com [66.25.7.22]) (authenticated bits=0) by nostrum.com (8.15.2/8.15.2) with ESMTPSA id v7PEf2hJ000691 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NO); Fri, 25 Aug 2017 09:41:03 -0500 (CDT) (envelope-from ben@nostrum.com) X-Authentication-Warning: raven.nostrum.com: Host cpe-66-25-7-22.tx.res.rr.com [66.25.7.22] claimed to be [10.0.1.63] Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) From: Ben Campbell In-Reply-To: <195f8cfb-9ee4-a13d-3703-cc51844899cd@ericsson.com> Date: Fri, 25 Aug 2017 09:41:03 -0500 Cc: Henning Schulzrinne , aamelnikov@fastmail.fm, Adam Roach , bo.burman@ericsson.com, Flemming Andreasen , persgray@gmail.com, mmusic@ietf.org Content-Transfer-Encoding: quoted-printable Message-Id: References: <20170808165231.7B757B80E45@rfc-editor.org> <195f8cfb-9ee4-a13d-3703-cc51844899cd@ericsson.com> To: Magnus Westerlund X-Mailer: Apple Mail (2.3273) Archived-At: Subject: Re: [MMUSIC] [Technical Errata Reported] RFC2326 (5079) X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 25 Aug 2017 14:41:07 -0000 RFC 2326 is obsolete. I don=E2=80=99t think we normally accept errata = against obsolete drafts, do we? (If anyone still cares about RTSP 1.0, = maybe it should have been made historical instead,. But that=E2=80=99s = water under the bridge.) I assume the content-length exampless in 7826 are correct? Ben. > On Aug 25, 2017, at 3:45 AM, Magnus Westerlund = wrote: >=20 > Hi, >=20 > Thanks for reporting, however considering how many issues there are in = RFC 2326, and why RFC 7826 was produced, I frankly don't know if its = worth accepting this errata or not. >=20 > The errata is clearly right in that the RFC is wrong. If one follows = the format for text/parameters defined in RTSP 2.0: = https://datatracker.ietf.org/doc/rfc7826/ then there should be CRLF at = the end of each line, and there are no EOF marker. Thus the length = should be: 26. So maybe with that edit it is simplest to accept it. >=20 > Cheers >=20 > Magnus Westerlund >=20 >=20 >=20 > Den 2017-08-08 kl. 18:52, skrev RFC Errata System: >> The following errata report has been submitted for RFC2326, >> "Real Time Streaming Protocol (RTSP)". >>=20 >> -------------------------------------- >> You may review the report below and at: >> http://www.rfc-editor.org/errata/eid5079 >>=20 >> -------------------------------------- >> Type: Technical >> Reported by: Vadim Zhukov >>=20 >> Section: 10.8 >>=20 >> Original Text >> ------------- >> S->C: GET_PARAMETER rtsp://example.com/fizzle/foo RTSP/1.0 >> CSeq: 431 >> Content-Type: text/parameters >> Session: 12345678 >> Content-Length: 15 >>=20 >> packets_received >> jitter >>=20 >> Corrected Text >> -------------- >> S->C: GET_PARAMETER rtsp://example.com/fizzle/foo RTSP/1.0 >> CSeq: 431 >> Content-Type: text/parameters >> Session: 12345678 >> Content-Length: 24 >>=20 >> packets_received >> jitter >>=20 >> Notes >> ----- >> The Content-Length value is wrong, it should be either 24 (as = proposed) or 26, depending on end-of-line marker used for message = content. >>=20 >> Instructions: >> ------------- >> This erratum is currently posted as "Reported". If necessary, please >> use "Reply All" to discuss whether it should be verified or >> rejected. When a decision is reached, the verifying party >> can log in to change the status and edit the report, if necessary. >>=20 >> -------------------------------------- >> RFC2326 (no draft string recorded) >> -------------------------------------- >> Title : Real Time Streaming Protocol (RTSP) >> Publication Date : April 1998 >> Author(s) : H. Schulzrinne, A. Rao, R. Lanphier >> Category : PROPOSED STANDARD >> Source : Multiparty Multimedia Session Control RAI >> Area : Real-time Applications and Infrastructure >> Stream : IETF >> Verifying Party : IESG >>=20 >> _______________________________________________ >> mmusic mailing list >> mmusic@ietf.org >> https://www.ietf.org/mailman/listinfo/mmusic >=20 > --=20 >=20 > Magnus Westerlund >=20 > ---------------------------------------------------------------------- > Media Technologies, Ericsson Research > ---------------------------------------------------------------------- > Ericsson AB | Phone +46 10 7148287 > Torshamnsgatan 23 | Mobile +46 73 0949079 > SE-164 80 Stockholm, Sweden | mailto: magnus.westerlund@ericsson.com > ---------------------------------------------------------------------- >=20 >=20 From nobody Fri Aug 25 13:30:20 2017 Return-Path: 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 CFA38132C4B for ; Fri, 25 Aug 2017 13:30:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.879 X-Spam-Level: X-Spam-Status: No, score=-1.879 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, T_SPF_HELO_PERMERROR=0.01, T_SPF_PERMERROR=0.01] autolearn=ham autolearn_force=no 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 hm0ydOxL1aSs for ; Fri, 25 Aug 2017 13:30:17 -0700 (PDT) Received: from nostrum.com (raven-v6.nostrum.com [IPv6:2001:470:d:1130::1]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1C52813219F for ; Fri, 25 Aug 2017 13:30:17 -0700 (PDT) Received: from Svantevit.roach.at (cpe-70-122-154-80.tx.res.rr.com [70.122.154.80]) (authenticated bits=0) by nostrum.com (8.15.2/8.15.2) with ESMTPSA id v7PKUElA059650 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NO) for ; Fri, 25 Aug 2017 15:30:15 -0500 (CDT) (envelope-from adam@nostrum.com) X-Authentication-Warning: raven.nostrum.com: Host cpe-70-122-154-80.tx.res.rr.com [70.122.154.80] claimed to be Svantevit.roach.at To: "mmusic@ietf.org" From: Adam Roach Message-ID: Date: Fri, 25 Aug 2017 15:30:14 -0500 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:52.0) Gecko/20100101 Thunderbird/52.2.1 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="------------449D652A9719D600E82E4E85" Content-Language: en-US Archived-At: Subject: [MMUSIC] DTLS-SDP and JSEP Conflicts X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 25 Aug 2017 20:30:19 -0000 This is a multi-part message in MIME format. --------------449D652A9719D600E82E4E85 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit MMUSIC -- [I will be posting a separate message to RTCWEB directing interested parties to discuss this issue on the MMUSIC mailing list] During the IESG review of draft-ietf-mmusic-dtls-sdp, EKR identified some conflicts between the procedures in DTLS-SDP and JSEP were identified. This note is an attempt to summarize them. I have also made an initial proposal, for each conflict, regarding which document needs to change, in and which way. Issue 1 (quoting EKR), which raises a couple of additional sub-issues: > 1. Assuming I understand this document correctly, it conflicts with > the guidance in JSEP. Specifically, S 4 says: > > No default value is defined for the SDP 'tls-id' attribute. > Implementations that wish to use the attribute MUST explicitly > include it in SDP offers and answers. If an offer or answer does not > contain a 'tls-id' attribute (this could happen if the offerer or > answerer represents an existing implementation that has not been > updated to support the 'tls-id' attribute), unless there is another > mechanism to explicitly indicate that a new DTLS association is to be > established, a modification of one or more of the following > characteristics MUST be treated as an indication that an endpoint > wants to establish a new DTLS association: > > o DTLS setup role; or > > o fingerprint set; or > > o local transport parameters; or > > o ICE ufrag value > > This seems to say that if there is no tls-id attribute, then an ICE restart > (which necessitates a ufrag change) requires a DTLS restart. JSEP isn't > incredibly clear on this point, but 5.7.3 seems to say that tls-id > need not be present: > > * tls-id value, which MUST be set according to > [I-D.ietf-mmusic-dtls-sdp], Section 5. If this is a re-offer > and the tls-id value is different from that presently in use, > the DTLS connection is not being continued and the remote > description MUST be part of an ICE restart, together with new > ufrag and password values. If this is an answer, the tls-id > value, if present, MUST be the same as in the offer. > > I believe that the first sentence is in error, as we clearly > can't have JSEP implementations requiring that tls-id be present. > > ... > > o If the remote DTLS fingerprint has been changed or the tls-id has > changed, tear down the DTLS connection. This includes the case > when the PeerConnection state is "have-remote-pranswer". If a > DTLS connection needs to be torn down but the answer does not > indicate an ICE restart or, in the case of "have-remote-pranswer", > new ICE credentials, an error MUST be generated. If an ICE > restart is performed without a change in tls-id or fingerprint, > then the same DTLS connection is continued over the new ICE > channel. > > I think the best interpretation of this is that if tls-id is not present > (and hence unchanged) then ICE restart does not cause DTLS restart. > This is also my memory of the consensus in RTCWEB. In any case, these > two documents clearly must match. My observations/recommendations: 1. (Issue 1a) EKR is correct that the first sentence of the bullet from JSEP needs to be removed so as to enable interoperation with non-JSEP implementations. 2. (Issue 1b) Additionally the final sentence of that bullet ("If this is an answer, the tls-id value, if present, MUST be the same as in the offer") conflicts with the definition of tls-id ("the offerer and answerer generate their own local 'tls-id' attribute values, and the combination of both values identify the DTLS association"). In this case, the DTLS-SDP document would appear to be correct (the fact that the two parties choose different IDs is integral to the mechanism's design), so JSEP needs to change. 3. (Issue 1c) The crux of the matter: does ICE restart cause DTLS to restart? The primary rationale outlined in RFC5245 for restarting ICE is changing the destination (IP address or port) of an ongoing media stream -- which would commonly involve changing to a different physical device. While it would, in theory, be possible to transfer the TLS state associated with the connection between devices, this is rather cumbersome (and, as far as I know, not generally supported by TLS libraries). From that perspective, it is my opinion that the DTLS-SDP document is correct that an ICE restart necessitates a new DTLS connection; and I conclude that JSEP needs to change. Issue 2 (quoting EKR): > 2. S 4 says: > > The mux category [I-D.ietf-mmusic-sdp-mux-attributes] for the 'tls- > id' attribute is 'IDENTICAL', which means that the attribute value > must be identical across all media descriptions being multiplexed > [I-D.ietf-mmusic-sdp-bundle-negotiation]. > > This is not actually what JSEP requires: > > different categories. To avoid unnecessary duplication when > bundling, attributes of category IDENTICAL or TRANSPORT MUST NOT be > repeated in bundled m= sections, repeating the guidance from > [I-D.ietf-mmusic-sdp-bundle-negotiation], Section 8.1. This includes > > I suspect this is old text. (Issue 2) JSEP is aligned with draft-ietf-mmusic-sdp-bundle-negotiation-38, while DTLS-SDP does not. This is a largely aesthetic decision (although the JSEP/BUNDLE approach does save a tiny handful of bytes), but I think changing one document (DTLS-SDP) makes more sense than changing two. (I suspect the BUNDLE formulation more closely tracks consensus anyway). /a --------------449D652A9719D600E82E4E85 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 7bit

MMUSIC --

[I will be posting a separate message to RTCWEB directing interested parties to discuss this issue on the MMUSIC mailing list]

During the IESG review of draft-ietf-mmusic-dtls-sdp, EKR identified some conflicts between the procedures in DTLS-SDP and JSEP were identified. This note is an attempt to summarize them. I have also made an initial proposal, for each conflict, regarding which document needs to change, in and which way.

Issue 1 (quoting EKR), which raises a couple of additional sub-issues:

1. Assuming I understand this document correctly, it conflicts with
the guidance in JSEP. Specifically, S 4 says:

   No default value is defined for the SDP 'tls-id' attribute.
   Implementations that wish to use the attribute MUST explicitly
   include it in SDP offers and answers.  If an offer or answer does not
   contain a 'tls-id' attribute (this could happen if the offerer or
   answerer represents an existing implementation that has not been
   updated to support the 'tls-id' attribute), unless there is another
   mechanism to explicitly indicate that a new DTLS association is to be
   established, a modification of one or more of the following
   characteristics MUST be treated as an indication that an endpoint
   wants to establish a new DTLS association:

   o  DTLS setup role; or

   o  fingerprint set; or

   o  local transport parameters; or

   o  ICE ufrag value

This seems to say that if there is no tls-id attribute, then an ICE restart
(which necessitates a ufrag change) requires a DTLS restart. JSEP isn't
incredibly clear on this point, but 5.7.3 seems to say that tls-id
need not be present:

      *  tls-id value, which MUST be set according to
         [I-D.ietf-mmusic-dtls-sdp], Section 5.  If this is a re-offer
         and the tls-id value is different from that presently in use,
         the DTLS connection is not being continued and the remote
         description MUST be part of an ICE restart, together with new
         ufrag and password values.  If this is an answer, the tls-id
         value, if present, MUST be the same as in the offer.

I believe that the first sentence is in error, as we clearly
can't have JSEP implementations requiring that tls-id be present.

   ...
   
   o  If the remote DTLS fingerprint has been changed or the tls-id has
      changed, tear down the DTLS connection.  This includes the case
      when the PeerConnection state is "have-remote-pranswer".  If a
      DTLS connection needs to be torn down but the answer does not
      indicate an ICE restart or, in the case of "have-remote-pranswer",
      new ICE credentials, an error MUST be generated.  If an ICE
      restart is performed without a change in tls-id or fingerprint,
      then the same DTLS connection is continued over the new ICE
      channel.
      
I think the best interpretation of this is that if tls-id is not present
(and hence unchanged) then ICE restart does not cause DTLS restart.
This is also my memory of the consensus in RTCWEB. In any case, these
two documents clearly must match.


My observations/recommendations:

  1. (Issue 1a) EKR is correct that the first sentence of the bullet from JSEP needs to be removed so as to enable interoperation with non-JSEP implementations.

  2. (Issue 1b) Additionally the final sentence of that bullet ("If this is an answer, the tls-id value, if present, MUST be the same as in the offer") conflicts with the definition of tls-id ("the offerer and answerer generate their own local 'tls-id' attribute values, and the combination of both values identify the DTLS association"). In this case, the DTLS-SDP document would appear to be correct (the fact that the two parties choose different IDs is integral to the mechanism's design), so JSEP needs to change.

  3. (Issue 1c) The crux of the matter: does ICE restart cause DTLS to restart? The primary rationale outlined in RFC5245 for restarting ICE is changing the destination (IP address or port) of an ongoing media stream -- which would commonly involve changing to a different physical device. While it would, in theory, be possible to transfer the TLS state associated with the connection between devices, this is rather cumbersome (and, as far as I know, not generally supported by TLS libraries). From that perspective, it is my opinion that the DTLS-SDP document is correct that an ICE restart necessitates a new DTLS connection; and I conclude that JSEP needs to change.


Issue 2 (quoting EKR):

2. S 4 says:

   The mux category [I-D.ietf-mmusic-sdp-mux-attributes] for the 'tls-
   id' attribute is 'IDENTICAL', which means that the attribute value
   must be identical across all media descriptions being multiplexed
   [I-D.ietf-mmusic-sdp-bundle-negotiation].

This is not actually what JSEP requires:

   different categories.  To avoid unnecessary duplication when
   bundling, attributes of category IDENTICAL or TRANSPORT MUST NOT be
   repeated in bundled m= sections, repeating the guidance from
   [I-D.ietf-mmusic-sdp-bundle-negotiation], Section 8.1.  This includes

I suspect this is old text.


(Issue 2) JSEP is aligned with draft-ietf-mmusic-sdp-bundle-negotiation-38, while DTLS-SDP does not. This is a largely aesthetic decision (although the JSEP/BUNDLE approach does save a tiny handful of bytes), but I think changing one document (DTLS-SDP) makes more sense than changing two. (I suspect the BUNDLE formulation more closely tracks consensus anyway).


/a

--------------449D652A9719D600E82E4E85-- From nobody Fri Aug 25 14:39:28 2017 Return-Path: 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 ADFEB132C6C for ; Fri, 25 Aug 2017 14:39:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.388 X-Spam-Level: X-Spam-Status: No, score=-1.388 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_SORBS_SPAM=0.5, T_SPF_PERMERROR=0.01, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=telurix-com.20150623.gappssmtp.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 jMT8FRwZps_I for ; Fri, 25 Aug 2017 14:39:26 -0700 (PDT) Received: from mail-pg0-x22d.google.com (mail-pg0-x22d.google.com [IPv6:2607:f8b0:400e:c05::22d]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 07A4213280C for ; Fri, 25 Aug 2017 14:39:25 -0700 (PDT) Received: by mail-pg0-x22d.google.com with SMTP id r133so5260334pgr.3 for ; Fri, 25 Aug 2017 14:39:25 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=telurix-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=jiePJZOOoIjmUeuRiLJWUKolRq6kuMVlcyBsZ+kz8LQ=; b=XmeLxnILvq1Li4Om6IRriCdfvQ0iTWt25i/gm2ncW/BH3YIY66wBVcz59TNA72eOkP ibOakfXxtvOEoI2YM8EJU1pwT9az6Jdycghf7i+4G1sb3gz4RsvxThdfvhEq9RSNL+yB oX6LghYIGlstKh17+fA4buGiwvWhf4n+457APRXgiy0EKKJcrP+Y4Ma3TWVukTXb1NI+ pAcjfQA2NJZsO1MIPdUvA1qJ/qli046cs+pU8/UK8az9HTIOCKCH+o9F6zTrrLlHTCGF J7Zv/gpEOoU/QBVeEOb7r9OwA9HqrCsWitPYW7O+WnTiStCanJ01KfnJfb2NO6kbLHKL fBFQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=jiePJZOOoIjmUeuRiLJWUKolRq6kuMVlcyBsZ+kz8LQ=; b=mSQNdoWiOsfAIEC+IxSGKDCD8uMlTBCmhtzX7UIO5wuJWPsfYaYkoDyGvo1uPJzIv9 GMBp9BS9cwA8UDSm5HcsTwCw7avWzGck/CXmR0o6cj/2cvjmKAnQpFSGOgMrd3Jt/Qdm aT8Dv3ObVf9Qd5LHroynXlyHxlGJTCKV0gkUvpI5pWlzNXdVIbwp8r2ETKWF8BA7yJL5 V2g8N6v4HREoVg4ytFsnAiPY52iaQrRvZ9rRKRJvXM1QqnFBZul3WYq1JeFeJfISiqIX 70/7nsUD4ZR0zaZ2K4r9iCGx2U4Bh37+dYdNNg8JV828EEpsj0P9i/wtcDyEAz5NCEzt mzBQ== X-Gm-Message-State: AHYfb5hy5rRlqh+UZlT61bGyXTlrU4Bil8irXv+oRxHbNQf69/UXt+Nk W/GM9cOmfAt1YDZk4Iw= X-Received: by 10.99.119.196 with SMTP id s187mr11051736pgc.57.1503697165241; Fri, 25 Aug 2017 14:39:25 -0700 (PDT) Received: from mail-pg0-f52.google.com (mail-pg0-f52.google.com. [74.125.83.52]) by smtp.gmail.com with ESMTPSA id p17sm15244089pfj.176.2017.08.25.14.39.24 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 25 Aug 2017 14:39:24 -0700 (PDT) Received: by mail-pg0-f52.google.com with SMTP id t3so5345601pgt.0 for ; Fri, 25 Aug 2017 14:39:24 -0700 (PDT) X-Received: by 10.84.140.3 with SMTP id 3mr12429876pls.374.1503697164363; Fri, 25 Aug 2017 14:39:24 -0700 (PDT) MIME-Version: 1.0 Received: by 10.100.191.8 with HTTP; Fri, 25 Aug 2017 14:39:23 -0700 (PDT) In-Reply-To: References: From: Roman Shpount Date: Fri, 25 Aug 2017 17:39:23 -0400 X-Gmail-Original-Message-ID: Message-ID: To: Adam Roach Cc: "mmusic@ietf.org" Content-Type: multipart/alternative; boundary="94eb2c1194da54ee2605579ac74c" Archived-At: Subject: Re: [MMUSIC] DTLS-SDP and JSEP Conflicts X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 25 Aug 2017 21:39:28 -0000 --94eb2c1194da54ee2605579ac74c Content-Type: text/plain; charset="UTF-8" On Fri, Aug 25, 2017 at 4:30 PM, Adam Roach wrote: > > 1. (Issue 1c) The crux of the matter: does ICE restart cause DTLS to > restart? The primary rationale outlined in RFC5245 for restarting ICE is > changing the destination (IP address or port) of an ongoing media stream -- > which would commonly involve changing to a different physical device. While > it would, in theory, be possible to transfer the TLS state associated with > the connection between devices, this is rather cumbersome (and, as far as I > know, not generally supported by TLS libraries). From that perspective, it > is my opinion that the DTLS-SDP document is correct that an ICE restart > necessitates a new DTLS connection; and I conclude that JSEP needs to > change. > > > This is a really thorny issue which does not have a good solution. Correct handling of ufrag change is one of the main reasons why tls-id draft was written in the first place. Here is a little bit more background on the problem: 1. If ICE restart was caused by 3pcc and resulted in connection to a new device, new DTLS association is required. In some cases, connection to a new device will also result in the new fingerprint set. In some cases (like transfer withing the same organization which uses the same pre-provisioned certificate), fingerprints will stay the same and only ufrag will change. So, this means new DTLS association should be established if ufrag changes due to device change. 2. If ICE restart is initiated when new network interfaces became available, such as when WiFi became available on the mobile device. This means that both existing candidates and new candidates can be present during ICE restart. This also means, that in some situations, even though ICE restart completes, the underlying transport does not have to change and the same ICE candidate pair will be used after ICE restart. Since this is the same ICE candidate pair, it will mean that packets from old and new DTLS association can be received over the same 5-tuple and they cannot be demultiplexed. This means DTLS association should stay the same even if ufrag changes due to ICE restart but when end points plans to re-use ICE candidates. So, we have two situations which both will result in some interop problems regardless of which decision we will make. Taking into account that most of existing ICE with DTLS implementations use ephemeral certificates, 3pcc will likely result in change of both ufrag and fingerprints. Because of this, I think not establishing new DTLS association on ufrag change is a safer option. Which means JSEP text is probably a safer option, especially where WebRTC is concerned. This being said, going forward tls-id should be used to make sure this is resolved in unambiguous manner. Regards, _____________ Roman Shpount --94eb2c1194da54ee2605579ac74c Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
On Fri, Aug 25, 2017 at 4:30 PM, Adam Roach <adam@nostrum.com><= /span> wrote:
=20 =20 =20
  1. (Issue 1c) The crux of the matter: does ICE restart cause DTLS to restart? The primary rationale outlined in RFC5245 for restarting ICE is changing the destination (IP address or port) of an ongoing media stream -- which would commonly involve changing to a different physical device. While it would, in theory, be possible to transfer the TLS state associated with the connection between devices, this is rather cumbersome (and, as far as I know, not generally supported by TLS libraries). From that perspective, it is my opinion that the DTLS-SDP document is correct that an ICE restart necessitates a new DTLS connection; and I conclude that JSEP needs to change.


This is a really thorny issue which = does not have a good solution. Correct handling of ufrag change is one of t= he main reasons why tls-id draft was written in the first place. Here is a = little bit more background on the problem:

1. If I= CE restart was caused by 3pcc and resulted in connection to a new device, n= ew DTLS association is required. In some cases, connection to a new device = will also result in the new fingerprint set. In some cases (like transfer w= ithing the same organization which uses the same pre-provisioned certificat= e), fingerprints will stay the same and only ufrag will change. So, this me= ans new DTLS association should be established if ufrag changes due to devi= ce change.

2. If ICE restart is initiated when new= network interfaces became available, such as when WiFi became available on= the mobile device. This means that both existing candidates and new candid= ates can be present during ICE restart. This also means, that in some situa= tions, even though ICE restart completes, the underlying transport does not= have to change and the same ICE candidate pair will be used after ICE rest= art. Since this is the same ICE candidate pair, it will mean that packets f= rom old and new DTLS association can be received over the same 5-tuple and = they cannot be demultiplexed. This means DTLS association should stay the s= ame even if ufrag changes due to ICE restart but when end points plans to r= e-use ICE candidates.

So, we have two situations w= hich both will result in some interop problems regardless of which decision= we will make. Taking into account that most of existing ICE with DTLS impl= ementations use ephemeral certificates, 3pcc will likely result in change o= f both ufrag and fingerprints. Because of this, I think not establishing ne= w DTLS association on ufrag change is a safer option. Which means JSEP text= is probably a safer option, especially where WebRTC is concerned.

This being said, going forward tls-id should be used to ma= ke sure this is resolved in unambiguous manner.

Re= gards,
_____________
Roman Shpo= unt
=C2=A0
--94eb2c1194da54ee2605579ac74c-- From nobody Fri Aug 25 15:47:33 2017 Return-Path: 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 E523B1321E6 for ; Fri, 25 Aug 2017 15:47:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.879 X-Spam-Level: X-Spam-Status: No, score=-1.879 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, T_SPF_HELO_PERMERROR=0.01, T_SPF_PERMERROR=0.01] autolearn=ham autolearn_force=no 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 ee49u7Vo34KI for ; Fri, 25 Aug 2017 15:47:28 -0700 (PDT) Received: from nostrum.com (raven-v6.nostrum.com [IPv6:2001:470:d:1130::1]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 525DD126BFD for ; Fri, 25 Aug 2017 15:47:28 -0700 (PDT) Received: from Svantevit.roach.at (cpe-70-122-154-80.tx.res.rr.com [70.122.154.80]) (authenticated bits=0) by nostrum.com (8.15.2/8.15.2) with ESMTPSA id v7PMlO1t082485 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NO); Fri, 25 Aug 2017 17:47:26 -0500 (CDT) (envelope-from adam@nostrum.com) X-Authentication-Warning: raven.nostrum.com: Host cpe-70-122-154-80.tx.res.rr.com [70.122.154.80] claimed to be Svantevit.roach.at To: Roman Shpount Cc: "mmusic@ietf.org" References: From: Adam Roach Message-ID: <3be5cdc3-b191-d3be-4097-2b17d5a78b7c@nostrum.com> Date: Fri, 25 Aug 2017 17:47:23 -0500 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:52.0) Gecko/20100101 Thunderbird/52.2.1 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/alternative; boundary="------------1461726FFBA51479F0213F6E" Content-Language: en-US Archived-At: Subject: Re: [MMUSIC] DTLS-SDP and JSEP Conflicts X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 25 Aug 2017 22:47:30 -0000 This is a multi-part message in MIME format. --------------1461726FFBA51479F0213F6E Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit On 8/25/17 4:39 PM, Roman Shpount wrote: > > This is a really thorny issue which does not have a good solution. > Correct handling of ufrag change is one of the main reasons why tls-id > draft was written in the first place. Here is a little bit more > background on the problem: > > 1. If ICE restart was caused by 3pcc and resulted in connection to a > new device, new DTLS association is required. In some cases, > connection to a new device will also result in the new fingerprint > set. In some cases (like transfer withing the same organization which > uses the same pre-provisioned certificate), fingerprints will stay the > same and only ufrag will change. So, this means new DTLS association > should be established if ufrag changes due to device change. > > 2. If ICE restart is initiated when new network interfaces became > available, such as when WiFi became available on the mobile device. > This means that both existing candidates and new candidates can be > present during ICE restart. This also means, that in some situations, > even though ICE restart completes, the underlying transport does not > have to change and the same ICE candidate pair will be used after ICE > restart. Since this is the same ICE candidate pair, it will mean that > packets from old and new DTLS association can be received over the > same 5-tuple and they cannot be demultiplexed. This means DTLS > association should stay the same even if ufrag changes due to ICE > restart but when end points plans to re-use ICE candidates. I hate to throw new engineering into the document at this point, but shouldn't it be possible to distinguish between these two circumstances by examining the candidates and determining whether they're completely new (versus having at least one in common with the existing connection)? This means that you won't know whether to restart DTLS until trickling has ended (for trickle), but you can solve that by not doing aggressive (or passive-aggressive) nomination -- just wait until you have all the candidates before you start connecting. Does that sound like it would work? /a --------------1461726FFBA51479F0213F6E Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 7bit
On 8/25/17 4:39 PM, Roman Shpount wrote:

This is a really thorny issue which does not have a good solution. Correct handling of ufrag change is one of the main reasons why tls-id draft was written in the first place. Here is a little bit more background on the problem:

1. If ICE restart was caused by 3pcc and resulted in connection to a new device, new DTLS association is required. In some cases, connection to a new device will also result in the new fingerprint set. In some cases (like transfer withing the same organization which uses the same pre-provisioned certificate), fingerprints will stay the same and only ufrag will change. So, this means new DTLS association should be established if ufrag changes due to device change.

2. If ICE restart is initiated when new network interfaces became available, such as when WiFi became available on the mobile device. This means that both existing candidates and new candidates can be present during ICE restart. This also means, that in some situations, even though ICE restart completes, the underlying transport does not have to change and the same ICE candidate pair will be used after ICE restart. Since this is the same ICE candidate pair, it will mean that packets from old and new DTLS association can be received over the same 5-tuple and they cannot be demultiplexed. This means DTLS association should stay the same even if ufrag changes due to ICE restart but when end points plans to re-use ICE candidates.

I hate to throw new engineering into the document at this point, but shouldn't it be possible to distinguish between these two circumstances by examining the candidates and determining whether they're completely new (versus having at least one in common with the existing connection)? This means that you won't know whether to restart DTLS until trickling has ended (for trickle), but you can solve that by not doing aggressive (or passive-aggressive) nomination -- just wait until you have all the candidates before you start connecting.

Does that sound like it would work?

/a
--------------1461726FFBA51479F0213F6E-- From nobody Fri Aug 25 16:23:13 2017 Return-Path: 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 B7DC7132C74 for ; Fri, 25 Aug 2017 16:23:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.388 X-Spam-Level: X-Spam-Status: No, score=-1.388 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_SORBS_SPAM=0.5, T_SPF_PERMERROR=0.01, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=telurix-com.20150623.gappssmtp.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 VW5EKFDe8quA for ; Fri, 25 Aug 2017 16:23:10 -0700 (PDT) Received: from mail-pg0-x233.google.com (mail-pg0-x233.google.com [IPv6:2607:f8b0:400e:c05::233]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 979E3132C7F for ; Fri, 25 Aug 2017 16:23:10 -0700 (PDT) Received: by mail-pg0-x233.google.com with SMTP id t3so6324817pgt.0 for ; Fri, 25 Aug 2017 16:23:10 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=telurix-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=7hBnHGzxw5k3/IiWqsLltiOhpLStZcgyVY62x15W0VY=; b=wCvlHWVhcyi9NFOG1Da5b8oE6UoGcsMbLjfHQQ1EoXg1oTJQwj9WWdz1tvNLfGXqdQ S/m0i6W0RFOS2Q4y1iETgOv64yJStPuA13ZKp+W0G+TAfNHGaPBmIww1A9UjSOaoYAhx ldaYTaOnJP/3CEWbTbbY2ozo1P+FrXx3cjQENORgrrGYIN4l7Ah8/RwXTcVnIm6eyBEE r0vcedDJu/b3cnkhxKorCUNwBUrRP0DAUpbDy4Z7hMpF0Jy13bL90hC45ofcwQF5ZJ0b wER2LIXBrpmHcVU9GFsMcOAVfiXG9a+35ut9HmKTw1vK2cOmrfmj5i/9PXI4SBA88glj Z7Iw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=7hBnHGzxw5k3/IiWqsLltiOhpLStZcgyVY62x15W0VY=; b=c2ZqicWxfKwc1K3yEL2OwuKU8cjLE1jHCj9H1N8zyQkXeluMZrqGJoNjFAFc4X3yrQ LW3v+t8z1PW8N4fcGSjcpwWsv6JANJ+QhNn9wLu/T7Dbas7GdUQIT586vuUcCGV24D83 cJlWuunZu0qMEmCg2sdcKrB+zp7ZEwaPaqkDVa+bAvMImgYBwL3Z5KJb6VU18gyjaBvc k9fOU4z7o3qp/pNDUZp5FiUjii1FOGfec0ctim5oPdlQ2/Jske77qkdzGQLuZinXXMbg jSdX+pLxN7h2Ca9w1XLC0T27a3FZu+SyBJO2rFQJaKYZWvli7hab+ybJGavkf8opJVL7 Se6A== X-Gm-Message-State: AHYfb5i990AC/47QyPfXVoCk+mcj1NZD9SIeWY/h2Ry3RdGDa/I4yNvs imaN+ctRwUn9aoSnMdg= X-Received: by 10.98.178.144 with SMTP id z16mr104830pfl.282.1503703389700; Fri, 25 Aug 2017 16:23:09 -0700 (PDT) Received: from mail-pg0-f45.google.com (mail-pg0-f45.google.com. [74.125.83.45]) by smtp.gmail.com with ESMTPSA id u26sm13546753pfi.140.2017.08.25.16.23.08 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 25 Aug 2017 16:23:09 -0700 (PDT) Received: by mail-pg0-f45.google.com with SMTP id r133so6228852pgr.3 for ; Fri, 25 Aug 2017 16:23:08 -0700 (PDT) X-Received: by 10.99.36.134 with SMTP id k128mr78187pgk.413.1503703388689; Fri, 25 Aug 2017 16:23:08 -0700 (PDT) MIME-Version: 1.0 Received: by 10.100.191.8 with HTTP; Fri, 25 Aug 2017 16:23:08 -0700 (PDT) In-Reply-To: <3be5cdc3-b191-d3be-4097-2b17d5a78b7c@nostrum.com> References: <3be5cdc3-b191-d3be-4097-2b17d5a78b7c@nostrum.com> From: Roman Shpount Date: Fri, 25 Aug 2017 19:23:08 -0400 X-Gmail-Original-Message-ID: Message-ID: To: Adam Roach Cc: "mmusic@ietf.org" Content-Type: multipart/alternative; boundary="94eb2c031c9c549ccf05579c3a36" Archived-At: Subject: Re: [MMUSIC] DTLS-SDP and JSEP Conflicts X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 25 Aug 2017 23:23:13 -0000 --94eb2c031c9c549ccf05579c3a36 Content-Type: text/plain; charset="UTF-8" On Fri, Aug 25, 2017 at 6:47 PM, Adam Roach wrote: > On 8/25/17 4:39 PM, Roman Shpount wrote: > > > This is a really thorny issue which does not have a good solution. Correct > handling of ufrag change is one of the main reasons why tls-id draft was > written in the first place. Here is a little bit more background on the > problem: > > 1. If ICE restart was caused by 3pcc and resulted in connection to a new > device, new DTLS association is required. In some cases, connection to a > new device will also result in the new fingerprint set. In some cases (like > transfer withing the same organization which uses the same pre-provisioned > certificate), fingerprints will stay the same and only ufrag will change. > So, this means new DTLS association should be established if ufrag changes > due to device change. > > 2. If ICE restart is initiated when new network interfaces became > available, such as when WiFi became available on the mobile device. This > means that both existing candidates and new candidates can be present > during ICE restart. This also means, that in some situations, even though > ICE restart completes, the underlying transport does not have to change and > the same ICE candidate pair will be used after ICE restart. Since this is > the same ICE candidate pair, it will mean that packets from old and new > DTLS association can be received over the same 5-tuple and they cannot be > demultiplexed. This means DTLS association should stay the same even if > ufrag changes due to ICE restart but when end points plans to re-use ICE > candidates. > > > I hate to throw new engineering into the document at this point, but > shouldn't it be possible to distinguish between these two circumstances by > examining the candidates and determining whether they're completely new > (versus having at least one in common with the existing connection)? This > means that you won't know whether to restart DTLS until trickling has ended > (for trickle), but you can solve that by not doing aggressive (or > passive-aggressive) nomination -- just wait until you have all the > candidates before you start connecting. > > Does that sound like it would work? > This will theoretically work, but can delay DTLS association setup in case of tricket ICE past the point of being usable. More importantly this is not how existing implementations work. They simply do not start new DTLS association on ufrag change. This is for legacy interop only, so we might as well do what legacy end points do and ignore ufrag. Regards, _____________ Roman Shpount --94eb2c031c9c549ccf05579c3a36 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
On Fri, Aug 25, 2017 at 6:47 PM, Adam Roach <adam@nostrum.com><= /span> wrote:
=20 =20 =20
On 8/25/17 4= :39 PM, Roman Shpount wrote:

This is a really thorny issue which does not have a good solution. Correct handling of ufrag change is one of the main reasons why tls-id draft was written in the first place. Here is a little bit more background on the problem:

1. If ICE restart was caused by 3pcc and resulted in connection to a new device, new DTLS association is required. In some cases, connection to a new device will also result in the new fingerprint set. In some cases (like transfer withing the same organization which uses the same pre-provisioned certificate), fingerprints will stay the same and only ufrag will change. So, this means new DTLS association should be established if ufrag changes due to device change.

2. If ICE restart is initiated when new network interfaces became available, such as when WiFi became available on the mobile device. This means that both existing candidates and new candidates can be present during ICE restart. This also means, that in some situations, even though ICE restart completes, the underlying transport does not have to change and the same ICE candidate pair will be used after ICE restart. Since this is the same ICE candidate pair, it will mean that packets from old and new DTLS association can be received over the same 5-tuple and they cannot be demultiplexed. This means DTLS association should stay the same even if ufrag changes due to ICE restart but when end points plans to re-use ICE candidates.

 I hate to throw new engineering into the document at this point, but shouldn't it be possible to distinguish between these two circumstances by examining the candidates and determining whether they're completely new (versus having at least one in common with the existing connection)? This means that you won't know whether to restart DTLS until trickling has ended (for trickle), but you can solve that by not doing aggressive (or passive-aggressive) nomination -- just wait until you have all the candidates before you start connecting.

Does that sound like it would work?

This will theoretically work, but can delay DTLS association setup in ca= se of tricket ICE past the point of being usable.

= More importantly this is not how existing implementations work. They simply= do not start new DTLS association on ufrag change. This is for legacy inte= rop only, so we might as well do what legacy end points do and ignore ufrag= .

Regards,
_____________
Roman Shpount
=C2=A0
--94eb2c031c9c549ccf05579c3a36-- From nobody Fri Aug 25 16:28:31 2017 Return-Path: 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 1DB53132C7D for ; Fri, 25 Aug 2017 16:28:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.88 X-Spam-Level: X-Spam-Status: No, score=-1.88 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, T_SPF_HELO_PERMERROR=0.01, T_SPF_PERMERROR=0.01] autolearn=ham autolearn_force=no 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 apJ21UE6ZNhU for ; Fri, 25 Aug 2017 16:28:27 -0700 (PDT) Received: from nostrum.com (raven-v6.nostrum.com [IPv6:2001:470:d:1130::1]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 297E6132716 for ; Fri, 25 Aug 2017 16:28:27 -0700 (PDT) Received: from Svantevit.roach.at (cpe-70-122-154-80.tx.res.rr.com [70.122.154.80]) (authenticated bits=0) by nostrum.com (8.15.2/8.15.2) with ESMTPSA id v7PNSPU8089283 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NO); Fri, 25 Aug 2017 18:28:26 -0500 (CDT) (envelope-from adam@nostrum.com) X-Authentication-Warning: raven.nostrum.com: Host cpe-70-122-154-80.tx.res.rr.com [70.122.154.80] claimed to be Svantevit.roach.at To: Roman Shpount Cc: "mmusic@ietf.org" References: <3be5cdc3-b191-d3be-4097-2b17d5a78b7c@nostrum.com> From: Adam Roach Message-ID: Date: Fri, 25 Aug 2017 18:28:25 -0500 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:52.0) Gecko/20100101 Thunderbird/52.2.1 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Content-Language: en-US Archived-At: Subject: Re: [MMUSIC] DTLS-SDP and JSEP Conflicts X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 25 Aug 2017 23:28:30 -0000 On 8/25/17 6:23 PM, Roman Shpount wrote: > More importantly this is not how existing implementations work. They > simply do not start new DTLS association on ufrag change. This is for > legacy interop only, so we might as well do what legacy end points do > and ignore ufrag. This seems pretty compelling, as arguments go. /a From nobody Fri Aug 25 16:32:16 2017 Return-Path: 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 50C8C13243A for ; Fri, 25 Aug 2017 16:32:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, 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=google.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 QTZ2YaxJ7tOM for ; Fri, 25 Aug 2017 16:32:13 -0700 (PDT) Received: from mail-wr0-x22b.google.com (mail-wr0-x22b.google.com [IPv6:2a00:1450:400c:c0c::22b]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3EC3D13219C for ; Fri, 25 Aug 2017 16:32:13 -0700 (PDT) Received: by mail-wr0-x22b.google.com with SMTP id o76so3336155wrb.5 for ; Fri, 25 Aug 2017 16:32:13 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=peyYtEAYOs4U/5AjLJIKBI587SK8XKDhdu7BuBvH+qg=; b=fi2O4ZRZ4Z/6Nf3lf8+IqwPD7abu5Z66GNEer8hsGACQ7KmNe7PPr7kzIVGF5s1reO XC+XBibj3Q0vBNS1iiH2CCce1hyBbuxp+tghqtYZqwxB7Jxh6zOkM5tHAOaVCs825iZH Sis0pee80Qen03Z1uKm0PZeW1X41U0VVgN7M0FhnS0w+h7Joi56PWRbIBoj8afgzEcQv G4q4dd+iiUuFo5brvNpq4R5rM6/znePctyg5q/HHzyE1fL86D1S8bZuyTmi1qBgsCa6M uvKoheAn2duzUYEL7Xezuj1u98GiyccT9YeEG9Lv7tnr0+eJ4QsO/lGZ8myrDZpJg2CA x08g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=peyYtEAYOs4U/5AjLJIKBI587SK8XKDhdu7BuBvH+qg=; b=oVzZMF+seHEmuQwLla6vkkK9J+tco8PqiJ344toxWRCgSutALhROAl8oaHPoHZuy+N U2gWFWKv9f3/J7D71bwD8vy9swU4qhpJ1FDUH9xlyRzJu5OklHymHNXrgNO/IDofIyla 6IUcjPObKJQWPtIUoGKZ5+JNEOSzlF4pMsRTcoKxkJW6KB0ScZb7mmrqBUBjC6U/GJvW rjFNAjaY5KK87zTR9QgxJRI5/txbX6+u0jAV50Fdlk/VGy3MoVu5+tOO5gWXeIF0BpiQ Wen8whhhf2xRthapIVompBgCcV4tRYPmiZLKvPHP9jVPna293STmTpMVSX6ON+g45CGq enBQ== X-Gm-Message-State: AHYfb5jOuYEs3yjfnCIg5OrekCOK4f9QcV4DZWc1za16uqTURpTxTj9N fa0H8h8TYKwRF+To0ufl3B+EQV4tZ/Ls X-Google-Smtp-Source: ADKCNb5vb0+7NuGVLeOPWc0f6UgB0I8rlb/f38klJMX7/7ldjK3Z87/wYbuo0kgXG/Aaz4rlNrpP3QiUkAhZQQdr8Ak= X-Received: by 10.223.134.189 with SMTP id 58mr51127wrx.157.1503703931537; Fri, 25 Aug 2017 16:32:11 -0700 (PDT) MIME-Version: 1.0 Received: by 10.223.130.229 with HTTP; Fri, 25 Aug 2017 16:32:10 -0700 (PDT) In-Reply-To: References: <3be5cdc3-b191-d3be-4097-2b17d5a78b7c@nostrum.com> From: Taylor Brandstetter Date: Fri, 25 Aug 2017 16:32:10 -0700 Message-ID: To: Adam Roach Cc: Roman Shpount , "mmusic@ietf.org" Content-Type: multipart/alternative; boundary="001a1146c5c6b02b0305579c5a62" Archived-At: Subject: Re: [MMUSIC] DTLS-SDP and JSEP Conflicts X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 25 Aug 2017 23:32:15 -0000 --001a1146c5c6b02b0305579c5a62 Content-Type: text/plain; charset="UTF-8" I think I'm just echoing Roman at this point, but might as well send the email since I already wrote it. > (Issue 1c) The crux of the matter: does ICE restart cause DTLS to > restart? The primary rationale outlined in RFC5245 for restarting ICE is > changing the destination (IP address or port) of an ongoing media stream -- > which would commonly involve changing to a different physical device. The purpose of section 4 is to describe what should happen for an "existing implementation that has not been updated to support the 'tls-id' attribute", correct? And existing WebRTC implementations do *not* create a new DTLS association upon ICE restarts. In my experience, ICE restarts are mostly used to restore connectivity when network interfaces change, not to transfer a call to a new endpoint. So I'd say the "ICE ufrag value" bullet in section 4 should be removed. I hate to throw new engineering into the document at this point, but > shouldn't it be possible to distinguish between these two circumstances by > examining the candidates and determining whether they're completely new > (versus having at least one in common with the existing connection)? This > means that you won't know whether to restart DTLS until trickling has > ended (for trickle), but you can solve that by not doing aggressive (or > passive-aggressive) nomination -- just wait until you have all the > candidates before you start connecting. > > Does that sound like it would work? If I understand correctly, you're saying "wait until trickling has ended, and use a new DTLS association if the list of candidates is completely new, and old association if it contains an old candidate"? That doesn't work for a couple reasons: 1. The list may be completely new, but the endpoint may still want to use the existing DTLS association. This is what existing WebRTC implementations do. They continue sending media over the old candidate pair while they're doing an ICE restart, but they don't trickle the old candidate again. 2. It could take a long time to tell that trickling ended, which would delay media. It would defeat a large part of the benefit of trickle ICE. On Fri, Aug 25, 2017 at 4:28 PM, Adam Roach wrote: > On 8/25/17 6:23 PM, Roman Shpount wrote: > >> More importantly this is not how existing implementations work. They >> simply do not start new DTLS association on ufrag change. This is for >> legacy interop only, so we might as well do what legacy end points do and >> ignore ufrag. >> > > > This seems pretty compelling, as arguments go. > > /a > > _______________________________________________ > mmusic mailing list > mmusic@ietf.org > https://www.ietf.org/mailman/listinfo/mmusic > --001a1146c5c6b02b0305579c5a62 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
I think I'm just echoing Roman at this point, but= might as well send the email since I already wrote it.
=C2=A0
(Issue 1c) The crux of the matter: does ICE restart cause=C2=A0<= /span>DTLS=C2=A0to restart? The primary rationale outlined= in RFC5245 for restarting ICE is changing the destination (IP address or p= ort) of an ongoing media stream -- which would commonly involve changing to= a different physical device.

The pu= rpose of section 4 is to describe what should happen for an "existing = implementation that has not been updated to support the 'tls-id' at= tribute", correct? And existing WebRTC implementations do=C2=A0not<= /i>=C2=A0create a new DTLS association upon ICE restarts. In my experience,= ICE restarts are mostly used to restore connectivity when network interfac= es change, not to transfer a call to a new endpoint. So I'd say the &qu= ot;ICE ufrag value" bullet in section 4 should be removed.
<= br>
I hate to throw new engineering into th= e document at this point, but shouldn't it be possible to distinguish b= etween these two circumstances by examining the candidates and determining = whether they're completely new (versus having at least one in common wi= th the existing connection)? This means that you won't know whether to = restart=C2=A0DTLS=C2=A0until trickling has ended (for trickle), but you can solve that b= y not doing aggressive (or passive-aggressive) nomination -- just wait unti= l you have all the candidates before you start connecting.

Does th= at sound like it would work?

If I un= derstand correctly, you're saying "wait until trickling has ended,= and use a new DTLS association if the list of candidates is completely new= , and old association if it contains an old candidate"? That doesn'= ;t work for a couple reasons:
  1. The list may be completely = new, but the endpoint may still want to use the existing DTLS association. = This is what existing WebRTC implementations do. They continue sending medi= a over the old candidate pair while they're doing an ICE restart, but t= hey don't trickle the old candidate again.
  2. It could take a = long time to tell that trickling ended, which would delay media. It would d= efeat a large part of the benefit of trickle ICE.

On Fri, Aug 25, 2017 = at 4:28 PM, Adam Roach <adam@nostrum.com> wrote:
On 8/25/17 6:23 PM, Roman Shpount wr= ote:
More importantly this is not how existing implementations work. They simply= do not start new DTLS association on ufrag change. This is for legacy inte= rop only, so we might as well do what legacy end points do and ignore ufrag= .


 This seems pretty compelling, as arguments go.

/a

_______________________________________________
mmusic mailing list
mmusic@ietf.org https://www.ietf.org/mailman/listinfo/mmusic

--001a1146c5c6b02b0305579c5a62-- From nobody Sun Aug 27 23:49:33 2017 Return-Path: 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 BD25E1329B4 for ; Sun, 27 Aug 2017 23:49:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.221 X-Spam-Level: X-Spam-Status: No, score=-4.221 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=ham autolearn_force=no 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 c2gDY8ibMYYz for ; Sun, 27 Aug 2017 23:49:30 -0700 (PDT) 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 9CFC01329BF for ; Sun, 27 Aug 2017 23:49:28 -0700 (PDT) X-AuditID: c1b4fb2d-11bff700000057a4-4a-59a3bcf6deb5 Received: from ESESSHC020.ericsson.se (Unknown_Domain [153.88.183.78]) by sessmg23.ericsson.net (Symantec Mail Security) with SMTP id 77.47.22436.6FCB3A95; Mon, 28 Aug 2017 08:49:26 +0200 (CEST) Received: from ESESSMB109.ericsson.se ([169.254.9.194]) by ESESSHC020.ericsson.se ([153.88.183.78]) with mapi id 14.03.0352.000; Mon, 28 Aug 2017 08:49:26 +0200 From: Christer Holmberg To: Adam Roach , "mmusic@ietf.org" Thread-Topic: [MMUSIC] DTLS-SDP and JSEP Conflicts Thread-Index: AQHTHeD9eWXjhOvP60up2QfAnU62xaKZac6A Date: Mon, 28 Aug 2017 06:49:26 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.7.4.170508 x-originating-ip: [153.88.183.17] Content-Type: text/plain; charset="us-ascii" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFupnkeLIzCtJLcpLzFFi42KZGbHdT/fbnsWRBht3m1ns+buI3WLq8scs DkweS5b8ZPKYtfMJSwBTFJdNSmpOZllqkb5dAlfGz+2zWAv62CoWHp/P1sD4nqWLkZNDQsBE ov/0KrYuRi4OIYEjjBK/Pl9mhXCWMEq8e9DO1MXIwcEmYCHR/U8bxBQRcJOYdyodxBQWMJQ4 cQZsjIiAkcTl4w+YYewvUz4xgtgsAqoSR46vZAEp5xWwljg5Mw0kLCRgJ3HmzhtWEJtTwF5i 8tQT7CA2o4CYxPdTa5hAbGYBcYlbT+YzQVwpILFkz3lmCFtU4uXjf6wgI0UF9CTe7fcEMSUE FCWW98tBdOpILNj9iQ3CtpaYvLSRHcLWlli28DXYFF4BQaBjnrBMYBSbhWTZLCTts5C0z0LS PgtJ+wJG1lWMosWpxcW56UbGeqlFmcnFxfl5enmpJZsYgdF0cMtv3R2Mq187HmIU4GBU4uF1 WLM4Uog1say4MvcQowQHs5IIb8cuoBBvSmJlVWpRfnxRaU5q8SFGaQ4WJXFeh30XIoQE0hNL UrNTUwtSi2CyTBycUg2MvgtYa/L51KWZozvU/7QoBhgIeJ65tMCxhL1onuihs4233jVuC7lj ken8sTL1/PED8reP7Mi8++VBt/66a62bp1k/Yl/RLeCT0MWScPP1JMN3ugtOlmfWXrxazbf1 u3TswTs+rLfTpkxxfsUx94/Ozt/hRq82iPAa7JZYHfgjSmaz73MpK4kXSizFGYmGWsxFxYkA GVWNzaICAAA= Archived-At: Subject: Re: [MMUSIC] DTLS-SDP and JSEP Conflicts X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 28 Aug 2017 06:49:32 -0000 Hi, >Issue 2 (quoting EKR): > >2. S 4 says: > > The mux category [I-D.ietf-mmusic-sdp-mux-attributes] for the 'tls- > id' attribute is 'IDENTICAL', which means that the attribute value > must be identical across all media descriptions being multiplexed > [I-D.ietf-mmusic-sdp-bundle-negotiation]. > >This is not actually what JSEP requires: > > different categories. To avoid unnecessary duplication when > bundling, attributes of category IDENTICAL or TRANSPORT MUST NOT be > repeated in bundled m=3D sections, repeating the guidance from > [I-D.ietf-mmusic-sdp-bundle-negotiation], Section 8.1. This includes > >I suspect this is old text. Correct, and it has been fixed in the IESG-review PR I have submitted. Regards, Christer From nobody Mon Aug 28 00:10:46 2017 Return-Path: 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 7C87A132C60 for ; Mon, 28 Aug 2017 00:10:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.221 X-Spam-Level: X-Spam-Status: No, score=-4.221 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=ham autolearn_force=no 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 ZZQVHzNo23oe for ; Mon, 28 Aug 2017 00:10:42 -0700 (PDT) Received: from sessmg22.ericsson.net (sessmg22.ericsson.net [193.180.251.58]) (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 3D82D132C5F for ; Mon, 28 Aug 2017 00:10:42 -0700 (PDT) X-AuditID: c1b4fb3a-5ffff700000051a3-a2-59a3c1f094bd Received: from ESESSHC005.ericsson.se (Unknown_Domain [153.88.183.33]) by sessmg22.ericsson.net (Symantec Mail Security) with SMTP id D2.B7.20899.0F1C3A95; Mon, 28 Aug 2017 09:10:40 +0200 (CEST) Received: from ESESSMB109.ericsson.se ([169.254.9.194]) by ESESSHC005.ericsson.se ([153.88.183.33]) with mapi id 14.03.0352.000; Mon, 28 Aug 2017 09:10:39 +0200 From: Christer Holmberg To: Taylor Brandstetter , Adam Roach CC: "mmusic@ietf.org" Thread-Topic: [MMUSIC] DTLS-SDP and JSEP Conflicts Thread-Index: AQHTHeD9eWXjhOvP60up2QfAnU62xaKVd/KAgAATAICAAAn9AIAAAXqAgAABDACAA9hHAA== Date: Mon, 28 Aug 2017 07:10:39 +0000 Message-ID: References: <3be5cdc3-b191-d3be-4097-2b17d5a78b7c@nostrum.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.7.4.170508 x-originating-ip: [153.88.183.146] Content-Type: text/plain; charset="iso-8859-1" Content-ID: <3B8B4813428CEB4CB0A72701F6DFEF5B@ericsson.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFlrOIsWRmVeSWpSXmKPExsUyM2K7ou6Hg4sjDTq+yljs+buI3eLyioes FlOXP2ZxYPZYsKnUY8mSn0wes3Y+YQlgjuKySUnNySxLLdK3S+DK6D9zi7XgvFzFtIZe5gbG oxJdjJwcEgImEnOnLmLpYuTiEBI4wihx+eFEZghnCaPE4WPXmboYOTjYBCwkuv9pgzSICPhI rLx3BCzMLKAucXVxEIgpLGAoceIMC0SFkcTl4w+YIewwiV33Z4DFWQRUJc5cPsoKYvMKWEtM 7fvBBrHpL5NE29v9YEWcAoESc3tngxUxCohJfD+1hgnEZhYQl7j1ZD4TxM0CEkv2nGeGsEUl Xj7+xwpyg6iAnsS7/Z4QYSWJHxsusUC06kncmDqFDcK2ltj8ZgrUSG2JZQtfM0PcIyhxcuYT lgmM4rOQbJuFpH0WkvZZSNpnIWlfwMi6ilG0OLW4ODfdyEgvtSgzubg4P08vL7VkEyMw+g5u +W21g/Hgc8dDjAIcjEo8vBprFkcKsSaWFVfmHmKU4GBWEuG13Q8U4k1JrKxKLcqPLyrNSS0+ xCjNwaIkzuuw70KEkEB6YklqdmpqQWoRTJaJg1OqgTH73s/w+dt/fNavnnFb9s7p9wXrPwuJ Sz008owp2c+r+yjga87ydz0r8su+WE3coXvK/WV3+flVcYxnXryIU/ToNdsaoCbW2nm4i9Ek 7O5Jnk2W3oUCWzYnBH6r3dL9zUbimp50tPKX0o037Hc+U92962v1929NRerLZbIq237vnDn1 2v1npfZKLMUZiYZazEXFiQDwlM75ugIAAA== Archived-At: Subject: Re: [MMUSIC] DTLS-SDP and JSEP Conflicts X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 28 Aug 2017 07:10:44 -0000 Hi, So, does anyone *OBJECT* to the remove-ufrag-from-section-4 proposal? I assume Justin and Cullen would be ok with it, since it is what JSEP does, but it would still be nice to hear them say that :) I assume we could still keep section 3.3, but we should remove the =B3(see Section 4)=B2 part. Because, section 3.3 does not say that a ufrag change triggers a new DTLS association, it simply says that if one changes the ufrag AND wants to create a new DTLS association, the tls-id must be changed. We could also clarify section 3.3: "If an endpoint uses ICE, and modifies a local ufrag value, and if the modification requires a new DTLS association, the endpoint MUST change its local SDP 'tls-id' attribute value, as a modification of=20 the local ufrag value does not itself trigger a new DTLS association " Regards, Christer From: mmusic on behalf of Taylor Brandstetter Date: Saturday 26 August 2017 at 02:32 To: "adam@nostrum.com" Cc: "mmusic@ietf.org" Subject: Re: [MMUSIC] DTLS-SDP and JSEP Conflicts I think I'm just echoing Roman at this point, but might as well send the email since I already wrote it. =20 (Issue 1c) The crux of the matter: does ICE restart cause DTLS to restart? The primary rationale outlined in RFC5245 for restarting ICE is changing the destination (IP address or port) of an ongoing media stream -- which would commonly involve changing to a different physical device. The purpose of section 4 is to describe what should happen for an "existing implementation that has not been updated to support the 'tls-id' attribute", correct? And existing WebRTC implementations do not create a new DTLS association upon ICE restarts. In my experience, ICE restarts are mostly used to restore connectivity when network interfaces change, not to transfer a call to a new endpoint. So I'd say the "ICE ufrag value" bullet in section 4 should be removed. I hate to throw new engineering into the document at this point, but shouldn't it be possible to distinguish between these two circumstances by examining the candidates and determining whether they're completely new (versus having at least one in common with the existing connection)? This means that you won't know whether to restart DTLS until trickling has ended (for trickle), but you can solve that by not doing aggressive (or passive-aggressive) nomination -- just wait until you have all the candidates before you start connecting. Does that sound like it would work? If I understand correctly, you're saying "wait until trickling has ended, and use a new DTLS association if the list of candidates is completely new, and old association if it contains an old candidate"? That doesn't work for a couple reasons: 1. The list may be completely new, but the endpoint may still want to use the existing DTLS association. This is what existing WebRTC implementations do. They continue sending media over the old candidate pair while they're doing an ICE restart, but they don't trickle the old candidate again. 2. It could take a long time to tell that trickling ended, which would delay media. It would defeat a large part of the benefit of trickle ICE. On Fri, Aug 25, 2017 at 4:28 PM, Adam Roach wrote: On 8/25/17 6:23 PM, Roman Shpount wrote: More importantly this is not how existing implementations work. They simply do not start new DTLS association on ufrag change. This is for legacy interop only, so we might as well do what legacy end points do and ignore ufrag. This seems pretty compelling, as arguments go. /a _______________________________________________ mmusic mailing list mmusic@ietf.org https://www.ietf.org/mailman/listinfo/mmusic From nobody Mon Aug 28 02:50:39 2017 Return-Path: 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 837ED132811; Mon, 28 Aug 2017 02:50:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.221 X-Spam-Level: X-Spam-Status: No, score=-4.221 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=ham autolearn_force=no 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 dOsSaRxOw4bA; Mon, 28 Aug 2017 02:50:29 -0700 (PDT) Received: from sesbmg22.ericsson.net (sesbmg22.ericsson.net [193.180.251.48]) (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 C3F391201F8; Mon, 28 Aug 2017 02:50:28 -0700 (PDT) X-AuditID: c1b4fb30-597ff70000005897-54-59a3e762f205 Received: from ESESSHC003.ericsson.se (Unknown_Domain [153.88.183.27]) by sesbmg22.ericsson.net (Symantec Mail Security) with SMTP id B8.80.22679.267E3A95; Mon, 28 Aug 2017 11:50:26 +0200 (CEST) Received: from ESESSMB109.ericsson.se ([169.254.9.194]) by ESESSHC003.ericsson.se ([153.88.183.27]) with mapi id 14.03.0352.000; Mon, 28 Aug 2017 11:50:26 +0200 From: Christer Holmberg To: Christer Holmberg , Adam Roach , Ben Campbell CC: "draft-ietf-mmusic-dtls-sdp@ietf.org" , "mmusic-chairs@ietf.org" , "mmusic@ietf.org" , "Flemming Andreasen" , The IESG Thread-Topic: Adam Roach's No Objection on draft-ietf-mmusic-dtls-sdp-28: (with COMMENT) Thread-Index: AQHTF6uY+fnArxR5YU+2MrlLLf27GqKRybkAgABhHACAAYaTgIAAAUUAgAACz4CAAA4TgIABYdMAgASDaAA= Date: Mon, 28 Aug 2017 09:50:25 +0000 Message-ID: References: <150301038555.14103.1567567703984434290.idtracker@ietfa.amsl.com> <8EB6BD4A-26A9-4F98-A57A-FCCFC3F6AC97@nostrum.com> <9cdb8f3b-eb9b-f478-ecb0-2095cdba2484@nostrum.com> <83BCB0B5-0F74-43A2-9EF1-1D04EF4F9A0E@nostrum.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.7.4.170508 x-originating-ip: [153.88.183.147] Content-Type: text/plain; charset="euc-kr" Content-ID: <89C1D8F592FECB4CAC4DFE023B8FD775@ericsson.com> Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFtrLIsWRmVeSWpSXmKPExsUyM2K7tG7S88WRBks+WFjs+buI3WJ+52l2 i/8T57NavL+gazHjz0Rmi/M71zNZTF3+mMWB3WPK742sHkuW/GTymLXzCUsAcxSXTUpqTmZZ apG+XQJXxtTnvxkLpklVfOrfzNzAeECyi5GTQ0LARKJh2kLGLkYuDiGBI4wSl6dPYIZwljBK XHzyjK2LkYODTcBCovufNkiDiEC5xI95P9lBapgFPjFK/Fy/hBUkISwQKXHyQSsjRFGUxLPn c6DsJImDXafBbBYBVYk5q1exgNi8AtYSO34egNq8i1li3uT3TCAJTgEbiSOfn4EVMQqISXw/ tQYsziwgLnHryXwmiLMFJJbsOc8MYYtKvHz8jxXkUFEBPYl3+z1BTAkBJYlpW9MgOrUkvvzY xwZhW0u8utQINVFRYkr3Q3aIcwQlTs58wjKBUXwWkmWzkLTPQtI+C0n7LCTtCxhZVzGKFqcW J+WmGxnppRZlJhcX5+fp5aWWbGIERurBLb8NdjC+fO54iFGAg1GJhzf72eJIIdbEsuLK3EOM EhzMSiK8r58AhXhTEiurUovy44tKc1KLDzFKc7AoifM67rsQISSQnliSmp2aWpBaBJNl4uCU amCcJdG1/ci7hCfK+qHqR523be8+yH5w2X7TgsMzNQrCOCv+u3RfsS/uYz/5WnfPZafnJTws H9blHb0zwXRPvKGu3RWFlWq+EpePFM/r4d+S0rWJe66PQe6jRToOLbKaVmuEnnjHfXmyhOlO i03Kmmu9jZYv5vlU3ZOZv1pXsKgz9ENSh/DPH41KLMUZiYZazEXFiQArwOEE0AIAAA== Archived-At: Subject: Re: [MMUSIC] Adam Roach's No Objection on draft-ietf-mmusic-dtls-sdp-28: (with COMMENT) X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 28 Aug 2017 09:50:32 -0000 SGksDQoNClBSIGhhcyBiZWVuIHVwZGF0ZWQgd2l0aCB0aGUgbmV3IHRpdGxlLg0KDQpSZWdhcmRz LA0KDQpDaHJpc3Rlcg0KDQoNCk9uIDI1LzA4LzE3IDE1OjU1LCAiQ2hyaXN0ZXIgSG9sbWJlcmci IDxjaHJpc3Rlci5ob2xtYmVyZ0Blcmljc3Nvbi5jb20+DQp3cm90ZToNCg0KPkhpLA0KPg0KPg0K Pk9uIDI0LzA4LzE3IDIxOjUzLCAiQWRhbSBSb2FjaCIgPGFkYW1Abm9zdHJ1bS5jb20+IHdyb3Rl Og0KPg0KPj5PbiA4LzI0LzE3IDEzOjAyLCBCZW4gQ2FtcGJlbGwgd3JvdGU6DQo+Pj4+IE9uIEF1 ZyAyNCwgMjAxNywgYXQgMTI6NTIgUE0sIEFkYW0gUm9hY2ggPGFkYW1Abm9zdHJ1bS5jb20+IHdy b3RlOg0KPj4+Pg0KPj4+PiBPbiA4LzI0LzE3IDEyOjQ4LCBCZW4gQ2FtcGJlbGwgd3JvdGU6DQo+ Pj4+Pj4gT24gQXVnIDIzLCAyMDE3LCBhdCAxOjMwIFBNLCBBZGFtIFJvYWNoIDxhZGFtQG5vc3Ry dW0uY29tPiB3cm90ZToNCj4+Pj4+Pg0KPj4+Pj4+IE9uIDgvMjMvMTcgMDQ6MzgsIENocmlzdGVy IEhvbG1iZXJnIHdyb3RlOg0KPj4+Pj4+Pj4gSSB3b3VsZCB0aGluayB0aGUgbG9uZy1mb3JtIHRp dGxlIG9mIHRoaXMgZG9jdW1lbnQgc2hvdWxkIGluY2x1ZGUNCj4+Pj4+Pj4+IlRMUywiDQo+Pj4+ Pj4+PiB0bw0KPj4+Pj4+Pj4gcmVmbGVjdCB0aGF0IGl0IGFsc28gY29udGFpbnMgVExTLXJlbGF0 ZWQgcHJvY2VkdXJlcy4NCj4+Pj4+Pj4gVGhlIGlzc3VlIGlzIHRoYXQgdGhlIGRvY3VtZW50IGRv ZXNuqfZ0IHJlYWxseSBkZWZpbmUgdGhlIE8vQQ0KPj4+Pj4+PnByb2NlZHVyZXMNCj4+Pj4+Pj4g Zm9yIFRMUy4gSXQgc2ltcGx5IGFkZHMgdGhlIHVzYWdlIG9mIHRoZSB0bHMtaWQgYXR0cmlidXRl IHRvIHRoZQ0KPj4+Pj4+PmV4aXN0aW5nDQo+Pj4+Pj4+IHByb2NlZHVyZXMgZGVmaW5lZCBlbHNl d2hlcmUuDQo+Pj4+Pj4gUmlnaHQsIHNvIG1ha2UgdGhhdCBjbGVhci4gSSBub3RlIHRoYXQgc2lt cGx5IGFkZGluZyAiYW5kDQo+Pj4+Pj5JZGVudGlmaWNhdGlvbiBvZiBUTFMgQ29ubmVjdGlvbnMi IHRvIHRoZSBlbmQgaXMgYW1iaWd1b3VzIChzaW5jZSBpdA0KPj4+Pj4+bWFrZXMgaXQgc291bmQg bGlrZSBpdCBkZWZpbmVzIE8vQSBmb3IgVExTKSwgYnV0IHlvdSBjYW4gZml4IHRoaXMgYnkNCj4+ Pj4+PnJldmVyc2luZyB0aGUgZXhpc3RpbmcgdGl0bGU7IGUuZy4sIHNvbWV0aGluZyBsaWtlOiAi RXN0YWJsaXNoaW5nDQo+Pj4+Pj5EYXRhZ3JhbSBUcmFuc3BvcnQgTGF5ZXIgU2VjdXJpdHkgKERU TFMpIFVzaW5nIHRoZSBTZXNzaW9uDQo+Pj4+Pj5EZXNjcmlwdGlvbiBQcm90b2NvbCAoU0RQKSBP ZmZlci9BbnN3ZXIgTWVjaGFuaXNtIGFuZCBJZGVudGlmaWNhdGlvbg0KPj4+Pj4+b2YgVHJhbnNw b3J0IExheWVyIFNlY3VyaXR5IChUTFMpIENvbm5lY3Rpb25zIGluIFNEUKGxDQo+Pj4+PiBXb3cs IHRoYXShr3MgcGV0dHkgY3VtYmVyc29tZSBhcyBhIHRpdGxloappdKGvcyBwcmV0dHkgbXVjaCBh biBhYnN0cmFjdC4NCj4+Pj4+RG9lcyBpdCBuZWVkIHRoYXQgbXVjaCBkZXRhaWw/DQo+Pj4+Pg0K Pj4+PiBJdCdzIHRoZSByZXN1bHQgb2YgdGFraW5nIGEgcmVhc29uYWJseSBzaG9ydCB0aXRsZSAo IkVzdGFibGlzaGluZyBETFRTDQo+Pj4+dXNpbmcgdGhlIFNEUCBPZmZlci9BbnN3ZXIgTWVjaGFu aXNtIGFuZCBJZGVudGlmaWNhdGlvbiBvZiBUTFMNCj4+Pj5Db25uZWN0aW9ucyBpbiBTRFAiKSBh bmQgYXBwbHlpbmcgUkZDIEVkaXRvciBwb2xpY2llcyBvZiBhY3JvbnltDQo+Pj4+ZXhwYW5zaW9u IHRvIGl0LiBJZiB5b3UgY2FuIHRoaW5rIG9mIHNvbWUgc2hvcnRlciB3YXkgdG8gc2F5IGl0LCB0 aGF0J2QNCj4+Pj5iZSBncmVhdCAtLSBidXQgaWYgSSdtIHBlcnVzaW5nIGEgbGlzdCBvZiB0aXRs ZXMgZm9yIHNvbWV0aGluZw0KPj4+PlRMUy1yZWxhdGVkIGFuZCBjb21lIGFjcm9zcyBvbmUgdGhh dCBtZW50aW9ucyBvbmx5IERUTFMsIEknZCBza2lwIG92ZXINCj4+Pj5pdC4gVGhlIG9yaWdpbmFs IHRpdGxlIHNlZW1zIGxpa2UgYSBnZW51aW5lIGZsYXcuDQo+Pj4gSGVyZaGvcyBhIHNhY3JpZmlj aWFsIHByb3Bvc2FsIGZyb20gdGhlIF9tdWNoXyBtb3JlIGdlbmVyYWwgc2lkZToNCj4+Pg0KPj4+ ICAgICAgobBEVExTIGFuZCBUTFMgY29uc2lkZXJhdGlvbnMgaW4gdGhlIFNEUCBPZmZlci9BbnN3 ZXIgTWVjaGFuaXNtobENCj4+Pg0KPj4+IKGmIHdpdGggYXBwcm9wcmlhdGUgYWNyb255bSBleHBh bnNpb25zIG9mIGNvdXJzZS4NCj4+DQo+PkkgaGF2ZSBubyBwcm9ibGVtIHdpdGggdGhhdC4NCj4N Cj4NCj6hsEluIHRoZSBtZWNoYW5pc22hsSBzb3VuZHMgYSBsaXR0bGUgc3RyYW5nZSBpbiBteSBl YXJzLCBzbyBJIHN1Z2dlc3Q6DQo+DQo+obBTRFAgT2ZmZXIvQW5zd2VyIGNvbnNpZGVyYXRpb25z IGZvciBEVExTIGFuZCBUTFOhsQ0KPg0KPlJlZ2FyZHMsDQo+DQo+Q2hyaXN0ZXINCj4NCg0K From nobody Mon Aug 28 03:12:32 2017 Return-Path: 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 AE38B13202D for ; Mon, 28 Aug 2017 03:12:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.22 X-Spam-Level: X-Spam-Status: No, score=-4.22 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=ham autolearn_force=no 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 7q_hcjEv65tH for ; Mon, 28 Aug 2017 03:12:28 -0700 (PDT) Received: from sessmg22.ericsson.net (sessmg22.ericsson.net [193.180.251.58]) (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 A797B1201F8 for ; Mon, 28 Aug 2017 03:12:27 -0700 (PDT) X-AuditID: c1b4fb3a-5ffff700000051a3-b7-59a3ec88a4bd Received: from ESESSHC014.ericsson.se (Unknown_Domain [153.88.183.60]) by sessmg22.ericsson.net (Symantec Mail Security) with SMTP id 9E.62.20899.88CE3A95; Mon, 28 Aug 2017 12:12:25 +0200 (CEST) Received: from ESESSMB109.ericsson.se ([169.254.9.194]) by ESESSHC014.ericsson.se ([153.88.183.60]) with mapi id 14.03.0352.000; Mon, 28 Aug 2017 12:12:24 +0200 From: Christer Holmberg To: Adam Roach , "mmusic@ietf.org" Thread-Topic: [MMUSIC] DTLS-SDP and JSEP Conflicts Thread-Index: AQHTHeD9eWXjhOvP60up2QfAnU62xaKZooIA Date: Mon, 28 Aug 2017 10:12:23 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.7.4.170508 x-originating-ip: [153.88.183.16] Content-Type: multipart/alternative; boundary="_000_D5C9C7CB20655christerholmbergericssoncom_" MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFprDIsWRmVeSWpSXmKPExsUyM2K7jW7nm8WRBhtu8ljs+buI3WLq8scs DkweS5b8ZPKYtfMJSwBTFJdNSmpOZllqkb5dAldG9+N25oLFVRXbF/1ibWDsSu5i5OCQEDCR eDHTv4uRi0NI4AijxObOiUwQzhJGifOnljCCFLEJWEh0/9MGMUUE3CTmnUoHMYUFDCVOnGHp YuQEihpJXD7+gBnG3vFtLzuIzSKgKjGhYR1YnFfAWmLFhVlgtpCAncSZO29YQWxOAXuJyVNP gNUzCohJfD+1hgnEZhYQl7j1ZD6YLSEgILFkz3lmCFtU4uXjf6wgJ4gK6Em82+8JEVaU2Hm2 nRmiNUGire0y1FpBiZMzn7BMYBSZhWTqLCRls5CUQcQNJN6fm88MYWtLLFv4GsrWl9j45Swj hG0tcX7iJUZkNQsYOVYxihanFhfnphsZ6aUWZSYXF+fn6eWllmxiBMbZwS2/rXYwHnzueIhR gINRiYf36bPFkUKsiWXFlbmHGCU4mJVEeCtfAoV4UxIrq1KL8uOLSnNSiw8xSnOwKInzOuy7 ECEkkJ5YkpqdmlqQWgSTZeLglGpgLF2dHlV8dY/oBAFd8y1VVomT7qvO2cpwmeNZsvnf5mdz vxuWnbaPLGGZZCN/ctaRqUdehvpuUVCc8DNPfKuChfiJcyurb6lbrGJYuiP84b8529p+Bs77 Wb/Gq7/7luCVnRPDRcs21hZIeO93TOiIl886+XIl++uLX+OiMowVJs+Id6n1f/v1qRJLcUai oRZzUXEiAKTiruWvAgAA Archived-At: Subject: Re: [MMUSIC] DTLS-SDP and JSEP Conflicts X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 28 Aug 2017 10:12:31 -0000 --_000_D5C9C7CB20655christerholmbergericssoncom_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable Hi Adam, I don=92t know if you left the following out by mistake, if you assumed the= issue had been solved, or if I simply missed it, but just in case: >DTLS-SDP: "the offerer and answerer generate their own local 'tls-id' attr= ibute >values, and the combination of both values identify the DTLS association." > >JSEP: "If this is an answer, the tls-id value, if present, MUST be the sam= e as >in the offer.=94 As I said earlier (and I think others who have commented agree) this needs = to be fixed in JSEP. Regards, Christer From: mmusic > on b= ehalf of "adam@nostrum.com" > Date: Friday 25 August 2017 at 23:30 To: "mmusic@ietf.org" > Subject: [MMUSIC] DTLS-SDP and JSEP Conflicts MMUSIC -- [I will be posting a separate message to RTCWEB directing interested partie= s to discuss this issue on the MMUSIC mailing list] During the IESG review of draft-ietf-mmusic-dtls-sdp, EKR identified some c= onflicts between the procedures in DTLS-SDP and JSEP were identified. This = note is an attempt to summarize them. I have also made an initial proposal,= for each conflict, regarding which document needs to change, in and which = way. Issue 1 (quoting EKR), which raises a couple of additional sub-issues: 1. Assuming I understand this document correctly, it conflicts with the guidance in JSEP. Specifically, S 4 says: No default value is defined for the SDP 'tls-id' attribute. Implementations that wish to use the attribute MUST explicitly include it in SDP offers and answers. If an offer or answer does not contain a 'tls-id' attribute (this could happen if the offerer or answerer represents an existing implementation that has not been updated to support the 'tls-id' attribute), unless there is another mechanism to explicitly indicate that a new DTLS association is to be established, a modification of one or more of the following characteristics MUST be treated as an indication that an endpoint wants to establish a new DTLS association: o DTLS setup role; or o fingerprint set; or o local transport parameters; or o ICE ufrag value This seems to say that if there is no tls-id attribute, then an ICE restart (which necessitates a ufrag change) requires a DTLS restart. JSEP isn't incredibly clear on this point, but 5.7.3 seems to say that tls-id need not be present: * tls-id value, which MUST be set according to [I-D.ietf-mmusic-dtls-sdp], Section 5. If this is a re-offer and the tls-id value is different from that presently in use, the DTLS connection is not being continued and the remote description MUST be part of an ICE restart, together with new ufrag and password values. If this is an answer, the tls-id value, if present, MUST be the same as in the offer. I believe that the first sentence is in error, as we clearly can't have JSEP implementations requiring that tls-id be present. ... o If the remote DTLS fingerprint has been changed or the tls-id has changed, tear down the DTLS connection. This includes the case when the PeerConnection state is "have-remote-pranswer". If a DTLS connection needs to be torn down but the answer does not indicate an ICE restart or, in the case of "have-remote-pranswer", new ICE credentials, an error MUST be generated. If an ICE restart is performed without a change in tls-id or fingerprint, then the same DTLS connection is continued over the new ICE channel. I think the best interpretation of this is that if tls-id is not present (and hence unchanged) then ICE restart does not cause DTLS restart. This is also my memory of the consensus in RTCWEB. In any case, these two documents clearly must match. My observations/recommendations: 1. (Issue 1a) EKR is correct that the first sentence of the bullet from = JSEP needs to be removed so as to enable interoperation with non-JSEP imple= mentations. 2. (Issue 1b) Additionally the final sentence of that bullet ("If this i= s an answer, the tls-id value, if present, MUST be the same as in the offer= ") conflicts with the definition of tls-id ("the offerer and answerer gener= ate their own local 'tls-id' attribute values, and the combination of both = values identify the DTLS association"). In this case, the DTLS-SDP document= would appear to be correct (the fact that the two parties choose different= IDs is integral to the mechanism's design), so JSEP needs to change. 3. (Issue 1c) The crux of the matter: does ICE restart cause DTLS to res= tart? The primary rationale outlined in RFC5245 for restarting ICE is chang= ing the destination (IP address or port) of an ongoing media stream -- whic= h would commonly involve changing to a different physical device. While it = would, in theory, be possible to transfer the TLS state associated with the= connection between devices, this is rather cumbersome (and, as far as I kn= ow, not generally supported by TLS libraries). From that perspective, it is= my opinion that the DTLS-SDP document is correct that an ICE restart neces= sitates a new DTLS connection; and I conclude that JSEP needs to change. Issue 2 (quoting EKR): 2. S 4 says: The mux category [I-D.ietf-mmusic-sdp-mux-attributes] for the 'tls- id' attribute is 'IDENTICAL', which means that the attribute value must be identical across all media descriptions being multiplexed [I-D.ietf-mmusic-sdp-bundle-negotiation]. This is not actually what JSEP requires: different categories. To avoid unnecessary duplication when bundling, attributes of category IDENTICAL or TRANSPORT MUST NOT be repeated in bundled m=3D sections, repeating the guidance from [I-D.ietf-mmusic-sdp-bundle-negotiation], Section 8.1. This includes I suspect this is old text. (Issue 2) JSEP is aligned with draft-ietf-mmusic-sdp-bundle-negotiation-38,= while DTLS-SDP does not. This is a largely aesthetic decision (although th= e JSEP/BUNDLE approach does save a tiny handful of bytes), but I think chan= ging one document (DTLS-SDP) makes more sense than changing two. (I suspect= the BUNDLE formulation more closely tracks consensus anyway). /a --_000_D5C9C7CB20655christerholmbergericssoncom_ Content-Type: text/html; charset="Windows-1252" Content-ID: Content-Transfer-Encoding: quoted-printable
Hi Adam,

I don=92t know if you left the following out by mistake, if you assume= d the issue had been solved, or if I simply missed it, but just in case:

>DTLS-SDP: "the offer= er and answerer generate their own local 'tls-id' attribute
>values, and the combinati= on of both values identify the DTLS association."
>
>JSEP: "If this is an= answer, the tls-id value, if present, MUST be the same as
>in the offer.=94

As I said earlier (and I thin= k others who have commented agree) this needs to be fixed in JSEP.

Regards,

Christer

From: mmusic <mmusic-bounces@ietf.org> on behalf of "= ;adam@nostrum.com" <adam@nostrum.com>
Date: Friday 25 August 2017 at 23:3= 0
To: "mmusic@ietf.org" <= mmusic@ietf.org>
Subject: [MMUSIC] DTLS-SDP and JSEP= Conflicts

MMUSIC --

[I will be posting a separate message to RTCWEB directing interested par= ties to discuss this issue on the MMUSIC mailing list]

During the IESG review of draft-ietf-mmusic-dtls-sdp, EKR identified som= e conflicts between the procedures in DTLS-SDP and JSEP were identified. Th= is note is an attempt to summarize them. I have also made an initial propos= al, for each conflict, regarding which document needs to change, in and which way.

Issue 1 (quoting EKR), which raises a couple of additional sub-issues: 

1. Assuming I understand this document correct=
ly, it conflicts with
the guidance in JSEP. Specifically, S 4 says:

   No default value is defined for the SDP 'tls-id' attribute.
   Implementations that wish to use the attribute MUST explicitly
   include it in SDP offers and answers.  If an offer or answer does not
   contain a 'tls-id' attribute (this could happen if the offerer or
   answerer represents an existing implementation that has not been
   updated to support the 'tls-id' attribute), unless there is another
   mechanism to explicitly indicate that a new DTLS association is to be
   established, a modification of one or more of the following
   characteristics MUST be treated as an indication that an endpoint
   wants to establish a new DTLS association:

   o  DTLS setup role; or

   o  fingerprint set; or

   o  local transport parameters; or

   o  ICE ufrag value

This seems to say that if there is no tls-id attribute, then an ICE restart
(which necessitates a ufrag change) requires a DTLS restart. JSEP isn't
incredibly clear on this point, but 5.7.3 seems to say that tls-id
need not be present:

      *  tls-id value, which MUST be set according to
         [I-D.ietf-mmusic-dtls-sdp], Section 5.  If this is a re-offer
         and the tls-id value is different from that presently in use,
         the DTLS connection is not being continued and the remote
         description MUST be part of an ICE restart, together with new
         ufrag and password values.  If this is an answer, the tls-id
         value, if present, MUST be the same as in the offer.

I believe that the first sentence is in error, as we clearly
can't have JSEP implementations requiring that tls-id be present.

   ...
  =20
   o  If the remote DTLS fingerprint has been changed or the tls-id has
      changed, tear down the DTLS connection.  This includes the case
      when the PeerConnection state is "have-remote-pranswer".  I=
f a
      DTLS connection needs to be torn down but the answer does not
      indicate an ICE restart or, in the case of "have-remote-pranswer=
",
      new ICE credentials, an error MUST be generated.  If an ICE
      restart is performed without a change in tls-id or fingerprint,
      then the same DTLS connection is continued over the new ICE
      channel.
     =20
I think the best interpretation of this is that if tls-id is not present
(and hence unchanged) then ICE restart does not cause DTLS restart.
This is also my memory of the consensus in RTCWEB. In any case, these
two documents clearly must match.


My observations/recommendations:

  1. (Issue 1a) EKR is correct that the first sentence of the bullet from JS= EP needs to be removed so as to enable interoperation with non-JSEP impleme= ntations.

  2. (Issue 1b) Additionally the final sentence of that bullet ("I= f this is an answer, the tls-id value, if present, MUST be the same as in t= he offer") conflicts with the definition of tls-id ("the offerer = and answerer generate their own local 'tls-id' attribute values, and the combination of both values identify the DTLS association&q= uot;). In this case, the DTLS-SDP document would appear to be correct (the = fact that the two parties choose different IDs is integral to the mechanism= 's design), so JSEP needs to change.

  3. (Issue 1c) The crux of the matter: does ICE restart cause DTLS to = restart? The primary rationale outlined in RFC5245 for restarting ICE is ch= anging the destination (IP address or port) of an ongoing media stream -- w= hich would commonly involve changing to a different physical device. While it would, in theory, be possible to = transfer the TLS state associated with the connection between devices, this= is rather cumbersome (and, as far as I know, not generally supported by TL= S libraries). From that perspective, it is my opinion that the DTLS-SDP document is correct that an ICE restart= necessitates a new DTLS connection; and I conclude that JSEP needs to chan= ge.


Issue 2 (quoting EKR):

2. S 4 says:

   The mux category [I-D.ietf-mmusic-sdp-mux-attributes] for the 'tls-
   id' attribute is 'IDENTICAL', which means that the attribute value
   must be identical across all media descriptions being multiplexed
   [I-D.ietf-mmusic-sdp-bundle-negotiation].

This is not actually what JSEP requires:

   different categories.  To avoid unnecessary duplication when
   bundling, attributes of category IDENTICAL or TRANSPORT MUST NOT be
   repeated in bundled m=3D sections, repeating the guidance from
   [I-D.ietf-mmusic-sdp-bundle-negotiation], Section 8.1.  This includes

I suspect this is old text.


(Issue 2) JSEP is aligned with draft-ietf-mmusic-sdp-bundle-negotiation-38,= while DTLS-SDP does not. This is a largely aesthetic decision (although th= e JSEP/BUNDLE approach does save a tiny handful of bytes), but I think chan= ging one document (DTLS-SDP) makes more sense than changing two. (I suspect the BUNDLE formulation more close= ly tracks consensus anyway).


/a

 --_000_D5C9C7CB20655christerholmbergericssoncom_-- From nobody Mon Aug 28 03:18:09 2017 Return-Path: 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 1559C1201F8 for ; Mon, 28 Aug 2017 03:18:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.221 X-Spam-Level: X-Spam-Status: No, score=-4.221 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=ham autolearn_force=no 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 YSStR-wiaOsc for ; Mon, 28 Aug 2017 03:18:03 -0700 (PDT) Received: from sesbmg22.ericsson.net (sesbmg22.ericsson.net [193.180.251.48]) (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 E4D2C13202D for ; Mon, 28 Aug 2017 03:18:02 -0700 (PDT) X-AuditID: c1b4fb30-96f7a9c000005897-71-59a3edd98b99 Received: from ESESSHC022.ericsson.se (Unknown_Domain [153.88.183.84]) by sesbmg22.ericsson.net (Symantec Mail Security) with SMTP id 3A.C6.22679.8DDE3A95; Mon, 28 Aug 2017 12:18:01 +0200 (CEST) Received: from ESESSMB109.ericsson.se ([169.254.9.194]) by ESESSHC022.ericsson.se ([153.88.183.84]) with mapi id 14.03.0352.000; Mon, 28 Aug 2017 12:18:00 +0200 From: Christer Holmberg To: Colin Perkins CC: "mmusic (E-mail)" Thread-Topic: [MMUSIC] Comments on BUNDLE -37 - RTP handling Thread-Index: AQHSr8FdWx51Nry6SECZI3BgadjWMKG8rSlggJ1pOYCAQGnwAA== Date: Mon, 28 Aug 2017 10:17:59 +0000 Message-ID: References: <0E29A586-1532-498D-86D2-D787D3F9FD3E@csperkins.org> <7594FB04B1934943A5C02806D1A2204B4CB5BA24@ESESSMB102.ericsson.se> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.7.4.170508 x-originating-ip: [153.88.183.17] Content-Type: text/plain; charset="Windows-1252" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFlrAIsWRmVeSWpSXmKPExsUyM2J7iO7Nt4sjDf5M47dY/vIEo8XU5Y9Z HJg8pt2/z+axZMlPpgCmKC6blNSczLLUIn27BK6Mmw3TGQuun2GsOP5gG2MD4/Z5jF2MnBwS AiYS668cYgexhQSOMEp8m1jYxcgFZC8BsjcvYOpi5OBgE7CQ6P6nDVIjIqAqseP4P7BeZgF1 iZ7fLcwgtrCAtcS/rn42iBobiaYXp1khbCeJzgttYPUsQL2rJ5wHq+cFqt9+ew8LxK7djBJf Z01gAUlwCjhKnO54B1bEKCAm8f3UGiaIZeISt57MZ4I4WkBiyR6IQRICohIvH/9jBblTVEBP 4t1+TxBTQkBRYnm/HESngcT7c/OZIWxriZXbv7FB2NoSyxa+hjpHUOLkzCcsExjFZyFZNgtJ +ywk7bOQtM9C0r6AkXUVo2hxanFSbrqRkV5qUWZycXF+nl5easkmRmC8Hdzy22AH48vnjocY BTgYlXh4s58tjhRiTSwrrsw9xCjBwawkwlv5EijEm5JYWZValB9fVJqTWnyIUZqDRUmc13Hf hQghgfTEktTs1NSC1CKYLBMHp1QDo97S5nkfuqTEvlc99fleMPmIYUZ82cqaF/7may75vmGQ XDDJJ/JvxoptYSaR7m+c9rw5uThw8ovZtQce9nh2xXK2ptevO9PN3fSw8my3nfzazq4Wn217 bskebv6w8UI81/cj3w5+e+igftt4ltMGqyc1AmvX1Sy12xQ1rXHOT7v1q7T37HrDKqDEUpyR aKjFXFScCABScAaOswIAAA== Archived-At: Subject: Re: [MMUSIC] Comments on BUNDLE -37 - RTP handling X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 28 Aug 2017 10:18:07 -0000 Hi, Nobody has objected to Colin=B9s text, so my suggested is to now merge the PR. Regards, Christer On 18/07/17 16:42, "Colin Perkins" wrote: >Hi Christer, > >As discussed - pull request submitted. >Colin > > > >> On 9 Apr 2017, at 08:54, Christer Holmberg >> wrote: >>=20 >> Hi Colin, >>=20 >> Thanks for your input! >>=20 >> Would it be possible for you to create a pull request with your >>suggested changes? >>=20 >> BUNDLE can be found at: https://github.com/cdh4u/draft-sdp-bundle >>=20 >> Regards, >>=20 >> Christer >>=20 >> -----Original Message----- >> From: mmusic [mailto:mmusic-bounces@ietf.org] On Behalf Of Colin Perkins >> Sent: 07 April 2017 20:06 >> To: mmusic (E-mail) >> Subject: [MMUSIC] Comments on BUNDLE -37 - RTP handling >>=20 >> I have some comments on BUNDLE -37 - apologies that I wasn=B9t able to >>participate fully in the mailing list discussion before the meeting. >>=20 >> The current text is generally reasonably clear, and is certainly >>precisely written, but I do think it has some problems. Most of these >>relate to the issue of whether RTP packets or RTP streams are being >>processed. I think it=B9s important that this draft is written in terms o= f >>how to associate RTP streams with m=3D lines, rather than how to route an= d >>demultiplex RTP packets, since RTP packet routing and demultiplexing is >>already specified by the various RTP specifications. In particular, >>there are some places where the draft as written conflates the two >>layers in ways that conflict with the RTP and RTCP specifications, that >>I=B9ve tried to correct by more cleanly separating the layers. >>=20 >> I=B9ve tried to write my suggestions in a prescriptive manner, keeping t= o >>the style of the existing text where possible. Hopefully the result is >>clear and understandable. >>=20 >> Comments line below: >>=20 >>> 10.2. Associating RTP/RTCP Streams With Correct SDP Media Description >>>=20 >>> NOTE: The text in this section is copied from Appendix B of JSEP. >>> The community has not yet agreed on the text. >>>=20 >>> As described in [RFC3550], RTP packets are associated with RTP >>> streams [RFC7656]. Each RTP stream is identified by an SSRC value, >>> and each RTP packet includes an SSRC field that is used to associate >>> the packet with the correct RTP stream. RTCP packets also use SSRCs >>> to identify which RTP streams the packet relates to. However, a RTCP >>> packet can contain multiple SSRC fields, in the course of providing >>> feedback or reports on different RTP streams, and therefore can be >>> associated with multiple such streams. >>>=20 >>> In order to be able to process received RTP/RTCP packets correctly, >>> it must be possible to associate an RTP stream with the correct "m=3D= " >>>=20 >>>=20 >>>=20 >>> Holmberg, et al. Expires October 2, 2017 [Page >>>20] >>> Internet-Draft Bundled media March >>>2017 >>>=20 >>>=20 >>> line, as the "m=3D" line and SDP attributes associated with the "m=3D= " >>> line contain information needed to process the packets. >>>=20 >>> As all RTP streams associated with a BUNDLE group use the same >>> address:port combination for sending and receiving RTP/RTCP packets, >>> the local address:port combination cannot be used to associate an RTP >>> stream with the correct "m=3D" line. In addition, multiple RTP strea= ms >>> might be associated with the same "m=3D" line. >>>=20 >>> An offerer and answerer can inform each other which SSRC values they >>> will use for an RTP stream by using the SDP 'ssrc' attribute >>> [RFC5576]. However, an offerer will not know which SSRC values the >>> answerer will use until the offerer has received the answer providing >>> that information. Due to this, before the offerer has received the >>> answer, the offerer will not be able to associate an RTP stream with >>> the correct "m=3D" line using the SSRC value associated with the RTP >>> stream. In addition, the offerer and answerer may start using new >>> SSRC values mid-session, without informing each other using the SDP >>> 'ssrc' attribute. >>>=20 >>> In order for an offerer and answerer to always be able to associate >>> an RTP stream with the correct "m=3D" line, the offerer and answerer >>> using the BUNDLE extension MUST support the mechanism defined in >>> section 14, where the offerer and answerer insert the identification- >>> tag associated with an "m=3D" line (provided by the remote peer) into >>> RTP and RTCP packets associated with a BUNDLE group. >>>=20 >>> When using this mechanism, the mapping from an SSRC to an >>> identification-tag is carried in RTP header extensions or RTCP SDES >>> packets, as specified in section 14. Since a compound RTCP packet >>> can contain multiple RTCP SDES packets, and each RTCP SDES packet can >>> contain multiple chunks, a single RTCP packet can contain several >>> SSRC to identification-tag mappings. The offerer and answerer >>> maintain tables used for routing that are updated each time an RTP/ >>> RTCP packet contains new information that affects how packets should >>> be routed. >>=20 >> The text above looks good. In particular, it correctly focusses on >>associating RTP streams with m=3D lines, which is the correct level of >>abstraction.=20 >>=20 >>> However, some implementations of may not include this identification- >>> tag in their RTP and RTCP traffic when using the BUNDLE mechanism, >>> and instead use a payload type based mechanism for demuxing. In this >>=20 >> The term =B3demuxing=B2 is unclear. For precision, I suggest changing = =B3use >>a payload type based mechanisms for demuxing=B2 to =B3use a payload type >>based mechanism to associate RTP streams with SDP m=3D lines=B2. >>=20 >>> situation, each "m=3D" line MUST use unique payload type values, in >>> order for the payload type to be a reliable indicator of the relevant >>> "m=3D" line for the RTP stream. Note that when using payload type >>> based demuxing, >>=20 >> Similarly, for precision, I suggest changing =B3when using payload type >>based demuxing=B2 to =B3when using the payload type to associate RTP stre= ams >>with m=3D lines=B2. >>=20 >>> an SSRC will be mapped to an =B3m=3D=B3 line >>=20 >> Suggest changing to =B3an RTP stream, identified by SSRC, will be >>mapped=8A=B2 to be clear what=B9s being done. >>=20 >>> by the first >>> packet with that SSRC, and the mapping will not be changed even if >>=20 >> Suggest changing to =B3when the first RTP packet of that RTP stream is >>received, and=8A=B2 to be clear, since there could be RTCP packets with t= he >>same SSRC. >>=20 >>> the same SSRC is received with a different payload type. In other >>=20 >> Suggest changing to =B3the payload type used by that RTP stream changes. >>In other=B2 to be precise. >>=20 >>> words, the SSRC cannot to "move" to a different "m=3D" line simply by >>> changing the payload type. >>>=20 >>> Holmberg, et al. Expires October 2, 2017 [Page >>>21] >>> Internet-Draft Bundled media March >>>2017 >>>=20 >>>=20 >>> Applications can implement RTP stacks in many different ways. The >>> algorithm below details one way that demultiplexing can be >>> accomplished, but is not meant to be prescriptive about exactly how >>=20 >> To be clear about what is being demultiplexed, I suggest changing =B3one >>way that demultiplexing can be accomplished=B2 to =B3one way that RTP >>streams can be associated with m=3D lines=B2. >>=20 >>> an RTP stack needs to be implemented. Applications MAY use any >>> algorithm that achieves equivalent results to those described in the >>> algorithm below. >>>=20 >>> To prepare for demultiplexing RTP/RTCP packets to the correct "m=3D" >>> line, the following steps MUST be followed for each BUNDLE group. >>=20 >> I suggest changing =B3=8Aprepare for demultiplexing RTP/RTCP packets to = the >>correct=8A=B2 to =B3=8Aprepare to associate RTP streams with the correct= =8A=B2. RTP >>and RTCP packets are not demultiplexed to m=3D lines, they=B9re >>demultiplexed into RTP streams, and then those RTP streams are >>associated with m=3D lines. The distinction is important, in order to >>implement RTCP correctly. >>=20 >>> Construct a table mapping MID to "m=3D" line for each "m=3D" line = in >>> this BUNDLE group. Note that an "m=3D" line may only have one MID= . >>>=20 >>> Construct a table mapping incoming SSRC to "m=3D" line for each "m= =3D" >>> line in this BUNDLE group and for each SSRC configured for >>> receiving in that =B3m=3D" line. >>=20 >> The SSRC is a property of an RTP stream, so I suggest changing =B3mappin= g >>incoming SSRC to=B2 to =B3mapping SSRCs of incoming RTP streams to=B2. >>=20 >>> Construct a table mapping outgoing SSRC to "m=3Dline" for each "m= =3D" >>> line in this BUNDLE group and for each SSRC configured for sending >>> in that =B3m=3D" line. >>=20 >> Similarly, change =B3mapping outgoing SSRC=B2 to =B3mapping the SSRC of = each >>outgoing RTP stream=B2 >>=20 >>> Construct a table mapping payload type to "m=3D" line for each "m= =3D" >>> line in the BUNDLE group and for each payload type configured for >>> receiving in that "m=3D" line. If any payload type is configured >>> for receiving in more than one "m=3D" line in the BUNDLE group, do >>> not it include it in the table, as it cannot be used to uniquely >>> identify a "m=3D" line. >>>=20 >>> Note that for each of these tables, there can only be one mapping >>> for any given key (MID, SSRC, or PT). In other words, the tables >>> are not multimaps. >>>=20 >>> As "m=3D" lines are added or removed from the BUNDLE groups, or their >>> configurations are changed, the tables above MUST also be updated. >>>=20 >>> For each RTP packet received, the following steps MUST be followed to >>> route the packet to the correct "m=3D" section within a BUNDLE group. >>=20 >> The goal is not to route RTP packets to m=3D lines, but rather to >>associate the corresponding RTP streams with m=3D lines. This keeps the >>distinction between RTP and RTCP processing that has to happen >>irrespective of the m=3D line, and the application level processing that >>depends on the choice of m=3D line. I suggest changing this sentence to: >>=B3When an RTP packet is received, it MUST be delivered to the RTP stream >>corresponding to its SSRC. That RTP stream MUST then be associated with >>the correct m=3D line within a BUNDLE group, according to the following >>steps.=B2 >>=20 >>> Note that the phrase 'deliver a packet to the "m=3D" line' means to >>> further process the packet as would normally happen with RTP/RTCP, if >>> it were received on a transport associated with that "m=3D" line >>> outside of a BUNDLE group (i.e., if the "m=3D" line were not BUNDLEd)= , >>> including dropping an RTP packet if the packet's PT does not match >>> any PT in the =B3m=3D" line. >>=20 >> Dropping RTP packets with unknown payload type breaks RTCP. The RTP >>packet must be processed by the RTP layer as normal, updating the >>statistics that are maintained by RTCP. The payload is then discarded, >>because there=B9s no decoder associated with the payload type. I suggest >>removing this part of the paragraph entirely. >>=20 >>> If the packet has a MID, and that MID is not in the table mapping >>> MID to =B3m=3D" line, drop the packet and stop. >>=20 >> Dropping the RTP packet will break the RTCP reports. The RTP packet has >>to be processed as normal, but the corresponding RTP stream is not >>decoded if it=B9s not associated with an =B3m=3D=B3 line (i.e., you drop = the >>payload, not the RTP packet). I suggest replacing the above with >>something like: >>=20 >> If the MID associated with the RTP stream is not in the table mapping >> MID to =B3m=3D=B3 line, then the RTP stream is not decoded and the pay= load >> data is discarded. >>=20 >>> If the packet has a MID, and the packet's extended sequence number >>> is greater than that of the last MID update, as discussed in >>> [RFC7941], Section 4.2.6, update the incoming SSRC mapping table >>> to include an entry that maps the packet's SSRC to the "m=3D" line >>> for that MID. >>=20 >> There are two things that need to be done here: update the MID >>associated with the RTP stream to match that in the newly received RTP >>packet, and update the mapping table. I suggest changing =B3update the >>incoming SSRC mapping table to include an entry that maps the packet=B9s >>SSRC to the =B3m=3D=B3 line for that MID=B2 to =B3update the MID associat= ed with >>the RTP stream to match the MID carried in the RTP packet, then update >>the mapping tables to include an entry that maps the SSRC of that RTP >>stream to the =B3m=3D=B3 line for that MID=B2. >>=20 >>> If the packet's SSRC is in the incoming SSRC mapping table, check >>> that the packet's PT matches a PT included on the associated "m=3D= " >>> line. If so, route the packet to that associated "m=3D" line and >>> stop; otherwise drop the packet and stop. >>=20 >> Dropping the packet breaks RTCP. The RTP packet is processed as normal, >>but the corresponding RTP stream is not decoded if it=B9s not associated >>with an =B3m=3D=B3 line. I suggest replacing the above with: >>=20 >> If the SSRC of the RTP stream is in the incoming SSRC mapping table, >> check that the payload type used by the RTP stream matches a payload >> type included on the matching =B3m=3D=B3 line. If so, associate the RT= P >> stream with that =B3m=3D=B3 line. Otherwise, the RTP stream is not dec= oded >> and the payload data is discarded. >>=20 >>> If the packet's payload type is in the payload type table, update >>> the the incoming SSRC mapping table to include an entry that maps >>> the packet's SSRC to the "m=3D" line for that payload type. In >>> addition, route the packet to the associated =B3m=3D" line and sto= p. >>=20 >> RTP packets correspond to RTP streams, and those RTP streams are >>associated with m=3D lines. Suggest changing to: >>=20 >> If the payload type used by the RTP stream is in the payload type >> table, update the incoming SSRC mapping table to include an entry >> that maps the RTP stream=B9s SSRC to the =B3m=3D=B3 line for that payl= oad >> type. Associate the RTP stream with the corresponding =B3m=3D=B3 line. >>=20 >>> Otherwise, drop the packet. >>=20 >> The packet cannot be discarded without breaking RTCP. I suggest >>replacing the above with: >>=20 >> Otherwise, mark the RTP stream as not for decoding and discard the >> payload.=20 >>=20 >>> For each RTCP packet received (including each RTCP packet that is >>> part of a compound RTCP packet), the packet MUST be routed to the >>> =B3m=3D=B3 line for the RTP streams it contains information about. T= his >>> routing is type-dependent, as each kind of RTCP packet has its own >>> mechanism for associating it with the relevant RTP streams. >>=20 >> The first sentence might be clearer written =B3For each RTCP packet >>received (including each RTCP packet that is part of a compound RTCP >>packet), the packet is processed as usual by the RTP layer, then is >>passed to the =B3m=3D=B3 lines corresponding to the RTP streams it contai= ns >>information about for further processing.=B2 >>=20 >>> Packets for which no appropriate "m=3D" line can be identified (i.e., >>> for unknown RTP streams) are not relevant in the context of this >>> algorithm and MAY be dropped. This situation may occur with certain >>> multiparty RTP topologies. >>=20 >> These packets can=B9t be dropped. They setup state at the RTP layer that >>might become relevant when further RTP/RTCP packets are received (RTCP >>packets can round-robin SDES items, such as the MID, in some cases, so >>these can potentially be important). I suggest changing this to: >>=20 >> RTCP packets for which no appropriate =B3m=3D=B3 line can be identifie= d >> MUST be processed as usual by the RTP layer, updating the metadata >> associated with the corresponding RTP streams, but are not passed >> to any =B3m=3D=B3 line. This situation can occur with certain multipar= ty >> RTP topologies, or when RTCP packets are sent containing a subset >> of the SDES information. >>=20 >>> Rules for handling the various types of RTCP packets are explained >>> below. >>=20 >> Perhaps change to =B3Rules for additional processing of the various=8A= =B2, to >>make it clear that this doesn=B9t replace the usual RTCP processing. >>=20 >>> If the packet is of type SDES, for each chunk in the packet whose >>=20 >> "If the RTCP packet is=8A=B2 >>=20 >>> SSRC is found in the incoming SSRC table, deliver a copy of the >>> packet to the "m=3D" line associated with that SSRC. In addition, >>=20 >> =B3a copy of the SDES packet=B2 presumably, since otherwise it=B9s ambig= uous >>if the entire compound RTCP packet is delivered or just the SDES packet. >>=20 >>> for any SDES MID items contained in these chunks, if the MID is >>> found in the table mapping MID to "m=3D" line, update the incoming >>> SSRC table to include an entry that maps the chunk=B9s SSRC to the >>=20 >> =B3=8Amaps the RTP stream associated with the chunk=B9s SSRC to=8A=B2 >>=20 >>> "m=3D" line associated with that MID, unless the packet is older >>> than the packet that most recently updated the mapping for this >>> SSRC, as discussed in [RFC7941], Section 4.2.6. >>>=20 >>> Note that if an SDES packet is received as part of a compound RTCP >>> packet, the SSRC to "m=3D" line mapping may not exist until the SD= ES >>> packet is handled (e.g., in the case where RTCP for a source is >>> received before any RTP packets). Therefore, when processing a >>> compound packet, any contained SDES packet MUST be handled first. >>=20 >> It might be worth referencing RFC 3550 section 6.1, which says: >>=20 >> Each individual RTCP packet in the compound packet may be processed >> independently with no requirements upon the order or combination of >> packets. =20 >>=20 >> as justification for this. >>=20 >>> Holmberg, et al. Expires October 2, 2017 [Page >>>23] >>> Internet-Draft Bundled media March >>>2017 >>>=20 >>>=20 >>> If the packet is of type BYE, it indicates that the RTP streams >>=20 >> =B3If the RTCP packet is=8A=B2 >>=20 >>> referenced in the packet are ending. Therefore, for each SSRC >>> indicated in the packet that is found in the incoming SSRC table, >>=20 >> =B3=8Ain the BYE packet=8A=B2 >>=20 >>> first deliver a copy of the packet to the =B3m=3D" line associated >>=20 >> =B3=8Aa copy of the BYE packet=8A=B2 >>=20 >>> with that SSRC, but then remove the entry for that SSRC from the >>> incoming SSRC table after an appropriate delay to account for >>> "straggler packets", as specified in [RFC3550], Section 6.2.1. >>>=20 >>> If the packet is of type SR or RR, for each report block in the >>=20 >> =B3If the RTCP packet is=8A=B2 >>=20 >>> report whose "SSRC of source" is found in the outgoing SSRC table, >>> deliver a copy of the RTCP packet to the =B3m=3D" line associated = with >>=20 >> =B3the RTCP packet=B2 or =B3the SR or RR packet=B2? To avoid confusion w= hen >>compound RTCP packets are used, I suggest the latter phrasing here, and >>in the later sections. >>=20 >>> that SSRC. In addition, if the packet is of type SR, and the >>> sender SSRC for the packet is found in the incoming SSRC table, >>> deliver a copy of the packet to the =B3m=3D" line associated with = that >>=20 >> =B3a copy of the SR packet=B2? >>=20 >>> SSRC. >>>=20 >>> If the implementation supports RTCP XR and the packet is of type >>> XR, as defined in [RFC3611], for each report block in the report >>> whose "SSRC of source" is is found in the outgoing SSRC table, >>> deliver a copy of the RTCP packet to the =B3m=3D" line associated = with >>=20 >> =B3the RTCP packet=B2 or =B3the XR packet=B2? >>=20 >>> that SSRC. In addition, if the sender SSRC for the packet is >>> found in the incoming SSRC table, deliver a copy of the packet to >>=20 >> =B3the packet=B2 -> =B3the RTCP packet=B2 or =B3the XR packet=B2? >>=20 >>> the "m=3D" line associated with that SSRC. >>>=20 >>> If the packet is a feedback message of type RTPFB or PSFB, as >>=20 >> =B3If the RTCP packet is=8A=B2 >>=20 >>> defined in [RFC4585], it will contain a media source SSRC, and >>> this SSRC is used for routing certain subtypes of feedback >>> messages. However, several subtypes of PSFB messages include >>> target SSRC(s) in a section called Feedback Control Information >>> (FCI). For these messages, the target SSRC(s) are used for >>> routing. >>>=20 >>> If the packet is a feedback message that does not include target >>=20 >> =B3If the RTCP packet is=8A=B2 >>=20 >>> SSRCs in its FCI section, and the media source SSRC is found in >>> the outgoing SSRC table, deliver the packet to the =B3m=3D" line >>=20 >> Which packet?=20 >>=20 >>> associated with that SSRC. RTPFB and PSFB types that are handled >>> in this way include: >>>=20 >>> Generic NACK: [RFC4585] (PT=3DRTPFB, FMT=3D1). >>>=20 >>> Picture Loss Indication (PLI): [RFC4585] (PT=3DPSFB, FMT=3D1). >>>=20 >>> Slice Loss Indication (SLI): [RFC4585] (PT=3DPSFB, FMT=3D2). >>>=20 >>> Reference Picture Selection Indication (RPSI): [RFC4585] >>> (PT=3DPSFB, FMT=3D3). >>>=20 >>>=20 >>>=20 >>>=20 >>>=20 >>> Holmberg, et al. Expires October 2, 2017 [Page >>>24] >>> Internet-Draft Bundled media March >>>2017 >>>=20 >>>=20 >>> If the packet is a feedback message that does include target >>=20 >> =B3If the RTCP packet is=8A=B2 >>=20 >>> SSRC(s) in its FCI section, it can either be a request or a >>> notification. Requests reference a RTP stream that is being sent >>> by the message recipient, whereas notifications are responses to >>> an earlier request, and therefore reference a RTP stream that is >>> being received by the message recipient. >>>=20 >>> If the packet is a feedback request that includes target SSRC(s), >>=20 >> =B3If the RTCP packet is=8A=B2 >>=20 >>> for each target SSRC that is found in the outgoing SSRC table, >>> deliver a copy of the RTCP packet to the "m=3D" line associated wi= th >>> that SSRC. PSFB types that are handled in this way include: >>>=20 >>> Full Intra Request (FIR): [RFC5104] (PT=3DPSFB, FMT=3D4). >>>=20 >>> Temporal-Spatial Trade-off Request (TSTR): [RFC5104] (PT=3DPSFB, >>> FMT=3D5). >>>=20 >>> H.271 Video Back Channel Message (VBCM): [RFC5104] (PT=3DPSFB, >>> FMT=3D7). >>>=20 >>> Layer Refresh Request (LRR): [I-D.ietf-avtext-lrr] (PT=3DPSFB, >>> FMT=3DTBD). >>>=20 >>> If the packet is a feedback notification that include target >>> SSRC(s), for each target SSRC that is found in the incoming SSRC >>> table, deliver a copy of the RTCP packet to the "m=3D" line >>> associated with that SSRC. PSFB types that are handled in this >>=20 >> =B3deliver a copy of the RTCP packet to the =B3m=3D=B3 line associated w= ith the >>RTP stream with matching SSRC=B2 >>=20 >>> way include: >>>=20 >>> Temporal-Spatial Trade-off Notification (TSTN): [RFC5104] >>> (PT=3DPSFB, FMT=3D6). This message is a notification in respon= se >>> to a prior TSTR. >>>=20 >>> If the packet is of type APP, the only routing information >>> included is the source of the packet, and therefore the packet >>> could be related to any existing "m=3D" line. Accordingly, delive= r >>> a copy of the packet to each =B3m=3D" line. >>=20 >> Are APP packets exposed in the WebRTC APIs? Given that we have the data >>channel, it=B9s not clear that we want to support arbitrary application >>information passing via RTCP. It might be better to say that APP packets >>are processed in an application specific manner, and if the application >>doesn=B9t understand them, they=B9re not passed to any m=3D line? >>=20 >> Finally, I note that this section of the draft doesn=B9t mention the CSR= C >>list anywhere, but should probably do so. As written, RTP packets with a >>CSRC list will be delivered to the RTP stream matching their SSRC in the >>usual way, then passed up to the m=3D line associated with that RTP >>stream. That may well be sufficient, but if so it=B9s likely useful to sa= y >>that, to make the intent clear. >>=20 >> Colin >>=20 >>=20 >>=20 >>=20 >> --=20 >> Colin Perkins >> https://csperkins.org/ >>=20 >>=20 >>=20 >>=20 >> _______________________________________________ >> 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 > > > >--=20 >Colin Perkins >https://csperkins.org/ > > > > From nobody Mon Aug 28 10:39:44 2017 Return-Path: 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 8B8D51326EC for ; Mon, 28 Aug 2017 10:39:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.879 X-Spam-Level: X-Spam-Status: No, score=-1.879 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, T_SPF_HELO_PERMERROR=0.01, T_SPF_PERMERROR=0.01] autolearn=ham autolearn_force=no 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 MROnP2x7tUWt for ; Mon, 28 Aug 2017 10:39:41 -0700 (PDT) Received: from nostrum.com (raven-v6.nostrum.com [IPv6:2001:470:d:1130::1]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3B45A13218E for ; Mon, 28 Aug 2017 10:39:41 -0700 (PDT) Received: from Svantevit.roach.at (cpe-70-122-154-80.tx.res.rr.com [70.122.154.80]) (authenticated bits=0) by nostrum.com (8.15.2/8.15.2) with ESMTPSA id v7SHdYpO051669 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NO); Mon, 28 Aug 2017 12:39:37 -0500 (CDT) (envelope-from adam@nostrum.com) X-Authentication-Warning: raven.nostrum.com: Host cpe-70-122-154-80.tx.res.rr.com [70.122.154.80] claimed to be Svantevit.roach.at To: Christer Holmberg , "mmusic@ietf.org" References: From: Adam Roach Message-ID: <72b8570f-be3c-fcad-cd81-5fd4cd853f92@nostrum.com> Date: Mon, 28 Aug 2017 12:39:33 -0500 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:52.0) Gecko/20100101 Thunderbird/52.2.1 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/alternative; boundary="------------3427563875272C7A468A4942" Content-Language: en-US Archived-At: Subject: Re: [MMUSIC] DTLS-SDP and JSEP Conflicts X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 28 Aug 2017 17:39:42 -0000 This is a multi-part message in MIME format. --------------3427563875272C7A468A4942 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit On 8/28/17 5:12 AM, Christer Holmberg wrote: > Hi Adam, > > I don’t know if you left the following out by mistake, if you assumed > the issue had been solved, or if I simply missed it, but just in case: > > >DTLS-SDP: "the offerer and answerer generate their own local 'tls-id' > attribute > >values, and the combination of both values identify the DTLS > association." > > > >JSEP: "If this is an answer, the tls-id value, if present, MUST be > the same as > >in the offer.” That was my "Issue 1b": > (Issue 1b) Additionally the final sentence of that bullet ("If this is > an answer, the tls-id value, if present, MUST be the same as in the > offer") conflicts with the definition of tls-id ("the offerer and > answerer generate their own local 'tls-id' attribute values, and the > combination of both values identify the DTLS association"). In this > case, the DTLS-SDP document would appear to be correct (the fact that > the two parties choose different IDs is integral to the mechanism's > design), so JSEP needs to change. /a --------------3427563875272C7A468A4942 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit
On 8/28/17 5:12 AM, Christer Holmberg wrote:
Hi Adam,

I don’t know if you left the following out by mistake, if you assumed the issue had been solved, or if I simply missed it, but just in case:

>DTLS-SDP: "the offerer and answerer generate their own local 'tls-id' attribute
>values, and the combination of both values identify the DTLS association."
>
>JSEP: "If this is an answer, the tls-id value, if present, MUST be the same as
>in the offer.”

That was my "Issue 1b":

(Issue 1b) Additionally the final sentence of that bullet ("If this is an answer, the tls-id value, if present, MUST be the same as in the offer") conflicts with the definition of tls-id ("the offerer and answerer generate their own local 'tls-id' attribute values, and the combination of both values identify the DTLS association"). In this case, the DTLS-SDP document would appear to be correct (the fact that the two parties choose different IDs is integral to the mechanism's design), so JSEP needs to change.

/a
--------------3427563875272C7A468A4942-- From nobody Mon Aug 28 12:26:10 2017 Return-Path: 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 42593132812 for ; Mon, 28 Aug 2017 12:26:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.221 X-Spam-Level: X-Spam-Status: No, score=-4.221 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=ham autolearn_force=no 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 rkMGR42cqqVp for ; Mon, 28 Aug 2017 12:26:07 -0700 (PDT) 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 40C641320CC for ; Mon, 28 Aug 2017 12:26:07 -0700 (PDT) X-AuditID: c1b4fb2d-11bff700000057a4-0c-59a46e4d15a2 Received: from ESESSHC006.ericsson.se (Unknown_Domain [153.88.183.36]) by sessmg23.ericsson.net (Symantec Mail Security) with SMTP id C2.15.22436.D4E64A95; Mon, 28 Aug 2017 21:26:05 +0200 (CEST) Received: from ESESSMB109.ericsson.se ([169.254.9.194]) by ESESSHC006.ericsson.se ([153.88.183.36]) with mapi id 14.03.0352.000; Mon, 28 Aug 2017 21:26:05 +0200 From: Christer Holmberg To: Adam Roach , "mmusic@ietf.org" Thread-Topic: [MMUSIC] DTLS-SDP and JSEP Conflicts Thread-Index: AQHTHeD9eWXjhOvP60up2QfAnU62xaKZooIAgABJbICAAD8LcA== Date: Mon, 28 Aug 2017 19:26:03 +0000 Message-ID: <7594FB04B1934943A5C02806D1A2204B4CD03BD4@ESESSMB109.ericsson.se> References: <72b8570f-be3c-fcad-cd81-5fd4cd853f92@nostrum.com> In-Reply-To: <72b8570f-be3c-fcad-cd81-5fd4cd853f92@nostrum.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [153.88.183.150] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFnrDLMWRmVeSWpSXmKPExsUyM2K7iq5v3pJIgzsrZC32/F3EbjF1+WMW ByaPJUt+MnnM2vmEJYApissmJTUnsyy1SN8ugSvj290PjAV/uCru3b7A2sB4g6uLkZNDQsBE YkXra6YuRi4OIYEjjBJHNvWxQjhLGCXuHVnM1sXIwcEmYCHR/U8bxBQRcJOYdyodxBQWMJQ4 fd8IZIyIgJHE5eMPmCFsJ4n/m2aygdgsAqoS8+f9BovzCvhKbJu8kAXEFhJYyigxYYkfiM0p YC9xq+k3O4jNKCAm8f3UGiYQm1lAXOLWk/lMEGcKSCzZc54ZwhaVePn4HyuErSSxYvslRpBz mAU0Jdbv0odoVZSY0v2QHWKtoMTJmU9YJjCKzEIydRZCxywkHbOQdCxgZFnFKFqcWlycm25k rJdalJlcXJyfp5eXWrKJERgHB7f81t3BuPq14yFGAQ5GJR5e+5glkUKsiWXFlbmHGCU4mJVE eG1zgUK8KYmVValF+fFFpTmpxYcYpTlYlMR5HfZdiBASSE8sSc1OTS1ILYLJMnFwSjUwerK/ vH2hQjlFk4/NRPX8t8nOSodLOk3mKS4XmT7TkK9Lw3R6R/rc4zFKwU+Keb+tlOzx3N+/1XlS 2sNcRocVy52aNjY/D7D7ErTN40KzcN8lluX//13xZLjcdfdETbSznPiiq9eXRkXa/jgmoiF0 MuGY3BIFNxe2t9ek/RcmNnn1O7Vm7pupxFKckWioxVxUnAgAQhjGqX8CAAA= Archived-At: Subject: Re: [MMUSIC] DTLS-SDP and JSEP Conflicts X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 28 Aug 2017 19:26:09 -0000 SGksDQoNCj4+SSBkb27igJl0IGtub3cgaWYgeW91IGxlZnQgdGhlIGZvbGxvd2luZyBvdXQgYnkg bWlzdGFrZSwgaWYgeW91IGFzc3VtZWQgdGhlIGlzc3VlIGhhZCBiZWVuIHNvbHZlZCwgb3IgaWYg SSBzaW1wbHkgbWlzc2VkIGl0LCBidXQganVzdCBpbiBjYXNlOg0KPj4NCj4+RFRMUy1TRFA6ICJ0 aGUgb2ZmZXJlciBhbmQgYW5zd2VyZXIgZ2VuZXJhdGUgdGhlaXIgb3duIGxvY2FsICd0bHMtaWQn IGF0dHJpYnV0ZQ0KPj52YWx1ZXMsIGFuZCB0aGUgY29tYmluYXRpb24gb2YgYm90aCB2YWx1ZXMg aWRlbnRpZnkgdGhlIERUTFMgYXNzb2NpYXRpb24uIg0KPj4NCj4+SlNFUDogIklmIHRoaXMgaXMg YW4gYW5zd2VyLCB0aGUgdGxzLWlkIHZhbHVlLCBpZiBwcmVzZW50LCBNVVNUIGJlIHRoZSBzYW1l IGFzDQo+PmluIHRoZSBvZmZlci7igJ0NCj4NCj5UaGF0IHdhcyBteSAiSXNzdWUgMWIiOg0KPg0K PihJc3N1ZSAxYikgQWRkaXRpb25hbGx5IHRoZSBmaW5hbCBzZW50ZW5jZSBvZiB0aGF0IGJ1bGxl dCAoIklmIHRoaXMgaXMgYW4gYW5zd2VyLCB0aGUgdGxzLWlkIHZhbHVlLCBpZiBwcmVzZW50LCBN VVNUIGJlIHRoZSBzYW1lIGFzIGluIHRoZSBvZmZlciIpIGNvbmZsaWN0cyB3aXRoIHRoZSBkZWZp bml0aW9uIG9mID50bHMtaWQgKCJ0aGUgb2ZmZXJlciBhbmQgYW5zd2VyZXIgZ2VuZXJhdGUgdGhl aXIgb3duIGxvY2FsICd0bHMtaWQnIGF0dHJpYnV0ZSB2YWx1ZXMsIGFuZCB0aGUgY29tYmluYXRp b24gb2YgYm90aCB2YWx1ZXMgaWRlbnRpZnkgdGhlIERUTFMgYXNzb2NpYXRpb24iKS4gSW4gdGhp cyBjYXNlLCB0aGUgRFRMUy0+U0RQIGRvY3VtZW50IHdvdWxkIGFwcGVhciB0byBiZSBjb3JyZWN0 ICh0aGUgZmFjdCB0aGF0IHRoZSB0d28gcGFydGllcyBjaG9vc2UgZGlmZmVyZW50IElEcyBpcyBp bnRlZ3JhbCB0byB0aGUgbWVjaGFuaXNtJ3MgZGVzaWduKSwgc28gSlNFUCBuZWVkcyB0byBjaGFu Z2UuDQoNCkNvcnJlY3QuIE15IG1pc3Rha2UuDQoNClJlZ2FyZHMsDQoNCkNocmlzdGVyDQoNCg== From nobody Tue Aug 29 06:08:27 2017 Return-Path: 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 58FE11326EA for ; Tue, 29 Aug 2017 06:08:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.698 X-Spam-Level: X-Spam-Status: No, score=-2.698 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, 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=gmail.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 8irp2UV3l5z3 for ; Tue, 29 Aug 2017 06:08:23 -0700 (PDT) Received: from mail-vk0-x230.google.com (mail-vk0-x230.google.com [IPv6:2607:f8b0:400c:c05::230]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BCC7713292E for ; Tue, 29 Aug 2017 06:08:21 -0700 (PDT) Received: by mail-vk0-x230.google.com with SMTP id d124so9284030vkf.3 for ; Tue, 29 Aug 2017 06:08:21 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=Ko0V7vk6NdfwS5q+P0q/QP24a0c85/OI+gOY6TGtDTk=; b=Ro7UR46gofn12tkhXAmKhY2G3x8T+YdeQeqQXsrZHSDVvu/FkJjAfVfkDRFxlGT/5j 4oE7M1vNBg60Jgz6NZZhP/KdEV9ivGuafkdPitfl+yQjoOSe2pogxMzyRT1AsVRDK8Nz WK7dNKBivdCNfiMpqijQ4S11oZOJDYHpeSTlbUrP0MJ8vWsRKCqGJ6HX7SSnreYvVTSb Tgx3CZ7nqL8mvNoBgwZu9qrauje9hKF/ULGTBODJ5keu8IXwjfbnbBbAaj4p61mh9eTp NGRtKs97AVh73rjps1U4Q6ug/FXvYjn63TdkLoJg3qpkFnWIAtv/EEhwcHoWOW2wOg8N WfyQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=Ko0V7vk6NdfwS5q+P0q/QP24a0c85/OI+gOY6TGtDTk=; b=Wovdgd3sIYvi7N9M0rjlnNcK7Y4WVtYqjlJ9nFpAqzcANf/J4NQoOGdm3w+HHwi3GL kuekJIzWoh31gI9m7trAnzhQWMghAjE+lTUkCoIGt/iy97sv8hVPakKE2D0GQfoUe+fg AvrDMib1SP9/w3Jzjk9jMTExr+n2oeYC2uVxGSEwbo1TAVm9QwrfyRQ+mz0bO4lwePYL 0GGDVBwG/2CKV4uL/cCYlQjhheht8ZgwOTVgePHfa/vptP3hBd1OHROoO8vDLVv8mTyw iqAe71zDqgLJe2MiDG5cZXQiCmmvLpUGny4DPrtFlVXm98VXCK+UniBOVyIHxnPF2vGB TrrQ== X-Gm-Message-State: AHYfb5hQi4BB+OChwTm5lDZHzE58ZxxA16kfG5nPxim0eb7GeOIbvNNJ mlav7PO7CU7vOuALpizUGVoVTIIg5Q== X-Received: by 10.31.92.66 with SMTP id q63mr157097vkb.107.1504012100326; Tue, 29 Aug 2017 06:08:20 -0700 (PDT) MIME-Version: 1.0 Received: by 10.176.74.23 with HTTP; Tue, 29 Aug 2017 06:07:59 -0700 (PDT) In-Reply-To: References: From: Bernard Aboba Date: Tue, 29 Aug 2017 09:07:59 -0400 Message-ID: To: Adam Roach Cc: "mmusic@ietf.org" Content-Type: multipart/alternative; boundary="001a114e22f0fa5b3a0557e41ae2" Archived-At: Subject: Re: [MMUSIC] DTLS-SDP and JSEP Conflicts X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 29 Aug 2017 13:08:26 -0000 --001a114e22f0fa5b3a0557e41ae2 Content-Type: text/plain; charset="UTF-8" On Issue 1, Adam said: " 1. (Issue 1c) The crux of the matter: does ICE restart cause DTLS to restart? The primary rationale outlined in RFC5245 for restarting ICE is changing the destination (IP address or port) of an ongoing media stream -- which would commonly involve changing to a different physical device. While it would, in theory, be possible to transfer the TLS state associated with the connection between devices, this is rather cumbersome (and, as far as I know, not generally supported by TLS libraries). From that perspective, it is my opinion that the DTLS-SDP document is correct that an ICE restart necessitates a new DTLS connection; and I conclude that JSEP needs to change. " [BA] Agree that for consistency, it is best for an ICE restart to necessitate a new DTLS connection, since an ICE restart can result in connection to a different device (and the need for a new DTLS connection). On Fri, Aug 25, 2017 at 4:30 PM, Adam Roach wrote: > MMUSIC -- > > [I will be posting a separate message to RTCWEB directing interested > parties to discuss this issue on the MMUSIC mailing list] > > During the IESG review of draft-ietf-mmusic-dtls-sdp, EKR identified some > conflicts between the procedures in DTLS-SDP and JSEP were identified. This > note is an attempt to summarize them. I have also made an initial proposal, > for each conflict, regarding which document needs to change, in and which > way. > > Issue 1 (quoting EKR), which raises a couple of additional sub-issues: > > 1. Assuming I understand this document correctly, it conflicts with > the guidance in JSEP. Specifically, S 4 says: > > No default value is defined for the SDP 'tls-id' attribute. > Implementations that wish to use the attribute MUST explicitly > include it in SDP offers and answers. If an offer or answer does not > contain a 'tls-id' attribute (this could happen if the offerer or > answerer represents an existing implementation that has not been > updated to support the 'tls-id' attribute), unless there is another > mechanism to explicitly indicate that a new DTLS association is to be > established, a modification of one or more of the following > characteristics MUST be treated as an indication that an endpoint > wants to establish a new DTLS association: > > o DTLS setup role; or > > o fingerprint set; or > > o local transport parameters; or > > o ICE ufrag value > > This seems to say that if there is no tls-id attribute, then an ICE restart > (which necessitates a ufrag change) requires a DTLS restart. JSEP isn't > incredibly clear on this point, but 5.7.3 seems to say that tls-id > need not be present: > > * tls-id value, which MUST be set according to > [I-D.ietf-mmusic-dtls-sdp], Section 5. If this is a re-offer > and the tls-id value is different from that presently in use, > the DTLS connection is not being continued and the remote > description MUST be part of an ICE restart, together with new > ufrag and password values. If this is an answer, the tls-id > value, if present, MUST be the same as in the offer. > > I believe that the first sentence is in error, as we clearly > can't have JSEP implementations requiring that tls-id be present. > > ... > > o If the remote DTLS fingerprint has been changed or the tls-id has > changed, tear down the DTLS connection. This includes the case > when the PeerConnection state is "have-remote-pranswer". If a > DTLS connection needs to be torn down but the answer does not > indicate an ICE restart or, in the case of "have-remote-pranswer", > new ICE credentials, an error MUST be generated. If an ICE > restart is performed without a change in tls-id or fingerprint, > then the same DTLS connection is continued over the new ICE > channel. > > I think the best interpretation of this is that if tls-id is not present > (and hence unchanged) then ICE restart does not cause DTLS restart. > This is also my memory of the consensus in RTCWEB. In any case, these > two documents clearly must match. > > > My observations/recommendations: > > 1. (Issue 1a) EKR is correct that the first sentence of the bullet > from JSEP needs to be removed so as to enable interoperation with non-JSEP > implementations. > > 2. (Issue 1b) Additionally the final sentence of that bullet ("If this > is an answer, the tls-id value, if present, MUST be the same as in the > offer") conflicts with the definition of tls-id ("the offerer and answerer > generate their own local 'tls-id' attribute values, and the combination of > both values identify the DTLS association"). In this case, the DTLS-SDP > document would appear to be correct (the fact that the two parties choose > different IDs is integral to the mechanism's design), so JSEP needs to > change. > > 3. (Issue 1c) The crux of the matter: does ICE restart cause DTLS to > restart? The primary rationale outlined in RFC5245 for restarting ICE is > changing the destination (IP address or port) of an ongoing media stream -- > which would commonly involve changing to a different physical device. While > it would, in theory, be possible to transfer the TLS state associated with > the connection between devices, this is rather cumbersome (and, as far as I > know, not generally supported by TLS libraries). From that perspective, it > is my opinion that the DTLS-SDP document is correct that an ICE restart > necessitates a new DTLS connection; and I conclude that JSEP needs to > change. > > > Issue 2 (quoting EKR): > > 2. S 4 says: > > The mux category [I-D.ietf-mmusic-sdp-mux-attributes] for the 'tls- > id' attribute is 'IDENTICAL', which means that the attribute value > must be identical across all media descriptions being multiplexed > [I-D.ietf-mmusic-sdp-bundle-negotiation]. > > This is not actually what JSEP requires: > > different categories. To avoid unnecessary duplication when > bundling, attributes of category IDENTICAL or TRANSPORT MUST NOT be > repeated in bundled m= sections, repeating the guidance from > [I-D.ietf-mmusic-sdp-bundle-negotiation], Section 8.1. This includes > > I suspect this is old text. > > > (Issue 2) JSEP is aligned with draft-ietf-mmusic-sdp-bundle-negotiation-38, > while DTLS-SDP does not. This is a largely aesthetic decision (although the > JSEP/BUNDLE approach does save a tiny handful of bytes), but I think > changing one document (DTLS-SDP) makes more sense than changing two. (I > suspect the BUNDLE formulation more closely tracks consensus anyway). > > > /a > > _______________________________________________ > mmusic mailing list > mmusic@ietf.org > https://www.ietf.org/mailman/listinfo/mmusic > > --001a114e22f0fa5b3a0557e41ae2 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
On Issue 1, Adam said:=C2=A0

"
  1. (Issue 1c) = The crux of the matter: does ICE restart cause DTLS to restart? The primary= rationale outlined in RFC5245 for restarting ICE is changing the destinati= on (IP address or port) of an ongoing media stream -- which would commonly = involve changing to a different physical device. While it would, in theory,= be possible to transfer the TLS state associated with the connection betwe= en devices, this is rather cumbersome (and, as far as I know, not generally= supported by TLS libraries). From that perspective, it is my opinion that = the DTLS-SDP document is correct that an ICE restart necessitates a new DTL= S connection; and I conclude that JSEP needs to change.
"= ;

[BA] Agree that for consistency, it is best for = an ICE restart to necessitate a new DTLS connection, since an ICE restart c= an result in connection to a different device (and the need for a new DTLS = connection).=C2=A0=C2=A0

On Fri, Aug 25, 2017 at 4:30 PM, Adam Roach <adam@nostru= m.com> wrote:
=20 =20 =20

MMUSIC --

[I will be posting a separate message to RTCWEB directing interested parties to discuss this issue on the MMUSIC mailing list]

During the IESG review of draft-ietf-mmusic-dtls-sdp, EKR identified some conflicts between the procedures in DTLS-SDP and JSEP were identified. This note is an attempt to summarize them. I have also made an initial proposal, for each conflict, regarding which document needs to change, in and which way.

Issue 1 (quoting EKR), which raises a couple of additional sub-issues:

        

    


    

    
/a

_______________________________________________
mmusic mailing list
mmusic@ietf.org
https://www.ietf.org/mailman/listinfo/mmusic

--001a114e22f0fa5b3a0557e41ae2-- From nobody Wed Aug 30 02:32:00 2017 Return-Path: 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 572D2132D45; Wed, 30 Aug 2017 02:31:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.221 X-Spam-Level: X-Spam-Status: No, score=-4.221 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=ham autolearn_force=no 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 XZ6XgGhO-IwK; Wed, 30 Aug 2017 02:31:50 -0700 (PDT) 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 4E0171326FE; Wed, 30 Aug 2017 02:31:49 -0700 (PDT) X-AuditID: c1b4fb2d-4e93a9c0000057a4-58-59a68603c956 Received: from ESESSHC021.ericsson.se (Unknown_Domain [153.88.183.81]) by sessmg23.ericsson.net (Symantec Mail Security) with SMTP id 25.E2.22436.30686A95; Wed, 30 Aug 2017 11:31:47 +0200 (CEST) Received: from ESESSMB109.ericsson.se ([169.254.9.194]) by ESESSHC021.ericsson.se ([153.88.183.81]) with mapi id 14.03.0352.000; Wed, 30 Aug 2017 11:31:42 +0200 From: Christer Holmberg To: Adam Roach , Ben Campbell , "Eric Rescorla" , Alexey Melnikov , =?iso-8859-1?Q?Mirja_K=FChlewind?= , Roman Shpount CC: "draft-ietf-mmusic-dtls-sdp@ietf.org" , "mmusic-chairs@ietf.org" , "mmusic@ietf.org" , The IESG Thread-Topic: Adam Roach's No Objection on draft-ietf-mmusic-dtls-sdp-28: (with COMMENT) - All comments should now have been addressed Thread-Index: AQHTIXLJNIlpz3f/yE6ODK9en612cQ== Date: Wed, 30 Aug 2017 09:31:42 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.7.4.170508 x-originating-ip: [153.88.183.17] Content-Type: text/plain; charset="iso-8859-1" Content-ID: <5F14731844F060489BB0CD7B13B8FBC3@ericsson.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFjrGIsWRmVeSWpSXmKPExsUyM2J7oC5z27JIgyuzpCz2vz/EZLHn7yJ2 i/mdp9kt/k+cz2qx4vU5dosZfyYyW7y4/pHZ4vzO9UwWU5c/ZrG4/nQXiwOXx85TB9g8liz5 yeTR8nEhq8esnU9YPCY/bmP22Pr3L1sAWxSXTUpqTmZZapG+XQJXxse/j1kLLjJXbF93lbWB 8TNTFyMnh4SAicTJBzuAbC4OIYEjjBJnWzexQThLGCWWrV4N5HBwsAlYSHT/0waJiwh8ZZS4 8ugxK4jDLHCcUWLF6pNgHcIC7YwSj14cYoco62CU2Lv+ECPIEhEBPYkjt2eyg9gsAqoSj2b+ YQGxeQWsJW5PW8EMYjMKiEl8P7UG7ChmAXGJW0/mQx0oILFkz3lmCFtU4uXjf6wgJ4kCzXy3 3xPElBBQlFjeLwfRqSdxY+oUNgjbWmLL5rdQtrbEsoWvmSG2CkqcnPmEZQKj6Cwky2YhaZ+F pH0WkvZZSNoXMLKuYhQtTi0uzk03MtZLLcpMLi7Oz9PLSy3ZxAiM3YNbfuvuYFz92vEQowAH oxIPr2Thskgh1sSy4srcQ4wSHMxKIrxZDUAh3pTEyqrUovz4otKc1OJDjNIcLErivA77LkQI CaQnlqRmp6YWpBbBZJk4OKUaGOVDjLn+M/eExjkuZNrP7xCf9usnv0ChY5v8s/VJ5uJMxh4H XW4oSd8027RGqWG29BGxfT6tbqHigpnnE3tXs5xYODHzZFW6m+qOlcIs7667PP7gqrbZtqTO 7Y6fc8Tjso4ZenoTjMtkdJonvLty45pAcPE3RfPJHC/vLr68Z8dZyde7ba5sVmIpzkg01GIu Kk4EAENqZlTZAgAA Archived-At: Subject: Re: [MMUSIC] Adam Roach's No Objection on draft-ietf-mmusic-dtls-sdp-28: (with COMMENT) - All comments should now have been addressed X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 30 Aug 2017 09:31:52 -0000 Hi, I have updated the PR. It should now address the IESG comments given by Adam, Ekr, Alexey and Mirja. https://github.com/cdh4u/draft-dtls-sdp/pull/35 In the latest commit (#7): - Section 7 (Transport Protocol Considerations) was removed. - Text regarding correlation of SDP and TLS connection was added to the Security Considerations (as requested by Mirja). Please let me know if there is something I=B9ve forgot. Regards, Christer From nobody Wed Aug 30 11:03:47 2017 Return-Path: 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 E981F132518; Wed, 30 Aug 2017 11:03:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.88 X-Spam-Level: X-Spam-Status: No, score=-1.88 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, T_SPF_HELO_PERMERROR=0.01, T_SPF_PERMERROR=0.01] autolearn=ham autolearn_force=no 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 UEdwJPIhWUoU; Wed, 30 Aug 2017 11:03:44 -0700 (PDT) Received: from nostrum.com (raven-v6.nostrum.com [IPv6:2001:470:d:1130::1]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 015B1132803; Wed, 30 Aug 2017 11:03:43 -0700 (PDT) Received: from Orochi.local (99-152-146-228.lightspeed.dllstx.sbcglobal.net [99.152.146.228]) (authenticated bits=0) by nostrum.com (8.15.2/8.15.2) with ESMTPSA id v7UI3Ywo049449 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NO); Wed, 30 Aug 2017 13:03:35 -0500 (CDT) (envelope-from adam@nostrum.com) X-Authentication-Warning: raven.nostrum.com: Host 99-152-146-228.lightspeed.dllstx.sbcglobal.net [99.152.146.228] claimed to be Orochi.local To: Christer Holmberg , Ben Campbell , Eric Rescorla , Alexey Melnikov , =?UTF-8?Q?Mirja_K=c3=bchlewind?= , Roman Shpount Cc: "draft-ietf-mmusic-dtls-sdp@ietf.org" , "mmusic-chairs@ietf.org" , "mmusic@ietf.org" , The IESG References: From: Adam Roach Message-ID: <244f9778-9cc4-eb99-bec1-f1905e7ec00e@nostrum.com> Date: Wed, 30 Aug 2017 13:03:29 -0500 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:52.0) Gecko/20100101 Thunderbird/52.3.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Content-Language: en-US Archived-At: Subject: Re: [MMUSIC] Adam Roach's No Objection on draft-ietf-mmusic-dtls-sdp-28: (with COMMENT) - All comments should now have been addressed X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 30 Aug 2017 18:03:46 -0000 On 8/30/17 04:31, Christer Holmberg wrote: > Hi, > > I have updated the PR. It should now address the IESG comments given by > Adam, Ekr, Alexey and Mirja. > > https://github.com/cdh4u/draft-dtls-sdp/pull/35 > > > In the latest commit (#7): > > - Section 7 (Transport Protocol Considerations) was removed. > - Text regarding correlation of SDP and TLS connection was added to the > Security Considerations (as requested by Mirja). > > Please let me know if there is something I¹ve forgot. The list of issues I posted to MMUSIC included the question about whether ufrag change requires a DTLS restart in the absence of a 'tls-id'. There was a bit of discussion on that list which seemed to conclude that it should *not*. I believe the document needs to reflect this -- but I'd specifically ask the MMUSIC chairs whether they see consensus on this point first. On the topic of looking over your changes: it's still easier to read a text-form document than digging through XML source. Version numbers are free. I encourage you to drop a new version whenever you ask people to look at changes. /a From nobody Wed Aug 30 12:28:16 2017 Return-Path: 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 3F7B4132932; Wed, 30 Aug 2017 12:28:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.88 X-Spam-Level: X-Spam-Status: No, score=-1.88 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, T_SPF_HELO_PERMERROR=0.01, T_SPF_PERMERROR=0.01] autolearn=ham autolearn_force=no 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 ENg-QzR1s576; Wed, 30 Aug 2017 12:28:06 -0700 (PDT) Received: from nostrum.com (raven-v6.nostrum.com [IPv6:2001:470:d:1130::1]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C805A13248B; Wed, 30 Aug 2017 12:28:04 -0700 (PDT) Received: from [10.0.1.63] (cpe-66-25-7-22.tx.res.rr.com [66.25.7.22]) (authenticated bits=0) by nostrum.com (8.15.2/8.15.2) with ESMTPSA id v7UJRt1X064024 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NO); Wed, 30 Aug 2017 14:27:56 -0500 (CDT) (envelope-from ben@nostrum.com) X-Authentication-Warning: raven.nostrum.com: Host cpe-66-25-7-22.tx.res.rr.com [66.25.7.22] claimed to be [10.0.1.63] Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) From: Ben Campbell In-Reply-To: <244f9778-9cc4-eb99-bec1-f1905e7ec00e@nostrum.com> Date: Wed, 30 Aug 2017 14:27:55 -0500 Cc: Eric Rescorla , Adam Roach , Alexey Melnikov , =?utf-8?Q?Mirja_K=C3=BChlewind?= , Roman Shpount , "draft-ietf-mmusic-dtls-sdp@ietf.org" , "mmusic@ietf.org" , The IESG Content-Transfer-Encoding: quoted-printable Message-Id: References: <244f9778-9cc4-eb99-bec1-f1905e7ec00e@nostrum.com> To: Christer Holmberg , "mmusic-chairs@ietf.org" X-Mailer: Apple Mail (2.3273) Archived-At: Subject: Re: [MMUSIC] Adam Roach's No Objection on draft-ietf-mmusic-dtls-sdp-28: (with COMMENT) - All comments should now have been addressed X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 30 Aug 2017 19:28:08 -0000 > On Aug 30, 2017, at 1:03 PM, Adam Roach wrote: >=20 > On 8/30/17 04:31, Christer Holmberg wrote: >> Hi, >>=20 >> I have updated the PR. It should now address the IESG comments given = by >> Adam, Ekr, Alexey and Mirja. >>=20 >> https://github.com/cdh4u/draft-dtls-sdp/pull/35 >>=20 >>=20 >> In the latest commit (#7): >>=20 >> - Section 7 (Transport Protocol Considerations) was removed. >> - Text regarding correlation of SDP and TLS connection was added to = the >> Security Considerations (as requested by Mirja). >>=20 >> Please let me know if there is something I=C2=B9ve forgot. >=20 > The list of issues I posted to MMUSIC included the question about = whether ufrag change requires a DTLS restart in the absence of a = 'tls-id'. There was a bit of discussion on that list which seemed to = conclude that it should *not*. I believe the document needs to reflect = this -- but I'd specifically ask the MMUSIC chairs whether they see = consensus on this point first. I concur. Chairs, what do you think? >=20 > On the topic of looking over your changes: it's still easier to read a = text-form document than digging through XML source. Version numbers are = free. I encourage you to drop a new version whenever you ask people to = look at changes. I agree here, too. Christer, can you submit a revision with the changes = so far? Thanks! Ben.= From nobody Wed Aug 30 12:32:58 2017 Return-Path: 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 CD46E1326EA; Wed, 30 Aug 2017 12:32:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.521 X-Spam-Level: X-Spam-Status: No, score=-14.521 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_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.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 ICXxTLtpnMgW; Wed, 30 Aug 2017 12:32:54 -0700 (PDT) Received: from rcdn-iport-2.cisco.com (rcdn-iport-2.cisco.com [173.37.86.73]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8C179132941; Wed, 30 Aug 2017 12:32:54 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1617; q=dns/txt; s=iport; t=1504121574; x=1505331174; h=subject:to:cc:references:from:message-id:date: mime-version:in-reply-to:content-transfer-encoding; bh=lYasAyQz8dZkFizBDIy6/Vxo8FwjUYXl9GemgG/N5YE=; b=RnB/Ctehz96R5GG7S4waP2cBewfU+8K3FdYSvJTAiRjINskgHoWkJLxv kedyY8zUP66EQVje6PTr9wHxvnDFkIymnNkUG9fPt2wk7UDKisYlrqu0J 8tsdi7kxq7x0XM/dyyJcrDMlvytcKVfOWuPESU8xRcAtJVz1SWJYO66x5 g=; X-IronPort-AV: E=Sophos;i="5.41,449,1498521600"; d="scan'208";a="292423755" Received: from rcdn-core-12.cisco.com ([173.37.93.148]) by rcdn-iport-2.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 30 Aug 2017 19:32:53 +0000 Received: from [10.118.10.21] (rtp-fandreas-2-8814.cisco.com [10.118.10.21]) by rcdn-core-12.cisco.com (8.14.5/8.14.5) with ESMTP id v7UJWqsC022953; Wed, 30 Aug 2017 19:32:52 GMT To: Ben Campbell , Christer Holmberg , "mmusic-chairs@ietf.org" , Cullen Jennings , Justin Uberti Cc: Eric Rescorla , Adam Roach , Alexey Melnikov , =?UTF-8?Q?Mirja_K=c3=bchlewind?= , Roman Shpount , "draft-ietf-mmusic-dtls-sdp@ietf.org" , "mmusic@ietf.org" , The IESG References: <244f9778-9cc4-eb99-bec1-f1905e7ec00e@nostrum.com> From: Flemming Andreasen Message-ID: <3f9b6282-6f7a-3ef3-23ee-c314d062a32c@cisco.com> Date: Wed, 30 Aug 2017 15:32:52 -0400 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.11; rv:52.0) Gecko/20100101 Thunderbird/52.3.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Content-Language: en-US Archived-At: Subject: Re: [MMUSIC] Adam Roach's No Objection on draft-ietf-mmusic-dtls-sdp-28: (with COMMENT) - All comments should now have been addressed X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 30 Aug 2017 19:32:57 -0000 On 8/30/17 3:27 PM, Ben Campbell wrote: >> On Aug 30, 2017, at 1:03 PM, Adam Roach wrote: >> >> On 8/30/17 04:31, Christer Holmberg wrote: >>> Hi, >>> >>> I have updated the PR. It should now address the IESG comments given by >>> Adam, Ekr, Alexey and Mirja. >>> >>> https://github.com/cdh4u/draft-dtls-sdp/pull/35 >>> >>> >>> In the latest commit (#7): >>> >>> - Section 7 (Transport Protocol Considerations) was removed. >>> - Text regarding correlation of SDP and TLS connection was added to the >>> Security Considerations (as requested by Mirja). >>> >>> Please let me know if there is something I¹ve forgot. >> The list of issues I posted to MMUSIC included the question about whether ufrag change requires a DTLS restart in the absence of a 'tls-id'. There was a bit of discussion on that list which seemed to conclude that it should *not*. I believe the document needs to reflect this -- but I'd specifically ask the MMUSIC chairs whether they see consensus on this point first. > I concur. > > Chairs, what do you think? I would like to hear from a few more people first (and in particular some of the traditional stakeholders such as EKR, Cullen and Justin). Thanks -- Flemming (as MMUSIC co-chair) >> On the topic of looking over your changes: it's still easier to read a text-form document than digging through XML source. Version numbers are free. I encourage you to drop a new version whenever you ask people to look at changes. > I agree here, too. Christer, can you submit a revision with the changes so far? > > Thanks! > > Ben.. > From nobody Wed Aug 30 13:08:04 2017 Return-Path: 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 1E73F1329E3 for ; Wed, 30 Aug 2017 13:08:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.254 X-Spam-Level: X-Spam-Status: No, score=-1.254 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_SOFTFAIL=0.665] autolearn=no autolearn_force=no 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 9IF3kzxrnaaR for ; Wed, 30 Aug 2017 13:08:00 -0700 (PDT) Received: from smtp114.ord1c.emailsrvr.com (smtp114.ord1c.emailsrvr.com [108.166.43.114]) (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 7FB6C132955 for ; Wed, 30 Aug 2017 13:07:59 -0700 (PDT) Received: from smtp23.relay.ord1c.emailsrvr.com (localhost [127.0.0.1]) by smtp23.relay.ord1c.emailsrvr.com (SMTP Server) with ESMTP id 5F396401E0; Wed, 30 Aug 2017 16:07:51 -0400 (EDT) X-Auth-ID: fluffy@iii.ca Received: by smtp23.relay.ord1c.emailsrvr.com (Authenticated sender: fluffy-AT-iii.ca) with ESMTPSA id 61AB6401C7; Wed, 30 Aug 2017 16:07:50 -0400 (EDT) X-Sender-Id: fluffy@iii.ca Received: from dhcp-10-154-140-23.cisco.com ([UNAVAILABLE]. [128.107.241.189]) (using TLSv1 with cipher DHE-RSA-AES256-SHA) by 0.0.0.0:587 (trex/5.7.12); Wed, 30 Aug 2017 16:07:51 -0400 Content-Type: multipart/alternative; boundary="Apple-Mail=_3CD98E4E-EA92-4E49-A1EE-D85334DFF0E4" Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) From: "Cullen Jennings (fluffy)" In-Reply-To: <3f9b6282-6f7a-3ef3-23ee-c314d062a32c@cisco.com> Date: Wed, 30 Aug 2017 13:07:52 -0700 Cc: Ben Campbell , Christer Holmberg , "mmusic-chairs@ietf.org" , Justin Uberti , Eric Rescorla , Adam Roach , Alexey Melnikov , =?utf-8?Q?Mirja_K=C3=BChlewind?= , Roman Shpount , "draft-ietf-mmusic-dtls-sdp@ietf.org" , "mmusic@ietf.org" Message-Id: References: <244f9778-9cc4-eb99-bec1-f1905e7ec00e@nostrum.com> <3f9b6282-6f7a-3ef3-23ee-c314d062a32c@cisco.com> To: Flemming Andreasen X-Mailer: Apple Mail (2.3124) Archived-At: Subject: Re: [MMUSIC] Adam Roach's No Objection on draft-ietf-mmusic-dtls-sdp-28: (with COMMENT) - All comments should now have been addressed X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 30 Aug 2017 20:08:02 -0000 --Apple-Mail=_3CD98E4E-EA92-4E49-A1EE-D85334DFF0E4 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 It's been on my list to go and read all of this but hope to email = comments in early Sept.=20 > On Aug 30, 2017, at 12:32 PM, Flemming Andreasen (fandreas) = wrote: >=20 >=20 >=20 > On 8/30/17 3:27 PM, Ben Campbell wrote: >>> On Aug 30, 2017, at 1:03 PM, Adam Roach wrote: >>>=20 >>> On 8/30/17 04:31, Christer Holmberg wrote: >>>> Hi, >>>>=20 >>>> I have updated the PR. It should now address the IESG comments = given by >>>> Adam, Ekr, Alexey and Mirja. >>>>=20 >>>> https://github.com/cdh4u/draft-dtls-sdp/pull/35 >>>>=20 >>>>=20 >>>> In the latest commit (#7): >>>>=20 >>>> - Section 7 (Transport Protocol Considerations) was removed. >>>> - Text regarding correlation of SDP and TLS connection was added to = the >>>> Security Considerations (as requested by Mirja). >>>>=20 >>>> Please let me know if there is something I=C2=B9ve forgot. >>> The list of issues I posted to MMUSIC included the question about = whether ufrag change requires a DTLS restart in the absence of a = 'tls-id'. There was a bit of discussion on that list which seemed to = conclude that it should *not*. I believe the document needs to reflect = this -- but I'd specifically ask the MMUSIC chairs whether they see = consensus on this point first. >> I concur. >>=20 >> Chairs, what do you think? > I would like to hear from a few more people first (and in particular = some of the traditional stakeholders such as EKR, Cullen and Justin). >=20 > Thanks >=20 > -- Flemming (as MMUSIC co-chair) >=20 >=20 >>> On the topic of looking over your changes: it's still easier to read = a text-form document than digging through XML source. Version numbers = are free. I encourage you to drop a new version whenever you ask people = to look at changes. >> I agree here, too. Christer, can you submit a revision with the = changes so far? >>=20 >> Thanks! >>=20 >> Ben.. --Apple-Mail=_3CD98E4E-EA92-4E49-A1EE-D85334DFF0E4 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8

It's = been on my list to go and read all of this but hope to email comments in = early Sept. 

On Aug 30, 2017, at 12:32 PM, Flemming = Andreasen (fandreas) <fandreas@cisco.com> wrote:



On 8/30/17 3:27 PM, Ben Campbell = wrote:
On Aug 30, 2017, at 1:03 PM, Adam Roach <adam@nostrum.com> = wrote:

On 8/30/17 04:31, Christer Holmberg = wrote:
Hi,

I have updated the PR. It should now address = the IESG comments given by
Adam, Ekr, Alexey and Mirja.

https://github.com/cdh4u/draft-dtls-sdp/pull/35


In the latest commit (#7):

- Section 7 (Transport Protocol = Considerations) was removed.
- Text regarding correlation = of SDP and TLS connection was added to the
Security = Considerations (as requested by Mirja).

Please let me know if there is something I=C2=B9ve forgot.
The list of issues I posted to MMUSIC included = the question about whether ufrag change requires a DTLS restart in the = absence of a 'tls-id'. There was a bit of discussion on that list which = seemed to conclude that it should *not*. I believe the document needs to = reflect this -- but I'd specifically ask the MMUSIC chairs whether they = see consensus on this point first.
I = concur.

Chairs, what do you think?
I would like to hear from = a few more people first (and in particular some of the traditional = stakeholders such as EKR, Cullen and Justin).

Thanks

-- Flemming (as MMUSIC co-chair)


On the topic of looking over your changes: = it's still easier to read a text-form document than digging through XML = source. Version numbers are free. I encourage you to drop a new version = whenever you ask people to look at changes.
I = agree here, too. Christer, can you submit a revision with the changes so = far?

Thanks!

Ben..

= --Apple-Mail=_3CD98E4E-EA92-4E49-A1EE-D85334DFF0E4-- From nobody Wed Aug 30 13:22:04 2017 Return-Path: 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 0208C1321C7; Wed, 30 Aug 2017 13:22:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.521 X-Spam-Level: X-Spam-Status: No, score=-14.521 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_HI=-5, RCVD_IN_MSPIKE_H4=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.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 6O-0-JEhTneh; Wed, 30 Aug 2017 13:22:01 -0700 (PDT) Received: from rcdn-iport-8.cisco.com (rcdn-iport-8.cisco.com [173.37.86.79]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CAD7B1326EC; Wed, 30 Aug 2017 13:21:59 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=489; q=dns/txt; s=iport; t=1504124519; x=1505334119; h=to:cc:from:subject:message-id:date:mime-version: content-transfer-encoding; bh=Sn3PKeQx5KbSQq9Con8yqk9zySGOtY3VT2pAs4oVUM0=; b=igHRZ5G4O1j5V0k58WqsuYlAL4/yFGsCuV1SfLnb8if/U67hcTM5L+af 6HeAli2jvPGBMNTUeqhQmPSjjrwO9xAvNf8o4RyqGayLfAOSWoeBuWsjb zWWIIOh9MtW7RTOuZx7HMTW4689dWBO9Ak5a6mnL70QLTmx82KXgZsaeB E=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0CzAgAlHadZ/4kNJK1eGgEBAQECAQEBA?= =?us-ascii?q?QgBAQEBg1pkgRWDd5o8mBiCEiyFG4QpQRYBAgEBAQEBAQFrKIVCDwEFQTUCJgJ?= =?us-ascii?q?fDQgBAYogDRCtKoIni0QBAQEBAQEBAwEBAQEBAQEBAQEZBYENgh2CAoFOgWMri?= =?us-ascii?q?wWCYQEEoGyUTIF6GIVng1mFUIFJlkMmCCmBDVMkFUmHNyQ2AYsLAQEB?= X-IronPort-AV: E=Sophos;i="5.41,449,1498521600"; d="scan'208";a="287593545" Received: from alln-core-4.cisco.com ([173.36.13.137]) by rcdn-iport-8.cisco.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 30 Aug 2017 20:21:59 +0000 Received: from [10.118.10.21] (rtp-fandreas-2-8814.cisco.com [10.118.10.21]) by alln-core-4.cisco.com (8.14.5/8.14.5) with ESMTP id v7UKLw52002510; Wed, 30 Aug 2017 20:21:58 GMT To: mmusic Cc: "draft-ietf-mmusic-trickle-ice-sip@ietf.org" From: Flemming Andreasen Message-ID: <50b57d8c-127d-419d-9da3-7141adf13402@cisco.com> Date: Wed, 30 Aug 2017 16:21:58 -0400 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.11; rv:52.0) Gecko/20100101 Thunderbird/52.3.0 MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Content-Language: en-US Archived-At: Subject: [MMUSIC] WGLC on draft-ietf-mmusic-trickle-ice-sip-08 X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 30 Aug 2017 20:22:03 -0000 Greetings MMUSIC This is to announce a 2 week WGLC on the  draft: https://www.ietf.org/id/draft-ietf-mmusic-trickle-ice-sip-08.txt as Proposed Standard. Please review and provide any comments you may have on the document by Wednesday, September 13, 2017. Comments should be sent to the document authors and the MMUSIC WG list. If you review the document but do not have any comments, please send a note to that effect as well. Thanks -- Flemming (MMUSIC co-chair) From nobody Wed Aug 30 13:44:03 2017 Return-Path: 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 24EFA132153 for ; Wed, 30 Aug 2017 13:44:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.521 X-Spam-Level: X-Spam-Status: No, score=-14.521 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_HI=-5, RCVD_IN_MSPIKE_H4=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.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 IgHwcvGIZLGm for ; Wed, 30 Aug 2017 13:43:59 -0700 (PDT) Received: from rcdn-iport-8.cisco.com (rcdn-iport-8.cisco.com [173.37.86.79]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5CBC11252BA for ; Wed, 30 Aug 2017 13:43:59 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=525; q=dns/txt; s=iport; t=1504125839; x=1505335439; h=to:cc:from:subject:message-id:date:mime-version: content-transfer-encoding; bh=Q1sBX2fxRN+5hDTIcQWAZPmLq9Wwy51eUAwjhKJWw0o=; b=aMuKKqkqRYP11/gJTpMpi8L5tQunbun16KPQ9uWzc2qlC/CQEkOumsbR Ao6ZvTbARYYBtZZUG08Gl/lrM5QS04DvzflUAKcyCTMoBz8wdZ00m+mnu FoG+SRYy7X88272QJTQGTGNZ97PIL6zPTRJ6Pb1m5ixUxY2ry760SWstG Q=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0DaAwAKI6dZ/5ldJa1eGgEBAQECAQEBA?= =?us-ascii?q?QgBAQEBg1pkgRWDd5o8gU+WSYISLIUbhClBFgECAQEBAQEBAWsohUIVQTUCJgJ?= =?us-ascii?q?fDQgBAYogDRCtKIIni0QBAQEBAQEBAwEBAQEBAR0FgQ2CHYICgU6CDguKeoJhA?= =?us-ascii?q?QSgbIFrkmGBehiFZ4NZhxmWQyYCL4ENUyQVSYc3JDYBiwsBAQE?= X-IronPort-AV: E=Sophos;i="5.41,450,1498521600"; d="scan'208";a="287600435" Received: from rcdn-core-2.cisco.com ([173.37.93.153]) by rcdn-iport-8.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 30 Aug 2017 20:43:58 +0000 Received: from [10.118.10.21] (rtp-fandreas-2-8814.cisco.com [10.118.10.21]) by rcdn-core-2.cisco.com (8.14.5/8.14.5) with ESMTP id v7UKhwd2001038; Wed, 30 Aug 2017 20:43:58 GMT To: mmusic From: Flemming Andreasen Message-ID: <1e0cdc97-5e3e-c471-9800-18bbc846e98f@cisco.com> Date: Wed, 30 Aug 2017 16:43:57 -0400 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.11; rv:52.0) Gecko/20100101 Thunderbird/52.3.0 MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Content-Language: en-US Archived-At: Subject: [MMUSIC] Getting ready to progress 4566bis (SDP) X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 30 Aug 2017 20:44:01 -0000 Hi MMUSIC It's been a while since we saw any open issues or discussions around 4566bis (https://www.ietf.org/id/draft-ietf-mmusic-rfc4566bis-22.txt) and the author is also not aware of any open issues at this point. Based on that, we are getting ready to start progressing the draft, however we wanted to give people a heads-up in case of any lingering issues people want to raise. If you have any, please send an e-mail to the list and the author at this point. Thanks -- Flemming (as MMUSIC co-chair) From nobody Wed Aug 30 13:45:35 2017 Return-Path: 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 3E5511252BA for ; Wed, 30 Aug 2017 13:45:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.521 X-Spam-Level: X-Spam-Status: No, score=-14.521 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_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.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 G6pjQ0Tt5YXG for ; Wed, 30 Aug 2017 13:45:30 -0700 (PDT) Received: from alln-iport-8.cisco.com (alln-iport-8.cisco.com [173.37.142.95]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A6B4D132027 for ; Wed, 30 Aug 2017 13:45:29 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=26133; q=dns/txt; s=iport; t=1504125929; x=1505335529; h=subject:to:cc:references:from:message-id:date: mime-version:in-reply-to:content-transfer-encoding; bh=ac3t0hR0TtobIh0DZtMiiT8rP8cm+g03eylij4z/Epw=; b=POTeH5aOXFbWxe+mUbWAxDqzbTx8Qm1LqF8V5fBOHj9sy7srxtCFFZQG HyHaE55zenruwEcIShxpL1KSHBonii1SdWL+xA0Bpi6rWIVcKx4pBgHMH VPbozO50ugJaavr5/bk8f/MFhcm0aNtpXwjPVak32sbkHTeMt5RryW1Th 4=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0DfAAAKI6dZ/5RdJa1UChkBAQEBAQEBA?= =?us-ascii?q?QEBAQcBAQEBAYNaZIEVjhWQHoFPIneVMA6CAQMhC4RMTwKEJz8YAQIBAQEBAQE?= =?us-ascii?q?BayiFGAEBAQEDAQEYDQsBBS8HCwwECxEEAQEBFRIHJx8JCAYBDAYCAQEQihANE?= =?us-ascii?q?K8VOotEAQEBAQEBAQEBAQEBAQEBAQEBAQEBGAWDKoICgU6BYysLgj01hDAaE1e?= =?us-ascii?q?FNQEEmBeIVYdZgRKBfkmJGoIShWeDWYFNhUyJd4xMHziBDVMkFUmFGByCAyQ2i?= =?us-ascii?q?wwBAQE?= X-IronPort-AV: E=Sophos;i="5.41,450,1498521600"; d="scan'208";a="479062327" Received: from rcdn-core-12.cisco.com ([173.37.93.148]) by alln-iport-8.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 30 Aug 2017 20:45:27 +0000 Received: from [10.118.10.21] (rtp-fandreas-2-8814.cisco.com [10.118.10.21]) by rcdn-core-12.cisco.com (8.14.5/8.14.5) with ESMTP id v7UKjR6S004428; Wed, 30 Aug 2017 20:45:27 GMT To: Christer Holmberg , Colin Perkins Cc: "mmusic (E-mail)" References: <0E29A586-1532-498D-86D2-D787D3F9FD3E@csperkins.org> <7594FB04B1934943A5C02806D1A2204B4CB5BA24@ESESSMB102.ericsson.se> From: Flemming Andreasen Message-ID: Date: Wed, 30 Aug 2017 16:45:26 -0400 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.11; rv:52.0) Gecko/20100101 Thunderbird/52.3.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit Content-Language: en-US Archived-At: Subject: Re: [MMUSIC] Comments on BUNDLE -37 - RTP handling X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 30 Aug 2017 20:45:34 -0000 As you said Christer, nobody has objected or provided an alternative suggestion, so please proceed with the suggested text. Thanks -- Flemming (as MMUSIC co-chair) On 8/28/17 6:17 AM, Christer Holmberg wrote: > Hi, > > Nobody has objected to Colins text, so my suggested is to now merge the > PR. > > Regards, > > Christer > > > > On 18/07/17 16:42, "Colin Perkins" wrote: > >> Hi Christer, >> >> As discussed - pull request submitted. >> Colin >> >> >> >>> On 9 Apr 2017, at 08:54, Christer Holmberg >>> wrote: >>> >>> Hi Colin, >>> >>> Thanks for your input! >>> >>> Would it be possible for you to create a pull request with your >>> suggested changes? >>> >>> BUNDLE can be found at: https://github.com/cdh4u/draft-sdp-bundle >>> >>> Regards, >>> >>> Christer >>> >>> -----Original Message----- >>> From: mmusic [mailto:mmusic-bounces@ietf.org] On Behalf Of Colin Perkins >>> Sent: 07 April 2017 20:06 >>> To: mmusic (E-mail) >>> Subject: [MMUSIC] Comments on BUNDLE -37 - RTP handling >>> >>> I have some comments on BUNDLE -37 - apologies that I wasnt able to >>> participate fully in the mailing list discussion before the meeting. >>> >>> The current text is generally reasonably clear, and is certainly >>> precisely written, but I do think it has some problems. Most of these >>> relate to the issue of whether RTP packets or RTP streams are being >>> processed. I think its important that this draft is written in terms of >>> how to associate RTP streams with m= lines, rather than how to route and >>> demultiplex RTP packets, since RTP packet routing and demultiplexing is >>> already specified by the various RTP specifications. In particular, >>> there are some places where the draft as written conflates the two >>> layers in ways that conflict with the RTP and RTCP specifications, that >>> Ive tried to correct by more cleanly separating the layers. >>> >>> Ive tried to write my suggestions in a prescriptive manner, keeping to >>> the style of the existing text where possible. Hopefully the result is >>> clear and understandable. >>> >>> Comments line below: >>> >>>> 10.2. Associating RTP/RTCP Streams With Correct SDP Media Description >>>> >>>> NOTE: The text in this section is copied from Appendix B of JSEP. >>>> The community has not yet agreed on the text. >>>> >>>> As described in [RFC3550], RTP packets are associated with RTP >>>> streams [RFC7656]. Each RTP stream is identified by an SSRC value, >>>> and each RTP packet includes an SSRC field that is used to associate >>>> the packet with the correct RTP stream. RTCP packets also use SSRCs >>>> to identify which RTP streams the packet relates to. However, a RTCP >>>> packet can contain multiple SSRC fields, in the course of providing >>>> feedback or reports on different RTP streams, and therefore can be >>>> associated with multiple such streams. >>>> >>>> In order to be able to process received RTP/RTCP packets correctly, >>>> it must be possible to associate an RTP stream with the correct "m=" >>>> >>>> >>>> >>>> Holmberg, et al. Expires October 2, 2017 [Page >>>> 20] >>>> Internet-Draft Bundled media March >>>> 2017 >>>> >>>> >>>> line, as the "m=" line and SDP attributes associated with the "m=" >>>> line contain information needed to process the packets. >>>> >>>> As all RTP streams associated with a BUNDLE group use the same >>>> address:port combination for sending and receiving RTP/RTCP packets, >>>> the local address:port combination cannot be used to associate an RTP >>>> stream with the correct "m=" line. In addition, multiple RTP streams >>>> might be associated with the same "m=" line. >>>> >>>> An offerer and answerer can inform each other which SSRC values they >>>> will use for an RTP stream by using the SDP 'ssrc' attribute >>>> [RFC5576]. However, an offerer will not know which SSRC values the >>>> answerer will use until the offerer has received the answer providing >>>> that information. Due to this, before the offerer has received the >>>> answer, the offerer will not be able to associate an RTP stream with >>>> the correct "m=" line using the SSRC value associated with the RTP >>>> stream. In addition, the offerer and answerer may start using new >>>> SSRC values mid-session, without informing each other using the SDP >>>> 'ssrc' attribute. >>>> >>>> In order for an offerer and answerer to always be able to associate >>>> an RTP stream with the correct "m=" line, the offerer and answerer >>>> using the BUNDLE extension MUST support the mechanism defined in >>>> section 14, where the offerer and answerer insert the identification- >>>> tag associated with an "m=" line (provided by the remote peer) into >>>> RTP and RTCP packets associated with a BUNDLE group. >>>> >>>> When using this mechanism, the mapping from an SSRC to an >>>> identification-tag is carried in RTP header extensions or RTCP SDES >>>> packets, as specified in section 14. Since a compound RTCP packet >>>> can contain multiple RTCP SDES packets, and each RTCP SDES packet can >>>> contain multiple chunks, a single RTCP packet can contain several >>>> SSRC to identification-tag mappings. The offerer and answerer >>>> maintain tables used for routing that are updated each time an RTP/ >>>> RTCP packet contains new information that affects how packets should >>>> be routed. >>> The text above looks good. In particular, it correctly focusses on >>> associating RTP streams with m= lines, which is the correct level of >>> abstraction. >>> >>>> However, some implementations of may not include this identification- >>>> tag in their RTP and RTCP traffic when using the BUNDLE mechanism, >>>> and instead use a payload type based mechanism for demuxing. In this >>> The term demuxing is unclear. For precision, I suggest changing use >>> a payload type based mechanisms for demuxing to use a payload type >>> based mechanism to associate RTP streams with SDP m= lines. >>> >>>> situation, each "m=" line MUST use unique payload type values, in >>>> order for the payload type to be a reliable indicator of the relevant >>>> "m=" line for the RTP stream. Note that when using payload type >>>> based demuxing, >>> Similarly, for precision, I suggest changing when using payload type >>> based demuxing to when using the payload type to associate RTP streams >>> with m= lines. >>> >>>> an SSRC will be mapped to an m= line >>> Suggest changing to an RTP stream, identified by SSRC, will be >>> mapped to be clear whats being done. >>> >>>> by the first >>>> packet with that SSRC, and the mapping will not be changed even if >>> Suggest changing to when the first RTP packet of that RTP stream is >>> received, and to be clear, since there could be RTCP packets with the >>> same SSRC. >>> >>>> the same SSRC is received with a different payload type. In other >>> Suggest changing to the payload type used by that RTP stream changes. >>> In other to be precise. >>> >>>> words, the SSRC cannot to "move" to a different "m=" line simply by >>>> changing the payload type. >>>> >>>> Holmberg, et al. Expires October 2, 2017 [Page >>>> 21] >>>> Internet-Draft Bundled media March >>>> 2017 >>>> >>>> >>>> Applications can implement RTP stacks in many different ways. The >>>> algorithm below details one way that demultiplexing can be >>>> accomplished, but is not meant to be prescriptive about exactly how >>> To be clear about what is being demultiplexed, I suggest changing one >>> way that demultiplexing can be accomplished to one way that RTP >>> streams can be associated with m= lines. >>> >>>> an RTP stack needs to be implemented. Applications MAY use any >>>> algorithm that achieves equivalent results to those described in the >>>> algorithm below. >>>> >>>> To prepare for demultiplexing RTP/RTCP packets to the correct "m=" >>>> line, the following steps MUST be followed for each BUNDLE group. >>> I suggest changing prepare for demultiplexing RTP/RTCP packets to the >>> correct to prepare to associate RTP streams with the correct. RTP >>> and RTCP packets are not demultiplexed to m= lines, theyre >>> demultiplexed into RTP streams, and then those RTP streams are >>> associated with m= lines. The distinction is important, in order to >>> implement RTCP correctly. >>> >>>> Construct a table mapping MID to "m=" line for each "m=" line in >>>> this BUNDLE group. Note that an "m=" line may only have one MID. >>>> >>>> Construct a table mapping incoming SSRC to "m=" line for each "m=" >>>> line in this BUNDLE group and for each SSRC configured for >>>> receiving in that m=" line. >>> The SSRC is a property of an RTP stream, so I suggest changing mapping >>> incoming SSRC to to mapping SSRCs of incoming RTP streams to. >>> >>>> Construct a table mapping outgoing SSRC to "m=line" for each "m=" >>>> line in this BUNDLE group and for each SSRC configured for sending >>>> in that m=" line. >>> Similarly, change mapping outgoing SSRC to mapping the SSRC of each >>> outgoing RTP stream >>> >>>> Construct a table mapping payload type to "m=" line for each "m=" >>>> line in the BUNDLE group and for each payload type configured for >>>> receiving in that "m=" line. If any payload type is configured >>>> for receiving in more than one "m=" line in the BUNDLE group, do >>>> not it include it in the table, as it cannot be used to uniquely >>>> identify a "m=" line. >>>> >>>> Note that for each of these tables, there can only be one mapping >>>> for any given key (MID, SSRC, or PT). In other words, the tables >>>> are not multimaps. >>>> >>>> As "m=" lines are added or removed from the BUNDLE groups, or their >>>> configurations are changed, the tables above MUST also be updated. >>>> >>>> For each RTP packet received, the following steps MUST be followed to >>>> route the packet to the correct "m=" section within a BUNDLE group. >>> The goal is not to route RTP packets to m= lines, but rather to >>> associate the corresponding RTP streams with m= lines. This keeps the >>> distinction between RTP and RTCP processing that has to happen >>> irrespective of the m= line, and the application level processing that >>> depends on the choice of m= line. I suggest changing this sentence to: >>> When an RTP packet is received, it MUST be delivered to the RTP stream >>> corresponding to its SSRC. That RTP stream MUST then be associated with >>> the correct m= line within a BUNDLE group, according to the following >>> steps. >>> >>>> Note that the phrase 'deliver a packet to the "m=" line' means to >>>> further process the packet as would normally happen with RTP/RTCP, if >>>> it were received on a transport associated with that "m=" line >>>> outside of a BUNDLE group (i.e., if the "m=" line were not BUNDLEd), >>>> including dropping an RTP packet if the packet's PT does not match >>>> any PT in the m=" line. >>> Dropping RTP packets with unknown payload type breaks RTCP. The RTP >>> packet must be processed by the RTP layer as normal, updating the >>> statistics that are maintained by RTCP. The payload is then discarded, >>> because theres no decoder associated with the payload type. I suggest >>> removing this part of the paragraph entirely. >>> >>>> If the packet has a MID, and that MID is not in the table mapping >>>> MID to m=" line, drop the packet and stop. >>> Dropping the RTP packet will break the RTCP reports. The RTP packet has >>> to be processed as normal, but the corresponding RTP stream is not >>> decoded if its not associated with an m= line (i.e., you drop the >>> payload, not the RTP packet). I suggest replacing the above with >>> something like: >>> >>> If the MID associated with the RTP stream is not in the table mapping >>> MID to m= line, then the RTP stream is not decoded and the payload >>> data is discarded. >>> >>>> If the packet has a MID, and the packet's extended sequence number >>>> is greater than that of the last MID update, as discussed in >>>> [RFC7941], Section 4.2.6, update the incoming SSRC mapping table >>>> to include an entry that maps the packet's SSRC to the "m=" line >>>> for that MID. >>> There are two things that need to be done here: update the MID >>> associated with the RTP stream to match that in the newly received RTP >>> packet, and update the mapping table. I suggest changing update the >>> incoming SSRC mapping table to include an entry that maps the packets >>> SSRC to the m= line for that MID to update the MID associated with >>> the RTP stream to match the MID carried in the RTP packet, then update >>> the mapping tables to include an entry that maps the SSRC of that RTP >>> stream to the m= line for that MID. >>> >>>> If the packet's SSRC is in the incoming SSRC mapping table, check >>>> that the packet's PT matches a PT included on the associated "m=" >>>> line. If so, route the packet to that associated "m=" line and >>>> stop; otherwise drop the packet and stop. >>> Dropping the packet breaks RTCP. The RTP packet is processed as normal, >>> but the corresponding RTP stream is not decoded if its not associated >>> with an m= line. I suggest replacing the above with: >>> >>> If the SSRC of the RTP stream is in the incoming SSRC mapping table, >>> check that the payload type used by the RTP stream matches a payload >>> type included on the matching m= line. If so, associate the RTP >>> stream with that m= line. Otherwise, the RTP stream is not decoded >>> and the payload data is discarded. >>> >>>> If the packet's payload type is in the payload type table, update >>>> the the incoming SSRC mapping table to include an entry that maps >>>> the packet's SSRC to the "m=" line for that payload type. In >>>> addition, route the packet to the associated m=" line and stop. >>> RTP packets correspond to RTP streams, and those RTP streams are >>> associated with m= lines. Suggest changing to: >>> >>> If the payload type used by the RTP stream is in the payload type >>> table, update the incoming SSRC mapping table to include an entry >>> that maps the RTP streams SSRC to the m= line for that payload >>> type. Associate the RTP stream with the corresponding m= line. >>> >>>> Otherwise, drop the packet. >>> The packet cannot be discarded without breaking RTCP. I suggest >>> replacing the above with: >>> >>> Otherwise, mark the RTP stream as not for decoding and discard the >>> payload. >>> >>>> For each RTCP packet received (including each RTCP packet that is >>>> part of a compound RTCP packet), the packet MUST be routed to the >>>> m= line for the RTP streams it contains information about. This >>>> routing is type-dependent, as each kind of RTCP packet has its own >>>> mechanism for associating it with the relevant RTP streams. >>> The first sentence might be clearer written For each RTCP packet >>> received (including each RTCP packet that is part of a compound RTCP >>> packet), the packet is processed as usual by the RTP layer, then is >>> passed to the m= lines corresponding to the RTP streams it contains >>> information about for further processing. >>> >>>> Packets for which no appropriate "m=" line can be identified (i.e., >>>> for unknown RTP streams) are not relevant in the context of this >>>> algorithm and MAY be dropped. This situation may occur with certain >>>> multiparty RTP topologies. >>> These packets cant be dropped. They setup state at the RTP layer that >>> might become relevant when further RTP/RTCP packets are received (RTCP >>> packets can round-robin SDES items, such as the MID, in some cases, so >>> these can potentially be important). I suggest changing this to: >>> >>> RTCP packets for which no appropriate m= line can be identified >>> MUST be processed as usual by the RTP layer, updating the metadata >>> associated with the corresponding RTP streams, but are not passed >>> to any m= line. This situation can occur with certain multiparty >>> RTP topologies, or when RTCP packets are sent containing a subset >>> of the SDES information. >>> >>>> Rules for handling the various types of RTCP packets are explained >>>> below. >>> Perhaps change to Rules for additional processing of the various, to >>> make it clear that this doesnt replace the usual RTCP processing. >>> >>>> If the packet is of type SDES, for each chunk in the packet whose >>> "If the RTCP packet is >>> >>>> SSRC is found in the incoming SSRC table, deliver a copy of the >>>> packet to the "m=" line associated with that SSRC. In addition, >>> a copy of the SDES packet presumably, since otherwise its ambiguous >>> if the entire compound RTCP packet is delivered or just the SDES packet. >>> >>>> for any SDES MID items contained in these chunks, if the MID is >>>> found in the table mapping MID to "m=" line, update the incoming >>>> SSRC table to include an entry that maps the chunks SSRC to the >>> maps the RTP stream associated with the chunks SSRC to >>> >>>> "m=" line associated with that MID, unless the packet is older >>>> than the packet that most recently updated the mapping for this >>>> SSRC, as discussed in [RFC7941], Section 4.2.6. >>>> >>>> Note that if an SDES packet is received as part of a compound RTCP >>>> packet, the SSRC to "m=" line mapping may not exist until the SDES >>>> packet is handled (e.g., in the case where RTCP for a source is >>>> received before any RTP packets). Therefore, when processing a >>>> compound packet, any contained SDES packet MUST be handled first. >>> It might be worth referencing RFC 3550 section 6.1, which says: >>> >>> Each individual RTCP packet in the compound packet may be processed >>> independently with no requirements upon the order or combination of >>> packets. >>> >>> as justification for this. >>> >>>> Holmberg, et al. Expires October 2, 2017 [Page >>>> 23] >>>> Internet-Draft Bundled media March >>>> 2017 >>>> >>>> >>>> If the packet is of type BYE, it indicates that the RTP streams >>> If the RTCP packet is >>> >>>> referenced in the packet are ending. Therefore, for each SSRC >>>> indicated in the packet that is found in the incoming SSRC table, >>> in the BYE packet >>> >>>> first deliver a copy of the packet to the m=" line associated >>> a copy of the BYE packet >>> >>>> with that SSRC, but then remove the entry for that SSRC from the >>>> incoming SSRC table after an appropriate delay to account for >>>> "straggler packets", as specified in [RFC3550], Section 6.2.1. >>>> >>>> If the packet is of type SR or RR, for each report block in the >>> If the RTCP packet is >>> >>>> report whose "SSRC of source" is found in the outgoing SSRC table, >>>> deliver a copy of the RTCP packet to the m=" line associated with >>> the RTCP packet or the SR or RR packet? To avoid confusion when >>> compound RTCP packets are used, I suggest the latter phrasing here, and >>> in the later sections. >>> >>>> that SSRC. In addition, if the packet is of type SR, and the >>>> sender SSRC for the packet is found in the incoming SSRC table, >>>> deliver a copy of the packet to the m=" line associated with that >>> a copy of the SR packet? >>> >>>> SSRC. >>>> >>>> If the implementation supports RTCP XR and the packet is of type >>>> XR, as defined in [RFC3611], for each report block in the report >>>> whose "SSRC of source" is is found in the outgoing SSRC table, >>>> deliver a copy of the RTCP packet to the m=" line associated with >>> the RTCP packet or the XR packet? >>> >>>> that SSRC. In addition, if the sender SSRC for the packet is >>>> found in the incoming SSRC table, deliver a copy of the packet to >>> the packet -> the RTCP packet or the XR packet? >>> >>>> the "m=" line associated with that SSRC. >>>> >>>> If the packet is a feedback message of type RTPFB or PSFB, as >>> If the RTCP packet is >>> >>>> defined in [RFC4585], it will contain a media source SSRC, and >>>> this SSRC is used for routing certain subtypes of feedback >>>> messages. However, several subtypes of PSFB messages include >>>> target SSRC(s) in a section called Feedback Control Information >>>> (FCI). For these messages, the target SSRC(s) are used for >>>> routing. >>>> >>>> If the packet is a feedback message that does not include target >>> If the RTCP packet is >>> >>>> SSRCs in its FCI section, and the media source SSRC is found in >>>> the outgoing SSRC table, deliver the packet to the m=" line >>> Which packet? >>> >>>> associated with that SSRC. RTPFB and PSFB types that are handled >>>> in this way include: >>>> >>>> Generic NACK: [RFC4585] (PT=RTPFB, FMT=1). >>>> >>>> Picture Loss Indication (PLI): [RFC4585] (PT=PSFB, FMT=1). >>>> >>>> Slice Loss Indication (SLI): [RFC4585] (PT=PSFB, FMT=2). >>>> >>>> Reference Picture Selection Indication (RPSI): [RFC4585] >>>> (PT=PSFB, FMT=3). >>>> >>>> >>>> >>>> >>>> >>>> Holmberg, et al. Expires October 2, 2017 [Page >>>> 24] >>>> Internet-Draft Bundled media March >>>> 2017 >>>> >>>> >>>> If the packet is a feedback message that does include target >>> If the RTCP packet is >>> >>>> SSRC(s) in its FCI section, it can either be a request or a >>>> notification. Requests reference a RTP stream that is being sent >>>> by the message recipient, whereas notifications are responses to >>>> an earlier request, and therefore reference a RTP stream that is >>>> being received by the message recipient. >>>> >>>> If the packet is a feedback request that includes target SSRC(s), >>> If the RTCP packet is >>> >>>> for each target SSRC that is found in the outgoing SSRC table, >>>> deliver a copy of the RTCP packet to the "m=" line associated with >>>> that SSRC. PSFB types that are handled in this way include: >>>> >>>> Full Intra Request (FIR): [RFC5104] (PT=PSFB, FMT=4). >>>> >>>> Temporal-Spatial Trade-off Request (TSTR): [RFC5104] (PT=PSFB, >>>> FMT=5). >>>> >>>> H.271 Video Back Channel Message (VBCM): [RFC5104] (PT=PSFB, >>>> FMT=7). >>>> >>>> Layer Refresh Request (LRR): [I-D.ietf-avtext-lrr] (PT=PSFB, >>>> FMT=TBD). >>>> >>>> If the packet is a feedback notification that include target >>>> SSRC(s), for each target SSRC that is found in the incoming SSRC >>>> table, deliver a copy of the RTCP packet to the "m=" line >>>> associated with that SSRC. PSFB types that are handled in this >>> deliver a copy of the RTCP packet to the m= line associated with the >>> RTP stream with matching SSRC >>> >>>> way include: >>>> >>>> Temporal-Spatial Trade-off Notification (TSTN): [RFC5104] >>>> (PT=PSFB, FMT=6). This message is a notification in response >>>> to a prior TSTR. >>>> >>>> If the packet is of type APP, the only routing information >>>> included is the source of the packet, and therefore the packet >>>> could be related to any existing "m=" line. Accordingly, deliver >>>> a copy of the packet to each m=" line. >>> Are APP packets exposed in the WebRTC APIs? Given that we have the data >>> channel, its not clear that we want to support arbitrary application >>> information passing via RTCP. It might be better to say that APP packets >>> are processed in an application specific manner, and if the application >>> doesnt understand them, theyre not passed to any m= line? >>> >>> Finally, I note that this section of the draft doesnt mention the CSRC >>> list anywhere, but should probably do so. As written, RTP packets with a >>> CSRC list will be delivered to the RTP stream matching their SSRC in the >>> usual way, then passed up to the m= line associated with that RTP >>> stream. That may well be sufficient, but if so its likely useful to say >>> that, to make the intent clear. >>> >>> Colin >>> >>> >>> >>> >>> -- >>> Colin Perkins >>> https://csperkins.org/ >>> >>> >>> >>> >>> _______________________________________________ >>> 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 >> >> >> -- >> Colin Perkins >> https://csperkins.org/ >> >> >> >> > _______________________________________________ > mmusic mailing list > mmusic@ietf.org > https://www.ietf.org/mailman/listinfo/mmusic > . > From nobody Wed Aug 30 23:10:36 2017 Return-Path: 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 AB181132192; Wed, 30 Aug 2017 23:10:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.22 X-Spam-Level: X-Spam-Status: No, score=-4.22 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no 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 SIiNWa7R18Yb; Wed, 30 Aug 2017 23:10:33 -0700 (PDT) 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 BC7D0132144; Wed, 30 Aug 2017 23:10:32 -0700 (PDT) X-AuditID: c1b4fb2d-11bff700000057a4-a8-59a7a8562575 Received: from ESESSHC001.ericsson.se (Unknown_Domain [153.88.183.21]) by sessmg23.ericsson.net (Symantec Mail Security) with SMTP id 31.00.22436.658A7A95; Thu, 31 Aug 2017 08:10:30 +0200 (CEST) Received: from ESESSMB109.ericsson.se ([169.254.9.194]) by ESESSHC001.ericsson.se ([153.88.183.21]) with mapi id 14.03.0352.000; Thu, 31 Aug 2017 08:10:30 +0200 From: Christer Holmberg To: Adam Roach , Ben Campbell , "Eric Rescorla" , Alexey Melnikov , =?Windows-1252?Q?Mirja_K=FChlewind?= , Roman Shpount CC: "draft-ietf-mmusic-dtls-sdp@ietf.org" , "mmusic-chairs@ietf.org" , "mmusic@ietf.org" , The IESG Thread-Topic: Adam Roach's No Objection on draft-ietf-mmusic-dtls-sdp-28: (with COMMENT) - All comments should now have been addressed Thread-Index: AQHTIXLJNIlpz3f/yE6ODK9en612caKdECSAgAD+rQA= Date: Thu, 31 Aug 2017 06:10:29 +0000 Message-ID: References: <244f9778-9cc4-eb99-bec1-f1905e7ec00e@nostrum.com> In-Reply-To: <244f9778-9cc4-eb99-bec1-f1905e7ec00e@nostrum.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.7.4.170508 x-originating-ip: [153.88.183.147] Content-Type: text/plain; charset="Windows-1252" Content-ID: <1D2EDEB7E664034A82E3FE4F928CC426@ericsson.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFrrLIsWRmVeSWpSXmKPExsUyM2K7qG7YiuWRBmcnWFnsf3+IyWLP30Xs FvM7T7Nb/J84n9Vixetz7BYz/kxktnhx/SOzxfmd65kspi5/zGJx/ekuFgcuj52nDrB5LFny k8mj5eNCVo9ZO5+weEx+3MbssfXvX7YAtigum5TUnMyy1CJ9uwSujNs7t7EW/OSu2HJzLWsD 4zHOLkZODgkBE4meJ51MXYxcHEICRxglJhw9ywbhLGGU2Np0m7WLkYODTcBCovufNkhcROA7 o8TlN0fYQRxmgeOMEitWnwTrEBZoZ5R49OIQO0RZB6PE3vWHGEGWiAhYSUzccIsdZBSLgKrE zruhIGFeAWuJNzPOg5UICRRI7Dizmx3E5hSwlzjRsJAVxGYUEJP4fmoNE4jNLCAucevJfCaI uwUkluw5zwxhi0q8fPwP7FJRAT2Jd/s9QUwJASWJaVvTIDoNJN6fm88MYVtLdM5fwAJha0ss W/iaGeIaQYmTM5+wTGAUn4Vk2Swk7bOQtM9C0j4LSfsCRtZVjKLFqcXFuelGxnqpRZnJxcX5 eXp5qSWbGIGRfnDLb90djKtfOx5iFOBgVOLhvTN/eaQQa2JZcWXuIUYJDmYlEV676UAh3pTE yqrUovz4otKc1OJDjNIcLErivA77LkQICaQnlqRmp6YWpBbBZJk4OKUaGEX/fL8kz/VfPDD/ mseUprpZV/dIKM2TezRRscsrX2mdoN2VryY7o7IO2lasv/r37aRvzmEr9j3tZWD9vf/Zy/7Z 5k8UNDPfywqVRf6wcQoy/vfMdxX3AgfPgn9PklcI/JU69POeeUayouaVe+8f3Prd7xp0cV/d XC4rcQfF5t7Hk+5/ru49laXEUpyRaKjFXFScCAC4mxl/8AIAAA== Archived-At: Subject: Re: [MMUSIC] Adam Roach's No Objection on draft-ietf-mmusic-dtls-sdp-28: (with COMMENT) - All comments should now have been addressed X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 31 Aug 2017 06:10:35 -0000 Hi, >>I have updated the PR. It should now address the IESG comments given by >> Adam, Ekr, Alexey and Mirja. >> >> https://github.com/cdh4u/draft-dtls-sdp/pull/35 >> >> >> In the latest commit (#7): >> >> - Section 7 (Transport Protocol Considerations) was removed. >> - Text regarding correlation of SDP and TLS connection was added to the >> Security Considerations (as requested by Mirja). >> >> Please let me know if there is something I=B9ve forgot. > >The list of issues I posted to MMUSIC included the question about >whether ufrag change requires a DTLS restart in the absence of a >'tls-id'. There was a bit of discussion on that list which seemed to >conclude that it should *not*. I believe the document needs to reflect >this -- but I'd specifically ask the MMUSIC chairs whether they see >consensus on this point first. Correct, I forgot to mention that the PR yet does not address the ufrag issue, waiting for a WG consensus. Note that there is currently a discussion in RTCWEB on whether a ufrag change should trigger an ICE restart. But, as an ICE restart does not automatically trigger a DTLS restart I assume it won=92t affect draft-dtls-sdp. Worth keeping in mind, though. >On the topic of looking over your changes: it's still easier to read a >text-form document than digging through XML source. Version numbers are >free. I encourage you to drop a new version whenever you ask people to >look at changes. I will submit a new version. Regards, Christer From nobody Thu Aug 31 01:04:01 2017 Return-Path: X-Original-To: mmusic@ietf.org Delivered-To: mmusic@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 9B99D132335; Thu, 31 Aug 2017 01:04:00 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: Cc: mmusic@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.59.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <150416664058.16860.8036431568519600245@ietfa.amsl.com> Date: Thu, 31 Aug 2017 01:04:00 -0700 Archived-At: Subject: [MMUSIC] I-D Action: draft-ietf-mmusic-sdp-bundle-negotiation-39.txt X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.22 List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 31 Aug 2017 08:04:01 -0000 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 : Negotiating Media Multiplexing Using the Session Description Protocol (SDP) Authors : Christer Holmberg Harald Tveit Alvestrand Cullen Jennings Filename : draft-ietf-mmusic-sdp-bundle-negotiation-39.txt Pages : 63 Date : 2017-08-31 Abstract: This specification defines a new Session Description Protocol (SDP) Grouping Framework extension, 'BUNDLE'. The extension can be used with the SDP Offer/Answer mechanism to negotiate the usage of a single address:port combination (BUNDLE address) for receiving media, referred to as bundled media, specified by multiple SDP media descriptions ("m=" lines). To assist endpoints in negotiating the use of bundle this specification defines a new SDP attribute, 'bundle-only', which can be used to request that specific media is only used if bundled. The specification also updates RFC 3264, to allow usage of zero port values without meaning that media is rejected. There are multiple ways to correlate the bundled RTP packets with the appropriate media descriptions. This specification defines a new Real-time Transport Protocol (RTP) source description (SDES) item and a new RTP header extension that provides an additional way to do this correlation by using them to carry a value that associates the RTP/ RTCP packets with a specific media description. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-mmusic-sdp-bundle-negotiation/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-mmusic-sdp-bundle-negotiation-39 https://datatracker.ietf.org/doc/html/draft-ietf-mmusic-sdp-bundle-negotiation-39 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-mmusic-sdp-bundle-negotiation-39 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/ From nobody Thu Aug 31 01:05:58 2017 Return-Path: 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 804DA132335 for ; Thu, 31 Aug 2017 01:05:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.22 X-Spam-Level: X-Spam-Status: No, score=-4.22 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=ham autolearn_force=no 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 24mge-VGzhvG for ; Thu, 31 Aug 2017 01:05:54 -0700 (PDT) Received: from sesbmg23.ericsson.net (sesbmg23.ericsson.net [193.180.251.37]) (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 2B4CF13237B for ; Thu, 31 Aug 2017 01:05:53 -0700 (PDT) X-AuditID: c1b4fb25-d31059c000005333-84-59a7c36086f6 Received: from ESESSHC012.ericsson.se (Unknown_Domain [153.88.183.54]) by sesbmg23.ericsson.net (Symantec Mail Security) with SMTP id EC.91.21299.063C7A95; Thu, 31 Aug 2017 10:05:52 +0200 (CEST) Received: from ESESSMB109.ericsson.se ([169.254.9.194]) by ESESSHC012.ericsson.se ([153.88.183.54]) with mapi id 14.03.0352.000; Thu, 31 Aug 2017 10:05:51 +0200 From: Christer Holmberg To: "mmusic@ietf.org" Thread-Topic: Draft new version: BUNDLE-39 Thread-Index: AQHTIi/1dvgFZTvL6kmW9vo+OqBaJw== Date: Thu, 31 Aug 2017 08:05:51 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.7.4.170508 x-originating-ip: [153.88.183.20] Content-Type: multipart/alternative; boundary="_000_D5CD9F1D20CE8christerholmbergericssoncom_" MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFvrDLMWRmVeSWpSXmKPExsUyM2K7mW7C4eWRBgsbBC2mLn/M4sDosWTJ T6YAxigum5TUnMyy1CJ9uwSujI7mY+wFOzkrDk+6ztzAOIWji5GTQ0LARGL/m3uMXYxcHEIC Rxgldq77zw7hLGGUOLlkCVsXIwcHm4CFRPc/bZAGEQF1ia97e5hBbGEBVYlbM7ezQ8S1JPa+ /cIMUi4ioCex46EFSJgFqGTq55ssIDavgLXE7O/vGUFsRgExie+n1jCB2MwC4hK3nsxngrhH QGLJnvPMELaoxMvH/1hBRooCjXy33xMirChxdfpyqNYEiennTzNBjBeUODnzCcsERqFZSKbO QlI2C0kZRFxHYsHuT2wQtrbEsoWvmWHsMwceQ/VaS3SuOc6KrGYBI8cqRtHi1OKk3HQjY73U oszk4uL8PL281JJNjMA4Objlt+oOxstvHA8xCnAwKvHwNuxZHinEmlhWXJl7iFGCg1lJhLf1 IFCINyWxsiq1KD++qDQntfgQozQHi5I4r+O+CxFCAumJJanZqakFqUUwWSYOTqkGxvJToZyv 079Gp75ZfUvLNkLlw+6Xk31jbdJKV1XFtbDf+ND3fqpc7o6u8zruD+/vvS6x+1Dxrsj2uRyr VzfOFU3YvnqR/pzndw0uu+7WbfZXrX018UOes5V0w8+OuH61ZxE/PD3L1xbe5X7T62GUlSzL vGofj16J64onJ86sX+Z70SbarnJ+nxJLcUaioRZzUXEiAFLxsPSPAgAA Archived-At: Subject: [MMUSIC] Draft new version: BUNDLE-39 X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 31 Aug 2017 08:05:57 -0000 --_000_D5CD9F1D20CE8christerholmbergericssoncom_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi, I have submitted a new version (-39) of draft-bundle. The new version contains the RTP changes provided by Colin, and the referen= ce fix done by Nils. Regards, Christer --_000_D5CD9F1D20CE8christerholmbergericssoncom_ Content-Type: text/html; charset="us-ascii" Content-ID: Content-Transfer-Encoding: quoted-printable
Hi,

I have submitted a new version (-39) of draft-bundle.

The new version contains the RTP changes provided by Colin, and the re= ference fix done by Nils.

Regards,

Christer
--_000_D5CD9F1D20CE8christerholmbergericssoncom_-- From nobody Thu Aug 31 02:22:59 2017 Return-Path: X-Original-To: mmusic@ietf.org Delivered-To: mmusic@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 4DE9E132D51; Thu, 31 Aug 2017 02:22:51 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: Cc: mmusic@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.59.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <150417137126.16908.6074056511169559137@ietfa.amsl.com> Date: Thu, 31 Aug 2017 02:22:51 -0700 Archived-At: Subject: [MMUSIC] I-D Action: draft-ietf-mmusic-dtls-sdp-29.txt X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.22 List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 31 Aug 2017 09:22:51 -0000 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 : Session Description Protocol (SDP) Offer/Answer Considerations for Datagram Transport Layer Security (DTLS) and Transport Layer Security (TLS) Authors : Christer Holmberg Roman Shpount Filename : draft-ietf-mmusic-dtls-sdp-29.txt Pages : 27 Date : 2017-08-31 Abstract: This document defines the Session Description Protocol (SDP) offer/ answer procedures for negotiating and establishing a Datagram Transport Layer Security (DTLS) association. The document also defines the criteria for when a new DTLS association must be established. The document updates RFC 5763 and RFC 7345, by replacing common SDP offer/answer procedures with a reference to this specification. This document defines a new SDP media-level attribute, 'tls-id'. This document also defines how the 'tls-id' attribute can be used for negotiating and establishing a Transport Layer Security (TLS) connection, in conjunction with the procedures in RFC 4145 and RFC 8122. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-mmusic-dtls-sdp/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-mmusic-dtls-sdp-29 https://datatracker.ietf.org/doc/html/draft-ietf-mmusic-dtls-sdp-29 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-mmusic-dtls-sdp-29 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/