From nobody Sun Feb 12 01:26:43 2017 Return-Path: X-Original-To: clue@ietfa.amsl.com Delivered-To: clue@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CDF2B129495 for ; Sun, 12 Feb 2017 01:26:41 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.222 X-Spam-Level: X-Spam-Status: No, score=-4.222 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, RP_MATCHES_RCVD=-0.001, 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 FMqQqoUemy2T for ; Sun, 12 Feb 2017 01:26:39 -0800 (PST) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9AD43127A90 for ; Sun, 12 Feb 2017 01:26:38 -0800 (PST) Received: from 172.18.7.190 (EHLO lhreml702-cah.china.huawei.com) ([172.18.7.190]) by lhrrg01-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id DGG84077; Sun, 12 Feb 2017 09:26:34 +0000 (GMT) Received: from DGGEMM403-HUB.china.huawei.com (10.3.20.211) by lhreml702-cah.china.huawei.com (10.201.5.99) with Microsoft SMTP Server (TLS) id 14.3.301.0; Sun, 12 Feb 2017 09:26:33 +0000 Received: from DGGEMM506-MBX.china.huawei.com ([169.254.3.117]) by DGGEMM403-HUB.china.huawei.com ([10.3.20.211]) with mapi id 14.03.0301.000; Sun, 12 Feb 2017 17:26:30 +0800 From: Roni Even To: Magnus Westerlund , "clue@ietf.org" Thread-Topic: Comments on CaptureID and security Thread-Index: AQHScYH0r5NcLRRjNUS7Z54RehkMCKFlQA8g Date: Sun, 12 Feb 2017 09:26:30 +0000 Message-ID: <6E58094ECC8D8344914996DAD28F1CCD773548@DGGEMM506-MBX.china.huawei.com> References: <6E58094ECC8D8344914996DAD28F1CCD76DEFF@DGGEMM506-MBX.china.huawei.com> <5eb63eb7-0a07-cae4-cf7d-e4ff00fc7118@ericsson.com> <6E58094ECC8D8344914996DAD28F1CCD76DF3C@DGGEMM506-MBX.china.huawei.com> <74afe259-a7cd-c55b-ed4a-bea29ede012f@ericsson.com> In-Reply-To: <74afe259-a7cd-c55b-ed4a-bea29ede012f@ericsson.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.200.201.150] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-CFilter-Loop: Reflected X-Mirapoint-Virus-RAPID-Raw: score=unknown(0), refid=str=0001.0A090206.58A02A4B.0064, ss=1, re=0.000, recu=0.000, reip=0.000, cl=1, cld=1, fgs=0, ip=169.254.3.117, so=2013-06-18 04:22:30, dmn=2013-03-21 17:37:32 X-Mirapoint-Loop-Id: 37c3681b66ab832cd4f59909e82edb2b Archived-At: Cc: Jonathan Lennox Subject: Re: [clue] Comments on CaptureID and security X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: CLUE - ControLling mUltiple streams for TElepresence List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 12 Feb 2017 09:26:42 -0000 SGkgTWFnbnVzLA0KQWJvdXQgdGhlIHJlcXVpcmVtZW50IHRvIGVuY3J5cHQgdGhlIFJUQ1AgKGRv IG5vdCB1c2UgTlVMTCBzZWN1cml0eSBwcm9maWxlKSBJIHdhcyB3b25kZXJpbmcgd2h5IGl0IGlz IG5vdCBtZW50aW9uIGFsc28gb24gUlRDUHdlYiwgaXMgaXQgYmVjYXVzZSBSVFAvUlRDUCBtdWx0 aXBsZXhpbmc/IEkgdGhpbmsgdGhhdCBpdCBzaG91bGQgYmUgbWVudGlvbmVkIGFsc28gdGhlcmUg c2luY2UgdGhlcmUgaXMgb3B0aW9uIHRvIHN1cHBvcnQgbm9uIG11bHRpcGxleCBSVFAvUlRDUA0K Um9uaSANCg0KPiAtLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KPiBGcm9tOiBNYWdudXMgV2Vz dGVybHVuZCBbbWFpbHRvOm1hZ251cy53ZXN0ZXJsdW5kQGVyaWNzc29uLmNvbV0NCj4gU2VudDog 15nXldedwqDXkyAxOCDXmdeg15XXkNeoIDIwMTcgMTM6NTMNCj4gVG86IFJvbmkgRXZlbjsgY2x1 ZUBpZXRmLm9yZw0KPiBDYzogSm9uYXRoYW4gTGVubm94DQo+IFN1YmplY3Q6IFJlOiBDb21tZW50 cyBvbiBDYXB0dXJlSUQgYW5kIHNlY3VyaXR5DQo+IA0KPiBIaSwNCj4gDQo+IFllcywgSSB0aGlu ayBlbmNyeXB0aW5nIHRoZSBDYXB0dXJlSUQgYXZvaWRzIHRoZSBuZWdhdGl2ZSBpbXBhY3RzIHRo YXQgYmFkDQo+IGNvbnN0cnVjdGlvbiBjYW4gaGF2ZSB0aGF0IEkgY2FuIHRoaW5rIG9mLiBUaHVz LCBJIHN1cHBvcnQgZ29pbmcgaW4gdGhhdA0KPiBkaXJlY3Rpb24uDQo+IA0KPiBXaGVuIGl0IGNv bWVzIHRvIHRoZSBzZWN1cml0eSBzb2x1dGlvbiBJIHdvdWxkIHJlY29tbWVuZCBjb3B5aW5nIHRo ZSB0ZXh0DQo+IGFuZCB0aGVuIG1ha2UgdGhlIGVkaXRzLiBUaGVyZSBpcyBhdCBsZWFzdCB0d28g YWRkaXRpb25zLCB0aGUgTVVTVCBlbmNyeXB0DQo+IFJUQ1AsIGFuZCB0aGUgTVVTVCBpbXBsZW1l bnQgUkZDIDY5MDQgYW5kIHVzZSBpdCB0byBlbmNyeXB0IHRoZSBDYXB0dXJlSUQNCj4gaGVhZGVy IGV4dGVuc2lvbi4gUGxlYXNlIGJlIGV4cGxpY2l0IGFuZCBjbGVhciBpbiB0aGUgQ0xVRSBsZXZl bCBkb2N1bWVudCBvbg0KPiB3aGF0IHNlY3VyaXR5IHNvbHV0aW9ucyB0aGF0IG5lZWRzIHRvIGJl IGltcGxlbWVudGVkIGFuZCB1c2UuDQo+IA0KPiBSZWFzb25zIGZvciBjb3B5aW5nIHRoZSB0ZXh0 LCBpcyB0aGF0IHRoZXJlIGFyZSBkaWZmZXJlbmNlcyBiZXR3ZWVuIFJUQ1dlYg0KPiBhbmQgQ0xV RSwgYW5kIGluIGFkZGl0aW9uIEkgdGhpbmsgdGhlIGltcGxlbWVudGF0aW9uIGNvbnNpZGVyYXRp b25zIGFuZA0KPiBwb3RlbnRpYWwgbmVlZHMgdG8gbGF0ZXIgcmV2aXNlIHRoZSBzcGVjaWZpY2F0 aW9uIGFyZSBkaWZmZXJlbnQuIEkgYW0gbm90IGNlcnRhaW4NCj4gQ0xVRSB3aWxsIHdhbnQgdG8g YmUgcmVxdWlyZWQgdG8gZm9sbG93IGFueSBjaGFuZ2VzIHRoYXQgUlRDV2ViIGRvZXMgaW4gdGhl DQo+IGZ1dHVyZS4NCj4gDQo+IEkgd291bGQgYWxzbyBub3RlIHRoYXQgSSB0aGluayB5b3UgbmVl ZCBhdCBsZWFzdCB0byBwdXQgaW4gYSBzaG9ydCBwYXJhZ3JhcGgNCj4gYWJvdXQgdGhlIENhcHR1 cmVJRCB2YWx1ZS4gU29tZXRoaW5nIGxpa2UgdGhpcy4NCj4gDQo+IFRoZSBjb25zdHJ1Y3Rpb24g b2YgdGhlIENhcHR1cmVJRCB2YWx1ZSBpcyBpbXBsZW1lbnRhdGlvbiBkZXBlbmRlbnQgYW5kIGlz DQo+IG5vdCB0aWdodGx5IHJlc3RyaWN0ZWQuIFRoZXJlZm9yZSB0aGVyZSBleGlzdCBhIHJpc2sg dGhhdCB0aGUgQ2FwdHVyZUlEIGNvbnRhaW5zDQo+IHByaXZhY3kgc2Vuc2l0aXZlIGluZm9ybWF0 aW9uIG9yIG90aGVyd2lzZSByZXZlYWxpbmcgaW5mb3JtYXRpb24gYWJvdXQgdGhlDQo+IGNvbW11 bmljYXRpb24gc2Vzc2lvbiB0byB0aGlyZCBwYXJ0aWVzLiBUaGVyZWZvcmUgY29uZmlkZW50aWFs aXR5IHByb3RlY3Rpb24NCj4gaXMgYWx3YXlzIGFwcGxpZWQgdG8gYXZvaWQgdGhpcyByaXNrLg0K PiANCj4gQ2hlZXJzDQo+IA0KPiBNYWdudXMNCj4gDQo+IERlbiAyMDE3LTAxLTE4IGtsLiAxMDo0 NCwgc2tyZXYgUm9uaSBFdmVuOg0KPiA+IEhpLCBUaGUgdGV4dCBJIGFkZGVkIHRvIHRoZSAtMTEg dmVyc2lvbiAiVGhlIENhcHR1cmVJRCBpcyBjcmVhdGVkIGFzDQo+ID4gcGFydCBvZiB0aGUgQ0xV RSBwcm90b2NvbC4gIFRoZSBDYXB0SWQgU0RFUyBpdGVtIGlzIHVzZWQgdG8gY29udmV5IHRoZQ0K PiA+IHNhbWUgQ2FwdHVyZUlEIHZhbHVlIGluIHRoZSBTREVTIGl0ZW0uICBXaGVuIHNlbmRpbmcg dGhlIFNERVMgaXRlbSB0aGUNCj4gPiBzZWN1cml0eSBjb25zaWRlcnRpb24gc3BlY2llZCBpbiB0 aGUgc2VjdXJpdHkgc2VjdGlvbiBvZiBbUkZDNzk0MV0gYXJlDQo+ID4gYXBwbGljYWJsZSBhbmQg dGhpcyBTREVTIGl0ZW0gTVVTVCB1c2Ugc2ltaWxhciBzZWN1cml0eSBhcyB0aGUgQ0xVRQ0KPiA+ IHByb3RvY29sIG1lc3NhZ2VzIGNhcnJpZWQgaW4gdGhlIENMVUUgZGF0YSBjaGFubmVsLiINCj4g Pg0KPiA+IFNheSB0aGF0ICAiIHRoaXMgU0RFUyBpdGVtIE1VU1QgdXNlIHNpbWlsYXIgc2VjdXJp dHkgYXMgdGhlIENMVUUNCj4gPiBwcm90b2NvbCBtZXNzYWdlcyBjYXJyaWVkIGluIHRoZSBDTFVF IGRhdGEgY2hhbm5lbC4iIFRoZSBDTFVFIGRhdGENCj4gPiBjaGFubmVsIGRvY3VtZW50DQo+ID4g aHR0cHM6Ly90b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0LWlldGYtY2x1ZS1kYXRhY2hhbm5lbC0x NCNzZWN0aW9uLTQNCj4gPiBwb2ludCBhdA0KPiA+IGh0dHBzOi8vdG9vbHMuaWV0Zi5vcmcvaHRt bC9kcmFmdC1pZXRmLXJ0Y3dlYi1kYXRhLWNoYW5uZWwtMTMjc2VjdGlvbi0NCj4gPiA3DQo+ID4g cG9pbnRpbmcgdG8NCj4gPiBodHRwczovL3Rvb2xzLmlldGYub3JnL2h0bWwvZHJhZnQtaWV0Zi1y dGN3ZWItc2VjdXJpdHktYXJjaC0xMA0KPiA+DQo+ID4gU28gd2UgY2FuIHJlZmVyZW5jZSB0aGUg cnRjd2ViIHNlY3VyaXR5IGFyY2hpdGVjdHVyZSBvciB1c2UgdGhlIHRleHQgSQ0KPiA+IGNvcGll ZCBmcm9tIHRoZXJlIHRvIGRlZmluZSBhIHNlY3VyaXR5IHByb2ZpbGUNCj4gPg0KPiA+IEFzIGZv ciB0aGUgc2Vjb25kIGl0ZW0gSSBhZ3JlZSB0aGF0IGlmIHdlIGVuY3J5cHQgdGhlIGNvbnRlbnQg aW4gdGhlDQo+ID4gQ0xVRSBkYXRhIGNoYW5uZWwgdGhhdCBpbmNsdWRlcyB0aGUgY2FwdHVyZUlE LCB3ZSBuZWVkIGFsc28gdG8gZW5jcnlwdA0KPiA+IFJUQ1Agd2l0aCB0aGUgY2FwdHVyZUlEIFNE RVMgaXRlbSBhbmQgaXQgZG9lcyBub3QgbWF0dGVyIGhvdyB3ZSBjcmVhdGUNCj4gPiB0aGUgY2Fw dHVyZUlEIHZhbHVlLCBzbyBtYXliZSBpZiB3ZSBtYW5kYXRlIGVuY3J5cHRpbmcgdGhlIFNERVMg aXRlbQ0KPiA+IHRoZXJlIGlzIG5vIHN0cm9uZyBuZWVkIGZvciBzcGVjaWZ5aW5nIGhvdyB0byBj cmVhdGUgQ2FwdHVyZUlEIC4gTm90ZQ0KPiA+IHRoYXQgdGhlIENhcHR1cmVJRCBpcyBub3QgdXNl IHRvIHByb3ZpZGUgaHVtYW4tcmVhZGFibGUgdGV4dHVhbA0KPiA+IGluZm9ybWF0aW9uIHdoaWNo IGlzIGluIHRoZSBkZXNjcmlwdGlvbiBhdHRyaWJ1dGUuDQo+ID4NCj4gPiBSb25pDQo+ID4NCj4g Pj4gLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0gRnJvbTogTWFnbnVzIFdlc3Rlcmx1bmQNCj4g Pj4gW21haWx0bzptYWdudXMud2VzdGVybHVuZEBlcmljc3Nvbi5jb21dIFNlbnQ6INeZ15XXnSDX kyAxOCDXmdeg15XXkNeoIDIwMTcNCj4gPj4gMTA6NDUgVG86IFJvbmkgRXZlbjsgY2x1ZUBpZXRm Lm9yZyBDYzogSm9uYXRoYW4gTGVubm94IFN1YmplY3Q6IFJlOg0KPiA+PiBDb21tZW50cyBvbiBD YXB0dXJlSUQgYW5kIHNlY3VyaXR5DQo+ID4+DQo+ID4+IEhpLA0KPiA+Pg0KPiA+PiBBIGNvbW1l bnQgYWJvdXQgdGhlIGJlbG93LiBJIGhhdmUgYW4gaXNzdWUgcmFpc2VkIGFnYWluc3QgdGhlIGJl bG93DQo+ID4+IHF1b3RlZCB0ZXh0IGZyb20gdGhlIHJ0Y3dlYi1zZWN1cml0eS1hcmNoaXRlY3R1 cmUgaW4gdGhlIFJUQ1dlYiBXRywNCj4gPj4gYXMgaXQgZmFpbHMgdG8gc3BlY2lmeSBpZiBSVENQ IGVuY3J5cHRpb24gaXMgbWFuZGF0b3J5IHRvIHVzZSBvciBub3QuDQo+ID4+IFRoZXJlIGFyZSBw cm90ZWN0aW9uIHByb2ZpbGVzIHRoYXQgb25seSBoYXZlIGNvbmZpZGVudGlhbGl0eQ0KPiA+PiBw cm90ZWN0aW9uIGZvciBSVFAsIGFuZCBub3QgZm9yIFJUQ1AuIEkgd291bGQgcmVjb21tZW5kIHJl cXVpcmluZw0KPiA+PiBjb25maWRlbnRpYWxpdHkgcHJvdGVjdGlvbiBhbHNvIG9mIFJUQ1AuDQo+ ID4+DQo+ID4+IFRoZSBzZWNvbmQgbm90ZSBvbiB0aGUgYmVsb3cgaXMgdGhhdCBkZXBlbmRpbmcg b24gdGhlIG91dGNvbWUgb2YgdGhlDQo+ID4+IHNlY3VyaXR5IHJlcXVpcmVtZW50cyBmb3IgdGhl IENhcHR1cmVJRCBSVFAgaGVhZGVyIGV4dGVuc2lvbiwgeW91DQo+ID4+IG1pZ2h0IGluIGFkZGl0 aW9uIGhhdmUgdG8gcmVxdWlyZSBSRkMgNjkwNCwgaW1wbGVtZW50YXRpb24gYW5kIHVzYWdlDQo+ ID4+IGZvciB0aGUgQ2FwdHVyZUlkIGhlYWRlciBleHRlbnNpb24gZmllbGQuIE9yIHJhdGhlciBp ZiB5b3Ugd3JpdGUNCj4gPj4gbm90aGluZyBpdCB3aWxsIGJ5IGRlZmF1bHQgYmUgcmVxdWlyZWQg aWYgeW91IGVuY3J5cHQgUlRDUCwgZHVlIHRvDQo+ID4+IFJGQyA3OTQxLiBCdXQsIEkgcmVhbGx5 IHJlY29tbWVuZCB0aGF0IHlvdSBhcmUgZXhwbGljaXQgb24gdGhpcw0KPiA+PiBtYXR0ZXIuIEl0 IGNvbWVzIGRvd24gdG8gd2hhdCBzZWN1cml0eSByaXNrcyB0aGUgZmllbGQgZW50YWlscy4gV2hh dA0KPiA+PiBpbmZvcm1hdGlvbiB3aWxsIGl0IGxlYWsgdG8gYSB0aGlyZCBwYXJ0eSB2aWV3ZXIg b2YgdGhlIFJUUC9SVENQDQo+ID4+IHN0cmVhbSB0aGV5IGNhbiBjYXB0dXJlLg0KPiA+Pg0KPiA+ PiBDaGVlcnMNCj4gPj4NCj4gPj4gTWFnbnVzDQo+ID4+DQo+ID4+IERlbiAyMDE3LTAxLTE4IGts LiAwOTozMywgc2tyZXYgUm9uaSBFdmVuOg0KPiA+Pj4gMi4gICAgICAgV2hhdCBkbyB3ZSB3YW50 IHRvIHNheSBhYm91dCBzdXBwb3J0ZWQgc2VjdXJpdHkgcHJvZmlsZT8NCj4gPj4+IEZvciBleGFt cGxlIGRvZXMgdGhlIGZvbGxvd2luZyBkaXJlY3RpdmUgZnJvbQ0KPiA+Pj4gaHR0cHM6Ly90b29s cy5pZXRmLm9yZy9odG1sL2RyYWZ0LWlldGYtcnRjd2ViLXNlY3VyaXR5LWFyY2gtMTIjc2VjdGkN Cj4gPj4+IG9uLTUuNQ0KPiA+Pj4NCj4gPj4+DQo+IGxvb2tzIGdvb2QgZm9yIENMVUU/DQo+ID4+ Pg0KPiA+Pj4NCj4gPj4+DQo+ID4+PiDigJxJbXBsZW1lbnRhdGlvbnMgTVVTVCBpbXBsZW1lbnQg U1JUUCBbUkZDMzcxMQ0KPiA+Pj4gPGh0dHBzOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9yZmMzNzEx Pl0uICBJbXBsZW1lbnRhdGlvbnMgTVVTVA0KPiA+Pj4NCj4gPj4+IGltcGxlbWVudCBEVExTIFtS RkM0MzQ3IDxodHRwczovL3Rvb2xzLmlldGYub3JnL2h0bWwvcmZjNDM0Nz5dDQo+ID4+PiBhbmQg RFRMUy1TUlRQIFtSRkM1NzYzDQo+ID4+PiA8aHR0cHM6Ly90b29scy5pZXRmLm9yZy9odG1sL3Jm YzU3NjM+XVtSRkM1NzY0XSBmb3INCj4gPj4gU1JUUA0KPiA+Pj4NCj4gPj4+IGtleWluZy4gIElt cGxlbWVudGF0aW9ucyBNVVNUIGltcGxlbWVudA0KPiA+Pj4NCj4gPj4+IFtJLUQuaWV0Zi10c3Z3 Zy1zY3RwLWR0bHMtZW5jYXBzDQo+ID4+PiA8aHR0cHM6Ly90b29scy5pZXRmLm9yZy9odG1sL2Ry YWZ0LWlldGYtcnRjd2ViLXNlY3VyaXR5LWFyY2gtMTIjcmVmLQ0KPiA+Pj4gSS0NCj4gPj4NCj4g Pj4+DQo+IEQuaWV0Zi10c3Z3Zy1zY3RwLWR0bHMtZW5jYXBzPl0uDQo+ID4+Pg0KPiA+Pj4NCj4g Pj4+DQo+ID4+PiBBbGwgbWVkaWEgY2hhbm5lbHMgTVVTVCBiZSBzZWN1cmVkIHZpYSBTUlRQLiAg TWVkaWEgdHJhZmZpYyBNVVNUIE5PVA0KPiA+Pj4NCj4gPj4+IGJlIHNlbnQgb3ZlciBwbGFpbiAo dW5lbmNyeXB0ZWQpIFJUUDsgdGhhdCBpcywgaW1wbGVtZW50YXRpb25zIE1VU1QNCj4gPj4+DQo+ ID4+PiBOT1QgbmVnb3RpYXRlIGNpcGhlciBzdWl0ZXMgd2l0aCBOVUxMIGVuY3J5cHRpb24gbW9k ZXMuDQo+ID4+PiBEVExTLVNSVFANCj4gPj4+DQo+ID4+PiBNVVNUIGJlIG9mZmVyZWQgZm9yIGV2 ZXJ5IG1lZGlhIGNoYW5uZWwuDQo+ID4+Pg0KPiA+Pj4NCj4gPj4+DQo+ID4+PiBBbGwgZGF0YSBj aGFubmVscyBNVVNUIGJlIHNlY3VyZWQgdmlhIERUTFMuDQo+ID4+Pg0KPiA+Pj4NCj4gPj4+DQo+ ID4+PiBBbGwgaW1wbGVtZW50YXRpb25zIE1VU1QgaW1wbGVtZW50IERUTFMgMS4wLCB3aXRoIHRo ZSBjaXBoZXIgc3VpdGUNCj4gPj4+DQo+ID4+PiBUTFNfRUNESEVfRUNEU0FfV0lUSF9BRVNfMTI4 X0NCQ19TSEEgd2l0aCB0aGUgdGhlIFAtMjU2IGN1cnZlDQo+ID4+Pg0KPiA+Pj4gW0ZJUFMxODYN Cj4gPj4+IDxodHRwczovL3Rvb2xzLmlldGYub3JnL2h0bWwvZHJhZnQtaWV0Zi1ydGN3ZWItc2Vj dXJpdHktYXJjaC0xMiNyZWYtDQo+ID4+DQo+ID4+Pg0KPiBGSVBTMTg2Pl0uDQo+ID4+PiBUaGUg RFRMUy1TUlRQIHByb3RlY3Rpb24gcHJvZmlsZQ0KPiA+Pj4NCj4gPj4+IFNSVFBfQUVTMTI4X0NN X0hNQUNfU0hBMV84MCBNVVNUIGJlIHN1cHBvcnRlZCBmb3IgU1JUUC4NCj4gPj4+DQo+ID4+PiBJ bXBsZW1lbnRhdGlvbnMgU0hPVUxEIGltcGxlbWVudCBEVExTIDEuMiB3aXRoIHRoZQ0KPiA+Pj4N Cj4gPj4+IFRMU19FQ0RIRV9FQ0RTQV9XSVRIX0FFU18xMjhfR0NNX1NIQTI1NiBjaXBoZXIgc3Vp dGUuDQo+ID4+Pg0KPiA+Pj4gSW1wbGVtZW50YXRpb25zIE1VU1QgZmF2b3IgY2lwaGVyIHN1aXRl cyB3aGljaCBzdXBwb3J0IFBGUyBvdmVyDQo+ID4+PiBub24tDQo+ID4+Pg0KPiA+Pj4gUEZTIGNp cGhlciBzdWl0ZXMgYW5kIFNIT1VMRCBmYXZvciBBRUFEIG92ZXIgbm9uLUFFQUQgY2lwaGVyIHN1 aXRlcy4NCj4gPj4+DQo+ID4+PiDigJwNCj4gPj4NCj4gPj4NCj4gPj4gLS0NCj4gPj4NCj4gPj4g TWFnbnVzIFdlc3Rlcmx1bmQNCj4gPj4NCj4gPj4gLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tDQo+ID4+IC0NCj4gPj4N Cj4gPj4NCj4gU2VydmljZXMsIE1lZGlhIGFuZCBOZXR3b3JrIGZlYXR1cmVzLCBFcmljc3NvbiBS ZXNlYXJjaCBFQUIvVFhNDQo+ID4+IC0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLQ0KPiA+PiAtDQo+ID4+DQo+ID4+DQo+ IEVyaWNzc29uIEFCICAgICAgICAgICAgICAgICB8IFBob25lICArNDYgMTAgNzE0ODI4Nw0KPiA+ PiBGw6Ryw7ZnYXRhbiA2ICAgICAgICAgICAgICAgICB8IE1vYmlsZSArNDYgNzMgMDk0OTA3OSBT RS0xNjQgODANCj4gPj4gU3RvY2tob2xtLCBTd2VkZW4gfCBtYWlsdG86IG1hZ251cy53ZXN0ZXJs dW5kQGVyaWNzc29uLmNvbQ0KPiA+PiAtLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0NCj4gPj4gLQ0KPiA+DQo+ID4+DQo+ IC0tDQo+IA0KPiBNYWdudXMgV2VzdGVybHVuZA0KPiANCj4gLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLQ0KPiBTZXJ2 aWNlcywgTWVkaWEgYW5kIE5ldHdvcmsgZmVhdHVyZXMsIEVyaWNzc29uIFJlc2VhcmNoIEVBQi9U WE0NCj4gLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLQ0KPiBFcmljc3NvbiBBQiAgICAgICAgICAgICAgICAgfCBQaG9u ZSAgKzQ2IDEwIDcxNDgyODcNCj4gRsOkcsO2Z2F0YW4gNiAgICAgICAgICAgICAgICAgfCBNb2Jp bGUgKzQ2IDczIDA5NDkwNzkNCj4gU0UtMTY0IDgwIFN0b2NraG9sbSwgU3dlZGVuIHwgbWFpbHRv OiBtYWdudXMud2VzdGVybHVuZEBlcmljc3Nvbi5jb20NCj4gLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLQ0KDQo= From nobody Sun Feb 12 01:59:19 2017 Return-Path: X-Original-To: clue@ietfa.amsl.com Delivered-To: clue@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8BC4A129440 for ; Sun, 12 Feb 2017 01:59:18 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.222 X-Spam-Level: X-Spam-Status: No, score=-4.222 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, RP_MATCHES_RCVD=-0.001, 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 hOmik-88b9-7 for ; Sun, 12 Feb 2017 01:59:16 -0800 (PST) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DABCC129443 for ; Sun, 12 Feb 2017 01:59:15 -0800 (PST) Received: from 172.18.7.190 (EHLO lhreml702-cah.china.huawei.com) ([172.18.7.190]) by lhrrg02-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id DAK90246; Sun, 12 Feb 2017 09:58:58 +0000 (GMT) Received: from DGGEMM404-HUB.china.huawei.com (10.3.20.212) by lhreml702-cah.china.huawei.com (10.201.5.99) with Microsoft SMTP Server (TLS) id 14.3.301.0; Sun, 12 Feb 2017 09:58:57 +0000 Received: from DGGEMM506-MBX.china.huawei.com ([169.254.3.117]) by DGGEMM404-HUB.china.huawei.com ([10.3.20.212]) with mapi id 14.03.0301.000; Sun, 12 Feb 2017 17:58:54 +0800 From: Roni Even To: Magnus Westerlund , "clue@ietf.org" Thread-Topic: Comments on CaptureID and security Thread-Index: AdJxYyu3dvmMy6+lR4Sf9Fep5IDFDP//gdUA/9gbZDA= Date: Sun, 12 Feb 2017 09:58:53 +0000 Message-ID: <6E58094ECC8D8344914996DAD28F1CCD773560@DGGEMM506-MBX.china.huawei.com> References: <6E58094ECC8D8344914996DAD28F1CCD76DEFF@DGGEMM506-MBX.china.huawei.com> <5eb63eb7-0a07-cae4-cf7d-e4ff00fc7118@ericsson.com> In-Reply-To: <5eb63eb7-0a07-cae4-cf7d-e4ff00fc7118@ericsson.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.200.201.150] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-CFilter-Loop: Reflected X-Mirapoint-Virus-RAPID-Raw: score=unknown(0), refid=str=0001.0A020206.58A031E2.0115, ss=1, re=0.000, recu=0.000, reip=0.000, cl=1, cld=1, fgs=0, ip=169.254.3.117, so=2013-06-18 04:22:30, dmn=2013-03-21 17:37:32 X-Mirapoint-Loop-Id: 2f058d4d2abf29a32fabe2605f50cc63 Archived-At: Cc: Jonathan Lennox Subject: Re: [clue] Comments on CaptureID and security X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: CLUE - ControLling mUltiple streams for TElepresence List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 12 Feb 2017 09:59:18 -0000 SEkgTWFnbnVzLA0KSSB0aGluayB0aGF0IHRoZSBjb25maWRlbnRpYWxpdHkgIG9mIHRoZSBSVENQ IGlzIGNvdmVyZWQgaW4gUkZDNTc2NA0KIiBBcHBsaWNhdGlvbnMgdXNpbmcgRFRMUy1TUlRQIFNI T1VMRCBjb29yZGluYXRlIHRoZSBTUlRQIFByb3RlY3Rpb24NCiAgIFByb2ZpbGVzIGJldHdlZW4g dGhlIERUTFMtU1JUUCBzZXNzaW9uIHRoYXQgcHJvdGVjdHMgYW4gUlRQIGZsb3cgYW5kDQogICB0 aGUgRFRMUy1TUlRQIHNlc3Npb24gdGhhdCBwcm90ZWN0cyB0aGUgYXNzb2NpYXRlZCBSVENQIGZs b3cgKGluDQogICB0aG9zZSBjYXNlcyBpbiB3aGljaCB0aGUgUlRQIGFuZCBSVENQIGFyZSBub3Qg bXVsdGlwbGV4ZWQgb3ZlciBhDQogICBjb21tb24gcG9ydCkuICBJbiBwYXJ0aWN1bGFyLCBpZGVu dGljYWwgY2lwaGVycyBTSE9VTEQgYmUgdXNlZC4iDQoNClJvbmkNCg0KPiAtLS0tLU9yaWdpbmFs IE1lc3NhZ2UtLS0tLQ0KPiBGcm9tOiBNYWdudXMgV2VzdGVybHVuZCBbbWFpbHRvOm1hZ251cy53 ZXN0ZXJsdW5kQGVyaWNzc29uLmNvbV0NCj4gU2VudDog15nXldedwqDXkyAxOCDXmdeg15XXkNeo IDIwMTcgMTA6NDUNCj4gVG86IFJvbmkgRXZlbjsgY2x1ZUBpZXRmLm9yZw0KPiBDYzogSm9uYXRo YW4gTGVubm94DQo+IFN1YmplY3Q6IFJlOiBDb21tZW50cyBvbiBDYXB0dXJlSUQgYW5kIHNlY3Vy aXR5DQo+IA0KPiBIaSwNCj4gDQo+IEEgY29tbWVudCBhYm91dCB0aGUgYmVsb3cuIEkgaGF2ZSBh biBpc3N1ZSByYWlzZWQgYWdhaW5zdCB0aGUgYmVsb3cgcXVvdGVkDQo+IHRleHQgZnJvbSB0aGUg cnRjd2ViLXNlY3VyaXR5LWFyY2hpdGVjdHVyZSBpbiB0aGUgUlRDV2ViIFdHLCBhcyBpdCBmYWls cyB0bw0KPiBzcGVjaWZ5IGlmIFJUQ1AgZW5jcnlwdGlvbiBpcyBtYW5kYXRvcnkgdG8gdXNlIG9y IG5vdC4gVGhlcmUgYXJlIHByb3RlY3Rpb24NCj4gcHJvZmlsZXMgdGhhdCBvbmx5IGhhdmUgY29u ZmlkZW50aWFsaXR5IHByb3RlY3Rpb24gZm9yIFJUUCwgYW5kIG5vdCBmb3IgUlRDUC4gSQ0KPiB3 b3VsZCByZWNvbW1lbmQgcmVxdWlyaW5nIGNvbmZpZGVudGlhbGl0eSBwcm90ZWN0aW9uIGFsc28g b2YgUlRDUC4NCj4gDQo+IFRoZSBzZWNvbmQgbm90ZSBvbiB0aGUgYmVsb3cgaXMgdGhhdCBkZXBl bmRpbmcgb24gdGhlIG91dGNvbWUgb2YgdGhlDQo+IHNlY3VyaXR5IHJlcXVpcmVtZW50cyBmb3Ig dGhlIENhcHR1cmVJRCBSVFAgaGVhZGVyIGV4dGVuc2lvbiwgeW91IG1pZ2h0IGluDQo+IGFkZGl0 aW9uIGhhdmUgdG8gcmVxdWlyZSBSRkMgNjkwNCwgaW1wbGVtZW50YXRpb24gYW5kIHVzYWdlIGZv ciB0aGUNCj4gQ2FwdHVyZUlkIGhlYWRlciBleHRlbnNpb24gZmllbGQuIE9yIHJhdGhlciBpZiB5 b3Ugd3JpdGUgbm90aGluZyBpdCB3aWxsIGJ5DQo+IGRlZmF1bHQgYmUgcmVxdWlyZWQgaWYgeW91 IGVuY3J5cHQgUlRDUCwgZHVlIHRvIFJGQyA3OTQxLiBCdXQsIEkgcmVhbGx5DQo+IHJlY29tbWVu ZCB0aGF0IHlvdSBhcmUgZXhwbGljaXQgb24gdGhpcyBtYXR0ZXIuIEl0IGNvbWVzIGRvd24gdG8g d2hhdA0KPiBzZWN1cml0eSByaXNrcyB0aGUgZmllbGQgZW50YWlscy4gV2hhdCBpbmZvcm1hdGlv biB3aWxsIGl0IGxlYWsgdG8gYSB0aGlyZCBwYXJ0eQ0KPiB2aWV3ZXIgb2YgdGhlIFJUUC9SVENQ IHN0cmVhbSB0aGV5IGNhbiBjYXB0dXJlLg0KPiANCj4gQ2hlZXJzDQo+IA0KPiBNYWdudXMNCj4g DQo+IERlbiAyMDE3LTAxLTE4IGtsLiAwOTozMywgc2tyZXYgUm9uaSBFdmVuOg0KPiA+IDIuICAg ICAgIFdoYXQgZG8gd2Ugd2FudCB0byBzYXkgYWJvdXQgc3VwcG9ydGVkIHNlY3VyaXR5IHByb2Zp bGU/IEZvcg0KPiA+IGV4YW1wbGUgZG9lcyB0aGUgZm9sbG93aW5nIGRpcmVjdGl2ZSBmcm9tDQo+ ID4gaHR0cHM6Ly90b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0LWlldGYtcnRjd2ViLXNlY3VyaXR5 LWFyY2gtMTIjc2VjdGlvbi01LjUNCj4gPiBsb29rcyBnb29kIGZvciBDTFVFPw0KPiA+DQo+ID4N Cj4gPg0KPiA+IOKAnEltcGxlbWVudGF0aW9ucyBNVVNUIGltcGxlbWVudCBTUlRQIFtSRkMzNzEx DQo+ID4gPGh0dHBzOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9yZmMzNzExPl0uICBJbXBsZW1lbnRh dGlvbnMgTVVTVA0KPiA+DQo+ID4gICAgaW1wbGVtZW50IERUTFMgW1JGQzQzNDcgPGh0dHBzOi8v dG9vbHMuaWV0Zi5vcmcvaHRtbC9yZmM0MzQ3Pl0gYW5kDQo+ID4gRFRMUy1TUlRQIFtSRkM1NzYz IDxodHRwczovL3Rvb2xzLmlldGYub3JnL2h0bWwvcmZjNTc2Mz5dW1JGQzU3NjRdIGZvcg0KPiBT UlRQDQo+ID4NCj4gPiAgICBrZXlpbmcuICBJbXBsZW1lbnRhdGlvbnMgTVVTVCBpbXBsZW1lbnQN Cj4gPg0KPiA+ICAgIFtJLUQuaWV0Zi10c3Z3Zy1zY3RwLWR0bHMtZW5jYXBzDQo+ID4gPGh0dHBz Oi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC1pZXRmLXJ0Y3dlYi1zZWN1cml0eS1hcmNoLTEy I3JlZi1JLQ0KPiBELmlldGYtdHN2d2ctc2N0cC1kdGxzLWVuY2Fwcz5dLg0KPiA+DQo+ID4NCj4g Pg0KPiA+ICAgIEFsbCBtZWRpYSBjaGFubmVscyBNVVNUIGJlIHNlY3VyZWQgdmlhIFNSVFAuICBN ZWRpYSB0cmFmZmljIE1VU1QgTk9UDQo+ID4NCj4gPiAgICBiZSBzZW50IG92ZXIgcGxhaW4gKHVu ZW5jcnlwdGVkKSBSVFA7IHRoYXQgaXMsIGltcGxlbWVudGF0aW9ucyBNVVNUDQo+ID4NCj4gPiAg ICBOT1QgbmVnb3RpYXRlIGNpcGhlciBzdWl0ZXMgd2l0aCBOVUxMIGVuY3J5cHRpb24gbW9kZXMu ICBEVExTLVNSVFANCj4gPg0KPiA+ICAgIE1VU1QgYmUgb2ZmZXJlZCBmb3IgZXZlcnkgbWVkaWEg Y2hhbm5lbC4NCj4gPg0KPiA+DQo+ID4NCj4gPiAgICBBbGwgZGF0YSBjaGFubmVscyBNVVNUIGJl IHNlY3VyZWQgdmlhIERUTFMuDQo+ID4NCj4gPg0KPiA+DQo+ID4gICAgQWxsIGltcGxlbWVudGF0 aW9ucyBNVVNUIGltcGxlbWVudCBEVExTIDEuMCwgd2l0aCB0aGUgY2lwaGVyIHN1aXRlDQo+ID4N Cj4gPiAgICBUTFNfRUNESEVfRUNEU0FfV0lUSF9BRVNfMTI4X0NCQ19TSEEgd2l0aCB0aGUgdGhl IFAtMjU2IGN1cnZlDQo+ID4NCj4gPiAgICBbRklQUzE4Ng0KPiA+IDxodHRwczovL3Rvb2xzLmll dGYub3JnL2h0bWwvZHJhZnQtaWV0Zi1ydGN3ZWItc2VjdXJpdHktYXJjaC0xMiNyZWYtDQo+IEZJ UFMxODY+XS4NCj4gPiBUaGUgRFRMUy1TUlRQIHByb3RlY3Rpb24gcHJvZmlsZQ0KPiA+DQo+ID4g ICAgU1JUUF9BRVMxMjhfQ01fSE1BQ19TSEExXzgwIE1VU1QgYmUgc3VwcG9ydGVkIGZvciBTUlRQ Lg0KPiA+DQo+ID4gICBJbXBsZW1lbnRhdGlvbnMgU0hPVUxEIGltcGxlbWVudCBEVExTIDEuMiB3 aXRoIHRoZQ0KPiA+DQo+ID4gICAgVExTX0VDREhFX0VDRFNBX1dJVEhfQUVTXzEyOF9HQ01fU0hB MjU2IGNpcGhlciBzdWl0ZS4NCj4gPg0KPiA+ICAgIEltcGxlbWVudGF0aW9ucyBNVVNUIGZhdm9y IGNpcGhlciBzdWl0ZXMgd2hpY2ggc3VwcG9ydCBQRlMgb3ZlciBub24tDQo+ID4NCj4gPiAgICBQ RlMgY2lwaGVyIHN1aXRlcyBhbmQgU0hPVUxEIGZhdm9yIEFFQUQgb3ZlciBub24tQUVBRCBjaXBo ZXIgc3VpdGVzLg0KPiA+DQo+ID4g4oCcDQo+IA0KPiANCj4gLS0NCj4gDQo+IE1hZ251cyBXZXN0 ZXJsdW5kDQo+IA0KPiAtLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tDQo+IFNlcnZpY2VzLCBNZWRpYSBhbmQgTmV0d29y ayBmZWF0dXJlcywgRXJpY3Nzb24gUmVzZWFyY2ggRUFCL1RYTQ0KPiAtLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tDQo+ IEVyaWNzc29uIEFCICAgICAgICAgICAgICAgICB8IFBob25lICArNDYgMTAgNzE0ODI4Nw0KPiBG w6Ryw7ZnYXRhbiA2ICAgICAgICAgICAgICAgICB8IE1vYmlsZSArNDYgNzMgMDk0OTA3OQ0KPiBT RS0xNjQgODAgU3RvY2tob2xtLCBTd2VkZW4gfCBtYWlsdG86IG1hZ251cy53ZXN0ZXJsdW5kQGVy aWNzc29uLmNvbQ0KPiAtLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tDQoNCg== From nobody Sun Feb 12 02:07:54 2017 Return-Path: X-Original-To: clue@ietfa.amsl.com Delivered-To: clue@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B848A1293E8 for ; Sun, 12 Feb 2017 02:07:52 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.222 X-Spam-Level: X-Spam-Status: No, score=-4.222 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, RP_MATCHES_RCVD=-0.001, 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 INRD3emp8vBg for ; Sun, 12 Feb 2017 02:07:51 -0800 (PST) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B58DC127A90 for ; Sun, 12 Feb 2017 02:07:50 -0800 (PST) Received: from 172.18.7.190 (EHLO lhreml701-cah.china.huawei.com) ([172.18.7.190]) by lhrrg02-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id DAK90995; Sun, 12 Feb 2017 10:07:48 +0000 (GMT) Received: from DGGEMM405-HUB.china.huawei.com (10.3.20.213) by lhreml701-cah.china.huawei.com (10.201.5.93) with Microsoft SMTP Server (TLS) id 14.3.301.0; Sun, 12 Feb 2017 10:07:47 +0000 Received: from DGGEMM506-MBX.china.huawei.com ([169.254.3.117]) by DGGEMM405-HUB.china.huawei.com ([10.3.20.213]) with mapi id 14.03.0301.000; Sun, 12 Feb 2017 18:07:40 +0800 From: Roni Even To: Paul Kyzivat , "clue@ietf.org" Thread-Topic: [clue] Comments on CaptureID and security Thread-Index: AQHScaeXyoVHKH3YXUGaMZ9bBREL6qFlTDnQ Date: Sun, 12 Feb 2017 10:07:39 +0000 Message-ID: <6E58094ECC8D8344914996DAD28F1CCD773571@DGGEMM506-MBX.china.huawei.com> References: <6E58094ECC8D8344914996DAD28F1CCD76DEFF@DGGEMM506-MBX.china.huawei.com> <5eb63eb7-0a07-cae4-cf7d-e4ff00fc7118@ericsson.com> <6E58094ECC8D8344914996DAD28F1CCD76DF3C@DGGEMM506-MBX.china.huawei.com> <74afe259-a7cd-c55b-ed4a-bea29ede012f@ericsson.com> <208e2d66-b7bf-8167-7c3d-6841df84192e@alum.mit.edu> In-Reply-To: <208e2d66-b7bf-8167-7c3d-6841df84192e@alum.mit.edu> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.200.201.150] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-CFilter-Loop: Reflected X-Mirapoint-Virus-RAPID-Raw: score=unknown(0), refid=str=0001.0A020205.58A033F5.0069, ss=1, re=0.000, recu=0.000, reip=0.000, cl=1, cld=1, fgs=0, ip=169.254.3.117, so=2013-06-18 04:22:30, dmn=2013-03-21 17:37:32 X-Mirapoint-Loop-Id: 98a7b41afac6edef6b4b1affb1275325 Archived-At: Subject: Re: [clue] Comments on CaptureID and security X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: CLUE - ControLling mUltiple streams for TElepresence List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 12 Feb 2017 10:07:52 -0000 UGF1bCwNCkZyb20gUkZDNTc2NA0KIlJUUCBhbmQgUlRDUCB0cmFmZmljIE1BWSBiZSBtdWx0aXBs ZXhlZCBvbiBhIHNpbmdsZSBVRFAgcG9ydA0KICAgW1JGQzU3NjFdLiAgSW4gdGhpcyBjYXNlLCBi b3RoIFJUUCBhbmQgUlRDUCBwYWNrZXRzIG1heSBiZSBzZW50IG92ZXINCiAgIHRoZSBzYW1lIERU TFMtU1JUUCBzZXNzaW9uLCBoYWx2aW5nIHRoZSBudW1iZXIgb2YgRFRMUy1TUlRQIHNlc3Npb25z DQogICBuZWVkZWQuICBUaGlzIGltcHJvdmVzIHRoZSBjcnlwdG9ncmFwaGljIHBlcmZvcm1hbmNl IG9mIERUTFMsIGJ1dCBtYXkNCiAgIGNhdXNlIHByb2JsZW1zIHdoZW4gUlRDUCBhbmQgUlRQIGFy ZSBzdWJqZWN0IHRvIGRpZmZlcmVudCBuZXR3b3JrDQogICB0cmVhdG1lbnQgKGUuZy4sIGZvciBi YW5kd2lkdGggcmVzZXJ2YXRpb24gb3Igc2NoZWR1bGluZyByZWFzb25zKS4iDQoNClJvbmkNCg0K PiAtLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KPiBGcm9tOiBjbHVlIFttYWlsdG86Y2x1ZS1i b3VuY2VzQGlldGYub3JnXSBPbiBCZWhhbGYgT2YgUGF1bCBLeXppdmF0DQo+IFNlbnQ6INeZ15XX ncKg15MgMTgg15nXoNeV15DXqCAyMDE3IDE4OjI2DQo+IFRvOiBjbHVlQGlldGYub3JnDQo+IFN1 YmplY3Q6IFJlOiBbY2x1ZV0gQ29tbWVudHMgb24gQ2FwdHVyZUlEIGFuZCBzZWN1cml0eQ0KPiAN Cj4gSSBoYXZlIGEgc2lkZSBxdWVzdGlvbiBvbiB0aGlzOiBpZiBSVENQIGlzIGJlaW5nIG11bHRp cGxleGVkIHdpdGggUlRQLCBhbmQgdGhlDQo+IFJUUCBpcyBiZWluZyBlbmNyeXB0ZWQsIGlzIHRo ZSBSVENQIGFsc28gaW1wbGljaXRseSBlbmNyeXB0ZWQsIG9yIGlzIGl0IHN0aWxsIGFuDQo+IGlu ZGVwZW5kZW50bHkgbmVnb3RpYXRlZCBmZWF0dXJlPw0KPiANCj4gKFllcywgSSByZWFsaXplIHRo YXQgZG9lc24ndCBzb2x2ZSB0aGUgZ2VuZXJhbCBwcm9ibGVtIGZvciBDTFVFLikNCj4gDQo+IAlU aGFua3MsDQo+IAlQYXVsDQo+IA0KPiBPbiAxLzE4LzE3IDY6NTMgQU0sIE1hZ251cyBXZXN0ZXJs dW5kIHdyb3RlOg0KPiA+IEhpLA0KPiA+DQo+ID4gWWVzLCBJIHRoaW5rIGVuY3J5cHRpbmcgdGhl IENhcHR1cmVJRCBhdm9pZHMgdGhlIG5lZ2F0aXZlIGltcGFjdHMgdGhhdA0KPiA+IGJhZCBjb25z dHJ1Y3Rpb24gY2FuIGhhdmUgdGhhdCBJIGNhbiB0aGluayBvZi4gVGh1cywgSSBzdXBwb3J0IGdv aW5nDQo+ID4gaW4gdGhhdCBkaXJlY3Rpb24uDQo+ID4NCj4gPiBXaGVuIGl0IGNvbWVzIHRvIHRo ZSBzZWN1cml0eSBzb2x1dGlvbiBJIHdvdWxkIHJlY29tbWVuZCBjb3B5aW5nIHRoZQ0KPiA+IHRl eHQgYW5kIHRoZW4gbWFrZSB0aGUgZWRpdHMuIFRoZXJlIGlzIGF0IGxlYXN0IHR3byBhZGRpdGlv bnMsIHRoZQ0KPiA+IE1VU1QgZW5jcnlwdCBSVENQLCBhbmQgdGhlIE1VU1QgaW1wbGVtZW50IFJG QyA2OTA0IGFuZCB1c2UgaXQgdG8NCj4gPiBlbmNyeXB0IHRoZSBDYXB0dXJlSUQgaGVhZGVyIGV4 dGVuc2lvbi4gUGxlYXNlIGJlIGV4cGxpY2l0IGFuZCBjbGVhcg0KPiA+IGluIHRoZSBDTFVFIGxl dmVsIGRvY3VtZW50IG9uIHdoYXQgc2VjdXJpdHkgc29sdXRpb25zIHRoYXQgbmVlZHMgdG8gYmUN Cj4gPiBpbXBsZW1lbnRlZCBhbmQgdXNlLg0KPiA+DQo+ID4gUmVhc29ucyBmb3IgY29weWluZyB0 aGUgdGV4dCwgaXMgdGhhdCB0aGVyZSBhcmUgZGlmZmVyZW5jZXMgYmV0d2Vlbg0KPiA+IFJUQ1dl YiBhbmQgQ0xVRSwgYW5kIGluIGFkZGl0aW9uIEkgdGhpbmsgdGhlIGltcGxlbWVudGF0aW9uDQo+ ID4gY29uc2lkZXJhdGlvbnMgYW5kIHBvdGVudGlhbCBuZWVkcyB0byBsYXRlciByZXZpc2UgdGhl IHNwZWNpZmljYXRpb24NCj4gPiBhcmUgZGlmZmVyZW50LiBJIGFtIG5vdCBjZXJ0YWluIENMVUUg d2lsbCB3YW50IHRvIGJlIHJlcXVpcmVkIHRvDQo+ID4gZm9sbG93IGFueSBjaGFuZ2VzIHRoYXQg UlRDV2ViIGRvZXMgaW4gdGhlIGZ1dHVyZS4NCj4gPg0KPiA+IEkgd291bGQgYWxzbyBub3RlIHRo YXQgSSB0aGluayB5b3UgbmVlZCBhdCBsZWFzdCB0byBwdXQgaW4gYSBzaG9ydA0KPiA+IHBhcmFn cmFwaCBhYm91dCB0aGUgQ2FwdHVyZUlEIHZhbHVlLiBTb21ldGhpbmcgbGlrZSB0aGlzLg0KPiA+ DQo+ID4gVGhlIGNvbnN0cnVjdGlvbiBvZiB0aGUgQ2FwdHVyZUlEIHZhbHVlIGlzIGltcGxlbWVu dGF0aW9uIGRlcGVuZGVudA0KPiA+IGFuZCBpcyBub3QgdGlnaHRseSByZXN0cmljdGVkLiBUaGVy ZWZvcmUgdGhlcmUgZXhpc3QgYSByaXNrIHRoYXQgdGhlDQo+ID4gQ2FwdHVyZUlEIGNvbnRhaW5z IHByaXZhY3kgc2Vuc2l0aXZlIGluZm9ybWF0aW9uIG9yIG90aGVyd2lzZQ0KPiA+IHJldmVhbGlu ZyBpbmZvcm1hdGlvbiBhYm91dCB0aGUgY29tbXVuaWNhdGlvbiBzZXNzaW9uIHRvIHRoaXJkDQo+ ID4gcGFydGllcy4gVGhlcmVmb3JlIGNvbmZpZGVudGlhbGl0eSBwcm90ZWN0aW9uIGlzIGFsd2F5 cyBhcHBsaWVkIHRvIGF2b2lkIHRoaXMNCj4gcmlzay4NCj4gPg0KPiA+IENoZWVycw0KPiA+DQo+ ID4gTWFnbnVzDQo+ID4NCj4gPiBEZW4gMjAxNy0wMS0xOCBrbC4gMTA6NDQsIHNrcmV2IFJvbmkg RXZlbjoNCj4gPj4gSGksIFRoZSB0ZXh0IEkgYWRkZWQgdG8gdGhlIC0xMSB2ZXJzaW9uICJUaGUg Q2FwdHVyZUlEIGlzIGNyZWF0ZWQgYXMNCj4gPj4gcGFydCBvZiB0aGUgQ0xVRSBwcm90b2NvbC4g IFRoZSBDYXB0SWQgU0RFUyBpdGVtIGlzIHVzZWQgdG8gY29udmV5DQo+ID4+IHRoZSBzYW1lIENh cHR1cmVJRCB2YWx1ZSBpbiB0aGUgU0RFUyBpdGVtLiAgV2hlbiBzZW5kaW5nIHRoZSBTREVTDQo+ ID4+IGl0ZW0gdGhlIHNlY3VyaXR5IGNvbnNpZGVydGlvbiBzcGVjaWVkIGluIHRoZSBzZWN1cml0 eSBzZWN0aW9uIG9mDQo+ID4+IFtSRkM3OTQxXSBhcmUgYXBwbGljYWJsZSBhbmQgdGhpcyBTREVT IGl0ZW0gTVVTVCB1c2Ugc2ltaWxhciBzZWN1cml0eQ0KPiA+PiBhcyB0aGUgQ0xVRSBwcm90b2Nv bCBtZXNzYWdlcyBjYXJyaWVkIGluIHRoZSBDTFVFIGRhdGEgY2hhbm5lbC4iDQo+ID4+DQo+ID4+ IFNheSB0aGF0ICAiIHRoaXMgU0RFUyBpdGVtIE1VU1QgdXNlIHNpbWlsYXIgc2VjdXJpdHkgYXMg dGhlIENMVUUNCj4gPj4gcHJvdG9jb2wgbWVzc2FnZXMgY2FycmllZCBpbiB0aGUgQ0xVRSBkYXRh IGNoYW5uZWwuIiBUaGUgQ0xVRSBkYXRhDQo+ID4+IGNoYW5uZWwgZG9jdW1lbnQNCj4gPj4gaHR0 cHM6Ly90b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0LWlldGYtY2x1ZS1kYXRhY2hhbm5lbC0xNCNz ZWN0aW9uLTQNCj4gPj4gcG9pbnQgYXQNCj4gPj4gaHR0cHM6Ly90b29scy5pZXRmLm9yZy9odG1s L2RyYWZ0LWlldGYtcnRjd2ViLWRhdGEtY2hhbm5lbC0xMyNzZWN0aW9uDQo+ID4+IC03DQo+ID4+ IHBvaW50aW5nIHRvDQo+ID4+IGh0dHBzOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC1pZXRm LXJ0Y3dlYi1zZWN1cml0eS1hcmNoLTEwDQo+ID4+DQo+ID4+IFNvIHdlIGNhbiByZWZlcmVuY2Ug dGhlIHJ0Y3dlYiBzZWN1cml0eSBhcmNoaXRlY3R1cmUgb3IgdXNlIHRoZSB0ZXh0DQo+ID4+IEkg Y29waWVkIGZyb20gdGhlcmUgdG8gZGVmaW5lIGEgc2VjdXJpdHkgcHJvZmlsZQ0KPiA+Pg0KPiA+ PiBBcyBmb3IgdGhlIHNlY29uZCBpdGVtIEkgYWdyZWUgdGhhdCBpZiB3ZSBlbmNyeXB0IHRoZSBj b250ZW50IGluIHRoZQ0KPiA+PiBDTFVFIGRhdGEgY2hhbm5lbCB0aGF0IGluY2x1ZGVzIHRoZSBj YXB0dXJlSUQsIHdlIG5lZWQgYWxzbyB0bw0KPiA+PiBlbmNyeXB0IFJUQ1Agd2l0aCB0aGUgY2Fw dHVyZUlEIFNERVMgaXRlbSBhbmQgaXQgZG9lcyBub3QgbWF0dGVyIGhvdw0KPiA+PiB3ZSBjcmVh dGUgdGhlIGNhcHR1cmVJRCB2YWx1ZSwgc28gbWF5YmUgaWYgd2UgbWFuZGF0ZSBlbmNyeXB0aW5n IHRoZQ0KPiA+PiBTREVTIGl0ZW0gdGhlcmUgaXMgbm8gc3Ryb25nIG5lZWQgZm9yIHNwZWNpZnlp bmcgaG93IHRvIGNyZWF0ZQ0KPiA+PiBDYXB0dXJlSUQgLiBOb3RlIHRoYXQgdGhlIENhcHR1cmVJ RCBpcyBub3QgdXNlIHRvIHByb3ZpZGUNCj4gPj4gaHVtYW4tcmVhZGFibGUgdGV4dHVhbCBpbmZv cm1hdGlvbiB3aGljaCBpcyBpbiB0aGUgZGVzY3JpcHRpb24NCj4gPj4gYXR0cmlidXRlLg0KPiA+ Pg0KPiA+PiBSb25pDQo+ID4+DQo+ID4+PiAtLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLSBGcm9t OiBNYWdudXMgV2VzdGVybHVuZA0KPiA+Pj4gW21haWx0bzptYWdudXMud2VzdGVybHVuZEBlcmlj c3Nvbi5jb21dIFNlbnQ6INeZ15XXnSDXkyAxOCDXmdeg15XXkNeoIDIwMTcNCj4gPj4+IDEwOjQ1 IFRvOiBSb25pIEV2ZW47IGNsdWVAaWV0Zi5vcmcgQ2M6IEpvbmF0aGFuIExlbm5veCBTdWJqZWN0 OiBSZToNCj4gPj4+IENvbW1lbnRzIG9uIENhcHR1cmVJRCBhbmQgc2VjdXJpdHkNCj4gPj4+DQo+ ID4+PiBIaSwNCj4gPj4+DQo+ID4+PiBBIGNvbW1lbnQgYWJvdXQgdGhlIGJlbG93LiBJIGhhdmUg YW4gaXNzdWUgcmFpc2VkIGFnYWluc3QgdGhlIGJlbG93DQo+ID4+PiBxdW90ZWQgdGV4dCBmcm9t IHRoZSBydGN3ZWItc2VjdXJpdHktYXJjaGl0ZWN0dXJlIGluIHRoZSBSVENXZWIgV0csDQo+ID4+ PiBhcyBpdCBmYWlscyB0byBzcGVjaWZ5IGlmIFJUQ1AgZW5jcnlwdGlvbiBpcyBtYW5kYXRvcnkg dG8gdXNlIG9yDQo+ID4+PiBub3QuIFRoZXJlIGFyZSBwcm90ZWN0aW9uIHByb2ZpbGVzIHRoYXQg b25seSBoYXZlIGNvbmZpZGVudGlhbGl0eQ0KPiA+Pj4gcHJvdGVjdGlvbiBmb3IgUlRQLCBhbmQg bm90IGZvciBSVENQLiBJIHdvdWxkIHJlY29tbWVuZCByZXF1aXJpbmcNCj4gPj4+IGNvbmZpZGVu dGlhbGl0eSBwcm90ZWN0aW9uIGFsc28gb2YgUlRDUC4NCj4gPj4+DQo+ID4+PiBUaGUgc2Vjb25k IG5vdGUgb24gdGhlIGJlbG93IGlzIHRoYXQgZGVwZW5kaW5nIG9uIHRoZSBvdXRjb21lIG9mIHRo ZQ0KPiA+Pj4gc2VjdXJpdHkgcmVxdWlyZW1lbnRzIGZvciB0aGUgQ2FwdHVyZUlEIFJUUCBoZWFk ZXIgZXh0ZW5zaW9uLCB5b3UNCj4gPj4+IG1pZ2h0IGluIGFkZGl0aW9uIGhhdmUgdG8gcmVxdWly ZSBSRkMgNjkwNCwgaW1wbGVtZW50YXRpb24gYW5kIHVzYWdlDQo+ID4+PiBmb3IgdGhlIENhcHR1 cmVJZCBoZWFkZXIgZXh0ZW5zaW9uIGZpZWxkLiBPciByYXRoZXIgaWYgeW91IHdyaXRlDQo+ID4+ PiBub3RoaW5nIGl0IHdpbGwgYnkgZGVmYXVsdCBiZSByZXF1aXJlZCBpZiB5b3UgZW5jcnlwdCBS VENQLCBkdWUgdG8NCj4gPj4+IFJGQyA3OTQxLiBCdXQsIEkgcmVhbGx5IHJlY29tbWVuZCB0aGF0 IHlvdSBhcmUgZXhwbGljaXQgb24gdGhpcw0KPiA+Pj4gbWF0dGVyLiBJdCBjb21lcyBkb3duIHRv IHdoYXQgc2VjdXJpdHkgcmlza3MgdGhlIGZpZWxkIGVudGFpbHMuIFdoYXQNCj4gPj4+IGluZm9y bWF0aW9uIHdpbGwgaXQgbGVhayB0byBhIHRoaXJkIHBhcnR5IHZpZXdlciBvZiB0aGUgUlRQL1JU Q1ANCj4gPj4+IHN0cmVhbSB0aGV5IGNhbiBjYXB0dXJlLg0KPiA+Pj4NCj4gPj4+IENoZWVycw0K PiA+Pj4NCj4gPj4+IE1hZ251cw0KPiA+Pj4NCj4gPj4+IERlbiAyMDE3LTAxLTE4IGtsLiAwOToz Mywgc2tyZXYgUm9uaSBFdmVuOg0KPiA+Pj4+IDIuICAgICAgIFdoYXQgZG8gd2Ugd2FudCB0byBz YXkgYWJvdXQgc3VwcG9ydGVkIHNlY3VyaXR5IHByb2ZpbGU/DQo+ID4+Pj4gRm9yIGV4YW1wbGUg ZG9lcyB0aGUgZm9sbG93aW5nIGRpcmVjdGl2ZSBmcm9tDQo+ID4+Pj4gaHR0cHM6Ly90b29scy5p ZXRmLm9yZy9odG1sL2RyYWZ0LWlldGYtcnRjd2ViLXNlY3VyaXR5LWFyY2gtMTIjc2VjdA0KPiA+ Pj4+IGlvbi01LjUNCj4gPj4+Pg0KPiA+Pj4+DQo+ID4+Pj4NCj4gPiBsb29rcyBnb29kIGZvciBD TFVFPw0KPiA+Pj4+DQo+ID4+Pj4NCj4gPj4+Pg0KPiA+Pj4+IOKAnEltcGxlbWVudGF0aW9ucyBN VVNUIGltcGxlbWVudCBTUlRQIFtSRkMzNzExDQo+ID4+Pj4gPGh0dHBzOi8vdG9vbHMuaWV0Zi5v cmcvaHRtbC9yZmMzNzExPl0uICBJbXBsZW1lbnRhdGlvbnMgTVVTVA0KPiA+Pj4+DQo+ID4+Pj4g aW1wbGVtZW50IERUTFMgW1JGQzQzNDcgPGh0dHBzOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9yZmM0 MzQ3Pl0NCj4gPj4+PiBhbmQgRFRMUy1TUlRQIFtSRkM1NzYzDQo+ID4+Pj4gPGh0dHBzOi8vdG9v bHMuaWV0Zi5vcmcvaHRtbC9yZmM1NzYzPl1bUkZDNTc2NF0gZm9yDQo+ID4+PiBTUlRQDQo+ID4+ Pj4NCj4gPj4+PiBrZXlpbmcuICBJbXBsZW1lbnRhdGlvbnMgTVVTVCBpbXBsZW1lbnQNCj4gPj4+ Pg0KPiA+Pj4+IFtJLUQuaWV0Zi10c3Z3Zy1zY3RwLWR0bHMtZW5jYXBzDQo+ID4+Pj4gPGh0dHBz Oi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC1pZXRmLXJ0Y3dlYi1zZWN1cml0eS1hcmNoLTEy I3JlZg0KPiA+Pj4+IC1JLQ0KPiA+Pj4NCj4gPj4+Pg0KPiA+IEQuaWV0Zi10c3Z3Zy1zY3RwLWR0 bHMtZW5jYXBzPl0uDQo+ID4+Pj4NCj4gPj4+Pg0KPiA+Pj4+DQo+ID4+Pj4gQWxsIG1lZGlhIGNo YW5uZWxzIE1VU1QgYmUgc2VjdXJlZCB2aWEgU1JUUC4gIE1lZGlhIHRyYWZmaWMgTVVTVA0KPiA+ Pj4+IE5PVA0KPiA+Pj4+DQo+ID4+Pj4gYmUgc2VudCBvdmVyIHBsYWluICh1bmVuY3J5cHRlZCkg UlRQOyB0aGF0IGlzLCBpbXBsZW1lbnRhdGlvbnMgTVVTVA0KPiA+Pj4+DQo+ID4+Pj4gTk9UIG5l Z290aWF0ZSBjaXBoZXIgc3VpdGVzIHdpdGggTlVMTCBlbmNyeXB0aW9uIG1vZGVzLg0KPiA+Pj4+ IERUTFMtU1JUUA0KPiA+Pj4+DQo+ID4+Pj4gTVVTVCBiZSBvZmZlcmVkIGZvciBldmVyeSBtZWRp YSBjaGFubmVsLg0KPiA+Pj4+DQo+ID4+Pj4NCj4gPj4+Pg0KPiA+Pj4+IEFsbCBkYXRhIGNoYW5u ZWxzIE1VU1QgYmUgc2VjdXJlZCB2aWEgRFRMUy4NCj4gPj4+Pg0KPiA+Pj4+DQo+ID4+Pj4NCj4g Pj4+PiBBbGwgaW1wbGVtZW50YXRpb25zIE1VU1QgaW1wbGVtZW50IERUTFMgMS4wLCB3aXRoIHRo ZSBjaXBoZXIgc3VpdGUNCj4gPj4+Pg0KPiA+Pj4+IFRMU19FQ0RIRV9FQ0RTQV9XSVRIX0FFU18x MjhfQ0JDX1NIQSB3aXRoIHRoZSB0aGUgUC0yNTYgY3VydmUNCj4gPj4+Pg0KPiA+Pj4+IFtGSVBT MTg2DQo+ID4+Pj4gPGh0dHBzOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC1pZXRmLXJ0Y3dl Yi1zZWN1cml0eS1hcmNoLTEyI3JlZg0KPiA+Pj4+IC0NCj4gPj4+DQo+ID4+Pj4NCj4gPiBGSVBT MTg2Pl0uDQo+ID4+Pj4gVGhlIERUTFMtU1JUUCBwcm90ZWN0aW9uIHByb2ZpbGUNCj4gPj4+Pg0K PiA+Pj4+IFNSVFBfQUVTMTI4X0NNX0hNQUNfU0hBMV84MCBNVVNUIGJlIHN1cHBvcnRlZCBmb3Ig U1JUUC4NCj4gPj4+Pg0KPiA+Pj4+IEltcGxlbWVudGF0aW9ucyBTSE9VTEQgaW1wbGVtZW50IERU TFMgMS4yIHdpdGggdGhlDQo+ID4+Pj4NCj4gPj4+PiBUTFNfRUNESEVfRUNEU0FfV0lUSF9BRVNf MTI4X0dDTV9TSEEyNTYgY2lwaGVyIHN1aXRlLg0KPiA+Pj4+DQo+ID4+Pj4gSW1wbGVtZW50YXRp b25zIE1VU1QgZmF2b3IgY2lwaGVyIHN1aXRlcyB3aGljaCBzdXBwb3J0IFBGUyBvdmVyDQo+ID4+ Pj4gbm9uLQ0KPiA+Pj4+DQo+ID4+Pj4gUEZTIGNpcGhlciBzdWl0ZXMgYW5kIFNIT1VMRCBmYXZv ciBBRUFEIG92ZXIgbm9uLUFFQUQgY2lwaGVyDQo+ID4+Pj4gc3VpdGVzLg0KPiA+Pj4+DQo+ID4+ Pj4g4oCcDQo+ID4+Pg0KPiA+Pj4NCj4gPj4+IC0tDQo+ID4+Pg0KPiA+Pj4gTWFnbnVzIFdlc3Rl cmx1bmQNCj4gPj4+DQo+ID4+PiAtLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLQ0KPiA+Pj4gLS0NCj4gPj4+DQo+ID4+Pg0K PiA+IFNlcnZpY2VzLCBNZWRpYSBhbmQgTmV0d29yayBmZWF0dXJlcywgRXJpY3Nzb24gUmVzZWFy Y2ggRUFCL1RYTQ0KPiA+Pj4gLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0NCj4gPj4+IC0tDQo+ID4+Pg0KPiA+Pj4NCj4g PiBFcmljc3NvbiBBQiAgICAgICAgICAgICAgICAgfCBQaG9uZSAgKzQ2IDEwIDcxNDgyODcNCj4g Pj4+IEbDpHLDtmdhdGFuIDYgICAgICAgICAgICAgICAgIHwgTW9iaWxlICs0NiA3MyAwOTQ5MDc5 IFNFLTE2NCA4MA0KPiA+Pj4gU3RvY2tob2xtLCBTd2VkZW4gfCBtYWlsdG86IG1hZ251cy53ZXN0 ZXJsdW5kQGVyaWNzc29uLmNvbQ0KPiA+Pj4gLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0NCj4gPj4+IC0tDQo+ID4+DQo+ ID4+Pg0KPiANCj4gX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X18NCj4gY2x1ZSBtYWlsaW5nIGxpc3QNCj4gY2x1ZUBpZXRmLm9yZw0KPiBodHRwczovL3d3dy5p ZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL2NsdWUNCg== From nobody Sun Feb 12 11:45:52 2017 Return-Path: X-Original-To: clue@ietfa.amsl.com Delivered-To: clue@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0C6BC129585 for ; Sun, 12 Feb 2017 11:45:51 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.935 X-Spam-Level: X-Spam-Status: No, score=-1.935 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, 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 sVkmnhfHjXxn for ; Sun, 12 Feb 2017 11:45:49 -0800 (PST) Received: from resqmta-po-08v.sys.comcast.net (resqmta-po-08v.sys.comcast.net [IPv6:2001:558:fe16:19:96:114:154:167]) (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 59893129485 for ; Sun, 12 Feb 2017 11:45:49 -0800 (PST) Received: from resomta-po-17v.sys.comcast.net ([96.114.154.241]) by resqmta-po-08v.sys.comcast.net with SMTP id d05GcfZHiq9Pld05lc5oGV; Sun, 12 Feb 2017 19:45:49 +0000 Received: from [192.168.1.110] ([73.186.127.100]) by resomta-po-17v.sys.comcast.net with SMTP id d05jcAH1xe3QFd05kchMPX; Sun, 12 Feb 2017 19:45:48 +0000 To: Roni Even , "clue@ietf.org" References: <6E58094ECC8D8344914996DAD28F1CCD76DEFF@DGGEMM506-MBX.china.huawei.com> <5eb63eb7-0a07-cae4-cf7d-e4ff00fc7118@ericsson.com> <6E58094ECC8D8344914996DAD28F1CCD76DF3C@DGGEMM506-MBX.china.huawei.com> <74afe259-a7cd-c55b-ed4a-bea29ede012f@ericsson.com> <208e2d66-b7bf-8167-7c3d-6841df84192e@alum.mit.edu> <6E58094ECC8D8344914996DAD28F1CCD773571@DGGEMM506-MBX.china.huawei.com> From: Paul Kyzivat Message-ID: Date: Sun, 12 Feb 2017 14:45:47 -0500 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:45.0) Gecko/20100101 Thunderbird/45.7.1 MIME-Version: 1.0 In-Reply-To: <6E58094ECC8D8344914996DAD28F1CCD773571@DGGEMM506-MBX.china.huawei.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit X-CMAE-Envelope: MS4wfMRWzeynQOd6bclIosxefrzSGcE0ns1T60YVzt1OUdcexL5nOSwdHlCd5Z6OyEIzqAe6rRbmMcwncmvmob9eEJMN54vWZ1B41nrqKqGRuZXv40S4W0dh VUacajNnh+Mtty/Or9MtHlqyfZe3UsRk/1awF8H+2tttcyro86wKjGbYFqKoOOEGziwQUuTjd7oac8gONaw8IvUQ/BqV7OzKhmw= Archived-At: Subject: Re: [clue] Comments on CaptureID and security X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: CLUE - ControLling mUltiple streams for TElepresence List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 12 Feb 2017 19:45:51 -0000 Roni, On 2/12/17 5:07 AM, Roni Even wrote: > Paul, > From RFC5764 > "RTP and RTCP traffic MAY be multiplexed on a single UDP port > [RFC5761]. In this case, both RTP and RTCP packets may be sent over > the same DTLS-SRTP session, halving the number of DTLS-SRTP sessions > needed. This improves the cryptographic performance of DTLS, but may > cause problems when RTCP and RTP are subject to different network > treatment (e.g., for bandwidth reservation or scheduling reasons)." My understanding of RTP/RTCP is minimal, so my questions may not make any sense. But as best I understand, when RTP/RTCP is run over DTLS it isn't sent as DTLS encrypted payload. Rather, it reuses the DTLS negotiated keys but then encrypts the RTP/RTCP data independently and selectively, so some parts are encrypted and other parts are not. Based on that, my question is whether, when multiplexing RTP and RTCP and running them over DTLS, it is automatic that the RTCP pieces are encrypted, or if it is necessary to negotiate something explicit in the SDP (apart from what is negotiated for the RTP) to cause the RTCP data to be encrypted. Thanks, Paul > Roni > >> -----Original Message----- >> From: clue [mailto:clue-bounces@ietf.org] On Behalf Of Paul Kyzivat >> Sent: יום ד 18 ינואר 2017 18:26 >> To: clue@ietf.org >> Subject: Re: [clue] Comments on CaptureID and security >> >> I have a side question on this: if RTCP is being multiplexed with RTP, and the >> RTP is being encrypted, is the RTCP also implicitly encrypted, or is it still an >> independently negotiated feature? >> >> (Yes, I realize that doesn't solve the general problem for CLUE.) >> >> Thanks, >> Paul >> >> On 1/18/17 6:53 AM, Magnus Westerlund wrote: >>> Hi, >>> >>> Yes, I think encrypting the CaptureID avoids the negative impacts that >>> bad construction can have that I can think of. Thus, I support going >>> in that direction. >>> >>> When it comes to the security solution I would recommend copying the >>> text and then make the edits. There is at least two additions, the >>> MUST encrypt RTCP, and the MUST implement RFC 6904 and use it to >>> encrypt the CaptureID header extension. Please be explicit and clear >>> in the CLUE level document on what security solutions that needs to be >>> implemented and use. >>> >>> Reasons for copying the text, is that there are differences between >>> RTCWeb and CLUE, and in addition I think the implementation >>> considerations and potential needs to later revise the specification >>> are different. I am not certain CLUE will want to be required to >>> follow any changes that RTCWeb does in the future. >>> >>> I would also note that I think you need at least to put in a short >>> paragraph about the CaptureID value. Something like this. >>> >>> The construction of the CaptureID value is implementation dependent >>> and is not tightly restricted. Therefore there exist a risk that the >>> CaptureID contains privacy sensitive information or otherwise >>> revealing information about the communication session to third >>> parties. Therefore confidentiality protection is always applied to avoid this >> risk. >>> >>> Cheers >>> >>> Magnus >>> >>> Den 2017-01-18 kl. 10:44, skrev Roni Even: >>>> Hi, The text I added to the -11 version "The CaptureID is created as >>>> part of the CLUE protocol. The CaptId SDES item is used to convey >>>> the same CaptureID value in the SDES item. When sending the SDES >>>> item the security considertion specied in the security section of >>>> [RFC7941] are applicable and this SDES item MUST use similar security >>>> as the CLUE protocol messages carried in the CLUE data channel." >>>> >>>> Say that " this SDES item MUST use similar security as the CLUE >>>> protocol messages carried in the CLUE data channel." The CLUE data >>>> channel document >>>> https://tools.ietf.org/html/draft-ietf-clue-datachannel-14#section-4 >>>> point at >>>> https://tools.ietf.org/html/draft-ietf-rtcweb-data-channel-13#section >>>> -7 >>>> pointing to >>>> https://tools.ietf.org/html/draft-ietf-rtcweb-security-arch-10 >>>> >>>> So we can reference the rtcweb security architecture or use the text >>>> I copied from there to define a security profile >>>> >>>> As for the second item I agree that if we encrypt the content in the >>>> CLUE data channel that includes the captureID, we need also to >>>> encrypt RTCP with the captureID SDES item and it does not matter how >>>> we create the captureID value, so maybe if we mandate encrypting the >>>> SDES item there is no strong need for specifying how to create >>>> CaptureID . Note that the CaptureID is not use to provide >>>> human-readable textual information which is in the description >>>> attribute. >>>> >>>> Roni >>>> >>>>> -----Original Message----- From: Magnus Westerlund >>>>> [mailto:magnus.westerlund@ericsson.com] Sent: יום ד 18 ינואר 2017 >>>>> 10:45 To: Roni Even; clue@ietf.org Cc: Jonathan Lennox Subject: Re: >>>>> Comments on CaptureID and security >>>>> >>>>> Hi, >>>>> >>>>> A comment about the below. I have an issue raised against the below >>>>> quoted text from the rtcweb-security-architecture in the RTCWeb WG, >>>>> as it fails to specify if RTCP encryption is mandatory to use or >>>>> not. There are protection profiles that only have confidentiality >>>>> protection for RTP, and not for RTCP. I would recommend requiring >>>>> confidentiality protection also of RTCP. >>>>> >>>>> The second note on the below is that depending on the outcome of the >>>>> security requirements for the CaptureID RTP header extension, you >>>>> might in addition have to require RFC 6904, implementation and usage >>>>> for the CaptureId header extension field. Or rather if you write >>>>> nothing it will by default be required if you encrypt RTCP, due to >>>>> RFC 7941. But, I really recommend that you are explicit on this >>>>> matter. It comes down to what security risks the field entails. What >>>>> information will it leak to a third party viewer of the RTP/RTCP >>>>> stream they can capture. >>>>> >>>>> Cheers >>>>> >>>>> Magnus >>>>> >>>>> Den 2017-01-18 kl. 09:33, skrev Roni Even: >>>>>> 2. What do we want to say about supported security profile? >>>>>> For example does the following directive from >>>>>> https://tools.ietf.org/html/draft-ietf-rtcweb-security-arch-12#sect >>>>>> ion-5.5 >>>>>> >>>>>> >>>>>> >>> looks good for CLUE? >>>>>> >>>>>> >>>>>> >>>>>> “Implementations MUST implement SRTP [RFC3711 >>>>>> ]. Implementations MUST >>>>>> >>>>>> implement DTLS [RFC4347 ] >>>>>> and DTLS-SRTP [RFC5763 >>>>>> ][RFC5764] for >>>>> SRTP >>>>>> >>>>>> keying. Implementations MUST implement >>>>>> >>>>>> [I-D.ietf-tsvwg-sctp-dtls-encaps >>>>>> >>>>> -I- >>>>> >>>>>> >>> D.ietf-tsvwg-sctp-dtls-encaps>]. >>>>>> >>>>>> >>>>>> >>>>>> All media channels MUST be secured via SRTP. Media traffic MUST >>>>>> NOT >>>>>> >>>>>> be sent over plain (unencrypted) RTP; that is, implementations MUST >>>>>> >>>>>> NOT negotiate cipher suites with NULL encryption modes. >>>>>> DTLS-SRTP >>>>>> >>>>>> MUST be offered for every media channel. >>>>>> >>>>>> >>>>>> >>>>>> All data channels MUST be secured via DTLS. >>>>>> >>>>>> >>>>>> >>>>>> All implementations MUST implement DTLS 1.0, with the cipher suite >>>>>> >>>>>> TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA with the the P-256 curve >>>>>> >>>>>> [FIPS186 >>>>>> >>>>> - >>>>> >>>>>> >>> FIPS186>]. >>>>>> The DTLS-SRTP protection profile >>>>>> >>>>>> SRTP_AES128_CM_HMAC_SHA1_80 MUST be supported for SRTP. >>>>>> >>>>>> Implementations SHOULD implement DTLS 1.2 with the >>>>>> >>>>>> TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256 cipher suite. >>>>>> >>>>>> Implementations MUST favor cipher suites which support PFS over >>>>>> non- >>>>>> >>>>>> PFS cipher suites and SHOULD favor AEAD over non-AEAD cipher >>>>>> suites. >>>>>> >>>>>> “ >>>>> >>>>> >>>>> -- >>>>> >>>>> Magnus Westerlund >>>>> >>>>> -------------------------------------------------------------------- >>>>> -- >>>>> >>>>> >>> Services, Media and Network features, Ericsson Research EAB/TXM >>>>> -------------------------------------------------------------------- >>>>> -- >>>>> >>>>> >>> Ericsson AB | Phone +46 10 7148287 >>>>> Färögatan 6 | Mobile +46 73 0949079 SE-164 80 >>>>> Stockholm, Sweden | mailto: magnus.westerlund@ericsson.com >>>>> -------------------------------------------------------------------- >>>>> -- >>>> >>>>> >> >> _______________________________________________ >> clue mailing list >> clue@ietf.org >> https://www.ietf.org/mailman/listinfo/clue From nobody Mon Feb 13 01:30:00 2017 Return-Path: X-Original-To: clue@ietf.org Delivered-To: clue@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id B2C09129466; Mon, 13 Feb 2017 01:29:58 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: X-Test-IDTracker: no X-IETF-IDTracker: 6.43.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <148697819872.24905.9378282459902101772.idtracker@ietfa.amsl.com> Date: Mon, 13 Feb 2017 01:29:58 -0800 Archived-At: Cc: clue@ietf.org Subject: [clue] I-D Action: draft-ietf-clue-rtp-mapping-13.txt X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.17 List-Id: CLUE - ControLling mUltiple streams for TElepresence List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 13 Feb 2017 09:29:59 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the ControLling mUltiple streams for tElepresence of the IETF. Title : Mapping RTP streams to CLUE Media Captures Authors : Roni Even Jonathan Lennox Filename : draft-ietf-clue-rtp-mapping-13.txt Pages : 14 Date : 2017-02-13 Abstract: This document describes how the Real Time transport Protocol (RTP) is used in the context of the CLUE protocol (ControLling mUltiple streams for tElepresence). It also describes the mechanisms and recommended practice for mapping RTP media streams defined in Session Description Protocol (SDP) to CLUE Media Captures and defines a new RTP header extension (CaptureId). The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-clue-rtp-mapping/ There's also a htmlized version available at: https://tools.ietf.org/html/draft-ietf-clue-rtp-mapping-13 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-clue-rtp-mapping-13 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 Mon Feb 13 01:53:54 2017 Return-Path: X-Original-To: clue@ietfa.amsl.com Delivered-To: clue@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B8E7D1293FD for ; Mon, 13 Feb 2017 01:53:51 -0800 (PST) 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, RP_MATCHES_RCVD=-0.001, 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 zFii51PsW1ci for ; Mon, 13 Feb 2017 01:53:48 -0800 (PST) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 02FB31293DF for ; Mon, 13 Feb 2017 01:53:46 -0800 (PST) Received: from 172.18.7.190 (EHLO lhreml706-cah.china.huawei.com) ([172.18.7.190]) by lhrrg02-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id DAN60119; Mon, 13 Feb 2017 09:53:44 +0000 (GMT) Received: from DGGEMM405-HUB.china.huawei.com (10.3.20.213) by lhreml706-cah.china.huawei.com (10.201.5.182) with Microsoft SMTP Server (TLS) id 14.3.301.0; Mon, 13 Feb 2017 09:53:19 +0000 Received: from DGGEMM506-MBX.china.huawei.com ([169.254.3.117]) by DGGEMM405-HUB.china.huawei.com ([10.3.20.213]) with mapi id 14.03.0301.000; Mon, 13 Feb 2017 17:53:14 +0800 From: Roni Even To: Paul Kyzivat , "clue@ietf.org" Thread-Topic: [clue] Comments on CaptureID and security Thread-Index: AQHShWijSmQVYqqcLEWleHO7iQ8uOqFmr2Tg Date: Mon, 13 Feb 2017 09:53:13 +0000 Message-ID: <6E58094ECC8D8344914996DAD28F1CCD773733@DGGEMM506-MBX.china.huawei.com> References: <6E58094ECC8D8344914996DAD28F1CCD76DEFF@DGGEMM506-MBX.china.huawei.com> <5eb63eb7-0a07-cae4-cf7d-e4ff00fc7118@ericsson.com> <6E58094ECC8D8344914996DAD28F1CCD76DF3C@DGGEMM506-MBX.china.huawei.com> <74afe259-a7cd-c55b-ed4a-bea29ede012f@ericsson.com> <208e2d66-b7bf-8167-7c3d-6841df84192e@alum.mit.edu> <6E58094ECC8D8344914996DAD28F1CCD773571@DGGEMM506-MBX.china.huawei.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.200.201.150] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-CFilter-Loop: Reflected X-Mirapoint-Virus-RAPID-Raw: score=unknown(0), refid=str=0001.0A020204.58A18228.0254, ss=1, re=0.000, recu=0.000, reip=0.000, cl=1, cld=1, fgs=0, ip=169.254.3.117, so=2013-06-18 04:22:30, dmn=2013-03-21 17:37:32 X-Mirapoint-Loop-Id: 98a7b41afac6edef6b4b1affb1275325 Archived-At: Subject: Re: [clue] Comments on CaptureID and security X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: CLUE - ControLling mUltiple streams for TElepresence List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 13 Feb 2017 09:53:51 -0000 UGF1bCwNCk15IHVuZGVyc3RhbmRpbmcgaXMgSW5saW5lDQpSb25pDQoNCj4gLS0tLS1PcmlnaW5h bCBNZXNzYWdlLS0tLS0NCj4gRnJvbTogUGF1bCBLeXppdmF0IFttYWlsdG86cGt5eml2YXRAYWx1 bS5taXQuZWR1XQ0KPiBTZW50OiDXmdeV153CoNeQIDEyINek15HXqNeV15DXqCAyMDE3IDIxOjQ2 DQo+IFRvOiBSb25pIEV2ZW47IGNsdWVAaWV0Zi5vcmcNCj4gU3ViamVjdDogUmU6IFtjbHVlXSBD b21tZW50cyBvbiBDYXB0dXJlSUQgYW5kIHNlY3VyaXR5DQo+IA0KPiBSb25pLA0KPiANCj4gT24g Mi8xMi8xNyA1OjA3IEFNLCBSb25pIEV2ZW4gd3JvdGU6DQo+ID4gUGF1bCwNCj4gPiBGcm9tIFJG QzU3NjQNCj4gPiAiUlRQIGFuZCBSVENQIHRyYWZmaWMgTUFZIGJlIG11bHRpcGxleGVkIG9uIGEg c2luZ2xlIFVEUCBwb3J0DQo+ID4gICAgW1JGQzU3NjFdLiAgSW4gdGhpcyBjYXNlLCBib3RoIFJU UCBhbmQgUlRDUCBwYWNrZXRzIG1heSBiZSBzZW50IG92ZXINCj4gPiAgICB0aGUgc2FtZSBEVExT LVNSVFAgc2Vzc2lvbiwgaGFsdmluZyB0aGUgbnVtYmVyIG9mIERUTFMtU1JUUCBzZXNzaW9ucw0K PiA+ICAgIG5lZWRlZC4gIFRoaXMgaW1wcm92ZXMgdGhlIGNyeXB0b2dyYXBoaWMgcGVyZm9ybWFu Y2Ugb2YgRFRMUywgYnV0IG1heQ0KPiA+ICAgIGNhdXNlIHByb2JsZW1zIHdoZW4gUlRDUCBhbmQg UlRQIGFyZSBzdWJqZWN0IHRvIGRpZmZlcmVudCBuZXR3b3JrDQo+ID4gICAgdHJlYXRtZW50IChl LmcuLCBmb3IgYmFuZHdpZHRoIHJlc2VydmF0aW9uIG9yIHNjaGVkdWxpbmcgcmVhc29ucykuIg0K PiANCj4gTXkgdW5kZXJzdGFuZGluZyBvZiBSVFAvUlRDUCBpcyBtaW5pbWFsLCBzbyBteSBxdWVz dGlvbnMgbWF5IG5vdCBtYWtlDQo+IGFueSBzZW5zZS4gQnV0IGFzIGJlc3QgSSB1bmRlcnN0YW5k LCB3aGVuIFJUUC9SVENQIGlzIHJ1biBvdmVyIERUTFMgaXQgaXNuJ3QNCj4gc2VudCBhcyBEVExT IGVuY3J5cHRlZCBwYXlsb2FkLiBSYXRoZXIsIGl0IHJldXNlcyB0aGUgRFRMUyBuZWdvdGlhdGVk IGtleXMNCj4gYnV0IHRoZW4gZW5jcnlwdHMgdGhlIFJUUC9SVENQIGRhdGEgaW5kZXBlbmRlbnRs eQ0KW1JvbmkgRXZlbl0gdXNpbmcgU1JUUCB3aGljaCBkZWZpbmVzIHdoaWNoIHBhcnQgb2YgdGhl IFJUUCAvIFJUQ1AgcGFja2V0cyBhcmUgZW5jcnlwdGVkDQogYW5kIHNlbGVjdGl2ZWx5LCBzbyBz b21lDQo+IHBhcnRzIGFyZSBlbmNyeXB0ZWQgYW5kIG90aGVyIHBhcnRzIGFyZSBub3QuDQo+IA0K PiBCYXNlZCBvbiB0aGF0LCBteSBxdWVzdGlvbiBpcyB3aGV0aGVyLCB3aGVuIG11bHRpcGxleGlu ZyBSVFAgYW5kIFJUQ1AgYW5kDQo+IHJ1bm5pbmcgdGhlbSBvdmVyIERUTFMsIGl0IGlzIGF1dG9t YXRpYyB0aGF0IHRoZSBSVENQIHBpZWNlcyBhcmUgZW5jcnlwdGVkLA0KW1JvbmkgRXZlbl0gSSBk byBub3QgdGhpbmsgdGhhdCBpdCBpcyBpbXBsaWVkLCBkdGxzIHBhc3MgdGhlIHBhY2tldHMgdG8g dGhlIHNydHAgbGF5ZXIgd2hpY2ggZGVjaWRlIGhvdyB0byBzZWN1cmUgdGhlIFJUUCBhbmQgUlRD UA0KPiBvciBpZiBpdCBpcyBuZWNlc3NhcnkgdG8gbmVnb3RpYXRlIHNvbWV0aGluZyBleHBsaWNp dCBpbiB0aGUgU0RQIChhcGFydCBmcm9tDQo+IHdoYXQgaXMgbmVnb3RpYXRlZCBmb3IgdGhlIFJU UCkgdG8gY2F1c2UgdGhlIFJUQ1AgZGF0YSB0byBiZSBlbmNyeXB0ZWQuDQo+IA0KPiAJVGhhbmtz LA0KPiAJUGF1bA0KPiANCj4gPiBSb25pDQo+ID4NCj4gPj4gLS0tLS1PcmlnaW5hbCBNZXNzYWdl LS0tLS0NCj4gPj4gRnJvbTogY2x1ZSBbbWFpbHRvOmNsdWUtYm91bmNlc0BpZXRmLm9yZ10gT24g QmVoYWxmIE9mIFBhdWwgS3l6aXZhdA0KPiA+PiBTZW50OiDXmdeV150g15MgMTgg15nXoNeV15DX qCAyMDE3IDE4OjI2DQo+ID4+IFRvOiBjbHVlQGlldGYub3JnDQo+ID4+IFN1YmplY3Q6IFJlOiBb Y2x1ZV0gQ29tbWVudHMgb24gQ2FwdHVyZUlEIGFuZCBzZWN1cml0eQ0KPiA+Pg0KPiA+PiBJIGhh dmUgYSBzaWRlIHF1ZXN0aW9uIG9uIHRoaXM6IGlmIFJUQ1AgaXMgYmVpbmcgbXVsdGlwbGV4ZWQg d2l0aA0KPiA+PiBSVFAsIGFuZCB0aGUgUlRQIGlzIGJlaW5nIGVuY3J5cHRlZCwgaXMgdGhlIFJU Q1AgYWxzbyBpbXBsaWNpdGx5DQo+ID4+IGVuY3J5cHRlZCwgb3IgaXMgaXQgc3RpbGwgYW4gaW5k ZXBlbmRlbnRseSBuZWdvdGlhdGVkIGZlYXR1cmU/DQo+ID4+DQo+ID4+IChZZXMsIEkgcmVhbGl6 ZSB0aGF0IGRvZXNuJ3Qgc29sdmUgdGhlIGdlbmVyYWwgcHJvYmxlbSBmb3IgQ0xVRS4pDQo+ID4+ DQo+ID4+IAlUaGFua3MsDQo+ID4+IAlQYXVsDQo+ID4+DQo+ID4+IE9uIDEvMTgvMTcgNjo1MyBB TSwgTWFnbnVzIFdlc3Rlcmx1bmQgd3JvdGU6DQo+ID4+PiBIaSwNCj4gPj4+DQo+ID4+PiBZZXMs IEkgdGhpbmsgZW5jcnlwdGluZyB0aGUgQ2FwdHVyZUlEIGF2b2lkcyB0aGUgbmVnYXRpdmUgaW1w YWN0cw0KPiA+Pj4gdGhhdCBiYWQgY29uc3RydWN0aW9uIGNhbiBoYXZlIHRoYXQgSSBjYW4gdGhp bmsgb2YuIFRodXMsIEkgc3VwcG9ydA0KPiA+Pj4gZ29pbmcgaW4gdGhhdCBkaXJlY3Rpb24uDQo+ ID4+Pg0KPiA+Pj4gV2hlbiBpdCBjb21lcyB0byB0aGUgc2VjdXJpdHkgc29sdXRpb24gSSB3b3Vs ZCByZWNvbW1lbmQgY29weWluZyB0aGUNCj4gPj4+IHRleHQgYW5kIHRoZW4gbWFrZSB0aGUgZWRp dHMuIFRoZXJlIGlzIGF0IGxlYXN0IHR3byBhZGRpdGlvbnMsIHRoZQ0KPiA+Pj4gTVVTVCBlbmNy eXB0IFJUQ1AsIGFuZCB0aGUgTVVTVCBpbXBsZW1lbnQgUkZDIDY5MDQgYW5kIHVzZSBpdCB0bw0K PiA+Pj4gZW5jcnlwdCB0aGUgQ2FwdHVyZUlEIGhlYWRlciBleHRlbnNpb24uIFBsZWFzZSBiZSBl eHBsaWNpdCBhbmQgY2xlYXINCj4gPj4+IGluIHRoZSBDTFVFIGxldmVsIGRvY3VtZW50IG9uIHdo YXQgc2VjdXJpdHkgc29sdXRpb25zIHRoYXQgbmVlZHMgdG8NCj4gPj4+IGJlIGltcGxlbWVudGVk IGFuZCB1c2UuDQo+ID4+Pg0KPiA+Pj4gUmVhc29ucyBmb3IgY29weWluZyB0aGUgdGV4dCwgaXMg dGhhdCB0aGVyZSBhcmUgZGlmZmVyZW5jZXMgYmV0d2Vlbg0KPiA+Pj4gUlRDV2ViIGFuZCBDTFVF LCBhbmQgaW4gYWRkaXRpb24gSSB0aGluayB0aGUgaW1wbGVtZW50YXRpb24NCj4gPj4+IGNvbnNp ZGVyYXRpb25zIGFuZCBwb3RlbnRpYWwgbmVlZHMgdG8gbGF0ZXIgcmV2aXNlIHRoZSBzcGVjaWZp Y2F0aW9uDQo+ID4+PiBhcmUgZGlmZmVyZW50LiBJIGFtIG5vdCBjZXJ0YWluIENMVUUgd2lsbCB3 YW50IHRvIGJlIHJlcXVpcmVkIHRvDQo+ID4+PiBmb2xsb3cgYW55IGNoYW5nZXMgdGhhdCBSVENX ZWIgZG9lcyBpbiB0aGUgZnV0dXJlLg0KPiA+Pj4NCj4gPj4+IEkgd291bGQgYWxzbyBub3RlIHRo YXQgSSB0aGluayB5b3UgbmVlZCBhdCBsZWFzdCB0byBwdXQgaW4gYSBzaG9ydA0KPiA+Pj4gcGFy YWdyYXBoIGFib3V0IHRoZSBDYXB0dXJlSUQgdmFsdWUuIFNvbWV0aGluZyBsaWtlIHRoaXMuDQo+ ID4+Pg0KPiA+Pj4gVGhlIGNvbnN0cnVjdGlvbiBvZiB0aGUgQ2FwdHVyZUlEIHZhbHVlIGlzIGlt cGxlbWVudGF0aW9uIGRlcGVuZGVudA0KPiA+Pj4gYW5kIGlzIG5vdCB0aWdodGx5IHJlc3RyaWN0 ZWQuIFRoZXJlZm9yZSB0aGVyZSBleGlzdCBhIHJpc2sgdGhhdCB0aGUNCj4gPj4+IENhcHR1cmVJ RCBjb250YWlucyBwcml2YWN5IHNlbnNpdGl2ZSBpbmZvcm1hdGlvbiBvciBvdGhlcndpc2UNCj4g Pj4+IHJldmVhbGluZyBpbmZvcm1hdGlvbiBhYm91dCB0aGUgY29tbXVuaWNhdGlvbiBzZXNzaW9u IHRvIHRoaXJkDQo+ID4+PiBwYXJ0aWVzLiBUaGVyZWZvcmUgY29uZmlkZW50aWFsaXR5IHByb3Rl Y3Rpb24gaXMgYWx3YXlzIGFwcGxpZWQgdG8NCj4gPj4+IGF2b2lkIHRoaXMNCj4gPj4gcmlzay4N Cj4gPj4+DQo+ID4+PiBDaGVlcnMNCj4gPj4+DQo+ID4+PiBNYWdudXMNCj4gPj4+DQo+ID4+PiBE ZW4gMjAxNy0wMS0xOCBrbC4gMTA6NDQsIHNrcmV2IFJvbmkgRXZlbjoNCj4gPj4+PiBIaSwgVGhl IHRleHQgSSBhZGRlZCB0byB0aGUgLTExIHZlcnNpb24gIlRoZSBDYXB0dXJlSUQgaXMgY3JlYXRl ZA0KPiA+Pj4+IGFzIHBhcnQgb2YgdGhlIENMVUUgcHJvdG9jb2wuICBUaGUgQ2FwdElkIFNERVMg aXRlbSBpcyB1c2VkIHRvDQo+ID4+Pj4gY29udmV5IHRoZSBzYW1lIENhcHR1cmVJRCB2YWx1ZSBp biB0aGUgU0RFUyBpdGVtLiAgV2hlbiBzZW5kaW5nIHRoZQ0KPiA+Pj4+IFNERVMgaXRlbSB0aGUg c2VjdXJpdHkgY29uc2lkZXJ0aW9uIHNwZWNpZWQgaW4gdGhlIHNlY3VyaXR5IHNlY3Rpb24NCj4g Pj4+PiBvZiBbUkZDNzk0MV0gYXJlIGFwcGxpY2FibGUgYW5kIHRoaXMgU0RFUyBpdGVtIE1VU1Qg dXNlIHNpbWlsYXINCj4gPj4+PiBzZWN1cml0eSBhcyB0aGUgQ0xVRSBwcm90b2NvbCBtZXNzYWdl cyBjYXJyaWVkIGluIHRoZSBDTFVFIGRhdGENCj4gY2hhbm5lbC4iDQo+ID4+Pj4NCj4gPj4+PiBT YXkgdGhhdCAgIiB0aGlzIFNERVMgaXRlbSBNVVNUIHVzZSBzaW1pbGFyIHNlY3VyaXR5IGFzIHRo ZSBDTFVFDQo+ID4+Pj4gcHJvdG9jb2wgbWVzc2FnZXMgY2FycmllZCBpbiB0aGUgQ0xVRSBkYXRh IGNoYW5uZWwuIiBUaGUgQ0xVRSBkYXRhDQo+ID4+Pj4gY2hhbm5lbCBkb2N1bWVudA0KPiA+Pj4+ IGh0dHBzOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC1pZXRmLWNsdWUtZGF0YWNoYW5uZWwt MTQjc2VjdGlvbi0NCj4gPj4+PiA0DQo+ID4+Pj4gcG9pbnQgYXQNCj4gPj4+PiBodHRwczovL3Rv b2xzLmlldGYub3JnL2h0bWwvZHJhZnQtaWV0Zi1ydGN3ZWItZGF0YS1jaGFubmVsLTEzI3NlY3Rp DQo+ID4+Pj4gb24NCj4gPj4+PiAtNw0KPiA+Pj4+IHBvaW50aW5nIHRvDQo+ID4+Pj4gaHR0cHM6 Ly90b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0LWlldGYtcnRjd2ViLXNlY3VyaXR5LWFyY2gtMTAN Cj4gPj4+Pg0KPiA+Pj4+IFNvIHdlIGNhbiByZWZlcmVuY2UgdGhlIHJ0Y3dlYiBzZWN1cml0eSBh cmNoaXRlY3R1cmUgb3IgdXNlIHRoZQ0KPiA+Pj4+IHRleHQgSSBjb3BpZWQgZnJvbSB0aGVyZSB0 byBkZWZpbmUgYSBzZWN1cml0eSBwcm9maWxlDQo+ID4+Pj4NCj4gPj4+PiBBcyBmb3IgdGhlIHNl Y29uZCBpdGVtIEkgYWdyZWUgdGhhdCBpZiB3ZSBlbmNyeXB0IHRoZSBjb250ZW50IGluDQo+ID4+ Pj4gdGhlIENMVUUgZGF0YSBjaGFubmVsIHRoYXQgaW5jbHVkZXMgdGhlIGNhcHR1cmVJRCwgd2Ug bmVlZCBhbHNvIHRvDQo+ID4+Pj4gZW5jcnlwdCBSVENQIHdpdGggdGhlIGNhcHR1cmVJRCBTREVT IGl0ZW0gYW5kIGl0IGRvZXMgbm90IG1hdHRlcg0KPiA+Pj4+IGhvdyB3ZSBjcmVhdGUgdGhlIGNh cHR1cmVJRCB2YWx1ZSwgc28gbWF5YmUgaWYgd2UgbWFuZGF0ZQ0KPiA+Pj4+IGVuY3J5cHRpbmcg dGhlIFNERVMgaXRlbSB0aGVyZSBpcyBubyBzdHJvbmcgbmVlZCBmb3Igc3BlY2lmeWluZyBob3cN Cj4gPj4+PiB0byBjcmVhdGUgQ2FwdHVyZUlEIC4gTm90ZSB0aGF0IHRoZSBDYXB0dXJlSUQgaXMg bm90IHVzZSB0byBwcm92aWRlDQo+ID4+Pj4gaHVtYW4tcmVhZGFibGUgdGV4dHVhbCBpbmZvcm1h dGlvbiB3aGljaCBpcyBpbiB0aGUgZGVzY3JpcHRpb24NCj4gPj4+PiBhdHRyaWJ1dGUuDQo+ID4+ Pj4NCj4gPj4+PiBSb25pDQo+ID4+Pj4NCj4gPj4+Pj4gLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0t LS0gRnJvbTogTWFnbnVzIFdlc3Rlcmx1bmQNCj4gPj4+Pj4gW21haWx0bzptYWdudXMud2VzdGVy bHVuZEBlcmljc3Nvbi5jb21dIFNlbnQ6INeZ15XXnSDXkyAxOCDXmdeg15XXkNeoIDIwMTcNCj4g Pj4+Pj4gMTA6NDUgVG86IFJvbmkgRXZlbjsgY2x1ZUBpZXRmLm9yZyBDYzogSm9uYXRoYW4gTGVu bm94IFN1YmplY3Q6IFJlOg0KPiA+Pj4+PiBDb21tZW50cyBvbiBDYXB0dXJlSUQgYW5kIHNlY3Vy aXR5DQo+ID4+Pj4+DQo+ID4+Pj4+IEhpLA0KPiA+Pj4+Pg0KPiA+Pj4+PiBBIGNvbW1lbnQgYWJv dXQgdGhlIGJlbG93LiBJIGhhdmUgYW4gaXNzdWUgcmFpc2VkIGFnYWluc3QgdGhlDQo+ID4+Pj4+ IGJlbG93IHF1b3RlZCB0ZXh0IGZyb20gdGhlIHJ0Y3dlYi1zZWN1cml0eS1hcmNoaXRlY3R1cmUg aW4gdGhlDQo+ID4+Pj4+IFJUQ1dlYiBXRywgYXMgaXQgZmFpbHMgdG8gc3BlY2lmeSBpZiBSVENQ IGVuY3J5cHRpb24gaXMgbWFuZGF0b3J5DQo+ID4+Pj4+IHRvIHVzZSBvciBub3QuIFRoZXJlIGFy ZSBwcm90ZWN0aW9uIHByb2ZpbGVzIHRoYXQgb25seSBoYXZlDQo+ID4+Pj4+IGNvbmZpZGVudGlh bGl0eSBwcm90ZWN0aW9uIGZvciBSVFAsIGFuZCBub3QgZm9yIFJUQ1AuIEkgd291bGQNCj4gPj4+ Pj4gcmVjb21tZW5kIHJlcXVpcmluZyBjb25maWRlbnRpYWxpdHkgcHJvdGVjdGlvbiBhbHNvIG9m IFJUQ1AuDQo+ID4+Pj4+DQo+ID4+Pj4+IFRoZSBzZWNvbmQgbm90ZSBvbiB0aGUgYmVsb3cgaXMg dGhhdCBkZXBlbmRpbmcgb24gdGhlIG91dGNvbWUgb2YNCj4gPj4+Pj4gdGhlIHNlY3VyaXR5IHJl cXVpcmVtZW50cyBmb3IgdGhlIENhcHR1cmVJRCBSVFAgaGVhZGVyIGV4dGVuc2lvbiwNCj4gPj4+ Pj4geW91IG1pZ2h0IGluIGFkZGl0aW9uIGhhdmUgdG8gcmVxdWlyZSBSRkMgNjkwNCwgaW1wbGVt ZW50YXRpb24gYW5kDQo+ID4+Pj4+IHVzYWdlIGZvciB0aGUgQ2FwdHVyZUlkIGhlYWRlciBleHRl bnNpb24gZmllbGQuIE9yIHJhdGhlciBpZiB5b3UNCj4gPj4+Pj4gd3JpdGUgbm90aGluZyBpdCB3 aWxsIGJ5IGRlZmF1bHQgYmUgcmVxdWlyZWQgaWYgeW91IGVuY3J5cHQgUlRDUCwNCj4gPj4+Pj4g ZHVlIHRvIFJGQyA3OTQxLiBCdXQsIEkgcmVhbGx5IHJlY29tbWVuZCB0aGF0IHlvdSBhcmUgZXhw bGljaXQgb24NCj4gPj4+Pj4gdGhpcyBtYXR0ZXIuIEl0IGNvbWVzIGRvd24gdG8gd2hhdCBzZWN1 cml0eSByaXNrcyB0aGUgZmllbGQNCj4gPj4+Pj4gZW50YWlscy4gV2hhdCBpbmZvcm1hdGlvbiB3 aWxsIGl0IGxlYWsgdG8gYSB0aGlyZCBwYXJ0eSB2aWV3ZXIgb2YNCj4gPj4+Pj4gdGhlIFJUUC9S VENQIHN0cmVhbSB0aGV5IGNhbiBjYXB0dXJlLg0KPiA+Pj4+Pg0KPiA+Pj4+PiBDaGVlcnMNCj4g Pj4+Pj4NCj4gPj4+Pj4gTWFnbnVzDQo+ID4+Pj4+DQo+ID4+Pj4+IERlbiAyMDE3LTAxLTE4IGts LiAwOTozMywgc2tyZXYgUm9uaSBFdmVuOg0KPiA+Pj4+Pj4gMi4gICAgICAgV2hhdCBkbyB3ZSB3 YW50IHRvIHNheSBhYm91dCBzdXBwb3J0ZWQgc2VjdXJpdHkgcHJvZmlsZT8NCj4gPj4+Pj4+IEZv ciBleGFtcGxlIGRvZXMgdGhlIGZvbGxvd2luZyBkaXJlY3RpdmUgZnJvbQ0KPiA+Pj4+Pj4gaHR0 cHM6Ly90b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0LWlldGYtcnRjd2ViLXNlY3VyaXR5LWFyY2gt MTIjc2UNCj4gPj4+Pj4+IGN0DQo+ID4+Pj4+PiBpb24tNS41DQo+ID4+Pj4+Pg0KPiA+Pj4+Pj4N Cj4gPj4+Pj4+DQo+ID4+PiBsb29rcyBnb29kIGZvciBDTFVFPw0KPiA+Pj4+Pj4NCj4gPj4+Pj4+ DQo+ID4+Pj4+Pg0KPiA+Pj4+Pj4g4oCcSW1wbGVtZW50YXRpb25zIE1VU1QgaW1wbGVtZW50IFNS VFAgW1JGQzM3MTENCj4gPj4+Pj4+IDxodHRwczovL3Rvb2xzLmlldGYub3JnL2h0bWwvcmZjMzcx MT5dLiAgSW1wbGVtZW50YXRpb25zIE1VU1QNCj4gPj4+Pj4+DQo+ID4+Pj4+PiBpbXBsZW1lbnQg RFRMUyBbUkZDNDM0NyA8aHR0cHM6Ly90b29scy5pZXRmLm9yZy9odG1sL3JmYzQzNDc+XQ0KPiA+ Pj4+Pj4gYW5kIERUTFMtU1JUUCBbUkZDNTc2Mw0KPiA+Pj4+Pj4gPGh0dHBzOi8vdG9vbHMuaWV0 Zi5vcmcvaHRtbC9yZmM1NzYzPl1bUkZDNTc2NF0gZm9yDQo+ID4+Pj4+IFNSVFANCj4gPj4+Pj4+ DQo+ID4+Pj4+PiBrZXlpbmcuICBJbXBsZW1lbnRhdGlvbnMgTVVTVCBpbXBsZW1lbnQNCj4gPj4+ Pj4+DQo+ID4+Pj4+PiBbSS1ELmlldGYtdHN2d2ctc2N0cC1kdGxzLWVuY2Fwcw0KPiA+Pj4+Pj4g PGh0dHBzOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC1pZXRmLXJ0Y3dlYi1zZWN1cml0eS1h cmNoLTEyI3INCj4gPj4+Pj4+IGVmDQo+ID4+Pj4+PiAtSS0NCj4gPj4+Pj4NCj4gPj4+Pj4+DQo+ ID4+PiBELmlldGYtdHN2d2ctc2N0cC1kdGxzLWVuY2Fwcz5dLg0KPiA+Pj4+Pj4NCj4gPj4+Pj4+ DQo+ID4+Pj4+Pg0KPiA+Pj4+Pj4gQWxsIG1lZGlhIGNoYW5uZWxzIE1VU1QgYmUgc2VjdXJlZCB2 aWEgU1JUUC4gIE1lZGlhIHRyYWZmaWMgTVVTVA0KPiA+Pj4+Pj4gTk9UDQo+ID4+Pj4+Pg0KPiA+ Pj4+Pj4gYmUgc2VudCBvdmVyIHBsYWluICh1bmVuY3J5cHRlZCkgUlRQOyB0aGF0IGlzLCBpbXBs ZW1lbnRhdGlvbnMNCj4gPj4+Pj4+IE1VU1QNCj4gPj4+Pj4+DQo+ID4+Pj4+PiBOT1QgbmVnb3Rp YXRlIGNpcGhlciBzdWl0ZXMgd2l0aCBOVUxMIGVuY3J5cHRpb24gbW9kZXMuDQo+ID4+Pj4+PiBE VExTLVNSVFANCj4gPj4+Pj4+DQo+ID4+Pj4+PiBNVVNUIGJlIG9mZmVyZWQgZm9yIGV2ZXJ5IG1l ZGlhIGNoYW5uZWwuDQo+ID4+Pj4+Pg0KPiA+Pj4+Pj4NCj4gPj4+Pj4+DQo+ID4+Pj4+PiBBbGwg ZGF0YSBjaGFubmVscyBNVVNUIGJlIHNlY3VyZWQgdmlhIERUTFMuDQo+ID4+Pj4+Pg0KPiA+Pj4+ Pj4NCj4gPj4+Pj4+DQo+ID4+Pj4+PiBBbGwgaW1wbGVtZW50YXRpb25zIE1VU1QgaW1wbGVtZW50 IERUTFMgMS4wLCB3aXRoIHRoZSBjaXBoZXINCj4gPj4+Pj4+IHN1aXRlDQo+ID4+Pj4+Pg0KPiA+ Pj4+Pj4gVExTX0VDREhFX0VDRFNBX1dJVEhfQUVTXzEyOF9DQkNfU0hBIHdpdGggdGhlIHRoZSBQ LTI1Ng0KPiBjdXJ2ZQ0KPiA+Pj4+Pj4NCj4gPj4+Pj4+IFtGSVBTMTg2DQo+ID4+Pj4+PiA8aHR0 cHM6Ly90b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0LWlldGYtcnRjd2ViLXNlY3VyaXR5LWFyY2gt MTIjcg0KPiA+Pj4+Pj4gZWYNCj4gPj4+Pj4+IC0NCj4gPj4+Pj4NCj4gPj4+Pj4+DQo+ID4+PiBG SVBTMTg2Pl0uDQo+ID4+Pj4+PiBUaGUgRFRMUy1TUlRQIHByb3RlY3Rpb24gcHJvZmlsZQ0KPiA+ Pj4+Pj4NCj4gPj4+Pj4+IFNSVFBfQUVTMTI4X0NNX0hNQUNfU0hBMV84MCBNVVNUIGJlIHN1cHBv cnRlZCBmb3IgU1JUUC4NCj4gPj4+Pj4+DQo+ID4+Pj4+PiBJbXBsZW1lbnRhdGlvbnMgU0hPVUxE IGltcGxlbWVudCBEVExTIDEuMiB3aXRoIHRoZQ0KPiA+Pj4+Pj4NCj4gPj4+Pj4+IFRMU19FQ0RI RV9FQ0RTQV9XSVRIX0FFU18xMjhfR0NNX1NIQTI1NiBjaXBoZXIgc3VpdGUuDQo+ID4+Pj4+Pg0K PiA+Pj4+Pj4gSW1wbGVtZW50YXRpb25zIE1VU1QgZmF2b3IgY2lwaGVyIHN1aXRlcyB3aGljaCBz dXBwb3J0IFBGUyBvdmVyDQo+ID4+Pj4+PiBub24tDQo+ID4+Pj4+Pg0KPiA+Pj4+Pj4gUEZTIGNp cGhlciBzdWl0ZXMgYW5kIFNIT1VMRCBmYXZvciBBRUFEIG92ZXIgbm9uLUFFQUQgY2lwaGVyDQo+ ID4+Pj4+PiBzdWl0ZXMuDQo+ID4+Pj4+Pg0KPiA+Pj4+Pj4g4oCcDQo+ID4+Pj4+DQo+ID4+Pj4+ DQo+ID4+Pj4+IC0tDQo+ID4+Pj4+DQo+ID4+Pj4+IE1hZ251cyBXZXN0ZXJsdW5kDQo+ID4+Pj4+ DQo+ID4+Pj4+IC0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLQ0KPiA+Pj4+PiAtLQ0KPiA+Pj4+PiAtLQ0KPiA+Pj4+Pg0KPiA+ Pj4+Pg0KPiA+Pj4gU2VydmljZXMsIE1lZGlhIGFuZCBOZXR3b3JrIGZlYXR1cmVzLCBFcmljc3Nv biBSZXNlYXJjaCBFQUIvVFhNDQo+ID4+Pj4+IC0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLQ0KPiA+Pj4+PiAtLQ0KPiA+Pj4+ PiAtLQ0KPiA+Pj4+Pg0KPiA+Pj4+Pg0KPiA+Pj4gRXJpY3Nzb24gQUIgICAgICAgICAgICAgICAg IHwgUGhvbmUgICs0NiAxMCA3MTQ4Mjg3DQo+ID4+Pj4+IEbDpHLDtmdhdGFuIDYgICAgICAgICAg ICAgICAgIHwgTW9iaWxlICs0NiA3MyAwOTQ5MDc5IFNFLTE2NCA4MA0KPiA+Pj4+PiBTdG9ja2hv bG0sIFN3ZWRlbiB8IG1haWx0bzogbWFnbnVzLndlc3Rlcmx1bmRAZXJpY3Nzb24uY29tDQo+ID4+ Pj4+IC0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLQ0KPiA+Pj4+PiAtLQ0KPiA+Pj4+PiAtLQ0KPiA+Pj4+DQo+ID4+Pj4+DQo+ ID4+DQo+ID4+IF9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f DQo+ID4+IGNsdWUgbWFpbGluZyBsaXN0DQo+ID4+IGNsdWVAaWV0Zi5vcmcNCj4gPj4gaHR0cHM6 Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9jbHVlDQoNCg== From nobody Mon Feb 13 02:00:25 2017 Return-Path: X-Original-To: clue@ietfa.amsl.com Delivered-To: clue@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7D28D12955B for ; Mon, 13 Feb 2017 02:00:23 -0800 (PST) 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, RP_MATCHES_RCVD=-0.001, 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 Ihym997jHasw for ; Mon, 13 Feb 2017 02:00:22 -0800 (PST) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9B3FD1293FD for ; Mon, 13 Feb 2017 02:00:21 -0800 (PST) Received: from 172.18.7.190 (EHLO lhreml704-cah.china.huawei.com) ([172.18.7.190]) by lhrrg01-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id DGJ67896; Mon, 13 Feb 2017 10:00:18 +0000 (GMT) Received: from DGGEMM401-HUB.china.huawei.com (10.3.20.209) by lhreml704-cah.china.huawei.com (10.201.5.130) with Microsoft SMTP Server (TLS) id 14.3.301.0; Mon, 13 Feb 2017 09:59:26 +0000 Received: from DGGEMM506-MBX.china.huawei.com ([169.254.3.117]) by DGGEMM401-HUB.china.huawei.com ([10.3.20.209]) with mapi id 14.03.0301.000; Mon, 13 Feb 2017 17:59:22 +0800 From: Roni Even To: "clue@ietf.org" Thread-Topic: [clue] I-D Action: draft-ietf-clue-rtp-mapping-13.txt Thread-Index: AQHShdwQ39XSQRP1D0CafEj5+qLan6FmsmKQ Date: Mon, 13 Feb 2017 09:59:22 +0000 Message-ID: <6E58094ECC8D8344914996DAD28F1CCD77374B@DGGEMM506-MBX.china.huawei.com> References: <148697819872.24905.9378282459902101772.idtracker@ietfa.amsl.com> In-Reply-To: <148697819872.24905.9378282459902101772.idtracker@ietfa.amsl.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.200.201.150] Content-Type: text/plain; charset="windows-1255" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-CFilter-Loop: Reflected X-Mirapoint-Virus-RAPID-Raw: score=unknown(0), refid=str=0001.0A020206.58A183B2.02D5, ss=1, re=0.000, recu=0.000, reip=0.000, cl=1, cld=1, fgs=0, ip=169.254.3.117, so=2013-06-18 04:22:30, dmn=2013-03-21 17:37:32 X-Mirapoint-Loop-Id: 566214e471640e367f8b36a791f674c3 Archived-At: Subject: [clue] FW: I-D Action: draft-ietf-clue-rtp-mapping-13.txt X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: CLUE - ControLling mUltiple streams for TElepresence List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 13 Feb 2017 10:00:23 -0000 Hi, This new version is submitted to address Magnus and Ben comments. There is a new section Communication security that specifies normative secu= rity for CLUE media. The security consideration is just considerations and added text about the = CaptureID There are also some editorial and nits changes Roni -----Original Message----- From: clue [mailto:clue-bounces@ietf.org] On Behalf Of internet-drafts@ietf= .org Sent: =E9=E5=ED=A0=E1 13 =F4=E1=F8=E5=E0=F8 2017 11:30 To: i-d-announce@ietf.org Cc: clue@ietf.org Subject: [clue] I-D Action: draft-ietf-clue-rtp-mapping-13.txt A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the ControLling mUltiple streams for tEleprese= nce of the IETF. Title : Mapping RTP streams to CLUE Media Captures Authors : Roni Even Jonathan Lennox Filename : draft-ietf-clue-rtp-mapping-13.txt Pages : 14 Date : 2017-02-13 Abstract: This document describes how the Real Time transport Protocol (RTP) is used in the context of the CLUE protocol (ControLling mUltiple streams for tElepresence). It also describes the mechanisms and recommended practice for mapping RTP media streams defined in Session Description Protocol (SDP) to CLUE Media Captures and defines a new RTP header extension (CaptureId). The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-clue-rtp-mapping/ There's also a htmlized version available at: https://tools.ietf.org/html/draft-ietf-clue-rtp-mapping-13 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-clue-rtp-mapping-13 Please note that it may take a couple of minutes from the time of submissio= n 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/ _______________________________________________ clue mailing list clue@ietf.org https://www.ietf.org/mailman/listinfo/clue From nobody Mon Feb 13 08:04:19 2017 Return-Path: X-Original-To: clue@ietfa.amsl.com Delivered-To: clue@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D1575129524 for ; Mon, 13 Feb 2017 08:04:17 -0800 (PST) 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, RP_MATCHES_RCVD=-0.001, 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 cjob0-4oL9l6 for ; Mon, 13 Feb 2017 08:04:16 -0800 (PST) Received: from alum-mailsec-scanner-8.mit.edu (alum-mailsec-scanner-8.mit.edu [18.7.68.20]) by ietfa.amsl.com (Postfix) with ESMTP id 32AD31294F5 for ; Mon, 13 Feb 2017 08:04:16 -0800 (PST) X-AuditID: 12074414-7efff70000002bfd-1d-58a1d8fec8ef 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-8.mit.edu (Symantec Messaging Gateway) with SMTP id D9.C1.11261.EF8D1A85; Mon, 13 Feb 2017 11:04:14 -0500 (EST) Received: from [192.168.1.110] (c-73-186-127-100.hsd1.ma.comcast.net [73.186.127.100]) (authenticated bits=0) (User authenticated as pkyzivat@ALUM.MIT.EDU) by outgoing-alum.mit.edu (8.13.8/8.12.4) with ESMTP id v1DG4D5O009706 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT) for ; Mon, 13 Feb 2017 11:04:14 -0500 To: clue@ietf.org References: <148697819872.24905.9378282459902101772.idtracker@ietfa.amsl.com> <6E58094ECC8D8344914996DAD28F1CCD77374B@DGGEMM506-MBX.china.huawei.com> From: Paul Kyzivat Message-ID: <4b1cde72-e134-6d49-38a7-878683cbf6d0@alum.mit.edu> Date: Mon, 13 Feb 2017 11:04:13 -0500 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:45.0) Gecko/20100101 Thunderbird/45.7.1 MIME-Version: 1.0 In-Reply-To: <6E58094ECC8D8344914996DAD28F1CCD77374B@DGGEMM506-MBX.china.huawei.com> Content-Type: text/plain; charset=windows-1255; format=flowed Content-Transfer-Encoding: 8bit X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFjrNIsWRmVeSWpSXmKPExsUixO6iqPvvxsIIg80bdS32n7rM7MDosWTJ T6YAxigum5TUnMyy1CJ9uwSujPcLD7EUHBCvOHNkJWsD436hLkZODgkBE4mF868xdzFycQgJ 7GCS+PH7NBOE85pJ4u63BUwgVcICbhInnp5i6WLk4BAREJR4eUUQomY6o8Tkvz2sIDVsAloS cw79ZwGxeQXsJR6/WcgMYrMIqErM/PEBzBYVSJN42vidGaJGUOLkzCdg9ZwCIRKT1k1kB7GZ BWwl/v58zQphy0s0b53NPIGRbxaSlllIymYhKVvAyLyKUS4xpzRXNzcxM6c4NVm3ODkxLy+1 SNdCLzezRC81pXQTIyTMRHYwHjkpd4hRgINRiYd3woGFEUKsiWXFlbmHGCU5mJREeWM3AYX4 kvJTKjMSizPii0pzUosPMUpwMCuJ8O48A5TjTUmsrEotyodJSXOwKInzflus7ickkJ5Ykpqd mlqQWgSTleHgUJLg9QHGk5BgUWp6akVaZk4JQpqJgxNkOA/Q8JfXQYYXFyTmFmemQ+RPMSpK ifN2gSQEQBIZpXlwvbA08IpRHOgVYd51IFU8wBQC1/0KaDAT0GDWOLDBJYkIKakGRi6vZWKc eXNOsN1vfRq94ubR/VVWr4+dNVk7Ifjbow2LXqRP/q7PtubAfBFu94h7C2Un33ja0a++XnHt 90O/ep9cU9C06sn/Xlmb/0uur+oWh358Xrjqvqmu4inPXDzX3V2ms8b/mPZvn0+3jWs4/i2x m3crue/kGSe3W949ky4+frfMUvnBCh0lluKMREMt5qLiRADiXMf93gIAAA== Archived-At: Subject: Re: [clue] FW: I-D Action: draft-ietf-clue-rtp-mapping-13.txt X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: CLUE - ControLling mUltiple streams for TElepresence List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 13 Feb 2017 16:04:18 -0000 On 2/13/17 4:59 AM, Roni Even wrote: > Hi, > This new version is submitted to address Magnus and Ben comments. > There is a new section Communication security that specifies normative security for CLUE media. > The security consideration is just considerations and added text about the CaptureID > There are also some editorial and nits changes > Roni Magnus & Ben: does this resolve your issues? I noticed one nit: In Section 10 the following text: ... A mandatory to implement and use media security solution is created by combining this secured RTP profile and DTLS-SRTP keying [RFC5764] as defined in the communication security section of this memo Section 7 is lacking a period at the end. Based on the diffs it may also be lacking a paragraph break, but in the actual document there is a page break there so it is hard to say for sure. No need to fix it now. It can await the next edit. Thanks, Paul > -----Original Message----- > From: clue [mailto:clue-bounces@ietf.org] On Behalf Of internet-drafts@ietf.org > Sent: 13 2017 11:30 > To: i-d-announce@ietf.org > Cc: clue@ietf.org > Subject: [clue] I-D Action: draft-ietf-clue-rtp-mapping-13.txt > > > A New Internet-Draft is available from the on-line Internet-Drafts directories. > This draft is a work item of the ControLling mUltiple streams for tElepresence of the IETF. > > Title : Mapping RTP streams to CLUE Media Captures > Authors : Roni Even > Jonathan Lennox > Filename : draft-ietf-clue-rtp-mapping-13.txt > Pages : 14 > Date : 2017-02-13 > > Abstract: > This document describes how the Real Time transport Protocol (RTP) is > used in the context of the CLUE protocol (ControLling mUltiple > streams for tElepresence). It also describes the mechanisms and > recommended practice for mapping RTP media streams defined in Session > Description Protocol (SDP) to CLUE Media Captures and defines a new > RTP header extension (CaptureId). > > > The IETF datatracker status page for this draft is: > https://datatracker.ietf.org/doc/draft-ietf-clue-rtp-mapping/ > > There's also a htmlized version available at: > https://tools.ietf.org/html/draft-ietf-clue-rtp-mapping-13 > > A diff from the previous version is available at: > https://www.ietf.org/rfcdiff?url2=draft-ietf-clue-rtp-mapping-13 > > > 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/ > > _______________________________________________ > clue mailing list > clue@ietf.org > https://www.ietf.org/mailman/listinfo/clue > > _______________________________________________ > clue mailing list > clue@ietf.org > https://www.ietf.org/mailman/listinfo/clue > From nobody Thu Feb 23 00:32:42 2017 Return-Path: X-Original-To: clue@ietfa.amsl.com Delivered-To: clue@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0FE4C12A14C for ; Thu, 23 Feb 2017 00:32:41 -0800 (PST) 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 Ynhx613yKt8m for ; Thu, 23 Feb 2017 00:32:39 -0800 (PST) Received: from sessmg23.ericsson.net (sessmg23.ericsson.net [193.180.251.45]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7DBD4129C60 for ; Thu, 23 Feb 2017 00:32:39 -0800 (PST) X-AuditID: c1b4fb2d-18e0e98000005112-99-58ae9e25e8b7 Received: from ESESSHC024.ericsson.se (Unknown_Domain [153.88.183.90]) by (Symantec Mail Security) with SMTP id 27.B6.20754.52E9EA85; Thu, 23 Feb 2017 09:32:37 +0100 (CET) Received: from [127.0.0.1] (153.88.183.153) by smtp.internal.ericsson.com (153.88.183.92) with Microsoft SMTP Server id 14.3.319.2; Thu, 23 Feb 2017 09:32:30 +0100 To: Roni Even , "clue@ietf.org" References: <6E58094ECC8D8344914996DAD28F1CCD76DEFF@DGGEMM506-MBX.china.huawei.com> <5eb63eb7-0a07-cae4-cf7d-e4ff00fc7118@ericsson.com> <6E58094ECC8D8344914996DAD28F1CCD76DF3C@DGGEMM506-MBX.china.huawei.com> <74afe259-a7cd-c55b-ed4a-bea29ede012f@ericsson.com> <6E58094ECC8D8344914996DAD28F1CCD773548@DGGEMM506-MBX.china.huawei.com> From: Magnus Westerlund Message-ID: Date: Thu, 23 Feb 2017 09:32:30 +0100 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.7.1 MIME-Version: 1.0 In-Reply-To: <6E58094ECC8D8344914996DAD28F1CCD773548@DGGEMM506-MBX.china.huawei.com> Content-Type: text/plain; charset="utf-8"; format=flowed Content-Transfer-Encoding: 8bit X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFtrLLMWRmVeSWpSXmKPExsUyM2J7lK7qvHURBh1LDC32n7rMbLF/8Xlm i0/HzrM4MHu0HHnL6rFkyU8mj7Znd9gDmKO4bFJSczLLUov07RK4Mm5NyC6YIFRxZccD9gbG u3xdjBwcEgImEp3nk7sYuTiEBNYxSjycvpoRwlnOKPHs/gXmLkZODmEBfYnVy+awg9giAq4S RxbsY4couswkseXPS3aQScwCGhJNEyJAatgELCRu/mhkA7F5BewlZl58xwJiswioSky5uxLM FhWIkdjbf58JokZQ4uTMJ2BxToEQiQkXz7GC2MxAc2bOP88IYctLNG+dDXaPkIC2RENTB+sE RoFZSNpnIWmZhaRlASPzKkbR4tTi4tx0I2O91KLM5OLi/Dy9vNSSTYzAQD245bfuDsbVrx0P MQpwMCrx8BYsXxshxJpYVlyZe4hRgoNZSYQ3a/a6CCHelMTKqtSi/Pii0pzU4kOM0hwsSuK8 ZivvhwsJpCeWpGanphakFsFkmTg4pRoYVxbs/lFzu7ngypYLN73z5+9VOBA3c//Nyhf7eVYn XnvrXyMvbTBbcvob3yts/w9yzZ61nWHRW+W5EzY+rGNNSLwYtHHHgrNtuxXmqKuoL2/cFbLs z5Ibtkv+/1v8NMcpL+CE8te693mrPFScPxua/AisfXhK4R3H//nKZ9JOeb6vuPaoibv0/kkl luKMREMt5qLiRAAYs/ehUAIAAA== Archived-At: Cc: Jonathan Lennox Subject: Re: [clue] Comments on CaptureID and security X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: CLUE - ControLling mUltiple streams for TElepresence List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 23 Feb 2017 08:32:41 -0000 Hi Roni, Den 2017-02-12 kl. 10:26, skrev Roni Even: > Hi Magnus, About the requirement to encrypt the RTCP (do not use NULL > security profile) I was wondering why it is not mention also on > RTCPweb, is it because RTP/RTCP multiplexing? I think that it should > be mentioned also there since there is option to support non > multiplex RTP/RTCP That is actually a shortcoming of RTCWeb Security architecture and there exists an tracked issue for it: https://github.com/rtcweb-wg/security-arch/issues/34 So, yes, I would really like to see the communication security section mandate encrypted RTCP. This due to the information included in RTCP about the application. The protection profile mandated does imply equal strength RTCP protection, but if one uses other profiles it might not be as clear cut. So a wording on protecting RTCP at same or similar protection strength to RTP I think is motivated. What I also think is missing in the new text is discussion of RTP header extension encryption, i.e. RFC 6904. I thought the conclusion on the capture ID is that there is no strong generation requirements to ensure they don't contain privacy sensitive information. And it definitely reveals what is happening in the application context to third parties. Thus, I think encrypting the RTP header extensions would be good practice in clue situations. I also reacted to the use of "untraceable" in this sentence: CLUE endpoint MUST generate short-term persistent RTCP CNAMES, as specified in [RFC7022], resulting in untraceable CNAME values. The point of them is that they are not long term persistent and thus can't be used for long term tracking of the user. Writing "untraceable" I would interpret as indicating a stronger user protection then what is actually provided. Magnus Westerlund ---------------------------------------------------------------------- Services, Media and Network features, Ericsson Research EAB/TXM ---------------------------------------------------------------------- Ericsson AB | Phone +46 10 7148287 Färögatan 6 | Mobile +46 73 0949079 SE-164 80 Stockholm, Sweden | mailto: magnus.westerlund@ericsson.com ---------------------------------------------------------------------- From nobody Thu Feb 23 00:51:15 2017 Return-Path: X-Original-To: clue@ietfa.amsl.com Delivered-To: clue@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C041D12968E for ; Thu, 23 Feb 2017 00:51:09 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-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 3PN6H70wIKLr for ; Thu, 23 Feb 2017 00:51:07 -0800 (PST) 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 BD6AF129688 for ; Thu, 23 Feb 2017 00:51:07 -0800 (PST) Received: from [10.10.1.4] ([162.216.46.73]) (authenticated bits=0) by nostrum.com (8.15.2/8.15.2) with ESMTPSA id v1N8op97059399 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NO); Thu, 23 Feb 2017 02:51:00 -0600 (CST) (envelope-from ben@nostrum.com) X-Authentication-Warning: raven.nostrum.com: Host [162.216.46.73] claimed to be [10.10.1.4] From: "Ben Campbell" To: "Paul Kyzivat" Date: Thu, 23 Feb 2017 09:50:50 +0100 Message-ID: <637FA052-9925-462E-AD6B-ED2837DF8CAE@nostrum.com> In-Reply-To: <4b1cde72-e134-6d49-38a7-878683cbf6d0@alum.mit.edu> References: <148697819872.24905.9378282459902101772.idtracker@ietfa.amsl.com> <6E58094ECC8D8344914996DAD28F1CCD77374B@DGGEMM506-MBX.china.huawei.com> <4b1cde72-e134-6d49-38a7-878683cbf6d0@alum.mit.edu> MIME-Version: 1.0 Content-Type: text/plain; format=flowed; markup=markdown X-Mailer: MailMate (1.9.6r5347) Archived-At: Cc: clue@ietf.org Subject: Re: [clue] I-D Action: draft-ietf-clue-rtp-mapping-13.txt X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: CLUE - ControLling mUltiple streams for TElepresence List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 23 Feb 2017 08:51:10 -0000 On 13 Feb 2017, at 17:04, Paul Kyzivat wrote: > Magnus & Ben: does this resolve your issues? Yes for me. (Sorry for the delay, I cleared my discuss a while back, but I guess I failed to answer this.) Thanks! Ben. From nobody Thu Feb 23 03:36:23 2017 Return-Path: X-Original-To: clue@ietf.org Delivered-To: clue@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 85519129B2B; Thu, 23 Feb 2017 03:36:19 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: X-Test-IDTracker: no X-IETF-IDTracker: 6.45.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <148784977951.20366.2805731545649153843.idtracker@ietfa.amsl.com> Date: Thu, 23 Feb 2017 03:36:19 -0800 Archived-At: Cc: clue@ietf.org Subject: [clue] I-D Action: draft-ietf-clue-protocol-13.txt X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.17 List-Id: CLUE - ControLling mUltiple streams for TElepresence List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 23 Feb 2017 11:36:19 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the ControLling mUltiple streams for tElepresence of the IETF. Title : CLUE protocol Authors : Roberta Presta Simon Pietro Romano Filename : draft-ietf-clue-protocol-13.txt Pages : 63 Date : 2017-02-23 Abstract: The CLUE protocol is an application protocol conceived for the description and negotiation of a telepresence session. The design of the CLUE protocol takes into account the requirements and the framework defined within the IETF CLUE working group. A companion document delves into CLUE signaling details, as well as on the SIP/ SDP session establishment phase. CLUE messages flow over the CLUE data channel, based on reliable and ordered SCTP over DTLS transport. Message details, together with the behavior of CLUE Participants acting as Media Providers and/or Media Consumers, are herein discussed. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-clue-protocol/ There's also a htmlized version available at: https://tools.ietf.org/html/draft-ietf-clue-protocol-13 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-clue-protocol-13 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 Feb 23 03:41:38 2017 Return-Path: X-Original-To: clue@ietfa.amsl.com Delivered-To: clue@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BDD5412A133 for ; Thu, 23 Feb 2017 03:41:36 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-0.001, 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 pGlM5nWpCqrD for ; Thu, 23 Feb 2017 03:41:34 -0800 (PST) Received: from brc1.unina.it (antispam.unina.it [192.132.34.50]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id F2CD01296BD for ; Thu, 23 Feb 2017 03:41:33 -0800 (PST) X-ASG-Debug-ID: 1487850090-05ce370d1f4ed230001-dOUo1C Received: from smtp1.unina.it (smtp1.unina.it [192.132.34.61]) by brc1.unina.it with ESMTP id TLRYA5szzSBQbF5B (version=TLSv1 cipher=AES256-SHA bits=256 verify=NO); Thu, 23 Feb 2017 12:41:30 +0100 (CET) X-Barracuda-Envelope-From: spromano@unina.it X-Barracuda-Apparent-Source-IP: 192.132.34.61 Received: from [143.225.28.167] ([143.225.28.167]) (authenticated bits=0) by smtp1.unina.it (8.14.4/8.14.4) with ESMTP id v1NBfSDL007198 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 23 Feb 2017 12:41:29 +0100 Content-Type: multipart/alternative; boundary="Apple-Mail=_EC881E29-8B35-43B0-AD3A-D6D904AE45D5" Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) From: Simon Pietro Romano X-ASG-Orig-Subj: Re: [clue] WGLC for draft-ietf-clue-protocol-10 In-Reply-To: <5f5ddf96-41a9-9c55-c692-077791a04ec7@nteczone.com> Date: Thu, 23 Feb 2017 12:41:28 +0100 Message-Id: <0E687D17-2DFB-4A7A-AF1C-F7D68E06F931@unina.it> References: <075716a0-ab1d-f943-50d0-a65fd339f165@nteczone.com> <4B2480BA-75CA-4E73-A3D4-ABA3058EE6AD@unina.it> <8A070EF8-BEB7-4CA8-86C1-E10A25C91F04@unina.it> <5f5ddf96-41a9-9c55-c692-077791a04ec7@nteczone.com> To: Christian Groves X-Mailer: Apple Mail (2.3124) X-Barracuda-Connect: smtp1.unina.it[192.132.34.61] X-Barracuda-Start-Time: 1487850090 X-Barracuda-Encrypted: AES256-SHA X-Barracuda-URL: http://192.132.34.50:8000/cgi-mod/mark.cgi X-Virus-Scanned: by bsmtpd at unina.it X-Barracuda-BRTS-Status: 1 X-Barracuda-Spam-Score: 0.82 X-Barracuda-Spam-Status: No, SCORE=0.82 using global scores of TAG_LEVEL=1000.0 QUARANTINE_LEVEL=1000.0 KILL_LEVEL=6.0 tests=BSF_SC0_MISMATCH_TO, HTML_MESSAGE, MIME_QP_LONG_LINE, MIME_QP_LONG_LINE_2 X-Barracuda-Spam-Report: Code version 3.2, rules version 3.2.3.35465 Rule breakdown below pts rule name description ---- ---------------------- -------------------------------------------------- 0.00 BSF_SC0_MISMATCH_TO Envelope rcpt doesn't match header 0.00 HTML_MESSAGE BODY: HTML included in message 0.00 MIME_QP_LONG_LINE RAW: Quoted-printable line longer than 76 chars 0.82 MIME_QP_LONG_LINE_2 RAW: Quoted-printable line longer than 76 chars Archived-At: Cc: clue@ietf.org Subject: Re: [clue] WGLC for draft-ietf-clue-protocol-10 X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: CLUE - ControLling mUltiple streams for TElepresence List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 23 Feb 2017 11:41:37 -0000 --Apple-Mail=_EC881E29-8B35-43B0-AD3A-D6D904AE45D5 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Hello Christian, > [CNG] I agree with Paul in that any new response code will need to be = registered by IANA. However I don't see the problem with having two = mechanisms to define codes within the protocol. It should be possible to = add an error code to CLUE without having to bump the version. I think if = you delete "(by adding them to the related IANA registry)," and add a = sentence along the lines of: > "In both cases the new response code MUST be registered with IANA=E2=80=9D= . We followed your advice in version -13 of the draft.=20 Cheers, Simon _\\|//_ ( O-O ) ~~~~~~~~~~~~~~~~~~~~~~o00~~(_)~~00o~~~~~~~~~~~~~~~~~~~~~~~~ Simon Pietro Romano Universita' di Napoli Federico = II Computer Engineering Department=20 Phone: +39 081 7683823 -- Fax: +39 081 7683816 e-mail: spromano@unina.it = <>. = Magritte. oooO ~~~~~~~~~~~~~~~~~~~~~~~( )~~~ Oooo~~~~~~~~~~~~~~~~~~~~~~~~~ \ ( = ( ) \_) ) = / = (_/ > On 24 Jan 2017, at 06:08, Christian Groves = wrote: >=20 > Hello Simon and Roberta, >=20 > Thanks for addressing the comments. Please see below. >=20 > Regards, Christian >=20 > ..snip >>=20 >>>> Cl.5.7: It says future protocol version can introduce error codes? = How about options? It seems like an option could introduce a specific = error code. >>>> Based on the discussion in section 8, a new response code might = indeed be added through the =E2=80=9Cextension=E2=80=9D mechanism. = Though, the =E2=80=9Ccleanest=E2=80=9D way for achieving such a task in = a formal way is by adding >>>> the new response code to the list of codes published in the = dedicated IANA registry (see section 12.4.2 fo the draft). In the = mentioned section, we refer to future versions of the standard. >>> [CNG] By saying that error codes can be designed in future versions = seems to preclude them being defined by extensions. (BTW 5.7 uses = "designed", I think "defined" would be better). >>=20 >> We rephrased the sentence as follows: >>=20 >> "Further response codes can be either defined in future versions of = the >> protocol or defined >> by leveraging the extension mechanism. In any case, such new response >> codes MUST NOT overwrite the ones here defined and they MUST >> respect the semantics of the first code digit.=E2=80=9D >>=20 >> Does this sound OK to you? > [CNG] I agree with Paul in that any new response code will need to be = registered by IANA. However I don't see the problem with having two = mechanisms to define codes within the protocol. It should be possible to = add an error code to CLUE without having to bump the version. I think if = you delete "(by adding them to the related IANA registry)," and add a = sentence along the lines of: > "In both cases the new response code MUST be registered with IANA". >=20 >>=20 >>> I agree one could simply update the IANA registry with the new code = but I was thinking more of how an end point would know that it would be = used. That's where registering an extension would make sense. Of course = if you made a new version you wouldn't need an extension. >>=20 >> OK. See above. >>=20 >>> ..snip >>>> Cl.6 para 5: "Otherwise ("channel error")=E2=80=A6" >>>> Should we add an "if" between =E2=80=9COtherwise=E2=80=9D and the = parenthesis? Please advise on that. >>> [CNG] If doesn't need to be in parentheses just "Otherwise if =E2=80=A6= " >>=20 >> You=E2=80=99re the English master! We modified accordingly: >>=20 >> "Otherwise if ("channel error"), it moves back to the IDLE state.=E2=80= =9D > [CNG] You can delete the ( and ), i.e. just "Otherwise if "channel = error", it... " >>=20 >=20 >=20 --Apple-Mail=_EC881E29-8B35-43B0-AD3A-D6D904AE45D5 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 Hello Christian,

