From nobody Sun Nov 1 23:05:52 2015 Return-Path: X-Original-To: bfcpbis@ietfa.amsl.com Delivered-To: bfcpbis@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4ADE11B3338 for ; Sun, 1 Nov 2015 23:05:50 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.201 X-Spam-Level: X-Spam-Status: No, score=-4.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, 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 Us4VsFFxisRp for ; Sun, 1 Nov 2015 23:05:39 -0800 (PST) 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 C88341A0040 for ; Sun, 1 Nov 2015 23:05:37 -0800 (PST) X-AuditID: c1b4fb25-f79a26d00000149a-57-56370b3f2c3c Received: from ESESSHC005.ericsson.se (Unknown_Domain [153.88.253.125]) by sesbmg23.ericsson.net (Symantec Mail Security) with SMTP id FC.42.05274.F3B07365; Mon, 2 Nov 2015 08:05:36 +0100 (CET) Received: from ESESSMB209.ericsson.se ([169.254.9.202]) by ESESSHC005.ericsson.se ([153.88.183.33]) with mapi id 14.03.0248.002; Mon, 2 Nov 2015 08:04:50 +0100 From: Christer Holmberg To: "Charles Eckel (eckelcu)" , "Tom Kristensen (tomkrist)" Thread-Topic: Status update on draft-ietf-mmusic-dtls-sdp [was: [bfcpbis] draft-ietf-bfcpbis-rfc4583bis] Thread-Index: AdEVPGtzePVeqGKXRT2MOxuY5KEVyA== Date: Mon, 2 Nov 2015 07:04:49 +0000 Message-ID: <7594FB04B1934943A5C02806D1A2204B37BC8F7B@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: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFprMIsWRmVeSWpSXmKPExsUyM+Jvra4Dt3mYwa/XzBbTz/xltJjfeZrd 4t+6o0wWt9bfZrHYNOsLm8WVI7/YHNg8pvzeyOrx5clLJo8lS34yecza+YTF48vlz2wBrFFc NimpOZllqUX6dglcGRs/zmcp+HWMueLj5D0sDYxLdjN3MXJySAiYSPzc3scKYYtJXLi3nq2L kYtDSOAIo8SFbfsZIZzFjBJXFqwF6uDgYBOwkOj+pw3SICKQKnFiYQdYM7NAK5PEoU4vEFsY KP5s6gVGiJosicbZU9kgbD2JJ087WUBsFgEViUvHboPV8Ar4Srz98gXsIEagI76fWsMEMVNc 4taT+UwQxwlILNlzHupoUYmXj/9BHa0k0bjkCSvIacwCmhLrd+lDtCpKTOl+yA4xXlDi5Mwn LBMYRWYhmToLoWMWko5ZSDoWMLKsYhQtTi1Oyk03MtZLLcpMLi7Oz9PLSy3ZxAiMqoNbfqvu YLz8xvEQowAHoxIPr0GiWZgQa2JZcWXuIUYJDmYlEV6vG0Ah3pTEyqrUovz4otKc1OJDjNIc LErivM1MD0KFBNITS1KzU1MLUotgskwcnFINjLbPmKaKpIm55R2uil7e0GgbuHv6Vx3WpO9L w/K/mS/0S5OVn2PU2/y3ZKrdivCSmpLuDde9Up9onaptuXxl5xbto1ZvStXEDsa6/Hqlze4Y mHz2VUxAD9ui9PakH42y25d0pjQy+f86dtrGyu4z52o997yAH13c/F7HKppCEvwvTmmfFx2q xFKckWioxVxUnAgArB3sWaYCAAA= Archived-At: Cc: "draft-ietf-bfcpbis-rfc4582bis@tools.ietf.org" , "bfcpbis@ietf.org" , Alissa Cooper , Gonzalo Camarillo , Ben Campbell Subject: [bfcpbis] Status update on draft-ietf-mmusic-dtls-sdp [was: draft-ietf-bfcpbis-rfc4583bis] X-BeenThere: bfcpbis@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: BFCPBIS working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 02 Nov 2015 07:05:50 -0000 SGksDQoNCmRyYWZ0LWlldGYtbW11c2ljLWR0bHMtc2RwIHdhcyBkaXNjdXNzZWQgYXQgTU1VU0lD IHRvZGF5Lg0KDQpBdCB0aGlzIG1vbWVudCB0aGVyZSBhcmUgbm8gdGVjaG5pY2FsIG9wZW4gaXNz dWVzLiBUaGUgcGxhbiBpcyB0byBhZGQgc29tZSBlZGl0b3JpYWwgd29yaywgYmFzZWQgb24gY29t bWVudHMgcmVjZWl2ZWQgZHVyaW5nIHRoZSBzZXNzaW9uLCBhbmQgdGhlIGFkZCB0ZXh0IHJlZ2Fy ZGluZyBEVExTLXVzYWdlIGRyYWZ0cy9zcGVjcyB0aGF0IHRoZSBkcmFmdCB1cGRhdGVzLiBBZnRl ciB0aGF0LCB1bmxlc3Mgc29tZXRoaW5nIHVuZXhwZWN0ZWQgY29tZXMgdXAsIHRoZSBkcmFmdCBz aG91bGQgYmUgcmVhZHkgZm9yIFdHTEMuDQoNClJlZ2FyZHMsDQoNCkNocmlzdGVyIA0KDQoNCg0K LS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCkZyb206IENoYXJsZXMgRWNrZWwgKGVja2VsY3Up IFttYWlsdG86ZWNrZWxjdUBjaXNjby5jb21dIA0KU2VudDogMjggU2VwdGVtYmVyIDIwMTUgMTg6 NTANClRvOiBDaHJpc3RlciBIb2xtYmVyZyA8Y2hyaXN0ZXIuaG9sbWJlcmdAZXJpY3Nzb24uY29t PjsgVG9tIEtyaXN0ZW5zZW4gKHRvbWtyaXN0KSA8dG9ta3Jpc3RAY2lzY28uY29tPg0KQ2M6IEFs aXNzYSBDb29wZXIgPGFsaXNzYUBjb29wZXJ3LmluPjsgYmZjcGJpc0BpZXRmLm9yZzsgZHJhZnQt aWV0Zi1iZmNwYmlzLXJmYzQ1ODJiaXNAdG9vbHMuaWV0Zi5vcmc7IEdvbnphbG8gQ2FtYXJpbGxv IDxnb256YWxvLmNhbWFyaWxsb0Blcmljc3Nvbi5jb20+OyBCZW4gQ2FtcGJlbGwgPGJlbkBub3N0 cnVtLmNvbT4NClN1YmplY3Q6IFJlOiBbYmZjcGJpc10gZHJhZnQtaWV0Zi1iZmNwYmlzLXJmYzQ1 ODNiaXMNCg0KVGhhbmtzIENocmlzdGVyLg0KDQpUb20sIGNhbiB5b3UgcGxlYXNlIHBvc3QgdGhl IGNvcnJlc3BvbmRpbmcgdXBkYXRlIHRvIHRoZSBkcmFmdD8NCg0KQ2hlZXJzLA0KQ2hhcmxlcw0K DQpPbiA5LzI4LzE1LCAzOjA3IEFNLCAiYmZjcGJpcyBvbiBiZWhhbGYgb2YgQ2hyaXN0ZXIgSG9s bWJlcmciDQo8YmZjcGJpcy1ib3VuY2VzQGlldGYub3JnIG9uIGJlaGFsZiBvZiBjaHJpc3Rlci5o b2xtYmVyZ0Blcmljc3Nvbi5jb20+DQp3cm90ZToNCg0KPkhpLA0KPg0KPj5JbiB0aGF0IGNhc2Us IEkgcHJlZmVyIFRvbeKAmXMgb3JpZ2luYWwgc3VnZ2VzdGlvbiwNCj4+DQo+PiAgV2hhdCBpZiB3 ZSBrZWVwIHRoZSB0ZXh0IGFuZCBhZGRzIHRoaXMgYXMgYW4gYWRkaXRpb25hbCByZWZlcmVuY2Ug IA0KPj4gaW4gdGhlIHR3byBuZXcgdGV4dCBwYXNzYWdlcyBwcm9wb3NlZCBieSBDaGFybGVzOiAi Li4uIFsxM10sIGFuZCAgdGhlIA0KPj4gY2xhcmlmaWNhdGlvbnMgZGVmaW5lZCBpbiBbZHJhZnQt aWV0Zi1tbXVzaWMtZHRscy1zZHBdLCAuLi4iLg0KPj4NCj4+ICBXaGVyZSBbMTNdIGlzIGEgcmVm ZXJlbmNlIHRvIFJGQyA1NzYzLg0KPg0KPklmIHRoYXQncyBzb21ldGhpbmcgcGVvcGxlIGNhbiBh Z3JlZSB0bywgdGhlbiBjYW4gbGl2ZSB3aXRoIHN1Y2ggDQo+Y29tcHJvbWlzZSA6KQ0KPg0KPlJl Z2FyZHMsDQo+DQo+Q2hyaXN0ZXINCj4NCj4NCj4NCj4NCj4NCj5JZiBpdCB0dXJucyBvdXQgdGhh dCBkcmFmdC1pZXRmLW1tdXNpYy1kdGxzLXNkcCB1cGRhdGVzIFJGQyA1NzYzLCB0aGVuIA0KPnRo ZXJlIGlzIHNvbWUgcmVkdW5kYW5jeS4gQnV0IHRoYXQgaXMgYmV0dGVyIHRoYW4gaGF2aW5nIGEg aG9sZSB3aGVuIGl0IA0KPmNvbWVzIHRvIGJhY2t3YXJkIGNvbXBhdGliaWxpdHkgd2l0aCBleGlz dGluZyBpbXBsZW1lbnRhdGlvbnMsIHdoaWNoIGlzIA0KPndoYXQgd2Ugd2lsbCBoYXZlIHRvZGF5 IGlmIHdlIHJlZmVyZW5jZSBkcmFmdC1pZXRmLW1tdXNpYy1kdGxzLXNkcCBvbmx5Lg0KPg0KPkNo ZWVycywNCj5DaGFybGVzDQo+DQo+IA0KPg0KPk9uIDkvMjUvMTUsIDI6MjEgQU0sICJDaHJpc3Rl ciBIb2xtYmVyZyIgDQo+PGNocmlzdGVyLmhvbG1iZXJnQGVyaWNzc29uLmNvbT4NCj53cm90ZToN Cj4NCj4+SGkgQ2hhcmxlcywNCj4+DQo+Pj5BcyBhIHNpbXBsZSBleGFtcGxlLCB3ZSBjdXJyZW50 bHkgcmVmZXIgdG8gcmZjNDU4MmJpcyBpbnN0ZWFkIG9mIHRoZSANCj4+PmV2ZW50dWFsIFJGQy4g QXNzdW1pbmcgcmZjNDU4MmJpcyBkb2VzIGJlY29tZSBhbiBSRkMsIHdlIHdvdWxkIHdhbnQgDQo+ Pj50aGUgUkZDIGVkaXRvciB0byB1cGRhdGUgcmVmZXJlbmNlcyB0byBpdCBhbmQgdG8gUkZDeHh4 eCB3aXRoIHRoZSANCj4+PmFjdHVhbCBSRkMgbnVtYmVyLg0KPj4+U2ltaWxhciBoZXJlLCB3ZSB3 b3VsZCB3YW50IHRoZW0gdG8gY2hlY2sgd2l0aCBhdXRob3JzL2NoYWlycy9BRHMgb24gDQo+Pj50 aGUgc3RhdGUgb2YgZHJhZnQtaWV0Zi1tbXVzaWMtZHRscy1zZHAgdG8gc2VlIGlmIHdlIHdhbnQg dG8gcmVwbGFjZSANCj4+Pm91ciByZWZlcmVuY2UgdG8gUkZDIDU3NjMgd2l0aCBhIHJlZmVyZW5j ZSB0byBpdC4gVGhpcyB3YXkgd2UgY2FuIA0KPj4+bW92ZSBmb3J3YXJkIHdoaWxlIGRyYWZ0LWll dGYtbW11c2ljLWR0bHMtc2RwIGNvbnRpbnVlcyB0byBwcm9ncmVzcyANCj4+PmFzIHdlbGwuDQo+ Pg0KPj5JIGRvbid0IHRoaW5rIGl0J3MgdGhlIHNhbWUgdGhpbmcuIEZpcnN0IHlvdSB0YWxrIGFi b3V0IGEgZHJhZnQsIHdoZXJlIA0KPj50aGUgZHJhZnQgbmFtZSB3aWxsIGJlIHJlcGxhY2VkIHdp dGggdGhlIHRvLWJlLWFzc2lnbmVkIFJGQyBudW1iZXIuIEluIA0KPj50aGUgY2FzZSBvZiBEVExT LVNEUCB3ZSBhcmUgdGFsa2luZyBhYm91dCB0d28gc2VwYXJhdGUgc3BlY2lmaWNhdGlvbnMuDQo+ Pg0KPj5SZWdhcmRzLA0KPj4NCj4+Q2hyaXN0ZXINCj4+DQo+Pg0KPj5PbiA5LzI0LzE1LCAyOjUz IEFNLCAiQ2hyaXN0ZXIgSG9sbWJlcmciDQo+PjxjaHJpc3Rlci5ob2xtYmVyZ0Blcmljc3Nvbi5j b20+DQo+Pndyb3RlOg0KPj4NCj4+PkhpIENoYXJsZXMsDQo+Pj4NCj4+PkkgYW0gc3RpbGwgbm90 IHN1cmUgSSB1bmRlcnN0YW5kIHlvdXIgc3VnZ2VzdGlvbjogd2hhdCBpcyBtZWFudCBieSANCj4+ PiJhcyBkZXRlcm1pbmVkIHByaW9yIHRvIHB1YmxpY2F0aW9uIj8gV2hlbi93aGVyZS93aG8/IDop DQo+Pj4NCj4+PlJlZ2FyZHMsDQo+Pj4NCj4+PkNocmlzdGVyDQo+Pj4NCj4+Pi0tLS0tT3JpZ2lu YWwgTWVzc2FnZS0tLS0tDQo+Pj5Gcm9tOiBDaGFybGVzIEVja2VsIChlY2tlbGN1KSBbbWFpbHRv OmVja2VsY3VAY2lzY28uY29tXQ0KPj4+U2VudDogMjIuIHN5eXNrdXV0YSAyMDE1IDE3OjA1DQo+ Pj5UbzogQ2hyaXN0ZXIgSG9sbWJlcmc7IFRvbSBLcmlzdGVuc2VuICh0b21rcmlzdCkNCj4+PkNj OiBkcmFmdC1pZXRmLWJmY3BiaXMtcmZjNDU4MmJpc0B0b29scy5pZXRmLm9yZzsgYmZjcGJpc0Bp ZXRmLm9yZzsgDQo+Pj5BbGlzc2EgQ29vcGVyOyBHb256YWxvIENhbWFyaWxsbzsgQmVuIENhbXBi ZWxsDQo+Pj5TdWJqZWN0OiBSZTogW2JmY3BiaXNdIGRyYWZ0LWlldGYtYmZjcGJpcy1yZmM0NTgz YmlzDQo+Pj4NCj4+PkkgdmlldyByZWZlcnJpbmcgdG8gZHJhZnQtaWV0Zi1tbXVzaWMtZHRscy1z ZHAgbm93IGluc3RlYWQgb2YgUkZDIA0KPj4+NTc2MyB0byBiZSBsaWtlIHdyaXRpbmcgYSBibGFu ayBjaGVjay4gRGViYXRlIGlzIGFjdGl2ZWx5IG9jY3VycmluZyANCj4+Pm9uIHRoZSBsaXN0LCB0 aGUgbm9ybWF0aXZlIGxhbmd1YWdlIGluIFJGQyA1NzYzIGlzIGV4cGVjdGVkIHRvIGJlIA0KPj4+ dXBkYXRlZCBpbiBtdWx0aXBsZSB3YXlzLCBhbmQgYmFja3dhcmQgY29tcGF0aWJpbGl0eSB3aXRo IHRoZSB0aGUgDQo+Pj5ub3JtYXRpdmUgbGFuZ3VhZ2UgcHJvdmlkZSBpbiBwcmV2aW91cyB2ZXJz aW9uIG9mIHJmYzQ1ODNiaXMgaXMgbm90IA0KPj4+ZnVsbHkgYWRkcmVzc2VkLiBJdCBzZWVtcyBt b3JlIGFwcHJvcHJpYXRlIHRvIG1lIGF0IHRoaXMgc3RhZ2UgdG8gDQo+Pj5jb250aW51ZSB0byBy ZWZlciB0byBSRkMgNTc2MyB3aXRoIGEgbm90ZSByZWdhcmRpbmcgdXBkYXRpbmcgb3IgDQo+Pj5y ZXBsYWNpbmcgdGhhdCByZWZlcmVuY2Ugd2l0aCBvbmUgdG8gZHJhZnQtaWV0Zi1tbXVzaWMtZHRs cy1zZHAsIGFzIA0KPj4+ZGV0ZXJtaW5lZCBwcmlvciB0byBwdWJsaWNhdGlvbi4NCj4+Pg0KPj4+ Q2hlZXJzLA0KPj4+Q2hhcmxlcw0KPj4+DQo+Pj5PbiA5LzIxLzE1LCAxMTo0OCBQTSwgIkNocmlz dGVyIEhvbG1iZXJnIg0KPj4+PGNocmlzdGVyLmhvbG1iZXJnQGVyaWNzc29uLmNvbT4NCj4+Pndy b3RlOg0KPj4+DQo+Pj4+SGksDQo+Pj4+DQo+Pj4+Pkkgc2VlLiBBcyB0aGlzIGlzIGEgbW92aW5n IHRhcmdldCwgcGVyaGFwcyB3aGVyZSB3ZSByZWZlcmVuY2UgUkZDDQo+Pj4+PjU3NjMgd2UgY2Fu IGFkZCBhIG5vdGUgZm9yIHRoZSBSRkMgZWRpdG9yIHRoYXQgDQo+Pj4+PmRyYWZ0LWlldGYtbW11 c2ljLWR0bHMtc2RwIGlzIGV4cGVjdGVkIHRvIGFkZCBjbGFyaWZpY2F0aW9ucyBhbmQgDQo+Pj4+ Pm1ha2UgY2hhbmdlcyB0byBSRkMgNTc2MyB0aGF0IHNob3VsZCBiZSBjb25zaWRlcmVkIHByaW9y IHRvIA0KPj4+Pj5wdWJsaWNhdGlvbiBvZiByZmM0NTgzYmlzLg0KPj4+Pg0KPj4+PkkgYW0gbm90 IHN1cmUgSSB1bmRlcnN0YW5kLiBJIGRvbid0IHRoaW5rIGl0J3MgdXAgdG8gdGhlIFJGQyBlZGl0 b3IgDQo+Pj4+dG8gbWFrZSBhIGRlY2lzaW9uIHdoZXRoZXIgdGhlIGRyYWZ0IHNob3VsZCByZWZl cmVuY2UgRFRMUy1TRFAuDQo+Pj4+DQo+Pj4+UmVnYXJkcywNCj4+Pj4NCj4+Pj5DaHJpc3Rlcg0K Pj4+Pg0KPj4+Pg0KPj4+Pg0KPj4+Pk9uIDkvMjEvMTUsIDExOjIzIEFNLCAiQ2hyaXN0ZXIgSG9s bWJlcmciDQo+Pj4+PGNocmlzdGVyLmhvbG1iZXJnQGVyaWNzc29uLmNvbT4NCj4+Pj53cm90ZToN Cj4+Pj4NCj4+Pj4+SGksDQo+Pj4+Pg0KPj4+Pj4+UkZDIDU3NjMsIHdoaWNoIGlzIGN1cnJlbnRs eSByZXF1aXJlZCBmb3IgQkZDUCB3aXRoIERUTFMgcmVhZHM6DQo+Pj4+Pj4NCj4+Pj4+PiAgIG8g IFRoZSBlbmRwb2ludCBNVVNUIE5PVCB1c2UgdGhlIGNvbm5lY3Rpb24gYXR0cmlidXRlIGRlZmlu ZWQgaW4NCj4+Pj4+PiAgICAgW1JGQzQxNDUgPGh0dHBzOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9y ZmM0MTQ1Pl0uDQo+Pj4+Pg0KPj4+Pj5Db3JyZWN0Lg0KPj4+Pj4NCj4+Pj4+QW5kLCBJRiB3ZSBk ZWNpZGUgdG8gdXNlIGRlZmluZSB1c2FnZSBvZiB0aGUgJ2Nvbm5lY3Rpb24nIGF0dHJpYnV0ZSAN Cj4+Pj4+Zm9yIERUTFMsIHdlIHdvdWxkIGNoYW5nZSB0aGF0Lg0KPj4+Pj4NCj4+Pj4+SG93ZXZl ciwgYSBmZXcgZGF5cyBhZ28gd2Ugc2VudCBhbiBlLW1haWwgdG8gdGhlIE1NVVNJQyBsaXN0LCAN Cj4+Pj4+c3VnZ2VzdGluZyB0aGF0IHdlIHNob3VsZCBOT1QgdXNlIHRoZSAnY29ubmVjdGlvbicg YXR0cmlidXRlIGZvciBEVExTLg0KPj4+Pj5JbnN0ZWFkIHdlIHNob3VsZCBkZWZpbmUgYSBuZXcg YXR0cmlidXRlIChmb3IgbW9yZSBkZXRhaWxzLCBwbGVhc2UgDQo+Pj4+PnNlZSB0aGUgTU1VU0lD IGxpc3QpLg0KPj4+Pj4NCj4+Pj4+PlNlY3Rpb24gNS4xIG9mIGRyYWZ0LWlldGYtbW11c2ljLWR0 bHMtc2RwIHJlYWRzOg0KPj4+Pj4+DQo+Pj4+Pj4gICBXaGVuIHVzZWQgd2l0aCBEVExTLCB0aGVy ZSBpcyBubyBkZWZhdWx0IHZhbHVlIGRlZmluZWQgZm9yIHRoZQ0KPj4+Pj4+ICAgYXR0cmlidXRl LiAgSW1wbGVtZW50YXRpb25zIHRoYXQgd2lzaCB0byB1c2UgdGhlIGF0dHJpYnV0ZSBNVVNUDQo+ Pj4+Pj4gICBleHBsaWNpdGx5IGluY2x1ZGUgaXQgaW4gU0RQIG9mZmVycyBhbmQgYW5zd2Vycy4g IElmIGFuIG9mZmVyIG9yDQo+Pj4+Pj4gICBhbnN3ZXIgZG9lcyBub3QgY29udGFpbiBhbiBhdHRy aWJ1dGUsIG90aGVyIG1lYW5zIG5lZWRzIHRvIGJlIA0KPj4+Pj4+dXNlZCBpbg0KPj4+Pj4+ICAg b3JkZXIgZm9yIGVuZHBvaW50cyB0byBkZXRlcm1pbmUgd2hldGhlciBhbiBvZmZlciBvciBhbnN3 ZXIgaXMNCj4+Pj4+PiAgIGFzc29jaWF0ZWQgd2l0aCBhbiBldmVudCB0aGF0IHJlcXVpcmVzIHRo ZSBEVExTIGFzc29jaWF0aW9uIHRvIA0KPj4+Pj4+YmUNCj4+Pj4+PnJlLQ0KPj4+Pj4+ICAgZXN0 YWJsaXNoZWQuDQo+Pj4+Pj4NCj4+Pj4+PiBJIHN1cHBvc2UgaWYgZHJhZnQtaWV0Zi1tbXVzaWMt ZHRscy1zZHAgcHVsbHMgaW4gZW5vdWdoIGZyb20gUkZDDQo+Pj4+Pj41NzYzIHRvIG1ha2UgaXQg Y2xlYXIgaG93IHRoZSBEVExTIGVzdGFibGlzaG1lbnQgYW5kIA0KPj4+Pj4+cmUtZXN0YWJsaXNo bWVudCB3b3JrcyBmb3IgdGhlIGNhc2Ugb2Ygd2hpY2ggdGhlIGNvbm5lY3Rpb24gDQo+Pj4+Pj5h dHRyaWJ1dGUgaXMgbm90IHVzZWQsIHRoZW4gd2UgY2FuIGNoYW5nZSB0aGUgcmVmZXJlbmNlIGZy b20gUkZDDQo+Pj4+Pj41NzYzIHRvIGRyYWZ0LWlldGYtbW11c2ljLWR0bHMtc2RwLg0KPj4+Pj4+ DQo+Pj4+Pj4gVGhlIGxhc3Qgc2V2ZXJhbCB1cGRhdGVzIG9mIGRyYWZ0LWlldGYtYmZjcGJpcy1y ZmM0NTgzYmlzIGhhdmUgDQo+Pj4+Pj5yZW1vdmVkIHN1cHBvcnRpbmcgdGV4dCBmcm9tIHRoZSBk cmFmdCBpbiBmYXZvciBvZiBwb2ludGluZyB0byBSRkMNCj4+Pj4+PjU3NjMgYXMgdGhlICBzb3Vy Y2Ugb2YgdHJ1dGguIEkgZmVhciB0aGF0IA0KPj4+Pj4+ZHJhZnQtaWV0Zi1tbXVzaWMtZHRscy1z ZHAgaW4gaXRzIGN1cnJlbnQgc3RhdGUgZG9lcyBub3Qgc2VydmUgDQo+Pj4+Pj50aGF0IG5lZWQg Zm9yIGRyYWZ0LWlldGYtYmZjcGJpcy1yZmM0NTgzYmlzLiBJIHZhbHVlICBDaHJpc3RlcuKAmXMg DQo+Pj4+Pj50aG91Z2h0cyBhbmQgd2VsY29tZSB0aGUgb3BpbmlvbiBvZiBvdGhlcnMsIGVzcGVj aWFsbHkgdGhvc2Ugd2hvIA0KPj4+Pj4+aGF2ZSBvciBhcmUgaW1wbGVtZW50aW5nIEJGQ1Agd2l0 aCBEVExTIGFuZCBJQ0UsIHdoaWNoIEkgaGF2ZSBub3QuDQo+Pj4+Pg0KPj4+Pj5QbGVhc2Ugbm90 ZSB0aGF0IERUTFMtU0RQIGRvZXMgbm90IG9ubHkgZGVmaW5lIHVzYWdlIG9mIHRoZSANCj4+Pj4+ J2Nvbm5lY3Rpb24nDQo+Pj4+PmF0dHJpYnV0ZSwgaXQgYWxzbyBkb2VzIG90aGVyIHRoaW5ncy4g TWF5YmUgbW9yZSBpbXBvcnRhbnQsIGl0IGRvZXMgDQo+Pj4+Pm5vdCBzdGF0ZSB0aGF0IGFuIGFk ZHJlc3MgY2hhbmdlIGJ5IGRlZmF1bHQgcmVxdWlyZXMgYSBuZXcgRFRMUyANCj4+Pj4+YXNzb2Np YXRpb24NCj4+Pj4+LSB3aGljaCBpcyBhIGFub3RoZXIgNTc2MyBtb2RpZmljYXRpb24uDQo+Pj4+ Pg0KPj4+Pj5SZWdhcmRzLA0KPj4+Pj4NCj4+Pj4+Q2hyaXN0ZXINCj4+Pj4+DQo+Pj4+Pg0KPj4+ Pj4NCj4+Pj4+DQo+Pj4+Pk9uIDkvMjEvMTUsIDk6MzIgQU0sICJiZmNwYmlzIG9uIGJlaGFsZiBv ZiBDaHJpc3RlciBIb2xtYmVyZyINCj4+Pj4+PGJmY3BiaXMtYm91bmNlc0BpZXRmLm9yZyBvbiBi ZWhhbGYgb2YgDQo+Pj4+PmNocmlzdGVyLmhvbG1iZXJnQGVyaWNzc29uLmNvbT4NCj4+Pj4+d3Jv dGU6DQo+Pj4+Pg0KPj4+Pj4+SGkgQ2hhcmxlcywNCj4+Pj4+Pg0KPj4+Pj4+PlRoZSBwcm9ibGVt IEkgc2VlIHdpdGggdGhpcyBpcyB0aGF0IGl0IGlzIG5vdCBqdXN0IGEgbWF0dGVyIG9mIA0KPj4+ Pj4+PmNoYW5naW5nIHRoZSByZWZlcmVuY2UsIGl0IGlzIGFsc28gYSBtYXR0ZXIgb2YgY2hhbmdp bmcgdGhlIA0KPj4+Pj4+Pm5vcm1hdGl2ZSBiZWhhdmlvci4NCj4+Pj4+Pj5Gb3IgRFRMUyB3aXRo IEJGQ1AsIHdlIG5ldmVyIHJlcXVpcmVkIHRoZSB1c2Ugb2YgdGhlID7igJxjb25uZWN0aW9u4oCd DQo+Pj4+Pj4+YXR0cmlidXRlLg0KPj4+Pj4+PklmIHdlIGFyZSB0byBzdGFydCByZXF1aXJpbmcg aXQsIHdlIHdvdWxkIG5lZWQgYWRkIHRleHQgdG8gDQo+Pj4+Pj4+ZGVzY3JpYmUgaG93IHRvIGFk ZHJlc3MgYmFja3dhcmQgY29tcGF0aWJpbGl0eSBpbiBjYXNlcyBpbiB3aGljaCANCj4+Pj4+Pj50 aGUgY29ubmVjdGlvbiBhdHRyaWJ1dGUgaXMgbm90IHNwZWNpZmllZC4NCj4+Pj4+Pg0KPj4+Pj4+ VGhlIGludGVudGlvbiBpcyB0byBjb3ZlciBiYWNrd2FyZCBjb21wYXRpYmlsaXR5IGluIHRoZSBk cmFmdC4NCj4+Pj4+Pg0KPj4+Pj4+PkFyZSB0aGVyZSBwbGFucyBmb3IgdGhpcyB3aXRoaW4gUkZD IDU3NjNiaXMgZHJhZnQ/IElmIHNvLCBUb23igJlzIA0KPj4+Pj4+PnJlY29tbWVuZGF0aW9uIG9m IGNvbnRpbnVpbmcgdG8gcG9pbnQgdG8gUkZDIDU3NjMgZm9yIG5vdyBtYXkgYmUgDQo+Pj4+Pj4+ dGhlIGJlc3QgYXBwcm9hY2guDQo+Pj4+Pj4NCj4+Pj4+PkkgYW0gbm90IGZhbWlsaWFyIHdpdGgg dGhlIDU3NjNiaXMgZHJhZnQuIEJ1dCwgZXZlbiBpZiB0aGUgDQo+Pj4+Pj5EVExTLVNEUCBkcmFm dCBtYWtlcyB1cGRhdGVzIHRvIDU3NjMsIGl0IHdvbid0IGJlY29tZSBhIDU3NjNiaXMgZHJhZnQu DQo+Pj4+Pj4NCj4+Pj4+PlJlZ2FyZHMsDQo+Pj4+Pj4NCj4+Pj4+PkNocmlzdGVyDQo+Pj4+Pj4g DQo+Pj4+Pj4NCj4+Pj4+Pg0KPj4+Pj4+T24gOS8xMS8xNSwgMToxMSBQTSwgIkNocmlzdGVyIEhv bG1iZXJnIg0KPj4+Pj4+PGNocmlzdGVyLmhvbG1iZXJnQGVyaWNzc29uLmNvbT4NCj4+Pj4+Pndy b3RlOg0KPj4+Pj4+DQo+Pj4+Pj4+SGksDQo+Pj4+Pj4+DQo+Pj4+Pj4+PkhtbSwgeWVzIG1heWJl IGFuIGlkZWEgaWYgaXQncyBmaW5lIHByb2NlZWRpbmcgd2l0aCByZWZlcnJpbmcgYSANCj4+Pj4+ Pj4+d29yay1pbi1wcm9ncmVzcyBkcmFmdCBoZXJlLg0KPj4+Pj4+Pj5XaGF0IGlmIHdlIGtlZXAg dGhlIHRleHQgYW5kIGFkZHMgdGhpcyBhcyBhbiBhZGRpdGlvbmFsIA0KPj4+Pj4+Pj5yZWZlcmVu Y2UgaW4gdGhlIHR3byBuZXcgdGV4dCBwYXNzYWdlcyBwcm9wb3NlZCBieSBDaGFybGVzOiAiLi4u IA0KPj4+Pj4+Pj5bMTNdLCBhbmQgdGhlIGNsYXJpZmljYXRpb25zIGRlZmluZWQgaW4gW2RyYWZ0 LWlldGYtbW11c2ljLWR0bHMtc2RwXSwgLi4uIi4NCj4+Pj4+Pj4+DQo+Pj4+Pj4+PldoZXJlIFsx M10gaXMgYSByZWZlcmVuY2UgdG8gUkZDIDU3NjMuDQo+Pj4+Pj4+DQo+Pj4+Pj4+TXkgc3VnZ2Vz dGlvbiBpcyB0byAqb25seSogcmVmZXIgdGhlIG5ldyBkdGxzLXNkcCBkcmFmdC4gQmVjYXVzZSwg DQo+Pj4+Pj4+b25lIG9mIHRoZSBpZGVhcyB3aXRoIHRoZSBuZXcgZHJhZnQgaXMgdG8gYWxzbyB1 cGRhdGUgUkZDIDU3NjMgdG8gDQo+Pj4+Pj4+cmVmZXJlbmNlIHRoZSBuZXcgZHRscy1zZHAgZHJh ZnQuDQo+Pj4+Pj4+DQo+Pj4+Pj4+PkFueXdheSwgSSdkIHN0aWxsIHByZWZlciB0byBrZWVwIHRo ZSB0ZXh0IGluDQo+Pj4+Pj4+PmRyYWZ0LWlldGYtYmZjcGJpcy1yZmM0NTgzYmlzLTEyIGFuZCBy ZWRpcmVjdCB0aGUgcmVhZGVycyB0byB0aGUgDQo+Pj4+Pj4+PnJmYzU3NjNiaXMsIHRoYXQgZXZl bnR1YWxseSB0aGVuIHdpbGwgb2Jzb2xldGUgKG9yIGV4dGVuZD8pIFJGQyANCj4+Pj4+Pj4+NTc2 My4NCj4+Pj4+Pj4NCj4+Pj4+Pj5UaGUgbmV3IGR0bHMtc2RwIGRyYWZ0IHdpbGwgbm90IGJlY29t ZSA1NzYzYmlzIChldmVudGhvdWdoIGl0IE1BWSANCj4+Pj4+Pj51cGRhdGUgc29tZSBwYXJ0cyBv ZiA1NzYzKS4gSXQncyBhIGdlbmVyaWMgZG9jdW1lbnQsIHdoaWNoICphbnkqIA0KPj4+Pj4+PkRU TFMgdXNhZ2UgY2FuIHRoZW4gcmVmZXJlbmNlLg0KPj4+Pj4+Pg0KPj4+Pj4+PlJlZ2FyZHMsDQo+ Pj4+Pj4+DQo+Pj4+Pj4+Q2hyaXN0ZXINCj4+Pj4+Pj4NCj4+Pj4+Pj4NCj4+Pj4+Pj4NCj4+Pj4+ Pj5PbiAwOS8xMS8yMDE1IDAxOjI1IFBNLCBDaHJpc3RlciBIb2xtYmVyZyB3cm90ZToNCj4+Pj4+ Pj4+IEhpLA0KPj4+Pj4+Pj4NCj4+Pj4+Pj4+IE15IHN1Z2dlc3Rpb24gd291bGQgYWN0dWFsbHkg YmUgdG8gcmVmZXIgdG8gdGhlIG5ldyANCj4+Pj4+Pj4+ZHJhZnQtaWV0Zi1tbXVzaWMtZHRscy1z ZHAsIHdoaWNoIGlzIGdvaW5nIHRvIGNsYXJpZnkgdGhlIA0KPj4+Pj4+Pj5EVExTLVNSVFAgcnVs ZXMgcmVnYXJkaW5nIHdoZW4gYSBuZXcgRFRMUyBhc3NvY2lhdGlvbiBtdXN0IGJlIA0KPj4+Pj4+ Pj5lc3RhYmxpc2hlZC4NCj4+Pj4+Pj4+DQo+Pj4+Pj4+PiBSZWdhcmRzLA0KPj4+Pj4+Pj4NCj4+ Pj4+Pj4+IENocmlzdGVyDQo+Pj4+Pj4+Pg0KPj4+Pj4+Pj4gLS0tLS1PcmlnaW5hbCBNZXNzYWdl LS0tLS0NCj4+Pj4+Pj4+IEZyb206IFRvbSBLcmlzdGVuc2VuIFttYWlsdG86dG9ta3Jpc3RAY2lz Y28uY29tXQ0KPj4+Pj4+Pj4gU2VudDogMTEuIHN5eXNrdXV0YSAyMDE1IDEzOjI1DQo+Pj4+Pj4+ PiBUbzogQ2hhcmxlcyBFY2tlbCAoZWNrZWxjdSkNCj4+Pj4+Pj4+IENjOiBDaHJpc3RlciBIb2xt YmVyZzsgQWxpc3NhIENvb3BlcjsgR29uemFsbyBDYW1hcmlsbG87IA0KPj4+Pj4+Pj4gZHJhZnQt aWV0Zi1iZmNwYmlzLXJmYzQ1ODJiaXNAdG9vbHMuaWV0Zi5vcmc7IEJlbiBDYW1wYmVsbDsgDQo+ Pj4+Pj4+PiBiZmNwYmlzQGlldGYub3JnDQo+Pj4+Pj4+PiBTdWJqZWN0OiBSZTogZHJhZnQtaWV0 Zi1iZmNwYmlzLXJmYzQ1ODNiaXMNCj4+Pj4+Pj4+DQo+Pj4+Pj4+PiBQb2ludGluZyB0byB0aGUg RFRMUy1TUlRQIChhbmQgYnkgdGhhdCBhbnkgdXBkYXRlcyBvZiBpdCkgaXMgYSANCj4+Pj4+Pj4+ c2ltcGxlLCBzYWZlIGFuZCBzdHJhaWd0LWZvcndhcmQgc29sdXRpb24uDQo+Pj4+Pj4+Pg0KPj4+ Pj4+Pj4gVGhlIG9ubHkgY2hhbmdlIGluIHRoZSBuZXcgdmVyc2lvbiBvZiByZmM0NTgzYmlzIGp1 c3Qgc3VibWl0dGVkLg0KPj4+Pj4+Pj5BbmQgYXMgQ2hhcmxlcyBzYXlzLCB0aGlzIHNob3VsZCBi ZSB0aGUgbGFzdCBtaXNzaW5nIGZpeCBmb3IgDQo+Pj4+Pj4+PnRoaXMgZHJhZnQgdW50aWwgbmV4 dCBzdGFnZXMgaW4gdGhlIHByb2Nlc3MgYXQgbGVhc3QuDQo+Pj4+Pj4+Pg0KPj4+Pj4+Pj4gLS0g VG9tDQo+Pj4+Pj4+Pg0KPj4+Pj4+Pj4gT24gMDkvMDgvMjAxNSAwNzo0OCBQTSwgQ2hhcmxlcyBF Y2tlbCAoZWNrZWxjdSkgd3JvdGU6DQo+Pj4+Pj4+PiAgICANCj4+Pj4+Pj4+PiBQaWNraW5nIHVw IG9uIHRoaXMgb2xkIHRocmVhZCByZWdhcmRpbmcgDQo+Pj4+Pj4+Pj5kcmFmdC1pZXRmLWJmY3Bi aXMtcmZjNDU4M2Jpcy4NCj4+Pj4+Pj4+PiBJIHRoaW5rIHRoaXMgaXMgdGhlIG9ubHkgb3V0c3Rh bmRpbmcgaXRlbSB3aXRoIHJlc3BlY3QgdG8gdGhlIA0KPj4+Pj4+Pj4+Y3VycmVudCAgdmVyc2lv biBvZiB0aGUgZHJhZnQuIFVubGVzcyBhbnlvbmUgaGFzIGFuIGlzc3VlIHdpdGggDQo+Pj4+Pj4+ Pj50aGUgcHJvcG9zZWQgIHJlc29sdXRpb24sIEkgcmVxdWVzdCB3ZSB1cGRhdGUgdGhlIGRyYWZ0 IA0KPj4+Pj4+Pj4+YWNjb3JkaW5nbHkgYW5kIHRoZW4gdXNlIGl0ICBhcyB0aGUgYmFzaXMgZm9y IE1hcnksIHRoZSANCj4+Pj4+Pj4+PmRvY3VtZW50IHNoZXBoZXJkLCB0byBwcm92aWRlIGEgcHJv dG8gd3JpdGV1cC4NCj4+Pj4+Pj4+Pg0KPj4+Pj4+Pj4+IENoZWVycywNCj4+Pj4+Pj4+PiBDaGFy bGVzDQo+Pj4+Pj4+Pj4NCj4+Pj4+Pj4+Pg0KPj4+Pj4+Pj4+IE9uIDQvMjAvMTUsIDEwOjM5IEFN LCAiQ2hhcmxlcyBFY2tlbCANCj4+Pj4+Pj4+PihlY2tlbGN1KSI8ZWNrZWxjdUBjaXNjby5jb20+ DQo+Pj4+Pj4+Pj53cm90ZToNCj4+Pj4+Pj4+Pg0KPj4+Pj4+Pj4+DQo+Pj4+Pj4+Pj4gICAgICAN Cj4+Pj4+Pj4+Pj4gSGkgQ2hyaXN0ZXIsDQo+Pj4+Pj4+Pj4+DQo+Pj4+Pj4+Pj4+IEkgcmVyZWFk IHRoZSBjdXJyZW50IGRyYWZ0IGFuZCB3ZW50IHRocm91Z2ggdGhlIGZvbGxvd2luZyANCj4+Pj4+ Pj4+Pj4gTU1VU0lDIHRocmVhZCBvbiB0aGlzIHN1YmplY3Q6DQo+Pj4+Pj4+Pj4+IGh0dHA6Ly93 d3cuaWV0Zi5vcmcvbWFpbC1hcmNoaXZlL3dlYi9tbXVzaWMvY3VycmVudC9tc2cxNDYzMS4NCj4+ Pj4+Pj4+Pj4gaA0KPj4+Pj4+Pj4+PiB0DQo+Pj4+Pj4+Pj4+IG0NCj4+Pj4+Pj4+Pj4gbA0KPj4+ Pj4+Pj4+Pg0KPj4+Pj4+Pj4+PiBBcyBhIHJlc3VsdCwgSSBiZXR0ZXIgdW5kZXJzdGFuZCB0aGUg aXNzdWUgeW91IGFyZSBhZGRyZXNzaW5nLg0KPj4+Pj4+Pj4+PiBJIHN1Z2dlc3QgdGhlIGZvbGxv d2luZyBjaGFuZ2VzIHRvIGJlIGNvbnNpc3RlbnQgd2l0aCB3aGF0IGlzIA0KPj4+Pj4+Pj4+PiBi ZWluZyBwcm9wb3NlZCBpbg0KPj4+Pj4+Pj4+PiBNTVVTSUM6DQo+Pj4+Pj4+Pj4+DQo+Pj4+Pj4+ Pj4+IC0tLS0tLS0tLS0tLQ0KPj4+Pj4+Pj4+PiBTZWN0aW9uIDk6DQo+Pj4+Pj4+Pj4+DQo+Pj4+ Pj4+Pj4+IE9MRDoNCj4+Pj4+Pj4+Pj4gRW5kcG9pbnRzIHRoYXQgdXNlIHRoZSBvZmZlci9hbnN3 ZXIgbW9kZWwgdG8gZXN0YWJsaXNoIGEgRFRMUw0KPj4+Pj4+Pj4+PiAgICAgYXNzb2NpYXRpb24g TVVTVCBzdXBwb3J0IHRoZSAnc2V0dXAnIGF0dHJpYnV0ZSwgYXMgDQo+Pj4+Pj4+Pj4+ZGVmaW5l ZCBpbiBbN10uDQo+Pj4+Pj4+Pj4+IFdoZW4gRFRMUyBpcyB1c2VkIHdpdGggVURQLCB0aGUgJ3Nl dHVwJyBhdHRyaWJ1dGUgaW5kaWNhdGVzIA0KPj4+Pj4+Pj4+PndoaWNoIG9mIHRoZSBlbmRwb2lu dHMgKGNsaWVudCBvciBmbG9vciBjb250cm9sIHNlcnZlcikgDQo+Pj4+Pj4+Pj4+aW5pdGlhdGVz IHRoZSBEVExTIGFzc29jaWF0aW9uIHNldHVwLiBUaGUgcmVxdWlyZW1lbnRzIGZvciB0aGUgDQo+ Pj4+Pj4+Pj4+b2ZmZXIvYW5zd2VyIGV4Y2hhbmdlIHNwZWNpZmllZCBpbiBbMTNdLCBTZWN0aW9u IDUgb2YgWzEzXSANCj4+Pj4+Pj4+Pj5NVVNUIGJlIGZvbGxvd2VkIHdoZW4gdXNpbmcgRFRMUy4N Cj4+Pj4+Pj4+Pj4gT2ZmZXIvYW5zd2VyIGNvbnNpZGVyYXRpb25zIGFyZSBkZXNjcmliZWQgaW4g U2VjdGlvbiAxMC41Lg0KPj4+Pj4+Pj4+Pg0KPj4+Pj4+Pj4+PiBORVc6DQo+Pj4+Pj4+Pj4+IFdo ZW4gRFRMUyBpcyB1c2VkIHdpdGggVURQLCB0aGUgcmVxdWlyZW1lbnRzIHNwZWNpZmllZCBpbiAN Cj4+Pj4+Pj4+Pj4gU2VjdGlvbg0KPj4+Pj4+Pj4+PiA1IG9mIFsxM10gTVVTVCBiZSBmb2xsb3dl ZC4NCj4+Pj4+Pj4+Pj4NCj4+Pj4+Pj4+Pj4NCj4+Pj4+Pj4+Pj4gU2VjdGlvbiAxMC41DQo+Pj4+ Pj4+Pj4+DQo+Pj4+Pj4+Pj4+IE9MRA0KPj4+Pj4+Pj4+PiAgICAgSWYgdGhlIHRyYW5zcG9ydCBw YXJhbWV0ZXJzIG9yIHRoZSBrZXkgZmluZ2VycHJpbnRzIA0KPj4+Pj4+Pj4+PmNoYW5nZSwgdGhl DQo+Pj4+Pj4+Pj4+ICAgICBlbmRwb2ludHMgTVVTVCBlc3RhYmxpc2ggYSBuZXcgRFRMUyBjb25u ZWN0aW9uLiAgSW4gc3VjaCANCj4+Pj4+Pj4+Pj5jYXNlIHRoZQ0KPj4+Pj4+Pj4+PiAgICAgJ2Fj dGl2ZS9wYXNzaXZlJyBzdGF0dXMgb2YgdGhlIGVuZHBvaW50cyB3aWxsIGFnYWluIGJlIA0KPj4+ Pj4+Pj4+PmRldGVybWluZWQNCj4+Pj4+Pj4+Pj4gICAgIGZvbGxvd2luZyB0aGUgcHJvY2VkdXJl cyBpbiBbN10sIGFuZCB0aGUgbmV3IHN0YXR1cyB3aWxsIA0KPj4+Pj4+Pj4+PmJlIHVzZWQgdG8N Cj4+Pj4+Pj4+Pj4gICAgIGRldGVybWluZSB0aGUgVExTIHJvbGVzIGFzc29jaWF0ZWQgd2l0aCB0 aGUgbmV3IERUTFMgDQo+Pj4+Pj4+Pj4+Y29ubmVjdGlvbi4NCj4+Pj4+Pj4+Pj4NCj4+Pj4+Pj4+ Pj4gICAgICAgIEluZm9ybWF0aW9uYWwgbm90ZTogVGhlIHByb2NlZHVyZSBhYm92ZSBpcyBpZGVu dGljYWwgDQo+Pj4+Pj4+Pj4+dG8gdGhlIG9uZQ0KPj4+Pj4+Pj4+PiAgICAgICAgZGVmaW5lZCBm b3IgRFRMUy1TUlRQIGluIFsxM10uDQo+Pj4+Pj4+Pj4+DQo+Pj4+Pj4+Pj4+ICAgICAgICBOb3Rl OiBBIG5ldyBEVExTIGNvbm5lY3Rpb24gbmVlZHMgdG8gYmUgZXN0YWJsaXNoZWQgaWYgDQo+Pj4+ Pj4+Pj4+dGhlDQo+Pj4+Pj4+Pj4+ICAgICAgICB0cmFuc3BvcnQgcGFyYW1ldGVycyBvciB0aGUg a2V5IGZpbmdlcnByaW50cyBjaGFuZ2UuDQo+Pj4+Pj4+Pj4+DQo+Pj4+Pj4+Pj4+DQo+Pj4+Pj4+ Pj4+DQo+Pj4+Pj4+Pj4+IE5FVzoNCj4+Pj4+Pj4+Pj4gVGhlIGNvbmRpdGlvbnMgdW5kZXIgd2hp Y2ggZW5kcG9pbnRzIE1VU1QgZXN0YWJsaXNoIGEgbmV3IA0KPj4+Pj4+Pj4+PiBEVExTIGNvbm5l Y3Rpb24gYXJlIGFzIHRoZSBzYW1lIGRlZmluZWQgZm9yIERUTFMtU1JUUCBpbiBbMTNdLg0KPj4+ Pj4+Pj4+PiDigJTigJTigJTigJTigJTigJTigJTigJQNCj4+Pj4+Pj4+Pj4NCj4+Pj4+Pj4+Pj4g VGhpcyB3YXkgd2UgYXZvaWQgYW55IHBvdGVudGlhbCBjb25mbGljdHMgd2l0aCB0aGUgaW50ZW50 IG9mIA0KPj4+Pj4+Pj4+PiBSRkMgNTc2MywgYW5kIHdoZW4gY2xhcmlmaWNhdGlvbnMgdG8gUkZD IDU3NjMgYXJlIG1hZGUsIHRoZXkgDQo+Pj4+Pj4+Pj4+IHdpbGwgYmUgcGlja2VkIHVwIGJ5IHRo ZSBCRkNQIHNwZWMuDQo+Pj4+Pj4+Pj4+DQo+Pj4+Pj4+Pj4+IENoZWVycywNCj4+Pj4+Pj4+Pj4g Q2hhcmxlcw0KPj4+Pj4+Pj4+Pg0KPj4+Pj4+Pj4+Pg0KPj4+Pj4+Pj4+Pg0KPj4+Pj4+Pj4+Pg0K Pj4+Pj4+Pj4+PiBPbiA0LzE4LzE1LCAyOjAxIFBNLCAiQ2hyaXN0ZXIgDQo+Pj4+Pj4+Pj4+IEhv bG1iZXJnIjxjaHJpc3Rlci5ob2xtYmVyZ0Blcmljc3Nvbi5jb20+DQo+Pj4+Pj4+Pj4+IHdyb3Rl Og0KPj4+Pj4+Pj4+Pg0KPj4+Pj4+Pj4+Pg0KPj4+Pj4+Pj4+PiAgICAgICAgDQo+Pj4+Pj4+Pj4+ PiBIaSBDaGFybGVzLA0KPj4+Pj4+Pj4+Pj4NCj4+Pj4+Pj4+Pj4+DQo+Pj4+Pj4+Pj4+PiAgICAg ICAgDQo+Pj4+Pj4+Pj4+Pj4gW2FkZGluZyBiZmNwcGJpcyBsaXN0XQ0KPj4+Pj4+Pj4+Pj4+DQo+ Pj4+Pj4+Pj4+Pj4gSGkgQ2hyaXN0ZXIsDQo+Pj4+Pj4+Pj4+Pj4NCj4+Pj4+Pj4+Pj4+PiBUaGFu a3MgZm9yIHlvdXIgcmV2aWV3IGFuZCBjb21tZW50cy4gSW4gdGhlIEJGQ1AgdXNhZ2UsIHRoZSAN Cj4+Pj4+Pj4+Pj4+PkRUTFMgY29ubmVjdGlvbiBpcyBkZWRpY2F0ZWQgdG8gdGhlIEJGQ1Agc3Ry ZWFtIGl0IGNvbnRhaW5zLg0KPj4+Pj4+Pj4+Pj4+QXMgSSB1bmRlcnN0YW5kIGl0LCB0aGUgY29t cGxpY2F0aW9ucyBhcm91bmQgRFRMUyANCj4+Pj4+Pj4+Pj4+PnJlLWVzdGFibGlzaGVtZW50IGRp c2N1c3NlZCBpbiBNTVVTSUMgcmVzdWx0IGZyb20gdXNlIG9mIGEgDQo+Pj4+Pj4+Pj4+Pj5zaW5n bGUgRFRMUyBjb25uZWN0aW9uIGZvciBtdWx0aXBsZSBSVFAgYW5kL29yIFNDVFAgc3RyZWFtcy4N Cj4+Pj4+Pj4+Pj4+PlRob3NlIGNvbXBsaWNhdGlvbnMgZG8gbm90IGV4aXN0IHdpdGggdGhlIEJG Q1AgdXNhZ2UsIHNvIEkgDQo+Pj4+Pj4+Pj4+Pj50aGluayBpdCBpcyBzdWZmaWNpZW50IHRvIGNv bnRpbnVlIHRvIHJlZmVyZW5jZSBSRkMgNTc2MyBhbmQgDQo+Pj4+Pj4+Pj4+Pj5ub3QgdXNlIHRo ZSBTRFAgY29ubmVjdGlvbiBhdHRyaWJ1dGUuDQo+Pj4+Pj4+Pj4+Pj4NCj4+Pj4+Pj4+Pj4+PiAg ICAgICANCj4+Pj4+Pj4+Pj4+IFRoZSBjb21wbGljYXRpb25zIGRvIG5vdCByZXN1bHQgZnJvbSB1 c2Ugb2YgYSBzaW5nbGUgRFRMUyANCj4+Pj4+Pj4+Pj4+Y29ubmVjdGlvbiBmb3IgbXVsdGlwbGUg c3RyZWFtcyAtIGl0IG1haW5seSByZXN1bHRzIGZyb20gdGhlIA0KPj4+Pj4+Pj4+Pj51c2FnZSBv ZiBJQ0UuIEFuZCwgYXMgZmFyIGFzIEkga25vdywgSUNFIGNhbiBiZSB1c2VkIGFsc28gZm9yIA0K Pj4+Pj4+Pj4+Pj5CRkNQLg0KPj4+Pj4+Pj4+Pj4NCj4+Pj4+Pj4+Pj4+IEFuZCwgZXZlbiB3aXRo b3V0IElDRSB3ZSBpbnRlbmQgdG8gYWRkIHRleHQgc2F5aW5nIHRoYXQgYSANCj4+Pj4+Pj4+Pj4+ RFRMUyBjb25uZWN0aW9uIGlzIG9ubHkgcmUtZXN0YWJsaXNoZWQgaWYgdGhlIHVuZGVybHlpbmcg DQo+Pj4+Pj4+Pj4+PnRyYW5zcG9ydCBjaGFuZ2VzLg0KPj4+Pj4+Pj4+Pj4NCj4+Pj4+Pj4+Pj4+ IFJlZ2FyZHMsDQo+Pj4+Pj4+Pj4+Pg0KPj4+Pj4+Pj4+Pj4gQ2hyaXN0ZXINCj4+Pj4+Pj4+Pj4+ DQo+Pj4+Pj4+Pj4+Pg0KPj4+Pj4+Pj4+Pj4NCj4+Pj4+Pj4+Pj4+DQo+Pj4+Pj4+Pj4+PiAgICAg ICAgDQo+Pj4+Pj4+Pj4+Pj4gSGksDQo+Pj4+Pj4+Pj4+Pj4NCj4+Pj4+Pj4+Pj4+PiBGaXJzdCwg SSB3YW50IHRvIGFwb2xvZ2l6ZSBmb3Igbm90IHByb3ZpZGluZyBteSByZXZpZXcgDQo+Pj4+Pj4+ Pj4+Pj5lYXJsaWVyLg0KPj4+Pj4+Pj4+Pj4+DQo+Pj4+Pj4+Pj4+Pj4gQXMgZmFyIGFzIHRoZSBC RkNQIHNwZWNpZmljcyBhcmUgY29uY2VybmVkLCBJIGFtIG9rIHdpdGggDQo+Pj4+Pj4+Pj4+Pj4g dGhlIGxhdGVzdCB2ZXJzaW9uIG9mIHRoZSBkcmFmdC4NCj4+Pj4+Pj4+Pj4+Pg0KPj4+Pj4+Pj4+ Pj4+IEhvd2V2ZXIsIHRoZXJlIGlzIGFuIGlzc3VlIHJlZ2FyZGluZyB0aGUgRFRMUyANCj4+Pj4+ Pj4+Pj4+PiBjb25zaWRlcmF0aW9ucyAoc2VjdGlvbiAxMC41KS4NCj4+Pj4+Pj4+Pj4+Pg0KPj4+ Pj4+Pj4+Pj4+IFRoZSB0ZXh0IHNheXM6DQo+Pj4+Pj4+Pj4+Pj4NCj4+Pj4+Pj4+Pj4+PiAJIk9u Y2UgYSBEVExTIGNvbm5lY3Rpb24gaGFzIGJlZW4gZXN0YWJsaXNoZWQsIGlmIHRoZSANCj4+Pj4+ Pj4+Pj4+PidhY3RpdmUvcGFzc2l2ZScNCj4+Pj4+Pj4+Pj4+PiAgICAgCXN0YXR1cyBvZiB0aGUg ZW5kcG9pbnRzIGNoYW5nZSBkdXJpbmcgYSBzZXNzaW9uLCBhIG5ldyANCj4+Pj4+Pj4+Pj4+PkRU TFMNCj4+Pj4+Pj4+Pj4+PiAgICAgCWNvbm5lY3Rpb24gTVVTVCBiZSBlc3RhYmxpc2hlZC4iDQo+ Pj4+Pj4+Pj4+Pj4NCj4+Pj4+Pj4+Pj4+PiBUaGVyZSBpcyBjdXJyZW50bHkgYW4gb25nb2luZyBk aXNjdXNzaW9uIGluIE1NVVNJQyBhYm91dCANCj4+Pj4+Pj4+Pj4+PiB3aGVuIGEgRFRMUyBjb25u ZWN0aW9uIGlzIHRvIGJlIHJlLWVzdGFibGlzaGVkLg0KPj4+Pj4+Pj4+Pj4+DQo+Pj4+Pj4+Pj4+ Pj4gVGhlIGRpc2N1c3Npb24gaXMgc3RpbGwgb25nb2luZywgYnV0IHRoZSBvdXRjb21lIHdpbGwg bW9zdCANCj4+Pj4+Pj4+Pj4+PiBsaWtlbHkgTk9UIGJlIGFsaWduZWQgd2l0aCB0aGUgdGV4dCBh Ym92ZS4NCj4+Pj4+Pj4+Pj4+Pg0KPj4+Pj4+Pj4+Pj4+IEZvciBleGFtcGxlLCB0aGVyZSBoYXMg YmVlbiBhIHN1Z2dlc3Rpb24gKGJ5IG15c2VsZikgdG8gdXNlIA0KPj4+Pj4+Pj4+Pj4+IHRoZSBT RFAgY29ubmVjdGlvbiBhdHRyaWJ1dGUgdG8gZXhwbGljaXRseSBpbmRpY2F0ZSB0aGF0IGEgDQo+ Pj4+Pj4+Pj4+Pj4gbmV3IERUTFMgY29ubmVjdGlvbiBuZWVkcyB0byBiZSBlc3RhYmxpc2hlZC4N Cj4+Pj4+Pj4+Pj4+Pg0KPj4+Pj4+Pj4+Pj4+DQo+Pj4+Pj4+Pj4+Pj4gVGhlIGRyYWZ0IGFsc28g c2F5czoNCj4+Pj4+Pj4+Pj4+Pg0KPj4+Pj4+Pj4+Pj4+IAkiSWYgdGhlIHRyYW5zcG9ydCBwYXJh bWV0ZXJzIG9yIHRoZSBrZXkgZmluZ2VycHJpbnRzIA0KPj4+Pj4+Pj4+Pj4+Y2hhbmdlLCB0aGUN Cj4+Pj4+Pj4+Pj4+PiAgICAgCWVuZHBvaW50cyBNVVNUIGVzdGFibGlzaCBhIG5ldyBEVExTIGNv bm5lY3Rpb24uIg0KPj4+Pj4+Pj4+Pj4+DQo+Pj4+Pj4+Pj4+Pj4gVGhpcyBpcyByZWxhdGVkIHRv IHRoZSBlYXJsaWVyIGlzc3VlLiBUaGVyZSBpcyB0aGUgDQo+Pj4+Pj4+Pj4+Pj5kaXNjdXNzaW9u IGFib3V0IElDRSAidmlydHVhbCBjb25uZWN0aW9ucyIsIGFuZCB0aGF0IGEgDQo+Pj4+Pj4+Pj4+ Pj5zaW5nbGUgRFRMUyBjb25uZWN0aW9uIHdvdWxkIGFwcGx5IHRvIGFsbCBJQ0UgY2FuZGlkYXRl cyANCj4+Pj4+Pj4+Pj4+PmFzc29jaWF0ZWQgd2l0aCBhbg0KPj4+Pj4+Pj4+Pj4+IG0tIGxpbmUu IFNvLCBldmVuIGlmIGEgY2FuZGlkYXRlIGNoYW5nZXMgKHJlYWQ6IHRyYW5zcG9ydCANCj4+Pj4+ Pj4+Pj4+PnBhcmFtZXRlciBjaGFuZ2VzKSwgaXQgd291bGQgbm90IGF1dG9tYXRpY2FsbHkgdHJp Z2dlciBhIG5ldyANCj4+Pj4+Pj4+Pj4+PkRUTFMgY29ubmVjdGlvbi4NCj4+Pj4+Pj4+Pj4+Pg0K Pj4+Pj4+Pj4+Pj4+DQo+Pj4+Pj4+Pj4+Pj4gVGhlIGlzc3VlcyBhYm92ZSBhcmUgYWxzbyBob2xk aW5nIHVwIHRoZSBTQ1RQLVNEUCBkcmFmdCwgc28gDQo+Pj4+Pj4+Pj4+Pj4gaXQgZG9lc24ndCBv bmx5IGFmZmVjdCBCRkNQYmlzIDopDQo+Pj4+Pj4+Pj4+Pj4NCj4+Pj4+Pj4+Pj4+Pg0KPj4+Pj4+ Pj4+Pj4+IFJlZ2FyZHMsDQo+Pj4+Pj4+Pj4+Pj4NCj4+Pj4+Pj4+Pj4+PiBDaHJpc3Rlcg0KPj4+ Pj4+Pj4+Pj4+DQo+Pj4+Pj4+Pj4+Pj4NCj4+Pj4+Pj4+Pj4+PiAtLS0tLU9yaWdpbmFsIE1lc3Nh Z2UtLS0tLQ0KPj4+Pj4+Pj4+Pj4+IEZyb206IEFsaXNzYSBDb29wZXIgW21haWx0bzphbGlzc2FA Y29vcGVydy5pbl0NCj4+Pj4+Pj4+Pj4+PiBTZW50OiA4LiBodWh0aWt1dXRhIDIwMTUgMzowNw0K Pj4+Pj4+Pj4+Pj4+IFRvOiBDaGFybGVzIEVja2VsIChlY2tlbGN1KQ0KPj4+Pj4+Pj4+Pj4+IENj OiBHb256YWxvIENhbWFyaWxsbzsgVG9tIEtyaXN0ZW5zZW4gKHRvbWtyaXN0KTsgDQo+Pj4+Pj4+ Pj4+Pj4gZHJhZnQtaWV0Zi1iZmNwYmlzLXJmYzQ1ODJiaXNAdG9vbHMuaWV0Zi5vcmc7IEJlbiBD YW1wYmVsbDsgDQo+Pj4+Pj4+Pj4+Pj4gQ2hyaXN0ZXIgSG9sbWJlcmcNCj4+Pj4+Pj4+Pj4+PiBT dWJqZWN0OiBSZTogZHJhZnQtaWV0Zi1iZmNwYmlzLXJmYzQ1ODNiaXMNCj4+Pj4+Pj4+Pj4+Pg0K Pj4+Pj4+Pj4+Pj4+IEFkZGluZyBDaHJpc3RlciB0byB0aGlzIHRocmVhZC4NCj4+Pj4+Pj4+Pj4+ Pg0KPj4+Pj4+Pj4+Pj4+IE9uIEFwciA3LCAyMDE1LCBhdCAxMjo0NCBQTSwgQ2hhcmxlcyBFY2tl bCAoZWNrZWxjdSkgDQo+Pj4+Pj4+Pj4+Pj4gPGVja2VsY3VAY2lzY28uY29tPg0KPj4+Pj4+Pj4+ Pj4+IHdyb3RlOg0KPj4+Pj4+Pj4+Pj4+DQo+Pj4+Pj4+Pj4+Pj4NCj4+Pj4+Pj4+Pj4+PiAgICAg ICANCj4+Pj4+Pj4+Pj4+Pj4gQ2hyaXN0ZXIgKGNj4oCZZCkgYW5kIEkgZGlzY3Vzc2VkIHNvbWUg b2YgdGhlIGNoYW5nZXMgDQo+Pj4+Pj4+Pj4+Pj4+IG9mZmxpc3QgaW4gRGFsbGFzLCBhbmQgaGUg aXMgdG8gY29tZSBiYWNrIHRvIHRoZSBsaXN0IHdpdGggDQo+Pj4+Pj4+Pj4+Pj4+IGNvbW1lbnRz IGFmdGVyIERhbGxhcw0KPj4+Pj4+Pj4+Pj4+PiAtIHdoaWNoIGlzIG5vdyA6KQ0KPj4+Pj4+Pj4+ Pj4+Pg0KPj4+Pj4+Pj4+Pj4+PiBDaGVlcnMsDQo+Pj4+Pj4+Pj4+Pj4+IENoYXJsZXMNCj4+Pj4+ Pj4+Pj4+Pj4NCj4+Pj4+Pj4+Pj4+Pj4gT24gNC83LzE1LCAxMDoyNiBBTSwgIkFsaXNzYSBDb29w ZXIiPGFsaXNzYUBjb29wZXJ3LmluPg0KPj4+Pj4+Pj4+Pj4+Pndyb3RlOg0KPj4+Pj4+Pj4+Pj4+ Pg0KPj4+Pj4+Pj4+Pj4+Pg0KPj4+Pj4+Pj4+Pj4+PiAgICAgIA0KPj4+Pj4+Pj4+Pj4+Pj4gQ2hl Y2tpbmcgaW4gb24gdGhpcyDigJQgaGFzIENocmlzdGVyIGJlZW4gcHJvbXB0ZWQgdG8gDQo+Pj4+ Pj4+Pj4+Pj4+PiByZXZpZXcgdGhlIGxhdGVzdCByZXYgb2YgZHJhZnQtaWV0Zi1iZmNwYmlzLXJm YzQ1ODNiaXM/DQo+Pj4+Pj4+Pj4+Pj4+Pg0KPj4+Pj4+Pj4+Pj4+Pj4gVGhhbmtzLA0KPj4+Pj4+ Pj4+Pj4+Pj4gQWxpc3NhDQo+Pj4+Pj4+Pj4+Pj4+Pg0KPj4+Pj4+Pj4+Pj4+Pj4gT24gRmViIDI1 LCAyMDE1LCBhdCA5OjE0IEFNLCBDaGFybGVzIEVja2VsIChlY2tlbGN1KSANCj4+Pj4+Pj4+Pj4+ Pj4+IDxlY2tlbGN1QGNpc2NvLmNvbT4NCj4+Pj4+Pj4+Pj4+Pj4+IHdyb3RlOg0KPj4+Pj4+Pj4+ Pj4+Pj4NCj4+Pj4+Pj4+Pj4+Pj4+DQo+Pj4+Pj4+Pj4+Pj4+PiAgICAgDQo+Pj4+Pj4+Pj4+Pj4+ Pj4gTW9zdCBvZiB0aGUgY2hhbmdlcyBJIHRoaXMgcmVjZW50IHVwZGF0ZSB0byByZmM0NTgzYmlz IA0KPj4+Pj4+Pj4+Pj4+Pj4+d2VyZSBpbnNwaXJlZCBieSBjb21tZW50cyBhbmQgc3VnZ2VzdGVk IHRleHQgcHJvdmlkZWQgYnkgDQo+Pj4+Pj4+Pj4+Pj4+Pj5DaHJpc3Rlci4NCj4+Pj4+Pj4+Pj4+ Pj4+PiBIZSBpcyBpbiB0aGUgcHJvY2VzcyBvZiByZXZpZXdpbmcuIElmIGFsbCBnb2VzIHdlbGwg d2l0aCANCj4+Pj4+Pj4+Pj4+Pj4+PnRoYXQsIHdlIGFyZSByZWFkeSB0byBwcm9jZWVkIHdpdGgg cHJvdG8gd3JpdGV1cCAoTWFyeSkgDQo+Pj4+Pj4+Pj4+Pj4+Pj5hbmQgQUQgcmV2aWV3Lg0KPj4+ Pj4+Pj4+Pj4+Pj4+DQo+Pj4+Pj4+Pj4+Pj4+Pj4gQ2hlZXJzLA0KPj4+Pj4+Pj4+Pj4+Pj4+IENo YXJsZXMNCj4+Pj4+Pj4+Pj4+Pj4+Pg0KPj4+Pj4+Pj4+Pj4+Pj4+IE9uIDIvMjUvMTUsIDc6MDEg QU0sICJBbGlzc2EgQ29vcGVyIjxhbGlzc2FAY29vcGVydy5pbj4NCj4+Pj4+Pj4+Pj4+Pj4+Pndy b3RlOg0KPj4+Pj4+Pj4+Pj4+Pj4+DQo+Pj4+Pj4+Pj4+Pj4+Pj4NCj4+Pj4+Pj4+Pj4+Pj4+PiAg ICANCj4+Pj4+Pj4+Pj4+Pj4+Pj4gcmZjNDU4MyBoYXMgbm90IGhhZCBhbiBBRCByZXZpZXcgeWV0 LiBSaWNoYXJkIGNhbiANCj4+Pj4+Pj4+Pj4+Pj4+Pj5ob3BlZnVsbHkgdGFrZSBjYXJlIG9mIHRo YXQgd2hpbGUgScK5bSBvbiBsZWF2ZSAoc3RhcnRpbmcgDQo+Pj4+Pj4+Pj4+Pj4+Pj4+dG9kYXks IGFjdHVhbGx5KS4NCj4+Pj4+Pj4+Pj4+Pj4+Pj4NCj4+Pj4+Pj4+Pj4+Pj4+Pj4gT24gRmViIDI1 LCAyMDE1LCBhdCAyOjU2IEFNLCBHb256YWxvIENhbWFyaWxsbw0KPj4+Pj4+Pj4+Pj4+Pj4+PiA8 Z29uemFsby5jYW1hcmlsbG9AZXJpY3Nzb24uY29tPiAgIHdyb3RlOg0KPj4+Pj4+Pj4+Pj4+Pj4+ Pg0KPj4+Pj4+Pj4+Pj4+Pj4+Pg0KPj4+Pj4+Pj4+Pj4+Pj4+PiAgIA0KPj4+Pj4+Pj4+Pj4+Pj4+ Pj4gSGkgQWxpc3NhLA0KPj4+Pj4+Pj4+Pj4+Pj4+Pj4NCj4+Pj4+Pj4+Pj4+Pj4+Pj4+IEkgaGF2 ZSBub3RlZCB0aGF0IHdoaWxlIHJmYzQ1ODJiaXMgaW4gb24gdGhlIGFnZW5kYSBvZiANCj4+Pj4+ Pj4+Pj4+Pj4+Pj4+dGhlIE1hcmNoIDV0aCB0ZWxlY2hhdCAodGhhbmtzIGZvciBoYW5kbGluZyB0 aGF0ISksIA0KPj4+Pj4+Pj4+Pj4+Pj4+Pj5yZmM0NTgzYmlzIGlzbid0LiBUb20gcmV2aXNlZCBy ZmM0NTgzYmlzIG9uIEZlYnJ1YXJ5IA0KPj4+Pj4+Pj4+Pj4+Pj4+Pj4yMHRoLiBTaG91bGQgcmZj NDU4M2JpcyBiZSBvbiB0aGUgYWdlbmRhIG9mIHRoZSANCj4+Pj4+Pj4+Pj4+Pj4+Pj4+dGVsZWNo YXQgYXMgd2VsbCBvciB0aGVyZSBpcyBzdGlsbCBzb21ldGhpbmcgbGVmdCBmb3IgDQo+Pj4+Pj4+ Pj4+Pj4+Pj4+PlRvbSB0byB0YWtlIGNhcmUgb2Y/DQo+Pj4+Pj4+Pj4+Pj4+Pj4+Pg0KPj4+Pj4+ Pj4+Pj4+Pj4+Pj4gVGhhbmtzLA0KPj4+Pj4+Pj4+Pj4+Pj4+Pj4NCj4+Pj4+Pj4+Pj4+Pj4+Pj4+ IEdvbnphbG8NCj4+Pj4+Pj4+Pj4+Pj4+Pj4+DQo+Pj4+Pj4+Pj4+Pj4+Pj4+PiBPbiAxOC8wMi8y MDE1IDk6MjggUE0sIEFsaXNzYSBDb29wZXIgd3JvdGU6DQo+Pj4+Pj4+Pj4+Pj4+Pj4+Pg0KPj4+ Pj4+Pj4+Pj4+Pj4+Pj4gIA0KPj4+Pj4+Pj4+Pj4+Pj4+Pj4+IFBpbmdpbmcgb24gdGhpcy4NCj4+ Pj4+Pj4+Pj4+Pj4+Pj4+Pg0KPj4+Pj4+Pj4+Pj4+Pj4+Pj4+IE1hcmNoIDUgd2lsbCBsaWtlbHkg YmUgbXkgbGFzdCB0ZWxlY2hhdCBiZWZvcmUgZ29pbmcgIA0KPj4+Pj4+Pj4+Pj4+Pj4+Pj4+b24g bGVhdmUsIHNvICBpdCB3b3VsZCBiZSBncmVhdCB0byBnZXQgdGhpcyBzY2hlZHVsZWQgIA0KPj4+ Pj4+Pj4+Pj4+Pj4+Pj4+b24gdGhhdCBvbmUuIFRvIGRvIHRoYXQsICB0aGUgcmV2IG5lZWRzIHRv IGJlIHBvc3RlZCANCj4+Pj4+Pj4+Pj4+Pj4+Pj4+PnRvZGF5Lg0KPj4+Pj4+Pj4+Pj4+Pj4+Pj4+ IFRoZSB1cGRhdGVzIGFyZSBwcmV0dHkgbWluaW1hbCAgYW5kIGFyZSBhbGwgYmFzaWNhbGx5ICAN Cj4+Pj4+Pj4+Pj4+Pj4+Pj4+PndyaXR0ZW4gdXAgaW4gQ2hhcmxlc8K5IHJlc3BvbnNlIHRvIG15 IEFEIHJldmlldy4NCj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pg0KPj4+Pj4+Pj4+Pj4+Pj4+Pj4+IEFsaXNz YQ0KPj4+Pj4+Pj4+Pj4+Pj4+Pj4+DQo+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4gT24gRmViIDE1LCAyMDE1 LCBhdCA5OjEzIEFNLCBHb256YWxvIENhbWFyaWxsbyANCj4+Pj4+Pj4+Pj4+Pj4+Pj4+PiA8Z29u emFsby5jYW1hcmlsbG9AZXJpY3Nzb24uY29tIA0KPj4+Pj4+Pj4+Pj4+Pj4+Pj4+IDxtYWlsdG86 Z29uemFsby5jYW1hcmlsbG9AZXJpY3Nzb24uY29tPj4NCj4+Pj4+Pj4+Pj4+Pj4+Pj4+PiB3cm90 ZToNCj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pg0KPj4+Pj4+Pj4+Pj4+Pj4+Pj4+DQo+Pj4+Pj4+Pj4+Pj4+ Pj4+Pj4gDQo+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+IEkgaGF2ZSB0YWxrZWQgb2ZmbGluZSB3aXRoIHRo ZSBvdGhlciBhdXRob3JzIGFuZCBUb20gDQo+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+aXMgaG9sZGluZyB0 aGUgcGVuLiBUb20sIGRvIHlvdSB0aGluayB5b3UgY2FuIG1lZXQgDQo+Pj4+Pj4+Pj4+Pj4+Pj4+ Pj4+dGhlIHRpbWUgZnJhbWUgYmVsb3c/DQo+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+DQo+Pj4+Pj4+Pj4+ Pj4+Pj4+Pj4+IENoZWVycywNCj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4NCj4+Pj4+Pj4+Pj4+Pj4+Pj4+ Pj4gR29uemFsbw0KPj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pg0KPj4+Pj4+Pj4+Pj4+Pj4+Pj4+PiBTZW50 IGZyb20gbXkgbW9iaWxlDQo+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+DQo+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+ DQo+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+DQo+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+IC0tLS0gQWxpc3NhIENv b3BlciB3cm90ZSAtLS0tDQo+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+DQo+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+ IEp1c3Qgd2FudGVkIHRvIHNlZSBpZiB0aGlzIHJldiBtaWdodCBnZXQgZG9uZSBpbiB0aGUgDQo+ Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+IG5leHQgY291cGxlICBvZiBkYXlzLiBJZiBzbywgd2UgY291bGQg Z2V0IGl0IG9uIHRoZSANCj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4gbmV4dCB0ZWxlY2hhdCBhZ2VuZGEg KE1hcmNoIDUpLg0KPj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pg0KPj4+Pj4+Pj4+Pj4+Pj4+Pj4+PiBBbGlz c2ENCj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4NCj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4gQmVnaW4gZm9yd2Fy ZGVkIG1lc3NhZ2U6DQo+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+DQo+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+DQo+ Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+DQo+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+PiAqRnJvbTogKkFsaXNzYSBD b29wZXI8YWxpc3NhQGNvb3BlcncuaW4gDQo+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+PiA8bWFpbHRvOmFs aXNzYUBjb29wZXJ3LmluPj4NCj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+ICpTdWJqZWN0OiAqKlJlOiBb YmZjcGJpc10gQUQgZXZhbHVhdGlvbjoNCj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+IGRyYWZ0LWlldGYt YmZjcGJpcy1yZmM0NTgyYmlzLTEyKg0KPj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4gKkRhdGU6ICpGZWJy dWFyeSA5LCAyMDE1IGF0IDM6NTg6NTIgUE0gUFNUDQo+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+PiAqVG86 ICoiQ2hhcmxlcyBFY2tlbCAoZWNrZWxjdSkiPGVja2VsY3VAY2lzY28uY29tIA0KPj4+Pj4+Pj4+ Pj4+Pj4+Pj4+Pj4gPG1haWx0bzplY2tlbGN1QGNpc2NvLmNvbT4+DQo+Pj4+Pj4+Pj4+Pj4+Pj4+ Pj4+PiAqQ2M6ICoiYmZjcGJpc0BpZXRmLm9yZzxtYWlsdG86YmZjcGJpc0BpZXRmLm9yZz4iDQo+ Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+PiA8YmZjcGJpc0BpZXRmLm9yZw0KPj4+Pj4+Pj4+Pj4+Pj4+Pj4+ Pj4gPG1haWx0bzpiZmNwYmlzQGlldGYub3JnPj4NCj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+DQo+Pj4+ Pj4+Pj4+Pj4+Pj4+Pj4+PiBIaSBDaGFybGVzLA0KPj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4NCj4+Pj4+ Pj4+Pj4+Pj4+Pj4+Pj4+IFRoYW5rcywgc29tZSByZXNwb25zZXMgaW5saW5lLg0KPj4+Pj4+Pj4+ Pj4+Pj4+Pj4+Pj4NCj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+IE9uIEZlYiA0LCAyMDE1LCBhdCAxMDo0 MCBBTSwgQ2hhcmxlcyBFY2tlbCAoZWNrZWxjdSkNCj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+IDxlY2tl bGN1QGNpc2NvLmNvbTxtYWlsdG86ZWNrZWxjdUBjaXNjby5jb20+PiAgIHdyb3RlOg0KPj4+Pj4+ Pj4+Pj4+Pj4+Pj4+Pj4NCj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+DQo+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+ Pg0KPj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+IEhJIEFsaXNzYSwNCj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+ Pg0KPj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+IFRoYW5rIHlvdSBmb3IgdGhlIHJldmlldy4gUGxlYXNl IHNlZSBteSB0aG91Z2h0cyANCj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+PiBvbiB5b3VyIGNvbW1lbnRz IGFuZCBxdWVzdGlvbnMgaW5saW5lLg0KPj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+DQo+Pj4+Pj4+Pj4+ Pj4+Pj4+Pj4+Pj4gRnJvbTogQWxpc3NhIENvb3BlcjxhbGlzc2FAY29vcGVydy5pbiANCj4+Pj4+ Pj4+Pj4+Pj4+Pj4+Pj4+PiA8bWFpbHRvOmFsaXNzYUBjb29wZXJ3LmluPj4NCj4+Pj4+Pj4+Pj4+ Pj4+Pj4+Pj4+PiBEYXRlOiBUaHVyc2RheSwgSmFudWFyeSAyOSwgMjAxNSBhdCAxMDoxOSBQTQ0K Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+IFRvOiAiYmZjcGJpc0BpZXRmLm9yZzxtYWlsdG86YmZjcGJp c0BpZXRmLm9yZz4iDQo+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4gPGJmY3BiaXNAaWV0Zi5vcmc8bWFp bHRvOmJmY3BiaXNAaWV0Zi5vcmc+Pg0KPj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+IFN1YmplY3Q6IFti ZmNwYmlzXSBBRCBldmFsdWF0aW9uOg0KPj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+IGRyYWZ0LWlldGYt YmZjcGJpcy1yZmM0NTgyYmlzLTEyDQo+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4NCj4+Pj4+Pj4+Pj4+ Pj4+Pj4+Pj4+Pg0KPj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+DQo+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+ IEkgaGF2ZSByZXZpZXdlZCB0aGlzIGRyYWZ0IGluIHByZXBhcmF0aW9uIGZvciBJRVRGIExDLg0K Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+PiBPdmVyYWxsIHRoZSBkb2N1bWVudCBhcHBlYXJzIGluIGdv b2Qgc2hhcGUuIEkgDQo+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+IGhhdmUgYSBmZXcgcXVlc3Rpb25z IGFuZCBjb21tZW50cyBJwrlkIGxpa2UgdG8gDQo+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+IGRpc2N1 c3MgYmVmb3JlIGlzc3VpbmcgdGhlIElFVEYgbGFzdCBjYWxsLiBJwrl2ZSANCj4+Pj4+Pj4+Pj4+ Pj4+Pj4+Pj4+Pj4gYWxzbyBpbmNsdWRlZCBzb21lIGVkaXRvcmlhbCBuaXRzIHRoYXQgc2hvdWxk IGJlIA0KPj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+PiBhZGRyZXNzZWQgdG9nZXRoZXIgd2l0aCBhbnkg bGFzdCBjYWxsIGNvbW1lbnRzLg0KPj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pg0KPj4+Pj4+Pj4+Pj4+ Pj4+Pj4+Pj4+PiBDb21tZW50cyBhbmQgcXVlc3Rpb25zOg0KPj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+ Pg0KPj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+PiA9IFNlY3Rpb24gNS4xID0NCj4+Pj4+Pj4+Pj4+Pj4+ Pj4+Pj4+Pj4gIklmIGFuIGVuZHBvaW50IHJlY2VpdmVzIGEgbWVzc2FnZSB3aXRoIGFuIA0KPj4+ Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+PiB1bnN1cHBvcnRlZCB2ZXJzaW9uIGZpZWxkIHZhbHVlLCB0aGUg cmVjZWl2aW5nIA0KPj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+PiBzZXJ2ZXIgTVVTVCBzZW5kIGFuIEVy cm9yIG1lc3NhZ2Ugd2l0aCBwYXJhbWV0ZXIgDQo+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+IHZhbHVl IDEyIChVbnN1cHBvcnRlZA0KPj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+PiBWZXJzaW9uKSB0byBpbmRp Y2F0ZSB0aGlzLsKyDQo+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+DQo+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+ Pj4+IFRoaXMgc2VlbXMgYSBsaXR0bGUgbWlzbGVhZGluZyBzaW5jZSBSRkMgNDU4MiANCj4+Pj4+ Pj4+Pj4+Pj4+Pj4+Pj4+Pj5kaWRuwrl0IHNwZWNpZnkgd2hhdCB0byBkbyB1cG9uIHJlY2VpcHQg b2YgYSANCj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj5tZXNzYWdlIHdpdGggYSB2ZXJzaW9uIG90aGVy IHRoYW4gMS4NCj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4gSW1wbGVtZW50YXRpb25zIHRoYXQgZG8g bm90IGdldCB1cGdyYWRlZCB0byBiZSANCj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj5jb21wbGlhbnQg d2l0aCAgNDU4MmJpcyAod2hpY2ggY291bGQgY2VydGFpbmx5IA0KPj4+Pj4+Pj4+Pj4+Pj4+Pj4+ Pj4+PmFjY291bnQgZm9yIHNvbWUgb2YgdGhvc2UgdGhhdCAgd2lsbCBub3Qgc3VwcG9ydCANCj4+ Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj52ZXJzaW9uIDIpIHdpbGwgdGhlcmVmb3JlIG5ldmVyIHNlbmQg dGhlICBlcnJvciANCj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj5zcGVjaWZpZWQgaGVyZS4NCj4+Pj4+ Pj4+Pj4+Pj4+Pj4+Pj4+Pj4gVGhpcyBzZWVtcyBsaWtlIGl0IHNob3VsZCBhdCBsZWFzdCBiZSAg bm90ZWQgDQo+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+Z2l2ZW4gdGhlIE1VU1QtbGV2ZWwgcmVxdWly ZW1lbnQuIFRoZSBzYW1lIGFwcGxpZXMgDQo+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+aW4gU2VjdGlv biAxMy43Lg0KPj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pg0KPj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pg0K Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+IEdvb2QgcG9pbnQuIEkgYmVsaWV2ZSB3ZSBtYWRlIHRoaXMg YSBNVVNUIGJlY2F1c2UgDQo+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4gd2Ugd2VyZSB0aGlua2luZyBp biB0ZXJtcyBvZiBpbXBsZW1lbnRhdGlvbnMgDQo+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4gY29tcGxp YW50IHdpdGggdGhpcyBiaXMgdmVyc2lvbi4NCj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+PiBBZGRpbmcN Cj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+PiB5b3VyIHN1Z2dlc3RlZCBub3RlIGFib3V0IHJmYyA0NTgy IGltcGxlbWVudGF0aW9ucyANCj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+PiBoZXJlIGFuZCBpbiAgc2Vj dGlvbiAxMy43IHNlZW1zIHVzZWZ1bCB0byBtZS4NCj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pg0KPj4+ Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+DQo+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+PiBPaw0KPj4+Pj4+Pj4+Pj4+ Pj4+Pj4+Pj4NCj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+DQo+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pg0KPj4+ Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+DQo+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4NCj4+Pj4+Pj4+Pj4+Pj4+ Pj4+Pj4+Pj4gPSBTZWN0aW9uIDcgPQ0KPj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+PiAiQkZDUCBlbnRp dGllcyBNVVNUIHN1cHBvcnQsIGF0IGEgbWluaW11bSwgdGhlIA0KPj4+Pj4+Pj4+Pj4+Pj4+Pj4+ Pj4+PiBUTFNfUlNBX1dJVEhfQUVTXzEyOF9DQkNfU0hBIGNpcGhlcnN1aXRlIFs2XS7Csg0KPj4+ Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pg0KPj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+PiBJIHJlYWxpemUgdGhp cyByZXF1aXJlbWVudCBjb21lcyBmcm9tIFJGQyA0NTgyLCANCj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+ Pj4gYnV0IEnCuWQgbGlrZSB0byB1bmRlcnN0YW5kIHdoeSBpdCBoYXMgbm90IGJlZW4gDQo+Pj4+ Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+IHVwZGF0ZWQgdG8gYmUgY29uc2lzdGVudCB3aXRoIG1vcmUgY3Vy cmVudCANCj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4gZ3VpZGFuY2Ugb24gY2lwaGVyIHN1aXRlIHNl bGVjdGlvbiAoZS5nLiwNCj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4NCj4+Pj4+Pj4+Pj4+Pj4+Pj4+ Pj4+Pj4gaHR0cHM6Ly90b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0LWlldGYtdXRhLXRscy1iYw0K Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+PiBwDQo+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+IC0NCj4+Pj4+ Pj4+Pj4+Pj4+Pj4+Pj4+Pj4gMA0KPj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+PiA4DQo+Pj4+Pj4+Pj4+ Pj4+Pj4+Pj4+Pj4+ICMNCj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4gcw0KPj4+Pj4+Pj4+Pj4+Pj4+ Pj4+Pj4+PiBlDQo+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+IGMNCj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+ Pj4gdGlvbg0KPj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+PiAtNCkNCj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+ Pj4gLg0KPj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pg0KPj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pg0KPj4+ Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+IEhvdyBhYm91dCB3ZSBrZWVwIHRoaXMgbWluaW11bSByZXF1aXJl bWVudCwgYW5kIA0KPj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+IGFkZCBhIHJlZmVyZW5jZSB0byBkcmFm dC1pZXRmLXV0YS10bHMtYmNwIGFsb25nIA0KPj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+IHdpdGggYSBy ZWNvbW1lbmRhdGlvbiB0byBhZGhlcmUgdG8gdGhlIGJlc3QgDQo+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+ Pj4gcHJhY3RpY2VzIGl0IG91dGxpbmVzIGluIHNlY3Rpb24gND8NCj4+Pj4+Pj4+Pj4+Pj4+Pj4+ Pj4+Pg0KPj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+DQo+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+PiBJIHRoaW5r IE1VU1Qgc3VwcG9ydCBUTFNfUlNBX1dJVEhfQUVTXzEyOF9DQkNfU0hBIA0KPj4+Pj4+Pj4+Pj4+ Pj4+Pj4+Pj4gZm9yIGJhY2t3YXJkcyBjb21wYXRpYmlsaXR5IGFuZCBTSE9VTEQgc3VwcG9ydCB0 aGUgDQo+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+PiBvbmVzIGxpc3RlZCBpbiB0aGUgVVRBIGRyYWZ0cyB3 b3VsZCBiZSBvay4NCj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+DQo+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pg0K Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4NCj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pg0KPj4+Pj4+Pj4+Pj4+ Pj4+Pj4+Pj4+DQo+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+ID0gU2VjdGlvbnMgOCwgOC4xLCA4LjIg PSBJdCBzZWVtcyBsaWtlIHRoZSANCj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj50cmFuc2FjdGlvbiBJ RCByZXF1aXJlbWVudHMgcmVnYXJkaW5nIA0KPj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pm5vbi1yZXVz ZS9tb25vdG9uaWNhbGx5IGluY3JlYXNpbmcgSURzIGFyZSANCj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+ Pj5yZS1zdGF0ZWQgbXVsdGlwbGUgdGltZXMgYWNyb3NzIHRoZXNlIHRocmVlIA0KPj4+Pj4+Pj4+ Pj4+Pj4+Pj4+Pj4+PnNlY3Rpb25zLCBpbiBzbGlnaHRseSBkaWZmZXJlbnQgd2F5cywgdG8gdGhl IHBvaW50IA0KPj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+PndoZXJlIGl0wrlzIG5vdCBjbGVhciBleGFj dGx5IHdoYXQgdGhleSBhcmUuDQo+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+IEl0IHNlZW1zIGxpa2Ug dGhleSBhcmU6DQo+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+DQo+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+ ICgxKSBSZWxpYWJsZSB0cmFuc3BvcnQsIHNlcnZlci1pbml0aWF0ZWQgdHJhbnNhY3Rpb246DQo+ Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+IElEIGlzDQo+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+IDANCj4+ Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4gKDIpIFVucmVsaWFibGUgdHJhbnNwb3J0LCBzZXJ2ZXItaW5p dGlhdGVkDQo+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+dHJhbnNhY3Rpb246DQo+Pj4+Pj4+Pj4+Pj4+ Pj4+Pj4+Pj4+IElEIE1VU1QgYmUgbW9ub3RvbmljYWxseSBpbmNyZWFzaW5nIChleGNlcHQgZm9y DQo+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+IHdyYXAtYXJvdW5kKQ0KPj4+Pj4+Pj4+Pj4+Pj4+Pj4+ Pj4+PiAoMykgUmVsaWFibGUgdHJhbnNwb3J0LCBjbGllbnQtaW5pdGlhdGVkIHRyYW5zYWN0aW9u Og0KPj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+PiBJRCBNVVNUIE5PVCBiZSAwIGFuZCBNVVNUIE5PVCBi ZSByZXVzZWQgaW4gDQo+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+YW5vdGhlciBtZXNzYWdlIGZyb20g dGhlIGNsaWVudCB1bnRpbCBhIHJlc3BvbnNlIA0KPj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+PmZyb20g dGhlIHNlcnZlciBpcyByZWNlaXZlZCBmb3IgdGhlIHRyYW5zYWN0aW9uLCANCj4+Pj4+Pj4+Pj4+ Pj4+Pj4+Pj4+Pj5idXQgbmVlZCBub3QgYmUgbW9ub3RvbmljYWxseSBpbmNyZWFzaW5nIChlLmcu LCBhIA0KPj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pmxvd2VyLCByZWNlbnRseSB1c2VkIElEIGNvdWxk IGJlIHJlLXVzZWQgb25jZSBhIA0KPj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+PnJlc3BvbnNlIGlzDQo+ Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+IHJlY2VpdmVkKQ0KPj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+PiAo NCkgVW5yZWxpYWJsZSB0cmFuc3BvcnQsIGNsaWVudC1pbml0aWF0ZWQNCj4+Pj4+Pj4+Pj4+Pj4+ Pj4+Pj4+Pj50cmFuc2FjdGlvbjoNCj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4gSUQgTVVTVCBiZSBt b25vdG9uaWNhbGx5IGluY3JlYXNpbmcgKGV4Y2VwdCBmb3INCj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+ Pj4gd3JhcC1hcm91bmQpDQo+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+DQo+Pj4+Pj4+Pj4+Pj4+Pj4+ Pj4+Pj4+IElzICgzKSB0aGUgY29ycmVjdCBpbnRlcnByZXRhdGlvbiBvZiB0aGUgdGV4dCBpbiA4 LjE/DQo+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+IElmIHNvLCB3aHkgbm90IGp1c3QgcmVxdWlyZSBJ RHMgaW4gYWxsIA0KPj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+PmNsaWVudC1pbml0aWF0ZWQgdHJhbnNh Y3Rpb25zIHRvIGJlIG1vbm90b25pY2FsbHkgDQo+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+aW5jcmVh c2luZz8NCj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4NCj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4NCj4+ Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+PiBBZ3JlZSB3ZSBjYW4gYW5kIHNob3VsZCBzaW1wbGlmeSB0aGlz LiBTZWN0aW9ucyANCj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+PiA4LjEgYW5kDQo+Pj4+Pj4+Pj4+Pj4+ Pj4+Pj4+Pj4gOC4yIGNvdmVyIHRoZSBjbGllbnQgYmVoYXZpb3IgYW5kIHNlcnZlciBiZWhhdmlv ciANCj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+PiBpbiBkZXRhaWwuIEFzIHN1Y2gsIHRoZSB0cmFuc2Fj dGlvbiBJRCByZWxhdGVkIA0KPj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+IGluZm9ybWF0aW9uIGF0IHRo ZSBzdGFydCBvZiBTZWN0aW9uIDggaXMgc3VwZXJmbHVvdXMuDQo+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+ Pj4gSSByZWNvbW1lbmQgcmVkdWNpbmcgdGhlIHRleHQgaW4gU2VjdGlvbiA4IHRvIHRoZQ0KPj4+ Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+IGZvbGxvdzoNCj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pg0KPj4+Pj4+ Pj4+Pj4+Pj4+Pj4+Pj4+IDguIFByb3RvY29sIFRyYW5zYWN0aW9ucw0KPj4+Pj4+Pj4+Pj4+Pj4+ Pj4+Pj4+DQo+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4gSW4gQkZDUCwgdGhlcmUgYXJlIHR3byB0eXBl cyBvZiB0cmFuc2FjdGlvbnM6DQo+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4gY2xpZW50LWluaXRpYXRl ZCB0cmFuc2FjdGlvbnMgYW5kIHNlcnZlci1pbml0aWF0ZWQgDQo+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+ Pj4gdHJhbnNhY3Rpb25zLg0KPj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+DQo+Pj4+Pj4+Pj4+Pj4+Pj4+ Pj4+Pj4gQ2xpZW50LWluaXRpYXRlZCB0cmFuc2FjdGlvbnMgY29uc2lzdCBvZiBhIHJlcXVlc3Qg DQo+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4gZnJvbSBhIGNsaWVudCB0byBhIGZsb29yIGNvbnRyb2wg c2VydmVyIGFuZCBhIA0KPj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+IHJlc3BvbnNlIGZyb20gdGhlIGZs b29yIGNvbnRyb2wgc2VydmVyIHRvIHRoZSBjbGllbnQuDQo+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4N Cj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+PiBTZXJ2ZXItaW5pdGlhdGVkIHRyYW5zYWN0aW9ucyBoYXZl IGRpZmZlcmVudCANCj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+PiBiZWhhdmlvciBkZXBlbmRpbmcgb24g dW5kZXJseWluZyB0cmFuc3BvcnQ6DQo+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4NCj4+Pj4+Pj4+Pj4+ Pj4+Pj4+Pj4+PiAgICAgIFdoZW4gdXNpbmcgYSByZWxpYWJsZSB0cmFuc3BvcnQsIA0KPj4+Pj4+ Pj4+Pj4+Pj4+Pj4+Pj4+c2VydmVyLWluaXRpYXRlZCB0cmFuc2FjdGlvbnMNCj4+Pj4+Pj4+Pj4+ Pj4+Pj4+Pj4+PiAgICAgIGNvbnNpc3Qgb2YgYSBzaW5nbGUgbWVzc2FnZSBmcm9tIGEgZmxvb3Ig DQo+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj5jb250cm9sIHNlcnZlciB0byBhDQo+Pj4+Pj4+Pj4+Pj4+ Pj4+Pj4+Pj4gICAgICBjbGllbnQgKG5vdGlmaWNhdGlvbnMpLiAgVGhleSBkbyBub3QgdHJpZ2dl ciANCj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+PmFueSByZXNwb25zZS4NCj4+Pj4+Pj4+Pj4+Pj4+Pj4+ Pj4+Pg0KPj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+ICAgICAgV2hlbiB1c2luZyBhbiB1bnJlbGlhYmxl IHRyYW5zcG9ydCwgDQo+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj5zZXJ2ZXItaW5pdGlhdGVkIHRyYW5z YWN0aW9ucw0KPj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+ICAgICAgY29uc2lzdCBvZiBhIHJlcXVlc3Qg ZnJvbSBhIGZsb29yIGNvbnRyb2wgDQo+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj5zZXJ2ZXIgdG8gYSBj bGllbnQgYW5kIGENCj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+PiAgICAgIHJlc3BvbnNlIGZyb20gdGhl IGNsaWVudCB0byB0aGUgZmxvb3IgY29udHJvbCANCj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+PnNlcnZl ci4NCj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pg0KPj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+IFdoZW4gdXNp bmcgQkZDUCBvdmVyIGFuIHVucmVsaWFibGUgdHJhbnNwb3J0LCANCj4+Pj4+Pj4+Pj4+Pj4+Pj4+ Pj4+PnJldHJhbnNtaXNzaW9uIHRpbWVyIFQxIChzZWUgU2VjdGlvbiA4LjMpIE1VU1QgYmUgDQo+ Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj51c2VkIGZvciBhbGwgcmVxdWVzdHMgdW50aWwgdGhlIHRyYW5z YWN0aW9uIGlzIA0KPj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+Y29tcGxldGVkLg0KPj4+Pj4+Pj4+Pj4+ Pj4+Pj4+Pj4+DQo+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4gVGhlbiBpbiBzZWN0aW9uIDguMSwgd2Ug YWRkIHRoZSBpbXBvcnRhbnQgZGV0YWlscyANCj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+PiByZW1vdmVk IGZyb20gc2VjdGlvbiA4Lg0KPj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+DQo+Pj4+Pj4+Pj4+Pj4+Pj4+ Pj4+Pj4gOC4xLjEgQ2xpZW50IEJlaGF2aW9yDQo+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4NCj4+Pj4+ Pj4+Pj4+Pj4+Pj4+Pj4+PiBBIGNsaWVudCBzdGFydGluZyBhIGNsaWVudC1pbml0aWF0ZWQgdHJh bnNhY3Rpb24gDQo+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4gTVVTVCBzZXQgdGhlIENvbmZlcmVuY2Ug SUQgaW4gdGhlIGNvbW1vbiBoZWFkZXIgb2YgDQo+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4gdGhlIG1l c3NhZ2UgdG8gdGhlIENvbmZlcmVuY2UgSUQgZm9yIHRoZSANCj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+ PiBjb25mZXJlbmNlIHRoYXQgdGhlIGNsaWVudCBvYnRhaW5lZCBwcmV2aW91c2x5Lg0KPj4+Pj4+ Pj4+Pj4+Pj4+Pj4+Pj4+DQo+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4gVGhlIGNsaWVudCBNVVNUIHNl dCB0aGUgVHJhbnNhY3Rpb24gSUQgdmFsdWUgaW4gDQo+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj50aGUg Y29tbW9uIGhlYWRlciB0byBhIG51bWJlciB0aGF0IGlzIGRpZmZlcmVudCANCj4+Pj4+Pj4+Pj4+ Pj4+Pj4+Pj4+PmZyb20gMCBhbmQgdGhhdCBNVVNUIE5PVCBiZSByZXVzZWQgaW4gYW5vdGhlciAN Cj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pm1lc3NhZ2UgZnJvbSB0aGUgY2xpZW50IHVudGlsIGEgcmVz cG9uc2UgZnJvbSB0aGUgDQo+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj5zZXJ2ZXIgaXMgcmVjZWl2ZWQg Zm9yIHRoZSB0cmFuc2FjdGlvbi4NCj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+PiBUaGUgY2xpZW50IHVz ZXMgdGhlIFRyYW5zYWN0aW9uIElEIHZhbHVlIHRvIG1hdGNoIA0KPj4+Pj4+Pj4+Pj4+Pj4+Pj4+ Pj4+dGhpcyBtZXNzYWdlIHdpdGggdGhlIHJlc3BvbnNlIGZyb20gdGhlIGZsb29yIA0KPj4+Pj4+ Pj4+Pj4+Pj4+Pj4+Pj4+Y29udHJvbCBzZXJ2ZXIuDQo+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4gV2hl biB1c2luZyBCRkNQIG92ZXIgYW4gdW5yZWxpYWJsZSB0cmFuc3BvcnQsIGl0IA0KPj4+Pj4+Pj4+ Pj4+Pj4+Pj4+Pj4+aXMgaW1wb3J0YW50IHRvIGNob29zZSBhIFRyYW5zYWN0aW9uIElEIHZhbHVl IHRoYXQgDQo+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj5sZXRzIHRoZSByZWNlaXZlciBkaXN0aW5ndWlz aCB0aGUgcmVjZXB0aW9uIG9mIHRoZSANCj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pm5leHQgbWVzc2Fn ZSBpbiBhIHNlcXVlbmNlIG9mIEJGQ1AgbWVzc2FnZXMgZnJvbSBhIA0KPj4+Pj4+Pj4+Pj4+Pj4+ Pj4+Pj4+cmV0cmFuc21pc3Npb24gb2YgYSBwcmV2aW91cyBtZXNzYWdlLiAgVGhlcmVmb3JlLCAN Cj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+PkJGQ1AgZW50aXRpZXMgdXNpbmcgYW4gdW5yZWxpYWJsZSB0 cmFuc3BvcnQgTVVTVCANCj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+PnVzZSBtb25vdG9uaWNhbGx5IGlu Y3JlYXNpbmcgVHJhbnNhY3Rpb24gSUQgdmFsdWVzIA0KPj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+KGV4 Y2VwdCBmb3Igd3JhcC1hcm91bmQpLg0KPj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+DQo+Pj4+Pj4+Pj4+ Pj4+Pj4+Pj4+Pj4gQSBjbGllbnQgcmVjZWl2aW5nIGEgc2VydmVyLWluaXRpYXRlZCB0cmFuc2Fj dGlvbiANCj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pm92ZXIgYW4gdW5yZWxpYWJsZSB0cmFuc3BvcnQg TVVTVCBjb3B5IHRoZSANCj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+PlRyYW5zYWN0aW9uIElEIGZyb20g dGhlIHJlcXVlc3QgcmVjZWl2ZWQgZnJvbSB0aGUgDQo+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj5zZXJ2 ZXIgaW50byB0aGUgcmVzcG9uc2UuDQo+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4gW1F1ZXN0aW9uOiBp cyB0aGVyZSBhIG5lZWQgdG8gY29weSB0aGUgQ29uZmVyZW5jZSANCj4+Pj4+Pj4+Pj4+Pj4+Pj4+ Pj4+PklEIGFuZCAgVXNlciBJRCwgaWYgcHJlc2VudD9dDQo+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4N Cj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+PiA4LjIuIFNlcnZlciBCZWhhdmlvcg0KPj4+Pj4+Pj4+Pj4+ Pj4+Pj4+Pj4+DQo+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4gQSBmbG9vciBjb250cm9sIHNlcnZlciBz ZW5kaW5nIGEgcmVzcG9uc2Ugd2l0aGluIGEgDQo+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj5jbGllbnQt aW5pdGlhdGVkIHRyYW5zYWN0aW9uIE1VU1QgY29weSB0aGUgDQo+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+ Pj5Db25mZXJlbmNlIElELCB0aGUgVHJhbnNhY3Rpb24gSUQsIGFuZCB0aGUgVXNlciBJRCANCj4+ Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+PmZyb20gdGhlIHJlcXVlc3QgcmVjZWl2ZWQgZnJvbSB0aGUgY2xp ZW50IGludG8gdGhlIA0KPj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+cmVzcG9uc2UuDQo+Pj4+Pj4+Pj4+ Pj4+Pj4+Pj4+Pj4NCj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+PiBTZXJ2ZXItaW5pdGlhdGVkIHRyYW5z YWN0aW9ucyBNVVNUIGNvbnRhaW4gYSANCj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+PlRyYW5zYWN0aW9u IElEIGVxdWFsIHRvDQo+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4gMCB3aGVuIEJGQ1AgaXMgdXNlZCBv dmVyIGEgcmVsaWFibGUgdHJhbnNwb3J0Lg0KPj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+T3ZlciBhbiB1 bnJlbGlhYmxlIHRyYW5zcG9ydCwgdGhlIFRyYW5zYWN0aW9uIElEIA0KPj4+Pj4+Pj4+Pj4+Pj4+ Pj4+Pj4+c2hhbGwgaGF2ZSB0aGUgc2FtZSBwcm9wZXJ0aWVzIGFzIGZvciANCj4+Pj4+Pj4+Pj4+ Pj4+Pj4+Pj4+PmNsaWVudC1pbml0aWF0ZWQgdHJhbnNhY3Rpb25zLg0KPj4+Pj4+Pj4+Pj4+Pj4+ Pj4+Pj4+VGhlIHNlcnZlciB1c2VzIHRoZSBUcmFuc2FjdGlvbiBJRCB2YWx1ZSB0byBtYXRjaCAN Cj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+PnRoaXMgbWVzc2FnZSB3aXRoIHRoZSByZXNwb25zZSBmcm9t IHRoZSBmbG9vciANCj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+PnBhcnRpY2lwYW50IG9yIGZsb29yIGNo YWlyLg0KPj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+DQo+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4NCj4+Pj4+ Pj4+Pj4+Pj4+Pj4+Pj4+Pg0KPj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4gVGhhbmtzLCB0aGlzIGlzIGJl dHRlci4NCj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+DQo+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pg0KPj4+Pj4+ Pj4+Pj4+Pj4+Pj4+Pj4NCj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4gPSBTZWN0aW9uIDkgKGltcGFj dHMgU2VjdGlvbiAxNCBhcyB3ZWxsKSA9ICJCRkNQIA0KPj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+PmNs aWVudHMgIFNIT1VMRCBhdXRoZW50aWNhdGUgdGhlIGZsb29yIGNvbnRyb2wgDQo+Pj4+Pj4+Pj4+ Pj4+Pj4+Pj4+Pj4+c2VydmVyIGJlZm9yZSAgc2VuZGluZyBhbnkgQkZDUCBtZXNzYWdlIHRvIGl0 IG9yIA0KPj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+PmFjY2VwdGluZyBhbnkgQkZDUCBtZXNzYWdlIGZy b20gaXQuDQo+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+IFNpbWlsYXJseSwgZmxvb3IgY29udHJvbCBz ZXJ2ZXJzIFNIT1VMRCANCj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj5hdXRoZW50aWNhdGUgYSBjbGll bnQgYmVmb3JlIGFjY2VwdGluZyBhbnkgQkZDUCANCj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj5tZXNz YWdlIGZyb20gaXQgb3Igc2VuZGluZyBhbnkgQkZDUCBtZXNzYWdlIHRvIGl0Lg0KPj4+Pj4+Pj4+ Pj4+Pj4+Pj4+Pj4+Pg0KPj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+PiBCRkNQIHN1cHBvcnRzIFRMUy9E VExTIG11dHVhbCBhdXRoZW50aWNhdGlvbiANCj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj5iZXR3ZWVu IGNsaWVudHMgYW5kIGZsb29yIGNvbnRyb2wgc2VydmVycywgYXMgDQo+Pj4+Pj4+Pj4+Pj4+Pj4+ Pj4+Pj4+c3BlY2lmaWVkIGluIFNlY3Rpb24gOS4xLg0KPj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+PiBU aGlzIGlzIHRoZSBSRUNPTU1FTkRFRCBhdXRoZW50aWNhdGlvbiBtZWNoYW5pc20gDQo+Pj4+Pj4+ Pj4+Pj4+Pj4+Pj4+Pj4+aW4gQkZDUC7Csg0KPj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pg0KPj4+Pj4+ Pj4+Pj4+Pj4+Pj4+Pj4+PiBXaGF0IGFyZSB0aGUgY2FzZXMgd2hlcmUgY2xpZW50cyBhbmQgc2Vy dmVycyBkbyANCj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj5ub3QgbmVlZCAgdG8gYmUgYXV0aGVudGlj YXRpbmcgZWFjaCBvdGhlcj8gSSBrbm93IA0KPj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+PnRoaXMgcmVx dWlyZW1lbnQgIGFuZCB0aGUgb3RoZXIgU0hPVUxELWxldmVsIA0KPj4+Pj4+Pj4+Pj4+Pj4+Pj4+ Pj4+PnJlcXVpcmVtZW50cyBhcm91bmQgdXNlIG9mICBUTFMvRFRMUyBhcmUgY2FycmllZCANCj4+ Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj5vdmVyIGZyb20gUkZDIDQ1ODIsIGJ1dCBJwrltICBjb25jZXJu ZWQgdGhhdCB0aGV5IA0KPj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+PmFyZW7CuXQgYXMgc3Ryb25nIGFz IHRoZXkgc2hvdWxkIGJlLg0KPj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+PiBGb3IgYSBjb25mZXJlbmNl IHdoZXJlIHRoZSBzaWduYWxpbmcgdHJhZmZpYyBpcyANCj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj5h dXRoZW50aWNhdGVkIGFuZCBjb25maWRlbnRpYWxpdHkgYW5kIGludGVncml0eSANCj4+Pj4+Pj4+ Pj4+Pj4+Pj4+Pj4+Pj5wcm90ZWN0ZWQsIHdoeSBpcyBpdCBvayBmb3IgdGhlIGZsb29yIGNvbnRy b2wgDQo+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+dHJhZmZpYyBub3QgdG8gYmU/IENvdWxkIHRoZXNl IHJlcXVpcmVtZW50cyBiZSANCj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj5hZGp1c3RlZCB0byByZXF1 aXJlIHVzZSBvZiBUTFMvRFRMUyBhdCBsZWFzdCBpbiANCj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj5j YXNlcyB3aGVyZSB0aGUgc2lnbmFsaW5nIGlzIGFsc28gcHJvdGVjdGVkPw0KPj4+Pj4+Pj4+Pj4+ Pj4+Pj4+Pj4+Pg0KPj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pg0KPj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+ IFllcywgYnV0IGFnYWluLCB0aGlzIHdvdWxkIGJlIGF0IHRoZSBleHBlbnNlIG9mIA0KPj4+Pj4+ Pj4+Pj4+Pj4+Pj4+Pj4+IGFkZGluZyBhIG5vbiBiYWNrd2FyZCBjb21wYXRpYmxlIGNoYW5nZSBm cm9tIHJmYyANCj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+PiA0NTgyLiBIb3cgYWJvdXQgc2F5aW5nIFRM Uy9EVExTIE1VU1QgYmUgdXNlZCBmb3IgDQo+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4gQkZDUCBpbiBz dWNoIGNhc2VzLCB3aGlsZSBwb2ludGluZyBvdXQgdGhlIHJmYw0KPj4+Pj4+Pj4+Pj4+Pj4+Pj4+ Pj4+IDQ1ODINCj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+PiBiYXNlZCBpbXBsZW1lbnRhdGlvbnMgbWF5 IG5vdCBjb21wbHkgKHNpbWlsYXIgdG8gDQo+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4gd2hhdCB3ZSBk aWQgd2l0aCB0aGUgdmVyc2lvbiBmaWVsZCkuDQo+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4NCj4+Pj4+ Pj4+Pj4+Pj4+Pj4+Pj4+Pg0KPj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4gV29ya3MgZm9yIG1lLg0KPj4+ Pj4+Pj4+Pj4+Pj4+Pj4+Pj4NCj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+IEZlZWwgZnJlZSB0byBtYWtl IGFsbCBvZiB0aGVzZSBjaGFuZ2VzIGFuZCBzdWJtaXQgYSANCj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+ IHJldiBhbmQgScK5bGwgaXNzdWUgdGhlIElFVEYgTEMuDQo+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pg0K Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4gVGhhbmtzLA0KPj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4gQWxpc3Nh DQo+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pg0KPj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4NCj4+Pj4+Pj4+Pj4+ Pj4+Pj4+Pj4+IA0KPj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+PiA9IFNlY3Rpb24gMTQgPQ0KPj4+Pj4+ Pj4+Pj4+Pj4+Pj4+Pj4+PiBTZWUgdGhlIHBvaW50IGFib3ZlIGFib3V0IGNpcGhlcnN1aXRlcy4g wrNOb24tbnVsbCANCj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4gZW5jcnlwdGlvbsKyIGlzIG5vdCBh IHN1ZmZpY2llbnQgbWluaW11bSBiYXNlbGluZSwgDQo+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+IGFu ZCBpZiB0aGUgcmVxdWlyZW1lbnRzIGNoYW5nZSBpbiBTZWN0aW9uIDcgdGhleSANCj4+Pj4+Pj4+ Pj4+Pj4+Pj4+Pj4+Pj4gc2hvdWxkIGJlIHJlZmxlY3RlZCBoZXJlIGFzIHdlbGwuDQo+Pj4+Pj4+ Pj4+Pj4+Pj4+Pj4+Pj4+DQo+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+DQo+Pj4+Pj4+Pj4+Pj4+Pj4+ Pj4+Pj4gWWVwLg0KPj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+DQo+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4N Cj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+PiANCj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4gRWRpdG9yaWFs IG5pdHMgdG8gYmUgcmVzb2x2ZWQgd2l0aCBMQyBjb21tZW50czoNCj4+Pj4+Pj4+Pj4+Pj4+Pj4+ Pj4+Pj4NCj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4gPSBTZWN0aW9uIDUuMSA9DQo+Pj4+Pj4+Pj4+ Pj4+Pj4+Pj4+Pj4+IMKzVGhlIHZlcnNpb24gZmllbGQgTVVTVCBiZSBzZXQgdG8gMSB3aGVuIHVz aW5nIA0KPj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+PiBCRkNQIG92ZXIgYSByZWxpYWJsZSB0cmFuc3Bv cnQsIGkuZS4gYXMgaW4gWzJdLsKyDQo+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+DQo+Pj4+Pj4+Pj4+ Pj4+Pj4+Pj4+Pj4+IEkgZmluZCBpdCBhIGxpdHRsZSBvZGQgdG8gcmVmZXJlbmNlIHRoZSBzcGVj IA0KPj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+PnlvdcK5cmUgb2Jzb2xldGluZyBpbiB0aGlzIHNlbnRl bmNlLCBlc3BlY2lhbGx5IA0KPj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+PnNpbmNlIEJGQ1Agb3ZlciBh IHJlbGlhYmxlIHRyYW5zcG9ydCBpcyBjb21wbGV0ZWx5IA0KPj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+ PnNwZWNpZmllZCBpbiB0aGlzIGJpcyBkb2N1bWVudC4gSSB3b3VsZCBzdWdnZXN0IA0KPj4+Pj4+ Pj4+Pj4+Pj4+Pj4+Pj4+PmRyb3BwaW5nDQp0aGUgaS5lLg0KPj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+ PmNsYXVzZS4NCj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4NCj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4N Cj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+PiBHb29kIGNhdGNoLiBUaGlzIGlzIGEgY2Fycnkgb3ZlciBm cm9tIGJlZm9yZSB0aGlzIA0KPj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+IGRyYWZ0IHdhcyBhZG9wdGVk IGFzIGEgYmlzIHZlcnNpb24gb2YgcmZjNDU4Mi4NCj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pg0KPj4+ Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+DQo+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4gDQo+Pj4+Pj4+Pj4+Pj4+ Pj4+Pj4+Pj4+ICJUaGUgdmVyc2lvbiBmaWVsZCBNVVNUIGJlIHNldCB0byAyIHdoZW4gdXNpbmcg DQo+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+IEJGQ1Agb3ZlciBhbiB1bnJlbGlhYmxlIHRyYW5zcG9y dCB3aXRoIHRoZSANCj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4gZXh0ZW5zaW9ucyBzcGVjaWZpZWQg aW4gdGhpcyBkb2N1bWVudC7Csg0KPj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pg0KPj4+Pj4+Pj4+Pj4+ Pj4+Pj4+Pj4+PiBUaGUgYml0IGFib3V0IMKzd2l0aCB0aGUgZXh0ZW5zaW9ucyBzcGVjaWZpZWQg aW4gDQo+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+IHRoaXMgZG9jdW1lbnTCsiBpcyBleHRyYW5lb3Vz IGFuZCBzaG91bGQgYmUgcmVtb3ZlZC4NCj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4NCj4+Pj4+Pj4+ Pj4+Pj4+Pj4+Pj4+Pj4gIklmIGFuIGVuZHBvaW50IHJlY2VpdmVzIGEgbWVzc2FnZSB3aXRoIGFu IA0KPj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+PiB1bnN1cHBvcnRlZCB2ZXJzaW9uIGZpZWxkIHZhbHVl LCB0aGUgcmVjZWl2aW5nIA0KPj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+PiBzZXJ2ZXIgTVVTVCBzZW5k IGFuIEVycm9yIG1lc3NhZ2Ugd2l0aCBwYXJhbWV0ZXIgDQo+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+ IHZhbHVlIDEyIChVbnN1cHBvcnRlZA0KPj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+PiBWZXJzaW9uKSB0 byBpbmRpY2F0ZSB0aGlzLsKyDQo+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+DQo+Pj4+Pj4+Pj4+Pj4+ Pj4+Pj4+Pj4+IFVzZSBvZiB0aGUgd29yZCDCs3NlcnZlcsKyIGhlcmUgbWFrZXMgaXQgc291bmQg YXMgDQo+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+aWYgb25seSBzZXJ2ZXJzIGNvdWxkIHJlY2VpdmUg aGVhZGVycyB3aXRoIA0KPj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+PnVuc3VwcG9ydGVkIHZlcnNpb25z Lg0KPj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+PiBTaG91bGQgdGhpcyBiZSDCs3RoZSByZWNlaXZpbmcg ZW5kcG9pbnTCsj8NCj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4NCj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+ Pj4gPSBTZWN0aW9uIDYuMi40ID0gIlsyM10sIFNlY3Rpb24gNi43IHByb3ZpZGVzIA0KPj4+Pj4+ Pj4+Pj4+Pj4+Pj4+Pj4+PiB1c2VmdWwgcmVjb21tZW5kYXRpb25zIMWgwrINCj4+Pj4+Pj4+Pj4+ Pj4+Pj4+Pj4+Pj4NCj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4gVGhlIGxpbmtzIGluIHRoZSByZWZl cmVuY2VzIGFyZSBub3QgcXVpdGUgcmlnaHQuDQo+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+DQo+Pj4+ Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+ID0gU2VjdGlvbiA4LjMuMiA9IHMvd2hlbiBmaXJlcy93aGVuIGZp cmVkLw0KPj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pg0KPj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+PiA9IFNl Y3Rpb24gMTQgPQ0KPj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+PiBzL2hpZ2gtamFjay9oaWphY2svDQo+ Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+DQo+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+ID0gU2VjdGlvbiBC LjEgPQ0KPj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+PiAic2l0dWF0aW9uIHdoZXJlIG11bHRpcGxlIGRp ZmZlcmVudCBhbmQgDQo+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+IG5vbi1pbnRlcm9wZXJhYmxlIHdv dWxkDQo+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+IGNvLQ0KPj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+PiBl eGlzdCBpbiB0aGUgbWFya2V0LsKyDQo+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+DQo+Pj4+Pj4+Pj4+ Pj4+Pj4+Pj4+Pj4+IFRoZXJlIGlzIGEgd29yZCBtaXNzaW5nIGFmdGVyIMKzbm9uLWludGVyb3Bl cmFibGUuIg0KPj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pg0KPj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+PiAN Cj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+PiBUaGlzIHNob3VsZCByZWFkIMKzbm9uLWludGVyb3BlcmFi bGUgaW1wbGVtZW50YXRpb25zwrIuDQo+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4gRWFybGllciBpbiB0 aGF0IHNhbWUgc2VudGVuY2UsIMKzQkZDUCBvdmVyIFVEUCB3ZXJlIA0KPj4+Pj4+Pj4+Pj4+Pj4+ Pj4+Pj4+YWxyZWFkeSB1c2VkwrIgc2hvdWxkIHJlYWQgwrNCRkNQIG92ZXIgVURQIGlzIGFscmVh ZHkgDQo+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj5iZWluZyB1c2VkwrIuDQo+Pj4+Pj4+Pj4+Pj4+Pj4+ Pj4+Pj4NCj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+PiBDaGVlcnMsDQo+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+ Pj4gQ2hhcmxlcw0KPj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+DQo+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4g IA0KPj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4gX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX18NCj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+IGJmY3BiaXMgbWFpbGluZyBsaXN0 IA0KPj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4gYmZjcGJpc0BpZXRmLm9yZzxtYWlsdG86YmZjcGJpc0Bp ZXRmLm9yZz4NCj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+IGh0dHBzOi8vd3d3LmlldGYub3JnL21haWxt YW4vbGlzdGluZm8vYmZjcGJpcw0KPj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4NCj4+Pj4+Pj4+Pj4+Pj4+ Pj4+Pj4+ICAgDQo+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+DQo+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+ICAgIA0K Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+DQo+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4gICAgIA0KPj4+Pj4+Pj4+Pj4+ Pj4+Pj4NCj4+Pj4+Pj4+Pj4+Pj4+Pj4+ICAgICAgDQo+Pj4+Pj4+Pj4+Pj4+Pj4+DQo+Pj4+Pj4+ Pj4+Pj4+Pj4+ICAgICAgIA0KPj4+Pj4+Pj4+Pj4+Pj4+DQo+Pj4+Pj4+Pj4+Pj4+Pj4gICAgICAg IA0KPj4+Pj4+Pj4+Pj4+Pj4NCj4+Pj4+Pj4+Pj4+Pj4+ICAgICAgICAgDQo+Pj4+Pj4+Pj4+Pj4+ DQo+Pj4+Pj4+Pj4+Pj4+ICAgICAgICAgIA0KPj4+Pj4+Pj4+Pj4+DQo+Pj4+Pj4+Pj4+Pj4gICAg ICAgICAgIA0KPj4+Pj4+Pj4+Pj4NCj4+Pj4+Pj4+Pj4+ICAgICAgICAgIA0KPj4+Pj4+Pj4+DQo+ Pj4+Pj4+Pj4gICAgICANCj4+Pj4+Pj4+ICAgIA0KPj4+Pj4+Pg0KPj4+Pj4+DQo+Pj4+Pj5fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KPj4+Pj4+YmZjcGJp cyBtYWlsaW5nIGxpc3QNCj4+Pj4+PmJmY3BiaXNAaWV0Zi5vcmcNCj4+Pj4+Pmh0dHBzOi8vd3d3 LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vYmZjcGJpcw0KPj4+Pj4NCj4+Pj4NCj4+Pg0KPj4N Cj4NCj5fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KPmJm Y3BiaXMgbWFpbGluZyBsaXN0DQo+YmZjcGJpc0BpZXRmLm9yZw0KPmh0dHBzOi8vd3d3LmlldGYu b3JnL21haWxtYW4vbGlzdGluZm8vYmZjcGJpcw0KDQo= From nobody Sun Nov 1 23:45:37 2015 Return-Path: X-Original-To: bfcpbis@ietfa.amsl.com Delivered-To: bfcpbis@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 87DCD1B33F8 for ; Sun, 1 Nov 2015 23:45:36 -0800 (PST) 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 0mbjAob6mDgK for ; Sun, 1 Nov 2015 23:45:29 -0800 (PST) Received: from aer-iport-4.cisco.com (aer-iport-4.cisco.com [173.38.203.54]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E33071B3430 for ; Sun, 1 Nov 2015 23:45:27 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=47277; q=dns/txt; s=iport; t=1446450328; x=1447659928; h=message-id:date:from:mime-version:to:cc:subject: references:in-reply-to:content-transfer-encoding; bh=pf4CC/cdxOTKS8Ksv1qQ2qjl9aBB0tJ69W1f481JPcM=; b=WYKSlJy7yt1taQQaQ9mHBczhXru/DpaxPaUPr5vS309vZTYi5gzoAr8a L/7sH9wDIyJiN8XQ6y9d+gVFZ/DkifHhh4ukj/1M5GWXSOLded5LqKvoK E3Nug7YkauXLGO7wMNPzVIfSqSSFDUHNWX9CvOvgKF5QZMbY+Jtp9UA4u c=; X-IronPort-AV: E=Sophos;i="5.20,233,1444694400"; d="scan'208";a="607916935" Received: from aer-iport-nat.cisco.com (HELO aer-core-4.cisco.com) ([173.38.203.22]) by aer-iport-4.cisco.com with ESMTP; 02 Nov 2015 07:45:26 +0000 Received: from [10.54.90.26] (dhcp-10-54-90-26.cisco.com [10.54.90.26]) by aer-core-4.cisco.com (8.14.5/8.14.5) with ESMTP id tA27jPBU009254; Mon, 2 Nov 2015 07:45:25 GMT Message-ID: <56371495.7080105@cisco.com> Date: Mon, 02 Nov 2015 08:45:25 +0100 From: Tom Kristensen Organization: Cisco User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.1.15) Gecko/20101027 Fedora/3.0.10-1.fc12 Lightning/1.0b2pre Thunderbird/3.0.10 MIME-Version: 1.0 To: Christer Holmberg References: <7594FB04B1934943A5C02806D1A2204B37BC8F7B@ESESSMB209.ericsson.se> In-Reply-To: <7594FB04B1934943A5C02806D1A2204B37BC8F7B@ESESSMB209.ericsson.se> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit Archived-At: Cc: Ben Campbell , "bfcpbis@ietf.org" , Alissa Cooper , "Charles Eckel \(eckelcu\)" , Gonzalo Camarillo , "draft-ietf-bfcpbis-rfc4582bis@tools.ietf.org" Subject: Re: [bfcpbis] Status update on draft-ietf-mmusic-dtls-sdp [was: draft-ietf-bfcpbis-rfc4583bis] X-BeenThere: bfcpbis@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: BFCPBIS working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 02 Nov 2015 07:45:36 -0000 Perfect! I'll update and polish the draft as discussed and agreed upon below and submit. -- Tom On 11/02/2015 08:04 AM, Christer Holmberg wrote: > Hi, > > draft-ietf-mmusic-dtls-sdp was discussed at MMUSIC today. > > At this moment there are no technical open issues. The plan is to add some editorial work, based on comments received during the session, and the add text regarding DTLS-usage drafts/specs that the draft updates. After that, unless something unexpected comes up, the draft should be ready for WGLC. > > Regards, > > Christer > > > > -----Original Message----- > From: Charles Eckel (eckelcu) [mailto:eckelcu@cisco.com] > Sent: 28 September 2015 18:50 > To: Christer Holmberg; Tom Kristensen (tomkrist) > Cc: Alissa Cooper; bfcpbis@ietf.org; draft-ietf-bfcpbis-rfc4582bis@tools.ietf.org; Gonzalo Camarillo; Ben Campbell > Subject: Re: [bfcpbis] draft-ietf-bfcpbis-rfc4583bis > > Thanks Christer. > > Tom, can you please post the corresponding update to the draft? > > Cheers, > Charles > > On 9/28/15, 3:07 AM, "bfcpbis on behalf of Christer Holmberg" > > wrote: > > >> Hi, >> >> >>> In that case, I prefer Tom’s original suggestion, >>> >>> What if we keep the text and adds this as an additional reference >>> in the two new text passages proposed by Charles: "... [13], and the >>> clarifications defined in [draft-ietf-mmusic-dtls-sdp], ...". >>> >>> Where [13] is a reference to RFC 5763. >>> >> If that's something people can agree to, then can live with such >> compromise :) >> >> Regards, >> >> Christer >> >> >> >> >> >> If it turns out that draft-ietf-mmusic-dtls-sdp updates RFC 5763, then >> there is some redundancy. But that is better than having a hole when it >> comes to backward compatibility with existing implementations, which is >> what we will have today if we reference draft-ietf-mmusic-dtls-sdp only. >> >> Cheers, >> Charles >> >> >> >> On 9/25/15, 2:21 AM, "Christer Holmberg" >> >> wrote: >> >> >>> Hi Charles, >>> >>> >>>> As a simple example, we currently refer to rfc4582bis instead of the >>>> eventual RFC. Assuming rfc4582bis does become an RFC, we would want >>>> the RFC editor to update references to it and to RFCxxxx with the >>>> actual RFC number. >>>> Similar here, we would want them to check with authors/chairs/ADs on >>>> the state of draft-ietf-mmusic-dtls-sdp to see if we want to replace >>>> our reference to RFC 5763 with a reference to it. This way we can >>>> move forward while draft-ietf-mmusic-dtls-sdp continues to progress >>>> as well. >>>> >>> I don't think it's the same thing. First you talk about a draft, where >>> the draft name will be replaced with the to-be-assigned RFC number. In >>> the case of DTLS-SDP we are talking about two separate specifications. >>> >>> Regards, >>> >>> Christer >>> >>> >>> On 9/24/15, 2:53 AM, "Christer Holmberg" >>> >>> wrote: >>> >>> >>>> Hi Charles, >>>> >>>> I am still not sure I understand your suggestion: what is meant by >>>> "as determined prior to publication"? When/where/who? :) >>>> >>>> Regards, >>>> >>>> Christer >>>> >>>> -----Original Message----- >>>> From: Charles Eckel (eckelcu) [mailto:eckelcu@cisco.com] >>>> Sent: 22. syyskuuta 2015 17:05 >>>> To: Christer Holmberg; Tom Kristensen (tomkrist) >>>> Cc: draft-ietf-bfcpbis-rfc4582bis@tools.ietf.org; bfcpbis@ietf.org; >>>> Alissa Cooper; Gonzalo Camarillo; Ben Campbell >>>> Subject: Re: [bfcpbis] draft-ietf-bfcpbis-rfc4583bis >>>> >>>> I view referring to draft-ietf-mmusic-dtls-sdp now instead of RFC >>>> 5763 to be like writing a blank check. Debate is actively occurring >>>> on the list, the normative language in RFC 5763 is expected to be >>>> updated in multiple ways, and backward compatibility with the the >>>> normative language provide in previous version of rfc4583bis is not >>>> fully addressed. It seems more appropriate to me at this stage to >>>> continue to refer to RFC 5763 with a note regarding updating or >>>> replacing that reference with one to draft-ietf-mmusic-dtls-sdp, as >>>> determined prior to publication. >>>> >>>> Cheers, >>>> Charles >>>> >>>> On 9/21/15, 11:48 PM, "Christer Holmberg" >>>> >>>> wrote: >>>> >>>> >>>>> Hi, >>>>> >>>>> >>>>>> I see. As this is a moving target, perhaps where we reference RFC >>>>>> 5763 we can add a note for the RFC editor that >>>>>> draft-ietf-mmusic-dtls-sdp is expected to add clarifications and >>>>>> make changes to RFC 5763 that should be considered prior to >>>>>> publication of rfc4583bis. >>>>>> >>>>> I am not sure I understand. I don't think it's up to the RFC editor >>>>> to make a decision whether the draft should reference DTLS-SDP. >>>>> >>>>> Regards, >>>>> >>>>> Christer >>>>> >>>>> >>>>> >>>>> On 9/21/15, 11:23 AM, "Christer Holmberg" >>>>> >>>>> wrote: >>>>> >>>>> >>>>>> Hi, >>>>>> >>>>>> >>>>>>> RFC 5763, which is currently required for BFCP with DTLS reads: >>>>>>> >>>>>>> o The endpoint MUST NOT use the connection attribute defined in >>>>>>> [RFC4145]. >>>>>>> >>>>>> Correct. >>>>>> >>>>>> And, IF we decide to use define usage of the 'connection' attribute >>>>>> for DTLS, we would change that. >>>>>> >>>>>> However, a few days ago we sent an e-mail to the MMUSIC list, >>>>>> suggesting that we should NOT use the 'connection' attribute for DTLS. >>>>>> Instead we should define a new attribute (for more details, please >>>>>> see the MMUSIC list). >>>>>> >>>>>> >>>>>>> Section 5.1 of draft-ietf-mmusic-dtls-sdp reads: >>>>>>> >>>>>>> When used with DTLS, there is no default value defined for the >>>>>>> attribute. Implementations that wish to use the attribute MUST >>>>>>> explicitly include it in SDP offers and answers. If an offer or >>>>>>> answer does not contain an attribute, other means needs to be >>>>>>> used in >>>>>>> order for endpoints to determine whether an offer or answer is >>>>>>> associated with an event that requires the DTLS association to >>>>>>> be >>>>>>> re- >>>>>>> established. >>>>>>> >>>>>>> I suppose if draft-ietf-mmusic-dtls-sdp pulls in enough from RFC >>>>>>> 5763 to make it clear how the DTLS establishment and >>>>>>> re-establishment works for the case of which the connection >>>>>>> attribute is not used, then we can change the reference from RFC >>>>>>> 5763 to draft-ietf-mmusic-dtls-sdp. >>>>>>> >>>>>>> The last several updates of draft-ietf-bfcpbis-rfc4583bis have >>>>>>> removed supporting text from the draft in favor of pointing to RFC >>>>>>> 5763 as the source of truth. I fear that >>>>>>> draft-ietf-mmusic-dtls-sdp in its current state does not serve >>>>>>> that need for draft-ietf-bfcpbis-rfc4583bis. I value Christer’s >>>>>>> thoughts and welcome the opinion of others, especially those who >>>>>>> have or are implementing BFCP with DTLS and ICE, which I have not. >>>>>>> >>>>>> Please note that DTLS-SDP does not only define usage of the >>>>>> 'connection' >>>>>> attribute, it also does other things. Maybe more important, it does >>>>>> not state that an address change by default requires a new DTLS >>>>>> association >>>>>> - which is a another 5763 modification. >>>>>> >>>>>> Regards, >>>>>> >>>>>> Christer >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> On 9/21/15, 9:32 AM, "bfcpbis on behalf of Christer Holmberg" >>>>>> >>>>> christer.holmberg@ericsson.com> >>>>>> wrote: >>>>>> >>>>>> >>>>>>> Hi Charles, >>>>>>> >>>>>>> >>>>>>>> The problem I see with this is that it is not just a matter of >>>>>>>> changing the reference, it is also a matter of changing the >>>>>>>> normative behavior. >>>>>>>> For DTLS with BFCP, we never required the use of the>“connection” >>>>>>>> attribute. >>>>>>>> If we are to start requiring it, we would need add text to >>>>>>>> describe how to address backward compatibility in cases in which >>>>>>>> the connection attribute is not specified. >>>>>>>> >>>>>>> The intention is to cover backward compatibility in the draft. >>>>>>> >>>>>>> >>>>>>>> Are there plans for this within RFC 5763bis draft? If so, Tom’s >>>>>>>> recommendation of continuing to point to RFC 5763 for now may be >>>>>>>> the best approach. >>>>>>>> >>>>>>> I am not familiar with the 5763bis draft. But, even if the >>>>>>> DTLS-SDP draft makes updates to 5763, it won't become a 5763bis draft. >>>>>>> >>>>>>> Regards, >>>>>>> >>>>>>> Christer >>>>>>> >>>>>>> >>>>>>> >>>>>>> On 9/11/15, 1:11 PM, "Christer Holmberg" >>>>>>> >>>>>>> wrote: >>>>>>> >>>>>>> >>>>>>>> Hi, >>>>>>>> >>>>>>>> >>>>>>>>> Hmm, yes maybe an idea if it's fine proceeding with referring a >>>>>>>>> work-in-progress draft here. >>>>>>>>> What if we keep the text and adds this as an additional >>>>>>>>> reference in the two new text passages proposed by Charles: "... >>>>>>>>> [13], and the clarifications defined in [draft-ietf-mmusic-dtls-sdp], ...". >>>>>>>>> >>>>>>>>> Where [13] is a reference to RFC 5763. >>>>>>>>> >>>>>>>> My suggestion is to *only* refer the new dtls-sdp draft. Because, >>>>>>>> one of the ideas with the new draft is to also update RFC 5763 to >>>>>>>> reference the new dtls-sdp draft. >>>>>>>> >>>>>>>> >>>>>>>>> Anyway, I'd still prefer to keep the text in >>>>>>>>> draft-ietf-bfcpbis-rfc4583bis-12 and redirect the readers to the >>>>>>>>> rfc5763bis, that eventually then will obsolete (or extend?) RFC >>>>>>>>> 5763. >>>>>>>>> >>>>>>>> The new dtls-sdp draft will not become 5763bis (eventhough it MAY >>>>>>>> update some parts of 5763). It's a generic document, which *any* >>>>>>>> DTLS usage can then reference. >>>>>>>> >>>>>>>> Regards, >>>>>>>> >>>>>>>> Christer >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> On 09/11/2015 01:25 PM, Christer Holmberg wrote: >>>>>>>> >>>>>>>>> Hi, >>>>>>>>> >>>>>>>>> My suggestion would actually be to refer to the new >>>>>>>>> draft-ietf-mmusic-dtls-sdp, which is going to clarify the >>>>>>>>> DTLS-SRTP rules regarding when a new DTLS association must be >>>>>>>>> established. >>>>>>>>> >>>>>>>>> Regards, >>>>>>>>> >>>>>>>>> Christer >>>>>>>>> >>>>>>>>> -----Original Message----- >>>>>>>>> From: Tom Kristensen [mailto:tomkrist@cisco.com] >>>>>>>>> Sent: 11. syyskuuta 2015 13:25 >>>>>>>>> To: Charles Eckel (eckelcu) >>>>>>>>> Cc: Christer Holmberg; Alissa Cooper; Gonzalo Camarillo; >>>>>>>>> draft-ietf-bfcpbis-rfc4582bis@tools.ietf.org; Ben Campbell; >>>>>>>>> bfcpbis@ietf.org >>>>>>>>> Subject: Re: draft-ietf-bfcpbis-rfc4583bis >>>>>>>>> >>>>>>>>> Pointing to the DTLS-SRTP (and by that any updates of it) is a >>>>>>>>> simple, safe and straigt-forward solution. >>>>>>>>> >>>>>>>>> The only change in the new version of rfc4583bis just submitted. >>>>>>>>> And as Charles says, this should be the last missing fix for >>>>>>>>> this draft until next stages in the process at least. >>>>>>>>> >>>>>>>>> -- Tom >>>>>>>>> >>>>>>>>> On 09/08/2015 07:48 PM, Charles Eckel (eckelcu) wrote: >>>>>>>>> >>>>>>>>> >>>>>>>>>> Picking up on this old thread regarding >>>>>>>>>> draft-ietf-bfcpbis-rfc4583bis. >>>>>>>>>> I think this is the only outstanding item with respect to the >>>>>>>>>> current version of the draft. Unless anyone has an issue with >>>>>>>>>> the proposed resolution, I request we update the draft >>>>>>>>>> accordingly and then use it as the basis for Mary, the >>>>>>>>>> document shepherd, to provide a proto writeup. >>>>>>>>>> >>>>>>>>>> Cheers, >>>>>>>>>> Charles >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> On 4/20/15, 10:39 AM, "Charles Eckel >>>>>>>>>> (eckelcu)" >>>>>>>>>> wrote: >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>>> Hi Christer, >>>>>>>>>>> >>>>>>>>>>> I reread the current draft and went through the following >>>>>>>>>>> MMUSIC thread on this subject: >>>>>>>>>>> http://www.ietf.org/mail-archive/web/mmusic/current/msg14631. >>>>>>>>>>> h >>>>>>>>>>> t >>>>>>>>>>> m >>>>>>>>>>> l >>>>>>>>>>> >>>>>>>>>>> As a result, I better understand the issue you are addressing. >>>>>>>>>>> I suggest the following changes to be consistent with what is >>>>>>>>>>> being proposed in >>>>>>>>>>> MMUSIC: >>>>>>>>>>> >>>>>>>>>>> ------------ >>>>>>>>>>> Section 9: >>>>>>>>>>> >>>>>>>>>>> OLD: >>>>>>>>>>> Endpoints that use the offer/answer model to establish a DTLS >>>>>>>>>>> association MUST support the 'setup' attribute, as >>>>>>>>>>> defined in [7]. >>>>>>>>>>> When DTLS is used with UDP, the 'setup' attribute indicates >>>>>>>>>>> which of the endpoints (client or floor control server) >>>>>>>>>>> initiates the DTLS association setup. The requirements for the >>>>>>>>>>> offer/answer exchange specified in [13], Section 5 of [13] >>>>>>>>>>> MUST be followed when using DTLS. >>>>>>>>>>> Offer/answer considerations are described in Section 10.5. >>>>>>>>>>> >>>>>>>>>>> NEW: >>>>>>>>>>> When DTLS is used with UDP, the requirements specified in >>>>>>>>>>> Section >>>>>>>>>>> 5 of [13] MUST be followed. >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> Section 10.5 >>>>>>>>>>> >>>>>>>>>>> OLD >>>>>>>>>>> If the transport parameters or the key fingerprints >>>>>>>>>>> change, the >>>>>>>>>>> endpoints MUST establish a new DTLS connection. In such >>>>>>>>>>> case the >>>>>>>>>>> 'active/passive' status of the endpoints will again be >>>>>>>>>>> determined >>>>>>>>>>> following the procedures in [7], and the new status will >>>>>>>>>>> be used to >>>>>>>>>>> determine the TLS roles associated with the new DTLS >>>>>>>>>>> connection. >>>>>>>>>>> >>>>>>>>>>> Informational note: The procedure above is identical >>>>>>>>>>> to the one >>>>>>>>>>> defined for DTLS-SRTP in [13]. >>>>>>>>>>> >>>>>>>>>>> Note: A new DTLS connection needs to be established if >>>>>>>>>>> the >>>>>>>>>>> transport parameters or the key fingerprints change. >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> NEW: >>>>>>>>>>> The conditions under which endpoints MUST establish a new >>>>>>>>>>> DTLS connection are as the same defined for DTLS-SRTP in [13]. >>>>>>>>>>> ———————— >>>>>>>>>>> >>>>>>>>>>> This way we avoid any potential conflicts with the intent of >>>>>>>>>>> RFC 5763, and when clarifications to RFC 5763 are made, they >>>>>>>>>>> will be picked up by the BFCP spec. >>>>>>>>>>> >>>>>>>>>>> Cheers, >>>>>>>>>>> Charles >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> On 4/18/15, 2:01 PM, "Christer >>>>>>>>>>> Holmberg" >>>>>>>>>>> wrote: >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>>> Hi Charles, >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>>> [adding bfcppbis list] >>>>>>>>>>>>> >>>>>>>>>>>>> Hi Christer, >>>>>>>>>>>>> >>>>>>>>>>>>> Thanks for your review and comments. In the BFCP usage, the >>>>>>>>>>>>> DTLS connection is dedicated to the BFCP stream it contains. >>>>>>>>>>>>> As I understand it, the complications around DTLS >>>>>>>>>>>>> re-establishement discussed in MMUSIC result from use of a >>>>>>>>>>>>> single DTLS connection for multiple RTP and/or SCTP streams. >>>>>>>>>>>>> Those complications do not exist with the BFCP usage, so I >>>>>>>>>>>>> think it is sufficient to continue to reference RFC 5763 and >>>>>>>>>>>>> not use the SDP connection attribute. >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>> The complications do not result from use of a single DTLS >>>>>>>>>>>> connection for multiple streams - it mainly results from the >>>>>>>>>>>> usage of ICE. And, as far as I know, ICE can be used also for >>>>>>>>>>>> BFCP. >>>>>>>>>>>> >>>>>>>>>>>> And, even without ICE we intend to add text saying that a >>>>>>>>>>>> DTLS connection is only re-established if the underlying >>>>>>>>>>>> transport changes. >>>>>>>>>>>> >>>>>>>>>>>> Regards, >>>>>>>>>>>> >>>>>>>>>>>> Christer >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>>> Hi, >>>>>>>>>>>>> >>>>>>>>>>>>> First, I want to apologize for not providing my review >>>>>>>>>>>>> earlier. >>>>>>>>>>>>> >>>>>>>>>>>>> As far as the BFCP specifics are concerned, I am ok with >>>>>>>>>>>>> the latest version of the draft. >>>>>>>>>>>>> >>>>>>>>>>>>> However, there is an issue regarding the DTLS >>>>>>>>>>>>> considerations (section 10.5). >>>>>>>>>>>>> >>>>>>>>>>>>> The text says: >>>>>>>>>>>>> >>>>>>>>>>>>> "Once a DTLS connection has been established, if the >>>>>>>>>>>>> 'active/passive' >>>>>>>>>>>>> status of the endpoints change during a session, a new >>>>>>>>>>>>> DTLS >>>>>>>>>>>>> connection MUST be established." >>>>>>>>>>>>> >>>>>>>>>>>>> There is currently an ongoing discussion in MMUSIC about >>>>>>>>>>>>> when a DTLS connection is to be re-established. >>>>>>>>>>>>> >>>>>>>>>>>>> The discussion is still ongoing, but the outcome will most >>>>>>>>>>>>> likely NOT be aligned with the text above. >>>>>>>>>>>>> >>>>>>>>>>>>> For example, there has been a suggestion (by myself) to use >>>>>>>>>>>>> the SDP connection attribute to explicitly indicate that a >>>>>>>>>>>>> new DTLS connection needs to be established. >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> The draft also says: >>>>>>>>>>>>> >>>>>>>>>>>>> "If the transport parameters or the key fingerprints >>>>>>>>>>>>> change, the >>>>>>>>>>>>> endpoints MUST establish a new DTLS connection." >>>>>>>>>>>>> >>>>>>>>>>>>> This is related to the earlier issue. There is the >>>>>>>>>>>>> discussion about ICE "virtual connections", and that a >>>>>>>>>>>>> single DTLS connection would apply to all ICE candidates >>>>>>>>>>>>> associated with an >>>>>>>>>>>>> m- line. So, even if a candidate changes (read: transport >>>>>>>>>>>>> parameter changes), it would not automatically trigger a new >>>>>>>>>>>>> DTLS connection. >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> The issues above are also holding up the SCTP-SDP draft, so >>>>>>>>>>>>> it doesn't only affect BFCPbis :) >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> Regards, >>>>>>>>>>>>> >>>>>>>>>>>>> Christer >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> -----Original Message----- >>>>>>>>>>>>> From: Alissa Cooper [mailto:alissa@cooperw.in] >>>>>>>>>>>>> Sent: 8. huhtikuuta 2015 3:07 >>>>>>>>>>>>> To: Charles Eckel (eckelcu) >>>>>>>>>>>>> Cc: Gonzalo Camarillo; Tom Kristensen (tomkrist); >>>>>>>>>>>>> draft-ietf-bfcpbis-rfc4582bis@tools.ietf.org; Ben Campbell; >>>>>>>>>>>>> Christer Holmberg >>>>>>>>>>>>> Subject: Re: draft-ietf-bfcpbis-rfc4583bis >>>>>>>>>>>>> >>>>>>>>>>>>> Adding Christer to this thread. >>>>>>>>>>>>> >>>>>>>>>>>>> On Apr 7, 2015, at 12:44 PM, Charles Eckel (eckelcu) >>>>>>>>>>>>> >>>>>>>>>>>>> wrote: >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>>> Christer (cc’d) and I discussed some of the changes >>>>>>>>>>>>>> offlist in Dallas, and he is to come back to the list with >>>>>>>>>>>>>> comments after Dallas >>>>>>>>>>>>>> - which is now :) >>>>>>>>>>>>>> >>>>>>>>>>>>>> Cheers, >>>>>>>>>>>>>> Charles >>>>>>>>>>>>>> >>>>>>>>>>>>>> On 4/7/15, 10:26 AM, "Alissa Cooper" >>>>>>>>>>>>>> wrote: >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>>> Checking in on this — has Christer been prompted to >>>>>>>>>>>>>>> review the latest rev of draft-ietf-bfcpbis-rfc4583bis? >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> Thanks, >>>>>>>>>>>>>>> Alissa >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> On Feb 25, 2015, at 9:14 AM, Charles Eckel (eckelcu) >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> wrote: >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> Most of the changes I this recent update to rfc4583bis >>>>>>>>>>>>>>>> were inspired by comments and suggested text provided by >>>>>>>>>>>>>>>> Christer. >>>>>>>>>>>>>>>> He is in the process of reviewing. If all goes well with >>>>>>>>>>>>>>>> that, we are ready to proceed with proto writeup (Mary) >>>>>>>>>>>>>>>> and AD review. >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> Cheers, >>>>>>>>>>>>>>>> Charles >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> On 2/25/15, 7:01 AM, "Alissa Cooper" >>>>>>>>>>>>>>>> wrote: >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> rfc4583 has not had an AD review yet. Richard can >>>>>>>>>>>>>>>>> hopefully take care of that while I¹m on leave (starting >>>>>>>>>>>>>>>>> today, actually). >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> On Feb 25, 2015, at 2:56 AM, Gonzalo Camarillo >>>>>>>>>>>>>>>>> wrote: >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> Hi Alissa, >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> I have noted that while rfc4582bis in on the agenda of >>>>>>>>>>>>>>>>>> the March 5th telechat (thanks for handling that!), >>>>>>>>>>>>>>>>>> rfc4583bis isn't. Tom revised rfc4583bis on February >>>>>>>>>>>>>>>>>> 20th. Should rfc4583bis be on the agenda of the >>>>>>>>>>>>>>>>>> telechat as well or there is still something left for >>>>>>>>>>>>>>>>>> Tom to take care of? >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> Thanks, >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> Gonzalo >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> On 18/02/2015 9:28 PM, Alissa Cooper wrote: >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>> Pinging on this. >>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>> March 5 will likely be my last telechat before going >>>>>>>>>>>>>>>>>>> on leave, so it would be great to get this scheduled >>>>>>>>>>>>>>>>>>> on that one. To do that, the rev needs to be posted >>>>>>>>>>>>>>>>>>> today. >>>>>>>>>>>>>>>>>>> The updates are pretty minimal and are all basically >>>>>>>>>>>>>>>>>>> written up in Charles¹ response to my AD review. >>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>> Alissa >>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>> On Feb 15, 2015, at 9:13 AM, Gonzalo Camarillo >>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>>> wrote: >>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>> I have talked offline with the other authors and Tom >>>>>>>>>>>>>>>>>>>> is holding the pen. Tom, do you think you can meet >>>>>>>>>>>>>>>>>>>> the time frame below? >>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>> Cheers, >>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>> Gonzalo >>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>> Sent from my mobile >>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>> ---- Alissa Cooper wrote ---- >>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>> Just wanted to see if this rev might get done in the >>>>>>>>>>>>>>>>>>>> next couple of days. If so, we could get it on the >>>>>>>>>>>>>>>>>>>> next telechat agenda (March 5). >>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>> Alissa >>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>> Begin forwarded message: >>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>> *From: *Alissa Cooper>>>>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>>>>> *Subject: **Re: [bfcpbis] AD evaluation: >>>>>>>>>>>>>>>>>>>>> draft-ietf-bfcpbis-rfc4582bis-12* >>>>>>>>>>>>>>>>>>>>> *Date: *February 9, 2015 at 3:58:52 PM PST >>>>>>>>>>>>>>>>>>>>> *To: *"Charles Eckel (eckelcu)">>>>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>>>>> *Cc: *"bfcpbis@ietf.org" >>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>> Hi Charles, >>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>> Thanks, some responses inline. >>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>> On Feb 4, 2015, at 10:40 AM, Charles Eckel (eckelcu) >>>>>>>>>>>>>>>>>>>>> > wrote: >>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>> HI Alissa, >>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>> Thank you for the review. Please see my thoughts >>>>>>>>>>>>>>>>>>>>>> on your comments and questions inline. >>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>> From: Alissa Cooper>>>>>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>>>>>> Date: Thursday, January 29, 2015 at 10:19 PM >>>>>>>>>>>>>>>>>>>>>> To: "bfcpbis@ietf.org" >>>>>>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>>>>>> Subject: [bfcpbis] AD evaluation: >>>>>>>>>>>>>>>>>>>>>> draft-ietf-bfcpbis-rfc4582bis-12 >>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>> I have reviewed this draft in preparation for IETF LC. >>>>>>>>>>>>>>>>>>>>>>> Overall the document appears in good shape. I >>>>>>>>>>>>>>>>>>>>>>> have a few questions and comments I¹d like to >>>>>>>>>>>>>>>>>>>>>>> discuss before issuing the IETF last call. I¹ve >>>>>>>>>>>>>>>>>>>>>>> also included some editorial nits that should be >>>>>>>>>>>>>>>>>>>>>>> addressed together with any last call comments. >>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>> Comments and questions: >>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>> = Section 5.1 = >>>>>>>>>>>>>>>>>>>>>>> "If an endpoint receives a message with an >>>>>>>>>>>>>>>>>>>>>>> unsupported version field value, the receiving >>>>>>>>>>>>>>>>>>>>>>> server MUST send an Error message with parameter >>>>>>>>>>>>>>>>>>>>>>> value 12 (Unsupported >>>>>>>>>>>>>>>>>>>>>>> Version) to indicate this.² >>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>> This seems a little misleading since RFC 4582 >>>>>>>>>>>>>>>>>>>>>>> didn¹t specify what to do upon receipt of a >>>>>>>>>>>>>>>>>>>>>>> message with a version other than 1. >>>>>>>>>>>>>>>>>>>>>>> Implementations that do not get upgraded to be >>>>>>>>>>>>>>>>>>>>>>> compliant with 4582bis (which could certainly >>>>>>>>>>>>>>>>>>>>>>> account for some of those that will not support >>>>>>>>>>>>>>>>>>>>>>> version 2) will therefore never send the error >>>>>>>>>>>>>>>>>>>>>>> specified here. >>>>>>>>>>>>>>>>>>>>>>> This seems like it should at least be noted >>>>>>>>>>>>>>>>>>>>>>> given the MUST-level requirement. The same applies >>>>>>>>>>>>>>>>>>>>>>> in Section 13.7. >>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>> Good point. I believe we made this a MUST because >>>>>>>>>>>>>>>>>>>>>> we were thinking in terms of implementations >>>>>>>>>>>>>>>>>>>>>> compliant with this bis version. >>>>>>>>>>>>>>>>>>>>>> Adding >>>>>>>>>>>>>>>>>>>>>> your suggested note about rfc 4582 implementations >>>>>>>>>>>>>>>>>>>>>> here and in section 13.7 seems useful to me. >>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>> Ok >>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>> = Section 7 = >>>>>>>>>>>>>>>>>>>>>>> "BFCP entities MUST support, at a minimum, the >>>>>>>>>>>>>>>>>>>>>>> TLS_RSA_WITH_AES_128_CBC_SHA ciphersuite [6].² >>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>> I realize this requirement comes from RFC 4582, >>>>>>>>>>>>>>>>>>>>>>> but I¹d like to understand why it has not been >>>>>>>>>>>>>>>>>>>>>>> updated to be consistent with more current >>>>>>>>>>>>>>>>>>>>>>> guidance on cipher suite selection (e.g., >>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>> https://tools.ietf.org/html/draft-ietf-uta-tls-bc >>>>>>>>>>>>>>>>>>>>>>> p >>>>>>>>>>>>>>>>>>>>>>> - >>>>>>>>>>>>>>>>>>>>>>> 0 >>>>>>>>>>>>>>>>>>>>>>> 8 >>>>>>>>>>>>>>>>>>>>>>> # >>>>>>>>>>>>>>>>>>>>>>> s >>>>>>>>>>>>>>>>>>>>>>> e >>>>>>>>>>>>>>>>>>>>>>> c >>>>>>>>>>>>>>>>>>>>>>> tion >>>>>>>>>>>>>>>>>>>>>>> -4) >>>>>>>>>>>>>>>>>>>>>>> . >>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>> How about we keep this minimum requirement, and >>>>>>>>>>>>>>>>>>>>>> add a reference to draft-ietf-uta-tls-bcp along >>>>>>>>>>>>>>>>>>>>>> with a recommendation to adhere to the best >>>>>>>>>>>>>>>>>>>>>> practices it outlines in section 4? >>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>> I think MUST support TLS_RSA_WITH_AES_128_CBC_SHA >>>>>>>>>>>>>>>>>>>>> for backwards compatibility and SHOULD support the >>>>>>>>>>>>>>>>>>>>> ones listed in the UTA drafts would be ok. >>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>> = Sections 8, 8.1, 8.2 = It seems like the >>>>>>>>>>>>>>>>>>>>>>> transaction ID requirements regarding >>>>>>>>>>>>>>>>>>>>>>> non-reuse/monotonically increasing IDs are >>>>>>>>>>>>>>>>>>>>>>> re-stated multiple times across these three >>>>>>>>>>>>>>>>>>>>>>> sections, in slightly different ways, to the point >>>>>>>>>>>>>>>>>>>>>>> where it¹s not clear exactly what they are. >>>>>>>>>>>>>>>>>>>>>>> It seems like they are: >>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>> (1) Reliable transport, server-initiated transaction: >>>>>>>>>>>>>>>>>>>>>>> ID is >>>>>>>>>>>>>>>>>>>>>>> 0 >>>>>>>>>>>>>>>>>>>>>>> (2) Unreliable transport, server-initiated >>>>>>>>>>>>>>>>>>>>>>> transaction: >>>>>>>>>>>>>>>>>>>>>>> ID MUST be monotonically increasing (except for >>>>>>>>>>>>>>>>>>>>>>> wrap-around) >>>>>>>>>>>>>>>>>>>>>>> (3) Reliable transport, client-initiated transaction: >>>>>>>>>>>>>>>>>>>>>>> ID MUST NOT be 0 and MUST NOT be reused in >>>>>>>>>>>>>>>>>>>>>>> another message from the client until a response >>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>> >from the server is received for the transaction, >>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>> but need not be monotonically increasing (e.g., a >>>>>>>>>>>>>>>>>>>>>>> lower, recently used ID could be re-used once a >>>>>>>>>>>>>>>>>>>>>>> response is >>>>>>>>>>>>>>>>>>>>>>> received) >>>>>>>>>>>>>>>>>>>>>>> (4) Unreliable transport, client-initiated >>>>>>>>>>>>>>>>>>>>>>> transaction: >>>>>>>>>>>>>>>>>>>>>>> ID MUST be monotonically increasing (except for >>>>>>>>>>>>>>>>>>>>>>> wrap-around) >>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>> Is (3) the correct interpretation of the text in 8.1? >>>>>>>>>>>>>>>>>>>>>>> If so, why not just require IDs in all >>>>>>>>>>>>>>>>>>>>>>> client-initiated transactions to be monotonically >>>>>>>>>>>>>>>>>>>>>>> increasing? >>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>> Agree we can and should simplify this. Sections >>>>>>>>>>>>>>>>>>>>>> 8.1 and >>>>>>>>>>>>>>>>>>>>>> 8.2 cover the client behavior and server behavior >>>>>>>>>>>>>>>>>>>>>> in detail. As such, the transaction ID related >>>>>>>>>>>>>>>>>>>>>> information at the start of Section 8 is superfluous. >>>>>>>>>>>>>>>>>>>>>> I recommend reducing the text in Section 8 to the >>>>>>>>>>>>>>>>>>>>>> follow: >>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>> 8. Protocol Transactions >>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>> In BFCP, there are two types of transactions: >>>>>>>>>>>>>>>>>>>>>> client-initiated transactions and server-initiated >>>>>>>>>>>>>>>>>>>>>> transactions. >>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>> Client-initiated transactions consist of a request >>>>>>>>>>>>>>>>>>>>>> from a client to a floor control server and a >>>>>>>>>>>>>>>>>>>>>> response from the floor control server to the client. >>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>> Server-initiated transactions have different >>>>>>>>>>>>>>>>>>>>>> behavior depending on underlying transport: >>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>> When using a reliable transport, >>>>>>>>>>>>>>>>>>>>>> server-initiated transactions >>>>>>>>>>>>>>>>>>>>>> consist of a single message from a floor >>>>>>>>>>>>>>>>>>>>>> control server to a >>>>>>>>>>>>>>>>>>>>>> client (notifications). They do not trigger >>>>>>>>>>>>>>>>>>>>>> any response. >>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>> When using an unreliable transport, >>>>>>>>>>>>>>>>>>>>>> server-initiated transactions >>>>>>>>>>>>>>>>>>>>>> consist of a request from a floor control >>>>>>>>>>>>>>>>>>>>>> server to a client and a >>>>>>>>>>>>>>>>>>>>>> response from the client to the floor control >>>>>>>>>>>>>>>>>>>>>> server. >>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>> When using BFCP over an unreliable transport, >>>>>>>>>>>>>>>>>>>>>> retransmission timer T1 (see Section 8.3) MUST be >>>>>>>>>>>>>>>>>>>>>> used for all requests until the transaction is >>>>>>>>>>>>>>>>>>>>>> completed. >>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>> Then in section 8.1, we add the important details >>>>>>>>>>>>>>>>>>>>>> removed from section 8. >>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>> 8.1.1 Client Behavior >>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>> A client starting a client-initiated transaction >>>>>>>>>>>>>>>>>>>>>> MUST set the Conference ID in the common header of >>>>>>>>>>>>>>>>>>>>>> the message to the Conference ID for the >>>>>>>>>>>>>>>>>>>>>> conference that the client obtained previously. >>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>> The client MUST set the Transaction ID value in >>>>>>>>>>>>>>>>>>>>>> the common header to a number that is different >>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>> >from 0 and that MUST NOT be reused in another >>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>> message from the client until a response from the >>>>>>>>>>>>>>>>>>>>>> server is received for the transaction. >>>>>>>>>>>>>>>>>>>>>> The client uses the Transaction ID value to match >>>>>>>>>>>>>>>>>>>>>> this message with the response from the floor >>>>>>>>>>>>>>>>>>>>>> control server. >>>>>>>>>>>>>>>>>>>>>> When using BFCP over an unreliable transport, it >>>>>>>>>>>>>>>>>>>>>> is important to choose a Transaction ID value that >>>>>>>>>>>>>>>>>>>>>> lets the receiver distinguish the reception of the >>>>>>>>>>>>>>>>>>>>>> next message in a sequence of BFCP messages from a >>>>>>>>>>>>>>>>>>>>>> retransmission of a previous message. Therefore, >>>>>>>>>>>>>>>>>>>>>> BFCP entities using an unreliable transport MUST >>>>>>>>>>>>>>>>>>>>>> use monotonically increasing Transaction ID values >>>>>>>>>>>>>>>>>>>>>> (except for wrap-around). >>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>> A client receiving a server-initiated transaction >>>>>>>>>>>>>>>>>>>>>> over an unreliable transport MUST copy the >>>>>>>>>>>>>>>>>>>>>> Transaction ID from the request received from the >>>>>>>>>>>>>>>>>>>>>> server into the response. >>>>>>>>>>>>>>>>>>>>>> [Question: is there a need to copy the Conference >>>>>>>>>>>>>>>>>>>>>> ID and User ID, if present?] >>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>> 8.2. Server Behavior >>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>> A floor control server sending a response within a >>>>>>>>>>>>>>>>>>>>>> client-initiated transaction MUST copy the >>>>>>>>>>>>>>>>>>>>>> Conference ID, the Transaction ID, and the User ID >>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>> >from the request received from the client into the >>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>> response. >>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>> Server-initiated transactions MUST contain a >>>>>>>>>>>>>>>>>>>>>> Transaction ID equal to >>>>>>>>>>>>>>>>>>>>>> 0 when BFCP is used over a reliable transport. >>>>>>>>>>>>>>>>>>>>>> Over an unreliable transport, the Transaction ID >>>>>>>>>>>>>>>>>>>>>> shall have the same properties as for >>>>>>>>>>>>>>>>>>>>>> client-initiated transactions. >>>>>>>>>>>>>>>>>>>>>> The server uses the Transaction ID value to match >>>>>>>>>>>>>>>>>>>>>> this message with the response from the floor >>>>>>>>>>>>>>>>>>>>>> participant or floor chair. >>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>> Thanks, this is better. >>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>> = Section 9 (impacts Section 14 as well) = "BFCP >>>>>>>>>>>>>>>>>>>>>>> clients SHOULD authenticate the floor control >>>>>>>>>>>>>>>>>>>>>>> server before sending any BFCP message to it or >>>>>>>>>>>>>>>>>>>>>>> accepting any BFCP message from it. >>>>>>>>>>>>>>>>>>>>>>> Similarly, floor control servers SHOULD >>>>>>>>>>>>>>>>>>>>>>> authenticate a client before accepting any BFCP >>>>>>>>>>>>>>>>>>>>>>> message from it or sending any BFCP message to it. >>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>> BFCP supports TLS/DTLS mutual authentication >>>>>>>>>>>>>>>>>>>>>>> between clients and floor control servers, as >>>>>>>>>>>>>>>>>>>>>>> specified in Section 9.1. >>>>>>>>>>>>>>>>>>>>>>> This is the RECOMMENDED authentication mechanism >>>>>>>>>>>>>>>>>>>>>>> in BFCP.² >>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>> What are the cases where clients and servers do >>>>>>>>>>>>>>>>>>>>>>> not need to be authenticating each other? I know >>>>>>>>>>>>>>>>>>>>>>> this requirement and the other SHOULD-level >>>>>>>>>>>>>>>>>>>>>>> requirements around use of TLS/DTLS are carried >>>>>>>>>>>>>>>>>>>>>>> over from RFC 4582, but I¹m concerned that they >>>>>>>>>>>>>>>>>>>>>>> aren¹t as strong as they should be. >>>>>>>>>>>>>>>>>>>>>>> For a conference where the signaling traffic is >>>>>>>>>>>>>>>>>>>>>>> authenticated and confidentiality and integrity >>>>>>>>>>>>>>>>>>>>>>> protected, why is it ok for the floor control >>>>>>>>>>>>>>>>>>>>>>> traffic not to be? Could these requirements be >>>>>>>>>>>>>>>>>>>>>>> adjusted to require use of TLS/DTLS at least in >>>>>>>>>>>>>>>>>>>>>>> cases where the signaling is also protected? >>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>> Yes, but again, this would be at the expense of >>>>>>>>>>>>>>>>>>>>>> adding a non backward compatible change from rfc >>>>>>>>>>>>>>>>>>>>>> 4582. How about saying TLS/DTLS MUST be used for >>>>>>>>>>>>>>>>>>>>>> BFCP in such cases, while pointing out the rfc >>>>>>>>>>>>>>>>>>>>>> 4582 >>>>>>>>>>>>>>>>>>>>>> based implementations may not comply (similar to >>>>>>>>>>>>>>>>>>>>>> what we did with the version field). >>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>> Works for me. >>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>> Feel free to make all of these changes and submit a >>>>>>>>>>>>>>>>>>>>> rev and I¹ll issue the IETF LC. >>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>> Thanks, >>>>>>>>>>>>>>>>>>>>> Alissa >>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>> = Section 14 = >>>>>>>>>>>>>>>>>>>>>>> See the point above about ciphersuites. ³Non-null >>>>>>>>>>>>>>>>>>>>>>> encryption² is not a sufficient minimum baseline, >>>>>>>>>>>>>>>>>>>>>>> and if the requirements change in Section 7 they >>>>>>>>>>>>>>>>>>>>>>> should be reflected here as well. >>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>> Yep. >>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>> Editorial nits to be resolved with LC comments: >>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>> = Section 5.1 = >>>>>>>>>>>>>>>>>>>>>>> ³The version field MUST be set to 1 when using >>>>>>>>>>>>>>>>>>>>>>> BFCP over a reliable transport, i.e. as in [2].² >>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>> I find it a little odd to reference the spec >>>>>>>>>>>>>>>>>>>>>>> you¹re obsoleting in this sentence, especially >>>>>>>>>>>>>>>>>>>>>>> since BFCP over a reliable transport is completely >>>>>>>>>>>>>>>>>>>>>>> specified in this bis document. I would suggest >>>>>>>>>>>>>>>>>>>>>>> dropping >>>>>>>>>>>>>>>>>>>>>>> > the i.e. > >>>>>>>>>>>>>>>>>>>>>>> clause. >>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>> Good catch. This is a carry over from before this >>>>>>>>>>>>>>>>>>>>>> draft was adopted as a bis version of rfc4582. >>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>> "The version field MUST be set to 2 when using >>>>>>>>>>>>>>>>>>>>>>> BFCP over an unreliable transport with the >>>>>>>>>>>>>>>>>>>>>>> extensions specified in this document.² >>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>> The bit about ³with the extensions specified in >>>>>>>>>>>>>>>>>>>>>>> this document² is extraneous and should be removed. >>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>> "If an endpoint receives a message with an >>>>>>>>>>>>>>>>>>>>>>> unsupported version field value, the receiving >>>>>>>>>>>>>>>>>>>>>>> server MUST send an Error message with parameter >>>>>>>>>>>>>>>>>>>>>>> value 12 (Unsupported >>>>>>>>>>>>>>>>>>>>>>> Version) to indicate this.² >>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>> Use of the word ³server² here makes it sound as >>>>>>>>>>>>>>>>>>>>>>> if only servers could receive headers with >>>>>>>>>>>>>>>>>>>>>>> unsupported versions. >>>>>>>>>>>>>>>>>>>>>>> Should this be ³the receiving endpoint²? >>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>> = Section 6.2.4 = "[23], Section 6.7 provides >>>>>>>>>>>>>>>>>>>>>>> useful recommendations Š² >>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>> The links in the references are not quite right. >>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>> = Section 8.3.2 = s/when fires/when fired/ >>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>> = Section 14 = >>>>>>>>>>>>>>>>>>>>>>> s/high-jack/hijack/ >>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>> = Section B.1 = >>>>>>>>>>>>>>>>>>>>>>> "situation where multiple different and >>>>>>>>>>>>>>>>>>>>>>> non-interoperable would >>>>>>>>>>>>>>>>>>>>>>> co- >>>>>>>>>>>>>>>>>>>>>>> exist in the market.² >>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>> There is a word missing after ³non-interoperable." >>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>> This should read ³non-interoperable implementations². >>>>>>>>>>>>>>>>>>>>>> Earlier in that same sentence, ³BFCP over UDP were >>>>>>>>>>>>>>>>>>>>>> already used² should read ³BFCP over UDP is already >>>>>>>>>>>>>>>>>>>>>> being used². >>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>> Cheers, >>>>>>>>>>>>>>>>>>>>>> Charles >>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>> _______________________________________________ >>>>>>>>>>>>>>>>>>>>> bfcpbis mailing list >>>>>>>>>>>>>>>>>>>>> bfcpbis@ietf.org >>>>>>>>>>>>>>>>>>>>> https://www.ietf.org/mailman/listinfo/bfcpbis >>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>> >>>>>>> _______________________________________________ >>>>>>> bfcpbis mailing list >>>>>>> bfcpbis@ietf.org >>>>>>> https://www.ietf.org/mailman/listinfo/bfcpbis >>>>>>> >>>>>> >>>>> >>>> >>> >> _______________________________________________ >> bfcpbis mailing list >> bfcpbis@ietf.org >> https://www.ietf.org/mailman/listinfo/bfcpbis >> > From nobody Mon Nov 2 00:26:08 2015 Return-Path: X-Original-To: bfcpbis@ietfa.amsl.com Delivered-To: bfcpbis@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6FD891B2BFF for ; Mon, 2 Nov 2015 00:26:06 -0800 (PST) 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 XRMaIbVh1Ebd for ; Mon, 2 Nov 2015 00:25:59 -0800 (PST) Received: from alln-iport-7.cisco.com (alln-iport-7.cisco.com [173.37.142.94]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4BA281B33A7 for ; Mon, 2 Nov 2015 00:25:59 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=65102; q=dns/txt; s=iport; t=1446452759; x=1447662359; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=oTC5VYmQpTer1y8wA/i2NupEzgO0yuCN44e1UdD6e+k=; b=Ut2xPcmpoQAuesYjeRTfR8FNTG37DO/SDWU5qZhdjBHYOKGWTb6FseFX 7TPPDqcdrB05DrKBmCa5c6AF8chyeBDdD1EYCoLqOqOBJQMyCA+tRWl3c whdfVPG2xyJsWWM7iMhcKSDJqU73dsLHed+U61aivIlKilk/OdP5SC5rl c=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: A0AgAgDKHDdW/4YNJK1egztTbwa/NgENgVcDFwqFLkoCHIEOOBQBAQEBAQEBgQqENQEBAQQBAQEXAQgRMwEGBgUMBAIBBgIRAwEBAQECAhEBEQMCAgIlCxQBCAgBAQQBDQUJEogVDZMEnTeQWAEBAQEBAQEBAQEBAQEBAQEBAQEBARiBIolNgQaEPgEBBQkmKQkMgkmBRQWHRYVWhTWDcwGFHIJwhRiBWYQ/gyR3iTWEYINxAR8BAUKCER0WgUByhDYHFyOBBwEBAQ X-IronPort-AV: E=Sophos;i="5.20,233,1444694400"; d="scan'208";a="204072687" Received: from alln-core-12.cisco.com ([173.36.13.134]) by alln-iport-7.cisco.com with ESMTP; 02 Nov 2015 08:25:56 +0000 Received: from XCH-RCD-013.cisco.com (xch-rcd-013.cisco.com [173.37.102.23]) by alln-core-12.cisco.com (8.14.5/8.14.5) with ESMTP id tA28Pu8O003019 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Mon, 2 Nov 2015 08:25:56 GMT Received: from xch-aln-018.cisco.com (173.36.7.28) by XCH-RCD-013.cisco.com (173.37.102.23) with Microsoft SMTP Server (TLS) id 15.0.1104.5; Mon, 2 Nov 2015 02:25:56 -0600 Received: from xch-aln-018.cisco.com ([173.36.7.28]) by XCH-ALN-018.cisco.com ([173.36.7.28]) with mapi id 15.00.1104.000; Mon, 2 Nov 2015 02:25:56 -0600 From: "Charles Eckel (eckelcu)" To: "Tom Kristensen (tomkrist)" , Christer Holmberg Thread-Topic: Status update on draft-ietf-mmusic-dtls-sdp [was: [bfcpbis] draft-ietf-bfcpbis-rfc4583bis] Thread-Index: AdEVPGtzePVeqGKXRT2MOxuY5KEVyAAOE52AABRFx4A= Date: Mon, 2 Nov 2015 08:25:55 +0000 Message-ID: References: <7594FB04B1934943A5C02806D1A2204B37BC8F7B@ESESSMB209.ericsson.se> <56371495.7080105@cisco.com> In-Reply-To: <56371495.7080105@cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.5.7.151005 x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.70.231.142] Content-Type: text/plain; charset="utf-8" Content-ID: <3242EE522069D04691E3743861E78535@emea.cisco.com> Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: Cc: "draft-ietf-bfcpbis-rfc4582bis@tools.ietf.org" , "bfcpbis@ietf.org" , Alissa Cooper , Gonzalo Camarillo , Ben Campbell Subject: Re: [bfcpbis] Status update on draft-ietf-mmusic-dtls-sdp [was: draft-ietf-bfcpbis-rfc4583bis] X-BeenThere: bfcpbis@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: BFCPBIS working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 02 Nov 2015 08:26:06 -0000 R3JlYXQsIHRoYW5rcyBUb20uIEkgbG9vayBmb3J3YXJkIHRvIHNlZWluZyB0aGUgdXBkYXRlIHBv c3RlZCBiZWZvcmUgdGhlDQplbmQgb2YgdGhpcyB3ZWVrLg0KDQpDaGVlcnMsDQpDaGFybGVzDQoN Ck9uIDExLzIvMTUsIDQ6NDUgUE0sICJUb20gS3Jpc3RlbnNlbiAodG9ta3Jpc3QpIiA8dG9ta3Jp c3RAY2lzY28uY29tPg0Kd3JvdGU6DQoNCj5QZXJmZWN0ISBJJ2xsIHVwZGF0ZSBhbmQgcG9saXNo IHRoZSBkcmFmdCBhcyBkaXNjdXNzZWQgYW5kIGFncmVlZCB1cG9uDQo+YmVsb3cgYW5kIHN1Ym1p dC4NCj4NCj4tLSBUb20NCj4NCj5PbiAxMS8wMi8yMDE1IDA4OjA0IEFNLCBDaHJpc3RlciBIb2xt YmVyZyB3cm90ZToNCj4+IEhpLA0KPj4NCj4+IGRyYWZ0LWlldGYtbW11c2ljLWR0bHMtc2RwIHdh cyBkaXNjdXNzZWQgYXQgTU1VU0lDIHRvZGF5Lg0KPj4NCj4+IEF0IHRoaXMgbW9tZW50IHRoZXJl IGFyZSBubyB0ZWNobmljYWwgb3BlbiBpc3N1ZXMuIFRoZSBwbGFuIGlzIHRvIGFkZA0KPj5zb21l IGVkaXRvcmlhbCB3b3JrLCBiYXNlZCBvbiBjb21tZW50cyByZWNlaXZlZCBkdXJpbmcgdGhlIHNl c3Npb24sIGFuZA0KPj50aGUgYWRkIHRleHQgcmVnYXJkaW5nIERUTFMtdXNhZ2UgZHJhZnRzL3Nw ZWNzIHRoYXQgdGhlIGRyYWZ0IHVwZGF0ZXMuDQo+PkFmdGVyIHRoYXQsIHVubGVzcyBzb21ldGhp bmcgdW5leHBlY3RlZCBjb21lcyB1cCwgdGhlIGRyYWZ0IHNob3VsZCBiZQ0KPj5yZWFkeSBmb3Ig V0dMQy4NCj4+DQo+PiBSZWdhcmRzLA0KPj4NCj4+IENocmlzdGVyDQo+Pg0KPj4NCj4+DQo+PiAt LS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KPj4gRnJvbTogQ2hhcmxlcyBFY2tlbCAoZWNrZWxj dSkgW21haWx0bzplY2tlbGN1QGNpc2NvLmNvbV0NCj4+IFNlbnQ6IDI4IFNlcHRlbWJlciAyMDE1 IDE4OjUwDQo+PiBUbzogQ2hyaXN0ZXIgSG9sbWJlcmc8Y2hyaXN0ZXIuaG9sbWJlcmdAZXJpY3Nz b24uY29tPjsgVG9tIEtyaXN0ZW5zZW4NCj4+KHRvbWtyaXN0KTx0b21rcmlzdEBjaXNjby5jb20+ DQo+PiBDYzogQWxpc3NhIENvb3BlcjxhbGlzc2FAY29vcGVydy5pbj47IGJmY3BiaXNAaWV0Zi5v cmc7DQo+PmRyYWZ0LWlldGYtYmZjcGJpcy1yZmM0NTgyYmlzQHRvb2xzLmlldGYub3JnOyBHb256 YWxvDQo+PkNhbWFyaWxsbzxnb256YWxvLmNhbWFyaWxsb0Blcmljc3Nvbi5jb20+OyBCZW4gQ2Ft cGJlbGw8YmVuQG5vc3RydW0uY29tPg0KPj4gU3ViamVjdDogUmU6IFtiZmNwYmlzXSBkcmFmdC1p ZXRmLWJmY3BiaXMtcmZjNDU4M2Jpcw0KPj4NCj4+IFRoYW5rcyBDaHJpc3Rlci4NCj4+DQo+PiBU b20sIGNhbiB5b3UgcGxlYXNlIHBvc3QgdGhlIGNvcnJlc3BvbmRpbmcgdXBkYXRlIHRvIHRoZSBk cmFmdD8NCj4+DQo+PiBDaGVlcnMsDQo+PiBDaGFybGVzDQo+Pg0KPj4gT24gOS8yOC8xNSwgMzow NyBBTSwgImJmY3BiaXMgb24gYmVoYWxmIG9mIENocmlzdGVyIEhvbG1iZXJnIg0KPj4gPGJmY3Bi aXMtYm91bmNlc0BpZXRmLm9yZyBvbiBiZWhhbGYgb2YgY2hyaXN0ZXIuaG9sbWJlcmdAZXJpY3Nz b24uY29tPg0KPj4gd3JvdGU6DQo+Pg0KPj4gICAgDQo+Pj4gSGksDQo+Pj4NCj4+PiAgICAgIA0K Pj4+PiBJbiB0aGF0IGNhc2UsIEkgcHJlZmVyIFRvbeKAmXMgb3JpZ2luYWwgc3VnZ2VzdGlvbiwN Cj4+Pj4NCj4+Pj4gICBXaGF0IGlmIHdlIGtlZXAgdGhlIHRleHQgYW5kIGFkZHMgdGhpcyBhcyBh biBhZGRpdGlvbmFsIHJlZmVyZW5jZQ0KPj4+PiBpbiB0aGUgdHdvIG5ldyB0ZXh0IHBhc3NhZ2Vz IHByb3Bvc2VkIGJ5IENoYXJsZXM6ICIuLi4gWzEzXSwgYW5kICB0aGUNCj4+Pj4gY2xhcmlmaWNh dGlvbnMgZGVmaW5lZCBpbiBbZHJhZnQtaWV0Zi1tbXVzaWMtZHRscy1zZHBdLCAuLi4iLg0KPj4+ Pg0KPj4+PiAgIFdoZXJlIFsxM10gaXMgYSByZWZlcmVuY2UgdG8gUkZDIDU3NjMuDQo+Pj4+ICAg ICAgICANCj4+PiBJZiB0aGF0J3Mgc29tZXRoaW5nIHBlb3BsZSBjYW4gYWdyZWUgdG8sIHRoZW4g Y2FuIGxpdmUgd2l0aCBzdWNoDQo+Pj4gY29tcHJvbWlzZSA6KQ0KPj4+DQo+Pj4gUmVnYXJkcywN Cj4+Pg0KPj4+IENocmlzdGVyDQo+Pj4NCj4+Pg0KPj4+DQo+Pj4NCj4+Pg0KPj4+IElmIGl0IHR1 cm5zIG91dCB0aGF0IGRyYWZ0LWlldGYtbW11c2ljLWR0bHMtc2RwIHVwZGF0ZXMgUkZDIDU3NjMs IHRoZW4NCj4+PiB0aGVyZSBpcyBzb21lIHJlZHVuZGFuY3kuIEJ1dCB0aGF0IGlzIGJldHRlciB0 aGFuIGhhdmluZyBhIGhvbGUgd2hlbiBpdA0KPj4+IGNvbWVzIHRvIGJhY2t3YXJkIGNvbXBhdGli aWxpdHkgd2l0aCBleGlzdGluZyBpbXBsZW1lbnRhdGlvbnMsIHdoaWNoIGlzDQo+Pj4gd2hhdCB3 ZSB3aWxsIGhhdmUgdG9kYXkgaWYgd2UgcmVmZXJlbmNlIGRyYWZ0LWlldGYtbW11c2ljLWR0bHMt c2RwDQo+Pj5vbmx5Lg0KPj4+DQo+Pj4gQ2hlZXJzLA0KPj4+IENoYXJsZXMNCj4+Pg0KPj4+DQo+ Pj4NCj4+PiBPbiA5LzI1LzE1LCAyOjIxIEFNLCAiQ2hyaXN0ZXIgSG9sbWJlcmciDQo+Pj4gPGNo cmlzdGVyLmhvbG1iZXJnQGVyaWNzc29uLmNvbT4NCj4+PiB3cm90ZToNCj4+Pg0KPj4+ICAgICAg DQo+Pj4+IEhpIENoYXJsZXMsDQo+Pj4+DQo+Pj4+ICAgICAgICANCj4+Pj4+IEFzIGEgc2ltcGxl IGV4YW1wbGUsIHdlIGN1cnJlbnRseSByZWZlciB0byByZmM0NTgyYmlzIGluc3RlYWQgb2YgdGhl DQo+Pj4+PiBldmVudHVhbCBSRkMuIEFzc3VtaW5nIHJmYzQ1ODJiaXMgZG9lcyBiZWNvbWUgYW4g UkZDLCB3ZSB3b3VsZCB3YW50DQo+Pj4+PiB0aGUgUkZDIGVkaXRvciB0byB1cGRhdGUgcmVmZXJl bmNlcyB0byBpdCBhbmQgdG8gUkZDeHh4eCB3aXRoIHRoZQ0KPj4+Pj4gYWN0dWFsIFJGQyBudW1i ZXIuDQo+Pj4+PiBTaW1pbGFyIGhlcmUsIHdlIHdvdWxkIHdhbnQgdGhlbSB0byBjaGVjayB3aXRo IGF1dGhvcnMvY2hhaXJzL0FEcyBvbg0KPj4+Pj4gdGhlIHN0YXRlIG9mIGRyYWZ0LWlldGYtbW11 c2ljLWR0bHMtc2RwIHRvIHNlZSBpZiB3ZSB3YW50IHRvIHJlcGxhY2UNCj4+Pj4+IG91ciByZWZl cmVuY2UgdG8gUkZDIDU3NjMgd2l0aCBhIHJlZmVyZW5jZSB0byBpdC4gVGhpcyB3YXkgd2UgY2Fu DQo+Pj4+PiBtb3ZlIGZvcndhcmQgd2hpbGUgZHJhZnQtaWV0Zi1tbXVzaWMtZHRscy1zZHAgY29u dGludWVzIHRvIHByb2dyZXNzDQo+Pj4+PiBhcyB3ZWxsLg0KPj4+Pj4gICAgICAgICAgDQo+Pj4+ IEkgZG9uJ3QgdGhpbmsgaXQncyB0aGUgc2FtZSB0aGluZy4gRmlyc3QgeW91IHRhbGsgYWJvdXQg YSBkcmFmdCwgd2hlcmUNCj4+Pj4gdGhlIGRyYWZ0IG5hbWUgd2lsbCBiZSByZXBsYWNlZCB3aXRo IHRoZSB0by1iZS1hc3NpZ25lZCBSRkMgbnVtYmVyLiBJbg0KPj4+PiB0aGUgY2FzZSBvZiBEVExT LVNEUCB3ZSBhcmUgdGFsa2luZyBhYm91dCB0d28gc2VwYXJhdGUgc3BlY2lmaWNhdGlvbnMuDQo+ Pj4+DQo+Pj4+IFJlZ2FyZHMsDQo+Pj4+DQo+Pj4+IENocmlzdGVyDQo+Pj4+DQo+Pj4+DQo+Pj4+ IE9uIDkvMjQvMTUsIDI6NTMgQU0sICJDaHJpc3RlciBIb2xtYmVyZyINCj4+Pj4gPGNocmlzdGVy LmhvbG1iZXJnQGVyaWNzc29uLmNvbT4NCj4+Pj4gd3JvdGU6DQo+Pj4+DQo+Pj4+ICAgICAgICAN Cj4+Pj4+IEhpIENoYXJsZXMsDQo+Pj4+Pg0KPj4+Pj4gSSBhbSBzdGlsbCBub3Qgc3VyZSBJIHVu ZGVyc3RhbmQgeW91ciBzdWdnZXN0aW9uOiB3aGF0IGlzIG1lYW50IGJ5DQo+Pj4+PiAiYXMgZGV0 ZXJtaW5lZCBwcmlvciB0byBwdWJsaWNhdGlvbiI/IFdoZW4vd2hlcmUvd2hvPyA6KQ0KPj4+Pj4N Cj4+Pj4+IFJlZ2FyZHMsDQo+Pj4+Pg0KPj4+Pj4gQ2hyaXN0ZXINCj4+Pj4+DQo+Pj4+PiAtLS0t LU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KPj4+Pj4gRnJvbTogQ2hhcmxlcyBFY2tlbCAoZWNrZWxj dSkgW21haWx0bzplY2tlbGN1QGNpc2NvLmNvbV0NCj4+Pj4+IFNlbnQ6IDIyLiBzeXlza3V1dGEg MjAxNSAxNzowNQ0KPj4+Pj4gVG86IENocmlzdGVyIEhvbG1iZXJnOyBUb20gS3Jpc3RlbnNlbiAo dG9ta3Jpc3QpDQo+Pj4+PiBDYzogZHJhZnQtaWV0Zi1iZmNwYmlzLXJmYzQ1ODJiaXNAdG9vbHMu aWV0Zi5vcmc7IGJmY3BiaXNAaWV0Zi5vcmc7DQo+Pj4+PiBBbGlzc2EgQ29vcGVyOyBHb256YWxv IENhbWFyaWxsbzsgQmVuIENhbXBiZWxsDQo+Pj4+PiBTdWJqZWN0OiBSZTogW2JmY3BiaXNdIGRy YWZ0LWlldGYtYmZjcGJpcy1yZmM0NTgzYmlzDQo+Pj4+Pg0KPj4+Pj4gSSB2aWV3IHJlZmVycmlu ZyB0byBkcmFmdC1pZXRmLW1tdXNpYy1kdGxzLXNkcCBub3cgaW5zdGVhZCBvZiBSRkMNCj4+Pj4+ IDU3NjMgdG8gYmUgbGlrZSB3cml0aW5nIGEgYmxhbmsgY2hlY2suIERlYmF0ZSBpcyBhY3RpdmVs eSBvY2N1cnJpbmcNCj4+Pj4+IG9uIHRoZSBsaXN0LCB0aGUgbm9ybWF0aXZlIGxhbmd1YWdlIGlu IFJGQyA1NzYzIGlzIGV4cGVjdGVkIHRvIGJlDQo+Pj4+PiB1cGRhdGVkIGluIG11bHRpcGxlIHdh eXMsIGFuZCBiYWNrd2FyZCBjb21wYXRpYmlsaXR5IHdpdGggdGhlIHRoZQ0KPj4+Pj4gbm9ybWF0 aXZlIGxhbmd1YWdlIHByb3ZpZGUgaW4gcHJldmlvdXMgdmVyc2lvbiBvZiByZmM0NTgzYmlzIGlz IG5vdA0KPj4+Pj4gZnVsbHkgYWRkcmVzc2VkLiBJdCBzZWVtcyBtb3JlIGFwcHJvcHJpYXRlIHRv IG1lIGF0IHRoaXMgc3RhZ2UgdG8NCj4+Pj4+IGNvbnRpbnVlIHRvIHJlZmVyIHRvIFJGQyA1NzYz IHdpdGggYSBub3RlIHJlZ2FyZGluZyB1cGRhdGluZyBvcg0KPj4+Pj4gcmVwbGFjaW5nIHRoYXQg cmVmZXJlbmNlIHdpdGggb25lIHRvIGRyYWZ0LWlldGYtbW11c2ljLWR0bHMtc2RwLCBhcw0KPj4+ Pj4gZGV0ZXJtaW5lZCBwcmlvciB0byBwdWJsaWNhdGlvbi4NCj4+Pj4+DQo+Pj4+PiBDaGVlcnMs DQo+Pj4+PiBDaGFybGVzDQo+Pj4+Pg0KPj4+Pj4gT24gOS8yMS8xNSwgMTE6NDggUE0sICJDaHJp c3RlciBIb2xtYmVyZyINCj4+Pj4+IDxjaHJpc3Rlci5ob2xtYmVyZ0Blcmljc3Nvbi5jb20+DQo+ Pj4+PiB3cm90ZToNCj4+Pj4+DQo+Pj4+PiAgICAgICAgICANCj4+Pj4+PiBIaSwNCj4+Pj4+Pg0K Pj4+Pj4+ICAgICAgICAgICAgDQo+Pj4+Pj4+IEkgc2VlLiBBcyB0aGlzIGlzIGEgbW92aW5nIHRh cmdldCwgcGVyaGFwcyB3aGVyZSB3ZSByZWZlcmVuY2UgUkZDDQo+Pj4+Pj4+IDU3NjMgd2UgY2Fu IGFkZCBhIG5vdGUgZm9yIHRoZSBSRkMgZWRpdG9yIHRoYXQNCj4+Pj4+Pj4gZHJhZnQtaWV0Zi1t bXVzaWMtZHRscy1zZHAgaXMgZXhwZWN0ZWQgdG8gYWRkIGNsYXJpZmljYXRpb25zIGFuZA0KPj4+ Pj4+PiBtYWtlIGNoYW5nZXMgdG8gUkZDIDU3NjMgdGhhdCBzaG91bGQgYmUgY29uc2lkZXJlZCBw cmlvciB0bw0KPj4+Pj4+PiBwdWJsaWNhdGlvbiBvZiByZmM0NTgzYmlzLg0KPj4+Pj4+PiAgICAg ICAgICAgIA0KPj4+Pj4+IEkgYW0gbm90IHN1cmUgSSB1bmRlcnN0YW5kLiBJIGRvbid0IHRoaW5r IGl0J3MgdXAgdG8gdGhlIFJGQyBlZGl0b3INCj4+Pj4+PiB0byBtYWtlIGEgZGVjaXNpb24gd2hl dGhlciB0aGUgZHJhZnQgc2hvdWxkIHJlZmVyZW5jZSBEVExTLVNEUC4NCj4+Pj4+Pg0KPj4+Pj4+ IFJlZ2FyZHMsDQo+Pj4+Pj4NCj4+Pj4+PiBDaHJpc3Rlcg0KPj4+Pj4+DQo+Pj4+Pj4NCj4+Pj4+ Pg0KPj4+Pj4+IE9uIDkvMjEvMTUsIDExOjIzIEFNLCAiQ2hyaXN0ZXIgSG9sbWJlcmciDQo+Pj4+ Pj4gPGNocmlzdGVyLmhvbG1iZXJnQGVyaWNzc29uLmNvbT4NCj4+Pj4+PiB3cm90ZToNCj4+Pj4+ Pg0KPj4+Pj4+ICAgICAgICAgICAgDQo+Pj4+Pj4+IEhpLA0KPj4+Pj4+Pg0KPj4+Pj4+PiAgICAg ICAgICAgIA0KPj4+Pj4+Pj4gUkZDIDU3NjMsIHdoaWNoIGlzIGN1cnJlbnRseSByZXF1aXJlZCBm b3IgQkZDUCB3aXRoIERUTFMgcmVhZHM6DQo+Pj4+Pj4+Pg0KPj4+Pj4+Pj4gICAgbyAgVGhlIGVu ZHBvaW50IE1VU1QgTk9UIHVzZSB0aGUgY29ubmVjdGlvbiBhdHRyaWJ1dGUgZGVmaW5lZA0KPj4+ Pj4+Pj5pbg0KPj4+Pj4+Pj4gICAgICBbUkZDNDE0NTxodHRwczovL3Rvb2xzLmlldGYub3JnL2h0 bWwvcmZjNDE0NT5dLg0KPj4+Pj4+Pj4gICAgICAgICAgIA0KPj4+Pj4+PiBDb3JyZWN0Lg0KPj4+ Pj4+Pg0KPj4+Pj4+PiBBbmQsIElGIHdlIGRlY2lkZSB0byB1c2UgZGVmaW5lIHVzYWdlIG9mIHRo ZSAnY29ubmVjdGlvbicgYXR0cmlidXRlDQo+Pj4+Pj4+IGZvciBEVExTLCB3ZSB3b3VsZCBjaGFu Z2UgdGhhdC4NCj4+Pj4+Pj4NCj4+Pj4+Pj4gSG93ZXZlciwgYSBmZXcgZGF5cyBhZ28gd2Ugc2Vu dCBhbiBlLW1haWwgdG8gdGhlIE1NVVNJQyBsaXN0LA0KPj4+Pj4+PiBzdWdnZXN0aW5nIHRoYXQg d2Ugc2hvdWxkIE5PVCB1c2UgdGhlICdjb25uZWN0aW9uJyBhdHRyaWJ1dGUgZm9yDQo+Pj4+Pj4+ RFRMUy4NCj4+Pj4+Pj4gSW5zdGVhZCB3ZSBzaG91bGQgZGVmaW5lIGEgbmV3IGF0dHJpYnV0ZSAo Zm9yIG1vcmUgZGV0YWlscywgcGxlYXNlDQo+Pj4+Pj4+IHNlZSB0aGUgTU1VU0lDIGxpc3QpLg0K Pj4+Pj4+Pg0KPj4+Pj4+PiAgICAgICAgICAgIA0KPj4+Pj4+Pj4gU2VjdGlvbiA1LjEgb2YgZHJh ZnQtaWV0Zi1tbXVzaWMtZHRscy1zZHAgcmVhZHM6DQo+Pj4+Pj4+Pg0KPj4+Pj4+Pj4gICAgV2hl biB1c2VkIHdpdGggRFRMUywgdGhlcmUgaXMgbm8gZGVmYXVsdCB2YWx1ZSBkZWZpbmVkIGZvciB0 aGUNCj4+Pj4+Pj4+ICAgIGF0dHJpYnV0ZS4gIEltcGxlbWVudGF0aW9ucyB0aGF0IHdpc2ggdG8g dXNlIHRoZSBhdHRyaWJ1dGUgTVVTVA0KPj4+Pj4+Pj4gICAgZXhwbGljaXRseSBpbmNsdWRlIGl0 IGluIFNEUCBvZmZlcnMgYW5kIGFuc3dlcnMuICBJZiBhbiBvZmZlcg0KPj4+Pj4+Pj5vcg0KPj4+ Pj4+Pj4gICAgYW5zd2VyIGRvZXMgbm90IGNvbnRhaW4gYW4gYXR0cmlidXRlLCBvdGhlciBtZWFu cyBuZWVkcyB0byBiZQ0KPj4+Pj4+Pj4gdXNlZCBpbg0KPj4+Pj4+Pj4gICAgb3JkZXIgZm9yIGVu ZHBvaW50cyB0byBkZXRlcm1pbmUgd2hldGhlciBhbiBvZmZlciBvciBhbnN3ZXIgaXMNCj4+Pj4+ Pj4+ICAgIGFzc29jaWF0ZWQgd2l0aCBhbiBldmVudCB0aGF0IHJlcXVpcmVzIHRoZSBEVExTIGFz c29jaWF0aW9uIHRvDQo+Pj4+Pj4+PiBiZQ0KPj4+Pj4+Pj4gcmUtDQo+Pj4+Pj4+PiAgICBlc3Rh Ymxpc2hlZC4NCj4+Pj4+Pj4+DQo+Pj4+Pj4+PiBJIHN1cHBvc2UgaWYgZHJhZnQtaWV0Zi1tbXVz aWMtZHRscy1zZHAgcHVsbHMgaW4gZW5vdWdoIGZyb20gUkZDDQo+Pj4+Pj4+PiA1NzYzIHRvIG1h a2UgaXQgY2xlYXIgaG93IHRoZSBEVExTIGVzdGFibGlzaG1lbnQgYW5kDQo+Pj4+Pj4+PiByZS1l c3RhYmxpc2htZW50IHdvcmtzIGZvciB0aGUgY2FzZSBvZiB3aGljaCB0aGUgY29ubmVjdGlvbg0K Pj4+Pj4+Pj4gYXR0cmlidXRlIGlzIG5vdCB1c2VkLCB0aGVuIHdlIGNhbiBjaGFuZ2UgdGhlIHJl ZmVyZW5jZSBmcm9tIFJGQw0KPj4+Pj4+Pj4gNTc2MyB0byBkcmFmdC1pZXRmLW1tdXNpYy1kdGxz LXNkcC4NCj4+Pj4+Pj4+DQo+Pj4+Pj4+PiBUaGUgbGFzdCBzZXZlcmFsIHVwZGF0ZXMgb2YgZHJh ZnQtaWV0Zi1iZmNwYmlzLXJmYzQ1ODNiaXMgaGF2ZQ0KPj4+Pj4+Pj4gcmVtb3ZlZCBzdXBwb3J0 aW5nIHRleHQgZnJvbSB0aGUgZHJhZnQgaW4gZmF2b3Igb2YgcG9pbnRpbmcgdG8gUkZDDQo+Pj4+ Pj4+PiA1NzYzIGFzIHRoZSAgc291cmNlIG9mIHRydXRoLiBJIGZlYXIgdGhhdA0KPj4+Pj4+Pj4g ZHJhZnQtaWV0Zi1tbXVzaWMtZHRscy1zZHAgaW4gaXRzIGN1cnJlbnQgc3RhdGUgZG9lcyBub3Qg c2VydmUNCj4+Pj4+Pj4+IHRoYXQgbmVlZCBmb3IgZHJhZnQtaWV0Zi1iZmNwYmlzLXJmYzQ1ODNi aXMuIEkgdmFsdWUgIENocmlzdGVy4oCZcw0KPj4+Pj4+Pj4gdGhvdWdodHMgYW5kIHdlbGNvbWUg dGhlIG9waW5pb24gb2Ygb3RoZXJzLCBlc3BlY2lhbGx5IHRob3NlIHdobw0KPj4+Pj4+Pj4gaGF2 ZSBvciBhcmUgaW1wbGVtZW50aW5nIEJGQ1Agd2l0aCBEVExTIGFuZCBJQ0UsIHdoaWNoIEkgaGF2 ZSBub3QuDQo+Pj4+Pj4+PiAgICAgICAgICAgDQo+Pj4+Pj4+IFBsZWFzZSBub3RlIHRoYXQgRFRM Uy1TRFAgZG9lcyBub3Qgb25seSBkZWZpbmUgdXNhZ2Ugb2YgdGhlDQo+Pj4+Pj4+ICdjb25uZWN0 aW9uJw0KPj4+Pj4+PiBhdHRyaWJ1dGUsIGl0IGFsc28gZG9lcyBvdGhlciB0aGluZ3MuIE1heWJl IG1vcmUgaW1wb3J0YW50LCBpdCBkb2VzDQo+Pj4+Pj4+IG5vdCBzdGF0ZSB0aGF0IGFuIGFkZHJl c3MgY2hhbmdlIGJ5IGRlZmF1bHQgcmVxdWlyZXMgYSBuZXcgRFRMUw0KPj4+Pj4+PiBhc3NvY2lh dGlvbg0KPj4+Pj4+PiAtIHdoaWNoIGlzIGEgYW5vdGhlciA1NzYzIG1vZGlmaWNhdGlvbi4NCj4+ Pj4+Pj4NCj4+Pj4+Pj4gUmVnYXJkcywNCj4+Pj4+Pj4NCj4+Pj4+Pj4gQ2hyaXN0ZXINCj4+Pj4+ Pj4NCj4+Pj4+Pj4NCj4+Pj4+Pj4NCj4+Pj4+Pj4NCj4+Pj4+Pj4gT24gOS8yMS8xNSwgOTozMiBB TSwgImJmY3BiaXMgb24gYmVoYWxmIG9mIENocmlzdGVyIEhvbG1iZXJnIg0KPj4+Pj4+PiA8YmZj cGJpcy1ib3VuY2VzQGlldGYub3JnIG9uIGJlaGFsZiBvZg0KPj4+Pj4+PiBjaHJpc3Rlci5ob2xt YmVyZ0Blcmljc3Nvbi5jb20+DQo+Pj4+Pj4+IHdyb3RlOg0KPj4+Pj4+Pg0KPj4+Pj4+PiAgICAg ICAgICAgIA0KPj4+Pj4+Pj4gSGkgQ2hhcmxlcywNCj4+Pj4+Pj4+DQo+Pj4+Pj4+PiAgICAgICAg ICAgDQo+Pj4+Pj4+Pj4gVGhlIHByb2JsZW0gSSBzZWUgd2l0aCB0aGlzIGlzIHRoYXQgaXQgaXMg bm90IGp1c3QgYSBtYXR0ZXIgb2YNCj4+Pj4+Pj4+PiBjaGFuZ2luZyB0aGUgcmVmZXJlbmNlLCBp dCBpcyBhbHNvIGEgbWF0dGVyIG9mIGNoYW5naW5nIHRoZQ0KPj4+Pj4+Pj4+IG5vcm1hdGl2ZSBi ZWhhdmlvci4NCj4+Pj4+Pj4+PiBGb3IgRFRMUyB3aXRoIEJGQ1AsIHdlIG5ldmVyIHJlcXVpcmVk IHRoZSB1c2Ugb2YgdGhlPuKAnGNvbm5lY3Rpb27igJ0NCj4+Pj4+Pj4+PiBhdHRyaWJ1dGUuDQo+ Pj4+Pj4+Pj4gSWYgd2UgYXJlIHRvIHN0YXJ0IHJlcXVpcmluZyBpdCwgd2Ugd291bGQgbmVlZCBh ZGQgdGV4dCB0bw0KPj4+Pj4+Pj4+IGRlc2NyaWJlIGhvdyB0byBhZGRyZXNzIGJhY2t3YXJkIGNv bXBhdGliaWxpdHkgaW4gY2FzZXMgaW4gd2hpY2gNCj4+Pj4+Pj4+PiB0aGUgY29ubmVjdGlvbiBh dHRyaWJ1dGUgaXMgbm90IHNwZWNpZmllZC4NCj4+Pj4+Pj4+PiAgICAgICAgICANCj4+Pj4+Pj4+ IFRoZSBpbnRlbnRpb24gaXMgdG8gY292ZXIgYmFja3dhcmQgY29tcGF0aWJpbGl0eSBpbiB0aGUg ZHJhZnQuDQo+Pj4+Pj4+Pg0KPj4+Pj4+Pj4gICAgICAgICAgIA0KPj4+Pj4+Pj4+IEFyZSB0aGVy ZSBwbGFucyBmb3IgdGhpcyB3aXRoaW4gUkZDIDU3NjNiaXMgZHJhZnQ/IElmIHNvLCBUb23igJlz DQo+Pj4+Pj4+Pj4gcmVjb21tZW5kYXRpb24gb2YgY29udGludWluZyB0byBwb2ludCB0byBSRkMg NTc2MyBmb3Igbm93IG1heSBiZQ0KPj4+Pj4+Pj4+IHRoZSBiZXN0IGFwcHJvYWNoLg0KPj4+Pj4+ Pj4+ICAgICAgICAgIA0KPj4+Pj4+Pj4gSSBhbSBub3QgZmFtaWxpYXIgd2l0aCB0aGUgNTc2M2Jp cyBkcmFmdC4gQnV0LCBldmVuIGlmIHRoZQ0KPj4+Pj4+Pj4gRFRMUy1TRFAgZHJhZnQgbWFrZXMg dXBkYXRlcyB0byA1NzYzLCBpdCB3b24ndCBiZWNvbWUgYSA1NzYzYmlzDQo+Pj4+Pj4+PmRyYWZ0 Lg0KPj4+Pj4+Pj4NCj4+Pj4+Pj4+IFJlZ2FyZHMsDQo+Pj4+Pj4+Pg0KPj4+Pj4+Pj4gQ2hyaXN0 ZXINCj4+Pj4+Pj4+DQo+Pj4+Pj4+Pg0KPj4+Pj4+Pj4NCj4+Pj4+Pj4+IE9uIDkvMTEvMTUsIDE6 MTEgUE0sICJDaHJpc3RlciBIb2xtYmVyZyINCj4+Pj4+Pj4+IDxjaHJpc3Rlci5ob2xtYmVyZ0Bl cmljc3Nvbi5jb20+DQo+Pj4+Pj4+PiB3cm90ZToNCj4+Pj4+Pj4+DQo+Pj4+Pj4+PiAgICAgICAg ICAgDQo+Pj4+Pj4+Pj4gSGksDQo+Pj4+Pj4+Pj4NCj4+Pj4+Pj4+PiAgICAgICAgICANCj4+Pj4+ Pj4+Pj4gSG1tLCB5ZXMgbWF5YmUgYW4gaWRlYSBpZiBpdCdzIGZpbmUgcHJvY2VlZGluZyB3aXRo IHJlZmVycmluZyBhDQo+Pj4+Pj4+Pj4+IHdvcmstaW4tcHJvZ3Jlc3MgZHJhZnQgaGVyZS4NCj4+ Pj4+Pj4+Pj4gV2hhdCBpZiB3ZSBrZWVwIHRoZSB0ZXh0IGFuZCBhZGRzIHRoaXMgYXMgYW4gYWRk aXRpb25hbA0KPj4+Pj4+Pj4+PiByZWZlcmVuY2UgaW4gdGhlIHR3byBuZXcgdGV4dCBwYXNzYWdl cyBwcm9wb3NlZCBieSBDaGFybGVzOiAiLi4uDQo+Pj4+Pj4+Pj4+IFsxM10sIGFuZCB0aGUgY2xh cmlmaWNhdGlvbnMgZGVmaW5lZCBpbg0KPj4+Pj4+Pj4+PltkcmFmdC1pZXRmLW1tdXNpYy1kdGxz LXNkcF0sIC4uLiIuDQo+Pj4+Pj4+Pj4+DQo+Pj4+Pj4+Pj4+IFdoZXJlIFsxM10gaXMgYSByZWZl cmVuY2UgdG8gUkZDIDU3NjMuDQo+Pj4+Pj4+Pj4+ICAgICAgICAgDQo+Pj4+Pj4+Pj4gTXkgc3Vn Z2VzdGlvbiBpcyB0byAqb25seSogcmVmZXIgdGhlIG5ldyBkdGxzLXNkcCBkcmFmdC4gQmVjYXVz ZSwNCj4+Pj4+Pj4+PiBvbmUgb2YgdGhlIGlkZWFzIHdpdGggdGhlIG5ldyBkcmFmdCBpcyB0byBh bHNvIHVwZGF0ZSBSRkMgNTc2MyB0bw0KPj4+Pj4+Pj4+IHJlZmVyZW5jZSB0aGUgbmV3IGR0bHMt c2RwIGRyYWZ0Lg0KPj4+Pj4+Pj4+DQo+Pj4+Pj4+Pj4gICAgICAgICAgDQo+Pj4+Pj4+Pj4+IEFu eXdheSwgSSdkIHN0aWxsIHByZWZlciB0byBrZWVwIHRoZSB0ZXh0IGluDQo+Pj4+Pj4+Pj4+IGRy YWZ0LWlldGYtYmZjcGJpcy1yZmM0NTgzYmlzLTEyIGFuZCByZWRpcmVjdCB0aGUgcmVhZGVycyB0 byB0aGUNCj4+Pj4+Pj4+Pj4gcmZjNTc2M2JpcywgdGhhdCBldmVudHVhbGx5IHRoZW4gd2lsbCBv YnNvbGV0ZSAob3IgZXh0ZW5kPykgUkZDDQo+Pj4+Pj4+Pj4+IDU3NjMuDQo+Pj4+Pj4+Pj4+ICAg ICAgICAgDQo+Pj4+Pj4+Pj4gVGhlIG5ldyBkdGxzLXNkcCBkcmFmdCB3aWxsIG5vdCBiZWNvbWUg NTc2M2JpcyAoZXZlbnRob3VnaCBpdCBNQVkNCj4+Pj4+Pj4+PiB1cGRhdGUgc29tZSBwYXJ0cyBv ZiA1NzYzKS4gSXQncyBhIGdlbmVyaWMgZG9jdW1lbnQsIHdoaWNoICphbnkqDQo+Pj4+Pj4+Pj4g RFRMUyB1c2FnZSBjYW4gdGhlbiByZWZlcmVuY2UuDQo+Pj4+Pj4+Pj4NCj4+Pj4+Pj4+PiBSZWdh cmRzLA0KPj4+Pj4+Pj4+DQo+Pj4+Pj4+Pj4gQ2hyaXN0ZXINCj4+Pj4+Pj4+Pg0KPj4+Pj4+Pj4+ DQo+Pj4+Pj4+Pj4NCj4+Pj4+Pj4+PiBPbiAwOS8xMS8yMDE1IDAxOjI1IFBNLCBDaHJpc3RlciBI b2xtYmVyZyB3cm90ZToNCj4+Pj4+Pj4+PiAgICAgICAgICANCj4+Pj4+Pj4+Pj4gSGksDQo+Pj4+ Pj4+Pj4+DQo+Pj4+Pj4+Pj4+IE15IHN1Z2dlc3Rpb24gd291bGQgYWN0dWFsbHkgYmUgdG8gcmVm ZXIgdG8gdGhlIG5ldw0KPj4+Pj4+Pj4+PiBkcmFmdC1pZXRmLW1tdXNpYy1kdGxzLXNkcCwgd2hp Y2ggaXMgZ29pbmcgdG8gY2xhcmlmeSB0aGUNCj4+Pj4+Pj4+Pj4gRFRMUy1TUlRQIHJ1bGVzIHJl Z2FyZGluZyB3aGVuIGEgbmV3IERUTFMgYXNzb2NpYXRpb24gbXVzdCBiZQ0KPj4+Pj4+Pj4+PiBl c3RhYmxpc2hlZC4NCj4+Pj4+Pj4+Pj4NCj4+Pj4+Pj4+Pj4gUmVnYXJkcywNCj4+Pj4+Pj4+Pj4N Cj4+Pj4+Pj4+Pj4gQ2hyaXN0ZXINCj4+Pj4+Pj4+Pj4NCj4+Pj4+Pj4+Pj4gLS0tLS1PcmlnaW5h bCBNZXNzYWdlLS0tLS0NCj4+Pj4+Pj4+Pj4gRnJvbTogVG9tIEtyaXN0ZW5zZW4gW21haWx0bzp0 b21rcmlzdEBjaXNjby5jb21dDQo+Pj4+Pj4+Pj4+IFNlbnQ6IDExLiBzeXlza3V1dGEgMjAxNSAx MzoyNQ0KPj4+Pj4+Pj4+PiBUbzogQ2hhcmxlcyBFY2tlbCAoZWNrZWxjdSkNCj4+Pj4+Pj4+Pj4g Q2M6IENocmlzdGVyIEhvbG1iZXJnOyBBbGlzc2EgQ29vcGVyOyBHb256YWxvIENhbWFyaWxsbzsN Cj4+Pj4+Pj4+Pj4gZHJhZnQtaWV0Zi1iZmNwYmlzLXJmYzQ1ODJiaXNAdG9vbHMuaWV0Zi5vcmc7 IEJlbiBDYW1wYmVsbDsNCj4+Pj4+Pj4+Pj4gYmZjcGJpc0BpZXRmLm9yZw0KPj4+Pj4+Pj4+PiBT dWJqZWN0OiBSZTogZHJhZnQtaWV0Zi1iZmNwYmlzLXJmYzQ1ODNiaXMNCj4+Pj4+Pj4+Pj4NCj4+ Pj4+Pj4+Pj4gUG9pbnRpbmcgdG8gdGhlIERUTFMtU1JUUCAoYW5kIGJ5IHRoYXQgYW55IHVwZGF0 ZXMgb2YgaXQpIGlzIGENCj4+Pj4+Pj4+Pj4gc2ltcGxlLCBzYWZlIGFuZCBzdHJhaWd0LWZvcndh cmQgc29sdXRpb24uDQo+Pj4+Pj4+Pj4+DQo+Pj4+Pj4+Pj4+IFRoZSBvbmx5IGNoYW5nZSBpbiB0 aGUgbmV3IHZlcnNpb24gb2YgcmZjNDU4M2JpcyBqdXN0IHN1Ym1pdHRlZC4NCj4+Pj4+Pj4+Pj4g QW5kIGFzIENoYXJsZXMgc2F5cywgdGhpcyBzaG91bGQgYmUgdGhlIGxhc3QgbWlzc2luZyBmaXgg Zm9yDQo+Pj4+Pj4+Pj4+IHRoaXMgZHJhZnQgdW50aWwgbmV4dCBzdGFnZXMgaW4gdGhlIHByb2Nl c3MgYXQgbGVhc3QuDQo+Pj4+Pj4+Pj4+DQo+Pj4+Pj4+Pj4+IC0tIFRvbQ0KPj4+Pj4+Pj4+Pg0K Pj4+Pj4+Pj4+PiBPbiAwOS8wOC8yMDE1IDA3OjQ4IFBNLCBDaGFybGVzIEVja2VsIChlY2tlbGN1 KSB3cm90ZToNCj4+Pj4+Pj4+Pj4NCj4+Pj4+Pj4+Pj4gICAgICAgICANCj4+Pj4+Pj4+Pj4+IFBp Y2tpbmcgdXAgb24gdGhpcyBvbGQgdGhyZWFkIHJlZ2FyZGluZw0KPj4+Pj4+Pj4+Pj4gZHJhZnQt aWV0Zi1iZmNwYmlzLXJmYzQ1ODNiaXMuDQo+Pj4+Pj4+Pj4+PiBJIHRoaW5rIHRoaXMgaXMgdGhl IG9ubHkgb3V0c3RhbmRpbmcgaXRlbSB3aXRoIHJlc3BlY3QgdG8gdGhlDQo+Pj4+Pj4+Pj4+PiBj dXJyZW50ICB2ZXJzaW9uIG9mIHRoZSBkcmFmdC4gVW5sZXNzIGFueW9uZSBoYXMgYW4gaXNzdWUg d2l0aA0KPj4+Pj4+Pj4+Pj4gdGhlIHByb3Bvc2VkICByZXNvbHV0aW9uLCBJIHJlcXVlc3Qgd2Ug dXBkYXRlIHRoZSBkcmFmdA0KPj4+Pj4+Pj4+Pj4gYWNjb3JkaW5nbHkgYW5kIHRoZW4gdXNlIGl0 ICBhcyB0aGUgYmFzaXMgZm9yIE1hcnksIHRoZQ0KPj4+Pj4+Pj4+Pj4gZG9jdW1lbnQgc2hlcGhl cmQsIHRvIHByb3ZpZGUgYSBwcm90byB3cml0ZXVwLg0KPj4+Pj4+Pj4+Pj4NCj4+Pj4+Pj4+Pj4+ IENoZWVycywNCj4+Pj4+Pj4+Pj4+IENoYXJsZXMNCj4+Pj4+Pj4+Pj4+DQo+Pj4+Pj4+Pj4+Pg0K Pj4+Pj4+Pj4+Pj4gT24gNC8yMC8xNSwgMTA6MzkgQU0sICJDaGFybGVzIEVja2VsDQo+Pj4+Pj4+ Pj4+PiAoZWNrZWxjdSkiPGVja2VsY3VAY2lzY28uY29tPg0KPj4+Pj4+Pj4+Pj4gd3JvdGU6DQo+ Pj4+Pj4+Pj4+Pg0KPj4+Pj4+Pj4+Pj4NCj4+Pj4+Pj4+Pj4+DQo+Pj4+Pj4+Pj4+PiAgICAgICAg DQo+Pj4+Pj4+Pj4+Pj4gSGkgQ2hyaXN0ZXIsDQo+Pj4+Pj4+Pj4+Pj4NCj4+Pj4+Pj4+Pj4+PiBJ IHJlcmVhZCB0aGUgY3VycmVudCBkcmFmdCBhbmQgd2VudCB0aHJvdWdoIHRoZSBmb2xsb3dpbmcN Cj4+Pj4+Pj4+Pj4+PiBNTVVTSUMgdGhyZWFkIG9uIHRoaXMgc3ViamVjdDoNCj4+Pj4+Pj4+Pj4+ PiBodHRwOi8vd3d3LmlldGYub3JnL21haWwtYXJjaGl2ZS93ZWIvbW11c2ljL2N1cnJlbnQvbXNn MTQ2MzEuDQo+Pj4+Pj4+Pj4+Pj4gaA0KPj4+Pj4+Pj4+Pj4+IHQNCj4+Pj4+Pj4+Pj4+PiBtDQo+ Pj4+Pj4+Pj4+Pj4gbA0KPj4+Pj4+Pj4+Pj4+DQo+Pj4+Pj4+Pj4+Pj4gQXMgYSByZXN1bHQsIEkg YmV0dGVyIHVuZGVyc3RhbmQgdGhlIGlzc3VlIHlvdSBhcmUgYWRkcmVzc2luZy4NCj4+Pj4+Pj4+ Pj4+PiBJIHN1Z2dlc3QgdGhlIGZvbGxvd2luZyBjaGFuZ2VzIHRvIGJlIGNvbnNpc3RlbnQgd2l0 aCB3aGF0IGlzDQo+Pj4+Pj4+Pj4+Pj4gYmVpbmcgcHJvcG9zZWQgaW4NCj4+Pj4+Pj4+Pj4+PiBN TVVTSUM6DQo+Pj4+Pj4+Pj4+Pj4NCj4+Pj4+Pj4+Pj4+PiAtLS0tLS0tLS0tLS0NCj4+Pj4+Pj4+ Pj4+PiBTZWN0aW9uIDk6DQo+Pj4+Pj4+Pj4+Pj4NCj4+Pj4+Pj4+Pj4+PiBPTEQ6DQo+Pj4+Pj4+ Pj4+Pj4gRW5kcG9pbnRzIHRoYXQgdXNlIHRoZSBvZmZlci9hbnN3ZXIgbW9kZWwgdG8gZXN0YWJs aXNoIGEgRFRMUw0KPj4+Pj4+Pj4+Pj4+ICAgICAgYXNzb2NpYXRpb24gTVVTVCBzdXBwb3J0IHRo ZSAnc2V0dXAnIGF0dHJpYnV0ZSwgYXMNCj4+Pj4+Pj4+Pj4+PiBkZWZpbmVkIGluIFs3XS4NCj4+ Pj4+Pj4+Pj4+PiBXaGVuIERUTFMgaXMgdXNlZCB3aXRoIFVEUCwgdGhlICdzZXR1cCcgYXR0cmli dXRlIGluZGljYXRlcw0KPj4+Pj4+Pj4+Pj4+IHdoaWNoIG9mIHRoZSBlbmRwb2ludHMgKGNsaWVu dCBvciBmbG9vciBjb250cm9sIHNlcnZlcikNCj4+Pj4+Pj4+Pj4+PiBpbml0aWF0ZXMgdGhlIERU TFMgYXNzb2NpYXRpb24gc2V0dXAuIFRoZSByZXF1aXJlbWVudHMgZm9yIHRoZQ0KPj4+Pj4+Pj4+ Pj4+IG9mZmVyL2Fuc3dlciBleGNoYW5nZSBzcGVjaWZpZWQgaW4gWzEzXSwgU2VjdGlvbiA1IG9m IFsxM10NCj4+Pj4+Pj4+Pj4+PiBNVVNUIGJlIGZvbGxvd2VkIHdoZW4gdXNpbmcgRFRMUy4NCj4+ Pj4+Pj4+Pj4+PiBPZmZlci9hbnN3ZXIgY29uc2lkZXJhdGlvbnMgYXJlIGRlc2NyaWJlZCBpbiBT ZWN0aW9uIDEwLjUuDQo+Pj4+Pj4+Pj4+Pj4NCj4+Pj4+Pj4+Pj4+PiBORVc6DQo+Pj4+Pj4+Pj4+ Pj4gV2hlbiBEVExTIGlzIHVzZWQgd2l0aCBVRFAsIHRoZSByZXF1aXJlbWVudHMgc3BlY2lmaWVk IGluDQo+Pj4+Pj4+Pj4+Pj4gU2VjdGlvbg0KPj4+Pj4+Pj4+Pj4+IDUgb2YgWzEzXSBNVVNUIGJl IGZvbGxvd2VkLg0KPj4+Pj4+Pj4+Pj4+DQo+Pj4+Pj4+Pj4+Pj4NCj4+Pj4+Pj4+Pj4+PiBTZWN0 aW9uIDEwLjUNCj4+Pj4+Pj4+Pj4+Pg0KPj4+Pj4+Pj4+Pj4+IE9MRA0KPj4+Pj4+Pj4+Pj4+ICAg ICAgSWYgdGhlIHRyYW5zcG9ydCBwYXJhbWV0ZXJzIG9yIHRoZSBrZXkgZmluZ2VycHJpbnRzDQo+ Pj4+Pj4+Pj4+Pj4gY2hhbmdlLCB0aGUNCj4+Pj4+Pj4+Pj4+PiAgICAgIGVuZHBvaW50cyBNVVNU IGVzdGFibGlzaCBhIG5ldyBEVExTIGNvbm5lY3Rpb24uICBJbiBzdWNoDQo+Pj4+Pj4+Pj4+Pj4g Y2FzZSB0aGUNCj4+Pj4+Pj4+Pj4+PiAgICAgICdhY3RpdmUvcGFzc2l2ZScgc3RhdHVzIG9mIHRo ZSBlbmRwb2ludHMgd2lsbCBhZ2FpbiBiZQ0KPj4+Pj4+Pj4+Pj4+IGRldGVybWluZWQNCj4+Pj4+ Pj4+Pj4+PiAgICAgIGZvbGxvd2luZyB0aGUgcHJvY2VkdXJlcyBpbiBbN10sIGFuZCB0aGUgbmV3 IHN0YXR1cyB3aWxsDQo+Pj4+Pj4+Pj4+Pj4gYmUgdXNlZCB0bw0KPj4+Pj4+Pj4+Pj4+ICAgICAg ZGV0ZXJtaW5lIHRoZSBUTFMgcm9sZXMgYXNzb2NpYXRlZCB3aXRoIHRoZSBuZXcgRFRMUw0KPj4+ Pj4+Pj4+Pj4+IGNvbm5lY3Rpb24uDQo+Pj4+Pj4+Pj4+Pj4NCj4+Pj4+Pj4+Pj4+PiAgICAgICAg IEluZm9ybWF0aW9uYWwgbm90ZTogVGhlIHByb2NlZHVyZSBhYm92ZSBpcyBpZGVudGljYWwNCj4+ Pj4+Pj4+Pj4+PiB0byB0aGUgb25lDQo+Pj4+Pj4+Pj4+Pj4gICAgICAgICBkZWZpbmVkIGZvciBE VExTLVNSVFAgaW4gWzEzXS4NCj4+Pj4+Pj4+Pj4+Pg0KPj4+Pj4+Pj4+Pj4+ICAgICAgICAgTm90 ZTogQSBuZXcgRFRMUyBjb25uZWN0aW9uIG5lZWRzIHRvIGJlIGVzdGFibGlzaGVkIGlmDQo+Pj4+ Pj4+Pj4+Pj4gdGhlDQo+Pj4+Pj4+Pj4+Pj4gICAgICAgICB0cmFuc3BvcnQgcGFyYW1ldGVycyBv ciB0aGUga2V5IGZpbmdlcnByaW50cyBjaGFuZ2UuDQo+Pj4+Pj4+Pj4+Pj4NCj4+Pj4+Pj4+Pj4+ Pg0KPj4+Pj4+Pj4+Pj4+DQo+Pj4+Pj4+Pj4+Pj4gTkVXOg0KPj4+Pj4+Pj4+Pj4+IFRoZSBjb25k aXRpb25zIHVuZGVyIHdoaWNoIGVuZHBvaW50cyBNVVNUIGVzdGFibGlzaCBhIG5ldw0KPj4+Pj4+ Pj4+Pj4+IERUTFMgY29ubmVjdGlvbiBhcmUgYXMgdGhlIHNhbWUgZGVmaW5lZCBmb3IgRFRMUy1T UlRQIGluIFsxM10uDQo+Pj4+Pj4+Pj4+Pj4g4oCU4oCU4oCU4oCU4oCU4oCU4oCU4oCUDQo+Pj4+ Pj4+Pj4+Pj4NCj4+Pj4+Pj4+Pj4+PiBUaGlzIHdheSB3ZSBhdm9pZCBhbnkgcG90ZW50aWFsIGNv bmZsaWN0cyB3aXRoIHRoZSBpbnRlbnQgb2YNCj4+Pj4+Pj4+Pj4+PiBSRkMgNTc2MywgYW5kIHdo ZW4gY2xhcmlmaWNhdGlvbnMgdG8gUkZDIDU3NjMgYXJlIG1hZGUsIHRoZXkNCj4+Pj4+Pj4+Pj4+ PiB3aWxsIGJlIHBpY2tlZCB1cCBieSB0aGUgQkZDUCBzcGVjLg0KPj4+Pj4+Pj4+Pj4+DQo+Pj4+ Pj4+Pj4+Pj4gQ2hlZXJzLA0KPj4+Pj4+Pj4+Pj4+IENoYXJsZXMNCj4+Pj4+Pj4+Pj4+Pg0KPj4+ Pj4+Pj4+Pj4+DQo+Pj4+Pj4+Pj4+Pj4NCj4+Pj4+Pj4+Pj4+Pg0KPj4+Pj4+Pj4+Pj4+IE9uIDQv MTgvMTUsIDI6MDEgUE0sICJDaHJpc3Rlcg0KPj4+Pj4+Pj4+Pj4+IEhvbG1iZXJnIjxjaHJpc3Rl ci5ob2xtYmVyZ0Blcmljc3Nvbi5jb20+DQo+Pj4+Pj4+Pj4+Pj4gd3JvdGU6DQo+Pj4+Pj4+Pj4+ Pj4NCj4+Pj4+Pj4+Pj4+Pg0KPj4+Pj4+Pj4+Pj4+DQo+Pj4+Pj4+Pj4+Pj4gICAgICAgDQo+Pj4+ Pj4+Pj4+Pj4+IEhpIENoYXJsZXMsDQo+Pj4+Pj4+Pj4+Pj4+DQo+Pj4+Pj4+Pj4+Pj4+DQo+Pj4+ Pj4+Pj4+Pj4+DQo+Pj4+Pj4+Pj4+Pj4+ICAgICAgDQo+Pj4+Pj4+Pj4+Pj4+PiBbYWRkaW5nIGJm Y3BwYmlzIGxpc3RdDQo+Pj4+Pj4+Pj4+Pj4+Pg0KPj4+Pj4+Pj4+Pj4+Pj4gSGkgQ2hyaXN0ZXIs DQo+Pj4+Pj4+Pj4+Pj4+Pg0KPj4+Pj4+Pj4+Pj4+Pj4gVGhhbmtzIGZvciB5b3VyIHJldmlldyBh bmQgY29tbWVudHMuIEluIHRoZSBCRkNQIHVzYWdlLCB0aGUNCj4+Pj4+Pj4+Pj4+Pj4+IERUTFMg Y29ubmVjdGlvbiBpcyBkZWRpY2F0ZWQgdG8gdGhlIEJGQ1Agc3RyZWFtIGl0IGNvbnRhaW5zLg0K Pj4+Pj4+Pj4+Pj4+Pj4gQXMgSSB1bmRlcnN0YW5kIGl0LCB0aGUgY29tcGxpY2F0aW9ucyBhcm91 bmQgRFRMUw0KPj4+Pj4+Pj4+Pj4+Pj4gcmUtZXN0YWJsaXNoZW1lbnQgZGlzY3Vzc2VkIGluIE1N VVNJQyByZXN1bHQgZnJvbSB1c2Ugb2YgYQ0KPj4+Pj4+Pj4+Pj4+Pj4gc2luZ2xlIERUTFMgY29u bmVjdGlvbiBmb3IgbXVsdGlwbGUgUlRQIGFuZC9vciBTQ1RQIHN0cmVhbXMuDQo+Pj4+Pj4+Pj4+ Pj4+PiBUaG9zZSBjb21wbGljYXRpb25zIGRvIG5vdCBleGlzdCB3aXRoIHRoZSBCRkNQIHVzYWdl LCBzbyBJDQo+Pj4+Pj4+Pj4+Pj4+PiB0aGluayBpdCBpcyBzdWZmaWNpZW50IHRvIGNvbnRpbnVl IHRvIHJlZmVyZW5jZSBSRkMgNTc2MyBhbmQNCj4+Pj4+Pj4+Pj4+Pj4+IG5vdCB1c2UgdGhlIFNE UCBjb25uZWN0aW9uIGF0dHJpYnV0ZS4NCj4+Pj4+Pj4+Pj4+Pj4+DQo+Pj4+Pj4+Pj4+Pj4+Pg0K Pj4+Pj4+Pj4+Pj4+Pj4gICAgIA0KPj4+Pj4+Pj4+Pj4+PiBUaGUgY29tcGxpY2F0aW9ucyBkbyBu b3QgcmVzdWx0IGZyb20gdXNlIG9mIGEgc2luZ2xlIERUTFMNCj4+Pj4+Pj4+Pj4+Pj4gY29ubmVj dGlvbiBmb3IgbXVsdGlwbGUgc3RyZWFtcyAtIGl0IG1haW5seSByZXN1bHRzIGZyb20gdGhlDQo+ Pj4+Pj4+Pj4+Pj4+IHVzYWdlIG9mIElDRS4gQW5kLCBhcyBmYXIgYXMgSSBrbm93LCBJQ0UgY2Fu IGJlIHVzZWQgYWxzbyBmb3INCj4+Pj4+Pj4+Pj4+Pj4gQkZDUC4NCj4+Pj4+Pj4+Pj4+Pj4NCj4+ Pj4+Pj4+Pj4+Pj4gQW5kLCBldmVuIHdpdGhvdXQgSUNFIHdlIGludGVuZCB0byBhZGQgdGV4dCBz YXlpbmcgdGhhdCBhDQo+Pj4+Pj4+Pj4+Pj4+IERUTFMgY29ubmVjdGlvbiBpcyBvbmx5IHJlLWVz dGFibGlzaGVkIGlmIHRoZSB1bmRlcmx5aW5nDQo+Pj4+Pj4+Pj4+Pj4+IHRyYW5zcG9ydCBjaGFu Z2VzLg0KPj4+Pj4+Pj4+Pj4+Pg0KPj4+Pj4+Pj4+Pj4+PiBSZWdhcmRzLA0KPj4+Pj4+Pj4+Pj4+ Pg0KPj4+Pj4+Pj4+Pj4+PiBDaHJpc3Rlcg0KPj4+Pj4+Pj4+Pj4+Pg0KPj4+Pj4+Pj4+Pj4+Pg0K Pj4+Pj4+Pj4+Pj4+Pg0KPj4+Pj4+Pj4+Pj4+Pg0KPj4+Pj4+Pj4+Pj4+Pg0KPj4+Pj4+Pj4+Pj4+ PiAgICAgIA0KPj4+Pj4+Pj4+Pj4+Pj4gSGksDQo+Pj4+Pj4+Pj4+Pj4+Pg0KPj4+Pj4+Pj4+Pj4+ Pj4gRmlyc3QsIEkgd2FudCB0byBhcG9sb2dpemUgZm9yIG5vdCBwcm92aWRpbmcgbXkgcmV2aWV3 DQo+Pj4+Pj4+Pj4+Pj4+PiBlYXJsaWVyLg0KPj4+Pj4+Pj4+Pj4+Pj4NCj4+Pj4+Pj4+Pj4+Pj4+ IEFzIGZhciBhcyB0aGUgQkZDUCBzcGVjaWZpY3MgYXJlIGNvbmNlcm5lZCwgSSBhbSBvayB3aXRo DQo+Pj4+Pj4+Pj4+Pj4+PiB0aGUgbGF0ZXN0IHZlcnNpb24gb2YgdGhlIGRyYWZ0Lg0KPj4+Pj4+ Pj4+Pj4+Pj4NCj4+Pj4+Pj4+Pj4+Pj4+IEhvd2V2ZXIsIHRoZXJlIGlzIGFuIGlzc3VlIHJlZ2Fy ZGluZyB0aGUgRFRMUw0KPj4+Pj4+Pj4+Pj4+Pj4gY29uc2lkZXJhdGlvbnMgKHNlY3Rpb24gMTAu NSkuDQo+Pj4+Pj4+Pj4+Pj4+Pg0KPj4+Pj4+Pj4+Pj4+Pj4gVGhlIHRleHQgc2F5czoNCj4+Pj4+ Pj4+Pj4+Pj4+DQo+Pj4+Pj4+Pj4+Pj4+PiAJIk9uY2UgYSBEVExTIGNvbm5lY3Rpb24gaGFzIGJl ZW4gZXN0YWJsaXNoZWQsIGlmIHRoZQ0KPj4+Pj4+Pj4+Pj4+Pj4gJ2FjdGl2ZS9wYXNzaXZlJw0K Pj4+Pj4+Pj4+Pj4+Pj4gICAgICAJc3RhdHVzIG9mIHRoZSBlbmRwb2ludHMgY2hhbmdlIGR1cmlu ZyBhIHNlc3Npb24sIGEgbmV3DQo+Pj4+Pj4+Pj4+Pj4+PiBEVExTDQo+Pj4+Pj4+Pj4+Pj4+PiAg ICAgIAljb25uZWN0aW9uIE1VU1QgYmUgZXN0YWJsaXNoZWQuIg0KPj4+Pj4+Pj4+Pj4+Pj4NCj4+ Pj4+Pj4+Pj4+Pj4+IFRoZXJlIGlzIGN1cnJlbnRseSBhbiBvbmdvaW5nIGRpc2N1c3Npb24gaW4g TU1VU0lDIGFib3V0DQo+Pj4+Pj4+Pj4+Pj4+PiB3aGVuIGEgRFRMUyBjb25uZWN0aW9uIGlzIHRv IGJlIHJlLWVzdGFibGlzaGVkLg0KPj4+Pj4+Pj4+Pj4+Pj4NCj4+Pj4+Pj4+Pj4+Pj4+IFRoZSBk aXNjdXNzaW9uIGlzIHN0aWxsIG9uZ29pbmcsIGJ1dCB0aGUgb3V0Y29tZSB3aWxsIG1vc3QNCj4+ Pj4+Pj4+Pj4+Pj4+IGxpa2VseSBOT1QgYmUgYWxpZ25lZCB3aXRoIHRoZSB0ZXh0IGFib3ZlLg0K Pj4+Pj4+Pj4+Pj4+Pj4NCj4+Pj4+Pj4+Pj4+Pj4+IEZvciBleGFtcGxlLCB0aGVyZSBoYXMgYmVl biBhIHN1Z2dlc3Rpb24gKGJ5IG15c2VsZikgdG8gdXNlDQo+Pj4+Pj4+Pj4+Pj4+PiB0aGUgU0RQ IGNvbm5lY3Rpb24gYXR0cmlidXRlIHRvIGV4cGxpY2l0bHkgaW5kaWNhdGUgdGhhdCBhDQo+Pj4+ Pj4+Pj4+Pj4+PiBuZXcgRFRMUyBjb25uZWN0aW9uIG5lZWRzIHRvIGJlIGVzdGFibGlzaGVkLg0K Pj4+Pj4+Pj4+Pj4+Pj4NCj4+Pj4+Pj4+Pj4+Pj4+DQo+Pj4+Pj4+Pj4+Pj4+PiBUaGUgZHJhZnQg YWxzbyBzYXlzOg0KPj4+Pj4+Pj4+Pj4+Pj4NCj4+Pj4+Pj4+Pj4+Pj4+IAkiSWYgdGhlIHRyYW5z cG9ydCBwYXJhbWV0ZXJzIG9yIHRoZSBrZXkgZmluZ2VycHJpbnRzDQo+Pj4+Pj4+Pj4+Pj4+PiBj aGFuZ2UsIHRoZQ0KPj4+Pj4+Pj4+Pj4+Pj4gICAgICAJZW5kcG9pbnRzIE1VU1QgZXN0YWJsaXNo IGEgbmV3IERUTFMgY29ubmVjdGlvbi4iDQo+Pj4+Pj4+Pj4+Pj4+Pg0KPj4+Pj4+Pj4+Pj4+Pj4g VGhpcyBpcyByZWxhdGVkIHRvIHRoZSBlYXJsaWVyIGlzc3VlLiBUaGVyZSBpcyB0aGUNCj4+Pj4+ Pj4+Pj4+Pj4+IGRpc2N1c3Npb24gYWJvdXQgSUNFICJ2aXJ0dWFsIGNvbm5lY3Rpb25zIiwgYW5k IHRoYXQgYQ0KPj4+Pj4+Pj4+Pj4+Pj4gc2luZ2xlIERUTFMgY29ubmVjdGlvbiB3b3VsZCBhcHBs eSB0byBhbGwgSUNFIGNhbmRpZGF0ZXMNCj4+Pj4+Pj4+Pj4+Pj4+IGFzc29jaWF0ZWQgd2l0aCBh bg0KPj4+Pj4+Pj4+Pj4+Pj4gbS0gbGluZS4gU28sIGV2ZW4gaWYgYSBjYW5kaWRhdGUgY2hhbmdl cyAocmVhZDogdHJhbnNwb3J0DQo+Pj4+Pj4+Pj4+Pj4+PiBwYXJhbWV0ZXIgY2hhbmdlcyksIGl0 IHdvdWxkIG5vdCBhdXRvbWF0aWNhbGx5IHRyaWdnZXIgYSBuZXcNCj4+Pj4+Pj4+Pj4+Pj4+IERU TFMgY29ubmVjdGlvbi4NCj4+Pj4+Pj4+Pj4+Pj4+DQo+Pj4+Pj4+Pj4+Pj4+Pg0KPj4+Pj4+Pj4+ Pj4+Pj4gVGhlIGlzc3VlcyBhYm92ZSBhcmUgYWxzbyBob2xkaW5nIHVwIHRoZSBTQ1RQLVNEUCBk cmFmdCwgc28NCj4+Pj4+Pj4+Pj4+Pj4+IGl0IGRvZXNuJ3Qgb25seSBhZmZlY3QgQkZDUGJpcyA6 KQ0KPj4+Pj4+Pj4+Pj4+Pj4NCj4+Pj4+Pj4+Pj4+Pj4+DQo+Pj4+Pj4+Pj4+Pj4+PiBSZWdhcmRz LA0KPj4+Pj4+Pj4+Pj4+Pj4NCj4+Pj4+Pj4+Pj4+Pj4+IENocmlzdGVyDQo+Pj4+Pj4+Pj4+Pj4+ Pg0KPj4+Pj4+Pj4+Pj4+Pj4NCj4+Pj4+Pj4+Pj4+Pj4+IC0tLS0tT3JpZ2luYWwgTWVzc2FnZS0t LS0tDQo+Pj4+Pj4+Pj4+Pj4+PiBGcm9tOiBBbGlzc2EgQ29vcGVyIFttYWlsdG86YWxpc3NhQGNv b3BlcncuaW5dDQo+Pj4+Pj4+Pj4+Pj4+PiBTZW50OiA4LiBodWh0aWt1dXRhIDIwMTUgMzowNw0K Pj4+Pj4+Pj4+Pj4+Pj4gVG86IENoYXJsZXMgRWNrZWwgKGVja2VsY3UpDQo+Pj4+Pj4+Pj4+Pj4+ PiBDYzogR29uemFsbyBDYW1hcmlsbG87IFRvbSBLcmlzdGVuc2VuICh0b21rcmlzdCk7DQo+Pj4+ Pj4+Pj4+Pj4+PiBkcmFmdC1pZXRmLWJmY3BiaXMtcmZjNDU4MmJpc0B0b29scy5pZXRmLm9yZzsg QmVuIENhbXBiZWxsOw0KPj4+Pj4+Pj4+Pj4+Pj4gQ2hyaXN0ZXIgSG9sbWJlcmcNCj4+Pj4+Pj4+ Pj4+Pj4+IFN1YmplY3Q6IFJlOiBkcmFmdC1pZXRmLWJmY3BiaXMtcmZjNDU4M2Jpcw0KPj4+Pj4+ Pj4+Pj4+Pj4NCj4+Pj4+Pj4+Pj4+Pj4+IEFkZGluZyBDaHJpc3RlciB0byB0aGlzIHRocmVhZC4N Cj4+Pj4+Pj4+Pj4+Pj4+DQo+Pj4+Pj4+Pj4+Pj4+PiBPbiBBcHIgNywgMjAxNSwgYXQgMTI6NDQg UE0sIENoYXJsZXMgRWNrZWwgKGVja2VsY3UpDQo+Pj4+Pj4+Pj4+Pj4+PiA8ZWNrZWxjdUBjaXNj by5jb20+DQo+Pj4+Pj4+Pj4+Pj4+PiB3cm90ZToNCj4+Pj4+Pj4+Pj4+Pj4+DQo+Pj4+Pj4+Pj4+ Pj4+Pg0KPj4+Pj4+Pj4+Pj4+Pj4NCj4+Pj4+Pj4+Pj4+Pj4+ICAgICANCj4+Pj4+Pj4+Pj4+Pj4+ PiBDaHJpc3RlciAoY2PigJlkKSBhbmQgSSBkaXNjdXNzZWQgc29tZSBvZiB0aGUgY2hhbmdlcw0K Pj4+Pj4+Pj4+Pj4+Pj4+IG9mZmxpc3QgaW4gRGFsbGFzLCBhbmQgaGUgaXMgdG8gY29tZSBiYWNr IHRvIHRoZSBsaXN0IHdpdGgNCj4+Pj4+Pj4+Pj4+Pj4+PiBjb21tZW50cyBhZnRlciBEYWxsYXMN Cj4+Pj4+Pj4+Pj4+Pj4+PiAtIHdoaWNoIGlzIG5vdyA6KQ0KPj4+Pj4+Pj4+Pj4+Pj4+DQo+Pj4+ Pj4+Pj4+Pj4+Pj4gQ2hlZXJzLA0KPj4+Pj4+Pj4+Pj4+Pj4+IENoYXJsZXMNCj4+Pj4+Pj4+Pj4+ Pj4+Pg0KPj4+Pj4+Pj4+Pj4+Pj4+IE9uIDQvNy8xNSwgMTA6MjYgQU0sICJBbGlzc2EgQ29vcGVy IjxhbGlzc2FAY29vcGVydy5pbj4NCj4+Pj4+Pj4+Pj4+Pj4+PiB3cm90ZToNCj4+Pj4+Pj4+Pj4+ Pj4+Pg0KPj4+Pj4+Pj4+Pj4+Pj4+DQo+Pj4+Pj4+Pj4+Pj4+Pj4NCj4+Pj4+Pj4+Pj4+Pj4+PiAg ICANCj4+Pj4+Pj4+Pj4+Pj4+Pj4gQ2hlY2tpbmcgaW4gb24gdGhpcyDigJQgaGFzIENocmlzdGVy IGJlZW4gcHJvbXB0ZWQgdG8NCj4+Pj4+Pj4+Pj4+Pj4+Pj4gcmV2aWV3IHRoZSBsYXRlc3QgcmV2 IG9mIGRyYWZ0LWlldGYtYmZjcGJpcy1yZmM0NTgzYmlzPw0KPj4+Pj4+Pj4+Pj4+Pj4+Pg0KPj4+ Pj4+Pj4+Pj4+Pj4+PiBUaGFua3MsDQo+Pj4+Pj4+Pj4+Pj4+Pj4+IEFsaXNzYQ0KPj4+Pj4+Pj4+ Pj4+Pj4+Pg0KPj4+Pj4+Pj4+Pj4+Pj4+PiBPbiBGZWIgMjUsIDIwMTUsIGF0IDk6MTQgQU0sIENo YXJsZXMgRWNrZWwgKGVja2VsY3UpDQo+Pj4+Pj4+Pj4+Pj4+Pj4+IDxlY2tlbGN1QGNpc2NvLmNv bT4NCj4+Pj4+Pj4+Pj4+Pj4+Pj4gd3JvdGU6DQo+Pj4+Pj4+Pj4+Pj4+Pj4+DQo+Pj4+Pj4+Pj4+ Pj4+Pj4+DQo+Pj4+Pj4+Pj4+Pj4+Pj4+DQo+Pj4+Pj4+Pj4+Pj4+Pj4+ICAgDQo+Pj4+Pj4+Pj4+ Pj4+Pj4+PiBNb3N0IG9mIHRoZSBjaGFuZ2VzIEkgdGhpcyByZWNlbnQgdXBkYXRlIHRvIHJmYzQ1 ODNiaXMNCj4+Pj4+Pj4+Pj4+Pj4+Pj4+IHdlcmUgaW5zcGlyZWQgYnkgY29tbWVudHMgYW5kIHN1 Z2dlc3RlZCB0ZXh0IHByb3ZpZGVkIGJ5DQo+Pj4+Pj4+Pj4+Pj4+Pj4+PiBDaHJpc3Rlci4NCj4+ Pj4+Pj4+Pj4+Pj4+Pj4+IEhlIGlzIGluIHRoZSBwcm9jZXNzIG9mIHJldmlld2luZy4gSWYgYWxs IGdvZXMgd2VsbCB3aXRoDQo+Pj4+Pj4+Pj4+Pj4+Pj4+PiB0aGF0LCB3ZSBhcmUgcmVhZHkgdG8g cHJvY2VlZCB3aXRoIHByb3RvIHdyaXRldXAgKE1hcnkpDQo+Pj4+Pj4+Pj4+Pj4+Pj4+PiBhbmQg QUQgcmV2aWV3Lg0KPj4+Pj4+Pj4+Pj4+Pj4+Pj4NCj4+Pj4+Pj4+Pj4+Pj4+Pj4+IENoZWVycywN Cj4+Pj4+Pj4+Pj4+Pj4+Pj4+IENoYXJsZXMNCj4+Pj4+Pj4+Pj4+Pj4+Pj4+DQo+Pj4+Pj4+Pj4+ Pj4+Pj4+PiBPbiAyLzI1LzE1LCA3OjAxIEFNLCAiQWxpc3NhIENvb3BlciI8YWxpc3NhQGNvb3Bl cncuaW4+DQo+Pj4+Pj4+Pj4+Pj4+Pj4+PiB3cm90ZToNCj4+Pj4+Pj4+Pj4+Pj4+Pj4+DQo+Pj4+ Pj4+Pj4+Pj4+Pj4+Pg0KPj4+Pj4+Pj4+Pj4+Pj4+Pj4NCj4+Pj4+Pj4+Pj4+Pj4+Pj4+ICANCj4+ Pj4+Pj4+Pj4+Pj4+Pj4+PiByZmM0NTgzIGhhcyBub3QgaGFkIGFuIEFEIHJldmlldyB5ZXQuIFJp Y2hhcmQgY2FuDQo+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4gaG9wZWZ1bGx5IHRha2UgY2FyZSBvZiB0aGF0 IHdoaWxlIEnCuW0gb24gbGVhdmUgKHN0YXJ0aW5nDQo+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4gdG9kYXks IGFjdHVhbGx5KS4NCj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pg0KPj4+Pj4+Pj4+Pj4+Pj4+Pj4+IE9uIEZl YiAyNSwgMjAxNSwgYXQgMjo1NiBBTSwgR29uemFsbyBDYW1hcmlsbG8NCj4+Pj4+Pj4+Pj4+Pj4+ Pj4+PiA8Z29uemFsby5jYW1hcmlsbG9AZXJpY3Nzb24uY29tPiAgICB3cm90ZToNCj4+Pj4+Pj4+ Pj4+Pj4+Pj4+Pg0KPj4+Pj4+Pj4+Pj4+Pj4+Pj4+DQo+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4NCj4+Pj4+ Pj4+Pj4+Pj4+Pj4+PiANCj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4gSGkgQWxpc3NhLA0KPj4+Pj4+Pj4+ Pj4+Pj4+Pj4+Pg0KPj4+Pj4+Pj4+Pj4+Pj4+Pj4+PiBJIGhhdmUgbm90ZWQgdGhhdCB3aGlsZSBy ZmM0NTgyYmlzIGluIG9uIHRoZSBhZ2VuZGEgb2YNCj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4gdGhlIE1h cmNoIDV0aCB0ZWxlY2hhdCAodGhhbmtzIGZvciBoYW5kbGluZyB0aGF0ISksDQo+Pj4+Pj4+Pj4+ Pj4+Pj4+Pj4+IHJmYzQ1ODNiaXMgaXNuJ3QuIFRvbSByZXZpc2VkIHJmYzQ1ODNiaXMgb24gRmVi cnVhcnkNCj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4gMjB0aC4gU2hvdWxkIHJmYzQ1ODNiaXMgYmUgb24g dGhlIGFnZW5kYSBvZiB0aGUNCj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4gdGVsZWNoYXQgYXMgd2VsbCBv ciB0aGVyZSBpcyBzdGlsbCBzb21ldGhpbmcgbGVmdCBmb3INCj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4g VG9tIHRvIHRha2UgY2FyZSBvZj8NCj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4NCj4+Pj4+Pj4+Pj4+Pj4+ Pj4+Pj4gVGhhbmtzLA0KPj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pg0KPj4+Pj4+Pj4+Pj4+Pj4+Pj4+PiBH b256YWxvDQo+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+DQo+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+IE9uIDE4LzAy LzIwMTUgOToyOCBQTSwgQWxpc3NhIENvb3BlciB3cm90ZToNCj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4N Cj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4NCj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4NCj4+Pj4+Pj4+Pj4+Pj4+ Pj4+Pj4+IFBpbmdpbmcgb24gdGhpcy4NCj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+DQo+Pj4+Pj4+Pj4+ Pj4+Pj4+Pj4+PiBNYXJjaCA1IHdpbGwgbGlrZWx5IGJlIG15IGxhc3QgdGVsZWNoYXQgYmVmb3Jl IGdvaW5nDQo+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+PiBvbiBsZWF2ZSwgc28gIGl0IHdvdWxkIGJlIGdy ZWF0IHRvIGdldCB0aGlzIHNjaGVkdWxlZA0KPj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4gb24gdGhhdCBv bmUuIFRvIGRvIHRoYXQsICB0aGUgcmV2IG5lZWRzIHRvIGJlIHBvc3RlZA0KPj4+Pj4+Pj4+Pj4+ Pj4+Pj4+Pj4gdG9kYXkuDQo+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+PiBUaGUgdXBkYXRlcyBhcmUgcHJl dHR5IG1pbmltYWwgIGFuZCBhcmUgYWxsIGJhc2ljYWxseQ0KPj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4g d3JpdHRlbiB1cCBpbiBDaGFybGVzwrkgcmVzcG9uc2UgdG8gbXkgQUQgcmV2aWV3Lg0KPj4+Pj4+ Pj4+Pj4+Pj4+Pj4+Pj4NCj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+IEFsaXNzYQ0KPj4+Pj4+Pj4+Pj4+ Pj4+Pj4+Pj4NCj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+IE9uIEZlYiAxNSwgMjAxNSwgYXQgOToxMyBB TSwgR29uemFsbyBDYW1hcmlsbG8NCj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+IDxnb256YWxvLmNhbWFy aWxsb0Blcmljc3Nvbi5jb20NCj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+IDxtYWlsdG86Z29uemFsby5j YW1hcmlsbG9AZXJpY3Nzb24uY29tPj4NCj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+IHdyb3RlOg0KPj4+ Pj4+Pj4+Pj4+Pj4+Pj4+Pj4NCj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+DQo+Pj4+Pj4+Pj4+Pj4+Pj4+ Pj4+Pg0KPj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4NCj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+PiBJIGhhdmUg dGFsa2VkIG9mZmxpbmUgd2l0aCB0aGUgb3RoZXIgYXV0aG9ycyBhbmQgVG9tDQo+Pj4+Pj4+Pj4+ Pj4+Pj4+Pj4+Pj4gaXMgaG9sZGluZyB0aGUgcGVuLiBUb20sIGRvIHlvdSB0aGluayB5b3UgY2Fu IG1lZXQNCj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+PiB0aGUgdGltZSBmcmFtZSBiZWxvdz8NCj4+Pj4+ Pj4+Pj4+Pj4+Pj4+Pj4+Pg0KPj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+IENoZWVycywNCj4+Pj4+Pj4+ Pj4+Pj4+Pj4+Pj4+Pg0KPj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+IEdvbnphbG8NCj4+Pj4+Pj4+Pj4+ Pj4+Pj4+Pj4+Pg0KPj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+IFNlbnQgZnJvbSBteSBtb2JpbGUNCj4+ Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pg0KPj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+DQo+Pj4+Pj4+Pj4+Pj4+ Pj4+Pj4+Pj4NCj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+PiAtLS0tIEFsaXNzYSBDb29wZXIgd3JvdGUg LS0tLQ0KPj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+DQo+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4gSnVzdCB3 YW50ZWQgdG8gc2VlIGlmIHRoaXMgcmV2IG1pZ2h0IGdldCBkb25lIGluIHRoZQ0KPj4+Pj4+Pj4+ Pj4+Pj4+Pj4+Pj4+IG5leHQgY291cGxlICBvZiBkYXlzLiBJZiBzbywgd2UgY291bGQgZ2V0IGl0 IG9uIHRoZQ0KPj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+IG5leHQgdGVsZWNoYXQgYWdlbmRhIChNYXJj aCA1KS4NCj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pg0KPj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+IEFsaXNz YQ0KPj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+DQo+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4gQmVnaW4gZm9y d2FyZGVkIG1lc3NhZ2U6DQo+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4NCj4+Pj4+Pj4+Pj4+Pj4+Pj4+ Pj4+Pg0KPj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+DQo+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4NCj4+Pj4+ Pj4+Pj4+Pj4+Pj4+Pj4+Pj4gKkZyb206ICpBbGlzc2EgQ29vcGVyPGFsaXNzYUBjb29wZXJ3Lmlu DQo+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+IDxtYWlsdG86YWxpc3NhQGNvb3BlcncuaW4+Pg0KPj4+ Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+PiAqU3ViamVjdDogKipSZTogW2JmY3BiaXNdIEFEIGV2YWx1YXRp b246DQo+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+IGRyYWZ0LWlldGYtYmZjcGJpcy1yZmM0NTgyYmlz LTEyKg0KPj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+PiAqRGF0ZTogKkZlYnJ1YXJ5IDksIDIwMTUgYXQg Mzo1ODo1MiBQTSBQU1QNCj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4gKlRvOiAqIkNoYXJsZXMgRWNr ZWwgKGVja2VsY3UpIjxlY2tlbGN1QGNpc2NvLmNvbQ0KPj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+PiA8 bWFpbHRvOmVja2VsY3VAY2lzY28uY29tPj4NCj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4gKkNjOiAq ImJmY3BiaXNAaWV0Zi5vcmc8bWFpbHRvOmJmY3BiaXNAaWV0Zi5vcmc+Ig0KPj4+Pj4+Pj4+Pj4+ Pj4+Pj4+Pj4+PiA8YmZjcGJpc0BpZXRmLm9yZw0KPj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+PiA8bWFp bHRvOmJmY3BiaXNAaWV0Zi5vcmc+Pg0KPj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pg0KPj4+Pj4+Pj4+ Pj4+Pj4+Pj4+Pj4+PiBIaSBDaGFybGVzLA0KPj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pg0KPj4+Pj4+ Pj4+Pj4+Pj4+Pj4+Pj4+PiBUaGFua3MsIHNvbWUgcmVzcG9uc2VzIGlubGluZS4NCj4+Pj4+Pj4+ Pj4+Pj4+Pj4+Pj4+Pj4NCj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4gT24gRmViIDQsIDIwMTUsIGF0 IDEwOjQwIEFNLCBDaGFybGVzIEVja2VsIChlY2tlbGN1KQ0KPj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+ PiA8ZWNrZWxjdUBjaXNjby5jb208bWFpbHRvOmVja2VsY3VAY2lzY28uY29tPj4gICAgd3JvdGU6 DQo+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+DQo+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+DQo+Pj4+Pj4+ Pj4+Pj4+Pj4+Pj4+Pj4+DQo+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+DQo+Pj4+Pj4+Pj4+Pj4+Pj4+ Pj4+Pj4+PiBISSBBbGlzc2EsDQo+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pg0KPj4+Pj4+Pj4+Pj4+ Pj4+Pj4+Pj4+Pj4gVGhhbmsgeW91IGZvciB0aGUgcmV2aWV3LiBQbGVhc2Ugc2VlIG15IHRob3Vn aHRzDQo+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+PiBvbiB5b3VyIGNvbW1lbnRzIGFuZCBxdWVzdGlv bnMgaW5saW5lLg0KPj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4NCj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+ Pj4+IEZyb206IEFsaXNzYSBDb29wZXI8YWxpc3NhQGNvb3BlcncuaW4NCj4+Pj4+Pj4+Pj4+Pj4+ Pj4+Pj4+Pj4+IDxtYWlsdG86YWxpc3NhQGNvb3BlcncuaW4+Pg0KPj4+Pj4+Pj4+Pj4+Pj4+Pj4+ Pj4+Pj4gRGF0ZTogVGh1cnNkYXksIEphbnVhcnkgMjksIDIwMTUgYXQgMTA6MTkgUE0NCj4+Pj4+ Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+IFRvOiAiYmZjcGJpc0BpZXRmLm9yZzxtYWlsdG86YmZjcGJpc0Bp ZXRmLm9yZz4iDQo+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+PiA8YmZjcGJpc0BpZXRmLm9yZzxtYWls dG86YmZjcGJpc0BpZXRmLm9yZz4+DQo+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+PiBTdWJqZWN0OiBb YmZjcGJpc10gQUQgZXZhbHVhdGlvbjoNCj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+IGRyYWZ0LWll dGYtYmZjcGJpcy1yZmM0NTgyYmlzLTEyDQo+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pg0KPj4+Pj4+ Pj4+Pj4+Pj4+Pj4+Pj4+Pj4NCj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+DQo+Pj4+Pj4+Pj4+Pj4+ Pj4+Pj4+Pj4+Pg0KPj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+IEkgaGF2ZSByZXZpZXdlZCB0aGlz IGRyYWZ0IGluIHByZXBhcmF0aW9uIGZvciBJRVRGIExDLg0KPj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+ Pj4+IE92ZXJhbGwgdGhlIGRvY3VtZW50IGFwcGVhcnMgaW4gZ29vZCBzaGFwZS4gSQ0KPj4+Pj4+ Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+IGhhdmUgYSBmZXcgcXVlc3Rpb25zIGFuZCBjb21tZW50cyBJwrlk IGxpa2UgdG8NCj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+PiBkaXNjdXNzIGJlZm9yZSBpc3N1aW5n IHRoZSBJRVRGIGxhc3QgY2FsbC4gScK5dmUNCj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+PiBhbHNv IGluY2x1ZGVkIHNvbWUgZWRpdG9yaWFsIG5pdHMgdGhhdCBzaG91bGQgYmUNCj4+Pj4+Pj4+Pj4+ Pj4+Pj4+Pj4+Pj4+PiBhZGRyZXNzZWQgdG9nZXRoZXIgd2l0aCBhbnkgbGFzdCBjYWxsIGNvbW1l bnRzLg0KPj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+DQo+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4g Q29tbWVudHMgYW5kIHF1ZXN0aW9uczoNCj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pg0KPj4+Pj4+ Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+ID0gU2VjdGlvbiA1LjEgPQ0KPj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+ Pj4+ICJJZiBhbiBlbmRwb2ludCByZWNlaXZlcyBhIG1lc3NhZ2Ugd2l0aCBhbg0KPj4+Pj4+Pj4+ Pj4+Pj4+Pj4+Pj4+Pj4+IHVuc3VwcG9ydGVkIHZlcnNpb24gZmllbGQgdmFsdWUsIHRoZSByZWNl aXZpbmcNCj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+PiBzZXJ2ZXIgTVVTVCBzZW5kIGFuIEVycm9y IG1lc3NhZ2Ugd2l0aCBwYXJhbWV0ZXINCj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+PiB2YWx1ZSAx MiAoVW5zdXBwb3J0ZWQNCj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+PiBWZXJzaW9uKSB0byBpbmRp Y2F0ZSB0aGlzLsKyDQo+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4NCj4+Pj4+Pj4+Pj4+Pj4+Pj4+ Pj4+Pj4+PiBUaGlzIHNlZW1zIGEgbGl0dGxlIG1pc2xlYWRpbmcgc2luY2UgUkZDIDQ1ODINCj4+ Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+PiBkaWRuwrl0IHNwZWNpZnkgd2hhdCB0byBkbyB1cG9uIHJl Y2VpcHQgb2YgYQ0KPj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+IG1lc3NhZ2Ugd2l0aCBhIHZlcnNp b24gb3RoZXIgdGhhbiAxLg0KPj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+IEltcGxlbWVudGF0aW9u cyB0aGF0IGRvIG5vdCBnZXQgdXBncmFkZWQgdG8gYmUNCj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+ PiBjb21wbGlhbnQgd2l0aCAgNDU4MmJpcyAod2hpY2ggY291bGQgY2VydGFpbmx5DQo+Pj4+Pj4+ Pj4+Pj4+Pj4+Pj4+Pj4+Pj4gYWNjb3VudCBmb3Igc29tZSBvZiB0aG9zZSB0aGF0ICB3aWxsIG5v dCBzdXBwb3J0DQo+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4gdmVyc2lvbiAyKSB3aWxsIHRoZXJl Zm9yZSBuZXZlciBzZW5kIHRoZSAgZXJyb3INCj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+PiBzcGVj aWZpZWQgaGVyZS4NCj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+PiBUaGlzIHNlZW1zIGxpa2UgaXQg c2hvdWxkIGF0IGxlYXN0IGJlICBub3RlZA0KPj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+IGdpdmVu IHRoZSBNVVNULWxldmVsIHJlcXVpcmVtZW50LiBUaGUgc2FtZSBhcHBsaWVzDQo+Pj4+Pj4+Pj4+ Pj4+Pj4+Pj4+Pj4+Pj4gaW4gU2VjdGlvbiAxMy43Lg0KPj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+ DQo+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4NCj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pg0KPj4+ Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4gR29vZCBwb2ludC4gSSBiZWxpZXZlIHdlIG1hZGUgdGhpcyBh IE1VU1QgYmVjYXVzZQ0KPj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4gd2Ugd2VyZSB0aGlua2luZyBp biB0ZXJtcyBvZiBpbXBsZW1lbnRhdGlvbnMNCj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+IGNvbXBs aWFudCB3aXRoIHRoaXMgYmlzIHZlcnNpb24uDQo+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+PiBBZGRp bmcNCj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+IHlvdXIgc3VnZ2VzdGVkIG5vdGUgYWJvdXQgcmZj IDQ1ODIgaW1wbGVtZW50YXRpb25zDQo+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+PiBoZXJlIGFuZCBp biAgc2VjdGlvbiAxMy43IHNlZW1zIHVzZWZ1bCB0byBtZS4NCj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+ Pj4+DQo+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pg0KPj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4NCj4+ Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4gT2sNCj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4NCj4+Pj4+Pj4+ Pj4+Pj4+Pj4+Pj4+Pj4NCj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4NCj4+Pj4+Pj4+Pj4+Pj4+Pj4+ Pj4+Pj4NCj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+DQo+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pg0K Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+ID0gU2VjdGlvbiA3ID0NCj4+Pj4+Pj4+Pj4+Pj4+Pj4+ Pj4+Pj4+PiAiQkZDUCBlbnRpdGllcyBNVVNUIHN1cHBvcnQsIGF0IGEgbWluaW11bSwgdGhlDQo+ Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4gVExTX1JTQV9XSVRIX0FFU18xMjhfQ0JDX1NIQSBjaXBo ZXJzdWl0ZSBbNl0uwrINCj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pg0KPj4+Pj4+Pj4+Pj4+Pj4+ Pj4+Pj4+Pj4+IEkgcmVhbGl6ZSB0aGlzIHJlcXVpcmVtZW50IGNvbWVzIGZyb20gUkZDIDQ1ODIs DQo+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4gYnV0IEnCuWQgbGlrZSB0byB1bmRlcnN0YW5kIHdo eSBpdCBoYXMgbm90IGJlZW4NCj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+PiB1cGRhdGVkIHRvIGJl IGNvbnNpc3RlbnQgd2l0aCBtb3JlIGN1cnJlbnQNCj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+PiBn dWlkYW5jZSBvbiBjaXBoZXIgc3VpdGUgc2VsZWN0aW9uIChlLmcuLA0KPj4+Pj4+Pj4+Pj4+Pj4+ Pj4+Pj4+Pj4+DQo+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4gaHR0cHM6Ly90b29scy5pZXRmLm9y Zy9odG1sL2RyYWZ0LWlldGYtdXRhLXRscy1iYw0KPj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+IHAN Cj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+PiAtDQo+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4gMA0K Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+IDgNCj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+PiAjDQo+ Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4gcw0KPj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+IGUNCj4+ Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+PiBjDQo+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4gdGlvbg0K Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+IC00KQ0KPj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+IC4N Cj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pg0KPj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+DQo+Pj4+ Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4NCj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+IEhvdyBhYm91dCB3 ZSBrZWVwIHRoaXMgbWluaW11bSByZXF1aXJlbWVudCwgYW5kDQo+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+ Pj4+PiBhZGQgYSByZWZlcmVuY2UgdG8gZHJhZnQtaWV0Zi11dGEtdGxzLWJjcCBhbG9uZw0KPj4+ Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4gd2l0aCBhIHJlY29tbWVuZGF0aW9uIHRvIGFkaGVyZSB0byB0 aGUgYmVzdA0KPj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4gcHJhY3RpY2VzIGl0IG91dGxpbmVzIGlu IHNlY3Rpb24gND8NCj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+DQo+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+ Pj4+Pg0KPj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4NCj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4gSSB0 aGluayBNVVNUIHN1cHBvcnQgVExTX1JTQV9XSVRIX0FFU18xMjhfQ0JDX1NIQQ0KPj4+Pj4+Pj4+ Pj4+Pj4+Pj4+Pj4+PiBmb3IgYmFja3dhcmRzIGNvbXBhdGliaWxpdHkgYW5kIFNIT1VMRCBzdXBw b3J0IHRoZQ0KPj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+PiBvbmVzIGxpc3RlZCBpbiB0aGUgVVRBIGRy YWZ0cyB3b3VsZCBiZSBvay4NCj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4NCj4+Pj4+Pj4+Pj4+Pj4+ Pj4+Pj4+Pj4NCj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4NCj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4N Cj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+DQo+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pg0KPj4+Pj4+ Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+ID0gU2VjdGlvbnMgOCwgOC4xLCA4LjIgPSBJdCBzZWVtcyBsaWtl IHRoZQ0KPj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+IHRyYW5zYWN0aW9uIElEIHJlcXVpcmVtZW50 cyByZWdhcmRpbmcNCj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+PiBub24tcmV1c2UvbW9ub3Rvbmlj YWxseSBpbmNyZWFzaW5nIElEcyBhcmUNCj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+PiByZS1zdGF0 ZWQgbXVsdGlwbGUgdGltZXMgYWNyb3NzIHRoZXNlIHRocmVlDQo+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+ Pj4+Pj4gc2VjdGlvbnMsIGluIHNsaWdodGx5IGRpZmZlcmVudCB3YXlzLCB0byB0aGUgcG9pbnQN Cj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+PiB3aGVyZSBpdMK5cyBub3QgY2xlYXIgZXhhY3RseSB3 aGF0IHRoZXkgYXJlLg0KPj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+IEl0IHNlZW1zIGxpa2UgdGhl eSBhcmU6DQo+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4NCj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+ PiAoMSkgUmVsaWFibGUgdHJhbnNwb3J0LCBzZXJ2ZXItaW5pdGlhdGVkIHRyYW5zYWN0aW9uOg0K Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+IElEIGlzDQo+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4g MA0KPj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+ICgyKSBVbnJlbGlhYmxlIHRyYW5zcG9ydCwgc2Vy dmVyLWluaXRpYXRlZA0KPj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+IHRyYW5zYWN0aW9uOg0KPj4+ Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+IElEIE1VU1QgYmUgbW9ub3RvbmljYWxseSBpbmNyZWFzaW5n IChleGNlcHQgZm9yDQo+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4gd3JhcC1hcm91bmQpDQo+Pj4+ Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4gKDMpIFJlbGlhYmxlIHRyYW5zcG9ydCwgY2xpZW50LWluaXRp YXRlZCB0cmFuc2FjdGlvbjoNCj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+PiBJRCBNVVNUIE5PVCBi ZSAwIGFuZCBNVVNUIE5PVCBiZSByZXVzZWQgaW4NCj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+PiBh bm90aGVyIG1lc3NhZ2UgZnJvbSB0aGUgY2xpZW50IHVudGlsIGEgcmVzcG9uc2UNCj4+Pj4+Pj4+ Pj4+Pj4+Pj4+Pj4+Pj4+Pg0KPj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4gPmZyb20gdGhlIHNlcnZl ciBpcyByZWNlaXZlZCBmb3IgdGhlIHRyYW5zYWN0aW9uLA0KPj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+ Pj4NCj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+PiBidXQgbmVlZCBub3QgYmUgbW9ub3RvbmljYWxs eSBpbmNyZWFzaW5nIChlLmcuLCBhDQo+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4gbG93ZXIsIHJl Y2VudGx5IHVzZWQgSUQgY291bGQgYmUgcmUtdXNlZCBvbmNlIGENCj4+Pj4+Pj4+Pj4+Pj4+Pj4+ Pj4+Pj4+PiByZXNwb25zZSBpcw0KPj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+IHJlY2VpdmVkKQ0K Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+ICg0KSBVbnJlbGlhYmxlIHRyYW5zcG9ydCwgY2xpZW50 LWluaXRpYXRlZA0KPj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+IHRyYW5zYWN0aW9uOg0KPj4+Pj4+ Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+IElEIE1VU1QgYmUgbW9ub3RvbmljYWxseSBpbmNyZWFzaW5nIChl eGNlcHQgZm9yDQo+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4gd3JhcC1hcm91bmQpDQo+Pj4+Pj4+ Pj4+Pj4+Pj4+Pj4+Pj4+Pj4NCj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+PiBJcyAoMykgdGhlIGNv cnJlY3QgaW50ZXJwcmV0YXRpb24gb2YgdGhlIHRleHQgaW4gOC4xPw0KPj4+Pj4+Pj4+Pj4+Pj4+ Pj4+Pj4+Pj4+IElmIHNvLCB3aHkgbm90IGp1c3QgcmVxdWlyZSBJRHMgaW4gYWxsDQo+Pj4+Pj4+ Pj4+Pj4+Pj4+Pj4+Pj4+Pj4gY2xpZW50LWluaXRpYXRlZCB0cmFuc2FjdGlvbnMgdG8gYmUgbW9u b3RvbmljYWxseQ0KPj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+IGluY3JlYXNpbmc/DQo+Pj4+Pj4+ Pj4+Pj4+Pj4+Pj4+Pj4+Pj4NCj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pg0KPj4+Pj4+Pj4+Pj4+ Pj4+Pj4+Pj4+Pj4+DQo+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+PiBBZ3JlZSB3ZSBjYW4gYW5kIHNo b3VsZCBzaW1wbGlmeSB0aGlzLiBTZWN0aW9ucw0KPj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4gOC4x IGFuZA0KPj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4gOC4yIGNvdmVyIHRoZSBjbGllbnQgYmVoYXZp b3IgYW5kIHNlcnZlciBiZWhhdmlvcg0KPj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4gaW4gZGV0YWls LiBBcyBzdWNoLCB0aGUgdHJhbnNhY3Rpb24gSUQgcmVsYXRlZA0KPj4+Pj4+Pj4+Pj4+Pj4+Pj4+ Pj4+Pj4gaW5mb3JtYXRpb24gYXQgdGhlIHN0YXJ0IG9mIFNlY3Rpb24gOCBpcyBzdXBlcmZsdW91 cy4NCj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+IEkgcmVjb21tZW5kIHJlZHVjaW5nIHRoZSB0ZXh0 IGluIFNlY3Rpb24gOCB0byB0aGUNCj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+IGZvbGxvdzoNCj4+ Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+DQo+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+PiA4LiBQcm90b2Nv bCBUcmFuc2FjdGlvbnMNCj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+DQo+Pj4+Pj4+Pj4+Pj4+Pj4+ Pj4+Pj4+PiBJbiBCRkNQLCB0aGVyZSBhcmUgdHdvIHR5cGVzIG9mIHRyYW5zYWN0aW9uczoNCj4+ Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+IGNsaWVudC1pbml0aWF0ZWQgdHJhbnNhY3Rpb25zIGFuZCBz ZXJ2ZXItaW5pdGlhdGVkDQo+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+PiB0cmFuc2FjdGlvbnMuDQo+ Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pg0KPj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4gQ2xpZW50LWlu aXRpYXRlZCB0cmFuc2FjdGlvbnMgY29uc2lzdCBvZiBhIHJlcXVlc3QNCj4+Pj4+Pj4+Pj4+Pj4+ Pj4+Pj4+Pj4+IGZyb20gYSBjbGllbnQgdG8gYSBmbG9vciBjb250cm9sIHNlcnZlciBhbmQgYQ0K Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4gcmVzcG9uc2UgZnJvbSB0aGUgZmxvb3IgY29udHJvbCBz ZXJ2ZXIgdG8gdGhlIGNsaWVudC4NCj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+DQo+Pj4+Pj4+Pj4+ Pj4+Pj4+Pj4+Pj4+PiBTZXJ2ZXItaW5pdGlhdGVkIHRyYW5zYWN0aW9ucyBoYXZlIGRpZmZlcmVu dA0KPj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4gYmVoYXZpb3IgZGVwZW5kaW5nIG9uIHVuZGVybHlp bmcgdHJhbnNwb3J0Og0KPj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4NCj4+Pj4+Pj4+Pj4+Pj4+Pj4+ Pj4+Pj4+ICAgICAgIFdoZW4gdXNpbmcgYSByZWxpYWJsZSB0cmFuc3BvcnQsDQo+Pj4+Pj4+Pj4+ Pj4+Pj4+Pj4+Pj4+PiBzZXJ2ZXItaW5pdGlhdGVkIHRyYW5zYWN0aW9ucw0KPj4+Pj4+Pj4+Pj4+ Pj4+Pj4+Pj4+Pj4gICAgICAgY29uc2lzdCBvZiBhIHNpbmdsZSBtZXNzYWdlIGZyb20gYSBmbG9v cg0KPj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4gY29udHJvbCBzZXJ2ZXIgdG8gYQ0KPj4+Pj4+Pj4+ Pj4+Pj4+Pj4+Pj4+Pj4gICAgICAgY2xpZW50IChub3RpZmljYXRpb25zKS4gIFRoZXkgZG8gbm90 IHRyaWdnZXINCj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+IGFueSByZXNwb25zZS4NCj4+Pj4+Pj4+ Pj4+Pj4+Pj4+Pj4+Pj4+DQo+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+PiAgICAgICBXaGVuIHVzaW5n IGFuIHVucmVsaWFibGUgdHJhbnNwb3J0LA0KPj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4gc2VydmVy LWluaXRpYXRlZCB0cmFuc2FjdGlvbnMNCj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+ICAgICAgIGNv bnNpc3Qgb2YgYSByZXF1ZXN0IGZyb20gYSBmbG9vciBjb250cm9sDQo+Pj4+Pj4+Pj4+Pj4+Pj4+ Pj4+Pj4+PiBzZXJ2ZXIgdG8gYSBjbGllbnQgYW5kIGENCj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+ ICAgICAgIHJlc3BvbnNlIGZyb20gdGhlIGNsaWVudCB0byB0aGUgZmxvb3IgY29udHJvbA0KPj4+ Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4gc2VydmVyLg0KPj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4NCj4+ Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+IFdoZW4gdXNpbmcgQkZDUCBvdmVyIGFuIHVucmVsaWFibGUg dHJhbnNwb3J0LA0KPj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4gcmV0cmFuc21pc3Npb24gdGltZXIg VDEgKHNlZSBTZWN0aW9uIDguMykgTVVTVCBiZQ0KPj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4gdXNl ZCBmb3IgYWxsIHJlcXVlc3RzIHVudGlsIHRoZSB0cmFuc2FjdGlvbiBpcw0KPj4+Pj4+Pj4+Pj4+ Pj4+Pj4+Pj4+Pj4gY29tcGxldGVkLg0KPj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4NCj4+Pj4+Pj4+ Pj4+Pj4+Pj4+Pj4+Pj4+IFRoZW4gaW4gc2VjdGlvbiA4LjEsIHdlIGFkZCB0aGUgaW1wb3J0YW50 IGRldGFpbHMNCj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+IHJlbW92ZWQgZnJvbSBzZWN0aW9uIDgu DQo+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pg0KPj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4gOC4xLjEg Q2xpZW50IEJlaGF2aW9yDQo+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pg0KPj4+Pj4+Pj4+Pj4+Pj4+ Pj4+Pj4+Pj4gQSBjbGllbnQgc3RhcnRpbmcgYSBjbGllbnQtaW5pdGlhdGVkIHRyYW5zYWN0aW9u DQo+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+PiBNVVNUIHNldCB0aGUgQ29uZmVyZW5jZSBJRCBpbiB0 aGUgY29tbW9uIGhlYWRlciBvZg0KPj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4gdGhlIG1lc3NhZ2Ug dG8gdGhlIENvbmZlcmVuY2UgSUQgZm9yIHRoZQ0KPj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4gY29u ZmVyZW5jZSB0aGF0IHRoZSBjbGllbnQgb2J0YWluZWQgcHJldmlvdXNseS4NCj4+Pj4+Pj4+Pj4+ Pj4+Pj4+Pj4+Pj4+DQo+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+PiBUaGUgY2xpZW50IE1VU1Qgc2V0 IHRoZSBUcmFuc2FjdGlvbiBJRCB2YWx1ZSBpbg0KPj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4gdGhl IGNvbW1vbiBoZWFkZXIgdG8gYSBudW1iZXIgdGhhdCBpcyBkaWZmZXJlbnQNCj4+Pj4+Pj4+Pj4+ Pj4+Pj4+Pj4+Pj4+ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg IA0KPj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+PiA+ZnJvbSAwIGFuZCB0aGF0IE1VU1QgTk9UIGJlIHJl dXNlZCBpbiBhbm90aGVyDQo+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+ICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICANCj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+IG1lc3Nh Z2UgZnJvbSB0aGUgY2xpZW50IHVudGlsIGEgcmVzcG9uc2UgZnJvbSB0aGUNCj4+Pj4+Pj4+Pj4+ Pj4+Pj4+Pj4+Pj4+IHNlcnZlciBpcyByZWNlaXZlZCBmb3IgdGhlIHRyYW5zYWN0aW9uLg0KPj4+ Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4gVGhlIGNsaWVudCB1c2VzIHRoZSBUcmFuc2FjdGlvbiBJRCB2 YWx1ZSB0byBtYXRjaA0KPj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4gdGhpcyBtZXNzYWdlIHdpdGgg dGhlIHJlc3BvbnNlIGZyb20gdGhlIGZsb29yDQo+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+PiBjb250 cm9sIHNlcnZlci4NCj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+IFdoZW4gdXNpbmcgQkZDUCBvdmVy IGFuIHVucmVsaWFibGUgdHJhbnNwb3J0LCBpdA0KPj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4gaXMg aW1wb3J0YW50IHRvIGNob29zZSBhIFRyYW5zYWN0aW9uIElEIHZhbHVlIHRoYXQNCj4+Pj4+Pj4+ Pj4+Pj4+Pj4+Pj4+Pj4+IGxldHMgdGhlIHJlY2VpdmVyIGRpc3Rpbmd1aXNoIHRoZSByZWNlcHRp b24gb2YgdGhlDQo+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+PiBuZXh0IG1lc3NhZ2UgaW4gYSBzZXF1 ZW5jZSBvZiBCRkNQIG1lc3NhZ2VzIGZyb20gYQ0KPj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4gcmV0 cmFuc21pc3Npb24gb2YgYSBwcmV2aW91cyBtZXNzYWdlLiAgVGhlcmVmb3JlLA0KPj4+Pj4+Pj4+ Pj4+Pj4+Pj4+Pj4+Pj4gQkZDUCBlbnRpdGllcyB1c2luZyBhbiB1bnJlbGlhYmxlIHRyYW5zcG9y dCBNVVNUDQo+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+PiB1c2UgbW9ub3RvbmljYWxseSBpbmNyZWFz aW5nIFRyYW5zYWN0aW9uIElEIHZhbHVlcw0KPj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4gKGV4Y2Vw dCBmb3Igd3JhcC1hcm91bmQpLg0KPj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4NCj4+Pj4+Pj4+Pj4+ Pj4+Pj4+Pj4+Pj4+IEEgY2xpZW50IHJlY2VpdmluZyBhIHNlcnZlci1pbml0aWF0ZWQgdHJhbnNh Y3Rpb24NCj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+IG92ZXIgYW4gdW5yZWxpYWJsZSB0cmFuc3Bv cnQgTVVTVCBjb3B5IHRoZQ0KPj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4gVHJhbnNhY3Rpb24gSUQg ZnJvbSB0aGUgcmVxdWVzdCByZWNlaXZlZCBmcm9tIHRoZQ0KPj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+ Pj4gc2VydmVyIGludG8gdGhlIHJlc3BvbnNlLg0KPj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4gW1F1 ZXN0aW9uOiBpcyB0aGVyZSBhIG5lZWQgdG8gY29weSB0aGUgQ29uZmVyZW5jZQ0KPj4+Pj4+Pj4+ Pj4+Pj4+Pj4+Pj4+Pj4gSUQgYW5kICBVc2VyIElELCBpZiBwcmVzZW50P10NCj4+Pj4+Pj4+Pj4+ Pj4+Pj4+Pj4+Pj4+DQo+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+PiA4LjIuIFNlcnZlciBCZWhhdmlv cg0KPj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4NCj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+IEEgZmxv b3IgY29udHJvbCBzZXJ2ZXIgc2VuZGluZyBhIHJlc3BvbnNlIHdpdGhpbiBhDQo+Pj4+Pj4+Pj4+ Pj4+Pj4+Pj4+Pj4+PiBjbGllbnQtaW5pdGlhdGVkIHRyYW5zYWN0aW9uIE1VU1QgY29weSB0aGUN Cj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+IENvbmZlcmVuY2UgSUQsIHRoZSBUcmFuc2FjdGlvbiBJ RCwgYW5kIHRoZSBVc2VyIElEDQo+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+PiAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICANCj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4g PmZyb20gdGhlIHJlcXVlc3QgcmVjZWl2ZWQgZnJvbSB0aGUgY2xpZW50IGludG8gdGhlDQo+Pj4+ Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICANCj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+IHJlc3BvbnNlLg0KPj4+Pj4+Pj4+Pj4+Pj4+ Pj4+Pj4+Pj4NCj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+IFNlcnZlci1pbml0aWF0ZWQgdHJhbnNh Y3Rpb25zIE1VU1QgY29udGFpbiBhDQo+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+PiBUcmFuc2FjdGlv biBJRCBlcXVhbCB0bw0KPj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4gMCB3aGVuIEJGQ1AgaXMgdXNl ZCBvdmVyIGEgcmVsaWFibGUgdHJhbnNwb3J0Lg0KPj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4gT3Zl ciBhbiB1bnJlbGlhYmxlIHRyYW5zcG9ydCwgdGhlIFRyYW5zYWN0aW9uIElEDQo+Pj4+Pj4+Pj4+ Pj4+Pj4+Pj4+Pj4+PiBzaGFsbCBoYXZlIHRoZSBzYW1lIHByb3BlcnRpZXMgYXMgZm9yDQo+Pj4+ Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+PiBjbGllbnQtaW5pdGlhdGVkIHRyYW5zYWN0aW9ucy4NCj4+Pj4+ Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+IFRoZSBzZXJ2ZXIgdXNlcyB0aGUgVHJhbnNhY3Rpb24gSUQgdmFs dWUgdG8gbWF0Y2gNCj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+IHRoaXMgbWVzc2FnZSB3aXRoIHRo ZSByZXNwb25zZSBmcm9tIHRoZSBmbG9vcg0KPj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4gcGFydGlj aXBhbnQgb3IgZmxvb3IgY2hhaXIuDQo+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pg0KPj4+Pj4+Pj4+ Pj4+Pj4+Pj4+Pj4+Pj4NCj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+DQo+Pj4+Pj4+Pj4+Pj4+Pj4+ Pj4+Pj4+PiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICANCj4+ Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4gVGhhbmtzLCB0aGlzIGlzIGJldHRlci4NCj4+Pj4+Pj4+Pj4+ Pj4+Pj4+Pj4+Pj4NCj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4NCj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+ Pj4NCj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4gICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgIA0KPj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+ID0gU2VjdGlvbiA5IChpbXBh Y3RzIFNlY3Rpb24gMTQgYXMgd2VsbCkgPSAiQkZDUA0KPj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+ IGNsaWVudHMgIFNIT1VMRCBhdXRoZW50aWNhdGUgdGhlIGZsb29yIGNvbnRyb2wNCj4+Pj4+Pj4+ Pj4+Pj4+Pj4+Pj4+Pj4+PiBzZXJ2ZXIgYmVmb3JlICBzZW5kaW5nIGFueSBCRkNQIG1lc3NhZ2Ug dG8gaXQgb3INCj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+PiBhY2NlcHRpbmcgYW55IEJGQ1AgbWVz c2FnZSBmcm9tIGl0Lg0KPj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+IFNpbWlsYXJseSwgZmxvb3Ig Y29udHJvbCBzZXJ2ZXJzIFNIT1VMRA0KPj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+IGF1dGhlbnRp Y2F0ZSBhIGNsaWVudCBiZWZvcmUgYWNjZXB0aW5nIGFueSBCRkNQDQo+Pj4+Pj4+Pj4+Pj4+Pj4+ Pj4+Pj4+Pj4gbWVzc2FnZSBmcm9tIGl0IG9yIHNlbmRpbmcgYW55IEJGQ1AgbWVzc2FnZSB0byBp dC4NCj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pg0KPj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+IEJG Q1Agc3VwcG9ydHMgVExTL0RUTFMgbXV0dWFsIGF1dGhlbnRpY2F0aW9uDQo+Pj4+Pj4+Pj4+Pj4+ Pj4+Pj4+Pj4+Pj4gYmV0d2VlbiBjbGllbnRzIGFuZCBmbG9vciBjb250cm9sIHNlcnZlcnMsIGFz DQo+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4gc3BlY2lmaWVkIGluIFNlY3Rpb24gOS4xLg0KPj4+ Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+IFRoaXMgaXMgdGhlIFJFQ09NTUVOREVEIGF1dGhlbnRpY2F0 aW9uIG1lY2hhbmlzbQ0KPj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+IGluIEJGQ1AuwrINCj4+Pj4+ Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pg0KPj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+IFdoYXQgYXJlIHRo ZSBjYXNlcyB3aGVyZSBjbGllbnRzIGFuZCBzZXJ2ZXJzIGRvDQo+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+ Pj4+Pj4gbm90IG5lZWQgIHRvIGJlIGF1dGhlbnRpY2F0aW5nIGVhY2ggb3RoZXI/IEkga25vdw0K Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+IHRoaXMgcmVxdWlyZW1lbnQgIGFuZCB0aGUgb3RoZXIg U0hPVUxELWxldmVsDQo+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4gcmVxdWlyZW1lbnRzIGFyb3Vu ZCB1c2Ugb2YgIFRMUy9EVExTIGFyZSBjYXJyaWVkDQo+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4g b3ZlciBmcm9tIFJGQyA0NTgyLCBidXQgScK5bSAgY29uY2VybmVkIHRoYXQgdGhleQ0KPj4+Pj4+ Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+IGFyZW7CuXQgYXMgc3Ryb25nIGFzIHRoZXkgc2hvdWxkIGJlLg0K Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+IEZvciBhIGNvbmZlcmVuY2Ugd2hlcmUgdGhlIHNpZ25h bGluZyB0cmFmZmljIGlzDQo+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4gYXV0aGVudGljYXRlZCBh bmQgY29uZmlkZW50aWFsaXR5IGFuZCBpbnRlZ3JpdHkNCj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+ PiBwcm90ZWN0ZWQsIHdoeSBpcyBpdCBvayBmb3IgdGhlIGZsb29yIGNvbnRyb2wNCj4+Pj4+Pj4+ Pj4+Pj4+Pj4+Pj4+Pj4+PiB0cmFmZmljIG5vdCB0byBiZT8gQ291bGQgdGhlc2UgcmVxdWlyZW1l bnRzIGJlDQo+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4gYWRqdXN0ZWQgdG8gcmVxdWlyZSB1c2Ug b2YgVExTL0RUTFMgYXQgbGVhc3QgaW4NCj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+PiBjYXNlcyB3 aGVyZSB0aGUgc2lnbmFsaW5nIGlzIGFsc28gcHJvdGVjdGVkPw0KPj4+Pj4+Pj4+Pj4+Pj4+Pj4+ Pj4+Pj4+DQo+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4NCj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+ PiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIA0KPj4+Pj4+ Pj4+Pj4+Pj4+Pj4+Pj4+Pj4gWWVzLCBidXQgYWdhaW4sIHRoaXMgd291bGQgYmUgYXQgdGhlIGV4 cGVuc2Ugb2YNCj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+IGFkZGluZyBhIG5vbiBiYWNrd2FyZCBj b21wYXRpYmxlIGNoYW5nZSBmcm9tIHJmYw0KPj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4gNDU4Mi4g SG93IGFib3V0IHNheWluZyBUTFMvRFRMUyBNVVNUIGJlIHVzZWQgZm9yDQo+Pj4+Pj4+Pj4+Pj4+ Pj4+Pj4+Pj4+PiBCRkNQIGluIHN1Y2ggY2FzZXMsIHdoaWxlIHBvaW50aW5nIG91dCB0aGUgcmZj DQo+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+PiA0NTgyDQo+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+PiBi YXNlZCBpbXBsZW1lbnRhdGlvbnMgbWF5IG5vdCBjb21wbHkgKHNpbWlsYXIgdG8NCj4+Pj4+Pj4+ Pj4+Pj4+Pj4+Pj4+Pj4+IHdoYXQgd2UgZGlkIHdpdGggdGhlIHZlcnNpb24gZmllbGQpLg0KPj4+ Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4NCj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+DQo+Pj4+Pj4+Pj4+ Pj4+Pj4+Pj4+Pj4+PiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICANCj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4gV29ya3MgZm9yIG1lLg0KPj4+Pj4+Pj4+Pj4+Pj4+ Pj4+Pj4+Pg0KPj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+PiBGZWVsIGZyZWUgdG8gbWFrZSBhbGwgb2Yg dGhlc2UgY2hhbmdlcyBhbmQgc3VibWl0IGENCj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4gcmV2IGFu ZCBJwrlsbCBpc3N1ZSB0aGUgSUVURiBMQy4NCj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4NCj4+Pj4+ Pj4+Pj4+Pj4+Pj4+Pj4+Pj4gVGhhbmtzLA0KPj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+PiBBbGlzc2EN Cj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4NCj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4NCj4+Pj4+Pj4+ Pj4+Pj4+Pj4+Pj4+Pj4NCj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4gICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgIA0KPj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+ID0gU2Vj dGlvbiAxNCA9DQo+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4gU2VlIHRoZSBwb2ludCBhYm92ZSBh Ym91dCBjaXBoZXJzdWl0ZXMuIMKzTm9uLW51bGwNCj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+PiBl bmNyeXB0aW9uwrIgaXMgbm90IGEgc3VmZmljaWVudCBtaW5pbXVtIGJhc2VsaW5lLA0KPj4+Pj4+ Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+IGFuZCBpZiB0aGUgcmVxdWlyZW1lbnRzIGNoYW5nZSBpbiBTZWN0 aW9uIDcgdGhleQ0KPj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+IHNob3VsZCBiZSByZWZsZWN0ZWQg aGVyZSBhcyB3ZWxsLg0KPj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+DQo+Pj4+Pj4+Pj4+Pj4+Pj4+ Pj4+Pj4+Pj4NCj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+PiAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgIA0KPj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4gWWVwLg0K Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4NCj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+DQo+Pj4+Pj4+ Pj4+Pj4+Pj4+Pj4+Pj4+Pg0KPj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4gICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgDQo+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4g RWRpdG9yaWFsIG5pdHMgdG8gYmUgcmVzb2x2ZWQgd2l0aCBMQyBjb21tZW50czoNCj4+Pj4+Pj4+ Pj4+Pj4+Pj4+Pj4+Pj4+Pg0KPj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+ID0gU2VjdGlvbiA1LjEg PQ0KPj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+IMKzVGhlIHZlcnNpb24gZmllbGQgTVVTVCBiZSBz ZXQgdG8gMSB3aGVuIHVzaW5nDQo+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4gQkZDUCBvdmVyIGEg cmVsaWFibGUgdHJhbnNwb3J0LCBpLmUuIGFzIGluIFsyXS7Csg0KPj4+Pj4+Pj4+Pj4+Pj4+Pj4+ Pj4+Pj4+DQo+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4gSSBmaW5kIGl0IGEgbGl0dGxlIG9kZCB0 byByZWZlcmVuY2UgdGhlIHNwZWMNCj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+PiB5b3XCuXJlIG9i c29sZXRpbmcgaW4gdGhpcyBzZW50ZW5jZSwgZXNwZWNpYWxseQ0KPj4+Pj4+Pj4+Pj4+Pj4+Pj4+ Pj4+Pj4+IHNpbmNlIEJGQ1Agb3ZlciBhIHJlbGlhYmxlIHRyYW5zcG9ydCBpcyBjb21wbGV0ZWx5 DQo+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4gc3BlY2lmaWVkIGluIHRoaXMgYmlzIGRvY3VtZW50 LiBJIHdvdWxkIHN1Z2dlc3QNCj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+PiBkcm9wcGluZw0KPj4+ Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgDQo+PiB0aGUgaS5lLg0KPj4gICAgDQo+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+ Pj4gY2xhdXNlLg0KPj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+DQo+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+ Pj4+Pj4NCj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+PiAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgIA0KPj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4gR29vZCBjYXRj aC4gVGhpcyBpcyBhIGNhcnJ5IG92ZXIgZnJvbSBiZWZvcmUgdGhpcw0KPj4+Pj4+Pj4+Pj4+Pj4+ Pj4+Pj4+Pj4gZHJhZnQgd2FzIGFkb3B0ZWQgYXMgYSBiaXMgdmVyc2lvbiBvZiByZmM0NTgyLg0K Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4NCj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+DQo+Pj4+Pj4+ Pj4+Pj4+Pj4+Pj4+Pj4+Pg0KPj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4gICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgDQo+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4g IlRoZSB2ZXJzaW9uIGZpZWxkIE1VU1QgYmUgc2V0IHRvIDIgd2hlbiB1c2luZw0KPj4+Pj4+Pj4+ Pj4+Pj4+Pj4+Pj4+Pj4+IEJGQ1Agb3ZlciBhbiB1bnJlbGlhYmxlIHRyYW5zcG9ydCB3aXRoIHRo ZQ0KPj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+IGV4dGVuc2lvbnMgc3BlY2lmaWVkIGluIHRoaXMg ZG9jdW1lbnQuwrINCj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pg0KPj4+Pj4+Pj4+Pj4+Pj4+Pj4+ Pj4+Pj4+IFRoZSBiaXQgYWJvdXQgwrN3aXRoIHRoZSBleHRlbnNpb25zIHNwZWNpZmllZCBpbg0K Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+IHRoaXMgZG9jdW1lbnTCsiBpcyBleHRyYW5lb3VzIGFu ZCBzaG91bGQgYmUgcmVtb3ZlZC4NCj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pg0KPj4+Pj4+Pj4+ Pj4+Pj4+Pj4+Pj4+Pj4+ICJJZiBhbiBlbmRwb2ludCByZWNlaXZlcyBhIG1lc3NhZ2Ugd2l0aCBh bg0KPj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+IHVuc3VwcG9ydGVkIHZlcnNpb24gZmllbGQgdmFs dWUsIHRoZSByZWNlaXZpbmcNCj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+PiBzZXJ2ZXIgTVVTVCBz ZW5kIGFuIEVycm9yIG1lc3NhZ2Ugd2l0aCBwYXJhbWV0ZXINCj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+ Pj4+PiB2YWx1ZSAxMiAoVW5zdXBwb3J0ZWQNCj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+PiBWZXJz aW9uKSB0byBpbmRpY2F0ZSB0aGlzLsKyDQo+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4NCj4+Pj4+ Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+PiBVc2Ugb2YgdGhlIHdvcmQgwrNzZXJ2ZXLCsiBoZXJlIG1ha2Vz IGl0IHNvdW5kIGFzDQo+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4gaWYgb25seSBzZXJ2ZXJzIGNv dWxkIHJlY2VpdmUgaGVhZGVycyB3aXRoDQo+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4gdW5zdXBw b3J0ZWQgdmVyc2lvbnMuDQo+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4gU2hvdWxkIHRoaXMgYmUg wrN0aGUgcmVjZWl2aW5nIGVuZHBvaW50wrI/DQo+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4NCj4+ Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+PiA9IFNlY3Rpb24gNi4yLjQgPSAiWzIzXSwgU2VjdGlvbiA2 LjcgcHJvdmlkZXMNCj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+PiB1c2VmdWwgcmVjb21tZW5kYXRp b25zIMWgwrINCj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pg0KPj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+ Pj4+IFRoZSBsaW5rcyBpbiB0aGUgcmVmZXJlbmNlcyBhcmUgbm90IHF1aXRlIHJpZ2h0Lg0KPj4+ Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+DQo+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4gPSBTZWN0aW9u IDguMy4yID0gcy93aGVuIGZpcmVzL3doZW4gZmlyZWQvDQo+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+ Pj4NCj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+PiA9IFNlY3Rpb24gMTQgPQ0KPj4+Pj4+Pj4+Pj4+ Pj4+Pj4+Pj4+Pj4+IHMvaGlnaC1qYWNrL2hpamFjay8NCj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+ Pg0KPj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+ID0gU2VjdGlvbiBCLjEgPQ0KPj4+Pj4+Pj4+Pj4+ Pj4+Pj4+Pj4+Pj4+ICJzaXR1YXRpb24gd2hlcmUgbXVsdGlwbGUgZGlmZmVyZW50IGFuZA0KPj4+ Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+IG5vbi1pbnRlcm9wZXJhYmxlIHdvdWxkDQo+Pj4+Pj4+Pj4+ Pj4+Pj4+Pj4+Pj4+Pj4gY28tDQo+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4gZXhpc3QgaW4gdGhl IG1hcmtldC7Csg0KPj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+DQo+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+ Pj4+Pj4gVGhlcmUgaXMgYSB3b3JkIG1pc3NpbmcgYWZ0ZXIgwrNub24taW50ZXJvcGVyYWJsZS4i DQo+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4NCj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pg0KPj4+ Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgDQo+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+PiBUaGlzIHNob3VsZCByZWFkIMKz bm9uLWludGVyb3BlcmFibGUgaW1wbGVtZW50YXRpb25zwrIuDQo+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+ Pj4+PiBFYXJsaWVyIGluIHRoYXQgc2FtZSBzZW50ZW5jZSwgwrNCRkNQIG92ZXIgVURQIHdlcmUN Cj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+IGFscmVhZHkgdXNlZMKyIHNob3VsZCByZWFkIMKzQkZD UCBvdmVyIFVEUCBpcyBhbHJlYWR5DQo+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+PiBiZWluZyB1c2Vk wrIuDQo+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pg0KPj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4gQ2hl ZXJzLA0KPj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4gQ2hhcmxlcw0KPj4+Pj4+Pj4+Pj4+Pj4+Pj4+ Pj4+Pj4NCj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+DQo+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+PiAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICANCj4+Pj4+Pj4+Pj4+ Pj4+Pj4+Pj4+Pj4gX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X18NCj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4gYmZjcGJpcyBtYWlsaW5nIGxpc3QNCj4+Pj4+Pj4+ Pj4+Pj4+Pj4+Pj4+Pj4gYmZjcGJpc0BpZXRmLm9yZzxtYWlsdG86YmZjcGJpc0BpZXRmLm9yZz4N Cj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4gaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0 aW5mby9iZmNwYmlzDQo+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+DQo+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+ Pj4+DQo+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICANCj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pg0KPj4+Pj4+Pj4+Pj4+Pj4+Pj4+ Pj4+ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgDQo+Pj4+Pj4+Pj4+ Pj4+Pj4+Pj4+Pg0KPj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4gICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgDQo+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+DQo+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+ ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICANCj4+Pj4+Pj4+Pj4+Pj4+Pj4+ Pg0KPj4+Pj4+Pj4+Pj4+Pj4+Pj4+ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg DQo+Pj4+Pj4+Pj4+Pj4+Pj4+Pg0KPj4+Pj4+Pj4+Pj4+Pj4+Pj4gICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgDQo+Pj4+Pj4+Pj4+Pj4+Pj4+DQo+Pj4+Pj4+Pj4+Pj4+Pj4+ICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICANCj4+Pj4+Pj4+Pj4+Pj4+Pg0KPj4+Pj4+Pj4+Pj4+ Pj4+ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgDQo+Pj4+Pj4+Pj4+Pj4+Pg0KPj4+Pj4+ Pj4+Pj4+Pj4gICAgICAgICAgICAgICAgICAgICAgICAgICAgDQo+Pj4+Pj4+Pj4+Pj4+DQo+Pj4+ Pj4+Pj4+Pj4+ICAgICAgICAgICAgICAgICAgICAgICAgICANCj4+Pj4+Pj4+Pj4+DQo+Pj4+Pj4+ Pj4+PiAgICAgICAgICAgICAgICAgICAgICANCj4+Pj4+Pj4+Pj4NCj4+Pj4+Pj4+Pj4gICAgICAg ICAgICAgICAgICAgIA0KPj4+Pj4+Pj4+ICAgICAgICAgICAgICAgICAgDQo+Pj4+Pj4+PiBfX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KPj4+Pj4+Pj4gYmZj cGJpcyBtYWlsaW5nIGxpc3QNCj4+Pj4+Pj4+IGJmY3BiaXNAaWV0Zi5vcmcNCj4+Pj4+Pj4+IGh0 dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vYmZjcGJpcw0KPj4+Pj4+Pj4gICAg ICAgICAgICAgICAgDQo+Pj4+Pj4+ICAgICAgICAgICAgICANCj4+Pj4+PiAgICAgICAgICAgIA0K Pj4+Pj4gICAgICAgICAgDQo+Pj4+ICAgICAgICANCj4+PiBfX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fXw0KPj4+IGJmY3BiaXMgbWFpbGluZyBsaXN0DQo+Pj4g YmZjcGJpc0BpZXRmLm9yZw0KPj4+IGh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGlu Zm8vYmZjcGJpcw0KPj4+ICAgICAgDQo+PiAgICANCj4NCg0K From nobody Mon Nov 2 02:39:55 2015 Return-Path: X-Original-To: bfcpbis@ietfa.amsl.com Delivered-To: bfcpbis@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 871961A1BCF for ; Mon, 2 Nov 2015 02:39:53 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.201 X-Spam-Level: X-Spam-Status: No, score=-4.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, 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 VaP-C3aD3pI0 for ; Mon, 2 Nov 2015 02:39:46 -0800 (PST) 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 3417A1A1BC8 for ; Mon, 2 Nov 2015 02:39:45 -0800 (PST) X-AuditID: c1b4fb2d-f79626d000004282-82-56373d6ee265 Received: from ESESSHC018.ericsson.se (Unknown_Domain [153.88.253.125]) by sessmg23.ericsson.net (Symantec Mail Security) with SMTP id CE.F2.17026.E6D37365; Mon, 2 Nov 2015 11:39:43 +0100 (CET) Received: from ESESSMB209.ericsson.se ([169.254.9.202]) by ESESSHC018.ericsson.se ([153.88.183.72]) with mapi id 14.03.0248.002; Mon, 2 Nov 2015 11:39:39 +0100 From: Christer Holmberg To: "Charles Eckel (eckelcu)" , "Tom Kristensen (tomkrist)" Thread-Topic: Status update on draft-ietf-mmusic-dtls-sdp [was: [bfcpbis] draft-ietf-bfcpbis-rfc4583bis] Thread-Index: AdEVPGtzePVeqGKXRT2MOxuY5KEVyP//+0SAgAALUID//8n3gA== Date: Mon, 2 Nov 2015 10:39:39 +0000 Message-ID: <7594FB04B1934943A5C02806D1A2204B37BCD730@ESESSMB209.ericsson.se> References: <7594FB04B1934943A5C02806D1A2204B37BC8F7B@ESESSMB209.ericsson.se> <56371495.7080105@cisco.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [153.88.183.154] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFlrJIsWRmVeSWpSXmKPExsUyM+JvrW6+rXmYwasONovpZ/4yWszvPM1u 8W/dUSaLW+tvs1hsmvWFzeLKkV9sDmweU35vZPX48uQlk8eSJT+ZPGbtfMLi8eXyZ7YA1igu m5TUnMyy1CJ9uwSujP9/prIV7OpgqdjwfilLA2PPb+YuRk4OCQETiTOnp7JB2GISF+6tB7K5 OIQEjjBKXDm/nBHCWcwosfviUqAODg42AQuJ7n/aIA0iAqkSJxZ2sILYzAKtTBKHOr1ASoQF MiU23iyEKMmSaJwNMV9EwEli3cOJYHtZBFQkDq7ZxAhSzivgK7HzUD3Epn5GibM3NjOBxDkF 9CWWXVIAKWcEOu37qTVMEJvEJW49mc8EcbKAxJI956FeEZV4+fgfK4StJLHo9mewMcwCmhLr d+lDtCpKTOl+yA5i8woISpyc+YRlAqPYLCRTZyF0zELSMQtJxwJGllWMosWpxcW56UbGeqlF mcnFxfl5enmpJZsYgRF4cMtv3R2Mq187HmIU4GBU4uE1SDQLE2JNLCuuzD3EKMHBrCTCG6Jl HibEm5JYWZValB9fVJqTWnyIUZqDRUmct4XpQaiQQHpiSWp2ampBahFMlomDU6qBcfX/XzNl gw+7msbH26eeVmpe68DdI3b385WGju9vG1myrPTDOW93Ge09L8AucOVeY7h2s9u0qjc3fDm1 C4+Zmrt0/9if5P8rpfzExcNpQb8yNQwdzBgSp60xuaHNt+56zFr7cok3Eun7/G9olEpPTTd8 O5np+CanNdwtZ5KOLlTPPOCZnfNHiaU4I9FQi7moOBEAot6Xw7wCAAA= Archived-At: Cc: "draft-ietf-bfcpbis-rfc4582bis@tools.ietf.org" , "bfcpbis@ietf.org" , Alissa Cooper , Gonzalo Camarillo , Ben Campbell Subject: Re: [bfcpbis] Status update on draft-ietf-mmusic-dtls-sdp [was: draft-ietf-bfcpbis-rfc4583bis] X-BeenThere: bfcpbis@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: BFCPBIS working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 02 Nov 2015 10:39:53 -0000 SnVzdCBhIHF1ZXN0aW9uIGZvciBjbGFyaWZpY2F0aW9uOiB3aWxsIHRoZSBkcmFmdCBub3cgYWRv cHQgdGhlICdkdGxzLWNvbm5lY3Rpb24nIGF0dHJpYnV0ZSBkZWZpbmVkIGluIHRoZSBEVExTLVNE UCBkcmFmdD8NCg0KUmVnYXJkcywNCg0KQ2hyaXN0ZXINCg0KLS0tLS1PcmlnaW5hbCBNZXNzYWdl LS0tLS0NCkZyb206IENoYXJsZXMgRWNrZWwgKGVja2VsY3UpIFttYWlsdG86ZWNrZWxjdUBjaXNj by5jb21dIA0KU2VudDogMDIgTm92ZW1iZXIgMjAxNSAxMDoyNg0KVG86IFRvbSBLcmlzdGVuc2Vu ICh0b21rcmlzdCkgPHRvbWtyaXN0QGNpc2NvLmNvbT47IENocmlzdGVyIEhvbG1iZXJnIDxjaHJp c3Rlci5ob2xtYmVyZ0Blcmljc3Nvbi5jb20+DQpDYzogQWxpc3NhIENvb3BlciA8YWxpc3NhQGNv b3BlcncuaW4+OyBiZmNwYmlzQGlldGYub3JnOyBkcmFmdC1pZXRmLWJmY3BiaXMtcmZjNDU4MmJp c0B0b29scy5pZXRmLm9yZzsgR29uemFsbyBDYW1hcmlsbG8gPGdvbnphbG8uY2FtYXJpbGxvQGVy aWNzc29uLmNvbT47IEJlbiBDYW1wYmVsbCA8YmVuQG5vc3RydW0uY29tPg0KU3ViamVjdDogUmU6 IFN0YXR1cyB1cGRhdGUgb24gZHJhZnQtaWV0Zi1tbXVzaWMtZHRscy1zZHAgW3dhczogW2JmY3Bi aXNdIGRyYWZ0LWlldGYtYmZjcGJpcy1yZmM0NTgzYmlzXQ0KDQpHcmVhdCwgdGhhbmtzIFRvbS4g SSBsb29rIGZvcndhcmQgdG8gc2VlaW5nIHRoZSB1cGRhdGUgcG9zdGVkIGJlZm9yZSB0aGUgZW5k IG9mIHRoaXMgd2Vlay4NCg0KQ2hlZXJzLA0KQ2hhcmxlcw0KDQpPbiAxMS8yLzE1LCA0OjQ1IFBN LCAiVG9tIEtyaXN0ZW5zZW4gKHRvbWtyaXN0KSIgPHRvbWtyaXN0QGNpc2NvLmNvbT4NCndyb3Rl Og0KDQo+UGVyZmVjdCEgSSdsbCB1cGRhdGUgYW5kIHBvbGlzaCB0aGUgZHJhZnQgYXMgZGlzY3Vz c2VkIGFuZCBhZ3JlZWQgdXBvbiANCj5iZWxvdyBhbmQgc3VibWl0Lg0KPg0KPi0tIFRvbQ0KPg0K Pk9uIDExLzAyLzIwMTUgMDg6MDQgQU0sIENocmlzdGVyIEhvbG1iZXJnIHdyb3RlOg0KPj4gSGks DQo+Pg0KPj4gZHJhZnQtaWV0Zi1tbXVzaWMtZHRscy1zZHAgd2FzIGRpc2N1c3NlZCBhdCBNTVVT SUMgdG9kYXkuDQo+Pg0KPj4gQXQgdGhpcyBtb21lbnQgdGhlcmUgYXJlIG5vIHRlY2huaWNhbCBv cGVuIGlzc3Vlcy4gVGhlIHBsYW4gaXMgdG8gYWRkIA0KPj5zb21lIGVkaXRvcmlhbCB3b3JrLCBi YXNlZCBvbiBjb21tZW50cyByZWNlaXZlZCBkdXJpbmcgdGhlIHNlc3Npb24sIA0KPj5hbmQgdGhl IGFkZCB0ZXh0IHJlZ2FyZGluZyBEVExTLXVzYWdlIGRyYWZ0cy9zcGVjcyB0aGF0IHRoZSBkcmFm dCB1cGRhdGVzLg0KPj5BZnRlciB0aGF0LCB1bmxlc3Mgc29tZXRoaW5nIHVuZXhwZWN0ZWQgY29t ZXMgdXAsIHRoZSBkcmFmdCBzaG91bGQgYmUgDQo+PnJlYWR5IGZvciBXR0xDLg0KPj4NCj4+IFJl Z2FyZHMsDQo+Pg0KPj4gQ2hyaXN0ZXINCj4+DQo+Pg0KPj4NCj4+IC0tLS0tT3JpZ2luYWwgTWVz c2FnZS0tLS0tDQo+PiBGcm9tOiBDaGFybGVzIEVja2VsIChlY2tlbGN1KSBbbWFpbHRvOmVja2Vs Y3VAY2lzY28uY29tXQ0KPj4gU2VudDogMjggU2VwdGVtYmVyIDIwMTUgMTg6NTANCj4+IFRvOiBD aHJpc3RlciBIb2xtYmVyZzxjaHJpc3Rlci5ob2xtYmVyZ0Blcmljc3Nvbi5jb20+OyBUb20gS3Jp c3RlbnNlbiANCj4+KHRvbWtyaXN0KTx0b21rcmlzdEBjaXNjby5jb20+DQo+PiBDYzogQWxpc3Nh IENvb3BlcjxhbGlzc2FAY29vcGVydy5pbj47IGJmY3BiaXNAaWV0Zi5vcmc7IA0KPj5kcmFmdC1p ZXRmLWJmY3BiaXMtcmZjNDU4MmJpc0B0b29scy5pZXRmLm9yZzsgR29uemFsbyANCj4+Q2FtYXJp bGxvPGdvbnphbG8uY2FtYXJpbGxvQGVyaWNzc29uLmNvbT47IEJlbiANCj4+Q2FtcGJlbGw8YmVu QG5vc3RydW0uY29tPg0KPj4gU3ViamVjdDogUmU6IFtiZmNwYmlzXSBkcmFmdC1pZXRmLWJmY3Bi aXMtcmZjNDU4M2Jpcw0KPj4NCj4+IFRoYW5rcyBDaHJpc3Rlci4NCj4+DQo+PiBUb20sIGNhbiB5 b3UgcGxlYXNlIHBvc3QgdGhlIGNvcnJlc3BvbmRpbmcgdXBkYXRlIHRvIHRoZSBkcmFmdD8NCj4+ DQo+PiBDaGVlcnMsDQo+PiBDaGFybGVzDQo+Pg0KPj4gT24gOS8yOC8xNSwgMzowNyBBTSwgImJm Y3BiaXMgb24gYmVoYWxmIG9mIENocmlzdGVyIEhvbG1iZXJnIg0KPj4gPGJmY3BiaXMtYm91bmNl c0BpZXRmLm9yZyBvbiBiZWhhbGYgb2YgDQo+PiBjaHJpc3Rlci5ob2xtYmVyZ0Blcmljc3Nvbi5j b20+DQo+PiB3cm90ZToNCj4+DQo+PiAgICANCj4+PiBIaSwNCj4+Pg0KPj4+ICAgICAgDQo+Pj4+ IEluIHRoYXQgY2FzZSwgSSBwcmVmZXIgVG9t4oCZcyBvcmlnaW5hbCBzdWdnZXN0aW9uLA0KPj4+ Pg0KPj4+PiAgIFdoYXQgaWYgd2Uga2VlcCB0aGUgdGV4dCBhbmQgYWRkcyB0aGlzIGFzIGFuIGFk ZGl0aW9uYWwgcmVmZXJlbmNlIA0KPj4+PiBpbiB0aGUgdHdvIG5ldyB0ZXh0IHBhc3NhZ2VzIHBy b3Bvc2VkIGJ5IENoYXJsZXM6ICIuLi4gWzEzXSwgYW5kICANCj4+Pj4gdGhlIGNsYXJpZmljYXRp b25zIGRlZmluZWQgaW4gW2RyYWZ0LWlldGYtbW11c2ljLWR0bHMtc2RwXSwgLi4uIi4NCj4+Pj4N Cj4+Pj4gICBXaGVyZSBbMTNdIGlzIGEgcmVmZXJlbmNlIHRvIFJGQyA1NzYzLg0KPj4+PiAgICAg ICAgDQo+Pj4gSWYgdGhhdCdzIHNvbWV0aGluZyBwZW9wbGUgY2FuIGFncmVlIHRvLCB0aGVuIGNh biBsaXZlIHdpdGggc3VjaCANCj4+PiBjb21wcm9taXNlIDopDQo+Pj4NCj4+PiBSZWdhcmRzLA0K Pj4+DQo+Pj4gQ2hyaXN0ZXINCj4+Pg0KPj4+DQo+Pj4NCj4+Pg0KPj4+DQo+Pj4gSWYgaXQgdHVy bnMgb3V0IHRoYXQgZHJhZnQtaWV0Zi1tbXVzaWMtZHRscy1zZHAgdXBkYXRlcyBSRkMgNTc2Mywg DQo+Pj50aGVuICB0aGVyZSBpcyBzb21lIHJlZHVuZGFuY3kuIEJ1dCB0aGF0IGlzIGJldHRlciB0 aGFuIGhhdmluZyBhIGhvbGUgDQo+Pj53aGVuIGl0ICBjb21lcyB0byBiYWNrd2FyZCBjb21wYXRp YmlsaXR5IHdpdGggZXhpc3RpbmcgDQo+Pj5pbXBsZW1lbnRhdGlvbnMsIHdoaWNoIGlzICB3aGF0 IHdlIHdpbGwgaGF2ZSB0b2RheSBpZiB3ZSByZWZlcmVuY2UgDQo+Pj5kcmFmdC1pZXRmLW1tdXNp Yy1kdGxzLXNkcCBvbmx5Lg0KPj4+DQo+Pj4gQ2hlZXJzLA0KPj4+IENoYXJsZXMNCj4+Pg0KPj4+ DQo+Pj4NCj4+PiBPbiA5LzI1LzE1LCAyOjIxIEFNLCAiQ2hyaXN0ZXIgSG9sbWJlcmciDQo+Pj4g PGNocmlzdGVyLmhvbG1iZXJnQGVyaWNzc29uLmNvbT4NCj4+PiB3cm90ZToNCj4+Pg0KPj4+ICAg ICAgDQo+Pj4+IEhpIENoYXJsZXMsDQo+Pj4+DQo+Pj4+ICAgICAgICANCj4+Pj4+IEFzIGEgc2lt cGxlIGV4YW1wbGUsIHdlIGN1cnJlbnRseSByZWZlciB0byByZmM0NTgyYmlzIGluc3RlYWQgb2Yg DQo+Pj4+PiB0aGUgZXZlbnR1YWwgUkZDLiBBc3N1bWluZyByZmM0NTgyYmlzIGRvZXMgYmVjb21l IGFuIFJGQywgd2Ugd291bGQgDQo+Pj4+PiB3YW50IHRoZSBSRkMgZWRpdG9yIHRvIHVwZGF0ZSBy ZWZlcmVuY2VzIHRvIGl0IGFuZCB0byBSRkN4eHh4IHdpdGggDQo+Pj4+PiB0aGUgYWN0dWFsIFJG QyBudW1iZXIuDQo+Pj4+PiBTaW1pbGFyIGhlcmUsIHdlIHdvdWxkIHdhbnQgdGhlbSB0byBjaGVj ayB3aXRoIGF1dGhvcnMvY2hhaXJzL0FEcyANCj4+Pj4+IG9uIHRoZSBzdGF0ZSBvZiBkcmFmdC1p ZXRmLW1tdXNpYy1kdGxzLXNkcCB0byBzZWUgaWYgd2Ugd2FudCB0byANCj4+Pj4+IHJlcGxhY2Ug b3VyIHJlZmVyZW5jZSB0byBSRkMgNTc2MyB3aXRoIGEgcmVmZXJlbmNlIHRvIGl0LiBUaGlzIHdh eSANCj4+Pj4+IHdlIGNhbiBtb3ZlIGZvcndhcmQgd2hpbGUgZHJhZnQtaWV0Zi1tbXVzaWMtZHRs cy1zZHAgY29udGludWVzIHRvIA0KPj4+Pj4gcHJvZ3Jlc3MgYXMgd2VsbC4NCj4+Pj4+ICAgICAg ICAgIA0KPj4+PiBJIGRvbid0IHRoaW5rIGl0J3MgdGhlIHNhbWUgdGhpbmcuIEZpcnN0IHlvdSB0 YWxrIGFib3V0IGEgZHJhZnQsIA0KPj4+PiB3aGVyZSB0aGUgZHJhZnQgbmFtZSB3aWxsIGJlIHJl cGxhY2VkIHdpdGggdGhlIHRvLWJlLWFzc2lnbmVkIFJGQyANCj4+Pj4gbnVtYmVyLiBJbiB0aGUg Y2FzZSBvZiBEVExTLVNEUCB3ZSBhcmUgdGFsa2luZyBhYm91dCB0d28gc2VwYXJhdGUgc3BlY2lm aWNhdGlvbnMuDQo+Pj4+DQo+Pj4+IFJlZ2FyZHMsDQo+Pj4+DQo+Pj4+IENocmlzdGVyDQo+Pj4+ DQo+Pj4+DQo+Pj4+IE9uIDkvMjQvMTUsIDI6NTMgQU0sICJDaHJpc3RlciBIb2xtYmVyZyINCj4+ Pj4gPGNocmlzdGVyLmhvbG1iZXJnQGVyaWNzc29uLmNvbT4NCj4+Pj4gd3JvdGU6DQo+Pj4+DQo+ Pj4+ICAgICAgICANCj4+Pj4+IEhpIENoYXJsZXMsDQo+Pj4+Pg0KPj4+Pj4gSSBhbSBzdGlsbCBu b3Qgc3VyZSBJIHVuZGVyc3RhbmQgeW91ciBzdWdnZXN0aW9uOiB3aGF0IGlzIG1lYW50IGJ5IA0K Pj4+Pj4gImFzIGRldGVybWluZWQgcHJpb3IgdG8gcHVibGljYXRpb24iPyBXaGVuL3doZXJlL3do bz8gOikNCj4+Pj4+DQo+Pj4+PiBSZWdhcmRzLA0KPj4+Pj4NCj4+Pj4+IENocmlzdGVyDQo+Pj4+ Pg0KPj4+Pj4gLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCj4+Pj4+IEZyb206IENoYXJsZXMg RWNrZWwgKGVja2VsY3UpIFttYWlsdG86ZWNrZWxjdUBjaXNjby5jb21dDQo+Pj4+PiBTZW50OiAy Mi4gc3l5c2t1dXRhIDIwMTUgMTc6MDUNCj4+Pj4+IFRvOiBDaHJpc3RlciBIb2xtYmVyZzsgVG9t IEtyaXN0ZW5zZW4gKHRvbWtyaXN0KQ0KPj4+Pj4gQ2M6IGRyYWZ0LWlldGYtYmZjcGJpcy1yZmM0 NTgyYmlzQHRvb2xzLmlldGYub3JnOyANCj4+Pj4+IGJmY3BiaXNAaWV0Zi5vcmc7IEFsaXNzYSBD b29wZXI7IEdvbnphbG8gQ2FtYXJpbGxvOyBCZW4gQ2FtcGJlbGwNCj4+Pj4+IFN1YmplY3Q6IFJl OiBbYmZjcGJpc10gZHJhZnQtaWV0Zi1iZmNwYmlzLXJmYzQ1ODNiaXMNCj4+Pj4+DQo+Pj4+PiBJ IHZpZXcgcmVmZXJyaW5nIHRvIGRyYWZ0LWlldGYtbW11c2ljLWR0bHMtc2RwIG5vdyBpbnN0ZWFk IG9mIFJGQw0KPj4+Pj4gNTc2MyB0byBiZSBsaWtlIHdyaXRpbmcgYSBibGFuayBjaGVjay4gRGVi YXRlIGlzIGFjdGl2ZWx5IA0KPj4+Pj4gb2NjdXJyaW5nIG9uIHRoZSBsaXN0LCB0aGUgbm9ybWF0 aXZlIGxhbmd1YWdlIGluIFJGQyA1NzYzIGlzIA0KPj4+Pj4gZXhwZWN0ZWQgdG8gYmUgdXBkYXRl ZCBpbiBtdWx0aXBsZSB3YXlzLCBhbmQgYmFja3dhcmQgDQo+Pj4+PiBjb21wYXRpYmlsaXR5IHdp dGggdGhlIHRoZSBub3JtYXRpdmUgbGFuZ3VhZ2UgcHJvdmlkZSBpbiBwcmV2aW91cyANCj4+Pj4+ IHZlcnNpb24gb2YgcmZjNDU4M2JpcyBpcyBub3QgZnVsbHkgYWRkcmVzc2VkLiBJdCBzZWVtcyBt b3JlIA0KPj4+Pj4gYXBwcm9wcmlhdGUgdG8gbWUgYXQgdGhpcyBzdGFnZSB0byBjb250aW51ZSB0 byByZWZlciB0byBSRkMgNTc2MyANCj4+Pj4+IHdpdGggYSBub3RlIHJlZ2FyZGluZyB1cGRhdGlu ZyBvciByZXBsYWNpbmcgdGhhdCByZWZlcmVuY2Ugd2l0aCANCj4+Pj4+IG9uZSB0byBkcmFmdC1p ZXRmLW1tdXNpYy1kdGxzLXNkcCwgYXMgZGV0ZXJtaW5lZCBwcmlvciB0byBwdWJsaWNhdGlvbi4N Cj4+Pj4+DQo+Pj4+PiBDaGVlcnMsDQo+Pj4+PiBDaGFybGVzDQo+Pj4+Pg0KPj4+Pj4gT24gOS8y MS8xNSwgMTE6NDggUE0sICJDaHJpc3RlciBIb2xtYmVyZyINCj4+Pj4+IDxjaHJpc3Rlci5ob2xt YmVyZ0Blcmljc3Nvbi5jb20+DQo+Pj4+PiB3cm90ZToNCj4+Pj4+DQo+Pj4+PiAgICAgICAgICAN Cj4+Pj4+PiBIaSwNCj4+Pj4+Pg0KPj4+Pj4+ICAgICAgICAgICAgDQo+Pj4+Pj4+IEkgc2VlLiBB cyB0aGlzIGlzIGEgbW92aW5nIHRhcmdldCwgcGVyaGFwcyB3aGVyZSB3ZSByZWZlcmVuY2UgDQo+ Pj4+Pj4+IFJGQw0KPj4+Pj4+PiA1NzYzIHdlIGNhbiBhZGQgYSBub3RlIGZvciB0aGUgUkZDIGVk aXRvciB0aGF0IA0KPj4+Pj4+PiBkcmFmdC1pZXRmLW1tdXNpYy1kdGxzLXNkcCBpcyBleHBlY3Rl ZCB0byBhZGQgY2xhcmlmaWNhdGlvbnMgYW5kIA0KPj4+Pj4+PiBtYWtlIGNoYW5nZXMgdG8gUkZD IDU3NjMgdGhhdCBzaG91bGQgYmUgY29uc2lkZXJlZCBwcmlvciB0byANCj4+Pj4+Pj4gcHVibGlj YXRpb24gb2YgcmZjNDU4M2Jpcy4NCj4+Pj4+Pj4gICAgICAgICAgICANCj4+Pj4+PiBJIGFtIG5v dCBzdXJlIEkgdW5kZXJzdGFuZC4gSSBkb24ndCB0aGluayBpdCdzIHVwIHRvIHRoZSBSRkMgDQo+ Pj4+Pj4gZWRpdG9yIHRvIG1ha2UgYSBkZWNpc2lvbiB3aGV0aGVyIHRoZSBkcmFmdCBzaG91bGQg cmVmZXJlbmNlIERUTFMtU0RQLg0KPj4+Pj4+DQo+Pj4+Pj4gUmVnYXJkcywNCj4+Pj4+Pg0KPj4+ Pj4+IENocmlzdGVyDQo+Pj4+Pj4NCj4+Pj4+Pg0KPj4+Pj4+DQo+Pj4+Pj4gT24gOS8yMS8xNSwg MTE6MjMgQU0sICJDaHJpc3RlciBIb2xtYmVyZyINCj4+Pj4+PiA8Y2hyaXN0ZXIuaG9sbWJlcmdA ZXJpY3Nzb24uY29tPg0KPj4+Pj4+IHdyb3RlOg0KPj4+Pj4+DQo+Pj4+Pj4gICAgICAgICAgICAN Cj4+Pj4+Pj4gSGksDQo+Pj4+Pj4+DQo+Pj4+Pj4+ICAgICAgICAgICAgDQo+Pj4+Pj4+PiBSRkMg NTc2Mywgd2hpY2ggaXMgY3VycmVudGx5IHJlcXVpcmVkIGZvciBCRkNQIHdpdGggRFRMUyByZWFk czoNCj4+Pj4+Pj4+DQo+Pj4+Pj4+PiAgICBvICBUaGUgZW5kcG9pbnQgTVVTVCBOT1QgdXNlIHRo ZSBjb25uZWN0aW9uIGF0dHJpYnV0ZSANCj4+Pj4+Pj4+ZGVmaW5lZCBpbg0KPj4+Pj4+Pj4gICAg ICBbUkZDNDE0NTxodHRwczovL3Rvb2xzLmlldGYub3JnL2h0bWwvcmZjNDE0NT5dLg0KPj4+Pj4+ Pj4gICAgICAgICAgIA0KPj4+Pj4+PiBDb3JyZWN0Lg0KPj4+Pj4+Pg0KPj4+Pj4+PiBBbmQsIElG IHdlIGRlY2lkZSB0byB1c2UgZGVmaW5lIHVzYWdlIG9mIHRoZSAnY29ubmVjdGlvbicgDQo+Pj4+ Pj4+IGF0dHJpYnV0ZSBmb3IgRFRMUywgd2Ugd291bGQgY2hhbmdlIHRoYXQuDQo+Pj4+Pj4+DQo+ Pj4+Pj4+IEhvd2V2ZXIsIGEgZmV3IGRheXMgYWdvIHdlIHNlbnQgYW4gZS1tYWlsIHRvIHRoZSBN TVVTSUMgbGlzdCwgIA0KPj4+Pj4+PnN1Z2dlc3RpbmcgdGhhdCB3ZSBzaG91bGQgTk9UIHVzZSB0 aGUgJ2Nvbm5lY3Rpb24nIGF0dHJpYnV0ZSBmb3IgDQo+Pj4+Pj4+RFRMUy4NCj4+Pj4+Pj4gSW5z dGVhZCB3ZSBzaG91bGQgZGVmaW5lIGEgbmV3IGF0dHJpYnV0ZSAoZm9yIG1vcmUgZGV0YWlscywg DQo+Pj4+Pj4+cGxlYXNlICBzZWUgdGhlIE1NVVNJQyBsaXN0KS4NCj4+Pj4+Pj4NCj4+Pj4+Pj4g ICAgICAgICAgICANCj4+Pj4+Pj4+IFNlY3Rpb24gNS4xIG9mIGRyYWZ0LWlldGYtbW11c2ljLWR0 bHMtc2RwIHJlYWRzOg0KPj4+Pj4+Pj4NCj4+Pj4+Pj4+ICAgIFdoZW4gdXNlZCB3aXRoIERUTFMs IHRoZXJlIGlzIG5vIGRlZmF1bHQgdmFsdWUgZGVmaW5lZCBmb3IgdGhlDQo+Pj4+Pj4+PiAgICBh dHRyaWJ1dGUuICBJbXBsZW1lbnRhdGlvbnMgdGhhdCB3aXNoIHRvIHVzZSB0aGUgYXR0cmlidXRl IE1VU1QNCj4+Pj4+Pj4+ICAgIGV4cGxpY2l0bHkgaW5jbHVkZSBpdCBpbiBTRFAgb2ZmZXJzIGFu ZCBhbnN3ZXJzLiAgSWYgYW4gDQo+Pj4+Pj4+Pm9mZmVyIG9yDQo+Pj4+Pj4+PiAgICBhbnN3ZXIg ZG9lcyBub3QgY29udGFpbiBhbiBhdHRyaWJ1dGUsIG90aGVyIG1lYW5zIG5lZWRzIHRvIA0KPj4+ Pj4+Pj5iZSAgdXNlZCBpbg0KPj4+Pj4+Pj4gICAgb3JkZXIgZm9yIGVuZHBvaW50cyB0byBkZXRl cm1pbmUgd2hldGhlciBhbiBvZmZlciBvciBhbnN3ZXIgaXMNCj4+Pj4+Pj4+ICAgIGFzc29jaWF0 ZWQgd2l0aCBhbiBldmVudCB0aGF0IHJlcXVpcmVzIHRoZSBEVExTIGFzc29jaWF0aW9uIA0KPj4+ Pj4+Pj50byAgYmUNCj4+Pj4+Pj4+IHJlLQ0KPj4+Pj4+Pj4gICAgZXN0YWJsaXNoZWQuDQo+Pj4+ Pj4+Pg0KPj4+Pj4+Pj4gSSBzdXBwb3NlIGlmIGRyYWZ0LWlldGYtbW11c2ljLWR0bHMtc2RwIHB1 bGxzIGluIGVub3VnaCBmcm9tIA0KPj4+Pj4+Pj4gUkZDDQo+Pj4+Pj4+PiA1NzYzIHRvIG1ha2Ug aXQgY2xlYXIgaG93IHRoZSBEVExTIGVzdGFibGlzaG1lbnQgYW5kIA0KPj4+Pj4+Pj4gcmUtZXN0 YWJsaXNobWVudCB3b3JrcyBmb3IgdGhlIGNhc2Ugb2Ygd2hpY2ggdGhlIGNvbm5lY3Rpb24gDQo+ Pj4+Pj4+PiBhdHRyaWJ1dGUgaXMgbm90IHVzZWQsIHRoZW4gd2UgY2FuIGNoYW5nZSB0aGUgcmVm ZXJlbmNlIGZyb20gDQo+Pj4+Pj4+PiBSRkMNCj4+Pj4+Pj4+IDU3NjMgdG8gZHJhZnQtaWV0Zi1t bXVzaWMtZHRscy1zZHAuDQo+Pj4+Pj4+Pg0KPj4+Pj4+Pj4gVGhlIGxhc3Qgc2V2ZXJhbCB1cGRh dGVzIG9mIGRyYWZ0LWlldGYtYmZjcGJpcy1yZmM0NTgzYmlzIGhhdmUgDQo+Pj4+Pj4+PiByZW1v dmVkIHN1cHBvcnRpbmcgdGV4dCBmcm9tIHRoZSBkcmFmdCBpbiBmYXZvciBvZiBwb2ludGluZyB0 byANCj4+Pj4+Pj4+IFJGQw0KPj4+Pj4+Pj4gNTc2MyBhcyB0aGUgIHNvdXJjZSBvZiB0cnV0aC4g SSBmZWFyIHRoYXQgDQo+Pj4+Pj4+PiBkcmFmdC1pZXRmLW1tdXNpYy1kdGxzLXNkcCBpbiBpdHMg Y3VycmVudCBzdGF0ZSBkb2VzIG5vdCBzZXJ2ZSANCj4+Pj4+Pj4+IHRoYXQgbmVlZCBmb3IgZHJh ZnQtaWV0Zi1iZmNwYmlzLXJmYzQ1ODNiaXMuIEkgdmFsdWUgIA0KPj4+Pj4+Pj4gQ2hyaXN0ZXLi gJlzIHRob3VnaHRzIGFuZCB3ZWxjb21lIHRoZSBvcGluaW9uIG9mIG90aGVycywgDQo+Pj4+Pj4+ PiBlc3BlY2lhbGx5IHRob3NlIHdobyBoYXZlIG9yIGFyZSBpbXBsZW1lbnRpbmcgQkZDUCB3aXRo IERUTFMgYW5kIElDRSwgd2hpY2ggSSBoYXZlIG5vdC4NCj4+Pj4+Pj4+ICAgICAgICAgICANCj4+ Pj4+Pj4gUGxlYXNlIG5vdGUgdGhhdCBEVExTLVNEUCBkb2VzIG5vdCBvbmx5IGRlZmluZSB1c2Fn ZSBvZiB0aGUgDQo+Pj4+Pj4+ICdjb25uZWN0aW9uJw0KPj4+Pj4+PiBhdHRyaWJ1dGUsIGl0IGFs c28gZG9lcyBvdGhlciB0aGluZ3MuIE1heWJlIG1vcmUgaW1wb3J0YW50LCBpdCANCj4+Pj4+Pj4g ZG9lcyBub3Qgc3RhdGUgdGhhdCBhbiBhZGRyZXNzIGNoYW5nZSBieSBkZWZhdWx0IHJlcXVpcmVz IGEgbmV3IA0KPj4+Pj4+PiBEVExTIGFzc29jaWF0aW9uDQo+Pj4+Pj4+IC0gd2hpY2ggaXMgYSBh bm90aGVyIDU3NjMgbW9kaWZpY2F0aW9uLg0KPj4+Pj4+Pg0KPj4+Pj4+PiBSZWdhcmRzLA0KPj4+ Pj4+Pg0KPj4+Pj4+PiBDaHJpc3Rlcg0KPj4+Pj4+Pg0KPj4+Pj4+Pg0KPj4+Pj4+Pg0KPj4+Pj4+ Pg0KPj4+Pj4+PiBPbiA5LzIxLzE1LCA5OjMyIEFNLCAiYmZjcGJpcyBvbiBiZWhhbGYgb2YgQ2hy aXN0ZXIgSG9sbWJlcmciDQo+Pj4+Pj4+IDxiZmNwYmlzLWJvdW5jZXNAaWV0Zi5vcmcgb24gYmVo YWxmIG9mIA0KPj4+Pj4+PiBjaHJpc3Rlci5ob2xtYmVyZ0Blcmljc3Nvbi5jb20+DQo+Pj4+Pj4+ IHdyb3RlOg0KPj4+Pj4+Pg0KPj4+Pj4+PiAgICAgICAgICAgIA0KPj4+Pj4+Pj4gSGkgQ2hhcmxl cywNCj4+Pj4+Pj4+DQo+Pj4+Pj4+PiAgICAgICAgICAgDQo+Pj4+Pj4+Pj4gVGhlIHByb2JsZW0g SSBzZWUgd2l0aCB0aGlzIGlzIHRoYXQgaXQgaXMgbm90IGp1c3QgYSBtYXR0ZXIgb2YgDQo+Pj4+ Pj4+Pj4gY2hhbmdpbmcgdGhlIHJlZmVyZW5jZSwgaXQgaXMgYWxzbyBhIG1hdHRlciBvZiBjaGFu Z2luZyB0aGUgDQo+Pj4+Pj4+Pj4gbm9ybWF0aXZlIGJlaGF2aW9yLg0KPj4+Pj4+Pj4+IEZvciBE VExTIHdpdGggQkZDUCwgd2UgbmV2ZXIgcmVxdWlyZWQgdGhlIHVzZSBvZiB0aGU+4oCcY29ubmVj dGlvbuKAnQ0KPj4+Pj4+Pj4+IGF0dHJpYnV0ZS4NCj4+Pj4+Pj4+PiBJZiB3ZSBhcmUgdG8gc3Rh cnQgcmVxdWlyaW5nIGl0LCB3ZSB3b3VsZCBuZWVkIGFkZCB0ZXh0IHRvIA0KPj4+Pj4+Pj4+IGRl c2NyaWJlIGhvdyB0byBhZGRyZXNzIGJhY2t3YXJkIGNvbXBhdGliaWxpdHkgaW4gY2FzZXMgaW4g DQo+Pj4+Pj4+Pj4gd2hpY2ggdGhlIGNvbm5lY3Rpb24gYXR0cmlidXRlIGlzIG5vdCBzcGVjaWZp ZWQuDQo+Pj4+Pj4+Pj4gICAgICAgICAgDQo+Pj4+Pj4+PiBUaGUgaW50ZW50aW9uIGlzIHRvIGNv dmVyIGJhY2t3YXJkIGNvbXBhdGliaWxpdHkgaW4gdGhlIGRyYWZ0Lg0KPj4+Pj4+Pj4NCj4+Pj4+ Pj4+ICAgICAgICAgICANCj4+Pj4+Pj4+PiBBcmUgdGhlcmUgcGxhbnMgZm9yIHRoaXMgd2l0aGlu IFJGQyA1NzYzYmlzIGRyYWZ0PyBJZiBzbywgDQo+Pj4+Pj4+Pj4gVG9t4oCZcyByZWNvbW1lbmRh dGlvbiBvZiBjb250aW51aW5nIHRvIHBvaW50IHRvIFJGQyA1NzYzIGZvciANCj4+Pj4+Pj4+PiBu b3cgbWF5IGJlIHRoZSBiZXN0IGFwcHJvYWNoLg0KPj4+Pj4+Pj4+ICAgICAgICAgIA0KPj4+Pj4+ Pj4gSSBhbSBub3QgZmFtaWxpYXIgd2l0aCB0aGUgNTc2M2JpcyBkcmFmdC4gQnV0LCBldmVuIGlm IHRoZSAgDQo+Pj4+Pj4+PkRUTFMtU0RQIGRyYWZ0IG1ha2VzIHVwZGF0ZXMgdG8gNTc2MywgaXQg d29uJ3QgYmVjb21lIGEgNTc2M2JpcyANCj4+Pj4+Pj4+ZHJhZnQuDQo+Pj4+Pj4+Pg0KPj4+Pj4+ Pj4gUmVnYXJkcywNCj4+Pj4+Pj4+DQo+Pj4+Pj4+PiBDaHJpc3Rlcg0KPj4+Pj4+Pj4NCj4+Pj4+ Pj4+DQo+Pj4+Pj4+Pg0KPj4+Pj4+Pj4gT24gOS8xMS8xNSwgMToxMSBQTSwgIkNocmlzdGVyIEhv bG1iZXJnIg0KPj4+Pj4+Pj4gPGNocmlzdGVyLmhvbG1iZXJnQGVyaWNzc29uLmNvbT4NCj4+Pj4+ Pj4+IHdyb3RlOg0KPj4+Pj4+Pj4NCj4+Pj4+Pj4+ICAgICAgICAgICANCj4+Pj4+Pj4+PiBIaSwN Cj4+Pj4+Pj4+Pg0KPj4+Pj4+Pj4+ICAgICAgICAgIA0KPj4+Pj4+Pj4+PiBIbW0sIHllcyBtYXli ZSBhbiBpZGVhIGlmIGl0J3MgZmluZSBwcm9jZWVkaW5nIHdpdGggcmVmZXJyaW5nIA0KPj4+Pj4+ Pj4+PmEgIHdvcmstaW4tcHJvZ3Jlc3MgZHJhZnQgaGVyZS4NCj4+Pj4+Pj4+Pj4gV2hhdCBpZiB3 ZSBrZWVwIHRoZSB0ZXh0IGFuZCBhZGRzIHRoaXMgYXMgYW4gYWRkaXRpb25hbCAgDQo+Pj4+Pj4+ Pj4+cmVmZXJlbmNlIGluIHRoZSB0d28gbmV3IHRleHQgcGFzc2FnZXMgcHJvcG9zZWQgYnkgQ2hh cmxlczogIi4uLg0KPj4+Pj4+Pj4+PiBbMTNdLCBhbmQgdGhlIGNsYXJpZmljYXRpb25zIGRlZmlu ZWQgaW4gDQo+Pj4+Pj4+Pj4+W2RyYWZ0LWlldGYtbW11c2ljLWR0bHMtc2RwXSwgLi4uIi4NCj4+ Pj4+Pj4+Pj4NCj4+Pj4+Pj4+Pj4gV2hlcmUgWzEzXSBpcyBhIHJlZmVyZW5jZSB0byBSRkMgNTc2 My4NCj4+Pj4+Pj4+Pj4gICAgICAgICANCj4+Pj4+Pj4+PiBNeSBzdWdnZXN0aW9uIGlzIHRvICpv bmx5KiByZWZlciB0aGUgbmV3IGR0bHMtc2RwIGRyYWZ0LiANCj4+Pj4+Pj4+PiBCZWNhdXNlLCBv bmUgb2YgdGhlIGlkZWFzIHdpdGggdGhlIG5ldyBkcmFmdCBpcyB0byBhbHNvIHVwZGF0ZSANCj4+ Pj4+Pj4+PiBSRkMgNTc2MyB0byByZWZlcmVuY2UgdGhlIG5ldyBkdGxzLXNkcCBkcmFmdC4NCj4+ Pj4+Pj4+Pg0KPj4+Pj4+Pj4+ICAgICAgICAgIA0KPj4+Pj4+Pj4+PiBBbnl3YXksIEknZCBzdGls bCBwcmVmZXIgdG8ga2VlcCB0aGUgdGV4dCBpbg0KPj4+Pj4+Pj4+PiBkcmFmdC1pZXRmLWJmY3Bi aXMtcmZjNDU4M2Jpcy0xMiBhbmQgcmVkaXJlY3QgdGhlIHJlYWRlcnMgdG8gDQo+Pj4+Pj4+Pj4+ IHRoZSByZmM1NzYzYmlzLCB0aGF0IGV2ZW50dWFsbHkgdGhlbiB3aWxsIG9ic29sZXRlIChvciAN Cj4+Pj4+Pj4+Pj4gZXh0ZW5kPykgUkZDIDU3NjMuDQo+Pj4+Pj4+Pj4+ICAgICAgICAgDQo+Pj4+ Pj4+Pj4gVGhlIG5ldyBkdGxzLXNkcCBkcmFmdCB3aWxsIG5vdCBiZWNvbWUgNTc2M2JpcyAoZXZl bnRob3VnaCBpdCANCj4+Pj4+Pj4+PiBNQVkgdXBkYXRlIHNvbWUgcGFydHMgb2YgNTc2MykuIEl0 J3MgYSBnZW5lcmljIGRvY3VtZW50LCB3aGljaCANCj4+Pj4+Pj4+PiAqYW55KiBEVExTIHVzYWdl IGNhbiB0aGVuIHJlZmVyZW5jZS4NCj4+Pj4+Pj4+Pg0KPj4+Pj4+Pj4+IFJlZ2FyZHMsDQo+Pj4+ Pj4+Pj4NCj4+Pj4+Pj4+PiBDaHJpc3Rlcg0KPj4+Pj4+Pj4+DQo+Pj4+Pj4+Pj4NCj4+Pj4+Pj4+ Pg0KPj4+Pj4+Pj4+IE9uIDA5LzExLzIwMTUgMDE6MjUgUE0sIENocmlzdGVyIEhvbG1iZXJnIHdy b3RlOg0KPj4+Pj4+Pj4+ICAgICAgICAgIA0KPj4+Pj4+Pj4+PiBIaSwNCj4+Pj4+Pj4+Pj4NCj4+ Pj4+Pj4+Pj4gTXkgc3VnZ2VzdGlvbiB3b3VsZCBhY3R1YWxseSBiZSB0byByZWZlciB0byB0aGUg bmV3IA0KPj4+Pj4+Pj4+PiBkcmFmdC1pZXRmLW1tdXNpYy1kdGxzLXNkcCwgd2hpY2ggaXMgZ29p bmcgdG8gY2xhcmlmeSB0aGUgDQo+Pj4+Pj4+Pj4+IERUTFMtU1JUUCBydWxlcyByZWdhcmRpbmcg d2hlbiBhIG5ldyBEVExTIGFzc29jaWF0aW9uIG11c3QgYmUgDQo+Pj4+Pj4+Pj4+IGVzdGFibGlz aGVkLg0KPj4+Pj4+Pj4+Pg0KPj4+Pj4+Pj4+PiBSZWdhcmRzLA0KPj4+Pj4+Pj4+Pg0KPj4+Pj4+ Pj4+PiBDaHJpc3Rlcg0KPj4+Pj4+Pj4+Pg0KPj4+Pj4+Pj4+PiAtLS0tLU9yaWdpbmFsIE1lc3Nh Z2UtLS0tLQ0KPj4+Pj4+Pj4+PiBGcm9tOiBUb20gS3Jpc3RlbnNlbiBbbWFpbHRvOnRvbWtyaXN0 QGNpc2NvLmNvbV0NCj4+Pj4+Pj4+Pj4gU2VudDogMTEuIHN5eXNrdXV0YSAyMDE1IDEzOjI1DQo+ Pj4+Pj4+Pj4+IFRvOiBDaGFybGVzIEVja2VsIChlY2tlbGN1KQ0KPj4+Pj4+Pj4+PiBDYzogQ2hy aXN0ZXIgSG9sbWJlcmc7IEFsaXNzYSBDb29wZXI7IEdvbnphbG8gQ2FtYXJpbGxvOyANCj4+Pj4+ Pj4+Pj4gZHJhZnQtaWV0Zi1iZmNwYmlzLXJmYzQ1ODJiaXNAdG9vbHMuaWV0Zi5vcmc7IEJlbiBD YW1wYmVsbDsgDQo+Pj4+Pj4+Pj4+IGJmY3BiaXNAaWV0Zi5vcmcNCj4+Pj4+Pj4+Pj4gU3ViamVj dDogUmU6IGRyYWZ0LWlldGYtYmZjcGJpcy1yZmM0NTgzYmlzDQo+Pj4+Pj4+Pj4+DQo+Pj4+Pj4+ Pj4+IFBvaW50aW5nIHRvIHRoZSBEVExTLVNSVFAgKGFuZCBieSB0aGF0IGFueSB1cGRhdGVzIG9m IGl0KSBpcyANCj4+Pj4+Pj4+Pj4gYSBzaW1wbGUsIHNhZmUgYW5kIHN0cmFpZ3QtZm9yd2FyZCBz b2x1dGlvbi4NCj4+Pj4+Pj4+Pj4NCj4+Pj4+Pj4+Pj4gVGhlIG9ubHkgY2hhbmdlIGluIHRoZSBu ZXcgdmVyc2lvbiBvZiByZmM0NTgzYmlzIGp1c3Qgc3VibWl0dGVkLg0KPj4+Pj4+Pj4+PiBBbmQg YXMgQ2hhcmxlcyBzYXlzLCB0aGlzIHNob3VsZCBiZSB0aGUgbGFzdCBtaXNzaW5nIGZpeCBmb3Ig DQo+Pj4+Pj4+Pj4+IHRoaXMgZHJhZnQgdW50aWwgbmV4dCBzdGFnZXMgaW4gdGhlIHByb2Nlc3Mg YXQgbGVhc3QuDQo+Pj4+Pj4+Pj4+DQo+Pj4+Pj4+Pj4+IC0tIFRvbQ0KPj4+Pj4+Pj4+Pg0KPj4+ Pj4+Pj4+PiBPbiAwOS8wOC8yMDE1IDA3OjQ4IFBNLCBDaGFybGVzIEVja2VsIChlY2tlbGN1KSB3 cm90ZToNCj4+Pj4+Pj4+Pj4NCj4+Pj4+Pj4+Pj4gICAgICAgICANCj4+Pj4+Pj4+Pj4+IFBpY2tp bmcgdXAgb24gdGhpcyBvbGQgdGhyZWFkIHJlZ2FyZGluZyANCj4+Pj4+Pj4+Pj4+IGRyYWZ0LWll dGYtYmZjcGJpcy1yZmM0NTgzYmlzLg0KPj4+Pj4+Pj4+Pj4gSSB0aGluayB0aGlzIGlzIHRoZSBv bmx5IG91dHN0YW5kaW5nIGl0ZW0gd2l0aCByZXNwZWN0IHRvIA0KPj4+Pj4+Pj4+Pj4gdGhlIGN1 cnJlbnQgIHZlcnNpb24gb2YgdGhlIGRyYWZ0LiBVbmxlc3MgYW55b25lIGhhcyBhbiANCj4+Pj4+ Pj4+Pj4+IGlzc3VlIHdpdGggdGhlIHByb3Bvc2VkICByZXNvbHV0aW9uLCBJIHJlcXVlc3Qgd2Ug dXBkYXRlIHRoZSANCj4+Pj4+Pj4+Pj4+IGRyYWZ0IGFjY29yZGluZ2x5IGFuZCB0aGVuIHVzZSBp dCAgYXMgdGhlIGJhc2lzIGZvciBNYXJ5LCANCj4+Pj4+Pj4+Pj4+IHRoZSBkb2N1bWVudCBzaGVw aGVyZCwgdG8gcHJvdmlkZSBhIHByb3RvIHdyaXRldXAuDQo+Pj4+Pj4+Pj4+Pg0KPj4+Pj4+Pj4+ Pj4gQ2hlZXJzLA0KPj4+Pj4+Pj4+Pj4gQ2hhcmxlcw0KPj4+Pj4+Pj4+Pj4NCj4+Pj4+Pj4+Pj4+ DQo+Pj4+Pj4+Pj4+PiBPbiA0LzIwLzE1LCAxMDozOSBBTSwgIkNoYXJsZXMgRWNrZWwgDQo+Pj4+ Pj4+Pj4+PiAoZWNrZWxjdSkiPGVja2VsY3VAY2lzY28uY29tPg0KPj4+Pj4+Pj4+Pj4gd3JvdGU6 DQo+Pj4+Pj4+Pj4+Pg0KPj4+Pj4+Pj4+Pj4NCj4+Pj4+Pj4+Pj4+DQo+Pj4+Pj4+Pj4+PiAgICAg ICAgDQo+Pj4+Pj4+Pj4+Pj4gSGkgQ2hyaXN0ZXIsDQo+Pj4+Pj4+Pj4+Pj4NCj4+Pj4+Pj4+Pj4+ PiBJIHJlcmVhZCB0aGUgY3VycmVudCBkcmFmdCBhbmQgd2VudCB0aHJvdWdoIHRoZSBmb2xsb3dp bmcgDQo+Pj4+Pj4+Pj4+Pj4gTU1VU0lDIHRocmVhZCBvbiB0aGlzIHN1YmplY3Q6DQo+Pj4+Pj4+ Pj4+Pj4gaHR0cDovL3d3dy5pZXRmLm9yZy9tYWlsLWFyY2hpdmUvd2ViL21tdXNpYy9jdXJyZW50 L21zZzE0NjMxLg0KPj4+Pj4+Pj4+Pj4+IGgNCj4+Pj4+Pj4+Pj4+PiB0DQo+Pj4+Pj4+Pj4+Pj4g bQ0KPj4+Pj4+Pj4+Pj4+IGwNCj4+Pj4+Pj4+Pj4+Pg0KPj4+Pj4+Pj4+Pj4+IEFzIGEgcmVzdWx0 LCBJIGJldHRlciB1bmRlcnN0YW5kIHRoZSBpc3N1ZSB5b3UgYXJlIGFkZHJlc3NpbmcuDQo+Pj4+ Pj4+Pj4+Pj4gSSBzdWdnZXN0IHRoZSBmb2xsb3dpbmcgY2hhbmdlcyB0byBiZSBjb25zaXN0ZW50 IHdpdGggd2hhdCANCj4+Pj4+Pj4+Pj4+PiBpcyBiZWluZyBwcm9wb3NlZCBpbg0KPj4+Pj4+Pj4+ Pj4+IE1NVVNJQzoNCj4+Pj4+Pj4+Pj4+Pg0KPj4+Pj4+Pj4+Pj4+IC0tLS0tLS0tLS0tLQ0KPj4+ Pj4+Pj4+Pj4+IFNlY3Rpb24gOToNCj4+Pj4+Pj4+Pj4+Pg0KPj4+Pj4+Pj4+Pj4+IE9MRDoNCj4+ Pj4+Pj4+Pj4+PiBFbmRwb2ludHMgdGhhdCB1c2UgdGhlIG9mZmVyL2Fuc3dlciBtb2RlbCB0byBl c3RhYmxpc2ggYSBEVExTDQo+Pj4+Pj4+Pj4+Pj4gICAgICBhc3NvY2lhdGlvbiBNVVNUIHN1cHBv cnQgdGhlICdzZXR1cCcgYXR0cmlidXRlLCBhcyANCj4+Pj4+Pj4+Pj4+PiBkZWZpbmVkIGluIFs3 XS4NCj4+Pj4+Pj4+Pj4+PiBXaGVuIERUTFMgaXMgdXNlZCB3aXRoIFVEUCwgdGhlICdzZXR1cCcg YXR0cmlidXRlIGluZGljYXRlcyANCj4+Pj4+Pj4+Pj4+PiB3aGljaCBvZiB0aGUgZW5kcG9pbnRz IChjbGllbnQgb3IgZmxvb3IgY29udHJvbCBzZXJ2ZXIpIA0KPj4+Pj4+Pj4+Pj4+IGluaXRpYXRl cyB0aGUgRFRMUyBhc3NvY2lhdGlvbiBzZXR1cC4gVGhlIHJlcXVpcmVtZW50cyBmb3IgDQo+Pj4+ Pj4+Pj4+Pj4gdGhlIG9mZmVyL2Fuc3dlciBleGNoYW5nZSBzcGVjaWZpZWQgaW4gWzEzXSwgU2Vj dGlvbiA1IG9mIA0KPj4+Pj4+Pj4+Pj4+IFsxM10gTVVTVCBiZSBmb2xsb3dlZCB3aGVuIHVzaW5n IERUTFMuDQo+Pj4+Pj4+Pj4+Pj4gT2ZmZXIvYW5zd2VyIGNvbnNpZGVyYXRpb25zIGFyZSBkZXNj cmliZWQgaW4gU2VjdGlvbiAxMC41Lg0KPj4+Pj4+Pj4+Pj4+DQo+Pj4+Pj4+Pj4+Pj4gTkVXOg0K Pj4+Pj4+Pj4+Pj4+IFdoZW4gRFRMUyBpcyB1c2VkIHdpdGggVURQLCB0aGUgcmVxdWlyZW1lbnRz IHNwZWNpZmllZCBpbiANCj4+Pj4+Pj4+Pj4+PiBTZWN0aW9uDQo+Pj4+Pj4+Pj4+Pj4gNSBvZiBb MTNdIE1VU1QgYmUgZm9sbG93ZWQuDQo+Pj4+Pj4+Pj4+Pj4NCj4+Pj4+Pj4+Pj4+Pg0KPj4+Pj4+ Pj4+Pj4+IFNlY3Rpb24gMTAuNQ0KPj4+Pj4+Pj4+Pj4+DQo+Pj4+Pj4+Pj4+Pj4gT0xEDQo+Pj4+ Pj4+Pj4+Pj4gICAgICBJZiB0aGUgdHJhbnNwb3J0IHBhcmFtZXRlcnMgb3IgdGhlIGtleSBmaW5n ZXJwcmludHMgDQo+Pj4+Pj4+Pj4+Pj4gY2hhbmdlLCB0aGUNCj4+Pj4+Pj4+Pj4+PiAgICAgIGVu ZHBvaW50cyBNVVNUIGVzdGFibGlzaCBhIG5ldyBEVExTIGNvbm5lY3Rpb24uICBJbiANCj4+Pj4+ Pj4+Pj4+PiBzdWNoIGNhc2UgdGhlDQo+Pj4+Pj4+Pj4+Pj4gICAgICAnYWN0aXZlL3Bhc3NpdmUn IHN0YXR1cyBvZiB0aGUgZW5kcG9pbnRzIHdpbGwgYWdhaW4gYmUgDQo+Pj4+Pj4+Pj4+Pj4gZGV0 ZXJtaW5lZA0KPj4+Pj4+Pj4+Pj4+ICAgICAgZm9sbG93aW5nIHRoZSBwcm9jZWR1cmVzIGluIFs3 XSwgYW5kIHRoZSBuZXcgc3RhdHVzIA0KPj4+Pj4+Pj4+Pj4+IHdpbGwgYmUgdXNlZCB0bw0KPj4+ Pj4+Pj4+Pj4+ICAgICAgZGV0ZXJtaW5lIHRoZSBUTFMgcm9sZXMgYXNzb2NpYXRlZCB3aXRoIHRo ZSBuZXcgRFRMUyANCj4+Pj4+Pj4+Pj4+PiBjb25uZWN0aW9uLg0KPj4+Pj4+Pj4+Pj4+DQo+Pj4+ Pj4+Pj4+Pj4gICAgICAgICBJbmZvcm1hdGlvbmFsIG5vdGU6IFRoZSBwcm9jZWR1cmUgYWJvdmUg aXMgDQo+Pj4+Pj4+Pj4+Pj4gaWRlbnRpY2FsIHRvIHRoZSBvbmUNCj4+Pj4+Pj4+Pj4+PiAgICAg ICAgIGRlZmluZWQgZm9yIERUTFMtU1JUUCBpbiBbMTNdLg0KPj4+Pj4+Pj4+Pj4+DQo+Pj4+Pj4+ Pj4+Pj4gICAgICAgICBOb3RlOiBBIG5ldyBEVExTIGNvbm5lY3Rpb24gbmVlZHMgdG8gYmUgZXN0 YWJsaXNoZWQgDQo+Pj4+Pj4+Pj4+Pj4gaWYgdGhlDQo+Pj4+Pj4+Pj4+Pj4gICAgICAgICB0cmFu c3BvcnQgcGFyYW1ldGVycyBvciB0aGUga2V5IGZpbmdlcnByaW50cyBjaGFuZ2UuDQo+Pj4+Pj4+ Pj4+Pj4NCj4+Pj4+Pj4+Pj4+Pg0KPj4+Pj4+Pj4+Pj4+DQo+Pj4+Pj4+Pj4+Pj4gTkVXOg0KPj4+ Pj4+Pj4+Pj4+IFRoZSBjb25kaXRpb25zIHVuZGVyIHdoaWNoIGVuZHBvaW50cyBNVVNUIGVzdGFi bGlzaCBhIG5ldyANCj4+Pj4+Pj4+Pj4+PiBEVExTIGNvbm5lY3Rpb24gYXJlIGFzIHRoZSBzYW1l IGRlZmluZWQgZm9yIERUTFMtU1JUUCBpbiBbMTNdLg0KPj4+Pj4+Pj4+Pj4+IOKAlOKAlOKAlOKA lOKAlOKAlOKAlOKAlA0KPj4+Pj4+Pj4+Pj4+DQo+Pj4+Pj4+Pj4+Pj4gVGhpcyB3YXkgd2UgYXZv aWQgYW55IHBvdGVudGlhbCBjb25mbGljdHMgd2l0aCB0aGUgaW50ZW50IA0KPj4+Pj4+Pj4+Pj4+ IG9mIFJGQyA1NzYzLCBhbmQgd2hlbiBjbGFyaWZpY2F0aW9ucyB0byBSRkMgNTc2MyBhcmUgbWFk ZSwgDQo+Pj4+Pj4+Pj4+Pj4gdGhleSB3aWxsIGJlIHBpY2tlZCB1cCBieSB0aGUgQkZDUCBzcGVj Lg0KPj4+Pj4+Pj4+Pj4+DQo+Pj4+Pj4+Pj4+Pj4gQ2hlZXJzLA0KPj4+Pj4+Pj4+Pj4+IENoYXJs ZXMNCj4+Pj4+Pj4+Pj4+Pg0KPj4+Pj4+Pj4+Pj4+DQo+Pj4+Pj4+Pj4+Pj4NCj4+Pj4+Pj4+Pj4+ Pg0KPj4+Pj4+Pj4+Pj4+IE9uIDQvMTgvMTUsIDI6MDEgUE0sICJDaHJpc3RlciANCj4+Pj4+Pj4+ Pj4+PiBIb2xtYmVyZyI8Y2hyaXN0ZXIuaG9sbWJlcmdAZXJpY3Nzb24uY29tPg0KPj4+Pj4+Pj4+ Pj4+IHdyb3RlOg0KPj4+Pj4+Pj4+Pj4+DQo+Pj4+Pj4+Pj4+Pj4NCj4+Pj4+Pj4+Pj4+Pg0KPj4+ Pj4+Pj4+Pj4+ICAgICAgIA0KPj4+Pj4+Pj4+Pj4+PiBIaSBDaGFybGVzLA0KPj4+Pj4+Pj4+Pj4+ Pg0KPj4+Pj4+Pj4+Pj4+Pg0KPj4+Pj4+Pj4+Pj4+Pg0KPj4+Pj4+Pj4+Pj4+PiAgICAgIA0KPj4+ Pj4+Pj4+Pj4+Pj4gW2FkZGluZyBiZmNwcGJpcyBsaXN0XQ0KPj4+Pj4+Pj4+Pj4+Pj4NCj4+Pj4+ Pj4+Pj4+Pj4+IEhpIENocmlzdGVyLA0KPj4+Pj4+Pj4+Pj4+Pj4NCj4+Pj4+Pj4+Pj4+Pj4+IFRo YW5rcyBmb3IgeW91ciByZXZpZXcgYW5kIGNvbW1lbnRzLiBJbiB0aGUgQkZDUCB1c2FnZSwgDQo+ Pj4+Pj4+Pj4+Pj4+PiB0aGUgRFRMUyBjb25uZWN0aW9uIGlzIGRlZGljYXRlZCB0byB0aGUgQkZD UCBzdHJlYW0gaXQgY29udGFpbnMuDQo+Pj4+Pj4+Pj4+Pj4+PiBBcyBJIHVuZGVyc3RhbmQgaXQs IHRoZSBjb21wbGljYXRpb25zIGFyb3VuZCBEVExTIA0KPj4+Pj4+Pj4+Pj4+Pj4gcmUtZXN0YWJs aXNoZW1lbnQgZGlzY3Vzc2VkIGluIE1NVVNJQyByZXN1bHQgZnJvbSB1c2Ugb2YgDQo+Pj4+Pj4+ Pj4+Pj4+PiBhIHNpbmdsZSBEVExTIGNvbm5lY3Rpb24gZm9yIG11bHRpcGxlIFJUUCBhbmQvb3Ig U0NUUCBzdHJlYW1zLg0KPj4+Pj4+Pj4+Pj4+Pj4gVGhvc2UgY29tcGxpY2F0aW9ucyBkbyBub3Qg ZXhpc3Qgd2l0aCB0aGUgQkZDUCB1c2FnZSwgc28gDQo+Pj4+Pj4+Pj4+Pj4+PiBJIHRoaW5rIGl0 IGlzIHN1ZmZpY2llbnQgdG8gY29udGludWUgdG8gcmVmZXJlbmNlIFJGQyANCj4+Pj4+Pj4+Pj4+ Pj4+IDU3NjMgYW5kIG5vdCB1c2UgdGhlIFNEUCBjb25uZWN0aW9uIGF0dHJpYnV0ZS4NCj4+Pj4+ Pj4+Pj4+Pj4+DQo+Pj4+Pj4+Pj4+Pj4+Pg0KPj4+Pj4+Pj4+Pj4+Pj4gICAgIA0KPj4+Pj4+Pj4+ Pj4+PiBUaGUgY29tcGxpY2F0aW9ucyBkbyBub3QgcmVzdWx0IGZyb20gdXNlIG9mIGEgc2luZ2xl IERUTFMgDQo+Pj4+Pj4+Pj4+Pj4+IGNvbm5lY3Rpb24gZm9yIG11bHRpcGxlIHN0cmVhbXMgLSBp dCBtYWlubHkgcmVzdWx0cyBmcm9tIA0KPj4+Pj4+Pj4+Pj4+PiB0aGUgdXNhZ2Ugb2YgSUNFLiBB bmQsIGFzIGZhciBhcyBJIGtub3csIElDRSBjYW4gYmUgdXNlZCANCj4+Pj4+Pj4+Pj4+Pj4gYWxz byBmb3IgQkZDUC4NCj4+Pj4+Pj4+Pj4+Pj4NCj4+Pj4+Pj4+Pj4+Pj4gQW5kLCBldmVuIHdpdGhv dXQgSUNFIHdlIGludGVuZCB0byBhZGQgdGV4dCBzYXlpbmcgdGhhdCBhIA0KPj4+Pj4+Pj4+Pj4+ PiBEVExTIGNvbm5lY3Rpb24gaXMgb25seSByZS1lc3RhYmxpc2hlZCBpZiB0aGUgdW5kZXJseWlu ZyANCj4+Pj4+Pj4+Pj4+Pj4gdHJhbnNwb3J0IGNoYW5nZXMuDQo+Pj4+Pj4+Pj4+Pj4+DQo+Pj4+ Pj4+Pj4+Pj4+IFJlZ2FyZHMsDQo+Pj4+Pj4+Pj4+Pj4+DQo+Pj4+Pj4+Pj4+Pj4+IENocmlzdGVy DQo+Pj4+Pj4+Pj4+Pj4+DQo+Pj4+Pj4+Pj4+Pj4+DQo+Pj4+Pj4+Pj4+Pj4+DQo+Pj4+Pj4+Pj4+ Pj4+DQo+Pj4+Pj4+Pj4+Pj4+DQo+Pj4+Pj4+Pj4+Pj4+ICAgICAgDQo+Pj4+Pj4+Pj4+Pj4+PiBI aSwNCj4+Pj4+Pj4+Pj4+Pj4+DQo+Pj4+Pj4+Pj4+Pj4+PiBGaXJzdCwgSSB3YW50IHRvIGFwb2xv Z2l6ZSBmb3Igbm90IHByb3ZpZGluZyBteSByZXZpZXcgDQo+Pj4+Pj4+Pj4+Pj4+PiBlYXJsaWVy Lg0KPj4+Pj4+Pj4+Pj4+Pj4NCj4+Pj4+Pj4+Pj4+Pj4+IEFzIGZhciBhcyB0aGUgQkZDUCBzcGVj aWZpY3MgYXJlIGNvbmNlcm5lZCwgSSBhbSBvayB3aXRoIA0KPj4+Pj4+Pj4+Pj4+Pj4gdGhlIGxh dGVzdCB2ZXJzaW9uIG9mIHRoZSBkcmFmdC4NCj4+Pj4+Pj4+Pj4+Pj4+DQo+Pj4+Pj4+Pj4+Pj4+ PiBIb3dldmVyLCB0aGVyZSBpcyBhbiBpc3N1ZSByZWdhcmRpbmcgdGhlIERUTFMgDQo+Pj4+Pj4+ Pj4+Pj4+PiBjb25zaWRlcmF0aW9ucyAoc2VjdGlvbiAxMC41KS4NCj4+Pj4+Pj4+Pj4+Pj4+DQo+ Pj4+Pj4+Pj4+Pj4+PiBUaGUgdGV4dCBzYXlzOg0KPj4+Pj4+Pj4+Pj4+Pj4NCj4+Pj4+Pj4+Pj4+ Pj4+IAkiT25jZSBhIERUTFMgY29ubmVjdGlvbiBoYXMgYmVlbiBlc3RhYmxpc2hlZCwgaWYgdGhl IA0KPj4+Pj4+Pj4+Pj4+Pj4gJ2FjdGl2ZS9wYXNzaXZlJw0KPj4+Pj4+Pj4+Pj4+Pj4gICAgICAJ c3RhdHVzIG9mIHRoZSBlbmRwb2ludHMgY2hhbmdlIGR1cmluZyBhIHNlc3Npb24sIGEgDQo+Pj4+ Pj4+Pj4+Pj4+PiBuZXcgRFRMUw0KPj4+Pj4+Pj4+Pj4+Pj4gICAgICAJY29ubmVjdGlvbiBNVVNU IGJlIGVzdGFibGlzaGVkLiINCj4+Pj4+Pj4+Pj4+Pj4+DQo+Pj4+Pj4+Pj4+Pj4+PiBUaGVyZSBp cyBjdXJyZW50bHkgYW4gb25nb2luZyBkaXNjdXNzaW9uIGluIE1NVVNJQyBhYm91dCANCj4+Pj4+ Pj4+Pj4+Pj4+IHdoZW4gYSBEVExTIGNvbm5lY3Rpb24gaXMgdG8gYmUgcmUtZXN0YWJsaXNoZWQu DQo+Pj4+Pj4+Pj4+Pj4+Pg0KPj4+Pj4+Pj4+Pj4+Pj4gVGhlIGRpc2N1c3Npb24gaXMgc3RpbGwg b25nb2luZywgYnV0IHRoZSBvdXRjb21lIHdpbGwgDQo+Pj4+Pj4+Pj4+Pj4+PiBtb3N0IGxpa2Vs eSBOT1QgYmUgYWxpZ25lZCB3aXRoIHRoZSB0ZXh0IGFib3ZlLg0KPj4+Pj4+Pj4+Pj4+Pj4NCj4+ Pj4+Pj4+Pj4+Pj4+IEZvciBleGFtcGxlLCB0aGVyZSBoYXMgYmVlbiBhIHN1Z2dlc3Rpb24gKGJ5 IG15c2VsZikgdG8gDQo+Pj4+Pj4+Pj4+Pj4+PiB1c2UgdGhlIFNEUCBjb25uZWN0aW9uIGF0dHJp YnV0ZSB0byBleHBsaWNpdGx5IGluZGljYXRlIA0KPj4+Pj4+Pj4+Pj4+Pj4gdGhhdCBhIG5ldyBE VExTIGNvbm5lY3Rpb24gbmVlZHMgdG8gYmUgZXN0YWJsaXNoZWQuDQo+Pj4+Pj4+Pj4+Pj4+Pg0K Pj4+Pj4+Pj4+Pj4+Pj4NCj4+Pj4+Pj4+Pj4+Pj4+IFRoZSBkcmFmdCBhbHNvIHNheXM6DQo+Pj4+ Pj4+Pj4+Pj4+Pg0KPj4+Pj4+Pj4+Pj4+Pj4gCSJJZiB0aGUgdHJhbnNwb3J0IHBhcmFtZXRlcnMg b3IgdGhlIGtleSBmaW5nZXJwcmludHMgDQo+Pj4+Pj4+Pj4+Pj4+PiBjaGFuZ2UsIHRoZQ0KPj4+ Pj4+Pj4+Pj4+Pj4gICAgICAJZW5kcG9pbnRzIE1VU1QgZXN0YWJsaXNoIGEgbmV3IERUTFMgY29u bmVjdGlvbi4iDQo+Pj4+Pj4+Pj4+Pj4+Pg0KPj4+Pj4+Pj4+Pj4+Pj4gVGhpcyBpcyByZWxhdGVk IHRvIHRoZSBlYXJsaWVyIGlzc3VlLiBUaGVyZSBpcyB0aGUgDQo+Pj4+Pj4+Pj4+Pj4+PiBkaXNj dXNzaW9uIGFib3V0IElDRSAidmlydHVhbCBjb25uZWN0aW9ucyIsIGFuZCB0aGF0IGEgDQo+Pj4+ Pj4+Pj4+Pj4+PiBzaW5nbGUgRFRMUyBjb25uZWN0aW9uIHdvdWxkIGFwcGx5IHRvIGFsbCBJQ0Ug Y2FuZGlkYXRlcyANCj4+Pj4+Pj4+Pj4+Pj4+IGFzc29jaWF0ZWQgd2l0aCBhbg0KPj4+Pj4+Pj4+ Pj4+Pj4gbS0gbGluZS4gU28sIGV2ZW4gaWYgYSBjYW5kaWRhdGUgY2hhbmdlcyAocmVhZDogdHJh bnNwb3J0IA0KPj4+Pj4+Pj4+Pj4+Pj4gcGFyYW1ldGVyIGNoYW5nZXMpLCBpdCB3b3VsZCBub3Qg YXV0b21hdGljYWxseSB0cmlnZ2VyIGEgDQo+Pj4+Pj4+Pj4+Pj4+PiBuZXcgRFRMUyBjb25uZWN0 aW9uLg0KPj4+Pj4+Pj4+Pj4+Pj4NCj4+Pj4+Pj4+Pj4+Pj4+DQo+Pj4+Pj4+Pj4+Pj4+PiBUaGUg aXNzdWVzIGFib3ZlIGFyZSBhbHNvIGhvbGRpbmcgdXAgdGhlIFNDVFAtU0RQIGRyYWZ0LCANCj4+ Pj4+Pj4+Pj4+Pj4+IHNvIGl0IGRvZXNuJ3Qgb25seSBhZmZlY3QgQkZDUGJpcyA6KQ0KPj4+Pj4+ Pj4+Pj4+Pj4NCj4+Pj4+Pj4+Pj4+Pj4+DQo+Pj4+Pj4+Pj4+Pj4+PiBSZWdhcmRzLA0KPj4+Pj4+ Pj4+Pj4+Pj4NCj4+Pj4+Pj4+Pj4+Pj4+IENocmlzdGVyDQo+Pj4+Pj4+Pj4+Pj4+Pg0KPj4+Pj4+ Pj4+Pj4+Pj4NCj4+Pj4+Pj4+Pj4+Pj4+IC0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQo+Pj4+ Pj4+Pj4+Pj4+PiBGcm9tOiBBbGlzc2EgQ29vcGVyIFttYWlsdG86YWxpc3NhQGNvb3BlcncuaW5d DQo+Pj4+Pj4+Pj4+Pj4+PiBTZW50OiA4LiBodWh0aWt1dXRhIDIwMTUgMzowNw0KPj4+Pj4+Pj4+ Pj4+Pj4gVG86IENoYXJsZXMgRWNrZWwgKGVja2VsY3UpDQo+Pj4+Pj4+Pj4+Pj4+PiBDYzogR29u emFsbyBDYW1hcmlsbG87IFRvbSBLcmlzdGVuc2VuICh0b21rcmlzdCk7IA0KPj4+Pj4+Pj4+Pj4+ Pj4gZHJhZnQtaWV0Zi1iZmNwYmlzLXJmYzQ1ODJiaXNAdG9vbHMuaWV0Zi5vcmc7IEJlbiANCj4+ Pj4+Pj4+Pj4+Pj4+IENhbXBiZWxsOyBDaHJpc3RlciBIb2xtYmVyZw0KPj4+Pj4+Pj4+Pj4+Pj4g U3ViamVjdDogUmU6IGRyYWZ0LWlldGYtYmZjcGJpcy1yZmM0NTgzYmlzDQo+Pj4+Pj4+Pj4+Pj4+ Pg0KPj4+Pj4+Pj4+Pj4+Pj4gQWRkaW5nIENocmlzdGVyIHRvIHRoaXMgdGhyZWFkLg0KPj4+Pj4+ Pj4+Pj4+Pj4NCj4+Pj4+Pj4+Pj4+Pj4+IE9uIEFwciA3LCAyMDE1LCBhdCAxMjo0NCBQTSwgQ2hh cmxlcyBFY2tlbCAoZWNrZWxjdSkgDQo+Pj4+Pj4+Pj4+Pj4+PiA8ZWNrZWxjdUBjaXNjby5jb20+ DQo+Pj4+Pj4+Pj4+Pj4+PiB3cm90ZToNCj4+Pj4+Pj4+Pj4+Pj4+DQo+Pj4+Pj4+Pj4+Pj4+Pg0K Pj4+Pj4+Pj4+Pj4+Pj4NCj4+Pj4+Pj4+Pj4+Pj4+ICAgICANCj4+Pj4+Pj4+Pj4+Pj4+PiBDaHJp c3RlciAoY2PigJlkKSBhbmQgSSBkaXNjdXNzZWQgc29tZSBvZiB0aGUgY2hhbmdlcyANCj4+Pj4+ Pj4+Pj4+Pj4+PiBvZmZsaXN0IGluIERhbGxhcywgYW5kIGhlIGlzIHRvIGNvbWUgYmFjayB0byB0 aGUgbGlzdCANCj4+Pj4+Pj4+Pj4+Pj4+PiB3aXRoIGNvbW1lbnRzIGFmdGVyIERhbGxhcw0KPj4+ Pj4+Pj4+Pj4+Pj4+IC0gd2hpY2ggaXMgbm93IDopDQo+Pj4+Pj4+Pj4+Pj4+Pj4NCj4+Pj4+Pj4+ Pj4+Pj4+PiBDaGVlcnMsDQo+Pj4+Pj4+Pj4+Pj4+Pj4gQ2hhcmxlcw0KPj4+Pj4+Pj4+Pj4+Pj4+ DQo+Pj4+Pj4+Pj4+Pj4+Pj4gT24gNC83LzE1LCAxMDoyNiBBTSwgIkFsaXNzYSBDb29wZXIiPGFs aXNzYUBjb29wZXJ3LmluPg0KPj4+Pj4+Pj4+Pj4+Pj4+IHdyb3RlOg0KPj4+Pj4+Pj4+Pj4+Pj4+ DQo+Pj4+Pj4+Pj4+Pj4+Pj4NCj4+Pj4+Pj4+Pj4+Pj4+Pg0KPj4+Pj4+Pj4+Pj4+Pj4+ICAgIA0K Pj4+Pj4+Pj4+Pj4+Pj4+PiBDaGVja2luZyBpbiBvbiB0aGlzIOKAlCBoYXMgQ2hyaXN0ZXIgYmVl biBwcm9tcHRlZCB0byANCj4+Pj4+Pj4+Pj4+Pj4+Pj4gcmV2aWV3IHRoZSBsYXRlc3QgcmV2IG9m IGRyYWZ0LWlldGYtYmZjcGJpcy1yZmM0NTgzYmlzPw0KPj4+Pj4+Pj4+Pj4+Pj4+Pg0KPj4+Pj4+ Pj4+Pj4+Pj4+PiBUaGFua3MsDQo+Pj4+Pj4+Pj4+Pj4+Pj4+IEFsaXNzYQ0KPj4+Pj4+Pj4+Pj4+ Pj4+Pg0KPj4+Pj4+Pj4+Pj4+Pj4+PiBPbiBGZWIgMjUsIDIwMTUsIGF0IDk6MTQgQU0sIENoYXJs ZXMgRWNrZWwgKGVja2VsY3UpIA0KPj4+Pj4+Pj4+Pj4+Pj4+PiA8ZWNrZWxjdUBjaXNjby5jb20+ DQo+Pj4+Pj4+Pj4+Pj4+Pj4+IHdyb3RlOg0KPj4+Pj4+Pj4+Pj4+Pj4+Pg0KPj4+Pj4+Pj4+Pj4+ Pj4+Pg0KPj4+Pj4+Pj4+Pj4+Pj4+Pg0KPj4+Pj4+Pj4+Pj4+Pj4+PiAgIA0KPj4+Pj4+Pj4+Pj4+ Pj4+Pj4gTW9zdCBvZiB0aGUgY2hhbmdlcyBJIHRoaXMgcmVjZW50IHVwZGF0ZSB0byByZmM0NTgz YmlzIA0KPj4+Pj4+Pj4+Pj4+Pj4+Pj4gd2VyZSBpbnNwaXJlZCBieSBjb21tZW50cyBhbmQgc3Vn Z2VzdGVkIHRleHQgcHJvdmlkZWQgDQo+Pj4+Pj4+Pj4+Pj4+Pj4+PiBieSBDaHJpc3Rlci4NCj4+ Pj4+Pj4+Pj4+Pj4+Pj4+IEhlIGlzIGluIHRoZSBwcm9jZXNzIG9mIHJldmlld2luZy4gSWYgYWxs IGdvZXMgd2VsbCANCj4+Pj4+Pj4+Pj4+Pj4+Pj4+IHdpdGggdGhhdCwgd2UgYXJlIHJlYWR5IHRv IHByb2NlZWQgd2l0aCBwcm90byB3cml0ZXVwIA0KPj4+Pj4+Pj4+Pj4+Pj4+Pj4gKE1hcnkpIGFu ZCBBRCByZXZpZXcuDQo+Pj4+Pj4+Pj4+Pj4+Pj4+Pg0KPj4+Pj4+Pj4+Pj4+Pj4+Pj4gQ2hlZXJz LA0KPj4+Pj4+Pj4+Pj4+Pj4+Pj4gQ2hhcmxlcw0KPj4+Pj4+Pj4+Pj4+Pj4+Pj4NCj4+Pj4+Pj4+ Pj4+Pj4+Pj4+IE9uIDIvMjUvMTUsIDc6MDEgQU0sICJBbGlzc2EgDQo+Pj4+Pj4+Pj4+Pj4+Pj4+ PiBDb29wZXIiPGFsaXNzYUBjb29wZXJ3LmluPg0KPj4+Pj4+Pj4+Pj4+Pj4+Pj4gd3JvdGU6DQo+ Pj4+Pj4+Pj4+Pj4+Pj4+Pg0KPj4+Pj4+Pj4+Pj4+Pj4+Pj4NCj4+Pj4+Pj4+Pj4+Pj4+Pj4+DQo+ Pj4+Pj4+Pj4+Pj4+Pj4+PiAgDQo+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4gcmZjNDU4MyBoYXMgbm90IGhh ZCBhbiBBRCByZXZpZXcgeWV0LiBSaWNoYXJkIGNhbiANCj4+Pj4+Pj4+Pj4+Pj4+Pj4+PiBob3Bl ZnVsbHkgdGFrZSBjYXJlIG9mIHRoYXQgd2hpbGUgScK5bSBvbiBsZWF2ZSANCj4+Pj4+Pj4+Pj4+ Pj4+Pj4+PiAoc3RhcnRpbmcgdG9kYXksIGFjdHVhbGx5KS4NCj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pg0K Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+IE9uIEZlYiAyNSwgMjAxNSwgYXQgMjo1NiBBTSwgR29uemFsbyBD YW1hcmlsbG8NCj4+Pj4+Pj4+Pj4+Pj4+Pj4+PiA8Z29uemFsby5jYW1hcmlsbG9AZXJpY3Nzb24u Y29tPiAgICB3cm90ZToNCj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pg0KPj4+Pj4+Pj4+Pj4+Pj4+Pj4+DQo+ Pj4+Pj4+Pj4+Pj4+Pj4+Pj4NCj4+Pj4+Pj4+Pj4+Pj4+Pj4+PiANCj4+Pj4+Pj4+Pj4+Pj4+Pj4+ Pj4gSGkgQWxpc3NhLA0KPj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pg0KPj4+Pj4+Pj4+Pj4+Pj4+Pj4+PiBJ IGhhdmUgbm90ZWQgdGhhdCB3aGlsZSByZmM0NTgyYmlzIGluIG9uIHRoZSBhZ2VuZGEgDQo+Pj4+ Pj4+Pj4+Pj4+Pj4+Pj4+IG9mIHRoZSBNYXJjaCA1dGggdGVsZWNoYXQgKHRoYW5rcyBmb3IgaGFu ZGxpbmcgDQo+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+IHRoYXQhKSwgcmZjNDU4M2JpcyBpc24ndC4gVG9t IHJldmlzZWQgcmZjNDU4M2JpcyBvbiANCj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4gRmVicnVhcnkgMjB0 aC4gU2hvdWxkIHJmYzQ1ODNiaXMgYmUgb24gdGhlIGFnZW5kYSBvZiANCj4+Pj4+Pj4+Pj4+Pj4+ Pj4+Pj4gdGhlIHRlbGVjaGF0IGFzIHdlbGwgb3IgdGhlcmUgaXMgc3RpbGwgc29tZXRoaW5nIA0K Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+PiBsZWZ0IGZvciBUb20gdG8gdGFrZSBjYXJlIG9mPw0KPj4+Pj4+ Pj4+Pj4+Pj4+Pj4+Pg0KPj4+Pj4+Pj4+Pj4+Pj4+Pj4+PiBUaGFua3MsDQo+Pj4+Pj4+Pj4+Pj4+ Pj4+Pj4+DQo+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+IEdvbnphbG8NCj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4N Cj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4gT24gMTgvMDIvMjAxNSA5OjI4IFBNLCBBbGlzc2EgQ29vcGVy IHdyb3RlOg0KPj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pg0KPj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pg0KPj4+Pj4+ Pj4+Pj4+Pj4+Pj4+Pg0KPj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4gUGluZ2luZyBvbiB0aGlzLg0KPj4+ Pj4+Pj4+Pj4+Pj4+Pj4+Pj4NCj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+IE1hcmNoIDUgd2lsbCBsaWtl bHkgYmUgbXkgbGFzdCB0ZWxlY2hhdCBiZWZvcmUgDQo+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+PiBnb2lu ZyBvbiBsZWF2ZSwgc28gIGl0IHdvdWxkIGJlIGdyZWF0IHRvIGdldCB0aGlzIA0KPj4+Pj4+Pj4+ Pj4+Pj4+Pj4+Pj4gc2NoZWR1bGVkIG9uIHRoYXQgb25lLiBUbyBkbyB0aGF0LCAgdGhlIHJldiBu ZWVkcyANCj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+IHRvIGJlIHBvc3RlZCB0b2RheS4NCj4+Pj4+Pj4+ Pj4+Pj4+Pj4+Pj4+IFRoZSB1cGRhdGVzIGFyZSBwcmV0dHkgbWluaW1hbCAgYW5kIGFyZSBhbGwg DQo+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+PiBiYXNpY2FsbHkgd3JpdHRlbiB1cCBpbiBDaGFybGVzwrkg cmVzcG9uc2UgdG8gbXkgQUQgcmV2aWV3Lg0KPj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4NCj4+Pj4+Pj4+ Pj4+Pj4+Pj4+Pj4+IEFsaXNzYQ0KPj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4NCj4+Pj4+Pj4+Pj4+Pj4+ Pj4+Pj4+IE9uIEZlYiAxNSwgMjAxNSwgYXQgOToxMyBBTSwgR29uemFsbyBDYW1hcmlsbG8gDQo+ Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+PiA8Z29uemFsby5jYW1hcmlsbG9AZXJpY3Nzb24uY29tIA0KPj4+ Pj4+Pj4+Pj4+Pj4+Pj4+Pj4gPG1haWx0bzpnb256YWxvLmNhbWFyaWxsb0Blcmljc3Nvbi5jb20+ Pg0KPj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4gd3JvdGU6DQo+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pg0KPj4+ Pj4+Pj4+Pj4+Pj4+Pj4+Pj4NCj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+DQo+Pj4+Pj4+Pj4+Pj4+Pj4+ Pj4+Pg0KPj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+IEkgaGF2ZSB0YWxrZWQgb2ZmbGluZSB3aXRoIHRo ZSBvdGhlciBhdXRob3JzIGFuZCANCj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+PiBUb20gaXMgaG9sZGlu ZyB0aGUgcGVuLiBUb20sIGRvIHlvdSB0aGluayB5b3UgY2FuIA0KPj4+Pj4+Pj4+Pj4+Pj4+Pj4+ Pj4+IG1lZXQgdGhlIHRpbWUgZnJhbWUgYmVsb3c/DQo+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4NCj4+ Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+PiBDaGVlcnMsDQo+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4NCj4+Pj4+ Pj4+Pj4+Pj4+Pj4+Pj4+PiBHb256YWxvDQo+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4NCj4+Pj4+Pj4+ Pj4+Pj4+Pj4+Pj4+PiBTZW50IGZyb20gbXkgbW9iaWxlDQo+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4N Cj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pg0KPj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+DQo+Pj4+Pj4+Pj4+ Pj4+Pj4+Pj4+Pj4gLS0tLSBBbGlzc2EgQ29vcGVyIHdyb3RlIC0tLS0NCj4+Pj4+Pj4+Pj4+Pj4+ Pj4+Pj4+Pg0KPj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+IEp1c3Qgd2FudGVkIHRvIHNlZSBpZiB0aGlz IHJldiBtaWdodCBnZXQgZG9uZSBpbiANCj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+PiB0aGUgbmV4dCBj b3VwbGUgIG9mIGRheXMuIElmIHNvLCB3ZSBjb3VsZCBnZXQgaXQgDQo+Pj4+Pj4+Pj4+Pj4+Pj4+ Pj4+Pj4gb24gdGhlIG5leHQgdGVsZWNoYXQgYWdlbmRhIChNYXJjaCA1KS4NCj4+Pj4+Pj4+Pj4+ Pj4+Pj4+Pj4+Pg0KPj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+IEFsaXNzYQ0KPj4+Pj4+Pj4+Pj4+Pj4+ Pj4+Pj4+DQo+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4gQmVnaW4gZm9yd2FyZGVkIG1lc3NhZ2U6DQo+ Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4NCj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pg0KPj4+Pj4+Pj4+Pj4+ Pj4+Pj4+Pj4+DQo+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4NCj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4g KkZyb206ICpBbGlzc2EgQ29vcGVyPGFsaXNzYUBjb29wZXJ3LmluIA0KPj4+Pj4+Pj4+Pj4+Pj4+ Pj4+Pj4+PiA8bWFpbHRvOmFsaXNzYUBjb29wZXJ3LmluPj4NCj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+ Pj4gKlN1YmplY3Q6ICoqUmU6IFtiZmNwYmlzXSBBRCBldmFsdWF0aW9uOg0KPj4+Pj4+Pj4+Pj4+ Pj4+Pj4+Pj4+PiBkcmFmdC1pZXRmLWJmY3BiaXMtcmZjNDU4MmJpcy0xMioNCj4+Pj4+Pj4+Pj4+ Pj4+Pj4+Pj4+Pj4gKkRhdGU6ICpGZWJydWFyeSA5LCAyMDE1IGF0IDM6NTg6NTIgUE0gUFNUDQo+ Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+ICpUbzogKiJDaGFybGVzIEVja2VsIChlY2tlbGN1KSI8ZWNr ZWxjdUBjaXNjby5jb20gDQo+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+IDxtYWlsdG86ZWNrZWxjdUBj aXNjby5jb20+Pg0KPj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+PiAqQ2M6ICoiYmZjcGJpc0BpZXRmLm9y ZzxtYWlsdG86YmZjcGJpc0BpZXRmLm9yZz4iDQo+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+IDxiZmNw YmlzQGlldGYub3JnIDxtYWlsdG86YmZjcGJpc0BpZXRmLm9yZz4+DQo+Pj4+Pj4+Pj4+Pj4+Pj4+ Pj4+Pj4+DQo+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+IEhpIENoYXJsZXMsDQo+Pj4+Pj4+Pj4+Pj4+ Pj4+Pj4+Pj4+DQo+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+IFRoYW5rcywgc29tZSByZXNwb25zZXMg aW5saW5lLg0KPj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pg0KPj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+PiBP biBGZWIgNCwgMjAxNSwgYXQgMTA6NDAgQU0sIENoYXJsZXMgRWNrZWwgKGVja2VsY3UpDQo+Pj4+ Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+IDxlY2tlbGN1QGNpc2NvLmNvbTxtYWlsdG86ZWNrZWxjdUBjaXNj by5jb20+PiAgICB3cm90ZToNCj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4NCj4+Pj4+Pj4+Pj4+Pj4+ Pj4+Pj4+Pj4NCj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4NCj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4N Cj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+IEhJIEFsaXNzYSwNCj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+ Pj4+DQo+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+PiBUaGFuayB5b3UgZm9yIHRoZSByZXZpZXcuIFBs ZWFzZSBzZWUgbXkgdGhvdWdodHMgDQo+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+PiBvbiB5b3VyIGNv bW1lbnRzIGFuZCBxdWVzdGlvbnMgaW5saW5lLg0KPj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4NCj4+ Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+IEZyb206IEFsaXNzYSBDb29wZXI8YWxpc3NhQGNvb3Blcncu aW4gDQo+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+PiA8bWFpbHRvOmFsaXNzYUBjb29wZXJ3LmluPj4N Cj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+IERhdGU6IFRodXJzZGF5LCBKYW51YXJ5IDI5LCAyMDE1 IGF0IDEwOjE5IFBNDQo+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+PiBUbzogImJmY3BiaXNAaWV0Zi5v cmc8bWFpbHRvOmJmY3BiaXNAaWV0Zi5vcmc+Ig0KPj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4gPGJm Y3BiaXNAaWV0Zi5vcmc8bWFpbHRvOmJmY3BiaXNAaWV0Zi5vcmc+Pg0KPj4+Pj4+Pj4+Pj4+Pj4+ Pj4+Pj4+Pj4gU3ViamVjdDogW2JmY3BiaXNdIEFEIGV2YWx1YXRpb246DQo+Pj4+Pj4+Pj4+Pj4+ Pj4+Pj4+Pj4+PiBkcmFmdC1pZXRmLWJmY3BiaXMtcmZjNDU4MmJpcy0xMg0KPj4+Pj4+Pj4+Pj4+ Pj4+Pj4+Pj4+Pj4NCj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+DQo+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+ Pj4+Pg0KPj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4NCj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+PiBJ IGhhdmUgcmV2aWV3ZWQgdGhpcyBkcmFmdCBpbiBwcmVwYXJhdGlvbiBmb3IgSUVURiBMQy4NCj4+ Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+PiBPdmVyYWxsIHRoZSBkb2N1bWVudCBhcHBlYXJzIGluIGdv b2Qgc2hhcGUuIEkgDQo+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4gaGF2ZSBhIGZldyBxdWVzdGlv bnMgYW5kIGNvbW1lbnRzIEnCuWQgbGlrZSB0byANCj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+PiBk aXNjdXNzIGJlZm9yZSBpc3N1aW5nIHRoZSBJRVRGIGxhc3QgY2FsbC4gScK5dmUgDQo+Pj4+Pj4+ Pj4+Pj4+Pj4+Pj4+Pj4+Pj4gYWxzbyBpbmNsdWRlZCBzb21lIGVkaXRvcmlhbCBuaXRzIHRoYXQg c2hvdWxkIA0KPj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+IGJlIGFkZHJlc3NlZCB0b2dldGhlciB3 aXRoIGFueSBsYXN0IGNhbGwgY29tbWVudHMuDQo+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4NCj4+ Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+PiBDb21tZW50cyBhbmQgcXVlc3Rpb25zOg0KPj4+Pj4+Pj4+ Pj4+Pj4+Pj4+Pj4+Pj4+DQo+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4gPSBTZWN0aW9uIDUuMSA9 ICJJZiBhbiBlbmRwb2ludCByZWNlaXZlcyBhIA0KPj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+IG1l c3NhZ2Ugd2l0aCBhbiB1bnN1cHBvcnRlZCB2ZXJzaW9uIGZpZWxkIA0KPj4+Pj4+Pj4+Pj4+Pj4+ Pj4+Pj4+Pj4+IHZhbHVlLCB0aGUgcmVjZWl2aW5nIHNlcnZlciBNVVNUIHNlbmQgYW4gRXJyb3Ig DQo+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4gbWVzc2FnZSB3aXRoIHBhcmFtZXRlciB2YWx1ZSAx MiAoVW5zdXBwb3J0ZWQNCj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+PiBWZXJzaW9uKSB0byBpbmRp Y2F0ZSB0aGlzLsKyDQo+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4NCj4+Pj4+Pj4+Pj4+Pj4+Pj4+ Pj4+Pj4+PiBUaGlzIHNlZW1zIGEgbGl0dGxlIG1pc2xlYWRpbmcgc2luY2UgUkZDIDQ1ODIgDQo+ Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4gZGlkbsK5dCBzcGVjaWZ5IHdoYXQgdG8gZG8gdXBvbiBy ZWNlaXB0IG9mIGEgDQo+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4gbWVzc2FnZSB3aXRoIGEgdmVy c2lvbiBvdGhlciB0aGFuIDEuDQo+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4gSW1wbGVtZW50YXRp b25zIHRoYXQgZG8gbm90IGdldCB1cGdyYWRlZCB0byBiZSANCj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+ Pj4+PiBjb21wbGlhbnQgd2l0aCAgNDU4MmJpcyAod2hpY2ggY291bGQgY2VydGFpbmx5IA0KPj4+ Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+IGFjY291bnQgZm9yIHNvbWUgb2YgdGhvc2UgdGhhdCAgd2ls bCBub3QgDQo+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4gc3VwcG9ydCB2ZXJzaW9uIDIpIHdpbGwg dGhlcmVmb3JlIG5ldmVyIHNlbmQgDQo+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4gdGhlICBlcnJv ciBzcGVjaWZpZWQgaGVyZS4NCj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+PiBUaGlzIHNlZW1zIGxp a2UgaXQgc2hvdWxkIGF0IGxlYXN0IGJlICBub3RlZCANCj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+ PiBnaXZlbiB0aGUgTVVTVC1sZXZlbCByZXF1aXJlbWVudC4gVGhlIHNhbWUgDQo+Pj4+Pj4+Pj4+ Pj4+Pj4+Pj4+Pj4+Pj4gYXBwbGllcyBpbiBTZWN0aW9uIDEzLjcuDQo+Pj4+Pj4+Pj4+Pj4+Pj4+ Pj4+Pj4+Pj4NCj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pg0KPj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+ Pj4+DQo+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+PiBHb29kIHBvaW50LiBJIGJlbGlldmUgd2UgbWFk ZSB0aGlzIGEgTVVTVCANCj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+IGJlY2F1c2Ugd2Ugd2VyZSB0 aGlua2luZyBpbiB0ZXJtcyBvZiANCj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+IGltcGxlbWVudGF0 aW9ucyBjb21wbGlhbnQgd2l0aCB0aGlzIGJpcyB2ZXJzaW9uLg0KPj4+Pj4+Pj4+Pj4+Pj4+Pj4+ Pj4+Pj4gQWRkaW5nDQo+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+PiB5b3VyIHN1Z2dlc3RlZCBub3Rl IGFib3V0IHJmYyA0NTgyIA0KPj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4gaW1wbGVtZW50YXRpb25z IGhlcmUgYW5kIGluICBzZWN0aW9uIDEzLjcgc2VlbXMgdXNlZnVsIHRvIG1lLg0KPj4+Pj4+Pj4+ Pj4+Pj4+Pj4+Pj4+Pj4NCj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+DQo+Pj4+Pj4+Pj4+Pj4+Pj4+ Pj4+Pj4+Pg0KPj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+PiBPaw0KPj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+ Pg0KPj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pg0KPj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pg0KPj4+Pj4+ Pj4+Pj4+Pj4+Pj4+Pj4+Pg0KPj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4NCj4+Pj4+Pj4+Pj4+Pj4+ Pj4+Pj4+Pj4+DQo+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4gPSBTZWN0aW9uIDcgPQ0KPj4+Pj4+ Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+ICJCRkNQIGVudGl0aWVzIE1VU1Qgc3VwcG9ydCwgYXQgYSBtaW5p bXVtLCB0aGUgDQo+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4gVExTX1JTQV9XSVRIX0FFU18xMjhf Q0JDX1NIQSBjaXBoZXJzdWl0ZSBbNl0uwrINCj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pg0KPj4+ Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+IEkgcmVhbGl6ZSB0aGlzIHJlcXVpcmVtZW50IGNvbWVzIGZy b20gUkZDIDQ1ODIsIA0KPj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+IGJ1dCBJwrlkIGxpa2UgdG8g dW5kZXJzdGFuZCB3aHkgaXQgaGFzIG5vdCBiZWVuIA0KPj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+ IHVwZGF0ZWQgdG8gYmUgY29uc2lzdGVudCB3aXRoIG1vcmUgY3VycmVudCANCj4+Pj4+Pj4+Pj4+ Pj4+Pj4+Pj4+Pj4+PiBndWlkYW5jZSBvbiBjaXBoZXIgc3VpdGUgc2VsZWN0aW9uIChlLmcuLA0K Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+DQo+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4gaHR0cHM6 Ly90b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0LWlldGYtdXRhLXRscy0NCj4+Pj4+Pj4+Pj4+Pj4+ Pj4+Pj4+Pj4+PiBiYw0KPj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+IHANCj4+Pj4+Pj4+Pj4+Pj4+ Pj4+Pj4+Pj4+PiAtDQo+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4gMA0KPj4+Pj4+Pj4+Pj4+Pj4+ Pj4+Pj4+Pj4+IDgNCj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+PiAjDQo+Pj4+Pj4+Pj4+Pj4+Pj4+ Pj4+Pj4+Pj4gcw0KPj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+IGUNCj4+Pj4+Pj4+Pj4+Pj4+Pj4+ Pj4+Pj4+PiBjDQo+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4gdGlvbg0KPj4+Pj4+Pj4+Pj4+Pj4+ Pj4+Pj4+Pj4+IC00KQ0KPj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+IC4NCj4+Pj4+Pj4+Pj4+Pj4+ Pj4+Pj4+Pj4+Pg0KPj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+DQo+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+ Pj4+Pj4NCj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+IEhvdyBhYm91dCB3ZSBrZWVwIHRoaXMgbWlu aW11bSByZXF1aXJlbWVudCwgYW5kIA0KPj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4gYWRkIGEgcmVm ZXJlbmNlIHRvIGRyYWZ0LWlldGYtdXRhLXRscy1iY3AgYWxvbmcgDQo+Pj4+Pj4+Pj4+Pj4+Pj4+ Pj4+Pj4+PiB3aXRoIGEgcmVjb21tZW5kYXRpb24gdG8gYWRoZXJlIHRvIHRoZSBiZXN0IA0KPj4+ Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4gcHJhY3RpY2VzIGl0IG91dGxpbmVzIGluIHNlY3Rpb24gND8N Cj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+DQo+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pg0KPj4+Pj4+ Pj4+Pj4+Pj4+Pj4+Pj4+Pj4NCj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4gSSB0aGluayBNVVNUIHN1 cHBvcnQgVExTX1JTQV9XSVRIX0FFU18xMjhfQ0JDX1NIQSANCj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+ Pj4gZm9yIGJhY2t3YXJkcyBjb21wYXRpYmlsaXR5IGFuZCBTSE9VTEQgc3VwcG9ydCANCj4+Pj4+ Pj4+Pj4+Pj4+Pj4+Pj4+Pj4gdGhlIG9uZXMgbGlzdGVkIGluIHRoZSBVVEEgZHJhZnRzIHdvdWxk IGJlIG9rLg0KPj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pg0KPj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pg0K Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pg0KPj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pg0KPj4+Pj4+Pj4+ Pj4+Pj4+Pj4+Pj4+Pj4NCj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+DQo+Pj4+Pj4+Pj4+Pj4+Pj4+ Pj4+Pj4+Pj4gPSBTZWN0aW9ucyA4LCA4LjEsIDguMiA9IEl0IHNlZW1zIGxpa2UgdGhlIA0KPj4+ Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+IHRyYW5zYWN0aW9uIElEIHJlcXVpcmVtZW50cyByZWdhcmRp bmcgDQo+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4gbm9uLXJldXNlL21vbm90b25pY2FsbHkgaW5j cmVhc2luZyBJRHMgYXJlIA0KPj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+IHJlLXN0YXRlZCBtdWx0 aXBsZSB0aW1lcyBhY3Jvc3MgdGhlc2UgdGhyZWUgDQo+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4g c2VjdGlvbnMsIGluIHNsaWdodGx5IGRpZmZlcmVudCB3YXlzLCB0byB0aGUgDQo+Pj4+Pj4+Pj4+ Pj4+Pj4+Pj4+Pj4+Pj4gcG9pbnQgd2hlcmUgaXTCuXMgbm90IGNsZWFyIGV4YWN0bHkgd2hhdCB0 aGV5IGFyZS4NCj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+PiBJdCBzZWVtcyBsaWtlIHRoZXkgYXJl Og0KPj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+DQo+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4gKDEp IFJlbGlhYmxlIHRyYW5zcG9ydCwgc2VydmVyLWluaXRpYXRlZCB0cmFuc2FjdGlvbjoNCj4+Pj4+ Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+PiBJRCBpcw0KPj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+IDANCj4+ Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+PiAoMikgVW5yZWxpYWJsZSB0cmFuc3BvcnQsIHNlcnZlci1p bml0aWF0ZWQNCj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+PiB0cmFuc2FjdGlvbjoNCj4+Pj4+Pj4+ Pj4+Pj4+Pj4+Pj4+Pj4+PiBJRCBNVVNUIGJlIG1vbm90b25pY2FsbHkgaW5jcmVhc2luZyAoZXhj ZXB0IGZvcg0KPj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+IHdyYXAtYXJvdW5kKQ0KPj4+Pj4+Pj4+ Pj4+Pj4+Pj4+Pj4+Pj4+ICgzKSBSZWxpYWJsZSB0cmFuc3BvcnQsIGNsaWVudC1pbml0aWF0ZWQg dHJhbnNhY3Rpb246DQo+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4gSUQgTVVTVCBOT1QgYmUgMCBh bmQgTVVTVCBOT1QgYmUgcmV1c2VkIGluIA0KPj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+IGFub3Ro ZXIgbWVzc2FnZSBmcm9tIHRoZSBjbGllbnQgdW50aWwgYSANCj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+ Pj4+PiByZXNwb25zZQ0KPj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+DQo+Pj4+Pj4+Pj4+Pj4+Pj4+ Pj4+Pj4+PiA+ZnJvbSB0aGUgc2VydmVyIGlzIHJlY2VpdmVkIGZvciB0aGUgDQo+Pj4+Pj4+Pj4+ Pj4+Pj4+Pj4+Pj4+PiA+dHJhbnNhY3Rpb24sDQo+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pg0KPj4+ Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+IGJ1dCBuZWVkIG5vdCBiZSBtb25vdG9uaWNhbGx5IGluY3Jl YXNpbmcgKGUuZy4sIA0KPj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+IGEgbG93ZXIsIHJlY2VudGx5 IHVzZWQgSUQgY291bGQgYmUgcmUtdXNlZCBvbmNlIA0KPj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+ IGEgcmVzcG9uc2UgaXMNCj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+PiByZWNlaXZlZCkNCj4+Pj4+ Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+PiAoNCkgVW5yZWxpYWJsZSB0cmFuc3BvcnQsIGNsaWVudC1pbml0 aWF0ZWQNCj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+PiB0cmFuc2FjdGlvbjoNCj4+Pj4+Pj4+Pj4+ Pj4+Pj4+Pj4+Pj4+PiBJRCBNVVNUIGJlIG1vbm90b25pY2FsbHkgaW5jcmVhc2luZyAoZXhjZXB0 IGZvcg0KPj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+IHdyYXAtYXJvdW5kKQ0KPj4+Pj4+Pj4+Pj4+ Pj4+Pj4+Pj4+Pj4+DQo+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4gSXMgKDMpIHRoZSBjb3JyZWN0 IGludGVycHJldGF0aW9uIG9mIHRoZSB0ZXh0IGluIDguMT8NCj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+ Pj4+PiBJZiBzbywgd2h5IG5vdCBqdXN0IHJlcXVpcmUgSURzIGluIGFsbCANCj4+Pj4+Pj4+Pj4+ Pj4+Pj4+Pj4+Pj4+PiBjbGllbnQtaW5pdGlhdGVkIHRyYW5zYWN0aW9ucyB0byBiZSANCj4+Pj4+ Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+PiBtb25vdG9uaWNhbGx5IGluY3JlYXNpbmc/DQo+Pj4+Pj4+Pj4+ Pj4+Pj4+Pj4+Pj4+Pj4NCj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pg0KPj4+Pj4+Pj4+Pj4+Pj4+ Pj4+Pj4+Pj4+DQo+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+PiBBZ3JlZSB3ZSBjYW4gYW5kIHNob3Vs ZCBzaW1wbGlmeSB0aGlzLiBTZWN0aW9ucw0KPj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4gOC4xIGFu ZA0KPj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4gOC4yIGNvdmVyIHRoZSBjbGllbnQgYmVoYXZpb3Ig YW5kIHNlcnZlciANCj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+IGJlaGF2aW9yIGluIGRldGFpbC4g QXMgc3VjaCwgdGhlIHRyYW5zYWN0aW9uIElEIA0KPj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4gcmVs YXRlZCBpbmZvcm1hdGlvbiBhdCB0aGUgc3RhcnQgb2YgU2VjdGlvbiA4IGlzIHN1cGVyZmx1b3Vz Lg0KPj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4gSSByZWNvbW1lbmQgcmVkdWNpbmcgdGhlIHRleHQg aW4gU2VjdGlvbiA4IHRvIA0KPj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4gdGhlDQo+Pj4+Pj4+Pj4+ Pj4+Pj4+Pj4+Pj4+PiBmb2xsb3c6DQo+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pg0KPj4+Pj4+Pj4+ Pj4+Pj4+Pj4+Pj4+Pj4gOC4gUHJvdG9jb2wgVHJhbnNhY3Rpb25zDQo+Pj4+Pj4+Pj4+Pj4+Pj4+ Pj4+Pj4+Pg0KPj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4gSW4gQkZDUCwgdGhlcmUgYXJlIHR3byB0 eXBlcyBvZiB0cmFuc2FjdGlvbnM6DQo+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+PiBjbGllbnQtaW5p dGlhdGVkIHRyYW5zYWN0aW9ucyBhbmQgDQo+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+PiBzZXJ2ZXIt aW5pdGlhdGVkIHRyYW5zYWN0aW9ucy4NCj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+DQo+Pj4+Pj4+ Pj4+Pj4+Pj4+Pj4+Pj4+PiBDbGllbnQtaW5pdGlhdGVkIHRyYW5zYWN0aW9ucyBjb25zaXN0IG9m IGEgDQo+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+PiByZXF1ZXN0IGZyb20gYSBjbGllbnQgdG8gYSBm bG9vciBjb250cm9sIHNlcnZlciANCj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+IGFuZCBhIHJlc3Bv bnNlIGZyb20gdGhlIGZsb29yIGNvbnRyb2wgc2VydmVyIHRvIHRoZSBjbGllbnQuDQo+Pj4+Pj4+ Pj4+Pj4+Pj4+Pj4+Pj4+Pg0KPj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4gU2VydmVyLWluaXRpYXRl ZCB0cmFuc2FjdGlvbnMgaGF2ZSBkaWZmZXJlbnQgDQo+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+PiBi ZWhhdmlvciBkZXBlbmRpbmcgb24gdW5kZXJseWluZyB0cmFuc3BvcnQ6DQo+Pj4+Pj4+Pj4+Pj4+ Pj4+Pj4+Pj4+Pg0KPj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4gICAgICAgV2hlbiB1c2luZyBhIHJl bGlhYmxlIHRyYW5zcG9ydCwgDQo+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+PiBzZXJ2ZXItaW5pdGlh dGVkIHRyYW5zYWN0aW9ucw0KPj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4gICAgICAgY29uc2lzdCBv ZiBhIHNpbmdsZSBtZXNzYWdlIGZyb20gYSBmbG9vciANCj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+ IGNvbnRyb2wgc2VydmVyIHRvIGENCj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+ICAgICAgIGNsaWVu dCAobm90aWZpY2F0aW9ucykuICBUaGV5IGRvIG5vdCANCj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+ IHRyaWdnZXIgYW55IHJlc3BvbnNlLg0KPj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4NCj4+Pj4+Pj4+ Pj4+Pj4+Pj4+Pj4+Pj4+ICAgICAgIFdoZW4gdXNpbmcgYW4gdW5yZWxpYWJsZSB0cmFuc3BvcnQs IA0KPj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4gc2VydmVyLWluaXRpYXRlZCB0cmFuc2FjdGlvbnMN Cj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+ICAgICAgIGNvbnNpc3Qgb2YgYSByZXF1ZXN0IGZyb20g YSBmbG9vciBjb250cm9sIA0KPj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4gc2VydmVyIHRvIGEgY2xp ZW50IGFuZCBhDQo+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+PiAgICAgICByZXNwb25zZSBmcm9tIHRo ZSBjbGllbnQgdG8gdGhlIGZsb29yIA0KPj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4gY29udHJvbCBz ZXJ2ZXIuDQo+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pg0KPj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4g V2hlbiB1c2luZyBCRkNQIG92ZXIgYW4gdW5yZWxpYWJsZSB0cmFuc3BvcnQsIA0KPj4+Pj4+Pj4+ Pj4+Pj4+Pj4+Pj4+Pj4gcmV0cmFuc21pc3Npb24gdGltZXIgVDEgKHNlZSBTZWN0aW9uIDguMykg TVVTVCANCj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+IGJlIHVzZWQgZm9yIGFsbCByZXF1ZXN0cyB1 bnRpbCB0aGUgdHJhbnNhY3Rpb24gDQo+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+PiBpcyBjb21wbGV0 ZWQuDQo+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pg0KPj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4gVGhl biBpbiBzZWN0aW9uIDguMSwgd2UgYWRkIHRoZSBpbXBvcnRhbnQgDQo+Pj4+Pj4+Pj4+Pj4+Pj4+ Pj4+Pj4+PiBkZXRhaWxzIHJlbW92ZWQgZnJvbSBzZWN0aW9uIDguDQo+Pj4+Pj4+Pj4+Pj4+Pj4+ Pj4+Pj4+Pg0KPj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4gOC4xLjEgQ2xpZW50IEJlaGF2aW9yDQo+ Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pg0KPj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4gQSBjbGllbnQg c3RhcnRpbmcgYSBjbGllbnQtaW5pdGlhdGVkIHRyYW5zYWN0aW9uIA0KPj4+Pj4+Pj4+Pj4+Pj4+ Pj4+Pj4+Pj4gTVVTVCBzZXQgdGhlIENvbmZlcmVuY2UgSUQgaW4gdGhlIGNvbW1vbiBoZWFkZXIg DQo+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+PiBvZiB0aGUgbWVzc2FnZSB0byB0aGUgQ29uZmVyZW5j ZSBJRCBmb3IgdGhlIA0KPj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4gY29uZmVyZW5jZSB0aGF0IHRo ZSBjbGllbnQgb2J0YWluZWQgcHJldmlvdXNseS4NCj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+DQo+ Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+PiBUaGUgY2xpZW50IE1VU1Qgc2V0IHRoZSBUcmFuc2FjdGlv biBJRCB2YWx1ZSBpbiANCj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+IHRoZSBjb21tb24gaGVhZGVy IHRvIGEgbnVtYmVyIHRoYXQgaXMgZGlmZmVyZW50DQo+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+PiAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICANCj4+Pj4+Pj4+Pj4+ Pj4+Pj4+Pj4+Pj4gPmZyb20gMCBhbmQgdGhhdCBNVVNUIE5PVCBiZSByZXVzZWQgaW4gYW5vdGhl cg0KPj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+PiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgDQo+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+PiBtZXNzYWdlIGZyb20gdGhlIGNs aWVudCB1bnRpbCBhIHJlc3BvbnNlIGZyb20gDQo+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+PiB0aGUg c2VydmVyIGlzIHJlY2VpdmVkIGZvciB0aGUgdHJhbnNhY3Rpb24uDQo+Pj4+Pj4+Pj4+Pj4+Pj4+ Pj4+Pj4+PiBUaGUgY2xpZW50IHVzZXMgdGhlIFRyYW5zYWN0aW9uIElEIHZhbHVlIHRvIA0KPj4+ Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4gbWF0Y2ggdGhpcyBtZXNzYWdlIHdpdGggdGhlIHJlc3BvbnNl IGZyb20gdGhlIA0KPj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4gZmxvb3IgY29udHJvbCBzZXJ2ZXIu DQo+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+PiBXaGVuIHVzaW5nIEJGQ1Agb3ZlciBhbiB1bnJlbGlh YmxlIHRyYW5zcG9ydCwgaXQgDQo+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+PiBpcyBpbXBvcnRhbnQg dG8gY2hvb3NlIGEgVHJhbnNhY3Rpb24gSUQgdmFsdWUgDQo+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+ PiB0aGF0IGxldHMgdGhlIHJlY2VpdmVyIGRpc3Rpbmd1aXNoIHRoZSByZWNlcHRpb24gDQo+Pj4+ Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+PiBvZiB0aGUgbmV4dCBtZXNzYWdlIGluIGEgc2VxdWVuY2Ugb2Yg QkZDUCANCj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+IG1lc3NhZ2VzIGZyb20gYSByZXRyYW5zbWlz c2lvbiBvZiBhIHByZXZpb3VzIA0KPj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4gbWVzc2FnZS4gIFRo ZXJlZm9yZSwgQkZDUCBlbnRpdGllcyB1c2luZyBhbiANCj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+ IHVucmVsaWFibGUgdHJhbnNwb3J0IE1VU1QgdXNlIG1vbm90b25pY2FsbHkgDQo+Pj4+Pj4+Pj4+ Pj4+Pj4+Pj4+Pj4+PiBpbmNyZWFzaW5nIFRyYW5zYWN0aW9uIElEIHZhbHVlcyAoZXhjZXB0IGZv ciB3cmFwLWFyb3VuZCkuDQo+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pg0KPj4+Pj4+Pj4+Pj4+Pj4+ Pj4+Pj4+Pj4gQSBjbGllbnQgcmVjZWl2aW5nIGEgc2VydmVyLWluaXRpYXRlZCANCj4+Pj4+Pj4+ Pj4+Pj4+Pj4+Pj4+Pj4+IHRyYW5zYWN0aW9uIG92ZXIgYW4gdW5yZWxpYWJsZSB0cmFuc3BvcnQg TVVTVCANCj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+IGNvcHkgdGhlIFRyYW5zYWN0aW9uIElEIGZy b20gdGhlIHJlcXVlc3QgDQo+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+PiByZWNlaXZlZCBmcm9tIHRo ZSBzZXJ2ZXIgaW50byB0aGUgcmVzcG9uc2UuDQo+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+PiBbUXVl c3Rpb246IGlzIHRoZXJlIGEgbmVlZCB0byBjb3B5IHRoZSANCj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+ Pj4+IENvbmZlcmVuY2UgSUQgYW5kICBVc2VyIElELCBpZiBwcmVzZW50P10NCj4+Pj4+Pj4+Pj4+ Pj4+Pj4+Pj4+Pj4+DQo+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+PiA4LjIuIFNlcnZlciBCZWhhdmlv cg0KPj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4NCj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+IEEgZmxv b3IgY29udHJvbCBzZXJ2ZXIgc2VuZGluZyBhIHJlc3BvbnNlIHdpdGhpbiANCj4+Pj4+Pj4+Pj4+ Pj4+Pj4+Pj4+Pj4+IGEgY2xpZW50LWluaXRpYXRlZCB0cmFuc2FjdGlvbiBNVVNUIGNvcHkgdGhl IA0KPj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4gQ29uZmVyZW5jZSBJRCwgdGhlIFRyYW5zYWN0aW9u IElELCBhbmQgdGhlIFVzZXIgDQo+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+PiBJRA0KPj4+Pj4+Pj4+ Pj4+Pj4+Pj4+Pj4+Pj4gICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgDQo+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+ID5mcm9tIHRoZSByZXF1ZXN0IHJlY2VpdmVkIGZy b20gdGhlIGNsaWVudCBpbnRvIA0KPj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+PiA+dGhlDQo+Pj4+Pj4+ Pj4+Pj4+Pj4+Pj4+Pj4+ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICANCj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+IHJlc3BvbnNlLg0KPj4+Pj4+Pj4+Pj4+Pj4+Pj4+ Pj4+Pj4NCj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+IFNlcnZlci1pbml0aWF0ZWQgdHJhbnNhY3Rp b25zIE1VU1QgY29udGFpbiBhIA0KPj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4gVHJhbnNhY3Rpb24g SUQgZXF1YWwgdG8NCj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+IDAgd2hlbiBCRkNQIGlzIHVzZWQg b3ZlciBhIHJlbGlhYmxlIHRyYW5zcG9ydC4NCj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+IE92ZXIg YW4gdW5yZWxpYWJsZSB0cmFuc3BvcnQsIHRoZSBUcmFuc2FjdGlvbiBJRCANCj4+Pj4+Pj4+Pj4+ Pj4+Pj4+Pj4+Pj4+IHNoYWxsIGhhdmUgdGhlIHNhbWUgcHJvcGVydGllcyBhcyBmb3IgDQo+Pj4+ Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+PiBjbGllbnQtaW5pdGlhdGVkIHRyYW5zYWN0aW9ucy4NCj4+Pj4+ Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+IFRoZSBzZXJ2ZXIgdXNlcyB0aGUgVHJhbnNhY3Rpb24gSUQgdmFs dWUgdG8gDQo+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+PiBtYXRjaCB0aGlzIG1lc3NhZ2Ugd2l0aCB0 aGUgcmVzcG9uc2UgZnJvbSB0aGUgDQo+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+PiBmbG9vciBwYXJ0 aWNpcGFudCBvciBmbG9vciBjaGFpci4NCj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+DQo+Pj4+Pj4+ Pj4+Pj4+Pj4+Pj4+Pj4+Pg0KPj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4NCj4+Pj4+Pj4+Pj4+Pj4+ Pj4+Pj4+Pj4+ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIA0K Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+PiBUaGFua3MsIHRoaXMgaXMgYmV0dGVyLg0KPj4+Pj4+Pj4+ Pj4+Pj4+Pj4+Pj4+Pg0KPj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pg0KPj4+Pj4+Pj4+Pj4+Pj4+Pj4+ Pj4+Pg0KPj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+PiAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgDQo+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4gPSBTZWN0aW9uIDkgKGlt cGFjdHMgU2VjdGlvbiAxNCBhcyB3ZWxsKSA9IA0KPj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+ICJC RkNQIGNsaWVudHMgIFNIT1VMRCBhdXRoZW50aWNhdGUgdGhlIGZsb29yIA0KPj4+Pj4+Pj4+Pj4+ Pj4+Pj4+Pj4+Pj4+IGNvbnRyb2wgc2VydmVyIGJlZm9yZSAgc2VuZGluZyBhbnkgQkZDUCBtZXNz YWdlIA0KPj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+IHRvIGl0IG9yIGFjY2VwdGluZyBhbnkgQkZD UCBtZXNzYWdlIGZyb20gaXQuDQo+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4gU2ltaWxhcmx5LCBm bG9vciBjb250cm9sIHNlcnZlcnMgU0hPVUxEIA0KPj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+IGF1 dGhlbnRpY2F0ZSBhIGNsaWVudCBiZWZvcmUgYWNjZXB0aW5nIGFueSBCRkNQIA0KPj4+Pj4+Pj4+ Pj4+Pj4+Pj4+Pj4+Pj4+IG1lc3NhZ2UgZnJvbSBpdCBvciBzZW5kaW5nIGFueSBCRkNQIG1lc3Nh Z2UgdG8gaXQuDQo+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4NCj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+ Pj4+PiBCRkNQIHN1cHBvcnRzIFRMUy9EVExTIG11dHVhbCBhdXRoZW50aWNhdGlvbiANCj4+Pj4+ Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+PiBiZXR3ZWVuIGNsaWVudHMgYW5kIGZsb29yIGNvbnRyb2wgc2Vy dmVycywgYXMgDQo+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4gc3BlY2lmaWVkIGluIFNlY3Rpb24g OS4xLg0KPj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+IFRoaXMgaXMgdGhlIFJFQ09NTUVOREVEIGF1 dGhlbnRpY2F0aW9uIA0KPj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+IG1lY2hhbmlzbSBpbiBCRkNQ LsKyDQo+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4NCj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+PiBX aGF0IGFyZSB0aGUgY2FzZXMgd2hlcmUgY2xpZW50cyBhbmQgc2VydmVycyBkbyANCj4+Pj4+Pj4+ Pj4+Pj4+Pj4+Pj4+Pj4+PiBub3QgbmVlZCAgdG8gYmUgYXV0aGVudGljYXRpbmcgZWFjaCBvdGhl cj8gSSANCj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+PiBrbm93IHRoaXMgcmVxdWlyZW1lbnQgIGFu ZCB0aGUgb3RoZXIgDQo+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4gU0hPVUxELWxldmVsIHJlcXVp cmVtZW50cyBhcm91bmQgdXNlIG9mICANCj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+PiBUTFMvRFRM UyBhcmUgY2FycmllZCBvdmVyIGZyb20gUkZDIDQ1ODIsIGJ1dCANCj4+Pj4+Pj4+Pj4+Pj4+Pj4+ Pj4+Pj4+PiBJwrltICBjb25jZXJuZWQgdGhhdCB0aGV5IGFyZW7CuXQgYXMgc3Ryb25nIGFzIHRo ZXkgc2hvdWxkIGJlLg0KPj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+IEZvciBhIGNvbmZlcmVuY2Ug d2hlcmUgdGhlIHNpZ25hbGluZyB0cmFmZmljIGlzIA0KPj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+ IGF1dGhlbnRpY2F0ZWQgYW5kIGNvbmZpZGVudGlhbGl0eSBhbmQgaW50ZWdyaXR5IA0KPj4+Pj4+ Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+IHByb3RlY3RlZCwgd2h5IGlzIGl0IG9rIGZvciB0aGUgZmxvb3Ig Y29udHJvbCANCj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+PiB0cmFmZmljIG5vdCB0byBiZT8gQ291 bGQgdGhlc2UgcmVxdWlyZW1lbnRzIGJlIA0KPj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+IGFkanVz dGVkIHRvIHJlcXVpcmUgdXNlIG9mIFRMUy9EVExTIGF0IGxlYXN0IGluIA0KPj4+Pj4+Pj4+Pj4+ Pj4+Pj4+Pj4+Pj4+IGNhc2VzIHdoZXJlIHRoZSBzaWduYWxpbmcgaXMgYWxzbyBwcm90ZWN0ZWQ/ DQo+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4NCj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pg0KPj4+ Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgDQo+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+PiBZZXMsIGJ1dCBhZ2FpbiwgdGhp cyB3b3VsZCBiZSBhdCB0aGUgZXhwZW5zZSBvZiANCj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+IGFk ZGluZyBhIG5vbiBiYWNrd2FyZCBjb21wYXRpYmxlIGNoYW5nZSBmcm9tIHJmYyANCj4+Pj4+Pj4+ Pj4+Pj4+Pj4+Pj4+Pj4+IDQ1ODIuIEhvdyBhYm91dCBzYXlpbmcgVExTL0RUTFMgTVVTVCBiZSB1 c2VkIGZvciANCj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+IEJGQ1AgaW4gc3VjaCBjYXNlcywgd2hp bGUgcG9pbnRpbmcgb3V0IHRoZSByZmMNCj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+IDQ1ODINCj4+ Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+IGJhc2VkIGltcGxlbWVudGF0aW9ucyBtYXkgbm90IGNvbXBs eSAoc2ltaWxhciB0byANCj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+IHdoYXQgd2UgZGlkIHdpdGgg dGhlIHZlcnNpb24gZmllbGQpLg0KPj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4NCj4+Pj4+Pj4+Pj4+ Pj4+Pj4+Pj4+Pj4+DQo+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+PiAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICANCj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4gV29ya3Mg Zm9yIG1lLg0KPj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pg0KPj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+PiBG ZWVsIGZyZWUgdG8gbWFrZSBhbGwgb2YgdGhlc2UgY2hhbmdlcyBhbmQgc3VibWl0IA0KPj4+Pj4+ Pj4+Pj4+Pj4+Pj4+Pj4+PiBhIHJldiBhbmQgScK5bGwgaXNzdWUgdGhlIElFVEYgTEMuDQo+Pj4+ Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+DQo+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+IFRoYW5rcywNCj4+Pj4+ Pj4+Pj4+Pj4+Pj4+Pj4+Pj4gQWxpc3NhDQo+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+DQo+Pj4+Pj4+ Pj4+Pj4+Pj4+Pj4+Pj4+DQo+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+DQo+Pj4+Pj4+Pj4+Pj4+Pj4+ Pj4+Pj4+ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICANCj4+Pj4+ Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+PiA9IFNlY3Rpb24gMTQgPQ0KPj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+ Pj4+IFNlZSB0aGUgcG9pbnQgYWJvdmUgYWJvdXQgY2lwaGVyc3VpdGVzLiANCj4+Pj4+Pj4+Pj4+ Pj4+Pj4+Pj4+Pj4+PiDCs05vbi1udWxsIGVuY3J5cHRpb27CsiBpcyBub3QgYSBzdWZmaWNpZW50 IA0KPj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+IG1pbmltdW0gYmFzZWxpbmUsIGFuZCBpZiB0aGUg cmVxdWlyZW1lbnRzIA0KPj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+IGNoYW5nZSBpbiBTZWN0aW9u IDcgdGhleSBzaG91bGQgYmUgcmVmbGVjdGVkIGhlcmUgYXMgd2VsbC4NCj4+Pj4+Pj4+Pj4+Pj4+ Pj4+Pj4+Pj4+Pg0KPj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+DQo+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+ Pj4+Pj4gICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICANCj4+ Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+IFllcC4NCj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+DQo+Pj4+ Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pg0KPj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4NCj4+Pj4+Pj4+Pj4+ Pj4+Pj4+Pj4+Pj4+ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg IA0KPj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+IEVkaXRvcmlhbCBuaXRzIHRvIGJlIHJlc29sdmVk IHdpdGggTEMgY29tbWVudHM6DQo+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4NCj4+Pj4+Pj4+Pj4+ Pj4+Pj4+Pj4+Pj4+PiA9IFNlY3Rpb24gNS4xID0gwrNUaGUgdmVyc2lvbiBmaWVsZCBNVVNUIGJl IHNldCANCj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+PiB0byAxIHdoZW4gdXNpbmcgQkZDUCBvdmVy IGEgcmVsaWFibGUgdHJhbnNwb3J0LCANCj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+PiBpLmUuIGFz IGluIFsyXS7Csg0KPj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+DQo+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+ Pj4+Pj4gSSBmaW5kIGl0IGEgbGl0dGxlIG9kZCB0byByZWZlcmVuY2UgdGhlIHNwZWMgDQo+Pj4+ Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4geW91wrlyZSBvYnNvbGV0aW5nIGluIHRoaXMgc2VudGVuY2Us IGVzcGVjaWFsbHkgDQo+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4gc2luY2UgQkZDUCBvdmVyIGEg cmVsaWFibGUgdHJhbnNwb3J0IGlzIA0KPj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+IGNvbXBsZXRl bHkgc3BlY2lmaWVkIGluIHRoaXMgYmlzIGRvY3VtZW50LiBJIA0KPj4+Pj4+Pj4+Pj4+Pj4+Pj4+ Pj4+Pj4+IHdvdWxkIHN1Z2dlc3QgZHJvcHBpbmcNCj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+PiAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIA0KPj4gdGhlIGku ZS4NCj4+ICAgIA0KPj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+IGNsYXVzZS4NCj4+Pj4+Pj4+Pj4+ Pj4+Pj4+Pj4+Pj4+Pg0KPj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+DQo+Pj4+Pj4+Pj4+Pj4+Pj4+ Pj4+Pj4+Pj4gICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAN Cj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+IEdvb2QgY2F0Y2guIFRoaXMgaXMgYSBjYXJyeSBvdmVy IGZyb20gYmVmb3JlIA0KPj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4gdGhpcyBkcmFmdCB3YXMgYWRv cHRlZCBhcyBhIGJpcyB2ZXJzaW9uIG9mIHJmYzQ1ODIuDQo+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+ Pg0KPj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4NCj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+DQo+Pj4+ Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+PiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICANCj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+PiAiVGhlIHZlcnNpb24gZmllbGQgTVVT VCBiZSBzZXQgdG8gMiB3aGVuIHVzaW5nIA0KPj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+IEJGQ1Ag b3ZlciBhbiB1bnJlbGlhYmxlIHRyYW5zcG9ydCB3aXRoIHRoZSANCj4+Pj4+Pj4+Pj4+Pj4+Pj4+ Pj4+Pj4+PiBleHRlbnNpb25zIHNwZWNpZmllZCBpbiB0aGlzIGRvY3VtZW50LsKyDQo+Pj4+Pj4+ Pj4+Pj4+Pj4+Pj4+Pj4+Pj4NCj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+PiBUaGUgYml0IGFib3V0 IMKzd2l0aCB0aGUgZXh0ZW5zaW9ucyBzcGVjaWZpZWQgaW4gDQo+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+ Pj4+Pj4gdGhpcyBkb2N1bWVudMKyIGlzIGV4dHJhbmVvdXMgYW5kIHNob3VsZCBiZSByZW1vdmVk Lg0KPj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+DQo+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4gIklm IGFuIGVuZHBvaW50IHJlY2VpdmVzIGEgbWVzc2FnZSB3aXRoIGFuIA0KPj4+Pj4+Pj4+Pj4+Pj4+ Pj4+Pj4+Pj4+IHVuc3VwcG9ydGVkIHZlcnNpb24gZmllbGQgdmFsdWUsIHRoZSByZWNlaXZpbmcg DQo+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4gc2VydmVyIE1VU1Qgc2VuZCBhbiBFcnJvciBtZXNz YWdlIHdpdGggDQo+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4gcGFyYW1ldGVyIHZhbHVlIDEyIChV bnN1cHBvcnRlZA0KPj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+IFZlcnNpb24pIHRvIGluZGljYXRl IHRoaXMuwrINCj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pg0KPj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+ Pj4+IFVzZSBvZiB0aGUgd29yZCDCs3NlcnZlcsKyIGhlcmUgbWFrZXMgaXQgc291bmQgYXMgDQo+ Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4gaWYgb25seSBzZXJ2ZXJzIGNvdWxkIHJlY2VpdmUgaGVh ZGVycyB3aXRoIA0KPj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+IHVuc3VwcG9ydGVkIHZlcnNpb25z Lg0KPj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+IFNob3VsZCB0aGlzIGJlIMKzdGhlIHJlY2Vpdmlu ZyBlbmRwb2ludMKyPw0KPj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+DQo+Pj4+Pj4+Pj4+Pj4+Pj4+ Pj4+Pj4+Pj4gPSBTZWN0aW9uIDYuMi40ID0gIlsyM10sIFNlY3Rpb24gNi43IHByb3ZpZGVzIA0K Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+IHVzZWZ1bCByZWNvbW1lbmRhdGlvbnMgxaDCsg0KPj4+ Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+DQo+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4gVGhlIGxpbmtz IGluIHRoZSByZWZlcmVuY2VzIGFyZSBub3QgcXVpdGUgcmlnaHQuDQo+Pj4+Pj4+Pj4+Pj4+Pj4+ Pj4+Pj4+Pj4NCj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+PiA9IFNlY3Rpb24gOC4zLjIgPSBzL3do ZW4gZmlyZXMvd2hlbiBmaXJlZC8NCj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pg0KPj4+Pj4+Pj4+ Pj4+Pj4+Pj4+Pj4+Pj4+ID0gU2VjdGlvbiAxNCA9DQo+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4g cy9oaWdoLWphY2svaGlqYWNrLw0KPj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+DQo+Pj4+Pj4+Pj4+ Pj4+Pj4+Pj4+Pj4+Pj4gPSBTZWN0aW9uIEIuMSA9ICJzaXR1YXRpb24gd2hlcmUgbXVsdGlwbGUg DQo+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4gZGlmZmVyZW50IGFuZCBub24taW50ZXJvcGVyYWJs ZSB3b3VsZA0KPj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+IGNvLQ0KPj4+Pj4+Pj4+Pj4+Pj4+Pj4+ Pj4+Pj4+IGV4aXN0IGluIHRoZSBtYXJrZXQuwrINCj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pg0K Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+IFRoZXJlIGlzIGEgd29yZCBtaXNzaW5nIGFmdGVyIMKz bm9uLWludGVyb3BlcmFibGUuIg0KPj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+DQo+Pj4+Pj4+Pj4+ Pj4+Pj4+Pj4+Pj4+Pj4NCj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+PiAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIA0KPj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4g VGhpcyBzaG91bGQgcmVhZCDCs25vbi1pbnRlcm9wZXJhYmxlIGltcGxlbWVudGF0aW9uc8KyLg0K Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4gRWFybGllciBpbiB0aGF0IHNhbWUgc2VudGVuY2UsIMKz QkZDUCBvdmVyIFVEUCANCj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+IHdlcmUgYWxyZWFkeSB1c2Vk wrIgc2hvdWxkIHJlYWQgwrNCRkNQIG92ZXIgVURQIGlzIA0KPj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+ Pj4gYWxyZWFkeSBiZWluZyB1c2VkwrIuDQo+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pg0KPj4+Pj4+ Pj4+Pj4+Pj4+Pj4+Pj4+Pj4gQ2hlZXJzLA0KPj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4gQ2hhcmxl cw0KPj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4NCj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+DQo+Pj4+ Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+PiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICANCj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4gX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX18NCj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4gYmZjcGJpcyBt YWlsaW5nIGxpc3QgDQo+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+IGJmY3BiaXNAaWV0Zi5vcmc8bWFp bHRvOmJmY3BiaXNAaWV0Zi5vcmc+DQo+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+IGh0dHBzOi8vd3d3 LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vYmZjcGJpcw0KPj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+ Pg0KPj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pg0KPj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+PiAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgDQo+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+ Pj4NCj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+PiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgIA0KPj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4NCj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+ICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIA0KPj4+Pj4+Pj4+Pj4+Pj4+Pj4+ Pg0KPj4+Pj4+Pj4+Pj4+Pj4+Pj4+PiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgDQo+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4NCj4+Pj4+Pj4+Pj4+Pj4+Pj4+PiAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgIA0KPj4+Pj4+Pj4+Pj4+Pj4+Pj4NCj4+Pj4+Pj4+Pj4+Pj4+ Pj4+ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIA0KPj4+Pj4+Pj4+Pj4+Pj4+Pg0K Pj4+Pj4+Pj4+Pj4+Pj4+PiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgDQo+Pj4+Pj4+ Pj4+Pj4+Pj4NCj4+Pj4+Pj4+Pj4+Pj4+PiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIA0K Pj4+Pj4+Pj4+Pj4+Pj4NCj4+Pj4+Pj4+Pj4+Pj4+ICAgICAgICAgICAgICAgICAgICAgICAgICAg IA0KPj4+Pj4+Pj4+Pj4+Pg0KPj4+Pj4+Pj4+Pj4+PiAgICAgICAgICAgICAgICAgICAgICAgICAg DQo+Pj4+Pj4+Pj4+Pg0KPj4+Pj4+Pj4+Pj4gICAgICAgICAgICAgICAgICAgICAgDQo+Pj4+Pj4+ Pj4+DQo+Pj4+Pj4+Pj4+ICAgICAgICAgICAgICAgICAgICANCj4+Pj4+Pj4+PiAgICAgICAgICAg ICAgICAgIA0KPj4+Pj4+Pj4gX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX18NCj4+Pj4+Pj4+IGJmY3BiaXMgbWFpbGluZyBsaXN0DQo+Pj4+Pj4+PiBiZmNwYmlz QGlldGYub3JnDQo+Pj4+Pj4+PiBodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZv L2JmY3BiaXMNCj4+Pj4+Pj4+ICAgICAgICAgICAgICAgIA0KPj4+Pj4+PiAgICAgICAgICAgICAg DQo+Pj4+Pj4gICAgICAgICAgICANCj4+Pj4+ICAgICAgICAgIA0KPj4+PiAgICAgICAgDQo+Pj4g X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCj4+PiBiZmNw YmlzIG1haWxpbmcgbGlzdA0KPj4+IGJmY3BiaXNAaWV0Zi5vcmcNCj4+PiBodHRwczovL3d3dy5p ZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL2JmY3BiaXMNCj4+PiAgICAgIA0KPj4gICAgDQo+DQoN Cg== From nobody Tue Nov 3 00:25:28 2015 Return-Path: X-Original-To: bfcpbis@ietfa.amsl.com Delivered-To: bfcpbis@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8D2381A00BE for ; Tue, 3 Nov 2015 00:25:26 -0800 (PST) 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 DzrmHWky2ekT for ; Tue, 3 Nov 2015 00:25:17 -0800 (PST) Received: from aer-iport-4.cisco.com (aer-iport-4.cisco.com [173.38.203.54]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7AA561A01CB for ; Tue, 3 Nov 2015 00:25:16 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=52937; q=dns/txt; s=iport; t=1446539116; x=1447748716; h=message-id:date:from:mime-version:to:cc:subject: references:in-reply-to:content-transfer-encoding; bh=f+lswFWp93QildV8w7OFM5OryVVX7H1Nfl6XTChv9bw=; b=CxjlODr4thm1/PBcZyIXT4Q+c/RXdqGpnSC0fOgNrlQCcu0kvZtBG5wt wdm8QUnUVAWpltjsTjgfAOY1hESmxTDxzY6dsvCTOYm8ym5t8oGQuCz7t QeghZ5iDTl6Pxyg7Rkym+vZEH8T4dfldHAd1RlyvYlutUoQTbAP18b1Xb E=; X-IronPort-AV: E=Sophos;i="5.20,238,1444694400"; d="scan'208";a="607936458" Received: from aer-iport-nat.cisco.com (HELO aer-core-2.cisco.com) ([173.38.203.22]) by aer-iport-4.cisco.com with ESMTP; 03 Nov 2015 08:25:14 +0000 Received: from [10.54.90.26] (dhcp-10-54-90-26.cisco.com [10.54.90.26]) by aer-core-2.cisco.com (8.14.5/8.14.5) with ESMTP id tA38PEfQ002393; Tue, 3 Nov 2015 08:25:14 GMT Message-ID: <56386F6A.9040200@cisco.com> Date: Tue, 03 Nov 2015 09:25:14 +0100 From: Tom Kristensen Organization: Cisco User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.1.15) Gecko/20101027 Fedora/3.0.10-1.fc12 Lightning/1.0b2pre Thunderbird/3.0.10 MIME-Version: 1.0 To: Christer Holmberg References: <7594FB04B1934943A5C02806D1A2204B37BC8F7B@ESESSMB209.ericsson.se> <56371495.7080105@cisco.com> <7594FB04B1934943A5C02806D1A2204B37BCD730@ESESSMB209.ericsson.se> In-Reply-To: <7594FB04B1934943A5C02806D1A2204B37BCD730@ESESSMB209.ericsson.se> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit Archived-At: Cc: Ben Campbell , "bfcpbis@ietf.org" , Alissa Cooper , "Charles Eckel \(eckelcu\)" , Gonzalo Camarillo , "draft-ietf-bfcpbis-rfc4582bis@tools.ietf.org" Subject: Re: [bfcpbis] Status update on draft-ietf-mmusic-dtls-sdp [was: draft-ietf-bfcpbis-rfc4583bis] X-BeenThere: bfcpbis@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: BFCPBIS working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 Nov 2015 08:25:26 -0000 I have to study the latest version of draft-ietf-mmusic-dtls-sdp to tell, but as of know I think we may need a new section similar to "8.1. TCP Connection Management" for DTLS/UDP, where amongst other things the 'dtls-connection' will be mentioned. -- Tom On 11/02/2015 11:39 AM, Christer Holmberg wrote: > Just a question for clarification: will the draft now adopt the 'dtls-connection' attribute defined in the DTLS-SDP draft? > > Regards, > > Christer > > -----Original Message----- > From: Charles Eckel (eckelcu) [mailto:eckelcu@cisco.com] > Sent: 02 November 2015 10:26 > To: Tom Kristensen (tomkrist); Christer Holmberg > Cc: Alissa Cooper; bfcpbis@ietf.org; draft-ietf-bfcpbis-rfc4582bis@tools.ietf.org; Gonzalo Camarillo; Ben Campbell > Subject: Re: Status update on draft-ietf-mmusic-dtls-sdp [was: [bfcpbis] draft-ietf-bfcpbis-rfc4583bis] > > Great, thanks Tom. I look forward to seeing the update posted before the end of this week. > > Cheers, > Charles > > On 11/2/15, 4:45 PM, "Tom Kristensen (tomkrist)" > wrote: > > >> Perfect! I'll update and polish the draft as discussed and agreed upon >> below and submit. >> >> -- Tom >> >> On 11/02/2015 08:04 AM, Christer Holmberg wrote: >> >>> Hi, >>> >>> draft-ietf-mmusic-dtls-sdp was discussed at MMUSIC today. >>> >>> At this moment there are no technical open issues. The plan is to add >>> some editorial work, based on comments received during the session, >>> and the add text regarding DTLS-usage drafts/specs that the draft updates. >>> After that, unless something unexpected comes up, the draft should be >>> ready for WGLC. >>> >>> Regards, >>> >>> Christer >>> >>> >>> >>> -----Original Message----- >>> From: Charles Eckel (eckelcu) [mailto:eckelcu@cisco.com] >>> Sent: 28 September 2015 18:50 >>> To: Christer Holmberg; Tom Kristensen >>> (tomkrist) >>> Cc: Alissa Cooper; bfcpbis@ietf.org; >>> draft-ietf-bfcpbis-rfc4582bis@tools.ietf.org; Gonzalo >>> Camarillo; Ben >>> Campbell >>> Subject: Re: [bfcpbis] draft-ietf-bfcpbis-rfc4583bis >>> >>> Thanks Christer. >>> >>> Tom, can you please post the corresponding update to the draft? >>> >>> Cheers, >>> Charles >>> >>> On 9/28/15, 3:07 AM, "bfcpbis on behalf of Christer Holmberg" >>> >> christer.holmberg@ericsson.com> >>> wrote: >>> >>> >>> >>>> Hi, >>>> >>>> >>>> >>>>> In that case, I prefer Tom’s original suggestion, >>>>> >>>>> What if we keep the text and adds this as an additional reference >>>>> in the two new text passages proposed by Charles: "... [13], and >>>>> the clarifications defined in [draft-ietf-mmusic-dtls-sdp], ...". >>>>> >>>>> Where [13] is a reference to RFC 5763. >>>>> >>>>> >>>> If that's something people can agree to, then can live with such >>>> compromise :) >>>> >>>> Regards, >>>> >>>> Christer >>>> >>>> >>>> >>>> >>>> >>>> If it turns out that draft-ietf-mmusic-dtls-sdp updates RFC 5763, >>>> then there is some redundancy. But that is better than having a hole >>>> when it comes to backward compatibility with existing >>>> implementations, which is what we will have today if we reference >>>> draft-ietf-mmusic-dtls-sdp only. >>>> >>>> Cheers, >>>> Charles >>>> >>>> >>>> >>>> On 9/25/15, 2:21 AM, "Christer Holmberg" >>>> >>>> wrote: >>>> >>>> >>>> >>>>> Hi Charles, >>>>> >>>>> >>>>> >>>>>> As a simple example, we currently refer to rfc4582bis instead of >>>>>> the eventual RFC. Assuming rfc4582bis does become an RFC, we would >>>>>> want the RFC editor to update references to it and to RFCxxxx with >>>>>> the actual RFC number. >>>>>> Similar here, we would want them to check with authors/chairs/ADs >>>>>> on the state of draft-ietf-mmusic-dtls-sdp to see if we want to >>>>>> replace our reference to RFC 5763 with a reference to it. This way >>>>>> we can move forward while draft-ietf-mmusic-dtls-sdp continues to >>>>>> progress as well. >>>>>> >>>>>> >>>>> I don't think it's the same thing. First you talk about a draft, >>>>> where the draft name will be replaced with the to-be-assigned RFC >>>>> number. In the case of DTLS-SDP we are talking about two separate specifications. >>>>> >>>>> Regards, >>>>> >>>>> Christer >>>>> >>>>> >>>>> On 9/24/15, 2:53 AM, "Christer Holmberg" >>>>> >>>>> wrote: >>>>> >>>>> >>>>> >>>>>> Hi Charles, >>>>>> >>>>>> I am still not sure I understand your suggestion: what is meant by >>>>>> "as determined prior to publication"? When/where/who? :) >>>>>> >>>>>> Regards, >>>>>> >>>>>> Christer >>>>>> >>>>>> -----Original Message----- >>>>>> From: Charles Eckel (eckelcu) [mailto:eckelcu@cisco.com] >>>>>> Sent: 22. syyskuuta 2015 17:05 >>>>>> To: Christer Holmberg; Tom Kristensen (tomkrist) >>>>>> Cc: draft-ietf-bfcpbis-rfc4582bis@tools.ietf.org; >>>>>> bfcpbis@ietf.org; Alissa Cooper; Gonzalo Camarillo; Ben Campbell >>>>>> Subject: Re: [bfcpbis] draft-ietf-bfcpbis-rfc4583bis >>>>>> >>>>>> I view referring to draft-ietf-mmusic-dtls-sdp now instead of RFC >>>>>> 5763 to be like writing a blank check. Debate is actively >>>>>> occurring on the list, the normative language in RFC 5763 is >>>>>> expected to be updated in multiple ways, and backward >>>>>> compatibility with the the normative language provide in previous >>>>>> version of rfc4583bis is not fully addressed. It seems more >>>>>> appropriate to me at this stage to continue to refer to RFC 5763 >>>>>> with a note regarding updating or replacing that reference with >>>>>> one to draft-ietf-mmusic-dtls-sdp, as determined prior to publication. >>>>>> >>>>>> Cheers, >>>>>> Charles >>>>>> >>>>>> On 9/21/15, 11:48 PM, "Christer Holmberg" >>>>>> >>>>>> wrote: >>>>>> >>>>>> >>>>>> >>>>>>> Hi, >>>>>>> >>>>>>> >>>>>>> >>>>>>>> I see. As this is a moving target, perhaps where we reference >>>>>>>> RFC >>>>>>>> 5763 we can add a note for the RFC editor that >>>>>>>> draft-ietf-mmusic-dtls-sdp is expected to add clarifications and >>>>>>>> make changes to RFC 5763 that should be considered prior to >>>>>>>> publication of rfc4583bis. >>>>>>>> >>>>>>>> >>>>>>> I am not sure I understand. I don't think it's up to the RFC >>>>>>> editor to make a decision whether the draft should reference DTLS-SDP. >>>>>>> >>>>>>> Regards, >>>>>>> >>>>>>> Christer >>>>>>> >>>>>>> >>>>>>> >>>>>>> On 9/21/15, 11:23 AM, "Christer Holmberg" >>>>>>> >>>>>>> wrote: >>>>>>> >>>>>>> >>>>>>> >>>>>>>> Hi, >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>>> RFC 5763, which is currently required for BFCP with DTLS reads: >>>>>>>>> >>>>>>>>> o The endpoint MUST NOT use the connection attribute >>>>>>>>> defined in >>>>>>>>> [RFC4145]. >>>>>>>>> >>>>>>>>> >>>>>>>> Correct. >>>>>>>> >>>>>>>> And, IF we decide to use define usage of the 'connection' >>>>>>>> attribute for DTLS, we would change that. >>>>>>>> >>>>>>>> However, a few days ago we sent an e-mail to the MMUSIC list, >>>>>>>> suggesting that we should NOT use the 'connection' attribute for >>>>>>>> DTLS. >>>>>>>> Instead we should define a new attribute (for more details, >>>>>>>> please see the MMUSIC list). >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>>> Section 5.1 of draft-ietf-mmusic-dtls-sdp reads: >>>>>>>>> >>>>>>>>> When used with DTLS, there is no default value defined for the >>>>>>>>> attribute. Implementations that wish to use the attribute MUST >>>>>>>>> explicitly include it in SDP offers and answers. If an >>>>>>>>> offer or >>>>>>>>> answer does not contain an attribute, other means needs to >>>>>>>>> be used in >>>>>>>>> order for endpoints to determine whether an offer or answer is >>>>>>>>> associated with an event that requires the DTLS association >>>>>>>>> to be >>>>>>>>> re- >>>>>>>>> established. >>>>>>>>> >>>>>>>>> I suppose if draft-ietf-mmusic-dtls-sdp pulls in enough from >>>>>>>>> RFC >>>>>>>>> 5763 to make it clear how the DTLS establishment and >>>>>>>>> re-establishment works for the case of which the connection >>>>>>>>> attribute is not used, then we can change the reference from >>>>>>>>> RFC >>>>>>>>> 5763 to draft-ietf-mmusic-dtls-sdp. >>>>>>>>> >>>>>>>>> The last several updates of draft-ietf-bfcpbis-rfc4583bis have >>>>>>>>> removed supporting text from the draft in favor of pointing to >>>>>>>>> RFC >>>>>>>>> 5763 as the source of truth. I fear that >>>>>>>>> draft-ietf-mmusic-dtls-sdp in its current state does not serve >>>>>>>>> that need for draft-ietf-bfcpbis-rfc4583bis. I value >>>>>>>>> Christer’s thoughts and welcome the opinion of others, >>>>>>>>> especially those who have or are implementing BFCP with DTLS and ICE, which I have not. >>>>>>>>> >>>>>>>>> >>>>>>>> Please note that DTLS-SDP does not only define usage of the >>>>>>>> 'connection' >>>>>>>> attribute, it also does other things. Maybe more important, it >>>>>>>> does not state that an address change by default requires a new >>>>>>>> DTLS association >>>>>>>> - which is a another 5763 modification. >>>>>>>> >>>>>>>> Regards, >>>>>>>> >>>>>>>> Christer >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> On 9/21/15, 9:32 AM, "bfcpbis on behalf of Christer Holmberg" >>>>>>>> >>>>>>> christer.holmberg@ericsson.com> >>>>>>>> wrote: >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>>> Hi Charles, >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>>> The problem I see with this is that it is not just a matter of >>>>>>>>>> changing the reference, it is also a matter of changing the >>>>>>>>>> normative behavior. >>>>>>>>>> For DTLS with BFCP, we never required the use of the>“connection” >>>>>>>>>> attribute. >>>>>>>>>> If we are to start requiring it, we would need add text to >>>>>>>>>> describe how to address backward compatibility in cases in >>>>>>>>>> which the connection attribute is not specified. >>>>>>>>>> >>>>>>>>>> >>>>>>>>> The intention is to cover backward compatibility in the draft. >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>>> Are there plans for this within RFC 5763bis draft? If so, >>>>>>>>>> Tom’s recommendation of continuing to point to RFC 5763 for >>>>>>>>>> now may be the best approach. >>>>>>>>>> >>>>>>>>>> >>>>>>>>> I am not familiar with the 5763bis draft. But, even if the >>>>>>>>> DTLS-SDP draft makes updates to 5763, it won't become a 5763bis >>>>>>>>> draft. >>>>>>>>> >>>>>>>>> Regards, >>>>>>>>> >>>>>>>>> Christer >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> On 9/11/15, 1:11 PM, "Christer Holmberg" >>>>>>>>> >>>>>>>>> wrote: >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>>> Hi, >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>>> Hmm, yes maybe an idea if it's fine proceeding with referring >>>>>>>>>>> a work-in-progress draft here. >>>>>>>>>>> What if we keep the text and adds this as an additional >>>>>>>>>>> reference in the two new text passages proposed by Charles: "... >>>>>>>>>>> [13], and the clarifications defined in >>>>>>>>>>> [draft-ietf-mmusic-dtls-sdp], ...". >>>>>>>>>>> >>>>>>>>>>> Where [13] is a reference to RFC 5763. >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>> My suggestion is to *only* refer the new dtls-sdp draft. >>>>>>>>>> Because, one of the ideas with the new draft is to also update >>>>>>>>>> RFC 5763 to reference the new dtls-sdp draft. >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>>> Anyway, I'd still prefer to keep the text in >>>>>>>>>>> draft-ietf-bfcpbis-rfc4583bis-12 and redirect the readers to >>>>>>>>>>> the rfc5763bis, that eventually then will obsolete (or >>>>>>>>>>> extend?) RFC 5763. >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>> The new dtls-sdp draft will not become 5763bis (eventhough it >>>>>>>>>> MAY update some parts of 5763). It's a generic document, which >>>>>>>>>> *any* DTLS usage can then reference. >>>>>>>>>> >>>>>>>>>> Regards, >>>>>>>>>> >>>>>>>>>> Christer >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> On 09/11/2015 01:25 PM, Christer Holmberg wrote: >>>>>>>>>> >>>>>>>>>> >>>>>>>>>>> Hi, >>>>>>>>>>> >>>>>>>>>>> My suggestion would actually be to refer to the new >>>>>>>>>>> draft-ietf-mmusic-dtls-sdp, which is going to clarify the >>>>>>>>>>> DTLS-SRTP rules regarding when a new DTLS association must be >>>>>>>>>>> established. >>>>>>>>>>> >>>>>>>>>>> Regards, >>>>>>>>>>> >>>>>>>>>>> Christer >>>>>>>>>>> >>>>>>>>>>> -----Original Message----- >>>>>>>>>>> From: Tom Kristensen [mailto:tomkrist@cisco.com] >>>>>>>>>>> Sent: 11. syyskuuta 2015 13:25 >>>>>>>>>>> To: Charles Eckel (eckelcu) >>>>>>>>>>> Cc: Christer Holmberg; Alissa Cooper; Gonzalo Camarillo; >>>>>>>>>>> draft-ietf-bfcpbis-rfc4582bis@tools.ietf.org; Ben Campbell; >>>>>>>>>>> bfcpbis@ietf.org >>>>>>>>>>> Subject: Re: draft-ietf-bfcpbis-rfc4583bis >>>>>>>>>>> >>>>>>>>>>> Pointing to the DTLS-SRTP (and by that any updates of it) is >>>>>>>>>>> a simple, safe and straigt-forward solution. >>>>>>>>>>> >>>>>>>>>>> The only change in the new version of rfc4583bis just submitted. >>>>>>>>>>> And as Charles says, this should be the last missing fix for >>>>>>>>>>> this draft until next stages in the process at least. >>>>>>>>>>> >>>>>>>>>>> -- Tom >>>>>>>>>>> >>>>>>>>>>> On 09/08/2015 07:48 PM, Charles Eckel (eckelcu) wrote: >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>>> Picking up on this old thread regarding >>>>>>>>>>>> draft-ietf-bfcpbis-rfc4583bis. >>>>>>>>>>>> I think this is the only outstanding item with respect to >>>>>>>>>>>> the current version of the draft. Unless anyone has an >>>>>>>>>>>> issue with the proposed resolution, I request we update the >>>>>>>>>>>> draft accordingly and then use it as the basis for Mary, >>>>>>>>>>>> the document shepherd, to provide a proto writeup. >>>>>>>>>>>> >>>>>>>>>>>> Cheers, >>>>>>>>>>>> Charles >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> On 4/20/15, 10:39 AM, "Charles Eckel >>>>>>>>>>>> (eckelcu)" >>>>>>>>>>>> wrote: >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>>> Hi Christer, >>>>>>>>>>>>> >>>>>>>>>>>>> I reread the current draft and went through the following >>>>>>>>>>>>> MMUSIC thread on this subject: >>>>>>>>>>>>> http://www.ietf.org/mail-archive/web/mmusic/current/msg14631. >>>>>>>>>>>>> h >>>>>>>>>>>>> t >>>>>>>>>>>>> m >>>>>>>>>>>>> l >>>>>>>>>>>>> >>>>>>>>>>>>> As a result, I better understand the issue you are addressing. >>>>>>>>>>>>> I suggest the following changes to be consistent with what >>>>>>>>>>>>> is being proposed in >>>>>>>>>>>>> MMUSIC: >>>>>>>>>>>>> >>>>>>>>>>>>> ------------ >>>>>>>>>>>>> Section 9: >>>>>>>>>>>>> >>>>>>>>>>>>> OLD: >>>>>>>>>>>>> Endpoints that use the offer/answer model to establish a DTLS >>>>>>>>>>>>> association MUST support the 'setup' attribute, as >>>>>>>>>>>>> defined in [7]. >>>>>>>>>>>>> When DTLS is used with UDP, the 'setup' attribute indicates >>>>>>>>>>>>> which of the endpoints (client or floor control server) >>>>>>>>>>>>> initiates the DTLS association setup. The requirements for >>>>>>>>>>>>> the offer/answer exchange specified in [13], Section 5 of >>>>>>>>>>>>> [13] MUST be followed when using DTLS. >>>>>>>>>>>>> Offer/answer considerations are described in Section 10.5. >>>>>>>>>>>>> >>>>>>>>>>>>> NEW: >>>>>>>>>>>>> When DTLS is used with UDP, the requirements specified in >>>>>>>>>>>>> Section >>>>>>>>>>>>> 5 of [13] MUST be followed. >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> Section 10.5 >>>>>>>>>>>>> >>>>>>>>>>>>> OLD >>>>>>>>>>>>> If the transport parameters or the key fingerprints >>>>>>>>>>>>> change, the >>>>>>>>>>>>> endpoints MUST establish a new DTLS connection. In >>>>>>>>>>>>> such case the >>>>>>>>>>>>> 'active/passive' status of the endpoints will again be >>>>>>>>>>>>> determined >>>>>>>>>>>>> following the procedures in [7], and the new status >>>>>>>>>>>>> will be used to >>>>>>>>>>>>> determine the TLS roles associated with the new DTLS >>>>>>>>>>>>> connection. >>>>>>>>>>>>> >>>>>>>>>>>>> Informational note: The procedure above is >>>>>>>>>>>>> identical to the one >>>>>>>>>>>>> defined for DTLS-SRTP in [13]. >>>>>>>>>>>>> >>>>>>>>>>>>> Note: A new DTLS connection needs to be established >>>>>>>>>>>>> if the >>>>>>>>>>>>> transport parameters or the key fingerprints change. >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> NEW: >>>>>>>>>>>>> The conditions under which endpoints MUST establish a new >>>>>>>>>>>>> DTLS connection are as the same defined for DTLS-SRTP in [13]. >>>>>>>>>>>>> ———————— >>>>>>>>>>>>> >>>>>>>>>>>>> This way we avoid any potential conflicts with the intent >>>>>>>>>>>>> of RFC 5763, and when clarifications to RFC 5763 are made, >>>>>>>>>>>>> they will be picked up by the BFCP spec. >>>>>>>>>>>>> >>>>>>>>>>>>> Cheers, >>>>>>>>>>>>> Charles >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> On 4/18/15, 2:01 PM, "Christer >>>>>>>>>>>>> Holmberg" >>>>>>>>>>>>> wrote: >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>>> Hi Charles, >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>>> [adding bfcppbis list] >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> Hi Christer, >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> Thanks for your review and comments. In the BFCP usage, >>>>>>>>>>>>>>> the DTLS connection is dedicated to the BFCP stream it contains. >>>>>>>>>>>>>>> As I understand it, the complications around DTLS >>>>>>>>>>>>>>> re-establishement discussed in MMUSIC result from use of >>>>>>>>>>>>>>> a single DTLS connection for multiple RTP and/or SCTP streams. >>>>>>>>>>>>>>> Those complications do not exist with the BFCP usage, so >>>>>>>>>>>>>>> I think it is sufficient to continue to reference RFC >>>>>>>>>>>>>>> 5763 and not use the SDP connection attribute. >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>> The complications do not result from use of a single DTLS >>>>>>>>>>>>>> connection for multiple streams - it mainly results from >>>>>>>>>>>>>> the usage of ICE. And, as far as I know, ICE can be used >>>>>>>>>>>>>> also for BFCP. >>>>>>>>>>>>>> >>>>>>>>>>>>>> And, even without ICE we intend to add text saying that a >>>>>>>>>>>>>> DTLS connection is only re-established if the underlying >>>>>>>>>>>>>> transport changes. >>>>>>>>>>>>>> >>>>>>>>>>>>>> Regards, >>>>>>>>>>>>>> >>>>>>>>>>>>>> Christer >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>>> Hi, >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> First, I want to apologize for not providing my review >>>>>>>>>>>>>>> earlier. >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> As far as the BFCP specifics are concerned, I am ok with >>>>>>>>>>>>>>> the latest version of the draft. >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> However, there is an issue regarding the DTLS >>>>>>>>>>>>>>> considerations (section 10.5). >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> The text says: >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> "Once a DTLS connection has been established, if the >>>>>>>>>>>>>>> 'active/passive' >>>>>>>>>>>>>>> status of the endpoints change during a session, a >>>>>>>>>>>>>>> new DTLS >>>>>>>>>>>>>>> connection MUST be established." >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> There is currently an ongoing discussion in MMUSIC about >>>>>>>>>>>>>>> when a DTLS connection is to be re-established. >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> The discussion is still ongoing, but the outcome will >>>>>>>>>>>>>>> most likely NOT be aligned with the text above. >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> For example, there has been a suggestion (by myself) to >>>>>>>>>>>>>>> use the SDP connection attribute to explicitly indicate >>>>>>>>>>>>>>> that a new DTLS connection needs to be established. >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> The draft also says: >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> "If the transport parameters or the key fingerprints >>>>>>>>>>>>>>> change, the >>>>>>>>>>>>>>> endpoints MUST establish a new DTLS connection." >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> This is related to the earlier issue. There is the >>>>>>>>>>>>>>> discussion about ICE "virtual connections", and that a >>>>>>>>>>>>>>> single DTLS connection would apply to all ICE candidates >>>>>>>>>>>>>>> associated with an >>>>>>>>>>>>>>> m- line. So, even if a candidate changes (read: transport >>>>>>>>>>>>>>> parameter changes), it would not automatically trigger a >>>>>>>>>>>>>>> new DTLS connection. >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> The issues above are also holding up the SCTP-SDP draft, >>>>>>>>>>>>>>> so it doesn't only affect BFCPbis :) >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> Regards, >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> Christer >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> -----Original Message----- >>>>>>>>>>>>>>> From: Alissa Cooper [mailto:alissa@cooperw.in] >>>>>>>>>>>>>>> Sent: 8. huhtikuuta 2015 3:07 >>>>>>>>>>>>>>> To: Charles Eckel (eckelcu) >>>>>>>>>>>>>>> Cc: Gonzalo Camarillo; Tom Kristensen (tomkrist); >>>>>>>>>>>>>>> draft-ietf-bfcpbis-rfc4582bis@tools.ietf.org; Ben >>>>>>>>>>>>>>> Campbell; Christer Holmberg >>>>>>>>>>>>>>> Subject: Re: draft-ietf-bfcpbis-rfc4583bis >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> Adding Christer to this thread. >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> On Apr 7, 2015, at 12:44 PM, Charles Eckel (eckelcu) >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> wrote: >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> Christer (cc’d) and I discussed some of the changes >>>>>>>>>>>>>>>> offlist in Dallas, and he is to come back to the list >>>>>>>>>>>>>>>> with comments after Dallas >>>>>>>>>>>>>>>> - which is now :) >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> Cheers, >>>>>>>>>>>>>>>> Charles >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> On 4/7/15, 10:26 AM, "Alissa Cooper" >>>>>>>>>>>>>>>> wrote: >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> Checking in on this — has Christer been prompted to >>>>>>>>>>>>>>>>> review the latest rev of draft-ietf-bfcpbis-rfc4583bis? >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> Thanks, >>>>>>>>>>>>>>>>> Alissa >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> On Feb 25, 2015, at 9:14 AM, Charles Eckel (eckelcu) >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> wrote: >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> Most of the changes I this recent update to rfc4583bis >>>>>>>>>>>>>>>>>> were inspired by comments and suggested text provided >>>>>>>>>>>>>>>>>> by Christer. >>>>>>>>>>>>>>>>>> He is in the process of reviewing. If all goes well >>>>>>>>>>>>>>>>>> with that, we are ready to proceed with proto writeup >>>>>>>>>>>>>>>>>> (Mary) and AD review. >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> Cheers, >>>>>>>>>>>>>>>>>> Charles >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> On 2/25/15, 7:01 AM, "Alissa >>>>>>>>>>>>>>>>>> Cooper" >>>>>>>>>>>>>>>>>> wrote: >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>> rfc4583 has not had an AD review yet. Richard can >>>>>>>>>>>>>>>>>>> hopefully take care of that while I¹m on leave >>>>>>>>>>>>>>>>>>> (starting today, actually). >>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>> On Feb 25, 2015, at 2:56 AM, Gonzalo Camarillo >>>>>>>>>>>>>>>>>>> wrote: >>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>> Hi Alissa, >>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>> I have noted that while rfc4582bis in on the agenda >>>>>>>>>>>>>>>>>>>> of the March 5th telechat (thanks for handling >>>>>>>>>>>>>>>>>>>> that!), rfc4583bis isn't. Tom revised rfc4583bis on >>>>>>>>>>>>>>>>>>>> February 20th. Should rfc4583bis be on the agenda of >>>>>>>>>>>>>>>>>>>> the telechat as well or there is still something >>>>>>>>>>>>>>>>>>>> left for Tom to take care of? >>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>> Thanks, >>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>> Gonzalo >>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>> On 18/02/2015 9:28 PM, Alissa Cooper wrote: >>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>> Pinging on this. >>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>> March 5 will likely be my last telechat before >>>>>>>>>>>>>>>>>>>>> going on leave, so it would be great to get this >>>>>>>>>>>>>>>>>>>>> scheduled on that one. To do that, the rev needs >>>>>>>>>>>>>>>>>>>>> to be posted today. >>>>>>>>>>>>>>>>>>>>> The updates are pretty minimal and are all >>>>>>>>>>>>>>>>>>>>> basically written up in Charles¹ response to my AD review. >>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>> Alissa >>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>> On Feb 15, 2015, at 9:13 AM, Gonzalo Camarillo >>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>>>>> wrote: >>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>> I have talked offline with the other authors and >>>>>>>>>>>>>>>>>>>>>> Tom is holding the pen. Tom, do you think you can >>>>>>>>>>>>>>>>>>>>>> meet the time frame below? >>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>> Cheers, >>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>> Gonzalo >>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>> Sent from my mobile >>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>> ---- Alissa Cooper wrote ---- >>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>> Just wanted to see if this rev might get done in >>>>>>>>>>>>>>>>>>>>>> the next couple of days. If so, we could get it >>>>>>>>>>>>>>>>>>>>>> on the next telechat agenda (March 5). >>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>> Alissa >>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>> Begin forwarded message: >>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>> *From: *Alissa Cooper>>>>>>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>>>>>>> *Subject: **Re: [bfcpbis] AD evaluation: >>>>>>>>>>>>>>>>>>>>>>> draft-ietf-bfcpbis-rfc4582bis-12* >>>>>>>>>>>>>>>>>>>>>>> *Date: *February 9, 2015 at 3:58:52 PM PST >>>>>>>>>>>>>>>>>>>>>>> *To: *"Charles Eckel (eckelcu)">>>>>>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>>>>>>> *Cc: *"bfcpbis@ietf.org" >>>>>>>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>> Hi Charles, >>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>> Thanks, some responses inline. >>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>> On Feb 4, 2015, at 10:40 AM, Charles Eckel (eckelcu) >>>>>>>>>>>>>>>>>>>>>>> > wrote: >>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>> HI Alissa, >>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>> Thank you for the review. Please see my thoughts >>>>>>>>>>>>>>>>>>>>>>>> on your comments and questions inline. >>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>> From: Alissa Cooper>>>>>>>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>>>>>>>> Date: Thursday, January 29, 2015 at 10:19 PM >>>>>>>>>>>>>>>>>>>>>>>> To: "bfcpbis@ietf.org" >>>>>>>>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>>>>>>>> Subject: [bfcpbis] AD evaluation: >>>>>>>>>>>>>>>>>>>>>>>> draft-ietf-bfcpbis-rfc4582bis-12 >>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>> I have reviewed this draft in preparation for IETF LC. >>>>>>>>>>>>>>>>>>>>>>>>> Overall the document appears in good shape. I >>>>>>>>>>>>>>>>>>>>>>>>> have a few questions and comments I¹d like to >>>>>>>>>>>>>>>>>>>>>>>>> discuss before issuing the IETF last call. I¹ve >>>>>>>>>>>>>>>>>>>>>>>>> also included some editorial nits that should >>>>>>>>>>>>>>>>>>>>>>>>> be addressed together with any last call comments. >>>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>> Comments and questions: >>>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>> = Section 5.1 = "If an endpoint receives a >>>>>>>>>>>>>>>>>>>>>>>>> message with an unsupported version field >>>>>>>>>>>>>>>>>>>>>>>>> value, the receiving server MUST send an Error >>>>>>>>>>>>>>>>>>>>>>>>> message with parameter value 12 (Unsupported >>>>>>>>>>>>>>>>>>>>>>>>> Version) to indicate this.² >>>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>> This seems a little misleading since RFC 4582 >>>>>>>>>>>>>>>>>>>>>>>>> didn¹t specify what to do upon receipt of a >>>>>>>>>>>>>>>>>>>>>>>>> message with a version other than 1. >>>>>>>>>>>>>>>>>>>>>>>>> Implementations that do not get upgraded to be >>>>>>>>>>>>>>>>>>>>>>>>> compliant with 4582bis (which could certainly >>>>>>>>>>>>>>>>>>>>>>>>> account for some of those that will not >>>>>>>>>>>>>>>>>>>>>>>>> support version 2) will therefore never send >>>>>>>>>>>>>>>>>>>>>>>>> the error specified here. >>>>>>>>>>>>>>>>>>>>>>>>> This seems like it should at least be noted >>>>>>>>>>>>>>>>>>>>>>>>> given the MUST-level requirement. The same >>>>>>>>>>>>>>>>>>>>>>>>> applies in Section 13.7. >>>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>> Good point. I believe we made this a MUST >>>>>>>>>>>>>>>>>>>>>>>> because we were thinking in terms of >>>>>>>>>>>>>>>>>>>>>>>> implementations compliant with this bis version. >>>>>>>>>>>>>>>>>>>>>>>> Adding >>>>>>>>>>>>>>>>>>>>>>>> your suggested note about rfc 4582 >>>>>>>>>>>>>>>>>>>>>>>> implementations here and in section 13.7 seems useful to me. >>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>> Ok >>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>> = Section 7 = >>>>>>>>>>>>>>>>>>>>>>>>> "BFCP entities MUST support, at a minimum, the >>>>>>>>>>>>>>>>>>>>>>>>> TLS_RSA_WITH_AES_128_CBC_SHA ciphersuite [6].² >>>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>> I realize this requirement comes from RFC 4582, >>>>>>>>>>>>>>>>>>>>>>>>> but I¹d like to understand why it has not been >>>>>>>>>>>>>>>>>>>>>>>>> updated to be consistent with more current >>>>>>>>>>>>>>>>>>>>>>>>> guidance on cipher suite selection (e.g., >>>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>> https://tools.ietf.org/html/draft-ietf-uta-tls- >>>>>>>>>>>>>>>>>>>>>>>>> bc >>>>>>>>>>>>>>>>>>>>>>>>> p >>>>>>>>>>>>>>>>>>>>>>>>> - >>>>>>>>>>>>>>>>>>>>>>>>> 0 >>>>>>>>>>>>>>>>>>>>>>>>> 8 >>>>>>>>>>>>>>>>>>>>>>>>> # >>>>>>>>>>>>>>>>>>>>>>>>> s >>>>>>>>>>>>>>>>>>>>>>>>> e >>>>>>>>>>>>>>>>>>>>>>>>> c >>>>>>>>>>>>>>>>>>>>>>>>> tion >>>>>>>>>>>>>>>>>>>>>>>>> -4) >>>>>>>>>>>>>>>>>>>>>>>>> . >>>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>> How about we keep this minimum requirement, and >>>>>>>>>>>>>>>>>>>>>>>> add a reference to draft-ietf-uta-tls-bcp along >>>>>>>>>>>>>>>>>>>>>>>> with a recommendation to adhere to the best >>>>>>>>>>>>>>>>>>>>>>>> practices it outlines in section 4? >>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>> I think MUST support TLS_RSA_WITH_AES_128_CBC_SHA >>>>>>>>>>>>>>>>>>>>>>> for backwards compatibility and SHOULD support >>>>>>>>>>>>>>>>>>>>>>> the ones listed in the UTA drafts would be ok. >>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>> = Sections 8, 8.1, 8.2 = It seems like the >>>>>>>>>>>>>>>>>>>>>>>>> transaction ID requirements regarding >>>>>>>>>>>>>>>>>>>>>>>>> non-reuse/monotonically increasing IDs are >>>>>>>>>>>>>>>>>>>>>>>>> re-stated multiple times across these three >>>>>>>>>>>>>>>>>>>>>>>>> sections, in slightly different ways, to the >>>>>>>>>>>>>>>>>>>>>>>>> point where it¹s not clear exactly what they are. >>>>>>>>>>>>>>>>>>>>>>>>> It seems like they are: >>>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>> (1) Reliable transport, server-initiated transaction: >>>>>>>>>>>>>>>>>>>>>>>>> ID is >>>>>>>>>>>>>>>>>>>>>>>>> 0 >>>>>>>>>>>>>>>>>>>>>>>>> (2) Unreliable transport, server-initiated >>>>>>>>>>>>>>>>>>>>>>>>> transaction: >>>>>>>>>>>>>>>>>>>>>>>>> ID MUST be monotonically increasing (except for >>>>>>>>>>>>>>>>>>>>>>>>> wrap-around) >>>>>>>>>>>>>>>>>>>>>>>>> (3) Reliable transport, client-initiated transaction: >>>>>>>>>>>>>>>>>>>>>>>>> ID MUST NOT be 0 and MUST NOT be reused in >>>>>>>>>>>>>>>>>>>>>>>>> another message from the client until a >>>>>>>>>>>>>>>>>>>>>>>>> response >>>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>> >from the server is received for the >>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>> transaction, >>>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>> but need not be monotonically increasing (e.g., >>>>>>>>>>>>>>>>>>>>>>>>> a lower, recently used ID could be re-used once >>>>>>>>>>>>>>>>>>>>>>>>> a response is >>>>>>>>>>>>>>>>>>>>>>>>> received) >>>>>>>>>>>>>>>>>>>>>>>>> (4) Unreliable transport, client-initiated >>>>>>>>>>>>>>>>>>>>>>>>> transaction: >>>>>>>>>>>>>>>>>>>>>>>>> ID MUST be monotonically increasing (except for >>>>>>>>>>>>>>>>>>>>>>>>> wrap-around) >>>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>> Is (3) the correct interpretation of the text in 8.1? >>>>>>>>>>>>>>>>>>>>>>>>> If so, why not just require IDs in all >>>>>>>>>>>>>>>>>>>>>>>>> client-initiated transactions to be >>>>>>>>>>>>>>>>>>>>>>>>> monotonically increasing? >>>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>> Agree we can and should simplify this. Sections >>>>>>>>>>>>>>>>>>>>>>>> 8.1 and >>>>>>>>>>>>>>>>>>>>>>>> 8.2 cover the client behavior and server >>>>>>>>>>>>>>>>>>>>>>>> behavior in detail. As such, the transaction ID >>>>>>>>>>>>>>>>>>>>>>>> related information at the start of Section 8 is superfluous. >>>>>>>>>>>>>>>>>>>>>>>> I recommend reducing the text in Section 8 to >>>>>>>>>>>>>>>>>>>>>>>> the >>>>>>>>>>>>>>>>>>>>>>>> follow: >>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>> 8. Protocol Transactions >>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>> In BFCP, there are two types of transactions: >>>>>>>>>>>>>>>>>>>>>>>> client-initiated transactions and >>>>>>>>>>>>>>>>>>>>>>>> server-initiated transactions. >>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>> Client-initiated transactions consist of a >>>>>>>>>>>>>>>>>>>>>>>> request from a client to a floor control server >>>>>>>>>>>>>>>>>>>>>>>> and a response from the floor control server to the client. >>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>> Server-initiated transactions have different >>>>>>>>>>>>>>>>>>>>>>>> behavior depending on underlying transport: >>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>> When using a reliable transport, >>>>>>>>>>>>>>>>>>>>>>>> server-initiated transactions >>>>>>>>>>>>>>>>>>>>>>>> consist of a single message from a floor >>>>>>>>>>>>>>>>>>>>>>>> control server to a >>>>>>>>>>>>>>>>>>>>>>>> client (notifications). They do not >>>>>>>>>>>>>>>>>>>>>>>> trigger any response. >>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>> When using an unreliable transport, >>>>>>>>>>>>>>>>>>>>>>>> server-initiated transactions >>>>>>>>>>>>>>>>>>>>>>>> consist of a request from a floor control >>>>>>>>>>>>>>>>>>>>>>>> server to a client and a >>>>>>>>>>>>>>>>>>>>>>>> response from the client to the floor >>>>>>>>>>>>>>>>>>>>>>>> control server. >>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>> When using BFCP over an unreliable transport, >>>>>>>>>>>>>>>>>>>>>>>> retransmission timer T1 (see Section 8.3) MUST >>>>>>>>>>>>>>>>>>>>>>>> be used for all requests until the transaction >>>>>>>>>>>>>>>>>>>>>>>> is completed. >>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>> Then in section 8.1, we add the important >>>>>>>>>>>>>>>>>>>>>>>> details removed from section 8. >>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>> 8.1.1 Client Behavior >>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>> A client starting a client-initiated transaction >>>>>>>>>>>>>>>>>>>>>>>> MUST set the Conference ID in the common header >>>>>>>>>>>>>>>>>>>>>>>> of the message to the Conference ID for the >>>>>>>>>>>>>>>>>>>>>>>> conference that the client obtained previously. >>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>> The client MUST set the Transaction ID value in >>>>>>>>>>>>>>>>>>>>>>>> the common header to a number that is different >>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>> >from 0 and that MUST NOT be reused in another >>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>> message from the client until a response from >>>>>>>>>>>>>>>>>>>>>>>> the server is received for the transaction. >>>>>>>>>>>>>>>>>>>>>>>> The client uses the Transaction ID value to >>>>>>>>>>>>>>>>>>>>>>>> match this message with the response from the >>>>>>>>>>>>>>>>>>>>>>>> floor control server. >>>>>>>>>>>>>>>>>>>>>>>> When using BFCP over an unreliable transport, it >>>>>>>>>>>>>>>>>>>>>>>> is important to choose a Transaction ID value >>>>>>>>>>>>>>>>>>>>>>>> that lets the receiver distinguish the reception >>>>>>>>>>>>>>>>>>>>>>>> of the next message in a sequence of BFCP >>>>>>>>>>>>>>>>>>>>>>>> messages from a retransmission of a previous >>>>>>>>>>>>>>>>>>>>>>>> message. Therefore, BFCP entities using an >>>>>>>>>>>>>>>>>>>>>>>> unreliable transport MUST use monotonically >>>>>>>>>>>>>>>>>>>>>>>> increasing Transaction ID values (except for wrap-around). >>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>> A client receiving a server-initiated >>>>>>>>>>>>>>>>>>>>>>>> transaction over an unreliable transport MUST >>>>>>>>>>>>>>>>>>>>>>>> copy the Transaction ID from the request >>>>>>>>>>>>>>>>>>>>>>>> received from the server into the response. >>>>>>>>>>>>>>>>>>>>>>>> [Question: is there a need to copy the >>>>>>>>>>>>>>>>>>>>>>>> Conference ID and User ID, if present?] >>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>> 8.2. Server Behavior >>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>> A floor control server sending a response within >>>>>>>>>>>>>>>>>>>>>>>> a client-initiated transaction MUST copy the >>>>>>>>>>>>>>>>>>>>>>>> Conference ID, the Transaction ID, and the User >>>>>>>>>>>>>>>>>>>>>>>> ID >>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>> >from the request received from the client into >>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>> the >>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>> response. >>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>> Server-initiated transactions MUST contain a >>>>>>>>>>>>>>>>>>>>>>>> Transaction ID equal to >>>>>>>>>>>>>>>>>>>>>>>> 0 when BFCP is used over a reliable transport. >>>>>>>>>>>>>>>>>>>>>>>> Over an unreliable transport, the Transaction ID >>>>>>>>>>>>>>>>>>>>>>>> shall have the same properties as for >>>>>>>>>>>>>>>>>>>>>>>> client-initiated transactions. >>>>>>>>>>>>>>>>>>>>>>>> The server uses the Transaction ID value to >>>>>>>>>>>>>>>>>>>>>>>> match this message with the response from the >>>>>>>>>>>>>>>>>>>>>>>> floor participant or floor chair. >>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>> Thanks, this is better. >>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>> = Section 9 (impacts Section 14 as well) = >>>>>>>>>>>>>>>>>>>>>>>>> "BFCP clients SHOULD authenticate the floor >>>>>>>>>>>>>>>>>>>>>>>>> control server before sending any BFCP message >>>>>>>>>>>>>>>>>>>>>>>>> to it or accepting any BFCP message from it. >>>>>>>>>>>>>>>>>>>>>>>>> Similarly, floor control servers SHOULD >>>>>>>>>>>>>>>>>>>>>>>>> authenticate a client before accepting any BFCP >>>>>>>>>>>>>>>>>>>>>>>>> message from it or sending any BFCP message to it. >>>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>> BFCP supports TLS/DTLS mutual authentication >>>>>>>>>>>>>>>>>>>>>>>>> between clients and floor control servers, as >>>>>>>>>>>>>>>>>>>>>>>>> specified in Section 9.1. >>>>>>>>>>>>>>>>>>>>>>>>> This is the RECOMMENDED authentication >>>>>>>>>>>>>>>>>>>>>>>>> mechanism in BFCP.² >>>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>> What are the cases where clients and servers do >>>>>>>>>>>>>>>>>>>>>>>>> not need to be authenticating each other? I >>>>>>>>>>>>>>>>>>>>>>>>> know this requirement and the other >>>>>>>>>>>>>>>>>>>>>>>>> SHOULD-level requirements around use of >>>>>>>>>>>>>>>>>>>>>>>>> TLS/DTLS are carried over from RFC 4582, but >>>>>>>>>>>>>>>>>>>>>>>>> I¹m concerned that they aren¹t as strong as they should be. >>>>>>>>>>>>>>>>>>>>>>>>> For a conference where the signaling traffic is >>>>>>>>>>>>>>>>>>>>>>>>> authenticated and confidentiality and integrity >>>>>>>>>>>>>>>>>>>>>>>>> protected, why is it ok for the floor control >>>>>>>>>>>>>>>>>>>>>>>>> traffic not to be? Could these requirements be >>>>>>>>>>>>>>>>>>>>>>>>> adjusted to require use of TLS/DTLS at least in >>>>>>>>>>>>>>>>>>>>>>>>> cases where the signaling is also protected? >>>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>> Yes, but again, this would be at the expense of >>>>>>>>>>>>>>>>>>>>>>>> adding a non backward compatible change from rfc >>>>>>>>>>>>>>>>>>>>>>>> 4582. How about saying TLS/DTLS MUST be used for >>>>>>>>>>>>>>>>>>>>>>>> BFCP in such cases, while pointing out the rfc >>>>>>>>>>>>>>>>>>>>>>>> 4582 >>>>>>>>>>>>>>>>>>>>>>>> based implementations may not comply (similar to >>>>>>>>>>>>>>>>>>>>>>>> what we did with the version field). >>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>> Works for me. >>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>> Feel free to make all of these changes and submit >>>>>>>>>>>>>>>>>>>>>>> a rev and I¹ll issue the IETF LC. >>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>> Thanks, >>>>>>>>>>>>>>>>>>>>>>> Alissa >>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>> = Section 14 = >>>>>>>>>>>>>>>>>>>>>>>>> See the point above about ciphersuites. >>>>>>>>>>>>>>>>>>>>>>>>> ³Non-null encryption² is not a sufficient >>>>>>>>>>>>>>>>>>>>>>>>> minimum baseline, and if the requirements >>>>>>>>>>>>>>>>>>>>>>>>> change in Section 7 they should be reflected here as well. >>>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>> Yep. >>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>> Editorial nits to be resolved with LC comments: >>>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>> = Section 5.1 = ³The version field MUST be set >>>>>>>>>>>>>>>>>>>>>>>>> to 1 when using BFCP over a reliable transport, >>>>>>>>>>>>>>>>>>>>>>>>> i.e. as in [2].² >>>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>> I find it a little odd to reference the spec >>>>>>>>>>>>>>>>>>>>>>>>> you¹re obsoleting in this sentence, especially >>>>>>>>>>>>>>>>>>>>>>>>> since BFCP over a reliable transport is >>>>>>>>>>>>>>>>>>>>>>>>> completely specified in this bis document. I >>>>>>>>>>>>>>>>>>>>>>>>> would suggest dropping >>>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>> >>> the i.e. >>> >>> >>>>>>>>>>>>>>>>>>>>>>>>> clause. >>>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>> Good catch. This is a carry over from before >>>>>>>>>>>>>>>>>>>>>>>> this draft was adopted as a bis version of rfc4582. >>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>> "The version field MUST be set to 2 when using >>>>>>>>>>>>>>>>>>>>>>>>> BFCP over an unreliable transport with the >>>>>>>>>>>>>>>>>>>>>>>>> extensions specified in this document.² >>>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>> The bit about ³with the extensions specified in >>>>>>>>>>>>>>>>>>>>>>>>> this document² is extraneous and should be removed. >>>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>> "If an endpoint receives a message with an >>>>>>>>>>>>>>>>>>>>>>>>> unsupported version field value, the receiving >>>>>>>>>>>>>>>>>>>>>>>>> server MUST send an Error message with >>>>>>>>>>>>>>>>>>>>>>>>> parameter value 12 (Unsupported >>>>>>>>>>>>>>>>>>>>>>>>> Version) to indicate this.² >>>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>> Use of the word ³server² here makes it sound as >>>>>>>>>>>>>>>>>>>>>>>>> if only servers could receive headers with >>>>>>>>>>>>>>>>>>>>>>>>> unsupported versions. >>>>>>>>>>>>>>>>>>>>>>>>> Should this be ³the receiving endpoint²? >>>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>> = Section 6.2.4 = "[23], Section 6.7 provides >>>>>>>>>>>>>>>>>>>>>>>>> useful recommendations Š² >>>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>> The links in the references are not quite right. >>>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>> = Section 8.3.2 = s/when fires/when fired/ >>>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>> = Section 14 = >>>>>>>>>>>>>>>>>>>>>>>>> s/high-jack/hijack/ >>>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>> = Section B.1 = "situation where multiple >>>>>>>>>>>>>>>>>>>>>>>>> different and non-interoperable would >>>>>>>>>>>>>>>>>>>>>>>>> co- >>>>>>>>>>>>>>>>>>>>>>>>> exist in the market.² >>>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>> There is a word missing after ³non-interoperable." >>>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>> This should read ³non-interoperable implementations². >>>>>>>>>>>>>>>>>>>>>>>> Earlier in that same sentence, ³BFCP over UDP >>>>>>>>>>>>>>>>>>>>>>>> were already used² should read ³BFCP over UDP is >>>>>>>>>>>>>>>>>>>>>>>> already being used². >>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>> Cheers, >>>>>>>>>>>>>>>>>>>>>>>> Charles >>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>> _______________________________________________ >>>>>>>>>>>>>>>>>>>>>>> bfcpbis mailing list >>>>>>>>>>>>>>>>>>>>>>> bfcpbis@ietf.org >>>>>>>>>>>>>>>>>>>>>>> https://www.ietf.org/mailman/listinfo/bfcpbis >>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>> _______________________________________________ >>>>>>>>> bfcpbis mailing list >>>>>>>>> bfcpbis@ietf.org >>>>>>>>> https://www.ietf.org/mailman/listinfo/bfcpbis >>>>>>>>> >>>>>>>>> >>>>>>>> >>>>>>>> >>>>>>> >>>>>>> >>>>>> >>>>>> >>>>> >>>>> >>>> _______________________________________________ >>>> bfcpbis mailing list >>>> bfcpbis@ietf.org >>>> https://www.ietf.org/mailman/listinfo/bfcpbis >>>> >>>> >>> >>> >> > From nobody Tue Nov 3 05:58:12 2015 Return-Path: X-Original-To: bfcpbis@ietfa.amsl.com Delivered-To: bfcpbis@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2A2951A00B4 for ; Tue, 3 Nov 2015 05:58:09 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.201 X-Spam-Level: X-Spam-Status: No, score=-4.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, 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 hSA9rMJQgHFx for ; Tue, 3 Nov 2015 05:57:58 -0800 (PST) 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 EB1EF1A000F for ; Tue, 3 Nov 2015 05:57:55 -0800 (PST) X-AuditID: c1b4fb25-f79a26d00000149a-7b-5638bd61c37b Received: from ESESSHC021.ericsson.se (Unknown_Domain [153.88.183.81]) by sesbmg23.ericsson.net (Symantec Mail Security) with SMTP id 6D.EE.05274.16DB8365; Tue, 3 Nov 2015 14:57:54 +0100 (CET) Received: from ESESSMB209.ericsson.se ([169.254.9.202]) by ESESSHC021.ericsson.se ([153.88.183.81]) with mapi id 14.03.0248.002; Tue, 3 Nov 2015 14:57:19 +0100 From: Christer Holmberg To: Tom Kristensen Thread-Topic: Status update on draft-ietf-mmusic-dtls-sdp [was: [bfcpbis] draft-ietf-bfcpbis-rfc4583bis] Thread-Index: AQHRFhEr5RAE6iT9yEeonJGC51Bbm56KUnWQ Date: Tue, 3 Nov 2015 13:57:19 +0000 Message-ID: <7594FB04B1934943A5C02806D1A2204B37BD2F52@ESESSMB209.ericsson.se> References: <7594FB04B1934943A5C02806D1A2204B37BC8F7B@ESESSMB209.ericsson.se> <56371495.7080105@cisco.com> <7594FB04B1934943A5C02806D1A2204B37BCD730@ESESSMB209.ericsson.se> <56386F6A.9040200@cisco.com> In-Reply-To: <56386F6A.9040200@cisco.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: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFlrNIsWRmVeSWpSXmKPExsUyM2J7oG7SXoswg6mzOS2mn/nLaDG/8zS7 xb91R5ksbq2/zWKxadYXNosrR36xObB5TPm9kdXjy5OXTB5Llvxk8pi18wmLx5fLn9kCWKO4 bFJSczLLUov07RK4Mk4ufMtS8GMHS8Xk3fNZGxjXrGLpYuTkkBAwkXg0fymULSZx4d56ti5G Lg4hgcOMEkce32SHcBYzStz8fwzI4eBgE7CQ6P6nDdIgIqAu0bf3O1gNs8A2Joknyy6wgtQI C2RKbLxZCFGTJdE4eyobhG0ksfXoaUYQm0VARaL//mUmEJtXwFfi3+9P7CC2kMAnRond1wNB bE4BTYlzj+eA1TMCHff91BqwemYBcYlbT+YzQRwtILFkz3lmCFtU4uXjf6wQtpLE2sPbWUDO YQaas36XPkSrosSU7ofsEGsFJU7OfMIygVFsFpKpsxA6ZiHpmIWkYwEjyypG0eLU4qTcdCNj vdSizOTi4vw8vbzUkk2MwCg8uOW36g7Gy28cDzEKcDAq8fBu2GQeJsSaWFZcmXuIUYKDWUmE l2WnRZgQb0piZVVqUX58UWlOavEhRmkOFiVx3mamB6FCAumJJanZqakFqUUwWSYOTqkGxomf VzG4TH/2UHRjyEp/f5V+i50XV23pnlQkXqi5zyxLms/4mv/mnKmcy1OZlRYunh1WopX8aPvT Ss1ih8kyltZZV5orOD/vcjhouFDh8GGWAzu5Pr80FDH0/Zv9cdqBr2++3Eo6fdHfeyXnI4WF ZfuU8zsXTvsUMdf101TWA4n3Tt9+qhli5aHEUpyRaKjFXFScCAATz0REvgIAAA== Archived-At: Cc: Ben Campbell , "bfcpbis@ietf.org" , Alissa Cooper , "Charles Eckel \(eckelcu\)" , Gonzalo Camarillo , "draft-ietf-bfcpbis-rfc4582bis@tools.ietf.org" Subject: Re: [bfcpbis] Status update on draft-ietf-mmusic-dtls-sdp [was: draft-ietf-bfcpbis-rfc4583bis] X-BeenThere: bfcpbis@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: BFCPBIS working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 Nov 2015 13:58:09 -0000 SGksDQoNCj5JIGhhdmUgdG8gc3R1ZHkgdGhlIGxhdGVzdCB2ZXJzaW9uIG9mIGRyYWZ0LWlldGYt bW11c2ljLWR0bHMtc2RwIHRvIA0KPnRlbGwsIGJ1dCBhcyBvZiBrbm93IEkgdGhpbmsgd2UgbWF5 IG5lZWQgYSBuZXcgc2VjdGlvbiBzaW1pbGFyIHRvICI4LjEuICANCj5UQ1AgQ29ubmVjdGlvbiBN YW5hZ2VtZW50IiBmb3IgRFRMUy9VRFAsIHdoZXJlIGFtb25nc3Qgb3RoZXIgdGhpbmdzIHRoZSAN Cj4nZHRscy1jb25uZWN0aW9uJyB3aWxsIGJlIG1lbnRpb25lZC4NCg0KVGhlIGlzc3VlIGlzIHRo YXQgdGhlIHRleHQgd2UgYWdyZWVkIHVwb24gdGFsa3MgYWJvdXQgImNsYXJpZmljYXRpb25zIi4g DQoNCkJ1dCwgZHJhZnQtZHRscy1zZHAgaXMgbW9yZSB0aGFuIGNsYXJpZmljYXRpb25zIC0gaXQg aXMgYWxzbyBuZXcgc3R1ZmYgKGUuZy4gdGhlICdkdGxzLWNvbm5lY3Rpb24nIGF0dHJpYnV0ZSkg LSBzbyBpdCBuZWVkcyB0byBiZSBjbGVhciB3aGV0aGVyIHRoYXQgaXMgaW5jbHVkZWQgb3Igbm90 Lg0KDQpSZWdhcmRzLA0KDQpDaHJpc3Rlcg0KIA0KDQpPbiAxMS8wMi8yMDE1IDExOjM5IEFNLCBD aHJpc3RlciBIb2xtYmVyZyB3cm90ZToNCj4gSnVzdCBhIHF1ZXN0aW9uIGZvciBjbGFyaWZpY2F0 aW9uOiB3aWxsIHRoZSBkcmFmdCBub3cgYWRvcHQgdGhlICdkdGxzLWNvbm5lY3Rpb24nIGF0dHJp YnV0ZSBkZWZpbmVkIGluIHRoZSBEVExTLVNEUCBkcmFmdD8NCj4NCj4gUmVnYXJkcywNCj4NCj4g Q2hyaXN0ZXINCj4NCj4gLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCj4gRnJvbTogQ2hhcmxl cyBFY2tlbCAoZWNrZWxjdSkgW21haWx0bzplY2tlbGN1QGNpc2NvLmNvbV0NCj4gU2VudDogMDIg Tm92ZW1iZXIgMjAxNSAxMDoyNg0KPiBUbzogVG9tIEtyaXN0ZW5zZW4gKHRvbWtyaXN0KTx0b21r cmlzdEBjaXNjby5jb20+OyBDaHJpc3RlciBIb2xtYmVyZzxjaHJpc3Rlci5ob2xtYmVyZ0Blcmlj c3Nvbi5jb20+DQo+IENjOiBBbGlzc2EgQ29vcGVyPGFsaXNzYUBjb29wZXJ3LmluPjsgYmZjcGJp c0BpZXRmLm9yZzsgZHJhZnQtaWV0Zi1iZmNwYmlzLXJmYzQ1ODJiaXNAdG9vbHMuaWV0Zi5vcmc7 IEdvbnphbG8gQ2FtYXJpbGxvPGdvbnphbG8uY2FtYXJpbGxvQGVyaWNzc29uLmNvbT47IEJlbiBD YW1wYmVsbDxiZW5Abm9zdHJ1bS5jb20+DQo+IFN1YmplY3Q6IFJlOiBTdGF0dXMgdXBkYXRlIG9u IGRyYWZ0LWlldGYtbW11c2ljLWR0bHMtc2RwIFt3YXM6IFtiZmNwYmlzXSBkcmFmdC1pZXRmLWJm Y3BiaXMtcmZjNDU4M2Jpc10NCj4NCj4gR3JlYXQsIHRoYW5rcyBUb20uIEkgbG9vayBmb3J3YXJk IHRvIHNlZWluZyB0aGUgdXBkYXRlIHBvc3RlZCBiZWZvcmUgdGhlIGVuZCBvZiB0aGlzIHdlZWsu DQo+DQo+IENoZWVycywNCj4gQ2hhcmxlcw0KPg0KPiBPbiAxMS8yLzE1LCA0OjQ1IFBNLCAiVG9t IEtyaXN0ZW5zZW4gKHRvbWtyaXN0KSI8dG9ta3Jpc3RAY2lzY28uY29tPg0KPiB3cm90ZToNCj4N Cj4gICAgDQo+PiBQZXJmZWN0ISBJJ2xsIHVwZGF0ZSBhbmQgcG9saXNoIHRoZSBkcmFmdCBhcyBk aXNjdXNzZWQgYW5kIGFncmVlZCB1cG9uDQo+PiBiZWxvdyBhbmQgc3VibWl0Lg0KPj4NCj4+IC0t IFRvbQ0KPj4NCj4+IE9uIDExLzAyLzIwMTUgMDg6MDQgQU0sIENocmlzdGVyIEhvbG1iZXJnIHdy b3RlOg0KPj4gICAgICANCj4+PiBIaSwNCj4+Pg0KPj4+IGRyYWZ0LWlldGYtbW11c2ljLWR0bHMt c2RwIHdhcyBkaXNjdXNzZWQgYXQgTU1VU0lDIHRvZGF5Lg0KPj4+DQo+Pj4gQXQgdGhpcyBtb21l bnQgdGhlcmUgYXJlIG5vIHRlY2huaWNhbCBvcGVuIGlzc3Vlcy4gVGhlIHBsYW4gaXMgdG8gYWRk DQo+Pj4gc29tZSBlZGl0b3JpYWwgd29yaywgYmFzZWQgb24gY29tbWVudHMgcmVjZWl2ZWQgZHVy aW5nIHRoZSBzZXNzaW9uLA0KPj4+IGFuZCB0aGUgYWRkIHRleHQgcmVnYXJkaW5nIERUTFMtdXNh Z2UgZHJhZnRzL3NwZWNzIHRoYXQgdGhlIGRyYWZ0IHVwZGF0ZXMuDQo+Pj4gQWZ0ZXIgdGhhdCwg dW5sZXNzIHNvbWV0aGluZyB1bmV4cGVjdGVkIGNvbWVzIHVwLCB0aGUgZHJhZnQgc2hvdWxkIGJl DQo+Pj4gcmVhZHkgZm9yIFdHTEMuDQo+Pj4NCj4+PiBSZWdhcmRzLA0KPj4+DQo+Pj4gQ2hyaXN0 ZXINCj4+Pg0KPj4+DQo+Pj4NCj4+PiAtLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KPj4+IEZy b206IENoYXJsZXMgRWNrZWwgKGVja2VsY3UpIFttYWlsdG86ZWNrZWxjdUBjaXNjby5jb21dDQo+ Pj4gU2VudDogMjggU2VwdGVtYmVyIDIwMTUgMTg6NTANCj4+PiBUbzogQ2hyaXN0ZXIgSG9sbWJl cmc8Y2hyaXN0ZXIuaG9sbWJlcmdAZXJpY3Nzb24uY29tPjsgVG9tIEtyaXN0ZW5zZW4NCj4+PiAo dG9ta3Jpc3QpPHRvbWtyaXN0QGNpc2NvLmNvbT4NCj4+PiBDYzogQWxpc3NhIENvb3BlcjxhbGlz c2FAY29vcGVydy5pbj47IGJmY3BiaXNAaWV0Zi5vcmc7DQo+Pj4gZHJhZnQtaWV0Zi1iZmNwYmlz LXJmYzQ1ODJiaXNAdG9vbHMuaWV0Zi5vcmc7IEdvbnphbG8NCj4+PiBDYW1hcmlsbG88Z29uemFs by5jYW1hcmlsbG9AZXJpY3Nzb24uY29tPjsgQmVuDQo+Pj4gQ2FtcGJlbGw8YmVuQG5vc3RydW0u Y29tPg0KPj4+IFN1YmplY3Q6IFJlOiBbYmZjcGJpc10gZHJhZnQtaWV0Zi1iZmNwYmlzLXJmYzQ1 ODNiaXMNCj4+Pg0KPj4+IFRoYW5rcyBDaHJpc3Rlci4NCj4+Pg0KPj4+IFRvbSwgY2FuIHlvdSBw bGVhc2UgcG9zdCB0aGUgY29ycmVzcG9uZGluZyB1cGRhdGUgdG8gdGhlIGRyYWZ0Pw0KPj4+DQo+ Pj4gQ2hlZXJzLA0KPj4+IENoYXJsZXMNCj4+Pg0KPj4+IE9uIDkvMjgvMTUsIDM6MDcgQU0sICJi ZmNwYmlzIG9uIGJlaGFsZiBvZiBDaHJpc3RlciBIb2xtYmVyZyINCj4+PiA8YmZjcGJpcy1ib3Vu Y2VzQGlldGYub3JnIG9uIGJlaGFsZiBvZg0KPj4+IGNocmlzdGVyLmhvbG1iZXJnQGVyaWNzc29u LmNvbT4NCj4+PiB3cm90ZToNCj4+Pg0KPj4+DQo+Pj4gICAgICAgIA0KPj4+PiBIaSwNCj4+Pj4N Cj4+Pj4NCj4+Pj4gICAgICAgICAgDQo+Pj4+PiBJbiB0aGF0IGNhc2UsIEkgcHJlZmVyIFRvbeKA mXMgb3JpZ2luYWwgc3VnZ2VzdGlvbiwNCj4+Pj4+DQo+Pj4+PiAgICBXaGF0IGlmIHdlIGtlZXAg dGhlIHRleHQgYW5kIGFkZHMgdGhpcyBhcyBhbiBhZGRpdGlvbmFsIHJlZmVyZW5jZQ0KPj4+Pj4g aW4gdGhlIHR3byBuZXcgdGV4dCBwYXNzYWdlcyBwcm9wb3NlZCBieSBDaGFybGVzOiAiLi4uIFsx M10sIGFuZA0KPj4+Pj4gdGhlIGNsYXJpZmljYXRpb25zIGRlZmluZWQgaW4gW2RyYWZ0LWlldGYt bW11c2ljLWR0bHMtc2RwXSwgLi4uIi4NCj4+Pj4+DQo+Pj4+PiAgICBXaGVyZSBbMTNdIGlzIGEg cmVmZXJlbmNlIHRvIFJGQyA1NzYzLg0KPj4+Pj4NCj4+Pj4+ICAgICAgICAgICAgDQo+Pj4+IElm IHRoYXQncyBzb21ldGhpbmcgcGVvcGxlIGNhbiBhZ3JlZSB0bywgdGhlbiBjYW4gbGl2ZSB3aXRo IHN1Y2gNCj4+Pj4gY29tcHJvbWlzZSA6KQ0KPj4+Pg0KPj4+PiBSZWdhcmRzLA0KPj4+Pg0KPj4+ PiBDaHJpc3Rlcg0KPj4+Pg0KPj4+Pg0KPj4+Pg0KPj4+Pg0KPj4+Pg0KPj4+PiBJZiBpdCB0dXJu cyBvdXQgdGhhdCBkcmFmdC1pZXRmLW1tdXNpYy1kdGxzLXNkcCB1cGRhdGVzIFJGQyA1NzYzLA0K Pj4+PiB0aGVuICB0aGVyZSBpcyBzb21lIHJlZHVuZGFuY3kuIEJ1dCB0aGF0IGlzIGJldHRlciB0 aGFuIGhhdmluZyBhIGhvbGUNCj4+Pj4gd2hlbiBpdCAgY29tZXMgdG8gYmFja3dhcmQgY29tcGF0 aWJpbGl0eSB3aXRoIGV4aXN0aW5nDQo+Pj4+IGltcGxlbWVudGF0aW9ucywgd2hpY2ggaXMgIHdo YXQgd2Ugd2lsbCBoYXZlIHRvZGF5IGlmIHdlIHJlZmVyZW5jZQ0KPj4+PiBkcmFmdC1pZXRmLW1t dXNpYy1kdGxzLXNkcCBvbmx5Lg0KPj4+Pg0KPj4+PiBDaGVlcnMsDQo+Pj4+IENoYXJsZXMNCj4+ Pj4NCj4+Pj4NCj4+Pj4NCj4+Pj4gT24gOS8yNS8xNSwgMjoyMSBBTSwgIkNocmlzdGVyIEhvbG1i ZXJnIg0KPj4+PiA8Y2hyaXN0ZXIuaG9sbWJlcmdAZXJpY3Nzb24uY29tPg0KPj4+PiB3cm90ZToN Cj4+Pj4NCj4+Pj4NCj4+Pj4gICAgICAgICAgDQo+Pj4+PiBIaSBDaGFybGVzLA0KPj4+Pj4NCj4+ Pj4+DQo+Pj4+PiAgICAgICAgICAgIA0KPj4+Pj4+IEFzIGEgc2ltcGxlIGV4YW1wbGUsIHdlIGN1 cnJlbnRseSByZWZlciB0byByZmM0NTgyYmlzIGluc3RlYWQgb2YNCj4+Pj4+PiB0aGUgZXZlbnR1 YWwgUkZDLiBBc3N1bWluZyByZmM0NTgyYmlzIGRvZXMgYmVjb21lIGFuIFJGQywgd2Ugd291bGQN Cj4+Pj4+PiB3YW50IHRoZSBSRkMgZWRpdG9yIHRvIHVwZGF0ZSByZWZlcmVuY2VzIHRvIGl0IGFu ZCB0byBSRkN4eHh4IHdpdGgNCj4+Pj4+PiB0aGUgYWN0dWFsIFJGQyBudW1iZXIuDQo+Pj4+Pj4g U2ltaWxhciBoZXJlLCB3ZSB3b3VsZCB3YW50IHRoZW0gdG8gY2hlY2sgd2l0aCBhdXRob3JzL2No YWlycy9BRHMNCj4+Pj4+PiBvbiB0aGUgc3RhdGUgb2YgZHJhZnQtaWV0Zi1tbXVzaWMtZHRscy1z ZHAgdG8gc2VlIGlmIHdlIHdhbnQgdG8NCj4+Pj4+PiByZXBsYWNlIG91ciByZWZlcmVuY2UgdG8g UkZDIDU3NjMgd2l0aCBhIHJlZmVyZW5jZSB0byBpdC4gVGhpcyB3YXkNCj4+Pj4+PiB3ZSBjYW4g bW92ZSBmb3J3YXJkIHdoaWxlIGRyYWZ0LWlldGYtbW11c2ljLWR0bHMtc2RwIGNvbnRpbnVlcyB0 bw0KPj4+Pj4+IHByb2dyZXNzIGFzIHdlbGwuDQo+Pj4+Pj4NCj4+Pj4+PiAgICAgICAgICAgICAg DQo+Pj4+PiBJIGRvbid0IHRoaW5rIGl0J3MgdGhlIHNhbWUgdGhpbmcuIEZpcnN0IHlvdSB0YWxr IGFib3V0IGEgZHJhZnQsDQo+Pj4+PiB3aGVyZSB0aGUgZHJhZnQgbmFtZSB3aWxsIGJlIHJlcGxh Y2VkIHdpdGggdGhlIHRvLWJlLWFzc2lnbmVkIFJGQw0KPj4+Pj4gbnVtYmVyLiBJbiB0aGUgY2Fz ZSBvZiBEVExTLVNEUCB3ZSBhcmUgdGFsa2luZyBhYm91dCB0d28gc2VwYXJhdGUgc3BlY2lmaWNh dGlvbnMuDQo+Pj4+Pg0KPj4+Pj4gUmVnYXJkcywNCj4+Pj4+DQo+Pj4+PiBDaHJpc3Rlcg0KPj4+ Pj4NCj4+Pj4+DQo+Pj4+PiBPbiA5LzI0LzE1LCAyOjUzIEFNLCAiQ2hyaXN0ZXIgSG9sbWJlcmci DQo+Pj4+PiA8Y2hyaXN0ZXIuaG9sbWJlcmdAZXJpY3Nzb24uY29tPg0KPj4+Pj4gd3JvdGU6DQo+ Pj4+Pg0KPj4+Pj4NCj4+Pj4+ICAgICAgICAgICAgDQo+Pj4+Pj4gSGkgQ2hhcmxlcywNCj4+Pj4+ Pg0KPj4+Pj4+IEkgYW0gc3RpbGwgbm90IHN1cmUgSSB1bmRlcnN0YW5kIHlvdXIgc3VnZ2VzdGlv bjogd2hhdCBpcyBtZWFudCBieQ0KPj4+Pj4+ICJhcyBkZXRlcm1pbmVkIHByaW9yIHRvIHB1Ymxp Y2F0aW9uIj8gV2hlbi93aGVyZS93aG8/IDopDQo+Pj4+Pj4NCj4+Pj4+PiBSZWdhcmRzLA0KPj4+ Pj4+DQo+Pj4+Pj4gQ2hyaXN0ZXINCj4+Pj4+Pg0KPj4+Pj4+IC0tLS0tT3JpZ2luYWwgTWVzc2Fn ZS0tLS0tDQo+Pj4+Pj4gRnJvbTogQ2hhcmxlcyBFY2tlbCAoZWNrZWxjdSkgW21haWx0bzplY2tl bGN1QGNpc2NvLmNvbV0NCj4+Pj4+PiBTZW50OiAyMi4gc3l5c2t1dXRhIDIwMTUgMTc6MDUNCj4+ Pj4+PiBUbzogQ2hyaXN0ZXIgSG9sbWJlcmc7IFRvbSBLcmlzdGVuc2VuICh0b21rcmlzdCkNCj4+ Pj4+PiBDYzogZHJhZnQtaWV0Zi1iZmNwYmlzLXJmYzQ1ODJiaXNAdG9vbHMuaWV0Zi5vcmc7DQo+ Pj4+Pj4gYmZjcGJpc0BpZXRmLm9yZzsgQWxpc3NhIENvb3BlcjsgR29uemFsbyBDYW1hcmlsbG87 IEJlbiBDYW1wYmVsbA0KPj4+Pj4+IFN1YmplY3Q6IFJlOiBbYmZjcGJpc10gZHJhZnQtaWV0Zi1i ZmNwYmlzLXJmYzQ1ODNiaXMNCj4+Pj4+Pg0KPj4+Pj4+IEkgdmlldyByZWZlcnJpbmcgdG8gZHJh ZnQtaWV0Zi1tbXVzaWMtZHRscy1zZHAgbm93IGluc3RlYWQgb2YgUkZDDQo+Pj4+Pj4gNTc2MyB0 byBiZSBsaWtlIHdyaXRpbmcgYSBibGFuayBjaGVjay4gRGViYXRlIGlzIGFjdGl2ZWx5DQo+Pj4+ Pj4gb2NjdXJyaW5nIG9uIHRoZSBsaXN0LCB0aGUgbm9ybWF0aXZlIGxhbmd1YWdlIGluIFJGQyA1 NzYzIGlzDQo+Pj4+Pj4gZXhwZWN0ZWQgdG8gYmUgdXBkYXRlZCBpbiBtdWx0aXBsZSB3YXlzLCBh bmQgYmFja3dhcmQNCj4+Pj4+PiBjb21wYXRpYmlsaXR5IHdpdGggdGhlIHRoZSBub3JtYXRpdmUg bGFuZ3VhZ2UgcHJvdmlkZSBpbiBwcmV2aW91cw0KPj4+Pj4+IHZlcnNpb24gb2YgcmZjNDU4M2Jp cyBpcyBub3QgZnVsbHkgYWRkcmVzc2VkLiBJdCBzZWVtcyBtb3JlDQo+Pj4+Pj4gYXBwcm9wcmlh dGUgdG8gbWUgYXQgdGhpcyBzdGFnZSB0byBjb250aW51ZSB0byByZWZlciB0byBSRkMgNTc2Mw0K Pj4+Pj4+IHdpdGggYSBub3RlIHJlZ2FyZGluZyB1cGRhdGluZyBvciByZXBsYWNpbmcgdGhhdCBy ZWZlcmVuY2Ugd2l0aA0KPj4+Pj4+IG9uZSB0byBkcmFmdC1pZXRmLW1tdXNpYy1kdGxzLXNkcCwg YXMgZGV0ZXJtaW5lZCBwcmlvciB0byBwdWJsaWNhdGlvbi4NCj4+Pj4+Pg0KPj4+Pj4+IENoZWVy cywNCj4+Pj4+PiBDaGFybGVzDQo+Pj4+Pj4NCj4+Pj4+PiBPbiA5LzIxLzE1LCAxMTo0OCBQTSwg IkNocmlzdGVyIEhvbG1iZXJnIg0KPj4+Pj4+IDxjaHJpc3Rlci5ob2xtYmVyZ0Blcmljc3Nvbi5j b20+DQo+Pj4+Pj4gd3JvdGU6DQo+Pj4+Pj4NCj4+Pj4+Pg0KPj4+Pj4+ICAgICAgICAgICAgICAN Cj4+Pj4+Pj4gSGksDQo+Pj4+Pj4+DQo+Pj4+Pj4+DQo+Pj4+Pj4+ICAgICAgICAgICAgICAgIA0K Pj4+Pj4+Pj4gSSBzZWUuIEFzIHRoaXMgaXMgYSBtb3ZpbmcgdGFyZ2V0LCBwZXJoYXBzIHdoZXJl IHdlIHJlZmVyZW5jZQ0KPj4+Pj4+Pj4gUkZDDQo+Pj4+Pj4+PiA1NzYzIHdlIGNhbiBhZGQgYSBu b3RlIGZvciB0aGUgUkZDIGVkaXRvciB0aGF0DQo+Pj4+Pj4+PiBkcmFmdC1pZXRmLW1tdXNpYy1k dGxzLXNkcCBpcyBleHBlY3RlZCB0byBhZGQgY2xhcmlmaWNhdGlvbnMgYW5kDQo+Pj4+Pj4+PiBt YWtlIGNoYW5nZXMgdG8gUkZDIDU3NjMgdGhhdCBzaG91bGQgYmUgY29uc2lkZXJlZCBwcmlvciB0 bw0KPj4+Pj4+Pj4gcHVibGljYXRpb24gb2YgcmZjNDU4M2Jpcy4NCj4+Pj4+Pj4+DQo+Pj4+Pj4+ PiAgICAgICAgICAgICAgICAgIA0KPj4+Pj4+PiBJIGFtIG5vdCBzdXJlIEkgdW5kZXJzdGFuZC4g SSBkb24ndCB0aGluayBpdCdzIHVwIHRvIHRoZSBSRkMNCj4+Pj4+Pj4gZWRpdG9yIHRvIG1ha2Ug YSBkZWNpc2lvbiB3aGV0aGVyIHRoZSBkcmFmdCBzaG91bGQgcmVmZXJlbmNlIERUTFMtU0RQLg0K Pj4+Pj4+Pg0KPj4+Pj4+PiBSZWdhcmRzLA0KPj4+Pj4+Pg0KPj4+Pj4+PiBDaHJpc3Rlcg0KPj4+ Pj4+Pg0KPj4+Pj4+Pg0KPj4+Pj4+Pg0KPj4+Pj4+PiBPbiA5LzIxLzE1LCAxMToyMyBBTSwgIkNo cmlzdGVyIEhvbG1iZXJnIg0KPj4+Pj4+PiA8Y2hyaXN0ZXIuaG9sbWJlcmdAZXJpY3Nzb24uY29t Pg0KPj4+Pj4+PiB3cm90ZToNCj4+Pj4+Pj4NCj4+Pj4+Pj4NCj4+Pj4+Pj4gICAgICAgICAgICAg ICAgDQo+Pj4+Pj4+PiBIaSwNCj4+Pj4+Pj4+DQo+Pj4+Pj4+Pg0KPj4+Pj4+Pj4gICAgICAgICAg ICAgICAgICANCj4+Pj4+Pj4+PiBSRkMgNTc2Mywgd2hpY2ggaXMgY3VycmVudGx5IHJlcXVpcmVk IGZvciBCRkNQIHdpdGggRFRMUyByZWFkczoNCj4+Pj4+Pj4+Pg0KPj4+Pj4+Pj4+ICAgICBvICBU aGUgZW5kcG9pbnQgTVVTVCBOT1QgdXNlIHRoZSBjb25uZWN0aW9uIGF0dHJpYnV0ZQ0KPj4+Pj4+ Pj4+IGRlZmluZWQgaW4NCj4+Pj4+Pj4+PiAgICAgICBbUkZDNDE0NTxodHRwczovL3Rvb2xzLmll dGYub3JnL2h0bWwvcmZjNDE0NT5dLg0KPj4+Pj4+Pj4+DQo+Pj4+Pj4+Pj4gICAgICAgICAgICAg ICAgICAgIA0KPj4+Pj4+Pj4gQ29ycmVjdC4NCj4+Pj4+Pj4+DQo+Pj4+Pj4+PiBBbmQsIElGIHdl IGRlY2lkZSB0byB1c2UgZGVmaW5lIHVzYWdlIG9mIHRoZSAnY29ubmVjdGlvbicNCj4+Pj4+Pj4+ IGF0dHJpYnV0ZSBmb3IgRFRMUywgd2Ugd291bGQgY2hhbmdlIHRoYXQuDQo+Pj4+Pj4+Pg0KPj4+ Pj4+Pj4gSG93ZXZlciwgYSBmZXcgZGF5cyBhZ28gd2Ugc2VudCBhbiBlLW1haWwgdG8gdGhlIE1N VVNJQyBsaXN0LA0KPj4+Pj4+Pj4gc3VnZ2VzdGluZyB0aGF0IHdlIHNob3VsZCBOT1QgdXNlIHRo ZSAnY29ubmVjdGlvbicgYXR0cmlidXRlIGZvcg0KPj4+Pj4+Pj4gRFRMUy4NCj4+Pj4+Pj4+IElu c3RlYWQgd2Ugc2hvdWxkIGRlZmluZSBhIG5ldyBhdHRyaWJ1dGUgKGZvciBtb3JlIGRldGFpbHMs DQo+Pj4+Pj4+PiBwbGVhc2UgIHNlZSB0aGUgTU1VU0lDIGxpc3QpLg0KPj4+Pj4+Pj4NCj4+Pj4+ Pj4+DQo+Pj4+Pj4+PiAgICAgICAgICAgICAgICAgIA0KPj4+Pj4+Pj4+IFNlY3Rpb24gNS4xIG9m IGRyYWZ0LWlldGYtbW11c2ljLWR0bHMtc2RwIHJlYWRzOg0KPj4+Pj4+Pj4+DQo+Pj4+Pj4+Pj4g ICAgIFdoZW4gdXNlZCB3aXRoIERUTFMsIHRoZXJlIGlzIG5vIGRlZmF1bHQgdmFsdWUgZGVmaW5l ZCBmb3IgdGhlDQo+Pj4+Pj4+Pj4gICAgIGF0dHJpYnV0ZS4gIEltcGxlbWVudGF0aW9ucyB0aGF0 IHdpc2ggdG8gdXNlIHRoZSBhdHRyaWJ1dGUgTVVTVA0KPj4+Pj4+Pj4+ICAgICBleHBsaWNpdGx5 IGluY2x1ZGUgaXQgaW4gU0RQIG9mZmVycyBhbmQgYW5zd2Vycy4gIElmIGFuDQo+Pj4+Pj4+Pj4g b2ZmZXIgb3INCj4+Pj4+Pj4+PiAgICAgYW5zd2VyIGRvZXMgbm90IGNvbnRhaW4gYW4gYXR0cmli dXRlLCBvdGhlciBtZWFucyBuZWVkcyB0bw0KPj4+Pj4+Pj4+IGJlICB1c2VkIGluDQo+Pj4+Pj4+ Pj4gICAgIG9yZGVyIGZvciBlbmRwb2ludHMgdG8gZGV0ZXJtaW5lIHdoZXRoZXIgYW4gb2ZmZXIg b3IgYW5zd2VyIGlzDQo+Pj4+Pj4+Pj4gICAgIGFzc29jaWF0ZWQgd2l0aCBhbiBldmVudCB0aGF0 IHJlcXVpcmVzIHRoZSBEVExTIGFzc29jaWF0aW9uDQo+Pj4+Pj4+Pj4gdG8gIGJlDQo+Pj4+Pj4+ Pj4gcmUtDQo+Pj4+Pj4+Pj4gICAgIGVzdGFibGlzaGVkLg0KPj4+Pj4+Pj4+DQo+Pj4+Pj4+Pj4g SSBzdXBwb3NlIGlmIGRyYWZ0LWlldGYtbW11c2ljLWR0bHMtc2RwIHB1bGxzIGluIGVub3VnaCBm cm9tDQo+Pj4+Pj4+Pj4gUkZDDQo+Pj4+Pj4+Pj4gNTc2MyB0byBtYWtlIGl0IGNsZWFyIGhvdyB0 aGUgRFRMUyBlc3RhYmxpc2htZW50IGFuZA0KPj4+Pj4+Pj4+IHJlLWVzdGFibGlzaG1lbnQgd29y a3MgZm9yIHRoZSBjYXNlIG9mIHdoaWNoIHRoZSBjb25uZWN0aW9uDQo+Pj4+Pj4+Pj4gYXR0cmli dXRlIGlzIG5vdCB1c2VkLCB0aGVuIHdlIGNhbiBjaGFuZ2UgdGhlIHJlZmVyZW5jZSBmcm9tDQo+ Pj4+Pj4+Pj4gUkZDDQo+Pj4+Pj4+Pj4gNTc2MyB0byBkcmFmdC1pZXRmLW1tdXNpYy1kdGxzLXNk cC4NCj4+Pj4+Pj4+Pg0KPj4+Pj4+Pj4+IFRoZSBsYXN0IHNldmVyYWwgdXBkYXRlcyBvZiBkcmFm dC1pZXRmLWJmY3BiaXMtcmZjNDU4M2JpcyBoYXZlDQo+Pj4+Pj4+Pj4gcmVtb3ZlZCBzdXBwb3J0 aW5nIHRleHQgZnJvbSB0aGUgZHJhZnQgaW4gZmF2b3Igb2YgcG9pbnRpbmcgdG8NCj4+Pj4+Pj4+ PiBSRkMNCj4+Pj4+Pj4+PiA1NzYzIGFzIHRoZSAgc291cmNlIG9mIHRydXRoLiBJIGZlYXIgdGhh dA0KPj4+Pj4+Pj4+IGRyYWZ0LWlldGYtbW11c2ljLWR0bHMtc2RwIGluIGl0cyBjdXJyZW50IHN0 YXRlIGRvZXMgbm90IHNlcnZlDQo+Pj4+Pj4+Pj4gdGhhdCBuZWVkIGZvciBkcmFmdC1pZXRmLWJm Y3BiaXMtcmZjNDU4M2Jpcy4gSSB2YWx1ZQ0KPj4+Pj4+Pj4+IENocmlzdGVy4oCZcyB0aG91Z2h0 cyBhbmQgd2VsY29tZSB0aGUgb3BpbmlvbiBvZiBvdGhlcnMsDQo+Pj4+Pj4+Pj4gZXNwZWNpYWxs eSB0aG9zZSB3aG8gaGF2ZSBvciBhcmUgaW1wbGVtZW50aW5nIEJGQ1Agd2l0aCBEVExTIGFuZCBJ Q0UsIHdoaWNoIEkgaGF2ZSBub3QuDQo+Pj4+Pj4+Pj4NCj4+Pj4+Pj4+PiAgICAgICAgICAgICAg ICAgICAgDQo+Pj4+Pj4+PiBQbGVhc2Ugbm90ZSB0aGF0IERUTFMtU0RQIGRvZXMgbm90IG9ubHkg ZGVmaW5lIHVzYWdlIG9mIHRoZQ0KPj4+Pj4+Pj4gJ2Nvbm5lY3Rpb24nDQo+Pj4+Pj4+PiBhdHRy aWJ1dGUsIGl0IGFsc28gZG9lcyBvdGhlciB0aGluZ3MuIE1heWJlIG1vcmUgaW1wb3J0YW50LCBp dA0KPj4+Pj4+Pj4gZG9lcyBub3Qgc3RhdGUgdGhhdCBhbiBhZGRyZXNzIGNoYW5nZSBieSBkZWZh dWx0IHJlcXVpcmVzIGEgbmV3DQo+Pj4+Pj4+PiBEVExTIGFzc29jaWF0aW9uDQo+Pj4+Pj4+PiAt IHdoaWNoIGlzIGEgYW5vdGhlciA1NzYzIG1vZGlmaWNhdGlvbi4NCj4+Pj4+Pj4+DQo+Pj4+Pj4+ PiBSZWdhcmRzLA0KPj4+Pj4+Pj4NCj4+Pj4+Pj4+IENocmlzdGVyDQo+Pj4+Pj4+Pg0KPj4+Pj4+ Pj4NCj4+Pj4+Pj4+DQo+Pj4+Pj4+Pg0KPj4+Pj4+Pj4gT24gOS8yMS8xNSwgOTozMiBBTSwgImJm Y3BiaXMgb24gYmVoYWxmIG9mIENocmlzdGVyIEhvbG1iZXJnIg0KPj4+Pj4+Pj4gPGJmY3BiaXMt Ym91bmNlc0BpZXRmLm9yZyBvbiBiZWhhbGYgb2YNCj4+Pj4+Pj4+IGNocmlzdGVyLmhvbG1iZXJn QGVyaWNzc29uLmNvbT4NCj4+Pj4+Pj4+IHdyb3RlOg0KPj4+Pj4+Pj4NCj4+Pj4+Pj4+DQo+Pj4+ Pj4+PiAgICAgICAgICAgICAgICAgIA0KPj4+Pj4+Pj4+IEhpIENoYXJsZXMsDQo+Pj4+Pj4+Pj4N Cj4+Pj4+Pj4+Pg0KPj4+Pj4+Pj4+ICAgICAgICAgICAgICAgICAgICANCj4+Pj4+Pj4+Pj4gVGhl IHByb2JsZW0gSSBzZWUgd2l0aCB0aGlzIGlzIHRoYXQgaXQgaXMgbm90IGp1c3QgYSBtYXR0ZXIg b2YNCj4+Pj4+Pj4+Pj4gY2hhbmdpbmcgdGhlIHJlZmVyZW5jZSwgaXQgaXMgYWxzbyBhIG1hdHRl ciBvZiBjaGFuZ2luZyB0aGUNCj4+Pj4+Pj4+Pj4gbm9ybWF0aXZlIGJlaGF2aW9yLg0KPj4+Pj4+ Pj4+PiBGb3IgRFRMUyB3aXRoIEJGQ1AsIHdlIG5ldmVyIHJlcXVpcmVkIHRoZSB1c2Ugb2YgdGhl PuKAnGNvbm5lY3Rpb27igJ0NCj4+Pj4+Pj4+Pj4gYXR0cmlidXRlLg0KPj4+Pj4+Pj4+PiBJZiB3 ZSBhcmUgdG8gc3RhcnQgcmVxdWlyaW5nIGl0LCB3ZSB3b3VsZCBuZWVkIGFkZCB0ZXh0IHRvDQo+ Pj4+Pj4+Pj4+IGRlc2NyaWJlIGhvdyB0byBhZGRyZXNzIGJhY2t3YXJkIGNvbXBhdGliaWxpdHkg aW4gY2FzZXMgaW4NCj4+Pj4+Pj4+Pj4gd2hpY2ggdGhlIGNvbm5lY3Rpb24gYXR0cmlidXRlIGlz IG5vdCBzcGVjaWZpZWQuDQo+Pj4+Pj4+Pj4+DQo+Pj4+Pj4+Pj4+ICAgICAgICAgICAgICAgICAg ICAgIA0KPj4+Pj4+Pj4+IFRoZSBpbnRlbnRpb24gaXMgdG8gY292ZXIgYmFja3dhcmQgY29tcGF0 aWJpbGl0eSBpbiB0aGUgZHJhZnQuDQo+Pj4+Pj4+Pj4NCj4+Pj4+Pj4+Pg0KPj4+Pj4+Pj4+ICAg ICAgICAgICAgICAgICAgICANCj4+Pj4+Pj4+Pj4gQXJlIHRoZXJlIHBsYW5zIGZvciB0aGlzIHdp dGhpbiBSRkMgNTc2M2JpcyBkcmFmdD8gSWYgc28sDQo+Pj4+Pj4+Pj4+IFRvbeKAmXMgcmVjb21t ZW5kYXRpb24gb2YgY29udGludWluZyB0byBwb2ludCB0byBSRkMgNTc2MyBmb3INCj4+Pj4+Pj4+ Pj4gbm93IG1heSBiZSB0aGUgYmVzdCBhcHByb2FjaC4NCj4+Pj4+Pj4+Pj4NCj4+Pj4+Pj4+Pj4g ICAgICAgICAgICAgICAgICAgICAgDQo+Pj4+Pj4+Pj4gSSBhbSBub3QgZmFtaWxpYXIgd2l0aCB0 aGUgNTc2M2JpcyBkcmFmdC4gQnV0LCBldmVuIGlmIHRoZQ0KPj4+Pj4+Pj4+IERUTFMtU0RQIGRy YWZ0IG1ha2VzIHVwZGF0ZXMgdG8gNTc2MywgaXQgd29uJ3QgYmVjb21lIGEgNTc2M2Jpcw0KPj4+ Pj4+Pj4+IGRyYWZ0Lg0KPj4+Pj4+Pj4+DQo+Pj4+Pj4+Pj4gUmVnYXJkcywNCj4+Pj4+Pj4+Pg0K Pj4+Pj4+Pj4+IENocmlzdGVyDQo+Pj4+Pj4+Pj4NCj4+Pj4+Pj4+Pg0KPj4+Pj4+Pj4+DQo+Pj4+ Pj4+Pj4gT24gOS8xMS8xNSwgMToxMSBQTSwgIkNocmlzdGVyIEhvbG1iZXJnIg0KPj4+Pj4+Pj4+ IDxjaHJpc3Rlci5ob2xtYmVyZ0Blcmljc3Nvbi5jb20+DQo+Pj4+Pj4+Pj4gd3JvdGU6DQo+Pj4+ Pj4+Pj4NCj4+Pj4+Pj4+Pg0KPj4+Pj4+Pj4+ICAgICAgICAgICAgICAgICAgICANCj4+Pj4+Pj4+ Pj4gSGksDQo+Pj4+Pj4+Pj4+DQo+Pj4+Pj4+Pj4+DQo+Pj4+Pj4+Pj4+ICAgICAgICAgICAgICAg ICAgICAgIA0KPj4+Pj4+Pj4+Pj4gSG1tLCB5ZXMgbWF5YmUgYW4gaWRlYSBpZiBpdCdzIGZpbmUg cHJvY2VlZGluZyB3aXRoIHJlZmVycmluZw0KPj4+Pj4+Pj4+Pj4gYSAgd29yay1pbi1wcm9ncmVz cyBkcmFmdCBoZXJlLg0KPj4+Pj4+Pj4+Pj4gV2hhdCBpZiB3ZSBrZWVwIHRoZSB0ZXh0IGFuZCBh ZGRzIHRoaXMgYXMgYW4gYWRkaXRpb25hbA0KPj4+Pj4+Pj4+Pj4gcmVmZXJlbmNlIGluIHRoZSB0 d28gbmV3IHRleHQgcGFzc2FnZXMgcHJvcG9zZWQgYnkgQ2hhcmxlczogIi4uLg0KPj4+Pj4+Pj4+ Pj4gWzEzXSwgYW5kIHRoZSBjbGFyaWZpY2F0aW9ucyBkZWZpbmVkIGluDQo+Pj4+Pj4+Pj4+PiBb ZHJhZnQtaWV0Zi1tbXVzaWMtZHRscy1zZHBdLCAuLi4iLg0KPj4+Pj4+Pj4+Pj4NCj4+Pj4+Pj4+ Pj4+IFdoZXJlIFsxM10gaXMgYSByZWZlcmVuY2UgdG8gUkZDIDU3NjMuDQo+Pj4+Pj4+Pj4+Pg0K Pj4+Pj4+Pj4+Pj4gICAgICAgICAgICAgICAgICAgICAgICANCj4+Pj4+Pj4+Pj4gTXkgc3VnZ2Vz dGlvbiBpcyB0byAqb25seSogcmVmZXIgdGhlIG5ldyBkdGxzLXNkcCBkcmFmdC4NCj4+Pj4+Pj4+ Pj4gQmVjYXVzZSwgb25lIG9mIHRoZSBpZGVhcyB3aXRoIHRoZSBuZXcgZHJhZnQgaXMgdG8gYWxz byB1cGRhdGUNCj4+Pj4+Pj4+Pj4gUkZDIDU3NjMgdG8gcmVmZXJlbmNlIHRoZSBuZXcgZHRscy1z ZHAgZHJhZnQuDQo+Pj4+Pj4+Pj4+DQo+Pj4+Pj4+Pj4+DQo+Pj4+Pj4+Pj4+ICAgICAgICAgICAg ICAgICAgICAgIA0KPj4+Pj4+Pj4+Pj4gQW55d2F5LCBJJ2Qgc3RpbGwgcHJlZmVyIHRvIGtlZXAg dGhlIHRleHQgaW4NCj4+Pj4+Pj4+Pj4+IGRyYWZ0LWlldGYtYmZjcGJpcy1yZmM0NTgzYmlzLTEy IGFuZCByZWRpcmVjdCB0aGUgcmVhZGVycyB0bw0KPj4+Pj4+Pj4+Pj4gdGhlIHJmYzU3NjNiaXMs IHRoYXQgZXZlbnR1YWxseSB0aGVuIHdpbGwgb2Jzb2xldGUgKG9yDQo+Pj4+Pj4+Pj4+PiBleHRl bmQ/KSBSRkMgNTc2My4NCj4+Pj4+Pj4+Pj4+DQo+Pj4+Pj4+Pj4+PiAgICAgICAgICAgICAgICAg ICAgICAgIA0KPj4+Pj4+Pj4+PiBUaGUgbmV3IGR0bHMtc2RwIGRyYWZ0IHdpbGwgbm90IGJlY29t ZSA1NzYzYmlzIChldmVudGhvdWdoIGl0DQo+Pj4+Pj4+Pj4+IE1BWSB1cGRhdGUgc29tZSBwYXJ0 cyBvZiA1NzYzKS4gSXQncyBhIGdlbmVyaWMgZG9jdW1lbnQsIHdoaWNoDQo+Pj4+Pj4+Pj4+ICph bnkqIERUTFMgdXNhZ2UgY2FuIHRoZW4gcmVmZXJlbmNlLg0KPj4+Pj4+Pj4+Pg0KPj4+Pj4+Pj4+ PiBSZWdhcmRzLA0KPj4+Pj4+Pj4+Pg0KPj4+Pj4+Pj4+PiBDaHJpc3Rlcg0KPj4+Pj4+Pj4+Pg0K Pj4+Pj4+Pj4+Pg0KPj4+Pj4+Pj4+Pg0KPj4+Pj4+Pj4+PiBPbiAwOS8xMS8yMDE1IDAxOjI1IFBN LCBDaHJpc3RlciBIb2xtYmVyZyB3cm90ZToNCj4+Pj4+Pj4+Pj4NCj4+Pj4+Pj4+Pj4gICAgICAg ICAgICAgICAgICAgICAgDQo+Pj4+Pj4+Pj4+PiBIaSwNCj4+Pj4+Pj4+Pj4+DQo+Pj4+Pj4+Pj4+ PiBNeSBzdWdnZXN0aW9uIHdvdWxkIGFjdHVhbGx5IGJlIHRvIHJlZmVyIHRvIHRoZSBuZXcNCj4+ Pj4+Pj4+Pj4+IGRyYWZ0LWlldGYtbW11c2ljLWR0bHMtc2RwLCB3aGljaCBpcyBnb2luZyB0byBj bGFyaWZ5IHRoZQ0KPj4+Pj4+Pj4+Pj4gRFRMUy1TUlRQIHJ1bGVzIHJlZ2FyZGluZyB3aGVuIGEg bmV3IERUTFMgYXNzb2NpYXRpb24gbXVzdCBiZQ0KPj4+Pj4+Pj4+Pj4gZXN0YWJsaXNoZWQuDQo+ Pj4+Pj4+Pj4+Pg0KPj4+Pj4+Pj4+Pj4gUmVnYXJkcywNCj4+Pj4+Pj4+Pj4+DQo+Pj4+Pj4+Pj4+ PiBDaHJpc3Rlcg0KPj4+Pj4+Pj4+Pj4NCj4+Pj4+Pj4+Pj4+IC0tLS0tT3JpZ2luYWwgTWVzc2Fn ZS0tLS0tDQo+Pj4+Pj4+Pj4+PiBGcm9tOiBUb20gS3Jpc3RlbnNlbiBbbWFpbHRvOnRvbWtyaXN0 QGNpc2NvLmNvbV0NCj4+Pj4+Pj4+Pj4+IFNlbnQ6IDExLiBzeXlza3V1dGEgMjAxNSAxMzoyNQ0K Pj4+Pj4+Pj4+Pj4gVG86IENoYXJsZXMgRWNrZWwgKGVja2VsY3UpDQo+Pj4+Pj4+Pj4+PiBDYzog Q2hyaXN0ZXIgSG9sbWJlcmc7IEFsaXNzYSBDb29wZXI7IEdvbnphbG8gQ2FtYXJpbGxvOw0KPj4+ Pj4+Pj4+Pj4gZHJhZnQtaWV0Zi1iZmNwYmlzLXJmYzQ1ODJiaXNAdG9vbHMuaWV0Zi5vcmc7IEJl biBDYW1wYmVsbDsNCj4+Pj4+Pj4+Pj4+IGJmY3BiaXNAaWV0Zi5vcmcNCj4+Pj4+Pj4+Pj4+IFN1 YmplY3Q6IFJlOiBkcmFmdC1pZXRmLWJmY3BiaXMtcmZjNDU4M2Jpcw0KPj4+Pj4+Pj4+Pj4NCj4+ Pj4+Pj4+Pj4+IFBvaW50aW5nIHRvIHRoZSBEVExTLVNSVFAgKGFuZCBieSB0aGF0IGFueSB1cGRh dGVzIG9mIGl0KSBpcw0KPj4+Pj4+Pj4+Pj4gYSBzaW1wbGUsIHNhZmUgYW5kIHN0cmFpZ3QtZm9y d2FyZCBzb2x1dGlvbi4NCj4+Pj4+Pj4+Pj4+DQo+Pj4+Pj4+Pj4+PiBUaGUgb25seSBjaGFuZ2Ug aW4gdGhlIG5ldyB2ZXJzaW9uIG9mIHJmYzQ1ODNiaXMganVzdCBzdWJtaXR0ZWQuDQo+Pj4+Pj4+ Pj4+PiBBbmQgYXMgQ2hhcmxlcyBzYXlzLCB0aGlzIHNob3VsZCBiZSB0aGUgbGFzdCBtaXNzaW5n IGZpeCBmb3INCj4+Pj4+Pj4+Pj4+IHRoaXMgZHJhZnQgdW50aWwgbmV4dCBzdGFnZXMgaW4gdGhl IHByb2Nlc3MgYXQgbGVhc3QuDQo+Pj4+Pj4+Pj4+Pg0KPj4+Pj4+Pj4+Pj4gLS0gVG9tDQo+Pj4+ Pj4+Pj4+Pg0KPj4+Pj4+Pj4+Pj4gT24gMDkvMDgvMjAxNSAwNzo0OCBQTSwgQ2hhcmxlcyBFY2tl bCAoZWNrZWxjdSkgd3JvdGU6DQo+Pj4+Pj4+Pj4+Pg0KPj4+Pj4+Pj4+Pj4NCj4+Pj4+Pj4+Pj4+ ICAgICAgICAgICAgICAgICAgICAgICAgDQo+Pj4+Pj4+Pj4+Pj4gUGlja2luZyB1cCBvbiB0aGlz IG9sZCB0aHJlYWQgcmVnYXJkaW5nDQo+Pj4+Pj4+Pj4+Pj4gZHJhZnQtaWV0Zi1iZmNwYmlzLXJm YzQ1ODNiaXMuDQo+Pj4+Pj4+Pj4+Pj4gSSB0aGluayB0aGlzIGlzIHRoZSBvbmx5IG91dHN0YW5k aW5nIGl0ZW0gd2l0aCByZXNwZWN0IHRvDQo+Pj4+Pj4+Pj4+Pj4gdGhlIGN1cnJlbnQgIHZlcnNp b24gb2YgdGhlIGRyYWZ0LiBVbmxlc3MgYW55b25lIGhhcyBhbg0KPj4+Pj4+Pj4+Pj4+IGlzc3Vl IHdpdGggdGhlIHByb3Bvc2VkICByZXNvbHV0aW9uLCBJIHJlcXVlc3Qgd2UgdXBkYXRlIHRoZQ0K Pj4+Pj4+Pj4+Pj4+IGRyYWZ0IGFjY29yZGluZ2x5IGFuZCB0aGVuIHVzZSBpdCAgYXMgdGhlIGJh c2lzIGZvciBNYXJ5LA0KPj4+Pj4+Pj4+Pj4+IHRoZSBkb2N1bWVudCBzaGVwaGVyZCwgdG8gcHJv dmlkZSBhIHByb3RvIHdyaXRldXAuDQo+Pj4+Pj4+Pj4+Pj4NCj4+Pj4+Pj4+Pj4+PiBDaGVlcnMs DQo+Pj4+Pj4+Pj4+Pj4gQ2hhcmxlcw0KPj4+Pj4+Pj4+Pj4+DQo+Pj4+Pj4+Pj4+Pj4NCj4+Pj4+ Pj4+Pj4+PiBPbiA0LzIwLzE1LCAxMDozOSBBTSwgIkNoYXJsZXMgRWNrZWwNCj4+Pj4+Pj4+Pj4+ PiAoZWNrZWxjdSkiPGVja2VsY3VAY2lzY28uY29tPg0KPj4+Pj4+Pj4+Pj4+IHdyb3RlOg0KPj4+ Pj4+Pj4+Pj4+DQo+Pj4+Pj4+Pj4+Pj4NCj4+Pj4+Pj4+Pj4+Pg0KPj4+Pj4+Pj4+Pj4+DQo+Pj4+ Pj4+Pj4+Pj4gICAgICAgICAgICAgICAgICAgICAgICAgIA0KPj4+Pj4+Pj4+Pj4+PiBIaSBDaHJp c3RlciwNCj4+Pj4+Pj4+Pj4+Pj4NCj4+Pj4+Pj4+Pj4+Pj4gSSByZXJlYWQgdGhlIGN1cnJlbnQg ZHJhZnQgYW5kIHdlbnQgdGhyb3VnaCB0aGUgZm9sbG93aW5nDQo+Pj4+Pj4+Pj4+Pj4+IE1NVVNJ QyB0aHJlYWQgb24gdGhpcyBzdWJqZWN0Og0KPj4+Pj4+Pj4+Pj4+PiBodHRwOi8vd3d3LmlldGYu b3JnL21haWwtYXJjaGl2ZS93ZWIvbW11c2ljL2N1cnJlbnQvbXNnMTQ2MzEuDQo+Pj4+Pj4+Pj4+ Pj4+IGgNCj4+Pj4+Pj4+Pj4+Pj4gdA0KPj4+Pj4+Pj4+Pj4+PiBtDQo+Pj4+Pj4+Pj4+Pj4+IGwN Cj4+Pj4+Pj4+Pj4+Pj4NCj4+Pj4+Pj4+Pj4+Pj4gQXMgYSByZXN1bHQsIEkgYmV0dGVyIHVuZGVy c3RhbmQgdGhlIGlzc3VlIHlvdSBhcmUgYWRkcmVzc2luZy4NCj4+Pj4+Pj4+Pj4+Pj4gSSBzdWdn ZXN0IHRoZSBmb2xsb3dpbmcgY2hhbmdlcyB0byBiZSBjb25zaXN0ZW50IHdpdGggd2hhdA0KPj4+ Pj4+Pj4+Pj4+PiBpcyBiZWluZyBwcm9wb3NlZCBpbg0KPj4+Pj4+Pj4+Pj4+PiBNTVVTSUM6DQo+ Pj4+Pj4+Pj4+Pj4+DQo+Pj4+Pj4+Pj4+Pj4+IC0tLS0tLS0tLS0tLQ0KPj4+Pj4+Pj4+Pj4+PiBT ZWN0aW9uIDk6DQo+Pj4+Pj4+Pj4+Pj4+DQo+Pj4+Pj4+Pj4+Pj4+IE9MRDoNCj4+Pj4+Pj4+Pj4+ Pj4gRW5kcG9pbnRzIHRoYXQgdXNlIHRoZSBvZmZlci9hbnN3ZXIgbW9kZWwgdG8gZXN0YWJsaXNo IGEgRFRMUw0KPj4+Pj4+Pj4+Pj4+PiAgICAgICBhc3NvY2lhdGlvbiBNVVNUIHN1cHBvcnQgdGhl ICdzZXR1cCcgYXR0cmlidXRlLCBhcw0KPj4+Pj4+Pj4+Pj4+PiBkZWZpbmVkIGluIFs3XS4NCj4+ Pj4+Pj4+Pj4+Pj4gV2hlbiBEVExTIGlzIHVzZWQgd2l0aCBVRFAsIHRoZSAnc2V0dXAnIGF0dHJp YnV0ZSBpbmRpY2F0ZXMNCj4+Pj4+Pj4+Pj4+Pj4gd2hpY2ggb2YgdGhlIGVuZHBvaW50cyAoY2xp ZW50IG9yIGZsb29yIGNvbnRyb2wgc2VydmVyKQ0KPj4+Pj4+Pj4+Pj4+PiBpbml0aWF0ZXMgdGhl IERUTFMgYXNzb2NpYXRpb24gc2V0dXAuIFRoZSByZXF1aXJlbWVudHMgZm9yDQo+Pj4+Pj4+Pj4+ Pj4+IHRoZSBvZmZlci9hbnN3ZXIgZXhjaGFuZ2Ugc3BlY2lmaWVkIGluIFsxM10sIFNlY3Rpb24g NSBvZg0KPj4+Pj4+Pj4+Pj4+PiBbMTNdIE1VU1QgYmUgZm9sbG93ZWQgd2hlbiB1c2luZyBEVExT Lg0KPj4+Pj4+Pj4+Pj4+PiBPZmZlci9hbnN3ZXIgY29uc2lkZXJhdGlvbnMgYXJlIGRlc2NyaWJl ZCBpbiBTZWN0aW9uIDEwLjUuDQo+Pj4+Pj4+Pj4+Pj4+DQo+Pj4+Pj4+Pj4+Pj4+IE5FVzoNCj4+ Pj4+Pj4+Pj4+Pj4gV2hlbiBEVExTIGlzIHVzZWQgd2l0aCBVRFAsIHRoZSByZXF1aXJlbWVudHMg c3BlY2lmaWVkIGluDQo+Pj4+Pj4+Pj4+Pj4+IFNlY3Rpb24NCj4+Pj4+Pj4+Pj4+Pj4gNSBvZiBb MTNdIE1VU1QgYmUgZm9sbG93ZWQuDQo+Pj4+Pj4+Pj4+Pj4+DQo+Pj4+Pj4+Pj4+Pj4+DQo+Pj4+ Pj4+Pj4+Pj4+IFNlY3Rpb24gMTAuNQ0KPj4+Pj4+Pj4+Pj4+Pg0KPj4+Pj4+Pj4+Pj4+PiBPTEQN Cj4+Pj4+Pj4+Pj4+Pj4gICAgICAgSWYgdGhlIHRyYW5zcG9ydCBwYXJhbWV0ZXJzIG9yIHRoZSBr ZXkgZmluZ2VycHJpbnRzDQo+Pj4+Pj4+Pj4+Pj4+IGNoYW5nZSwgdGhlDQo+Pj4+Pj4+Pj4+Pj4+ ICAgICAgIGVuZHBvaW50cyBNVVNUIGVzdGFibGlzaCBhIG5ldyBEVExTIGNvbm5lY3Rpb24uICBJ bg0KPj4+Pj4+Pj4+Pj4+PiBzdWNoIGNhc2UgdGhlDQo+Pj4+Pj4+Pj4+Pj4+ICAgICAgICdhY3Rp dmUvcGFzc2l2ZScgc3RhdHVzIG9mIHRoZSBlbmRwb2ludHMgd2lsbCBhZ2FpbiBiZQ0KPj4+Pj4+ Pj4+Pj4+PiBkZXRlcm1pbmVkDQo+Pj4+Pj4+Pj4+Pj4+ICAgICAgIGZvbGxvd2luZyB0aGUgcHJv Y2VkdXJlcyBpbiBbN10sIGFuZCB0aGUgbmV3IHN0YXR1cw0KPj4+Pj4+Pj4+Pj4+PiB3aWxsIGJl IHVzZWQgdG8NCj4+Pj4+Pj4+Pj4+Pj4gICAgICAgZGV0ZXJtaW5lIHRoZSBUTFMgcm9sZXMgYXNz b2NpYXRlZCB3aXRoIHRoZSBuZXcgRFRMUw0KPj4+Pj4+Pj4+Pj4+PiBjb25uZWN0aW9uLg0KPj4+ Pj4+Pj4+Pj4+Pg0KPj4+Pj4+Pj4+Pj4+PiAgICAgICAgICBJbmZvcm1hdGlvbmFsIG5vdGU6IFRo ZSBwcm9jZWR1cmUgYWJvdmUgaXMNCj4+Pj4+Pj4+Pj4+Pj4gaWRlbnRpY2FsIHRvIHRoZSBvbmUN Cj4+Pj4+Pj4+Pj4+Pj4gICAgICAgICAgZGVmaW5lZCBmb3IgRFRMUy1TUlRQIGluIFsxM10uDQo+ Pj4+Pj4+Pj4+Pj4+DQo+Pj4+Pj4+Pj4+Pj4+ICAgICAgICAgIE5vdGU6IEEgbmV3IERUTFMgY29u bmVjdGlvbiBuZWVkcyB0byBiZSBlc3RhYmxpc2hlZA0KPj4+Pj4+Pj4+Pj4+PiBpZiB0aGUNCj4+ Pj4+Pj4+Pj4+Pj4gICAgICAgICAgdHJhbnNwb3J0IHBhcmFtZXRlcnMgb3IgdGhlIGtleSBmaW5n ZXJwcmludHMgY2hhbmdlLg0KPj4+Pj4+Pj4+Pj4+Pg0KPj4+Pj4+Pj4+Pj4+Pg0KPj4+Pj4+Pj4+ Pj4+Pg0KPj4+Pj4+Pj4+Pj4+PiBORVc6DQo+Pj4+Pj4+Pj4+Pj4+IFRoZSBjb25kaXRpb25zIHVu ZGVyIHdoaWNoIGVuZHBvaW50cyBNVVNUIGVzdGFibGlzaCBhIG5ldw0KPj4+Pj4+Pj4+Pj4+PiBE VExTIGNvbm5lY3Rpb24gYXJlIGFzIHRoZSBzYW1lIGRlZmluZWQgZm9yIERUTFMtU1JUUCBpbiBb MTNdLg0KPj4+Pj4+Pj4+Pj4+PiDigJTigJTigJTigJTigJTigJTigJTigJQNCj4+Pj4+Pj4+Pj4+ Pj4NCj4+Pj4+Pj4+Pj4+Pj4gVGhpcyB3YXkgd2UgYXZvaWQgYW55IHBvdGVudGlhbCBjb25mbGlj dHMgd2l0aCB0aGUgaW50ZW50DQo+Pj4+Pj4+Pj4+Pj4+IG9mIFJGQyA1NzYzLCBhbmQgd2hlbiBj bGFyaWZpY2F0aW9ucyB0byBSRkMgNTc2MyBhcmUgbWFkZSwNCj4+Pj4+Pj4+Pj4+Pj4gdGhleSB3 aWxsIGJlIHBpY2tlZCB1cCBieSB0aGUgQkZDUCBzcGVjLg0KPj4+Pj4+Pj4+Pj4+Pg0KPj4+Pj4+ Pj4+Pj4+PiBDaGVlcnMsDQo+Pj4+Pj4+Pj4+Pj4+IENoYXJsZXMNCj4+Pj4+Pj4+Pj4+Pj4NCj4+ Pj4+Pj4+Pj4+Pj4NCj4+Pj4+Pj4+Pj4+Pj4NCj4+Pj4+Pj4+Pj4+Pj4NCj4+Pj4+Pj4+Pj4+Pj4g T24gNC8xOC8xNSwgMjowMSBQTSwgIkNocmlzdGVyDQo+Pj4+Pj4+Pj4+Pj4+IEhvbG1iZXJnIjxj aHJpc3Rlci5ob2xtYmVyZ0Blcmljc3Nvbi5jb20+DQo+Pj4+Pj4+Pj4+Pj4+IHdyb3RlOg0KPj4+ Pj4+Pj4+Pj4+Pg0KPj4+Pj4+Pj4+Pj4+Pg0KPj4+Pj4+Pj4+Pj4+Pg0KPj4+Pj4+Pj4+Pj4+Pg0K Pj4+Pj4+Pj4+Pj4+PiAgICAgICAgICAgICAgICAgICAgICAgICAgICANCj4+Pj4+Pj4+Pj4+Pj4+ IEhpIENoYXJsZXMsDQo+Pj4+Pj4+Pj4+Pj4+Pg0KPj4+Pj4+Pj4+Pj4+Pj4NCj4+Pj4+Pj4+Pj4+ Pj4+DQo+Pj4+Pj4+Pj4+Pj4+Pg0KPj4+Pj4+Pj4+Pj4+Pj4gICAgICAgICAgICAgICAgICAgICAg ICAgICAgICANCj4+Pj4+Pj4+Pj4+Pj4+PiBbYWRkaW5nIGJmY3BwYmlzIGxpc3RdDQo+Pj4+Pj4+ Pj4+Pj4+Pj4NCj4+Pj4+Pj4+Pj4+Pj4+PiBIaSBDaHJpc3RlciwNCj4+Pj4+Pj4+Pj4+Pj4+Pg0K Pj4+Pj4+Pj4+Pj4+Pj4+IFRoYW5rcyBmb3IgeW91ciByZXZpZXcgYW5kIGNvbW1lbnRzLiBJbiB0 aGUgQkZDUCB1c2FnZSwNCj4+Pj4+Pj4+Pj4+Pj4+PiB0aGUgRFRMUyBjb25uZWN0aW9uIGlzIGRl ZGljYXRlZCB0byB0aGUgQkZDUCBzdHJlYW0gaXQgY29udGFpbnMuDQo+Pj4+Pj4+Pj4+Pj4+Pj4g QXMgSSB1bmRlcnN0YW5kIGl0LCB0aGUgY29tcGxpY2F0aW9ucyBhcm91bmQgRFRMUw0KPj4+Pj4+ Pj4+Pj4+Pj4+IHJlLWVzdGFibGlzaGVtZW50IGRpc2N1c3NlZCBpbiBNTVVTSUMgcmVzdWx0IGZy b20gdXNlIG9mDQo+Pj4+Pj4+Pj4+Pj4+Pj4gYSBzaW5nbGUgRFRMUyBjb25uZWN0aW9uIGZvciBt dWx0aXBsZSBSVFAgYW5kL29yIFNDVFAgc3RyZWFtcy4NCj4+Pj4+Pj4+Pj4+Pj4+PiBUaG9zZSBj b21wbGljYXRpb25zIGRvIG5vdCBleGlzdCB3aXRoIHRoZSBCRkNQIHVzYWdlLCBzbw0KPj4+Pj4+ Pj4+Pj4+Pj4+IEkgdGhpbmsgaXQgaXMgc3VmZmljaWVudCB0byBjb250aW51ZSB0byByZWZlcmVu Y2UgUkZDDQo+Pj4+Pj4+Pj4+Pj4+Pj4gNTc2MyBhbmQgbm90IHVzZSB0aGUgU0RQIGNvbm5lY3Rp b24gYXR0cmlidXRlLg0KPj4+Pj4+Pj4+Pj4+Pj4+DQo+Pj4+Pj4+Pj4+Pj4+Pj4NCj4+Pj4+Pj4+ Pj4+Pj4+Pg0KPj4+Pj4+Pj4+Pj4+Pj4+ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAN Cj4+Pj4+Pj4+Pj4+Pj4+IFRoZSBjb21wbGljYXRpb25zIGRvIG5vdCByZXN1bHQgZnJvbSB1c2Ug b2YgYSBzaW5nbGUgRFRMUw0KPj4+Pj4+Pj4+Pj4+Pj4gY29ubmVjdGlvbiBmb3IgbXVsdGlwbGUg c3RyZWFtcyAtIGl0IG1haW5seSByZXN1bHRzIGZyb20NCj4+Pj4+Pj4+Pj4+Pj4+IHRoZSB1c2Fn ZSBvZiBJQ0UuIEFuZCwgYXMgZmFyIGFzIEkga25vdywgSUNFIGNhbiBiZSB1c2VkDQo+Pj4+Pj4+ Pj4+Pj4+PiBhbHNvIGZvciBCRkNQLg0KPj4+Pj4+Pj4+Pj4+Pj4NCj4+Pj4+Pj4+Pj4+Pj4+IEFu ZCwgZXZlbiB3aXRob3V0IElDRSB3ZSBpbnRlbmQgdG8gYWRkIHRleHQgc2F5aW5nIHRoYXQgYQ0K Pj4+Pj4+Pj4+Pj4+Pj4gRFRMUyBjb25uZWN0aW9uIGlzIG9ubHkgcmUtZXN0YWJsaXNoZWQgaWYg dGhlIHVuZGVybHlpbmcNCj4+Pj4+Pj4+Pj4+Pj4+IHRyYW5zcG9ydCBjaGFuZ2VzLg0KPj4+Pj4+ Pj4+Pj4+Pj4NCj4+Pj4+Pj4+Pj4+Pj4+IFJlZ2FyZHMsDQo+Pj4+Pj4+Pj4+Pj4+Pg0KPj4+Pj4+ Pj4+Pj4+Pj4gQ2hyaXN0ZXINCj4+Pj4+Pj4+Pj4+Pj4+DQo+Pj4+Pj4+Pj4+Pj4+Pg0KPj4+Pj4+ Pj4+Pj4+Pj4NCj4+Pj4+Pj4+Pj4+Pj4+DQo+Pj4+Pj4+Pj4+Pj4+Pg0KPj4+Pj4+Pj4+Pj4+Pj4N Cj4+Pj4+Pj4+Pj4+Pj4+ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgDQo+Pj4+Pj4+Pj4+ Pj4+Pj4gSGksDQo+Pj4+Pj4+Pj4+Pj4+Pj4NCj4+Pj4+Pj4+Pj4+Pj4+PiBGaXJzdCwgSSB3YW50 IHRvIGFwb2xvZ2l6ZSBmb3Igbm90IHByb3ZpZGluZyBteSByZXZpZXcNCj4+Pj4+Pj4+Pj4+Pj4+ PiBlYXJsaWVyLg0KPj4+Pj4+Pj4+Pj4+Pj4+DQo+Pj4+Pj4+Pj4+Pj4+Pj4gQXMgZmFyIGFzIHRo ZSBCRkNQIHNwZWNpZmljcyBhcmUgY29uY2VybmVkLCBJIGFtIG9rIHdpdGgNCj4+Pj4+Pj4+Pj4+ Pj4+PiB0aGUgbGF0ZXN0IHZlcnNpb24gb2YgdGhlIGRyYWZ0Lg0KPj4+Pj4+Pj4+Pj4+Pj4+DQo+ Pj4+Pj4+Pj4+Pj4+Pj4gSG93ZXZlciwgdGhlcmUgaXMgYW4gaXNzdWUgcmVnYXJkaW5nIHRoZSBE VExTDQo+Pj4+Pj4+Pj4+Pj4+Pj4gY29uc2lkZXJhdGlvbnMgKHNlY3Rpb24gMTAuNSkuDQo+Pj4+ Pj4+Pj4+Pj4+Pj4NCj4+Pj4+Pj4+Pj4+Pj4+PiBUaGUgdGV4dCBzYXlzOg0KPj4+Pj4+Pj4+Pj4+ Pj4+DQo+Pj4+Pj4+Pj4+Pj4+Pj4gCSJPbmNlIGEgRFRMUyBjb25uZWN0aW9uIGhhcyBiZWVuIGVz dGFibGlzaGVkLCBpZiB0aGUNCj4+Pj4+Pj4+Pj4+Pj4+PiAnYWN0aXZlL3Bhc3NpdmUnDQo+Pj4+ Pj4+Pj4+Pj4+Pj4gICAgICAgCXN0YXR1cyBvZiB0aGUgZW5kcG9pbnRzIGNoYW5nZSBkdXJpbmcg YSBzZXNzaW9uLCBhDQo+Pj4+Pj4+Pj4+Pj4+Pj4gbmV3IERUTFMNCj4+Pj4+Pj4+Pj4+Pj4+PiAg ICAgICAJY29ubmVjdGlvbiBNVVNUIGJlIGVzdGFibGlzaGVkLiINCj4+Pj4+Pj4+Pj4+Pj4+Pg0K Pj4+Pj4+Pj4+Pj4+Pj4+IFRoZXJlIGlzIGN1cnJlbnRseSBhbiBvbmdvaW5nIGRpc2N1c3Npb24g aW4gTU1VU0lDIGFib3V0DQo+Pj4+Pj4+Pj4+Pj4+Pj4gd2hlbiBhIERUTFMgY29ubmVjdGlvbiBp cyB0byBiZSByZS1lc3RhYmxpc2hlZC4NCj4+Pj4+Pj4+Pj4+Pj4+Pg0KPj4+Pj4+Pj4+Pj4+Pj4+ IFRoZSBkaXNjdXNzaW9uIGlzIHN0aWxsIG9uZ29pbmcsIGJ1dCB0aGUgb3V0Y29tZSB3aWxsDQo+ Pj4+Pj4+Pj4+Pj4+Pj4gbW9zdCBsaWtlbHkgTk9UIGJlIGFsaWduZWQgd2l0aCB0aGUgdGV4dCBh Ym92ZS4NCj4+Pj4+Pj4+Pj4+Pj4+Pg0KPj4+Pj4+Pj4+Pj4+Pj4+IEZvciBleGFtcGxlLCB0aGVy ZSBoYXMgYmVlbiBhIHN1Z2dlc3Rpb24gKGJ5IG15c2VsZikgdG8NCj4+Pj4+Pj4+Pj4+Pj4+PiB1 c2UgdGhlIFNEUCBjb25uZWN0aW9uIGF0dHJpYnV0ZSB0byBleHBsaWNpdGx5IGluZGljYXRlDQo+ Pj4+Pj4+Pj4+Pj4+Pj4gdGhhdCBhIG5ldyBEVExTIGNvbm5lY3Rpb24gbmVlZHMgdG8gYmUgZXN0 YWJsaXNoZWQuDQo+Pj4+Pj4+Pj4+Pj4+Pj4NCj4+Pj4+Pj4+Pj4+Pj4+Pg0KPj4+Pj4+Pj4+Pj4+ Pj4+IFRoZSBkcmFmdCBhbHNvIHNheXM6DQo+Pj4+Pj4+Pj4+Pj4+Pj4NCj4+Pj4+Pj4+Pj4+Pj4+ PiAJIklmIHRoZSB0cmFuc3BvcnQgcGFyYW1ldGVycyBvciB0aGUga2V5IGZpbmdlcnByaW50cw0K Pj4+Pj4+Pj4+Pj4+Pj4+IGNoYW5nZSwgdGhlDQo+Pj4+Pj4+Pj4+Pj4+Pj4gICAgICAgCWVuZHBv aW50cyBNVVNUIGVzdGFibGlzaCBhIG5ldyBEVExTIGNvbm5lY3Rpb24uIg0KPj4+Pj4+Pj4+Pj4+ Pj4+DQo+Pj4+Pj4+Pj4+Pj4+Pj4gVGhpcyBpcyByZWxhdGVkIHRvIHRoZSBlYXJsaWVyIGlzc3Vl LiBUaGVyZSBpcyB0aGUNCj4+Pj4+Pj4+Pj4+Pj4+PiBkaXNjdXNzaW9uIGFib3V0IElDRSAidmly dHVhbCBjb25uZWN0aW9ucyIsIGFuZCB0aGF0IGENCj4+Pj4+Pj4+Pj4+Pj4+PiBzaW5nbGUgRFRM UyBjb25uZWN0aW9uIHdvdWxkIGFwcGx5IHRvIGFsbCBJQ0UgY2FuZGlkYXRlcw0KPj4+Pj4+Pj4+ Pj4+Pj4+IGFzc29jaWF0ZWQgd2l0aCBhbg0KPj4+Pj4+Pj4+Pj4+Pj4+IG0tIGxpbmUuIFNvLCBl dmVuIGlmIGEgY2FuZGlkYXRlIGNoYW5nZXMgKHJlYWQ6IHRyYW5zcG9ydA0KPj4+Pj4+Pj4+Pj4+ Pj4+IHBhcmFtZXRlciBjaGFuZ2VzKSwgaXQgd291bGQgbm90IGF1dG9tYXRpY2FsbHkgdHJpZ2dl ciBhDQo+Pj4+Pj4+Pj4+Pj4+Pj4gbmV3IERUTFMgY29ubmVjdGlvbi4NCj4+Pj4+Pj4+Pj4+Pj4+ Pg0KPj4+Pj4+Pj4+Pj4+Pj4+DQo+Pj4+Pj4+Pj4+Pj4+Pj4gVGhlIGlzc3VlcyBhYm92ZSBhcmUg YWxzbyBob2xkaW5nIHVwIHRoZSBTQ1RQLVNEUCBkcmFmdCwNCj4+Pj4+Pj4+Pj4+Pj4+PiBzbyBp dCBkb2Vzbid0IG9ubHkgYWZmZWN0IEJGQ1BiaXMgOikNCj4+Pj4+Pj4+Pj4+Pj4+Pg0KPj4+Pj4+ Pj4+Pj4+Pj4+DQo+Pj4+Pj4+Pj4+Pj4+Pj4gUmVnYXJkcywNCj4+Pj4+Pj4+Pj4+Pj4+Pg0KPj4+ Pj4+Pj4+Pj4+Pj4+IENocmlzdGVyDQo+Pj4+Pj4+Pj4+Pj4+Pj4NCj4+Pj4+Pj4+Pj4+Pj4+Pg0K Pj4+Pj4+Pj4+Pj4+Pj4+IC0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQo+Pj4+Pj4+Pj4+Pj4+ Pj4gRnJvbTogQWxpc3NhIENvb3BlciBbbWFpbHRvOmFsaXNzYUBjb29wZXJ3LmluXQ0KPj4+Pj4+ Pj4+Pj4+Pj4+IFNlbnQ6IDguIGh1aHRpa3V1dGEgMjAxNSAzOjA3DQo+Pj4+Pj4+Pj4+Pj4+Pj4g VG86IENoYXJsZXMgRWNrZWwgKGVja2VsY3UpDQo+Pj4+Pj4+Pj4+Pj4+Pj4gQ2M6IEdvbnphbG8g Q2FtYXJpbGxvOyBUb20gS3Jpc3RlbnNlbiAodG9ta3Jpc3QpOw0KPj4+Pj4+Pj4+Pj4+Pj4+IGRy YWZ0LWlldGYtYmZjcGJpcy1yZmM0NTgyYmlzQHRvb2xzLmlldGYub3JnOyBCZW4NCj4+Pj4+Pj4+ Pj4+Pj4+PiBDYW1wYmVsbDsgQ2hyaXN0ZXIgSG9sbWJlcmcNCj4+Pj4+Pj4+Pj4+Pj4+PiBTdWJq ZWN0OiBSZTogZHJhZnQtaWV0Zi1iZmNwYmlzLXJmYzQ1ODNiaXMNCj4+Pj4+Pj4+Pj4+Pj4+Pg0K Pj4+Pj4+Pj4+Pj4+Pj4+IEFkZGluZyBDaHJpc3RlciB0byB0aGlzIHRocmVhZC4NCj4+Pj4+Pj4+ Pj4+Pj4+Pg0KPj4+Pj4+Pj4+Pj4+Pj4+IE9uIEFwciA3LCAyMDE1LCBhdCAxMjo0NCBQTSwgQ2hh cmxlcyBFY2tlbCAoZWNrZWxjdSkNCj4+Pj4+Pj4+Pj4+Pj4+PiA8ZWNrZWxjdUBjaXNjby5jb20+ DQo+Pj4+Pj4+Pj4+Pj4+Pj4gd3JvdGU6DQo+Pj4+Pj4+Pj4+Pj4+Pj4NCj4+Pj4+Pj4+Pj4+Pj4+ Pg0KPj4+Pj4+Pj4+Pj4+Pj4+DQo+Pj4+Pj4+Pj4+Pj4+Pj4NCj4+Pj4+Pj4+Pj4+Pj4+PiAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgDQo+Pj4+Pj4+Pj4+Pj4+Pj4+IENocmlzdGVyIChj Y+KAmWQpIGFuZCBJIGRpc2N1c3NlZCBzb21lIG9mIHRoZSBjaGFuZ2VzDQo+Pj4+Pj4+Pj4+Pj4+ Pj4+IG9mZmxpc3QgaW4gRGFsbGFzLCBhbmQgaGUgaXMgdG8gY29tZSBiYWNrIHRvIHRoZSBsaXN0 DQo+Pj4+Pj4+Pj4+Pj4+Pj4+IHdpdGggY29tbWVudHMgYWZ0ZXIgRGFsbGFzDQo+Pj4+Pj4+Pj4+ Pj4+Pj4+IC0gd2hpY2ggaXMgbm93IDopDQo+Pj4+Pj4+Pj4+Pj4+Pj4+DQo+Pj4+Pj4+Pj4+Pj4+ Pj4+IENoZWVycywNCj4+Pj4+Pj4+Pj4+Pj4+Pj4gQ2hhcmxlcw0KPj4+Pj4+Pj4+Pj4+Pj4+Pg0K Pj4+Pj4+Pj4+Pj4+Pj4+PiBPbiA0LzcvMTUsIDEwOjI2IEFNLCAiQWxpc3NhIENvb3BlciI8YWxp c3NhQGNvb3BlcncuaW4+DQo+Pj4+Pj4+Pj4+Pj4+Pj4+IHdyb3RlOg0KPj4+Pj4+Pj4+Pj4+Pj4+ Pg0KPj4+Pj4+Pj4+Pj4+Pj4+Pg0KPj4+Pj4+Pj4+Pj4+Pj4+Pg0KPj4+Pj4+Pj4+Pj4+Pj4+Pg0K Pj4+Pj4+Pj4+Pj4+Pj4+PiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICANCj4+Pj4+ Pj4+Pj4+Pj4+Pj4+IENoZWNraW5nIGluIG9uIHRoaXMg4oCUIGhhcyBDaHJpc3RlciBiZWVuIHBy b21wdGVkIHRvDQo+Pj4+Pj4+Pj4+Pj4+Pj4+PiByZXZpZXcgdGhlIGxhdGVzdCByZXYgb2YgZHJh ZnQtaWV0Zi1iZmNwYmlzLXJmYzQ1ODNiaXM/DQo+Pj4+Pj4+Pj4+Pj4+Pj4+Pg0KPj4+Pj4+Pj4+ Pj4+Pj4+Pj4gVGhhbmtzLA0KPj4+Pj4+Pj4+Pj4+Pj4+Pj4gQWxpc3NhDQo+Pj4+Pj4+Pj4+Pj4+ Pj4+Pg0KPj4+Pj4+Pj4+Pj4+Pj4+Pj4gT24gRmViIDI1LCAyMDE1LCBhdCA5OjE0IEFNLCBDaGFy bGVzIEVja2VsIChlY2tlbGN1KQ0KPj4+Pj4+Pj4+Pj4+Pj4+Pj4gPGVja2VsY3VAY2lzY28uY29t Pg0KPj4+Pj4+Pj4+Pj4+Pj4+Pj4gd3JvdGU6DQo+Pj4+Pj4+Pj4+Pj4+Pj4+Pg0KPj4+Pj4+Pj4+ Pj4+Pj4+Pj4NCj4+Pj4+Pj4+Pj4+Pj4+Pj4+DQo+Pj4+Pj4+Pj4+Pj4+Pj4+Pg0KPj4+Pj4+Pj4+ Pj4+Pj4+Pj4gICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICANCj4+Pj4+Pj4+Pj4+ Pj4+Pj4+PiBNb3N0IG9mIHRoZSBjaGFuZ2VzIEkgdGhpcyByZWNlbnQgdXBkYXRlIHRvIHJmYzQ1 ODNiaXMNCj4+Pj4+Pj4+Pj4+Pj4+Pj4+PiB3ZXJlIGluc3BpcmVkIGJ5IGNvbW1lbnRzIGFuZCBz dWdnZXN0ZWQgdGV4dCBwcm92aWRlZA0KPj4+Pj4+Pj4+Pj4+Pj4+Pj4+IGJ5IENocmlzdGVyLg0K Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+IEhlIGlzIGluIHRoZSBwcm9jZXNzIG9mIHJldmlld2luZy4gSWYg YWxsIGdvZXMgd2VsbA0KPj4+Pj4+Pj4+Pj4+Pj4+Pj4+IHdpdGggdGhhdCwgd2UgYXJlIHJlYWR5 IHRvIHByb2NlZWQgd2l0aCBwcm90byB3cml0ZXVwDQo+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4gKE1hcnkp IGFuZCBBRCByZXZpZXcuDQo+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4NCj4+Pj4+Pj4+Pj4+Pj4+Pj4+PiBD aGVlcnMsDQo+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4gQ2hhcmxlcw0KPj4+Pj4+Pj4+Pj4+Pj4+Pj4+DQo+ Pj4+Pj4+Pj4+Pj4+Pj4+Pj4gT24gMi8yNS8xNSwgNzowMSBBTSwgIkFsaXNzYQ0KPj4+Pj4+Pj4+ Pj4+Pj4+Pj4+IENvb3BlciI8YWxpc3NhQGNvb3BlcncuaW4+DQo+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4g d3JvdGU6DQo+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4NCj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pg0KPj4+Pj4+Pj4+ Pj4+Pj4+Pj4+DQo+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4NCj4+Pj4+Pj4+Pj4+Pj4+Pj4+PiAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgDQo+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+IHJmYzQ1 ODMgaGFzIG5vdCBoYWQgYW4gQUQgcmV2aWV3IHlldC4gUmljaGFyZCBjYW4NCj4+Pj4+Pj4+Pj4+ Pj4+Pj4+Pj4gaG9wZWZ1bGx5IHRha2UgY2FyZSBvZiB0aGF0IHdoaWxlIEnCuW0gb24gbGVhdmUN Cj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4gKHN0YXJ0aW5nIHRvZGF5LCBhY3R1YWxseSkuDQo+Pj4+Pj4+ Pj4+Pj4+Pj4+Pj4+DQo+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+IE9uIEZlYiAyNSwgMjAxNSwgYXQgMjo1 NiBBTSwgR29uemFsbyBDYW1hcmlsbG8NCj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4gPGdvbnphbG8uY2Ft YXJpbGxvQGVyaWNzc29uLmNvbT4gICAgIHdyb3RlOg0KPj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pg0KPj4+ Pj4+Pj4+Pj4+Pj4+Pj4+Pg0KPj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pg0KPj4+Pj4+Pj4+Pj4+Pj4+Pj4+ Pg0KPj4+Pj4+Pj4+Pj4+Pj4+Pj4+PiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICANCj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+IEhpIEFsaXNzYSwNCj4+Pj4+Pj4+Pj4+Pj4+Pj4+ Pj4+DQo+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+PiBJIGhhdmUgbm90ZWQgdGhhdCB3aGlsZSByZmM0NTgy YmlzIGluIG9uIHRoZSBhZ2VuZGENCj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+IG9mIHRoZSBNYXJjaCA1 dGggdGVsZWNoYXQgKHRoYW5rcyBmb3IgaGFuZGxpbmcNCj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+IHRo YXQhKSwgcmZjNDU4M2JpcyBpc24ndC4gVG9tIHJldmlzZWQgcmZjNDU4M2JpcyBvbg0KPj4+Pj4+ Pj4+Pj4+Pj4+Pj4+Pj4gRmVicnVhcnkgMjB0aC4gU2hvdWxkIHJmYzQ1ODNiaXMgYmUgb24gdGhl IGFnZW5kYSBvZg0KPj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4gdGhlIHRlbGVjaGF0IGFzIHdlbGwgb3Ig dGhlcmUgaXMgc3RpbGwgc29tZXRoaW5nDQo+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+PiBsZWZ0IGZvciBU b20gdG8gdGFrZSBjYXJlIG9mPw0KPj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4NCj4+Pj4+Pj4+Pj4+Pj4+ Pj4+Pj4+IFRoYW5rcywNCj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+DQo+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+ PiBHb256YWxvDQo+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pg0KPj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4gT24g MTgvMDIvMjAxNSA5OjI4IFBNLCBBbGlzc2EgQ29vcGVyIHdyb3RlOg0KPj4+Pj4+Pj4+Pj4+Pj4+ Pj4+Pj4NCj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+DQo+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pg0KPj4+Pj4+ Pj4+Pj4+Pj4+Pj4+Pj4gICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAN Cj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+PiBQaW5naW5nIG9uIHRoaXMuDQo+Pj4+Pj4+Pj4+Pj4+Pj4+ Pj4+Pj4NCj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+PiBNYXJjaCA1IHdpbGwgbGlrZWx5IGJlIG15IGxh c3QgdGVsZWNoYXQgYmVmb3JlDQo+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4gZ29pbmcgb24gbGVhdmUs IHNvICBpdCB3b3VsZCBiZSBncmVhdCB0byBnZXQgdGhpcw0KPj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+ IHNjaGVkdWxlZCBvbiB0aGF0IG9uZS4gVG8gZG8gdGhhdCwgIHRoZSByZXYgbmVlZHMNCj4+Pj4+ Pj4+Pj4+Pj4+Pj4+Pj4+PiB0byBiZSBwb3N0ZWQgdG9kYXkuDQo+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+ Pj4gVGhlIHVwZGF0ZXMgYXJlIHByZXR0eSBtaW5pbWFsICBhbmQgYXJlIGFsbA0KPj4+Pj4+Pj4+ Pj4+Pj4+Pj4+Pj4+IGJhc2ljYWxseSB3cml0dGVuIHVwIGluIENoYXJsZXPCuSByZXNwb25zZSB0 byBteSBBRCByZXZpZXcuDQo+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4NCj4+Pj4+Pj4+Pj4+Pj4+Pj4+ Pj4+PiBBbGlzc2ENCj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pg0KPj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+ IE9uIEZlYiAxNSwgMjAxNSwgYXQgOToxMyBBTSwgR29uemFsbyBDYW1hcmlsbG8NCj4+Pj4+Pj4+ Pj4+Pj4+Pj4+Pj4+PiA8Z29uemFsby5jYW1hcmlsbG9AZXJpY3Nzb24uY29tDQo+Pj4+Pj4+Pj4+ Pj4+Pj4+Pj4+Pj4gPG1haWx0bzpnb256YWxvLmNhbWFyaWxsb0Blcmljc3Nvbi5jb20+Pg0KPj4+ Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+IHdyb3RlOg0KPj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+DQo+Pj4+Pj4+ Pj4+Pj4+Pj4+Pj4+Pj4NCj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pg0KPj4+Pj4+Pj4+Pj4+Pj4+Pj4+ Pj4+DQo+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4gICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgIA0KPj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+PiBJIGhhdmUgdGFsa2VkIG9mZmxp bmUgd2l0aCB0aGUgb3RoZXIgYXV0aG9ycyBhbmQNCj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4gVG9t IGlzIGhvbGRpbmcgdGhlIHBlbi4gVG9tLCBkbyB5b3UgdGhpbmsgeW91IGNhbg0KPj4+Pj4+Pj4+ Pj4+Pj4+Pj4+Pj4+PiBtZWV0IHRoZSB0aW1lIGZyYW1lIGJlbG93Pw0KPj4+Pj4+Pj4+Pj4+Pj4+ Pj4+Pj4+Pg0KPj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+PiBDaGVlcnMsDQo+Pj4+Pj4+Pj4+Pj4+Pj4+ Pj4+Pj4+DQo+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+IEdvbnphbG8NCj4+Pj4+Pj4+Pj4+Pj4+Pj4+ Pj4+Pj4NCj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4gU2VudCBmcm9tIG15IG1vYmlsZQ0KPj4+Pj4+ Pj4+Pj4+Pj4+Pj4+Pj4+Pg0KPj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pg0KPj4+Pj4+Pj4+Pj4+Pj4+ Pj4+Pj4+Pg0KPj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+PiAtLS0tIEFsaXNzYSBDb29wZXIgd3JvdGUg LS0tLQ0KPj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pg0KPj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+PiBKdXN0 IHdhbnRlZCB0byBzZWUgaWYgdGhpcyByZXYgbWlnaHQgZ2V0IGRvbmUgaW4NCj4+Pj4+Pj4+Pj4+ Pj4+Pj4+Pj4+Pj4gdGhlIG5leHQgY291cGxlICBvZiBkYXlzLiBJZiBzbywgd2UgY291bGQgZ2V0 IGl0DQo+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+IG9uIHRoZSBuZXh0IHRlbGVjaGF0IGFnZW5kYSAo TWFyY2ggNSkuDQo+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+DQo+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+ IEFsaXNzYQ0KPj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pg0KPj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+PiBC ZWdpbiBmb3J3YXJkZWQgbWVzc2FnZToNCj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4NCj4+Pj4+Pj4+ Pj4+Pj4+Pj4+Pj4+Pj4NCj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4NCj4+Pj4+Pj4+Pj4+Pj4+Pj4+ Pj4+Pj4NCj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4gICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgDQo+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+PiAqRnJvbTogKkFsaXNz YSBDb29wZXI8YWxpc3NhQGNvb3BlcncuaW4NCj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+IDxtYWls dG86YWxpc3NhQGNvb3BlcncuaW4+Pg0KPj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4gKlN1YmplY3Q6 ICoqUmU6IFtiZmNwYmlzXSBBRCBldmFsdWF0aW9uOg0KPj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4g ZHJhZnQtaWV0Zi1iZmNwYmlzLXJmYzQ1ODJiaXMtMTIqDQo+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+ PiAqRGF0ZTogKkZlYnJ1YXJ5IDksIDIwMTUgYXQgMzo1ODo1MiBQTSBQU1QNCj4+Pj4+Pj4+Pj4+ Pj4+Pj4+Pj4+Pj4+ICpUbzogKiJDaGFybGVzIEVja2VsIChlY2tlbGN1KSI8ZWNrZWxjdUBjaXNj by5jb20NCj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+IDxtYWlsdG86ZWNrZWxjdUBjaXNjby5jb20+ Pg0KPj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4gKkNjOiAqImJmY3BiaXNAaWV0Zi5vcmc8bWFpbHRv OmJmY3BiaXNAaWV0Zi5vcmc+Ig0KPj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4gPGJmY3BiaXNAaWV0 Zi5vcmc8bWFpbHRvOmJmY3BiaXNAaWV0Zi5vcmc+Pg0KPj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4N Cj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+IEhpIENoYXJsZXMsDQo+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+ Pj4+Pg0KPj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4gVGhhbmtzLCBzb21lIHJlc3BvbnNlcyBpbmxp bmUuDQo+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pg0KPj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4gT24g RmViIDQsIDIwMTUsIGF0IDEwOjQwIEFNLCBDaGFybGVzIEVja2VsIChlY2tlbGN1KQ0KPj4+Pj4+ Pj4+Pj4+Pj4+Pj4+Pj4+Pj4gPGVja2VsY3VAY2lzY28uY29tPG1haWx0bzplY2tlbGN1QGNpc2Nv LmNvbT4+ICAgICB3cm90ZToNCj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+DQo+Pj4+Pj4+Pj4+Pj4+ Pj4+Pj4+Pj4+Pg0KPj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4NCj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+ Pj4+DQo+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+PiAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgIA0KPj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+IEhJIEFsaXNzYSwN Cj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pg0KPj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+IFRoYW5r IHlvdSBmb3IgdGhlIHJldmlldy4gUGxlYXNlIHNlZSBteSB0aG91Z2h0cw0KPj4+Pj4+Pj4+Pj4+ Pj4+Pj4+Pj4+Pj4+IG9uIHlvdXIgY29tbWVudHMgYW5kIHF1ZXN0aW9ucyBpbmxpbmUuDQo+Pj4+ Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4NCj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+PiBGcm9tOiBBbGlz c2EgQ29vcGVyPGFsaXNzYUBjb29wZXJ3LmluDQo+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4gPG1h aWx0bzphbGlzc2FAY29vcGVydy5pbj4+DQo+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4gRGF0ZTog VGh1cnNkYXksIEphbnVhcnkgMjksIDIwMTUgYXQgMTA6MTkgUE0NCj4+Pj4+Pj4+Pj4+Pj4+Pj4+ Pj4+Pj4+PiBUbzogImJmY3BiaXNAaWV0Zi5vcmc8bWFpbHRvOmJmY3BiaXNAaWV0Zi5vcmc+Ig0K Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+IDxiZmNwYmlzQGlldGYub3JnPG1haWx0bzpiZmNwYmlz QGlldGYub3JnPj4NCj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+PiBTdWJqZWN0OiBbYmZjcGJpc10g QUQgZXZhbHVhdGlvbjoNCj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+PiBkcmFmdC1pZXRmLWJmY3Bi aXMtcmZjNDU4MmJpcy0xMg0KPj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+DQo+Pj4+Pj4+Pj4+Pj4+ Pj4+Pj4+Pj4+Pj4NCj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pg0KPj4+Pj4+Pj4+Pj4+Pj4+Pj4+ Pj4+Pj4+DQo+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4gICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgIA0KPj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+PiBJIGhh dmUgcmV2aWV3ZWQgdGhpcyBkcmFmdCBpbiBwcmVwYXJhdGlvbiBmb3IgSUVURiBMQy4NCj4+Pj4+ Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4gT3ZlcmFsbCB0aGUgZG9jdW1lbnQgYXBwZWFycyBpbiBnb29k IHNoYXBlLiBJDQo+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+IGhhdmUgYSBmZXcgcXVlc3Rpb25z IGFuZCBjb21tZW50cyBJwrlkIGxpa2UgdG8NCj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4gZGlz Y3VzcyBiZWZvcmUgaXNzdWluZyB0aGUgSUVURiBsYXN0IGNhbGwuIEnCuXZlDQo+Pj4+Pj4+Pj4+ Pj4+Pj4+Pj4+Pj4+Pj4+IGFsc28gaW5jbHVkZWQgc29tZSBlZGl0b3JpYWwgbml0cyB0aGF0IHNo b3VsZA0KPj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+PiBiZSBhZGRyZXNzZWQgdG9nZXRoZXIgd2l0 aCBhbnkgbGFzdCBjYWxsIGNvbW1lbnRzLg0KPj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pg0KPj4+ Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+PiBDb21tZW50cyBhbmQgcXVlc3Rpb25zOg0KPj4+Pj4+Pj4+ Pj4+Pj4+Pj4+Pj4+Pj4+Pg0KPj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+PiA9IFNlY3Rpb24gNS4x ID0gIklmIGFuIGVuZHBvaW50IHJlY2VpdmVzIGENCj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4g bWVzc2FnZSB3aXRoIGFuIHVuc3VwcG9ydGVkIHZlcnNpb24gZmllbGQNCj4+Pj4+Pj4+Pj4+Pj4+ Pj4+Pj4+Pj4+Pj4gdmFsdWUsIHRoZSByZWNlaXZpbmcgc2VydmVyIE1VU1Qgc2VuZCBhbiBFcnJv cg0KPj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+PiBtZXNzYWdlIHdpdGggcGFyYW1ldGVyIHZhbHVl IDEyIChVbnN1cHBvcnRlZA0KPj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+PiBWZXJzaW9uKSB0byBp bmRpY2F0ZSB0aGlzLsKyDQo+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+DQo+Pj4+Pj4+Pj4+Pj4+ Pj4+Pj4+Pj4+Pj4+IFRoaXMgc2VlbXMgYSBsaXR0bGUgbWlzbGVhZGluZyBzaW5jZSBSRkMgNDU4 Mg0KPj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+PiBkaWRuwrl0IHNwZWNpZnkgd2hhdCB0byBkbyB1 cG9uIHJlY2VpcHQgb2YgYQ0KPj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+PiBtZXNzYWdlIHdpdGgg YSB2ZXJzaW9uIG90aGVyIHRoYW4gMS4NCj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4gSW1wbGVt ZW50YXRpb25zIHRoYXQgZG8gbm90IGdldCB1cGdyYWRlZCB0byBiZQ0KPj4+Pj4+Pj4+Pj4+Pj4+ Pj4+Pj4+Pj4+PiBjb21wbGlhbnQgd2l0aCAgNDU4MmJpcyAod2hpY2ggY291bGQgY2VydGFpbmx5 DQo+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+IGFjY291bnQgZm9yIHNvbWUgb2YgdGhvc2UgdGhh dCAgd2lsbCBub3QNCj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4gc3VwcG9ydCB2ZXJzaW9uIDIp IHdpbGwgdGhlcmVmb3JlIG5ldmVyIHNlbmQNCj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4gdGhl ICBlcnJvciBzcGVjaWZpZWQgaGVyZS4NCj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4gVGhpcyBz ZWVtcyBsaWtlIGl0IHNob3VsZCBhdCBsZWFzdCBiZSAgbm90ZWQNCj4+Pj4+Pj4+Pj4+Pj4+Pj4+ Pj4+Pj4+Pj4gZ2l2ZW4gdGhlIE1VU1QtbGV2ZWwgcmVxdWlyZW1lbnQuIFRoZSBzYW1lDQo+Pj4+ Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+IGFwcGxpZXMgaW4gU2VjdGlvbiAxMy43Lg0KPj4+Pj4+Pj4+ Pj4+Pj4+Pj4+Pj4+Pj4+Pg0KPj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pg0KPj4+Pj4+Pj4+Pj4+ Pj4+Pj4+Pj4+Pj4+Pg0KPj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+PiAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICANCj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+ Pj4+PiBHb29kIHBvaW50LiBJIGJlbGlldmUgd2UgbWFkZSB0aGlzIGEgTVVTVA0KPj4+Pj4+Pj4+ Pj4+Pj4+Pj4+Pj4+Pj4+IGJlY2F1c2Ugd2Ugd2VyZSB0aGlua2luZyBpbiB0ZXJtcyBvZg0KPj4+ Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+IGltcGxlbWVudGF0aW9ucyBjb21wbGlhbnQgd2l0aCB0aGlz IGJpcyB2ZXJzaW9uLg0KPj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+IEFkZGluZw0KPj4+Pj4+Pj4+ Pj4+Pj4+Pj4+Pj4+Pj4+IHlvdXIgc3VnZ2VzdGVkIG5vdGUgYWJvdXQgcmZjIDQ1ODINCj4+Pj4+ Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+PiBpbXBsZW1lbnRhdGlvbnMgaGVyZSBhbmQgaW4gIHNlY3Rpb24g MTMuNyBzZWVtcyB1c2VmdWwgdG8gbWUuDQo+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4NCj4+Pj4+ Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pg0KPj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+DQo+Pj4+Pj4+Pj4+ Pj4+Pj4+Pj4+Pj4+Pj4gICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgIA0KPj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4gT2sNCj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+ Pj4+DQo+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pg0KPj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4NCj4+ Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+DQo+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+PiAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIA0KPj4+Pj4+Pj4+Pj4+Pj4+Pj4+ Pj4+Pj4+DQo+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4gICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgIA0KPj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+PiA9IFNl Y3Rpb24gNyA9DQo+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+ICJCRkNQIGVudGl0aWVzIE1VU1Qg c3VwcG9ydCwgYXQgYSBtaW5pbXVtLCB0aGUNCj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4gVExT X1JTQV9XSVRIX0FFU18xMjhfQ0JDX1NIQSBjaXBoZXJzdWl0ZSBbNl0uwrINCj4+Pj4+Pj4+Pj4+ Pj4+Pj4+Pj4+Pj4+Pj4NCj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4gSSByZWFsaXplIHRoaXMg cmVxdWlyZW1lbnQgY29tZXMgZnJvbSBSRkMgNDU4MiwNCj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+ Pj4gYnV0IEnCuWQgbGlrZSB0byB1bmRlcnN0YW5kIHdoeSBpdCBoYXMgbm90IGJlZW4NCj4+Pj4+ Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4gdXBkYXRlZCB0byBiZSBjb25zaXN0ZW50IHdpdGggbW9yZSBj dXJyZW50DQo+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+IGd1aWRhbmNlIG9uIGNpcGhlciBzdWl0 ZSBzZWxlY3Rpb24gKGUuZy4sDQo+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+DQo+Pj4+Pj4+Pj4+ Pj4+Pj4+Pj4+Pj4+Pj4+IGh0dHBzOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC1pZXRmLXV0 YS10bHMtDQo+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+IGJjDQo+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+ Pj4+Pj4+IHANCj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4gLQ0KPj4+Pj4+Pj4+Pj4+Pj4+Pj4+ Pj4+Pj4+PiAwDQo+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+IDgNCj4+Pj4+Pj4+Pj4+Pj4+Pj4+ Pj4+Pj4+Pj4gIw0KPj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+PiBzDQo+Pj4+Pj4+Pj4+Pj4+Pj4+ Pj4+Pj4+Pj4+IGUNCj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4gYw0KPj4+Pj4+Pj4+Pj4+Pj4+ Pj4+Pj4+Pj4+PiB0aW9uDQo+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+IC00KQ0KPj4+Pj4+Pj4+ Pj4+Pj4+Pj4+Pj4+Pj4+PiAuDQo+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+DQo+Pj4+Pj4+Pj4+ Pj4+Pj4+Pj4+Pj4+Pj4+DQo+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+DQo+Pj4+Pj4+Pj4+Pj4+ Pj4+Pj4+Pj4+Pj4+ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgIA0KPj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+IEhvdyBhYm91dCB3ZSBrZWVwIHRoaXMg bWluaW11bSByZXF1aXJlbWVudCwgYW5kDQo+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4gYWRkIGEg cmVmZXJlbmNlIHRvIGRyYWZ0LWlldGYtdXRhLXRscy1iY3AgYWxvbmcNCj4+Pj4+Pj4+Pj4+Pj4+ Pj4+Pj4+Pj4+PiB3aXRoIGEgcmVjb21tZW5kYXRpb24gdG8gYWRoZXJlIHRvIHRoZSBiZXN0DQo+ Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4gcHJhY3RpY2VzIGl0IG91dGxpbmVzIGluIHNlY3Rpb24g ND8NCj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pg0KPj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+DQo+ Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4NCj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+PiAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgDQo+Pj4+Pj4+Pj4+Pj4+ Pj4+Pj4+Pj4+PiBJIHRoaW5rIE1VU1Qgc3VwcG9ydCBUTFNfUlNBX1dJVEhfQUVTXzEyOF9DQkNf U0hBDQo+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+PiBmb3IgYmFja3dhcmRzIGNvbXBhdGliaWxpdHkg YW5kIFNIT1VMRCBzdXBwb3J0DQo+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+PiB0aGUgb25lcyBsaXN0 ZWQgaW4gdGhlIFVUQSBkcmFmdHMgd291bGQgYmUgb2suDQo+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+ Pg0KPj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4NCj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+DQo+Pj4+ Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pg0KPj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4gICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICANCj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+ Pj4+Pg0KPj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+ICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICANCj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4gPSBTZWN0 aW9ucyA4LCA4LjEsIDguMiA9IEl0IHNlZW1zIGxpa2UgdGhlDQo+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+ Pj4+Pj4+IHRyYW5zYWN0aW9uIElEIHJlcXVpcmVtZW50cyByZWdhcmRpbmcNCj4+Pj4+Pj4+Pj4+ Pj4+Pj4+Pj4+Pj4+Pj4gbm9uLXJldXNlL21vbm90b25pY2FsbHkgaW5jcmVhc2luZyBJRHMgYXJl DQo+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+IHJlLXN0YXRlZCBtdWx0aXBsZSB0aW1lcyBhY3Jv c3MgdGhlc2UgdGhyZWUNCj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4gc2VjdGlvbnMsIGluIHNs aWdodGx5IGRpZmZlcmVudCB3YXlzLCB0byB0aGUNCj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4g cG9pbnQgd2hlcmUgaXTCuXMgbm90IGNsZWFyIGV4YWN0bHkgd2hhdCB0aGV5IGFyZS4NCj4+Pj4+ Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4gSXQgc2VlbXMgbGlrZSB0aGV5IGFyZToNCj4+Pj4+Pj4+Pj4+ Pj4+Pj4+Pj4+Pj4+Pj4NCj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4gKDEpIFJlbGlhYmxlIHRy YW5zcG9ydCwgc2VydmVyLWluaXRpYXRlZCB0cmFuc2FjdGlvbjoNCj4+Pj4+Pj4+Pj4+Pj4+Pj4+ Pj4+Pj4+Pj4gSUQgaXMNCj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4gMA0KPj4+Pj4+Pj4+Pj4+ Pj4+Pj4+Pj4+Pj4+PiAoMikgVW5yZWxpYWJsZSB0cmFuc3BvcnQsIHNlcnZlci1pbml0aWF0ZWQN Cj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4gdHJhbnNhY3Rpb246DQo+Pj4+Pj4+Pj4+Pj4+Pj4+ Pj4+Pj4+Pj4+IElEIE1VU1QgYmUgbW9ub3RvbmljYWxseSBpbmNyZWFzaW5nIChleGNlcHQgZm9y DQo+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+IHdyYXAtYXJvdW5kKQ0KPj4+Pj4+Pj4+Pj4+Pj4+ Pj4+Pj4+Pj4+PiAoMykgUmVsaWFibGUgdHJhbnNwb3J0LCBjbGllbnQtaW5pdGlhdGVkIHRyYW5z YWN0aW9uOg0KPj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+PiBJRCBNVVNUIE5PVCBiZSAwIGFuZCBN VVNUIE5PVCBiZSByZXVzZWQgaW4NCj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4gYW5vdGhlciBt ZXNzYWdlIGZyb20gdGhlIGNsaWVudCB1bnRpbCBhDQo+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+ IHJlc3BvbnNlDQo+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+DQo+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+ Pj4+Pj4+ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg IA0KPj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+ID5mcm9tIHRoZSBzZXJ2ZXIgaXMgcmVjZWl2ZWQg Zm9yIHRoZQ0KPj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+ICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICANCj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4gdHJh bnNhY3Rpb24sDQo+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+ICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIA0KPj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+ ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICANCj4+Pj4+ Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4gYnV0IG5lZWQgbm90IGJlIG1vbm90b25pY2FsbHkgaW5jcmVh c2luZyAoZS5nLiwNCj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4gYSBsb3dlciwgcmVjZW50bHkg dXNlZCBJRCBjb3VsZCBiZSByZS11c2VkIG9uY2UNCj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4g YSByZXNwb25zZSBpcw0KPj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+PiByZWNlaXZlZCkNCj4+Pj4+ Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4gKDQpIFVucmVsaWFibGUgdHJhbnNwb3J0LCBjbGllbnQtaW5p dGlhdGVkDQo+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+IHRyYW5zYWN0aW9uOg0KPj4+Pj4+Pj4+ Pj4+Pj4+Pj4+Pj4+Pj4+PiBJRCBNVVNUIGJlIG1vbm90b25pY2FsbHkgaW5jcmVhc2luZyAoZXhj ZXB0IGZvcg0KPj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+PiB3cmFwLWFyb3VuZCkNCj4+Pj4+Pj4+ Pj4+Pj4+Pj4+Pj4+Pj4+Pj4NCj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4gSXMgKDMpIHRoZSBj b3JyZWN0IGludGVycHJldGF0aW9uIG9mIHRoZSB0ZXh0IGluIDguMT8NCj4+Pj4+Pj4+Pj4+Pj4+ Pj4+Pj4+Pj4+Pj4gSWYgc28sIHdoeSBub3QganVzdCByZXF1aXJlIElEcyBpbiBhbGwNCj4+Pj4+ Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4gY2xpZW50LWluaXRpYXRlZCB0cmFuc2FjdGlvbnMgdG8gYmUN Cj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4gbW9ub3RvbmljYWxseSBpbmNyZWFzaW5nPw0KPj4+ Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pg0KPj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pg0KPj4+Pj4+ Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pg0KPj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+PiAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICANCj4+Pj4+Pj4+Pj4+Pj4+ Pj4+Pj4+Pj4+PiBBZ3JlZSB3ZSBjYW4gYW5kIHNob3VsZCBzaW1wbGlmeSB0aGlzLiBTZWN0aW9u cw0KPj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+IDguMSBhbmQNCj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+ Pj4+PiA4LjIgY292ZXIgdGhlIGNsaWVudCBiZWhhdmlvciBhbmQgc2VydmVyDQo+Pj4+Pj4+Pj4+ Pj4+Pj4+Pj4+Pj4+Pj4gYmVoYXZpb3IgaW4gZGV0YWlsLiBBcyBzdWNoLCB0aGUgdHJhbnNhY3Rp b24gSUQNCj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+PiByZWxhdGVkIGluZm9ybWF0aW9uIGF0IHRo ZSBzdGFydCBvZiBTZWN0aW9uIDggaXMgc3VwZXJmbHVvdXMuDQo+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+ Pj4+Pj4gSSByZWNvbW1lbmQgcmVkdWNpbmcgdGhlIHRleHQgaW4gU2VjdGlvbiA4IHRvDQo+Pj4+ Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4gdGhlDQo+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4gZm9sbG93 Og0KPj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+DQo+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4gOC4g UHJvdG9jb2wgVHJhbnNhY3Rpb25zDQo+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4NCj4+Pj4+Pj4+ Pj4+Pj4+Pj4+Pj4+Pj4+PiBJbiBCRkNQLCB0aGVyZSBhcmUgdHdvIHR5cGVzIG9mIHRyYW5zYWN0 aW9uczoNCj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+PiBjbGllbnQtaW5pdGlhdGVkIHRyYW5zYWN0 aW9ucyBhbmQNCj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+PiBzZXJ2ZXItaW5pdGlhdGVkIHRyYW5z YWN0aW9ucy4NCj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pg0KPj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+ Pj4+IENsaWVudC1pbml0aWF0ZWQgdHJhbnNhY3Rpb25zIGNvbnNpc3Qgb2YgYQ0KPj4+Pj4+Pj4+ Pj4+Pj4+Pj4+Pj4+Pj4+IHJlcXVlc3QgZnJvbSBhIGNsaWVudCB0byBhIGZsb29yIGNvbnRyb2wg c2VydmVyDQo+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4gYW5kIGEgcmVzcG9uc2UgZnJvbSB0aGUg Zmxvb3IgY29udHJvbCBzZXJ2ZXIgdG8gdGhlIGNsaWVudC4NCj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+ Pj4+Pg0KPj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+IFNlcnZlci1pbml0aWF0ZWQgdHJhbnNhY3Rp b25zIGhhdmUgZGlmZmVyZW50DQo+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4gYmVoYXZpb3IgZGVw ZW5kaW5nIG9uIHVuZGVybHlpbmcgdHJhbnNwb3J0Og0KPj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+ DQo+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4gICAgICAgIFdoZW4gdXNpbmcgYSByZWxpYWJsZSB0 cmFuc3BvcnQsDQo+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4gc2VydmVyLWluaXRpYXRlZCB0cmFu c2FjdGlvbnMNCj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+PiAgICAgICAgY29uc2lzdCBvZiBhIHNp bmdsZSBtZXNzYWdlIGZyb20gYSBmbG9vcg0KPj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+IGNvbnRy b2wgc2VydmVyIHRvIGENCj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+PiAgICAgICAgY2xpZW50IChu b3RpZmljYXRpb25zKS4gIFRoZXkgZG8gbm90DQo+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4gdHJp Z2dlciBhbnkgcmVzcG9uc2UuDQo+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4NCj4+Pj4+Pj4+Pj4+ Pj4+Pj4+Pj4+Pj4+PiAgICAgICAgV2hlbiB1c2luZyBhbiB1bnJlbGlhYmxlIHRyYW5zcG9ydCwN Cj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+PiBzZXJ2ZXItaW5pdGlhdGVkIHRyYW5zYWN0aW9ucw0K Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+ICAgICAgICBjb25zaXN0IG9mIGEgcmVxdWVzdCBmcm9t IGEgZmxvb3IgY29udHJvbA0KPj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+IHNlcnZlciB0byBhIGNs aWVudCBhbmQgYQ0KPj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+ICAgICAgICByZXNwb25zZSBmcm9t IHRoZSBjbGllbnQgdG8gdGhlIGZsb29yDQo+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4gY29udHJv bCBzZXJ2ZXIuDQo+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4NCj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+ Pj4+PiBXaGVuIHVzaW5nIEJGQ1Agb3ZlciBhbiB1bnJlbGlhYmxlIHRyYW5zcG9ydCwNCj4+Pj4+ Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+PiByZXRyYW5zbWlzc2lvbiB0aW1lciBUMSAoc2VlIFNlY3Rpb24g OC4zKSBNVVNUDQo+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4gYmUgdXNlZCBmb3IgYWxsIHJlcXVl c3RzIHVudGlsIHRoZSB0cmFuc2FjdGlvbg0KPj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+IGlzIGNv bXBsZXRlZC4NCj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pg0KPj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+ Pj4+IFRoZW4gaW4gc2VjdGlvbiA4LjEsIHdlIGFkZCB0aGUgaW1wb3J0YW50DQo+Pj4+Pj4+Pj4+ Pj4+Pj4+Pj4+Pj4+Pj4gZGV0YWlscyByZW1vdmVkIGZyb20gc2VjdGlvbiA4Lg0KPj4+Pj4+Pj4+ Pj4+Pj4+Pj4+Pj4+Pj4+DQo+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4gOC4xLjEgQ2xpZW50IEJl aGF2aW9yDQo+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4NCj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+ PiBBIGNsaWVudCBzdGFydGluZyBhIGNsaWVudC1pbml0aWF0ZWQgdHJhbnNhY3Rpb24NCj4+Pj4+ Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+PiBNVVNUIHNldCB0aGUgQ29uZmVyZW5jZSBJRCBpbiB0aGUgY29t bW9uIGhlYWRlcg0KPj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+IG9mIHRoZSBtZXNzYWdlIHRvIHRo ZSBDb25mZXJlbmNlIElEIGZvciB0aGUNCj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+PiBjb25mZXJl bmNlIHRoYXQgdGhlIGNsaWVudCBvYnRhaW5lZCBwcmV2aW91c2x5Lg0KPj4+Pj4+Pj4+Pj4+Pj4+ Pj4+Pj4+Pj4+DQo+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4gVGhlIGNsaWVudCBNVVNUIHNldCB0 aGUgVHJhbnNhY3Rpb24gSUQgdmFsdWUgaW4NCj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+PiB0aGUg Y29tbW9uIGhlYWRlciB0byBhIG51bWJlciB0aGF0IGlzIGRpZmZlcmVudA0KPj4+Pj4+Pj4+Pj4+ Pj4+Pj4+Pj4+Pj4+DQo+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4gICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIA0KPj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4g PmZyb20gMCBhbmQgdGhhdCBNVVNUIE5PVCBiZSByZXVzZWQgaW4gYW5vdGhlcg0KPj4+Pj4+Pj4+ Pj4+Pj4+Pj4+Pj4+Pj4NCj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+ICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgDQo+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4g bWVzc2FnZSBmcm9tIHRoZSBjbGllbnQgdW50aWwgYSByZXNwb25zZSBmcm9tDQo+Pj4+Pj4+Pj4+ Pj4+Pj4+Pj4+Pj4+Pj4gdGhlIHNlcnZlciBpcyByZWNlaXZlZCBmb3IgdGhlIHRyYW5zYWN0aW9u Lg0KPj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+IFRoZSBjbGllbnQgdXNlcyB0aGUgVHJhbnNhY3Rp b24gSUQgdmFsdWUgdG8NCj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+PiBtYXRjaCB0aGlzIG1lc3Nh Z2Ugd2l0aCB0aGUgcmVzcG9uc2UgZnJvbSB0aGUNCj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+PiBm bG9vciBjb250cm9sIHNlcnZlci4NCj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+PiBXaGVuIHVzaW5n IEJGQ1Agb3ZlciBhbiB1bnJlbGlhYmxlIHRyYW5zcG9ydCwgaXQNCj4+Pj4+Pj4+Pj4+Pj4+Pj4+ Pj4+Pj4+PiBpcyBpbXBvcnRhbnQgdG8gY2hvb3NlIGEgVHJhbnNhY3Rpb24gSUQgdmFsdWUNCj4+ Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+PiB0aGF0IGxldHMgdGhlIHJlY2VpdmVyIGRpc3Rpbmd1aXNo IHRoZSByZWNlcHRpb24NCj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+PiBvZiB0aGUgbmV4dCBtZXNz YWdlIGluIGEgc2VxdWVuY2Ugb2YgQkZDUA0KPj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+IG1lc3Nh Z2VzIGZyb20gYSByZXRyYW5zbWlzc2lvbiBvZiBhIHByZXZpb3VzDQo+Pj4+Pj4+Pj4+Pj4+Pj4+ Pj4+Pj4+Pj4gbWVzc2FnZS4gIFRoZXJlZm9yZSwgQkZDUCBlbnRpdGllcyB1c2luZyBhbg0KPj4+ Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+IHVucmVsaWFibGUgdHJhbnNwb3J0IE1VU1QgdXNlIG1vbm90 b25pY2FsbHkNCj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+PiBpbmNyZWFzaW5nIFRyYW5zYWN0aW9u IElEIHZhbHVlcyAoZXhjZXB0IGZvciB3cmFwLWFyb3VuZCkuDQo+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+ Pj4+Pj4NCj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+PiBBIGNsaWVudCByZWNlaXZpbmcgYSBzZXJ2 ZXItaW5pdGlhdGVkDQo+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4gdHJhbnNhY3Rpb24gb3ZlciBh biB1bnJlbGlhYmxlIHRyYW5zcG9ydCBNVVNUDQo+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4gY29w eSB0aGUgVHJhbnNhY3Rpb24gSUQgZnJvbSB0aGUgcmVxdWVzdA0KPj4+Pj4+Pj4+Pj4+Pj4+Pj4+ Pj4+Pj4+IHJlY2VpdmVkIGZyb20gdGhlIHNlcnZlciBpbnRvIHRoZSByZXNwb25zZS4NCj4+Pj4+ Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+PiBbUXVlc3Rpb246IGlzIHRoZXJlIGEgbmVlZCB0byBjb3B5IHRo ZQ0KPj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+IENvbmZlcmVuY2UgSUQgYW5kICBVc2VyIElELCBp ZiBwcmVzZW50P10NCj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pg0KPj4+Pj4+Pj4+Pj4+Pj4+Pj4+ Pj4+Pj4+IDguMi4gU2VydmVyIEJlaGF2aW9yDQo+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4NCj4+ Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+PiBBIGZsb29yIGNvbnRyb2wgc2VydmVyIHNlbmRpbmcgYSBy ZXNwb25zZSB3aXRoaW4NCj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+PiBhIGNsaWVudC1pbml0aWF0 ZWQgdHJhbnNhY3Rpb24gTVVTVCBjb3B5IHRoZQ0KPj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+IENv bmZlcmVuY2UgSUQsIHRoZSBUcmFuc2FjdGlvbiBJRCwgYW5kIHRoZSBVc2VyDQo+Pj4+Pj4+Pj4+ Pj4+Pj4+Pj4+Pj4+Pj4gSUQNCj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pg0KPj4+Pj4+Pj4+Pj4+ Pj4+Pj4+Pj4+Pj4+ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICANCj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+ID5mcm9tIHRoZSByZXF1ZXN0IHJlY2VpdmVk IGZyb20gdGhlIGNsaWVudCBpbnRvDQo+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+PiAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIA0KPj4+Pj4+Pj4+Pj4+Pj4+Pj4+ Pj4+Pj4+IHRoZQ0KPj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+ICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICANCj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+DQo+ Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+PiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgIA0KPj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+IHJlc3BvbnNlLg0KPj4+Pj4+ Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+DQo+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4gU2VydmVyLWluaXRp YXRlZCB0cmFuc2FjdGlvbnMgTVVTVCBjb250YWluIGENCj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+ PiBUcmFuc2FjdGlvbiBJRCBlcXVhbCB0bw0KPj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+IDAgd2hl biBCRkNQIGlzIHVzZWQgb3ZlciBhIHJlbGlhYmxlIHRyYW5zcG9ydC4NCj4+Pj4+Pj4+Pj4+Pj4+ Pj4+Pj4+Pj4+PiBPdmVyIGFuIHVucmVsaWFibGUgdHJhbnNwb3J0LCB0aGUgVHJhbnNhY3Rpb24g SUQNCj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+PiBzaGFsbCBoYXZlIHRoZSBzYW1lIHByb3BlcnRp ZXMgYXMgZm9yDQo+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4gY2xpZW50LWluaXRpYXRlZCB0cmFu c2FjdGlvbnMuDQo+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4gVGhlIHNlcnZlciB1c2VzIHRoZSBU cmFuc2FjdGlvbiBJRCB2YWx1ZSB0bw0KPj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+IG1hdGNoIHRo aXMgbWVzc2FnZSB3aXRoIHRoZSByZXNwb25zZSBmcm9tIHRoZQ0KPj4+Pj4+Pj4+Pj4+Pj4+Pj4+ Pj4+Pj4+IGZsb29yIHBhcnRpY2lwYW50IG9yIGZsb29yIGNoYWlyLg0KPj4+Pj4+Pj4+Pj4+Pj4+ Pj4+Pj4+Pj4+DQo+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4NCj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+ Pj4+Pg0KPj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+DQo+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4g ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIA0KPj4+Pj4+ Pj4+Pj4+Pj4+Pj4+Pj4+Pj4gVGhhbmtzLCB0aGlzIGlzIGJldHRlci4NCj4+Pj4+Pj4+Pj4+Pj4+ Pj4+Pj4+Pj4+DQo+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pg0KPj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+ Pj4NCj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+DQo+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+PiAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIA0KPj4+Pj4+Pj4+Pj4+ Pj4+Pj4+Pj4+Pj4+PiA9IFNlY3Rpb24gOSAoaW1wYWN0cyBTZWN0aW9uIDE0IGFzIHdlbGwpID0N Cj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4gIkJGQ1AgY2xpZW50cyAgU0hPVUxEIGF1dGhlbnRp Y2F0ZSB0aGUgZmxvb3INCj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4gY29udHJvbCBzZXJ2ZXIg YmVmb3JlICBzZW5kaW5nIGFueSBCRkNQIG1lc3NhZ2UNCj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+ Pj4gdG8gaXQgb3IgYWNjZXB0aW5nIGFueSBCRkNQIG1lc3NhZ2UgZnJvbSBpdC4NCj4+Pj4+Pj4+ Pj4+Pj4+Pj4+Pj4+Pj4+Pj4gU2ltaWxhcmx5LCBmbG9vciBjb250cm9sIHNlcnZlcnMgU0hPVUxE DQo+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+IGF1dGhlbnRpY2F0ZSBhIGNsaWVudCBiZWZvcmUg YWNjZXB0aW5nIGFueSBCRkNQDQo+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+IG1lc3NhZ2UgZnJv bSBpdCBvciBzZW5kaW5nIGFueSBCRkNQIG1lc3NhZ2UgdG8gaXQuDQo+Pj4+Pj4+Pj4+Pj4+Pj4+ Pj4+Pj4+Pj4+DQo+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+IEJGQ1Agc3VwcG9ydHMgVExTL0RU TFMgbXV0dWFsIGF1dGhlbnRpY2F0aW9uDQo+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+IGJldHdl ZW4gY2xpZW50cyBhbmQgZmxvb3IgY29udHJvbCBzZXJ2ZXJzLCBhcw0KPj4+Pj4+Pj4+Pj4+Pj4+ Pj4+Pj4+Pj4+PiBzcGVjaWZpZWQgaW4gU2VjdGlvbiA5LjEuDQo+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+ Pj4+Pj4+IFRoaXMgaXMgdGhlIFJFQ09NTUVOREVEIGF1dGhlbnRpY2F0aW9uDQo+Pj4+Pj4+Pj4+ Pj4+Pj4+Pj4+Pj4+Pj4+IG1lY2hhbmlzbSBpbiBCRkNQLsKyDQo+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+ Pj4+Pj4+DQo+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+IFdoYXQgYXJlIHRoZSBjYXNlcyB3aGVy ZSBjbGllbnRzIGFuZCBzZXJ2ZXJzIGRvDQo+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+IG5vdCBu ZWVkICB0byBiZSBhdXRoZW50aWNhdGluZyBlYWNoIG90aGVyPyBJDQo+Pj4+Pj4+Pj4+Pj4+Pj4+ Pj4+Pj4+Pj4+IGtub3cgdGhpcyByZXF1aXJlbWVudCAgYW5kIHRoZSBvdGhlcg0KPj4+Pj4+Pj4+ Pj4+Pj4+Pj4+Pj4+Pj4+PiBTSE9VTEQtbGV2ZWwgcmVxdWlyZW1lbnRzIGFyb3VuZCB1c2Ugb2YN Cj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4gVExTL0RUTFMgYXJlIGNhcnJpZWQgb3ZlciBmcm9t IFJGQyA0NTgyLCBidXQNCj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4gScK5bSAgY29uY2VybmVk IHRoYXQgdGhleSBhcmVuwrl0IGFzIHN0cm9uZyBhcyB0aGV5IHNob3VsZCBiZS4NCj4+Pj4+Pj4+ Pj4+Pj4+Pj4+Pj4+Pj4+Pj4gRm9yIGEgY29uZmVyZW5jZSB3aGVyZSB0aGUgc2lnbmFsaW5nIHRy YWZmaWMgaXMNCj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4gYXV0aGVudGljYXRlZCBhbmQgY29u ZmlkZW50aWFsaXR5IGFuZCBpbnRlZ3JpdHkNCj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4gcHJv dGVjdGVkLCB3aHkgaXMgaXQgb2sgZm9yIHRoZSBmbG9vciBjb250cm9sDQo+Pj4+Pj4+Pj4+Pj4+ Pj4+Pj4+Pj4+Pj4+IHRyYWZmaWMgbm90IHRvIGJlPyBDb3VsZCB0aGVzZSByZXF1aXJlbWVudHMg YmUNCj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4gYWRqdXN0ZWQgdG8gcmVxdWlyZSB1c2Ugb2Yg VExTL0RUTFMgYXQgbGVhc3QgaW4NCj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4gY2FzZXMgd2hl cmUgdGhlIHNpZ25hbGluZyBpcyBhbHNvIHByb3RlY3RlZD8NCj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+ Pj4+Pj4NCj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4NCj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+ Pj4NCj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4gICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgDQo+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4gWWVzLCBi dXQgYWdhaW4sIHRoaXMgd291bGQgYmUgYXQgdGhlIGV4cGVuc2Ugb2YNCj4+Pj4+Pj4+Pj4+Pj4+ Pj4+Pj4+Pj4+PiBhZGRpbmcgYSBub24gYmFja3dhcmQgY29tcGF0aWJsZSBjaGFuZ2UgZnJvbSBy ZmMNCj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+PiA0NTgyLiBIb3cgYWJvdXQgc2F5aW5nIFRMUy9E VExTIE1VU1QgYmUgdXNlZCBmb3INCj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+PiBCRkNQIGluIHN1 Y2ggY2FzZXMsIHdoaWxlIHBvaW50aW5nIG91dCB0aGUgcmZjDQo+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+ Pj4+Pj4gNDU4Mg0KPj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+IGJhc2VkIGltcGxlbWVudGF0aW9u cyBtYXkgbm90IGNvbXBseSAoc2ltaWxhciB0bw0KPj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+IHdo YXQgd2UgZGlkIHdpdGggdGhlIHZlcnNpb24gZmllbGQpLg0KPj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+ Pj4+DQo+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4NCj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pg0K Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICANCj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+IFdvcmtzIGZvciBtZS4N Cj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+DQo+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+PiBGZWVsIGZy ZWUgdG8gbWFrZSBhbGwgb2YgdGhlc2UgY2hhbmdlcyBhbmQgc3VibWl0DQo+Pj4+Pj4+Pj4+Pj4+ Pj4+Pj4+Pj4+PiBhIHJldiBhbmQgScK5bGwgaXNzdWUgdGhlIElFVEYgTEMuDQo+Pj4+Pj4+Pj4+ Pj4+Pj4+Pj4+Pj4+Pg0KPj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4gVGhhbmtzLA0KPj4+Pj4+Pj4+ Pj4+Pj4+Pj4+Pj4+Pj4gQWxpc3NhDQo+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pg0KPj4+Pj4+Pj4+ Pj4+Pj4+Pj4+Pj4+Pj4NCj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+DQo+Pj4+Pj4+Pj4+Pj4+Pj4+ Pj4+Pj4+Pg0KPj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4gICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICANCj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4gPSBTZWN0 aW9uIDE0ID0NCj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4gU2VlIHRoZSBwb2ludCBhYm92ZSBh Ym91dCBjaXBoZXJzdWl0ZXMuDQo+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+IMKzTm9uLW51bGwg ZW5jcnlwdGlvbsKyIGlzIG5vdCBhIHN1ZmZpY2llbnQNCj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+ Pj4gbWluaW11bSBiYXNlbGluZSwgYW5kIGlmIHRoZSByZXF1aXJlbWVudHMNCj4+Pj4+Pj4+Pj4+ Pj4+Pj4+Pj4+Pj4+Pj4gY2hhbmdlIGluIFNlY3Rpb24gNyB0aGV5IHNob3VsZCBiZSByZWZsZWN0 ZWQgaGVyZSBhcyB3ZWxsLg0KPj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pg0KPj4+Pj4+Pj4+Pj4+ Pj4+Pj4+Pj4+Pj4+Pg0KPj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pg0KPj4+Pj4+Pj4+Pj4+Pj4+ Pj4+Pj4+Pj4+PiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICANCj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+PiBZZXAuDQo+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+ Pj4+Pj4NCj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pg0KPj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+ DQo+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4NCj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+PiAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgDQo+Pj4+Pj4+Pj4+ Pj4+Pj4+Pj4+Pj4+Pj4+IEVkaXRvcmlhbCBuaXRzIHRvIGJlIHJlc29sdmVkIHdpdGggTEMgY29t bWVudHM6DQo+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+DQo+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+ Pj4+ID0gU2VjdGlvbiA1LjEgPSDCs1RoZSB2ZXJzaW9uIGZpZWxkIE1VU1QgYmUgc2V0DQo+Pj4+ Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+IHRvIDEgd2hlbiB1c2luZyBCRkNQIG92ZXIgYSByZWxpYWJs ZSB0cmFuc3BvcnQsDQo+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+IGkuZS4gYXMgaW4gWzJdLsKy DQo+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+DQo+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+IEkg ZmluZCBpdCBhIGxpdHRsZSBvZGQgdG8gcmVmZXJlbmNlIHRoZSBzcGVjDQo+Pj4+Pj4+Pj4+Pj4+ Pj4+Pj4+Pj4+Pj4+IHlvdcK5cmUgb2Jzb2xldGluZyBpbiB0aGlzIHNlbnRlbmNlLCBlc3BlY2lh bGx5DQo+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+IHNpbmNlIEJGQ1Agb3ZlciBhIHJlbGlhYmxl IHRyYW5zcG9ydCBpcw0KPj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+PiBjb21wbGV0ZWx5IHNwZWNp ZmllZCBpbiB0aGlzIGJpcyBkb2N1bWVudC4gSQ0KPj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+PiB3 b3VsZCBzdWdnZXN0IGRyb3BwaW5nDQo+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+DQo+Pj4+Pj4+ Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgIA0KPj4+IHRoZSBpLmUuDQo+Pj4NCj4+PiAgICAgICAgDQo+Pj4+Pj4+Pj4+ Pj4+Pj4+Pj4+Pj4+Pj4+IGNsYXVzZS4NCj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4NCj4+Pj4+ Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4NCj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4NCj4+Pj4+Pj4+ Pj4+Pj4+Pj4+Pj4+Pj4+Pj4gICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgDQo+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4gR29vZCBjYXRjaC4gVGhpcyBp cyBhIGNhcnJ5IG92ZXIgZnJvbSBiZWZvcmUNCj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+PiB0aGlz IGRyYWZ0IHdhcyBhZG9wdGVkIGFzIGEgYmlzIHZlcnNpb24gb2YgcmZjNDU4Mi4NCj4+Pj4+Pj4+ Pj4+Pj4+Pj4+Pj4+Pj4+Pg0KPj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+DQo+Pj4+Pj4+Pj4+Pj4+ Pj4+Pj4+Pj4+Pj4NCj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pg0KPj4+Pj4+Pj4+Pj4+Pj4+Pj4+ Pj4+Pj4+ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAN Cj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4gIlRoZSB2ZXJzaW9uIGZpZWxkIE1VU1QgYmUgc2V0 IHRvIDIgd2hlbiB1c2luZw0KPj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+PiBCRkNQIG92ZXIgYW4g dW5yZWxpYWJsZSB0cmFuc3BvcnQgd2l0aCB0aGUNCj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4g ZXh0ZW5zaW9ucyBzcGVjaWZpZWQgaW4gdGhpcyBkb2N1bWVudC7Csg0KPj4+Pj4+Pj4+Pj4+Pj4+ Pj4+Pj4+Pj4+Pg0KPj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+PiBUaGUgYml0IGFib3V0IMKzd2l0 aCB0aGUgZXh0ZW5zaW9ucyBzcGVjaWZpZWQgaW4NCj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4g dGhpcyBkb2N1bWVudMKyIGlzIGV4dHJhbmVvdXMgYW5kIHNob3VsZCBiZSByZW1vdmVkLg0KPj4+ Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pg0KPj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+PiAiSWYgYW4g ZW5kcG9pbnQgcmVjZWl2ZXMgYSBtZXNzYWdlIHdpdGggYW4NCj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+ Pj4+Pj4gdW5zdXBwb3J0ZWQgdmVyc2lvbiBmaWVsZCB2YWx1ZSwgdGhlIHJlY2VpdmluZw0KPj4+ Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+PiBzZXJ2ZXIgTVVTVCBzZW5kIGFuIEVycm9yIG1lc3NhZ2Ug d2l0aA0KPj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+PiBwYXJhbWV0ZXIgdmFsdWUgMTIgKFVuc3Vw cG9ydGVkDQo+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+IFZlcnNpb24pIHRvIGluZGljYXRlIHRo aXMuwrINCj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4NCj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+ Pj4gVXNlIG9mIHRoZSB3b3JkIMKzc2VydmVywrIgaGVyZSBtYWtlcyBpdCBzb3VuZCBhcw0KPj4+ Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+PiBpZiBvbmx5IHNlcnZlcnMgY291bGQgcmVjZWl2ZSBoZWFk ZXJzIHdpdGgNCj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4gdW5zdXBwb3J0ZWQgdmVyc2lvbnMu DQo+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+IFNob3VsZCB0aGlzIGJlIMKzdGhlIHJlY2Vpdmlu ZyBlbmRwb2ludMKyPw0KPj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pg0KPj4+Pj4+Pj4+Pj4+Pj4+ Pj4+Pj4+Pj4+PiA9IFNlY3Rpb24gNi4yLjQgPSAiWzIzXSwgU2VjdGlvbiA2LjcgcHJvdmlkZXMN Cj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4gdXNlZnVsIHJlY29tbWVuZGF0aW9ucyDFoMKyDQo+ Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+DQo+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+IFRoZSBs aW5rcyBpbiB0aGUgcmVmZXJlbmNlcyBhcmUgbm90IHF1aXRlIHJpZ2h0Lg0KPj4+Pj4+Pj4+Pj4+ Pj4+Pj4+Pj4+Pj4+Pg0KPj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+PiA9IFNlY3Rpb24gOC4zLjIg PSBzL3doZW4gZmlyZXMvd2hlbiBmaXJlZC8NCj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4NCj4+ Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4gPSBTZWN0aW9uIDE0ID0NCj4+Pj4+Pj4+Pj4+Pj4+Pj4+ Pj4+Pj4+Pj4gcy9oaWdoLWphY2svaGlqYWNrLw0KPj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pg0K Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+PiA9IFNlY3Rpb24gQi4xID0gInNpdHVhdGlvbiB3aGVy ZSBtdWx0aXBsZQ0KPj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+PiBkaWZmZXJlbnQgYW5kIG5vbi1p bnRlcm9wZXJhYmxlIHdvdWxkDQo+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+IGNvLQ0KPj4+Pj4+ Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+PiBleGlzdCBpbiB0aGUgbWFya2V0LsKyDQo+Pj4+Pj4+Pj4+Pj4+ Pj4+Pj4+Pj4+Pj4+DQo+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+IFRoZXJlIGlzIGEgd29yZCBt aXNzaW5nIGFmdGVyIMKzbm9uLWludGVyb3BlcmFibGUuIg0KPj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+ Pj4+Pg0KPj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pg0KPj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+ Pg0KPj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+PiAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICANCj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+PiBUaGlzIHNo b3VsZCByZWFkIMKzbm9uLWludGVyb3BlcmFibGUgaW1wbGVtZW50YXRpb25zwrIuDQo+Pj4+Pj4+ Pj4+Pj4+Pj4+Pj4+Pj4+Pj4gRWFybGllciBpbiB0aGF0IHNhbWUgc2VudGVuY2UsIMKzQkZDUCBv dmVyIFVEUA0KPj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+IHdlcmUgYWxyZWFkeSB1c2VkwrIgc2hv dWxkIHJlYWQgwrNCRkNQIG92ZXIgVURQIGlzDQo+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4gYWxy ZWFkeSBiZWluZyB1c2VkwrIuDQo+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4NCj4+Pj4+Pj4+Pj4+ Pj4+Pj4+Pj4+Pj4+PiBDaGVlcnMsDQo+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4gQ2hhcmxlcw0K Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+DQo+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4NCj4+Pj4+ Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pg0KPj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+ICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICANCj4+Pj4+Pj4+Pj4+Pj4+Pj4+ Pj4+Pj4+IF9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQo+ Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+PiBiZmNwYmlzIG1haWxpbmcgbGlzdA0KPj4+Pj4+Pj4+Pj4+ Pj4+Pj4+Pj4+Pj4gYmZjcGJpc0BpZXRmLm9yZzxtYWlsdG86YmZjcGJpc0BpZXRmLm9yZz4NCj4+ Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+IGh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGlu Zm8vYmZjcGJpcw0KPj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4NCj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+ Pj4+DQo+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pg0KPj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4gICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICANCj4+Pj4+Pj4+Pj4+ Pj4+Pj4+Pj4+Pj4NCj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4gICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgDQo+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4NCj4+Pj4+Pj4+ Pj4+Pj4+Pj4+Pj4+PiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg DQo+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pg0KPj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4gICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICANCj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4NCj4+Pj4+ Pj4+Pj4+Pj4+Pj4+Pj4gICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgDQo+ Pj4+Pj4+Pj4+Pj4+Pj4+Pj4NCj4+Pj4+Pj4+Pj4+Pj4+Pj4+PiAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgDQo+Pj4+Pj4+Pj4+Pj4+Pj4+Pg0KPj4+Pj4+Pj4+Pj4+Pj4+Pj4g ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICANCj4+Pj4+Pj4+Pj4+Pj4+Pj4NCj4+ Pj4+Pj4+Pj4+Pj4+Pj4gICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgDQo+Pj4+Pj4+ Pj4+Pj4+Pj4NCj4+Pj4+Pj4+Pj4+Pj4+PiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg DQo+Pj4+Pj4+Pj4+Pj4+Pg0KPj4+Pj4+Pj4+Pj4+Pj4gICAgICAgICAgICAgICAgICAgICAgICAg ICAgICANCj4+Pj4+Pj4+Pj4+Pg0KPj4+Pj4+Pj4+Pj4+ICAgICAgICAgICAgICAgICAgICAgICAg ICANCj4+Pj4+Pj4+Pj4+DQo+Pj4+Pj4+Pj4+PiAgICAgICAgICAgICAgICAgICAgICAgIA0KPj4+ Pj4+Pj4+Pg0KPj4+Pj4+Pj4+PiAgICAgICAgICAgICAgICAgICAgICANCj4+Pj4+Pj4+PiBfX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KPj4+Pj4+Pj4+IGJm Y3BiaXMgbWFpbGluZyBsaXN0DQo+Pj4+Pj4+Pj4gYmZjcGJpc0BpZXRmLm9yZw0KPj4+Pj4+Pj4+ IGh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vYmZjcGJpcw0KPj4+Pj4+Pj4+ DQo+Pj4+Pj4+Pj4gICAgICAgICAgICAgICAgICAgIA0KPj4+Pj4+Pj4NCj4+Pj4+Pj4+ICAgICAg ICAgICAgICAgICAgDQo+Pj4+Pj4+DQo+Pj4+Pj4+ICAgICAgICAgICAgICAgIA0KPj4+Pj4+DQo+ Pj4+Pj4gICAgICAgICAgICAgIA0KPj4+Pj4NCj4+Pj4+ICAgICAgICAgICAgDQo+Pj4+IF9fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQo+Pj4+IGJmY3BiaXMg bWFpbGluZyBsaXN0DQo+Pj4+IGJmY3BiaXNAaWV0Zi5vcmcNCj4+Pj4gaHR0cHM6Ly93d3cuaWV0 Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9iZmNwYmlzDQo+Pj4+DQo+Pj4+ICAgICAgICAgIA0KPj4+ DQo+Pj4gICAgICAgIA0KPj4gICAgICANCj4gICAgDQoNCg== From nobody Wed Nov 4 18:31:09 2015 Return-Path: X-Original-To: bfcpbis@ietf.org Delivered-To: bfcpbis@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id BA8DB1B3668; Wed, 4 Nov 2015 18:31:08 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: "Spencer Dawkins" To: "The IESG" X-Test-IDTracker: no X-IETF-IDTracker: 6.8.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20151105023108.17210.54132.idtracker@ietfa.amsl.com> Date: Wed, 04 Nov 2015 18:31:08 -0800 Archived-At: Cc: gorry@erg.abdn.ac.uk, mary.ietf.barnes@gmail.com, bfcpbis-chairs@ietf.org, bfcpbis@ietf.org, draft-ietf-bfcpbis-rfc4582bis@ietf.org Subject: [bfcpbis] Spencer Dawkins' Discuss on draft-ietf-bfcpbis-rfc4582bis-15: (with DISCUSS and COMMENT) X-BeenThere: bfcpbis@ietf.org X-Mailman-Version: 2.1.15 List-Id: BFCPBIS working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Nov 2015 02:31:08 -0000 Spencer Dawkins has entered the following ballot position for draft-ietf-bfcpbis-rfc4582bis-15: Discuss When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-bfcpbis-rfc4582bis/ ---------------------------------------------------------------------- DISCUSS: ---------------------------------------------------------------------- Thanks for working through my Discuss and Comments on -13. I'm mostly good (at the Discuss level), but have one remaining concern, on section 14. Security Considerations BFCP uses TLS/DTLS to provide mutual authentication between clients and servers. TLS/DTLS also provides replay and integrity protection and confidentiality. It is RECOMMENDED that TLS/DTLS with an encryption algorithm according to Section 7 always be used. In cases where signaling/control traffic is properly protected, as described in Section 9 it is REQUIRED to use a mandated encryption algorithm. BFCP entities MAY use other security mechanisms as long as they provide similar security properties. If I'm reading this text correctly (please correct me if I'm misunderstanding), it is still allowed to run BFCP over TCP/UDP without TLS/DTLS. If you run a protocol over TCP without TLS, you're still vulnerable to on-path attackers, but off-path attackers have to insert attack packets with sequence numbers that are within the current window. That's not impossible, but it's not easy. So, I'm not happy that TLS isn't required when you run BFCP over TCP, but OK, fine. If you run a protocol over UDP without DTLS, off-path attackers don't have this constraint, so inserting attack packets off-path is much easier. That makes BFCP much more vulnerable to attack over UDP than it was over TCP. Is that really OK? That seems quite odd to me, when said without a clear warning that if you do not use DTLS (or equivalent) security mechanisms the protocol is vulnerable to various attacks. I’d have preferred section 7 to have said “SHOULD use TLS or DTLS” and then have gone on to explain - “reasons for not using DTLS include ... but when TLS or DTLS is not used the protocol becomes vulnerable to security attacks (e.g. ...).” ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- I have a couple of Comments on new text: 6.2.2. ICMP Error Handling ICMP is not used with unreliable transports due to risks asociated with off-path attacks. Any ICMP messages received over an unreliable transport MUST be ignored. ICMP is inherently unreliable - and is itself a control transport, rather than sent over another transport. I think I know what you mean, but it's not what the text says. Perhaps you mean ICMP is not usable when BFCP is running over an unreliable transport due to risks associated with off-path attacks. Any ICMP messages associated with BFCP running over an unreliable transport MUST be ignored. The new text says: “predictable conference identifiers in conjunction with a non-secure transport protocol makes BFCP more susceptible to forged request and response messages. See the Security Considerations section regarding the recommendation to use a secure transport.)” - This text could be improved a little by changing this to: “ predictable conference identifiers in conjunction with a non-secure transport protocol makes BFCP susceptible to off path data injection attacks, where an attacker can forge a request or response message.” However, this falls short of saying you should randomize the conference ID. The current text could be OK if it is hard or impossible to randomize for some reason, but I’d have thought if it was possible this should be RECOMMENDED either as the default method, or at least as a more secure alternative for an unreliable transport. Cleaning up the last few Comments on -13: I'm still working through the conflation of transports and version numbers. It's getting better, but the current text says: “If a floor control server receives a message with an unsupported version field value, the server MUST indicate it does not support the protocol version by sending an Error message with parameter value 12 (Unsupported Version).“ I’d have expected this error message to also have been returned if the transport did not match. Would it be correct if the text said: “If a floor control server receives a message with an unsupported version field value or a message with a version number that is not permitted with the transport over which it was received, the server MUST indicate it does not support the protocol version by sending an Error message with parameter value 12 (Unsupported Version).“ From nobody Wed Nov 4 20:24:38 2015 Return-Path: X-Original-To: bfcpbis@ietfa.amsl.com Delivered-To: bfcpbis@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 741541B30CE; Wed, 4 Nov 2015 20:24:33 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.701 X-Spam-Level: X-Spam-Status: No, score=-1.701 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_ADSP_ALL=0.8, DKIM_SIGNED=0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, T_DKIM_INVALID=0.01, 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 35_52IzLkpmp; Wed, 4 Nov 2015 20:24:30 -0800 (PST) Received: from dublin.packetizer.com (dublin.packetizer.com [75.101.130.125]) (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 033521B2D56; Wed, 4 Nov 2015 20:24:27 -0800 (PST) Received: from dhcp-26-115.meeting.ietf94.jp (dhcp-26-115.meeting.ietf94.jp [133.93.26.115]) (authenticated bits=0) by dublin.packetizer.com (8.15.2/8.15.2) with ESMTPSA id tA54OFA1016123 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 4 Nov 2015 23:24:20 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=packetizer.com; s=dublin; t=1446697462; bh=cftnyN+RZhu9VvPVaqJ0VJd9CQsoEu+sL9p2xTjGf1I=; h=In-Reply-To:References:Subject:From:Date:To:CC; b=sMtrMdI2r3svyWQ9C+KLKq7d5RnvP+cehdF4nCI2Qen2PUnPL1quUILmfX1qrCsHy 6PnPaU1RmIOsjjuA9fGZKUaFZPY+Pe42RMUMbt4hfyQS4STLbs2r9PIqn512jRehlE VnIaSAo/IgRxKeyW4XGsn+g3y3eZv79/BasHgllA= User-Agent: K-9 Mail for Android In-Reply-To: <20151105023108.17210.54132.idtracker@ietfa.amsl.com> References: <20151105023108.17210.54132.idtracker@ietfa.amsl.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----RX9GUI1V6C9SKYOKKG60RSD7VCESBU" Content-Transfer-Encoding: 8bit From: "Paul E. Jones" Date: Thu, 05 Nov 2015 13:24:10 +0900 To: Spencer Dawkins , The IESG Message-ID: <19C90DA9-652D-499F-8462-7EC7878307CB@packetizer.com> X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.5.12 (dublin.packetizer.com [10.109.150.103]); Wed, 04 Nov 2015 23:24:22 -0500 (EST) Archived-At: Cc: gorry@erg.abdn.ac.uk, bfcpbis@ietf.org, mary.ietf.barnes@gmail.com, draft-ietf-bfcpbis-rfc4582bis@ietf.org, bfcpbis-chairs@ietf.org Subject: Re: [bfcpbis] Spencer Dawkins' Discuss on draft-ietf-bfcpbis-rfc4582bis-15: (with DISCUSS and COMMENT) X-BeenThere: bfcpbis@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: BFCPBIS working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Nov 2015 04:24:33 -0000 ------RX9GUI1V6C9SKYOKKG60RSD7VCESBU Content-Transfer-Encoding: 8bit Content-Type: text/plain; charset=UTF-8 Spencer, I think all of the suggestions in the comments are perfectly fine and I can accept those. With respect to the random conference ID, I think the issue is that this ID is considered outside the protocol. This protocol just uses this ID. If that's wrong, I would agree suggesting randomizing it would be good. With respect to the DISCUSS point, I'm not sure what to do. Section 7 says TLS or DTLS must be supported, but that doesn't mean it must be used. I guess that's your concern. I think the security considerations section is the right place to provide warning to those who choose not use it. And there is warning. What more really needs to be said? I'm entirely OK with more scary language, but would prefer it added only to security considerations. Paul -------- Original Message -------- From: Spencer Dawkins Sent: November 5, 2015 11:31:08 AM GMT+09:00 To: The IESG Cc: gorry@erg.abdn.ac.uk, mary.ietf.barnes@gmail.com, bfcpbis-chairs@ietf.org, bfcpbis@ietf.org, draft-ietf-bfcpbis-rfc4582bis@ietf.org Subject: [bfcpbis] Spencer Dawkins' Discuss on draft-ietf-bfcpbis-rfc4582bis-15: (with DISCUSS and COMMENT) Spencer Dawkins has entered the following ballot position for draft-ietf-bfcpbis-rfc4582bis-15: Discuss When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-bfcpbis-rfc4582bis/ ---------------------------------------------------------------------- DISCUSS: ---------------------------------------------------------------------- Thanks for working through my Discuss and Comments on -13. I'm mostly good (at the Discuss level), but have one remaining concern, on section 14. Security Considerations BFCP uses TLS/DTLS to provide mutual authentication between clients and servers. TLS/DTLS also provides replay and integrity protection and confidentiality. It is RECOMMENDED that TLS/DTLS with an encryption algorithm according to Section 7 always be used. In cases where signaling/control traffic is properly protected, as described in Section 9 it is REQUIRED to use a mandated encryption algorithm. BFCP entities MAY use other security mechanisms as long as they provide similar security properties. If I'm reading this text correctly (please correct me if I'm misunderstanding), it is still allowed to run BFCP over TCP/UDP without TLS/DTLS. If you run a protocol over TCP without TLS, you're still vulnerable to on-path attackers, but off-path attackers have to insert attack packets with sequence numbers that are within the current window. That's not impossible, but it's not easy. So, I'm not happy that TLS isn't required when you run BFCP over TCP, but OK, fine. If you run a protocol over UDP without DTLS, off-path attackers don't have this constraint, so inserting attack packets off-path is much easier. That makes BFCP much more vulnerable to attack over UDP than it was over TCP. Is that really OK? That seems quite odd to me, when said without a clear warning that if you do not use DTLS (or equivalent) security mechanisms the protocol is vulnerable to various attacks. I’d have preferred section 7 to have said “SHOULD use TLS or DTLS” and then have gone on to explain - “reasons for not using DTLS include ... but when TLS or DTLS is not used the protocol becomes vulnerable to security attacks (e.g. ...).” ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- I have a couple of Comments on new text: 6.2.2. ICMP Error Handling ICMP is not used with unreliable transports due to risks asociated with off-path attacks. Any ICMP messages received over an unreliable transport MUST be ignored. ICMP is inherently unreliable - and is itself a control transport, rather than sent over another transport. I think I know what you mean, but it's not what the text says. Perhaps you mean ICMP is not usable when BFCP is running over an unreliable transport due to risks associated with off-path attacks. Any ICMP messages associated with BFCP running over an unreliable transport MUST be ignored. The new text says: “predictable conference identifiers in conjunction with a non-secure transport protocol makes BFCP more susceptible to forged request and response messages. See the Security Considerations section regarding the recommendation to use a secure transport.)” - This text could be improved a little by changing this to: “ predictable conference identifiers in conjunction with a non-secure transport protocol makes BFCP susceptible to off path data injection attacks, where an attacker can forge a request or response message.” However, this falls short of saying you should randomize the conference ID. The current text could be OK if it is hard or impossible to randomize for some reason, but I’d have thought if it was possible this should be RECOMMENDED either as the default method, or at least as a more secure alternative for an unreliable transport. Cleaning up the last few Comments on -13: I'm still working through the conflation of transports and version numbers. It's getting better, but the current text says: “If a floor control server receives a message with an unsupported version field value, the server MUST indicate it does not support the protocol version by sending an Error message with parameter value 12 (Unsupported Version).“ I’d have expected this error message to also have been returned if the transport did not match. Would it be correct if the text said: “If a floor control server receives a message with an unsupported version field value or a message with a version number that is not permitted with the transport over which it was received, the server MUST indicate it does not support the protocol version by sending an Error message with parameter value 12 (Unsupported Version).“ _______________________________________________ bfcpbis mailing list bfcpbis@ietf.org https://www.ietf.org/mailman/listinfo/bfcpbis ------RX9GUI1V6C9SKYOKKG60RSD7VCESBU Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit Spencer,

I think all of the suggestions in the comments are perfectly fine and I can accept those. With respect to the random conference ID, I think the issue is that this ID is considered outside the protocol. This protocol just uses this ID. If that's wrong, I would agree suggesting randomizing it would be good.

With respect to the DISCUSS point, I'm not sure what to do. Section 7 says TLS or DTLS must be supported, but that doesn't mean it must be used. I guess that's your concern. I think the security considerations section is the right place to provide warning to those who choose not use it. And there is warning. What more really needs to be said?

I'm entirely OK with more scary language, but would prefer it added only to security considerations.

Paul

From: Spencer Dawkins <spencerdawkins.ietf@gmail.com>
Sent: November 5, 2015 11:31:08 AM GMT+09:00
To: The IESG <iesg@ietf.org>
Cc: gorry@erg.abdn.ac.uk, mary.ietf.barnes@gmail.com, bfcpbis-chairs@ietf.org, bfcpbis@ietf.org, draft-ietf-bfcpbis-rfc4582bis@ietf.org
Subject: [bfcpbis] Spencer Dawkins' Discuss on draft-ietf-bfcpbis-rfc4582bis-15: (with DISCUSS and COMMENT)

Spencer Dawkins has entered the following ballot position for
draft-ietf-bfcpbis-rfc4582bis-15: Discuss

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


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


The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-bfcpbis-rfc4582bis/




DISCUSS:


Thanks for working through my Discuss and Comments on -13. I'm mostly
good (at the Discuss level), but have one remaining concern!
 , on
section
14.  Security Considerations

   BFCP uses TLS/DTLS to provide mutual authentication between clients
   and servers.  TLS/DTLS also provides replay and integrity protection
   and confidentiality.  It is RECOMMENDED that TLS/DTLS with an
   encryption algorithm according to Section 7 always be used.  In cases
   where signaling/control traffic is properly protected, as described
   in Section 9 it is REQUIRED to use a mandated encryption algorithm.
   BFCP entities MAY use other security mechanisms as long as they
   provide similar security properties.
   
If I'm reading this text correctly (please correct me if I'm
misunderstanding), it is still allowed to run BFCP over TCP/UDP without
TLS/DTLS. 

If you run a protocol over TCP without TLS, you're still vulnerable to
on-path attackers, but off-path attackers have to insert attack packets
with sequence numbers that are within t!
 he
current window. That's not
impossible, but it's not easy. So, I'm not happy that TLS isn't required
when you run BFCP over TCP, but OK, fine.

If you run a protocol over UDP without DTLS, off-path attackers don't
have this constraint, so inserting attack packets off-path is much
easier. That makes BFCP much more vulnerable to attack over UDP than it
was over TCP. 

Is that really OK? That seems quite odd to me, when said without a clear
warning that if you do not use DTLS (or equivalent) security mechanisms
the protocol is vulnerable to various attacks.

I’d have preferred section 7 to have said “SHOULD use TLS or DTLS” and
then have gone on to explain - “reasons for not using DTLS include ...
but when TLS or DTLS is not used the protocol becomes vulnerable to
security attacks (e.g. ...).”



COMMENT:



I have a couple of Comments on !
 new
text:

6.2.2.  ICMP Error Handling 
   
   ICMP is not used with unreliable transports due to risks asociated 
   with off-path attacks.  Any ICMP messages received over an
unreliable 
   transport MUST be ignored.
   
ICMP is inherently unreliable - and is itself a control transport, rather
than sent over another transport. I think I know what you mean, but it's
not what the text says. Perhaps you mean

   ICMP is not usable when BFCP is running over an unreliable transport
due 
   to risks associated with off-path attacks.  Any ICMP messages
associated 
   with BFCP running over an unreliable transport MUST be ignored.
   
The new text says:

“predictable conference identifiers in conjunction with a non-secure
transport protocol makes BFCP more susceptible to forged request and
response messages.  See the Security Considerations section regarding
the
recommendation to use a secure transport.)”

- This text  could be improved a little by changing this to:

“ predictable conference identifiers in conjunction with a non-secure
transport protocol makes BFCP susceptible to off path data injection
attacks, where an attacker can forge a request or response message.”

However, this falls short of saying you should randomize the conference
ID.

The current text could be OK if it is hard or impossible to randomize for
some reason, but I’d have thought if it was possible this should be
RECOMMENDED either as the default method, or at least as a more secure
alternative for an unreliable transport.
   
Cleaning up the last few Comments on -13:

I'm still working through the conflation of transports and version
numbers. It's getting better, but the current text says:

   “If a floor control server receives a
   messag!
 e with
an unsupported version field value, the server MUST
   indicate it does not support the protocol version by sending an Error
   message with parameter value 12 (Unsupported Version).“

I’d have expected this error message to also have been returned if the
transport did not match.

Would it be correct if the text said:

  “If a floor control server receives a
   message with an unsupported version field value
   or a message with a version number that is not permitted
   with the transport over which it was received,  the server MUST
   indicate it does not support the protocol version by sending an Error
   message with parameter value 12 (Unsupported Version).“



bfcpbis mailing list
bfcpbis@ietf.org
https://www.ietf.org/mailman/listinfo/bfcpbis
------RX9GUI1V6C9SKYOKKG60RSD7VCESBU-- From nobody Wed Nov 4 20:46:31 2015 Return-Path: X-Original-To: bfcpbis@ietfa.amsl.com Delivered-To: bfcpbis@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B74C71A89FE; Wed, 4 Nov 2015 20:46:25 -0800 (PST) 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 p_ou_alXE83X; Wed, 4 Nov 2015 20:46:22 -0800 (PST) Received: from mail-yk0-x233.google.com (mail-yk0-x233.google.com [IPv6:2607:f8b0:4002:c07::233]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id F1E6A1B38FB; Wed, 4 Nov 2015 20:46:21 -0800 (PST) Received: by ykdr3 with SMTP id r3so112054528ykd.1; Wed, 04 Nov 2015 20:46:21 -0800 (PST) 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=Zw5dOXiFlLlKstwRaTQKcmJuBg4nS/00AR2VYy6ddQA=; b=gml3H06zX5DVB4pX5JMUIPUmHUcN+rY+VJSXELnXPt2oKhrF3dfkPQs/OexdxGMYkr EMzu5fbjC35umQ9PkuTfiBp6QcZUeM9QWlm8rU+mp7tB4uBJyynOpeHBFKIJhOIxKS/v sYcsZTK8qH8IHKRIAe78nQqbl0O4BK+8c5a4gmswxsRPTZ1ASnWKhwyayngMj/cZ/lCH lcqXdWnYNow6E9sxUMBY3FeXkygO5p/djTC7BOxBGm4dY/U4dgtGRerfmJS8O7WhK0JL bFktSXwIiIzj5oAXq6G3VKvVQsIRGZuriowHjgqfLk4c2O3MGzYQsIOeUw+18kAOT87y /w7g== MIME-Version: 1.0 X-Received: by 10.31.8.69 with SMTP id 66mr5149463vki.82.1446698781345; Wed, 04 Nov 2015 20:46:21 -0800 (PST) Received: by 10.31.149.79 with HTTP; Wed, 4 Nov 2015 20:46:21 -0800 (PST) In-Reply-To: <19C90DA9-652D-499F-8462-7EC7878307CB@packetizer.com> References: <20151105023108.17210.54132.idtracker@ietfa.amsl.com> <19C90DA9-652D-499F-8462-7EC7878307CB@packetizer.com> Date: Thu, 5 Nov 2015 13:46:21 +0900 Message-ID: From: Spencer Dawkins at IETF To: "Paul E. Jones" Content-Type: multipart/alternative; boundary=001a11440bccf58d5b0523c3ce25 Archived-At: Cc: "gorry@erg.abdn.ac.uk" , bfcpbis-chairs@ietf.org, bfcpbis@ietf.org, draft-ietf-bfcpbis-rfc4582bis@ietf.org, The IESG , Mary Barnes Subject: Re: [bfcpbis] Spencer Dawkins' Discuss on draft-ietf-bfcpbis-rfc4582bis-15: (with DISCUSS and COMMENT) X-BeenThere: bfcpbis@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: BFCPBIS working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Nov 2015 04:46:25 -0000 --001a11440bccf58d5b0523c3ce25 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Hi, Paul, On Thu, Nov 5, 2015 at 1:24 PM, Paul E. Jones wrote= : > Spencer, > > I think all of the suggestions in the comments are perfectly fine and I > can accept those. With respect to the random conference ID, I think the > issue is that this ID is considered outside the protocol. This protocol > just uses this ID. If that's wrong, I would agree suggesting randomizing = it > would be good. > > With respect to the DISCUSS point, I'm not sure what to do. Section 7 say= s > TLS or DTLS must be supported, but that doesn't mean it must be used. I > guess that's your concern. I think the security considerations section is > the right place to provide warning to those who choose not use it. And > there is warning. What more really needs to be said? > > I'm entirely OK with more scary language, but would prefer it added only > to security considerations. > So, we both want to do the right thing. Let's talk about what that is, before we spend time twiddling words. The reason why we're having this chat, is that DTLS is RECOMMENDED, not REQUIRED. Can you help me understand why that is? I'm seeing language in the spec that looks, to me, like it's trying to hold the door open in case another mechanism with equivalent functionality to DTLS becomes available (so, not MUST DTLS, because you couldn't use it). For example, from the Security Considerations section: BFCP entities MAY use other security mechanisms as long as they provide similar security properties. Is that relevant to my question, or am I misunderstanding, and there are use cases where unencrypted BFCP is necessary? Thanks, Spencer > Paul > > ------------------------------ > *From:* Spencer Dawkins > *Sent:* November 5, 2015 11:31:08 AM GMT+09:00 > *To:* The IESG > *Cc:* gorry@erg.abdn.ac.uk, mary.ietf.barnes@gmail.com, > bfcpbis-chairs@ietf.org, bfcpbis@ietf.org, > draft-ietf-bfcpbis-rfc4582bis@ietf.org > *Subject:* [bfcpbis] Spencer Dawkins' Discuss on > draft-ietf-bfcpbis-rfc4582bis-15: (with DISCUSS and COMMENT) > > Spencer Dawkins has entered the following ballot position for > draft-ietf-bfcpbis-rfc4582bis-15: Discuss > > When responding, please keep the subject line intact and reply to all > email addresses included in the To and CC lines. (Feel free to cut this > introductory paragraph, however.) > > > Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html > for more information about IESG DISCUSS and COMMENT positions. > > > The document, along with other ballot positions, can be found here: > https://datatracker.ietf.org/doc/draft-ietf-bfcpbis-rfc4582bis/ > > > > ------------------------------ > > DISCUSS: > ------------------------------ > > > Thanks for working through my Discuss and Comments on -13. I'm mostly > good (at the Discuss level), but have one remaining concern! > , on > section > 14. Security Considerations > > BFCP uses TLS/DTLS to provide mutual authentication between clients > and servers. TLS/DTLS also provides replay and integrity protection > and confidentiality. It is RECOMMENDED that TLS/DTLS with an > encryption algorithm according to Section 7 always be used. In cases > where signaling/control traffic is properly protected, as described > in Section 9 it is REQUIRED to use a mandated encryption algorithm. > BFCP entities MAY use other security mechanisms as long as they > provide similar security properties. > > If I'm reading this text correctly (please correct me if I'm > misunderstanding), it is still allowed to run BFCP over TCP/UDP without > TLS/DTLS. > > If you run a protocol over TCP without TLS, you're still vulnerable to > on-path attackers, but off-path attackers have to insert attack packets > with sequence numbers that are within t! > he > current window. That's not > impossible, but it's not easy. So, I'm not happy that TLS isn't required > when you run BFCP over TCP, but OK, fine. > > If you run a protocol over UDP without DTLS, off-path attackers don't > have this constraint, so inserting attack packets off-path is much > easier. That makes BFCP much more vulnerable to attack over UDP than it > was over TCP. > > Is that really OK? That seems quite odd to me, when said without a clear > warning that if you do not use DTLS (or equivalent) security mechanisms > the protocol is vulnerable to various attacks. > > I=E2=80=99d have preferred section 7 to have said =E2=80=9CSHOULD use TLS= or DTLS=E2=80=9D and > then have gone on to explain - =E2=80=9Creasons for not using DTLS includ= e ... > but when TLS or DTLS is not used the protocol becomes vulnerable to > security attacks (e.g. ...).=E2=80=9D > > > ------------------------------ > > COMMENT: > ------------------------------ > > > > I have a couple of Comments on ! > new > text: > > > 6.2.2. ICMP Error Handling > > ICMP is not used with unreliable transports due to risks asociated > with off-path attacks. Any ICMP messages received over an > unreliable > transport MUST be ignored. > > ICMP is inherently unreliable - and is itself a control transport, rather > than sent over another transport. I think I know what you mean, but it's > not what the text says. Perhaps you mean > > ICMP is not usable when BFCP is running over an unreliable transport > due > to risks associated with off-path attacks. Any ICMP messages > associated > with BFCP running over an unreliable transport MUST be ignored. > > The new text says: > > =E2=80=9Cpredictable conference identifiers in conjunction with a non-sec= ure > transport protocol makes BFCP more susceptible to forged request and > response messages. See the Security Considerations section regarding > the > recommendation to use a secure transport.)=E2=80=9D > > - This text could be improved a little by changing this to: > > =E2=80=9C predictable conference identifiers in conjunction with a non-se= cure > transport protocol makes BFCP susceptible to off path data injection > attacks, where an attacker can forge a request or response message.=E2=80= =9D > > However, this falls short of saying you should randomize the conference > ID. > > The current text could be OK if it is hard or impossible to randomize for > some reason, but I=E2=80=99d have thought if it was possible this should = be > RECOMMENDED either as the default method, or at least as a more secure > alternative for an unreliable transport. > > Cleaning up the last few Comments on -13: > > I'm still working through the conflation of transports and version > numbers. It's getting better, but the current text says: > > =E2=80=9CIf a floor control server receives a > messag! > e with > an unsupported version field value, the server MUST > indicate it does not support the protocol version by sending an Error > message with parameter value 12 (Unsupported Version).=E2=80=9C > > I=E2=80=99d have expected this error message to also have been returned i= f the > transport did not match. > > Would it be correct if the text said: > > =E2=80=9CIf a floor control server receives a > message with an unsupported version field value > or a message with a version number that is not permitted > with the transport over which it was received, the server MUST > indicate it does not support the protocol version by sending an Error > message with parameter value 12 (Unsupported Version).=E2=80=9C > > > ------------------------------ > > bfcpbis mailing list > bfcpbis@ietf.org > https://www.ietf.org/mailman/listinfo/bfcpbis > > --001a11440bccf58d5b0523c3ce25 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hi, Paul,

On Thu, Nov 5, 2015 at 1:24 PM, Paul E. Jones &l= t;paulej@packeti= zer.com> wrote:
Spencer,

I think all of the suggestions in the comments are perfectly fine and I can= accept those. With respect to the random conference ID, I think the issue = is that this ID is considered outside the protocol. This protocol just use= s this ID. If that's wrong, I would agree suggesting randomizing it wo= uld be good.

With respect to the DISCUSS point, I'm not sure what to do. Section 7 s= ays TLS or DTLS must be supported, but that doesn't mean it must be use= d. I guess that's your concern. I think the security considerations s= ection is the right place to provide warning to those who choose not use it= . And there is warning. What more really needs to be said?

I'm entirely OK with more scary language, but would prefer it added onl= y to security considerations.

So, we = both want to do the right thing. Let's talk about what that is, before = we spend time twiddling words.

The reason why we&#= 39;re having this chat, is that DTLS is RECOMMENDED, not REQUIRED. Can you = help me understand why that is?=C2=A0

I'm seei= ng language in the spec that looks, to me, like it's trying to hold the= door open in case another mechanism with equivalent functionality to DTLS = becomes available (so, not MUST DTLS, because you couldn't use it). For= example, from the Security Considerations section:

   BFCP entities MAY use other security mechanisms a=
s long as they
   provide similar security properties.

Is t= hat relevant to my question, or am I misunderstanding, and there are use ca= ses where unencrypted BFCP is necessary?

Thanks,

Spencer
=C2=A0
Paul

From: Spencer Dawkins <spencerdawkins.ietf@gmail.com>
Sent: November 5, 2015 11:31:08 AM GMT+09:00
To: The IESG <= iesg@ietf.org>
Cc: gorry@= erg.abdn.ac.uk, mary.ietf.barnes@gmail.com, bfcpbis-chairs@ietf.org, bfcpbis@ietf.org, draft-ietf-bfcpbi= s-rfc4582bis@ietf.org
Subject: [bfcpbis] Spencer Dawkins' Discuss on draft-ietf-bfcpbi= s-rfc4582bis-15: (with DISCUSS and COMMENT)

Spencer Dawkins has entered the following ballot posi=
tion for
draft-ietf-bfcpbis-rfc4582bis-15: Discuss

When respondin=
g, 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 par=
agraph, however.)


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


The document, along with oth=
er ballot positions, can be found here:
https://datatr=
acker.ietf.org/doc/draft-ietf-bfcpbis-rfc4582bis/




DISCUSS:


Thanks for working throug=
h my Discuss and Comments on -13. I'm mostly
good (at the Dis=
cuss level), but have one remaining concern!
 , on
section
14.  Security Considerations

   BFCP use=
s TLS/DTLS to provide mutual authentication between clients
   and serve=
rs.  TLS/DTLS also provides replay and integrity protection
   and confi=
dentiality.  It is RECOMMENDED that TLS/DTLS with an
   encryption algor=
ithm according to Section 7 always be used.  In cases
   where signaling=
/control traffic is properly protected, as described
   in Section 9 it =
is REQUIRED to use a mandated encryption algorithm.
   BFCP entities MAY=
 use other security mechanisms as long as they
   provide similar securi=
ty properties.
   
If I'm reading this text correctly (please cor=
rect me if I'm
misunderstanding), it is still allowed to run BFCP ov=
er TCP/UDP without
TLS/DTLS. 

If you run a protocol over TCP with=
out TLS, you're still vulnerable to
on-path attackers, but off-path =
attackers have to insert attack packets
with sequence numbers tha=
t are within t!
 he
current window. That's not
impossible, but it's=
 not easy. So, I'm not happy that TLS isn't required
when you ru=
n BFCP over TCP, but OK, fine.

If you run a protocol over UDP withou=
t DTLS, off-path attackers don't
have this constraint, so inserting =
attack packets off-path is much
easier. That makes BFCP much more vulner=
able to attack over UDP than it
was over TCP. 

Is that really OK?=
 That seems quite odd to me, when said without a clear
warning that if y=
ou do not use DTLS (or equivalent) security mechanisms
the protocol is v=
ulnerable to various attacks.

I=E2=80=99d have preferred section 7 t=
o have said =E2=80=9CSHOULD use TLS or DTLS=E2=80=9D and
then have gone =
on to explain - =E2=80=9Creasons for not using DTLS include ...
but when=
 TLS or DTLS is not used the protocol becomes vulnerable to
security att=
acks (e.g. ...).=E2=80=9D



COMMENT:


I have a couple of Comments on !
 new
text:


6.2.2.  ICMP Error Handling 
   
=
   ICMP is not used with unreliable transports due to risks asociated 
 =
  with off-path attacks.  Any ICMP messages received over an
unreliable =

   transport MUST be ignored.
   
ICMP is inherently unreliable -=
 and is itself a control transport, rather
than sent over another transp=
ort. I think I know what you mean, but it's
not what the text says. =
Perhaps you mean

   ICMP is not usable when BFCP is running over an =
unreliable transport
due 
   to risks associated with off-path attack=
s.  Any ICMP messages
associated 
   with BFCP running over an unreli=
able transport MUST be ignored.
   
The new text says:

=E2=80=
=9Cpredictable conference identifiers in conjunction with a non-secure
t=
ransport protocol makes BFCP more susceptible to forged request and
resp=
onse messages.  See the Security Considerations section regarding
the
recommendation to use a secure transport.)=E2=80=9D

- This text  cou=
ld be improved a little by changing this to:

=E2=80=9C predictable c=
onference identifiers in conjunction with a non-secure
transport protoco=
l makes BFCP susceptible to off path data injection
attacks, where an at=
tacker can forge a request or response message.=E2=80=9D

However, th=
is falls short of saying you should randomize the conference
ID.

=
The current text could be OK if it is hard or impossible to randomize forsome reason, but I=E2=80=99d have thought if it was possible this should =
be
RECOMMENDED either as the default method, or at least as a more secur=
e
alternative for an unreliable transport.
   
Cleaning up the las=
t few Comments on -13:

I'm still working through the conflation =
of transports and version
numbers. It's getting better, but the curr=
ent text says:

   =E2=80=9CIf a floor control server receives a
<=
/div>
   messag!
 e with
an unsupported version field value, the server MUST
   =
indicate it does not support the protocol version by sending an Error
  =
 message with parameter value 12 (Unsupported Version).=E2=80=9C

I=
=E2=80=99d have expected this error message to also have been returned if t=
he
transport did not match.

Would it be correct if the text said:=


  =E2=80=9CIf a floor control server receives a
   message with =
an unsupported version field value
   or a message with a version number=
 that is not permitted
   with the transport over which it was received,=
  the server MUST
   indicate it does not support the protocol version b=
y sending an Error
   message with parameter value 12 (Unsupported Versi=
on).=E2=80=9C



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

--001a11440bccf58d5b0523c3ce25-- From nobody Wed Nov 4 20:54:52 2015 Return-Path: X-Original-To: bfcpbis@ietfa.amsl.com Delivered-To: bfcpbis@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BE1A11B390F; Wed, 4 Nov 2015 20:54:50 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.701 X-Spam-Level: X-Spam-Status: No, score=-1.701 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_ADSP_ALL=0.8, DKIM_SIGNED=0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, T_DKIM_INVALID=0.01, 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 cLEgU3EqWS4w; Wed, 4 Nov 2015 20:54:47 -0800 (PST) Received: from dublin.packetizer.com (dublin.packetizer.com [75.101.130.125]) (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 BC2C01B391F; Wed, 4 Nov 2015 20:54:44 -0800 (PST) Received: from dhcp-26-115.meeting.ietf94.jp (dhcp-26-115.meeting.ietf94.jp [133.93.26.115]) (authenticated bits=0) by dublin.packetizer.com (8.15.2/8.15.2) with ESMTPSA id tA54sbq4018152 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 4 Nov 2015 23:54:39 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=packetizer.com; s=dublin; t=1446699281; bh=IPskXdfNvWp8wiedBaB6u5dXHyQt4TDXADIgVGovIuo=; h=In-Reply-To:References:Subject:From:Date:To:CC; b=liflID/q/TtI7N+5Oy4bhHE9RBF0BAa21TSuiisakSA3kDK+Ff3DyWqgyX1StEAPa IW2Dut4s6lgAYYqCiXNN/sEyWxINktZYG44GWr11H57DD/8hjIOJkpWLyN4fY7GMbd FoOKsjqSpRG2WbIeayHTLmgIT8ZdDtiRagwJTIqU= User-Agent: K-9 Mail for Android In-Reply-To: References: <20151105023108.17210.54132.idtracker@ietfa.amsl.com> <19C90DA9-652D-499F-8462-7EC7878307CB@packetizer.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----YT3WWGLV170470J3HV0QDACVJYWN6W" Content-Transfer-Encoding: 8bit From: "Paul E. Jones" Date: Thu, 05 Nov 2015 13:54:35 +0900 To: Spencer Dawkins at IETF Message-ID: X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.5.12 (dublin.packetizer.com [10.109.150.103]); Wed, 04 Nov 2015 23:54:41 -0500 (EST) Archived-At: Cc: "gorry@erg.abdn.ac.uk" , bfcpbis-chairs@ietf.org, bfcpbis@ietf.org, draft-ietf-bfcpbis-rfc4582bis@ietf.org, The IESG , Mary Barnes Subject: Re: [bfcpbis] Spencer Dawkins' Discuss on draft-ietf-bfcpbis-rfc4582bis-15: (with DISCUSS and COMMENT) X-BeenThere: bfcpbis@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: BFCPBIS working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Nov 2015 04:54:50 -0000 ------YT3WWGLV170470J3HV0QDACVJYWN6W Content-Transfer-Encoding: 8bit Content-Type: text/plain; charset=UTF-8 Spencer, Unfortunately, I don't know the answer to that question and we need to ask one of the authors. I came in at the end here to try to address DISCUSS points, but don't have background on why a non-secure option was allowed. Any other authors or folks in the WG able to answer that question? Is anyone opposed to making (D)TLS mandatory? Paul -------- Original Message -------- From: Spencer Dawkins at IETF Sent: November 5, 2015 1:46:21 PM GMT+09:00 To: "Paul E. Jones" Cc: "gorry@erg.abdn.ac.uk" , bfcpbis-chairs@ietf.org, bfcpbis@ietf.org, draft-ietf-bfcpbis-rfc4582bis@ietf.org, The IESG , Mary Barnes Subject: Re: [bfcpbis] Spencer Dawkins' Discuss on draft-ietf-bfcpbis-rfc4582bis-15: (with DISCUSS and COMMENT) Hi, Paul, On Thu, Nov 5, 2015 at 1:24 PM, Paul E. Jones wrote: > Spencer, > > I think all of the suggestions in the comments are perfectly fine and I > can accept those. With respect to the random conference ID, I think the > issue is that this ID is considered outside the protocol. This protocol > just uses this ID. If that's wrong, I would agree suggesting randomizing it > would be good. > > With respect to the DISCUSS point, I'm not sure what to do. Section 7 says > TLS or DTLS must be supported, but that doesn't mean it must be used. I > guess that's your concern. I think the security considerations section is > the right place to provide warning to those who choose not use it. And > there is warning. What more really needs to be said? > > I'm entirely OK with more scary language, but would prefer it added only > to security considerations. > So, we both want to do the right thing. Let's talk about what that is, before we spend time twiddling words. The reason why we're having this chat, is that DTLS is RECOMMENDED, not REQUIRED. Can you help me understand why that is? I'm seeing language in the spec that looks, to me, like it's trying to hold the door open in case another mechanism with equivalent functionality to DTLS becomes available (so, not MUST DTLS, because you couldn't use it). For example, from the Security Considerations section: BFCP entities MAY use other security mechanisms as long as they provide similar security properties. Is that relevant to my question, or am I misunderstanding, and there are use cases where unencrypted BFCP is necessary? Thanks, Spencer > Paul > > ------------------------------ > *From:* Spencer Dawkins > *Sent:* November 5, 2015 11:31:08 AM GMT+09:00 > *To:* The IESG > *Cc:* gorry@erg.abdn.ac.uk, mary.ietf.barnes@gmail.com, > bfcpbis-chairs@ietf.org, bfcpbis@ietf.org, > draft-ietf-bfcpbis-rfc4582bis@ietf.org > *Subject:* [bfcpbis] Spencer Dawkins' Discuss on > draft-ietf-bfcpbis-rfc4582bis-15: (with DISCUSS and COMMENT) > > Spencer Dawkins has entered the following ballot position for > draft-ietf-bfcpbis-rfc4582bis-15: Discuss > > When responding, please keep the subject line intact and reply to all > email addresses included in the To and CC lines. (Feel free to cut this > introductory paragraph, however.) > > > Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html > for more information about IESG DISCUSS and COMMENT positions. > > > The document, along with other ballot positions, can be found here: > https://datatracker.ietf.org/doc/draft-ietf-bfcpbis-rfc4582bis/ > > > > ------------------------------ > > DISCUSS: > ------------------------------ > > > Thanks for working through my Discuss and Comments on -13. I'm mostly > good (at the Discuss level), but have one remaining concern! > , on > section > 14. Security Considerations > > BFCP uses TLS/DTLS to provide mutual authentication between clients > and servers. TLS/DTLS also provides replay and integrity protection > and confidentiality. It is RECOMMENDED that TLS/DTLS with an > encryption algorithm according to Section 7 always be used. In cases > where signaling/control traffic is properly protected, as described > in Section 9 it is REQUIRED to use a mandated encryption algorithm. > BFCP entities MAY use other security mechanisms as long as they > provide similar security properties. > > If I'm reading this text correctly (please correct me if I'm > misunderstanding), it is still allowed to run BFCP over TCP/UDP without > TLS/DTLS. > > If you run a protocol over TCP without TLS, you're still vulnerable to > on-path attackers, but off-path attackers have to insert attack packets > with sequence numbers that are within t! > he > current window. That's not > impossible, but it's not easy. So, I'm not happy that TLS isn't required > when you run BFCP over TCP, but OK, fine. > > If you run a protocol over UDP without DTLS, off-path attackers don't > have this constraint, so inserting attack packets off-path is much > easier. That makes BFCP much more vulnerable to attack over UDP than it > was over TCP. > > Is that really OK? That seems quite odd to me, when said without a clear > warning that if you do not use DTLS (or equivalent) security mechanisms > the protocol is vulnerable to various attacks. > > I’d have preferred section 7 to have said “SHOULD use TLS or DTLS” and > then have gone on to explain - “reasons for not using DTLS include ... > but when TLS or DTLS is not used the protocol becomes vulnerable to > security attacks (e.g. ...).” > > > ------------------------------ > > COMMENT: > ------------------------------ > > > > I have a couple of Comments on ! > new > text: > > > 6.2.2. ICMP Error Handling > > ICMP is not used with unreliable transports due to risks asociated > with off-path attacks. Any ICMP messages received over an > unreliable > transport MUST be ignored. > > ICMP is inherently unreliable - and is itself a control transport, rather > than sent over another transport. I think I know what you mean, but it's > not what the text says. Perhaps you mean > > ICMP is not usable when BFCP is running over an unreliable transport > due > to risks associated with off-path attacks. Any ICMP messages > associated > with BFCP running over an unreliable transport MUST be ignored. > > The new text says: > > “predictable conference identifiers in conjunction with a non-secure > transport protocol makes BFCP more susceptible to forged request and > response messages. See the Security Considerations section regarding > the > recommendation to use a secure transport.)” > > - This text could be improved a little by changing this to: > > “ predictable conference identifiers in conjunction with a non-secure > transport protocol makes BFCP susceptible to off path data injection > attacks, where an attacker can forge a request or response message.” > > However, this falls short of saying you should randomize the conference > ID. > > The current text could be OK if it is hard or impossible to randomize for > some reason, but I’d have thought if it was possible this should be > RECOMMENDED either as the default method, or at least as a more secure > alternative for an unreliable transport. > > Cleaning up the last few Comments on -13: > > I'm still working through the conflation of transports and version > numbers. It's getting better, but the current text says: > > “If a floor control server receives a > messag! > e with > an unsupported version field value, the server MUST > indicate it does not support the protocol version by sending an Error > message with parameter value 12 (Unsupported Version).“ > > I’d have expected this error message to also have been returned if the > transport did not match. > > Would it be correct if the text said: > > “If a floor control server receives a > message with an unsupported version field value > or a message with a version number that is not permitted > with the transport over which it was received, the server MUST > indicate it does not support the protocol version by sending an Error > message with parameter value 12 (Unsupported Version).“ > > > ------------------------------ > > bfcpbis mailing list > bfcpbis@ietf.org > https://www.ietf.org/mailman/listinfo/bfcpbis > > ------------------------------------------------------------------------ _______________________________________________ bfcpbis mailing list bfcpbis@ietf.org https://www.ietf.org/mailman/listinfo/bfcpbis ------YT3WWGLV170470J3HV0QDACVJYWN6W Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit Spencer,

Unfortunately, I don't know the answer to that question and we need to ask one of the authors. I came in at the end here to try to address DISCUSS points, but don't have background on why a non-secure option was allowed.

Any other authors or folks in the WG able to answer that question? Is anyone opposed to making (D)TLS mandatory?

Paul

From: Spencer Dawkins at IETF <spencerdawkins.ietf@gmail.com>
Sent: November 5, 2015 1:46:21 PM GMT+09:00
To: "Paul E. Jones" <paulej@packetizer.com>
Cc: "gorry@erg.abdn.ac.uk" <gorry@erg.abdn.ac.uk>, bfcpbis-chairs@ietf.org, bfcpbis@ietf.org, draft-ietf-bfcpbis-rfc4582bis@ietf.org, The IESG <iesg@ietf.org>, Mary Barnes <mary.ietf.barnes@gmail.com>
Subject: Re: [bfcpbis] Spencer Dawkins' Discuss on draft-ietf-bfcpbis-rfc4582bis-15: (with DISCUSS and COMMENT)

Hi, Paul,

On Thu, Nov 5, 2015 at 1:24 PM, Paul E. Jones <paulej@packetizer.com> wrote:
Spencer,

I think all of the suggestions in the comments are perfectly fine and I can accept those. With respect to the random conference ID, I think the issue is that this ID is considered outside the protocol. This protocol just uses this ID. If that's wrong, I would agree suggesting randomizing it would be good.

With respect to the DISCUSS point, I'm not sure what to do. Section 7 says TLS or DTLS must be supported, but that doesn't mean it must be used. I guess that's your concern. I think the security considerations section is the right place to provide warning to those who choose not use it. And there is warning. What more really needs to be said?

I'm entirely OK with more scary language, but would prefer it added only to security considerations.

So, we both want to do the right thing. Let's talk about what that is, before we spend time twiddling words.

The reason why we're having this chat, is that DTLS is RECOMMENDED, not REQUIRED. Can you help me understand why that is? 

I'm seeing language in the spec that looks, to me, like it's trying to hold the door open in case another mechanism with equivalent functionality to DTLS becomes available (so, not MUST DTLS, because you couldn't use it). For example, from the Security Considerations section:

   BFCP entities MAY use other security mechanisms as long as they
   provide similar security properties.

Is that relevant to my question, or am I misunderstanding, and there are use cases where unencrypted BFCP is necessary?

Thanks,

Spencer
 
Paul

From: Spencer Dawkins <spencerdawkins.ietf@gmail.com>
Sent: November 5, 2015 11:31:08 AM GMT+09:00
To: The IESG <iesg@ietf.org>
Cc: gorry@erg.abdn.ac.uk, mary.ietf.barnes@gmail.com, bfcpbis-chairs@ietf.org, bfcpbis@ietf.org, draft-ietf-bfcpbis-rfc4582bis@ietf.org
Subject: [bfcpbis] Spencer Dawkins' Discuss on draft-ietf-bfcpbis-rfc4582bis-15: (with DISCUSS and COMMENT)

Spencer Dawkins has entered the following ballot position for
draft-ietf-bfcpbis-rfc4582bis-15: Discuss

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


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


The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-bfcpbis-rfc4582bis/




DISCUSS:


Thanks for working through my Discuss and Comments on -13. I'm mostly
good (at the Discuss level), but have one remaining concern!
 , on
section
14.  Security Considerations

   BFCP uses TLS/DTLS to provide mutual authentication between clients
   and servers.  TLS/DTLS also provides replay and integrity protection
   and confidentiality.  It is RECOMMENDED that TLS/DTLS with an
   encryption algorithm according to Section 7 always be used.  In cases
   where signaling/control traffic is properly protected, as described
   in Section 9 it is REQUIRED to use a mandated encryption algorithm.
   BFCP entities MAY use other security mechanisms as long as they
   provide similar security properties.
   
If I'm reading this text correctly (please correct me if I'm
misunderstanding), it is still allowed to run BFCP over TCP/UDP without
TLS/DTLS. 

If you run a protocol over TCP without TLS, you're still vulnerable to
on-path attackers, but off-path attackers have to insert attack packets
with !
 sequence
numbers that are within t!
 he
current window. That's not
impossible, but it's not easy. So, I'm not happy that TLS isn't required
when you run BFCP over TCP, but OK, fine.

If you run a protocol over UDP without DTLS, off-path attackers don't
have this constraint, so inserting attack packets off-path is much
easier. That makes BFCP much more vulnerable to attack over UDP than it
was over TCP. 

Is that really OK? That seems quite odd to me, when said without a clear
warning that if you do not use DTLS (or equivalent) security mechanisms
the protocol is vulnerable to various attacks.

I’d have preferred section 7 to have said “SHOULD use TLS or DTLS” and
then have gone on to explain - “reasons for not using DTLS include ...
but when TLS or DTLS is not used the protocol becomes vulnerable to
security attacks (e.g. ...).”



COMMENT:


I have a couple of Comments on !
 new
text:


6.2.2.  ICMP Error Handling 
   
   ICMP is not used with unreliable transports due to risks asociated 
   with off-path attacks.  Any ICMP messages received over an
unreliable 
   transport MUST be ignored.
   
ICMP is inherently unreliable - and is itself a control transport, rather
than sent over another transport. I think I know what you mean, but it's
not what the text says. Perhaps you mean

   ICMP is not usable when BFCP is running over an unreliable transport
due 
   to risks associated with off-path attacks.  Any ICMP messages
associated 
   with BFCP running over an unreliable transport MUST be ignored.
   
The new text says:

“predictable conference identifiers in conjunction with a non-secure
transport protocol makes BFCP more susceptible to forged request and
response messages.  See the Security Considerations sect!
 ion
regarding
the
recommendation to use a secure transport.)”

- This text  could be improved a little by changing this to:

“ predictable conference identifiers in conjunction with a non-secure
transport protocol makes BFCP susceptible to off path data injection
attacks, where an attacker can forge a request or response message.”

However, this falls short of saying you should randomize the conference
ID.

The current text could be OK if it is hard or impossible to randomize for
some reason, but I’d have thought if it was possible this should be
RECOMMENDED either as the default method, or at least as a more secure
alternative for an unreliable transport.
   
Cleaning up the last few Comments on -13:

I'm still working through the conflation of transports and version
numbers. It's getting better, but the current text says:

   “If a floor control server receives a
   messag!
 e with
an unsupported version field value, the server MUST
   indicate it does not support the protocol version by sending an Error
   message with parameter value 12 (Unsupported Version).“

I’d have expected this error message to also have been returned if the
transport did not match.

Would it be correct if the text said:

  “If a floor control server receives a
   message with an unsupported version field value
   or a message with a version number that is not permitted
   with the transport over which it was received,  the server MUST
   indicate it does not support the protocol version by sending an Error
   message with parameter value 12 (Unsupported Version).“



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


bfcpbis mailing list
bfcpbis@ietf.org
https://www.ietf.org/mailman/listinfo/bfcpbis
------YT3WWGLV170470J3HV0QDACVJYWN6W-- From nobody Wed Nov 4 22:42:34 2015 Return-Path: X-Original-To: bfcpbis@ietfa.amsl.com Delivered-To: bfcpbis@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E6CF51B3AC2 for ; Wed, 4 Nov 2015 22:42:32 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=unavailable 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 RYkuaw8YlQas for ; Wed, 4 Nov 2015 22:42:29 -0800 (PST) Received: from out2-smtp.messagingengine.com (out2-smtp.messagingengine.com [66.111.4.26]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A119A1B3AC7 for ; Wed, 4 Nov 2015 22:42:29 -0800 (PST) Received: from compute3.internal (compute3.nyi.internal [10.202.2.43]) by mailout.nyi.internal (Postfix) with ESMTP id 9C1AD21079 for ; Thu, 5 Nov 2015 01:36:18 -0500 (EST) Received: from frontend1 ([10.202.2.160]) by compute3.internal (MEProxy); Thu, 05 Nov 2015 01:36:18 -0500 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=cooperw.in; h=cc :content-type:date:from:in-reply-to:message-id:mime-version :references:subject:to:x-sasl-enc:x-sasl-enc; s=mesmtp; bh=e0dRJ gkqqGigMTEraZK/k5hUHLU=; b=gxJIP6HYSdh31nTFNinmNUmDWwzbuaMZnznDF PsrtAY4d45qLyt44FZSEX+n8PqzGBJR8jpjLxwMWDFuwvq+OyKKCcPtBexwtgdB5 cxQ7hluQSxXe8QARDXMBYnMe0+1vmikh3fQFEb2e1pa73sni3VSMZZg7nrkawvx4 NZlTic= DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d= messagingengine.com; h=cc:content-type:date:from:in-reply-to :message-id:mime-version:references:subject:to:x-sasl-enc :x-sasl-enc; s=smtpout; bh=e0dRJgkqqGigMTEraZK/k5hUHLU=; b=ch5MV uZ1pUqbCeqcG7Dlxj8kwFqGOHHZr+DnGP7i+hDeg+SSP4NR04UNPw9q86ixQaAFs 4KTKUmyIjMnuLcE0C3dsHz/0hK+XCSME8lV338wK7GCIxrBQ7bLbGdUK73XC6eHD rFJeXINDrkujMC1rjNImSQ/qfT5XUsbdFbWKe8= X-Sasl-enc: 6mBxVpF0qbiOEcu+uu1DG+MMfu9kzKz/5Ezvavzq+ZIc 1446705377 Received: from [10.24.188.39] (unknown [128.107.241.176]) by mail.messagingengine.com (Postfix) with ESMTPA id C6276C016EE; Thu, 5 Nov 2015 01:36:15 -0500 (EST) Content-Type: multipart/alternative; boundary="Apple-Mail=_44EC733D-93FE-4721-9CB4-D5CFD58A4EEC" Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2104\)) From: Alissa Cooper In-Reply-To: Date: Thu, 5 Nov 2015 15:36:13 +0900 Message-Id: References: <20151105023108.17210.54132.idtracker@ietfa.amsl.com> <19C90DA9-652D-499F-8462-7EC7878307CB@packetizer.com> To: "Paul E. Jones" X-Mailer: Apple Mail (2.2104) Archived-At: Cc: "gorry@erg.abdn.ac.uk" , bfcpbis-chairs@ietf.org, bfcpbis@ietf.org, draft-ietf-bfcpbis-rfc4582bis@ietf.org, IESG , Mary Barnes , Spencer Dawkins at IETF Subject: Re: [bfcpbis] Spencer Dawkins' Discuss on draft-ietf-bfcpbis-rfc4582bis-15: (with DISCUSS and COMMENT) X-BeenThere: bfcpbis@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: BFCPBIS working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Nov 2015 06:42:33 -0000 --Apple-Mail=_44EC733D-93FE-4721-9CB4-D5CFD58A4EEC Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Hi Spencer, My understanding is that DTLS is not REQUIRED because that would be a = non-backwards-compatible change with RFC 4582, and the goal with this = bis was to remain backwards compatible. Charles may be able to elaborate. Alissa > On Nov 5, 2015, at 1:54 PM, Paul E. Jones = wrote: >=20 > Spencer, >=20 > Unfortunately, I don't know the answer to that question and we need to = ask one of the authors. I came in at the end here to try to address = DISCUSS points, but don't have background on why a non-secure option was = allowed. >=20 > Any other authors or folks in the WG able to answer that question? Is = anyone opposed to making (D)TLS mandatory? >=20 > Paul >=20 > From: Spencer Dawkins at IETF > Sent: November 5, 2015 1:46:21 PM GMT+09:00 > To: "Paul E. Jones" > Cc: "gorry@erg.abdn.ac.uk" , = bfcpbis-chairs@ietf.org, bfcpbis@ietf.org, = draft-ietf-bfcpbis-rfc4582bis@ietf.org, The IESG , Mary = Barnes > Subject: Re: [bfcpbis] Spencer Dawkins' Discuss on = draft-ietf-bfcpbis-rfc4582bis-15: (with DISCUSS and COMMENT) >=20 > Hi, Paul, >=20 > On Thu, Nov 5, 2015 at 1:24 PM, Paul E. Jones > wrote: > Spencer, >=20 > I think all of the suggestions in the comments are perfectly fine and = I can accept those. With respect to the random conference ID, I think = the issue is that this ID is considered outside the protocol. This = protocol just uses this ID. If that's wrong, I would agree suggesting = randomizing it would be good. >=20 > With respect to the DISCUSS point, I'm not sure what to do. Section 7 = says TLS or DTLS must be supported, but that doesn't mean it must be = used. I guess that's your concern. I think the security considerations = section is the right place to provide warning to those who choose not = use it. And there is warning. What more really needs to be said? >=20 > I'm entirely OK with more scary language, but would prefer it added = only to security considerations. >=20 > So, we both want to do the right thing. Let's talk about what that is, = before we spend time twiddling words. >=20 > The reason why we're having this chat, is that DTLS is RECOMMENDED, = not REQUIRED. Can you help me understand why that is?=20 >=20 > I'm seeing language in the spec that looks, to me, like it's trying to = hold the door open in case another mechanism with equivalent = functionality to DTLS becomes available (so, not MUST DTLS, because you = couldn't use it). For example, from the Security Considerations section: >=20 > BFCP entities MAY use other security mechanisms as long as they > provide similar security properties. >=20 > Is that relevant to my question, or am I misunderstanding, and there = are use cases where unencrypted BFCP is necessary? >=20 > Thanks, >=20 > Spencer > =20 > Paul >=20 > From: Spencer Dawkins > > Sent: November 5, 2015 11:31:08 AM GMT+09:00 > To: The IESG > > Cc: gorry@erg.abdn.ac.uk , = mary.ietf.barnes@gmail.com , = bfcpbis-chairs@ietf.org , = bfcpbis@ietf.org , = draft-ietf-bfcpbis-rfc4582bis@ietf.org = > Subject: [bfcpbis] Spencer Dawkins' Discuss on = draft-ietf-bfcpbis-rfc4582bis-15: (with DISCUSS and COMMENT) >=20 > Spencer Dawkins has entered the following ballot position for > draft-ietf-bfcpbis-rfc4582bis-15: Discuss >=20 > When responding, please keep the subject line intact and reply to all > email addresses included in the To and CC lines. (Feel free to cut = this > introductory paragraph, however.) >=20 >=20 > Please refer to = https://www.ietf.org/iesg/statement/discuss-criteria.html = > for more information about IESG DISCUSS and COMMENT positions. >=20 >=20 > The document, along with other ballot positions, can be found here: > https://datatracker.ietf.org/doc/draft-ietf-bfcpbis-rfc4582bis = / >=20 >=20 >=20 >=20 > DISCUSS: >=20 >=20 > Thanks for working through my Discuss and Comments on -13. I'm mostly > good (at the Discuss level), but have one remaining concern! > , on > section > 14. Security Considerations >=20 > BFCP uses TLS/DTLS to provide mutual authentication between clients > and servers. TLS/DTLS also provides replay and integrity = protection > and confidentiality. It is RECOMMENDED that TLS/DTLS with an > encryption algorithm according to Section 7 always be used. In = cases > where signaling/control traffic is properly protected, as described > in Section 9 it is REQUIRED to use a mandated encryption algorithm. > BFCP entities MAY use other security mechanisms as long as they > provide similar security properties. > =20 > If I'm reading this text correctly (please correct me if I'm > misunderstanding), it is still allowed to run BFCP over TCP/UDP = without > TLS/DTLS.=20 >=20 > If you run a protocol over TCP without TLS, you're still vulnerable to > on-path attackers, but off-path attackers have to insert attack = packets > with ! > sequence > numbers that are within t! > he > current window. That's not > impossible, but it's not easy. So, I'm not happy that TLS isn't = required > when you run BFCP over TCP, but OK, fine. >=20 > If you run a protocol over UDP without DTLS, off-path attackers don't > have this constraint, so inserting attack packets off-path is much > easier. That makes BFCP much more vulnerable to attack over UDP than = it > was over TCP.=20 >=20 > Is that really OK? That seems quite odd to me, when said without a = clear > warning that if you do not use DTLS (or equivalent) security = mechanisms > the protocol is vulnerable to various attacks. >=20 > I=E2=80=99d have preferred section 7 to have said =E2=80=9CSHOULD use = TLS or DTLS=E2=80=9D and > then have gone on to explain - =E2=80=9Creasons for not using DTLS = include ... > but when TLS or DTLS is not used the protocol becomes vulnerable to > security attacks (e.g. ...).=E2=80=9D >=20 >=20 >=20 > COMMENT: >=20 >=20 > I have a couple of Comments on ! > new > text: >=20 >=20 > 6.2.2. ICMP Error Handling=20 > =20 > ICMP is not used with unreliable transports due to risks asociated=20= > with off-path attacks. Any ICMP messages received over an > unreliable=20 > transport MUST be ignored. > =20 > ICMP is inherently unreliable - and is itself a control transport, = rather > than sent over another transport. I think I know what you mean, but = it's > not what the text says. Perhaps you mean >=20 > ICMP is not usable when BFCP is running over an unreliable = transport > due=20 > to risks associated with off-path attacks. Any ICMP messages > associated=20 > with BFCP running over an unreliable transport MUST be ignored. > =20 > The new text says: >=20 > =E2=80=9Cpredictable conference identifiers in conjunction with a = non-secure > transport protocol makes BFCP more susceptible to forged request and > response messages. See the Security Considerations sect! > ion > regarding > the > recommendation to use a secure transport.)=E2=80=9D >=20 > - This text could be improved a little by changing this to: >=20 > =E2=80=9C predictable conference identifiers in conjunction with a = non-secure > transport protocol makes BFCP susceptible to off path data injection > attacks, where an attacker can forge a request or response message.=E2=80= =9D >=20 > However, this falls short of saying you should randomize the = conference > ID. >=20 > The current text could be OK if it is hard or impossible to randomize = for > some reason, but I=E2=80=99d have thought if it was possible this = should be > RECOMMENDED either as the default method, or at least as a more secure > alternative for an unreliable transport. > =20 > Cleaning up the last few Comments on -13: >=20 > I'm still working through the conflation of transports and version > numbers. It's getting better, but the current text says: >=20 > =E2=80=9CIf a floor control server receives a > messag! > e with > an unsupported version field value, the server MUST > indicate it does not support the protocol version by sending an = Error > message with parameter value 12 (Unsupported Version).=E2=80=9C >=20 > I=E2=80=99d have expected this error message to also have been = returned if the > transport did not match. >=20 > Would it be correct if the text said: >=20 > =E2=80=9CIf a floor control server receives a > message with an unsupported version field value > or a message with a version number that is not permitted > with the transport over which it was received, the server MUST > indicate it does not support the protocol version by sending an = Error > message with parameter value 12 (Unsupported Version).=E2=80=9C >=20 >=20 >=20 > bfcpbis mailing list > bfcpbis@ietf.org > https://www.ietf.org/mailman/listinfo/bfcpbis = >=20 >=20 >=20 > bfcpbis mailing list > bfcpbis@ietf.org > https://www.ietf.org/mailman/listinfo/bfcpbis = > _______________________________________________ > bfcpbis mailing list > bfcpbis@ietf.org > https://www.ietf.org/mailman/listinfo/bfcpbis --Apple-Mail=_44EC733D-93FE-4721-9CB4-D5CFD58A4EEC Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8
Hi Spencer,

My understanding is that DTLS is not = REQUIRED because that would be a non-backwards-compatible change with = RFC 4582, and the goal with this bis was to remain backwards = compatible.

Charles may be able to elaborate.

Alissa

On = Nov 5, 2015, at 1:54 PM, Paul E. Jones <paulej@packetizer.com> wrote:

Spencer,

Unfortunately, I don't know the answer to that question and we need to = ask one of the authors. I came in at the end here to try to address = DISCUSS points, but don't have background on why a non-secure option was = allowed.

Any other authors or folks in the WG able to answer that question? Is = anyone opposed to making (D)TLS mandatory?

Paul

From: Spencer Dawkins at IETF <spencerdawkins.ietf@gmail.com>
Sent: November 5, 2015 1:46:21 PM GMT+09:00
To: "Paul E. Jones" <paulej@packetizer.com>
Cc: "gorry@erg.abdn.ac.uk" <gorry@erg.abdn.ac.uk>, bfcpbis-chairs@ietf.org, bfcpbis@ietf.org, draft-ietf-bfcpbis-rfc4582bis@ietf.org, The IESG <iesg@ietf.org>, Mary = Barnes <mary.ietf.barnes@gmail.com>
Subject: Re: [bfcpbis] Spencer Dawkins' Discuss on = draft-ietf-bfcpbis-rfc4582bis-15: (with DISCUSS and COMMENT)

Hi, Paul,

On Thu, Nov 5, 2015 at 1:24 PM, = Paul E. Jones <paulej@packetizer.com> wrote:
Spencer,

I think all of the suggestions in the comments are perfectly fine and I = can accept those. With respect to the random conference ID, I think the = issue is that this ID is considered outside the protocol. This protocol = just uses this ID. If that's wrong, I would agree suggesting = randomizing it would be good.

With respect to the DISCUSS point, I'm not sure what to do. Section 7 = says TLS or DTLS must be supported, but that doesn't mean it must be = used. I guess that's your concern. I think the security considerations = section is the right place to provide warning to those who choose not = use it. And there is warning. What more really needs to be said?

I'm entirely OK with more scary language, but would prefer it added only = to security considerations.

So, we both want to do the right thing. = Let's talk about what that is, before we spend time twiddling = words.

The = reason why we're having this chat, is that DTLS is RECOMMENDED, not = REQUIRED. Can you help me understand why that is? 

I'm seeing language in = the spec that looks, to me, like it's trying to hold the door open in = case another mechanism with equivalent functionality to DTLS becomes = available (so, not MUST DTLS, because you couldn't use it). For example, = from the Security Considerations section:

   BFCP entities MAY =
use other security mechanisms as long as they
   provide similar security properties.

Is that relevant to my question, or am = I misunderstanding, and there are use cases where unencrypted BFCP is = necessary?

Thanks,

Spencer
 
Paul

From: Spencer Dawkins <spencerdawkins.ietf@gmail.com>
Sent: November 5, 2015 11:31:08 AM GMT+09:00
To: The IESG <iesg@ietf.org>
Cc: gorry@erg.abdn.ac.uk, mary.ietf.barnes@gmail.com, bfcpbis-chairs@ietf.org, bfcpbis@ietf.org, draft-ietf-bfcpbis-rfc4582bis@ietf.org
Subject: [bfcpbis] Spencer Dawkins' Discuss on = draft-ietf-bfcpbis-rfc4582bis-15: (with DISCUSS and COMMENT)

Spencer Dawkins has entered the =
following ballot position for
draft-ietf-bfcpbis-rfc4582bis-15: Discuss

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


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


The document, =
along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-bfcpbis-rfc4582bis<=
/a>/




DISCUSS:


Thanks for working through my =
Discuss and Comments on -13. I'm mostly
good (at =
the Discuss level), but have one remaining concern!
 , on
section
14.  Security Considerations

   BFCP uses TLS/DTLS to provide mutual =
authentication between clients
   and servers.  TLS/DTLS =
also provides replay and integrity protection
   and =
confidentiality.  It is RECOMMENDED that TLS/DTLS with an
 =
  encryption algorithm according to Section 7 always be used.  In =
cases
   where signaling/control traffic is properly =
protected, as described
   in Section 9 it is REQUIRED to =
use a mandated encryption algorithm.
   BFCP entities MAY =
use other security mechanisms as long as they
   provide =
similar security properties.
   
If I'm =
reading this text correctly (please correct me if I'm
misunderstanding), it is still allowed to run BFCP over =
TCP/UDP without
TLS/DTLS. 

If =
you run a protocol over TCP without TLS, you're still vulnerable to
on-path attackers, but off-path attackers have to insert =
attack packets
with !
 sequence
numbers that are within t!
 he
current window. That's not
impossible, =
but it's not easy. So, I'm not happy that TLS isn't required
when you run BFCP over TCP, but OK, fine.

If you run a protocol over UDP without DTLS, off-path =
attackers don't
have this constraint, so inserting attack =
packets off-path is much
easier. That makes BFCP much more =
vulnerable to attack over UDP than it
was over TCP. 

Is that really OK? That seems quite odd to me, =
when said without a clear
warning that if you do not use =
DTLS (or equivalent) security mechanisms
the protocol is =
vulnerable to various attacks.

I=E2=80=99d =
have preferred section 7 to have said =E2=80=9CSHOULD use TLS or DTLS=E2=80=
=9D and
then have gone on to explain - =E2=80=9Creasons =
for not using DTLS include ...
but when TLS or DTLS is not =
used the protocol becomes vulnerable to
security attacks =
(e.g. ...).=E2=80=9D



COMMENT:


I have a couple of Comments on !
 new
text:


6.2.2.  ICMP Error Handling 
   
 =
  ICMP is not used with unreliable transports due to risks asociated 
   with off-path attacks.  Any ICMP messages received over =
an
unreliable 
   transport MUST be =
ignored.
   
ICMP is inherently unreliable - =
and is itself a control transport, rather
than sent over =
another transport. I think I know what you mean, but it's
not what the text says. Perhaps you mean

   ICMP is not usable when BFCP is running over an unreliable =
transport
due 
   to risks associated with =
off-path attacks.  Any ICMP messages
associated 
   with BFCP running over an unreliable transport MUST be =
ignored.
   
The new text says:

=E2=80=9Cpredictable conference identifiers in =
conjunction with a non-secure
transport protocol makes =
BFCP more susceptible to forged request and
response =
messages.  See the Security Considerations sect!
 ion
regarding
the
recommendation to use a secure transport.)=E2=80=9D

- This text  could be improved a little by changing this =
to:

=E2=80=9C predictable conference =
identifiers in conjunction with a non-secure
transport =
protocol makes BFCP susceptible to off path data injection
attacks, where an attacker can forge a request or response =
message.=E2=80=9D

However, this falls short =
of saying you should randomize the conference
ID.

The current text could be OK if it is hard or =
impossible to randomize for
some reason, but I=E2=80=99d =
have thought if it was possible this should be
RECOMMENDED =
either as the default method, or at least as a more secure
alternative for an unreliable transport.
   
Cleaning up the last few Comments on -13:

I'm still working through the conflation of transports and =
version
numbers. It's getting better, but the current text =
says:

   =E2=80=9CIf a floor control server =
receives a
   messag!
 e with
an unsupported version field value, the server MUST
   indicate it does not support the protocol version by =
sending an Error
   message with parameter value 12 =
(Unsupported Version).=E2=80=9C

I=E2=80=99d =
have expected this error message to also have been returned if the
transport did not match.

Would =
it be correct if the text said:

  =E2=80=9CIf=
 a floor control server receives a
   message with an =
unsupported version field value
   or a message with a =
version number that is not permitted
   with the transport =
over which it was received,  the server MUST
   indicate =
it does not support the protocol version by sending an Error
   message with parameter value 12 (Unsupported =
Version).=E2=80=9C



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



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

= --Apple-Mail=_44EC733D-93FE-4721-9CB4-D5CFD58A4EEC-- From nobody Thu Nov 5 00:43:30 2015 Return-Path: X-Original-To: bfcpbis@ietfa.amsl.com Delivered-To: bfcpbis@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D2CD51A8A72; Thu, 5 Nov 2015 00:43:25 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.51 X-Spam-Level: X-Spam-Status: No, score=-14.51 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_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 WS4OLT1sYVx1; Thu, 5 Nov 2015 00:43:22 -0800 (PST) Received: from rcdn-iport-7.cisco.com (rcdn-iport-7.cisco.com [173.37.86.78]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D52F61A8A56; Thu, 5 Nov 2015 00:43:21 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=22940; q=dns/txt; s=iport; t=1446713001; x=1447922601; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=4qeYCtVz3ni1D6tB+EhR1URHLPg7ey1OoyfAuahqcd8=; b=Q6Zmf22sVvOBGeNgN8H3mZw9lnT5XR2WWVR/Iy7cRo7UxiWkzSuUKjmr boeQ3hK2esiaLMhAF1KuOsS32AmX4/93lynRvcB3G/nODgTGgpNAPtVEJ jI9sQyq+wyPBBgSuw0BtKPIvz4DYY7slai+SEYy26mW1rmDdgIRXoyUf+ w=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: A0AOAgB0FTtW/5JdJa1egm5NU28GvW0BDYFeFwEJhSdKAoE0OBQBAQEBAQEBgQqENQEBAQQBAQFlBgsQAgEIEQMBAQEkBAchBgsUCQgCBAENBRuHfgMSDb0sDYQ8AQEBAQEBAQEBAQEBAQEBAQEBAQEBFASKTIEGglOBVxEBBjkNCYQoBZZIAYUcgnCDIoF0gVqEP45Xg2CDcQEfAQFCghEdFoFAcgGDXTqBBwEBAQ X-IronPort-AV: E=Sophos; i="5.20,246,1444694400"; d="scan'208,217"; a="42148947" Received: from rcdn-core-10.cisco.com ([173.37.93.146]) by rcdn-iport-7.cisco.com with ESMTP; 05 Nov 2015 08:43:20 +0000 Received: from XCH-ALN-017.cisco.com (xch-aln-017.cisco.com [173.36.7.27]) by rcdn-core-10.cisco.com (8.14.5/8.14.5) with ESMTP id tA58hK5p025567 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Thu, 5 Nov 2015 08:43:20 GMT Received: from xch-aln-018.cisco.com (173.36.7.28) by XCH-ALN-017.cisco.com (173.36.7.27) with Microsoft SMTP Server (TLS) id 15.0.1104.5; Thu, 5 Nov 2015 02:43:19 -0600 Received: from xch-aln-018.cisco.com ([173.36.7.28]) by XCH-ALN-018.cisco.com ([173.36.7.28]) with mapi id 15.00.1104.000; Thu, 5 Nov 2015 02:43:19 -0600 From: "Charles Eckel (eckelcu)" To: Spencer Dawkins at IETF , "Paul E. Jones" Thread-Topic: [bfcpbis] Spencer Dawkins' Discuss on draft-ietf-bfcpbis-rfc4582bis-15: (with DISCUSS and COMMENT) Thread-Index: AQHRF3IJ5JJDWYYKUEOdhULB9tmr356NOVMAgAAGM4CAANkWAA== Date: Thu, 5 Nov 2015 08:43:19 +0000 Message-ID: References: <20151105023108.17210.54132.idtracker@ietfa.amsl.com> <19C90DA9-652D-499F-8462-7EC7878307CB@packetizer.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.5.7.151005 x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.70.230.15] Content-Type: multipart/alternative; boundary="_000_D261445D5E397eckelcuciscocom_" MIME-Version: 1.0 Archived-At: Cc: "gorry@erg.abdn.ac.uk" , "bfcpbis-chairs@ietf.org" , "bfcpbis@ietf.org" , "draft-ietf-bfcpbis-rfc4582bis@ietf.org" , The IESG , Mary Barnes Subject: Re: [bfcpbis] Spencer Dawkins' Discuss on draft-ietf-bfcpbis-rfc4582bis-15: (with DISCUSS and COMMENT) X-BeenThere: bfcpbis@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: BFCPBIS working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Nov 2015 08:43:26 -0000 --_000_D261445D5E397eckelcuciscocom_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable For TCP, the use of TLS was not required by RFC 4582. For 4582bis, we do no= t require TLS in order to maintain backward compatibility with RFC 4582. For UDP, the reason for not mandating DTLS is backward compatibility with e= xisting solutions. The IMTC Role Based Video Best Practice established a se= t of recommendations for getting BFCP to work within enterprise video conf= erence deployments. As that time,draft-sandbakken-xcon-bfcp-udp defined BFC= P over UDP only. DTLS was left for future study. Today we have many impleme= ntations of BFCP over UDP, but few if any using DTLS. We need the ultimate = RFC that standardizes BFCP over UDP (and over DTLS) to allow interworking w= ith these existing deployments. Cheers, Charles From: Spencer Dawkins at IETF > Date: Thursday, November 5, 2015 at 1:46 PM To: Paul Jones > Cc: The IESG >, "gorry@erg.abdn.ac.uk" >, Mary Barnes >, "bfcpbis-chairs@ietf.org" >, "bfcpbis@ietf.org" >, "draft-iet= f-bfcpbis-rfc4582bis@ietf.org" > Subject: Re: [bfcpbis] Spencer Dawkins' Discuss on draft-ietf-bfcpbis-rfc45= 82bis-15: (with DISCUSS and COMMENT) Hi, Paul, On Thu, Nov 5, 2015 at 1:24 PM, Paul E. Jones > wrote: Spencer, I think all of the suggestions in the comments are perfectly fine and I can= accept those. With respect to the random conference ID, I think the issue = is that this ID is considered outside the protocol. This protocol just uses= this ID. If that's wrong, I would agree suggesting randomizing it would be= good. With respect to the DISCUSS point, I'm not sure what to do. Section 7 says = TLS or DTLS must be supported, but that doesn't mean it must be used. I gue= ss that's your concern. I think the security considerations section is the = right place to provide warning to those who choose not use it. And there is= warning. What more really needs to be said? I'm entirely OK with more scary language, but would prefer it added only to= security considerations. So, we both want to do the right thing. Let's talk about what that is, befo= re we spend time twiddling words. The reason why we're having this chat, is that DTLS is RECOMMENDED, not REQ= UIRED. Can you help me understand why that is? I'm seeing language in the spec that looks, to me, like it's trying to hold= the door open in case another mechanism with equivalent functionality to D= TLS becomes available (so, not MUST DTLS, because you couldn't use it). For= example, from the Security Considerations section: BFCP entities MAY use other security mechanisms as long as they provide similar security properties. Is that relevant to my question, or am I misunderstanding, and there are us= e cases where unencrypted BFCP is necessary? Thanks, Spencer Paul ________________________________ From: Spencer Dawkins > Sent: November 5, 2015 11:31:08 AM GMT+09:00 To: The IESG > Cc: gorry@erg.abdn.ac.uk, mary.ietf.barnes@gma= il.com, bfcpbis-chairs@ietf.org, bfcpbis@ietf.org, draft-i= etf-bfcpbis-rfc4582bis@ietf.org Subject: [bfcpbis] Spencer Dawkins' Discuss on draft-ietf-bfcpbis-rfc4582bi= s-15: (with DISCUSS and COMMENT) Spencer Dawkins has entered the following ballot position for draft-ietf-bfcpbis-rfc4582bis-15: Discuss When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-bfcpbis-rfc4582bis/ ________________________________ DISCUSS: ________________________________ Thanks for working through my Discuss and Comments on -13. I'm mostly good (at the Discuss level), but have one remaining concern! , on section 14. Security Considerations BFCP uses TLS/DTLS to provide mutual authentication between clients and servers. TLS/DTLS also provides replay and integrity protection and confidentiality. It is RECOMMENDED that TLS/DTLS with an encryption algorithm according to Section 7 always be used. In cases where signaling/control traffic is properly protected, as described in Section 9 it is REQUIRED to use a mandated encryption algorithm. BFCP entities MAY use other security mechanisms as long as they provide similar security properties. If I'm reading this text correctly (please correct me if I'm misunderstanding), it is still allowed to run BFCP over TCP/UDP without TLS/DTLS. If you run a protocol over TCP without TLS, you're still vulnerable to on-path attackers, but off-path attackers have to insert attack packets with sequence numbers that are within t! he current window. That's not impossible, but it's not easy. So, I'm not happy that TLS isn't required when you run BFCP over TCP, but OK, fine. If you run a protocol over UDP without DTLS, off-path attackers don't have this constraint, so inserting attack packets off-path is much easier. That makes BFCP much more vulnerable to attack over UDP than it was over TCP. Is that really OK? That seems quite odd to me, when said without a clear warning that if you do not use DTLS (or equivalent) security mechanisms the protocol is vulnerable to various attacks. I=92d have preferred section 7 to have said =93SHOULD use TLS or DTLS=94 an= d then have gone on to explain - =93reasons for not using DTLS include ... but when TLS or DTLS is not used the protocol becomes vulnerable to security attacks (e.g. ...).=94 ________________________________ COMMENT: ________________________________ I have a couple of Comments on ! new text: 6.2.2. ICMP Error Handling ICMP is not used with unreliable transports due to risks asociated with off-path attacks. Any ICMP messages received over an unreliable transport MUST be ignored. ICMP is inherently unreliable - and is itself a control transport, rather than sent over another transport. I think I know what you mean, but it's not what the text says. Perhaps you mean ICMP is not usable when BFCP is running over an unreliable transport due to risks associated with off-path attacks. Any ICMP messages associated with BFCP running over an unreliable transport MUST be ignored. The new text says: =93predictable conference identifiers in conjunction with a non-secure transport protocol makes BFCP more susceptible to forged request and response messages. See the Security Considerations section regarding the recommendation to use a secure transport.)=94 - This text could be improved a little by changing this to: =93 predictable conference identifiers in conjunction with a non-secure transport protocol makes BFCP susceptible to off path data injection attacks, where an attacker can forge a request or response message.=94 However, this falls short of saying you should randomize the conference ID. The current text could be OK if it is hard or impossible to randomize for some reason, but I=92d have thought if it was possible this should be RECOMMENDED either as the default method, or at least as a more secure alternative for an unreliable transport. Cleaning up the last few Comments on -13: I'm still working through the conflation of transports and version numbers. It's getting better, but the current text says: =93If a floor control server receives a messag! e with an unsupported version field value, the server MUST indicate it does not support the protocol version by sending an Error message with parameter value 12 (Unsupported Version).=93 I=92d have expected this error message to also have been returned if the transport did not match. Would it be correct if the text said: =93If a floor control server receives a message with an unsupported version field value or a message with a version number that is not permitted with the transport over which it was received, the server MUST indicate it does not support the protocol version by sending an Error message with parameter value 12 (Unsupported Version).=93 ________________________________ bfcpbis mailing list bfcpbis@ietf.org https://www.ietf.org/mailman/listinfo/bfcpbis --_000_D261445D5E397eckelcuciscocom_ Content-Type: text/html; charset="Windows-1252" Content-ID: Content-Transfer-Encoding: quoted-printable
For TCP, the use of TLS was not required by RFC 4582. For 4582bis, we = do not require TLS in order to maintain backward compatibility with RFC 458= 2. 
For UDP, the reason for not mandating DTLS is backward compatibility w= ith existing solutions. The IMTC Role Based Video Best Practice established= a set of recommendations for getting BFCP to work  within enterprise = video conference deployments. As that time,draft-sandbakken-xcon-bfcp-udp defined BFCP over UDP only. DTLS = was left for future study. Today we have many implementations of BFCP over = UDP, but few if any using DTLS. We need the ultimate RFC that standardizes = BFCP over UDP (and over DTLS) to allow interworking with these existing deployments.

Cheers,
Charles

From: Spencer Dawkins at IETF <<= a href=3D"mailto:spencerdawkins.ietf@gmail.com">spencerdawkins.ietf@gmail.c= om>
Date: Thursday, November 5, 2015 at= 1:46 PM
To: Paul Jones <paulej@packetizer.com>
Cc: The IESG <iesg@ietf.org>, "gorry@erg.abdn.ac.uk" <gorry@erg.abdn.ac.uk>, Mary Barnes <mary.ietf.barnes@gmail.com>, "bfcpbis-chairs@ietf.org" <bfcpbis-chairs@ietf= .org>, "bfcpbis@ietf.org" <bfcpbis@ietf.org>, "draft-ietf= -bfcpbis-rfc4582bis@ietf.org" <draft-ietf-bfcpbis-rfc4582bis@ietf.org> Subject: Re: [bfcpbis] Spencer Dawk= ins' Discuss on draft-ietf-bfcpbis-rfc4582bis-15: (with DISCUSS and COMMENT= )

Hi, Paul,

On Thu, Nov 5, 2015 at 1:24 PM, Paul E. Jones <paulej@packe= tizer.com> wrote:
Spencer,

I think all of the suggestions in the comments are perfectly fine and I can= accept those. With respect to the random conference ID, I think the issue = is that this ID is considered outside the protocol. This protocol just uses= this ID. If that's wrong, I would agree suggesting randomizing it would be good.

With respect to the DISCUSS point, I'm not sure what to do. Section 7 says = TLS or DTLS must be supported, but that doesn't mean it must be used. I gue= ss that's your concern. I think the security considerations section is the = right place to provide warning to those who choose not use it. And there is warning. What more really needs = to be said?

I'm entirely OK with more scary language, but would prefer it added only to= security considerations.

So, we both want to do the right thing. Let's talk about what that is,= before we spend time twiddling words.

The reason why we're having this chat, is that DTLS is RECOMMENDED, no= t REQUIRED. Can you help me understand why that is? 

I'm seeing language in the spec that looks, to me, like it's trying to= hold the door open in case another mechanism with equivalent functionality= to DTLS becomes available (so, not MUST DTLS, because you couldn't use it)= . For example, from the Security Considerations section:

   BFCP entities MAY use other security mechanisms as =
long as they
   provide similar security properties.

Is that relevant to my question, or am I misunderstanding, and there a= re use cases where unencrypted BFCP is necessary?

Thanks,

Spencer
 
Paul

From: Spencer Dawkins <spencerdawkins.ietf@gmail.com>
Sent: November 5, 2015 11:31:08 AM GMT+09:00
To: The IESG <= iesg@ietf.org>
Cc: gorry@= erg.abdn.ac.uk, mary.ietf.b= arnes@gmail.com, bfcpbis-chairs= @ietf.org, bfcpbis@ietf.org,= draft-ietf-bfcpbis-rfc4582bis@ietf.org
Subject: [bfcpbis] Spencer Dawkins' Discuss on draft-ietf-bfcpbis-rf= c4582bis-15: (with DISCUSS and COMMENT)

Spencer Dawkins has entered the following ballot posi=
tion for
draft-ietf-bfcpbis-rfc4582bis-15: Discuss

When respondin=
g, 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 par=
agraph, however.)


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


The document, along with oth=
er ballot positions, can be found here:
https://datatr=
acker.ietf.org/doc/draft-ietf-bfcpbis-rfc4582bis/




DISCUSS:


Thanks for working throug=
h my Discuss and Comments on -13. I'm mostly
good (at the Discuss=
 level), but have one remaining concern!
 , on
section
14.  Security Considerations

   BFCP use=
s TLS/DTLS to provide mutual authentication between clients
   and serve=
rs.  TLS/DTLS also provides replay and integrity protection
   and confi=
dentiality.  It is RECOMMENDED that TLS/DTLS with an
   encryption algor=
ithm according to Section 7 always be used.  In cases
   where signaling=
/control traffic is properly protected, as described
   in Section 9 it =
is REQUIRED to use a mandated encryption algorithm.
   BFCP entities MAY=
 use other security mechanisms as long as they
   provide similar securi=
ty properties.
   
If I'm reading this text correctly (please correct=
 me if I'm
misunderstanding), it is still allowed to run BFCP over TCP/U=
DP without
TLS/DTLS. 

If you run a protocol over TCP without TLS,=
 you're still vulnerable to
on-path attackers, but off-path attackers ha=
ve to insert attack packets
with sequence numbers that are within=
 t!
 he
current window. That's not
impossible, but it's not eas=
y. So, I'm not happy that TLS isn't required
when you run BFCP over TCP,=
 but OK, fine.

If you run a protocol over UDP without DTLS, off-path=
 attackers don't
have this constraint, so inserting attack packets off-p=
ath is much
easier. That makes BFCP much more vulnerable to attack over =
UDP than it
was over TCP. 

Is that really OK? That seems quite od=
d to me, when said without a clear
warning that if you do not use DTLS (=
or equivalent) security mechanisms
the protocol is vulnerable to various=
 attacks.

I=92d have preferred section 7 to have said =93SHOULD use =
TLS or DTLS=94 and
then have gone on to explain - =93reasons for not usi=
ng DTLS include ...
but when TLS or DTLS is not used the protocol become=
s vulnerable to
security attacks (e.g. ...).=94


COMMENT:



I have a couple of Comments on !
 new
text:


6.2.2.  ICMP Error Handling 
   
=
   ICMP is not used with unreliable transports due to risks asociated 
 =
  with off-path attacks.  Any ICMP messages received over an
unreliable =

   transport MUST be ignored.
   
ICMP is inherently unreliable -=
 and is itself a control transport, rather
than sent over another transp=
ort. I think I know what you mean, but it's
not what the text says. Perh=
aps you mean

   ICMP is not usable when BFCP is running over an unre=
liable transport
due 
   to risks associated with off-path attacks.  =
Any ICMP messages
associated 
   with BFCP running over an unreliable=
 transport MUST be ignored.
   
The new text says:

=93predicta=
ble conference identifiers in conjunction with a non-secure
transport pr=
otocol makes BFCP more susceptible to forged request and
response messag=
es.  See the Security Considerations section regarding
the
recommendation to use a secure transport.)=94

- This text  could be =
improved a little by changing this to:

=93 predictable conference id=
entifiers in conjunction with a non-secure
transport protocol makes BFCP=
 susceptible to off path data injection
attacks, where an attacker can f=
orge a request or response message.=94

However, this falls short of =
saying you should randomize the conference
ID.

The current text c=
ould be OK if it is hard or impossible to randomize for
some reason, but=
 I=92d have thought if it was possible this should be
RECOMMENDED either=
 as the default method, or at least as a more secure
alternative for an =
unreliable transport.
   
Cleaning up the last few Comments on -13:
I'm still working through the conflation of transports and versionnumbers. It's getting better, but the current text says:

   =93If a=
 floor control server receives a
   messag!
 e with
an unsupported version field value, the server MUST
   =
indicate it does not support the protocol version by sending an Error
  =
 message with parameter value 12 (Unsupported Version).=93

I=92d hav=
e expected this error message to also have been returned if the
transpor=
t did not match.

Would it be correct if the text said:

  =93I=
f a floor control server receives a
   message with an unsupported versi=
on field value
   or a message with a version number that is not permitt=
ed
   with the transport over which it was received,  the server MUST   indicate it does not support the protocol version by sending an Error   message with parameter value 12 (Unsupported Version).=93


<=
/span>

bfcpbis mailing list
bfcpbis@ietf.org
https://www.ietf.org/mailman/list=
info/bfcpbis

 --_000_D261445D5E397eckelcuciscocom_-- From nobody Thu Nov 5 06:21:01 2015 Return-Path: X-Original-To: bfcpbis@ietfa.amsl.com Delivered-To: bfcpbis@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9CEB81B2D7C; Thu, 5 Nov 2015 06:20:46 -0800 (PST) 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 SO73DmZJujFb; Thu, 5 Nov 2015 06:20:44 -0800 (PST) Received: from mail-yk0-x233.google.com (mail-yk0-x233.google.com [IPv6:2607:f8b0:4002:c07::233]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 730351B2D53; Thu, 5 Nov 2015 06:20:42 -0800 (PST) Received: by ykdr3 with SMTP id r3so132564529ykd.1; Thu, 05 Nov 2015 06:20:41 -0800 (PST) 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=3L6ai6Vz1XCJ+opoJBIUPfsPu9d8UWufbIbRvgm6E80=; b=DZeGZLfop47A2XRfpygOPXKItz501nJm5q+XTpms0LctCXoc1Vq7lSum+zUnzdyRV5 XsJj83birLVchYgpjg2ifmBt44nva8Vwph3SHq7ZO8CusAPWTgMIlEZcZ2rIpPD6xhHK GE0AzN893+z5sjn/epJ9Rj43Vso1w+FCh/7aWoNfpLCKhC2AAcmvuTC5uW75em0BCLxl lgtQz8DCEQD9geiwy6/Dduv+M0VOC6owpxOWKv4N/pfZkAw1z8InBfpH2GedXQWNsjEK rIHZKX2C58f5DkyFcDVThYirekgMNhl4hdPBQSdnSIAWajmHt6j/NZXL/rplX9zjID+M GU+A== MIME-Version: 1.0 X-Received: by 10.31.8.69 with SMTP id 66mr7223072vki.82.1446733241432; Thu, 05 Nov 2015 06:20:41 -0800 (PST) Received: by 10.31.149.79 with HTTP; Thu, 5 Nov 2015 06:20:41 -0800 (PST) In-Reply-To: References: <20151105023108.17210.54132.idtracker@ietfa.amsl.com> <19C90DA9-652D-499F-8462-7EC7878307CB@packetizer.com> Date: Thu, 5 Nov 2015 23:20:41 +0900 Message-ID: From: Spencer Dawkins at IETF To: "Charles Eckel (eckelcu)" Content-Type: multipart/alternative; boundary=001a11440bccf0c10f0523cbd4c5 Archived-At: Cc: "gorry@erg.abdn.ac.uk" , "bfcpbis-chairs@ietf.org" , "bfcpbis@ietf.org" , "draft-ietf-bfcpbis-rfc4582bis@ietf.org" , "Paul E. Jones" , The IESG , Mary Barnes Subject: Re: [bfcpbis] Spencer Dawkins' Discuss on draft-ietf-bfcpbis-rfc4582bis-15: (with DISCUSS and COMMENT) X-BeenThere: bfcpbis@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: BFCPBIS working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Nov 2015 14:20:46 -0000 --001a11440bccf0c10f0523cbd4c5 Content-Type: text/plain; charset=UTF-8 Hi, Charles, On Thu, Nov 5, 2015 at 5:43 PM, Charles Eckel (eckelcu) wrote: > For TCP, the use of TLS was not required by RFC 4582. For 4582bis, we do > not require TLS in order to maintain backward compatibility with RFC 4582. > Got it. I'm holding my nose on this one, based on backward compatibility, and given the degree of difficulty in splicing attack packets into the TCP sequence numbering space if you're off-path. I'm not thrilled, but someone else needs to decide when threats reach the level where making that incompatible change is necessary - and that might not be the right thing to do today. > For UDP, the reason for not mandating DTLS is backward compatibility with > existing solutions. The IMTC Role Based Video Best Practice established a > set of recommendations for getting BFCP to work within enterprise video > conference deployments. As that time,draft-sandbakken-xcon-bfcp-udp defined > BFCP over UDP only. DTLS was left for future study. Today we have many > implementations of BFCP over UDP, but few if any using DTLS. We need the > ultimate RFC that standardizes BFCP over UDP (and over DTLS) to allow > interworking with these existing deployments. > OK, I'm not the Protocol Security Police, so, fine, but it seems like the draft could be clearer about this, and what you said in your answer would be really helpful in the document. If the text said something like "DTLS is REQUIRED unless you are interworking with a pre-standardization deployment that is already insecure, in which case you're not making things worse by running without transport-level security", that would capture my concern and reflect what you're saying, unless I'm missing something. Thanks to you and Paul for the speedy response on the evening of Bits and Bites! Spencer --001a11440bccf0c10f0523cbd4c5 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hi, Charles,

On Thu, Nov 5, 2015 at 5:43 PM, Charles Eckel (eckelcu) <eckel= cu@cisco.com> wrote:
For TCP, the use of TLS was not required by RFC 4582. For 4582bis, we = do not require TLS in order to maintain backward compatibility with RFC 458= 2.

Got it. I'm holding my = nose on this one, based on backward compatibility, and given the degree of = difficulty in splicing attack packets into the TCP sequence numbering space= if you're off-path. I'm not thrilled, but someone else needs to de= cide when threats reach the level where making that incompatible change is = necessary - and that might not be the right thing to do today.
= =C2=A0
For= UDP, the reason for not mandating DTLS is backward compatibility with exis= ting solutions. The IMTC Role Based Video Best Practice established a set o= f recommendations for getting BFCP to work =C2=A0within enterprise video co= nference deployments. As that time,draft-sandbakken-xcon-bfcp-udp=C2=A0defined BFCP over UDP only. DTLS = was left for future study. Today we have many implementations of BFCP over = UDP, but few if any using DTLS. We need the ultimate RFC that standardizes = BFCP over UDP (and over DTLS) to allow interworking with these existing deployments.

OK, I'm not the Protocol Security Police, so, fine, but= it seems like the draft could be clearer about this, and what you said in = your answer would be really helpful in the document.=C2=A0

If the text said something like "DTLS is REQUIRED unless you = are interworking with a pre-standardization deployment that is already inse= cure, in which case you're not making things worse by running without t= ransport-level security", that would capture my concern and reflect wh= at you're saying, unless I'm missing something.

Thanks to you and Paul for the speedy response on the evening of Bits= and Bites!

Spencer
--001a11440bccf0c10f0523cbd4c5-- From nobody Thu Nov 5 14:12:34 2015 Return-Path: X-Original-To: bfcpbis@ietfa.amsl.com Delivered-To: bfcpbis@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C4B4B1B3C3E for ; Thu, 5 Nov 2015 14:12:30 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.699 X-Spam-Level: X-Spam-Status: No, score=-2.699 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, MIME_QP_LONG_LINE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=unavailable 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 8Goclfnz9xIs for ; Thu, 5 Nov 2015 14:12:29 -0800 (PST) Received: from out3-smtp.messagingengine.com (out3-smtp.messagingengine.com [66.111.4.27]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9A47C1B3C54 for ; Thu, 5 Nov 2015 14:12:23 -0800 (PST) Received: from compute3.internal (compute3.nyi.internal [10.202.2.43]) by mailout.nyi.internal (Postfix) with ESMTP id D69C7208B4 for ; Thu, 5 Nov 2015 17:06:35 -0500 (EST) Received: from frontend1 ([10.202.2.160]) by compute3.internal (MEProxy); Thu, 05 Nov 2015 17:06:35 -0500 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=cooperw.in; h=cc :content-transfer-encoding:content-type:date:from:in-reply-to :message-id:mime-version:references:subject:to:x-sasl-enc :x-sasl-enc; s=mesmtp; bh=mqHkCm2tER9gZj+jdxVmKKZ3Qvk=; b=PX3jnX Np8xSR4Zgezj6BGXEUi11dJeUPrESdrm+bq7qEuRCrn3grFUTVKs08ycvPwfjHf4 rq9a1BKKP+qC+vEpVWoxZCr1jagq2c5FFcHXHFQ5+pUtmjRUw/5zEh52qhPTDAJq sipZoVfkt46m4z7dHYtduB/qXxtdQ3dpSwrn4= DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d= messagingengine.com; h=cc:content-transfer-encoding:content-type :date:from:in-reply-to:message-id:mime-version:references :subject:to:x-sasl-enc:x-sasl-enc; s=smtpout; bh=mqHkCm2tER9gZj+ jdxVmKKZ3Qvk=; b=SsVuox0+Wx6Hak5757ooi+kO9QDa6UVt89FjFS4Zo4A5KjR 15mebGE28hmywHILJ9ECw98W3rGriynmSK4UNwubzQ6CA3MT9gEqaSTQD3Y9cpSB SdXnhVfzBwxMJPaZ6KbEBmNuKnDgDto6CJNoiuH9weZmwsfVdlhgC6+1b0hs= X-Sasl-enc: EfuqTq1DXtuHfowx6z5PgBk77W/ecZQcrvv/cXQ6JIWv 1446761195 Received: from [133.93.84.252] (dhcp-84-252.meeting.ietf94.jp [133.93.84.252]) by mail.messagingengine.com (Postfix) with ESMTPA id 0C135C016D5; Thu, 5 Nov 2015 17:06:35 -0500 (EST) References: <20151105023108.17210.54132.idtracker@ietfa.amsl.com> <19C90DA9-652D-499F-8462-7EC7878307CB@packetizer.com> Mime-Version: 1.0 (1.0) In-Reply-To: Content-Type: multipart/alternative; boundary=Apple-Mail-20392379-9182-494D-962A-9FD677DC435F Content-Transfer-Encoding: 7bit Message-Id: <5D0066E2-6BD9-4ED8-A37D-CE83118E099E@cooperw.in> X-Mailer: iPhone Mail (12F70) From: Alissa Cooper Date: Fri, 6 Nov 2015 07:06:31 +0900 To: Spencer Dawkins at IETF Archived-At: Cc: "gorry@erg.abdn.ac.uk" , "bfcpbis-chairs@ietf.org" , "bfcpbis@ietf.org" , "Charles Eckel \(eckelcu\)" , "draft-ietf-bfcpbis-rfc4582bis@ietf.org" , "Paul E. Jones" , The IESG , Mary Barnes Subject: Re: [bfcpbis] Spencer Dawkins' Discuss on draft-ietf-bfcpbis-rfc4582bis-15: (with DISCUSS and COMMENT) X-BeenThere: bfcpbis@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: BFCPBIS working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Nov 2015 22:12:30 -0000 --Apple-Mail-20392379-9182-494D-962A-9FD677DC435F Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Hi Spencer, > On Nov 5, 2015, at 11:20 PM, Spencer Dawkins at IETF wrote: >=20 > Hi, Charles, >=20 >> On Thu, Nov 5, 2015 at 5:43 PM, Charles Eckel (eckelcu) wrote: >> For TCP, the use of TLS was not required by RFC 4582. For 4582bis, we do n= ot require TLS in order to maintain backward compatibility with RFC 4582. >=20 > Got it. I'm holding my nose on this one, based on backward compatibility, a= nd given the degree of difficulty in splicing attack packets into the TCP se= quence numbering space if you're off-path. I'm not thrilled, but someone els= e needs to decide when threats reach the level where making that incompatibl= e change is necessary - and that might not be the right thing to do today. > =20 >> For UDP, the reason for not mandating DTLS is backward compatibility with= existing solutions. The IMTC Role Based Video Best Practice established a s= et of recommendations for getting BFCP to work within enterprise video conf= erence deployments. As that time,draft-sandbakken-xcon-bfcp-udp defined BFCP= over UDP only. DTLS was left for future study. Today we have many implement= ations of BFCP over UDP, but few if any using DTLS. We need the ultimate RFC= that standardizes BFCP over UDP (and over DTLS) to allow interworking with t= hese existing deployments. >=20 > OK, I'm not the Protocol Security Police, so, fine, but it seems like the d= raft could be clearer about this, and what you said in your answer would be r= eally helpful in the document.=20 >=20 > If the text said something like "DTLS is REQUIRED unless you are interwork= ing with a pre-standardization deployment that is already insecure, "REQUIRED unless" strikes me as a faulty construction. That case is what REC= OMMENDED is for, when there is a known exception to the requirement. Alissa > in which case you're not making things worse by running without transport-= level security", that would capture my concern and reflect what you're sayin= g, unless I'm missing something. >=20 > Thanks to you and Paul for the speedy response on the evening of Bits and B= ites! >=20 > Spencer > _______________________________________________ > bfcpbis mailing list > bfcpbis@ietf.org > https://www.ietf.org/mailman/listinfo/bfcpbis --Apple-Mail-20392379-9182-494D-962A-9FD677DC435F Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable
Hi Spencer,



= On Nov 5, 2015, at 11:20 PM, Spencer Dawkins at IETF <spencerdawkins.ietf@gmail.com> wrote:
Hi, Charles,
On Thu, Nov 5, 2015 at= 5:43 PM, Charles Eckel (eckelcu) <eckelcu@cisco.com> wrote:
For TCP, the use of TLS was not required by RFC 4582. For 4582bis, we d= o not require TLS in order to maintain backward compatibility with RFC 4582.=

Got it. I'm holding my nose on= this one, based on backward compatibility, and given the degree of difficul= ty in splicing attack packets into the TCP sequence numbering space if you'r= e off-path. I'm not thrilled, but someone else needs to decide when threats r= each the level where making that incompatible change is necessary - and that= might not be the right thing to do today.
 
For UDP, the reason for not m= andating DTLS is backward compatibility with existing solutions. The IMTC Ro= le Based Video Best Practice established a set of recommendations for gettin= g BFCP to work  within enterprise video conference deployments. As that= time,draft-sandbakken-xcon-bfcp-udp defined BFCP over UDP only. DTLS w= as left for future study. Today we have many implementations of BFCP over UD= P, but few if any using DTLS. We need the ultimate RFC that standardizes BFC= P over UDP (and over DTLS) to allow interworking with these existing deployments.
=
OK, I'm not the Protocol Security Police, so, fine, but it se= ems like the draft could be clearer about this, and what you said in your an= swer would be really helpful in the document. 

If the text said something like "DTLS is REQUIRED unless you are interworki= ng with a pre-standardization deployment that is already insecure,

"REQUIRED unless" stri= kes me as a faulty construction. That case is what RECOMMENDED is for, when t= here is a known exception to the requirement.

Aliss= a

in which case you're not making th= ings worse by running without transport-level security", that would capture m= y concern and reflect what you're saying, unless I'm missing something.

Thanks to you and Paul for the speedy response on the e= vening of Bits and Bites!

Spencer
=
____________________= ___________________________
bfcpbis mailing list
<= span>bfcpbis@ietf.org
https://www.ietf= .org/mailman/listinfo/bfcpbis
= --Apple-Mail-20392379-9182-494D-962A-9FD677DC435F-- From nobody Thu Nov 5 14:23:24 2015 Return-Path: X-Original-To: bfcpbis@ietfa.amsl.com Delivered-To: bfcpbis@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F3FD11B3C6B; Thu, 5 Nov 2015 14:23:19 -0800 (PST) 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 81GZSUuhv8qk; Thu, 5 Nov 2015 14:23:17 -0800 (PST) Received: from mail-yk0-x22b.google.com (mail-yk0-x22b.google.com [IPv6:2607:f8b0:4002:c07::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 B84D81B3C69; Thu, 5 Nov 2015 14:23:17 -0800 (PST) Received: by ykek133 with SMTP id k133so158292868yke.2; Thu, 05 Nov 2015 14:23:17 -0800 (PST) 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=cmRrHlMFoMfJbA5PCZWJKmCy8qU/QJQTusxze6oOBUo=; b=MfonzU97TLsZCa/xR71y/27BZCdEiN2Pouc5tub5DjPbXz1sxgJF+c/rIfFfJ/w5kE eL9/1rIsDI/fXRMDvFs+9XJ8+jcsLYQtbFcmIZpj8NnFvv7xoWXzGr3HiU++/CchBjZT ZjqqFoEVmGYRo4Wm2DpwaxOwcIUEq57MfGiA56OxjBrD3l/qU7O7XK1L0IrPCRPBBIqY 7zxZFc/cHQhvAAvEl+7C9NCSvVPNwUKvtgXOxHQYlMDbU0OBU+iy5F/9s1z13uUjWDkb dziBOuavtGmVLNDMsFk2iWN9oyHre6+/85p0gth6QOLVZ6g+qWYDXsI/ugwu+s11ki0Y 13Ig== MIME-Version: 1.0 X-Received: by 10.31.49.22 with SMTP id x22mr9263475vkx.60.1446762196982; Thu, 05 Nov 2015 14:23:16 -0800 (PST) Received: by 10.31.149.79 with HTTP; Thu, 5 Nov 2015 14:23:16 -0800 (PST) Received: by 10.31.149.79 with HTTP; Thu, 5 Nov 2015 14:23:16 -0800 (PST) In-Reply-To: <5D0066E2-6BD9-4ED8-A37D-CE83118E099E@cooperw.in> References: <20151105023108.17210.54132.idtracker@ietfa.amsl.com> <19C90DA9-652D-499F-8462-7EC7878307CB@packetizer.com> <5D0066E2-6BD9-4ED8-A37D-CE83118E099E@cooperw.in> Date: Fri, 6 Nov 2015 07:23:16 +0900 Message-ID: From: Spencer Dawkins at IETF To: Alissa Cooper Content-Type: multipart/alternative; boundary=001a11440790d360ff0523d292a7 Archived-At: Cc: "gorry@erg.abdn.ac.uk" , bfcpbis-chairs@ietf.org, "bfcpbis@ietf.org" , "Charles Eckel \(eckelcu\)" , "draft-ietf-bfcpbis-rfc4582bis@ietf.org" , "Paul E. Jones" , iesg@ietf.org, Mary Barnes Subject: Re: [bfcpbis] Spencer Dawkins' Discuss on draft-ietf-bfcpbis-rfc4582bis-15: (with DISCUSS and COMMENT) X-BeenThere: bfcpbis@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: BFCPBIS working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Nov 2015 22:23:20 -0000 --001a11440790d360ff0523d292a7 Content-Type: text/plain; charset=UTF-8 Hi, Alissa, On Nov 6, 2015 7:06 AM, "Alissa Cooper" wrote: > > Hi Spencer, > > > > On Nov 5, 2015, at 11:20 PM, Spencer Dawkins at IETF < spencerdawkins.ietf@gmail.com> wrote: > >> Hi, Charles, >> >> On Thu, Nov 5, 2015 at 5:43 PM, Charles Eckel (eckelcu) < eckelcu@cisco.com> wrote: >>> >>> For TCP, the use of TLS was not required by RFC 4582. For 4582bis, we do not require TLS in order to maintain backward compatibility with RFC 4582. >> >> >> Got it. I'm holding my nose on this one, based on backward compatibility, and given the degree of difficulty in splicing attack packets into the TCP sequence numbering space if you're off-path. I'm not thrilled, but someone else needs to decide when threats reach the level where making that incompatible change is necessary - and that might not be the right thing to do today. >> >>> >>> For UDP, the reason for not mandating DTLS is backward compatibility with existing solutions. The IMTC Role Based Video Best Practice established a set of recommendations for getting BFCP to work within enterprise video conference deployments. As that time,draft-sandbakken-xcon-bfcp-udp defined BFCP over UDP only. DTLS was left for future study. Today we have many implementations of BFCP over UDP, but few if any using DTLS. We need the ultimate RFC that standardizes BFCP over UDP (and over DTLS) to allow interworking with these existing deployments. >> >> >> OK, I'm not the Protocol Security Police, so, fine, but it seems like the draft could be clearer about this, and what you said in your answer would be really helpful in the document. >> >> If the text said something like "DTLS is REQUIRED unless you are interworking with a pre-standardization deployment that is already insecure, > > > "REQUIRED unless" strikes me as a faulty construction. That case is what RECOMMENDED is for, when there is a known exception to the requirement. That usage is certainly more common in some parts of the IETF than others, but it does get used. But ignoring that. Do you think "RECOMMENDED unless you are interworking with a pre-standardization deployment that is already insecure" is tight enough? The reason I'm asking, is that offpath attacks on UDP-based protocols are a lot easier than TCP-based protocols, and if the IETF is going to publish a proposed standard with a known deficiency to accommodate pre-standardization deployments, I'd prefer that the guidance about using that accommodation be as clear as possible. Thanks, Spencer > Alissa > >> in which case you're not making things worse by running without transport-level security", that would capture my concern and reflect what you're saying, unless I'm missing something. >> >> Thanks to you and Paul for the speedy response on the evening of Bits and Bites! >> >> Spencer >> >> _______________________________________________ >> >> bfcpbis mailing list >> bfcpbis@ietf.org >> https://www.ietf.org/mailman/listinfo/bfcpbis --001a11440790d360ff0523d292a7 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable

Hi, Alissa,

On Nov 6, 2015 7:06 AM, "Alissa Cooper" <alissa@cooperw.in> wrote:
>
> Hi Spencer,
>
>
>
> On Nov 5, 2015, at 11:20 PM, Spencer Dawkins at IETF <spencerdawkins.ietf@gmail.com> w= rote:
>
>> Hi, Charles,
>>
>> On Thu, Nov 5, 2015 at 5:43 PM, Charles Eckel (eckelcu) <eckelcu@cisco.com> wrote:
>>>
>>> For TCP, the use of TLS was not required by RFC 4582. For 4582= bis, we do not require TLS in order to maintain backward compatibility with= RFC 4582.
>>
>>
>> Got it. I'm holding my nose on this one, based on backward com= patibility, and given the degree of difficulty in splicing attack packets i= nto the TCP sequence numbering space if you're off-path. I'm not th= rilled, but someone else needs to decide when threats reach the level where= making that incompatible change is necessary - and that might not be the r= ight thing to do today.
>> =C2=A0
>>>
>>> For UDP, the reason for not mandating DTLS is backward compati= bility with existing solutions. The IMTC Role Based Video Best Practice est= ablished a set of recommendations for getting BFCP to work =C2=A0within ent= erprise video conference deployments. As that time,draft-sandbakken-xcon-bf= cp-udp=C2=A0defined BFCP over UDP only. DTLS was left for future study. Tod= ay we have many implementations of BFCP over UDP, but few if any using DTLS= . We need the ultimate RFC that standardizes BFCP over UDP (and over DTLS) = to allow interworking with these existing deployments.
>>
>>
>> OK, I'm not the Protocol Security Police, so, fine, but it see= ms like the draft could be clearer about this, and what you said in your an= swer would be really helpful in the document.=C2=A0
>>
>> If the text said something like "DTLS is REQUIRED unless you = are interworking with a pre-standardization deployment that is already inse= cure,
>
>
> "REQUIRED unless" strikes me as a faulty construction. That = case is what RECOMMENDED is for, when there is a known exception to the req= uirement.

That usage is certainly more common in some parts of the IET= F than others, but it does get used. But ignoring that.

Do you think "RECOMMENDED unless you are interworking w= ith a pre-standardization deployment that is already insecure" is tigh= t enough?

The reason I'm asking, is that offpath attacks on UDP-ba= sed protocols are a lot easier than TCP-based protocols, and if the IETF is= going to publish a proposed standard with a known deficiency to accommodat= e pre-standardization deployments, I'd prefer that the guidance about u= sing that accommodation be as clear as possible.

Thanks,

Spencer

> Alissa
>
>> in which case you're not making things worse by running withou= t transport-level security", that would capture my concern and reflect= what you're saying, unless I'm missing something.
>>
>> Thanks to you and Paul for the speedy response on the evening of B= its and Bites!
>>
>> Spencer
>>
>> _______________________________________________
>>
>> bfcpbis mailing list
>> bfcpbis@ietf.org
>> https://= www.ietf.org/mailman/listinfo/bfcpbis

--001a11440790d360ff0523d292a7-- From nobody Thu Nov 5 14:46:29 2015 Return-Path: X-Original-To: bfcpbis@ietfa.amsl.com Delivered-To: bfcpbis@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8A5DF1B3CDC for ; Thu, 5 Nov 2015 14:46:28 -0800 (PST) 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 2dhvT-INDclS for ; Thu, 5 Nov 2015 14:46:27 -0800 (PST) Received: from resqmta-ch2-12v.sys.comcast.net (resqmta-ch2-12v.sys.comcast.net [IPv6:2001:558:fe21:29:69:252:207:44]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8A6731B3CDB for ; Thu, 5 Nov 2015 14:46:27 -0800 (PST) Received: from resomta-ch2-03v.sys.comcast.net ([69.252.207.99]) by resqmta-ch2-12v.sys.comcast.net with comcast id dymJ1r00329Cfhx01ymSvh; Thu, 05 Nov 2015 22:46:26 +0000 Received: from Paul-Kyzivats-MacBook-Pro.local ([73.218.51.154]) by resomta-ch2-03v.sys.comcast.net with comcast id dymS1r00A3KdFy101ymS1A; Thu, 05 Nov 2015 22:46:26 +0000 To: bfcpbis@ietf.org References: <20151105023108.17210.54132.idtracker@ietfa.amsl.com> <19C90DA9-652D-499F-8462-7EC7878307CB@packetizer.com> <5D0066E2-6BD9-4ED8-A37D-CE83118E099E@cooperw.in> From: Paul Kyzivat Message-ID: <563BDC41.3030006@alum.mit.edu> Date: Thu, 5 Nov 2015 17:46:25 -0500 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:38.0) Gecko/20100101 Thunderbird/38.3.0 MIME-Version: 1.0 In-Reply-To: <5D0066E2-6BD9-4ED8-A37D-CE83118E099E@cooperw.in> 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=1446763586; bh=rFMY//rOjNiEDvvRo2YIF1lZ76nHj4hlzJakb8CxYf4=; h=Received:Received:Subject:To:From:Message-ID:Date:MIME-Version: Content-Type; b=uDCvvjjcU/Q2p6UPQuufQ92Mc7v+1sVI4U8tcD2iHDY6sG7UewJC4nTLQntvKxzox XdfsaeIFwpmJtrqV1/SjUSY+JIfuorDiUw2xt1TZncisJPs5VrCTP87fD5DNGvBuMv pAw0a3VAuspy6UXK+SylK8Jh4TTNhzOuU0HN/EjRwY3EfxMyf3ijNuAkCh5ZAq7z37 OTxHAzuxAmQ9xrtjtDXJB2kLfYtGrUKffqRA4vS0peeSh6c1iiuWLP3xuOrbGXncND 46f6+lUza2gRZ+3lD/NISOZbOPTjJLpTOd9oTwfCDpy/FtVgU43C1TrxHv/v6aoKEx 3ce2WrIhccqmA== Archived-At: Subject: Re: [bfcpbis] Spencer Dawkins' Discuss on draft-ietf-bfcpbis-rfc4582bis-15: (with DISCUSS and COMMENT) X-BeenThere: bfcpbis@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: BFCPBIS working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Nov 2015 22:46:28 -0000 On 11/5/15 5:06 PM, Alissa Cooper wrote: > "REQUIRED unless" strikes me as a faulty construction. That case is what > RECOMMENDED is for, when there is a known exception to the requirement. I don't think I agree. I think "REQUIRED unless" is quite precise. Using "RECOMMENDED unless" says to me that in cases where the the "unless" doesn't apply then RECOMMENDED applies and hence can still be violated for cause. Historically, SHOULD/RECOMMENDED has been used in a rather casual way, in the spirit of "we trust you to be responsible about this". And it hasn't worked out well. So now we at least *say* that you ought not use SHOULD/RECOMMENDED without being explicit about the conditions when it is acceptable to violate it. At that point, the distinction between MUST and SHOULD goes away. I think the following constructions are most clear: - You MUST do foobar except when blah blah blah. - You are REQUIRED to do foobar except when blah blah blah. - You SHOULD do foobar. The only acceptable situation to not do foobar is blah blah blah. - It is RECOMMENDED that you do foobar. The only acceptable situation to not do foobar is blah blah blah. I have had implementers tell me that when they get an assignment to implement a spec, their management tells them to only do the MUSTs, because that is all that is required to satisfy the checkoff! Thanks, Paul From nobody Thu Nov 5 15:32:54 2015 Return-Path: X-Original-To: bfcpbis@ietfa.amsl.com Delivered-To: bfcpbis@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4C9B41B35EC for ; Thu, 5 Nov 2015 15:32:53 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.701 X-Spam-Level: X-Spam-Status: No, score=-2.701 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_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 JhmBl-7SdkHi for ; Thu, 5 Nov 2015 15:32:51 -0800 (PST) Received: from out3-smtp.messagingengine.com (out3-smtp.messagingengine.com [66.111.4.27]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 990A51B35EB for ; Thu, 5 Nov 2015 15:32:51 -0800 (PST) Received: from compute2.internal (compute2.nyi.internal [10.202.2.42]) by mailout.nyi.internal (Postfix) with ESMTP id 13A682092B for ; Thu, 5 Nov 2015 18:32:51 -0500 (EST) Received: from frontend2 ([10.202.2.161]) by compute2.internal (MEProxy); Thu, 05 Nov 2015 18:32:51 -0500 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=cooperw.in; h=cc :content-transfer-encoding:content-type:date:from:in-reply-to :message-id:mime-version:references:subject:to:x-sasl-enc :x-sasl-enc; s=mesmtp; bh=GIpZoDwxgeD9y9k6h2IXegRUaWs=; b=oAISDJ lQWm9Zpx4XemIXfoHFX1C8WRx8Pw527+qy3olZ9A0I2y75rt2j3zuakpvO6LHjB8 3/9aVlT8EjKY/yii/0jf7PIskqfuko+Afg/RoFkz30/FuqrJD6GDPCJqgFYyPFyo RbGenhlx8NOLHsH47gSnE9IpA2kcHsEmffP2E= DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d= messagingengine.com; h=cc:content-transfer-encoding:content-type :date:from:in-reply-to:message-id:mime-version:references :subject:to:x-sasl-enc:x-sasl-enc; s=smtpout; bh=GIpZoDwxgeD9y9k 6h2IXegRUaWs=; b=C1TWRwXfMx+v27UYCwzswnaO9w5kjtLjAn+tRWE2pLwpVRi /zoixEMcabzrtLD3NngpCFbiFc/98sQJdz5ofXlxmaGx0iGvZysoTpj12c9CE3V1 TItV4eL1w4KAgrF+tp8pxfncK6XRhtUWAKyum6NstD6936+wraGwasoEOQXc= X-Sasl-enc: tvyVDsHHhch4Z9nGIb7ngTl6OhQc73+aL4DvnsiXGW2y 1446766370 Received: from [10.24.51.227] (unknown [128.107.241.163]) by mail.messagingengine.com (Postfix) with ESMTPA id DD48868013E; Thu, 5 Nov 2015 18:32:49 -0500 (EST) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2104\)) From: Alissa Cooper In-Reply-To: <563BDC41.3030006@alum.mit.edu> Date: Fri, 6 Nov 2015 08:32:48 +0900 Content-Transfer-Encoding: quoted-printable Message-Id: <39A1EC5B-9245-41BC-A898-94EB5A0BE9BD@cooperw.in> References: <20151105023108.17210.54132.idtracker@ietfa.amsl.com> <19C90DA9-652D-499F-8462-7EC7878307CB@packetizer.com> <5D0066E2-6BD9-4ED8-A37D-CE83118E099E@cooperw.in> <563BDC41.3030006@alum.mit.edu> To: Paul Kyzivat X-Mailer: Apple Mail (2.2104) Archived-At: Cc: bfcpbis@ietf.org Subject: Re: [bfcpbis] Spencer Dawkins' Discuss on draft-ietf-bfcpbis-rfc4582bis-15: (with DISCUSS and COMMENT) X-BeenThere: bfcpbis@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: BFCPBIS working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Nov 2015 23:32:53 -0000 > On Nov 6, 2015, at 7:46 AM, Paul Kyzivat = wrote: >=20 > - You SHOULD do foobar. The only acceptable situation to not do foobar > is blah blah blah. > - It is RECOMMENDED that you do foobar. The only acceptable situation > to not do foobar is blah blah blah. Either of the above would be fine. SHOULD and RECOMMENDED are equivalent = according to RFC 2119. Alissa >=20 > I have had implementers tell me that when they get an assignment to = implement a spec, their management tells them to only do the MUSTs, = because that is all that is required to satisfy the checkoff! >=20 > Thanks, > Paul >=20 > _______________________________________________ > bfcpbis mailing list > bfcpbis@ietf.org > https://www.ietf.org/mailman/listinfo/bfcpbis From nobody Thu Nov 5 15:42:54 2015 Return-Path: X-Original-To: bfcpbis@ietfa.amsl.com Delivered-To: bfcpbis@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F35031B3D61; Thu, 5 Nov 2015 15:42:48 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.51 X-Spam-Level: X-Spam-Status: No, score=-14.51 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_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 uEEvP-Ic0N_T; Thu, 5 Nov 2015 15:42:46 -0800 (PST) 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 EFC581B3D64; Thu, 5 Nov 2015 15:42:45 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=16511; q=dns/txt; s=iport; t=1446766966; x=1447976566; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=VzizgRKCG1S1qyqMsUneZp+e/7anQ2vEQv/hk2PhzCA=; b=Ft8y8JNugTbYMqjv+/VAS7hToRNJX7wVAV/NAuxaLGNaMK5nY8aCXVay gRg0hm8mhf7qllRQ8gVdO9pqcAIRkv4jKwh+AEL/esB/rD7KGBCJg94On zm2QHWawOOVYl8by8p4OIWIokyLFT4jL3AZLY0TREn+ixuxcFdUActHtw 0=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: A0D3AQDu6DtW/5tdJa1egm5NU28GvgMBDYFfFwEJhSVKAoE9OBQBAQEBAQEBgQqENQEBAQMBAQEBZQYLBQsCAQgRAwECASMEByEGCxQJCAIEAQ0FG4d+AwoIDbxaDYQ+AQEBAQEBAQEBAQEBAQEBAQEBAQEBFASLUoJTgigNhDEFlkgBiAyDIoF0gVqTFoNgg3EBHwEBQoIRHRaBQHIBhBeBBwEBAQ X-IronPort-AV: E=Sophos; i="5.20,249,1444694400"; d="scan'208,217"; a="47868673" Received: from rcdn-core-4.cisco.com ([173.37.93.155]) by rcdn-iport-3.cisco.com with ESMTP; 05 Nov 2015 23:42:22 +0000 Received: from XCH-RCD-020.cisco.com (xch-rcd-020.cisco.com [173.37.102.30]) by rcdn-core-4.cisco.com (8.14.5/8.14.5) with ESMTP id tA5NgMdD026758 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Thu, 5 Nov 2015 23:42:22 GMT Received: from xch-aln-018.cisco.com (173.36.7.28) by XCH-RCD-020.cisco.com (173.37.102.30) with Microsoft SMTP Server (TLS) id 15.0.1104.5; Thu, 5 Nov 2015 17:42:21 -0600 Received: from xch-aln-018.cisco.com ([173.36.7.28]) by XCH-ALN-018.cisco.com ([173.36.7.28]) with mapi id 15.00.1104.000; Thu, 5 Nov 2015 17:42:21 -0600 From: "Charles Eckel (eckelcu)" To: Spencer Dawkins at IETF , Alissa Cooper Thread-Topic: [bfcpbis] Spencer Dawkins' Discuss on draft-ietf-bfcpbis-rfc4582bis-15: (with DISCUSS and COMMENT) Thread-Index: AQHRF3IJ5JJDWYYKUEOdhULB9tmr356NOVMAgAAGM4CAANkWAP//x2GAgACCJ4CAAASuAIAArPmA Date: Thu, 5 Nov 2015 23:42:21 +0000 Message-ID: References: <20151105023108.17210.54132.idtracker@ietfa.amsl.com> <19C90DA9-652D-499F-8462-7EC7878307CB@packetizer.com> <5D0066E2-6BD9-4ED8-A37D-CE83118E099E@cooperw.in> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.5.7.151005 x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.70.233.176] Content-Type: multipart/alternative; boundary="_000_D26216C35E457eckelcuciscocom_" MIME-Version: 1.0 Archived-At: Cc: "gorry@erg.abdn.ac.uk" , "bfcpbis-chairs@ietf.org" , "bfcpbis@ietf.org" , "draft-ietf-bfcpbis-rfc4582bis@ietf.org" , "Paul E. Jones" , "iesg@ietf.org" , Mary Barnes Subject: Re: [bfcpbis] Spencer Dawkins' Discuss on draft-ietf-bfcpbis-rfc4582bis-15: (with DISCUSS and COMMENT) X-BeenThere: bfcpbis@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: BFCPBIS working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Nov 2015 23:42:49 -0000 --_000_D26216C35E457eckelcuciscocom_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable From: Spencer Dawkins at IETF > Date: Friday, November 6, 2015 at 7:23 AM To: Alissa Cooper > Cc: "iesg@ietf.org" >, "bfcpbis-chairs@ietf.org" >, Paul Jones >, "gorry@erg.abdn.ac.uk" >, Mary B= arnes >, "dra= ft-ietf-bfcpbis-rfc4582bis@ietf.org" >, "bfcpbis@ietf.org" >, Charles Eckel > Subject: Re: [bfcpbis] Spencer Dawkins' Discuss on draft-ietf-bfcpbis-rfc45= 82bis-15: (with DISCUSS and COMMENT) Hi, Alissa, On Nov 6, 2015 7:06 AM, "Alissa Cooper" > wrote: > > Hi Spencer, > > > > On Nov 5, 2015, at 11:20 PM, Spencer Dawkins at IETF > wrote: > >> Hi, Charles, >> >> On Thu, Nov 5, 2015 at 5:43 PM, Charles Eckel (eckelcu) > wrote: >>> >>> For TCP, the use of TLS was not required by RFC 4582. For 4582bis, we d= o not require TLS in order to maintain backward compatibility with RFC 4582= . >> >> >> Got it. I'm holding my nose on this one, based on backward compatibility= , and given the degree of difficulty in splicing attack packets into the TC= P sequence numbering space if you're off-path. I'm not thrilled, but someon= e else needs to decide when threats reach the level where making that incom= patible change is necessary - and that might not be the right thing to do t= oday. >> >>> >>> For UDP, the reason for not mandating DTLS is backward compatibility wi= th existing solutions. The IMTC Role Based Video Best Practice established = a set of recommendations for getting BFCP to work within enterprise video = conference deployments. As that time,draft-sandbakken-xcon-bfcp-udp defined= BFCP over UDP only. DTLS was left for future study. Today we have many imp= lementations of BFCP over UDP, but few if any using DTLS. We need the ultim= ate RFC that standardizes BFCP over UDP (and over DTLS) to allow interworki= ng with these existing deployments. >> >> >> OK, I'm not the Protocol Security Police, so, fine, but it seems like th= e draft could be clearer about this, and what you said in your answer would= be really helpful in the document. >> >> If the text said something like "DTLS is REQUIRED unless you are interwo= rking with a pre-standardization deployment that is already insecure, > > > "REQUIRED unless" strikes me as a faulty construction. That case is what = RECOMMENDED is for, when there is a known exception to the requirement. That usage is certainly more common in some parts of the IETF than others, = but it does get used. But ignoring that. Do you think "RECOMMENDED unless you are interworking with a pre-standardiz= ation deployment that is already insecure" is tight enough? The reason I'm asking, is that offpath attacks on UDP-based protocols are a= lot easier than TCP-based protocols, and if the IETF is going to publish a= proposed standard with a known deficiency to accommodate pre-standardizati= on deployments, I'd prefer that the guidance about using that accommodation= be as clear as possible. I agree with your intent. My concern with calling out exceptions is that it= can make the existing recommendation in the draft seem weaker. How about t= his: OLD: =85 It is RECOMMENDED that TLS/DTLS with an encryption algorithm according to Section 7 always be used. In cases where signaling/control traffic is properly protected, as described in Section 9 it is REQUIRED to use a mandated encryption algorithm. BFCP entities MAY use other security mechanisms as long as they provide similar security properties. NEW =85 It is RECOMMENDED that TLS/DTLS with an encryption algorithm according to Section 7 always be used. In cases where signaling/control traffic is properly protected, as described in Section 9 it is REQUIRED to use a mandated encryption algorithm. BFCP entities MAY use other security mechanisms to interwork with legacy implementation that do not use TLS/DTLS as long as these mechanisms provide similar security properties. Cheers, Charles Thanks, Spencer > Alissa > >> in which case you're not making things worse by running without transpor= t-level security", that would capture my concern and reflect what you're sa= ying, unless I'm missing something. >> >> Thanks to you and Paul for the speedy response on the evening of Bits an= d Bites! >> >> Spencer >> >> _______________________________________________ >> >> bfcpbis mailing list >> bfcpbis@ietf.org >> https://www.ietf.org/mailman/listinfo/bfcpbis --_000_D26216C35E457eckelcuciscocom_ Content-Type: text/html; charset="Windows-1252" Content-ID: <197004D83B69B349924483F328E6309A@emea.cisco.com> Content-Transfer-Encoding: quoted-printable

From: Spencer Dawkins at IETF <<= a href=3D"mailto:spencerdawkins.ietf@gmail.com">spencerdawkins.ietf@gmail.c= om>
Date: Friday, November 6, 2015 at 7= :23 AM
To: Alissa Cooper <alissa@cooperw.in>
Cc: "iesg@ietf.org" <iesg@i= etf.org>, "bfcpbis-c= hairs@ietf.org" <bfc= pbis-chairs@ietf.org>, Paul Jones <paulej@packetizer.= com>, "gorry@erg.abdn.a= c.uk" <gorry@erg.abdn.a= c.uk>, Mary Barnes <mary.ietf.barnes@gmail.com>, "draft-ietf= -bfcpbis-rfc4582bis@ietf.org" <draft-ietf-bfcpbis-rfc4582bis@ietf.org>, &= quot;bfcpbis@ietf.org" <bfcpbis@ietf.org>, Charles = Eckel <eckelcu@cisco.com> Subject: Re: [bfcpbis] Spencer Dawk= ins' Discuss on draft-ietf-bfcpbis-rfc4582bis-15: (with DISCUSS and COMMENT= )

Hi, Alissa,

On Nov 6, 2015 7:06 AM, "Alissa Cooper" <alissa@cooperw.in> wrote:
>
> Hi Spencer,
>
>
>
> On Nov 5, 2015, at 11:20 PM, Spencer Dawkins at IETF <spencerdawkins.ietf@gmail.com> w= rote:
>
>> Hi, Charles,
>>
>> On Thu, Nov 5, 2015 at 5:43 PM, Charles Eckel (eckelcu) <eckelcu@cisco.com> wrote:
>>>
>>> For TCP, the use of TLS was not required by RFC 4582. For 4582= bis, we do not require TLS in order to maintain backward compatibility with= RFC 4582.
>>
>>
>> Got it. I'm holding my nose on this one, based on backward compati= bility, and given the degree of difficulty in splicing attack packets into = the TCP sequence numbering space if you're off-path. I'm not thrilled, but = someone else needs to decide when threats reach the level where making that incompatible change is necessary - and t= hat might not be the right thing to do today.
>>  
>>>
>>> For UDP, the reason for not mandating DTLS is backward compati= bility with existing solutions. The IMTC Role Based Video Best Practice est= ablished a set of recommendations for getting BFCP to work  within ent= erprise video conference deployments. As that time,draft-sandbakken-xcon-bfcp-udp defined BFCP over UDP only. DTLS = was left for future study. Today we have many implementations of BFCP over = UDP, but few if any using DTLS. We need the ultimate RFC that standardizes = BFCP over UDP (and over DTLS) to allow interworking with these existing deployments.
>>
>>
>> OK, I'm not the Protocol Security Police, so, fine, but it seems l= ike the draft could be clearer about this, and what you said in your answer= would be really helpful in the document. 
>>
>> If the text said something like "DTLS is REQUIRED unless you = are interworking with a pre-standardization deployment that is already inse= cure,
>
>
> "REQUIRED unless" strikes me as a faulty construction. That = case is what RECOMMENDED is for, when there is a known exception to the req= uirement.

That usage is certainly more common in some parts of the IET= F than others, but it does get used. But ignoring that.

Do you think "RECOMMENDED unless you are interworking w= ith a pre-standardization deployment that is already insecure" is tigh= t enough?

The reason I'm asking, is that offpath attacks on UDP-based = protocols are a lot easier than TCP-based protocols, and if the IETF is goi= ng to publish a proposed standard with a known deficiency to accommodate pr= e-standardization deployments, I'd prefer that the guidance about using that accommodation be as clear as pos= sible.

I agree with your intent. My concern with calling out exceptions is that it= can make the existing recommendation in the draft seem weaker. How about t= his:

OLD:

   =85 It is RECOMMENDED that TLS/DTLS with an
   encryption algorithm ac= cording to Section 7 always be used.  In cases
   where signaling/control= traffic is properly protected, as described
   in Section 9 it is REQU= IRED to use a mandated encryption algorithm.
   BFCP entities MAY use o= ther security mechanisms as long as they
   provide similar securit= y properties.

NEW

   =85 It is RECOMMENDED that T= LS/DTLS with an
=    encryption algorithm accordi= ng to Section 7 always be used.  In cases
=    where signaling/control traf= fic is properly protected, as described
=    in Section 9 it is REQUIRED = to use a mandated encryption algorithm.
=    BFCP entities MAY use other = security mechanisms to interwork with 
=    legacy implementation that d= o not use TLS/DTLS as long as these 
=    mechanisms provide similar security prope= rties. 

Cheers,
Charles
 

Thanks,

Spencer

> Alissa
>
>> in which case you're not making things worse by running without tr= ansport-level security", that would capture my concern and reflect wha= t you're saying, unless I'm missing something.
>>
>> Thanks to you and Paul for the speedy response on the evening of B= its and Bites!
>>
>> Spencer
>>
>> _______________________________________________
>>
>> bfcpbis mailing list
>> bfcpbis@ietf.org
>> https://= www.ietf.org/mailman/listinfo/bfcpbis

 --_000_D26216C35E457eckelcuciscocom_-- From nobody Thu Nov 5 17:51:40 2015 Return-Path: X-Original-To: bfcpbis@ietfa.amsl.com Delivered-To: bfcpbis@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A654E1B2AC1 for ; Thu, 5 Nov 2015 17:51:38 -0800 (PST) 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 afsp-LtiKvsh for ; Thu, 5 Nov 2015 17:51:31 -0800 (PST) Received: from alln-iport-7.cisco.com (alln-iport-7.cisco.com [173.37.142.94]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 872551B2AF0 for ; Thu, 5 Nov 2015 17:51:15 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=69040; q=dns/txt; s=iport; t=1446774676; x=1447984276; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=FCrGYu4X/bChuR0C7uUZ1nMq0+r53huIvJyumR4krU4=; b=WzeqX9kOEwDsjVA4LS0iCXy6TEulW62eMan5GaDYV2Nnb2/j/OSNjoYB tbEblbt86sMqBVUTTiaWIpuWZWiGkoafU1i9l3KIXnchXv9GxG+AU6zng 7kFEnwAx+APARDXlXM2xvkOKolfYWhqgOUc9u+gOpIn0dyufi+/dAnHDJ g=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: A0D3AQCiBjxW/5pdJa1egztTbwa+AwENgV8XCoUlSgIcgSE4FAEBAQEBAQGBCoQ1AQEBBAEBARcBCBEzAQYGBQwEAgEGAhEDAQEBAQICEQERAwICAiULFAEICAEBBAENBQkSiBMNkledNJB4AQEBAQEBAQEBAQEBAQEBAQEBAQEBGIEBiUuBBoQ7AQEFCQ4YKQkMgkaBRAWHRIVXhTaDdwGFHIJwhRaBWoQ/gyV3iTqEYYNxAR8BAUKCER0WgUByg1cHFyOBBwEBAQ X-IronPort-AV: E=Sophos;i="5.20,249,1444694400"; d="scan'208";a="205570666" Received: from rcdn-core-3.cisco.com ([173.37.93.154]) by alln-iport-7.cisco.com with ESMTP; 06 Nov 2015 01:51:14 +0000 Received: from XCH-RCD-013.cisco.com (xch-rcd-013.cisco.com [173.37.102.23]) by rcdn-core-3.cisco.com (8.14.5/8.14.5) with ESMTP id tA61pD25013068 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Fri, 6 Nov 2015 01:51:13 GMT Received: from xch-aln-018.cisco.com (173.36.7.28) by XCH-RCD-013.cisco.com (173.37.102.23) with Microsoft SMTP Server (TLS) id 15.0.1104.5; Thu, 5 Nov 2015 19:51:12 -0600 Received: from xch-aln-018.cisco.com ([173.36.7.28]) by XCH-ALN-018.cisco.com ([173.36.7.28]) with mapi id 15.00.1104.000; Thu, 5 Nov 2015 19:51:12 -0600 From: "Charles Eckel (eckelcu)" To: Christer Holmberg , "Tom Kristensen (tomkrist)" Thread-Topic: Status update on draft-ietf-mmusic-dtls-sdp [was: [bfcpbis] draft-ietf-bfcpbis-rfc4583bis] Thread-Index: AdEVPGtzePVeqGKXRT2MOxuY5KEVyAAOE52AABRFx4D//45/gIAGTBIA Date: Fri, 6 Nov 2015 01:51:12 +0000 Message-ID: References: <7594FB04B1934943A5C02806D1A2204B37BC8F7B@ESESSMB209.ericsson.se> <56371495.7080105@cisco.com> <7594FB04B1934943A5C02806D1A2204B37BCD730@ESESSMB209.ericsson.se> In-Reply-To: <7594FB04B1934943A5C02806D1A2204B37BCD730@ESESSMB209.ericsson.se> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.5.7.151005 x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.70.232.194] Content-Type: text/plain; charset="utf-8" Content-ID: Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: Cc: "draft-ietf-bfcpbis-rfc4582bis@tools.ietf.org" , "bfcpbis@ietf.org" , Alissa Cooper , Gonzalo Camarillo , Ben Campbell Subject: Re: [bfcpbis] Status update on draft-ietf-mmusic-dtls-sdp [was: draft-ietf-bfcpbis-rfc4583bis] X-BeenThere: bfcpbis@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: BFCPBIS working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 Nov 2015 01:51:38 -0000 Q2hyaXN0ZXIsDQoNCkhhcyB0aGUgTU1VU0lDIHdvcmtpbmcgZ3JvdXAgZGVjaWRlZCB0aGF0IGRy YWZ0LWlldGYtbW11c2ljLWR0bHMtc2RwIHdpbGwNCk5PVCB1cGRhdGUgUkZDIDU3NjM/IEl0IGN1 cnJlbnRseSByZWZlcmVuY2VzIGl0IGV4dGVuc2l2ZWx5LCBidXQgYWNjb3JkaW5nDQp0byB0aGUg Ym9pbGVycGxhdGUgaXQgZG9lcyBub3QgZXhwbGljaXRseSB1cGRhdGUgUkZDIDU3NjMuDQoNClRo ZSBkcmFmdCBub3cgaW5jbHVkZXMgYmV0dGVyIGJhY2t3YXJkIGNvbXBhdGliaWxpdHkgd2l0aCBy ZXNwZWN0IHRvIFJGQw0KNTc2Mywgd2hpY2ggaXMgZ29vZCB0byBzZWUuIEkgdGhpbmsgd2Ugc2hv dWxkIGJlIGFibGUgdG8gd29yZCB0aGluZ3Mgc3VjaA0KdGhhdCB3ZSByZWNvbW1lbmQgdXNpbmcg dGhlIG5ldyBkdGxzLWNvbm5lY3Rpb24gYXR0cmlidXRlIHdoaWxlIGFsc28NCnJlcXVpcmluZyBz dXBwb3J0IHRoZSBhYnNlbmNlIG9mIHRoaXMgYXR0cmlidXRlIGZvciBiYWNrd2FyZA0KY29tcGF0 aWJpbGl0eS4gVGhpcyB3b3VsZCBiZSB2ZXJ5IHN0cmFpZ2h0Zm9yd2FyZCBpZg0KZHJhZnQtaWV0 Zi1tbXVzaWMtZHRscy1zZHAgdXBkYXRlcyBSRkMgNTc2My4NCg0KQ2hlZXJzLA0KQ2hhcmxlcw0K DQpPbiAxMS8yLzE1LCA3OjM5IFBNLCAiQ2hyaXN0ZXIgSG9sbWJlcmciIDxjaHJpc3Rlci5ob2xt YmVyZ0Blcmljc3Nvbi5jb20+DQp3cm90ZToNCg0KPkp1c3QgYSBxdWVzdGlvbiBmb3IgY2xhcmlm aWNhdGlvbjogd2lsbCB0aGUgZHJhZnQgbm93IGFkb3B0IHRoZQ0KPidkdGxzLWNvbm5lY3Rpb24n IGF0dHJpYnV0ZSBkZWZpbmVkIGluIHRoZSBEVExTLVNEUCBkcmFmdD8NCj4NCj5SZWdhcmRzLA0K Pg0KPkNocmlzdGVyDQo+DQo+LS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCj5Gcm9tOiBDaGFy bGVzIEVja2VsIChlY2tlbGN1KSBbbWFpbHRvOmVja2VsY3VAY2lzY28uY29tXQ0KPlNlbnQ6IDAy IE5vdmVtYmVyIDIwMTUgMTA6MjYNCj5UbzogVG9tIEtyaXN0ZW5zZW4gKHRvbWtyaXN0KSA8dG9t a3Jpc3RAY2lzY28uY29tPjsgQ2hyaXN0ZXIgSG9sbWJlcmcNCj48Y2hyaXN0ZXIuaG9sbWJlcmdA ZXJpY3Nzb24uY29tPg0KPkNjOiBBbGlzc2EgQ29vcGVyIDxhbGlzc2FAY29vcGVydy5pbj47IGJm Y3BiaXNAaWV0Zi5vcmc7DQo+ZHJhZnQtaWV0Zi1iZmNwYmlzLXJmYzQ1ODJiaXNAdG9vbHMuaWV0 Zi5vcmc7IEdvbnphbG8gQ2FtYXJpbGxvDQo+PGdvbnphbG8uY2FtYXJpbGxvQGVyaWNzc29uLmNv bT47IEJlbiBDYW1wYmVsbCA8YmVuQG5vc3RydW0uY29tPg0KPlN1YmplY3Q6IFJlOiBTdGF0dXMg dXBkYXRlIG9uIGRyYWZ0LWlldGYtbW11c2ljLWR0bHMtc2RwIFt3YXM6IFtiZmNwYmlzXQ0KPmRy YWZ0LWlldGYtYmZjcGJpcy1yZmM0NTgzYmlzXQ0KPg0KPkdyZWF0LCB0aGFua3MgVG9tLiBJIGxv b2sgZm9yd2FyZCB0byBzZWVpbmcgdGhlIHVwZGF0ZSBwb3N0ZWQgYmVmb3JlIHRoZQ0KPmVuZCBv ZiB0aGlzIHdlZWsuDQo+DQo+Q2hlZXJzLA0KPkNoYXJsZXMNCj4NCj5PbiAxMS8yLzE1LCA0OjQ1 IFBNLCAiVG9tIEtyaXN0ZW5zZW4gKHRvbWtyaXN0KSIgPHRvbWtyaXN0QGNpc2NvLmNvbT4NCj53 cm90ZToNCj4NCj4+UGVyZmVjdCEgSSdsbCB1cGRhdGUgYW5kIHBvbGlzaCB0aGUgZHJhZnQgYXMg ZGlzY3Vzc2VkIGFuZCBhZ3JlZWQgdXBvbg0KPj5iZWxvdyBhbmQgc3VibWl0Lg0KPj4NCj4+LS0g VG9tDQo+Pg0KPj5PbiAxMS8wMi8yMDE1IDA4OjA0IEFNLCBDaHJpc3RlciBIb2xtYmVyZyB3cm90 ZToNCj4+PiBIaSwNCj4+Pg0KPj4+IGRyYWZ0LWlldGYtbW11c2ljLWR0bHMtc2RwIHdhcyBkaXNj dXNzZWQgYXQgTU1VU0lDIHRvZGF5Lg0KPj4+DQo+Pj4gQXQgdGhpcyBtb21lbnQgdGhlcmUgYXJl IG5vIHRlY2huaWNhbCBvcGVuIGlzc3Vlcy4gVGhlIHBsYW4gaXMgdG8gYWRkDQo+Pj5zb21lIGVk aXRvcmlhbCB3b3JrLCBiYXNlZCBvbiBjb21tZW50cyByZWNlaXZlZCBkdXJpbmcgdGhlIHNlc3Np b24sDQo+Pj5hbmQgdGhlIGFkZCB0ZXh0IHJlZ2FyZGluZyBEVExTLXVzYWdlIGRyYWZ0cy9zcGVj cyB0aGF0IHRoZSBkcmFmdA0KPj4+dXBkYXRlcy4NCj4+PkFmdGVyIHRoYXQsIHVubGVzcyBzb21l dGhpbmcgdW5leHBlY3RlZCBjb21lcyB1cCwgdGhlIGRyYWZ0IHNob3VsZCBiZQ0KPj4+cmVhZHkg Zm9yIFdHTEMuDQo+Pj4NCj4+PiBSZWdhcmRzLA0KPj4+DQo+Pj4gQ2hyaXN0ZXINCj4+Pg0KPj4+ DQo+Pj4NCj4+PiAtLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KPj4+IEZyb206IENoYXJsZXMg RWNrZWwgKGVja2VsY3UpIFttYWlsdG86ZWNrZWxjdUBjaXNjby5jb21dDQo+Pj4gU2VudDogMjgg U2VwdGVtYmVyIDIwMTUgMTg6NTANCj4+PiBUbzogQ2hyaXN0ZXIgSG9sbWJlcmc8Y2hyaXN0ZXIu aG9sbWJlcmdAZXJpY3Nzb24uY29tPjsgVG9tIEtyaXN0ZW5zZW4NCj4+Pih0b21rcmlzdCk8dG9t a3Jpc3RAY2lzY28uY29tPg0KPj4+IENjOiBBbGlzc2EgQ29vcGVyPGFsaXNzYUBjb29wZXJ3Lmlu PjsgYmZjcGJpc0BpZXRmLm9yZzsNCj4+PmRyYWZ0LWlldGYtYmZjcGJpcy1yZmM0NTgyYmlzQHRv b2xzLmlldGYub3JnOyBHb256YWxvDQo+Pj5DYW1hcmlsbG88Z29uemFsby5jYW1hcmlsbG9AZXJp Y3Nzb24uY29tPjsgQmVuDQo+Pj5DYW1wYmVsbDxiZW5Abm9zdHJ1bS5jb20+DQo+Pj4gU3ViamVj dDogUmU6IFtiZmNwYmlzXSBkcmFmdC1pZXRmLWJmY3BiaXMtcmZjNDU4M2Jpcw0KPj4+DQo+Pj4g VGhhbmtzIENocmlzdGVyLg0KPj4+DQo+Pj4gVG9tLCBjYW4geW91IHBsZWFzZSBwb3N0IHRoZSBj b3JyZXNwb25kaW5nIHVwZGF0ZSB0byB0aGUgZHJhZnQ/DQo+Pj4NCj4+PiBDaGVlcnMsDQo+Pj4g Q2hhcmxlcw0KPj4+DQo+Pj4gT24gOS8yOC8xNSwgMzowNyBBTSwgImJmY3BiaXMgb24gYmVoYWxm IG9mIENocmlzdGVyIEhvbG1iZXJnIg0KPj4+IDxiZmNwYmlzLWJvdW5jZXNAaWV0Zi5vcmcgb24g YmVoYWxmIG9mDQo+Pj4gY2hyaXN0ZXIuaG9sbWJlcmdAZXJpY3Nzb24uY29tPg0KPj4+IHdyb3Rl Og0KPj4+DQo+Pj4gICAgDQo+Pj4+IEhpLA0KPj4+Pg0KPj4+PiAgICAgIA0KPj4+Pj4gSW4gdGhh dCBjYXNlLCBJIHByZWZlciBUb23igJlzIG9yaWdpbmFsIHN1Z2dlc3Rpb24sDQo+Pj4+Pg0KPj4+ Pj4gICBXaGF0IGlmIHdlIGtlZXAgdGhlIHRleHQgYW5kIGFkZHMgdGhpcyBhcyBhbiBhZGRpdGlv bmFsIHJlZmVyZW5jZQ0KPj4+Pj4gaW4gdGhlIHR3byBuZXcgdGV4dCBwYXNzYWdlcyBwcm9wb3Nl ZCBieSBDaGFybGVzOiAiLi4uIFsxM10sIGFuZA0KPj4+Pj4gdGhlIGNsYXJpZmljYXRpb25zIGRl ZmluZWQgaW4gW2RyYWZ0LWlldGYtbW11c2ljLWR0bHMtc2RwXSwgLi4uIi4NCj4+Pj4+DQo+Pj4+ PiAgIFdoZXJlIFsxM10gaXMgYSByZWZlcmVuY2UgdG8gUkZDIDU3NjMuDQo+Pj4+PiAgICAgICAg DQo+Pj4+IElmIHRoYXQncyBzb21ldGhpbmcgcGVvcGxlIGNhbiBhZ3JlZSB0bywgdGhlbiBjYW4g bGl2ZSB3aXRoIHN1Y2gNCj4+Pj4gY29tcHJvbWlzZSA6KQ0KPj4+Pg0KPj4+PiBSZWdhcmRzLA0K Pj4+Pg0KPj4+PiBDaHJpc3Rlcg0KPj4+Pg0KPj4+Pg0KPj4+Pg0KPj4+Pg0KPj4+Pg0KPj4+PiBJ ZiBpdCB0dXJucyBvdXQgdGhhdCBkcmFmdC1pZXRmLW1tdXNpYy1kdGxzLXNkcCB1cGRhdGVzIFJG QyA1NzYzLA0KPj4+PnRoZW4gIHRoZXJlIGlzIHNvbWUgcmVkdW5kYW5jeS4gQnV0IHRoYXQgaXMg YmV0dGVyIHRoYW4gaGF2aW5nIGEgaG9sZQ0KPj4+PndoZW4gaXQgIGNvbWVzIHRvIGJhY2t3YXJk IGNvbXBhdGliaWxpdHkgd2l0aCBleGlzdGluZw0KPj4+PmltcGxlbWVudGF0aW9ucywgd2hpY2gg aXMgIHdoYXQgd2Ugd2lsbCBoYXZlIHRvZGF5IGlmIHdlIHJlZmVyZW5jZQ0KPj4+PmRyYWZ0LWll dGYtbW11c2ljLWR0bHMtc2RwIG9ubHkuDQo+Pj4+DQo+Pj4+IENoZWVycywNCj4+Pj4gQ2hhcmxl cw0KPj4+Pg0KPj4+Pg0KPj4+Pg0KPj4+PiBPbiA5LzI1LzE1LCAyOjIxIEFNLCAiQ2hyaXN0ZXIg SG9sbWJlcmciDQo+Pj4+IDxjaHJpc3Rlci5ob2xtYmVyZ0Blcmljc3Nvbi5jb20+DQo+Pj4+IHdy b3RlOg0KPj4+Pg0KPj4+PiAgICAgIA0KPj4+Pj4gSGkgQ2hhcmxlcywNCj4+Pj4+DQo+Pj4+PiAg ICAgICAgDQo+Pj4+Pj4gQXMgYSBzaW1wbGUgZXhhbXBsZSwgd2UgY3VycmVudGx5IHJlZmVyIHRv IHJmYzQ1ODJiaXMgaW5zdGVhZCBvZg0KPj4+Pj4+IHRoZSBldmVudHVhbCBSRkMuIEFzc3VtaW5n IHJmYzQ1ODJiaXMgZG9lcyBiZWNvbWUgYW4gUkZDLCB3ZSB3b3VsZA0KPj4+Pj4+IHdhbnQgdGhl IFJGQyBlZGl0b3IgdG8gdXBkYXRlIHJlZmVyZW5jZXMgdG8gaXQgYW5kIHRvIFJGQ3h4eHggd2l0 aA0KPj4+Pj4+IHRoZSBhY3R1YWwgUkZDIG51bWJlci4NCj4+Pj4+PiBTaW1pbGFyIGhlcmUsIHdl IHdvdWxkIHdhbnQgdGhlbSB0byBjaGVjayB3aXRoIGF1dGhvcnMvY2hhaXJzL0FEcw0KPj4+Pj4+ IG9uIHRoZSBzdGF0ZSBvZiBkcmFmdC1pZXRmLW1tdXNpYy1kdGxzLXNkcCB0byBzZWUgaWYgd2Ug d2FudCB0bw0KPj4+Pj4+IHJlcGxhY2Ugb3VyIHJlZmVyZW5jZSB0byBSRkMgNTc2MyB3aXRoIGEg cmVmZXJlbmNlIHRvIGl0LiBUaGlzIHdheQ0KPj4+Pj4+IHdlIGNhbiBtb3ZlIGZvcndhcmQgd2hp bGUgZHJhZnQtaWV0Zi1tbXVzaWMtZHRscy1zZHAgY29udGludWVzIHRvDQo+Pj4+Pj4gcHJvZ3Jl c3MgYXMgd2VsbC4NCj4+Pj4+PiAgICAgICAgICANCj4+Pj4+IEkgZG9uJ3QgdGhpbmsgaXQncyB0 aGUgc2FtZSB0aGluZy4gRmlyc3QgeW91IHRhbGsgYWJvdXQgYSBkcmFmdCwNCj4+Pj4+IHdoZXJl IHRoZSBkcmFmdCBuYW1lIHdpbGwgYmUgcmVwbGFjZWQgd2l0aCB0aGUgdG8tYmUtYXNzaWduZWQg UkZDDQo+Pj4+PiBudW1iZXIuIEluIHRoZSBjYXNlIG9mIERUTFMtU0RQIHdlIGFyZSB0YWxraW5n IGFib3V0IHR3byBzZXBhcmF0ZQ0KPj4+Pj5zcGVjaWZpY2F0aW9ucy4NCj4+Pj4+DQo+Pj4+PiBS ZWdhcmRzLA0KPj4+Pj4NCj4+Pj4+IENocmlzdGVyDQo+Pj4+Pg0KPj4+Pj4NCj4+Pj4+IE9uIDkv MjQvMTUsIDI6NTMgQU0sICJDaHJpc3RlciBIb2xtYmVyZyINCj4+Pj4+IDxjaHJpc3Rlci5ob2xt YmVyZ0Blcmljc3Nvbi5jb20+DQo+Pj4+PiB3cm90ZToNCj4+Pj4+DQo+Pj4+PiAgICAgICAgDQo+ Pj4+Pj4gSGkgQ2hhcmxlcywNCj4+Pj4+Pg0KPj4+Pj4+IEkgYW0gc3RpbGwgbm90IHN1cmUgSSB1 bmRlcnN0YW5kIHlvdXIgc3VnZ2VzdGlvbjogd2hhdCBpcyBtZWFudCBieQ0KPj4+Pj4+ICJhcyBk ZXRlcm1pbmVkIHByaW9yIHRvIHB1YmxpY2F0aW9uIj8gV2hlbi93aGVyZS93aG8/IDopDQo+Pj4+ Pj4NCj4+Pj4+PiBSZWdhcmRzLA0KPj4+Pj4+DQo+Pj4+Pj4gQ2hyaXN0ZXINCj4+Pj4+Pg0KPj4+ Pj4+IC0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQo+Pj4+Pj4gRnJvbTogQ2hhcmxlcyBFY2tl bCAoZWNrZWxjdSkgW21haWx0bzplY2tlbGN1QGNpc2NvLmNvbV0NCj4+Pj4+PiBTZW50OiAyMi4g c3l5c2t1dXRhIDIwMTUgMTc6MDUNCj4+Pj4+PiBUbzogQ2hyaXN0ZXIgSG9sbWJlcmc7IFRvbSBL cmlzdGVuc2VuICh0b21rcmlzdCkNCj4+Pj4+PiBDYzogZHJhZnQtaWV0Zi1iZmNwYmlzLXJmYzQ1 ODJiaXNAdG9vbHMuaWV0Zi5vcmc7DQo+Pj4+Pj4gYmZjcGJpc0BpZXRmLm9yZzsgQWxpc3NhIENv b3BlcjsgR29uemFsbyBDYW1hcmlsbG87IEJlbiBDYW1wYmVsbA0KPj4+Pj4+IFN1YmplY3Q6IFJl OiBbYmZjcGJpc10gZHJhZnQtaWV0Zi1iZmNwYmlzLXJmYzQ1ODNiaXMNCj4+Pj4+Pg0KPj4+Pj4+ IEkgdmlldyByZWZlcnJpbmcgdG8gZHJhZnQtaWV0Zi1tbXVzaWMtZHRscy1zZHAgbm93IGluc3Rl YWQgb2YgUkZDDQo+Pj4+Pj4gNTc2MyB0byBiZSBsaWtlIHdyaXRpbmcgYSBibGFuayBjaGVjay4g RGViYXRlIGlzIGFjdGl2ZWx5DQo+Pj4+Pj4gb2NjdXJyaW5nIG9uIHRoZSBsaXN0LCB0aGUgbm9y bWF0aXZlIGxhbmd1YWdlIGluIFJGQyA1NzYzIGlzDQo+Pj4+Pj4gZXhwZWN0ZWQgdG8gYmUgdXBk YXRlZCBpbiBtdWx0aXBsZSB3YXlzLCBhbmQgYmFja3dhcmQNCj4+Pj4+PiBjb21wYXRpYmlsaXR5 IHdpdGggdGhlIHRoZSBub3JtYXRpdmUgbGFuZ3VhZ2UgcHJvdmlkZSBpbiBwcmV2aW91cw0KPj4+ Pj4+IHZlcnNpb24gb2YgcmZjNDU4M2JpcyBpcyBub3QgZnVsbHkgYWRkcmVzc2VkLiBJdCBzZWVt cyBtb3JlDQo+Pj4+Pj4gYXBwcm9wcmlhdGUgdG8gbWUgYXQgdGhpcyBzdGFnZSB0byBjb250aW51 ZSB0byByZWZlciB0byBSRkMgNTc2Mw0KPj4+Pj4+IHdpdGggYSBub3RlIHJlZ2FyZGluZyB1cGRh dGluZyBvciByZXBsYWNpbmcgdGhhdCByZWZlcmVuY2Ugd2l0aA0KPj4+Pj4+IG9uZSB0byBkcmFm dC1pZXRmLW1tdXNpYy1kdGxzLXNkcCwgYXMgZGV0ZXJtaW5lZCBwcmlvciB0bw0KPj4+Pj4+cHVi bGljYXRpb24uDQo+Pj4+Pj4NCj4+Pj4+PiBDaGVlcnMsDQo+Pj4+Pj4gQ2hhcmxlcw0KPj4+Pj4+ DQo+Pj4+Pj4gT24gOS8yMS8xNSwgMTE6NDggUE0sICJDaHJpc3RlciBIb2xtYmVyZyINCj4+Pj4+ PiA8Y2hyaXN0ZXIuaG9sbWJlcmdAZXJpY3Nzb24uY29tPg0KPj4+Pj4+IHdyb3RlOg0KPj4+Pj4+ DQo+Pj4+Pj4gICAgICAgICAgDQo+Pj4+Pj4+IEhpLA0KPj4+Pj4+Pg0KPj4+Pj4+PiAgICAgICAg ICAgIA0KPj4+Pj4+Pj4gSSBzZWUuIEFzIHRoaXMgaXMgYSBtb3ZpbmcgdGFyZ2V0LCBwZXJoYXBz IHdoZXJlIHdlIHJlZmVyZW5jZQ0KPj4+Pj4+Pj4gUkZDDQo+Pj4+Pj4+PiA1NzYzIHdlIGNhbiBh ZGQgYSBub3RlIGZvciB0aGUgUkZDIGVkaXRvciB0aGF0DQo+Pj4+Pj4+PiBkcmFmdC1pZXRmLW1t dXNpYy1kdGxzLXNkcCBpcyBleHBlY3RlZCB0byBhZGQgY2xhcmlmaWNhdGlvbnMgYW5kDQo+Pj4+ Pj4+PiBtYWtlIGNoYW5nZXMgdG8gUkZDIDU3NjMgdGhhdCBzaG91bGQgYmUgY29uc2lkZXJlZCBw cmlvciB0bw0KPj4+Pj4+Pj4gcHVibGljYXRpb24gb2YgcmZjNDU4M2Jpcy4NCj4+Pj4+Pj4+ICAg ICAgICAgICANCj4+Pj4+Pj4gSSBhbSBub3Qgc3VyZSBJIHVuZGVyc3RhbmQuIEkgZG9uJ3QgdGhp bmsgaXQncyB1cCB0byB0aGUgUkZDDQo+Pj4+Pj4+IGVkaXRvciB0byBtYWtlIGEgZGVjaXNpb24g d2hldGhlciB0aGUgZHJhZnQgc2hvdWxkIHJlZmVyZW5jZQ0KPj4+Pj4+PkRUTFMtU0RQLg0KPj4+ Pj4+Pg0KPj4+Pj4+PiBSZWdhcmRzLA0KPj4+Pj4+Pg0KPj4+Pj4+PiBDaHJpc3Rlcg0KPj4+Pj4+ Pg0KPj4+Pj4+Pg0KPj4+Pj4+Pg0KPj4+Pj4+PiBPbiA5LzIxLzE1LCAxMToyMyBBTSwgIkNocmlz dGVyIEhvbG1iZXJnIg0KPj4+Pj4+PiA8Y2hyaXN0ZXIuaG9sbWJlcmdAZXJpY3Nzb24uY29tPg0K Pj4+Pj4+PiB3cm90ZToNCj4+Pj4+Pj4NCj4+Pj4+Pj4gICAgICAgICAgICANCj4+Pj4+Pj4+IEhp LA0KPj4+Pj4+Pj4NCj4+Pj4+Pj4+ICAgICAgICAgICANCj4+Pj4+Pj4+PiBSRkMgNTc2Mywgd2hp Y2ggaXMgY3VycmVudGx5IHJlcXVpcmVkIGZvciBCRkNQIHdpdGggRFRMUyByZWFkczoNCj4+Pj4+ Pj4+Pg0KPj4+Pj4+Pj4+ICAgIG8gIFRoZSBlbmRwb2ludCBNVVNUIE5PVCB1c2UgdGhlIGNvbm5l Y3Rpb24gYXR0cmlidXRlDQo+Pj4+Pj4+Pj5kZWZpbmVkIGluDQo+Pj4+Pj4+Pj4gICAgICBbUkZD NDE0NTxodHRwczovL3Rvb2xzLmlldGYub3JnL2h0bWwvcmZjNDE0NT5dLg0KPj4+Pj4+Pj4+ICAg ICAgICAgIA0KPj4+Pj4+Pj4gQ29ycmVjdC4NCj4+Pj4+Pj4+DQo+Pj4+Pj4+PiBBbmQsIElGIHdl IGRlY2lkZSB0byB1c2UgZGVmaW5lIHVzYWdlIG9mIHRoZSAnY29ubmVjdGlvbicNCj4+Pj4+Pj4+ IGF0dHJpYnV0ZSBmb3IgRFRMUywgd2Ugd291bGQgY2hhbmdlIHRoYXQuDQo+Pj4+Pj4+Pg0KPj4+ Pj4+Pj4gSG93ZXZlciwgYSBmZXcgZGF5cyBhZ28gd2Ugc2VudCBhbiBlLW1haWwgdG8gdGhlIE1N VVNJQyBsaXN0LA0KPj4+Pj4+Pj5zdWdnZXN0aW5nIHRoYXQgd2Ugc2hvdWxkIE5PVCB1c2UgdGhl ICdjb25uZWN0aW9uJyBhdHRyaWJ1dGUgZm9yDQo+Pj4+Pj4+PkRUTFMuDQo+Pj4+Pj4+PiBJbnN0 ZWFkIHdlIHNob3VsZCBkZWZpbmUgYSBuZXcgYXR0cmlidXRlIChmb3IgbW9yZSBkZXRhaWxzLA0K Pj4+Pj4+Pj5wbGVhc2UgIHNlZSB0aGUgTU1VU0lDIGxpc3QpLg0KPj4+Pj4+Pj4NCj4+Pj4+Pj4+ ICAgICAgICAgICANCj4+Pj4+Pj4+PiBTZWN0aW9uIDUuMSBvZiBkcmFmdC1pZXRmLW1tdXNpYy1k dGxzLXNkcCByZWFkczoNCj4+Pj4+Pj4+Pg0KPj4+Pj4+Pj4+ICAgIFdoZW4gdXNlZCB3aXRoIERU TFMsIHRoZXJlIGlzIG5vIGRlZmF1bHQgdmFsdWUgZGVmaW5lZCBmb3IgdGhlDQo+Pj4+Pj4+Pj4g ICAgYXR0cmlidXRlLiAgSW1wbGVtZW50YXRpb25zIHRoYXQgd2lzaCB0byB1c2UgdGhlIGF0dHJp YnV0ZQ0KPj4+Pj4+Pj4+TVVTVA0KPj4+Pj4+Pj4+ICAgIGV4cGxpY2l0bHkgaW5jbHVkZSBpdCBp biBTRFAgb2ZmZXJzIGFuZCBhbnN3ZXJzLiAgSWYgYW4NCj4+Pj4+Pj4+Pm9mZmVyIG9yDQo+Pj4+ Pj4+Pj4gICAgYW5zd2VyIGRvZXMgbm90IGNvbnRhaW4gYW4gYXR0cmlidXRlLCBvdGhlciBtZWFu cyBuZWVkcyB0bw0KPj4+Pj4+Pj4+YmUgIHVzZWQgaW4NCj4+Pj4+Pj4+PiAgICBvcmRlciBmb3Ig ZW5kcG9pbnRzIHRvIGRldGVybWluZSB3aGV0aGVyIGFuIG9mZmVyIG9yIGFuc3dlciBpcw0KPj4+ Pj4+Pj4+ICAgIGFzc29jaWF0ZWQgd2l0aCBhbiBldmVudCB0aGF0IHJlcXVpcmVzIHRoZSBEVExT IGFzc29jaWF0aW9uDQo+Pj4+Pj4+Pj50byAgYmUNCj4+Pj4+Pj4+PiByZS0NCj4+Pj4+Pj4+PiAg ICBlc3RhYmxpc2hlZC4NCj4+Pj4+Pj4+Pg0KPj4+Pj4+Pj4+IEkgc3VwcG9zZSBpZiBkcmFmdC1p ZXRmLW1tdXNpYy1kdGxzLXNkcCBwdWxscyBpbiBlbm91Z2ggZnJvbQ0KPj4+Pj4+Pj4+IFJGQw0K Pj4+Pj4+Pj4+IDU3NjMgdG8gbWFrZSBpdCBjbGVhciBob3cgdGhlIERUTFMgZXN0YWJsaXNobWVu dCBhbmQNCj4+Pj4+Pj4+PiByZS1lc3RhYmxpc2htZW50IHdvcmtzIGZvciB0aGUgY2FzZSBvZiB3 aGljaCB0aGUgY29ubmVjdGlvbg0KPj4+Pj4+Pj4+IGF0dHJpYnV0ZSBpcyBub3QgdXNlZCwgdGhl biB3ZSBjYW4gY2hhbmdlIHRoZSByZWZlcmVuY2UgZnJvbQ0KPj4+Pj4+Pj4+IFJGQw0KPj4+Pj4+ Pj4+IDU3NjMgdG8gZHJhZnQtaWV0Zi1tbXVzaWMtZHRscy1zZHAuDQo+Pj4+Pj4+Pj4NCj4+Pj4+ Pj4+PiBUaGUgbGFzdCBzZXZlcmFsIHVwZGF0ZXMgb2YgZHJhZnQtaWV0Zi1iZmNwYmlzLXJmYzQ1 ODNiaXMgaGF2ZQ0KPj4+Pj4+Pj4+IHJlbW92ZWQgc3VwcG9ydGluZyB0ZXh0IGZyb20gdGhlIGRy YWZ0IGluIGZhdm9yIG9mIHBvaW50aW5nIHRvDQo+Pj4+Pj4+Pj4gUkZDDQo+Pj4+Pj4+Pj4gNTc2 MyBhcyB0aGUgIHNvdXJjZSBvZiB0cnV0aC4gSSBmZWFyIHRoYXQNCj4+Pj4+Pj4+PiBkcmFmdC1p ZXRmLW1tdXNpYy1kdGxzLXNkcCBpbiBpdHMgY3VycmVudCBzdGF0ZSBkb2VzIG5vdCBzZXJ2ZQ0K Pj4+Pj4+Pj4+IHRoYXQgbmVlZCBmb3IgZHJhZnQtaWV0Zi1iZmNwYmlzLXJmYzQ1ODNiaXMuIEkg dmFsdWUNCj4+Pj4+Pj4+PiBDaHJpc3RlcuKAmXMgdGhvdWdodHMgYW5kIHdlbGNvbWUgdGhlIG9w aW5pb24gb2Ygb3RoZXJzLA0KPj4+Pj4+Pj4+IGVzcGVjaWFsbHkgdGhvc2Ugd2hvIGhhdmUgb3Ig YXJlIGltcGxlbWVudGluZyBCRkNQIHdpdGggRFRMUyBhbmQNCj4+Pj4+Pj4+PklDRSwgd2hpY2gg SSBoYXZlIG5vdC4NCj4+Pj4+Pj4+PiAgICAgICAgICANCj4+Pj4+Pj4+IFBsZWFzZSBub3RlIHRo YXQgRFRMUy1TRFAgZG9lcyBub3Qgb25seSBkZWZpbmUgdXNhZ2Ugb2YgdGhlDQo+Pj4+Pj4+PiAn Y29ubmVjdGlvbicNCj4+Pj4+Pj4+IGF0dHJpYnV0ZSwgaXQgYWxzbyBkb2VzIG90aGVyIHRoaW5n cy4gTWF5YmUgbW9yZSBpbXBvcnRhbnQsIGl0DQo+Pj4+Pj4+PiBkb2VzIG5vdCBzdGF0ZSB0aGF0 IGFuIGFkZHJlc3MgY2hhbmdlIGJ5IGRlZmF1bHQgcmVxdWlyZXMgYSBuZXcNCj4+Pj4+Pj4+IERU TFMgYXNzb2NpYXRpb24NCj4+Pj4+Pj4+IC0gd2hpY2ggaXMgYSBhbm90aGVyIDU3NjMgbW9kaWZp Y2F0aW9uLg0KPj4+Pj4+Pj4NCj4+Pj4+Pj4+IFJlZ2FyZHMsDQo+Pj4+Pj4+Pg0KPj4+Pj4+Pj4g Q2hyaXN0ZXINCj4+Pj4+Pj4+DQo+Pj4+Pj4+Pg0KPj4+Pj4+Pj4NCj4+Pj4+Pj4+DQo+Pj4+Pj4+ PiBPbiA5LzIxLzE1LCA5OjMyIEFNLCAiYmZjcGJpcyBvbiBiZWhhbGYgb2YgQ2hyaXN0ZXIgSG9s bWJlcmciDQo+Pj4+Pj4+PiA8YmZjcGJpcy1ib3VuY2VzQGlldGYub3JnIG9uIGJlaGFsZiBvZg0K Pj4+Pj4+Pj4gY2hyaXN0ZXIuaG9sbWJlcmdAZXJpY3Nzb24uY29tPg0KPj4+Pj4+Pj4gd3JvdGU6 DQo+Pj4+Pj4+Pg0KPj4+Pj4+Pj4gICAgICAgICAgIA0KPj4+Pj4+Pj4+IEhpIENoYXJsZXMsDQo+ Pj4+Pj4+Pj4NCj4+Pj4+Pj4+PiAgICAgICAgICANCj4+Pj4+Pj4+Pj4gVGhlIHByb2JsZW0gSSBz ZWUgd2l0aCB0aGlzIGlzIHRoYXQgaXQgaXMgbm90IGp1c3QgYSBtYXR0ZXIgb2YNCj4+Pj4+Pj4+ Pj4gY2hhbmdpbmcgdGhlIHJlZmVyZW5jZSwgaXQgaXMgYWxzbyBhIG1hdHRlciBvZiBjaGFuZ2lu ZyB0aGUNCj4+Pj4+Pj4+Pj4gbm9ybWF0aXZlIGJlaGF2aW9yLg0KPj4+Pj4+Pj4+PiBGb3IgRFRM UyB3aXRoIEJGQ1AsIHdlIG5ldmVyIHJlcXVpcmVkIHRoZSB1c2Ugb2YNCj4+Pj4+Pj4+Pj50aGU+ 4oCcY29ubmVjdGlvbuKAnQ0KPj4+Pj4+Pj4+PiBhdHRyaWJ1dGUuDQo+Pj4+Pj4+Pj4+IElmIHdl IGFyZSB0byBzdGFydCByZXF1aXJpbmcgaXQsIHdlIHdvdWxkIG5lZWQgYWRkIHRleHQgdG8NCj4+ Pj4+Pj4+Pj4gZGVzY3JpYmUgaG93IHRvIGFkZHJlc3MgYmFja3dhcmQgY29tcGF0aWJpbGl0eSBp biBjYXNlcyBpbg0KPj4+Pj4+Pj4+PiB3aGljaCB0aGUgY29ubmVjdGlvbiBhdHRyaWJ1dGUgaXMg bm90IHNwZWNpZmllZC4NCj4+Pj4+Pj4+Pj4gICAgICAgICANCj4+Pj4+Pj4+PiBUaGUgaW50ZW50 aW9uIGlzIHRvIGNvdmVyIGJhY2t3YXJkIGNvbXBhdGliaWxpdHkgaW4gdGhlIGRyYWZ0Lg0KPj4+ Pj4+Pj4+DQo+Pj4+Pj4+Pj4gICAgICAgICAgDQo+Pj4+Pj4+Pj4+IEFyZSB0aGVyZSBwbGFucyBm b3IgdGhpcyB3aXRoaW4gUkZDIDU3NjNiaXMgZHJhZnQ/IElmIHNvLA0KPj4+Pj4+Pj4+PiBUb23i gJlzIHJlY29tbWVuZGF0aW9uIG9mIGNvbnRpbnVpbmcgdG8gcG9pbnQgdG8gUkZDIDU3NjMgZm9y DQo+Pj4+Pj4+Pj4+IG5vdyBtYXkgYmUgdGhlIGJlc3QgYXBwcm9hY2guDQo+Pj4+Pj4+Pj4+ICAg ICAgICAgDQo+Pj4+Pj4+Pj4gSSBhbSBub3QgZmFtaWxpYXIgd2l0aCB0aGUgNTc2M2JpcyBkcmFm dC4gQnV0LCBldmVuIGlmIHRoZQ0KPj4+Pj4+Pj4+RFRMUy1TRFAgZHJhZnQgbWFrZXMgdXBkYXRl cyB0byA1NzYzLCBpdCB3b24ndCBiZWNvbWUgYSA1NzYzYmlzDQo+Pj4+Pj4+Pj5kcmFmdC4NCj4+ Pj4+Pj4+Pg0KPj4+Pj4+Pj4+IFJlZ2FyZHMsDQo+Pj4+Pj4+Pj4NCj4+Pj4+Pj4+PiBDaHJpc3Rl cg0KPj4+Pj4+Pj4+DQo+Pj4+Pj4+Pj4NCj4+Pj4+Pj4+Pg0KPj4+Pj4+Pj4+IE9uIDkvMTEvMTUs IDE6MTEgUE0sICJDaHJpc3RlciBIb2xtYmVyZyINCj4+Pj4+Pj4+PiA8Y2hyaXN0ZXIuaG9sbWJl cmdAZXJpY3Nzb24uY29tPg0KPj4+Pj4+Pj4+IHdyb3RlOg0KPj4+Pj4+Pj4+DQo+Pj4+Pj4+Pj4g ICAgICAgICAgDQo+Pj4+Pj4+Pj4+IEhpLA0KPj4+Pj4+Pj4+Pg0KPj4+Pj4+Pj4+PiAgICAgICAg IA0KPj4+Pj4+Pj4+Pj4gSG1tLCB5ZXMgbWF5YmUgYW4gaWRlYSBpZiBpdCdzIGZpbmUgcHJvY2Vl ZGluZyB3aXRoIHJlZmVycmluZw0KPj4+Pj4+Pj4+Pj5hICB3b3JrLWluLXByb2dyZXNzIGRyYWZ0 IGhlcmUuDQo+Pj4+Pj4+Pj4+PiBXaGF0IGlmIHdlIGtlZXAgdGhlIHRleHQgYW5kIGFkZHMgdGhp cyBhcyBhbiBhZGRpdGlvbmFsDQo+Pj4+Pj4+Pj4+PnJlZmVyZW5jZSBpbiB0aGUgdHdvIG5ldyB0 ZXh0IHBhc3NhZ2VzIHByb3Bvc2VkIGJ5IENoYXJsZXM6ICIuLi4NCj4+Pj4+Pj4+Pj4+IFsxM10s IGFuZCB0aGUgY2xhcmlmaWNhdGlvbnMgZGVmaW5lZCBpbg0KPj4+Pj4+Pj4+Pj5bZHJhZnQtaWV0 Zi1tbXVzaWMtZHRscy1zZHBdLCAuLi4iLg0KPj4+Pj4+Pj4+Pj4NCj4+Pj4+Pj4+Pj4+IFdoZXJl IFsxM10gaXMgYSByZWZlcmVuY2UgdG8gUkZDIDU3NjMuDQo+Pj4+Pj4+Pj4+PiAgICAgICAgDQo+ Pj4+Pj4+Pj4+IE15IHN1Z2dlc3Rpb24gaXMgdG8gKm9ubHkqIHJlZmVyIHRoZSBuZXcgZHRscy1z ZHAgZHJhZnQuDQo+Pj4+Pj4+Pj4+IEJlY2F1c2UsIG9uZSBvZiB0aGUgaWRlYXMgd2l0aCB0aGUg bmV3IGRyYWZ0IGlzIHRvIGFsc28gdXBkYXRlDQo+Pj4+Pj4+Pj4+IFJGQyA1NzYzIHRvIHJlZmVy ZW5jZSB0aGUgbmV3IGR0bHMtc2RwIGRyYWZ0Lg0KPj4+Pj4+Pj4+Pg0KPj4+Pj4+Pj4+PiAgICAg ICAgIA0KPj4+Pj4+Pj4+Pj4gQW55d2F5LCBJJ2Qgc3RpbGwgcHJlZmVyIHRvIGtlZXAgdGhlIHRl eHQgaW4NCj4+Pj4+Pj4+Pj4+IGRyYWZ0LWlldGYtYmZjcGJpcy1yZmM0NTgzYmlzLTEyIGFuZCBy ZWRpcmVjdCB0aGUgcmVhZGVycyB0bw0KPj4+Pj4+Pj4+Pj4gdGhlIHJmYzU3NjNiaXMsIHRoYXQg ZXZlbnR1YWxseSB0aGVuIHdpbGwgb2Jzb2xldGUgKG9yDQo+Pj4+Pj4+Pj4+PiBleHRlbmQ/KSBS RkMgNTc2My4NCj4+Pj4+Pj4+Pj4+ICAgICAgICANCj4+Pj4+Pj4+Pj4gVGhlIG5ldyBkdGxzLXNk cCBkcmFmdCB3aWxsIG5vdCBiZWNvbWUgNTc2M2JpcyAoZXZlbnRob3VnaCBpdA0KPj4+Pj4+Pj4+ PiBNQVkgdXBkYXRlIHNvbWUgcGFydHMgb2YgNTc2MykuIEl0J3MgYSBnZW5lcmljIGRvY3VtZW50 LCB3aGljaA0KPj4+Pj4+Pj4+PiAqYW55KiBEVExTIHVzYWdlIGNhbiB0aGVuIHJlZmVyZW5jZS4N Cj4+Pj4+Pj4+Pj4NCj4+Pj4+Pj4+Pj4gUmVnYXJkcywNCj4+Pj4+Pj4+Pj4NCj4+Pj4+Pj4+Pj4g Q2hyaXN0ZXINCj4+Pj4+Pj4+Pj4NCj4+Pj4+Pj4+Pj4NCj4+Pj4+Pj4+Pj4NCj4+Pj4+Pj4+Pj4g T24gMDkvMTEvMjAxNSAwMToyNSBQTSwgQ2hyaXN0ZXIgSG9sbWJlcmcgd3JvdGU6DQo+Pj4+Pj4+ Pj4+ICAgICAgICAgDQo+Pj4+Pj4+Pj4+PiBIaSwNCj4+Pj4+Pj4+Pj4+DQo+Pj4+Pj4+Pj4+PiBN eSBzdWdnZXN0aW9uIHdvdWxkIGFjdHVhbGx5IGJlIHRvIHJlZmVyIHRvIHRoZSBuZXcNCj4+Pj4+ Pj4+Pj4+IGRyYWZ0LWlldGYtbW11c2ljLWR0bHMtc2RwLCB3aGljaCBpcyBnb2luZyB0byBjbGFy aWZ5IHRoZQ0KPj4+Pj4+Pj4+Pj4gRFRMUy1TUlRQIHJ1bGVzIHJlZ2FyZGluZyB3aGVuIGEgbmV3 IERUTFMgYXNzb2NpYXRpb24gbXVzdCBiZQ0KPj4+Pj4+Pj4+Pj4gZXN0YWJsaXNoZWQuDQo+Pj4+ Pj4+Pj4+Pg0KPj4+Pj4+Pj4+Pj4gUmVnYXJkcywNCj4+Pj4+Pj4+Pj4+DQo+Pj4+Pj4+Pj4+PiBD aHJpc3Rlcg0KPj4+Pj4+Pj4+Pj4NCj4+Pj4+Pj4+Pj4+IC0tLS0tT3JpZ2luYWwgTWVzc2FnZS0t LS0tDQo+Pj4+Pj4+Pj4+PiBGcm9tOiBUb20gS3Jpc3RlbnNlbiBbbWFpbHRvOnRvbWtyaXN0QGNp c2NvLmNvbV0NCj4+Pj4+Pj4+Pj4+IFNlbnQ6IDExLiBzeXlza3V1dGEgMjAxNSAxMzoyNQ0KPj4+ Pj4+Pj4+Pj4gVG86IENoYXJsZXMgRWNrZWwgKGVja2VsY3UpDQo+Pj4+Pj4+Pj4+PiBDYzogQ2hy aXN0ZXIgSG9sbWJlcmc7IEFsaXNzYSBDb29wZXI7IEdvbnphbG8gQ2FtYXJpbGxvOw0KPj4+Pj4+ Pj4+Pj4gZHJhZnQtaWV0Zi1iZmNwYmlzLXJmYzQ1ODJiaXNAdG9vbHMuaWV0Zi5vcmc7IEJlbiBD YW1wYmVsbDsNCj4+Pj4+Pj4+Pj4+IGJmY3BiaXNAaWV0Zi5vcmcNCj4+Pj4+Pj4+Pj4+IFN1Ympl Y3Q6IFJlOiBkcmFmdC1pZXRmLWJmY3BiaXMtcmZjNDU4M2Jpcw0KPj4+Pj4+Pj4+Pj4NCj4+Pj4+ Pj4+Pj4+IFBvaW50aW5nIHRvIHRoZSBEVExTLVNSVFAgKGFuZCBieSB0aGF0IGFueSB1cGRhdGVz IG9mIGl0KSBpcw0KPj4+Pj4+Pj4+Pj4gYSBzaW1wbGUsIHNhZmUgYW5kIHN0cmFpZ3QtZm9yd2Fy ZCBzb2x1dGlvbi4NCj4+Pj4+Pj4+Pj4+DQo+Pj4+Pj4+Pj4+PiBUaGUgb25seSBjaGFuZ2UgaW4g dGhlIG5ldyB2ZXJzaW9uIG9mIHJmYzQ1ODNiaXMganVzdA0KPj4+Pj4+Pj4+Pj5zdWJtaXR0ZWQu DQo+Pj4+Pj4+Pj4+PiBBbmQgYXMgQ2hhcmxlcyBzYXlzLCB0aGlzIHNob3VsZCBiZSB0aGUgbGFz dCBtaXNzaW5nIGZpeCBmb3INCj4+Pj4+Pj4+Pj4+IHRoaXMgZHJhZnQgdW50aWwgbmV4dCBzdGFn ZXMgaW4gdGhlIHByb2Nlc3MgYXQgbGVhc3QuDQo+Pj4+Pj4+Pj4+Pg0KPj4+Pj4+Pj4+Pj4gLS0g VG9tDQo+Pj4+Pj4+Pj4+Pg0KPj4+Pj4+Pj4+Pj4gT24gMDkvMDgvMjAxNSAwNzo0OCBQTSwgQ2hh cmxlcyBFY2tlbCAoZWNrZWxjdSkgd3JvdGU6DQo+Pj4+Pj4+Pj4+Pg0KPj4+Pj4+Pj4+Pj4gICAg ICAgIA0KPj4+Pj4+Pj4+Pj4+IFBpY2tpbmcgdXAgb24gdGhpcyBvbGQgdGhyZWFkIHJlZ2FyZGlu Zw0KPj4+Pj4+Pj4+Pj4+IGRyYWZ0LWlldGYtYmZjcGJpcy1yZmM0NTgzYmlzLg0KPj4+Pj4+Pj4+ Pj4+IEkgdGhpbmsgdGhpcyBpcyB0aGUgb25seSBvdXRzdGFuZGluZyBpdGVtIHdpdGggcmVzcGVj dCB0bw0KPj4+Pj4+Pj4+Pj4+IHRoZSBjdXJyZW50ICB2ZXJzaW9uIG9mIHRoZSBkcmFmdC4gVW5s ZXNzIGFueW9uZSBoYXMgYW4NCj4+Pj4+Pj4+Pj4+PiBpc3N1ZSB3aXRoIHRoZSBwcm9wb3NlZCAg cmVzb2x1dGlvbiwgSSByZXF1ZXN0IHdlIHVwZGF0ZSB0aGUNCj4+Pj4+Pj4+Pj4+PiBkcmFmdCBh Y2NvcmRpbmdseSBhbmQgdGhlbiB1c2UgaXQgIGFzIHRoZSBiYXNpcyBmb3IgTWFyeSwNCj4+Pj4+ Pj4+Pj4+PiB0aGUgZG9jdW1lbnQgc2hlcGhlcmQsIHRvIHByb3ZpZGUgYSBwcm90byB3cml0ZXVw Lg0KPj4+Pj4+Pj4+Pj4+DQo+Pj4+Pj4+Pj4+Pj4gQ2hlZXJzLA0KPj4+Pj4+Pj4+Pj4+IENoYXJs ZXMNCj4+Pj4+Pj4+Pj4+Pg0KPj4+Pj4+Pj4+Pj4+DQo+Pj4+Pj4+Pj4+Pj4gT24gNC8yMC8xNSwg MTA6MzkgQU0sICJDaGFybGVzIEVja2VsDQo+Pj4+Pj4+Pj4+Pj4gKGVja2VsY3UpIjxlY2tlbGN1 QGNpc2NvLmNvbT4NCj4+Pj4+Pj4+Pj4+PiB3cm90ZToNCj4+Pj4+Pj4+Pj4+Pg0KPj4+Pj4+Pj4+ Pj4+DQo+Pj4+Pj4+Pj4+Pj4NCj4+Pj4+Pj4+Pj4+PiAgICAgICANCj4+Pj4+Pj4+Pj4+Pj4gSGkg Q2hyaXN0ZXIsDQo+Pj4+Pj4+Pj4+Pj4+DQo+Pj4+Pj4+Pj4+Pj4+IEkgcmVyZWFkIHRoZSBjdXJy ZW50IGRyYWZ0IGFuZCB3ZW50IHRocm91Z2ggdGhlIGZvbGxvd2luZw0KPj4+Pj4+Pj4+Pj4+PiBN TVVTSUMgdGhyZWFkIG9uIHRoaXMgc3ViamVjdDoNCj4+Pj4+Pj4+Pj4+Pj4gaHR0cDovL3d3dy5p ZXRmLm9yZy9tYWlsLWFyY2hpdmUvd2ViL21tdXNpYy9jdXJyZW50L21zZzE0NjMxLg0KPj4+Pj4+ Pj4+Pj4+PiBoDQo+Pj4+Pj4+Pj4+Pj4+IHQNCj4+Pj4+Pj4+Pj4+Pj4gbQ0KPj4+Pj4+Pj4+Pj4+ PiBsDQo+Pj4+Pj4+Pj4+Pj4+DQo+Pj4+Pj4+Pj4+Pj4+IEFzIGEgcmVzdWx0LCBJIGJldHRlciB1 bmRlcnN0YW5kIHRoZSBpc3N1ZSB5b3UgYXJlDQo+Pj4+Pj4+Pj4+Pj4+YWRkcmVzc2luZy4NCj4+ Pj4+Pj4+Pj4+Pj4gSSBzdWdnZXN0IHRoZSBmb2xsb3dpbmcgY2hhbmdlcyB0byBiZSBjb25zaXN0 ZW50IHdpdGggd2hhdA0KPj4+Pj4+Pj4+Pj4+PiBpcyBiZWluZyBwcm9wb3NlZCBpbg0KPj4+Pj4+ Pj4+Pj4+PiBNTVVTSUM6DQo+Pj4+Pj4+Pj4+Pj4+DQo+Pj4+Pj4+Pj4+Pj4+IC0tLS0tLS0tLS0t LQ0KPj4+Pj4+Pj4+Pj4+PiBTZWN0aW9uIDk6DQo+Pj4+Pj4+Pj4+Pj4+DQo+Pj4+Pj4+Pj4+Pj4+ IE9MRDoNCj4+Pj4+Pj4+Pj4+Pj4gRW5kcG9pbnRzIHRoYXQgdXNlIHRoZSBvZmZlci9hbnN3ZXIg bW9kZWwgdG8gZXN0YWJsaXNoIGEgRFRMUw0KPj4+Pj4+Pj4+Pj4+PiAgICAgIGFzc29jaWF0aW9u IE1VU1Qgc3VwcG9ydCB0aGUgJ3NldHVwJyBhdHRyaWJ1dGUsIGFzDQo+Pj4+Pj4+Pj4+Pj4+IGRl ZmluZWQgaW4gWzddLg0KPj4+Pj4+Pj4+Pj4+PiBXaGVuIERUTFMgaXMgdXNlZCB3aXRoIFVEUCwg dGhlICdzZXR1cCcgYXR0cmlidXRlIGluZGljYXRlcw0KPj4+Pj4+Pj4+Pj4+PiB3aGljaCBvZiB0 aGUgZW5kcG9pbnRzIChjbGllbnQgb3IgZmxvb3IgY29udHJvbCBzZXJ2ZXIpDQo+Pj4+Pj4+Pj4+ Pj4+IGluaXRpYXRlcyB0aGUgRFRMUyBhc3NvY2lhdGlvbiBzZXR1cC4gVGhlIHJlcXVpcmVtZW50 cyBmb3INCj4+Pj4+Pj4+Pj4+Pj4gdGhlIG9mZmVyL2Fuc3dlciBleGNoYW5nZSBzcGVjaWZpZWQg aW4gWzEzXSwgU2VjdGlvbiA1IG9mDQo+Pj4+Pj4+Pj4+Pj4+IFsxM10gTVVTVCBiZSBmb2xsb3dl ZCB3aGVuIHVzaW5nIERUTFMuDQo+Pj4+Pj4+Pj4+Pj4+IE9mZmVyL2Fuc3dlciBjb25zaWRlcmF0 aW9ucyBhcmUgZGVzY3JpYmVkIGluIFNlY3Rpb24gMTAuNS4NCj4+Pj4+Pj4+Pj4+Pj4NCj4+Pj4+ Pj4+Pj4+Pj4gTkVXOg0KPj4+Pj4+Pj4+Pj4+PiBXaGVuIERUTFMgaXMgdXNlZCB3aXRoIFVEUCwg dGhlIHJlcXVpcmVtZW50cyBzcGVjaWZpZWQgaW4NCj4+Pj4+Pj4+Pj4+Pj4gU2VjdGlvbg0KPj4+ Pj4+Pj4+Pj4+PiA1IG9mIFsxM10gTVVTVCBiZSBmb2xsb3dlZC4NCj4+Pj4+Pj4+Pj4+Pj4NCj4+ Pj4+Pj4+Pj4+Pj4NCj4+Pj4+Pj4+Pj4+Pj4gU2VjdGlvbiAxMC41DQo+Pj4+Pj4+Pj4+Pj4+DQo+ Pj4+Pj4+Pj4+Pj4+IE9MRA0KPj4+Pj4+Pj4+Pj4+PiAgICAgIElmIHRoZSB0cmFuc3BvcnQgcGFy YW1ldGVycyBvciB0aGUga2V5IGZpbmdlcnByaW50cw0KPj4+Pj4+Pj4+Pj4+PiBjaGFuZ2UsIHRo ZQ0KPj4+Pj4+Pj4+Pj4+PiAgICAgIGVuZHBvaW50cyBNVVNUIGVzdGFibGlzaCBhIG5ldyBEVExT IGNvbm5lY3Rpb24uICBJbg0KPj4+Pj4+Pj4+Pj4+PiBzdWNoIGNhc2UgdGhlDQo+Pj4+Pj4+Pj4+ Pj4+ICAgICAgJ2FjdGl2ZS9wYXNzaXZlJyBzdGF0dXMgb2YgdGhlIGVuZHBvaW50cyB3aWxsIGFn YWluIGJlDQo+Pj4+Pj4+Pj4+Pj4+IGRldGVybWluZWQNCj4+Pj4+Pj4+Pj4+Pj4gICAgICBmb2xs b3dpbmcgdGhlIHByb2NlZHVyZXMgaW4gWzddLCBhbmQgdGhlIG5ldyBzdGF0dXMNCj4+Pj4+Pj4+ Pj4+Pj4gd2lsbCBiZSB1c2VkIHRvDQo+Pj4+Pj4+Pj4+Pj4+ICAgICAgZGV0ZXJtaW5lIHRoZSBU TFMgcm9sZXMgYXNzb2NpYXRlZCB3aXRoIHRoZSBuZXcgRFRMUw0KPj4+Pj4+Pj4+Pj4+PiBjb25u ZWN0aW9uLg0KPj4+Pj4+Pj4+Pj4+Pg0KPj4+Pj4+Pj4+Pj4+PiAgICAgICAgIEluZm9ybWF0aW9u YWwgbm90ZTogVGhlIHByb2NlZHVyZSBhYm92ZSBpcw0KPj4+Pj4+Pj4+Pj4+PiBpZGVudGljYWwg dG8gdGhlIG9uZQ0KPj4+Pj4+Pj4+Pj4+PiAgICAgICAgIGRlZmluZWQgZm9yIERUTFMtU1JUUCBp biBbMTNdLg0KPj4+Pj4+Pj4+Pj4+Pg0KPj4+Pj4+Pj4+Pj4+PiAgICAgICAgIE5vdGU6IEEgbmV3 IERUTFMgY29ubmVjdGlvbiBuZWVkcyB0byBiZSBlc3RhYmxpc2hlZA0KPj4+Pj4+Pj4+Pj4+PiBp ZiB0aGUNCj4+Pj4+Pj4+Pj4+Pj4gICAgICAgICB0cmFuc3BvcnQgcGFyYW1ldGVycyBvciB0aGUg a2V5IGZpbmdlcnByaW50cyBjaGFuZ2UuDQo+Pj4+Pj4+Pj4+Pj4+DQo+Pj4+Pj4+Pj4+Pj4+DQo+ Pj4+Pj4+Pj4+Pj4+DQo+Pj4+Pj4+Pj4+Pj4+IE5FVzoNCj4+Pj4+Pj4+Pj4+Pj4gVGhlIGNvbmRp dGlvbnMgdW5kZXIgd2hpY2ggZW5kcG9pbnRzIE1VU1QgZXN0YWJsaXNoIGEgbmV3DQo+Pj4+Pj4+ Pj4+Pj4+IERUTFMgY29ubmVjdGlvbiBhcmUgYXMgdGhlIHNhbWUgZGVmaW5lZCBmb3IgRFRMUy1T UlRQIGluDQo+Pj4+Pj4+Pj4+Pj4+WzEzXS4NCj4+Pj4+Pj4+Pj4+Pj4g4oCU4oCU4oCU4oCU4oCU 4oCU4oCU4oCUDQo+Pj4+Pj4+Pj4+Pj4+DQo+Pj4+Pj4+Pj4+Pj4+IFRoaXMgd2F5IHdlIGF2b2lk IGFueSBwb3RlbnRpYWwgY29uZmxpY3RzIHdpdGggdGhlIGludGVudA0KPj4+Pj4+Pj4+Pj4+PiBv ZiBSRkMgNTc2MywgYW5kIHdoZW4gY2xhcmlmaWNhdGlvbnMgdG8gUkZDIDU3NjMgYXJlIG1hZGUs DQo+Pj4+Pj4+Pj4+Pj4+IHRoZXkgd2lsbCBiZSBwaWNrZWQgdXAgYnkgdGhlIEJGQ1Agc3BlYy4N Cj4+Pj4+Pj4+Pj4+Pj4NCj4+Pj4+Pj4+Pj4+Pj4gQ2hlZXJzLA0KPj4+Pj4+Pj4+Pj4+PiBDaGFy bGVzDQo+Pj4+Pj4+Pj4+Pj4+DQo+Pj4+Pj4+Pj4+Pj4+DQo+Pj4+Pj4+Pj4+Pj4+DQo+Pj4+Pj4+ Pj4+Pj4+DQo+Pj4+Pj4+Pj4+Pj4+IE9uIDQvMTgvMTUsIDI6MDEgUE0sICJDaHJpc3Rlcg0KPj4+ Pj4+Pj4+Pj4+PiBIb2xtYmVyZyI8Y2hyaXN0ZXIuaG9sbWJlcmdAZXJpY3Nzb24uY29tPg0KPj4+ Pj4+Pj4+Pj4+PiB3cm90ZToNCj4+Pj4+Pj4+Pj4+Pj4NCj4+Pj4+Pj4+Pj4+Pj4NCj4+Pj4+Pj4+ Pj4+Pj4NCj4+Pj4+Pj4+Pj4+Pj4gICAgICANCj4+Pj4+Pj4+Pj4+Pj4+IEhpIENoYXJsZXMsDQo+ Pj4+Pj4+Pj4+Pj4+Pg0KPj4+Pj4+Pj4+Pj4+Pj4NCj4+Pj4+Pj4+Pj4+Pj4+DQo+Pj4+Pj4+Pj4+ Pj4+PiAgICAgDQo+Pj4+Pj4+Pj4+Pj4+Pj4gW2FkZGluZyBiZmNwcGJpcyBsaXN0XQ0KPj4+Pj4+ Pj4+Pj4+Pj4+DQo+Pj4+Pj4+Pj4+Pj4+Pj4gSGkgQ2hyaXN0ZXIsDQo+Pj4+Pj4+Pj4+Pj4+Pj4N Cj4+Pj4+Pj4+Pj4+Pj4+PiBUaGFua3MgZm9yIHlvdXIgcmV2aWV3IGFuZCBjb21tZW50cy4gSW4g dGhlIEJGQ1AgdXNhZ2UsDQo+Pj4+Pj4+Pj4+Pj4+Pj4gdGhlIERUTFMgY29ubmVjdGlvbiBpcyBk ZWRpY2F0ZWQgdG8gdGhlIEJGQ1Agc3RyZWFtIGl0DQo+Pj4+Pj4+Pj4+Pj4+Pj5jb250YWlucy4N Cj4+Pj4+Pj4+Pj4+Pj4+PiBBcyBJIHVuZGVyc3RhbmQgaXQsIHRoZSBjb21wbGljYXRpb25zIGFy b3VuZCBEVExTDQo+Pj4+Pj4+Pj4+Pj4+Pj4gcmUtZXN0YWJsaXNoZW1lbnQgZGlzY3Vzc2VkIGlu IE1NVVNJQyByZXN1bHQgZnJvbSB1c2Ugb2YNCj4+Pj4+Pj4+Pj4+Pj4+PiBhIHNpbmdsZSBEVExT IGNvbm5lY3Rpb24gZm9yIG11bHRpcGxlIFJUUCBhbmQvb3IgU0NUUA0KPj4+Pj4+Pj4+Pj4+Pj4+ c3RyZWFtcy4NCj4+Pj4+Pj4+Pj4+Pj4+PiBUaG9zZSBjb21wbGljYXRpb25zIGRvIG5vdCBleGlz dCB3aXRoIHRoZSBCRkNQIHVzYWdlLCBzbw0KPj4+Pj4+Pj4+Pj4+Pj4+IEkgdGhpbmsgaXQgaXMg c3VmZmljaWVudCB0byBjb250aW51ZSB0byByZWZlcmVuY2UgUkZDDQo+Pj4+Pj4+Pj4+Pj4+Pj4g NTc2MyBhbmQgbm90IHVzZSB0aGUgU0RQIGNvbm5lY3Rpb24gYXR0cmlidXRlLg0KPj4+Pj4+Pj4+ Pj4+Pj4+DQo+Pj4+Pj4+Pj4+Pj4+Pj4NCj4+Pj4+Pj4+Pj4+Pj4+PiAgICANCj4+Pj4+Pj4+Pj4+ Pj4+IFRoZSBjb21wbGljYXRpb25zIGRvIG5vdCByZXN1bHQgZnJvbSB1c2Ugb2YgYSBzaW5nbGUg RFRMUw0KPj4+Pj4+Pj4+Pj4+Pj4gY29ubmVjdGlvbiBmb3IgbXVsdGlwbGUgc3RyZWFtcyAtIGl0 IG1haW5seSByZXN1bHRzIGZyb20NCj4+Pj4+Pj4+Pj4+Pj4+IHRoZSB1c2FnZSBvZiBJQ0UuIEFu ZCwgYXMgZmFyIGFzIEkga25vdywgSUNFIGNhbiBiZSB1c2VkDQo+Pj4+Pj4+Pj4+Pj4+PiBhbHNv IGZvciBCRkNQLg0KPj4+Pj4+Pj4+Pj4+Pj4NCj4+Pj4+Pj4+Pj4+Pj4+IEFuZCwgZXZlbiB3aXRo b3V0IElDRSB3ZSBpbnRlbmQgdG8gYWRkIHRleHQgc2F5aW5nIHRoYXQgYQ0KPj4+Pj4+Pj4+Pj4+ Pj4gRFRMUyBjb25uZWN0aW9uIGlzIG9ubHkgcmUtZXN0YWJsaXNoZWQgaWYgdGhlIHVuZGVybHlp bmcNCj4+Pj4+Pj4+Pj4+Pj4+IHRyYW5zcG9ydCBjaGFuZ2VzLg0KPj4+Pj4+Pj4+Pj4+Pj4NCj4+ Pj4+Pj4+Pj4+Pj4+IFJlZ2FyZHMsDQo+Pj4+Pj4+Pj4+Pj4+Pg0KPj4+Pj4+Pj4+Pj4+Pj4gQ2hy aXN0ZXINCj4+Pj4+Pj4+Pj4+Pj4+DQo+Pj4+Pj4+Pj4+Pj4+Pg0KPj4+Pj4+Pj4+Pj4+Pj4NCj4+ Pj4+Pj4+Pj4+Pj4+DQo+Pj4+Pj4+Pj4+Pj4+Pg0KPj4+Pj4+Pj4+Pj4+Pj4gICAgIA0KPj4+Pj4+ Pj4+Pj4+Pj4+IEhpLA0KPj4+Pj4+Pj4+Pj4+Pj4+DQo+Pj4+Pj4+Pj4+Pj4+Pj4gRmlyc3QsIEkg d2FudCB0byBhcG9sb2dpemUgZm9yIG5vdCBwcm92aWRpbmcgbXkgcmV2aWV3DQo+Pj4+Pj4+Pj4+ Pj4+Pj4gZWFybGllci4NCj4+Pj4+Pj4+Pj4+Pj4+Pg0KPj4+Pj4+Pj4+Pj4+Pj4+IEFzIGZhciBh cyB0aGUgQkZDUCBzcGVjaWZpY3MgYXJlIGNvbmNlcm5lZCwgSSBhbSBvayB3aXRoDQo+Pj4+Pj4+ Pj4+Pj4+Pj4gdGhlIGxhdGVzdCB2ZXJzaW9uIG9mIHRoZSBkcmFmdC4NCj4+Pj4+Pj4+Pj4+Pj4+ Pg0KPj4+Pj4+Pj4+Pj4+Pj4+IEhvd2V2ZXIsIHRoZXJlIGlzIGFuIGlzc3VlIHJlZ2FyZGluZyB0 aGUgRFRMUw0KPj4+Pj4+Pj4+Pj4+Pj4+IGNvbnNpZGVyYXRpb25zIChzZWN0aW9uIDEwLjUpLg0K Pj4+Pj4+Pj4+Pj4+Pj4+DQo+Pj4+Pj4+Pj4+Pj4+Pj4gVGhlIHRleHQgc2F5czoNCj4+Pj4+Pj4+ Pj4+Pj4+Pg0KPj4+Pj4+Pj4+Pj4+Pj4+IAkiT25jZSBhIERUTFMgY29ubmVjdGlvbiBoYXMgYmVl biBlc3RhYmxpc2hlZCwgaWYgdGhlDQo+Pj4+Pj4+Pj4+Pj4+Pj4gJ2FjdGl2ZS9wYXNzaXZlJw0K Pj4+Pj4+Pj4+Pj4+Pj4+ICAgICAgCXN0YXR1cyBvZiB0aGUgZW5kcG9pbnRzIGNoYW5nZSBkdXJp bmcgYSBzZXNzaW9uLCBhDQo+Pj4+Pj4+Pj4+Pj4+Pj4gbmV3IERUTFMNCj4+Pj4+Pj4+Pj4+Pj4+ PiAgICAgIAljb25uZWN0aW9uIE1VU1QgYmUgZXN0YWJsaXNoZWQuIg0KPj4+Pj4+Pj4+Pj4+Pj4+ DQo+Pj4+Pj4+Pj4+Pj4+Pj4gVGhlcmUgaXMgY3VycmVudGx5IGFuIG9uZ29pbmcgZGlzY3Vzc2lv biBpbiBNTVVTSUMgYWJvdXQNCj4+Pj4+Pj4+Pj4+Pj4+PiB3aGVuIGEgRFRMUyBjb25uZWN0aW9u IGlzIHRvIGJlIHJlLWVzdGFibGlzaGVkLg0KPj4+Pj4+Pj4+Pj4+Pj4+DQo+Pj4+Pj4+Pj4+Pj4+ Pj4gVGhlIGRpc2N1c3Npb24gaXMgc3RpbGwgb25nb2luZywgYnV0IHRoZSBvdXRjb21lIHdpbGwN Cj4+Pj4+Pj4+Pj4+Pj4+PiBtb3N0IGxpa2VseSBOT1QgYmUgYWxpZ25lZCB3aXRoIHRoZSB0ZXh0 IGFib3ZlLg0KPj4+Pj4+Pj4+Pj4+Pj4+DQo+Pj4+Pj4+Pj4+Pj4+Pj4gRm9yIGV4YW1wbGUsIHRo ZXJlIGhhcyBiZWVuIGEgc3VnZ2VzdGlvbiAoYnkgbXlzZWxmKSB0bw0KPj4+Pj4+Pj4+Pj4+Pj4+ IHVzZSB0aGUgU0RQIGNvbm5lY3Rpb24gYXR0cmlidXRlIHRvIGV4cGxpY2l0bHkgaW5kaWNhdGUN Cj4+Pj4+Pj4+Pj4+Pj4+PiB0aGF0IGEgbmV3IERUTFMgY29ubmVjdGlvbiBuZWVkcyB0byBiZSBl c3RhYmxpc2hlZC4NCj4+Pj4+Pj4+Pj4+Pj4+Pg0KPj4+Pj4+Pj4+Pj4+Pj4+DQo+Pj4+Pj4+Pj4+ Pj4+Pj4gVGhlIGRyYWZ0IGFsc28gc2F5czoNCj4+Pj4+Pj4+Pj4+Pj4+Pg0KPj4+Pj4+Pj4+Pj4+ Pj4+IAkiSWYgdGhlIHRyYW5zcG9ydCBwYXJhbWV0ZXJzIG9yIHRoZSBrZXkgZmluZ2VycHJpbnRz DQo+Pj4+Pj4+Pj4+Pj4+Pj4gY2hhbmdlLCB0aGUNCj4+Pj4+Pj4+Pj4+Pj4+PiAgICAgIAllbmRw b2ludHMgTVVTVCBlc3RhYmxpc2ggYSBuZXcgRFRMUyBjb25uZWN0aW9uLiINCj4+Pj4+Pj4+Pj4+ Pj4+Pg0KPj4+Pj4+Pj4+Pj4+Pj4+IFRoaXMgaXMgcmVsYXRlZCB0byB0aGUgZWFybGllciBpc3N1 ZS4gVGhlcmUgaXMgdGhlDQo+Pj4+Pj4+Pj4+Pj4+Pj4gZGlzY3Vzc2lvbiBhYm91dCBJQ0UgInZp cnR1YWwgY29ubmVjdGlvbnMiLCBhbmQgdGhhdCBhDQo+Pj4+Pj4+Pj4+Pj4+Pj4gc2luZ2xlIERU TFMgY29ubmVjdGlvbiB3b3VsZCBhcHBseSB0byBhbGwgSUNFIGNhbmRpZGF0ZXMNCj4+Pj4+Pj4+ Pj4+Pj4+PiBhc3NvY2lhdGVkIHdpdGggYW4NCj4+Pj4+Pj4+Pj4+Pj4+PiBtLSBsaW5lLiBTbywg ZXZlbiBpZiBhIGNhbmRpZGF0ZSBjaGFuZ2VzIChyZWFkOiB0cmFuc3BvcnQNCj4+Pj4+Pj4+Pj4+ Pj4+PiBwYXJhbWV0ZXIgY2hhbmdlcyksIGl0IHdvdWxkIG5vdCBhdXRvbWF0aWNhbGx5IHRyaWdn ZXIgYQ0KPj4+Pj4+Pj4+Pj4+Pj4+IG5ldyBEVExTIGNvbm5lY3Rpb24uDQo+Pj4+Pj4+Pj4+Pj4+ Pj4NCj4+Pj4+Pj4+Pj4+Pj4+Pg0KPj4+Pj4+Pj4+Pj4+Pj4+IFRoZSBpc3N1ZXMgYWJvdmUgYXJl IGFsc28gaG9sZGluZyB1cCB0aGUgU0NUUC1TRFAgZHJhZnQsDQo+Pj4+Pj4+Pj4+Pj4+Pj4gc28g aXQgZG9lc24ndCBvbmx5IGFmZmVjdCBCRkNQYmlzIDopDQo+Pj4+Pj4+Pj4+Pj4+Pj4NCj4+Pj4+ Pj4+Pj4+Pj4+Pg0KPj4+Pj4+Pj4+Pj4+Pj4+IFJlZ2FyZHMsDQo+Pj4+Pj4+Pj4+Pj4+Pj4NCj4+ Pj4+Pj4+Pj4+Pj4+PiBDaHJpc3Rlcg0KPj4+Pj4+Pj4+Pj4+Pj4+DQo+Pj4+Pj4+Pj4+Pj4+Pj4N Cj4+Pj4+Pj4+Pj4+Pj4+PiAtLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KPj4+Pj4+Pj4+Pj4+ Pj4+IEZyb206IEFsaXNzYSBDb29wZXIgW21haWx0bzphbGlzc2FAY29vcGVydy5pbl0NCj4+Pj4+ Pj4+Pj4+Pj4+PiBTZW50OiA4LiBodWh0aWt1dXRhIDIwMTUgMzowNw0KPj4+Pj4+Pj4+Pj4+Pj4+ IFRvOiBDaGFybGVzIEVja2VsIChlY2tlbGN1KQ0KPj4+Pj4+Pj4+Pj4+Pj4+IENjOiBHb256YWxv IENhbWFyaWxsbzsgVG9tIEtyaXN0ZW5zZW4gKHRvbWtyaXN0KTsNCj4+Pj4+Pj4+Pj4+Pj4+PiBk cmFmdC1pZXRmLWJmY3BiaXMtcmZjNDU4MmJpc0B0b29scy5pZXRmLm9yZzsgQmVuDQo+Pj4+Pj4+ Pj4+Pj4+Pj4gQ2FtcGJlbGw7IENocmlzdGVyIEhvbG1iZXJnDQo+Pj4+Pj4+Pj4+Pj4+Pj4gU3Vi amVjdDogUmU6IGRyYWZ0LWlldGYtYmZjcGJpcy1yZmM0NTgzYmlzDQo+Pj4+Pj4+Pj4+Pj4+Pj4N Cj4+Pj4+Pj4+Pj4+Pj4+PiBBZGRpbmcgQ2hyaXN0ZXIgdG8gdGhpcyB0aHJlYWQuDQo+Pj4+Pj4+ Pj4+Pj4+Pj4NCj4+Pj4+Pj4+Pj4+Pj4+PiBPbiBBcHIgNywgMjAxNSwgYXQgMTI6NDQgUE0sIENo YXJsZXMgRWNrZWwgKGVja2VsY3UpDQo+Pj4+Pj4+Pj4+Pj4+Pj4gPGVja2VsY3VAY2lzY28uY29t Pg0KPj4+Pj4+Pj4+Pj4+Pj4+IHdyb3RlOg0KPj4+Pj4+Pj4+Pj4+Pj4+DQo+Pj4+Pj4+Pj4+Pj4+ Pj4NCj4+Pj4+Pj4+Pj4+Pj4+Pg0KPj4+Pj4+Pj4+Pj4+Pj4+ICAgIA0KPj4+Pj4+Pj4+Pj4+Pj4+ PiBDaHJpc3RlciAoY2PigJlkKSBhbmQgSSBkaXNjdXNzZWQgc29tZSBvZiB0aGUgY2hhbmdlcw0K Pj4+Pj4+Pj4+Pj4+Pj4+PiBvZmZsaXN0IGluIERhbGxhcywgYW5kIGhlIGlzIHRvIGNvbWUgYmFj ayB0byB0aGUgbGlzdA0KPj4+Pj4+Pj4+Pj4+Pj4+PiB3aXRoIGNvbW1lbnRzIGFmdGVyIERhbGxh cw0KPj4+Pj4+Pj4+Pj4+Pj4+PiAtIHdoaWNoIGlzIG5vdyA6KQ0KPj4+Pj4+Pj4+Pj4+Pj4+Pg0K Pj4+Pj4+Pj4+Pj4+Pj4+PiBDaGVlcnMsDQo+Pj4+Pj4+Pj4+Pj4+Pj4+IENoYXJsZXMNCj4+Pj4+ Pj4+Pj4+Pj4+Pj4NCj4+Pj4+Pj4+Pj4+Pj4+Pj4gT24gNC83LzE1LCAxMDoyNiBBTSwgIkFsaXNz YSBDb29wZXIiPGFsaXNzYUBjb29wZXJ3LmluPg0KPj4+Pj4+Pj4+Pj4+Pj4+PiB3cm90ZToNCj4+ Pj4+Pj4+Pj4+Pj4+Pj4NCj4+Pj4+Pj4+Pj4+Pj4+Pj4NCj4+Pj4+Pj4+Pj4+Pj4+Pj4NCj4+Pj4+ Pj4+Pj4+Pj4+Pj4gICANCj4+Pj4+Pj4+Pj4+Pj4+Pj4+IENoZWNraW5nIGluIG9uIHRoaXMg4oCU IGhhcyBDaHJpc3RlciBiZWVuIHByb21wdGVkIHRvDQo+Pj4+Pj4+Pj4+Pj4+Pj4+PiByZXZpZXcg dGhlIGxhdGVzdCByZXYgb2YgZHJhZnQtaWV0Zi1iZmNwYmlzLXJmYzQ1ODNiaXM/DQo+Pj4+Pj4+ Pj4+Pj4+Pj4+Pg0KPj4+Pj4+Pj4+Pj4+Pj4+Pj4gVGhhbmtzLA0KPj4+Pj4+Pj4+Pj4+Pj4+Pj4g QWxpc3NhDQo+Pj4+Pj4+Pj4+Pj4+Pj4+Pg0KPj4+Pj4+Pj4+Pj4+Pj4+Pj4gT24gRmViIDI1LCAy MDE1LCBhdCA5OjE0IEFNLCBDaGFybGVzIEVja2VsIChlY2tlbGN1KQ0KPj4+Pj4+Pj4+Pj4+Pj4+ Pj4gPGVja2VsY3VAY2lzY28uY29tPg0KPj4+Pj4+Pj4+Pj4+Pj4+Pj4gd3JvdGU6DQo+Pj4+Pj4+ Pj4+Pj4+Pj4+Pg0KPj4+Pj4+Pj4+Pj4+Pj4+Pj4NCj4+Pj4+Pj4+Pj4+Pj4+Pj4+DQo+Pj4+Pj4+ Pj4+Pj4+Pj4+PiAgDQo+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4gTW9zdCBvZiB0aGUgY2hhbmdlcyBJIHRo aXMgcmVjZW50IHVwZGF0ZSB0byByZmM0NTgzYmlzDQo+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4gd2VyZSBp bnNwaXJlZCBieSBjb21tZW50cyBhbmQgc3VnZ2VzdGVkIHRleHQgcHJvdmlkZWQNCj4+Pj4+Pj4+ Pj4+Pj4+Pj4+PiBieSBDaHJpc3Rlci4NCj4+Pj4+Pj4+Pj4+Pj4+Pj4+PiBIZSBpcyBpbiB0aGUg cHJvY2VzcyBvZiByZXZpZXdpbmcuIElmIGFsbCBnb2VzIHdlbGwNCj4+Pj4+Pj4+Pj4+Pj4+Pj4+ PiB3aXRoIHRoYXQsIHdlIGFyZSByZWFkeSB0byBwcm9jZWVkIHdpdGggcHJvdG8gd3JpdGV1cA0K Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+IChNYXJ5KSBhbmQgQUQgcmV2aWV3Lg0KPj4+Pj4+Pj4+Pj4+Pj4+ Pj4+DQo+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4gQ2hlZXJzLA0KPj4+Pj4+Pj4+Pj4+Pj4+Pj4+IENoYXJs ZXMNCj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pg0KPj4+Pj4+Pj4+Pj4+Pj4+Pj4+IE9uIDIvMjUvMTUsIDc6 MDEgQU0sICJBbGlzc2ENCj4+Pj4+Pj4+Pj4+Pj4+Pj4+PiBDb29wZXIiPGFsaXNzYUBjb29wZXJ3 LmluPg0KPj4+Pj4+Pj4+Pj4+Pj4+Pj4+IHdyb3RlOg0KPj4+Pj4+Pj4+Pj4+Pj4+Pj4+DQo+Pj4+ Pj4+Pj4+Pj4+Pj4+Pj4NCj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pg0KPj4+Pj4+Pj4+Pj4+Pj4+Pj4+IA0K Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+PiByZmM0NTgzIGhhcyBub3QgaGFkIGFuIEFEIHJldmlldyB5ZXQu IFJpY2hhcmQgY2FuDQo+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+IGhvcGVmdWxseSB0YWtlIGNhcmUgb2Yg dGhhdCB3aGlsZSBJwrltIG9uIGxlYXZlDQo+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+IChzdGFydGluZyB0 b2RheSwgYWN0dWFsbHkpLg0KPj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pg0KPj4+Pj4+Pj4+Pj4+Pj4+Pj4+ PiBPbiBGZWIgMjUsIDIwMTUsIGF0IDI6NTYgQU0sIEdvbnphbG8gQ2FtYXJpbGxvDQo+Pj4+Pj4+ Pj4+Pj4+Pj4+Pj4+IDxnb256YWxvLmNhbWFyaWxsb0Blcmljc3Nvbi5jb20+ICAgIHdyb3RlOg0K Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pg0KPj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pg0KPj4+Pj4+Pj4+Pj4+Pj4+ Pj4+Pg0KPj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pg0KPj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4gSGkgQWxpc3Nh LA0KPj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4NCj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+IEkgaGF2ZSBub3Rl ZCB0aGF0IHdoaWxlIHJmYzQ1ODJiaXMgaW4gb24gdGhlIGFnZW5kYQ0KPj4+Pj4+Pj4+Pj4+Pj4+ Pj4+Pj4gb2YgdGhlIE1hcmNoIDV0aCB0ZWxlY2hhdCAodGhhbmtzIGZvciBoYW5kbGluZw0KPj4+ Pj4+Pj4+Pj4+Pj4+Pj4+Pj4gdGhhdCEpLCByZmM0NTgzYmlzIGlzbid0LiBUb20gcmV2aXNlZCBy ZmM0NTgzYmlzIG9uDQo+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+PiBGZWJydWFyeSAyMHRoLiBTaG91bGQg cmZjNDU4M2JpcyBiZSBvbiB0aGUgYWdlbmRhIG9mDQo+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+PiB0aGUg dGVsZWNoYXQgYXMgd2VsbCBvciB0aGVyZSBpcyBzdGlsbCBzb21ldGhpbmcNCj4+Pj4+Pj4+Pj4+ Pj4+Pj4+Pj4+IGxlZnQgZm9yIFRvbSB0byB0YWtlIGNhcmUgb2Y/DQo+Pj4+Pj4+Pj4+Pj4+Pj4+ Pj4+Pg0KPj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4gVGhhbmtzLA0KPj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4N Cj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+IEdvbnphbG8NCj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+DQo+Pj4+ Pj4+Pj4+Pj4+Pj4+Pj4+PiBPbiAxOC8wMi8yMDE1IDk6MjggUE0sIEFsaXNzYSBDb29wZXIgd3Jv dGU6DQo+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pg0KPj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4NCj4+Pj4+Pj4+ Pj4+Pj4+Pj4+Pj4+DQo+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4gUGluZ2luZyBvbiB0aGlzLg0KPj4+ Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+DQo+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4gTWFyY2ggNSB3aWxsIGxp a2VseSBiZSBteSBsYXN0IHRlbGVjaGF0IGJlZm9yZQ0KPj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+IGdv aW5nIG9uIGxlYXZlLCBzbyAgaXQgd291bGQgYmUgZ3JlYXQgdG8gZ2V0IHRoaXMNCj4+Pj4+Pj4+ Pj4+Pj4+Pj4+Pj4+PiBzY2hlZHVsZWQgb24gdGhhdCBvbmUuIFRvIGRvIHRoYXQsICB0aGUgcmV2 IG5lZWRzDQo+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4gdG8gYmUgcG9zdGVkIHRvZGF5Lg0KPj4+Pj4+ Pj4+Pj4+Pj4+Pj4+Pj4+IFRoZSB1cGRhdGVzIGFyZSBwcmV0dHkgbWluaW1hbCAgYW5kIGFyZSBh bGwNCj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+PiBiYXNpY2FsbHkgd3JpdHRlbiB1cCBpbiBDaGFybGVz wrkgcmVzcG9uc2UgdG8gbXkgQUQgcmV2aWV3Lg0KPj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+DQo+Pj4+ Pj4+Pj4+Pj4+Pj4+Pj4+Pj4gQWxpc3NhDQo+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4NCj4+Pj4+Pj4+ Pj4+Pj4+Pj4+Pj4+PiBPbiBGZWIgMTUsIDIwMTUsIGF0IDk6MTMgQU0sIEdvbnphbG8gQ2FtYXJp bGxvDQo+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4gPGdvbnphbG8uY2FtYXJpbGxvQGVyaWNzc29uLmNv bQ0KPj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+IDxtYWlsdG86Z29uemFsby5jYW1hcmlsbG9AZXJpY3Nz b24uY29tPj4NCj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+PiB3cm90ZToNCj4+Pj4+Pj4+Pj4+Pj4+Pj4+ Pj4+Pg0KPj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+DQo+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4NCj4+Pj4+ Pj4+Pj4+Pj4+Pj4+Pj4+Pg0KPj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+PiBJIGhhdmUgdGFsa2VkIG9m ZmxpbmUgd2l0aCB0aGUgb3RoZXIgYXV0aG9ycyBhbmQNCj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4g VG9tIGlzIGhvbGRpbmcgdGhlIHBlbi4gVG9tLCBkbyB5b3UgdGhpbmsgeW91IGNhbg0KPj4+Pj4+ Pj4+Pj4+Pj4+Pj4+Pj4+PiBtZWV0IHRoZSB0aW1lIGZyYW1lIGJlbG93Pw0KPj4+Pj4+Pj4+Pj4+ Pj4+Pj4+Pj4+Pg0KPj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+PiBDaGVlcnMsDQo+Pj4+Pj4+Pj4+Pj4+ Pj4+Pj4+Pj4+DQo+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+IEdvbnphbG8NCj4+Pj4+Pj4+Pj4+Pj4+ Pj4+Pj4+Pj4NCj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4gU2VudCBmcm9tIG15IG1vYmlsZQ0KPj4+ Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pg0KPj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pg0KPj4+Pj4+Pj4+Pj4+ Pj4+Pj4+Pj4+Pg0KPj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+PiAtLS0tIEFsaXNzYSBDb29wZXIgd3Jv dGUgLS0tLQ0KPj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pg0KPj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+PiBK dXN0IHdhbnRlZCB0byBzZWUgaWYgdGhpcyByZXYgbWlnaHQgZ2V0IGRvbmUgaW4NCj4+Pj4+Pj4+ Pj4+Pj4+Pj4+Pj4+Pj4gdGhlIG5leHQgY291cGxlICBvZiBkYXlzLiBJZiBzbywgd2UgY291bGQg Z2V0IGl0DQo+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+IG9uIHRoZSBuZXh0IHRlbGVjaGF0IGFnZW5k YSAoTWFyY2ggNSkuDQo+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+DQo+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+ Pj4+IEFsaXNzYQ0KPj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pg0KPj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+ PiBCZWdpbiBmb3J3YXJkZWQgbWVzc2FnZToNCj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4NCj4+Pj4+ Pj4+Pj4+Pj4+Pj4+Pj4+Pj4NCj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4NCj4+Pj4+Pj4+Pj4+Pj4+ Pj4+Pj4+Pj4NCj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+ICpGcm9tOiAqQWxpc3NhIENvb3Blcjxh bGlzc2FAY29vcGVydy5pbg0KPj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4gPG1haWx0bzphbGlzc2FA Y29vcGVydy5pbj4+DQo+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+PiAqU3ViamVjdDogKipSZTogW2Jm Y3BiaXNdIEFEIGV2YWx1YXRpb246DQo+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+PiBkcmFmdC1pZXRm LWJmY3BiaXMtcmZjNDU4MmJpcy0xMioNCj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+ICpEYXRlOiAq RmVicnVhcnkgOSwgMjAxNSBhdCAzOjU4OjUyIFBNIFBTVA0KPj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+ Pj4gKlRvOiAqIkNoYXJsZXMgRWNrZWwgKGVja2VsY3UpIjxlY2tlbGN1QGNpc2NvLmNvbQ0KPj4+ Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4gPG1haWx0bzplY2tlbGN1QGNpc2NvLmNvbT4+DQo+Pj4+Pj4+ Pj4+Pj4+Pj4+Pj4+Pj4+PiAqQ2M6ICoiYmZjcGJpc0BpZXRmLm9yZzxtYWlsdG86YmZjcGJpc0Bp ZXRmLm9yZz4iDQo+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+PiA8YmZjcGJpc0BpZXRmLm9yZyA8bWFp bHRvOmJmY3BiaXNAaWV0Zi5vcmc+Pg0KPj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4NCj4+Pj4+Pj4+ Pj4+Pj4+Pj4+Pj4+Pj4+IEhpIENoYXJsZXMsDQo+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pg0KPj4+ Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4gVGhhbmtzLCBzb21lIHJlc3BvbnNlcyBpbmxpbmUuDQo+Pj4+ Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pg0KPj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4gT24gRmViIDQsIDIw MTUsIGF0IDEwOjQwIEFNLCBDaGFybGVzIEVja2VsIChlY2tlbGN1KQ0KPj4+Pj4+Pj4+Pj4+Pj4+ Pj4+Pj4+Pj4gPGVja2VsY3VAY2lzY28uY29tPG1haWx0bzplY2tlbGN1QGNpc2NvLmNvbT4+ICAg IHdyb3RlOg0KPj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4NCj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+ DQo+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pg0KPj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4NCj4+Pj4+ Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+PiBISSBBbGlzc2EsDQo+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4N Cj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+PiBUaGFuayB5b3UgZm9yIHRoZSByZXZpZXcuIFBsZWFz ZSBzZWUgbXkgdGhvdWdodHMNCj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+PiBvbiB5b3VyIGNvbW1l bnRzIGFuZCBxdWVzdGlvbnMgaW5saW5lLg0KPj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+DQo+Pj4+ Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4gRnJvbTogQWxpc3NhIENvb3BlcjxhbGlzc2FAY29vcGVydy5p bg0KPj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+IDxtYWlsdG86YWxpc3NhQGNvb3BlcncuaW4+Pg0K Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+IERhdGU6IFRodXJzZGF5LCBKYW51YXJ5IDI5LCAyMDE1 IGF0IDEwOjE5IFBNDQo+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4gVG86ICJiZmNwYmlzQGlldGYu b3JnPG1haWx0bzpiZmNwYmlzQGlldGYub3JnPiINCj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+PiA8 YmZjcGJpc0BpZXRmLm9yZzxtYWlsdG86YmZjcGJpc0BpZXRmLm9yZz4+DQo+Pj4+Pj4+Pj4+Pj4+ Pj4+Pj4+Pj4+Pj4gU3ViamVjdDogW2JmY3BiaXNdIEFEIGV2YWx1YXRpb246DQo+Pj4+Pj4+Pj4+ Pj4+Pj4+Pj4+Pj4+Pj4gZHJhZnQtaWV0Zi1iZmNwYmlzLXJmYzQ1ODJiaXMtMTINCj4+Pj4+Pj4+ Pj4+Pj4+Pj4+Pj4+Pj4+Pg0KPj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+DQo+Pj4+Pj4+Pj4+Pj4+ Pj4+Pj4+Pj4+Pj4NCj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pg0KPj4+Pj4+Pj4+Pj4+Pj4+Pj4+ Pj4+Pj4+PiBJIGhhdmUgcmV2aWV3ZWQgdGhpcyBkcmFmdCBpbiBwcmVwYXJhdGlvbiBmb3IgSUVU RiBMQy4NCj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4gT3ZlcmFsbCB0aGUgZG9jdW1lbnQgYXBw ZWFycyBpbiBnb29kIHNoYXBlLiBJDQo+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+IGhhdmUgYSBm ZXcgcXVlc3Rpb25zIGFuZCBjb21tZW50cyBJwrlkIGxpa2UgdG8NCj4+Pj4+Pj4+Pj4+Pj4+Pj4+ Pj4+Pj4+Pj4gZGlzY3VzcyBiZWZvcmUgaXNzdWluZyB0aGUgSUVURiBsYXN0IGNhbGwuIEnCuXZl DQo+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+IGFsc28gaW5jbHVkZWQgc29tZSBlZGl0b3JpYWwg bml0cyB0aGF0IHNob3VsZA0KPj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+PiBiZSBhZGRyZXNzZWQg dG9nZXRoZXIgd2l0aCBhbnkgbGFzdCBjYWxsIGNvbW1lbnRzLg0KPj4+Pj4+Pj4+Pj4+Pj4+Pj4+ Pj4+Pj4+Pg0KPj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+PiBDb21tZW50cyBhbmQgcXVlc3Rpb25z Og0KPj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pg0KPj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+PiA9 IFNlY3Rpb24gNS4xID0gIklmIGFuIGVuZHBvaW50IHJlY2VpdmVzIGENCj4+Pj4+Pj4+Pj4+Pj4+ Pj4+Pj4+Pj4+Pj4gbWVzc2FnZSB3aXRoIGFuIHVuc3VwcG9ydGVkIHZlcnNpb24gZmllbGQNCj4+ Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4gdmFsdWUsIHRoZSByZWNlaXZpbmcgc2VydmVyIE1VU1Qg c2VuZCBhbiBFcnJvcg0KPj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+PiBtZXNzYWdlIHdpdGggcGFy YW1ldGVyIHZhbHVlIDEyIChVbnN1cHBvcnRlZA0KPj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+PiBW ZXJzaW9uKSB0byBpbmRpY2F0ZSB0aGlzLsKyDQo+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+DQo+ Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+IFRoaXMgc2VlbXMgYSBsaXR0bGUgbWlzbGVhZGluZyBz aW5jZSBSRkMgNDU4Mg0KPj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+PiBkaWRuwrl0IHNwZWNpZnkg d2hhdCB0byBkbyB1cG9uIHJlY2VpcHQgb2YgYQ0KPj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+PiBt ZXNzYWdlIHdpdGggYSB2ZXJzaW9uIG90aGVyIHRoYW4gMS4NCj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+ Pj4+Pj4gSW1wbGVtZW50YXRpb25zIHRoYXQgZG8gbm90IGdldCB1cGdyYWRlZCB0byBiZQ0KPj4+ Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+PiBjb21wbGlhbnQgd2l0aCAgNDU4MmJpcyAod2hpY2ggY291 bGQgY2VydGFpbmx5DQo+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+IGFjY291bnQgZm9yIHNvbWUg b2YgdGhvc2UgdGhhdCAgd2lsbCBub3QNCj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4gc3VwcG9y dCB2ZXJzaW9uIDIpIHdpbGwgdGhlcmVmb3JlIG5ldmVyIHNlbmQNCj4+Pj4+Pj4+Pj4+Pj4+Pj4+ Pj4+Pj4+Pj4gdGhlICBlcnJvciBzcGVjaWZpZWQgaGVyZS4NCj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+ Pj4+Pj4gVGhpcyBzZWVtcyBsaWtlIGl0IHNob3VsZCBhdCBsZWFzdCBiZSAgbm90ZWQNCj4+Pj4+ Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4gZ2l2ZW4gdGhlIE1VU1QtbGV2ZWwgcmVxdWlyZW1lbnQuIFRo ZSBzYW1lDQo+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+IGFwcGxpZXMgaW4gU2VjdGlvbiAxMy43 Lg0KPj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pg0KPj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pg0K Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pg0KPj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+IEdvb2Qg cG9pbnQuIEkgYmVsaWV2ZSB3ZSBtYWRlIHRoaXMgYSBNVVNUDQo+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+ Pj4+Pj4gYmVjYXVzZSB3ZSB3ZXJlIHRoaW5raW5nIGluIHRlcm1zIG9mDQo+Pj4+Pj4+Pj4+Pj4+ Pj4+Pj4+Pj4+Pj4gaW1wbGVtZW50YXRpb25zIGNvbXBsaWFudCB3aXRoIHRoaXMgYmlzIHZlcnNp b24uDQo+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4gQWRkaW5nDQo+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+ Pj4+Pj4geW91ciBzdWdnZXN0ZWQgbm90ZSBhYm91dCByZmMgNDU4Mg0KPj4+Pj4+Pj4+Pj4+Pj4+ Pj4+Pj4+Pj4+IGltcGxlbWVudGF0aW9ucyBoZXJlIGFuZCBpbiAgc2VjdGlvbiAxMy43IHNlZW1z IHVzZWZ1bA0KdG8gbWUuDQo+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4NCj4+Pj4+Pj4+Pj4+Pj4+ Pj4+Pj4+Pj4+Pg0KPj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+DQo+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+ Pj4+PiBPaw0KPj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4NCj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+ DQo+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pg0KPj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4NCj4+Pj4+ Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pg0KPj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+DQo+Pj4+Pj4+Pj4+ Pj4+Pj4+Pj4+Pj4+Pj4+ID0gU2VjdGlvbiA3ID0NCj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4g IkJGQ1AgZW50aXRpZXMgTVVTVCBzdXBwb3J0LCBhdCBhIG1pbmltdW0sIHRoZQ0KPj4+Pj4+Pj4+ Pj4+Pj4+Pj4+Pj4+Pj4+PiBUTFNfUlNBX1dJVEhfQUVTXzEyOF9DQkNfU0hBIGNpcGhlcnN1aXRl IFs2XS7Csg0KPj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pg0KPj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+ Pj4+PiBJIHJlYWxpemUgdGhpcyByZXF1aXJlbWVudCBjb21lcyBmcm9tIFJGQyA0NTgyLA0KPj4+ Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+PiBidXQgScK5ZCBsaWtlIHRvIHVuZGVyc3RhbmQgd2h5IGl0 IGhhcyBub3QgYmVlbg0KPj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+PiB1cGRhdGVkIHRvIGJlIGNv bnNpc3RlbnQgd2l0aCBtb3JlIGN1cnJlbnQNCj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4gZ3Vp ZGFuY2Ugb24gY2lwaGVyIHN1aXRlIHNlbGVjdGlvbiAoZS5nLiwNCj4+Pj4+Pj4+Pj4+Pj4+Pj4+ Pj4+Pj4+Pj4NCj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4gaHR0cHM6Ly90b29scy5pZXRmLm9y Zy9odG1sL2RyYWZ0LWlldGYtdXRhLXRscy0NCj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4gYmMN Cj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4gcA0KPj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+PiAt DQo+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+IDANCj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4g OA0KPj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+PiAjDQo+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+ IHMNCj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4gZQ0KPj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+ PiBjDQo+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+IHRpb24NCj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+ Pj4+Pj4gLTQpDQo+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+IC4NCj4+Pj4+Pj4+Pj4+Pj4+Pj4+ Pj4+Pj4+Pj4NCj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4NCj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+ Pj4+Pj4NCj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+PiBIb3cgYWJvdXQgd2Uga2VlcCB0aGlzIG1p bmltdW0gcmVxdWlyZW1lbnQsIGFuZA0KPj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+IGFkZCBhIHJl ZmVyZW5jZSB0byBkcmFmdC1pZXRmLXV0YS10bHMtYmNwIGFsb25nDQo+Pj4+Pj4+Pj4+Pj4+Pj4+ Pj4+Pj4+Pj4gd2l0aCBhIHJlY29tbWVuZGF0aW9uIHRvIGFkaGVyZSB0byB0aGUgYmVzdA0KPj4+ Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+IHByYWN0aWNlcyBpdCBvdXRsaW5lcyBpbiBzZWN0aW9uIDQ/ DQo+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4NCj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pg0KPj4+ Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+DQo+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+PiBJIHRoaW5rIE1V U1Qgc3VwcG9ydCBUTFNfUlNBX1dJVEhfQUVTXzEyOF9DQkNfU0hBDQo+Pj4+Pj4+Pj4+Pj4+Pj4+ Pj4+Pj4+PiBmb3IgYmFja3dhcmRzIGNvbXBhdGliaWxpdHkgYW5kIFNIT1VMRCBzdXBwb3J0DQo+ Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+PiB0aGUgb25lcyBsaXN0ZWQgaW4gdGhlIFVUQSBkcmFmdHMg d291bGQgYmUgb2suDQo+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pg0KPj4+Pj4+Pj4+Pj4+Pj4+Pj4+ Pj4+Pj4NCj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+DQo+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pg0K Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+DQo+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4NCj4+Pj4+ Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4gPSBTZWN0aW9ucyA4LCA4LjEsIDguMiA9IEl0IHNlZW1zIGxp a2UgdGhlDQo+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+IHRyYW5zYWN0aW9uIElEIHJlcXVpcmVt ZW50cyByZWdhcmRpbmcNCj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4gbm9uLXJldXNlL21vbm90 b25pY2FsbHkgaW5jcmVhc2luZyBJRHMgYXJlDQo+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+IHJl LXN0YXRlZCBtdWx0aXBsZSB0aW1lcyBhY3Jvc3MgdGhlc2UgdGhyZWUNCj4+Pj4+Pj4+Pj4+Pj4+ Pj4+Pj4+Pj4+Pj4gc2VjdGlvbnMsIGluIHNsaWdodGx5IGRpZmZlcmVudCB3YXlzLCB0byB0aGUN Cj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4gcG9pbnQgd2hlcmUgaXTCuXMgbm90IGNsZWFyIGV4 YWN0bHkgd2hhdCB0aGV5IGFyZS4NCj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4gSXQgc2VlbXMg bGlrZSB0aGV5IGFyZToNCj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4NCj4+Pj4+Pj4+Pj4+Pj4+ Pj4+Pj4+Pj4+Pj4gKDEpIFJlbGlhYmxlIHRyYW5zcG9ydCwgc2VydmVyLWluaXRpYXRlZCB0cmFu c2FjdGlvbjoNCj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4gSUQgaXMNCj4+Pj4+Pj4+Pj4+Pj4+ Pj4+Pj4+Pj4+Pj4gMA0KPj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+PiAoMikgVW5yZWxpYWJsZSB0 cmFuc3BvcnQsIHNlcnZlci1pbml0aWF0ZWQNCj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4gdHJh bnNhY3Rpb246DQo+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+IElEIE1VU1QgYmUgbW9ub3Rvbmlj YWxseSBpbmNyZWFzaW5nIChleGNlcHQgZm9yDQo+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+IHdy YXAtYXJvdW5kKQ0KPj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+PiAoMykgUmVsaWFibGUgdHJhbnNw b3J0LCBjbGllbnQtaW5pdGlhdGVkIHRyYW5zYWN0aW9uOg0KPj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+ Pj4+PiBJRCBNVVNUIE5PVCBiZSAwIGFuZCBNVVNUIE5PVCBiZSByZXVzZWQgaW4gDQo+Pj4+Pj4+ Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+IGFub3RoZXIgbWVzc2FnZSBmcm9tIHRoZSBjbGllbnQgdW50aWwg YSANCj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4gcmVzcG9uc2UNCj4+Pj4+Pj4+Pj4+Pj4+Pj4+ Pj4+Pj4+Pj4NCj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+PiA+ZnJvbSB0aGUgc2VydmVyIGlzIHJl Y2VpdmVkIGZvciB0aGUgDQo+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4gPnRyYW5zYWN0aW9uLA0K Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+DQo+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+IGJ1dCBu ZWVkIG5vdCBiZSBtb25vdG9uaWNhbGx5IGluY3JlYXNpbmcgKGUuZy4sIA0KPj4+Pj4+Pj4+Pj4+ Pj4+Pj4+Pj4+Pj4+PiBhIGxvd2VyLCByZWNlbnRseSB1c2VkIElEIGNvdWxkIGJlIHJlLXVzZWQg b25jZSANCj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4gYSByZXNwb25zZSBpcw0KPj4+Pj4+Pj4+ Pj4+Pj4+Pj4+Pj4+Pj4+PiByZWNlaXZlZCkNCj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4gKDQp IFVucmVsaWFibGUgdHJhbnNwb3J0LCBjbGllbnQtaW5pdGlhdGVkDQo+Pj4+Pj4+Pj4+Pj4+Pj4+ Pj4+Pj4+Pj4+IHRyYW5zYWN0aW9uOg0KPj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+PiBJRCBNVVNU IGJlIG1vbm90b25pY2FsbHkgaW5jcmVhc2luZyAoZXhjZXB0IGZvcg0KPj4+Pj4+Pj4+Pj4+Pj4+ Pj4+Pj4+Pj4+PiB3cmFwLWFyb3VuZCkNCj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4NCj4+Pj4+ Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4gSXMgKDMpIHRoZSBjb3JyZWN0IGludGVycHJldGF0aW9uIG9m IHRoZSB0ZXh0IGluIDguMT8NCj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4gSWYgc28sIHdoeSBu b3QganVzdCByZXF1aXJlIElEcyBpbiBhbGwgDQo+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+IGNs aWVudC1pbml0aWF0ZWQgdHJhbnNhY3Rpb25zIHRvIGJlIA0KPj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+ Pj4+PiBtb25vdG9uaWNhbGx5IGluY3JlYXNpbmc/DQo+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+ DQo+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+DQo+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+DQo+ Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4gQWdyZWUgd2UgY2FuIGFuZCBzaG91bGQgc2ltcGxpZnkg dGhpcy4gU2VjdGlvbnMNCj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+PiA4LjEgYW5kDQo+Pj4+Pj4+ Pj4+Pj4+Pj4+Pj4+Pj4+Pj4gOC4yIGNvdmVyIHRoZSBjbGllbnQgYmVoYXZpb3IgYW5kIHNlcnZl ciANCj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+PiBiZWhhdmlvciBpbiBkZXRhaWwuIEFzIHN1Y2gs IHRoZSB0cmFuc2FjdGlvbiBJRCANCj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+PiByZWxhdGVkIGlu Zm9ybWF0aW9uIGF0IHRoZSBzdGFydCBvZiBTZWN0aW9uIDggaXMgDQpzdXBlcmZsdW91cy4NCj4+ Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+PiBJIHJlY29tbWVuZCByZWR1Y2luZyB0aGUgdGV4dCBpbiBT ZWN0aW9uIDggdG8gDQo+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4gdGhlDQo+Pj4+Pj4+Pj4+Pj4+ Pj4+Pj4+Pj4+Pj4gZm9sbG93Og0KPj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+DQo+Pj4+Pj4+Pj4+ Pj4+Pj4+Pj4+Pj4+Pj4gOC4gUHJvdG9jb2wgVHJhbnNhY3Rpb25zDQo+Pj4+Pj4+Pj4+Pj4+Pj4+ Pj4+Pj4+Pj4NCj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+PiBJbiBCRkNQLCB0aGVyZSBhcmUgdHdv IHR5cGVzIG9mIHRyYW5zYWN0aW9uczoNCj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+PiBjbGllbnQt aW5pdGlhdGVkIHRyYW5zYWN0aW9ucyBhbmQgDQo+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4gc2Vy dmVyLWluaXRpYXRlZCB0cmFuc2FjdGlvbnMuDQo+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4NCj4+ Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+PiBDbGllbnQtaW5pdGlhdGVkIHRyYW5zYWN0aW9ucyBjb25z aXN0IG9mIGEgDQo+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4gcmVxdWVzdCBmcm9tIGEgY2xpZW50 IHRvIGEgZmxvb3IgY29udHJvbCBzZXJ2ZXIgDQo+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4gYW5k IGEgcmVzcG9uc2UgZnJvbSB0aGUgZmxvb3IgY29udHJvbCBzZXJ2ZXIgdG8gdGhlIA0KY2xpZW50 Lg0KPj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+DQo+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4gU2Vy dmVyLWluaXRpYXRlZCB0cmFuc2FjdGlvbnMgaGF2ZSBkaWZmZXJlbnQgDQo+Pj4+Pj4+Pj4+Pj4+ Pj4+Pj4+Pj4+Pj4gYmVoYXZpb3IgZGVwZW5kaW5nIG9uIHVuZGVybHlpbmcgdHJhbnNwb3J0Og0K Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+DQo+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4gICAgICAg V2hlbiB1c2luZyBhIHJlbGlhYmxlIHRyYW5zcG9ydCwgDQo+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+ Pj4gc2VydmVyLWluaXRpYXRlZCB0cmFuc2FjdGlvbnMNCj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+ PiAgICAgICBjb25zaXN0IG9mIGEgc2luZ2xlIG1lc3NhZ2UgZnJvbSBhIGZsb29yIA0KPj4+Pj4+ Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+IGNvbnRyb2wgc2VydmVyIHRvIGENCj4+Pj4+Pj4+Pj4+Pj4+Pj4+ Pj4+Pj4+PiAgICAgICBjbGllbnQgKG5vdGlmaWNhdGlvbnMpLiAgVGhleSBkbyBub3QgDQo+Pj4+ Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4gdHJpZ2dlciBhbnkgcmVzcG9uc2UuDQo+Pj4+Pj4+Pj4+Pj4+ Pj4+Pj4+Pj4+Pj4NCj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+PiAgICAgICBXaGVuIHVzaW5nIGFu IHVucmVsaWFibGUgdHJhbnNwb3J0LCANCj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+PiBzZXJ2ZXIt aW5pdGlhdGVkIHRyYW5zYWN0aW9ucw0KPj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+ICAgICAgIGNv bnNpc3Qgb2YgYSByZXF1ZXN0IGZyb20gYSBmbG9vciBjb250cm9sIA0KPj4+Pj4+Pj4+Pj4+Pj4+ Pj4+Pj4+Pj4+IHNlcnZlciB0byBhIGNsaWVudCBhbmQgYQ0KPj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+ Pj4+ICAgICAgIHJlc3BvbnNlIGZyb20gdGhlIGNsaWVudCB0byB0aGUgZmxvb3IgDQo+Pj4+Pj4+ Pj4+Pj4+Pj4+Pj4+Pj4+Pj4gY29udHJvbCBzZXJ2ZXIuDQo+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+ Pj4NCj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+PiBXaGVuIHVzaW5nIEJGQ1Agb3ZlciBhbiB1bnJl bGlhYmxlIHRyYW5zcG9ydCwgDQo+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4gcmV0cmFuc21pc3Np b24gdGltZXIgVDEgKHNlZSBTZWN0aW9uIDguMykgTVVTVCANCj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+ Pj4+PiBiZSB1c2VkIGZvciBhbGwgcmVxdWVzdHMgdW50aWwgdGhlIHRyYW5zYWN0aW9uIA0KPj4+ Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+IGlzIGNvbXBsZXRlZC4NCj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+ Pj4+Pg0KPj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+IFRoZW4gaW4gc2VjdGlvbiA4LjEsIHdlIGFk ZCB0aGUgaW1wb3J0YW50IA0KPj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+IGRldGFpbHMgcmVtb3Zl ZCBmcm9tIHNlY3Rpb24gOC4NCj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pg0KPj4+Pj4+Pj4+Pj4+ Pj4+Pj4+Pj4+Pj4+IDguMS4xIENsaWVudCBCZWhhdmlvcg0KPj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+ Pj4+DQo+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4gQSBjbGllbnQgc3RhcnRpbmcgYSBjbGllbnQt aW5pdGlhdGVkIHRyYW5zYWN0aW9uIA0KPj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+IE1VU1Qgc2V0 IHRoZSBDb25mZXJlbmNlIElEIGluIHRoZSBjb21tb24gaGVhZGVyIA0KPj4+Pj4+Pj4+Pj4+Pj4+ Pj4+Pj4+Pj4+IG9mIHRoZSBtZXNzYWdlIHRvIHRoZSBDb25mZXJlbmNlIElEIGZvciB0aGUgDQo+ Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4gY29uZmVyZW5jZSB0aGF0IHRoZSBjbGllbnQgb2J0YWlu ZWQgcHJldmlvdXNseS4NCj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pg0KPj4+Pj4+Pj4+Pj4+Pj4+ Pj4+Pj4+Pj4+IFRoZSBjbGllbnQgTVVTVCBzZXQgdGhlIFRyYW5zYWN0aW9uIElEIHZhbHVlIGlu IA0KPj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+IHRoZSBjb21tb24gaGVhZGVyIHRvIGEgbnVtYmVy IHRoYXQgaXMgZGlmZmVyZW50DQo+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4gICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgDQo+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+ PiA+ZnJvbSAwIGFuZCB0aGF0IE1VU1QgTk9UIGJlIHJldXNlZCBpbiBhbm90aGVyDQo+Pj4+Pj4+ Pj4+Pj4+Pj4+Pj4+Pj4+PiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgDQo+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4gbWVzc2FnZSBmcm9tIHRoZSBjbGllbnQgdW50 aWwgYSByZXNwb25zZSBmcm9tIA0KPj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+IHRoZSBzZXJ2ZXIg aXMgcmVjZWl2ZWQgZm9yIHRoZSB0cmFuc2FjdGlvbi4NCj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+ PiBUaGUgY2xpZW50IHVzZXMgdGhlIFRyYW5zYWN0aW9uIElEIHZhbHVlIHRvIA0KPj4+Pj4+Pj4+ Pj4+Pj4+Pj4+Pj4+Pj4+IG1hdGNoIHRoaXMgbWVzc2FnZSB3aXRoIHRoZSByZXNwb25zZSBmcm9t IHRoZSANCj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+PiBmbG9vciBjb250cm9sIHNlcnZlci4NCj4+ Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+PiBXaGVuIHVzaW5nIEJGQ1Agb3ZlciBhbiB1bnJlbGlhYmxl IHRyYW5zcG9ydCwgaXQgDQo+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4gaXMgaW1wb3J0YW50IHRv IGNob29zZSBhIFRyYW5zYWN0aW9uIElEIHZhbHVlIA0KPj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+ IHRoYXQgbGV0cyB0aGUgcmVjZWl2ZXIgZGlzdGluZ3Vpc2ggdGhlIHJlY2VwdGlvbiANCj4+Pj4+ Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+PiBvZiB0aGUgbmV4dCBtZXNzYWdlIGluIGEgc2VxdWVuY2Ugb2Yg QkZDUCANCj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+PiBtZXNzYWdlcyBmcm9tIGEgcmV0cmFuc21p c3Npb24gb2YgYSBwcmV2aW91cyANCj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+PiBtZXNzYWdlLiAg VGhlcmVmb3JlLCBCRkNQIGVudGl0aWVzIHVzaW5nIGFuIA0KPj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+ Pj4+IHVucmVsaWFibGUgdHJhbnNwb3J0IE1VU1QgdXNlIG1vbm90b25pY2FsbHkgDQo+Pj4+Pj4+ Pj4+Pj4+Pj4+Pj4+Pj4+Pj4gaW5jcmVhc2luZyBUcmFuc2FjdGlvbiBJRCB2YWx1ZXMgKGV4Y2Vw dCBmb3IgDQp3cmFwLWFyb3VuZCkuDQo+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4NCj4+Pj4+Pj4+ Pj4+Pj4+Pj4+Pj4+Pj4+PiBBIGNsaWVudCByZWNlaXZpbmcgYSBzZXJ2ZXItaW5pdGlhdGVkIA0K Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+IHRyYW5zYWN0aW9uIG92ZXIgYW4gdW5yZWxpYWJsZSB0 cmFuc3BvcnQgTVVTVCANCj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+PiBjb3B5IHRoZSBUcmFuc2Fj dGlvbiBJRCBmcm9tIHRoZSByZXF1ZXN0IA0KPj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+IHJlY2Vp dmVkIGZyb20gdGhlIHNlcnZlciBpbnRvIHRoZSByZXNwb25zZS4NCj4+Pj4+Pj4+Pj4+Pj4+Pj4+ Pj4+Pj4+PiBbUXVlc3Rpb246IGlzIHRoZXJlIGEgbmVlZCB0byBjb3B5IHRoZSANCj4+Pj4+Pj4+ Pj4+Pj4+Pj4+Pj4+Pj4+PiBDb25mZXJlbmNlIElEIGFuZCAgVXNlciBJRCwgaWYgcHJlc2VudD9d DQo+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4NCj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+PiA4LjIu IFNlcnZlciBCZWhhdmlvcg0KPj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+DQo+Pj4+Pj4+Pj4+Pj4+ Pj4+Pj4+Pj4+Pj4gQSBmbG9vciBjb250cm9sIHNlcnZlciBzZW5kaW5nIGEgcmVzcG9uc2Ugd2l0 aGluIA0KPj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+IGEgY2xpZW50LWluaXRpYXRlZCB0cmFuc2Fj dGlvbiBNVVNUIGNvcHkgdGhlIA0KPj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+IENvbmZlcmVuY2Ug SUQsIHRoZSBUcmFuc2FjdGlvbiBJRCwgYW5kIHRoZSBVc2VyIA0KPj4+Pj4+Pj4+Pj4+Pj4+Pj4+ Pj4+Pj4+IElEDQo+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4gICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgDQo+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+PiA+ZnJvbSB0 aGUgcmVxdWVzdCByZWNlaXZlZCBmcm9tIHRoZSBjbGllbnQgaW50byANCj4+Pj4+Pj4+Pj4+Pj4+ Pj4+Pj4+Pj4+ID50aGUNCj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+ICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICANCj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+PiByZXNw b25zZS4NCj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pg0KPj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+ IFNlcnZlci1pbml0aWF0ZWQgdHJhbnNhY3Rpb25zIE1VU1QgY29udGFpbiBhIA0KPj4+Pj4+Pj4+ Pj4+Pj4+Pj4+Pj4+Pj4+IFRyYW5zYWN0aW9uIElEIGVxdWFsIHRvDQo+Pj4+Pj4+Pj4+Pj4+Pj4+ Pj4+Pj4+Pj4gMCB3aGVuIEJGQ1AgaXMgdXNlZCBvdmVyIGEgcmVsaWFibGUgdHJhbnNwb3J0Lg0K Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+IE92ZXIgYW4gdW5yZWxpYWJsZSB0cmFuc3BvcnQsIHRo ZSBUcmFuc2FjdGlvbiBJRCANCj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+PiBzaGFsbCBoYXZlIHRo ZSBzYW1lIHByb3BlcnRpZXMgYXMgZm9yIA0KPj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+IGNsaWVu dC1pbml0aWF0ZWQgdHJhbnNhY3Rpb25zLg0KPj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+IFRoZSBz ZXJ2ZXIgdXNlcyB0aGUgVHJhbnNhY3Rpb24gSUQgdmFsdWUgdG8gDQo+Pj4+Pj4+Pj4+Pj4+Pj4+ Pj4+Pj4+Pj4gbWF0Y2ggdGhpcyBtZXNzYWdlIHdpdGggdGhlIHJlc3BvbnNlIGZyb20gdGhlIA0K Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+IGZsb29yIHBhcnRpY2lwYW50IG9yIGZsb29yIGNoYWly Lg0KPj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+DQo+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4NCj4+ Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pg0KPj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+ICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIA0KPj4+Pj4+Pj4+Pj4+Pj4+Pj4+ Pj4+Pj4gVGhhbmtzLCB0aGlzIGlzIGJldHRlci4NCj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+DQo+ Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pg0KPj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4NCj4+Pj4+Pj4+ Pj4+Pj4+Pj4+Pj4+Pj4+ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICANCj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4gPSBTZWN0aW9uIDkgKGltcGFjdHMgU2VjdGlv biAxNCBhcyB3ZWxsKSA9IA0KPj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+PiAiQkZDUCBjbGllbnRz ICBTSE9VTEQgYXV0aGVudGljYXRlIHRoZSBmbG9vciANCj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+ Pj4gY29udHJvbCBzZXJ2ZXIgYmVmb3JlICBzZW5kaW5nIGFueSBCRkNQIG1lc3NhZ2UgDQo+Pj4+ Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+IHRvIGl0IG9yIGFjY2VwdGluZyBhbnkgQkZDUCBtZXNzYWdl IGZyb20gaXQuDQo+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+IFNpbWlsYXJseSwgZmxvb3IgY29u dHJvbCBzZXJ2ZXJzIFNIT1VMRCANCj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4gYXV0aGVudGlj YXRlIGEgY2xpZW50IGJlZm9yZSBhY2NlcHRpbmcgYW55IEJGQ1AgDQo+Pj4+Pj4+Pj4+Pj4+Pj4+ Pj4+Pj4+Pj4+IG1lc3NhZ2UgZnJvbSBpdCBvciBzZW5kaW5nIGFueSBCRkNQIG1lc3NhZ2UgdG8g aXQuDQo+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+DQo+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+ IEJGQ1Agc3VwcG9ydHMgVExTL0RUTFMgbXV0dWFsIGF1dGhlbnRpY2F0aW9uIA0KPj4+Pj4+Pj4+ Pj4+Pj4+Pj4+Pj4+Pj4+PiBiZXR3ZWVuIGNsaWVudHMgYW5kIGZsb29yIGNvbnRyb2wgc2VydmVy cywgYXMgDQo+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+IHNwZWNpZmllZCBpbiBTZWN0aW9uIDku MS4NCj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4gVGhpcyBpcyB0aGUgUkVDT01NRU5ERUQgYXV0 aGVudGljYXRpb24gDQo+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+IG1lY2hhbmlzbSBpbiBCRkNQ LsKyDQo+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+DQo+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+ IFdoYXQgYXJlIHRoZSBjYXNlcyB3aGVyZSBjbGllbnRzIGFuZCBzZXJ2ZXJzIGRvIA0KPj4+Pj4+ Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+PiBub3QgbmVlZCAgdG8gYmUgYXV0aGVudGljYXRpbmcgZWFjaCBv dGhlcj8gSSANCj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4ga25vdyB0aGlzIHJlcXVpcmVtZW50 ICBhbmQgdGhlIG90aGVyIA0KPj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+PiBTSE9VTEQtbGV2ZWwg cmVxdWlyZW1lbnRzIGFyb3VuZCB1c2Ugb2YgIA0KPj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+PiBU TFMvRFRMUyBhcmUgY2FycmllZCBvdmVyIGZyb20gUkZDIDQ1ODIsIGJ1dCANCj4+Pj4+Pj4+Pj4+ Pj4+Pj4+Pj4+Pj4+Pj4gScK5bSAgY29uY2VybmVkIHRoYXQgdGhleSBhcmVuwrl0IGFzIHN0cm9u ZyBhcyB0aGV5IA0Kc2hvdWxkIGJlLg0KPj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+PiBGb3IgYSBj b25mZXJlbmNlIHdoZXJlIHRoZSBzaWduYWxpbmcgdHJhZmZpYyBpcyANCj4+Pj4+Pj4+Pj4+Pj4+ Pj4+Pj4+Pj4+Pj4gYXV0aGVudGljYXRlZCBhbmQgY29uZmlkZW50aWFsaXR5IGFuZCBpbnRlZ3Jp dHkgDQo+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+IHByb3RlY3RlZCwgd2h5IGlzIGl0IG9rIGZv ciB0aGUgZmxvb3IgY29udHJvbCANCj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4gdHJhZmZpYyBu b3QgdG8gYmU/IENvdWxkIHRoZXNlIHJlcXVpcmVtZW50cyBiZSANCj4+Pj4+Pj4+Pj4+Pj4+Pj4+ Pj4+Pj4+Pj4gYWRqdXN0ZWQgdG8gcmVxdWlyZSB1c2Ugb2YgVExTL0RUTFMgYXQgbGVhc3QgaW4g DQo+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+IGNhc2VzIHdoZXJlIHRoZSBzaWduYWxpbmcgaXMg YWxzbyBwcm90ZWN0ZWQ/DQo+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+DQo+Pj4+Pj4+Pj4+Pj4+ Pj4+Pj4+Pj4+Pj4+DQo+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+ICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgDQo+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4g WWVzLCBidXQgYWdhaW4sIHRoaXMgd291bGQgYmUgYXQgdGhlIGV4cGVuc2Ugb2YgDQo+Pj4+Pj4+ Pj4+Pj4+Pj4+Pj4+Pj4+Pj4gYWRkaW5nIGEgbm9uIGJhY2t3YXJkIGNvbXBhdGlibGUgY2hhbmdl IGZyb20gcmZjIA0KPj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+IDQ1ODIuIEhvdyBhYm91dCBzYXlp bmcgVExTL0RUTFMgTVVTVCBiZSB1c2VkIGZvciANCj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+PiBC RkNQIGluIHN1Y2ggY2FzZXMsIHdoaWxlIHBvaW50aW5nIG91dCB0aGUgcmZjDQo+Pj4+Pj4+Pj4+ Pj4+Pj4+Pj4+Pj4+Pj4gNDU4Mg0KPj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+IGJhc2VkIGltcGxl bWVudGF0aW9ucyBtYXkgbm90IGNvbXBseSAoc2ltaWxhciB0byANCj4+Pj4+Pj4+Pj4+Pj4+Pj4+ Pj4+Pj4+PiB3aGF0IHdlIGRpZCB3aXRoIHRoZSB2ZXJzaW9uIGZpZWxkKS4NCj4+Pj4+Pj4+Pj4+ Pj4+Pj4+Pj4+Pj4+Pg0KPj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+DQo+Pj4+Pj4+Pj4+Pj4+Pj4+ Pj4+Pj4+Pj4gICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgDQo+ Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+PiBXb3JrcyBmb3IgbWUuDQo+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+ Pj4+Pg0KPj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4gRmVlbCBmcmVlIHRvIG1ha2UgYWxsIG9mIHRo ZXNlIGNoYW5nZXMgYW5kIHN1Ym1pdCANCj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+IGEgcmV2IGFu ZCBJwrlsbCBpc3N1ZSB0aGUgSUVURiBMQy4NCj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+DQo+Pj4+ Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+PiBUaGFua3MsDQo+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+PiBBbGlz c2ENCj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+DQo+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pg0KPj4+ Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4NCj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+ICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICANCj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+ Pj4gPSBTZWN0aW9uIDE0ID0NCj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4gU2VlIHRoZSBwb2lu dCBhYm92ZSBhYm91dCBjaXBoZXJzdWl0ZXMuIA0KPj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+PiDC s05vbi1udWxsIGVuY3J5cHRpb27CsiBpcyBub3QgYSBzdWZmaWNpZW50IA0KPj4+Pj4+Pj4+Pj4+ Pj4+Pj4+Pj4+Pj4+PiBtaW5pbXVtIGJhc2VsaW5lLCBhbmQgaWYgdGhlIHJlcXVpcmVtZW50cyAN Cj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4gY2hhbmdlIGluIFNlY3Rpb24gNyB0aGV5IHNob3Vs ZCBiZSByZWZsZWN0ZWQgaGVyZSBhcyANCndlbGwuDQo+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+ DQo+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+DQo+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+ICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgDQo+Pj4+Pj4+Pj4+ Pj4+Pj4+Pj4+Pj4+Pj4gWWVwLg0KPj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+DQo+Pj4+Pj4+Pj4+ Pj4+Pj4+Pj4+Pj4+Pj4NCj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pg0KPj4+Pj4+Pj4+Pj4+Pj4+ Pj4+Pj4+Pj4+ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIA0K Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+PiBFZGl0b3JpYWwgbml0cyB0byBiZSByZXNvbHZlZCB3 aXRoIExDIGNvbW1lbnRzOg0KPj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pg0KPj4+Pj4+Pj4+Pj4+ Pj4+Pj4+Pj4+Pj4+PiA9IFNlY3Rpb24gNS4xID0gwrNUaGUgdmVyc2lvbiBmaWVsZCBNVVNUIGJl IHNldCANCj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4gdG8gMSB3aGVuIHVzaW5nIEJGQ1Agb3Zl ciBhIHJlbGlhYmxlIHRyYW5zcG9ydCwgDQo+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+IGkuZS4g YXMgaW4gWzJdLsKyDQo+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+DQo+Pj4+Pj4+Pj4+Pj4+Pj4+ Pj4+Pj4+Pj4+IEkgZmluZCBpdCBhIGxpdHRsZSBvZGQgdG8gcmVmZXJlbmNlIHRoZSBzcGVjIA0K Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+PiB5b3XCuXJlIG9ic29sZXRpbmcgaW4gdGhpcyBzZW50 ZW5jZSwgZXNwZWNpYWxseSANCj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4gc2luY2UgQkZDUCBv dmVyIGEgcmVsaWFibGUgdHJhbnNwb3J0IGlzIA0KPj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+PiBj b21wbGV0ZWx5IHNwZWNpZmllZCBpbiB0aGlzIGJpcyBkb2N1bWVudC4gSSANCj4+Pj4+Pj4+Pj4+ Pj4+Pj4+Pj4+Pj4+Pj4gd291bGQgc3VnZ2VzdCBkcm9wcGluZw0KPj4+Pj4+Pj4+Pj4+Pj4+Pj4+ Pj4+Pj4+PiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIA0K Pj4+IHRoZSBpLmUuDQo+Pj4gICAgDQo+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+IGNsYXVzZS4N Cj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4NCj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4NCj4+ Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4gICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICANCj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+PiBHb29kIGNhdGNoLiBUaGlz IGlzIGEgY2Fycnkgb3ZlciBmcm9tIGJlZm9yZSANCj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+PiB0 aGlzIGRyYWZ0IHdhcyBhZG9wdGVkIGFzIGEgYmlzIHZlcnNpb24gb2YgcmZjNDU4Mi4NCj4+Pj4+ Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pg0KPj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+DQo+Pj4+Pj4+Pj4+ Pj4+Pj4+Pj4+Pj4+Pj4NCj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+PiAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICANCj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4g IlRoZSB2ZXJzaW9uIGZpZWxkIE1VU1QgYmUgc2V0IHRvIDIgd2hlbiB1c2luZyANCj4+Pj4+Pj4+ Pj4+Pj4+Pj4+Pj4+Pj4+Pj4gQkZDUCBvdmVyIGFuIHVucmVsaWFibGUgdHJhbnNwb3J0IHdpdGgg dGhlIA0KPj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+PiBleHRlbnNpb25zIHNwZWNpZmllZCBpbiB0 aGlzIGRvY3VtZW50LsKyDQo+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+DQo+Pj4+Pj4+Pj4+Pj4+ Pj4+Pj4+Pj4+Pj4+IFRoZSBiaXQgYWJvdXQgwrN3aXRoIHRoZSBleHRlbnNpb25zIHNwZWNpZmll ZCBpbiANCj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4gdGhpcyBkb2N1bWVudMKyIGlzIGV4dHJh bmVvdXMgYW5kIHNob3VsZCBiZSByZW1vdmVkLg0KPj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pg0K Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+PiAiSWYgYW4gZW5kcG9pbnQgcmVjZWl2ZXMgYSBtZXNz YWdlIHdpdGggYW4gDQo+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+IHVuc3VwcG9ydGVkIHZlcnNp b24gZmllbGQgdmFsdWUsIHRoZSByZWNlaXZpbmcgDQo+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+ IHNlcnZlciBNVVNUIHNlbmQgYW4gRXJyb3IgbWVzc2FnZSB3aXRoIA0KPj4+Pj4+Pj4+Pj4+Pj4+ Pj4+Pj4+Pj4+PiBwYXJhbWV0ZXIgdmFsdWUgMTIgKFVuc3VwcG9ydGVkDQo+Pj4+Pj4+Pj4+Pj4+ Pj4+Pj4+Pj4+Pj4+IFZlcnNpb24pIHRvIGluZGljYXRlIHRoaXMuwrINCj4+Pj4+Pj4+Pj4+Pj4+ Pj4+Pj4+Pj4+Pj4NCj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4gVXNlIG9mIHRoZSB3b3JkIMKz c2VydmVywrIgaGVyZSBtYWtlcyBpdCBzb3VuZCBhcyANCj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+ Pj4gaWYgb25seSBzZXJ2ZXJzIGNvdWxkIHJlY2VpdmUgaGVhZGVycyB3aXRoIA0KPj4+Pj4+Pj4+ Pj4+Pj4+Pj4+Pj4+Pj4+PiB1bnN1cHBvcnRlZCB2ZXJzaW9ucy4NCj4+Pj4+Pj4+Pj4+Pj4+Pj4+ Pj4+Pj4+Pj4gU2hvdWxkIHRoaXMgYmUgwrN0aGUgcmVjZWl2aW5nIGVuZHBvaW50wrI/DQo+Pj4+ Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+DQo+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+ID0gU2VjdGlv biA2LjIuNCA9ICJbMjNdLCBTZWN0aW9uIDYuNyBwcm92aWRlcyANCj4+Pj4+Pj4+Pj4+Pj4+Pj4+ Pj4+Pj4+Pj4gdXNlZnVsIHJlY29tbWVuZGF0aW9ucyDFoMKyDQo+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+ Pj4+Pj4+DQo+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+IFRoZSBsaW5rcyBpbiB0aGUgcmVmZXJl bmNlcyBhcmUgbm90IHF1aXRlIHJpZ2h0Lg0KPj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pg0KPj4+ Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+PiA9IFNlY3Rpb24gOC4zLjIgPSBzL3doZW4gZmlyZXMvd2hl biBmaXJlZC8NCj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4NCj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+ Pj4+Pj4gPSBTZWN0aW9uIDE0ID0NCj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4gcy9oaWdoLWph Y2svaGlqYWNrLw0KPj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pg0KPj4+Pj4+Pj4+Pj4+Pj4+Pj4+ Pj4+Pj4+PiA9IFNlY3Rpb24gQi4xID0gInNpdHVhdGlvbiB3aGVyZSBtdWx0aXBsZSANCj4+Pj4+ Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4gZGlmZmVyZW50IGFuZCBub24taW50ZXJvcGVyYWJsZSB3b3Vs ZA0KPj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+PiBjby0NCj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+ Pj4gZXhpc3QgaW4gdGhlIG1hcmtldC7Csg0KPj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pg0KPj4+ Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+PiBUaGVyZSBpcyBhIHdvcmQgbWlzc2luZyBhZnRlciDCs25v bi1pbnRlcm9wZXJhYmxlLiINCj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4NCj4+Pj4+Pj4+Pj4+ Pj4+Pj4+Pj4+Pj4+Pj4NCj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4gICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICANCj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+ PiBUaGlzIHNob3VsZCByZWFkIMKzbm9uLWludGVyb3BlcmFibGUgaW1wbGVtZW50YXRpb25zwrIu DQo+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4gRWFybGllciBpbiB0aGF0IHNhbWUgc2VudGVuY2Us IMKzQkZDUCBvdmVyIFVEUCANCj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+PiB3ZXJlIGFscmVhZHkg dXNlZMKyIHNob3VsZCByZWFkIMKzQkZDUCBvdmVyIFVEUCBpcyANCj4+Pj4+Pj4+Pj4+Pj4+Pj4+ Pj4+Pj4+PiBhbHJlYWR5IGJlaW5nIHVzZWTCsi4NCj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pg0K Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+IENoZWVycywNCj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+ PiBDaGFybGVzDQo+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4NCj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+ Pj4+Pg0KPj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+ICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgIA0KPj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4gX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+ Pj4+IGJmY3BiaXMgbWFpbGluZyBsaXN0IA0KPj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4gYmZjcGJp c0BpZXRmLm9yZzxtYWlsdG86YmZjcGJpc0BpZXRmLm9yZz4NCj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+ Pj4+IGh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vYmZjcGJpcw0KPj4+Pj4+ Pj4+Pj4+Pj4+Pj4+Pj4+Pj4NCj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+DQo+Pj4+Pj4+Pj4+Pj4+ Pj4+Pj4+Pj4+PiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgDQo+ Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+DQo+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+ICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgDQo+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4NCj4+ Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+PiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICANCj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+DQo+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+PiAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgDQo+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+DQo+Pj4+Pj4+ Pj4+Pj4+Pj4+Pj4+ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgDQo+Pj4+Pj4+ Pj4+Pj4+Pj4+Pj4NCj4+Pj4+Pj4+Pj4+Pj4+Pj4+PiAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICANCj4+Pj4+Pj4+Pj4+Pj4+Pj4+DQo+Pj4+Pj4+Pj4+Pj4+Pj4+PiAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgDQo+Pj4+Pj4+Pj4+Pj4+Pj4+DQo+Pj4+Pj4+Pj4+Pj4+Pj4+ ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgDQo+Pj4+Pj4+Pj4+Pj4+Pj4NCj4+Pj4+Pj4+ Pj4+Pj4+PiAgICAgICAgICAgICAgICAgICAgICAgICAgICANCj4+Pj4+Pj4+Pj4+Pj4+DQo+Pj4+ Pj4+Pj4+Pj4+PiAgICAgICAgICAgICAgICAgICAgICAgICAgDQo+Pj4+Pj4+Pj4+Pj4NCj4+Pj4+ Pj4+Pj4+PiAgICAgICAgICAgICAgICAgICAgICANCj4+Pj4+Pj4+Pj4+DQo+Pj4+Pj4+Pj4+PiAg ICAgICAgICAgICAgICAgICAgDQo+Pj4+Pj4+Pj4+ICAgICAgICAgICAgICAgICAgDQo+Pj4+Pj4+ Pj4gX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCj4+Pj4+ Pj4+PiBiZmNwYmlzIG1haWxpbmcgbGlzdA0KPj4+Pj4+Pj4+IGJmY3BiaXNAaWV0Zi5vcmcNCj4+ Pj4+Pj4+PiBodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL2JmY3BiaXMNCj4+ Pj4+Pj4+PiAgICAgICAgICAgICAgICANCj4+Pj4+Pj4+ICAgICAgICAgICAgICANCj4+Pj4+Pj4g ICAgICAgICAgICANCj4+Pj4+PiAgICAgICAgICANCj4+Pj4+ICAgICAgICANCj4+Pj4gX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCj4+Pj4gYmZjcGJpcyBt YWlsaW5nIGxpc3QNCj4+Pj4gYmZjcGJpc0BpZXRmLm9yZw0KPj4+PiBodHRwczovL3d3dy5pZXRm Lm9yZy9tYWlsbWFuL2xpc3RpbmZvL2JmY3BiaXMNCj4+Pj4gICAgICANCj4+PiAgICANCj4+DQo+ DQoNCg== From nobody Wed Nov 11 14:38:13 2015 Return-Path: X-Original-To: bfcpbis@ietfa.amsl.com Delivered-To: bfcpbis@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5D5E51B3B8F for ; Wed, 11 Nov 2015 14:38:11 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_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 s8EO1jqxwIt9 for ; Wed, 11 Nov 2015 14:38:08 -0800 (PST) Received: from out4-smtp.messagingengine.com (out4-smtp.messagingengine.com [66.111.4.28]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 748DF1B3B8E for ; Wed, 11 Nov 2015 14:38:08 -0800 (PST) Received: from compute4.internal (compute4.nyi.internal [10.202.2.44]) by mailout.nyi.internal (Postfix) with ESMTP id A4ED42097C for ; Wed, 11 Nov 2015 17:38:07 -0500 (EST) Received: from frontend2 ([10.202.2.161]) by compute4.internal (MEProxy); Wed, 11 Nov 2015 17:38:07 -0500 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=cooperw.in; h=cc :content-type:date:from:in-reply-to:message-id:mime-version :references:subject:to:x-sasl-enc:x-sasl-enc; s=mesmtp; bh=1B3JU pGD4aNLdftcvZxTEKoZ9p8=; b=bu2h3DEVMrsoX4c5kaXZi6GoRiIv+zVg8JIJM p3DBI1gSUMgkUVxhPxgU3X2JnrIGXhr7lf05IuOIAuUwdHIOvTJiYuT//dyMoXGY E2q1JKEunSdUlf7TUsCVMIt+5IKnlMCqou4DcQKrhamaMIFUNa9LYBe6qHtyeQpD 9GcwFo= DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d= messagingengine.com; h=cc:content-type:date:from:in-reply-to :message-id:mime-version:references:subject:to:x-sasl-enc :x-sasl-enc; s=smtpout; bh=1B3JUpGD4aNLdftcvZxTEKoZ9p8=; b=uEBqB yDi5W1F9+V3h4iuiYjBVFr25Faui6IRX7YGHvwh8KH+pS3ddseapb3JhueO3Zf96 xYoWX5Cd0jVCPXtsFDGaUu/sS5aPmQP7Zks5w8/2Z1xYgpnTf0b8l7+JDd5Cr8HC ek0UCVtQdb2C2l9kmA3M0wofpKrWnQDjXlyJek= X-Sasl-enc: yBDc93LoJc/VNHAPgOwgKUwyks4t68IWfqQR7l1t3OXT 1447281487 Received: from dhcp-171-68-20-148.cisco.com (dhcp-171-68-20-148.cisco.com [171.68.20.148]) by mail.messagingengine.com (Postfix) with ESMTPA id 408FF6800B4; Wed, 11 Nov 2015 17:38:06 -0500 (EST) Content-Type: multipart/alternative; boundary="Apple-Mail=_AA572572-1C21-4E16-9B95-FA577DC56C95" Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2104\)) From: Alissa Cooper In-Reply-To: Date: Wed, 11 Nov 2015 14:38:05 -0800 Message-Id: <0BAEEA7C-B892-460B-AAD3-80A0F85E766D@cooperw.in> References: <20151105023108.17210.54132.idtracker@ietfa.amsl.com> <19C90DA9-652D-499F-8462-7EC7878307CB@packetizer.com> <5D0066E2-6BD9-4ED8-A37D-CE83118E099E@cooperw.in> To: Spencer Dawkins at IETF X-Mailer: Apple Mail (2.2104) Archived-At: Cc: "gorry@erg.abdn.ac.uk" , "bfcpbis-chairs@ietf.org" , "bfcpbis@ietf.org" , "Charles Eckel \(eckelcu\)" , "draft-ietf-bfcpbis-rfc4582bis@ietf.org" , "Paul E. Jones" , IESG , Mary Barnes Subject: Re: [bfcpbis] Spencer Dawkins' Discuss on draft-ietf-bfcpbis-rfc4582bis-15: (with DISCUSS and COMMENT) X-BeenThere: bfcpbis@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: BFCPBIS working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Nov 2015 22:38:11 -0000 --Apple-Mail=_AA572572-1C21-4E16-9B95-FA577DC56C95 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 Hi Spencer, Does Charles=92 proposal below work for you? Thanks, Alissa > On Nov 5, 2015, at 3:42 PM, Charles Eckel (eckelcu) = wrote: >=20 >=20 > From: Spencer Dawkins at IETF > > Date: Friday, November 6, 2015 at 7:23 AM > To: Alissa Cooper > > Cc: "iesg@ietf.org " >, "bfcpbis-chairs@ietf.org = " >, Paul Jones >, "gorry@erg.abdn.ac.uk = " >, Mary Barnes >, = "draft-ietf-bfcpbis-rfc4582bis@ietf.org = " = >, "bfcpbis@ietf.org = " >, = Charles Eckel > > Subject: Re: [bfcpbis] Spencer Dawkins' Discuss on = draft-ietf-bfcpbis-rfc4582bis-15: (with DISCUSS and COMMENT) >=20 >> Hi, Alissa, >> On Nov 6, 2015 7:06 AM, "Alissa Cooper" > wrote: >> > >> > Hi Spencer, >> > >> > >> > >> > On Nov 5, 2015, at 11:20 PM, Spencer Dawkins at IETF = > = wrote: >> > >> >> Hi, Charles, >> >> >> >> On Thu, Nov 5, 2015 at 5:43 PM, Charles Eckel (eckelcu) = > wrote: >> >>> >> >>> For TCP, the use of TLS was not required by RFC 4582. For = 4582bis, we do not require TLS in order to maintain backward = compatibility with RFC 4582. >> >> >> >> >> >> Got it. I'm holding my nose on this one, based on backward = compatibility, and given the degree of difficulty in splicing attack = packets into the TCP sequence numbering space if you're off-path. I'm = not thrilled, but someone else needs to decide when threats reach the = level where making that incompatible change is necessary - and that = might not be the right thing to do today. >> >> =20 >> >>> >> >>> For UDP, the reason for not mandating DTLS is backward = compatibility with existing solutions. The IMTC Role Based Video Best = Practice established a set of recommendations for getting BFCP to work = within enterprise video conference deployments. As that = time,draft-sandbakken-xcon-bfcp-udp defined BFCP over UDP only. DTLS was = left for future study. Today we have many implementations of BFCP over = UDP, but few if any using DTLS. We need the ultimate RFC that = standardizes BFCP over UDP (and over DTLS) to allow interworking with = these existing deployments. >> >> >> >> >> >> OK, I'm not the Protocol Security Police, so, fine, but it seems = like the draft could be clearer about this, and what you said in your = answer would be really helpful in the document.=20 >> >> >> >> If the text said something like "DTLS is REQUIRED unless you are = interworking with a pre-standardization deployment that is already = insecure, >> > >> > >> > "REQUIRED unless" strikes me as a faulty construction. That case is = what RECOMMENDED is for, when there is a known exception to the = requirement. >> That usage is certainly more common in some parts of the IETF than = others, but it does get used. But ignoring that. >> Do you think "RECOMMENDED unless you are interworking with a = pre-standardization deployment that is already insecure" is tight = enough? >> The reason I'm asking, is that offpath attacks on UDP-based protocols = are a lot easier than TCP-based protocols, and if the IETF is going to = publish a proposed standard with a known deficiency to accommodate = pre-standardization deployments, I'd prefer that the guidance about = using that accommodation be as clear as possible. >=20 >=20 > I agree with your intent. My concern with calling out exceptions is = that it can make the existing recommendation in the draft seem weaker. = How about this: >=20 > OLD: >=20 > =85 It is RECOMMENDED that TLS/DTLS with an > encryption algorithm according to Section 7 always be used. In = cases > where signaling/control traffic is properly protected, as described > in Section 9 it is REQUIRED to use a mandated encryption algorithm. > BFCP entities MAY use other security mechanisms as long as they > provide similar security properties. >=20 > NEW >=20 > =85 It is RECOMMENDED that TLS/DTLS with an > encryption algorithm according to Section 7 always be used. In = cases > where signaling/control traffic is properly protected, as described > in Section 9 it is REQUIRED to use a mandated encryption algorithm. > BFCP entities MAY use other security mechanisms to interwork with=20= > legacy implementation that do not use TLS/DTLS as long as these=20 > mechanisms provide similar security properties.=20 >=20 > Cheers, > Charles > =20 >>=20 >> Thanks, >> Spencer >> > Alissa >> > >> >> in which case you're not making things worse by running without = transport-level security", that would capture my concern and reflect = what you're saying, unless I'm missing something. >> >> >> >> Thanks to you and Paul for the speedy response on the evening of = Bits and Bites! >> >> >> >> Spencer >> >> >> >> _______________________________________________ >> >> >> >> bfcpbis mailing list >> >> bfcpbis@ietf.org >> >> https://www.ietf.org/mailman/listinfo/bfcpbis = --Apple-Mail=_AA572572-1C21-4E16-9B95-FA577DC56C95 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=windows-1252
Hi Spencer,

Does Charles=92 proposal below work for = you?

Thanks,
Alissa

On Nov = 5, 2015, at 3:42 PM, Charles Eckel (eckelcu) <eckelcu@cisco.com> = wrote:


From: Spencer Dawkins = at IETF <spencerdawkins.ietf@gmail.com>
Date: Friday, = November 6, 2015 at 7:23 AM
To: Alissa Cooper = <alissa@cooperw.in>
Cc: "iesg@ietf.org" <iesg@ietf.org>, "bfcpbis-chairs@ietf.org" <bfcpbis-chairs@ietf.org>, Paul Jones <paulej@packetizer.com>, "gorry@erg.abdn.ac.uk" = <gorry@erg.abdn.ac.uk>, Mary Barnes <mary.ietf.barnes@gmail.com>, "draft-ietf-bfcpbis-rfc4582bis@ietf.org" <draft-ietf-bfcpbis-rfc4582bis@ietf.org>, "bfcpbis@ietf.org" <bfcpbis@ietf.org>, Charles Eckel <eckelcu@cisco.com>
Subject: Re: = [bfcpbis] Spencer Dawkins' Discuss on draft-ietf-bfcpbis-rfc4582bis-15: = (with DISCUSS and COMMENT)

Hi, Alissa,
On Nov 6, 2015 7:06 AM, "Alissa Cooper" <alissa@cooperw.in> = wrote:
>
> Hi Spencer,
>
>
>
> On Nov 5, 2015, at 11:20 PM, Spencer Dawkins at IETF <spencerdawkins.ietf@gmail.com> wrote:
>
>> Hi, Charles,
>>
>> On Thu, Nov 5, 2015 at 5:43 PM, Charles Eckel (eckelcu) <eckelcu@cisco.com> = wrote:
>>>
>>> For TCP, the use of TLS was not required by RFC 4582. For = 4582bis, we do not require TLS in order to maintain backward = compatibility with RFC 4582.
>>
>>
>> Got it. I'm holding my nose on this one, based on backward = compatibility, and given the degree of difficulty in splicing attack = packets into the TCP sequence numbering space if you're off-path. I'm = not thrilled, but someone else needs to decide when threats reach the level where making that incompatible change is necessary - = and that might not be the right thing to do today.
>>  
>>>
>>> For UDP, the reason for not mandating DTLS is backward = compatibility with existing solutions. The IMTC Role Based Video Best = Practice established a set of recommendations for getting BFCP to work =  within enterprise video conference deployments. As that time,draft-sandbakken-xcon-bfcp-udp defined BFCP over UDP only. = DTLS was left for future study. Today we have many implementations of = BFCP over UDP, but few if any using DTLS. We need the ultimate RFC that = standardizes BFCP over UDP (and over DTLS) to allow interworking with these existing deployments.
>>
>>
>> OK, I'm not the Protocol Security Police, so, fine, but it = seems like the draft could be clearer about this, and what you said in = your answer would be really helpful in the document. 
>>
>> If the text said something like "DTLS is REQUIRED unless you = are interworking with a pre-standardization deployment that is already = insecure,
>
>
> "REQUIRED unless" strikes me as a faulty construction. That case is = what RECOMMENDED is for, when there is a known exception to the = requirement.
That usage is certainly = more common in some parts of the IETF than others, but it does get used. = But ignoring that.
Do you think = "RECOMMENDED unless you are interworking with a pre-standardization = deployment that is already insecure" is tight enough?
The reason I'm asking, is that offpath attacks on = UDP-based protocols are a lot easier than TCP-based protocols, and if = the IETF is going to publish a proposed standard with a known deficiency = to accommodate pre-standardization deployments, I'd prefer that the guidance about using that accommodation be as clear as = possible.

I agree with your intent. My concern with calling out exceptions is that = it can make the existing recommendation in the draft seem weaker. How = about this:

OLD:

  =  =85 It is = RECOMMENDED that TLS/DTLS with an
  =  encryption algorithm according to Section 7 always be used. =  In cases
  =  where signaling/control traffic is properly protected, as = described
  =  in Section 9 it is REQUIRED to use a mandated encryption = algorithm.
  =  BFCP entities MAY use other security mechanisms as long as = they
  =  provide similar security properties.

NEW

   =85 It is = RECOMMENDED that TLS/DTLS with an
   encryption algorithm = according to Section 7 always be used.  In cases
   where = signaling/control traffic is properly protected, as = described
   in Section 9 it is = REQUIRED to use a mandated encryption algorithm.
   BFCP entities MAY = use other security mechanisms to interwork with 
   legacy = implementation that do not use TLS/DTLS as long as = these 
  =  mechanisms provide similar security = properties. 

Cheers,
Charles
 

Thanks,
Spencer
> Alissa
>
>> in which case you're not making things worse by running without = transport-level security", that would capture my concern and reflect = what you're saying, unless I'm missing something.
>>
>> Thanks to you and Paul for the speedy response on the evening = of Bits and Bites!
>>
>> Spencer
>>
>> _______________________________________________
>>
>> bfcpbis mailing list
>> = bfcpbis@ietf.org
>> https://www.ietf.org/mailman/listinfo/bfcpbis

= --Apple-Mail=_AA572572-1C21-4E16-9B95-FA577DC56C95-- From nobody Fri Nov 13 09:57:42 2015 Return-Path: X-Original-To: bfcpbis@ietfa.amsl.com Delivered-To: bfcpbis@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 332221ACEEE; Fri, 13 Nov 2015 09:57:40 -0800 (PST) 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 D4zO1GpN_0dH; Fri, 13 Nov 2015 09:57:36 -0800 (PST) Received: from mail-yk0-x232.google.com (mail-yk0-x232.google.com [IPv6:2607:f8b0:4002:c07::232]) (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 2CECE1ACEEB; Fri, 13 Nov 2015 09:57:36 -0800 (PST) Received: by ykfs79 with SMTP id s79so160019277ykf.1; Fri, 13 Nov 2015 09:57:35 -0800 (PST) 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=SHtu9vbKRJcTHIoBom17Xu3yzqEnJhLOAW+t/AbNU/A=; b=PpXaUzNhuJF7YQcll5nBWxg88/tJbsLu9grVKf9UWr0DD2h8/FMmFomcgM+JdKAs4u olREJWNKSUFGfI+n/bjrdeEF4mFpXSmSvWm2L4N0GzPCT0EsfpfLQgJnASmu0c2sQhK1 +kcPE+iVX8CjMNGKgVXgMu29ekwbI7mdkNjm7yRofBqnQjVQvvX5lrpXvEhpKAhB1DGb Lf/7y83YBRqLTaFaVzMCjXQ3Piuw67/dKAWmzSfoylH9vt6tIYNKjarZnvUBvBgIozvE PWSz9ujubJvGf0XMZb/a64fZjMenR12J6uBrIeKkufJttuQAh1Ui2c5b3BzdC8cme9d+ AyRg== MIME-Version: 1.0 X-Received: by 10.129.31.70 with SMTP id f67mr23446942ywf.114.1447437455366; Fri, 13 Nov 2015 09:57:35 -0800 (PST) Received: by 10.31.149.79 with HTTP; Fri, 13 Nov 2015 09:57:35 -0800 (PST) In-Reply-To: <0BAEEA7C-B892-460B-AAD3-80A0F85E766D@cooperw.in> References: <20151105023108.17210.54132.idtracker@ietfa.amsl.com> <19C90DA9-652D-499F-8462-7EC7878307CB@packetizer.com> <5D0066E2-6BD9-4ED8-A37D-CE83118E099E@cooperw.in> <0BAEEA7C-B892-460B-AAD3-80A0F85E766D@cooperw.in> Date: Fri, 13 Nov 2015 11:57:35 -0600 Message-ID: From: Spencer Dawkins at IETF To: Alissa Cooper Content-Type: multipart/alternative; boundary=001a1141e2565ca37f05246fcb4d Archived-At: Cc: "gorry@erg.abdn.ac.uk" , "bfcpbis-chairs@ietf.org" , "bfcpbis@ietf.org" , "Charles Eckel \(eckelcu\)" , "draft-ietf-bfcpbis-rfc4582bis@ietf.org" , "Paul E. Jones" , IESG , Mary Barnes Subject: Re: [bfcpbis] Spencer Dawkins' Discuss on draft-ietf-bfcpbis-rfc4582bis-15: (with DISCUSS and COMMENT) X-BeenThere: bfcpbis@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: BFCPBIS working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 13 Nov 2015 17:57:40 -0000 --001a1141e2565ca37f05246fcb4d Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable So, we're getting there. On Wed, Nov 11, 2015 at 4:38 PM, Alissa Cooper wrote: > Hi Spencer, > > Does Charles=E2=80=99 proposal below work for you? > > Thanks, > Alissa > > On Nov 5, 2015, at 3:42 PM, Charles Eckel (eckelcu) > wrote: > > > From: Spencer Dawkins at IETF > Date: Friday, November 6, 2015 at 7:23 AM > To: Alissa Cooper > Cc: "iesg@ietf.org" , "bfcpbis-chairs@ietf.org" < > bfcpbis-chairs@ietf.org>, Paul Jones , " > gorry@erg.abdn.ac.uk" , Mary Barnes < > mary.ietf.barnes@gmail.com>, "draft-ietf-bfcpbis-rfc4582bis@ietf.org" < > draft-ietf-bfcpbis-rfc4582bis@ietf.org>, "bfcpbis@ietf.org" < > bfcpbis@ietf.org>, Charles Eckel > Subject: Re: [bfcpbis] Spencer Dawkins' Discuss on > draft-ietf-bfcpbis-rfc4582bis-15: (with DISCUSS and COMMENT) > > Hi, Alissa, > On Nov 6, 2015 7:06 AM, "Alissa Cooper" wrote: > > > > Hi Spencer, > > > > > > > > On Nov 5, 2015, at 11:20 PM, Spencer Dawkins at IETF < > spencerdawkins.ietf@gmail.com> wrote: > > > >> Hi, Charles, > >> > >> On Thu, Nov 5, 2015 at 5:43 PM, Charles Eckel (eckelcu) < > eckelcu@cisco.com> wrote: > >>> > >>> For TCP, the use of TLS was not required by RFC 4582. For 4582bis, we > do not require TLS in order to maintain backward compatibility with RFC > 4582. > >> > >> > >> Got it. I'm holding my nose on this one, based on backward > compatibility, and given the degree of difficulty in splicing attack > packets into the TCP sequence numbering space if you're off-path. I'm not > thrilled, but someone else needs to decide when threats reach the level > where making that incompatible change is necessary - and that might not b= e > the right thing to do today. > >> > >>> > >>> For UDP, the reason for not mandating DTLS is backward compatibility > with existing solutions. The IMTC Role Based Video Best Practice > established a set of recommendations for getting BFCP to work within > enterprise video conference deployments. As that > time,draft-sandbakken-xcon-bfcp-udp defined BFCP over UDP only. DTLS was > left for future study. Today we have many implementations of BFCP over UD= P, > but few if any using DTLS. We need the ultimate RFC that standardizes BFC= P > over UDP (and over DTLS) to allow interworking with these existing > deployments. > >> > >> > >> OK, I'm not the Protocol Security Police, so, fine, but it seems like > the draft could be clearer about this, and what you said in your answer > would be really helpful in the document. > >> > >> If the text said something like "DTLS is REQUIRED unless you are > interworking with a pre-standardization deployment that is already insecu= re, > > > > > > "REQUIRED unless" strikes me as a faulty construction. That case is wha= t > RECOMMENDED is for, when there is a known exception to the requirement. > That usage is certainly more common in some parts of the IETF than others= , > but it does get used. But ignoring that. > Do you think "RECOMMENDED unless you are interworking with a > pre-standardization deployment that is already insecure" is tight enough? > The reason I'm asking, is that offpath attacks on UDP-based protocols are > a lot easier than TCP-based protocols, and if the IETF is going to publis= h > a proposed standard with a known deficiency to accommodate > pre-standardization deployments, I'd prefer that the guidance about using > that accommodation be as clear as possible. > > > I agree with your intent. My concern with calling out exceptions is that > it can make the existing recommendation in the draft seem weaker. How abo= ut > this: > > OLD: > > =E2=80=A6 It is RECOMMENDED that TLS/DTLS with an > encryption algorithm according to Section 7 always be used. In cases > where signaling/control traffic is properly protected, as described > in Section 9 it is REQUIRED to use a mandated encryption algorithm. > BFCP entities MAY use other security mechanisms as long as they > provide similar security properties. > > NEW > > =E2=80=A6 It is RECOMMENDED that TLS/DTLS with an > encryption algorithm according to Section 7 always be used. In cases > where signaling/control traffic is properly protected, as described > in Section 9 it is REQUIRED to use a mandated encryption algorithm. > BFCP entities MAY use other security mechanisms to interwork with > legacy implementation that do not use TLS/DTLS as long as these > mechanisms provide similar security properties. > > Probably for Charles: This last sentence seems to be responsible for most of my remaining heartburn. My understanding was that TLS and (especially) DTLS were RECOMMENDED, not REQUIRED, because there are legacy implementations that have been deployed already. I can live with that, but is it obvious to everyone how a legacy receiver tells a sender to use a non-TLS/DTLS mechanism? I'm looking at the "use TLS" and "use DTLS" error codes in Table 5, and wondering where the "use legacy security mechanism" error code might be. Do legacy endpoints "just know" this? Thanks, Spencer > Cheers, > Charles > > > > Thanks, > Spencer > > Alissa > > > >> in which case you're not making things worse by running without > transport-level security", that would capture my concern and reflect what > you're saying, unless I'm missing something. > >> > >> Thanks to you and Paul for the speedy response on the evening of Bits > and Bites! > >> > >> Spencer > >> > >> _______________________________________________ > >> > >> bfcpbis mailing list > >> bfcpbis@ietf.org > >> https://www.ietf.org/mailman/listinfo/bfcpbis > > > --001a1141e2565ca37f05246fcb4d Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
So, we're getting there.
On Wed, Nov 11, 2015 at 4:38 PM, Alissa Cooper = <alissa@cooperw.in> wrote:
Hi Spencer,

<= div>Does Charles=E2=80=99 proposal below work for you?

=
Thanks,
Alissa

On Nov 5, 2015, at 3:42 PM, Charles Eckel (eckelcu) = <eckelcu@cisco.co= m> wrote:


From: Spencer Dawkins at IETF <<= a href=3D"mailto:spencerdawkins.ietf@gmail.com" target=3D"_blank">spencerda= wkins.ietf@gmail.com>
Date: Friday, November 6, 2015 at 7= :23 AM
To: Alissa Cooper <alissa@cooperw.in>
Cc: "iesg@ietf.org" <iesg@ietf.org>, "bfcpbis-chairs@ietf.org&qu= ot; <bfcpbi= s-chairs@ietf.org>, Paul Jones <= paulej@packetizer.com>, "gorry@erg.abdn.ac.uk" <gorry@erg.abdn.ac.uk>, Mary Ba= rnes <ma= ry.ietf.barnes@gmail.com>, "draft-ietf-bfcpbis-rfc4582bis@ietf.org" <draft-ietf-bf= cpbis-rfc4582bis@ietf.org>, "bfcpbis@ietf.org" <bfcpbis@ietf.org= >, Charles Eckel <eckelcu@cisco.com>
Subject: Re: [bfcpbis] Spencer Dawk= ins' Discuss on draft-ietf-bfcpbis-rfc4582bis-15: (with DISCUSS and COM= MENT)

Hi, Alissa,
On Nov 6, 2015 7:06= AM, "Alissa Cooper" <alissa@cooperw.in> wrote:
>
> Hi Spencer,
>
>
>
> On Nov 5, 2015, at 11:20 PM, Spencer Dawkins at IETF <spencerdawkins.ietf@g= mail.com> wrote:
>
>> Hi, Charles,
>>
>> On Thu, Nov 5, 2015 at 5:43 PM, Charles Eckel (eckelcu) <eckelcu@cisco.com> = wrote:
>>>
>>> For TCP, the use of TLS was not required by RFC 4582. For 4582= bis, we do not require TLS in order to maintain backward compatibility with= RFC 4582.
>>
>>
>> Got it. I'm holding my nose on this one, based on backward com= patibility, and given the degree of difficulty in splicing attack packets i= nto the TCP sequence numbering space if you're off-path. I'm not th= rilled, but someone else needs to decide when threats reach the level where making that incompatible change is necessary - and t= hat might not be the right thing to do today.
>> =C2=A0
>>>
>>> For UDP, the reason for not mandating DTLS is backward compati= bility with existing solutions. The IMTC Role Based Video Best Practice est= ablished a set of recommendations for getting BFCP to work =C2=A0within ent= erprise video conference deployments. As that time,draft-sandbakken-xcon-bfcp-udp=C2=A0defined BFCP over UDP only. DTLS = was left for future study. Today we have many implementations of BFCP over = UDP, but few if any using DTLS. We need the ultimate RFC that standardizes = BFCP over UDP (and over DTLS) to allow interworking with these existing deployments.
>>
>>
>> OK, I'm not the Protocol Security Police, so, fine, but it see= ms like the draft could be clearer about this, and what you said in your an= swer would be really helpful in the document.=C2=A0
>>
>> If the text said something like "DTLS is REQUIRED unless you = are interworking with a pre-standardization deployment that is already inse= cure,
>
>
> "REQUIRED unless" strikes me as a faulty construction. That = case is what RECOMMENDED is for, when there is a known exception to the req= uirement.
That usage is certainly more common in some= parts of the IETF than others, but it does get used. But ignoring that.
Do you think "RECOMMENDED unless you are interwork= ing with a pre-standardization deployment that is already insecure" is= tight enough?
The reason I'm asking, is that off= path attacks on UDP-based protocols are a lot easier than TCP-based protoco= ls, and if the IETF is going to publish a proposed standard with a known de= ficiency to accommodate pre-standardization deployments, I'd prefer that the guidance about using that accommodation be as clear as pos= sible.

I agree with your intent. My concern with calling out exceptions is that it= can make the existing recommendation in the draft seem weaker. How about t= his:

OLD:

=C2=A0 =C2=A0=E2=80=A6 It is RECOMMENDED that TLS/DTLS with an<= /div>
=C2=A0 =C2=A0encryption algorithm ac= cording to Section 7 always be used.=C2=A0 In cases
=C2=A0 =C2=A0where signaling/control= traffic is properly protected, as described
=C2=A0 =C2=A0in Section 9 it is REQU= IRED to use a mandated encryption algorithm.
=C2=A0 =C2=A0BFCP entities MAY use o= ther security mechanisms as long as they
=C2=A0 =C2=A0provide similar securit= y properties.

NEW

=C2=A0 =C2=A0=E2=80=A6 It is RECOMMENDED = that TLS/DTLS with an
=C2=A0 =C2=A0encryption algorithm according to Section 7 always be= used.=C2=A0 In cases
=C2=A0 =C2=A0where signaling/control traffic is properly protected= , as described
=C2=A0 =C2=A0in Section 9 it is REQUIRED to use a mandated encrypt= ion algorithm.
=C2=A0 =C2=A0BFCP entities MAY use other security mechanisms to in= terwork with=C2=A0
=C2=A0 =C2=A0legacy implementation that do not use TLS/DTLS as lon= g as these=C2=A0
=C2=A0 =C2=A0mechanisms=C2=A0provide similar security properties.=C2=A0

<= /div>
Probably for Charles:

This last sentence= seems to be responsible for most of my remaining heartburn.=C2=A0

My understanding was that TLS and (especially) DTLS were R= ECOMMENDED, not REQUIRED, because there are legacy implementations that hav= e been deployed already. I can live with that, but is it obvious to everyon= e how a legacy receiver tells a sender to use a non-TLS/DTLS mechanism? I&#= 39;m looking at the "use TLS" and "use DTLS" error code= s in Table 5, and wondering where the "use legacy security mechanism&q= uot; error code might be.=C2=A0

Do legacy endpoint= s "just know" this?

Thanks,
Spencer
=C2=A0
<= div style=3D"word-wrap:break-word">
Cheers,
Charles
=C2=A0

Thanks,
Spencer<= /div>
> Alissa
>
>> in which case you're not making things worse by running withou= t transport-level security", that would capture my concern and reflect= what you're saying, unless I'm missing something.
>>
>> Thanks to you and Paul for the speedy response on the evening of B= its and Bites!
>>
>> Spencer
>>
>> _______________________________________________
>>
>> bfcpbis mailing list
>> bfcpbis@ietf= .org
>> https://www.ietf.org/mailman/listinfo/bfcpbis


--001a1141e2565ca37f05246fcb4d-- From nobody Fri Nov 13 10:44:43 2015 Return-Path: X-Original-To: bfcpbis@ietfa.amsl.com Delivered-To: bfcpbis@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6F5591B2B40 for ; Fri, 13 Nov 2015 10:44:42 -0800 (PST) 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 swSwj6msc0Gl for ; Fri, 13 Nov 2015 10:44:40 -0800 (PST) Received: from rcdn-iport-8.cisco.com (rcdn-iport-8.cisco.com [173.37.86.79]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 896AA1B2B31 for ; Fri, 13 Nov 2015 10:44:40 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=3057; q=dns/txt; s=iport; t=1447440280; x=1448649880; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=S1IGNREkIpVYLtLzmd+mHfyGU4MMh5BkaG/tNznry80=; b=WrxxrIc/NdIajccYO9lGC5iakWn1Em++5d/9J/dI1aH+m+pEb4TEaQjj 0sMmYDfd9A9ozZ9wcoA9mt8o//6UYz6AfwYGNHdWlUmLsJVDUoqbRnwVh 9c1PLXf1RGJX8b5WDD63Dd+oOAKeicivwlya9Nkyvj/XQT9NnaTlOFHRM 8=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0AnAgBML0ZW/5xdJa1egztTbwa+QQENg?= =?us-ascii?q?WUXCoUlSgKBOzgUAQEBAQEBAYEKhDUBAQQBAQFrCxACAQgYLicLJQIEAQ0FiC4?= =?us-ascii?q?NwEoBAQEBAQEBAQEBAQEBAQEBAQEBAQEYi1KEWYRgBY1UiHQBhRyICoFbSYN3l?= =?us-ascii?q?ikBHwEBQoQEcoQ2gQcBAQE?= X-IronPort-AV: E=Sophos;i="5.20,288,1444694400"; d="scan'208";a="44726177" Received: from rcdn-core-5.cisco.com ([173.37.93.156]) by rcdn-iport-8.cisco.com with ESMTP; 13 Nov 2015 18:44:32 +0000 Received: from XCH-ALN-019.cisco.com (xch-aln-019.cisco.com [173.36.7.29]) by rcdn-core-5.cisco.com (8.14.5/8.14.5) with ESMTP id tADIiW9w004279 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Fri, 13 Nov 2015 18:44:32 GMT Received: from xch-aln-018.cisco.com (173.36.7.28) by XCH-ALN-019.cisco.com (173.36.7.29) with Microsoft SMTP Server (TLS) id 15.0.1104.5; Fri, 13 Nov 2015 12:44:32 -0600 Received: from xch-aln-018.cisco.com ([173.36.7.28]) by XCH-ALN-018.cisco.com ([173.36.7.28]) with mapi id 15.00.1104.000; Fri, 13 Nov 2015 12:44:32 -0600 From: "Charles Eckel (eckelcu)" To: "Gonzalo Salgueiro (gsalguei)" , "bfcpbis@ietf.org" , "christer.holmberg@ericsson.com" Thread-Topic: [bfcpbis] I-D Action: draft-ietf-bfcpbis-bfcp-websocket-05.txt Thread-Index: AQHRBdZW52xxX/jQ5U+TKdh+0zIhOZ5p+f6AgDBfdwA= Date: Fri, 13 Nov 2015 18:44:32 +0000 Message-ID: References: <20151013164348.9920.89287.idtracker@ietfa.amsl.com> <6D74D935-2204-49AD-9CDA-D432A74BD477@cisco.com> In-Reply-To: <6D74D935-2204-49AD-9CDA-D432A74BD477@cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.5.7.151005 x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.24.78.221] Content-Type: text/plain; charset="iso-8859-1" Content-ID: <1E261E210CBED94BAD593CBAF91FA515@emea.cisco.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Cc: "Ram Mohan R \(rmohanr\)" , "bfcpbis-chairs@tools.ietf.org" Subject: Re: [bfcpbis] I-D Action: draft-ietf-bfcpbis-bfcp-websocket-05.txt X-BeenThere: bfcpbis@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: BFCPBIS working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 13 Nov 2015 18:44:42 -0000 Christer reviewed draft-ram-bfcpbis-sdp-ws-uri and recommended substantial changes to it. The authors have not yet responded to that. Regarding draft-ietf-bfcpbis-bfcp-websocket, I=B9d like to see this respons= e and potential impacts on either/both drafts before starting WGLC for draft-ietf-bfcpbis-bfcp-websocket. Cheers, Charles On 10/13/15, 10:02 AM, "bfcpbis on behalf of Gonzalo Salgueiro (gsalguei)" wrote: >New version of the draft has been published and addresses all open >comments raised by Christer. At this point authors feel this is ready >for WGLC. > >There is a pending request for Christer to review the complementary draft >he requested >(draft-ram-bfcpbis-sdp-ws-uri-00) be split off from the original >document. Once this is done, we ask the chairs for guidance on how best >to progress this spin-off draft. > >Thanks, > >Gonzalo > >> On Oct 13, 2015, at 12:43 PM, internet-drafts@ietf.org wrote: >>=20 >>=20 >> A New Internet-Draft is available from the on-line Internet-Drafts >>directories. >> This draft is a work item of the Binary Floor Control Protocol Bis >>Working Group of the IETF. >>=20 >> Title : The WebSocket Protocol as a Transport for the >>Binary Floor Control Protocol (BFCP) >> Authors : Victor Pascual >> Ant=F3n Rom=E1n >> St=E9phane Cazeaux >> Gonzalo Salgueiro >> Ram Mohan Ravindranath >> Sergio Garcia Murillo >> Filename : draft-ietf-bfcpbis-bfcp-websocket-05.txt >> Pages : 14 >> Date : 2015-10-13 >>=20 >> Abstract: >> The WebSocket protocol enables two-way realtime communication between >> clients and servers. This document specifies a new WebSocket sub- >> protocol as a reliable transport mechanism between Binary Floor >> Control Protocol (BFCP) entities to enable usage of BFCP in new >> scenarios. >>=20 >>=20 >> The IETF datatracker status page for this draft is: >> https://datatracker.ietf.org/doc/draft-ietf-bfcpbis-bfcp-websocket/ >>=20 >> There's also a htmlized version available at: >> https://tools.ietf.org/html/draft-ietf-bfcpbis-bfcp-websocket-05 >>=20 >> A diff from the previous version is available at: >> https://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-bfcpbis-bfcp-websocket-05 >>=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 >> Internet-Drafts are also available by anonymous FTP at: >> ftp://ftp.ietf.org/internet-drafts/ >>=20 >> _______________________________________________ >> bfcpbis mailing list >> bfcpbis@ietf.org >> https://www.ietf.org/mailman/listinfo/bfcpbis > >_______________________________________________ >bfcpbis mailing list >bfcpbis@ietf.org >https://www.ietf.org/mailman/listinfo/bfcpbis From nobody Fri Nov 13 11:11:49 2015 Return-Path: X-Original-To: bfcpbis@ietfa.amsl.com Delivered-To: bfcpbis@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 36A8E1B2D9A; Fri, 13 Nov 2015 11:11:44 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -13.91 X-Spam-Level: X-Spam-Status: No, score=-13.91 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, J_CHICKENPOX_111=0.6, 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 JkXiSQzHL9aO; Fri, 13 Nov 2015 11:11:40 -0800 (PST) Received: from rcdn-iport-4.cisco.com (rcdn-iport-4.cisco.com [173.37.86.75]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 47AE51B2CBA; Fri, 13 Nov 2015 11:11:40 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=48357; q=dns/txt; s=iport; t=1447441900; x=1448651500; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=X/mU8Wj5AmIxpBR5Of8Xy+vWREFnIEbP4149FzVcWMI=; b=cNzA+cRA5kRhlPICY+QwMvgoZNUjxWBjrp0diDhanTgbzpL0sKMsKk5A uBdZHiNZuwOCpddGtoaJZ+wyJqtKiqBtmMRO0/S7qwKT9DIBa84SQvhjG KgzJVdHTtLo4yDQFfFFEo4oKIOkOngHwmsQA73HVZfh6+IYgbXzlRqJ2I o=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0ApAgCzNEZW/40NJK1egm5NU28GvkEBD?= =?us-ascii?q?YFiAxcBCYUlSgKBOzgUAQEBAQEBAYEKhDQBAQEDAQEBASo7BgsFCwIBCBEDAQI?= =?us-ascii?q?BIAECBAchBgsUCQgCBAENBRuHfgMKCA27Xw2EVwEBAQEBAQEBAQEBAQEBAQEBA?= =?us-ascii?q?QEBARQEi1KCU4IoDYQxBYdOhn+EGoNhAYgNgySBdYFbhECOV4Nhg3EBHwEBQoI?= =?us-ascii?q?RHRaBQHIBhDWBBwEBAQ?= X-IronPort-AV: E=Sophos; i="5.20,288,1444694400"; d="scan'208,217"; a="46513131" Received: from alln-core-8.cisco.com ([173.36.13.141]) by rcdn-iport-4.cisco.com with ESMTP; 13 Nov 2015 19:11:38 +0000 Received: from XCH-ALN-020.cisco.com (xch-aln-020.cisco.com [173.36.7.30]) by alln-core-8.cisco.com (8.14.5/8.14.5) with ESMTP id tADJBcEn004944 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Fri, 13 Nov 2015 19:11:38 GMT Received: from xch-aln-018.cisco.com (173.36.7.28) by XCH-ALN-020.cisco.com (173.36.7.30) with Microsoft SMTP Server (TLS) id 15.0.1104.5; Fri, 13 Nov 2015 13:11:38 -0600 Received: from xch-aln-018.cisco.com ([173.36.7.28]) by XCH-ALN-018.cisco.com ([173.36.7.28]) with mapi id 15.00.1104.000; Fri, 13 Nov 2015 13:11:38 -0600 From: "Charles Eckel (eckelcu)" To: Spencer Dawkins at IETF , Alissa Cooper Thread-Topic: [bfcpbis] Spencer Dawkins' Discuss on draft-ietf-bfcpbis-rfc4582bis-15: (with DISCUSS and COMMENT) Thread-Index: AQHRF3IJ5JJDWYYKUEOdhULB9tmr356NOVMAgAAGM4CAANkWAP//x2GAgACCJ4CAAASuAIAArPmAgAjFKICAAtZLgP//jpIA Date: Fri, 13 Nov 2015 19:11:38 +0000 Message-ID: References: <20151105023108.17210.54132.idtracker@ietfa.amsl.com> <19C90DA9-652D-499F-8462-7EC7878307CB@packetizer.com> <5D0066E2-6BD9-4ED8-A37D-CE83118E099E@cooperw.in> <0BAEEA7C-B892-460B-AAD3-80A0F85E766D@cooperw.in> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.5.7.151005 x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.24.78.221] Content-Type: multipart/alternative; boundary="_000_D26B71875EAB9eckelcuciscocom_" MIME-Version: 1.0 Archived-At: Cc: "gorry@erg.abdn.ac.uk" , "bfcpbis-chairs@ietf.org" , "bfcpbis@ietf.org" , "draft-ietf-bfcpbis-rfc4582bis@ietf.org" , "Paul E. Jones" , IESG , Mary Barnes Subject: Re: [bfcpbis] Spencer Dawkins' Discuss on draft-ietf-bfcpbis-rfc4582bis-15: (with DISCUSS and COMMENT) X-BeenThere: bfcpbis@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: BFCPBIS working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 13 Nov 2015 19:11:44 -0000 --_000_D26B71875EAB9eckelcuciscocom_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable Hi Spencer, Please see inline. From: Spencer Dawkins at IETF > Date: Saturday, November 14, 2015 at 2:57 AM To: Alissa Cooper > Cc: IESG >, "bfcpbis-chairs@ietf.org" >, Paul Jones >, "gorry@erg.abdn.ac.uk" >, Mary Barnes >, "draft-ietf-bfcpbis-rfc4582bis@ietf.o= rg" >, "bfcpbis@i= etf.org" >, Charles Eckel > Subject: Re: [bfcpbis] Spencer Dawkins' Discuss on draft-ietf-bfcpbis-rfc45= 82bis-15: (with DISCUSS and COMMENT) So, we're getting there. On Wed, Nov 11, 2015 at 4:38 PM, Alissa Cooper > wrote: Hi Spencer, Does Charles=92 proposal below work for you? Thanks, Alissa On Nov 5, 2015, at 3:42 PM, Charles Eckel (eckelcu) > wrote: From: Spencer Dawkins at IETF > Date: Friday, November 6, 2015 at 7:23 AM To: Alissa Cooper > Cc: "iesg@ietf.org" >, "bfcpbis-chairs@ietf.org" >, Paul Jones >, "gorry@erg.abdn.ac.uk" >, Mary B= arnes >, "dra= ft-ietf-bfcpbis-rfc4582bis@ietf.org" >, "bfcpbis@ietf.org" >, Charles Eckel > Subject: Re: [bfcpbis] Spencer Dawkins' Discuss on draft-ietf-bfcpbis-rfc45= 82bis-15: (with DISCUSS and COMMENT) Hi, Alissa, On Nov 6, 2015 7:06 AM, "Alissa Cooper" > wrote: > > Hi Spencer, > > > > On Nov 5, 2015, at 11:20 PM, Spencer Dawkins at IETF > wrote: > >> Hi, Charles, >> >> On Thu, Nov 5, 2015 at 5:43 PM, Charles Eckel (eckelcu) > wrote: >>> >>> For TCP, the use of TLS was not required by RFC 4582. For 4582bis, we d= o not require TLS in order to maintain backward compatibility with RFC 4582= . >> >> >> Got it. I'm holding my nose on this one, based on backward compatibility= , and given the degree of difficulty in splicing attack packets into the TC= P sequence numbering space if you're off-path. I'm not thrilled, but someon= e else needs to decide when threats reach the level where making that incom= patible change is necessary - and that might not be the right thing to do t= oday. >> >>> >>> For UDP, the reason for not mandating DTLS is backward compatibility wi= th existing solutions. The IMTC Role Based Video Best Practice established = a set of recommendations for getting BFCP to work within enterprise video = conference deployments. As that time,draft-sandbakken-xcon-bfcp-udp defined= BFCP over UDP only. DTLS was left for future study. Today we have many imp= lementations of BFCP over UDP, but few if any using DTLS. We need the ultim= ate RFC that standardizes BFCP over UDP (and over DTLS) to allow interworki= ng with these existing deployments. >> >> >> OK, I'm not the Protocol Security Police, so, fine, but it seems like th= e draft could be clearer about this, and what you said in your answer would= be really helpful in the document. >> >> If the text said something like "DTLS is REQUIRED unless you are interwo= rking with a pre-standardization deployment that is already insecure, > > > "REQUIRED unless" strikes me as a faulty construction. That case is what = RECOMMENDED is for, when there is a known exception to the requirement. That usage is certainly more common in some parts of the IETF than others, = but it does get used. But ignoring that. Do you think "RECOMMENDED unless you are interworking with a pre-standardiz= ation deployment that is already insecure" is tight enough? The reason I'm asking, is that offpath attacks on UDP-based protocols are a= lot easier than TCP-based protocols, and if the IETF is going to publish a= proposed standard with a known deficiency to accommodate pre-standardizati= on deployments, I'd prefer that the guidance about using that accommodation= be as clear as possible. I agree with your intent. My concern with calling out exceptions is that it= can make the existing recommendation in the draft seem weaker. How about t= his: OLD: =85 It is RECOMMENDED that TLS/DTLS with an encryption algorithm according to Section 7 always be used. In cases where signaling/control traffic is properly protected, as described in Section 9 it is REQUIRED to use a mandated encryption algorithm. BFCP entities MAY use other security mechanisms as long as they provide similar security properties. NEW =85 It is RECOMMENDED that TLS/DTLS with an encryption algorithm according to Section 7 always be used. In cases where signaling/control traffic is properly protected, as described in Section 9 it is REQUIRED to use a mandated encryption algorithm. BFCP entities MAY use other security mechanisms to interwork with legacy implementation that do not use TLS/DTLS as long as these mechanisms provide similar security properties. Probably for Charles: This last sentence seems to be responsible for most of my remaining heartbu= rn. My understanding was that TLS and (especially) DTLS were RECOMMENDED, not R= EQUIRED, because there are legacy implementations that have been deployed a= lready. I can live with that, but is it obvious to everyone how a legacy re= ceiver tells a sender to use a non-TLS/DTLS mechanism? I'm looking at the "= use TLS" and "use DTLS" error codes in Table 5, and wondering where the "us= e legacy security mechanism" error code might be. Do legacy endpoints "just know" this? This draft describes how to use SDP to establish a BFCP connection. The det= ermination of whether to use TLS or TCP or DTLS or UDP is based on the SDP = offer/answer and the specification within it of the m-line, e.g. m=3Dapplication 50000 UDP/BFCP * m=3Dapplication 50000 TCP/BFCP * m=3Dapplication 50000 TCP/TLS/BFCP * m=3Dapplication 50000 UDP/TLS/BFCP * When making the offer, an implementation has a choice of using any of these= and the answerer can choose to accept of reject. Some very implementations= supported TCP only. Most current implementations support UDP only or in ad= dition to TCP. In the future, we hope all with support DTLS. Typically impl= ementation the support more than one transport provide configuration option= s, such as require DTLS, or offer DTLS but accept UDP or DTLS, or offer DTL= S first and if rejected offer UDP. The current IMTC best practice recommend= s offering UDP and if that fails offer TCP. This will be updated to include= DTLS once RFC4583bis is published. Cheers, Charles Thanks, Spencer Cheers, Charles Thanks, Spencer > Alissa > >> in which case you're not making things worse by running without transpor= t-level security", that would capture my concern and reflect what you're sa= ying, unless I'm missing something. >> >> Thanks to you and Paul for the speedy response on the evening of Bits an= d Bites! >> >> Spencer >> >> _______________________________________________ >> >> bfcpbis mailing list >> bfcpbis@ietf.org >> https://www.ietf.org/mailman/listinfo/bfcpbis --_000_D26B71875EAB9eckelcuciscocom_ Content-Type: text/html; charset="Windows-1252" Content-ID: <933105159ABE6840BF295363E4C57D81@emea.cisco.com> Content-Transfer-Encoding: quoted-printable
Hi Spencer,

Please see inline.

From: Spencer Dawkins at IETF <<= a href=3D"mailto:spencerdawkins.ietf@gmail.com">spencerdawkins.ietf@gmail.c= om>
Date: Saturday, November 14, 2015 a= t 2:57 AM
To: Alissa Cooper <alissa@cooperw.in>
Cc: IESG <iesg@ietf.org>, "bfcpbis-chairs@ietf.org" <bfcpbis-chairs@ietf.org>, Paul Jones <paulej@packetizer.com>, "gorry@erg.abdn.ac.uk&quo= t; <gorry@erg.abdn.ac.uk>= , Mary Barnes <mary.ietf.b= arnes@gmail.com>, "draft-ietf-bfcpbis-rfc4582bis@ietf.org" <draft-ietf-b= fcpbis-rfc4582bis@ietf.org>, "bfcpbis@ietf.org" <bfcpb= is@ietf.org>, Charles Eckel <eckelcu@cisco.com>
Subject: Re: [bfcpbis] Spencer Dawk= ins' Discuss on draft-ietf-bfcpbis-rfc4582bis-15: (with DISCUSS and COMMENT= )

So, we're getting there.

On Wed, Nov 11, 2015 at 4:38 PM, Alissa Cooper <= span dir=3D"ltr"> <alissa@cooperw.i= n> wrote:
Hi Spencer,

Does Charles=92 proposal below work for you?

Thanks,
Alissa

On Nov 5, 2015, at 3:42 PM, Charles Eckel (eckelcu) <eckelcu@cisco.com> wrote:

From: Spencer Dawkins at IETF <<= a href=3D"mailto:spencerdawkins.ietf@gmail.com" target=3D"_blank">spencerda= wkins.ietf@gmail.com>
Date: Friday, November 6, 2015 at 7= :23 AM
To: Alissa Cooper <alissa@cooperw.in>
Cc: "iesg@ietf.org" <iesg@ietf.org>, "bfcpbis-chairs@ietf.org&qu= ot; <bfcpbis-c= hairs@ietf.org>, Paul Jones <paulej@packetizer.com>, "gorry@erg.abdn.ac.uk" <gorry@erg.ab= dn.ac.uk>, Mary Barnes <mary.ietf.barnes@gmail.com>, "draft-iet= f-bfcpbis-rfc4582bis@ietf.org" <draft-ietf-bfcpbis-rfc4582bis@ietf.org>, "bfcpbis@ietf.org" <bfcpbis@ietf.org>, Charles Eckel <e= ckelcu@cisco.com>
Subject: Re: [bfcpbis] Spencer Dawk= ins' Discuss on draft-ietf-bfcpbis-rfc4582bis-15: (with DISCUSS and COMMENT= )

Hi, Alissa,
On Nov 6, 2015 7:06 AM, "Alissa Cooper" <alissa@cooperw.in>= ; wrote:
>
> Hi Spencer,
>
>
>
> On Nov 5, 2015, at 11:20 PM, Spencer Dawkins at IETF <spencerdawkins.ietf@g= mail.com> wrote:
>
>> Hi, Charles,
>>
>> On Thu, Nov 5, 2015 at 5:43 PM, Charles Eckel (eckelcu) <eckelcu@cisco.com> = wrote:
>>>
>>> For TCP, the use of TLS was not required by RFC 4582. For 4582= bis, we do not require TLS in order to maintain backward compatibility with= RFC 4582.
>>
>>
>> Got it. I'm holding my nose on this one, based on backward compati= bility, and given the degree of difficulty in splicing attack packets into = the TCP sequence numbering space if you're off-path. I'm not thrilled, but = someone else needs to decide when threats reach the level where making that incompatible change is necessary - and t= hat might not be the right thing to do today.
>>  
>>>
>>> For UDP, the reason for not mandating DTLS is backward compati= bility with existing solutions. The IMTC Role Based Video Best Practice est= ablished a set of recommendations for getting BFCP to work  within ent= erprise video conference deployments. As that time,draft-sandbakken-xcon-bfcp-udp defined BFCP over UDP only. DTLS = was left for future study. Today we have many implementations of BFCP over = UDP, but few if any using DTLS. We need the ultimate RFC that standardizes = BFCP over UDP (and over DTLS) to allow interworking with these existing deployments.
>>
>>
>> OK, I'm not the Protocol Security Police, so, fine, but it seems l= ike the draft could be clearer about this, and what you said in your answer= would be really helpful in the document. 
>>
>> If the text said something like "DTLS is REQUIRED unless you = are interworking with a pre-standardization deployment that is already inse= cure,
>
>
> "REQUIRED unless" strikes me as a faulty construction. That = case is what RECOMMENDED is for, when there is a known exception to the req= uirement.
That usage is certainly more common in some parts of the I= ETF than others, but it does get used. But ignoring that.
Do you think "RECOMMENDED unless you are interworking= with a pre-standardization deployment that is already insecure" is ti= ght enough?
The reason I'm asking, is that offpath attacks on UDP-base= d protocols are a lot easier than TCP-based protocols, and if the IETF is g= oing to publish a proposed standard with a known deficiency to accommodate = pre-standardization deployments, I'd prefer that the guidance about using that accommodation be as clear as pos= sible.

I agree with y= our intent. My concern with calling out exceptions is that it can make the = existing recommendation in the draft seem weaker. How about this:

OLD:

   =85 It is RECOMMENDED that TLS/DTLS with an
   encryption algorithm ac= cording to Section 7 always be used.  In cases
   where signaling/control= traffic is properly protected, as described
   in Section 9 it is REQU= IRED to use a mandated encryption algorithm.
   BFCP entities MAY use o= ther security mechanisms as long as they
   provide similar securit= y properties.

NEW

   =85 It is RECOMMENDED that T= LS/DTLS with an
   encryption algorithm according to Section 7 always be= used.  In cases
   where signaling/control traffic is properly protected= , as described
   in Section 9 it is REQUIRED to use a mandated encrypt= ion algorithm.
   BFCP entities MAY use other security mechanisms to in= terwork with 
   legacy implementation that do not use TLS/DTLS as lon= g as these 
   mechanisms provide similar security properties. 

Probably for Charles:

This last sentence seems to be responsible for most of my remaining he= artburn. 

My understanding was that TLS and (especially) DTLS were RECOMMENDED, = not REQUIRED, because there are legacy implementations that have been deplo= yed already. I can live with that, but is it obvious to everyone how a lega= cy receiver tells a sender to use a non-TLS/DTLS mechanism? I'm looking at the "use TLS" and "= ;use DTLS" error codes in Table 5, and wondering where the "use l= egacy security mechanism" error code might be. 

Do legacy endpoints "just know" this?

This draf= t describes how to use SDP to establish a BFCP connection. The determinatio= n of whether to use TLS or TCP or DTLS or UDP is based on the SDP offer/ans= wer and the specification within it of the m-line, e.g.

m=3Dapplication 50000 UDP/BFCP *

m=3Dapplication 50000 TCP/BFCP *

m=3Dapplication 50000 TCP/TLS/BFCP *

m=3Dapplication 50000 UDP/TLS/BFCP *


When making the offer, an implementation has a choice of using any of = these and the answerer can choose to accept of reject. Some very implementa= tions supported TCP only. Most current implementations support UDP only or = in addition to TCP. In the future, we hope all with support DTLS. Typically implementation the support more t= han one transport provide configuration options, such as require DTLS, or o= ffer DTLS but accept UDP or DTLS, or offer DTLS first and if rejected offer= UDP. The current IMTC best practice recommends offering UDP and if that fails offer TCP. This will be updated = to include DTLS once RFC4583bis is published.  

Cheers,
Charles

Thanks,

Spencer
 
Cheers,
Charles
 

Thanks,
Spencer
> Alissa
>
>> in which case you're not making things worse by running without tr= ansport-level security", that would capture my concern and reflect wha= t you're saying, unless I'm missing something.
>>
>> Thanks to you and Paul for the speedy response on the evening of B= its and Bites!
>>
>> Spencer
>>
>> _______________________________________________
>>
>> bfcpbis mailing list
>> bfcpbis@ietf= .org
>> https://www.ietf.org/mailman/listinfo/bfcpbis


 --_000_D26B71875EAB9eckelcuciscocom_-- From nobody Fri Nov 13 12:51:33 2015 Return-Path: X-Original-To: bfcpbis@ietfa.amsl.com Delivered-To: bfcpbis@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2A3481B313B; Fri, 13 Nov 2015 12:51:29 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.399 X-Spam-Level: X-Spam-Status: No, score=-1.399 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, J_CHICKENPOX_111=0.6, 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 lRsoBcCovedc; Fri, 13 Nov 2015 12:51:26 -0800 (PST) Received: from mail-yk0-x231.google.com (mail-yk0-x231.google.com [IPv6:2607:f8b0:4002:c07::231]) (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 D08801B3138; Fri, 13 Nov 2015 12:51:23 -0800 (PST) Received: by ykba77 with SMTP id a77so167450550ykb.2; Fri, 13 Nov 2015 12:51:23 -0800 (PST) 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=nDhMhRzJlWC2c+l2com+mxnm9xJJi2DVv06hXtG4GlE=; b=FfTMiC0w+O5QWFZzFsHo3j3ykQb12z8KaxpjgRvahgGEgktsQtGaN55Dv30zO3sgfs xluKQAxTS0TPPTVkFQFhbijEzYIODFIbHckHMegnybm4TZagFiBzDBZGeUBEpnrfTmH3 i5BP2EkAucTPOikf3zezM0cRGcaZ5sakgCRXGhHrtFMWlyAoounefZtcH92MIQ8/nNpb 28/8ZmInNbx7aH/wRvjE8t/zPbfeoUPRSi3zNz2ED3XKmzXFsgi26T1mMn17M8cmjTew BiC/9gGVUhl3zr94fvR4LqXnIV12zArNnrUoVSwMVEGB7uZD8PsYU9A/4JZVYFUVJfkR meaQ== MIME-Version: 1.0 X-Received: by 10.129.13.213 with SMTP id 204mr25960947ywn.281.1447447883016; Fri, 13 Nov 2015 12:51:23 -0800 (PST) Received: by 10.31.149.79 with HTTP; Fri, 13 Nov 2015 12:51:22 -0800 (PST) In-Reply-To: References: <20151105023108.17210.54132.idtracker@ietfa.amsl.com> <19C90DA9-652D-499F-8462-7EC7878307CB@packetizer.com> <5D0066E2-6BD9-4ED8-A37D-CE83118E099E@cooperw.in> <0BAEEA7C-B892-460B-AAD3-80A0F85E766D@cooperw.in> Date: Fri, 13 Nov 2015 14:51:22 -0600 Message-ID: From: Spencer Dawkins at IETF To: "Charles Eckel (eckelcu)" Content-Type: multipart/alternative; boundary=001a1145ed86e5f28405247238fa Archived-At: Cc: "gorry@erg.abdn.ac.uk" , "bfcpbis-chairs@ietf.org" , "bfcpbis@ietf.org" , Alissa Cooper , "draft-ietf-bfcpbis-rfc4582bis@ietf.org" , "Paul E. Jones" , IESG , Mary Barnes Subject: Re: [bfcpbis] Spencer Dawkins' Discuss on draft-ietf-bfcpbis-rfc4582bis-15: (with DISCUSS and COMMENT) X-BeenThere: bfcpbis@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: BFCPBIS working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 13 Nov 2015 20:51:29 -0000 --001a1145ed86e5f28405247238fa Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Hi, Charles, On Fri, Nov 13, 2015 at 1:11 PM, Charles Eckel (eckelcu) wrote: > Hi Spencer, > > Please see inline. > > From: Spencer Dawkins at IETF > Date: Saturday, November 14, 2015 at 2:57 AM > To: Alissa Cooper > Cc: IESG , "bfcpbis-chairs@ietf.org" < > bfcpbis-chairs@ietf.org>, Paul Jones , " > gorry@erg.abdn.ac.uk" , Mary Barnes < > mary.ietf.barnes@gmail.com>, "draft-ietf-bfcpbis-rfc4582bis@ietf.org" < > draft-ietf-bfcpbis-rfc4582bis@ietf.org>, "bfcpbis@ietf.org" < > bfcpbis@ietf.org>, Charles Eckel > > Subject: Re: [bfcpbis] Spencer Dawkins' Discuss on > draft-ietf-bfcpbis-rfc4582bis-15: (with DISCUSS and COMMENT) > > So, we're getting there. > > On Wed, Nov 11, 2015 at 4:38 PM, Alissa Cooper wrote: > >> Hi Spencer, >> >> Does Charles=E2=80=99 proposal below work for you? >> >> Thanks, >> Alissa >> >> On Nov 5, 2015, at 3:42 PM, Charles Eckel (eckelcu) >> wrote: >> >> >> From: Spencer Dawkins at IETF >> Date: Friday, November 6, 2015 at 7:23 AM >> To: Alissa Cooper >> Cc: "iesg@ietf.org" , "bfcpbis-chairs@ietf.org" < >> bfcpbis-chairs@ietf.org>, Paul Jones , " >> gorry@erg.abdn.ac.uk" , Mary Barnes < >> mary.ietf.barnes@gmail.com>, "draft-ietf-bfcpbis-rfc4582bis@ietf.org" < >> draft-ietf-bfcpbis-rfc4582bis@ietf.org>, "bfcpbis@ietf.org" < >> bfcpbis@ietf.org>, Charles Eckel >> Subject: Re: [bfcpbis] Spencer Dawkins' Discuss on >> draft-ietf-bfcpbis-rfc4582bis-15: (with DISCUSS and COMMENT) >> >> Hi, Alissa, >> On Nov 6, 2015 7:06 AM, "Alissa Cooper" wrote: >> > >> > Hi Spencer, >> > >> > >> > >> > On Nov 5, 2015, at 11:20 PM, Spencer Dawkins at IETF < >> spencerdawkins.ietf@gmail.com> wrote: >> > >> >> Hi, Charles, >> >> >> >> On Thu, Nov 5, 2015 at 5:43 PM, Charles Eckel (eckelcu) < >> eckelcu@cisco.com> wrote: >> >>> >> >>> For TCP, the use of TLS was not required by RFC 4582. For 4582bis, w= e >> do not require TLS in order to maintain backward compatibility with RFC >> 4582. >> >> >> >> >> >> Got it. I'm holding my nose on this one, based on backward >> compatibility, and given the degree of difficulty in splicing attack >> packets into the TCP sequence numbering space if you're off-path. I'm no= t >> thrilled, but someone else needs to decide when threats reach the level >> where making that incompatible change is necessary - and that might not = be >> the right thing to do today. >> >> >> >>> >> >>> For UDP, the reason for not mandating DTLS is backward compatibility >> with existing solutions. The IMTC Role Based Video Best Practice >> established a set of recommendations for getting BFCP to work within >> enterprise video conference deployments. As that >> time,draft-sandbakken-xcon-bfcp-udp defined BFCP over UDP only. DTLS was >> left for future study. Today we have many implementations of BFCP over U= DP, >> but few if any using DTLS. We need the ultimate RFC that standardizes BF= CP >> over UDP (and over DTLS) to allow interworking with these existing >> deployments. >> >> >> >> >> >> OK, I'm not the Protocol Security Police, so, fine, but it seems like >> the draft could be clearer about this, and what you said in your answer >> would be really helpful in the document. >> >> >> >> If the text said something like "DTLS is REQUIRED unless you are >> interworking with a pre-standardization deployment that is already insec= ure, >> > >> > >> > "REQUIRED unless" strikes me as a faulty construction. That case is >> what RECOMMENDED is for, when there is a known exception to the requirem= ent. >> That usage is certainly more common in some parts of the IETF than >> others, but it does get used. But ignoring that. >> Do you think "RECOMMENDED unless you are interworking with a >> pre-standardization deployment that is already insecure" is tight enough= ? >> The reason I'm asking, is that offpath attacks on UDP-based protocols ar= e >> a lot easier than TCP-based protocols, and if the IETF is going to publi= sh >> a proposed standard with a known deficiency to accommodate >> pre-standardization deployments, I'd prefer that the guidance about usin= g >> that accommodation be as clear as possible. >> >> >> I agree with your intent. My concern with calling out exceptions is that >> it can make the existing recommendation in the draft seem weaker. How ab= out >> this: >> >> OLD: >> >> =E2=80=A6 It is RECOMMENDED that TLS/DTLS with an >> encryption algorithm according to Section 7 always be used. In cases >> where signaling/control traffic is properly protected, as described >> in Section 9 it is REQUIRED to use a mandated encryption algorithm. >> BFCP entities MAY use other security mechanisms as long as they >> provide similar security properties. >> >> NEW >> >> =E2=80=A6 It is RECOMMENDED that TLS/DTLS with an >> encryption algorithm according to Section 7 always be used. In cases >> where signaling/control traffic is properly protected, as described >> in Section 9 it is REQUIRED to use a mandated encryption algorithm. >> BFCP entities MAY use other security mechanisms to interwork with >> legacy implementation that do not use TLS/DTLS as long as these >> mechanisms provide similar security properties. >> >> > Probably for Charles: > > This last sentence seems to be responsible for most of my remaining > heartburn. > > My understanding was that TLS and (especially) DTLS were RECOMMENDED, not > REQUIRED, because there are legacy implementations that have been deploye= d > already. I can live with that, but is it obvious to everyone how a legacy > receiver tells a sender to use a non-TLS/DTLS mechanism? I'm looking at t= he > "use TLS" and "use DTLS" error codes in Table 5, and wondering where the > "use legacy security mechanism" error code might be. > > Do legacy endpoints "just know" this? > > > This draft describes how to use SDP to establish a BFCP connection. The > determination of whether to use TLS or TCP or DTLS or UDP is based on the > SDP offer/answer and the specification within it of the m-line, e.g. > > m=3Dapplication 50000 UDP/BFCP * > > m=3Dapplication 50000 TCP/BFCP * > > m=3Dapplication 50000 TCP/TLS/BFCP * > > m=3Dapplication 50000 UDP/TLS/BFCP * > > When making the offer, an implementation has a choice of using any of > these and the answerer can choose to accept of reject. Some very > implementations supported TCP only. Most current implementations support > UDP only or in addition to TCP. In the future, we hope all with support > DTLS. Typically implementation the support more than one transport provid= e > configuration options, such as require DTLS, or offer DTLS but accept UDP > or DTLS, or offer DTLS first and if rejected offer UDP. The current IMTC > best practice recommends offering UDP and if that fails offer TCP. This > will be updated to include DTLS once RFC4583bis is published. > This all makes perfect sense to me. I'm not understanding how legacy implementations offering "UDP only" maps onto "other mechanisms that provide similar security properties" in the proposed text. Is "other mechanisms that provide similar security properties" even talking about the same thing? And thanks for the quick follow-up. Spencer > Cheers, > Charles > > Thanks, > > Spencer > > >> Cheers, >> Charles >> >> >> >> Thanks, >> Spencer >> > Alissa >> > >> >> in which case you're not making things worse by running without >> transport-level security", that would capture my concern and reflect wha= t >> you're saying, unless I'm missing something. >> >> >> >> Thanks to you and Paul for the speedy response on the evening of Bits >> and Bites! >> >> >> >> Spencer >> >> >> >> _______________________________________________ >> >> >> >> bfcpbis mailing list >> >> bfcpbis@ietf.org >> >> https://www.ietf.org/mailman/listinfo/bfcpbis >> >> >> > --001a1145ed86e5f28405247238fa Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hi, Charles,

On Fri, Nov 13, 2015 at 1:11 PM, Charles Eckel (eckelcu) <ecke= lcu@cisco.com> wrote:
Hi Spencer,

Please see inline.

From: Spencer Dawkins at IETF <<= a href=3D"mailto:spencerdawkins.ietf@gmail.com" target=3D"_blank">spencerda= wkins.ietf@gmail.com>
Date: Saturday, November 14,= 2015 at 2:57 AM
To: Alissa Cooper <alissa@cooperw.in>
Cc: IESG <iesg@ietf.org>, "bfcpbis-chairs@ietf.org&quo= t; <bfcpbis= -chairs@ietf.org>, Paul Jones <paulej@packetizer.com>, "gorry@erg.= abdn.ac.uk" <gorry@erg.abdn.ac.uk>, Mary Barnes <mary.ietf.barnes@gmail.com&g= t;, "draft-ietf-bfcpbis-rfc4582bis@ietf.org" <draft-ietf-bfcpbis-rfc4582bis@ietf.org>, "bfcpbis@ietf.org" <bfcpbis@ietf.org>, = Charles Eckel <ec= kelcu@cisco.com>

Subject: Re: [bfcpbis] Spencer Dawk= ins' Discuss on draft-ietf-bfcpbis-rfc4582bis-15: (with DISCUSS and COM= MENT)

So, we're getting there.

On Wed, Nov 11, 2015 at 4:38 PM, Alissa Cooper <= span dir=3D"ltr"> <alissa@cooperw.i= n> wrote:
Hi Spencer,

Does Charles=E2=80=99 proposal below work for you?

Thanks,
Alissa

On Nov 5, 2015, at 3:42 PM, Charles Eckel (eckelcu) <eckelcu@cisco.com> wrote:

From: Spencer Dawkins at IETF <<= a href=3D"mailto:spencerdawkins.ietf@gmail.com" target=3D"_blank">spencerda= wkins.ietf@gmail.com>
Date: Friday, November 6, 2015 at 7= :23 AM
To: Alissa Cooper <alissa@cooperw.in>
Cc: "iesg@ietf.org" <iesg@ietf.org>, "bfcpbis-chairs@ietf.org&qu= ot; <bfcpbis-c= hairs@ietf.org>, Paul Jones <paulej@packetizer.com>, "gorry@erg.abdn.ac.uk" <gorry@erg.ab= dn.ac.uk>, Mary Barnes <mary.ietf.barnes@gmail.com>, "draft-iet= f-bfcpbis-rfc4582bis@ietf.org" <draft-ietf-bfcpbis-rfc4582bis@ietf.org>, "bfcpbis@ietf.org" <bfcpbis@ietf.org>, Charles Eckel <e= ckelcu@cisco.com>
Subject: Re: [bfcpbis] Spencer Dawk= ins' Discuss on draft-ietf-bfcpbis-rfc4582bis-15: (with DISCUSS and COM= MENT)

Hi, Alissa,
On Nov 6, 2015 7:06 AM, "Alissa Cooper" <alissa@cooperw.in>= ; wrote:
>
> Hi Spencer,
>
>
>
> On Nov 5, 2015, at 11:20 PM, Spencer Dawkins at IETF <spencerdawkins.ietf@g= mail.com> wrote:
>
>> Hi, Charles,
>>
>> On Thu, Nov 5, 2015 at 5:43 PM, Charles Eckel (eckelcu) <eckelcu@cisco.com> = wrote:
>>>
>>> For TCP, the use of TLS was not required by RFC 4582. For 4582= bis, we do not require TLS in order to maintain backward compatibility with= RFC 4582.
>>
>>
>> Got it. I'm holding my nose on this one, based on backward com= patibility, and given the degree of difficulty in splicing attack packets i= nto the TCP sequence numbering space if you're off-path. I'm not th= rilled, but someone else needs to decide when threats reach the level where making that incompatible change is necessary - and t= hat might not be the right thing to do today.
>> =C2=A0
>>>
>>> For UDP, the reason for not mandating DTLS is backward compati= bility with existing solutions. The IMTC Role Based Video Best Practice est= ablished a set of recommendations for getting BFCP to work =C2=A0within ent= erprise video conference deployments. As that time,draft-sandbakken-xcon-bfcp-udp=C2=A0defined BFCP over UDP only. DTLS = was left for future study. Today we have many implementations of BFCP over = UDP, but few if any using DTLS. We need the ultimate RFC that standardizes = BFCP over UDP (and over DTLS) to allow interworking with these existing deployments.
>>
>>
>> OK, I'm not the Protocol Security Police, so, fine, but it see= ms like the draft could be clearer about this, and what you said in your an= swer would be really helpful in the document.=C2=A0
>>
>> If the text said something like "DTLS is REQUIRED unless you = are interworking with a pre-standardization deployment that is already inse= cure,
>
>
> "REQUIRED unless" strikes me as a faulty construction. That = case is what RECOMMENDED is for, when there is a known exception to the req= uirement.
That usage is certainly more common in some parts of the I= ETF than others, but it does get used. But ignoring that.
Do you think "RECOMMENDED unless you are interworking= with a pre-standardization deployment that is already insecure" is ti= ght enough?
The reason I'm asking, is that offpath attacks on UDP-= based protocols are a lot easier than TCP-based protocols, and if the IETF = is going to publish a proposed standard with a known deficiency to accommod= ate pre-standardization deployments, I'd prefer that the guidance about using that accommodation be as clear as pos= sible.

I agree with y= our intent. My concern with calling out exceptions is that it can make the = existing recommendation in the draft seem weaker. How about this:

OLD:

=C2=A0 =C2=A0=E2=80=A6 It is RECOMMENDED that TLS/DTLS with an<= /div>
=C2=A0 =C2=A0encryption algorithm ac= cording to Section 7 always be used.=C2=A0 In cases
=C2=A0 =C2=A0where signaling/control= traffic is properly protected, as described
=C2=A0 =C2=A0in Section 9 it is REQU= IRED to use a mandated encryption algorithm.
=C2=A0 =C2=A0BFCP entities MAY use o= ther security mechanisms as long as they
=C2=A0 =C2=A0provide similar securit= y properties.

NEW

=C2=A0 =C2=A0=E2=80=A6 It is RECOMMENDED = that TLS/DTLS with an
=C2=A0 =C2=A0encryption algorithm according to Section 7 always be= used.=C2=A0 In cases
=C2=A0 =C2=A0where signaling/control traffic is properly protected= , as described
=C2=A0 =C2=A0in Section 9 it is REQUIRED to use a mandated encrypt= ion algorithm.
=C2=A0 =C2=A0BFCP entities MAY use other security mechanisms to in= terwork with=C2=A0
=C2=A0 =C2=A0legacy implementation that do not use TLS/DTLS as lon= g as these=C2=A0
=C2=A0 =C2=A0mechanisms=C2=A0provide similar security properties.=C2=A0

Probably for Charles:

This last sentence seems to be responsible for most of my remaining he= artburn.=C2=A0

My understanding was that TLS and (especially) DTLS were RECOMMENDED, = not REQUIRED, because there are legacy implementations that have been deplo= yed already. I can live with that, but is it obvious to everyone how a lega= cy receiver tells a sender to use a non-TLS/DTLS mechanism? I'm looking at the "use TLS" and &= quot;use DTLS" error codes in Table 5, and wondering where the "u= se legacy security mechanism" error code might be.=C2=A0

Do legacy endpoints "just know" this?

This draft des= cribes how to use SDP to establish a BFCP connection. The determination of = whether to use TLS or TCP or DTLS or UDP is based on the SDP offer/answer a= nd the specification within it of the m-line, e.g.

m=3Dapplication 50000 UDP/BFCP *

m=3Dapplication 50000 TCP/BFCP *

m=3Dapplication 50000 TCP/TLS/BFCP *

m=3Dapplication 50000 UDP/TLS/BFCP *


When making the offer, an implementation has a choice of using any of = these and the answerer can choose to accept of reject. Some very implementa= tions supported TCP only. Most current implementations support UDP only or = in addition to TCP. In the future, we hope all with support DTLS. Typically implementation the support more t= han one transport provide configuration options, such as require DTLS, or o= ffer DTLS but accept UDP or DTLS, or offer DTLS first and if rejected offer= UDP. The current IMTC best practice recommends offering UDP and if that fails offer TCP. This will be updated = to include DTLS once RFC4583bis is published. =C2=A0

This all makes perfect sense to me. I'm not under= standing how legacy implementations offering "UDP only" maps onto= "other mechanisms that provide similar security properties" in t= he proposed text.=C2=A0

Is "other mechanisms = that provide similar security properties" even talking about the same = thing?

And thanks for the quick follow-up.

Spencer
=C2=A0
Cheers,
Charles

Thanks,

Spencer
=C2=A0
Cheers,
Charles
=C2=A0

Thanks,
Spencer
> Alissa
>
>> in which case you're not making things worse by running withou= t transport-level security", that would capture my concern and reflect= what you're saying, unless I'm missing something.
>>
>> Thanks to you and Paul for the speedy response on the evening of B= its and Bites!
>>
>> Spencer
>>
>> _______________________________________________
>>
>> bfcpbis mailing list
>> bfcpbis@ietf= .org
>> https://www.ietf.org/mailman/listinfo/bfcpbis

--001a1145ed86e5f28405247238fa-- From nobody Fri Nov 13 13:07:32 2015 Return-Path: X-Original-To: bfcpbis@ietfa.amsl.com Delivered-To: bfcpbis@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 40B2C1B31BC; Fri, 13 Nov 2015 13:07:30 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -13.91 X-Spam-Level: X-Spam-Status: No, score=-13.91 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, J_CHICKENPOX_111=0.6, 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 PbFDvAmVKGCC; Fri, 13 Nov 2015 13:07:26 -0800 (PST) Received: from alln-iport-6.cisco.com (alln-iport-6.cisco.com [173.37.142.93]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0E9151B31B9; Fri, 13 Nov 2015 13:07:26 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=32472; q=dns/txt; s=iport; t=1447448846; x=1448658446; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=pFUzVF5aHz0jKw7/0yAaPVjTlmbjsoTfkqmiqz5QSV8=; b=D3eBbO3S4jZYdV6qZZ2BcsrlPVd5le7BgTK1UPHsCzjCEXyOoB1Ch7ix Cgv2f4YVuRnlAuXJeVRVkLq80H8BIcluRdq1vN3V+NC+bVyCeWp283zDf x1v6qt49ODx9bs3ZL2oxAJthpJXVd97I3LIXpvBCf5YpSduNYmKrA45SM 4=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: A0AtAgAiUEZW/5tdJa1egm5NU28GvkYBDYFkFwEJhSVKAoE+OBQBAQEBAQEBgQqENAEBAQMBAQEBZQYLBQsCAQgRAwECASABAgQHIQYLFAkIAgQOBRuHfgMKCA27RA2EVwEBAQEBAQEBAQEBAQEBAQEBAQEBARQEikyBBoJTgigNhDEFh06Gf4Qag2EBiA2DJIF1gVuEQI5Xg2GDcQEfAQFCghEdFoFAcgGENYEHAQEB X-IronPort-AV: E=Sophos;i="5.20,289,1444694400"; d="scan'208,217";a="208001671" Received: from rcdn-core-4.cisco.com ([173.37.93.155]) by alln-iport-6.cisco.com with ESMTP; 13 Nov 2015 21:07:25 +0000 Received: from XCH-RCD-017.cisco.com (xch-rcd-017.cisco.com [173.37.102.27]) by rcdn-core-4.cisco.com (8.14.5/8.14.5) with ESMTP id tADL7Omc012473 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Fri, 13 Nov 2015 21:07:24 GMT Received: from xch-aln-018.cisco.com (173.36.7.28) by XCH-RCD-017.cisco.com (173.37.102.27) with Microsoft SMTP Server (TLS) id 15.0.1104.5; Fri, 13 Nov 2015 15:07:24 -0600 Received: from xch-aln-018.cisco.com ([173.36.7.28]) by XCH-ALN-018.cisco.com ([173.36.7.28]) with mapi id 15.00.1104.000; Fri, 13 Nov 2015 15:07:23 -0600 From: "Charles Eckel (eckelcu)" To: Spencer Dawkins at IETF Thread-Topic: [bfcpbis] Spencer Dawkins' Discuss on draft-ietf-bfcpbis-rfc4582bis-15: (with DISCUSS and COMMENT) Thread-Index: AQHRF3IJ5JJDWYYKUEOdhULB9tmr356NOVMAgAAGM4CAANkWAP//x2GAgACCJ4CAAASuAIAArPmAgAjFKICAAtZLgP//jpIAgACh/AD//35cAA== Date: Fri, 13 Nov 2015 21:07:23 +0000 Message-ID: References: <20151105023108.17210.54132.idtracker@ietfa.amsl.com> <19C90DA9-652D-499F-8462-7EC7878307CB@packetizer.com> <5D0066E2-6BD9-4ED8-A37D-CE83118E099E@cooperw.in> <0BAEEA7C-B892-460B-AAD3-80A0F85E766D@cooperw.in> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.5.8.151023 x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.24.78.221] Content-Type: multipart/alternative; boundary="_000_D26B8E4A5EAFEeckelcuciscocom_" MIME-Version: 1.0 Archived-At: Cc: "gorry@erg.abdn.ac.uk" , "bfcpbis-chairs@ietf.org" , "bfcpbis@ietf.org" , Alissa Cooper , "draft-ietf-bfcpbis-rfc4582bis@ietf.org" , "Paul E. Jones" , IESG , Mary Barnes Subject: Re: [bfcpbis] Spencer Dawkins' Discuss on draft-ietf-bfcpbis-rfc4582bis-15: (with DISCUSS and COMMENT) X-BeenThere: bfcpbis@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: BFCPBIS working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 13 Nov 2015 21:07:30 -0000 --_000_D26B8E4A5EAFEeckelcuciscocom_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable From: Spencer Dawkins at IETF > Date: Friday, November 13, 2015 at 12:51 PM To: Charles Eckel > Cc: Alissa Cooper >, IESG >, "bfcpbis-chairs@ietf.org" >,= Paul Jones >, "gorry@e= rg.abdn.ac.uk" >, Mary Barnes >, "draft-ietf-bfcpbis-rfc4582bis@ietf.org" >, "bfcpbis@ietf.org" > Subject: Re: [bfcpbis] Spencer Dawkins' Discuss on draft-ietf-bfcpbis-rfc45= 82bis-15: (with DISCUSS and COMMENT) Hi, Charles, On Fri, Nov 13, 2015 at 1:11 PM, Charles Eckel (eckelcu) > wrote: Hi Spencer, Please see inline. From: Spencer Dawkins at IETF > Date: Saturday, November 14, 2015 at 2:57 AM To: Alissa Cooper > Cc: IESG >, "bfcpbis-chairs@ietf.org" >, Paul Jones >, "gorry@erg.abdn.ac.uk" >, Mary Barnes >, "draft-ietf-bfcpbis-rfc4582bis@ietf.o= rg" >, "bfcpbis@i= etf.org" >, Charles Eckel > Subject: Re: [bfcpbis] Spencer Dawkins' Discuss on draft-ietf-bfcpbis-rfc45= 82bis-15: (with DISCUSS and COMMENT) So, we're getting there. On Wed, Nov 11, 2015 at 4:38 PM, Alissa Cooper > wrote: Hi Spencer, Does Charles=92 proposal below work for you? Thanks, Alissa On Nov 5, 2015, at 3:42 PM, Charles Eckel (eckelcu) > wrote: From: Spencer Dawkins at IETF > Date: Friday, November 6, 2015 at 7:23 AM To: Alissa Cooper > Cc: "iesg@ietf.org" >, "bfcpbis-chairs@ietf.org" >, Paul Jones >, "gorry@erg.abdn.ac.uk" >, Mary B= arnes >, "dra= ft-ietf-bfcpbis-rfc4582bis@ietf.org" >, "bfcpbis@ietf.org" >, Charles Eckel > Subject: Re: [bfcpbis] Spencer Dawkins' Discuss on draft-ietf-bfcpbis-rfc45= 82bis-15: (with DISCUSS and COMMENT) Hi, Alissa, On Nov 6, 2015 7:06 AM, "Alissa Cooper" > wrote: > > Hi Spencer, > > > > On Nov 5, 2015, at 11:20 PM, Spencer Dawkins at IETF > wrote: > >> Hi, Charles, >> >> On Thu, Nov 5, 2015 at 5:43 PM, Charles Eckel (eckelcu) > wrote: >>> >>> For TCP, the use of TLS was not required by RFC 4582. For 4582bis, we d= o not require TLS in order to maintain backward compatibility with RFC 4582= . >> >> >> Got it. I'm holding my nose on this one, based on backward compatibility= , and given the degree of difficulty in splicing attack packets into the TC= P sequence numbering space if you're off-path. I'm not thrilled, but someon= e else needs to decide when threats reach the level where making that incom= patible change is necessary - and that might not be the right thing to do t= oday. >> >>> >>> For UDP, the reason for not mandating DTLS is backward compatibility wi= th existing solutions. The IMTC Role Based Video Best Practice established = a set of recommendations for getting BFCP to work within enterprise video = conference deployments. As that time,draft-sandbakken-xcon-bfcp-udp defined= BFCP over UDP only. DTLS was left for future study. Today we have many imp= lementations of BFCP over UDP, but few if any using DTLS. We need the ultim= ate RFC that standardizes BFCP over UDP (and over DTLS) to allow interworki= ng with these existing deployments. >> >> >> OK, I'm not the Protocol Security Police, so, fine, but it seems like th= e draft could be clearer about this, and what you said in your answer would= be really helpful in the document. >> >> If the text said something like "DTLS is REQUIRED unless you are interwo= rking with a pre-standardization deployment that is already insecure, > > > "REQUIRED unless" strikes me as a faulty construction. That case is what = RECOMMENDED is for, when there is a known exception to the requirement. That usage is certainly more common in some parts of the IETF than others, = but it does get used. But ignoring that. Do you think "RECOMMENDED unless you are interworking with a pre-standardiz= ation deployment that is already insecure" is tight enough? The reason I'm asking, is that offpath attacks on UDP-based protocols are a= lot easier than TCP-based protocols, and if the IETF is going to publish a= proposed standard with a known deficiency to accommodate pre-standardizati= on deployments, I'd prefer that the guidance about using that accommodation= be as clear as possible. I agree with your intent. My concern with calling out exceptions is that it= can make the existing recommendation in the draft seem weaker. How about t= his: OLD: =85 It is RECOMMENDED that TLS/DTLS with an encryption algorithm according to Section 7 always be used. In cases where signaling/control traffic is properly protected, as described in Section 9 it is REQUIRED to use a mandated encryption algorithm. BFCP entities MAY use other security mechanisms as long as they provide similar security properties. NEW =85 It is RECOMMENDED that TLS/DTLS with an encryption algorithm according to Section 7 always be used. In cases where signaling/control traffic is properly protected, as described in Section 9 it is REQUIRED to use a mandated encryption algorithm. BFCP entities MAY use other security mechanisms to interwork with legacy implementation that do not use TLS/DTLS as long as these mechanisms provide similar security properties. Probably for Charles: This last sentence seems to be responsible for most of my remaining heartbu= rn. My understanding was that TLS and (especially) DTLS were RECOMMENDED, not R= EQUIRED, because there are legacy implementations that have been deployed a= lready. I can live with that, but is it obvious to everyone how a legacy re= ceiver tells a sender to use a non-TLS/DTLS mechanism? I'm looking at the "= use TLS" and "use DTLS" error codes in Table 5, and wondering where the "us= e legacy security mechanism" error code might be. Do legacy endpoints "just know" this? This draft describes how to use SDP to establish a BFCP connection. The det= ermination of whether to use TLS or TCP or DTLS or UDP is based on the SDP = offer/answer and the specification within it of the m-line, e.g. m=3Dapplication 50000 UDP/BFCP * m=3Dapplication 50000 TCP/BFCP * m=3Dapplication 50000 TCP/TLS/BFCP * m=3Dapplication 50000 UDP/TLS/BFCP * When making the offer, an implementation has a choice of using any of these= and the answerer can choose to accept of reject. Some very implementations= supported TCP only. Most current implementations support UDP only or in ad= dition to TCP. In the future, we hope all with support DTLS. Typically impl= ementation the support more than one transport provide configuration option= s, such as require DTLS, or offer DTLS but accept UDP or DTLS, or offer DTL= S first and if rejected offer UDP. The current IMTC best practice recommend= s offering UDP and if that fails offer TCP. This will be updated to include= DTLS once RFC4583bis is published. This all makes perfect sense to me. I'm not understanding how legacy implem= entations offering "UDP only" maps onto "other mechanisms that provide simi= lar security properties" in the proposed text. Is "other mechanisms that provide similar security properties" even talking= about the same thing? And thanks for the quick follow-up. Likewise. An example of other mechanisms is IPSEC and having a UDP based BF= CP connection within it. Cheers, Charles Spencer Cheers, Charles Thanks, Spencer Cheers, Charles Thanks, Spencer > Alissa > >> in which case you're not making things worse by running without transpor= t-level security", that would capture my concern and reflect what you're sa= ying, unless I'm missing something. >> >> Thanks to you and Paul for the speedy response on the evening of Bits an= d Bites! >> >> Spencer >> >> _______________________________________________ >> >> bfcpbis mailing list >> bfcpbis@ietf.org >> https://www.ietf.org/mailman/listinfo/bfcpbis --_000_D26B8E4A5EAFEeckelcuciscocom_ Content-Type: text/html; charset="Windows-1252" Content-ID: Content-Transfer-Encoding: quoted-printable

From: Spencer Dawkins at IETF <<= a href=3D"mailto:spencerdawkins.ietf@gmail.com">spencerdawkins.ietf@gmail.c= om>
Date: Friday, November 13, 2015 at = 12:51 PM
To: Charles Eckel <eckelcu@cisco.com>
Cc: Alissa Cooper <alissa@cooperw.in>, IESG <iesg@ietf.org>, "bfcpbis-chairs@ietf.org" <bfcpbis-chairs@ietf.org>, Paul Jones <paulej@packetizer.= com>, "gorry@erg.abdn.a= c.uk" <gorry@erg.abdn.a= c.uk>, Mary Barnes <mary.ietf.barnes@gmail.com>, "draft-ietf= -bfcpbis-rfc4582bis@ietf.org" <draft-ietf-bfcpbis-rfc4582bis@ietf.org>, &= quot;bfcpbis@ietf.org" <bfcpbis@ietf.org>
Subject: Re: [bfcpbis] Spencer Dawk= ins' Discuss on draft-ietf-bfcpbis-rfc4582bis-15: (with DISCUSS and COMMENT= )

Hi, Charles,

On Fri, Nov 13, 2015 at 1:11 PM, Charles Eckel (= eckelcu) <eckelcu@cisco.com> wrote:
Hi Spencer,

Please see inline.

From: Spencer Dawk= ins at IETF <spencerdawkins.ietf@gmail.com>
Date: Saturday, November 14,= 2015 at 2:57 AM
To: Alissa Cooper <alissa@cooperw.in>
Cc: IESG <iesg@ietf.org>, "bfcpbis-chairs@ietf.org&quo= t; <bfcpbis= -chairs@ietf.org>, Paul Jones <= paulej@packetizer.com>, "gorry@erg.abdn.ac.uk" <gorry@erg.abdn.ac.uk>, Mary Barnes <mary.ietf.barnes@gmail.com>, "draft-ietf-bfcpbis-rfc4582= bis@ietf.org" <draft-ietf-bfcpbis-rfc4582bis@ietf.org>, "bfcpbis@ietf.o= rg" <bfcp= bis@ietf.org>, Charles Eckel <eckelcu@cisco.com>

Subject: Re: [bfcpbis] Spencer Dawk= ins' Discuss on draft-ietf-bfcpbis-rfc4582bis-15: (with DISCUSS and COMMENT= )

So, we're getting there.

On Wed, Nov 11, 2015 at 4:38 PM, Alissa Cooper <= span dir=3D"ltr"> <alissa@cooperw.i= n> wrote:
Hi Spencer,

Does Charles=92 proposal below work for you?

Thanks,
Alissa

On Nov 5, 2015, at 3:42 PM, Charles Eckel (eckelcu) <eckelcu@cisco.com> wrote:

From: Spencer Dawkins at IETF <<= a href=3D"mailto:spencerdawkins.ietf@gmail.com" target=3D"_blank">spencerda= wkins.ietf@gmail.com>
Date: Friday, November 6, 2015 at 7= :23 AM
To: Alissa Cooper <alissa@cooperw.in>
Cc: "iesg@ietf.org" <iesg@ietf.org>, "bfcpbis-chairs@ietf.org&qu= ot; <bfcpbis-c= hairs@ietf.org>, Paul Jones <paulej@packetizer.com>, "gorry@erg.abdn.ac.uk" <gorry@erg.ab= dn.ac.uk>, Mary Barnes <mary.ietf.barnes@gmail.com>, "draft-iet= f-bfcpbis-rfc4582bis@ietf.org" <draft-ietf-bfcpbis-rfc4582bis@ietf.org>, "bfcpbis@ietf.org" <bfcpbis@ietf.org>, Charles Eckel <e= ckelcu@cisco.com>
Subject: Re: [bfcpbis] Spencer Dawk= ins' Discuss on draft-ietf-bfcpbis-rfc4582bis-15: (with DISCUSS and COMMENT= )

Hi, Alissa,
On Nov 6, 2015 7:06 AM, "Alissa Cooper" <alissa@cooperw.in>= ; wrote:
>
> Hi Spencer,
>
>
>
> On Nov 5, 2015, at 11:20 PM, Spencer Dawkins at IETF <spencerdawkins.ietf@g= mail.com> wrote:
>
>> Hi, Charles,
>>
>> On Thu, Nov 5, 2015 at 5:43 PM, Charles Eckel (eckelcu) <eckelcu@cisco.com> = wrote:
>>>
>>> For TCP, the use of TLS was not required by RFC 4582. For 4582= bis, we do not require TLS in order to maintain backward compatibility with= RFC 4582.
>>
>>
>> Got it. I'm holding my nose on this one, based on backward compati= bility, and given the degree of difficulty in splicing attack packets into = the TCP sequence numbering space if you're off-path. I'm not thrilled, but = someone else needs to decide when threats reach the level where making that incompatible change is necessary - and t= hat might not be the right thing to do today.
>>  
>>>
>>> For UDP, the reason for not mandating DTLS is backward compati= bility with existing solutions. The IMTC Role Based Video Best Practice est= ablished a set of recommendations for getting BFCP to work  within ent= erprise video conference deployments. As that time,draft-sandbakken-xcon-bfcp-udp defined BFCP over UDP only. DTLS = was left for future study. Today we have many implementations of BFCP over = UDP, but few if any using DTLS. We need the ultimate RFC that standardizes = BFCP over UDP (and over DTLS) to allow interworking with these existing deployments.
>>
>>
>> OK, I'm not the Protocol Security Police, so, fine, but it seems l= ike the draft could be clearer about this, and what you said in your answer= would be really helpful in the document. 
>>
>> If the text said something like "DTLS is REQUIRED unless you = are interworking with a pre-standardization deployment that is already inse= cure,
>
>
> "REQUIRED unless" strikes me as a faulty construction. That = case is what RECOMMENDED is for, when there is a known exception to the req= uirement.
That usage is certainly more common in some parts of the I= ETF than others, but it does get used. But ignoring that.
Do you think "RECOMMENDED unless you are interworking= with a pre-standardization deployment that is already insecure" is ti= ght enough?
The reason I'm asking, is that offpath attacks on UDP-base= d protocols are a lot easier than TCP-based protocols, and if the IETF is g= oing to publish a proposed standard with a known deficiency to accommodate = pre-standardization deployments, I'd prefer that the guidance about using that accommodation be as clear as pos= sible.

I agree with y= our intent. My concern with calling out exceptions is that it can make the = existing recommendation in the draft seem weaker. How about this:

OLD:

   =85 It is RECOMMENDED that TLS/DTLS with an
   encryption algorithm ac= cording to Section 7 always be used.  In cases
   where signaling/control= traffic is properly protected, as described
   in Section 9 it is REQU= IRED to use a mandated encryption algorithm.
   BFCP entities MAY use o= ther security mechanisms as long as they
   provide similar securit= y properties.

NEW

   =85 It is RECOMMENDED that T= LS/DTLS with an
   encryption algorithm according to Section 7 always be= used.  In cases
   where signaling/control traffic is properly protected= , as described
   in Section 9 it is REQUIRED to use a mandated encrypt= ion algorithm.
   BFCP entities MAY use other security mechanisms to in= terwork with 
   legacy implementation that do not use TLS/DTLS as lon= g as these 
   mechanisms provide similar security properties. 

Probably for Charles:

This last sentence seems to be responsible for most of my remaining he= artburn. 

My understanding was that TLS and (especially) DTLS were RECOMMENDED, = not REQUIRED, because there are legacy implementations that have been deplo= yed already. I can live with that, but is it obvious to everyone how a lega= cy receiver tells a sender to use a non-TLS/DTLS mechanism? I'm looking at the "use TLS" and "= ;use DTLS" error codes in Table 5, and wondering where the "use l= egacy security mechanism" error code might be. 

Do legacy endpoints "just know" this?

This draft des= cribes how to use SDP to establish a BFCP connection. The determination of = whether to use TLS or TCP or DTLS or UDP is based on the SDP offer/answer a= nd the specification within it of the m-line, e.g.

m=3Dapplication 50000 UDP/BFCP *

m=3Dapplication 50000 TCP/BFCP *

m=3Dapplication 50000 TCP/TLS/BFCP *

m=3Dapplication 50000 UDP/TLS/BFCP *


When making the offer, an implementation has a choice of using any of = these and the answerer can choose to accept of reject. Some very implementa= tions supported TCP only. Most current implementations support UDP only or = in addition to TCP. In the future, we hope all with support DTLS. Typically implementation the support more t= han one transport provide configuration options, such as require DTLS, or o= ffer DTLS but accept UDP or DTLS, or offer DTLS first and if rejected offer= UDP. The current IMTC best practice recommends offering UDP and if that fails offer TCP. This will be updated = to include DTLS once RFC4583bis is published.  

This all makes perfect sense to me. I'm not understanding how legacy i= mplementations offering "UDP only" maps onto "other mechanis= ms that provide similar security properties" in the proposed text.&nbs= p;

Is "other mechanisms that provide similar security properties&quo= t; even talking about the same thing?

And thanks for the quick follow-up.

Likewise. An example of other mechanisms is IPSEC and having a UDP bas= ed BFCP  connection within it.

Cheers,
Charles


Spencer
 
Cheers,
Charles

Thanks,

Spencer
 
Cheers,
Charles
 

Thanks,
Spencer
> Alissa
>
>> in which case you're not making things worse by running without tr= ansport-level security", that would capture my concern and reflect wha= t you're saying, unless I'm missing something.
>>
>> Thanks to you and Paul for the speedy response on the evening of B= its and Bites!
>>
>> Spencer
>>
>> _______________________________________________
>>
>> bfcpbis mailing list
>> bfcpbis@ietf= .org
>> https://www.ietf.org/mailman/listinfo/bfcpbis



 --_000_D26B8E4A5EAFEeckelcuciscocom_-- From nobody Fri Nov 13 13:15:21 2015 Return-Path: X-Original-To: bfcpbis@ietfa.amsl.com Delivered-To: bfcpbis@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6C4D41B3214; Fri, 13 Nov 2015 13:15:19 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.399 X-Spam-Level: X-Spam-Status: No, score=-1.399 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, J_CHICKENPOX_111=0.6, 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 YL0IeNcB_OBF; Fri, 13 Nov 2015 13:15:15 -0800 (PST) Received: from mail-yk0-x22d.google.com (mail-yk0-x22d.google.com [IPv6:2607:f8b0:4002:c07::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 438821B3201; Fri, 13 Nov 2015 13:15:15 -0800 (PST) Received: by ykdv3 with SMTP id v3so169660092ykd.0; Fri, 13 Nov 2015 13:15:14 -0800 (PST) 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=cfOXzCkrDvER6LZ4ooy0qfl2T5AxCMEGTstXltPeyW8=; b=wMT9WbflPrg0uN5yqTz2bjOtnvq6yizMOiHeF3tJu9GYGbFupk/NofoWblUK8CfZ1+ ZskFkEOOO+sEWRUtn9W1ZUJGbOd2TBtNBX1y4mOXjhSD7zP5r/Ata8Ifi97zc4045ykO YTn25Cf5oIIB+YTdUrFozz73nA5xbUmx6/RX/Mz1y2GtQsDcVA50AXB5/c47HKnFpojG xTr8mHoHgclHKHAuprcRxlWiL5nm9+RVQi5AgWShbd/0tnlRHh67kLTUYNVtfDtiMw8q DlHynaqJLEm4inXb96bqjbSuOC2CnuzGdsWwrrjfIgVS8CoCse1rfKHZh6ffTaf2bM7Y LEnA== MIME-Version: 1.0 X-Received: by 10.13.210.134 with SMTP id u128mr3450834ywd.175.1447449314498; Fri, 13 Nov 2015 13:15:14 -0800 (PST) Received: by 10.31.149.79 with HTTP; Fri, 13 Nov 2015 13:15:14 -0800 (PST) In-Reply-To: References: <20151105023108.17210.54132.idtracker@ietfa.amsl.com> <19C90DA9-652D-499F-8462-7EC7878307CB@packetizer.com> <5D0066E2-6BD9-4ED8-A37D-CE83118E099E@cooperw.in> <0BAEEA7C-B892-460B-AAD3-80A0F85E766D@cooperw.in> Date: Fri, 13 Nov 2015 15:15:14 -0600 Message-ID: From: Spencer Dawkins at IETF To: "Charles Eckel (eckelcu)" Content-Type: multipart/alternative; boundary=001a114e4e7438a07b0524728eb9 Archived-At: Cc: "gorry@erg.abdn.ac.uk" , "bfcpbis-chairs@ietf.org" , "bfcpbis@ietf.org" , Alissa Cooper , "draft-ietf-bfcpbis-rfc4582bis@ietf.org" , "Paul E. Jones" , IESG , Mary Barnes Subject: Re: [bfcpbis] Spencer Dawkins' Discuss on draft-ietf-bfcpbis-rfc4582bis-15: (with DISCUSS and COMMENT) X-BeenThere: bfcpbis@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: BFCPBIS working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 13 Nov 2015 21:15:19 -0000 --001a114e4e7438a07b0524728eb9 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Hi, Charles, On Fri, Nov 13, 2015 at 3:07 PM, Charles Eckel (eckelcu) wrote: > > From: Spencer Dawkins at IETF > Date: Friday, November 13, 2015 at 12:51 PM > To: Charles Eckel > Cc: Alissa Cooper , IESG , " > bfcpbis-chairs@ietf.org" , Paul Jones < > paulej@packetizer.com>, "gorry@erg.abdn.ac.uk" , > Mary Barnes , " > draft-ietf-bfcpbis-rfc4582bis@ietf.org" < > draft-ietf-bfcpbis-rfc4582bis@ietf.org>, "bfcpbis@ietf.org" < > bfcpbis@ietf.org> > > Subject: Re: [bfcpbis] Spencer Dawkins' Discuss on > draft-ietf-bfcpbis-rfc4582bis-15: (with DISCUSS and COMMENT) > > Hi, Charles, > > On Fri, Nov 13, 2015 at 1:11 PM, Charles Eckel (eckelcu) < > eckelcu@cisco.com> wrote: > >> Hi Spencer, >> >> Please see inline. >> >> From: Spencer Dawkins at IETF >> Date: Saturday, November 14, 2015 at 2:57 AM >> To: Alissa Cooper >> Cc: IESG , "bfcpbis-chairs@ietf.org" < >> bfcpbis-chairs@ietf.org>, Paul Jones , " >> gorry@erg.abdn.ac.uk" , Mary Barnes < >> mary.ietf.barnes@gmail.com>, "draft-ietf-bfcpbis-rfc4582bis@ietf.org" < >> draft-ietf-bfcpbis-rfc4582bis@ietf.org>, "bfcpbis@ietf.org" < >> bfcpbis@ietf.org>, Charles Eckel >> >> Subject: Re: [bfcpbis] Spencer Dawkins' Discuss on >> draft-ietf-bfcpbis-rfc4582bis-15: (with DISCUSS and COMMENT) >> >> So, we're getting there. >> >> On Wed, Nov 11, 2015 at 4:38 PM, Alissa Cooper wrote= : >> >>> Hi Spencer, >>> >>> Does Charles=E2=80=99 proposal below work for you? >>> >>> Thanks, >>> Alissa >>> >>> On Nov 5, 2015, at 3:42 PM, Charles Eckel (eckelcu) >>> wrote: >>> >>> >>> From: Spencer Dawkins at IETF >>> Date: Friday, November 6, 2015 at 7:23 AM >>> To: Alissa Cooper >>> Cc: "iesg@ietf.org" , "bfcpbis-chairs@ietf.org" < >>> bfcpbis-chairs@ietf.org>, Paul Jones , " >>> gorry@erg.abdn.ac.uk" , Mary Barnes < >>> mary.ietf.barnes@gmail.com>, "draft-ietf-bfcpbis-rfc4582bis@ietf.org" < >>> draft-ietf-bfcpbis-rfc4582bis@ietf.org>, "bfcpbis@ietf.org" < >>> bfcpbis@ietf.org>, Charles Eckel >>> Subject: Re: [bfcpbis] Spencer Dawkins' Discuss on >>> draft-ietf-bfcpbis-rfc4582bis-15: (with DISCUSS and COMMENT) >>> >>> Hi, Alissa, >>> On Nov 6, 2015 7:06 AM, "Alissa Cooper" wrote: >>> > >>> > Hi Spencer, >>> > >>> > >>> > >>> > On Nov 5, 2015, at 11:20 PM, Spencer Dawkins at IETF < >>> spencerdawkins.ietf@gmail.com> wrote: >>> > >>> >> Hi, Charles, >>> >> >>> >> On Thu, Nov 5, 2015 at 5:43 PM, Charles Eckel (eckelcu) < >>> eckelcu@cisco.com> wrote: >>> >>> >>> >>> For TCP, the use of TLS was not required by RFC 4582. For 4582bis, >>> we do not require TLS in order to maintain backward compatibility with = RFC >>> 4582. >>> >> >>> >> >>> >> Got it. I'm holding my nose on this one, based on backward >>> compatibility, and given the degree of difficulty in splicing attack >>> packets into the TCP sequence numbering space if you're off-path. I'm n= ot >>> thrilled, but someone else needs to decide when threats reach the level >>> where making that incompatible change is necessary - and that might not= be >>> the right thing to do today. >>> >> >>> >>> >>> >>> For UDP, the reason for not mandating DTLS is backward compatibilit= y >>> with existing solutions. The IMTC Role Based Video Best Practice >>> established a set of recommendations for getting BFCP to work within >>> enterprise video conference deployments. As that >>> time,draft-sandbakken-xcon-bfcp-udp defined BFCP over UDP only. DTLS wa= s >>> left for future study. Today we have many implementations of BFCP over = UDP, >>> but few if any using DTLS. We need the ultimate RFC that standardizes B= FCP >>> over UDP (and over DTLS) to allow interworking with these existing >>> deployments. >>> >> >>> >> >>> >> OK, I'm not the Protocol Security Police, so, fine, but it seems lik= e >>> the draft could be clearer about this, and what you said in your answer >>> would be really helpful in the document. >>> >> >>> >> If the text said something like "DTLS is REQUIRED unless you are >>> interworking with a pre-standardization deployment that is already inse= cure, >>> > >>> > >>> > "REQUIRED unless" strikes me as a faulty construction. That case is >>> what RECOMMENDED is for, when there is a known exception to the require= ment. >>> That usage is certainly more common in some parts of the IETF than >>> others, but it does get used. But ignoring that. >>> Do you think "RECOMMENDED unless you are interworking with a >>> pre-standardization deployment that is already insecure" is tight enoug= h? >>> The reason I'm asking, is that offpath attacks on UDP-based protocols >>> are a lot easier than TCP-based protocols, and if the IETF is going to >>> publish a proposed standard with a known deficiency to accommodate >>> pre-standardization deployments, I'd prefer that the guidance about usi= ng >>> that accommodation be as clear as possible. >>> >>> >>> I agree with your intent. My concern with calling out exceptions is tha= t >>> it can make the existing recommendation in the draft seem weaker. How a= bout >>> this: >>> >>> OLD: >>> >>> =E2=80=A6 It is RECOMMENDED that TLS/DTLS with an >>> encryption algorithm according to Section 7 always be used. In case= s >>> where signaling/control traffic is properly protected, as described >>> in Section 9 it is REQUIRED to use a mandated encryption algorithm. >>> BFCP entities MAY use other security mechanisms as long as they >>> provide similar security properties. >>> >>> NEW >>> >>> =E2=80=A6 It is RECOMMENDED that TLS/DTLS with an >>> encryption algorithm according to Section 7 always be used. In case= s >>> where signaling/control traffic is properly protected, as described >>> in Section 9 it is REQUIRED to use a mandated encryption algorithm. >>> BFCP entities MAY use other security mechanisms to interwork with >>> legacy implementation that do not use TLS/DTLS as long as these >>> mechanisms provide similar security properties. >>> >>> >> Probably for Charles: >> >> This last sentence seems to be responsible for most of my remaining >> heartburn. >> >> My understanding was that TLS and (especially) DTLS were RECOMMENDED, no= t >> REQUIRED, because there are legacy implementations that have been deploy= ed >> already. I can live with that, but is it obvious to everyone how a legac= y >> receiver tells a sender to use a non-TLS/DTLS mechanism? I'm looking at = the >> "use TLS" and "use DTLS" error codes in Table 5, and wondering where the >> "use legacy security mechanism" error code might be. >> >> Do legacy endpoints "just know" this? >> >> >> This draft describes how to use SDP to establish a BFCP connection. The >> determination of whether to use TLS or TCP or DTLS or UDP is based on th= e >> SDP offer/answer and the specification within it of the m-line, e.g. >> >> m=3Dapplication 50000 UDP/BFCP * >> >> m=3Dapplication 50000 TCP/BFCP * >> >> m=3Dapplication 50000 TCP/TLS/BFCP * >> >> m=3Dapplication 50000 UDP/TLS/BFCP * >> >> When making the offer, an implementation has a choice of using any of >> these and the answerer can choose to accept of reject. Some very >> implementations supported TCP only. Most current implementations support >> UDP only or in addition to TCP. In the future, we hope all with support >> DTLS. Typically implementation the support more than one transport provi= de >> configuration options, such as require DTLS, or offer DTLS but accept UD= P >> or DTLS, or offer DTLS first and if rejected offer UDP. The current IMTC >> best practice recommends offering UDP and if that fails offer TCP. This >> will be updated to include DTLS once RFC4583bis is published. >> > > This all makes perfect sense to me. I'm not understanding how legacy > implementations offering "UDP only" maps onto "other mechanisms that > provide similar security properties" in the proposed text. > > Is "other mechanisms that provide similar security properties" even > talking about the same thing? > > And thanks for the quick follow-up. > > > Likewise. An example of other mechanisms is IPSEC and having a UDP based > BFCP connection within it. > OK, so you're talking about security mechanisms that aren't under application control at all then. I love those :D I'll clear, but I think the document might be clearer if you said that (even as an example). Thanks, Spencer > Cheers, > Charles > > > Spencer > > >> Cheers, >> Charles >> >> Thanks, >> >> Spencer >> >> >>> Cheers, >>> Charles >>> >>> >>> >>> Thanks, >>> Spencer >>> > Alissa >>> > >>> >> in which case you're not making things worse by running without >>> transport-level security", that would capture my concern and reflect wh= at >>> you're saying, unless I'm missing something. >>> >> >>> >> Thanks to you and Paul for the speedy response on the evening of Bit= s >>> and Bites! >>> >> >>> >> Spencer >>> >> >>> >> _______________________________________________ >>> >> >>> >> bfcpbis mailing list >>> >> bfcpbis@ietf.org >>> >> https://www.ietf.org/mailman/listinfo/bfcpbis >>> >>> >>> >> > --001a114e4e7438a07b0524728eb9 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hi, Charles,

On Fri, Nov 13, 2015 at 3:07 PM, Charles Eckel (eckelcu) <ecke= lcu@cisco.com> wrote:

From: Spencer Dawkins at IETF <<= a href=3D"mailto:spencerdawkins.ietf@gmail.com" target=3D"_blank">spencerda= wkins.ietf@gmail.com>
Date: Friday, November 13, 2= 015 at 12:51 PM
To: Charles Eckel <eckelcu@cisco.com>
Cc: Alissa Cooper <alissa@cooperw.in>, IESG &= lt;iesg@ietf.org>= , "bfcpbi= s-chairs@ietf.org" <bfcpbis-chairs@ietf.org>, Paul Jones <= paulej@packetizer.com>, "gorry@erg.abdn.ac.uk" <gorry@erg.abdn.ac.uk>, Mary Ba= rnes <ma= ry.ietf.barnes@gmail.com>, "draft-ietf-bfcpbis-rfc4582bis@ietf.org" <draft-ietf-bf= cpbis-rfc4582bis@ietf.org>, "bfcpbis@ietf.org" <bfcpbis@ietf.org= >

Subject: Re: [bfcpbis] Spencer Dawk= ins' Discuss on draft-ietf-bfcpbis-rfc4582bis-15: (with DISCUSS and COM= MENT)

Hi, Charles,

On Fri, Nov 13, 2015 at 1:11 PM, Charles Eckel (= eckelcu) <eckelcu@cisco.com> wrote:
Hi Spencer,

Please see inline.

From: Spencer Dawkins at IETF= <spe= ncerdawkins.ietf@gmail.com>
Date: Saturday, November 14,= 2015 at 2:57 AM
To: Alissa Cooper <alissa@cooperw.in>
Cc: IESG <iesg@ietf.org>, "bfcpbis-chairs@ietf.org&quo= t; <bfcpbis= -chairs@ietf.org>, Paul Jones <= paulej@packetizer.com>, "gorry@erg.abdn.ac.uk" <gorry@erg.abdn.ac.uk>, Mary Barnes <mary.ietf.barnes@gmail.com>, "draft-ietf-bfcpbis-rfc4582= bis@ietf.org" <draft-ietf-bfcpbis-rfc4582bis@ietf.org>, "bfcpbis@ietf.o= rg" <bfcp= bis@ietf.org>, Charles Eckel <eckelcu@cisco.com>

Subject: Re: [bfcpbis] Spencer Dawk= ins' Discuss on draft-ietf-bfcpbis-rfc4582bis-15: (with DISCUSS and COM= MENT)

So, we're getting there.

On Wed, Nov 11, 2015 at 4:38 PM, Alissa Cooper <= span dir=3D"ltr"> <alissa@cooperw.i= n> wrote:
Hi Spencer,

Does Charles=E2=80=99 proposal below work for you?

Thanks,
Alissa

On Nov 5, 2015, at 3:42 PM, Charles Eckel (eckelcu) <eckelcu@cisco.com> wrote:

From: Spencer Dawkins at IETF <<= a href=3D"mailto:spencerdawkins.ietf@gmail.com" target=3D"_blank">spencerda= wkins.ietf@gmail.com>
Date: Friday, November 6, 2015 at 7= :23 AM
To: Alissa Cooper <alissa@cooperw.in>
Cc: "iesg@ietf.org" <iesg@ietf.org>, "bfcpbis-chairs@ietf.org&qu= ot; <bfcpbis-c= hairs@ietf.org>, Paul Jones <paulej@packetizer.com>, "gorry@erg.abdn.ac.uk" <gorry@erg.ab= dn.ac.uk>, Mary Barnes <mary.ietf.barnes@gmail.com>, "draft-iet= f-bfcpbis-rfc4582bis@ietf.org" <draft-ietf-bfcpbis-rfc4582bis@ietf.org>, "bfcpbis@ietf.org" <bfcpbis@ietf.org>, Charles Eckel <e= ckelcu@cisco.com>
Subject: Re: [bfcpbis] Spencer Dawk= ins' Discuss on draft-ietf-bfcpbis-rfc4582bis-15: (with DISCUSS and COM= MENT)

Hi, Alissa,
On Nov 6, 2015 7:06 AM, "Alissa Cooper" <alissa@cooperw.in>= ; wrote:
>
> Hi Spencer,
>
>
>
> On Nov 5, 2015, at 11:20 PM, Spencer Dawkins at IETF <spencerdawkins.ietf@g= mail.com> wrote:
>
>> Hi, Charles,
>>
>> On Thu, Nov 5, 2015 at 5:43 PM, Charles Eckel (eckelcu) <eckelcu@cisco.com> = wrote:
>>>
>>> For TCP, the use of TLS was not required by RFC 4582. For 4582= bis, we do not require TLS in order to maintain backward compatibility with= RFC 4582.
>>
>>
>> Got it. I'm holding my nose on this one, based on backward com= patibility, and given the degree of difficulty in splicing attack packets i= nto the TCP sequence numbering space if you're off-path. I'm not th= rilled, but someone else needs to decide when threats reach the level where making that incompatible change is necessary - and t= hat might not be the right thing to do today.
>> =C2=A0
>>>
>>> For UDP, the reason for not mandating DTLS is backward compati= bility with existing solutions. The IMTC Role Based Video Best Practice est= ablished a set of recommendations for getting BFCP to work =C2=A0within ent= erprise video conference deployments. As that time,draft-sandbakken-xcon-bfcp-udp=C2=A0defined BFCP over UDP only. DTLS = was left for future study. Today we have many implementations of BFCP over = UDP, but few if any using DTLS. We need the ultimate RFC that standardizes = BFCP over UDP (and over DTLS) to allow interworking with these existing deployments.
>>
>>
>> OK, I'm not the Protocol Security Police, so, fine, but it see= ms like the draft could be clearer about this, and what you said in your an= swer would be really helpful in the document.=C2=A0
>>
>> If the text said something like "DTLS is REQUIRED unless you = are interworking with a pre-standardization deployment that is already inse= cure,
>
>
> "REQUIRED unless" strikes me as a faulty construction. That = case is what RECOMMENDED is for, when there is a known exception to the req= uirement.
That usage is certainly more common in some parts of the I= ETF than others, but it does get used. But ignoring that.
Do you think "RECOMMENDED unless you are interworking= with a pre-standardization deployment that is already insecure" is ti= ght enough?
The reason I'm asking, is that offpath attacks on UDP-= based protocols are a lot easier than TCP-based protocols, and if the IETF = is going to publish a proposed standard with a known deficiency to accommod= ate pre-standardization deployments, I'd prefer that the guidance about using that accommodation be as clear as pos= sible.

I agree with y= our intent. My concern with calling out exceptions is that it can make the = existing recommendation in the draft seem weaker. How about this:

OLD:

=C2=A0 =C2=A0=E2=80=A6 It is RECOMMENDED that TLS/DTLS with an<= /div>
=C2=A0 =C2=A0encryption algorithm ac= cording to Section 7 always be used.=C2=A0 In cases
=C2=A0 =C2=A0where signaling/control= traffic is properly protected, as described
=C2=A0 =C2=A0in Section 9 it is REQU= IRED to use a mandated encryption algorithm.
=C2=A0 =C2=A0BFCP entities MAY use o= ther security mechanisms as long as they
=C2=A0 =C2=A0provide similar securit= y properties.

NEW

=C2=A0 =C2=A0=E2=80=A6 It is RECOMMENDED = that TLS/DTLS with an
=C2=A0 =C2=A0encryption algorithm according to Section 7 always be= used.=C2=A0 In cases
=C2=A0 =C2=A0where signaling/control traffic is properly protected= , as described
=C2=A0 =C2=A0in Section 9 it is REQUIRED to use a mandated encrypt= ion algorithm.
=C2=A0 =C2=A0BFCP entities MAY use other security mechanisms to in= terwork with=C2=A0
=C2=A0 =C2=A0legacy implementation that do not use TLS/DTLS as lon= g as these=C2=A0
=C2=A0 =C2=A0mechanisms=C2=A0provide similar security properties.=C2=A0

Probably for Charles:

This last sentence seems to be responsible for most of my remaining he= artburn.=C2=A0

My understanding was that TLS and (especially) DTLS were RECOMMENDED, = not REQUIRED, because there are legacy implementations that have been deplo= yed already. I can live with that, but is it obvious to everyone how a lega= cy receiver tells a sender to use a non-TLS/DTLS mechanism? I'm looking at the "use TLS" and &= quot;use DTLS" error codes in Table 5, and wondering where the "u= se legacy security mechanism" error code might be.=C2=A0

Do legacy endpoints "just know" this?

This draft des= cribes how to use SDP to establish a BFCP connection. The determination of = whether to use TLS or TCP or DTLS or UDP is based on the SDP offer/answer a= nd the specification within it of the m-line, e.g.

m=3Dapplication 50000 UDP/BFCP *

m=3Dapplication 50000 TCP/BFCP *

m=3Dapplication 50000 TCP/TLS/BFCP *

m=3Dapplication 50000 UDP/TLS/BFCP *


When making the offer, an implementation has a choice of using any of = these and the answerer can choose to accept of reject. Some very implementa= tions supported TCP only. Most current implementations support UDP only or = in addition to TCP. In the future, we hope all with support DTLS. Typically implementation the support more t= han one transport provide configuration options, such as require DTLS, or o= ffer DTLS but accept UDP or DTLS, or offer DTLS first and if rejected offer= UDP. The current IMTC best practice recommends offering UDP and if that fails offer TCP. This will be updated = to include DTLS once RFC4583bis is published. =C2=A0

This all makes perfect sense to me. I'm not understanding how lega= cy implementations offering "UDP only" maps onto "other mech= anisms that provide similar security properties" in the proposed text.= =C2=A0

Is "other mechanisms that provide similar security properties&quo= t; even talking about the same thing?

And thanks for the quick follow-up.

Likewise. An example of other mechanisms is IPSEC and having a UDP bas= ed BFCP =C2=A0connection within it.

=
OK, so you're talking about security mechanisms that aren't un= der application control at all then. I love those :D

I'll clear, but I think the document might be clearer if you said th= at (even as an example).

Thanks,

Spencer
=C2=A0
Cheers,
Charles


Spencer
=C2=A0
Cheers,
Charles

Thanks,

Spencer
=C2=A0
Cheers,
Charles
=C2=A0

Thanks,
Spencer
> Alissa
>
>> in which case you're not making things worse by running withou= t transport-level security", that would capture my concern and reflect= what you're saying, unless I'm missing something.
>>
>> Thanks to you and Paul for the speedy response on the evening of B= its and Bites!
>>
>> Spencer
>>
>> _______________________________________________
>>
>> bfcpbis mailing list
>> bfcpbis@ietf= .org
>> https://www.ietf.org/mailman/listinfo/bfcpbis

--001a114e4e7438a07b0524728eb9-- From nobody Fri Nov 13 13:21:20 2015 Return-Path: X-Original-To: bfcpbis@ietf.org Delivered-To: bfcpbis@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 2F3F81B323A; Fri, 13 Nov 2015 13:21:17 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "Spencer Dawkins" To: "The IESG" X-Test-IDTracker: no X-IETF-IDTracker: 6.9.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20151113212117.17871.25116.idtracker@ietfa.amsl.com> Date: Fri, 13 Nov 2015 13:21:17 -0800 Archived-At: Cc: mary.ietf.barnes@gmail.com, bfcpbis-chairs@ietf.org, bfcpbis@ietf.org, draft-ietf-bfcpbis-rfc4582bis@ietf.org Subject: [bfcpbis] Spencer Dawkins' No Objection on draft-ietf-bfcpbis-rfc4582bis-15: (with COMMENT) X-BeenThere: bfcpbis@ietf.org X-Mailman-Version: 2.1.15 List-Id: BFCPBIS working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 13 Nov 2015 21:21:17 -0000 Spencer Dawkins has entered the following ballot position for draft-ietf-bfcpbis-rfc4582bis-15: No Objection When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-bfcpbis-rfc4582bis/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- Thanks for working through my Discuss. From nobody Fri Nov 13 13:32:26 2015 Return-Path: X-Original-To: bfcpbis@ietfa.amsl.com Delivered-To: bfcpbis@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3D5AE1B32AC; Fri, 13 Nov 2015 13:32:25 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -13.91 X-Spam-Level: X-Spam-Status: No, score=-13.91 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, J_CHICKENPOX_111=0.6, 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 gzvt7mbDSV5Z; Fri, 13 Nov 2015 13:32:20 -0800 (PST) Received: from rcdn-iport-6.cisco.com (rcdn-iport-6.cisco.com [173.37.86.77]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4A3DD1B32AB; Fri, 13 Nov 2015 13:32:20 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=41329; q=dns/txt; s=iport; t=1447450340; x=1448659940; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=dOO1oLE99KG3J2Cy2R4u6yD6cR0VYN2W+W5z6ugeuBA=; b=aZzfRT80dbGct3f1oDo/QTDwXRWHoa+CQuOnHk+ruykcDzJSJsx5ym5K 05dLD4gG6BVlsTUdEsD/2CxY5Ka+g86PCy1tsilwjo1gFMh/qqKALmUZA 4uutcTpDKK8Rzp3RMTm+WyxzGYbB2yFg3FPPfJrupMwOaiZ4NUMkCX4RU 4=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0AtAgCJVUZW/4YNJK1egm5NU28GvkYBD?= =?us-ascii?q?YFkFwEJhSVKAoE+OBQBAQEBAQEBgQqENAEBAQMBAQEBF04GCwULAgEIEQMBAgE?= =?us-ascii?q?gAQIEByEGCxQJCAIEDgUbh34DCggNu0UNhFcBAQEBAQEBAQEBAQEBAQEBAQEBA?= =?us-ascii?q?QEUBIpMgQaCU4IoDYQxBYdOhn+EGoNhAYgNgySBdYFbhECOV4Nhg3EBHwEBQoI?= =?us-ascii?q?RHRaBQHIBhDWBBwEBAQ?= X-IronPort-AV: E=Sophos; i="5.20,289,1444694400"; d="scan'208,217"; a="46681715" Received: from alln-core-12.cisco.com ([173.36.13.134]) by rcdn-iport-6.cisco.com with ESMTP; 13 Nov 2015 21:32:18 +0000 Received: from XCH-ALN-019.cisco.com (xch-aln-019.cisco.com [173.36.7.29]) by alln-core-12.cisco.com (8.14.5/8.14.5) with ESMTP id tADLWIho003563 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Fri, 13 Nov 2015 21:32:18 GMT Received: from xch-aln-018.cisco.com (173.36.7.28) by XCH-ALN-019.cisco.com (173.36.7.29) with Microsoft SMTP Server (TLS) id 15.0.1104.5; Fri, 13 Nov 2015 15:32:18 -0600 Received: from xch-aln-018.cisco.com ([173.36.7.28]) by XCH-ALN-018.cisco.com ([173.36.7.28]) with mapi id 15.00.1104.000; Fri, 13 Nov 2015 15:32:17 -0600 From: "Charles Eckel (eckelcu)" To: Spencer Dawkins at IETF Thread-Topic: [bfcpbis] Spencer Dawkins' Discuss on draft-ietf-bfcpbis-rfc4582bis-15: (with DISCUSS and COMMENT) Thread-Index: AQHRF3IJ5JJDWYYKUEOdhULB9tmr356NOVMAgAAGM4CAANkWAP//x2GAgACCJ4CAAASuAIAArPmAgAjFKICAAtZLgP//jpIAgACh/AD//35cAAARCe4A//9+pgA= Date: Fri, 13 Nov 2015 21:32:17 +0000 Message-ID: References: <20151105023108.17210.54132.idtracker@ietfa.amsl.com> <19C90DA9-652D-499F-8462-7EC7878307CB@packetizer.com> <5D0066E2-6BD9-4ED8-A37D-CE83118E099E@cooperw.in> <0BAEEA7C-B892-460B-AAD3-80A0F85E766D@cooperw.in> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.5.8.151023 x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.24.78.221] Content-Type: multipart/alternative; boundary="_000_D26B955B5EB22eckelcuciscocom_" MIME-Version: 1.0 Archived-At: Cc: "gorry@erg.abdn.ac.uk" , "bfcpbis-chairs@ietf.org" , "bfcpbis@ietf.org" , Alissa Cooper , "draft-ietf-bfcpbis-rfc4582bis@ietf.org" , "Paul E. Jones" , IESG , Mary Barnes Subject: Re: [bfcpbis] Spencer Dawkins' Discuss on draft-ietf-bfcpbis-rfc4582bis-15: (with DISCUSS and COMMENT) X-BeenThere: bfcpbis@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: BFCPBIS working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 13 Nov 2015 21:32:25 -0000 --_000_D26B955B5EB22eckelcuciscocom_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable Thanks Spencer. Based on your feedback, I have updated the proposal: OLD: =85 It is RECOMMENDED that TLS/DTLS with an encryption algorithm according to Section 7 always be used. In cases where signaling/control traffic is properly protected, as described in Section 9 it is REQUIRED to use a mandated encryption algorithm. BFCP entities MAY use other security mechanisms as long as they provide similar security properties. NEW =85 It is RECOMMENDED that TLS/DTLS with an encryption algorithm according to Section 7 always be used. In cases where signaling/control traffic is properly protected, as described in Section 9 it is REQUIRED to use a mandated encryption algorithm. BFCP entities MAY use other security mechanisms to interwork with legacy implementation that do not use TLS/DTLS as long as these mechanisms provide similar security properties. An example of other mechanisms is IPSEC to effectively secure a non-secure BFCP connection. Cheers, Charles From: Spencer Dawkins at IETF > Date: Friday, November 13, 2015 at 1:15 PM To: Charles Eckel > Cc: Alissa Cooper >, IESG >, "bfcpbis-chairs@ietf.org" >,= Paul Jones >, "gorry@e= rg.abdn.ac.uk" >, Mary Barnes >, "draft-ietf-bfcpbis-rfc4582bis@ietf.org" >, "bfcpbis@ietf.org" > Subject: Re: [bfcpbis] Spencer Dawkins' Discuss on draft-ietf-bfcpbis-rfc45= 82bis-15: (with DISCUSS and COMMENT) Hi, Charles, On Fri, Nov 13, 2015 at 3:07 PM, Charles Eckel (eckelcu) > wrote: From: Spencer Dawkins at IETF > Date: Friday, November 13, 2015 at 12:51 PM To: Charles Eckel > Cc: Alissa Cooper >, IESG >, "bfcpbis-chairs@ietf.org" >,= Paul Jones >, "gorry@e= rg.abdn.ac.uk" >, Mary Barnes >, "draft-ietf-bfcpbis-rfc4582bis@ietf.org" >, "bfcpbis@ietf.org" > Subject: Re: [bfcpbis] Spencer Dawkins' Discuss on draft-ietf-bfcpbis-rfc45= 82bis-15: (with DISCUSS and COMMENT) Hi, Charles, On Fri, Nov 13, 2015 at 1:11 PM, Charles Eckel (eckelcu) > wrote: Hi Spencer, Please see inline. From: Spencer Dawkins at IETF > Date: Saturday, November 14, 2015 at 2:57 AM To: Alissa Cooper > Cc: IESG >, "bfcpbis-chairs@ietf.org" >, Paul Jones >, "gorry@erg.abdn.ac.uk" >, Mary Barnes >, "draft-ietf-bfcpbis-rfc4582bis@ietf.o= rg" >, "bfcpbis@i= etf.org" >, Charles Eckel > Subject: Re: [bfcpbis] Spencer Dawkins' Discuss on draft-ietf-bfcpbis-rfc45= 82bis-15: (with DISCUSS and COMMENT) So, we're getting there. On Wed, Nov 11, 2015 at 4:38 PM, Alissa Cooper > wrote: Hi Spencer, Does Charles=92 proposal below work for you? Thanks, Alissa On Nov 5, 2015, at 3:42 PM, Charles Eckel (eckelcu) > wrote: From: Spencer Dawkins at IETF > Date: Friday, November 6, 2015 at 7:23 AM To: Alissa Cooper > Cc: "iesg@ietf.org" >, "bfcpbis-chairs@ietf.org" >, Paul Jones >, "gorry@erg.abdn.ac.uk" >, Mary B= arnes >, "dra= ft-ietf-bfcpbis-rfc4582bis@ietf.org" >, "bfcpbis@ietf.org" >, Charles Eckel > Subject: Re: [bfcpbis] Spencer Dawkins' Discuss on draft-ietf-bfcpbis-rfc45= 82bis-15: (with DISCUSS and COMMENT) Hi, Alissa, On Nov 6, 2015 7:06 AM, "Alissa Cooper" > wrote: > > Hi Spencer, > > > > On Nov 5, 2015, at 11:20 PM, Spencer Dawkins at IETF > wrote: > >> Hi, Charles, >> >> On Thu, Nov 5, 2015 at 5:43 PM, Charles Eckel (eckelcu) > wrote: >>> >>> For TCP, the use of TLS was not required by RFC 4582. For 4582bis, we d= o not require TLS in order to maintain backward compatibility with RFC 4582= . >> >> >> Got it. I'm holding my nose on this one, based on backward compatibility= , and given the degree of difficulty in splicing attack packets into the TC= P sequence numbering space if you're off-path. I'm not thrilled, but someon= e else needs to decide when threats reach the level where making that incom= patible change is necessary - and that might not be the right thing to do t= oday. >> >>> >>> For UDP, the reason for not mandating DTLS is backward compatibility wi= th existing solutions. The IMTC Role Based Video Best Practice established = a set of recommendations for getting BFCP to work within enterprise video = conference deployments. As that time,draft-sandbakken-xcon-bfcp-udp defined= BFCP over UDP only. DTLS was left for future study. Today we have many imp= lementations of BFCP over UDP, but few if any using DTLS. We need the ultim= ate RFC that standardizes BFCP over UDP (and over DTLS) to allow interworki= ng with these existing deployments. >> >> >> OK, I'm not the Protocol Security Police, so, fine, but it seems like th= e draft could be clearer about this, and what you said in your answer would= be really helpful in the document. >> >> If the text said something like "DTLS is REQUIRED unless you are interwo= rking with a pre-standardization deployment that is already insecure, > > > "REQUIRED unless" strikes me as a faulty construction. That case is what = RECOMMENDED is for, when there is a known exception to the requirement. That usage is certainly more common in some parts of the IETF than others, = but it does get used. But ignoring that. Do you think "RECOMMENDED unless you are interworking with a pre-standardiz= ation deployment that is already insecure" is tight enough? The reason I'm asking, is that offpath attacks on UDP-based protocols are a= lot easier than TCP-based protocols, and if the IETF is going to publish a= proposed standard with a known deficiency to accommodate pre-standardizati= on deployments, I'd prefer that the guidance about using that accommodation= be as clear as possible. I agree with your intent. My concern with calling out exceptions is that it= can make the existing recommendation in the draft seem weaker. How about t= his: OLD: =85 It is RECOMMENDED that TLS/DTLS with an encryption algorithm according to Section 7 always be used. In cases where signaling/control traffic is properly protected, as described in Section 9 it is REQUIRED to use a mandated encryption algorithm. BFCP entities MAY use other security mechanisms as long as they provide similar security properties. NEW =85 It is RECOMMENDED that TLS/DTLS with an encryption algorithm according to Section 7 always be used. In cases where signaling/control traffic is properly protected, as described in Section 9 it is REQUIRED to use a mandated encryption algorithm. BFCP entities MAY use other security mechanisms to interwork with legacy implementation that do not use TLS/DTLS as long as these mechanisms provide similar security properties. Probably for Charles: This last sentence seems to be responsible for most of my remaining heartbu= rn. My understanding was that TLS and (especially) DTLS were RECOMMENDED, not R= EQUIRED, because there are legacy implementations that have been deployed a= lready. I can live with that, but is it obvious to everyone how a legacy re= ceiver tells a sender to use a non-TLS/DTLS mechanism? I'm looking at the "= use TLS" and "use DTLS" error codes in Table 5, and wondering where the "us= e legacy security mechanism" error code might be. Do legacy endpoints "just know" this? This draft describes how to use SDP to establish a BFCP connection. The det= ermination of whether to use TLS or TCP or DTLS or UDP is based on the SDP = offer/answer and the specification within it of the m-line, e.g. m=3Dapplication 50000 UDP/BFCP * m=3Dapplication 50000 TCP/BFCP * m=3Dapplication 50000 TCP/TLS/BFCP * m=3Dapplication 50000 UDP/TLS/BFCP * When making the offer, an implementation has a choice of using any of these= and the answerer can choose to accept of reject. Some very implementations= supported TCP only. Most current implementations support UDP only or in ad= dition to TCP. In the future, we hope all with support DTLS. Typically impl= ementation the support more than one transport provide configuration option= s, such as require DTLS, or offer DTLS but accept UDP or DTLS, or offer DTL= S first and if rejected offer UDP. The current IMTC best practice recommend= s offering UDP and if that fails offer TCP. This will be updated to include= DTLS once RFC4583bis is published. This all makes perfect sense to me. I'm not understanding how legacy implem= entations offering "UDP only" maps onto "other mechanisms that provide simi= lar security properties" in the proposed text. Is "other mechanisms that provide similar security properties" even talking= about the same thing? And thanks for the quick follow-up. Likewise. An example of other mechanisms is IPSEC and having a UDP based BF= CP connection within it. OK, so you're talking about security mechanisms that aren't under applicati= on control at all then. I love those :D I'll clear, but I think the document might be clearer if you said that (eve= n as an example). Thanks, Spencer Cheers, Charles Spencer Cheers, Charles Thanks, Spencer Cheers, Charles Thanks, Spencer > Alissa > >> in which case you're not making things worse by running without transpor= t-level security", that would capture my concern and reflect what you're sa= ying, unless I'm missing something. >> >> Thanks to you and Paul for the speedy response on the evening of Bits an= d Bites! >> >> Spencer >> >> _______________________________________________ >> >> bfcpbis mailing list >> bfcpbis@ietf.org >> https://www.ietf.org/mailman/listinfo/bfcpbis --_000_D26B955B5EB22eckelcuciscocom_ Content-Type: text/html; charset="Windows-1252" Content-ID: Content-Transfer-Encoding: quoted-printable
Thanks Spencer. Based on your feedback, I have updated the proposal:

OLD:

   =85 It is RECOMMENDED t= hat TLS/DTLS with an
   encryption algorithm ac= cording to Section 7 always be used.  In cases
   where signaling/control= traffic is properly protected, as described
   in Section 9 it is REQU= IRED to use a mandated encryption algorithm.
   BFCP entities MAY use o= ther security mechanisms as long as they
   provide similar securit= y properties.

NEW

   =85 It is RECOMMENDED t= hat TLS/DTLS with an
   encryption algorithm ac= cording to Section 7 always be used.  In cases
   where signaling/control= traffic is properly protected, as described
   in Section 9 it is REQU= IRED to use a mandated encryption algorithm.
   BFCP entities MAY use o= ther security mechanisms to interwork with 
   legacy implementation t= hat do not use TLS/DTLS as long as these 
   mechanisms provide simi= lar security properties. An example of other 
   mechanisms is IPSEC to = effectively secure a non-secure BFCP 
   connection.

Cheers,
Charles


From: Spencer Dawkins at IETF <<= a href=3D"mailto:spencerdawkins.ietf@gmail.com">spencerdawkins.ietf@gmail.c= om>
Date: Friday, November 13, 2015 at = 1:15 PM
To: Charles Eckel <eckelcu@cisco.com>
Cc: Alissa Cooper <alissa@cooperw.in>, IESG <iesg@ietf.org>, "bfcpbis-chairs@ietf.org" <bfcpbis-chairs@ietf.org>, Paul Jones <paulej@packetizer.= com>, "gorry@erg.abdn.a= c.uk" <gorry@erg.abdn.a= c.uk>, Mary Barnes <mary.ietf.barnes@gmail.com>, "draft-ietf= -bfcpbis-rfc4582bis@ietf.org" <draft-ietf-bfcpbis-rfc4582bis@ietf.org>, &= quot;bfcpbis@ietf.org" <bfcpbis@ietf.org>
Subject: Re: [bfcpbis] Spencer Dawk= ins' Discuss on draft-ietf-bfcpbis-rfc4582bis-15: (with DISCUSS and COMMENT= )

Hi, Charles,

On Fri, Nov 13, 2015 at 3:07 PM, Charles Eckel (= eckelcu) <eckelcu@cisco.com> wrote:

From: Spencer Dawk= ins at IETF <spencerdawkins.ietf@gmail.com>
Date: Friday, November 13, 2= 015 at 12:51 PM
To: Charles Eckel <eckelcu@cisco.com>
Cc: Alissa Cooper <alissa@cooperw.in>, IESG &= lt;iesg@ietf.org>= , "bfcpbi= s-chairs@ietf.org" <bfcpbis-c= hairs@ietf.org>, Paul Jones <paulej@packetizer.com>, "gorry@erg.abdn.ac.uk" <gorry@erg.ab= dn.ac.uk>, Mary Barnes <mary.ietf.barnes@gmail.com>, "draft-iet= f-bfcpbis-rfc4582bis@ietf.org" <draft-ietf-bfcpbis-rfc4582bis@ietf.org>, "bfcpbis@ietf.org" <bfcpbis@ietf.org>

Subject: Re: [bfcpbis] Spencer Dawk= ins' Discuss on draft-ietf-bfcpbis-rfc4582bis-15: (with DISCUSS and COMMENT= )

Hi, Charles,

On Fri, Nov 13, 2015 at 1:11 PM, Charles Eckel (= eckelcu) <eckelcu@cisco.com> wrote:
Hi Spencer,

Please see inline.

From: Spencer Dawkins at IETF= <spe= ncerdawkins.ietf@gmail.com>
Date: Saturday, November 14,= 2015 at 2:57 AM
To: Alissa Cooper <alissa@cooperw.in>
Cc: IESG <iesg@ietf.org>, "bfcpbis-chairs@ietf.org&quo= t; <bfcpbis= -chairs@ietf.org>, Paul Jones <= paulej@packetizer.com>, "gorry@erg.abdn.ac.uk" <gorry@erg.abdn.ac.uk>, Mary Barnes <mary.ietf.barnes@gmail.com>, "draft-ietf-bfcpbis-rfc4582= bis@ietf.org" <draft-ietf-bfcpbis-rfc4582bis@ietf.org>, "bfcpbis@ietf.o= rg" <bfcp= bis@ietf.org>, Charles Eckel <eckelcu@cisco.com>

Subject: Re: [bfcpbis] Spencer Dawk= ins' Discuss on draft-ietf-bfcpbis-rfc4582bis-15: (with DISCUSS and COMMENT= )

So, we're getting there.

On Wed, Nov 11, 2015 at 4:38 PM, Alissa Cooper <= span dir=3D"ltr"> <alissa@cooperw.i= n> wrote:
Hi Spencer,

Does Charles=92 proposal below work for you?

Thanks,
Alissa

On Nov 5, 2015, at 3:42 PM, Charles Eckel (eckelcu) <eckelcu@cisco.com> wrote:

From: Spencer Dawkins at IETF <<= a href=3D"mailto:spencerdawkins.ietf@gmail.com" target=3D"_blank">spencerda= wkins.ietf@gmail.com>
Date: Friday, November 6, 2015 at 7= :23 AM
To: Alissa Cooper <alissa@cooperw.in>
Cc: "iesg@ietf.org" <iesg@ietf.org>, "bfcpbis-chairs@ietf.org&qu= ot; <bfcpbis-c= hairs@ietf.org>, Paul Jones <paulej@packetizer.com>, "gorry@erg.abdn.ac.uk" <gorry@erg.ab= dn.ac.uk>, Mary Barnes <mary.ietf.barnes@gmail.com>, "draft-iet= f-bfcpbis-rfc4582bis@ietf.org" <draft-ietf-bfcpbis-rfc4582bis@ietf.org>, "bfcpbis@ietf.org" <bfcpbis@ietf.org>, Charles Eckel <e= ckelcu@cisco.com>
Subject: Re: [bfcpbis] Spencer Dawk= ins' Discuss on draft-ietf-bfcpbis-rfc4582bis-15: (with DISCUSS and COMMENT= )

Hi, Alissa,
On Nov 6, 2015 7:06 AM, "Alissa Cooper" <alissa@cooperw.in>= ; wrote:
>
> Hi Spencer,
>
>
>
> On Nov 5, 2015, at 11:20 PM, Spencer Dawkins at IETF <spencerdawkins.ietf@g= mail.com> wrote:
>
>> Hi, Charles,
>>
>> On Thu, Nov 5, 2015 at 5:43 PM, Charles Eckel (eckelcu) <eckelcu@cisco.com> = wrote:
>>>
>>> For TCP, the use of TLS was not required by RFC 4582. For 4582= bis, we do not require TLS in order to maintain backward compatibility with= RFC 4582.
>>
>>
>> Got it. I'm holding my nose on this one, based on backward compati= bility, and given the degree of difficulty in splicing attack packets into = the TCP sequence numbering space if you're off-path. I'm not thrilled, but = someone else needs to decide when threats reach the level where making that incompatible change is necessary - and t= hat might not be the right thing to do today.
>>  
>>>
>>> For UDP, the reason for not mandating DTLS is backward compati= bility with existing solutions. The IMTC Role Based Video Best Practice est= ablished a set of recommendations for getting BFCP to work  within ent= erprise video conference deployments. As that time,draft-sandbakken-xcon-bfcp-udp defined BFCP over UDP only. DTLS = was left for future study. Today we have many implementations of BFCP over = UDP, but few if any using DTLS. We need the ultimate RFC that standardizes = BFCP over UDP (and over DTLS) to allow interworking with these existing deployments.
>>
>>
>> OK, I'm not the Protocol Security Police, so, fine, but it seems l= ike the draft could be clearer about this, and what you said in your answer= would be really helpful in the document. 
>>
>> If the text said something like "DTLS is REQUIRED unless you = are interworking with a pre-standardization deployment that is already inse= cure,
>
>
> "REQUIRED unless" strikes me as a faulty construction. That = case is what RECOMMENDED is for, when there is a known exception to the req= uirement.
That usage is certainly more common in some parts of the I= ETF than others, but it does get used. But ignoring that.
Do you think "RECOMMENDED unless you are interworking= with a pre-standardization deployment that is already insecure" is ti= ght enough?
The reason I'm asking, is that offpath attacks on UDP-base= d protocols are a lot easier than TCP-based protocols, and if the IETF is g= oing to publish a proposed standard with a known deficiency to accommodate = pre-standardization deployments, I'd prefer that the guidance about using that accommodation be as clear as pos= sible.

I agree with y= our intent. My concern with calling out exceptions is that it can make the = existing recommendation in the draft seem weaker. How about this:

OLD:

   =85 It is RECOMMENDED that TLS/DTLS with an
   encryption algorithm ac= cording to Section 7 always be used.  In cases
   where signaling/control= traffic is properly protected, as described
   in Section 9 it is REQU= IRED to use a mandated encryption algorithm.
   BFCP entities MAY use o= ther security mechanisms as long as they
   provide similar securit= y properties.

NEW

   =85 It is RECOMMENDED that T= LS/DTLS with an
   encryption algorithm according to Section 7 always be= used.  In cases
   where signaling/control traffic is properly protected= , as described
   in Section 9 it is REQUIRED to use a mandated encrypt= ion algorithm.
   BFCP entities MAY use other security mechanisms to in= terwork with 
   legacy implementation that do not use TLS/DTLS as lon= g as these 
   mechanisms provide similar security properties. 

Probably for Charles:

This last sentence seems to be responsible for most of my remaining he= artburn. 

My understanding was that TLS and (especially) DTLS were RECOMMENDED, = not REQUIRED, because there are legacy implementations that have been deplo= yed already. I can live with that, but is it obvious to everyone how a lega= cy receiver tells a sender to use a non-TLS/DTLS mechanism? I'm looking at the "use TLS" and "= ;use DTLS" error codes in Table 5, and wondering where the "use l= egacy security mechanism" error code might be. 

Do legacy endpoints "just know" this?

This draft des= cribes how to use SDP to establish a BFCP connection. The determination of = whether to use TLS or TCP or DTLS or UDP is based on the SDP offer/answer a= nd the specification within it of the m-line, e.g.

m=3Dapplication 50000 UDP/BFCP *

m=3Dapplication 50000 TCP/BFCP *

m=3Dapplication 50000 TCP/TLS/BFCP *

m=3Dapplication 50000 UDP/TLS/BFCP *


When making the offer, an implementation has a choice of using any of = these and the answerer can choose to accept of reject. Some very implementa= tions supported TCP only. Most current implementations support UDP only or = in addition to TCP. In the future, we hope all with support DTLS. Typically implementation the support more t= han one transport provide configuration options, such as require DTLS, or o= ffer DTLS but accept UDP or DTLS, or offer DTLS first and if rejected offer= UDP. The current IMTC best practice recommends offering UDP and if that fails offer TCP. This will be updated = to include DTLS once RFC4583bis is published.  

This all makes perfect sense to me. I'm not understanding how legacy i= mplementations offering "UDP only" maps onto "other mechanis= ms that provide similar security properties" in the proposed text.&nbs= p;

Is "other mechanisms that provide similar security properties&quo= t; even talking about the same thing?

And thanks for the quick follow-up.

Likewise. An example of other mechanisms is IPSEC and having a UDP bas= ed BFCP  connection within it.

OK, so you're talking about security mechanisms that aren't under appl= ication control at all then. I love those :D

I'll clear, but I think the document might be clearer if you said that= (even as an example).

Thanks,

Spencer
 
Cheers,
Charles


Spencer
 
Cheers,
Charles

Thanks,

Spencer
 
Cheers,
Charles
 

Thanks,
Spencer
> Alissa
>
>> in which case you're not making things worse by running without tr= ansport-level security", that would capture my concern and reflect wha= t you're saying, unless I'm missing something.
>>
>> Thanks to you and Paul for the speedy response on the evening of B= its and Bites!
>>
>> Spencer
>>
>> _______________________________________________
>>
>> bfcpbis mailing list
>> bfcpbis@ietf= .org
>> https://www.ietf.org/mailman/listinfo/bfcpbis




 --_000_D26B955B5EB22eckelcuciscocom_-- From nobody Fri Nov 13 13:44:21 2015 Return-Path: X-Original-To: bfcpbis@ietfa.amsl.com Delivered-To: bfcpbis@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8FD0B1B32C1; Fri, 13 Nov 2015 13:44:16 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.711 X-Spam-Level: X-Spam-Status: No, score=-2.711 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_HELO_PASS=-0.001, 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 Ia2lANbdonCp; Fri, 13 Nov 2015 13:44:12 -0800 (PST) Received: from dublin.packetizer.com (dublin.packetizer.com [75.101.130.125]) (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 902FE1B32C0; Fri, 13 Nov 2015 13:44:08 -0800 (PST) Received: from [192.168.1.20] (cpe-098-122-181-215.nc.res.rr.com [98.122.181.215] (may be forged)) (authenticated bits=0) by dublin.packetizer.com (8.15.2/8.15.2) with ESMTPSA id tADLi0iP032028 (version=TLSv1 cipher=ECDHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 13 Nov 2015 16:44:00 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=packetizer.com; s=dublin; t=1447451041; bh=ybc8V0Yoj8cDmKvI5KhwvPdsj0F94q3ZhmAWhQS1wF0=; h=From:To:Subject:Cc:Date:In-Reply-To:Reply-To; b=OOhlHJQe1kXTlVuBMqPBTWCrqxWq05BFBFf0a7bUoWwdMkyl2ZDLvTnOmZ3fT2rl7 ctUHUGeuBsXcjgQyseQSVEx4p0JWKFVUc40RKyJ8IZoXOw21X1iWbKrusTUzEF6DwJ tDAC1b0GAwYAAHIKwlz/GsJiWZaJSwRCyL1Pzf1g= From: "Paul E. Jones" To: "Charles Eckel (eckelcu)" , "Spencer Dawkins at IETF" Date: Fri, 13 Nov 2015 21:44:00 +0000 Message-Id: In-Reply-To: User-Agent: eM_Client/6.0.23421.0 Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="------=_MB76CF6052-B515-4113-83E6-105C5E8083D5" X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.5.12 (dublin.packetizer.com [10.109.150.103]); Fri, 13 Nov 2015 16:44:01 -0500 (EST) Archived-At: Cc: "gorry@erg.abdn.ac.uk" , "bfcpbis-chairs@ietf.org" , "bfcpbis@ietf.org" , Alissa Cooper , "draft-ietf-bfcpbis-rfc4582bis@ietf.org" , IESG , Mary Barnes Subject: Re: [bfcpbis] Spencer Dawkins' Discuss on draft-ietf-bfcpbis-rfc4582bis-15: (with DISCUSS and COMMENT) X-BeenThere: bfcpbis@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: "Paul E. Jones" List-Id: BFCPBIS working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 13 Nov 2015 21:44:16 -0000 --------=_MB76CF6052-B515-4113-83E6-105C5E8083D5 Content-Type: text/plain; format=flowed; charset=utf-8 Content-Transfer-Encoding: quoted-printable OK, we have this and several other suggested changes from Spencer we=20 discussed during 94 that were agreed. I'll revise the text and submit a new version of the draft to include=20 this and the other suggestions. Paul ------ Original Message ------ From: "Charles Eckel (eckelcu)" To: "Spencer Dawkins at IETF" Cc: "Alissa Cooper" ; "IESG" ;=20 "bfcpbis-chairs@ietf.org" ; "Paul E. Jones"=20 ; "gorry@erg.abdn.ac.uk" ;=20 "Mary Barnes" ;=20 "draft-ietf-bfcpbis-rfc4582bis@ietf.org"=20 ; "bfcpbis@ietf.org"=20 Sent: 11/13/2015 4:32:17 PM Subject: Re: [bfcpbis] Spencer Dawkins' Discuss on=20 draft-ietf-bfcpbis-rfc4582bis-15: (with DISCUSS and COMMENT) >Thanks Spencer. Based on your feedback, I have updated the proposal: > >OLD: > > =E2=80=A6 It is RECOMMENDED that TLS/DTLS with an > encryption algorithm according to Section 7 always be used. In=20 >cases > where signaling/control traffic is properly protected, as described > in Section 9 it is REQUIRED to use a mandated encryption algorithm. > BFCP entities MAY use other security mechanisms as long as they > provide similar security properties. > >NEW > > =E2=80=A6 It is RECOMMENDED that TLS/DTLS with an > encryption algorithm according to Section 7 always be used. In=20 >cases > where signaling/control traffic is properly protected, as described > in Section 9 it is REQUIRED to use a mandated encryption algorithm. > BFCP entities MAY use other security mechanisms to interwork with > legacy implementation that do not use TLS/DTLS as long as these > mechanisms provide similar security properties. An example of other > mechanisms is IPSEC to effectively secure a non-secure BFCP > connection. > >Cheers, >Charles > > >From: Spencer Dawkins at IETF >Date: Friday, November 13, 2015 at 1:15 PM >To: Charles Eckel >Cc: Alissa Cooper , IESG ,=20 >"bfcpbis-chairs@ietf.org" , Paul Jones=20 >, "gorry@erg.abdn.ac.uk" ,= =20 >Mary Barnes ,=20 >"draft-ietf-bfcpbis-rfc4582bis@ietf.org"=20 >, "bfcpbis@ietf.org"=20 > >Subject: Re: [bfcpbis] Spencer Dawkins' Discuss on=20 >draft-ietf-bfcpbis-rfc4582bis-15: (with DISCUSS and COMMENT) > >>Hi, Charles, >> >>On Fri, Nov 13, 2015 at 3:07 PM, Charles Eckel (eckelcu)=20 >> wrote: >>> >>>From: Spencer Dawkins at IETF >>>Date: Friday, November 13, 2015 at 12:51 PM >>>To: Charles Eckel >>>Cc: Alissa Cooper , IESG ,=20 >>>"bfcpbis-chairs@ietf.org" , Paul Jones=20 >>>, "gorry@erg.abdn.ac.uk"=20 >>>, Mary Barnes ,=20 >>>"draft-ietf-bfcpbis-rfc4582bis@ietf.org"=20 >>>, "bfcpbis@ietf.org"=20 >>> >>> >>>Subject: Re: [bfcpbis] Spencer Dawkins' Discuss on=20 >>>draft-ietf-bfcpbis-rfc4582bis-15: (with DISCUSS and COMMENT) >>> >>>>Hi, Charles, >>>> >>>>On Fri, Nov 13, 2015 at 1:11 PM, Charles Eckel (eckelcu)=20 >>>> wrote: >>>>>Hi Spencer, >>>>> >>>>>Please see inline. >>>>> >>>>>From: Spencer Dawkins at IETF >>>>>Date: Saturday, November 14, 2015 at 2:57 AM >>>>>To: Alissa Cooper >>>>>Cc: IESG , "bfcpbis-chairs@ietf.org"=20 >>>>>, Paul Jones ,=20 >>>>>"gorry@erg.abdn.ac.uk" , Mary Barnes=20 >>>>>,=20 >>>>>"draft-ietf-bfcpbis-rfc4582bis@ietf.org"=20 >>>>>, "bfcpbis@ietf.org"=20 >>>>>, Charles Eckel >>>>> >>>>>Subject: Re: [bfcpbis] Spencer Dawkins' Discuss on=20 >>>>>draft-ietf-bfcpbis-rfc4582bis-15: (with DISCUSS and COMMENT) >>>>> >>>>>>So, we're getting there. >>>>>> >>>>>>On Wed, Nov 11, 2015 at 4:38 PM, Alissa Cooper = =20 >>>>>>wrote: >>>>>>>Hi Spencer, >>>>>>> >>>>>>>Does Charles=E2=80=99 proposal below work for you? >>>>>>> >>>>>>>Thanks, >>>>>>>Alissa >>>>>>> >>>>>>>>On Nov 5, 2015, at 3:42 PM, Charles Eckel (eckelcu)=20 >>>>>>>> wrote: >>>>>>>> >>>>>>>> >>>>>>>>From: Spencer Dawkins at IETF >>>>>>>>Date: Friday, November 6, 2015 at 7:23 AM >>>>>>>>To: Alissa Cooper >>>>>>>>Cc: "iesg@ietf.org" , "bfcpbis-chairs@ietf.org"=20 >>>>>>>>, Paul Jones ,=20 >>>>>>>>"gorry@erg.abdn.ac.uk" , Mary Barnes=20 >>>>>>>>,=20 >>>>>>>>"draft-ietf-bfcpbis-rfc4582bis@ietf.org"=20 >>>>>>>>, "bfcpbis@ietf.org"=20 >>>>>>>>, Charles Eckel >>>>>>>>Subject: Re: [bfcpbis] Spencer Dawkins' Discuss on=20 >>>>>>>>draft-ietf-bfcpbis-rfc4582bis-15: (with DISCUSS and COMMENT) >>>>>>>> >>>>>>>>>Hi, Alissa, >>>>>>>>>On Nov 6, 2015 7:06 AM, "Alissa Cooper" =20 >>>>>>>>>wrote: >>>>>>>>> > >>>>>>>>> > Hi Spencer, >>>>>>>>> > >>>>>>>>> > >>>>>>>>> > >>>>>>>>> > On Nov 5, 2015, at 11:20 PM, Spencer Dawkins at IETF=20 >>>>>>>>> wrote: >>>>>>>>> > >>>>>>>>> >> Hi, Charles, >>>>>>>>> >> >>>>>>>>> >> On Thu, Nov 5, 2015 at 5:43 PM, Charles Eckel (eckelcu)=20 >>>>>>>>> wrote: >>>>>>>>> >>> >>>>>>>>> >>> For TCP, the use of TLS was not required by RFC 4582. For=20 >>>>>>>>>4582bis, we do not require TLS in order to maintain backward=20 >>>>>>>>>compatibility with RFC 4582. >>>>>>>>> >> >>>>>>>>> >> >>>>>>>>> >> Got it. I'm holding my nose on this one, based on backward=20 >>>>>>>>>compatibility, and given the degree of difficulty in splicing=20 >>>>>>>>>attack packets into the TCP sequence numbering space if you're=20 >>>>>>>>>off-path. I'm not thrilled, but someone else needs to decide=20 >>>>>>>>>when threats reach the level where making that incompatible=20 >>>>>>>>>change is necessary - and that might not be the right thing to=20 >>>>>>>>>do today. >>>>>>>>> >> >>>>>>>>> >>> >>>>>>>>> >>> For UDP, the reason for not mandating DTLS is backward=20 >>>>>>>>>compatibility with existing solutions. The IMTC Role Based=20 >>>>>>>>>Video Best Practice established a set of recommendations for=20 >>>>>>>>>getting BFCP to work within enterprise video conference=20 >>>>>>>>>deployments. As that time,draft-sandbakken-xcon-bfcp-udp=20 >>>>>>>>>defined BFCP over UDP only. DTLS was left for future study.=20 >>>>>>>>>Today we have many implementations of BFCP over UDP, but few if= =20 >>>>>>>>>any using DTLS. We need the ultimate RFC that standardizes BFCP= =20 >>>>>>>>>over UDP (and over DTLS) to allow interworking with these=20 >>>>>>>>>existing deployments. >>>>>>>>> >> >>>>>>>>> >> >>>>>>>>> >> OK, I'm not the Protocol Security Police, so, fine, but it=20 >>>>>>>>>seems like the draft could be clearer about this, and what you=20 >>>>>>>>>said in your answer would be really helpful in the document. >>>>>>>>> >> >>>>>>>>> >> If the text said something like "DTLS is REQUIRED unless you= =20 >>>>>>>>>are interworking with a pre-standardization deployment that is=20 >>>>>>>>>already insecure, >>>>>>>>> > >>>>>>>>> > >>>>>>>>> > "REQUIRED unless" strikes me as a faulty construction. That=20 >>>>>>>>>case is what RECOMMENDED is for, when there is a known=20 >>>>>>>>>exception to the requirement. >>>>>>>>>That usage is certainly more common in some parts of the IETF=20 >>>>>>>>>than others, but it does get used. But ignoring that. >>>>>>>>>Do you think "RECOMMENDED unless you are interworking with a=20 >>>>>>>>>pre-standardization deployment that is already insecure" is=20 >>>>>>>>>tight enough? >>>>>>>>>The reason I'm asking, is that offpath attacks on UDP-based=20 >>>>>>>>>protocols are a lot easier than TCP-based protocols, and if the= =20 >>>>>>>>>IETF is going to publish a proposed standard with a known=20 >>>>>>>>>deficiency to accommodate pre-standardization deployments, I'd=20 >>>>>>>>>prefer that the guidance about using that accommodation be as=20 >>>>>>>>>clear as possible. >>>>>>>> >>>>>>>>I agree with your intent. My concern with calling out exceptions= =20 >>>>>>>>is that it can make the existing recommendation in the draft=20 >>>>>>>>seem weaker. How about this: >>>>>>>> >>>>>>>>OLD: >>>>>>>> >>>>>>>> =E2=80=A6 It is RECOMMENDED that TLS/DTLS with an >>>>>>>> encryption algorithm according to Section 7 always be used. = =20 >>>>>>>>In cases >>>>>>>> where signaling/control traffic is properly protected, as=20 >>>>>>>>described >>>>>>>> in Section 9 it is REQUIRED to use a mandated encryption=20 >>>>>>>>algorithm. >>>>>>>> BFCP entities MAY use other security mechanisms as long as=20 >>>>>>>>they >>>>>>>> provide similar security properties. >>>>>>>> >>>>>>>>NEW >>>>>>>> >>>>>>>> =E2=80=A6 It is RECOMMENDED that TLS/DTLS with an >>>>>>>> encryption algorithm according to Section 7 always be used. = =20 >>>>>>>>In cases >>>>>>>> where signaling/control traffic is properly protected, as=20 >>>>>>>>described >>>>>>>> in Section 9 it is REQUIRED to use a mandated encryption=20 >>>>>>>>algorithm. >>>>>>>> BFCP entities MAY use other security mechanisms to interwork= =20 >>>>>>>>with >>>>>>>> legacy implementation that do not use TLS/DTLS as long as=20 >>>>>>>>these >>>>>>>> mechanisms provide similar security properties. >>>>>> >>>>>>Probably for Charles: >>>>>> >>>>>>This last sentence seems to be responsible for most of my=20 >>>>>>remaining heartburn. >>>>>> >>>>>>My understanding was that TLS and (especially) DTLS were=20 >>>>>>RECOMMENDED, not REQUIRED, because there are legacy=20 >>>>>>implementations that have been deployed already. I can live with=20 >>>>>>that, but is it obvious to everyone how a legacy receiver tells a=20 >>>>>>sender to use a non-TLS/DTLS mechanism? I'm looking at the "use=20 >>>>>>TLS" and "use DTLS" error codes in Table 5, and wondering where=20 >>>>>>the "use legacy security mechanism" error code might be. >>>>>> >>>>>>Do legacy endpoints "just know" this? >>>>> >>>>>This draft describes how to use SDP to establish a BFCP connection.= =20 >>>>>The determination of whether to use TLS or TCP or DTLS or UDP is=20 >>>>>based on the SDP offer/answer and the specification within it of=20 >>>>>the m-line, e.g. >>>>> >>>>>m=3Dapplication 50000 UDP/BFCP * >>>>> >>>>> >>>>>m=3Dapplication 50000 TCP/BFCP * >>>>> >>>>>m=3Dapplication 50000 TCP/TLS/BFCP * >>>>> >>>>>m=3Dapplication 50000 UDP/TLS/BFCP * >>>>> >>>>> >>>>>When making the offer, an implementation has a choice of using any=20 >>>>>of these and the answerer can choose to accept of reject. Some very= =20 >>>>>implementations supported TCP only. Most current implementations=20 >>>>>support UDP only or in addition to TCP. In the future, we hope all=20 >>>>>with support DTLS. Typically implementation the support more than=20 >>>>>one transport provide configuration options, such as require DTLS,=20 >>>>>or offer DTLS but accept UDP or DTLS, or offer DTLS first and if=20 >>>>>rejected offer UDP. The current IMTC best practice recommends=20 >>>>>offering UDP and if that fails offer TCP. This will be updated to=20 >>>>>include DTLS once RFC4583bis is published. >>>> >>>>This all makes perfect sense to me. I'm not understanding how legacy= =20 >>>>implementations offering "UDP only" maps onto "other mechanisms that= =20 >>>>provide similar security properties" in the proposed text. >>>> >>>>Is "other mechanisms that provide similar security properties" even=20 >>>>talking about the same thing? >>>> >>>>And thanks for the quick follow-up. >>> >>>Likewise. An example of other mechanisms is IPSEC and having a UDP=20 >>>based BFCP connection within it. >> >>OK, so you're talking about security mechanisms that aren't under=20 >>application control at all then. I love those :D >> >>I'll clear, but I think the document might be clearer if you said that= =20 >>(even as an example). >> >>Thanks, >> >>Spencer >> >>>Cheers, >>>Charles >>> >>>> >>>>Spencer >>>> >>>>>Cheers, >>>>>Charles >>>>> >>>>>>Thanks, >>>>>> >>>>>>Spencer >>>>>> >>>>>>>>Cheers, >>>>>>>>Charles >>>>>>>> >>>>>>>>> >>>>>>>>>Thanks, >>>>>>>>>Spencer >>>>>>>>> > Alissa >>>>>>>>> > >>>>>>>>> >> in which case you're not making things worse by running=20 >>>>>>>>>without transport-level security", that would capture my=20 >>>>>>>>>concern and reflect what you're saying, unless I'm missing=20 >>>>>>>>>something. >>>>>>>>> >> >>>>>>>>> >> Thanks to you and Paul for the speedy response on the=20 >>>>>>>>>evening of Bits and Bites! >>>>>>>>> >> >>>>>>>>> >> Spencer >>>>>>>>> >> >>>>>>>>> >> _______________________________________________ >>>>>>>>> >> >>>>>>>>> >> bfcpbis mailing list >>>>>>>>> >>mailto:bfcpbis@ietf.org >>>>>>>>> >> https://www.ietf.org/mailman/listinfo/bfcpbis >>>>>>> >>>>>> >>>> >> --------=_MB76CF6052-B515-4113-83E6-105C5E8083D5 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable
OK, we have this and several other suggested changes from Spencer we= discussed during 94 that were agreed. 
 
I'll revise the text and submit a new version of the draft to include= this and the other suggestions.
 
Paul
 
------ Original Message ------
From: "Charles Eckel (eckelcu)" <eckelcu@cisco.com>
To: "Spencer Dawkins at IETF" <spencerdawkins.ietf@gmail.com>
Cc: "Alissa Cooper" <alissa@co= operw.in>; "IESG" <iesg@ietf.org= >; "bfcpbis-chairs@ietf.org" <bfcpbis-chairs@ietf.org>; "Paul E. Jones" <paulej@packetizer.com>; "gorry@erg.abdn.a= c.uk" <gorry@erg.abdn.ac.uk&= gt;; "Mary Barnes" <mary.i= etf.barnes@gmail.com>; "draft-ietf-bfcpbis-rfc4582bis@ietf.org" <= draft-ietf-bfcpbi= s-rfc4582bis@ietf.org>; "bfcpbis@ietf.org" <bfcpbis@ietf.org>
Sent: 11/13/2015 4:32:17 PM
Subject: Re: [bfcpbis] Spencer Dawkins' Discuss on draft-ietf-bfcpbis-= rfc4582bis-15: (with DISCUSS and COMMENT)
 
Thanks Spencer. Based on your feedback, I have updated the prop= osal:

OLD:

   =E2=80=A6 It is RECOMMEND= ED that TLS/DTLS with an
   encryption algorithm acco= rding to Section 7 always be used.  In cases
   where signaling/control= traffic is properly protected, as described
   in Section 9 it is REQUIR= ED to use a mandated encryption algorithm.
   BFCP entities MAY use = other security mechanisms as long as they
   provide similar security= properties.

NEW

   =E2=80=A6 It is RECOMMEND= ED that TLS/DTLS with an
   encryption algorithm acco= rding to Section 7 always be used.  In cases
   where signaling/control= traffic is properly protected, as described
   in Section 9 it is REQUIR= ED to use a mandated encryption algorithm.
   BFCP entities MAY use = other security mechanisms to interwork with 
   legacy implementation = that do not use TLS/DTLS as long as these 
   mechanisms provide simila= r security properties. An example of other 
   mechanisms is IPSEC to= effectively secure a non-secure BFCP 
   connection.

Cheers,
Charles


From: Spencer Dawkins at IETF <spencerdawkins.ietf@gmail.com>
Date: Friday, November 13, 2015 at 1:15= PM
To: Charles Eckel <eckelcu@cisco.com>
Cc: Alissa Cooper <alissa@cooperw.in>, IESG <iesg@ietf.org>, "= bfcpbis-chairs@ietf.org" <bfcpbis-chairs@ietf.org>, Paul Jones <paulej@packetizer.com>, "gorry@erg.abdn.ac.uk" <gorry@erg.abdn.ac.uk>, Mary Barnes <mary.ietf.barnes@gmail.com>, "draft-ietf-bfcpbis-rfc4582bis@i= etf.org" <= draft-ietf-bfcpbis-rfc4582bis@ietf.org>, "bfcpbis@ietf.org" <bfc= pbis@ietf.org>
Subject: = Re: [bfcpbis] Spencer Dawkins' Discuss on draft-ietf-bfcpbis-rfc4582bis-15:= (with DISCUSS and COMMENT)

Hi, Charles,=20

On Fri, Nov 13, 2015 at 3:07 PM, Charles Eckel = (eckelcu) <eckelcu@= cisco.com> wrote:

From: Spencer Dawkins at IETF <spencerdawkins.ietf@gmail.com>Date: Friday, November = 13, 2015 at 12:51 PM
To: Charle= s Eckel <eckelcu@cisco.com><= BR>Cc: Alissa Cooper <alissa@cooperw.in>, IESG <iesg@ietf.org>, "bfcpbis-chairs@ietf.org" <bfcpbis-chairs@ietf.org>, Paul Jones <paulej@packetizer.com>, "gorry@erg.abdn.ac.uk" <gorry@erg.abdn.ac.uk>, Mary Barnes = <mary.ietf.barnes@gmail.co= m>, "draft= -ietf-bfcpbis-rfc4582bis@ietf.org" <draft-ietf-bfcpbis-rfc4582bis@ietf.org>,= "bfcpbis@ietf.org" <bfcpbis@ietf.org>=20

Subject: Re:= [bfcpbis] Spencer Dawkins' Discuss on draft-ietf-bfcpbis-rfc4582bis-15:= (with DISCUSS and COMMENT)

Hi, Charles,=20

On Fri, Nov 13, 2015 at 1:11 PM, Charles Eckel = (eckelcu) <eckelcu@= cisco.com> wrote:
Hi Spencer,

Please see inline.

From: Spencer Dawkins at IETF <spencerdawkins.ietf@gmail.com>Date: Saturday, November= 14, 2015 at 2:57 AM
To: Alissa= Cooper <alissa@cooperw.in><= BR>Cc: IESG <iesg@ietf.org>, "bfcpbis-chairs@ietf.org" <bfcpbis-chairs@ietf.org>, Paul Jones <paulej@packetizer.com>, "gorry@erg.abdn.ac.uk" <gorry@erg.abdn.ac.uk>, Mary Barnes <mary.ietf.barnes@gmail.com>, "draft-ietf-bfcpbis-rfc45= 82bis@ietf.org" <draft-ietf-bfcpbis-rfc4582bis@ietf.org>, "bfcpbis@ietf.org" <bfcpbis@ietf.org>, Charles Eckel <eckelcu@cisco.com>=20

Subject: Re: [bfcpbis]= Spencer Dawkins' Discuss on draft-ietf-bfcpbis-rfc4582bis-15: (with DISCUS= S and COMMENT)

So, we're getting there.=20

On Wed, Nov 11, 2015 at 4:38 PM, Alissa Cooper = <alissa@cooperw.in<= /A>> wrote:
Hi Spencer,

Does Charles=E2=80=99 proposal below work for you?

Thanks,
Alissa



<= SPAN style=3D"FONT-SIZE: 16px; FONT-FAMILY: Calibri, sans-serif">
From: Spencer Dawkins at IETF <spencerdawkins.ietf@gmail.com>
Date: Friday, November 6, 2015 at 7:23= AM
To: Alissa Cooper <alissa@cooperw.in>
Cc: "iesg@ie= tf.org" <iesg@ietf.org>, = "bfcpbis-chairs@ietf.org"= <bfcpbis-chairs@ietf.org= >, Paul Jones <paulej@packet= izer.com>, "gorry@erg.abdn.a= c.uk" <gorry@erg.abdn.ac.uk<= /A>>, Mary Barnes <mary= .ietf.barnes@gmail.com>, "draft-ietf-bfcpbis-rfc4582bis@ietf.org" <draft-ietf-bfcpbis-rfc4582b= is@ietf.org>, "bfcpbis@ietf.org<= /A>" <bfcpbis@ietf.org>, Char= les Eckel <eckelcu@cisco.com>= ;
Subject: Re: [bfcpbis] Spence= r Dawkins' Discuss on draft-ietf-bfcpbis-rfc4582bis-15: (with DISCUSS and= COMMENT)

Hi, Alissa,
On Nov 6, 2015 7:06 AM, "Alissa Cooper" <alissa@cooperw.in> wrote:
>
> Hi= Spencer,
>
>
>
> On Nov 5, 2015, at 11:20 PM, Spen= cer Dawkins at IETF <sp= encerdawkins.ietf@gmail.com> wrote:
>
>> Hi, Charles,=
>>
>> On Thu, Nov 5, 2015 at 5:43 PM, Charles Eckel (eck= elcu) <eckelcu@cisco.com>= wrote:
>>>
>>> For TCP, the use of TLS was not = required by RFC 4582. For 4582bis, we do not require TLS in order to mainta= in backward compatibility with RFC 4582.
>>
>>
>>= ; Got it. I'm holding my nose on this one, based on backward compatibility,= and given the degree of difficulty in splicing attack packets into the = TCP sequence numbering space if you're off-path. I'm not thrilled, but some= one else needs to decide when threats reach the level where making that = incompatible change is necessary - and that might not be the right thing= to do today.
>>  
>>>
>>> For UDP,= the reason for not mandating DTLS is backward compatibility with existing= solutions. The IMTC Role Based Video Best Practice established a set of= recommendations for getting BFCP to work  within enterprise video = conference deployments. As that time,draft-sandbakken-xcon-bfcp-udp de= fined BFCP over UDP only. DTLS was left for future study. Today we have = many implementations of BFCP over UDP, but few if any using DTLS. We need= the ultimate RFC that standardizes BFCP over UDP (and over DTLS) to allow= interworking with these existing deployments.
>>
>>
&= gt;> OK, I'm not the Protocol Security Police, so, fine, but it seems= like the draft could be clearer about this, and what you said in your answ= er would be really helpful in the document. 
>>
>>= If the text said something like "DTLS is REQUIRED unless you are interwork= ing with a pre-standardization deployment that is already insecure,
>=
>
> "REQUIRED unless" strikes me as a faulty construction. = That case is what RECOMMENDED is for, when there is a known exception to= the requirement.
That usage is certainly more common in some parts of the = IETF than others, but it does get used. But ignoring that.
Do you think "RECOMMENDED unless you are interworking with= a pre-standardization deployment that is already insecure" is tight enough= ?
The reason I'm asking, is that offpath attacks on UDP-based= protocols are a lot easier than TCP-based protocols, and if the IETF is= going to publish a proposed standard with a known deficiency to accommodat= e pre-standardization deployments, I'd prefer that the guidance about using= that accommodation be as clear as possible.
=

I agree = with your intent. My concern with calling out exceptions is that it can = make the existing recommendation in the draft seem weaker. How about this:<= /DIV>

OLD:

   =E2=80=A6 It is RECOMMENDED that TLS/DTLS with an
   encryption algorithm acco= rding to Section 7 always be used.  In cases
   where signaling/control= traffic is properly protected, as described
   in Section 9 it is REQUIR= ED to use a mandated encryption algorithm.
   BFCP entities MAY use = other security mechanisms as long as they
   provide similar security= properties.

NEW

   =E2=80=A6 = It is RECOMMENDED that TLS/DTLS with an
   encryption algorithm according to Section 7 always= be used.  In cases
   where signaling/control traffic is properly protecte= d, as described
   in Section 9 it is REQUIRED to use a mandated encryp= tion algorithm.
   BFCP entities MAY use other security mechanisms to= interwork with 
   legacy implementation that do not use TLS/DTLS as= long as these 
   mechanisms provide similar security properties. 

Probably for Charles:

This last sentence seems to be responsible for most of my remaining= heartburn. 

My understanding was that TLS and (especially) DTLS were RECOMMENDED,= not REQUIRED, because there are legacy implementations that have been depl= oyed already. I can live with that, but is it obvious to everyone how a = legacy receiver tells a sender to use a non-TLS/DTLS mechanism? I'm looking= at the "use TLS" and "use DTLS" error codes in Table 5, and wondering wher= e the "use legacy security mechanism" error code might be. 

Do legacy endpoints "just know" this?

This draft= describes how to use SDP to establish a BFCP connection. The determination= of whether to use TLS or TCP or DTLS or UDP is based on the SDP offer/answ= er and the specification within it of the m-line, e.g.

m=3Dappli= cation 50000 UDP/BFCP *

m=3Dapplication 50000 TCP/BFCP *

m=3Dapplication 50000 = TCP/TLS/BFCP *

m=3Dapplication 50000 = UDP/TLS/BFCP *


When making the offer, an implementation has a choice of using any = of these and the answerer can choose to accept of reject. Some very impleme= ntations supported TCP only. Most current implementations support UDP only= or in addition to TCP. In the future, we hope all with support DTLS. Typic= ally implementation the support more than one transport provide configurati= on options, such as require DTLS, or offer DTLS but accept UDP or DTLS, = or offer DTLS first and if rejected offer UDP. The current IMTC best practi= ce recommends offering UDP and if that fails offer TCP. This will be update= d to include DTLS once RFC4583bis is published.  

This all makes perfect sense to me. I'm not understanding how legacy= implementations offering "UDP only" maps onto "other mechanisms that provi= de similar security properties" in the proposed text. 

Is "other mechanisms that provide similar security properties" even= talking about the same thing?

And thanks for the quick follow-up.

Likewise. An example of other mechanisms is IPSEC and having a UDP = based BFCP  connection within it.

OK, so you're talking about security mechanisms that aren't under appl= ication control at all then. I love those :D

I'll clear, but I think the document might be clearer if you said that= (even as an example).

Thanks,

Spencer
 
Cheers,
Charles


Spencer
 
Cheers,
Charles

Thanks,

Spencer
 
Cheers,
Charles
 

Thanks,
Spencer
> Alissa
>
>> in which case you're not = making things worse by running without transport-level security", that woul= d capture my concern and reflect what you're saying, unless I'm missing = something.
>>
>> Thanks to you and Paul for the speedy= response on the evening of Bits and Bites!
>>
>> Spencer=
>>
>> _______________________________________________>>
>> bfcpbis mailing list
>>mailto:bfcpbis@ietf.org
>> https://www.ietf.org/mailman/listinfo= /bfcpbis




--------=_MB76CF6052-B515-4113-83E6-105C5E8083D5-- From nobody Fri Nov 13 13:48:10 2015 Return-Path: X-Original-To: bfcpbis@ietfa.amsl.com Delivered-To: bfcpbis@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 00CFA1B32DD; Fri, 13 Nov 2015 13:48:09 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.399 X-Spam-Level: X-Spam-Status: No, score=-1.399 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, J_CHICKENPOX_111=0.6, 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 z7nKq-DtQpaN; Fri, 13 Nov 2015 13:48:04 -0800 (PST) Received: from mail-vk0-x22a.google.com (mail-vk0-x22a.google.com [IPv6:2607:f8b0:400c:c05::22a]) (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 94E231B3277; Fri, 13 Nov 2015 13:48:04 -0800 (PST) Received: by vkbq142 with SMTP id q142so86675vkb.3; Fri, 13 Nov 2015 13:48:03 -0800 (PST) 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=q1h0JqUDdvo6u1vZo/mnh1VeBhLg8lmY/tfCH3Mbtlc=; b=nz3/MjphJRBwyAAcHMMTSSlnHJpOsXCzigRLRWmBdGvLf5sLw20zdN/QcRkouF//P3 mFkuAxr8dBHRpkydXvIP0/ZeRWWkq/noReL/FdV181yg5rkLjqEyL1KEhTSwH3epYtpa 805FJX2FEJMZHHHjuIw/kQF7Kc1acDyu+Y3NdQrGLpLp530mnffEOPdnbPg4L/GjAe0j tFn/eW86zJTYjE96yWJbGf1mltBNClmLj6KWtBdb7++ItlLCq44blBL82hExFlFLp87b CM/5I567PChKvd6zVp/NA9C0wWcxTJpcqa1cXNUP44MG+NUdkaqtHcaMAbrA06Ljbaes uuow== MIME-Version: 1.0 X-Received: by 10.31.133.129 with SMTP id h123mr33756vkd.154.1447451283392; Fri, 13 Nov 2015 13:48:03 -0800 (PST) Received: by 10.31.149.79 with HTTP; Fri, 13 Nov 2015 13:48:03 -0800 (PST) In-Reply-To: References: Date: Fri, 13 Nov 2015 15:48:03 -0600 Message-ID: From: Spencer Dawkins at IETF To: "Paul E. Jones" Content-Type: multipart/alternative; boundary=001a114110be938fe30524730301 Archived-At: Cc: "gorry@erg.abdn.ac.uk" , "bfcpbis-chairs@ietf.org" , "bfcpbis@ietf.org" , Alissa Cooper , "Charles Eckel \(eckelcu\)" , "draft-ietf-bfcpbis-rfc4582bis@ietf.org" , IESG , Mary Barnes Subject: Re: [bfcpbis] Spencer Dawkins' Discuss on draft-ietf-bfcpbis-rfc4582bis-15: (with DISCUSS and COMMENT) X-BeenThere: bfcpbis@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: BFCPBIS working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 13 Nov 2015 21:48:09 -0000 --001a114110be938fe30524730301 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Thanks - and Charles' latest proposal makes me feel better about clearing. Spencer On Fri, Nov 13, 2015 at 3:44 PM, Paul E. Jones wrote: > OK, we have this and several other suggested changes from Spencer we > discussed during 94 that were agreed. > > I'll revise the text and submit a new version of the draft to include thi= s > and the other suggestions. > > Paul > > ------ Original Message ------ > From: "Charles Eckel (eckelcu)" > To: "Spencer Dawkins at IETF" > Cc: "Alissa Cooper" ; "IESG" ; " > bfcpbis-chairs@ietf.org" ; "Paul E. Jones" < > paulej@packetizer.com>; "gorry@erg.abdn.ac.uk" ; > "Mary Barnes" ; " > draft-ietf-bfcpbis-rfc4582bis@ietf.org" < > draft-ietf-bfcpbis-rfc4582bis@ietf.org>; "bfcpbis@ietf.org" < > bfcpbis@ietf.org> > Sent: 11/13/2015 4:32:17 PM > Subject: Re: [bfcpbis] Spencer Dawkins' Discuss on > draft-ietf-bfcpbis-rfc4582bis-15: (with DISCUSS and COMMENT) > > > Thanks Spencer. Based on your feedback, I have updated the proposal: > > OLD: > > =E2=80=A6 It is RECOMMENDED that TLS/DTLS with an > encryption algorithm according to Section 7 always be used. In cases > where signaling/control traffic is properly protected, as described > in Section 9 it is REQUIRED to use a mandated encryption algorithm. > BFCP entities MAY use other security mechanisms as long as they > provide similar security properties. > > NEW > > =E2=80=A6 It is RECOMMENDED that TLS/DTLS with an > encryption algorithm according to Section 7 always be used. In cases > where signaling/control traffic is properly protected, as described > in Section 9 it is REQUIRED to use a mandated encryption algorithm. > BFCP entities MAY use other security mechanisms to interwork with > legacy implementation that do not use TLS/DTLS as long as these > mechanisms provide similar security properties. An example of other > mechanisms is IPSEC to effectively secure a non-secure BFCP > connection. > > Cheers, > Charles > > > From: Spencer Dawkins at IETF > Date: Friday, November 13, 2015 at 1:15 PM > To: Charles Eckel > Cc: Alissa Cooper , IESG , " > bfcpbis-chairs@ietf.org" , Paul Jones < > paulej@packetizer.com>, "gorry@erg.abdn.ac.uk" , > Mary Barnes , " > draft-ietf-bfcpbis-rfc4582bis@ietf.org" < > draft-ietf-bfcpbis-rfc4582bis@ietf.org>, "bfcpbis@ietf.org" < > bfcpbis@ietf.org> > Subject: Re: [bfcpbis] Spencer Dawkins' Discuss on > draft-ietf-bfcpbis-rfc4582bis-15: (with DISCUSS and COMMENT) > > Hi, Charles, > > On Fri, Nov 13, 2015 at 3:07 PM, Charles Eckel (eckelcu) < > eckelcu@cisco.com> wrote: > >> >> From: Spencer Dawkins at IETF >> Date: Friday, November 13, 2015 at 12:51 PM >> To: Charles Eckel >> Cc: Alissa Cooper , IESG , " >> bfcpbis-chairs@ietf.org" , Paul Jones < >> paulej@packetizer.com>, "gorry@erg.abdn.ac.uk" , >> Mary Barnes , " >> draft-ietf-bfcpbis-rfc4582bis@ietf.org" < >> draft-ietf-bfcpbis-rfc4582bis@ietf.org>, "bfcpbis@ietf.org" < >> bfcpbis@ietf.org> >> >> Subject: Re: [bfcpbis] Spencer Dawkins' Discuss on >> draft-ietf-bfcpbis-rfc4582bis-15: (with DISCUSS and COMMENT) >> >> Hi, Charles, >> >> On Fri, Nov 13, 2015 at 1:11 PM, Charles Eckel (eckelcu) < >> eckelcu@cisco.com> wrote: >> >>> Hi Spencer, >>> >>> Please see inline. >>> >>> From: Spencer Dawkins at IETF >>> Date: Saturday, November 14, 2015 at 2:57 AM >>> To: Alissa Cooper >>> Cc: IESG , "bfcpbis-chairs@ietf.org" < >>> bfcpbis-chairs@ietf.org>, Paul Jones , " >>> gorry@erg.abdn.ac.uk" , Mary Barnes < >>> mary.ietf.barnes@gmail.com>, "draft-ietf-bfcpbis-rfc4582bis@ietf.org" < >>> draft-ietf-bfcpbis-rfc4582bis@ietf.org>, "bfcpbis@ietf.org" < >>> bfcpbis@ietf.org>, Charles Eckel >>> >>> Subject: Re: [bfcpbis] Spencer Dawkins' Discuss on >>> draft-ietf-bfcpbis-rfc4582bis-15: (with DISCUSS and COMMENT) >>> >>> So, we're getting there. >>> >>> On Wed, Nov 11, 2015 at 4:38 PM, Alissa Cooper >>> wrote: >>> >>>> Hi Spencer, >>>> >>>> Does Charles=E2=80=99 proposal below work for you? >>>> >>>> Thanks, >>>> Alissa >>>> >>>> On Nov 5, 2015, at 3:42 PM, Charles Eckel (eckelcu) >>>> wrote: >>>> >>>> >>>> From: Spencer Dawkins at IETF >>>> Date: Friday, November 6, 2015 at 7:23 AM >>>> To: Alissa Cooper >>>> Cc: "iesg@ietf.org" , "bfcpbis-chairs@ietf.org" < >>>> bfcpbis-chairs@ietf.org>, Paul Jones , " >>>> gorry@erg.abdn.ac.uk" , Mary Barnes < >>>> mary.ietf.barnes@gmail.com>, "draft-ietf-bfcpbis-rfc4582bis@ietf.org" = < >>>> draft-ietf-bfcpbis-rfc4582bis@ietf.org>, "bfcpbis@ietf.org" < >>>> bfcpbis@ietf.org>, Charles Eckel >>>> Subject: Re: [bfcpbis] Spencer Dawkins' Discuss on >>>> draft-ietf-bfcpbis-rfc4582bis-15: (with DISCUSS and COMMENT) >>>> >>>> Hi, Alissa, >>>> On Nov 6, 2015 7:06 AM, "Alissa Cooper" wrote: >>>> > >>>> > Hi Spencer, >>>> > >>>> > >>>> > >>>> > On Nov 5, 2015, at 11:20 PM, Spencer Dawkins at IETF < >>>> spencerdawkins.ietf@gmail.com> wrote: >>>> > >>>> >> Hi, Charles, >>>> >> >>>> >> On Thu, Nov 5, 2015 at 5:43 PM, Charles Eckel (eckelcu) < >>>> eckelcu@cisco.com> wrote: >>>> >>> >>>> >>> For TCP, the use of TLS was not required by RFC 4582. For 4582bis, >>>> we do not require TLS in order to maintain backward compatibility with= RFC >>>> 4582. >>>> >> >>>> >> >>>> >> Got it. I'm holding my nose on this one, based on backward >>>> compatibility, and given the degree of difficulty in splicing attack >>>> packets into the TCP sequence numbering space if you're off-path. I'm = not >>>> thrilled, but someone else needs to decide when threats reach the leve= l >>>> where making that incompatible change is necessary - and that might no= t be >>>> the right thing to do today. >>>> >> >>>> >>> >>>> >>> For UDP, the reason for not mandating DTLS is backward >>>> compatibility with existing solutions. The IMTC Role Based Video Best >>>> Practice established a set of recommendations for getting BFCP to work >>>> within enterprise video conference deployments. As that >>>> time,draft-sandbakken-xcon-bfcp-udp defined BFCP over UDP only. DTLS w= as >>>> left for future study. Today we have many implementations of BFCP over= UDP, >>>> but few if any using DTLS. We need the ultimate RFC that standardizes = BFCP >>>> over UDP (and over DTLS) to allow interworking with these existing >>>> deployments. >>>> >> >>>> >> >>>> >> OK, I'm not the Protocol Security Police, so, fine, but it seems >>>> like the draft could be clearer about this, and what you said in your >>>> answer would be really helpful in the document. >>>> >> >>>> >> If the text said something like "DTLS is REQUIRED unless you are >>>> interworking with a pre-standardization deployment that is already ins= ecure, >>>> > >>>> > >>>> > "REQUIRED unless" strikes me as a faulty construction. That case is >>>> what RECOMMENDED is for, when there is a known exception to the requir= ement. >>>> That usage is certainly more common in some parts of the IETF than >>>> others, but it does get used. But ignoring that. >>>> Do you think "RECOMMENDED unless you are interworking with a >>>> pre-standardization deployment that is already insecure" is tight enou= gh? >>>> The reason I'm asking, is that offpath attacks on UDP-based protocols >>>> are a lot easier than TCP-based protocols, and if the IETF is going to >>>> publish a proposed standard with a known deficiency to accommodate >>>> pre-standardization deployments, I'd prefer that the guidance about us= ing >>>> that accommodation be as clear as possible. >>>> >>>> >>>> I agree with your intent. My concern with calling out exceptions is >>>> that it can make the existing recommendation in the draft seem weaker.= How >>>> about this: >>>> >>>> OLD: >>>> >>>> =E2=80=A6 It is RECOMMENDED that TLS/DTLS with an >>>> encryption algorithm according to Section 7 always be used. In cas= es >>>> where signaling/control traffic is properly protected, as described >>>> in Section 9 it is REQUIRED to use a mandated encryption algorithm. >>>> BFCP entities MAY use other security mechanisms as long as they >>>> provide similar security properties. >>>> >>>> NEW >>>> >>>> =E2=80=A6 It is RECOMMENDED that TLS/DTLS with an >>>> encryption algorithm according to Section 7 always be used. In cas= es >>>> where signaling/control traffic is properly protected, as described >>>> in Section 9 it is REQUIRED to use a mandated encryption algorithm. >>>> BFCP entities MAY use other security mechanisms to interwork with >>>> legacy implementation that do not use TLS/DTLS as long as these >>>> mechanisms provide similar security properties. >>>> >>>> >>> Probably for Charles: >>> >>> This last sentence seems to be responsible for most of my remaining >>> heartburn. >>> >>> My understanding was that TLS and (especially) DTLS were RECOMMENDED, >>> not REQUIRED, because there are legacy implementations that have been >>> deployed already. I can live with that, but is it obvious to everyone h= ow a >>> legacy receiver tells a sender to use a non-TLS/DTLS mechanism? I'm loo= king >>> at the "use TLS" and "use DTLS" error codes in Table 5, and wondering w= here >>> the "use legacy security mechanism" error code might be. >>> >>> Do legacy endpoints "just know" this? >>> >>> >>> This draft describes how to use SDP to establish a BFCP connection. The >>> determination of whether to use TLS or TCP or DTLS or UDP is based on t= he >>> SDP offer/answer and the specification within it of the m-line, e.g. >>> >>> m=3Dapplication 50000 UDP/BFCP * >>> >>> m=3Dapplication 50000 TCP/BFCP * >>> >>> m=3Dapplication 50000 TCP/TLS/BFCP * >>> >>> m=3Dapplication 50000 UDP/TLS/BFCP * >>> >>> When making the offer, an implementation has a choice of using any of >>> these and the answerer can choose to accept of reject. Some very >>> implementations supported TCP only. Most current implementations suppor= t >>> UDP only or in addition to TCP. In the future, we hope all with support >>> DTLS. Typically implementation the support more than one transport prov= ide >>> configuration options, such as require DTLS, or offer DTLS but accept U= DP >>> or DTLS, or offer DTLS first and if rejected offer UDP. The current IMT= C >>> best practice recommends offering UDP and if that fails offer TCP. This >>> will be updated to include DTLS once RFC4583bis is published. >>> >> >> This all makes perfect sense to me. I'm not understanding how legacy >> implementations offering "UDP only" maps onto "other mechanisms that >> provide similar security properties" in the proposed text. >> >> Is "other mechanisms that provide similar security properties" even >> talking about the same thing? >> >> And thanks for the quick follow-up. >> >> >> Likewise. An example of other mechanisms is IPSEC and having a UDP based >> BFCP connection within it. >> > > OK, so you're talking about security mechanisms that aren't under > application control at all then. I love those :D > > I'll clear, but I think the document might be clearer if you said that > (even as an example). > > Thanks, > > Spencer > > >> Cheers, >> Charles >> >> >> Spencer >> >> >>> Cheers, >>> Charles >>> >>> Thanks, >>> >>> Spencer >>> >>> >>>> Cheers, >>>> Charles >>>> >>>> >>>> >>>> Thanks, >>>> Spencer >>>> > Alissa >>>> > >>>> >> in which case you're not making things worse by running without >>>> transport-level security", that would capture my concern and reflect w= hat >>>> you're saying, unless I'm missing something. >>>> >> >>>> >> Thanks to you and Paul for the speedy response on the evening of >>>> Bits and Bites! >>>> >> >>>> >> Spencer >>>> >> >>>> >> _______________________________________________ >>>> >> >>>> >> bfcpbis mailing list >>>> >>mailto:bfcpbis@ietf.org >>>> >> https://www.ietf.org/mailman/listinfo/bfcpbis >>>> >>>> >>>> >>> >> > --001a114110be938fe30524730301 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Thanks - and Charles' latest proposal makes me feel be= tter about clearing.

Spencer

On Fri, Nov 13, 2015 at 3:44 PM, = Paul E. Jones <paulej@packetizer.com> wrote:
OK, we have this and several other suggested changes from Spencer we d= iscussed during 94 that were=C2=A0agreed.=C2=A0
=C2=A0
I'll revise the text and submit a new version of the draft to incl= ude this and the other suggestions.
=C2=A0
Paul
=
Thanks Spencer. Based on your feedback, I have updated the proposal:

OLD:

=C2=A0 =C2=A0=E2=80=A6 It is RECOMME= NDED that TLS/DTLS with an
=C2=A0 =C2=A0encryption algorithm ac= cording to Section 7 always be used.=C2=A0 In cases
=C2=A0 =C2=A0where signaling/control= traffic is properly protected, as described
=C2=A0 =C2=A0in Section 9 it is REQU= IRED to use a mandated encryption algorithm.
=C2=A0 =C2=A0BFCP entities MAY use o= ther security mechanisms as long as they
=C2=A0 =C2=A0provide similar securit= y properties.

NEW

=C2=A0 =C2=A0=E2=80=A6 It is RECOMME= NDED that TLS/DTLS with an
=C2=A0 =C2=A0encryption algorithm ac= cording to Section 7 always be used.=C2=A0 In cases
=C2=A0 =C2=A0where signaling/control= traffic is properly protected, as described
=C2=A0 =C2=A0in Section 9 it is REQU= IRED to use a mandated encryption algorithm.
=C2=A0 =C2=A0BFCP entities MAY use o= ther security mechanisms to interwork with=C2=A0
=C2=A0 =C2=A0legacy implementation t= hat do not use TLS/DTLS as long as these=C2=A0
=C2=A0 =C2=A0mechanisms provide simi= lar security properties.=C2=A0An example of other=C2=A0
=C2=A0 =C2=A0mechanisms is IPSEC to = effectively secure a non-secure BFCP=C2=A0
=C2=A0 =C2=A0connection.

Cheers,
Charles


From: Sp= encer Dawkins at IETF <spencerdawkins.ietf@gmail.com>
Date: Friday, November 13, 2015 at 1:15 PM
To: Charles Eckel <eckelcu@cisco.com>
Cc: Alissa Cooper <alissa@cooperw.in>, IESG <iesg@ietf.org>, "<= a href=3D"mailto:bfcpbis-chairs@ietf.org" target=3D"_blank">bfcpbis-chairs@= ietf.org" <bfcpbis-chairs@ietf.org>, Paul Jones <paulej@packetizer.com>, &qu= ot;gorry@erg.abdn= .ac.uk" <gorry@erg.abdn.ac.uk>, Mary Barnes <mary.ietf.barnes@gmail.com>, = "draft-ietf-bfcpbis-rfc4582bis@ietf.org" <draft-ietf-bfc= pbis-rfc4582bis@ietf.org>, "bfcpbis@ietf.org" <bfcpbis@ietf.org>
Subject: Re: [bfcpbis] Spencer Dawkins' Discuss o= n draft-ietf-bfcpbis-rfc4582bis-15: (with DISCUSS and COMMENT)

Hi, Charles,=20

On Fri, Nov 13, 2015 at 3= :07 PM, Charles Eckel (eckelcu) <eckelcu@cisco.com> wrote:

From: Spencer Dawkins at IETF <spencerdawkins.ietf@gmail.com>
Date: Friday, November 13, 2015 at 12:= 51 PM
To: Charles Eckel <eckelcu@cisco.com>= ;
Cc: Alissa Cooper <alissa@cooperw.in>, = IESG <iesg@ietf.org>, "= bfcpbis-chairs@ietf.org" <bfcpbis-chairs@ietf.org>, Paul Jones <paulej@packetizer.c= om>, "gorry@erg.abdn.ac.uk" <gorry@erg.abdn.ac.uk>, Mary Barnes <mary.ietf.barnes@gmai= l.com>, "draft-ietf-bfcpbis-rfc4582bis@ietf.org" <= draft-ietf-bfcpbis-rfc4582bis@ietf.org>, "bfcpbis@ietf.org" <bfcpbis@ietf.org>=20

Subject: Re: [bfcpbis] Spe= ncer Dawkins' Discuss on draft-ietf-bfcpbis-rfc4582bis-15: (with DISCUS= S and COMMENT)

Hi, Charles,=20

On Fri, Nov 13, 2015 at 1:11 PM, Charles Eckel (= eckelcu) <eckelcu@cisco.com> wrote:
Hi Spencer,

Please see inline.

From: Spencer Dawkins at IETF <spencerdawkins.ietf@gmail.com>
Date: Saturday, November 14, 2015 at 2= :57 AM
To: Alissa Cooper <alissa@cooperw.in&g= t;
Cc: IESG <iesg@ietf.org>, "bfcpbis-chairs@ietf.org" <b= fcpbis-chairs@ietf.org>, Paul Jones <paulej@packetizer.com>, "gorry@erg.abdn.ac.uk= " <gorry@= erg.abdn.ac.uk>, Mary Barnes <mary.ietf.barnes@gmail.com>, "dra= ft-ietf-bfcpbis-rfc4582bis@ietf.org" <draft-ietf-bfcpbis-rfc45= 82bis@ietf.org>, "bfcpbis@ietf.org" <bfcpbis@ietf.org>, Charles Eckel <eckelcu@cisco.com>=20

Subject: Re: [bfcpbis] Spe= ncer Dawkins' Discuss on draft-ietf-bfcpbis-rfc4582bis-15: (with DISCUS= S and COMMENT)

So, we're getting there.=20

On Wed, Nov 11, 2015 at 4:38 PM, Alissa Cooper <= span dir=3D"ltr"><alissa@cooperw.in> wrote:
Hi Spencer,

Does Charles=E2=80=99 proposal below work for you?

Thanks,
Alissa

On Nov 5, 2015, at 3:42 PM, Charles Eckel (eckelcu) <eckelcu@cisco.com> wrote:

From: Spenc= er Dawkins at IETF <spencerdawkins.ietf@gmail.com>
Date: Friday, November 6, 2015 at 7:23 AM
To: Alissa Cooper <alissa@cooperw.in>
Cc: "iesg@ietf.org" <iesg@ietf.org>, "bfcpbis-chairs@ietf.org" <bfcpbis-chairs@ie= tf.org>, Paul Jones <paulej@packetizer.com>, "gorry@erg.abdn.ac.uk" <gorry@erg.abdn.ac.uk>, Mary Barnes <mary.ietf.barnes@gmail.com>, "draft-ietf-bfcpbis-= rfc4582bis@ietf.org" <draft-ietf-bfcpbis-rfc4582bis@ietf.org>, "bfcpbis= @ietf.org" <bfcpbis@ietf.org>, Charles Eckel <eckelcu@cisco.com>
Subject: Re: [bfcpbis] Spencer Dawkins' Discuss on= draft-ietf-bfcpbis-rfc4582bis-15: (with DISCUSS and COMMENT)

Hi, Alissa,
On Nov 6, 2015 7:06 AM, "Alissa Cooper" <alissa@cooperw.in>= ; wrote:
>
> Hi Spencer,
>
>
>
> On Nov= 5, 2015, at 11:20 PM, Spencer Dawkins at IETF <spencerdawkins.ietf@gmail.com> wrote:
>
>> Hi, Charles,
>>
>> On Th= u, Nov 5, 2015 at 5:43 PM, Charles Eckel (eckelcu) <eckelcu@cisco.com> wrote:
>= >>
>>> For TCP, the use of TLS was not required by RFC 45= 82. For 4582bis, we do not require TLS in order to maintain backward compat= ibility with RFC 4582.
>>
>>
>> Got it. I'm = holding my nose on this one, based on backward compatibility, and given the= degree of difficulty in splicing attack packets into the TCP sequence numb= ering space if you're off-path. I'm not thrilled, but someone else = needs to decide when threats reach the level where making that incompatible= change is necessary - and that might not be the right thing to do today.>> =C2=A0
>>>
>>> For UDP, the reason for n= ot mandating DTLS is backward compatibility with existing solutions. The IM= TC Role Based Video Best Practice established a set of recommendations for = getting BFCP to work =C2=A0within enterprise video conference deployments. = As that time,draft-sandbakken-xcon-bfcp-udp=C2=A0defined BFCP over UDP only= . DTLS was left for future study. Today we have many implementations of BFC= P over UDP, but few if any using DTLS. We need the ultimate RFC that standa= rdizes BFCP over UDP (and over DTLS) to allow interworking with these exist= ing deployments.
>>
>>
>> OK, I'm not the Pr= otocol Security Police, so, fine, but it seems like the draft could be clea= rer about this, and what you said in your answer would be really helpful in= the document.=C2=A0
>>
>> If the text said something lik= e "DTLS is REQUIRED unless you are interworking with a pre-standardiza= tion deployment that is already insecure,
>
>
> "REQ= UIRED unless" strikes me as a faulty construction. That case is what R= ECOMMENDED is for, when there is a known exception to the requirement.
That usage is certainly more common in some parts of the I= ETF than others, but it does get used. But ignoring that.
Do you think "RECOMMENDED unless you are interworking= with a pre-standardization deployment that is already insecure" is ti= ght enough?
The reason I'm asking, is that offpath attacks on UDP-= based protocols are a lot easier than TCP-based protocols, and if the IETF = is going to publish a proposed standard with a known deficiency to accommod= ate pre-standardization deployments, I'd prefer that the guidance about= using that accommodation be as clear as possible.

I agree with y= our intent. My concern with calling out exceptions is that it can make the = existing recommendation in the draft seem weaker. How about this:

OLD:

=C2=A0 =C2=A0=E2=80=A6 It is RECOMMENDED that TLS/DTLS with an<= /div>
=C2=A0 =C2=A0encryption algorithm ac= cording to Section 7 always be used.=C2=A0 In cases
=C2=A0 =C2=A0where signaling/control= traffic is properly protected, as described
=C2=A0 =C2=A0in Section 9 it is REQU= IRED to use a mandated encryption algorithm.
=C2=A0 =C2=A0BFCP entities MAY use o= ther security mechanisms as long as they
=C2=A0 =C2=A0provide similar securit= y properties.

NEW

=C2=A0 =C2=A0=E2=80=A6 It= is RECOMMENDED that TLS/DTLS with an
=C2=A0 =C2=A0encryption algorithm according to Section 7 always be= used.=C2=A0 In cases
=C2=A0 =C2=A0where signaling/control traffic is properly protected= , as described
=C2=A0 =C2=A0in Section 9 it is REQUIRED to use a mandated encrypt= ion algorithm.
=C2=A0 =C2=A0BFCP entities MAY use other security mechanisms to in= terwork with=C2=A0
=C2=A0 =C2=A0legacy implementation that do not use TLS/DTLS as lon= g as these=C2=A0
=C2=A0 =C2=A0mechanisms=C2=A0provide similar security properties.=C2=A0

Probably for Charles:

This last sentence seems to be responsible for most of my remaining he= artburn.=C2=A0

My understanding was that TLS and (especially) DTLS were RECOMMENDED, = not REQUIRED, because there are legacy implementations that have been deplo= yed already. I can live with that, but is it obvious to everyone how a lega= cy receiver tells a sender to use a non-TLS/DTLS mechanism? I'm looking= at the "use TLS" and "use DTLS" error codes in Table 5= , and wondering where the "use legacy security mechanism" error c= ode might be.=C2=A0

Do legacy endpoints "just know" this?

This draft des= cribes how to use SDP to establish a BFCP connection. The determination of = whether to use TLS or TCP or DTLS or UDP is based on the SDP offer/answer a= nd the specification within it of the m-line, e.g.

m=3Dapplication = 50000 UDP/BFCP *

m=3Dapplication 50000 TCP/BFCP *

m=3Dapplication 50000 TCP/TLS= /BFCP *

m=3Dapplication 50000 UDP/TLS= /BFCP *


When making the offer, an implementation has a choice of using any of = these and the answerer can choose to accept of reject. Some very implementa= tions supported TCP only. Most current implementations support UDP only or = in addition to TCP. In the future, we hope all with support DTLS. Typically= implementation the support more than one transport provide configuration o= ptions, such as require DTLS, or offer DTLS but accept UDP or DTLS, or offe= r DTLS first and if rejected offer UDP. The current IMTC best practice reco= mmends offering UDP and if that fails offer TCP. This will be updated to in= clude DTLS once RFC4583bis is published. =C2=A0

This all makes perfect sense to me. I'm not understanding how lega= cy implementations offering "UDP only" maps onto "other mech= anisms that provide similar security properties" in the proposed text.= =C2=A0

Is "other mechanisms that provide similar security properties&quo= t; even talking about the same thing?

And thanks for the quick follow-up.

Likewise. An example of other mechanisms is IPSEC and having a UDP bas= ed BFCP =C2=A0connection within it.

OK, so you're talking about security mechanisms that aren't un= der application control at all then. I love those :D

I'll clear, but I think the document might be clearer if you said = that (even as an example).

Thanks,

Spencer
=C2=A0
Cheers,
Charles


Spencer
=C2=A0
Cheers,
Charles

Thanks,

Spencer
=C2=A0
Cheers,
Charles
=C2=A0

Thanks,
Spencer
> Alissa
>
>> in = which case you're not making things worse by running without transport-= level security", that would capture my concern and reflect what you= 9;re saying, unless I'm missing something.
>>
>> Than= ks to you and Paul for the speedy response on the evening of Bits and Bites= !
>>
>> Spencer
>>
>> _________________= ______________________________
>>
>> bfcpbis mailing list=
>>mailto:bfcpbis@ietf.org
>> https://www.ietf.org/mailman/li= stinfo/bfcpbis





--001a114110be938fe30524730301-- From nobody Fri Nov 13 17:40:13 2015 Return-Path: X-Original-To: bfcpbis@ietf.org Delivered-To: bfcpbis@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 59FFB1A9152; Fri, 13 Nov 2015 17:40:11 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: X-Test-IDTracker: no X-IETF-IDTracker: 6.9.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20151114014011.31111.35465.idtracker@ietfa.amsl.com> Date: Fri, 13 Nov 2015 17:40:11 -0800 Archived-At: Cc: bfcpbis@ietf.org Subject: [bfcpbis] I-D Action: draft-ietf-bfcpbis-rfc4582bis-16.txt X-BeenThere: bfcpbis@ietf.org X-Mailman-Version: 2.1.15 List-Id: BFCPBIS working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 14 Nov 2015 01:40:11 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Binary Floor Control Protocol Bis Working Group of the IETF. Title : The Binary Floor Control Protocol (BFCP) Authors : Gonzalo Camarillo Keith Drage Tom Kristensen Joerg Ott Charles Eckel Filename : draft-ietf-bfcpbis-rfc4582bis-16.txt Pages : 90 Date : 2015-11-13 Abstract: Floor control is a means to manage joint or exclusive access to shared resources in a (multiparty) conferencing environment. Thereby, floor control complements other functions -- such as conference and media session setup, conference policy manipulation, and media control -- that are realized by other protocols. This document specifies the Binary Floor Control Protocol (BFCP). BFCP is used between floor participants and floor control servers, and between floor chairs (i.e., moderators) and floor control servers. This document obsoletes RFC 4582. Changes from RFC 4582 are summarized in Section 16. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-bfcpbis-rfc4582bis/ There's also a htmlized version available at: https://tools.ietf.org/html/draft-ietf-bfcpbis-rfc4582bis-16 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-bfcpbis-rfc4582bis-16 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Fri Nov 13 20:42:31 2015 Return-Path: X-Original-To: bfcpbis@ietfa.amsl.com Delivered-To: bfcpbis@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6CF6B1B3890 for ; Fri, 13 Nov 2015 20:42:30 -0800 (PST) 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 YC0c1ul3Sf3L for ; Fri, 13 Nov 2015 20:42:29 -0800 (PST) Received: from alln-iport-6.cisco.com (alln-iport-6.cisco.com [173.37.142.93]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BDAA71B388C for ; Fri, 13 Nov 2015 20:42:28 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=5186; q=dns/txt; s=iport; t=1447476148; x=1448685748; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=XFWxgWjhwOW5ISY1L4M6PtWy+sCDVl85sNZNANlzC90=; b=T/JiTwKkjYlQsQFF+8csIT2yaYaAFjdojALU7besCylOgFoqmoSwgP4T PYGOr8fm0RxFwu+SNNBSTIFvYA/7lyKTvhJqBZQtmRXQ0Am5PdHwZR4Wb PHijSB8M+bAG9dFv8HPG95Y5FO9GXYnn/atrWhJrmgQ71aqT19G0YVeIA M=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0DjAwDyukZW/49dJa1egztTbwaEI7oiA?= =?us-ascii?q?Q2BZBcKhSVKAhyBGzgUAQEBAQEBAYEKhDQBAQEDAQEBASAROgsMBAIBCBEDAQI?= =?us-ascii?q?BAgImAgICJQsVCAgCBAENBYgmCA2vV5A+AQEBAQEBAQEBAQEBAQEBAQEBAQEBG?= =?us-ascii?q?IEBhVSEfYRxgwSBRAWWSAGFHIgKgVtJg3eWKQEfAQFChARyhDaBBwEBAQ?= X-IronPort-AV: E=Sophos;i="5.20,291,1444694400"; d="scan'208";a="208084481" Received: from rcdn-core-7.cisco.com ([173.37.93.143]) by alln-iport-6.cisco.com with ESMTP; 14 Nov 2015 04:42:27 +0000 Received: from XCH-RTP-009.cisco.com (xch-rtp-009.cisco.com [64.101.220.149]) by rcdn-core-7.cisco.com (8.14.5/8.14.5) with ESMTP id tAE4gR0d022117 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Sat, 14 Nov 2015 04:42:27 GMT Received: from xch-rtp-017.cisco.com (64.101.220.157) by XCH-RTP-009.cisco.com (64.101.220.149) with Microsoft SMTP Server (TLS) id 15.0.1104.5; Fri, 13 Nov 2015 23:42:26 -0500 Received: from xch-rtp-017.cisco.com ([64.101.220.157]) by XCH-RTP-017.cisco.com ([64.101.220.157]) with mapi id 15.00.1104.000; Fri, 13 Nov 2015 23:42:26 -0500 From: "Ram Mohan R (rmohanr)" To: "Charles Eckel (eckelcu)" , "Gonzalo Salgueiro (gsalguei)" , "bfcpbis@ietf.org" , "christer.holmberg@ericsson.com" Thread-Topic: [bfcpbis] I-D Action: draft-ietf-bfcpbis-bfcp-websocket-05.txt Thread-Index: AQHRBdZWO9iZLlEWGU6Llb7iQs5Gsp5p+f6AgDDU0gCAAQRdgA== Date: Sat, 14 Nov 2015 04:42:26 +0000 Message-ID: References: <20151013164348.9920.89287.idtracker@ietfa.amsl.com> <6D74D935-2204-49AD-9CDA-D432A74BD477@cisco.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.5.7.151005 x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.65.75.187] Content-Type: text/plain; charset="utf-8" Content-ID: <8A39148B4796004A95DEE7C140023351@emea.cisco.com> Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: Cc: "bfcpbis-chairs@tools.ietf.org" Subject: Re: [bfcpbis] I-D Action: draft-ietf-bfcpbis-bfcp-websocket-05.txt X-BeenThere: bfcpbis@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: BFCPBIS working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 14 Nov 2015 04:42:30 -0000 SGkgQ2hhcmxlcywNCg0KSSB3aWxsIGdldCBiYWNrIHdpdGggcmVzcG9uc2VzIGFuZCB1cGRhdGVk IGRpZmZzIHRvDQpkcmFmdC1yYW0tYmZjcGJpcy1zZHAtd3MtdXJpIHNvb24uIEkgYWdyZWUgdGhh dCB3ZSBzaG91bGQgd2FpdCB0aWxsIHRoaXMNCmlzIHJlc29sdmVkIGJlZm9yZSBsb29raW5nIHRv IHN0YXJ0IFdHTEMuDQoNClJlZ2FyZHMsDQpSYW0NCg0KLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0t LS0NCkZyb206ICJDaGFybGVzIEVja2VsIChlY2tlbGN1KSIgPGVja2VsY3VAY2lzY28uY29tPg0K RGF0ZTogU2F0dXJkYXksIDE0IE5vdmVtYmVyIDIwMTUgMTI6MTQgYW0NClRvOiAiR29uemFsbyBT YWxndWVpcm8gKGdzYWxndWVpKSIgPGdzYWxndWVpQGNpc2NvLmNvbT4sDQoiYmZjcGJpc0BpZXRm Lm9yZyIgPGJmY3BiaXNAaWV0Zi5vcmc+LCAiY2hyaXN0ZXIuaG9sbWJlcmdAZXJpY3Nzb24uY29t Ig0KPGNocmlzdGVyLmhvbG1iZXJnQGVyaWNzc29uLmNvbT4NCkNjOiAiYmZjcGJpcy1jaGFpcnNA dG9vbHMuaWV0Zi5vcmciIDxiZmNwYmlzLWNoYWlyc0B0b29scy5pZXRmLm9yZz4sIENpc2NvDQpF bXBsb3llZSA8cm1vaGFuckBjaXNjby5jb20+DQpTdWJqZWN0OiBSZTogW2JmY3BiaXNdIEktRCBB Y3Rpb246IGRyYWZ0LWlldGYtYmZjcGJpcy1iZmNwLXdlYnNvY2tldC0wNS50eHQNCg0KPkNocmlz dGVyIHJldmlld2VkIGRyYWZ0LXJhbS1iZmNwYmlzLXNkcC13cy11cmkgYW5kIHJlY29tbWVuZGVk IHN1YnN0YW50aWFsDQo+Y2hhbmdlcyB0byBpdC4gVGhlIGF1dGhvcnMgaGF2ZSBub3QgeWV0IHJl c3BvbmRlZCB0byB0aGF0Lg0KPg0KPlJlZ2FyZGluZyBkcmFmdC1pZXRmLWJmY3BiaXMtYmZjcC13 ZWJzb2NrZXQsIEnCuWQgbGlrZSB0byBzZWUgdGhpcyByZXNwb25zZQ0KPmFuZCBwb3RlbnRpYWwg aW1wYWN0cyBvbiBlaXRoZXIvYm90aCBkcmFmdHMgYmVmb3JlIHN0YXJ0aW5nIFdHTEMgZm9yDQo+ ZHJhZnQtaWV0Zi1iZmNwYmlzLWJmY3Atd2Vic29ja2V0Lg0KPg0KPg0KPkNoZWVycywNCj5DaGFy bGVzDQo+DQo+T24gMTAvMTMvMTUsIDEwOjAyIEFNLCAiYmZjcGJpcyBvbiBiZWhhbGYgb2YgR29u emFsbyBTYWxndWVpcm8gKGdzYWxndWVpKSINCj48YmZjcGJpcy1ib3VuY2VzQGlldGYub3JnIG9u IGJlaGFsZiBvZiBnc2FsZ3VlaUBjaXNjby5jb20+IHdyb3RlOg0KPg0KPj5OZXcgdmVyc2lvbiBv ZiB0aGUgZHJhZnQgaGFzIGJlZW4gcHVibGlzaGVkIGFuZCBhZGRyZXNzZXMgYWxsIG9wZW4NCj4+ Y29tbWVudHMgcmFpc2VkIGJ5IENocmlzdGVyLiAgQXQgdGhpcyBwb2ludCBhdXRob3JzIGZlZWwg dGhpcyBpcyByZWFkeQ0KPj5mb3IgV0dMQy4NCj4+DQo+PlRoZXJlIGlzIGEgcGVuZGluZyByZXF1 ZXN0IGZvciBDaHJpc3RlciB0byByZXZpZXcgdGhlIGNvbXBsZW1lbnRhcnkgZHJhZnQNCj4+aGUg cmVxdWVzdGVkDQo+PihkcmFmdC1yYW0tYmZjcGJpcy1zZHAtd3MtdXJpLTAwKSBiZSBzcGxpdCBv ZmYgZnJvbSB0aGUgb3JpZ2luYWwNCj4+ZG9jdW1lbnQuIE9uY2UgdGhpcyBpcyBkb25lLCB3ZSBh c2sgdGhlIGNoYWlycyBmb3IgZ3VpZGFuY2Ugb24gaG93IGJlc3QNCj4+dG8gcHJvZ3Jlc3MgdGhp cyBzcGluLW9mZiBkcmFmdC4NCj4+DQo+PlRoYW5rcywNCj4+DQo+PkdvbnphbG8NCj4+DQo+Pj4g T24gT2N0IDEzLCAyMDE1LCBhdCAxMjo0MyBQTSwgaW50ZXJuZXQtZHJhZnRzQGlldGYub3JnIHdy b3RlOg0KPj4+IA0KPj4+IA0KPj4+IEEgTmV3IEludGVybmV0LURyYWZ0IGlzIGF2YWlsYWJsZSBm cm9tIHRoZSBvbi1saW5lIEludGVybmV0LURyYWZ0cw0KPj4+ZGlyZWN0b3JpZXMuDQo+Pj4gVGhp cyBkcmFmdCBpcyBhIHdvcmsgaXRlbSBvZiB0aGUgQmluYXJ5IEZsb29yIENvbnRyb2wgUHJvdG9j b2wgQmlzDQo+Pj5Xb3JraW5nIEdyb3VwIG9mIHRoZSBJRVRGLg0KPj4+IA0KPj4+ICAgICAgICBU aXRsZSAgICAgICAgICAgOiBUaGUgV2ViU29ja2V0IFByb3RvY29sIGFzIGEgVHJhbnNwb3J0IGZv ciB0aGUNCj4+PkJpbmFyeSBGbG9vciBDb250cm9sIFByb3RvY29sIChCRkNQKQ0KPj4+ICAgICAg ICBBdXRob3JzICAgICAgICAgOiBWaWN0b3IgUGFzY3VhbA0KPj4+ICAgICAgICAgICAgICAgICAg ICAgICAgICBBbnTDs24gUm9tw6FuDQo+Pj4gICAgICAgICAgICAgICAgICAgICAgICAgIFN0w6lw aGFuZSBDYXplYXV4DQo+Pj4gICAgICAgICAgICAgICAgICAgICAgICAgIEdvbnphbG8gU2FsZ3Vl aXJvDQo+Pj4gICAgICAgICAgICAgICAgICAgICAgICAgIFJhbSBNb2hhbiBSYXZpbmRyYW5hdGgN Cj4+PiAgICAgICAgICAgICAgICAgICAgICAgICAgU2VyZ2lvIEdhcmNpYSBNdXJpbGxvDQo+Pj4g CUZpbGVuYW1lICAgICAgICA6IGRyYWZ0LWlldGYtYmZjcGJpcy1iZmNwLXdlYnNvY2tldC0wNS50 eHQNCj4+PiAJUGFnZXMgICAgICAgICAgIDogMTQNCj4+PiAJRGF0ZSAgICAgICAgICAgIDogMjAx NS0xMC0xMw0KPj4+IA0KPj4+IEFic3RyYWN0Og0KPj4+ICAgVGhlIFdlYlNvY2tldCBwcm90b2Nv bCBlbmFibGVzIHR3by13YXkgcmVhbHRpbWUgY29tbXVuaWNhdGlvbiBiZXR3ZWVuDQo+Pj4gICBj bGllbnRzIGFuZCBzZXJ2ZXJzLiAgVGhpcyBkb2N1bWVudCBzcGVjaWZpZXMgYSBuZXcgV2ViU29j a2V0IHN1Yi0NCj4+PiAgIHByb3RvY29sIGFzIGEgcmVsaWFibGUgdHJhbnNwb3J0IG1lY2hhbmlz bSBiZXR3ZWVuIEJpbmFyeSBGbG9vcg0KPj4+ICAgQ29udHJvbCBQcm90b2NvbCAoQkZDUCkgZW50 aXRpZXMgdG8gZW5hYmxlIHVzYWdlIG9mIEJGQ1AgaW4gbmV3DQo+Pj4gICBzY2VuYXJpb3MuDQo+ Pj4gDQo+Pj4gDQo+Pj4gVGhlIElFVEYgZGF0YXRyYWNrZXIgc3RhdHVzIHBhZ2UgZm9yIHRoaXMg ZHJhZnQgaXM6DQo+Pj4gaHR0cHM6Ly9kYXRhdHJhY2tlci5pZXRmLm9yZy9kb2MvZHJhZnQtaWV0 Zi1iZmNwYmlzLWJmY3Atd2Vic29ja2V0Lw0KPj4+IA0KPj4+IFRoZXJlJ3MgYWxzbyBhIGh0bWxp emVkIHZlcnNpb24gYXZhaWxhYmxlIGF0Og0KPj4+IGh0dHBzOi8vdG9vbHMuaWV0Zi5vcmcvaHRt bC9kcmFmdC1pZXRmLWJmY3BiaXMtYmZjcC13ZWJzb2NrZXQtMDUNCj4+PiANCj4+PiBBIGRpZmYg ZnJvbSB0aGUgcHJldmlvdXMgdmVyc2lvbiBpcyBhdmFpbGFibGUgYXQ6DQo+Pj4gaHR0cHM6Ly93 d3cuaWV0Zi5vcmcvcmZjZGlmZj91cmwyPWRyYWZ0LWlldGYtYmZjcGJpcy1iZmNwLXdlYnNvY2tl dC0wNQ0KPj4+IA0KPj4+IA0KPj4+IFBsZWFzZSBub3RlIHRoYXQgaXQgbWF5IHRha2UgYSBjb3Vw bGUgb2YgbWludXRlcyBmcm9tIHRoZSB0aW1lIG9mDQo+Pj5zdWJtaXNzaW9uDQo+Pj4gdW50aWwg dGhlIGh0bWxpemVkIHZlcnNpb24gYW5kIGRpZmYgYXJlIGF2YWlsYWJsZSBhdCB0b29scy5pZXRm Lm9yZy4NCj4+PiANCj4+PiBJbnRlcm5ldC1EcmFmdHMgYXJlIGFsc28gYXZhaWxhYmxlIGJ5IGFu b255bW91cyBGVFAgYXQ6DQo+Pj4gZnRwOi8vZnRwLmlldGYub3JnL2ludGVybmV0LWRyYWZ0cy8N Cj4+PiANCj4+PiBfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f Xw0KPj4+IGJmY3BiaXMgbWFpbGluZyBsaXN0DQo+Pj4gYmZjcGJpc0BpZXRmLm9yZw0KPj4+IGh0 dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vYmZjcGJpcw0KPj4NCj4+X19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCj4+YmZjcGJpcyBtYWls aW5nIGxpc3QNCj4+YmZjcGJpc0BpZXRmLm9yZw0KPj5odHRwczovL3d3dy5pZXRmLm9yZy9tYWls bWFuL2xpc3RpbmZvL2JmY3BiaXMNCj4NCg0K From nobody Mon Nov 23 09:50:43 2015 Return-Path: X-Original-To: bfcpbis@ietf.org Delivered-To: bfcpbis@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 0DC2C1AC3EC; Mon, 23 Nov 2015 09:50:41 -0800 (PST) Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit From: The IESG To: "IETF-Announce" X-Test-IDTracker: no X-IETF-IDTracker: 6.11.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20151123175041.14265.3420.idtracker@ietfa.amsl.com> Date: Mon, 23 Nov 2015 09:50:41 -0800 Archived-At: Cc: alcoop@cisco.com, bfcpbis-chairs@ietf.org, bfcpbis@ietf.org, draft-ietf-bfcpbis-rfc4582bis@ietf.org, The IESG , mary.ietf.barnes@gmail.com, rfc-editor@rfc-editor.org Subject: [bfcpbis] Protocol Action: 'The Binary Floor Control Protocol (BFCP)' to Proposed Standard (draft-ietf-bfcpbis-rfc4582bis-16.txt) X-BeenThere: bfcpbis@ietf.org X-Mailman-Version: 2.1.15 List-Id: BFCPBIS working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Nov 2015 17:50:41 -0000 The IESG has approved the following document: - 'The Binary Floor Control Protocol (BFCP)' (draft-ietf-bfcpbis-rfc4582bis-16.txt) as Proposed Standard This document is the product of the Binary Floor Control Protocol Bis Working Group. The IESG contact persons are Ben Campbell, Barry Leiba and Alissa Cooper. A URL of this Internet Draft is: https://datatracker.ietf.org/doc/draft-ietf-bfcpbis-rfc4582bis/ Technical Summary: This document specifies the Binary Floor Control Protocol (BFCP). BFCP is used between floor participants and floor control servers, and between floor chairs (i.e., moderators) and floor control servers. Floor control is a means to manage joint or exclusive access to shared resources in a (multiparty) conferencing environment. Thereby, floor control complements other functions -- such as conference and media session setup, conference policy manipulation, and media control -- that are realized by other protocols. This document obsoletes RFC 4582. Working Group Summary: This document was thoroughly reviewed by members of the BFCPBIS WG. Document Quality There are existing implementations of RFC 4582 and this document has been implemented by at least one vendor. The formation of the BFCPBIS WG was triggered by the IMTC, who defined the use of BFCP in their SIP Best Current Practices for Video profile. The vendors that had implemented BFCP found the need to also use UDP in certain situations, thus the interested parties brought the proposal, along with an initial version of this draft to the IETF (DISPATCH WG). Personnel Mary Barnes is the Document Shepherd. Alissa Cooper is the Responsible AD.