From nobody Mon Jun 1 02:47:54 2015 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 870541A9129 for ; Mon, 1 Jun 2015 02:47:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.201 X-Spam-Level: X-Spam-Status: No, score=-4.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham 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 9Ld3NEqy3s3R for ; Mon, 1 Jun 2015 02:47:51 -0700 (PDT) Received: from sesbmg23.ericsson.net (sesbmg23.ericsson.net [193.180.251.37]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2E0B41A912C for ; Mon, 1 Jun 2015 02:47:51 -0700 (PDT) X-AuditID: c1b4fb25-f79b66d000001131-ac-556c2a453530 Received: from ESESSHC020.ericsson.se (Unknown_Domain [153.88.253.125]) by sesbmg23.ericsson.net (Symantec Mail Security) with SMTP id B5.A7.04401.54A2C655; Mon, 1 Jun 2015 11:47:49 +0200 (CEST) Received: from [127.0.0.1] (153.88.183.153) by smtp.internal.ericsson.com (153.88.183.80) with Microsoft SMTP Server id 14.3.210.2; Mon, 1 Jun 2015 11:47:48 +0200 Message-ID: <556C2A44.8010805@ericsson.com> Date: Mon, 1 Jun 2015 11:47:48 +0200 From: Magnus Westerlund User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.7.0 MIME-Version: 1.0 To: Mary Barnes References: <55683230.3020600@ericsson.com> In-Reply-To: Content-Type: text/plain; charset="utf-8"; format=flowed Content-Transfer-Encoding: 8bit X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFtrJLMWRmVeSWpSXmKPExsUyM+Jvra6rVk6owcEHshaHFl9itZjfeZrd YumkBawWn/fvZ3Zg8WhZ1cvssXPWXXaPJUt+MnnM2vmEJYAlissmJTUnsyy1SN8ugStj3aK5 7AVtShXz+p+xNDAekuhi5OCQEDCRWPrbqIuRE8gUk7hwbz1bFyMXh5DAUUaJCdt2MIMkhASW MUosXlEBYvMKaEvcbTwDFmcRUJHY1XOdCcRmE7CQuPmjkQ3EFhWIkpj6eB0LRL2gxMmZT8Bs EQEdiW+f34LVMAtsYpQ4vRlsprCAqcSSnT+gFj9llNh/Zgk7SIJTIFCiYdVOdogGC4mZ888z QtjyEs1bZ0Mdpy3R0NTBOoFRcBaSfbOQtMxC0rKAkXkVo2hxanFSbrqRsV5qUWZycXF+nl5e askmRmBYH9zyW3UH4+U3jocYBTgYlXh4F+zJDhViTSwrrsw9xCjNwaIkzuvZFRIqJJCeWJKa nZpakFoUX1Sak1p8iJGJg1OqgbH1C+OlNXf28jS+XMpQs2oP68Jpr9cmG9Y3dU/4p/rjwcIX UpKzCqoLF133FeBgM/5q92AZ27vPHHMlvc/aLwj5W6T+49P0deGfFh/MkJvqzdARISpQ+afw 7jfOnc+OrP1xVCT1i/hHL67A13slAtv4F1zY9lzTd83pLqP5Dbw7bzOG+Z2N+h+nxFKckWio xVxUnAgAYAlD60wCAAA= Archived-At: Cc: Ben Campbell , DISPATCH , Barry Leiba Subject: Re: [dispatch] Updated PERC Charter proposal X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 01 Jun 2015 09:47:53 -0000 Hi, I have edited the proposed change into the Google Doc. Any more feedback on this? Cheers Magnus Mary Barnes skrev den 2015-05-29 16:53: > > > On Fri, May 29, 2015 at 4:32 AM, Magnus Westerlund > > > wrote: > > Hi, > > I hope others can comment on this also. > > Göran Eriksson AP skrev den 2015-05-25 17:10: > > Hi, > > I have some minor comments concerning the meaning of ³SIP² and > ³WebRTC² > endpoints. > > Sorry for the late response and for top-posting but it became a > bit messy > to add inline: > > 1. The link to > https://datatracker.ietf.org/doc/draft-ietf-rtcweb-overview/ did > not work? > > > It works fine for me. > > 2. The text uses ³SIP² and ³WebRTC² to describe the different > kind of > end-points that are in scope. > W3C WebRTC WG recognises the fact that the WebRTC end > points can be > browser end points > (browser + web (client portion of) web app) or native > WebRTC (or rather > rtcweb) clients and both are in scope for the W3C WG. > The browser endpoint trust model is different from that of > native > clients and it is also evolving. > I think that clarity in how different endpoints trust model and > security framework look like and different is beneficial for > several of > the deliverables, notably 2,3 and 5. > > > The use of WebRTC endpoints where deliberate by my and intended to > cover not only browsers but anything meeting the WebRTC endpoint > definition. So the question, does this need to be made more explicit > in the charter? > > [MB] I think this is fine as is in the charter - certainly it needs to > be clear in the deliverables but that's a detail we can deal with there. > [/MB] > > > > > 3. The charter says it will ³notify² W3C WebRTC about this > activity; what > do the WG expect to get back and why not Œcoordinate¹? And are > there other > W3C WG¹s that are relevant? > > > I think the expectation is that in the end W3C and likely RTCWEB WG > agrees to integrate the PERC solution into their specifications so > that one can actually use it with WebRTC. In intermediate step I > think it will be a question of notifying for example when there > exist a proposed blue-print for integration. This may be an example > of where coordinate might be needed. > > I could see that we could change the last sentence in the > collaboration part from: > "We will notify AVTCore, CLUE, MMUSIC, RTCWEB, SIPREC, W3C WebRTC, > and other related groups about this work." > > to > "We will notify, and when needed coordinate with, AVTCore, CLUE, > MMUSIC, RTCWEB, SIPREC, W3C WebRTC, and other related groups about > this work." > > Opinions? > > [MB] I think the suggested change is fine. [/MB] > > > Cheers > > 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 > > ---------------------------------------------------------------------- > > -- 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 Jun 1 03:06:17 2015 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0CFBE1A9063 for ; Mon, 1 Jun 2015 03:06:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.901 X-Spam-Level: X-Spam-Status: No, score=-3.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham 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 yloI-C5RvfaH for ; Mon, 1 Jun 2015 03:06:14 -0700 (PDT) Received: from sesbmg22.ericsson.net (sesbmg22.ericsson.net [193.180.251.48]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 94FAF1A905F for ; Mon, 1 Jun 2015 03:06:13 -0700 (PDT) X-AuditID: c1b4fb30-f799f6d000000faf-4d-556c2e9382ac Received: from ESESSHC007.ericsson.se (Unknown_Domain [153.88.253.125]) by sesbmg22.ericsson.net (Symantec Mail Security) with SMTP id AF.0B.04015.39E2C655; Mon, 1 Jun 2015 12:06:11 +0200 (CEST) Received: from ESESSMB209.ericsson.se ([169.254.9.71]) by ESESSHC007.ericsson.se ([153.88.183.39]) with mapi id 14.03.0210.002; Mon, 1 Jun 2015 12:06:10 +0200 From: =?utf-8?B?R8O2cmFuIEVyaWtzc29uIEFQ?= To: Magnus Westerlund , Mary Barnes Thread-Topic: [dispatch] Updated PERC Charter proposal Thread-Index: AQHQlKdG9ChevnWVek2TK9VDBGzQpZ2M0KkAgAXJRwCAAFnGAIAEYX0AgAAmp4A= Date: Mon, 1 Jun 2015 10:06:10 +0000 Message-ID: References: <55683230.3020600@ericsson.com> <556C2A44.8010805@ericsson.com> In-Reply-To: <556C2A44.8010805@ericsson.com> Accept-Language: sv-SE, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.5.0.150423 x-originating-ip: [153.88.183.150] Content-Type: text/plain; charset="utf-8" Content-ID: <34211EF1831EFA4B99C8ADFADED56E78@ericsson.com> Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFlrMIsWRmVeSWpSXmKPExsUyM+Jvre5kvZxQg90NchaHFl9itZjfeZrd YumkBawWn/fvZ3Zg8WhZ1cvssXPWXXaPJUt+MnnM2vmEJYAlissmJTUnsyy1SN8ugSvj4Zxr LAUHDCuO/JjH2MA4x6CLkZNDQsBEYtKk7awQtpjEhXvr2boYuTiEBI4ySrx5A5IAcRYxShzd OosdpIpNwFuireUwC4gtIpAkMWldL1g3s0CmxLQbR8FsYQFTiSU7f7BB1JhJfNy/FqreT+LI uTlgcRYBFYkVR38wg9i8AtYSl1+/BbOFBHqZJHb/i+pi5ODgFNCRuN+VDxJmFJCVuP/9HgvE KnGJW0/mM0EcLSCxZM95ZghbVOLl439gJ4gK6Eks/XoaqkZJYsX2S4wgI5kFNCXW79KHGGMt cb37ABuErSgxpfshO8Q1ghInZz5hmcAoMQvJtlkI3bOQdM9C0j0LSfcCRtZVjKLFqcVJuelG RnqpRZnJxcX5eXp5qSWbGIGxenDLb4MdjC+fOx5iFOBgVOLhXbAnO1SINbGsuDL3EKM0B4uS OK9nV0iokEB6YklqdmpqQWpRfFFpTmrxIUYmDk6pBsYS9b/CPt4yXFeVNyZarqgsNYx9uE3b ouX6S37NCpcZeyfekbbMTNqZuXDr818J1huNHk9OXNhjltPIFpZ+xKEnJTP1gJyDNWNh7L8l q6LeGfD3XHOT9TrU4HTsLeORTbl1WU/5vD/7uZ47uHinT3ZmQbTm5vyMZ9sPn/q6PCrS+cjH WJv4eCWW4oxEQy3mouJEAOiX5S+2AgAA Archived-At: Cc: Ben Campbell , DISPATCH , Barry Leiba Subject: Re: [dispatch] Updated PERC Charter proposal X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 01 Jun 2015 10:06:16 -0000 DQoNCg0KDQo+SGksDQo+DQo+SSBoYXZlIGVkaXRlZCB0aGUgcHJvcG9zZWQgY2hhbmdlIGludG8g dGhlIEdvb2dsZSBEb2MuIEFueSBtb3JlIGZlZWRiYWNrDQo+b24gdGhpcz8NCg0KTm8sIE1hcnni gJlzIHN0YXRlbWVudCBvbiBkZWxpdmVyYWJsZXMgYW5kIFlvdSBhZGRpdGlvbiBhZGRyZXNzZXMg bXkNCmNvbmNlcm5zIHdlbGwgZW5vdWdoIGF0IHRoaXMgcGludCwgOi0pLg0KDQoNCj4NCj5DaGVl cnMNCj4NCj5NYWdudXMNCj4NCj5NYXJ5IEJhcm5lcyBza3JldiBkZW4gMjAxNS0wNS0yOSAxNjo1 MzoNCj4+DQo+Pg0KPj4gT24gRnJpLCBNYXkgMjksIDIwMTUgYXQgNDozMiBBTSwgTWFnbnVzIFdl c3Rlcmx1bmQNCj4+IDxtYWdudXMud2VzdGVybHVuZEBlcmljc3Nvbi5jb20gPG1haWx0bzptYWdu dXMud2VzdGVybHVuZEBlcmljc3Nvbi5jb20+Pg0KPj4gd3JvdGU6DQo+Pg0KPj4gICAgIEhpLA0K Pj4NCj4+ICAgICBJIGhvcGUgb3RoZXJzIGNhbiBjb21tZW50IG9uIHRoaXMgYWxzby4NCj4+DQo+ PiAgICAgR8O2cmFuIEVyaWtzc29uIEFQIHNrcmV2IGRlbiAyMDE1LTA1LTI1IDE3OjEwOg0KPj4N Cj4+ICAgICAgICAgSGksDQo+Pg0KPj4gICAgICAgICBJIGhhdmUgc29tZSBtaW5vciBjb21tZW50 cyBjb25jZXJuaW5nIHRoZSBtZWFuaW5nIG9mIMKzU0lQwrIgYW5kDQo+PiAgICAgICAgIMKzV2Vi UlRDwrINCj4+ICAgICAgICAgZW5kcG9pbnRzLg0KPj4NCj4+ICAgICAgICAgU29ycnkgZm9yIHRo ZSBsYXRlIHJlc3BvbnNlIGFuZCBmb3IgdG9wLXBvc3RpbmcgYnV0IGl0IGJlY2FtZSBhDQo+PiAg ICAgICAgIGJpdCBtZXNzeQ0KPj4gICAgICAgICB0byBhZGQgaW5saW5lOg0KPj4NCj4+ICAgICAg ICAgMS4gVGhlIGxpbmsgdG8NCj4+ICAgICAgICAgaHR0cHM6Ly9kYXRhdHJhY2tlci5pZXRmLm9y Zy9kb2MvZHJhZnQtaWV0Zi1ydGN3ZWItb3ZlcnZpZXcvIGRpZA0KPj4gICAgICAgICBub3Qgd29y az8NCj4+DQo+Pg0KPj4gICAgIEl0IHdvcmtzIGZpbmUgZm9yIG1lLg0KPj4NCj4+ICAgICAgICAg Mi4gVGhlIHRleHQgdXNlcyDCs1NJUMKyIGFuZCDCs1dlYlJUQ8KyIHRvIGRlc2NyaWJlIHRoZSBk aWZmZXJlbnQNCj4+ICAgICAgICAga2luZCBvZg0KPj4gICAgICAgICBlbmQtcG9pbnRzIHRoYXQg YXJlIGluIHNjb3BlLg0KPj4gICAgICAgICAgICAgIFczQyBXZWJSVEMgV0cgcmVjb2duaXNlcyB0 aGUgZmFjdCB0aGF0IHRoZSBXZWJSVEMgZW5kDQo+PiAgICAgICAgIHBvaW50cyBjYW4gYmUNCj4+ ICAgICAgICAgYnJvd3NlciBlbmQgcG9pbnRzDQo+PiAgICAgICAgICAgICAgKGJyb3dzZXIgKyB3 ZWIgKGNsaWVudCBwb3J0aW9uIG9mKSB3ZWIgYXBwKSBvciBuYXRpdmUNCj4+ICAgICAgICAgV2Vi UlRDIChvciByYXRoZXINCj4+ICAgICAgICAgcnRjd2ViKSBjbGllbnRzIGFuZCBib3RoIGFyZSBp biBzY29wZSBmb3IgdGhlIFczQyBXRy4NCj4+ICAgICAgICAgICAgICBUaGUgYnJvd3NlciBlbmRw b2ludCB0cnVzdCBtb2RlbCBpcyBkaWZmZXJlbnQgZnJvbSB0aGF0IG9mDQo+PiAgICAgICAgIG5h dGl2ZQ0KPj4gICAgICAgICBjbGllbnRzIGFuZCBpdCBpcyBhbHNvIGV2b2x2aW5nLg0KPj4gICAg ICAgICAgICAgIEkgdGhpbmsgdGhhdCBjbGFyaXR5IGluIGhvdyBkaWZmZXJlbnQgZW5kcG9pbnRz IHRydXN0DQo+Pm1vZGVsIGFuZA0KPj4gICAgICAgICBzZWN1cml0eSBmcmFtZXdvcmsgbG9vayBs aWtlIGFuZCBkaWZmZXJlbnQgaXMgYmVuZWZpY2lhbCBmb3INCj4+ICAgICAgICAgc2V2ZXJhbCBv Zg0KPj4gICAgICAgICB0aGUgZGVsaXZlcmFibGVzLCBub3RhYmx5IDIsMyBhbmQgNS4NCj4+DQo+ Pg0KPj4gICAgIFRoZSB1c2Ugb2YgV2ViUlRDIGVuZHBvaW50cyB3aGVyZSBkZWxpYmVyYXRlIGJ5 IG15IGFuZCBpbnRlbmRlZCB0bw0KPj4gICAgIGNvdmVyIG5vdCBvbmx5IGJyb3dzZXJzIGJ1dCBh bnl0aGluZyBtZWV0aW5nIHRoZSBXZWJSVEMgZW5kcG9pbnQNCj4+ICAgICBkZWZpbml0aW9uLiBT byB0aGUgcXVlc3Rpb24sIGRvZXMgdGhpcyBuZWVkIHRvIGJlIG1hZGUgbW9yZSBleHBsaWNpdA0K Pj4gICAgIGluIHRoZSBjaGFydGVyPw0KPj4NCj4+IFtNQl0gSSB0aGluayB0aGlzIGlzIGZpbmUg YXMgaXMgaW4gdGhlIGNoYXJ0ZXIgLSBjZXJ0YWlubHkgaXQgbmVlZHMgdG8NCj4+IGJlIGNsZWFy IGluIHRoZSBkZWxpdmVyYWJsZXMgYnV0IHRoYXQncyBhIGRldGFpbCB3ZSBjYW4gZGVhbCB3aXRo IHRoZXJlLg0KPj4gWy9NQl0NCj4+DQo+Pg0KPj4NCj4+DQo+PiAgICAgICAgIDMuIFRoZSBjaGFy dGVyIHNheXMgaXQgd2lsbCDCs25vdGlmecKyIFczQyBXZWJSVEMgYWJvdXQgdGhpcw0KPj4gICAg ICAgICBhY3Rpdml0eTsgd2hhdA0KPj4gICAgICAgICBkbyB0aGUgV0cgZXhwZWN0IHRvIGdldCBi YWNrIGFuZCB3aHkgbm90IMWSY29vcmRpbmF0ZcK5PyBBbmQgYXJlDQo+PiAgICAgICAgIHRoZXJl IG90aGVyDQo+PiAgICAgICAgIFczQyBXR8K5cyB0aGF0IGFyZSByZWxldmFudD8NCj4+DQo+Pg0K Pj4gICAgIEkgdGhpbmsgdGhlIGV4cGVjdGF0aW9uIGlzIHRoYXQgaW4gdGhlIGVuZCBXM0MgYW5k IGxpa2VseSBSVENXRUIgV0cNCj4+ICAgICBhZ3JlZXMgdG8gaW50ZWdyYXRlIHRoZSBQRVJDIHNv bHV0aW9uIGludG8gdGhlaXIgc3BlY2lmaWNhdGlvbnMgc28NCj4+ICAgICB0aGF0IG9uZSBjYW4g YWN0dWFsbHkgdXNlIGl0IHdpdGggV2ViUlRDLiBJbiBpbnRlcm1lZGlhdGUgc3RlcCBJDQo+PiAg ICAgdGhpbmsgaXQgd2lsbCBiZSBhIHF1ZXN0aW9uIG9mIG5vdGlmeWluZyBmb3IgZXhhbXBsZSB3 aGVuIHRoZXJlDQo+PiAgICAgZXhpc3QgYSBwcm9wb3NlZCBibHVlLXByaW50IGZvciBpbnRlZ3Jh dGlvbi4gVGhpcyBtYXkgYmUgYW4gZXhhbXBsZQ0KPj4gICAgIG9mIHdoZXJlIGNvb3JkaW5hdGUg bWlnaHQgYmUgbmVlZGVkLg0KPj4NCj4+ICAgICBJIGNvdWxkIHNlZSB0aGF0IHdlIGNvdWxkIGNo YW5nZSB0aGUgbGFzdCBzZW50ZW5jZSBpbiB0aGUNCj4+ICAgICBjb2xsYWJvcmF0aW9uIHBhcnQg ZnJvbToNCj4+ICAgICAiV2Ugd2lsbCBub3RpZnkgQVZUQ29yZSwgQ0xVRSwgTU1VU0lDLCBSVENX RUIsIFNJUFJFQywgVzNDIFdlYlJUQywNCj4+ICAgICBhbmQgb3RoZXIgcmVsYXRlZCBncm91cHMg YWJvdXQgdGhpcyB3b3JrLiINCj4+DQo+PiAgICAgdG8NCj4+ICAgICAiV2Ugd2lsbCBub3RpZnks IGFuZCB3aGVuIG5lZWRlZCBjb29yZGluYXRlIHdpdGgsIEFWVENvcmUsIENMVUUsDQo+PiAgICAg TU1VU0lDLCBSVENXRUIsIFNJUFJFQywgVzNDIFdlYlJUQywgYW5kIG90aGVyIHJlbGF0ZWQgZ3Jv dXBzIGFib3V0DQo+PiAgICAgdGhpcyB3b3JrLiINCj4+DQo+PiAgICAgT3BpbmlvbnM/DQo+Pg0K Pj4gW01CXSBJIHRoaW5rIHRoZSBzdWdnZXN0ZWQgY2hhbmdlIGlzIGZpbmUuIFsvTUJdDQo+Pg0K Pj4NCj4+ICAgICBDaGVlcnMNCj4+DQo+PiAgICAgTWFnbnVzIFdlc3Rlcmx1bmQNCj4+DQo+PiAg ICAgDQo+Pi0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0NCj4+ICAgICBTZXJ2aWNlcywgTWVkaWEgYW5kIE5ldHdvcmsg ZmVhdHVyZXMsIEVyaWNzc29uIFJlc2VhcmNoIEVBQi9UWE0NCj4+ICAgICANCj4+LS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLQ0KPj4gICAgIEVyaWNzc29uIEFCICAgICAgICAgICAgICAgICB8IFBob25lICs0NiAxMCA3 MTQ4Mjg3DQo+PiAgICAgPHRlbDolMkI0NiUyMDEwJTIwNzE0ODI4Nz4NCj4+ICAgICBGw6Ryw7Zn YXRhbiA2ICAgICAgICAgICAgICAgICB8IE1vYmlsZSArNDYgNzMgMDk0OTA3OQ0KPj4gICAgIDx0 ZWw6JTJCNDYlMjA3MyUyMDA5NDkwNzk+DQo+PiAgICAgU0UtMTY0IDgwIFN0b2NraG9sbSwgU3dl ZGVuIHwgbWFpbHRvOiBtYWdudXMud2VzdGVybHVuZEBlcmljc3Nvbi5jb20NCj4+ICAgICA8bWFp bHRvOm1hZ251cy53ZXN0ZXJsdW5kQGVyaWNzc29uLmNvbT4NCj4+ICAgICANCj4+LS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLQ0KPj4NCj4+DQo+DQo+DQo+LS0gDQo+DQo+TWFnbnVzIFdlc3Rlcmx1bmQNCj4NCj4tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tDQo+U2VydmljZXMsIE1lZGlhIGFuZCBOZXR3b3JrIGZlYXR1cmVzLCBFcmljc3Nv biBSZXNlYXJjaCBFQUIvVFhNDQo+LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLQ0KPkVyaWNzc29uIEFCICAgICAgICAg ICAgICAgICB8IFBob25lICArNDYgMTAgNzE0ODI4Nw0KPkbDpHLDtmdhdGFuIDYgICAgICAgICAg ICAgICAgIHwgTW9iaWxlICs0NiA3MyAwOTQ5MDc5DQo+U0UtMTY0IDgwIFN0b2NraG9sbSwgU3dl ZGVuIHwgbWFpbHRvOiBtYWdudXMud2VzdGVybHVuZEBlcmljc3Nvbi5jb20NCj4tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tDQo+DQoNCg== From nobody Tue Jun 2 02:36:25 2015 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 076491A877A for ; Tue, 2 Jun 2015 02:36:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.598 X-Spam-Level: X-Spam-Status: No, score=-1.598 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, FREEMAIL_REPLY=1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, UNPARSEABLE_RELAY=0.001] autolearn=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 v9SUo-s_GeSc for ; Tue, 2 Jun 2015 02:36:20 -0700 (PDT) Received: from relais-inet.francetelecom.com (relais-ias244.francetelecom.com [80.12.204.244]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 56FC21A908B for ; Tue, 2 Jun 2015 02:36:10 -0700 (PDT) Received: from omfeda08.si.francetelecom.fr (unknown [xx.xx.xx.201]) by omfeda10.si.francetelecom.fr (ESMTP service) with ESMTP id AFA1B3740C0; Tue, 2 Jun 2015 11:36:08 +0200 (CEST) Received: from Exchangemail-eme2.itn.ftgroup (unknown [10.114.31.60]) by omfeda08.si.francetelecom.fr (ESMTP service) with ESMTP id 93FB9384061; Tue, 2 Jun 2015 11:36:08 +0200 (CEST) Received: from OPEXCLILM42.corporate.adroot.infra.ftgroup ([fe80::d5fd:9c7d:2ee3:39d9]) by OPEXCLILM7F.corporate.adroot.infra.ftgroup ([fe80::c1d7:e278:e357:11ad%19]) with mapi id 14.03.0235.001; Tue, 2 Jun 2015 11:36:08 +0200 From: To: Mary Barnes Thread-Topic: Comments: draft-mohali-dispatch-cause-for-service-number-02.txt Thread-Index: AQHQlCDXKEdgl3jgf0KpV71iuAdXSp2ZBgXg Date: Tue, 2 Jun 2015 09:36:08 +0000 Message-ID: <5736_1433237768_556D7908_5736_2614_1_8B970F90C584EA4E97D5BAAC9172DBB814D255FE@OPEXCLILM42.corporate.adroot.infra.ftgroup> References: In-Reply-To: Accept-Language: fr-FR, en-US Content-Language: fr-FR X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.168.234.5] Content-Type: multipart/alternative; boundary="_000_8B970F90C584EA4E97D5BAAC9172DBB814D255FEOPEXCLILM42corp_" MIME-Version: 1.0 X-PMX-Version: 6.2.1.2478543, Antispam-Engine: 2.7.2.2107409, Antispam-Data: 2015.6.2.90316 Archived-At: Cc: Ben Campbell , "dispatch@ietf.org" Subject: Re: [dispatch] Comments: draft-mohali-dispatch-cause-for-service-number-02.txt X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 02 Jun 2015 09:36:24 -0000 --_000_8B970F90C584EA4E97D5BAAC9172DBB814D255FEOPEXCLILM42corp_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SGkgTWFyeSwNCg0KTWFueSB0aGFua3MgZm9yIHlvdXIgZGV0YWlsZWQgcmV2aWV3ICENCknigJlt IG9rIHdpdGggeW91ciBnZW5lcmFsIGNvbW1lbnQuDQpJ4oCZbSBnb2luZyB0byB1cGRhdGUgdGhl IGRyYWZ0IGZvbGxvd2luZyB5b3VyIHByb3Bvc2FsLg0KDQpLaW5kIHJlZ2FyZHMsDQpNYXJpYW5u ZQ0KDQpEZSA6IE1hcnkgQmFybmVzIFttYWlsdG86bWFyeS5pZXRmLmJhcm5lc0BnbWFpbC5jb21d DQpFbnZvecOpIDogdmVuZHJlZGkgMjIgbWFpIDIwMTUgMDE6NTANCsOAIDogTU9IQUxJIE1hcmlh bm5lIElNVC9PTE4NCkNjIDogZGlzcGF0Y2hAaWV0Zi5vcmc7IEJlbiBDYW1wYmVsbA0KT2JqZXQg OiBDb21tZW50czogZHJhZnQtbW9oYWxpLWRpc3BhdGNoLWNhdXNlLWZvci1zZXJ2aWNlLW51bWJl ci0wMi50eHQNCg0KSW4gYW50aWNpcGF0aW9uIG9mIGRvaW5nIHRoZSBzaGVwaGVyZCB3cml0ZS11 cCwgSSBoYXZlIGNhcmVmdWxseSByZXZpZXdlZCB0aGlzIGRvY3VtZW50IGFuZCBpdCBzdGlsbCBu ZWVkcyBzb21lIHdvcmsgYmVmb3JlIHdlIGNhbiBwcm9ncmVzcyBpdC4NClBlciB0aGUgZW1haWwg ZGlzY3Vzc2lvbiB3aXRoIFBhdWwsIEkgdGhpbmsgd2UgbmVlZCB0byBtYWtlIHN1cmUgdGhpcyBk b2N1bWVudCBpcyBwYXJ0aWN1bGFybHkgY2xlYXIgdGhhdCB0aGUgbmV3IHZhbHVlIGRlZmluZWQg Zm9yIHRoZSDigJxjYXVzZeKAnSBVUkkgcGFyYW1ldGVyIGlzIG9ubHkgYWRkZWQgdG8gdGhlIFJl cXVlc3QtVVJJIHBlciBSRkMgNDQ1OC4gICBUaGUgcHJlc2VuY2Ugb2YgdGhlIOKAnGNhdXNl4oCd IFVSSSBwYXJhbWV0ZXIgaW4gdGhlIFJlcXVlc3QtVVJJIGlzIHRvdGFsbHkgdHJhbnNwYXJlbnQg dG8gdGhlIEhpc3RvcnktSW5mbyBoZWFkZXIgZmllbGQgcHJvY2Vzc2luZyB3aGVuIHRoZSBSZXF1 ZXN0LVVSSSBpcyBjYXB0dXJlZCBpbiB0aGUgaGktdGFyZ2V0ZWQtdG8tdXJpIGhlYWRlciBmaWVs ZCBwYXJhbWV0ZXIuDQpGb3IgdGhlIGZ1bmN0aW9uYWxpdHkgdGhhdCBpcyBpbnRlbmRlZCB0byBi ZSBhY2hpZXZlZCB3aXRoIGEgbmV3IHZhbHVlIGZvciB0aGUg4oCcY2F1c2XigJ0gVVJJIHBhcmFt ZXRlciwgdGhlIHJldGFyZ2V0aW5nIGVudGl0eSBuZWVkcyB0byBhZGQgdGhlIEhpc3RvcnktSW5m byBoZWFkZXIgZmllbGQsIG90aGVyd2lzZSB0aGUgUmVxdWVzdC1VUkkgdGhhdCBjb250YWlucyB0 aGUgZGVzaXJlZCBpbmZvcm1hdGlvbiBpcyBsb3N0LCBidXQgdGhhdCBpcyBnZW5lcmljIGZ1bmN0 aW9uYWxpdHkgZm9yIGFueSBhcHBsaWNhdGlvbiB0aGF0IG5lZWRzIHRvIG1ha2UgZGVjaXNpb25z IGJhc2VkIG9uIHRoZSBvcmlnaW5hbC9yZXRhcmdldGVkIFVSSXMuICAgIEJhc2ljYWxseSwgdGhp cyBwcm9wb3NhbCBpcyB0YWtpbmcgYWR2YW50YWdlIG9mIHRoZSBmdW5jdGlvbmFsaXR5IGRlZmlu ZWQgaW4gUkZDIDQ0NTggZm9yIHRoZSBuZXcg4oCcY2F1c2XigJ0gdmFsdWUgYW5kIHRoZXJlIGlz IGEgZGVwZW5kZW5jeSBvbiB0aGUgSGlzdG9yeS1JbmZvIGhlYWRlciBmaWVsZCB0byBjYXB0dXJl IHRoYXQgaW5mb3JtYXRpb24uICBCdXQsIGl04oCZcyB0aGUgZW5kIGFwcGxpY2F0aW9uIHRoYXQg cHJvY2Vzc2VzIHRoZSBIaXN0b3J5LUluZm8gaGVhZGVyIGZpZWxkIHRoYXQga25vd3Mgd2hhdCB0 byBkbyB3aXRoIHRoYXQg4oCcY2F1c2XigJ0gdmFsdWUuICAgVGhlcmUgY291bGQgc3RpbGwgYmUg c29tZSBjYXNlcyB0aGF0IG1pZ2h0IHdvcmsgd2l0aG91dCBIaXN0b3J5LUluZm8gaWYgeW91IHdl cmVu4oCZdCBkb2luZyBtdWx0aXBsZSByZXRhcmdldHMuDQpNeSBzdWdnZXN0ZWQgY2hhbmdlcyBi ZWxvdyBhcmUgaW50ZW5kZWQgdG8gZm9jdXMgdGhlIGRvY3VtZW50IG9uIHRoZSBuZXcgcHJvdG9j b2wgaW1wYWN0cywgbGVhdmluZyBvdXQgbWVudGlvbiBvZiBIaXN0b3J5LUluZm8gdW50aWwgYSBs YXR0ZXIgc2VjdGlvbiB3aGVyZSB0aGUgdXNlIG9mIHRoZSBuZXcg4oCcY2F1c2XigJ0gdmFsdWUg aXMgZGVzY3JpYmVkLg0KTm90ZSwgSeKAmXZlIGFsc28gaWRlbnRpZmllZCBzb21lIG90aGVyIGVk aXRvcmlhbCBjaGFuZ2VzIHRoYXQgSSB0aGluayBjYW4gYmUgZG9uZSB3aXRob3V0IGxvc2luZyBp bXBvcnRhbnQgYXNwZWN0cyBvZiB0aGUgcHJvcG9zYWwgYW5kIHRoZW4gSSBoYXZlIGlkZW50aWZp ZWQgc29tZSAgbml0cyBhdCB0aGUgZW5kOg0KMSkgQWJzdHJhY3Q6DQpJIGRvbuKAmXQgdGhpbmsg eW91IHJlYWxseSBldmVuIG5lZWQgdG8gbWVudGlvbiBIaXN0b3J5LUluZm8gaW4gdGhlIGFic3Ry YWN0LiAgUmVhbGx5LCB3aGF0IHlvdSBhcmUgZG9pbmcgaXMgZW5hYmxpbmcgYSBzZXJ2aWNlIGlu IG11Y2ggdGhlIHNhbWUgbWFubmVyIGFzIFJGQyA0NDU4IGVuYWJsZWQgdm9pY2VtYWlsIGZvciBz b21lIHNjZW5hcmlvcy4gICBTbywgSSBzdWdnZXN0IHRoYXQgeW91IHJld29yZCB0aGUgYWJzdHJh Y3Qgc29tZXRoaW5nIGxpa2UgdGhlIGZvbGxvd2luZzoNCk9MRDoNCiAgIFtSRkM0NDU4XSBkZWZp bmVzIGEgImNhdXNlIiBVUkkgcGFyYW1ldGVyIGFzIGhhdmluZyBwcmVkZWZpbmVkIHZhbHVlcw0K ICAgZm9yIFJlZGlyZWN0aW5nIHJlYXNvbnMgYXMgYSBtYXBwaW5nIGZyb20gSVRVLVQgUS43MzIu Mi01IFJlZGlyZWN0aW5nDQogICBSZWFzb25zLiAgVGhlICJjYXVzZSIgVVJJIHBhcmFtZXRlciBp cyB0byBiZSB1c2VkIGluIFNJUCBvciBTSVBzIFVSSS4NCiAgIEluIHBhcnRpY3VsYXIsIGl0IG1h eSBhcHBlYXIgaW4gdGhlIFJlcXVlc3QtVVJJIGFuZCBpbiB0aGUgSGlzdG9yeS0NCiAgIEluZm8g aGVhZGVyIGZpZWxkIGRlZmluZWQgaW4gW1JGQzcwNDRdIGluIHNvbWUgc3BlY2lmaWMgcmV0YXJn ZXRlZA0KICAgcmVxdWVzdHMgZGVmaW5lZCBpbiB0aGlzIGRvY3VtZW50Lg0KICAgVGhpcyBzcGVj aWZpY2F0aW9uIGNyZWF0ZXMgYSBuZXcgcHJlZGVmaW5lZCB2YWx1ZSBmb3IgY2FzZXMgd2hlbiB0 aGUNCiAgIHJldGFyZ2V0aW5nIGlzIGNhdXNlZCBieSBhIHNwZWNpZmljIHNlcnZpY2UgYWN0aW9u IGxlYWRpbmcgdG8gYQ0KICAgY2FsbGVkIHNlcnZpY2UgYWNjZXNzIG51bWJlciB0cmFuc2xhdGlv bi4NCiAgIFRoaXMgZG9jdW1lbnQgdXBkYXRlcyBbUkZDNDQ1OF0uDQpORVc6DQogICBbUkZDNDQ1 OF0gZGVmaW5lcyBhICJjYXVzZSIgVVJJIHBhcmFtZXRlciBhcyBoYXZpbmcgcHJlZGVmaW5lZCB2 YWx1ZXMNCiAgIGZvciBSZWRpcmVjdGluZyByZWFzb25zIGJhc2VkIG9uIGEgbWFwcGluZyBmcm9t IElUVS1UIFEuNzMyLjItNQ0KICAgUmVkaXJlY3RpbmcgUmVhc29ucy4gVGhlICJjYXVzZSIgVVJJ IHBhcmFtZXRlciBjYW4gYmUgdXNlZCBpbiBhIFNJUCBvcg0KICAgU0lQcyBVUkkuIEluIHBhcnRp Y3VsYXIsIGl0IG1heSBhcHBlYXIgaW4gdGhlIFJlcXVlc3QtVVJJIGluIGEgU0lQDQogICBSZXF1 ZXN0LiAgVGhpcyBzcGVjaWZpY2F0aW9uIGNyZWF0ZXMgYSBuZXcgcHJlZGVmaW5lZCB2YWx1ZSBm b3IgdGhlDQogICAiY2F1c2UiIFVSSSBwYXJhbWV0ZXIgZm9yIGNhc2VzIHdoZW4gdGhlIHJldGFy Z2V0aW5nIGlzIGR1ZSB0byBhIHNwZWNpZmljDQogICBzZXJ2aWNlIGFjdGlvbiBsZWFkaW5nIHRv IGEgY2FsbGVkIHNlcnZpY2UgYWNjZXNzIG51bWJlciB0cmFuc2xhdGlvbi4NCiAgIFRoaXMgZG9j dW1lbnQgdXBkYXRlcyBbUkZDNDQ1OF0uDQoyKSBJbnRyb2R1Y3Rpb246DQphKSBJIHN1Z2dlc3Qg dG8gbW92ZSB0aGUgZmlyc3QgMiBwYXJhZ3JhcGhzIHRvIGEgbmV3IHNlY3Rpb24gdGhhdCBkZXNj cmliZXMgaGFuZGxpbmcgb2YgUmVxdWVzdC1VUklzIHRoYXQgY29udGFpbiBhIOKAnGNhdXNl4oCd IHZhbHVlIGluZGljYXRpbmcgU2VydmljZSBOdW1iZXIgVHJhbnNsYXRpb24uDQpiKSAzcmQgcGFy YWdyYXBoLiAgSSBzdWdnZXN0IHRvIHJld29yZCB0aGlzIHBhcmFncmFwaDoNCk9MRDoNCiAgIFRo ZSAiY2F1c2UiIFVSSSBwYXJhbWV0ZXIgbWF5IGJlIHVzZWQgaW4gdGhlDQogICBSZXF1ZXN0LVVS SSBhbmQgaW4gdGhlIEhpc3RvcnktaW5mbyBoZWFkZXIgZmllbGQgdG8gaW5kaWNhdGUgdGhlDQog ICBzZXJ2aWNlIHRoYXQgdGhlIFVzZXJBZ2VudCBTZXJ2ZXIgKFVBUykgcmVjZWl2aW5nIHRoZSBt ZXNzYWdlIHNob3VsZA0KICAgcGVyZm9ybS4NCk5FVzoNCiAgIFRoZSAiY2F1c2UiIFVSSSBwYXJh bWV0ZXIgbWF5IGJlIHVzZWQgaW4gdGhlDQogICBSZXF1ZXN0LVVSSSB0byBpbmRpY2F0ZSB0aGUN CiAgIHNlcnZpY2UgdGhhdCB0aGUgVXNlciBBZ2VudCBTZXJ2ZXIgKFVBUykgcmVjZWl2aW5nIHRo ZSBtZXNzYWdlIHNob3VsZCBwZXJmb3JtLg0KYykgNHRoIHBhcmFncmFwaDogUmVtb3ZlIHRoZSDi gJxDb25jdXJyZW50bHks4oCdIGFuZCBzdGFydCB3aXRoIOKAnEEgbWVjaGFuaXNt4oCm4oCdDQpk KSA1dGggcGFyYWdyYXBoLiBSZW1vdmUgc2luY2UgeW91IGhhdmVu4oCZdCBicm91Z2h0IEhpc3Rv cnktSW5mbyBpbnRvIHRoaXMgZGlzY3Vzc2lvbiB5ZXQuICBZb3UgY2FuIGFkZCB0aGlzIGNsYXJp ZnlpbmcgcG9pbnQgbGF0ZXIgdG8gdGhlIHNlY3Rpb24gdGhhdCBkZXNjcmliZXMgdGhlIGhhbmRs aW5nIG9mIFJlcXVlc3QtVVJJcyB0aGF0IGNvbnRhaW4gdGhlIG5ldyBjYXVzZSB2YWx1ZS4NCjMp IFNlY3Rpb24gNCAtIEV4YW1wbGUuICAgQWxvbmcgdGhlIGxpbmVzIG9mIHRoZSBwcm9wb3NhbCB0 byBkZXNjcmliZSB0aGUgcHJvY2Vzc2luZyBmb3IgdGhlIG5ldyDigJxjYXVzZeKAnSBVUkkgcGFy YW1ldGVyLCBJIHRoaW5rIGl0IHdvdWxkIGhlbHAgdG8gaGF2ZSBhIHRleHR1YWwgZGVzY3JpcHRp b24gZm9yIGVhY2ggb2YgdGhlIHN0ZXBzIGluIHRoZSBtZXNzYWdlIGZsb3cuDQoNClByb3Bvc2Vk IG5ldyBzZWN0aW9uIG9uIGhvdyB0aGUgbmV3IOKAnGNhdXNl4oCdIFVSSSBwYXJhbWV0ZXIgdmFs dWUgaXMgaGFuZGxlZC9wcm9jZXNzZWQ6DQo9PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09DQpJdCBtaWdodCBiZSBiZXN0IHRv IGRlc2NyaWJlIHdoZW4gdGhhdCBzcGVjaWZpYyB2YWx1ZSBmb3IgdGhlIOKAnGNhdXNl4oCdIGlz IHVzZWQgYnkgdGhlIHByb3h5L2ludGVybWVkaWFyeSBhbmQgdGhlbiBzZXBhcmF0ZWx5IGRlc2Ny aWJlIHRoZSBiZWhhdmlvciBvZiB0aGUgVUFTIHVwb24gcmVjZWlwdCBvZiBoaS10YXJnZXRlZC10 by11cmlzIHRoYXQgY29udGFpbiB0aGF0IOKAnGNhdXNl4oCdIHZhbHVlLiAgICBJIHdvdWxkIHN1 Z2dlc3QgdG8gYWRkIHRoaXMgc2VjdGlvbiBhcyBhIHN1Yi1zZWN0aW9uIG9mIHNlY3Rpb24gMyBv ciBhcyBhIG5ldyBzZWN0aW9uIGJldHdlZW4gc2VjdGlvbnMgMyAmIDQgKG5vdGUsIHlvdSBjb3Vs ZCBmb2xsb3cgdGhlIG1vZGVsIGluIHNlY3Rpb24gMiBvZiBSRkMgNDQ1OCkNCkluIHRlcm1zIG9m IHdoZW4gdGhlIOKAnGNhdXNl4oCdIGlzIGFkZGVkIHRvIHRoZSBSZXF1ZXN0IFVSSSBieSB0aGUg cHJveHkvaW50ZXJtZWRpYXJ5LCBpdOKAmXMgaW1wb3J0YW50IHRoYXQgaXTigJlzIGNsZWFyIHRo YXQgdGhlIGRldGVybWluYXRpb24gb2YgdGhlIG5ldyB0YXJnZXQgaXMgaW5kZXBlbmRlbnQgb2Yg cHJvY2Vzc2luZyBkb25lIHdoZW4gdGhlIEhpc3RvcnktSW5mbyBoZWFkZXIgZmllbGQgaXMgYWRk ZWQgLSB3ZSB3b3JrZWQgdmVyeSBoYXJkIHRvIG1ha2UgdGhhdCBxdWl0ZSBjbGVhciAob3IgYXMg Y2xlYXIgYXMgcG9zc2libGUgZ2l2ZW4gU0lQKSBpbiB0ZXJtcyBvZiBub3QgZGV2aWF0aW5nIGZy b20gdGhlIHByb2Nlc3NpbmcgYXMgZGVzY3JpYmVkIGluIFJGQyAzMjYxLiAgIFRoaXMgc2VjdGlv biB3b3VsZCBiZSB3aGVyZSB5b3UgYWRkIHRoZSB3YXJuaW5nIGFib3V0IG5vdCBjb25mdXNpbmcg dGhlIG5ldyDigJxjYXVzZeKAnSB2YWx1ZSB3aXRoIHRoZSDigJxjYXVzZeKAnSBpbiB0aGUgUmVh c29uIGhlYWRlciBmaWVsZCB0aGF0IGlzIHBhcnQgb2YgdGhlIEhpc3RvcnktSW5mbyBoZWFkZXIg ZmllbGQuDQpJbiB0aGlzIG5ldyBzZWN0aW9uLCBJIHRoaW5rIHlvdSBvdWdodCB0byBkZXNjcmli ZSBhbnkgaW50ZXJhY3Rpb25zIGJldHdlZW4gdGhlIG5ldyB2YWx1ZSBmb3IgdGhlIOKAnGNhdXNl 4oCdIFVSSSBwYXJhbWV0ZXJzIGFuZCB0aGUgSGlzdG9yeS1JbmZvIGhlYWRlciBmaWVsZCBwYXJh bWV0ZXJzIGFzIHdhcyBkb25lIGluIFJGQyA0NDU4IChzZWN0aW9uIDMpLiAgWW91IGNvdWxkIHBy ZWZhY2UgdGhpcyBkaXNjdXNzaW9uIHdpdGggdGhlIHR3byBwYXJhZ3JhcGhzIHlvdSBoYWQgaW4g dGhlIGludHJvIHdpdGggYmFja2dyb3VuZCBvbiBSRkMgNDI0NC4gSW4gdGhpcyBzZWN0aW9uLCBJ IHdvdWxkIGV4cGVjdCB0byBzZWUgdGhpbmdzIGxpa2UgdGhlIGZvbGxvd2luZyBhZGRyZXNzZWQv Y2xhcmlmaWVkOiAgIGRvZXMgdGhlIFVBUyBvbmx5IGxvb2sgZm9yIHRoZSDigJxjYXVzZeKAnSBV UkkgcGFyYW1ldGVyIGlmIHRoZXJlIGlzIGFuIOKAnG1w4oCdIG9yIOKAnHJj4oCdIHRhZyBvciBk b2VzIGl0IGxvb2sgZm9yIHRoZSDigJxjYXVzZeKAnSBVUkkgcGFyYW1ldGVyIGFuZCB0aGVuIGxv b2sgZm9yIOKAnG1w4oCdIGFuZCDigJxyY+KAnSB0byBrbm93IHdoZXRoZXIgdGhlIFVBUyBuZWVk cyB0byBwZXJmb3JtIHRoYXQgc3BlY2lmaWMgc2VydmljZS4gIEl0IGFsc28gbmVlZHMgdG8gYmUg Y2xlYXIsIG9mIGNvdXJzZSwgdGhhdCB0aGUgZW5kIGZ1bmN0aW9uYWxpdHkgeW91IGRlc2lyZSBt YXkgbm90IGJlIGFjaGlldmFibGUgd2l0aG91dCB0aGUgSGlzdG9yeS1JbmZvIGhlYWRlciBzdWJz ZXF1ZW50bHkgYmVpbmcgYWRkZWQgdG8gdGhlIG1lc3NhZ2UgYW5kIE5PVCBiZWluZyByZW1vdmVk IGFsb25nIHRoZSB3YXkuICAgQWx0aG91Z2gsIEkgd291bGQgdGhpbmsgeW91ciBhcHBsaWNhdGlv biBvdWdodCB0byB3b3JrIGFzIGV4cGVjdGVkIGlmIHRoYXQg4oCcY2F1c2XigJ0gVVJJIHBhcmFt ZXRlciB2YWx1ZSBpcyBpbiB0aGUgUmVxdWVzdC1VUkkuICAgUGVyIFJGQyA3MDQ0LCB5b3Ugb3Vn aHQgdG8gZGVzY3JpYmUgd2hhdCB3aWxsIGhhcHBlbiBpZiBhIEhpc3RvcnktSW5mbyBoZWFkZXIg ZmllbGQgd2l0aCBhIFJlcXVlc3QtVVJJIGNvbnRhaW5pbmcgdGhhdCB2YWx1ZSBmb3IgdGhlIOKA nGNhdXNl4oCdIFVSSSBwYXJhbWV0ZXIgaXMgcmVtb3ZlZC4NCk1pbm9yIGVkaXRvcmlhbCBjaGFu Z2VzOg0KPT09PT09PT09PT09PT09PT09PQ0KMSkgSW50cm9kdWN0aW9uIC0gNnRoIHBhcmFncmFw aDogSSB3b3VsZCBzdWdnZXN0IGRlbGV0aW5nIHRoYXQgMm5kIHNlbnRlbmNlIGFzIEkgdGhpbmsg bWFueSB3b3VsZCBkZWJhdGUgd2hldGhlciB0aGF0IGludGVudGlvbiB3YXMgYWN0dWFsbHkgcmVh bGl6ZWQgYnkgdGhhdCBzcGVjaWZpY2F0aW9uLiAgIFRoZW4sIHlvdSBsaWtlbHkgc2hvdWxkIGFk ZCB0aGF0IHJlZmVyZW5jZSBhdCB0aGUgZW5kIG9mIHRoZSBmaXJzdCBzZW50ZW5jZS4NCjIpIEni gJltIG5vdCBzdXJlIHRoYXQgc2VjdGlvbiAyIChQcm9ibGVtIHN0YXRlbWVudCkgYWRkcyBtdWNo IG1vcmUgdGhhbiB3aGF04oCZcyBpbiB0aGUgSW50cm9kdWN0aW9uICh3aGljaCBpbiB0aGUgZW5k IGlzIHJlYWxseSBtb3JlIG9mIGFuIEludHJvZHVjdGlvbiBhbmQgT3ZlcnZpZXcpLiAgU28sIHlv dSBjb3VsZCBqdXN0IG1vdmUgdGhlIDJuZCBwYXJhZ3JhcGggaW4gdGhpcyBzZWN0aW9uIHRvIHRo ZSBlbmQgb2Ygc2VjdGlvbiAxIGFuZCBzdGF0ZSBkZWNsYXJhdGl2ZWx5LCBzb21ldGhpbmcgbGlr ZSB0aGUgZm9sbG93aW5nICh1c2luZyDigJxhdCBsZWFzdOKAnSBpbXBsaWVzIHRoYXQgaXQgbWln aHQgY292ZXIgb3RoZXIgdGhpbmdzIHdoaWNoIGJlZ3MgdGhlIHF1ZXN0aW9uIHdoYXQgZWxzZSBt aWdodCBpdCBjb3ZlciB1bmxlc3MgeW91IGFjdHVhbGx5ICBoYXZlIHNvbWV0aGluZyBpbiBtaW5k KSA6DQogICBUaGUgbWVjaGFuaXNtIGNvdmVycyB0aGUgSU4gc2VydmljZXMgdGhhdCBjYW4gYmUN CiAgIGlkZW50aWZpZWQgaW4gdGhlIElTVVAgc2lnbmFsaW5nIGluIHRoZSAiY2FsbGVkIElOIG51 bWJlciIgYW5kDQogICAib3JpZ2luYWwgY2FsbGVkIElOIG51bWJlciIgb3B0aW9uYWwgcGFyYW1l dGVycyBkZWZpbmVkIGluDQogICBbSVRVLVRfUS43NjNdIGFuZCB1c2VkIGluIElTVVAvSU5BUCBp bnRlcndvcmtpbmcgYXMgZGVzY3JpYmVkIGluDQogICBbSVRVLVRfUS4xNjAwXS4NCkVkaXRvcmlh bCBuaXRzOg0KPT09PT09PT09PQ0KMSkgSW50cm9kdWN0aW9uLCAzcmQgcGFyYWdyYXBoOg0KLSDi gJxzZXJ2aWNlcyBmb3Jt4oCdIC0+IOKAnHNlcnZpY2VzIGZyb23igJ0NCi0gRXhwYW5kIHRoZSBh Y3JvbnltIFRETQ0KMikgU2VjdGlvbiAzIC0gU29sdXRpb246DQotIDFzdCBzZW50ZW5jZSByZW1v dmUgdGhlIHdvcmQg4oCcYWx0ZXJuYXRpdmXigJ0NCi0gMm5kIHBhcmFncmFwaCwgMXN0IHNlbnRl bmNlOiDigJxyZW1pbmRlZOKAnSAtPiDigJxzdW1tYXJpemVk4oCdDQoNCg0KCl9fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18KCkNl IG1lc3NhZ2UgZXQgc2VzIHBpZWNlcyBqb2ludGVzIHBldXZlbnQgY29udGVuaXIgZGVzIGluZm9y bWF0aW9ucyBjb25maWRlbnRpZWxsZXMgb3UgcHJpdmlsZWdpZWVzIGV0IG5lIGRvaXZlbnQgZG9u YwpwYXMgZXRyZSBkaWZmdXNlcywgZXhwbG9pdGVzIG91IGNvcGllcyBzYW5zIGF1dG9yaXNhdGlv bi4gU2kgdm91cyBhdmV6IHJlY3UgY2UgbWVzc2FnZSBwYXIgZXJyZXVyLCB2ZXVpbGxleiBsZSBz aWduYWxlcgphIGwnZXhwZWRpdGV1ciBldCBsZSBkZXRydWlyZSBhaW5zaSBxdWUgbGVzIHBpZWNl cyBqb2ludGVzLiBMZXMgbWVzc2FnZXMgZWxlY3Ryb25pcXVlcyBldGFudCBzdXNjZXB0aWJsZXMg ZCdhbHRlcmF0aW9uLApPcmFuZ2UgZGVjbGluZSB0b3V0ZSByZXNwb25zYWJpbGl0ZSBzaSBjZSBt ZXNzYWdlIGEgZXRlIGFsdGVyZSwgZGVmb3JtZSBvdSBmYWxzaWZpZS4gTWVyY2kuCgpUaGlzIG1l c3NhZ2UgYW5kIGl0cyBhdHRhY2htZW50cyBtYXkgY29udGFpbiBjb25maWRlbnRpYWwgb3IgcHJp dmlsZWdlZCBpbmZvcm1hdGlvbiB0aGF0IG1heSBiZSBwcm90ZWN0ZWQgYnkgbGF3Owp0aGV5IHNo b3VsZCBub3QgYmUgZGlzdHJpYnV0ZWQsIHVzZWQgb3IgY29waWVkIHdpdGhvdXQgYXV0aG9yaXNh dGlvbi4KSWYgeW91IGhhdmUgcmVjZWl2ZWQgdGhpcyBlbWFpbCBpbiBlcnJvciwgcGxlYXNlIG5v dGlmeSB0aGUgc2VuZGVyIGFuZCBkZWxldGUgdGhpcyBtZXNzYWdlIGFuZCBpdHMgYXR0YWNobWVu dHMuCkFzIGVtYWlscyBtYXkgYmUgYWx0ZXJlZCwgT3JhbmdlIGlzIG5vdCBsaWFibGUgZm9yIG1l c3NhZ2VzIHRoYXQgaGF2ZSBiZWVuIG1vZGlmaWVkLCBjaGFuZ2VkIG9yIGZhbHNpZmllZC4KVGhh bmsgeW91LgoK --_000_8B970F90C584EA4E97D5BAAC9172DBB814D255FEOPEXCLILM42corp_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTQgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 Q2FsaWJyaTsNCglwYW5vc2UtMToyIDE1IDUgMiAyIDIgNCAzIDIgNDt9DQpAZm9udC1mYWNlDQoJ e2ZvbnQtZmFtaWx5OlRhaG9tYTsNCglwYW5vc2UtMToyIDExIDYgNCAzIDUgNCA0IDIgNDt9DQov KiBTdHlsZSBEZWZpbml0aW9ucyAqLw0KcC5Nc29Ob3JtYWwsIGxpLk1zb05vcm1hbCwgZGl2Lk1z b05vcm1hbA0KCXttYXJnaW46MGNtOw0KCW1hcmdpbi1ib3R0b206LjAwMDFwdDsNCglmb250LXNp emU6MTIuMHB0Ow0KCWZvbnQtZmFtaWx5OiJUaW1lcyBOZXcgUm9tYW4iLCJzZXJpZiI7fQ0KYTps aW5rLCBzcGFuLk1zb0h5cGVybGluaw0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6 Ymx1ZTsNCgl0ZXh0LWRlY29yYXRpb246dW5kZXJsaW5lO30NCmE6dmlzaXRlZCwgc3Bhbi5Nc29I eXBlcmxpbmtGb2xsb3dlZA0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6cHVycGxl Ow0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0Kc3Bhbi5FbWFpbFN0eWxlMTcNCgl7bXNv LXN0eWxlLXR5cGU6cGVyc29uYWwtcmVwbHk7DQoJZm9udC1mYW1pbHk6IkFyaWFsIiwic2Fucy1z ZXJpZiI7DQoJY29sb3I6YmxhY2s7DQoJZm9udC13ZWlnaHQ6bm9ybWFsOw0KCWZvbnQtc3R5bGU6 bm9ybWFsO30NCi5Nc29DaHBEZWZhdWx0DQoJe21zby1zdHlsZS10eXBlOmV4cG9ydC1vbmx5Ow0K CWZvbnQtZmFtaWx5OiJDYWxpYnJpIiwic2Fucy1zZXJpZiI7DQoJbXNvLWZhcmVhc3QtbGFuZ3Vh Z2U6RU4tVVM7fQ0KQHBhZ2UgV29yZFNlY3Rpb24xDQoJe3NpemU6NjEyLjBwdCA3OTIuMHB0Ow0K CW1hcmdpbjo3MC44NXB0IDcwLjg1cHQgNzAuODVwdCA3MC44NXB0O30NCmRpdi5Xb3JkU2VjdGlv bjENCgl7cGFnZTpXb3JkU2VjdGlvbjE7fQ0KLS0+PC9zdHlsZT48IS0tW2lmIGd0ZSBtc28gOV0+ PHhtbD4NCjxvOnNoYXBlZGVmYXVsdHMgdjpleHQ9ImVkaXQiIHNwaWRtYXg9IjEwMjYiIC8+DQo8 L3htbD48IVtlbmRpZl0tLT48IS0tW2lmIGd0ZSBtc28gOV0+PHhtbD4NCjxvOnNoYXBlbGF5b3V0 IHY6ZXh0PSJlZGl0Ij4NCjxvOmlkbWFwIHY6ZXh0PSJlZGl0IiBkYXRhPSIxIiAvPg0KPC9vOnNo YXBlbGF5b3V0PjwveG1sPjwhW2VuZGlmXS0tPg0KPC9oZWFkPg0KPGJvZHkgbGFuZz0iRlIiIGxp bms9ImJsdWUiIHZsaW5rPSJwdXJwbGUiPg0KPGRpdiBjbGFzcz0iV29yZFNlY3Rpb24xIj4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFt aWx5OiZxdW90O0FyaWFsJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6YmxhY2si PkhpIE1hcnksPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNw YW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDss JnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjpibGFjayI+PG86cD4mbmJzcDs8L286cD48L3Nw YW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJm b250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7LCZxdW90O3NhbnMt c2VyaWYmcXVvdDs7Y29sb3I6YmxhY2siPk1hbnkgdGhhbmtzIGZvciB5b3VyIGRldGFpbGVkIHJl dmlldyZuYnNwOyE8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48 c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1 b3Q7QXJpYWwmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjpibGFjayI+SeKAmW0g b2sgd2l0aCB5b3VyIGdlbmVyYWwgY29tbWVudC48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC4w cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztj b2xvcjpibGFjayI+SeKAmW0gZ29pbmcgdG8gdXBkYXRlIHRoZSBkcmFmdCBmb2xsb3dpbmcgeW91 ciBwcm9wb3NhbC48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48 c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1 b3Q7QXJpYWwmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjpibGFjayI+PG86cD4m bmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0i RU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1 b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6YmxhY2siPktpbmQgcmVnYXJkcyw8bzpw PjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1V UyIgc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDss JnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjpibGFjayI+TWFyaWFubmU8bzpwPjwvbzpwPjwv c3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9 ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDssJnF1b3Q7c2Fu cy1zZXJpZiZxdW90Oztjb2xvcjpibGFjayI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+PGI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9u dC1mYW1pbHk6JnF1b3Q7VGFob21hJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPkRlJm5i c3A7Ojwvc3Bhbj48L2I+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6 JnF1b3Q7VGFob21hJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPiBNYXJ5IEJhcm5lcyBb bWFpbHRvOm1hcnkuaWV0Zi5iYXJuZXNAZ21haWwuY29tXQ0KPGJyPg0KPGI+RW52b3nDqSZuYnNw Ozo8L2I+IHZlbmRyZWRpIDIyIG1haSAyMDE1IDAxOjUwPGJyPg0KPGI+w4AmbmJzcDs6PC9iPiBN T0hBTEkgTWFyaWFubmUgSU1UL09MTjxicj4NCjxiPkNjJm5ic3A7OjwvYj4gZGlzcGF0Y2hAaWV0 Zi5vcmc7IEJlbiBDYW1wYmVsbDxicj4NCjxiPk9iamV0Jm5ic3A7OjwvYj4gQ29tbWVudHM6IGRy YWZ0LW1vaGFsaS1kaXNwYXRjaC1jYXVzZS1mb3Itc2VydmljZS1udW1iZXItMDIudHh0PG86cD48 L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48 L3A+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2lu LXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+SW4gYW50aWNpcGF0aW9u IG9mIGRvaW5nIHRoZSBzaGVwaGVyZCB3cml0ZS11cCwgSSBoYXZlIGNhcmVmdWxseSByZXZpZXdl ZCB0aGlzIGRvY3VtZW50IGFuZCBpdCBzdGlsbCBuZWVkcyBzb21lIHdvcmsgYmVmb3JlIHdlIGNh biBwcm9ncmVzcyBpdC4gJm5ic3A7ICZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1z b05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9t LWFsdDphdXRvIj5QZXIgdGhlIGVtYWlsIGRpc2N1c3Npb24gd2l0aCBQYXVsLCBJIHRoaW5rIHdl IG5lZWQgdG8gbWFrZSBzdXJlIHRoaXMgZG9jdW1lbnQgaXMgcGFydGljdWxhcmx5IGNsZWFyIHRo YXQgdGhlIG5ldyB2YWx1ZSBkZWZpbmVkIGZvciB0aGUg4oCcY2F1c2XigJ0gVVJJIHBhcmFtZXRl ciBpcyBvbmx5IGFkZGVkIHRvIHRoZQ0KIFJlcXVlc3QtVVJJIHBlciBSRkMgNDQ1OC4gJm5ic3A7 IFRoZSBwcmVzZW5jZSBvZiB0aGUg4oCcY2F1c2XigJ0gVVJJIHBhcmFtZXRlciBpbiB0aGUgUmVx dWVzdC1VUkkgaXMgdG90YWxseSB0cmFuc3BhcmVudCB0byB0aGUgSGlzdG9yeS1JbmZvIGhlYWRl ciBmaWVsZCBwcm9jZXNzaW5nIHdoZW4gdGhlIFJlcXVlc3QtVVJJIGlzIGNhcHR1cmVkIGluIHRo ZSBoaS10YXJnZXRlZC10by11cmkgaGVhZGVyIGZpZWxkIHBhcmFtZXRlci4gJm5ic3A7PG86cD48 L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0 OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPkZvciB0aGUgZnVuY3Rpb25hbGl0eSB0 aGF0IGlzIGludGVuZGVkIHRvIGJlIGFjaGlldmVkIHdpdGggYSBuZXcgdmFsdWUgZm9yIHRoZSDi gJxjYXVzZeKAnSBVUkkgcGFyYW1ldGVyLCB0aGUgcmV0YXJnZXRpbmcgZW50aXR5IG5lZWRzIHRv IGFkZCB0aGUgSGlzdG9yeS1JbmZvIGhlYWRlciBmaWVsZCwgb3RoZXJ3aXNlDQogdGhlIFJlcXVl c3QtVVJJIHRoYXQgY29udGFpbnMgdGhlIGRlc2lyZWQgaW5mb3JtYXRpb24gaXMgbG9zdCwgYnV0 IHRoYXQgaXMgZ2VuZXJpYyBmdW5jdGlvbmFsaXR5IGZvciBhbnkgYXBwbGljYXRpb24gdGhhdCBu ZWVkcyB0byBtYWtlIGRlY2lzaW9ucyBiYXNlZCBvbiB0aGUgb3JpZ2luYWwvcmV0YXJnZXRlZCBV UklzLiZuYnNwOyAmbmJzcDsgQmFzaWNhbGx5LCB0aGlzIHByb3Bvc2FsIGlzIHRha2luZyBhZHZh bnRhZ2Ugb2YgdGhlIGZ1bmN0aW9uYWxpdHkgZGVmaW5lZA0KIGluIFJGQyA0NDU4IGZvciB0aGUg bmV3IOKAnGNhdXNl4oCdIHZhbHVlIGFuZCB0aGVyZSBpcyBhIGRlcGVuZGVuY3kgb24gdGhlIEhp c3RvcnktSW5mbyBoZWFkZXIgZmllbGQgdG8gY2FwdHVyZSB0aGF0IGluZm9ybWF0aW9uLiZuYnNw OyBCdXQsIGl04oCZcyB0aGUgZW5kIGFwcGxpY2F0aW9uIHRoYXQgcHJvY2Vzc2VzIHRoZSBIaXN0 b3J5LUluZm8gaGVhZGVyIGZpZWxkIHRoYXQga25vd3Mgd2hhdCB0byBkbyB3aXRoIHRoYXQg4oCc Y2F1c2XigJ0gdmFsdWUuICZuYnNwOyBUaGVyZQ0KIGNvdWxkIHN0aWxsIGJlIHNvbWUgY2FzZXMg dGhhdCBtaWdodCB3b3JrIHdpdGhvdXQgSGlzdG9yeS1JbmZvIGlmIHlvdSB3ZXJlbuKAmXQgZG9p bmcgbXVsdGlwbGUgcmV0YXJnZXRzLiAmbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRv bS1hbHQ6YXV0byI+TXkgc3VnZ2VzdGVkIGNoYW5nZXMgYmVsb3cgYXJlIGludGVuZGVkIHRvIGZv Y3VzIHRoZSBkb2N1bWVudCBvbiB0aGUgbmV3IHByb3RvY29sIGltcGFjdHMsIGxlYXZpbmcgb3V0 IG1lbnRpb24gb2YgSGlzdG9yeS1JbmZvIHVudGlsIGEgbGF0dGVyIHNlY3Rpb24gd2hlcmUgdGhl IHVzZSBvZiB0aGUgbmV3IOKAnGNhdXNl4oCdDQogdmFsdWUgaXMgZGVzY3JpYmVkLiAmbmJzcDs8 bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRv cC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+Tm90ZSwgSeKAmXZlIGFsc28g aWRlbnRpZmllZCBzb21lIG90aGVyIGVkaXRvcmlhbCBjaGFuZ2VzIHRoYXQgSSB0aGluayBjYW4g YmUgZG9uZSB3aXRob3V0IGxvc2luZyBpbXBvcnRhbnQgYXNwZWN0cyBvZiB0aGUgcHJvcG9zYWwg YW5kIHRoZW4gSSBoYXZlIGlkZW50aWZpZWQgc29tZSZuYnNwOyBuaXRzIGF0IHRoZSBlbmQ6Jm5i c3A7PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdp bi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjEpIEFic3RyYWN0Ojxv OnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9w LWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj5JIGRvbuKAmXQgdGhpbmsgeW91 IHJlYWxseSBldmVuIG5lZWQgdG8gbWVudGlvbiBIaXN0b3J5LUluZm8gaW4gdGhlIGFic3RyYWN0 LiZuYnNwOyZuYnNwO1JlYWxseSwgd2hhdCB5b3UgYXJlIGRvaW5nIGlzIGVuYWJsaW5nIGEgc2Vy dmljZSBpbiBtdWNoIHRoZSBzYW1lIG1hbm5lciBhcyBSRkMgNDQ1OCBlbmFibGVkIHZvaWNlbWFp bA0KIGZvciBzb21lIHNjZW5hcmlvcy4mbmJzcDsmbmJzcDsmbmJzcDtTbywgSSBzdWdnZXN0IHRo YXQgeW91IHJld29yZCB0aGUgYWJzdHJhY3Qgc29tZXRoaW5nIGxpa2UgdGhlIGZvbGxvd2luZzom bmJzcDs8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFy Z2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+T0xEOiZuYnNwOzxv OnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9w LWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj4mbmJzcDsgJm5ic3A7W1JGQzQ0 NThdIGRlZmluZXMgYSAmcXVvdDtjYXVzZSZxdW90OyBVUkkgcGFyYW1ldGVyIGFzIGhhdmluZyBw cmVkZWZpbmVkIHZhbHVlczxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5 bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj4m bmJzcDsmbmJzcDsgZm9yIFJlZGlyZWN0aW5nIHJlYXNvbnMgYXMgYSBtYXBwaW5nIGZyb20gSVRV LVQgUS43MzIuMi01IFJlZGlyZWN0aW5nPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0 OmF1dG8iPiZuYnNwOyZuYnNwOyBSZWFzb25zLiZuYnNwOyBUaGUgJnF1b3Q7Y2F1c2UmcXVvdDsg VVJJIHBhcmFtZXRlciBpcyB0byBiZSB1c2VkIGluIFNJUCBvciBTSVBzIFVSSS48bzpwPjwvbzpw PjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0 bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+Jm5ic3A7Jm5ic3A7IEluIHBhcnRpY3VsYXIs IGl0IG1heSBhcHBlYXIgaW4gdGhlIFJlcXVlc3QtVVJJIGFuZCBpbiB0aGUgSGlzdG9yeS08bzpw PjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1h bHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+Jm5ic3A7Jm5ic3A7IEluZm8gaGVh ZGVyIGZpZWxkIGRlZmluZWQgaW4gW1JGQzcwNDRdIGluIHNvbWUgc3BlY2lmaWMgcmV0YXJnZXRl ZDxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4t dG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj4mbmJzcDsmbmJzcDsgcmVx dWVzdHMgZGVmaW5lZCBpbiB0aGlzIGRvY3VtZW50LjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90 dG9tLWFsdDphdXRvIj4mbmJzcDsmbmJzcDsgVGhpcyBzcGVjaWZpY2F0aW9uIGNyZWF0ZXMgYSBu ZXcgcHJlZGVmaW5lZCB2YWx1ZSBmb3IgY2FzZXMgd2hlbiB0aGU8bzpwPjwvbzpwPjwvcD4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFy Z2luLWJvdHRvbS1hbHQ6YXV0byI+Jm5ic3A7Jm5ic3A7IHJldGFyZ2V0aW5nIGlzIGNhdXNlZCBi eSBhIHNwZWNpZmljIHNlcnZpY2UgYWN0aW9uIGxlYWRpbmcgdG8gYTxvOnA+PC9vOnA+PC9wPg0K PHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1t YXJnaW4tYm90dG9tLWFsdDphdXRvIj4mbmJzcDsmbmJzcDsgY2FsbGVkIHNlcnZpY2UgYWNjZXNz IG51bWJlciB0cmFuc2xhdGlvbi48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi IHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0 byI+Jm5ic3A7Jm5ic3A7IFRoaXMgZG9jdW1lbnQgdXBkYXRlcyBbUkZDNDQ1OF0uPG86cD48L286 cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1 dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPk5FVzo8bzpwPjwvbzpwPjwvcD4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2lu LWJvdHRvbS1hbHQ6YXV0byI+Jm5ic3A7ICZuYnNwO1tSRkM0NDU4XSBkZWZpbmVzIGEgJnF1b3Q7 Y2F1c2UmcXVvdDsgVVJJIHBhcmFtZXRlciBhcyBoYXZpbmcgcHJlZGVmaW5lZCB2YWx1ZXM8bzpw PjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1h bHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+Jm5ic3A7Jm5ic3A7IGZvciBSZWRp cmVjdGluZyByZWFzb25zIGJhc2VkIG9uIGEgbWFwcGluZyBmcm9tIElUVS1UIFEuNzMyLjItNSZu YnNwOyAmbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJt c28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+Jm5ic3A7 Jm5ic3A7IFJlZGlyZWN0aW5nIFJlYXNvbnMuIFRoZSAmcXVvdDtjYXVzZSZxdW90OyBVUkkgcGFy YW1ldGVyIGNhbiBiZSB1c2VkIGluIGEgU0lQIG9yPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0 b20tYWx0OmF1dG8iPiZuYnNwOyZuYnNwOyBTSVBzIFVSSS4gSW4gcGFydGljdWxhciwgaXQgbWF5 IGFwcGVhciBpbiB0aGUgUmVxdWVzdC1VUkkgaW4gYSBTSVAmbmJzcDsgJm5ic3A7PG86cD48L286 cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1 dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPiZuYnNwOyZuYnNwOyBSZXF1ZXN0LiZuYnNw OyBUaGlzIHNwZWNpZmljYXRpb24gY3JlYXRlcyBhIG5ldyBwcmVkZWZpbmVkIHZhbHVlIGZvciB0 aGU8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2lu LXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+Jm5ic3A7Jm5ic3A7ICZx dW90O2NhdXNlJnF1b3Q7IFVSSSBwYXJhbWV0ZXIgZm9yIGNhc2VzIHdoZW4gdGhlIHJldGFyZ2V0 aW5nIGlzIGR1ZSB0byBhIHNwZWNpZmljJm5ic3A7PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0 b20tYWx0OmF1dG8iPiZuYnNwOyZuYnNwOyBzZXJ2aWNlIGFjdGlvbiBsZWFkaW5nIHRvIGEgY2Fs bGVkIHNlcnZpY2UgYWNjZXNzIG51bWJlciB0cmFuc2xhdGlvbi48bzpwPjwvbzpwPjwvcD4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFy Z2luLWJvdHRvbS1hbHQ6YXV0byI+Jm5ic3A7Jm5ic3A7IFRoaXMgZG9jdW1lbnQgdXBkYXRlcyBb UkZDNDQ1OF0uPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNv LW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjIpIEludHJv ZHVjdGlvbjombmJzcDs8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxl PSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+YSkg SSBzdWdnZXN0IHRvIG1vdmUgdGhlIGZpcnN0IDIgcGFyYWdyYXBocyB0byBhIG5ldyBzZWN0aW9u IHRoYXQgZGVzY3JpYmVzIGhhbmRsaW5nIG9mIFJlcXVlc3QtVVJJcyB0aGF0IGNvbnRhaW4gYSDi gJxjYXVzZeKAnSB2YWx1ZSBpbmRpY2F0aW5nIFNlcnZpY2UgTnVtYmVyIFRyYW5zbGF0aW9uLiZu YnNwOzxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJn aW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj5iKSAzcmQgcGFyYWdy YXBoLiZuYnNwOyBJIHN1Z2dlc3QgdG8gcmV3b3JkIHRoaXMgcGFyYWdyYXBoOiZuYnNwOzxvOnA+ PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFs dDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj5PTEQ6Jm5ic3A7PG86cD48L286cD48 L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87 bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPiZuYnNwOyZuYnNwOyBUaGUgJnF1b3Q7Y2F1c2Um cXVvdDsgVVJJIHBhcmFtZXRlciBtYXkgYmUgdXNlZCBpbiB0aGU8bzpwPjwvbzpwPjwvcD4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFy Z2luLWJvdHRvbS1hbHQ6YXV0byI+Jm5ic3A7Jm5ic3A7IFJlcXVlc3QtVVJJIGFuZCBpbiB0aGUg SGlzdG9yeS1pbmZvIGhlYWRlciBmaWVsZCB0byBpbmRpY2F0ZSB0aGU8bzpwPjwvbzpwPjwvcD4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28t bWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+Jm5ic3A7Jm5ic3A7IHNlcnZpY2UgdGhhdCB0aGUgVXNl ckFnZW50IFNlcnZlciAoVUFTKSByZWNlaXZpbmcgdGhlIG1lc3NhZ2Ugc2hvdWxkPG86cD48L286 cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1 dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPiZuYnNwOyZuYnNwOyBwZXJmb3JtLiAmbmJz cDs8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2lu LXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+TkVXOjxvOnA+PC9vOnA+ PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRv O21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj4mbmJzcDsmbmJzcDsgVGhlICZxdW90O2NhdXNl JnF1b3Q7IFVSSSBwYXJhbWV0ZXIgbWF5IGJlIHVzZWQgaW4gdGhlPG86cD48L286cD48L3A+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1h cmdpbi1ib3R0b20tYWx0OmF1dG8iPiZuYnNwOyZuYnNwOyBSZXF1ZXN0LVVSSSB0byBpbmRpY2F0 ZSB0aGU8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFy Z2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+Jm5ic3A7Jm5ic3A7 IHNlcnZpY2UgdGhhdCB0aGUgVXNlciBBZ2VudCBTZXJ2ZXIgKFVBUykgcmVjZWl2aW5nIHRoZSBt ZXNzYWdlIHNob3VsZCBwZXJmb3JtLiAmbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRv bS1hbHQ6YXV0byI+YykgNHRoIHBhcmFncmFwaDogUmVtb3ZlIHRoZSDigJxDb25jdXJyZW50bHks 4oCdIGFuZCBzdGFydCB3aXRoIOKAnEEgbWVjaGFuaXNt4oCm4oCdJm5ic3A7PG86cD48L286cD48 L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87 bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPmQpIDV0aCBwYXJhZ3JhcGguIFJlbW92ZSBzaW5j ZSB5b3UgaGF2ZW7igJl0IGJyb3VnaHQgSGlzdG9yeS1JbmZvIGludG8gdGhpcyBkaXNjdXNzaW9u IHlldC4mbmJzcDsgWW91IGNhbiBhZGQgdGhpcyBjbGFyaWZ5aW5nIHBvaW50IGxhdGVyIHRvIHRo ZSBzZWN0aW9uIHRoYXQgZGVzY3JpYmVzIHRoZSBoYW5kbGluZyBvZg0KIFJlcXVlc3QtVVJJcyB0 aGF0IGNvbnRhaW4gdGhlIG5ldyBjYXVzZSB2YWx1ZS48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJv dHRvbS1hbHQ6YXV0byI+MykgU2VjdGlvbiA0IC0gRXhhbXBsZS4gJm5ic3A7IEFsb25nIHRoZSBs aW5lcyBvZiB0aGUgcHJvcG9zYWwgdG8gZGVzY3JpYmUgdGhlIHByb2Nlc3NpbmcgZm9yIHRoZSBu ZXcg4oCcY2F1c2XigJ0gVVJJIHBhcmFtZXRlciwgSSB0aGluayBpdCB3b3VsZCBoZWxwIHRvIGhh dmUgYSB0ZXh0dWFsIGRlc2NyaXB0aW9uIGZvciBlYWNoDQogb2YgdGhlIHN0ZXBzIGluIHRoZSBt ZXNzYWdlIGZsb3cuJm5ic3A7ICZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05v cm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFs dDphdXRvIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxl PSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+UHJv cG9zZWQgbmV3IHNlY3Rpb24gb24gaG93IHRoZSBuZXcg4oCcY2F1c2XigJ0gVVJJIHBhcmFtZXRl ciB2YWx1ZSBpcyBoYW5kbGVkL3Byb2Nlc3NlZDo8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRv bS1hbHQ6YXV0byI+PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PTxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1h bCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDph dXRvIj5JdCBtaWdodCBiZSBiZXN0IHRvIGRlc2NyaWJlIHdoZW4gdGhhdCBzcGVjaWZpYyB2YWx1 ZSBmb3IgdGhlIOKAnGNhdXNl4oCdIGlzIHVzZWQgYnkgdGhlIHByb3h5L2ludGVybWVkaWFyeSBh bmQgdGhlbiBzZXBhcmF0ZWx5IGRlc2NyaWJlIHRoZSBiZWhhdmlvciBvZiB0aGUgVUFTIHVwb24g cmVjZWlwdCBvZiBoaS10YXJnZXRlZC10by11cmlzDQogdGhhdCBjb250YWluIHRoYXQg4oCcY2F1 c2XigJ0gdmFsdWUuJm5ic3A7ICZuYnNwOyBJIHdvdWxkIHN1Z2dlc3QgdG8gYWRkIHRoaXMgc2Vj dGlvbiBhcyBhIHN1Yi1zZWN0aW9uIG9mIHNlY3Rpb24gMyBvciBhcyBhIG5ldyBzZWN0aW9uIGJl dHdlZW4gc2VjdGlvbnMgMyAmYW1wOyA0IChub3RlLCB5b3UgY291bGQgZm9sbG93IHRoZSBtb2Rl bCBpbiBzZWN0aW9uIDIgb2YgUkZDIDQ0NTgpJm5ic3A7PG86cD48L286cD48L3A+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1i b3R0b20tYWx0OmF1dG8iPkluIHRlcm1zIG9mIHdoZW4gdGhlIOKAnGNhdXNl4oCdIGlzIGFkZGVk IHRvIHRoZSBSZXF1ZXN0IFVSSSBieSB0aGUgcHJveHkvaW50ZXJtZWRpYXJ5LCBpdOKAmXMgaW1w b3J0YW50IHRoYXQgaXTigJlzIGNsZWFyIHRoYXQgdGhlIGRldGVybWluYXRpb24gb2YgdGhlIG5l dyB0YXJnZXQgaXMgaW5kZXBlbmRlbnQgb2YgcHJvY2Vzc2luZw0KIGRvbmUgd2hlbiB0aGUgSGlz dG9yeS1JbmZvIGhlYWRlciBmaWVsZCBpcyBhZGRlZCAtIHdlIHdvcmtlZCB2ZXJ5IGhhcmQgdG8g bWFrZSB0aGF0IHF1aXRlIGNsZWFyIChvciBhcyBjbGVhciBhcyBwb3NzaWJsZSBnaXZlbiBTSVAp IGluIHRlcm1zIG9mIG5vdCBkZXZpYXRpbmcgZnJvbSB0aGUgcHJvY2Vzc2luZyBhcyBkZXNjcmli ZWQgaW4gUkZDIDMyNjEuICZuYnNwOyBUaGlzIHNlY3Rpb24gd291bGQgYmUgd2hlcmUgeW91IGFk ZCB0aGUgd2FybmluZyBhYm91dA0KIG5vdCBjb25mdXNpbmcgdGhlIG5ldyDigJxjYXVzZeKAnSB2 YWx1ZSB3aXRoIHRoZSDigJxjYXVzZeKAnSBpbiB0aGUgUmVhc29uIGhlYWRlciBmaWVsZCB0aGF0 IGlzIHBhcnQgb2YgdGhlIEhpc3RvcnktSW5mbyBoZWFkZXIgZmllbGQuJm5ic3A7ICZuYnNwOzxv OnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9w LWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj5JbiB0aGlzIG5ldyBzZWN0aW9u LCBJIHRoaW5rIHlvdSBvdWdodCB0byBkZXNjcmliZSBhbnkgaW50ZXJhY3Rpb25zIGJldHdlZW4g dGhlIG5ldyB2YWx1ZSBmb3IgdGhlIOKAnGNhdXNl4oCdIFVSSSBwYXJhbWV0ZXJzIGFuZCB0aGUg SGlzdG9yeS1JbmZvIGhlYWRlciBmaWVsZCBwYXJhbWV0ZXJzIGFzIHdhcyBkb25lDQogaW4gUkZD IDQ0NTggKHNlY3Rpb24gMykuJm5ic3A7IFlvdSBjb3VsZCBwcmVmYWNlIHRoaXMgZGlzY3Vzc2lv biB3aXRoIHRoZSB0d28gcGFyYWdyYXBocyB5b3UgaGFkIGluIHRoZSBpbnRybyB3aXRoIGJhY2tn cm91bmQgb24gUkZDIDQyNDQuIEluIHRoaXMgc2VjdGlvbiwgSSB3b3VsZCBleHBlY3QgdG8gc2Vl IHRoaW5ncyBsaWtlIHRoZSBmb2xsb3dpbmcgYWRkcmVzc2VkL2NsYXJpZmllZDogJm5ic3A7IGRv ZXMgdGhlIFVBUyBvbmx5IGxvb2sgZm9yIHRoZSDigJxjYXVzZeKAnQ0KIFVSSSBwYXJhbWV0ZXIg aWYgdGhlcmUgaXMgYW4g4oCcbXDigJ0gb3Ig4oCccmPigJ0gdGFnIG9yIGRvZXMgaXQgbG9vayBm b3IgdGhlIOKAnGNhdXNl4oCdIFVSSSBwYXJhbWV0ZXIgYW5kIHRoZW4gbG9vayBmb3Ig4oCcbXDi gJ0gYW5kIOKAnHJj4oCdIHRvIGtub3cgd2hldGhlciB0aGUgVUFTIG5lZWRzIHRvIHBlcmZvcm0g dGhhdCBzcGVjaWZpYyBzZXJ2aWNlLiZuYnNwOyBJdCBhbHNvIG5lZWRzIHRvIGJlIGNsZWFyLCBv ZiBjb3Vyc2UsIHRoYXQgdGhlIGVuZCBmdW5jdGlvbmFsaXR5IHlvdQ0KIGRlc2lyZSBtYXkgbm90 IGJlIGFjaGlldmFibGUgd2l0aG91dCB0aGUgSGlzdG9yeS1JbmZvIGhlYWRlciBzdWJzZXF1ZW50 bHkgYmVpbmcgYWRkZWQgdG8gdGhlIG1lc3NhZ2UgYW5kIE5PVCBiZWluZyByZW1vdmVkIGFsb25n IHRoZSB3YXkuICZuYnNwOyBBbHRob3VnaCwgSSB3b3VsZCB0aGluayB5b3VyIGFwcGxpY2F0aW9u IG91Z2h0IHRvIHdvcmsgYXMgZXhwZWN0ZWQgaWYgdGhhdCDigJxjYXVzZeKAnSBVUkkgcGFyYW1l dGVyIHZhbHVlIGlzIGluIHRoZSBSZXF1ZXN0LVVSSS4NCiAmbmJzcDsgUGVyIFJGQyA3MDQ0LCB5 b3Ugb3VnaHQgdG8gZGVzY3JpYmUgd2hhdCB3aWxsIGhhcHBlbiBpZiBhIEhpc3RvcnktSW5mbyBo ZWFkZXIgZmllbGQgd2l0aCBhIFJlcXVlc3QtVVJJIGNvbnRhaW5pbmcgdGhhdCB2YWx1ZSBmb3Ig dGhlIOKAnGNhdXNl4oCdIFVSSSBwYXJhbWV0ZXIgaXMgcmVtb3ZlZC4mbmJzcDsgJm5ic3A7PG86 cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3At YWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPk1pbm9yIGVkaXRvcmlhbCBjaGFu Z2VzOjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJn aW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj49PT09PT09PT09PT09 PT09PT09PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1h cmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjEpIEludHJvZHVj dGlvbiAtIDZ0aCBwYXJhZ3JhcGg6IEkgd291bGQgc3VnZ2VzdCBkZWxldGluZyB0aGF0IDJuZCBz ZW50ZW5jZSBhcyBJIHRoaW5rIG1hbnkgd291bGQgZGViYXRlIHdoZXRoZXIgdGhhdCBpbnRlbnRp b24gd2FzIGFjdHVhbGx5IHJlYWxpemVkIGJ5IHRoYXQgc3BlY2lmaWNhdGlvbi4gJm5ic3A7IFRo ZW4sDQogeW91IGxpa2VseSBzaG91bGQgYWRkIHRoYXQgcmVmZXJlbmNlIGF0IHRoZSBlbmQgb2Yg dGhlIGZpcnN0IHNlbnRlbmNlLiAmbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29O b3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1h bHQ6YXV0byI+MikgSeKAmW0gbm90IHN1cmUgdGhhdCBzZWN0aW9uIDIgKFByb2JsZW0gc3RhdGVt ZW50KSBhZGRzIG11Y2ggbW9yZSB0aGFuIHdoYXTigJlzIGluIHRoZSBJbnRyb2R1Y3Rpb24gKHdo aWNoIGluIHRoZSBlbmQgaXMgcmVhbGx5IG1vcmUgb2YgYW4gSW50cm9kdWN0aW9uIGFuZCBPdmVy dmlldykuJm5ic3A7IFNvLCB5b3UgY291bGQNCiBqdXN0IG1vdmUgdGhlIDJuZCBwYXJhZ3JhcGgg aW4gdGhpcyBzZWN0aW9uIHRvIHRoZSBlbmQgb2Ygc2VjdGlvbiAxIGFuZCBzdGF0ZSBkZWNsYXJh dGl2ZWx5LCBzb21ldGhpbmcgbGlrZSB0aGUgZm9sbG93aW5nICh1c2luZyDigJxhdCBsZWFzdOKA nSBpbXBsaWVzIHRoYXQgaXQgbWlnaHQgY292ZXIgb3RoZXIgdGhpbmdzIHdoaWNoIGJlZ3MgdGhl IHF1ZXN0aW9uIHdoYXQgZWxzZSBtaWdodCBpdCBjb3ZlciB1bmxlc3MgeW91IGFjdHVhbGx5Jm5i c3A7IGhhdmUNCiBzb21ldGhpbmcgaW4gbWluZCkgOjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90 dG9tLWFsdDphdXRvIj4mbmJzcDsgJm5ic3A7VGhlIG1lY2hhbmlzbSBjb3ZlcnMgdGhlIElOIHNl cnZpY2VzIHRoYXQgY2FuIGJlPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBz dHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8i PiZuYnNwOyZuYnNwOyBpZGVudGlmaWVkIGluIHRoZSBJU1VQIHNpZ25hbGluZyBpbiB0aGUgJnF1 b3Q7Y2FsbGVkIElOIG51bWJlciZxdW90OyBhbmQ8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRv bS1hbHQ6YXV0byI+Jm5ic3A7Jm5ic3A7ICZxdW90O29yaWdpbmFsIGNhbGxlZCBJTiBudW1iZXIm cXVvdDsgb3B0aW9uYWwgcGFyYW1ldGVycyBkZWZpbmVkIGluPG86cD48L286cD48L3A+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdp bi1ib3R0b20tYWx0OmF1dG8iPiZuYnNwOyZuYnNwOyBbSVRVLVRfUS43NjNdIGFuZCB1c2VkIGlu IElTVVAvSU5BUCBpbnRlcndvcmtpbmcgYXMgZGVzY3JpYmVkIGluPG86cD48L286cD48L3A+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1h cmdpbi1ib3R0b20tYWx0OmF1dG8iPiZuYnNwOyZuYnNwOyBbSVRVLVRfUS4xNjAwXS48bzpwPjwv bzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6 YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+RWRpdG9yaWFsIG5pdHM6Jm5ic3A7PG86 cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3At YWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPj09PT09PT09PT08bzpwPjwvbzpw PjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0 bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+MSkgSW50cm9kdWN0aW9uLCAzcmQgcGFyYWdy YXBoOjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJn aW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj4tIOKAnHNlcnZpY2Vz IGZvcm3igJ0gLSZndDsg4oCcc2VydmljZXMgZnJvbeKAnTxvOnA+PC9vOnA+PC9wPg0KPHAgY2xh c3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4t Ym90dG9tLWFsdDphdXRvIj4tIEV4cGFuZCB0aGUgYWNyb255bSBURE08bzpwPjwvbzpwPjwvcD4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28t bWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+MikgU2VjdGlvbiAzIC0gU29sdXRpb246PG86cD48L286 cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1 dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPi0gMXN0IHNlbnRlbmNlIHJlbW92ZSB0aGUg d29yZCDigJxhbHRlcm5hdGl2ZeKAnSZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1z b05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9t LWFsdDphdXRvIj4tIDJuZCBwYXJhZ3JhcGgsIDFzdCBzZW50ZW5jZTog4oCccmVtaW5kZWTigJ0g LSZndDsg4oCcc3VtbWFyaXplZOKAnSZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPGRpdj4NCjxibG9j a3F1b3RlIHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItbGVmdDpzb2xpZCAjQ0NDQ0NDIDEuMHB0 O3BhZGRpbmc6MGNtIDBjbSAwY20gNi4wcHQ7bWFyZ2luLWxlZnQ6NC44cHQ7bWFyZ2luLXJpZ2h0 OjBjbSI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvYmxv Y2txdW90ZT4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48 L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8UFJFPl9fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18KCkNlIG1lc3NhZ2UgZXQg c2VzIHBpZWNlcyBqb2ludGVzIHBldXZlbnQgY29udGVuaXIgZGVzIGluZm9ybWF0aW9ucyBjb25m aWRlbnRpZWxsZXMgb3UgcHJpdmlsZWdpZWVzIGV0IG5lIGRvaXZlbnQgZG9uYwpwYXMgZXRyZSBk aWZmdXNlcywgZXhwbG9pdGVzIG91IGNvcGllcyBzYW5zIGF1dG9yaXNhdGlvbi4gU2kgdm91cyBh dmV6IHJlY3UgY2UgbWVzc2FnZSBwYXIgZXJyZXVyLCB2ZXVpbGxleiBsZSBzaWduYWxlcgphIGwn ZXhwZWRpdGV1ciBldCBsZSBkZXRydWlyZSBhaW5zaSBxdWUgbGVzIHBpZWNlcyBqb2ludGVzLiBM ZXMgbWVzc2FnZXMgZWxlY3Ryb25pcXVlcyBldGFudCBzdXNjZXB0aWJsZXMgZCdhbHRlcmF0aW9u LApPcmFuZ2UgZGVjbGluZSB0b3V0ZSByZXNwb25zYWJpbGl0ZSBzaSBjZSBtZXNzYWdlIGEgZXRl IGFsdGVyZSwgZGVmb3JtZSBvdSBmYWxzaWZpZS4gTWVyY2kuCgpUaGlzIG1lc3NhZ2UgYW5kIGl0 cyBhdHRhY2htZW50cyBtYXkgY29udGFpbiBjb25maWRlbnRpYWwgb3IgcHJpdmlsZWdlZCBpbmZv cm1hdGlvbiB0aGF0IG1heSBiZSBwcm90ZWN0ZWQgYnkgbGF3Owp0aGV5IHNob3VsZCBub3QgYmUg ZGlzdHJpYnV0ZWQsIHVzZWQgb3IgY29waWVkIHdpdGhvdXQgYXV0aG9yaXNhdGlvbi4KSWYgeW91 IGhhdmUgcmVjZWl2ZWQgdGhpcyBlbWFpbCBpbiBlcnJvciwgcGxlYXNlIG5vdGlmeSB0aGUgc2Vu ZGVyIGFuZCBkZWxldGUgdGhpcyBtZXNzYWdlIGFuZCBpdHMgYXR0YWNobWVudHMuCkFzIGVtYWls cyBtYXkgYmUgYWx0ZXJlZCwgT3JhbmdlIGlzIG5vdCBsaWFibGUgZm9yIG1lc3NhZ2VzIHRoYXQg aGF2ZSBiZWVuIG1vZGlmaWVkLCBjaGFuZ2VkIG9yIGZhbHNpZmllZC4KVGhhbmsgeW91Lgo8L1BS RT48L2JvZHk+DQo8L2h0bWw+DQo= --_000_8B970F90C584EA4E97D5BAAC9172DBB814D255FEOPEXCLILM42corp_-- From nobody Tue Jun 2 08:56:10 2015 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AC4311AD094 for ; Tue, 2 Jun 2015 08:56:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.511 X-Spam-Level: X-Spam-Status: No, score=-14.511 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham 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 qp9KUnLwIaXc for ; Tue, 2 Jun 2015 08:56:06 -0700 (PDT) Received: from rcdn-iport-8.cisco.com (rcdn-iport-8.cisco.com [173.37.86.79]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B83831ACD0E for ; Tue, 2 Jun 2015 08:56:04 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=7748; q=dns/txt; s=iport; t=1433260564; x=1434470164; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=PM/PrMv1mgi0IqkQSxPk5pFCkueOHCHcGHbn/jjOptc=; b=kEiauLDTIhbbD/E2usMrnOtaTtNcPhV2r+kWqMhLssxH2SFmGN/B+5cW 7QbsTj7Yww3RIEl3ljI3HouPxVZ1XhEWyH/dvUuyk1wbgCgEwqSKexjMi XWm0rajKCu3Qw7zKPcmK6UIlV1aulA0dAMS4rNI4Y3/nITTRblFpfxq9z 8=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: A0DgBQDs0G1V/49dJa1bgxBUXgaCUka9JAqFLUoCHIEiTAEBAQEBAYELhCIBAQEEAQEBCRcROgsMAgICAQYCEQMBAgECAiMDAgICGQYGCxQBCAgCBAENBRuHfQMSDZkKnRmeaQ2FDQEBAQEBAQEBAQEBAQEBAQEBAQEBARMEBIEdiiKCTYIeGwcGgmKBRQWGa4wlhDaFBIFckDOHBSNhgSkcgVJvAYFFgQEBAQE X-IronPort-AV: E=Sophos;i="5.13,540,1427760000"; d="scan'208";a="16850509" Received: from rcdn-core-7.cisco.com ([173.37.93.143]) by rcdn-iport-8.cisco.com with ESMTP; 02 Jun 2015 15:56:02 +0000 Received: from xhc-rcd-x14.cisco.com (xhc-rcd-x14.cisco.com [173.37.183.88]) by rcdn-core-7.cisco.com (8.14.5/8.14.5) with ESMTP id t52Fu2fb020394 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Tue, 2 Jun 2015 15:56:02 GMT Received: from xmb-aln-x05.cisco.com ([169.254.11.78]) by xhc-rcd-x14.cisco.com ([173.37.183.88]) with mapi id 14.03.0195.001; Tue, 2 Jun 2015 10:56:02 -0500 From: "Ram Mohan R (rmohanr)" To: Magnus Westerlund , Mary Barnes , DISPATCH Thread-Topic: [dispatch] Updated PERC Charter proposal Thread-Index: AQHQnUyfWltY/wRomUKg84MUr9mBhg== Date: Tue, 2 Jun 2015 15:56:01 +0000 Message-ID: References: <55683230.3020600@ericsson.com> <556C2A44.8010805@ericsson.com> In-Reply-To: <556C2A44.8010805@ericsson.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.4.7.141117 x-originating-ip: [10.65.45.100] Content-Type: text/plain; charset="utf-8" Content-ID: <15167FFD79178A419AE7904340D6F474@emea.cisco.com> Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: Cc: Ben Campbell , Barry Leiba , Yaron Pdut , "Tirumaleswar Reddy \(tireddy\)" Subject: Re: [dispatch] Updated PERC Charter proposal X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 02 Jun 2015 15:56:08 -0000 VGhlIHByb3Bvc2VkIGNoYXJ0ZXIgbG9va3MgZ29vZC4NCg0KIE9uZSBxdWVzdGlvbiAtDQoNCkFz IGRlZmluZWQgaW4gU0lQUkVDIFdHIHJlcXVpcmVtZW50IGRvY3VtZW50IFJGQzYzNDEgcmVjb3Jk aW5nIG9mDQptdWx0aW1lZGlhIHNlc3Npb25zIGlzIGEgY3JpdGljYWwgcmVxdWlyZW1lbnQgaW4g bWFueSBidXNpbmVzcw0KICAgY29tbXVuaWNhdGlvbnMgZW52aXJvbm1lbnRzLCBzdWNoIGFzIGNh bGwgY2VudGVycyBhbmQgZmluYW5jaWFsIHRyYWRpbmcNCmZsb29ycy4gIE5vdGUgdGhhdCB0aGlz IGlzIGFjdGl2ZSByZWNvcmRpbmcgd2hlcmUgdGhlIHBhcnRpY2lwYW50cw0KT2YgdGhlIHNlc3Np b24gd2lsbCBiZSBpbmZvcm1lZCBhbmQgdGhleSBjYW4gY2hvb3NlIHRvIG5vdCBiZWluZyByZWNv cmRlZC4NCihsaWtlIFNJUFJFQyBXRyBoYXMgZGVmaW5lZCB0b2RheSkuDQoNCmlmIFBFUkMgYmFz ZWQgY29uZmVyZW5jaW5nIGlzIHVzZWQgaW4gc3VjaCBkZXBsb3ltZW50cywgd2Ugd291bGQgdGhl biBoYXZlDQphIHJlcXVpcmVtZW50IHRvIHJlY29yZCB0aG9zZSBzZXNzaW9ucy4NCg0KVGhpcyB3 b3VsZCBicmluZyBpbiBhIHJlcXVpcmVtZW50IHRvIHJlY29yZCBQRVJDIHNlc3Npb25zLiBXb3Vs ZCB0aGlzIGJlDQpyaWdodCBwbGFjZSB0byBhZGQgdGhpcyA/DQoNCnJlZ2FyZHMsDQpSYW0NCg0K DQotLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KRnJvbTogTWFnbnVzIFdlc3Rlcmx1bmQgPG1h Z251cy53ZXN0ZXJsdW5kQGVyaWNzc29uLmNvbT4NCkRhdGU6IE1vbmRheSwgMSBKdW5lIDIwMTUg MzoxNyBwbQ0KVG86IE1hcnkgQmFybmVzIDxtYXJ5LmlldGYuYmFybmVzQGdtYWlsLmNvbT4NCkNj OiBCZW4gQ2FtcGJlbGwgPGJlbkBub3N0cnVtLmNvbT4sIERJU1BBVENIIDxkaXNwYXRjaEBpZXRm Lm9yZz4sIEJhcnJ5DQpMZWliYSA8YmFycnlsZWliYUBjb21wdXRlci5vcmc+DQpTdWJqZWN0OiBS ZTogW2Rpc3BhdGNoXSBVcGRhdGVkIFBFUkMgQ2hhcnRlciBwcm9wb3NhbA0KDQo+SGksDQo+DQo+ SSBoYXZlIGVkaXRlZCB0aGUgcHJvcG9zZWQgY2hhbmdlIGludG8gdGhlIEdvb2dsZSBEb2MuIEFu eSBtb3JlIGZlZWRiYWNrDQo+b24gdGhpcz8NCj4NCj5DaGVlcnMNCj4NCj5NYWdudXMNCj4NCj5N YXJ5IEJhcm5lcyBza3JldiBkZW4gMjAxNS0wNS0yOSAxNjo1MzoNCj4+DQo+Pg0KPj4gT24gRnJp LCBNYXkgMjksIDIwMTUgYXQgNDozMiBBTSwgTWFnbnVzIFdlc3Rlcmx1bmQNCj4+IDxtYWdudXMu d2VzdGVybHVuZEBlcmljc3Nvbi5jb20gPG1haWx0bzptYWdudXMud2VzdGVybHVuZEBlcmljc3Nv bi5jb20+Pg0KPj4gd3JvdGU6DQo+Pg0KPj4gICAgIEhpLA0KPj4NCj4+ICAgICBJIGhvcGUgb3Ro ZXJzIGNhbiBjb21tZW50IG9uIHRoaXMgYWxzby4NCj4+DQo+PiAgICAgR8O2cmFuIEVyaWtzc29u IEFQIHNrcmV2IGRlbiAyMDE1LTA1LTI1IDE3OjEwOg0KPj4NCj4+ICAgICAgICAgSGksDQo+Pg0K Pj4gICAgICAgICBJIGhhdmUgc29tZSBtaW5vciBjb21tZW50cyBjb25jZXJuaW5nIHRoZSBtZWFu aW5nIG9mIMKzU0lQwrIgYW5kDQo+PiAgICAgICAgIMKzV2ViUlRDwrINCj4+ICAgICAgICAgZW5k cG9pbnRzLg0KPj4NCj4+ICAgICAgICAgU29ycnkgZm9yIHRoZSBsYXRlIHJlc3BvbnNlIGFuZCBm b3IgdG9wLXBvc3RpbmcgYnV0IGl0IGJlY2FtZSBhDQo+PiAgICAgICAgIGJpdCBtZXNzeQ0KPj4g ICAgICAgICB0byBhZGQgaW5saW5lOg0KPj4NCj4+ICAgICAgICAgMS4gVGhlIGxpbmsgdG8NCj4+ ICAgICAgICAgaHR0cHM6Ly9kYXRhdHJhY2tlci5pZXRmLm9yZy9kb2MvZHJhZnQtaWV0Zi1ydGN3 ZWItb3ZlcnZpZXcvIGRpZA0KPj4gICAgICAgICBub3Qgd29yaz8NCj4+DQo+Pg0KPj4gICAgIEl0 IHdvcmtzIGZpbmUgZm9yIG1lLg0KPj4NCj4+ICAgICAgICAgMi4gVGhlIHRleHQgdXNlcyDCs1NJ UMKyIGFuZCDCs1dlYlJUQ8KyIHRvIGRlc2NyaWJlIHRoZSBkaWZmZXJlbnQNCj4+ICAgICAgICAg a2luZCBvZg0KPj4gICAgICAgICBlbmQtcG9pbnRzIHRoYXQgYXJlIGluIHNjb3BlLg0KPj4gICAg ICAgICAgICAgIFczQyBXZWJSVEMgV0cgcmVjb2duaXNlcyB0aGUgZmFjdCB0aGF0IHRoZSBXZWJS VEMgZW5kDQo+PiAgICAgICAgIHBvaW50cyBjYW4gYmUNCj4+ICAgICAgICAgYnJvd3NlciBlbmQg cG9pbnRzDQo+PiAgICAgICAgICAgICAgKGJyb3dzZXIgKyB3ZWIgKGNsaWVudCBwb3J0aW9uIG9m KSB3ZWIgYXBwKSBvciBuYXRpdmUNCj4+ICAgICAgICAgV2ViUlRDIChvciByYXRoZXINCj4+ICAg ICAgICAgcnRjd2ViKSBjbGllbnRzIGFuZCBib3RoIGFyZSBpbiBzY29wZSBmb3IgdGhlIFczQyBX Ry4NCj4+ICAgICAgICAgICAgICBUaGUgYnJvd3NlciBlbmRwb2ludCB0cnVzdCBtb2RlbCBpcyBk aWZmZXJlbnQgZnJvbSB0aGF0IG9mDQo+PiAgICAgICAgIG5hdGl2ZQ0KPj4gICAgICAgICBjbGll bnRzIGFuZCBpdCBpcyBhbHNvIGV2b2x2aW5nLg0KPj4gICAgICAgICAgICAgIEkgdGhpbmsgdGhh dCBjbGFyaXR5IGluIGhvdyBkaWZmZXJlbnQgZW5kcG9pbnRzIHRydXN0DQo+Pm1vZGVsIGFuZA0K Pj4gICAgICAgICBzZWN1cml0eSBmcmFtZXdvcmsgbG9vayBsaWtlIGFuZCBkaWZmZXJlbnQgaXMg YmVuZWZpY2lhbCBmb3INCj4+ICAgICAgICAgc2V2ZXJhbCBvZg0KPj4gICAgICAgICB0aGUgZGVs aXZlcmFibGVzLCBub3RhYmx5IDIsMyBhbmQgNS4NCj4+DQo+Pg0KPj4gICAgIFRoZSB1c2Ugb2Yg V2ViUlRDIGVuZHBvaW50cyB3aGVyZSBkZWxpYmVyYXRlIGJ5IG15IGFuZCBpbnRlbmRlZCB0bw0K Pj4gICAgIGNvdmVyIG5vdCBvbmx5IGJyb3dzZXJzIGJ1dCBhbnl0aGluZyBtZWV0aW5nIHRoZSBX ZWJSVEMgZW5kcG9pbnQNCj4+ICAgICBkZWZpbml0aW9uLiBTbyB0aGUgcXVlc3Rpb24sIGRvZXMg dGhpcyBuZWVkIHRvIGJlIG1hZGUgbW9yZSBleHBsaWNpdA0KPj4gICAgIGluIHRoZSBjaGFydGVy Pw0KPj4NCj4+IFtNQl0gSSB0aGluayB0aGlzIGlzIGZpbmUgYXMgaXMgaW4gdGhlIGNoYXJ0ZXIg LSBjZXJ0YWlubHkgaXQgbmVlZHMgdG8NCj4+IGJlIGNsZWFyIGluIHRoZSBkZWxpdmVyYWJsZXMg YnV0IHRoYXQncyBhIGRldGFpbCB3ZSBjYW4gZGVhbCB3aXRoIHRoZXJlLg0KPj4gWy9NQl0NCj4+ DQo+Pg0KPj4NCj4+DQo+PiAgICAgICAgIDMuIFRoZSBjaGFydGVyIHNheXMgaXQgd2lsbCDCs25v dGlmecKyIFczQyBXZWJSVEMgYWJvdXQgdGhpcw0KPj4gICAgICAgICBhY3Rpdml0eTsgd2hhdA0K Pj4gICAgICAgICBkbyB0aGUgV0cgZXhwZWN0IHRvIGdldCBiYWNrIGFuZCB3aHkgbm90IMWSY29v cmRpbmF0ZcK5PyBBbmQgYXJlDQo+PiAgICAgICAgIHRoZXJlIG90aGVyDQo+PiAgICAgICAgIFcz QyBXR8K5cyB0aGF0IGFyZSByZWxldmFudD8NCj4+DQo+Pg0KPj4gICAgIEkgdGhpbmsgdGhlIGV4 cGVjdGF0aW9uIGlzIHRoYXQgaW4gdGhlIGVuZCBXM0MgYW5kIGxpa2VseSBSVENXRUIgV0cNCj4+ ICAgICBhZ3JlZXMgdG8gaW50ZWdyYXRlIHRoZSBQRVJDIHNvbHV0aW9uIGludG8gdGhlaXIgc3Bl Y2lmaWNhdGlvbnMgc28NCj4+ICAgICB0aGF0IG9uZSBjYW4gYWN0dWFsbHkgdXNlIGl0IHdpdGgg V2ViUlRDLiBJbiBpbnRlcm1lZGlhdGUgc3RlcCBJDQo+PiAgICAgdGhpbmsgaXQgd2lsbCBiZSBh IHF1ZXN0aW9uIG9mIG5vdGlmeWluZyBmb3IgZXhhbXBsZSB3aGVuIHRoZXJlDQo+PiAgICAgZXhp c3QgYSBwcm9wb3NlZCBibHVlLXByaW50IGZvciBpbnRlZ3JhdGlvbi4gVGhpcyBtYXkgYmUgYW4g ZXhhbXBsZQ0KPj4gICAgIG9mIHdoZXJlIGNvb3JkaW5hdGUgbWlnaHQgYmUgbmVlZGVkLg0KPj4N Cj4+ICAgICBJIGNvdWxkIHNlZSB0aGF0IHdlIGNvdWxkIGNoYW5nZSB0aGUgbGFzdCBzZW50ZW5j ZSBpbiB0aGUNCj4+ICAgICBjb2xsYWJvcmF0aW9uIHBhcnQgZnJvbToNCj4+ICAgICAiV2Ugd2ls bCBub3RpZnkgQVZUQ29yZSwgQ0xVRSwgTU1VU0lDLCBSVENXRUIsIFNJUFJFQywgVzNDIFdlYlJU QywNCj4+ICAgICBhbmQgb3RoZXIgcmVsYXRlZCBncm91cHMgYWJvdXQgdGhpcyB3b3JrLiINCj4+ DQo+PiAgICAgdG8NCj4+ICAgICAiV2Ugd2lsbCBub3RpZnksIGFuZCB3aGVuIG5lZWRlZCBjb29y ZGluYXRlIHdpdGgsIEFWVENvcmUsIENMVUUsDQo+PiAgICAgTU1VU0lDLCBSVENXRUIsIFNJUFJF QywgVzNDIFdlYlJUQywgYW5kIG90aGVyIHJlbGF0ZWQgZ3JvdXBzIGFib3V0DQo+PiAgICAgdGhp cyB3b3JrLiINCj4+DQo+PiAgICAgT3BpbmlvbnM/DQo+Pg0KPj4gW01CXSBJIHRoaW5rIHRoZSBz dWdnZXN0ZWQgY2hhbmdlIGlzIGZpbmUuIFsvTUJdDQo+Pg0KPj4NCj4+ICAgICBDaGVlcnMNCj4+ DQo+PiAgICAgTWFnbnVzIFdlc3Rlcmx1bmQNCj4+DQo+PiAgICAgDQo+Pi0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0N Cj4+ICAgICBTZXJ2aWNlcywgTWVkaWEgYW5kIE5ldHdvcmsgZmVhdHVyZXMsIEVyaWNzc29uIFJl c2VhcmNoIEVBQi9UWE0NCj4+ICAgICANCj4+LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLQ0KPj4gICAgIEVyaWNzc29u IEFCICAgICAgICAgICAgICAgICB8IFBob25lICs0NiAxMCA3MTQ4Mjg3DQo+PiAgICAgPHRlbDol MkI0NiUyMDEwJTIwNzE0ODI4Nz4NCj4+ICAgICBGw6Ryw7ZnYXRhbiA2ICAgICAgICAgICAgICAg ICB8IE1vYmlsZSArNDYgNzMgMDk0OTA3OQ0KPj4gICAgIDx0ZWw6JTJCNDYlMjA3MyUyMDA5NDkw Nzk+DQo+PiAgICAgU0UtMTY0IDgwIFN0b2NraG9sbSwgU3dlZGVuIHwgbWFpbHRvOiBtYWdudXMu d2VzdGVybHVuZEBlcmljc3Nvbi5jb20NCj4+ICAgICA8bWFpbHRvOm1hZ251cy53ZXN0ZXJsdW5k QGVyaWNzc29uLmNvbT4NCj4+ICAgICANCj4+LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLQ0KPj4NCj4+DQo+DQo+DQo+ LS0gDQo+DQo+TWFnbnVzIFdlc3Rlcmx1bmQNCj4NCj4tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tDQo+U2VydmljZXMs IE1lZGlhIGFuZCBOZXR3b3JrIGZlYXR1cmVzLCBFcmljc3NvbiBSZXNlYXJjaCBFQUIvVFhNDQo+ LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLQ0KPkVyaWNzc29uIEFCICAgICAgICAgICAgICAgICB8IFBob25lICArNDYg MTAgNzE0ODI4Nw0KPkbDpHLDtmdhdGFuIDYgICAgICAgICAgICAgICAgIHwgTW9iaWxlICs0NiA3 MyAwOTQ5MDc5DQo+U0UtMTY0IDgwIFN0b2NraG9sbSwgU3dlZGVuIHwgbWFpbHRvOiBtYWdudXMu d2VzdGVybHVuZEBlcmljc3Nvbi5jb20NCj4tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tDQo+DQo+X19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCj5kaXNwYXRjaCBtYWlsaW5nIGxp c3QNCj5kaXNwYXRjaEBpZXRmLm9yZw0KPmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlz dGluZm8vZGlzcGF0Y2gNCg0K From nobody Tue Jun 2 09:22:56 2015 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8E7C91B2ABF for ; Tue, 2 Jun 2015 09:22:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.977 X-Spam-Level: X-Spam-Status: No, score=-1.977 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham 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 msMy-ZNdr9vx for ; Tue, 2 Jun 2015 09:22:47 -0700 (PDT) Received: from mail-wg0-f42.google.com (mail-wg0-f42.google.com [74.125.82.42]) (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 B14201B2EA7 for ; Tue, 2 Jun 2015 09:22:22 -0700 (PDT) Received: by wgez8 with SMTP id z8so144454231wge.0 for ; Tue, 02 Jun 2015 09:22:21 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type; bh=8p2hWwCdCrdNyvxBehchgNp8dWmm1FBivYw+2EAkR3o=; b=SGu/E7N9Gjcmqz5AKtJGxDKd19tgKanV/Cn4oVXvj4kNCMQNYiOjW6mUn1FSULWsej F2BpY621fB6wa7Mw33HG8uOzemgFcV7BkNamoQpcLeBIxjiC6sfzQ3mrc/50mu7XHr83 JApybh6Oxia06GJ62hKisKb2UOnsCFZkShngIkL9wy8wagVic/4JpL/HdSwBcmmit9co APwhEQIFej142nS+fw9D9oLRW2+fWOWFQd4p5foY1CvGyQ1XtXsNTDzdHQLoiTGaNxRv GfjW65Vka4EFzaLZ1w4CHyRsa8eogKCiaci1LBNO2X1bqx8fgizLQCMNyJ8xnl3eyKOi mIgw== X-Gm-Message-State: ALoCoQmG37VZNq/tAC4KvdJr8Vxn+Teq4ZNILa/WPv61jkPfKgPm9FiaZ5ORGHhQ8YmKZvYug08r X-Received: by 10.180.73.176 with SMTP id m16mr33363407wiv.68.1433262141418; Tue, 02 Jun 2015 09:22:21 -0700 (PDT) MIME-Version: 1.0 Received: by 10.27.225.14 with HTTP; Tue, 2 Jun 2015 09:21:40 -0700 (PDT) In-Reply-To: References: <55683230.3020600@ericsson.com> <556C2A44.8010805@ericsson.com> From: Eric Rescorla Date: Tue, 2 Jun 2015 09:21:40 -0700 Message-ID: To: "Ram Mohan R (rmohanr)" Content-Type: multipart/alternative; boundary=f46d043c7e58cf40a705178b589a Archived-At: Cc: DISPATCH , Ben Campbell , "Tirumaleswar Reddy \(tireddy\)" , Yaron Pdut , Barry Leiba Subject: Re: [dispatch] Updated PERC Charter proposal X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 02 Jun 2015 16:22:54 -0000 --f46d043c7e58cf40a705178b589a Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On Tue, Jun 2, 2015 at 8:56 AM, Ram Mohan R (rmohanr) wrote: > The proposed charter looks good. > > One question - > > As defined in SIPREC WG requirement document RFC6341 recording of > multimedia sessions is a critical requirement in many business > communications environments, such as call centers and financial tradin= g > floors. Note that this is active recording where the participants > Of the session will be informed and they can choose to not being recorded= . > (like SIPREC WG has defined today). > > if PERC based conferencing is used in such deployments, we would then hav= e > a requirement to record those sessions. > > This would bring in a requirement to record PERC sessions. Would this be > right place to add this ? > I don't agree that there is a requirement to add this. The way you record PERC sessions is by bringing them into the call at the signaling level. There's no PERC-level accommodation needed. -Ekr > regards, > Ram > > > -----Original Message----- > From: Magnus Westerlund > Date: Monday, 1 June 2015 3:17 pm > To: Mary Barnes > Cc: Ben Campbell , DISPATCH , Barry > Leiba > Subject: Re: [dispatch] Updated PERC Charter proposal > > >Hi, > > > >I have edited the proposed change into the Google Doc. Any more feedback > >on this? > > > >Cheers > > > >Magnus > > > >Mary Barnes skrev den 2015-05-29 16:53: > >> > >> > >> On Fri, May 29, 2015 at 4:32 AM, Magnus Westerlund > >> >> > >> wrote: > >> > >> Hi, > >> > >> I hope others can comment on this also. > >> > >> G=C3=B6ran Eriksson AP skrev den 2015-05-25 17:10: > >> > >> Hi, > >> > >> I have some minor comments concerning the meaning of =C2=B3SIP= =C2=B2 and > >> =C2=B3WebRTC=C2=B2 > >> endpoints. > >> > >> Sorry for the late response and for top-posting but it became = a > >> bit messy > >> to add inline: > >> > >> 1. The link to > >> https://datatracker.ietf.org/doc/draft-ietf-rtcweb-overview/ > did > >> not work? > >> > >> > >> It works fine for me. > >> > >> 2. The text uses =C2=B3SIP=C2=B2 and =C2=B3WebRTC=C2=B2 to des= cribe the different > >> kind of > >> end-points that are in scope. > >> W3C WebRTC WG recognises the fact that the WebRTC end > >> points can be > >> browser end points > >> (browser + web (client portion of) web app) or native > >> WebRTC (or rather > >> rtcweb) clients and both are in scope for the W3C WG. > >> The browser endpoint trust model is different from that o= f > >> native > >> clients and it is also evolving. > >> I think that clarity in how different endpoints trust > >>model and > >> security framework look like and different is beneficial for > >> several of > >> the deliverables, notably 2,3 and 5. > >> > >> > >> The use of WebRTC endpoints where deliberate by my and intended to > >> cover not only browsers but anything meeting the WebRTC endpoint > >> definition. So the question, does this need to be made more explic= it > >> in the charter? > >> > >> [MB] I think this is fine as is in the charter - certainly it needs to > >> be clear in the deliverables but that's a detail we can deal with ther= e. > >> [/MB] > >> > >> > >> > >> > >> 3. The charter says it will =C2=B3notify=C2=B2 W3C WebRTC abou= t this > >> activity; what > >> do the WG expect to get back and why not =C5=92coordinate=C2= =B9? And are > >> there other > >> W3C WG=C2=B9s that are relevant? > >> > >> > >> I think the expectation is that in the end W3C and likely RTCWEB W= G > >> agrees to integrate the PERC solution into their specifications so > >> that one can actually use it with WebRTC. In intermediate step I > >> think it will be a question of notifying for example when there > >> exist a proposed blue-print for integration. This may be an exampl= e > >> of where coordinate might be needed. > >> > >> I could see that we could change the last sentence in the > >> collaboration part from: > >> "We will notify AVTCore, CLUE, MMUSIC, RTCWEB, SIPREC, W3C WebRTC, > >> and other related groups about this work." > >> > >> to > >> "We will notify, and when needed coordinate with, AVTCore, CLUE, > >> MMUSIC, RTCWEB, SIPREC, W3C WebRTC, and other related groups about > >> this work." > >> > >> Opinions? > >> > >> [MB] I think the suggested change is fine. [/MB] > >> > >> > >> Cheers > >> > >> Magnus Westerlund > >> > >> > >>---------------------------------------------------------------------- > >> Services, Media and Network features, Ericsson Research EAB/TXM > >> > >>---------------------------------------------------------------------- > >> Ericsson AB | Phone +46 10 7148287 > >> > >> F=C3=A4r=C3=B6gatan 6 | Mobile +46 73 0949079 > >> > >> SE-164 80 Stockholm, Sweden | mailto: > magnus.westerlund@ericsson.com > >> > >> > >>---------------------------------------------------------------------- > >> > >> > > > > > >-- > > > >Magnus Westerlund > > > >---------------------------------------------------------------------- > >Services, Media and Network features, Ericsson Research EAB/TXM > >---------------------------------------------------------------------- > >Ericsson AB | Phone +46 10 7148287 > >F=C3=A4r=C3=B6gatan 6 | Mobile +46 73 0949079 > >SE-164 80 Stockholm, Sweden | mailto: magnus.westerlund@ericsson.com > >---------------------------------------------------------------------- > > > >_______________________________________________ > >dispatch mailing list > >dispatch@ietf.org > >https://www.ietf.org/mailman/listinfo/dispatch > > _______________________________________________ > dispatch mailing list > dispatch@ietf.org > https://www.ietf.org/mailman/listinfo/dispatch > --f46d043c7e58cf40a705178b589a Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


On Tue, Jun 2, 2015 at 8:56 AM, Ram Mohan R (rmohanr) <rmohanr@cisco.c= om> wrote:
The proposed cha= rter looks good.

=C2=A0One question -

As defined in SIPREC WG requirement document RFC6341 recording of
multimedia sessions is a critical requirement in many business
=C2=A0 =C2=A0communications environments, such as call centers and financia= l trading
floors.=C2=A0 Note that this is active recording where the participants
Of the session will be informed and they can choose to not being recorded.<= br> (like SIPREC WG has defined today).

if PERC based conferencing is used in such deployments, we would then have<= br> a requirement to record those sessions.

This would bring in a requirement to record PERC sessions. Would this be right place to add this ?

I don't a= gree that there is a requirement to add this.

The = way you record PERC sessions is by bringing them into the call at
the signaling level. There's no PERC-level accommodation needed.
=

-Ekr
=C2=A0
regards,
Ram


-----Original Message-----
From: Magnus Westerlund <magnus.westerlund@ericsson.com>
Date: Monday, 1 June 2015 3:17 pm
To: Mary Barnes <mary.ietf= .barnes@gmail.com>
Cc: Ben Campbell <ben@nostrum.com= >, DISPATCH <dispatch@ietf.org>, Barry
Leiba <barryleiba@computer.or= g>
Subject: Re: [dispatch] Updated PERC Charter proposal

>Hi,
>
>I have edited the proposed change into the Google Doc. Any more feedbac= k
>on this?
>
>Cheers
>
>Magnus
>
>Mary Barnes skrev den 2015-05-29 16:53:
>>
>>
>> On Fri, May 29, 2015 at 4:32 AM, Magnus Westerlund
>> <magnus.weste= rlund@ericsson.com <mailto:magnus.westerlund@ericsson.com>>
>> wrote:
>>
>>=C2=A0 =C2=A0 =C2=A0Hi,
>>
>>=C2=A0 =C2=A0 =C2=A0I hope others can comment on this also.
>>
>>=C2=A0 =C2=A0 =C2=A0G=C3=B6ran Eriksson AP skrev den 2015-05-25 17:= 10:
>>
>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Hi,
>>
>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0I have some minor comments concer= ning the meaning of =C2=B3SIP=C2=B2 and
>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0=C2=B3WebRTC=C2=B2
>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0endpoints.
>>
>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Sorry for the late response and f= or top-posting but it became a
>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0bit messy
>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0to add inline:
>>
>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A01. The link to
>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0https://datatrack= er.ietf.org/doc/draft-ietf-rtcweb-overview/ did
>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0not work?
>>
>>
>>=C2=A0 =C2=A0 =C2=A0It works fine for me.
>>
>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A02. The text uses =C2=B3SIP=C2=B2 = and =C2=B3WebRTC=C2=B2 to describe the different
>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0kind of
>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0end-points that are in scope.
>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 W3C WebRTC WG reco= gnises the fact that the WebRTC end
>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0points can be
>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0browser end points
>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 (browser + web (cl= ient portion of) web app) or native
>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0WebRTC (or rather
>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0rtcweb) clients and both are in s= cope for the W3C WG.
>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 The browser endpoi= nt trust model is different from that of
>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0native
>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0clients and it is also evolving.<= br> >>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 I think that clari= ty in how different endpoints trust
>>model and
>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0security framework look like and = different is beneficial for
>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0several of
>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0the deliverables, notably 2,3 and= 5.
>>
>>
>>=C2=A0 =C2=A0 =C2=A0The use of WebRTC endpoints where deliberate by= my and intended to
>>=C2=A0 =C2=A0 =C2=A0cover not only browsers but anything meeting th= e WebRTC endpoint
>>=C2=A0 =C2=A0 =C2=A0definition. So the question, does this need to = be made more explicit
>>=C2=A0 =C2=A0 =C2=A0in the charter?
>>
>> [MB] I think this is fine as is in the charter - certainly it need= s to
>> be clear in the deliverables but that's a detail we can deal w= ith there.
>> [/MB]
>>
>>
>>
>>
>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A03. The charter says it will =C2= =B3notify=C2=B2 W3C WebRTC about this
>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0activity; what
>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0do the WG expect to get back and = why not =C5=92coordinate=C2=B9? And are
>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0there other
>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0W3C WG=C2=B9s that are relevant?<= br> >>
>>
>>=C2=A0 =C2=A0 =C2=A0I think the expectation is that in the end W3C = and likely RTCWEB WG
>>=C2=A0 =C2=A0 =C2=A0agrees to integrate the PERC solution into thei= r specifications so
>>=C2=A0 =C2=A0 =C2=A0that one can actually use it with WebRTC. In in= termediate step I
>>=C2=A0 =C2=A0 =C2=A0think it will be a question of notifying for ex= ample when there
>>=C2=A0 =C2=A0 =C2=A0exist a proposed blue-print for integration. Th= is may be an example
>>=C2=A0 =C2=A0 =C2=A0of where coordinate might be needed.
>>
>>=C2=A0 =C2=A0 =C2=A0I could see that we could change the last sente= nce in the
>>=C2=A0 =C2=A0 =C2=A0collaboration part from:
>>=C2=A0 =C2=A0 =C2=A0"We will notify AVTCore, CLUE, MMUSIC, RTC= WEB, SIPREC, W3C WebRTC,
>>=C2=A0 =C2=A0 =C2=A0and other related groups about this work."=
>>
>>=C2=A0 =C2=A0 =C2=A0to
>>=C2=A0 =C2=A0 =C2=A0"We will notify, and when needed coordinat= e with, AVTCore, CLUE,
>>=C2=A0 =C2=A0 =C2=A0MMUSIC, RTCWEB, SIPREC, W3C WebRTC, and other r= elated groups about
>>=C2=A0 =C2=A0 =C2=A0this work."
>>
>>=C2=A0 =C2=A0 =C2=A0Opinions?
>>
>> [MB] I think the suggested change is fine. [/MB]
>>
>>
>>=C2=A0 =C2=A0 =C2=A0Cheers
>>
>>=C2=A0 =C2=A0 =C2=A0Magnus Westerlund
>>
>>
>>-------------------------------------------------------------------= ---
>>=C2=A0 =C2=A0 =C2=A0Services, Media and Network features, Ericsson = Research EAB/TXM
>>
>>-------------------------------------------------------------------= ---
>>=C2=A0 =C2=A0 =C2=A0Ericsson AB=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0| Phone +46 10 7148287
>>=C2=A0 =C2=A0 =C2=A0<tel:%2B46%2010%207148287>
>>=C2=A0 =C2=A0 =C2=A0F=C3=A4r=C3=B6gatan 6=C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0| Mobile +46 73 0949079
>>=C2=A0 =C2=A0 =C2=A0<tel:%2B46%2073%200949079>
>>=C2=A0 =C2=A0 =C2=A0SE-164 80 Stockholm, Sweden | mailto: magnus.westerlund@ericsson.com
>>=C2=A0 =C2=A0 =C2=A0<mailto:magnus.westerlund@ericsson.com>
>>
>>-------------------------------------------------------------------= ---
>>
>>
>
>
>--
>
>Magnus Westerlund
>
>----------------------------------------------------------------------<= br> >Services, Media and Network features, Ericsson Research EAB/TXM
>----------------------------------------------------------------------<= br> >Ericsson AB=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0| Phone=C2=A0 +46 10 7148287
>F=C3=A4r=C3=B6gatan 6=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0| Mobile +46 73 0949079
>SE-164 80 Stockholm, Sweden | mailto: magnus.westerlund@ericsson.com
>----------------------------------------------------------------------<= br> >
>_______________________________________________
>dispatch mailing list
>dispatch@ietf.org
>https://www.ietf.org/mailman/listinfo/dispatch

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

--f46d043c7e58cf40a705178b589a-- From nobody Tue Jun 2 09:38:41 2015 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 568811B2CA8 for ; Tue, 2 Jun 2015 09:38:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.601 X-Spam-Level: X-Spam-Status: No, score=-2.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham 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 aAFDp4c0Dqg4 for ; Tue, 2 Jun 2015 09:38:39 -0700 (PDT) Received: from mail-ig0-f182.google.com (mail-ig0-f182.google.com [209.85.213.182]) (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 E572D1B2C24 for ; Tue, 2 Jun 2015 09:38:38 -0700 (PDT) Received: by igblz2 with SMTP id lz2so15297635igb.1 for ; Tue, 02 Jun 2015 09:38:38 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:message-id:date:from:user-agent:mime-version:to :cc:subject:references:in-reply-to:content-type :content-transfer-encoding; bh=Z0gYxqI1BLadM3pA5SYJbst/7x6umBWoMNdoXpf6P1g=; b=TvZN1fsfs648qLTBrapQFGFzlEcStyqqYvODze19cC8JS+YH5k/oeGFZDc5yPdff8G Ic83IYYZshID2CHlDFRozFtUPG0TR+vJ9Dyow+L5jFfjLGV6zFKhhCP25EWv9r7+iTdQ 4nor9NibLjdy/MEmaEHl6AJEHJSAHhqijNfE374iFrz4yAO++5z5+nReFz5QvtJx7DCw WQAbe3hx3u5ej1PK8bAtTUIdZ98vc7fxcSNr5Kyjw0E2jTtovGTAqzgFdOV7G9YeLpo7 JJ767bcgx7PJPzKYC3GQu2FzoG28kOIAG3cEPv3l2jqlKlyp3c/2gw4uqmFpMrsXnAHF OFgQ== X-Gm-Message-State: ALoCoQmw/wDIslNjJDZqK+pNiv7Y1npusTaJty7S/A0p6cmvQxsm5t43u4IXLBJ+cMOqTKAca1R3 X-Received: by 10.43.148.72 with SMTP id kf8mr36423510icc.76.1433263118408; Tue, 02 Jun 2015 09:38:38 -0700 (PDT) Received: from aither.local (c-73-34-202-214.hsd1.co.comcast.net. [73.34.202.214]) by mx.google.com with ESMTPSA id d4sm10287333igl.1.2015.06.02.09.38.36 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 02 Jun 2015 09:38:37 -0700 (PDT) Message-ID: <556DDC0C.3010107@andyet.net> Date: Tue, 02 Jun 2015 10:38:36 -0600 From: Peter Saint-Andre - &yet User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:31.0) Gecko/20100101 Thunderbird/31.7.0 MIME-Version: 1.0 To: Eric Rescorla References: <55683230.3020600@ericsson.com> <556C2A44.8010805@ericsson.com> In-Reply-To: Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Cc: Ben Campbell , DISPATCH , Yaron Pdut , "Tirumaleswar Reddy \(tireddy\)" , Barry Leiba Subject: Re: [dispatch] Updated PERC Charter proposal X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 02 Jun 2015 16:38:40 -0000 On 6/2/15 10:21 AM, Eric Rescorla wrote: > The way you record PERC sessions is by bringing them into the call at > the signaling level. There's no PERC-level accommodation needed. Who is "them"? Do you mean "recording resources" of some kind would be added as participants to the call? Just trying to clarify the model... Peter -- Peter Saint-Andre https://andyet.com/ From nobody Tue Jun 2 09:41:10 2015 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E50061AC406 for ; Tue, 2 Jun 2015 09:41:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.977 X-Spam-Level: X-Spam-Status: No, score=-1.977 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham 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 SRDfQMM77-oI for ; Tue, 2 Jun 2015 09:41:08 -0700 (PDT) Received: from mail-wi0-f182.google.com (mail-wi0-f182.google.com [209.85.212.182]) (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 963E91AC3D2 for ; Tue, 2 Jun 2015 09:41:07 -0700 (PDT) Received: by wikd7 with SMTP id d7so19339938wik.0 for ; Tue, 02 Jun 2015 09:41:06 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type; bh=jl0+Zp/j5zRCf6NIkYFV0+kmtFdq0OqBrcxOVMufheE=; b=C0ievnsz0gNQyhsoZG3O5cDIH1EZZtwWiad0C2mwO2+UvBfgHQI11hOrRzfNgnb9Zh VMb2DMr1T12Y8MG7g6aoV11L4+dRqi5Y6NTNPBppUM1QbPv14PI4kPz0rFCmx8S3E7Pm UXoZZyrow4rIVag5qS977Yg9BBJwws+cDjcYIKUgz57B4+GttyH/tdwE5mCrF2oqATc+ vRyfAd4O3M1Wh7g2UO/v0aCOApOZcSeCIAA6Z7HCsUazKGWBF+j9UOH3jD+C/68JhBtY uDZaPAplhv7lZF2r4RAuJhcHARqKLzawtAvwkm5UMW8QNOSWQJtWD04tTH8LoGpq0bmm SXtg== X-Gm-Message-State: ALoCoQk3cfO4lhY2/McTB5vcd0Ic2fiuSle0rJhksmTG2AHDhGtB/T4iLR60COJa+Hj21Q4F0c4E X-Received: by 10.194.59.79 with SMTP id x15mr35510021wjq.81.1433263266362; Tue, 02 Jun 2015 09:41:06 -0700 (PDT) MIME-Version: 1.0 Received: by 10.27.225.14 with HTTP; Tue, 2 Jun 2015 09:40:25 -0700 (PDT) In-Reply-To: <556DDC0C.3010107@andyet.net> References: <55683230.3020600@ericsson.com> <556C2A44.8010805@ericsson.com> <556DDC0C.3010107@andyet.net> From: Eric Rescorla Date: Tue, 2 Jun 2015 09:40:25 -0700 Message-ID: To: "Peter Saint-Andre - &yet" Content-Type: multipart/alternative; boundary=047d7b8737aedc89e705178b9bc7 Archived-At: Cc: Ben Campbell , DISPATCH , Yaron Pdut , "Tirumaleswar Reddy \(tireddy\)" , Barry Leiba Subject: Re: [dispatch] Updated PERC Charter proposal X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 02 Jun 2015 16:41:09 -0000 --047d7b8737aedc89e705178b9bc7 Content-Type: text/plain; charset=UTF-8 On Tue, Jun 2, 2015 at 9:38 AM, Peter Saint-Andre - &yet wrote: > On 6/2/15 10:21 AM, Eric Rescorla wrote: > > The way you record PERC sessions is by bringing them into the call at >> the signaling level. There's no PERC-level accommodation needed. >> > > Who is "them"? Do you mean "recording resources" of some kind would be > added as participants to the call? Just trying to clarify the model... Yes. -Ekr --047d7b8737aedc89e705178b9bc7 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


On Tue, Jun 2, 2015 at 9:38 AM, Peter Saint-Andre - &yet <peter@an= dyet.net> wrote:
On 6/2/15 10:21 AM, Eric Rescorla wrote:

The way you record PERC sessions is by bringing them into the call at
the signaling level. There's no PERC-level accommodation needed.

 Who is "them"? Do you mean "recording resources" of som= e kind would be added as participants to the call? Just trying to clarify t= he model...

Yes.

-= Ekr


--047d7b8737aedc89e705178b9bc7-- From nobody Tue Jun 2 11:38:52 2015 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 54AEC1A1B84 for ; Tue, 2 Jun 2015 11:38:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.235 X-Spam-Level: X-Spam-Status: No, score=-1.235 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, SPF_SOFTFAIL=0.665] autolearn=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 oRPu90oyD0bF for ; Tue, 2 Jun 2015 11:38:50 -0700 (PDT) Received: from resqmta-ch2-11v.sys.comcast.net (resqmta-ch2-11v.sys.comcast.net [IPv6:2001:558:fe21:29:69:252:207:43]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0E88C1A1B60 for ; Tue, 2 Jun 2015 11:38:49 -0700 (PDT) Received: from resomta-ch2-16v.sys.comcast.net ([69.252.207.112]) by resqmta-ch2-11v.sys.comcast.net with comcast id bWcZ1q0032S2Q5R01WepKo; Tue, 02 Jun 2015 18:38:49 +0000 Received: from Paul-Kyzivats-MacBook-Pro.local ([50.138.229.151]) by resomta-ch2-16v.sys.comcast.net with comcast id bWeo1q00Y3Ge9ey01Weoez; Tue, 02 Jun 2015 18:38:49 +0000 Message-ID: <556DF837.8050704@alum.mit.edu> Date: Tue, 02 Jun 2015 14:38:47 -0400 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:31.0) Gecko/20100101 Thunderbird/31.7.0 MIME-Version: 1.0 To: dispatch@ietf.org References: <55683230.3020600@ericsson.com> <556C2A44.8010805@ericsson.com> <556DDC0C.3010107@andyet.net> In-Reply-To: Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=q20140121; t=1433270329; bh=Bw3ExQ4kuTzGVS+8h+vdvq6JsmbF8QBzef8/nxJtjyY=; h=Received:Received:Message-ID:Date:From:MIME-Version:To:Subject: Content-Type; b=aYPaP8O5ZNxQ+ShQnjM1VJSkXmngcR+ccFlDLcYp+XN9ldHYB/NLyo3eB7TlmeKYa 6bVIKWwAr0MEaXYSOKA/TniEOwRKgi+g+BetN6C5lw1APgviauUgdYLgcGKNT7slJR SjCZcFIjdp+6bj7l8dYGEekYeHCTtmIWzbBJwEF4Rp91uRqDgrvk6V1NafYTff3Rh1 D+HUzppE1OW9wp1Ge7A28ppz312mqf+3bKFRGsyssAQINTIGY6BvHDMgqzuRulflCD gpwfz3zyrvJmGJt2bBaW1491pU2OsJUzrZpQOigMkoZjMG3CI3zVhvD5nwsOMkvoqQ 8vAbAE8KYKukA== Archived-At: Subject: Re: [dispatch] Updated PERC Charter proposal X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 02 Jun 2015 18:38:51 -0000 At some level this would "work", but it might require rethinking the whole approach to recording in an enterprise where recording is an important part of the business. IIUC, with PERC there is still likely to be a conference focus, for signaling, much as without PERC. But the details of how the media is handled will be different. Such a focus could automatically bring in a recorder as a participant. That is already one of the models covered by siprec. But PERC would prevent the focus and the PERC 'mixer" from directly serving as the SRC. Thanks, Paul As long as PERC conferences are On 6/2/15 12:40 PM, Eric Rescorla wrote: > > > On Tue, Jun 2, 2015 at 9:38 AM, Peter Saint-Andre - &yet > > wrote: > > On 6/2/15 10:21 AM, Eric Rescorla wrote: > > The way you record PERC sessions is by bringing them into the > call at > the signaling level. There's no PERC-level accommodation needed. > > > Who is "them"? Do you mean "recording resources" of some kind would > be added as participants to the call? Just trying to clarify the > model... > > > Yes. > > -Ekr > > > > > _______________________________________________ > dispatch mailing list > dispatch@ietf.org > https://www.ietf.org/mailman/listinfo/dispatch > From nobody Tue Jun 2 14:09:14 2015 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 43A901B309C for ; Tue, 2 Jun 2015 14:09:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0 X-Spam-Level: X-Spam-Status: No, score=0 tagged_above=-999 required=5 tests=[BAYES_50=0.8, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham 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 Rs2cU0e4SvlS for ; Tue, 2 Jun 2015 14:09:12 -0700 (PDT) Received: from out5-smtp.messagingengine.com (out5-smtp.messagingengine.com [66.111.4.29]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EBB6A1B3098 for ; Tue, 2 Jun 2015 14:09:11 -0700 (PDT) Received: from compute3.internal (compute3.nyi.internal [10.202.2.43]) by mailout.nyi.internal (Postfix) with ESMTP id 320DF2022D for ; Tue, 2 Jun 2015 17:09:11 -0400 (EDT) Received: from frontend2 ([10.202.2.161]) by compute3.internal (MEProxy); Tue, 02 Jun 2015 17:09:11 -0400 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=cooperw.in; h= content-transfer-encoding:content-type:date:from:message-id :mime-version:subject:to:x-sasl-enc:x-sasl-enc; s=mesmtp; bh=QJh 4+EnpwoTUJaVK6bwqXG2Dbxs=; b=ZKnvYnyHh29Q9K52q+2sFNguJ4cdX/gDhoi n4xntJtp8PBGo9LnqITz+kGPrX5+bhpKPyDQ7YQ2jeAF+NdBo5G4TbjVyKiQK73o lGxL3EKESkGbjTd4hbuwBP4L3Ngo6sTfNCVRrR8FUuESuQ02DU6oi4Ntc417/R8j wNJtivAk= DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d= messagingengine.com; h=content-transfer-encoding:content-type :date:from:message-id:mime-version:subject:to:x-sasl-enc :x-sasl-enc; s=smtpout; bh=QJh4+EnpwoTUJaVK6bwqXG2Dbxs=; b=E9FGM Wimxg/WxL+WZYgIDDzPoeAJLSiWqDAXDJASTE99iorkU4dg7+8xIzCwwA8Ggxm8q g7/0cpJvKr3i1qzRSZqhjzPyP6CpBGrBt/OqO1taVotYD+SzafVXjMC0cd76mdVP 0MCkjZM8yvB70uYR/eDcNotXcXDPAvxSgcF4Sg= X-Sasl-enc: m9RBJ8KXb0COJbOs1nVrykpOxJCBX6X3Vg78641xQkio 1433279350 Received: from sjc-alcoop-8813.cisco.com (unknown [128.107.241.161]) by mail.messagingengine.com (Postfix) with ESMTPA id 0625E6800B2; Tue, 2 Jun 2015 17:09:09 -0400 (EDT) From: Alissa Cooper Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Message-Id: Date: Tue, 2 Jun 2015 14:09:08 -0700 To: dispatch@ietf.org, rai@ietf.org, tsv-area@ietf.org Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) X-Mailer: Apple Mail (2.1878.6) Archived-At: Subject: [dispatch] James Polk X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 02 Jun 2015 21:09:13 -0000 I wanted to let you know that our colleague and friend James Polk passed = away last week. James had been participating in the IETF for over a = decade. Over the years he made many valuable contributions that spanned = the areas, with particular focus on SIP, emergency services, = geolocation, and differentiated services. Beyond his technical work, he = sought to make improvements in the role of WG chair and the IETF = overall. I think we all knew him as a fierce defender of the solutions = he believed in who also had a softer side. He will be missed at the IETF = and at Cisco. Please keep James' family in your thoughts. Alissa= From nobody Tue Jun 2 20:10:37 2015 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0DA751B32FF for ; Tue, 2 Jun 2015 20:10:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.511 X-Spam-Level: X-Spam-Status: No, score=-14.511 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham 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 jJud-Pfj4R6Z for ; Tue, 2 Jun 2015 20:10:34 -0700 (PDT) Received: from alln-iport-1.cisco.com (alln-iport-1.cisco.com [173.37.142.88]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1E5EB1B32FB for ; Tue, 2 Jun 2015 20:10:21 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2401; q=dns/txt; s=iport; t=1433301021; x=1434510621; h=from:to:subject:date:message-id:references:in-reply-to: content-id:content-transfer-encoding:mime-version; bh=kY/B4K06tRsACIia33CUeX4lgbMRcX0+sRDEM0L/ycY=; b=TNa9MuOwDgToYfmfFUB2EUvtzURN8GUNq+LiJjxBYx26dCK8ZjJqfaiU ygOT4LxXQUqN38cciTNfW6Golo+nZ69OAj6bVpewMbsWR5oA7OZflOcPX YFnNnDM7yarg/+uK0ZKErHtDsftG+JgowXBD5j9P7hcEhw9Oz8ptH/YLd E=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: A0BcBAD3bm5V/4cNJK1PDA6DAlReBr5wCYFQCoUtSgKBRDgUAQEBAQEBAYEKhCIBAQEEAQEBGksGFwQCAQgOAwMBAgEnBycLFAkIAgQBEogtDdo9AQEBAQEBAQEBAQEBAQEBAQEBFgSLQ4QeAW4GhCcFjAyHBYsel0AjYYJZPm+BRoEBAQEB X-IronPort-AV: E=Sophos;i="5.13,544,1427760000"; d="scan'208";a="155869428" Received: from alln-core-2.cisco.com ([173.36.13.135]) by alln-iport-1.cisco.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 03 Jun 2015 03:10:20 +0000 Received: from xhc-rcd-x10.cisco.com (xhc-rcd-x10.cisco.com [173.37.183.84]) by alln-core-2.cisco.com (8.14.5/8.14.5) with ESMTP id t533AKB2000506 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Wed, 3 Jun 2015 03:10:20 GMT Received: from xmb-aln-x05.cisco.com ([169.254.11.78]) by xhc-rcd-x10.cisco.com ([173.37.183.84]) with mapi id 14.03.0195.001; Tue, 2 Jun 2015 22:10:20 -0500 From: "Ram Mohan R (rmohanr)" To: Paul Kyzivat , "dispatch@ietf.org" Thread-Topic: [dispatch] Updated PERC Charter proposal Thread-Index: AQHQnarSsS6MnJSWb0icHD/hN/fwhg== Date: Wed, 3 Jun 2015 03:10:19 +0000 Message-ID: References: <55683230.3020600@ericsson.com> <556C2A44.8010805@ericsson.com> <556DDC0C.3010107@andyet.net> <556DF837.8050704@alum.mit.edu> In-Reply-To: <556DF837.8050704@alum.mit.edu> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.4.7.141117 x-originating-ip: [173.39.64.86] Content-Type: text/plain; charset="iso-8859-1" Content-ID: <54B24D5880CDF74EB846725D4BF9E2E7@emea.cisco.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Subject: Re: [dispatch] Updated PERC Charter proposal X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 03 Jun 2015 03:10:36 -0000 Hi Paul, -----Original Message----- From: Paul Kyzivat Date: Wednesday, 3 June 2015 12:08 am To: "dispatch@ietf.org" Subject: Re: [dispatch] Updated PERC Charter proposal >At some level this would "work", but it might require rethinking the >whole approach to recording in an enterprise where recording is an >important part of the business. > >IIUC, with PERC there is still likely to be a conference focus, for >signaling, much as without PERC. But the details of how the media is >handled will be different Yes. The way PERC handles media would likely bring in differences on how recording needs to be done. IIUC PERC also brings in a model where in the conference cloud is less trusted and hence there needs to be some thinking on how recording needs to be handled in general. >. Such a focus could automatically bring in a >recorder as a participant. That is already one of the models covered by >siprec. But PERC would prevent the focus and the PERC 'mixer" from >directly serving as the SRC. Yes. That=B9s exactly where I am coming from as well. The conference model where a mixer acts as SRC that SIPREC defines today will not work with PERC.=20 I am trying to see if there is an interest in looking at this problem. Given that recording is critical in many business I believe there is some value in looking at it. Regards, Ram > > Thanks, > Paul > >As long as PERC conferences are > >On 6/2/15 12:40 PM, Eric Rescorla wrote: >> >> >> On Tue, Jun 2, 2015 at 9:38 AM, Peter Saint-Andre - &yet >> > wrote: >> >> On 6/2/15 10:21 AM, Eric Rescorla wrote: >> >> The way you record PERC sessions is by bringing them into the >> call at >> the signaling level. There's no PERC-level accommodation needed. >> >> >> Who is "them"? Do you mean "recording resources" of some kind would >> be added as participants to the call? Just trying to clarify the >> model... >> >> >> Yes. >> >> -Ekr >> >> >> >> >> _______________________________________________ >> dispatch mailing list >> dispatch@ietf.org >> https://www.ietf.org/mailman/listinfo/dispatch >> > >_______________________________________________ >dispatch mailing list >dispatch@ietf.org >https://www.ietf.org/mailman/listinfo/dispatch From nobody Wed Jun 3 00:15:04 2015 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DB1F51B2D9E for ; Wed, 3 Jun 2015 00:15:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham 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 u4-68e2wnyCz for ; Wed, 3 Jun 2015 00:15:00 -0700 (PDT) Received: from mail-pd0-x22d.google.com (mail-pd0-x22d.google.com [IPv6:2607:f8b0:400e:c02::22d]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 33A361B2D96 for ; Wed, 3 Jun 2015 00:15:00 -0700 (PDT) Received: by pdbnf5 with SMTP id nf5so1197245pdb.2 for ; Wed, 03 Jun 2015 00:14:59 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=from:content-type:subject:date:references:to:message-id :mime-version; bh=YkDTlJ/N804o7E4ZleFglvK3QTRoxATVaSBKvxwOWLU=; b=VuxdLsdRy6FXz739P3gsytGPTSVAm6gfKvr7b6bqt3OxjkPnFPMda+1X1LrRd0OrRs 3+eVcOWhEIBuvWxwuW1CC1mQFpoX+955UduAMKpZfRlI/04FVbs52L36U5qUZfJ0QewJ 6NUr9cLqCHo9iiZA3yfzdn9M0KKZG1t49G4vqhpWejcjHP3ix7Ad4FlV89EFMbpNjJnW 9S7wxg0aL2n9PxTc0MhtnVhLITnXfGjp4km8uyXPcmaLLPdkalk8eIq6EnK9++sPMd0h z+tAKTDWsnodrrbn/vc03pgK7u87N+j5PswqZ9JFElxWaacDy7iBoZlIHB9hYmF8n1jq GAUw== X-Received: by 10.68.94.129 with SMTP id dc1mr19718365pbb.8.1433315699729; Wed, 03 Jun 2015 00:14:59 -0700 (PDT) Received: from [192.168.1.100] ([101.170.27.163]) by mx.google.com with ESMTPSA id cp10sm19920771pdb.44.2015.06.03.00.14.57 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Wed, 03 Jun 2015 00:14:59 -0700 (PDT) From: James Winterbottom Content-Type: multipart/alternative; boundary="Apple-Mail=_722E7704-768A-4B58-9B87-DFCF338F6CDA" Date: Wed, 3 Jun 2015 17:14:53 +1000 References: <20150602112139.8638.82982.idtracker@ietfa.amsl.com> To: dispatch@ietf.org Message-Id: Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2098\)) X-Mailer: Apple Mail (2.2098) Archived-At: Subject: [dispatch] Fwd: New Version Notification for draft-winterbottom-dispatch-locparam-00.txt X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 03 Jun 2015 07:15:03 -0000 --Apple-Mail=_722E7704-768A-4B58-9B87-DFCF338F6CDA Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii FYI, > Begin forwarded message: >=20 > From: internet-drafts@ietf.org > Subject: New Version Notification for = draft-winterbottom-dispatch-locparam-00.txt > Date: 2 June 2015 9:21:39 pm AEST > To: "Laura Liess" , "James Winterbottom" = , "Bruno Chatras" = , "Andrew Hutton" , = "Laura Liess" , "Andrew Hutton" = , "James Winterbottom" = , "Bruno Chatras" = >=20 >=20 > A new version of I-D, draft-winterbottom-dispatch-locparam-00.txt > has been successfully submitted by James Winterbottom and posted to = the > IETF repository. >=20 > Name: draft-winterbottom-dispatch-locparam > Revision: 00 > Title: Location Source Parameter for the SIP = Geolocation Header Field > Document date: 2015-06-01 > Group: Individual Submission > Pages: 7 > URL: = https://www.ietf.org/internet-drafts/draft-winterbottom-dispatch-locparam-= 00.txt > Status: = https://datatracker.ietf.org/doc/draft-winterbottom-dispatch-locparam/ > Htmlized: = https://tools.ietf.org/html/draft-winterbottom-dispatch-locparam-00 >=20 >=20 > Abstract: > There are some circumstances where a geolocation header field may > contain more than one location value. Knowing the identity of the > node adding the location value allows the recipient more freedom in > selecting the value to look at first rather than relying solely on > the order of the location values. >=20 >=20 >=20 >=20 > 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. >=20 > The IETF Secretariat >=20 --Apple-Mail=_722E7704-768A-4B58-9B87-DFCF338F6CDA Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii FYI,


Begin = forwarded message:

From: = internet-drafts@ietf.org
Subject: = New Version = Notification for draft-winterbottom-dispatch-locparam-00.txt
Date: = 2 June 2015 9:21:39 pm AEST
To: = "Laura Liess" <L.Liess@telekom.de>, = "James Winterbottom" <a.james.winterbottom@gmail.com>, "Bruno Chatras" = <bruno.chatras@orange.com>, "Andrew Hutton" <andrew.hutton@unify.com>, "Laura Liess" <l.liess@telekom.de>, = "Andrew Hutton" <andrew.hutton@unify.com>, "James Winterbottom" <a.james.winterbottom@gmail.com>, "Bruno Chatras" = <bruno.chatras@orange.com>

A new version of I-D, = draft-winterbottom-dispatch-locparam-00.txt
has been = successfully submitted by James Winterbottom and posted to the
IETF repository.

Name: = draft-winterbottom-dispatch-locparam
Revision: 00
Title:= = Location Source Parameter for the SIP Geolocation Header Field
Document date: 2015-06-01
Group:= = Individual Submission
Pages: 7
URL: =            https://www.ietf.org/internet-drafts/draft-winterbottom-dispatc= h-locparam-00.txt
Status: =         https://datatracker.ietf.org/doc/draft-winterbottom-dispatch-lo= cparam/
Htmlized: =       https://tools.ietf.org/html/draft-winterbottom-dispatch-locpara= m-00


Abstract:
  There are some circumstances where a geolocation = header field may
  contain more than one = location value.  Knowing the identity of the
=   node adding the location value allows the recipient more = freedom in
  selecting the value to look at = first rather than relying solely on
  the order = of the location values.




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.

The IETF = Secretariat


= --Apple-Mail=_722E7704-768A-4B58-9B87-DFCF338F6CDA-- From nobody Wed Jun 3 01:42:38 2015 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5A7261A88E0 for ; Wed, 3 Jun 2015 01:42:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.61 X-Spam-Level: X-Spam-Status: No, score=-2.61 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, T_RP_MATCHES_RCVD=-0.01] autolearn=ham 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 G-QRMs1VnYRn for ; Wed, 3 Jun 2015 01:42:35 -0700 (PDT) Received: from mx12.unify.com (mx12.unify.com [62.134.46.10]) by ietfa.amsl.com (Postfix) with ESMTP id 9C8C41A88D7 for ; Wed, 3 Jun 2015 01:42:35 -0700 (PDT) Received: from MCHP01HTC.global-ad.net (unknown [172.29.42.234]) by mx12.unify.com (Server) with ESMTP id 42E8A23F045F; Wed, 3 Jun 2015 10:42:34 +0200 (CEST) Received: from MCHP04MSX.global-ad.net ([169.254.1.213]) by MCHP01HTC.global-ad.net ([172.29.42.234]) with mapi id 14.03.0224.002; Wed, 3 Jun 2015 10:42:33 +0200 From: "Hutton, Andrew" To: "Ram Mohan R (rmohanr)" Thread-Topic: [dispatch] Updated PERC Charter proposal Thread-Index: AQHQnWNihHzG6QUxl02HeR+DxLSPGZ2Z+VaAgAB+W3Q= Date: Wed, 3 Jun 2015 08:42:33 +0000 Message-ID: References: <55683230.3020600@ericsson.com> <556C2A44.8010805@ericsson.com> <556DDC0C.3010107@andyet.net> <556DF837.8050704@alum.mit.edu>, In-Reply-To: Accept-Language: en-US Content-Language: en-GB X-MS-Has-Attach: X-MS-TNEF-Correlator: Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Cc: "dispatch@ietf.org" Subject: Re: [dispatch] Updated PERC Charter proposal X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 03 Jun 2015 08:42:37 -0000 I agree there is some value in exploring the recording use case it is one o= f the first questions everybody asks when discussing PERC. Hope we are allowed to consider this. Andy=20 > On 3 Jun 2015, at 04:10, Ram Mohan R (rmohanr) wrote: >=20 > Hi Paul, >=20 > -----Original Message----- > From: Paul Kyzivat > Date: Wednesday, 3 June 2015 12:08 am > To: "dispatch@ietf.org" > Subject: Re: [dispatch] Updated PERC Charter proposal >=20 >> At some level this would "work", but it might require rethinking the >> whole approach to recording in an enterprise where recording is an >> important part of the business. >>=20 >> IIUC, with PERC there is still likely to be a conference focus, for >> signaling, much as without PERC. But the details of how the media is >> handled will be different >=20 > Yes. The way PERC handles media would likely bring in differences on how > recording needs to be done. > IIUC PERC also brings in a model where in the conference cloud is less > trusted and hence there needs > to be some thinking on how recording needs to be handled in general. >=20 >> . Such a focus could automatically bring in a >> recorder as a participant. That is already one of the models covered by >> siprec. But PERC would prevent the focus and the PERC 'mixer" from >> directly serving as the SRC. >=20 > Yes. That=B9s exactly where I am coming from as well. The conference mode= l > where a mixer acts as SRC that SIPREC defines today will not work with > PERC.=20 > I am trying to see if there is an interest in looking at this problem. > Given that recording is critical in many business I believe there > is some value in looking at it. >=20 > Regards, > Ram >>=20 >> Thanks, >> Paul >>=20 >> As long as PERC conferences are >>=20 >>> On 6/2/15 12:40 PM, Eric Rescorla wrote: >>>=20 >>>=20 >>> On Tue, Jun 2, 2015 at 9:38 AM, Peter Saint-Andre - &yet >>> > wrote: >>>=20 >>> On 6/2/15 10:21 AM, Eric Rescorla wrote: >>>=20 >>> The way you record PERC sessions is by bringing them into the >>> call at >>> the signaling level. There's no PERC-level accommodation needed. >>>=20 >>>=20 >>> Who is "them"? Do you mean "recording resources" of some kind would >>> be added as participants to the call? Just trying to clarify the >>> model... >>>=20 >>>=20 >>> Yes. >>>=20 >>> -Ekr >>>=20 >>>=20 >>>=20 >>>=20 >>> _______________________________________________ >>> dispatch mailing list >>> dispatch@ietf.org >>> https://www.ietf.org/mailman/listinfo/dispatch >>=20 >> _______________________________________________ >> dispatch mailing list >> dispatch@ietf.org >> https://www.ietf.org/mailman/listinfo/dispatch >=20 > _______________________________________________ > dispatch mailing list > dispatch@ietf.org > https://www.ietf.org/mailman/listinfo/dispatch From nobody Wed Jun 3 05:38:32 2015 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BF4191A8777 for ; Wed, 3 Jun 2015 05:38:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.977 X-Spam-Level: X-Spam-Status: No, score=-1.977 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham 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 b6O8CSKQCSlw for ; Wed, 3 Jun 2015 05:38:29 -0700 (PDT) Received: from mail-wi0-f180.google.com (mail-wi0-f180.google.com [209.85.212.180]) (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 A73931A8778 for ; Wed, 3 Jun 2015 05:38:28 -0700 (PDT) Received: by wifw1 with SMTP id w1so20306379wif.0 for ; Wed, 03 Jun 2015 05:38:27 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type; bh=szsmO+1wmZFLgm/sjy1twSgmg2o5oJhVCHcih0iu+Ds=; b=Pbx4ucH04uu1g/HdJtDaHDDaowmUBOmqlRm3HCMccwTcg8jd3GH5qzUWcHnQzQwVwI jdcMezg5t76hfTDIlFdnulFfALdNhZkuuKA8zJHaon9JFHHNthE2w+FPIvv/FZBIn8Gz zIHspxcwlQ7t68DIxppM/rrbWxHp8EpylLMQEMWpDODt3vzyYJI9o33k6FjxEjAyy7ei iQdVHy9zk56Y8JzKl7VYmzkqg9Xc5lwz6LZKHHjLeRBOMUYtTXj8CuO813j+P2SHueqi 6pNqkmlRxXjMKZvVSfAexBGT0ZxYz3+dpzo0W4RGPK8H1pOcJC8dS/035n6/CpgZzkzH ldoA== X-Gm-Message-State: ALoCoQlog3ar8BPT3WX1EFbhoKVpD/BpFhSmjMrGC0uJ58qNMV5Z3sPgMYf4/k9UQ9I6xh9JY9J5 X-Received: by 10.180.73.176 with SMTP id m16mr42373532wiv.68.1433335101321; Wed, 03 Jun 2015 05:38:21 -0700 (PDT) MIME-Version: 1.0 Received: by 10.27.225.14 with HTTP; Wed, 3 Jun 2015 05:37:40 -0700 (PDT) In-Reply-To: <556DF837.8050704@alum.mit.edu> References: <55683230.3020600@ericsson.com> <556C2A44.8010805@ericsson.com> <556DDC0C.3010107@andyet.net> <556DF837.8050704@alum.mit.edu> From: Eric Rescorla Date: Wed, 3 Jun 2015 05:37:40 -0700 Message-ID: To: Paul Kyzivat Content-Type: multipart/alternative; boundary=f46d043c7e588f097b05179c5532 Archived-At: Cc: DISPATCH Subject: Re: [dispatch] Updated PERC Charter proposal X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 03 Jun 2015 12:38:30 -0000 --f46d043c7e588f097b05179c5532 Content-Type: text/plain; charset=UTF-8 On Tue, Jun 2, 2015 at 11:38 AM, Paul Kyzivat wrote: > At some level this would "work", but it might require rethinking the whole > approach to recording in an enterprise where recording is an important part > of the business. > > IIUC, with PERC there is still likely to be a conference focus, for > signaling, much as without PERC. But the details of how the media is > handled will be different. Such a focus could automatically bring in a > recorder as a participant. That is already one of the models covered by > siprec. But PERC would prevent the focus and the PERC 'mixer" from directly > serving as the SRC. > I don't really understand the problem here. The *signaling* server needs to bring the recorder in, but that's intentional: the whole point of PERC is that you have to be a first-class participant in order to be any part of the call. In any case, I'm not opposed to exploring whether PERC can support some kind of (consensual) recording, but I'm definitely opposed to making it a charter requirement that it do so. -Ekr Thanks, > Paul > > As long as PERC conferences are > > On 6/2/15 12:40 PM, Eric Rescorla wrote: > >> >> >> On Tue, Jun 2, 2015 at 9:38 AM, Peter Saint-Andre - &yet >> > wrote: >> >> On 6/2/15 10:21 AM, Eric Rescorla wrote: >> >> The way you record PERC sessions is by bringing them into the >> call at >> the signaling level. There's no PERC-level accommodation needed. >> >> >> Who is "them"? Do you mean "recording resources" of some kind would >> be added as participants to the call? Just trying to clarify the >> model... >> >> >> Yes. >> >> -Ekr >> >> >> >> >> _______________________________________________ >> dispatch mailing list >> dispatch@ietf.org >> https://www.ietf.org/mailman/listinfo/dispatch >> >> > _______________________________________________ > dispatch mailing list > dispatch@ietf.org > https://www.ietf.org/mailman/listinfo/dispatchI do > --f46d043c7e588f097b05179c5532 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On T= ue, Jun 2, 2015 at 11:38 AM, Paul Kyzivat <pkyzivat@alum.mit.edu&g= t; wrote:
At some level this would= "work", but it might require rethinking the whole approach to re= cording in an enterprise where recording is an important part of the busine= ss.

IIUC, with PERC there is still likely to be a conference focus, for signali= ng, much as without PERC. But the details of how the media is handled will = be different. Such a focus could automatically bring in a recorder as a par= ticipant. That is already one of the models covered by siprec. But PERC wou= ld prevent the focus and the PERC 'mixer" from directly serving as= the SRC.

I don't really understand= the problem here. The *signaling* server needs to bring
the reco= rder in, but that's intentional: the whole point of PERC is that you ha= ve
to be a first-class participant in order to be any part of the= call.

In any case, I'm not opposed to explori= ng whether PERC can support some kind
of (consensual) recording, = but I'm definitely opposed to making it a charter
requirement= that it do so.

-Ekr


=

=C2=A0 =C2=A0 =C2=A0 =C2=A0 Thanks,
=C2=A0 =C2=A0 =C2=A0 =C2=A0 Paul

As long as PERC conferences are

On 6/2/15 12:40 PM, Eric Rescorla wrote:


On Tue, Jun 2, 2015 at 9:38 AM, Peter Saint-Andre - &yet
 <peter@andyet.net<= /a> <mailto:peter@= andyet.net>> wrote:

=C2=A0 =C2=A0 On 6/2/15 10:21 AM, Eric Rescorla wrote:

=C2=A0 =C2=A0 =C2=A0 =C2=A0 The way you record PERC sessions is by bringing= them into the
=C2=A0 =C2=A0 =C2=A0 =C2=A0 call at
=C2=A0 =C2=A0 =C2=A0 =C2=A0 the signaling level. There's no PERC-level = accommodation needed.


=C2=A0 =C2=A0 Who is "them"? Do you mean "recording resource= s" of some kind would
=C2=A0 =C2=A0 be added as participants to the call? Just trying to clarify = the
=C2=A0 =C2=A0 model...


Yes.

-Ekr




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


_______________________________________________
dispatch mailing list
dispatch@ietf.org
https://www.ietf.org/mailman/listinfo/dispatchI do

--f46d043c7e588f097b05179c5532-- From nobody Wed Jun 3 05:59:03 2015 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8D4F41A1BE4 for ; Wed, 3 Jun 2015 05:59:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.201 X-Spam-Level: X-Spam-Status: No, score=-4.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham 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 u0KaB4kmwiFz for ; Wed, 3 Jun 2015 05:58:57 -0700 (PDT) Received: from sessmg23.ericsson.net (sessmg23.ericsson.net [193.180.251.45]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 66E961A1A60 for ; Wed, 3 Jun 2015 05:58:57 -0700 (PDT) X-AuditID: c1b4fb2d-f794d6d000004501-9f-556efa0fe1f5 Received: from ESESSHC013.ericsson.se (Unknown_Domain [153.88.253.125]) by sessmg23.ericsson.net (Symantec Mail Security) with SMTP id AA.C3.17665.F0AFE655; Wed, 3 Jun 2015 14:58:55 +0200 (CEST) Received: from [127.0.0.1] (153.88.183.153) by smtp.internal.ericsson.com (153.88.183.59) with Microsoft SMTP Server id 14.3.210.2; Wed, 3 Jun 2015 14:58:55 +0200 Message-ID: <556EFA0E.8050408@ericsson.com> Date: Wed, 3 Jun 2015 14:58:54 +0200 From: Magnus Westerlund User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.7.0 MIME-Version: 1.0 To: "Hutton, Andrew" , "Ram Mohan R (rmohanr)" References: <55683230.3020600@ericsson.com> <556C2A44.8010805@ericsson.com> <556DDC0C.3010107@andyet.net> <556DF837.8050704@alum.mit.edu>, In-Reply-To: Content-Type: text/plain; charset="windows-1252"; format=flowed Content-Transfer-Encoding: 8bit X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFlrLLMWRmVeSWpSXmKPExsUyM+JvrS7/r7xQg2UfDSy2bSi1WDppAavF 8q4djA7MHlN+b2T1WLLkJ5PH9p7HLAHMUVw2Kak5mWWpRfp2CVwZS6dsZirYIVjxY/Ih1gbG Jr4uRk4OCQETiYnfNzJD2GISF+6tZ+ti5OIQEjjKKPFvWy87hLOMUWLWp7lMIFW8AtoSq/of AdkcHCwCKhL/OsJAwmwCFhI3fzSygdiiAlESUx+vY4EoF5Q4OfMJmC0iECvR+e4iO4jNDDTm //V1jCC2sICpxJKdP6AW72ORWHX6KdhFnALmEjfebgfbxSxgL/FgaxlEr7xE89bZYCVCQHMa mjpYJzAKzkKybhZCxywkHQsYmVcxihanFhfnphsZ66UWZSYXF+fn6eWllmxiBIbvwS2/dXcw rn7teIhRgINRiYd3QXxeqBBrYllxZe4hRmkOFiVx3hmbgUIC6YklqdmpqQWpRfFFpTmpxYcY mTg4pYDBOnP/jZ4NU9SYM85oLLH7JzthwrnDJqsT1Cs8/K1/Cdu7v79yiPf35Uj/Ha9MxQ1f vvsedfTjHQHmkim7WANMrb12rf5qbDA1KXj2eTfNM3s/Xg3P93li4uzu4L9Qtr1D9WZgdbnv 1t1dnra7jOyKtgvsKPaKLpjd+2/ni/q7vtzbDMw+hM5SYinOSDTUYi4qTgQA9meGXUACAAA= Archived-At: Cc: "dispatch@ietf.org" Subject: Re: [dispatch] Updated PERC Charter proposal X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 03 Jun 2015 12:59:02 -0000 Hutton, Andrew skrev den 2015-06-03 10:42: > I agree there is some value in exploring the recording use case it is > one of the first questions everybody asks when discussing PERC. From my perspective there are two ways of doing recording of media content in PERC. 1. Invite the recorder as a full fledged authenticated session participant that use the normal way of getting the keys to the media as any other endpoint. 2. The recorder only stores the encrypted media content, thus being a semi-trusted entity to that are allowed to get a copy or be integrated into the central forwarders. At the time one wants to access the recorded content one will have to request the relevant keys from the key-management function, that will also have to have stored the relevant group keys for the session to enable decryption. I would claim that the second one is the securer, and enables better tracking of who access recordings of a secured conference. > > Hope we are allowed to consider this. The charter talks about informing and coordinating with SIPREC. This to have an exchange about the possibilities. However, it is not a work item of the PERC WG to specify a solution for recording. I would expect any technical work on solving PERC recording would need to be chartered in the most relevant WG. I think the ones interested in recording should be active in the WG work to ensure that the developed solution do support recording. If there are contention between the goals, then we will need to have a serious discussion. But, remember that we have clear goals of ensuring end to end security, thus compromises to the security model to fit recording will be unlikely to be accepted. Cheers 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 Wed Jun 3 06:03:35 2015 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 87E671A877A for ; Wed, 3 Jun 2015 06:03:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.977 X-Spam-Level: X-Spam-Status: No, score=-1.977 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham 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 nqfCN0fl1Upq for ; Wed, 3 Jun 2015 06:03:24 -0700 (PDT) Received: from mail-wg0-f50.google.com (mail-wg0-f50.google.com [74.125.82.50]) (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 C60C21A1F20 for ; Wed, 3 Jun 2015 06:03:23 -0700 (PDT) Received: by wgez8 with SMTP id z8so8651310wge.0 for ; Wed, 03 Jun 2015 06:03:22 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type; bh=dF16hBy2MNUIRGyetjkSVu4fVwFxZ6KVaNxcg8VLJno=; b=kpQO9rlfe+mFwW7pd/WYjGGE2NQCGinSqZs3Lk4ol0endbBkxhQW+euypQWfutmBe9 ur7/jFG60suYPKNUOMJPZe0xi9YNXTIh8lUytgjTxQEGOy1AGMq67LgaUVqyl6SIRQ4E t6Kzn2oL+kDpf+rRlX/3bGqfvdik9iUAwJQERZFavol6qiUKMvCpaAP2/cKRa8yeJzjz +JBBkxvyJ+ApVD6WZnKu2yw3jXq6O7Zhaw8q+Q4dvUNRvAzR46hWKQYMLRTkEZJSkw+H x/z9EjiXWZmlKm3UTVrEcri0OufcFsBYHhzo4VLkhCJRT7CzaSP02o5xQS65Kq6qtmaH VbhA== X-Gm-Message-State: ALoCoQm5U5PP5W5EY+ShNAPgqNPZvsJ1972I2JQIbJbSx0k/h1VyjhKthFc+kNAtzzBuIzPD0uD1 X-Received: by 10.180.75.8 with SMTP id y8mr41463791wiv.31.1433336602534; Wed, 03 Jun 2015 06:03:22 -0700 (PDT) MIME-Version: 1.0 Received: by 10.27.225.14 with HTTP; Wed, 3 Jun 2015 06:02:42 -0700 (PDT) In-Reply-To: <556EFA0E.8050408@ericsson.com> References: <55683230.3020600@ericsson.com> <556C2A44.8010805@ericsson.com> <556DDC0C.3010107@andyet.net> <556DF837.8050704@alum.mit.edu> <556EFA0E.8050408@ericsson.com> From: Eric Rescorla Date: Wed, 3 Jun 2015 06:02:42 -0700 Message-ID: To: Magnus Westerlund Content-Type: multipart/alternative; boundary=f46d043c7b9c09bb0705179cafd2 Archived-At: Cc: "dispatch@ietf.org" Subject: Re: [dispatch] Updated PERC Charter proposal X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 03 Jun 2015 13:03:26 -0000 --f46d043c7b9c09bb0705179cafd2 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable I like Magnus's position here and I appreciate him stating it so clearly. -Ekr On Wed, Jun 3, 2015 at 5:58 AM, Magnus Westerlund < magnus.westerlund@ericsson.com> wrote: > Hutton, Andrew skrev den 2015-06-03 10:42: > >> I agree there is some value in exploring the recording use case it is >> one of the first questions everybody asks when discussing PERC. >> > > From my perspective there are two ways of doing recording of media conten= t > in PERC. > > 1. Invite the recorder as a full fledged authenticated session participan= t > that use the normal way of getting the keys to the media as any other > endpoint. > > 2. The recorder only stores the encrypted media content, thus being a > semi-trusted entity to that are allowed to get a copy or be integrated in= to > the central forwarders. At the time one wants to access the recorded > content one will have to request the relevant keys from the key-managemen= t > function, that will also have to have stored the relevant group keys for > the session to enable decryption. > > I would claim that the second one is the securer, and enables better > tracking of who access recordings of a secured conference. > > >> Hope we are allowed to consider this. >> > > The charter talks about informing and coordinating with SIPREC. This to > have an exchange about the possibilities. However, it is not a work item = of > the PERC WG to specify a solution for recording. I would expect any > technical work on solving PERC recording would need to be chartered in th= e > most relevant WG. I think the ones interested in recording should be acti= ve > in the WG work to ensure that the developed solution do support recording= . > If there are contention between the goals, then we will need to have a > serious discussion. But, remember that we have clear goals of ensuring en= d > to end security, thus compromises to the security model to fit recording > will be unlikely to be accepted. > > Cheers > > Magnus Westerlund > > ---------------------------------------------------------------------- > Services, Media and Network features, Ericsson Research EAB/TXM > ---------------------------------------------------------------------- > Ericsson AB | Phone +46 10 7148287 > F=C3=A4r=C3=B6gatan 6 | Mobile +46 73 0949079 > SE-164 80 Stockholm, Sweden | mailto: magnus.westerlund@ericsson.com > ---------------------------------------------------------------------- > > _______________________________________________ > dispatch mailing list > dispatch@ietf.org > https://www.ietf.org/mailman/listinfo/dispatch > --f46d043c7b9c09bb0705179cafd2 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
I like Magnus's position here and I appreciate him sta= ting it so clearly.

-Ekr


On Wed, Jun 3, 2015 at= 5:58 AM, Magnus Westerlund <magnus.westerlund@ericsson.com> wrote:
Hut= ton, Andrew skrev den 2015-06-03 10:42:
I agree there is some value in exploring the recording use case it is
one of the first questions everybody asks when discussing PERC.

 >From my perspective there are two ways of doing recording of media content = in PERC.

1. Invite the recorder as a full fledged authenticated session participant = that use the normal way of getting the keys to the media as any other endpo= int.

2. The recorder only stores the encrypted media content, thus being a semi-= trusted entity to that are allowed to get a copy or be integrated into the = central forwarders. At the time one wants to access the recorded content on= e will have to request the relevant keys from the key-management function, = that will also have to have stored the relevant group keys for the session = to enable decryption.

I would claim that the second one is the securer, and enables better tracki= ng of who access recordings of a secured conference.


Hope we are allowed to consider this.

 The charter talks about informing and coordinating with SIPREC. This to hav= e an exchange about the possibilities. However, it is not a work item of th= e PERC WG to specify a solution for recording. I would expect any technical= work on solving PERC recording would need to be chartered in the most rele= vant WG. I think the ones interested in recording should be active in the W= G work to ensure that the developed solution do support recording. If there= are contention between the goals, then we will need to have a serious disc= ussion. But, remember that we have clear goals of ensuring end to end secur= ity, thus compromises to the security model to fit recording will be unlike= ly to be accepted.

Cheers

Magnus Westerlund

----------------------------------------------------------------------
Services, Media and Network features, Ericsson Research EAB/TXM
----------------------------------------------------------------------
Ericsson AB=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0| = Phone=C2=A0 +46 10 7148287
F=C3=A4r=C3=B6gatan 6=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0| Mobile +46 73 0949079
SE-164 80 Stockholm, Sweden | mailto: magnus.westerlund@ericsson.com
----------------------------------------------------------------------

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

--f46d043c7b9c09bb0705179cafd2-- From nobody Wed Jun 3 07:03:13 2015 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 77AA61A7018 for ; Wed, 3 Jun 2015 07:03:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.909 X-Spam-Level: X-Spam-Status: No, score=-1.909 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham 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 8ddvWjMjrsm1 for ; Wed, 3 Jun 2015 07:03:05 -0700 (PDT) Received: from nostrum.com (raven-v6.nostrum.com [IPv6:2001:470:d:1130::1]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C6D611A8731 for ; Wed, 3 Jun 2015 07:03:01 -0700 (PDT) Received: from Orochi.local (99-152-145-110.lightspeed.dllstx.sbcglobal.net [99.152.145.110]) (authenticated bits=0) by nostrum.com (8.15.1/8.14.9) with ESMTPSA id t53E2tqD025823 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NO); Wed, 3 Jun 2015 09:02:56 -0500 (CDT) (envelope-from adam@nostrum.com) X-Authentication-Warning: raven.nostrum.com: Host 99-152-145-110.lightspeed.dllstx.sbcglobal.net [99.152.145.110] claimed to be Orochi.local Message-ID: <556F090F.5050907@nostrum.com> Date: Wed, 03 Jun 2015 09:02:55 -0500 From: Adam Roach User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:31.0) Gecko/20100101 Thunderbird/31.7.0 MIME-Version: 1.0 To: Eric Rescorla , Magnus Westerlund References: <55683230.3020600@ericsson.com> <556C2A44.8010805@ericsson.com> <556DDC0C.3010107@andyet.net> <556DF837.8050704@alum.mit.edu> <556EFA0E.8050408@ericsson.com> In-Reply-To: Content-Type: multipart/alternative; boundary="------------060006010106030104090105" Archived-At: Cc: "dispatch@ietf.org" Subject: Re: [dispatch] Updated PERC Charter proposal X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 03 Jun 2015 14:03:12 -0000 This is a multi-part message in MIME format. --------------060006010106030104090105 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit This sounds reasonable. Given Magnus's earlier proposal to add "...coordinate with...SIPREC...," I don't think any further changes are needed in the charter to accommodate recording. /a On 6/3/15 08:02, Eric Rescorla wrote: > I like Magnus's position here and I appreciate him stating it so clearly. > > -Ekr > > > On Wed, Jun 3, 2015 at 5:58 AM, Magnus Westerlund > > wrote: > > Hutton, Andrew skrev den 2015-06-03 10:42: > > I agree there is some value in exploring the recording use > case it is > one of the first questions everybody asks when discussing PERC. > > > >From my perspective there are two ways of doing recording of > media content in PERC. > > 1. Invite the recorder as a full fledged authenticated session > participant that use the normal way of getting the keys to the > media as any other endpoint. > > 2. The recorder only stores the encrypted media content, thus > being a semi-trusted entity to that are allowed to get a copy or > be integrated into the central forwarders. At the time one wants > to access the recorded content one will have to request the > relevant keys from the key-management function, that will also > have to have stored the relevant group keys for the session to > enable decryption. > > I would claim that the second one is the securer, and enables > better tracking of who access recordings of a secured conference. > > > Hope we are allowed to consider this. > > > The charter talks about informing and coordinating with SIPREC. > This to have an exchange about the possibilities. However, it is > not a work item of the PERC WG to specify a solution for > recording. I would expect any technical work on solving PERC > recording would need to be chartered in the most relevant WG. I > think the ones interested in recording should be active in the WG > work to ensure that the developed solution do support recording. > If there are contention between the goals, then we will need to > have a serious discussion. But, remember that we have clear goals > of ensuring end to end security, thus compromises to the security > model to fit recording will be unlikely to be accepted. > > Cheers > > 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 > ---------------------------------------------------------------------- > > _______________________________________________ > dispatch mailing list > dispatch@ietf.org > https://www.ietf.org/mailman/listinfo/dispatch > > > > > _______________________________________________ > dispatch mailing list > dispatch@ietf.org > https://www.ietf.org/mailman/listinfo/dispatch --------------060006010106030104090105 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit
This sounds reasonable. Given Magnus's earlier proposal to add "...coordinate with...SIPREC...," I don't think any further changes are needed in the charter to accommodate recording.

/a

On 6/3/15 08:02, Eric Rescorla wrote:
I like Magnus's position here and I appreciate him stating it so clearly.

-Ekr


On Wed, Jun 3, 2015 at 5:58 AM, Magnus Westerlund <magnus.westerlund@ericsson.com> wrote:
Hutton, Andrew skrev den 2015-06-03 10:42:
I agree there is some value in exploring the recording use case it is
one of the first questions everybody asks when discussing PERC.

 >From my perspective there are two ways of doing recording of media content in PERC.

1. Invite the recorder as a full fledged authenticated session participant that use the normal way of getting the keys to the media as any other endpoint.

2. The recorder only stores the encrypted media content, thus being a semi-trusted entity to that are allowed to get a copy or be integrated into the central forwarders. At the time one wants to access the recorded content one will have to request the relevant keys from the key-management function, that will also have to have stored the relevant group keys for the session to enable decryption.

I would claim that the second one is the securer, and enables better tracking of who access recordings of a secured conference.


Hope we are allowed to consider this.

 The charter talks about informing and coordinating with SIPREC. This to have an exchange about the possibilities. However, it is not a work item of the PERC WG to specify a solution for recording. I would expect any technical work on solving PERC recording would need to be chartered in the most relevant WG. I think the ones interested in recording should be active in the WG work to ensure that the developed solution do support recording. If there are contention between the goals, then we will need to have a serious discussion. But, remember that we have clear goals of ensuring end to end security, thus compromises to the security model to fit recording will be unlikely to be accepted.

Cheers

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
----------------------------------------------------------------------
_______________________________________________
dispatch mailing list
dispatch@ietf.org
https://www.ietf.org/mailman/listinfo/dispatch



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

--------------060006010106030104090105-- From nobody Wed Jun 3 08:27:27 2015 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5A2F31A8F49 for ; Wed, 3 Jun 2015 08:27:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.511 X-Spam-Level: X-Spam-Status: No, score=-14.511 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham 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 1iZZPKNkBMB9 for ; Wed, 3 Jun 2015 08:27:23 -0700 (PDT) Received: from alln-iport-4.cisco.com (alln-iport-4.cisco.com [173.37.142.91]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C23E51A3BA1 for ; Wed, 3 Jun 2015 08:27:23 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2935; q=dns/txt; s=iport; t=1433345243; x=1434554843; h=from:to:subject:date:message-id:references:in-reply-to: content-id:content-transfer-encoding:mime-version; bh=6Nwz2YXAObu+WxA/HcKzgzA3YI1//2NK7p1Zky6O67o=; b=cMM/PaO7RjsbiMqfNYdErXDPt35ytZysSe44/+ZueKvJAtf4rYP1mswG liJBc5uOyWwqzeVsd2yxe/mdzZYN4o8hL+XF8g7rlNX0yWqpIxPIudMjU NpTtHsARoi0KBnM7vBb52vVqmmreCTxiNeY5Pg0hGJvItvrvDlNkiAxZt Y=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: A0ApBQDyG29V/5xdJa1bgxCBMgbGJwICAoE/OxEBAQEBAQEBgQqEIgEBAQQMXB0CAgIBCBEDAQIoBxsXFAkIAgQBEhuIEttFAQEBAQEBAQEBAQEBAQEBAQEbBIs/hQ0GhCcFhmyFIoRHgj+LH5dEJGGDF2+BRoEBAQEB X-IronPort-AV: E=Sophos;i="5.13,547,1427760000"; d="scan'208";a="156068550" Received: from rcdn-core-5.cisco.com ([173.37.93.156]) by alln-iport-4.cisco.com with ESMTP; 03 Jun 2015 15:27:22 +0000 Received: from xhc-aln-x12.cisco.com (xhc-aln-x12.cisco.com [173.36.12.86]) by rcdn-core-5.cisco.com (8.14.5/8.14.5) with ESMTP id t53FRMaL030127 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Wed, 3 Jun 2015 15:27:22 GMT Received: from xmb-aln-x05.cisco.com ([169.254.11.78]) by xhc-aln-x12.cisco.com ([173.36.12.86]) with mapi id 14.03.0195.001; Wed, 3 Jun 2015 10:27:22 -0500 From: "Ram Mohan R (rmohanr)" To: Magnus Westerlund , "Hutton, Andrew" , "dispatch@ietf.org" Thread-Topic: [dispatch] Updated PERC Charter proposal Thread-Index: AQHQnhHIkh59aGNCBkW9506d2tXpsg== Date: Wed, 3 Jun 2015 15:27:21 +0000 Message-ID: References: <55683230.3020600@ericsson.com> <556C2A44.8010805@ericsson.com> <556DDC0C.3010107@andyet.net> <556DF837.8050704@alum.mit.edu> <556EFA0E.8050408@ericsson.com> In-Reply-To: <556EFA0E.8050408@ericsson.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.4.7.141117 x-originating-ip: [10.65.59.238] Content-Type: text/plain; charset="iso-8859-1" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Subject: Re: [dispatch] Updated PERC Charter proposal X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 03 Jun 2015 15:27:25 -0000 Hi Magnus, -----Original Message----- From: Magnus Westerlund Date: Wednesday, 3 June 2015 6:28 pm To: "Hutton, Andrew" , Cisco Employee Cc: "dispatch@ietf.org" Subject: Re: [dispatch] Updated PERC Charter proposal >Hutton, Andrew skrev den 2015-06-03 10:42: >> I agree there is some value in exploring the recording use case it is >> one of the first questions everybody asks when discussing PERC. > > From my perspective there are two ways of doing recording of media >content in PERC. > >1. Invite the recorder as a full fledged authenticated session >participant that use the normal way of getting the keys to the media as >any other endpoint. > >2. The recorder only stores the encrypted media content, thus being a >semi-trusted entity to that are allowed to get a copy or be integrated >into the central forwarders. At the time one wants to access the >recorded content one will have to request the relevant keys from the >key-management function, that will also have to have stored the relevant >group keys for the session to enable decryption. This is some thing similar to what I was visualising as well. The recorder and KMS needs interactions to get access to recordings. > >I would claim that the second one is the securer, and enables better >tracking of who access recordings of a secured conference. > >> >> Hope we are allowed to consider this. > >The charter talks about informing and coordinating with SIPREC. This to >have an exchange about the possibilities. However, it is not a work item >of the PERC WG to specify a solution for recording. I would expect any >technical work on solving PERC recording would need to be chartered in >the most relevant WG. I am not too worried about where it is done as long as we are doing it. Perhaps SIPREC may be a place given that it was already doing recording for existing models. >I think the ones interested in recording should be >active in the WG work to ensure that the developed solution do support >recording.=20 Agree. Regards, Ram >If there are contention between the goals, then we will need >to have a serious discussion. But, remember that we have clear goals of >ensuring end to end security, thus compromises to the security model to >fit recording will be unlikely to be accepted. > >Cheers > >Magnus Westerlund > >---------------------------------------------------------------------- >Services, Media and Network features, Ericsson Research EAB/TXM >---------------------------------------------------------------------- >Ericsson AB | Phone +46 10 7148287 >F=E4r=F6gatan 6 | Mobile +46 73 0949079 >SE-164 80 Stockholm, Sweden | mailto: magnus.westerlund@ericsson.com >---------------------------------------------------------------------- > From nobody Wed Jun 3 08:57:20 2015 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1755B1A9119 for ; Wed, 3 Jun 2015 08:57:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.235 X-Spam-Level: X-Spam-Status: No, score=-1.235 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, SPF_SOFTFAIL=0.665] autolearn=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 cr2G3UqRraCD for ; Wed, 3 Jun 2015 08:57:16 -0700 (PDT) Received: from resqmta-ch2-11v.sys.comcast.net (resqmta-ch2-11v.sys.comcast.net [IPv6:2001:558:fe21:29:69:252:207:43]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D16201A90FD for ; Wed, 3 Jun 2015 08:57:16 -0700 (PDT) Received: from resomta-ch2-08v.sys.comcast.net ([69.252.207.104]) by resqmta-ch2-11v.sys.comcast.net with comcast id brwC1q0052Fh1PH01rxGem; Wed, 03 Jun 2015 15:57:16 +0000 Received: from Paul-Kyzivats-MacBook-Pro.local ([50.138.229.151]) by resomta-ch2-08v.sys.comcast.net with comcast id brxF1q00m3Ge9ey01rxFQS; Wed, 03 Jun 2015 15:57:16 +0000 Message-ID: <556F23DB.8060306@alum.mit.edu> Date: Wed, 03 Jun 2015 11:57:15 -0400 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:31.0) Gecko/20100101 Thunderbird/31.7.0 MIME-Version: 1.0 To: dispatch@ietf.org References: <55683230.3020600@ericsson.com> <556C2A44.8010805@ericsson.com> <556DDC0C.3010107@andyet.net> <556DF837.8050704@alum.mit.edu>, <556EFA0E.8050408@ericsson.com> In-Reply-To: <556EFA0E.8050408@ericsson.com> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=q20140121; t=1433347036; bh=I+6ltf8vUjfExh0LXSit8j/NoYfvQohy03djdNEyI9c=; h=Received:Received:Message-ID:Date:From:MIME-Version:To:Subject: Content-Type; b=qfwsI2jfFfj0H0Q5n7KPz4c2fLlZgWwTxv7G+5FvIqIGH6NPr1nXSy25+uqx2A5rb AaYB1HdwqhEL9c8MLLqfuTXI8zFexRJ1HZdesQGm1wYnUWp2gCF/JX4oMgCD+0thyg bgS0+k4CpYyynvxQyJ1X8EopwRNr57d3LuwogzU9f/qZWgtXVoGCRNYRRqZodtf28t 90rce2pP8Ng1UCk3WIcm/MGqKq6BKCjRFilFiaxftr7UMf24ZQKBzbOsyFIKeShnxx Bdp4F5a2cVJBngbLkuG7UNDDxV1iXZ7xvx++nNI8AiNjE86EWEQ84N58x8Z4eKcX6O Wfa1LRUanC7ew== Archived-At: Subject: Re: [dispatch] Updated PERC Charter proposal X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 03 Jun 2015 15:57:18 -0000 On 6/3/15 8:58 AM, Magnus Westerlund wrote: > Hutton, Andrew skrev den 2015-06-03 10:42: >> I agree there is some value in exploring the recording use case it is >> one of the first questions everybody asks when discussing PERC. > > From my perspective there are two ways of doing recording of media > content in PERC. > > 1. Invite the recorder as a full fledged authenticated session > participant that use the normal way of getting the keys to the media as > any other endpoint. > > 2. The recorder only stores the encrypted media content, thus being a > semi-trusted entity to that are allowed to get a copy or be integrated > into the central forwarders. At the time one wants to access the > recorded content one will have to request the relevant keys from the > key-management function, that will also have to have stored the relevant > group keys for the session to enable decryption. > > I would claim that the second one is the securer, and enables better > tracking of who access recordings of a secured conference. These sound reasonable to me. IIUC, (2) could be complicated because each time a new participant joins or leaves there must be new keys. Thanks, Paul >> Hope we are allowed to consider this. > > The charter talks about informing and coordinating with SIPREC. This to > have an exchange about the possibilities. However, it is not a work item > of the PERC WG to specify a solution for recording. I would expect any > technical work on solving PERC recording would need to be chartered in > the most relevant WG. I think the ones interested in recording should be > active in the WG work to ensure that the developed solution do support > recording. If there are contention between the goals, then we will need > to have a serious discussion. But, remember that we have clear goals of > ensuring end to end security, thus compromises to the security model to > fit recording will be unlikely to be accepted. > > Cheers > > 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 > ---------------------------------------------------------------------- > > _______________________________________________ > dispatch mailing list > dispatch@ietf.org > https://www.ietf.org/mailman/listinfo/dispatch > From nobody Wed Jun 3 09:03:27 2015 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 66DB41A914B for ; Wed, 3 Jun 2015 09:03:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.977 X-Spam-Level: X-Spam-Status: No, score=-1.977 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham 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 iDCimwzZPv4J for ; Wed, 3 Jun 2015 09:03:24 -0700 (PDT) Received: from mail-wi0-f172.google.com (mail-wi0-f172.google.com [209.85.212.172]) (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 EE96F1A9145 for ; Wed, 3 Jun 2015 09:03:23 -0700 (PDT) Received: by wifw1 with SMTP id w1so27931020wif.0 for ; Wed, 03 Jun 2015 09:03:22 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type; bh=ogldrjhKIgoSsr4RAzhs9E20asMPmo9A8p/8aPxzwgo=; b=gh2vqL00XTpZc0ZZi2o4F76GDRaLa8A3z1icbnlzRnVjM1JdHdwQb/zKSIV8co6v1i dO2KBmo10JPplUswRRncSLn4OC67adcjx3RbTwDfpJaODnxaTCTw988AbsTSkojzzJA6 ISvjN5Wq3w9jAXSmP05ILLprQwpp0PdTtmaqvNQMfmDV6HDhC3b2fkUaLnpBEK+rXQuZ HXfeRXBYLYCMhtxkCU8H5/u81RG1fI2Xn2rQjFYrK1E+6QEMgBEMi2RnRjrTYodrVvZv uEtsANip0uFkMLlwgtcsNyY6qfmSdPj/ZyISmM2GElqxfzniq/qQjafcONVWgeCFLt2I Bz8g== X-Gm-Message-State: ALoCoQnj1Se+DFTc0K7t/KIf9JM65lajVY5EHOUgECM16aC89OWMPofvHvg1bNlB8tVTLDad6p3m X-Received: by 10.194.59.79 with SMTP id x15mr45152658wjq.81.1433347402636; Wed, 03 Jun 2015 09:03:22 -0700 (PDT) MIME-Version: 1.0 Received: by 10.27.225.14 with HTTP; Wed, 3 Jun 2015 09:02:42 -0700 (PDT) In-Reply-To: <556F23DB.8060306@alum.mit.edu> References: <55683230.3020600@ericsson.com> <556C2A44.8010805@ericsson.com> <556DDC0C.3010107@andyet.net> <556DF837.8050704@alum.mit.edu> <556EFA0E.8050408@ericsson.com> <556F23DB.8060306@alum.mit.edu> From: Eric Rescorla Date: Wed, 3 Jun 2015 09:02:42 -0700 Message-ID: To: Paul Kyzivat Content-Type: multipart/alternative; boundary=047d7b8737aec6387f05179f32b6 Archived-At: Cc: DISPATCH Subject: Re: [dispatch] Updated PERC Charter proposal X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 03 Jun 2015 16:03:26 -0000 --047d7b8737aec6387f05179f32b6 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On Wed, Jun 3, 2015 at 8:57 AM, Paul Kyzivat wrote: > On 6/3/15 8:58 AM, Magnus Westerlund wrote: > >> Hutton, Andrew skrev den 2015-06-03 10:42: >> >>> I agree there is some value in exploring the recording use case it is >>> one of the first questions everybody asks when discussing PERC. >>> >> >> From my perspective there are two ways of doing recording of media >> content in PERC. >> >> 1. Invite the recorder as a full fledged authenticated session >> participant that use the normal way of getting the keys to the media as >> any other endpoint. >> >> 2. The recorder only stores the encrypted media content, thus being a >> semi-trusted entity to that are allowed to get a copy or be integrated >> into the central forwarders. At the time one wants to access the >> recorded content one will have to request the relevant keys from the >> key-management function, that will also have to have stored the relevant >> group keys for the session to enable decryption. >> >> I would claim that the second one is the securer, and enables better >> tracking of who access recordings of a secured conference. >> > > These sound reasonable to me. IIUC, (2) could be complicated because each > time a new participant joins or leaves there must be new keys. > Not on joins, only on leaves. -Ekr > Thanks, > Paul > > > Hope we are allowed to consider this. >>> >> >> The charter talks about informing and coordinating with SIPREC. This to >> have an exchange about the possibilities. However, it is not a work item >> of the PERC WG to specify a solution for recording. I would expect any >> technical work on solving PERC recording would need to be chartered in >> the most relevant WG. I think the ones interested in recording should be >> active in the WG work to ensure that the developed solution do support >> recording. If there are contention between the goals, then we will need >> to have a serious discussion. But, remember that we have clear goals of >> ensuring end to end security, thus compromises to the security model to >> fit recording will be unlikely to be accepted. >> >> Cheers >> >> Magnus Westerlund >> >> ---------------------------------------------------------------------- >> Services, Media and Network features, Ericsson Research EAB/TXM >> ---------------------------------------------------------------------- >> Ericsson AB | Phone +46 10 7148287 >> F=C3=A4r=C3=B6gatan 6 | Mobile +46 73 0949079 >> SE-164 80 Stockholm, Sweden | mailto: magnus.westerlund@ericsson.com >> ---------------------------------------------------------------------- >> >> _______________________________________________ >> dispatch mailing list >> dispatch@ietf.org >> https://www.ietf.org/mailman/listinfo/dispatch >> >> > _______________________________________________ > dispatch mailing list > dispatch@ietf.org > https://www.ietf.org/mailman/listinfo/dispatch > --047d7b8737aec6387f05179f32b6 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


On Wed, Jun 3, 2015 at 8:57 AM, Paul Kyzivat <pkyzivat@alum.mit.ed= u> wrote:
= On 6/3/15 8:58 AM, Magnus Westerlund wrote:
Hutton, Andrew skrev den 2015-06-03 10:42:
I agree there is some value in exploring the recording use case it is
one of the first questions everybody asks when discussing PERC.

=C2=A0From my perspective there are two ways of doing recording of media content in PERC.

1. Invite the recorder as a full fledged authenticated session
participant that use the normal way of getting the keys to the media as
any other endpoint.

2. The recorder only stores the encrypted media content, thus being a
semi-trusted entity to that are allowed to get a copy or be integrated
into the central forwarders. At the time one wants to access the
recorded content one will have to request the relevant keys from the
key-management function, that will also have to have stored the relevant group keys for the session to enable decryption.

I would claim that the second one is the securer, and enables better
tracking of who access recordings of a secured conference.

 These sound reasonable to me. IIUC, (2) could be complicated because each t= ime a new participant joins or leaves there must be new keys.

Not on joins, only on leaves.

-Ekr
=C2=A0
=C2=A0 =C2=A0 =C2=A0 =C2=A0 Thanks,
=C2=A0 =C2=A0 =C2=A0 =C2=A0 Paul

Hope we are allowed to consider this.

The charter talks about informing and coordinating with SIPREC. This to
have an exchange about the possibilities. However, it is not a work item of the PERC WG to specify a solution for recording. I would expect any
technical work on solving PERC recording would need to be chartered in
the most relevant WG. I think the ones interested in recording should be active in the WG work to ensure that the developed solution do support
recording. If there are contention between the goals, then we will need
to have a serious discussion. But, remember that we have clear goals of
ensuring end to end security, thus compromises to the security model to
fit recording will be unlikely to be accepted.

Cheers

Magnus Westerlund

----------------------------------------------------------------------
Services, Media and Network features, Ericsson Research EAB/TXM
----------------------------------------------------------------------
Ericsson AB=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0| = Phone=C2=A0 +46 10 7148287
F=C3=A4r=C3=B6gatan 6=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0| Mobile +46 73 0949079
SE-164 80 Stockholm, Sweden | mailto: magnus.westerlund@ericsson.com
----------------------------------------------------------------------

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


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

--047d7b8737aec6387f05179f32b6-- From nobody Wed Jun 3 10:47:08 2015 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B09C51A9082; Wed, 3 Jun 2015 10:47:05 -0700 (PDT) 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] autolearn=ham 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 174wdUorvxRy; Wed, 3 Jun 2015 10:47:04 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 967E51A9236; Wed, 3 Jun 2015 10:47:04 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "Ben Campbell" To: "The IESG" X-Test-IDTracker: no X-IETF-IDTracker: 6.0.3.p2 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20150603174704.17626.84304.idtracker@ietfa.amsl.com> Date: Wed, 03 Jun 2015 10:47:04 -0700 Archived-At: Cc: dispatch@ietf.org Subject: [dispatch] Ben Campbell's Yes on charter-ietf-perc-00-03 X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.15 List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 03 Jun 2015 17:47:05 -0000 Ben Campbell has entered the following ballot position for charter-ietf-perc-00-03: Yes When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/charter-ietf-perc/ There are no remarks associated with this position. From nobody Wed Jun 3 11:50:31 2015 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 08EE91AD364; Wed, 3 Jun 2015 11:50:30 -0700 (PDT) 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] autolearn=ham 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 SjVY_3sOdk-d; Wed, 3 Jun 2015 11:50:29 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id EDBEC1AD365; Wed, 3 Jun 2015 11:50:28 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "Barry Leiba" To: "The IESG" X-Test-IDTracker: no X-IETF-IDTracker: 6.0.3.p2 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20150603185028.19683.28696.idtracker@ietfa.amsl.com> Date: Wed, 03 Jun 2015 11:50:28 -0700 Archived-At: Cc: dispatch@ietf.org Subject: [dispatch] Barry Leiba's Yes on charter-ietf-perc-00-03: (with COMMENT) X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.15 List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 03 Jun 2015 18:50:30 -0000 Barry Leiba has entered the following ballot position for charter-ietf-perc-00-03: Yes When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/charter-ietf-perc/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- Editorial: In three places, some sort of fancy apostrophe has come out as "???"; please replace the three trigrams each with a boring ASCII apostrophe. From nobody Wed Jun 3 17:09:22 2015 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2E3CE1B30AC for ; Wed, 3 Jun 2015 17:09:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.222 X-Spam-Level: X-Spam-Status: No, score=-1.222 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-0.001, SPF_NEUTRAL=0.779] autolearn=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 6m11gEMaPkpI for ; Wed, 3 Jun 2015 17:09:19 -0700 (PDT) Received: from outbound.mailhostbox.com (outbound.mailhostbox.com [162.222.225.25]) by ietfa.amsl.com (Postfix) with ESMTP id 4AB201B30A9 for ; Wed, 3 Jun 2015 17:09:18 -0700 (PDT) Received: from userPC (unknown [122.167.213.54]) (Authenticated sender: partha@parthasarathi.co.in) by outbound.mailhostbox.com (Postfix) with ESMTPA id 65470360D52; Thu, 4 Jun 2015 00:09:16 +0000 (GMT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=parthasarathi.co.in; s=20120823; t=1433376558; bh=i9GIRRLKgN44YB9oiJhYN6muttxCjhmMw3UoYSNyihI=; h=From:To:Cc:References:In-Reply-To:Subject:Date; b=Sxx0wM9qUevWeY7f5ZmfL6CisOYLhphNot7pdetFfLQfqGLf5GyxKYMh6FZ2dhH0/ ZF75Mcrw4/1tFcuic1NN8a89NuXpAWzxDKJ5GIAmT+168xFOnZRg5rjQuxqIWFyWnK lP9wAfayj6DXWPhX4AGFesbliQcqDAlDLJ0C0dm8= From: "Parthasarathi R" To: "'Hutton, Andrew'" , "'Ram Mohan R \(rmohanr\)'" References: <55683230.3020600@ericsson.com> <556C2A44.8010805@ericsson.com> <556DDC0C.3010107@andyet.net> <556DF837.8050704@alum.mit.edu>, In-Reply-To: Date: Thu, 4 Jun 2015 05:39:09 +0530 Message-ID: <006d01d09e5a$b0410200$10c30600$@co.in> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: AQHQnWNihHzG6QUxl02HeR+DxLSPGZ2Z+VaAgAB+W3SAAP/I0A== Content-Language: en-us X-CMAE-Score: 0 X-CMAE-Analysis: v=2.1 cv=Rpo4V3SK c=1 sm=1 tr=0 a=H+G4Ku4ocOoIotg0tggP2g==:117 a=H+G4Ku4ocOoIotg0tggP2g==:17 a=-NIMs_s3AAAA:8 a=8nJEP1OIZ-IA:10 a=VQADlPdMAAAA:8 a=MKtGQD3n3ToA:10 a=ZZnuYtJkoWoA:10 a=48vgC7mUAAAA:8 a=AUd_NHdVAAAA:8 a=xuZ767C1AAAA:8 a=bSPgVrhNYmrbXBBa8KIA:9 a=Aq5J_YdZWCenWMyf:21 a=AqMGYbIVGWMhB5QC:21 a=wPNLvfGTeEIA:10 X-CTCH-RefID: str=0001.0A020205.556F972E.009C, ss=1, re=0.000, recu=0.000, reip=0.000, cl=1, cld=1, fgs=0 X-CTCH-VOD: Unknown X-CTCH-Spam: Unknown X-CTCH-Score: 0.000 X-CTCH-Rules: X-CTCH-Flags: 0 X-CTCH-ScoreCust: 0.000 X-CTCH-SenderID: partha@parthasarathi.co.in X-CTCH-SenderID-TotalMessages: 1 X-CTCH-SenderID-TotalSpam: 0 X-CTCH-SenderID-TotalSuspected: 0 X-CTCH-SenderID-TotalBulk: 0 X-CTCH-SenderID-TotalConfirmed: 0 X-CTCH-SenderID-TotalRecipients: 0 X-CTCH-SenderID-TotalVirus: 0 X-CTCH-SenderID-BlueWhiteFlag: 0 X-Scanned-By: MIMEDefang 2.72 on 172.18.214.93 Archived-At: Cc: dispatch@ietf.org Subject: Re: [dispatch] Updated PERC Charter proposal X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 04 Jun 2015 00:09:21 -0000 I also agree to consider the requirement to see how SIPREC & PERC will=20 work together as it is important for Enterprise usecases. =20 > -----Original Message----- > From: dispatch [mailto:dispatch-bounces@ietf.org] On Behalf Of Hutton, > Andrew > Sent: Wednesday, June 03, 2015 2:13 PM > To: Ram Mohan R (rmohanr) > Cc: dispatch@ietf.org > Subject: Re: [dispatch] Updated PERC Charter proposal >=20 > I agree there is some value in exploring the recording use case it is > one of the first questions everybody asks when discussing PERC. >=20 > Hope we are allowed to consider this. >=20 > Andy >=20 >=20 >=20 > > On 3 Jun 2015, at 04:10, Ram Mohan R (rmohanr) > wrote: > > > > Hi Paul, > > > > -----Original Message----- > > From: Paul Kyzivat > > Date: Wednesday, 3 June 2015 12:08 am > > To: "dispatch@ietf.org" > > Subject: Re: [dispatch] Updated PERC Charter proposal > > > >> At some level this would "work", but it might require rethinking = the > >> whole approach to recording in an enterprise where recording is an > >> important part of the business. > >> > >> IIUC, with PERC there is still likely to be a conference focus, for > >> signaling, much as without PERC. But the details of how the media = is > >> handled will be different > > > > Yes. The way PERC handles media would likely bring in differences on > how > > recording needs to be done. > > IIUC PERC also brings in a model where in the conference cloud is > less > > trusted and hence there needs > > to be some thinking on how recording needs to be handled in general. > > > >> . Such a focus could automatically bring in a > >> recorder as a participant. That is already one of the models = covered > by > >> siprec. But PERC would prevent the focus and the PERC 'mixer" from > >> directly serving as the SRC. > > > > Yes. That=B9s exactly where I am coming from as well. The conference > model > > where a mixer acts as SRC that SIPREC defines today will not work > with > > PERC. > > I am trying to see if there is an interest in looking at this > problem. > > Given that recording is critical in many business I believe there > > is some value in looking at it. > > > > Regards, > > Ram > >> > >> Thanks, > >> Paul > >> > >> As long as PERC conferences are > >> > >>> On 6/2/15 12:40 PM, Eric Rescorla wrote: > >>> > >>> > >>> On Tue, Jun 2, 2015 at 9:38 AM, Peter Saint-Andre - &yet > >>> > wrote: > >>> > >>> On 6/2/15 10:21 AM, Eric Rescorla wrote: > >>> > >>> The way you record PERC sessions is by bringing them into > the > >>> call at > >>> the signaling level. There's no PERC-level accommodation > needed. > >>> > >>> > >>> Who is "them"? Do you mean "recording resources" of some kind > would > >>> be added as participants to the call? Just trying to clarify = the > >>> model... > >>> > >>> > >>> Yes. > >>> > >>> -Ekr > >>> > >>> > >>> > >>> > >>> _______________________________________________ > >>> dispatch mailing list > >>> dispatch@ietf.org > >>> https://www.ietf.org/mailman/listinfo/dispatch > >> > >> _______________________________________________ > >> dispatch mailing list > >> dispatch@ietf.org > >> https://www.ietf.org/mailman/listinfo/dispatch > > > > _______________________________________________ > > dispatch mailing list > > dispatch@ietf.org > > https://www.ietf.org/mailman/listinfo/dispatch >=20 > _______________________________________________ > dispatch mailing list > dispatch@ietf.org > https://www.ietf.org/mailman/listinfo/dispatch From nobody Thu Jun 4 13:12:42 2015 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0A0011A90CF for ; Thu, 4 Jun 2015 13:12:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.91 X-Spam-Level: X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, T_RP_MATCHES_RCVD=-0.01] autolearn=ham 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 pPJUh7oIbd4P for ; Thu, 4 Jun 2015 13:12:40 -0700 (PDT) Received: from nostrum.com (raven-v6.nostrum.com [IPv6:2001:470:d:1130::1]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3801D1A8706 for ; Thu, 4 Jun 2015 13:12:40 -0700 (PDT) Received: from [10.0.1.23] (cpe-70-119-203-4.tx.res.rr.com [70.119.203.4]) (authenticated bits=0) by nostrum.com (8.15.1/8.14.9) with ESMTPSA id t54KCPaD053823 (version=TLSv1 cipher=DHE-RSA-AES128-SHA bits=128 verify=NO); Thu, 4 Jun 2015 15:12:36 -0500 (CDT) (envelope-from ben@nostrum.com) X-Authentication-Warning: raven.nostrum.com: Host cpe-70-119-203-4.tx.res.rr.com [70.119.203.4] claimed to be [10.0.1.23] From: "Ben Campbell" To: "Parthasarathi R" Date: Thu, 04 Jun 2015 15:12:25 -0500 Message-ID: <780FAA10-DE23-49C2-BB7E-5DB92AC2208F@nostrum.com> In-Reply-To: <006d01d09e5a$b0410200$10c30600$@co.in> References: <55683230.3020600@ericsson.com> <556C2A44.8010805@ericsson.com> <556DDC0C.3010107@andyet.net> <556DF837.8050704@alum.mit.edu> <006d01d09e5a$b0410200$10c30600$@co.in> MIME-Version: 1.0 Content-Type: text/plain; format=flowed X-Mailer: MailMate (1.9.1r5084) Archived-At: Cc: dispatch@ietf.org Subject: Re: [dispatch] Updated PERC Charter proposal X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 04 Jun 2015 20:12:41 -0000 On 3 Jun 2015, at 19:09, Parthasarathi R wrote: > I also agree to consider the requirement to see how SIPREC & PERC will > work together as it is important for Enterprise usecases. (Trying to separate this out from the mechanism discussion over the last couple of days...) Is the charter text about coordinating with SIPREC insufficient for this purpose? From nobody Thu Jun 4 22:03:35 2015 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 36EB11B2BB3 for ; Thu, 4 Jun 2015 22:03:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.511 X-Spam-Level: X-Spam-Status: No, score=-14.511 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham 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 E9GHgDX1RVmP for ; Thu, 4 Jun 2015 22:03:32 -0700 (PDT) Received: from rcdn-iport-3.cisco.com (rcdn-iport-3.cisco.com [173.37.86.74]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 143351B2BE1 for ; Thu, 4 Jun 2015 22:02:51 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=840; q=dns/txt; s=iport; t=1433480571; x=1434690171; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=H8wRnyGZocl+gpxKrTXj1aDW6MwVFQ0gQlMjnNEiVrc=; b=EEgJknyBeZrLvr1iokinBlJ/gNxTmUtVt8HTC6t6yi4ORv8iturqVSv3 Wv3zxJuNXzxs0jbpikz1C2VQczN0/KVYhMfz7/XqcWO//c6RIpA8zflsw KWSqZac5qlfdTEJvVbbYgjgoyCgVJ/CVu07zfe2Z0MKiUe3v6+hXXO2XJ o=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: A0AjBADbLHFV/49dJa1bgxCBMga+UQmHUgKBLzgUAQEBAQEBAYEKhCIBAQEEOj8MBAIBCBEDAQIBHhAyHQgCBAENBYgt20UBAQEBAQEBAQEBAQEBAQEBAQEBGYtDhQYHBoQnAQSTGoZOhFaXUCRhgxZvgUaBAQEBAQ X-IronPort-AV: E=Sophos;i="5.13,556,1427760000"; d="scan'208";a="4704955" Received: from rcdn-core-7.cisco.com ([173.37.93.143]) by rcdn-iport-3.cisco.com with ESMTP; 05 Jun 2015 05:02:51 +0000 Received: from xhc-aln-x02.cisco.com (xhc-aln-x02.cisco.com [173.36.12.76]) by rcdn-core-7.cisco.com (8.14.5/8.14.5) with ESMTP id t5552org022330 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Fri, 5 Jun 2015 05:02:50 GMT Received: from xmb-aln-x05.cisco.com ([169.254.11.78]) by xhc-aln-x02.cisco.com ([173.36.12.76]) with mapi id 14.03.0195.001; Fri, 5 Jun 2015 00:02:47 -0500 From: "Ram Mohan R (rmohanr)" To: Ben Campbell , Parthasarathi R Thread-Topic: [dispatch] Updated PERC Charter proposal Thread-Index: AQHQn0zdkh59aGNCBkW9506d2tXpsg== Date: Fri, 5 Jun 2015 05:02:47 +0000 Message-ID: References: <55683230.3020600@ericsson.com> <556C2A44.8010805@ericsson.com> <556DDC0C.3010107@andyet.net> <556DF837.8050704@alum.mit.edu> <006d01d09e5a$b0410200$10c30600$@co.in> <780FAA10-DE23-49C2-BB7E-5DB92AC2208F@nostrum.com> In-Reply-To: <780FAA10-DE23-49C2-BB7E-5DB92AC2208F@nostrum.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.4.7.141117 x-originating-ip: [10.65.62.184] Content-Type: text/plain; charset="us-ascii" Content-ID: <3BDEE047893E854687E28832BE17E3F3@emea.cisco.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Cc: "dispatch@ietf.org" Subject: Re: [dispatch] Updated PERC Charter proposal X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 05 Jun 2015 05:03:34 -0000 Proposed text WFM and I assume SIPREC WG would accomodate this discussions and any deliverables around it. Regards, Ram -----Original Message----- From: Ben Campbell Date: Friday, 5 June 2015 1:42 am To: Parthasarathi R Cc: "Hutton, Andrew" , Cisco Employee , "dispatch@ietf.org" Subject: Re: [dispatch] Updated PERC Charter proposal >On 3 Jun 2015, at 19:09, Parthasarathi R wrote: > >> I also agree to consider the requirement to see how SIPREC & PERC will >> work together as it is important for Enterprise usecases. > >(Trying to separate this out from the mechanism discussion over the last >couple of days...) > >Is the charter text about coordinating with SIPREC insufficient for this >purpose? From nobody Fri Jun 5 06:22:12 2015 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BDAB71A871B; Fri, 5 Jun 2015 06:22:07 -0700 (PDT) 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] autolearn=ham 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 EzIl8Eg0IaDJ; Fri, 5 Jun 2015 06:22:06 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 0FFE81A870B; Fri, 5 Jun 2015 06:22:06 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "Stephen Farrell" To: "The IESG" X-Test-IDTracker: no X-IETF-IDTracker: 6.0.3.p2 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20150605132206.12593.88582.idtracker@ietfa.amsl.com> Date: Fri, 05 Jun 2015 06:22:06 -0700 Archived-At: Cc: dispatch@ietf.org Subject: [dispatch] Stephen Farrell's Yes on charter-ietf-perc-00-03: (with COMMENT) X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.15 List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 05 Jun 2015 13:22:07 -0000 Stephen Farrell has entered the following ballot position for charter-ietf-perc-00-03: Yes When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/charter-ietf-perc/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- This is a good thing. I have a few non-blocking questions. It's fine if those are answered now or during external review. - I think I'm fine with the WG figuring this out but do we have any current view as to how much metadata has to be visible to the media distribution devices? - does "source authentication" here really mean identifying the source (e.g. as a person/user) or simply as a valid participant in the conference (e.g. via possession of some key shared by the UAs and the media distribution device)? - What does "implementable by" SIP and WebRTC mean? Do you mean a single call with both kinds of UA present or not? From nobody Fri Jun 5 12:17:28 2015 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 676841A874D for ; Fri, 5 Jun 2015 12:17:27 -0700 (PDT) X-Quarantine-ID: X-Virus-Scanned: amavisd-new at amsl.com X-Amavis-Alert: BAD HEADER SECTION, Duplicate header field: "MIME-Version" X-Spam-Flag: NO X-Spam-Score: -7.011 X-Spam-Level: X-Spam-Status: No, score=-7.011 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham 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 nLuK2B3_eaaR for ; Fri, 5 Jun 2015 12:17:25 -0700 (PDT) Received: from wolverine02.qualcomm.com (wolverine02.qualcomm.com [199.106.114.251]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CAAFA1A700A for ; Fri, 5 Jun 2015 12:17:25 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=qti.qualcomm.com; i=@qti.qualcomm.com; q=dns/txt; s=qcdkim; t=1433531845; x=1465067845; h=message-id:date:to:from:subject; bh=auhn9bcaf2jztQKOhbG5O2g9OWrKjOfILkQbwBR6rbo=; b=W0MkIV8pR38IoQOcN+E3LWoejXoe/Fm+k5XdaNVrxEs0DaKQ96akIaDc OTXVDuVGiZwbF2Ske/2fsVZiMMxa0w0vz5sFnMJ8NIXa+qjndGPRz/o0f QQEb3nKsGgQuv32jHA66hSoVCfWZtiCWfK0GAu238V0gj3NBas3wPA3p5 o=; X-IronPort-AV: E=McAfee;i="5700,7163,7823"; a="214424311" Received: from ironmsg04-r.qualcomm.com ([172.30.46.18]) by wolverine02.qualcomm.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 05 Jun 2015 12:17:25 -0700 X-IronPort-AV: E=Sophos;i="5.13,560,1427785200"; d="scan'208";a="987131209" Received: from plus.qualcomm.com ([10.52.255.8]) by Ironmsg04-R.qualcomm.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 05 Jun 2015 12:17:25 -0700 Received: from ironmsg02-R.qualcomm.com (ironmsg02-R.qualcomm.com [172.30.46.16]) by plus.qualcomm.com (8.14.2/8.14.2/1.0) with ESMTP id t55JHORF007265; Fri, 5 Jun 2015 12:17:24 -0700 X-IronPort-AV: E=Sophos;i="5.13,560,1427785200"; d="scan'208";a="485523236" X-ojodefuego: yes Received: from myvpn-l-00447.ras.qualcomm.com (HELO [99.111.97.136]) ([10.64.135.38]) by ironmsg02-R.qualcomm.com with ESMTP; 05 Jun 2015 12:17:23 -0700 Mime-Version: 1.0 Message-Id: X-Mailer: Eudora for Mac OS X Date: Fri, 5 Jun 2015 12:15:05 -0700 To: dispatch@ietf.org From: Randall Gellens Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Random-Sig-Tag: 1.0b28 X-Random-Sig-Tag: 1.0b28 X-Random-Sig-Tag: 1.0b28 X-Random-Sig-Tag: 1.0b28 X-Random-Sig-Tag: 1.0b28 Archived-At: Subject: [dispatch] Confirmed: Virtual Bar-BoF for SLIM: June 18 @2-3 PDT X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 05 Jun 2015 19:17:27 -0000 The time and date for the virtual Bar-BoF for SLIM (from the Doodle poll) is June 18 at 2-3 PDT (5-6 EDT). To follow up on the SLIM face-to-face discussion in Dallas, this virtual bar-BoF provides an opportunity for further discussion on moving forward with a charter. In particular: (1) Are there objections to the current proposed charter wording, or is it acceptable? (2) Are there objections to moving forward on this basis? Please participate in the virtual Bar-BoF. The WebEx link will be sent in advance. I'm sending this message to the dispatch list, but all discussion should take place on the SLIM list. -- Randall Gellens Opinions are personal; facts are suspect; I speak for myself only -------------- Randomly selected tag: --------------- Never put off till tomorrow what you can avoid altogether. From nobody Sun Jun 7 10:59:39 2015 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6097D1ACCE3 for ; Sun, 7 Jun 2015 10:59:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.7 X-Spam-Level: X-Spam-Status: No, score=0.7 tagged_above=-999 required=5 tests=[BAYES_50=0.8, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham 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 uYP3Ns_qPn_a for ; Sun, 7 Jun 2015 10:59:35 -0700 (PDT) Received: from mail-wg0-x22f.google.com (mail-wg0-x22f.google.com [IPv6:2a00:1450:400c:c00::22f]) (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 275C91ACCE1 for ; Sun, 7 Jun 2015 10:59:35 -0700 (PDT) Received: by wgme6 with SMTP id e6so87376955wgm.2 for ; Sun, 07 Jun 2015 10:59:33 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=from:to:cc:references:in-reply-to:subject:date:message-id :mime-version:content-type:content-transfer-encoding:thread-index :content-language; bh=DV8MN15g6TtGel27NAwIdJftWNqfDbslmfodlJK8Y04=; b=x+l487G85ZDo6JMGHuOomiOOdK9pHa2Wh2Mhu03ikiSl/K13u7XG9JsSJB1cve/3PG jvlb/Tv0JxBxXyzQCfWpW5wg83jnbSJS7daKyPYuuLhth8ERwniZbxIMZOBRjC2ZzCKZ C9MEqp8wP42LeTX0KFjgGKltgjbu+0KhSzuBp7nxlpuPbLfTYuxsYU7MsEKqsZSj58Zb VWiaBRBc2o8aSx4Gan20YlGvXrIoui3JkpjcOfg3TLxqNP7aUaf8cGbaz3DlrLiQWzH/ alD/eBfWxzWRpZlyGbSTvphmGxADNKo0UQZ3IwJIRGNl037CzFbS5Me4DcQ87z1DLgbP Ar9A== X-Received: by 10.194.5.74 with SMTP id q10mr23748405wjq.27.1433699973856; Sun, 07 Jun 2015 10:59:33 -0700 (PDT) Received: from RoniE (bzq-79-178-33-123.red.bezeqint.net. [79.178.33.123]) by mx.google.com with ESMTPSA id q4sm471577wja.24.2015.06.07.10.59.31 (version=TLSv1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Sun, 07 Jun 2015 10:59:32 -0700 (PDT) From: "Roni Even" To: "'Magnus Westerlund'" , "'Hutton, Andrew'" , "'Ram Mohan R \(rmohanr\)'" References: <55683230.3020600@ericsson.com> <556C2A44.8010805@ericsson.com> <556DDC0C.3010107@andyet.net> <556DF837.8050704@alum.mit.edu>, <556EFA0E.8050408@ericsson.com> In-Reply-To: <556EFA0E.8050408@ericsson.com> Date: Sun, 7 Jun 2015 20:59:24 +0300 Message-ID: <0b9601d0a14b$b2374490$16a5cdb0$@gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQMeczP7p56zGI9386mjnB7ayVQMqQMrehJXAnvFbc0CR27rYgKr26SIAeyhdVIBb+KmngIamlaNAobT3r8B/JK9fAGtG1EQAYQ0ClYB6V2rt5o4LW6Q Content-Language: en-us Archived-At: Cc: dispatch@ietf.org Subject: Re: [dispatch] Updated PERC Charter proposal X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 07 Jun 2015 17:59:37 -0000 Hi, My personal view is that if there is a requirement to record a = multipoint conference as specified in section 3.1.5 of RFC7245, you should not use = a PERC conferencing server for conferencing.=20 Magnus two cases are correct but will not supply a good recording = solution. My view is that the recorded content should be managed by the conference server (it will be the SRC as defined in SIPREC) and not by a = conference participants, so in the first case where the recorder is a participant = it will not have a full view of the conference but will get what the PERC server sends it as a regular participant invited by another participant (e.g. not aware of side conference or get only part all the media = streams in the conference). The PERC server cannot define the recorder as a special user since this will contradict the requirement that it is not trusted = to render the media. In the second case, if the PERC server send the media to the recorder encrypted this phase will work but why should the recorder get the keys = from the KMF if the decision to send the media to it was done by the = non-trusted PERC server. Roni Even=20 > -----Original Message----- > From: dispatch [mailto:dispatch-bounces@ietf.org] On Behalf Of Magnus > Westerlund > Sent: 03 June, 2015 3:59 PM > To: Hutton, Andrew; Ram Mohan R (rmohanr) > Cc: dispatch@ietf.org > Subject: Re: [dispatch] Updated PERC Charter proposal >=20 > Hutton, Andrew skrev den 2015-06-03 10:42: > > I agree there is some value in exploring the recording use case it = is > > one of the first questions everybody asks when discussing PERC. >=20 > From my perspective there are two ways of doing recording of media content > in PERC. >=20 > 1. Invite the recorder as a full fledged authenticated session = participant that > use the normal way of getting the keys to the media as any other = endpoint. >=20 > 2. The recorder only stores the encrypted media content, thus being a semi- > trusted entity to that are allowed to get a copy or be integrated into = the central > forwarders. At the time one wants to access the recorded content one = will have > to request the relevant keys from the key-management function, that = will also > have to have stored the relevant group keys for the session to enable > decryption. >=20 > I would claim that the second one is the securer, and enables better tracking of > who access recordings of a secured conference. >=20 > > > > Hope we are allowed to consider this. >=20 > The charter talks about informing and coordinating with SIPREC. This = to have > an exchange about the possibilities. However, it is not a work item of = the PERC > WG to specify a solution for recording. I would expect any technical = work on > solving PERC recording would need to be chartered in the most relevant = WG. I > think the ones interested in recording should be active in the WG work = to > ensure that the developed solution do support recording. If there are > contention between the goals, then we will need to have a serious discussion. > But, remember that we have clear goals of ensuring end to end = security, thus > compromises to the security model to fit recording will be unlikely to = be > accepted. >=20 > Cheers >=20 > Magnus Westerlund >=20 > ---------------------------------------------------------------------- > Services, Media and Network features, Ericsson Research EAB/TXM > ---------------------------------------------------------------------- > Ericsson AB | Phone +46 10 7148287 > F=E4r=F6gatan 6 | Mobile +46 73 0949079 > SE-164 80 Stockholm, Sweden | mailto: magnus.westerlund@ericsson.com > ---------------------------------------------------------------------- >=20 > _______________________________________________ > dispatch mailing list > dispatch@ietf.org > https://www.ietf.org/mailman/listinfo/dispatch From nobody Mon Jun 8 01:26:31 2015 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CCE841B2D6C for ; Mon, 8 Jun 2015 01:26:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.801 X-Spam-Level: X-Spam-Status: No, score=-2.801 tagged_above=-999 required=5 tests=[BAYES_05=-0.5, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham 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 CbY84gtJDfc0 for ; Mon, 8 Jun 2015 01:26:28 -0700 (PDT) Received: from sesbmg22.ericsson.net (sesbmg22.ericsson.net [193.180.251.48]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AA9141A1AB3 for ; Mon, 8 Jun 2015 01:26:27 -0700 (PDT) X-AuditID: c1b4fb30-f799f6d000000faf-fa-557551b159dc Received: from ESESSHC016.ericsson.se (Unknown_Domain [153.88.253.125]) by sesbmg22.ericsson.net (Symantec Mail Security) with SMTP id 41.04.04015.1B155755; Mon, 8 Jun 2015 10:26:25 +0200 (CEST) Received: from [127.0.0.1] (153.88.183.153) by smtp.internal.ericsson.com (153.88.183.68) with Microsoft SMTP Server id 14.3.210.2; Mon, 8 Jun 2015 10:26:24 +0200 Message-ID: <557551B0.4060109@ericsson.com> Date: Mon, 8 Jun 2015 10:26:24 +0200 From: Magnus Westerlund User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.7.0 MIME-Version: 1.0 To: Eric Rescorla , Paul Kyzivat References: <55683230.3020600@ericsson.com> <556C2A44.8010805@ericsson.com> <556DDC0C.3010107@andyet.net> <556DF837.8050704@alum.mit.edu> <556EFA0E.8050408@ericsson.com> <556F23DB.8060306@alum.mit.edu> In-Reply-To: Content-Type: text/plain; charset="windows-1252"; format=flowed Content-Transfer-Encoding: 8bit X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFlrDLMWRmVeSWpSXmKPExsUyM+Jvre7GwNJQg0fvjSyWTlrAarHi9Tl2 ixUbDrA6MHv8ff+ByWPJkp9MHpMftzEHMEdx2aSk5mSWpRbp2yVwZZybKVrwg6tiaZNNA+Md ji5GTg4JAROJnx3T2SFsMYkL99azdTFycQgJHGWU6L3wkxHCWcYosenpVWaQKl4BbYnbj54w gdgsAioSdz/tYAOx2QQsJG7+aASzRQWiJKY+XscCUS8ocXLmEzBbRMBN4u/MB0BDOTiYBRQk 1qznBAkLC5hKLNn5A2rxYVaJF9vOgO3iFAiUaFt/lR2i3l7iwdYykDCzgLxE89bZYCVCQOc0 NHWwTmAUnIVk2yyEjllIOhYwMq9iFC1OLU7KTTcy0kstykwuLs7P08tLLdnECAzeg1t+G+xg fPnc8RCjAAejEg/vg30loUKsiWXFlbmHGKU5WJTEeWdszgsVEkhPLEnNTk0tSC2KLyrNSS0+ xMjEwSnVwLi9/+Wbdceu65zdaW/2fp/7wthbxaxsrYtmr/PbJDunqeGVU5LDX+/q/NXyVllb lFJdJ7jxuGtG5kbmbA04yz+FMVagcO7v0zNfaQuJbtVzfq64Kuv0QeudjXnZX+QlGqO31Mqk bP21wEzBJt1iZ8StVRWTVCx3vuK5fiZWKzbo3MKvATbuYUosxRmJhlrMRcWJALqAYl8/AgAA Archived-At: Cc: DISPATCH Subject: Re: [dispatch] Updated PERC Charter proposal X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 08 Jun 2015 08:26:30 -0000 EKR, Eric Rescorla skrev den 2015-06-03 18:02: > > On Wed, Jun 3, 2015 at 8:57 AM, Paul Kyzivat > wrote: > These sound reasonable to me. IIUC, (2) could be complicated because > each time a new participant joins or leaves there must be new keys. > > > Not on joins, only on leaves. > Are you certain? This may depend on how the solution is done, but if one takes the proposal so far, where each participant gets a copy of the current session master EKT key, then gets each participants transmission key wrapped by EKT master. If attacker can get access to the media packet prior to it joins the session, then as it joins the session it can later decrypt the EKT packets recorded. Thus, you can potentially do the equivalent of listening at the door before you enter the room, but only after you have joined. Cheers 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 Jun 8 04:59:18 2015 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7846F1A6F22; Mon, 8 Jun 2015 04:59:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.201 X-Spam-Level: X-Spam-Status: No, score=-4.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham 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 AwRxUrqWWjG1; Mon, 8 Jun 2015 04:59:08 -0700 (PDT) Received: from sessmg23.ericsson.net (sessmg23.ericsson.net [193.180.251.45]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 582481A6F27; Mon, 8 Jun 2015 04:59:07 -0700 (PDT) X-AuditID: c1b4fb2d-f794d6d000004501-9f-55758389e4e2 Received: from ESESSHC024.ericsson.se (Unknown_Domain [153.88.253.125]) by sessmg23.ericsson.net (Symantec Mail Security) with SMTP id 51.41.17665.98385755; Mon, 8 Jun 2015 13:59:05 +0200 (CEST) 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.210.2; Mon, 8 Jun 2015 13:59:04 +0200 Message-ID: <55758388.3030101@ericsson.com> Date: Mon, 8 Jun 2015 13:59:04 +0200 From: Magnus Westerlund User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.7.0 MIME-Version: 1.0 To: Stephen Farrell , The IESG References: <20150605132206.12593.88582.idtracker@ietfa.amsl.com> In-Reply-To: <20150605132206.12593.88582.idtracker@ietfa.amsl.com> Content-Type: text/plain; charset="windows-1252"; format=flowed Content-Transfer-Encoding: 8bit X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFlrOLMWRmVeSWpSXmKPExsUyM+JvrW5nc2mowYW/GhZLJy1gtZjxZyKz xfS919gdmD3Wdl9l81iy5CdTAFMUl01Kak5mWWqRvl0CV8bk95+YCg7JVew8M5uxgfG2RBcj J4eEgInE5DM7WCFsMYkL99azdTFycQgJHGWUOLnkIxOEs4xR4sf1i+xdjBwcvALaEv/m6YM0 sAioSKyc95wRxGYTsJC4+aORDcQWFYiSmPp4HQuIzSsgKHFy5hMwW0TAU+Jh3ykwm1lAXOJZ 23M2kJHCQPUb9omChIUEHCVubWxgBrE5BZwkljw6wAJSwixgL/FgaxlEp7xE89bZzBDl2hIN TR2sExgFZyFZNguhYxaSjgWMzKsYRYtTi4tz042M9VKLMpOLi/Pz9PJSSzYxAkP24JbfujsY V792PMQowMGoxMP7YF9JqBBrYllxZe4hRmkOFiVx3hmb80KFBNITS1KzU1MLUovii0pzUosP MTJxcEo1MDL5PrnxeMqWrL8fHjnvL40UMFLeztD94F/e858cEvz/ZW8+u1iXf+coj8d7g9gS fYUYm+X7Rczdbhxzez5HMjlw/brVTqZs7/osrno597x6ECd/fudRI7aontgLBxQET64TNrpy ZJqH0vpHi+eGh7Y8Mp7v1Vf6RrP5pqjtnmn1h5d2+GcsXafEUpyRaKjFXFScCACo3NCvOgIA AA== Archived-At: Cc: dispatch@ietf.org Subject: Re: [dispatch] Stephen Farrell's Yes on charter-ietf-perc-00-03: (with COMMENT) X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 08 Jun 2015 11:59:13 -0000 Hi Stephen, An attempt to answer your comments and questions. Stephen Farrell skrev den 2015-06-05 15:22: > Stephen Farrell has entered the following ballot position for > charter-ietf-perc-00-03: Yes > > When responding, please keep the subject line intact and reply to all > email addresses included in the To and CC lines. (Feel free to cut this > introductory paragraph, however.) > > > > The document, along with other ballot positions, can be found here: > https://datatracker.ietf.org/doc/charter-ietf-perc/ > > > > ---------------------------------------------------------------------- > COMMENT: > ---------------------------------------------------------------------- > > > This is a good thing. I have a few non-blocking questions. It's > fine if those are answered now or during external review. > > - I think I'm fine with the WG figuring this out but do we have > any current view as to how much metadata has to be visible to > the media distribution devices? There has been some work ongoing also on this. For voice activity based switching, at minimal something like the client to mixer audio levels (RFC6464) will be needed. To be able to determine where it is appropriate to perform an actual switch for media encodings with long prediction chains, like video, there is a draft for an header extension for frame markings: https://datatracker.ietf.org/doc/draft-berger-avtext-framemarking/ > > - does "source authentication" here really mean identifying > the source (e.g. as a person/user) or simply as a valid > participant in the conference (e.g. via possession of some > key shared by the UAs and the media distribution device)? It means at a minimal to determine that the streams comes from a valid participant. As SRTP normally do not provide stronger guarantees, the only cipher for SRTP that can do more is TESLA based integrity checks defined in RFC 4383. However, my understanding is that it would be desirable to know which participant is the actual source of the content of an RTP stream. I think it should be a topic for the WG to discuss if the trade-offs for the security levels and decide on what is included in the solution. > > - What does "implementable by" SIP and WebRTC mean? Do you > mean a single call with both kinds of UA present or not? The solution proposals so far indicates a single solution for how to accomplish two tier of RTP payload data protection in SRTP. To that is the key-management solution. So far the discussed solutions are two components, one is the (likely EKT) method to provide (in-band) the actual transmission key used by a particular source for the inner security. The other part is how to key the other component with the necessary group key. From my perspective supporting the SRTP and EKT? parts in both types of end-points have no issues, thus enabling conference instances with both type of endpoints participating. For the master group key distribution there might exist reasons why that may differ between a SIP and WebRTC endpoint, but preferably they are common solutions. However, here I think the WG must be open and discuss how the integration of user authentication mechanism can occur, and the differences in server infrastructure for the relevant entities and what protocols are already in place. I hope this helps Cheers 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 Jun 8 05:24:37 2015 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4ECCA1A0366; Mon, 8 Jun 2015 05:24:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.21 X-Spam-Level: X-Spam-Status: No, score=-4.21 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, T_RP_MATCHES_RCVD=-0.01] autolearn=ham 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 YBGUQZopmFPe; Mon, 8 Jun 2015 05:24:33 -0700 (PDT) Received: from mercury.scss.tcd.ie (mercury.scss.tcd.ie [134.226.56.6]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 042B21A1ADA; Mon, 8 Jun 2015 05:24:31 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id C2E2ABEBC; Mon, 8 Jun 2015 13:24:28 +0100 (IST) X-Virus-Scanned: Debian amavisd-new at scss.tcd.ie Received: from mercury.scss.tcd.ie ([127.0.0.1]) by localhost (mercury.scss.tcd.ie [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cxnfVvbwKeke; Mon, 8 Jun 2015 13:24:26 +0100 (IST) Received: from [172.16.20.132] (62-50-200-74.client.stsn.net [62.50.200.74]) by mercury.scss.tcd.ie (Postfix) with ESMTPSA id 5AF2EBEB0; Mon, 8 Jun 2015 13:24:26 +0100 (IST) Message-ID: <55758979.1040207@cs.tcd.ie> Date: Mon, 08 Jun 2015 13:24:25 +0100 From: Stephen Farrell User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.7.0 MIME-Version: 1.0 To: Magnus Westerlund , The IESG References: <20150605132206.12593.88582.idtracker@ietfa.amsl.com> <55758388.3030101@ericsson.com> In-Reply-To: <55758388.3030101@ericsson.com> OpenPGP: id=D66EA7906F0B897FB2E97D582F3C8736805F8DA2; url= Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit Archived-At: Cc: dispatch@ietf.org Subject: Re: [dispatch] Stephen Farrell's Yes on charter-ietf-perc-00-03: (with COMMENT) X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 08 Jun 2015 12:24:36 -0000 On 08/06/15 12:59, Magnus Westerlund wrote: > Hi Stephen, > > An attempt to answer your comments and questions. Tanks Magnus, those are good (enough:-) answers. BTW - just to clarify in case it's useful - I interpret the name of this WG and the charter to be implicitly saying that the goal is to minimise the amount of data (whether metadata or not) that is meaningful to the media distribution device. If that's a bad assumption then it'd probably be good to bottom out on that during chartering. If it's a good assumption then maybe it's something to consider being explicit about in the charter. (Sorry, I forgot to say that in my initial ballot.) Cheers, S. > > Stephen Farrell skrev den 2015-06-05 15:22: >> Stephen Farrell has entered the following ballot position for >> charter-ietf-perc-00-03: Yes >> >> When responding, please keep the subject line intact and reply to all >> email addresses included in the To and CC lines. (Feel free to cut this >> introductory paragraph, however.) >> >> >> >> The document, along with other ballot positions, can be found here: >> https://datatracker.ietf.org/doc/charter-ietf-perc/ >> >> >> >> ---------------------------------------------------------------------- >> COMMENT: >> ---------------------------------------------------------------------- >> >> >> This is a good thing. I have a few non-blocking questions. It's >> fine if those are answered now or during external review. >> >> - I think I'm fine with the WG figuring this out but do we have >> any current view as to how much metadata has to be visible to >> the media distribution devices? > > There has been some work ongoing also on this. For voice activity based > switching, at minimal something like the client to mixer audio levels > (RFC6464) will be needed. > > To be able to determine where it is appropriate to perform an actual > switch for media encodings with long prediction chains, like video, > there is a draft for an header extension for frame markings: > https://datatracker.ietf.org/doc/draft-berger-avtext-framemarking/ > > >> >> - does "source authentication" here really mean identifying >> the source (e.g. as a person/user) or simply as a valid >> participant in the conference (e.g. via possession of some >> key shared by the UAs and the media distribution device)? > > It means at a minimal to determine that the streams comes from a valid > participant. As SRTP normally do not provide stronger guarantees, the > only cipher for SRTP that can do more is TESLA based integrity checks > defined in RFC 4383. However, my understanding is that it would be > desirable to know which participant is the actual source of the content > of an RTP stream. I think it should be a topic for the WG to discuss if > the trade-offs for the security levels and decide on what is included in > the solution. > >> >> - What does "implementable by" SIP and WebRTC mean? Do you >> mean a single call with both kinds of UA present or not? > > The solution proposals so far indicates a single solution for how to > accomplish two tier of RTP payload data protection in SRTP. To that is > the key-management solution. So far the discussed solutions are two > components, one is the (likely EKT) method to provide (in-band) the > actual transmission key used by a particular source for the inner > security. The other part is how to key the other component with the > necessary group key. > > From my perspective supporting the SRTP and EKT? parts in both types of > end-points have no issues, thus enabling conference instances with both > type of endpoints participating. For the master group key distribution > there might exist reasons why that may differ between a SIP and WebRTC > endpoint, but preferably they are common solutions. However, here I > think the WG must be open and discuss how the integration of user > authentication mechanism can occur, and the differences in server > infrastructure for the relevant entities and what protocols are already > in place. > > I hope this helps > > Cheers > > 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 Jun 8 12:15:30 2015 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 199721A014B for ; Mon, 8 Jun 2015 12:15:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.301 X-Spam-Level: X-Spam-Status: No, score=-2.301 tagged_above=-999 required=5 tests=[BAYES_40=-0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham 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 gOcuxyb9Q1G5 for ; Mon, 8 Jun 2015 12:15:28 -0700 (PDT) Received: from sessmg23.ericsson.net (sessmg23.ericsson.net [193.180.251.45]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BF4351A00FA for ; Mon, 8 Jun 2015 12:15:27 -0700 (PDT) X-AuditID: c1b4fb2d-f794d6d000004501-20-5575e9cdf5fe Received: from ESESSHC013.ericsson.se (Unknown_Domain [153.88.253.125]) by sessmg23.ericsson.net (Symantec Mail Security) with SMTP id 4C.CB.17665.DC9E5755; Mon, 8 Jun 2015 21:15:25 +0200 (CEST) Received: from ESESSMB209.ericsson.se ([169.254.9.72]) by ESESSHC013.ericsson.se ([153.88.183.57]) with mapi id 14.03.0210.002; Mon, 8 Jun 2015 21:15:25 +0200 From: Christer Holmberg To: "dispatch@ietf.org" Thread-Topic: New draft: draft-holmberg-dispatch-received-realm-00 Thread-Index: AdCiHwUUGsBUGXYYRyCmNYpBt1Qlew== Date: Mon, 8 Jun 2015 19:15:24 +0000 Message-ID: <7594FB04B1934943A5C02806D1A2204B1D8AA730@ESESSMB209.ericsson.se> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [153.88.183.148] Content-Type: multipart/alternative; boundary="_000_7594FB04B1934943A5C02806D1A2204B1D8AA730ESESSMB209erics_" MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFrrGLMWRmVeSWpSXmKPExsUyM+Jvre7Zl6WhBsc3qlksnbSA1YHRY8mS n0wBjFFcNimpOZllqUX6dglcGe2H/rIV9MhV3GqezNrAuFyqi5GTQ0LARGLu5M9sELaYxIV7 64FsLg4hgaOMEte23wVLCAksYpQ4OKmgi5GDg03AQqL7nzZIWERAW+Loqi5mEFtYwFbi65nf 7BBxJ4krPxewQNh6Eq0T77CC2CwCKhKHV7wGs3kFfCWevvnJBGIzAu39fmoNmM0sIC5x68l8 Joh7BCSW7DnPDGGLSrx8/I8VwlaSaFzyhBWiPl/i+eqPzBAzBSVOznzCMoFRaBaSUbOQlM1C UgYR15FYsPsTG4StLbFs4WtmGPvMgcdMyOILGNlXMYoWpxYX56YbGeulFmUmFxfn5+nlpZZs YgRGxMEtv3V3MK5+7XiIUYCDUYmH98G+klAh1sSy4srcQ4zSHCxK4rwzNueFCgmkJ5akZqem FqQWxReV5qQWH2Jk4uCUamB0WrpJiDPhg+/zyn07FmrfP/CbdcPLyMf2FhL3Krc4rXw7t3ld d9tnuRL14tXi6Z8WJWfwJ0kvWrfs35YlmZ/FLnlHaF7QWv5qk6O3Ocvlk2nxWtmKPUf3lpdO e2Elnzt7kY6vhsMGddn5Fu+3Te/RjOlIOu9SId1fdc9jpvfbd/s9L+59ZzRTiaU4I9FQi7mo OBEA0NfAvmkCAAA= Archived-At: Subject: [dispatch] New draft: draft-holmberg-dispatch-received-realm-00 X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 08 Jun 2015 19:15:30 -0000 --_000_7594FB04B1934943A5C02806D1A2204B1D8AA730ESESSMB209erics_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi, I've submitted a new draft to dispatch: draft-holmberg-dispatch-received-re= alm-00. The draft defines a new Via header field parameter, "received-realm= ", which network entry entities can insert in order to inform other entitie= s in the network from which network the request was received. Previous versions of the draft have been submitted to SIPCORE, but I was ad= vised by the SIPCORE chairs to submit it to DISPATCH. Compared to previous versions, there is a technical change: the entity whic= h inserts a parameter also calculates a HMAC value, which is inserted toget= her with the network value. Regards, Christer --_000_7594FB04B1934943A5C02806D1A2204B1D8AA730ESESSMB209erics_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi,

 

I’ve submitted a new draft to dispatch: draft-= holmberg-dispatch-received-realm-00. The draft defines a new Via header fie= ld parameter, “received-realm”, which network entry entities ca= n insert in order to inform other entities in the network from which network the request was received.

 

Previous versions of the draft have been submitted t= o SIPCORE, but I was advised by the SIPCORE chairs to submit it to DISPATCH= .

 

Compared to previous versions, there is a technical = change: the entity which inserts a parameter also calculates a HMAC value, = which is inserted together with the network value.

 

Regards,

 

Christer

--_000_7594FB04B1934943A5C02806D1A2204B1D8AA730ESESSMB209erics_-- From nobody Tue Jun 9 00:59:47 2015 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 843EC1ACD22; Tue, 9 Jun 2015 00:59:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.201 X-Spam-Level: X-Spam-Status: No, score=-4.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham 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 0-Eci7Xr9u4e; Tue, 9 Jun 2015 00:59:43 -0700 (PDT) Received: from sesbmg23.ericsson.net (sesbmg23.ericsson.net [193.180.251.37]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 584D31AD2B2; Tue, 9 Jun 2015 00:59:42 -0700 (PDT) X-AuditID: c1b4fb25-f79b66d000001131-c5-55769cece3a0 Received: from ESESSHC009.ericsson.se (Unknown_Domain [153.88.253.125]) by sesbmg23.ericsson.net (Symantec Mail Security) with SMTP id EE.29.04401.CEC96755; Tue, 9 Jun 2015 09:59:40 +0200 (CEST) Received: from [127.0.0.1] (153.88.183.153) by smtp.internal.ericsson.com (153.88.183.47) with Microsoft SMTP Server id 14.3.210.2; Tue, 9 Jun 2015 09:59:39 +0200 Message-ID: <55769CEB.3020409@ericsson.com> Date: Tue, 9 Jun 2015 09:59:39 +0200 From: Magnus Westerlund User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.7.0 MIME-Version: 1.0 To: DISPATCH list , IETF AVTCore WG References: <20150608194758.14681.73891.idtracker@ietfa.amsl.com> In-Reply-To: <20150608194758.14681.73891.idtracker@ietfa.amsl.com> X-Forwarded-Message-Id: <20150608194758.14681.73891.idtracker@ietfa.amsl.com> Content-Type: multipart/mixed; boundary="------------060706060505090303090804" X-Brightmail-Tracker: H4sIAAAAAAAAA2WSe0iTYRTGefd9m3O0epuaxwkWS8ELal6CQWYpVkIERggpQS77UGtO22yU ECw1JiGRpqhz1iRvU9NZoispcKEilpc0K1DBGzUvy3KmXTbavm9/SP33O4fnPOd5Dy+XEFjZ Qm6WLI+SyyRSEYdHVp+33Qpd1SqTD7WMe4nNJXo3cUOZjn2clVhf/5OVhFJ5MZcpaZaSkofH pvEypy2TRK4h6sZaWxGhQhuhd5E7F3A0PH6pcmN4H4zNdnDuIh5XgPsR6E2VbkzRiKCvz8Jy qvg4BCbKVthOJrE/dH/WcJzMwWL4tH2bZi+cChUL7SSj3wtD1Ys0e+ITYG0207MeOAkGl/XI yQIcB9ujo3TfHcdD78aIK9EZMBtqaSYc+q35ZZLRh4CqoJh9H2HNjhWaHTKGxVD9aBQxvB96 1rQEw9mwubTM+b+vRmDV8jX06j2gHn5D9wXYgKCizlvjOpj2+yRLQ9+lggXG0n6CKR4g2Oy0 sJ0FiVUkjBq6SWYkBN62btAxSBwMQzNq10Q5go/9ixxGFAhV+jGHiEvvfmI6yLQFMNtUyWKY D8Plgy55GjTNdLp8uhHUls6zmKyOGL13Mp0+BA6Cjhfh/z6TgyNhoPgD7eOJo6CrTE1n88Cn YWpoCjH+nmB5P0cwLITp9jqaEfaD7YEFehXGGOxlY6QOHW5BXgpKcSk7IzIqjJJnpSsUObIw GZX3FDm+aV/X7wAjmliNMyHMRaJdfF2iMlnAligVN7NNyJdLirz5Vc9kyQKcIcmjrlJULiW/ KL8upRQmxOK6C1UoInHFaswpkuVeaC40U21+P+ZqZNHDDfd8tUFJszW6wAR7z5/M8ApPXWy0 ciStmN+6lXIqvjEyPz39W03+2XclIt8me6PqirG/5dpDodFWWbNuKz8WHrD7a+ugVOqTQ3CC 5r/YJg+8OtoVwU84sl7g+/z1uZMl/jOFMeMpv3yW7CJSkSmJCCbkCslfapQwTYcDAAA= Archived-At: Subject: [dispatch] Fwd: New Non-WG Mailing List: Perc -- Privacy Enhanced RTP Conferencing X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 09 Jun 2015 07:59:44 -0000 --------------060706060505090303090804 Content-Type: text/plain; charset="utf-8"; format=flowed Content-Transfer-Encoding: 7bit Hi, A mailing list has now been created for the Privacy Enhanced RTP Conferencing (PERC) work. I suggest all interested to subscribe as we will soon start using it to discuss any related to PERC. Regarding the progress of PERC. The charter is currently in IESG internal review, that is why you seen some emails from IESG members. They will on Thursday decided if the charter shall go out for IETF review as a proposed new WG. Cheers Magnus Westerlund --------------060706060505090303090804 Content-Type: message/rfc822; name="New Non-WG Mailing List: Perc -- Privacy Enhanced RTP Conferencing.eml" Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename*0="New Non-WG Mailing List: Perc -- Privacy Enhanced RTP Confer"; filename*1="encing.eml" X-Mozilla-Keys: Received: from sessmg14.ericsson.net (153.88.183.153) by smtp.internal.ericsson.com (153.88.183.73) with Microsoft SMTP Server id 14.3.210.2; Mon, 8 Jun 2015 21:48:21 +0200 X-AuditID: c1b4fb3e-f792d6d000002c82-98-5575f182a471 Received: from mail.ietf.org (mail.ietf.org [4.31.198.44]) (using TLS with cipher AES256-SHA (256/256 bits)) (Client did not present a certificate) by sessmg14.ericsson.net (Symantec Mail Security) with SMTP id 0E.43.11394.481F5755; Mon, 8 Jun 2015 21:48:21 +0200 (CEST) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 330A11ACD35; Mon, 8 Jun 2015 12:48:02 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=ietf.org; s=ietf1; t=1433792882; bh=MlvCBiKb8VT27BadMJ9rczUUD8oxtnqvICHSZHS2c40=; h=MIME-Version:Content-Type:Content-Transfer-Encoding:From:To: Subject:Message-ID:Date:Cc:Reply-To:List-Id:List-Unsubscribe: List-Archive:List-Post:List-Help:List-Subscribe:Sender; b=m1lB2Tq2XHBftsKDCAUyymY9j+lCI3AYiAIjkTysqGdHnXQ6XWlMM7vDIIVGKZF3i J1mCnz91hrw4IG01nbU4YqEDiO50KAB4XWRnj5h95OArMeFSJJ75K2zcFuLLpq84bn nSkEoMdsS/IiWUk9FF2u4gPJfB0jubnrPjkifEMs= X-Original-To: ietf-announce@ietfa.amsl.com Delivered-To: ietf-announce@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 68FD91ACD1E; Mon, 8 Jun 2015 12:47:59 -0700 (PDT) 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] autolearn=ham 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 Q7YlDbndHNzc; Mon, 8 Jun 2015 12:47:58 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 5AE431A8F48; Mon, 8 Jun 2015 12:47:58 -0700 (PDT) Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: IETF Secretariat To: IETF Announcement List Subject: New Non-WG Mailing List: Perc -- Privacy Enhanced RTP Conferencing X-Test-IDTracker: no X-IETF-IDTracker: 6.0.3.p2 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20150608194758.14681.73891.idtracker@ietfa.amsl.com> Date: Mon, 8 Jun 2015 12:47:58 -0700 Archived-At: CC: , X-BeenThere: ietf-announce@ietf.org X-Mailman-Version: 2.1.15 Reply-To: List-Id: "IETF announcement list. No discussions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ietf-announce-bounces@ietf.org Sender: IETF-Announce X-Brightmail-Tracker: H4sIAAAAAAAAA1VSWUwTURTlTV/bsXbwOaBc6kZq3HDBBZOJGqPRxDXRD/nRGC060kZaSGcw NcZYTRVBicYoIhIDVq1gAEVEI0hCIwjigoCVD8SlWI1G64IRlYAznQr6d9475557zsujVWxA Y6B5h8jbbaZUo0aH8YSGGTMPfslIml36jubuNl/E3P5OP8VV+8q13MszmWruRPMmrsJTTHG1 7YcorrW8i+L238jBXLCuBHOB3D4Nl1fwU7tEv/LX96ea9WijbtF2PtWyi7cnLN6qM9cH16b3 aBydfS61EwXV2WgYDSQRCr62UwoeDS1d5ZpspKNZcoqCC55GKnxAUB14HWIwcWJ4fLUKKyPT 4eGVb0jGmMRD0/NMlTKRi2CgawApoqmQV9wiYVrCI6DUO1G5ZqHLczq8OhKevOsN463geX4t 7FOFoLaxFw/GyPYfDwVnyEhoOtONZVMVmQbltxPkaxWZADc/FqhkrCFzoeHwM42Mo8l8uNTh 18o4iqwBX5MvnC0aPj19pVKwATrLikIYkfHQ2+APBSKEQP+JFqysXQp3nLWUUngSuO61hfWb IetWo1aJMxlyH61QLCfCb/fj8FPHwoO2h6G1LImBY+2H0XE0Nf+fMvlDZfL/KVOIVCVolMAL gjVlTuIs3m7ZJghptlk2XqxA0r+pq/y9+Ba66FvuRYRGRj3zslZMYtWmXcJuqxfF0pRxFDPl Q0YSG5mctn232SSYt9gzUnnBi8bQ2BjDLLluS2JJiknkd/J8Om//y46laSMw/UFpcqSdT+Ed Oyyp4hBN0cO8CGi9MZpZ9lnSMEK6ySpYUhT+PppHX63rO0/RnScHzlMstqXZeEMMs0KWEllq zrANuv39/q1onCGKQREREaxeSmK1iP/z71GM1DCK0coueotNHNz3XopCSVF+fBfkKKJpiDI4 0WWUvG91x4uFLdxR1BtZvKqopjAvIe7cs5zm+oDzbeL47gXTLmWm43OOI2M23ZgXwPEHarhl c7e4chyunprCUvc98diGqqyzyxe6o8pm6jy+ZG6SK/dI9Zucu+pWt7ujcmBG2+fgnnUbDsRm a4d39++ZXFIZ561/0+PfW6FLTsyyGrFgNs2JV9kF0x9yT7VY+QMAAA== Return-Path: ietf-announce-bounces@ietf.org X-MS-Exchange-Organization-AuthSource: ESESSHC018.ericsson.se X-MS-Exchange-Organization-AuthAs: Anonymous X-MS-Exchange-Organization-AVStamp-Mailbox: MSFTFF;1;0;0 0 0 MIME-Version: 1.0 A new IETF non-working group email list has been created. List address: perc@ietf.org Archive: http://www.ietf.org/mail-archive/web/perc/ To subscribe: https://www.ietf.org/mailman/listinfo/perc Purpose: Discussion list for Privacy Enhanced RTP Conferencing (PERC). The purpose is to develop a solution based on SRTP that enables end-to-end security in a centralized multi-party conference, utilizing one or more semi-trusted central media forwarding devices. The media forwarding devices are not trusted with the media content, but can make selection decisions on which media streams to forward. In addition to the media protection also key-management will be defined. The goal is to enable integration in WebRTC endpoints, CLUE endpoints as well as endpoints using SIP to establish communication. For additional information, please contact the list administrators. --------------060706060505090303090804-- From nobody Wed Jun 10 06:06:37 2015 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0CCC61A1F73 for ; Wed, 10 Jun 2015 06:06:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.801 X-Spam-Level: X-Spam-Status: No, score=0.801 tagged_above=-999 required=5 tests=[BAYES_50=0.8, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-0.001] autolearn=ham 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 7VwsjTOGZAdI for ; Wed, 10 Jun 2015 06:06:32 -0700 (PDT) Received: from mail1.bemta5.messagelabs.com (mail1.bemta5.messagelabs.com [195.245.231.141]) (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 BAD0A1A1C04 for ; Wed, 10 Jun 2015 06:06:31 -0700 (PDT) Received: from [85.158.139.163] by server-5.bemta-5.messagelabs.com id 15/95-19215-65638755; Wed, 10 Jun 2015 13:06:30 +0000 X-Env-Sender: Peter.Dawes@vodafone.com X-Msg-Ref: server-4.tower-188.messagelabs.com!1433941589!9024730!1 X-Originating-IP: [195.232.244.136] X-StarScan-Received: X-StarScan-Version: 6.13.16; banners=-,-,- X-VirusChecked: Checked Received: (qmail 10002 invoked from network); 10 Jun 2015 13:06:29 -0000 Received: from mailout04.vodafone.com (HELO mailout04.vodafone.com) (195.232.244.136) by server-4.tower-188.messagelabs.com with DHE-RSA-AES256-SHA encrypted SMTP; 10 Jun 2015 13:06:29 -0000 Received: from mailint04.vodafone.com (mailint04.vodafone.com [195.232.244.201]) by mailout04.vodafone.com (Postfix) with ESMTP id 3m67qn3J2WznTX0; Wed, 10 Jun 2015 15:06:29 +0200 (CEST) Received: from mailint04.vodafone.com (localhost [127.0.0.1]) by mailint04.vodafone.com (Postfix) with ESMTP id 3m67qn2HkLzfZMq; Wed, 10 Jun 2015 15:06:29 +0200 (CEST) Received: from VOEXC06W.internal.vodafone.com (voexc06w.dc-ratingen.de [145.230.101.26]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by mailint04.vodafone.com (Postfix) with ESMTPS id 3m67qn1n6YzfZMR; Wed, 10 Jun 2015 15:06:29 +0200 (CEST) Received: from VOEXC09W.internal.vodafone.com (145.230.101.29) by VOEXC06W.internal.vodafone.com (145.230.101.26) with Microsoft SMTP Server (TLS) id 14.3.224.2; Wed, 10 Jun 2015 15:06:28 +0200 Received: from VOEXM31W.internal.vodafone.com ([169.254.7.90]) by VOEXC09W.internal.vodafone.com ([145.230.101.29]) with mapi id 14.03.0224.002; Wed, 10 Jun 2015 15:06:27 +0200 From: "Dawes, Peter, Vodafone Group" To: Christer Holmberg , "dispatch@ietf.org" Thread-Topic: New draft: draft-holmberg-dispatch-received-realm-00 Thread-Index: AdCiHwUUGsBUGXYYRyCmNYpBt1QlewBXgnVw Date: Wed, 10 Jun 2015 13:06:26 +0000 Message-ID: <4A4F136CBD0E0D44AE1EDE36C4CD9D99AEEE2567@VOEXM31W.internal.vodafone.com> References: <7594FB04B1934943A5C02806D1A2204B1D8AA730@ESESSMB209.ericsson.se> In-Reply-To: <7594FB04B1934943A5C02806D1A2204B1D8AA730@ESESSMB209.ericsson.se> Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: Content-Type: multipart/alternative; boundary="_000_4A4F136CBD0E0D44AE1EDE36C4CD9D99AEEE2567VOEXM31Winterna_" MIME-Version: 1.0 Archived-At: Subject: Re: [dispatch] New draft: draft-holmberg-dispatch-received-realm-00 X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 10 Jun 2015 13:06:36 -0000 --_000_4A4F136CBD0E0D44AE1EDE36C4CD9D99AEEE2567VOEXM31Winterna_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi Christer, I agree that it is useful for a (transit) network to know which network a r= equest arrived from, as this draft argues. But isn't this information to be= in the Via header field already in the entry before the transit network? T= he draft mentions that inter-operator identifier cannot be used but I think= the draft should expand on why a new header field parameter is needed. Regards, Peter From: dispatch [mailto:dispatch-bounces@ietf.org] On Behalf Of Christer Hol= mberg Sent: 08 June 2015 20:15 To: dispatch@ietf.org Subject: [dispatch] New draft: draft-holmberg-dispatch-received-realm-00 Hi, I've submitted a new draft to dispatch: draft-holmberg-dispatch-received-re= alm-00. The draft defines a new Via header field parameter, "received-realm= ", which network entry entities can insert in order to inform other entitie= s in the network from which network the request was received. Previous versions of the draft have been submitted to SIPCORE, but I was ad= vised by the SIPCORE chairs to submit it to DISPATCH. Compared to previous versions, there is a technical change: the entity whic= h inserts a parameter also calculates a HMAC value, which is inserted toget= her with the network value. Regards, Christer --_000_4A4F136CBD0E0D44AE1EDE36C4CD9D99AEEE2567VOEXM31Winterna_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi Christer,

I agree that it is use= ful for a (transit) network to know which network a request arrived from, a= s this draft argues. But isn’t this information to be in the Via head= er field already in the entry before the transit network? The draft mentions that inter-operator identifier cannot be used = but I think the draft should expand on why a new header field parameter is = needed.

 

Regards,

Peter

 

From:= dispatch [mailto:dispatch-bounces@ietf.org] On Behalf Of Christer Holmberg Sent: 08 June 2015 20:15
To: dispatch@ietf.org
Subject: [dispatch] New draft: draft-holmberg-dispatch-received-real= m-00

 

Hi,

 

I’ve submitted a new draft to dispatch: draft-= holmberg-dispatch-received-realm-00. The draft defines a new Via header fie= ld parameter, “received-realm”, which network entry entities ca= n insert in order to inform other entities in the network from which network the request was received.

 

Previous versions of the draft have been submitted t= o SIPCORE, but I was advised by the SIPCORE chairs to submit it to DISPATCH= .

 

Compared to previous versions, there is a technical = change: the entity which inserts a parameter also calculates a HMAC value, = which is inserted together with the network value.

 

Regards,

 

Christer

--_000_4A4F136CBD0E0D44AE1EDE36C4CD9D99AEEE2567VOEXM31Winterna_-- From nobody Wed Jun 10 06:11:14 2015 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 98BCC1A89F9 for ; Wed, 10 Jun 2015 06:11:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.209 X-Spam-Level: X-Spam-Status: No, score=-4.209 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, T_RP_MATCHES_RCVD=-0.01] autolearn=ham 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 49KeXXKPGJtt for ; Wed, 10 Jun 2015 06:11:11 -0700 (PDT) Received: from nbfkord-smmo07.seg.att.com (nbfkord-smmo07.seg.att.com [209.65.160.93]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7889B1A8969 for ; Wed, 10 Jun 2015 06:11:11 -0700 (PDT) Received: from unknown [144.160.229.24] (EHLO alpi155.enaf.aldc.att.com) by nbfkord-smmo07.seg.att.com(mxl_mta-7.2.4-5) with ESMTP id f6738755.2b6a46616940.692677.00-2496.1969044.nbfkord-smmo07.seg.att.com (envelope-from ); Wed, 10 Jun 2015 13:11:11 +0000 (UTC) X-MXL-Hash: 5578376f6737b620-bbc7410a87784fe4c80ae6fb1bb52cdd1fece34e Received: from unknown [144.160.229.24] (EHLO alpi155.enaf.aldc.att.com) by nbfkord-smmo07.seg.att.com(mxl_mta-7.2.4-5) over TLS secured channel with ESMTP id 36738755.0.692583.00-2074.1968744.nbfkord-smmo07.seg.att.com (envelope-from ); Wed, 10 Jun 2015 13:11:04 +0000 (UTC) X-MXL-Hash: 5578376847ca31ea-dcc9b18fe645f790babdea2e4848fc86fff68bf5 Received: from enaf.aldc.att.com (localhost [127.0.0.1]) by alpi155.enaf.aldc.att.com (8.14.5/8.14.5) with ESMTP id t5ADAwFi024786; Wed, 10 Jun 2015 09:10:59 -0400 Received: from mlpi408.sfdc.sbc.com (mlpi408.sfdc.sbc.com [130.9.128.240]) by alpi155.enaf.aldc.att.com (8.14.5/8.14.5) with ESMTP id t5ADApW0024655 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Wed, 10 Jun 2015 09:10:55 -0400 Received: from MISOUT7MSGHUBAA.ITServices.sbc.com (MISOUT7MSGHUBAA.itservices.sbc.com [130.9.129.145]) by mlpi408.sfdc.sbc.com (RSA Interceptor); Wed, 10 Jun 2015 13:10:34 GMT Received: from MISOUT7MSGUSRDB.ITServices.sbc.com ([169.254.2.183]) by MISOUT7MSGHUBAA.ITServices.sbc.com ([130.9.129.145]) with mapi id 14.03.0224.002; Wed, 10 Jun 2015 09:10:34 -0400 From: "DOLLY, MARTIN C" To: Christer Holmberg , "dispatch@ietf.org" Thread-Topic: New draft: draft-holmberg-dispatch-received-realm-00 Thread-Index: AdCiHwUUGsBUGXYYRyCmNYpBt1QlewBX8PeQ Date: Wed, 10 Jun 2015 13:10:33 +0000 Message-ID: References: <7594FB04B1934943A5C02806D1A2204B1D8AA730@ESESSMB209.ericsson.se> In-Reply-To: <7594FB04B1934943A5C02806D1A2204B1D8AA730@ESESSMB209.ericsson.se> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [135.70.30.247] Content-Type: multipart/alternative; boundary="_000_E42CCDDA6722744CB241677169E8365603601550MISOUT7MSGUSRDB_" MIME-Version: 1.0 X-RSA-Inspected: yes X-RSA-Classifications: public X-AnalysisOut: [v=2.0 cv=eKykegV1 c=1 sm=1 a=dhB6nF3YHL5t/Ixux6cINA==:17 a] X-AnalysisOut: [=-tun_wYrly0A:10 a=BLceEmwcHowA:10 a=zQP7CpKOAAAA:8 a=XIqp] X-AnalysisOut: [o32RAAAA:8 a=XAFQembCKUMA:10 a=48vgC7mUAAAA:8 a=ebXSIoLKA3] X-AnalysisOut: [6nZ1OJd28A:9 a=CjuIK1q_8ugA:10 a=yMhMjlubAAAA:8 a=SSmOFEAC] X-AnalysisOut: [AAAA:8 a=yfOfqV7fDVqOniZXTmsA:9 a=gKO2Hq4RSVkA:10 a=UiCQ7L] X-AnalysisOut: [4-1S4A:10 a=hTZeC7Yk6K0A:10 a=frz4AuCg-hUA:10 a=FuVXjYcGmJ] X-AnalysisOut: [U4n-f8:21] X-Spam: [F=0.2000000000; CM=0.500; S=0.200(2014051901)] X-MAIL-FROM: X-SOURCE-IP: [144.160.229.24] Archived-At: Subject: Re: [dispatch] New draft: draft-holmberg-dispatch-received-realm-00 X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 10 Jun 2015 13:11:13 -0000 --_000_E42CCDDA6722744CB241677169E8365603601550MISOUT7MSGUSRDB_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable I support this draft moving forward From: dispatch [mailto:dispatch-bounces@ietf.org] On Behalf Of Christer Hol= mberg Sent: Monday, June 08, 2015 3:15 PM To: dispatch@ietf.org Subject: [dispatch] New draft: draft-holmberg-dispatch-received-realm-00 Hi, I've submitted a new draft to dispatch: draft-holmberg-dispatch-received-re= alm-00. The draft defines a new Via header field parameter, "received-realm= ", which network entry entities can insert in order to inform other entitie= s in the network from which network the request was received. Previous versions of the draft have been submitted to SIPCORE, but I was ad= vised by the SIPCORE chairs to submit it to DISPATCH. Compared to previous versions, there is a technical change: the entity whic= h inserts a parameter also calculates a HMAC value, which is inserted toget= her with the network value. Regards, Christer --_000_E42CCDDA6722744CB241677169E8365603601550MISOUT7MSGUSRDB_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

I support this draft m= oving forward

 

From: dispatch [mailto:dispatch-bounces@ietf.= org] On Behalf Of Christer Holmberg
Sent: Monday, June 08, 2015 3:15 PM
To: dispatch@ietf.org
Subject: [dispatch] New draft: draft-holmberg-dispatch-received-real= m-00

 

Hi,

 

I’ve submitted a new draf= t to dispatch: draft-holmberg-dispatch-received-realm-00. The draft defines= a new Via header field parameter, “received-realm”, which netw= ork entry entities can insert in order to inform other entities in the network from which network the request was received.<= /o:p>

 

Previous versions of the draft = have been submitted to SIPCORE, but I was advised by the SIPCORE chairs to = submit it to DISPATCH.

 

Compared to previous versions, = there is a technical change: the entity which inserts a parameter also calc= ulates a HMAC value, which is inserted together with the network value.

 

Regards,

 

Christer

--_000_E42CCDDA6722744CB241677169E8365603601550MISOUT7MSGUSRDB_-- From nobody Wed Jun 10 06:16:53 2015 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1DF0B1AD481 for ; Wed, 10 Jun 2015 06:16:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.129 X-Spam-Level: X-Spam-Status: No, score=-1.129 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_SORBS_WEB=0.77, SPF_PASS=-0.001] autolearn=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 VnlyloEsU8mD for ; Wed, 10 Jun 2015 06:16:50 -0700 (PDT) Received: from mout.gmx.net (mout.gmx.net [212.227.17.21]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 474451AD277 for ; Wed, 10 Jun 2015 06:16:50 -0700 (PDT) Received: from [192.168.43.115] ([178.115.133.67]) by mail.gmx.com (mrgmx102) with ESMTPSA (Nemesis) id 0MGXV6-1YpQJa2sIC-00DFPW; Wed, 10 Jun 2015 15:16:46 +0200 Message-ID: <557838BD.8030602@gmx.com> Date: Wed, 10 Jun 2015 15:16:45 +0200 From: Georg Mayer User-Agent: Mozilla/5.0 (X11; Linux i686; rv:31.0) Gecko/20100101 Thunderbird/31.7.0 MIME-Version: 1.0 To: "DOLLY, MARTIN C" , Christer Holmberg , "dispatch@ietf.org" References: <7594FB04B1934943A5C02806D1A2204B1D8AA730@ESESSMB209.ericsson.se> In-Reply-To: Content-Type: multipart/alternative; boundary="------------040402080507020000040403" X-Provags-ID: V03:K0:2t8225fGVhBq6UUuXaLmvsPkaRvfRoud9N2l+hQa+zDZaOhyBEF t18dvGwzY9/5c83xgELrNKak+0w1eWzlwRdh/O4vH3oQEuYsMCLsbT2rfy+73R+rOg1OOwY fxt0bvjRrQzdWi8a/ycQKpvP/W0cH4N/NZ7AyRnAb+eIG992NxPdyzcs3xCh7llJv6rMLhY y72Gj50tFlS+kOBWwhVvg== X-UI-Out-Filterresults: notjunk:1;V01:K0:I8xs05FQQOU=:itYZ0mrnF9lPJFSkbOXxBe tR4TIUctATuC2FV3fwvHDE1kpdXyeF6gOPaaqWj53fjroeqbgPB+/o1tXoMUjfyZB47UFx1IC VXGvvI35KL/RQyfV0qcxcff1GEQNKl5p+tiwP77uXcQQ+lucsj+OkXqWacq+l72yEAOIqzSDY UiEE6XeFfsE5e3LrqRt7PtA63gvPxfWI1636rY5X46eJxPaJmNPbIGOkTSWEN2TYAlv287QAe rByx3ZIwpS5zvA2FSXJvYD5q/jVeCDZqs/Xvq/M2eL59ZCvd3ZHgwCPeNFWTvOUE4Eg/FGWPR An8MrQbtoxbF6NlJu7Dk17APguNIS2rxkjD0FRTvP07ARxehY5KmpTfX64HF1Kuk2cKk7Z+TF tOCA/cJuPHY5XOLMuCnngK6qJW4LjWVwgNHVP93qPmY2VIc99vtJY9dRlfBU0fuJkPJW1l9uz 56iF1WRN+0d3hrgOD3JECaOQY7LJUejasHItZFgJ/CjCQmY7g4t5iS/W0QGuHZ/rCAPkZGjor obbNKKvvafVIKjyzBZTWfPfRwAjwtpP/akPiRtRquZZ0dzYFQ3g7HCcHSDRIsNGdE48fzkDxz QmpoNHj6d+7k3VhbAqEMdExombv1IqThTMEsSRCKO9CKvVTS1rSuQWbmsxCC6lGY5Mk0nlUMD OmNAQiCds8cnjcf3bWXJeegxg1LCDcNHjXr0hrJ+G9kMGykLhRRR0og94NWB4NkaRLE8= Archived-At: Subject: Re: [dispatch] New draft: draft-holmberg-dispatch-received-realm-00 X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 10 Jun 2015 13:16:52 -0000 This is a multi-part message in MIME format. --------------040402080507020000040403 Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit +1 On 06/10/2015 03:10 PM, DOLLY, MARTIN C wrote: > > I support this draft moving forward > > *From:* dispatch [mailto:dispatch-bounces@ietf.org] *On Behalf Of > *Christer Holmberg > *Sent:* Monday, June 08, 2015 3:15 PM > *To:* dispatch@ietf.org > *Subject:* [dispatch] New draft: draft-holmberg-dispatch-received-realm-00 > > Hi, > > I’ve submitted a new draft to dispatch: > draft-holmberg-dispatch-received-realm-00. The draft defines a new Via > header field parameter, “received-realm”, which network entry entities > can insert in order to inform other entities in the network from which > network the request was received. > > Previous versions of the draft have been submitted to SIPCORE, but I > was advised by the SIPCORE chairs to submit it to DISPATCH. > > Compared to previous versions, there is a technical change: the entity > which inserts a parameter also calculates a HMAC value, which is > inserted together with the network value. > > Regards, > > Christer > > > > _______________________________________________ > dispatch mailing list > dispatch@ietf.org > https://www.ietf.org/mailman/listinfo/dispatch -- -- Georg Mayer 3GPP CT Chairman HUAWEI Technologies Mobile: +43 699 1900 5758 --------------040402080507020000040403 Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: 8bit +1

On 06/10/2015 03:10 PM, DOLLY, MARTIN C wrote:

I support this draft moving forward

 

From: dispatch [mailto:dispatch-bounces@ietf.org] On Behalf Of Christer Holmberg
Sent: Monday, June 08, 2015 3:15 PM
To: dispatch@ietf.org
Subject: [dispatch] New draft: draft-holmberg-dispatch-received-realm-00

 

Hi,

 

I’ve submitted a new draft to dispatch: draft-holmberg-dispatch-received-realm-00. The draft defines a new Via header field parameter, “received-realm”, which network entry entities can insert in order to inform other entities in the network from which network the request was received.

 

Previous versions of the draft have been submitted to SIPCORE, but I was advised by the SIPCORE chairs to submit it to DISPATCH.

 

Compared to previous versions, there is a technical change: the entity which inserts a parameter also calculates a HMAC value, which is inserted together with the network value.

 

Regards,

 

Christer



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


-- 
--
Georg Mayer
3GPP CT Chairman
HUAWEI Technologies
Mobile: +43 699 1900 5758
--------------040402080507020000040403-- From nobody Wed Jun 10 07:14:17 2015 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 940E91B2AD2 for ; Wed, 10 Jun 2015 07:14:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.864 X-Spam-Level: * X-Spam-Status: No, score=1.864 tagged_above=-999 required=5 tests=[BAYES_50=0.8, FREEMAIL_FROM=0.001, HELO_EQ_DE=0.35, HTML_MESSAGE=0.001, MIME_HTML_ONLY=0.723, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=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 NgwTTv354Us9 for ; Wed, 10 Jun 2015 07:14:14 -0700 (PDT) Received: from mout.web.de (mout.web.de [212.227.15.14]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D87031B2ACC for ; Wed, 10 Jun 2015 07:14:13 -0700 (PDT) Received: from [80.187.110.213] by msvc-mesg-web010.server.lan (via HTTP); Wed, 10 Jun 2015 16:14:11 +0200 MIME-Version: 1.0 Message-ID: From: "Roland Jesske" To: "DOLLY, MARTIN C" , "Christer Holmberg" , "dispatch@ietf.org" Content-Type: text/html; charset=UTF-8 Date: Wed, 10 Jun 2015 16:14:11 +0200 X-Provags-ID: V03:K0:aw+BfN2K7LOrNG2CJOZptudD1DGTKdGD6rUH6YZkyun sB0I13d1UUmzJPx3NUk2U2dL9BgMnQ+2tIzY4SIn3UJm42xFdH Xae/pPlNvS2y+nIPNvsworYw5Szhinx/Nv28Zxj20uMx027xHy 8a7scdMdD9qKQBlXmaCrJt2t4RNA+7dQOsFPx4+Ay2EqIN5io/ wu47wqZMFx7W7UuCI6nmnMTeZVrdkFnws8k+pJ+vychYZS09HE /HztHBHXm1DgyNcEEYE1Ky10OPHteTtkh+1jhY0FhviQiaPmpw 0blMVU= X-UI-Out-Filterresults: notjunk:1;V01:K0:+eV8jzPQ2SI=:+Fo2lHupYYzAeucJ9pTRxB EY1I3CmWtWzskHDIGnOxVXsO6Jcxty4HjK8Fh1UZGXGzV4gTYydGc0Qz0foFRucyxcV8glex6 7Vcl6gis0ZnVroNPE4mHeQ3XMOzKGg1rH2nMlkmihXVetT7zccrdYl2OKzQz6Vssiv9J+upSX cD2Amrdocnmj+5ltKBwy26DBtSWH8b1w3p2GpRWENkuYO8ULQPXrbocwNYmmfAOMCHaD96wnd wiVGp2NS792Cni/bU9YFzBZ5NMuDGLnLxsJHswDnHpHtk/L7DGqD07zsV9kwGRC+rq+y/vIN8 oTZhL9H602bNVyITefRkyMTpvOdGJk+HKD89qCeUQoMD2huWk1yLqqg+hP9RujgArsk0hHJh2 tLiU3G4+O59phBSOtYR8nuZrPOe13f5IjtNjF02jqEUr0rz4+lF+RA497Blq9KSXn8lYyGk89 HY8OSztWlCDIhw0JGEJqW6i1NCuEdlyZCmop5wbHkesvKY60iyg5 Archived-At: Subject: Re: [dispatch] New draft: draft-holmberg-dispatch-received-realm-00 X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 10 Jun 2015 14:14:15 -0000 +1
Regards
Roland
--
Diese Nachricht wurde von meinem Android Mobiltelefon mit WEB.DE Mail gesendet.



"DOLLY, MARTIN C" <md3135@att.com>schrieb:

I support this draft moving forward

 

From: dispatch [mailto:dispatch-bounces@ietf.org] On Behalf Of Christer Holmberg
Sent: Monday, June 08, 2015 3:15 PM
To: dispatch@ietf.org
Subject: [dispatch] New draft: draft-holmberg-dispatch-received-realm-00

 

Hi,

 

I’ve submitted a new draft to dispatch: draft-holmberg-dispatch-received-realm-00. The draft defines a new Via header field parameter, “received-realm”, which network entry entities can insert in order to inform other entities in the network from which network the request was received.

 

Previous versions of the draft have been submitted to SIPCORE, but I was advised by the SIPCORE chairs to submit it to DISPATCH.

 

Compared to previous versions, there is a technical change: the entity which inserts a parameter also calculates a HMAC value, which is inserted together with the network value.

 

Regards,

 

Christer

_______________________________________________ dispatch mailing list dispatch@ietf.org https://www.ietf.org/mailman/listinfo/dispatch
From nobody Wed Jun 10 08:20:10 2015 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D92BD1B2B8D for ; Wed, 10 Jun 2015 08:20:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.2 X-Spam-Level: X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham 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 5_PtdNh4ftO5 for ; Wed, 10 Jun 2015 08:20:06 -0700 (PDT) Received: from sesbmg23.ericsson.net (sesbmg23.ericsson.net [193.180.251.37]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9A2CE1B2B9C for ; Wed, 10 Jun 2015 08:20:05 -0700 (PDT) X-AuditID: c1b4fb25-f79b66d000001131-a1-557855a347b1 Received: from ESESSHC009.ericsson.se (Unknown_Domain [153.88.253.125]) by sesbmg23.ericsson.net (Symantec Mail Security) with SMTP id 9F.9D.04401.3A558755; Wed, 10 Jun 2015 17:20:03 +0200 (CEST) Received: from ESESSMB209.ericsson.se ([169.254.9.72]) by ESESSHC009.ericsson.se ([153.88.183.45]) with mapi id 14.03.0210.002; Wed, 10 Jun 2015 17:20:03 +0200 From: Christer Holmberg To: "Dawes, Peter, Vodafone Group" , "dispatch@ietf.org" Thread-Topic: New draft: draft-holmberg-dispatch-received-realm-00 Thread-Index: AdCiHwUUGsBUGXYYRyCmNYpBt1QlewBXgnVwAATWnjA= Date: Wed, 10 Jun 2015 15:20:03 +0000 Message-ID: <7594FB04B1934943A5C02806D1A2204B1D8B72D9@ESESSMB209.ericsson.se> References: <7594FB04B1934943A5C02806D1A2204B1D8AA730@ESESSMB209.ericsson.se> <4A4F136CBD0E0D44AE1EDE36C4CD9D99AEEE2567@VOEXM31W.internal.vodafone.com> In-Reply-To: <4A4F136CBD0E0D44AE1EDE36C4CD9D99AEEE2567@VOEXM31W.internal.vodafone.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [153.88.183.149] Content-Type: multipart/alternative; boundary="_000_7594FB04B1934943A5C02806D1A2204B1D8B72D9ESESSMB209erics_" MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFvrGLMWRmVeSWpSXmKPExsUyM+Jvre7i0IpQg1+7bSyWTlrAatH38guT A5PHkiU/mTz6ZqxnDGCK4rJJSc3JLEst0rdL4MronrWNpeCUc8Xv6b2MDYzvrLoYOTkkBEwk Fjy7wAZhi0lcuLcezBYSOMoosXeVGYS9mFGiZb9cFyMHB5uAhUT3P22QsIhAhsTdddPZQWxh AUeJBRt2M0LEnSSu/FzAAlIuImAlsXleJkiYRUBV4nrbBSYQm1fAV+Lr1aksENNnMkrsei0D YnMKhEncfTKBFcRmBLrm+6k1YPXMAuISt57MZ4K4UkBiyZ7zzBC2qMTLx/9YIWwlibWHt7NA 1OcDxa8wQ+wSlDg58wnLBEaRWUhGzUJSNgtJGURcR2LB7k9sELa2xLKFr5lh7DMHHjMhiy9g ZF/FKFqcWpyUm25krJdalJlcXJyfp5eXWrKJERhRB7f8Vt3BePmN4yFGAQ5GJR5ehVnloUKs iWXFlbmHGKU5WJTEeWdszgsVEkhPLEnNTk0tSC2KLyrNSS0+xMjEwSnVwMjVESjQyB9pIGlk 9OnlxJLsW4fMt7FMEtzT8CT0lN66/L+Nl4T9aw+v/76uUPdi4f7Pj25MmXE34MwG24+3G88u yXl3NnVz58eQ17nOKxav/t//ZoJM8cKEWwslPqUL1/yLkDwQvs71aVHIdXbH0wqemUU3ylId FaNDD3i82hB39KFqae9uW0MlluKMREMt5qLiRABG0oVBiQIAAA== Archived-At: Subject: Re: [dispatch] New draft: draft-holmberg-dispatch-received-realm-00 X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 10 Jun 2015 15:20:09 -0000 --_000_7594FB04B1934943A5C02806D1A2204B1D8B72D9ESESSMB209erics_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi Peter, Thanks for your comments! See inline. > I agree that it is useful for a (transit) network to know which network a= request arrived from, as this > draft argues. But isn't this information to be in the Via header field al= ready in the entry before the > transit network? The draft mentions that inter-operator identifier cannot= be used but I think the >draft should expand on why a new header field parameter is needed. Via headers may contain IP addresses, and they cannot always be used to ide= ntify the network. Also, the consumer of the information would have to scan= through the Via headers, and figure out which belongs to the consumer netw= ork and which belongs to the adjacent network. The purpose of the identifier is to have an explicit indicator, which preve= nts such scanning etc. I try to explain that in the draft, but maybe more text is needed :) Regards, Christer From: dispatch [mailto:dispatch-bounces@ietf.org] On Behalf Of Christer Hol= mberg Sent: 08 June 2015 20:15 To: dispatch@ietf.org Subject: [dispatch] New draft: draft-holmberg-dispatch-received-realm-00 Hi, I've submitted a new draft to dispatch: draft-holmberg-dispatch-received-re= alm-00. The draft defines a new Via header field parameter, "received-realm= ", which network entry entities can insert in order to inform other entitie= s in the network from which network the request was received. Previous versions of the draft have been submitted to SIPCORE, but I was ad= vised by the SIPCORE chairs to submit it to DISPATCH. Compared to previous versions, there is a technical change: the entity whic= h inserts a parameter also calculates a HMAC value, which is inserted toget= her with the network value. Regards, Christer --_000_7594FB04B1934943A5C02806D1A2204B1D8B72D9ESESSMB209erics_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi Peter,

 

Thanks for your commen= ts! See inline.

 

> I agree that it i= s useful for a (transit) network to know which network a request arrived fr= om, as this

> draft argues. But= isn’t this information to be in the Via header field already in the = entry before the

> transit network?<= /span> The draft mentions that inter-operator identifier cannot be used but I thin= k the

>draft should expan= d on why a new header field parameter is needed.

 

Via headers may contain IP addresses, and they canno= t always be used to identify the network. Also, the consumer of the informa= tion would have to scan through the Via headers, and figure out which belon= gs to the consumer network and which belongs to the adjacent network.

 

The purpose of the identifier is to have an explicit= indicator, which prevents such scanning etc.

 

I try to explain that in the draft, but maybe more t= ext is needed :)

 

Regards,

 

Christer

 

 

From: dispatch [mailto:dispatch-bounces@ietf.org] On Behalf Of Christer Holmberg
Sent: 08 June 2015 20:15
To: dispatch@ietf.org
Subject: [dispatch] New draft: draft-holmberg-dispatch-received-real= m-00

 

Hi,

 

I’ve submitted a new draft to dispatch: draft-= holmberg-dispatch-received-realm-00. The draft defines a new Via header fie= ld parameter, “received-realm”, which network entry entities ca= n insert in order to inform other entities in the network from which network the request was received.

 

Previous versions of the draft have been submitted t= o SIPCORE, but I was advised by the SIPCORE chairs to submit it to DISPATCH= .

 

Compared to previous versions, there is a technical = change: the entity which inserts a parameter also calculates a HMAC value, = which is inserted together with the network value.

 

Regards,

 

Christer

--_000_7594FB04B1934943A5C02806D1A2204B1D8B72D9ESESSMB209erics_-- From nobody Wed Jun 10 12:06:42 2015 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1C5C21A8700 for ; Wed, 10 Jun 2015 12:06:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.002 X-Spam-Level: X-Spam-Status: No, score=-0.002 tagged_above=-999 required=5 tests=[BAYES_40=-0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham 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 2kWOHtHSOIRW for ; Wed, 10 Jun 2015 12:06:38 -0700 (PDT) Received: from na01-by2-obe.outbound.protection.outlook.com (mail-by2on0082.outbound.protection.outlook.com [207.46.100.82]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 657D41A86F3 for ; Wed, 10 Jun 2015 12:06:38 -0700 (PDT) Received: from CY1PR0601MB1657.namprd06.prod.outlook.com (25.163.232.19) by CY1PR0601MB1659.namprd06.prod.outlook.com (25.163.232.21) with Microsoft SMTP Server (TLS) id 15.1.184.17; Wed, 10 Jun 2015 19:06:36 +0000 Received: from CY1PR0601MB1657.namprd06.prod.outlook.com ([25.163.232.19]) by CY1PR0601MB1657.namprd06.prod.outlook.com ([25.163.232.19]) with mapi id 15.01.0184.014; Wed, 10 Jun 2015 19:06:36 +0000 From: Dan York To: "dispatch@ietf.org" Thread-Topic: Need guidance on how to progress draft-york-dispatch-p-charge-info Thread-Index: AQHQo6zx5yx2Tgh9VkKar7py3gFYdA== Date: Wed, 10 Jun 2015 19:06:35 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: ietf.org; dkim=none (message not signed) header.d=none; x-ms-exchange-messagesentrepresentingtype: 1 x-originating-ip: [74.69.229.215] x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:CY1PR0601MB1659; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:; x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(601004)(5005006)(520003)(3002001); SRVR:CY1PR0601MB1659; BCL:0; PCL:0; RULEID:; SRVR:CY1PR0601MB1659; x-forefront-prvs: 06036BD506 x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(6009001)(52314003)(164054003)(5001960100002)(107886002)(66066001)(86362001)(110136002)(46102003)(40100003)(2501003)(33656002)(92566002)(5003600100002)(19625215002)(2900100001)(19580395003)(19627405001)(99286002)(2656002)(2351001)(74316001)(106116001)(50986999)(122556002)(230783001)(102836002)(15975445007)(76576001)(189998001)(16236675004)(5002640100001)(77156002)(450100001)(62966003)(87936001)(54356999); DIR:OUT; SFP:1101; SCL:1; SRVR:CY1PR0601MB1659; H:CY1PR0601MB1657.namprd06.prod.outlook.com; FPR:; SPF:None; MLV:sfv; LANG:en; Content-Type: multipart/alternative; boundary="_000_CY1PR0601MB1657710F6E8509476D8C8373B7BD0CY1PR0601MB1657_" MIME-Version: 1.0 X-OriginatorOrg: isoc.org X-MS-Exchange-CrossTenant-originalarrivaltime: 10 Jun 2015 19:06:35.8333 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 89f84dfb-7285-4810-bc4d-8b9b5794554f X-MS-Exchange-Transport-CrossTenantHeadersStamped: CY1PR0601MB1659 Archived-At: Subject: [dispatch] Need guidance on how to progress draft-york-dispatch-p-charge-info X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 10 Jun 2015 19:06:41 -0000 --_000_CY1PR0601MB1657710F6E8509476D8C8373B7BD0CY1PR0601MB1657_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable DISPATCH participants, I could use some help/guidance about how to move my now-seemingly-ancient P= -Charge-Info draft forward. The draft is at: https://tools.ietf.org/html/draft-york-dispatch-p-charge-info-05 Way back in 2008, I first submitted the draft to the SIPPING WG. My goal wa= s simply to *document the existing usage* of the P-Charge-Info SIP header p= er the then-relevant RFC 3427 so that the header could be listed in the IAN= A registry of SIP parameters at: http://www.iana.org/assignments/sip-parameters/sip-parameters.xhtml#sip-par= ameters-2 My employer at the time, Voxeo, was (and still is) a strong user of the hea= der and encouraged me to document it so that others could use the header wi= thin private networks. As an IETF participant and SIP advocate, I personal= ly wanted to document P-Charge-Info so that perhaps people could find it an= d use that header instead of creating yet another private header. Tolga As= veren of Sonus Networks joined on very early in the process because Sonus w= as (and presumably still is) also actively using the header. Lots of other= people chimed in along the way. After an initial flurry of commentary and changes on the SIPPING list from = 2008-2010, there's a longer story of why it took so long... there was the R= FC 3427bis process which became RFC 5727... life and job changes... much mo= re... Anyway, at this point in 2015 I just want to move the document along and ge= t it published so that the header can be registered and, quite honestly, so= that I can stop renewing the document every 6 months. Given that I still = get inquiries about this header from time to time and that it is still bein= g used, I feel a certain responsibility to just "get this done" rather than= simply abandoning the draft. >From what I know, there are three ways I can move this forward to publicati= on: 1. DISPATCH approval - this WG can approve the draft and send to the IESG; = [1] 2. AD-SPONSORED - I can ask a friendly AD to help send this to the IESG; 3. INDIVIDUAL SUBMISSION - I can send this in to the independent stream edi= tor. Am I correct? And if so, what would any of you suggest as the simplest pat= h to checking this off as done? Comments on the actual draft are of course also welcome, with the reminder = that the aim of the draft was and is to document existing usage rather than= to create a new header, etc. (Because if it was to create a new header, t= he "P-" would be removed, etc.) Thanks, Dan [1] And yes, I do realize there is actually a 4th path which is that DISPAT= CH could "dispatch" this draft off to some other WG and I could then bring = it through *that* WG. And if that's the best path I'm glad to do that, too.= .. I just want to get this finished. --_000_CY1PR0601MB1657710F6E8509476D8C8373B7BD0CY1PR0601MB1657_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

DISPATCH participants,


I could use some help/guidance about how to move my now-seemingly-ancien= t P-Charge-Info draft forward. The draft is at:


https://tools.ietf.org/html/draft-york-dispatch-p-charge-info-05


Way back in 2008, I first submitted the draft to the SIPPING WG. My goal= was simply to *document the existing usage* of the P-Charge-Info SIP = header per the then-relevant RFC 3427 so that the header could be list= ed in the IANA registry of SIP parameters at:


http://www.iana.org/assignments/sip-parameters/sip-parameters.xhtml#sip-= parameters-2 


My employer at the time, Voxeo, was (and still is) a strong user of= the header and encouraged me to document it so that others could use the h= eader within private networks.  As an IETF participant and SIP ad= vocate, I personally wanted to document P-Charge-Info so that perhaps people could find it and use that header instead of creati= ng yet another private header.  Tolga Asveren of Sonus Networks joined= on very early in the process because Sonus was (and presumably still is) a= lso actively using the header.  Lots of other people  chimed in along the way.


After an initial flurry of commentary and changes on the SIPPING list fr= om 2008-2010, there's a longer story of why it took so long... there was th= e RFC 3427bis process which became RFC 5727... life and job changes... much= more...


Anyway, at this point in 2015 I just want to move the document along and= get it published so that the header can be registered and, quite honestly,= so that I can stop renewing the document every 6 months.  Given = that I still get inquiries about this header from time to time and that it is still being used, I feel a certain respon= sibility to just "get this done" rather than simply abandoning th= e draft.


From what I know, there are three ways I can move this forward to public= ation:


1. DISPATCH approval - this WG can approve the draft and send to the IES= G; [1]


2. AD-SPONSORED - I can ask a friendly AD to help send this to the IESG;=


3. INDIVIDUAL SUBMISSION - I can send this in to the independent stream = editor.


Am I correct?  And if so, what would any of you suggest as the simp= lest path to checking this off as done?


Comments on the actual draft are of course also welcome, with the remind= er that the aim of the draft was and is to document existing usage rather t= han to create a new header, etc.  (Because if it was to create a new h= eader, the "P-" would be removed, etc.)


Thanks,

Dan


[1] And yes, I do realize there is actually a 4th path which is that DIS= PATCH could "dispatch" this draft off to some other WG and I coul= d then bring it through *that* WG. And if that's the best path I'm glad to = do that, too... I just want to get this finished.



--_000_CY1PR0601MB1657710F6E8509476D8C8373B7BD0CY1PR0601MB1657_-- From nobody Wed Jun 10 12:21:59 2015 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2688F1A882A for ; Wed, 10 Jun 2015 12:21:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.909 X-Spam-Level: X-Spam-Status: No, score=-1.909 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham 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 yekWnRKtYVgQ for ; Wed, 10 Jun 2015 12:21:56 -0700 (PDT) Received: from nostrum.com (raven-v6.nostrum.com [IPv6:2001:470:d:1130::1]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E8EED1A87F1 for ; Wed, 10 Jun 2015 12:21:55 -0700 (PDT) Received: from unnumerable.local (pool-71-170-237-80.dllstx.fios.verizon.net [71.170.237.80]) (authenticated bits=0) by nostrum.com (8.15.1/8.14.9) with ESMTPSA id t5AJLsPN089770 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=OK) for ; Wed, 10 Jun 2015 14:21:55 -0500 (CDT) (envelope-from rjsparks@nostrum.com) X-Authentication-Warning: raven.nostrum.com: Host pool-71-170-237-80.dllstx.fios.verizon.net [71.170.237.80] claimed to be unnumerable.local Message-ID: <55788E4D.6060804@nostrum.com> Date: Wed, 10 Jun 2015 14:21:49 -0500 From: Robert Sparks User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:31.0) Gecko/20100101 Thunderbird/31.7.0 MIME-Version: 1.0 To: dispatch@ietf.org References: In-Reply-To: Content-Type: multipart/alternative; boundary="------------070505070905000006070806" Archived-At: Subject: Re: [dispatch] Need guidance on how to progress draft-york-dispatch-p-charge-info X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 10 Jun 2015 19:21:58 -0000 This is a multi-part message in MIME format. --------------070505070905000006070806 Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit On 6/10/15 2:06 PM, Dan York wrote: > > DISPATCH participants, > > > I could use some help/guidance about how to move my > now-seemingly-ancient P-Charge-Info draft forward. The draft is at: > > > https://tools.ietf.org/html/draft-york-dispatch-p-charge-info-05 > > > Way back in 2008, I first submitted the draft to the SIPPING WG. My > goal was simply to *document the existing usage* of the P-Charge-Info > SIP header per the then-relevant RFC 3427 so that the header could be > listed in the IANA registry of SIP parameters at: > > > http://www.iana.org/assignments/sip-parameters/sip-parameters.xhtml#sip-parameters-2 > > > > My employer at the time, Voxeo, was (and still is) a strong user of > the header and encouraged me to document it so that others could use > the header within private networks. As an IETF participant and > SIP advocate, I personally wanted to document P-Charge-Info so that > perhaps people could find it and use that header instead of creating > yet another private header. Tolga Asveren of Sonus Networks joined on > very early in the process because Sonus was (and presumably still is) > also actively using the header. Lots of other people chimed in along > the way. > > > After an initial flurry of commentary and changes on the SIPPING list > from 2008-2010, there's a longer story of why it took so long... there > was the RFC 3427bis process which became RFC 5727... life and job > changes... much more... > > > Anyway, at this point in 2015 I just want to move the document along > and get it published so that the header can be registered and, quite > honestly, so that I can stop renewing the document every 6 months. > Given that I still get inquiries about this header from time to time > and that it is still being used, I feel a certain responsibility to > just "get this done" rather than simply abandoning the draft. > > > From what I know, there are three ways I can move this forward to > publication: > > > 1. DISPATCH approval - this WG can approve the draft and send to the > IESG; [1] > This is not what DISPATCH is designed to do. > > > 2. AD-SPONSORED - I can ask a friendly AD to help send this to the IESG; > This is the path I think this document should take. > > > 3. INDIVIDUAL SUBMISSION - I can send this in to the independent > stream editor. > You could do this. Diversion went this way to support the diversion-history-info work. I would prefer, though, that the document take path 2, and pursue publication as an IETF document. > > Am I correct? And if so, what would any of you suggest as the > simplest path to checking this off as done? > > > Comments on the actual draft are of course also welcome, with the > reminder that the aim of the draft was and is to document existing > usage rather than to create a new header, etc. (Because if it was to > create a new header, the "P-" would be removed, etc.) > > > Thanks, > > Dan > > > [1] And yes, I do realize there is actually a 4th path which is that > DISPATCH could "dispatch" this draft off to some other WG and I could > then bring it through *that* WG. And if that's the best path I'm glad > to do that, too... I just want to get this finished. > > > > > > _______________________________________________ > dispatch mailing list > dispatch@ietf.org > https://www.ietf.org/mailman/listinfo/dispatch --------------070505070905000006070806 Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: 8bit

On 6/10/15 2:06 PM, Dan York wrote:

DISPATCH participants,


I could use some help/guidance about how to move my now-seemingly-ancient P-Charge-Info draft forward. The draft is at:


https://tools.ietf.org/html/draft-york-dispatch-p-charge-info-05


Way back in 2008, I first submitted the draft to the SIPPING WG. My goal was simply to *document the existing usage* of the P-Charge-Info SIP header per the then-relevant RFC 3427 so that the header could be listed in the IANA registry of SIP parameters at:


http://www.iana.org/assignments/sip-parameters/sip-parameters.xhtml#sip-parameters-2 


My employer at the time, Voxeo, was (and still is) a strong user of the header and encouraged me to document it so that others could use the header within private networks.  As an IETF participant and SIP advocate, I personally wanted to document P-Charge-Info so that perhaps people could find it and use that header instead of creating yet another private header.  Tolga Asveren of Sonus Networks joined on very early in the process because Sonus was (and presumably still is) also actively using the header.  Lots of other people  chimed in along the way.


After an initial flurry of commentary and changes on the SIPPING list from 2008-2010, there's a longer story of why it took so long... there was the RFC 3427bis process which became RFC 5727... life and job changes... much more...


Anyway, at this point in 2015 I just want to move the document along and get it published so that the header can be registered and, quite honestly, so that I can stop renewing the document every 6 months.  Given that I still get inquiries about this header from time to time and that it is still being used, I feel a certain responsibility to just "get this done" rather than simply abandoning the draft.


From what I know, there are three ways I can move this forward to publication:


1. DISPATCH approval - this WG can approve the draft and send to the IESG; [1]

This is not what DISPATCH is designed to do.


2. AD-SPONSORED - I can ask a friendly AD to help send this to the IESG;

This is the path I think this document should take.


3. INDIVIDUAL SUBMISSION - I can send this in to the independent stream editor.

You could do this. Diversion went this way to support the diversion-history-info work.
I would prefer, though, that the document take path 2, and pursue publication as an IETF document.

Am I correct?  And if so, what would any of you suggest as the simplest path to checking this off as done?


Comments on the actual draft are of course also welcome, with the reminder that the aim of the draft was and is to document existing usage rather than to create a new header, etc.  (Because if it was to create a new header, the "P-" would be removed, etc.)


Thanks,

Dan


[1] And yes, I do realize there is actually a 4th path which is that DISPATCH could "dispatch" this draft off to some other WG and I could then bring it through *that* WG. And if that's the best path I'm glad to do that, too... I just want to get this finished.





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

--------------070505070905000006070806-- From nobody Wed Jun 10 20:08:18 2015 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9F6551A0075 for ; Wed, 10 Jun 2015 20:08:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.318 X-Spam-Level: X-Spam-Status: No, score=-0.318 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, IP_NOT_FRIENDLY=0.334, MIME_QP_LONG_LINE=0.001, RCVD_IN_BL_SPAMCOP_NET=1.347, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=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 FBpjX4I9nclw for ; Wed, 10 Jun 2015 20:08:13 -0700 (PDT) Received: from qproxy5-pub.mail.unifiedlayer.com (qproxy5-pub.mail.unifiedlayer.com [69.89.21.30]) by ietfa.amsl.com (Postfix) with SMTP id 9E4821A0030 for ; Wed, 10 Jun 2015 20:08:13 -0700 (PDT) Received: (qmail 22591 invoked by uid 0); 11 Jun 2015 03:08:11 -0000 Received: from unknown (HELO cmgw2) (10.0.90.83) by qproxy5.mail.unifiedlayer.com with SMTP; 11 Jun 2015 03:08:11 -0000 Received: from box462.bluehost.com ([74.220.219.62]) by cmgw2 with id eqgU1q0121MNPNq01qgXxn; Wed, 10 Jun 2015 20:40:36 -0600 X-Authority-Analysis: v=2.1 cv=cooIzTIi c=1 sm=1 tr=0 a=jTEj1adHphCQ5SwrTAOQMg==:117 a=jTEj1adHphCQ5SwrTAOQMg==:17 a=cNaOj0WVAAAA:8 a=f5113yIGAAAA:8 a=j1VUBDpLDLYA:10 a=MKtGQD3n3ToA:10 a=1oJP67jkp3AA:10 a=ZZnuYtJkoWoA:10 a=8WrITzYgnNwA:10 a=-h4zUWlAkX4A:10 a=XAFQembCKUMA:10 a=PeFO9FbFhS32YxYntvkA:9 a=dci_DRCyiIAA:10 a=CiRkrLRW1GAA:10 a=iycWLhIX580A:10 a=ll-iCDY8AAAA:8 a=M0OflfRGAAAA:8 a=Z80JlwQ0AAAA:8 a=48vgC7mUAAAA:8 a=I0CVDw5ZAAAA:8 a=Cm7i93eBQ1MjLFupGdsA:9 a=wPNLvfGTeEIA:10 a=ivbTfD_dPm4A:10 a=6fpOX-4qs7AA:10 a=BQYh4w-RC7EA:10 a=UqCG9HQmAAAA:8 a=QuG_L61sZbL7PxngLusA:9 a=8h0mPX9qhmhza83L:21 a=_W_S_7VecoQA:10 a=frz4AuCg-hUA:10 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=shockey.us; s=default; h=Content-type:Mime-version:In-Reply-To:References:Message-ID:To:From:Subject:Date; bh=+lkEtldAf6OZGOrIEtr4rtsinbUw7EnsldmeJaDhjy8=; b=SEwyGOAaQh+RjQyQdcauwNgZz7P8rZt2gIpaGvAMIT3mYmjanvb8tDTkgvvkvgZVhaolFrnuzCUlL8LSnX5m6u2OZ0KWnOZTNYDZWTKsOWKiW9aNzJIqAQb1gmL97Dpu; Received: from [108.56.131.149] (port=49986 helo=[192.168.1.11]) by box462.bluehost.com with esmtpa (Exim 4.84) (envelope-from ) id 1Z2sXE-0007zI-AA; Wed, 10 Jun 2015 20:48:04 -0600 User-Agent: Microsoft-MacOutlook/14.5.1.150515 Date: Wed, 10 Jun 2015 22:47:59 -0400 From: Richard Shockey To: Robert Sparks , Message-ID: Thread-Topic: [dispatch] Need guidance on how to progress draft-york-dispatch-p-charge-info References: <55788E4D.6060804@nostrum.com> In-Reply-To: <55788E4D.6060804@nostrum.com> Mime-version: 1.0 Content-type: multipart/alternative; boundary="B_3516821284_2453400" X-Identified-User: {3286:box462.bluehost.com:shockeyu:shockey.us} {sentby:smtp auth 108.56.131.149 authed with richard+shockey.us} Archived-At: Subject: Re: [dispatch] Need guidance on how to progress draft-york-dispatch-p-charge-info X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 11 Jun 2015 03:08:16 -0000 > This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. --B_3516821284_2453400 Content-type: text/plain; charset="ISO-8859-1" Content-transfer-encoding: quoted-printable AD Sponsored .. Please This is actually an important document for endless reasons. =8B=20 Richard Shockey Shockey Consulting LLC Chairman of the Board SIP Forum www.shockey.us www.sipforum.org richardshockey.us Skype-Linkedin-Facebook rshockey101 PSTN +1 703-593-2683 From: Robert Sparks Date: Wednesday, June 10, 2015 at 3:21 PM To: Subject: Re: [dispatch] Need guidance on how to progress draft-york-dispatch-p-charge-info =20 =20 =20 =20 On 6/10/15 2:06 PM, Dan York wrote: =20 =20 > =20 > =20 >=20 > DISPATCH participants, > =20 > =20 >=20 >=20 > =20 > =20 >=20 > I could use some help/guidance about how to move my now-seemingly-ancient > P-Charge-Info draft forward. The draft is at: > =20 > =20 >=20 >=20 > =20 > =20 >=20 > https://tools.ietf.org/html/draft-york-dispatch-p-charge-info-05 > =20 > =20 >=20 >=20 > =20 > =20 >=20 > Way back in 2008, I first submitted the draft to the SIPPING WG. My goal = was > simply to *document the existing usage* of the P-Charge-Info SIP header p= er > the then-relevant RFC 3427 so that the header could be listed in the IANA > registry of SIP parameters at: > =20 > =20 >=20 >=20 > =20 > =20 >=20 > http://www.iana.org/assignments/sip-parameters/sip-parameters.xhtml#sip-p= arame > ters-2=20 > =20 > =20 >=20 >=20 > =20 > =20 >=20 > My employer at the time, Voxeo, was (and still is) a strong user of the h= eader > and encouraged me to document it so that others could use the header with= in > private networks. As an IETF participant and SIP advocate, I personally > wanted to document P-Charge-Info so that perhaps people could find it and= use > that header instead of creating yet another private header. Tolga Asvere= n of > Sonus Networks joined on very early in the process because Sonus was (and > presumably still is) also actively using the header. Lots of other peopl= e > chimed in along the way. > =20 > =20 >=20 >=20 > =20 > =20 >=20 > After an initial flurry of commentary and changes on the SIPPING list fro= m > 2008-2010, there's a longer story of why it took so long... there was the= RFC > 3427bis process which became RFC 5727... life and job changes... much mor= e... > =20 > =20 >=20 >=20 > =20 > =20 >=20 > Anyway, at this point in 2015 I just want to move the document along and = get > it published so that the header can be registered and, quite honestly, so= that > I can stop renewing the document every 6 months. Given that I still get > inquiries about this header from time to time and that it is still being = used, > I feel a certain responsibility to just "get this done" rather than simpl= y > abandoning the draft. > =20 > =20 >=20 >=20 > =20 > =20 >=20 > From what I know, there are three ways I can move this forward to publica= tion: > =20 > =20 >=20 >=20 > =20 > =20 >=20 > 1. DISPATCH approval - this WG can approve the draft and send to the IESG= ; [1] > =20 > =20 > =20 This is not what DISPATCH is designed to do. =20 > =20 > =20 >=20 > =20 > =20 >=20 >=20 > =20 > =20 >=20 > 2. AD-SPONSORED - I can ask a friendly AD to help send this to the IESG; > =20 > =20 > =20 This is the path I think this document should take. =20 > =20 > =20 >=20 > =20 > =20 >=20 >=20 > =20 > =20 >=20 > 3. INDIVIDUAL SUBMISSION - I can send this in to the independent stream > editor. > =20 > =20 > =20 You could do this. Diversion went this way to support the diversion-history-info work. I would prefer, though, that the document take path 2, and pursue publication as an IETF document. > =20 > =20 >=20 > Am I correct? And if so, what would any of you suggest as the simplest p= ath > to checking this off as done? > =20 > =20 >=20 >=20 > =20 > =20 >=20 > Comments on the actual draft are of course also welcome, with the reminde= r > that the aim of the draft was and is to document existing usage rather th= an to > create a new header, etc. (Because if it was to create a new header, the= "P-" > would be removed, etc.) > =20 > =20 >=20 >=20 > =20 > =20 >=20 > Thanks, > =20 > =20 >=20 > Dan > =20 > =20 >=20 >=20 > =20 > =20 >=20 > [1] And yes, I do realize there is actually a 4th path which is that DISP= ATCH > could "dispatch" this draft off to some other WG and I could then bring i= t > through *that* WG. And if that's the best path I'm glad to do that, too..= . I > just want to get this finished. > =20 > =20 >=20 >=20 > =20 > =20 >=20 >=20 > =20 > =20 > =20 > =20 > =20 > =20 > =20 > =20 > =20 > _______________________________________________ > dispatch mailing list > dispatch@ietf.orghttps://www.ietf.org/mailman/listinfo/dispatch > =20 =20 =20 _______________________________________________ dispatch mailing list dispatch@ietf.org https://www.ietf.org/mailman/listinfo/dispatch --B_3516821284_2453400 Content-type: text/html; charset="ISO-8859-1" Content-transfer-encoding: quoted-printable

AD S= ponsored .. Please 

This is actually an import= ant document for endless reasons.


— 
Richard Shockey
Shockey Consulting LLC<= /div>
Chairman of the Board SIP Forum
www.shockey.us
www.sipforum.org
richard<at>shockey.us
Skype-Link= edin-Facebook rshockey101
PSTN +1 703-593-2683


From: = Robert Sparks <rjsparks@nostrum.com= >
Date: Wednesday, June 10,= 2015 at 3:21 PM
To: <dispatch@ietf.org>
Subject: Re: [dispatch] Need guidance on how to progress d= raft-york-dispatch-p-charge-info



On 6/10/15 2:06 PM, Dan York wrote:

DISPATCH participants,


I could use some help/guidance about how to move my now-seemingly-ancient P-Charge-Info draft forward. The draft is at:


https://tools.ietf.org/html/draft-y= ork-dispatch-p-charge-info-05


Way back in 2008, I first submitted the draft to the SIPPING WG. My goal was simply to *document the existing usage* of t= he P-Charge-Info SIP header per the then-relevant RFC 3427 so that the header could be listed in the IANA registry of SIP parameters at:


http://www.iana= .org/assignments/sip-parameters/sip-parameters.xhtml#sip-parameters-2&nb= sp;


My employer at the time, Voxeo, was (and still is) a strong= user of the header and encouraged me to document it so that others could use the header within private networks.  As an IETF participant and SIP advocate, I personally wanted = to document P-Charge-Info so that perhaps people could find it and use that header instead of creating yet another private header.  Tolga Asveren of Sonus Networks joined on very earl= y in the process because Sonus was (and presumably still is) also actively using the header.  Lots of other people  = chimed in along the way.


After an initial flurry of commentary and changes on the SIPPING list from 2008-2010, there's a longer story of why it took so long... there was the RFC 3427bis process which became RFC 5727... life and job changes... much more...


Anyway, at this point in 2015 I just want to move the document along and get it published so that the header can be registered and, quite honestly, so that I can stop renewing the document every 6 months.  Given that I still get inquiri= es about this header from time to time and that it is still being used, I feel a certain responsibility to just "get this done" rather than simply abandoning the draft.


From what I know, there are three ways I can move this forward to publication:


1. DISPATCH approval - this WG can approve the draft and send to the IESG; [1]

This is not what DISPATCH is designed to do.


2. AD-SPONSORED - I can ask a friendly AD to help send this to the IESG;

This is the path I think this document should take.


3. INDIVIDUAL SUBMISSION - I can send this in to the independent stream editor.

You could do this. Diversion went this way to support the diversion-history-info work.
I would prefer, though, that the document take path 2, and pursue publication as an IETF document.

Am I correct?  And if so, what would any of you suggest as the simplest path to checking this off as done?


Comments on the actual draft are of course also welcome, with the reminder that the aim of the draft was and is to document existing usage rather than to create a new header, etc.  (Because if it was to create a new header, the "P-" would b= e removed, etc.)


Thanks,

Dan


[1] And yes, I do realize there is actually a 4th path which is that DISPATCH could "dispatch" this draft off to some other WG and I could then bring it through *that* WG. And if that's the best path I'm glad to do that, too... I just want to get this finished.





_______________________________________________
dispatch mailing list
dispatc=
h@ietf.orghttps://www.ietf.org/mailman/listinfo/dispatch<=
/pre>

_______________________________________________ dispatch mailing list dispatch@ietf.org https://www.ietf.o= rg/mailman/listinfo/dispatch --B_3516821284_2453400-- From nobody Wed Jun 10 21:29:54 2015 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B03D61A1B49 for ; Wed, 10 Jun 2015 21:29:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.999 X-Spam-Level: X-Spam-Status: No, score=-101.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001, USER_IN_WHITELIST=-100] autolearn=ham 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 2etk6eqsIsbc for ; Wed, 10 Jun 2015 21:29:50 -0700 (PDT) Received: from mail-la0-x22e.google.com (mail-la0-x22e.google.com [IPv6:2a00:1450:4010:c03::22e]) (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 8BF311A1AA8 for ; Wed, 10 Jun 2015 21:29:49 -0700 (PDT) Received: by laar3 with SMTP id r3so44130518laa.3 for ; Wed, 10 Jun 2015 21:29:47 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=JoB5chPhnr+gDErdNWrEDSUeyBsunv2tHRkuL89gJQc=; b=FnlzEjEEmWBtjUOfMQwHvnolsOsx/bAQwRCjum0ek15cYSTGU21GzIfDc3lMLbfDoT 26PqTcJK4emXE/AQx3dwQlzbbJ/MjrYEjy6tuE/96lnikwsJSF70mwDcREQG7E/vMYnK bE32dyQo6S+nDyfLC92uh5x0IOdJ1Zh7o3sO8v/FNkAvLE7BzSvTKE41KkQY6LBL/FcH RAANoVX/KMJ9WyMvoEQbbvxCNoBBs62zKDfiOEqKjtzwPHAJdpXF0Tsc4GnyVflOUbDR 1yFL31bl1HPbPf9oxR82QJzeCDkVm4fK7n99ZbyKFpMk9r4MdaNyAWwCp74wQhQr5pII a4kQ== MIME-Version: 1.0 X-Received: by 10.112.234.200 with SMTP id ug8mr7578357lbc.117.1433996987787; Wed, 10 Jun 2015 21:29:47 -0700 (PDT) Received: by 10.25.128.206 with HTTP; Wed, 10 Jun 2015 21:29:47 -0700 (PDT) In-Reply-To: References: Date: Wed, 10 Jun 2015 23:29:47 -0500 Message-ID: From: Mary Barnes To: Dan York Content-Type: multipart/alternative; boundary=001a11c3cc6210efd205183671f7 Archived-At: Cc: "dispatch@ietf.org" Subject: Re: [dispatch] Need guidance on how to progress draft-york-dispatch-p-charge-info X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 11 Jun 2015 04:29:52 -0000 --001a11c3cc6210efd205183671f7 Content-Type: text/plain; charset=UTF-8 The DISPATCH process is fairly clearly described on the wiki: https://tools.ietf.org/wg/dispatch/trac/wiki So, your option 1. as Robert points out isn't an option with the current process. Option 2 could happen as part of the DISPATCH process and as others have noted seems the most likely outcome. In the case of option 2, the usual process is to ask whether there are any concerns on the DISPATCH WG mailing list and get feedback from the WG participants. The challenge of course is that we've deprecated P-headers and this would be an exception and would have to be clearly documented as such, but I would worry about this opening the floodgate for additional P-headers. We would need to be clear that this isn't the intent here. Regards, Mary. On Wed, Jun 10, 2015 at 2:06 PM, Dan York wrote: > DISPATCH participants, > > > I could use some help/guidance about how to move my > now-seemingly-ancient P-Charge-Info draft forward. The draft is at: > > > https://tools.ietf.org/html/draft-york-dispatch-p-charge-info-05 > > > Way back in 2008, I first submitted the draft to the SIPPING WG. My goal > was simply to *document the existing usage* of the P-Charge-Info SIP header > per the then-relevant RFC 3427 so that the header could be listed in the > IANA registry of SIP parameters at: > > > > http://www.iana.org/assignments/sip-parameters/sip-parameters.xhtml#sip-parameters-2 > > > > My employer at the time, Voxeo, was (and still is) a strong user of the > header and encouraged me to document it so that others could use the header > within private networks. As an IETF participant and SIP advocate, I > personally wanted to document P-Charge-Info so that perhaps people could > find it and use that header instead of creating yet another private > header. Tolga Asveren of Sonus Networks joined on very early in the > process because Sonus was (and presumably still is) also actively using the > header. Lots of other people chimed in along the way. > > > After an initial flurry of commentary and changes on the SIPPING list > from 2008-2010, there's a longer story of why it took so long... there was > the RFC 3427bis process which became RFC 5727... life and job changes... > much more... > > > Anyway, at this point in 2015 I just want to move the document along and > get it published so that the header can be registered and, quite honestly, > so that I can stop renewing the document every 6 months. Given that I > still get inquiries about this header from time to time and that it is > still being used, I feel a certain responsibility to just "get this done" > rather than simply abandoning the draft. > > > From what I know, there are three ways I can move this forward to > publication: > > > 1. DISPATCH approval - this WG can approve the draft and send to the > IESG; [1] > > > 2. AD-SPONSORED - I can ask a friendly AD to help send this to the IESG; > > > 3. INDIVIDUAL SUBMISSION - I can send this in to the independent stream > editor. > > > Am I correct? And if so, what would any of you suggest as the simplest > path to checking this off as done? > > > Comments on the actual draft are of course also welcome, with the > reminder that the aim of the draft was and is to document existing usage > rather than to create a new header, etc. (Because if it was to create a > new header, the "P-" would be removed, etc.) > > > Thanks, > > Dan > > > [1] And yes, I do realize there is actually a 4th path which is that > DISPATCH could "dispatch" this draft off to some other WG and I could then > bring it through *that* WG. And if that's the best path I'm glad to do > that, too... I just want to get this finished. > > > > > _______________________________________________ > dispatch mailing list > dispatch@ietf.org > https://www.ietf.org/mailman/listinfo/dispatch > > --001a11c3cc6210efd205183671f7 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
The DISPATCH process is fairly clearly described on the wi= ki:=C2=A0

S= o, your option 1. as Robert points out isn't an option with the current= process.=C2=A0 Option 2 could happen as part of the DISPATCH process and a= s others have noted seems the most likely outcome.=C2=A0 In the case of opt= ion 2, the usual process is to ask whether there are any concerns on the DI= SPATCH WG mailing list and get feedback from the WG participants. =C2=A0 = =C2=A0 =C2=A0

The challenge of course is that we&#= 39;ve deprecated P-headers and this would be an exception and would have to= be clearly documented as such, but I would worry about this opening the fl= oodgate for additional P-headers.=C2=A0 We would need to be clear that this= isn't the intent here. =C2=A0 =C2=A0

Regards,=
Mary.

On Wed, Jun 10, 2015 at 2:06 PM, Dan York <= york@isoc.org> wrote:

DISPATCH participants,


I could use some help/guidance about how to move my now-seemingly-ancien= t P-Charge-Info draft forward. The draft is at:


https://tools.ietf.org/html/draft-york-dispatch-p-ch= arge-info-05


Way back in 2008, I first submitted the draft to the SIPPING WG. My goal= was simply to *document the existing usage*=C2=A0of the P-Charge-Info SIP = header per the then-relevant=C2=A0RFC 3427 so that the header could be list= ed in the IANA registry of SIP parameters at:


http://www.iana.org/assignments/= sip-parameters/sip-parameters.xhtml#sip-parameters-2=C2=A0


My employer at the time, Voxeo, was (and=C2=A0still is) a strong user of= the header and encouraged me to document it so that others could use the h= eader within private networks.=C2=A0 As an IETF participant and SIP=C2=A0ad= vocate, I personally=C2=A0wanted to document P-Charge-Info so that perhaps people could find it and use that header instead of creati= ng yet another private header.=C2=A0 Tolga Asveren of Sonus Networks joined= on very early in the process because Sonus was (and presumably still is) a= lso actively using the header.=C2=A0 Lots of other people =C2=A0chimed in along the way.


After an initial flurry of commentary and changes on the SIPPING list fr= om 2008-2010, there's a longer story of why it took so long... there wa= s the RFC 3427bis process which became RFC 5727... life and job changes... = much more...


Anyway, at this point in 2015 I just want to move the document along and= get it published so that the header can be registered and, quite honestly,= so that=C2=A0I can stop renewing the document every 6 months.=C2=A0 Given = that I still get inquiries about this header from time to time and that it is still being used, I feel a certain respon= sibility to just "get this done" rather than simply abandoning th= e draft.


From what I know, there are three ways I can move this forward to public= ation:


1. DISPATCH approval - this WG can approve the draft and send to the IES= G; [1]


2. AD-SPONSORED - I can ask a friendly AD to help send this to the IESG;=


3. INDIVIDUAL SUBMISSION - I can send this in to the independent stream = editor.


Am I correct?=C2=A0 And if so, what would any of you suggest as the simp= lest path to checking this off as done?


Comments on the actual draft are of course also welcome, with the remind= er that the aim of the draft was and is to document existing usage rather t= han to create a new header, etc. =C2=A0(Because if it was to create a new h= eader, the "P-" would be removed, etc.)


Thanks,

Dan


[1] And yes, I do realize there is actually a 4th path which is that DIS= PATCH could "dispatch" this draft off to some other WG and I coul= d then bring it through *that* WG. And if that's the best path I'm = glad to do that, too... I just want to get this finished.




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


--001a11c3cc6210efd205183671f7-- From nobody Thu Jun 11 05:50:40 2015 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1B9BA1ACEC1 for ; Thu, 11 Jun 2015 05:50:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_HELO_PASS=-0.001] autolearn=ham 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 xPhkjKTiJqHT for ; Thu, 11 Jun 2015 05:50:34 -0700 (PDT) Received: from mail1.bemta5.messagelabs.com (mail1.bemta5.messagelabs.com [195.245.231.153]) (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 E17311ACEBF for ; Thu, 11 Jun 2015 05:50:33 -0700 (PDT) Received: from [85.158.136.83] by server-17.bemta-5.messagelabs.com id 46/4F-01139-81489755; Thu, 11 Jun 2015 12:50:32 +0000 X-Env-Sender: Peter.Dawes@vodafone.com X-Msg-Ref: server-16.tower-36.messagelabs.com!1434027027!9172601!1 X-Originating-IP: [195.232.244.133] X-StarScan-Received: X-StarScan-Version: 6.13.16; banners=-,-,- X-VirusChecked: Checked Received: (qmail 9422 invoked from network); 11 Jun 2015 12:50:27 -0000 Received: from mailout01.vodafone.com (HELO mailout01.vodafone.com) (195.232.244.133) by server-16.tower-36.messagelabs.com with DHE-RSA-AES256-SHA encrypted SMTP; 11 Jun 2015 12:50:27 -0000 Received: from mailint04.vodafone.com (mailint04.vodafone.com [195.232.244.201]) by mailout01.vodafone.com (Postfix) with ESMTP id 3m6lQq29lqz1yJj; Thu, 11 Jun 2015 14:50:27 +0200 (CEST) Received: from mailint04.vodafone.com (localhost [127.0.0.1]) by mailint04.vodafone.com (Postfix) with ESMTP id 3m6lQT5kqbzfZnN; Thu, 11 Jun 2015 14:50:09 +0200 (CEST) Received: from VOEXC03W.internal.vodafone.com (voexc03w.dc-ratingen.de [145.230.101.23]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by mailint04.vodafone.com (Postfix) with ESMTPS id 3m6lQT57jWzfZlK; Thu, 11 Jun 2015 14:50:09 +0200 (CEST) Received: from VOEXM31W.internal.vodafone.com ([169.254.7.90]) by VOEXC03W.internal.vodafone.com ([145.230.101.23]) with mapi id 14.03.0224.002; Thu, 11 Jun 2015 14:50:08 +0200 From: "Dawes, Peter, Vodafone Group" To: Christer Holmberg , "dispatch@ietf.org" Thread-Topic: New draft: draft-holmberg-dispatch-received-realm-00 Thread-Index: AdCiHwUUGsBUGXYYRyCmNYpBt1QlewBXgnVwAATWnjAALOoNAA== Date: Thu, 11 Jun 2015 12:50:08 +0000 Message-ID: <4A4F136CBD0E0D44AE1EDE36C4CD9D99AEEE2BFF@VOEXM31W.internal.vodafone.com> References: <7594FB04B1934943A5C02806D1A2204B1D8AA730@ESESSMB209.ericsson.se> <4A4F136CBD0E0D44AE1EDE36C4CD9D99AEEE2567@VOEXM31W.internal.vodafone.com> <7594FB04B1934943A5C02806D1A2204B1D8B72D9@ESESSMB209.ericsson.se> In-Reply-To: <7594FB04B1934943A5C02806D1A2204B1D8B72D9@ESESSMB209.ericsson.se> Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: Content-Type: multipart/alternative; boundary="_000_4A4F136CBD0E0D44AE1EDE36C4CD9D99AEEE2BFFVOEXM31Winterna_" MIME-Version: 1.0 Archived-At: Subject: Re: [dispatch] New draft: draft-holmberg-dispatch-received-realm-00 X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 11 Jun 2015 12:50:39 -0000 --_000_4A4F136CBD0E0D44AE1EDE36C4CD9D99AEEE2BFFVOEXM31Winterna_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Thanks Christer, I would like to see this draft progress, I think it describes functionality= that is needed. I have other comments and questions on the text but they c= an be raised later. Regards, Peter From: Christer Holmberg [mailto:christer.holmberg@ericsson.com] Sent: 10 June 2015 16:20 To: Dawes, Peter, Vodafone Group; dispatch@ietf.org Subject: RE: New draft: draft-holmberg-dispatch-received-realm-00 Hi Peter, Thanks for your comments! See inline. > I agree that it is useful for a (transit) network to know which network a= request arrived from, as this > draft argues. But isn't this information to be in the Via header field al= ready in the entry before the > transit network? The draft mentions that inter-operator identifier cannot= be used but I think the >draft should expand on why a new header field parameter is needed. Via headers may contain IP addresses, and they cannot always be used to ide= ntify the network. Also, the consumer of the information would have to scan= through the Via headers, and figure out which belongs to the consumer netw= ork and which belongs to the adjacent network. The purpose of the identifier is to have an explicit indicator, which preve= nts such scanning etc. I try to explain that in the draft, but maybe more text is needed :) Regards, Christer From: dispatch [mailto:dispatch-bounces@ietf.org] On Behalf Of Christer Hol= mberg Sent: 08 June 2015 20:15 To: dispatch@ietf.org Subject: [dispatch] New draft: draft-holmberg-dispatch-received-realm-00 Hi, I've submitted a new draft to dispatch: draft-holmberg-dispatch-received-re= alm-00. The draft defines a new Via header field parameter, "received-realm= ", which network entry entities can insert in order to inform other entitie= s in the network from which network the request was received. Previous versions of the draft have been submitted to SIPCORE, but I was ad= vised by the SIPCORE chairs to submit it to DISPATCH. Compared to previous versions, there is a technical change: the entity whic= h inserts a parameter also calculates a HMAC value, which is inserted toget= her with the network value. Regards, Christer --_000_4A4F136CBD0E0D44AE1EDE36C4CD9D99AEEE2BFFVOEXM31Winterna_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Thanks Christer,<= /o:p>

I would like to see th= is draft progress, I think it describes functionality that is needed. I hav= e other comments and questions on the text but they can be raised later.

 

Regards,

Peter

 

From:= Christer Holmberg [mailto:christer.holmberg@ericsson.com]
Sent: 10 June 2015 16:20
To: Dawes, Peter, Vodafone Group; dispatch@ietf.org
Subject: RE: New draft: draft-holmberg-dispatch-received-realm-00

 

Hi Peter,

 

Thanks for your commen= ts! See inline.

 

> I agree that it i= s useful for a (transit) network to know which network a request arrived fr= om, as this

> draft argues. But= isn’t this information to be in the Via header field already in the = entry before the

> transit network?<= /span> The draft mentions that inter-operator identifier cannot be used but I thin= k the

>draft should expan= d on why a new header field parameter is needed.

 

Via headers may contain IP addresses, and they canno= t always be used to identify the network. Also, the consumer of the informa= tion would have to scan through the Via headers, and figure out which belon= gs to the consumer network and which belongs to the adjacent network.

 

The purpose of the identifier is to have an explicit= indicator, which prevents such scanning etc.

 

I try to explain that in the draft, but maybe more t= ext is needed :)

 

Regards,

 

Christer

 

 

From:= dispatch [mailto:dispatch-bounces@ietf= .org] On Behalf Of Christer Holmberg
Sent: 08 June 2015 20:15
To: dispatch@ietf.org
Subject: [dispatch] New draft: draft-holmberg-dispatch-received-real= m-00

 

Hi,

 

I’ve submitted a new draft to dispatch: draft-= holmberg-dispatch-received-realm-00. The draft defines a new Via header fie= ld parameter, “received-realm”, which network entry entities ca= n insert in order to inform other entities in the network from which network the request was received.

 

Previous versions of the draft have been submitted t= o SIPCORE, but I was advised by the SIPCORE chairs to submit it to DISPATCH= .

 

Compared to previous versions, there is a technical = change: the entity which inserts a parameter also calculates a HMAC value, = which is inserted together with the network value.

 

Regards,

 

Christer

--_000_4A4F136CBD0E0D44AE1EDE36C4CD9D99AEEE2BFFVOEXM31Winterna_-- From nobody Thu Jun 11 09:09:35 2015 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5D8231A87D1 for ; Thu, 11 Jun 2015 09:09:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.318 X-Spam-Level: X-Spam-Status: No, score=-0.318 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, IP_NOT_FRIENDLY=0.334, MIME_QP_LONG_LINE=0.001, RCVD_IN_BL_SPAMCOP_NET=1.347, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=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 CwKofFtzuLye for ; Thu, 11 Jun 2015 09:09:31 -0700 (PDT) Received: from qproxy5-pub.mail.unifiedlayer.com (qproxy5-pub.mail.unifiedlayer.com [69.89.21.30]) by ietfa.amsl.com (Postfix) with SMTP id 4DD471B2B87 for ; Thu, 11 Jun 2015 09:09:26 -0700 (PDT) Received: (qmail 22702 invoked by uid 0); 11 Jun 2015 16:09:24 -0000 Received: from unknown (HELO CMOut01) (10.0.90.82) by qproxy5.mail.unifiedlayer.com with SMTP; 11 Jun 2015 16:09:24 -0000 Received: from box462.bluehost.com ([74.220.219.62]) by CMOut01 with id f3ey1q00D1MNPNq013f1mg; Thu, 11 Jun 2015 09:39:03 -0600 X-Authority-Analysis: v=2.1 cv=GeGEw2nL c=1 sm=1 tr=0 a=jTEj1adHphCQ5SwrTAOQMg==:117 a=jTEj1adHphCQ5SwrTAOQMg==:17 a=cNaOj0WVAAAA:8 a=f5113yIGAAAA:8 a=j1VUBDpLDLYA:10 a=MKtGQD3n3ToA:10 a=1oJP67jkp3AA:10 a=ZZnuYtJkoWoA:10 a=8WrITzYgnNwA:10 a=-h4zUWlAkX4A:10 a=XAFQembCKUMA:10 a=PeFO9FbFhS32YxYntvkA:9 a=dci_DRCyiIAA:10 a=CiRkrLRW1GAA:10 a=iycWLhIX580A:10 a=pGLkceISAAAA:8 a=qerv6Y54AAAA:8 a=48vgC7mUAAAA:8 a=I0CVDw5ZAAAA:8 a=Y_bY35CHMsfZN32Bh2kA:9 a=wPNLvfGTeEIA:10 a=dTtG3SAASjswWQGJug0A:9 a=TGo5tWpxocMk81uT:21 a=_W_S_7VecoQA:10 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=shockey.us; s=default; h=Content-type:Mime-version:In-Reply-To:References:Message-ID:CC:To:From:Subject:Date; bh=o3VzowCy+le7PzmcIGs7Qo/10IXn3xkqgHzy5E2aLdE=; b=j6v/lbtdr3nv0iQbedHw0tO/U5eY3sUwUMfcycSErSTkFzs2ctfDjGgLtuvWkcZZLJ2hsdhu2f2xqzuc1oMb7NKK7lN4x1x4I9ekmP/HHndVWqENgYRJFT/1NrBp4iLR; Received: from [108.56.131.149] (port=50400 helo=[192.168.1.11]) by box462.bluehost.com with esmtpa (Exim 4.84) (envelope-from ) id 1Z34jG-0006FX-Tm; Thu, 11 Jun 2015 09:49:19 -0600 User-Agent: Microsoft-MacOutlook/14.5.1.150515 Date: Thu, 11 Jun 2015 11:49:12 -0400 From: Richard Shockey To: Mary Barnes , Dan York Message-ID: Thread-Topic: [dispatch] Need guidance on how to progress draft-york-dispatch-p-charge-info References: In-Reply-To: Mime-version: 1.0 Content-type: multipart/alternative; boundary="B_3516868158_95819" X-Identified-User: {3286:box462.bluehost.com:shockeyu:shockey.us} {sentby:smtp auth 108.56.131.149 authed with richard+shockey.us} Archived-At: Cc: "dispatch@ietf.org" Subject: Re: [dispatch] Need guidance on how to progress draft-york-dispatch-p-charge-info X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 11 Jun 2015 16:09:34 -0000 > This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. --B_3516868158_95819 Content-type: text/plain; charset="ISO-8859-1" Content-transfer-encoding: quoted-printable BTW It was my understanding that there is actually a regulatory requirement here.=20 Henning, if I recall, mentioned this a while back. I can=B9t recall the context. From: Mary Barnes Date: Thursday, June 11, 2015 at 12:29 AM To: Dan York Cc: "dispatch@ietf.org" Subject: Re: [dispatch] Need guidance on how to progress draft-york-dispatch-p-charge-info The DISPATCH process is fairly clearly described on the wiki: https://tools.ietf.org/wg/dispatch/trac/wiki So, your option 1. as Robert points out isn't an option with the current process. Option 2 could happen as part of the DISPATCH process and as others have noted seems the most likely outcome. In the case of option 2, the usual process is to ask whether there are any concerns on the DISPATCH WG mailing list and get feedback from the WG participants. The challenge of course is that we've deprecated P-headers and this would b= e an exception and would have to be clearly documented as such, but I would worry about this opening the floodgate for additional P-headers. We would need to be clear that this isn't the intent here. Regards, Mary. On Wed, Jun 10, 2015 at 2:06 PM, Dan York wrote: > DISPATCH participants, >=20 >=20 >=20 > I could use some help/guidance about how to move my now-seemingly-ancient > P-Charge-Info draft forward. The draft is at: >=20 >=20 >=20 > https://tools.ietf.org/html/draft-york-dispatch-p-charge-info-05 >=20 >=20 >=20 > Way back in 2008, I first submitted the draft to the SIPPING WG. My goal = was > simply to *document the existing usage* of the P-Charge-Info SIP header p= er > the then-relevant RFC 3427 so that the header could be listed in the IANA > registry of SIP parameters at: >=20 >=20 >=20 > http://www.iana.org/assignments/sip-parameters/sip-parameters.xhtml#sip-p= arame > ters-2=20 >=20 >=20 >=20 > My employer at the time, Voxeo, was (and still is) a strong user of the h= eader > and encouraged me to document it so that others could use the header with= in > private networks. As an IETF participant and SIP advocate, I personally > wanted to document P-Charge-Info so that perhaps people could find it and= use > that header instead of creating yet another private header. Tolga Asvere= n of > Sonus Networks joined on very early in the process because Sonus was (and > presumably still is) also actively using the header. Lots of other peopl= e > chimed in along the way. >=20 >=20 >=20 > After an initial flurry of commentary and changes on the SIPPING list fro= m > 2008-2010, there's a longer story of why it took so long... there was the= RFC > 3427bis process which became RFC 5727... life and job changes... much mor= e... >=20 >=20 >=20 > Anyway, at this point in 2015 I just want to move the document along and = get > it published so that the header can be registered and, quite honestly, so= that > I can stop renewing the document every 6 months. Given that I still get > inquiries about this header from time to time and that it is still being = used, > I feel a certain responsibility to just "get this done" rather than simpl= y > abandoning the draft. >=20 >=20 >=20 > From what I know, there are three ways I can move this forward to publica= tion: >=20 >=20 >=20 > 1. DISPATCH approval - this WG can approve the draft and send to the IESG= ; [1] >=20 >=20 >=20 > 2. AD-SPONSORED - I can ask a friendly AD to help send this to the IESG; >=20 >=20 >=20 > 3. INDIVIDUAL SUBMISSION - I can send this in to the independent stream > editor. >=20 >=20 >=20 > Am I correct? And if so, what would any of you suggest as the simplest p= ath > to checking this off as done? >=20 >=20 >=20 > Comments on the actual draft are of course also welcome, with the reminde= r > that the aim of the draft was and is to document existing usage rather th= an to > create a new header, etc. (Because if it was to create a new header, the= "P-" > would be removed, etc.) >=20 >=20 >=20 > Thanks, >=20 > Dan >=20 >=20 >=20 > [1] And yes, I do realize there is actually a 4th path which is that DISP= ATCH > could "dispatch" this draft off to some other WG and I could then bring i= t > through *that* WG. And if that's the best path I'm glad to do that, too..= . I > just want to get this finished. >=20 >=20 >=20 >=20 >=20 > _______________________________________________ > dispatch mailing list > dispatch@ietf.org > https://www.ietf.org/mailman/listinfo/dispatch >=20 _______________________________________________ dispatch mailing list dispatch@ietf.org https://www.ietf.org/mailman/listinfo/dispatch --B_3516868158_95819 Content-type: text/html; charset="ISO-8859-1" Content-transfer-encoding: quoted-printable

BTW = It was my understanding that there is actually a regulatory requirement here= . 

Henning, if I recall, mentioned this a whil= e back. I can’t recall the context.

From: Mary Barnes <mary.ietf.barnes@gmail.com>
Date: Thursday, June 11, 2015 at 12:29 AM
To: Dan York <york@isoc.org>
Cc: "dispatch@ietf.org" <dispatch@ietf.org>
Subject: Re: [dispatch] Need guidance on how to progress draft-yo= rk-dispatch-p-charge-info

The DISPATC= H process is fairly clearly described on the wiki: 

So, your option 1. as Robert point= s out isn't an option with the current process.  Option 2 could happen = as part of the DISPATCH process and as others have noted seems the most like= ly outcome.  In the case of option 2, the usual process is to ask wheth= er there are any concerns on the DISPATCH WG mailing list and get feedback f= rom the WG participants.      

The c= hallenge of course is that we've deprecated P-headers and this would be an e= xception and would have to be clearly documented as such, but I would worry = about this opening the floodgate for additional P-headers.  We would ne= ed to be clear that this isn't the intent here.    

=
Regards,
Mary.

=
On Wed, Jun 10, 2015 at 2:06 PM, Dan York <york@isoc.org&= gt; wrote:

DISPATCH participants,


I cou= ld use some help/guidance about how to move my now-seemingly-ancient P-Charg= e-Info draft forward. The draft is at:


h= ttps://tools.ietf.org/html/draft-york-dispatch-p-charge-info-05

<= p>

Way back in 2008, I first submitted the draft to the SIPPING WG= . My goal was simply to *document the existing usage* of the P-Charge-I= nfo SIP header per the then-relevant RFC 3427 so that the header could = be listed in the IANA registry of SIP parameters at:


http://www.ian= a.org/assignments/sip-parameters/sip-parameters.xhtml#sip-parameters-2&n= bsp;


My employer at the time, Voxeo, was (and stil= l is) a strong user of the header and encouraged me to document it so that o= thers could use the header within private networks.  As an IETF partici= pant and SIP advocate, I personally wanted to document P-Charge-In= fo so that perhaps people could find it and use that header instead of creati= ng yet another private header.  Tolga Asveren of Sonus Networks joined = on very early in the process because Sonus was (and presumably still is) als= o actively using the header.  Lots of other people  chimed in along the way.


After = an initial flurry of commentary and changes on the SIPPING list from 2008-20= 10, there's a longer story of why it took so long... there was the RFC 3427b= is process which became RFC 5727... life and job changes... much more...
=


Anyway, at this point in 2015 I just want to move the docu= ment along and get it published so that the header can be registered and, qu= ite honestly, so that I can stop renewing the document every 6 months.&= nbsp; Given that I still get inquiries about this header from time to time and that it is still being used, I feel a certain respon= sibility to just "get this done" rather than simply abandoning the draft.


From what I know, there are three ways I can move this fo= rward to publication:


1. DISPATCH approval - this WG ca= n approve the draft and send to the IESG; [1]


2. AD-SPO= NSORED - I can ask a friendly AD to help send this to the IESG;

3. INDIVIDUAL SUBMISSION - I can send this in to the independent st= ream editor.


Am I correct?  And if so, what would = any of you suggest as the simplest path to checking this off as done?


Comments on the actual draft are of course also welcome, with= the reminder that the aim of the draft was and is to document existing usag= e rather than to create a new header, etc.  (Because if it was to creat= e a new header, the "P-" would be removed, etc.)


Thanks= ,

Dan


[1] And yes, I do realize there is actu= ally a 4th path which is that DISPATCH could "dispatch" this draft off to so= me other WG and I could then bring it through *that* WG. And if that's the b= est path I'm glad to do that, too... I just want to get this finished.




_______________________________________________
dispatch mailing list
dispatch@ietf.o= rg
https://www.ietf.org/mailman/listinfo/dispatch


_______________________________________________ dispatch mailing list dispatch@ietf.org https://www.ietf.o= rg/mailman/listinfo/dispatch --B_3516868158_95819-- From nobody Thu Jun 11 10:02:08 2015 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D5AE61B318D for ; Thu, 11 Jun 2015 10:02:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.211 X-Spam-Level: X-Spam-Status: No, score=-4.211 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham 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 Eh8dp1LoFd_o for ; Thu, 11 Jun 2015 10:02:03 -0700 (PDT) Received: from DC-IP-1.fcc.gov (dc-ip-1.fcc.gov [192.104.54.97]) by ietfa.amsl.com (Postfix) with ESMTP id CB4431B3185 for ; Thu, 11 Jun 2015 10:02:02 -0700 (PDT) Message-ID: From: Henning Schulzrinne To: Richard Shockey , Mary Barnes , Dan York Thread-Topic: [dispatch] Need guidance on how to progress draft-york-dispatch-p-charge-info Thread-Index: AQHQo/9LjoZsCBbeckmUHigkSG8TCZ2nt2IA///QUWE= Date: Thu, 11 Jun 2015 17:02:00 +0000 References: , In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Cc: "dispatch@ietf.org" Subject: Re: [dispatch] Need guidance on how to progress draft-york-dispatch-p-charge-info X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 11 Jun 2015 17:02:07 -0000 Yes, carrying the charge number is important for various (arcane) settlemen= t and rural call completion issues; see 47 CFR 64.1601 for one example: Intermediate providers within an interstate or intrastate call path that or= iginates and/or terminates on the PSTN must pass unaltered to subsequent pr= oviders in the call path signaling information identifying the telephone nu= mber, or billing number, if different, of the calling party that is receive= d with a call. https://www.law.cornell.edu/cfr/text/47/64.1601 Henning ________________________________ From: dispatch [dispatch-bounces@ietf.org] on behalf of Richard Shockey [ri= chard@shockey.us] Sent: Thursday, June 11, 2015 11:49 AM To: Mary Barnes; Dan York Cc: dispatch@ietf.org Subject: Re: [dispatch] Need guidance on how to progress draft-york-dispatc= h-p-charge-info BTW It was my understanding that there is actually a regulatory requirement= here. Henning, if I recall, mentioned this a while back. I can=92t recall the con= text. From: Mary Barnes > Date: Thursday, June 11, 2015 at 12:29 AM To: Dan York > Cc: "dispatch@ietf.org" > Subject: Re: [dispatch] Need guidance on how to progress draft-york-dispatc= h-p-charge-info The DISPATCH process is fairly clearly described on the wiki: https://tools.ietf.org/wg/dispatch/trac/wiki So, your option 1. as Robert points out isn't an option with the current pr= ocess. Option 2 could happen as part of the DISPATCH process and as others= have noted seems the most likely outcome. In the case of option 2, the us= ual process is to ask whether there are any concerns on the DISPATCH WG mai= ling list and get feedback from the WG participants. The challenge of course is that we've deprecated P-headers and this would b= e an exception and would have to be clearly documented as such, but I would= worry about this opening the floodgate for additional P-headers. We would= need to be clear that this isn't the intent here. Regards, Mary. On Wed, Jun 10, 2015 at 2:06 PM, Dan York > wrote: DISPATCH participants, I could use some help/guidance about how to move my now-seemingly-ancient P= -Charge-Info draft forward. The draft is at: https://tools.ietf.org/html/draft-york-dispatch-p-charge-info-05 Way back in 2008, I first submitted the draft to the SIPPING WG. My goal wa= s simply to *document the existing usage* of the P-Charge-Info SIP header p= er the then-relevant RFC 3427 so that the header could be listed in the IAN= A registry of SIP parameters at: http://www.iana.org/assignments/sip-parameters/sip-parameters.xhtml#sip-par= ameters-2 My employer at the time, Voxeo, was (and still is) a strong user of the hea= der and encouraged me to document it so that others could use the header wi= thin private networks. As an IETF participant and SIP advocate, I personal= ly wanted to document P-Charge-Info so that perhaps people could find it an= d use that header instead of creating yet another private header. Tolga As= veren of Sonus Networks joined on very early in the process because Sonus w= as (and presumably still is) also actively using the header. Lots of other= people chimed in along the way. After an initial flurry of commentary and changes on the SIPPING list from = 2008-2010, there's a longer story of why it took so long... there was the R= FC 3427bis process which became RFC 5727... life and job changes... much mo= re... Anyway, at this point in 2015 I just want to move the document along and ge= t it published so that the header can be registered and, quite honestly, so= that I can stop renewing the document every 6 months. Given that I still = get inquiries about this header from time to time and that it is still bein= g used, I feel a certain responsibility to just "get this done" rather than= simply abandoning the draft. >From what I know, there are three ways I can move this forward to publicati= on: 1. DISPATCH approval - this WG can approve the draft and send to the IESG; = [1] 2. AD-SPONSORED - I can ask a friendly AD to help send this to the IESG; 3. INDIVIDUAL SUBMISSION - I can send this in to the independent stream edi= tor. Am I correct? And if so, what would any of you suggest as the simplest pat= h to checking this off as done? Comments on the actual draft are of course also welcome, with the reminder = that the aim of the draft was and is to document existing usage rather than= to create a new header, etc. (Because if it was to create a new header, t= he "P-" would be removed, etc.) Thanks, Dan [1] And yes, I do realize there is actually a 4th path which is that DISPAT= CH could "dispatch" this draft off to some other WG and I could then bring = it through *that* WG. And if that's the best path I'm glad to do that, too.= .. I just want to get this finished. _______________________________________________ dispatch mailing list dispatch@ietf.org https://www.ietf.org/mailman/listinfo/dispatch _______________________________________________ dispatch mailing list dispa= tch@ietf.org https://www.ietf.org/mailman/listinf= o/dispatch From nobody Fri Jun 12 01:29:54 2015 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DFA891A88C2 for ; Fri, 12 Jun 2015 01:29:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.201 X-Spam-Level: X-Spam-Status: No, score=-4.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham 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 PYmZReOlaNTv for ; Fri, 12 Jun 2015 01:29:52 -0700 (PDT) Received: from sessmg23.ericsson.net (sessmg23.ericsson.net [193.180.251.45]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9E0BB1A88C1 for ; Fri, 12 Jun 2015 01:29:51 -0700 (PDT) X-AuditID: c1b4fb2d-f794d6d000004501-09-557a987d4391 Received: from ESESSHC014.ericsson.se (Unknown_Domain [153.88.253.125]) by sessmg23.ericsson.net (Symantec Mail Security) with SMTP id 83.B2.17665.D789A755; Fri, 12 Jun 2015 10:29:49 +0200 (CEST) Received: from [127.0.0.1] (153.88.183.153) by smtp.internal.ericsson.com (153.88.183.62) with Microsoft SMTP Server id 14.3.210.2; Fri, 12 Jun 2015 10:29:49 +0200 Message-ID: <557A987D.6070300@ericsson.com> Date: Fri, 12 Jun 2015 10:29:49 +0200 From: Magnus Westerlund User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.7.0 MIME-Version: 1.0 To: DISPATCH list References: <557A9838.6030108@ericsson.com> In-Reply-To: <557A9838.6030108@ericsson.com> X-Forwarded-Message-Id: <557A9838.6030108@ericsson.com> Content-Type: multipart/mixed; boundary="------------070107030200000000080504" X-Brightmail-Tracker: H4sIAAAAAAAAA2WSfyxVYRjH9957znWvZb0u6olZudZmfhUKfwhtUn811bQmG3e3M2647B4Z prqJfjDNz8XBIiQsCUWkuGYypls3YsuPoUyYaVd+zXTPObfN1n+f93mf7/t9zvM9YqF0m7QV K1WJlFolj5WJzImSKzs33W4Vp4Yer5T41uRXkIHoXHX1piAEhZn7XaNilUmU+ph/pHn0t/LA hJHzyc8XCggNWg3KQhIx4BMwu7gj4PkA6CZfirKQuViK+xBsZs6YDrUIDGs7QrbLArvAR+1X kmUCHwX9zJQZyyLsC+Mbd0QsS/Eh2M0wcK/a4DAomm0keK0lDJTMcWxt1HaUTnNsZeSVTAPJ a12ge7We85JgV/g1+1nIT+cDo7psrkeIQ2Dq2ZrwX78m/QGZiyyZPRbMnjYGiY0cANOvk/jy YWhbLhPyHAjlu/Po//pZWB7b4hjwfrg/OGRkdhWvEMzk9HAXUlwkgLH37vxFAQJdayNiDwR+ RECL3iDi5TLo2pjiLAjsAIWz6wJe0YTgp77K5OEExXU6xI7K+r3QOvJla8jSfCF4toDBwn4R qwWcg0Df9d2Mf0iHoLO1FPGHKgHMNLeTjCndH0trJrt+BJMT2abPMCY6fndFxJgSnU4fIBhT ojXdO2bMnkQZLsVwWOxYJtn5rHEM1M5f5TfgD6VLlSK2LDFu+N1jlwrkU49saIqm46I8vdwp tVJB0/EqdxWV2IyMf2tP67ZbO2pYPK1FWIxk+yyOnEoNlZLyJDolTovsxITsoEVxiypUiqPk iVQMRSVQ6gj1jViK1iKBWGKrQVmQN/xwciKo5814jH+vYjhtzLcvycP+tmtuTshQQr0L83Zg xPNyXsOZkEtpvZFFwfHK8eR7m39GU+ckbZ+CnK/bK5vWP1gjr+CUi+GpZcN6haZDRT0JC4jw mJiry2gtdbCyPPnUbKHzt3cCmb5FrtkpbPycL5Sl5VeUTTltO3rLCDpa7uEsVNPyv5O+hJ2O AwAA Archived-At: Subject: [dispatch] Fwd: Re: [Perc] PERC Charter X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: perc@ietf.org List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 12 Jun 2015 08:29:54 -0000 --------------070107030200000000080504 Content-Type: text/plain; charset="windows-1252"; format=flowed Content-Transfer-Encoding: 7bit FYI, We will use the PERC list from here on for this type of discussion. Cheers Magnus --------------070107030200000000080504 Content-Type: message/rfc822; name="Re: [Perc] PERC Charter.eml" Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="Re: [Perc] PERC Charter.eml" X-Mozilla-Keys: Received: from sessmg14.ericsson.net (153.88.183.153) by smtp.internal.ericsson.com (153.88.183.58) with Microsoft SMTP Server id 14.3.210.2; Fri, 12 Jun 2015 10:28:51 +0200 Received: from mail.ietf.org (mail.ietf.org [4.31.198.44]) (using TLS with cipher AES256-SHA (256/256 bits)) (Client did not present a certificate) by sessmg14.ericsson.net (Symantec Mail Security) with SMTP id B2.B7.11394.2489A755; Fri, 12 Jun 2015 10:28:51 +0200 (CEST) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id CCA531A88C7; Fri, 12 Jun 2015 01:28:48 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=ietf.org; s=ietf1; t=1434097728; bh=Ubu6WqcIuad1yDQa/tWN/VItvbpOoiLaD0m609IEIJo=; h=Message-ID:Date:From:MIME-Version:To:References:In-Reply-To:Cc: Subject:List-Id:List-Unsubscribe:List-Archive:List-Post:List-Help: List-Subscribe:Content-Transfer-Encoding:Content-Type:Sender; b=nSQblP6VJ06eWfLvskvBNz5HOCknGRkAnuoS9rG8bpongSsp/qTr4q44WBq72QnzT PBP0eASD8ZB4ZZu5yWimFlFbNZFrBUhjCwK4gkGD1jcFhe2enpL6N1AkBc2tywA7pE RpM0Tw9smqzYIZOA8vNw3ddqG+kiqNbK+ua2gD6Q= X-Original-To: perc@ietfa.amsl.com Delivered-To: perc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1C14C1A88C4 for ; Fri, 12 Jun 2015 01:28:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.201 X-Spam-Level: X-Spam-Status: No, score=-4.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham 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 1HTRakn4Qb1L for ; Fri, 12 Jun 2015 01:28:45 -0700 (PDT) Received: from sessmg22.ericsson.net (sessmg22.ericsson.net [193.180.251.58]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E25FC1A88C1 for ; Fri, 12 Jun 2015 01:28:44 -0700 (PDT) X-AuditID: c1b4fb3e-f792d6d000002c82-54-557a9841a912 Received: from ESESSHC006.ericsson.se (Unknown_Domain [153.88.253.125]) by sessmg22.ericsson.net (Symantec Mail Security) with SMTP id D9.A5.28096.B389A755; Fri, 12 Jun 2015 10:28:43 +0200 (CEST) Received: from [127.0.0.1] (153.88.183.153) by smtp.internal.ericsson.com (153.88.183.38) with Microsoft SMTP Server id 14.3.210.2; Fri, 12 Jun 2015 10:28:42 +0200 Message-ID: <557A9838.6030108@ericsson.com> Date: Fri, 12 Jun 2015 10:28:40 +0200 From: Magnus Westerlund User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.7.0 To: Ben Campbell , Richard Barnes , "Suhas Nandakumar" References: <57945B43-F3CD-450A-ABB5-A97DE52E4570@nostrum.com> In-Reply-To: <57945B43-F3CD-450A-ABB5-A97DE52E4570@nostrum.com> X-Brightmail-Tracker: H4sIAAAAAAAAA1VSbUgTYRz3uTvnKV6dU+ffWahXQrSyrCCLMsOiF/pgoZmW1KXXNtym7Tbx JWKpGJiGhFPTPij5UlEptiDEMkdYZoUvFCZlZmZmjvrgG0nS3W5qffs9z+/t/394SFx+V6Yk uSwTZzSwOkbmRRDBnRs2xlTmxG8u/BgcmffR5hF5q9GBIvuahrBo/ODv6beyWJTktSuV02kz OeOmqDNemrszZzLGgrLyh97hFlSsKEKeJNDb4OvkNCZhBfQMNcmKkBcpp60YNLe2464DgoWu cUw8EPRVAh70T8kkCwOP5z4hERN0KJR9mcUkRzOC4QGHK3cdVN7uEUSkgFfCPfsa6doPiix9 hIRXQO/4nNMLdAmC/scfPKSgPgRd3Q7XUPUYdFtG3Bcn7/7WhItYTj9HYC84KokaEbzP/+mc j6JVMJzXRUjzhUH90z8eIpbRkfB+7pJT40+fgh+tDndJ7wNd10edej9aCx0tNR5SQRRUT9bK xBU86T3QVqGSZiiVQUXHThEjOg5mCwacG+NCTN3IvDPGlw6Bzg/XXM+lhAGb1YUD4VX/a1SK VFX/NFc57SpoqP2BS3gv1DnGUA3C7yB/nuN5vTpiWzhn1KbwfLoh3MCZWpDwHzps81GPUP27 fXZEk4jxpkJ258TL3dlMPltvR4EkxvhTCVrhasXZ9NRsDctrThvNOo63oyCSYAKo6AeGeDmt Zk1cGsdlcMZFdhVJMkAVlgtOHyOn5rLOaXWmZRojPe0ISG/GjyoQNRSfwep5rVriX6JQZQBl EwlaJDRmw5J38RP3odVKXwq5ubnJvYVevdb0Pz+BAoR9fKkrYoq31mBaSp8QijGh+HKxs9jE LlNKC0rpHh0MfRP7pOq8IyI5qa15qy0t4VnejurNzMWxhqkLh9fFpUxYVxXePHbc3BkSPj85 Yx1oLjd/r65ky3I79h9R3/ucrBg0tx8IW3vQuuVFSckN8sQme+xYY8zJqaPP2n0bzj78ZatR 5d5P1lXcz+C2Jy6Er805bmmaUCQe6i1Vt8QzBK9hI9bjRp79Cx9WyRu/AwAA X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFtrCLMWRmVeSWpSXmKPExsUyM+Jvra71jKpQgx/tvBbzO0+zW6xeOJ3R YmqfrcXOuR3MDiweO2fdZfdYsuQnk8fkjbNYPGbtfMISwBLFZZOSmpNZllqkb5fAlbFr7h/m gsVSFQ8/WDUw/hbpYuTkkBAwkTj9fD0zhC0mceHeejYQW0jgKKPEnx6+LkYuIHs5o8TN5vdg CV4BbYkHTSdZQGwWAVWJpQf+soPYbAIWEjd/NILViApESUx9vI4Fol5Q4uTMJ2C2iECmxMFN C8DqmQWEJd6tWge2WFhAUmLalmOMEIvtJGa/WQg0h4ODU8BeYs90bRCTGch8sLUMolNeonnr bGaIam2JhqYO1gmMgrOQLJuF0DELSccCRuZVjKLFqcXFuelGRnqpRZnJxcX5eXp5qSWbGIHB fHDLb6sdjAefOx5iFOBgVOLhVbCtChViTSwrrsw9xCjNwaIkzjtjc16okEB6YklqdmpqQWpR fFFpTmrxIUYmDk6pBsYV9usNbt4XTbaYsGBOtYrF8uDfnAd9C2/wn3H4U23b2DZdZ/HJJUtF mv8lTzHuZZoWZ/vj6RWewFPX40+d2jjVJ+PwzAtGjtc9NbueTMk+vriykfuz3g1LVq1tR5sl dQTehb+J4NL58ZtbzV/FcBer55IL8174zvrQcbGpsnf3Ky3HX2Vbt3crsRRnJBpqMRcVJwIA 1pj9XEcCAAA= Archived-At: CC: Subject: Re: [Perc] PERC Charter X-BeenThere: perc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Privacy Enhanced RTP Conferencing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="windows-1252"; format=flowed Errors-To: perc-bounces@ietf.org Sender: Perc Return-Path: perc-bounces@ietf.org X-MS-Exchange-Organization-AuthSource: ESESSHC013.ericsson.se X-MS-Exchange-Organization-AuthAs: Anonymous X-MS-Exchange-Organization-AVStamp-Mailbox: MSFTFF;1;0;0 0 0 MIME-Version: 1.0 Ben Campbell skrev den 2015-06-11 18:26: > (oops, meant to include the mailing list) > > Hi, > > The PERC charter is approved to go to external review, pending a couple > of last minute things. > > 1) Are you guys willing to put some dates to the milestones? I don't > think it's _required_ for external review, but people will ask. If so, I > will move the milestones from the text to the milestone list. Yes, I am willing to give it an initial shot. Sep 2016 Submit architecture or framework specification to IESG=20 (Standards Track) Jan 2017 Submit documentation of how to integrate solution in SIP,=20 WebRTC and CLUE to IESG (Informational) Jun 2017 Submit SRTP protocol extension specification to IESG=20 (Standards Track) Jun 2017 Submit Key-management protocol specification to IESG=20 (Standards Track) I know people see this as quite urgent, but we actually appear to have=20 quite a lot to discuss on how it should work and be solved. Then we must=20 show due dillegence in getting the pieces well specified and well=20 reviewed and tested. Thus, I think 2 years is not at all uncalled for,=20 unfortunately. > > 2) Do you want to add anything based on Stephen's last email (quoted > below): > >> BTW - just to clarify in case it's useful - I interpret >> the name of this WG and the charter to be implicitly >> saying that the goal is to minimise the amount of data >> (whether metadata or not) that is meaningful to the >> media distribution device. If that's a bad assumption >> then it'd probably be good to bottom out on that during >> chartering. If it's a good assumption then maybe it's >> something to consider being explicit about in the >> charter. (Sorry, I forgot to say that in my initial >> ballot.) > Yes, I think it is a goal. I would propose that we enter into the WG=20 objectives the following sentence: The meta information provided to the central device is to be limited to=20 the minimal required for it to perform its function to preserve the=20 conference participants' privacy. The full paragraph would then read: WG Objectives This WG will work on a solution that enables centralized SRTP-based=20 conferencing, where the central device distributing the media is not=20 required to be trusted with the keys to decrypt the participants=92 media.= =20 The media must be kept confidential and authenticated between an=20 originating endpoint and the explicitly allowed receiving endpoints or=20 other devices. The meta information provided to the central device is to=20 be limited to the minimal required for it to perform its function to=20 preserve the conference participants privacy. Further, it is desired=20 that a solution still provides replay protection, so that the media=20 distribution devices can=92t replay previous parts of the media. Opinions on that. Please respond quickly. Magnus Westerlund ---------------------------------------------------------------------- Services, Media and Network features, Ericsson Research EAB/TXM ---------------------------------------------------------------------- Ericsson AB | Phone +46 10 7148287 F=E4r=F6gatan 6 | Mobile +46 73 0949079 SE-164 80 Stockholm, Sweden | mailto: magnus.westerlund@ericsson.com ---------------------------------------------------------------------- _______________________________________________ Perc mailing list Perc@ietf.org https://www.ietf.org/mailman/listinfo/perc --------------070107030200000000080504-- From nobody Fri Jun 12 14:03:44 2015 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2BD331B2AC6; Fri, 12 Jun 2015 14:03:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.9 X-Spam-Level: X-Spam-Status: No, score=-101.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, USER_IN_WHITELIST=-100] autolearn=ham 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 lJzRFhsay6a6; Fri, 12 Jun 2015 14:03:41 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 3DD671B2ABE; Fri, 12 Jun 2015 14:03:39 -0700 (PDT) Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 8bit From: The IESG To: "IETF-Announce" X-Test-IDTracker: no X-IETF-IDTracker: 6.0.3.p2 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20150612210339.32575.99047.idtracker@ietfa.amsl.com> Date: Fri, 12 Jun 2015 14:03:39 -0700 Archived-At: Cc: perc WG Subject: [dispatch] WG Review: Privacy Enhanced RTP Conferencing (perc) X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.15 List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 12 Jun 2015 21:03:43 -0000 A new IETF working group has been proposed in the Applications and Real-Time Area. The IESG has not made any determination yet. The following draft charter was submitted, and is provided for informational purposes only. Please send your comments to the IESG mailing list (iesg at ietf.org) by 2015-06-22. Privacy Enhanced RTP Conferencing (perc) ------------------------------------------------ Current Status: Proposed WG Chairs: Richard Barnes Suhas Nandakumar Assigned Area Director: Ben Campbell Mailing list Address: dispatch@ietf.org To Subscribe: Archive: Charter: RTP-based real-time multi-party interactive media conferencing is in widespread use today. Many of the deployments use one or more centrally located media distribution devices that perform selective forwarding of mixed-media streams received from the participating endpoints. The media transport protocol commonly used is RTP (RFC3550). There are various signaling systems used to establish these multi-party conferences. These conferences require security to ensure that the RTP media and related metadata of the conference is kept private and only available to the set of invited participants and other devices trusted by those participants with their media. At the same time, multi-party media conferences need source authentication and integrity checks to protect against modifications, insertions, and replay attacks. Media distribution devices supporting these conferences may also perform RTP header changes, and they often consume and create RTCP messages for efficient media handling. To date, deployment models for these multi-party media distribution devices do not enable the devices to perform their functions without having keys to decrypt the participants’ media, primarily using Secure RTP (RFC3711) to provide session security. This trust model has limitations and prevents or hampers deployment of secure RTP conferencing in a multitude of cases, including outsourcing, legal requirements on confidentiality, and utilization of virtualized servers. Thus, a new architectural model and related specifications are needed, with a focused effort from the RTP and Security communities. WG Objectives This WG will work on a solution that enables centralized SRTP-based conferencing, where the central device distributing the media is not required to be trusted with the keys to decrypt the participants' media. The media must be kept confidential and authenticated between an originating endpoint and the explicitly allowed receiving endpoints or other devices. The meta information provided to the central device is to be limited to the minimal required for it to perform its function to preserve the conference participants privacy. Further, it is desired that a solution still provides replay protection, so that the media distribution devices can’t replay previous parts of the media. The solution must also provide security for each hop between endpoints and multi-party media distribution devices and between multi-party media distribution devices. The RTCP messages and RTP header extensions required for the media distribution device to perform the selective media forwarding may require both source authentication and integrity as well as confidentiality. The solution may also consider providing end-to-end security for a subset of the RTCP messages or RTP header extensions. The solution should be implementable by both SIP (RFC3261) and WebRTC endpoints (draft-ietf-rtcweb-overview). How telepresence endpoints using the protocols defined in the CLUE working group could utilize the defined security solution needs to be considered. However, it is acknowledged that limitations may exist, resulting in restricted functionality or need for additional adaptations of the CLUE protocols. This working group will perform the following work: 1. Define a general architecture and RTP topology(s) that enables end-to-end media security for multi-party RTP conferencing. 2. Define the trust model and describe the resulting security properties. 3. Document models considered for integrating the solution with WebRTC, SIP and CLUE establishment of conferencing sessions. 4. Specify any necessary extensions to SRTP. 5. Define needed Key Management Functions that distribute the keys. The system needs to be able to bind the media to the identity of the sender of the media and/or the identity of the conference. Collaboration If there is identification of missing protocols or functionalities, such work can be requested to be done in another working group with a suitable charter or by requests for chartering it in this WG or another WG. Potential items that might require work in other WGs are DTLS extensions (TLS WG) and RTP header extensions (AVTEXT WG). This work requires strong collaboration with the security area. We will notify, and when needed coordinate with, AVTCore, CLUE, MMUSIC, RTCWEB, SIPREC, W3C WebRTC, and other related groups about this work. Non-Goals The PERC working group is not chartered to extend any signaling system used to establish the RTP-based conferences. It will, however, need to consider in its architecture how the solution may integrate with these systems, and document such consideration for WebRTC, SIP, and CLUE. The specification of how a particular system integrates the security solution will happen outside of this working group, in suitable venues. The WG will not consider non-real-time usage, multicast-based media distribution, or Security descriptions-based keying (RFC4568). Input to the WG Proposals already existing relating to this charter proposal: https://datatracker.ietf.org/doc/draft-jones-avtcore-private-media-reqts/ https://datatracker.ietf.org/doc/draft-jones-avtcore-private-media-framework/ https://datatracker.ietf.org/doc/draft-cheng-avtcore-srtp-cloud/ Milestones: Sep 2016 - Submit architecture or framework specification to IESG (Standards Track) Jan 2017 - Submit documentation of how to integrate solution in SIP, WebRTC and CLUE to IESG (Informational) Jun 2017 - Submit SRTP protocol extension specification to IESG (Standards Track) Jun 2017 - Submit Key-management protocol specification to IESG (Standards Track) From nobody Thu Jun 18 11:04:37 2015 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AECA81B2B4B for ; Thu, 18 Jun 2015 11:04:35 -0700 (PDT) X-Quarantine-ID: X-Virus-Scanned: amavisd-new at amsl.com X-Amavis-Alert: BAD HEADER SECTION, Duplicate header field: "MIME-Version" X-Spam-Flag: NO X-Spam-Score: -7.011 X-Spam-Level: X-Spam-Status: No, score=-7.011 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham 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 e95B3MBsy1Tz for ; Thu, 18 Jun 2015 11:04:34 -0700 (PDT) Received: from wolverine01.qualcomm.com (wolverine01.qualcomm.com [199.106.114.254]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0EA621B2B6F for ; Thu, 18 Jun 2015 11:04:25 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=qti.qualcomm.com; i=@qti.qualcomm.com; q=dns/txt; s=qcdkim; t=1434650665; x=1466186665; h=message-id:date:to:from:subject; bh=OaOoIQTEsxSKKUL+raVU1qS6I7HVcMjtSmTRJxKGio0=; b=n34Y0dntbcnNeLWFfvi6B+Nik0mnW0EAxOs6X7gO/4z92KWu2UjhqP9b q3ut8zdr7lII/EvyMKfQ6yKFlplXpM58ynk32d+rk7mGdR5LvE8wXpvy2 mvaubjQoINNNEH+etJ5JC60bHoFjAa9Cmdhiu4JUI70aqDb6xSO/9NyL8 c=; X-IronPort-AV: E=McAfee;i="5700,7163,7836"; a="123924350" Received: from ironmsg04-l.qualcomm.com ([172.30.48.19]) by wolverine01.qualcomm.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 18 Jun 2015 11:04:24 -0700 X-IronPort-AV: E=Sophos;i="5.13,640,1427785200"; d="scan'208";a="913966001" X-ojodefuego: yes Received: from unknown (HELO [99.111.97.136]) ([10.64.197.226]) by Ironmsg04-L.qualcomm.com with ESMTP; 18 Jun 2015 11:04:23 -0700 Mime-Version: 1.0 Message-Id: X-Mailer: Eudora for Mac OS X Date: Thu, 18 Jun 2015 11:04:22 -0700 To: dispatch@ietf.org From: Randall Gellens Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Random-Sig-Tag: 1.0b28 Archived-At: Subject: [dispatch] Bridge/Link info: Virtual Bar-BoF for SLIM: June 18 @2-3 PDT X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 18 Jun 2015 18:04:35 -0000 The time and date for the virtual Bar-BoF for SLIM (from the Doodle poll) is June 18 at 2-3 PDT (5-6 EDT). To follow up on the SLIM face-to-face discussion in Dallas, this virtual bar-BoF provides an opportunity for further discussion on moving forward with a charter. In particular: (1) Are there objections to the current proposed charter wording, or is it acceptable? (2) Are there objections to moving forward on this basis? Please participate in the virtual Bar-BoF. The WebEx link will be sent in advance. I'm sending this message to the dispatch list, but all discussion should take place on the SLIM list. JOIN WEBEX MEETING https://ietf.webex.com/ietf/j.php?MTID=m1b2db0345d0037b70066ce7b94b6c07d Meeting number: 648 397 435 Meeting password: slimbof JOIN BY PHONE 1-877-668-4493 Call-in toll free number (US/Canada) 1-650-479-3208 Call-in toll number (US/Canada) Access code: 648 397 435 Toll-free dialing restrictions: http://www.webex.com/pdf/tollfree_restrictions.pdf Can't join the meeting? Contact support here: https://ietf.webex.com/ietf/mc -- Randall Gellens Opinions are personal; facts are suspect; I speak for myself only -------------- Randomly selected tag: --------------- Algol was a great improvement on most of its successors. --C.A.R Hoare From nobody Mon Jun 22 00:24:28 2015 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B61E11B2D96 for ; Mon, 22 Jun 2015 00:24:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.5 X-Spam-Level: X-Spam-Status: No, score=-1.5 tagged_above=-999 required=5 tests=[BAYES_50=0.8, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham 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 9lVTw3lx894I for ; Mon, 22 Jun 2015 00:24:25 -0700 (PDT) Received: from sessmg23.ericsson.net (sessmg23.ericsson.net [193.180.251.45]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 524411B2D99 for ; Mon, 22 Jun 2015 00:24:24 -0700 (PDT) X-AuditID: c1b4fb2d-f794d6d000004501-c1-5587b826653c Received: from ESESSHC020.ericsson.se (Unknown_Domain [153.88.253.125]) by sessmg23.ericsson.net (Symantec Mail Security) with SMTP id 48.16.17665.628B7855; Mon, 22 Jun 2015 09:24:22 +0200 (CEST) Received: from ESESSMB305.ericsson.se ([169.254.5.124]) by ESESSHC020.ericsson.se ([153.88.183.78]) with mapi id 14.03.0210.002; Mon, 22 Jun 2015 09:24:21 +0200 From: Jan Holm To: Roland Jesske , "DOLLY, MARTIN C" , Christer Holmberg , "dispatch@ietf.org" Thread-Topic: [dispatch] New draft: draft-holmberg-dispatch-received-realm-00 Thread-Index: AQHQo4e4GsBUGXYYRyCmNYpBt1Qle524McKw Date: Mon, 22 Jun 2015 07:24:21 +0000 Message-ID: <3D5559CA03CD4346AF73974A97A3A743261CE671@ESESSMB305.ericsson.se> References: In-Reply-To: Accept-Language: sv-SE, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [153.88.183.18] Content-Type: multipart/alternative; boundary="_000_3D5559CA03CD4346AF73974A97A3A743261CE671ESESSMB305erics_" MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFmpkkeLIzCtJLcpLzFFi42KZGfG3VldtR3uowbP3MhZLJy1gtTj04Cm7 xcoNbxgdmD1e9s9h9Fiy5CeTx+1n21gCmKO4bFJSczLLUov07RK4Mrq/ehV8iKpYtuggYwPj hoguRg4OCQETiWkTlLoYOYFMMYkL99azdTFycQgJHGWU+Lr4HAuEs4RRYsn972wgVWwCahJz +9aBVYkIrGWUaHv5mxkkISzgI9E79x47yFQRAV+JzlZnkLCIgJHE24mrWUBsFgFViX2T74LZ vEAl15f9AJspJBApsXHzJnYQm1MgSmLPjLlgIxkFZCXuf78HVs8sIC5x68l8JohLBSSW7DnP DGGLSrx8/I8VwlaU+PhqHyNEfb7E1jUfoHYJSpyc+YRlAqPILCSjZiEpm4WkbBbQB8wCmhLr d+lDlChKTOl+yA5ha0i0zpnLjiy+gJF9FaNocWpxcW66kbFealFmcnFxfp5eXmrJJkZgnB3c 8lt3B+Pq146HGAU4GJV4eBVy2kOFWBPLiitzDzFKc7AoifPO2JwXKiSQnliSmp2aWpBaFF9U mpNafIiRiYNTqoFRYO1kxT7z/lDed77V2bcm5fv+mj39ikTt+TNT13mduWx80OTAuUW+368W RBb7Wf8qPNkx7+mG8zYzN9+eHJzmYcO9P+JXesrkY9f9DJS7q84xerHlJohe72201Xr18/Bf +eZnYaU7fv0QuLS7wi5Ze6HUid383ru2+vS6hM86d2jJhDOLepWNlViKMxINtZiLihMB9A5B 0pQCAAA= Archived-At: Subject: Re: [dispatch] New draft: draft-holmberg-dispatch-received-realm-00 X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 22 Jun 2015 07:24:26 -0000 --_000_3D5559CA03CD4346AF73974A97A3A743261CE671ESESSMB305erics_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 KzENClJlZ2FyZHMgSmFuIEhvbG0NCg0KRnJvbTogZGlzcGF0Y2ggW21haWx0bzpkaXNwYXRjaC1i b3VuY2VzQGlldGYub3JnXSBPbiBCZWhhbGYgT2YgUm9sYW5kIEplc3NrZQ0KU2VudDogZGVuIDEw IGp1bmkgMjAxNSAxNjoxNA0KVG86IERPTExZLCBNQVJUSU4gQzsgQ2hyaXN0ZXIgSG9sbWJlcmc7 IGRpc3BhdGNoQGlldGYub3JnDQpTdWJqZWN0OiBSZTogW2Rpc3BhdGNoXSBOZXcgZHJhZnQ6IGRy YWZ0LWhvbG1iZXJnLWRpc3BhdGNoLXJlY2VpdmVkLXJlYWxtLTAwDQoNCisxDQpSZWdhcmRzDQpS b2xhbmQNCi0tDQpEaWVzZSBOYWNocmljaHQgd3VyZGUgdm9uIG1laW5lbSBBbmRyb2lkIE1vYmls dGVsZWZvbiBtaXQgV0VCLkRFPGh0dHA6Ly9XRUIuREU+IE1haWwgZ2VzZW5kZXQuDQoNCg0KIkRP TExZLCBNQVJUSU4gQyIgPG1kMzEzNUBhdHQuY29tPG1haWx0bzptZDMxMzVAYXR0LmNvbT4+c2No cmllYjoNCkkgc3VwcG9ydCB0aGlzIGRyYWZ0IG1vdmluZyBmb3J3YXJkDQoNCkZyb206IGRpc3Bh dGNoIFttYWlsdG86ZGlzcGF0Y2gtYm91bmNlc0BpZXRmLm9yZ10gT24gQmVoYWxmIE9mIENocmlz dGVyIEhvbG1iZXJnDQpTZW50OiBNb25kYXksIEp1bmUgMDgsIDIwMTUgMzoxNSBQTQ0KVG86IGRp c3BhdGNoQGlldGYub3JnPG1haWx0bzpkaXNwYXRjaEBpZXRmLm9yZz4NClN1YmplY3Q6IFtkaXNw YXRjaF0gTmV3IGRyYWZ0OiBkcmFmdC1ob2xtYmVyZy1kaXNwYXRjaC1yZWNlaXZlZC1yZWFsbS0w MA0KDQpIaSwNCg0KSeKAmXZlIHN1Ym1pdHRlZCBhIG5ldyBkcmFmdCB0byBkaXNwYXRjaDogZHJh ZnQtaG9sbWJlcmctZGlzcGF0Y2gtcmVjZWl2ZWQtcmVhbG0tMDAuIFRoZSBkcmFmdCBkZWZpbmVz IGEgbmV3IFZpYSBoZWFkZXIgZmllbGQgcGFyYW1ldGVyLCDigJxyZWNlaXZlZC1yZWFsbeKAnSwg d2hpY2ggbmV0d29yayBlbnRyeSBlbnRpdGllcyBjYW4gaW5zZXJ0IGluIG9yZGVyIHRvIGluZm9y bSBvdGhlciBlbnRpdGllcyBpbiB0aGUgbmV0d29yayBmcm9tIHdoaWNoIG5ldHdvcmsgdGhlIHJl cXVlc3Qgd2FzIHJlY2VpdmVkLg0KDQpQcmV2aW91cyB2ZXJzaW9ucyBvZiB0aGUgZHJhZnQgaGF2 ZSBiZWVuIHN1Ym1pdHRlZCB0byBTSVBDT1JFLCBidXQgSSB3YXMgYWR2aXNlZCBieSB0aGUgU0lQ Q09SRSBjaGFpcnMgdG8gc3VibWl0IGl0IHRvIERJU1BBVENILg0KDQpDb21wYXJlZCB0byBwcmV2 aW91cyB2ZXJzaW9ucywgdGhlcmUgaXMgYSB0ZWNobmljYWwgY2hhbmdlOiB0aGUgZW50aXR5IHdo aWNoIGluc2VydHMgYSBwYXJhbWV0ZXIgYWxzbyBjYWxjdWxhdGVzIGEgSE1BQyB2YWx1ZSwgd2hp Y2ggaXMgaW5zZXJ0ZWQgdG9nZXRoZXIgd2l0aCB0aGUgbmV0d29yayB2YWx1ZS4NCg0KUmVnYXJk cywNCg0KQ2hyaXN0ZXINCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fIGRpc3BhdGNoIG1haWxpbmcgbGlzdCBkaXNwYXRjaEBpZXRmLm9yZzxtYWlsdG86ZGlz cGF0Y2hAaWV0Zi5vcmc+IGh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vZGlz cGF0Y2gNCg== --_000_3D5559CA03CD4346AF73974A97A3A743261CE671ESESSMB305erics_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTQgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 Q2FsaWJyaTsNCglwYW5vc2UtMToyIDE1IDUgMiAyIDIgNCAzIDIgNDt9DQpAZm9udC1mYWNlDQoJ e2ZvbnQtZmFtaWx5OlRhaG9tYTsNCglwYW5vc2UtMToyIDExIDYgNCAzIDUgNCA0IDIgNDt9DQov KiBTdHlsZSBEZWZpbml0aW9ucyAqLw0KcC5Nc29Ob3JtYWwsIGxpLk1zb05vcm1hbCwgZGl2Lk1z b05vcm1hbA0KCXttYXJnaW46MGNtOw0KCW1hcmdpbi1ib3R0b206LjAwMDFwdDsNCglmb250LXNp emU6MTEuMHB0Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIiwic2Fucy1zZXJpZiI7fQ0KYTpsaW5r LCBzcGFuLk1zb0h5cGVybGluaw0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6IzA1 NjNDMTsNCgl0ZXh0LWRlY29yYXRpb246dW5kZXJsaW5lO30NCmE6dmlzaXRlZCwgc3Bhbi5Nc29I eXBlcmxpbmtGb2xsb3dlZA0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6Izk1NEY3 MjsNCgl0ZXh0LWRlY29yYXRpb246dW5kZXJsaW5lO30NCnAuTXNvQWNldGF0ZSwgbGkuTXNvQWNl dGF0ZSwgZGl2Lk1zb0FjZXRhdGUNCgl7bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCW1zby1zdHls ZS1saW5rOiJCYWxsb29uIFRleHQgQ2hhciI7DQoJbWFyZ2luOjBjbTsNCgltYXJnaW4tYm90dG9t Oi4wMDAxcHQ7DQoJZm9udC1zaXplOjguMHB0Ow0KCWZvbnQtZmFtaWx5OiJUYWhvbWEiLCJzYW5z LXNlcmlmIjt9DQpzcGFuLmVtYWlsc3R5bGUxNw0KCXttc28tc3R5bGUtbmFtZTplbWFpbHN0eWxl MTc7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLCJzYW5zLXNlcmlmIjsNCgljb2xvcjp3aW5kb3d0 ZXh0O30NCnNwYW4uZW1haWxzdHlsZTE4DQoJe21zby1zdHlsZS1uYW1lOmVtYWlsc3R5bGUxODsN Cglmb250LWZhbWlseToiQ2FsaWJyaSIsInNhbnMtc2VyaWYiOw0KCWNvbG9yOiMxRjQ5N0Q7fQ0K c3Bhbi5CYWxsb29uVGV4dENoYXINCgl7bXNvLXN0eWxlLW5hbWU6IkJhbGxvb24gVGV4dCBDaGFy IjsNCgltc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJbXNvLXN0eWxlLWxpbms6IkJhbGxvb24gVGV4 dCI7DQoJZm9udC1mYW1pbHk6IlRhaG9tYSIsInNhbnMtc2VyaWYiO30NCnNwYW4uRW1haWxTdHls ZTIxDQoJe21zby1zdHlsZS10eXBlOnBlcnNvbmFsLXJlcGx5Ow0KCWZvbnQtZmFtaWx5OiJDYWxp YnJpIiwic2Fucy1zZXJpZiI7DQoJY29sb3I6IzFGNDk3RDt9DQouTXNvQ2hwRGVmYXVsdA0KCXtt c28tc3R5bGUtdHlwZTpleHBvcnQtb25seTsNCglmb250LXNpemU6MTAuMHB0O30NCkBwYWdlIFdv cmRTZWN0aW9uMQ0KCXtzaXplOjYxMi4wcHQgNzkyLjBwdDsNCgltYXJnaW46NzAuODVwdCA3MC44 NXB0IDcwLjg1cHQgNzAuODVwdDt9DQpkaXYuV29yZFNlY3Rpb24xDQoJe3BhZ2U6V29yZFNlY3Rp b24xO30NCi0tPjwvc3R5bGU+PCEtLVtpZiBndGUgbXNvIDldPjx4bWw+DQo8bzpzaGFwZWRlZmF1 bHRzIHY6ZXh0PSJlZGl0IiBzcGlkbWF4PSIxMDI2IiAvPg0KPC94bWw+PCFbZW5kaWZdLS0+PCEt LVtpZiBndGUgbXNvIDldPjx4bWw+DQo8bzpzaGFwZWxheW91dCB2OmV4dD0iZWRpdCI+DQo8bzpp ZG1hcCB2OmV4dD0iZWRpdCIgZGF0YT0iMSIgLz4NCjwvbzpzaGFwZWxheW91dD48L3htbD48IVtl bmRpZl0tLT4NCjwvaGVhZD4NCjxib2R5IGxhbmc9IlNWIiBsaW5rPSIjMDU2M0MxIiB2bGluaz0i Izk1NEY3MiI+DQo8ZGl2IGNsYXNzPSJXb3JkU2VjdGlvbjEiPg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+PHNwYW4gc3R5bGU9ImNvbG9yOiMxRjQ5N0QiPiYjNDM7MTxvOnA+PC9vOnA+PC9zcGFuPjwv cD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJjb2xvcjojMUY0OTdEIj5SZWdh cmRzIEphbiBIb2xtPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ PHNwYW4gc3R5bGU9ImNvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4N CjxkaXY+DQo8ZGl2IHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItdG9wOnNvbGlkICNCNUM0REYg MS4wcHQ7cGFkZGluZzozLjBwdCAwY20gMGNtIDBjbSI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48 Yj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6 JnF1b3Q7VGFob21hJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPkZyb206PC9zcGFuPjwv Yj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6 JnF1b3Q7VGFob21hJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPiBkaXNwYXRjaCBbbWFp bHRvOmRpc3BhdGNoLWJvdW5jZXNAaWV0Zi5vcmddDQo8Yj5PbiBCZWhhbGYgT2YgPC9iPlJvbGFu ZCBKZXNza2U8YnI+DQo8Yj5TZW50OjwvYj4gZGVuIDEwIGp1bmkgMjAxNSAxNjoxNDxicj4NCjxi PlRvOjwvYj4gRE9MTFksIE1BUlRJTiBDOyBDaHJpc3RlciBIb2xtYmVyZzsgZGlzcGF0Y2hAaWV0 Zi5vcmc8YnI+DQo8Yj5TdWJqZWN0OjwvYj4gUmU6IFtkaXNwYXRjaF0gTmV3IGRyYWZ0OiBkcmFm dC1ob2xtYmVyZy1kaXNwYXRjaC1yZWNlaXZlZC1yZWFsbS0wMDxvOnA+PC9vOnA+PC9zcGFuPjwv cD4NCjwvZGl2Pg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpw PjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tYm90dG9tOjEyLjBwdCI+ PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMi4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7VGltZXMgTmV3 IFJvbWFuJnF1b3Q7LCZxdW90O3NlcmlmJnF1b3Q7Ij4mIzQzOzE8YnI+DQpSZWdhcmRzPGJyPg0K Um9sYW5kPGJyPg0KLS0gPGJyPg0KRGllc2UgTmFjaHJpY2h0IHd1cmRlIHZvbiBtZWluZW0gQW5k cm9pZCBNb2JpbHRlbGVmb24gbWl0IDxhIGhyZWY9Imh0dHA6Ly9XRUIuREUiPg0KV0VCLkRFPC9h PiBNYWlsIGdlc2VuZGV0LjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxkaXY+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEyLjBwdDtmb250LWZhbWlseTomcXVv dDtUaW1lcyBOZXcgUm9tYW4mcXVvdDssJnF1b3Q7c2VyaWYmcXVvdDsiPjxicj4NCjxicj4NCjwv c3Bhbj48c3BhbiBsYW5nPSJFTi1HQiIgc3R5bGU9ImZvbnQtc2l6ZToxMi4wcHQ7Zm9udC1mYW1p bHk6JnF1b3Q7VGltZXMgTmV3IFJvbWFuJnF1b3Q7LCZxdW90O3NlcmlmJnF1b3Q7Ij4mcXVvdDtE T0xMWSwgTUFSVElOIEMmcXVvdDsgJmx0Ozwvc3Bhbj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEy LjBwdDtmb250LWZhbWlseTomcXVvdDtUaW1lcyBOZXcgUm9tYW4mcXVvdDssJnF1b3Q7c2VyaWYm cXVvdDsiPjxhIGhyZWY9Im1haWx0bzptZDMxMzVAYXR0LmNvbSI+PHNwYW4gbGFuZz0iRU4tR0Ii Pm1kMzEzNUBhdHQuY29tPC9zcGFuPjwvYT48L3NwYW4+PHNwYW4gbGFuZz0iRU4tR0IiIHN0eWxl PSJmb250LXNpemU6MTIuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O1RpbWVzIE5ldyBSb21hbiZxdW90 OywmcXVvdDtzZXJpZiZxdW90OyI+Jmd0O3NjaHJpZWI6PG86cD48L286cD48L3NwYW4+PC9wPg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImNvbG9yOiMxRjQ5N0QiPkkgc3VwcG9y dCB0aGlzIGRyYWZ0IG1vdmluZyBmb3J3YXJkPC9zcGFuPg0KPG86cD48L286cD48L3A+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iY29sb3I6IzFGNDk3RCI+Jm5ic3A7PC9zcGFu PiA8bzpwPjwvbzpwPjwvcD4NCjxkaXY+DQo8ZGl2IHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXIt dG9wOnNvbGlkICNFMUUxRTEgMS4wcHQ7cGFkZGluZzozLjBwdCAwY20gMGNtIDBjbSI+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj48Yj48c3BhbiBsYW5nPSJFTi1HQiI+RnJvbTo8L3NwYW4+PC9iPjxz cGFuIGxhbmc9IkVOLUdCIj4gZGlzcGF0Y2ggWzwvc3Bhbj48YSBocmVmPSJtYWlsdG86ZGlzcGF0 Y2gtYm91bmNlc0BpZXRmLm9yZyI+PHNwYW4gbGFuZz0iRU4tR0IiPm1haWx0bzpkaXNwYXRjaC1i b3VuY2VzQGlldGYub3JnPC9zcGFuPjwvYT48c3BhbiBsYW5nPSJFTi1HQiI+XTxiPiBPbiBCZWhh bGYgT2Y8L2I+IENocmlzdGVyIEhvbG1iZXJnPGJyPg0KPGI+U2VudDo8L2I+IE1vbmRheSwgSnVu ZSAwOCwgMjAxNSAzOjE1IFBNPGJyPg0KPGI+VG86PC9iPiA8L3NwYW4+PGEgaHJlZj0ibWFpbHRv OmRpc3BhdGNoQGlldGYub3JnIj48c3BhbiBsYW5nPSJFTi1HQiI+ZGlzcGF0Y2hAaWV0Zi5vcmc8 L3NwYW4+PC9hPjxzcGFuIGxhbmc9IkVOLUdCIj48YnI+DQo8Yj5TdWJqZWN0OjwvYj4gW2Rpc3Bh dGNoXSBOZXcgZHJhZnQ6IGRyYWZ0LWhvbG1iZXJnLWRpc3BhdGNoLXJlY2VpdmVkLXJlYWxtLTAw IDxvOnA+DQo8L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPjxzcGFuIGxhbmc9IkVOLUdCIj4mbmJzcDsgPG86cD48L286cD48L3NwYW4+PC9wPg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+SGksIDxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+Jm5ic3A7IDxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+SeKAmXZl IHN1Ym1pdHRlZCBhIG5ldyBkcmFmdCB0byBkaXNwYXRjaDogZHJhZnQtaG9sbWJlcmctZGlzcGF0 Y2gtcmVjZWl2ZWQtcmVhbG0tMDAuIFRoZSBkcmFmdCBkZWZpbmVzIGEgbmV3IFZpYSBoZWFkZXIg ZmllbGQgcGFyYW1ldGVyLCDigJxyZWNlaXZlZC1yZWFsbeKAnSwgd2hpY2ggbmV0d29yayBlbnRy eSBlbnRpdGllcyBjYW4gaW5zZXJ0IGluIG9yZGVyIHRvIGluZm9ybSBvdGhlciBlbnRpdGllcyBp biB0aGUgbmV0d29yaw0KIGZyb20gd2hpY2ggbmV0d29yayB0aGUgcmVxdWVzdCB3YXMgcmVjZWl2 ZWQuIDxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Jm5ic3A7IDxvOnA+PC9v OnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+UHJldmlvdXMgdmVyc2lvbnMgb2YgdGhlIGRy YWZ0IGhhdmUgYmVlbiBzdWJtaXR0ZWQgdG8gU0lQQ09SRSwgYnV0IEkgd2FzIGFkdmlzZWQgYnkg dGhlIFNJUENPUkUgY2hhaXJzIHRvIHN1Ym1pdCBpdCB0byBESVNQQVRDSC4NCjxvOnA+PC9vOnA+ PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Jm5ic3A7IDxvOnA+PC9vOnA+PC9wPg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+Q29tcGFyZWQgdG8gcHJldmlvdXMgdmVyc2lvbnMsIHRoZXJlIGlzIGEg dGVjaG5pY2FsIGNoYW5nZTogdGhlIGVudGl0eSB3aGljaCBpbnNlcnRzIGEgcGFyYW1ldGVyIGFs c28gY2FsY3VsYXRlcyBhIEhNQUMgdmFsdWUsIHdoaWNoIGlzIGluc2VydGVkIHRvZ2V0aGVyIHdp dGggdGhlIG5ldHdvcmsgdmFsdWUuDQo8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPiZuYnNwOyA8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPlJlZ2FyZHMs IDxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Jm5ic3A7IDxvOnA+PC9vOnA+ PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Q2hyaXN0ZXIgPG86cD48L286cD48L3A+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1HQiIgc3R5bGU9ImZvbnQtc2l6ZToxMi4w cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7VGltZXMgTmV3IFJvbWFuJnF1b3Q7LCZxdW90O3NlcmlmJnF1 b3Q7Ij5fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXyBkaXNw YXRjaCBtYWlsaW5nIGxpc3QNCjwvc3Bhbj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEyLjBwdDtm b250LWZhbWlseTomcXVvdDtUaW1lcyBOZXcgUm9tYW4mcXVvdDssJnF1b3Q7c2VyaWYmcXVvdDsi PjxhIGhyZWY9Im1haWx0bzpkaXNwYXRjaEBpZXRmLm9yZyI+PHNwYW4gbGFuZz0iRU4tR0IiPmRp c3BhdGNoQGlldGYub3JnPC9zcGFuPjwvYT48YSBocmVmPSJodHRwczovL3d3dy5pZXRmLm9yZy9t YWlsbWFuL2xpc3RpbmZvL2Rpc3BhdGNoIiB0YXJnZXQ9Il9ibGFuayI+PHNwYW4gbGFuZz0iRU4t R0IiPiBodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL2Rpc3BhdGNoPC9zcGFu PjwvYT48L3NwYW4+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMi4wcHQ7Zm9udC1mYW1pbHk6JnF1 b3Q7VGltZXMgTmV3IFJvbWFuJnF1b3Q7LCZxdW90O3NlcmlmJnF1b3Q7Ij4NCjxzcGFuIGxhbmc9 IkVOLUdCIj48bzpwPjwvbzpwPjwvc3Bhbj48L3NwYW4+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwv Ym9keT4NCjwvaHRtbD4NCg== --_000_3D5559CA03CD4346AF73974A97A3A743261CE671ESESSMB305erics_-- From nobody Mon Jun 22 15:04:30 2015 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1A50C1AD481 for ; Mon, 22 Jun 2015 15:04:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -97.032 X-Spam-Level: X-Spam-Status: No, score=-97.032 tagged_above=-999 required=5 tests=[BAYES_60=1.5, HELO_EQ_RU=0.595, HOST_EQ_RU=0.875, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, USER_IN_WHITELIST=-100] autolearn=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 H_jZ_gMuJfnG for ; Mon, 22 Jun 2015 15:04:27 -0700 (PDT) Received: from msk-mail-app01.ti.ru (msk-mail-app01.ti.ru [89.20.149.130]) by ietfa.amsl.com (Postfix) with ESMTP id 2A6921AD35E for ; Mon, 22 Jun 2015 15:04:25 -0700 (PDT) Received: from [151.252.67.136] (account fas_vm@surguttel.ru HELO surguttel.ru) by msk-mail-app01.ti.ru (CommuniGate Pro SMTP 5.2.20) with ESMTPA id 12136671 for dispatch@ietf.org; Tue, 23 Jun 2015 01:04:22 +0300 From: "Anton Tveretin" To: dispatch@ietf.org Date: Tue, 23 Jun 2015 03:03:55 +0500 MIME-Version: 1.0 Message-ID: <5588864B.30003.1B2AC860@fas_vm.surguttel.ru> Priority: normal X-mailer: Pegasus Mail for Windows (4.70) Content-type: text/plain; charset=US-ASCII Content-transfer-encoding: 7BIT Content-description: Mail message body X-Antivirus: avast! (VPS 150622-3, 22.06.2015), Outbound message X-Antivirus-Status: Clean Archived-At: Subject: Re: [dispatch] New draft: draft-holmberg-dispatch-received-realm-00 X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 22 Jun 2015 22:04:29 -0000 You've got one more supporter. From nobody Tue Jun 23 02:11:42 2015 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4B0AE1AC398 for ; Tue, 23 Jun 2015 02:11:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham 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 bQ6MzmNS8mNC for ; Tue, 23 Jun 2015 02:11:40 -0700 (PDT) Received: from mail-pa0-x22b.google.com (mail-pa0-x22b.google.com [IPv6:2607:f8b0:400e:c03::22b]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2AA6D1ABD8F for ; Tue, 23 Jun 2015 02:11:40 -0700 (PDT) Received: by pabvl15 with SMTP id vl15so3121328pab.1 for ; Tue, 23 Jun 2015 02:11:39 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=from:content-type:content-transfer-encoding:subject:message-id:date :to:mime-version; bh=HLxcLzS4/g3u4iBXVbTp4WC/vYnBtjqRQ7gmjcjHbqU=; b=iCC5oF+mCpms8ZwU7gKvddWa/5wPc94lVII42oSi220Q/gjP37xspyCPc1BCNInnF2 ePbNH1OI0JPDePrrkIah+ddJwnAr+69NA4DOJpfIVPq1r8jgttCQ4KiZaxhpJ1RRZTCR NwupXiRiLiP96uVtTf72SrTKzS9lKO1g0z1tAtR/QyuUhsNinAUR2qxTmkjalTXdiSZA 2LxTGpy2EKHtyl/xCcUiXPHp/DdJKKrpbo6YxR1+sgLNRm6vlr0vWHMhat7ucsmVcNsf CdvTQpCq+BHEJzkTpV+r6FZlQBQQoiSWxuwzwCTM4kM8whzFCYtuyWN4Lv+EFWv7kNOV +IFQ== X-Received: by 10.68.193.232 with SMTP id hr8mr67352493pbc.145.1435050699783; Tue, 23 Jun 2015 02:11:39 -0700 (PDT) Received: from [192.168.1.100] ([120.153.56.24]) by mx.google.com with ESMTPSA id mx5sm22509877pdb.75.2015.06.23.02.11.37 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Tue, 23 Jun 2015 02:11:39 -0700 (PDT) From: James Winterbottom Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Message-Id: <1FDDC22B-849A-448D-AA1C-657064B84C55@gmail.com> Date: Tue, 23 Jun 2015 19:11:31 +1000 To: dispatch@ietf.org Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2098\)) X-Mailer: Apple Mail (2.2098) Archived-At: Subject: [dispatch] draft-winterbottom-dispatch-locparam X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 23 Jun 2015 09:11:41 -0000 Hi All, I a notice about this draft a few weeks ago but haven=E2=80=99t seen and = follow up discussion. This work is required in ETSI and I believe that as I understand from = some 3GPP folks they would like something similar to this also. https://tools.ietf.org/html/draft-winterbottom-dispatch-locparam-00 I am just not sure where the right final home for it is. Cheers James From nobody Thu Jun 25 01:22:10 2015 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E85481B3245 for ; Thu, 25 Jun 2015 01:22:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham 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 o92Ik0dGTOWh for ; Thu, 25 Jun 2015 01:22:07 -0700 (PDT) Received: from mail-wi0-x236.google.com (mail-wi0-x236.google.com [IPv6:2a00:1450:400c:c05::236]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4017B1B3231 for ; Thu, 25 Jun 2015 01:22:07 -0700 (PDT) Received: by wibdq8 with SMTP id dq8so68122255wib.1 for ; Thu, 25 Jun 2015 01:22:06 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=JXVu8EHVWEXjbpfLASgJGpNFN3uPcNcY4yf5JPnZj6k=; b=wEcyZUSs5uypa4VNl3AKWfOSXmnMYh0ScqUgA2EOOjHxZO7QsNRoNaigcx87Ywn2Wp Vn4op7qWrCFc3IJuThh5yKrLL7Y98oFiu0n3H6LWMORERo0UKmHBiwEditUUlwmbz577 /Mr5+NoGOdn6yHH8VDUDxAUFCrywcFwzpLUBWIHPrpwAADi6wlO65xT5EO7T1kvD6/6Z uMaVfamUsn9e5CH44c5fXeAxJzp2KnmV0nJfRS/BcTeWG+pmXUaq9tDgd9M7evah/fJn cJTuCQF05Lt6zUvZ/0rE55mSzrz/rM8OhjwlFEKZNbYrqfCbprwJQ+Pxy4GJSDA5cUe7 OLIw== MIME-Version: 1.0 X-Received: by 10.194.85.163 with SMTP id i3mr76269451wjz.141.1435220525679; Thu, 25 Jun 2015 01:22:05 -0700 (PDT) Received: by 10.28.16.14 with HTTP; Thu, 25 Jun 2015 01:22:05 -0700 (PDT) In-Reply-To: <4A4F136CBD0E0D44AE1EDE36C4CD9D99AEEE2BFF@VOEXM31W.internal.vodafone.com> References: <7594FB04B1934943A5C02806D1A2204B1D8AA730@ESESSMB209.ericsson.se> <4A4F136CBD0E0D44AE1EDE36C4CD9D99AEEE2567@VOEXM31W.internal.vodafone.com> <7594FB04B1934943A5C02806D1A2204B1D8B72D9@ESESSMB209.ericsson.se> <4A4F136CBD0E0D44AE1EDE36C4CD9D99AEEE2BFF@VOEXM31W.internal.vodafone.com> Date: Thu, 25 Jun 2015 10:22:05 +0200 Message-ID: From: Victor Pascual Avila To: "Dawes, Peter, Vodafone Group" Content-Type: multipart/alternative; boundary=089e010d82909b8c1a0519535153 Archived-At: Cc: "dispatch@ietf.org" Subject: Re: [dispatch] New draft: draft-holmberg-dispatch-received-realm-00 X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 25 Jun 2015 08:22:10 -0000 --089e010d82909b8c1a0519535153 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable +1 On Thu, Jun 11, 2015 at 2:50 PM, Dawes, Peter, Vodafone Group < Peter.Dawes@vodafone.com> wrote: > Thanks Christer, > > I would like to see this draft progress, I think it describes > functionality that is needed. I have other comments and questions on the > text but they can be raised later. > > > > Regards, > > Peter > > > > *From:* Christer Holmberg [mailto:christer.holmberg@ericsson.com] > *Sent:* 10 June 2015 16:20 > *To:* Dawes, Peter, Vodafone Group; dispatch@ietf.org > *Subject:* RE: New draft: draft-holmberg-dispatch-received-realm-00 > > > > Hi Peter, > > > > Thanks for your comments! See inline. > > > > > I agree that it is useful for a (transit) network to know which network > a request arrived from, as this > > > draft argues. But isn=E2=80=99t this information to be in the Via heade= r field > already in the entry before the > > > transit network? The draft mentions that inter-operator identifier > cannot be used but I think the > > >draft should expand on why a new header field parameter is needed. > > > > Via headers may contain IP addresses, and they cannot always be used to > identify the network. Also, the consumer of the information would have to > scan through the Via headers, and figure out which belongs to the consume= r > network and which belongs to the adjacent network. > > > > The purpose of the identifier is to have an explicit indicator, which > prevents such scanning etc. > > > > I try to explain that in the draft, but maybe more text is needed :) > > > > Regards, > > > > Christer > > > > > > *From:* dispatch [mailto:dispatch-bounces@ietf.org > ] *On Behalf Of *Christer Holmberg > *Sent:* 08 June 2015 20:15 > *To:* dispatch@ietf.org > *Subject:* [dispatch] New draft: draft-holmberg-dispatch-received-realm-0= 0 > > > > Hi, > > > > I=E2=80=99ve submitted a new draft to dispatch: > draft-holmberg-dispatch-received-realm-00. The draft defines a new Via > header field parameter, =E2=80=9Creceived-realm=E2=80=9D, which network e= ntry entities can > insert in order to inform other entities in the network from which networ= k > the request was received. > > > > Previous versions of the draft have been submitted to SIPCORE, but I was > advised by the SIPCORE chairs to submit it to DISPATCH. > > > > Compared to previous versions, there is a technical change: the entity > which inserts a parameter also calculates a HMAC value, which is inserted > together with the network value. > > > > Regards, > > > > Christer > > _______________________________________________ > dispatch mailing list > dispatch@ietf.org > https://www.ietf.org/mailman/listinfo/dispatch > > --=20 Victor Pascual =C3=81vila --089e010d82909b8c1a0519535153 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
+1

On Thu, Jun 11, 2015 at 2:50 PM, Dawes, Peter, Vodafone Group <Peter.Dawes@vodafone.com> wrote:

Thanks Christer= ,

I would like to= see this draft progress, I think it describes functionality that is needed= . I have other comments and questions on the text but they can be raised la= ter.

=C2=A0

Regards,=

Peter

=C2=A0

From: Christer Holmberg [mailto:christer.holmberg@ericsson.com]
Sent: 10 June 2015 16:20
To: Dawes, Peter, Vodafone Group; dispatch@ietf.org
Subject: RE: New draft: draft-holmberg-dispatch-received-realm-00=

=C2=A0

Hi Peter,

=C2=A0

Thanks for your= comments! See inline.

=C2=A0

> I agree th= at it is useful for a (transit) network to know which network a request arr= ived from, as this

> draft argu= es. But isn=E2=80=99t this information to be in the Via header field alread= y in the entry before the

> transit ne= twork? The draft mentions that inter-operator identifier cannot be used but I thin= k the

>draft shoul= d expand on why a new header field parameter is needed.

=C2=A0

Via headers may contain IP addresses, and they canno= t always be used to identify the network. Also, the consumer of the informa= tion would have to scan through the Via headers, and figure out which belon= gs to the consumer network and which belongs to the adjacent network.

=C2=A0

The purpose of the identifier is to have an explicit= indicator, which prevents such scanning etc.

=C2=A0

I try to explain that in the draft, but maybe more t= ext is needed :)

=C2=A0

Regards,

=C2=A0

Christer

=C2=A0

=C2=A0

From: dispatch [mailto:dis= patch-bounces@ietf.org] On Behalf Of Christer Holmberg
Sent: 08 June 2015 20:15
To: dispatch@= ietf.org
Subject: [dispatch] New draft: draft-holmberg-dispatch-received-real= m-00

=C2=A0

Hi,

=C2=A0

I=E2=80=99ve submitted a new draft to dispatch: draf= t-holmberg-dispatch-received-realm-00. The draft defines a new Via header f= ield parameter, =E2=80=9Creceived-realm=E2=80=9D, which network entry entit= ies can insert in order to inform other entities in the network from which network the request was received.

=C2=A0

Previous versions of the draft have been submitted t= o SIPCORE, but I was advised by the SIPCORE chairs to submit it to DISPATCH= .

=C2=A0

Compared to previous versions, there is a technical = change: the entity which inserts a parameter also calculates a HMAC value, = which is inserted together with the network value.

=C2=A0

Regards,

=C2=A0

Christer


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




--
Victor Pascual =C3=81vila
--089e010d82909b8c1a0519535153-- From nobody Thu Jun 25 10:16:06 2015 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 764C31AC3BB for ; Thu, 25 Jun 2015 10:15:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.1 X-Spam-Level: X-Spam-Status: No, score=0.1 tagged_above=-999 required=5 tests=[BAYES_50=0.8, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham 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 Irz5JkbVWuV2 for ; Thu, 25 Jun 2015 10:15:56 -0700 (PDT) Received: from zucker2.schokokeks.org (zucker2.schokokeks.org [178.63.68.90]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 36E611AC3B8 for ; Thu, 25 Jun 2015 10:15:51 -0700 (PDT) Received: from [192.168.1.11] (chello212186126020.11.vie.surfer.at [::ffff:212.186.126.20]) (AUTH: PLAIN bubestinger@schokokeks.org, TLS: TLSv1/SSLv3, 128bits, ECDHE-RSA-AES128-GCM-SHA256) by zucker.schokokeks.org with ESMTPSA; Thu, 25 Jun 2015 19:15:47 +0200 id 00000000000000F3.00000000558C3743.00006A75 Message-ID: <558C3744.7040302@das-werkstatt.com> Date: Thu, 25 Jun 2015 19:15:48 +0200 From: "Peter B." User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.5.0 MIME-Version: 1.0 To: dispatch@ietf.org References: <5FF8B7A3-BEB0-4F7B-9825-0F56F193C2D6@cisco.com> <5564D62E.9070506@xiph.org> In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [dispatch] Standardization of FFV1, Matroska X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 25 Jun 2015 17:15:58 -0000 I thought it might be a good idea to present some additional information about importance of and interest in an IETF specification for the users of FFV1 in Matroska (MKV) for lossless video encoding: At the Austrian National A/V Archive (the Austrian Mediathek) [1], we've performed extensive tests of FFV1's implementation in collaboration with other archives and companies. The U.S. Library of Congress has also included FFV1/MKV as archiving format in their recent list of preservation formats [3]. Technically, FFV1 can be considered not only stable, but very suitable for long-term preservation. Its origin and current reference implementation was written by Michael Niedermayer, project leader of FFmpeg [2]. Yet, for easier adoption among institutions that deal with long-term preservation of video, it is desirable to have a proper standardization reference for the format of choice. Format decisions in that case must consider future accessibility, as well as proper interoperability between the applications used. Therefore, it is strongly advised to use standardized, open formats. FFV1 is currently completely open, but its paper specification is still under development, and its lack of standardization is preventing many organizations from using it in their archives. At the moment, the only alternative would be JPEG2000-lossless in MXF container. Although both are defined in ISO standards, codec as well as container implementations are suffering from diverse interoperability issues. In practice, FFV1 has turned out to be a very good, faster and simpler alternative, and using Matroska as container format has several benefits over others (like AVI or MOV). Some companies have already deployed installations at broadcasters and national archives using FFV1, and have already offered financial aid to fund the technical specifications of FFV1. I'd therefore be very grateful and happy to see engagement by the IETF community in discussion of the specifications and suitability of FFV1/MKV for IETF. Thank you very much in advance, Peter Bubestinger == References: [1] http://www.mediathek.at/ [2] http://ffmpeg.org/ [3] http://www.digitizationguidelines.gov/guidelines/video_reformatting_compare.html From nobody Thu Jun 25 10:36:08 2015 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 17B591A036D for ; Thu, 25 Jun 2015 10:36:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham 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 5EDgJ_d1pTIO for ; Thu, 25 Jun 2015 10:36:05 -0700 (PDT) Received: from zucker2.schokokeks.org (zucker2.schokokeks.org [178.63.68.90]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A1C791A0199 for ; Thu, 25 Jun 2015 10:36:05 -0700 (PDT) Received: from [192.168.1.11] (chello212186126020.11.vie.surfer.at [::ffff:212.186.126.20]) (AUTH: PLAIN bubestinger@schokokeks.org, TLS: TLSv1/SSLv3, 128bits, ECDHE-RSA-AES128-GCM-SHA256) by zucker.schokokeks.org with ESMTPSA; Thu, 25 Jun 2015 19:36:03 +0200 id 0000000000000119.00000000558C3C03.0000082D Message-ID: <558C3C03.7090403@das-werkstatt.com> Date: Thu, 25 Jun 2015 19:36:03 +0200 From: "Peter B." User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.5.0 MIME-Version: 1.0 To: dispatch@ietf.org References: <5FF8B7A3-BEB0-4F7B-9825-0F56F193C2D6@cisco.com> <5564D62E.9070506@xiph.org> <558C3744.7040302@das-werkstatt.com> In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [dispatch] Standardization of FFV1, Matroska X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 25 Jun 2015 17:36:07 -0000 On 06/25/2015 07:18 PM, Tessa Fallon wrote: > :) +1 thanks! :) btw: I've just seen that this year's World Conference of FIAT/IFTA (International Federation of Television Archives) [1] mentions FFV1 explicitly in their Call for Papers [2]: [quote] Archives and technology evolution [...] Is FFV1 the new JPEG2000? [/quote] Yet another indicator that standardization of FFV1 gains more interest :) Regards, Peter B. == References: [1] http://fiatifta.org/world-conference-2015-vienna/ [2] http://fiatifta.org/wp-content/uploads/2015/06/call-for-presentation-world-conference.pdf From nobody Tue Jun 30 01:21:58 2015 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C97EC1A1B03 for ; Tue, 30 Jun 2015 01:21:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, UNPARSEABLE_RELAY=0.001] autolearn=ham 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 vpPu5vxan_MK for ; Tue, 30 Jun 2015 01:21:55 -0700 (PDT) Received: from relais-inet.francetelecom.com (relais-ias245.francetelecom.com [80.12.204.245]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 209851A1AB8 for ; Tue, 30 Jun 2015 01:21:54 -0700 (PDT) Received: from omfeda08.si.francetelecom.fr (unknown [xx.xx.xx.201]) by omfeda09.si.francetelecom.fr (ESMTP service) with ESMTP id 6340AC0B6D; Tue, 30 Jun 2015 10:21:52 +0200 (CEST) Received: from Exchangemail-eme2.itn.ftgroup (unknown [10.114.31.32]) by omfeda08.si.francetelecom.fr (ESMTP service) with ESMTP id 40B7438406B; Tue, 30 Jun 2015 10:21:52 +0200 (CEST) Received: from OPEXCLILM23.corporate.adroot.infra.ftgroup ([fe80::787e:db0c:23c4:71b3]) by OPEXCLILM32.corporate.adroot.infra.ftgroup ([fe80::8924:188:2124:a046%19]) with mapi id 14.03.0235.001; Tue, 30 Jun 2015 10:21:52 +0200 From: To: James Winterbottom , "dispatch@ietf.org" Thread-Topic: [dispatch] draft-winterbottom-dispatch-locparam Thread-Index: AQHQrZShCYaDi4+sH0KaaTnELEvtAp3Ev2dA Date: Tue, 30 Jun 2015 08:21:51 +0000 Message-ID: <21058_1435652512_559251A0_21058_4734_1_88CAD1D4E8773F42858B58CAA28272A015C228F4@OPEXCLILM23.corporate.adroot.infra.ftgroup> References: <1FDDC22B-849A-448D-AA1C-657064B84C55@gmail.com> In-Reply-To: <1FDDC22B-849A-448D-AA1C-657064B84C55@gmail.com> Accept-Language: fr-FR, en-US Content-Language: fr-FR X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.168.234.5] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-PMX-Version: 6.2.1.2478543, Antispam-Engine: 2.7.2.2107409, Antispam-Data: 2015.6.30.72417 Archived-At: Subject: Re: [dispatch] draft-winterbottom-dispatch-locparam X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 30 Jun 2015 08:21:57 -0000 SW5kZWVkLCBpdCBpcyBpbXBvcnRhbnQgZm9yIHRoYXQgdGhpcyB3b3JrIGJlIGRpc3BhdGNoZWQg dG8gdGhlIHJpZ2h0IHBsYWNlIHF1aWNrbHkgYW5kIG1vdmVzIGZvcndhcmQuDQpCcnVubw0KDQo+ IC0tLS0tTWVzc2FnZSBkJ29yaWdpbmUtLS0tLQ0KPiBEZcKgOiBkaXNwYXRjaCBbbWFpbHRvOmRp c3BhdGNoLWJvdW5jZXNAaWV0Zi5vcmddIERlIGxhIHBhcnQgZGUgSmFtZXMNCj4gV2ludGVyYm90 dG9tDQo+IEVudm95w6nCoDogbWFyZGkgMjMganVpbiAyMDE1IDExOjEyDQo+IMOAwqA6IGRpc3Bh dGNoQGlldGYub3JnDQo+IE9iamV0wqA6IFtkaXNwYXRjaF0gZHJhZnQtd2ludGVyYm90dG9tLWRp c3BhdGNoLWxvY3BhcmFtDQo+IA0KPiBIaSBBbGwsDQo+IA0KPiBJIGEgbm90aWNlIGFib3V0IHRo aXMgZHJhZnQgYSBmZXcgd2Vla3MgYWdvIGJ1dCBoYXZlbuKAmXQgc2VlbiBhbmQgZm9sbG93IHVw DQo+IGRpc2N1c3Npb24uDQo+IFRoaXMgd29yayBpcyByZXF1aXJlZCBpbiBFVFNJIGFuZCBJIGJl bGlldmUgdGhhdCBhcyBJIHVuZGVyc3RhbmQgZnJvbSBzb21lDQo+IDNHUFAgZm9sa3MgdGhleSB3 b3VsZCBsaWtlIHNvbWV0aGluZyBzaW1pbGFyIHRvIHRoaXMgYWxzby4NCj4gDQo+IGh0dHBzOi8v dG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC13aW50ZXJib3R0b20tZGlzcGF0Y2gtbG9jcGFyYW0t MDANCj4gDQo+IEkgYW0ganVzdCBub3Qgc3VyZSB3aGVyZSB0aGUgcmlnaHQgZmluYWwgaG9tZSBm b3IgaXQgaXMuDQo+IA0KPiBDaGVlcnMNCj4gSmFtZXMNCj4gDQo+IF9fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQo+IGRpc3BhdGNoIG1haWxpbmcgbGlzdA0K PiBkaXNwYXRjaEBpZXRmLm9yZw0KPiBodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3Rp bmZvL2Rpc3BhdGNoDQoKX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fXwoKQ2UgbWVzc2FnZSBldCBzZXMgcGllY2VzIGpvaW50ZXMg cGV1dmVudCBjb250ZW5pciBkZXMgaW5mb3JtYXRpb25zIGNvbmZpZGVudGllbGxlcyBvdSBwcml2 aWxlZ2llZXMgZXQgbmUgZG9pdmVudCBkb25jCnBhcyBldHJlIGRpZmZ1c2VzLCBleHBsb2l0ZXMg b3UgY29waWVzIHNhbnMgYXV0b3Jpc2F0aW9uLiBTaSB2b3VzIGF2ZXogcmVjdSBjZSBtZXNzYWdl IHBhciBlcnJldXIsIHZldWlsbGV6IGxlIHNpZ25hbGVyCmEgbCdleHBlZGl0ZXVyIGV0IGxlIGRl dHJ1aXJlIGFpbnNpIHF1ZSBsZXMgcGllY2VzIGpvaW50ZXMuIExlcyBtZXNzYWdlcyBlbGVjdHJv bmlxdWVzIGV0YW50IHN1c2NlcHRpYmxlcyBkJ2FsdGVyYXRpb24sCk9yYW5nZSBkZWNsaW5lIHRv dXRlIHJlc3BvbnNhYmlsaXRlIHNpIGNlIG1lc3NhZ2UgYSBldGUgYWx0ZXJlLCBkZWZvcm1lIG91 IGZhbHNpZmllLiBNZXJjaS4KClRoaXMgbWVzc2FnZSBhbmQgaXRzIGF0dGFjaG1lbnRzIG1heSBj b250YWluIGNvbmZpZGVudGlhbCBvciBwcml2aWxlZ2VkIGluZm9ybWF0aW9uIHRoYXQgbWF5IGJl IHByb3RlY3RlZCBieSBsYXc7CnRoZXkgc2hvdWxkIG5vdCBiZSBkaXN0cmlidXRlZCwgdXNlZCBv ciBjb3BpZWQgd2l0aG91dCBhdXRob3Jpc2F0aW9uLgpJZiB5b3UgaGF2ZSByZWNlaXZlZCB0aGlz IGVtYWlsIGluIGVycm9yLCBwbGVhc2Ugbm90aWZ5IHRoZSBzZW5kZXIgYW5kIGRlbGV0ZSB0aGlz IG1lc3NhZ2UgYW5kIGl0cyBhdHRhY2htZW50cy4KQXMgZW1haWxzIG1heSBiZSBhbHRlcmVkLCBP cmFuZ2UgaXMgbm90IGxpYWJsZSBmb3IgbWVzc2FnZXMgdGhhdCBoYXZlIGJlZW4gbW9kaWZpZWQs IGNoYW5nZWQgb3IgZmFsc2lmaWVkLgpUaGFuayB5b3UuCgo=