[CNG] I agree with Paul = in that any new response code will need to be registered by IANA. = However I don't see the problem with having two mechanisms to define = codes within the protocol. It should be possible to add an error code to = CLUE without having to bump the version. I think if you delete "(by = adding them to the related IANA registry)," and add a sentence along the = lines of:
"In both cases the new response code MUST be = registered with IANA=E2=80=9D.

We followed your advice in version -13 = of the draft. 

Cheers,

Simon


          =             =   _\\|//_
      =                     =   = ( O-O )
      = ~~~~~~~~~~~~~~~~~~~~~~o00~~(_)~~00o~~~~~~~~~~~~~~~~~~~~~~~~
  =                 =    = Simon Pietro Romano
    =            Universita' di = Napoli Federico II
        =               Computer Engineering = Department 
           =   Phone: +39 081 7683823 -- Fax: +39 081 7683816
                =                     =        e-mail: spromano@unina.it

    <<Molti mi = dicono che lo scoraggiamento =C3=A8 l'alibi degli 
=     idioti. Ci rifletto un istante; e mi = scoraggio>>. Magritte.
      =                 =                oooO
       ~~~~~~~~~~~~~~~~~~~~~~~( =   )~~~ Oooo~~~~~~~~~~~~~~~~~~~~~~~~~
=               =    \ (            (   = )
=               =                   =   \_)          ) /
                =                     =                     =               =  (_/



On 24 Jan 2017, at 06:08, Christian Groves <Christian.Groves@nteczone.com> wrote:

Hello = Simon and Roberta,

Thanks for addressing = the comments. Please see below.

Regards, = Christian

..snip

Cl.5.7: It says future = protocol version can introduce error codes? How about options? It seems = like an option could introduce a specific error code.
Based = on the discussion in section 8, a new response code might indeed be = added through the =E2=80=9Cextension=E2=80=9D mechanism. Though, the = =E2=80=9Ccleanest=E2=80=9D way for achieving such a task in a formal way = is by adding
the new response code to the list of codes = published in the dedicated IANA registry (see section 12.4.2 fo the = draft). In the mentioned section, we refer to future versions of the = standard.
[CNG] By saying that error codes = can be designed in future versions seems to preclude them being defined = by extensions. (BTW 5.7 uses "designed", I think "defined" would be = better).

We rephrased the = sentence as follows:

"Further response = codes can be either defined in future versions of the
protocol  or defined
by leveraging the = extension mechanism. In any case, such new response
codes = MUST NOT overwrite the ones here defined and they MUST
respect the semantics of the first code digit.=E2=80=9D

Does this sound OK to you?
[CNG] I agree with Paul in that any new response = code will need to be registered by IANA. However I don't see the problem = with having two mechanisms to define codes within the protocol. It = should be possible to add an error code to CLUE without having to bump = the version. I think if you delete "(by adding them to the related IANA = registry)," and add a sentence along the lines of:
"In = both cases the new response code MUST be registered with IANA".


I agree one could simply = update the IANA registry with the new code but I was thinking more of = how an end point would know that it would be used. That's where = registering an extension would make sense. Of course if you made a new = version you wouldn't need an extension.

OK. See above.

..snip
Cl.6 para 5: "Otherwise <if> ("channel error")=E2=80=A6"<= br class=3D"">Should we add an "if" between =E2=80=9COtherwise=E2=80=9D = and the parenthesis? Please advise on that.
[CNG] If doesn't need to be in parentheses just = "Otherwise if =E2=80=A6"

You=E2=80=99re the English master! We modified = accordingly:

"Otherwise if ("channel = error"), it moves back to the IDLE state.=E2=80=9D
[CNG] You can delete the ( and ), i.e. just = "Otherwise if "channel error", it... "




= --Apple-Mail=_EC881E29-8B35-43B0-AD3A-D6D904AE45D5-- From nobody Thu Feb 23 03:43:03 2017 Return-Path: X-Original-To: clue@ietfa.amsl.com Delivered-To: clue@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 97D7D129E53 for ; Thu, 23 Feb 2017 03:43:01 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-0.001, 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 s3ns62Z3ku9X for ; Thu, 23 Feb 2017 03:42:58 -0800 (PST) Received: from brc2.unina.it (brc2.unina.it [192.132.34.42]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 02D9A12A162 for ; Thu, 23 Feb 2017 03:42:58 -0800 (PST) X-ASG-Debug-ID: 1487850174-05f275541c419e20001-dOUo1C Received: from smtp2.unina.it (smtp2.unina.it [192.132.34.62]) by brc2.unina.it with ESMTP id ImPFVOG5HBlciKud (version=TLSv1 cipher=AES256-SHA bits=256 verify=NO); Thu, 23 Feb 2017 12:42:54 +0100 (CET) X-Barracuda-Envelope-From: spromano@unina.it X-Barracuda-Apparent-Source-IP: 192.132.34.62 Received: from [143.225.28.167] ([143.225.28.167]) (authenticated bits=0) by smtp2.unina.it (8.14.4/8.14.4) with ESMTP id v1NBgsre012598 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 23 Feb 2017 12:42:54 +0100 Content-Type: multipart/alternative; boundary="Apple-Mail=_E20380F0-76D2-438B-822E-348F5D9FAA7C" Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) From: Simon Pietro Romano X-ASG-Orig-Subj: Re: [clue] Mark's WGLC comments on protocol-10 In-Reply-To: Date: Thu, 23 Feb 2017 12:42:54 +0100 Message-Id: <970C5324-027B-463F-953B-879A7E99A0DB@unina.it> References: <54CC7438-AB52-45A5-A9B9-BB23525F9C07@unina.it> <1D301144-1CF5-4874-AB66-7223C867011F@unina.it> To: Mark Duckworth X-Mailer: Apple Mail (2.3124) X-Barracuda-Connect: smtp2.unina.it[192.132.34.62] X-Barracuda-Start-Time: 1487850174 X-Barracuda-Encrypted: AES256-SHA X-Barracuda-URL: http://192.132.34.42:8000/cgi-mod/mark.cgi X-Virus-Scanned: by bsmtpd at unina.it X-Barracuda-BRTS-Status: 1 X-Barracuda-Spam-Score: 0.00 X-Barracuda-Spam-Status: No, SCORE=0.00 using global scores of TAG_LEVEL=1000.0 QUARANTINE_LEVEL=1000.0 KILL_LEVEL=6.0 tests=BSF_SC0_MISMATCH_TO, HTML_MESSAGE, MAILTO_TO_SPAM_ADDR X-Barracuda-Spam-Report: Code version 3.2, rules version 3.2.3.36049 Rule breakdown below pts rule name description ---- ---------------------- -------------------------------------------------- 0.00 BSF_SC0_MISMATCH_TO Envelope rcpt doesn't match header 0.00 HTML_MESSAGE BODY: HTML included in message 0.00 MAILTO_TO_SPAM_ADDR Includes a link to a likely spammer email Archived-At: Cc: "clue@ietf.org" , Christian Groves Subject: Re: [clue] Mark's WGLC comments on protocol-10 X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: CLUE - ControLling mUltiple streams for TElepresence List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 23 Feb 2017 11:43:01 -0000 --Apple-Mail=_E20380F0-76D2-438B-822E-348F5D9FAA7C Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 Hello Mark, > That's fine with me, too. The clueId is now optional. Cheers, Simon _\\|//_ ( O-O ) ~~~~~~~~~~~~~~~~~~~~~~o00~~(_)~~00o~~~~~~~~~~~~~~~~~~~~~~~~ Simon Pietro Romano Universita' di Napoli Federico = II Computer Engineering Department=20 Phone: +39 081 7683823 -- Fax: +39 081 7683816 e-mail: spromano@unina.it = <>. = Magritte. oooO ~~~~~~~~~~~~~~~~~~~~~~~( )~~~ Oooo~~~~~~~~~~~~~~~~~~~~~~~~~ \ ( = ( ) \_) ) = / = (_/ > On 24 Jan 2017, at 17:36, Mark Duckworth = wrote: >=20 > That's fine with me, too. > Mark >=20 >=20 > -------- Original message -------- > From: Christian Groves >=20 > Date:01/24/2017 00:35 (GMT-05:00)=20 > To: clue@ietf.org =20 > Subject: Re: [clue] Mark's WGLC comments on protocol-10=20 >=20 > I'd vote for making it optional and providing some more text on what = the > information could actually be. >=20 > Regards, Christian >=20 >=20 > On 23/01/2017 8:00 PM, Simon Pietro Romano wrote: > > Hello Mark, > > > > please find in-line our answers to your comments. > > > >> About the clueId element - I guess my main point is I don't = understand what this is for or how to use it. As an implementer, I = wouldn't know what to do with it. As a sender, can I populate this field = with any random string? Can I send a different value for this element = for every message? If I send random values, or empty string, will it = cause a problem? As a receiver, what should I do with this element? Can = I safely ignore it? Should I check it for some type of validity, and = possibly send a nack if it is invalid? Is it permissible to display the = value to a human user? It seems to me the document isn't clear enough = about how to use this element, so my interpretation is that this clueId = element is useless because there are absolutely no rules about what to = do with it. It says the clueId is " > >> identifier (in the form of a > >> > >> generic string) of the CP within the telepresence system". But what = is the "identifier"? I don't think this is defined anywhere. > >> > >> If it is okay for an implementation to send an empty string for = clueId, and to ignore any value it receives, then can we add this = clarification to the document? If it is not okay, then can you please = add an explanation why, and what the additional rules are? > > In our view the clueId is similar to the =93confUserID=94 (and = related XCON-USERID) parameter we introduced in RFC6503 (CCMP) when = standardizing centralised conferencing. In that case, the specification = was much more detailed. The identifier was mentioned in the framework = (as well as in the protocol) and specified in the data model. In the = CLUE case we kept this more loose, since the only identifiers that are = mentioned in the framework document are those related to individual = encodings. As it is defined now, such an identifier can only have = application-specific semantics; yet, we believe it might be useful in a = number of different scenarios (we=92re clueIds in our prototype = telepresence architecture, for example). This said, we do not want this = to further delay the standardization process. We see two options here = (other than leaving things unchanged): > > > > i) we make the clueId optional (minOccurs=3D0) and leave the rest of = the document unchanged. In this way, those who want to rely on this = piece of information for their own implementations are allowed to do = that; > > ii) we remove the clueId from the specification. > > > > We=92d like to gather the feeling of the WG on this and are ready to = apply any of the proposed solutions. > > > > > >> About "Each CP MUST be able to manage up to three (independent) = streams of sequence numbers" - okay, now I understand you are talking = about the sending side only. But this statement still isn't strictly = correct, because a CP doesn't have to be both a mediaProvider and a = mediaConsumer, so it doesn't necessarily have to manage three streams. = How about this instead, to replace the current paragraph: > >> > >> "Each CP is responsible for creating and updating up to three = independent streams of sequence numbers in messages it sends: (i) one = for the messages sent in the initiation phase, (ii) one for the messages = sent as MP (if it is acting as a MP), and (iii) one for the messages = sent as MC (if it is acting as a MC).=94 > > Done. > > > > Thanks a lot, > > > > Simon & Roberta > > > >> Mark > >> From: clue > = on behalf of Simon Pietro Romano > > >> Sent: Monday, January 02, 2017 11:21 AM > >> To: Mark.Duckworth@polycom.com > >> Cc: clue@ietf.org > >> Subject: Re: [clue] Mark's WGLC comments on protocol-10 > >> =20 > >> Dear Mark, > >> > >> thanks a lot for your review. Please find in-line our answers. > >> > >> Cheers, > >> > >> Simon & Roberta > >> > >>> 4. "three main communication layers" - I agree with Christian = these are phases, not layers. > >> Fixed. > >> > >>> 5. clueId - it still isn't clear to me what is the use of this = element. It seems wasteful to include this element in every message. > >>> Simon previously said "In my view, it is just a name for the CP". = But what is it used for? Can we delete clueId if it has no purpose? > >>> Or if it has a purpose and is meant to be static, can we make it = part of the options message exchange rather than every message? And = explain what the purpose is? > >> If we just look at the CLUE protocol level dialogue, the clueId = provides a means for properly identifying the interacting parties. What = is wrong with this? > >> > >>> "Each CP MUST be able to manage up to three (independent) = streams of > >>> sequence numbers" - sounds to me like it is really six streams of = sequence numbers. Because each of the three "streams" described actually = has separate independent sequence numbers for each direction. > >>> - initiation phase send > >>> - initiation phase receive > >>> - MP send > >>> - MP receive > >>> - MC send > >>> - MC receive > >>> It also is misleading because it is not required to be both an MC = and an MP, so possibly only one of those applies. So it could be either = four streams of sequence numbers, or six streams. > >> Got it. When we say =93manage=94 we actually mean =93being = responsible for the creation and the update=94. So, we were looking at = the three roles mentioned above, but by focusing just on the =93sending=94= perspective. Would you like us to reword that sentence? > >> > >>> 5.2 "copied in the the" remove a =93the" > >> Done. > >> > >>> 5.3 "an MP may send new ADV messages to replace the previously = advertised options" - this could be misunderstood as relating to the = options messages in the initiation phase. How about "an MP may send new = ADV messages to replace the previous advertisement=94 > >> Done. > >> > >>> Christian wrote: "Cl.6.1&6.2: Do we need to indicate that the = timeout and retry relates to the transport (e.g. SCTP) rather than = application level timers/counters? I'm a bit confused about the = descriptions in the draft as we have a reliable transport" > >>> I thought the timeout and retry stuff was application level, not = to account for transport errors but rather to account for application = behavior such as an application not responding for whatever reason. So I = think it does need to be clarified if Christian and I interpreted it = differently. > >> This is inline with our interpretation. See also our answer to = Christian=92s point in the related e-mail. > >> > >> > >>> Christian wrote: "Cl.6.2 para 3: "If the ADV elaboration is = unsuccessful (bad syntax, missing XML elements, etc.), and the number of = times this has happened is under the retry treshold," I don't understand = why the retry threshold comes in here? Wouldn't the MC simply send a = NACK is there's an error. It wouldn't wait for multiple instances of the = erroneous message." > >>> My understanding is it gives the MP an opportunity to send a = different advertisement after it receives a nack. It doesn't have to = send another copy of the same advertisement. > >> Agreed. As per above, see also our answer to Christian=92s point in = the related e-mail. > >> > >>> 10.1 simple ADV - I suggest updating this to be consistent with = the sample XML file in the data model. We already fixed some problems = with that sample XML. I see problems, probably the same ones we already = fixed, here in the simple ADV example. For example captureID AC0 is a = video capture but the description says "main audio from the room". And = on page 36 sceneView SE3 and SE4 are the same, so that is a mistake. I = think we've done a good review of the XML in the data model, so let's = just use that as much as possible to avoid new mistakes in this = document. > >> Done. Thank you for pointing this out. > >> > >>> 10.2 - same comment, I suggest using the already reviewed XML = from the data model, and show it here in the protocol message envelope. > >> Done. > >> > >> > >>> =20 > >>> Mark > >>> _______________________________________________ > >>> clue mailing list > >>> clue@ietf.org > >>> https://www.ietf.org/mailman/listinfo/clue = > > _______________________________________________ > > clue mailing list > > clue@ietf.org > > https://www.ietf.org/mailman/listinfo/clue = > > >=20 > _______________________________________________ > clue mailing list > clue@ietf.org > https://www.ietf.org/mailman/listinfo/clue = > _______________________________________________ > clue mailing list > clue@ietf.org > https://www.ietf.org/mailman/listinfo/clue = --Apple-Mail=_E20380F0-76D2-438B-822E-348F5D9FAA7C Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=windows-1252 Hello Mark,

That's = fine with me, too.

The clueId is now optional.

Cheers,

Simon

          =             =   _\\|//_
      =                     =   = ( O-O )
      = ~~~~~~~~~~~~~~~~~~~~~~o00~~(_)~~00o~~~~~~~~~~~~~~~~~~~~~~~~
  =                 =    = Simon Pietro Romano
    =            Universita' di = Napoli Federico II
        =               Computer Engineering = Department 
           =   Phone: +39 081 7683823 -- Fax: +39 081 7683816
                =                     =        e-mail: spromano@unina.it

    <<Molti mi = dicono che lo scoraggiamento =E8 l'alibi degli 
=     idioti. Ci rifletto un istante; e mi = scoraggio>>. Magritte.
      =                 =                oooO
       ~~~~~~~~~~~~~~~~~~~~~~~( =   )~~~ Oooo~~~~~~~~~~~~~~~~~~~~~~~~~
=               =    \ (            (   = )
=               =                   =   \_)          ) /
                =                     =                     =               =  (_/



On 24 Jan 2017, at 17:36, Mark Duckworth <mrducky73@outlook.com> wrote:

That's fine with me, = too.
Mark


-------- = Original message --------
From: Christian Groves <Christian.Groves@nteczone.com> 
Date:01/24/2017 00:35 (GMT-05:00) 
To: clue@ietf.org 
Subject: Re: = [clue] Mark's WGLC comments on protocol-10 

I'd vote = for making it optional and providing some more text on what the
information could actually be.

Regards, Christian


On 23/01/2017 8:00 PM, Simon Pietro Romano wrote:
> Hello Mark,
>
> please = find in-line our answers to your comments.
>
>> About the clueId element - I guess my main point is = I don't understand what this is for or how to use it. As an implementer, = I wouldn't know what to do with it. As a sender, can I populate this = field with any random string? Can I send a different value for this = element for every message? If I send random values, or empty string, = will it cause a problem? As a receiver, what should I do with this = element? Can I safely ignore it? Should I check it for some type of = validity, and possibly send a nack if it is invalid? Is it permissible = to display the value to a human user? It seems to me the document isn't = clear enough about how to use this element, so my interpretation is that = this clueId element is useless because there are absolutely no rules = about what to do with it. It says the clueId is "
>> = identifier (in the form of a
>>
>>= generic string) of the CP within the telepresence system". But what is = the "identifier"? I don't think this is defined anywhere.
>>
>> If it is okay for an = implementation to send an empty string for clueId, and to ignore any = value it receives, then can we add this clarification to the document? = If it is not okay, then can you please add an explanation why, and what = the additional rules are?
> In our view the clueId is = similar to the =93confUserID=94 (and related XCON-USERID) parameter we = introduced in RFC6503 (CCMP) when standardizing centralised = conferencing. In that case, the specification was much more detailed. = The identifier was mentioned in the framework (as well as in the = protocol) and specified in the data model. In the CLUE case we kept this = more loose, since the only identifiers that are mentioned in the = framework document are those related to individual encodings. As it is = defined now, such an identifier can only have application-specific = semantics; yet, we believe it might be useful in a number of different = scenarios (we=92re clueIds in our prototype telepresence architecture, = for example). This said, we do not want this to further delay the = standardization process. We see two options here (other than leaving = things unchanged):
>
> i) we make the = clueId optional (minOccurs=3D0) and leave the rest of the document = unchanged. In this way, those who want to rely on this piece of = information for their own implementations are allowed to do that;
> ii) we remove the clueId from the specification.
>
> We=92d like to gather the feeling of = the WG on this and are ready to apply any of the proposed solutions.
>
>
>> About "Each CP = MUST be able to manage up to three (independent) streams of sequence = numbers" - okay, now I understand you are talking about the sending side = only. But this statement still isn't strictly correct, because a CP = doesn't have to be both a mediaProvider and a mediaConsumer, so it = doesn't necessarily have to manage three streams. How about this = instead, to replace the current paragraph:
>>
>> "Each CP is responsible for creating and updating up = to three independent streams of sequence numbers in messages it sends: = (i) one for the messages sent in the initiation phase, (ii) one for the = messages sent as MP (if it is acting as a MP), and (iii) one for the = messages sent as MC (if it is acting as a MC).=94
> = Done.
>
> Thanks a lot,
>
> Simon & Roberta
>
>> Mark
>> From: = clue <clue-bounces@ietf.org> on behalf of Simon Pietro = Romano <spromano@unina.it>
>> Sent: = Monday, January 02, 2017 11:21 AM
>> To: Mark.Duckworth@polycom.com
>> = Cc: clue@ietf.org
>> Subject: Re: [clue] Mark's WGLC comments on = protocol-10
>>   
>> = Dear Mark,
>>
>> thanks a lot = for your review. Please find in-line our answers.
>>
>> Cheers,
>>
>> Simon & Roberta
>>
>>> 4. "three main = communication layers" - I agree with Christian these are phases, not = layers.
>> Fixed.
>>
>>>   5. clueId - it still isn't clear to = me what is the use of this element. It seems wasteful to include this = element in every message.
>>> Simon previously = said "In my view, it is just a name for the CP". But what is it used = for? Can we delete clueId if it has no purpose?
>>>= Or if it has a purpose and is meant to be static, can we make it part = of the options message exchange rather than every message? And explain = what the purpose is?
>> If we just look at the CLUE = protocol level dialogue, the clueId provides a means for properly = identifying the interacting parties. What is wrong with this?
>>
>>>   "Each CP MUST = be able to manage up to three (independent) streams of
>>> sequence numbers" - sounds to me like it is = really six streams of sequence numbers. Because each of the three = "streams" described actually has separate independent sequence numbers = for each direction.
>>> - initiation phase = send
>>> - initiation phase receive
>>> - MP send
>>> - MP = receive
>>> - MC send
>>> = - MC receive
>>> It also is misleading because it = is not required to be both an MC and an MP, so possibly only one of = those applies. So it could be either four streams of sequence numbers, = or six streams.
>> Got it. When we say =93manage=94 = we actually mean =93being responsible for the creation and the update=94. = So, we were looking at the three roles mentioned above, but by focusing = just on the =93sending=94 perspective. Would you like us to reword that = sentence?
>>
>>>   = 5.2 "copied in the the" remove a =93the"
>> Done.
>>
>>>   5.3 "an MP = may send new ADV messages to replace the previously advertised options" = - this could be misunderstood as relating to the options messages in the = initiation phase. How about "an MP may send new ADV messages to replace = the previous advertisement=94
>> Done.
>>
>>>   Christian = wrote: "Cl.6.1&6.2: Do we need to indicate that the timeout and = retry relates to the transport (e.g. SCTP) rather than application level = timers/counters? I'm a bit confused about the descriptions in the draft = as we have a reliable transport"
>>> I thought = the timeout and retry stuff was application level, not to account for = transport errors but rather to account for application behavior such as = an application not responding for whatever reason. So I think it does = need to be clarified if Christian and I interpreted it differently.
>> This is inline with our interpretation. See also our = answer to Christian=92s point in the related e-mail.
>>
>>
>>>   Christian wrote: "Cl.6.2 para 3: "If = the ADV elaboration is unsuccessful (bad syntax, missing XML elements, = etc.), and the number of times this has happened is under the retry = treshold," I don't understand why the retry threshold comes in here? = Wouldn't the MC simply send a NACK is there's an error. It wouldn't wait = for multiple instances of the erroneous message."
>>> My understanding is it gives the MP an = opportunity to send a different advertisement after it receives a nack. = It doesn't have to send another copy of the same advertisement.
>> Agreed. As per above, see also our answer to = Christian=92s point in the related e-mail.
>>
>>> 10.1 simple ADV - I suggest updating this to be = consistent with the sample XML file in the data model. We already fixed = some problems with that sample XML. I see problems, probably the same = ones we already fixed, here in the simple ADV example. For example = captureID AC0 is a video capture but the description says "main audio = from the room". And on page 36 sceneView SE3 and SE4 are the same, so = that is a mistake. I think we've done a good review of the XML in the = data model, so let's just use that as much as possible to avoid new = mistakes in this document.
>> Done. Thank you for = pointing this out.
>>
>>>   10.2 - same comment, I suggest using = the already reviewed XML from the data model, and show it here in the = protocol message envelope.
>> Done.
>>
>>
>>>   
>>> = Mark
>>> = _______________________________________________
>>>= clue mailing list
>>> clue@ietf.org
>>> https://www.ietf.org/mailman/listinfo/clue
> _______________________________________________
> clue mailing list
> clue@ietf.org
> https://www.ietf.org/mailman/listinfo/clue
>

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

= --Apple-Mail=_E20380F0-76D2-438B-822E-348F5D9FAA7C-- From nobody Fri Feb 24 00:14:36 2017 Return-Path: X-Original-To: clue@ietfa.amsl.com Delivered-To: clue@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 75F00129545 for ; Fri, 24 Feb 2017 00:14:35 -0800 (PST) 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 7-G3nqINXIl3 for ; Fri, 24 Feb 2017 00:14:33 -0800 (PST) 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 53290129489 for ; Fri, 24 Feb 2017 00:14:33 -0800 (PST) X-AuditID: c1b4fb3a-b9bff700000021e0-b9-58afeb67dbf6 Received: from ESESSHC007.ericsson.se (Unknown_Domain [153.88.183.39]) by (Symantec Mail Security) with SMTP id 42.C8.08672.76BEFA85; Fri, 24 Feb 2017 09:14:31 +0100 (CET) Received: from [127.0.0.1] (153.88.183.153) by smtp.internal.ericsson.com (153.88.183.41) with Microsoft SMTP Server id 14.3.319.2; Fri, 24 Feb 2017 09:14:30 +0100 To: Roni Even , "clue@ietf.org" References: <148697819872.24905.9378282459902101772.idtracker@ietfa.amsl.com> <6E58094ECC8D8344914996DAD28F1CCD77374B@DGGEMM506-MBX.china.huawei.com> From: Magnus Westerlund Message-ID: <8d7ca9a1-b4de-8c3f-833e-c7119c1b7614@ericsson.com> Date: Fri, 24 Feb 2017 09:14:29 +0100 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.7.1 MIME-Version: 1.0 In-Reply-To: <6E58094ECC8D8344914996DAD28F1CCD77374B@DGGEMM506-MBX.china.huawei.com> Content-Type: text/plain; charset="UTF-8"; format=flowed Content-Transfer-Encoding: 8bit X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFlrFLMWRmVeSWpSXmKPExsUyM2K7um766/URBt8uqVvsP3WZ2eLTsfMs DkweLUfesnosWfKTKYApissmJTUnsyy1SN8ugSvjRuMupoIVyhWtJyewNzCuk+li5OSQEDCR OLS0ma2LkYtDSGAdo0RPYz8rhLOcUWLCmSOsIFXCAm4SJ56eYgGxRQRcJY4s2McOUTSdUWLy 3x6wIjYBC4mbPxrZQGxeAXuJps4DYHEWAVWJ39tWgDWLCsRI7O2/zwRRIyhxcuYTsDinQIjE pHUT2UFsZqA5i98chLLlJZq3zmYGsYUEtCUamjpYJzDyz0LSPgtJyywkLQsYmVcxihanFhfn phsZ6aUWZSYXF+fn6eWllmxiBIbgwS2/rXYwHnzueIhRgINRiYf3w491EUKsiWXFlbmHGCU4 mJVEeLufrY8Q4k1JrKxKLcqPLyrNSS0+xCjNwaIkzmu28n64kEB6YklqdmpqQWoRTJaJg1Oq gTE7wXT5R0+l4sP6V/5v2SzsEL44TulK9MkIOS5D5ZtHzxYuzNprUHuAl1Mmq/Rkbu/seaf8 m6eaTpxwMzMr+dzzHytn/WMxj2M9Yex749PFlR3Gx3idftamSc1OqTs7Zd2X5zHp6gKJxu8j VI9cE9QNsoh4Mvl8wiLZcPVVP7cJKz6XZZ9aFKLEUpyRaKjFXFScCADt53F6PQIAAA== Archived-At: Subject: Re: [clue] FW: I-D Action: draft-ietf-clue-rtp-mapping-13.txt X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: CLUE - ControLling mUltiple streams for TElepresence List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 24 Feb 2017 08:14:35 -0000 Hi, To be clear, yesterday's posting with remaining issues are applicable on this version. That is actually a shortcoming of RTCWeb Security architecture and there exists an tracked issue for it: https://github.com/rtcweb-wg/security-arch/issues/34 So, yes, I would really like to see the communication security section mandate encrypted RTCP. This due to the information included in RTCP about the application. The protection profile mandated does imply equal strength RTCP protection, but if one uses other profiles it might not be as clear cut. So a wording on protecting RTCP at same or similar protection strength to RTP I think is motivated. What I also think is missing in the new text is discussion of RTP header extension encryption, i.e. RFC 6904. I thought the conclusion on the capture ID is that there is no strong generation requirements to ensure they don't contain privacy sensitive information. And it definitely reveals what is happening in the application context to third parties. Thus, I think encrypting the RTP header extensions would be good practice in clue situations. I also reacted to the use of "untraceable" in this sentence: CLUE endpoint MUST generate short-term persistent RTCP CNAMES, as specified in [RFC7022], resulting in untraceable CNAME values. The point of them is that they are not long term persistent and thus can't be used for long term tracking of the user. Writing "untraceable" I would interpret as indicating a stronger user protection then what is actually provided. Cheers Magnus Den 2017-02-13 kl. 10:59, skrev Roni Even: > Hi, > This new version is submitted to address Magnus and Ben comments. > There is a new section Communication security that specifies normative security for CLUE media. > The security consideration is just considerations and added text about the CaptureID > There are also some editorial and nits changes > Roni > > > -----Original Message----- > From: clue [mailto:clue-bounces@ietf.org] On Behalf Of internet-drafts@ietf.org > Sent: יום ב 13 פברואר 2017 11:30 > To: i-d-announce@ietf.org > Cc: clue@ietf.org > Subject: [clue] I-D Action: draft-ietf-clue-rtp-mapping-13.txt > > > A New Internet-Draft is available from the on-line Internet-Drafts directories. > This draft is a work item of the ControLling mUltiple streams for tElepresence of the IETF. > > Title : Mapping RTP streams to CLUE Media Captures > Authors : Roni Even > Jonathan Lennox > Filename : draft-ietf-clue-rtp-mapping-13.txt > Pages : 14 > Date : 2017-02-13 > > Abstract: > This document describes how the Real Time transport Protocol (RTP) is > used in the context of the CLUE protocol (ControLling mUltiple > streams for tElepresence). It also describes the mechanisms and > recommended practice for mapping RTP media streams defined in Session > Description Protocol (SDP) to CLUE Media Captures and defines a new > RTP header extension (CaptureId). > > > The IETF datatracker status page for this draft is: > https://datatracker.ietf.org/doc/draft-ietf-clue-rtp-mapping/ > > There's also a htmlized version available at: > https://tools.ietf.org/html/draft-ietf-clue-rtp-mapping-13 > > A diff from the previous version is available at: > https://www.ietf.org/rfcdiff?url2=draft-ietf-clue-rtp-mapping-13 > > > 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/ > > _______________________________________________ > clue mailing list > clue@ietf.org > https://www.ietf.org/mailman/listinfo/clue > > _______________________________________________ > clue mailing list > clue@ietf.org > https://www.ietf.org/mailman/listinfo/clue > - -- Magnus Westerlund ---------------------------------------------------------------------- Services, Media and Network features, Ericsson Research EAB/TXM ---------------------------------------------------------------------- Ericsson AB | Phone +46 10 7148287 Färögatan 6 | Mobile +46 73 0949079 SE-164 80 Stockholm, Sweden | mailto: magnus.westerlund@ericsson.com ---------------------------------------------------------------------- From nobody Fri Feb 24 14:43:10 2017 Return-Path: X-Original-To: clue@ietfa.amsl.com Delivered-To: clue@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A0563129533 for ; Fri, 24 Feb 2017 14:43:09 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.202 X-Spam-Level: X-Spam-Status: No, score=-4.202 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.001, 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 ZqgozC3_KqP0 for ; Fri, 24 Feb 2017 14:43:07 -0800 (PST) Received: from alum-mailsec-scanner-3.mit.edu (alum-mailsec-scanner-3.mit.edu [18.7.68.14]) by ietfa.amsl.com (Postfix) with ESMTP id 9D83E129527 for ; Fri, 24 Feb 2017 14:43:07 -0800 (PST) X-AuditID: 1207440e-cb3ff7000000340b-19-58b0b6f86277 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-3.mit.edu (Symantec Messaging Gateway) with SMTP id 73.5E.13323.8F6B0B85; Fri, 24 Feb 2017 17:43:05 -0500 (EST) Received: from [192.168.1.110] (c-73-186-127-100.hsd1.ma.comcast.net [73.186.127.100]) (authenticated bits=0) (User authenticated as pkyzivat@ALUM.MIT.EDU) by outgoing-alum.mit.edu (8.13.8/8.12.4) with ESMTP id v1OMh2pW021604 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Fri, 24 Feb 2017 17:43:02 -0500 To: Roni Even , "clue@ietf.org" , Jonathan Lennox References: <148697819872.24905.9378282459902101772.idtracker@ietfa.amsl.com> <6E58094ECC8D8344914996DAD28F1CCD77374B@DGGEMM506-MBX.china.huawei.com> <8d7ca9a1-b4de-8c3f-833e-c7119c1b7614@ericsson.com> From: Paul Kyzivat Message-ID: Date: Fri, 24 Feb 2017 17:43:02 -0500 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:45.0) Gecko/20100101 Thunderbird/45.7.1 MIME-Version: 1.0 In-Reply-To: <8d7ca9a1-b4de-8c3f-833e-c7119c1b7614@ericsson.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFvrCIsWRmVeSWpSXmKPExsUixO6iqPtz24YIg4dTzSz2n7rMbLF/8Xlm i0vr7zFZfDp2nsWBxePX16tsHi1H3rJ6LFnyk8mj7dkd9gCWKC6blNSczLLUIn27BK6Mtwsq Cl4pVrQcnMbUwPhLqouRk0NCwERi3pmX7F2MXBxCAjuYJNZP6oJyrjNJrLi+jQmkSljATeLE 01MsILaIQIlE/5xDrBBFZxklOv9NBytiFjCTuLFlKSOIzSagJTHn0H+wBl4Be4lbdz6D1bAI qEo0LVnLBmKLCqRJPG38zgxRIyhxcuYToHoODk4BB4m7B6xgRs7b/JAZwpaXaN46m3kCI/8s JB2zkJTNQlK2gJF5FaNcYk5prm5uYmZOcWqybnFyYl5eapGusV5uZoleakrpJkZI4PLtYGxf L3OIUYCDUYmHN8FmQ4QQa2JZcWXuIUZJDiYlUd5Vc4BCfEn5KZUZicUZ8UWlOanFhxglOJiV RHg1lwPleFMSK6tSi/JhUtIcLErivGpL1P2EBNITS1KzU1MLUotgsjIcHEoSvJbACBUSLEpN T61Iy8wpQUgzcXCCDOcBGn5uK8jw4oLE3OLMdIj8KUZFKXHelyAJAZBERmkeXC8ssbxiFAd6 RZj3C0gVDzApwXW/AhrMBDTY0nktyOCSRISUVAOjXsnGU//Zp+Z7utyxecDCGqF18o28KbuZ xpU4Vvk4Db0Vb0q6Zv87bhEzZ/luvlNblf0XN7VHNVVMXCUkEsSxdPqt9e5ero8yFr03viNx 9OO6E/UNzt+PXJdlVw1Ymrdnd9jUZcks8vtOMVuvy91/npX3SUDIvbLP0bLFntkd55qyI8/s 2VmmxFKckWioxVxUnAgAnPyo6gcDAAA= Archived-At: Subject: Re: [clue] FW: I-D Action: draft-ietf-clue-rtp-mapping-13.txt X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: CLUE - ControLling mUltiple streams for TElepresence List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 24 Feb 2017 22:43:09 -0000 Roni, Jonathan, Are you able to change in a way that will satisfy Magnus? Thanks, Paul On 2/24/17 3:14 AM, Magnus Westerlund wrote: > Hi, > > To be clear, yesterday's posting with remaining issues are applicable on > this version. > > That is actually a shortcoming of RTCWeb Security architecture and there > exists an tracked issue for it: > > https://github.com/rtcweb-wg/security-arch/issues/34 > > So, yes, I would really like to see the communication security section > mandate encrypted RTCP. This due to the information included in RTCP > about the application. The protection profile mandated does imply equal > strength RTCP protection, but if one uses other profiles it might not be > as clear cut. So a wording on protecting RTCP at same or similar > protection strength to RTP I think is motivated. > > What I also think is missing in the new text is discussion of RTP header > extension encryption, i.e. RFC 6904. I thought the conclusion on the > capture ID is that there is no strong generation requirements to ensure > they don't contain privacy sensitive information. And it definitely > reveals what is happening in the application context to third parties. > Thus, I think encrypting the RTP header extensions would be good > practice in clue situations. > > I also reacted to the use of "untraceable" in this sentence: > > CLUE endpoint MUST generate short-term persistent RTCP CNAMES, as > specified in [RFC7022], resulting in untraceable CNAME values. > > The point of them is that they are not long term persistent and thus > can't be used for long term tracking of the user. Writing "untraceable" > I would interpret as indicating a stronger user protection then what is > actually provided. > > Cheers > > Magnus > > Den 2017-02-13 kl. 10:59, skrev Roni Even: >> Hi, >> This new version is submitted to address Magnus and Ben comments. >> There is a new section Communication security that specifies normative >> security for CLUE media. >> The security consideration is just considerations and added text about >> the CaptureID >> There are also some editorial and nits changes >> Roni >> >> >> -----Original Message----- >> From: clue [mailto:clue-bounces@ietf.org] On Behalf Of >> internet-drafts@ietf.org >> Sent: יום ב 13 פברואר 2017 11:30 >> To: i-d-announce@ietf.org >> Cc: clue@ietf.org >> Subject: [clue] I-D Action: draft-ietf-clue-rtp-mapping-13.txt >> >> >> A New Internet-Draft is available from the on-line Internet-Drafts >> directories. >> This draft is a work item of the ControLling mUltiple streams for >> tElepresence of the IETF. >> >> Title : Mapping RTP streams to CLUE Media Captures >> Authors : Roni Even >> Jonathan Lennox >> Filename : draft-ietf-clue-rtp-mapping-13.txt >> Pages : 14 >> Date : 2017-02-13 >> >> Abstract: >> This document describes how the Real Time transport Protocol (RTP) is >> used in the context of the CLUE protocol (ControLling mUltiple >> streams for tElepresence). It also describes the mechanisms and >> recommended practice for mapping RTP media streams defined in Session >> Description Protocol (SDP) to CLUE Media Captures and defines a new >> RTP header extension (CaptureId). >> >> >> The IETF datatracker status page for this draft is: >> https://datatracker.ietf.org/doc/draft-ietf-clue-rtp-mapping/ >> >> There's also a htmlized version available at: >> https://tools.ietf.org/html/draft-ietf-clue-rtp-mapping-13 >> >> A diff from the previous version is available at: >> https://www.ietf.org/rfcdiff?url2=draft-ietf-clue-rtp-mapping-13 >> >> >> 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/ >> >> _______________________________________________ >> clue mailing list >> clue@ietf.org >> https://www.ietf.org/mailman/listinfo/clue >> >> _______________________________________________ >> clue mailing list >> clue@ietf.org >> https://www.ietf.org/mailman/listinfo/clue >> > - > From nobody Sat Feb 25 23:13:21 2017 Return-Path: X-Original-To: clue@ietfa.amsl.com Delivered-To: clue@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 42EDD129535 for ; Sat, 25 Feb 2017 23:13:19 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.222 X-Spam-Level: X-Spam-Status: No, score=-4.222 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, RP_MATCHES_RCVD=-0.001, 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 bUFaWkJu3OhF for ; Sat, 25 Feb 2017 23:13:17 -0800 (PST) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C1DFA12950F for ; Sat, 25 Feb 2017 23:13:16 -0800 (PST) Received: from 172.18.7.190 (EHLO lhreml702-cah.china.huawei.com) ([172.18.7.190]) by lhrrg02-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id DBS48619; Sun, 26 Feb 2017 07:13:14 +0000 (GMT) Received: from DGGEMM406-HUB.china.huawei.com (10.3.20.214) by lhreml702-cah.china.huawei.com (10.201.108.43) with Microsoft SMTP Server (TLS) id 14.3.301.0; Sun, 26 Feb 2017 07:13:13 +0000 Received: from DGGEMM506-MBX.china.huawei.com ([169.254.3.117]) by DGGEMM406-HUB.china.huawei.com ([10.3.20.214]) with mapi id 14.03.0301.000; Sun, 26 Feb 2017 15:13:05 +0800 From: Roni Even To: Magnus Westerlund , "clue@ietf.org" Thread-Topic: [clue] FW: I-D Action: draft-ietf-clue-rtp-mapping-13.txt Thread-Index: AQHSjnYLI5E0p0FPFkOsfZCUnmoPx6F64E5w Date: Sun, 26 Feb 2017 07:13:04 +0000 Message-ID: <6E58094ECC8D8344914996DAD28F1CCD776942@DGGEMM506-MBX.china.huawei.com> References: <148697819872.24905.9378282459902101772.idtracker@ietfa.amsl.com> <6E58094ECC8D8344914996DAD28F1CCD77374B@DGGEMM506-MBX.china.huawei.com> <8d7ca9a1-b4de-8c3f-833e-c7119c1b7614@ericsson.com> In-Reply-To: <8d7ca9a1-b4de-8c3f-833e-c7119c1b7614@ericsson.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.200.201.150] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-CFilter-Loop: Reflected X-Mirapoint-Virus-RAPID-Raw: score=unknown(0), refid=str=0001.0A090201.58B2800A.0081, ss=1, re=0.000, recu=0.000, reip=0.000, cl=1, cld=1, fgs=0, ip=169.254.3.117, so=2013-06-18 04:22:30, dmn=2013-03-21 17:37:32 X-Mirapoint-Loop-Id: 890cbe386ddaebc04e8765caff1669ab Archived-At: Subject: Re: [clue] FW: I-D Action: draft-ietf-clue-rtp-mapping-13.txt X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: CLUE - ControLling mUltiple streams for TElepresence List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 26 Feb 2017 07:13:19 -0000 SEkgTWFnbnVzLA0KVGhhbmtzLA0KDQpUaGUgc2VjdXJpdHkgY29uc2lkZXJhdGlvbiB3aGVuIGRp c2N1c3NpbmcgY2FwdHVyZUlEIHJlZmVyZW5jZXMgUkZDNzk0MSB3aGVyZSBpdCBzYXlzOg0KDQoi SW4gUlRQIHNlc3Npb25zIHdoZXJlIGFueSB0eXBlIG9mIGNvbmZpZGVudGlhbGl0eSBwcm90ZWN0 aW9uIGlzDQogICBlbmFibGVkIGZvciBSVENQLCB0aGUgU0RFUyBpdGVtIGhlYWRlciBleHRlbnNp b25zIE1VU1QgYWxzbyBiZQ0KICAgcHJvdGVjdGVkLiAgVGhpcyBpbXBsaWVzIHRoYXQgdG8gcHJv dmlkZSBjb25maWRlbnRpYWxpdHksIHVzZXJzIG9mDQogICB0aGUgU2VjdXJlIFJlYWwtdGltZSBU cmFuc3BvcnQgUHJvdG9jb2wgKFNSVFApIG5lZWQgdG8gaW1wbGVtZW50IGFuZA0KICAgdXNlIGVu Y3J5cHRlZCBoZWFkZXIgZXh0ZW5zaW9ucyBwZXIgW1JGQzY5MDRdLiAgIg0KIA0Kc28gc2luY2Ug d2UgbWFuZGF0ZSBSVENQIGNvbmZpZGVudGlhbGl0eSB0aGUgUlRQIGhlYWRlciBleHRlbnNpb24g TVVTVCBhbHNvIGJlIGVuY3J5cHRlZC4NCg0KQXMgZm9yIHRoZSBub24tdHJhY2VhYmxlIEkgd2ls bCBjaGFuZ2UgdG8gDQoNCiJDTFVFIGVuZHBvaW50IE1VU1QgZ2VuZXJhdGUgc2hvcnQtdGVybSBw ZXJzaXN0ZW50IFJUQ1AgQ05BTUVTLCBhcw0KICAgIHNwZWNpZmllZCBpbiBbUkZDNzAyMl0sIGFu ZCB0aHVzIGNhbid0IGJlIHVzZWQgZm9yIGxvbmcgdGVybSB0cmFja2luZyBvZiB0aGUgdXNlci4i DQoNCkFueSBvdGhlciBvcGVuIGlzc3VlPyBJIHdvdWxkIGxpa2UgdG8gc3VibWl0IHdoYXQgd291 bGQgbWF5YmUgYmUgdGhlIGZpbmFsIHZlcnNpb24NClJvbmkNCg0KDQoNCg0KPiAtLS0tLU9yaWdp bmFsIE1lc3NhZ2UtLS0tLQ0KPiBGcm9tOiBNYWdudXMgV2VzdGVybHVuZCBbbWFpbHRvOm1hZ251 cy53ZXN0ZXJsdW5kQGVyaWNzc29uLmNvbV0NCj4gU2VudDog15nXldedwqDXlSAyNCDXpNeR16jX ldeQ16ggMjAxNyAxMDoxNA0KPiBUbzogUm9uaSBFdmVuOyBjbHVlQGlldGYub3JnDQo+IFN1Ympl Y3Q6IFJlOiBbY2x1ZV0gRlc6IEktRCBBY3Rpb246IGRyYWZ0LWlldGYtY2x1ZS1ydHAtbWFwcGlu Zy0xMy50eHQNCj4gDQo+IEhpLA0KPiANCj4gVG8gYmUgY2xlYXIsIHllc3RlcmRheSdzIHBvc3Rp bmcgd2l0aCByZW1haW5pbmcgaXNzdWVzIGFyZSBhcHBsaWNhYmxlIG9uIHRoaXMNCj4gdmVyc2lv bi4NCj4gDQo+IFRoYXQgaXMgYWN0dWFsbHkgYSBzaG9ydGNvbWluZyBvZiBSVENXZWIgU2VjdXJp dHkgYXJjaGl0ZWN0dXJlIGFuZCB0aGVyZQ0KPiBleGlzdHMgYW4gdHJhY2tlZCBpc3N1ZSBmb3Ig aXQ6DQo+IA0KPiBodHRwczovL2dpdGh1Yi5jb20vcnRjd2ViLXdnL3NlY3VyaXR5LWFyY2gvaXNz dWVzLzM0DQo+IA0KPiBTbywgeWVzLCBJIHdvdWxkIHJlYWxseSBsaWtlIHRvIHNlZSB0aGUgY29t bXVuaWNhdGlvbiBzZWN1cml0eSBzZWN0aW9uDQo+IG1hbmRhdGUgZW5jcnlwdGVkIFJUQ1AuIFRo aXMgZHVlIHRvIHRoZSBpbmZvcm1hdGlvbiBpbmNsdWRlZCBpbiBSVENQIGFib3V0DQo+IHRoZSBh cHBsaWNhdGlvbi4gVGhlIHByb3RlY3Rpb24gcHJvZmlsZSBtYW5kYXRlZCBkb2VzIGltcGx5IGVx dWFsIHN0cmVuZ3RoDQo+IFJUQ1AgcHJvdGVjdGlvbiwgYnV0IGlmIG9uZSB1c2VzIG90aGVyIHBy b2ZpbGVzIGl0IG1pZ2h0IG5vdCBiZSBhcyBjbGVhciBjdXQuIFNvDQo+IGEgd29yZGluZyBvbiBw cm90ZWN0aW5nIFJUQ1AgYXQgc2FtZSBvciBzaW1pbGFyIHByb3RlY3Rpb24gc3RyZW5ndGggdG8g UlRQIEkNCj4gdGhpbmsgaXMgbW90aXZhdGVkLg0KPiANCj4gV2hhdCBJIGFsc28gdGhpbmsgaXMg bWlzc2luZyBpbiB0aGUgbmV3IHRleHQgaXMgZGlzY3Vzc2lvbiBvZiBSVFAgaGVhZGVyDQo+IGV4 dGVuc2lvbiBlbmNyeXB0aW9uLCBpLmUuIFJGQyA2OTA0LiBJIHRob3VnaHQgdGhlIGNvbmNsdXNp b24gb24gdGhlIGNhcHR1cmUNCj4gSUQgaXMgdGhhdCB0aGVyZSBpcyBubyBzdHJvbmcgZ2VuZXJh dGlvbiByZXF1aXJlbWVudHMgdG8gZW5zdXJlIHRoZXkgZG9uJ3QNCj4gY29udGFpbiBwcml2YWN5 IHNlbnNpdGl2ZSBpbmZvcm1hdGlvbi4gQW5kIGl0IGRlZmluaXRlbHkgcmV2ZWFscyB3aGF0IGlz DQo+IGhhcHBlbmluZyBpbiB0aGUgYXBwbGljYXRpb24gY29udGV4dCB0byB0aGlyZCBwYXJ0aWVz Lg0KPiBUaHVzLCBJIHRoaW5rIGVuY3J5cHRpbmcgdGhlIFJUUCBoZWFkZXIgZXh0ZW5zaW9ucyB3 b3VsZCBiZSBnb29kIHByYWN0aWNlIGluDQo+IGNsdWUgc2l0dWF0aW9ucy4NCj4gDQo+IEkgYWxz byByZWFjdGVkIHRvIHRoZSB1c2Ugb2YgInVudHJhY2VhYmxlIiBpbiB0aGlzIHNlbnRlbmNlOg0K PiANCj4gQ0xVRSBlbmRwb2ludCBNVVNUIGdlbmVyYXRlIHNob3J0LXRlcm0gcGVyc2lzdGVudCBS VENQIENOQU1FUywgYXMNCj4gICAgIHNwZWNpZmllZCBpbiBbUkZDNzAyMl0sIHJlc3VsdGluZyBp biB1bnRyYWNlYWJsZSBDTkFNRSB2YWx1ZXMuDQo+IA0KPiBUaGUgcG9pbnQgb2YgdGhlbSBpcyB0 aGF0IHRoZXkgYXJlIG5vdCBsb25nIHRlcm0gcGVyc2lzdGVudCBhbmQgdGh1cyBjYW4ndCBiZQ0K PiB1c2VkIGZvciBsb25nIHRlcm0gdHJhY2tpbmcgb2YgdGhlIHVzZXIuIFdyaXRpbmcgInVudHJh Y2VhYmxlIg0KPiBJIHdvdWxkIGludGVycHJldCBhcyBpbmRpY2F0aW5nIGEgc3Ryb25nZXIgdXNl ciBwcm90ZWN0aW9uIHRoZW4gd2hhdCBpcyBhY3R1YWxseQ0KPiBwcm92aWRlZC4NCj4gDQo+IENo ZWVycw0KPiANCj4gTWFnbnVzDQo+IA0KPiBEZW4gMjAxNy0wMi0xMyBrbC4gMTA6NTksIHNrcmV2 IFJvbmkgRXZlbjoNCj4gPiBIaSwNCj4gPiBUaGlzIG5ldyB2ZXJzaW9uIGlzIHN1Ym1pdHRlZCB0 byBhZGRyZXNzIE1hZ251cyBhbmQgQmVuIGNvbW1lbnRzLg0KPiA+IFRoZXJlIGlzIGEgbmV3IHNl Y3Rpb24gQ29tbXVuaWNhdGlvbiBzZWN1cml0eSB0aGF0IHNwZWNpZmllcyBub3JtYXRpdmUNCj4g c2VjdXJpdHkgZm9yIENMVUUgbWVkaWEuDQo+ID4gVGhlIHNlY3VyaXR5IGNvbnNpZGVyYXRpb24g aXMganVzdCBjb25zaWRlcmF0aW9ucyBhbmQgYWRkZWQgdGV4dCBhYm91dA0KPiA+IHRoZSBDYXB0 dXJlSUQgVGhlcmUgYXJlIGFsc28gc29tZSBlZGl0b3JpYWwgYW5kIG5pdHMgY2hhbmdlcyBSb25p DQo+ID4NCj4gPg0KPiA+IC0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQo+ID4gRnJvbTogY2x1 ZSBbbWFpbHRvOmNsdWUtYm91bmNlc0BpZXRmLm9yZ10gT24gQmVoYWxmIE9mDQo+ID4gaW50ZXJu ZXQtZHJhZnRzQGlldGYub3JnDQo+ID4gU2VudDog15nXldedINeRIDEzINek15HXqNeV15DXqCAy MDE3IDExOjMwDQo+ID4gVG86IGktZC1hbm5vdW5jZUBpZXRmLm9yZw0KPiA+IENjOiBjbHVlQGll dGYub3JnDQo+ID4gU3ViamVjdDogW2NsdWVdIEktRCBBY3Rpb246IGRyYWZ0LWlldGYtY2x1ZS1y dHAtbWFwcGluZy0xMy50eHQNCj4gPg0KPiA+DQo+ID4gQSBOZXcgSW50ZXJuZXQtRHJhZnQgaXMg YXZhaWxhYmxlIGZyb20gdGhlIG9uLWxpbmUgSW50ZXJuZXQtRHJhZnRzDQo+IGRpcmVjdG9yaWVz Lg0KPiA+IFRoaXMgZHJhZnQgaXMgYSB3b3JrIGl0ZW0gb2YgdGhlIENvbnRyb0xsaW5nIG1VbHRp cGxlIHN0cmVhbXMgZm9yDQo+IHRFbGVwcmVzZW5jZSBvZiB0aGUgSUVURi4NCj4gPg0KPiA+ICAg ICAgICAgVGl0bGUgICAgICAgICAgIDogTWFwcGluZyBSVFAgc3RyZWFtcyB0byBDTFVFIE1lZGlh IENhcHR1cmVzDQo+ID4gICAgICAgICBBdXRob3JzICAgICAgICAgOiBSb25pIEV2ZW4NCj4gPiAg ICAgICAgICAgICAgICAgICAgICAgICAgIEpvbmF0aGFuIExlbm5veA0KPiA+IAlGaWxlbmFtZSAg ICAgICAgOiBkcmFmdC1pZXRmLWNsdWUtcnRwLW1hcHBpbmctMTMudHh0DQo+ID4gCVBhZ2VzICAg ICAgICAgICA6IDE0DQo+ID4gCURhdGUgICAgICAgICAgICA6IDIwMTctMDItMTMNCj4gPg0KPiA+ IEFic3RyYWN0Og0KPiA+ICAgIFRoaXMgZG9jdW1lbnQgZGVzY3JpYmVzIGhvdyB0aGUgUmVhbCBU aW1lIHRyYW5zcG9ydCBQcm90b2NvbCAoUlRQKSBpcw0KPiA+ICAgIHVzZWQgaW4gdGhlIGNvbnRl eHQgb2YgdGhlIENMVUUgcHJvdG9jb2wgKENvbnRyb0xsaW5nIG1VbHRpcGxlDQo+ID4gICAgc3Ry ZWFtcyBmb3IgdEVsZXByZXNlbmNlKS4gIEl0IGFsc28gZGVzY3JpYmVzIHRoZSBtZWNoYW5pc21z IGFuZA0KPiA+ICAgIHJlY29tbWVuZGVkIHByYWN0aWNlIGZvciBtYXBwaW5nIFJUUCBtZWRpYSBz dHJlYW1zIGRlZmluZWQgaW4NCj4gU2Vzc2lvbg0KPiA+ICAgIERlc2NyaXB0aW9uIFByb3RvY29s IChTRFApIHRvIENMVUUgTWVkaWEgQ2FwdHVyZXMgYW5kIGRlZmluZXMgYSBuZXcNCj4gPiAgICBS VFAgaGVhZGVyIGV4dGVuc2lvbiAoQ2FwdHVyZUlkKS4NCj4gPg0KPiA+DQo+ID4gVGhlIElFVEYg ZGF0YXRyYWNrZXIgc3RhdHVzIHBhZ2UgZm9yIHRoaXMgZHJhZnQgaXM6DQo+ID4gaHR0cHM6Ly9k YXRhdHJhY2tlci5pZXRmLm9yZy9kb2MvZHJhZnQtaWV0Zi1jbHVlLXJ0cC1tYXBwaW5nLw0KPiA+ DQo+ID4gVGhlcmUncyBhbHNvIGEgaHRtbGl6ZWQgdmVyc2lvbiBhdmFpbGFibGUgYXQ6DQo+ID4g aHR0cHM6Ly90b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0LWlldGYtY2x1ZS1ydHAtbWFwcGluZy0x Mw0KPiA+DQo+ID4gQSBkaWZmIGZyb20gdGhlIHByZXZpb3VzIHZlcnNpb24gaXMgYXZhaWxhYmxl IGF0Og0KPiA+IGh0dHBzOi8vd3d3LmlldGYub3JnL3JmY2RpZmY/dXJsMj1kcmFmdC1pZXRmLWNs dWUtcnRwLW1hcHBpbmctMTMNCj4gPg0KPiA+DQo+ID4gUGxlYXNlIG5vdGUgdGhhdCBpdCBtYXkg dGFrZSBhIGNvdXBsZSBvZiBtaW51dGVzIGZyb20gdGhlIHRpbWUgb2YNCj4gc3VibWlzc2lvbiB1 bnRpbCB0aGUgaHRtbGl6ZWQgdmVyc2lvbiBhbmQgZGlmZiBhcmUgYXZhaWxhYmxlIGF0IHRvb2xz LmlldGYub3JnLg0KPiA+DQo+ID4gSW50ZXJuZXQtRHJhZnRzIGFyZSBhbHNvIGF2YWlsYWJsZSBi eSBhbm9ueW1vdXMgRlRQIGF0Og0KPiA+IGZ0cDovL2Z0cC5pZXRmLm9yZy9pbnRlcm5ldC1kcmFm dHMvDQo+ID4NCj4gPiBfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fXw0KPiA+IGNsdWUgbWFpbGluZyBsaXN0DQo+ID4gY2x1ZUBpZXRmLm9yZw0KPiA+IGh0dHBz Oi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vY2x1ZQ0KPiA+DQo+ID4gX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCj4gPiBjbHVlIG1haWxpbmcg bGlzdA0KPiA+IGNsdWVAaWV0Zi5vcmcNCj4gPiBodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFu L2xpc3RpbmZvL2NsdWUNCj4gPg0KPiAtDQo+IA0KPiAtLQ0KPiANCj4gTWFnbnVzIFdlc3Rlcmx1 bmQNCj4gDQo+IC0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0NCj4gU2VydmljZXMsIE1lZGlhIGFuZCBOZXR3b3JrIGZl YXR1cmVzLCBFcmljc3NvbiBSZXNlYXJjaCBFQUIvVFhNDQo+IC0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0NCj4gRXJp Y3Nzb24gQUIgICAgICAgICAgICAgICAgIHwgUGhvbmUgICs0NiAxMCA3MTQ4Mjg3DQo+IEbDpHLD tmdhdGFuIDYgICAgICAgICAgICAgICAgIHwgTW9iaWxlICs0NiA3MyAwOTQ5MDc5DQo+IFNFLTE2 NCA4MCBTdG9ja2hvbG0sIFN3ZWRlbiB8IG1haWx0bzogbWFnbnVzLndlc3Rlcmx1bmRAZXJpY3Nz b24uY29tDQo+IC0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0NCg0K From nobody Sat Feb 25 23:14:13 2017 Return-Path: X-Original-To: clue@ietfa.amsl.com Delivered-To: clue@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3812E129535 for ; Sat, 25 Feb 2017 23:14:12 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.222 X-Spam-Level: X-Spam-Status: No, score=-4.222 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, RP_MATCHES_RCVD=-0.001, 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 dbHN2r3kPP9T for ; Sat, 25 Feb 2017 23:14:11 -0800 (PST) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9A76612950F for ; Sat, 25 Feb 2017 23:14:10 -0800 (PST) Received: from 172.18.7.190 (EHLO lhreml709-cah.china.huawei.com) ([172.18.7.190]) by lhrrg01-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id DHT81488; Sun, 26 Feb 2017 07:14:06 +0000 (GMT) Received: from DGGEMM403-HUB.china.huawei.com (10.3.20.211) by lhreml709-cah.china.huawei.com (10.201.108.32) with Microsoft SMTP Server (TLS) id 14.3.301.0; Sun, 26 Feb 2017 07:14:06 +0000 Received: from DGGEMM506-MBX.china.huawei.com ([169.254.3.117]) by DGGEMM403-HUB.china.huawei.com ([10.3.20.211]) with mapi id 14.03.0301.000; Sun, 26 Feb 2017 15:13:58 +0800 From: Roni Even To: Paul Kyzivat , "clue@ietf.org" , Jonathan Lennox Thread-Topic: [clue] FW: I-D Action: draft-ietf-clue-rtp-mapping-13.txt Thread-Index: AQHSjnYLI5E0p0FPFkOsfZCUnmoPx6F4O60AgAKnCsA= Date: Sun, 26 Feb 2017 07:13:57 +0000 Message-ID: <6E58094ECC8D8344914996DAD28F1CCD776953@DGGEMM506-MBX.china.huawei.com> References: <148697819872.24905.9378282459902101772.idtracker@ietfa.amsl.com> <6E58094ECC8D8344914996DAD28F1CCD77374B@DGGEMM506-MBX.china.huawei.com> <8d7ca9a1-b4de-8c3f-833e-c7119c1b7614@ericsson.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.200.201.150] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-CFilter-Loop: Reflected X-Mirapoint-Virus-RAPID-Raw: score=unknown(0), refid=str=0001.0A020206.58B2803F.0129, ss=1, re=0.000, recu=0.000, reip=0.000, cl=1, cld=1, fgs=0, ip=169.254.3.117, so=2013-06-18 04:22:30, dmn=2013-03-21 17:37:32 X-Mirapoint-Loop-Id: 07475f4d78ae535fe712d2b5fe26cdaa Archived-At: Subject: Re: [clue] FW: I-D Action: draft-ietf-clue-rtp-mapping-13.txt X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: CLUE - ControLling mUltiple streams for TElepresence List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 26 Feb 2017 07:14:12 -0000 SGkgUGF1bCwNCkkgaG9wZSB3ZSB3aWxsIGJlIGRvbmUgQVNBUA0KUm9uaQ0KDQo+IC0tLS0tT3Jp Z2luYWwgTWVzc2FnZS0tLS0tDQo+IEZyb206IFBhdWwgS3l6aXZhdCBbbWFpbHRvOnBreXppdmF0 QGFsdW0ubWl0LmVkdV0NCj4gU2VudDog16nXkdeqIDI1INek15HXqNeV15DXqCAyMDE3IDAwOjQz DQo+IFRvOiBSb25pIEV2ZW47IGNsdWVAaWV0Zi5vcmc7IEpvbmF0aGFuIExlbm5veA0KPiBDYzog TWFnbnVzIFdlc3Rlcmx1bmQNCj4gU3ViamVjdDogUmU6IFtjbHVlXSBGVzogSS1EIEFjdGlvbjog ZHJhZnQtaWV0Zi1jbHVlLXJ0cC1tYXBwaW5nLTEzLnR4dA0KPiANCj4gUm9uaSwgSm9uYXRoYW4s DQo+IA0KPiBBcmUgeW91IGFibGUgdG8gY2hhbmdlIGluIGEgd2F5IHRoYXQgd2lsbCBzYXRpc2Z5 IE1hZ251cz8NCj4gDQo+IAlUaGFua3MsDQo+IAlQYXVsDQo+IA0KPiBPbiAyLzI0LzE3IDM6MTQg QU0sIE1hZ251cyBXZXN0ZXJsdW5kIHdyb3RlOg0KPiA+IEhpLA0KPiA+DQo+ID4gVG8gYmUgY2xl YXIsIHllc3RlcmRheSdzIHBvc3Rpbmcgd2l0aCByZW1haW5pbmcgaXNzdWVzIGFyZSBhcHBsaWNh YmxlDQo+ID4gb24gdGhpcyB2ZXJzaW9uLg0KPiA+DQo+ID4gVGhhdCBpcyBhY3R1YWxseSBhIHNo b3J0Y29taW5nIG9mIFJUQ1dlYiBTZWN1cml0eSBhcmNoaXRlY3R1cmUgYW5kDQo+ID4gdGhlcmUg ZXhpc3RzIGFuIHRyYWNrZWQgaXNzdWUgZm9yIGl0Og0KPiA+DQo+ID4gaHR0cHM6Ly9naXRodWIu Y29tL3J0Y3dlYi13Zy9zZWN1cml0eS1hcmNoL2lzc3Vlcy8zNA0KPiA+DQo+ID4gU28sIHllcywg SSB3b3VsZCByZWFsbHkgbGlrZSB0byBzZWUgdGhlIGNvbW11bmljYXRpb24gc2VjdXJpdHkgc2Vj dGlvbg0KPiA+IG1hbmRhdGUgZW5jcnlwdGVkIFJUQ1AuIFRoaXMgZHVlIHRvIHRoZSBpbmZvcm1h dGlvbiBpbmNsdWRlZCBpbiBSVENQDQo+ID4gYWJvdXQgdGhlIGFwcGxpY2F0aW9uLiBUaGUgcHJv dGVjdGlvbiBwcm9maWxlIG1hbmRhdGVkIGRvZXMgaW1wbHkNCj4gPiBlcXVhbCBzdHJlbmd0aCBS VENQIHByb3RlY3Rpb24sIGJ1dCBpZiBvbmUgdXNlcyBvdGhlciBwcm9maWxlcyBpdA0KPiA+IG1p Z2h0IG5vdCBiZSBhcyBjbGVhciBjdXQuIFNvIGEgd29yZGluZyBvbiBwcm90ZWN0aW5nIFJUQ1Ag YXQgc2FtZSBvcg0KPiA+IHNpbWlsYXIgcHJvdGVjdGlvbiBzdHJlbmd0aCB0byBSVFAgSSB0aGlu ayBpcyBtb3RpdmF0ZWQuDQo+ID4NCj4gPiBXaGF0IEkgYWxzbyB0aGluayBpcyBtaXNzaW5nIGlu IHRoZSBuZXcgdGV4dCBpcyBkaXNjdXNzaW9uIG9mIFJUUA0KPiA+IGhlYWRlciBleHRlbnNpb24g ZW5jcnlwdGlvbiwgaS5lLiBSRkMgNjkwNC4gSSB0aG91Z2h0IHRoZSBjb25jbHVzaW9uDQo+ID4g b24gdGhlIGNhcHR1cmUgSUQgaXMgdGhhdCB0aGVyZSBpcyBubyBzdHJvbmcgZ2VuZXJhdGlvbiBy ZXF1aXJlbWVudHMNCj4gPiB0byBlbnN1cmUgdGhleSBkb24ndCBjb250YWluIHByaXZhY3kgc2Vu c2l0aXZlIGluZm9ybWF0aW9uLiBBbmQgaXQNCj4gPiBkZWZpbml0ZWx5IHJldmVhbHMgd2hhdCBp cyBoYXBwZW5pbmcgaW4gdGhlIGFwcGxpY2F0aW9uIGNvbnRleHQgdG8gdGhpcmQNCj4gcGFydGll cy4NCj4gPiBUaHVzLCBJIHRoaW5rIGVuY3J5cHRpbmcgdGhlIFJUUCBoZWFkZXIgZXh0ZW5zaW9u cyB3b3VsZCBiZSBnb29kDQo+ID4gcHJhY3RpY2UgaW4gY2x1ZSBzaXR1YXRpb25zLg0KPiA+DQo+ ID4gSSBhbHNvIHJlYWN0ZWQgdG8gdGhlIHVzZSBvZiAidW50cmFjZWFibGUiIGluIHRoaXMgc2Vu dGVuY2U6DQo+ID4NCj4gPiBDTFVFIGVuZHBvaW50IE1VU1QgZ2VuZXJhdGUgc2hvcnQtdGVybSBw ZXJzaXN0ZW50IFJUQ1AgQ05BTUVTLCBhcw0KPiA+ICAgIHNwZWNpZmllZCBpbiBbUkZDNzAyMl0s IHJlc3VsdGluZyBpbiB1bnRyYWNlYWJsZSBDTkFNRSB2YWx1ZXMuDQo+ID4NCj4gPiBUaGUgcG9p bnQgb2YgdGhlbSBpcyB0aGF0IHRoZXkgYXJlIG5vdCBsb25nIHRlcm0gcGVyc2lzdGVudCBhbmQg dGh1cw0KPiA+IGNhbid0IGJlIHVzZWQgZm9yIGxvbmcgdGVybSB0cmFja2luZyBvZiB0aGUgdXNl ci4gV3JpdGluZyAidW50cmFjZWFibGUiDQo+ID4gSSB3b3VsZCBpbnRlcnByZXQgYXMgaW5kaWNh dGluZyBhIHN0cm9uZ2VyIHVzZXIgcHJvdGVjdGlvbiB0aGVuIHdoYXQNCj4gPiBpcyBhY3R1YWxs eSBwcm92aWRlZC4NCj4gPg0KPiA+IENoZWVycw0KPiA+DQo+ID4gTWFnbnVzDQo+ID4NCj4gPiBE ZW4gMjAxNy0wMi0xMyBrbC4gMTA6NTksIHNrcmV2IFJvbmkgRXZlbjoNCj4gPj4gSGksDQo+ID4+ IFRoaXMgbmV3IHZlcnNpb24gaXMgc3VibWl0dGVkIHRvIGFkZHJlc3MgTWFnbnVzIGFuZCBCZW4g Y29tbWVudHMuDQo+ID4+IFRoZXJlIGlzIGEgbmV3IHNlY3Rpb24gQ29tbXVuaWNhdGlvbiBzZWN1 cml0eSB0aGF0IHNwZWNpZmllcw0KPiA+PiBub3JtYXRpdmUgc2VjdXJpdHkgZm9yIENMVUUgbWVk aWEuDQo+ID4+IFRoZSBzZWN1cml0eSBjb25zaWRlcmF0aW9uIGlzIGp1c3QgY29uc2lkZXJhdGlv bnMgYW5kIGFkZGVkIHRleHQNCj4gPj4gYWJvdXQgdGhlIENhcHR1cmVJRCBUaGVyZSBhcmUgYWxz byBzb21lIGVkaXRvcmlhbCBhbmQgbml0cyBjaGFuZ2VzDQo+ID4+IFJvbmkNCj4gPj4NCj4gPj4N Cj4gPj4gLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCj4gPj4gRnJvbTogY2x1ZSBbbWFpbHRv OmNsdWUtYm91bmNlc0BpZXRmLm9yZ10gT24gQmVoYWxmIE9mDQo+ID4+IGludGVybmV0LWRyYWZ0 c0BpZXRmLm9yZw0KPiA+PiBTZW50OiDXmdeV150g15EgMTMg16TXkdeo15XXkNeoIDIwMTcgMTE6 MzANCj4gPj4gVG86IGktZC1hbm5vdW5jZUBpZXRmLm9yZw0KPiA+PiBDYzogY2x1ZUBpZXRmLm9y Zw0KPiA+PiBTdWJqZWN0OiBbY2x1ZV0gSS1EIEFjdGlvbjogZHJhZnQtaWV0Zi1jbHVlLXJ0cC1t YXBwaW5nLTEzLnR4dA0KPiA+Pg0KPiA+Pg0KPiA+PiBBIE5ldyBJbnRlcm5ldC1EcmFmdCBpcyBh dmFpbGFibGUgZnJvbSB0aGUgb24tbGluZSBJbnRlcm5ldC1EcmFmdHMNCj4gPj4gZGlyZWN0b3Jp ZXMuDQo+ID4+IFRoaXMgZHJhZnQgaXMgYSB3b3JrIGl0ZW0gb2YgdGhlIENvbnRyb0xsaW5nIG1V bHRpcGxlIHN0cmVhbXMgZm9yDQo+ID4+IHRFbGVwcmVzZW5jZSBvZiB0aGUgSUVURi4NCj4gPj4N Cj4gPj4gICAgICAgICBUaXRsZSAgICAgICAgICAgOiBNYXBwaW5nIFJUUCBzdHJlYW1zIHRvIENM VUUgTWVkaWEgQ2FwdHVyZXMNCj4gPj4gICAgICAgICBBdXRob3JzICAgICAgICAgOiBSb25pIEV2 ZW4NCj4gPj4gICAgICAgICAgICAgICAgICAgICAgICAgICBKb25hdGhhbiBMZW5ub3gNCj4gPj4g ICAgIEZpbGVuYW1lICAgICAgICA6IGRyYWZ0LWlldGYtY2x1ZS1ydHAtbWFwcGluZy0xMy50eHQN Cj4gPj4gICAgIFBhZ2VzICAgICAgICAgICA6IDE0DQo+ID4+ICAgICBEYXRlICAgICAgICAgICAg OiAyMDE3LTAyLTEzDQo+ID4+DQo+ID4+IEFic3RyYWN0Og0KPiA+PiAgICBUaGlzIGRvY3VtZW50 IGRlc2NyaWJlcyBob3cgdGhlIFJlYWwgVGltZSB0cmFuc3BvcnQgUHJvdG9jb2wgKFJUUCkgaXMN Cj4gPj4gICAgdXNlZCBpbiB0aGUgY29udGV4dCBvZiB0aGUgQ0xVRSBwcm90b2NvbCAoQ29udHJv TGxpbmcgbVVsdGlwbGUNCj4gPj4gICAgc3RyZWFtcyBmb3IgdEVsZXByZXNlbmNlKS4gIEl0IGFs c28gZGVzY3JpYmVzIHRoZSBtZWNoYW5pc21zIGFuZA0KPiA+PiAgICByZWNvbW1lbmRlZCBwcmFj dGljZSBmb3IgbWFwcGluZyBSVFAgbWVkaWEgc3RyZWFtcyBkZWZpbmVkIGluDQo+IFNlc3Npb24N Cj4gPj4gICAgRGVzY3JpcHRpb24gUHJvdG9jb2wgKFNEUCkgdG8gQ0xVRSBNZWRpYSBDYXB0dXJl cyBhbmQgZGVmaW5lcyBhIG5ldw0KPiA+PiAgICBSVFAgaGVhZGVyIGV4dGVuc2lvbiAoQ2FwdHVy ZUlkKS4NCj4gPj4NCj4gPj4NCj4gPj4gVGhlIElFVEYgZGF0YXRyYWNrZXIgc3RhdHVzIHBhZ2Ug Zm9yIHRoaXMgZHJhZnQgaXM6DQo+ID4+IGh0dHBzOi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcvZG9j L2RyYWZ0LWlldGYtY2x1ZS1ydHAtbWFwcGluZy8NCj4gPj4NCj4gPj4gVGhlcmUncyBhbHNvIGEg aHRtbGl6ZWQgdmVyc2lvbiBhdmFpbGFibGUgYXQ6DQo+ID4+IGh0dHBzOi8vdG9vbHMuaWV0Zi5v cmcvaHRtbC9kcmFmdC1pZXRmLWNsdWUtcnRwLW1hcHBpbmctMTMNCj4gPj4NCj4gPj4gQSBkaWZm IGZyb20gdGhlIHByZXZpb3VzIHZlcnNpb24gaXMgYXZhaWxhYmxlIGF0Og0KPiA+PiBodHRwczov L3d3dy5pZXRmLm9yZy9yZmNkaWZmP3VybDI9ZHJhZnQtaWV0Zi1jbHVlLXJ0cC1tYXBwaW5nLTEz DQo+ID4+DQo+ID4+DQo+ID4+IFBsZWFzZSBub3RlIHRoYXQgaXQgbWF5IHRha2UgYSBjb3VwbGUg b2YgbWludXRlcyBmcm9tIHRoZSB0aW1lIG9mDQo+ID4+IHN1Ym1pc3Npb24gdW50aWwgdGhlIGh0 bWxpemVkIHZlcnNpb24gYW5kIGRpZmYgYXJlIGF2YWlsYWJsZSBhdA0KPiA+PiB0b29scy5pZXRm Lm9yZy4NCj4gPj4NCj4gPj4gSW50ZXJuZXQtRHJhZnRzIGFyZSBhbHNvIGF2YWlsYWJsZSBieSBh bm9ueW1vdXMgRlRQIGF0Og0KPiA+PiBmdHA6Ly9mdHAuaWV0Zi5vcmcvaW50ZXJuZXQtZHJhZnRz Lw0KPiA+Pg0KPiA+PiBfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fXw0KPiA+PiBjbHVlIG1haWxpbmcgbGlzdA0KPiA+PiBjbHVlQGlldGYub3JnDQo+ID4+IGh0 dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vY2x1ZQ0KPiA+Pg0KPiA+PiBfX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KPiA+PiBjbHVlIG1h aWxpbmcgbGlzdA0KPiA+PiBjbHVlQGlldGYub3JnDQo+ID4+IGh0dHBzOi8vd3d3LmlldGYub3Jn L21haWxtYW4vbGlzdGluZm8vY2x1ZQ0KPiA+Pg0KPiA+IC0NCj4gPg0KDQo= From nobody Mon Feb 27 06:15:03 2017 Return-Path: X-Original-To: clue@ietfa.amsl.com Delivered-To: clue@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C318D129FC8 for ; Mon, 27 Feb 2017 06:15:01 -0800 (PST) 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 w62yp_pkWApm for ; Mon, 27 Feb 2017 06:15:00 -0800 (PST) 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 4572F1298C3 for ; Mon, 27 Feb 2017 06:14:59 -0800 (PST) X-AuditID: c1b4fb3a-ae2b298000007c1e-7e-58b43461bd85 Received: from ESESSHC017.ericsson.se (Unknown_Domain [153.88.183.69]) by (Symantec Mail Security) with SMTP id 58.0D.31774.16434B85; Mon, 27 Feb 2017 15:14:57 +0100 (CET) Received: from [127.0.0.1] (153.88.183.153) by smtp.internal.ericsson.com (153.88.183.71) with Microsoft SMTP Server id 14.3.319.2; Mon, 27 Feb 2017 15:14:10 +0100 To: Roni Even , "clue@ietf.org" References: <148697819872.24905.9378282459902101772.idtracker@ietfa.amsl.com> <6E58094ECC8D8344914996DAD28F1CCD77374B@DGGEMM506-MBX.china.huawei.com> <8d7ca9a1-b4de-8c3f-833e-c7119c1b7614@ericsson.com> <6E58094ECC8D8344914996DAD28F1CCD776942@DGGEMM506-MBX.china.huawei.com> From: Magnus Westerlund Message-ID: <4ef3844c-f726-2747-51cf-e077bc1ef547@ericsson.com> Date: Mon, 27 Feb 2017 15:14:10 +0100 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.7.1 MIME-Version: 1.0 In-Reply-To: <6E58094ECC8D8344914996DAD28F1CCD776942@DGGEMM506-MBX.china.huawei.com> Content-Type: text/plain; charset="utf-8"; format=flowed Content-Transfer-Encoding: 8bit X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFlrFLMWRmVeSWpSXmKPExsUyM2K7q26iyZYIg7vfTSz2n7rMbPHp2HkW ByaPliNvWT2WLPnJFMAUxWWTkpqTWZZapG+XwJVx6t9W1oJZghX9166wNTA+5e1i5OSQEDCR +HR4O3sXIxeHkMA6RonnR9awQjjLGSU+f9vMDFIlLOAmceLpKRYQW0TAVeLIgn1QHdOZJL5s Og6WYBOwkLj5o5ENxOYVsJeYOOExO4jNIqAq8bh3HtggUYEYib3995kgagQlTs58AtbLKRAi sfDYdLA4M9CcmfPPM0LY8hLNW2eD9QoJaEs0NHWwTmDkn4WkfRaSlllIWhYwMq9iFC1OLS7O TTcy0kstykwuLs7P08tLLdnECAzBg1t+W+1gPPjc8RCjAAejEg/vh9jNEUKsiWXFlbmHGCU4 mJVEeL9qb4kQ4k1JrKxKLcqPLyrNSS0+xCjNwaIkzmu28n64kEB6YklqdmpqQWoRTJaJg1Oq gXH1/j1f17csvac0k88n8tlqh4O3D4uL/JJ4Y/2SRXiCWau1h1Oaueoh5o1ya+b9EPMRzO/q C4vb9X5a8kwHwds3E+Y/tFpvW/RQOzBT81Zi5wLDrgkywvuPqmsyGD65kHr5rZPH0UvbBbj+ bny+VO5wOsvWEznhlbZupppvL3w8qGzkKtH15a0SS3FGoqEWc1FxIgCz3B+RPQIAAA== Archived-At: Subject: Re: [clue] FW: I-D Action: draft-ietf-clue-rtp-mapping-13.txt X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: CLUE - ControLling mUltiple streams for TElepresence List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 27 Feb 2017 14:15:02 -0000 Den 2017-02-26 kl. 08:13, skrev Roni Even: > HI Magnus, Thanks, > > The security consideration when discussing captureID references > RFC7941 where it says: > > "In RTP sessions where any type of confidentiality protection is > enabled for RTCP, the SDES item header extensions MUST also be > protected. This implies that to provide confidentiality, users of > the Secure Real-time Transport Protocol (SRTP) need to implement and > use encrypted header extensions per [RFC6904]. " > > so since we mandate RTCP confidentiality the RTP header extension > MUST also be encrypted. Yes, but I think it would be much clearer to have the implementation requirement written out in Section 7. I would expand this paragraph: All CLUE implementations MUST implement DTLS 1.0, with the cipher suite TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA with the the P-256 curve [FIPS186]. The DTLS-SRTP protection profile SRTP_AES128_CM_HMAC_SHA1_80 MUST be supported for SRTP. to say: All CLUE implementations MUST implement DTLS 1.0, with the cipher suite TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA with the the P-256 curve [FIPS186]. The DTLS-SRTP protection profile SRTP_AES128_CM_HMAC_SHA1_80 MUST be supported for SRTP. Encrypted SRTP Header extensions [RFC6904] MUST be supported. > > As for the non-traceable I will change to > > "CLUE endpoint MUST generate short-term persistent RTCP CNAMES, as > specified in [RFC7022], and thus can't be used for long term tracking > of the user." Sounds good. > > Any other open issue? I would like to submit what would maybe be the > final version Roni > > Not to my knowledge. I think this is done. Thanks Magnus Westerlund ---------------------------------------------------------------------- Services, Media and Network features, Ericsson Research EAB/TXM ---------------------------------------------------------------------- Ericsson AB | Phone +46 10 7148287 Färögatan 6 | Mobile +46 73 0949079 SE-164 80 Stockholm, Sweden | mailto: magnus.westerlund@ericsson.com ---------------------------------------------------------------------- From nobody Mon Feb 27 07:07:56 2017 Return-Path: X-Original-To: clue@ietf.org Delivered-To: clue@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 94CDC12A029; Mon, 27 Feb 2017 07:07:55 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: X-Test-IDTracker: no X-IETF-IDTracker: 6.46.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <148820807560.21157.236059762151302518.idtracker@ietfa.amsl.com> Date: Mon, 27 Feb 2017 07:07:55 -0800 Archived-At: Cc: clue@ietf.org Subject: [clue] I-D Action: draft-ietf-clue-rtp-mapping-14.txt X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.17 List-Id: CLUE - ControLling mUltiple streams for TElepresence List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 27 Feb 2017 15:07:55 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the ControLling mUltiple streams for tElepresence of the IETF. Title : Mapping RTP streams to CLUE Media Captures Authors : Roni Even Jonathan Lennox Filename : draft-ietf-clue-rtp-mapping-14.txt Pages : 14 Date : 2017-02-27 Abstract: This document describes how the Real Time transport Protocol (RTP) is used in the context of the CLUE protocol (ControLling mUltiple streams for tElepresence). It also describes the mechanisms and recommended practice for mapping RTP media streams defined in Session Description Protocol (SDP) to CLUE Media Captures and defines a new RTP header extension (CaptureId). The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-clue-rtp-mapping/ There's also a htmlized version available at: https://tools.ietf.org/html/draft-ietf-clue-rtp-mapping-14 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-clue-rtp-mapping-14 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 Mon Feb 27 07:10:03 2017 Return-Path: X-Original-To: clue@ietfa.amsl.com Delivered-To: clue@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 05BCD12A0C6 for ; Mon, 27 Feb 2017 07:10:02 -0800 (PST) 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, RP_MATCHES_RCVD=-0.001, 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 m0pDHCEG_VTC for ; Mon, 27 Feb 2017 07:09:59 -0800 (PST) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1F20C129D13 for ; Mon, 27 Feb 2017 07:09:58 -0800 (PST) Received: from 172.18.7.190 (EHLO LHREML711-CAH.china.huawei.com) ([172.18.7.190]) by lhrrg01-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id DHV84581; Mon, 27 Feb 2017 15:09:55 +0000 (GMT) Received: from DGGEMM406-HUB.china.huawei.com (10.3.20.214) by LHREML711-CAH.china.huawei.com (10.201.108.34) with Microsoft SMTP Server (TLS) id 14.3.301.0; Mon, 27 Feb 2017 15:09:54 +0000 Received: from DGGEMM506-MBX.china.huawei.com ([169.254.3.117]) by DGGEMM406-HUB.china.huawei.com ([10.3.20.214]) with mapi id 14.03.0301.000; Mon, 27 Feb 2017 23:09:39 +0800 From: Roni Even To: Paul Kyzivat , "clue@ietf.org" , Jonathan Lennox Thread-Topic: [clue] FW: I-D Action: draft-ietf-clue-rtp-mapping-13.txt Thread-Index: AQHSjnYLI5E0p0FPFkOsfZCUnmoPx6F4O60AgAS+PTA= Date: Mon, 27 Feb 2017 15:09:38 +0000 Message-ID: <6E58094ECC8D8344914996DAD28F1CCD776CF8@DGGEMM506-MBX.china.huawei.com> References: <148697819872.24905.9378282459902101772.idtracker@ietfa.amsl.com> <6E58094ECC8D8344914996DAD28F1CCD77374B@DGGEMM506-MBX.china.huawei.com> <8d7ca9a1-b4de-8c3f-833e-c7119c1b7614@ericsson.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.200.201.150] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-CFilter-Loop: Reflected X-Mirapoint-Virus-RAPID-Raw: score=unknown(0), refid=str=0001.0A020202.58B44144.0129, ss=1, re=0.000, recu=0.000, reip=0.000, cl=1, cld=1, fgs=0, ip=169.254.3.117, so=2013-06-18 04:22:30, dmn=2013-03-21 17:37:32 X-Mirapoint-Loop-Id: 07475f4d78ae535fe712d2b5fe26cdaa Archived-At: Subject: Re: [clue] FW: I-D Action: draft-ietf-clue-rtp-mapping-13.txt X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: CLUE - ControLling mUltiple streams for TElepresence List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 27 Feb 2017 15:10:02 -0000 SGkgUGF1bCwNCkp1c3Qgc3VibWl0dGVkIC0xNCB0aGF0IEkgdGhpbmsgYWRkcmVzc2VzIE1hZ251 cyBjb25jZXJucw0KUm9uaQ0KDQo+IC0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQo+IEZyb206 IFBhdWwgS3l6aXZhdCBbbWFpbHRvOnBreXppdmF0QGFsdW0ubWl0LmVkdV0NCj4gU2VudDog16nX kdeqIDI1INek15HXqNeV15DXqCAyMDE3IDAwOjQzDQo+IFRvOiBSb25pIEV2ZW47IGNsdWVAaWV0 Zi5vcmc7IEpvbmF0aGFuIExlbm5veA0KPiBDYzogTWFnbnVzIFdlc3Rlcmx1bmQNCj4gU3ViamVj dDogUmU6IFtjbHVlXSBGVzogSS1EIEFjdGlvbjogZHJhZnQtaWV0Zi1jbHVlLXJ0cC1tYXBwaW5n LTEzLnR4dA0KPiANCj4gUm9uaSwgSm9uYXRoYW4sDQo+IA0KPiBBcmUgeW91IGFibGUgdG8gY2hh bmdlIGluIGEgd2F5IHRoYXQgd2lsbCBzYXRpc2Z5IE1hZ251cz8NCj4gDQo+IAlUaGFua3MsDQo+ IAlQYXVsDQo+IA0KPiBPbiAyLzI0LzE3IDM6MTQgQU0sIE1hZ251cyBXZXN0ZXJsdW5kIHdyb3Rl Og0KPiA+IEhpLA0KPiA+DQo+ID4gVG8gYmUgY2xlYXIsIHllc3RlcmRheSdzIHBvc3Rpbmcgd2l0 aCByZW1haW5pbmcgaXNzdWVzIGFyZSBhcHBsaWNhYmxlDQo+ID4gb24gdGhpcyB2ZXJzaW9uLg0K PiA+DQo+ID4gVGhhdCBpcyBhY3R1YWxseSBhIHNob3J0Y29taW5nIG9mIFJUQ1dlYiBTZWN1cml0 eSBhcmNoaXRlY3R1cmUgYW5kDQo+ID4gdGhlcmUgZXhpc3RzIGFuIHRyYWNrZWQgaXNzdWUgZm9y IGl0Og0KPiA+DQo+ID4gaHR0cHM6Ly9naXRodWIuY29tL3J0Y3dlYi13Zy9zZWN1cml0eS1hcmNo L2lzc3Vlcy8zNA0KPiA+DQo+ID4gU28sIHllcywgSSB3b3VsZCByZWFsbHkgbGlrZSB0byBzZWUg dGhlIGNvbW11bmljYXRpb24gc2VjdXJpdHkgc2VjdGlvbg0KPiA+IG1hbmRhdGUgZW5jcnlwdGVk IFJUQ1AuIFRoaXMgZHVlIHRvIHRoZSBpbmZvcm1hdGlvbiBpbmNsdWRlZCBpbiBSVENQDQo+ID4g YWJvdXQgdGhlIGFwcGxpY2F0aW9uLiBUaGUgcHJvdGVjdGlvbiBwcm9maWxlIG1hbmRhdGVkIGRv ZXMgaW1wbHkNCj4gPiBlcXVhbCBzdHJlbmd0aCBSVENQIHByb3RlY3Rpb24sIGJ1dCBpZiBvbmUg dXNlcyBvdGhlciBwcm9maWxlcyBpdA0KPiA+IG1pZ2h0IG5vdCBiZSBhcyBjbGVhciBjdXQuIFNv IGEgd29yZGluZyBvbiBwcm90ZWN0aW5nIFJUQ1AgYXQgc2FtZSBvcg0KPiA+IHNpbWlsYXIgcHJv dGVjdGlvbiBzdHJlbmd0aCB0byBSVFAgSSB0aGluayBpcyBtb3RpdmF0ZWQuDQo+ID4NCj4gPiBX aGF0IEkgYWxzbyB0aGluayBpcyBtaXNzaW5nIGluIHRoZSBuZXcgdGV4dCBpcyBkaXNjdXNzaW9u IG9mIFJUUA0KPiA+IGhlYWRlciBleHRlbnNpb24gZW5jcnlwdGlvbiwgaS5lLiBSRkMgNjkwNC4g SSB0aG91Z2h0IHRoZSBjb25jbHVzaW9uDQo+ID4gb24gdGhlIGNhcHR1cmUgSUQgaXMgdGhhdCB0 aGVyZSBpcyBubyBzdHJvbmcgZ2VuZXJhdGlvbiByZXF1aXJlbWVudHMNCj4gPiB0byBlbnN1cmUg dGhleSBkb24ndCBjb250YWluIHByaXZhY3kgc2Vuc2l0aXZlIGluZm9ybWF0aW9uLiBBbmQgaXQN Cj4gPiBkZWZpbml0ZWx5IHJldmVhbHMgd2hhdCBpcyBoYXBwZW5pbmcgaW4gdGhlIGFwcGxpY2F0 aW9uIGNvbnRleHQgdG8gdGhpcmQNCj4gcGFydGllcy4NCj4gPiBUaHVzLCBJIHRoaW5rIGVuY3J5 cHRpbmcgdGhlIFJUUCBoZWFkZXIgZXh0ZW5zaW9ucyB3b3VsZCBiZSBnb29kDQo+ID4gcHJhY3Rp Y2UgaW4gY2x1ZSBzaXR1YXRpb25zLg0KPiA+DQo+ID4gSSBhbHNvIHJlYWN0ZWQgdG8gdGhlIHVz ZSBvZiAidW50cmFjZWFibGUiIGluIHRoaXMgc2VudGVuY2U6DQo+ID4NCj4gPiBDTFVFIGVuZHBv aW50IE1VU1QgZ2VuZXJhdGUgc2hvcnQtdGVybSBwZXJzaXN0ZW50IFJUQ1AgQ05BTUVTLCBhcw0K PiA+ICAgIHNwZWNpZmllZCBpbiBbUkZDNzAyMl0sIHJlc3VsdGluZyBpbiB1bnRyYWNlYWJsZSBD TkFNRSB2YWx1ZXMuDQo+ID4NCj4gPiBUaGUgcG9pbnQgb2YgdGhlbSBpcyB0aGF0IHRoZXkgYXJl IG5vdCBsb25nIHRlcm0gcGVyc2lzdGVudCBhbmQgdGh1cw0KPiA+IGNhbid0IGJlIHVzZWQgZm9y IGxvbmcgdGVybSB0cmFja2luZyBvZiB0aGUgdXNlci4gV3JpdGluZyAidW50cmFjZWFibGUiDQo+ ID4gSSB3b3VsZCBpbnRlcnByZXQgYXMgaW5kaWNhdGluZyBhIHN0cm9uZ2VyIHVzZXIgcHJvdGVj dGlvbiB0aGVuIHdoYXQNCj4gPiBpcyBhY3R1YWxseSBwcm92aWRlZC4NCj4gPg0KPiA+IENoZWVy cw0KPiA+DQo+ID4gTWFnbnVzDQo+ID4NCj4gPiBEZW4gMjAxNy0wMi0xMyBrbC4gMTA6NTksIHNr cmV2IFJvbmkgRXZlbjoNCj4gPj4gSGksDQo+ID4+IFRoaXMgbmV3IHZlcnNpb24gaXMgc3VibWl0 dGVkIHRvIGFkZHJlc3MgTWFnbnVzIGFuZCBCZW4gY29tbWVudHMuDQo+ID4+IFRoZXJlIGlzIGEg bmV3IHNlY3Rpb24gQ29tbXVuaWNhdGlvbiBzZWN1cml0eSB0aGF0IHNwZWNpZmllcw0KPiA+PiBu b3JtYXRpdmUgc2VjdXJpdHkgZm9yIENMVUUgbWVkaWEuDQo+ID4+IFRoZSBzZWN1cml0eSBjb25z aWRlcmF0aW9uIGlzIGp1c3QgY29uc2lkZXJhdGlvbnMgYW5kIGFkZGVkIHRleHQNCj4gPj4gYWJv dXQgdGhlIENhcHR1cmVJRCBUaGVyZSBhcmUgYWxzbyBzb21lIGVkaXRvcmlhbCBhbmQgbml0cyBj aGFuZ2VzDQo+ID4+IFJvbmkNCj4gPj4NCj4gPj4NCj4gPj4gLS0tLS1PcmlnaW5hbCBNZXNzYWdl LS0tLS0NCj4gPj4gRnJvbTogY2x1ZSBbbWFpbHRvOmNsdWUtYm91bmNlc0BpZXRmLm9yZ10gT24g QmVoYWxmIE9mDQo+ID4+IGludGVybmV0LWRyYWZ0c0BpZXRmLm9yZw0KPiA+PiBTZW50OiDXmdeV 150g15EgMTMg16TXkdeo15XXkNeoIDIwMTcgMTE6MzANCj4gPj4gVG86IGktZC1hbm5vdW5jZUBp ZXRmLm9yZw0KPiA+PiBDYzogY2x1ZUBpZXRmLm9yZw0KPiA+PiBTdWJqZWN0OiBbY2x1ZV0gSS1E IEFjdGlvbjogZHJhZnQtaWV0Zi1jbHVlLXJ0cC1tYXBwaW5nLTEzLnR4dA0KPiA+Pg0KPiA+Pg0K PiA+PiBBIE5ldyBJbnRlcm5ldC1EcmFmdCBpcyBhdmFpbGFibGUgZnJvbSB0aGUgb24tbGluZSBJ bnRlcm5ldC1EcmFmdHMNCj4gPj4gZGlyZWN0b3JpZXMuDQo+ID4+IFRoaXMgZHJhZnQgaXMgYSB3 b3JrIGl0ZW0gb2YgdGhlIENvbnRyb0xsaW5nIG1VbHRpcGxlIHN0cmVhbXMgZm9yDQo+ID4+IHRF bGVwcmVzZW5jZSBvZiB0aGUgSUVURi4NCj4gPj4NCj4gPj4gICAgICAgICBUaXRsZSAgICAgICAg ICAgOiBNYXBwaW5nIFJUUCBzdHJlYW1zIHRvIENMVUUgTWVkaWEgQ2FwdHVyZXMNCj4gPj4gICAg ICAgICBBdXRob3JzICAgICAgICAgOiBSb25pIEV2ZW4NCj4gPj4gICAgICAgICAgICAgICAgICAg ICAgICAgICBKb25hdGhhbiBMZW5ub3gNCj4gPj4gICAgIEZpbGVuYW1lICAgICAgICA6IGRyYWZ0 LWlldGYtY2x1ZS1ydHAtbWFwcGluZy0xMy50eHQNCj4gPj4gICAgIFBhZ2VzICAgICAgICAgICA6 IDE0DQo+ID4+ICAgICBEYXRlICAgICAgICAgICAgOiAyMDE3LTAyLTEzDQo+ID4+DQo+ID4+IEFi c3RyYWN0Og0KPiA+PiAgICBUaGlzIGRvY3VtZW50IGRlc2NyaWJlcyBob3cgdGhlIFJlYWwgVGlt ZSB0cmFuc3BvcnQgUHJvdG9jb2wgKFJUUCkgaXMNCj4gPj4gICAgdXNlZCBpbiB0aGUgY29udGV4 dCBvZiB0aGUgQ0xVRSBwcm90b2NvbCAoQ29udHJvTGxpbmcgbVVsdGlwbGUNCj4gPj4gICAgc3Ry ZWFtcyBmb3IgdEVsZXByZXNlbmNlKS4gIEl0IGFsc28gZGVzY3JpYmVzIHRoZSBtZWNoYW5pc21z IGFuZA0KPiA+PiAgICByZWNvbW1lbmRlZCBwcmFjdGljZSBmb3IgbWFwcGluZyBSVFAgbWVkaWEg c3RyZWFtcyBkZWZpbmVkIGluDQo+IFNlc3Npb24NCj4gPj4gICAgRGVzY3JpcHRpb24gUHJvdG9j b2wgKFNEUCkgdG8gQ0xVRSBNZWRpYSBDYXB0dXJlcyBhbmQgZGVmaW5lcyBhIG5ldw0KPiA+PiAg ICBSVFAgaGVhZGVyIGV4dGVuc2lvbiAoQ2FwdHVyZUlkKS4NCj4gPj4NCj4gPj4NCj4gPj4gVGhl IElFVEYgZGF0YXRyYWNrZXIgc3RhdHVzIHBhZ2UgZm9yIHRoaXMgZHJhZnQgaXM6DQo+ID4+IGh0 dHBzOi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcvZG9jL2RyYWZ0LWlldGYtY2x1ZS1ydHAtbWFwcGlu Zy8NCj4gPj4NCj4gPj4gVGhlcmUncyBhbHNvIGEgaHRtbGl6ZWQgdmVyc2lvbiBhdmFpbGFibGUg YXQ6DQo+ID4+IGh0dHBzOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC1pZXRmLWNsdWUtcnRw LW1hcHBpbmctMTMNCj4gPj4NCj4gPj4gQSBkaWZmIGZyb20gdGhlIHByZXZpb3VzIHZlcnNpb24g aXMgYXZhaWxhYmxlIGF0Og0KPiA+PiBodHRwczovL3d3dy5pZXRmLm9yZy9yZmNkaWZmP3VybDI9 ZHJhZnQtaWV0Zi1jbHVlLXJ0cC1tYXBwaW5nLTEzDQo+ID4+DQo+ID4+DQo+ID4+IFBsZWFzZSBu b3RlIHRoYXQgaXQgbWF5IHRha2UgYSBjb3VwbGUgb2YgbWludXRlcyBmcm9tIHRoZSB0aW1lIG9m DQo+ID4+IHN1Ym1pc3Npb24gdW50aWwgdGhlIGh0bWxpemVkIHZlcnNpb24gYW5kIGRpZmYgYXJl IGF2YWlsYWJsZSBhdA0KPiA+PiB0b29scy5pZXRmLm9yZy4NCj4gPj4NCj4gPj4gSW50ZXJuZXQt RHJhZnRzIGFyZSBhbHNvIGF2YWlsYWJsZSBieSBhbm9ueW1vdXMgRlRQIGF0Og0KPiA+PiBmdHA6 Ly9mdHAuaWV0Zi5vcmcvaW50ZXJuZXQtZHJhZnRzLw0KPiA+Pg0KPiA+PiBfX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KPiA+PiBjbHVlIG1haWxpbmcgbGlz dA0KPiA+PiBjbHVlQGlldGYub3JnDQo+ID4+IGh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4v bGlzdGluZm8vY2x1ZQ0KPiA+Pg0KPiA+PiBfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fXw0KPiA+PiBjbHVlIG1haWxpbmcgbGlzdA0KPiA+PiBjbHVlQGlldGYu b3JnDQo+ID4+IGh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vY2x1ZQ0KPiA+ Pg0KPiA+IC0NCj4gPg0KDQo= From nobody Mon Feb 27 08:20:25 2017 Return-Path: X-Original-To: clue@ietfa.amsl.com Delivered-To: clue@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E4275129959 for ; Mon, 27 Feb 2017 08:20:23 -0800 (PST) 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 TpJkskbclwlO for ; Mon, 27 Feb 2017 08:20:22 -0800 (PST) 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 8881E12A1DA for ; Mon, 27 Feb 2017 08:20:20 -0800 (PST) X-AuditID: c1b4fb30-677ff70000001a00-84-58b451c12542 Received: from ESESSHC003.ericsson.se (Unknown_Domain [153.88.183.27]) by (Symantec Mail Security) with SMTP id 0A.44.06656.1C154B85; Mon, 27 Feb 2017 17:20:18 +0100 (CET) Received: from [127.0.0.1] (153.88.183.153) by smtp.internal.ericsson.com (153.88.183.29) with Microsoft SMTP Server id 14.3.319.2; Mon, 27 Feb 2017 17:20:17 +0100 To: Roni Even , Paul Kyzivat , "clue@ietf.org" , Jonathan Lennox References: <148697819872.24905.9378282459902101772.idtracker@ietfa.amsl.com> <6E58094ECC8D8344914996DAD28F1CCD77374B@DGGEMM506-MBX.china.huawei.com> <8d7ca9a1-b4de-8c3f-833e-c7119c1b7614@ericsson.com> <6E58094ECC8D8344914996DAD28F1CCD776CF8@DGGEMM506-MBX.china.huawei.com> From: Magnus Westerlund Message-ID: <999a3be6-2210-d38c-fb33-23ac6b9479e2@ericsson.com> Date: Mon, 27 Feb 2017 17:20:17 +0100 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.7.1 MIME-Version: 1.0 In-Reply-To: <6E58094ECC8D8344914996DAD28F1CCD776CF8@DGGEMM506-MBX.china.huawei.com> Content-Type: text/plain; charset="utf-8"; format=flowed Content-Transfer-Encoding: 8bit X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFtrLLMWRmVeSWpSXmKPExsUyM2K7tO6hwC0RBrOe6VrsP3WZ2WL/4vPM Fis2HGC1+HTsPIsDi8ff9x+YPFqOvGX1WLLkJ5NH27M77AEsUVw2Kak5mWWpRfp2CVwZN/5M ZytoYq34eGM9ewNjL0sXIyeHhICJxJn9rWxdjFwcQgLrGCXubPzBDOEsZ5T4MrORCaRKWMBN 4sTTU2AdIgKTGSU2X+AHsYUEzjJJLJprDWKzCVhI3PzRyAZi8wrYS6x9BWGzCKhKLDi8lhXE FhWIkdjbf58JokZQ4uTMJ2AzOQVCJJ69uwlmMwPNmTn/PCOELS/RvHU2M8QubYmGpg7WCYz8 s5C0z0LSMgtJywJG5lWMosWpxUm56UZGeqlFmcnFxfl5enmpJZsYgYF6cMtvgx2ML587HmIU 4GBU4uH9YLclQog1say4MvcQowQHs5IIr5s3UIg3JbGyKrUoP76oNCe1+BCjNAeLkjiv2cr7 4UIC6YklqdmpqQWpRTBZJg5OqQbGNR5yu0++OMO0eJXNeoO7Pc/rjh/fHxSZo84922Z5116z o41aE38um3jrf+i292v+p32UXb/6Yrf/qrA7PybPmH1t+0Kv5b6c8qULSh7xS+WE6N3tVSyY 3i5Z9JMxbHLgnOX2/6xyLDPLpzK3NZxSu7Tlv//Xy+uX7ntqvvSR+dZohj9XC+Xb+ZRYijMS DbWYi4oTATCpraFQAgAA Archived-At: Subject: Re: [clue] FW: I-D Action: draft-ietf-clue-rtp-mapping-13.txt X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: CLUE - ControLling mUltiple streams for TElepresence List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 27 Feb 2017 16:20:24 -0000 Den 2017-02-27 kl. 16:09, skrev Roni Even: > Hi Paul, > Just submitted -14 that I think addresses Magnus concerns Yes, I this is good enough. Thanks Magnus Westerlund ---------------------------------------------------------------------- Services, Media and Network features, Ericsson Research EAB/TXM ---------------------------------------------------------------------- Ericsson AB | Phone +46 10 7148287 Färögatan 6 | Mobile +46 73 0949079 SE-164 80 Stockholm, Sweden | mailto: magnus.westerlund@ericsson.com ---------------------------------------------------------------------- From nobody Mon Feb 27 09:37:23 2017 Return-Path: X-Original-To: clue@ietfa.amsl.com Delivered-To: clue@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F3AD612A2B2 for ; Mon, 27 Feb 2017 09:37:21 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.934 X-Spam-Level: X-Spam-Status: No, score=-1.934 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_SOFTFAIL=0.665, URIBL_BLOCKED=0.001] 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 M_M92_5RSM62 for ; Mon, 27 Feb 2017 09:37:21 -0800 (PST) Received: from resqmta-po-04v.sys.comcast.net (resqmta-po-04v.sys.comcast.net [IPv6:2001:558:fe16:19:96:114:154:163]) (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 3AB9A12A2B0 for ; Mon, 27 Feb 2017 09:37:21 -0800 (PST) Received: from resomta-po-20v.sys.comcast.net ([96.114.154.244]) by resqmta-po-04v.sys.comcast.net with SMTP id iPCKcqbrvxUJaiPEecQnog; Mon, 27 Feb 2017 17:37:20 +0000 Received: from [192.168.1.110] ([73.186.127.100]) by resomta-po-20v.sys.comcast.net with SMTP id iPEdcNk80XnUMiPEecUg0f; Mon, 27 Feb 2017 17:37:20 +0000 To: Magnus Westerlund , Roni Even , "clue@ietf.org" , Jonathan Lennox References: <148697819872.24905.9378282459902101772.idtracker@ietfa.amsl.com> <6E58094ECC8D8344914996DAD28F1CCD77374B@DGGEMM506-MBX.china.huawei.com> <8d7ca9a1-b4de-8c3f-833e-c7119c1b7614@ericsson.com> <6E58094ECC8D8344914996DAD28F1CCD776CF8@DGGEMM506-MBX.china.huawei.com> <999a3be6-2210-d38c-fb33-23ac6b9479e2@ericsson.com> From: Paul Kyzivat Message-ID: <36d2728f-7d58-c527-adff-e034a8955e2b@alum.mit.edu> Date: Mon, 27 Feb 2017 12:37:19 -0500 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:45.0) Gecko/20100101 Thunderbird/45.7.1 MIME-Version: 1.0 In-Reply-To: <999a3be6-2210-d38c-fb33-23ac6b9479e2@ericsson.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit X-CMAE-Envelope: MS4wfJo+r7hwWutiTts14zbgrnYsIw7IVqasCArbhyuFBpMomKlWqlzq/GbtQ2eAdA5JUnPNuJIQvx8/QV8pD4u5m77TNoqL4wkIgyKoSpTH7vSTqprPlA1Q oMewGFsLQALfHQvtgQIkT1BtmYKyd6N8tv+Ovxlom1/+0SUqb8CvM3YJjnoNTrfKcgtxY28JM3Y416QRUvuF8p3Rj9DTcQ6hRnJaFaQF09FrXq4quVXRGEBK guOb/rk3q040RmmimygdlBPdvS6/hAZlUjd4xP7Ew6g= Archived-At: Subject: Re: [clue] FW: I-D Action: draft-ietf-clue-rtp-mapping-13.txt X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: CLUE - ControLling mUltiple streams for TElepresence List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 27 Feb 2017 17:37:22 -0000 Thank you Roni and Magnus! IIUC we should be good to go now. I'm going to review and update my shepherd writeup now and then submit to iesg. If you know any reason not to do that then speak up NOW. Thanks, Paul On 2/27/17 11:20 AM, Magnus Westerlund wrote: > Den 2017-02-27 kl. 16:09, skrev Roni Even: >> Hi Paul, >> Just submitted -14 that I think addresses Magnus concerns > > Yes, I this is good enough. > > Thanks > > Magnus Westerlund > > ---------------------------------------------------------------------- > Services, Media and Network features, Ericsson Research EAB/TXM > ---------------------------------------------------------------------- > Ericsson AB | Phone +46 10 7148287 > Färögatan 6 | Mobile +46 73 0949079 > SE-164 80 Stockholm, Sweden | mailto: magnus.westerlund@ericsson.com > ---------------------------------------------------------------------- > > From nobody Mon Feb 27 12:41:54 2017 Return-Path: X-Original-To: clue@ietf.org Delivered-To: clue@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 0FE5C124281; Mon, 27 Feb 2017 12:41:54 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: The IESG To: "IETF-Announce" X-Test-IDTracker: no X-IETF-IDTracker: 6.46.0 Auto-Submitted: auto-generated Precedence: bulk MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit Message-ID: <148822811404.13771.3135289066043288949.idtracker@ietfa.amsl.com> Date: Mon, 27 Feb 2017 12:41:54 -0800 Archived-At: Cc: draft-ietf-clue-rtp-mapping@ietf.org, clue@ietf.org, The IESG , clue-chairs@ietf.org, rfc-editor@rfc-editor.org Subject: [clue] Protocol Action: 'Mapping RTP streams to CLUE Media Captures' to Proposed Standard (draft-ietf-clue-rtp-mapping-14.txt) X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.17 List-Id: CLUE - ControLling mUltiple streams for TElepresence List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 27 Feb 2017 20:41:54 -0000 The IESG has approved the following document: - 'Mapping RTP streams to CLUE Media Captures' (draft-ietf-clue-rtp-mapping-14.txt) as Proposed Standard This document is the product of the ControLling mUltiple streams for tElepresence Working Group. The IESG contact persons are Alexey Melnikov, Ben Campbell and Alissa Cooper. A URL of this Internet Draft is: https://datatracker.ietf.org/doc/draft-ietf-clue-rtp-mapping/ Technical Summary This document describes how the Real Time transport Protocol (RTP) is used in the context of the CLUE protocol. It also describes the mechanisms and recommended practice for mapping RTP media streams defined in SDP to CLUE Media Captures. Working Group Summary Very late in the game we received substantial comments on this document from an RTP expert that had not been active in the work group. This led to some substantial revisions, primarily for alignment with other RTP-related documents. The primary effect was to remove a lot of text that was thought to be be confusing. Document Quality Are there existing implementations of the protocol? A prototype implementation has been built and demonstrated. Have a significant number of vendors indicated their plan to implement the specification? Not yet. Are there any reviewers that merit special mention as having done a thorough review, e.g., one that resulted in important changes or a conclusion that the document had no substantive issues? Colin Perkins made major comments that resulted in better alignment of this document with other work. If there was a MIB Doctor, Media Type or other expert review, what was its course (briefly)? In the case of a Media Type review, on what date was the request posted? N/A Personnel Who is the Document Shepherd? Paul Kyzivat Who is the Responsible Area Director? Alissa Cooper