From nobody Sat Aug 1 03:42:59 2015 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B82E91A88D9 for ; Sat, 1 Aug 2015 03:42:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.2 X-Spam-Level: X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id i6w04XXfPQAv for ; Sat, 1 Aug 2015 03:42:56 -0700 (PDT) Received: from sesbmg22.ericsson.net (sesbmg22.ericsson.net [193.180.251.48]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BDE301A1A16 for ; Sat, 1 Aug 2015 03:42:55 -0700 (PDT) X-AuditID: c1b4fb30-f79706d000007227-0f-55bca2ad8c5b Received: from ESESSHC022.ericsson.se (Unknown_Domain [153.88.253.124]) by sesbmg22.ericsson.net (Symantec Mail Security) with SMTP id 74.15.29223.DA2ACB55; Sat, 1 Aug 2015 12:42:53 +0200 (CEST) Received: from ESESSMB209.ericsson.se ([169.254.9.36]) by ESESSHC022.ericsson.se ([153.88.183.84]) with mapi id 14.03.0210.002; Sat, 1 Aug 2015 12:42:53 +0200 From: Christer Holmberg To: Roman Shpount , "Rauschenbach, Uwe (Nokia - DE/Munich)" Thread-Topic: [rtcweb] Proposal: require rtcp-mux (remove non-muxed RTCP; it would be Christmas in July!) Thread-Index: AQHQyvx8V8vzTHQq1UyV9J/pt2HwDp30w60AgAB5cYCAAAlpAIAAEkYAgAAd/QCAACs4gIAALhWu///gU4CAAARagIAANhQA///fmQCAAA46gIABHnAA Date: Sat, 1 Aug 2015 10:42:52 +0000 Message-ID: <7594FB04B1934943A5C02806D1A2204B348E3B60@ESESSMB209.ericsson.se> References: <7594FB04B1934943A5C02806D1A2204B348E29DA@ESESSMB209.ericsson.se> <7594FB04B1934943A5C02806D1A2204B348E2D1B@ESESSMB209.ericsson.se> <56C2F665D49E0341B9DF5938005ACDF8196FF34B@DEMUMBX005.nsn-intra.net> 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: multipart/alternative; boundary="_000_7594FB04B1934943A5C02806D1A2204B348E3B60ESESSMB209erics_" MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFprKIsWRmVeSWpSXmKPExsUyM+Jvje7aRXtCDV7Ok7PYOlXIYsaFqcwW a/+1s1s8nnyK3YHFY8GmUo8lS34yedy9dYnJ49aUggCWKC6blNSczLLUIn27BK6M7z87mQp+ 6VdcX7CMuYHxhF4XIyeHhICJxJprPawQtpjEhXvr2boYuTiEBI4ySlxds5wdwlnEKPHn0XOg Kg4ONgELie5/2iANIgK5EquP3WAHsZkFfCVevJ0GNkhYIEtiY/M0sHIRgWyJS/ddQcaICDQx Svzb+IcRJM4ioCJxdmkmSDkvUOvp1q+MEKt2sks8a33KApLgFAiUmP3pCCOIzQh03PdTa5gg dolL3HoynwniaAGJJXvOM0PYohIvH/+DekZJYtHtz1D1+RJvHrQzQywTlDg58wnLBEbRWUhG zUJSNgtJ2SygU5kFNCXW79KHKFGUmNL9kB3C1pBonTOXHVl8ASP7KkbR4tTipNx0IyO91KLM 5OLi/Dy9vNSSTYzAeDy45bfBDsaXzx0PMQpwMCrx8Cpo7AkVYk0sK67MPcQozcGiJM47Y3Ne qJBAemJJanZqakFqUXxRaU5q8SFGJg5OqQZGlofyizgmHr2ww/L2iwP/29OWzHLvnSDTps4U mRxTetH9caVrwaZzcS6caXz2kfseRijqzq9K0N6hNZG/dOq7yS0fdWS4j5jHc3z9rrS/rva2 8L80xodWAu/U3Ve59YnLzJ/OOGfFwWu+p07J7dwmkPmc0cL0bl7OsnMeq5/eDWRLznoZoBKr xFKckWioxVxUnAgAPAEGCagCAAA= Archived-At: Cc: "" Subject: Re: [rtcweb] Proposal: require rtcp-mux (remove non-muxed RTCP; it would be Christmas in July!) X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 01 Aug 2015 10:42:57 -0000 --_000_7594FB04B1934943A5C02806D1A2204B348E3B60ESESSMB209erics_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SGksDQoNCj5JIGFtIHRyeWluZyB0byBkaWZmZXJlbnRpYXRlIGhlcmUgZW5kIHBvaW50cyB0aGF0 IGNhbiBiZSBjb21wbGlhbnQgd2l0aCBSRkMgNTc2MSBieSBuZXZlciBvZmZlcmluZyBydGNwLW11 eCBhbmQgcmVqZWN0aW5nIGFsbCBvZmZlcnMgPndpdGggcnRjcC1tdXguIFdoYXQgd2UgYXJlIHBy b3Bvc2luZyBoZXJlIGlzIHRoYXQgcnRjcC1tdXggaXMgYWN0dWFsbHkgdXNlZCBmb3IgYWxsIHRo ZSBSVFAvUlRDUCBzdHJlYW1zLCBub3QganVzdCBjb3JyZWN0bHkgPm5lZ290aWF0ZWQgYXdheS4N Cg0KV2VsbCwgSSBzdGlsbCB0aGluayBpdCBzaGFsbCBiZSBjb3JyZWN0bHkgbmVnb3RpYXRlZC4g QW5kLCBpZiBOT1QgbmVnb3RpYXRlZCwgdGhlIGRldmljZSB3b3VsZCBub3QgYmUgY29tcGxpYW50 IHdpdGggdGhlIHNwZWMuDQoNClJlZ2FyZHMsDQoNCkNocmlzdGVyDQoNCg0KX19fX19fX19fX19f Xw0KUm9tYW4gU2hwb3VudA0KDQo= --_000_7594FB04B1934943A5C02806D1A2204B348E3B60ESESSMB209erics_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 IkNhbWJyaWEgTWF0aCI7DQoJcGFub3NlLTE6MiA0IDUgMyA1IDQgNiAzIDIgNDt9DQpAZm9udC1m YWNlDQoJe2ZvbnQtZmFtaWx5OkNhbGlicmk7DQoJcGFub3NlLTE6MiAxNSA1IDIgMiAyIDQgMyAy IDQ7fQ0KLyogU3R5bGUgRGVmaW5pdGlvbnMgKi8NCnAuTXNvTm9ybWFsLCBsaS5Nc29Ob3JtYWws IGRpdi5Nc29Ob3JtYWwNCgl7bWFyZ2luOjBjbTsNCgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJ Zm9udC1zaXplOjEyLjBwdDsNCglmb250LWZhbWlseToiVGltZXMgTmV3IFJvbWFuIixzZXJpZjt9 DQphOmxpbmssIHNwYW4uTXNvSHlwZXJsaW5rDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCglj b2xvcjpibHVlOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0KYTp2aXNpdGVkLCBzcGFu Lk1zb0h5cGVybGlua0ZvbGxvd2VkDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgljb2xvcjpw dXJwbGU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQpzcGFuLkVtYWlsU3R5bGUxNw0K CXttc28tc3R5bGUtdHlwZTpwZXJzb25hbDsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsc2Fucy1z ZXJpZjsNCgljb2xvcjojMUY0OTdEO30NCnNwYW4uRW1haWxTdHlsZTE4DQoJe21zby1zdHlsZS10 eXBlOnBlcnNvbmFsLWNvbXBvc2U7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLHNhbnMtc2VyaWY7 DQoJY29sb3I6d2luZG93dGV4dDt9DQouTXNvQ2hwRGVmYXVsdA0KCXttc28tc3R5bGUtdHlwZTpl eHBvcnQtb25seTsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsc2Fucy1zZXJpZjsNCgltc28tZmFy ZWFzdC1sYW5ndWFnZTpFTi1VUzt9DQpAcGFnZSBXb3JkU2VjdGlvbjENCgl7c2l6ZTo2MTIuMHB0 IDc5Mi4wcHQ7DQoJbWFyZ2luOjcyLjBwdCA3Mi4wcHQgNzIuMHB0IDcyLjBwdDt9DQpkaXYuV29y ZFNlY3Rpb24xDQoJe3BhZ2U6V29yZFNlY3Rpb24xO30NCi0tPjwvc3R5bGU+PCEtLVtpZiBndGUg bXNvIDldPjx4bWw+DQo8bzpzaGFwZWRlZmF1bHRzIHY6ZXh0PSJlZGl0IiBzcGlkbWF4PSIxMDI2 IiAvPg0KPC94bWw+PCFbZW5kaWZdLS0+PCEtLVtpZiBndGUgbXNvIDldPjx4bWw+DQo8bzpzaGFw ZWxheW91dCB2OmV4dD0iZWRpdCI+DQo8bzppZG1hcCB2OmV4dD0iZWRpdCIgZGF0YT0iMSIgLz4N CjwvbzpzaGFwZWxheW91dD48L3htbD48IVtlbmRpZl0tLT4NCjwvaGVhZD4NCjxib2R5IGxhbmc9 IkVOLUdCIiBsaW5rPSJibHVlIiB2bGluaz0icHVycGxlIj4NCjxkaXYgY2xhc3M9IldvcmRTZWN0 aW9uMSI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBw dDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3 RDttc28tZmFyZWFzdC1sYW5ndWFnZTpFTi1VUyI+SGksPG86cD48L286cD48L3NwYW4+PC9wPg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1m YW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0Q7bXNvLWZh cmVhc3QtbGFuZ3VhZ2U6RU4tVVMiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxkaXY+ DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4mZ3Q7SSBhbSB0cnlp bmcgdG8gZGlmZmVyZW50aWF0ZSBoZXJlIGVuZCBwb2ludHMgdGhhdCBjYW4gYmUgY29tcGxpYW50 IHdpdGggUkZDIDU3NjEgYnkgbmV2ZXIgb2ZmZXJpbmcgcnRjcC1tdXggYW5kIHJlamVjdGluZyBh bGwgb2ZmZXJzICZndDt3aXRoIHJ0Y3AtbXV4LiBXaGF0IHdlIGFyZSBwcm9wb3NpbmcgaGVyZSBp cyB0aGF0IHJ0Y3AtbXV4IGlzIGFjdHVhbGx5IHVzZWQgZm9yIGFsbCB0aGUgUlRQL1JUQ1Agc3Ry ZWFtcywNCiBub3QganVzdCBjb3JyZWN0bHkgJmd0O25lZ290aWF0ZWQgYXdheS48bzpwPjwvbzpw PjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0 O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZiI+PG86cD4mbmJzcDs8 L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQt c2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmIj5X ZWxsLCBJIHN0aWxsIHRoaW5rIGl0IHNoYWxsIGJlIGNvcnJlY3RseSBuZWdvdGlhdGVkLiBBbmQs IGlmIE5PVCBuZWdvdGlhdGVkLCB0aGUgZGV2aWNlIHdvdWxkIG5vdCBiZSBjb21wbGlhbnQgd2l0 aCB0aGUgc3BlYy48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48 c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1 b3Q7LHNhbnMtc2VyaWYiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90 O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZiI+UmVnYXJkcyw8bzpwPjwvbzpwPjwvc3Bhbj48L3A+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250 LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWYiPjxvOnA+Jm5ic3A7PC9vOnA+ PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6 MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZiI+Q2hyaXN0 ZXI8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHls ZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMt c2VyaWYiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkm cXVvdDssc2Fucy1zZXJpZiI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8 ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPl9fX19fX19fX19fX188YnI+DQpSb21h biBTaHBvdW50PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2 Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvYm9keT4NCjwvaHRtbD4NCg== --_000_7594FB04B1934943A5C02806D1A2204B348E3B60ESESSMB209erics_-- From nobody Sat Aug 1 16:02:15 2015 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E01091A8745 for ; Sat, 1 Aug 2015 16:02:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, SPF_HELO_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Ww9JJZ_huhwP for ; Sat, 1 Aug 2015 16:02:11 -0700 (PDT) Received: from na01-bn1-obe.outbound.protection.outlook.com (mail-bn1bon0676.outbound.protection.outlook.com [IPv6:2a01:111:f400:fc10::1:676]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0BFA81A873A for ; Sat, 1 Aug 2015 16:02:11 -0700 (PDT) Received: from SN1PR0301MB1551.namprd03.prod.outlook.com (10.162.129.157) by SN1PR0301MB1552.namprd03.prod.outlook.com (10.162.129.158) with Microsoft SMTP Server (TLS) id 15.1.225.19; Sat, 1 Aug 2015 23:01:51 +0000 Received: from SN1PR0301MB1551.namprd03.prod.outlook.com ([10.162.129.157]) by SN1PR0301MB1551.namprd03.prod.outlook.com ([10.162.129.157]) with mapi id 15.01.0225.018; Sat, 1 Aug 2015 23:01:50 +0000 From: "Asveren, Tolga" To: Victor Pascual Avila , Roman Shpount Thread-Topic: [rtcweb] Proposal: require rtcp-mux (remove non-muxed RTCP; it would be Christmas in July!) Thread-Index: AQHQyz2WarP6bihqdUKrjE+AJblPlJ31XJYcgAAK9gCAABGjIIAAHqAAgAArOICAAAyOgIAABlBPgAABOICAAe25gA== Date: Sat, 1 Aug 2015 23:01:50 +0000 Message-ID: References: <7594FB04B1934943A5C02806D1A2204B348E29DA@ESESSMB209.ericsson.se> , In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: ietf.org; dkim=none (message not signed) header.d=none; x-originating-ip: [50.182.164.80] x-microsoft-exchange-diagnostics: 1; SN1PR0301MB1552; 5:p7wX08W6GWgwfw7+2k8QTMU8q3DkdxRNaW3IEoALGcO1R4GOXT/jLvbs4nBelaeJScsTagXWTqqK9fqrOHmFQhIay2NmLMVQspLauAUzsK9085iWlSEwgW9hcvEyb0/S6ZQp45tb/GuisNlMA9N4PQ==; 24:J/tRqvr3zAFsvXzUlb64MFoBLQiFVWZa/sgxp193T5rBVEi2LLeo2ddxmj5DDNxeKfWg8bvxMOWAlGrCWnq6rCBDKr4p0jp0fWG6+XBmGWY=; 20:JvgIfWbdJUFJa7YYB2R9QomkehCeSUb6SPL/cmWXVt/s95plhY3/Q0qOxPhufj+r8flmUprLvuOb16d7IIJOug== x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:SN1PR0301MB1552; sn1pr0301mb1552: X-MS-Exchange-Organization-RulesExecuted x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:; x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(601004)(5005006)(3002001); SRVR:SN1PR0301MB1552; BCL:0; PCL:0; RULEID:; SRVR:SN1PR0301MB1552; x-forefront-prvs: 0655F9F006 x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(24454002)(164054003)(377454003)(5002640100001)(40100003)(19580405001)(86362001)(5001960100002)(50986999)(5003600100002)(66066001)(102836002)(92566002)(77096005)(87936001)(99286002)(19625215002)(2900100001)(189998001)(2656002)(561944003)(46102003)(76576001)(122556002)(93886004)(62966003)(76176999)(74316001)(106116001)(5001770100001)(2950100001)(16236675004)(33656002)(77156002)(19580395003)(54356999)(19627405001); DIR:OUT; SFP:1101; SCL:1; SRVR:SN1PR0301MB1552; H:SN1PR0301MB1551.namprd03.prod.outlook.com; FPR:; SPF:None; MLV:sfv; LANG:en; Content-Type: multipart/alternative; boundary="_000_SN1PR0301MB1551BFEAACC328FD8998AFD8B2890SN1PR0301MB1551_" MIME-Version: 1.0 X-OriginatorOrg: sonusnet.com X-MS-Exchange-CrossTenant-originalarrivaltime: 01 Aug 2015 23:01:50.1364 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 29a671dc-ed7e-4a54-b1e5-8da1eb495dc3 X-MS-Exchange-Transport-CrossTenantHeadersStamped: SN1PR0301MB1552 Archived-At: Cc: "" Subject: Re: [rtcweb] Proposal: require rtcp-mux (remove non-muxed RTCP; it would be Christmas in July!) X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 01 Aug 2015 23:02:14 -0000 --_000_SN1PR0301MB1551BFEAACC328FD8998AFD8B2890SN1PR0301MB1551_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable This list of expected behavior sounds good to me as well. GWs being "WebRTC= -compatible endpoint" rather than "WebRTC endpoint" would have some freedom= and browsers still can choose the path of mandating rtcp-mux (and otherwis= e failing the sessions) if the choose to do so. Thanks, Tolga ________________________________ From: rtcweb on behalf of Victor Pascual Avila Sent: Friday, July 31, 2015 1:31 PM To: Roman Shpount Cc: Subject: Re: [rtcweb] Proposal: require rtcp-mux (remove non-muxed RTCP; it= would be Christmas in July!) On Fri, Jul 31, 2015 at 7:27 PM, Roman Shpount > wrote: On Fri, Jul 31, 2015 at 1:11 PM, Justin Uberti > wrote: Mandating usage rtcp-mux means that an implementation is free to not negoti= ate it (or fail if the remote side does not support it). Right? What I want to see precisely is the following: 1. WebRTC end point MUST include rtcp-mux for every SDP m-line in any offer= it generates 2. WebRTC end point MAY include RTCP ICE component, RTCP ICE candidates, an= d "rtcp" SDP attribute with distinct RTCP address/port in the offer if it w= ants to support non mux RTCP traffic or it MAY ommit all of those attribute= s. 3. WebRTC end point MUST include rtcp-mux in response to any offer which co= ntains rtcp-mux. It should not include RTCP ICE components or RTCP ICE cand= idates in the answer. "rtcp" SDP attribute MUST contain only port which sho= uld be the same as port associated with m-line (or address from c-line and = port from m-line). 4. WebRTC end point MAY accept offers without rtcp-mux or MAY reject them. So, basically, rtcp-mux must be offered and must be accepted if offered. En= d point can continue to create offers which will work without rtcp-mux or a= ccept offers without rtcp-mux if it needs to interop with legacy. +1 Cheers, -Victor --_000_SN1PR0301MB1551BFEAACC328FD8998AFD8B2890SN1PR0301MB1551_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

This list of expected behavior sounds good to me as well. GWs being &quo= t;WebRTC-compatible endpoint" rather than "WebRTC endpoint" = would have some freedom and browsers still can choose the path of mandating= rtcp-mux (and otherwise failing the sessions) if the choose to do so.


Thanks,

Tolga



From: rtcweb <rtcweb-bou= nces@ietf.org> on behalf of Victor Pascual Avila <victor.pascual.avil= a@gmail.com>
Sent: Friday, July 31, 2015 1:31 PM
To: Roman Shpount
Cc: <rtcweb@ietf.org>
Subject: Re: [rtcweb] Proposal: require rtcp-mux (remove non-muxed R= TCP; it would be Christmas in July!)
 
On Fri, Jul 31, 2015 at 7:27 PM, Roman Shpount <= span dir=3D"ltr"> <roman@telurix.co= m> wrote:
On Fri, Jul 31, 2015 at 1:11 PM, Justin Uberti <<= a href=3D"mailto:juberti@google.com" target=3D"_blank" title=3D"mailto:jube= rti@google.com=0A= Cmd+Click or tap to follow the link">juberti@google.com> = wrote:
Mandating usage rtcp-mux means that an implementation is f= ree to not negotiate it (or fail if the remote side does not support it). R= ight?


What I want to see precisely is the following:

1. WebRTC end point MUST include rtcp-mux for every SDP m-li= ne in any offer it generates
2. WebRTC end point MAY include RTCP ICE component, RTCP ICE candidate= s, and "rtcp" SDP attribute with distinct RTCP address/port in th= e offer if it wants to support non mux RTCP traffic or it MAY ommit all of = those attributes.
3. WebRTC end point MUST include rtcp-mux in response to any offer whi= ch contains rtcp-mux. It should not include RTCP ICE components or RTCP ICE= candidates in the answer. "rtcp" SDP attribute MUST contain only= port which should be the same as port associated with m-line (or address from c-line and port from m-line).
4. WebRTC end point MAY accept offers without rtcp-mux or MAY reject t= hem.

So, basically, rtcp-mux must be offered and must be accepted if offere= d. End point can continue to create offers which will work without rtcp-mux= or accept offers without rtcp-mux if it needs to interop with legacy.

+1

Cheers,
-Victor
--_000_SN1PR0301MB1551BFEAACC328FD8998AFD8B2890SN1PR0301MB1551_-- From nobody Sat Aug 1 19:20:54 2015 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 832A51A8840 for ; Sat, 1 Aug 2015 19:20:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.423 X-Spam-Level: X-Spam-Status: No, score=-0.423 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FAKE_REPLY_C=1.486, T_RP_MATCHES_RCVD=-0.01, WEIRD_PORT=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 jSk5jE-eZBoG for ; Sat, 1 Aug 2015 19:20:51 -0700 (PDT) Received: from lo.psyced.org (lost.in.psyced.org [188.40.42.221]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E89E41A883E for ; Sat, 1 Aug 2015 19:20:50 -0700 (PDT) Received: from lo.psyced.org (localhost [127.0.0.1]) by lo.psyced.org (8.14.3/8.14.3/Debian-9.4) with ESMTP id t722L7aX025213 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Sun, 2 Aug 2015 04:21:07 +0200 Received: (from lynx@localhost) by lo.psyced.org (8.14.3/8.14.3/Submit) id t722L71L025212 for rtcweb@ietf.org; Sun, 2 Aug 2015 04:21:07 +0200 Date: Sun, 2 Aug 2015 04:21:06 +0200 From: carlo von lynX To: rtcweb@ietf.org Message-ID: <20150802022106.GA25129@lo.psyced.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.5.20 (2009-06-14) Archived-At: Subject: Re: [rtcweb] Prompt for mic, camera *and* network access X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 02 Aug 2015 02:20:52 -0000 On Fri, Jul 31, 2015 at 05:18:33PM -0700, Matthew Kaufman wrote: > I understood the magnitude of the issue, and I still think you're > overreacting. > > Disagree. That is both irrelevant. Either you disprove the scenario I described as non-critical or you fix the bug. > If you're worried about "top notch security bugs risking human > lives" there's at least a dozen I'd tackle before thinking about > this one. It allows browsers to do little more than people have been > accepting for years, in their browsers. Name some. We have plenty of bugs allowing to trace a user being the same user as yesterday, but we don't have many that produce the IP number of that person's home so authority knows where to pick her up. -- E-mail is public! Talk to me in private using encryption: http://loupsycedyglgamf.onion/LynX/ irc://loupsycedyglgamf.onion:67/lynX https://psyced.org:34443/LynX/ From nobody Sat Aug 1 19:21:29 2015 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 497991A8854 for ; Sat, 1 Aug 2015 19:21:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 4.258 X-Spam-Level: **** X-Spam-Status: No, score=4.258 tagged_above=-999 required=5 tests=[BAYES_50=0.8, FAKE_REPLY_C=1.486, FRT_PROFILE2=1.981, T_RP_MATCHES_RCVD=-0.01, WEIRD_PORT=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 uXezvFj9D2Vt for ; Sat, 1 Aug 2015 19:21:27 -0700 (PDT) Received: from lo.psyced.org (lost.in.psyced.org [188.40.42.221]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 94D0D1A87D0 for ; Sat, 1 Aug 2015 19:21:26 -0700 (PDT) Received: from lo.psyced.org (localhost [127.0.0.1]) by lo.psyced.org (8.14.3/8.14.3/Debian-9.4) with ESMTP id t722LhLD025253 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Sun, 2 Aug 2015 04:21:43 +0200 Received: (from lynx@localhost) by lo.psyced.org (8.14.3/8.14.3/Submit) id t722LgHw025252 for rtcweb@ietf.org; Sun, 2 Aug 2015 04:21:42 +0200 Date: Sun, 2 Aug 2015 04:21:42 +0200 From: carlo von lynX To: rtcweb@ietf.org Message-ID: <20150802022142.GB25129@lo.psyced.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.5.20 (2009-06-14) Archived-At: Subject: Re: [rtcweb] Prompt for mic, camera *and* network access X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 02 Aug 2015 02:21:28 -0000 On Sat, Aug 01, 2015 at 03:45:13AM +0200, Philipp Hancke wrote: > At least hackingteam didn't figure out the webrtc method themselves > either according to > https://wikileaks.org/hackingteam/emails/emailid/119217 Exactly, so they wouldn't have figured out the RTMFP possibility until Mr Kaufman informed us about it. The only agency that has enough financing to keep people actively looking for this sort of flaws is the NSA, and the NSA is not the threat model in this situation. We are talking of a lot less proficient folks digging up some methods from the Internet and applying it against dissidents in their own country. They know of the WebRTC method since that got published and maybe since a few mails they also know about RTMFP. > Now if you assume a smarter opponent than that, why is that opponent not > smart enough to have figured out the RTMFP method as well? I don't. HackingTeam is about the best a country like Sudan can afford. > Granted, RTMFP is a pretty tough nut to reverse engineer but it had > been done back in late 2010. I know who did so. It's less than a handful of people I assume and none of them saw the secret service potential of local IP numbers, including the folks at Adobe supervising Mr Kaufman's work. So the fact that nobody ever cared to mention this loophole was enough to keep it out of range for oppressive regimes. > And it is P2P. It has to exchange some ip addresses somehow. I would expect this to already be a notion beyond the competences of Egyptian or Syrian authorities... until you said it. > Even despite the encryption scheme, you can use wireshark to see > ice-like packets. Their content will be unreadable, but the IP > addresses tell you what is going on. Sure, but have the ever thought of wiresharking the traffic of chatroulette close enough to notice that there are IPs in there? No, because whenever they caught anyone using chatroulette they already knew his IP number. Why should they care to wireshark deeper? Whereas if there ever were dissidents looking at chat- roulette (I doubt that) through a VPN or Tor (even less likely) then it bypassed them entirely so there was nothing to wireshark. > I do recall LOL'ing when finding out that Adobe leaked 10.x server > addresses in the early days of cirrus. How are servers related to this? > >Hardly anyone looked at RTMFP all that much since the only > >existing server implementation was running at Adobe. > > I disagree with your "hardly anyone" FWIW. But you cannot disprove my danger scenario for dissidents, so that's enough to still take this issue seriously. > >Quite different from the WebRTC case where the API quite clearly > >explains how to get at local IP information. > > I do not understand your argument. RTMFP did not expose the local IP > information at the API level. However, that did not mean it was not > discoverable as explained above. And that is exactly the point. Persian authorities would never figure out that a custom flash movie using RTMFP would have helped them do their job, but it's easy to put into practice what's openly stated in a documentation.. especially after there has been a major shitstorm about it. > Assuming that your point is that WebRTC shouldn't expose this and > use a signaling channel that isn't under control of the browser, how > would that increase security? I'm saying that WebRTC should not do anything until it has gotten permission from the user. Dissidents would be alert and block the transaction. The only situation a dissident would want to use WebRTC is when the VPN is turned off and she is calling her mother to talk about what to cook for dinner. But if WebRTC is allowed to do what it likes to do even when she is crawling government sites for information useful to the resistance movement... well then that is bad as it can cause the bad guys to come to her house and search her computer for incriminating material (which they would probably find, because your average dissident isn't an OPSEC Appelbaum type). Being a person out of millions is protection. Deanonymization can spell imprisonment, torture and worse. -- E-mail is public! Talk to me in private using encryption: http://loupsycedyglgamf.onion/LynX/ irc://loupsycedyglgamf.onion:67/lynX https://psyced.org:34443/LynX/ From nobody Mon Aug 3 00:19:18 2015 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 011F81A8902 for ; Mon, 3 Aug 2015 00:19:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.909 X-Spam-Level: X-Spam-Status: No, score=-4.909 tagged_above=-999 required=5 tests=[BAYES_05=-0.5, HTML_MESSAGE=0.001, J_CHICKENPOX_34=0.6, RCVD_IN_DNSWL_HI=-5, 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 RAXQrkqW9J_K for ; Mon, 3 Aug 2015 00:19:09 -0700 (PDT) Received: from smtp-fr.alcatel-lucent.com (fr-hpida-esg-02.alcatel-lucent.com [135.245.210.21]) (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 C78FB1A8937 for ; Mon, 3 Aug 2015 00:19:08 -0700 (PDT) Received: from fr712usmtp2.zeu.alcatel-lucent.com (unknown [135.239.2.42]) by Websense Email Security Gateway with ESMTPS id CFD24AEBFE2E9; Mon, 3 Aug 2015 07:19:03 +0000 (GMT) Received: from FR711WXCHHUB02.zeu.alcatel-lucent.com (fr711wxchhub02.zeu.alcatel-lucent.com [135.239.2.112]) by fr712usmtp2.zeu.alcatel-lucent.com (GMO) with ESMTP id t737J3Ss006386 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Mon, 3 Aug 2015 09:19:04 +0200 Received: from FR711WXCHMBA03.zeu.alcatel-lucent.com ([169.254.3.123]) by FR711WXCHHUB02.zeu.alcatel-lucent.com ([135.239.2.112]) with mapi id 14.03.0195.001; Mon, 3 Aug 2015 09:19:03 +0200 From: "Schwarz, Albrecht (Albrecht)" To: "Rauschenbach, Uwe (Nokia - DE/Munich)" , "ext Asveren, Tolga" , Christer Holmberg , Bernard Aboba , Roman Shpount Thread-Topic: [rtcweb] What the gateway draft should say about mux/non-mux Thread-Index: AQHQy78uKxT/0f1cqU+61qeHi7bRGJ31yJ8AgAABlICAAAJzgIAAAVWAgAABfoCABA9LcA== Date: Mon, 3 Aug 2015 07:19:02 +0000 Message-ID: <786615F3A85DF44AA2A76164A71FE1AC7ADB690D@FR711WXCHMBA03.zeu.alcatel-lucent.com> References: <7594FB04B1934943A5C02806D1A2204B348E29DA@ESESSMB209.ericsson.se> <67196805-ED4E-49EA-83AA-3F4C37B5BC50@gmail.com> <7594FB04B1934943A5C02806D1A2204B348E2D52@ESESSMB209.ericsson.se> <56C2F665D49E0341B9DF5938005ACDF8196FF3ED@DEMUMBX005.nsn-intra.net> <56C2F665D49E0341B9DF5938005ACDF8196FF450@DEMUMBX005.nsn-intra.net> In-Reply-To: <56C2F665D49E0341B9DF5938005ACDF8196FF450@DEMUMBX005.nsn-intra.net> Accept-Language: de-DE, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [135.239.27.38] Content-Type: multipart/alternative; boundary="_000_786615F3A85DF44AA2A76164A71FE1AC7ADB690DFR711WXCHMBA03z_" MIME-Version: 1.0 Archived-At: Cc: "" Subject: Re: [rtcweb] What the gateway draft should say about mux/non-mux X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 03 Aug 2015 07:19:15 -0000 --_000_786615F3A85DF44AA2A76164A71FE1AC7ADB690DFR711WXCHMBA03z_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 VGhlIHByaW1hcnkganVzdGlmaWNhdGlvbiBvZiB3ZWJydGMgZ2F0ZXdheXMgaXMgdG8gaW5jcmVh c2UgdGhlIHByb3BhYmlsaXR5IG9mIHN1Y2Nlc3NmdWxseSBlbmQtdG8tZW5kIHdlYnJ0YyBjYWxs czsgLQ0KYmV0d2VlbiB3ZWJydGMgYW5kIG5vbi13ZWJydGMgY2xpZW50cywgYmV0d2VlbiB0d28g d2VicnRjIGNsaWVudHMgd2l0aCBkaWZmZXJlbnQgY2FwYWJpbGl0eSBzdXBwb3J0Lg0KVGhhdCBz YWlkLCB0aGUgc3VwcG9ydGVkIGNhcGFiaWxpdGllcyBvZiBhIHdlYnJ0YyBnYXRld2F5IHNob3Vs ZCBub3QgbGVhZCB0byBhbiBpbmhlcmVudCByZWR1Y3Rpb24gb2YgdGhlIHN1Y2Nlc3NmdWwgd2Vi cnRjIGNhbGwgZXN0YWJsaXNobWVudCByYXRlLCBpLmUuLCBub3QgbmVnYXRpdmVseSBpbXBhY3Qg dGhlIGNhbGwgY29udHJvbCBsZXZlbCBuZWdvdGlhdGlvbiBwcm9jZWR1cmVzLg0KDQpDb25jbHVz aW9uOiB0aGUgd2VicnRjIGdhdGV3YXkgTVVTVCBzdXBwb3J0IFJUQ1AgdHJhbnNwb3J0IG11bHRp cGxleGVkIGFuZCBSVENQIHRyYW5zcG9ydCB1bm11bHRpcGxleGVkIG1vZGVzLCBhcyB3ZWxsIGFz IHRoZSBpbnRlcndvcmtpbmcgYmV0d2VlbiBib3RoIG1vZGVzLg0KDQpSZWdhcmRzLA0KQWxicmVj aHQNCg0KUFMNCldpdGggcmVnYXJkcyB0byBEVExTLVNSVFAsIGkuZS4sIHRoZSBEVExTLWJhc2Vk IGtleSBtYW5hZ2VtZW50IHNjaGVtZSBmb3IgU1JUUDoNCkEgd2VicnRjIGdhdGV3YXkgbWlnaHQg bmVlZCB0byBzdXBwb3J0IGludGVyd29ya2luZyBiZXR3ZWVuIGEgd2VicnRjIGRvbWFpbiB3aXRo IERUTFMtU1JUUCBhbmQgYSBub24td2VicnRjIGRvbWFpbiB3aXRoIFNERVMtYmFzZWQga2V5IG1h bmFnZW1lbnQgc2NoZW1lLCBpLmUuIGEgc2NlbmFyaW8gb2YgdHlwZSBTUlRQLXRvLVNSVFAgaW50 ZXJ3b3JraW5nLiBCdXQgSSBndWVzcyB0aGF0IHVzZSBjYXNlIGlzIGJleW9uZCB0aGUgSUVURiBn YXRld2F5IGRyYWZ0Lg0KDQoNCkZyb206IHJ0Y3dlYiBbbWFpbHRvOnJ0Y3dlYi1ib3VuY2VzQGll dGYub3JnXSBPbiBCZWhhbGYgT2YgUmF1c2NoZW5iYWNoLCBVd2UgKE5va2lhIC0gREUvTXVuaWNo KQ0KU2VudDogRnJlaXRhZywgMzEuIEp1bGkgMjAxNSAyMTowOA0KVG86IGV4dCBBc3ZlcmVuLCBU b2xnYTsgQ2hyaXN0ZXIgSG9sbWJlcmc7IEJlcm5hcmQgQWJvYmE7IFJvbWFuIFNocG91bnQNCkNj OiA8cnRjd2ViQGlldGYub3JnPg0KU3ViamVjdDogUmU6IFtydGN3ZWJdIFdoYXQgdGhlIGdhdGV3 YXkgZHJhZnQgc2hvdWxkIHNheSBhYm91dCBtdXgvbm9uLW11eA0KDQpZZXMsIGFncmVlZCwgdGhl c2UgYXJlIGluIHR3byBkaWZmZXJlbnQgY2F0ZWdvcmllcy4NCg0KUlRDUCBtdXggaXMgYW4gb3B0 aW1pemF0aW9uIOKAkyBub3Qgc3VwcG9ydGluZyBpdCBkb3VibGVzIHRoZSBudW1iZXIgb2YgcG9y dHMgdG8gYmUgdXNlZCwgYW5kIHNsb3dzIGRvd24gSUNFIGdhdGhlcmluZy4NCldoZXJlYXMgSUNF IG5vbi1zdXBwb3J0IGlzIGEgc2hvd3N0b3BwZXINCg0KTGV0IG1lIGhhdmUgc29tZSBpbnRlcm5h bCBkaXNjdXNzaW9ucyBvbiB0aGlzIHRvcGljIGFuZCBnZXQgYmFjayB0byB0aGUgbGlzdCBuZXh0 IHdlZWsuDQoNCktpbmQgcmVnYXJkcywNClV3ZQ0KDQpGcm9tOiBleHQgQXN2ZXJlbiwgVG9sZ2Eg W21haWx0bzp0YXN2ZXJlbkBzb251c25ldC5jb21dDQpTZW50OiBGcmlkYXksIEp1bHkgMzEsIDIw MTUgMTI6MDMgUE0NClRvOiBSYXVzY2hlbmJhY2gsIFV3ZSAoTm9raWEgLSBERS9NdW5pY2gpOyBD aHJpc3RlciBIb2xtYmVyZzsgQmVybmFyZCBBYm9iYTsgUm9tYW4gU2hwb3VudA0KQ2M6IDxydGN3 ZWJAaWV0Zi5vcmc8bWFpbHRvOnJ0Y3dlYkBpZXRmLm9yZz4+DQpTdWJqZWN0OiBSRTogW3J0Y3dl Yl0gV2hhdCB0aGUgZ2F0ZXdheSBkcmFmdCBzaG91bGQgc2F5IGFib3V0IG11eC9ub24tbXV4DQoN ClllcywgY29tcGxldGVseSBhZ3JlZSBvbiB0aGUg4oCcbmV34oCdIHYucy4g4oCcdGhlIHdheSB0 aGluZ3MgdXNlZCB0byB3b3JrIGZvciBtYW55IHllYXJz4oCdIHBvaW50IGFzIGZhciBhcyBydGNw LW11eCBpcyBjb25jZXJuZWQuDQoNCkZ1cnRoZXJtb3JlLCAtZm9yIGV4YW1wbGUtLCBub3QgbWFu ZGF0aW5nIElDRSB3b3VsZCBoYXZlIHNlcmlvdXMgaW1wYWN0IGFzIGZhciBhcyDigJxtYWtpbmcg dGhpbmdzIHdvcmsgZnJvbSBlbmQgdXNlciBwZXJzcGVjdGl2ZeKAnSBpcyBjb25jZXJuZWQuIE9U T0gsIHRoZSBzYW1lIGRvZXMgbm90IG5lY2Vzc2FyaWx5IGhvbGQgdHJ1ZSBmb3IgcnRjcC1tdXgu IFR3byBXZWJSVEMgZWxlbWVudHMsIHdoaWNoIGRvIG5vdCB3YW50IHRvIHVzZSBpdCBjYW4gY29t bXVuaWNhdGUgc3VjY2Vzc2Z1bGx5Lg0KDQpUaGFua3MsDQpUb2xnYQ0KDQpGcm9tOiBSYXVzY2hl bmJhY2gsIFV3ZSAoTm9raWEgLSBERS9NdW5pY2gpIFttYWlsdG86dXdlLnJhdXNjaGVuYmFjaEBu b2tpYS5jb21dDQpTZW50OiBGcmlkYXksIEp1bHkgMzEsIDIwMTUgMjo1OCBQTQ0KVG86IEFzdmVy ZW4sIFRvbGdhIDx0YXN2ZXJlbkBzb251c25ldC5jb208bWFpbHRvOnRhc3ZlcmVuQHNvbnVzbmV0 LmNvbT4+OyBDaHJpc3RlciBIb2xtYmVyZyA8Y2hyaXN0ZXIuaG9sbWJlcmdAZXJpY3Nzb24uY29t PG1haWx0bzpjaHJpc3Rlci5ob2xtYmVyZ0Blcmljc3Nvbi5jb20+PjsgQmVybmFyZCBBYm9iYSA8 YmVybmFyZC5hYm9iYUBnbWFpbC5jb208bWFpbHRvOmJlcm5hcmQuYWJvYmFAZ21haWwuY29tPj47 IFJvbWFuIFNocG91bnQgPHJvbWFuQHRlbHVyaXguY29tPG1haWx0bzpyb21hbkB0ZWx1cml4LmNv bT4+DQpDYzogPHJ0Y3dlYkBpZXRmLm9yZzxtYWlsdG86cnRjd2ViQGlldGYub3JnPj4gPHJ0Y3dl YkBpZXRmLm9yZzxtYWlsdG86cnRjd2ViQGlldGYub3JnPj4NClN1YmplY3Q6IFJFOiBbcnRjd2Vi XSBXaGF0IHRoZSBnYXRld2F5IGRyYWZ0IHNob3VsZCBzYXkgYWJvdXQgbXV4L25vbi1tdXgNCg0K V2VsbDogbm9uLW11eCBpcyBub3QgYSDigJxuZXcgdGhpbmfigJ0gdGhhdCB3ZSBtYW5kYXRlIHRo ZSB3aG9sZSB1bml2ZXJzZSB0byBzdXBwb3J0IOKAkyBpdCBpcyBvbiB0aGUgY29udHJhcnkgdGhl IHdheSBSVENQL1JUUCB1c2VkIHRvIGZ1bmN0aW9uIHNpbmNlIHRoZSBiZWdpbm5pbmcuDQpNVVhp bmcgaXMgdGhlIOKAnG5ldyB0aGluZ+KAnS4NCg0KT2YgY291cnNlIHlvdSBjYW4gdGFrZSBhd2F5 IGxlZ2FjeSBzdXBwb3J0IGlmIG5vLW9uZSBpcyBpbnRlcmVzdGVkIGluIHN1cHBvcnRpbmcgaXQg YW55bW9yZS4NCg0KSSB0aGluayB0aGlzIGlzIHRoZSBjb3JlIG9mIHRoZSBkaXNjdXNzaW9uIHRo YXQgd2UgYXJlIGhhdmluZyDigJMgZG8gd2Ugd2FudCB0byByZXRpcmUgdGhlIG9yaWdpbmFsIHdh eSBSVFArUlRDUCB3ZXJlIHdvcmtpbmcgdy5yLnQuIHBvcnQgdXNhZ2U/DQpJIGhhdmUgbXkgZG91 YnRzIChmb3IgdGhlIHRpbWUgYmVpbmcpLg0KDQpLaW5kIHJlZ2FyZHMsDQpVd2UNCg0KRnJvbTog cnRjd2ViIFttYWlsdG86cnRjd2ViLWJvdW5jZXNAaWV0Zi5vcmddIE9uIEJlaGFsZiBPZiBleHQg QXN2ZXJlbiwgVG9sZ2ENClNlbnQ6IEZyaWRheSwgSnVseSAzMSwgMjAxNSAxMTo0OSBBTQ0KVG86 IENocmlzdGVyIEhvbG1iZXJnOyBCZXJuYXJkIEFib2JhOyBSb21hbiBTaHBvdW50DQpDYzogPHJ0 Y3dlYkBpZXRmLm9yZzxtYWlsdG86cnRjd2ViQGlldGYub3JnPj4NClN1YmplY3Q6IFJlOiBbcnRj d2ViXSBXaGF0IHRoZSBnYXRld2F5IGRyYWZ0IHNob3VsZCBzYXkgYWJvdXQgbXV4L25vbi1tdXgN Cg0KWWVzLCB5b3UgKmNvdWxkKiBtYW5kYXRlIHRoZSB3aG9sZSB1bml2ZXJzZSB0byBzdXBwb3J0 IGl0LCB0aGF0IHNob3VsZG7igJl0IGJlIHRvbyBkaWZmaWN1bHQgdG8gZGVzY3JpYmUgb24gcGFw ZXIgOy0pDQoNCk9UT0gsIHdoeT8gSWYgdGhlcmUgYXJlIGZvbGtzLCBmb3Igd2hvbSBuby1ydGNw LW11eCBpcyBqdXN0IGZpbmUgKGZvciB3aGF0ZXZlciByZWFzb24pLCBsZXQgdGhlaXIgaW1wbGVt ZW50YXRpb25zIGZ1bmN0aW9uIHRoYXQgd2F5IChhbmQgbGV0IHRoZW0gc3VmZmVyIGlmIHRoaXMg aXMgcmVhbGx5IHN1Y2ggYSB0ZXJyaWJsZSB0aGluZyBmcm9tIGltcGxlbWVudGF0aW9uIGRpZmZp Y3VsdHkgcGVyc3BlY3RpdmUpLiBBbmQgaXQgd2lsbCBiZSB0aGVpciBwcm9ibGVtIGlmIHRoYXQg Y2F1c2VzIGludGVyb3BlcmFiaWxpdHkgaXNzdWVzIGZvciB0aGVtLCBlLmcuIHRoZXkgd29u4oCZ dCBiZSBhYmxlIHRvIHRhbGsgdG8gYnJvd3NlcnMsIHdoaWNoIG1hbmRhdGUgdXNlIG9mIHJ0Y3At bXV4Lg0KDQpCcm93c2VycyAob3IgYW55IG90aGVyIGltcGxlbWVudGF0aW9uKSBhbHdheXMgbWFu ZGF0ZSB1c2Ugb2YgcnRjcC1tdXggYnkgYWx3YXlzIG9mZmVyaW5nIGl0IGFuZCB0ZXJtaW5hdGlu ZyBhIHNlc3Npb24gaWYgdGhlIGFuc3dlciBpbmRpY2F0ZXMgbm8gcnRjcC1tdXggc3VwcG9ydC4g U2ltaWxhcmx5LCB0aGV5IGNhbiByZWplY3Qgb2ZmZXJzIHdpdGggcnRjcC1tdXguDQoNClRoYW5r cywNClRvbGdhDQoNCkZyb206IHJ0Y3dlYiBbbWFpbHRvOnJ0Y3dlYi1ib3VuY2VzQGlldGYub3Jn XSBPbiBCZWhhbGYgT2YgQ2hyaXN0ZXIgSG9sbWJlcmcNClNlbnQ6IEZyaWRheSwgSnVseSAzMSwg MjAxNSAyOjQ0IFBNDQpUbzogQmVybmFyZCBBYm9iYSA8YmVybmFyZC5hYm9iYUBnbWFpbC5jb208 bWFpbHRvOmJlcm5hcmQuYWJvYmFAZ21haWwuY29tPj47IFJvbWFuIFNocG91bnQgPHJvbWFuQHRl bHVyaXguY29tPG1haWx0bzpyb21hbkB0ZWx1cml4LmNvbT4+DQpDYzogPHJ0Y3dlYkBpZXRmLm9y ZzxtYWlsdG86cnRjd2ViQGlldGYub3JnPj4gPHJ0Y3dlYkBpZXRmLm9yZzxtYWlsdG86cnRjd2Vi QGlldGYub3JnPj4NClN1YmplY3Q6IFJlOiBbcnRjd2ViXSBXaGF0IHRoZSBnYXRld2F5IGRyYWZ0 IHNob3VsZCBzYXkgYWJvdXQgbXV4L25vbi1tdXgNCg0KSGksDQoNCklmIHdlIGNob29zZSB0byBt YW5kYXRlIHVzYWdlIG9mIHJ0Y3AtbXV4LCB3ZSBjb3VsZCBhbHNvIG1hbmRhdGUgZ2F0ZXdheXMg dG8gc3VwcG9ydCBpdC4NCg0KUmVnYXJkcywNCg0KQ2hyaXN0ZXINCg0KRnJvbTogcnRjd2ViIFtt YWlsdG86cnRjd2ViLWJvdW5jZXNAaWV0Zi5vcmddIE9uIEJlaGFsZiBPZiBCZXJuYXJkIEFib2Jh DQpTZW50OiAzMSBKdWx5IDIwMTUgMjE6MzINClRvOiBSb21hbiBTaHBvdW50IDxyb21hbkB0ZWx1 cml4LmNvbTxtYWlsdG86cm9tYW5AdGVsdXJpeC5jb20+Pg0KQ2M6IDxydGN3ZWJAaWV0Zi5vcmc8 bWFpbHRvOnJ0Y3dlYkBpZXRmLm9yZz4+IDxydGN3ZWJAaWV0Zi5vcmc8bWFpbHRvOnJ0Y3dlYkBp ZXRmLm9yZz4+DQpTdWJqZWN0OiBSZTogW3J0Y3dlYl0gV2hhdCB0aGUgZ2F0ZXdheSBkcmFmdCBz aG91bGQgc2F5IGFib3V0IG11eC9ub24tbXV4DQoNCk9uIEp1bCAzMSwgMjAxNSwgYXQgMTA6NTcs IFJvbWFuIFNocG91bnQgPHJvbWFuQHRlbHVyaXguY29tPG1haWx0bzpyb21hbkB0ZWx1cml4LmNv bT4+IHdyb3RlOg0KDQpXaHkgd291bGQgdGhlIGdhdGV3YXkgbmVlZCB0byBuZWdvdGlhdGUgbm9u LW11eCBpZiBydGNwLW11eCBpcyBzdXBwb3J0ZWQ/DQoNCltCQV0gSU1ITywgR2F0ZXdheXMgc2hv dWxkIGJlIHJlcXVpcmVkIHRvIHN1cHBvcnQgbXV4IGxpa2UgYW55IG90aGVyIFdFQlJUQyBlbmRw b2ludCwgYnV0IHRoaXMgaXMgbm90IHdoYXQgaXQgc2F5cyBpbiBTZWN0aW9uIDIgb2YgaHR0cHM6 Ly90b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0LWlldGYtcnRjd2ViLWdhdGV3YXlzIDoNCg0KDQoi SWYgYSBnYXRld2F5IHNlcnZlcyBhcyBhIG1lZGlhIHJlbGF5IGludG8gYW5vdGhlciBSVFAgZG9t YWluLCBpdCBNQVkgY2hvb3NlIHRvIHN1cHBvcnQgb25seSBmZWF0dXJlcyBhdmFpbGFibGUgaW4g dGhhdCBuZXR3b3JrLiBUaGlzIG1lYW5zIHRoYXQgaXQgTUFZIGNob29zZSB0byBub3Qgc3VwcG9y dCBCdW5kbGUgYW5kIGFueSBvZiB0aGUgUlRQLyBSVENQIGV4dGVuc2lvbnMgcmVsYXRlZCB0byBp dCwgUlRDUC1NdXgsIG9yIFRyaWNrbGUgSWNlLiBIb3dldmVyLCB0aGUgZ2F0ZXdheSBNVVNUIHN1 cHBvcnQgRFRMUy1TUlRQLCBzaW5jZSB0aGlzIGlzIHJlcXVpcmVkIGZvciBpbnRlcndvcmtpbmcg d2l0aCBXZWJSVEMgZW5kcG9pbnRzLiINCg0KDQpBc3N1bWluZyB0aGF0IGJyb3dzZXJzIHJlbW92 ZSBvciBkbyBub3QgaW1wbGVtZW50IG5vbi1tdXgsIGl0IHNlZW1zIHBydWRlbnQgdG8gcmVxdWly ZSBnYXRld2F5cyB0byBzdXBwb3J0IG11eCBzbyBhcyB0byBhdm9pZCBuZWdvdGlhdGlvbiBmYWls dXJlcy4gSWYgd2UgbWFrZSB0aGF0IGNoYW5nZSB0aGVuIGdhdGV3YXlzIHdvdWxkIGFsd2F5cyBu ZWdvdGlhdGUgUlRDUC1tdXggd2l0aCBicm93c2Vycy4NCg== --_000_786615F3A85DF44AA2A76164A71FE1AC7ADB690DFR711WXCHMBA03z_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTIgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 IkNhbWJyaWEgTWF0aCI7DQoJcGFub3NlLTE6MiA0IDUgMyA1IDQgNiAzIDIgNDt9DQpAZm9udC1m YWNlDQoJe2ZvbnQtZmFtaWx5OkNhbGlicmk7DQoJcGFub3NlLTE6MiAxNSA1IDIgMiAyIDQgMyAy IDQ7fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseTpUYWhvbWE7DQoJcGFub3NlLTE6MiAxMSA2 IDQgMyA1IDQgNCAyIDQ7fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseTpDb25zb2xhczsNCglw YW5vc2UtMToyIDExIDYgOSAyIDIgNCAzIDIgNDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5 OlVJQ1RGb250VGV4dFN0eWxlQm9keTsNCglwYW5vc2UtMTowIDAgMCAwIDAgMCAwIDAgMCAwO30N Ci8qIFN0eWxlIERlZmluaXRpb25zICovDQpwLk1zb05vcm1hbCwgbGkuTXNvTm9ybWFsLCBkaXYu TXNvTm9ybWFsDQoJe21hcmdpbjowY207DQoJbWFyZ2luLWJvdHRvbTouMDAwMXB0Ow0KCWZvbnQt c2l6ZToxMi4wcHQ7DQoJZm9udC1mYW1pbHk6IlRpbWVzIE5ldyBSb21hbiIsInNlcmlmIjt9DQph OmxpbmssIHNwYW4uTXNvSHlwZXJsaW5rDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgljb2xv cjpibHVlOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0KYTp2aXNpdGVkLCBzcGFuLk1z b0h5cGVybGlua0ZvbGxvd2VkDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgljb2xvcjpwdXJw bGU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQpwcmUNCgl7bXNvLXN0eWxlLXByaW9y aXR5Ojk5Ow0KCW1zby1zdHlsZS1saW5rOiJIVE1MIFByZWZvcm1hdHRlZCBDaGFyIjsNCgltYXJn aW46MGNtOw0KCW1hcmdpbi1ib3R0b206LjAwMDFwdDsNCglmb250LXNpemU6MTAuMHB0Ow0KCWZv bnQtZmFtaWx5OiJDb3VyaWVyIE5ldyI7fQ0KcC5Nc29BY2V0YXRlLCBsaS5Nc29BY2V0YXRlLCBk aXYuTXNvQWNldGF0ZQ0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJbXNvLXN0eWxlLWxpbms6 IkJhbGxvb24gVGV4dCBDaGFyIjsNCgltYXJnaW46MGNtOw0KCW1hcmdpbi1ib3R0b206LjAwMDFw dDsNCglmb250LXNpemU6OC4wcHQ7DQoJZm9udC1mYW1pbHk6IlRhaG9tYSIsInNhbnMtc2VyaWYi O30NCnNwYW4uSFRNTFByZWZvcm1hdHRlZENoYXINCgl7bXNvLXN0eWxlLW5hbWU6IkhUTUwgUHJl Zm9ybWF0dGVkIENoYXIiOw0KCW1zby1zdHlsZS1wcmlvcml0eTo5OTsNCgltc28tc3R5bGUtbGlu azoiSFRNTCBQcmVmb3JtYXR0ZWQiOw0KCWZvbnQtZmFtaWx5OkNvbnNvbGFzO30NCnNwYW4uQmFs bG9vblRleHRDaGFyDQoJe21zby1zdHlsZS1uYW1lOiJCYWxsb29uIFRleHQgQ2hhciI7DQoJbXNv LXN0eWxlLXByaW9yaXR5Ojk5Ow0KCW1zby1zdHlsZS1saW5rOiJCYWxsb29uIFRleHQiOw0KCWZv bnQtZmFtaWx5OiJUYWhvbWEiLCJzYW5zLXNlcmlmIjt9DQpzcGFuLkVtYWlsU3R5bGUyMQ0KCXtt c28tc3R5bGUtdHlwZTpwZXJzb25hbDsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsInNhbnMtc2Vy aWYiOw0KCWNvbG9yOiMxRjQ5N0Q7fQ0Kc3Bhbi5FbWFpbFN0eWxlMjINCgl7bXNvLXN0eWxlLXR5 cGU6cGVyc29uYWw7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLCJzYW5zLXNlcmlmIjsNCgljb2xv cjp3aW5kb3d0ZXh0O30NCnNwYW4uRW1haWxTdHlsZTIzDQoJe21zby1zdHlsZS10eXBlOnBlcnNv bmFsOw0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIiwic2Fucy1zZXJpZiI7DQoJY29sb3I6IzFGNDk3 RDt9DQpzcGFuLkVtYWlsU3R5bGUyNA0KCXttc28tc3R5bGUtdHlwZTpwZXJzb25hbDsNCglmb250 LWZhbWlseToiQXJpYWwiLCJzYW5zLXNlcmlmIjsNCgljb2xvcjp3aW5kb3d0ZXh0O30NCnNwYW4u RW1haWxTdHlsZTI1DQoJe21zby1zdHlsZS10eXBlOnBlcnNvbmFsOw0KCWZvbnQtZmFtaWx5OiJD YWxpYnJpIiwic2Fucy1zZXJpZiI7DQoJY29sb3I6IzFGNDk3RDt9DQpzcGFuLkVtYWlsU3R5bGUy Ng0KCXttc28tc3R5bGUtdHlwZTpwZXJzb25hbDsNCglmb250LWZhbWlseToiQXJpYWwiLCJzYW5z LXNlcmlmIjsNCgljb2xvcjp3aW5kb3d0ZXh0O30NCnNwYW4uRW1haWxTdHlsZTI3DQoJe21zby1z dHlsZS10eXBlOnBlcnNvbmFsLXJlcGx5Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIiwic2Fucy1z ZXJpZiI7DQoJY29sb3I6IzFGNDk3RDt9DQouTXNvQ2hwRGVmYXVsdA0KCXttc28tc3R5bGUtdHlw ZTpleHBvcnQtb25seTsNCglmb250LXNpemU6MTAuMHB0O30NCkBwYWdlIFdvcmRTZWN0aW9uMQ0K CXtzaXplOjYxMi4wcHQgNzkyLjBwdDsNCgltYXJnaW46NzIuMHB0IDcyLjBwdCA3Mi4wcHQgNzIu MHB0O30NCmRpdi5Xb3JkU2VjdGlvbjENCgl7cGFnZTpXb3JkU2VjdGlvbjE7fQ0KLS0+PC9zdHls ZT48IS0tW2lmIGd0ZSBtc28gOV0+PHhtbD4NCjxvOnNoYXBlZGVmYXVsdHMgdjpleHQ9ImVkaXQi IHNwaWRtYXg9IjEwMjYiIC8+DQo8L3htbD48IVtlbmRpZl0tLT48IS0tW2lmIGd0ZSBtc28gOV0+ PHhtbD4NCjxvOnNoYXBlbGF5b3V0IHY6ZXh0PSJlZGl0Ij4NCjxvOmlkbWFwIHY6ZXh0PSJlZGl0 IiBkYXRhPSIxIiAvPg0KPC9vOnNoYXBlbGF5b3V0PjwveG1sPjwhW2VuZGlmXS0tPg0KPC9oZWFk Pg0KPGJvZHkgbGFuZz0iRU4tR0IiIGxpbms9ImJsdWUiIHZsaW5rPSJwdXJwbGUiPg0KPGRpdiBj bGFzcz0iV29yZFNlY3Rpb24xIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJm b250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OkNvbnNvbGFzO2NvbG9yOiMxRjQ5N0QiPlRoZSBw cmltYXJ5IGp1c3RpZmljYXRpb24gb2Ygd2VicnRjIGdhdGV3YXlzIGlzIHRvIGluY3JlYXNlIHRo ZSBwcm9wYWJpbGl0eSBvZiBzdWNjZXNzZnVsbHkgZW5kLXRvLWVuZCB3ZWJydGMgY2FsbHM7IC08 bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0i Zm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTpDb25zb2xhcztjb2xvcjojMUY0OTdEIj5iZXR3 ZWVuIHdlYnJ0YyBhbmQgbm9uLXdlYnJ0YyBjbGllbnRzLCBiZXR3ZWVuIHR3byB3ZWJydGMgY2xp ZW50cyB3aXRoIGRpZmZlcmVudCBjYXBhYmlsaXR5IHN1cHBvcnQuPG86cD48L286cD48L3NwYW4+ PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7 Zm9udC1mYW1pbHk6Q29uc29sYXM7Y29sb3I6IzFGNDk3RCI+VGhhdCBzYWlkLCB0aGUgc3VwcG9y dGVkIGNhcGFiaWxpdGllcyBvZiBhIHdlYnJ0YyBnYXRld2F5IHNob3VsZCBub3QgbGVhZCB0byBh biBpbmhlcmVudCByZWR1Y3Rpb24gb2YgdGhlIHN1Y2Nlc3NmdWwgd2VicnRjIGNhbGwgZXN0YWJs aXNobWVudCByYXRlLCBpLmUuLCBub3QgbmVnYXRpdmVseQ0KIGltcGFjdCB0aGUgY2FsbCBjb250 cm9sIGxldmVsIG5lZ290aWF0aW9uIHByb2NlZHVyZXMuPG86cD48L286cD48L3NwYW4+PC9wPg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1m YW1pbHk6Q29uc29sYXM7Y29sb3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9w Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9u dC1mYW1pbHk6Q29uc29sYXM7Y29sb3I6IzFGNDk3RCI+Q29uY2x1c2lvbjogdGhlIHdlYnJ0YyBn YXRld2F5IE1VU1Qgc3VwcG9ydCBSVENQIHRyYW5zcG9ydCBtdWx0aXBsZXhlZCBhbmQgUlRDUCB0 cmFuc3BvcnQgdW5tdWx0aXBsZXhlZCBtb2RlcywgYXMgd2VsbCBhcyB0aGUgaW50ZXJ3b3JraW5n IGJldHdlZW4gYm90aCBtb2Rlcy48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTpDb25zb2xh cztjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTpDb25z b2xhcztjb2xvcjojMUY0OTdEIj5SZWdhcmRzLDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5 OkNvbnNvbGFzO2NvbG9yOiMxRjQ5N0QiPkFsYnJlY2h0PG86cD48L286cD48L3NwYW4+PC9wPg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1m YW1pbHk6Q29uc29sYXM7Y29sb3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9w Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9u dC1mYW1pbHk6Q29uc29sYXM7Y29sb3I6IzFGNDk3RCI+UFM8bzpwPjwvbzpwPjwvc3Bhbj48L3A+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250 LWZhbWlseTpDb25zb2xhcztjb2xvcjojMUY0OTdEIj5XaXRoIHJlZ2FyZHMgdG8gRFRMUy1TUlRQ LCBpLmUuLCB0aGUgRFRMUy1iYXNlZCBrZXkgbWFuYWdlbWVudCBzY2hlbWUgZm9yIFNSVFA6PG86 cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZv bnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6Q29uc29sYXM7Y29sb3I6IzFGNDk3RCI+QSB3ZWJy dGMgZ2F0ZXdheSBtaWdodCBuZWVkIHRvIHN1cHBvcnQgaW50ZXJ3b3JraW5nIGJldHdlZW4gYSB3 ZWJydGMgZG9tYWluIHdpdGggRFRMUy1TUlRQIGFuZCBhIG5vbi13ZWJydGMgZG9tYWluIHdpdGgg U0RFUy1iYXNlZCBrZXkgbWFuYWdlbWVudCBzY2hlbWUsIGkuZS4gYSBzY2VuYXJpbw0KIG9mIHR5 cGUgU1JUUC10by1TUlRQIGludGVyd29ya2luZy4gQnV0IEkgZ3Vlc3MgdGhhdCB1c2UgY2FzZSBp cyBiZXlvbmQgdGhlIElFVEYgZ2F0ZXdheSBkcmFmdC48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZh bWlseTpDb25zb2xhcztjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250 LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6 IzFGNDk3RCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPGRpdj4NCjxkaXYgc3R5bGU9 ImJvcmRlcjpub25lO2JvcmRlci10b3A6c29saWQgI0I1QzRERiAxLjBwdDtwYWRkaW5nOjMuMHB0 IDBjbSAwY20gMGNtIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxiPjxzcGFuIGxhbmc9IkVOLVVT IiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtUYWhvbWEmcXVvdDss JnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+RnJvbTo8L3NwYW4+PC9iPjxzcGFuIGxhbmc9IkVOLVVT IiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtUYWhvbWEmcXVvdDss JnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+IHJ0Y3dlYiBbbWFpbHRvOnJ0Y3dlYi1ib3VuY2VzQGll dGYub3JnXQ0KPGI+T24gQmVoYWxmIE9mIDwvYj5SYXVzY2hlbmJhY2gsIFV3ZSAoTm9raWEgLSBE RS9NdW5pY2gpPGJyPg0KPGI+U2VudDo8L2I+IEZyZWl0YWcsIDMxLiBKdWxpIDIwMTUgMjE6MDg8 YnI+DQo8Yj5Ubzo8L2I+IGV4dCBBc3ZlcmVuLCBUb2xnYTsgQ2hyaXN0ZXIgSG9sbWJlcmc7IEJl cm5hcmQgQWJvYmE7IFJvbWFuIFNocG91bnQ8YnI+DQo8Yj5DYzo8L2I+ICZsdDtydGN3ZWJAaWV0 Zi5vcmcmZ3Q7PGJyPg0KPGI+U3ViamVjdDo8L2I+IFJlOiBbcnRjd2ViXSBXaGF0IHRoZSBnYXRl d2F5IGRyYWZ0IHNob3VsZCBzYXkgYWJvdXQgbXV4L25vbi1tdXg8bzpwPjwvbzpwPjwvc3Bhbj48 L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286 cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZv bnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDssJnF1b3Q7c2Fucy1z ZXJpZiZxdW90OyI+WWVzLCBhZ3JlZWQsIHRoZXNlIGFyZSBpbiB0d28gZGlmZmVyZW50IGNhdGVn b3JpZXMuPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4g bGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0Fy aWFsJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFu PjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9u dC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtBcmlhbCZxdW90OywmcXVvdDtzYW5zLXNl cmlmJnF1b3Q7Ij5SVENQIG11eCBpcyBhbiBvcHRpbWl6YXRpb24g4oCTIG5vdCBzdXBwb3J0aW5n IGl0IGRvdWJsZXMgdGhlIG51bWJlciBvZiBwb3J0cyB0byBiZSB1c2VkLCBhbmQgc2xvd3MgZG93 biBJQ0UgZ2F0aGVyaW5nLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWls eTomcXVvdDtBcmlhbCZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij5XaGVyZWFzIElDRSBu b24tc3VwcG9ydCBpcyBhIHNob3dzdG9wcGVyPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAuMHB0 O2ZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPjxv OnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxh bmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtBcmlh bCZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij5MZXQgbWUgaGF2ZSBzb21lIGludGVybmFs IGRpc2N1c3Npb25zIG9uIHRoaXMgdG9waWMgYW5kIGdldCBiYWNrIHRvIHRoZSBsaXN0IG5leHQg d2Vlay48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBs YW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7QXJp YWwmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+ PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250 LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7LCZxdW90O3NhbnMtc2Vy aWYmcXVvdDsiPktpbmQgcmVnYXJkcyw8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9u dC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+VXdlPG86 cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4t VVMiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxkaXY+DQo8ZGl2IHN0eWxlPSJib3Jk ZXI6bm9uZTtib3JkZXItdG9wOnNvbGlkICNCNUM0REYgMS4wcHQ7cGFkZGluZzozLjBwdCAwY20g MGNtIDBjbSI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48Yj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5 bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7VGFob21hJnF1b3Q7LCZxdW90 O3NhbnMtc2VyaWYmcXVvdDsiPkZyb206PC9zcGFuPjwvYj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5 bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7VGFob21hJnF1b3Q7LCZxdW90 O3NhbnMtc2VyaWYmcXVvdDsiPiBleHQgQXN2ZXJlbiwgVG9sZ2EgWzxhIGhyZWY9Im1haWx0bzp0 YXN2ZXJlbkBzb251c25ldC5jb20iPm1haWx0bzp0YXN2ZXJlbkBzb251c25ldC5jb208L2E+XQ0K PGJyPg0KPGI+U2VudDo8L2I+IEZyaWRheSwgSnVseSAzMSwgMjAxNSAxMjowMyBQTTxicj4NCjxi PlRvOjwvYj4gUmF1c2NoZW5iYWNoLCBVd2UgKE5va2lhIC0gREUvTXVuaWNoKTsgQ2hyaXN0ZXIg SG9sbWJlcmc7IEJlcm5hcmQgQWJvYmE7IFJvbWFuIFNocG91bnQ8YnI+DQo8Yj5DYzo8L2I+ICZs dDs8YSBocmVmPSJtYWlsdG86cnRjd2ViQGlldGYub3JnIj5ydGN3ZWJAaWV0Zi5vcmc8L2E+Jmd0 Ozxicj4NCjxiPlN1YmplY3Q6PC9iPiBSRTogW3J0Y3dlYl0gV2hhdCB0aGUgZ2F0ZXdheSBkcmFm dCBzaG91bGQgc2F5IGFib3V0IG11eC9ub24tbXV4PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9k aXY+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIj48bzpw PiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5n PSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJy aSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPlllcywgY29tcGxl dGVseSBhZ3JlZSBvbiB0aGUg4oCcbmV34oCdIHYucy4g4oCcdGhlIHdheSB0aGluZ3MgdXNlZCB0 byB3b3JrIGZvciBtYW55IHllYXJz4oCdIHBvaW50IGFzIGZhciBhcyBydGNwLW11eCBpcyBjb25j ZXJuZWQuDQo8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3Bh biBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7 Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPjxvOnA+ Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9 IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJp JnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+RnVydGhlcm1vcmUs IC1mb3IgZXhhbXBsZS0sIG5vdCBtYW5kYXRpbmcgSUNFIHdvdWxkIGhhdmUgc2VyaW91cyBpbXBh Y3QgYXMgZmFyIGFzIOKAnG1ha2luZyB0aGluZ3Mgd29yayBmcm9tIGVuZCB1c2VyIHBlcnNwZWN0 aXZl4oCdIGlzIGNvbmNlcm5lZC4NCiBPVE9ILCB0aGUgc2FtZSBkb2VzIG5vdCBuZWNlc3Nhcmls eSBob2xkIHRydWUgZm9yIHJ0Y3AtbXV4LiBUd28gV2ViUlRDIGVsZW1lbnRzLCB3aGljaCBkbyBu b3Qgd2FudCB0byB1c2UgaXQgY2FuIGNvbW11bmljYXRlIHN1Y2Nlc3NmdWxseS48bzpwPjwvbzpw Pjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5 bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVv dDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFu PjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9u dC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMt c2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+VGhhbmtzLDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXpl OjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYm cXVvdDs7Y29sb3I6IzFGNDk3RCI+VG9sZ2E8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7 Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2Nv bG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxkaXYgc3R5bGU9ImJv cmRlcjpub25lO2JvcmRlci1sZWZ0OnNvbGlkIGJsdWUgMS41cHQ7cGFkZGluZzowY20gMGNtIDBj bSA0LjBwdCI+DQo8ZGl2Pg0KPGRpdiBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLXRvcDpzb2xp ZCAjRTFFMUUxIDEuMHB0O3BhZGRpbmc6My4wcHQgMGNtIDBjbSAwY20iPg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+PGI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2Zv bnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+RnJv bTo8L3NwYW4+PC9iPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtm b250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPiBS YXVzY2hlbmJhY2gsIFV3ZSAoTm9raWEgLSBERS9NdW5pY2gpIFs8YSBocmVmPSJtYWlsdG86dXdl LnJhdXNjaGVuYmFjaEBub2tpYS5jb20iPm1haWx0bzp1d2UucmF1c2NoZW5iYWNoQG5va2lhLmNv bTwvYT5dDQo8YnI+DQo8Yj5TZW50OjwvYj4gRnJpZGF5LCBKdWx5IDMxLCAyMDE1IDI6NTggUE08 YnI+DQo8Yj5Ubzo8L2I+IEFzdmVyZW4sIFRvbGdhICZsdDs8YSBocmVmPSJtYWlsdG86dGFzdmVy ZW5Ac29udXNuZXQuY29tIj50YXN2ZXJlbkBzb251c25ldC5jb208L2E+Jmd0OzsgQ2hyaXN0ZXIg SG9sbWJlcmcgJmx0OzxhIGhyZWY9Im1haWx0bzpjaHJpc3Rlci5ob2xtYmVyZ0Blcmljc3Nvbi5j b20iPmNocmlzdGVyLmhvbG1iZXJnQGVyaWNzc29uLmNvbTwvYT4mZ3Q7OyBCZXJuYXJkIEFib2Jh ICZsdDs8YSBocmVmPSJtYWlsdG86YmVybmFyZC5hYm9iYUBnbWFpbC5jb20iPmJlcm5hcmQuYWJv YmFAZ21haWwuY29tPC9hPiZndDs7DQogUm9tYW4gU2hwb3VudCAmbHQ7PGEgaHJlZj0ibWFpbHRv OnJvbWFuQHRlbHVyaXguY29tIj5yb21hbkB0ZWx1cml4LmNvbTwvYT4mZ3Q7PGJyPg0KPGI+Q2M6 PC9iPiAmbHQ7PGEgaHJlZj0ibWFpbHRvOnJ0Y3dlYkBpZXRmLm9yZyI+cnRjd2ViQGlldGYub3Jn PC9hPiZndDsgJmx0OzxhIGhyZWY9Im1haWx0bzpydGN3ZWJAaWV0Zi5vcmciPnJ0Y3dlYkBpZXRm Lm9yZzwvYT4mZ3Q7PGJyPg0KPGI+U3ViamVjdDo8L2I+IFJFOiBbcnRjd2ViXSBXaGF0IHRoZSBn YXRld2F5IGRyYWZ0IHNob3VsZCBzYXkgYWJvdXQgbXV4L25vbi1tdXg8bzpwPjwvbzpwPjwvc3Bh bj48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0i RU4tVVMiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTom cXVvdDtBcmlhbCZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij5XZWxsOiBub24tbXV4IGlz IG5vdCBhIOKAnG5ldyB0aGluZ+KAnSB0aGF0IHdlIG1hbmRhdGUgdGhlIHdob2xlIHVuaXZlcnNl IHRvIHN1cHBvcnQg4oCTIGl0IGlzIG9uIHRoZSBjb250cmFyeSB0aGUgd2F5IFJUQ1AvUlRQIHVz ZWQgdG8gZnVuY3Rpb24gc2luY2UgdGhlIGJlZ2lubmluZy48bzpwPjwvbzpwPjwvc3Bhbj48L3A+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6 ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZx dW90OyI+TVVYaW5nIGlzIHRoZSDigJxuZXcgdGhpbmfigJ0uPG86cD48L286cD48L3NwYW4+PC9w Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNp emU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYm cXVvdDsiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTom cXVvdDtBcmlhbCZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij5PZiBjb3Vyc2UgeW91IGNh biB0YWtlIGF3YXkgbGVnYWN5IHN1cHBvcnQgaWYgbm8tb25lIGlzIGludGVyZXN0ZWQgaW4gc3Vw cG9ydGluZyBpdCBhbnltb3JlLg0KPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQt ZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPjxvOnA+Jm5i c3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVO LVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtBcmlhbCZxdW90 OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij5JIHRoaW5rIHRoaXMgaXMgdGhlIGNvcmUgb2YgdGhl IGRpc2N1c3Npb24gdGhhdCB3ZSBhcmUgaGF2aW5nIOKAkyBkbyB3ZSB3YW50IHRvIHJldGlyZSB0 aGUgb3JpZ2luYWwgd2F5IFJUUCYjNDM7UlRDUCB3ZXJlIHdvcmtpbmcgdy5yLnQuIHBvcnQgdXNh Z2U/DQo8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBs YW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7QXJp YWwmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+SSBoYXZlIG15IGRvdWJ0cyAoZm9yIHRo ZSB0aW1lIGJlaW5nKS48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6 JnF1b3Q7QXJpYWwmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+PG86cD4mbmJzcDs8L286 cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0 eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7LCZxdW90 O3NhbnMtc2VyaWYmcXVvdDsiPktpbmQgcmVnYXJkcyw8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZTox MC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90 OyI+VXdlPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4g bGFuZz0iRU4tVVMiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxkaXY+DQo8ZGl2IHN0 eWxlPSJib3JkZXI6bm9uZTtib3JkZXItdG9wOnNvbGlkICNCNUM0REYgMS4wcHQ7cGFkZGluZzoz LjBwdCAwY20gMGNtIDBjbSI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48Yj48c3BhbiBsYW5nPSJF Ti1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7VGFob21hJnF1 b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPkZyb206PC9zcGFuPjwvYj48c3BhbiBsYW5nPSJF Ti1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7VGFob21hJnF1 b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPiBydGN3ZWIgWzxhIGhyZWY9Im1haWx0bzpydGN3 ZWItYm91bmNlc0BpZXRmLm9yZyI+bWFpbHRvOnJ0Y3dlYi1ib3VuY2VzQGlldGYub3JnPC9hPl0N CjxiPk9uIEJlaGFsZiBPZiA8L2I+ZXh0IEFzdmVyZW4sIFRvbGdhPGJyPg0KPGI+U2VudDo8L2I+ IEZyaWRheSwgSnVseSAzMSwgMjAxNSAxMTo0OSBBTTxicj4NCjxiPlRvOjwvYj4gQ2hyaXN0ZXIg SG9sbWJlcmc7IEJlcm5hcmQgQWJvYmE7IFJvbWFuIFNocG91bnQ8YnI+DQo8Yj5DYzo8L2I+ICZs dDs8YSBocmVmPSJtYWlsdG86cnRjd2ViQGlldGYub3JnIj5ydGN3ZWJAaWV0Zi5vcmc8L2E+Jmd0 Ozxicj4NCjxiPlN1YmplY3Q6PC9iPiBSZTogW3J0Y3dlYl0gV2hhdCB0aGUgZ2F0ZXdheSBkcmFm dCBzaG91bGQgc2F5IGFib3V0IG11eC9ub24tbXV4PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9k aXY+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIj48bzpw PiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5n PSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJy aSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPlllcywgeW91ICo8 Yj5jb3VsZDwvYj4qIG1hbmRhdGUgdGhlIHdob2xlIHVuaXZlcnNlIHRvIHN1cHBvcnQgaXQsIHRo YXQgc2hvdWxkbuKAmXQgYmUgdG9vIGRpZmZpY3VsdCB0byBkZXNjcmliZSBvbiBwYXBlciA7LSk8 bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJF Ti1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZx dW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9v OnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBz dHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZx dW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+T1RPSCwgd2h5PyBJZiB0aGVyZSBh cmUgZm9sa3MsIGZvciB3aG9tIG5vLXJ0Y3AtbXV4IGlzIGp1c3QgZmluZSAoZm9yIHdoYXRldmVy IHJlYXNvbiksIGxldCB0aGVpciBpbXBsZW1lbnRhdGlvbnMgZnVuY3Rpb24gdGhhdCB3YXkgKGFu ZCBsZXQgdGhlbQ0KIHN1ZmZlciBpZiB0aGlzIGlzIHJlYWxseSBzdWNoIGEgdGVycmlibGUgdGhp bmcgZnJvbSBpbXBsZW1lbnRhdGlvbiBkaWZmaWN1bHR5IHBlcnNwZWN0aXZlKS4gQW5kIGl0IHdp bGwgYmUgdGhlaXIgcHJvYmxlbSBpZiB0aGF0IGNhdXNlcyBpbnRlcm9wZXJhYmlsaXR5IGlzc3Vl cyBmb3IgdGhlbSwgZS5nLiB0aGV5IHdvbuKAmXQgYmUgYWJsZSB0byB0YWxrIHRvIGJyb3dzZXJz LCB3aGljaCBtYW5kYXRlIHVzZSBvZiBydGNwLW11eC4NCjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXpl OjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYm cXVvdDs7Y29sb3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTEuMHB0 O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztj b2xvcjojMUY0OTdEIj5Ccm93c2VycyAob3IgYW55IG90aGVyIGltcGxlbWVudGF0aW9uKSBhbHdh eXMgbWFuZGF0ZSB1c2Ugb2YgcnRjcC1tdXggYnkgYWx3YXlzIG9mZmVyaW5nIGl0IGFuZCB0ZXJt aW5hdGluZyBhIHNlc3Npb24gaWYgdGhlIGFuc3dlciBpbmRpY2F0ZXMgbm8NCiBydGNwLW11eCBz dXBwb3J0LiBTaW1pbGFybHksIHRoZXkgY2FuIHJlamVjdCBvZmZlcnMgd2l0aCBydGNwLW11eC4g PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0i RU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkm cXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwv bzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIg c3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90Oywm cXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPlRoYW5rcyw8bzpwPjwvbzpwPjwv c3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9 ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtz YW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPlRvbGdhPG86cD48L286cD48L3NwYW4+PC9w Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNp emU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJp ZiZxdW90Oztjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8ZGl2 IHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItbGVmdDpzb2xpZCBibHVlIDEuNXB0O3BhZGRpbmc6 MGNtIDBjbSAwY20gNC4wcHQiPg0KPGRpdj4NCjxkaXYgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRl ci10b3A6c29saWQgI0UxRTFFMSAxLjBwdDtwYWRkaW5nOjMuMHB0IDBjbSAwY20gMGNtIj4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPjxiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXpl OjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYm cXVvdDsiPkZyb206PC9zcGFuPjwvYj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6 ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlm JnF1b3Q7Ij4gcnRjd2ViIFs8YSBocmVmPSJtYWlsdG86cnRjd2ViLWJvdW5jZXNAaWV0Zi5vcmci Pm1haWx0bzpydGN3ZWItYm91bmNlc0BpZXRmLm9yZzwvYT5dDQo8Yj5PbiBCZWhhbGYgT2YgPC9i PkNocmlzdGVyIEhvbG1iZXJnPGJyPg0KPGI+U2VudDo8L2I+IEZyaWRheSwgSnVseSAzMSwgMjAx NSAyOjQ0IFBNPGJyPg0KPGI+VG86PC9iPiBCZXJuYXJkIEFib2JhICZsdDs8YSBocmVmPSJtYWls dG86YmVybmFyZC5hYm9iYUBnbWFpbC5jb20iPmJlcm5hcmQuYWJvYmFAZ21haWwuY29tPC9hPiZn dDs7IFJvbWFuIFNocG91bnQgJmx0OzxhIGhyZWY9Im1haWx0bzpyb21hbkB0ZWx1cml4LmNvbSI+ cm9tYW5AdGVsdXJpeC5jb208L2E+Jmd0Ozxicj4NCjxiPkNjOjwvYj4gJmx0OzxhIGhyZWY9Im1h aWx0bzpydGN3ZWJAaWV0Zi5vcmciPnJ0Y3dlYkBpZXRmLm9yZzwvYT4mZ3Q7ICZsdDs8YSBocmVm PSJtYWlsdG86cnRjd2ViQGlldGYub3JnIj5ydGN3ZWJAaWV0Zi5vcmc8L2E+Jmd0Ozxicj4NCjxi PlN1YmplY3Q6PC9iPiBSZTogW3J0Y3dlYl0gV2hhdCB0aGUgZ2F0ZXdheSBkcmFmdCBzaG91bGQg c2F5IGFib3V0IG11eC9ub24tbXV4PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8L2Rp dj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIj48bzpwPiZuYnNwOzwv bzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1z aXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2Vy aWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+SGksPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6 JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0Qi PjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFu IHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDss JnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj5JZiB3ZSBjaG9vc2UgdG8gbWFu ZGF0ZSB1c2FnZSBvZiBydGNwLW11eCwgd2UgY291bGQgYWxzbyBtYW5kYXRlIGdhdGV3YXlzIHRv IHN1cHBvcnQgaXQuPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZx dW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9v OnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNp emU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJp ZiZxdW90Oztjb2xvcjojMUY0OTdEIj5SZWdhcmRzLDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFt aWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0 OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48 c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1 b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+Q2hyaXN0ZXI8bzpwPjwv bzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48YSBuYW1lPSJfTWFpbEVuZENv bXBvc2UiPjwvYT48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVv dDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+PG86 cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPGRpdj4NCjxkaXYgc3R5bGU9ImJvcmRlcjpub25l O2JvcmRlci10b3A6c29saWQgI0UxRTFFMSAxLjBwdDtwYWRkaW5nOjMuMHB0IDBjbSAwY20gMGNt Ij4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9u dC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMt c2VyaWYmcXVvdDsiPkZyb206PC9zcGFuPjwvYj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZv bnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5z LXNlcmlmJnF1b3Q7Ij4gcnRjd2ViIFs8YSBocmVmPSJtYWlsdG86cnRjd2ViLWJvdW5jZXNAaWV0 Zi5vcmciPm1haWx0bzpydGN3ZWItYm91bmNlc0BpZXRmLm9yZzwvYT5dDQo8Yj5PbiBCZWhhbGYg T2YgPC9iPkJlcm5hcmQgQWJvYmE8YnI+DQo8Yj5TZW50OjwvYj4gMzEgSnVseSAyMDE1IDIxOjMy PGJyPg0KPGI+VG86PC9iPiBSb21hbiBTaHBvdW50ICZsdDs8YSBocmVmPSJtYWlsdG86cm9tYW5A dGVsdXJpeC5jb20iPnJvbWFuQHRlbHVyaXguY29tPC9hPiZndDs8YnI+DQo8Yj5DYzo8L2I+ICZs dDs8YSBocmVmPSJtYWlsdG86cnRjd2ViQGlldGYub3JnIj5ydGN3ZWJAaWV0Zi5vcmc8L2E+Jmd0 OyAmbHQ7PGEgaHJlZj0ibWFpbHRvOnJ0Y3dlYkBpZXRmLm9yZyI+cnRjd2ViQGlldGYub3JnPC9h PiZndDs8YnI+DQo8Yj5TdWJqZWN0OjwvYj4gUmU6IFtydGN3ZWJdIFdoYXQgdGhlIGdhdGV3YXkg ZHJhZnQgc2hvdWxkIHNheSBhYm91dCBtdXgvbm9uLW11eDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4N CjwvZGl2Pg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwv cD4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5PbiBKdWwgMzEsIDIwMTUsIGF0IDEwOjU3 LCBSb21hbiBTaHBvdW50ICZsdDs8YSBocmVmPSJtYWlsdG86cm9tYW5AdGVsdXJpeC5jb20iPnJv bWFuQHRlbHVyaXguY29tPC9hPiZndDsgd3JvdGU6PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxi bG9ja3F1b3RlIHN0eWxlPSJtYXJnaW4tdG9wOjUuMHB0O21hcmdpbi1ib3R0b206NS4wcHQiPg0K PGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4N CjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPldoeSB3b3VsZCB0aGUgZ2F0ZXdh eSBuZWVkIHRvIG5lZ290aWF0ZSBub24tbXV4IGlmIHJ0Y3AtbXV4IGlzIHN1cHBvcnRlZD8NCjxv OnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwvYmxvY2txdW90ZT4NCjxkaXY+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPltCQV0gSU1ITywgR2F0ZXdheXMgc2hvdWxkIGJlIHJlcXVpcmVk IHRvIHN1cHBvcnQgbXV4IGxpa2UgYW55IG90aGVyIFdFQlJUQyBlbmRwb2ludCwgYnV0IHRoaXMg aXMgbm90IHdoYXQgaXQgc2F5cyBpbiBTZWN0aW9uIDIgb2YNCjxhIGhyZWY9Imh0dHBzOi8vdG9v bHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC1pZXRmLXJ0Y3dlYi1nYXRld2F5cyI+aHR0cHM6Ly90b29s cy5pZXRmLm9yZy9odG1sL2RyYWZ0LWlldGYtcnRjd2ViLWdhdGV3YXlzPC9hPiA6PG86cD48L286 cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwv bzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwcmUgc3R5bGU9InBhZ2UtYnJlYWstYmVmb3JlOmFs d2F5cyI+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O1VJQ1RGb250VGV4dFN0eWxlQm9k eSZxdW90OywmcXVvdDtzZXJpZiZxdW90OyI+JnF1b3Q7SWYgYSBnYXRld2F5IHNlcnZlcyBhcyBh IG1lZGlhIHJlbGF5IGludG8gYW5vdGhlciBSVFAgZG9tYWluLCBpdCBNQVkgY2hvb3NlIHRvIHN1 cHBvcnQgb25seSBmZWF0dXJlcyBhdmFpbGFibGUgaW4gdGhhdCBuZXR3b3JrLiBUaGlzIG1lYW5z IHRoYXQgaXQgTUFZIGNob29zZSB0byBub3Qgc3VwcG9ydCBCdW5kbGUgYW5kIGFueSBvZiB0aGUg UlRQLyBSVENQIGV4dGVuc2lvbnMgcmVsYXRlZCB0byBpdCwgUlRDUC1NdXgsIG9yIFRyaWNrbGUg SWNlLiBIb3dldmVyLCB0aGUgZ2F0ZXdheSBNVVNUIHN1cHBvcnQgRFRMUy1TUlRQLCBzaW5jZSB0 aGlzIGlzIHJlcXVpcmVkIGZvciBpbnRlcndvcmtpbmcgd2l0aCBXZWJSVEMgZW5kcG9pbnRzLiZx dW90Ozwvc3Bhbj48bzpwPjwvbzpwPjwvcHJlPg0KPHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4w cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7VUlDVEZvbnRUZXh0U3R5bGVCb2R5JnF1b3Q7LCZxdW90O3Nl cmlmJnF1b3Q7Ij48YnIgY2xlYXI9ImFsbCIgc3R5bGU9InBhZ2UtYnJlYWstYmVmb3JlOmFsd2F5 cyI+DQo8L3NwYW4+DQo8cHJlIHN0eWxlPSJwYWdlLWJyZWFrLWJlZm9yZTphbHdheXMiPjxzcGFu IHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtVSUNURm9udFRleHRTdHlsZUJvZHkmcXVvdDssJnF1 b3Q7c2VyaWYmcXVvdDsiPkFzc3VtaW5nIHRoYXQgYnJvd3NlcnMgcmVtb3ZlIG9yIGRvIG5vdCBp bXBsZW1lbnQgbm9uLW11eCwgaXQgc2VlbXMgcHJ1ZGVudCB0byByZXF1aXJlIGdhdGV3YXlzIHRv IHN1cHBvcnQgbXV4IHNvIGFzIHRvIGF2b2lkIG5lZ290aWF0aW9uIGZhaWx1cmVzLiBJZiB3ZSBt YWtlIHRoYXQgY2hhbmdlIHRoZW4gZ2F0ZXdheXMgd291bGQgYWx3YXlzIG5lZ290aWF0ZSBSVENQ LW11eCB3aXRoIGJyb3dzZXJzLjwvc3Bhbj48bzpwPjwvbzpwPjwvcHJlPg0KPC9kaXY+DQo8L2Rp dj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2JvZHk+DQo8L2h0bWw+DQo= --_000_786615F3A85DF44AA2A76164A71FE1AC7ADB690DFR711WXCHMBA03z_-- From nobody Mon Aug 3 04:13:36 2015 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7CE0B1A6FEF for ; Mon, 3 Aug 2015 04:13:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.377 X-Spam-Level: X-Spam-Status: No, score=-1.377 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, J_CHICKENPOX_34=0.6, RCVD_IN_DNSWL_LOW=-0.7] 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 pmRTazCN6tar for ; Mon, 3 Aug 2015 04:13:31 -0700 (PDT) Received: from mail-wi0-f173.google.com (mail-wi0-f173.google.com [209.85.212.173]) (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 E77321A86F5 for ; Mon, 3 Aug 2015 04:13:30 -0700 (PDT) Received: by wibud3 with SMTP id ud3so131321568wib.1 for ; Mon, 03 Aug 2015 04:13:29 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type; bh=TC4rozsr3bzX0YIzy5aUgtob3DVsQAjuDsV2IAFnhPw=; b=fdJX0Llc3FNXvuWr8mvlw37zm8oQbg+R/WoLUJGE84OmYt9DQpOib8YB2sN53Lly08 WsI4Lyp/WVgxlKsX2Z7D2YrSVCf8E9zcaugChfvVpjExf0o92j5Xp1W7K2xTEHmOq42M Ke30zLk6OKpMfDKVFqrPsxKywelsw4MiAOU8J72IlRcUSWiHk8KebljwOmgKLJNCRGB7 fTu9zqefxR87xkFliWbK0cZA4CGyTdPWUOwxrgc+TZyrvxTZvxMGVdr0B4aNeXVoCLkG DIs9+5+9v6yDEDs/upLkeEyRqyM3waLm4nmeECoEx7ERyX7jDM7DyuYOEY1vmSy4CzKK YBaQ== X-Gm-Message-State: ALoCoQmf41mCcsA7iQy/R9QokE8b0fAGlUlzBDwoUA6aIhiTXAjL7Ob4yOTbkA9CUDvcQNNOF4r4 X-Received: by 10.180.83.137 with SMTP id q9mr34401645wiy.68.1438600409687; Mon, 03 Aug 2015 04:13:29 -0700 (PDT) MIME-Version: 1.0 Received: by 10.27.85.86 with HTTP; Mon, 3 Aug 2015 04:12:50 -0700 (PDT) In-Reply-To: <786615F3A85DF44AA2A76164A71FE1AC7ADB690D@FR711WXCHMBA03.zeu.alcatel-lucent.com> References: <7594FB04B1934943A5C02806D1A2204B348E29DA@ESESSMB209.ericsson.se> <67196805-ED4E-49EA-83AA-3F4C37B5BC50@gmail.com> <7594FB04B1934943A5C02806D1A2204B348E2D52@ESESSMB209.ericsson.se> <56C2F665D49E0341B9DF5938005ACDF8196FF3ED@DEMUMBX005.nsn-intra.net> <56C2F665D49E0341B9DF5938005ACDF8196FF450@DEMUMBX005.nsn-intra.net> <786615F3A85DF44AA2A76164A71FE1AC7ADB690D@FR711WXCHMBA03.zeu.alcatel-lucent.com> From: Eric Rescorla Date: Mon, 3 Aug 2015 04:12:50 -0700 Message-ID: To: "Schwarz, Albrecht (Albrecht)" Content-Type: multipart/alternative; boundary=f46d0444019664bf27051c66426d Archived-At: Cc: "" Subject: Re: [rtcweb] What the gateway draft should say about mux/non-mux X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 03 Aug 2015 11:13:35 -0000 --f46d0444019664bf27051c66426d Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On Mon, Aug 3, 2015 at 12:19 AM, Schwarz, Albrecht (Albrecht) < albrecht.schwarz@alcatel-lucent.com> wrote: > The primary justification of webrtc gateways is to increase the > propability of successfully end-to-end webrtc calls; - > > between webrtc and non-webrtc clients, between two webrtc clients with > different capability support. > > That said, the supported capabilities of a webrtc gateway should not lead > to an inherent reduction of the successful webrtc call establishment rate= , > i.e., not negatively impact the call control level negotiation procedures= . > > > > Conclusion: the webrtc gateway MUST support RTCP transport multiplexed an= d > RTCP transport unmultiplexed modes, as well as the interworking between > both modes. > I don't see how this conclusion follows. I think this goes back to the question Peter and Cullen have been asking. What concrete scenario (i.e., real equipment) will fail to interoperate if we simple require MUX all the time? -Ekr Regards, > > Albrecht > > > > PS > > With regards to DTLS-SRTP, i.e., the DTLS-based key management scheme for > SRTP: > > A webrtc gateway might need to support interworking between a webrtc > domain with DTLS-SRTP and a non-webrtc domain with SDES-based key > management scheme, i.e. a scenario of type SRTP-to-SRTP interworking. But= I > guess that use case is beyond the IETF gateway draft. > > > > > > *From:* rtcweb [mailto:rtcweb-bounces@ietf.org] *On Behalf Of *Rauschenba= ch, > Uwe (Nokia - DE/Munich) > *Sent:* Freitag, 31. Juli 2015 21:08 > *To:* ext Asveren, Tolga; Christer Holmberg; Bernard Aboba; Roman Shpount > > *Cc:* > *Subject:* Re: [rtcweb] What the gateway draft should say about > mux/non-mux > > > > Yes, agreed, these are in two different categories. > > > > RTCP mux is an optimization =E2=80=93 not supporting it doubles the numbe= r of > ports to be used, and slows down ICE gathering. > > Whereas ICE non-support is a showstopper > > > > Let me have some internal discussions on this topic and get back to the > list next week. > > > > Kind regards, > > Uwe > > > > *From:* ext Asveren, Tolga [mailto:tasveren@sonusnet.com > ] > *Sent:* Friday, July 31, 2015 12:03 PM > *To:* Rauschenbach, Uwe (Nokia - DE/Munich); Christer Holmberg; Bernard > Aboba; Roman Shpount > *Cc:* > *Subject:* RE: [rtcweb] What the gateway draft should say about > mux/non-mux > > > > Yes, completely agree on the =E2=80=9Cnew=E2=80=9D v.s. =E2=80=9Cthe way = things used to work for > many years=E2=80=9D point as far as rtcp-mux is concerned. > > > > Furthermore, -for example-, not mandating ICE would have serious impact a= s > far as =E2=80=9Cmaking things work from end user perspective=E2=80=9D is = concerned. OTOH, > the same does not necessarily hold true for rtcp-mux. Two WebRTC elements= , > which do not want to use it can communicate successfully. > > > > Thanks, > > Tolga > > > > *From:* Rauschenbach, Uwe (Nokia - DE/Munich) [ > mailto:uwe.rauschenbach@nokia.com ] > *Sent:* Friday, July 31, 2015 2:58 PM > *To:* Asveren, Tolga ; Christer Holmberg < > christer.holmberg@ericsson.com>; Bernard Aboba ; > Roman Shpount > *Cc:* > *Subject:* RE: [rtcweb] What the gateway draft should say about > mux/non-mux > > > > Well: non-mux is not a =E2=80=9Cnew thing=E2=80=9D that we mandate the wh= ole universe to > support =E2=80=93 it is on the contrary the way RTCP/RTP used to function= since the > beginning. > > MUXing is the =E2=80=9Cnew thing=E2=80=9D. > > > > Of course you can take away legacy support if no-one is interested in > supporting it anymore. > > > > I think this is the core of the discussion that we are having =E2=80=93 d= o we want > to retire the original way RTP+RTCP were working w.r.t. port usage? > > I have my doubts (for the time being). > > > > Kind regards, > > Uwe > > > > *From:* rtcweb [mailto:rtcweb-bounces@ietf.org ]= *On > Behalf Of *ext Asveren, Tolga > *Sent:* Friday, July 31, 2015 11:49 AM > *To:* Christer Holmberg; Bernard Aboba; Roman Shpount > *Cc:* > *Subject:* Re: [rtcweb] What the gateway draft should say about > mux/non-mux > > > > Yes, you **could** mandate the whole universe to support it, that > shouldn=E2=80=99t be too difficult to describe on paper ;-) > > > > OTOH, why? If there are folks, for whom no-rtcp-mux is just fine (for > whatever reason), let their implementations function that way (and let th= em > suffer if this is really such a terrible thing from implementation > difficulty perspective). And it will be their problem if that causes > interoperability issues for them, e.g. they won=E2=80=99t be able to talk= to > browsers, which mandate use of rtcp-mux. > > > > Browsers (or any other implementation) always mandate use of rtcp-mux by > always offering it and terminating a session if the answer indicates no > rtcp-mux support. Similarly, they can reject offers with rtcp-mux. > > > > Thanks, > > Tolga > > > > *From:* rtcweb [mailto:rtcweb-bounces@ietf.org ]= *On > Behalf Of *Christer Holmberg > *Sent:* Friday, July 31, 2015 2:44 PM > *To:* Bernard Aboba ; Roman Shpount < > roman@telurix.com> > *Cc:* > *Subject:* Re: [rtcweb] What the gateway draft should say about > mux/non-mux > > > > Hi, > > > > If we choose to mandate usage of rtcp-mux, we could also mandate gateways > to support it. > > > > Regards, > > > > Christer > > > > *From:* rtcweb [mailto:rtcweb-bounces@ietf.org ]= *On > Behalf Of *Bernard Aboba > *Sent:* 31 July 2015 21:32 > *To:* Roman Shpount > *Cc:* > *Subject:* Re: [rtcweb] What the gateway draft should say about > mux/non-mux > > > > On Jul 31, 2015, at 10:57, Roman Shpount wrote: > > > > Why would the gateway need to negotiate non-mux if rtcp-mux is supported? > > > > [BA] IMHO, Gateways should be required to support mux like any other > WEBRTC endpoint, but this is not what it says in Section 2 of > https://tools.ietf.org/html/draft-ietf-rtcweb-gateways : > > > > "If a gateway serves as a media relay into another RTP domain, it MAY cho= ose to support only features available in that network. This means that it = MAY choose to not support Bundle and any of the RTP/ RTCP extensions relate= d to it, RTCP-Mux, or Trickle Ice. However, the gateway MUST support DTLS-S= RTP, since this is required for interworking with WebRTC endpoints." > > > Assuming that browsers remove or do not implement non-mux, it seems prude= nt to require gateways to support mux so as to avoid negotiation failures. = If we make that change then gateways would always negotiate RTCP-mux with b= rowsers. > > > _______________________________________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/listinfo/rtcweb > > --f46d0444019664bf27051c66426d Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


On Mon, Aug 3, 2015 at 12:19 AM, Schwarz, Albrecht (Albrecht) <albrecht.schwarz@alcatel-lucent.com> wrote:

The primary justification of webrtc gateways is to increase= the propability of successfully end-to-end webrtc calls; -

between webrtc and non-webrtc clients, between two webrtc c= lients with different capability support.

That said, the supported capabilities of a webrtc gateway s= hould not lead to an inherent reduction of the successful webrtc call estab= lishment rate, i.e., not negatively impact the call control level negotiation procedures.=

=C2=A0

Conclusion: the webrtc gateway MUST support RTCP transport = multiplexed and RTCP transport unmultiplexed modes, as well as the interwor= king between both modes.


=
I don't see how this conclusion follows.=C2=A0

I think this goes back to the question Peter and Cullen have been ask= ing. What
concrete scenario (i.e., real equipment) will fail to i= nteroperate if we simple require
MUX all the time?

=
-Ekr

Regards,

Albrecht

=C2=A0

PS

With regards to DTLS-SRTP, i.e., the DTLS-based key managem= ent scheme for SRTP:

A webrtc gateway might need to support interworking between= a webrtc domain with DTLS-SRTP and a non-webrtc domain with SDES-based key= management scheme, i.e. a scenario of type SRTP-to-SRTP interworking. But I guess that use case is beyond the= IETF gateway draft.

=C2=A0

=C2=A0

From: rtcweb [mailto:rtcweb-bounces@ietf.org] On Behalf Of Rauschenbach, Uwe (Nokia - DE/Munich)
Sent: Freitag, 31. Juli 2015 21:08
To: ext Asveren, Tolga; Christer Holmberg; Bernard Aboba; Roman Shpo= unt


Cc: <rtcweb@= ietf.org>
Subject: Re: [rtcweb] What the gateway draft should say about mux/no= n-mux

=C2=A0

Yes, agreed, these are in = two different categories.

=C2=A0

RTCP mux is an optimizatio= n =E2=80=93 not supporting it doubles the number of ports to be used, and s= lows down ICE gathering.

Whereas ICE non-support is= a showstopper

=C2=A0

Let me have some internal = discussions on this topic and get back to the list next week.=

=C2=A0

Kind regards,

Uwe

=C2=A0

From: ext Asveren, Tolga [mailto:tasveren@sonusnet.com]
Sent: Friday, July 31, 2015 12:03 PM
To: Rauschenbach, Uwe (Nokia - DE/Munich); Christer Holmberg; Bernar= d Aboba; Roman Shpount
Cc: <rtcweb@= ietf.org>
Subject: RE: [rtcweb] What the gateway draft should say about mux/no= n-mux

=C2=A0

Yes, compl= etely agree on the =E2=80=9Cnew=E2=80=9D v.s. =E2=80=9Cthe way things used = to work for many years=E2=80=9D point as far as rtcp-mux is concerned.

=C2= =A0

Furthermor= e, -for example-, not mandating ICE would have serious impact as far as =E2= =80=9Cmaking things work from end user perspective=E2=80=9D is concerned. OTOH, the same does not necessarily hold true for rtcp-mux. Two WebRTC ele= ments, which do not want to use it can communicate successfully.<= /u>

=C2= =A0

Thanks,=

Tolga

=C2= =A0

From: Rauschenbach, Uwe (Nokia - DE/Munich) [mailto:uwe.rauschenbach= @nokia.com]
Sent: Friday, July 31, 2015 2:58 PM
To: Asveren, Tolga <tasveren@sonusnet.com>; Christer Holmberg <christer.holmb= erg@ericsson.com>; Bernard Aboba <bernard.aboba@gmail.com>; Roman Shpount <r= oman@telurix.com>
Cc: <rtcweb@= ietf.org> <r= tcweb@ietf.org>
Subject: RE: [rtcweb] What the gateway draft should say about mux/no= n-mux

=C2=A0

Well: non-mux is not a =E2= =80=9Cnew thing=E2=80=9D that we mandate the whole universe to support =E2= =80=93 it is on the contrary the way RTCP/RTP used to function since the be= ginning.

MUXing is the =E2=80=9Cnew= thing=E2=80=9D.

=C2=A0

Of course you can take awa= y legacy support if no-one is interested in supporting it anymore.

=C2=A0

I think this is the core o= f the discussion that we are having =E2=80=93 do we want to retire the orig= inal way RTP+RTCP were working w.r.t. port usage?

I have my doubts (for the = time being).

=C2=A0

Kind regards,

Uwe

=C2=A0

From: rtcweb [mailto:rtcweb-bounces@ietf.org] On Behalf Of ext Asveren, Tolga
Sent: Friday, July 31, 2015 11:49 AM
To: Christer Holmberg; Bernard Aboba; Roman Shpount
Cc: <rtcweb@= ietf.org>
Subject: Re: [rtcweb] What the gateway draft should say about mux/no= n-mux

=C2=A0

Yes, you *= could* mandate the whole universe to support it, that shouldn=E2=80= =99t be too difficult to describe on paper ;-)

=C2= =A0

OTOH, why?= If there are folks, for whom no-rtcp-mux is just fine (for whatever reason= ), let their implementations function that way (and let them suffer if this is really such a terrible thing from implementation difficu= lty perspective). And it will be their problem if that causes interoperabil= ity issues for them, e.g. they won=E2=80=99t be able to talk to browsers, w= hich mandate use of rtcp-mux.

=C2= =A0

Browsers (= or any other implementation) always mandate use of rtcp-mux by always offer= ing it and terminating a session if the answer indicates no rtcp-mux support. Similarly, they can reject offers with rtcp-mux. =

=C2= =A0

Thanks,=

Tolga

=C2= =A0

From: rtcweb [mailto:rtcweb-bounces@ietf.org] On Behalf Of Christer Holmberg
Sent: Friday, July 31, 2015 2:44 PM
To: Bernard Aboba <bernard.aboba@gmail.com>; Roman Shpount <roman@telurix.com> Cc: <rtcweb@= ietf.org> <r= tcweb@ietf.org>
Subject: Re: [rtcweb] What the gateway draft should say about mux/no= n-mux

=C2=A0

Hi,<= /p>

=C2=A0

If we choose to mandate u= sage of rtcp-mux, we could also mandate gateways to support it.

=C2=A0

Regards,

=C2=A0

Christer

=C2=A0

From: rtcweb [mailto:rtcweb-bounces@ietf.org] On Behalf Of Bernard Aboba
Sent: 31 July 2015 21:32
To: Roman Shpount <roman@telurix.com>
Cc: <rtcweb@= ietf.org> <r= tcweb@ietf.org>
Subject: Re: [rtcweb] What the gateway draft should say about mux/no= n-mux

=C2=A0

On Jul 31, 2015, at 10:57, Roman Shpount <roman@telurix.com> w= rote:

=C2=A0

Why would the gateway need to negotiate non-mux if r= tcp-mux is supported?

=C2=A0

[BA] IMHO, Gateways should be required to support mu= x like any other WEBRTC endpoint, but this is not what it says in Section 2= of https://tools.ietf.org/html/draft-ietf-rtcweb-gateways :=

=C2=A0

"If a gateway serves as a media relay into another RTP domai=
n, it MAY choose to support only features available in that network. This m=
eans that it MAY choose to not support Bundle and any of the RTP/ RTCP exte=
nsions related to it, RTCP-Mux, or Trickle Ice. However, the gateway MUST s=
upport DTLS-SRTP, since this is required for interworking with WebRTC endpo=
ints."

 
Assuming that browsers remove or do not implement non-mux, it see=
ms prudent to require gateways to support mux so as to avoid negotiation fa=
ilures. If we make that change then gateways would always negotiate RTCP-mu=
x with browsers.

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


--f46d0444019664bf27051c66426d-- From nobody Mon Aug 3 08:25:05 2015 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7DD061A9091 for ; Mon, 3 Aug 2015 08:25:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CTTxI8MZAB3X for ; Mon, 3 Aug 2015 08:24:58 -0700 (PDT) Received: from mail-pa0-x229.google.com (mail-pa0-x229.google.com [IPv6:2607:f8b0:400e:c03::229]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A9B911A9067 for ; Mon, 3 Aug 2015 08:24:56 -0700 (PDT) Received: by padck2 with SMTP id ck2so92442307pad.0 for ; Mon, 03 Aug 2015 08:24:56 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=content-type:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=JjW/pYTPdsBbPw3/b9uVS1LNZB6YLNMmtd1lpW/VpFM=; b=klbOriuYRG/a7CyjyrqhOdVIIOJp6KPA1+xMVUygiQeu+Pw2SYMwvIdwGYv3N3Y11m tx7H2ER/X85UJA870W4fgXWIAM+0/BnefNhZ66ZOUN+2OL7oCasXaaYXNXKTM/sdntCV ys5VN+rV+2hqCTlustIsS5eTwM/zMRt9XTmCeXYRRgbR6dcFH3UzBPlRnRHFQd9ULXbb 54LlgdstrjeY2kYxec/sh55Hcwj6hy8EBDcE1PuUYAr//h4+QLgmgOmkb04gKQozPFJt SGgtZVRP5D2uWfdMgIA02dLvrIp+TjfBoIhteIJGLZ415yST6TBOcMdFF0RG8zxkXWnX sOHA== X-Received: by 10.66.183.10 with SMTP id ei10mr21226311pac.10.1438615496293; Mon, 03 Aug 2015 08:24:56 -0700 (PDT) Received: from [192.168.1.110] (c-71-227-237-49.hsd1.wa.comcast.net. [71.227.237.49]) by smtp.gmail.com with ESMTPSA id wc8sm17951736pab.45.2015.08.03.08.24.54 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Mon, 03 Aug 2015 08:24:55 -0700 (PDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (1.0) From: Bernard Aboba X-Mailer: iPad Mail (12H143) In-Reply-To: Date: Mon, 3 Aug 2015 08:24:53 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <0D57A303-5917-4829-BDC7-F4345881F783@gmail.com> References: <7594FB04B1934943A5C02806D1A2204B348E29DA@ESESSMB209.ericsson.se> <67196805-ED4E-49EA-83AA-3F4C37B5BC50@gmail.com> <7594FB04B1934943A5C02806D1A2204B348E2D52@ESESSMB209.ericsson.se> <56C2F665D49E0341B9DF5938005ACDF8196FF3ED@DEMUMBX005.nsn-intra.net> <56C2F665D49E0341B9DF5938005ACDF8196FF450@DEMUMBX005.nsn-intra.net> <786615F3A85DF44AA2A76164A71FE1AC7ADB690D@FR711WXCHMBA03.zeu.alcatel-lucent.com> To: Eric Rescorla Archived-At: Cc: "" Subject: Re: [rtcweb] What the gateway draft should say about mux/non-mux X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 03 Aug 2015 15:25:03 -0000 On Aug 3, 2015, at 04:12, Eric Rescorla wrote: > I don't see how this conclusion follows.=20 [BA] It is logical that a gateway needs to support both WEBRTC endpoints an= d non-WEBRTC endpoints. However, it does not follow that WEBRTC endpoints sh= ould be required to support features of non-WEBRTC endpoints (e.g. like non-= mux or SRTP/SDES).=20 > I think this goes back to the question Peter and Cullen have been asking. W= hat > concrete scenario (i.e., real equipment) will fail to interoperate if we s= imply require > MUX all the time? [BA] =46rom what I can tell, none. The gateway can speak mux to WEBRTC endpo= ints and non-mux to legacy.=20 From nobody Mon Aug 3 10:47:25 2015 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 75FF81B2D65 for ; Mon, 3 Aug 2015 10:47:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MfNQZ65GtHQz for ; Mon, 3 Aug 2015 10:47:20 -0700 (PDT) Received: from na01-by2-obe.outbound.protection.outlook.com (mail-by2on0071.outbound.protection.outlook.com [207.46.100.71]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 95C9E1B2D64 for ; Mon, 3 Aug 2015 10:47:20 -0700 (PDT) Received: from SN1PR0301MB1551.namprd03.prod.outlook.com (10.162.129.157) by SN1PR0301MB1551.namprd03.prod.outlook.com (10.162.129.157) with Microsoft SMTP Server (TLS) id 15.1.225.19; Mon, 3 Aug 2015 17:47:18 +0000 Received: from SN1PR0301MB1551.namprd03.prod.outlook.com ([10.162.129.157]) by SN1PR0301MB1551.namprd03.prod.outlook.com ([10.162.129.157]) with mapi id 15.01.0225.018; Mon, 3 Aug 2015 17:47:17 +0000 From: "Asveren, Tolga" To: Bernard Aboba , Eric Rescorla Thread-Topic: [rtcweb] What the gateway draft should say about mux/non-mux Thread-Index: AQHQy8DcUgzWwtVCmk+8q67BCzjC45316kQQgAAD5oCAAACVsIAAAj2AgAPw2gCAAEFTAIAARmyAgAAi5WA= Date: Mon, 3 Aug 2015 17:47:17 +0000 Message-ID: References: <7594FB04B1934943A5C02806D1A2204B348E29DA@ESESSMB209.ericsson.se> <67196805-ED4E-49EA-83AA-3F4C37B5BC50@gmail.com> <7594FB04B1934943A5C02806D1A2204B348E2D52@ESESSMB209.ericsson.se> <56C2F665D49E0341B9DF5938005ACDF8196FF3ED@DEMUMBX005.nsn-intra.net> <56C2F665D49E0341B9DF5938005ACDF8196FF450@DEMUMBX005.nsn-intra.net> <786615F3A85DF44AA2A76164A71FE1AC7ADB690D@FR711WXCHMBA03.zeu.alcatel-lucent.com> <0D57A303-5917-4829-BDC7-F4345881F783@gmail.com> In-Reply-To: <0D57A303-5917-4829-BDC7-F4345881F783@gmail.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=tasveren@sonusnet.com; x-originating-ip: [50.182.164.80] x-microsoft-exchange-diagnostics: 1; SN1PR0301MB1551; 5:x339m4W0/zuyHJmFgIFvIb7PkLm43Zxy+L1V5/Vj4t05HTQX6zM9NZA7d9C7/tA+wnGqi9Z991aI5TKtKOqVsea725Yjodu1VZlZT2p3/1bT6824dXUL/iqDhUozZNZIhrOZhXgxbYio1CaSej0MgA==; 24:mBjmhdlxhodlDZw9ZdFh1XlF6X8noGK3zen7OJUzfzN2EyOjLdxISu2YnPh0+i9yEPCrBe9qIetkZ+BXT0GTcpmn/1AxBOLmvNO4pAZ+ybI=; 20:ZwxTGBnb1ImXplx2u6RelztFJPZFaLazsJL2uePbbwwqmdZc9KWWJeuIchJPI3TxYTZ8CSFje2/IdfCNn35XMQ== x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:SN1PR0301MB1551; sn1pr0301mb1551: X-MS-Exchange-Organization-RulesExecuted x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:; x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(601004)(5005006)(3002001); SRVR:SN1PR0301MB1551; BCL:0; PCL:0; RULEID:; SRVR:SN1PR0301MB1551; x-forefront-prvs: 0657D528EC x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(6009001)(13464003)(189002)(199003)(377454003)(24454002)(164054003)(46102003)(64706001)(68736005)(33656002)(5001860100001)(5001960100002)(77156002)(122556002)(5003600100002)(5001770100001)(86362001)(97736004)(101416001)(5001830100001)(189998001)(4001540100001)(19580405001)(106356001)(74316001)(87936001)(2900100001)(76176999)(76576001)(50986999)(105586002)(81156007)(19580395003)(77096005)(2656002)(5002640100001)(2950100001)(99286002)(54356999)(93886004)(92566002)(62966003)(102836002)(40100003)(106116001)(66066001); DIR:OUT; SFP:1101; SCL:1; SRVR:SN1PR0301MB1551; H:SN1PR0301MB1551.namprd03.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; MX:1; A:1; LANG:en; received-spf: None (protection.outlook.com: sonusnet.com does not designate permitted sender hosts) Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: sonusnet.com X-MS-Exchange-CrossTenant-originalarrivaltime: 03 Aug 2015 17:47:17.6447 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 29a671dc-ed7e-4a54-b1e5-8da1eb495dc3 X-MS-Exchange-Transport-CrossTenantHeadersStamped: SN1PR0301MB1551 Archived-At: Cc: "" Subject: Re: [rtcweb] What the gateway draft should say about mux/non-mux X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 03 Aug 2015 17:47:23 -0000 There are/will be deployment models, where WebRTC is used as a "Real Time C= ommunication Profile" with endpoints as native applications rather than bro= wsers ( I am not arguing/advocating that this interpretation/use of WebRTC = specifications is completely kosher). In such environments, certain charact= eristics/capabilities/expectations will be a bit different than the "tradit= ional" WebRTC use with browsers+Internet. So, a gateway, which is purpose-b= uilt for such specific deployments may not need to interwork with browsers.= If it needs, it needs to support rtcp-mux. I think a "SHOULD" strength statement for gateway rtcp-mux support with som= e explanation about the rationale behind it could be a good path forward. Thanks, Tolga > -----Original Message----- > From: Bernard Aboba [mailto:bernard.aboba@gmail.com] > Sent: Monday, August 03, 2015 11:25 AM > To: Eric Rescorla > Cc: Schwarz, Albrecht (Albrecht) ; > Rauschenbach, Uwe (Nokia - DE/Munich) ; > Asveren, Tolga ; Christer Holmberg > ; Roman Shpount ; > > Subject: Re: [rtcweb] What the gateway draft should say about mux/non- > mux >=20 > On Aug 3, 2015, at 04:12, Eric Rescorla wrote: > > I don't see how this conclusion follows. >=20 >=20 > [BA] It is logical that a gateway needs to support both WEBRTC endpoints > and non-WEBRTC endpoints. However, it does not follow that WEBRTC > endpoints should be required to support features of non-WEBRTC endpoints > (e.g. like non-mux or SRTP/SDES). >=20 > > I think this goes back to the question Peter and Cullen have been > > asking. What concrete scenario (i.e., real equipment) will fail to > > interoperate if we simply require MUX all the time? >=20 > [BA] From what I can tell, none. The gateway can speak mux to WEBRTC > endpoints and non-mux to legacy. >=20 From nobody Mon Aug 3 11:45:51 2015 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 210301B2FF9 for ; Mon, 3 Aug 2015 11:45:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.978 X-Spam-Level: X-Spam-Status: No, score=-1.978 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, 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 8ViH0CSgwKI0 for ; Mon, 3 Aug 2015 11:45:49 -0700 (PDT) Received: from mail-ig0-f174.google.com (mail-ig0-f174.google.com [209.85.213.174]) (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 E6F761B2FF8 for ; Mon, 3 Aug 2015 11:45:48 -0700 (PDT) Received: by igk11 with SMTP id 11so77847591igk.1 for ; Mon, 03 Aug 2015 11:45:48 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=/xG0ygz/crM8B4qTyUx32VvnGqP02NwjJe/57j9N5ow=; b=Sw4/IkyEHwtMYGWwze0p4XmkXtCYOYCqshZv78WlHPAa23zpSzx701NH+B/5FYta0e TVAedVtcY7wXykFY8uN5vpzCljJhosEVlHhEV9FgfgDszLUOJo1+cbis1BHfT5dATNR6 txgQIZjN57Mwj0orXvkaM+vCp8fx/9mCjFAwKTRfDjfwKLQSUkx4xdXV293nCGzZ6dBa XJk0XEkY+74uJeHE0Dm2d8czpiUXqLc32fxUTwNAAs67HN81bs/7tZtGDIkRTfGCsrTV YtGa44nt4LGlAmwCY7yrvO6giJQe6XQXg3fSBhIfSxIqHxQfTmCPKwponhjesLziyQHc dOuQ== X-Gm-Message-State: ALoCoQn/+r05KimIwjaI5N2nsBAEEe9MGFj9dczi4SJ2/6aLtAaHmda8g4iXAR1syYhK55K1PpNM X-Received: by 10.50.225.65 with SMTP id ri1mr23209296igc.47.1438627548250; Mon, 03 Aug 2015 11:45:48 -0700 (PDT) Received: from mail-ig0-f181.google.com (mail-ig0-f181.google.com. [209.85.213.181]) by smtp.gmail.com with ESMTPSA id m134sm9634609ioe.42.2015.08.03.11.45.46 for (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 03 Aug 2015 11:45:48 -0700 (PDT) Received: by igbpg9 with SMTP id pg9so61680772igb.0 for ; Mon, 03 Aug 2015 11:45:46 -0700 (PDT) MIME-Version: 1.0 X-Received: by 10.50.61.179 with SMTP id q19mr23217165igr.24.1438627546145; Mon, 03 Aug 2015 11:45:46 -0700 (PDT) Received: by 10.36.89.70 with HTTP; Mon, 3 Aug 2015 11:45:45 -0700 (PDT) In-Reply-To: References: <7594FB04B1934943A5C02806D1A2204B348E29DA@ESESSMB209.ericsson.se> <67196805-ED4E-49EA-83AA-3F4C37B5BC50@gmail.com> <7594FB04B1934943A5C02806D1A2204B348E2D52@ESESSMB209.ericsson.se> <56C2F665D49E0341B9DF5938005ACDF8196FF3ED@DEMUMBX005.nsn-intra.net> <56C2F665D49E0341B9DF5938005ACDF8196FF450@DEMUMBX005.nsn-intra.net> <786615F3A85DF44AA2A76164A71FE1AC7ADB690D@FR711WXCHMBA03.zeu.alcatel-lucent.com> <0D57A303-5917-4829-BDC7-F4345881F783@gmail.com> Date: Mon, 3 Aug 2015 14:45:45 -0400 Message-ID: From: Roman Shpount To: "Asveren, Tolga" Content-Type: multipart/alternative; boundary=047d7bdc109eda2dfe051c6c93c8 Archived-At: Cc: "" Subject: Re: [rtcweb] What the gateway draft should say about mux/non-mux X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 03 Aug 2015 18:45:50 -0000 --047d7bdc109eda2dfe051c6c93c8 Content-Type: text/plain; charset=UTF-8 I think offering rtcp-mux and accepting rtcp-mux if offered should be a MUST for WebRTC gateways. The gateway MAY accept offers or handle answers without rtcp-mux, if it is needed for the particular deployment scenario. _____________ Roman Shpount --047d7bdc109eda2dfe051c6c93c8 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
I think offering rtcp-mux and accepting rtcp-mux if offere= d should be a MUST for WebRTC gateways. The gateway MAY accept offers or ha= ndle answers without rtcp-mux, if it is needed for the particular deploymen= t scenario.
_____________
Roman Shpount

--047d7bdc109eda2dfe051c6c93c8-- From nobody Mon Aug 3 11:52:14 2015 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 95FA41B3048 for ; Mon, 3 Aug 2015 11:52:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id med_AErl7LgU for ; Mon, 3 Aug 2015 11:52:11 -0700 (PDT) Received: from mail-wi0-x230.google.com (mail-wi0-x230.google.com [IPv6:2a00:1450:400c:c05::230]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 284C51B3045 for ; Mon, 3 Aug 2015 11:52:11 -0700 (PDT) Received: by wibud3 with SMTP id ud3so147739806wib.1 for ; Mon, 03 Aug 2015 11:52:10 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=vN1awluOWT3ewezabI5DVFt+iCzW0vb19AJ/MeLBvDc=; b=y13Dm4dX4fxQO8aD/hbIeRak3+NOt1Oyt/xGzn9M3LxJT/WO0IwHq/k/FkxELxeGm8 JMM5/9wQumNF7e0MsnZeGXYvOkmSBMIJlGa/mSMTqp8Dl8tBRgZU9n4IoiTq2RXwdkwx +6H89CyPK6r4yZyVIgtPVgyBzvjmAH29znhVtfik1j1tcyagmWB+8xnopBW877noPsfq tLFfL8PfK06dTW9C2o4kMyJwHBupdFfx1b1nBvFa6DX0s248gQ4qC3acbrZqpp8t0l5t 46At4Z5haxu3QwThDazJRKxQcl7YCdCSiEVvfnZeezu/9aG6iWGVd3w+ZsmQnJT14fe/ CMWw== X-Received: by 10.180.107.34 with SMTP id gz2mr24267421wib.77.1438627929954; Mon, 03 Aug 2015 11:52:09 -0700 (PDT) MIME-Version: 1.0 Received: by 10.27.24.88 with HTTP; Mon, 3 Aug 2015 11:51:50 -0700 (PDT) In-Reply-To: References: <7594FB04B1934943A5C02806D1A2204B348E29DA@ESESSMB209.ericsson.se> <67196805-ED4E-49EA-83AA-3F4C37B5BC50@gmail.com> <7594FB04B1934943A5C02806D1A2204B348E2D52@ESESSMB209.ericsson.se> <56C2F665D49E0341B9DF5938005ACDF8196FF3ED@DEMUMBX005.nsn-intra.net> <56C2F665D49E0341B9DF5938005ACDF8196FF450@DEMUMBX005.nsn-intra.net> <786615F3A85DF44AA2A76164A71FE1AC7ADB690D@FR711WXCHMBA03.zeu.alcatel-lucent.com> <0D57A303-5917-4829-BDC7-F4345881F783@gmail.com> From: Bernard Aboba Date: Mon, 3 Aug 2015 11:51:50 -0700 Message-ID: To: "Asveren, Tolga" Content-Type: multipart/alternative; boundary=e89a8f235697ba9e92051c6caa81 Archived-At: Cc: "" Subject: Re: [rtcweb] What the gateway draft should say about mux/non-mux X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 03 Aug 2015 18:52:13 -0000 --e89a8f235697ba9e92051c6caa81 Content-Type: text/plain; charset=UTF-8 Some mobile applications do not care about interoperating with browsers, only interoperating with their own backend infrastructure and the same application running on other mobile platforms. Those applications can customize the WebRTC stack significantly, adding or removing functionality such as RTP/RTCP features, codecs, transports, etc. without having to test interoperability with browsers. Although this kind of customization occurs very frequently today, it isn't that relevant to the IETF RTCWEB specifications which apply to browser implementations and gateways that support browser implementations. Just as a mobile application can deviate from the WebRTC specifications, a gateway developed for that application may not conform to the WebRTC gateway specification either. Cataloging every way that non-compliant implementations can deviate is a potentially endless task. On Mon, Aug 3, 2015 at 10:47 AM, Asveren, Tolga wrote: > There are/will be deployment models, where WebRTC is used as a "Real Time > Communication Profile" with endpoints as native applications rather than > browsers ( I am not arguing/advocating that this interpretation/use of > WebRTC specifications is completely kosher). In such environments, certain > characteristics/capabilities/expectations will be a bit different than the > "traditional" WebRTC use with browsers+Internet. So, a gateway, which is > purpose-built for such specific deployments may not need to interwork with > browsers. If it needs, it needs to support rtcp-mux. > > I think a "SHOULD" strength statement for gateway rtcp-mux support with > some explanation about the rationale behind it could be a good path forward. > > Thanks, > Tolga > > > -----Original Message----- > > From: Bernard Aboba [mailto:bernard.aboba@gmail.com] > > Sent: Monday, August 03, 2015 11:25 AM > > To: Eric Rescorla > > Cc: Schwarz, Albrecht (Albrecht) ; > > Rauschenbach, Uwe (Nokia - DE/Munich) ; > > Asveren, Tolga ; Christer Holmberg > > ; Roman Shpount ; > > > > Subject: Re: [rtcweb] What the gateway draft should say about mux/non- > > mux > > > > On Aug 3, 2015, at 04:12, Eric Rescorla wrote: > > > I don't see how this conclusion follows. > > > > > > [BA] It is logical that a gateway needs to support both WEBRTC endpoints > > and non-WEBRTC endpoints. However, it does not follow that WEBRTC > > endpoints should be required to support features of non-WEBRTC endpoints > > (e.g. like non-mux or SRTP/SDES). > > > > > I think this goes back to the question Peter and Cullen have been > > > asking. What concrete scenario (i.e., real equipment) will fail to > > > interoperate if we simply require MUX all the time? > > > > [BA] From what I can tell, none. The gateway can speak mux to WEBRTC > > endpoints and non-mux to legacy. > > > > --e89a8f235697ba9e92051c6caa81 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Some mobile applications=C2=A0do not care about inter= operating with browsers, only interoperating with their own backend infrast= ructure and the same application running on=C2=A0other mobile platforms.=C2= =A0=C2=A0Those applications can customize the WebRTC stack significantly, a= dding or removing functionality such as RTP/RTCP features, codecs, transpor= ts, etc.=C2=A0without having to test interoperability with browsers.=C2=A0 =

Although this kind of customization occurs very f= requently today, it isn't=C2=A0that relevant to the IETF RTCWEB specifi= cations=C2=A0which apply to browser implementations=C2=A0and gateways that = support=C2=A0browser implementations.=C2=A0 Just as a mobile application ca= n deviate from the WebRTC specifications, a gateway developed=C2=A0for that= application may not conform to the WebRTC gateway specification either.=C2= =A0 Cataloging every way that non-compliant implementations can deviate is = a potentially endless task.
=C2=A0

On Mon, Aug 3, 2015 at 10:47 AM, A= sveren, Tolga <tasveren@sonusnet.com> wrote:
There are/will be deployment models, where WebRTC is= used as a "Real Time Communication Profile" with endpoints as na= tive applications rather than browsers ( I am not arguing/advocating that t= his interpretation/use of WebRTC specifications is completely kosher). In s= uch environments, certain characteristics/capabilities/expectations will be= a bit different than the "traditional" WebRTC use with browsers+= Internet. So, a gateway, which is purpose-built for such specific deploymen= ts may not need to interwork with browsers. If it needs, it needs to suppor= t rtcp-mux.

I think a "SHOULD" strength statement for gateway rtcp-mux suppor= t with some explanation about the rationale behind it could be a good path = forward.

Thanks,
Tolga

> -----Original Message-----
> From: Bernard Aboba [mailto:bernard.aboba@gmail.com]
> Sent: Monday, August 03, 2015 11:25 AM
> To: Eric Rescorla <ekr@rtfm.com= >
> Cc: Schwarz, Albrecht (Albrecht) <albrecht.schwarz@alcatel-lucent.com>;
> Rauschenbach, Uwe (Nokia - DE/Munich) <uwe.rauschenbach@nokia.com>;
> Asveren, Tolga <tasveren@s= onusnet.com>; Christer Holmberg
> <christer.holmberg@ericsson.com>; Roman Shpount <= roman@telurix.com>;
> <rtcweb@ietf.org> <rtcweb@ietf.org>
> Subject: Re: [rtcweb] What the gateway draft should say about mux/non-=
> mux
>
> On Aug 3, 2015, at 04:1= 2, Eric Rescorla <ekr@rtfm.com> w= rote:
> > I don't see how this conclusion follows.
>
>
> [BA]=C2=A0 It is logical that a gateway needs to support both WEBRTC e= ndpoints
> and non-WEBRTC endpoints. However, it does not follow that WEBRTC
> endpoints should be required to support features of non-WEBRTC endpoin= ts
> (e.g. like non-mux or SRTP/SDES).
>
> > I think this goes back to the question Peter and Cullen have been=
> > asking. What concrete scenario (i.e., real equipment) will fail t= o
> > interoperate if we simply require MUX all the time?
>
> [BA] From what I can tell, none. The gateway can speak mux to WEBRTC > endpoints and non-mux to legacy.
>


--e89a8f235697ba9e92051c6caa81-- From nobody Mon Aug 3 16:21:55 2015 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 627EE1B29C4 for ; Mon, 3 Aug 2015 16:21:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bkdwGASLIEen for ; Mon, 3 Aug 2015 16:21:51 -0700 (PDT) Received: from na01-bl2-obe.outbound.protection.outlook.com (mail-bl2on0093.outbound.protection.outlook.com [65.55.169.93]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BB0B61B29C0 for ; Mon, 3 Aug 2015 16:21:50 -0700 (PDT) Received: from SN1PR0301MB1551.namprd03.prod.outlook.com (10.162.129.157) by SN1PR0301MB1551.namprd03.prod.outlook.com (10.162.129.157) with Microsoft SMTP Server (TLS) id 15.1.225.19; Mon, 3 Aug 2015 23:21:47 +0000 Received: from SN1PR0301MB1551.namprd03.prod.outlook.com ([10.162.129.157]) by SN1PR0301MB1551.namprd03.prod.outlook.com ([10.162.129.157]) with mapi id 15.01.0225.018; Mon, 3 Aug 2015 23:21:47 +0000 From: "Asveren, Tolga" To: Bernard Aboba Thread-Topic: [rtcweb] What the gateway draft should say about mux/non-mux Thread-Index: AQHQy8DcUgzWwtVCmk+8q67BCzjC45316kQQgAAD5oCAAACVsIAAAj2AgAPw2gCAAEFTAIAARmyAgAAi5WCAABbtAIAASnwU Date: Mon, 3 Aug 2015 23:21:47 +0000 Message-ID: References: <7594FB04B1934943A5C02806D1A2204B348E29DA@ESESSMB209.ericsson.se> <67196805-ED4E-49EA-83AA-3F4C37B5BC50@gmail.com> <7594FB04B1934943A5C02806D1A2204B348E2D52@ESESSMB209.ericsson.se> <56C2F665D49E0341B9DF5938005ACDF8196FF3ED@DEMUMBX005.nsn-intra.net> <56C2F665D49E0341B9DF5938005ACDF8196FF450@DEMUMBX005.nsn-intra.net> <786615F3A85DF44AA2A76164A71FE1AC7ADB690D@FR711WXCHMBA03.zeu.alcatel-lucent.com> <0D57A303-5917-4829-BDC7-F4345881F783@gmail.com> , In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=tasveren@sonusnet.com; x-originating-ip: [50.182.164.80] x-microsoft-exchange-diagnostics: 1; SN1PR0301MB1551; 5:ybSn9APVhwL9P9CQOcQLQtoYXf7ekGX/Hgg+EQ0cCZ6yizaXy4yV2IvPddJ4LldAPXISmJKHVjWH8GxtM6FdspsKyHz3CBD4XIe8qQWeXihpY938/CK7+/9slDZUyS1EfucUhFR6d42fy9GTe5oLgw==; 24:yiMSWGUAQNfcltZsZqiZGSbd/etUD0/+QotAoe2GWyyLo3IBs9xvzEz19DWi3NiAsVOttK6J3YuzrhEZ5w82HUfy3rCekd9wM2JydaWhcPA=; 20:x/Q6EIaUX1QQ9qQ5DStrq1uy2LQjuZOjzzhcJK563+QbH0c+l6pIJ82MirPsiJpnEVrlS4A9M8lHND/tSO4+Pg== x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:SN1PR0301MB1551; sn1pr0301mb1551: X-MS-Exchange-Organization-RulesExecuted x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:; x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(601004)(5005006)(3002001); SRVR:SN1PR0301MB1551; BCL:0; PCL:0; RULEID:; SRVR:SN1PR0301MB1551; x-forefront-prvs: 0657D528EC x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(164054003)(24454002)(13464003)(377454003)(189002)(199003)(77096005)(2656002)(19580395003)(74316001)(87936001)(2900100001)(81156007)(16236675004)(76576001)(105586002)(76176999)(50986999)(102836002)(62966003)(92566002)(66066001)(106356001)(40100003)(106116001)(5002640100001)(2950100001)(93886004)(99286002)(54356999)(122556002)(5003600100002)(77156002)(86362001)(68736005)(64706001)(5001920100001)(110136002)(5001860100001)(46102003)(33656002)(5001960100002)(101416001)(19580405001)(4001540100001)(5001830100001)(189998001)(19627405001)(19625215002)(97736004); DIR:OUT; SFP:1101; SCL:1; SRVR:SN1PR0301MB1551; H:SN1PR0301MB1551.namprd03.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; MX:1; A:1; LANG:en; received-spf: None (protection.outlook.com: sonusnet.com does not designate permitted sender hosts) Content-Type: multipart/alternative; boundary="_000_SN1PR0301MB1551A9B7F04FCAA8380EF6CBB2770SN1PR0301MB1551_" MIME-Version: 1.0 X-OriginatorOrg: sonusnet.com X-MS-Exchange-CrossTenant-originalarrivaltime: 03 Aug 2015 23:21:47.5404 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 29a671dc-ed7e-4a54-b1e5-8da1eb495dc3 X-MS-Exchange-Transport-CrossTenantHeadersStamped: SN1PR0301MB1551 Archived-At: Cc: "" Subject: Re: [rtcweb] What the gateway draft should say about mux/non-mux X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 03 Aug 2015 23:21:54 -0000 --_000_SN1PR0301MB1551A9B7F04FCAA8380EF6CBB2770SN1PR0301MB1551_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable With this interpretation, is there really a raison d'=EAtre for the GW draf= t? One just could view it as an entity with one side facing WebRTC universe= as a "full WebRTC endpoint". Honestly, that would make life easier rather = than muddying the water with what a GW should/must/may do. Thanks, Tolga ________________________________ From: Bernard Aboba Sent: Monday, August 3, 2015 2:51 PM To: Asveren, Tolga Cc: Eric Rescorla; Schwarz, Albrecht (Albrecht); Rauschenbach, Uwe (Nokia -= DE/Munich); Christer Holmberg; Roman Shpount; Subject: Re: [rtcweb] What the gateway draft should say about mux/non-mux Some mobile applications do not care about interoperating with browsers, on= ly interoperating with their own backend infrastructure and the same applic= ation running on other mobile platforms. Those applications can customize = the WebRTC stack significantly, adding or removing functionality such as RT= P/RTCP features, codecs, transports, etc. without having to test interopera= bility with browsers. Although this kind of customization occurs very frequently today, it isn't = that relevant to the IETF RTCWEB specifications which apply to browser impl= ementations and gateways that support browser implementations. Just as a m= obile application can deviate from the WebRTC specifications, a gateway dev= eloped for that application may not conform to the WebRTC gateway specifica= tion either. Cataloging every way that non-compliant implementations can d= eviate is a potentially endless task. On Mon, Aug 3, 2015 at 10:47 AM, Asveren, Tolga > wrote: There are/will be deployment models, where WebRTC is used as a "Real Time C= ommunication Profile" with endpoints as native applications rather than bro= wsers ( I am not arguing/advocating that this interpretation/use of WebRTC = specifications is completely kosher). In such environments, certain charact= eristics/capabilities/expectations will be a bit different than the "tradit= ional" WebRTC use with browsers+Internet. So, a gateway, which is purpose-b= uilt for such specific deployments may not need to interwork with browsers.= If it needs, it needs to support rtcp-mux. I think a "SHOULD" strength statement for gateway rtcp-mux support with som= e explanation about the rationale behind it could be a good path forward. Thanks, Tolga > -----Original Message----- > From: Bernard Aboba [mailto:bernard.aboba@gmail.com] > Sent: Monday, August 03, 2015 11:25 AM > To: Eric Rescorla > > Cc: Schwarz, Albrecht (Albrecht) >; > Rauschenbach, Uwe (Nokia - DE/Munich) >; > Asveren, Tolga >; Chr= ister Holmberg > >; = Roman Shpount >; > > > > Subject: Re: [rtcweb] What the gateway draft should say about mux/non- > mux > > On Aug 3, 2015, at 04:12, Eric Rescorla > wrote: > > I don't see how this conclusion follows. > > > [BA] It is logical that a gateway needs to support both WEBRTC endpoints > and non-WEBRTC endpoints. However, it does not follow that WEBRTC > endpoints should be required to support features of non-WEBRTC endpoints > (e.g. like non-mux or SRTP/SDES). > > > I think this goes back to the question Peter and Cullen have been > > asking. What concrete scenario (i.e., real equipment) will fail to > > interoperate if we simply require MUX all the time? > > [BA] From what I can tell, none. The gateway can speak mux to WEBRTC > endpoints and non-mux to legacy. > --_000_SN1PR0301MB1551A9B7F04FCAA8380EF6CBB2770SN1PR0301MB1551_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

With this interpretation, is there really a raison d'=EAtre for the GW d= raft? One just could view it as an entity with one side facing WebRTC unive= rse as a "full WebRTC endpoint". Honestly, that would make life e= asier rather than muddying the water with what a GW should/must/may do. 


Thanks,

Tolga



From: Bernard Aboba <ber= nard.aboba@gmail.com>
Sent: Monday, August 3, 2015 2:51 PM
To: Asveren, Tolga
Cc: Eric Rescorla; Schwarz, Albrecht (Albrecht); Rauschenbach, Uwe (= Nokia - DE/Munich); Christer Holmberg; Roman Shpount; <rtcweb@ietf.org&g= t;
Subject: Re: [rtcweb] What the gateway draft should say about mux/no= n-mux
 
Some mobile applications do not care about interoperating with br= owsers, only interoperating with their own backend infrastructure and the s= ame application running on other mobile platforms.  Those ap= plications can customize the WebRTC stack significantly, adding or removing functionality such as RTP/RTCP features, codecs, transp= orts, etc. without having to test interoperability with browsers. = ;

Although this kind of customization occurs very frequently today, it i= sn't that relevant to the IETF RTCWEB specifications which apply = to browser implementations and gateways that support browser impl= ementations.  Just as a mobile application can deviate from the WebRTC specifications, a gateway developed for that applicat= ion may not conform to the WebRTC gateway specification either.  Catal= oging every way that non-compliant implementations can deviate is a potenti= ally endless task.
 

On Mon, Aug 3, 2015 at 10:47 AM, Asveren, Tolga = <tasveren@son= usnet.com> wrote:
There are/will be deployment models, where WebRTC is used as a "Real T= ime Communication Profile" with endpoints as native applications rathe= r than browsers ( I am not arguing/advocating that this interpretation/use = of WebRTC specifications is completely kosher). In such environments, certain characteristics/capabilities/expectations wi= ll be a bit different than the "traditional" WebRTC use with brow= sers+Internet. So, a gateway, which is purpose-built for such specific = deployments may not need to interwork with browsers. If it needs, it needs to support rtcp-mux.

I think a "SHOULD" strength statement for gateway rtcp-mux suppor= t with some explanation about the rationale behind it could be a good path = forward.

Thanks,
Tolga

> -----Original Message-----
> From: Bernard Aboba [mailto:bernard.aboba@gmail.com]
> Sent: Monday, August 03, 2015 11:25 AM
> To: Eric Rescorla <ekr@rtfm.com= >
> Cc: Schwarz, Albrecht (Albrecht) <albrecht.schwarz@alcatel-lucent.com>;
> Rauschenbach, Uwe (Nokia - DE/Munich) <uwe.rauschenbach@nokia.com>;
> Asveren, Tolga <tasveren@s= onusnet.com>; Christer Holmberg
> <christer.holmberg@ericsson.com>; Roman Shpount <= roman@telurix.com>;
> <rtcweb@ietf.org> <rtcweb@ietf.org>
> Subject: Re: [rtcweb] What the gateway draft should say about mux/non-=
> mux
>
> On Aug 3, 2015, at 04:12, Eric Rescorla <ekr@rtfm.com> wrote:
> > I don't see how this conclusion follows.
>
>
> [BA]  It is logical that a gateway needs to support both WEBRTC e= ndpoints
> and non-WEBRTC endpoints. However, it does not follow that WEBRTC
> endpoints should be required to support features of non-WEBRTC endpoin= ts
> (e.g. like non-mux or SRTP/SDES).
>
> > I think this goes back to the question Peter and Cullen have been=
> > asking. What concrete scenario (i.e., real equipment) will fail t= o
> > interoperate if we simply require MUX all the time?
>
> [BA] From what I can tell, none. The gateway can speak mux to WEBRTC > endpoints and non-mux to legacy.
>


--_000_SN1PR0301MB1551A9B7F04FCAA8380EF6CBB2770SN1PR0301MB1551_-- From nobody Mon Aug 3 16:39:51 2015 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9646B1B31F8 for ; Mon, 3 Aug 2015 16:39:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.978 X-Spam-Level: X-Spam-Status: No, score=-1.978 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, 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 lv_AAYk5nlEB for ; Mon, 3 Aug 2015 16:39:49 -0700 (PDT) Received: from mail-io0-f174.google.com (mail-io0-f174.google.com [209.85.223.174]) (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 3DE2D1B31F6 for ; Mon, 3 Aug 2015 16:39:49 -0700 (PDT) Received: by ioii16 with SMTP id i16so1001924ioi.0 for ; Mon, 03 Aug 2015 16:39:48 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=6jtErKgzrzUdZgijrk+5KIYHeggfMoqKmSfc6IkmqWU=; b=U5KMYeucs9bVJu5WCzYdp6Q50iLge7btoVxtb/os6+GTat+n4GA80sCiJL58UcQWF1 SJQPu6JONBVXmSMSGKonoqr2e7vooSIcpdCVZrTAXh541wp+Yy/cRk6snjpm+GwOGwI+ xD+WdCTTCiz8ORoRhwCtMWZ+RzqALsXaAlsJ6WTZBZpbKZYgXooRfSOSwwuqCtt7KnIy sA33+Y6ug6U3XDN/fxZykWnCGXMDIZZTJEriMuozFa8QC3QWFzhPJQDJbLe19ubE7znT kZdHNm3EMWKtajM3z8uqJmqIkPzujbetlFsEj5U95YZaeO5Wjcx1QGL49GmqnBpC5A39 zj+A== X-Gm-Message-State: ALoCoQm2iacY7d2UYf0m8PoVv+D7rUmchINg8nUEaK9pC/bMpfsfD1A6op6Zz1zfpPr/VaB+d3TO X-Received: by 10.107.18.10 with SMTP id a10mr686229ioj.98.1438645188658; Mon, 03 Aug 2015 16:39:48 -0700 (PDT) Received: from mail-io0-f177.google.com (mail-io0-f177.google.com. [209.85.223.177]) by smtp.gmail.com with ESMTPSA id bd7sm6849287igb.19.2015.08.03.16.39.46 for (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 03 Aug 2015 16:39:47 -0700 (PDT) Received: by ioii16 with SMTP id i16so1001246ioi.0 for ; Mon, 03 Aug 2015 16:39:46 -0700 (PDT) MIME-Version: 1.0 X-Received: by 10.107.152.81 with SMTP id a78mr547073ioe.145.1438645186411; Mon, 03 Aug 2015 16:39:46 -0700 (PDT) Received: by 10.36.89.70 with HTTP; Mon, 3 Aug 2015 16:39:46 -0700 (PDT) In-Reply-To: References: <7594FB04B1934943A5C02806D1A2204B348E29DA@ESESSMB209.ericsson.se> <67196805-ED4E-49EA-83AA-3F4C37B5BC50@gmail.com> <7594FB04B1934943A5C02806D1A2204B348E2D52@ESESSMB209.ericsson.se> <56C2F665D49E0341B9DF5938005ACDF8196FF3ED@DEMUMBX005.nsn-intra.net> <56C2F665D49E0341B9DF5938005ACDF8196FF450@DEMUMBX005.nsn-intra.net> <786615F3A85DF44AA2A76164A71FE1AC7ADB690D@FR711WXCHMBA03.zeu.alcatel-lucent.com> <0D57A303-5917-4829-BDC7-F4345881F783@gmail.com> Date: Mon, 3 Aug 2015 19:39:46 -0400 Message-ID: From: Roman Shpount To: "Asveren, Tolga" Content-Type: multipart/alternative; boundary=001a114043c64b4265051c70af45 Archived-At: Cc: "" Subject: Re: [rtcweb] What the gateway draft should say about mux/non-mux X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 03 Aug 2015 23:39:50 -0000 --001a114043c64b4265051c70af45 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On Mon, Aug 3, 2015 at 7:21 PM, Asveren, Tolga wrote: > With this interpretation, is there really a raison d'=C3=AAtre for the GW > draft? One just could view it as an entity with one side facing WebRTC > universe as a "full WebRTC endpoint". Honestly, that would make life easi= er > rather than muddying the water with what a GW should/must/may do. > GW is different from the "full WebRTC endpoint" since it would typically be placed on public IP. This allows for slightly different requirements. For instance gateway can be ICE-lite instead of full ICE required by WebRTC end point. Regards, _____________ Roman Shpount --001a114043c64b4265051c70af45 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On Mon, Aug 3, 2015 at 7:21 PM, Asveren, Tolga <tasveren@sonusnet.com= > wrote:

With this interpretation, is there really a raison d'=C3=AAtre for t= he GW draft? One just could view it as an entity with one side facing WebRT= C universe as a "full WebRTC endpoint". Honestly, that would make= life easier rather than muddying the water with what a GW=C2=A0should/must/may do.=C2=A0

GW is= different from the "full WebRTC endpoint" since it would typical= ly be placed on public IP. This allows for slightly different requirements.= For instance gateway can be ICE-lite instead of full ICE required by WebRT= C end point.

Regards,
_____________
Roman Shpount
=C2=A0
--001a114043c64b4265051c70af45-- From nobody Mon Aug 3 16:57:47 2015 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 564411B29A6 for ; Mon, 3 Aug 2015 16:57:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, SPF_HELO_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4CAlU5RYgleK for ; Mon, 3 Aug 2015 16:57:44 -0700 (PDT) Received: from na01-bn1-obe.outbound.protection.outlook.com (mail-bn1on0672.outbound.protection.outlook.com [IPv6:2a01:111:f400:fc10::672]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 00AD91ACEA4 for ; Mon, 3 Aug 2015 16:57:43 -0700 (PDT) Received: from SN1PR0301MB1551.namprd03.prod.outlook.com (10.162.129.157) by SN1PR0301MB1549.namprd03.prod.outlook.com (10.162.129.155) with Microsoft SMTP Server (TLS) id 15.1.225.19; Mon, 3 Aug 2015 23:57:20 +0000 Received: from SN1PR0301MB1551.namprd03.prod.outlook.com ([10.162.129.157]) by SN1PR0301MB1551.namprd03.prod.outlook.com ([10.162.129.157]) with mapi id 15.01.0225.018; Mon, 3 Aug 2015 23:57:20 +0000 From: "Asveren, Tolga" To: Roman Shpount Thread-Topic: [rtcweb] What the gateway draft should say about mux/non-mux Thread-Index: AQHQy8DcUgzWwtVCmk+8q67BCzjC45316kQQgAAD5oCAAACVsIAAAj2AgAPw2gCAAEFTAIAARmyAgAAi5WCAABbtAIAASnwUgAAF9wCAAARiaw== Date: Mon, 3 Aug 2015 23:57:19 +0000 Message-ID: References: <7594FB04B1934943A5C02806D1A2204B348E29DA@ESESSMB209.ericsson.se> <67196805-ED4E-49EA-83AA-3F4C37B5BC50@gmail.com> <7594FB04B1934943A5C02806D1A2204B348E2D52@ESESSMB209.ericsson.se> <56C2F665D49E0341B9DF5938005ACDF8196FF3ED@DEMUMBX005.nsn-intra.net> <56C2F665D49E0341B9DF5938005ACDF8196FF450@DEMUMBX005.nsn-intra.net> <786615F3A85DF44AA2A76164A71FE1AC7ADB690D@FR711WXCHMBA03.zeu.alcatel-lucent.com> <0D57A303-5917-4829-BDC7-F4345881F783@gmail.com> , In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=tasveren@sonusnet.com; x-originating-ip: [50.182.164.80] x-microsoft-exchange-diagnostics: 1; SN1PR0301MB1549; 5:3ku+pacf0b5KZcMAstsr4lR0ScC8uBLPdeOLkDtxpCH+yLq4LZ+SvL8c9OHOrfn0z92oCrJktKodXrO3dXmnIHSspubi53BEbPB9zn1pfzO1Lz87X+Fvmmm+sZOJZecvIqmeYaVacDoYen+bef7Nbw==; 24:h+UPjMd8HRTZ5jg+skWzZqYMLGQOJ2aSTV5WVpL8Bldh9VeoRb3L3VWTm0Kwp56SsxjhGYcKtaiQXQTb13BR4NWruQ6dyCH/RCq64Ao3G60=; 20:9z/6n0q6Gf7Taz3rqsKX8CJlWqBPGJYXz1YbYi8wVSM6PyTswCC5bmllDoZ5//gI7QAoWW/QaXsARRxeeykA/g== x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:SN1PR0301MB1549; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:; x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(601004)(5005006)(3002001); SRVR:SN1PR0301MB1549; BCL:0; PCL:0; RULEID:; SRVR:SN1PR0301MB1549; x-forefront-prvs: 0657D528EC x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(199003)(24454002)(377454003)(189002)(164054003)(40100003)(122556002)(101416001)(46102003)(99286002)(76176999)(19627405001)(54356999)(106116001)(19580405001)(106356001)(105586002)(50986999)(74316001)(5003600100002)(5002640100001)(189998001)(2656002)(87936001)(19580395003)(64706001)(77156002)(5001860100001)(5001830100001)(97736004)(5001920100001)(4001540100001)(81156007)(66066001)(110136002)(5001960100002)(92566002)(33656002)(93886004)(62966003)(102836002)(16236675004)(77096005)(68736005)(76576001)(2900100001)(86362001)(2950100001)(19625215002); DIR:OUT; SFP:1101; SCL:1; SRVR:SN1PR0301MB1549; H:SN1PR0301MB1551.namprd03.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; A:1; MX:1; LANG:en; received-spf: None (protection.outlook.com: sonusnet.com does not designate permitted sender hosts) Content-Type: multipart/alternative; boundary="_000_SN1PR0301MB1551D357070BE253DFDBE783B2770SN1PR0301MB1551_" MIME-Version: 1.0 X-OriginatorOrg: sonusnet.com X-MS-Exchange-CrossTenant-originalarrivaltime: 03 Aug 2015 23:57:20.0109 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 29a671dc-ed7e-4a54-b1e5-8da1eb495dc3 X-MS-Exchange-Transport-CrossTenantHeadersStamped: SN1PR0301MB1549 Archived-At: Cc: "" Subject: Re: [rtcweb] What the gateway draft should say about mux/non-mux X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 03 Aug 2015 23:57:46 -0000 --_000_SN1PR0301MB1551D357070BE253DFDBE783B2770SN1PR0301MB1551_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Well, the same would apply to a WebRTC-endpoint, which is deployed with a p= ublic IP. Why invent a new term as GW? These are just choices based on depl= oyment model. And who said there are universal guarantees that GWs will be deployed with = routable IP Addresses? Again, deployment choices are best left unspecified. Thanks, Tolga ________________________________ From: Roman Shpount Sent: Monday, August 3, 2015 7:39 PM To: Asveren, Tolga Cc: Bernard Aboba; Eric Rescorla; Schwarz, Albrecht (Albrecht); Rauschenbac= h, Uwe (Nokia - DE/Munich); Christer Holmberg; Subject: Re: [rtcweb] What the gateway draft should say about mux/non-mux On Mon, Aug 3, 2015 at 7:21 PM, Asveren, Tolga > wrote: With this interpretation, is there really a raison d'=EAtre for the GW draf= t? One just could view it as an entity with one side facing WebRTC universe= as a "full WebRTC endpoint". Honestly, that would make life easier rather = than muddying the water with what a GW should/must/may do. GW is different from the "full WebRTC endpoint" since it would typically be= placed on public IP. This allows for slightly different requirements. For = instance gateway can be ICE-lite instead of full ICE required by WebRTC end= point. Regards, _____________ Roman Shpount --_000_SN1PR0301MB1551D357070BE253DFDBE783B2770SN1PR0301MB1551_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

Well, the same would apply to a WebRTC-endpoint, which is deployed with = a public IP. Why invent a new term as GW? These are just choices based on d= eployment model.


And who said there are universal guarantees that GWs will be deployed wi= th routable IP Addresses? Again, deployment choices are best left unspecifi= ed.


Thanks,

Tolga



From: Roman Shpount <rom= an@telurix.com>
Sent: Monday, August 3, 2015 7:39 PM
To: Asveren, Tolga
Cc: Bernard Aboba; Eric Rescorla; Schwarz, Albrecht (Albrecht); Raus= chenbach, Uwe (Nokia - DE/Munich); Christer Holmberg; <rtcweb@ietf.org&g= t;
Subject: Re: [rtcweb] What the gateway draft should say about mux/no= n-mux
 
On Mon, Aug 3, 2015 at 7:21 PM, Asveren, Tolga <= span dir=3D"ltr"> <tasveren@son= usnet.com> wrote:

With this interpretation, is there really a raison d'=EAtre for the GW d= raft? One just could view it as an entity with one side facing WebRTC unive= rse as a "full WebRTC endpoint". Honestly, that would make life e= asier rather than muddying the water with what a GW should/must/may do. 

GW is different from the "full WebRTC endpoint" since it wou= ld typically be placed on public IP. This allows for slightly different req= uirements. For instance gateway can be ICE-lite instead of full ICE require= d by WebRTC end point.

Regards,
_____________
Roman Shpount
 
--_000_SN1PR0301MB1551D357070BE253DFDBE783B2770SN1PR0301MB1551_-- From nobody Mon Aug 3 22:05:13 2015 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E09D01B3180 for ; Mon, 3 Aug 2015 22:05:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.998 X-Spam-Level: X-Spam-Status: No, score=-1.998 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, MIME_QP_LONG_LINE=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 4dy07UzthJH8 for ; Mon, 3 Aug 2015 22:05:10 -0700 (PDT) Received: from mail-pa0-x229.google.com (mail-pa0-x229.google.com [IPv6:2607:f8b0:400e:c03::229]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 646B61AC3BB for ; Mon, 3 Aug 2015 22:05:10 -0700 (PDT) Received: by pacgq8 with SMTP id gq8so41429414pac.3 for ; Mon, 03 Aug 2015 22:05:10 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=content-type:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=mZPsnwFGuI60dndHxogpOasUYxBPj9tY9+MKG0HVwz0=; b=sEIbcuDUsd7s9fp/bOY043IvntLT6PEw53uAA/h856WafBBU66c0eqXWIQhUdF4cJs m4AzOu75xLnS3ZU1PsNiPoJDXAhbA4w85uxcgY/H+3Mp+V3243OTwQ33hbiySK52Z+Hm AwQDIkXHqwYIb9L4vjpC3N07uDykjLjcDqj/vpBrOqy+ZIeYadxuh4hLoPn3zXBNpx6d HqMcX8LQdOjDmk4M4fzNshdp5O97gwj+enjr/b4T6cmzhTr/hJH3BkZQdf1t9oTvPauq s7ttLGOYKEtk/yEf0+d6999kSzsceHnJceh1opYU+LLT0PbV2OHK5xRQ90a/6+cbNd76 8RXQ== X-Received: by 10.68.111.228 with SMTP id il4mr3901444pbb.44.1438664710035; Mon, 03 Aug 2015 22:05:10 -0700 (PDT) Received: from [192.168.1.110] (c-71-227-237-49.hsd1.wa.comcast.net. [71.227.237.49]) by smtp.gmail.com with ESMTPSA id kd2sm9689133pbc.1.2015.08.03.22.05.08 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Mon, 03 Aug 2015 22:05:08 -0700 (PDT) Content-Type: multipart/alternative; boundary=Apple-Mail-1909E66A-C949-4321-AC93-11DD97C69071 Mime-Version: 1.0 (1.0) From: Bernard Aboba X-Mailer: iPad Mail (12H143) In-Reply-To: Date: Mon, 3 Aug 2015 22:05:07 -0700 Content-Transfer-Encoding: 7bit Message-Id: References: <7594FB04B1934943A5C02806D1A2204B348E29DA@ESESSMB209.ericsson.se> <67196805-ED4E-49EA-83AA-3F4C37B5BC50@gmail.com> <7594FB04B1934943A5C02806D1A2204B348E2D52@ESESSMB209.ericsson.se> <56C2F665D49E0341B9DF5938005ACDF8196FF3ED@DEMUMBX005.nsn-intra.net> <56C2F665D49E0341B9DF5938005ACDF8196FF450@DEMUMBX005.nsn-intra.net> <786615F3A85DF44AA2A76164A71FE1AC7ADB690D@FR711WXCHMBA03.zeu.alcatel-lucent.com> <0D57A303-5917-4829-BDC7-F4345881F783@gmail.com> To: "Asveren, Tolga" Archived-At: Cc: "" Subject: Re: [rtcweb] What the gateway draft should say about mux/non-mux X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 04 Aug 2015 05:05:12 -0000 --Apple-Mail-1909E66A-C949-4321-AC93-11DD97C69071 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable As Roman said, gateways have only slightly different requirements on the WEB= RTC side due to potential ability to use a Public IP address, allowing use o= f ICE-LITE. Requirements on the other side depend on what the legacy endpoi= nt is. The lowest legacy endpoint is one with IPv4, g.711, RTP/AVP or perhap= s RTP/SAVP, no ICE, maybe no RTCP.=20 > On Aug 3, 2015, at 16:57, Asveren, Tolga wrote: >=20 > Well, the same would apply to a WebRTC-endpoint, which is deployed with a p= ublic IP. Why invent a new term as GW? These are just choices based on deplo= yment model. >=20 >=20 > And who said there are universal guarantees that GWs will be deployed with= routable IP Addresses? Again, deployment choices are best left unspecified.= >=20 >=20 > Thanks, >=20 > Tolga >=20 >=20 >=20 > From: Roman Shpount > Sent: Monday, August 3, 2015 7:39 PM > To: Asveren, Tolga > Cc: Bernard Aboba; Eric Rescorla; Schwarz, Albrecht (Albrecht); Rauschenba= ch, Uwe (Nokia - DE/Munich); Christer Holmberg; > Subject: Re: [rtcweb] What the gateway draft should say about mux/non-mux > =20 >> On Mon, Aug 3, 2015 at 7:21 PM, Asveren, Tolga wr= ote: >> With this interpretation, is there really a raison d'=C3=AAtre for the GW= draft? One just could view it as an entity with one side facing WebRTC univ= erse as a "full WebRTC endpoint". Honestly, that would make life easier rath= er than muddying the water with what a GW should/must/may do.=20 >>=20 > GW is different from the "full WebRTC endpoint" since it would typically b= e placed on public IP. This allows for slightly different requirements. For i= nstance gateway can be ICE-lite instead of full ICE required by WebRTC end p= oint. >=20 > Regards, > _____________ > Roman Shpount > =20 --Apple-Mail-1909E66A-C949-4321-AC93-11DD97C69071 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable
As Roman said, gateways have only slig= htly different requirements on the WEBRTC side due to potential ability to u= se a Public IP address, allowing use of ICE-LITE.  Requirements on the o= ther side depend on what the legacy endpoint is. The lowest legacy endpoint i= s one with IPv4, g.711, RTP/AVP or perhaps RTP/SAVP, no ICE, maybe no RTCP.&= nbsp;

On Aug 3, 2015, at 16:57, Asveren, Tolga <tasveren@sonusnet.com> wrote:

Well, the same would apply to a WebRTC-endpoint, which is deployed with a= public IP. Why invent a new term as GW? These are just choices based on dep= loyment model.


And who said there are universal guarantees that GWs will be deployed wit= h routable IP Addresses? Again, deployment choices are best left unspecified= .


Thanks,

Tolga



From: Roman Shpount <roman@telurix.com>
Sent: Monday, August 3, 2015 7:39 PM
To: Asveren, Tolga
Cc: Bernard Aboba; Eric Rescorla; Schwarz, Albrecht (Albrecht); Rausc= henbach, Uwe (Nokia - DE/Munich); Christer Holmberg; <rtcweb@ietf.org>
Subject: Re: [rtcweb] What the gateway draft should say about mux/non= -mux
 
On Mon, Aug 3, 2015 at 7:21 PM, Asveren, Tolga <tasveren@sonu= snet.com> wrote:

With this interpretation, is there really a raison d'=C3=AAtre for the GW= draft? One just could view it as an entity with one side facing WebRTC univ= erse as a "full WebRTC endpoint". Honestly, that would make life easier rath= er than muddying the water with what a GW should/must/may do. 

GW is different from the "full WebRTC endpoint" since it would typicall= y be placed on public IP. This allows for slightly different requirements. Fo= r instance gateway can be ICE-lite instead of full ICE required by WebRTC en= d point.

Regards,
_____________
Roman Shpount
 
= --Apple-Mail-1909E66A-C949-4321-AC93-11DD97C69071-- From nobody Tue Aug 4 01:48:00 2015 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 211271B372F for ; Tue, 4 Aug 2015 01:47:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, SPF_HELO_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id raWcYHMTip0n for ; Tue, 4 Aug 2015 01:47:56 -0700 (PDT) Received: from na01-bn1-obe.outbound.protection.outlook.com (mail-bn1bon0636.outbound.protection.outlook.com [IPv6:2a01:111:f400:fc10::1:636]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 32DEF1A0061 for ; Tue, 4 Aug 2015 01:47:56 -0700 (PDT) Received: from SN1PR0301MB1551.namprd03.prod.outlook.com (10.162.129.157) by SN1PR0301MB1551.namprd03.prod.outlook.com (10.162.129.157) with Microsoft SMTP Server (TLS) id 15.1.225.19; Tue, 4 Aug 2015 08:47:34 +0000 Received: from SN1PR0301MB1551.namprd03.prod.outlook.com ([10.162.129.157]) by SN1PR0301MB1551.namprd03.prod.outlook.com ([10.162.129.157]) with mapi id 15.01.0225.018; Tue, 4 Aug 2015 08:47:34 +0000 From: "Asveren, Tolga" To: Bernard Aboba Thread-Topic: [rtcweb] What the gateway draft should say about mux/non-mux Thread-Index: AQHQy8DcUgzWwtVCmk+8q67BCzjC45316kQQgAAD5oCAAACVsIAAAj2AgAPw2gCAAEFTAIAARmyAgAAi5WCAABbtAIAASnwUgAAF9wCAAARia4AAVoWAgAA8di4= Date: Tue, 4 Aug 2015 08:47:34 +0000 Message-ID: References: <7594FB04B1934943A5C02806D1A2204B348E29DA@ESESSMB209.ericsson.se> <67196805-ED4E-49EA-83AA-3F4C37B5BC50@gmail.com> <7594FB04B1934943A5C02806D1A2204B348E2D52@ESESSMB209.ericsson.se> <56C2F665D49E0341B9DF5938005ACDF8196FF3ED@DEMUMBX005.nsn-intra.net> <56C2F665D49E0341B9DF5938005ACDF8196FF450@DEMUMBX005.nsn-intra.net> <786615F3A85DF44AA2A76164A71FE1AC7ADB690D@FR711WXCHMBA03.zeu.alcatel-lucent.com> <0D57A303-5917-4829-BDC7-F4345881F783@gmail.com> , In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=tasveren@sonusnet.com; x-originating-ip: [50.182.164.80] x-microsoft-exchange-diagnostics: 1; SN1PR0301MB1551; 5:XWykjttkAYnq2BSOcTIPit4+WUhoz4QDSOucQ6WheNH4U4ikkNep4eIqMU5pezfLs/O7576cLMQijShov4d3q1Bfva6AlVA0FyGO0ejTQor95NdH8/HyntRiO0CouzmjMK/1jdA8oLIdwsE7bFHsPA==; 24:+3PYV2/5ltaU6IohN6VApBoneWMGFfnh3RPtcZEMf/b4TIWVtLS2hx1llL8VrXr8YdsOR+s95331C9e1RSKIUqVITBpe7I6BBoQQjNy4ofU=; 20:vVuHjmfpKUXgArRd9dNJXTC+TpwNFDOnq/qJzFzakhAJO1Od53Vu7RDoed+VWgg6hU9BpS8YTAdEUdKQ5XbDcQ== x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:SN1PR0301MB1551; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:; x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(601004)(5005006)(3002001); SRVR:SN1PR0301MB1551; BCL:0; PCL:0; RULEID:; SRVR:SN1PR0301MB1551; x-forefront-prvs: 0658BAF71F x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(24454002)(164054003)(189002)(377454003)(199003)(105586002)(62966003)(77156002)(40100003)(5003600100002)(93886004)(76576001)(189998001)(5002640100001)(106116001)(99286002)(81156007)(97736004)(110136002)(4001540100001)(5001830100001)(5001860100001)(86362001)(77096005)(102836002)(5001960100002)(2950100001)(68736005)(2900100001)(122556002)(92566002)(106356001)(64706001)(66066001)(54356999)(19580405001)(19627405001)(76176999)(50986999)(33656002)(19625215002)(87936001)(2656002)(101416001)(46102003)(19580395003)(74316001)(16236675004); DIR:OUT; SFP:1101; SCL:1; SRVR:SN1PR0301MB1551; H:SN1PR0301MB1551.namprd03.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; MX:1; A:1; LANG:en; received-spf: None (protection.outlook.com: sonusnet.com does not designate permitted sender hosts) Content-Type: multipart/alternative; boundary="_000_SN1PR0301MB1551DF037806CA3522EF0BFAB2760SN1PR0301MB1551_" MIME-Version: 1.0 X-OriginatorOrg: sonusnet.com X-MS-Exchange-CrossTenant-originalarrivaltime: 04 Aug 2015 08:47:34.3128 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 29a671dc-ed7e-4a54-b1e5-8da1eb495dc3 X-MS-Exchange-Transport-CrossTenantHeadersStamped: SN1PR0301MB1551 Archived-At: Cc: "" Subject: Re: [rtcweb] What the gateway draft should say about mux/non-mux X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 04 Aug 2015 08:47:59 -0000 --_000_SN1PR0301MB1551DF037806CA3522EF0BFAB2760SN1PR0301MB1551_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable These are just some *assumptions*. There are/will be gateways deployed with= no public IP Addresses. Similarly what is "on the other side" of the gatew= ay is/will be varied as well. If one goes into the guessing game, it can be argued that "A gateway potent= ially may be deployed with only endpoints supporting x/y/z etc..". There co= uld be many such combinations. In the light of this, I really don't see a point for the GW draft, especial= ly after seeing that folks have the view that it should fully interoperate = with a "vanilla WebRTC endpoint". That pretty much means that a GW itself a= WebRTC endpoint and there is nothing else to specify from RTCWeb WG perspe= ctive (and hence there is even no need to define an entity as "WebRTC GW"). Thanks, Tolga ________________________________ From: Bernard Aboba Sent: Tuesday, August 4, 2015 1:05 AM To: Asveren, Tolga Cc: Roman Shpount; Eric Rescorla; Schwarz, Albrecht (Albrecht); Rauschenbac= h, Uwe (Nokia - DE/Munich); Christer Holmberg; Subject: Re: [rtcweb] What the gateway draft should say about mux/non-mux As Roman said, gateways have only slightly different requirements on the WE= BRTC side due to potential ability to use a Public IP address, allowing use= of ICE-LITE. Requirements on the other side depend on what the legacy end= point is. The lowest legacy endpoint is one with IPv4, g.711, RTP/AVP or pe= rhaps RTP/SAVP, no ICE, maybe no RTCP. On Aug 3, 2015, at 16:57, Asveren, Tolga > wrote: Well, the same would apply to a WebRTC-endpoint, which is deployed with a p= ublic IP. Why invent a new term as GW? These are just choices based on depl= oyment model. And who said there are universal guarantees that GWs will be deployed with = routable IP Addresses? Again, deployment choices are best left unspecified. Thanks, Tolga ________________________________ From: Roman Shpount > Sent: Monday, August 3, 2015 7:39 PM To: Asveren, Tolga Cc: Bernard Aboba; Eric Rescorla; Schwarz, Albrecht (Albrecht); Rauschenbac= h, Uwe (Nokia - DE/Munich); Christer Holmberg; > Subject: Re: [rtcweb] What the gateway draft should say about mux/non-mux On Mon, Aug 3, 2015 at 7:21 PM, Asveren, Tolga > wrote: With this interpretation, is there really a raison d'=EAtre for the GW draf= t? One just could view it as an entity with one side facing WebRTC universe= as a "full WebRTC endpoint". Honestly, that would make life easier rather = than muddying the water with what a GW should/must/may do. GW is different from the "full WebRTC endpoint" since it would typically be= placed on public IP. This allows for slightly different requirements. For = instance gateway can be ICE-lite instead of full ICE required by WebRTC end= point. Regards, _____________ Roman Shpount --_000_SN1PR0301MB1551DF037806CA3522EF0BFAB2760SN1PR0301MB1551_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

These are just some *assumptions*. There are/will be gateways deployed w= ith no public IP Addresses. Similarly what is "on the other side"= of the gateway is/will be varied as well.


If one goes into the guessing game, it can be argued that "A gatewa= y potentially may be deployed with only endpoints supporting x/y/z etc..&qu= ot;. There could be many such combinations.


In the light of this, I really don't see a point for the GW draft, = especially after seeing that folks have the view that it should fully inter= operate with a "vanilla WebRTC endpoint". That pretty much means = that a GW itself a WebRTC endpoint and there is nothing else to specify from RTCWeb WG perspective (and hence there is eve= n no need to define an entity as "WebRTC GW").


Thanks,

Tolga



From: Bernard Aboba <ber= nard.aboba@gmail.com>
Sent: Tuesday, August 4, 2015 1:05 AM
To: Asveren, Tolga
Cc: Roman Shpount; Eric Rescorla; Schwarz, Albrecht (Albrecht); Raus= chenbach, Uwe (Nokia - DE/Munich); Christer Holmberg; <rtcweb@ietf.org&g= t;
Subject: Re: [rtcweb] What the gateway draft should say about mux/no= n-mux
 
As Roman said, gateways have only slightly different requirements on t= he WEBRTC side due to potential ability to use a Public IP address, allowin= g use of ICE-LITE.  Requirements on the other side depend on what the = legacy endpoint is. The lowest legacy endpoint is one with IPv4, g.711, RTP/AVP or perhaps RTP/SAVP, no ICE, may= be no RTCP. 

On Aug 3, 2015, at 16:57, Asveren, Tolga <tasveren@sonusnet.com> wrote:

Well, the same would apply to a WebRTC-endpoint, which is deployed with = a public IP. Why invent a new term as GW? These are just choices based on d= eployment model.


And who said there are universal guarantees that GWs will be deployed wi= th routable IP Addresses? Again, deployment choices are best left unspecifi= ed.


Thanks,

Tolga



From: Roman Shpount <roman@telurix.com>
Sent: Monday, August 3, 2015 7:39 PM
To: Asveren, Tolga
Cc: Bernard Aboba; Eric Rescorla; Schwarz, Albrecht (Albrecht); Raus= chenbach, Uwe (Nokia - DE/Munich); Christer Holmberg; <rtcweb@ietf.org>
Subject: Re: [rtcweb] What the gateway draft should say about mux/no= n-mux
 
On Mon, Aug 3, 2015 at 7:21 PM, Asveren, Tolga <= span dir=3D"ltr"> <tasveren@son= usnet.com> wrote:

With this interpretation, is there really a raison d'=EAtre for the GW d= raft? One just could view it as an entity with one side facing WebRTC unive= rse as a "full WebRTC endpoint". Honestly, that would make life e= asier rather than muddying the water with what a GW should/must/may do. 

GW is different from the "full WebRTC endpoint" since it wou= ld typically be placed on public IP. This allows for slightly different req= uirements. For instance gateway can be ICE-lite instead of full ICE require= d by WebRTC end point.

Regards,
_____________
Roman Shpount
 
--_000_SN1PR0301MB1551DF037806CA3522EF0BFAB2760SN1PR0301MB1551_-- From nobody Tue Aug 4 07:33:26 2015 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 367181A00E7 for ; Tue, 4 Aug 2015 07:33:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.2 X-Spam-Level: X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SnZAaYGscHlO for ; Tue, 4 Aug 2015 07:33:22 -0700 (PDT) Received: from sessmg23.ericsson.net (sessmg23.ericsson.net [193.180.251.45]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 251E61A017D for ; Tue, 4 Aug 2015 07:30:25 -0700 (PDT) X-AuditID: c1b4fb2d-f79176d00000321c-1e-55c0cc7f32e0 Received: from ESESSHC009.ericsson.se (Unknown_Domain [153.88.253.124]) by sessmg23.ericsson.net (Symantec Mail Security) with SMTP id 9A.62.12828.F7CC0C55; Tue, 4 Aug 2015 16:30:23 +0200 (CEST) Received: from ESESSMB209.ericsson.se ([169.254.9.36]) by ESESSHC009.ericsson.se ([153.88.183.45]) with mapi id 14.03.0210.002; Tue, 4 Aug 2015 16:30:22 +0200 From: Christer Holmberg To: "Asveren, Tolga" , Bernard Aboba Thread-Topic: [rtcweb] What the gateway draft should say about mux/non-mux Thread-Index: AQHQy78thNOz8AYdMEys1nzX7WTf2J316g6A///gJYCAAAJzgIAAAVWAgAABfoCAA/DZAIAAQVMAgABGbICAACfJgIAAEgkAgABLbYCAAAUGAIAABOeAgABWAICAAD4nAIAAgCkg Date: Tue, 4 Aug 2015 14:30:22 +0000 Message-ID: <7594FB04B1934943A5C02806D1A2204B348E82CA@ESESSMB209.ericsson.se> References: <7594FB04B1934943A5C02806D1A2204B348E29DA@ESESSMB209.ericsson.se> <67196805-ED4E-49EA-83AA-3F4C37B5BC50@gmail.com> <7594FB04B1934943A5C02806D1A2204B348E2D52@ESESSMB209.ericsson.se> <56C2F665D49E0341B9DF5938005ACDF8196FF3ED@DEMUMBX005.nsn-intra.net> <56C2F665D49E0341B9DF5938005ACDF8196FF450@DEMUMBX005.nsn-intra.net> <786615F3A85DF44AA2A76164A71FE1AC7ADB690D@FR711WXCHMBA03.zeu.alcatel-lucent.com> <0D57A303-5917-4829-BDC7-F4345881F783@gmail.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.17] Content-Type: multipart/alternative; boundary="_000_7594FB04B1934943A5C02806D1A2204B348E82CAESESSMB209erics_" MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFtrJIsWRmVeSWpSXmKPExsUyM+JvjW79mQOhBpuuqFn8af3FaLFh339m ixWvz7FbzLgwldli7b92dovZne+ZLB5PPsXuwO7R+mwvq8fOWXfZPZYs+cnkcffWJSaPyY/b mD0uff7P7nFrSkEAexSXTUpqTmZZapG+XQJXxsoH19kLjkxgrOjtP8HewHilgbGLkZNDQsBE Yvrmf8wQtpjEhXvr2boYuTiEBI4ySqz5f4sZwlnEKNE9pwPI4eBgE7CQ6P6nDdIgIhAucX7W GUaQGmaBP4wSmw7fYAJJCAt4StzqXMwEUeQlse77NbBBIgLTGCWuvNnMApJgEVCR2L7zCthq XgFfiSlzZrNAbDskIPF35zUWkG2cAokSp/bkgdQwAp33/dQasKHMAuISt57MZ4I4W0BiyZ7z UC+ISrx8/I8VpFVCQFFieb8cRHm+RN+rTywQqwQlTs58wjKBUXQWkkmzkJTNQlIGEdeTuDF1 ChuErS2xbOFrZghbV2LGv0MsyOILGNlXMYoWpxYX56YbGeulFmUmFxfn5+nlpZZsYgTG9cEt v3V3MK5+7XiIUYCDUYmHd4HMgVAh1sSy4srcQ4zSHCxK4rwzNueFCgmkJ5akZqemFqQWxReV 5qQWH2Jk4uCUamB0Yb2rwjizbbGJlQg/g4KBTHEY97mWs0Lzz3+70iQjMNuW54dwCuOnPd/+ lgeXvH98SpJjwgGD5YwblF51Juv8127gvPf++MK6DYmMeQsmJq58WFIu7PBnpomU0ZwK04tz mvMLysU3xKxmffMj5L7r4UqdbiEOEV2DU3abWJoEvOUX/QkpKFBiKc5INNRiLipOBAAOBwLU zAIAAA== Archived-At: Cc: "" Subject: Re: [rtcweb] What the gateway draft should say about mux/non-mux X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 04 Aug 2015 14:33:25 -0000 --_000_7594FB04B1934943A5C02806D1A2204B348E82CAESESSMB209erics_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi, > These are just some *assumptions*. There are/will be gateways deployed wi= th no public IP Addresses. Similarly what is "on the other side" of the gat= eway is/will be varied as well. > > If one goes into the guessing game, it can be argued that "A gateway pote= ntially may be deployed with only endpoints supporting x/y/z etc..". There = could be many such combinations. > > In the light of this, I really don't see a point for the GW draft, especi= ally after seeing that folks have the view that it should fully interoperat= e with a "vanilla WebRTC endpoint". That pretty > much means that a GW itself a WebRTC endpoint and there is nothing else t= o specify from RTCWeb WG perspective (and hence there is even no need to de= fine an entity as "WebRTC GW"). As has been said, a WebRTC GW differs from a vanilla WebRTC endpoint e.g. i= n that it can be ICE-lite and that it is not mandated to send consent refre= sh requests. However, that doesn't prevent it from fully interoperating wit= h a vanilla endpoint. Regards, Christer ________________________________ From: Bernard Aboba > Sent: Tuesday, August 4, 2015 1:05 AM To: Asveren, Tolga Cc: Roman Shpount; Eric Rescorla; Schwarz, Albrecht (Albrecht); Rauschenbac= h, Uwe (Nokia - DE/Munich); Christer Holmberg; > Subject: Re: [rtcweb] What the gateway draft should say about mux/non-mux As Roman said, gateways have only slightly different requirements on the WE= BRTC side due to potential ability to use a Public IP address, allowing use= of ICE-LITE. Requirements on the other side depend on what the legacy end= point is. The lowest legacy endpoint is one with IPv4, g.711, RTP/AVP or pe= rhaps RTP/SAVP, no ICE, maybe no RTCP. On Aug 3, 2015, at 16:57, Asveren, Tolga > wrote: Well, the same would apply to a WebRTC-endpoint, which is deployed with a p= ublic IP. Why invent a new term as GW? These are just choices based on depl= oyment model. And who said there are universal guarantees that GWs will be deployed with = routable IP Addresses? Again, deployment choices are best left unspecified. Thanks, Tolga ________________________________ From: Roman Shpount > Sent: Monday, August 3, 2015 7:39 PM To: Asveren, Tolga Cc: Bernard Aboba; Eric Rescorla; Schwarz, Albrecht (Albrecht); Rauschenbac= h, Uwe (Nokia - DE/Munich); Christer Holmberg; > Subject: Re: [rtcweb] What the gateway draft should say about mux/non-mux On Mon, Aug 3, 2015 at 7:21 PM, Asveren, Tolga > wrote: With this interpretation, is there really a raison d'=EAtre for the GW draf= t? One just could view it as an entity with one side facing WebRTC universe= as a "full WebRTC endpoint". Honestly, that would make life easier rather = than muddying the water with what a GW should/must/may do. GW is different from the "full WebRTC endpoint" since it would typically be= placed on public IP. This allows for slightly different requirements. For = instance gateway can be ICE-lite instead of full ICE required by WebRTC end= point. Regards, _____________ Roman Shpount --_000_7594FB04B1934943A5C02806D1A2204B348E82CAESESSMB209erics_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

Hi,

 

> These are just some *assumptions*. There are/= will be gateways deployed with no public IP Addresses. Similarly what is &q= uot;on the other side" of the gateway is/will be varied as well.<= /o:p>

> 

> If one goes into the guessing game, it can be= argued that "A gateway potentially may be deployed with only endpoint= s supporting x/y/z etc..". There could be many such combinations.

> 

> In the light of this, I really don't see a po= int for the GW draft, especially after seeing that folks have the view= that it should fully interoperate with a "vanilla WebRTC endpoint&quo= t;. That pretty

>= ; much means that a GW itself a WebRTC endpoint= and there is nothing else to specify from RTCWeb WG perspective (and hence= there is even no need to define an entity as "WebRTC GW").

 

As = has been said, a WebRTC GW differs from a vanilla WebRTC endpoint e.g. in t= hat it can be ICE-lite and that it is not mandated to send consent refresh requests. However, that doesn’t prevent it from full= y interoperating with a vanilla endpoint.

 

Reg= ards,

 

Chr= ister

 

 

From: = Bernard Aboba <bernard.aboba@gmail.com>
Sent: Tuesday, August 4, 2015 1:05 AM
To: Asveren, Tolga
Cc: Roman Shpount; Eric Rescorla; Schwarz, Albrecht (Albrecht); Raus= chenbach, Uwe (Nokia - DE/Munich); Christer Holmberg; <rtcw= eb@ietf.org> Subject: Re: [rtcweb] What the gateway draft should say about mux/no= n-mux

&n= bsp;

As Roman said, ga= teways have only slightly different requirements on the WEBRTC side due to = potential ability to use a Public IP address, allowing use of ICE-LITE.  Requirements on the other side depend on what the legac= y endpoint is. The lowest legacy endpoint is one with IPv4, g.711, RTP/AVP = or perhaps RTP/SAVP, no ICE, maybe no RTCP. 


On Aug 3, 2015, at 16:57, Asveren, Tolga <tasveren@sonusnet.com> wrote:

Well, the same would apply to a WebRT= C-endpoint, which is deployed with a public IP. Why invent a new term as GW= ? These are just choices based on deployment model.

 

And who said there are universal guar= antees that GWs will be deployed with routable IP Addresses? Again, deploym= ent choices are best left unspecified.

 

Thanks,

Tolga

 

From: Roman Shpount <roman@telurix.com>
Sent: Monday, August 3, 2015 7:39 PM
To: Asveren, Tolga
Cc: Bernard Aboba; Eric Rescorla; Schwarz, Albrecht (Albrecht); Raus= chenbach, Uwe (Nokia - DE/Munich); Christer Holmberg; <rtcweb@ietf.org>
Subject: Re: [rtcweb] What the gateway draft should say about mux/no= n-mux

 =

On Mon, Aug 3, 20= 15 at 7:21 PM, Asveren, Tolga <tasveren@sonusnet.com> wrote:

With this interpretation, is there re= ally a raison d'=EAtre for the GW draft? One just could view it as an entit= y with one side facing WebRTC universe as a "full WebRTC endpoint"= ;. Honestly, that would make life easier rather than muddying the water with = what a GW should/must/may do. 

GW is different f= rom the "full WebRTC endpoint" since it would typically be placed= on public IP. This allows for slightly different requirements. For instance gateway can be ICE-lite instead of full ICE required by WebRTC en= d point.

 =

Regards,

_____________
Roman Shpount

 =

--_000_7594FB04B1934943A5C02806D1A2204B348E82CAESESSMB209erics_-- From nobody Tue Aug 4 07:37:22 2015 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7D1A31A002C for ; Tue, 4 Aug 2015 07:37:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.2 X-Spam-Level: X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id c4n9MNEPtsOu for ; Tue, 4 Aug 2015 07:37:18 -0700 (PDT) Received: from sesbmg23.ericsson.net (sesbmg23.ericsson.net [193.180.251.37]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 73A3D1A004E for ; Tue, 4 Aug 2015 07:36:46 -0700 (PDT) X-AuditID: c1b4fb25-f79446d000003bb1-a0-55c0cdfc69e6 Received: from ESESSHC011.ericsson.se (Unknown_Domain [153.88.253.124]) by sesbmg23.ericsson.net (Symantec Mail Security) with SMTP id 68.0F.15281.CFDC0C55; Tue, 4 Aug 2015 16:36:44 +0200 (CEST) Received: from ESESSMB209.ericsson.se ([169.254.9.36]) by ESESSHC011.ericsson.se ([153.88.183.51]) with mapi id 14.03.0210.002; Tue, 4 Aug 2015 16:36:44 +0200 From: Christer Holmberg To: Bernard Aboba , "Asveren, Tolga" Thread-Topic: [rtcweb] What the gateway draft should say about mux/non-mux Thread-Index: AQHQy78thNOz8AYdMEys1nzX7WTf2J316g6A///gJYCAAAJzgIAAAVWAgAABfoCAA/DZAIAAQVMAgABGbICAACfJgIAAEgkAgAFreyA= Date: Tue, 4 Aug 2015 14:36:44 +0000 Message-ID: <7594FB04B1934943A5C02806D1A2204B348E8375@ESESSMB209.ericsson.se> References: <7594FB04B1934943A5C02806D1A2204B348E29DA@ESESSMB209.ericsson.se> <67196805-ED4E-49EA-83AA-3F4C37B5BC50@gmail.com> <7594FB04B1934943A5C02806D1A2204B348E2D52@ESESSMB209.ericsson.se> <56C2F665D49E0341B9DF5938005ACDF8196FF3ED@DEMUMBX005.nsn-intra.net> <56C2F665D49E0341B9DF5938005ACDF8196FF450@DEMUMBX005.nsn-intra.net> <786615F3A85DF44AA2A76164A71FE1AC7ADB690D@FR711WXCHMBA03.zeu.alcatel-lucent.com> <0D57A303-5917-4829-BDC7-F4345881F783@gmail.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.17] Content-Type: multipart/alternative; boundary="_000_7594FB04B1934943A5C02806D1A2204B348E8375ESESSMB209erics_" MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFtrOIsWRmVeSWpSXmKPExsUyM+Jvje6fswdCDS5807H40/qL0WLDvv/M Fiten2O3mHFhKrPF2n/t7BazO98zWTyefIrdgd2j9dleVo+ds+6yeyxZ8pPJ4+6tS0wekx+3 MXtc+vyf3ePWlIIA9igum5TUnMyy1CJ9uwSujK9bT7IW/GthrJj16TJzA+OWRsYuRk4OCQET iclLN0DZYhIX7q1n62Lk4hASOMoo0br8AwtIQkhgEaPEwu8VXYwcHGwCFhLd/7RBwiIC4RI9 H96ygtQzC/xhlPhw8gUrSEJYwFPiVudiJogiL4l1368xQ9hlEku/XGcDsVkEVCQO7O4EW8wr 4CtxY+M/FqjFvBKrF18GS3AKBEp87WwAa2AEuu77qTVgQ5kFxCVuPZnPBHG1gMSSPeeZIWxR iZeP/7GCHCohoCixvF8OojxfomddLzPELkGJkzOfsExgFJ2FZNIsJGWzkJTNAprELKApsX6X PkSJosSU7ofsELaGROucuezI4gsY2VcxihanFiflphsZ66UWZSYXF+fn6eWllmxiBMb0wS2/ VXcwXn7jeIhRgINRiYd3gcyBUCHWxLLiytxDjNIcLErivDM254UKCaQnlqRmp6YWpBbFF5Xm pBYfYmTi4JRqYOSwfnuKfZtrT2DE1Yc69oyx7hr/H0/q9bvzdsq9NBVVvdYrLWK8jk8LG8r0 X3UcDmXrXmowbZtfzvtsKf0k3W1vXqxQmqv4L17H68iu9aJbp2X/uztn3qXadQ6pRybauX+q r7M5+8o+xoQnt+BW3tWIrI82fnn/As1+ZGyO+xF2XPer7Lbwr0osxRmJhlrMRcWJAC6YbinK AgAA Archived-At: Cc: "" Subject: Re: [rtcweb] What the gateway draft should say about mux/non-mux X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 04 Aug 2015 14:37:21 -0000 --_000_7594FB04B1934943A5C02806D1A2204B348E8375ESESSMB209erics_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SGkgQmVybmFyZCwNCg0KSSBkb27igJl0IHRoaW5rIHRoZSBJRVRGIFJUQ1dFQiBzcGVjaWZpY2F0 aW9ucyBhcHBseSBvbmx5IHRvIGJyb3dzZXIgY2xpZW50cy4gSWYgc28sIHdoZXJlIGlzIHRoYXQg ZGVmaW5lZD8NCg0KUmVnYXJkcywNCg0KQ2hyaXN0ZXINCg0KRnJvbTogQmVybmFyZCBBYm9iYSBb bWFpbHRvOmJlcm5hcmQuYWJvYmFAZ21haWwuY29tXQ0KU2VudDogMy4gZWxva3V1dGEgMjAxNSAy MTo1Mg0KVG86IEFzdmVyZW4sIFRvbGdhDQpDYzogRXJpYyBSZXNjb3JsYTsgU2Nod2FyeiwgQWxi cmVjaHQgKEFsYnJlY2h0KTsgUmF1c2NoZW5iYWNoLCBVd2UgKE5va2lhIC0gREUvTXVuaWNoKTsg Q2hyaXN0ZXIgSG9sbWJlcmc7IFJvbWFuIFNocG91bnQ7IDxydGN3ZWJAaWV0Zi5vcmc+DQpTdWJq ZWN0OiBSZTogW3J0Y3dlYl0gV2hhdCB0aGUgZ2F0ZXdheSBkcmFmdCBzaG91bGQgc2F5IGFib3V0 IG11eC9ub24tbXV4DQoNClNvbWUgbW9iaWxlIGFwcGxpY2F0aW9ucyBkbyBub3QgY2FyZSBhYm91 dCBpbnRlcm9wZXJhdGluZyB3aXRoIGJyb3dzZXJzLCBvbmx5IGludGVyb3BlcmF0aW5nIHdpdGgg dGhlaXIgb3duIGJhY2tlbmQgaW5mcmFzdHJ1Y3R1cmUgYW5kIHRoZSBzYW1lIGFwcGxpY2F0aW9u IHJ1bm5pbmcgb24gb3RoZXIgbW9iaWxlIHBsYXRmb3Jtcy4gIFRob3NlIGFwcGxpY2F0aW9ucyBj YW4gY3VzdG9taXplIHRoZSBXZWJSVEMgc3RhY2sgc2lnbmlmaWNhbnRseSwgYWRkaW5nIG9yIHJl bW92aW5nIGZ1bmN0aW9uYWxpdHkgc3VjaCBhcyBSVFAvUlRDUCBmZWF0dXJlcywgY29kZWNzLCB0 cmFuc3BvcnRzLCBldGMuIHdpdGhvdXQgaGF2aW5nIHRvIHRlc3QgaW50ZXJvcGVyYWJpbGl0eSB3 aXRoIGJyb3dzZXJzLg0KDQpBbHRob3VnaCB0aGlzIGtpbmQgb2YgY3VzdG9taXphdGlvbiBvY2N1 cnMgdmVyeSBmcmVxdWVudGx5IHRvZGF5LCBpdCBpc24ndCB0aGF0IHJlbGV2YW50IHRvIHRoZSBJ RVRGIFJUQ1dFQiBzcGVjaWZpY2F0aW9ucyB3aGljaCBhcHBseSB0byBicm93c2VyIGltcGxlbWVu dGF0aW9ucyBhbmQgZ2F0ZXdheXMgdGhhdCBzdXBwb3J0IGJyb3dzZXIgaW1wbGVtZW50YXRpb25z LiAgSnVzdCBhcyBhIG1vYmlsZSBhcHBsaWNhdGlvbiBjYW4gZGV2aWF0ZSBmcm9tIHRoZSBXZWJS VEMgc3BlY2lmaWNhdGlvbnMsIGEgZ2F0ZXdheSBkZXZlbG9wZWQgZm9yIHRoYXQgYXBwbGljYXRp b24gbWF5IG5vdCBjb25mb3JtIHRvIHRoZSBXZWJSVEMgZ2F0ZXdheSBzcGVjaWZpY2F0aW9uIGVp dGhlci4gIENhdGFsb2dpbmcgZXZlcnkgd2F5IHRoYXQgbm9uLWNvbXBsaWFudCBpbXBsZW1lbnRh dGlvbnMgY2FuIGRldmlhdGUgaXMgYSBwb3RlbnRpYWxseSBlbmRsZXNzIHRhc2suDQoNCg0KT24g TW9uLCBBdWcgMywgMjAxNSBhdCAxMDo0NyBBTSwgQXN2ZXJlbiwgVG9sZ2EgPHRhc3ZlcmVuQHNv bnVzbmV0LmNvbTxtYWlsdG86dGFzdmVyZW5Ac29udXNuZXQuY29tPj4gd3JvdGU6DQpUaGVyZSBh cmUvd2lsbCBiZSBkZXBsb3ltZW50IG1vZGVscywgd2hlcmUgV2ViUlRDIGlzIHVzZWQgYXMgYSAi UmVhbCBUaW1lIENvbW11bmljYXRpb24gUHJvZmlsZSIgd2l0aCBlbmRwb2ludHMgYXMgbmF0aXZl IGFwcGxpY2F0aW9ucyByYXRoZXIgdGhhbiBicm93c2VycyAoIEkgYW0gbm90IGFyZ3VpbmcvYWR2 b2NhdGluZyB0aGF0IHRoaXMgaW50ZXJwcmV0YXRpb24vdXNlIG9mIFdlYlJUQyBzcGVjaWZpY2F0 aW9ucyBpcyBjb21wbGV0ZWx5IGtvc2hlcikuIEluIHN1Y2ggZW52aXJvbm1lbnRzLCBjZXJ0YWlu IGNoYXJhY3RlcmlzdGljcy9jYXBhYmlsaXRpZXMvZXhwZWN0YXRpb25zIHdpbGwgYmUgYSBiaXQg ZGlmZmVyZW50IHRoYW4gdGhlICJ0cmFkaXRpb25hbCIgV2ViUlRDIHVzZSB3aXRoIGJyb3dzZXJz K0ludGVybmV0LiBTbywgYSBnYXRld2F5LCB3aGljaCBpcyBwdXJwb3NlLWJ1aWx0IGZvciBzdWNo IHNwZWNpZmljIGRlcGxveW1lbnRzIG1heSBub3QgbmVlZCB0byBpbnRlcndvcmsgd2l0aCBicm93 c2Vycy4gSWYgaXQgbmVlZHMsIGl0IG5lZWRzIHRvIHN1cHBvcnQgcnRjcC1tdXguDQoNCkkgdGhp bmsgYSAiU0hPVUxEIiBzdHJlbmd0aCBzdGF0ZW1lbnQgZm9yIGdhdGV3YXkgcnRjcC1tdXggc3Vw cG9ydCB3aXRoIHNvbWUgZXhwbGFuYXRpb24gYWJvdXQgdGhlIHJhdGlvbmFsZSBiZWhpbmQgaXQg Y291bGQgYmUgYSBnb29kIHBhdGggZm9yd2FyZC4NCg0KVGhhbmtzLA0KVG9sZ2ENCg0KPiAtLS0t LU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KPiBGcm9tOiBCZXJuYXJkIEFib2JhIFttYWlsdG86YmVy bmFyZC5hYm9iYUBnbWFpbC5jb208bWFpbHRvOmJlcm5hcmQuYWJvYmFAZ21haWwuY29tPl0NCj4g U2VudDogTW9uZGF5LCBBdWd1c3QgMDMsIDIwMTUgMTE6MjUgQU0NCj4gVG86IEVyaWMgUmVzY29y bGEgPGVrckBydGZtLmNvbTxtYWlsdG86ZWtyQHJ0Zm0uY29tPj4NCj4gQ2M6IFNjaHdhcnosIEFs YnJlY2h0IChBbGJyZWNodCkgPGFsYnJlY2h0LnNjaHdhcnpAYWxjYXRlbC1sdWNlbnQuY29tPG1h aWx0bzphbGJyZWNodC5zY2h3YXJ6QGFsY2F0ZWwtbHVjZW50LmNvbT4+Ow0KPiBSYXVzY2hlbmJh Y2gsIFV3ZSAoTm9raWEgLSBERS9NdW5pY2gpIDx1d2UucmF1c2NoZW5iYWNoQG5va2lhLmNvbTxt YWlsdG86dXdlLnJhdXNjaGVuYmFjaEBub2tpYS5jb20+PjsNCj4gQXN2ZXJlbiwgVG9sZ2EgPHRh c3ZlcmVuQHNvbnVzbmV0LmNvbTxtYWlsdG86dGFzdmVyZW5Ac29udXNuZXQuY29tPj47IENocmlz dGVyIEhvbG1iZXJnDQo+IDxjaHJpc3Rlci5ob2xtYmVyZ0Blcmljc3Nvbi5jb208bWFpbHRvOmNo cmlzdGVyLmhvbG1iZXJnQGVyaWNzc29uLmNvbT4+OyBSb21hbiBTaHBvdW50IDxyb21hbkB0ZWx1 cml4LmNvbTxtYWlsdG86cm9tYW5AdGVsdXJpeC5jb20+PjsNCj4gPHJ0Y3dlYkBpZXRmLm9yZzxt YWlsdG86cnRjd2ViQGlldGYub3JnPj4gPHJ0Y3dlYkBpZXRmLm9yZzxtYWlsdG86cnRjd2ViQGll dGYub3JnPj4NCj4gU3ViamVjdDogUmU6IFtydGN3ZWJdIFdoYXQgdGhlIGdhdGV3YXkgZHJhZnQg c2hvdWxkIHNheSBhYm91dCBtdXgvbm9uLQ0KPiBtdXgNCj4NCj4gT24gQXVnIDMsIDIwMTUsIGF0 IDA0OjEyLCBFcmljIFJlc2NvcmxhIDxla3JAcnRmbS5jb208bWFpbHRvOmVrckBydGZtLmNvbT4+ IHdyb3RlOg0KPiA+IEkgZG9uJ3Qgc2VlIGhvdyB0aGlzIGNvbmNsdXNpb24gZm9sbG93cy4NCj4N Cj4NCj4gW0JBXSAgSXQgaXMgbG9naWNhbCB0aGF0IGEgZ2F0ZXdheSBuZWVkcyB0byBzdXBwb3J0 IGJvdGggV0VCUlRDIGVuZHBvaW50cw0KPiBhbmQgbm9uLVdFQlJUQyBlbmRwb2ludHMuIEhvd2V2 ZXIsIGl0IGRvZXMgbm90IGZvbGxvdyB0aGF0IFdFQlJUQw0KPiBlbmRwb2ludHMgc2hvdWxkIGJl IHJlcXVpcmVkIHRvIHN1cHBvcnQgZmVhdHVyZXMgb2Ygbm9uLVdFQlJUQyBlbmRwb2ludHMNCj4g KGUuZy4gbGlrZSBub24tbXV4IG9yIFNSVFAvU0RFUykuDQo+DQo+ID4gSSB0aGluayB0aGlzIGdv ZXMgYmFjayB0byB0aGUgcXVlc3Rpb24gUGV0ZXIgYW5kIEN1bGxlbiBoYXZlIGJlZW4NCj4gPiBh c2tpbmcuIFdoYXQgY29uY3JldGUgc2NlbmFyaW8gKGkuZS4sIHJlYWwgZXF1aXBtZW50KSB3aWxs IGZhaWwgdG8NCj4gPiBpbnRlcm9wZXJhdGUgaWYgd2Ugc2ltcGx5IHJlcXVpcmUgTVVYIGFsbCB0 aGUgdGltZT8NCj4NCj4gW0JBXSBGcm9tIHdoYXQgSSBjYW4gdGVsbCwgbm9uZS4gVGhlIGdhdGV3 YXkgY2FuIHNwZWFrIG11eCB0byBXRUJSVEMNCj4gZW5kcG9pbnRzIGFuZCBub24tbXV4IHRvIGxl Z2FjeS4NCj4NCg0K --_000_7594FB04B1934943A5C02806D1A2204B348E8375ESESSMB209erics_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTQgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 Q2FsaWJyaTsNCglwYW5vc2UtMToyIDE1IDUgMiAyIDIgNCAzIDIgNDt9DQpAZm9udC1mYWNlDQoJ e2ZvbnQtZmFtaWx5OlRhaG9tYTsNCglwYW5vc2UtMToyIDExIDYgNCAzIDUgNCA0IDIgNDt9DQov KiBTdHlsZSBEZWZpbml0aW9ucyAqLw0KcC5Nc29Ob3JtYWwsIGxpLk1zb05vcm1hbCwgZGl2Lk1z b05vcm1hbA0KCXttYXJnaW46MGNtOw0KCW1hcmdpbi1ib3R0b206LjAwMDFwdDsNCglmb250LXNp emU6MTIuMHB0Ow0KCWZvbnQtZmFtaWx5OiJUaW1lcyBOZXcgUm9tYW4iLCJzZXJpZiI7fQ0KYTps aW5rLCBzcGFuLk1zb0h5cGVybGluaw0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6 Ymx1ZTsNCgl0ZXh0LWRlY29yYXRpb246dW5kZXJsaW5lO30NCmE6dmlzaXRlZCwgc3Bhbi5Nc29I eXBlcmxpbmtGb2xsb3dlZA0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6cHVycGxl Ow0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0Kc3Bhbi5pbQ0KCXttc28tc3R5bGUtbmFt ZTppbTt9DQpzcGFuLkVtYWlsU3R5bGUxOA0KCXttc28tc3R5bGUtdHlwZTpwZXJzb25hbC1yZXBs eTsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsInNhbnMtc2VyaWYiOw0KCWNvbG9yOiMxRjQ5N0Q7 fQ0KLk1zb0NocERlZmF1bHQNCgl7bXNvLXN0eWxlLXR5cGU6ZXhwb3J0LW9ubHk7DQoJZm9udC1m YW1pbHk6IkNhbGlicmkiLCJzYW5zLXNlcmlmIjsNCgltc28tZmFyZWFzdC1sYW5ndWFnZTpFTi1V Uzt9DQpAcGFnZSBXb3JkU2VjdGlvbjENCgl7c2l6ZTo2MTIuMHB0IDc5Mi4wcHQ7DQoJbWFyZ2lu OjcwLjg1cHQgMi4wY20gNzAuODVwdCAyLjBjbTt9DQpkaXYuV29yZFNlY3Rpb24xDQoJe3BhZ2U6 V29yZFNlY3Rpb24xO30NCi0tPjwvc3R5bGU+PCEtLVtpZiBndGUgbXNvIDldPjx4bWw+DQo8bzpz aGFwZWRlZmF1bHRzIHY6ZXh0PSJlZGl0IiBzcGlkbWF4PSIxMDI2IiAvPg0KPC94bWw+PCFbZW5k aWZdLS0+PCEtLVtpZiBndGUgbXNvIDldPjx4bWw+DQo8bzpzaGFwZWxheW91dCB2OmV4dD0iZWRp dCI+DQo8bzppZG1hcCB2OmV4dD0iZWRpdCIgZGF0YT0iMSIgLz4NCjwvbzpzaGFwZWxheW91dD48 L3htbD48IVtlbmRpZl0tLT4NCjwvaGVhZD4NCjxib2R5IGxhbmc9IkZJIiBsaW5rPSJibHVlIiB2 bGluaz0icHVycGxlIj4NCjxkaXYgY2xhc3M9IldvcmRTZWN0aW9uMSI+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtD YWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+SGkgQmVy bmFyZCw8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBz dHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZx dW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8L286cD48L3Nw YW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJm b250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fu cy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj5JIGRvbuKAmXQgdGhpbmsgdGhlIElFVEYgUlRD V0VCIHNwZWNpZmljYXRpb25zIGFwcGx5IG9ubHkgdG8gYnJvd3NlciBjbGllbnRzLiBJZiBzbywg d2hlcmUgaXMgdGhhdCBkZWZpbmVkPzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250 LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6 IzFGNDk3RCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5 OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdE Ij5SZWdhcmRzLDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxz cGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVv dDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+PG86 cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFu Zz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGli cmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj5DaHJpc3Rlcjxv OnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVO LVVTIiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1 b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8L286 cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGI+PHNwYW4gbGFuZz0iRU4tVVMi IHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O1RhaG9tYSZxdW90Oywm cXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij5Gcm9tOjwvc3Bhbj48L2I+PHNwYW4gbGFuZz0iRU4tVVMi IHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O1RhaG9tYSZxdW90Oywm cXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij4gQmVybmFyZCBBYm9iYSBbbWFpbHRvOmJlcm5hcmQuYWJv YmFAZ21haWwuY29tXQ0KPGJyPg0KPGI+U2VudDo8L2I+IDMuIGVsb2t1dXRhIDIwMTUgMjE6NTI8 YnI+DQo8Yj5Ubzo8L2I+IEFzdmVyZW4sIFRvbGdhPGJyPg0KPGI+Q2M6PC9iPiBFcmljIFJlc2Nv cmxhOyBTY2h3YXJ6LCBBbGJyZWNodCAoQWxicmVjaHQpOyBSYXVzY2hlbmJhY2gsIFV3ZSAoTm9r aWEgLSBERS9NdW5pY2gpOyBDaHJpc3RlciBIb2xtYmVyZzsgUm9tYW4gU2hwb3VudDsgJmx0O3J0 Y3dlYkBpZXRmLm9yZyZndDs8YnI+DQo8Yj5TdWJqZWN0OjwvYj4gUmU6IFtydGN3ZWJdIFdoYXQg dGhlIGdhdGV3YXkgZHJhZnQgc2hvdWxkIHNheSBhYm91dCBtdXgvbm9uLW11eDxvOnA+PC9vOnA+ PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0K PGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5Tb21lIG1vYmlsZSBhcHBsaWNhdGlv bnMmbmJzcDtkbyBub3QgY2FyZSBhYm91dCBpbnRlcm9wZXJhdGluZyB3aXRoIGJyb3dzZXJzLCBv bmx5IGludGVyb3BlcmF0aW5nIHdpdGggdGhlaXIgb3duIGJhY2tlbmQgaW5mcmFzdHJ1Y3R1cmUg YW5kIHRoZSBzYW1lIGFwcGxpY2F0aW9uIHJ1bm5pbmcgb24mbmJzcDtvdGhlciBtb2JpbGUgcGxh dGZvcm1zLiZuYnNwOyZuYnNwO1Rob3NlIGFwcGxpY2F0aW9ucyBjYW4gY3VzdG9taXplIHRoZSBX ZWJSVEMNCiBzdGFjayBzaWduaWZpY2FudGx5LCBhZGRpbmcgb3IgcmVtb3ZpbmcgZnVuY3Rpb25h bGl0eSBzdWNoIGFzIFJUUC9SVENQIGZlYXR1cmVzLCBjb2RlY3MsIHRyYW5zcG9ydHMsIGV0Yy4m bmJzcDt3aXRob3V0IGhhdmluZyB0byB0ZXN0IGludGVyb3BlcmFiaWxpdHkgd2l0aCBicm93c2Vy cy4mbmJzcDsNCjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj5BbHRob3VnaCB0aGlzIGtpbmQgb2YgY3VzdG9taXphdGlvbiBvY2N1cnMgdmVyeSBm cmVxdWVudGx5IHRvZGF5LCBpdCBpc24ndCZuYnNwO3RoYXQgcmVsZXZhbnQgdG8gdGhlIElFVEYg UlRDV0VCIHNwZWNpZmljYXRpb25zJm5ic3A7d2hpY2ggYXBwbHkgdG8gYnJvd3NlciBpbXBsZW1l bnRhdGlvbnMmbmJzcDthbmQgZ2F0ZXdheXMgdGhhdCBzdXBwb3J0Jm5ic3A7YnJvd3NlciBpbXBs ZW1lbnRhdGlvbnMuJm5ic3A7IEp1c3QgYXMgYSBtb2JpbGUgYXBwbGljYXRpb24NCiBjYW4gZGV2 aWF0ZSBmcm9tIHRoZSBXZWJSVEMgc3BlY2lmaWNhdGlvbnMsIGEgZ2F0ZXdheSBkZXZlbG9wZWQm bmJzcDtmb3IgdGhhdCBhcHBsaWNhdGlvbiBtYXkgbm90IGNvbmZvcm0gdG8gdGhlIFdlYlJUQyBn YXRld2F5IHNwZWNpZmljYXRpb24gZWl0aGVyLiZuYnNwOyBDYXRhbG9naW5nIGV2ZXJ5IHdheSB0 aGF0IG5vbi1jb21wbGlhbnQgaW1wbGVtZW50YXRpb25zIGNhbiBkZXZpYXRlIGlzIGEgcG90ZW50 aWFsbHkgZW5kbGVzcyB0YXNrLg0KPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj4mbmJzcDsgPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0K PGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPGRpdj4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPk9uIE1vbiwgQXVnIDMsIDIwMTUgYXQgMTA6NDcgQU0sIEFz dmVyZW4sIFRvbGdhICZsdDs8YSBocmVmPSJtYWlsdG86dGFzdmVyZW5Ac29udXNuZXQuY29tIiB0 YXJnZXQ9Il9ibGFuayI+dGFzdmVyZW5Ac29udXNuZXQuY29tPC9hPiZndDsgd3JvdGU6PG86cD48 L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5UaGVyZSBhcmUvd2lsbCBiZSBkZXBsb3lt ZW50IG1vZGVscywgd2hlcmUgV2ViUlRDIGlzIHVzZWQgYXMgYSAmcXVvdDtSZWFsIFRpbWUgQ29t bXVuaWNhdGlvbiBQcm9maWxlJnF1b3Q7IHdpdGggZW5kcG9pbnRzIGFzIG5hdGl2ZSBhcHBsaWNh dGlvbnMgcmF0aGVyIHRoYW4gYnJvd3NlcnMgKCBJIGFtIG5vdCBhcmd1aW5nL2Fkdm9jYXRpbmcg dGhhdCB0aGlzIGludGVycHJldGF0aW9uL3VzZSBvZiBXZWJSVEMgc3BlY2lmaWNhdGlvbnMNCiBp cyBjb21wbGV0ZWx5IGtvc2hlcikuIEluIHN1Y2ggZW52aXJvbm1lbnRzLCBjZXJ0YWluIGNoYXJh Y3RlcmlzdGljcy9jYXBhYmlsaXRpZXMvZXhwZWN0YXRpb25zIHdpbGwgYmUgYSBiaXQgZGlmZmVy ZW50IHRoYW4gdGhlICZxdW90O3RyYWRpdGlvbmFsJnF1b3Q7IFdlYlJUQyB1c2Ugd2l0aCBicm93 c2VycyYjNDM7SW50ZXJuZXQuIFNvLCBhIGdhdGV3YXksIHdoaWNoIGlzIHB1cnBvc2UtYnVpbHQg Zm9yIHN1Y2ggc3BlY2lmaWMgZGVwbG95bWVudHMgbWF5IG5vdCBuZWVkDQogdG8gaW50ZXJ3b3Jr IHdpdGggYnJvd3NlcnMuIElmIGl0IG5lZWRzLCBpdCBuZWVkcyB0byBzdXBwb3J0IHJ0Y3AtbXV4 Ljxicj4NCjxicj4NCkkgdGhpbmsgYSAmcXVvdDtTSE9VTEQmcXVvdDsgc3RyZW5ndGggc3RhdGVt ZW50IGZvciBnYXRld2F5IHJ0Y3AtbXV4IHN1cHBvcnQgd2l0aCBzb21lIGV4cGxhbmF0aW9uIGFi b3V0IHRoZSByYXRpb25hbGUgYmVoaW5kIGl0IGNvdWxkIGJlIGEgZ29vZCBwYXRoIGZvcndhcmQu PGJyPg0KPGJyPg0KVGhhbmtzLDxicj4NClRvbGdhPGJyPg0KPGJyPg0KPHNwYW4gY2xhc3M9Imlt Ij4mZ3Q7IC0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tPC9zcGFuPjxicj4NCjxzcGFuIGNsYXNz PSJpbSI+Jmd0OyBGcm9tOiBCZXJuYXJkIEFib2JhIFttYWlsdG86PGEgaHJlZj0ibWFpbHRvOmJl cm5hcmQuYWJvYmFAZ21haWwuY29tIj5iZXJuYXJkLmFib2JhQGdtYWlsLmNvbTwvYT5dPC9zcGFu Pjxicj4NCjxzcGFuIGNsYXNzPSJpbSI+Jmd0OyBTZW50OiBNb25kYXksIEF1Z3VzdCAwMywgMjAx NSAxMToyNSBBTTwvc3Bhbj48YnI+DQo8c3BhbiBjbGFzcz0iaW0iPiZndDsgVG86IEVyaWMgUmVz Y29ybGEgJmx0OzxhIGhyZWY9Im1haWx0bzpla3JAcnRmbS5jb20iPmVrckBydGZtLmNvbTwvYT4m Z3Q7PC9zcGFuPjxicj4NCjxzcGFuIGNsYXNzPSJpbSI+Jmd0OyBDYzogU2Nod2FyeiwgQWxicmVj aHQgKEFsYnJlY2h0KSAmbHQ7PGEgaHJlZj0ibWFpbHRvOmFsYnJlY2h0LnNjaHdhcnpAYWxjYXRl bC1sdWNlbnQuY29tIj5hbGJyZWNodC5zY2h3YXJ6QGFsY2F0ZWwtbHVjZW50LmNvbTwvYT4mZ3Q7 Ozwvc3Bhbj48YnI+DQo8c3BhbiBjbGFzcz0iaW0iPiZndDsgUmF1c2NoZW5iYWNoLCBVd2UgKE5v a2lhIC0gREUvTXVuaWNoKSAmbHQ7PGEgaHJlZj0ibWFpbHRvOnV3ZS5yYXVzY2hlbmJhY2hAbm9r aWEuY29tIj51d2UucmF1c2NoZW5iYWNoQG5va2lhLmNvbTwvYT4mZ3Q7Ozwvc3Bhbj48YnI+DQo8 c3BhbiBjbGFzcz0iaW0iPiZndDsgQXN2ZXJlbiwgVG9sZ2EgJmx0OzxhIGhyZWY9Im1haWx0bzp0 YXN2ZXJlbkBzb251c25ldC5jb20iPnRhc3ZlcmVuQHNvbnVzbmV0LmNvbTwvYT4mZ3Q7OyBDaHJp c3RlciBIb2xtYmVyZzwvc3Bhbj48YnI+DQo8c3BhbiBjbGFzcz0iaW0iPiZndDsgJmx0OzxhIGhy ZWY9Im1haWx0bzpjaHJpc3Rlci5ob2xtYmVyZ0Blcmljc3Nvbi5jb20iPmNocmlzdGVyLmhvbG1i ZXJnQGVyaWNzc29uLmNvbTwvYT4mZ3Q7OyBSb21hbiBTaHBvdW50ICZsdDs8YSBocmVmPSJtYWls dG86cm9tYW5AdGVsdXJpeC5jb20iPnJvbWFuQHRlbHVyaXguY29tPC9hPiZndDs7PC9zcGFuPjxi cj4NCjxzcGFuIGNsYXNzPSJpbSI+Jmd0OyAmbHQ7PGEgaHJlZj0ibWFpbHRvOnJ0Y3dlYkBpZXRm Lm9yZyI+cnRjd2ViQGlldGYub3JnPC9hPiZndDsgJmx0OzxhIGhyZWY9Im1haWx0bzpydGN3ZWJA aWV0Zi5vcmciPnJ0Y3dlYkBpZXRmLm9yZzwvYT4mZ3Q7PC9zcGFuPjxicj4NCjxzcGFuIGNsYXNz PSJpbSI+Jmd0OyBTdWJqZWN0OiBSZTogW3J0Y3dlYl0gV2hhdCB0aGUgZ2F0ZXdheSBkcmFmdCBz aG91bGQgc2F5IGFib3V0IG11eC9ub24tPC9zcGFuPjxicj4NCjxzcGFuIGNsYXNzPSJpbSI+Jmd0 OyBtdXg8L3NwYW4+PGJyPg0KPHNwYW4gY2xhc3M9ImltIj4mZ3Q7PC9zcGFuPjxvOnA+PC9vOnA+ PC9wPg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWJv dHRvbToxMi4wcHQiPiZndDsgT24gQXVnIDMsIDIwMTUsIGF0IDA0OjEyLCBFcmljIFJlc2Nvcmxh ICZsdDs8YSBocmVmPSJtYWlsdG86ZWtyQHJ0Zm0uY29tIj5la3JAcnRmbS5jb208L2E+Jmd0OyB3 cm90ZTo8YnI+DQomZ3Q7ICZndDsgSSBkb24ndCBzZWUgaG93IHRoaXMgY29uY2x1c2lvbiBmb2xs b3dzLjxicj4NCiZndDs8YnI+DQomZ3Q7PGJyPg0KJmd0OyBbQkFdJm5ic3A7IEl0IGlzIGxvZ2lj YWwgdGhhdCBhIGdhdGV3YXkgbmVlZHMgdG8gc3VwcG9ydCBib3RoIFdFQlJUQyBlbmRwb2ludHM8 YnI+DQomZ3Q7IGFuZCBub24tV0VCUlRDIGVuZHBvaW50cy4gSG93ZXZlciwgaXQgZG9lcyBub3Qg Zm9sbG93IHRoYXQgV0VCUlRDPGJyPg0KJmd0OyBlbmRwb2ludHMgc2hvdWxkIGJlIHJlcXVpcmVk IHRvIHN1cHBvcnQgZmVhdHVyZXMgb2Ygbm9uLVdFQlJUQyBlbmRwb2ludHM8YnI+DQomZ3Q7IChl LmcuIGxpa2Ugbm9uLW11eCBvciBTUlRQL1NERVMpLjxicj4NCiZndDs8YnI+DQomZ3Q7ICZndDsg SSB0aGluayB0aGlzIGdvZXMgYmFjayB0byB0aGUgcXVlc3Rpb24gUGV0ZXIgYW5kIEN1bGxlbiBo YXZlIGJlZW48YnI+DQomZ3Q7ICZndDsgYXNraW5nLiBXaGF0IGNvbmNyZXRlIHNjZW5hcmlvIChp LmUuLCByZWFsIGVxdWlwbWVudCkgd2lsbCBmYWlsIHRvPGJyPg0KJmd0OyAmZ3Q7IGludGVyb3Bl cmF0ZSBpZiB3ZSBzaW1wbHkgcmVxdWlyZSBNVVggYWxsIHRoZSB0aW1lPzxicj4NCiZndDs8YnI+ DQomZ3Q7IFtCQV0gRnJvbSB3aGF0IEkgY2FuIHRlbGwsIG5vbmUuIFRoZSBnYXRld2F5IGNhbiBz cGVhayBtdXggdG8gV0VCUlRDPGJyPg0KJmd0OyBlbmRwb2ludHMgYW5kIG5vbi1tdXggdG8gbGVn YWN5Ljxicj4NCiZndDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4N CjwvYm9keT4NCjwvaHRtbD4NCg== --_000_7594FB04B1934943A5C02806D1A2204B348E8375ESESSMB209erics_-- From nobody Tue Aug 4 09:22:50 2015 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 828AD1B29B0; Mon, 3 Aug 2015 16:43:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.102 X-Spam-Level: X-Spam-Status: No, score=-0.102 tagged_above=-999 required=5 tests=[BAYES_40=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id abdslbSCsE3O; Mon, 3 Aug 2015 16:43:51 -0700 (PDT) Received: from na01-by2-obe.outbound.protection.outlook.com (mail-by2on0101.outbound.protection.outlook.com [207.46.100.101]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 879E01A7017; Mon, 3 Aug 2015 16:43:51 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=selector1; h=From:To:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=GsC57f7se7EjD7jyQOEEUdyIB2dEfwyEDmLaq+slZ74=; b=oE9/f8ee5pAchHSQlQppmFhfr7OsKQYcwevDWFO9v2jMQAIyRd/IGR1erJ8oAkQuC0P/gtNMl0s7MFygQC8ODXaa8xmDuzOHJGdLS8F8puO27WrB0rCvRZ2TBx+4xvbv1eNqEWAnrHH823N5877yz/WfVmNQiiuWCRFSo6DF/7I= Received: from BL2PR03MB290.namprd03.prod.outlook.com (10.141.68.19) by BL2PR03MB291.namprd03.prod.outlook.com (10.141.68.25) with Microsoft SMTP Server (TLS) id 15.1.225.19; Mon, 3 Aug 2015 23:43:48 +0000 Received: from BL2PR03MB290.namprd03.prod.outlook.com ([10.141.68.19]) by BL2PR03MB290.namprd03.prod.outlook.com ([10.141.68.19]) with mapi id 15.01.0225.018; Mon, 3 Aug 2015 23:43:48 +0000 From: "Orit Levin (LCA)" To: Ted Hardie , "rtcweb@ietf.org" Thread-Topic: [appsdir] Fwd: Request for Apps Directorate review of rtcweb-security drafts Thread-Index: AQHQr4DcT2qcK6DgvkiqLOtwc4J9zZ29oujwgBRIQaCACXjGAIAfyB6Q Date: Mon, 3 Aug 2015 23:43:48 +0000 Message-ID: References: <558C4C02.3000404@cisco.com> <558C5CA3.7020108@cisco.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=oritl@microsoft.com; x-originating-ip: [2001:4898:80e8:2::25] x-microsoft-exchange-diagnostics: 1; BL2PR03MB291; 5:No4dRa5iTiIJ3VUHLQrzPOgCvnJOueloswRTHJoxqh/WZSVcHgrHwMo4K0utM3jnG0wUUHRv5ztqXNwIwyGE2uhNj5KObz3BycJ1hKevwyvA0yj5t/wiZWK3SWcE0q0Qjz6yd75/MTQRxjjMYefOPQ==; 24:q45Lwax4/snUuSesmoOkWbGw++BGymddMf+rZfeQTWAX6LmK2XafDQ/m7DdWPm24r/mUpnegc8XQXjOs9SzTD9fF0jj6FXeb0mrergDAW7g=; 20:0tr8iQMI8cxdHNQ9IztQRY2U2wHh7945OjI9mIcqgTBmlk0No4AvuulaY0RKdQtR/ubpkn5Z/4leJlP4pxi7mQ== x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:BL2PR03MB291; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(108003899814671); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(601004)(2401001)(5005006)(3002001); SRVR:BL2PR03MB291; BCL:0; PCL:0; RULEID:; SRVR:BL2PR03MB291; x-forefront-prvs: 0657D528EC x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(199003)(164054003)(24454002)(479174004)(2473001)(377454003)(13464003)(51914003)(189002)(5001960100002)(97736004)(92566002)(19625215002)(7110500001)(46102003)(2420400006)(74316001)(106356001)(87936001)(50986999)(76176999)(54356999)(93886004)(5002640100001)(86362001)(19300405004)(189998001)(16236675004)(33656002)(101416001)(2656002)(19617315012)(86612001)(5001860100001)(76576001)(77096005)(81156007)(68736005)(105586002)(2900100001)(99286002)(64706001)(4001540100001)(2501003)(106116001)(5003600100002)(15975445007)(2950100001)(5001830100001)(5001770100001)(10090500001)(40100003)(19580395003)(19580405001)(122556002)(62966003)(102836002)(77156002)(3826002)(579004)(559001); DIR:OUT; SFP:1102; SCL:1; SRVR:BL2PR03MB291; H:BL2PR03MB290.namprd03.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; A:1; MX:1; LANG:en; received-spf: None (protection.outlook.com: microsoft.com does not designate permitted sender hosts) Content-Type: multipart/alternative; boundary="_000_BL2PR03MB2900414B69109280FD682B5AD770BL2PR03MB290namprd_" MIME-Version: 1.0 X-OriginatorOrg: microsoft.com X-MS-Exchange-CrossTenant-originalarrivaltime: 03 Aug 2015 23:43:48.0877 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 72f988bf-86f1-41af-91ab-2d7cd011db47 X-MS-Exchange-Transport-CrossTenantHeadersStamped: BL2PR03MB291 Archived-At: X-Mailman-Approved-At: Tue, 04 Aug 2015 09:22:47 -0700 Cc: "appsdir@ietf.org" , Eliot Lear Subject: Re: [rtcweb] [appsdir] Fwd: Request for Apps Directorate review of rtcweb-security drafts X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 03 Aug 2015 23:43:56 -0000 --_000_BL2PR03MB2900414B69109280FD682B5AD770BL2PR03MB290namprd_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SGkgZ3V5cywNClRocmVlIGJ1c3kgd2Vla3MgYW5kIGFuIElFVEYgbWVldGluZyBoYXZlIHBhc3Ti gKYgV2hlbiBzaG91bGQgd2UgZXhwZWN0IHRvIHNlZSB0aGUgZmVlZGJhY2sgdG8gdGhlIHJldmll dz8NClRoYW5rcyBhbmQgY2hlZXJzLA0KT3JpdC4NCg0KRnJvbTogVGVkIEhhcmRpZSBbbWFpbHRv OnRlZC5pZXRmQGdtYWlsLmNvbV0NClNlbnQ6IFR1ZXNkYXksIEp1bHkgMTQsIDIwMTUgMTE6MTgg QU0NClRvOiBPcml0IExldmluIChMQ0EpIDxvcml0bEBtaWNyb3NvZnQuY29tPjsgcnRjd2ViQGll dGYub3JnDQpDYzogRWxpb3QgTGVhciA8bGVhckBjaXNjby5jb20+OyBhcHBzZGlyQGlldGYub3Jn DQpTdWJqZWN0OiBSZTogW2FwcHNkaXJdIEZ3ZDogUmVxdWVzdCBmb3IgQXBwcyBEaXJlY3RvcmF0 ZSByZXZpZXcgb2YgcnRjd2ViLXNlY3VyaXR5IGRyYWZ0cw0KDQooYWRkaW5nIHRoZSBXRykNCkhp IE9yaXQsDQpUaGFua3MgZm9yIHRoZSByZXZpZXcuDQpyZWdhcmRzLA0KVGVkIEhhcmRpZQ0KDQpP biBUdWUsIEp1bCAxNCwgMjAxNSBhdCAxMTowNyBBTSwgT3JpdCBMZXZpbiAoTENBKSA8b3JpdGxA bWljcm9zb2Z0LmNvbTxtYWlsdG86b3JpdGxAbWljcm9zb2Z0LmNvbT4+IHdyb3RlOg0KRGlzY2xh aW1lcjogSSBhbSBmYW1pbGlhciB3aXRoIFJUQyBhbmQgV2ViUlRDLCBidXQgSSBoYXZlbid0IGZv bGxvd2VkIHRoZSBSVENXZWIgd29yayBpbiB0aGUgbGFzdCBmZXcgeWVhcnMuIEkgcmVhZCB0aGUg dHdvIGRyYWZ0cyBmb3IgdGhlIGZpcnN0IHRpbWUuDQpUaGVyZWZvcmUsIG15IGFwb2xvZ2llcyBm b3IgcG90ZW50aWFsbHkgcmFpc2luZyBwb2ludHMgdGhhdCBoYXZlIGJlZW4gZGlzY3Vzc2VkIGlu IHRoZSBwYXN0Lg0KDQo+RnJvbSB0aGUgQVBQIChvciBBUlQpIHJldmlldyBwZXJzcGVjdGl2ZSwg bXkgbWFpbiBjb21tZW50IGlzIG9uIHRoZSB0b3BpYyBvZiAiV2ViLUJhc2VkIFBlZXIgQXV0aGVu dGljYXRpb24iLiBXaGlsZSBpdCBpcyBub3QgY2xlYXIgZnJvbSB0aGUgdGV4dCwgd2hpY2ggcGFy dHMgYXJlIGFscmVhZHkgc3RhbmRhcmRpemVkIGNvbmNlcHRzIChlLmcuLCBieSBXM0MpIGFuZCB3 aGljaCBhcmUgaW50cm9kdWNlZCBoZXJlIGZvciB0aGUgZmlyc3QgdGltZSwgdGhlIGRlc2NyaWJl ZCBhcHByb2FjaCBzZWVtcyB0byBiZSAoMSkgdXNlZnVsIHRvIHdlYiBhcHBsaWNhdGlvbnMgYmV5 b25kIFdlYlJUQywgKDIpIHVuZGVyIGRldmVsb3BtZW50IGFuZCB0aHVzIHByb2JhYmx5IG5vdCBz dGFibGUsIGFuZCAoMykgdG9vIGRldGFpbGVkIGZvciAiYW4gYXJjaGl0ZWN0dXJlIiBkb2N1bWVu dC4gIEFzIHN1Y2gsIHRoZSBjb25jZXB0IG9mICIgV2ViLUJhc2VkIFBlZXIgQXV0aGVudGljYXRp b24iIHByb2JhYmx5IG5lZWRzIHRvIGJlIGludHJvZHVjZWQgYW5kIHN0YW5kYXJkaXplZCB1bmRl ciB0aGUgU2VjdXJpdHkgQXJlYSBhbmQgdGhlbiBhZG9wdGVkIGJ5IFdlYlJUQyBhbmQgb3RoZXIg YXBwcy4NCg0KaHR0cHM6Ly9kYXRhdHJhY2tlci5pZXRmLm9yZy9kb2MvZHJhZnQtaWV0Zi1ydGN3 ZWItc2VjdXJpdHkvDQpUaGlzIGRvY3VtZW50IGNvbnRhaW5zIGFuIGV4Y2VsbGVudCBjb2xsZWN0 aW9uIG9mIHNlY3VyaXR5IHRocmVhdHMgdG8gV2ViUlRDIGFuZCBkaXNjdXNzZXMgbWFueSBkaWZm ZXJlbnQgaWRlYXMgZm9yIHRoZWlyIHBvdGVudGlhbCBtaXRpZ2F0aW9uLiBUaGF0IGJlaW5nIHNh aWQsIGl0IGlzIG5vdCBhbiBlYXN5IHJlYWQuIFNwZWNpZmljYWxseSwgZnJvbSBoaWdoIGxldmVs IHRvIG1vcmUgc3BlY2lmaWM6DQoxLiBUaGUgaW50ZW5kZWQgc3RhdHVzIG9mIHRoZSBkb2N1bWVu dCBpcyBTdGFuZGFyZHMgVHJhY2ssIHdoaWxlIGEgdHlwaWNhbCBzdGF0dXMgb2YgYSAic2VjdXJp dHkgdGhyZWF0IG1vZGVsIiBSRkMgaXMgSW5mb3JtYXRpb25hbC4gVGhpcyBkaXNjcmVwYW5jeSBw cm9iYWJseSBsaWVzIGluIHRoZSBjdXJyZW50IHNjb3BlIG9mIHRoZSBkb2N1bWVudC4gU2VlIHRo ZSBuZXh0IGNvbW1lbnQgYmVsb3cuDQoyLiBUaGUgc2NvcGUgb2YgdGhlIGRvY3VtZW50IGlzIG5v dCBjbGVhci4gSW4gYWRkaXRpb24gdG8gZGVzY3JpYmluZyB0aGUgc2VjdXJpdHkgdGhyZWF0cyAo YW5kIHRoZSByZXF1aXJlbWVudHMgb3IgdXNlciBleHBlY3RhdGlvbnMgcmVsYXRlZCB0byB0aGVp ciBwcmV2ZW50aW9uKSwgaW4gbWFueSBwbGFjZXMgdGhlIGRvY3VtZW50IGxpc3RzIHBvdGVudGlh bCBzb2x1dGlvbnMgd2l0aCB0aGVpciBwZXJjZWl2ZWQgbGltaXRhdGlvbnMgYW5kL29yIGFwcGxp Y2FiaWxpdHkuIEV4YW1wbGVzIGFyZSBzZWN0aW9uczogNC4yLjEsIDQuMi4yLCA0LjIuMywgNC4y LjQsIDQuMy4yLjEsIDQuMy4yLjIsIDQuMy4yLjMuIFRvIGltcHJvdmUgdGhlIGRvY3VtZW50J3Mg cmVhZGFiaWxpdHkgYW5kIHJlZHVjZSBvdmVybGFwcywgIHRoZSBzb2x1dGlvbnMgc2hvdWxkIGJl IGludHJvZHVjZWQgYW5kIGV4cGxhaW5lZCBpbiB0aGUgY29tcGFuaW9uICJhcmNoaXRlY3R1cmUi IGRvY3VtZW50LiBTb2x1dGlvbnMnIGFwcGxpY2FiaWxpdHkgdG8gZGlmZmVyZW50IHVzZSBjYXNl cyBuZWVkcyB0byBiZSBwcm92aWRlZCBpbiBhIG5vbi1iaWFzIHdheS4NCjMuIEFwYXJ0IGZyb20g dGhlIGJyaWVmIEludHJvZHVjdGlvbiB3aXRoIGEgZmV3IGV4YW1wbGVzLCB0aGVyZSBpcyBubyBk ZXNjcmlwdGlvbiBvZiB0aGUgV2ViUlRDIHRocmVhdCBtb2RlbCBwdXR0aW5nIGFsbCBtYWluIHR5 cGVzIG9mIHRocmVhdCBpbiBvbmUgcGxhY2UuIEZvciBleGFtcGxlLCB0aGUgIkNvbW11bmljYXRp b25zIFNlY3VyaXR5IiBhc3BlY3QgaXMgaW50cm9kdWNlZCBmb3IgdGhlIGZpcnN0IHRpbWUgaW4g U2VjdGlvbiA0LjMgb25seS4gVGhlIHN0YXJ0IG9mIFNlY3Rpb24gIjQuIFNlY3VyaXR5IGZvciBX ZWJSVEMgQXBwbGljYXRpb25zIiBjb3VsZCBiZSBhIGxvZ2ljYWwgcGxhY2UgZm9yIGludHJvZHVj aW5nIHRoZSBXZWJSVEMgdGhyZWF0IG1vZGVsLg0KNC4gVGhlICJzaW1wbGUgV2ViUlRDIHN5c3Rl bSIgcHJlc2VudGVkIGluIHRoZSBJbnRyb2R1Y3Rpb24gaW4gRmlndXJlIDEgaXMgaW5hZGVxdWF0 ZSB0byBpbGx1c3RyYXRlIG1hbnkgb2YgdGhlIHNjZW5hcmlvcyBhbmQgcG9pbnRzIGRpc2N1c3Nl ZCBpbiB0aGUgZG9jdW1lbnQuIEZvciBleGFtcGxlLCBzZWUgdGhlIGRpc2N1c3Npb24gYXJvdW5k IG1lZGlhIG9yaWdpbiB2cy4gd2ViIG9yaWdpbiBpbiBTZWN0aW9uIDQuMS4zLg0KNS4gU2VjdGlv biAiMy4gVGhlIEJyb3dzZXIgVGhyZWF0IE1vZGVsIiBpcyBhbiBvdmVydmlldyBvZiB0aGUgZXhp c3Rpbmcgd2ViIHNlY3VyaXR5IGFyY2hpdGVjdHVyZSBhbmQgc29tZSBjdXJyZW50IHByYWN0aWNl cy4gQXMgc3VjaCwgcmVmZXJlbmNlcyB0byByZWxldmFudCBzdGFuZGFyZHMgKGUuZy4sIFczQykg YW5kIGNvbW1vbiBwcmFjdGljZXMgbmVlZCB0byBiZSBhZGRlZCB3aXRoaW4gdGhlIHRleHQgdG8g aGVscCB0aGUgcmVhZGVyIHRvIHVuZGVyc3RhbmQgdGhlIHN0YXR1cyBvZiB0aGUgaW5mb3JtYXRp b24gYW5kIHRvIGZvbGxvdyB0aGUgc291cmNlcy4NCjYuIFRoZSBsYXN0IHBhcmFncmFwaCBpbiBT ZWN0aW9uIDQuMSBjb252ZXlzIGEga2V5IHBvaW50IGluIHRoZSB3aG9sZSBXZWJSVEMgdGhyZWF0 IG1vZGVsLiBBcyBzdWNoLCAgaXQgbmVlZHMgdG8gYmUgbW92ZWQgdG8gdGhlIHN0YXJ0IG9mIHRo ZSBkaXNjdXNzaW9uIHdoZXJlIHRoZSB0aHJlYXQgbW9kZWwgaXMgaW50cm9kdWNlZCAoc2VlIGNv bW1lbnRzIGFib3ZlKS4NCjcuIFN0eWxpc3RpY2FsbHksIHRoZSBkb2N1bWVudCB3b3VsZCBiZW5l Zml0IGZyb20gcmVtb3Zpbmcgbm9uLXN0YW5kYXJkcyB2b2NhYnVsYXJ5LCBpLmUuLCAidG8gYnVn IiwgInRvIGJ1ZyBtZSIsICJubyByZWFsIHdheSIsICJpdCBpcyBpbXBvcnRhbnQgdG8gcmVxdWly ZSIsICJleHRyZW1lbHkgYWdncmVzc2l2ZSBpbnRlcm1lZGlhdGVzIiwgIGFuZCAiZm9yIG9idmlv dXMgcmVhc29ucyIsIGV0Yy4NCjguIFN1Z2dlc3Rpb25zIGZvciByZW5hbWluZyBzb21lIG9mIHRo ZSBzZWN0aW9ucyB0byBpbXByb3ZlIHJlYWRhYmlsaXR5Og0KIjMuIFRoZSBCcm93c2VyIFRocmVh dCBNb2RlbCIgLT4gIiAzLiBPdmVydmlldyBvZiB0aGUgRXhpc3RpbmcgV2ViIFRocmVhdCBNb2Rl bCINCiI0LjEuIEFjY2VzcyB0byBMb2NhbCBEZXZpY2VzIiAtPiAiNC4xLiBDb25zZW50IHRvIEFj Y2VzcyBMb2NhbCBSZXNvdXJjZXMiDQoiNC4xLjIuIENhbGxpbmcgU2NlbmFyaW9zIGFuZCBVc2Vy IEV4cGVjdGF0aW9ucyIgLT4gIjQuMS4yLiBTY29wZSBvZiBDb25zZW50IGluIFZhcmlvdXMgQ2Fs bGluZyBTY2VuYXJpb3MiDQoiNC4xLjIuMS4gRGVkaWNhdGVkIENhbGxpbmcgU2VydmljZXMiIC0+ ICI0LjEuMi4xLiBMb25nLXRlcm0gQ29uc2VudCINCiI0LjEuMi4yLiBDYWxsaW5nIHRoZSBzaXRl IFlvdSdyZSBPbiIgLT4gIjQuMS4yLjIuIFNob3J0LXRlcm0gQ29uc2VudCINCiI0LjEuMy4gT3Jp Z2luLUJhc2VkIFNlY3VyaXR5IiAtPiAiNC4xLjMuIFdlYiBBdHRhY2tlcnMgYW5kIE9yaWdpbi1i YXNlZCBTZWN1cml0eSINCiI0LjEuNC4gU2VjdXJpdHkgUHJvcGVydGllcyBvZiB0aGUgQ2FsbGlu ZyBQYWdlIiAtPiAiNC4xLjQuIE5ldHdvcmsgQXR0YWNrZXJzIGFuZCAgU2VjdXJpdHkgUHJvcGVy dGllcyBvZiB0aGUgQ2FsbGluZyBQYWdlIg0KIjQuMi4gQ29tbXVuaWNhdGlvbnMgQ29uc2VudCBW ZXJpZmljYXRpb24iIC0+ICI0LjIuIENvbnNlbnQgdG8gUmVjZWl2ZSBUcmFmZmljIg0KIjQuMy4z LiBNYWxpY2lvdXMgUGVlcnMiIC0+ICI0LjMuMy4gT3V0IG9mIFNjb3BlIg0KDQpodHRwczovL2Rh dGF0cmFja2VyLmlldGYub3JnL2RvYy9kcmFmdC1pZXRmLXJ0Y3dlYi1zZWN1cml0eS1hcmNoLw0K VGhpcyBkb2N1bWVudCBpcyBpbiBhIG11Y2ggYmV0dGVyIHN0YXRlIGluIHRlcm1zIG9mIGl0cyBv cmdhbml6YXRpb24gYW5kIHJlYWRhYmlsaXR5LiBJdCBpbnRyb2R1Y2VzIHRoZSBzZWN1cml0eSBh cmNoaXRlY3R1cmUgdXNpbmcgYW4gZXhhbXBsZSBhbmQgdGhlbiBsaXN0cyBwb3NzaWJsZSBhcHBy b2FjaGVzIHRvIGltcGxlbWVudCBpdC4gU29tZSBhcHByb2FjaGVzIGFyZSBkZXNjcmliZWQgb24g YSBoaWdoIGxldmVsIGJ5IHJlZmVyZW5jaW5nIG90aGVyIGRvY3VtZW50cywgd2hpbGUgb3RoZXJz IGFyZSBpbnRyb2R1Y2VkIGZvciB0aGUgZmlyc3QgdGltZSBpbiB0aGlzIGRvY3VtZW50IHRvZ2V0 aGVyIHdpdGggdGhlaXIgaW1wbGVtZW50YXRpb24gZGV0YWlscy4gQnkganVzdCByZWFkaW5nIHRo ZSBkb2N1bWVudCwgaXQgaXMgZGlmZmljdWx0IHRvIGp1ZGdlIHdoZXRoZXIgdGhlc2UgZGV0YWls cyBhcmUgc3VmZmljaWVudCBvciBzdGFibGUgZW5vdWdoIGZvciBpbXBsZW1lbnRhdGlvbi4gSW4g Z2VuZXJhbCwgSSBkb3VidCB0aGF0IHRoaXMgaXMgdGhlIGJlc3QgYXBwcm9hY2ggZm9yIGFuICJh cmNoaXRlY3R1cmUiIGRvY3VtZW50LCB3aGljaCBpcyBzdXBwb3NlZCB0byBzZXJ2ZSBhcyBhIGxv bmcgdGVybSBzdGFibGUgcmVmZXJlbmNlLg0KTW9yZSBzcGVjaWZpYyBjb21tZW50czoNCjEuIERp ZmZlcmVudCB0ZXJtaW5vbG9neSBpcyB1c2VkIHRocm91Z2hvdXQgdGhlIGRvY3VtZW50IHRvIGFk ZHJlc3Mgc2FtZSBvciBjbG9zZSBjb25jZXB0cy4gSXQgd291bGQgaGVscCBhIGxvdCB0byBleHBs YWluIHRoZSBjb25jZXB0cyB1cGZyb250IGFuZCB0aGVuIHRvIHVzZSB0aGUgdGVybWlub2xvZ3kg Y29uc2lzdGVudGx5LiBDdXJyZW50bHkgaXQgaW5jbHVkZXMgImNsaWVudCIsICJlbmRwb2ludCIs ICAicGVlciIsICJ1c2VyIjsgImltcGxlbWVudGF0aW9uIiwgImJyb3dzZXIiLCAiY2hyb21lIiwg IkFQSSIsICJKUyI7ICJhcHBsaWNhdGlvbiIsICJzZXJ2ZXIiLCBldGMuDQoyLiBUaGUgZGlzY3Vz c2lvbiBpcyBwaHJhc2VkIGluIHRlcm1zIG9mICJhdXRoZW50aWNhdGlvbiIgYW5kICJ0cnVzdCIu IEluIHRoaW5rIHRoYXQgImF1dGhvcml6YXRpb24iIGluc3RlYWQgb2YgInRydXN0IiB3b3VsZCBi ZSBhIGJldHRlciB0ZWNobmljYWwgdGVybSwgZm9yIGV4YW1wbGUsIGluIFNlY3Rpb24gMy4xLg0K My4gSW4gc2VjdGlvbiA0LiBPdmVydmlldywgc2VudGVuY2UgInRoZSB0ZW5zaW9uIGJldHdlZW4g c2VjdXJpdHkgKG9yIHBlcmZvcm1hbmNlKSBhbmQgcHJpdmFjeSIgaXMgbm90IGNsZWFyLCBlc3Bl Y2lhbGx5IGJlY2F1c2UgaXQgZG9lc24ndCBzZWVtIHRvIGNvcnJlc3BvbmQgdG8gU2VjdGlvbiA2 LjIuIChCVFcgInRyYWRlb2ZmIiB3b3VsZCBiZSBhIGJldHRlciB3b3JkIHRoYW4gInRlbnNpb24i LikNCjQuIFNlY3Rpb24gIjQuMS4gSW5pdGlhbCBTaWduYWxpbmciLCB0aGUgdGV4dCBpcyBpbmNv bnNpc3RlbnQgaW4gdGVybXMgb2Ygd2hldGhlciBBbGljZSBhbmQgQm9iIHNoYXJlIG9yIHVzZSBk aWZmZXJlbnQgaWRlbnRpdHkgcHJvdmlkZXJzLg0KNS4gU2VjdGlvbiAiNC4xLiBJbml0aWFsIFNp Z25hbGluZyIsIHJlZmVyZW5jZSB0byBQZWVyQ29ubmVjdGlvbiBuZWVkcyB0byBiZSBhZGRlZC4N CjYuIFNlY3Rpb24gIjQuMi4gTWVkaWEgQ29uc2VudCBWZXJpZmljYXRpb24iIGFuZCBTZWN0aW9u ICI1LjMgQ29tbXVuaWNhdGlvbnMgQ29uc2VudCI6IHRoZSBuYW1lL3Rlcm1pbm9sb2d5IG9mIHRo aXMgZnVuY3Rpb25hbGl0eSBuZWVkcyB0byBiZSBoYXJtb25pemVkLiBUaGUgSUNFLWJhc2VkIHNv bHV0aW9uIHdpdGggaXRzIHByb3MsIGNvbnMgYXMgd2VsbCBhcyB0aGUgYWx0ZXJuYXRpdmVzIChh cHBsaWNhYmxlIHRvIGRpZmZlcmVudCB1c2UgY2FzZXMpIG5lZWQgdG8gYmUgbW92ZWQgZnJvbSB0 aGUgY29tcGFuaW9uIHRocmVhdCBtb2RlbCBkb2N1bWVudCB0byB0aGlzICJhcmNoaXRlY3R1cmUi IG9uZS4NCjcuIEEgc3VnZ2VzdGlvbjogcmVuYW1lICI1LiBEZXRhaWxlZCBUZWNobmljYWwgRGVz Y3JpcHRpb24iIHRvICI1LiBTZWN1cml0eSBBcmNoaXRlY3R1cmUgQ29tcG9uZW50cyIuDQo4LiBJ biBTZWN0aW9uIDUuMi4sICJJbXBsZW1lbnRhdGlvbnMgd2hpY2ggc3VwcG9ydCBzb21lIGZvcm0g b2YgZGlyZWN0IHVzZXIgYXV0aGVudGljYXRpb24uLi4iIC0+ICJJbXBsZW1lbnRhdGlvbnMgdGhh dCBzdXBwb3J0IHNvbWUgZm9ybSBvZiBkaXJlY3QgdXNlciBhdXRoZW50aWNhdGlvbi4uLiINCjku IFNlY3Rpb24gIjUuNi4gV2ViLUJhc2VkIFBlZXIgQXV0aGVudGljYXRpb24iIGFuZCBzZWN0aW9u ICI1LjYuMi4gT3ZlcnZpZXcgb2Ygb3BlcmF0aW9uIjogSXQgaXMgbm90IGNsZWFyLCB3aGljaCBw YXJ0cyBhcmUgc3RhbmRhcmRpemVkIGNvbmNlcHRzIChlLmcuLCBieSBXM0MpIGFuZCB3aGljaCBh cmUgaW50cm9kdWNlZCBoZXJlIGZvciB0aGUgZmlyc3QgdGltZS4gSWYgZXhpc3QsIHJlZmVyZW5j ZXMgdG8gZXhpc3Rpbmcgc3RhbmRhcmRzIG5lZWQgdG8gYmUgYWRkZWQuIFRoZSBkZXNjcmliZWQg YXJjaGl0ZWN0dXJlIGFuZCB0aGUgdGVjaG5pY2FsIGRldGFpbHMgc2VlbSB0byBiZSAoMSkgdW5k ZXIgZGV2ZWxvcG1lbnQgYW5kIHRodXMgcHJvYmFibHkgbm90IHN0YWJsZSwgKDIpIHRvbyBkZXRh aWxlZCBmb3IgImFuIGFyY2hpdGVjdHVyZSIgZG9jdW1lbnQgYW5kICgzKSB1c2VmdWwgYmV5b25k IFdlYlJUQy4gIEFzIHN1Y2gsIHRoZSBjb25jZXB0IG9mIHRoZSAiIFdlYi1CYXNlZCBQZWVyIEF1 dGhlbnRpY2F0aW9uIiBwcm9iYWJseSBuZWVkcyBiZSBpbnRyb2R1Y2VkIHVuZGVyIHRoZSBTZWN1 cml0eSBBcmVhIGFuZCB0aGVuIGFkb3B0ZWQgYnkgV2ViUlRDLg0KMTAuIFRoZSB3ZWItYmFzZWQg cGVlciBhdXRoZW50aWNhdGlvbiB1c2luZyBJZFAgaXMgbm90IHRoZSBvbmx5IG1lY2hhbmlzbSBh cHBsaWNhYmxlIHRvIFdlYlJUQy4gTW9yZW92ZXIsIHRoZSB3ZWItYmFzZWQgcGVlciBhdXRoZW50 aWNhdGlvbiAgaXMgbm90IHRoZSBvbmx5IGFwcHJvYWNoIGFwcGxpY2FibGUgdG8gV2ViUlRDLiBB bHRlcm5hdGl2ZXMgYXJlIGxpc3RlZCBpbiB0aGUgY29tcGFuaW9uIGRvY3VtZW50IGFuZCBuZWVk IHRvIGJlIG1vdmVkIGhlcmUgdG8gdGhlICJhcmNoaXRlY3R1cmUiIGRvY3VtZW50IHdpdGggdGhl aXIgcHJvcyBhbmQgY29ucyBwcmVzZW50ZWQgaW4gYW4gdW5iaWFzZWQgd2F5Lg0KMTEuIFN0eWxp c3RpY2FsbHksIHRoZSBkb2N1bWVudCB3b3VsZCBiZW5lZml0IGZyb20gcmVtb3Zpbmcgbm9uLXN0 YW5kYXJkcyB2b2NhYnVsYXJ5LCBpLmUuLCAic29tZSBXZWIgc2VydmVyIiwgImNhbid0IHJlYWxs eSB0cnVzdCIsICJ0aGF0IG11Y2giLCAiZmFpcmx5IGNvbnZlbnRpb25hbCIsICJzaW1wbHkgaGF2 ZSIsICJhIGxpdHRsZSBhbnRpY2xpbWFjdGljIiwgZXRjLiA7LSkNCg0KVGhhbmtzLA0KT3JpdC4N Cg0KPiAtLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KPiBGcm9tOiBhcHBzZGlyIFttYWlsdG86 YXBwc2Rpci1ib3VuY2VzQGlldGYub3JnPG1haWx0bzphcHBzZGlyLWJvdW5jZXNAaWV0Zi5vcmc+ XSBPbiBCZWhhbGYgT2YgT3JpdCBMZXZpbg0KPiAoTENBKQ0KPiBTZW50OiBUaHVyc2RheSwgSnVu ZSAyNSwgMjAxNSAxOjE3IFBNDQo+IFRvOiBFbGlvdCBMZWFyOyBhcHBzZGlyQGlldGYub3JnPG1h aWx0bzphcHBzZGlyQGlldGYub3JnPg0KPiBTdWJqZWN0OiBSZTogW2FwcHNkaXJdIEZ3ZDogUmVx dWVzdCBmb3IgQXBwcyBEaXJlY3RvcmF0ZSByZXZpZXcgb2YgcnRjd2ViLQ0KPiBzZWN1cml0eSBk cmFmdHMNCj4NCj4gUGVyZmVjdCEgSSBoYXZlIGEgdmVyeSBsb25nIGZsaWdodCBvbiB0aGUgN3Ro Li4uIFNvIHJpZ2h0IGFmdGVyIHRoZW4gb3IgZWFybGllci4NCj4gT3JpdC4NCj4NCj4gPiAtLS0t LU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KPiA+IEZyb206IEVsaW90IExlYXIgW21haWx0bzpsZWFy QGNpc2NvLmNvbTxtYWlsdG86bGVhckBjaXNjby5jb20+XQ0KPiA+IFNlbnQ6IFRodXJzZGF5LCBK dW5lIDI1LCAyMDE1IDEyOjU1IFBNDQo+ID4gVG86IE9yaXQgTGV2aW4gKExDQSk7IGFwcHNkaXJA aWV0Zi5vcmc8bWFpbHRvOmFwcHNkaXJAaWV0Zi5vcmc+DQo+ID4gU3ViamVjdDogUmU6IFthcHBz ZGlyXSBGd2Q6IFJlcXVlc3QgZm9yIEFwcHMgRGlyZWN0b3JhdGUgcmV2aWV3IG9mIHJ0Y3dlYi0N Cj4gPiBzZWN1cml0eSBkcmFmdHMNCj4gPg0KPiA+IFRoYW5rIHlvdSBPcml0ISAgQ2FuIHlvdSB0 cnkgdG8gaGF2ZSB0aGVtIGRvbmUgaW4gYWJvdXQgdHdvIHdlZWtzPw0KPiA+DQo+ID4gRWxpb3QN Cj4gPg0KPiA+IE9uIDYvMjUvMTUgOTo1MiBQTSwgT3JpdCBMZXZpbiAoTENBKSB3cm90ZToNCj4g PiA+IEkgd2lsbCBiZSBoYXBweSB0byB0YWtlIGEgbG9vayBhdCB0aGVtIQ0KPiA+ID4gT3JpdC4N Cj4gPiA+DQo+ID4gPj4gLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCj4gPiA+PiBGcm9tOiBh cHBzZGlyIFttYWlsdG86YXBwc2Rpci1ib3VuY2VzQGlldGYub3JnPG1haWx0bzphcHBzZGlyLWJv dW5jZXNAaWV0Zi5vcmc+XSBPbiBCZWhhbGYgT2YgRWxpb3QNCj4gTGVhcg0KPiA+ID4+IFNlbnQ6 IFRodXJzZGF5LCBKdW5lIDI1LCAyMDE1IDExOjQ0IEFNDQo+ID4gPj4gVG86IGFwcHNkaXJAaWV0 Zi5vcmc8bWFpbHRvOmFwcHNkaXJAaWV0Zi5vcmc+DQo+ID4gPj4gU3ViamVjdDogW2FwcHNkaXJd IEZ3ZDogUmVxdWVzdCBmb3IgQXBwcyBEaXJlY3RvcmF0ZSByZXZpZXcgb2YgcnRjd2ViLQ0KPiA+ ID4+IHNlY3VyaXR5IGRyYWZ0cw0KPiA+ID4+DQo+ID4gPj4gRGVhciBBcHBzZGlyIGZvbGssDQo+ ID4gPj4NCj4gPiA+PiBDb3VsZCBJIGhhdmUgYSB2b2x1bnRlZXIgdG8gcmV2aWV3IHRoZSBmb2xs b3dpbmcgdHdvIGRyYWZ0cz8NCj4gPiA+Pg0KPiA+ID4+IGh0dHBzOi8vZGF0YXRyYWNrZXIuaWV0 Zi5vcmcvZG9jL2RyYWZ0LWlldGYtcnRjd2ViLXNlY3VyaXR5Lw0KPiA+ID4+DQo+ID4gPj4gYW5k DQo+ID4gPj4NCj4gPiA+PiBodHRwczovL2RhdGF0cmFja2VyLmlldGYub3JnL2RvYy9kcmFmdC1p ZXRmLXJ0Y3dlYi1zZWN1cml0eS1hcmNoLw0KPiA+ID4+DQo+ID4gPj4gVGVkIGlzIGV4ZW1wdCwg aGF2aW5nIG1hZGUgdGhlIHJlcXVlc3QgOy0pDQo+ID4gPj4NCj4gPiA+PiBFbGlvdA0KPiA+DQo+ DQo+IF9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQo+IGFw cHNkaXIgbWFpbGluZyBsaXN0DQo+IGFwcHNkaXJAaWV0Zi5vcmc8bWFpbHRvOmFwcHNkaXJAaWV0 Zi5vcmc+DQo+IGh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vYXBwc2Rpcg0K DQpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KYXBwc2Rp ciBtYWlsaW5nIGxpc3QNCmFwcHNkaXJAaWV0Zi5vcmc8bWFpbHRvOmFwcHNkaXJAaWV0Zi5vcmc+ DQpodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL2FwcHNkaXINCg0K --_000_BL2PR03MB2900414B69109280FD682B5AD770BL2PR03MB290namprd_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IlByb2dJZCIg Y29udGVudD0iV29yZC5Eb2N1bWVudCI+DQo8bWV0YSBuYW1lPSJHZW5lcmF0b3IiIGNvbnRlbnQ9 Ik1pY3Jvc29mdCBXb3JkIDE1Ij4NCjxtZXRhIG5hbWU9Ik9yaWdpbmF0b3IiIGNvbnRlbnQ9Ik1p Y3Jvc29mdCBXb3JkIDE1Ij4NCjxsaW5rIHJlbD0iRmlsZS1MaXN0IiBocmVmPSJjaWQ6ZmlsZWxp c3QueG1sQDAxRDBDRTBCLjhFNDc4QkMwIj48IS0tW2lmIGd0ZSBtc28gOV0+PHhtbD4NCjxvOk9m ZmljZURvY3VtZW50U2V0dGluZ3M+DQo8bzpBbGxvd1BORy8+DQo8L286T2ZmaWNlRG9jdW1lbnRT ZXR0aW5ncz4NCjwveG1sPjwhW2VuZGlmXS0tPjwhLS1baWYgZ3RlIG1zbyA5XT48eG1sPg0KPHc6 V29yZERvY3VtZW50Pg0KPHc6U3BlbGxpbmdTdGF0ZT5DbGVhbjwvdzpTcGVsbGluZ1N0YXRlPg0K PHc6VHJhY2tNb3Zlcy8+DQo8dzpUcmFja0Zvcm1hdHRpbmcvPg0KPHc6RW52ZWxvcGVWaXMvPg0K PHc6VmFsaWRhdGVBZ2FpbnN0U2NoZW1hcy8+DQo8dzpTYXZlSWZYTUxJbnZhbGlkPmZhbHNlPC93 OlNhdmVJZlhNTEludmFsaWQ+DQo8dzpJZ25vcmVNaXhlZENvbnRlbnQ+ZmFsc2U8L3c6SWdub3Jl TWl4ZWRDb250ZW50Pg0KPHc6QWx3YXlzU2hvd1BsYWNlaG9sZGVyVGV4dD5mYWxzZTwvdzpBbHdh eXNTaG93UGxhY2Vob2xkZXJUZXh0Pg0KPHc6RG9Ob3RQcm9tb3RlUUYvPg0KPHc6TGlkVGhlbWVP dGhlcj5FTi1VUzwvdzpMaWRUaGVtZU90aGVyPg0KPHc6TGlkVGhlbWVBc2lhbj5YLU5PTkU8L3c6 TGlkVGhlbWVBc2lhbj4NCjx3OkxpZFRoZW1lQ29tcGxleFNjcmlwdD5YLU5PTkU8L3c6TGlkVGhl bWVDb21wbGV4U2NyaXB0Pg0KPHc6Q29tcGF0aWJpbGl0eT4NCjx3OkRvTm90RXhwYW5kU2hpZnRS ZXR1cm4vPg0KPHc6QnJlYWtXcmFwcGVkVGFibGVzLz4NCjx3OlNwbGl0UGdCcmVha0FuZFBhcmFN YXJrLz4NCjx3OkVuYWJsZU9wZW5UeXBlS2VybmluZy8+DQo8L3c6Q29tcGF0aWJpbGl0eT4NCjxt Om1hdGhQcj4NCjxtOm1hdGhGb250IG06dmFsPSJDYW1icmlhIE1hdGgiLz4NCjxtOmJya0JpbiBt OnZhbD0iYmVmb3JlIi8+DQo8bTpicmtCaW5TdWIgbTp2YWw9IiYjNDU7LSIvPg0KPG06c21hbGxG cmFjIG06dmFsPSJvZmYiLz4NCjxtOmRpc3BEZWYvPg0KPG06bE1hcmdpbiBtOnZhbD0iMCIvPg0K PG06ck1hcmdpbiBtOnZhbD0iMCIvPg0KPG06ZGVmSmMgbTp2YWw9ImNlbnRlckdyb3VwIi8+DQo8 bTp3cmFwSW5kZW50IG06dmFsPSIxNDQwIi8+DQo8bTppbnRMaW0gbTp2YWw9InN1YlN1cCIvPg0K PG06bmFyeUxpbSBtOnZhbD0idW5kT3ZyIi8+DQo8L206bWF0aFByPjwvdzpXb3JkRG9jdW1lbnQ+ DQo8L3htbD48IVtlbmRpZl0tLT48IS0tW2lmIGd0ZSBtc28gOV0+PHhtbD4NCjx3OkxhdGVudFN0 eWxlcyBEZWZMb2NrZWRTdGF0ZT0iZmFsc2UiIERlZlVuaGlkZVdoZW5Vc2VkPSJmYWxzZSIgRGVm U2VtaUhpZGRlbj0iZmFsc2UiIERlZlFGb3JtYXQ9ImZhbHNlIiBEZWZQcmlvcml0eT0iOTkiIExh dGVudFN0eWxlQ291bnQ9IjM3MSI+DQo8dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJmYWxzZSIgUHJp b3JpdHk9IjAiIFFGb3JtYXQ9InRydWUiIE5hbWU9Ik5vcm1hbCIvPg0KPHc6THNkRXhjZXB0aW9u IExvY2tlZD0iZmFsc2UiIFByaW9yaXR5PSI5IiBRRm9ybWF0PSJ0cnVlIiBOYW1lPSJoZWFkaW5n IDEiLz4NCjx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBQcmlvcml0eT0iOSIgU2VtaUhp ZGRlbj0idHJ1ZSIgVW5oaWRlV2hlblVzZWQ9InRydWUiIFFGb3JtYXQ9InRydWUiIE5hbWU9Imhl YWRpbmcgMiIvPg0KPHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFByaW9yaXR5PSI5IiBT ZW1pSGlkZGVuPSJ0cnVlIiBVbmhpZGVXaGVuVXNlZD0idHJ1ZSIgUUZvcm1hdD0idHJ1ZSIgTmFt ZT0iaGVhZGluZyAzIi8+DQo8dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJmYWxzZSIgUHJpb3JpdHk9 IjkiIFNlbWlIaWRkZW49InRydWUiIFVuaGlkZVdoZW5Vc2VkPSJ0cnVlIiBRRm9ybWF0PSJ0cnVl IiBOYW1lPSJoZWFkaW5nIDQiLz4NCjx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBQcmlv cml0eT0iOSIgU2VtaUhpZGRlbj0idHJ1ZSIgVW5oaWRlV2hlblVzZWQ9InRydWUiIFFGb3JtYXQ9 InRydWUiIE5hbWU9ImhlYWRpbmcgNSIvPg0KPHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFsc2Ui IFByaW9yaXR5PSI5IiBTZW1pSGlkZGVuPSJ0cnVlIiBVbmhpZGVXaGVuVXNlZD0idHJ1ZSIgUUZv cm1hdD0idHJ1ZSIgTmFtZT0iaGVhZGluZyA2Ii8+DQo8dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJm YWxzZSIgUHJpb3JpdHk9IjkiIFNlbWlIaWRkZW49InRydWUiIFVuaGlkZVdoZW5Vc2VkPSJ0cnVl IiBRRm9ybWF0PSJ0cnVlIiBOYW1lPSJoZWFkaW5nIDciLz4NCjx3OkxzZEV4Y2VwdGlvbiBMb2Nr ZWQ9ImZhbHNlIiBQcmlvcml0eT0iOSIgU2VtaUhpZGRlbj0idHJ1ZSIgVW5oaWRlV2hlblVzZWQ9 InRydWUiIFFGb3JtYXQ9InRydWUiIE5hbWU9ImhlYWRpbmcgOCIvPg0KPHc6THNkRXhjZXB0aW9u IExvY2tlZD0iZmFsc2UiIFByaW9yaXR5PSI5IiBTZW1pSGlkZGVuPSJ0cnVlIiBVbmhpZGVXaGVu VXNlZD0idHJ1ZSIgUUZvcm1hdD0idHJ1ZSIgTmFtZT0iaGVhZGluZyA5Ii8+DQo8dzpMc2RFeGNl cHRpb24gTG9ja2VkPSJmYWxzZSIgU2VtaUhpZGRlbj0idHJ1ZSIgVW5oaWRlV2hlblVzZWQ9InRy dWUiIE5hbWU9ImluZGV4IDEiLz4NCjx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBTZW1p SGlkZGVuPSJ0cnVlIiBVbmhpZGVXaGVuVXNlZD0idHJ1ZSIgTmFtZT0iaW5kZXggMiIvPg0KPHc6 THNkRXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFNlbWlIaWRkZW49InRydWUiIFVuaGlkZVdoZW5V c2VkPSJ0cnVlIiBOYW1lPSJpbmRleCAzIi8+DQo8dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJmYWxz ZSIgU2VtaUhpZGRlbj0idHJ1ZSIgVW5oaWRlV2hlblVzZWQ9InRydWUiIE5hbWU9ImluZGV4IDQi Lz4NCjx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBTZW1pSGlkZGVuPSJ0cnVlIiBVbmhp ZGVXaGVuVXNlZD0idHJ1ZSIgTmFtZT0iaW5kZXggNSIvPg0KPHc6THNkRXhjZXB0aW9uIExvY2tl ZD0iZmFsc2UiIFNlbWlIaWRkZW49InRydWUiIFVuaGlkZVdoZW5Vc2VkPSJ0cnVlIiBOYW1lPSJp bmRleCA2Ii8+DQo8dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJmYWxzZSIgU2VtaUhpZGRlbj0idHJ1 ZSIgVW5oaWRlV2hlblVzZWQ9InRydWUiIE5hbWU9ImluZGV4IDciLz4NCjx3OkxzZEV4Y2VwdGlv biBMb2NrZWQ9ImZhbHNlIiBTZW1pSGlkZGVuPSJ0cnVlIiBVbmhpZGVXaGVuVXNlZD0idHJ1ZSIg TmFtZT0iaW5kZXggOCIvPg0KPHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFNlbWlIaWRk ZW49InRydWUiIFVuaGlkZVdoZW5Vc2VkPSJ0cnVlIiBOYW1lPSJpbmRleCA5Ii8+DQo8dzpMc2RF eGNlcHRpb24gTG9ja2VkPSJmYWxzZSIgUHJpb3JpdHk9IjM5IiBTZW1pSGlkZGVuPSJ0cnVlIiBV bmhpZGVXaGVuVXNlZD0idHJ1ZSIgTmFtZT0idG9jIDEiLz4NCjx3OkxzZEV4Y2VwdGlvbiBMb2Nr ZWQ9ImZhbHNlIiBQcmlvcml0eT0iMzkiIFNlbWlIaWRkZW49InRydWUiIFVuaGlkZVdoZW5Vc2Vk PSJ0cnVlIiBOYW1lPSJ0b2MgMiIvPg0KPHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFBy aW9yaXR5PSIzOSIgU2VtaUhpZGRlbj0idHJ1ZSIgVW5oaWRlV2hlblVzZWQ9InRydWUiIE5hbWU9 InRvYyAzIi8+DQo8dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJmYWxzZSIgUHJpb3JpdHk9IjM5IiBT ZW1pSGlkZGVuPSJ0cnVlIiBVbmhpZGVXaGVuVXNlZD0idHJ1ZSIgTmFtZT0idG9jIDQiLz4NCjx3 OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBQcmlvcml0eT0iMzkiIFNlbWlIaWRkZW49InRy dWUiIFVuaGlkZVdoZW5Vc2VkPSJ0cnVlIiBOYW1lPSJ0b2MgNSIvPg0KPHc6THNkRXhjZXB0aW9u IExvY2tlZD0iZmFsc2UiIFByaW9yaXR5PSIzOSIgU2VtaUhpZGRlbj0idHJ1ZSIgVW5oaWRlV2hl blVzZWQ9InRydWUiIE5hbWU9InRvYyA2Ii8+DQo8dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJmYWxz ZSIgUHJpb3JpdHk9IjM5IiBTZW1pSGlkZGVuPSJ0cnVlIiBVbmhpZGVXaGVuVXNlZD0idHJ1ZSIg TmFtZT0idG9jIDciLz4NCjx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBQcmlvcml0eT0i MzkiIFNlbWlIaWRkZW49InRydWUiIFVuaGlkZVdoZW5Vc2VkPSJ0cnVlIiBOYW1lPSJ0b2MgOCIv Pg0KPHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFByaW9yaXR5PSIzOSIgU2VtaUhpZGRl bj0idHJ1ZSIgVW5oaWRlV2hlblVzZWQ9InRydWUiIE5hbWU9InRvYyA5Ii8+DQo8dzpMc2RFeGNl cHRpb24gTG9ja2VkPSJmYWxzZSIgU2VtaUhpZGRlbj0idHJ1ZSIgVW5oaWRlV2hlblVzZWQ9InRy dWUiIE5hbWU9Ik5vcm1hbCBJbmRlbnQiLz4NCjx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNl IiBTZW1pSGlkZGVuPSJ0cnVlIiBVbmhpZGVXaGVuVXNlZD0idHJ1ZSIgTmFtZT0iZm9vdG5vdGUg dGV4dCIvPg0KPHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFNlbWlIaWRkZW49InRydWUi IFVuaGlkZVdoZW5Vc2VkPSJ0cnVlIiBOYW1lPSJhbm5vdGF0aW9uIHRleHQiLz4NCjx3OkxzZEV4 Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBTZW1pSGlkZGVuPSJ0cnVlIiBVbmhpZGVXaGVuVXNlZD0i dHJ1ZSIgTmFtZT0iaGVhZGVyIi8+DQo8dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJmYWxzZSIgU2Vt aUhpZGRlbj0idHJ1ZSIgVW5oaWRlV2hlblVzZWQ9InRydWUiIE5hbWU9ImZvb3RlciIvPg0KPHc6 THNkRXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFNlbWlIaWRkZW49InRydWUiIFVuaGlkZVdoZW5V c2VkPSJ0cnVlIiBOYW1lPSJpbmRleCBoZWFkaW5nIi8+DQo8dzpMc2RFeGNlcHRpb24gTG9ja2Vk PSJmYWxzZSIgUHJpb3JpdHk9IjM1IiBTZW1pSGlkZGVuPSJ0cnVlIiBVbmhpZGVXaGVuVXNlZD0i dHJ1ZSIgUUZvcm1hdD0idHJ1ZSIgTmFtZT0iY2FwdGlvbiIvPg0KPHc6THNkRXhjZXB0aW9uIExv Y2tlZD0iZmFsc2UiIFNlbWlIaWRkZW49InRydWUiIFVuaGlkZVdoZW5Vc2VkPSJ0cnVlIiBOYW1l PSJ0YWJsZSBvZiBmaWd1cmVzIi8+DQo8dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJmYWxzZSIgU2Vt aUhpZGRlbj0idHJ1ZSIgVW5oaWRlV2hlblVzZWQ9InRydWUiIE5hbWU9ImVudmVsb3BlIGFkZHJl c3MiLz4NCjx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBTZW1pSGlkZGVuPSJ0cnVlIiBV bmhpZGVXaGVuVXNlZD0idHJ1ZSIgTmFtZT0iZW52ZWxvcGUgcmV0dXJuIi8+DQo8dzpMc2RFeGNl cHRpb24gTG9ja2VkPSJmYWxzZSIgU2VtaUhpZGRlbj0idHJ1ZSIgVW5oaWRlV2hlblVzZWQ9InRy dWUiIE5hbWU9ImZvb3Rub3RlIHJlZmVyZW5jZSIvPg0KPHc6THNkRXhjZXB0aW9uIExvY2tlZD0i ZmFsc2UiIFNlbWlIaWRkZW49InRydWUiIFVuaGlkZVdoZW5Vc2VkPSJ0cnVlIiBOYW1lPSJhbm5v dGF0aW9uIHJlZmVyZW5jZSIvPg0KPHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFNlbWlI aWRkZW49InRydWUiIFVuaGlkZVdoZW5Vc2VkPSJ0cnVlIiBOYW1lPSJsaW5lIG51bWJlciIvPg0K PHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFNlbWlIaWRkZW49InRydWUiIFVuaGlkZVdo ZW5Vc2VkPSJ0cnVlIiBOYW1lPSJwYWdlIG51bWJlciIvPg0KPHc6THNkRXhjZXB0aW9uIExvY2tl ZD0iZmFsc2UiIFNlbWlIaWRkZW49InRydWUiIFVuaGlkZVdoZW5Vc2VkPSJ0cnVlIiBOYW1lPSJl bmRub3RlIHJlZmVyZW5jZSIvPg0KPHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFNlbWlI aWRkZW49InRydWUiIFVuaGlkZVdoZW5Vc2VkPSJ0cnVlIiBOYW1lPSJlbmRub3RlIHRleHQiLz4N Cjx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBTZW1pSGlkZGVuPSJ0cnVlIiBVbmhpZGVX aGVuVXNlZD0idHJ1ZSIgTmFtZT0idGFibGUgb2YgYXV0aG9yaXRpZXMiLz4NCjx3OkxzZEV4Y2Vw dGlvbiBMb2NrZWQ9ImZhbHNlIiBTZW1pSGlkZGVuPSJ0cnVlIiBVbmhpZGVXaGVuVXNlZD0idHJ1 ZSIgTmFtZT0ibWFjcm8iLz4NCjx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBTZW1pSGlk ZGVuPSJ0cnVlIiBVbmhpZGVXaGVuVXNlZD0idHJ1ZSIgTmFtZT0idG9hIGhlYWRpbmciLz4NCjx3 OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBTZW1pSGlkZGVuPSJ0cnVlIiBVbmhpZGVXaGVu VXNlZD0idHJ1ZSIgTmFtZT0iTGlzdCIvPg0KPHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFsc2Ui IFNlbWlIaWRkZW49InRydWUiIFVuaGlkZVdoZW5Vc2VkPSJ0cnVlIiBOYW1lPSJMaXN0IEJ1bGxl dCIvPg0KPHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFNlbWlIaWRkZW49InRydWUiIFVu aGlkZVdoZW5Vc2VkPSJ0cnVlIiBOYW1lPSJMaXN0IE51bWJlciIvPg0KPHc6THNkRXhjZXB0aW9u IExvY2tlZD0iZmFsc2UiIFNlbWlIaWRkZW49InRydWUiIFVuaGlkZVdoZW5Vc2VkPSJ0cnVlIiBO YW1lPSJMaXN0IDIiLz4NCjx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBTZW1pSGlkZGVu PSJ0cnVlIiBVbmhpZGVXaGVuVXNlZD0idHJ1ZSIgTmFtZT0iTGlzdCAzIi8+DQo8dzpMc2RFeGNl cHRpb24gTG9ja2VkPSJmYWxzZSIgU2VtaUhpZGRlbj0idHJ1ZSIgVW5oaWRlV2hlblVzZWQ9InRy dWUiIE5hbWU9Ikxpc3QgNCIvPg0KPHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFNlbWlI aWRkZW49InRydWUiIFVuaGlkZVdoZW5Vc2VkPSJ0cnVlIiBOYW1lPSJMaXN0IDUiLz4NCjx3Okxz ZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBTZW1pSGlkZGVuPSJ0cnVlIiBVbmhpZGVXaGVuVXNl ZD0idHJ1ZSIgTmFtZT0iTGlzdCBCdWxsZXQgMiIvPg0KPHc6THNkRXhjZXB0aW9uIExvY2tlZD0i ZmFsc2UiIFNlbWlIaWRkZW49InRydWUiIFVuaGlkZVdoZW5Vc2VkPSJ0cnVlIiBOYW1lPSJMaXN0 IEJ1bGxldCAzIi8+DQo8dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJmYWxzZSIgU2VtaUhpZGRlbj0i dHJ1ZSIgVW5oaWRlV2hlblVzZWQ9InRydWUiIE5hbWU9Ikxpc3QgQnVsbGV0IDQiLz4NCjx3Okxz ZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBTZW1pSGlkZGVuPSJ0cnVlIiBVbmhpZGVXaGVuVXNl ZD0idHJ1ZSIgTmFtZT0iTGlzdCBCdWxsZXQgNSIvPg0KPHc6THNkRXhjZXB0aW9uIExvY2tlZD0i ZmFsc2UiIFNlbWlIaWRkZW49InRydWUiIFVuaGlkZVdoZW5Vc2VkPSJ0cnVlIiBOYW1lPSJMaXN0 IE51bWJlciAyIi8+DQo8dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJmYWxzZSIgU2VtaUhpZGRlbj0i dHJ1ZSIgVW5oaWRlV2hlblVzZWQ9InRydWUiIE5hbWU9Ikxpc3QgTnVtYmVyIDMiLz4NCjx3Okxz ZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBTZW1pSGlkZGVuPSJ0cnVlIiBVbmhpZGVXaGVuVXNl ZD0idHJ1ZSIgTmFtZT0iTGlzdCBOdW1iZXIgNCIvPg0KPHc6THNkRXhjZXB0aW9uIExvY2tlZD0i ZmFsc2UiIFNlbWlIaWRkZW49InRydWUiIFVuaGlkZVdoZW5Vc2VkPSJ0cnVlIiBOYW1lPSJMaXN0 IE51bWJlciA1Ii8+DQo8dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJmYWxzZSIgUHJpb3JpdHk9IjEw IiBRRm9ybWF0PSJ0cnVlIiBOYW1lPSJUaXRsZSIvPg0KPHc6THNkRXhjZXB0aW9uIExvY2tlZD0i ZmFsc2UiIFNlbWlIaWRkZW49InRydWUiIFVuaGlkZVdoZW5Vc2VkPSJ0cnVlIiBOYW1lPSJDbG9z aW5nIi8+DQo8dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJmYWxzZSIgU2VtaUhpZGRlbj0idHJ1ZSIg VW5oaWRlV2hlblVzZWQ9InRydWUiIE5hbWU9IlNpZ25hdHVyZSIvPg0KPHc6THNkRXhjZXB0aW9u IExvY2tlZD0iZmFsc2UiIFByaW9yaXR5PSIxIiBTZW1pSGlkZGVuPSJ0cnVlIiBVbmhpZGVXaGVu VXNlZD0idHJ1ZSIgTmFtZT0iRGVmYXVsdCBQYXJhZ3JhcGggRm9udCIvPg0KPHc6THNkRXhjZXB0 aW9uIExvY2tlZD0iZmFsc2UiIFNlbWlIaWRkZW49InRydWUiIFVuaGlkZVdoZW5Vc2VkPSJ0cnVl IiBOYW1lPSJCb2R5IFRleHQiLz4NCjx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBTZW1p SGlkZGVuPSJ0cnVlIiBVbmhpZGVXaGVuVXNlZD0idHJ1ZSIgTmFtZT0iQm9keSBUZXh0IEluZGVu dCIvPg0KPHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFNlbWlIaWRkZW49InRydWUiIFVu aGlkZVdoZW5Vc2VkPSJ0cnVlIiBOYW1lPSJMaXN0IENvbnRpbnVlIi8+DQo8dzpMc2RFeGNlcHRp b24gTG9ja2VkPSJmYWxzZSIgU2VtaUhpZGRlbj0idHJ1ZSIgVW5oaWRlV2hlblVzZWQ9InRydWUi IE5hbWU9Ikxpc3QgQ29udGludWUgMiIvPg0KPHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFsc2Ui IFNlbWlIaWRkZW49InRydWUiIFVuaGlkZVdoZW5Vc2VkPSJ0cnVlIiBOYW1lPSJMaXN0IENvbnRp bnVlIDMiLz4NCjx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBTZW1pSGlkZGVuPSJ0cnVl IiBVbmhpZGVXaGVuVXNlZD0idHJ1ZSIgTmFtZT0iTGlzdCBDb250aW51ZSA0Ii8+DQo8dzpMc2RF eGNlcHRpb24gTG9ja2VkPSJmYWxzZSIgU2VtaUhpZGRlbj0idHJ1ZSIgVW5oaWRlV2hlblVzZWQ9 InRydWUiIE5hbWU9Ikxpc3QgQ29udGludWUgNSIvPg0KPHc6THNkRXhjZXB0aW9uIExvY2tlZD0i ZmFsc2UiIFNlbWlIaWRkZW49InRydWUiIFVuaGlkZVdoZW5Vc2VkPSJ0cnVlIiBOYW1lPSJNZXNz YWdlIEhlYWRlciIvPg0KPHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFByaW9yaXR5PSIx MSIgUUZvcm1hdD0idHJ1ZSIgTmFtZT0iU3VidGl0bGUiLz4NCjx3OkxzZEV4Y2VwdGlvbiBMb2Nr ZWQ9ImZhbHNlIiBTZW1pSGlkZGVuPSJ0cnVlIiBVbmhpZGVXaGVuVXNlZD0idHJ1ZSIgTmFtZT0i U2FsdXRhdGlvbiIvPg0KPHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFNlbWlIaWRkZW49 InRydWUiIFVuaGlkZVdoZW5Vc2VkPSJ0cnVlIiBOYW1lPSJEYXRlIi8+DQo8dzpMc2RFeGNlcHRp b24gTG9ja2VkPSJmYWxzZSIgU2VtaUhpZGRlbj0idHJ1ZSIgVW5oaWRlV2hlblVzZWQ9InRydWUi IE5hbWU9IkJvZHkgVGV4dCBGaXJzdCBJbmRlbnQiLz4NCjx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9 ImZhbHNlIiBTZW1pSGlkZGVuPSJ0cnVlIiBVbmhpZGVXaGVuVXNlZD0idHJ1ZSIgTmFtZT0iQm9k eSBUZXh0IEZpcnN0IEluZGVudCAyIi8+DQo8dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJmYWxzZSIg U2VtaUhpZGRlbj0idHJ1ZSIgVW5oaWRlV2hlblVzZWQ9InRydWUiIE5hbWU9Ik5vdGUgSGVhZGlu ZyIvPg0KPHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFNlbWlIaWRkZW49InRydWUiIFVu aGlkZVdoZW5Vc2VkPSJ0cnVlIiBOYW1lPSJCb2R5IFRleHQgMiIvPg0KPHc6THNkRXhjZXB0aW9u IExvY2tlZD0iZmFsc2UiIFNlbWlIaWRkZW49InRydWUiIFVuaGlkZVdoZW5Vc2VkPSJ0cnVlIiBO YW1lPSJCb2R5IFRleHQgMyIvPg0KPHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFNlbWlI aWRkZW49InRydWUiIFVuaGlkZVdoZW5Vc2VkPSJ0cnVlIiBOYW1lPSJCb2R5IFRleHQgSW5kZW50 IDIiLz4NCjx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBTZW1pSGlkZGVuPSJ0cnVlIiBV bmhpZGVXaGVuVXNlZD0idHJ1ZSIgTmFtZT0iQm9keSBUZXh0IEluZGVudCAzIi8+DQo8dzpMc2RF eGNlcHRpb24gTG9ja2VkPSJmYWxzZSIgU2VtaUhpZGRlbj0idHJ1ZSIgVW5oaWRlV2hlblVzZWQ9 InRydWUiIE5hbWU9IkJsb2NrIFRleHQiLz4NCjx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNl IiBTZW1pSGlkZGVuPSJ0cnVlIiBVbmhpZGVXaGVuVXNlZD0idHJ1ZSIgTmFtZT0iSHlwZXJsaW5r Ii8+DQo8dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJmYWxzZSIgU2VtaUhpZGRlbj0idHJ1ZSIgVW5o aWRlV2hlblVzZWQ9InRydWUiIE5hbWU9IkZvbGxvd2VkSHlwZXJsaW5rIi8+DQo8dzpMc2RFeGNl cHRpb24gTG9ja2VkPSJmYWxzZSIgUHJpb3JpdHk9IjIyIiBRRm9ybWF0PSJ0cnVlIiBOYW1lPSJT dHJvbmciLz4NCjx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBQcmlvcml0eT0iMjAiIFFG b3JtYXQ9InRydWUiIE5hbWU9IkVtcGhhc2lzIi8+DQo8dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJm YWxzZSIgU2VtaUhpZGRlbj0idHJ1ZSIgVW5oaWRlV2hlblVzZWQ9InRydWUiIE5hbWU9IkRvY3Vt ZW50IE1hcCIvPg0KPHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFNlbWlIaWRkZW49InRy dWUiIFVuaGlkZVdoZW5Vc2VkPSJ0cnVlIiBOYW1lPSJQbGFpbiBUZXh0Ii8+DQo8dzpMc2RFeGNl cHRpb24gTG9ja2VkPSJmYWxzZSIgU2VtaUhpZGRlbj0idHJ1ZSIgVW5oaWRlV2hlblVzZWQ9InRy dWUiIE5hbWU9IkUtbWFpbCBTaWduYXR1cmUiLz4NCjx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZh bHNlIiBTZW1pSGlkZGVuPSJ0cnVlIiBVbmhpZGVXaGVuVXNlZD0idHJ1ZSIgTmFtZT0iSFRNTCBU b3Agb2YgRm9ybSIvPg0KPHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFNlbWlIaWRkZW49 InRydWUiIFVuaGlkZVdoZW5Vc2VkPSJ0cnVlIiBOYW1lPSJIVE1MIEJvdHRvbSBvZiBGb3JtIi8+ DQo8dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJmYWxzZSIgU2VtaUhpZGRlbj0idHJ1ZSIgVW5oaWRl V2hlblVzZWQ9InRydWUiIE5hbWU9Ik5vcm1hbCAoV2ViKSIvPg0KPHc6THNkRXhjZXB0aW9uIExv Y2tlZD0iZmFsc2UiIFNlbWlIaWRkZW49InRydWUiIFVuaGlkZVdoZW5Vc2VkPSJ0cnVlIiBOYW1l PSJIVE1MIEFjcm9ueW0iLz4NCjx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBTZW1pSGlk ZGVuPSJ0cnVlIiBVbmhpZGVXaGVuVXNlZD0idHJ1ZSIgTmFtZT0iSFRNTCBBZGRyZXNzIi8+DQo8 dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJmYWxzZSIgU2VtaUhpZGRlbj0idHJ1ZSIgVW5oaWRlV2hl blVzZWQ9InRydWUiIE5hbWU9IkhUTUwgQ2l0ZSIvPg0KPHc6THNkRXhjZXB0aW9uIExvY2tlZD0i ZmFsc2UiIFNlbWlIaWRkZW49InRydWUiIFVuaGlkZVdoZW5Vc2VkPSJ0cnVlIiBOYW1lPSJIVE1M IENvZGUiLz4NCjx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBTZW1pSGlkZGVuPSJ0cnVl IiBVbmhpZGVXaGVuVXNlZD0idHJ1ZSIgTmFtZT0iSFRNTCBEZWZpbml0aW9uIi8+DQo8dzpMc2RF eGNlcHRpb24gTG9ja2VkPSJmYWxzZSIgU2VtaUhpZGRlbj0idHJ1ZSIgVW5oaWRlV2hlblVzZWQ9 InRydWUiIE5hbWU9IkhUTUwgS2V5Ym9hcmQiLz4NCjx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZh bHNlIiBTZW1pSGlkZGVuPSJ0cnVlIiBVbmhpZGVXaGVuVXNlZD0idHJ1ZSIgTmFtZT0iSFRNTCBQ cmVmb3JtYXR0ZWQiLz4NCjx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBTZW1pSGlkZGVu PSJ0cnVlIiBVbmhpZGVXaGVuVXNlZD0idHJ1ZSIgTmFtZT0iSFRNTCBTYW1wbGUiLz4NCjx3Okxz ZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBTZW1pSGlkZGVuPSJ0cnVlIiBVbmhpZGVXaGVuVXNl ZD0idHJ1ZSIgTmFtZT0iSFRNTCBUeXBld3JpdGVyIi8+DQo8dzpMc2RFeGNlcHRpb24gTG9ja2Vk PSJmYWxzZSIgU2VtaUhpZGRlbj0idHJ1ZSIgVW5oaWRlV2hlblVzZWQ9InRydWUiIE5hbWU9IkhU TUwgVmFyaWFibGUiLz4NCjx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBTZW1pSGlkZGVu PSJ0cnVlIiBVbmhpZGVXaGVuVXNlZD0idHJ1ZSIgTmFtZT0iTm9ybWFsIFRhYmxlIi8+DQo8dzpM c2RFeGNlcHRpb24gTG9ja2VkPSJmYWxzZSIgU2VtaUhpZGRlbj0idHJ1ZSIgVW5oaWRlV2hlblVz ZWQ9InRydWUiIE5hbWU9ImFubm90YXRpb24gc3ViamVjdCIvPg0KPHc6THNkRXhjZXB0aW9uIExv Y2tlZD0iZmFsc2UiIFNlbWlIaWRkZW49InRydWUiIFVuaGlkZVdoZW5Vc2VkPSJ0cnVlIiBOYW1l PSJObyBMaXN0Ii8+DQo8dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJmYWxzZSIgU2VtaUhpZGRlbj0i dHJ1ZSIgVW5oaWRlV2hlblVzZWQ9InRydWUiIE5hbWU9Ik91dGxpbmUgTGlzdCAxIi8+DQo8dzpM c2RFeGNlcHRpb24gTG9ja2VkPSJmYWxzZSIgU2VtaUhpZGRlbj0idHJ1ZSIgVW5oaWRlV2hlblVz ZWQ9InRydWUiIE5hbWU9Ik91dGxpbmUgTGlzdCAyIi8+DQo8dzpMc2RFeGNlcHRpb24gTG9ja2Vk PSJmYWxzZSIgU2VtaUhpZGRlbj0idHJ1ZSIgVW5oaWRlV2hlblVzZWQ9InRydWUiIE5hbWU9Ik91 dGxpbmUgTGlzdCAzIi8+DQo8dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJmYWxzZSIgU2VtaUhpZGRl bj0idHJ1ZSIgVW5oaWRlV2hlblVzZWQ9InRydWUiIE5hbWU9IlRhYmxlIFNpbXBsZSAxIi8+DQo8 dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJmYWxzZSIgU2VtaUhpZGRlbj0idHJ1ZSIgVW5oaWRlV2hl blVzZWQ9InRydWUiIE5hbWU9IlRhYmxlIFNpbXBsZSAyIi8+DQo8dzpMc2RFeGNlcHRpb24gTG9j a2VkPSJmYWxzZSIgU2VtaUhpZGRlbj0idHJ1ZSIgVW5oaWRlV2hlblVzZWQ9InRydWUiIE5hbWU9 IlRhYmxlIFNpbXBsZSAzIi8+DQo8dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJmYWxzZSIgU2VtaUhp ZGRlbj0idHJ1ZSIgVW5oaWRlV2hlblVzZWQ9InRydWUiIE5hbWU9IlRhYmxlIENsYXNzaWMgMSIv Pg0KPHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFNlbWlIaWRkZW49InRydWUiIFVuaGlk ZVdoZW5Vc2VkPSJ0cnVlIiBOYW1lPSJUYWJsZSBDbGFzc2ljIDIiLz4NCjx3OkxzZEV4Y2VwdGlv biBMb2NrZWQ9ImZhbHNlIiBTZW1pSGlkZGVuPSJ0cnVlIiBVbmhpZGVXaGVuVXNlZD0idHJ1ZSIg TmFtZT0iVGFibGUgQ2xhc3NpYyAzIi8+DQo8dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJmYWxzZSIg U2VtaUhpZGRlbj0idHJ1ZSIgVW5oaWRlV2hlblVzZWQ9InRydWUiIE5hbWU9IlRhYmxlIENsYXNz aWMgNCIvPg0KPHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFNlbWlIaWRkZW49InRydWUi IFVuaGlkZVdoZW5Vc2VkPSJ0cnVlIiBOYW1lPSJUYWJsZSBDb2xvcmZ1bCAxIi8+DQo8dzpMc2RF eGNlcHRpb24gTG9ja2VkPSJmYWxzZSIgU2VtaUhpZGRlbj0idHJ1ZSIgVW5oaWRlV2hlblVzZWQ9 InRydWUiIE5hbWU9IlRhYmxlIENvbG9yZnVsIDIiLz4NCjx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9 ImZhbHNlIiBTZW1pSGlkZGVuPSJ0cnVlIiBVbmhpZGVXaGVuVXNlZD0idHJ1ZSIgTmFtZT0iVGFi bGUgQ29sb3JmdWwgMyIvPg0KPHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFNlbWlIaWRk ZW49InRydWUiIFVuaGlkZVdoZW5Vc2VkPSJ0cnVlIiBOYW1lPSJUYWJsZSBDb2x1bW5zIDEiLz4N Cjx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBTZW1pSGlkZGVuPSJ0cnVlIiBVbmhpZGVX aGVuVXNlZD0idHJ1ZSIgTmFtZT0iVGFibGUgQ29sdW1ucyAyIi8+DQo8dzpMc2RFeGNlcHRpb24g TG9ja2VkPSJmYWxzZSIgU2VtaUhpZGRlbj0idHJ1ZSIgVW5oaWRlV2hlblVzZWQ9InRydWUiIE5h bWU9IlRhYmxlIENvbHVtbnMgMyIvPg0KPHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFNl bWlIaWRkZW49InRydWUiIFVuaGlkZVdoZW5Vc2VkPSJ0cnVlIiBOYW1lPSJUYWJsZSBDb2x1bW5z IDQiLz4NCjx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBTZW1pSGlkZGVuPSJ0cnVlIiBV bmhpZGVXaGVuVXNlZD0idHJ1ZSIgTmFtZT0iVGFibGUgQ29sdW1ucyA1Ii8+DQo8dzpMc2RFeGNl cHRpb24gTG9ja2VkPSJmYWxzZSIgU2VtaUhpZGRlbj0idHJ1ZSIgVW5oaWRlV2hlblVzZWQ9InRy dWUiIE5hbWU9IlRhYmxlIEdyaWQgMSIvPg0KPHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFsc2Ui IFNlbWlIaWRkZW49InRydWUiIFVuaGlkZVdoZW5Vc2VkPSJ0cnVlIiBOYW1lPSJUYWJsZSBHcmlk IDIiLz4NCjx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBTZW1pSGlkZGVuPSJ0cnVlIiBV bmhpZGVXaGVuVXNlZD0idHJ1ZSIgTmFtZT0iVGFibGUgR3JpZCAzIi8+DQo8dzpMc2RFeGNlcHRp b24gTG9ja2VkPSJmYWxzZSIgU2VtaUhpZGRlbj0idHJ1ZSIgVW5oaWRlV2hlblVzZWQ9InRydWUi IE5hbWU9IlRhYmxlIEdyaWQgNCIvPg0KPHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFNl bWlIaWRkZW49InRydWUiIFVuaGlkZVdoZW5Vc2VkPSJ0cnVlIiBOYW1lPSJUYWJsZSBHcmlkIDUi Lz4NCjx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBTZW1pSGlkZGVuPSJ0cnVlIiBVbmhp ZGVXaGVuVXNlZD0idHJ1ZSIgTmFtZT0iVGFibGUgR3JpZCA2Ii8+DQo8dzpMc2RFeGNlcHRpb24g TG9ja2VkPSJmYWxzZSIgU2VtaUhpZGRlbj0idHJ1ZSIgVW5oaWRlV2hlblVzZWQ9InRydWUiIE5h bWU9IlRhYmxlIEdyaWQgNyIvPg0KPHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFNlbWlI aWRkZW49InRydWUiIFVuaGlkZVdoZW5Vc2VkPSJ0cnVlIiBOYW1lPSJUYWJsZSBHcmlkIDgiLz4N Cjx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBTZW1pSGlkZGVuPSJ0cnVlIiBVbmhpZGVX aGVuVXNlZD0idHJ1ZSIgTmFtZT0iVGFibGUgTGlzdCAxIi8+DQo8dzpMc2RFeGNlcHRpb24gTG9j a2VkPSJmYWxzZSIgU2VtaUhpZGRlbj0idHJ1ZSIgVW5oaWRlV2hlblVzZWQ9InRydWUiIE5hbWU9 IlRhYmxlIExpc3QgMiIvPg0KPHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFNlbWlIaWRk ZW49InRydWUiIFVuaGlkZVdoZW5Vc2VkPSJ0cnVlIiBOYW1lPSJUYWJsZSBMaXN0IDMiLz4NCjx3 OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBTZW1pSGlkZGVuPSJ0cnVlIiBVbmhpZGVXaGVu VXNlZD0idHJ1ZSIgTmFtZT0iVGFibGUgTGlzdCA0Ii8+DQo8dzpMc2RFeGNlcHRpb24gTG9ja2Vk PSJmYWxzZSIgU2VtaUhpZGRlbj0idHJ1ZSIgVW5oaWRlV2hlblVzZWQ9InRydWUiIE5hbWU9IlRh YmxlIExpc3QgNSIvPg0KPHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFNlbWlIaWRkZW49 InRydWUiIFVuaGlkZVdoZW5Vc2VkPSJ0cnVlIiBOYW1lPSJUYWJsZSBMaXN0IDYiLz4NCjx3Okxz ZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBTZW1pSGlkZGVuPSJ0cnVlIiBVbmhpZGVXaGVuVXNl ZD0idHJ1ZSIgTmFtZT0iVGFibGUgTGlzdCA3Ii8+DQo8dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJm YWxzZSIgU2VtaUhpZGRlbj0idHJ1ZSIgVW5oaWRlV2hlblVzZWQ9InRydWUiIE5hbWU9IlRhYmxl IExpc3QgOCIvPg0KPHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFNlbWlIaWRkZW49InRy dWUiIFVuaGlkZVdoZW5Vc2VkPSJ0cnVlIiBOYW1lPSJUYWJsZSAzRCBlZmZlY3RzIDEiLz4NCjx3 OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBTZW1pSGlkZGVuPSJ0cnVlIiBVbmhpZGVXaGVu VXNlZD0idHJ1ZSIgTmFtZT0iVGFibGUgM0QgZWZmZWN0cyAyIi8+DQo8dzpMc2RFeGNlcHRpb24g TG9ja2VkPSJmYWxzZSIgU2VtaUhpZGRlbj0idHJ1ZSIgVW5oaWRlV2hlblVzZWQ9InRydWUiIE5h bWU9IlRhYmxlIDNEIGVmZmVjdHMgMyIvPg0KPHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFsc2Ui IFNlbWlIaWRkZW49InRydWUiIFVuaGlkZVdoZW5Vc2VkPSJ0cnVlIiBOYW1lPSJUYWJsZSBDb250 ZW1wb3JhcnkiLz4NCjx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBTZW1pSGlkZGVuPSJ0 cnVlIiBVbmhpZGVXaGVuVXNlZD0idHJ1ZSIgTmFtZT0iVGFibGUgRWxlZ2FudCIvPg0KPHc6THNk RXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFNlbWlIaWRkZW49InRydWUiIFVuaGlkZVdoZW5Vc2Vk PSJ0cnVlIiBOYW1lPSJUYWJsZSBQcm9mZXNzaW9uYWwiLz4NCjx3OkxzZEV4Y2VwdGlvbiBMb2Nr ZWQ9ImZhbHNlIiBTZW1pSGlkZGVuPSJ0cnVlIiBVbmhpZGVXaGVuVXNlZD0idHJ1ZSIgTmFtZT0i VGFibGUgU3VidGxlIDEiLz4NCjx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBTZW1pSGlk ZGVuPSJ0cnVlIiBVbmhpZGVXaGVuVXNlZD0idHJ1ZSIgTmFtZT0iVGFibGUgU3VidGxlIDIiLz4N Cjx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBTZW1pSGlkZGVuPSJ0cnVlIiBVbmhpZGVX aGVuVXNlZD0idHJ1ZSIgTmFtZT0iVGFibGUgV2ViIDEiLz4NCjx3OkxzZEV4Y2VwdGlvbiBMb2Nr ZWQ9ImZhbHNlIiBTZW1pSGlkZGVuPSJ0cnVlIiBVbmhpZGVXaGVuVXNlZD0idHJ1ZSIgTmFtZT0i VGFibGUgV2ViIDIiLz4NCjx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBTZW1pSGlkZGVu PSJ0cnVlIiBVbmhpZGVXaGVuVXNlZD0idHJ1ZSIgTmFtZT0iVGFibGUgV2ViIDMiLz4NCjx3Okxz ZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBTZW1pSGlkZGVuPSJ0cnVlIiBVbmhpZGVXaGVuVXNl ZD0idHJ1ZSIgTmFtZT0iQmFsbG9vbiBUZXh0Ii8+DQo8dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJm YWxzZSIgUHJpb3JpdHk9IjU5IiBOYW1lPSJUYWJsZSBHcmlkIi8+DQo8dzpMc2RFeGNlcHRpb24g TG9ja2VkPSJmYWxzZSIgU2VtaUhpZGRlbj0idHJ1ZSIgVW5oaWRlV2hlblVzZWQ9InRydWUiIE5h bWU9IlRhYmxlIFRoZW1lIi8+DQo8dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJmYWxzZSIgU2VtaUhp ZGRlbj0idHJ1ZSIgTmFtZT0iUGxhY2Vob2xkZXIgVGV4dCIvPg0KPHc6THNkRXhjZXB0aW9uIExv Y2tlZD0iZmFsc2UiIFByaW9yaXR5PSIxIiBRRm9ybWF0PSJ0cnVlIiBOYW1lPSJObyBTcGFjaW5n Ii8+DQo8dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJmYWxzZSIgUHJpb3JpdHk9IjYwIiBOYW1lPSJM aWdodCBTaGFkaW5nIi8+DQo8dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJmYWxzZSIgUHJpb3JpdHk9 IjYxIiBOYW1lPSJMaWdodCBMaXN0Ii8+DQo8dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJmYWxzZSIg UHJpb3JpdHk9IjYyIiBOYW1lPSJMaWdodCBHcmlkIi8+DQo8dzpMc2RFeGNlcHRpb24gTG9ja2Vk PSJmYWxzZSIgUHJpb3JpdHk9IjYzIiBOYW1lPSJNZWRpdW0gU2hhZGluZyAxIi8+DQo8dzpMc2RF eGNlcHRpb24gTG9ja2VkPSJmYWxzZSIgUHJpb3JpdHk9IjY0IiBOYW1lPSJNZWRpdW0gU2hhZGlu ZyAyIi8+DQo8dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJmYWxzZSIgUHJpb3JpdHk9IjY1IiBOYW1l PSJNZWRpdW0gTGlzdCAxIi8+DQo8dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJmYWxzZSIgUHJpb3Jp dHk9IjY2IiBOYW1lPSJNZWRpdW0gTGlzdCAyIi8+DQo8dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJm YWxzZSIgUHJpb3JpdHk9IjY3IiBOYW1lPSJNZWRpdW0gR3JpZCAxIi8+DQo8dzpMc2RFeGNlcHRp b24gTG9ja2VkPSJmYWxzZSIgUHJpb3JpdHk9IjY4IiBOYW1lPSJNZWRpdW0gR3JpZCAyIi8+DQo8 dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJmYWxzZSIgUHJpb3JpdHk9IjY5IiBOYW1lPSJNZWRpdW0g R3JpZCAzIi8+DQo8dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJmYWxzZSIgUHJpb3JpdHk9IjcwIiBO YW1lPSJEYXJrIExpc3QiLz4NCjx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBQcmlvcml0 eT0iNzEiIE5hbWU9IkNvbG9yZnVsIFNoYWRpbmciLz4NCjx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9 ImZhbHNlIiBQcmlvcml0eT0iNzIiIE5hbWU9IkNvbG9yZnVsIExpc3QiLz4NCjx3OkxzZEV4Y2Vw dGlvbiBMb2NrZWQ9ImZhbHNlIiBQcmlvcml0eT0iNzMiIE5hbWU9IkNvbG9yZnVsIEdyaWQiLz4N Cjx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBQcmlvcml0eT0iNjAiIE5hbWU9IkxpZ2h0 IFNoYWRpbmcgQWNjZW50IDEiLz4NCjx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBQcmlv cml0eT0iNjEiIE5hbWU9IkxpZ2h0IExpc3QgQWNjZW50IDEiLz4NCjx3OkxzZEV4Y2VwdGlvbiBM b2NrZWQ9ImZhbHNlIiBQcmlvcml0eT0iNjIiIE5hbWU9IkxpZ2h0IEdyaWQgQWNjZW50IDEiLz4N Cjx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBQcmlvcml0eT0iNjMiIE5hbWU9Ik1lZGl1 bSBTaGFkaW5nIDEgQWNjZW50IDEiLz4NCjx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBQ cmlvcml0eT0iNjQiIE5hbWU9Ik1lZGl1bSBTaGFkaW5nIDIgQWNjZW50IDEiLz4NCjx3OkxzZEV4 Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBQcmlvcml0eT0iNjUiIE5hbWU9Ik1lZGl1bSBMaXN0IDEg QWNjZW50IDEiLz4NCjx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBTZW1pSGlkZGVuPSJ0 cnVlIiBOYW1lPSJSZXZpc2lvbiIvPg0KPHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFBy aW9yaXR5PSIzNCIgUUZvcm1hdD0idHJ1ZSIgTmFtZT0iTGlzdCBQYXJhZ3JhcGgiLz4NCjx3Okxz ZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBQcmlvcml0eT0iMjkiIFFGb3JtYXQ9InRydWUiIE5h bWU9IlF1b3RlIi8+DQo8dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJmYWxzZSIgUHJpb3JpdHk9IjMw IiBRRm9ybWF0PSJ0cnVlIiBOYW1lPSJJbnRlbnNlIFF1b3RlIi8+DQo8dzpMc2RFeGNlcHRpb24g TG9ja2VkPSJmYWxzZSIgUHJpb3JpdHk9IjY2IiBOYW1lPSJNZWRpdW0gTGlzdCAyIEFjY2VudCAx Ii8+DQo8dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJmYWxzZSIgUHJpb3JpdHk9IjY3IiBOYW1lPSJN ZWRpdW0gR3JpZCAxIEFjY2VudCAxIi8+DQo8dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJmYWxzZSIg UHJpb3JpdHk9IjY4IiBOYW1lPSJNZWRpdW0gR3JpZCAyIEFjY2VudCAxIi8+DQo8dzpMc2RFeGNl cHRpb24gTG9ja2VkPSJmYWxzZSIgUHJpb3JpdHk9IjY5IiBOYW1lPSJNZWRpdW0gR3JpZCAzIEFj Y2VudCAxIi8+DQo8dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJmYWxzZSIgUHJpb3JpdHk9IjcwIiBO YW1lPSJEYXJrIExpc3QgQWNjZW50IDEiLz4NCjx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNl IiBQcmlvcml0eT0iNzEiIE5hbWU9IkNvbG9yZnVsIFNoYWRpbmcgQWNjZW50IDEiLz4NCjx3Okxz ZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBQcmlvcml0eT0iNzIiIE5hbWU9IkNvbG9yZnVsIExp c3QgQWNjZW50IDEiLz4NCjx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBQcmlvcml0eT0i NzMiIE5hbWU9IkNvbG9yZnVsIEdyaWQgQWNjZW50IDEiLz4NCjx3OkxzZEV4Y2VwdGlvbiBMb2Nr ZWQ9ImZhbHNlIiBQcmlvcml0eT0iNjAiIE5hbWU9IkxpZ2h0IFNoYWRpbmcgQWNjZW50IDIiLz4N Cjx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBQcmlvcml0eT0iNjEiIE5hbWU9IkxpZ2h0 IExpc3QgQWNjZW50IDIiLz4NCjx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBQcmlvcml0 eT0iNjIiIE5hbWU9IkxpZ2h0IEdyaWQgQWNjZW50IDIiLz4NCjx3OkxzZEV4Y2VwdGlvbiBMb2Nr ZWQ9ImZhbHNlIiBQcmlvcml0eT0iNjMiIE5hbWU9Ik1lZGl1bSBTaGFkaW5nIDEgQWNjZW50IDIi Lz4NCjx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBQcmlvcml0eT0iNjQiIE5hbWU9Ik1l ZGl1bSBTaGFkaW5nIDIgQWNjZW50IDIiLz4NCjx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNl IiBQcmlvcml0eT0iNjUiIE5hbWU9Ik1lZGl1bSBMaXN0IDEgQWNjZW50IDIiLz4NCjx3OkxzZEV4 Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBQcmlvcml0eT0iNjYiIE5hbWU9Ik1lZGl1bSBMaXN0IDIg QWNjZW50IDIiLz4NCjx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBQcmlvcml0eT0iNjci IE5hbWU9Ik1lZGl1bSBHcmlkIDEgQWNjZW50IDIiLz4NCjx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9 ImZhbHNlIiBQcmlvcml0eT0iNjgiIE5hbWU9Ik1lZGl1bSBHcmlkIDIgQWNjZW50IDIiLz4NCjx3 OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBQcmlvcml0eT0iNjkiIE5hbWU9Ik1lZGl1bSBH cmlkIDMgQWNjZW50IDIiLz4NCjx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBQcmlvcml0 eT0iNzAiIE5hbWU9IkRhcmsgTGlzdCBBY2NlbnQgMiIvPg0KPHc6THNkRXhjZXB0aW9uIExvY2tl ZD0iZmFsc2UiIFByaW9yaXR5PSI3MSIgTmFtZT0iQ29sb3JmdWwgU2hhZGluZyBBY2NlbnQgMiIv Pg0KPHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFByaW9yaXR5PSI3MiIgTmFtZT0iQ29s b3JmdWwgTGlzdCBBY2NlbnQgMiIvPg0KPHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFBy aW9yaXR5PSI3MyIgTmFtZT0iQ29sb3JmdWwgR3JpZCBBY2NlbnQgMiIvPg0KPHc6THNkRXhjZXB0 aW9uIExvY2tlZD0iZmFsc2UiIFByaW9yaXR5PSI2MCIgTmFtZT0iTGlnaHQgU2hhZGluZyBBY2Nl bnQgMyIvPg0KPHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFByaW9yaXR5PSI2MSIgTmFt ZT0iTGlnaHQgTGlzdCBBY2NlbnQgMyIvPg0KPHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFsc2Ui IFByaW9yaXR5PSI2MiIgTmFtZT0iTGlnaHQgR3JpZCBBY2NlbnQgMyIvPg0KPHc6THNkRXhjZXB0 aW9uIExvY2tlZD0iZmFsc2UiIFByaW9yaXR5PSI2MyIgTmFtZT0iTWVkaXVtIFNoYWRpbmcgMSBB Y2NlbnQgMyIvPg0KPHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFByaW9yaXR5PSI2NCIg TmFtZT0iTWVkaXVtIFNoYWRpbmcgMiBBY2NlbnQgMyIvPg0KPHc6THNkRXhjZXB0aW9uIExvY2tl ZD0iZmFsc2UiIFByaW9yaXR5PSI2NSIgTmFtZT0iTWVkaXVtIExpc3QgMSBBY2NlbnQgMyIvPg0K PHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFByaW9yaXR5PSI2NiIgTmFtZT0iTWVkaXVt IExpc3QgMiBBY2NlbnQgMyIvPg0KPHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFByaW9y aXR5PSI2NyIgTmFtZT0iTWVkaXVtIEdyaWQgMSBBY2NlbnQgMyIvPg0KPHc6THNkRXhjZXB0aW9u IExvY2tlZD0iZmFsc2UiIFByaW9yaXR5PSI2OCIgTmFtZT0iTWVkaXVtIEdyaWQgMiBBY2NlbnQg MyIvPg0KPHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFByaW9yaXR5PSI2OSIgTmFtZT0i TWVkaXVtIEdyaWQgMyBBY2NlbnQgMyIvPg0KPHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFsc2Ui IFByaW9yaXR5PSI3MCIgTmFtZT0iRGFyayBMaXN0IEFjY2VudCAzIi8+DQo8dzpMc2RFeGNlcHRp b24gTG9ja2VkPSJmYWxzZSIgUHJpb3JpdHk9IjcxIiBOYW1lPSJDb2xvcmZ1bCBTaGFkaW5nIEFj Y2VudCAzIi8+DQo8dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJmYWxzZSIgUHJpb3JpdHk9IjcyIiBO YW1lPSJDb2xvcmZ1bCBMaXN0IEFjY2VudCAzIi8+DQo8dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJm YWxzZSIgUHJpb3JpdHk9IjczIiBOYW1lPSJDb2xvcmZ1bCBHcmlkIEFjY2VudCAzIi8+DQo8dzpM c2RFeGNlcHRpb24gTG9ja2VkPSJmYWxzZSIgUHJpb3JpdHk9IjYwIiBOYW1lPSJMaWdodCBTaGFk aW5nIEFjY2VudCA0Ii8+DQo8dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJmYWxzZSIgUHJpb3JpdHk9 IjYxIiBOYW1lPSJMaWdodCBMaXN0IEFjY2VudCA0Ii8+DQo8dzpMc2RFeGNlcHRpb24gTG9ja2Vk PSJmYWxzZSIgUHJpb3JpdHk9IjYyIiBOYW1lPSJMaWdodCBHcmlkIEFjY2VudCA0Ii8+DQo8dzpM c2RFeGNlcHRpb24gTG9ja2VkPSJmYWxzZSIgUHJpb3JpdHk9IjYzIiBOYW1lPSJNZWRpdW0gU2hh ZGluZyAxIEFjY2VudCA0Ii8+DQo8dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJmYWxzZSIgUHJpb3Jp dHk9IjY0IiBOYW1lPSJNZWRpdW0gU2hhZGluZyAyIEFjY2VudCA0Ii8+DQo8dzpMc2RFeGNlcHRp b24gTG9ja2VkPSJmYWxzZSIgUHJpb3JpdHk9IjY1IiBOYW1lPSJNZWRpdW0gTGlzdCAxIEFjY2Vu dCA0Ii8+DQo8dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJmYWxzZSIgUHJpb3JpdHk9IjY2IiBOYW1l PSJNZWRpdW0gTGlzdCAyIEFjY2VudCA0Ii8+DQo8dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJmYWxz ZSIgUHJpb3JpdHk9IjY3IiBOYW1lPSJNZWRpdW0gR3JpZCAxIEFjY2VudCA0Ii8+DQo8dzpMc2RF eGNlcHRpb24gTG9ja2VkPSJmYWxzZSIgUHJpb3JpdHk9IjY4IiBOYW1lPSJNZWRpdW0gR3JpZCAy IEFjY2VudCA0Ii8+DQo8dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJmYWxzZSIgUHJpb3JpdHk9IjY5 IiBOYW1lPSJNZWRpdW0gR3JpZCAzIEFjY2VudCA0Ii8+DQo8dzpMc2RFeGNlcHRpb24gTG9ja2Vk PSJmYWxzZSIgUHJpb3JpdHk9IjcwIiBOYW1lPSJEYXJrIExpc3QgQWNjZW50IDQiLz4NCjx3Okxz ZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBQcmlvcml0eT0iNzEiIE5hbWU9IkNvbG9yZnVsIFNo YWRpbmcgQWNjZW50IDQiLz4NCjx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBQcmlvcml0 eT0iNzIiIE5hbWU9IkNvbG9yZnVsIExpc3QgQWNjZW50IDQiLz4NCjx3OkxzZEV4Y2VwdGlvbiBM b2NrZWQ9ImZhbHNlIiBQcmlvcml0eT0iNzMiIE5hbWU9IkNvbG9yZnVsIEdyaWQgQWNjZW50IDQi Lz4NCjx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBQcmlvcml0eT0iNjAiIE5hbWU9Ikxp Z2h0IFNoYWRpbmcgQWNjZW50IDUiLz4NCjx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBQ cmlvcml0eT0iNjEiIE5hbWU9IkxpZ2h0IExpc3QgQWNjZW50IDUiLz4NCjx3OkxzZEV4Y2VwdGlv biBMb2NrZWQ9ImZhbHNlIiBQcmlvcml0eT0iNjIiIE5hbWU9IkxpZ2h0IEdyaWQgQWNjZW50IDUi Lz4NCjx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBQcmlvcml0eT0iNjMiIE5hbWU9Ik1l ZGl1bSBTaGFkaW5nIDEgQWNjZW50IDUiLz4NCjx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNl IiBQcmlvcml0eT0iNjQiIE5hbWU9Ik1lZGl1bSBTaGFkaW5nIDIgQWNjZW50IDUiLz4NCjx3Okxz ZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBQcmlvcml0eT0iNjUiIE5hbWU9Ik1lZGl1bSBMaXN0 IDEgQWNjZW50IDUiLz4NCjx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBQcmlvcml0eT0i NjYiIE5hbWU9Ik1lZGl1bSBMaXN0IDIgQWNjZW50IDUiLz4NCjx3OkxzZEV4Y2VwdGlvbiBMb2Nr ZWQ9ImZhbHNlIiBQcmlvcml0eT0iNjciIE5hbWU9Ik1lZGl1bSBHcmlkIDEgQWNjZW50IDUiLz4N Cjx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBQcmlvcml0eT0iNjgiIE5hbWU9Ik1lZGl1 bSBHcmlkIDIgQWNjZW50IDUiLz4NCjx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBQcmlv cml0eT0iNjkiIE5hbWU9Ik1lZGl1bSBHcmlkIDMgQWNjZW50IDUiLz4NCjx3OkxzZEV4Y2VwdGlv biBMb2NrZWQ9ImZhbHNlIiBQcmlvcml0eT0iNzAiIE5hbWU9IkRhcmsgTGlzdCBBY2NlbnQgNSIv Pg0KPHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFByaW9yaXR5PSI3MSIgTmFtZT0iQ29s b3JmdWwgU2hhZGluZyBBY2NlbnQgNSIvPg0KPHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFsc2Ui IFByaW9yaXR5PSI3MiIgTmFtZT0iQ29sb3JmdWwgTGlzdCBBY2NlbnQgNSIvPg0KPHc6THNkRXhj ZXB0aW9uIExvY2tlZD0iZmFsc2UiIFByaW9yaXR5PSI3MyIgTmFtZT0iQ29sb3JmdWwgR3JpZCBB Y2NlbnQgNSIvPg0KPHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFByaW9yaXR5PSI2MCIg TmFtZT0iTGlnaHQgU2hhZGluZyBBY2NlbnQgNiIvPg0KPHc6THNkRXhjZXB0aW9uIExvY2tlZD0i ZmFsc2UiIFByaW9yaXR5PSI2MSIgTmFtZT0iTGlnaHQgTGlzdCBBY2NlbnQgNiIvPg0KPHc6THNk RXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFByaW9yaXR5PSI2MiIgTmFtZT0iTGlnaHQgR3JpZCBB Y2NlbnQgNiIvPg0KPHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFByaW9yaXR5PSI2MyIg TmFtZT0iTWVkaXVtIFNoYWRpbmcgMSBBY2NlbnQgNiIvPg0KPHc6THNkRXhjZXB0aW9uIExvY2tl ZD0iZmFsc2UiIFByaW9yaXR5PSI2NCIgTmFtZT0iTWVkaXVtIFNoYWRpbmcgMiBBY2NlbnQgNiIv Pg0KPHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFByaW9yaXR5PSI2NSIgTmFtZT0iTWVk aXVtIExpc3QgMSBBY2NlbnQgNiIvPg0KPHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFBy aW9yaXR5PSI2NiIgTmFtZT0iTWVkaXVtIExpc3QgMiBBY2NlbnQgNiIvPg0KPHc6THNkRXhjZXB0 aW9uIExvY2tlZD0iZmFsc2UiIFByaW9yaXR5PSI2NyIgTmFtZT0iTWVkaXVtIEdyaWQgMSBBY2Nl bnQgNiIvPg0KPHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFByaW9yaXR5PSI2OCIgTmFt ZT0iTWVkaXVtIEdyaWQgMiBBY2NlbnQgNiIvPg0KPHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFs c2UiIFByaW9yaXR5PSI2OSIgTmFtZT0iTWVkaXVtIEdyaWQgMyBBY2NlbnQgNiIvPg0KPHc6THNk RXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFByaW9yaXR5PSI3MCIgTmFtZT0iRGFyayBMaXN0IEFj Y2VudCA2Ii8+DQo8dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJmYWxzZSIgUHJpb3JpdHk9IjcxIiBO YW1lPSJDb2xvcmZ1bCBTaGFkaW5nIEFjY2VudCA2Ii8+DQo8dzpMc2RFeGNlcHRpb24gTG9ja2Vk PSJmYWxzZSIgUHJpb3JpdHk9IjcyIiBOYW1lPSJDb2xvcmZ1bCBMaXN0IEFjY2VudCA2Ii8+DQo8 dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJmYWxzZSIgUHJpb3JpdHk9IjczIiBOYW1lPSJDb2xvcmZ1 bCBHcmlkIEFjY2VudCA2Ii8+DQo8dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJmYWxzZSIgUHJpb3Jp dHk9IjE5IiBRRm9ybWF0PSJ0cnVlIiBOYW1lPSJTdWJ0bGUgRW1waGFzaXMiLz4NCjx3OkxzZEV4 Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBQcmlvcml0eT0iMjEiIFFGb3JtYXQ9InRydWUiIE5hbWU9 IkludGVuc2UgRW1waGFzaXMiLz4NCjx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBQcmlv cml0eT0iMzEiIFFGb3JtYXQ9InRydWUiIE5hbWU9IlN1YnRsZSBSZWZlcmVuY2UiLz4NCjx3Okxz ZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBQcmlvcml0eT0iMzIiIFFGb3JtYXQ9InRydWUiIE5h bWU9IkludGVuc2UgUmVmZXJlbmNlIi8+DQo8dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJmYWxzZSIg UHJpb3JpdHk9IjMzIiBRRm9ybWF0PSJ0cnVlIiBOYW1lPSJCb29rIFRpdGxlIi8+DQo8dzpMc2RF eGNlcHRpb24gTG9ja2VkPSJmYWxzZSIgUHJpb3JpdHk9IjM3IiBTZW1pSGlkZGVuPSJ0cnVlIiBV bmhpZGVXaGVuVXNlZD0idHJ1ZSIgTmFtZT0iQmlibGlvZ3JhcGh5Ii8+DQo8dzpMc2RFeGNlcHRp b24gTG9ja2VkPSJmYWxzZSIgUHJpb3JpdHk9IjM5IiBTZW1pSGlkZGVuPSJ0cnVlIiBVbmhpZGVX aGVuVXNlZD0idHJ1ZSIgUUZvcm1hdD0idHJ1ZSIgTmFtZT0iVE9DIEhlYWRpbmciLz4NCjx3Okxz ZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBQcmlvcml0eT0iNDEiIE5hbWU9IlBsYWluIFRhYmxl IDEiLz4NCjx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBQcmlvcml0eT0iNDIiIE5hbWU9 IlBsYWluIFRhYmxlIDIiLz4NCjx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBQcmlvcml0 eT0iNDMiIE5hbWU9IlBsYWluIFRhYmxlIDMiLz4NCjx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZh bHNlIiBQcmlvcml0eT0iNDQiIE5hbWU9IlBsYWluIFRhYmxlIDQiLz4NCjx3OkxzZEV4Y2VwdGlv biBMb2NrZWQ9ImZhbHNlIiBQcmlvcml0eT0iNDUiIE5hbWU9IlBsYWluIFRhYmxlIDUiLz4NCjx3 OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBQcmlvcml0eT0iNDAiIE5hbWU9IkdyaWQgVGFi bGUgTGlnaHQiLz4NCjx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBQcmlvcml0eT0iNDYi IE5hbWU9IkdyaWQgVGFibGUgMSBMaWdodCIvPg0KPHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFs c2UiIFByaW9yaXR5PSI0NyIgTmFtZT0iR3JpZCBUYWJsZSAyIi8+DQo8dzpMc2RFeGNlcHRpb24g TG9ja2VkPSJmYWxzZSIgUHJpb3JpdHk9IjQ4IiBOYW1lPSJHcmlkIFRhYmxlIDMiLz4NCjx3Okxz ZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBQcmlvcml0eT0iNDkiIE5hbWU9IkdyaWQgVGFibGUg NCIvPg0KPHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFByaW9yaXR5PSI1MCIgTmFtZT0i R3JpZCBUYWJsZSA1IERhcmsiLz4NCjx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBQcmlv cml0eT0iNTEiIE5hbWU9IkdyaWQgVGFibGUgNiBDb2xvcmZ1bCIvPg0KPHc6THNkRXhjZXB0aW9u IExvY2tlZD0iZmFsc2UiIFByaW9yaXR5PSI1MiIgTmFtZT0iR3JpZCBUYWJsZSA3IENvbG9yZnVs Ii8+DQo8dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJmYWxzZSIgUHJpb3JpdHk9IjQ2IiBOYW1lPSJH cmlkIFRhYmxlIDEgTGlnaHQgQWNjZW50IDEiLz4NCjx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZh bHNlIiBQcmlvcml0eT0iNDciIE5hbWU9IkdyaWQgVGFibGUgMiBBY2NlbnQgMSIvPg0KPHc6THNk RXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFByaW9yaXR5PSI0OCIgTmFtZT0iR3JpZCBUYWJsZSAz IEFjY2VudCAxIi8+DQo8dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJmYWxzZSIgUHJpb3JpdHk9IjQ5 IiBOYW1lPSJHcmlkIFRhYmxlIDQgQWNjZW50IDEiLz4NCjx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9 ImZhbHNlIiBQcmlvcml0eT0iNTAiIE5hbWU9IkdyaWQgVGFibGUgNSBEYXJrIEFjY2VudCAxIi8+ DQo8dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJmYWxzZSIgUHJpb3JpdHk9IjUxIiBOYW1lPSJHcmlk IFRhYmxlIDYgQ29sb3JmdWwgQWNjZW50IDEiLz4NCjx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZh bHNlIiBQcmlvcml0eT0iNTIiIE5hbWU9IkdyaWQgVGFibGUgNyBDb2xvcmZ1bCBBY2NlbnQgMSIv Pg0KPHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFByaW9yaXR5PSI0NiIgTmFtZT0iR3Jp ZCBUYWJsZSAxIExpZ2h0IEFjY2VudCAyIi8+DQo8dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJmYWxz ZSIgUHJpb3JpdHk9IjQ3IiBOYW1lPSJHcmlkIFRhYmxlIDIgQWNjZW50IDIiLz4NCjx3OkxzZEV4 Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBQcmlvcml0eT0iNDgiIE5hbWU9IkdyaWQgVGFibGUgMyBB Y2NlbnQgMiIvPg0KPHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFByaW9yaXR5PSI0OSIg TmFtZT0iR3JpZCBUYWJsZSA0IEFjY2VudCAyIi8+DQo8dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJm YWxzZSIgUHJpb3JpdHk9IjUwIiBOYW1lPSJHcmlkIFRhYmxlIDUgRGFyayBBY2NlbnQgMiIvPg0K PHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFByaW9yaXR5PSI1MSIgTmFtZT0iR3JpZCBU YWJsZSA2IENvbG9yZnVsIEFjY2VudCAyIi8+DQo8dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJmYWxz ZSIgUHJpb3JpdHk9IjUyIiBOYW1lPSJHcmlkIFRhYmxlIDcgQ29sb3JmdWwgQWNjZW50IDIiLz4N Cjx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBQcmlvcml0eT0iNDYiIE5hbWU9IkdyaWQg VGFibGUgMSBMaWdodCBBY2NlbnQgMyIvPg0KPHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFsc2Ui IFByaW9yaXR5PSI0NyIgTmFtZT0iR3JpZCBUYWJsZSAyIEFjY2VudCAzIi8+DQo8dzpMc2RFeGNl cHRpb24gTG9ja2VkPSJmYWxzZSIgUHJpb3JpdHk9IjQ4IiBOYW1lPSJHcmlkIFRhYmxlIDMgQWNj ZW50IDMiLz4NCjx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBQcmlvcml0eT0iNDkiIE5h bWU9IkdyaWQgVGFibGUgNCBBY2NlbnQgMyIvPg0KPHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFs c2UiIFByaW9yaXR5PSI1MCIgTmFtZT0iR3JpZCBUYWJsZSA1IERhcmsgQWNjZW50IDMiLz4NCjx3 OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBQcmlvcml0eT0iNTEiIE5hbWU9IkdyaWQgVGFi bGUgNiBDb2xvcmZ1bCBBY2NlbnQgMyIvPg0KPHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFsc2Ui IFByaW9yaXR5PSI1MiIgTmFtZT0iR3JpZCBUYWJsZSA3IENvbG9yZnVsIEFjY2VudCAzIi8+DQo8 dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJmYWxzZSIgUHJpb3JpdHk9IjQ2IiBOYW1lPSJHcmlkIFRh YmxlIDEgTGlnaHQgQWNjZW50IDQiLz4NCjx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBQ cmlvcml0eT0iNDciIE5hbWU9IkdyaWQgVGFibGUgMiBBY2NlbnQgNCIvPg0KPHc6THNkRXhjZXB0 aW9uIExvY2tlZD0iZmFsc2UiIFByaW9yaXR5PSI0OCIgTmFtZT0iR3JpZCBUYWJsZSAzIEFjY2Vu dCA0Ii8+DQo8dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJmYWxzZSIgUHJpb3JpdHk9IjQ5IiBOYW1l PSJHcmlkIFRhYmxlIDQgQWNjZW50IDQiLz4NCjx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNl IiBQcmlvcml0eT0iNTAiIE5hbWU9IkdyaWQgVGFibGUgNSBEYXJrIEFjY2VudCA0Ii8+DQo8dzpM c2RFeGNlcHRpb24gTG9ja2VkPSJmYWxzZSIgUHJpb3JpdHk9IjUxIiBOYW1lPSJHcmlkIFRhYmxl IDYgQ29sb3JmdWwgQWNjZW50IDQiLz4NCjx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBQ cmlvcml0eT0iNTIiIE5hbWU9IkdyaWQgVGFibGUgNyBDb2xvcmZ1bCBBY2NlbnQgNCIvPg0KPHc6 THNkRXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFByaW9yaXR5PSI0NiIgTmFtZT0iR3JpZCBUYWJs ZSAxIExpZ2h0IEFjY2VudCA1Ii8+DQo8dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJmYWxzZSIgUHJp b3JpdHk9IjQ3IiBOYW1lPSJHcmlkIFRhYmxlIDIgQWNjZW50IDUiLz4NCjx3OkxzZEV4Y2VwdGlv biBMb2NrZWQ9ImZhbHNlIiBQcmlvcml0eT0iNDgiIE5hbWU9IkdyaWQgVGFibGUgMyBBY2NlbnQg NSIvPg0KPHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFByaW9yaXR5PSI0OSIgTmFtZT0i R3JpZCBUYWJsZSA0IEFjY2VudCA1Ii8+DQo8dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJmYWxzZSIg UHJpb3JpdHk9IjUwIiBOYW1lPSJHcmlkIFRhYmxlIDUgRGFyayBBY2NlbnQgNSIvPg0KPHc6THNk RXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFByaW9yaXR5PSI1MSIgTmFtZT0iR3JpZCBUYWJsZSA2 IENvbG9yZnVsIEFjY2VudCA1Ii8+DQo8dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJmYWxzZSIgUHJp b3JpdHk9IjUyIiBOYW1lPSJHcmlkIFRhYmxlIDcgQ29sb3JmdWwgQWNjZW50IDUiLz4NCjx3Okxz ZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBQcmlvcml0eT0iNDYiIE5hbWU9IkdyaWQgVGFibGUg MSBMaWdodCBBY2NlbnQgNiIvPg0KPHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFByaW9y aXR5PSI0NyIgTmFtZT0iR3JpZCBUYWJsZSAyIEFjY2VudCA2Ii8+DQo8dzpMc2RFeGNlcHRpb24g TG9ja2VkPSJmYWxzZSIgUHJpb3JpdHk9IjQ4IiBOYW1lPSJHcmlkIFRhYmxlIDMgQWNjZW50IDYi Lz4NCjx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBQcmlvcml0eT0iNDkiIE5hbWU9Ikdy aWQgVGFibGUgNCBBY2NlbnQgNiIvPg0KPHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFBy aW9yaXR5PSI1MCIgTmFtZT0iR3JpZCBUYWJsZSA1IERhcmsgQWNjZW50IDYiLz4NCjx3OkxzZEV4 Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBQcmlvcml0eT0iNTEiIE5hbWU9IkdyaWQgVGFibGUgNiBD b2xvcmZ1bCBBY2NlbnQgNiIvPg0KPHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFByaW9y aXR5PSI1MiIgTmFtZT0iR3JpZCBUYWJsZSA3IENvbG9yZnVsIEFjY2VudCA2Ii8+DQo8dzpMc2RF eGNlcHRpb24gTG9ja2VkPSJmYWxzZSIgUHJpb3JpdHk9IjQ2IiBOYW1lPSJMaXN0IFRhYmxlIDEg TGlnaHQiLz4NCjx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBQcmlvcml0eT0iNDciIE5h bWU9Ikxpc3QgVGFibGUgMiIvPg0KPHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFByaW9y aXR5PSI0OCIgTmFtZT0iTGlzdCBUYWJsZSAzIi8+DQo8dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJm YWxzZSIgUHJpb3JpdHk9IjQ5IiBOYW1lPSJMaXN0IFRhYmxlIDQiLz4NCjx3OkxzZEV4Y2VwdGlv biBMb2NrZWQ9ImZhbHNlIiBQcmlvcml0eT0iNTAiIE5hbWU9Ikxpc3QgVGFibGUgNSBEYXJrIi8+ DQo8dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJmYWxzZSIgUHJpb3JpdHk9IjUxIiBOYW1lPSJMaXN0 IFRhYmxlIDYgQ29sb3JmdWwiLz4NCjx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBQcmlv cml0eT0iNTIiIE5hbWU9Ikxpc3QgVGFibGUgNyBDb2xvcmZ1bCIvPg0KPHc6THNkRXhjZXB0aW9u IExvY2tlZD0iZmFsc2UiIFByaW9yaXR5PSI0NiIgTmFtZT0iTGlzdCBUYWJsZSAxIExpZ2h0IEFj Y2VudCAxIi8+DQo8dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJmYWxzZSIgUHJpb3JpdHk9IjQ3IiBO YW1lPSJMaXN0IFRhYmxlIDIgQWNjZW50IDEiLz4NCjx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZh bHNlIiBQcmlvcml0eT0iNDgiIE5hbWU9Ikxpc3QgVGFibGUgMyBBY2NlbnQgMSIvPg0KPHc6THNk RXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFByaW9yaXR5PSI0OSIgTmFtZT0iTGlzdCBUYWJsZSA0 IEFjY2VudCAxIi8+DQo8dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJmYWxzZSIgUHJpb3JpdHk9IjUw IiBOYW1lPSJMaXN0IFRhYmxlIDUgRGFyayBBY2NlbnQgMSIvPg0KPHc6THNkRXhjZXB0aW9uIExv Y2tlZD0iZmFsc2UiIFByaW9yaXR5PSI1MSIgTmFtZT0iTGlzdCBUYWJsZSA2IENvbG9yZnVsIEFj Y2VudCAxIi8+DQo8dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJmYWxzZSIgUHJpb3JpdHk9IjUyIiBO YW1lPSJMaXN0IFRhYmxlIDcgQ29sb3JmdWwgQWNjZW50IDEiLz4NCjx3OkxzZEV4Y2VwdGlvbiBM b2NrZWQ9ImZhbHNlIiBQcmlvcml0eT0iNDYiIE5hbWU9Ikxpc3QgVGFibGUgMSBMaWdodCBBY2Nl bnQgMiIvPg0KPHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFByaW9yaXR5PSI0NyIgTmFt ZT0iTGlzdCBUYWJsZSAyIEFjY2VudCAyIi8+DQo8dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJmYWxz ZSIgUHJpb3JpdHk9IjQ4IiBOYW1lPSJMaXN0IFRhYmxlIDMgQWNjZW50IDIiLz4NCjx3OkxzZEV4 Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBQcmlvcml0eT0iNDkiIE5hbWU9Ikxpc3QgVGFibGUgNCBB Y2NlbnQgMiIvPg0KPHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFByaW9yaXR5PSI1MCIg TmFtZT0iTGlzdCBUYWJsZSA1IERhcmsgQWNjZW50IDIiLz4NCjx3OkxzZEV4Y2VwdGlvbiBMb2Nr ZWQ9ImZhbHNlIiBQcmlvcml0eT0iNTEiIE5hbWU9Ikxpc3QgVGFibGUgNiBDb2xvcmZ1bCBBY2Nl bnQgMiIvPg0KPHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFByaW9yaXR5PSI1MiIgTmFt ZT0iTGlzdCBUYWJsZSA3IENvbG9yZnVsIEFjY2VudCAyIi8+DQo8dzpMc2RFeGNlcHRpb24gTG9j a2VkPSJmYWxzZSIgUHJpb3JpdHk9IjQ2IiBOYW1lPSJMaXN0IFRhYmxlIDEgTGlnaHQgQWNjZW50 IDMiLz4NCjx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBQcmlvcml0eT0iNDciIE5hbWU9 Ikxpc3QgVGFibGUgMiBBY2NlbnQgMyIvPg0KPHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFsc2Ui IFByaW9yaXR5PSI0OCIgTmFtZT0iTGlzdCBUYWJsZSAzIEFjY2VudCAzIi8+DQo8dzpMc2RFeGNl cHRpb24gTG9ja2VkPSJmYWxzZSIgUHJpb3JpdHk9IjQ5IiBOYW1lPSJMaXN0IFRhYmxlIDQgQWNj ZW50IDMiLz4NCjx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBQcmlvcml0eT0iNTAiIE5h bWU9Ikxpc3QgVGFibGUgNSBEYXJrIEFjY2VudCAzIi8+DQo8dzpMc2RFeGNlcHRpb24gTG9ja2Vk PSJmYWxzZSIgUHJpb3JpdHk9IjUxIiBOYW1lPSJMaXN0IFRhYmxlIDYgQ29sb3JmdWwgQWNjZW50 IDMiLz4NCjx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBQcmlvcml0eT0iNTIiIE5hbWU9 Ikxpc3QgVGFibGUgNyBDb2xvcmZ1bCBBY2NlbnQgMyIvPg0KPHc6THNkRXhjZXB0aW9uIExvY2tl ZD0iZmFsc2UiIFByaW9yaXR5PSI0NiIgTmFtZT0iTGlzdCBUYWJsZSAxIExpZ2h0IEFjY2VudCA0 Ii8+DQo8dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJmYWxzZSIgUHJpb3JpdHk9IjQ3IiBOYW1lPSJM aXN0IFRhYmxlIDIgQWNjZW50IDQiLz4NCjx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBQ cmlvcml0eT0iNDgiIE5hbWU9Ikxpc3QgVGFibGUgMyBBY2NlbnQgNCIvPg0KPHc6THNkRXhjZXB0 aW9uIExvY2tlZD0iZmFsc2UiIFByaW9yaXR5PSI0OSIgTmFtZT0iTGlzdCBUYWJsZSA0IEFjY2Vu dCA0Ii8+DQo8dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJmYWxzZSIgUHJpb3JpdHk9IjUwIiBOYW1l PSJMaXN0IFRhYmxlIDUgRGFyayBBY2NlbnQgNCIvPg0KPHc6THNkRXhjZXB0aW9uIExvY2tlZD0i ZmFsc2UiIFByaW9yaXR5PSI1MSIgTmFtZT0iTGlzdCBUYWJsZSA2IENvbG9yZnVsIEFjY2VudCA0 Ii8+DQo8dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJmYWxzZSIgUHJpb3JpdHk9IjUyIiBOYW1lPSJM aXN0IFRhYmxlIDcgQ29sb3JmdWwgQWNjZW50IDQiLz4NCjx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9 ImZhbHNlIiBQcmlvcml0eT0iNDYiIE5hbWU9Ikxpc3QgVGFibGUgMSBMaWdodCBBY2NlbnQgNSIv Pg0KPHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFByaW9yaXR5PSI0NyIgTmFtZT0iTGlz dCBUYWJsZSAyIEFjY2VudCA1Ii8+DQo8dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJmYWxzZSIgUHJp b3JpdHk9IjQ4IiBOYW1lPSJMaXN0IFRhYmxlIDMgQWNjZW50IDUiLz4NCjx3OkxzZEV4Y2VwdGlv biBMb2NrZWQ9ImZhbHNlIiBQcmlvcml0eT0iNDkiIE5hbWU9Ikxpc3QgVGFibGUgNCBBY2NlbnQg NSIvPg0KPHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFByaW9yaXR5PSI1MCIgTmFtZT0i TGlzdCBUYWJsZSA1IERhcmsgQWNjZW50IDUiLz4NCjx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZh bHNlIiBQcmlvcml0eT0iNTEiIE5hbWU9Ikxpc3QgVGFibGUgNiBDb2xvcmZ1bCBBY2NlbnQgNSIv Pg0KPHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFByaW9yaXR5PSI1MiIgTmFtZT0iTGlz dCBUYWJsZSA3IENvbG9yZnVsIEFjY2VudCA1Ii8+DQo8dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJm YWxzZSIgUHJpb3JpdHk9IjQ2IiBOYW1lPSJMaXN0IFRhYmxlIDEgTGlnaHQgQWNjZW50IDYiLz4N Cjx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBQcmlvcml0eT0iNDciIE5hbWU9Ikxpc3Qg VGFibGUgMiBBY2NlbnQgNiIvPg0KPHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFByaW9y aXR5PSI0OCIgTmFtZT0iTGlzdCBUYWJsZSAzIEFjY2VudCA2Ii8+DQo8dzpMc2RFeGNlcHRpb24g TG9ja2VkPSJmYWxzZSIgUHJpb3JpdHk9IjQ5IiBOYW1lPSJMaXN0IFRhYmxlIDQgQWNjZW50IDYi Lz4NCjx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBQcmlvcml0eT0iNTAiIE5hbWU9Ikxp c3QgVGFibGUgNSBEYXJrIEFjY2VudCA2Ii8+DQo8dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJmYWxz ZSIgUHJpb3JpdHk9IjUxIiBOYW1lPSJMaXN0IFRhYmxlIDYgQ29sb3JmdWwgQWNjZW50IDYiLz4N Cjx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBQcmlvcml0eT0iNTIiIE5hbWU9Ikxpc3Qg VGFibGUgNyBDb2xvcmZ1bCBBY2NlbnQgNiIvPg0KPC93OkxhdGVudFN0eWxlcz4NCjwveG1sPjwh W2VuZGlmXS0tPjxzdHlsZT48IS0tDQovKiBGb250IERlZmluaXRpb25zICovDQpAZm9udC1mYWNl DQoJe2ZvbnQtZmFtaWx5OiJDYW1icmlhIE1hdGgiOw0KCXBhbm9zZS0xOjIgNCA1IDMgNSA0IDYg MyAyIDQ7DQoJbXNvLWZvbnQtY2hhcnNldDoxOw0KCW1zby1nZW5lcmljLWZvbnQtZmFtaWx5OnJv bWFuOw0KCW1zby1mb250LWZvcm1hdDpvdGhlcjsNCgltc28tZm9udC1waXRjaDp2YXJpYWJsZTsN Cgltc28tZm9udC1zaWduYXR1cmU6MCAwIDAgMCAwIDA7fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZh bWlseTpDYWxpYnJpOw0KCXBhbm9zZS0xOjIgMTUgNSAyIDIgMiA0IDMgMiA0Ow0KCW1zby1mb250 LWNoYXJzZXQ6MDsNCgltc28tZ2VuZXJpYy1mb250LWZhbWlseTpzd2lzczsNCgltc28tZm9udC1w aXRjaDp2YXJpYWJsZTsNCgltc28tZm9udC1zaWduYXR1cmU6LTUzNjg3MDE0NSAxMDczNzg2MTEx IDEgMCA0MTUgMDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OlRhaG9tYTsNCglwYW5vc2Ut MToyIDExIDYgNCAzIDUgNCA0IDIgNDsNCgltc28tZm9udC1jaGFyc2V0OjA7DQoJbXNvLWdlbmVy aWMtZm9udC1mYW1pbHk6c3dpc3M7DQoJbXNvLWZvbnQtcGl0Y2g6dmFyaWFibGU7DQoJbXNvLWZv bnQtc2lnbmF0dXJlOi01MjAwODE2NjUgLTEwNzM3MTcxNTcgNDEgMCA2NjA0NyAwO30NCi8qIFN0 eWxlIERlZmluaXRpb25zICovDQpwLk1zb05vcm1hbCwgbGkuTXNvTm9ybWFsLCBkaXYuTXNvTm9y bWFsDQoJe21zby1zdHlsZS11bmhpZGU6bm87DQoJbXNvLXN0eWxlLXFmb3JtYXQ6eWVzOw0KCW1z by1zdHlsZS1wYXJlbnQ6IiI7DQoJbWFyZ2luOjBpbjsNCgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7 DQoJbXNvLXBhZ2luYXRpb246d2lkb3ctb3JwaGFuOw0KCWZvbnQtc2l6ZToxMi4wcHQ7DQoJZm9u dC1mYW1pbHk6IlRpbWVzIE5ldyBSb21hbiIsc2VyaWY7DQoJbXNvLWZhcmVhc3QtZm9udC1mYW1p bHk6Q2FsaWJyaTt9DQphOmxpbmssIHNwYW4uTXNvSHlwZXJsaW5rDQoJe21zby1zdHlsZS1ub3No b3c6eWVzOw0KCW1zby1zdHlsZS1wcmlvcml0eTo5OTsNCgljb2xvcjpibHVlOw0KCXRleHQtZGVj b3JhdGlvbjp1bmRlcmxpbmU7DQoJdGV4dC11bmRlcmxpbmU6c2luZ2xlO30NCmE6dmlzaXRlZCwg c3Bhbi5Nc29IeXBlcmxpbmtGb2xsb3dlZA0KCXttc28tc3R5bGUtbm9zaG93OnllczsNCgltc28t c3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6cHVycGxlOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRl cmxpbmU7DQoJdGV4dC11bmRlcmxpbmU6c2luZ2xlO30NCnNwYW4uRW1haWxTdHlsZTE3DQoJe21z by1zdHlsZS10eXBlOnBlcnNvbmFsLXJlcGx5Ow0KCW1zby1zdHlsZS1ub3Nob3c6eWVzOw0KCW1z by1zdHlsZS11bmhpZGU6bm87DQoJbXNvLWFuc2ktZm9udC1zaXplOjExLjBwdDsNCgltc28tYmlk aS1mb250LXNpemU6MTEuMHB0Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIixzYW5zLXNlcmlmOw0K CW1zby1hc2NpaS1mb250LWZhbWlseTpDYWxpYnJpOw0KCW1zby1mYXJlYXN0LWZvbnQtZmFtaWx5 OkNhbGlicmk7DQoJbXNvLWhhbnNpLWZvbnQtZmFtaWx5OkNhbGlicmk7DQoJbXNvLWJpZGktZm9u dC1mYW1pbHk6IlRpbWVzIE5ldyBSb21hbiI7DQoJY29sb3I6IzFGNDk3RDt9DQpzcGFuLlNwZWxs RQ0KCXttc28tc3R5bGUtbmFtZToiIjsNCgltc28tc3BsLWU6eWVzO30NCi5Nc29DaHBEZWZhdWx0 DQoJe21zby1zdHlsZS10eXBlOmV4cG9ydC1vbmx5Ow0KCW1zby1kZWZhdWx0LXByb3BzOnllczsN Cglmb250LWZhbWlseToiQ2FsaWJyaSIsc2Fucy1zZXJpZjsNCgltc28tYXNjaWktZm9udC1mYW1p bHk6Q2FsaWJyaTsNCgltc28tZmFyZWFzdC1mb250LWZhbWlseTpDYWxpYnJpOw0KCW1zby1oYW5z aS1mb250LWZhbWlseTpDYWxpYnJpOw0KCW1zby1iaWRpLWZvbnQtZmFtaWx5OiJUaW1lcyBOZXcg Um9tYW4iO30NCkBwYWdlIFdvcmRTZWN0aW9uMQ0KCXtzaXplOjguNWluIDExLjBpbjsNCgltYXJn aW46MS4waW4gMS4waW4gMS4waW4gMS4waW47DQoJbXNvLWhlYWRlci1tYXJnaW46LjVpbjsNCglt c28tZm9vdGVyLW1hcmdpbjouNWluOw0KCW1zby1wYXBlci1zb3VyY2U6MDt9DQpkaXYuV29yZFNl Y3Rpb24xDQoJe3BhZ2U6V29yZFNlY3Rpb24xO30NCi0tPjwvc3R5bGU+PCEtLVtpZiBndGUgbXNv IDEwXT48c3R5bGU+LyogU3R5bGUgRGVmaW5pdGlvbnMgKi8NCnRhYmxlLk1zb05vcm1hbFRhYmxl DQoJe21zby1zdHlsZS1uYW1lOiJUYWJsZSBOb3JtYWwiOw0KCW1zby10c3R5bGUtcm93YmFuZC1z aXplOjA7DQoJbXNvLXRzdHlsZS1jb2xiYW5kLXNpemU6MDsNCgltc28tc3R5bGUtbm9zaG93Onll czsNCgltc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJbXNvLXN0eWxlLXBhcmVudDoiIjsNCgltc28t cGFkZGluZy1hbHQ6MGluIDUuNHB0IDBpbiA1LjRwdDsNCgltc28tcGFyYS1tYXJnaW46MGluOw0K CW1zby1wYXJhLW1hcmdpbi1ib3R0b206LjAwMDFwdDsNCgltc28tcGFnaW5hdGlvbjp3aWRvdy1v cnBoYW47DQoJZm9udC1zaXplOjExLjBwdDsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsc2Fucy1z ZXJpZjsNCgltc28tYXNjaWktZm9udC1mYW1pbHk6Q2FsaWJyaTsNCgltc28taGFuc2ktZm9udC1m YW1pbHk6Q2FsaWJyaTt9DQo8L3N0eWxlPjwhW2VuZGlmXS0tPjwhLS1baWYgZ3RlIG1zbyA5XT48 eG1sPg0KPG86c2hhcGVkZWZhdWx0cyB2OmV4dD0iZWRpdCIgc3BpZG1heD0iMTAyNiIgLz4NCjwv eG1sPjwhW2VuZGlmXS0tPjwhLS1baWYgZ3RlIG1zbyA5XT48eG1sPg0KPG86c2hhcGVsYXlvdXQg djpleHQ9ImVkaXQiPg0KPG86aWRtYXAgdjpleHQ9ImVkaXQiIGRhdGE9IjEiIC8+DQo8L286c2hh cGVsYXlvdXQ+PC94bWw+PCFbZW5kaWZdLS0+DQo8L2hlYWQ+DQo8Ym9keSBsYW5nPSJFTi1VUyIg bGluaz0iYmx1ZSIgdmxpbms9InB1cnBsZSIgc3R5bGU9InRhYi1pbnRlcnZhbDouNWluIj4NCjxk aXYgY2xhc3M9IldvcmRTZWN0aW9uMSI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHls ZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMt c2VyaWY7bXNvLWJpZGktZm9udC1mYW1pbHk6JnF1b3Q7VGltZXMgTmV3IFJvbWFuJnF1b3Q7O2Nv bG9yOiMxRjQ5N0QiPkhpIGd1eXMsPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7 Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO21zby1iaWRpLWZvbnQtZmFtaWx5OiZxdW90O1RpbWVz IE5ldyBSb21hbiZxdW90Oztjb2xvcjojMUY0OTdEIj5UaHJlZSBidXN5IHdlZWtzIGFuZCBhbiBJ RVRGIG1lZXRpbmcgaGF2ZSBwYXN04oCmIFdoZW4gc2hvdWxkIHdlIGV4cGVjdCB0byBzZWUgdGhl IGZlZWRiYWNrIHRvIHRoZSByZXZpZXc/PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1 b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO21zby1iaWRpLWZvbnQtZmFtaWx5OiZxdW90O1Rp bWVzIE5ldyBSb21hbiZxdW90Oztjb2xvcjojMUY0OTdEIj5UaGFua3MgYW5kIGNoZWVycyw8bzpw PjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9u dC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7 bXNvLWJpZGktZm9udC1mYW1pbHk6JnF1b3Q7VGltZXMgTmV3IFJvbWFuJnF1b3Q7O2NvbG9yOiMx RjQ5N0QiPk9yaXQuPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ PGEgbmFtZT0iX01haWxFbmRDb21wb3NlIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtm b250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7bXNvLWJpZGktZm9udC1m YW1pbHk6JnF1b3Q7VGltZXMgTmV3IFJvbWFuJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5i c3A7PC9vOnA+PC9zcGFuPjwvYT48L3A+DQo8c3BhbiBzdHlsZT0ibXNvLWJvb2ttYXJrOl9NYWls RW5kQ29tcG9zZSI+PC9zcGFuPg0KPGRpdiBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLWxlZnQ6 c29saWQgYmx1ZSAxLjVwdDtwYWRkaW5nOjBpbiAwaW4gMGluIDQuMHB0Ij4NCjxkaXY+DQo8ZGl2 IHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItdG9wOnNvbGlkICNFMUUxRTEgMS4wcHQ7cGFkZGlu ZzozLjBwdCAwaW4gMGluIDBpbiI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48Yj48c3BhbiBzdHls ZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMt c2VyaWY7bXNvLWZhcmVhc3QtZm9udC1mYW1pbHk6JnF1b3Q7VGltZXMgTmV3IFJvbWFuJnF1b3Q7 Ij5Gcm9tOjwvc3Bhbj48L2I+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1p bHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO21zby1mYXJlYXN0LWZvbnQtZmFtaWx5 OiZxdW90O1RpbWVzIE5ldyBSb21hbiZxdW90OyI+IFRlZA0KIEhhcmRpZSBbbWFpbHRvOnRlZC5p ZXRmQGdtYWlsLmNvbV0gPGJyPg0KPGI+U2VudDo8L2I+IFR1ZXNkYXksIEp1bHkgMTQsIDIwMTUg MTE6MTggQU08YnI+DQo8Yj5Ubzo8L2I+IE9yaXQgTGV2aW4gKExDQSkgJmx0O29yaXRsQG1pY3Jv c29mdC5jb20mZ3Q7OyBydGN3ZWJAaWV0Zi5vcmc8YnI+DQo8Yj5DYzo8L2I+IEVsaW90IExlYXIg Jmx0O2xlYXJAY2lzY28uY29tJmd0OzsgYXBwc2RpckBpZXRmLm9yZzxicj4NCjxiPlN1YmplY3Q6 PC9iPiBSZTogW2FwcHNkaXJdIEZ3ZDogUmVxdWVzdCBmb3IgQXBwcyBEaXJlY3RvcmF0ZSByZXZp ZXcgb2YgcnRjd2ViLXNlY3VyaXR5IGRyYWZ0czxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2 Pg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxk aXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1ib3R0b206MTIu MHB0Ij48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7VGFob21hJnF1b3Q7LHNhbnMtc2Vy aWYiPihhZGRpbmcgdGhlIFdHKTxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tYm90dG9tOjEyLjBwdCI+PHNwYW4g c3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O1RhaG9tYSZxdW90OyxzYW5zLXNlcmlmIj5IaSBPcml0 LDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiIHN0eWxlPSJtYXJnaW4tYm90dG9tOjEyLjBwdCI+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5 OiZxdW90O1RhaG9tYSZxdW90OyxzYW5zLXNlcmlmIj5UaGFua3MgZm9yIHRoZSByZXZpZXcuPG86 cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIg c3R5bGU9Im1hcmdpbi1ib3R0b206MTIuMHB0Ij48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1 b3Q7VGFob21hJnF1b3Q7LHNhbnMtc2VyaWYiPnJlZ2FyZHMsPG86cD48L286cD48L3NwYW4+PC9w Pg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQt ZmFtaWx5OiZxdW90O1RhaG9tYSZxdW90OyxzYW5zLXNlcmlmIj5UZWQgSGFyZGllPG86cD48L286 cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4m bmJzcDs8L286cD48L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+T24gVHVlLCBKdWwg MTQsIDIwMTUgYXQgMTE6MDcgQU0sIE9yaXQgTGV2aW4gKExDQSkgJmx0OzxhIGhyZWY9Im1haWx0 bzpvcml0bEBtaWNyb3NvZnQuY29tIiB0YXJnZXQ9Il9ibGFuayI+b3JpdGxAbWljcm9zb2Z0LmNv bTwvYT4mZ3Q7IHdyb3RlOjxvOnA+PC9vOnA+PC9wPg0KPGJsb2NrcXVvdGUgc3R5bGU9ImJvcmRl cjpub25lO2JvcmRlci1sZWZ0OnNvbGlkICNDQ0NDQ0MgMS4wcHQ7bXNvLWJvcmRlci1sZWZ0LWFs dDpzb2xpZCAjQ0NDQ0NDIC43NXB0O3BhZGRpbmc6MGluIDBpbiAwaW4gNi4wcHQ7bWFyZ2luLWxl ZnQ6NC44cHQ7bWFyZ2luLXJpZ2h0OjBpbiI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5EaXNjbGFp bWVyOiBJIGFtIGZhbWlsaWFyIHdpdGggUlRDIGFuZCBXZWJSVEMsIGJ1dCBJIGhhdmVuJ3QgZm9s bG93ZWQgdGhlIFJUQ1dlYiB3b3JrIGluIHRoZSBsYXN0IGZldyB5ZWFycy4gSSByZWFkIHRoZSB0 d28gZHJhZnRzIGZvciB0aGUgZmlyc3QgdGltZS48YnI+DQpUaGVyZWZvcmUsIG15IGFwb2xvZ2ll cyBmb3IgcG90ZW50aWFsbHkgcmFpc2luZyBwb2ludHMgdGhhdCBoYXZlIGJlZW4gZGlzY3Vzc2Vk IGluIHRoZSBwYXN0Ljxicj4NCjxicj4NCiZndDtGcm9tIHRoZSBBUFAgKG9yIEFSVCkgcmV2aWV3 IHBlcnNwZWN0aXZlLCBteSBtYWluIGNvbW1lbnQgaXMgb24gdGhlIHRvcGljIG9mICZxdW90O1dl Yi1CYXNlZCBQZWVyIEF1dGhlbnRpY2F0aW9uJnF1b3Q7LiBXaGlsZSBpdCBpcyBub3QgY2xlYXIg ZnJvbSB0aGUgdGV4dCwgd2hpY2ggcGFydHMgYXJlIGFscmVhZHkgc3RhbmRhcmRpemVkIGNvbmNl cHRzIChlLmcuLCBieSBXM0MpIGFuZCB3aGljaCBhcmUgaW50cm9kdWNlZCBoZXJlIGZvciB0aGUg Zmlyc3QgdGltZSwNCiB0aGUgZGVzY3JpYmVkIGFwcHJvYWNoIHNlZW1zIHRvIGJlICgxKSB1c2Vm dWwgdG8gd2ViIGFwcGxpY2F0aW9ucyBiZXlvbmQgV2ViUlRDLCAoMikgdW5kZXIgZGV2ZWxvcG1l bnQgYW5kIHRodXMgcHJvYmFibHkgbm90IHN0YWJsZSwgYW5kICgzKSB0b28gZGV0YWlsZWQgZm9y ICZxdW90O2FuIGFyY2hpdGVjdHVyZSZxdW90OyBkb2N1bWVudC4mbmJzcDsgQXMgc3VjaCwgdGhl IGNvbmNlcHQgb2YgJnF1b3Q7IFdlYi1CYXNlZCBQZWVyIEF1dGhlbnRpY2F0aW9uJnF1b3Q7IHBy b2JhYmx5IG5lZWRzDQogdG8gYmUgaW50cm9kdWNlZCBhbmQgc3RhbmRhcmRpemVkIHVuZGVyIHRo ZSBTZWN1cml0eSBBcmVhIGFuZCB0aGVuIGFkb3B0ZWQgYnkgV2ViUlRDIGFuZCBvdGhlciBhcHBz Ljxicj4NCjxicj4NCjxhIGhyZWY9Imh0dHBzOi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcvZG9jL2Ry YWZ0LWlldGYtcnRjd2ViLXNlY3VyaXR5LyIgdGFyZ2V0PSJfYmxhbmsiPmh0dHBzOi8vZGF0YXRy YWNrZXIuaWV0Zi5vcmcvZG9jL2RyYWZ0LWlldGYtcnRjd2ViLXNlY3VyaXR5LzwvYT48YnI+DQpU aGlzIGRvY3VtZW50IGNvbnRhaW5zIGFuIGV4Y2VsbGVudCBjb2xsZWN0aW9uIG9mIHNlY3VyaXR5 IHRocmVhdHMgdG8gV2ViUlRDIGFuZCBkaXNjdXNzZXMgbWFueSBkaWZmZXJlbnQgaWRlYXMgZm9y IHRoZWlyIHBvdGVudGlhbCBtaXRpZ2F0aW9uLiBUaGF0IGJlaW5nIHNhaWQsIGl0IGlzIG5vdCBh biBlYXN5IHJlYWQuIFNwZWNpZmljYWxseSwgZnJvbSBoaWdoIGxldmVsIHRvIG1vcmUgc3BlY2lm aWM6PGJyPg0KMS4gVGhlIGludGVuZGVkIHN0YXR1cyBvZiB0aGUgZG9jdW1lbnQgaXMgU3RhbmRh cmRzIFRyYWNrLCB3aGlsZSBhIHR5cGljYWwgc3RhdHVzIG9mIGEgJnF1b3Q7c2VjdXJpdHkgdGhy ZWF0IG1vZGVsJnF1b3Q7IFJGQyBpcyBJbmZvcm1hdGlvbmFsLiBUaGlzIGRpc2NyZXBhbmN5IHBy b2JhYmx5IGxpZXMgaW4gdGhlIGN1cnJlbnQgc2NvcGUgb2YgdGhlIGRvY3VtZW50LiBTZWUgdGhl IG5leHQgY29tbWVudCBiZWxvdy48YnI+DQoyLiBUaGUgc2NvcGUgb2YgdGhlIGRvY3VtZW50IGlz IG5vdCBjbGVhci4gSW4gYWRkaXRpb24gdG8gZGVzY3JpYmluZyB0aGUgc2VjdXJpdHkgdGhyZWF0 cyAoYW5kIHRoZSByZXF1aXJlbWVudHMgb3IgdXNlciBleHBlY3RhdGlvbnMgcmVsYXRlZCB0byB0 aGVpciBwcmV2ZW50aW9uKSwgaW4gbWFueSBwbGFjZXMgdGhlIGRvY3VtZW50IGxpc3RzIHBvdGVu dGlhbCBzb2x1dGlvbnMgd2l0aCB0aGVpciBwZXJjZWl2ZWQgbGltaXRhdGlvbnMgYW5kL29yDQog YXBwbGljYWJpbGl0eS4gRXhhbXBsZXMgYXJlIHNlY3Rpb25zOiA0LjIuMSwgNC4yLjIsIDQuMi4z LCA0LjIuNCwgNC4zLjIuMSwgNC4zLjIuMiwgNC4zLjIuMy4gVG8gaW1wcm92ZSB0aGUgZG9jdW1l bnQncyByZWFkYWJpbGl0eSBhbmQgcmVkdWNlIG92ZXJsYXBzLCZuYnNwOyB0aGUgc29sdXRpb25z IHNob3VsZCBiZSBpbnRyb2R1Y2VkIGFuZCBleHBsYWluZWQgaW4gdGhlIGNvbXBhbmlvbiAmcXVv dDthcmNoaXRlY3R1cmUmcXVvdDsgZG9jdW1lbnQuIFNvbHV0aW9ucycgYXBwbGljYWJpbGl0eQ0K IHRvIGRpZmZlcmVudCB1c2UgY2FzZXMgbmVlZHMgdG8gYmUgcHJvdmlkZWQgaW4gYSBub24tYmlh cyB3YXkuPGJyPg0KMy4gQXBhcnQgZnJvbSB0aGUgYnJpZWYgSW50cm9kdWN0aW9uIHdpdGggYSBm ZXcgZXhhbXBsZXMsIHRoZXJlIGlzIG5vIGRlc2NyaXB0aW9uIG9mIHRoZSBXZWJSVEMgdGhyZWF0 IG1vZGVsIHB1dHRpbmcgYWxsIG1haW4gdHlwZXMgb2YgdGhyZWF0IGluIG9uZSBwbGFjZS4gRm9y IGV4YW1wbGUsIHRoZSAmcXVvdDtDb21tdW5pY2F0aW9ucyBTZWN1cml0eSZxdW90OyBhc3BlY3Qg aXMgaW50cm9kdWNlZCBmb3IgdGhlIGZpcnN0IHRpbWUgaW4gU2VjdGlvbiA0LjMgb25seS4NCiBU aGUgc3RhcnQgb2YgU2VjdGlvbiAmcXVvdDs0LiBTZWN1cml0eSBmb3IgV2ViUlRDIEFwcGxpY2F0 aW9ucyZxdW90OyBjb3VsZCBiZSBhIGxvZ2ljYWwgcGxhY2UgZm9yIGludHJvZHVjaW5nIHRoZSBX ZWJSVEMgdGhyZWF0IG1vZGVsLjxicj4NCjQuIFRoZSAmcXVvdDtzaW1wbGUgV2ViUlRDIHN5c3Rl bSZxdW90OyBwcmVzZW50ZWQgaW4gdGhlIEludHJvZHVjdGlvbiBpbiBGaWd1cmUgMSBpcyBpbmFk ZXF1YXRlIHRvIGlsbHVzdHJhdGUgbWFueSBvZiB0aGUgc2NlbmFyaW9zIGFuZCBwb2ludHMgZGlz Y3Vzc2VkIGluIHRoZSBkb2N1bWVudC4gRm9yIGV4YW1wbGUsIHNlZSB0aGUgZGlzY3Vzc2lvbiBh cm91bmQgbWVkaWEgb3JpZ2luIHZzLiB3ZWIgb3JpZ2luIGluIFNlY3Rpb24gNC4xLjMuPGJyPg0K NS4gU2VjdGlvbiAmcXVvdDszLiBUaGUgQnJvd3NlciBUaHJlYXQgTW9kZWwmcXVvdDsgaXMgYW4g b3ZlcnZpZXcgb2YgdGhlIGV4aXN0aW5nIHdlYiBzZWN1cml0eSBhcmNoaXRlY3R1cmUgYW5kIHNv bWUgY3VycmVudCBwcmFjdGljZXMuIEFzIHN1Y2gsIHJlZmVyZW5jZXMgdG8gcmVsZXZhbnQgc3Rh bmRhcmRzIChlLmcuLCBXM0MpIGFuZCBjb21tb24gcHJhY3RpY2VzIG5lZWQgdG8gYmUgYWRkZWQg d2l0aGluIHRoZSB0ZXh0IHRvIGhlbHAgdGhlIHJlYWRlciB0byB1bmRlcnN0YW5kDQogdGhlIHN0 YXR1cyBvZiB0aGUgaW5mb3JtYXRpb24gYW5kIHRvIGZvbGxvdyB0aGUgc291cmNlcy48YnI+DQo2 LiBUaGUgbGFzdCBwYXJhZ3JhcGggaW4gU2VjdGlvbiA0LjEgY29udmV5cyBhIGtleSBwb2ludCBp biB0aGUgd2hvbGUgV2ViUlRDIHRocmVhdCBtb2RlbC4gQXMgc3VjaCwmbmJzcDsgaXQgbmVlZHMg dG8gYmUgbW92ZWQgdG8gdGhlIHN0YXJ0IG9mIHRoZSBkaXNjdXNzaW9uIHdoZXJlIHRoZSB0aHJl YXQgbW9kZWwgaXMgaW50cm9kdWNlZCAoc2VlIGNvbW1lbnRzIGFib3ZlKS48YnI+DQo3LiBTdHls aXN0aWNhbGx5LCB0aGUgZG9jdW1lbnQgd291bGQgYmVuZWZpdCBmcm9tIHJlbW92aW5nIG5vbi1z dGFuZGFyZHMgdm9jYWJ1bGFyeSwgaS5lLiwgJnF1b3Q7dG8gYnVnJnF1b3Q7LCAmcXVvdDt0byBi dWcgbWUmcXVvdDssICZxdW90O25vIHJlYWwgd2F5JnF1b3Q7LCAmcXVvdDtpdCBpcyBpbXBvcnRh bnQgdG8gcmVxdWlyZSZxdW90OywgJnF1b3Q7ZXh0cmVtZWx5IGFnZ3Jlc3NpdmUgaW50ZXJtZWRp YXRlcyZxdW90OywmbmJzcDsgYW5kICZxdW90O2ZvciBvYnZpb3VzIHJlYXNvbnMmcXVvdDssIGV0 Yy48YnI+DQo4LiBTdWdnZXN0aW9ucyBmb3IgcmVuYW1pbmcgc29tZSBvZiB0aGUgc2VjdGlvbnMg dG8gaW1wcm92ZSByZWFkYWJpbGl0eTo8YnI+DQomcXVvdDszLiBUaGUgQnJvd3NlciBUaHJlYXQg TW9kZWwmcXVvdDsgLSZndDsgJnF1b3Q7IDMuIE92ZXJ2aWV3IG9mIHRoZSBFeGlzdGluZyBXZWIg VGhyZWF0IE1vZGVsJnF1b3Q7PGJyPg0KJnF1b3Q7NC4xLiBBY2Nlc3MgdG8gTG9jYWwgRGV2aWNl cyZxdW90OyAtJmd0OyAmcXVvdDs0LjEuIENvbnNlbnQgdG8gQWNjZXNzIExvY2FsIFJlc291cmNl cyZxdW90Ozxicj4NCiZxdW90OzQuMS4yLiBDYWxsaW5nIFNjZW5hcmlvcyBhbmQgVXNlciBFeHBl Y3RhdGlvbnMmcXVvdDsgLSZndDsgJnF1b3Q7NC4xLjIuIFNjb3BlIG9mIENvbnNlbnQgaW4gVmFy aW91cyBDYWxsaW5nIFNjZW5hcmlvcyZxdW90Ozxicj4NCiZxdW90OzQuMS4yLjEuIERlZGljYXRl ZCBDYWxsaW5nIFNlcnZpY2VzJnF1b3Q7IC0mZ3Q7ICZxdW90OzQuMS4yLjEuIExvbmctdGVybSBD b25zZW50JnF1b3Q7PGJyPg0KJnF1b3Q7NC4xLjIuMi4gQ2FsbGluZyB0aGUgc2l0ZSBZb3UncmUg T24mcXVvdDsgLSZndDsgJnF1b3Q7NC4xLjIuMi4gU2hvcnQtdGVybSBDb25zZW50JnF1b3Q7PGJy Pg0KJnF1b3Q7NC4xLjMuIE9yaWdpbi1CYXNlZCBTZWN1cml0eSZxdW90OyAtJmd0OyAmcXVvdDs0 LjEuMy4gV2ViIEF0dGFja2VycyBhbmQgT3JpZ2luLWJhc2VkIFNlY3VyaXR5JnF1b3Q7PGJyPg0K JnF1b3Q7NC4xLjQuIFNlY3VyaXR5IFByb3BlcnRpZXMgb2YgdGhlIENhbGxpbmcgUGFnZSZxdW90 OyAtJmd0OyAmcXVvdDs0LjEuNC4gTmV0d29yayBBdHRhY2tlcnMgYW5kJm5ic3A7IFNlY3VyaXR5 IFByb3BlcnRpZXMgb2YgdGhlIENhbGxpbmcgUGFnZSZxdW90Ozxicj4NCiZxdW90OzQuMi4gQ29t bXVuaWNhdGlvbnMgQ29uc2VudCBWZXJpZmljYXRpb24mcXVvdDsgLSZndDsgJnF1b3Q7NC4yLiBD b25zZW50IHRvIFJlY2VpdmUgVHJhZmZpYyZxdW90Ozxicj4NCiZxdW90OzQuMy4zLiBNYWxpY2lv dXMgUGVlcnMmcXVvdDsgLSZndDsgJnF1b3Q7NC4zLjMuIE91dCBvZiBTY29wZSZxdW90Ozxicj4N Cjxicj4NCjxhIGhyZWY9Imh0dHBzOi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcvZG9jL2RyYWZ0LWll dGYtcnRjd2ViLXNlY3VyaXR5LWFyY2gvIiB0YXJnZXQ9Il9ibGFuayI+aHR0cHM6Ly9kYXRhdHJh Y2tlci5pZXRmLm9yZy9kb2MvZHJhZnQtaWV0Zi1ydGN3ZWItc2VjdXJpdHktYXJjaC88L2E+PGJy Pg0KVGhpcyBkb2N1bWVudCBpcyBpbiBhIG11Y2ggYmV0dGVyIHN0YXRlIGluIHRlcm1zIG9mIGl0 cyBvcmdhbml6YXRpb24gYW5kIHJlYWRhYmlsaXR5LiBJdCBpbnRyb2R1Y2VzIHRoZSBzZWN1cml0 eSBhcmNoaXRlY3R1cmUgdXNpbmcgYW4gZXhhbXBsZSBhbmQgdGhlbiBsaXN0cyBwb3NzaWJsZSBh cHByb2FjaGVzIHRvIGltcGxlbWVudCBpdC4gU29tZSBhcHByb2FjaGVzIGFyZSBkZXNjcmliZWQg b24gYSBoaWdoIGxldmVsIGJ5IHJlZmVyZW5jaW5nIG90aGVyDQogZG9jdW1lbnRzLCB3aGlsZSBv dGhlcnMgYXJlIGludHJvZHVjZWQgZm9yIHRoZSBmaXJzdCB0aW1lIGluIHRoaXMgZG9jdW1lbnQg dG9nZXRoZXIgd2l0aCB0aGVpciBpbXBsZW1lbnRhdGlvbiBkZXRhaWxzLiBCeSBqdXN0IHJlYWRp bmcgdGhlIGRvY3VtZW50LCBpdCBpcyBkaWZmaWN1bHQgdG8ganVkZ2Ugd2hldGhlciB0aGVzZSBk ZXRhaWxzIGFyZSBzdWZmaWNpZW50IG9yIHN0YWJsZSBlbm91Z2ggZm9yIGltcGxlbWVudGF0aW9u LiBJbiBnZW5lcmFsLA0KIEkgZG91YnQgdGhhdCB0aGlzIGlzIHRoZSBiZXN0IGFwcHJvYWNoIGZv ciBhbiAmcXVvdDthcmNoaXRlY3R1cmUmcXVvdDsgZG9jdW1lbnQsIHdoaWNoIGlzIHN1cHBvc2Vk IHRvIHNlcnZlIGFzIGEgbG9uZyB0ZXJtIHN0YWJsZSByZWZlcmVuY2UuPGJyPg0KTW9yZSBzcGVj aWZpYyBjb21tZW50czo8YnI+DQoxLiBEaWZmZXJlbnQgdGVybWlub2xvZ3kgaXMgdXNlZCB0aHJv dWdob3V0IHRoZSBkb2N1bWVudCB0byBhZGRyZXNzIHNhbWUgb3IgY2xvc2UgY29uY2VwdHMuIEl0 IHdvdWxkIGhlbHAgYSBsb3QgdG8gZXhwbGFpbiB0aGUgY29uY2VwdHMgdXBmcm9udCBhbmQgdGhl biB0byB1c2UgdGhlIHRlcm1pbm9sb2d5IGNvbnNpc3RlbnRseS4gQ3VycmVudGx5IGl0IGluY2x1 ZGVzICZxdW90O2NsaWVudCZxdW90OywgJnF1b3Q7ZW5kcG9pbnQmcXVvdDssJm5ic3A7ICZxdW90 O3BlZXImcXVvdDssICZxdW90O3VzZXImcXVvdDs7ICZxdW90O2ltcGxlbWVudGF0aW9uJnF1b3Q7 LA0KICZxdW90O2Jyb3dzZXImcXVvdDssICZxdW90O2Nocm9tZSZxdW90OywgJnF1b3Q7QVBJJnF1 b3Q7LCAmcXVvdDtKUyZxdW90OzsgJnF1b3Q7YXBwbGljYXRpb24mcXVvdDssICZxdW90O3NlcnZl ciZxdW90OywgZXRjLjxicj4NCjIuIFRoZSBkaXNjdXNzaW9uIGlzIHBocmFzZWQgaW4gdGVybXMg b2YgJnF1b3Q7YXV0aGVudGljYXRpb24mcXVvdDsgYW5kICZxdW90O3RydXN0JnF1b3Q7LiBJbiB0 aGluayB0aGF0ICZxdW90O2F1dGhvcml6YXRpb24mcXVvdDsgaW5zdGVhZCBvZiAmcXVvdDt0cnVz dCZxdW90OyB3b3VsZCBiZSBhIGJldHRlciB0ZWNobmljYWwgdGVybSwgZm9yIGV4YW1wbGUsIGlu IFNlY3Rpb24gMy4xLjxicj4NCjMuIEluIHNlY3Rpb24gNC4gT3ZlcnZpZXcsIHNlbnRlbmNlICZx dW90O3RoZSB0ZW5zaW9uIGJldHdlZW4gc2VjdXJpdHkgKG9yIHBlcmZvcm1hbmNlKSBhbmQgcHJp dmFjeSZxdW90OyBpcyBub3QgY2xlYXIsIGVzcGVjaWFsbHkgYmVjYXVzZSBpdCBkb2Vzbid0IHNl ZW0gdG8gY29ycmVzcG9uZCB0byBTZWN0aW9uIDYuMi4gKEJUVyAmcXVvdDt0cmFkZW9mZiZxdW90 OyB3b3VsZCBiZSBhIGJldHRlciB3b3JkIHRoYW4gJnF1b3Q7dGVuc2lvbiZxdW90Oy4pPGJyPg0K NC4gU2VjdGlvbiAmcXVvdDs0LjEuIEluaXRpYWwgU2lnbmFsaW5nJnF1b3Q7LCB0aGUgdGV4dCBp cyBpbmNvbnNpc3RlbnQgaW4gdGVybXMgb2Ygd2hldGhlciBBbGljZSBhbmQgQm9iIHNoYXJlIG9y IHVzZSBkaWZmZXJlbnQgaWRlbnRpdHkgcHJvdmlkZXJzLjxicj4NCjUuIFNlY3Rpb24gJnF1b3Q7 NC4xLiBJbml0aWFsIFNpZ25hbGluZyZxdW90OywgcmVmZXJlbmNlIHRvIFBlZXJDb25uZWN0aW9u IG5lZWRzIHRvIGJlIGFkZGVkLjxicj4NCjYuIFNlY3Rpb24gJnF1b3Q7NC4yLiBNZWRpYSBDb25z ZW50IFZlcmlmaWNhdGlvbiZxdW90OyBhbmQgU2VjdGlvbiAmcXVvdDs1LjMgQ29tbXVuaWNhdGlv bnMgQ29uc2VudCZxdW90OzogdGhlIG5hbWUvdGVybWlub2xvZ3kgb2YgdGhpcyBmdW5jdGlvbmFs aXR5IG5lZWRzIHRvIGJlIGhhcm1vbml6ZWQuIFRoZSBJQ0UtYmFzZWQgc29sdXRpb24gd2l0aCBp dHMgcHJvcywgY29ucyBhcyB3ZWxsIGFzIHRoZSBhbHRlcm5hdGl2ZXMgKGFwcGxpY2FibGUgdG8g ZGlmZmVyZW50IHVzZSBjYXNlcykNCiBuZWVkIHRvIGJlIG1vdmVkIGZyb20gdGhlIGNvbXBhbmlv biB0aHJlYXQgbW9kZWwgZG9jdW1lbnQgdG8gdGhpcyAmcXVvdDthcmNoaXRlY3R1cmUmcXVvdDsg b25lLjxicj4NCjcuIEEgc3VnZ2VzdGlvbjogcmVuYW1lICZxdW90OzUuIERldGFpbGVkIFRlY2hu aWNhbCBEZXNjcmlwdGlvbiZxdW90OyB0byAmcXVvdDs1LiBTZWN1cml0eSBBcmNoaXRlY3R1cmUg Q29tcG9uZW50cyZxdW90Oy48YnI+DQo4LiBJbiBTZWN0aW9uIDUuMi4sICZxdW90O0ltcGxlbWVu dGF0aW9ucyB3aGljaCBzdXBwb3J0IHNvbWUgZm9ybSBvZiBkaXJlY3QgdXNlciBhdXRoZW50aWNh dGlvbi4uLiZxdW90OyAtJmd0OyAmcXVvdDtJbXBsZW1lbnRhdGlvbnMgdGhhdCBzdXBwb3J0IHNv bWUgZm9ybSBvZiBkaXJlY3QgdXNlciBhdXRoZW50aWNhdGlvbi4uLiZxdW90Ozxicj4NCjkuIFNl Y3Rpb24gJnF1b3Q7NS42LiBXZWItQmFzZWQgUGVlciBBdXRoZW50aWNhdGlvbiZxdW90OyBhbmQg c2VjdGlvbiAmcXVvdDs1LjYuMi4gT3ZlcnZpZXcgb2Ygb3BlcmF0aW9uJnF1b3Q7OiBJdCBpcyBu b3QgY2xlYXIsIHdoaWNoIHBhcnRzIGFyZSBzdGFuZGFyZGl6ZWQgY29uY2VwdHMgKGUuZy4sIGJ5 IFczQykgYW5kIHdoaWNoIGFyZSBpbnRyb2R1Y2VkIGhlcmUgZm9yIHRoZSBmaXJzdCB0aW1lLiBJ ZiBleGlzdCwgcmVmZXJlbmNlcyB0byBleGlzdGluZyBzdGFuZGFyZHMgbmVlZA0KIHRvIGJlIGFk ZGVkLiBUaGUgZGVzY3JpYmVkIGFyY2hpdGVjdHVyZSBhbmQgdGhlIHRlY2huaWNhbCBkZXRhaWxz IHNlZW0gdG8gYmUgKDEpIHVuZGVyIGRldmVsb3BtZW50IGFuZCB0aHVzIHByb2JhYmx5IG5vdCBz dGFibGUsICgyKSB0b28gZGV0YWlsZWQgZm9yICZxdW90O2FuIGFyY2hpdGVjdHVyZSZxdW90OyBk b2N1bWVudCBhbmQgKDMpIHVzZWZ1bCBiZXlvbmQgV2ViUlRDLiZuYnNwOyBBcyBzdWNoLCB0aGUg Y29uY2VwdCBvZiB0aGUgJnF1b3Q7IFdlYi1CYXNlZCBQZWVyIEF1dGhlbnRpY2F0aW9uJnF1b3Q7 DQogcHJvYmFibHkgbmVlZHMgYmUgaW50cm9kdWNlZCB1bmRlciB0aGUgU2VjdXJpdHkgQXJlYSBh bmQgdGhlbiBhZG9wdGVkIGJ5IFdlYlJUQy48YnI+DQoxMC4gVGhlIHdlYi1iYXNlZCBwZWVyIGF1 dGhlbnRpY2F0aW9uIHVzaW5nIElkUCBpcyBub3QgdGhlIG9ubHkgbWVjaGFuaXNtIGFwcGxpY2Fi bGUgdG8gV2ViUlRDLiBNb3Jlb3ZlciwgdGhlIHdlYi1iYXNlZCBwZWVyIGF1dGhlbnRpY2F0aW9u Jm5ic3A7IGlzIG5vdCB0aGUgb25seSBhcHByb2FjaCBhcHBsaWNhYmxlIHRvIFdlYlJUQy4gQWx0 ZXJuYXRpdmVzIGFyZSBsaXN0ZWQgaW4gdGhlIGNvbXBhbmlvbiBkb2N1bWVudCBhbmQgbmVlZCB0 byBiZSBtb3ZlZA0KIGhlcmUgdG8gdGhlICZxdW90O2FyY2hpdGVjdHVyZSZxdW90OyBkb2N1bWVu dCB3aXRoIHRoZWlyIHByb3MgYW5kIGNvbnMgcHJlc2VudGVkIGluIGFuIHVuYmlhc2VkIHdheS48 YnI+DQoxMS4gU3R5bGlzdGljYWxseSwgdGhlIGRvY3VtZW50IHdvdWxkIGJlbmVmaXQgZnJvbSBy ZW1vdmluZyBub24tc3RhbmRhcmRzIHZvY2FidWxhcnksIGkuZS4sICZxdW90O3NvbWUgV2ViIHNl cnZlciZxdW90OywgJnF1b3Q7Y2FuJ3QgcmVhbGx5IHRydXN0JnF1b3Q7LCAmcXVvdDt0aGF0IG11 Y2gmcXVvdDssICZxdW90O2ZhaXJseSBjb252ZW50aW9uYWwmcXVvdDssICZxdW90O3NpbXBseSBo YXZlJnF1b3Q7LCAmcXVvdDthIGxpdHRsZSBhbnRpY2xpbWFjdGljJnF1b3Q7LCBldGMuIDstKTxi cj4NCjxicj4NClRoYW5rcyw8YnI+DQpPcml0LjxvOnA+PC9vOnA+PC9wPg0KPGRpdj4NCjxkaXY+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48YnI+DQomZ3Q7IC0tLS0tT3JpZ2luYWwgTWVzc2FnZS0t LS0tPGJyPg0KJmd0OyBGcm9tOiBhcHBzZGlyIFttYWlsdG86PGEgaHJlZj0ibWFpbHRvOmFwcHNk aXItYm91bmNlc0BpZXRmLm9yZyI+YXBwc2Rpci1ib3VuY2VzQGlldGYub3JnPC9hPl0gT24gQmVo YWxmIE9mIE9yaXQgTGV2aW48YnI+DQomZ3Q7IChMQ0EpPGJyPg0KJmd0OyBTZW50OiBUaHVyc2Rh eSwgSnVuZSAyNSwgMjAxNSAxOjE3IFBNPGJyPg0KJmd0OyBUbzogRWxpb3QgTGVhcjsgPGEgaHJl Zj0ibWFpbHRvOmFwcHNkaXJAaWV0Zi5vcmciPmFwcHNkaXJAaWV0Zi5vcmc8L2E+PGJyPg0KJmd0 OyBTdWJqZWN0OiBSZTogW2FwcHNkaXJdIEZ3ZDogUmVxdWVzdCBmb3IgQXBwcyBEaXJlY3RvcmF0 ZSByZXZpZXcgb2YgcnRjd2ViLTxicj4NCiZndDsgc2VjdXJpdHkgZHJhZnRzPGJyPg0KJmd0Ozxi cj4NCiZndDsgUGVyZmVjdCEgSSBoYXZlIGEgdmVyeSBsb25nIGZsaWdodCBvbiB0aGUgN3RoLi4u IFNvIHJpZ2h0IGFmdGVyIHRoZW4gb3IgZWFybGllci48YnI+DQomZ3Q7IE9yaXQuPGJyPg0KJmd0 Ozxicj4NCiZndDsgJmd0OyAtLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLTxicj4NCiZndDsgJmd0 OyBGcm9tOiBFbGlvdCBMZWFyIFttYWlsdG86PGEgaHJlZj0ibWFpbHRvOmxlYXJAY2lzY28uY29t Ij5sZWFyQGNpc2NvLmNvbTwvYT5dPGJyPg0KJmd0OyAmZ3Q7IFNlbnQ6IFRodXJzZGF5LCBKdW5l IDI1LCAyMDE1IDEyOjU1IFBNPGJyPg0KJmd0OyAmZ3Q7IFRvOiBPcml0IExldmluIChMQ0EpOyA8 YSBocmVmPSJtYWlsdG86YXBwc2RpckBpZXRmLm9yZyI+YXBwc2RpckBpZXRmLm9yZzwvYT48YnI+ DQomZ3Q7ICZndDsgU3ViamVjdDogUmU6IFthcHBzZGlyXSBGd2Q6IFJlcXVlc3QgZm9yIEFwcHMg RGlyZWN0b3JhdGUgcmV2aWV3IG9mIHJ0Y3dlYi08YnI+DQomZ3Q7ICZndDsgc2VjdXJpdHkgZHJh ZnRzPGJyPg0KJmd0OyAmZ3Q7PGJyPg0KJmd0OyAmZ3Q7IFRoYW5rIHlvdSBPcml0ISZuYnNwOyBD YW4geW91IHRyeSB0byBoYXZlIHRoZW0gZG9uZSBpbiBhYm91dCB0d28gd2Vla3M/PGJyPg0KJmd0 OyAmZ3Q7PGJyPg0KJmd0OyAmZ3Q7IEVsaW90PGJyPg0KJmd0OyAmZ3Q7PGJyPg0KJmd0OyAmZ3Q7 IE9uIDYvMjUvMTUgOTo1MiBQTSwgT3JpdCBMZXZpbiAoTENBKSB3cm90ZTo8YnI+DQomZ3Q7ICZn dDsgJmd0OyBJIHdpbGwgYmUgaGFwcHkgdG8gdGFrZSBhIGxvb2sgYXQgdGhlbSE8YnI+DQomZ3Q7 ICZndDsgJmd0OyBPcml0Ljxicj4NCiZndDsgJmd0OyAmZ3Q7PGJyPg0KJmd0OyAmZ3Q7ICZndDsm Z3Q7IC0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tPGJyPg0KJmd0OyAmZ3Q7ICZndDsmZ3Q7IEZy b206IGFwcHNkaXIgW21haWx0bzo8YSBocmVmPSJtYWlsdG86YXBwc2Rpci1ib3VuY2VzQGlldGYu b3JnIj5hcHBzZGlyLWJvdW5jZXNAaWV0Zi5vcmc8L2E+XSBPbiBCZWhhbGYgT2YgRWxpb3Q8YnI+ DQomZ3Q7IExlYXI8YnI+DQomZ3Q7ICZndDsgJmd0OyZndDsgU2VudDogVGh1cnNkYXksIEp1bmUg MjUsIDIwMTUgMTE6NDQgQU08YnI+DQomZ3Q7ICZndDsgJmd0OyZndDsgVG86IDxhIGhyZWY9Im1h aWx0bzphcHBzZGlyQGlldGYub3JnIj5hcHBzZGlyQGlldGYub3JnPC9hPjxicj4NCiZndDsgJmd0 OyAmZ3Q7Jmd0OyBTdWJqZWN0OiBbYXBwc2Rpcl0gRndkOiBSZXF1ZXN0IGZvciBBcHBzIERpcmVj dG9yYXRlIHJldmlldyBvZiBydGN3ZWItPGJyPg0KJmd0OyAmZ3Q7ICZndDsmZ3Q7IHNlY3VyaXR5 IGRyYWZ0czxicj4NCiZndDsgJmd0OyAmZ3Q7Jmd0Ozxicj4NCiZndDsgJmd0OyAmZ3Q7Jmd0OyBE ZWFyIEFwcHNkaXIgZm9sayw8YnI+DQomZ3Q7ICZndDsgJmd0OyZndDs8YnI+DQomZ3Q7ICZndDsg Jmd0OyZndDsgQ291bGQgSSBoYXZlIGEgdm9sdW50ZWVyIHRvIHJldmlldyB0aGUgZm9sbG93aW5n IHR3byBkcmFmdHM/PGJyPg0KJmd0OyAmZ3Q7ICZndDsmZ3Q7PGJyPg0KJmd0OyAmZ3Q7ICZndDsm Z3Q7IDxhIGhyZWY9Imh0dHBzOi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcvZG9jL2RyYWZ0LWlldGYt cnRjd2ViLXNlY3VyaXR5LyIgdGFyZ2V0PSJfYmxhbmsiPg0KaHR0cHM6Ly9kYXRhdHJhY2tlci5p ZXRmLm9yZy9kb2MvZHJhZnQtaWV0Zi1ydGN3ZWItc2VjdXJpdHkvPC9hPjxicj4NCiZndDsgJmd0 OyAmZ3Q7Jmd0Ozxicj4NCiZndDsgJmd0OyAmZ3Q7Jmd0OyBhbmQ8YnI+DQomZ3Q7ICZndDsgJmd0 OyZndDs8YnI+DQomZ3Q7ICZndDsgJmd0OyZndDsgPGEgaHJlZj0iaHR0cHM6Ly9kYXRhdHJhY2tl ci5pZXRmLm9yZy9kb2MvZHJhZnQtaWV0Zi1ydGN3ZWItc2VjdXJpdHktYXJjaC8iIHRhcmdldD0i X2JsYW5rIj4NCmh0dHBzOi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcvZG9jL2RyYWZ0LWlldGYtcnRj d2ViLXNlY3VyaXR5LWFyY2gvPC9hPjxicj4NCiZndDsgJmd0OyAmZ3Q7Jmd0Ozxicj4NCiZndDsg Jmd0OyAmZ3Q7Jmd0OyBUZWQgaXMgZXhlbXB0LCBoYXZpbmcgbWFkZSB0aGUgcmVxdWVzdCA7LSk8 YnI+DQomZ3Q7ICZndDsgJmd0OyZndDs8YnI+DQomZ3Q7ICZndDsgJmd0OyZndDsgRWxpb3Q8YnI+ DQomZ3Q7ICZndDs8YnI+DQomZ3Q7PGJyPg0KJmd0OyBfX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fXzxicj4NCiZndDsgYXBwc2RpciBtYWlsaW5nIGxpc3Q8YnI+ DQomZ3Q7IDxhIGhyZWY9Im1haWx0bzphcHBzZGlyQGlldGYub3JnIj5hcHBzZGlyQGlldGYub3Jn PC9hPjxicj4NCiZndDsgPGEgaHJlZj0iaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0 aW5mby9hcHBzZGlyIiB0YXJnZXQ9Il9ibGFuayI+aHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1h bi9saXN0aW5mby9hcHBzZGlyPC9hPjxicj4NCjxicj4NCl9fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fPGJyPg0KYXBwc2RpciBtYWlsaW5nIGxpc3Q8YnI+DQo8 YSBocmVmPSJtYWlsdG86YXBwc2RpckBpZXRmLm9yZyI+YXBwc2RpckBpZXRmLm9yZzwvYT48YnI+ DQo8YSBocmVmPSJodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL2FwcHNkaXIi IHRhcmdldD0iX2JsYW5rIj5odHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL2Fw cHNkaXI8L2E+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9ibG9ja3F1b3RlPg0K PC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2 Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9ib2R5Pg0KPC9odG1sPg0K --_000_BL2PR03MB2900414B69109280FD682B5AD770BL2PR03MB290namprd_-- From nobody Tue Aug 4 09:42:42 2015 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C3B291A87E4 for ; Tue, 4 Aug 2015 09:42:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.977 X-Spam-Level: X-Spam-Status: No, score=-1.977 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dUEdCRGXyvVC for ; Tue, 4 Aug 2015 09:42:36 -0700 (PDT) Received: from mail-wi0-f179.google.com (mail-wi0-f179.google.com [209.85.212.179]) (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 221281A87C6 for ; Tue, 4 Aug 2015 09:42:36 -0700 (PDT) Received: by wibxm9 with SMTP id xm9so31815932wib.1 for ; Tue, 04 Aug 2015 09:42:34 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type; bh=LsgSaRxTB7DEkpAGR0kWhn+H7w0VXGNObs5K2Hu4RkU=; b=ZsYBF2ljwTyBY7NmHNcLG2/a+/ppe/IEabA8/fS9On+TClwpAoFaZYF1fPHF1k7o9Z texoiUzu7ayCSF9O1hH0zgLCWDkx4Eac0T+DTVhx/A/ftCsFEqgL5JkCk0v2gTkw3k8u fDLPPIo38sHCVIyqZ8XUtMHdjHWa9oDx/PCO/AHXRvKP3u5B117E7rg5OCuz5wy/5C4J IPWk0/nNV4l3V2khaYUWLyhNlXmqPNlyrEsom5oQXnzGBf0FhHW6FG3Y4ENuomemYF6O YRd0SKV+rCJjJAozle1rBQY2eHwviINJqySwNFg6OH3y+AhrT8bexgRonpTYRmURopDz Oxyw== X-Gm-Message-State: ALoCoQlJWNeelRocFPdjbFj/sgF8IJeqSPSnOnUYKtsGn3cYpNcwh6yBS7HyfUZjzm0iJW8ec0Or X-Received: by 10.180.91.79 with SMTP id cc15mr10019129wib.53.1438706554827; Tue, 04 Aug 2015 09:42:34 -0700 (PDT) MIME-Version: 1.0 Received: by 10.27.85.86 with HTTP; Tue, 4 Aug 2015 09:41:55 -0700 (PDT) In-Reply-To: References: <558C4C02.3000404@cisco.com> <558C5CA3.7020108@cisco.com> From: Eric Rescorla Date: Tue, 4 Aug 2015 09:41:55 -0700 Message-ID: To: "Orit Levin (LCA)" Content-Type: multipart/alternative; boundary=f46d043be246230c45051c7ef99a Archived-At: Cc: "appsdir@ietf.org" , "rtcweb@ietf.org" , Eliot Lear Subject: Re: [rtcweb] [appsdir] Fwd: Request for Apps Directorate review of rtcweb-security drafts X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 04 Aug 2015 16:42:40 -0000 --f46d043be246230c45051c7ef99a Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable I'll be handling this along with the rest of the review comments I have received, at the next draft update (probably before the next RTCWEB/WebRTC interim) but I don't have a specific ETA. -Ekr On Mon, Aug 3, 2015 at 4:43 PM, Orit Levin (LCA) wrote: > Hi guys, > > Three busy weeks and an IETF meeting have past=E2=80=A6 When should we ex= pect to > see the feedback to the review? > > Thanks and cheers, > > Orit. > > > > *From:* Ted Hardie [mailto:ted.ietf@gmail.com] > *Sent:* Tuesday, July 14, 2015 11:18 AM > *To:* Orit Levin (LCA) ; rtcweb@ietf.org > *Cc:* Eliot Lear ; appsdir@ietf.org > > *Subject:* Re: [appsdir] Fwd: Request for Apps Directorate review of > rtcweb-security drafts > > > > (adding the WG) > > Hi Orit, > > Thanks for the review. > > regards, > > Ted Hardie > > > > On Tue, Jul 14, 2015 at 11:07 AM, Orit Levin (LCA) > wrote: > > Disclaimer: I am familiar with RTC and WebRTC, but I haven't followed the > RTCWeb work in the last few years. I read the two drafts for the first ti= me. > Therefore, my apologies for potentially raising points that have been > discussed in the past. > > >From the APP (or ART) review perspective, my main comment is on the topi= c > of "Web-Based Peer Authentication". While it is not clear from the text, > which parts are already standardized concepts (e.g., by W3C) and which ar= e > introduced here for the first time, the described approach seems to be (1= ) > useful to web applications beyond WebRTC, (2) under development and thus > probably not stable, and (3) too detailed for "an architecture" document. > As such, the concept of " Web-Based Peer Authentication" probably needs t= o > be introduced and standardized under the Security Area and then adopted b= y > WebRTC and other apps. > > https://datatracker.ietf.org/doc/draft-ietf-rtcweb-security/ > This document contains an excellent collection of security threats to > WebRTC and discusses many different ideas for their potential mitigation. > That being said, it is not an easy read. Specifically, from high level to > more specific: > 1. The intended status of the document is Standards Track, while a typica= l > status of a "security threat model" RFC is Informational. This discrepanc= y > probably lies in the current scope of the document. See the next comment > below. > 2. The scope of the document is not clear. In addition to describing the > security threats (and the requirements or user expectations related to > their prevention), in many places the document lists potential solutions > with their perceived limitations and/or applicability. Examples are > sections: 4.2.1, 4.2.2, 4.2.3, 4.2.4, 4.3.2.1, 4.3.2.2, 4.3.2.3. To impro= ve > the document's readability and reduce overlaps, the solutions should be > introduced and explained in the companion "architecture" document. > Solutions' applicability to different use cases needs to be provided in a > non-bias way. > 3. Apart from the brief Introduction with a few examples, there is no > description of the WebRTC threat model putting all main types of threat i= n > one place. For example, the "Communications Security" aspect is introduce= d > for the first time in Section 4.3 only. The start of Section "4. Security > for WebRTC Applications" could be a logical place for introducing the > WebRTC threat model. > 4. The "simple WebRTC system" presented in the Introduction in Figure 1 i= s > inadequate to illustrate many of the scenarios and points discussed in th= e > document. For example, see the discussion around media origin vs. web > origin in Section 4.1.3. > 5. Section "3. The Browser Threat Model" is an overview of the existing > web security architecture and some current practices. As such, references > to relevant standards (e.g., W3C) and common practices need to be added > within the text to help the reader to understand the status of the > information and to follow the sources. > 6. The last paragraph in Section 4.1 conveys a key point in the whole > WebRTC threat model. As such, it needs to be moved to the start of the > discussion where the threat model is introduced (see comments above). > 7. Stylistically, the document would benefit from removing non-standards > vocabulary, i.e., "to bug", "to bug me", "no real way", "it is important = to > require", "extremely aggressive intermediates", and "for obvious reasons= ", > etc. > 8. Suggestions for renaming some of the sections to improve readability: > "3. The Browser Threat Model" -> " 3. Overview of the Existing Web Threat > Model" > "4.1. Access to Local Devices" -> "4.1. Consent to Access Local Resources= " > "4.1.2. Calling Scenarios and User Expectations" -> "4.1.2. Scope of > Consent in Various Calling Scenarios" > "4.1.2.1. Dedicated Calling Services" -> "4.1.2.1. Long-term Consent" > "4.1.2.2. Calling the site You're On" -> "4.1.2.2. Short-term Consent" > "4.1.3. Origin-Based Security" -> "4.1.3. Web Attackers and Origin-based > Security" > "4.1.4. Security Properties of the Calling Page" -> "4.1.4. Network > Attackers and Security Properties of the Calling Page" > "4.2. Communications Consent Verification" -> "4.2. Consent to Receive > Traffic" > "4.3.3. Malicious Peers" -> "4.3.3. Out of Scope" > > https://datatracker.ietf.org/doc/draft-ietf-rtcweb-security-arch/ > This document is in a much better state in terms of its organization and > readability. It introduces the security architecture using an example and > then lists possible approaches to implement it. Some approaches are > described on a high level by referencing other documents, while others ar= e > introduced for the first time in this document together with their > implementation details. By just reading the document, it is difficult to > judge whether these details are sufficient or stable enough for > implementation. In general, I doubt that this is the best approach for an > "architecture" document, which is supposed to serve as a long term stable > reference. > More specific comments: > 1. Different terminology is used throughout the document to address same > or close concepts. It would help a lot to explain the concepts upfront an= d > then to use the terminology consistently. Currently it includes "client", > "endpoint", "peer", "user"; "implementation", "browser", "chrome", "API"= , > "JS"; "application", "server", etc. > 2. The discussion is phrased in terms of "authentication" and "trust". In > think that "authorization" instead of "trust" would be a better technical > term, for example, in Section 3.1. > 3. In section 4. Overview, sentence "the tension between security (or > performance) and privacy" is not clear, especially because it doesn't see= m > to correspond to Section 6.2. (BTW "tradeoff" would be a better word than > "tension".) > 4. Section "4.1. Initial Signaling", the text is inconsistent in terms of > whether Alice and Bob share or use different identity providers. > 5. Section "4.1. Initial Signaling", reference to PeerConnection needs to > be added. > 6. Section "4.2. Media Consent Verification" and Section "5.3 > Communications Consent": the name/terminology of this functionality needs > to be harmonized. The ICE-based solution with its pros, cons as well as t= he > alternatives (applicable to different use cases) need to be moved from th= e > companion threat model document to this "architecture" one. > 7. A suggestion: rename "5. Detailed Technical Description" to "5. > Security Architecture Components". > 8. In Section 5.2., "Implementations which support some form of direct > user authentication..." -> "Implementations that support some form of > direct user authentication..." > 9. Section "5.6. Web-Based Peer Authentication" and section "5.6.2. > Overview of operation": It is not clear, which parts are standardized > concepts (e.g., by W3C) and which are introduced here for the first time. > If exist, references to existing standards need to be added. The describe= d > architecture and the technical details seem to be (1) under development a= nd > thus probably not stable, (2) too detailed for "an architecture" document > and (3) useful beyond WebRTC. As such, the concept of the " Web-Based Pe= er > Authentication" probably needs be introduced under the Security Area and > then adopted by WebRTC. > 10. The web-based peer authentication using IdP is not the only mechanism > applicable to WebRTC. Moreover, the web-based peer authentication is not > the only approach applicable to WebRTC. Alternatives are listed in the > companion document and need to be moved here to the "architecture" docume= nt > with their pros and cons presented in an unbiased way. > 11. Stylistically, the document would benefit from removing non-standards > vocabulary, i.e., "some Web server", "can't really trust", "that much", > "fairly conventional", "simply have", "a little anticlimactic", etc. ;-) > > Thanks, > Orit. > > > > -----Original Message----- > > From: appsdir [mailto:appsdir-bounces@ietf.org] On Behalf Of Orit Levin > > (LCA) > > Sent: Thursday, June 25, 2015 1:17 PM > > To: Eliot Lear; appsdir@ietf.org > > Subject: Re: [appsdir] Fwd: Request for Apps Directorate review of > rtcweb- > > security drafts > > > > Perfect! I have a very long flight on the 7th... So right after then or > earlier. > > Orit. > > > > > -----Original Message----- > > > From: Eliot Lear [mailto:lear@cisco.com] > > > Sent: Thursday, June 25, 2015 12:55 PM > > > To: Orit Levin (LCA); appsdir@ietf.org > > > Subject: Re: [appsdir] Fwd: Request for Apps Directorate review of > rtcweb- > > > security drafts > > > > > > Thank you Orit! Can you try to have them done in about two weeks? > > > > > > Eliot > > > > > > On 6/25/15 9:52 PM, Orit Levin (LCA) wrote: > > > > I will be happy to take a look at them! > > > > Orit. > > > > > > > >> -----Original Message----- > > > >> From: appsdir [mailto:appsdir-bounces@ietf.org] On Behalf Of Eliot > > Lear > > > >> Sent: Thursday, June 25, 2015 11:44 AM > > > >> To: appsdir@ietf.org > > > >> Subject: [appsdir] Fwd: Request for Apps Directorate review of > rtcweb- > > > >> security drafts > > > >> > > > >> Dear Appsdir folk, > > > >> > > > >> Could I have a volunteer to review the following two drafts? > > > >> > > > >> https://datatracker.ietf.org/doc/draft-ietf-rtcweb-security/ > > > >> > > > >> and > > > >> > > > >> https://datatracker.ietf.org/doc/draft-ietf-rtcweb-security-arch/ > > > >> > > > >> Ted is exempt, having made the request ;-) > > > >> > > > >> Eliot > > > > > > > _______________________________________________ > > appsdir mailing list > > appsdir@ietf.org > > https://www.ietf.org/mailman/listinfo/appsdir > > _______________________________________________ > appsdir mailing list > appsdir@ietf.org > https://www.ietf.org/mailman/listinfo/appsdir > > > > _______________________________________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/listinfo/rtcweb > > --f46d043be246230c45051c7ef99a Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
I'll be handling this along with the rest of the revie= w comments I have received,
at the next draft update (probably before t= he next RTCWEB/WebRTC interim)
but I don't have a specific ETA.=

-Ekr



On Mon, Aug 3, = 2015 at 4:43 PM, Orit Levin (LCA) <oritl@microsoft.com> wr= ote:

Hi guys,

Three busy weeks and an IETF meeting = have past=E2=80=A6 When should we expect to see the feedback to the review?=

Thanks and cheers,

Orit.

=C2=A0

From: Ted Hardie [mailto:ted= .ietf@gmail.com]
Sent: Tuesday, July 14, 2015 11:18 AM
To: Orit Levin (LCA) <oritl@microsoft.com>; rtcweb@ietf.org
Cc: Eliot Lear <lear@cisco.com>; appsdir@ietf.org


Subject: Re: [appsdir] Fwd: Request for Apps Directorate review of r= tcweb-security drafts

=C2=A0

(adding the WG)

Hi Orit,

Thanks for the review.

regards,

Ted Hardie

=C2=A0

On Tue, Jul 14, 2015 at 11:07 AM, Orit Levin (LCA) &= lt;oritl@microsoft= .com> wrote:

Disclaimer: I am familiar with RTC and WebRTC, but I= haven't followed the RTCWeb work in the last few years. I read the two= drafts for the first time.
Therefore, my apologies for potentially raising points that have been discu= ssed in the past.

>From the APP (or ART) review perspective, my main comment is on the top= ic of "Web-Based Peer Authentication". While it is not clear from= the text, which parts are already standardized concepts (e.g., by W3C) and= which are introduced here for the first time, the described approach seems to be (1) useful to web applications beyond W= ebRTC, (2) under development and thus probably not stable, and (3) too deta= iled for "an architecture" document.=C2=A0 As such, the concept o= f " Web-Based Peer Authentication" probably needs to be introduced and standardized under the Security Area and then adopted= by WebRTC and other apps.

https://datatracker.ietf.org/doc/draft-ietf-rtcweb-security= /
This document contains an excellent collection of security threats to WebRT= C and discusses many different ideas for their potential mitigation. That b= eing said, it is not an easy read. Specifically, from high level to more sp= ecific:
1. The intended status of the document is Standards Track, while a typical = status of a "security threat model" RFC is Informational. This di= screpancy probably lies in the current scope of the document. See the next = comment below.
2. The scope of the document is not clear. In addition to describing the se= curity threats (and the requirements or user expectations related to their = prevention), in many places the document lists potential solutions with the= ir perceived limitations and/or applicability. Examples are sections: 4.2.1, 4.2.2, 4.2.3, 4.2.4, 4.3.2.1,= 4.3.2.2, 4.3.2.3. To improve the document's readability and reduce ove= rlaps,=C2=A0 the solutions should be introduced and explained in the compan= ion "architecture" document. Solutions' applicability to different use cases needs to be provided in a non-bias way.
3. Apart from the brief Introduction with a few examples, there is no descr= iption of the WebRTC threat model putting all main types of threat in one p= lace. For example, the "Communications Security" aspect is introd= uced for the first time in Section 4.3 only. The start of Section "4. Security for WebRTC Applications" could= be a logical place for introducing the WebRTC threat model.
4. The "simple WebRTC system" presented in the Introduction in Fi= gure 1 is inadequate to illustrate many of the scenarios and points discuss= ed in the document. For example, see the discussion around media origin vs.= web origin in Section 4.1.3.
5. Section "3. The Browser Threat Model" is an overview of the ex= isting web security architecture and some current practices. As such, refer= ences to relevant standards (e.g., W3C) and common practices need to be add= ed within the text to help the reader to understand the status of the information and to follow the sources.
6. The last paragraph in Section 4.1 conveys a key point in the whole WebRT= C threat model. As such,=C2=A0 it needs to be moved to the start of the dis= cussion where the threat model is introduced (see comments above).
7. Stylistically, the document would benefit from removing non-standards vo= cabulary, i.e., "to bug", "to bug me", "no real wa= y", "it is important to require", "extremely aggressive= intermediates",=C2=A0 and "for obvious reasons", etc.
8. Suggestions for renaming some of the sections to improve readability: "3. The Browser Threat Model" -> " 3. Overview of the Exi= sting Web Threat Model"
"4.1. Access to Local Devices" -> "4.1. Consent to Access= Local Resources"
"4.1.2. Calling Scenarios and User Expectations" -> "4.1.= 2. Scope of Consent in Various Calling Scenarios"
"4.1.2.1. Dedicated Calling Services" -> "4.1.2.1. Long-t= erm Consent"
"4.1.2.2. Calling the site You're On" -> "4.1.2.2. Sh= ort-term Consent"
"4.1.3. Origin-Based Security" -> "4.1.3. Web Attackers a= nd Origin-based Security"
"4.1.4. Security Properties of the Calling Page" -> "4.1.= 4. Network Attackers and=C2=A0 Security Properties of the Calling Page"= ;
"4.2. Communications Consent Verification" -> "4.2. Conse= nt to Receive Traffic"
"4.3.3. Malicious Peers" -> "4.3.3. Out of Scope"
https://datatracker.ietf.org/doc/draft-ietf-rtcweb-sec= urity-arch/
This document is in a much better state in terms of its organization and re= adability. It introduces the security architecture using an example and the= n lists possible approaches to implement it. Some approaches are described = on a high level by referencing other documents, while others are introduced for the first time in this document= together with their implementation details. By just reading the document, = it is difficult to judge whether these details are sufficient or stable eno= ugh for implementation. In general, I doubt that this is the best approach for an "architecture" doc= ument, which is supposed to serve as a long term stable reference.
More specific comments:
1. Different terminology is used throughout the document to address same or= close concepts. It would help a lot to explain the concepts upfront and th= en to use the terminology consistently. Currently it includes "client&= quot;, "endpoint",=C2=A0 "peer", "user"; &quo= t;implementation", "browser", "chrome", "API", "JS"; = "application", "server", etc.
2. The discussion is phrased in terms of "authentication" and &qu= ot;trust". In think that "authorization" instead of "tr= ust" would be a better technical term, for example, in Section 3.1. 3. In section 4. Overview, sentence "the tension between security (or = performance) and privacy" is not clear, especially because it doesn= 9;t seem to correspond to Section 6.2. (BTW "tradeoff" would be a= better word than "tension".)
4. Section "4.1. Initial Signaling", the text is inconsistent in = terms of whether Alice and Bob share or use different identity providers. 5. Section "4.1. Initial Signaling", reference to PeerConnection = needs to be added.
6. Section "4.2. Media Consent Verification" and Section "5.= 3 Communications Consent": the name/terminology of this functionality = needs to be harmonized. The ICE-based solution with its pros, cons as well = as the alternatives (applicable to different use cases) need to be moved from the companion threat model document to this "ar= chitecture" one.
7. A suggestion: rename "5. Detailed Technical Description" to &q= uot;5. Security Architecture Components".
8. In Section 5.2., "Implementations which support some form of direct= user authentication..." -> "Implementations that support some= form of direct user authentication..."
9. Section "5.6. Web-Based Peer Authentication" and section "= ;5.6.2. Overview of operation": It is not clear, which parts are stand= ardized concepts (e.g., by W3C) and which are introduced here for the first= time. If exist, references to existing standards need to be added. The described architecture and the technical details seem to = be (1) under development and thus probably not stable, (2) too detailed for= "an architecture" document and (3) useful beyond WebRTC.=C2=A0 A= s such, the concept of the " Web-Based Peer Authentication" probably needs be introduced under the Security Area and then adopted by W= ebRTC.
10. The web-based peer authentication using IdP is not the only mechanism a= pplicable to WebRTC. Moreover, the web-based peer authentication=C2=A0 is n= ot the only approach applicable to WebRTC. Alternatives are listed in the c= ompanion document and need to be moved here to the "architecture" document with their pros and cons pre= sented in an unbiased way.
11. Stylistically, the document would benefit from removing non-standards v= ocabulary, i.e., "some Web server", "can't really trust&= quot;, "that much", "fairly conventional", "simply= have", "a little anticlimactic", etc. ;-)

Thanks,
Orit.


> -----Original Message-----
> From: appsdir [mailto:appsdir-bounces@ietf.org] On Behalf Of Orit Levin
> (LCA)
> Sent: Thursday, June 25, 2015 1:17 PM
> To: Eliot Lear; = appsdir@ietf.org
> Subject: Re: [appsdir] Fwd: Request for Apps Directorate review of rtc= web-
> security drafts
>
> Perfect! I have a very long flight on the 7th... So right after then o= r earlier.
> Orit.
>
> > -----Original Message-----
> > From: Eliot Lear [mailto:lear@cisco.com]
> > Sent: Thursday, June 25, 2015 12:55 PM
> > To: Orit Levin (LCA); appsdir@ietf.org
> > Subject: Re: [appsdir] Fwd: Request for Apps Directorate review o= f rtcweb-
> > security drafts
> >
> > Thank you Orit!=C2=A0 Can you try to have them done in about two = weeks?
> >
> > Eliot
> >
> > On 6/25/15 9:52 PM, Orit Levin (LCA) wrote:
> > > I will be happy to take a look at them!
> > > Orit.
> > >
> > >> -----Original Message-----
> > >> From: appsdir [mailto:appsdir-bounces@ietf.org] On Behalf Of Elio= t
> Lear
> > >> Sent: Thursday, June 25, 2015 11:44 AM
> > >> To: appsdir@ietf.org
> > >> Subject: [appsdir] Fwd: Request for Apps Directorate rev= iew of rtcweb-
> > >> security drafts
> > >>
> > >> Dear Appsdir folk,
> > >>
> > >> Could I have a volunteer to review the following two dra= fts?
> > >>
> > >> https://datatracker.ietf.org/doc/draft-ietf-rtcweb-security/
> > >>
> > >> and
> > >>
> > >> https://datatracker.ietf.org/doc/draft-ietf-rtcweb-security-arch/
> > >>
> > >> Ted is exempt, having made the request ;-)
> > >>
> > >> Eliot
> >
>
> _______________________________________________
> appsdir mailing list
> appsdir@ietf.org=
> https://www.ietf.org/mailman/listinfo/appsdir

_______________________________________________
appsdir mailing list
appsdir@ietf.org<= br> https://www.ietf.org/mailman/listinfo/appsdir

=C2=A0


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


--f46d043be246230c45051c7ef99a-- From nobody Tue Aug 4 15:08:27 2015 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 97BFA1ACF1C; Tue, 4 Aug 2015 15:08:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nuKLRVnjB1HE; Tue, 4 Aug 2015 15:08:23 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 2392D1ACF16; Tue, 4 Aug 2015 15:08:23 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "Ben Campbell" To: "The IESG" X-Test-IDTracker: no X-IETF-IDTracker: 6.3.0.p1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20150804220823.6096.97126.idtracker@ietfa.amsl.com> Date: Tue, 04 Aug 2015 15:08:23 -0700 Archived-At: Cc: draft-ietf-rtcweb-stun-consent-freshness.ad@ietf.org, rtcweb@ietf.org, draft-ietf-rtcweb-stun-consent-freshness@ietf.org, rtcweb-chairs@ietf.org, draft-ietf-rtcweb-stun-consent-freshness.shepherd@ietf.org Subject: [rtcweb] Ben Campbell's Yes on draft-ietf-rtcweb-stun-consent-freshness-15: (with COMMENT) X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 04 Aug 2015 22:08:24 -0000 Ben Campbell has entered the following ballot position for draft-ietf-rtcweb-stun-consent-freshness-15: Yes When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) 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-rtcweb-stun-consent-freshness/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- This looks good overall. I have a few minor comments: -- General: After re-reading this, and the relevant parts of rtcweb-security-architecture, I think a novice reader might find the meaning of "consent" a bit vague, especially in terms of how it might differ from "reachability". Can you offer an example of when an otherwise reachable peer might choose to withdraw consent? -- section 1, first paragraph: I think readers are going to stumble over why we think a device that plans to attack a peer is going to worry about consent. This makes more sense in section 2. It might be helpful to move (or copy) the bit about "... deployments of WebRTC..." and "... malicious javascript" forward to the intro. - 4, 3rd paragraph: Should the reader infer that the receipt of a package that is strongly assured to have come from a party implies consent from that party? If so, it might be worth an explicit mention. -- 5.1, first paragraph: The normative MUST feels wrong here, (and is probably redundant with other normative language further down in the section.) For example, could a sender just choose to stop sending? -- 5.1, 5th paragraph: >From the next paragraph, I infer that you mean consent expires after 30 seconds when you have been sending binding request every few seconds, not 30 seconds after sending any particular binding request. If that's correct it might be helpful to add a few words to that effect. -- 5.1, 6th paragraph: Does the "MUST NOT" refer to the general interval between checks prior to randomization, or to the specific interval between a pair of checks after randomization? Nits: -- 2, 2nd paragraph: "verify peer's consent" Missing article (or "verify peer consent") -- 5.1, paragraph 3: s/sending an stun binding/sending a stun binding -- 5.1, 7th paragraph: "Each STUN binding request for consent MUST use a new STUN transaction identifier for every consent binding request..." That's sort of redundant. I suggest something to the effect of "each consent binding request MUST use a new stun transaction identifier. " From nobody Tue Aug 4 15:30:40 2015 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 739941A8988; Tue, 4 Aug 2015 15:30:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.001 X-Spam-Level: X-Spam-Status: No, score=-2.001 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, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5ditOEXUc-qL; Tue, 4 Aug 2015 15:30:30 -0700 (PDT) Received: from na01-bn1-obe.outbound.protection.outlook.com (mail-bn1on0795.outbound.protection.outlook.com [IPv6:2a01:111:f400:fc10::795]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5CB8E1A8777; Tue, 4 Aug 2015 15:30:29 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=selector1; h=From:To:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=Hg7LHcUEkgT1dUTkKkYTNAQh94sFO7nPOB2TWG1cYR8=; b=b/JAM17Tvty1VzFXPC97U7yumjxjjV2w4jEuWMUXUnWMc0wi1RfsSrtO61nGqKc3mOgB8BXHrSlEQqX20T/4tVO9P+5Oi9i7VZWd3Giw6pMgn6SSjjga7Dlx/vxQ4XJps/1gnt+kf1wH9g6u4H92Oxjk6VBuqHKKvbCsIW2SIQ4= Received: from BL2PR03MB290.namprd03.prod.outlook.com (10.141.68.19) by BL2PR03MB291.namprd03.prod.outlook.com (10.141.68.25) with Microsoft SMTP Server (TLS) id 15.1.225.19; Tue, 4 Aug 2015 22:30:07 +0000 Received: from BL2PR03MB290.namprd03.prod.outlook.com ([10.141.68.19]) by BL2PR03MB290.namprd03.prod.outlook.com ([10.141.68.19]) with mapi id 15.01.0225.018; Tue, 4 Aug 2015 22:30:07 +0000 From: "Orit Levin (LCA)" To: Eric Rescorla Thread-Topic: [rtcweb] [appsdir] Fwd: Request for Apps Directorate review of rtcweb-security drafts Thread-Index: AQHQr4DcT2qcK6DgvkiqLOtwc4J9zZ29oujwgBRIQaCACXjGAIAfyB6QgAEd44CAAFuUQA== Date: Tue, 4 Aug 2015 22:30:06 +0000 Message-ID: References: <558C4C02.3000404@cisco.com> <558C5CA3.7020108@cisco.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=oritl@microsoft.com; x-originating-ip: [2001:4898:80e8:2::3a7] x-microsoft-exchange-diagnostics: 1; BL2PR03MB291; 5:FW24PrAnnU2omZTazryzbtDDXi4b5QgfO4JApAnBoV21YP/kmj7+8SFEuk7aYEZ1eejEJbPRH8KBAo0q87pathlAEd0pE6PP+dVf2qKalIIlk5ihw+KU7HGcD4qYslVxPwoL4squTTgAXheC0AYZfg==; 24:ua36Fd8uoGYwFTMUFzBrSD+3A06Ceav4G6dNr7R08rfYLL1KQgf/l8EGfLJzMzX+3fXIi/ccBT7n1SKxqjH6+Yrhvl0pQ1WDjavdPS3yQSk=; 20:+YGeNyKas5DcdMP3k4W9Qe4dcPnApzM+/Lk88z8J9RgDzdLB6is6//sRuJbEhsf6UClPf9BmFuD5lfWxoTyMoA== x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:BL2PR03MB291; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(108003899814671); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(601004)(2401001)(5005006)(3002001); SRVR:BL2PR03MB291; BCL:0; PCL:0; RULEID:; SRVR:BL2PR03MB291; x-forefront-prvs: 0658BAF71F x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(199003)(479174004)(2473001)(164054003)(189002)(377454003)(13464003)(51914003)(24454002)(10090500001)(77156002)(74316001)(19580405001)(86362001)(19580395003)(106116001)(62966003)(106356001)(105586002)(5003600100002)(86612001)(122556002)(19300405004)(19625215002)(2950100001)(40100003)(102836002)(101416001)(15975445007)(64706001)(2900100001)(19617315012)(2420400006)(46102003)(50986999)(33656002)(2656002)(87936001)(54356999)(76176999)(93886004)(97736004)(16236675004)(99286002)(5001960100002)(5002640100001)(4001540100001)(81156007)(110136002)(7110500001)(5001860100001)(76576001)(92566002)(77096005)(189998001)(10400500002)(5001830100001)(5005710100001)(68736005)(10290500002)(3826002)(559001)(579004); DIR:OUT; SFP:1102; SCL:1; SRVR:BL2PR03MB291; H:BL2PR03MB290.namprd03.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; A:1; MX:1; LANG:en; received-spf: None (protection.outlook.com: microsoft.com does not designate permitted sender hosts) Content-Type: multipart/alternative; boundary="_000_BL2PR03MB2909277FDAF9F0F339D2476AD760BL2PR03MB290namprd_" MIME-Version: 1.0 X-OriginatorOrg: microsoft.com X-MS-Exchange-CrossTenant-originalarrivaltime: 04 Aug 2015 22:30:06.9507 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 72f988bf-86f1-41af-91ab-2d7cd011db47 X-MS-Exchange-Transport-CrossTenantHeadersStamped: BL2PR03MB291 Archived-At: Cc: "appsdir@ietf.org" , "rtcweb@ietf.org" , Eliot Lear Subject: Re: [rtcweb] [appsdir] Fwd: Request for Apps Directorate review of rtcweb-security drafts X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 04 Aug 2015 22:30:36 -0000 --_000_BL2PR03MB2909277FDAF9F0F339D2476AD760BL2PR03MB290namprd_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 VGhhbmtzLCBFa3IhIExvb2tpbmcgZm9yd2FyZCB0byByZWFkaW5nIHRoZSBuZXh0IHZlcnNpb24g b2YgdGhlIGRyYWZ0cy4NCldoZW5ldmVyIGl0IHdvcmtzIGJlc3QgZm9yIHlvdSwgY291bGQgeW91 LCBwbGVhc2UsIHJlcGx5IHRvIHRoZSBvcmlnaW5hbCBlbWFpbCBzaG93aW5nIGlubGluZSBob3cg ZWFjaCBjb21tZW50IGdvdCBhZGRyZXNzZWQ/IFRoYXQgd291bGQgaGVscCBhIGxvdC4NCkNoZWVy cywNCk9yaXQuDQoNCg0KRnJvbTogRXJpYyBSZXNjb3JsYSBbbWFpbHRvOmVrckBydGZtLmNvbV0N ClNlbnQ6IFR1ZXNkYXksIEF1Z3VzdCAwNCwgMjAxNSA5OjQyIEFNDQpUbzogT3JpdCBMZXZpbiAo TENBKSA8b3JpdGxAbWljcm9zb2Z0LmNvbT4NCkNjOiBUZWQgSGFyZGllIDx0ZWQuaWV0ZkBnbWFp bC5jb20+OyBydGN3ZWJAaWV0Zi5vcmc7IGFwcHNkaXJAaWV0Zi5vcmc7IEVsaW90IExlYXIgPGxl YXJAY2lzY28uY29tPg0KU3ViamVjdDogUmU6IFtydGN3ZWJdIFthcHBzZGlyXSBGd2Q6IFJlcXVl c3QgZm9yIEFwcHMgRGlyZWN0b3JhdGUgcmV2aWV3IG9mIHJ0Y3dlYi1zZWN1cml0eSBkcmFmdHMN Cg0KSSdsbCBiZSBoYW5kbGluZyB0aGlzIGFsb25nIHdpdGggdGhlIHJlc3Qgb2YgdGhlIHJldmll dyBjb21tZW50cyBJIGhhdmUgcmVjZWl2ZWQsDQphdCB0aGUgbmV4dCBkcmFmdCB1cGRhdGUgKHBy b2JhYmx5IGJlZm9yZSB0aGUgbmV4dCBSVENXRUIvV2ViUlRDIGludGVyaW0pDQpidXQgSSBkb24n dCBoYXZlIGEgc3BlY2lmaWMgRVRBLg0KDQotRWtyDQoNCg0KDQpPbiBNb24sIEF1ZyAzLCAyMDE1 IGF0IDQ6NDMgUE0sIE9yaXQgTGV2aW4gKExDQSkgPG9yaXRsQG1pY3Jvc29mdC5jb208bWFpbHRv Om9yaXRsQG1pY3Jvc29mdC5jb20+PiB3cm90ZToNCkhpIGd1eXMsDQpUaHJlZSBidXN5IHdlZWtz IGFuZCBhbiBJRVRGIG1lZXRpbmcgaGF2ZSBwYXN04oCmIFdoZW4gc2hvdWxkIHdlIGV4cGVjdCB0 byBzZWUgdGhlIGZlZWRiYWNrIHRvIHRoZSByZXZpZXc/DQpUaGFua3MgYW5kIGNoZWVycywNCk9y aXQuDQoNCkZyb206IFRlZCBIYXJkaWUgW21haWx0bzp0ZWQuaWV0ZkBnbWFpbC5jb208bWFpbHRv OnRlZC5pZXRmQGdtYWlsLmNvbT5dDQpTZW50OiBUdWVzZGF5LCBKdWx5IDE0LCAyMDE1IDExOjE4 IEFNDQpUbzogT3JpdCBMZXZpbiAoTENBKSA8b3JpdGxAbWljcm9zb2Z0LmNvbTxtYWlsdG86b3Jp dGxAbWljcm9zb2Z0LmNvbT4+OyBydGN3ZWJAaWV0Zi5vcmc8bWFpbHRvOnJ0Y3dlYkBpZXRmLm9y Zz4NCkNjOiBFbGlvdCBMZWFyIDxsZWFyQGNpc2NvLmNvbTxtYWlsdG86bGVhckBjaXNjby5jb20+ PjsgYXBwc2RpckBpZXRmLm9yZzxtYWlsdG86YXBwc2RpckBpZXRmLm9yZz4NCg0KU3ViamVjdDog UmU6IFthcHBzZGlyXSBGd2Q6IFJlcXVlc3QgZm9yIEFwcHMgRGlyZWN0b3JhdGUgcmV2aWV3IG9m IHJ0Y3dlYi1zZWN1cml0eSBkcmFmdHMNCg0KKGFkZGluZyB0aGUgV0cpDQpIaSBPcml0LA0KVGhh bmtzIGZvciB0aGUgcmV2aWV3Lg0KcmVnYXJkcywNClRlZCBIYXJkaWUNCg0KT24gVHVlLCBKdWwg MTQsIDIwMTUgYXQgMTE6MDcgQU0sIE9yaXQgTGV2aW4gKExDQSkgPG9yaXRsQG1pY3Jvc29mdC5j b208bWFpbHRvOm9yaXRsQG1pY3Jvc29mdC5jb20+PiB3cm90ZToNCkRpc2NsYWltZXI6IEkgYW0g ZmFtaWxpYXIgd2l0aCBSVEMgYW5kIFdlYlJUQywgYnV0IEkgaGF2ZW4ndCBmb2xsb3dlZCB0aGUg UlRDV2ViIHdvcmsgaW4gdGhlIGxhc3QgZmV3IHllYXJzLiBJIHJlYWQgdGhlIHR3byBkcmFmdHMg Zm9yIHRoZSBmaXJzdCB0aW1lLg0KVGhlcmVmb3JlLCBteSBhcG9sb2dpZXMgZm9yIHBvdGVudGlh bGx5IHJhaXNpbmcgcG9pbnRzIHRoYXQgaGF2ZSBiZWVuIGRpc2N1c3NlZCBpbiB0aGUgcGFzdC4N Cg0KPkZyb20gdGhlIEFQUCAob3IgQVJUKSByZXZpZXcgcGVyc3BlY3RpdmUsIG15IG1haW4gY29t bWVudCBpcyBvbiB0aGUgdG9waWMgb2YgIldlYi1CYXNlZCBQZWVyIEF1dGhlbnRpY2F0aW9uIi4g V2hpbGUgaXQgaXMgbm90IGNsZWFyIGZyb20gdGhlIHRleHQsIHdoaWNoIHBhcnRzIGFyZSBhbHJl YWR5IHN0YW5kYXJkaXplZCBjb25jZXB0cyAoZS5nLiwgYnkgVzNDKSBhbmQgd2hpY2ggYXJlIGlu dHJvZHVjZWQgaGVyZSBmb3IgdGhlIGZpcnN0IHRpbWUsIHRoZSBkZXNjcmliZWQgYXBwcm9hY2gg c2VlbXMgdG8gYmUgKDEpIHVzZWZ1bCB0byB3ZWIgYXBwbGljYXRpb25zIGJleW9uZCBXZWJSVEMs ICgyKSB1bmRlciBkZXZlbG9wbWVudCBhbmQgdGh1cyBwcm9iYWJseSBub3Qgc3RhYmxlLCBhbmQg KDMpIHRvbyBkZXRhaWxlZCBmb3IgImFuIGFyY2hpdGVjdHVyZSIgZG9jdW1lbnQuICBBcyBzdWNo LCB0aGUgY29uY2VwdCBvZiAiIFdlYi1CYXNlZCBQZWVyIEF1dGhlbnRpY2F0aW9uIiBwcm9iYWJs eSBuZWVkcyB0byBiZSBpbnRyb2R1Y2VkIGFuZCBzdGFuZGFyZGl6ZWQgdW5kZXIgdGhlIFNlY3Vy aXR5IEFyZWEgYW5kIHRoZW4gYWRvcHRlZCBieSBXZWJSVEMgYW5kIG90aGVyIGFwcHMuDQoNCmh0 dHBzOi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcvZG9jL2RyYWZ0LWlldGYtcnRjd2ViLXNlY3VyaXR5 Lw0KVGhpcyBkb2N1bWVudCBjb250YWlucyBhbiBleGNlbGxlbnQgY29sbGVjdGlvbiBvZiBzZWN1 cml0eSB0aHJlYXRzIHRvIFdlYlJUQyBhbmQgZGlzY3Vzc2VzIG1hbnkgZGlmZmVyZW50IGlkZWFz IGZvciB0aGVpciBwb3RlbnRpYWwgbWl0aWdhdGlvbi4gVGhhdCBiZWluZyBzYWlkLCBpdCBpcyBu b3QgYW4gZWFzeSByZWFkLiBTcGVjaWZpY2FsbHksIGZyb20gaGlnaCBsZXZlbCB0byBtb3JlIHNw ZWNpZmljOg0KMS4gVGhlIGludGVuZGVkIHN0YXR1cyBvZiB0aGUgZG9jdW1lbnQgaXMgU3RhbmRh cmRzIFRyYWNrLCB3aGlsZSBhIHR5cGljYWwgc3RhdHVzIG9mIGEgInNlY3VyaXR5IHRocmVhdCBt b2RlbCIgUkZDIGlzIEluZm9ybWF0aW9uYWwuIFRoaXMgZGlzY3JlcGFuY3kgcHJvYmFibHkgbGll cyBpbiB0aGUgY3VycmVudCBzY29wZSBvZiB0aGUgZG9jdW1lbnQuIFNlZSB0aGUgbmV4dCBjb21t ZW50IGJlbG93Lg0KMi4gVGhlIHNjb3BlIG9mIHRoZSBkb2N1bWVudCBpcyBub3QgY2xlYXIuIElu IGFkZGl0aW9uIHRvIGRlc2NyaWJpbmcgdGhlIHNlY3VyaXR5IHRocmVhdHMgKGFuZCB0aGUgcmVx dWlyZW1lbnRzIG9yIHVzZXIgZXhwZWN0YXRpb25zIHJlbGF0ZWQgdG8gdGhlaXIgcHJldmVudGlv biksIGluIG1hbnkgcGxhY2VzIHRoZSBkb2N1bWVudCBsaXN0cyBwb3RlbnRpYWwgc29sdXRpb25z IHdpdGggdGhlaXIgcGVyY2VpdmVkIGxpbWl0YXRpb25zIGFuZC9vciBhcHBsaWNhYmlsaXR5LiBF eGFtcGxlcyBhcmUgc2VjdGlvbnM6IDQuMi4xLCA0LjIuMiwgNC4yLjMsIDQuMi40LCA0LjMuMi4x LCA0LjMuMi4yLCA0LjMuMi4zLiBUbyBpbXByb3ZlIHRoZSBkb2N1bWVudCdzIHJlYWRhYmlsaXR5 IGFuZCByZWR1Y2Ugb3ZlcmxhcHMsICB0aGUgc29sdXRpb25zIHNob3VsZCBiZSBpbnRyb2R1Y2Vk IGFuZCBleHBsYWluZWQgaW4gdGhlIGNvbXBhbmlvbiAiYXJjaGl0ZWN0dXJlIiBkb2N1bWVudC4g U29sdXRpb25zJyBhcHBsaWNhYmlsaXR5IHRvIGRpZmZlcmVudCB1c2UgY2FzZXMgbmVlZHMgdG8g YmUgcHJvdmlkZWQgaW4gYSBub24tYmlhcyB3YXkuDQozLiBBcGFydCBmcm9tIHRoZSBicmllZiBJ bnRyb2R1Y3Rpb24gd2l0aCBhIGZldyBleGFtcGxlcywgdGhlcmUgaXMgbm8gZGVzY3JpcHRpb24g b2YgdGhlIFdlYlJUQyB0aHJlYXQgbW9kZWwgcHV0dGluZyBhbGwgbWFpbiB0eXBlcyBvZiB0aHJl YXQgaW4gb25lIHBsYWNlLiBGb3IgZXhhbXBsZSwgdGhlICJDb21tdW5pY2F0aW9ucyBTZWN1cml0 eSIgYXNwZWN0IGlzIGludHJvZHVjZWQgZm9yIHRoZSBmaXJzdCB0aW1lIGluIFNlY3Rpb24gNC4z IG9ubHkuIFRoZSBzdGFydCBvZiBTZWN0aW9uICI0LiBTZWN1cml0eSBmb3IgV2ViUlRDIEFwcGxp Y2F0aW9ucyIgY291bGQgYmUgYSBsb2dpY2FsIHBsYWNlIGZvciBpbnRyb2R1Y2luZyB0aGUgV2Vi UlRDIHRocmVhdCBtb2RlbC4NCjQuIFRoZSAic2ltcGxlIFdlYlJUQyBzeXN0ZW0iIHByZXNlbnRl ZCBpbiB0aGUgSW50cm9kdWN0aW9uIGluIEZpZ3VyZSAxIGlzIGluYWRlcXVhdGUgdG8gaWxsdXN0 cmF0ZSBtYW55IG9mIHRoZSBzY2VuYXJpb3MgYW5kIHBvaW50cyBkaXNjdXNzZWQgaW4gdGhlIGRv Y3VtZW50LiBGb3IgZXhhbXBsZSwgc2VlIHRoZSBkaXNjdXNzaW9uIGFyb3VuZCBtZWRpYSBvcmln aW4gdnMuIHdlYiBvcmlnaW4gaW4gU2VjdGlvbiA0LjEuMy4NCjUuIFNlY3Rpb24gIjMuIFRoZSBC cm93c2VyIFRocmVhdCBNb2RlbCIgaXMgYW4gb3ZlcnZpZXcgb2YgdGhlIGV4aXN0aW5nIHdlYiBz ZWN1cml0eSBhcmNoaXRlY3R1cmUgYW5kIHNvbWUgY3VycmVudCBwcmFjdGljZXMuIEFzIHN1Y2gs IHJlZmVyZW5jZXMgdG8gcmVsZXZhbnQgc3RhbmRhcmRzIChlLmcuLCBXM0MpIGFuZCBjb21tb24g cHJhY3RpY2VzIG5lZWQgdG8gYmUgYWRkZWQgd2l0aGluIHRoZSB0ZXh0IHRvIGhlbHAgdGhlIHJl YWRlciB0byB1bmRlcnN0YW5kIHRoZSBzdGF0dXMgb2YgdGhlIGluZm9ybWF0aW9uIGFuZCB0byBm b2xsb3cgdGhlIHNvdXJjZXMuDQo2LiBUaGUgbGFzdCBwYXJhZ3JhcGggaW4gU2VjdGlvbiA0LjEg Y29udmV5cyBhIGtleSBwb2ludCBpbiB0aGUgd2hvbGUgV2ViUlRDIHRocmVhdCBtb2RlbC4gQXMg c3VjaCwgIGl0IG5lZWRzIHRvIGJlIG1vdmVkIHRvIHRoZSBzdGFydCBvZiB0aGUgZGlzY3Vzc2lv biB3aGVyZSB0aGUgdGhyZWF0IG1vZGVsIGlzIGludHJvZHVjZWQgKHNlZSBjb21tZW50cyBhYm92 ZSkuDQo3LiBTdHlsaXN0aWNhbGx5LCB0aGUgZG9jdW1lbnQgd291bGQgYmVuZWZpdCBmcm9tIHJl bW92aW5nIG5vbi1zdGFuZGFyZHMgdm9jYWJ1bGFyeSwgaS5lLiwgInRvIGJ1ZyIsICJ0byBidWcg bWUiLCAibm8gcmVhbCB3YXkiLCAiaXQgaXMgaW1wb3J0YW50IHRvIHJlcXVpcmUiLCAiZXh0cmVt ZWx5IGFnZ3Jlc3NpdmUgaW50ZXJtZWRpYXRlcyIsICBhbmQgImZvciBvYnZpb3VzIHJlYXNvbnMi LCBldGMuDQo4LiBTdWdnZXN0aW9ucyBmb3IgcmVuYW1pbmcgc29tZSBvZiB0aGUgc2VjdGlvbnMg dG8gaW1wcm92ZSByZWFkYWJpbGl0eToNCiIzLiBUaGUgQnJvd3NlciBUaHJlYXQgTW9kZWwiIC0+ ICIgMy4gT3ZlcnZpZXcgb2YgdGhlIEV4aXN0aW5nIFdlYiBUaHJlYXQgTW9kZWwiDQoiNC4xLiBB Y2Nlc3MgdG8gTG9jYWwgRGV2aWNlcyIgLT4gIjQuMS4gQ29uc2VudCB0byBBY2Nlc3MgTG9jYWwg UmVzb3VyY2VzIg0KIjQuMS4yLiBDYWxsaW5nIFNjZW5hcmlvcyBhbmQgVXNlciBFeHBlY3RhdGlv bnMiIC0+ICI0LjEuMi4gU2NvcGUgb2YgQ29uc2VudCBpbiBWYXJpb3VzIENhbGxpbmcgU2NlbmFy aW9zIg0KIjQuMS4yLjEuIERlZGljYXRlZCBDYWxsaW5nIFNlcnZpY2VzIiAtPiAiNC4xLjIuMS4g TG9uZy10ZXJtIENvbnNlbnQiDQoiNC4xLjIuMi4gQ2FsbGluZyB0aGUgc2l0ZSBZb3UncmUgT24i IC0+ICI0LjEuMi4yLiBTaG9ydC10ZXJtIENvbnNlbnQiDQoiNC4xLjMuIE9yaWdpbi1CYXNlZCBT ZWN1cml0eSIgLT4gIjQuMS4zLiBXZWIgQXR0YWNrZXJzIGFuZCBPcmlnaW4tYmFzZWQgU2VjdXJp dHkiDQoiNC4xLjQuIFNlY3VyaXR5IFByb3BlcnRpZXMgb2YgdGhlIENhbGxpbmcgUGFnZSIgLT4g IjQuMS40LiBOZXR3b3JrIEF0dGFja2VycyBhbmQgIFNlY3VyaXR5IFByb3BlcnRpZXMgb2YgdGhl IENhbGxpbmcgUGFnZSINCiI0LjIuIENvbW11bmljYXRpb25zIENvbnNlbnQgVmVyaWZpY2F0aW9u IiAtPiAiNC4yLiBDb25zZW50IHRvIFJlY2VpdmUgVHJhZmZpYyINCiI0LjMuMy4gTWFsaWNpb3Vz IFBlZXJzIiAtPiAiNC4zLjMuIE91dCBvZiBTY29wZSINCg0KaHR0cHM6Ly9kYXRhdHJhY2tlci5p ZXRmLm9yZy9kb2MvZHJhZnQtaWV0Zi1ydGN3ZWItc2VjdXJpdHktYXJjaC8NClRoaXMgZG9jdW1l bnQgaXMgaW4gYSBtdWNoIGJldHRlciBzdGF0ZSBpbiB0ZXJtcyBvZiBpdHMgb3JnYW5pemF0aW9u IGFuZCByZWFkYWJpbGl0eS4gSXQgaW50cm9kdWNlcyB0aGUgc2VjdXJpdHkgYXJjaGl0ZWN0dXJl IHVzaW5nIGFuIGV4YW1wbGUgYW5kIHRoZW4gbGlzdHMgcG9zc2libGUgYXBwcm9hY2hlcyB0byBp bXBsZW1lbnQgaXQuIFNvbWUgYXBwcm9hY2hlcyBhcmUgZGVzY3JpYmVkIG9uIGEgaGlnaCBsZXZl bCBieSByZWZlcmVuY2luZyBvdGhlciBkb2N1bWVudHMsIHdoaWxlIG90aGVycyBhcmUgaW50cm9k dWNlZCBmb3IgdGhlIGZpcnN0IHRpbWUgaW4gdGhpcyBkb2N1bWVudCB0b2dldGhlciB3aXRoIHRo ZWlyIGltcGxlbWVudGF0aW9uIGRldGFpbHMuIEJ5IGp1c3QgcmVhZGluZyB0aGUgZG9jdW1lbnQs IGl0IGlzIGRpZmZpY3VsdCB0byBqdWRnZSB3aGV0aGVyIHRoZXNlIGRldGFpbHMgYXJlIHN1ZmZp Y2llbnQgb3Igc3RhYmxlIGVub3VnaCBmb3IgaW1wbGVtZW50YXRpb24uIEluIGdlbmVyYWwsIEkg ZG91YnQgdGhhdCB0aGlzIGlzIHRoZSBiZXN0IGFwcHJvYWNoIGZvciBhbiAiYXJjaGl0ZWN0dXJl IiBkb2N1bWVudCwgd2hpY2ggaXMgc3VwcG9zZWQgdG8gc2VydmUgYXMgYSBsb25nIHRlcm0gc3Rh YmxlIHJlZmVyZW5jZS4NCk1vcmUgc3BlY2lmaWMgY29tbWVudHM6DQoxLiBEaWZmZXJlbnQgdGVy bWlub2xvZ3kgaXMgdXNlZCB0aHJvdWdob3V0IHRoZSBkb2N1bWVudCB0byBhZGRyZXNzIHNhbWUg b3IgY2xvc2UgY29uY2VwdHMuIEl0IHdvdWxkIGhlbHAgYSBsb3QgdG8gZXhwbGFpbiB0aGUgY29u Y2VwdHMgdXBmcm9udCBhbmQgdGhlbiB0byB1c2UgdGhlIHRlcm1pbm9sb2d5IGNvbnNpc3RlbnRs eS4gQ3VycmVudGx5IGl0IGluY2x1ZGVzICJjbGllbnQiLCAiZW5kcG9pbnQiLCAgInBlZXIiLCAi dXNlciI7ICJpbXBsZW1lbnRhdGlvbiIsICJicm93c2VyIiwgImNocm9tZSIsICJBUEkiLCAiSlMi OyAiYXBwbGljYXRpb24iLCAic2VydmVyIiwgZXRjLg0KMi4gVGhlIGRpc2N1c3Npb24gaXMgcGhy YXNlZCBpbiB0ZXJtcyBvZiAiYXV0aGVudGljYXRpb24iIGFuZCAidHJ1c3QiLiBJbiB0aGluayB0 aGF0ICJhdXRob3JpemF0aW9uIiBpbnN0ZWFkIG9mICJ0cnVzdCIgd291bGQgYmUgYSBiZXR0ZXIg dGVjaG5pY2FsIHRlcm0sIGZvciBleGFtcGxlLCBpbiBTZWN0aW9uIDMuMS4NCjMuIEluIHNlY3Rp b24gNC4gT3ZlcnZpZXcsIHNlbnRlbmNlICJ0aGUgdGVuc2lvbiBiZXR3ZWVuIHNlY3VyaXR5IChv ciBwZXJmb3JtYW5jZSkgYW5kIHByaXZhY3kiIGlzIG5vdCBjbGVhciwgZXNwZWNpYWxseSBiZWNh dXNlIGl0IGRvZXNuJ3Qgc2VlbSB0byBjb3JyZXNwb25kIHRvIFNlY3Rpb24gNi4yLiAoQlRXICJ0 cmFkZW9mZiIgd291bGQgYmUgYSBiZXR0ZXIgd29yZCB0aGFuICJ0ZW5zaW9uIi4pDQo0LiBTZWN0 aW9uICI0LjEuIEluaXRpYWwgU2lnbmFsaW5nIiwgdGhlIHRleHQgaXMgaW5jb25zaXN0ZW50IGlu IHRlcm1zIG9mIHdoZXRoZXIgQWxpY2UgYW5kIEJvYiBzaGFyZSBvciB1c2UgZGlmZmVyZW50IGlk ZW50aXR5IHByb3ZpZGVycy4NCjUuIFNlY3Rpb24gIjQuMS4gSW5pdGlhbCBTaWduYWxpbmciLCBy ZWZlcmVuY2UgdG8gUGVlckNvbm5lY3Rpb24gbmVlZHMgdG8gYmUgYWRkZWQuDQo2LiBTZWN0aW9u ICI0LjIuIE1lZGlhIENvbnNlbnQgVmVyaWZpY2F0aW9uIiBhbmQgU2VjdGlvbiAiNS4zIENvbW11 bmljYXRpb25zIENvbnNlbnQiOiB0aGUgbmFtZS90ZXJtaW5vbG9neSBvZiB0aGlzIGZ1bmN0aW9u YWxpdHkgbmVlZHMgdG8gYmUgaGFybW9uaXplZC4gVGhlIElDRS1iYXNlZCBzb2x1dGlvbiB3aXRo IGl0cyBwcm9zLCBjb25zIGFzIHdlbGwgYXMgdGhlIGFsdGVybmF0aXZlcyAoYXBwbGljYWJsZSB0 byBkaWZmZXJlbnQgdXNlIGNhc2VzKSBuZWVkIHRvIGJlIG1vdmVkIGZyb20gdGhlIGNvbXBhbmlv biB0aHJlYXQgbW9kZWwgZG9jdW1lbnQgdG8gdGhpcyAiYXJjaGl0ZWN0dXJlIiBvbmUuDQo3LiBB IHN1Z2dlc3Rpb246IHJlbmFtZSAiNS4gRGV0YWlsZWQgVGVjaG5pY2FsIERlc2NyaXB0aW9uIiB0 byAiNS4gU2VjdXJpdHkgQXJjaGl0ZWN0dXJlIENvbXBvbmVudHMiLg0KOC4gSW4gU2VjdGlvbiA1 LjIuLCAiSW1wbGVtZW50YXRpb25zIHdoaWNoIHN1cHBvcnQgc29tZSBmb3JtIG9mIGRpcmVjdCB1 c2VyIGF1dGhlbnRpY2F0aW9uLi4uIiAtPiAiSW1wbGVtZW50YXRpb25zIHRoYXQgc3VwcG9ydCBz b21lIGZvcm0gb2YgZGlyZWN0IHVzZXIgYXV0aGVudGljYXRpb24uLi4iDQo5LiBTZWN0aW9uICI1 LjYuIFdlYi1CYXNlZCBQZWVyIEF1dGhlbnRpY2F0aW9uIiBhbmQgc2VjdGlvbiAiNS42LjIuIE92 ZXJ2aWV3IG9mIG9wZXJhdGlvbiI6IEl0IGlzIG5vdCBjbGVhciwgd2hpY2ggcGFydHMgYXJlIHN0 YW5kYXJkaXplZCBjb25jZXB0cyAoZS5nLiwgYnkgVzNDKSBhbmQgd2hpY2ggYXJlIGludHJvZHVj ZWQgaGVyZSBmb3IgdGhlIGZpcnN0IHRpbWUuIElmIGV4aXN0LCByZWZlcmVuY2VzIHRvIGV4aXN0 aW5nIHN0YW5kYXJkcyBuZWVkIHRvIGJlIGFkZGVkLiBUaGUgZGVzY3JpYmVkIGFyY2hpdGVjdHVy ZSBhbmQgdGhlIHRlY2huaWNhbCBkZXRhaWxzIHNlZW0gdG8gYmUgKDEpIHVuZGVyIGRldmVsb3Bt ZW50IGFuZCB0aHVzIHByb2JhYmx5IG5vdCBzdGFibGUsICgyKSB0b28gZGV0YWlsZWQgZm9yICJh biBhcmNoaXRlY3R1cmUiIGRvY3VtZW50IGFuZCAoMykgdXNlZnVsIGJleW9uZCBXZWJSVEMuICBB cyBzdWNoLCB0aGUgY29uY2VwdCBvZiB0aGUgIiBXZWItQmFzZWQgUGVlciBBdXRoZW50aWNhdGlv biIgcHJvYmFibHkgbmVlZHMgYmUgaW50cm9kdWNlZCB1bmRlciB0aGUgU2VjdXJpdHkgQXJlYSBh bmQgdGhlbiBhZG9wdGVkIGJ5IFdlYlJUQy4NCjEwLiBUaGUgd2ViLWJhc2VkIHBlZXIgYXV0aGVu dGljYXRpb24gdXNpbmcgSWRQIGlzIG5vdCB0aGUgb25seSBtZWNoYW5pc20gYXBwbGljYWJsZSB0 byBXZWJSVEMuIE1vcmVvdmVyLCB0aGUgd2ViLWJhc2VkIHBlZXIgYXV0aGVudGljYXRpb24gIGlz IG5vdCB0aGUgb25seSBhcHByb2FjaCBhcHBsaWNhYmxlIHRvIFdlYlJUQy4gQWx0ZXJuYXRpdmVz IGFyZSBsaXN0ZWQgaW4gdGhlIGNvbXBhbmlvbiBkb2N1bWVudCBhbmQgbmVlZCB0byBiZSBtb3Zl ZCBoZXJlIHRvIHRoZSAiYXJjaGl0ZWN0dXJlIiBkb2N1bWVudCB3aXRoIHRoZWlyIHByb3MgYW5k IGNvbnMgcHJlc2VudGVkIGluIGFuIHVuYmlhc2VkIHdheS4NCjExLiBTdHlsaXN0aWNhbGx5LCB0 aGUgZG9jdW1lbnQgd291bGQgYmVuZWZpdCBmcm9tIHJlbW92aW5nIG5vbi1zdGFuZGFyZHMgdm9j YWJ1bGFyeSwgaS5lLiwgInNvbWUgV2ViIHNlcnZlciIsICJjYW4ndCByZWFsbHkgdHJ1c3QiLCAi dGhhdCBtdWNoIiwgImZhaXJseSBjb252ZW50aW9uYWwiLCAic2ltcGx5IGhhdmUiLCAiYSBsaXR0 bGUgYW50aWNsaW1hY3RpYyIsIGV0Yy4gOy0pDQoNClRoYW5rcywNCk9yaXQuDQoNCj4gLS0tLS1P cmlnaW5hbCBNZXNzYWdlLS0tLS0NCj4gRnJvbTogYXBwc2RpciBbbWFpbHRvOmFwcHNkaXItYm91 bmNlc0BpZXRmLm9yZzxtYWlsdG86YXBwc2Rpci1ib3VuY2VzQGlldGYub3JnPl0gT24gQmVoYWxm IE9mIE9yaXQgTGV2aW4NCj4gKExDQSkNCj4gU2VudDogVGh1cnNkYXksIEp1bmUgMjUsIDIwMTUg MToxNyBQTQ0KPiBUbzogRWxpb3QgTGVhcjsgYXBwc2RpckBpZXRmLm9yZzxtYWlsdG86YXBwc2Rp ckBpZXRmLm9yZz4NCj4gU3ViamVjdDogUmU6IFthcHBzZGlyXSBGd2Q6IFJlcXVlc3QgZm9yIEFw cHMgRGlyZWN0b3JhdGUgcmV2aWV3IG9mIHJ0Y3dlYi0NCj4gc2VjdXJpdHkgZHJhZnRzDQo+DQo+ IFBlcmZlY3QhIEkgaGF2ZSBhIHZlcnkgbG9uZyBmbGlnaHQgb24gdGhlIDd0aC4uLiBTbyByaWdo dCBhZnRlciB0aGVuIG9yIGVhcmxpZXIuDQo+IE9yaXQuDQo+DQo+ID4gLS0tLS1PcmlnaW5hbCBN ZXNzYWdlLS0tLS0NCj4gPiBGcm9tOiBFbGlvdCBMZWFyIFttYWlsdG86bGVhckBjaXNjby5jb208 bWFpbHRvOmxlYXJAY2lzY28uY29tPl0NCj4gPiBTZW50OiBUaHVyc2RheSwgSnVuZSAyNSwgMjAx NSAxMjo1NSBQTQ0KPiA+IFRvOiBPcml0IExldmluIChMQ0EpOyBhcHBzZGlyQGlldGYub3JnPG1h aWx0bzphcHBzZGlyQGlldGYub3JnPg0KPiA+IFN1YmplY3Q6IFJlOiBbYXBwc2Rpcl0gRndkOiBS ZXF1ZXN0IGZvciBBcHBzIERpcmVjdG9yYXRlIHJldmlldyBvZiBydGN3ZWItDQo+ID4gc2VjdXJp dHkgZHJhZnRzDQo+ID4NCj4gPiBUaGFuayB5b3UgT3JpdCEgIENhbiB5b3UgdHJ5IHRvIGhhdmUg dGhlbSBkb25lIGluIGFib3V0IHR3byB3ZWVrcz8NCj4gPg0KPiA+IEVsaW90DQo+ID4NCj4gPiBP biA2LzI1LzE1IDk6NTIgUE0sIE9yaXQgTGV2aW4gKExDQSkgd3JvdGU6DQo+ID4gPiBJIHdpbGwg YmUgaGFwcHkgdG8gdGFrZSBhIGxvb2sgYXQgdGhlbSENCj4gPiA+IE9yaXQuDQo+ID4gPg0KPiA+ ID4+IC0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQo+ID4gPj4gRnJvbTogYXBwc2RpciBbbWFp bHRvOmFwcHNkaXItYm91bmNlc0BpZXRmLm9yZzxtYWlsdG86YXBwc2Rpci1ib3VuY2VzQGlldGYu b3JnPl0gT24gQmVoYWxmIE9mIEVsaW90DQo+IExlYXINCj4gPiA+PiBTZW50OiBUaHVyc2RheSwg SnVuZSAyNSwgMjAxNSAxMTo0NCBBTQ0KPiA+ID4+IFRvOiBhcHBzZGlyQGlldGYub3JnPG1haWx0 bzphcHBzZGlyQGlldGYub3JnPg0KPiA+ID4+IFN1YmplY3Q6IFthcHBzZGlyXSBGd2Q6IFJlcXVl c3QgZm9yIEFwcHMgRGlyZWN0b3JhdGUgcmV2aWV3IG9mIHJ0Y3dlYi0NCj4gPiA+PiBzZWN1cml0 eSBkcmFmdHMNCj4gPiA+Pg0KPiA+ID4+IERlYXIgQXBwc2RpciBmb2xrLA0KPiA+ID4+DQo+ID4g Pj4gQ291bGQgSSBoYXZlIGEgdm9sdW50ZWVyIHRvIHJldmlldyB0aGUgZm9sbG93aW5nIHR3byBk cmFmdHM/DQo+ID4gPj4NCj4gPiA+PiBodHRwczovL2RhdGF0cmFja2VyLmlldGYub3JnL2RvYy9k cmFmdC1pZXRmLXJ0Y3dlYi1zZWN1cml0eS8NCj4gPiA+Pg0KPiA+ID4+IGFuZA0KPiA+ID4+DQo+ ID4gPj4gaHR0cHM6Ly9kYXRhdHJhY2tlci5pZXRmLm9yZy9kb2MvZHJhZnQtaWV0Zi1ydGN3ZWIt c2VjdXJpdHktYXJjaC8NCj4gPiA+Pg0KPiA+ID4+IFRlZCBpcyBleGVtcHQsIGhhdmluZyBtYWRl IHRoZSByZXF1ZXN0IDstKQ0KPiA+ID4+DQo+ID4gPj4gRWxpb3QNCj4gPg0KPg0KPiBfX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KPiBhcHBzZGlyIG1haWxp bmcgbGlzdA0KPiBhcHBzZGlyQGlldGYub3JnPG1haWx0bzphcHBzZGlyQGlldGYub3JnPg0KPiBo dHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL2FwcHNkaXINCg0KX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCmFwcHNkaXIgbWFpbGluZyBs aXN0DQphcHBzZGlyQGlldGYub3JnPG1haWx0bzphcHBzZGlyQGlldGYub3JnPg0KaHR0cHM6Ly93 d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9hcHBzZGlyDQoNCg0KX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCnJ0Y3dlYiBtYWlsaW5nIGxpc3QNCnJ0 Y3dlYkBpZXRmLm9yZzxtYWlsdG86cnRjd2ViQGlldGYub3JnPg0KaHR0cHM6Ly93d3cuaWV0Zi5v cmcvbWFpbG1hbi9saXN0aW5mby9ydGN3ZWINCg0K --_000_BL2PR03MB2909277FDAF9F0F339D2476AD760BL2PR03MB290namprd_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IlByb2dJZCIg Y29udGVudD0iV29yZC5Eb2N1bWVudCI+DQo8bWV0YSBuYW1lPSJHZW5lcmF0b3IiIGNvbnRlbnQ9 Ik1pY3Jvc29mdCBXb3JkIDE1Ij4NCjxtZXRhIG5hbWU9Ik9yaWdpbmF0b3IiIGNvbnRlbnQ9Ik1p Y3Jvc29mdCBXb3JkIDE1Ij4NCjxsaW5rIHJlbD0iRmlsZS1MaXN0IiBocmVmPSJjaWQ6ZmlsZWxp c3QueG1sQDAxRDBDRUNBLjZCRTk5NDUwIj48IS0tW2lmIGd0ZSBtc28gOV0+PHhtbD4NCjxvOk9m ZmljZURvY3VtZW50U2V0dGluZ3M+DQo8bzpBbGxvd1BORy8+DQo8L286T2ZmaWNlRG9jdW1lbnRT ZXR0aW5ncz4NCjwveG1sPjwhW2VuZGlmXS0tPjwhLS1baWYgZ3RlIG1zbyA5XT48eG1sPg0KPHc6 V29yZERvY3VtZW50Pg0KPHc6U3BlbGxpbmdTdGF0ZT5DbGVhbjwvdzpTcGVsbGluZ1N0YXRlPg0K PHc6VHJhY2tNb3Zlcy8+DQo8dzpUcmFja0Zvcm1hdHRpbmcvPg0KPHc6RW52ZWxvcGVWaXMvPg0K PHc6VmFsaWRhdGVBZ2FpbnN0U2NoZW1hcy8+DQo8dzpTYXZlSWZYTUxJbnZhbGlkPmZhbHNlPC93 OlNhdmVJZlhNTEludmFsaWQ+DQo8dzpJZ25vcmVNaXhlZENvbnRlbnQ+ZmFsc2U8L3c6SWdub3Jl TWl4ZWRDb250ZW50Pg0KPHc6QWx3YXlzU2hvd1BsYWNlaG9sZGVyVGV4dD5mYWxzZTwvdzpBbHdh eXNTaG93UGxhY2Vob2xkZXJUZXh0Pg0KPHc6RG9Ob3RQcm9tb3RlUUYvPg0KPHc6TGlkVGhlbWVP dGhlcj5FTi1VUzwvdzpMaWRUaGVtZU90aGVyPg0KPHc6TGlkVGhlbWVBc2lhbj5YLU5PTkU8L3c6 TGlkVGhlbWVBc2lhbj4NCjx3OkxpZFRoZW1lQ29tcGxleFNjcmlwdD5YLU5PTkU8L3c6TGlkVGhl bWVDb21wbGV4U2NyaXB0Pg0KPHc6Q29tcGF0aWJpbGl0eT4NCjx3OkRvTm90RXhwYW5kU2hpZnRS ZXR1cm4vPg0KPHc6QnJlYWtXcmFwcGVkVGFibGVzLz4NCjx3OlNwbGl0UGdCcmVha0FuZFBhcmFN YXJrLz4NCjx3OkVuYWJsZU9wZW5UeXBlS2VybmluZy8+DQo8L3c6Q29tcGF0aWJpbGl0eT4NCjxt Om1hdGhQcj4NCjxtOm1hdGhGb250IG06dmFsPSJDYW1icmlhIE1hdGgiLz4NCjxtOmJya0JpbiBt OnZhbD0iYmVmb3JlIi8+DQo8bTpicmtCaW5TdWIgbTp2YWw9IiYjNDU7LSIvPg0KPG06c21hbGxG cmFjIG06dmFsPSJvZmYiLz4NCjxtOmRpc3BEZWYvPg0KPG06bE1hcmdpbiBtOnZhbD0iMCIvPg0K PG06ck1hcmdpbiBtOnZhbD0iMCIvPg0KPG06ZGVmSmMgbTp2YWw9ImNlbnRlckdyb3VwIi8+DQo8 bTp3cmFwSW5kZW50IG06dmFsPSIxNDQwIi8+DQo8bTppbnRMaW0gbTp2YWw9InN1YlN1cCIvPg0K PG06bmFyeUxpbSBtOnZhbD0idW5kT3ZyIi8+DQo8L206bWF0aFByPjwvdzpXb3JkRG9jdW1lbnQ+ DQo8L3htbD48IVtlbmRpZl0tLT48IS0tW2lmIGd0ZSBtc28gOV0+PHhtbD4NCjx3OkxhdGVudFN0 eWxlcyBEZWZMb2NrZWRTdGF0ZT0iZmFsc2UiIERlZlVuaGlkZVdoZW5Vc2VkPSJmYWxzZSIgRGVm U2VtaUhpZGRlbj0iZmFsc2UiIERlZlFGb3JtYXQ9ImZhbHNlIiBEZWZQcmlvcml0eT0iOTkiIExh dGVudFN0eWxlQ291bnQ9IjM3MSI+DQo8dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJmYWxzZSIgUHJp b3JpdHk9IjAiIFFGb3JtYXQ9InRydWUiIE5hbWU9Ik5vcm1hbCIvPg0KPHc6THNkRXhjZXB0aW9u IExvY2tlZD0iZmFsc2UiIFByaW9yaXR5PSI5IiBRRm9ybWF0PSJ0cnVlIiBOYW1lPSJoZWFkaW5n IDEiLz4NCjx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBQcmlvcml0eT0iOSIgU2VtaUhp ZGRlbj0idHJ1ZSIgVW5oaWRlV2hlblVzZWQ9InRydWUiIFFGb3JtYXQ9InRydWUiIE5hbWU9Imhl YWRpbmcgMiIvPg0KPHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFByaW9yaXR5PSI5IiBT ZW1pSGlkZGVuPSJ0cnVlIiBVbmhpZGVXaGVuVXNlZD0idHJ1ZSIgUUZvcm1hdD0idHJ1ZSIgTmFt ZT0iaGVhZGluZyAzIi8+DQo8dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJmYWxzZSIgUHJpb3JpdHk9 IjkiIFNlbWlIaWRkZW49InRydWUiIFVuaGlkZVdoZW5Vc2VkPSJ0cnVlIiBRRm9ybWF0PSJ0cnVl IiBOYW1lPSJoZWFkaW5nIDQiLz4NCjx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBQcmlv cml0eT0iOSIgU2VtaUhpZGRlbj0idHJ1ZSIgVW5oaWRlV2hlblVzZWQ9InRydWUiIFFGb3JtYXQ9 InRydWUiIE5hbWU9ImhlYWRpbmcgNSIvPg0KPHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFsc2Ui IFByaW9yaXR5PSI5IiBTZW1pSGlkZGVuPSJ0cnVlIiBVbmhpZGVXaGVuVXNlZD0idHJ1ZSIgUUZv cm1hdD0idHJ1ZSIgTmFtZT0iaGVhZGluZyA2Ii8+DQo8dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJm YWxzZSIgUHJpb3JpdHk9IjkiIFNlbWlIaWRkZW49InRydWUiIFVuaGlkZVdoZW5Vc2VkPSJ0cnVl IiBRRm9ybWF0PSJ0cnVlIiBOYW1lPSJoZWFkaW5nIDciLz4NCjx3OkxzZEV4Y2VwdGlvbiBMb2Nr ZWQ9ImZhbHNlIiBQcmlvcml0eT0iOSIgU2VtaUhpZGRlbj0idHJ1ZSIgVW5oaWRlV2hlblVzZWQ9 InRydWUiIFFGb3JtYXQ9InRydWUiIE5hbWU9ImhlYWRpbmcgOCIvPg0KPHc6THNkRXhjZXB0aW9u IExvY2tlZD0iZmFsc2UiIFByaW9yaXR5PSI5IiBTZW1pSGlkZGVuPSJ0cnVlIiBVbmhpZGVXaGVu VXNlZD0idHJ1ZSIgUUZvcm1hdD0idHJ1ZSIgTmFtZT0iaGVhZGluZyA5Ii8+DQo8dzpMc2RFeGNl cHRpb24gTG9ja2VkPSJmYWxzZSIgU2VtaUhpZGRlbj0idHJ1ZSIgVW5oaWRlV2hlblVzZWQ9InRy dWUiIE5hbWU9ImluZGV4IDEiLz4NCjx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBTZW1p SGlkZGVuPSJ0cnVlIiBVbmhpZGVXaGVuVXNlZD0idHJ1ZSIgTmFtZT0iaW5kZXggMiIvPg0KPHc6 THNkRXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFNlbWlIaWRkZW49InRydWUiIFVuaGlkZVdoZW5V c2VkPSJ0cnVlIiBOYW1lPSJpbmRleCAzIi8+DQo8dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJmYWxz ZSIgU2VtaUhpZGRlbj0idHJ1ZSIgVW5oaWRlV2hlblVzZWQ9InRydWUiIE5hbWU9ImluZGV4IDQi Lz4NCjx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBTZW1pSGlkZGVuPSJ0cnVlIiBVbmhp ZGVXaGVuVXNlZD0idHJ1ZSIgTmFtZT0iaW5kZXggNSIvPg0KPHc6THNkRXhjZXB0aW9uIExvY2tl ZD0iZmFsc2UiIFNlbWlIaWRkZW49InRydWUiIFVuaGlkZVdoZW5Vc2VkPSJ0cnVlIiBOYW1lPSJp bmRleCA2Ii8+DQo8dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJmYWxzZSIgU2VtaUhpZGRlbj0idHJ1 ZSIgVW5oaWRlV2hlblVzZWQ9InRydWUiIE5hbWU9ImluZGV4IDciLz4NCjx3OkxzZEV4Y2VwdGlv biBMb2NrZWQ9ImZhbHNlIiBTZW1pSGlkZGVuPSJ0cnVlIiBVbmhpZGVXaGVuVXNlZD0idHJ1ZSIg TmFtZT0iaW5kZXggOCIvPg0KPHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFNlbWlIaWRk ZW49InRydWUiIFVuaGlkZVdoZW5Vc2VkPSJ0cnVlIiBOYW1lPSJpbmRleCA5Ii8+DQo8dzpMc2RF eGNlcHRpb24gTG9ja2VkPSJmYWxzZSIgUHJpb3JpdHk9IjM5IiBTZW1pSGlkZGVuPSJ0cnVlIiBV bmhpZGVXaGVuVXNlZD0idHJ1ZSIgTmFtZT0idG9jIDEiLz4NCjx3OkxzZEV4Y2VwdGlvbiBMb2Nr ZWQ9ImZhbHNlIiBQcmlvcml0eT0iMzkiIFNlbWlIaWRkZW49InRydWUiIFVuaGlkZVdoZW5Vc2Vk PSJ0cnVlIiBOYW1lPSJ0b2MgMiIvPg0KPHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFBy aW9yaXR5PSIzOSIgU2VtaUhpZGRlbj0idHJ1ZSIgVW5oaWRlV2hlblVzZWQ9InRydWUiIE5hbWU9 InRvYyAzIi8+DQo8dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJmYWxzZSIgUHJpb3JpdHk9IjM5IiBT ZW1pSGlkZGVuPSJ0cnVlIiBVbmhpZGVXaGVuVXNlZD0idHJ1ZSIgTmFtZT0idG9jIDQiLz4NCjx3 OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBQcmlvcml0eT0iMzkiIFNlbWlIaWRkZW49InRy dWUiIFVuaGlkZVdoZW5Vc2VkPSJ0cnVlIiBOYW1lPSJ0b2MgNSIvPg0KPHc6THNkRXhjZXB0aW9u IExvY2tlZD0iZmFsc2UiIFByaW9yaXR5PSIzOSIgU2VtaUhpZGRlbj0idHJ1ZSIgVW5oaWRlV2hl blVzZWQ9InRydWUiIE5hbWU9InRvYyA2Ii8+DQo8dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJmYWxz ZSIgUHJpb3JpdHk9IjM5IiBTZW1pSGlkZGVuPSJ0cnVlIiBVbmhpZGVXaGVuVXNlZD0idHJ1ZSIg TmFtZT0idG9jIDciLz4NCjx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBQcmlvcml0eT0i MzkiIFNlbWlIaWRkZW49InRydWUiIFVuaGlkZVdoZW5Vc2VkPSJ0cnVlIiBOYW1lPSJ0b2MgOCIv Pg0KPHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFByaW9yaXR5PSIzOSIgU2VtaUhpZGRl bj0idHJ1ZSIgVW5oaWRlV2hlblVzZWQ9InRydWUiIE5hbWU9InRvYyA5Ii8+DQo8dzpMc2RFeGNl cHRpb24gTG9ja2VkPSJmYWxzZSIgU2VtaUhpZGRlbj0idHJ1ZSIgVW5oaWRlV2hlblVzZWQ9InRy dWUiIE5hbWU9Ik5vcm1hbCBJbmRlbnQiLz4NCjx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNl IiBTZW1pSGlkZGVuPSJ0cnVlIiBVbmhpZGVXaGVuVXNlZD0idHJ1ZSIgTmFtZT0iZm9vdG5vdGUg dGV4dCIvPg0KPHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFNlbWlIaWRkZW49InRydWUi IFVuaGlkZVdoZW5Vc2VkPSJ0cnVlIiBOYW1lPSJhbm5vdGF0aW9uIHRleHQiLz4NCjx3OkxzZEV4 Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBTZW1pSGlkZGVuPSJ0cnVlIiBVbmhpZGVXaGVuVXNlZD0i dHJ1ZSIgTmFtZT0iaGVhZGVyIi8+DQo8dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJmYWxzZSIgU2Vt aUhpZGRlbj0idHJ1ZSIgVW5oaWRlV2hlblVzZWQ9InRydWUiIE5hbWU9ImZvb3RlciIvPg0KPHc6 THNkRXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFNlbWlIaWRkZW49InRydWUiIFVuaGlkZVdoZW5V c2VkPSJ0cnVlIiBOYW1lPSJpbmRleCBoZWFkaW5nIi8+DQo8dzpMc2RFeGNlcHRpb24gTG9ja2Vk PSJmYWxzZSIgUHJpb3JpdHk9IjM1IiBTZW1pSGlkZGVuPSJ0cnVlIiBVbmhpZGVXaGVuVXNlZD0i dHJ1ZSIgUUZvcm1hdD0idHJ1ZSIgTmFtZT0iY2FwdGlvbiIvPg0KPHc6THNkRXhjZXB0aW9uIExv Y2tlZD0iZmFsc2UiIFNlbWlIaWRkZW49InRydWUiIFVuaGlkZVdoZW5Vc2VkPSJ0cnVlIiBOYW1l PSJ0YWJsZSBvZiBmaWd1cmVzIi8+DQo8dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJmYWxzZSIgU2Vt aUhpZGRlbj0idHJ1ZSIgVW5oaWRlV2hlblVzZWQ9InRydWUiIE5hbWU9ImVudmVsb3BlIGFkZHJl c3MiLz4NCjx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBTZW1pSGlkZGVuPSJ0cnVlIiBV bmhpZGVXaGVuVXNlZD0idHJ1ZSIgTmFtZT0iZW52ZWxvcGUgcmV0dXJuIi8+DQo8dzpMc2RFeGNl cHRpb24gTG9ja2VkPSJmYWxzZSIgU2VtaUhpZGRlbj0idHJ1ZSIgVW5oaWRlV2hlblVzZWQ9InRy dWUiIE5hbWU9ImZvb3Rub3RlIHJlZmVyZW5jZSIvPg0KPHc6THNkRXhjZXB0aW9uIExvY2tlZD0i ZmFsc2UiIFNlbWlIaWRkZW49InRydWUiIFVuaGlkZVdoZW5Vc2VkPSJ0cnVlIiBOYW1lPSJhbm5v dGF0aW9uIHJlZmVyZW5jZSIvPg0KPHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFNlbWlI aWRkZW49InRydWUiIFVuaGlkZVdoZW5Vc2VkPSJ0cnVlIiBOYW1lPSJsaW5lIG51bWJlciIvPg0K PHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFNlbWlIaWRkZW49InRydWUiIFVuaGlkZVdo ZW5Vc2VkPSJ0cnVlIiBOYW1lPSJwYWdlIG51bWJlciIvPg0KPHc6THNkRXhjZXB0aW9uIExvY2tl ZD0iZmFsc2UiIFNlbWlIaWRkZW49InRydWUiIFVuaGlkZVdoZW5Vc2VkPSJ0cnVlIiBOYW1lPSJl bmRub3RlIHJlZmVyZW5jZSIvPg0KPHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFNlbWlI aWRkZW49InRydWUiIFVuaGlkZVdoZW5Vc2VkPSJ0cnVlIiBOYW1lPSJlbmRub3RlIHRleHQiLz4N Cjx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBTZW1pSGlkZGVuPSJ0cnVlIiBVbmhpZGVX aGVuVXNlZD0idHJ1ZSIgTmFtZT0idGFibGUgb2YgYXV0aG9yaXRpZXMiLz4NCjx3OkxzZEV4Y2Vw dGlvbiBMb2NrZWQ9ImZhbHNlIiBTZW1pSGlkZGVuPSJ0cnVlIiBVbmhpZGVXaGVuVXNlZD0idHJ1 ZSIgTmFtZT0ibWFjcm8iLz4NCjx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBTZW1pSGlk ZGVuPSJ0cnVlIiBVbmhpZGVXaGVuVXNlZD0idHJ1ZSIgTmFtZT0idG9hIGhlYWRpbmciLz4NCjx3 OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBTZW1pSGlkZGVuPSJ0cnVlIiBVbmhpZGVXaGVu VXNlZD0idHJ1ZSIgTmFtZT0iTGlzdCIvPg0KPHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFsc2Ui IFNlbWlIaWRkZW49InRydWUiIFVuaGlkZVdoZW5Vc2VkPSJ0cnVlIiBOYW1lPSJMaXN0IEJ1bGxl dCIvPg0KPHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFNlbWlIaWRkZW49InRydWUiIFVu aGlkZVdoZW5Vc2VkPSJ0cnVlIiBOYW1lPSJMaXN0IE51bWJlciIvPg0KPHc6THNkRXhjZXB0aW9u IExvY2tlZD0iZmFsc2UiIFNlbWlIaWRkZW49InRydWUiIFVuaGlkZVdoZW5Vc2VkPSJ0cnVlIiBO YW1lPSJMaXN0IDIiLz4NCjx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBTZW1pSGlkZGVu PSJ0cnVlIiBVbmhpZGVXaGVuVXNlZD0idHJ1ZSIgTmFtZT0iTGlzdCAzIi8+DQo8dzpMc2RFeGNl cHRpb24gTG9ja2VkPSJmYWxzZSIgU2VtaUhpZGRlbj0idHJ1ZSIgVW5oaWRlV2hlblVzZWQ9InRy dWUiIE5hbWU9Ikxpc3QgNCIvPg0KPHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFNlbWlI aWRkZW49InRydWUiIFVuaGlkZVdoZW5Vc2VkPSJ0cnVlIiBOYW1lPSJMaXN0IDUiLz4NCjx3Okxz ZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBTZW1pSGlkZGVuPSJ0cnVlIiBVbmhpZGVXaGVuVXNl ZD0idHJ1ZSIgTmFtZT0iTGlzdCBCdWxsZXQgMiIvPg0KPHc6THNkRXhjZXB0aW9uIExvY2tlZD0i ZmFsc2UiIFNlbWlIaWRkZW49InRydWUiIFVuaGlkZVdoZW5Vc2VkPSJ0cnVlIiBOYW1lPSJMaXN0 IEJ1bGxldCAzIi8+DQo8dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJmYWxzZSIgU2VtaUhpZGRlbj0i dHJ1ZSIgVW5oaWRlV2hlblVzZWQ9InRydWUiIE5hbWU9Ikxpc3QgQnVsbGV0IDQiLz4NCjx3Okxz ZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBTZW1pSGlkZGVuPSJ0cnVlIiBVbmhpZGVXaGVuVXNl ZD0idHJ1ZSIgTmFtZT0iTGlzdCBCdWxsZXQgNSIvPg0KPHc6THNkRXhjZXB0aW9uIExvY2tlZD0i ZmFsc2UiIFNlbWlIaWRkZW49InRydWUiIFVuaGlkZVdoZW5Vc2VkPSJ0cnVlIiBOYW1lPSJMaXN0 IE51bWJlciAyIi8+DQo8dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJmYWxzZSIgU2VtaUhpZGRlbj0i dHJ1ZSIgVW5oaWRlV2hlblVzZWQ9InRydWUiIE5hbWU9Ikxpc3QgTnVtYmVyIDMiLz4NCjx3Okxz ZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBTZW1pSGlkZGVuPSJ0cnVlIiBVbmhpZGVXaGVuVXNl ZD0idHJ1ZSIgTmFtZT0iTGlzdCBOdW1iZXIgNCIvPg0KPHc6THNkRXhjZXB0aW9uIExvY2tlZD0i ZmFsc2UiIFNlbWlIaWRkZW49InRydWUiIFVuaGlkZVdoZW5Vc2VkPSJ0cnVlIiBOYW1lPSJMaXN0 IE51bWJlciA1Ii8+DQo8dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJmYWxzZSIgUHJpb3JpdHk9IjEw IiBRRm9ybWF0PSJ0cnVlIiBOYW1lPSJUaXRsZSIvPg0KPHc6THNkRXhjZXB0aW9uIExvY2tlZD0i ZmFsc2UiIFNlbWlIaWRkZW49InRydWUiIFVuaGlkZVdoZW5Vc2VkPSJ0cnVlIiBOYW1lPSJDbG9z aW5nIi8+DQo8dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJmYWxzZSIgU2VtaUhpZGRlbj0idHJ1ZSIg VW5oaWRlV2hlblVzZWQ9InRydWUiIE5hbWU9IlNpZ25hdHVyZSIvPg0KPHc6THNkRXhjZXB0aW9u IExvY2tlZD0iZmFsc2UiIFByaW9yaXR5PSIxIiBTZW1pSGlkZGVuPSJ0cnVlIiBVbmhpZGVXaGVu VXNlZD0idHJ1ZSIgTmFtZT0iRGVmYXVsdCBQYXJhZ3JhcGggRm9udCIvPg0KPHc6THNkRXhjZXB0 aW9uIExvY2tlZD0iZmFsc2UiIFNlbWlIaWRkZW49InRydWUiIFVuaGlkZVdoZW5Vc2VkPSJ0cnVl IiBOYW1lPSJCb2R5IFRleHQiLz4NCjx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBTZW1p SGlkZGVuPSJ0cnVlIiBVbmhpZGVXaGVuVXNlZD0idHJ1ZSIgTmFtZT0iQm9keSBUZXh0IEluZGVu dCIvPg0KPHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFNlbWlIaWRkZW49InRydWUiIFVu aGlkZVdoZW5Vc2VkPSJ0cnVlIiBOYW1lPSJMaXN0IENvbnRpbnVlIi8+DQo8dzpMc2RFeGNlcHRp b24gTG9ja2VkPSJmYWxzZSIgU2VtaUhpZGRlbj0idHJ1ZSIgVW5oaWRlV2hlblVzZWQ9InRydWUi IE5hbWU9Ikxpc3QgQ29udGludWUgMiIvPg0KPHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFsc2Ui IFNlbWlIaWRkZW49InRydWUiIFVuaGlkZVdoZW5Vc2VkPSJ0cnVlIiBOYW1lPSJMaXN0IENvbnRp bnVlIDMiLz4NCjx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBTZW1pSGlkZGVuPSJ0cnVl IiBVbmhpZGVXaGVuVXNlZD0idHJ1ZSIgTmFtZT0iTGlzdCBDb250aW51ZSA0Ii8+DQo8dzpMc2RF eGNlcHRpb24gTG9ja2VkPSJmYWxzZSIgU2VtaUhpZGRlbj0idHJ1ZSIgVW5oaWRlV2hlblVzZWQ9 InRydWUiIE5hbWU9Ikxpc3QgQ29udGludWUgNSIvPg0KPHc6THNkRXhjZXB0aW9uIExvY2tlZD0i ZmFsc2UiIFNlbWlIaWRkZW49InRydWUiIFVuaGlkZVdoZW5Vc2VkPSJ0cnVlIiBOYW1lPSJNZXNz YWdlIEhlYWRlciIvPg0KPHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFByaW9yaXR5PSIx MSIgUUZvcm1hdD0idHJ1ZSIgTmFtZT0iU3VidGl0bGUiLz4NCjx3OkxzZEV4Y2VwdGlvbiBMb2Nr ZWQ9ImZhbHNlIiBTZW1pSGlkZGVuPSJ0cnVlIiBVbmhpZGVXaGVuVXNlZD0idHJ1ZSIgTmFtZT0i U2FsdXRhdGlvbiIvPg0KPHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFNlbWlIaWRkZW49 InRydWUiIFVuaGlkZVdoZW5Vc2VkPSJ0cnVlIiBOYW1lPSJEYXRlIi8+DQo8dzpMc2RFeGNlcHRp b24gTG9ja2VkPSJmYWxzZSIgU2VtaUhpZGRlbj0idHJ1ZSIgVW5oaWRlV2hlblVzZWQ9InRydWUi IE5hbWU9IkJvZHkgVGV4dCBGaXJzdCBJbmRlbnQiLz4NCjx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9 ImZhbHNlIiBTZW1pSGlkZGVuPSJ0cnVlIiBVbmhpZGVXaGVuVXNlZD0idHJ1ZSIgTmFtZT0iQm9k eSBUZXh0IEZpcnN0IEluZGVudCAyIi8+DQo8dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJmYWxzZSIg U2VtaUhpZGRlbj0idHJ1ZSIgVW5oaWRlV2hlblVzZWQ9InRydWUiIE5hbWU9Ik5vdGUgSGVhZGlu ZyIvPg0KPHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFNlbWlIaWRkZW49InRydWUiIFVu aGlkZVdoZW5Vc2VkPSJ0cnVlIiBOYW1lPSJCb2R5IFRleHQgMiIvPg0KPHc6THNkRXhjZXB0aW9u IExvY2tlZD0iZmFsc2UiIFNlbWlIaWRkZW49InRydWUiIFVuaGlkZVdoZW5Vc2VkPSJ0cnVlIiBO YW1lPSJCb2R5IFRleHQgMyIvPg0KPHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFNlbWlI aWRkZW49InRydWUiIFVuaGlkZVdoZW5Vc2VkPSJ0cnVlIiBOYW1lPSJCb2R5IFRleHQgSW5kZW50 IDIiLz4NCjx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBTZW1pSGlkZGVuPSJ0cnVlIiBV bmhpZGVXaGVuVXNlZD0idHJ1ZSIgTmFtZT0iQm9keSBUZXh0IEluZGVudCAzIi8+DQo8dzpMc2RF eGNlcHRpb24gTG9ja2VkPSJmYWxzZSIgU2VtaUhpZGRlbj0idHJ1ZSIgVW5oaWRlV2hlblVzZWQ9 InRydWUiIE5hbWU9IkJsb2NrIFRleHQiLz4NCjx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNl IiBTZW1pSGlkZGVuPSJ0cnVlIiBVbmhpZGVXaGVuVXNlZD0idHJ1ZSIgTmFtZT0iSHlwZXJsaW5r Ii8+DQo8dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJmYWxzZSIgU2VtaUhpZGRlbj0idHJ1ZSIgVW5o aWRlV2hlblVzZWQ9InRydWUiIE5hbWU9IkZvbGxvd2VkSHlwZXJsaW5rIi8+DQo8dzpMc2RFeGNl cHRpb24gTG9ja2VkPSJmYWxzZSIgUHJpb3JpdHk9IjIyIiBRRm9ybWF0PSJ0cnVlIiBOYW1lPSJT dHJvbmciLz4NCjx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBQcmlvcml0eT0iMjAiIFFG b3JtYXQ9InRydWUiIE5hbWU9IkVtcGhhc2lzIi8+DQo8dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJm YWxzZSIgU2VtaUhpZGRlbj0idHJ1ZSIgVW5oaWRlV2hlblVzZWQ9InRydWUiIE5hbWU9IkRvY3Vt ZW50IE1hcCIvPg0KPHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFNlbWlIaWRkZW49InRy dWUiIFVuaGlkZVdoZW5Vc2VkPSJ0cnVlIiBOYW1lPSJQbGFpbiBUZXh0Ii8+DQo8dzpMc2RFeGNl cHRpb24gTG9ja2VkPSJmYWxzZSIgU2VtaUhpZGRlbj0idHJ1ZSIgVW5oaWRlV2hlblVzZWQ9InRy dWUiIE5hbWU9IkUtbWFpbCBTaWduYXR1cmUiLz4NCjx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZh bHNlIiBTZW1pSGlkZGVuPSJ0cnVlIiBVbmhpZGVXaGVuVXNlZD0idHJ1ZSIgTmFtZT0iSFRNTCBU b3Agb2YgRm9ybSIvPg0KPHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFNlbWlIaWRkZW49 InRydWUiIFVuaGlkZVdoZW5Vc2VkPSJ0cnVlIiBOYW1lPSJIVE1MIEJvdHRvbSBvZiBGb3JtIi8+ DQo8dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJmYWxzZSIgU2VtaUhpZGRlbj0idHJ1ZSIgVW5oaWRl V2hlblVzZWQ9InRydWUiIE5hbWU9Ik5vcm1hbCAoV2ViKSIvPg0KPHc6THNkRXhjZXB0aW9uIExv Y2tlZD0iZmFsc2UiIFNlbWlIaWRkZW49InRydWUiIFVuaGlkZVdoZW5Vc2VkPSJ0cnVlIiBOYW1l PSJIVE1MIEFjcm9ueW0iLz4NCjx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBTZW1pSGlk ZGVuPSJ0cnVlIiBVbmhpZGVXaGVuVXNlZD0idHJ1ZSIgTmFtZT0iSFRNTCBBZGRyZXNzIi8+DQo8 dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJmYWxzZSIgU2VtaUhpZGRlbj0idHJ1ZSIgVW5oaWRlV2hl blVzZWQ9InRydWUiIE5hbWU9IkhUTUwgQ2l0ZSIvPg0KPHc6THNkRXhjZXB0aW9uIExvY2tlZD0i ZmFsc2UiIFNlbWlIaWRkZW49InRydWUiIFVuaGlkZVdoZW5Vc2VkPSJ0cnVlIiBOYW1lPSJIVE1M IENvZGUiLz4NCjx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBTZW1pSGlkZGVuPSJ0cnVl IiBVbmhpZGVXaGVuVXNlZD0idHJ1ZSIgTmFtZT0iSFRNTCBEZWZpbml0aW9uIi8+DQo8dzpMc2RF eGNlcHRpb24gTG9ja2VkPSJmYWxzZSIgU2VtaUhpZGRlbj0idHJ1ZSIgVW5oaWRlV2hlblVzZWQ9 InRydWUiIE5hbWU9IkhUTUwgS2V5Ym9hcmQiLz4NCjx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZh bHNlIiBTZW1pSGlkZGVuPSJ0cnVlIiBVbmhpZGVXaGVuVXNlZD0idHJ1ZSIgTmFtZT0iSFRNTCBQ cmVmb3JtYXR0ZWQiLz4NCjx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBTZW1pSGlkZGVu PSJ0cnVlIiBVbmhpZGVXaGVuVXNlZD0idHJ1ZSIgTmFtZT0iSFRNTCBTYW1wbGUiLz4NCjx3Okxz ZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBTZW1pSGlkZGVuPSJ0cnVlIiBVbmhpZGVXaGVuVXNl ZD0idHJ1ZSIgTmFtZT0iSFRNTCBUeXBld3JpdGVyIi8+DQo8dzpMc2RFeGNlcHRpb24gTG9ja2Vk PSJmYWxzZSIgU2VtaUhpZGRlbj0idHJ1ZSIgVW5oaWRlV2hlblVzZWQ9InRydWUiIE5hbWU9IkhU TUwgVmFyaWFibGUiLz4NCjx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBTZW1pSGlkZGVu PSJ0cnVlIiBVbmhpZGVXaGVuVXNlZD0idHJ1ZSIgTmFtZT0iTm9ybWFsIFRhYmxlIi8+DQo8dzpM c2RFeGNlcHRpb24gTG9ja2VkPSJmYWxzZSIgU2VtaUhpZGRlbj0idHJ1ZSIgVW5oaWRlV2hlblVz ZWQ9InRydWUiIE5hbWU9ImFubm90YXRpb24gc3ViamVjdCIvPg0KPHc6THNkRXhjZXB0aW9uIExv Y2tlZD0iZmFsc2UiIFNlbWlIaWRkZW49InRydWUiIFVuaGlkZVdoZW5Vc2VkPSJ0cnVlIiBOYW1l PSJObyBMaXN0Ii8+DQo8dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJmYWxzZSIgU2VtaUhpZGRlbj0i dHJ1ZSIgVW5oaWRlV2hlblVzZWQ9InRydWUiIE5hbWU9Ik91dGxpbmUgTGlzdCAxIi8+DQo8dzpM c2RFeGNlcHRpb24gTG9ja2VkPSJmYWxzZSIgU2VtaUhpZGRlbj0idHJ1ZSIgVW5oaWRlV2hlblVz ZWQ9InRydWUiIE5hbWU9Ik91dGxpbmUgTGlzdCAyIi8+DQo8dzpMc2RFeGNlcHRpb24gTG9ja2Vk PSJmYWxzZSIgU2VtaUhpZGRlbj0idHJ1ZSIgVW5oaWRlV2hlblVzZWQ9InRydWUiIE5hbWU9Ik91 dGxpbmUgTGlzdCAzIi8+DQo8dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJmYWxzZSIgU2VtaUhpZGRl bj0idHJ1ZSIgVW5oaWRlV2hlblVzZWQ9InRydWUiIE5hbWU9IlRhYmxlIFNpbXBsZSAxIi8+DQo8 dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJmYWxzZSIgU2VtaUhpZGRlbj0idHJ1ZSIgVW5oaWRlV2hl blVzZWQ9InRydWUiIE5hbWU9IlRhYmxlIFNpbXBsZSAyIi8+DQo8dzpMc2RFeGNlcHRpb24gTG9j a2VkPSJmYWxzZSIgU2VtaUhpZGRlbj0idHJ1ZSIgVW5oaWRlV2hlblVzZWQ9InRydWUiIE5hbWU9 IlRhYmxlIFNpbXBsZSAzIi8+DQo8dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJmYWxzZSIgU2VtaUhp ZGRlbj0idHJ1ZSIgVW5oaWRlV2hlblVzZWQ9InRydWUiIE5hbWU9IlRhYmxlIENsYXNzaWMgMSIv Pg0KPHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFNlbWlIaWRkZW49InRydWUiIFVuaGlk ZVdoZW5Vc2VkPSJ0cnVlIiBOYW1lPSJUYWJsZSBDbGFzc2ljIDIiLz4NCjx3OkxzZEV4Y2VwdGlv biBMb2NrZWQ9ImZhbHNlIiBTZW1pSGlkZGVuPSJ0cnVlIiBVbmhpZGVXaGVuVXNlZD0idHJ1ZSIg TmFtZT0iVGFibGUgQ2xhc3NpYyAzIi8+DQo8dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJmYWxzZSIg U2VtaUhpZGRlbj0idHJ1ZSIgVW5oaWRlV2hlblVzZWQ9InRydWUiIE5hbWU9IlRhYmxlIENsYXNz aWMgNCIvPg0KPHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFNlbWlIaWRkZW49InRydWUi IFVuaGlkZVdoZW5Vc2VkPSJ0cnVlIiBOYW1lPSJUYWJsZSBDb2xvcmZ1bCAxIi8+DQo8dzpMc2RF eGNlcHRpb24gTG9ja2VkPSJmYWxzZSIgU2VtaUhpZGRlbj0idHJ1ZSIgVW5oaWRlV2hlblVzZWQ9 InRydWUiIE5hbWU9IlRhYmxlIENvbG9yZnVsIDIiLz4NCjx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9 ImZhbHNlIiBTZW1pSGlkZGVuPSJ0cnVlIiBVbmhpZGVXaGVuVXNlZD0idHJ1ZSIgTmFtZT0iVGFi bGUgQ29sb3JmdWwgMyIvPg0KPHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFNlbWlIaWRk ZW49InRydWUiIFVuaGlkZVdoZW5Vc2VkPSJ0cnVlIiBOYW1lPSJUYWJsZSBDb2x1bW5zIDEiLz4N Cjx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBTZW1pSGlkZGVuPSJ0cnVlIiBVbmhpZGVX aGVuVXNlZD0idHJ1ZSIgTmFtZT0iVGFibGUgQ29sdW1ucyAyIi8+DQo8dzpMc2RFeGNlcHRpb24g TG9ja2VkPSJmYWxzZSIgU2VtaUhpZGRlbj0idHJ1ZSIgVW5oaWRlV2hlblVzZWQ9InRydWUiIE5h bWU9IlRhYmxlIENvbHVtbnMgMyIvPg0KPHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFNl bWlIaWRkZW49InRydWUiIFVuaGlkZVdoZW5Vc2VkPSJ0cnVlIiBOYW1lPSJUYWJsZSBDb2x1bW5z IDQiLz4NCjx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBTZW1pSGlkZGVuPSJ0cnVlIiBV bmhpZGVXaGVuVXNlZD0idHJ1ZSIgTmFtZT0iVGFibGUgQ29sdW1ucyA1Ii8+DQo8dzpMc2RFeGNl cHRpb24gTG9ja2VkPSJmYWxzZSIgU2VtaUhpZGRlbj0idHJ1ZSIgVW5oaWRlV2hlblVzZWQ9InRy dWUiIE5hbWU9IlRhYmxlIEdyaWQgMSIvPg0KPHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFsc2Ui IFNlbWlIaWRkZW49InRydWUiIFVuaGlkZVdoZW5Vc2VkPSJ0cnVlIiBOYW1lPSJUYWJsZSBHcmlk IDIiLz4NCjx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBTZW1pSGlkZGVuPSJ0cnVlIiBV bmhpZGVXaGVuVXNlZD0idHJ1ZSIgTmFtZT0iVGFibGUgR3JpZCAzIi8+DQo8dzpMc2RFeGNlcHRp b24gTG9ja2VkPSJmYWxzZSIgU2VtaUhpZGRlbj0idHJ1ZSIgVW5oaWRlV2hlblVzZWQ9InRydWUi IE5hbWU9IlRhYmxlIEdyaWQgNCIvPg0KPHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFNl bWlIaWRkZW49InRydWUiIFVuaGlkZVdoZW5Vc2VkPSJ0cnVlIiBOYW1lPSJUYWJsZSBHcmlkIDUi Lz4NCjx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBTZW1pSGlkZGVuPSJ0cnVlIiBVbmhp ZGVXaGVuVXNlZD0idHJ1ZSIgTmFtZT0iVGFibGUgR3JpZCA2Ii8+DQo8dzpMc2RFeGNlcHRpb24g TG9ja2VkPSJmYWxzZSIgU2VtaUhpZGRlbj0idHJ1ZSIgVW5oaWRlV2hlblVzZWQ9InRydWUiIE5h bWU9IlRhYmxlIEdyaWQgNyIvPg0KPHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFNlbWlI aWRkZW49InRydWUiIFVuaGlkZVdoZW5Vc2VkPSJ0cnVlIiBOYW1lPSJUYWJsZSBHcmlkIDgiLz4N Cjx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBTZW1pSGlkZGVuPSJ0cnVlIiBVbmhpZGVX aGVuVXNlZD0idHJ1ZSIgTmFtZT0iVGFibGUgTGlzdCAxIi8+DQo8dzpMc2RFeGNlcHRpb24gTG9j a2VkPSJmYWxzZSIgU2VtaUhpZGRlbj0idHJ1ZSIgVW5oaWRlV2hlblVzZWQ9InRydWUiIE5hbWU9 IlRhYmxlIExpc3QgMiIvPg0KPHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFNlbWlIaWRk ZW49InRydWUiIFVuaGlkZVdoZW5Vc2VkPSJ0cnVlIiBOYW1lPSJUYWJsZSBMaXN0IDMiLz4NCjx3 OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBTZW1pSGlkZGVuPSJ0cnVlIiBVbmhpZGVXaGVu VXNlZD0idHJ1ZSIgTmFtZT0iVGFibGUgTGlzdCA0Ii8+DQo8dzpMc2RFeGNlcHRpb24gTG9ja2Vk PSJmYWxzZSIgU2VtaUhpZGRlbj0idHJ1ZSIgVW5oaWRlV2hlblVzZWQ9InRydWUiIE5hbWU9IlRh YmxlIExpc3QgNSIvPg0KPHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFNlbWlIaWRkZW49 InRydWUiIFVuaGlkZVdoZW5Vc2VkPSJ0cnVlIiBOYW1lPSJUYWJsZSBMaXN0IDYiLz4NCjx3Okxz ZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBTZW1pSGlkZGVuPSJ0cnVlIiBVbmhpZGVXaGVuVXNl ZD0idHJ1ZSIgTmFtZT0iVGFibGUgTGlzdCA3Ii8+DQo8dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJm YWxzZSIgU2VtaUhpZGRlbj0idHJ1ZSIgVW5oaWRlV2hlblVzZWQ9InRydWUiIE5hbWU9IlRhYmxl IExpc3QgOCIvPg0KPHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFNlbWlIaWRkZW49InRy dWUiIFVuaGlkZVdoZW5Vc2VkPSJ0cnVlIiBOYW1lPSJUYWJsZSAzRCBlZmZlY3RzIDEiLz4NCjx3 OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBTZW1pSGlkZGVuPSJ0cnVlIiBVbmhpZGVXaGVu VXNlZD0idHJ1ZSIgTmFtZT0iVGFibGUgM0QgZWZmZWN0cyAyIi8+DQo8dzpMc2RFeGNlcHRpb24g TG9ja2VkPSJmYWxzZSIgU2VtaUhpZGRlbj0idHJ1ZSIgVW5oaWRlV2hlblVzZWQ9InRydWUiIE5h bWU9IlRhYmxlIDNEIGVmZmVjdHMgMyIvPg0KPHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFsc2Ui IFNlbWlIaWRkZW49InRydWUiIFVuaGlkZVdoZW5Vc2VkPSJ0cnVlIiBOYW1lPSJUYWJsZSBDb250 ZW1wb3JhcnkiLz4NCjx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBTZW1pSGlkZGVuPSJ0 cnVlIiBVbmhpZGVXaGVuVXNlZD0idHJ1ZSIgTmFtZT0iVGFibGUgRWxlZ2FudCIvPg0KPHc6THNk RXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFNlbWlIaWRkZW49InRydWUiIFVuaGlkZVdoZW5Vc2Vk PSJ0cnVlIiBOYW1lPSJUYWJsZSBQcm9mZXNzaW9uYWwiLz4NCjx3OkxzZEV4Y2VwdGlvbiBMb2Nr ZWQ9ImZhbHNlIiBTZW1pSGlkZGVuPSJ0cnVlIiBVbmhpZGVXaGVuVXNlZD0idHJ1ZSIgTmFtZT0i VGFibGUgU3VidGxlIDEiLz4NCjx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBTZW1pSGlk ZGVuPSJ0cnVlIiBVbmhpZGVXaGVuVXNlZD0idHJ1ZSIgTmFtZT0iVGFibGUgU3VidGxlIDIiLz4N Cjx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBTZW1pSGlkZGVuPSJ0cnVlIiBVbmhpZGVX aGVuVXNlZD0idHJ1ZSIgTmFtZT0iVGFibGUgV2ViIDEiLz4NCjx3OkxzZEV4Y2VwdGlvbiBMb2Nr ZWQ9ImZhbHNlIiBTZW1pSGlkZGVuPSJ0cnVlIiBVbmhpZGVXaGVuVXNlZD0idHJ1ZSIgTmFtZT0i VGFibGUgV2ViIDIiLz4NCjx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBTZW1pSGlkZGVu PSJ0cnVlIiBVbmhpZGVXaGVuVXNlZD0idHJ1ZSIgTmFtZT0iVGFibGUgV2ViIDMiLz4NCjx3Okxz ZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBTZW1pSGlkZGVuPSJ0cnVlIiBVbmhpZGVXaGVuVXNl ZD0idHJ1ZSIgTmFtZT0iQmFsbG9vbiBUZXh0Ii8+DQo8dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJm YWxzZSIgUHJpb3JpdHk9IjU5IiBOYW1lPSJUYWJsZSBHcmlkIi8+DQo8dzpMc2RFeGNlcHRpb24g TG9ja2VkPSJmYWxzZSIgU2VtaUhpZGRlbj0idHJ1ZSIgVW5oaWRlV2hlblVzZWQ9InRydWUiIE5h bWU9IlRhYmxlIFRoZW1lIi8+DQo8dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJmYWxzZSIgU2VtaUhp ZGRlbj0idHJ1ZSIgTmFtZT0iUGxhY2Vob2xkZXIgVGV4dCIvPg0KPHc6THNkRXhjZXB0aW9uIExv Y2tlZD0iZmFsc2UiIFByaW9yaXR5PSIxIiBRRm9ybWF0PSJ0cnVlIiBOYW1lPSJObyBTcGFjaW5n Ii8+DQo8dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJmYWxzZSIgUHJpb3JpdHk9IjYwIiBOYW1lPSJM aWdodCBTaGFkaW5nIi8+DQo8dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJmYWxzZSIgUHJpb3JpdHk9 IjYxIiBOYW1lPSJMaWdodCBMaXN0Ii8+DQo8dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJmYWxzZSIg UHJpb3JpdHk9IjYyIiBOYW1lPSJMaWdodCBHcmlkIi8+DQo8dzpMc2RFeGNlcHRpb24gTG9ja2Vk PSJmYWxzZSIgUHJpb3JpdHk9IjYzIiBOYW1lPSJNZWRpdW0gU2hhZGluZyAxIi8+DQo8dzpMc2RF eGNlcHRpb24gTG9ja2VkPSJmYWxzZSIgUHJpb3JpdHk9IjY0IiBOYW1lPSJNZWRpdW0gU2hhZGlu ZyAyIi8+DQo8dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJmYWxzZSIgUHJpb3JpdHk9IjY1IiBOYW1l PSJNZWRpdW0gTGlzdCAxIi8+DQo8dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJmYWxzZSIgUHJpb3Jp dHk9IjY2IiBOYW1lPSJNZWRpdW0gTGlzdCAyIi8+DQo8dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJm YWxzZSIgUHJpb3JpdHk9IjY3IiBOYW1lPSJNZWRpdW0gR3JpZCAxIi8+DQo8dzpMc2RFeGNlcHRp b24gTG9ja2VkPSJmYWxzZSIgUHJpb3JpdHk9IjY4IiBOYW1lPSJNZWRpdW0gR3JpZCAyIi8+DQo8 dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJmYWxzZSIgUHJpb3JpdHk9IjY5IiBOYW1lPSJNZWRpdW0g R3JpZCAzIi8+DQo8dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJmYWxzZSIgUHJpb3JpdHk9IjcwIiBO YW1lPSJEYXJrIExpc3QiLz4NCjx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBQcmlvcml0 eT0iNzEiIE5hbWU9IkNvbG9yZnVsIFNoYWRpbmciLz4NCjx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9 ImZhbHNlIiBQcmlvcml0eT0iNzIiIE5hbWU9IkNvbG9yZnVsIExpc3QiLz4NCjx3OkxzZEV4Y2Vw dGlvbiBMb2NrZWQ9ImZhbHNlIiBQcmlvcml0eT0iNzMiIE5hbWU9IkNvbG9yZnVsIEdyaWQiLz4N Cjx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBQcmlvcml0eT0iNjAiIE5hbWU9IkxpZ2h0 IFNoYWRpbmcgQWNjZW50IDEiLz4NCjx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBQcmlv cml0eT0iNjEiIE5hbWU9IkxpZ2h0IExpc3QgQWNjZW50IDEiLz4NCjx3OkxzZEV4Y2VwdGlvbiBM b2NrZWQ9ImZhbHNlIiBQcmlvcml0eT0iNjIiIE5hbWU9IkxpZ2h0IEdyaWQgQWNjZW50IDEiLz4N Cjx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBQcmlvcml0eT0iNjMiIE5hbWU9Ik1lZGl1 bSBTaGFkaW5nIDEgQWNjZW50IDEiLz4NCjx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBQ cmlvcml0eT0iNjQiIE5hbWU9Ik1lZGl1bSBTaGFkaW5nIDIgQWNjZW50IDEiLz4NCjx3OkxzZEV4 Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBQcmlvcml0eT0iNjUiIE5hbWU9Ik1lZGl1bSBMaXN0IDEg QWNjZW50IDEiLz4NCjx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBTZW1pSGlkZGVuPSJ0 cnVlIiBOYW1lPSJSZXZpc2lvbiIvPg0KPHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFBy aW9yaXR5PSIzNCIgUUZvcm1hdD0idHJ1ZSIgTmFtZT0iTGlzdCBQYXJhZ3JhcGgiLz4NCjx3Okxz ZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBQcmlvcml0eT0iMjkiIFFGb3JtYXQ9InRydWUiIE5h bWU9IlF1b3RlIi8+DQo8dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJmYWxzZSIgUHJpb3JpdHk9IjMw IiBRRm9ybWF0PSJ0cnVlIiBOYW1lPSJJbnRlbnNlIFF1b3RlIi8+DQo8dzpMc2RFeGNlcHRpb24g TG9ja2VkPSJmYWxzZSIgUHJpb3JpdHk9IjY2IiBOYW1lPSJNZWRpdW0gTGlzdCAyIEFjY2VudCAx Ii8+DQo8dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJmYWxzZSIgUHJpb3JpdHk9IjY3IiBOYW1lPSJN ZWRpdW0gR3JpZCAxIEFjY2VudCAxIi8+DQo8dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJmYWxzZSIg UHJpb3JpdHk9IjY4IiBOYW1lPSJNZWRpdW0gR3JpZCAyIEFjY2VudCAxIi8+DQo8dzpMc2RFeGNl cHRpb24gTG9ja2VkPSJmYWxzZSIgUHJpb3JpdHk9IjY5IiBOYW1lPSJNZWRpdW0gR3JpZCAzIEFj Y2VudCAxIi8+DQo8dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJmYWxzZSIgUHJpb3JpdHk9IjcwIiBO YW1lPSJEYXJrIExpc3QgQWNjZW50IDEiLz4NCjx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNl IiBQcmlvcml0eT0iNzEiIE5hbWU9IkNvbG9yZnVsIFNoYWRpbmcgQWNjZW50IDEiLz4NCjx3Okxz ZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBQcmlvcml0eT0iNzIiIE5hbWU9IkNvbG9yZnVsIExp c3QgQWNjZW50IDEiLz4NCjx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBQcmlvcml0eT0i NzMiIE5hbWU9IkNvbG9yZnVsIEdyaWQgQWNjZW50IDEiLz4NCjx3OkxzZEV4Y2VwdGlvbiBMb2Nr ZWQ9ImZhbHNlIiBQcmlvcml0eT0iNjAiIE5hbWU9IkxpZ2h0IFNoYWRpbmcgQWNjZW50IDIiLz4N Cjx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBQcmlvcml0eT0iNjEiIE5hbWU9IkxpZ2h0 IExpc3QgQWNjZW50IDIiLz4NCjx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBQcmlvcml0 eT0iNjIiIE5hbWU9IkxpZ2h0IEdyaWQgQWNjZW50IDIiLz4NCjx3OkxzZEV4Y2VwdGlvbiBMb2Nr ZWQ9ImZhbHNlIiBQcmlvcml0eT0iNjMiIE5hbWU9Ik1lZGl1bSBTaGFkaW5nIDEgQWNjZW50IDIi Lz4NCjx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBQcmlvcml0eT0iNjQiIE5hbWU9Ik1l ZGl1bSBTaGFkaW5nIDIgQWNjZW50IDIiLz4NCjx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNl IiBQcmlvcml0eT0iNjUiIE5hbWU9Ik1lZGl1bSBMaXN0IDEgQWNjZW50IDIiLz4NCjx3OkxzZEV4 Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBQcmlvcml0eT0iNjYiIE5hbWU9Ik1lZGl1bSBMaXN0IDIg QWNjZW50IDIiLz4NCjx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBQcmlvcml0eT0iNjci IE5hbWU9Ik1lZGl1bSBHcmlkIDEgQWNjZW50IDIiLz4NCjx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9 ImZhbHNlIiBQcmlvcml0eT0iNjgiIE5hbWU9Ik1lZGl1bSBHcmlkIDIgQWNjZW50IDIiLz4NCjx3 OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBQcmlvcml0eT0iNjkiIE5hbWU9Ik1lZGl1bSBH cmlkIDMgQWNjZW50IDIiLz4NCjx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBQcmlvcml0 eT0iNzAiIE5hbWU9IkRhcmsgTGlzdCBBY2NlbnQgMiIvPg0KPHc6THNkRXhjZXB0aW9uIExvY2tl ZD0iZmFsc2UiIFByaW9yaXR5PSI3MSIgTmFtZT0iQ29sb3JmdWwgU2hhZGluZyBBY2NlbnQgMiIv Pg0KPHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFByaW9yaXR5PSI3MiIgTmFtZT0iQ29s b3JmdWwgTGlzdCBBY2NlbnQgMiIvPg0KPHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFBy aW9yaXR5PSI3MyIgTmFtZT0iQ29sb3JmdWwgR3JpZCBBY2NlbnQgMiIvPg0KPHc6THNkRXhjZXB0 aW9uIExvY2tlZD0iZmFsc2UiIFByaW9yaXR5PSI2MCIgTmFtZT0iTGlnaHQgU2hhZGluZyBBY2Nl bnQgMyIvPg0KPHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFByaW9yaXR5PSI2MSIgTmFt ZT0iTGlnaHQgTGlzdCBBY2NlbnQgMyIvPg0KPHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFsc2Ui IFByaW9yaXR5PSI2MiIgTmFtZT0iTGlnaHQgR3JpZCBBY2NlbnQgMyIvPg0KPHc6THNkRXhjZXB0 aW9uIExvY2tlZD0iZmFsc2UiIFByaW9yaXR5PSI2MyIgTmFtZT0iTWVkaXVtIFNoYWRpbmcgMSBB Y2NlbnQgMyIvPg0KPHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFByaW9yaXR5PSI2NCIg TmFtZT0iTWVkaXVtIFNoYWRpbmcgMiBBY2NlbnQgMyIvPg0KPHc6THNkRXhjZXB0aW9uIExvY2tl ZD0iZmFsc2UiIFByaW9yaXR5PSI2NSIgTmFtZT0iTWVkaXVtIExpc3QgMSBBY2NlbnQgMyIvPg0K PHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFByaW9yaXR5PSI2NiIgTmFtZT0iTWVkaXVt IExpc3QgMiBBY2NlbnQgMyIvPg0KPHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFByaW9y aXR5PSI2NyIgTmFtZT0iTWVkaXVtIEdyaWQgMSBBY2NlbnQgMyIvPg0KPHc6THNkRXhjZXB0aW9u IExvY2tlZD0iZmFsc2UiIFByaW9yaXR5PSI2OCIgTmFtZT0iTWVkaXVtIEdyaWQgMiBBY2NlbnQg MyIvPg0KPHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFByaW9yaXR5PSI2OSIgTmFtZT0i TWVkaXVtIEdyaWQgMyBBY2NlbnQgMyIvPg0KPHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFsc2Ui IFByaW9yaXR5PSI3MCIgTmFtZT0iRGFyayBMaXN0IEFjY2VudCAzIi8+DQo8dzpMc2RFeGNlcHRp b24gTG9ja2VkPSJmYWxzZSIgUHJpb3JpdHk9IjcxIiBOYW1lPSJDb2xvcmZ1bCBTaGFkaW5nIEFj Y2VudCAzIi8+DQo8dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJmYWxzZSIgUHJpb3JpdHk9IjcyIiBO YW1lPSJDb2xvcmZ1bCBMaXN0IEFjY2VudCAzIi8+DQo8dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJm YWxzZSIgUHJpb3JpdHk9IjczIiBOYW1lPSJDb2xvcmZ1bCBHcmlkIEFjY2VudCAzIi8+DQo8dzpM c2RFeGNlcHRpb24gTG9ja2VkPSJmYWxzZSIgUHJpb3JpdHk9IjYwIiBOYW1lPSJMaWdodCBTaGFk aW5nIEFjY2VudCA0Ii8+DQo8dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJmYWxzZSIgUHJpb3JpdHk9 IjYxIiBOYW1lPSJMaWdodCBMaXN0IEFjY2VudCA0Ii8+DQo8dzpMc2RFeGNlcHRpb24gTG9ja2Vk PSJmYWxzZSIgUHJpb3JpdHk9IjYyIiBOYW1lPSJMaWdodCBHcmlkIEFjY2VudCA0Ii8+DQo8dzpM c2RFeGNlcHRpb24gTG9ja2VkPSJmYWxzZSIgUHJpb3JpdHk9IjYzIiBOYW1lPSJNZWRpdW0gU2hh ZGluZyAxIEFjY2VudCA0Ii8+DQo8dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJmYWxzZSIgUHJpb3Jp dHk9IjY0IiBOYW1lPSJNZWRpdW0gU2hhZGluZyAyIEFjY2VudCA0Ii8+DQo8dzpMc2RFeGNlcHRp b24gTG9ja2VkPSJmYWxzZSIgUHJpb3JpdHk9IjY1IiBOYW1lPSJNZWRpdW0gTGlzdCAxIEFjY2Vu dCA0Ii8+DQo8dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJmYWxzZSIgUHJpb3JpdHk9IjY2IiBOYW1l PSJNZWRpdW0gTGlzdCAyIEFjY2VudCA0Ii8+DQo8dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJmYWxz ZSIgUHJpb3JpdHk9IjY3IiBOYW1lPSJNZWRpdW0gR3JpZCAxIEFjY2VudCA0Ii8+DQo8dzpMc2RF eGNlcHRpb24gTG9ja2VkPSJmYWxzZSIgUHJpb3JpdHk9IjY4IiBOYW1lPSJNZWRpdW0gR3JpZCAy IEFjY2VudCA0Ii8+DQo8dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJmYWxzZSIgUHJpb3JpdHk9IjY5 IiBOYW1lPSJNZWRpdW0gR3JpZCAzIEFjY2VudCA0Ii8+DQo8dzpMc2RFeGNlcHRpb24gTG9ja2Vk PSJmYWxzZSIgUHJpb3JpdHk9IjcwIiBOYW1lPSJEYXJrIExpc3QgQWNjZW50IDQiLz4NCjx3Okxz ZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBQcmlvcml0eT0iNzEiIE5hbWU9IkNvbG9yZnVsIFNo YWRpbmcgQWNjZW50IDQiLz4NCjx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBQcmlvcml0 eT0iNzIiIE5hbWU9IkNvbG9yZnVsIExpc3QgQWNjZW50IDQiLz4NCjx3OkxzZEV4Y2VwdGlvbiBM b2NrZWQ9ImZhbHNlIiBQcmlvcml0eT0iNzMiIE5hbWU9IkNvbG9yZnVsIEdyaWQgQWNjZW50IDQi Lz4NCjx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBQcmlvcml0eT0iNjAiIE5hbWU9Ikxp Z2h0IFNoYWRpbmcgQWNjZW50IDUiLz4NCjx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBQ cmlvcml0eT0iNjEiIE5hbWU9IkxpZ2h0IExpc3QgQWNjZW50IDUiLz4NCjx3OkxzZEV4Y2VwdGlv biBMb2NrZWQ9ImZhbHNlIiBQcmlvcml0eT0iNjIiIE5hbWU9IkxpZ2h0IEdyaWQgQWNjZW50IDUi Lz4NCjx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBQcmlvcml0eT0iNjMiIE5hbWU9Ik1l ZGl1bSBTaGFkaW5nIDEgQWNjZW50IDUiLz4NCjx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNl IiBQcmlvcml0eT0iNjQiIE5hbWU9Ik1lZGl1bSBTaGFkaW5nIDIgQWNjZW50IDUiLz4NCjx3Okxz ZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBQcmlvcml0eT0iNjUiIE5hbWU9Ik1lZGl1bSBMaXN0 IDEgQWNjZW50IDUiLz4NCjx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBQcmlvcml0eT0i NjYiIE5hbWU9Ik1lZGl1bSBMaXN0IDIgQWNjZW50IDUiLz4NCjx3OkxzZEV4Y2VwdGlvbiBMb2Nr ZWQ9ImZhbHNlIiBQcmlvcml0eT0iNjciIE5hbWU9Ik1lZGl1bSBHcmlkIDEgQWNjZW50IDUiLz4N Cjx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBQcmlvcml0eT0iNjgiIE5hbWU9Ik1lZGl1 bSBHcmlkIDIgQWNjZW50IDUiLz4NCjx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBQcmlv cml0eT0iNjkiIE5hbWU9Ik1lZGl1bSBHcmlkIDMgQWNjZW50IDUiLz4NCjx3OkxzZEV4Y2VwdGlv biBMb2NrZWQ9ImZhbHNlIiBQcmlvcml0eT0iNzAiIE5hbWU9IkRhcmsgTGlzdCBBY2NlbnQgNSIv Pg0KPHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFByaW9yaXR5PSI3MSIgTmFtZT0iQ29s b3JmdWwgU2hhZGluZyBBY2NlbnQgNSIvPg0KPHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFsc2Ui IFByaW9yaXR5PSI3MiIgTmFtZT0iQ29sb3JmdWwgTGlzdCBBY2NlbnQgNSIvPg0KPHc6THNkRXhj ZXB0aW9uIExvY2tlZD0iZmFsc2UiIFByaW9yaXR5PSI3MyIgTmFtZT0iQ29sb3JmdWwgR3JpZCBB Y2NlbnQgNSIvPg0KPHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFByaW9yaXR5PSI2MCIg TmFtZT0iTGlnaHQgU2hhZGluZyBBY2NlbnQgNiIvPg0KPHc6THNkRXhjZXB0aW9uIExvY2tlZD0i ZmFsc2UiIFByaW9yaXR5PSI2MSIgTmFtZT0iTGlnaHQgTGlzdCBBY2NlbnQgNiIvPg0KPHc6THNk RXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFByaW9yaXR5PSI2MiIgTmFtZT0iTGlnaHQgR3JpZCBB Y2NlbnQgNiIvPg0KPHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFByaW9yaXR5PSI2MyIg TmFtZT0iTWVkaXVtIFNoYWRpbmcgMSBBY2NlbnQgNiIvPg0KPHc6THNkRXhjZXB0aW9uIExvY2tl ZD0iZmFsc2UiIFByaW9yaXR5PSI2NCIgTmFtZT0iTWVkaXVtIFNoYWRpbmcgMiBBY2NlbnQgNiIv Pg0KPHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFByaW9yaXR5PSI2NSIgTmFtZT0iTWVk aXVtIExpc3QgMSBBY2NlbnQgNiIvPg0KPHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFBy aW9yaXR5PSI2NiIgTmFtZT0iTWVkaXVtIExpc3QgMiBBY2NlbnQgNiIvPg0KPHc6THNkRXhjZXB0 aW9uIExvY2tlZD0iZmFsc2UiIFByaW9yaXR5PSI2NyIgTmFtZT0iTWVkaXVtIEdyaWQgMSBBY2Nl bnQgNiIvPg0KPHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFByaW9yaXR5PSI2OCIgTmFt ZT0iTWVkaXVtIEdyaWQgMiBBY2NlbnQgNiIvPg0KPHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFs c2UiIFByaW9yaXR5PSI2OSIgTmFtZT0iTWVkaXVtIEdyaWQgMyBBY2NlbnQgNiIvPg0KPHc6THNk RXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFByaW9yaXR5PSI3MCIgTmFtZT0iRGFyayBMaXN0IEFj Y2VudCA2Ii8+DQo8dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJmYWxzZSIgUHJpb3JpdHk9IjcxIiBO YW1lPSJDb2xvcmZ1bCBTaGFkaW5nIEFjY2VudCA2Ii8+DQo8dzpMc2RFeGNlcHRpb24gTG9ja2Vk PSJmYWxzZSIgUHJpb3JpdHk9IjcyIiBOYW1lPSJDb2xvcmZ1bCBMaXN0IEFjY2VudCA2Ii8+DQo8 dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJmYWxzZSIgUHJpb3JpdHk9IjczIiBOYW1lPSJDb2xvcmZ1 bCBHcmlkIEFjY2VudCA2Ii8+DQo8dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJmYWxzZSIgUHJpb3Jp dHk9IjE5IiBRRm9ybWF0PSJ0cnVlIiBOYW1lPSJTdWJ0bGUgRW1waGFzaXMiLz4NCjx3OkxzZEV4 Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBQcmlvcml0eT0iMjEiIFFGb3JtYXQ9InRydWUiIE5hbWU9 IkludGVuc2UgRW1waGFzaXMiLz4NCjx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBQcmlv cml0eT0iMzEiIFFGb3JtYXQ9InRydWUiIE5hbWU9IlN1YnRsZSBSZWZlcmVuY2UiLz4NCjx3Okxz ZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBQcmlvcml0eT0iMzIiIFFGb3JtYXQ9InRydWUiIE5h bWU9IkludGVuc2UgUmVmZXJlbmNlIi8+DQo8dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJmYWxzZSIg UHJpb3JpdHk9IjMzIiBRRm9ybWF0PSJ0cnVlIiBOYW1lPSJCb29rIFRpdGxlIi8+DQo8dzpMc2RF eGNlcHRpb24gTG9ja2VkPSJmYWxzZSIgUHJpb3JpdHk9IjM3IiBTZW1pSGlkZGVuPSJ0cnVlIiBV bmhpZGVXaGVuVXNlZD0idHJ1ZSIgTmFtZT0iQmlibGlvZ3JhcGh5Ii8+DQo8dzpMc2RFeGNlcHRp b24gTG9ja2VkPSJmYWxzZSIgUHJpb3JpdHk9IjM5IiBTZW1pSGlkZGVuPSJ0cnVlIiBVbmhpZGVX aGVuVXNlZD0idHJ1ZSIgUUZvcm1hdD0idHJ1ZSIgTmFtZT0iVE9DIEhlYWRpbmciLz4NCjx3Okxz ZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBQcmlvcml0eT0iNDEiIE5hbWU9IlBsYWluIFRhYmxl IDEiLz4NCjx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBQcmlvcml0eT0iNDIiIE5hbWU9 IlBsYWluIFRhYmxlIDIiLz4NCjx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBQcmlvcml0 eT0iNDMiIE5hbWU9IlBsYWluIFRhYmxlIDMiLz4NCjx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZh bHNlIiBQcmlvcml0eT0iNDQiIE5hbWU9IlBsYWluIFRhYmxlIDQiLz4NCjx3OkxzZEV4Y2VwdGlv biBMb2NrZWQ9ImZhbHNlIiBQcmlvcml0eT0iNDUiIE5hbWU9IlBsYWluIFRhYmxlIDUiLz4NCjx3 OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBQcmlvcml0eT0iNDAiIE5hbWU9IkdyaWQgVGFi bGUgTGlnaHQiLz4NCjx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBQcmlvcml0eT0iNDYi IE5hbWU9IkdyaWQgVGFibGUgMSBMaWdodCIvPg0KPHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFs c2UiIFByaW9yaXR5PSI0NyIgTmFtZT0iR3JpZCBUYWJsZSAyIi8+DQo8dzpMc2RFeGNlcHRpb24g TG9ja2VkPSJmYWxzZSIgUHJpb3JpdHk9IjQ4IiBOYW1lPSJHcmlkIFRhYmxlIDMiLz4NCjx3Okxz ZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBQcmlvcml0eT0iNDkiIE5hbWU9IkdyaWQgVGFibGUg NCIvPg0KPHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFByaW9yaXR5PSI1MCIgTmFtZT0i R3JpZCBUYWJsZSA1IERhcmsiLz4NCjx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBQcmlv cml0eT0iNTEiIE5hbWU9IkdyaWQgVGFibGUgNiBDb2xvcmZ1bCIvPg0KPHc6THNkRXhjZXB0aW9u IExvY2tlZD0iZmFsc2UiIFByaW9yaXR5PSI1MiIgTmFtZT0iR3JpZCBUYWJsZSA3IENvbG9yZnVs Ii8+DQo8dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJmYWxzZSIgUHJpb3JpdHk9IjQ2IiBOYW1lPSJH cmlkIFRhYmxlIDEgTGlnaHQgQWNjZW50IDEiLz4NCjx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZh bHNlIiBQcmlvcml0eT0iNDciIE5hbWU9IkdyaWQgVGFibGUgMiBBY2NlbnQgMSIvPg0KPHc6THNk RXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFByaW9yaXR5PSI0OCIgTmFtZT0iR3JpZCBUYWJsZSAz IEFjY2VudCAxIi8+DQo8dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJmYWxzZSIgUHJpb3JpdHk9IjQ5 IiBOYW1lPSJHcmlkIFRhYmxlIDQgQWNjZW50IDEiLz4NCjx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9 ImZhbHNlIiBQcmlvcml0eT0iNTAiIE5hbWU9IkdyaWQgVGFibGUgNSBEYXJrIEFjY2VudCAxIi8+ DQo8dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJmYWxzZSIgUHJpb3JpdHk9IjUxIiBOYW1lPSJHcmlk IFRhYmxlIDYgQ29sb3JmdWwgQWNjZW50IDEiLz4NCjx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZh bHNlIiBQcmlvcml0eT0iNTIiIE5hbWU9IkdyaWQgVGFibGUgNyBDb2xvcmZ1bCBBY2NlbnQgMSIv Pg0KPHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFByaW9yaXR5PSI0NiIgTmFtZT0iR3Jp ZCBUYWJsZSAxIExpZ2h0IEFjY2VudCAyIi8+DQo8dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJmYWxz ZSIgUHJpb3JpdHk9IjQ3IiBOYW1lPSJHcmlkIFRhYmxlIDIgQWNjZW50IDIiLz4NCjx3OkxzZEV4 Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBQcmlvcml0eT0iNDgiIE5hbWU9IkdyaWQgVGFibGUgMyBB Y2NlbnQgMiIvPg0KPHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFByaW9yaXR5PSI0OSIg TmFtZT0iR3JpZCBUYWJsZSA0IEFjY2VudCAyIi8+DQo8dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJm YWxzZSIgUHJpb3JpdHk9IjUwIiBOYW1lPSJHcmlkIFRhYmxlIDUgRGFyayBBY2NlbnQgMiIvPg0K PHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFByaW9yaXR5PSI1MSIgTmFtZT0iR3JpZCBU YWJsZSA2IENvbG9yZnVsIEFjY2VudCAyIi8+DQo8dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJmYWxz ZSIgUHJpb3JpdHk9IjUyIiBOYW1lPSJHcmlkIFRhYmxlIDcgQ29sb3JmdWwgQWNjZW50IDIiLz4N Cjx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBQcmlvcml0eT0iNDYiIE5hbWU9IkdyaWQg VGFibGUgMSBMaWdodCBBY2NlbnQgMyIvPg0KPHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFsc2Ui IFByaW9yaXR5PSI0NyIgTmFtZT0iR3JpZCBUYWJsZSAyIEFjY2VudCAzIi8+DQo8dzpMc2RFeGNl cHRpb24gTG9ja2VkPSJmYWxzZSIgUHJpb3JpdHk9IjQ4IiBOYW1lPSJHcmlkIFRhYmxlIDMgQWNj ZW50IDMiLz4NCjx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBQcmlvcml0eT0iNDkiIE5h bWU9IkdyaWQgVGFibGUgNCBBY2NlbnQgMyIvPg0KPHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFs c2UiIFByaW9yaXR5PSI1MCIgTmFtZT0iR3JpZCBUYWJsZSA1IERhcmsgQWNjZW50IDMiLz4NCjx3 OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBQcmlvcml0eT0iNTEiIE5hbWU9IkdyaWQgVGFi bGUgNiBDb2xvcmZ1bCBBY2NlbnQgMyIvPg0KPHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFsc2Ui IFByaW9yaXR5PSI1MiIgTmFtZT0iR3JpZCBUYWJsZSA3IENvbG9yZnVsIEFjY2VudCAzIi8+DQo8 dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJmYWxzZSIgUHJpb3JpdHk9IjQ2IiBOYW1lPSJHcmlkIFRh YmxlIDEgTGlnaHQgQWNjZW50IDQiLz4NCjx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBQ cmlvcml0eT0iNDciIE5hbWU9IkdyaWQgVGFibGUgMiBBY2NlbnQgNCIvPg0KPHc6THNkRXhjZXB0 aW9uIExvY2tlZD0iZmFsc2UiIFByaW9yaXR5PSI0OCIgTmFtZT0iR3JpZCBUYWJsZSAzIEFjY2Vu dCA0Ii8+DQo8dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJmYWxzZSIgUHJpb3JpdHk9IjQ5IiBOYW1l PSJHcmlkIFRhYmxlIDQgQWNjZW50IDQiLz4NCjx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNl IiBQcmlvcml0eT0iNTAiIE5hbWU9IkdyaWQgVGFibGUgNSBEYXJrIEFjY2VudCA0Ii8+DQo8dzpM c2RFeGNlcHRpb24gTG9ja2VkPSJmYWxzZSIgUHJpb3JpdHk9IjUxIiBOYW1lPSJHcmlkIFRhYmxl IDYgQ29sb3JmdWwgQWNjZW50IDQiLz4NCjx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBQ cmlvcml0eT0iNTIiIE5hbWU9IkdyaWQgVGFibGUgNyBDb2xvcmZ1bCBBY2NlbnQgNCIvPg0KPHc6 THNkRXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFByaW9yaXR5PSI0NiIgTmFtZT0iR3JpZCBUYWJs ZSAxIExpZ2h0IEFjY2VudCA1Ii8+DQo8dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJmYWxzZSIgUHJp b3JpdHk9IjQ3IiBOYW1lPSJHcmlkIFRhYmxlIDIgQWNjZW50IDUiLz4NCjx3OkxzZEV4Y2VwdGlv biBMb2NrZWQ9ImZhbHNlIiBQcmlvcml0eT0iNDgiIE5hbWU9IkdyaWQgVGFibGUgMyBBY2NlbnQg NSIvPg0KPHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFByaW9yaXR5PSI0OSIgTmFtZT0i R3JpZCBUYWJsZSA0IEFjY2VudCA1Ii8+DQo8dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJmYWxzZSIg UHJpb3JpdHk9IjUwIiBOYW1lPSJHcmlkIFRhYmxlIDUgRGFyayBBY2NlbnQgNSIvPg0KPHc6THNk RXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFByaW9yaXR5PSI1MSIgTmFtZT0iR3JpZCBUYWJsZSA2 IENvbG9yZnVsIEFjY2VudCA1Ii8+DQo8dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJmYWxzZSIgUHJp b3JpdHk9IjUyIiBOYW1lPSJHcmlkIFRhYmxlIDcgQ29sb3JmdWwgQWNjZW50IDUiLz4NCjx3Okxz ZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBQcmlvcml0eT0iNDYiIE5hbWU9IkdyaWQgVGFibGUg MSBMaWdodCBBY2NlbnQgNiIvPg0KPHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFByaW9y aXR5PSI0NyIgTmFtZT0iR3JpZCBUYWJsZSAyIEFjY2VudCA2Ii8+DQo8dzpMc2RFeGNlcHRpb24g TG9ja2VkPSJmYWxzZSIgUHJpb3JpdHk9IjQ4IiBOYW1lPSJHcmlkIFRhYmxlIDMgQWNjZW50IDYi Lz4NCjx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBQcmlvcml0eT0iNDkiIE5hbWU9Ikdy aWQgVGFibGUgNCBBY2NlbnQgNiIvPg0KPHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFBy aW9yaXR5PSI1MCIgTmFtZT0iR3JpZCBUYWJsZSA1IERhcmsgQWNjZW50IDYiLz4NCjx3OkxzZEV4 Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBQcmlvcml0eT0iNTEiIE5hbWU9IkdyaWQgVGFibGUgNiBD b2xvcmZ1bCBBY2NlbnQgNiIvPg0KPHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFByaW9y aXR5PSI1MiIgTmFtZT0iR3JpZCBUYWJsZSA3IENvbG9yZnVsIEFjY2VudCA2Ii8+DQo8dzpMc2RF eGNlcHRpb24gTG9ja2VkPSJmYWxzZSIgUHJpb3JpdHk9IjQ2IiBOYW1lPSJMaXN0IFRhYmxlIDEg TGlnaHQiLz4NCjx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBQcmlvcml0eT0iNDciIE5h bWU9Ikxpc3QgVGFibGUgMiIvPg0KPHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFByaW9y aXR5PSI0OCIgTmFtZT0iTGlzdCBUYWJsZSAzIi8+DQo8dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJm YWxzZSIgUHJpb3JpdHk9IjQ5IiBOYW1lPSJMaXN0IFRhYmxlIDQiLz4NCjx3OkxzZEV4Y2VwdGlv biBMb2NrZWQ9ImZhbHNlIiBQcmlvcml0eT0iNTAiIE5hbWU9Ikxpc3QgVGFibGUgNSBEYXJrIi8+ DQo8dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJmYWxzZSIgUHJpb3JpdHk9IjUxIiBOYW1lPSJMaXN0 IFRhYmxlIDYgQ29sb3JmdWwiLz4NCjx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBQcmlv cml0eT0iNTIiIE5hbWU9Ikxpc3QgVGFibGUgNyBDb2xvcmZ1bCIvPg0KPHc6THNkRXhjZXB0aW9u IExvY2tlZD0iZmFsc2UiIFByaW9yaXR5PSI0NiIgTmFtZT0iTGlzdCBUYWJsZSAxIExpZ2h0IEFj Y2VudCAxIi8+DQo8dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJmYWxzZSIgUHJpb3JpdHk9IjQ3IiBO YW1lPSJMaXN0IFRhYmxlIDIgQWNjZW50IDEiLz4NCjx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZh bHNlIiBQcmlvcml0eT0iNDgiIE5hbWU9Ikxpc3QgVGFibGUgMyBBY2NlbnQgMSIvPg0KPHc6THNk RXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFByaW9yaXR5PSI0OSIgTmFtZT0iTGlzdCBUYWJsZSA0 IEFjY2VudCAxIi8+DQo8dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJmYWxzZSIgUHJpb3JpdHk9IjUw IiBOYW1lPSJMaXN0IFRhYmxlIDUgRGFyayBBY2NlbnQgMSIvPg0KPHc6THNkRXhjZXB0aW9uIExv Y2tlZD0iZmFsc2UiIFByaW9yaXR5PSI1MSIgTmFtZT0iTGlzdCBUYWJsZSA2IENvbG9yZnVsIEFj Y2VudCAxIi8+DQo8dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJmYWxzZSIgUHJpb3JpdHk9IjUyIiBO YW1lPSJMaXN0IFRhYmxlIDcgQ29sb3JmdWwgQWNjZW50IDEiLz4NCjx3OkxzZEV4Y2VwdGlvbiBM b2NrZWQ9ImZhbHNlIiBQcmlvcml0eT0iNDYiIE5hbWU9Ikxpc3QgVGFibGUgMSBMaWdodCBBY2Nl bnQgMiIvPg0KPHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFByaW9yaXR5PSI0NyIgTmFt ZT0iTGlzdCBUYWJsZSAyIEFjY2VudCAyIi8+DQo8dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJmYWxz ZSIgUHJpb3JpdHk9IjQ4IiBOYW1lPSJMaXN0IFRhYmxlIDMgQWNjZW50IDIiLz4NCjx3OkxzZEV4 Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBQcmlvcml0eT0iNDkiIE5hbWU9Ikxpc3QgVGFibGUgNCBB Y2NlbnQgMiIvPg0KPHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFByaW9yaXR5PSI1MCIg TmFtZT0iTGlzdCBUYWJsZSA1IERhcmsgQWNjZW50IDIiLz4NCjx3OkxzZEV4Y2VwdGlvbiBMb2Nr ZWQ9ImZhbHNlIiBQcmlvcml0eT0iNTEiIE5hbWU9Ikxpc3QgVGFibGUgNiBDb2xvcmZ1bCBBY2Nl bnQgMiIvPg0KPHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFByaW9yaXR5PSI1MiIgTmFt ZT0iTGlzdCBUYWJsZSA3IENvbG9yZnVsIEFjY2VudCAyIi8+DQo8dzpMc2RFeGNlcHRpb24gTG9j a2VkPSJmYWxzZSIgUHJpb3JpdHk9IjQ2IiBOYW1lPSJMaXN0IFRhYmxlIDEgTGlnaHQgQWNjZW50 IDMiLz4NCjx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBQcmlvcml0eT0iNDciIE5hbWU9 Ikxpc3QgVGFibGUgMiBBY2NlbnQgMyIvPg0KPHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFsc2Ui IFByaW9yaXR5PSI0OCIgTmFtZT0iTGlzdCBUYWJsZSAzIEFjY2VudCAzIi8+DQo8dzpMc2RFeGNl cHRpb24gTG9ja2VkPSJmYWxzZSIgUHJpb3JpdHk9IjQ5IiBOYW1lPSJMaXN0IFRhYmxlIDQgQWNj ZW50IDMiLz4NCjx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBQcmlvcml0eT0iNTAiIE5h bWU9Ikxpc3QgVGFibGUgNSBEYXJrIEFjY2VudCAzIi8+DQo8dzpMc2RFeGNlcHRpb24gTG9ja2Vk PSJmYWxzZSIgUHJpb3JpdHk9IjUxIiBOYW1lPSJMaXN0IFRhYmxlIDYgQ29sb3JmdWwgQWNjZW50 IDMiLz4NCjx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBQcmlvcml0eT0iNTIiIE5hbWU9 Ikxpc3QgVGFibGUgNyBDb2xvcmZ1bCBBY2NlbnQgMyIvPg0KPHc6THNkRXhjZXB0aW9uIExvY2tl ZD0iZmFsc2UiIFByaW9yaXR5PSI0NiIgTmFtZT0iTGlzdCBUYWJsZSAxIExpZ2h0IEFjY2VudCA0 Ii8+DQo8dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJmYWxzZSIgUHJpb3JpdHk9IjQ3IiBOYW1lPSJM aXN0IFRhYmxlIDIgQWNjZW50IDQiLz4NCjx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBQ cmlvcml0eT0iNDgiIE5hbWU9Ikxpc3QgVGFibGUgMyBBY2NlbnQgNCIvPg0KPHc6THNkRXhjZXB0 aW9uIExvY2tlZD0iZmFsc2UiIFByaW9yaXR5PSI0OSIgTmFtZT0iTGlzdCBUYWJsZSA0IEFjY2Vu dCA0Ii8+DQo8dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJmYWxzZSIgUHJpb3JpdHk9IjUwIiBOYW1l PSJMaXN0IFRhYmxlIDUgRGFyayBBY2NlbnQgNCIvPg0KPHc6THNkRXhjZXB0aW9uIExvY2tlZD0i ZmFsc2UiIFByaW9yaXR5PSI1MSIgTmFtZT0iTGlzdCBUYWJsZSA2IENvbG9yZnVsIEFjY2VudCA0 Ii8+DQo8dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJmYWxzZSIgUHJpb3JpdHk9IjUyIiBOYW1lPSJM aXN0IFRhYmxlIDcgQ29sb3JmdWwgQWNjZW50IDQiLz4NCjx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9 ImZhbHNlIiBQcmlvcml0eT0iNDYiIE5hbWU9Ikxpc3QgVGFibGUgMSBMaWdodCBBY2NlbnQgNSIv Pg0KPHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFByaW9yaXR5PSI0NyIgTmFtZT0iTGlz dCBUYWJsZSAyIEFjY2VudCA1Ii8+DQo8dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJmYWxzZSIgUHJp b3JpdHk9IjQ4IiBOYW1lPSJMaXN0IFRhYmxlIDMgQWNjZW50IDUiLz4NCjx3OkxzZEV4Y2VwdGlv biBMb2NrZWQ9ImZhbHNlIiBQcmlvcml0eT0iNDkiIE5hbWU9Ikxpc3QgVGFibGUgNCBBY2NlbnQg NSIvPg0KPHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFByaW9yaXR5PSI1MCIgTmFtZT0i TGlzdCBUYWJsZSA1IERhcmsgQWNjZW50IDUiLz4NCjx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZh bHNlIiBQcmlvcml0eT0iNTEiIE5hbWU9Ikxpc3QgVGFibGUgNiBDb2xvcmZ1bCBBY2NlbnQgNSIv Pg0KPHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFByaW9yaXR5PSI1MiIgTmFtZT0iTGlz dCBUYWJsZSA3IENvbG9yZnVsIEFjY2VudCA1Ii8+DQo8dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJm YWxzZSIgUHJpb3JpdHk9IjQ2IiBOYW1lPSJMaXN0IFRhYmxlIDEgTGlnaHQgQWNjZW50IDYiLz4N Cjx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBQcmlvcml0eT0iNDciIE5hbWU9Ikxpc3Qg VGFibGUgMiBBY2NlbnQgNiIvPg0KPHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFByaW9y aXR5PSI0OCIgTmFtZT0iTGlzdCBUYWJsZSAzIEFjY2VudCA2Ii8+DQo8dzpMc2RFeGNlcHRpb24g TG9ja2VkPSJmYWxzZSIgUHJpb3JpdHk9IjQ5IiBOYW1lPSJMaXN0IFRhYmxlIDQgQWNjZW50IDYi Lz4NCjx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBQcmlvcml0eT0iNTAiIE5hbWU9Ikxp c3QgVGFibGUgNSBEYXJrIEFjY2VudCA2Ii8+DQo8dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJmYWxz ZSIgUHJpb3JpdHk9IjUxIiBOYW1lPSJMaXN0IFRhYmxlIDYgQ29sb3JmdWwgQWNjZW50IDYiLz4N Cjx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBQcmlvcml0eT0iNTIiIE5hbWU9Ikxpc3Qg VGFibGUgNyBDb2xvcmZ1bCBBY2NlbnQgNiIvPg0KPC93OkxhdGVudFN0eWxlcz4NCjwveG1sPjwh W2VuZGlmXS0tPjxzdHlsZT48IS0tDQovKiBGb250IERlZmluaXRpb25zICovDQpAZm9udC1mYWNl DQoJe2ZvbnQtZmFtaWx5OiJDYW1icmlhIE1hdGgiOw0KCXBhbm9zZS0xOjIgNCA1IDMgNSA0IDYg MyAyIDQ7DQoJbXNvLWZvbnQtY2hhcnNldDowOw0KCW1zby1nZW5lcmljLWZvbnQtZmFtaWx5OnJv bWFuOw0KCW1zby1mb250LXBpdGNoOnZhcmlhYmxlOw0KCW1zby1mb250LXNpZ25hdHVyZTotNTM2 ODcwMTQ1IDExMDczMDU3MjcgMCAwIDQxNSAwO30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 Q2FsaWJyaTsNCglwYW5vc2UtMToyIDE1IDUgMiAyIDIgNCAzIDIgNDsNCgltc28tZm9udC1jaGFy c2V0OjA7DQoJbXNvLWdlbmVyaWMtZm9udC1mYW1pbHk6c3dpc3M7DQoJbXNvLWZvbnQtcGl0Y2g6 dmFyaWFibGU7DQoJbXNvLWZvbnQtc2lnbmF0dXJlOi01MzY4NzAxNDUgMTA3Mzc4NjExMSAxIDAg NDE1IDA7fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseTpUYWhvbWE7DQoJcGFub3NlLTE6MiAx MSA2IDQgMyA1IDQgNCAyIDQ7DQoJbXNvLWZvbnQtY2hhcnNldDowOw0KCW1zby1nZW5lcmljLWZv bnQtZmFtaWx5OnN3aXNzOw0KCW1zby1mb250LXBpdGNoOnZhcmlhYmxlOw0KCW1zby1mb250LXNp Z25hdHVyZTotNTIwMDgxNjY1IC0xMDczNzE3MTU3IDQxIDAgNjYwNDcgMDt9DQovKiBTdHlsZSBE ZWZpbml0aW9ucyAqLw0KcC5Nc29Ob3JtYWwsIGxpLk1zb05vcm1hbCwgZGl2Lk1zb05vcm1hbA0K CXttc28tc3R5bGUtdW5oaWRlOm5vOw0KCW1zby1zdHlsZS1xZm9ybWF0OnllczsNCgltc28tc3R5 bGUtcGFyZW50OiIiOw0KCW1hcmdpbjowaW47DQoJbWFyZ2luLWJvdHRvbTouMDAwMXB0Ow0KCW1z by1wYWdpbmF0aW9uOndpZG93LW9ycGhhbjsNCglmb250LXNpemU6MTIuMHB0Ow0KCWZvbnQtZmFt aWx5OiJUaW1lcyBOZXcgUm9tYW4iLHNlcmlmOw0KCW1zby1mYXJlYXN0LWZvbnQtZmFtaWx5OkNh bGlicmk7fQ0KYTpsaW5rLCBzcGFuLk1zb0h5cGVybGluaw0KCXttc28tc3R5bGUtbm9zaG93Onll czsNCgltc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6Ymx1ZTsNCgl0ZXh0LWRlY29yYXRp b246dW5kZXJsaW5lOw0KCXRleHQtdW5kZXJsaW5lOnNpbmdsZTt9DQphOnZpc2l0ZWQsIHNwYW4u TXNvSHlwZXJsaW5rRm9sbG93ZWQNCgl7bXNvLXN0eWxlLW5vc2hvdzp5ZXM7DQoJbXNvLXN0eWxl LXByaW9yaXR5Ojk5Ow0KCWNvbG9yOnB1cnBsZTsNCgl0ZXh0LWRlY29yYXRpb246dW5kZXJsaW5l Ow0KCXRleHQtdW5kZXJsaW5lOnNpbmdsZTt9DQpwDQoJe21zby1zdHlsZS1ub3Nob3c6eWVzOw0K CW1zby1zdHlsZS1wcmlvcml0eTo5OTsNCgltc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzsNCgltYXJn aW4tcmlnaHQ6MGluOw0KCW1zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvOw0KCW1hcmdpbi1sZWZ0 OjBpbjsNCgltc28tcGFnaW5hdGlvbjp3aWRvdy1vcnBoYW47DQoJZm9udC1zaXplOjEyLjBwdDsN Cglmb250LWZhbWlseToiVGltZXMgTmV3IFJvbWFuIixzZXJpZjsNCgltc28tZmFyZWFzdC1mb250 LWZhbWlseTpDYWxpYnJpO30NCnNwYW4uRW1haWxTdHlsZTE4DQoJe21zby1zdHlsZS10eXBlOnBl cnNvbmFsLXJlcGx5Ow0KCW1zby1zdHlsZS1ub3Nob3c6eWVzOw0KCW1zby1zdHlsZS11bmhpZGU6 bm87DQoJbXNvLWFuc2ktZm9udC1zaXplOjExLjBwdDsNCgltc28tYmlkaS1mb250LXNpemU6MTEu MHB0Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIixzYW5zLXNlcmlmOw0KCW1zby1hc2NpaS1mb250 LWZhbWlseTpDYWxpYnJpOw0KCW1zby1mYXJlYXN0LWZvbnQtZmFtaWx5OkNhbGlicmk7DQoJbXNv LWhhbnNpLWZvbnQtZmFtaWx5OkNhbGlicmk7DQoJbXNvLWJpZGktZm9udC1mYW1pbHk6IlRpbWVz IE5ldyBSb21hbiI7DQoJY29sb3I6IzFGNDk3RDt9DQpzcGFuLlNwZWxsRQ0KCXttc28tc3R5bGUt bmFtZToiIjsNCgltc28tc3BsLWU6eWVzO30NCi5Nc29DaHBEZWZhdWx0DQoJe21zby1zdHlsZS10 eXBlOmV4cG9ydC1vbmx5Ow0KCW1zby1kZWZhdWx0LXByb3BzOnllczsNCglmb250LWZhbWlseToi Q2FsaWJyaSIsc2Fucy1zZXJpZjsNCgltc28tYXNjaWktZm9udC1mYW1pbHk6Q2FsaWJyaTsNCglt c28tZmFyZWFzdC1mb250LWZhbWlseTpDYWxpYnJpOw0KCW1zby1oYW5zaS1mb250LWZhbWlseTpD YWxpYnJpOw0KCW1zby1iaWRpLWZvbnQtZmFtaWx5OiJUaW1lcyBOZXcgUm9tYW4iO30NCkBwYWdl IFdvcmRTZWN0aW9uMQ0KCXtzaXplOjguNWluIDExLjBpbjsNCgltYXJnaW46MS4waW4gMS4waW4g MS4waW4gMS4waW47DQoJbXNvLWhlYWRlci1tYXJnaW46LjVpbjsNCgltc28tZm9vdGVyLW1hcmdp bjouNWluOw0KCW1zby1wYXBlci1zb3VyY2U6MDt9DQpkaXYuV29yZFNlY3Rpb24xDQoJe3BhZ2U6 V29yZFNlY3Rpb24xO30NCi0tPjwvc3R5bGU+PCEtLVtpZiBndGUgbXNvIDEwXT48c3R5bGU+Lyog U3R5bGUgRGVmaW5pdGlvbnMgKi8NCnRhYmxlLk1zb05vcm1hbFRhYmxlDQoJe21zby1zdHlsZS1u YW1lOiJUYWJsZSBOb3JtYWwiOw0KCW1zby10c3R5bGUtcm93YmFuZC1zaXplOjA7DQoJbXNvLXRz dHlsZS1jb2xiYW5kLXNpemU6MDsNCgltc28tc3R5bGUtbm9zaG93OnllczsNCgltc28tc3R5bGUt cHJpb3JpdHk6OTk7DQoJbXNvLXN0eWxlLXBhcmVudDoiIjsNCgltc28tcGFkZGluZy1hbHQ6MGlu IDUuNHB0IDBpbiA1LjRwdDsNCgltc28tcGFyYS1tYXJnaW46MGluOw0KCW1zby1wYXJhLW1hcmdp bi1ib3R0b206LjAwMDFwdDsNCgltc28tcGFnaW5hdGlvbjp3aWRvdy1vcnBoYW47DQoJZm9udC1z aXplOjExLjBwdDsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsc2Fucy1zZXJpZjsNCgltc28tYXNj aWktZm9udC1mYW1pbHk6Q2FsaWJyaTsNCgltc28taGFuc2ktZm9udC1mYW1pbHk6Q2FsaWJyaTt9 DQo8L3N0eWxlPjwhW2VuZGlmXS0tPjwhLS1baWYgZ3RlIG1zbyA5XT48eG1sPg0KPG86c2hhcGVk ZWZhdWx0cyB2OmV4dD0iZWRpdCIgc3BpZG1heD0iMTAyNiIgLz4NCjwveG1sPjwhW2VuZGlmXS0t PjwhLS1baWYgZ3RlIG1zbyA5XT48eG1sPg0KPG86c2hhcGVsYXlvdXQgdjpleHQ9ImVkaXQiPg0K PG86aWRtYXAgdjpleHQ9ImVkaXQiIGRhdGE9IjEiIC8+DQo8L286c2hhcGVsYXlvdXQ+PC94bWw+ PCFbZW5kaWZdLS0+DQo8L2hlYWQ+DQo8Ym9keSBsYW5nPSJFTi1VUyIgbGluaz0iYmx1ZSIgdmxp bms9InB1cnBsZSIgc3R5bGU9InRhYi1pbnRlcnZhbDouNWluIj4NCjxkaXYgY2xhc3M9IldvcmRT ZWN0aW9uMSI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEx LjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7bXNvLWJpZGkt Zm9udC1mYW1pbHk6JnF1b3Q7VGltZXMgTmV3IFJvbWFuJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPlRo YW5rcywgRWtyISBMb29raW5nIGZvcndhcmQgdG8gcmVhZGluZyB0aGUgbmV4dCB2ZXJzaW9uIG9m IHRoZSBkcmFmdHMuPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZx dW90OyxzYW5zLXNlcmlmO21zby1iaWRpLWZvbnQtZmFtaWx5OiZxdW90O1RpbWVzIE5ldyBSb21h biZxdW90Oztjb2xvcjojMUY0OTdEIj5XaGVuZXZlciBpdCB3b3JrcyBiZXN0IGZvciB5b3UsIGNv dWxkIHlvdSwgcGxlYXNlLCByZXBseSB0byB0aGUgb3JpZ2luYWwgZW1haWwgc2hvd2luZyBpbmxp bmUgaG93IGVhY2ggY29tbWVudCBnb3QgYWRkcmVzc2VkPw0KIFRoYXQgd291bGQgaGVscCBhIGxv dC48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHls ZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMt c2VyaWY7bXNvLWJpZGktZm9udC1mYW1pbHk6JnF1b3Q7VGltZXMgTmV3IFJvbWFuJnF1b3Q7O2Nv bG9yOiMxRjQ5N0QiPkNoZWVycyw8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtD YWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7bXNvLWJpZGktZm9udC1mYW1pbHk6JnF1b3Q7VGltZXMg TmV3IFJvbWFuJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPk9yaXQuPG86cD48L286cD48L3NwYW4+PC9w Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9u dC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO21zby1iaWRpLWZvbnQtZmFt aWx5OiZxdW90O1RpbWVzIE5ldyBSb21hbiZxdW90Oztjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNw OzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48YSBuYW1lPSJfTWFpbEVu ZENvbXBvc2UiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90 O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjttc28tYmlkaS1mb250LWZhbWlseTomcXVvdDtUaW1l cyBOZXcgUm9tYW4mcXVvdDs7Y29sb3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+ PC9hPjwvcD4NCjxzcGFuIHN0eWxlPSJtc28tYm9va21hcms6X01haWxFbmRDb21wb3NlIj48L3Nw YW4+DQo8ZGl2IHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItbGVmdDpzb2xpZCBibHVlIDEuNXB0 O3BhZGRpbmc6MGluIDBpbiAwaW4gNC4wcHQiPg0KPGRpdj4NCjxkaXYgc3R5bGU9ImJvcmRlcjpu b25lO2JvcmRlci10b3A6c29saWQgI0UxRTFFMSAxLjBwdDtwYWRkaW5nOjMuMHB0IDBpbiAwaW4g MGluIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEu MHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjttc28tZmFyZWFz dC1mb250LWZhbWlseTomcXVvdDtUaW1lcyBOZXcgUm9tYW4mcXVvdDsiPkZyb206PC9zcGFuPjwv Yj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJp JnF1b3Q7LHNhbnMtc2VyaWY7bXNvLWZhcmVhc3QtZm9udC1mYW1pbHk6JnF1b3Q7VGltZXMgTmV3 IFJvbWFuJnF1b3Q7Ij4gRXJpYw0KIFJlc2NvcmxhIFttYWlsdG86ZWtyQHJ0Zm0uY29tXSA8YnI+ DQo8Yj5TZW50OjwvYj4gVHVlc2RheSwgQXVndXN0IDA0LCAyMDE1IDk6NDIgQU08YnI+DQo8Yj5U bzo8L2I+IE9yaXQgTGV2aW4gKExDQSkgJmx0O29yaXRsQG1pY3Jvc29mdC5jb20mZ3Q7PGJyPg0K PGI+Q2M6PC9iPiBUZWQgSGFyZGllICZsdDt0ZWQuaWV0ZkBnbWFpbC5jb20mZ3Q7OyBydGN3ZWJA aWV0Zi5vcmc7IGFwcHNkaXJAaWV0Zi5vcmc7IEVsaW90IExlYXIgJmx0O2xlYXJAY2lzY28uY29t Jmd0Ozxicj4NCjxiPlN1YmplY3Q6PC9iPiBSZTogW3J0Y3dlYl0gW2FwcHNkaXJdIEZ3ZDogUmVx dWVzdCBmb3IgQXBwcyBEaXJlY3RvcmF0ZSByZXZpZXcgb2YgcnRjd2ViLXNlY3VyaXR5IGRyYWZ0 czxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5J J2xsIGJlIGhhbmRsaW5nIHRoaXMgYWxvbmcgd2l0aCB0aGUgcmVzdCBvZiB0aGUgcmV2aWV3IGNv bW1lbnRzIEkgaGF2ZSByZWNlaXZlZCw8bzpwPjwvbzpwPjwvcD4NCjxkaXY+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj5hdCB0aGUgbmV4dCBkcmFmdCB1cGRhdGUgKHByb2JhYmx5IGJlZm9yZSB0aGUg bmV4dCBSVENXRUIvV2ViUlRDIGludGVyaW0pPG86cD48L286cD48L3A+DQo8ZGl2Pg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+YnV0IEkgZG9uJ3QgaGF2ZSBhIHNwZWNpZmljIEVUQS48bzpwPjwvbzpw PjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9v OnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+LUVrcjxvOnA+PC9v OnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8 L286cD48L3A+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7 PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi Pk9uIE1vbiwgQXVnIDMsIDIwMTUgYXQgNDo0MyBQTSwgT3JpdCBMZXZpbiAoTENBKSAmbHQ7PGEg aHJlZj0ibWFpbHRvOm9yaXRsQG1pY3Jvc29mdC5jb20iIHRhcmdldD0iX2JsYW5rIj5vcml0bEBt aWNyb3NvZnQuY29tPC9hPiZndDsgd3JvdGU6PG86cD48L286cD48L3A+DQo8YmxvY2txdW90ZSBz dHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLWxlZnQ6c29saWQgI0NDQ0NDQyAxLjBwdDttc28tYm9y ZGVyLWxlZnQtYWx0OnNvbGlkICNDQ0NDQ0MgLjc1cHQ7cGFkZGluZzowaW4gMGluIDBpbiA2LjBw dDttYXJnaW4tbGVmdDo0LjhwdDttYXJnaW4tcmlnaHQ6MGluIj4NCjxkaXY+DQo8ZGl2Pg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJn aW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZh bWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RCI+SGkgZ3V5 cyw8L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNv LW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIHN0 eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fu cy1zZXJpZjtjb2xvcjojMUY0OTdEIj5UaHJlZSBidXN5IHdlZWtzIGFuZCBhbiBJRVRGIG1lZXRp bmcgaGF2ZSBwYXN04oCmIFdoZW4gc2hvdWxkIHdlIGV4cGVjdCB0byBzZWUgdGhlIGZlZWRiYWNr IHRvIHRoZSByZXZpZXc/PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1h bCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDph dXRvIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxp YnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RCI+VGhhbmtzIGFuZCBjaGVlcnMsPC9z cGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJn aW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBzdHlsZT0i Zm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2Vy aWY7Y29sb3I6IzFGNDk3RCI+T3JpdC48L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0 b20tYWx0OmF1dG8iPjxhIG5hbWU9IjE0ZWY5OTNhMmNhZTZjNGNfMTRlZjk4NWQ4MzZiNGFlM19f TWFpbEUiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0Nh bGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEIj4mbmJzcDs8L3NwYW4+PC9hPjxv OnA+PC9vOnA+PC9wPg0KPGRpdiBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLWxlZnQ6c29saWQg Ymx1ZSAxLjVwdDtwYWRkaW5nOjBpbiAwaW4gMGluIDQuMHB0Ij4NCjxkaXY+DQo8ZGl2IHN0eWxl PSJib3JkZXI6bm9uZTtib3JkZXItdG9wOnNvbGlkICNFMUUxRTEgMS4wcHQ7cGFkZGluZzozLjBw dCAwaW4gMGluIDBpbiI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10 b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG87bXNvLW91dGxpbmUtbGV2ZWw6 MSI+DQo8Yj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtD YWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWYiPkZyb206PC9zcGFuPjwvYj48c3BhbiBzdHlsZT0iZm9u dC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWYi PiBUZWQgSGFyZGllIFttYWlsdG86PGEgaHJlZj0ibWFpbHRvOnRlZC5pZXRmQGdtYWlsLmNvbSIg dGFyZ2V0PSJfYmxhbmsiPnRlZC5pZXRmQGdtYWlsLmNvbTwvYT5dDQo8YnI+DQo8Yj5TZW50Ojwv Yj4gVHVlc2RheSwgSnVseSAxNCwgMjAxNSAxMToxOCBBTTxicj4NCjxiPlRvOjwvYj4gT3JpdCBM ZXZpbiAoTENBKSAmbHQ7PGEgaHJlZj0ibWFpbHRvOm9yaXRsQG1pY3Jvc29mdC5jb20iIHRhcmdl dD0iX2JsYW5rIj5vcml0bEBtaWNyb3NvZnQuY29tPC9hPiZndDs7DQo8YSBocmVmPSJtYWlsdG86 cnRjd2ViQGlldGYub3JnIiB0YXJnZXQ9Il9ibGFuayI+cnRjd2ViQGlldGYub3JnPC9hPjxicj4N CjxiPkNjOjwvYj4gRWxpb3QgTGVhciAmbHQ7PGEgaHJlZj0ibWFpbHRvOmxlYXJAY2lzY28uY29t IiB0YXJnZXQ9Il9ibGFuayI+bGVhckBjaXNjby5jb208L2E+Jmd0OzsNCjxhIGhyZWY9Im1haWx0 bzphcHBzZGlyQGlldGYub3JnIiB0YXJnZXQ9Il9ibGFuayI+YXBwc2RpckBpZXRmLm9yZzwvYT48 L3NwYW4+PG86cD48L286cD48L3A+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi Pjxicj4NCjxiPlN1YmplY3Q6PC9iPiBSZTogW2FwcHNkaXJdIEZ3ZDogUmVxdWVzdCBmb3IgQXBw cyBEaXJlY3RvcmF0ZSByZXZpZXcgb2YgcnRjd2ViLXNlY3VyaXR5IGRyYWZ0czxvOnA+PC9vOnA+ PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2lu LWJvdHRvbS1hbHQ6YXV0byI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8ZGl2Pg0KPGRpdj4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttYXJnaW4t Ym90dG9tOjEyLjBwdCI+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O1RhaG9tYSZxdW90 OyxzYW5zLXNlcmlmIj4oYWRkaW5nIHRoZSBXRyk8L3NwYW4+PG86cD48L286cD48L3A+DQo8L2Rp dj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0 OmF1dG87bWFyZ2luLWJvdHRvbToxMi4wcHQiPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTomcXVv dDtUYWhvbWEmcXVvdDssc2Fucy1zZXJpZiI+SGkgT3JpdCw8L3NwYW4+PG86cD48L286cD48L3A+ DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10 b3AtYWx0OmF1dG87bWFyZ2luLWJvdHRvbToxMi4wcHQiPjxzcGFuIHN0eWxlPSJmb250LWZhbWls eTomcXVvdDtUYWhvbWEmcXVvdDssc2Fucy1zZXJpZiI+VGhhbmtzIGZvciB0aGUgcmV2aWV3Ljwv c3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi IHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttYXJnaW4tYm90dG9tOjEyLjBwdCI+PHNw YW4gc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O1RhaG9tYSZxdW90OyxzYW5zLXNlcmlmIj5yZWdh cmRzLDwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29O b3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1h bHQ6YXV0byI+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O1RhaG9tYSZxdW90OyxzYW5z LXNlcmlmIj5UZWQgSGFyZGllPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0K PHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1t YXJnaW4tYm90dG9tLWFsdDphdXRvIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjxkaXY+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdp bi1ib3R0b20tYWx0OmF1dG8iPk9uIFR1ZSwgSnVsIDE0LCAyMDE1IGF0IDExOjA3IEFNLCBPcml0 IExldmluIChMQ0EpICZsdDs8YSBocmVmPSJtYWlsdG86b3JpdGxAbWljcm9zb2Z0LmNvbSIgdGFy Z2V0PSJfYmxhbmsiPm9yaXRsQG1pY3Jvc29mdC5jb208L2E+Jmd0OyB3cm90ZTo8bzpwPjwvbzpw PjwvcD4NCjxibG9ja3F1b3RlIHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItbGVmdDpzb2xpZCAj Q0NDQ0NDIDEuMHB0O3BhZGRpbmc6MGluIDBpbiAwaW4gNi4wcHQ7bWFyZ2luLWxlZnQ6NC44cHQ7 bWFyZ2luLXRvcDo1LjBwdDttYXJnaW4tcmlnaHQ6MGluO21hcmdpbi1ib3R0b206NS4wcHQiPg0K PHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1t YXJnaW4tYm90dG9tLWFsdDphdXRvIj5EaXNjbGFpbWVyOiBJIGFtIGZhbWlsaWFyIHdpdGggUlRD IGFuZCBXZWJSVEMsIGJ1dCBJIGhhdmVuJ3QgZm9sbG93ZWQgdGhlIFJUQ1dlYiB3b3JrIGluIHRo ZSBsYXN0IGZldyB5ZWFycy4gSSByZWFkIHRoZSB0d28gZHJhZnRzIGZvciB0aGUgZmlyc3QgdGlt ZS48YnI+DQpUaGVyZWZvcmUsIG15IGFwb2xvZ2llcyBmb3IgcG90ZW50aWFsbHkgcmFpc2luZyBw b2ludHMgdGhhdCBoYXZlIGJlZW4gZGlzY3Vzc2VkIGluIHRoZSBwYXN0Ljxicj4NCjxicj4NCiZn dDtGcm9tIHRoZSBBUFAgKG9yIEFSVCkgcmV2aWV3IHBlcnNwZWN0aXZlLCBteSBtYWluIGNvbW1l bnQgaXMgb24gdGhlIHRvcGljIG9mICZxdW90O1dlYi1CYXNlZCBQZWVyIEF1dGhlbnRpY2F0aW9u JnF1b3Q7LiBXaGlsZSBpdCBpcyBub3QgY2xlYXIgZnJvbSB0aGUgdGV4dCwgd2hpY2ggcGFydHMg YXJlIGFscmVhZHkgc3RhbmRhcmRpemVkIGNvbmNlcHRzIChlLmcuLCBieSBXM0MpIGFuZCB3aGlj aCBhcmUgaW50cm9kdWNlZCBoZXJlIGZvciB0aGUgZmlyc3QgdGltZSwNCiB0aGUgZGVzY3JpYmVk IGFwcHJvYWNoIHNlZW1zIHRvIGJlICgxKSB1c2VmdWwgdG8gd2ViIGFwcGxpY2F0aW9ucyBiZXlv bmQgV2ViUlRDLCAoMikgdW5kZXIgZGV2ZWxvcG1lbnQgYW5kIHRodXMgcHJvYmFibHkgbm90IHN0 YWJsZSwgYW5kICgzKSB0b28gZGV0YWlsZWQgZm9yICZxdW90O2FuIGFyY2hpdGVjdHVyZSZxdW90 OyBkb2N1bWVudC4mbmJzcDsgQXMgc3VjaCwgdGhlIGNvbmNlcHQgb2YgJnF1b3Q7IFdlYi1CYXNl ZCBQZWVyIEF1dGhlbnRpY2F0aW9uJnF1b3Q7IHByb2JhYmx5IG5lZWRzDQogdG8gYmUgaW50cm9k dWNlZCBhbmQgc3RhbmRhcmRpemVkIHVuZGVyIHRoZSBTZWN1cml0eSBBcmVhIGFuZCB0aGVuIGFk b3B0ZWQgYnkgV2ViUlRDIGFuZCBvdGhlciBhcHBzLjxicj4NCjxicj4NCjxhIGhyZWY9Imh0dHBz Oi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcvZG9jL2RyYWZ0LWlldGYtcnRjd2ViLXNlY3VyaXR5LyIg dGFyZ2V0PSJfYmxhbmsiPmh0dHBzOi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcvZG9jL2RyYWZ0LWll dGYtcnRjd2ViLXNlY3VyaXR5LzwvYT48YnI+DQpUaGlzIGRvY3VtZW50IGNvbnRhaW5zIGFuIGV4 Y2VsbGVudCBjb2xsZWN0aW9uIG9mIHNlY3VyaXR5IHRocmVhdHMgdG8gV2ViUlRDIGFuZCBkaXNj dXNzZXMgbWFueSBkaWZmZXJlbnQgaWRlYXMgZm9yIHRoZWlyIHBvdGVudGlhbCBtaXRpZ2F0aW9u LiBUaGF0IGJlaW5nIHNhaWQsIGl0IGlzIG5vdCBhbiBlYXN5IHJlYWQuIFNwZWNpZmljYWxseSwg ZnJvbSBoaWdoIGxldmVsIHRvIG1vcmUgc3BlY2lmaWM6PGJyPg0KMS4gVGhlIGludGVuZGVkIHN0 YXR1cyBvZiB0aGUgZG9jdW1lbnQgaXMgU3RhbmRhcmRzIFRyYWNrLCB3aGlsZSBhIHR5cGljYWwg c3RhdHVzIG9mIGEgJnF1b3Q7c2VjdXJpdHkgdGhyZWF0IG1vZGVsJnF1b3Q7IFJGQyBpcyBJbmZv cm1hdGlvbmFsLiBUaGlzIGRpc2NyZXBhbmN5IHByb2JhYmx5IGxpZXMgaW4gdGhlIGN1cnJlbnQg c2NvcGUgb2YgdGhlIGRvY3VtZW50LiBTZWUgdGhlIG5leHQgY29tbWVudCBiZWxvdy48YnI+DQoy LiBUaGUgc2NvcGUgb2YgdGhlIGRvY3VtZW50IGlzIG5vdCBjbGVhci4gSW4gYWRkaXRpb24gdG8g ZGVzY3JpYmluZyB0aGUgc2VjdXJpdHkgdGhyZWF0cyAoYW5kIHRoZSByZXF1aXJlbWVudHMgb3Ig dXNlciBleHBlY3RhdGlvbnMgcmVsYXRlZCB0byB0aGVpciBwcmV2ZW50aW9uKSwgaW4gbWFueSBw bGFjZXMgdGhlIGRvY3VtZW50IGxpc3RzIHBvdGVudGlhbCBzb2x1dGlvbnMgd2l0aCB0aGVpciBw ZXJjZWl2ZWQgbGltaXRhdGlvbnMgYW5kL29yDQogYXBwbGljYWJpbGl0eS4gRXhhbXBsZXMgYXJl IHNlY3Rpb25zOiA0LjIuMSwgNC4yLjIsIDQuMi4zLCA0LjIuNCwgNC4zLjIuMSwgNC4zLjIuMiwg NC4zLjIuMy4gVG8gaW1wcm92ZSB0aGUgZG9jdW1lbnQncyByZWFkYWJpbGl0eSBhbmQgcmVkdWNl IG92ZXJsYXBzLCZuYnNwOyB0aGUgc29sdXRpb25zIHNob3VsZCBiZSBpbnRyb2R1Y2VkIGFuZCBl eHBsYWluZWQgaW4gdGhlIGNvbXBhbmlvbiAmcXVvdDthcmNoaXRlY3R1cmUmcXVvdDsgZG9jdW1l bnQuIFNvbHV0aW9ucycgYXBwbGljYWJpbGl0eQ0KIHRvIGRpZmZlcmVudCB1c2UgY2FzZXMgbmVl ZHMgdG8gYmUgcHJvdmlkZWQgaW4gYSBub24tYmlhcyB3YXkuPGJyPg0KMy4gQXBhcnQgZnJvbSB0 aGUgYnJpZWYgSW50cm9kdWN0aW9uIHdpdGggYSBmZXcgZXhhbXBsZXMsIHRoZXJlIGlzIG5vIGRl c2NyaXB0aW9uIG9mIHRoZSBXZWJSVEMgdGhyZWF0IG1vZGVsIHB1dHRpbmcgYWxsIG1haW4gdHlw ZXMgb2YgdGhyZWF0IGluIG9uZSBwbGFjZS4gRm9yIGV4YW1wbGUsIHRoZSAmcXVvdDtDb21tdW5p Y2F0aW9ucyBTZWN1cml0eSZxdW90OyBhc3BlY3QgaXMgaW50cm9kdWNlZCBmb3IgdGhlIGZpcnN0 IHRpbWUgaW4gU2VjdGlvbiA0LjMgb25seS4NCiBUaGUgc3RhcnQgb2YgU2VjdGlvbiAmcXVvdDs0 LiBTZWN1cml0eSBmb3IgV2ViUlRDIEFwcGxpY2F0aW9ucyZxdW90OyBjb3VsZCBiZSBhIGxvZ2lj YWwgcGxhY2UgZm9yIGludHJvZHVjaW5nIHRoZSBXZWJSVEMgdGhyZWF0IG1vZGVsLjxicj4NCjQu IFRoZSAmcXVvdDtzaW1wbGUgV2ViUlRDIHN5c3RlbSZxdW90OyBwcmVzZW50ZWQgaW4gdGhlIElu dHJvZHVjdGlvbiBpbiBGaWd1cmUgMSBpcyBpbmFkZXF1YXRlIHRvIGlsbHVzdHJhdGUgbWFueSBv ZiB0aGUgc2NlbmFyaW9zIGFuZCBwb2ludHMgZGlzY3Vzc2VkIGluIHRoZSBkb2N1bWVudC4gRm9y IGV4YW1wbGUsIHNlZSB0aGUgZGlzY3Vzc2lvbiBhcm91bmQgbWVkaWEgb3JpZ2luIHZzLiB3ZWIg b3JpZ2luIGluIFNlY3Rpb24gNC4xLjMuPGJyPg0KNS4gU2VjdGlvbiAmcXVvdDszLiBUaGUgQnJv d3NlciBUaHJlYXQgTW9kZWwmcXVvdDsgaXMgYW4gb3ZlcnZpZXcgb2YgdGhlIGV4aXN0aW5nIHdl YiBzZWN1cml0eSBhcmNoaXRlY3R1cmUgYW5kIHNvbWUgY3VycmVudCBwcmFjdGljZXMuIEFzIHN1 Y2gsIHJlZmVyZW5jZXMgdG8gcmVsZXZhbnQgc3RhbmRhcmRzIChlLmcuLCBXM0MpIGFuZCBjb21t b24gcHJhY3RpY2VzIG5lZWQgdG8gYmUgYWRkZWQgd2l0aGluIHRoZSB0ZXh0IHRvIGhlbHAgdGhl IHJlYWRlciB0byB1bmRlcnN0YW5kDQogdGhlIHN0YXR1cyBvZiB0aGUgaW5mb3JtYXRpb24gYW5k IHRvIGZvbGxvdyB0aGUgc291cmNlcy48YnI+DQo2LiBUaGUgbGFzdCBwYXJhZ3JhcGggaW4gU2Vj dGlvbiA0LjEgY29udmV5cyBhIGtleSBwb2ludCBpbiB0aGUgd2hvbGUgV2ViUlRDIHRocmVhdCBt b2RlbC4gQXMgc3VjaCwmbmJzcDsgaXQgbmVlZHMgdG8gYmUgbW92ZWQgdG8gdGhlIHN0YXJ0IG9m IHRoZSBkaXNjdXNzaW9uIHdoZXJlIHRoZSB0aHJlYXQgbW9kZWwgaXMgaW50cm9kdWNlZCAoc2Vl IGNvbW1lbnRzIGFib3ZlKS48YnI+DQo3LiBTdHlsaXN0aWNhbGx5LCB0aGUgZG9jdW1lbnQgd291 bGQgYmVuZWZpdCBmcm9tIHJlbW92aW5nIG5vbi1zdGFuZGFyZHMgdm9jYWJ1bGFyeSwgaS5lLiwg JnF1b3Q7dG8gYnVnJnF1b3Q7LCAmcXVvdDt0byBidWcgbWUmcXVvdDssICZxdW90O25vIHJlYWwg d2F5JnF1b3Q7LCAmcXVvdDtpdCBpcyBpbXBvcnRhbnQgdG8gcmVxdWlyZSZxdW90OywgJnF1b3Q7 ZXh0cmVtZWx5IGFnZ3Jlc3NpdmUgaW50ZXJtZWRpYXRlcyZxdW90OywmbmJzcDsgYW5kICZxdW90 O2ZvciBvYnZpb3VzIHJlYXNvbnMmcXVvdDssIGV0Yy48YnI+DQo4LiBTdWdnZXN0aW9ucyBmb3Ig cmVuYW1pbmcgc29tZSBvZiB0aGUgc2VjdGlvbnMgdG8gaW1wcm92ZSByZWFkYWJpbGl0eTo8YnI+ DQomcXVvdDszLiBUaGUgQnJvd3NlciBUaHJlYXQgTW9kZWwmcXVvdDsgLSZndDsgJnF1b3Q7IDMu IE92ZXJ2aWV3IG9mIHRoZSBFeGlzdGluZyBXZWIgVGhyZWF0IE1vZGVsJnF1b3Q7PGJyPg0KJnF1 b3Q7NC4xLiBBY2Nlc3MgdG8gTG9jYWwgRGV2aWNlcyZxdW90OyAtJmd0OyAmcXVvdDs0LjEuIENv bnNlbnQgdG8gQWNjZXNzIExvY2FsIFJlc291cmNlcyZxdW90Ozxicj4NCiZxdW90OzQuMS4yLiBD YWxsaW5nIFNjZW5hcmlvcyBhbmQgVXNlciBFeHBlY3RhdGlvbnMmcXVvdDsgLSZndDsgJnF1b3Q7 NC4xLjIuIFNjb3BlIG9mIENvbnNlbnQgaW4gVmFyaW91cyBDYWxsaW5nIFNjZW5hcmlvcyZxdW90 Ozxicj4NCiZxdW90OzQuMS4yLjEuIERlZGljYXRlZCBDYWxsaW5nIFNlcnZpY2VzJnF1b3Q7IC0m Z3Q7ICZxdW90OzQuMS4yLjEuIExvbmctdGVybSBDb25zZW50JnF1b3Q7PGJyPg0KJnF1b3Q7NC4x LjIuMi4gQ2FsbGluZyB0aGUgc2l0ZSBZb3UncmUgT24mcXVvdDsgLSZndDsgJnF1b3Q7NC4xLjIu Mi4gU2hvcnQtdGVybSBDb25zZW50JnF1b3Q7PGJyPg0KJnF1b3Q7NC4xLjMuIE9yaWdpbi1CYXNl ZCBTZWN1cml0eSZxdW90OyAtJmd0OyAmcXVvdDs0LjEuMy4gV2ViIEF0dGFja2VycyBhbmQgT3Jp Z2luLWJhc2VkIFNlY3VyaXR5JnF1b3Q7PGJyPg0KJnF1b3Q7NC4xLjQuIFNlY3VyaXR5IFByb3Bl cnRpZXMgb2YgdGhlIENhbGxpbmcgUGFnZSZxdW90OyAtJmd0OyAmcXVvdDs0LjEuNC4gTmV0d29y ayBBdHRhY2tlcnMgYW5kJm5ic3A7IFNlY3VyaXR5IFByb3BlcnRpZXMgb2YgdGhlIENhbGxpbmcg UGFnZSZxdW90Ozxicj4NCiZxdW90OzQuMi4gQ29tbXVuaWNhdGlvbnMgQ29uc2VudCBWZXJpZmlj YXRpb24mcXVvdDsgLSZndDsgJnF1b3Q7NC4yLiBDb25zZW50IHRvIFJlY2VpdmUgVHJhZmZpYyZx dW90Ozxicj4NCiZxdW90OzQuMy4zLiBNYWxpY2lvdXMgUGVlcnMmcXVvdDsgLSZndDsgJnF1b3Q7 NC4zLjMuIE91dCBvZiBTY29wZSZxdW90Ozxicj4NCjxicj4NCjxhIGhyZWY9Imh0dHBzOi8vZGF0 YXRyYWNrZXIuaWV0Zi5vcmcvZG9jL2RyYWZ0LWlldGYtcnRjd2ViLXNlY3VyaXR5LWFyY2gvIiB0 YXJnZXQ9Il9ibGFuayI+aHR0cHM6Ly9kYXRhdHJhY2tlci5pZXRmLm9yZy9kb2MvZHJhZnQtaWV0 Zi1ydGN3ZWItc2VjdXJpdHktYXJjaC88L2E+PGJyPg0KVGhpcyBkb2N1bWVudCBpcyBpbiBhIG11 Y2ggYmV0dGVyIHN0YXRlIGluIHRlcm1zIG9mIGl0cyBvcmdhbml6YXRpb24gYW5kIHJlYWRhYmls aXR5LiBJdCBpbnRyb2R1Y2VzIHRoZSBzZWN1cml0eSBhcmNoaXRlY3R1cmUgdXNpbmcgYW4gZXhh bXBsZSBhbmQgdGhlbiBsaXN0cyBwb3NzaWJsZSBhcHByb2FjaGVzIHRvIGltcGxlbWVudCBpdC4g U29tZSBhcHByb2FjaGVzIGFyZSBkZXNjcmliZWQgb24gYSBoaWdoIGxldmVsIGJ5IHJlZmVyZW5j aW5nIG90aGVyDQogZG9jdW1lbnRzLCB3aGlsZSBvdGhlcnMgYXJlIGludHJvZHVjZWQgZm9yIHRo ZSBmaXJzdCB0aW1lIGluIHRoaXMgZG9jdW1lbnQgdG9nZXRoZXIgd2l0aCB0aGVpciBpbXBsZW1l bnRhdGlvbiBkZXRhaWxzLiBCeSBqdXN0IHJlYWRpbmcgdGhlIGRvY3VtZW50LCBpdCBpcyBkaWZm aWN1bHQgdG8ganVkZ2Ugd2hldGhlciB0aGVzZSBkZXRhaWxzIGFyZSBzdWZmaWNpZW50IG9yIHN0 YWJsZSBlbm91Z2ggZm9yIGltcGxlbWVudGF0aW9uLiBJbiBnZW5lcmFsLA0KIEkgZG91YnQgdGhh dCB0aGlzIGlzIHRoZSBiZXN0IGFwcHJvYWNoIGZvciBhbiAmcXVvdDthcmNoaXRlY3R1cmUmcXVv dDsgZG9jdW1lbnQsIHdoaWNoIGlzIHN1cHBvc2VkIHRvIHNlcnZlIGFzIGEgbG9uZyB0ZXJtIHN0 YWJsZSByZWZlcmVuY2UuPGJyPg0KTW9yZSBzcGVjaWZpYyBjb21tZW50czo8YnI+DQoxLiBEaWZm ZXJlbnQgdGVybWlub2xvZ3kgaXMgdXNlZCB0aHJvdWdob3V0IHRoZSBkb2N1bWVudCB0byBhZGRy ZXNzIHNhbWUgb3IgY2xvc2UgY29uY2VwdHMuIEl0IHdvdWxkIGhlbHAgYSBsb3QgdG8gZXhwbGFp biB0aGUgY29uY2VwdHMgdXBmcm9udCBhbmQgdGhlbiB0byB1c2UgdGhlIHRlcm1pbm9sb2d5IGNv bnNpc3RlbnRseS4gQ3VycmVudGx5IGl0IGluY2x1ZGVzICZxdW90O2NsaWVudCZxdW90OywgJnF1 b3Q7ZW5kcG9pbnQmcXVvdDssJm5ic3A7ICZxdW90O3BlZXImcXVvdDssICZxdW90O3VzZXImcXVv dDs7ICZxdW90O2ltcGxlbWVudGF0aW9uJnF1b3Q7LA0KICZxdW90O2Jyb3dzZXImcXVvdDssICZx dW90O2Nocm9tZSZxdW90OywgJnF1b3Q7QVBJJnF1b3Q7LCAmcXVvdDtKUyZxdW90OzsgJnF1b3Q7 YXBwbGljYXRpb24mcXVvdDssICZxdW90O3NlcnZlciZxdW90OywgZXRjLjxicj4NCjIuIFRoZSBk aXNjdXNzaW9uIGlzIHBocmFzZWQgaW4gdGVybXMgb2YgJnF1b3Q7YXV0aGVudGljYXRpb24mcXVv dDsgYW5kICZxdW90O3RydXN0JnF1b3Q7LiBJbiB0aGluayB0aGF0ICZxdW90O2F1dGhvcml6YXRp b24mcXVvdDsgaW5zdGVhZCBvZiAmcXVvdDt0cnVzdCZxdW90OyB3b3VsZCBiZSBhIGJldHRlciB0 ZWNobmljYWwgdGVybSwgZm9yIGV4YW1wbGUsIGluIFNlY3Rpb24gMy4xLjxicj4NCjMuIEluIHNl Y3Rpb24gNC4gT3ZlcnZpZXcsIHNlbnRlbmNlICZxdW90O3RoZSB0ZW5zaW9uIGJldHdlZW4gc2Vj dXJpdHkgKG9yIHBlcmZvcm1hbmNlKSBhbmQgcHJpdmFjeSZxdW90OyBpcyBub3QgY2xlYXIsIGVz cGVjaWFsbHkgYmVjYXVzZSBpdCBkb2Vzbid0IHNlZW0gdG8gY29ycmVzcG9uZCB0byBTZWN0aW9u IDYuMi4gKEJUVyAmcXVvdDt0cmFkZW9mZiZxdW90OyB3b3VsZCBiZSBhIGJldHRlciB3b3JkIHRo YW4gJnF1b3Q7dGVuc2lvbiZxdW90Oy4pPGJyPg0KNC4gU2VjdGlvbiAmcXVvdDs0LjEuIEluaXRp YWwgU2lnbmFsaW5nJnF1b3Q7LCB0aGUgdGV4dCBpcyBpbmNvbnNpc3RlbnQgaW4gdGVybXMgb2Yg d2hldGhlciBBbGljZSBhbmQgQm9iIHNoYXJlIG9yIHVzZSBkaWZmZXJlbnQgaWRlbnRpdHkgcHJv dmlkZXJzLjxicj4NCjUuIFNlY3Rpb24gJnF1b3Q7NC4xLiBJbml0aWFsIFNpZ25hbGluZyZxdW90 OywgcmVmZXJlbmNlIHRvIFBlZXJDb25uZWN0aW9uIG5lZWRzIHRvIGJlIGFkZGVkLjxicj4NCjYu IFNlY3Rpb24gJnF1b3Q7NC4yLiBNZWRpYSBDb25zZW50IFZlcmlmaWNhdGlvbiZxdW90OyBhbmQg U2VjdGlvbiAmcXVvdDs1LjMgQ29tbXVuaWNhdGlvbnMgQ29uc2VudCZxdW90OzogdGhlIG5hbWUv dGVybWlub2xvZ3kgb2YgdGhpcyBmdW5jdGlvbmFsaXR5IG5lZWRzIHRvIGJlIGhhcm1vbml6ZWQu IFRoZSBJQ0UtYmFzZWQgc29sdXRpb24gd2l0aCBpdHMgcHJvcywgY29ucyBhcyB3ZWxsIGFzIHRo ZSBhbHRlcm5hdGl2ZXMgKGFwcGxpY2FibGUgdG8gZGlmZmVyZW50IHVzZSBjYXNlcykNCiBuZWVk IHRvIGJlIG1vdmVkIGZyb20gdGhlIGNvbXBhbmlvbiB0aHJlYXQgbW9kZWwgZG9jdW1lbnQgdG8g dGhpcyAmcXVvdDthcmNoaXRlY3R1cmUmcXVvdDsgb25lLjxicj4NCjcuIEEgc3VnZ2VzdGlvbjog cmVuYW1lICZxdW90OzUuIERldGFpbGVkIFRlY2huaWNhbCBEZXNjcmlwdGlvbiZxdW90OyB0byAm cXVvdDs1LiBTZWN1cml0eSBBcmNoaXRlY3R1cmUgQ29tcG9uZW50cyZxdW90Oy48YnI+DQo4LiBJ biBTZWN0aW9uIDUuMi4sICZxdW90O0ltcGxlbWVudGF0aW9ucyB3aGljaCBzdXBwb3J0IHNvbWUg Zm9ybSBvZiBkaXJlY3QgdXNlciBhdXRoZW50aWNhdGlvbi4uLiZxdW90OyAtJmd0OyAmcXVvdDtJ bXBsZW1lbnRhdGlvbnMgdGhhdCBzdXBwb3J0IHNvbWUgZm9ybSBvZiBkaXJlY3QgdXNlciBhdXRo ZW50aWNhdGlvbi4uLiZxdW90Ozxicj4NCjkuIFNlY3Rpb24gJnF1b3Q7NS42LiBXZWItQmFzZWQg UGVlciBBdXRoZW50aWNhdGlvbiZxdW90OyBhbmQgc2VjdGlvbiAmcXVvdDs1LjYuMi4gT3ZlcnZp ZXcgb2Ygb3BlcmF0aW9uJnF1b3Q7OiBJdCBpcyBub3QgY2xlYXIsIHdoaWNoIHBhcnRzIGFyZSBz dGFuZGFyZGl6ZWQgY29uY2VwdHMgKGUuZy4sIGJ5IFczQykgYW5kIHdoaWNoIGFyZSBpbnRyb2R1 Y2VkIGhlcmUgZm9yIHRoZSBmaXJzdCB0aW1lLiBJZiBleGlzdCwgcmVmZXJlbmNlcyB0byBleGlz dGluZyBzdGFuZGFyZHMgbmVlZA0KIHRvIGJlIGFkZGVkLiBUaGUgZGVzY3JpYmVkIGFyY2hpdGVj dHVyZSBhbmQgdGhlIHRlY2huaWNhbCBkZXRhaWxzIHNlZW0gdG8gYmUgKDEpIHVuZGVyIGRldmVs b3BtZW50IGFuZCB0aHVzIHByb2JhYmx5IG5vdCBzdGFibGUsICgyKSB0b28gZGV0YWlsZWQgZm9y ICZxdW90O2FuIGFyY2hpdGVjdHVyZSZxdW90OyBkb2N1bWVudCBhbmQgKDMpIHVzZWZ1bCBiZXlv bmQgV2ViUlRDLiZuYnNwOyBBcyBzdWNoLCB0aGUgY29uY2VwdCBvZiB0aGUgJnF1b3Q7IFdlYi1C YXNlZCBQZWVyIEF1dGhlbnRpY2F0aW9uJnF1b3Q7DQogcHJvYmFibHkgbmVlZHMgYmUgaW50cm9k dWNlZCB1bmRlciB0aGUgU2VjdXJpdHkgQXJlYSBhbmQgdGhlbiBhZG9wdGVkIGJ5IFdlYlJUQy48 YnI+DQoxMC4gVGhlIHdlYi1iYXNlZCBwZWVyIGF1dGhlbnRpY2F0aW9uIHVzaW5nIElkUCBpcyBu b3QgdGhlIG9ubHkgbWVjaGFuaXNtIGFwcGxpY2FibGUgdG8gV2ViUlRDLiBNb3Jlb3ZlciwgdGhl IHdlYi1iYXNlZCBwZWVyIGF1dGhlbnRpY2F0aW9uJm5ic3A7IGlzIG5vdCB0aGUgb25seSBhcHBy b2FjaCBhcHBsaWNhYmxlIHRvIFdlYlJUQy4gQWx0ZXJuYXRpdmVzIGFyZSBsaXN0ZWQgaW4gdGhl IGNvbXBhbmlvbiBkb2N1bWVudCBhbmQgbmVlZCB0byBiZSBtb3ZlZA0KIGhlcmUgdG8gdGhlICZx dW90O2FyY2hpdGVjdHVyZSZxdW90OyBkb2N1bWVudCB3aXRoIHRoZWlyIHByb3MgYW5kIGNvbnMg cHJlc2VudGVkIGluIGFuIHVuYmlhc2VkIHdheS48YnI+DQoxMS4gU3R5bGlzdGljYWxseSwgdGhl IGRvY3VtZW50IHdvdWxkIGJlbmVmaXQgZnJvbSByZW1vdmluZyBub24tc3RhbmRhcmRzIHZvY2Fi dWxhcnksIGkuZS4sICZxdW90O3NvbWUgV2ViIHNlcnZlciZxdW90OywgJnF1b3Q7Y2FuJ3QgcmVh bGx5IHRydXN0JnF1b3Q7LCAmcXVvdDt0aGF0IG11Y2gmcXVvdDssICZxdW90O2ZhaXJseSBjb252 ZW50aW9uYWwmcXVvdDssICZxdW90O3NpbXBseSBoYXZlJnF1b3Q7LCAmcXVvdDthIGxpdHRsZSBh bnRpY2xpbWFjdGljJnF1b3Q7LCBldGMuIDstKTxicj4NCjxicj4NClRoYW5rcyw8YnI+DQpPcml0 LjxvOnA+PC9vOnA+PC9wPg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHls ZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxi cj4NCiZndDsgLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS08YnI+DQomZ3Q7IEZyb206IGFwcHNk aXIgW21haWx0bzo8YSBocmVmPSJtYWlsdG86YXBwc2Rpci1ib3VuY2VzQGlldGYub3JnIiB0YXJn ZXQ9Il9ibGFuayI+YXBwc2Rpci1ib3VuY2VzQGlldGYub3JnPC9hPl0gT24gQmVoYWxmIE9mIE9y aXQgTGV2aW48YnI+DQomZ3Q7IChMQ0EpPGJyPg0KJmd0OyBTZW50OiBUaHVyc2RheSwgSnVuZSAy NSwgMjAxNSAxOjE3IFBNPGJyPg0KJmd0OyBUbzogRWxpb3QgTGVhcjsgPGEgaHJlZj0ibWFpbHRv OmFwcHNkaXJAaWV0Zi5vcmciIHRhcmdldD0iX2JsYW5rIj5hcHBzZGlyQGlldGYub3JnPC9hPjxi cj4NCiZndDsgU3ViamVjdDogUmU6IFthcHBzZGlyXSBGd2Q6IFJlcXVlc3QgZm9yIEFwcHMgRGly ZWN0b3JhdGUgcmV2aWV3IG9mIHJ0Y3dlYi08YnI+DQomZ3Q7IHNlY3VyaXR5IGRyYWZ0czxicj4N CiZndDs8YnI+DQomZ3Q7IFBlcmZlY3QhIEkgaGF2ZSBhIHZlcnkgbG9uZyBmbGlnaHQgb24gdGhl IDd0aC4uLiBTbyByaWdodCBhZnRlciB0aGVuIG9yIGVhcmxpZXIuPGJyPg0KJmd0OyBPcml0Ljxi cj4NCiZndDs8YnI+DQomZ3Q7ICZndDsgLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS08YnI+DQom Z3Q7ICZndDsgRnJvbTogRWxpb3QgTGVhciBbbWFpbHRvOjxhIGhyZWY9Im1haWx0bzpsZWFyQGNp c2NvLmNvbSIgdGFyZ2V0PSJfYmxhbmsiPmxlYXJAY2lzY28uY29tPC9hPl08YnI+DQomZ3Q7ICZn dDsgU2VudDogVGh1cnNkYXksIEp1bmUgMjUsIDIwMTUgMTI6NTUgUE08YnI+DQomZ3Q7ICZndDsg VG86IE9yaXQgTGV2aW4gKExDQSk7IDxhIGhyZWY9Im1haWx0bzphcHBzZGlyQGlldGYub3JnIiB0 YXJnZXQ9Il9ibGFuayI+YXBwc2RpckBpZXRmLm9yZzwvYT48YnI+DQomZ3Q7ICZndDsgU3ViamVj dDogUmU6IFthcHBzZGlyXSBGd2Q6IFJlcXVlc3QgZm9yIEFwcHMgRGlyZWN0b3JhdGUgcmV2aWV3 IG9mIHJ0Y3dlYi08YnI+DQomZ3Q7ICZndDsgc2VjdXJpdHkgZHJhZnRzPGJyPg0KJmd0OyAmZ3Q7 PGJyPg0KJmd0OyAmZ3Q7IFRoYW5rIHlvdSBPcml0ISZuYnNwOyBDYW4geW91IHRyeSB0byBoYXZl IHRoZW0gZG9uZSBpbiBhYm91dCB0d28gd2Vla3M/PGJyPg0KJmd0OyAmZ3Q7PGJyPg0KJmd0OyAm Z3Q7IEVsaW90PGJyPg0KJmd0OyAmZ3Q7PGJyPg0KJmd0OyAmZ3Q7IE9uIDYvMjUvMTUgOTo1MiBQ TSwgT3JpdCBMZXZpbiAoTENBKSB3cm90ZTo8YnI+DQomZ3Q7ICZndDsgJmd0OyBJIHdpbGwgYmUg aGFwcHkgdG8gdGFrZSBhIGxvb2sgYXQgdGhlbSE8YnI+DQomZ3Q7ICZndDsgJmd0OyBPcml0Ljxi cj4NCiZndDsgJmd0OyAmZ3Q7PGJyPg0KJmd0OyAmZ3Q7ICZndDsmZ3Q7IC0tLS0tT3JpZ2luYWwg TWVzc2FnZS0tLS0tPGJyPg0KJmd0OyAmZ3Q7ICZndDsmZ3Q7IEZyb206IGFwcHNkaXIgW21haWx0 bzo8YSBocmVmPSJtYWlsdG86YXBwc2Rpci1ib3VuY2VzQGlldGYub3JnIiB0YXJnZXQ9Il9ibGFu ayI+YXBwc2Rpci1ib3VuY2VzQGlldGYub3JnPC9hPl0gT24gQmVoYWxmIE9mIEVsaW90PGJyPg0K Jmd0OyBMZWFyPGJyPg0KJmd0OyAmZ3Q7ICZndDsmZ3Q7IFNlbnQ6IFRodXJzZGF5LCBKdW5lIDI1 LCAyMDE1IDExOjQ0IEFNPGJyPg0KJmd0OyAmZ3Q7ICZndDsmZ3Q7IFRvOiA8YSBocmVmPSJtYWls dG86YXBwc2RpckBpZXRmLm9yZyIgdGFyZ2V0PSJfYmxhbmsiPmFwcHNkaXJAaWV0Zi5vcmc8L2E+ PGJyPg0KJmd0OyAmZ3Q7ICZndDsmZ3Q7IFN1YmplY3Q6IFthcHBzZGlyXSBGd2Q6IFJlcXVlc3Qg Zm9yIEFwcHMgRGlyZWN0b3JhdGUgcmV2aWV3IG9mIHJ0Y3dlYi08YnI+DQomZ3Q7ICZndDsgJmd0 OyZndDsgc2VjdXJpdHkgZHJhZnRzPGJyPg0KJmd0OyAmZ3Q7ICZndDsmZ3Q7PGJyPg0KJmd0OyAm Z3Q7ICZndDsmZ3Q7IERlYXIgQXBwc2RpciBmb2xrLDxicj4NCiZndDsgJmd0OyAmZ3Q7Jmd0Ozxi cj4NCiZndDsgJmd0OyAmZ3Q7Jmd0OyBDb3VsZCBJIGhhdmUgYSB2b2x1bnRlZXIgdG8gcmV2aWV3 IHRoZSBmb2xsb3dpbmcgdHdvIGRyYWZ0cz88YnI+DQomZ3Q7ICZndDsgJmd0OyZndDs8YnI+DQom Z3Q7ICZndDsgJmd0OyZndDsgPGEgaHJlZj0iaHR0cHM6Ly9kYXRhdHJhY2tlci5pZXRmLm9yZy9k b2MvZHJhZnQtaWV0Zi1ydGN3ZWItc2VjdXJpdHkvIiB0YXJnZXQ9Il9ibGFuayI+DQpodHRwczov L2RhdGF0cmFja2VyLmlldGYub3JnL2RvYy9kcmFmdC1pZXRmLXJ0Y3dlYi1zZWN1cml0eS88L2E+ PGJyPg0KJmd0OyAmZ3Q7ICZndDsmZ3Q7PGJyPg0KJmd0OyAmZ3Q7ICZndDsmZ3Q7IGFuZDxicj4N CiZndDsgJmd0OyAmZ3Q7Jmd0Ozxicj4NCiZndDsgJmd0OyAmZ3Q7Jmd0OyA8YSBocmVmPSJodHRw czovL2RhdGF0cmFja2VyLmlldGYub3JnL2RvYy9kcmFmdC1pZXRmLXJ0Y3dlYi1zZWN1cml0eS1h cmNoLyIgdGFyZ2V0PSJfYmxhbmsiPg0KaHR0cHM6Ly9kYXRhdHJhY2tlci5pZXRmLm9yZy9kb2Mv ZHJhZnQtaWV0Zi1ydGN3ZWItc2VjdXJpdHktYXJjaC88L2E+PGJyPg0KJmd0OyAmZ3Q7ICZndDsm Z3Q7PGJyPg0KJmd0OyAmZ3Q7ICZndDsmZ3Q7IFRlZCBpcyBleGVtcHQsIGhhdmluZyBtYWRlIHRo ZSByZXF1ZXN0IDstKTxicj4NCiZndDsgJmd0OyAmZ3Q7Jmd0Ozxicj4NCiZndDsgJmd0OyAmZ3Q7 Jmd0OyBFbGlvdDxicj4NCiZndDsgJmd0Ozxicj4NCiZndDs8YnI+DQomZ3Q7IF9fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fPGJyPg0KJmd0OyBhcHBzZGlyIG1h aWxpbmcgbGlzdDxicj4NCiZndDsgPGEgaHJlZj0ibWFpbHRvOmFwcHNkaXJAaWV0Zi5vcmciIHRh cmdldD0iX2JsYW5rIj5hcHBzZGlyQGlldGYub3JnPC9hPjxicj4NCiZndDsgPGEgaHJlZj0iaHR0 cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9hcHBzZGlyIiB0YXJnZXQ9Il9ibGFu ayI+aHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9hcHBzZGlyPC9hPjxicj4N Cjxicj4NCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fPGJy Pg0KYXBwc2RpciBtYWlsaW5nIGxpc3Q8YnI+DQo8YSBocmVmPSJtYWlsdG86YXBwc2RpckBpZXRm Lm9yZyIgdGFyZ2V0PSJfYmxhbmsiPmFwcHNkaXJAaWV0Zi5vcmc8L2E+PGJyPg0KPGEgaHJlZj0i aHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9hcHBzZGlyIiB0YXJnZXQ9Il9i bGFuayI+aHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9hcHBzZGlyPC9hPjxv OnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwvYmxvY2txdW90ZT4NCjwvZGl2Pg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJn aW4tYm90dG9tLWFsdDphdXRvIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+ DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05v cm1hbCIgc3R5bGU9Im1hcmdpbi1ib3R0b206MTIuMHB0Ij48YnI+DQpfX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXzxicj4NCnJ0Y3dlYiBtYWlsaW5nIGxpc3Q8 YnI+DQo8YSBocmVmPSJtYWlsdG86cnRjd2ViQGlldGYub3JnIiB0YXJnZXQ9Il9ibGFuayI+cnRj d2ViQGlldGYub3JnPC9hPjxicj4NCjxhIGhyZWY9Imh0dHBzOi8vd3d3LmlldGYub3JnL21haWxt YW4vbGlzdGluZm8vcnRjd2ViIiB0YXJnZXQ9Il9ibGFuayI+aHR0cHM6Ly93d3cuaWV0Zi5vcmcv bWFpbG1hbi9saXN0aW5mby9ydGN3ZWI8L2E+PG86cD48L286cD48L3A+DQo8L2Jsb2NrcXVvdGU+ DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9k aXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvYm9keT4NCjwvaHRtbD4NCg== --_000_BL2PR03MB2909277FDAF9F0F339D2476AD760BL2PR03MB290namprd_-- From nobody Tue Aug 4 16:16:26 2015 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AABED1A00AE; Tue, 4 Aug 2015 16:16:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Pa_K9m2M9PEM; Tue, 4 Aug 2015 16:16:21 -0700 (PDT) Received: from mail-wi0-x231.google.com (mail-wi0-x231.google.com [IPv6:2a00:1450:400c:c05::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 9E58F1A1A5B; Tue, 4 Aug 2015 16:16:20 -0700 (PDT) Received: by wibxm9 with SMTP id xm9so43134590wib.1; Tue, 04 Aug 2015 16:16:19 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=qkiW6YkVzTf/qOwmCY99f9iAEp2pQajj4WlyjhK2ZAo=; b=g4sZFyF42QsXa3TAKW9hY2avq9HGv6chZUpmP0yUd6Cm/VQ09T/XQ0KEwfm5wzpWF9 NSZU1ot5FkzxnDZ773A+tUOrtcf8LrAj7byHo9659BZCwrxuObxZ4V70O1e3tEGwdxnX 3cHKUWg6thabWRTD5+E+h3/Z3s5ynJCPR5U2g63QLShFmcG9mCN+xzKRCTiLK6fsS+l5 gep89SMzr374kdeu0cxAKPown4vzLlAfei1naYMMXs4fl6+y2mwqsOfcYeUc72a5uQgw LPu3qHtQ2j2IoVpl+zgIMIbX8bbfLNAKYc5HsFfZJLXI+psIFv/jzmO3Ggp2YpnuIalV CnPw== MIME-Version: 1.0 X-Received: by 10.194.108.232 with SMTP id hn8mr13122174wjb.154.1438730179381; Tue, 04 Aug 2015 16:16:19 -0700 (PDT) Received: by 10.194.17.68 with HTTP; Tue, 4 Aug 2015 16:16:19 -0700 (PDT) In-Reply-To: References: <558C4C02.3000404@cisco.com> <558C5CA3.7020108@cisco.com> Date: Tue, 4 Aug 2015 16:16:19 -0700 Message-ID: From: Ted Hardie To: "Orit Levin (LCA)" Content-Type: multipart/alternative; boundary=047d7bf198a0450e18051c8479d3 Archived-At: Cc: "appsdir@ietf.org" , "rtcweb@ietf.org" , Eliot Lear Subject: Re: [rtcweb] [appsdir] Fwd: Request for Apps Directorate review of rtcweb-security drafts X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 04 Aug 2015 23:16:25 -0000 --047d7bf198a0450e18051c8479d3 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On Tue, Aug 4, 2015 at 3:30 PM, Orit Levin (LCA) wrote: > Thanks, Ekr! Looking forward to reading the next version of the drafts. > > Whenever it works best for you, could you, please, reply to the original > email showing inline how each comment got addressed? That would help a lo= t. > > Cheers, > > Orit. > > > =E2=80=8BHi Orit, I think our aim is to describe how comments were addressed in the shepherd write-up; I'll take the action item to make sure you get a copy. Ted=E2=80=8B > > > *From:* Eric Rescorla [mailto:ekr@rtfm.com] > *Sent:* Tuesday, August 04, 2015 9:42 AM > *To:* Orit Levin (LCA) > *Cc:* Ted Hardie ; rtcweb@ietf.org; appsdir@ietf.org; > Eliot Lear > *Subject:* Re: [rtcweb] [appsdir] Fwd: Request for Apps Directorate > review of rtcweb-security drafts > > > > I'll be handling this along with the rest of the review comments I have > received, > > at the next draft update (probably before the next RTCWEB/WebRTC interim) > > but I don't have a specific ETA. > > > > -Ekr > > > > > > > > On Mon, Aug 3, 2015 at 4:43 PM, Orit Levin (LCA) > wrote: > > Hi guys, > > Three busy weeks and an IETF meeting have past=E2=80=A6 When should we ex= pect to > see the feedback to the review? > > Thanks and cheers, > > Orit. > > > > *From:* Ted Hardie [mailto:ted.ietf@gmail.com] > *Sent:* Tuesday, July 14, 2015 11:18 AM > *To:* Orit Levin (LCA) ; rtcweb@ietf.org > *Cc:* Eliot Lear ; appsdir@ietf.org > > > *Subject:* Re: [appsdir] Fwd: Request for Apps Directorate review of > rtcweb-security drafts > > > > (adding the WG) > > Hi Orit, > > Thanks for the review. > > regards, > > Ted Hardie > > > > On Tue, Jul 14, 2015 at 11:07 AM, Orit Levin (LCA) > wrote: > > Disclaimer: I am familiar with RTC and WebRTC, but I haven't followed the > RTCWeb work in the last few years. I read the two drafts for the first ti= me. > Therefore, my apologies for potentially raising points that have been > discussed in the past. > > >From the APP (or ART) review perspective, my main comment is on the topi= c > of "Web-Based Peer Authentication". While it is not clear from the text, > which parts are already standardized concepts (e.g., by W3C) and which ar= e > introduced here for the first time, the described approach seems to be (1= ) > useful to web applications beyond WebRTC, (2) under development and thus > probably not stable, and (3) too detailed for "an architecture" document. > As such, the concept of " Web-Based Peer Authentication" probably needs t= o > be introduced and standardized under the Security Area and then adopted b= y > WebRTC and other apps. > > https://datatracker.ietf.org/doc/draft-ietf-rtcweb-security/ > This document contains an excellent collection of security threats to > WebRTC and discusses many different ideas for their potential mitigation. > That being said, it is not an easy read. Specifically, from high level to > more specific: > 1. The intended status of the document is Standards Track, while a typica= l > status of a "security threat model" RFC is Informational. This discrepanc= y > probably lies in the current scope of the document. See the next comment > below. > 2. The scope of the document is not clear. In addition to describing the > security threats (and the requirements or user expectations related to > their prevention), in many places the document lists potential solutions > with their perceived limitations and/or applicability. Examples are > sections: 4.2.1, 4.2.2, 4.2.3, 4.2.4, 4.3.2.1, 4.3.2.2, 4.3.2.3. To impro= ve > the document's readability and reduce overlaps, the solutions should be > introduced and explained in the companion "architecture" document. > Solutions' applicability to different use cases needs to be provided in a > non-bias way. > 3. Apart from the brief Introduction with a few examples, there is no > description of the WebRTC threat model putting all main types of threat i= n > one place. For example, the "Communications Security" aspect is introduce= d > for the first time in Section 4.3 only. The start of Section "4. Security > for WebRTC Applications" could be a logical place for introducing the > WebRTC threat model. > 4. The "simple WebRTC system" presented in the Introduction in Figure 1 i= s > inadequate to illustrate many of the scenarios and points discussed in th= e > document. For example, see the discussion around media origin vs. web > origin in Section 4.1.3. > 5. Section "3. The Browser Threat Model" is an overview of the existing > web security architecture and some current practices. As such, references > to relevant standards (e.g., W3C) and common practices need to be added > within the text to help the reader to understand the status of the > information and to follow the sources. > 6. The last paragraph in Section 4.1 conveys a key point in the whole > WebRTC threat model. As such, it needs to be moved to the start of the > discussion where the threat model is introduced (see comments above). > 7. Stylistically, the document would benefit from removing non-standards > vocabulary, i.e., "to bug", "to bug me", "no real way", "it is important = to > require", "extremely aggressive intermediates", and "for obvious reasons= ", > etc. > 8. Suggestions for renaming some of the sections to improve readability: > "3. The Browser Threat Model" -> " 3. Overview of the Existing Web Threat > Model" > "4.1. Access to Local Devices" -> "4.1. Consent to Access Local Resources= " > "4.1.2. Calling Scenarios and User Expectations" -> "4.1.2. Scope of > Consent in Various Calling Scenarios" > "4.1.2.1. Dedicated Calling Services" -> "4.1.2.1. Long-term Consent" > "4.1.2.2. Calling the site You're On" -> "4.1.2.2. Short-term Consent" > "4.1.3. Origin-Based Security" -> "4.1.3. Web Attackers and Origin-based > Security" > "4.1.4. Security Properties of the Calling Page" -> "4.1.4. Network > Attackers and Security Properties of the Calling Page" > "4.2. Communications Consent Verification" -> "4.2. Consent to Receive > Traffic" > "4.3.3. Malicious Peers" -> "4.3.3. Out of Scope" > > https://datatracker.ietf.org/doc/draft-ietf-rtcweb-security-arch/ > This document is in a much better state in terms of its organization and > readability. It introduces the security architecture using an example and > then lists possible approaches to implement it. Some approaches are > described on a high level by referencing other documents, while others ar= e > introduced for the first time in this document together with their > implementation details. By just reading the document, it is difficult to > judge whether these details are sufficient or stable enough for > implementation. In general, I doubt that this is the best approach for an > "architecture" document, which is supposed to serve as a long term stable > reference. > More specific comments: > 1. Different terminology is used throughout the document to address same > or close concepts. It would help a lot to explain the concepts upfront an= d > then to use the terminology consistently. Currently it includes "client", > "endpoint", "peer", "user"; "implementation", "browser", "chrome", "API"= , > "JS"; "application", "server", etc. > 2. The discussion is phrased in terms of "authentication" and "trust". In > think that "authorization" instead of "trust" would be a better technical > term, for example, in Section 3.1. > 3. In section 4. Overview, sentence "the tension between security (or > performance) and privacy" is not clear, especially because it doesn't see= m > to correspond to Section 6.2. (BTW "tradeoff" would be a better word than > "tension".) > 4. Section "4.1. Initial Signaling", the text is inconsistent in terms of > whether Alice and Bob share or use different identity providers. > 5. Section "4.1. Initial Signaling", reference to PeerConnection needs to > be added. > 6. Section "4.2. Media Consent Verification" and Section "5.3 > Communications Consent": the name/terminology of this functionality needs > to be harmonized. The ICE-based solution with its pros, cons as well as t= he > alternatives (applicable to different use cases) need to be moved from th= e > companion threat model document to this "architecture" one. > 7. A suggestion: rename "5. Detailed Technical Description" to "5. > Security Architecture Components". > 8. In Section 5.2., "Implementations which support some form of direct > user authentication..." -> "Implementations that support some form of > direct user authentication..." > 9. Section "5.6. Web-Based Peer Authentication" and section "5.6.2. > Overview of operation": It is not clear, which parts are standardized > concepts (e.g., by W3C) and which are introduced here for the first time. > If exist, references to existing standards need to be added. The describe= d > architecture and the technical details seem to be (1) under development a= nd > thus probably not stable, (2) too detailed for "an architecture" document > and (3) useful beyond WebRTC. As such, the concept of the " Web-Based Pe= er > Authentication" probably needs be introduced under the Security Area and > then adopted by WebRTC. > 10. The web-based peer authentication using IdP is not the only mechanism > applicable to WebRTC. Moreover, the web-based peer authentication is not > the only approach applicable to WebRTC. Alternatives are listed in the > companion document and need to be moved here to the "architecture" docume= nt > with their pros and cons presented in an unbiased way. > 11. Stylistically, the document would benefit from removing non-standards > vocabulary, i.e., "some Web server", "can't really trust", "that much", > "fairly conventional", "simply have", "a little anticlimactic", etc. ;-) > > Thanks, > Orit. > > > > -----Original Message----- > > From: appsdir [mailto:appsdir-bounces@ietf.org] On Behalf Of Orit Levin > > (LCA) > > Sent: Thursday, June 25, 2015 1:17 PM > > To: Eliot Lear; appsdir@ietf.org > > Subject: Re: [appsdir] Fwd: Request for Apps Directorate review of > rtcweb- > > security drafts > > > > Perfect! I have a very long flight on the 7th... So right after then or > earlier. > > Orit. > > > > > -----Original Message----- > > > From: Eliot Lear [mailto:lear@cisco.com] > > > Sent: Thursday, June 25, 2015 12:55 PM > > > To: Orit Levin (LCA); appsdir@ietf.org > > > Subject: Re: [appsdir] Fwd: Request for Apps Directorate review of > rtcweb- > > > security drafts > > > > > > Thank you Orit! Can you try to have them done in about two weeks? > > > > > > Eliot > > > > > > On 6/25/15 9:52 PM, Orit Levin (LCA) wrote: > > > > I will be happy to take a look at them! > > > > Orit. > > > > > > > >> -----Original Message----- > > > >> From: appsdir [mailto:appsdir-bounces@ietf.org] On Behalf Of Eliot > > Lear > > > >> Sent: Thursday, June 25, 2015 11:44 AM > > > >> To: appsdir@ietf.org > > > >> Subject: [appsdir] Fwd: Request for Apps Directorate review of > rtcweb- > > > >> security drafts > > > >> > > > >> Dear Appsdir folk, > > > >> > > > >> Could I have a volunteer to review the following two drafts? > > > >> > > > >> https://datatracker.ietf.org/doc/draft-ietf-rtcweb-security/ > > > >> > > > >> and > > > >> > > > >> https://datatracker.ietf.org/doc/draft-ietf-rtcweb-security-arch/ > > > >> > > > >> Ted is exempt, having made the request ;-) > > > >> > > > >> Eliot > > > > > > > _______________________________________________ > > appsdir mailing list > > appsdir@ietf.org > > https://www.ietf.org/mailman/listinfo/appsdir > > _______________________________________________ > appsdir mailing list > appsdir@ietf.org > https://www.ietf.org/mailman/listinfo/appsdir > > > > > _______________________________________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/listinfo/rtcweb > > > --047d7bf198a0450e18051c8479d3 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On Tue, Aug 4, 2015 at 3:30 PM,= Orit Levin (LCA) <oritl@microsoft.com> wrote:

Thanks, Ekr! Looking forward to readi= ng the next version of the drafts.

Whenever it works best for you, could= you, please, reply to the original email showing inline how each comment g= ot addressed? That would help a lot.

Cheers,

Orit.

=C2=A0

<= /blockquote>

=E2=80=8BHi Orit,

I t= hink our aim is to describe how comments were addressed in the shepherd wri= te-up; I'll take the action item to make sure you get a copy.

Ted=E2=80=8B

=C2=A0

=C2=A0

From: Eric Rescorla [mailto:ekr@rtf= m.com]
Sent: Tuesday, August 04, 2015 9:42 AM
To: Orit Levin (LCA) <oritl@microsoft.com>
Cc: Ted Hardie <ted.ietf@gmail.com>; rtcweb@ietf.org; appsdir@ietf.org; Eliot Lear <lear@cisco.com>
Subject: Re: [rtcweb] [appsdir] Fwd: Request for Apps Directorate re= view of rtcweb-security drafts

=C2=A0

I'll be handling this along with the rest of the= review comments I have received,

at the next draft update (probably before the next R= TCWEB/WebRTC interim)

but I don't have a specific ETA.

=C2=A0

-Ekr

=C2=A0

=C2=A0

=C2=A0

On Mon, Aug 3, 2015 at 4:43 PM, Orit Levin (LCA) <= ;oritl@microsoft.c= om> wrote:

Hi guys,

Three busy weeks and an IETF meeting = have past=E2=80=A6 When should we expect to see the feedback to the review?=

Thanks and cheers,

Orit.

=C2=A0

From: Ted Hardie [mailto:ted.ietf@gmail.com]
Sent: Tuesday, July 14, 2015 11:18 AM
To: Orit Levin (LCA) <oritl@microsoft.com>; rtcweb@ietf.org Cc: Eliot Lear <lear@cisco.com>; appsdir@ietf.org<= /span>


Subject: Re: [appsdir] Fwd: Request for Apps Directorate review of r= tcweb-security drafts

=C2=A0

(adding the WG)

Hi Orit,

Thanks for the review.

regards,

Ted Hardie

=C2=A0

On Tue, Jul 14, 2015 at 11:07 AM, Orit Levin (LCA) &= lt;oritl@microsoft= .com> wrote:

Disclaimer: I am familiar with RTC and WebRTC, but I= haven't followed the RTCWeb work in the last few years. I read the two= drafts for the first time.
Therefore, my apologies for potentially raising points that have been discu= ssed in the past.

>From the APP (or ART) review perspective, my main comment is on the top= ic of "Web-Based Peer Authentication". While it is not clear from= the text, which parts are already standardized concepts (e.g., by W3C) and= which are introduced here for the first time, the described approach seems to be (1) useful to web applications beyond W= ebRTC, (2) under development and thus probably not stable, and (3) too deta= iled for "an architecture" document.=C2=A0 As such, the concept o= f " Web-Based Peer Authentication" probably needs to be introduced and standardized under the Security Area and then adopted= by WebRTC and other apps.

https://datatracker.ietf.org/doc/draft-ietf-rtcweb-security= /
This document contains an excellent collection of security threats to WebRT= C and discusses many different ideas for their potential mitigation. That b= eing said, it is not an easy read. Specifically, from high level to more sp= ecific:
1. The intended status of the document is Standards Track, while a typical = status of a "security threat model" RFC is Informational. This di= screpancy probably lies in the current scope of the document. See the next = comment below.
2. The scope of the document is not clear. In addition to describing the se= curity threats (and the requirements or user expectations related to their = prevention), in many places the document lists potential solutions with the= ir perceived limitations and/or applicability. Examples are sections: 4.2.1, 4.2.2, 4.2.3, 4.2.4, 4.3.2.1,= 4.3.2.2, 4.3.2.3. To improve the document's readability and reduce ove= rlaps,=C2=A0 the solutions should be introduced and explained in the compan= ion "architecture" document. Solutions' applicability to different use cases needs to be provided in a non-bias way.
3. Apart from the brief Introduction with a few examples, there is no descr= iption of the WebRTC threat model putting all main types of threat in one p= lace. For example, the "Communications Security" aspect is introd= uced for the first time in Section 4.3 only. The start of Section "4. Security for WebRTC Applications" could= be a logical place for introducing the WebRTC threat model.
4. The "simple WebRTC system" presented in the Introduction in Fi= gure 1 is inadequate to illustrate many of the scenarios and points discuss= ed in the document. For example, see the discussion around media origin vs.= web origin in Section 4.1.3.
5. Section "3. The Browser Threat Model" is an overview of the ex= isting web security architecture and some current practices. As such, refer= ences to relevant standards (e.g., W3C) and common practices need to be add= ed within the text to help the reader to understand the status of the information and to follow the sources.
6. The last paragraph in Section 4.1 conveys a key point in the whole WebRT= C threat model. As such,=C2=A0 it needs to be moved to the start of the dis= cussion where the threat model is introduced (see comments above).
7. Stylistically, the document would benefit from removing non-standards vo= cabulary, i.e., "to bug", "to bug me", "no real wa= y", "it is important to require", "extremely aggressive= intermediates",=C2=A0 and "for obvious reasons", etc.
8. Suggestions for renaming some of the sections to improve readability: "3. The Browser Threat Model" -> " 3. Overview of the Exi= sting Web Threat Model"
"4.1. Access to Local Devices" -> "4.1. Consent to Access= Local Resources"
"4.1.2. Calling Scenarios and User Expectations" -> "4.1.= 2. Scope of Consent in Various Calling Scenarios"
"4.1.2.1. Dedicated Calling Services" -> "4.1.2.1. Long-t= erm Consent"
"4.1.2.2. Calling the site You're On" -> "4.1.2.2. Sh= ort-term Consent"
"4.1.3. Origin-Based Security" -> "4.1.3. Web Attackers a= nd Origin-based Security"
"4.1.4. Security Properties of the Calling Page" -> "4.1.= 4. Network Attackers and=C2=A0 Security Properties of the Calling Page"= ;
"4.2. Communications Consent Verification" -> "4.2. Conse= nt to Receive Traffic"
"4.3.3. Malicious Peers" -> "4.3.3. Out of Scope"
https://datatracker.ietf.org/doc/draft-ietf-rtcweb-sec= urity-arch/
This document is in a much better state in terms of its organization and re= adability. It introduces the security architecture using an example and the= n lists possible approaches to implement it. Some approaches are described = on a high level by referencing other documents, while others are introduced for the first time in this document= together with their implementation details. By just reading the document, = it is difficult to judge whether these details are sufficient or stable eno= ugh for implementation. In general, I doubt that this is the best approach for an "architecture" doc= ument, which is supposed to serve as a long term stable reference.
More specific comments:
1. Different terminology is used throughout the document to address same or= close concepts. It would help a lot to explain the concepts upfront and th= en to use the terminology consistently. Currently it includes "client&= quot;, "endpoint",=C2=A0 "peer", "user"; &quo= t;implementation", "browser", "chrome", "API", "JS"; = "application", "server", etc.
2. The discussion is phrased in terms of "authentication" and &qu= ot;trust". In think that "authorization" instead of "tr= ust" would be a better technical term, for example, in Section 3.1. 3. In section 4. Overview, sentence "the tension between security (or = performance) and privacy" is not clear, especially because it doesn= 9;t seem to correspond to Section 6.2. (BTW "tradeoff" would be a= better word than "tension".)
4. Section "4.1. Initial Signaling", the text is inconsistent in = terms of whether Alice and Bob share or use different identity providers. 5. Section "4.1. Initial Signaling", reference to PeerConnection = needs to be added.
6. Section "4.2. Media Consent Verification" and Section "5.= 3 Communications Consent": the name/terminology of this functionality = needs to be harmonized. The ICE-based solution with its pros, cons as well = as the alternatives (applicable to different use cases) need to be moved from the companion threat model document to this "ar= chitecture" one.
7. A suggestion: rename "5. Detailed Technical Description" to &q= uot;5. Security Architecture Components".
8. In Section 5.2., "Implementations which support some form of direct= user authentication..." -> "Implementations that support some= form of direct user authentication..."
9. Section "5.6. Web-Based Peer Authentication" and section "= ;5.6.2. Overview of operation": It is not clear, which parts are stand= ardized concepts (e.g., by W3C) and which are introduced here for the first= time. If exist, references to existing standards need to be added. The described architecture and the technical details seem to = be (1) under development and thus probably not stable, (2) too detailed for= "an architecture" document and (3) useful beyond WebRTC.=C2=A0 A= s such, the concept of the " Web-Based Peer Authentication" probably needs be introduced under the Security Area and then adopted by W= ebRTC.
10. The web-based peer authentication using IdP is not the only mechanism a= pplicable to WebRTC. Moreover, the web-based peer authentication=C2=A0 is n= ot the only approach applicable to WebRTC. Alternatives are listed in the c= ompanion document and need to be moved here to the "architecture" document with their pros and cons pre= sented in an unbiased way.
11. Stylistically, the document would benefit from removing non-standards v= ocabulary, i.e., "some Web server", "can't really trust&= quot;, "that much", "fairly conventional", "simply= have", "a little anticlimactic", etc. ;-)

Thanks,
Orit.


> -----Original Message-----
> From: appsdir [mailto:appsdir-bounces@ietf.org] On Behalf Of Orit Levin
> (LCA)
> Sent: Thursday, June 25, 2015 1:17 PM
> To: Eliot Lear; = appsdir@ietf.org
> Subject: Re: [appsdir] Fwd: Request for Apps Directorate review of rtc= web-
> security drafts
>
> Perfect! I have a very long flight on the 7th... So right after then o= r earlier.
> Orit.
>
> > -----Original Message-----
> > From: Eliot Lear [mailto:lear@cisco.com]
> > Sent: Thursday, June 25, 2015 12:55 PM
> > To: Orit Levin (LCA); appsdir@ietf.org
> > Subject: Re: [appsdir] Fwd: Request for Apps Directorate review o= f rtcweb-
> > security drafts
> >
> > Thank you Orit!=C2=A0 Can you try to have them done in about two = weeks?
> >
> > Eliot
> >
> > On 6/25/15 9:52 PM, Orit Levin (LCA) wrote:
> > > I will be happy to take a look at them!
> > > Orit.
> > >
> > >> -----Original Message-----
> > >> From: appsdir [mailto:appsdir-bounces@ietf.org] On Behalf Of Elio= t
> Lear
> > >> Sent: Thursday, June 25, 2015 11:44 AM
> > >> To: appsdir@ietf.org
> > >> Subject: [appsdir] Fwd: Request for Apps Directorate rev= iew of rtcweb-
> > >> security drafts
> > >>
> > >> Dear Appsdir folk,
> > >>
> > >> Could I have a volunteer to review the following two dra= fts?
> > >>
> > >> https://datatracker.ietf.org/doc/draft-ietf-rtcweb-security/
> > >>
> > >> and
> > >>
> > >> https://datatracker.ietf.org/doc/draft-ietf-rtcweb-security-arch/
> > >>
> > >> Ted is exempt, having made the request ;-)
> > >>
> > >> Eliot
> >
>
> _______________________________________________
> appsdir mailing list
> appsdir@ietf.org=
> https://www.ietf.org/mailman/listinfo/appsdir

_______________________________________________
appsdir mailing list
appsdir@ietf.org<= br> https://www.ietf.org/mailman/listinfo/appsdir

=C2=A0


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

=C2=A0


--047d7bf198a0450e18051c8479d3-- From nobody Tue Aug 4 16:24:43 2015 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 59A261A896D for ; Tue, 4 Aug 2015 16:24:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tWZr-bmDJXpN for ; Tue, 4 Aug 2015 16:24:38 -0700 (PDT) Received: from na01-bl2-obe.outbound.protection.outlook.com (mail-bl2on0078.outbound.protection.outlook.com [65.55.169.78]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 71BC71A8998 for ; Tue, 4 Aug 2015 16:24:38 -0700 (PDT) Received: from SN1PR0301MB1551.namprd03.prod.outlook.com (10.162.129.157) by SN1PR0301MB1552.namprd03.prod.outlook.com (10.162.129.158) with Microsoft SMTP Server (TLS) id 15.1.225.19; Tue, 4 Aug 2015 23:24:35 +0000 Received: from SN1PR0301MB1551.namprd03.prod.outlook.com ([10.162.129.157]) by SN1PR0301MB1551.namprd03.prod.outlook.com ([10.162.129.157]) with mapi id 15.01.0225.018; Tue, 4 Aug 2015 23:24:35 +0000 From: "Asveren, Tolga" To: Christer Holmberg , Bernard Aboba Thread-Topic: [rtcweb] What the gateway draft should say about mux/non-mux Thread-Index: AQHQy8DcUgzWwtVCmk+8q67BCzjC45316kQQgAAD5oCAAACVsIAAAj2AgAPw2gCAAEFTAIAARmyAgAAi5WCAABbtAIAASnwUgAAF9wCAAARia4AAVoWAgAA8di6AAGF3AIAAj4Wz Date: Tue, 4 Aug 2015 23:24:35 +0000 Message-ID: References: , <7594FB04B1934943A5C02806D1A2204B348E82CA@ESESSMB209.ericsson.se> In-Reply-To: <7594FB04B1934943A5C02806D1A2204B348E82CA@ESESSMB209.ericsson.se> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=tasveren@sonusnet.com; x-originating-ip: [50.182.164.80] x-microsoft-exchange-diagnostics: 1; SN1PR0301MB1552; 5:P4TICaoY04SWq1lTxFpR/IH2O/fP0DldW13vZEJKGTmTwTEFX1LakO+fm37QX8S9+kj18FykkhSIvNtfAamHfgSHIVhZ/xxYSwH5h2MCUEsHeJ+tI+rtgON7hmh8saA1D/ErLCW52RKoBe/OSmKs+g==; 24:oafc9ETCFbcziuLvazPT29cPrlqXHHyfRuxsaBrNjT4QyximChpTCcq5/eujoHnRA725Xsjas+ahu0rg1ThFutjKjcoxfo2+qrHyhgpD4dg=; 20:aQnx0oMD5oR1P2RE/xIEmghC8hs/wIPj86CD1LASUUV7cpzyqXdXmoRlHkX06gcNN+EK51qenojLR4A7dPCj2g== x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:SN1PR0301MB1552; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:; x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(601004)(5005006)(3002001); SRVR:SN1PR0301MB1552; BCL:0; PCL:0; RULEID:; SRVR:SN1PR0301MB1552; x-forefront-prvs: 0658BAF71F x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(377454003)(24454002)(189002)(199003)(164054003)(16236675004)(66066001)(87936001)(64706001)(19580405001)(19580395003)(10400500002)(76576001)(40100003)(19627405001)(77156002)(62966003)(46102003)(5002640100001)(122556002)(97736004)(2950100001)(2656002)(19625215002)(76176999)(2900100001)(92566002)(68736005)(77096005)(105586002)(106116001)(106356001)(102836002)(99286002)(74316001)(50986999)(5001830100001)(5003600100002)(5001770100001)(33656002)(101416001)(4001540100001)(81156007)(189998001)(5001960100002)(86362001)(54356999)(5001860100001); DIR:OUT; SFP:1101; SCL:1; SRVR:SN1PR0301MB1552; H:SN1PR0301MB1551.namprd03.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; MX:1; A:1; LANG:en; received-spf: None (protection.outlook.com: sonusnet.com does not designate permitted sender hosts) Content-Type: multipart/alternative; boundary="_000_SN1PR0301MB15517DD9BF2570136FFD312EB2760SN1PR0301MB1551_" MIME-Version: 1.0 X-OriginatorOrg: sonusnet.com X-MS-Exchange-CrossTenant-originalarrivaltime: 04 Aug 2015 23:24:35.3221 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 29a671dc-ed7e-4a54-b1e5-8da1eb495dc3 X-MS-Exchange-Transport-CrossTenantHeadersStamped: SN1PR0301MB1552 Archived-At: Cc: "" Subject: Re: [rtcweb] What the gateway draft should say about mux/non-mux X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 04 Aug 2015 23:24:42 -0000 --_000_SN1PR0301MB15517DD9BF2570136FFD312EB2760SN1PR0301MB1551_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable There are broadly two different categories of behavior when it comes to sta= ndards organizations/specifications: i- Standards, which define the actual protocol mechanics, e.g. on the wire = messages, negotiation procedures between peers. These are essential for dif= ferent elements to communicate and "do the right thing". ii- Profiles, which usually specify a subset of the whole functionality def= ined in i- as a functionality set to be used in a particular deployment env= ironment. I think IETF in general is more interested in i-. Defining what a "WebRTC G= W" is and how it can use/omit certain core functionalities does not fall in= to this category. Just as an example, let's take the example of se of public IP Addresses: If= the actual standard allows use of ICE-lite, it is up to an implementer to = build a box with only ICE-lite support if it is going to be used exclusivel= y in an environment where it will be assigned a public IP Address. This doe= s not require "standardization" AFAICS. So, I don't think a document like G= W-draft is really much useful and should be "Informational", if it should e= xist at all. Admittedly, the issue of rtcp-mux is a bit more grey. In running code we tr= ust and several parties indicated that supporting DTLS-SRTP with full rtcp-= mux negotiation support is a pain in the neck. Actually even here one could= take a more "this is not a core protocol issue" approach. If all browsers = support only rtcp-mux and do not interoperate with elements which do not su= pport it, well that would be just it. Any such other entity either would no= t be able to communicate with the browsers and realize its mistake or it wo= n't care about it at all as it is designed to be deployed in a non-browser = environment. I understand that this is perceived as having a detrimental ef= fect on practical interoperability but I am not sure whether a core protoco= l level mandate of forbidding no-rtcp-mux is justified. When it comes to br= owser-to-non browser entity communication, I think the cards are stacked ve= ry heavily in favor of browsers for such functionality mismatches. In other= words, whatever browsers do would be the "de facto Internet Profile". Thanks, Tolga ________________________________ From: Christer Holmberg Sent: Tuesday, August 4, 2015 10:30 AM To: Asveren, Tolga; Bernard Aboba Cc: Roman Shpount; Eric Rescorla; Schwarz, Albrecht (Albrecht); Rauschenbac= h, Uwe (Nokia - DE/Munich); Subject: RE: [rtcweb] What the gateway draft should say about mux/non-mux Hi, > These are just some *assumptions*. There are/will be gateways deployed wi= th no public IP Addresses. Similarly what is "on the other side" of the gat= eway is/will be varied as well. > > If one goes into the guessing game, it can be argued that "A gateway pote= ntially may be deployed with only endpoints supporting x/y/z etc..". There = could be many such combinations. > > In the light of this, I really don't see a point for the GW draft, especi= ally after seeing that folks have the view that it should fully interoperat= e with a "vanilla WebRTC endpoint". That pretty > much means that a GW itself a WebRTC endpoint and there is nothing else t= o specify from RTCWeb WG perspective (and hence there is even no need to de= fine an entity as "WebRTC GW"). As has been said, a WebRTC GW differs from a vanilla WebRTC endpoint e.g. i= n that it can be ICE-lite and that it is not mandated to send consent refre= sh requests. However, that doesn=92t prevent it from fully interoperating w= ith a vanilla endpoint. Regards, Christer ________________________________ From: Bernard Aboba > Sent: Tuesday, August 4, 2015 1:05 AM To: Asveren, Tolga Cc: Roman Shpount; Eric Rescorla; Schwarz, Albrecht (Albrecht); Rauschenbac= h, Uwe (Nokia - DE/Munich); Christer Holmberg; > Subject: Re: [rtcweb] What the gateway draft should say about mux/non-mux As Roman said, gateways have only slightly different requirements on the WE= BRTC side due to potential ability to use a Public IP address, allowing use= of ICE-LITE. Requirements on the other side depend on what the legacy end= point is. The lowest legacy endpoint is one with IPv4, g.711, RTP/AVP or pe= rhaps RTP/SAVP, no ICE, maybe no RTCP. On Aug 3, 2015, at 16:57, Asveren, Tolga > wrote: Well, the same would apply to a WebRTC-endpoint, which is deployed with a p= ublic IP. Why invent a new term as GW? These are just choices based on depl= oyment model. And who said there are universal guarantees that GWs will be deployed with = routable IP Addresses? Again, deployment choices are best left unspecified. Thanks, Tolga ________________________________ From: Roman Shpount > Sent: Monday, August 3, 2015 7:39 PM To: Asveren, Tolga Cc: Bernard Aboba; Eric Rescorla; Schwarz, Albrecht (Albrecht); Rauschenbac= h, Uwe (Nokia - DE/Munich); Christer Holmberg; > Subject: Re: [rtcweb] What the gateway draft should say about mux/non-mux On Mon, Aug 3, 2015 at 7:21 PM, Asveren, Tolga > wrote: With this interpretation, is there really a raison d'=EAtre for the GW draf= t? One just could view it as an entity with one side facing WebRTC universe= as a "full WebRTC endpoint". Honestly, that would make life easier rather = than muddying the water with what a GW should/must/may do. GW is different from the "full WebRTC endpoint" since it would typically be= placed on public IP. This allows for slightly different requirements. For = instance gateway can be ICE-lite instead of full ICE required by WebRTC end= point. Regards, _____________ Roman Shpount --_000_SN1PR0301MB15517DD9BF2570136FFD312EB2760SN1PR0301MB1551_ Content-Type: text/html; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable

There are broadly two different categories of behavior when it comes to = standards organizations/specifications:


i- Standards, which define the actual protocol mechanics, e.g. on the wi= re messages, negotiation procedures between peers. These are essential for = different elements to communicate and "do the right thing".


ii- Profiles, which usually specify a subset of the whole functionality = defined in i- as a functionality set to be used in a particular deployment = environment.


I think IETF in general is more interested in i-. Defining what a "= WebRTC GW" is and how it can use/omit certain core functionalities doe= s not fall into this category.


Just as an example, let's take the example of se of public IP Addre= sses: If the actual standard allows use of ICE-lite, it is up to an impleme= nter to build a box with only ICE-lite support if it is going to be used ex= clusively in an environment where it will be assigned a public IP Address. This does not require "standard= ization" AFAICS. So, I don't think a document like GW-draft is really = much useful and should be "Informational", if it should exist at = all.


Admittedly, the issue of rtcp-mux is a bit more grey. In running code we= trust and several parties indicated that supporting DTLS-SRTP with full&nb= sp;rtcp-mux negotiation support is a pain in the neck. Actually even here o= ne could take a more "this is not a core protocol issue" approach. If all browsers support only rtcp-mux and d= o not interoperate with elements which do not support it, well that would b= e just it. Any such other entity either would not be able to communicate wi= th the browsers and realize its mistake or it won't care about it at all as it is designed to be deployed in a non= -browser environment. I understand that this is perceived as having a = detrimental effect on practical interoperability but I am not sure whe= ther a core protocol level mandate of forbidding no-rtcp-mux is justified. When it comes to browser-to-non browser entity c= ommunication, I think the cards are stacked very heavily in favor of browse= rs for such functionality mismatches. In other words, whatever browsers do = would be the "de facto Internet Profile". 


Thanks,

Tolga



From: Christer Holmberg <= ;christer.holmberg@ericsson.com>
Sent: Tuesday, August 4, 2015 10:30 AM
To: Asveren, Tolga; Bernard Aboba
Cc: Roman Shpount; Eric Rescorla; Schwarz, Albrecht (Albrecht); Raus= chenbach, Uwe (Nokia - DE/Munich); <rtcweb@ietf.org>
Subject: RE: [rtcweb] What the gateway draft should say about mux/no= n-mux
 

Hi,

 

> These are just some *assumptions*. There are= /will be gateways deployed with no public IP Addresses. Similarly what is &= quot;on the other side" of the gateway is/will be varied as well.

> 

> If one goes into the guessing game, it can b= e argued that "A gateway potentially may be deployed with only endpoin= ts supporting x/y/z etc..". There could be many such combinations.

> 

> In the light of this, I really don't see a p= oint for the GW draft, especially after seeing that folks have the vie= w that it should fully interoperate with a "vanilla WebRTC endpoint&qu= ot;. That pretty

&= gt; much means that a GW itself a WebRTC endpoin= t and there is nothing else to specify from RTCWeb WG perspective (and henc= e there is even no need to define an entity as "WebRTC GW").

&= nbsp;

A= s has been said, a WebRTC GW differs from a vanilla WebRTC endpoint e.g. in= that it can be ICE-lite and that it is not mandated to send consent refresh requests. However, that doesn=92t prevent it from fully in= teroperating with a vanilla endpoint.

&= nbsp;

R= egards,

&= nbsp;

C= hrister

&= nbsp;

 

From: Bernard Aboba <bernard.aboba@gmail.com>
Sent: Tuesday, August 4, 2015 1:05 AM
To: Asveren, Tolga
Cc: Roman Shpount; Eric Rescorla; Schwarz, Albrecht (Albrecht); Raus= chenbach, Uwe (Nokia - DE/Munich); Christer Holmberg; <rtcweb@ietf.org= >
Subject: Re: [rtcweb] What the gateway draft should say about mux/no= n-mux

 

As Roman said, gateways have only slightly different requirements = on the WEBRTC side due to potential ability to use a Public IP address, all= owing use of ICE-LITE.  Requirements on the other side depend on what the legacy endpoint is. The lowest legacy endpoint is one w= ith IPv4, g.711, RTP/AVP or perhaps RTP/SAVP, no ICE, maybe no RTCP. <= /span>


On Aug 3, 2015, at 16:57, Asveren, Tolga <tasveren@sonu= snet.com> wrote:

Well, the same would apply to a WebR= TC-endpoint, which is deployed with a public IP. Why invent a new term as G= W? These are just choices based on deployment model.

 

And who said there are universal gua= rantees that GWs will be deployed with routable IP Addresses? Again, deploy= ment choices are best left unspecified.

 

Thanks,

Tolga

 

From: R= oman Shpount <roman@telurix.com>
Sent: Monday, August 3, 2015 7:39 PM
To: Asveren, Tolga
Cc: Bernard Aboba; Eric Rescorla; Schwarz, Albrecht (Albrecht); Raus= chenbach, Uwe (Nokia - DE/Munich); Christer Holmberg; <rtcweb= @ietf.org>
Subject: Re: [rtcweb] What the gateway draft should say about mux/no= n-mux

 

On Mon, Aug 3, 2015 at 7:21 PM, Asveren, Tolga <tasveren@sonusnet.com> wrote:

With this interpretation, is there r= eally a raison d'=EAtre for the GW draft? One just could view it as an enti= ty with one side facing WebRTC universe as a "full WebRTC endpoint". Honestly, that would make life easier rather than muddying= the water with what a GW should/must/may do. 

GW is different from the "full WebRTC endpoint" since it= would typically be placed on public IP. This allows for slightly different= requirements. For instance gateway can be ICE-lite instead of full ICE required by WebRTC end point.

 

Regards,

_____________
Roman Shpount

 

--_000_SN1PR0301MB15517DD9BF2570136FFD312EB2760SN1PR0301MB1551_-- From nobody Tue Aug 4 16:33:45 2015 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7BBC51AD0D6 for ; Tue, 4 Aug 2015 16:33:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.978 X-Spam-Level: X-Spam-Status: No, score=-1.978 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, 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 mg-tpfaW0g5M for ; Tue, 4 Aug 2015 16:33:43 -0700 (PDT) Received: from mail-ig0-f172.google.com (mail-ig0-f172.google.com [209.85.213.172]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 448801ACED5 for ; Tue, 4 Aug 2015 16:33:42 -0700 (PDT) Received: by igbij6 with SMTP id ij6so84787640igb.1 for ; Tue, 04 Aug 2015 16:33:41 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=/XOnWirV8W2tVeu+E2ArJ13NAzsU4zU1K1z3sF05FJg=; b=hC61qrxbHNt4079n//+BNZTms8a8Cd4SZKZTEhDerSDtWcUlXizlwPGUckpNXjROkn 6DNq/M+VcvD0LTwcgzm5v1S3COcHEB+yv5+vf3fqGQau83JJ7GjGxm3dU7OKhsOq4yKJ wIJ+Mo5jrznE2j9MwnGksNNp2MkL3omfvN4j7d4byLwkjC4vSwzNajwya2Vmzwu+lbYi mV9kailavZt1U30k0WvLFhj95EIStK0FmpY2s+OXij6+dR4rG91nhQQo/hibrmUAgdl8 VE3fEmPXYmXyuDYSNUFOXsenCPJiKmdP21Gcvf1HtawSjtC7H4KCuDzbXRqE3VQhp3q/ 2RFQ== X-Gm-Message-State: ALoCoQkeFF9EineUxvp5/VlKJVCutEbk9K7CWA42lbUCsXA9dia/t2DtSph5KmpTTRi2w/o8w/dq X-Received: by 10.50.62.243 with SMTP id b19mr7359843igs.88.1438731221698; Tue, 04 Aug 2015 16:33:41 -0700 (PDT) Received: from mail-ig0-f171.google.com (mail-ig0-f171.google.com. [209.85.213.171]) by smtp.gmail.com with ESMTPSA id n6sm2263545igv.17.2015.08.04.16.33.40 for (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 04 Aug 2015 16:33:40 -0700 (PDT) Received: by iggf3 with SMTP id f3so22046284igg.1 for ; Tue, 04 Aug 2015 16:33:40 -0700 (PDT) MIME-Version: 1.0 X-Received: by 10.50.138.193 with SMTP id qs1mr7410885igb.2.1438731220122; Tue, 04 Aug 2015 16:33:40 -0700 (PDT) Received: by 10.36.89.70 with HTTP; Tue, 4 Aug 2015 16:33:40 -0700 (PDT) In-Reply-To: References: <7594FB04B1934943A5C02806D1A2204B348E82CA@ESESSMB209.ericsson.se> Date: Tue, 4 Aug 2015 19:33:40 -0400 Message-ID: From: Roman Shpount To: "Asveren, Tolga" Content-Type: multipart/alternative; boundary=089e0122a5b84d865a051c84b741 Archived-At: Cc: "" Subject: Re: [rtcweb] What the gateway draft should say about mux/non-mux X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 04 Aug 2015 23:33:44 -0000 --089e0122a5b84d865a051c84b741 Content-Type: text/plain; charset=UTF-8 On Tue, Aug 4, 2015 at 7:24 PM, Asveren, Tolga wrote: > In running code we trust and several parties indicated that supporting > DTLS-SRTP with full rtcp-mux negotiation support is a pain in the neck. > Did you mean to say "*supporting **DTLS-SRTP without rtcp-mux is a pain in the neck*"? Most of the people implement this wrong, since you need to create two DTLS sessions: one for RTP and another for RTCP. And then use different keys or possibly even encryption profiles for RTP and RTCP. I commonly see one session for RTP and keys negotiated there used for both RTP and RTCP, which is wrong. _____________ Roman Shpount --089e0122a5b84d865a051c84b741 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On T= ue, Aug 4, 2015 at 7:24 PM, Asveren, Tolga <tasveren@sonusnet.com&= gt; wrote:

In running code we trust and several part= ies indicated that supporting DTLS-SRTP with full=C2=A0rtcp-mux negotiation= support is a pain in the neck.=C2=A0

Did you mean to say "supporting=C2=A0= DTLS-SRTP without rtcp-mux is a pain in the neck"?

Most of the= people implement this wrong, since you need to create two DTLS sessions: o= ne for RTP and another for RTCP. And then use different keys or possibly ev= en encryption profiles for RTP and RTCP. I commonly see one session for RTP= and keys negotiated there used for both RTP and RTCP, which is wrong.
_____________
Roman Shpount<= /div>
=C2=A0
--089e0122a5b84d865a051c84b741-- From nobody Tue Aug 4 16:43:28 2015 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EF5EA1AD362 for ; Tue, 4 Aug 2015 16:43:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, SPF_HELO_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GiXUJlb6ATqE for ; Tue, 4 Aug 2015 16:43:25 -0700 (PDT) Received: from na01-bn1-obe.outbound.protection.outlook.com (mail-bn1on0615.outbound.protection.outlook.com [IPv6:2a01:111:f400:fc10::615]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D7C431AD35C for ; Tue, 4 Aug 2015 16:43:24 -0700 (PDT) Received: from SN1PR0301MB1550.namprd03.prod.outlook.com (10.162.129.156) by SN1PR0301MB1629.namprd03.prod.outlook.com (10.162.130.27) with Microsoft SMTP Server (TLS) id 15.1.225.19; Tue, 4 Aug 2015 23:43:15 +0000 Received: from SN1PR0301MB1551.namprd03.prod.outlook.com (10.162.129.157) by SN1PR0301MB1550.namprd03.prod.outlook.com (10.162.129.156) with Microsoft SMTP Server (TLS) id 15.1.225.19; Tue, 4 Aug 2015 23:43:13 +0000 Received: from SN1PR0301MB1551.namprd03.prod.outlook.com ([10.162.129.157]) by SN1PR0301MB1551.namprd03.prod.outlook.com ([10.162.129.157]) with mapi id 15.01.0225.018; Tue, 4 Aug 2015 23:43:13 +0000 From: "Asveren, Tolga" To: Roman Shpount Thread-Topic: [rtcweb] What the gateway draft should say about mux/non-mux Thread-Index: AQHQy8DcUgzWwtVCmk+8q67BCzjC45316kQQgAAD5oCAAACVsIAAAj2AgAPw2gCAAEFTAIAARmyAgAAi5WCAABbtAIAASnwUgAAF9wCAAARia4AAVoWAgAA8di6AAGF3AIAAj4WzgAAIRwCAAAFEvw== Date: Tue, 4 Aug 2015 23:43:13 +0000 Message-ID: References: <7594FB04B1934943A5C02806D1A2204B348E82CA@ESESSMB209.ericsson.se> , In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=tasveren@sonusnet.com; x-originating-ip: [50.182.164.80] x-microsoft-exchange-diagnostics: 1; SN1PR0301MB1550; 5:r3YIChmGxpe35HtH8uOVzStZ8RQMFBQ1D0iyn/4sy2B5f7dqntseylQ8RTmffAdyHNAWIJWBo4kV1W5k58NcR7cthTSUsCNLe+9Z9+IHwovpgwajS/rNBNNn1w1oB+i3yYqXdvnND60oTqUYZtslfA==; 24:Wtzafer2HAHPPP/TeydEt4KiNh6D+lCyFiZhHnOc/guSAnazno7Mu2GqLHlp2Ul0RLXhrDBEjn4bQRVJGST0L1VmkCCYruUR9OVxfKezEt8=; 20:x74gTPNAaMbz71sjKQetyfD7wgt5fmyqVkJ+tJ9oNQiM1yPznKM3+B/iZYO4xj7w3VwbREBPtFg/vwxo2Y49AA== x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:; SRVR:SN1PR0301MB1550; UriScan:; BCL:0; PCL:0; RULEID:; SRVR:SN1PR0301MB1629; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:; x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(601004)(5005006)(3002001); SRVR:SN1PR0301MB1550; BCL:0; PCL:0; RULEID:; SRVR:SN1PR0301MB1550; x-forefront-prvs: 0658BAF71F x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(51914003)(24454002)(199003)(189002)(164054003)(377454003)(62966003)(189998001)(50986999)(19627405001)(86362001)(46102003)(105586002)(77156002)(106356001)(99286002)(106116001)(19580395003)(93886004)(110136002)(2656002)(87936001)(40100003)(101416001)(122556002)(19625215002)(16236675004)(66066001)(5002640100001)(76176999)(5001960100002)(92566002)(2900100001)(5001860100001)(5001920100001)(68736005)(5001830100001)(2950100001)(33656002)(5003600100002)(77096005)(97736004)(64706001)(81156007)(4001540100001)(76576001)(74316001)(10400500002)(102836002)(19580405001)(54356999); DIR:OUT; SFP:1101; SCL:1; SRVR:SN1PR0301MB1550; H:SN1PR0301MB1551.namprd03.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; A:1; MX:1; LANG:en; received-spf: None (protection.outlook.com: sonusnet.com does not designate permitted sender hosts) Content-Type: multipart/alternative; boundary="_000_SN1PR0301MB15513E7BCA760872760C1D88B2760SN1PR0301MB1551_" MIME-Version: 1.0 X-MS-Exchange-CrossTenant-originalarrivaltime: 04 Aug 2015 23:43:13.4609 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 29a671dc-ed7e-4a54-b1e5-8da1eb495dc3 X-MS-Exchange-Transport-CrossTenantHeadersStamped: SN1PR0301MB1550 X-Microsoft-Exchange-Diagnostics: 1; SN1PR0301MB1629; 2:24ysWKH7un9FEsnFkdhwXkdO4oKXmH/mXIrx3/TA4DDaP4KmHqu5CJjYFxAK89rPa4OgFgOEFBJI6h9oTxc2eKfRFbkYci8onbEa/t+q7O/Rznnxs8FYr2bUIuFYK2k9BXCAfVf+p20zIs6X6lntn8Cht22TtQUoWW8Ai0t8Fik=; 3:9yTQQVOwv5KWXdVeFYn9OniTODBjL1Dz6+HZ6wEuObXM30s/5fboGa0FgVilF5YNCzB91t14dhq/lQlrQYKpFbJsPVZH4jGXUJVo28q6HwaQ7gpwSu078p6zjqAaDxpCKiu8HumRrLzUZsDUek9sfQ==; 25:GWEmsA/pFc4sKPMV/GyWA1a4VGE9VUCZotvc9zAaOdIzgrvt6+PmiuFQIAmmdWHxFgTeNtvIJhejuwOKl49Rqmzjh8nCc5sqkuunTobOtIbyeHnEyTwOKAIUnjWoL6R4RcGINPX9rV8RYg27mODTMxJy4vO3QkeMZS+tpKR/aEFUBEmDUTbCKCgTO7rjRMGMOtCNFtsPWCsYGc57mB/Qy/ny5D2aFQywySd6QE1kiChqeWjQGrLqbC5CAWJYQMmM8QyqIzJ9yGNExJnm9DpUlg==; 23:uNO9SW48lyxqZ1RCokkclt9ZPK9t+Q4mfIX0aBR+Hm3qupdtLqKNbRS4VWF1SQtKcZhZvoPe6nbeqMatpYAZfZk+QKjgXQDckLI5IRAeGIb2xEyxvtg/8R3X90qippNgwj3arnhJayU/7TFvo+Jz6e1yGDRE46S241mybHp9x7F3EbIbDM/EIc2CfGcy8b3lLt5GNoGjMt2K1v62eqod/MZURFHTaojxoKqAtnxdm0ZKKptdfghmQu4R1redGGjl X-OriginatorOrg: sonusnet.com Archived-At: Cc: "" Subject: Re: [rtcweb] What the gateway draft should say about mux/non-mux X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 04 Aug 2015 23:43:27 -0000 --_000_SN1PR0301MB15513E7BCA760872760C1D88B2760SN1PR0301MB1551_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Mea culpa, yes, thanks for the correction. Again, my opinion (actually more than an opinion, it is an observation) is = that whatever browsers do is followed/implemented by other entities if they= are expected to interface with them -even to the level of specification vi= olations-. So, the notion of "de facto Internet Profile" seems to be workin= g pretty efficiently. Thanks, Tolga ________________________________ From: Roman Shpount Sent: Tuesday, August 4, 2015 7:33 PM To: Asveren, Tolga Cc: Christer Holmberg; Bernard Aboba; Eric Rescorla; Schwarz, Albrecht (Alb= recht); Rauschenbach, Uwe (Nokia - DE/Munich); Subject: Re: [rtcweb] What the gateway draft should say about mux/non-mux On Tue, Aug 4, 2015 at 7:24 PM, Asveren, Tolga > wrote: In running code we trust and several parties indicated that supporting DTLS= -SRTP with full rtcp-mux negotiation support is a pain in the neck. Did you mean to say "supporting DTLS-SRTP without rtcp-mux is a pain in the= neck"? Most of the people implement this wrong, since you need to create two DTLS = sessions: one for RTP and another for RTCP. And then use different keys or = possibly even encryption profiles for RTP and RTCP. I commonly see one sess= ion for RTP and keys negotiated there used for both RTP and RTCP, which is = wrong. _____________ Roman Shpount --_000_SN1PR0301MB15513E7BCA760872760C1D88B2760SN1PR0301MB1551_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

Mea culpa, yes, thanks for the correction.


Again, my opinion (actually more than an opinion, it is an observation) = is that whatever browsers do is followed/implemented by other entities if t= hey are expected to interface with them -even to the level of spe= cification violations-. So, the notion of "de facto Internet Profile" seems to be working pretty efficient= ly.


Thanks,

Tolga



From: Roman Shpount <rom= an@telurix.com>
Sent: Tuesday, August 4, 2015 7:33 PM
To: Asveren, Tolga
Cc: Christer Holmberg; Bernard Aboba; Eric Rescorla; Schwarz, Albrec= ht (Albrecht); Rauschenbach, Uwe (Nokia - DE/Munich); <rtcweb@ietf.org&g= t;
Subject: Re: [rtcweb] What the gateway draft should say about mux/no= n-mux
 
On Tue, Aug 4, 2015 at 7:24 PM, Asveren, Tolga <= span dir=3D"ltr"> <tasveren@son= usnet.com> wrote:

In running code we trust and several part= ies indicated that supporting DTLS-SRTP with full rtcp-mux negotiation= support is a pain in the neck. 

Did you mean to say "supporting DTLS-SRTP without rtcp-mux is a pain in the neck"?

Most of the people implement this wrong, since y= ou need to create two DTLS sessions: one for RTP and another for RTCP. And = then use different keys or possibly even encryption profiles for RTP and RTCP. I commonly see one session for = RTP and keys negotiated there used for both RTP and RTCP, which is wrong.
_____________
Roman Shpount
 
--_000_SN1PR0301MB15513E7BCA760872760C1D88B2760SN1PR0301MB1551_-- From nobody Tue Aug 4 16:53:16 2015 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B261F1B29D7; Tue, 4 Aug 2015 16:53:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GadU8n-qhvAo; Tue, 4 Aug 2015 16:53:07 -0700 (PDT) Received: from na01-bn1-obe.outbound.protection.outlook.com (mail-bn1bon0740.outbound.protection.outlook.com [IPv6:2a01:111:f400:fc10::1:740]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8FD2A1B29C9; Tue, 4 Aug 2015 16:52:57 -0700 (PDT) Received: from BL2PR03MB290.namprd03.prod.outlook.com (10.141.68.19) by BL2PR03MB292.namprd03.prod.outlook.com (10.141.68.28) with Microsoft SMTP Server (TLS) id 15.1.225.19; Tue, 4 Aug 2015 23:52:35 +0000 Received: from BL2PR03MB290.namprd03.prod.outlook.com ([10.141.68.19]) by BL2PR03MB290.namprd03.prod.outlook.com ([10.141.68.19]) with mapi id 15.01.0225.018; Tue, 4 Aug 2015 23:52:35 +0000 From: "Orit Levin (LCA)" To: Ted Hardie Thread-Topic: [rtcweb] [appsdir] Fwd: Request for Apps Directorate review of rtcweb-security drafts Thread-Index: AQHQr4DcT2qcK6DgvkiqLOtwc4J9zZ29oujwgBRIQaCACXjGAIAfyB6QgAEd44CAAFuUQIAAEp2AgAAKBMA= Date: Tue, 4 Aug 2015 23:52:35 +0000 Message-ID: References: <558C4C02.3000404@cisco.com> <558C5CA3.7020108@cisco.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=oritl@microsoft.com; x-originating-ip: [2001:4898:80e8:5::735] x-microsoft-exchange-diagnostics: 1; BL2PR03MB292; 5:KYCHL/bX6rpEyWOQ1uILpMyQ/HaaWGwwptIiMPBxbUrjlMqRM0OzmddFWEJqzvST3N7MchOEITiOYAu/Zq4P4VhM6UR0W0um87ZkkR1OLWUx/zdTMOJUUy4R4uGZG+SmnzvW5k9pFlywaxLam/k/WQ==; 24:a1Vd5GE35oHhw353wpxeSu1oFEyrMQtcRceFaGPo8I5Y/Vx6Zh7GLECdZQoredFhxxv0IxYBJD5+4ntACJGY5PXbxN4mPzFzCPtDYtLHaCM=; 20:K58uOrSJWAxrObeREbpfLf4HNTLp/pZdYtUi1YrlVn4e5UfJNybWGoabHbsjvpt4qoqcmp2cxNOEMUOkXT2v8w== x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:BL2PR03MB292; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(108003899814671); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(601004)(2401001)(5005006)(3002001); SRVR:BL2PR03MB292; BCL:0; PCL:0; RULEID:; SRVR:BL2PR03MB292; x-forefront-prvs: 0658BAF71F x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(51914003)(24454002)(377454003)(199003)(189002)(164054003)(479174004)(2473001)(13464003)(50986999)(54356999)(101416001)(87936001)(46102003)(19617315012)(76176999)(106356001)(2656002)(105586002)(81156007)(10090500001)(10400500002)(86362001)(5005710100001)(92566002)(2420400006)(106116001)(5001860100001)(5003600100002)(19580405001)(189998001)(97736004)(74316001)(4001540100001)(110136002)(86612001)(7110500001)(19580395003)(5002640100001)(5001960100002)(19300405004)(99286002)(40100003)(5001830100001)(62966003)(15975445007)(122556002)(76576001)(102836002)(33656002)(77156002)(93886004)(2950100001)(2900100001)(77096005)(64706001)(19625215002)(16236675004)(68736005)(10290500002)(3826002)(579004)(559001); DIR:OUT; SFP:1102; SCL:1; SRVR:BL2PR03MB292; H:BL2PR03MB290.namprd03.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; A:1; MX:1; LANG:en; received-spf: None (protection.outlook.com: microsoft.com does not designate permitted sender hosts) Content-Type: multipart/alternative; boundary="_000_BL2PR03MB29088098BC3FA25C9D24AC2AD760BL2PR03MB290namprd_" MIME-Version: 1.0 X-OriginatorOrg: microsoft.com X-MS-Exchange-CrossTenant-originalarrivaltime: 04 Aug 2015 23:52:35.1746 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 72f988bf-86f1-41af-91ab-2d7cd011db47 X-MS-Exchange-Transport-CrossTenantHeadersStamped: BL2PR03MB292 Archived-At: Cc: "appsdir@ietf.org" , "rtcweb@ietf.org" , Eliot Lear Subject: Re: [rtcweb] [appsdir] Fwd: Request for Apps Directorate review of rtcweb-security drafts X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 04 Aug 2015 23:53:12 -0000 --_000_BL2PR03MB29088098BC3FA25C9D24AC2AD760BL2PR03MB290namprd_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 VGhhbmtzIQ0KT3JpdC4NCg0KRnJvbTogVGVkIEhhcmRpZSBbbWFpbHRvOnRlZC5pZXRmQGdtYWls LmNvbV0NClNlbnQ6IFR1ZXNkYXksIEF1Z3VzdCAwNCwgMjAxNSA0OjE2IFBNDQpUbzogT3JpdCBM ZXZpbiAoTENBKSA8b3JpdGxAbWljcm9zb2Z0LmNvbT4NCkNjOiBFcmljIFJlc2NvcmxhIDxla3JA cnRmbS5jb20+OyBydGN3ZWJAaWV0Zi5vcmc7IGFwcHNkaXJAaWV0Zi5vcmc7IEVsaW90IExlYXIg PGxlYXJAY2lzY28uY29tPg0KU3ViamVjdDogUmU6IFtydGN3ZWJdIFthcHBzZGlyXSBGd2Q6IFJl cXVlc3QgZm9yIEFwcHMgRGlyZWN0b3JhdGUgcmV2aWV3IG9mIHJ0Y3dlYi1zZWN1cml0eSBkcmFm dHMNCg0KT24gVHVlLCBBdWcgNCwgMjAxNSBhdCAzOjMwIFBNLCBPcml0IExldmluIChMQ0EpIDxv cml0bEBtaWNyb3NvZnQuY29tPG1haWx0bzpvcml0bEBtaWNyb3NvZnQuY29tPj4gd3JvdGU6DQpU aGFua3MsIEVrciEgTG9va2luZyBmb3J3YXJkIHRvIHJlYWRpbmcgdGhlIG5leHQgdmVyc2lvbiBv ZiB0aGUgZHJhZnRzLg0KV2hlbmV2ZXIgaXQgd29ya3MgYmVzdCBmb3IgeW91LCBjb3VsZCB5b3Us IHBsZWFzZSwgcmVwbHkgdG8gdGhlIG9yaWdpbmFsIGVtYWlsIHNob3dpbmcgaW5saW5lIGhvdyBl YWNoIGNvbW1lbnQgZ290IGFkZHJlc3NlZD8gVGhhdCB3b3VsZCBoZWxwIGEgbG90Lg0KQ2hlZXJz LA0KT3JpdC4NCg0KDQrigItIaSBPcml0LA0KSSB0aGluayBvdXIgYWltIGlzIHRvIGRlc2NyaWJl IGhvdyBjb21tZW50cyB3ZXJlIGFkZHJlc3NlZCBpbiB0aGUgc2hlcGhlcmQgd3JpdGUtdXA7IEkn bGwgdGFrZSB0aGUgYWN0aW9uIGl0ZW0gdG8gbWFrZSBzdXJlIHlvdSBnZXQgYSBjb3B5Lg0KVGVk 4oCLDQoNCg0KDQpGcm9tOiBFcmljIFJlc2NvcmxhIFttYWlsdG86ZWtyQHJ0Zm0uY29tPG1haWx0 bzpla3JAcnRmbS5jb20+XQ0KU2VudDogVHVlc2RheSwgQXVndXN0IDA0LCAyMDE1IDk6NDIgQU0N ClRvOiBPcml0IExldmluIChMQ0EpIDxvcml0bEBtaWNyb3NvZnQuY29tPG1haWx0bzpvcml0bEBt aWNyb3NvZnQuY29tPj4NCkNjOiBUZWQgSGFyZGllIDx0ZWQuaWV0ZkBnbWFpbC5jb208bWFpbHRv OnRlZC5pZXRmQGdtYWlsLmNvbT4+OyBydGN3ZWJAaWV0Zi5vcmc8bWFpbHRvOnJ0Y3dlYkBpZXRm Lm9yZz47IGFwcHNkaXJAaWV0Zi5vcmc8bWFpbHRvOmFwcHNkaXJAaWV0Zi5vcmc+OyBFbGlvdCBM ZWFyIDxsZWFyQGNpc2NvLmNvbTxtYWlsdG86bGVhckBjaXNjby5jb20+Pg0KU3ViamVjdDogUmU6 IFtydGN3ZWJdIFthcHBzZGlyXSBGd2Q6IFJlcXVlc3QgZm9yIEFwcHMgRGlyZWN0b3JhdGUgcmV2 aWV3IG9mIHJ0Y3dlYi1zZWN1cml0eSBkcmFmdHMNCg0KSSdsbCBiZSBoYW5kbGluZyB0aGlzIGFs b25nIHdpdGggdGhlIHJlc3Qgb2YgdGhlIHJldmlldyBjb21tZW50cyBJIGhhdmUgcmVjZWl2ZWQs DQphdCB0aGUgbmV4dCBkcmFmdCB1cGRhdGUgKHByb2JhYmx5IGJlZm9yZSB0aGUgbmV4dCBSVENX RUIvV2ViUlRDIGludGVyaW0pDQpidXQgSSBkb24ndCBoYXZlIGEgc3BlY2lmaWMgRVRBLg0KDQot RWtyDQoNCg0KDQpPbiBNb24sIEF1ZyAzLCAyMDE1IGF0IDQ6NDMgUE0sIE9yaXQgTGV2aW4gKExD QSkgPG9yaXRsQG1pY3Jvc29mdC5jb208bWFpbHRvOm9yaXRsQG1pY3Jvc29mdC5jb20+PiB3cm90 ZToNCkhpIGd1eXMsDQpUaHJlZSBidXN5IHdlZWtzIGFuZCBhbiBJRVRGIG1lZXRpbmcgaGF2ZSBw YXN04oCmIFdoZW4gc2hvdWxkIHdlIGV4cGVjdCB0byBzZWUgdGhlIGZlZWRiYWNrIHRvIHRoZSBy ZXZpZXc/DQpUaGFua3MgYW5kIGNoZWVycywNCk9yaXQuDQoNCkZyb206IFRlZCBIYXJkaWUgW21h aWx0bzp0ZWQuaWV0ZkBnbWFpbC5jb208bWFpbHRvOnRlZC5pZXRmQGdtYWlsLmNvbT5dDQpTZW50 OiBUdWVzZGF5LCBKdWx5IDE0LCAyMDE1IDExOjE4IEFNDQpUbzogT3JpdCBMZXZpbiAoTENBKSA8 b3JpdGxAbWljcm9zb2Z0LmNvbTxtYWlsdG86b3JpdGxAbWljcm9zb2Z0LmNvbT4+OyBydGN3ZWJA aWV0Zi5vcmc8bWFpbHRvOnJ0Y3dlYkBpZXRmLm9yZz4NCkNjOiBFbGlvdCBMZWFyIDxsZWFyQGNp c2NvLmNvbTxtYWlsdG86bGVhckBjaXNjby5jb20+PjsgYXBwc2RpckBpZXRmLm9yZzxtYWlsdG86 YXBwc2RpckBpZXRmLm9yZz4NCg0KU3ViamVjdDogUmU6IFthcHBzZGlyXSBGd2Q6IFJlcXVlc3Qg Zm9yIEFwcHMgRGlyZWN0b3JhdGUgcmV2aWV3IG9mIHJ0Y3dlYi1zZWN1cml0eSBkcmFmdHMNCg0K KGFkZGluZyB0aGUgV0cpDQpIaSBPcml0LA0KVGhhbmtzIGZvciB0aGUgcmV2aWV3Lg0KcmVnYXJk cywNClRlZCBIYXJkaWUNCg0KT24gVHVlLCBKdWwgMTQsIDIwMTUgYXQgMTE6MDcgQU0sIE9yaXQg TGV2aW4gKExDQSkgPG9yaXRsQG1pY3Jvc29mdC5jb208bWFpbHRvOm9yaXRsQG1pY3Jvc29mdC5j b20+PiB3cm90ZToNCkRpc2NsYWltZXI6IEkgYW0gZmFtaWxpYXIgd2l0aCBSVEMgYW5kIFdlYlJU QywgYnV0IEkgaGF2ZW4ndCBmb2xsb3dlZCB0aGUgUlRDV2ViIHdvcmsgaW4gdGhlIGxhc3QgZmV3 IHllYXJzLiBJIHJlYWQgdGhlIHR3byBkcmFmdHMgZm9yIHRoZSBmaXJzdCB0aW1lLg0KVGhlcmVm b3JlLCBteSBhcG9sb2dpZXMgZm9yIHBvdGVudGlhbGx5IHJhaXNpbmcgcG9pbnRzIHRoYXQgaGF2 ZSBiZWVuIGRpc2N1c3NlZCBpbiB0aGUgcGFzdC4NCg0KPkZyb20gdGhlIEFQUCAob3IgQVJUKSBy ZXZpZXcgcGVyc3BlY3RpdmUsIG15IG1haW4gY29tbWVudCBpcyBvbiB0aGUgdG9waWMgb2YgIldl Yi1CYXNlZCBQZWVyIEF1dGhlbnRpY2F0aW9uIi4gV2hpbGUgaXQgaXMgbm90IGNsZWFyIGZyb20g dGhlIHRleHQsIHdoaWNoIHBhcnRzIGFyZSBhbHJlYWR5IHN0YW5kYXJkaXplZCBjb25jZXB0cyAo ZS5nLiwgYnkgVzNDKSBhbmQgd2hpY2ggYXJlIGludHJvZHVjZWQgaGVyZSBmb3IgdGhlIGZpcnN0 IHRpbWUsIHRoZSBkZXNjcmliZWQgYXBwcm9hY2ggc2VlbXMgdG8gYmUgKDEpIHVzZWZ1bCB0byB3 ZWIgYXBwbGljYXRpb25zIGJleW9uZCBXZWJSVEMsICgyKSB1bmRlciBkZXZlbG9wbWVudCBhbmQg dGh1cyBwcm9iYWJseSBub3Qgc3RhYmxlLCBhbmQgKDMpIHRvbyBkZXRhaWxlZCBmb3IgImFuIGFy Y2hpdGVjdHVyZSIgZG9jdW1lbnQuICBBcyBzdWNoLCB0aGUgY29uY2VwdCBvZiAiIFdlYi1CYXNl ZCBQZWVyIEF1dGhlbnRpY2F0aW9uIiBwcm9iYWJseSBuZWVkcyB0byBiZSBpbnRyb2R1Y2VkIGFu ZCBzdGFuZGFyZGl6ZWQgdW5kZXIgdGhlIFNlY3VyaXR5IEFyZWEgYW5kIHRoZW4gYWRvcHRlZCBi eSBXZWJSVEMgYW5kIG90aGVyIGFwcHMuDQoNCmh0dHBzOi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcv ZG9jL2RyYWZ0LWlldGYtcnRjd2ViLXNlY3VyaXR5Lw0KVGhpcyBkb2N1bWVudCBjb250YWlucyBh biBleGNlbGxlbnQgY29sbGVjdGlvbiBvZiBzZWN1cml0eSB0aHJlYXRzIHRvIFdlYlJUQyBhbmQg ZGlzY3Vzc2VzIG1hbnkgZGlmZmVyZW50IGlkZWFzIGZvciB0aGVpciBwb3RlbnRpYWwgbWl0aWdh dGlvbi4gVGhhdCBiZWluZyBzYWlkLCBpdCBpcyBub3QgYW4gZWFzeSByZWFkLiBTcGVjaWZpY2Fs bHksIGZyb20gaGlnaCBsZXZlbCB0byBtb3JlIHNwZWNpZmljOg0KMS4gVGhlIGludGVuZGVkIHN0 YXR1cyBvZiB0aGUgZG9jdW1lbnQgaXMgU3RhbmRhcmRzIFRyYWNrLCB3aGlsZSBhIHR5cGljYWwg c3RhdHVzIG9mIGEgInNlY3VyaXR5IHRocmVhdCBtb2RlbCIgUkZDIGlzIEluZm9ybWF0aW9uYWwu IFRoaXMgZGlzY3JlcGFuY3kgcHJvYmFibHkgbGllcyBpbiB0aGUgY3VycmVudCBzY29wZSBvZiB0 aGUgZG9jdW1lbnQuIFNlZSB0aGUgbmV4dCBjb21tZW50IGJlbG93Lg0KMi4gVGhlIHNjb3BlIG9m IHRoZSBkb2N1bWVudCBpcyBub3QgY2xlYXIuIEluIGFkZGl0aW9uIHRvIGRlc2NyaWJpbmcgdGhl IHNlY3VyaXR5IHRocmVhdHMgKGFuZCB0aGUgcmVxdWlyZW1lbnRzIG9yIHVzZXIgZXhwZWN0YXRp b25zIHJlbGF0ZWQgdG8gdGhlaXIgcHJldmVudGlvbiksIGluIG1hbnkgcGxhY2VzIHRoZSBkb2N1 bWVudCBsaXN0cyBwb3RlbnRpYWwgc29sdXRpb25zIHdpdGggdGhlaXIgcGVyY2VpdmVkIGxpbWl0 YXRpb25zIGFuZC9vciBhcHBsaWNhYmlsaXR5LiBFeGFtcGxlcyBhcmUgc2VjdGlvbnM6IDQuMi4x LCA0LjIuMiwgNC4yLjMsIDQuMi40LCA0LjMuMi4xLCA0LjMuMi4yLCA0LjMuMi4zLiBUbyBpbXBy b3ZlIHRoZSBkb2N1bWVudCdzIHJlYWRhYmlsaXR5IGFuZCByZWR1Y2Ugb3ZlcmxhcHMsICB0aGUg c29sdXRpb25zIHNob3VsZCBiZSBpbnRyb2R1Y2VkIGFuZCBleHBsYWluZWQgaW4gdGhlIGNvbXBh bmlvbiAiYXJjaGl0ZWN0dXJlIiBkb2N1bWVudC4gU29sdXRpb25zJyBhcHBsaWNhYmlsaXR5IHRv IGRpZmZlcmVudCB1c2UgY2FzZXMgbmVlZHMgdG8gYmUgcHJvdmlkZWQgaW4gYSBub24tYmlhcyB3 YXkuDQozLiBBcGFydCBmcm9tIHRoZSBicmllZiBJbnRyb2R1Y3Rpb24gd2l0aCBhIGZldyBleGFt cGxlcywgdGhlcmUgaXMgbm8gZGVzY3JpcHRpb24gb2YgdGhlIFdlYlJUQyB0aHJlYXQgbW9kZWwg cHV0dGluZyBhbGwgbWFpbiB0eXBlcyBvZiB0aHJlYXQgaW4gb25lIHBsYWNlLiBGb3IgZXhhbXBs ZSwgdGhlICJDb21tdW5pY2F0aW9ucyBTZWN1cml0eSIgYXNwZWN0IGlzIGludHJvZHVjZWQgZm9y IHRoZSBmaXJzdCB0aW1lIGluIFNlY3Rpb24gNC4zIG9ubHkuIFRoZSBzdGFydCBvZiBTZWN0aW9u ICI0LiBTZWN1cml0eSBmb3IgV2ViUlRDIEFwcGxpY2F0aW9ucyIgY291bGQgYmUgYSBsb2dpY2Fs IHBsYWNlIGZvciBpbnRyb2R1Y2luZyB0aGUgV2ViUlRDIHRocmVhdCBtb2RlbC4NCjQuIFRoZSAi c2ltcGxlIFdlYlJUQyBzeXN0ZW0iIHByZXNlbnRlZCBpbiB0aGUgSW50cm9kdWN0aW9uIGluIEZp Z3VyZSAxIGlzIGluYWRlcXVhdGUgdG8gaWxsdXN0cmF0ZSBtYW55IG9mIHRoZSBzY2VuYXJpb3Mg YW5kIHBvaW50cyBkaXNjdXNzZWQgaW4gdGhlIGRvY3VtZW50LiBGb3IgZXhhbXBsZSwgc2VlIHRo ZSBkaXNjdXNzaW9uIGFyb3VuZCBtZWRpYSBvcmlnaW4gdnMuIHdlYiBvcmlnaW4gaW4gU2VjdGlv biA0LjEuMy4NCjUuIFNlY3Rpb24gIjMuIFRoZSBCcm93c2VyIFRocmVhdCBNb2RlbCIgaXMgYW4g b3ZlcnZpZXcgb2YgdGhlIGV4aXN0aW5nIHdlYiBzZWN1cml0eSBhcmNoaXRlY3R1cmUgYW5kIHNv bWUgY3VycmVudCBwcmFjdGljZXMuIEFzIHN1Y2gsIHJlZmVyZW5jZXMgdG8gcmVsZXZhbnQgc3Rh bmRhcmRzIChlLmcuLCBXM0MpIGFuZCBjb21tb24gcHJhY3RpY2VzIG5lZWQgdG8gYmUgYWRkZWQg d2l0aGluIHRoZSB0ZXh0IHRvIGhlbHAgdGhlIHJlYWRlciB0byB1bmRlcnN0YW5kIHRoZSBzdGF0 dXMgb2YgdGhlIGluZm9ybWF0aW9uIGFuZCB0byBmb2xsb3cgdGhlIHNvdXJjZXMuDQo2LiBUaGUg bGFzdCBwYXJhZ3JhcGggaW4gU2VjdGlvbiA0LjEgY29udmV5cyBhIGtleSBwb2ludCBpbiB0aGUg d2hvbGUgV2ViUlRDIHRocmVhdCBtb2RlbC4gQXMgc3VjaCwgIGl0IG5lZWRzIHRvIGJlIG1vdmVk IHRvIHRoZSBzdGFydCBvZiB0aGUgZGlzY3Vzc2lvbiB3aGVyZSB0aGUgdGhyZWF0IG1vZGVsIGlz IGludHJvZHVjZWQgKHNlZSBjb21tZW50cyBhYm92ZSkuDQo3LiBTdHlsaXN0aWNhbGx5LCB0aGUg ZG9jdW1lbnQgd291bGQgYmVuZWZpdCBmcm9tIHJlbW92aW5nIG5vbi1zdGFuZGFyZHMgdm9jYWJ1 bGFyeSwgaS5lLiwgInRvIGJ1ZyIsICJ0byBidWcgbWUiLCAibm8gcmVhbCB3YXkiLCAiaXQgaXMg aW1wb3J0YW50IHRvIHJlcXVpcmUiLCAiZXh0cmVtZWx5IGFnZ3Jlc3NpdmUgaW50ZXJtZWRpYXRl cyIsICBhbmQgImZvciBvYnZpb3VzIHJlYXNvbnMiLCBldGMuDQo4LiBTdWdnZXN0aW9ucyBmb3Ig cmVuYW1pbmcgc29tZSBvZiB0aGUgc2VjdGlvbnMgdG8gaW1wcm92ZSByZWFkYWJpbGl0eToNCiIz LiBUaGUgQnJvd3NlciBUaHJlYXQgTW9kZWwiIC0+ICIgMy4gT3ZlcnZpZXcgb2YgdGhlIEV4aXN0 aW5nIFdlYiBUaHJlYXQgTW9kZWwiDQoiNC4xLiBBY2Nlc3MgdG8gTG9jYWwgRGV2aWNlcyIgLT4g IjQuMS4gQ29uc2VudCB0byBBY2Nlc3MgTG9jYWwgUmVzb3VyY2VzIg0KIjQuMS4yLiBDYWxsaW5n IFNjZW5hcmlvcyBhbmQgVXNlciBFeHBlY3RhdGlvbnMiIC0+ICI0LjEuMi4gU2NvcGUgb2YgQ29u c2VudCBpbiBWYXJpb3VzIENhbGxpbmcgU2NlbmFyaW9zIg0KIjQuMS4yLjEuIERlZGljYXRlZCBD YWxsaW5nIFNlcnZpY2VzIiAtPiAiNC4xLjIuMS4gTG9uZy10ZXJtIENvbnNlbnQiDQoiNC4xLjIu Mi4gQ2FsbGluZyB0aGUgc2l0ZSBZb3UncmUgT24iIC0+ICI0LjEuMi4yLiBTaG9ydC10ZXJtIENv bnNlbnQiDQoiNC4xLjMuIE9yaWdpbi1CYXNlZCBTZWN1cml0eSIgLT4gIjQuMS4zLiBXZWIgQXR0 YWNrZXJzIGFuZCBPcmlnaW4tYmFzZWQgU2VjdXJpdHkiDQoiNC4xLjQuIFNlY3VyaXR5IFByb3Bl cnRpZXMgb2YgdGhlIENhbGxpbmcgUGFnZSIgLT4gIjQuMS40LiBOZXR3b3JrIEF0dGFja2VycyBh bmQgIFNlY3VyaXR5IFByb3BlcnRpZXMgb2YgdGhlIENhbGxpbmcgUGFnZSINCiI0LjIuIENvbW11 bmljYXRpb25zIENvbnNlbnQgVmVyaWZpY2F0aW9uIiAtPiAiNC4yLiBDb25zZW50IHRvIFJlY2Vp dmUgVHJhZmZpYyINCiI0LjMuMy4gTWFsaWNpb3VzIFBlZXJzIiAtPiAiNC4zLjMuIE91dCBvZiBT Y29wZSINCg0KaHR0cHM6Ly9kYXRhdHJhY2tlci5pZXRmLm9yZy9kb2MvZHJhZnQtaWV0Zi1ydGN3 ZWItc2VjdXJpdHktYXJjaC8NClRoaXMgZG9jdW1lbnQgaXMgaW4gYSBtdWNoIGJldHRlciBzdGF0 ZSBpbiB0ZXJtcyBvZiBpdHMgb3JnYW5pemF0aW9uIGFuZCByZWFkYWJpbGl0eS4gSXQgaW50cm9k dWNlcyB0aGUgc2VjdXJpdHkgYXJjaGl0ZWN0dXJlIHVzaW5nIGFuIGV4YW1wbGUgYW5kIHRoZW4g bGlzdHMgcG9zc2libGUgYXBwcm9hY2hlcyB0byBpbXBsZW1lbnQgaXQuIFNvbWUgYXBwcm9hY2hl cyBhcmUgZGVzY3JpYmVkIG9uIGEgaGlnaCBsZXZlbCBieSByZWZlcmVuY2luZyBvdGhlciBkb2N1 bWVudHMsIHdoaWxlIG90aGVycyBhcmUgaW50cm9kdWNlZCBmb3IgdGhlIGZpcnN0IHRpbWUgaW4g dGhpcyBkb2N1bWVudCB0b2dldGhlciB3aXRoIHRoZWlyIGltcGxlbWVudGF0aW9uIGRldGFpbHMu IEJ5IGp1c3QgcmVhZGluZyB0aGUgZG9jdW1lbnQsIGl0IGlzIGRpZmZpY3VsdCB0byBqdWRnZSB3 aGV0aGVyIHRoZXNlIGRldGFpbHMgYXJlIHN1ZmZpY2llbnQgb3Igc3RhYmxlIGVub3VnaCBmb3Ig aW1wbGVtZW50YXRpb24uIEluIGdlbmVyYWwsIEkgZG91YnQgdGhhdCB0aGlzIGlzIHRoZSBiZXN0 IGFwcHJvYWNoIGZvciBhbiAiYXJjaGl0ZWN0dXJlIiBkb2N1bWVudCwgd2hpY2ggaXMgc3VwcG9z ZWQgdG8gc2VydmUgYXMgYSBsb25nIHRlcm0gc3RhYmxlIHJlZmVyZW5jZS4NCk1vcmUgc3BlY2lm aWMgY29tbWVudHM6DQoxLiBEaWZmZXJlbnQgdGVybWlub2xvZ3kgaXMgdXNlZCB0aHJvdWdob3V0 IHRoZSBkb2N1bWVudCB0byBhZGRyZXNzIHNhbWUgb3IgY2xvc2UgY29uY2VwdHMuIEl0IHdvdWxk IGhlbHAgYSBsb3QgdG8gZXhwbGFpbiB0aGUgY29uY2VwdHMgdXBmcm9udCBhbmQgdGhlbiB0byB1 c2UgdGhlIHRlcm1pbm9sb2d5IGNvbnNpc3RlbnRseS4gQ3VycmVudGx5IGl0IGluY2x1ZGVzICJj bGllbnQiLCAiZW5kcG9pbnQiLCAgInBlZXIiLCAidXNlciI7ICJpbXBsZW1lbnRhdGlvbiIsICJi cm93c2VyIiwgImNocm9tZSIsICJBUEkiLCAiSlMiOyAiYXBwbGljYXRpb24iLCAic2VydmVyIiwg ZXRjLg0KMi4gVGhlIGRpc2N1c3Npb24gaXMgcGhyYXNlZCBpbiB0ZXJtcyBvZiAiYXV0aGVudGlj YXRpb24iIGFuZCAidHJ1c3QiLiBJbiB0aGluayB0aGF0ICJhdXRob3JpemF0aW9uIiBpbnN0ZWFk IG9mICJ0cnVzdCIgd291bGQgYmUgYSBiZXR0ZXIgdGVjaG5pY2FsIHRlcm0sIGZvciBleGFtcGxl LCBpbiBTZWN0aW9uIDMuMS4NCjMuIEluIHNlY3Rpb24gNC4gT3ZlcnZpZXcsIHNlbnRlbmNlICJ0 aGUgdGVuc2lvbiBiZXR3ZWVuIHNlY3VyaXR5IChvciBwZXJmb3JtYW5jZSkgYW5kIHByaXZhY3ki IGlzIG5vdCBjbGVhciwgZXNwZWNpYWxseSBiZWNhdXNlIGl0IGRvZXNuJ3Qgc2VlbSB0byBjb3Jy ZXNwb25kIHRvIFNlY3Rpb24gNi4yLiAoQlRXICJ0cmFkZW9mZiIgd291bGQgYmUgYSBiZXR0ZXIg d29yZCB0aGFuICJ0ZW5zaW9uIi4pDQo0LiBTZWN0aW9uICI0LjEuIEluaXRpYWwgU2lnbmFsaW5n IiwgdGhlIHRleHQgaXMgaW5jb25zaXN0ZW50IGluIHRlcm1zIG9mIHdoZXRoZXIgQWxpY2UgYW5k IEJvYiBzaGFyZSBvciB1c2UgZGlmZmVyZW50IGlkZW50aXR5IHByb3ZpZGVycy4NCjUuIFNlY3Rp b24gIjQuMS4gSW5pdGlhbCBTaWduYWxpbmciLCByZWZlcmVuY2UgdG8gUGVlckNvbm5lY3Rpb24g bmVlZHMgdG8gYmUgYWRkZWQuDQo2LiBTZWN0aW9uICI0LjIuIE1lZGlhIENvbnNlbnQgVmVyaWZp Y2F0aW9uIiBhbmQgU2VjdGlvbiAiNS4zIENvbW11bmljYXRpb25zIENvbnNlbnQiOiB0aGUgbmFt ZS90ZXJtaW5vbG9neSBvZiB0aGlzIGZ1bmN0aW9uYWxpdHkgbmVlZHMgdG8gYmUgaGFybW9uaXpl ZC4gVGhlIElDRS1iYXNlZCBzb2x1dGlvbiB3aXRoIGl0cyBwcm9zLCBjb25zIGFzIHdlbGwgYXMg dGhlIGFsdGVybmF0aXZlcyAoYXBwbGljYWJsZSB0byBkaWZmZXJlbnQgdXNlIGNhc2VzKSBuZWVk IHRvIGJlIG1vdmVkIGZyb20gdGhlIGNvbXBhbmlvbiB0aHJlYXQgbW9kZWwgZG9jdW1lbnQgdG8g dGhpcyAiYXJjaGl0ZWN0dXJlIiBvbmUuDQo3LiBBIHN1Z2dlc3Rpb246IHJlbmFtZSAiNS4gRGV0 YWlsZWQgVGVjaG5pY2FsIERlc2NyaXB0aW9uIiB0byAiNS4gU2VjdXJpdHkgQXJjaGl0ZWN0dXJl IENvbXBvbmVudHMiLg0KOC4gSW4gU2VjdGlvbiA1LjIuLCAiSW1wbGVtZW50YXRpb25zIHdoaWNo IHN1cHBvcnQgc29tZSBmb3JtIG9mIGRpcmVjdCB1c2VyIGF1dGhlbnRpY2F0aW9uLi4uIiAtPiAi SW1wbGVtZW50YXRpb25zIHRoYXQgc3VwcG9ydCBzb21lIGZvcm0gb2YgZGlyZWN0IHVzZXIgYXV0 aGVudGljYXRpb24uLi4iDQo5LiBTZWN0aW9uICI1LjYuIFdlYi1CYXNlZCBQZWVyIEF1dGhlbnRp Y2F0aW9uIiBhbmQgc2VjdGlvbiAiNS42LjIuIE92ZXJ2aWV3IG9mIG9wZXJhdGlvbiI6IEl0IGlz IG5vdCBjbGVhciwgd2hpY2ggcGFydHMgYXJlIHN0YW5kYXJkaXplZCBjb25jZXB0cyAoZS5nLiwg YnkgVzNDKSBhbmQgd2hpY2ggYXJlIGludHJvZHVjZWQgaGVyZSBmb3IgdGhlIGZpcnN0IHRpbWUu IElmIGV4aXN0LCByZWZlcmVuY2VzIHRvIGV4aXN0aW5nIHN0YW5kYXJkcyBuZWVkIHRvIGJlIGFk ZGVkLiBUaGUgZGVzY3JpYmVkIGFyY2hpdGVjdHVyZSBhbmQgdGhlIHRlY2huaWNhbCBkZXRhaWxz IHNlZW0gdG8gYmUgKDEpIHVuZGVyIGRldmVsb3BtZW50IGFuZCB0aHVzIHByb2JhYmx5IG5vdCBz dGFibGUsICgyKSB0b28gZGV0YWlsZWQgZm9yICJhbiBhcmNoaXRlY3R1cmUiIGRvY3VtZW50IGFu ZCAoMykgdXNlZnVsIGJleW9uZCBXZWJSVEMuICBBcyBzdWNoLCB0aGUgY29uY2VwdCBvZiB0aGUg IiBXZWItQmFzZWQgUGVlciBBdXRoZW50aWNhdGlvbiIgcHJvYmFibHkgbmVlZHMgYmUgaW50cm9k dWNlZCB1bmRlciB0aGUgU2VjdXJpdHkgQXJlYSBhbmQgdGhlbiBhZG9wdGVkIGJ5IFdlYlJUQy4N CjEwLiBUaGUgd2ViLWJhc2VkIHBlZXIgYXV0aGVudGljYXRpb24gdXNpbmcgSWRQIGlzIG5vdCB0 aGUgb25seSBtZWNoYW5pc20gYXBwbGljYWJsZSB0byBXZWJSVEMuIE1vcmVvdmVyLCB0aGUgd2Vi LWJhc2VkIHBlZXIgYXV0aGVudGljYXRpb24gIGlzIG5vdCB0aGUgb25seSBhcHByb2FjaCBhcHBs aWNhYmxlIHRvIFdlYlJUQy4gQWx0ZXJuYXRpdmVzIGFyZSBsaXN0ZWQgaW4gdGhlIGNvbXBhbmlv biBkb2N1bWVudCBhbmQgbmVlZCB0byBiZSBtb3ZlZCBoZXJlIHRvIHRoZSAiYXJjaGl0ZWN0dXJl IiBkb2N1bWVudCB3aXRoIHRoZWlyIHByb3MgYW5kIGNvbnMgcHJlc2VudGVkIGluIGFuIHVuYmlh c2VkIHdheS4NCjExLiBTdHlsaXN0aWNhbGx5LCB0aGUgZG9jdW1lbnQgd291bGQgYmVuZWZpdCBm cm9tIHJlbW92aW5nIG5vbi1zdGFuZGFyZHMgdm9jYWJ1bGFyeSwgaS5lLiwgInNvbWUgV2ViIHNl cnZlciIsICJjYW4ndCByZWFsbHkgdHJ1c3QiLCAidGhhdCBtdWNoIiwgImZhaXJseSBjb252ZW50 aW9uYWwiLCAic2ltcGx5IGhhdmUiLCAiYSBsaXR0bGUgYW50aWNsaW1hY3RpYyIsIGV0Yy4gOy0p DQoNClRoYW5rcywNCk9yaXQuDQoNCj4gLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCj4gRnJv bTogYXBwc2RpciBbbWFpbHRvOmFwcHNkaXItYm91bmNlc0BpZXRmLm9yZzxtYWlsdG86YXBwc2Rp ci1ib3VuY2VzQGlldGYub3JnPl0gT24gQmVoYWxmIE9mIE9yaXQgTGV2aW4NCj4gKExDQSkNCj4g U2VudDogVGh1cnNkYXksIEp1bmUgMjUsIDIwMTUgMToxNyBQTQ0KPiBUbzogRWxpb3QgTGVhcjsg YXBwc2RpckBpZXRmLm9yZzxtYWlsdG86YXBwc2RpckBpZXRmLm9yZz4NCj4gU3ViamVjdDogUmU6 IFthcHBzZGlyXSBGd2Q6IFJlcXVlc3QgZm9yIEFwcHMgRGlyZWN0b3JhdGUgcmV2aWV3IG9mIHJ0 Y3dlYi0NCj4gc2VjdXJpdHkgZHJhZnRzDQo+DQo+IFBlcmZlY3QhIEkgaGF2ZSBhIHZlcnkgbG9u ZyBmbGlnaHQgb24gdGhlIDd0aC4uLiBTbyByaWdodCBhZnRlciB0aGVuIG9yIGVhcmxpZXIuDQo+ IE9yaXQuDQo+DQo+ID4gLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCj4gPiBGcm9tOiBFbGlv dCBMZWFyIFttYWlsdG86bGVhckBjaXNjby5jb208bWFpbHRvOmxlYXJAY2lzY28uY29tPl0NCj4g PiBTZW50OiBUaHVyc2RheSwgSnVuZSAyNSwgMjAxNSAxMjo1NSBQTQ0KPiA+IFRvOiBPcml0IExl dmluIChMQ0EpOyBhcHBzZGlyQGlldGYub3JnPG1haWx0bzphcHBzZGlyQGlldGYub3JnPg0KPiA+ IFN1YmplY3Q6IFJlOiBbYXBwc2Rpcl0gRndkOiBSZXF1ZXN0IGZvciBBcHBzIERpcmVjdG9yYXRl IHJldmlldyBvZiBydGN3ZWItDQo+ID4gc2VjdXJpdHkgZHJhZnRzDQo+ID4NCj4gPiBUaGFuayB5 b3UgT3JpdCEgIENhbiB5b3UgdHJ5IHRvIGhhdmUgdGhlbSBkb25lIGluIGFib3V0IHR3byB3ZWVr cz8NCj4gPg0KPiA+IEVsaW90DQo+ID4NCj4gPiBPbiA2LzI1LzE1IDk6NTIgUE0sIE9yaXQgTGV2 aW4gKExDQSkgd3JvdGU6DQo+ID4gPiBJIHdpbGwgYmUgaGFwcHkgdG8gdGFrZSBhIGxvb2sgYXQg dGhlbSENCj4gPiA+IE9yaXQuDQo+ID4gPg0KPiA+ID4+IC0tLS0tT3JpZ2luYWwgTWVzc2FnZS0t LS0tDQo+ID4gPj4gRnJvbTogYXBwc2RpciBbbWFpbHRvOmFwcHNkaXItYm91bmNlc0BpZXRmLm9y ZzxtYWlsdG86YXBwc2Rpci1ib3VuY2VzQGlldGYub3JnPl0gT24gQmVoYWxmIE9mIEVsaW90DQo+ IExlYXINCj4gPiA+PiBTZW50OiBUaHVyc2RheSwgSnVuZSAyNSwgMjAxNSAxMTo0NCBBTQ0KPiA+ ID4+IFRvOiBhcHBzZGlyQGlldGYub3JnPG1haWx0bzphcHBzZGlyQGlldGYub3JnPg0KPiA+ID4+ IFN1YmplY3Q6IFthcHBzZGlyXSBGd2Q6IFJlcXVlc3QgZm9yIEFwcHMgRGlyZWN0b3JhdGUgcmV2 aWV3IG9mIHJ0Y3dlYi0NCj4gPiA+PiBzZWN1cml0eSBkcmFmdHMNCj4gPiA+Pg0KPiA+ID4+IERl YXIgQXBwc2RpciBmb2xrLA0KPiA+ID4+DQo+ID4gPj4gQ291bGQgSSBoYXZlIGEgdm9sdW50ZWVy IHRvIHJldmlldyB0aGUgZm9sbG93aW5nIHR3byBkcmFmdHM/DQo+ID4gPj4NCj4gPiA+PiBodHRw czovL2RhdGF0cmFja2VyLmlldGYub3JnL2RvYy9kcmFmdC1pZXRmLXJ0Y3dlYi1zZWN1cml0eS8N Cj4gPiA+Pg0KPiA+ID4+IGFuZA0KPiA+ID4+DQo+ID4gPj4gaHR0cHM6Ly9kYXRhdHJhY2tlci5p ZXRmLm9yZy9kb2MvZHJhZnQtaWV0Zi1ydGN3ZWItc2VjdXJpdHktYXJjaC8NCj4gPiA+Pg0KPiA+ ID4+IFRlZCBpcyBleGVtcHQsIGhhdmluZyBtYWRlIHRoZSByZXF1ZXN0IDstKQ0KPiA+ID4+DQo+ ID4gPj4gRWxpb3QNCj4gPg0KPg0KPiBfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fXw0KPiBhcHBzZGlyIG1haWxpbmcgbGlzdA0KPiBhcHBzZGlyQGlldGYub3Jn PG1haWx0bzphcHBzZGlyQGlldGYub3JnPg0KPiBodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFu L2xpc3RpbmZvL2FwcHNkaXINCg0KX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX18NCmFwcHNkaXIgbWFpbGluZyBsaXN0DQphcHBzZGlyQGlldGYub3JnPG1haWx0 bzphcHBzZGlyQGlldGYub3JnPg0KaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5m by9hcHBzZGlyDQoNCg0KX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX18NCnJ0Y3dlYiBtYWlsaW5nIGxpc3QNCnJ0Y3dlYkBpZXRmLm9yZzxtYWlsdG86cnRjd2Vi QGlldGYub3JnPg0KaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9ydGN3ZWIN Cg0KDQo= --_000_BL2PR03MB29088098BC3FA25C9D24AC2AD760BL2PR03MB290namprd_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IlByb2dJZCIg Y29udGVudD0iV29yZC5Eb2N1bWVudCI+DQo8bWV0YSBuYW1lPSJHZW5lcmF0b3IiIGNvbnRlbnQ9 Ik1pY3Jvc29mdCBXb3JkIDE1Ij4NCjxtZXRhIG5hbWU9Ik9yaWdpbmF0b3IiIGNvbnRlbnQ9Ik1p Y3Jvc29mdCBXb3JkIDE1Ij4NCjxsaW5rIHJlbD0iRmlsZS1MaXN0IiBocmVmPSJjaWQ6ZmlsZWxp c3QueG1sQDAxRDBDRUQ1LkYxQjU5NkYwIj48IS0tW2lmIGd0ZSBtc28gOV0+PHhtbD4NCjxvOk9m ZmljZURvY3VtZW50U2V0dGluZ3M+DQo8bzpBbGxvd1BORy8+DQo8L286T2ZmaWNlRG9jdW1lbnRT ZXR0aW5ncz4NCjwveG1sPjwhW2VuZGlmXS0tPjwhLS1baWYgZ3RlIG1zbyA5XT48eG1sPg0KPHc6 V29yZERvY3VtZW50Pg0KPHc6U3BlbGxpbmdTdGF0ZT5DbGVhbjwvdzpTcGVsbGluZ1N0YXRlPg0K PHc6VHJhY2tNb3Zlcy8+DQo8dzpUcmFja0Zvcm1hdHRpbmcvPg0KPHc6RW52ZWxvcGVWaXMvPg0K PHc6VmFsaWRhdGVBZ2FpbnN0U2NoZW1hcy8+DQo8dzpTYXZlSWZYTUxJbnZhbGlkPmZhbHNlPC93 OlNhdmVJZlhNTEludmFsaWQ+DQo8dzpJZ25vcmVNaXhlZENvbnRlbnQ+ZmFsc2U8L3c6SWdub3Jl TWl4ZWRDb250ZW50Pg0KPHc6QWx3YXlzU2hvd1BsYWNlaG9sZGVyVGV4dD5mYWxzZTwvdzpBbHdh eXNTaG93UGxhY2Vob2xkZXJUZXh0Pg0KPHc6RG9Ob3RQcm9tb3RlUUYvPg0KPHc6TGlkVGhlbWVP dGhlcj5FTi1VUzwvdzpMaWRUaGVtZU90aGVyPg0KPHc6TGlkVGhlbWVBc2lhbj5YLU5PTkU8L3c6 TGlkVGhlbWVBc2lhbj4NCjx3OkxpZFRoZW1lQ29tcGxleFNjcmlwdD5YLU5PTkU8L3c6TGlkVGhl bWVDb21wbGV4U2NyaXB0Pg0KPHc6Q29tcGF0aWJpbGl0eT4NCjx3OkRvTm90RXhwYW5kU2hpZnRS ZXR1cm4vPg0KPHc6QnJlYWtXcmFwcGVkVGFibGVzLz4NCjx3OlNwbGl0UGdCcmVha0FuZFBhcmFN YXJrLz4NCjx3OkVuYWJsZU9wZW5UeXBlS2VybmluZy8+DQo8L3c6Q29tcGF0aWJpbGl0eT4NCjxt Om1hdGhQcj4NCjxtOm1hdGhGb250IG06dmFsPSJDYW1icmlhIE1hdGgiLz4NCjxtOmJya0JpbiBt OnZhbD0iYmVmb3JlIi8+DQo8bTpicmtCaW5TdWIgbTp2YWw9IiYjNDU7LSIvPg0KPG06c21hbGxG cmFjIG06dmFsPSJvZmYiLz4NCjxtOmRpc3BEZWYvPg0KPG06bE1hcmdpbiBtOnZhbD0iMCIvPg0K PG06ck1hcmdpbiBtOnZhbD0iMCIvPg0KPG06ZGVmSmMgbTp2YWw9ImNlbnRlckdyb3VwIi8+DQo8 bTp3cmFwSW5kZW50IG06dmFsPSIxNDQwIi8+DQo8bTppbnRMaW0gbTp2YWw9InN1YlN1cCIvPg0K PG06bmFyeUxpbSBtOnZhbD0idW5kT3ZyIi8+DQo8L206bWF0aFByPjwvdzpXb3JkRG9jdW1lbnQ+ DQo8L3htbD48IVtlbmRpZl0tLT48IS0tW2lmIGd0ZSBtc28gOV0+PHhtbD4NCjx3OkxhdGVudFN0 eWxlcyBEZWZMb2NrZWRTdGF0ZT0iZmFsc2UiIERlZlVuaGlkZVdoZW5Vc2VkPSJmYWxzZSIgRGVm U2VtaUhpZGRlbj0iZmFsc2UiIERlZlFGb3JtYXQ9ImZhbHNlIiBEZWZQcmlvcml0eT0iOTkiIExh dGVudFN0eWxlQ291bnQ9IjM3MSI+DQo8dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJmYWxzZSIgUHJp b3JpdHk9IjAiIFFGb3JtYXQ9InRydWUiIE5hbWU9Ik5vcm1hbCIvPg0KPHc6THNkRXhjZXB0aW9u IExvY2tlZD0iZmFsc2UiIFByaW9yaXR5PSI5IiBRRm9ybWF0PSJ0cnVlIiBOYW1lPSJoZWFkaW5n IDEiLz4NCjx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBQcmlvcml0eT0iOSIgU2VtaUhp ZGRlbj0idHJ1ZSIgVW5oaWRlV2hlblVzZWQ9InRydWUiIFFGb3JtYXQ9InRydWUiIE5hbWU9Imhl YWRpbmcgMiIvPg0KPHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFByaW9yaXR5PSI5IiBT ZW1pSGlkZGVuPSJ0cnVlIiBVbmhpZGVXaGVuVXNlZD0idHJ1ZSIgUUZvcm1hdD0idHJ1ZSIgTmFt ZT0iaGVhZGluZyAzIi8+DQo8dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJmYWxzZSIgUHJpb3JpdHk9 IjkiIFNlbWlIaWRkZW49InRydWUiIFVuaGlkZVdoZW5Vc2VkPSJ0cnVlIiBRRm9ybWF0PSJ0cnVl IiBOYW1lPSJoZWFkaW5nIDQiLz4NCjx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBQcmlv cml0eT0iOSIgU2VtaUhpZGRlbj0idHJ1ZSIgVW5oaWRlV2hlblVzZWQ9InRydWUiIFFGb3JtYXQ9 InRydWUiIE5hbWU9ImhlYWRpbmcgNSIvPg0KPHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFsc2Ui IFByaW9yaXR5PSI5IiBTZW1pSGlkZGVuPSJ0cnVlIiBVbmhpZGVXaGVuVXNlZD0idHJ1ZSIgUUZv cm1hdD0idHJ1ZSIgTmFtZT0iaGVhZGluZyA2Ii8+DQo8dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJm YWxzZSIgUHJpb3JpdHk9IjkiIFNlbWlIaWRkZW49InRydWUiIFVuaGlkZVdoZW5Vc2VkPSJ0cnVl IiBRRm9ybWF0PSJ0cnVlIiBOYW1lPSJoZWFkaW5nIDciLz4NCjx3OkxzZEV4Y2VwdGlvbiBMb2Nr ZWQ9ImZhbHNlIiBQcmlvcml0eT0iOSIgU2VtaUhpZGRlbj0idHJ1ZSIgVW5oaWRlV2hlblVzZWQ9 InRydWUiIFFGb3JtYXQ9InRydWUiIE5hbWU9ImhlYWRpbmcgOCIvPg0KPHc6THNkRXhjZXB0aW9u IExvY2tlZD0iZmFsc2UiIFByaW9yaXR5PSI5IiBTZW1pSGlkZGVuPSJ0cnVlIiBVbmhpZGVXaGVu VXNlZD0idHJ1ZSIgUUZvcm1hdD0idHJ1ZSIgTmFtZT0iaGVhZGluZyA5Ii8+DQo8dzpMc2RFeGNl cHRpb24gTG9ja2VkPSJmYWxzZSIgU2VtaUhpZGRlbj0idHJ1ZSIgVW5oaWRlV2hlblVzZWQ9InRy dWUiIE5hbWU9ImluZGV4IDEiLz4NCjx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBTZW1p SGlkZGVuPSJ0cnVlIiBVbmhpZGVXaGVuVXNlZD0idHJ1ZSIgTmFtZT0iaW5kZXggMiIvPg0KPHc6 THNkRXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFNlbWlIaWRkZW49InRydWUiIFVuaGlkZVdoZW5V c2VkPSJ0cnVlIiBOYW1lPSJpbmRleCAzIi8+DQo8dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJmYWxz ZSIgU2VtaUhpZGRlbj0idHJ1ZSIgVW5oaWRlV2hlblVzZWQ9InRydWUiIE5hbWU9ImluZGV4IDQi Lz4NCjx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBTZW1pSGlkZGVuPSJ0cnVlIiBVbmhp ZGVXaGVuVXNlZD0idHJ1ZSIgTmFtZT0iaW5kZXggNSIvPg0KPHc6THNkRXhjZXB0aW9uIExvY2tl ZD0iZmFsc2UiIFNlbWlIaWRkZW49InRydWUiIFVuaGlkZVdoZW5Vc2VkPSJ0cnVlIiBOYW1lPSJp bmRleCA2Ii8+DQo8dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJmYWxzZSIgU2VtaUhpZGRlbj0idHJ1 ZSIgVW5oaWRlV2hlblVzZWQ9InRydWUiIE5hbWU9ImluZGV4IDciLz4NCjx3OkxzZEV4Y2VwdGlv biBMb2NrZWQ9ImZhbHNlIiBTZW1pSGlkZGVuPSJ0cnVlIiBVbmhpZGVXaGVuVXNlZD0idHJ1ZSIg TmFtZT0iaW5kZXggOCIvPg0KPHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFNlbWlIaWRk ZW49InRydWUiIFVuaGlkZVdoZW5Vc2VkPSJ0cnVlIiBOYW1lPSJpbmRleCA5Ii8+DQo8dzpMc2RF eGNlcHRpb24gTG9ja2VkPSJmYWxzZSIgUHJpb3JpdHk9IjM5IiBTZW1pSGlkZGVuPSJ0cnVlIiBV bmhpZGVXaGVuVXNlZD0idHJ1ZSIgTmFtZT0idG9jIDEiLz4NCjx3OkxzZEV4Y2VwdGlvbiBMb2Nr ZWQ9ImZhbHNlIiBQcmlvcml0eT0iMzkiIFNlbWlIaWRkZW49InRydWUiIFVuaGlkZVdoZW5Vc2Vk PSJ0cnVlIiBOYW1lPSJ0b2MgMiIvPg0KPHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFBy aW9yaXR5PSIzOSIgU2VtaUhpZGRlbj0idHJ1ZSIgVW5oaWRlV2hlblVzZWQ9InRydWUiIE5hbWU9 InRvYyAzIi8+DQo8dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJmYWxzZSIgUHJpb3JpdHk9IjM5IiBT ZW1pSGlkZGVuPSJ0cnVlIiBVbmhpZGVXaGVuVXNlZD0idHJ1ZSIgTmFtZT0idG9jIDQiLz4NCjx3 OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBQcmlvcml0eT0iMzkiIFNlbWlIaWRkZW49InRy dWUiIFVuaGlkZVdoZW5Vc2VkPSJ0cnVlIiBOYW1lPSJ0b2MgNSIvPg0KPHc6THNkRXhjZXB0aW9u IExvY2tlZD0iZmFsc2UiIFByaW9yaXR5PSIzOSIgU2VtaUhpZGRlbj0idHJ1ZSIgVW5oaWRlV2hl blVzZWQ9InRydWUiIE5hbWU9InRvYyA2Ii8+DQo8dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJmYWxz ZSIgUHJpb3JpdHk9IjM5IiBTZW1pSGlkZGVuPSJ0cnVlIiBVbmhpZGVXaGVuVXNlZD0idHJ1ZSIg TmFtZT0idG9jIDciLz4NCjx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBQcmlvcml0eT0i MzkiIFNlbWlIaWRkZW49InRydWUiIFVuaGlkZVdoZW5Vc2VkPSJ0cnVlIiBOYW1lPSJ0b2MgOCIv Pg0KPHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFByaW9yaXR5PSIzOSIgU2VtaUhpZGRl bj0idHJ1ZSIgVW5oaWRlV2hlblVzZWQ9InRydWUiIE5hbWU9InRvYyA5Ii8+DQo8dzpMc2RFeGNl cHRpb24gTG9ja2VkPSJmYWxzZSIgU2VtaUhpZGRlbj0idHJ1ZSIgVW5oaWRlV2hlblVzZWQ9InRy dWUiIE5hbWU9Ik5vcm1hbCBJbmRlbnQiLz4NCjx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNl IiBTZW1pSGlkZGVuPSJ0cnVlIiBVbmhpZGVXaGVuVXNlZD0idHJ1ZSIgTmFtZT0iZm9vdG5vdGUg dGV4dCIvPg0KPHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFNlbWlIaWRkZW49InRydWUi IFVuaGlkZVdoZW5Vc2VkPSJ0cnVlIiBOYW1lPSJhbm5vdGF0aW9uIHRleHQiLz4NCjx3OkxzZEV4 Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBTZW1pSGlkZGVuPSJ0cnVlIiBVbmhpZGVXaGVuVXNlZD0i dHJ1ZSIgTmFtZT0iaGVhZGVyIi8+DQo8dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJmYWxzZSIgU2Vt aUhpZGRlbj0idHJ1ZSIgVW5oaWRlV2hlblVzZWQ9InRydWUiIE5hbWU9ImZvb3RlciIvPg0KPHc6 THNkRXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFNlbWlIaWRkZW49InRydWUiIFVuaGlkZVdoZW5V c2VkPSJ0cnVlIiBOYW1lPSJpbmRleCBoZWFkaW5nIi8+DQo8dzpMc2RFeGNlcHRpb24gTG9ja2Vk PSJmYWxzZSIgUHJpb3JpdHk9IjM1IiBTZW1pSGlkZGVuPSJ0cnVlIiBVbmhpZGVXaGVuVXNlZD0i dHJ1ZSIgUUZvcm1hdD0idHJ1ZSIgTmFtZT0iY2FwdGlvbiIvPg0KPHc6THNkRXhjZXB0aW9uIExv Y2tlZD0iZmFsc2UiIFNlbWlIaWRkZW49InRydWUiIFVuaGlkZVdoZW5Vc2VkPSJ0cnVlIiBOYW1l PSJ0YWJsZSBvZiBmaWd1cmVzIi8+DQo8dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJmYWxzZSIgU2Vt aUhpZGRlbj0idHJ1ZSIgVW5oaWRlV2hlblVzZWQ9InRydWUiIE5hbWU9ImVudmVsb3BlIGFkZHJl c3MiLz4NCjx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBTZW1pSGlkZGVuPSJ0cnVlIiBV bmhpZGVXaGVuVXNlZD0idHJ1ZSIgTmFtZT0iZW52ZWxvcGUgcmV0dXJuIi8+DQo8dzpMc2RFeGNl cHRpb24gTG9ja2VkPSJmYWxzZSIgU2VtaUhpZGRlbj0idHJ1ZSIgVW5oaWRlV2hlblVzZWQ9InRy dWUiIE5hbWU9ImZvb3Rub3RlIHJlZmVyZW5jZSIvPg0KPHc6THNkRXhjZXB0aW9uIExvY2tlZD0i ZmFsc2UiIFNlbWlIaWRkZW49InRydWUiIFVuaGlkZVdoZW5Vc2VkPSJ0cnVlIiBOYW1lPSJhbm5v dGF0aW9uIHJlZmVyZW5jZSIvPg0KPHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFNlbWlI aWRkZW49InRydWUiIFVuaGlkZVdoZW5Vc2VkPSJ0cnVlIiBOYW1lPSJsaW5lIG51bWJlciIvPg0K PHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFNlbWlIaWRkZW49InRydWUiIFVuaGlkZVdo ZW5Vc2VkPSJ0cnVlIiBOYW1lPSJwYWdlIG51bWJlciIvPg0KPHc6THNkRXhjZXB0aW9uIExvY2tl ZD0iZmFsc2UiIFNlbWlIaWRkZW49InRydWUiIFVuaGlkZVdoZW5Vc2VkPSJ0cnVlIiBOYW1lPSJl bmRub3RlIHJlZmVyZW5jZSIvPg0KPHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFNlbWlI aWRkZW49InRydWUiIFVuaGlkZVdoZW5Vc2VkPSJ0cnVlIiBOYW1lPSJlbmRub3RlIHRleHQiLz4N Cjx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBTZW1pSGlkZGVuPSJ0cnVlIiBVbmhpZGVX aGVuVXNlZD0idHJ1ZSIgTmFtZT0idGFibGUgb2YgYXV0aG9yaXRpZXMiLz4NCjx3OkxzZEV4Y2Vw dGlvbiBMb2NrZWQ9ImZhbHNlIiBTZW1pSGlkZGVuPSJ0cnVlIiBVbmhpZGVXaGVuVXNlZD0idHJ1 ZSIgTmFtZT0ibWFjcm8iLz4NCjx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBTZW1pSGlk ZGVuPSJ0cnVlIiBVbmhpZGVXaGVuVXNlZD0idHJ1ZSIgTmFtZT0idG9hIGhlYWRpbmciLz4NCjx3 OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBTZW1pSGlkZGVuPSJ0cnVlIiBVbmhpZGVXaGVu VXNlZD0idHJ1ZSIgTmFtZT0iTGlzdCIvPg0KPHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFsc2Ui IFNlbWlIaWRkZW49InRydWUiIFVuaGlkZVdoZW5Vc2VkPSJ0cnVlIiBOYW1lPSJMaXN0IEJ1bGxl dCIvPg0KPHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFNlbWlIaWRkZW49InRydWUiIFVu aGlkZVdoZW5Vc2VkPSJ0cnVlIiBOYW1lPSJMaXN0IE51bWJlciIvPg0KPHc6THNkRXhjZXB0aW9u IExvY2tlZD0iZmFsc2UiIFNlbWlIaWRkZW49InRydWUiIFVuaGlkZVdoZW5Vc2VkPSJ0cnVlIiBO YW1lPSJMaXN0IDIiLz4NCjx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBTZW1pSGlkZGVu PSJ0cnVlIiBVbmhpZGVXaGVuVXNlZD0idHJ1ZSIgTmFtZT0iTGlzdCAzIi8+DQo8dzpMc2RFeGNl cHRpb24gTG9ja2VkPSJmYWxzZSIgU2VtaUhpZGRlbj0idHJ1ZSIgVW5oaWRlV2hlblVzZWQ9InRy dWUiIE5hbWU9Ikxpc3QgNCIvPg0KPHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFNlbWlI aWRkZW49InRydWUiIFVuaGlkZVdoZW5Vc2VkPSJ0cnVlIiBOYW1lPSJMaXN0IDUiLz4NCjx3Okxz ZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBTZW1pSGlkZGVuPSJ0cnVlIiBVbmhpZGVXaGVuVXNl ZD0idHJ1ZSIgTmFtZT0iTGlzdCBCdWxsZXQgMiIvPg0KPHc6THNkRXhjZXB0aW9uIExvY2tlZD0i ZmFsc2UiIFNlbWlIaWRkZW49InRydWUiIFVuaGlkZVdoZW5Vc2VkPSJ0cnVlIiBOYW1lPSJMaXN0 IEJ1bGxldCAzIi8+DQo8dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJmYWxzZSIgU2VtaUhpZGRlbj0i dHJ1ZSIgVW5oaWRlV2hlblVzZWQ9InRydWUiIE5hbWU9Ikxpc3QgQnVsbGV0IDQiLz4NCjx3Okxz ZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBTZW1pSGlkZGVuPSJ0cnVlIiBVbmhpZGVXaGVuVXNl ZD0idHJ1ZSIgTmFtZT0iTGlzdCBCdWxsZXQgNSIvPg0KPHc6THNkRXhjZXB0aW9uIExvY2tlZD0i ZmFsc2UiIFNlbWlIaWRkZW49InRydWUiIFVuaGlkZVdoZW5Vc2VkPSJ0cnVlIiBOYW1lPSJMaXN0 IE51bWJlciAyIi8+DQo8dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJmYWxzZSIgU2VtaUhpZGRlbj0i dHJ1ZSIgVW5oaWRlV2hlblVzZWQ9InRydWUiIE5hbWU9Ikxpc3QgTnVtYmVyIDMiLz4NCjx3Okxz ZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBTZW1pSGlkZGVuPSJ0cnVlIiBVbmhpZGVXaGVuVXNl ZD0idHJ1ZSIgTmFtZT0iTGlzdCBOdW1iZXIgNCIvPg0KPHc6THNkRXhjZXB0aW9uIExvY2tlZD0i ZmFsc2UiIFNlbWlIaWRkZW49InRydWUiIFVuaGlkZVdoZW5Vc2VkPSJ0cnVlIiBOYW1lPSJMaXN0 IE51bWJlciA1Ii8+DQo8dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJmYWxzZSIgUHJpb3JpdHk9IjEw IiBRRm9ybWF0PSJ0cnVlIiBOYW1lPSJUaXRsZSIvPg0KPHc6THNkRXhjZXB0aW9uIExvY2tlZD0i ZmFsc2UiIFNlbWlIaWRkZW49InRydWUiIFVuaGlkZVdoZW5Vc2VkPSJ0cnVlIiBOYW1lPSJDbG9z aW5nIi8+DQo8dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJmYWxzZSIgU2VtaUhpZGRlbj0idHJ1ZSIg VW5oaWRlV2hlblVzZWQ9InRydWUiIE5hbWU9IlNpZ25hdHVyZSIvPg0KPHc6THNkRXhjZXB0aW9u IExvY2tlZD0iZmFsc2UiIFByaW9yaXR5PSIxIiBTZW1pSGlkZGVuPSJ0cnVlIiBVbmhpZGVXaGVu VXNlZD0idHJ1ZSIgTmFtZT0iRGVmYXVsdCBQYXJhZ3JhcGggRm9udCIvPg0KPHc6THNkRXhjZXB0 aW9uIExvY2tlZD0iZmFsc2UiIFNlbWlIaWRkZW49InRydWUiIFVuaGlkZVdoZW5Vc2VkPSJ0cnVl IiBOYW1lPSJCb2R5IFRleHQiLz4NCjx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBTZW1p SGlkZGVuPSJ0cnVlIiBVbmhpZGVXaGVuVXNlZD0idHJ1ZSIgTmFtZT0iQm9keSBUZXh0IEluZGVu dCIvPg0KPHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFNlbWlIaWRkZW49InRydWUiIFVu aGlkZVdoZW5Vc2VkPSJ0cnVlIiBOYW1lPSJMaXN0IENvbnRpbnVlIi8+DQo8dzpMc2RFeGNlcHRp b24gTG9ja2VkPSJmYWxzZSIgU2VtaUhpZGRlbj0idHJ1ZSIgVW5oaWRlV2hlblVzZWQ9InRydWUi IE5hbWU9Ikxpc3QgQ29udGludWUgMiIvPg0KPHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFsc2Ui IFNlbWlIaWRkZW49InRydWUiIFVuaGlkZVdoZW5Vc2VkPSJ0cnVlIiBOYW1lPSJMaXN0IENvbnRp bnVlIDMiLz4NCjx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBTZW1pSGlkZGVuPSJ0cnVl IiBVbmhpZGVXaGVuVXNlZD0idHJ1ZSIgTmFtZT0iTGlzdCBDb250aW51ZSA0Ii8+DQo8dzpMc2RF eGNlcHRpb24gTG9ja2VkPSJmYWxzZSIgU2VtaUhpZGRlbj0idHJ1ZSIgVW5oaWRlV2hlblVzZWQ9 InRydWUiIE5hbWU9Ikxpc3QgQ29udGludWUgNSIvPg0KPHc6THNkRXhjZXB0aW9uIExvY2tlZD0i ZmFsc2UiIFNlbWlIaWRkZW49InRydWUiIFVuaGlkZVdoZW5Vc2VkPSJ0cnVlIiBOYW1lPSJNZXNz YWdlIEhlYWRlciIvPg0KPHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFByaW9yaXR5PSIx MSIgUUZvcm1hdD0idHJ1ZSIgTmFtZT0iU3VidGl0bGUiLz4NCjx3OkxzZEV4Y2VwdGlvbiBMb2Nr ZWQ9ImZhbHNlIiBTZW1pSGlkZGVuPSJ0cnVlIiBVbmhpZGVXaGVuVXNlZD0idHJ1ZSIgTmFtZT0i U2FsdXRhdGlvbiIvPg0KPHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFNlbWlIaWRkZW49 InRydWUiIFVuaGlkZVdoZW5Vc2VkPSJ0cnVlIiBOYW1lPSJEYXRlIi8+DQo8dzpMc2RFeGNlcHRp b24gTG9ja2VkPSJmYWxzZSIgU2VtaUhpZGRlbj0idHJ1ZSIgVW5oaWRlV2hlblVzZWQ9InRydWUi IE5hbWU9IkJvZHkgVGV4dCBGaXJzdCBJbmRlbnQiLz4NCjx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9 ImZhbHNlIiBTZW1pSGlkZGVuPSJ0cnVlIiBVbmhpZGVXaGVuVXNlZD0idHJ1ZSIgTmFtZT0iQm9k eSBUZXh0IEZpcnN0IEluZGVudCAyIi8+DQo8dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJmYWxzZSIg U2VtaUhpZGRlbj0idHJ1ZSIgVW5oaWRlV2hlblVzZWQ9InRydWUiIE5hbWU9Ik5vdGUgSGVhZGlu ZyIvPg0KPHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFNlbWlIaWRkZW49InRydWUiIFVu aGlkZVdoZW5Vc2VkPSJ0cnVlIiBOYW1lPSJCb2R5IFRleHQgMiIvPg0KPHc6THNkRXhjZXB0aW9u IExvY2tlZD0iZmFsc2UiIFNlbWlIaWRkZW49InRydWUiIFVuaGlkZVdoZW5Vc2VkPSJ0cnVlIiBO YW1lPSJCb2R5IFRleHQgMyIvPg0KPHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFNlbWlI aWRkZW49InRydWUiIFVuaGlkZVdoZW5Vc2VkPSJ0cnVlIiBOYW1lPSJCb2R5IFRleHQgSW5kZW50 IDIiLz4NCjx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBTZW1pSGlkZGVuPSJ0cnVlIiBV bmhpZGVXaGVuVXNlZD0idHJ1ZSIgTmFtZT0iQm9keSBUZXh0IEluZGVudCAzIi8+DQo8dzpMc2RF eGNlcHRpb24gTG9ja2VkPSJmYWxzZSIgU2VtaUhpZGRlbj0idHJ1ZSIgVW5oaWRlV2hlblVzZWQ9 InRydWUiIE5hbWU9IkJsb2NrIFRleHQiLz4NCjx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNl IiBTZW1pSGlkZGVuPSJ0cnVlIiBVbmhpZGVXaGVuVXNlZD0idHJ1ZSIgTmFtZT0iSHlwZXJsaW5r Ii8+DQo8dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJmYWxzZSIgU2VtaUhpZGRlbj0idHJ1ZSIgVW5o aWRlV2hlblVzZWQ9InRydWUiIE5hbWU9IkZvbGxvd2VkSHlwZXJsaW5rIi8+DQo8dzpMc2RFeGNl cHRpb24gTG9ja2VkPSJmYWxzZSIgUHJpb3JpdHk9IjIyIiBRRm9ybWF0PSJ0cnVlIiBOYW1lPSJT dHJvbmciLz4NCjx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBQcmlvcml0eT0iMjAiIFFG b3JtYXQ9InRydWUiIE5hbWU9IkVtcGhhc2lzIi8+DQo8dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJm YWxzZSIgU2VtaUhpZGRlbj0idHJ1ZSIgVW5oaWRlV2hlblVzZWQ9InRydWUiIE5hbWU9IkRvY3Vt ZW50IE1hcCIvPg0KPHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFNlbWlIaWRkZW49InRy dWUiIFVuaGlkZVdoZW5Vc2VkPSJ0cnVlIiBOYW1lPSJQbGFpbiBUZXh0Ii8+DQo8dzpMc2RFeGNl cHRpb24gTG9ja2VkPSJmYWxzZSIgU2VtaUhpZGRlbj0idHJ1ZSIgVW5oaWRlV2hlblVzZWQ9InRy dWUiIE5hbWU9IkUtbWFpbCBTaWduYXR1cmUiLz4NCjx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZh bHNlIiBTZW1pSGlkZGVuPSJ0cnVlIiBVbmhpZGVXaGVuVXNlZD0idHJ1ZSIgTmFtZT0iSFRNTCBU b3Agb2YgRm9ybSIvPg0KPHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFNlbWlIaWRkZW49 InRydWUiIFVuaGlkZVdoZW5Vc2VkPSJ0cnVlIiBOYW1lPSJIVE1MIEJvdHRvbSBvZiBGb3JtIi8+ DQo8dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJmYWxzZSIgU2VtaUhpZGRlbj0idHJ1ZSIgVW5oaWRl V2hlblVzZWQ9InRydWUiIE5hbWU9Ik5vcm1hbCAoV2ViKSIvPg0KPHc6THNkRXhjZXB0aW9uIExv Y2tlZD0iZmFsc2UiIFNlbWlIaWRkZW49InRydWUiIFVuaGlkZVdoZW5Vc2VkPSJ0cnVlIiBOYW1l PSJIVE1MIEFjcm9ueW0iLz4NCjx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBTZW1pSGlk ZGVuPSJ0cnVlIiBVbmhpZGVXaGVuVXNlZD0idHJ1ZSIgTmFtZT0iSFRNTCBBZGRyZXNzIi8+DQo8 dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJmYWxzZSIgU2VtaUhpZGRlbj0idHJ1ZSIgVW5oaWRlV2hl blVzZWQ9InRydWUiIE5hbWU9IkhUTUwgQ2l0ZSIvPg0KPHc6THNkRXhjZXB0aW9uIExvY2tlZD0i ZmFsc2UiIFNlbWlIaWRkZW49InRydWUiIFVuaGlkZVdoZW5Vc2VkPSJ0cnVlIiBOYW1lPSJIVE1M IENvZGUiLz4NCjx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBTZW1pSGlkZGVuPSJ0cnVl IiBVbmhpZGVXaGVuVXNlZD0idHJ1ZSIgTmFtZT0iSFRNTCBEZWZpbml0aW9uIi8+DQo8dzpMc2RF eGNlcHRpb24gTG9ja2VkPSJmYWxzZSIgU2VtaUhpZGRlbj0idHJ1ZSIgVW5oaWRlV2hlblVzZWQ9 InRydWUiIE5hbWU9IkhUTUwgS2V5Ym9hcmQiLz4NCjx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZh bHNlIiBTZW1pSGlkZGVuPSJ0cnVlIiBVbmhpZGVXaGVuVXNlZD0idHJ1ZSIgTmFtZT0iSFRNTCBQ cmVmb3JtYXR0ZWQiLz4NCjx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBTZW1pSGlkZGVu PSJ0cnVlIiBVbmhpZGVXaGVuVXNlZD0idHJ1ZSIgTmFtZT0iSFRNTCBTYW1wbGUiLz4NCjx3Okxz ZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBTZW1pSGlkZGVuPSJ0cnVlIiBVbmhpZGVXaGVuVXNl ZD0idHJ1ZSIgTmFtZT0iSFRNTCBUeXBld3JpdGVyIi8+DQo8dzpMc2RFeGNlcHRpb24gTG9ja2Vk PSJmYWxzZSIgU2VtaUhpZGRlbj0idHJ1ZSIgVW5oaWRlV2hlblVzZWQ9InRydWUiIE5hbWU9IkhU TUwgVmFyaWFibGUiLz4NCjx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBTZW1pSGlkZGVu PSJ0cnVlIiBVbmhpZGVXaGVuVXNlZD0idHJ1ZSIgTmFtZT0iTm9ybWFsIFRhYmxlIi8+DQo8dzpM c2RFeGNlcHRpb24gTG9ja2VkPSJmYWxzZSIgU2VtaUhpZGRlbj0idHJ1ZSIgVW5oaWRlV2hlblVz ZWQ9InRydWUiIE5hbWU9ImFubm90YXRpb24gc3ViamVjdCIvPg0KPHc6THNkRXhjZXB0aW9uIExv Y2tlZD0iZmFsc2UiIFNlbWlIaWRkZW49InRydWUiIFVuaGlkZVdoZW5Vc2VkPSJ0cnVlIiBOYW1l PSJObyBMaXN0Ii8+DQo8dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJmYWxzZSIgU2VtaUhpZGRlbj0i dHJ1ZSIgVW5oaWRlV2hlblVzZWQ9InRydWUiIE5hbWU9Ik91dGxpbmUgTGlzdCAxIi8+DQo8dzpM c2RFeGNlcHRpb24gTG9ja2VkPSJmYWxzZSIgU2VtaUhpZGRlbj0idHJ1ZSIgVW5oaWRlV2hlblVz ZWQ9InRydWUiIE5hbWU9Ik91dGxpbmUgTGlzdCAyIi8+DQo8dzpMc2RFeGNlcHRpb24gTG9ja2Vk PSJmYWxzZSIgU2VtaUhpZGRlbj0idHJ1ZSIgVW5oaWRlV2hlblVzZWQ9InRydWUiIE5hbWU9Ik91 dGxpbmUgTGlzdCAzIi8+DQo8dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJmYWxzZSIgU2VtaUhpZGRl bj0idHJ1ZSIgVW5oaWRlV2hlblVzZWQ9InRydWUiIE5hbWU9IlRhYmxlIFNpbXBsZSAxIi8+DQo8 dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJmYWxzZSIgU2VtaUhpZGRlbj0idHJ1ZSIgVW5oaWRlV2hl blVzZWQ9InRydWUiIE5hbWU9IlRhYmxlIFNpbXBsZSAyIi8+DQo8dzpMc2RFeGNlcHRpb24gTG9j a2VkPSJmYWxzZSIgU2VtaUhpZGRlbj0idHJ1ZSIgVW5oaWRlV2hlblVzZWQ9InRydWUiIE5hbWU9 IlRhYmxlIFNpbXBsZSAzIi8+DQo8dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJmYWxzZSIgU2VtaUhp ZGRlbj0idHJ1ZSIgVW5oaWRlV2hlblVzZWQ9InRydWUiIE5hbWU9IlRhYmxlIENsYXNzaWMgMSIv Pg0KPHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFNlbWlIaWRkZW49InRydWUiIFVuaGlk ZVdoZW5Vc2VkPSJ0cnVlIiBOYW1lPSJUYWJsZSBDbGFzc2ljIDIiLz4NCjx3OkxzZEV4Y2VwdGlv biBMb2NrZWQ9ImZhbHNlIiBTZW1pSGlkZGVuPSJ0cnVlIiBVbmhpZGVXaGVuVXNlZD0idHJ1ZSIg TmFtZT0iVGFibGUgQ2xhc3NpYyAzIi8+DQo8dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJmYWxzZSIg U2VtaUhpZGRlbj0idHJ1ZSIgVW5oaWRlV2hlblVzZWQ9InRydWUiIE5hbWU9IlRhYmxlIENsYXNz aWMgNCIvPg0KPHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFNlbWlIaWRkZW49InRydWUi IFVuaGlkZVdoZW5Vc2VkPSJ0cnVlIiBOYW1lPSJUYWJsZSBDb2xvcmZ1bCAxIi8+DQo8dzpMc2RF eGNlcHRpb24gTG9ja2VkPSJmYWxzZSIgU2VtaUhpZGRlbj0idHJ1ZSIgVW5oaWRlV2hlblVzZWQ9 InRydWUiIE5hbWU9IlRhYmxlIENvbG9yZnVsIDIiLz4NCjx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9 ImZhbHNlIiBTZW1pSGlkZGVuPSJ0cnVlIiBVbmhpZGVXaGVuVXNlZD0idHJ1ZSIgTmFtZT0iVGFi bGUgQ29sb3JmdWwgMyIvPg0KPHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFNlbWlIaWRk ZW49InRydWUiIFVuaGlkZVdoZW5Vc2VkPSJ0cnVlIiBOYW1lPSJUYWJsZSBDb2x1bW5zIDEiLz4N Cjx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBTZW1pSGlkZGVuPSJ0cnVlIiBVbmhpZGVX aGVuVXNlZD0idHJ1ZSIgTmFtZT0iVGFibGUgQ29sdW1ucyAyIi8+DQo8dzpMc2RFeGNlcHRpb24g TG9ja2VkPSJmYWxzZSIgU2VtaUhpZGRlbj0idHJ1ZSIgVW5oaWRlV2hlblVzZWQ9InRydWUiIE5h bWU9IlRhYmxlIENvbHVtbnMgMyIvPg0KPHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFNl bWlIaWRkZW49InRydWUiIFVuaGlkZVdoZW5Vc2VkPSJ0cnVlIiBOYW1lPSJUYWJsZSBDb2x1bW5z IDQiLz4NCjx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBTZW1pSGlkZGVuPSJ0cnVlIiBV bmhpZGVXaGVuVXNlZD0idHJ1ZSIgTmFtZT0iVGFibGUgQ29sdW1ucyA1Ii8+DQo8dzpMc2RFeGNl cHRpb24gTG9ja2VkPSJmYWxzZSIgU2VtaUhpZGRlbj0idHJ1ZSIgVW5oaWRlV2hlblVzZWQ9InRy dWUiIE5hbWU9IlRhYmxlIEdyaWQgMSIvPg0KPHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFsc2Ui IFNlbWlIaWRkZW49InRydWUiIFVuaGlkZVdoZW5Vc2VkPSJ0cnVlIiBOYW1lPSJUYWJsZSBHcmlk IDIiLz4NCjx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBTZW1pSGlkZGVuPSJ0cnVlIiBV bmhpZGVXaGVuVXNlZD0idHJ1ZSIgTmFtZT0iVGFibGUgR3JpZCAzIi8+DQo8dzpMc2RFeGNlcHRp b24gTG9ja2VkPSJmYWxzZSIgU2VtaUhpZGRlbj0idHJ1ZSIgVW5oaWRlV2hlblVzZWQ9InRydWUi IE5hbWU9IlRhYmxlIEdyaWQgNCIvPg0KPHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFNl bWlIaWRkZW49InRydWUiIFVuaGlkZVdoZW5Vc2VkPSJ0cnVlIiBOYW1lPSJUYWJsZSBHcmlkIDUi Lz4NCjx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBTZW1pSGlkZGVuPSJ0cnVlIiBVbmhp ZGVXaGVuVXNlZD0idHJ1ZSIgTmFtZT0iVGFibGUgR3JpZCA2Ii8+DQo8dzpMc2RFeGNlcHRpb24g TG9ja2VkPSJmYWxzZSIgU2VtaUhpZGRlbj0idHJ1ZSIgVW5oaWRlV2hlblVzZWQ9InRydWUiIE5h bWU9IlRhYmxlIEdyaWQgNyIvPg0KPHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFNlbWlI aWRkZW49InRydWUiIFVuaGlkZVdoZW5Vc2VkPSJ0cnVlIiBOYW1lPSJUYWJsZSBHcmlkIDgiLz4N Cjx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBTZW1pSGlkZGVuPSJ0cnVlIiBVbmhpZGVX aGVuVXNlZD0idHJ1ZSIgTmFtZT0iVGFibGUgTGlzdCAxIi8+DQo8dzpMc2RFeGNlcHRpb24gTG9j a2VkPSJmYWxzZSIgU2VtaUhpZGRlbj0idHJ1ZSIgVW5oaWRlV2hlblVzZWQ9InRydWUiIE5hbWU9 IlRhYmxlIExpc3QgMiIvPg0KPHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFNlbWlIaWRk ZW49InRydWUiIFVuaGlkZVdoZW5Vc2VkPSJ0cnVlIiBOYW1lPSJUYWJsZSBMaXN0IDMiLz4NCjx3 OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBTZW1pSGlkZGVuPSJ0cnVlIiBVbmhpZGVXaGVu VXNlZD0idHJ1ZSIgTmFtZT0iVGFibGUgTGlzdCA0Ii8+DQo8dzpMc2RFeGNlcHRpb24gTG9ja2Vk PSJmYWxzZSIgU2VtaUhpZGRlbj0idHJ1ZSIgVW5oaWRlV2hlblVzZWQ9InRydWUiIE5hbWU9IlRh YmxlIExpc3QgNSIvPg0KPHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFNlbWlIaWRkZW49 InRydWUiIFVuaGlkZVdoZW5Vc2VkPSJ0cnVlIiBOYW1lPSJUYWJsZSBMaXN0IDYiLz4NCjx3Okxz ZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBTZW1pSGlkZGVuPSJ0cnVlIiBVbmhpZGVXaGVuVXNl ZD0idHJ1ZSIgTmFtZT0iVGFibGUgTGlzdCA3Ii8+DQo8dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJm YWxzZSIgU2VtaUhpZGRlbj0idHJ1ZSIgVW5oaWRlV2hlblVzZWQ9InRydWUiIE5hbWU9IlRhYmxl IExpc3QgOCIvPg0KPHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFNlbWlIaWRkZW49InRy dWUiIFVuaGlkZVdoZW5Vc2VkPSJ0cnVlIiBOYW1lPSJUYWJsZSAzRCBlZmZlY3RzIDEiLz4NCjx3 OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBTZW1pSGlkZGVuPSJ0cnVlIiBVbmhpZGVXaGVu VXNlZD0idHJ1ZSIgTmFtZT0iVGFibGUgM0QgZWZmZWN0cyAyIi8+DQo8dzpMc2RFeGNlcHRpb24g TG9ja2VkPSJmYWxzZSIgU2VtaUhpZGRlbj0idHJ1ZSIgVW5oaWRlV2hlblVzZWQ9InRydWUiIE5h bWU9IlRhYmxlIDNEIGVmZmVjdHMgMyIvPg0KPHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFsc2Ui IFNlbWlIaWRkZW49InRydWUiIFVuaGlkZVdoZW5Vc2VkPSJ0cnVlIiBOYW1lPSJUYWJsZSBDb250 ZW1wb3JhcnkiLz4NCjx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBTZW1pSGlkZGVuPSJ0 cnVlIiBVbmhpZGVXaGVuVXNlZD0idHJ1ZSIgTmFtZT0iVGFibGUgRWxlZ2FudCIvPg0KPHc6THNk RXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFNlbWlIaWRkZW49InRydWUiIFVuaGlkZVdoZW5Vc2Vk PSJ0cnVlIiBOYW1lPSJUYWJsZSBQcm9mZXNzaW9uYWwiLz4NCjx3OkxzZEV4Y2VwdGlvbiBMb2Nr ZWQ9ImZhbHNlIiBTZW1pSGlkZGVuPSJ0cnVlIiBVbmhpZGVXaGVuVXNlZD0idHJ1ZSIgTmFtZT0i VGFibGUgU3VidGxlIDEiLz4NCjx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBTZW1pSGlk ZGVuPSJ0cnVlIiBVbmhpZGVXaGVuVXNlZD0idHJ1ZSIgTmFtZT0iVGFibGUgU3VidGxlIDIiLz4N Cjx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBTZW1pSGlkZGVuPSJ0cnVlIiBVbmhpZGVX aGVuVXNlZD0idHJ1ZSIgTmFtZT0iVGFibGUgV2ViIDEiLz4NCjx3OkxzZEV4Y2VwdGlvbiBMb2Nr ZWQ9ImZhbHNlIiBTZW1pSGlkZGVuPSJ0cnVlIiBVbmhpZGVXaGVuVXNlZD0idHJ1ZSIgTmFtZT0i VGFibGUgV2ViIDIiLz4NCjx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBTZW1pSGlkZGVu PSJ0cnVlIiBVbmhpZGVXaGVuVXNlZD0idHJ1ZSIgTmFtZT0iVGFibGUgV2ViIDMiLz4NCjx3Okxz ZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBTZW1pSGlkZGVuPSJ0cnVlIiBVbmhpZGVXaGVuVXNl ZD0idHJ1ZSIgTmFtZT0iQmFsbG9vbiBUZXh0Ii8+DQo8dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJm YWxzZSIgUHJpb3JpdHk9IjU5IiBOYW1lPSJUYWJsZSBHcmlkIi8+DQo8dzpMc2RFeGNlcHRpb24g TG9ja2VkPSJmYWxzZSIgU2VtaUhpZGRlbj0idHJ1ZSIgVW5oaWRlV2hlblVzZWQ9InRydWUiIE5h bWU9IlRhYmxlIFRoZW1lIi8+DQo8dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJmYWxzZSIgU2VtaUhp ZGRlbj0idHJ1ZSIgTmFtZT0iUGxhY2Vob2xkZXIgVGV4dCIvPg0KPHc6THNkRXhjZXB0aW9uIExv Y2tlZD0iZmFsc2UiIFByaW9yaXR5PSIxIiBRRm9ybWF0PSJ0cnVlIiBOYW1lPSJObyBTcGFjaW5n Ii8+DQo8dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJmYWxzZSIgUHJpb3JpdHk9IjYwIiBOYW1lPSJM aWdodCBTaGFkaW5nIi8+DQo8dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJmYWxzZSIgUHJpb3JpdHk9 IjYxIiBOYW1lPSJMaWdodCBMaXN0Ii8+DQo8dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJmYWxzZSIg UHJpb3JpdHk9IjYyIiBOYW1lPSJMaWdodCBHcmlkIi8+DQo8dzpMc2RFeGNlcHRpb24gTG9ja2Vk PSJmYWxzZSIgUHJpb3JpdHk9IjYzIiBOYW1lPSJNZWRpdW0gU2hhZGluZyAxIi8+DQo8dzpMc2RF eGNlcHRpb24gTG9ja2VkPSJmYWxzZSIgUHJpb3JpdHk9IjY0IiBOYW1lPSJNZWRpdW0gU2hhZGlu ZyAyIi8+DQo8dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJmYWxzZSIgUHJpb3JpdHk9IjY1IiBOYW1l PSJNZWRpdW0gTGlzdCAxIi8+DQo8dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJmYWxzZSIgUHJpb3Jp dHk9IjY2IiBOYW1lPSJNZWRpdW0gTGlzdCAyIi8+DQo8dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJm YWxzZSIgUHJpb3JpdHk9IjY3IiBOYW1lPSJNZWRpdW0gR3JpZCAxIi8+DQo8dzpMc2RFeGNlcHRp b24gTG9ja2VkPSJmYWxzZSIgUHJpb3JpdHk9IjY4IiBOYW1lPSJNZWRpdW0gR3JpZCAyIi8+DQo8 dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJmYWxzZSIgUHJpb3JpdHk9IjY5IiBOYW1lPSJNZWRpdW0g R3JpZCAzIi8+DQo8dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJmYWxzZSIgUHJpb3JpdHk9IjcwIiBO YW1lPSJEYXJrIExpc3QiLz4NCjx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBQcmlvcml0 eT0iNzEiIE5hbWU9IkNvbG9yZnVsIFNoYWRpbmciLz4NCjx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9 ImZhbHNlIiBQcmlvcml0eT0iNzIiIE5hbWU9IkNvbG9yZnVsIExpc3QiLz4NCjx3OkxzZEV4Y2Vw dGlvbiBMb2NrZWQ9ImZhbHNlIiBQcmlvcml0eT0iNzMiIE5hbWU9IkNvbG9yZnVsIEdyaWQiLz4N Cjx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBQcmlvcml0eT0iNjAiIE5hbWU9IkxpZ2h0 IFNoYWRpbmcgQWNjZW50IDEiLz4NCjx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBQcmlv cml0eT0iNjEiIE5hbWU9IkxpZ2h0IExpc3QgQWNjZW50IDEiLz4NCjx3OkxzZEV4Y2VwdGlvbiBM b2NrZWQ9ImZhbHNlIiBQcmlvcml0eT0iNjIiIE5hbWU9IkxpZ2h0IEdyaWQgQWNjZW50IDEiLz4N Cjx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBQcmlvcml0eT0iNjMiIE5hbWU9Ik1lZGl1 bSBTaGFkaW5nIDEgQWNjZW50IDEiLz4NCjx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBQ cmlvcml0eT0iNjQiIE5hbWU9Ik1lZGl1bSBTaGFkaW5nIDIgQWNjZW50IDEiLz4NCjx3OkxzZEV4 Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBQcmlvcml0eT0iNjUiIE5hbWU9Ik1lZGl1bSBMaXN0IDEg QWNjZW50IDEiLz4NCjx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBTZW1pSGlkZGVuPSJ0 cnVlIiBOYW1lPSJSZXZpc2lvbiIvPg0KPHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFBy aW9yaXR5PSIzNCIgUUZvcm1hdD0idHJ1ZSIgTmFtZT0iTGlzdCBQYXJhZ3JhcGgiLz4NCjx3Okxz ZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBQcmlvcml0eT0iMjkiIFFGb3JtYXQ9InRydWUiIE5h bWU9IlF1b3RlIi8+DQo8dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJmYWxzZSIgUHJpb3JpdHk9IjMw IiBRRm9ybWF0PSJ0cnVlIiBOYW1lPSJJbnRlbnNlIFF1b3RlIi8+DQo8dzpMc2RFeGNlcHRpb24g TG9ja2VkPSJmYWxzZSIgUHJpb3JpdHk9IjY2IiBOYW1lPSJNZWRpdW0gTGlzdCAyIEFjY2VudCAx Ii8+DQo8dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJmYWxzZSIgUHJpb3JpdHk9IjY3IiBOYW1lPSJN ZWRpdW0gR3JpZCAxIEFjY2VudCAxIi8+DQo8dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJmYWxzZSIg UHJpb3JpdHk9IjY4IiBOYW1lPSJNZWRpdW0gR3JpZCAyIEFjY2VudCAxIi8+DQo8dzpMc2RFeGNl cHRpb24gTG9ja2VkPSJmYWxzZSIgUHJpb3JpdHk9IjY5IiBOYW1lPSJNZWRpdW0gR3JpZCAzIEFj Y2VudCAxIi8+DQo8dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJmYWxzZSIgUHJpb3JpdHk9IjcwIiBO YW1lPSJEYXJrIExpc3QgQWNjZW50IDEiLz4NCjx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNl IiBQcmlvcml0eT0iNzEiIE5hbWU9IkNvbG9yZnVsIFNoYWRpbmcgQWNjZW50IDEiLz4NCjx3Okxz ZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBQcmlvcml0eT0iNzIiIE5hbWU9IkNvbG9yZnVsIExp c3QgQWNjZW50IDEiLz4NCjx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBQcmlvcml0eT0i NzMiIE5hbWU9IkNvbG9yZnVsIEdyaWQgQWNjZW50IDEiLz4NCjx3OkxzZEV4Y2VwdGlvbiBMb2Nr ZWQ9ImZhbHNlIiBQcmlvcml0eT0iNjAiIE5hbWU9IkxpZ2h0IFNoYWRpbmcgQWNjZW50IDIiLz4N Cjx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBQcmlvcml0eT0iNjEiIE5hbWU9IkxpZ2h0 IExpc3QgQWNjZW50IDIiLz4NCjx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBQcmlvcml0 eT0iNjIiIE5hbWU9IkxpZ2h0IEdyaWQgQWNjZW50IDIiLz4NCjx3OkxzZEV4Y2VwdGlvbiBMb2Nr ZWQ9ImZhbHNlIiBQcmlvcml0eT0iNjMiIE5hbWU9Ik1lZGl1bSBTaGFkaW5nIDEgQWNjZW50IDIi Lz4NCjx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBQcmlvcml0eT0iNjQiIE5hbWU9Ik1l ZGl1bSBTaGFkaW5nIDIgQWNjZW50IDIiLz4NCjx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNl IiBQcmlvcml0eT0iNjUiIE5hbWU9Ik1lZGl1bSBMaXN0IDEgQWNjZW50IDIiLz4NCjx3OkxzZEV4 Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBQcmlvcml0eT0iNjYiIE5hbWU9Ik1lZGl1bSBMaXN0IDIg QWNjZW50IDIiLz4NCjx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBQcmlvcml0eT0iNjci IE5hbWU9Ik1lZGl1bSBHcmlkIDEgQWNjZW50IDIiLz4NCjx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9 ImZhbHNlIiBQcmlvcml0eT0iNjgiIE5hbWU9Ik1lZGl1bSBHcmlkIDIgQWNjZW50IDIiLz4NCjx3 OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBQcmlvcml0eT0iNjkiIE5hbWU9Ik1lZGl1bSBH cmlkIDMgQWNjZW50IDIiLz4NCjx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBQcmlvcml0 eT0iNzAiIE5hbWU9IkRhcmsgTGlzdCBBY2NlbnQgMiIvPg0KPHc6THNkRXhjZXB0aW9uIExvY2tl ZD0iZmFsc2UiIFByaW9yaXR5PSI3MSIgTmFtZT0iQ29sb3JmdWwgU2hhZGluZyBBY2NlbnQgMiIv Pg0KPHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFByaW9yaXR5PSI3MiIgTmFtZT0iQ29s b3JmdWwgTGlzdCBBY2NlbnQgMiIvPg0KPHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFBy aW9yaXR5PSI3MyIgTmFtZT0iQ29sb3JmdWwgR3JpZCBBY2NlbnQgMiIvPg0KPHc6THNkRXhjZXB0 aW9uIExvY2tlZD0iZmFsc2UiIFByaW9yaXR5PSI2MCIgTmFtZT0iTGlnaHQgU2hhZGluZyBBY2Nl bnQgMyIvPg0KPHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFByaW9yaXR5PSI2MSIgTmFt ZT0iTGlnaHQgTGlzdCBBY2NlbnQgMyIvPg0KPHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFsc2Ui IFByaW9yaXR5PSI2MiIgTmFtZT0iTGlnaHQgR3JpZCBBY2NlbnQgMyIvPg0KPHc6THNkRXhjZXB0 aW9uIExvY2tlZD0iZmFsc2UiIFByaW9yaXR5PSI2MyIgTmFtZT0iTWVkaXVtIFNoYWRpbmcgMSBB Y2NlbnQgMyIvPg0KPHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFByaW9yaXR5PSI2NCIg TmFtZT0iTWVkaXVtIFNoYWRpbmcgMiBBY2NlbnQgMyIvPg0KPHc6THNkRXhjZXB0aW9uIExvY2tl ZD0iZmFsc2UiIFByaW9yaXR5PSI2NSIgTmFtZT0iTWVkaXVtIExpc3QgMSBBY2NlbnQgMyIvPg0K PHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFByaW9yaXR5PSI2NiIgTmFtZT0iTWVkaXVt IExpc3QgMiBBY2NlbnQgMyIvPg0KPHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFByaW9y aXR5PSI2NyIgTmFtZT0iTWVkaXVtIEdyaWQgMSBBY2NlbnQgMyIvPg0KPHc6THNkRXhjZXB0aW9u IExvY2tlZD0iZmFsc2UiIFByaW9yaXR5PSI2OCIgTmFtZT0iTWVkaXVtIEdyaWQgMiBBY2NlbnQg MyIvPg0KPHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFByaW9yaXR5PSI2OSIgTmFtZT0i TWVkaXVtIEdyaWQgMyBBY2NlbnQgMyIvPg0KPHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFsc2Ui IFByaW9yaXR5PSI3MCIgTmFtZT0iRGFyayBMaXN0IEFjY2VudCAzIi8+DQo8dzpMc2RFeGNlcHRp b24gTG9ja2VkPSJmYWxzZSIgUHJpb3JpdHk9IjcxIiBOYW1lPSJDb2xvcmZ1bCBTaGFkaW5nIEFj Y2VudCAzIi8+DQo8dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJmYWxzZSIgUHJpb3JpdHk9IjcyIiBO YW1lPSJDb2xvcmZ1bCBMaXN0IEFjY2VudCAzIi8+DQo8dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJm YWxzZSIgUHJpb3JpdHk9IjczIiBOYW1lPSJDb2xvcmZ1bCBHcmlkIEFjY2VudCAzIi8+DQo8dzpM c2RFeGNlcHRpb24gTG9ja2VkPSJmYWxzZSIgUHJpb3JpdHk9IjYwIiBOYW1lPSJMaWdodCBTaGFk aW5nIEFjY2VudCA0Ii8+DQo8dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJmYWxzZSIgUHJpb3JpdHk9 IjYxIiBOYW1lPSJMaWdodCBMaXN0IEFjY2VudCA0Ii8+DQo8dzpMc2RFeGNlcHRpb24gTG9ja2Vk PSJmYWxzZSIgUHJpb3JpdHk9IjYyIiBOYW1lPSJMaWdodCBHcmlkIEFjY2VudCA0Ii8+DQo8dzpM c2RFeGNlcHRpb24gTG9ja2VkPSJmYWxzZSIgUHJpb3JpdHk9IjYzIiBOYW1lPSJNZWRpdW0gU2hh ZGluZyAxIEFjY2VudCA0Ii8+DQo8dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJmYWxzZSIgUHJpb3Jp dHk9IjY0IiBOYW1lPSJNZWRpdW0gU2hhZGluZyAyIEFjY2VudCA0Ii8+DQo8dzpMc2RFeGNlcHRp b24gTG9ja2VkPSJmYWxzZSIgUHJpb3JpdHk9IjY1IiBOYW1lPSJNZWRpdW0gTGlzdCAxIEFjY2Vu dCA0Ii8+DQo8dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJmYWxzZSIgUHJpb3JpdHk9IjY2IiBOYW1l PSJNZWRpdW0gTGlzdCAyIEFjY2VudCA0Ii8+DQo8dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJmYWxz ZSIgUHJpb3JpdHk9IjY3IiBOYW1lPSJNZWRpdW0gR3JpZCAxIEFjY2VudCA0Ii8+DQo8dzpMc2RF eGNlcHRpb24gTG9ja2VkPSJmYWxzZSIgUHJpb3JpdHk9IjY4IiBOYW1lPSJNZWRpdW0gR3JpZCAy IEFjY2VudCA0Ii8+DQo8dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJmYWxzZSIgUHJpb3JpdHk9IjY5 IiBOYW1lPSJNZWRpdW0gR3JpZCAzIEFjY2VudCA0Ii8+DQo8dzpMc2RFeGNlcHRpb24gTG9ja2Vk PSJmYWxzZSIgUHJpb3JpdHk9IjcwIiBOYW1lPSJEYXJrIExpc3QgQWNjZW50IDQiLz4NCjx3Okxz ZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBQcmlvcml0eT0iNzEiIE5hbWU9IkNvbG9yZnVsIFNo YWRpbmcgQWNjZW50IDQiLz4NCjx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBQcmlvcml0 eT0iNzIiIE5hbWU9IkNvbG9yZnVsIExpc3QgQWNjZW50IDQiLz4NCjx3OkxzZEV4Y2VwdGlvbiBM b2NrZWQ9ImZhbHNlIiBQcmlvcml0eT0iNzMiIE5hbWU9IkNvbG9yZnVsIEdyaWQgQWNjZW50IDQi Lz4NCjx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBQcmlvcml0eT0iNjAiIE5hbWU9Ikxp Z2h0IFNoYWRpbmcgQWNjZW50IDUiLz4NCjx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBQ cmlvcml0eT0iNjEiIE5hbWU9IkxpZ2h0IExpc3QgQWNjZW50IDUiLz4NCjx3OkxzZEV4Y2VwdGlv biBMb2NrZWQ9ImZhbHNlIiBQcmlvcml0eT0iNjIiIE5hbWU9IkxpZ2h0IEdyaWQgQWNjZW50IDUi Lz4NCjx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBQcmlvcml0eT0iNjMiIE5hbWU9Ik1l ZGl1bSBTaGFkaW5nIDEgQWNjZW50IDUiLz4NCjx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNl IiBQcmlvcml0eT0iNjQiIE5hbWU9Ik1lZGl1bSBTaGFkaW5nIDIgQWNjZW50IDUiLz4NCjx3Okxz ZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBQcmlvcml0eT0iNjUiIE5hbWU9Ik1lZGl1bSBMaXN0 IDEgQWNjZW50IDUiLz4NCjx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBQcmlvcml0eT0i NjYiIE5hbWU9Ik1lZGl1bSBMaXN0IDIgQWNjZW50IDUiLz4NCjx3OkxzZEV4Y2VwdGlvbiBMb2Nr ZWQ9ImZhbHNlIiBQcmlvcml0eT0iNjciIE5hbWU9Ik1lZGl1bSBHcmlkIDEgQWNjZW50IDUiLz4N Cjx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBQcmlvcml0eT0iNjgiIE5hbWU9Ik1lZGl1 bSBHcmlkIDIgQWNjZW50IDUiLz4NCjx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBQcmlv cml0eT0iNjkiIE5hbWU9Ik1lZGl1bSBHcmlkIDMgQWNjZW50IDUiLz4NCjx3OkxzZEV4Y2VwdGlv biBMb2NrZWQ9ImZhbHNlIiBQcmlvcml0eT0iNzAiIE5hbWU9IkRhcmsgTGlzdCBBY2NlbnQgNSIv Pg0KPHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFByaW9yaXR5PSI3MSIgTmFtZT0iQ29s b3JmdWwgU2hhZGluZyBBY2NlbnQgNSIvPg0KPHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFsc2Ui IFByaW9yaXR5PSI3MiIgTmFtZT0iQ29sb3JmdWwgTGlzdCBBY2NlbnQgNSIvPg0KPHc6THNkRXhj ZXB0aW9uIExvY2tlZD0iZmFsc2UiIFByaW9yaXR5PSI3MyIgTmFtZT0iQ29sb3JmdWwgR3JpZCBB Y2NlbnQgNSIvPg0KPHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFByaW9yaXR5PSI2MCIg TmFtZT0iTGlnaHQgU2hhZGluZyBBY2NlbnQgNiIvPg0KPHc6THNkRXhjZXB0aW9uIExvY2tlZD0i ZmFsc2UiIFByaW9yaXR5PSI2MSIgTmFtZT0iTGlnaHQgTGlzdCBBY2NlbnQgNiIvPg0KPHc6THNk RXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFByaW9yaXR5PSI2MiIgTmFtZT0iTGlnaHQgR3JpZCBB Y2NlbnQgNiIvPg0KPHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFByaW9yaXR5PSI2MyIg TmFtZT0iTWVkaXVtIFNoYWRpbmcgMSBBY2NlbnQgNiIvPg0KPHc6THNkRXhjZXB0aW9uIExvY2tl ZD0iZmFsc2UiIFByaW9yaXR5PSI2NCIgTmFtZT0iTWVkaXVtIFNoYWRpbmcgMiBBY2NlbnQgNiIv Pg0KPHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFByaW9yaXR5PSI2NSIgTmFtZT0iTWVk aXVtIExpc3QgMSBBY2NlbnQgNiIvPg0KPHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFBy aW9yaXR5PSI2NiIgTmFtZT0iTWVkaXVtIExpc3QgMiBBY2NlbnQgNiIvPg0KPHc6THNkRXhjZXB0 aW9uIExvY2tlZD0iZmFsc2UiIFByaW9yaXR5PSI2NyIgTmFtZT0iTWVkaXVtIEdyaWQgMSBBY2Nl bnQgNiIvPg0KPHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFByaW9yaXR5PSI2OCIgTmFt ZT0iTWVkaXVtIEdyaWQgMiBBY2NlbnQgNiIvPg0KPHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFs c2UiIFByaW9yaXR5PSI2OSIgTmFtZT0iTWVkaXVtIEdyaWQgMyBBY2NlbnQgNiIvPg0KPHc6THNk RXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFByaW9yaXR5PSI3MCIgTmFtZT0iRGFyayBMaXN0IEFj Y2VudCA2Ii8+DQo8dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJmYWxzZSIgUHJpb3JpdHk9IjcxIiBO YW1lPSJDb2xvcmZ1bCBTaGFkaW5nIEFjY2VudCA2Ii8+DQo8dzpMc2RFeGNlcHRpb24gTG9ja2Vk PSJmYWxzZSIgUHJpb3JpdHk9IjcyIiBOYW1lPSJDb2xvcmZ1bCBMaXN0IEFjY2VudCA2Ii8+DQo8 dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJmYWxzZSIgUHJpb3JpdHk9IjczIiBOYW1lPSJDb2xvcmZ1 bCBHcmlkIEFjY2VudCA2Ii8+DQo8dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJmYWxzZSIgUHJpb3Jp dHk9IjE5IiBRRm9ybWF0PSJ0cnVlIiBOYW1lPSJTdWJ0bGUgRW1waGFzaXMiLz4NCjx3OkxzZEV4 Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBQcmlvcml0eT0iMjEiIFFGb3JtYXQ9InRydWUiIE5hbWU9 IkludGVuc2UgRW1waGFzaXMiLz4NCjx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBQcmlv cml0eT0iMzEiIFFGb3JtYXQ9InRydWUiIE5hbWU9IlN1YnRsZSBSZWZlcmVuY2UiLz4NCjx3Okxz ZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBQcmlvcml0eT0iMzIiIFFGb3JtYXQ9InRydWUiIE5h bWU9IkludGVuc2UgUmVmZXJlbmNlIi8+DQo8dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJmYWxzZSIg UHJpb3JpdHk9IjMzIiBRRm9ybWF0PSJ0cnVlIiBOYW1lPSJCb29rIFRpdGxlIi8+DQo8dzpMc2RF eGNlcHRpb24gTG9ja2VkPSJmYWxzZSIgUHJpb3JpdHk9IjM3IiBTZW1pSGlkZGVuPSJ0cnVlIiBV bmhpZGVXaGVuVXNlZD0idHJ1ZSIgTmFtZT0iQmlibGlvZ3JhcGh5Ii8+DQo8dzpMc2RFeGNlcHRp b24gTG9ja2VkPSJmYWxzZSIgUHJpb3JpdHk9IjM5IiBTZW1pSGlkZGVuPSJ0cnVlIiBVbmhpZGVX aGVuVXNlZD0idHJ1ZSIgUUZvcm1hdD0idHJ1ZSIgTmFtZT0iVE9DIEhlYWRpbmciLz4NCjx3Okxz ZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBQcmlvcml0eT0iNDEiIE5hbWU9IlBsYWluIFRhYmxl IDEiLz4NCjx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBQcmlvcml0eT0iNDIiIE5hbWU9 IlBsYWluIFRhYmxlIDIiLz4NCjx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBQcmlvcml0 eT0iNDMiIE5hbWU9IlBsYWluIFRhYmxlIDMiLz4NCjx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZh bHNlIiBQcmlvcml0eT0iNDQiIE5hbWU9IlBsYWluIFRhYmxlIDQiLz4NCjx3OkxzZEV4Y2VwdGlv biBMb2NrZWQ9ImZhbHNlIiBQcmlvcml0eT0iNDUiIE5hbWU9IlBsYWluIFRhYmxlIDUiLz4NCjx3 OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBQcmlvcml0eT0iNDAiIE5hbWU9IkdyaWQgVGFi bGUgTGlnaHQiLz4NCjx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBQcmlvcml0eT0iNDYi IE5hbWU9IkdyaWQgVGFibGUgMSBMaWdodCIvPg0KPHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFs c2UiIFByaW9yaXR5PSI0NyIgTmFtZT0iR3JpZCBUYWJsZSAyIi8+DQo8dzpMc2RFeGNlcHRpb24g TG9ja2VkPSJmYWxzZSIgUHJpb3JpdHk9IjQ4IiBOYW1lPSJHcmlkIFRhYmxlIDMiLz4NCjx3Okxz ZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBQcmlvcml0eT0iNDkiIE5hbWU9IkdyaWQgVGFibGUg NCIvPg0KPHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFByaW9yaXR5PSI1MCIgTmFtZT0i R3JpZCBUYWJsZSA1IERhcmsiLz4NCjx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBQcmlv cml0eT0iNTEiIE5hbWU9IkdyaWQgVGFibGUgNiBDb2xvcmZ1bCIvPg0KPHc6THNkRXhjZXB0aW9u IExvY2tlZD0iZmFsc2UiIFByaW9yaXR5PSI1MiIgTmFtZT0iR3JpZCBUYWJsZSA3IENvbG9yZnVs Ii8+DQo8dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJmYWxzZSIgUHJpb3JpdHk9IjQ2IiBOYW1lPSJH cmlkIFRhYmxlIDEgTGlnaHQgQWNjZW50IDEiLz4NCjx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZh bHNlIiBQcmlvcml0eT0iNDciIE5hbWU9IkdyaWQgVGFibGUgMiBBY2NlbnQgMSIvPg0KPHc6THNk RXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFByaW9yaXR5PSI0OCIgTmFtZT0iR3JpZCBUYWJsZSAz IEFjY2VudCAxIi8+DQo8dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJmYWxzZSIgUHJpb3JpdHk9IjQ5 IiBOYW1lPSJHcmlkIFRhYmxlIDQgQWNjZW50IDEiLz4NCjx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9 ImZhbHNlIiBQcmlvcml0eT0iNTAiIE5hbWU9IkdyaWQgVGFibGUgNSBEYXJrIEFjY2VudCAxIi8+ DQo8dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJmYWxzZSIgUHJpb3JpdHk9IjUxIiBOYW1lPSJHcmlk IFRhYmxlIDYgQ29sb3JmdWwgQWNjZW50IDEiLz4NCjx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZh bHNlIiBQcmlvcml0eT0iNTIiIE5hbWU9IkdyaWQgVGFibGUgNyBDb2xvcmZ1bCBBY2NlbnQgMSIv Pg0KPHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFByaW9yaXR5PSI0NiIgTmFtZT0iR3Jp ZCBUYWJsZSAxIExpZ2h0IEFjY2VudCAyIi8+DQo8dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJmYWxz ZSIgUHJpb3JpdHk9IjQ3IiBOYW1lPSJHcmlkIFRhYmxlIDIgQWNjZW50IDIiLz4NCjx3OkxzZEV4 Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBQcmlvcml0eT0iNDgiIE5hbWU9IkdyaWQgVGFibGUgMyBB Y2NlbnQgMiIvPg0KPHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFByaW9yaXR5PSI0OSIg TmFtZT0iR3JpZCBUYWJsZSA0IEFjY2VudCAyIi8+DQo8dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJm YWxzZSIgUHJpb3JpdHk9IjUwIiBOYW1lPSJHcmlkIFRhYmxlIDUgRGFyayBBY2NlbnQgMiIvPg0K PHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFByaW9yaXR5PSI1MSIgTmFtZT0iR3JpZCBU YWJsZSA2IENvbG9yZnVsIEFjY2VudCAyIi8+DQo8dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJmYWxz ZSIgUHJpb3JpdHk9IjUyIiBOYW1lPSJHcmlkIFRhYmxlIDcgQ29sb3JmdWwgQWNjZW50IDIiLz4N Cjx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBQcmlvcml0eT0iNDYiIE5hbWU9IkdyaWQg VGFibGUgMSBMaWdodCBBY2NlbnQgMyIvPg0KPHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFsc2Ui IFByaW9yaXR5PSI0NyIgTmFtZT0iR3JpZCBUYWJsZSAyIEFjY2VudCAzIi8+DQo8dzpMc2RFeGNl cHRpb24gTG9ja2VkPSJmYWxzZSIgUHJpb3JpdHk9IjQ4IiBOYW1lPSJHcmlkIFRhYmxlIDMgQWNj ZW50IDMiLz4NCjx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBQcmlvcml0eT0iNDkiIE5h bWU9IkdyaWQgVGFibGUgNCBBY2NlbnQgMyIvPg0KPHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFs c2UiIFByaW9yaXR5PSI1MCIgTmFtZT0iR3JpZCBUYWJsZSA1IERhcmsgQWNjZW50IDMiLz4NCjx3 OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBQcmlvcml0eT0iNTEiIE5hbWU9IkdyaWQgVGFi bGUgNiBDb2xvcmZ1bCBBY2NlbnQgMyIvPg0KPHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFsc2Ui IFByaW9yaXR5PSI1MiIgTmFtZT0iR3JpZCBUYWJsZSA3IENvbG9yZnVsIEFjY2VudCAzIi8+DQo8 dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJmYWxzZSIgUHJpb3JpdHk9IjQ2IiBOYW1lPSJHcmlkIFRh YmxlIDEgTGlnaHQgQWNjZW50IDQiLz4NCjx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBQ cmlvcml0eT0iNDciIE5hbWU9IkdyaWQgVGFibGUgMiBBY2NlbnQgNCIvPg0KPHc6THNkRXhjZXB0 aW9uIExvY2tlZD0iZmFsc2UiIFByaW9yaXR5PSI0OCIgTmFtZT0iR3JpZCBUYWJsZSAzIEFjY2Vu dCA0Ii8+DQo8dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJmYWxzZSIgUHJpb3JpdHk9IjQ5IiBOYW1l PSJHcmlkIFRhYmxlIDQgQWNjZW50IDQiLz4NCjx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNl IiBQcmlvcml0eT0iNTAiIE5hbWU9IkdyaWQgVGFibGUgNSBEYXJrIEFjY2VudCA0Ii8+DQo8dzpM c2RFeGNlcHRpb24gTG9ja2VkPSJmYWxzZSIgUHJpb3JpdHk9IjUxIiBOYW1lPSJHcmlkIFRhYmxl IDYgQ29sb3JmdWwgQWNjZW50IDQiLz4NCjx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBQ cmlvcml0eT0iNTIiIE5hbWU9IkdyaWQgVGFibGUgNyBDb2xvcmZ1bCBBY2NlbnQgNCIvPg0KPHc6 THNkRXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFByaW9yaXR5PSI0NiIgTmFtZT0iR3JpZCBUYWJs ZSAxIExpZ2h0IEFjY2VudCA1Ii8+DQo8dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJmYWxzZSIgUHJp b3JpdHk9IjQ3IiBOYW1lPSJHcmlkIFRhYmxlIDIgQWNjZW50IDUiLz4NCjx3OkxzZEV4Y2VwdGlv biBMb2NrZWQ9ImZhbHNlIiBQcmlvcml0eT0iNDgiIE5hbWU9IkdyaWQgVGFibGUgMyBBY2NlbnQg NSIvPg0KPHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFByaW9yaXR5PSI0OSIgTmFtZT0i R3JpZCBUYWJsZSA0IEFjY2VudCA1Ii8+DQo8dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJmYWxzZSIg UHJpb3JpdHk9IjUwIiBOYW1lPSJHcmlkIFRhYmxlIDUgRGFyayBBY2NlbnQgNSIvPg0KPHc6THNk RXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFByaW9yaXR5PSI1MSIgTmFtZT0iR3JpZCBUYWJsZSA2 IENvbG9yZnVsIEFjY2VudCA1Ii8+DQo8dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJmYWxzZSIgUHJp b3JpdHk9IjUyIiBOYW1lPSJHcmlkIFRhYmxlIDcgQ29sb3JmdWwgQWNjZW50IDUiLz4NCjx3Okxz ZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBQcmlvcml0eT0iNDYiIE5hbWU9IkdyaWQgVGFibGUg MSBMaWdodCBBY2NlbnQgNiIvPg0KPHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFByaW9y aXR5PSI0NyIgTmFtZT0iR3JpZCBUYWJsZSAyIEFjY2VudCA2Ii8+DQo8dzpMc2RFeGNlcHRpb24g TG9ja2VkPSJmYWxzZSIgUHJpb3JpdHk9IjQ4IiBOYW1lPSJHcmlkIFRhYmxlIDMgQWNjZW50IDYi Lz4NCjx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBQcmlvcml0eT0iNDkiIE5hbWU9Ikdy aWQgVGFibGUgNCBBY2NlbnQgNiIvPg0KPHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFBy aW9yaXR5PSI1MCIgTmFtZT0iR3JpZCBUYWJsZSA1IERhcmsgQWNjZW50IDYiLz4NCjx3OkxzZEV4 Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBQcmlvcml0eT0iNTEiIE5hbWU9IkdyaWQgVGFibGUgNiBD b2xvcmZ1bCBBY2NlbnQgNiIvPg0KPHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFByaW9y aXR5PSI1MiIgTmFtZT0iR3JpZCBUYWJsZSA3IENvbG9yZnVsIEFjY2VudCA2Ii8+DQo8dzpMc2RF eGNlcHRpb24gTG9ja2VkPSJmYWxzZSIgUHJpb3JpdHk9IjQ2IiBOYW1lPSJMaXN0IFRhYmxlIDEg TGlnaHQiLz4NCjx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBQcmlvcml0eT0iNDciIE5h bWU9Ikxpc3QgVGFibGUgMiIvPg0KPHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFByaW9y aXR5PSI0OCIgTmFtZT0iTGlzdCBUYWJsZSAzIi8+DQo8dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJm YWxzZSIgUHJpb3JpdHk9IjQ5IiBOYW1lPSJMaXN0IFRhYmxlIDQiLz4NCjx3OkxzZEV4Y2VwdGlv biBMb2NrZWQ9ImZhbHNlIiBQcmlvcml0eT0iNTAiIE5hbWU9Ikxpc3QgVGFibGUgNSBEYXJrIi8+ DQo8dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJmYWxzZSIgUHJpb3JpdHk9IjUxIiBOYW1lPSJMaXN0 IFRhYmxlIDYgQ29sb3JmdWwiLz4NCjx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBQcmlv cml0eT0iNTIiIE5hbWU9Ikxpc3QgVGFibGUgNyBDb2xvcmZ1bCIvPg0KPHc6THNkRXhjZXB0aW9u IExvY2tlZD0iZmFsc2UiIFByaW9yaXR5PSI0NiIgTmFtZT0iTGlzdCBUYWJsZSAxIExpZ2h0IEFj Y2VudCAxIi8+DQo8dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJmYWxzZSIgUHJpb3JpdHk9IjQ3IiBO YW1lPSJMaXN0IFRhYmxlIDIgQWNjZW50IDEiLz4NCjx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZh bHNlIiBQcmlvcml0eT0iNDgiIE5hbWU9Ikxpc3QgVGFibGUgMyBBY2NlbnQgMSIvPg0KPHc6THNk RXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFByaW9yaXR5PSI0OSIgTmFtZT0iTGlzdCBUYWJsZSA0 IEFjY2VudCAxIi8+DQo8dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJmYWxzZSIgUHJpb3JpdHk9IjUw IiBOYW1lPSJMaXN0IFRhYmxlIDUgRGFyayBBY2NlbnQgMSIvPg0KPHc6THNkRXhjZXB0aW9uIExv Y2tlZD0iZmFsc2UiIFByaW9yaXR5PSI1MSIgTmFtZT0iTGlzdCBUYWJsZSA2IENvbG9yZnVsIEFj Y2VudCAxIi8+DQo8dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJmYWxzZSIgUHJpb3JpdHk9IjUyIiBO YW1lPSJMaXN0IFRhYmxlIDcgQ29sb3JmdWwgQWNjZW50IDEiLz4NCjx3OkxzZEV4Y2VwdGlvbiBM b2NrZWQ9ImZhbHNlIiBQcmlvcml0eT0iNDYiIE5hbWU9Ikxpc3QgVGFibGUgMSBMaWdodCBBY2Nl bnQgMiIvPg0KPHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFByaW9yaXR5PSI0NyIgTmFt ZT0iTGlzdCBUYWJsZSAyIEFjY2VudCAyIi8+DQo8dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJmYWxz ZSIgUHJpb3JpdHk9IjQ4IiBOYW1lPSJMaXN0IFRhYmxlIDMgQWNjZW50IDIiLz4NCjx3OkxzZEV4 Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBQcmlvcml0eT0iNDkiIE5hbWU9Ikxpc3QgVGFibGUgNCBB Y2NlbnQgMiIvPg0KPHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFByaW9yaXR5PSI1MCIg TmFtZT0iTGlzdCBUYWJsZSA1IERhcmsgQWNjZW50IDIiLz4NCjx3OkxzZEV4Y2VwdGlvbiBMb2Nr ZWQ9ImZhbHNlIiBQcmlvcml0eT0iNTEiIE5hbWU9Ikxpc3QgVGFibGUgNiBDb2xvcmZ1bCBBY2Nl bnQgMiIvPg0KPHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFByaW9yaXR5PSI1MiIgTmFt ZT0iTGlzdCBUYWJsZSA3IENvbG9yZnVsIEFjY2VudCAyIi8+DQo8dzpMc2RFeGNlcHRpb24gTG9j a2VkPSJmYWxzZSIgUHJpb3JpdHk9IjQ2IiBOYW1lPSJMaXN0IFRhYmxlIDEgTGlnaHQgQWNjZW50 IDMiLz4NCjx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBQcmlvcml0eT0iNDciIE5hbWU9 Ikxpc3QgVGFibGUgMiBBY2NlbnQgMyIvPg0KPHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFsc2Ui IFByaW9yaXR5PSI0OCIgTmFtZT0iTGlzdCBUYWJsZSAzIEFjY2VudCAzIi8+DQo8dzpMc2RFeGNl cHRpb24gTG9ja2VkPSJmYWxzZSIgUHJpb3JpdHk9IjQ5IiBOYW1lPSJMaXN0IFRhYmxlIDQgQWNj ZW50IDMiLz4NCjx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBQcmlvcml0eT0iNTAiIE5h bWU9Ikxpc3QgVGFibGUgNSBEYXJrIEFjY2VudCAzIi8+DQo8dzpMc2RFeGNlcHRpb24gTG9ja2Vk PSJmYWxzZSIgUHJpb3JpdHk9IjUxIiBOYW1lPSJMaXN0IFRhYmxlIDYgQ29sb3JmdWwgQWNjZW50 IDMiLz4NCjx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBQcmlvcml0eT0iNTIiIE5hbWU9 Ikxpc3QgVGFibGUgNyBDb2xvcmZ1bCBBY2NlbnQgMyIvPg0KPHc6THNkRXhjZXB0aW9uIExvY2tl ZD0iZmFsc2UiIFByaW9yaXR5PSI0NiIgTmFtZT0iTGlzdCBUYWJsZSAxIExpZ2h0IEFjY2VudCA0 Ii8+DQo8dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJmYWxzZSIgUHJpb3JpdHk9IjQ3IiBOYW1lPSJM aXN0IFRhYmxlIDIgQWNjZW50IDQiLz4NCjx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBQ cmlvcml0eT0iNDgiIE5hbWU9Ikxpc3QgVGFibGUgMyBBY2NlbnQgNCIvPg0KPHc6THNkRXhjZXB0 aW9uIExvY2tlZD0iZmFsc2UiIFByaW9yaXR5PSI0OSIgTmFtZT0iTGlzdCBUYWJsZSA0IEFjY2Vu dCA0Ii8+DQo8dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJmYWxzZSIgUHJpb3JpdHk9IjUwIiBOYW1l PSJMaXN0IFRhYmxlIDUgRGFyayBBY2NlbnQgNCIvPg0KPHc6THNkRXhjZXB0aW9uIExvY2tlZD0i ZmFsc2UiIFByaW9yaXR5PSI1MSIgTmFtZT0iTGlzdCBUYWJsZSA2IENvbG9yZnVsIEFjY2VudCA0 Ii8+DQo8dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJmYWxzZSIgUHJpb3JpdHk9IjUyIiBOYW1lPSJM aXN0IFRhYmxlIDcgQ29sb3JmdWwgQWNjZW50IDQiLz4NCjx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9 ImZhbHNlIiBQcmlvcml0eT0iNDYiIE5hbWU9Ikxpc3QgVGFibGUgMSBMaWdodCBBY2NlbnQgNSIv Pg0KPHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFByaW9yaXR5PSI0NyIgTmFtZT0iTGlz dCBUYWJsZSAyIEFjY2VudCA1Ii8+DQo8dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJmYWxzZSIgUHJp b3JpdHk9IjQ4IiBOYW1lPSJMaXN0IFRhYmxlIDMgQWNjZW50IDUiLz4NCjx3OkxzZEV4Y2VwdGlv biBMb2NrZWQ9ImZhbHNlIiBQcmlvcml0eT0iNDkiIE5hbWU9Ikxpc3QgVGFibGUgNCBBY2NlbnQg NSIvPg0KPHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFByaW9yaXR5PSI1MCIgTmFtZT0i TGlzdCBUYWJsZSA1IERhcmsgQWNjZW50IDUiLz4NCjx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZh bHNlIiBQcmlvcml0eT0iNTEiIE5hbWU9Ikxpc3QgVGFibGUgNiBDb2xvcmZ1bCBBY2NlbnQgNSIv Pg0KPHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFByaW9yaXR5PSI1MiIgTmFtZT0iTGlz dCBUYWJsZSA3IENvbG9yZnVsIEFjY2VudCA1Ii8+DQo8dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJm YWxzZSIgUHJpb3JpdHk9IjQ2IiBOYW1lPSJMaXN0IFRhYmxlIDEgTGlnaHQgQWNjZW50IDYiLz4N Cjx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBQcmlvcml0eT0iNDciIE5hbWU9Ikxpc3Qg VGFibGUgMiBBY2NlbnQgNiIvPg0KPHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFByaW9y aXR5PSI0OCIgTmFtZT0iTGlzdCBUYWJsZSAzIEFjY2VudCA2Ii8+DQo8dzpMc2RFeGNlcHRpb24g TG9ja2VkPSJmYWxzZSIgUHJpb3JpdHk9IjQ5IiBOYW1lPSJMaXN0IFRhYmxlIDQgQWNjZW50IDYi Lz4NCjx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBQcmlvcml0eT0iNTAiIE5hbWU9Ikxp c3QgVGFibGUgNSBEYXJrIEFjY2VudCA2Ii8+DQo8dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJmYWxz ZSIgUHJpb3JpdHk9IjUxIiBOYW1lPSJMaXN0IFRhYmxlIDYgQ29sb3JmdWwgQWNjZW50IDYiLz4N Cjx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBQcmlvcml0eT0iNTIiIE5hbWU9Ikxpc3Qg VGFibGUgNyBDb2xvcmZ1bCBBY2NlbnQgNiIvPg0KPC93OkxhdGVudFN0eWxlcz4NCjwveG1sPjwh W2VuZGlmXS0tPjxzdHlsZT48IS0tDQovKiBGb250IERlZmluaXRpb25zICovDQpAZm9udC1mYWNl DQoJe2ZvbnQtZmFtaWx5OiJDYW1icmlhIE1hdGgiOw0KCXBhbm9zZS0xOjIgNCA1IDMgNSA0IDYg MyAyIDQ7DQoJbXNvLWZvbnQtY2hhcnNldDoxOw0KCW1zby1nZW5lcmljLWZvbnQtZmFtaWx5OnJv bWFuOw0KCW1zby1mb250LWZvcm1hdDpvdGhlcjsNCgltc28tZm9udC1waXRjaDp2YXJpYWJsZTsN Cgltc28tZm9udC1zaWduYXR1cmU6MCAwIDAgMCAwIDA7fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZh bWlseTpDYWxpYnJpOw0KCXBhbm9zZS0xOjIgMTUgNSAyIDIgMiA0IDMgMiA0Ow0KCW1zby1mb250 LWNoYXJzZXQ6MDsNCgltc28tZ2VuZXJpYy1mb250LWZhbWlseTpzd2lzczsNCgltc28tZm9udC1w aXRjaDp2YXJpYWJsZTsNCgltc28tZm9udC1zaWduYXR1cmU6LTUzNjg3MDE0NSAxMDczNzg2MTEx IDEgMCA0MTUgMDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OlRhaG9tYTsNCglwYW5vc2Ut MToyIDExIDYgNCAzIDUgNCA0IDIgNDsNCgltc28tZm9udC1jaGFyc2V0OjA7DQoJbXNvLWdlbmVy aWMtZm9udC1mYW1pbHk6c3dpc3M7DQoJbXNvLWZvbnQtcGl0Y2g6dmFyaWFibGU7DQoJbXNvLWZv bnQtc2lnbmF0dXJlOi01MjAwODE2NjUgLTEwNzM3MTcxNTcgNDEgMCA2NjA0NyAwO30NCi8qIFN0 eWxlIERlZmluaXRpb25zICovDQpwLk1zb05vcm1hbCwgbGkuTXNvTm9ybWFsLCBkaXYuTXNvTm9y bWFsDQoJe21zby1zdHlsZS11bmhpZGU6bm87DQoJbXNvLXN0eWxlLXFmb3JtYXQ6eWVzOw0KCW1z by1zdHlsZS1wYXJlbnQ6IiI7DQoJbWFyZ2luOjBpbjsNCgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7 DQoJbXNvLXBhZ2luYXRpb246d2lkb3ctb3JwaGFuOw0KCWZvbnQtc2l6ZToxMi4wcHQ7DQoJZm9u dC1mYW1pbHk6IlRpbWVzIE5ldyBSb21hbiIsc2VyaWY7DQoJbXNvLWZhcmVhc3QtZm9udC1mYW1p bHk6Q2FsaWJyaTt9DQphOmxpbmssIHNwYW4uTXNvSHlwZXJsaW5rDQoJe21zby1zdHlsZS1ub3No b3c6eWVzOw0KCW1zby1zdHlsZS1wcmlvcml0eTo5OTsNCgljb2xvcjpibHVlOw0KCXRleHQtZGVj b3JhdGlvbjp1bmRlcmxpbmU7DQoJdGV4dC11bmRlcmxpbmU6c2luZ2xlO30NCmE6dmlzaXRlZCwg c3Bhbi5Nc29IeXBlcmxpbmtGb2xsb3dlZA0KCXttc28tc3R5bGUtbm9zaG93OnllczsNCgltc28t c3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6cHVycGxlOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRl cmxpbmU7DQoJdGV4dC11bmRlcmxpbmU6c2luZ2xlO30NCnNwYW4uRW1haWxTdHlsZTE3DQoJe21z by1zdHlsZS10eXBlOnBlcnNvbmFsLXJlcGx5Ow0KCW1zby1zdHlsZS1ub3Nob3c6eWVzOw0KCW1z by1zdHlsZS11bmhpZGU6bm87DQoJbXNvLWFuc2ktZm9udC1zaXplOjExLjBwdDsNCgltc28tYmlk aS1mb250LXNpemU6MTEuMHB0Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIixzYW5zLXNlcmlmOw0K CW1zby1hc2NpaS1mb250LWZhbWlseTpDYWxpYnJpOw0KCW1zby1mYXJlYXN0LWZvbnQtZmFtaWx5 OkNhbGlicmk7DQoJbXNvLWhhbnNpLWZvbnQtZmFtaWx5OkNhbGlicmk7DQoJbXNvLWJpZGktZm9u dC1mYW1pbHk6IlRpbWVzIE5ldyBSb21hbiI7DQoJY29sb3I6IzFGNDk3RDt9DQouTXNvQ2hwRGVm YXVsdA0KCXttc28tc3R5bGUtdHlwZTpleHBvcnQtb25seTsNCgltc28tZGVmYXVsdC1wcm9wczp5 ZXM7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLHNhbnMtc2VyaWY7DQoJbXNvLWFzY2lpLWZvbnQt ZmFtaWx5OkNhbGlicmk7DQoJbXNvLWZhcmVhc3QtZm9udC1mYW1pbHk6Q2FsaWJyaTsNCgltc28t aGFuc2ktZm9udC1mYW1pbHk6Q2FsaWJyaTsNCgltc28tYmlkaS1mb250LWZhbWlseToiVGltZXMg TmV3IFJvbWFuIjt9DQpAcGFnZSBXb3JkU2VjdGlvbjENCgl7c2l6ZTo4LjVpbiAxMS4waW47DQoJ bWFyZ2luOjEuMGluIDEuMGluIDEuMGluIDEuMGluOw0KCW1zby1oZWFkZXItbWFyZ2luOi41aW47 DQoJbXNvLWZvb3Rlci1tYXJnaW46LjVpbjsNCgltc28tcGFwZXItc291cmNlOjA7fQ0KZGl2Lldv cmRTZWN0aW9uMQ0KCXtwYWdlOldvcmRTZWN0aW9uMTt9DQotLT48L3N0eWxlPjwhLS1baWYgZ3Rl IG1zbyAxMF0+PHN0eWxlPi8qIFN0eWxlIERlZmluaXRpb25zICovDQp0YWJsZS5Nc29Ob3JtYWxU YWJsZQ0KCXttc28tc3R5bGUtbmFtZToiVGFibGUgTm9ybWFsIjsNCgltc28tdHN0eWxlLXJvd2Jh bmQtc2l6ZTowOw0KCW1zby10c3R5bGUtY29sYmFuZC1zaXplOjA7DQoJbXNvLXN0eWxlLW5vc2hv dzp5ZXM7DQoJbXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCW1zby1zdHlsZS1wYXJlbnQ6IiI7DQoJ bXNvLXBhZGRpbmctYWx0OjBpbiA1LjRwdCAwaW4gNS40cHQ7DQoJbXNvLXBhcmEtbWFyZ2luOjBp bjsNCgltc28tcGFyYS1tYXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJbXNvLXBhZ2luYXRpb246d2lk b3ctb3JwaGFuOw0KCWZvbnQtc2l6ZToxMS4wcHQ7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLHNh bnMtc2VyaWY7DQoJbXNvLWFzY2lpLWZvbnQtZmFtaWx5OkNhbGlicmk7DQoJbXNvLWhhbnNpLWZv bnQtZmFtaWx5OkNhbGlicmk7fQ0KPC9zdHlsZT48IVtlbmRpZl0tLT48IS0tW2lmIGd0ZSBtc28g OV0+PHhtbD4NCjxvOnNoYXBlZGVmYXVsdHMgdjpleHQ9ImVkaXQiIHNwaWRtYXg9IjEwMjYiIC8+ DQo8L3htbD48IVtlbmRpZl0tLT48IS0tW2lmIGd0ZSBtc28gOV0+PHhtbD4NCjxvOnNoYXBlbGF5 b3V0IHY6ZXh0PSJlZGl0Ij4NCjxvOmlkbWFwIHY6ZXh0PSJlZGl0IiBkYXRhPSIxIiAvPg0KPC9v OnNoYXBlbGF5b3V0PjwveG1sPjwhW2VuZGlmXS0tPg0KPC9oZWFkPg0KPGJvZHkgbGFuZz0iRU4t VVMiIGxpbms9ImJsdWUiIHZsaW5rPSJwdXJwbGUiIHN0eWxlPSJ0YWItaW50ZXJ2YWw6LjVpbiI+ DQo8ZGl2IGNsYXNzPSJXb3JkU2VjdGlvbjEiPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4g c3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90Oyxz YW5zLXNlcmlmO21zby1iaWRpLWZvbnQtZmFtaWx5OiZxdW90O1RpbWVzIE5ldyBSb21hbiZxdW90 Oztjb2xvcjojMUY0OTdEIj5UaGFua3MhPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1 b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO21zby1iaWRpLWZvbnQtZmFtaWx5OiZxdW90O1Rp bWVzIE5ldyBSb21hbiZxdW90Oztjb2xvcjojMUY0OTdEIj5Pcml0LjxvOnA+PC9vOnA+PC9zcGFu PjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxhIG5hbWU9Il9NYWlsRW5kQ29tcG9zZSI+PHNw YW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90 OyxzYW5zLXNlcmlmO21zby1iaWRpLWZvbnQtZmFtaWx5OiZxdW90O1RpbWVzIE5ldyBSb21hbiZx dW90Oztjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L2E+PC9wPg0KPHNw YW4gc3R5bGU9Im1zby1ib29rbWFyazpfTWFpbEVuZENvbXBvc2UiPjwvc3Bhbj4NCjxkaXYgc3R5 bGU9ImJvcmRlcjpub25lO2JvcmRlci1sZWZ0OnNvbGlkIGJsdWUgMS41cHQ7cGFkZGluZzowaW4g MGluIDBpbiA0LjBwdCI+DQo8ZGl2Pg0KPGRpdiBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLXRv cDpzb2xpZCAjRTFFMUUxIDEuMHB0O3BhZGRpbmc6My4wcHQgMGluIDBpbiAwaW4iPg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+PGI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1p bHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO21zby1mYXJlYXN0LWZvbnQtZmFtaWx5 OiZxdW90O1RpbWVzIE5ldyBSb21hbiZxdW90OyI+RnJvbTo8L3NwYW4+PC9iPjxzcGFuIHN0eWxl PSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1z ZXJpZjttc28tZmFyZWFzdC1mb250LWZhbWlseTomcXVvdDtUaW1lcyBOZXcgUm9tYW4mcXVvdDsi PiBUZWQNCiBIYXJkaWUgW21haWx0bzp0ZWQuaWV0ZkBnbWFpbC5jb21dIDxicj4NCjxiPlNlbnQ6 PC9iPiBUdWVzZGF5LCBBdWd1c3QgMDQsIDIwMTUgNDoxNiBQTTxicj4NCjxiPlRvOjwvYj4gT3Jp dCBMZXZpbiAoTENBKSAmbHQ7b3JpdGxAbWljcm9zb2Z0LmNvbSZndDs8YnI+DQo8Yj5DYzo8L2I+ IEVyaWMgUmVzY29ybGEgJmx0O2VrckBydGZtLmNvbSZndDs7IHJ0Y3dlYkBpZXRmLm9yZzsgYXBw c2RpckBpZXRmLm9yZzsgRWxpb3QgTGVhciAmbHQ7bGVhckBjaXNjby5jb20mZ3Q7PGJyPg0KPGI+ U3ViamVjdDo8L2I+IFJlOiBbcnRjd2ViXSBbYXBwc2Rpcl0gRndkOiBSZXF1ZXN0IGZvciBBcHBz IERpcmVjdG9yYXRlIHJldmlldyBvZiBydGN3ZWItc2VjdXJpdHkgZHJhZnRzPG86cD48L286cD48 L3NwYW4+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5i c3A7PC9vOnA+PC9wPg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5PbiBUdWUs IEF1ZyA0LCAyMDE1IGF0IDM6MzAgUE0sIE9yaXQgTGV2aW4gKExDQSkgJmx0OzxhIGhyZWY9Im1h aWx0bzpvcml0bEBtaWNyb3NvZnQuY29tIiB0YXJnZXQ9Il9ibGFuayI+b3JpdGxAbWljcm9zb2Z0 LmNvbTwvYT4mZ3Q7IHdyb3RlOjxvOnA+PC9vOnA+PC9wPg0KPGRpdj4NCjxibG9ja3F1b3RlIHN0 eWxlPSJib3JkZXI6bm9uZTtib3JkZXItbGVmdDpzb2xpZCAjQ0NDQ0NDIDEuMHB0O21zby1ib3Jk ZXItbGVmdC1hbHQ6c29saWQgI0NDQ0NDQyAuNzVwdDtwYWRkaW5nOjBpbiAwaW4gMGluIDYuMHB0 O21hcmdpbi1sZWZ0OjQuOHB0O21hcmdpbi1yaWdodDowaW4iPg0KPGRpdj4NCjxkaXY+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdp bi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFt aWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEIj5UaGFua3Ms IEVrciEgTG9va2luZyBmb3J3YXJkIHRvIHJlYWRpbmcgdGhlIG5leHQgdmVyc2lvbiBvZiB0aGUg ZHJhZnRzLjwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxl PSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNw YW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90 OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0QiPldoZW5ldmVyIGl0IHdvcmtzIGJlc3QgZm9yIHlv dSwgY291bGQgeW91LCBwbGVhc2UsIHJlcGx5IHRvIHRoZSBvcmlnaW5hbCBlbWFpbCBzaG93aW5n IGlubGluZSBob3cgZWFjaA0KIGNvbW1lbnQgZ290IGFkZHJlc3NlZD8gVGhhdCB3b3VsZCBoZWxw IGEgbG90Ljwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxl PSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNw YW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90 OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0QiPkNoZWVycyw8L3NwYW4+PG86cD48L286cD48L3A+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNv LW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2Zv bnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEIj5P cml0Ljwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJt c28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4g c3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90Oyxz YW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0QiPiZuYnNwOzwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwv ZGl2Pg0KPC9kaXY+DQo8L2Jsb2NrcXVvdGU+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ PG86cD4mbmJzcDs8L286cD48L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9 Im1hcmdpbi1ib3R0b206MTIuMHB0Ij48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7VGFo b21hJnF1b3Q7LHNhbnMtc2VyaWYiPuKAi0hpIE9yaXQsPG86cD48L286cD48L3NwYW4+PC9wPg0K PC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1ib3R0b206 MTIuMHB0Ij48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7VGFob21hJnF1b3Q7LHNhbnMt c2VyaWYiPkkgdGhpbmsgb3VyIGFpbSBpcyB0byBkZXNjcmliZSBob3cgY29tbWVudHMgd2VyZSBh ZGRyZXNzZWQgaW4gdGhlIHNoZXBoZXJkIHdyaXRlLXVwOyBJJ2xsIHRha2UgdGhlIGFjdGlvbiBp dGVtIHRvIG1ha2Ugc3VyZSB5b3UgZ2V0IGEgY29weS48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8 L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1mYW1p bHk6JnF1b3Q7VGFob21hJnF1b3Q7LHNhbnMtc2VyaWYiPlRlZOKAizxvOnA+PC9vOnA+PC9zcGFu PjwvcD4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGJyPg0KJm5ic3A7PG86cD48L286 cD48L3A+DQo8L2Rpdj4NCjxibG9ja3F1b3RlIHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItbGVm dDpzb2xpZCAjQ0NDQ0NDIDEuMHB0O21zby1ib3JkZXItbGVmdC1hbHQ6c29saWQgI0NDQ0NDQyAu NzVwdDtwYWRkaW5nOjBpbiAwaW4gMGluIDYuMHB0O21hcmdpbi1sZWZ0OjQuOHB0O21hcmdpbi1y aWdodDowaW4iPg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNv LW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxhIG5hbWU9 IjE0ZWZhZDYwZWVlYTAxODVfX01haWxFbmRDb21wb3NlIj48c3BhbiBzdHlsZT0iZm9udC1zaXpl OjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6 IzFGNDk3RCI+Jm5ic3A7PC9zcGFuPjwvYT48bzpwPjwvbzpwPjwvcD4NCjxkaXYgc3R5bGU9ImJv cmRlcjpub25lO2JvcmRlci1sZWZ0OnNvbGlkIGJsdWUgMS41cHQ7cGFkZGluZzowaW4gMGluIDBp biA0LjBwdCI+DQo8ZGl2Pg0KPGRpdiBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLXRvcDpzb2xp ZCAjRTFFMUUxIDEuMHB0O3BhZGRpbmc6My4wcHQgMGluIDBpbiAwaW4iPg0KPHAgY2xhc3M9Ik1z b05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9t LWFsdDphdXRvO21zby1vdXRsaW5lLWxldmVsOjEiPg0KPGI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6 ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmIj5Gcm9t Ojwvc3Bhbj48L2I+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1 b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmIj4gRXJpYyBSZXNjb3JsYSBbbWFpbHRvOjxhIGhy ZWY9Im1haWx0bzpla3JAcnRmbS5jb20iIHRhcmdldD0iX2JsYW5rIj5la3JAcnRmbS5jb208L2E+ XQ0KPGJyPg0KPGI+U2VudDo8L2I+IFR1ZXNkYXksIEF1Z3VzdCAwNCwgMjAxNSA5OjQyIEFNPGJy Pg0KPGI+VG86PC9iPiBPcml0IExldmluIChMQ0EpICZsdDs8YSBocmVmPSJtYWlsdG86b3JpdGxA bWljcm9zb2Z0LmNvbSIgdGFyZ2V0PSJfYmxhbmsiPm9yaXRsQG1pY3Jvc29mdC5jb208L2E+Jmd0 Ozxicj4NCjxiPkNjOjwvYj4gVGVkIEhhcmRpZSAmbHQ7PGEgaHJlZj0ibWFpbHRvOnRlZC5pZXRm QGdtYWlsLmNvbSIgdGFyZ2V0PSJfYmxhbmsiPnRlZC5pZXRmQGdtYWlsLmNvbTwvYT4mZ3Q7Ow0K PGEgaHJlZj0ibWFpbHRvOnJ0Y3dlYkBpZXRmLm9yZyIgdGFyZ2V0PSJfYmxhbmsiPnJ0Y3dlYkBp ZXRmLm9yZzwvYT47IDxhIGhyZWY9Im1haWx0bzphcHBzZGlyQGlldGYub3JnIiB0YXJnZXQ9Il9i bGFuayI+DQphcHBzZGlyQGlldGYub3JnPC9hPjsgRWxpb3QgTGVhciAmbHQ7PGEgaHJlZj0ibWFp bHRvOmxlYXJAY2lzY28uY29tIiB0YXJnZXQ9Il9ibGFuayI+bGVhckBjaXNjby5jb208L2E+Jmd0 Ozxicj4NCjxiPlN1YmplY3Q6PC9iPiBSZTogW3J0Y3dlYl0gW2FwcHNkaXJdIEZ3ZDogUmVxdWVz dCBmb3IgQXBwcyBEaXJlY3RvcmF0ZSByZXZpZXcgb2YgcnRjd2ViLXNlY3VyaXR5IGRyYWZ0czwv c3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2lu LWJvdHRvbS1hbHQ6YXV0byI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90 dG9tLWFsdDphdXRvIj5JJ2xsIGJlIGhhbmRsaW5nIHRoaXMgYWxvbmcgd2l0aCB0aGUgcmVzdCBv ZiB0aGUgcmV2aWV3IGNvbW1lbnRzIEkgaGF2ZSByZWNlaXZlZCw8bzpwPjwvbzpwPjwvcD4NCjxk aXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87 bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPmF0IHRoZSBuZXh0IGRyYWZ0IHVwZGF0ZSAocHJv YmFibHkgYmVmb3JlIHRoZSBuZXh0IFJUQ1dFQi9XZWJSVEMgaW50ZXJpbSk8bzpwPjwvbzpwPjwv cD4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0 OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPmJ1dCBJIGRvbid0IGhhdmUgYSBzcGVj aWZpYyBFVEEuPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0 OmF1dG8iPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1z b05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9t LWFsdDphdXRvIj4tRWtyPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0 b20tYWx0OmF1dG8iPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1i b3R0b20tYWx0OmF1dG8iPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwv ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1h bHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+Jm5ic3A7PG86cD48L286cD48L3A+ DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDph dXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj5PbiBNb24sIEF1ZyAzLCAyMDE1IGF0IDQ6 NDMgUE0sIE9yaXQgTGV2aW4gKExDQSkgJmx0OzxhIGhyZWY9Im1haWx0bzpvcml0bEBtaWNyb3Nv ZnQuY29tIiB0YXJnZXQ9Il9ibGFuayI+b3JpdGxAbWljcm9zb2Z0LmNvbTwvYT4mZ3Q7IHdyb3Rl OjxvOnA+PC9vOnA+PC9wPg0KPGJsb2NrcXVvdGUgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci1s ZWZ0OnNvbGlkICNDQ0NDQ0MgMS4wcHQ7cGFkZGluZzowaW4gMGluIDBpbiA2LjBwdDttYXJnaW4t bGVmdDo0LjhwdDttYXJnaW4tdG9wOjUuMHB0O21hcmdpbi1yaWdodDowaW47bWFyZ2luLWJvdHRv bTo1LjBwdCI+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28t bWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gc3R5 bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5z LXNlcmlmO2NvbG9yOiMxRjQ5N0QiPkhpIGd1eXMsPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJn aW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZh bWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RCI+VGhyZWUg YnVzeSB3ZWVrcyBhbmQgYW4gSUVURiBtZWV0aW5nIGhhdmUgcGFzdOKApiBXaGVuIHNob3VsZCB3 ZSBleHBlY3QgdG8gc2VlIHRoZSBmZWVkYmFjayB0byB0aGUgcmV2aWV3Pzwvc3Bhbj48bzpwPjwv bzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6 YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTox MS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMx RjQ5N0QiPlRoYW5rcyBhbmQgY2hlZXJzLDwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJv dHRvbS1hbHQ6YXV0byI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6 JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0QiPk9yaXQuPC9zcGFu PjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4t dG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48YSBuYW1lPSIxNGVmYWQ2 MGVlZWEwMTg1XzE0ZWY5OTNhMmNhZTZjNGNfMTRlZjk4Ij48c3BhbiBzdHlsZT0iZm9udC1zaXpl OjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6 IzFGNDk3RCI+Jm5ic3A7PC9zcGFuPjwvYT48bzpwPjwvbzpwPjwvcD4NCjxkaXYgc3R5bGU9ImJv cmRlcjpub25lO2JvcmRlci1sZWZ0OnNvbGlkIGJsdWUgMS41cHQ7cGFkZGluZzowaW4gMGluIDBp biA0LjBwdCI+DQo8ZGl2Pg0KPGRpdiBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLXRvcDpzb2xp ZCAjRTFFMUUxIDEuMHB0O3BhZGRpbmc6My4wcHQgMGluIDBpbiAwaW4iPg0KPHAgY2xhc3M9Ik1z b05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9t LWFsdDphdXRvO21zby1vdXRsaW5lLWxldmVsOjEiPg0KPGI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6 ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmIj5Gcm9t Ojwvc3Bhbj48L2I+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1 b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmIj4gVGVkIEhhcmRpZSBbbWFpbHRvOjxhIGhyZWY9 Im1haWx0bzp0ZWQuaWV0ZkBnbWFpbC5jb20iIHRhcmdldD0iX2JsYW5rIj50ZWQuaWV0ZkBnbWFp bC5jb208L2E+XQ0KPGJyPg0KPGI+U2VudDo8L2I+IFR1ZXNkYXksIEp1bHkgMTQsIDIwMTUgMTE6 MTggQU08YnI+DQo8Yj5Ubzo8L2I+IE9yaXQgTGV2aW4gKExDQSkgJmx0OzxhIGhyZWY9Im1haWx0 bzpvcml0bEBtaWNyb3NvZnQuY29tIiB0YXJnZXQ9Il9ibGFuayI+b3JpdGxAbWljcm9zb2Z0LmNv bTwvYT4mZ3Q7Ow0KPGEgaHJlZj0ibWFpbHRvOnJ0Y3dlYkBpZXRmLm9yZyIgdGFyZ2V0PSJfYmxh bmsiPnJ0Y3dlYkBpZXRmLm9yZzwvYT48YnI+DQo8Yj5DYzo8L2I+IEVsaW90IExlYXIgJmx0Ozxh IGhyZWY9Im1haWx0bzpsZWFyQGNpc2NvLmNvbSIgdGFyZ2V0PSJfYmxhbmsiPmxlYXJAY2lzY28u Y29tPC9hPiZndDs7DQo8YSBocmVmPSJtYWlsdG86YXBwc2RpckBpZXRmLm9yZyIgdGFyZ2V0PSJf YmxhbmsiPmFwcHNkaXJAaWV0Zi5vcmc8L2E+PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPGRpdj4N CjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1 dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxicj4NCjxiPlN1YmplY3Q6PC9iPiBSZTog W2FwcHNkaXJdIEZ3ZDogUmVxdWVzdCBmb3IgQXBwcyBEaXJlY3RvcmF0ZSByZXZpZXcgb2YgcnRj d2ViLXNlY3VyaXR5IGRyYWZ0czxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2 Pg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28t bWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+Jm5ic3A7PG86 cD48L286cD48L3A+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJt c28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttYXJnaW4tYm90dG9tOjEyLjBwdCI+PHNwYW4gc3R5bGU9 ImZvbnQtZmFtaWx5OiZxdW90O1RhaG9tYSZxdW90OyxzYW5zLXNlcmlmIj4oYWRkaW5nIHRoZSBX Ryk8L3NwYW4+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bWFyZ2luLWJvdHRvbToxMi4wcHQi PjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtUYWhvbWEmcXVvdDssc2Fucy1zZXJpZiI+ SGkgT3JpdCw8L3NwYW4+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bWFyZ2luLWJvdHRvbTox Mi4wcHQiPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtUYWhvbWEmcXVvdDssc2Fucy1z ZXJpZiI+VGhhbmtzIGZvciB0aGUgcmV2aWV3Ljwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2 Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6 YXV0bzttYXJnaW4tYm90dG9tOjEyLjBwdCI+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90 O1RhaG9tYSZxdW90OyxzYW5zLXNlcmlmIj5yZWdhcmRzLDwvc3Bhbj48bzpwPjwvbzpwPjwvcD4N CjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRv cC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gc3R5bGU9ImZvbnQt ZmFtaWx5OiZxdW90O1RhaG9tYSZxdW90OyxzYW5zLXNlcmlmIj5UZWQgSGFyZGllPC9zcGFuPjxv OnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9 Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj4mbmJz cDs8bzpwPjwvbzpwPjwvcD4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNv LW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPk9uIFR1ZSwg SnVsIDE0LCAyMDE1IGF0IDExOjA3IEFNLCBPcml0IExldmluIChMQ0EpICZsdDs8YSBocmVmPSJt YWlsdG86b3JpdGxAbWljcm9zb2Z0LmNvbSIgdGFyZ2V0PSJfYmxhbmsiPm9yaXRsQG1pY3Jvc29m dC5jb208L2E+Jmd0OyB3cm90ZTo8bzpwPjwvbzpwPjwvcD4NCjxibG9ja3F1b3RlIHN0eWxlPSJi b3JkZXI6bm9uZTtib3JkZXItbGVmdDpzb2xpZCAjQ0NDQ0NDIDEuMHB0O3BhZGRpbmc6MGluIDBp biAwaW4gNi4wcHQ7bWFyZ2luLWxlZnQ6NC44cHQ7bWFyZ2luLXRvcDo1LjBwdDttYXJnaW4tcmln aHQ6MGluO21hcmdpbi1ib3R0b206NS4wcHQiPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9 Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj5EaXNj bGFpbWVyOiBJIGFtIGZhbWlsaWFyIHdpdGggUlRDIGFuZCBXZWJSVEMsIGJ1dCBJIGhhdmVuJ3Qg Zm9sbG93ZWQgdGhlIFJUQ1dlYiB3b3JrIGluIHRoZSBsYXN0IGZldyB5ZWFycy4gSSByZWFkIHRo ZSB0d28gZHJhZnRzIGZvciB0aGUgZmlyc3QgdGltZS48YnI+DQpUaGVyZWZvcmUsIG15IGFwb2xv Z2llcyBmb3IgcG90ZW50aWFsbHkgcmFpc2luZyBwb2ludHMgdGhhdCBoYXZlIGJlZW4gZGlzY3Vz c2VkIGluIHRoZSBwYXN0Ljxicj4NCjxicj4NCiZndDtGcm9tIHRoZSBBUFAgKG9yIEFSVCkgcmV2 aWV3IHBlcnNwZWN0aXZlLCBteSBtYWluIGNvbW1lbnQgaXMgb24gdGhlIHRvcGljIG9mICZxdW90 O1dlYi1CYXNlZCBQZWVyIEF1dGhlbnRpY2F0aW9uJnF1b3Q7LiBXaGlsZSBpdCBpcyBub3QgY2xl YXIgZnJvbSB0aGUgdGV4dCwgd2hpY2ggcGFydHMgYXJlIGFscmVhZHkgc3RhbmRhcmRpemVkIGNv bmNlcHRzIChlLmcuLCBieSBXM0MpIGFuZCB3aGljaCBhcmUgaW50cm9kdWNlZCBoZXJlIGZvciB0 aGUgZmlyc3QgdGltZSwNCiB0aGUgZGVzY3JpYmVkIGFwcHJvYWNoIHNlZW1zIHRvIGJlICgxKSB1 c2VmdWwgdG8gd2ViIGFwcGxpY2F0aW9ucyBiZXlvbmQgV2ViUlRDLCAoMikgdW5kZXIgZGV2ZWxv cG1lbnQgYW5kIHRodXMgcHJvYmFibHkgbm90IHN0YWJsZSwgYW5kICgzKSB0b28gZGV0YWlsZWQg Zm9yICZxdW90O2FuIGFyY2hpdGVjdHVyZSZxdW90OyBkb2N1bWVudC4mbmJzcDsgQXMgc3VjaCwg dGhlIGNvbmNlcHQgb2YgJnF1b3Q7IFdlYi1CYXNlZCBQZWVyIEF1dGhlbnRpY2F0aW9uJnF1b3Q7 IHByb2JhYmx5IG5lZWRzDQogdG8gYmUgaW50cm9kdWNlZCBhbmQgc3RhbmRhcmRpemVkIHVuZGVy IHRoZSBTZWN1cml0eSBBcmVhIGFuZCB0aGVuIGFkb3B0ZWQgYnkgV2ViUlRDIGFuZCBvdGhlciBh cHBzLjxicj4NCjxicj4NCjxhIGhyZWY9Imh0dHBzOi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcvZG9j L2RyYWZ0LWlldGYtcnRjd2ViLXNlY3VyaXR5LyIgdGFyZ2V0PSJfYmxhbmsiPmh0dHBzOi8vZGF0 YXRyYWNrZXIuaWV0Zi5vcmcvZG9jL2RyYWZ0LWlldGYtcnRjd2ViLXNlY3VyaXR5LzwvYT48YnI+ DQpUaGlzIGRvY3VtZW50IGNvbnRhaW5zIGFuIGV4Y2VsbGVudCBjb2xsZWN0aW9uIG9mIHNlY3Vy aXR5IHRocmVhdHMgdG8gV2ViUlRDIGFuZCBkaXNjdXNzZXMgbWFueSBkaWZmZXJlbnQgaWRlYXMg Zm9yIHRoZWlyIHBvdGVudGlhbCBtaXRpZ2F0aW9uLiBUaGF0IGJlaW5nIHNhaWQsIGl0IGlzIG5v dCBhbiBlYXN5IHJlYWQuIFNwZWNpZmljYWxseSwgZnJvbSBoaWdoIGxldmVsIHRvIG1vcmUgc3Bl Y2lmaWM6PGJyPg0KMS4gVGhlIGludGVuZGVkIHN0YXR1cyBvZiB0aGUgZG9jdW1lbnQgaXMgU3Rh bmRhcmRzIFRyYWNrLCB3aGlsZSBhIHR5cGljYWwgc3RhdHVzIG9mIGEgJnF1b3Q7c2VjdXJpdHkg dGhyZWF0IG1vZGVsJnF1b3Q7IFJGQyBpcyBJbmZvcm1hdGlvbmFsLiBUaGlzIGRpc2NyZXBhbmN5 IHByb2JhYmx5IGxpZXMgaW4gdGhlIGN1cnJlbnQgc2NvcGUgb2YgdGhlIGRvY3VtZW50LiBTZWUg dGhlIG5leHQgY29tbWVudCBiZWxvdy48YnI+DQoyLiBUaGUgc2NvcGUgb2YgdGhlIGRvY3VtZW50 IGlzIG5vdCBjbGVhci4gSW4gYWRkaXRpb24gdG8gZGVzY3JpYmluZyB0aGUgc2VjdXJpdHkgdGhy ZWF0cyAoYW5kIHRoZSByZXF1aXJlbWVudHMgb3IgdXNlciBleHBlY3RhdGlvbnMgcmVsYXRlZCB0 byB0aGVpciBwcmV2ZW50aW9uKSwgaW4gbWFueSBwbGFjZXMgdGhlIGRvY3VtZW50IGxpc3RzIHBv dGVudGlhbCBzb2x1dGlvbnMgd2l0aCB0aGVpciBwZXJjZWl2ZWQgbGltaXRhdGlvbnMgYW5kL29y DQogYXBwbGljYWJpbGl0eS4gRXhhbXBsZXMgYXJlIHNlY3Rpb25zOiA0LjIuMSwgNC4yLjIsIDQu Mi4zLCA0LjIuNCwgNC4zLjIuMSwgNC4zLjIuMiwgNC4zLjIuMy4gVG8gaW1wcm92ZSB0aGUgZG9j dW1lbnQncyByZWFkYWJpbGl0eSBhbmQgcmVkdWNlIG92ZXJsYXBzLCZuYnNwOyB0aGUgc29sdXRp b25zIHNob3VsZCBiZSBpbnRyb2R1Y2VkIGFuZCBleHBsYWluZWQgaW4gdGhlIGNvbXBhbmlvbiAm cXVvdDthcmNoaXRlY3R1cmUmcXVvdDsgZG9jdW1lbnQuIFNvbHV0aW9ucycgYXBwbGljYWJpbGl0 eQ0KIHRvIGRpZmZlcmVudCB1c2UgY2FzZXMgbmVlZHMgdG8gYmUgcHJvdmlkZWQgaW4gYSBub24t YmlhcyB3YXkuPGJyPg0KMy4gQXBhcnQgZnJvbSB0aGUgYnJpZWYgSW50cm9kdWN0aW9uIHdpdGgg YSBmZXcgZXhhbXBsZXMsIHRoZXJlIGlzIG5vIGRlc2NyaXB0aW9uIG9mIHRoZSBXZWJSVEMgdGhy ZWF0IG1vZGVsIHB1dHRpbmcgYWxsIG1haW4gdHlwZXMgb2YgdGhyZWF0IGluIG9uZSBwbGFjZS4g Rm9yIGV4YW1wbGUsIHRoZSAmcXVvdDtDb21tdW5pY2F0aW9ucyBTZWN1cml0eSZxdW90OyBhc3Bl Y3QgaXMgaW50cm9kdWNlZCBmb3IgdGhlIGZpcnN0IHRpbWUgaW4gU2VjdGlvbiA0LjMgb25seS4N CiBUaGUgc3RhcnQgb2YgU2VjdGlvbiAmcXVvdDs0LiBTZWN1cml0eSBmb3IgV2ViUlRDIEFwcGxp Y2F0aW9ucyZxdW90OyBjb3VsZCBiZSBhIGxvZ2ljYWwgcGxhY2UgZm9yIGludHJvZHVjaW5nIHRo ZSBXZWJSVEMgdGhyZWF0IG1vZGVsLjxicj4NCjQuIFRoZSAmcXVvdDtzaW1wbGUgV2ViUlRDIHN5 c3RlbSZxdW90OyBwcmVzZW50ZWQgaW4gdGhlIEludHJvZHVjdGlvbiBpbiBGaWd1cmUgMSBpcyBp bmFkZXF1YXRlIHRvIGlsbHVzdHJhdGUgbWFueSBvZiB0aGUgc2NlbmFyaW9zIGFuZCBwb2ludHMg ZGlzY3Vzc2VkIGluIHRoZSBkb2N1bWVudC4gRm9yIGV4YW1wbGUsIHNlZSB0aGUgZGlzY3Vzc2lv biBhcm91bmQgbWVkaWEgb3JpZ2luIHZzLiB3ZWIgb3JpZ2luIGluIFNlY3Rpb24gNC4xLjMuPGJy Pg0KNS4gU2VjdGlvbiAmcXVvdDszLiBUaGUgQnJvd3NlciBUaHJlYXQgTW9kZWwmcXVvdDsgaXMg YW4gb3ZlcnZpZXcgb2YgdGhlIGV4aXN0aW5nIHdlYiBzZWN1cml0eSBhcmNoaXRlY3R1cmUgYW5k IHNvbWUgY3VycmVudCBwcmFjdGljZXMuIEFzIHN1Y2gsIHJlZmVyZW5jZXMgdG8gcmVsZXZhbnQg c3RhbmRhcmRzIChlLmcuLCBXM0MpIGFuZCBjb21tb24gcHJhY3RpY2VzIG5lZWQgdG8gYmUgYWRk ZWQgd2l0aGluIHRoZSB0ZXh0IHRvIGhlbHAgdGhlIHJlYWRlciB0byB1bmRlcnN0YW5kDQogdGhl IHN0YXR1cyBvZiB0aGUgaW5mb3JtYXRpb24gYW5kIHRvIGZvbGxvdyB0aGUgc291cmNlcy48YnI+ DQo2LiBUaGUgbGFzdCBwYXJhZ3JhcGggaW4gU2VjdGlvbiA0LjEgY29udmV5cyBhIGtleSBwb2lu dCBpbiB0aGUgd2hvbGUgV2ViUlRDIHRocmVhdCBtb2RlbC4gQXMgc3VjaCwmbmJzcDsgaXQgbmVl ZHMgdG8gYmUgbW92ZWQgdG8gdGhlIHN0YXJ0IG9mIHRoZSBkaXNjdXNzaW9uIHdoZXJlIHRoZSB0 aHJlYXQgbW9kZWwgaXMgaW50cm9kdWNlZCAoc2VlIGNvbW1lbnRzIGFib3ZlKS48YnI+DQo3LiBT dHlsaXN0aWNhbGx5LCB0aGUgZG9jdW1lbnQgd291bGQgYmVuZWZpdCBmcm9tIHJlbW92aW5nIG5v bi1zdGFuZGFyZHMgdm9jYWJ1bGFyeSwgaS5lLiwgJnF1b3Q7dG8gYnVnJnF1b3Q7LCAmcXVvdDt0 byBidWcgbWUmcXVvdDssICZxdW90O25vIHJlYWwgd2F5JnF1b3Q7LCAmcXVvdDtpdCBpcyBpbXBv cnRhbnQgdG8gcmVxdWlyZSZxdW90OywgJnF1b3Q7ZXh0cmVtZWx5IGFnZ3Jlc3NpdmUgaW50ZXJt ZWRpYXRlcyZxdW90OywmbmJzcDsgYW5kICZxdW90O2ZvciBvYnZpb3VzIHJlYXNvbnMmcXVvdDss IGV0Yy48YnI+DQo4LiBTdWdnZXN0aW9ucyBmb3IgcmVuYW1pbmcgc29tZSBvZiB0aGUgc2VjdGlv bnMgdG8gaW1wcm92ZSByZWFkYWJpbGl0eTo8YnI+DQomcXVvdDszLiBUaGUgQnJvd3NlciBUaHJl YXQgTW9kZWwmcXVvdDsgLSZndDsgJnF1b3Q7IDMuIE92ZXJ2aWV3IG9mIHRoZSBFeGlzdGluZyBX ZWIgVGhyZWF0IE1vZGVsJnF1b3Q7PGJyPg0KJnF1b3Q7NC4xLiBBY2Nlc3MgdG8gTG9jYWwgRGV2 aWNlcyZxdW90OyAtJmd0OyAmcXVvdDs0LjEuIENvbnNlbnQgdG8gQWNjZXNzIExvY2FsIFJlc291 cmNlcyZxdW90Ozxicj4NCiZxdW90OzQuMS4yLiBDYWxsaW5nIFNjZW5hcmlvcyBhbmQgVXNlciBF eHBlY3RhdGlvbnMmcXVvdDsgLSZndDsgJnF1b3Q7NC4xLjIuIFNjb3BlIG9mIENvbnNlbnQgaW4g VmFyaW91cyBDYWxsaW5nIFNjZW5hcmlvcyZxdW90Ozxicj4NCiZxdW90OzQuMS4yLjEuIERlZGlj YXRlZCBDYWxsaW5nIFNlcnZpY2VzJnF1b3Q7IC0mZ3Q7ICZxdW90OzQuMS4yLjEuIExvbmctdGVy bSBDb25zZW50JnF1b3Q7PGJyPg0KJnF1b3Q7NC4xLjIuMi4gQ2FsbGluZyB0aGUgc2l0ZSBZb3Un cmUgT24mcXVvdDsgLSZndDsgJnF1b3Q7NC4xLjIuMi4gU2hvcnQtdGVybSBDb25zZW50JnF1b3Q7 PGJyPg0KJnF1b3Q7NC4xLjMuIE9yaWdpbi1CYXNlZCBTZWN1cml0eSZxdW90OyAtJmd0OyAmcXVv dDs0LjEuMy4gV2ViIEF0dGFja2VycyBhbmQgT3JpZ2luLWJhc2VkIFNlY3VyaXR5JnF1b3Q7PGJy Pg0KJnF1b3Q7NC4xLjQuIFNlY3VyaXR5IFByb3BlcnRpZXMgb2YgdGhlIENhbGxpbmcgUGFnZSZx dW90OyAtJmd0OyAmcXVvdDs0LjEuNC4gTmV0d29yayBBdHRhY2tlcnMgYW5kJm5ic3A7IFNlY3Vy aXR5IFByb3BlcnRpZXMgb2YgdGhlIENhbGxpbmcgUGFnZSZxdW90Ozxicj4NCiZxdW90OzQuMi4g Q29tbXVuaWNhdGlvbnMgQ29uc2VudCBWZXJpZmljYXRpb24mcXVvdDsgLSZndDsgJnF1b3Q7NC4y LiBDb25zZW50IHRvIFJlY2VpdmUgVHJhZmZpYyZxdW90Ozxicj4NCiZxdW90OzQuMy4zLiBNYWxp Y2lvdXMgUGVlcnMmcXVvdDsgLSZndDsgJnF1b3Q7NC4zLjMuIE91dCBvZiBTY29wZSZxdW90Ozxi cj4NCjxicj4NCjxhIGhyZWY9Imh0dHBzOi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcvZG9jL2RyYWZ0 LWlldGYtcnRjd2ViLXNlY3VyaXR5LWFyY2gvIiB0YXJnZXQ9Il9ibGFuayI+aHR0cHM6Ly9kYXRh dHJhY2tlci5pZXRmLm9yZy9kb2MvZHJhZnQtaWV0Zi1ydGN3ZWItc2VjdXJpdHktYXJjaC88L2E+ PGJyPg0KVGhpcyBkb2N1bWVudCBpcyBpbiBhIG11Y2ggYmV0dGVyIHN0YXRlIGluIHRlcm1zIG9m IGl0cyBvcmdhbml6YXRpb24gYW5kIHJlYWRhYmlsaXR5LiBJdCBpbnRyb2R1Y2VzIHRoZSBzZWN1 cml0eSBhcmNoaXRlY3R1cmUgdXNpbmcgYW4gZXhhbXBsZSBhbmQgdGhlbiBsaXN0cyBwb3NzaWJs ZSBhcHByb2FjaGVzIHRvIGltcGxlbWVudCBpdC4gU29tZSBhcHByb2FjaGVzIGFyZSBkZXNjcmli ZWQgb24gYSBoaWdoIGxldmVsIGJ5IHJlZmVyZW5jaW5nIG90aGVyDQogZG9jdW1lbnRzLCB3aGls ZSBvdGhlcnMgYXJlIGludHJvZHVjZWQgZm9yIHRoZSBmaXJzdCB0aW1lIGluIHRoaXMgZG9jdW1l bnQgdG9nZXRoZXIgd2l0aCB0aGVpciBpbXBsZW1lbnRhdGlvbiBkZXRhaWxzLiBCeSBqdXN0IHJl YWRpbmcgdGhlIGRvY3VtZW50LCBpdCBpcyBkaWZmaWN1bHQgdG8ganVkZ2Ugd2hldGhlciB0aGVz ZSBkZXRhaWxzIGFyZSBzdWZmaWNpZW50IG9yIHN0YWJsZSBlbm91Z2ggZm9yIGltcGxlbWVudGF0 aW9uLiBJbiBnZW5lcmFsLA0KIEkgZG91YnQgdGhhdCB0aGlzIGlzIHRoZSBiZXN0IGFwcHJvYWNo IGZvciBhbiAmcXVvdDthcmNoaXRlY3R1cmUmcXVvdDsgZG9jdW1lbnQsIHdoaWNoIGlzIHN1cHBv c2VkIHRvIHNlcnZlIGFzIGEgbG9uZyB0ZXJtIHN0YWJsZSByZWZlcmVuY2UuPGJyPg0KTW9yZSBz cGVjaWZpYyBjb21tZW50czo8YnI+DQoxLiBEaWZmZXJlbnQgdGVybWlub2xvZ3kgaXMgdXNlZCB0 aHJvdWdob3V0IHRoZSBkb2N1bWVudCB0byBhZGRyZXNzIHNhbWUgb3IgY2xvc2UgY29uY2VwdHMu IEl0IHdvdWxkIGhlbHAgYSBsb3QgdG8gZXhwbGFpbiB0aGUgY29uY2VwdHMgdXBmcm9udCBhbmQg dGhlbiB0byB1c2UgdGhlIHRlcm1pbm9sb2d5IGNvbnNpc3RlbnRseS4gQ3VycmVudGx5IGl0IGlu Y2x1ZGVzICZxdW90O2NsaWVudCZxdW90OywgJnF1b3Q7ZW5kcG9pbnQmcXVvdDssJm5ic3A7ICZx dW90O3BlZXImcXVvdDssICZxdW90O3VzZXImcXVvdDs7ICZxdW90O2ltcGxlbWVudGF0aW9uJnF1 b3Q7LA0KICZxdW90O2Jyb3dzZXImcXVvdDssICZxdW90O2Nocm9tZSZxdW90OywgJnF1b3Q7QVBJ JnF1b3Q7LCAmcXVvdDtKUyZxdW90OzsgJnF1b3Q7YXBwbGljYXRpb24mcXVvdDssICZxdW90O3Nl cnZlciZxdW90OywgZXRjLjxicj4NCjIuIFRoZSBkaXNjdXNzaW9uIGlzIHBocmFzZWQgaW4gdGVy bXMgb2YgJnF1b3Q7YXV0aGVudGljYXRpb24mcXVvdDsgYW5kICZxdW90O3RydXN0JnF1b3Q7LiBJ biB0aGluayB0aGF0ICZxdW90O2F1dGhvcml6YXRpb24mcXVvdDsgaW5zdGVhZCBvZiAmcXVvdDt0 cnVzdCZxdW90OyB3b3VsZCBiZSBhIGJldHRlciB0ZWNobmljYWwgdGVybSwgZm9yIGV4YW1wbGUs IGluIFNlY3Rpb24gMy4xLjxicj4NCjMuIEluIHNlY3Rpb24gNC4gT3ZlcnZpZXcsIHNlbnRlbmNl ICZxdW90O3RoZSB0ZW5zaW9uIGJldHdlZW4gc2VjdXJpdHkgKG9yIHBlcmZvcm1hbmNlKSBhbmQg cHJpdmFjeSZxdW90OyBpcyBub3QgY2xlYXIsIGVzcGVjaWFsbHkgYmVjYXVzZSBpdCBkb2Vzbid0 IHNlZW0gdG8gY29ycmVzcG9uZCB0byBTZWN0aW9uIDYuMi4gKEJUVyAmcXVvdDt0cmFkZW9mZiZx dW90OyB3b3VsZCBiZSBhIGJldHRlciB3b3JkIHRoYW4gJnF1b3Q7dGVuc2lvbiZxdW90Oy4pPGJy Pg0KNC4gU2VjdGlvbiAmcXVvdDs0LjEuIEluaXRpYWwgU2lnbmFsaW5nJnF1b3Q7LCB0aGUgdGV4 dCBpcyBpbmNvbnNpc3RlbnQgaW4gdGVybXMgb2Ygd2hldGhlciBBbGljZSBhbmQgQm9iIHNoYXJl IG9yIHVzZSBkaWZmZXJlbnQgaWRlbnRpdHkgcHJvdmlkZXJzLjxicj4NCjUuIFNlY3Rpb24gJnF1 b3Q7NC4xLiBJbml0aWFsIFNpZ25hbGluZyZxdW90OywgcmVmZXJlbmNlIHRvIFBlZXJDb25uZWN0 aW9uIG5lZWRzIHRvIGJlIGFkZGVkLjxicj4NCjYuIFNlY3Rpb24gJnF1b3Q7NC4yLiBNZWRpYSBD b25zZW50IFZlcmlmaWNhdGlvbiZxdW90OyBhbmQgU2VjdGlvbiAmcXVvdDs1LjMgQ29tbXVuaWNh dGlvbnMgQ29uc2VudCZxdW90OzogdGhlIG5hbWUvdGVybWlub2xvZ3kgb2YgdGhpcyBmdW5jdGlv bmFsaXR5IG5lZWRzIHRvIGJlIGhhcm1vbml6ZWQuIFRoZSBJQ0UtYmFzZWQgc29sdXRpb24gd2l0 aCBpdHMgcHJvcywgY29ucyBhcyB3ZWxsIGFzIHRoZSBhbHRlcm5hdGl2ZXMgKGFwcGxpY2FibGUg dG8gZGlmZmVyZW50IHVzZSBjYXNlcykNCiBuZWVkIHRvIGJlIG1vdmVkIGZyb20gdGhlIGNvbXBh bmlvbiB0aHJlYXQgbW9kZWwgZG9jdW1lbnQgdG8gdGhpcyAmcXVvdDthcmNoaXRlY3R1cmUmcXVv dDsgb25lLjxicj4NCjcuIEEgc3VnZ2VzdGlvbjogcmVuYW1lICZxdW90OzUuIERldGFpbGVkIFRl Y2huaWNhbCBEZXNjcmlwdGlvbiZxdW90OyB0byAmcXVvdDs1LiBTZWN1cml0eSBBcmNoaXRlY3R1 cmUgQ29tcG9uZW50cyZxdW90Oy48YnI+DQo4LiBJbiBTZWN0aW9uIDUuMi4sICZxdW90O0ltcGxl bWVudGF0aW9ucyB3aGljaCBzdXBwb3J0IHNvbWUgZm9ybSBvZiBkaXJlY3QgdXNlciBhdXRoZW50 aWNhdGlvbi4uLiZxdW90OyAtJmd0OyAmcXVvdDtJbXBsZW1lbnRhdGlvbnMgdGhhdCBzdXBwb3J0 IHNvbWUgZm9ybSBvZiBkaXJlY3QgdXNlciBhdXRoZW50aWNhdGlvbi4uLiZxdW90Ozxicj4NCjku IFNlY3Rpb24gJnF1b3Q7NS42LiBXZWItQmFzZWQgUGVlciBBdXRoZW50aWNhdGlvbiZxdW90OyBh bmQgc2VjdGlvbiAmcXVvdDs1LjYuMi4gT3ZlcnZpZXcgb2Ygb3BlcmF0aW9uJnF1b3Q7OiBJdCBp cyBub3QgY2xlYXIsIHdoaWNoIHBhcnRzIGFyZSBzdGFuZGFyZGl6ZWQgY29uY2VwdHMgKGUuZy4s IGJ5IFczQykgYW5kIHdoaWNoIGFyZSBpbnRyb2R1Y2VkIGhlcmUgZm9yIHRoZSBmaXJzdCB0aW1l LiBJZiBleGlzdCwgcmVmZXJlbmNlcyB0byBleGlzdGluZyBzdGFuZGFyZHMgbmVlZA0KIHRvIGJl IGFkZGVkLiBUaGUgZGVzY3JpYmVkIGFyY2hpdGVjdHVyZSBhbmQgdGhlIHRlY2huaWNhbCBkZXRh aWxzIHNlZW0gdG8gYmUgKDEpIHVuZGVyIGRldmVsb3BtZW50IGFuZCB0aHVzIHByb2JhYmx5IG5v dCBzdGFibGUsICgyKSB0b28gZGV0YWlsZWQgZm9yICZxdW90O2FuIGFyY2hpdGVjdHVyZSZxdW90 OyBkb2N1bWVudCBhbmQgKDMpIHVzZWZ1bCBiZXlvbmQgV2ViUlRDLiZuYnNwOyBBcyBzdWNoLCB0 aGUgY29uY2VwdCBvZiB0aGUgJnF1b3Q7IFdlYi1CYXNlZCBQZWVyIEF1dGhlbnRpY2F0aW9uJnF1 b3Q7DQogcHJvYmFibHkgbmVlZHMgYmUgaW50cm9kdWNlZCB1bmRlciB0aGUgU2VjdXJpdHkgQXJl YSBhbmQgdGhlbiBhZG9wdGVkIGJ5IFdlYlJUQy48YnI+DQoxMC4gVGhlIHdlYi1iYXNlZCBwZWVy IGF1dGhlbnRpY2F0aW9uIHVzaW5nIElkUCBpcyBub3QgdGhlIG9ubHkgbWVjaGFuaXNtIGFwcGxp Y2FibGUgdG8gV2ViUlRDLiBNb3Jlb3ZlciwgdGhlIHdlYi1iYXNlZCBwZWVyIGF1dGhlbnRpY2F0 aW9uJm5ic3A7IGlzIG5vdCB0aGUgb25seSBhcHByb2FjaCBhcHBsaWNhYmxlIHRvIFdlYlJUQy4g QWx0ZXJuYXRpdmVzIGFyZSBsaXN0ZWQgaW4gdGhlIGNvbXBhbmlvbiBkb2N1bWVudCBhbmQgbmVl ZCB0byBiZSBtb3ZlZA0KIGhlcmUgdG8gdGhlICZxdW90O2FyY2hpdGVjdHVyZSZxdW90OyBkb2N1 bWVudCB3aXRoIHRoZWlyIHByb3MgYW5kIGNvbnMgcHJlc2VudGVkIGluIGFuIHVuYmlhc2VkIHdh eS48YnI+DQoxMS4gU3R5bGlzdGljYWxseSwgdGhlIGRvY3VtZW50IHdvdWxkIGJlbmVmaXQgZnJv bSByZW1vdmluZyBub24tc3RhbmRhcmRzIHZvY2FidWxhcnksIGkuZS4sICZxdW90O3NvbWUgV2Vi IHNlcnZlciZxdW90OywgJnF1b3Q7Y2FuJ3QgcmVhbGx5IHRydXN0JnF1b3Q7LCAmcXVvdDt0aGF0 IG11Y2gmcXVvdDssICZxdW90O2ZhaXJseSBjb252ZW50aW9uYWwmcXVvdDssICZxdW90O3NpbXBs eSBoYXZlJnF1b3Q7LCAmcXVvdDthIGxpdHRsZSBhbnRpY2xpbWFjdGljJnF1b3Q7LCBldGMuIDst KTxicj4NCjxicj4NClRoYW5rcyw8YnI+DQpPcml0LjxvOnA+PC9vOnA+PC9wPg0KPGRpdj4NCjxk aXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87 bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxicj4NCiZndDsgLS0tLS1PcmlnaW5hbCBNZXNz YWdlLS0tLS08YnI+DQomZ3Q7IEZyb206IGFwcHNkaXIgW21haWx0bzo8YSBocmVmPSJtYWlsdG86 YXBwc2Rpci1ib3VuY2VzQGlldGYub3JnIiB0YXJnZXQ9Il9ibGFuayI+YXBwc2Rpci1ib3VuY2Vz QGlldGYub3JnPC9hPl0gT24gQmVoYWxmIE9mIE9yaXQgTGV2aW48YnI+DQomZ3Q7IChMQ0EpPGJy Pg0KJmd0OyBTZW50OiBUaHVyc2RheSwgSnVuZSAyNSwgMjAxNSAxOjE3IFBNPGJyPg0KJmd0OyBU bzogRWxpb3QgTGVhcjsgPGEgaHJlZj0ibWFpbHRvOmFwcHNkaXJAaWV0Zi5vcmciIHRhcmdldD0i X2JsYW5rIj5hcHBzZGlyQGlldGYub3JnPC9hPjxicj4NCiZndDsgU3ViamVjdDogUmU6IFthcHBz ZGlyXSBGd2Q6IFJlcXVlc3QgZm9yIEFwcHMgRGlyZWN0b3JhdGUgcmV2aWV3IG9mIHJ0Y3dlYi08 YnI+DQomZ3Q7IHNlY3VyaXR5IGRyYWZ0czxicj4NCiZndDs8YnI+DQomZ3Q7IFBlcmZlY3QhIEkg aGF2ZSBhIHZlcnkgbG9uZyBmbGlnaHQgb24gdGhlIDd0aC4uLiBTbyByaWdodCBhZnRlciB0aGVu IG9yIGVhcmxpZXIuPGJyPg0KJmd0OyBPcml0Ljxicj4NCiZndDs8YnI+DQomZ3Q7ICZndDsgLS0t LS1PcmlnaW5hbCBNZXNzYWdlLS0tLS08YnI+DQomZ3Q7ICZndDsgRnJvbTogRWxpb3QgTGVhciBb bWFpbHRvOjxhIGhyZWY9Im1haWx0bzpsZWFyQGNpc2NvLmNvbSIgdGFyZ2V0PSJfYmxhbmsiPmxl YXJAY2lzY28uY29tPC9hPl08YnI+DQomZ3Q7ICZndDsgU2VudDogVGh1cnNkYXksIEp1bmUgMjUs IDIwMTUgMTI6NTUgUE08YnI+DQomZ3Q7ICZndDsgVG86IE9yaXQgTGV2aW4gKExDQSk7IDxhIGhy ZWY9Im1haWx0bzphcHBzZGlyQGlldGYub3JnIiB0YXJnZXQ9Il9ibGFuayI+YXBwc2RpckBpZXRm Lm9yZzwvYT48YnI+DQomZ3Q7ICZndDsgU3ViamVjdDogUmU6IFthcHBzZGlyXSBGd2Q6IFJlcXVl c3QgZm9yIEFwcHMgRGlyZWN0b3JhdGUgcmV2aWV3IG9mIHJ0Y3dlYi08YnI+DQomZ3Q7ICZndDsg c2VjdXJpdHkgZHJhZnRzPGJyPg0KJmd0OyAmZ3Q7PGJyPg0KJmd0OyAmZ3Q7IFRoYW5rIHlvdSBP cml0ISZuYnNwOyBDYW4geW91IHRyeSB0byBoYXZlIHRoZW0gZG9uZSBpbiBhYm91dCB0d28gd2Vl a3M/PGJyPg0KJmd0OyAmZ3Q7PGJyPg0KJmd0OyAmZ3Q7IEVsaW90PGJyPg0KJmd0OyAmZ3Q7PGJy Pg0KJmd0OyAmZ3Q7IE9uIDYvMjUvMTUgOTo1MiBQTSwgT3JpdCBMZXZpbiAoTENBKSB3cm90ZTo8 YnI+DQomZ3Q7ICZndDsgJmd0OyBJIHdpbGwgYmUgaGFwcHkgdG8gdGFrZSBhIGxvb2sgYXQgdGhl bSE8YnI+DQomZ3Q7ICZndDsgJmd0OyBPcml0Ljxicj4NCiZndDsgJmd0OyAmZ3Q7PGJyPg0KJmd0 OyAmZ3Q7ICZndDsmZ3Q7IC0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tPGJyPg0KJmd0OyAmZ3Q7 ICZndDsmZ3Q7IEZyb206IGFwcHNkaXIgW21haWx0bzo8YSBocmVmPSJtYWlsdG86YXBwc2Rpci1i b3VuY2VzQGlldGYub3JnIiB0YXJnZXQ9Il9ibGFuayI+YXBwc2Rpci1ib3VuY2VzQGlldGYub3Jn PC9hPl0gT24gQmVoYWxmIE9mIEVsaW90PGJyPg0KJmd0OyBMZWFyPGJyPg0KJmd0OyAmZ3Q7ICZn dDsmZ3Q7IFNlbnQ6IFRodXJzZGF5LCBKdW5lIDI1LCAyMDE1IDExOjQ0IEFNPGJyPg0KJmd0OyAm Z3Q7ICZndDsmZ3Q7IFRvOiA8YSBocmVmPSJtYWlsdG86YXBwc2RpckBpZXRmLm9yZyIgdGFyZ2V0 PSJfYmxhbmsiPmFwcHNkaXJAaWV0Zi5vcmc8L2E+PGJyPg0KJmd0OyAmZ3Q7ICZndDsmZ3Q7IFN1 YmplY3Q6IFthcHBzZGlyXSBGd2Q6IFJlcXVlc3QgZm9yIEFwcHMgRGlyZWN0b3JhdGUgcmV2aWV3 IG9mIHJ0Y3dlYi08YnI+DQomZ3Q7ICZndDsgJmd0OyZndDsgc2VjdXJpdHkgZHJhZnRzPGJyPg0K Jmd0OyAmZ3Q7ICZndDsmZ3Q7PGJyPg0KJmd0OyAmZ3Q7ICZndDsmZ3Q7IERlYXIgQXBwc2RpciBm b2xrLDxicj4NCiZndDsgJmd0OyAmZ3Q7Jmd0Ozxicj4NCiZndDsgJmd0OyAmZ3Q7Jmd0OyBDb3Vs ZCBJIGhhdmUgYSB2b2x1bnRlZXIgdG8gcmV2aWV3IHRoZSBmb2xsb3dpbmcgdHdvIGRyYWZ0cz88 YnI+DQomZ3Q7ICZndDsgJmd0OyZndDs8YnI+DQomZ3Q7ICZndDsgJmd0OyZndDsgPGEgaHJlZj0i aHR0cHM6Ly9kYXRhdHJhY2tlci5pZXRmLm9yZy9kb2MvZHJhZnQtaWV0Zi1ydGN3ZWItc2VjdXJp dHkvIiB0YXJnZXQ9Il9ibGFuayI+DQpodHRwczovL2RhdGF0cmFja2VyLmlldGYub3JnL2RvYy9k cmFmdC1pZXRmLXJ0Y3dlYi1zZWN1cml0eS88L2E+PGJyPg0KJmd0OyAmZ3Q7ICZndDsmZ3Q7PGJy Pg0KJmd0OyAmZ3Q7ICZndDsmZ3Q7IGFuZDxicj4NCiZndDsgJmd0OyAmZ3Q7Jmd0Ozxicj4NCiZn dDsgJmd0OyAmZ3Q7Jmd0OyA8YSBocmVmPSJodHRwczovL2RhdGF0cmFja2VyLmlldGYub3JnL2Rv Yy9kcmFmdC1pZXRmLXJ0Y3dlYi1zZWN1cml0eS1hcmNoLyIgdGFyZ2V0PSJfYmxhbmsiPg0KaHR0 cHM6Ly9kYXRhdHJhY2tlci5pZXRmLm9yZy9kb2MvZHJhZnQtaWV0Zi1ydGN3ZWItc2VjdXJpdHkt YXJjaC88L2E+PGJyPg0KJmd0OyAmZ3Q7ICZndDsmZ3Q7PGJyPg0KJmd0OyAmZ3Q7ICZndDsmZ3Q7 IFRlZCBpcyBleGVtcHQsIGhhdmluZyBtYWRlIHRoZSByZXF1ZXN0IDstKTxicj4NCiZndDsgJmd0 OyAmZ3Q7Jmd0Ozxicj4NCiZndDsgJmd0OyAmZ3Q7Jmd0OyBFbGlvdDxicj4NCiZndDsgJmd0Ozxi cj4NCiZndDs8YnI+DQomZ3Q7IF9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fPGJyPg0KJmd0OyBhcHBzZGlyIG1haWxpbmcgbGlzdDxicj4NCiZndDsgPGEgaHJl Zj0ibWFpbHRvOmFwcHNkaXJAaWV0Zi5vcmciIHRhcmdldD0iX2JsYW5rIj5hcHBzZGlyQGlldGYu b3JnPC9hPjxicj4NCiZndDsgPGEgaHJlZj0iaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9s aXN0aW5mby9hcHBzZGlyIiB0YXJnZXQ9Il9ibGFuayI+aHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFp bG1hbi9saXN0aW5mby9hcHBzZGlyPC9hPjxicj4NCjxicj4NCl9fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fPGJyPg0KYXBwc2RpciBtYWlsaW5nIGxpc3Q8YnI+ DQo8YSBocmVmPSJtYWlsdG86YXBwc2RpckBpZXRmLm9yZyIgdGFyZ2V0PSJfYmxhbmsiPmFwcHNk aXJAaWV0Zi5vcmc8L2E+PGJyPg0KPGEgaHJlZj0iaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1h bi9saXN0aW5mby9hcHBzZGlyIiB0YXJnZXQ9Il9ibGFuayI+aHR0cHM6Ly93d3cuaWV0Zi5vcmcv bWFpbG1hbi9saXN0aW5mby9hcHBzZGlyPC9hPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rp dj4NCjwvYmxvY2txdW90ZT4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1z by1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj4mbmJzcDs8 bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8 L2Rpdj4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9w LWFsdDphdXRvO21hcmdpbi1ib3R0b206MTIuMHB0Ij48YnI+DQpfX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fXzxicj4NCnJ0Y3dlYiBtYWlsaW5nIGxpc3Q8YnI+ DQo8YSBocmVmPSJtYWlsdG86cnRjd2ViQGlldGYub3JnIiB0YXJnZXQ9Il9ibGFuayI+cnRjd2Vi QGlldGYub3JnPC9hPjxicj4NCjxhIGhyZWY9Imh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4v bGlzdGluZm8vcnRjd2ViIiB0YXJnZXQ9Il9ibGFuayI+aHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFp bG1hbi9saXN0aW5mby9ydGN3ZWI8L2E+PG86cD48L286cD48L3A+DQo8L2Jsb2NrcXVvdGU+DQo8 L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0 bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rp dj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2 Pg0KPC9ibG9ja3F1b3RlPg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNw OzwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9ib2R5Pg0KPC9o dG1sPg0K --_000_BL2PR03MB29088098BC3FA25C9D24AC2AD760BL2PR03MB290namprd_-- From nobody Tue Aug 4 16:54:28 2015 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 89E071B2A20 for ; Tue, 4 Aug 2015 16:54:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.978 X-Spam-Level: X-Spam-Status: No, score=-1.978 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, 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 RkeVBxr6cFyy for ; Tue, 4 Aug 2015 16:54:26 -0700 (PDT) Received: from mail-ig0-f171.google.com (mail-ig0-f171.google.com [209.85.213.171]) (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 7C2EE1B29FC for ; Tue, 4 Aug 2015 16:53:39 -0700 (PDT) Received: by igr7 with SMTP id 7so85132083igr.0 for ; Tue, 04 Aug 2015 16:53:39 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=IfeZxmqtZMrllY6u99wnZe55L9spPkOy0+84Ibe9JL4=; b=lI99QQwAdp78bAHQgElMqqxreNTJdT/H69e5Y9tEPEDN5hBd5CIvOU56h8HbD5i6hW EWwrG7Zqy701PjLWw8e/v7BJYE0HJgKB/C5jansjHn7LYVN0lQ5J1l1OG0/1LfBTKtLo FlBs4wrQrUJvjteORufttJFw/NNhUUrry+12I4/05E2pyAw0LZc9EcEmYuZgrH4Que6k fYnYXtgYWxQY/Yw0s8EXtvxNuiNHvO2hoMXk/FP15LQspNYWsFT/SSENJbhQwgv9+HnV F5UbjQW2IeD6/YcNa//oUBbasR8aX2a6+agrioOfu2iu8ZvUy+X6cQN/ltaMTZG5blzB TMaA== X-Gm-Message-State: ALoCoQkFhTVtDaDRKK86JUxGkVDT4S1p/lclcCKhzUg9bktT8pxqJDvx8niFawXwnGU3Mj9QgMNW X-Received: by 10.50.124.33 with SMTP id mf1mr307885igb.23.1438732419024; Tue, 04 Aug 2015 16:53:39 -0700 (PDT) Received: from mail-io0-f179.google.com (mail-io0-f179.google.com. [209.85.223.179]) by smtp.gmail.com with ESMTPSA id d70sm737056ioj.43.2015.08.04.16.53.37 for (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 04 Aug 2015 16:53:37 -0700 (PDT) Received: by ioeg141 with SMTP id g141so33402499ioe.3 for ; Tue, 04 Aug 2015 16:53:37 -0700 (PDT) MIME-Version: 1.0 X-Received: by 10.107.13.201 with SMTP id 192mr7276383ion.70.1438732417323; Tue, 04 Aug 2015 16:53:37 -0700 (PDT) Received: by 10.36.89.70 with HTTP; Tue, 4 Aug 2015 16:53:37 -0700 (PDT) In-Reply-To: References: <7594FB04B1934943A5C02806D1A2204B348E82CA@ESESSMB209.ericsson.se> Date: Tue, 4 Aug 2015 19:53:37 -0400 Message-ID: From: Roman Shpount To: "Asveren, Tolga" Content-Type: multipart/alternative; boundary=001a113fd5e0a958d9051c84fe87 Archived-At: Cc: "" Subject: Re: [rtcweb] What the gateway draft should say about mux/non-mux X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 04 Aug 2015 23:54:27 -0000 --001a113fd5e0a958d9051c84fe87 Content-Type: text/plain; charset=UTF-8 On Tue, Aug 4, 2015 at 7:43 PM, Asveren, Tolga wrote: > Again, my opinion (actually more than an opinion, it is an observation) is > that whatever browsers do is followed/implemented by other entities if they > are expected to interface with them -even to the level of specification > violations-. So, the notion of "de facto Internet Profile" seems to be > working pretty efficiently. > In some ways you are right and this group is just a way for web browser makers to ask the technical community opinion on how things should be built. It worked well so far. So, I guess, you can treat this whole discussion as web browser makers asking nicely if anybody have any objections to removing support for non muxed RTCP in web browsers. So far nobody here voice any. _____________ Roman Shpount --001a113fd5e0a958d9051c84fe87 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On T= ue, Aug 4, 2015 at 7:43 PM, Asveren, Tolga <tasveren@sonusnet.com&= gt; wrote:

Again, my opinion (actually more than an = opinion, it is an observation) is that whatever browsers do is followed/imp= lemented by other entities if they are expected to interface=C2=A0with them= =C2=A0-even to the level of specification violations-. So, the notion of "de facto Internet Profile" seems to be working pretty efficient= ly.

In some ways you are right and = this group is just a way for web browser makers to ask the technical commun= ity opinion on how things should be built. It worked well so far.

So, I guess, you can treat this whole discussion as web bro= wser makers asking nicely if anybody have any objections to removing suppor= t for non muxed RTCP in web browsers. So far nobody here voice any.
_____________
Roman Shpount
=C2=A0
--001a113fd5e0a958d9051c84fe87-- From nobody Tue Aug 4 19:04:04 2015 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A34C51A8716 for ; Tue, 4 Aug 2015 19:04:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id iIfKBBSj2ORw for ; Tue, 4 Aug 2015 19:04:00 -0700 (PDT) Received: from mail-pa0-x230.google.com (mail-pa0-x230.google.com [IPv6:2607:f8b0:400e:c03::230]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 98D6D1A1BF2 for ; Tue, 4 Aug 2015 19:04:00 -0700 (PDT) Received: by padck2 with SMTP id ck2so22624947pad.0 for ; Tue, 04 Aug 2015 19:04:00 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=content-type:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=sSl/vrt7dMlLnY81d1T5GeKMnELkEAf6ef/xohqR5YE=; b=vbwC7JGzQiXaEqoqsw8FN5HEsm7oZjqztEMueS00D+mSyMjmKIhuS17DHtF64XPGIq XR3yFzeh5NXPZlj3okuO1pUliKm5PnFVkoGSArPygeT2cMxbRFuNAd16ngab4OIXJwlu rbx0DTfUUymeowQy+3p9r4UlIEg3fwtOGpLuSzhnqDK1dsmnZrkpJwpKJeh+EmnVkm3/ WDVUBI8ehUyiT1QpD91iMImTz2a2TjyW2gsyNfmr3T9Pftv2TKXL09iG1CrdN/1wyES5 pzjslVZUPvQYLjlwYC3AxZ4CchFuGPrXDri1lmiviPQ+OdFEshbLqW8i+McSUNV/nPtt bYBg== X-Received: by 10.66.186.195 with SMTP id fm3mr14045001pac.91.1438740240119; Tue, 04 Aug 2015 19:04:00 -0700 (PDT) Received: from [192.168.1.110] (c-71-227-237-49.hsd1.wa.comcast.net. [71.227.237.49]) by smtp.gmail.com with ESMTPSA id pd10sm745956pdb.66.2015.08.04.19.03.58 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Tue, 04 Aug 2015 19:03:59 -0700 (PDT) Content-Type: multipart/alternative; boundary=Apple-Mail-766FCE0C-B3C3-41D7-9DFC-AED09005FB65 Mime-Version: 1.0 (1.0) From: Bernard Aboba X-Mailer: iPad Mail (12H143) In-Reply-To: Date: Tue, 4 Aug 2015 19:03:57 -0700 Content-Transfer-Encoding: 7bit Message-Id: <05B3C43B-2823-4590-889E-7A192FC8A3AD@gmail.com> References: <7594FB04B1934943A5C02806D1A2204B348E82CA@ESESSMB209.ericsson.se> To: Roman Shpount Archived-At: Cc: "" Subject: Re: [rtcweb] What the gateway draft should say about mux/non-mux X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 05 Aug 2015 02:04:02 -0000 --Apple-Mail-766FCE0C-B3C3-41D7-9DFC-AED09005FB65 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable On Aug 4, 2015, at 16:33, Roman Shpount wrote: >=20 > Most of the people implement this wrong, since you need to create two DTLS= sessions: one for RTP and another for RTCP. And then use different keys or p= ossibly even encryption profiles for RTP and RTCP. I commonly see one sessio= n for RTP and keys negotiated there used for both RTP and RTCP, which is wro= ng. [BA] Yes, that is only one of several common mistakes. Unfortunately, RFC 5= 764 does not rule out all of these and the security documents are not crysta= l clear on how things must be done. It is much harder to mess up RTP/RTCP mu= x. Given what I've seen so far, non-mux could become a support nightmare.=20= --Apple-Mail-766FCE0C-B3C3-41D7-9DFC-AED09005FB65 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 7bit
On Aug 4, 2015, at 16:33, Roman Shpount <roman@telurix.com> wrote:

Most of the people implement this wrong, since you need to create two DTLS sessions: one for RTP and another for RTCP. And then use different keys or possibly even encryption profiles for RTP and RTCP. I commonly see one session for RTP and keys negotiated there used for both RTP and RTCP, which is wrong.

[BA] Yes, that is only one of several common mistakes.  Unfortunately, RFC 5764 does not rule out all of these and the security documents are not crystal clear on how things must be done. It is much harder to mess up RTP/RTCP mux.  Given what I've seen so far, non-mux could become a support nightmare. 
--Apple-Mail-766FCE0C-B3C3-41D7-9DFC-AED09005FB65-- From nobody Wed Aug 5 01:03:47 2015 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 541311B2D6B; Wed, 5 Aug 2015 01:03:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.909 X-Spam-Level: X-Spam-Status: No, score=-6.909 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, 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 9498k-293C70; Wed, 5 Aug 2015 01:03:41 -0700 (PDT) Received: from smtp-fr.alcatel-lucent.com (fr-hpgre-esg-01.alcatel-lucent.com [135.245.210.22]) (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 72CF61B2D68; Wed, 5 Aug 2015 01:03:40 -0700 (PDT) Received: from fr711usmtp1.zeu.alcatel-lucent.com (unknown [135.239.2.122]) by Websense Email Security Gateway with ESMTPS id 9DD6811CF6F7E; Wed, 5 Aug 2015 08:03:37 +0000 (GMT) Received: from FR712WXCHHUB03.zeu.alcatel-lucent.com (fr712wxchhub03.zeu.alcatel-lucent.com [135.239.2.74]) by fr711usmtp1.zeu.alcatel-lucent.com (GMO) with ESMTP id t7583cw5025443 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Wed, 5 Aug 2015 10:03:38 +0200 Received: from FR711WXCHMBA03.zeu.alcatel-lucent.com ([169.254.3.123]) by FR712WXCHHUB03.zeu.alcatel-lucent.com ([135.239.2.74]) with mapi id 14.03.0195.001; Wed, 5 Aug 2015 10:03:38 +0200 From: "Schwarz, Albrecht (Albrecht)" To: "" Thread-Topic: Number of DTLS sessions/DTLS connections; RE: [rtcweb] What the gateway draft should say about mux/non-mux Thread-Index: AQHQzw3+KxT/0f1cqU+61qeHi7bRGJ38hlaAgAB9WhA= Date: Wed, 5 Aug 2015 08:03:37 +0000 Message-ID: <786615F3A85DF44AA2A76164A71FE1AC7ADB9197@FR711WXCHMBA03.zeu.alcatel-lucent.com> References: <7594FB04B1934943A5C02806D1A2204B348E82CA@ESESSMB209.ericsson.se> <05B3C43B-2823-4590-889E-7A192FC8A3AD@gmail.com> In-Reply-To: <05B3C43B-2823-4590-889E-7A192FC8A3AD@gmail.com> Accept-Language: de-DE, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [135.239.27.39] Content-Type: multipart/alternative; boundary="_000_786615F3A85DF44AA2A76164A71FE1AC7ADB9197FR711WXCHMBA03z_" MIME-Version: 1.0 Archived-At: Cc: "TLS@ietf.org \(tls@ietf.org\)" Subject: [rtcweb] Number of DTLS sessions/DTLS connections; RE: What the gateway draft should say about mux/non-mux X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 05 Aug 2015 08:03:44 -0000 --_000_786615F3A85DF44AA2A76164A71FE1AC7ADB9197FR711WXCHMBA03z_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 Um9tYW4sIEJlcm5hcmQsDQpyaWdodCwgUkZDIDU3NjQgaXMgdG9vIHZhZ3VlIG9uIHRoYXQgYXNw ZWN0LiBUaGFua3MgZm9yIGNvbmZpcm1pbmcgdGhlIG51bWJlciBvZiBEVExTIHNlc3Npb25zLCB3 aGljaCBpcyBpbmxpbmUgd2l0aCBvdXIgdW5kZXJzdGFuZGluZy4NCldvdWxkIGFwcHJlY2lhdGUg aWYgdGhpcyBjb3VsZCBiZSBzb21ld2hlcmUgZml4ZWQgaW4gYW4gcnRjd2ViIGRyYWZ0IGR1ZSB0 byBzaWduaWZpY2FudCBzaWRlIGVmZmVjdHMuDQpUaGlzIHRvcGljIGlzIGFsc28gYW4gb25nb2lu ZyBGQVEuDQoNClRoZSBtb3N0IHNpbXBsZSBjYXNlIGlzIGdpdmVuIGJ5IGEgc2NlbmFyaW8gd2l0 aCB1c2FnZSBvZiBidW5kbGluZyBwbHVzIHVzYWdlIG9mIFJUUC9SVENQIHRyYW5zcG9ydCBtdWx0 aXBsZXhpbmcsIGxlYWRpbmcgdG8gYSBzaW5nbGUgRFRMUyBzZXNzaW9uL0RUTFMgY29ubmVjdGlv biwgd2hpY2ggY291bGQgYmUgdGhlbiBhbHNvIHNoYXJlZCBmb3IgV2ViUlRDIGRhdGEuDQoNCkJv dGggY2FwYWJpbGl0aWVzIGFyZSBtYW5kYXRlZCBpbiB0aGUgcnRwIHVzYWdlIGRyYWZ0Og0KaHR0 cHM6Ly90b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0LWlldGYtcnRjd2ViLXJ0cC11c2FnZS0yNSNz ZWN0aW9uLTQuNA0KPT4gYnVuZGxpbmcNCmh0dHBzOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFm dC1pZXRmLXJ0Y3dlYi1ydHAtdXNhZ2UtMjUjc2VjdGlvbi00LjUNCj0+IFJUUC9SVENQIHRyYW5z cG9ydCBtdWx0aXBsZXhpbmcNCg0KTm93LCBJRiBidW5kbGluZyBpcyBub3QgdXNlZCBPUiBSVFAv UlRDUCB0cmFuc3BvcnQgbXVsdGlwbGV4aW5nIGlzIG5vdCB1c2VkIFRIRU4gdGhlcmUgd2lsbCBi ZSBtb3JlIHRoYW4gb25lIERUTFMgc2Vzc2lvbi9EVExTIGNvbm5lY3Rpb24gKGVpdGhlciAyIG9y IDQgaW4gY2FzZSBvZiBhdWRpbyAmIHZpZGVvKS4NClJhaXNpbmcgdGhlIHF1ZXN0aW9uIHdoaWNo IERUTFMgY29ubmVjdGlvbiBpcyB1c2VkIGZvciBhZGRpdGlvbmFsIFdlYlJUQyBkYXRhIHRyYWZm aWM/IC0gQmVjYXVzZQ0KaHR0cHM6Ly90b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0LWlldGYtcnRj d2ViLXRyYW5zcG9ydHMtMDkjc2VjdGlvbi0zLjUNCmluZGljYXRlcyB0aGUgc2hhcmluZyBvcHRp b24uDQpXb3VsZCB0aGVuIGJlIGEgM3JkIChvciA1dGgpIHNlbGYtY29udGFpbmVkIERUTFMgc2Vz c2lvbi9EVExTIGNvbm5lY3Rpb24gZm9yIFdlYlJUQyBkYXRhIHRyYWZmaWM/DQoNClByb3Bvc2Fs Og0KQWRkIGV4cGxpY2l0IHRleHQgdG8gY2xhdXNlIGh0dHBzOi8vdG9vbHMuaWV0Zi5vcmcvaHRt bC9kcmFmdC1pZXRmLXJ0Y3dlYi10cmFuc3BvcnRzLTA5I3NlY3Rpb24tMy41DQphYm91dCAoaW4g cmVkKSwgc29tZXRoaW5nIGxpa2U6DQoNCiAgIFdlYlJUQyBpbXBsZW1lbnRhdGlvbnMgTVVTVCBz dXBwb3J0IG11bHRpcGxleGluZyBvZiBEVExTIGFuZCBSVFAgb3Zlcg0KICAgdGhlIHNhbWUgcG9y dCBwYWlyLCBhcyBkZXNjcmliZWQgaW4gdGhlIERUTFMtU1JUUCBzcGVjaWZpY2F0aW9uDQogICBb UkZDNTc2NF0sIHNlY3Rpb24gNS4xLjI8aHR0cHM6Ly90b29scy5pZXRmLm9yZy9odG1sL3JmYzU3 NjQjc2VjdGlvbi01LjEuMj4uICBBbGwgYXBwbGljYXRpb24gbGF5ZXIgcHJvdG9jb2wgcGF5bG9h ZHMNCiAgIG92ZXIgdGhpcyBEVExTIGNvbm5lY3Rpb24gYXJlIFNDVFAgcGFja2V0cy4NCg0KDQoN CiAgIE5vdGUgMTogVGhlcmUgd2lsbCBiZSB0d28gRFRMUyBzZXNzaW9ucy9EVExTIGNvbm5lY3Rp b25zIHdoZW4gUlRQL1JUQ1AgdHJhbnNwb3J0IG11bHRpcGxleGluZyBpcyBub3QgYXBwbGllZC4g V2ViUlRDIGRhdGEgdHJhZmZpYyBjb3VsZCBzdGlsbCBzaGFyZSBvbmUgb2YgdGhlc2UgRFRMUyBj b25uZWN0aW9ucyDigKYgKOKAnHdoaWNoIG9uZT/igJ0pIOKApiBvciBUaGVyZSBzaG91bGQgYmUg dGhlbiBhIHNlcGFyYXRlLCBzZWxmLWNvbnRhaW5lZCBEVExTIHNlc3Npb24vRFRMUyBjb25uZWN0 aW9uIGVzdGFibGlzaGVkIGV4Y2x1c2l2ZWx5IGZvciBXZWJSVEMgZGF0YS4NCg0KDQoNCiAgIE5v dGUgMjogVGhlcmUgYXJlIHNpbWlsYXIgY29uc2lkZXJhdGlvbnMgaW4gY2FzZSBvZiBidW5kbGlu Zy4NCg0KICAgUHJvdG9jb2wgaWRlbnRpZmljYXRpb24gTVVTVCBiZSBzdXBwbGllZCBhcyBwYXJ0 IG9mIHRoZSBEVExTDQogICBoYW5kc2hha2UsIGFzIHNwZWNpZmllZCBpbiBbSS1ELmlldGYtcnRj d2ViLWFscG48aHR0cHM6Ly90b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0LWlldGYtcnRjd2ViLXRy YW5zcG9ydHMtMDkjcmVmLUktRC5pZXRmLXJ0Y3dlYi1hbHBuPl0uDQoNCkNvbW1lbnRzPw0KUmVn YXJkcywNCkFsYnJlY2h0DQoNClBTDQpVc2luZyAoRClUTFMgdGVybWlub2xvZ3kgYWNjb3JkaW5n IHRvIGh0dHA6Ly90b29scy5pZXRmLm9yZy9pZC9kcmFmdC1ndWJhbGxhLXRscy10ZXJtaW5vbG9n eS0wMS50eHQNCg0KDQpGcm9tOiBCZXJuYXJkIEFib2JhIFttYWlsdG86YmVybmFyZC5hYm9iYUBn bWFpbC5jb21dDQpTZW50OiBNaXR0d29jaCwgNS4gQXVndXN0IDIwMTUgMDQ6MDQNClRvOiBSb21h biBTaHBvdW50DQpDYzogQXN2ZXJlbiwgVG9sZ2E7IENocmlzdGVyIEhvbG1iZXJnOyBFcmljIFJl c2NvcmxhOyBTY2h3YXJ6LCBBbGJyZWNodCAoQWxicmVjaHQpOyBSYXVzY2hlbmJhY2gsIFV3ZSAo Tm9raWEgLSBERS9NdW5pY2gpOyA8cnRjd2ViQGlldGYub3JnPg0KU3ViamVjdDogUmU6IFtydGN3 ZWJdIFdoYXQgdGhlIGdhdGV3YXkgZHJhZnQgc2hvdWxkIHNheSBhYm91dCBtdXgvbm9uLW11eA0K DQpPbiBBdWcgNCwgMjAxNSwgYXQgMTY6MzMsIFJvbWFuIFNocG91bnQgPHJvbWFuQHRlbHVyaXgu Y29tPG1haWx0bzpyb21hbkB0ZWx1cml4LmNvbT4+IHdyb3RlOg0KDQpNb3N0IG9mIHRoZSBwZW9w bGUgaW1wbGVtZW50IHRoaXMgd3JvbmcsIHNpbmNlIHlvdSBuZWVkIHRvIGNyZWF0ZSB0d28gRFRM UyBzZXNzaW9uczogb25lIGZvciBSVFAgYW5kIGFub3RoZXIgZm9yIFJUQ1AuIEFuZCB0aGVuIHVz ZSBkaWZmZXJlbnQga2V5cyBvciBwb3NzaWJseSBldmVuIGVuY3J5cHRpb24gcHJvZmlsZXMgZm9y IFJUUCBhbmQgUlRDUC4gSSBjb21tb25seSBzZWUgb25lIHNlc3Npb24gZm9yIFJUUCBhbmQga2V5 cyBuZWdvdGlhdGVkIHRoZXJlIHVzZWQgZm9yIGJvdGggUlRQIGFuZCBSVENQLCB3aGljaCBpcyB3 cm9uZy4NCg0KW0JBXSBZZXMsIHRoYXQgaXMgb25seSBvbmUgb2Ygc2V2ZXJhbCBjb21tb24gbWlz dGFrZXMuICBVbmZvcnR1bmF0ZWx5LCBSRkMgNTc2NCBkb2VzIG5vdCBydWxlIG91dCBhbGwgb2Yg dGhlc2UgYW5kIHRoZSBzZWN1cml0eSBkb2N1bWVudHMgYXJlIG5vdCBjcnlzdGFsIGNsZWFyIG9u IGhvdyB0aGluZ3MgbXVzdCBiZSBkb25lLiBJdCBpcyBtdWNoIGhhcmRlciB0byBtZXNzIHVwIFJU UC9SVENQIG11eC4gIEdpdmVuIHdoYXQgSSd2ZSBzZWVuIHNvIGZhciwgbm9uLW11eCBjb3VsZCBi ZWNvbWUgYSBzdXBwb3J0IG5pZ2h0bWFyZS4NCg== --_000_786615F3A85DF44AA2A76164A71FE1AC7ADB9197FR711WXCHMBA03z_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTIgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 V2luZ2RpbmdzOw0KCXBhbm9zZS0xOjUgMCAwIDAgMCAwIDAgMCAwIDA7fQ0KQGZvbnQtZmFjZQ0K CXtmb250LWZhbWlseToiQ2FtYnJpYSBNYXRoIjsNCglwYW5vc2UtMToyIDQgNSAzIDUgNCA2IDMg MiA0O30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6Q2FsaWJyaTsNCglwYW5vc2UtMToyIDE1 IDUgMiAyIDIgNCAzIDIgNDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OlRhaG9tYTsNCglw YW5vc2UtMToyIDExIDYgNCAzIDUgNCA0IDIgNDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5 OkNvbnNvbGFzOw0KCXBhbm9zZS0xOjIgMTEgNiA5IDIgMiA0IDMgMiA0O30NCi8qIFN0eWxlIERl ZmluaXRpb25zICovDQpwLk1zb05vcm1hbCwgbGkuTXNvTm9ybWFsLCBkaXYuTXNvTm9ybWFsDQoJ e21hcmdpbjowY207DQoJbWFyZ2luLWJvdHRvbTouMDAwMXB0Ow0KCWZvbnQtc2l6ZToxMi4wcHQ7 DQoJZm9udC1mYW1pbHk6IlRpbWVzIE5ldyBSb21hbiIsInNlcmlmIjt9DQphOmxpbmssIHNwYW4u TXNvSHlwZXJsaW5rDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgljb2xvcjpibHVlOw0KCXRl eHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0KYTp2aXNpdGVkLCBzcGFuLk1zb0h5cGVybGlua0Zv bGxvd2VkDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgljb2xvcjpwdXJwbGU7DQoJdGV4dC1k ZWNvcmF0aW9uOnVuZGVybGluZTt9DQpwcmUNCgl7bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCW1z by1zdHlsZS1saW5rOiJIVE1MIFByZWZvcm1hdHRlZCBDaGFyIjsNCgltYXJnaW46MGNtOw0KCW1h cmdpbi1ib3R0b206LjAwMDFwdDsNCglmb250LXNpemU6MTAuMHB0Ow0KCWZvbnQtZmFtaWx5OiJD b3VyaWVyIE5ldyI7fQ0KcC5Nc29MaXN0UGFyYWdyYXBoLCBsaS5Nc29MaXN0UGFyYWdyYXBoLCBk aXYuTXNvTGlzdFBhcmFncmFwaA0KCXttc28tc3R5bGUtcHJpb3JpdHk6MzQ7DQoJbWFyZ2luLXRv cDowY207DQoJbWFyZ2luLXJpZ2h0OjBjbTsNCgltYXJnaW4tYm90dG9tOjBjbTsNCgltYXJnaW4t bGVmdDozNi4wcHQ7DQoJbWFyZ2luLWJvdHRvbTouMDAwMXB0Ow0KCWZvbnQtc2l6ZToxMi4wcHQ7 DQoJZm9udC1mYW1pbHk6IlRpbWVzIE5ldyBSb21hbiIsInNlcmlmIjt9DQpzcGFuLkVtYWlsU3R5 bGUxNw0KCXttc28tc3R5bGUtdHlwZTpwZXJzb25hbC1yZXBseTsNCglmb250LWZhbWlseToiQ2Fs aWJyaSIsInNhbnMtc2VyaWYiOw0KCWNvbG9yOiMxRjQ5N0Q7fQ0Kc3Bhbi5IVE1MUHJlZm9ybWF0 dGVkQ2hhcg0KCXttc28tc3R5bGUtbmFtZToiSFRNTCBQcmVmb3JtYXR0ZWQgQ2hhciI7DQoJbXNv LXN0eWxlLXByaW9yaXR5Ojk5Ow0KCW1zby1zdHlsZS1saW5rOiJIVE1MIFByZWZvcm1hdHRlZCI7 DQoJZm9udC1mYW1pbHk6IkNvdXJpZXIgTmV3Ijt9DQouTXNvQ2hwRGVmYXVsdA0KCXttc28tc3R5 bGUtdHlwZTpleHBvcnQtb25seTsNCglmb250LXNpemU6MTAuMHB0O30NCkBwYWdlIFdvcmRTZWN0 aW9uMQ0KCXtzaXplOjYxMi4wcHQgNzkyLjBwdDsNCgltYXJnaW46NzIuMHB0IDcyLjBwdCA3Mi4w cHQgNzIuMHB0O30NCmRpdi5Xb3JkU2VjdGlvbjENCgl7cGFnZTpXb3JkU2VjdGlvbjE7fQ0KLyog TGlzdCBEZWZpbml0aW9ucyAqLw0KQGxpc3QgbDANCgl7bXNvLWxpc3QtaWQ6MjA3NDExNDc5NjsN Cgltc28tbGlzdC10eXBlOmh5YnJpZDsNCgltc28tbGlzdC10ZW1wbGF0ZS1pZHM6LTczMTAzMzc4 IDEzNDgwNzU1MyAxMzQ4MDc1NTUgMTM0ODA3NTU3IDEzNDgwNzU1MyAxMzQ4MDc1NTUgMTM0ODA3 NTU3IDEzNDgwNzU1MyAxMzQ4MDc1NTUgMTM0ODA3NTU3O30NCkBsaXN0IGwwOmxldmVsMQ0KCXtt c28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ674K3Ow0KCW1z by1sZXZlbC10YWItc3RvcDpub25lOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsN Cgl0ZXh0LWluZGVudDotMTguMHB0Ow0KCWZvbnQtZmFtaWx5OlN5bWJvbDt9DQpvbA0KCXttYXJn aW4tYm90dG9tOjBjbTt9DQp1bA0KCXttYXJnaW4tYm90dG9tOjBjbTt9DQotLT48L3N0eWxlPjwh LS1baWYgZ3RlIG1zbyA5XT48eG1sPg0KPG86c2hhcGVkZWZhdWx0cyB2OmV4dD0iZWRpdCIgc3Bp ZG1heD0iMTAyNiIgLz4NCjwveG1sPjwhW2VuZGlmXS0tPjwhLS1baWYgZ3RlIG1zbyA5XT48eG1s Pg0KPG86c2hhcGVsYXlvdXQgdjpleHQ9ImVkaXQiPg0KPG86aWRtYXAgdjpleHQ9ImVkaXQiIGRh dGE9IjEiIC8+DQo8L286c2hhcGVsYXlvdXQ+PC94bWw+PCFbZW5kaWZdLS0+DQo8L2hlYWQ+DQo8 Ym9keSBsYW5nPSJFTi1HQiIgbGluaz0iYmx1ZSIgdmxpbms9InB1cnBsZSI+DQo8ZGl2IGNsYXNz PSJXb3JkU2VjdGlvbjEiPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQt c2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6Q29uc29sYXM7Y29sb3I6IzFGNDk3RCI+Um9tYW4sIEJl cm5hcmQsPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4g c3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6Q29uc29sYXM7Y29sb3I6IzFGNDk3 RCI+cmlnaHQsIFJGQyA1NzY0IGlzIHRvbyB2YWd1ZSBvbiB0aGF0IGFzcGVjdC4gVGhhbmtzIGZv ciBjb25maXJtaW5nIHRoZSBudW1iZXIgb2YgRFRMUyBzZXNzaW9ucywgd2hpY2ggaXMgaW5saW5l IHdpdGggb3VyIHVuZGVyc3RhbmRpbmcuPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6Q29u c29sYXM7Y29sb3I6IzFGNDk3RCI+V291bGQgYXBwcmVjaWF0ZSBpZiB0aGlzIGNvdWxkIGJlIHNv bWV3aGVyZSBmaXhlZCBpbiBhbiBydGN3ZWIgZHJhZnQgZHVlIHRvIHNpZ25pZmljYW50IHNpZGUg ZWZmZWN0cy48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3Bh biBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTpDb25zb2xhcztjb2xvcjojMUY0 OTdEIj5UaGlzIHRvcGljIGlzIGFsc28gYW4gb25nb2luZyBGQVEuPG86cD48L286cD48L3NwYW4+ PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7 Zm9udC1mYW1pbHk6Q29uc29sYXM7Y29sb3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8L286cD48L3Nw YW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4w cHQ7Zm9udC1mYW1pbHk6Q29uc29sYXM7Y29sb3I6IzFGNDk3RCI+VGhlIG1vc3Qgc2ltcGxlIGNh c2UgaXMgZ2l2ZW4gYnkgYSBzY2VuYXJpbyB3aXRoIHVzYWdlIG9mIGJ1bmRsaW5nIHBsdXMgdXNh Z2Ugb2YgUlRQL1JUQ1AgdHJhbnNwb3J0IG11bHRpcGxleGluZywgbGVhZGluZyB0byBhIHNpbmds ZSBEVExTIHNlc3Npb24vRFRMUyBjb25uZWN0aW9uLCB3aGljaA0KIGNvdWxkIGJlIHRoZW4gYWxz byBzaGFyZWQgZm9yIFdlYlJUQyBkYXRhLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OkNv bnNvbGFzO2NvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5 OkNvbnNvbGFzO2NvbG9yOiMxRjQ5N0QiPkJvdGggY2FwYWJpbGl0aWVzIGFyZSBtYW5kYXRlZCBp biB0aGUgcnRwIHVzYWdlIGRyYWZ0OjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OkNvbnNv bGFzO2NvbG9yOiMxRjQ5N0QiPjxhIGhyZWY9Imh0dHBzOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9k cmFmdC1pZXRmLXJ0Y3dlYi1ydHAtdXNhZ2UtMjUjc2VjdGlvbi00LjQiPjxzcGFuIGxhbmc9IkRF Ij5odHRwczovL3Rvb2xzLmlldGYub3JnL2h0bWwvZHJhZnQtaWV0Zi1ydGN3ZWItcnRwLXVzYWdl LTI1I3NlY3Rpb24tNC40PC9zcGFuPjwvYT48L3NwYW4+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTox MS4wcHQ7Zm9udC1mYW1pbHk6Q29uc29sYXM7Y29sb3I6IzFGNDk3RCI+DQo8c3BhbiBsYW5nPSJE RSI+PGJyPg0KPSZndDsgYnVuZGxpbmc8bzpwPjwvbzpwPjwvc3Bhbj48L3NwYW4+PC9wPg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1p bHk6Q29uc29sYXM7Y29sb3I6IzFGNDk3RCI+PGEgaHJlZj0iaHR0cHM6Ly90b29scy5pZXRmLm9y Zy9odG1sL2RyYWZ0LWlldGYtcnRjd2ViLXJ0cC11c2FnZS0yNSNzZWN0aW9uLTQuNSI+aHR0cHM6 Ly90b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0LWlldGYtcnRjd2ViLXJ0cC11c2FnZS0yNSNzZWN0 aW9uLTQuNTwvYT4NCjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OkNvbnNvbGFzO2NvbG9y OiMxRjQ5N0QiPj0mZ3Q7IFJUUC9SVENQIHRyYW5zcG9ydCBtdWx0aXBsZXhpbmc8bzpwPjwvbzpw Pjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXpl OjExLjBwdDtmb250LWZhbWlseTpDb25zb2xhcztjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwv bzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1z aXplOjExLjBwdDtmb250LWZhbWlseTpDb25zb2xhcztjb2xvcjojMUY0OTdEIj5Ob3csIElGIGJ1 bmRsaW5nIGlzIG5vdCB1c2VkIE9SIFJUUC9SVENQIHRyYW5zcG9ydCBtdWx0aXBsZXhpbmcgaXMg bm90IHVzZWQgVEhFTiB0aGVyZSB3aWxsIGJlIG1vcmUgdGhhbiBvbmUgRFRMUyBzZXNzaW9uL0RU TFMgY29ubmVjdGlvbiAoZWl0aGVyIDIgb3IgNCBpbiBjYXNlIG9mIGF1ZGlvDQogJmFtcDsgdmlk ZW8pLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0 eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OkNvbnNvbGFzO2NvbG9yOiMxRjQ5N0Qi PlJhaXNpbmcgdGhlIHF1ZXN0aW9uIHdoaWNoIERUTFMgY29ubmVjdGlvbiBpcyB1c2VkIGZvciBh ZGRpdGlvbmFsIFdlYlJUQyBkYXRhIHRyYWZmaWM/IC0gQmVjYXVzZTxvOnA+PC9vOnA+PC9zcGFu PjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0 O2ZvbnQtZmFtaWx5OkNvbnNvbGFzO2NvbG9yOiMxRjQ5N0QiPjxhIGhyZWY9Imh0dHBzOi8vdG9v bHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC1pZXRmLXJ0Y3dlYi10cmFuc3BvcnRzLTA5I3NlY3Rpb24t My41Ij5odHRwczovL3Rvb2xzLmlldGYub3JnL2h0bWwvZHJhZnQtaWV0Zi1ydGN3ZWItdHJhbnNw b3J0cy0wOSNzZWN0aW9uLTMuNTwvYT4NCjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OkNv bnNvbGFzO2NvbG9yOiMxRjQ5N0QiPmluZGljYXRlcyB0aGUgc2hhcmluZyBvcHRpb24uPG86cD48 L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQt c2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6Q29uc29sYXM7Y29sb3I6IzFGNDk3RCI+V291bGQgdGhl biBiZSBhIDM8c3VwPnJkPC9zdXA+IChvciA1PHN1cD50aDwvc3VwPikgc2VsZi1jb250YWluZWQg RFRMUyBzZXNzaW9uL0RUTFMgY29ubmVjdGlvbiBmb3IgV2ViUlRDIGRhdGEgdHJhZmZpYz88bzpw PjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9u dC1zaXplOjExLjBwdDtmb250LWZhbWlseTpDb25zb2xhcztjb2xvcjojMUY0OTdEIj48bzpwPiZu YnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0i Zm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTpDb25zb2xhcztjb2xvcjojMUY0OTdEIj5Qcm9w b3NhbDo8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBz dHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTpDb25zb2xhcztjb2xvcjojMUY0OTdE Ij5BZGQgZXhwbGljaXQgdGV4dCB0byBjbGF1c2UNCjxhIGhyZWY9Imh0dHBzOi8vdG9vbHMuaWV0 Zi5vcmcvaHRtbC9kcmFmdC1pZXRmLXJ0Y3dlYi10cmFuc3BvcnRzLTA5I3NlY3Rpb24tMy41Ij4N Cmh0dHBzOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC1pZXRmLXJ0Y3dlYi10cmFuc3BvcnRz LTA5I3NlY3Rpb24tMy41PC9hPiA8bzpwPg0KPC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OkNvbnNv bGFzO2NvbG9yOiMxRjQ5N0QiPmFib3V0IChpbiByZWQpLCBzb21ldGhpbmcgbGlrZTo8bzpwPjwv bzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1z aXplOjExLjBwdDtmb250LWZhbWlseTpDb25zb2xhcztjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNw OzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9u dC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90OyI+Jm5ic3A7 Jm5ic3A7IFdlYlJUQyBpbXBsZW1lbnRhdGlvbnMgTVVTVCBzdXBwb3J0IG11bHRpcGxleGluZyBv ZiBEVExTIGFuZCBSVFAgb3ZlcjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0Nv dXJpZXIgTmV3JnF1b3Q7Ij4mbmJzcDsmbmJzcDsgdGhlIHNhbWUgcG9ydCBwYWlyLCBhcyBkZXNj cmliZWQgaW4gdGhlIERUTFMtU1JUUCBzcGVjaWZpY2F0aW9uPG86cD48L286cD48L3NwYW4+PC9w Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9u dC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDsiPiZuYnNwOyZuYnNwOyA8YSBocmVmPSJo dHRwczovL3Rvb2xzLmlldGYub3JnL2h0bWwvcmZjNTc2NCNzZWN0aW9uLTUuMS4yIj4NCltSRkM1 NzY0XSwgc2VjdGlvbiZuYnNwOzUuMS4yPC9hPi4mbmJzcDsgQWxsIGFwcGxpY2F0aW9uIGxheWVy IHByb3RvY29sIHBheWxvYWRzPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291 cmllciBOZXcmcXVvdDsiPiZuYnNwOyZuYnNwOyBvdmVyIHRoaXMgRFRMUyBjb25uZWN0aW9uIGFy ZSBTQ1RQIHBhY2tldHMuPG86cD48L286cD48L3NwYW4+PC9wPg0KPHByZT48bzpwPiZuYnNwOzwv bzpwPjwvcHJlPg0KPHByZT48c3BhbiBzdHlsZT0iY29sb3I6cmVkIj4mbmJzcDsmbmJzcDsgTm90 ZSAxOiBUaGVyZSB3aWxsIGJlIHR3byBEVExTIHNlc3Npb25zL0RUTFMgY29ubmVjdGlvbnMgd2hl biBSVFAvUlRDUCB0cmFuc3BvcnQgbXVsdGlwbGV4aW5nIGlzIG5vdCBhcHBsaWVkLiBXZWJSVEMg ZGF0YSB0cmFmZmljIGNvdWxkIHN0aWxsIHNoYXJlIG9uZSBvZiB0aGVzZSBEVExTIGNvbm5lY3Rp b25zIOKApiA8c3BhbiBzdHlsZT0iYmFja2dyb3VuZDp5ZWxsb3c7bXNvLWhpZ2hsaWdodDp5ZWxs b3ciPijigJx3aGljaCBvbmU/4oCdKTwvc3Bhbj4g4oCmIG9yIFRoZXJlIHNob3VsZCBiZSB0aGVu IGEgc2VwYXJhdGUsIHNlbGYtY29udGFpbmVkIERUTFMgc2Vzc2lvbi9EVExTIGNvbm5lY3Rpb24g ZXN0YWJsaXNoZWQgZXhjbHVzaXZlbHkgZm9yIFdlYlJUQyBkYXRhLjxvOnA+PC9vOnA+PC9zcGFu PjwvcHJlPg0KPHByZT48c3BhbiBzdHlsZT0iY29sb3I6cmVkIj48bzpwPiZuYnNwOzwvbzpwPjwv c3Bhbj48L3ByZT4NCjxwcmU+PHNwYW4gc3R5bGU9ImNvbG9yOnJlZCI+Jm5ic3A7Jm5ic3A7IE5v dGUgMjogVGhlcmUgYXJlIHNpbWlsYXIgY29uc2lkZXJhdGlvbnMgaW4gY2FzZSBvZiBidW5kbGlu Zy48L3NwYW4+PG86cD48L286cD48L3ByZT4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0 eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7 Ij48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3Bh biBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZx dW90OyI+Jm5ic3A7Jm5ic3A7IFByb3RvY29sIGlkZW50aWZpY2F0aW9uIE1VU1QgYmUgc3VwcGxp ZWQgYXMgcGFydCBvZiB0aGUgRFRMUzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90 O0NvdXJpZXIgTmV3JnF1b3Q7Ij4mbmJzcDsmbmJzcDsgaGFuZHNoYWtlLCBhcyBzcGVjaWZpZWQg aW4gWzxhIGhyZWY9Imh0dHBzOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC1pZXRmLXJ0Y3dl Yi10cmFuc3BvcnRzLTA5I3JlZi1JLUQuaWV0Zi1ydGN3ZWItYWxwbiI+SS1ELmlldGYtcnRjd2Vi LWFscG48L2E+XS48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48 c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTpDb25zb2xhcztjb2xvcjoj MUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTpDb25zb2xhcztjb2xv cjojMUY0OTdEIj5Db21tZW50cz88bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTpDb25zb2xh cztjb2xvcjojMUY0OTdEIj5SZWdhcmRzLDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OkNv bnNvbGFzO2NvbG9yOiMxRjQ5N0QiPkFsYnJlY2h0PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1p bHk6Q29uc29sYXM7Y29sb3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1m YW1pbHk6Q29uc29sYXM7Y29sb3I6IzFGNDk3RCI+UFM8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZh bWlseTpDb25zb2xhcztjb2xvcjojMUY0OTdEIj5Vc2luZyAoRClUTFMgdGVybWlub2xvZ3kgYWNj b3JkaW5nIHRvDQo8YSBocmVmPSJodHRwOi8vdG9vbHMuaWV0Zi5vcmcvaWQvZHJhZnQtZ3ViYWxs YS10bHMtdGVybWlub2xvZ3ktMDEudHh0Ij5odHRwOi8vdG9vbHMuaWV0Zi5vcmcvaWQvZHJhZnQt Z3ViYWxsYS10bHMtdGVybWlub2xvZ3ktMDEudHh0PC9hPg0KPG86cD48L286cD48L3NwYW4+PC9w Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9u dC1mYW1pbHk6Q29uc29sYXM7Y29sb3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+ PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7 Zm9udC1mYW1pbHk6Q29uc29sYXM7Y29sb3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8L286cD48L3Nw YW4+PC9wPg0KPGRpdj4NCjxkaXYgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci10b3A6c29saWQg I0I1QzRERiAxLjBwdDtwYWRkaW5nOjMuMHB0IDBjbSAwY20gMGNtIj4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPjxiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250 LWZhbWlseTomcXVvdDtUYWhvbWEmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+RnJvbTo8 L3NwYW4+PC9iPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250 LWZhbWlseTomcXVvdDtUYWhvbWEmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+IEJlcm5h cmQgQWJvYmEgW21haWx0bzpiZXJuYXJkLmFib2JhQGdtYWlsLmNvbV0NCjxicj4NCjxiPlNlbnQ6 PC9iPiBNaXR0d29jaCwgNS4gQXVndXN0IDIwMTUgMDQ6MDQ8YnI+DQo8Yj5Ubzo8L2I+IFJvbWFu IFNocG91bnQ8YnI+DQo8Yj5DYzo8L2I+IEFzdmVyZW4sIFRvbGdhOyBDaHJpc3RlciBIb2xtYmVy ZzsgRXJpYyBSZXNjb3JsYTsgU2Nod2FyeiwgQWxicmVjaHQgKEFsYnJlY2h0KTsgUmF1c2NoZW5i YWNoLCBVd2UgKE5va2lhIC0gREUvTXVuaWNoKTsgJmx0O3J0Y3dlYkBpZXRmLm9yZyZndDs8YnI+ DQo8Yj5TdWJqZWN0OjwvYj4gUmU6IFtydGN3ZWJdIFdoYXQgdGhlIGdhdGV3YXkgZHJhZnQgc2hv dWxkIHNheSBhYm91dCBtdXgvbm9uLW11eDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0K PC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxkaXY+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5PbiBBdWcgNCwgMjAxNSwgYXQgMTY6MzMsIFJvbWFuIFNo cG91bnQgJmx0OzxhIGhyZWY9Im1haWx0bzpyb21hbkB0ZWx1cml4LmNvbSI+cm9tYW5AdGVsdXJp eC5jb208L2E+Jmd0OyB3cm90ZTo8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGJsb2NrcXVvdGUg c3R5bGU9Im1hcmdpbi10b3A6NS4wcHQ7bWFyZ2luLWJvdHRvbTo1LjBwdCI+DQo8ZGl2Pg0KPGRp dj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48 L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9u dC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9y OmJsYWNrIj5Nb3N0IG9mIHRoZSBwZW9wbGUgaW1wbGVtZW50IHRoaXMgd3JvbmcsIHNpbmNlIHlv dSBuZWVkIHRvIGNyZWF0ZSB0d28gRFRMUyBzZXNzaW9uczogb25lIGZvciBSVFAgYW5kIGFub3Ro ZXIgZm9yIFJUQ1AuIEFuZCB0aGVuIHVzZSBkaWZmZXJlbnQga2V5cyBvciBwb3NzaWJseSBldmVu IGVuY3J5cHRpb24NCiBwcm9maWxlcyBmb3IgUlRQIGFuZCBSVENQLiBJIGNvbW1vbmx5IHNlZSBv bmUgc2Vzc2lvbiBmb3IgUlRQIGFuZCBrZXlzIG5lZ290aWF0ZWQgdGhlcmUgdXNlZCBmb3IgYm90 aCBSVFAgYW5kIFJUQ1AsIHdoaWNoIGlzIHdyb25nLjwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwv ZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9ibG9ja3F1b3RlPg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+W0JBXSBZZXMsIHRoYXQgaXMgb25seSBvbmUgb2Ygc2V2ZXJhbCBjb21tb24gbWlzdGFrZXMu ICZuYnNwO1VuZm9ydHVuYXRlbHksIFJGQyA1NzY0IGRvZXMgbm90IHJ1bGUgb3V0IGFsbCBvZiB0 aGVzZSBhbmQgdGhlIHNlY3VyaXR5IGRvY3VtZW50cyBhcmUgbm90IGNyeXN0YWwgY2xlYXIgb24g aG93IHRoaW5ncyBtdXN0IGJlIGRvbmUuIEl0IGlzIG11Y2ggaGFyZGVyIHRvIG1lc3MgdXAgUlRQ L1JUQ1AgbXV4LiAmbmJzcDtHaXZlbg0KIHdoYXQgSSd2ZSBzZWVuIHNvIGZhciwgbm9uLW11eCBj b3VsZCBiZWNvbWUgYSBzdXBwb3J0IG5pZ2h0bWFyZS4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwv ZGl2Pg0KPC9kaXY+DQo8L2JvZHk+DQo8L2h0bWw+DQo= --_000_786615F3A85DF44AA2A76164A71FE1AC7ADB9197FR711WXCHMBA03z_-- From nobody Wed Aug 5 01:12:42 2015 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D2FAA1B2D50; Wed, 5 Aug 2015 01:12:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.2 X-Spam-Level: X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5_lZoqoYJGOs; Wed, 5 Aug 2015 01:12:38 -0700 (PDT) Received: from sessmg23.ericsson.net (sessmg23.ericsson.net [193.180.251.45]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 45A5F1B2D8E; Wed, 5 Aug 2015 01:12:37 -0700 (PDT) X-AuditID: c1b4fb2d-f79176d00000321c-55-55c1c5730748 Received: from ESESSHC023.ericsson.se (Unknown_Domain [153.88.253.124]) by sessmg23.ericsson.net (Symantec Mail Security) with SMTP id B1.40.12828.375C1C55; Wed, 5 Aug 2015 10:12:35 +0200 (CEST) Received: from ESESSMB209.ericsson.se ([169.254.9.36]) by ESESSHC023.ericsson.se ([153.88.183.87]) with mapi id 14.03.0210.002; Wed, 5 Aug 2015 10:12:34 +0200 From: Christer Holmberg To: "Schwarz, Albrecht (Albrecht)" , "" Thread-Topic: [rtcweb] Number of DTLS sessions/DTLS connections; RE: What the gateway draft should say about mux/non-mux Thread-Index: AQHQz1VVWzrNLwNmjUSvQIGN1uVQpZ39Df+g Date: Wed, 5 Aug 2015 08:12:34 +0000 Message-ID: <7594FB04B1934943A5C02806D1A2204B348E8E9F@ESESSMB209.ericsson.se> References: <7594FB04B1934943A5C02806D1A2204B348E82CA@ESESSMB209.ericsson.se> <05B3C43B-2823-4590-889E-7A192FC8A3AD@gmail.com> <786615F3A85DF44AA2A76164A71FE1AC7ADB9197@FR711WXCHMBA03.zeu.alcatel-lucent.com> In-Reply-To: <786615F3A85DF44AA2A76164A71FE1AC7ADB9197@FR711WXCHMBA03.zeu.alcatel-lucent.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [153.88.183.16] Content-Type: multipart/alternative; boundary="_000_7594FB04B1934943A5C02806D1A2204B348E8E9FESESSMB209erics_" MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFuphkeLIzCtJLcpLzFFi42KZGfG3Rrf46MFQg32zhCz+tP5itFj7r53d 4tP5LkYHZo/WZ3tZPZYs+ckUwBTFZZOSmpNZllqkb5fAlfHk9yTWgnmXGSvOHT/C1MB45Sxj FyMnh4SAicT8dV/YIWwxiQv31rN1MXJxCAkcZZRY3bWYFcJZxCjxaO0DoCoODjYBC4nuf9og DSIChRKPG7+DDWIWMJD4e+I6mC0sUCVxcN59VoiaaokHp66zQ9hGEp3PP4LFWQRUJJb9uscC YvMK+Eo0/2pngdh1glmic/88sCJOgViJp7/PMYPYjEDXfT+1hglimbjErSfzmSCuFpBYsuc8 M4QtKvHy8T9WCFtRYufZdmaI+nyJSxOeMEEsE5Q4OfMJywRG0VlIRs1CUjYLSdksoJeZBTQl 1u/ShyhRlJjS/ZAdwtaQaJ0zlx1ZfAEj+ypG0eLU4uLcdCNjvdSizOTi4vw8vbzUkk2MwOg7 uOW37g7G1a8dDzEKcDAq8fAq5B0MFWJNLCuuzD3EKM3BoiTOO2NzXqiQQHpiSWp2ampBalF8 UWlOavEhRiYOTqkGxu62y4XrW0u56ub0XHxxhfk17zH7T+u2zN5bYW5n+zDwwxNLP4mpyVwn Poe2Ve0tEjv/yvzzj3VL/AWt5hue9flqnLOqUFzzevvbH4oKDfNEY052fj51bfN5rgmSP+K2 Klm7nBKY+PNZxaRdO0/dEHjF9HnpjNMxztJnbMWv7ezPKtu8jLtK4LASS3FGoqEWc1FxIgA8 UH6XnwIAAA== Archived-At: Cc: "TLS@ietf.org \(tls@ietf.org\)" Subject: Re: [rtcweb] Number of DTLS sessions/DTLS connections; RE: What the gateway draft should say about mux/non-mux X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 05 Aug 2015 08:12:41 -0000 --_000_7594FB04B1934943A5C02806D1A2204B348E8E9FESESSMB209erics_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SGksDQoNCldlIHNoYWxsIG5vdCBtYWtlIFJGQyA1NzY0IGNvcnJlY3Rpb25zIGluIHRoZSBSVENX RUIgc3BlY3MuDQoNClJlZ2FyZHMsDQoNCkNocmlzdGVyDQoNCg0KDQpGcm9tOiBydGN3ZWIgW21h aWx0bzpydGN3ZWItYm91bmNlc0BpZXRmLm9yZ10gT24gQmVoYWxmIE9mIFNjaHdhcnosIEFsYnJl Y2h0IChBbGJyZWNodCkNClNlbnQ6IDUuIGVsb2t1dXRhIDIwMTUgMTE6MDQNClRvOiA8cnRjd2Vi QGlldGYub3JnPg0KQ2M6IFRMU0BpZXRmLm9yZyAodGxzQGlldGYub3JnKQ0KU3ViamVjdDogW3J0 Y3dlYl0gTnVtYmVyIG9mIERUTFMgc2Vzc2lvbnMvRFRMUyBjb25uZWN0aW9uczsgUkU6IFdoYXQg dGhlIGdhdGV3YXkgZHJhZnQgc2hvdWxkIHNheSBhYm91dCBtdXgvbm9uLW11eA0KDQpSb21hbiwg QmVybmFyZCwNCnJpZ2h0LCBSRkMgNTc2NCBpcyB0b28gdmFndWUgb24gdGhhdCBhc3BlY3QuIFRo YW5rcyBmb3IgY29uZmlybWluZyB0aGUgbnVtYmVyIG9mIERUTFMgc2Vzc2lvbnMsIHdoaWNoIGlz IGlubGluZSB3aXRoIG91ciB1bmRlcnN0YW5kaW5nLg0KV291bGQgYXBwcmVjaWF0ZSBpZiB0aGlz IGNvdWxkIGJlIHNvbWV3aGVyZSBmaXhlZCBpbiBhbiBydGN3ZWIgZHJhZnQgZHVlIHRvIHNpZ25p ZmljYW50IHNpZGUgZWZmZWN0cy4NClRoaXMgdG9waWMgaXMgYWxzbyBhbiBvbmdvaW5nIEZBUS4N Cg0KVGhlIG1vc3Qgc2ltcGxlIGNhc2UgaXMgZ2l2ZW4gYnkgYSBzY2VuYXJpbyB3aXRoIHVzYWdl IG9mIGJ1bmRsaW5nIHBsdXMgdXNhZ2Ugb2YgUlRQL1JUQ1AgdHJhbnNwb3J0IG11bHRpcGxleGlu ZywgbGVhZGluZyB0byBhIHNpbmdsZSBEVExTIHNlc3Npb24vRFRMUyBjb25uZWN0aW9uLCB3aGlj aCBjb3VsZCBiZSB0aGVuIGFsc28gc2hhcmVkIGZvciBXZWJSVEMgZGF0YS4NCg0KQm90aCBjYXBh YmlsaXRpZXMgYXJlIG1hbmRhdGVkIGluIHRoZSBydHAgdXNhZ2UgZHJhZnQ6DQpodHRwczovL3Rv b2xzLmlldGYub3JnL2h0bWwvZHJhZnQtaWV0Zi1ydGN3ZWItcnRwLXVzYWdlLTI1I3NlY3Rpb24t NC40DQo9PiBidW5kbGluZw0KaHR0cHM6Ly90b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0LWlldGYt cnRjd2ViLXJ0cC11c2FnZS0yNSNzZWN0aW9uLTQuNQ0KPT4gUlRQL1JUQ1AgdHJhbnNwb3J0IG11 bHRpcGxleGluZw0KDQpOb3csIElGIGJ1bmRsaW5nIGlzIG5vdCB1c2VkIE9SIFJUUC9SVENQIHRy YW5zcG9ydCBtdWx0aXBsZXhpbmcgaXMgbm90IHVzZWQgVEhFTiB0aGVyZSB3aWxsIGJlIG1vcmUg dGhhbiBvbmUgRFRMUyBzZXNzaW9uL0RUTFMgY29ubmVjdGlvbiAoZWl0aGVyIDIgb3IgNCBpbiBj YXNlIG9mIGF1ZGlvICYgdmlkZW8pLg0KUmFpc2luZyB0aGUgcXVlc3Rpb24gd2hpY2ggRFRMUyBj b25uZWN0aW9uIGlzIHVzZWQgZm9yIGFkZGl0aW9uYWwgV2ViUlRDIGRhdGEgdHJhZmZpYz8gLSBC ZWNhdXNlDQpodHRwczovL3Rvb2xzLmlldGYub3JnL2h0bWwvZHJhZnQtaWV0Zi1ydGN3ZWItdHJh bnNwb3J0cy0wOSNzZWN0aW9uLTMuNQ0KaW5kaWNhdGVzIHRoZSBzaGFyaW5nIG9wdGlvbi4NCldv dWxkIHRoZW4gYmUgYSAzcmQgKG9yIDV0aCkgc2VsZi1jb250YWluZWQgRFRMUyBzZXNzaW9uL0RU TFMgY29ubmVjdGlvbiBmb3IgV2ViUlRDIGRhdGEgdHJhZmZpYz8NCg0KUHJvcG9zYWw6DQpBZGQg ZXhwbGljaXQgdGV4dCB0byBjbGF1c2UgaHR0cHM6Ly90b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0 LWlldGYtcnRjd2ViLXRyYW5zcG9ydHMtMDkjc2VjdGlvbi0zLjUNCmFib3V0IChpbiByZWQpLCBz b21ldGhpbmcgbGlrZToNCg0KICAgV2ViUlRDIGltcGxlbWVudGF0aW9ucyBNVVNUIHN1cHBvcnQg bXVsdGlwbGV4aW5nIG9mIERUTFMgYW5kIFJUUCBvdmVyDQogICB0aGUgc2FtZSBwb3J0IHBhaXIs IGFzIGRlc2NyaWJlZCBpbiB0aGUgRFRMUy1TUlRQIHNwZWNpZmljYXRpb24NCiAgIFtSRkM1NzY0 XSwgc2VjdGlvbiA1LjEuMjxodHRwczovL3Rvb2xzLmlldGYub3JnL2h0bWwvcmZjNTc2NCNzZWN0 aW9uLTUuMS4yPi4gIEFsbCBhcHBsaWNhdGlvbiBsYXllciBwcm90b2NvbCBwYXlsb2Fkcw0KICAg b3ZlciB0aGlzIERUTFMgY29ubmVjdGlvbiBhcmUgU0NUUCBwYWNrZXRzLg0KDQoNCg0KICAgTm90 ZSAxOiBUaGVyZSB3aWxsIGJlIHR3byBEVExTIHNlc3Npb25zL0RUTFMgY29ubmVjdGlvbnMgd2hl biBSVFAvUlRDUCB0cmFuc3BvcnQgbXVsdGlwbGV4aW5nIGlzIG5vdCBhcHBsaWVkLiBXZWJSVEMg ZGF0YSB0cmFmZmljIGNvdWxkIHN0aWxsIHNoYXJlIG9uZSBvZiB0aGVzZSBEVExTIGNvbm5lY3Rp b25zIOKApiAo4oCcd2hpY2ggb25lP+KAnSkg4oCmIG9yIFRoZXJlIHNob3VsZCBiZSB0aGVuIGEg c2VwYXJhdGUsIHNlbGYtY29udGFpbmVkIERUTFMgc2Vzc2lvbi9EVExTIGNvbm5lY3Rpb24gZXN0 YWJsaXNoZWQgZXhjbHVzaXZlbHkgZm9yIFdlYlJUQyBkYXRhLg0KDQoNCg0KICAgTm90ZSAyOiBU aGVyZSBhcmUgc2ltaWxhciBjb25zaWRlcmF0aW9ucyBpbiBjYXNlIG9mIGJ1bmRsaW5nLg0KDQog ICBQcm90b2NvbCBpZGVudGlmaWNhdGlvbiBNVVNUIGJlIHN1cHBsaWVkIGFzIHBhcnQgb2YgdGhl IERUTFMNCiAgIGhhbmRzaGFrZSwgYXMgc3BlY2lmaWVkIGluIFtJLUQuaWV0Zi1ydGN3ZWItYWxw bjxodHRwczovL3Rvb2xzLmlldGYub3JnL2h0bWwvZHJhZnQtaWV0Zi1ydGN3ZWItdHJhbnNwb3J0 cy0wOSNyZWYtSS1ELmlldGYtcnRjd2ViLWFscG4+XS4NCg0KQ29tbWVudHM/DQpSZWdhcmRzLA0K QWxicmVjaHQNCg0KUFMNClVzaW5nIChEKVRMUyB0ZXJtaW5vbG9neSBhY2NvcmRpbmcgdG8gaHR0 cDovL3Rvb2xzLmlldGYub3JnL2lkL2RyYWZ0LWd1YmFsbGEtdGxzLXRlcm1pbm9sb2d5LTAxLnR4 dA0KDQoNCkZyb206IEJlcm5hcmQgQWJvYmEgW21haWx0bzpiZXJuYXJkLmFib2JhQGdtYWlsLmNv bV0NClNlbnQ6IE1pdHR3b2NoLCA1LiBBdWd1c3QgMjAxNSAwNDowNA0KVG86IFJvbWFuIFNocG91 bnQNCkNjOiBBc3ZlcmVuLCBUb2xnYTsgQ2hyaXN0ZXIgSG9sbWJlcmc7IEVyaWMgUmVzY29ybGE7 IFNjaHdhcnosIEFsYnJlY2h0IChBbGJyZWNodCk7IFJhdXNjaGVuYmFjaCwgVXdlIChOb2tpYSAt IERFL011bmljaCk7IDxydGN3ZWJAaWV0Zi5vcmc8bWFpbHRvOnJ0Y3dlYkBpZXRmLm9yZz4+DQpT dWJqZWN0OiBSZTogW3J0Y3dlYl0gV2hhdCB0aGUgZ2F0ZXdheSBkcmFmdCBzaG91bGQgc2F5IGFi b3V0IG11eC9ub24tbXV4DQoNCk9uIEF1ZyA0LCAyMDE1LCBhdCAxNjozMywgUm9tYW4gU2hwb3Vu dCA8cm9tYW5AdGVsdXJpeC5jb208bWFpbHRvOnJvbWFuQHRlbHVyaXguY29tPj4gd3JvdGU6DQoN Ck1vc3Qgb2YgdGhlIHBlb3BsZSBpbXBsZW1lbnQgdGhpcyB3cm9uZywgc2luY2UgeW91IG5lZWQg dG8gY3JlYXRlIHR3byBEVExTIHNlc3Npb25zOiBvbmUgZm9yIFJUUCBhbmQgYW5vdGhlciBmb3Ig UlRDUC4gQW5kIHRoZW4gdXNlIGRpZmZlcmVudCBrZXlzIG9yIHBvc3NpYmx5IGV2ZW4gZW5jcnlw dGlvbiBwcm9maWxlcyBmb3IgUlRQIGFuZCBSVENQLiBJIGNvbW1vbmx5IHNlZSBvbmUgc2Vzc2lv biBmb3IgUlRQIGFuZCBrZXlzIG5lZ290aWF0ZWQgdGhlcmUgdXNlZCBmb3IgYm90aCBSVFAgYW5k IFJUQ1AsIHdoaWNoIGlzIHdyb25nLg0KDQpbQkFdIFllcywgdGhhdCBpcyBvbmx5IG9uZSBvZiBz ZXZlcmFsIGNvbW1vbiBtaXN0YWtlcy4gIFVuZm9ydHVuYXRlbHksIFJGQyA1NzY0IGRvZXMgbm90 IHJ1bGUgb3V0IGFsbCBvZiB0aGVzZSBhbmQgdGhlIHNlY3VyaXR5IGRvY3VtZW50cyBhcmUgbm90 IGNyeXN0YWwgY2xlYXIgb24gaG93IHRoaW5ncyBtdXN0IGJlIGRvbmUuIEl0IGlzIG11Y2ggaGFy ZGVyIHRvIG1lc3MgdXAgUlRQL1JUQ1AgbXV4LiAgR2l2ZW4gd2hhdCBJJ3ZlIHNlZW4gc28gZmFy LCBub24tbXV4IGNvdWxkIGJlY29tZSBhIHN1cHBvcnQgbmlnaHRtYXJlLg0K --_000_7594FB04B1934943A5C02806D1A2204B348E8E9FESESSMB209erics_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTQgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 Q2FsaWJyaTsNCglwYW5vc2UtMToyIDE1IDUgMiAyIDIgNCAzIDIgNDt9DQpAZm9udC1mYWNlDQoJ e2ZvbnQtZmFtaWx5OlRhaG9tYTsNCglwYW5vc2UtMToyIDExIDYgNCAzIDUgNCA0IDIgNDt9DQpA Zm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OkNvbnNvbGFzOw0KCXBhbm9zZS0xOjIgMTEgNiA5IDIg MiA0IDMgMiA0O30NCi8qIFN0eWxlIERlZmluaXRpb25zICovDQpwLk1zb05vcm1hbCwgbGkuTXNv Tm9ybWFsLCBkaXYuTXNvTm9ybWFsDQoJe21hcmdpbjowY207DQoJbWFyZ2luLWJvdHRvbTouMDAw MXB0Ow0KCWZvbnQtc2l6ZToxMi4wcHQ7DQoJZm9udC1mYW1pbHk6IlRpbWVzIE5ldyBSb21hbiIs InNlcmlmIjt9DQphOmxpbmssIHNwYW4uTXNvSHlwZXJsaW5rDQoJe21zby1zdHlsZS1wcmlvcml0 eTo5OTsNCgljb2xvcjpibHVlOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0KYTp2aXNp dGVkLCBzcGFuLk1zb0h5cGVybGlua0ZvbGxvd2VkDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsN Cgljb2xvcjpwdXJwbGU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQpwcmUNCgl7bXNv LXN0eWxlLXByaW9yaXR5Ojk5Ow0KCW1zby1zdHlsZS1saW5rOiJIVE1MIFByZWZvcm1hdHRlZCBD aGFyIjsNCgltYXJnaW46MGNtOw0KCW1hcmdpbi1ib3R0b206LjAwMDFwdDsNCglmb250LXNpemU6 MTAuMHB0Ow0KCWZvbnQtZmFtaWx5OiJDb3VyaWVyIE5ldyI7fQ0KcC5Nc29BY2V0YXRlLCBsaS5N c29BY2V0YXRlLCBkaXYuTXNvQWNldGF0ZQ0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJbXNv LXN0eWxlLWxpbms6IkJhbGxvb24gVGV4dCBDaGFyIjsNCgltYXJnaW46MGNtOw0KCW1hcmdpbi1i b3R0b206LjAwMDFwdDsNCglmb250LXNpemU6OC4wcHQ7DQoJZm9udC1mYW1pbHk6IlRhaG9tYSIs InNhbnMtc2VyaWYiO30NCnAuTXNvTGlzdFBhcmFncmFwaCwgbGkuTXNvTGlzdFBhcmFncmFwaCwg ZGl2Lk1zb0xpc3RQYXJhZ3JhcGgNCgl7bXNvLXN0eWxlLXByaW9yaXR5OjM0Ow0KCW1hcmdpbi10 b3A6MGNtOw0KCW1hcmdpbi1yaWdodDowY207DQoJbWFyZ2luLWJvdHRvbTowY207DQoJbWFyZ2lu LWxlZnQ6MzYuMHB0Ow0KCW1hcmdpbi1ib3R0b206LjAwMDFwdDsNCglmb250LXNpemU6MTIuMHB0 Ow0KCWZvbnQtZmFtaWx5OiJUaW1lcyBOZXcgUm9tYW4iLCJzZXJpZiI7fQ0Kc3Bhbi5IVE1MUHJl Zm9ybWF0dGVkQ2hhcg0KCXttc28tc3R5bGUtbmFtZToiSFRNTCBQcmVmb3JtYXR0ZWQgQ2hhciI7 DQoJbXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCW1zby1zdHlsZS1saW5rOiJIVE1MIFByZWZvcm1h dHRlZCI7DQoJZm9udC1mYW1pbHk6IkNvdXJpZXIgTmV3Ijt9DQpzcGFuLkVtYWlsU3R5bGUyMA0K CXttc28tc3R5bGUtdHlwZTpwZXJzb25hbDsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsInNhbnMt c2VyaWYiOw0KCWNvbG9yOiMxRjQ5N0Q7fQ0Kc3Bhbi5FbWFpbFN0eWxlMjENCgl7bXNvLXN0eWxl LXR5cGU6cGVyc29uYWwtcmVwbHk7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLCJzYW5zLXNlcmlm IjsNCgljb2xvcjojMUY0OTdEO30NCnNwYW4uQmFsbG9vblRleHRDaGFyDQoJe21zby1zdHlsZS1u YW1lOiJCYWxsb29uIFRleHQgQ2hhciI7DQoJbXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCW1zby1z dHlsZS1saW5rOiJCYWxsb29uIFRleHQiOw0KCWZvbnQtZmFtaWx5OiJUYWhvbWEiLCJzYW5zLXNl cmlmIjt9DQouTXNvQ2hwRGVmYXVsdA0KCXttc28tc3R5bGUtdHlwZTpleHBvcnQtb25seTsNCglm b250LXNpemU6MTAuMHB0O30NCkBwYWdlIFdvcmRTZWN0aW9uMQ0KCXtzaXplOjYxMi4wcHQgNzky LjBwdDsNCgltYXJnaW46NzIuMHB0IDcyLjBwdCA3Mi4wcHQgNzIuMHB0O30NCmRpdi5Xb3JkU2Vj dGlvbjENCgl7cGFnZTpXb3JkU2VjdGlvbjE7fQ0KLS0+PC9zdHlsZT48IS0tW2lmIGd0ZSBtc28g OV0+PHhtbD4NCjxvOnNoYXBlZGVmYXVsdHMgdjpleHQ9ImVkaXQiIHNwaWRtYXg9IjEwMjYiIC8+ DQo8L3htbD48IVtlbmRpZl0tLT48IS0tW2lmIGd0ZSBtc28gOV0+PHhtbD4NCjxvOnNoYXBlbGF5 b3V0IHY6ZXh0PSJlZGl0Ij4NCjxvOmlkbWFwIHY6ZXh0PSJlZGl0IiBkYXRhPSIxIiAvPg0KPC9v OnNoYXBlbGF5b3V0PjwveG1sPjwhW2VuZGlmXS0tPg0KPC9oZWFkPg0KPGJvZHkgbGFuZz0iRkki IGxpbms9ImJsdWUiIHZsaW5rPSJwdXJwbGUiPg0KPGRpdiBjbGFzcz0iV29yZFNlY3Rpb24xIj4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQt ZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjoj MUY0OTdEIj5IaSw8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48 c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1 b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8L286 cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0 eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1 b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj5XZSBzaGFsbCBub3QgbWFrZSBSRkMg NTc2NCBjb3JyZWN0aW9ucyBpbiB0aGUgUlRDV0VCIHNwZWNzLjxvOnA+PC9vOnA+PC9zcGFuPjwv cD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1z aXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2Vy aWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTEu MHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90 Oztjb2xvcjojMUY0OTdEIj5SZWdhcmRzLDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtm b250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29s b3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFt aWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0 OTdEIj5DaHJpc3RlcjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTom cXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+ PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4g bGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0Nh bGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj48bzpwPiZu YnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJF Ti1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZx dW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9v OnA+PC9zcGFuPjwvcD4NCjxkaXY+DQo8ZGl2IHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItdG9w OnNvbGlkICNCNUM0REYgMS4wcHQ7cGFkZGluZzozLjBwdCAwY20gMGNtIDBjbSI+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj48Yj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC4w cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7VGFob21hJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsi PkZyb206PC9zcGFuPjwvYj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC4w cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7VGFob21hJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsi PiBydGN3ZWIgW21haWx0bzpydGN3ZWItYm91bmNlc0BpZXRmLm9yZ10NCjxiPk9uIEJlaGFsZiBP ZiA8L2I+U2Nod2FyeiwgQWxicmVjaHQgKEFsYnJlY2h0KTxicj4NCjxiPlNlbnQ6PC9iPiA1LiBl bG9rdXV0YSAyMDE1IDExOjA0PGJyPg0KPGI+VG86PC9iPiAmbHQ7cnRjd2ViQGlldGYub3JnJmd0 Ozxicj4NCjxiPkNjOjwvYj4gVExTQGlldGYub3JnICh0bHNAaWV0Zi5vcmcpPGJyPg0KPGI+U3Vi amVjdDo8L2I+IFtydGN3ZWJdIE51bWJlciBvZiBEVExTIHNlc3Npb25zL0RUTFMgY29ubmVjdGlv bnM7IFJFOiBXaGF0IHRoZSBnYXRld2F5IGRyYWZ0IHNob3VsZCBzYXkgYWJvdXQgbXV4L25vbi1t dXg8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBs YW5nPSJFTi1HQiIgc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6Q29uc29sYXM7 Y29sb3I6IzFGNDk3RCI+Um9tYW4sIEJlcm5hcmQsPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tR0IiIHN0eWxlPSJmb250LXNpemU6MTEu MHB0O2ZvbnQtZmFtaWx5OkNvbnNvbGFzO2NvbG9yOiMxRjQ5N0QiPnJpZ2h0LCBSRkMgNTc2NCBp cyB0b28gdmFndWUgb24gdGhhdCBhc3BlY3QuIFRoYW5rcyBmb3IgY29uZmlybWluZyB0aGUgbnVt YmVyIG9mIERUTFMgc2Vzc2lvbnMsIHdoaWNoIGlzIGlubGluZSB3aXRoIG91ciB1bmRlcnN0YW5k aW5nLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxh bmc9IkVOLUdCIiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTpDb25zb2xhcztj b2xvcjojMUY0OTdEIj5Xb3VsZCBhcHByZWNpYXRlIGlmIHRoaXMgY291bGQgYmUgc29tZXdoZXJl IGZpeGVkIGluIGFuIHJ0Y3dlYiBkcmFmdCBkdWUgdG8gc2lnbmlmaWNhbnQgc2lkZSBlZmZlY3Rz LjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9 IkVOLUdCIiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTpDb25zb2xhcztjb2xv cjojMUY0OTdEIj5UaGlzIHRvcGljIGlzIGFsc28gYW4gb25nb2luZyBGQVEuPG86cD48L286cD48 L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tR0IiIHN0eWxl PSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OkNvbnNvbGFzO2NvbG9yOiMxRjQ5N0QiPjxv OnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxh bmc9IkVOLUdCIiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTpDb25zb2xhcztj b2xvcjojMUY0OTdEIj5UaGUgbW9zdCBzaW1wbGUgY2FzZSBpcyBnaXZlbiBieSBhIHNjZW5hcmlv IHdpdGggdXNhZ2Ugb2YgYnVuZGxpbmcgcGx1cyB1c2FnZSBvZiBSVFAvUlRDUCB0cmFuc3BvcnQg bXVsdGlwbGV4aW5nLCBsZWFkaW5nIHRvIGEgc2luZ2xlIERUTFMgc2Vzc2lvbi9EVExTIGNvbm5l Y3Rpb24sDQogd2hpY2ggY291bGQgYmUgdGhlbiBhbHNvIHNoYXJlZCBmb3IgV2ViUlRDIGRhdGEu PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0i RU4tR0IiIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OkNvbnNvbGFzO2NvbG9y OiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPjxzcGFuIGxhbmc9IkVOLUdCIiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWls eTpDb25zb2xhcztjb2xvcjojMUY0OTdEIj5Cb3RoIGNhcGFiaWxpdGllcyBhcmUgbWFuZGF0ZWQg aW4gdGhlIHJ0cCB1c2FnZSBkcmFmdDo8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1HQiIgc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9u dC1mYW1pbHk6Q29uc29sYXM7Y29sb3I6IzFGNDk3RCI+PGEgaHJlZj0iaHR0cHM6Ly90b29scy5p ZXRmLm9yZy9odG1sL2RyYWZ0LWlldGYtcnRjd2ViLXJ0cC11c2FnZS0yNSNzZWN0aW9uLTQuNCI+ PHNwYW4gbGFuZz0iREUiPmh0dHBzOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC1pZXRmLXJ0 Y3dlYi1ydHAtdXNhZ2UtMjUjc2VjdGlvbi00LjQ8L3NwYW4+PC9hPg0KPC9zcGFuPjxzcGFuIGxh bmc9IkRFIiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTpDb25zb2xhcztjb2xv cjojMUY0OTdEIj48YnI+DQo9Jmd0OyBidW5kbGluZzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLUdCIiBzdHlsZT0iZm9udC1zaXplOjEx LjBwdDtmb250LWZhbWlseTpDb25zb2xhcztjb2xvcjojMUY0OTdEIj48YSBocmVmPSJodHRwczov L3Rvb2xzLmlldGYub3JnL2h0bWwvZHJhZnQtaWV0Zi1ydGN3ZWItcnRwLXVzYWdlLTI1I3NlY3Rp b24tNC41Ij5odHRwczovL3Rvb2xzLmlldGYub3JnL2h0bWwvZHJhZnQtaWV0Zi1ydGN3ZWItcnRw LXVzYWdlLTI1I3NlY3Rpb24tNC41PC9hPg0KPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tR0IiIHN0eWxlPSJmb250LXNpemU6MTEuMHB0 O2ZvbnQtZmFtaWx5OkNvbnNvbGFzO2NvbG9yOiMxRjQ5N0QiPj0mZ3Q7IFJUUC9SVENQIHRyYW5z cG9ydCBtdWx0aXBsZXhpbmc8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj48c3BhbiBsYW5nPSJFTi1HQiIgc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1p bHk6Q29uc29sYXM7Y29sb3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tR0IiIHN0eWxlPSJmb250LXNpemU6 MTEuMHB0O2ZvbnQtZmFtaWx5OkNvbnNvbGFzO2NvbG9yOiMxRjQ5N0QiPk5vdywgSUYgYnVuZGxp bmcgaXMgbm90IHVzZWQgT1IgUlRQL1JUQ1AgdHJhbnNwb3J0IG11bHRpcGxleGluZyBpcyBub3Qg dXNlZCBUSEVOIHRoZXJlIHdpbGwgYmUgbW9yZSB0aGFuIG9uZSBEVExTIHNlc3Npb24vRFRMUyBj b25uZWN0aW9uIChlaXRoZXIgMiBvciA0IGluIGNhc2UNCiBvZiBhdWRpbyAmYW1wOyB2aWRlbyku PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0i RU4tR0IiIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OkNvbnNvbGFzO2NvbG9y OiMxRjQ5N0QiPlJhaXNpbmcgdGhlIHF1ZXN0aW9uIHdoaWNoIERUTFMgY29ubmVjdGlvbiBpcyB1 c2VkIGZvciBhZGRpdGlvbmFsIFdlYlJUQyBkYXRhIHRyYWZmaWM/IC0gQmVjYXVzZTxvOnA+PC9v OnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLUdCIiBz dHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTpDb25zb2xhcztjb2xvcjojMUY0OTdE Ij48YSBocmVmPSJodHRwczovL3Rvb2xzLmlldGYub3JnL2h0bWwvZHJhZnQtaWV0Zi1ydGN3ZWIt dHJhbnNwb3J0cy0wOSNzZWN0aW9uLTMuNSI+aHR0cHM6Ly90b29scy5pZXRmLm9yZy9odG1sL2Ry YWZ0LWlldGYtcnRjd2ViLXRyYW5zcG9ydHMtMDkjc2VjdGlvbi0zLjU8L2E+DQo8bzpwPjwvbzpw Pjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1HQiIgc3R5 bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6Q29uc29sYXM7Y29sb3I6IzFGNDk3RCI+ aW5kaWNhdGVzIHRoZSBzaGFyaW5nIG9wdGlvbi48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1HQiIgc3R5bGU9ImZvbnQtc2l6ZToxMS4w cHQ7Zm9udC1mYW1pbHk6Q29uc29sYXM7Y29sb3I6IzFGNDk3RCI+V291bGQgdGhlbiBiZSBhIDM8 c3VwPnJkPC9zdXA+IChvciA1PHN1cD50aDwvc3VwPikgc2VsZi1jb250YWluZWQgRFRMUyBzZXNz aW9uL0RUTFMgY29ubmVjdGlvbiBmb3IgV2ViUlRDIGRhdGEgdHJhZmZpYz88bzpwPjwvbzpwPjwv c3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1HQiIgc3R5bGU9 ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6Q29uc29sYXM7Y29sb3I6IzFGNDk3RCI+PG86 cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFu Zz0iRU4tR0IiIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OkNvbnNvbGFzO2Nv bG9yOiMxRjQ5N0QiPlByb3Bvc2FsOjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLUdCIiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250 LWZhbWlseTpDb25zb2xhcztjb2xvcjojMUY0OTdEIj5BZGQgZXhwbGljaXQgdGV4dCB0byBjbGF1 c2UNCjxhIGhyZWY9Imh0dHBzOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC1pZXRmLXJ0Y3dl Yi10cmFuc3BvcnRzLTA5I3NlY3Rpb24tMy41Ij4NCmh0dHBzOi8vdG9vbHMuaWV0Zi5vcmcvaHRt bC9kcmFmdC1pZXRmLXJ0Y3dlYi10cmFuc3BvcnRzLTA5I3NlY3Rpb24tMy41PC9hPiA8bzpwPg0K PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLUdC IiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTpDb25zb2xhcztjb2xvcjojMUY0 OTdEIj5hYm91dCAoaW4gcmVkKSwgc29tZXRoaW5nIGxpa2U6PG86cD48L286cD48L3NwYW4+PC9w Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tR0IiIHN0eWxlPSJmb250LXNp emU6MTEuMHB0O2ZvbnQtZmFtaWx5OkNvbnNvbGFzO2NvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7 PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLUdC IiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZx dW90OyI+Jm5ic3A7Jm5ic3A7IFdlYlJUQyBpbXBsZW1lbnRhdGlvbnMgTVVTVCBzdXBwb3J0IG11 bHRpcGxleGluZyBvZiBEVExTIGFuZCBSVFAgb3ZlcjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLUdCIiBzdHlsZT0iZm9udC1zaXplOjEw LjBwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90OyI+Jm5ic3A7Jm5ic3A7IHRo ZSBzYW1lIHBvcnQgcGFpciwgYXMgZGVzY3JpYmVkIGluIHRoZSBEVExTLVNSVFAgc3BlY2lmaWNh dGlvbjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxh bmc9IkVOLUdCIiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtDb3Vy aWVyIE5ldyZxdW90OyI+Jm5ic3A7Jm5ic3A7DQo8YSBocmVmPSJodHRwczovL3Rvb2xzLmlldGYu b3JnL2h0bWwvcmZjNTc2NCNzZWN0aW9uLTUuMS4yIj5bUkZDNTc2NF0sIHNlY3Rpb24mbmJzcDs1 LjEuMjwvYT4uJm5ic3A7IEFsbCBhcHBsaWNhdGlvbiBsYXllciBwcm90b2NvbCBwYXlsb2Fkczxv OnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVO LUdCIiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5l dyZxdW90OyI+Jm5ic3A7Jm5ic3A7IG92ZXIgdGhpcyBEVExTIGNvbm5lY3Rpb24gYXJlIFNDVFAg cGFja2V0cy48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cHJlPjxzcGFuIGxhbmc9IkVOLUdCIj48 bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3ByZT4NCjxwcmU+PHNwYW4gbGFuZz0iRU4tR0IiIHN0 eWxlPSJjb2xvcjpyZWQiPiZuYnNwOyZuYnNwOyBOb3RlIDE6IFRoZXJlIHdpbGwgYmUgdHdvIERU TFMgc2Vzc2lvbnMvRFRMUyBjb25uZWN0aW9ucyB3aGVuIFJUUC9SVENQIHRyYW5zcG9ydCBtdWx0 aXBsZXhpbmcgaXMgbm90IGFwcGxpZWQuIFdlYlJUQyBkYXRhIHRyYWZmaWMgY291bGQgc3RpbGwg c2hhcmUgb25lIG9mIHRoZXNlIERUTFMgY29ubmVjdGlvbnMg4oCmIDxzcGFuIHN0eWxlPSJiYWNr Z3JvdW5kOnllbGxvdzttc28taGlnaGxpZ2h0OnllbGxvdyI+KOKAnHdoaWNoIG9uZT/igJ0pPC9z cGFuPiDigKYgb3IgVGhlcmUgc2hvdWxkIGJlIHRoZW4gYSBzZXBhcmF0ZSwgc2VsZi1jb250YWlu ZWQgRFRMUyBzZXNzaW9uL0RUTFMgY29ubmVjdGlvbiBlc3RhYmxpc2hlZCBleGNsdXNpdmVseSBm b3IgV2ViUlRDIGRhdGEuPG86cD48L286cD48L3NwYW4+PC9wcmU+DQo8cHJlPjxzcGFuIGxhbmc9 IkVOLUdCIiBzdHlsZT0iY29sb3I6cmVkIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3ByZT4N CjxwcmU+PHNwYW4gbGFuZz0iRU4tR0IiIHN0eWxlPSJjb2xvcjpyZWQiPiZuYnNwOyZuYnNwOyBO b3RlIDI6IFRoZXJlIGFyZSBzaW1pbGFyIGNvbnNpZGVyYXRpb25zIGluIGNhc2Ugb2YgYnVuZGxp bmcuPC9zcGFuPjxzcGFuIGxhbmc9IkVOLUdCIj48bzpwPjwvbzpwPjwvc3Bhbj48L3ByZT4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLUdCIiBzdHlsZT0iZm9udC1zaXplOjEw LjBwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90OyI+PG86cD4mbmJzcDs8L286 cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tR0IiIHN0 eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7 Ij4mbmJzcDsmbmJzcDsgUHJvdG9jb2wgaWRlbnRpZmljYXRpb24gTVVTVCBiZSBzdXBwbGllZCBh cyBwYXJ0IG9mIHRoZSBEVExTPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+PHNwYW4gbGFuZz0iRU4tR0IiIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFt aWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7Ij4mbmJzcDsmbmJzcDsgaGFuZHNoYWtlLCBhcyBz cGVjaWZpZWQgaW4gWzxhIGhyZWY9Imh0dHBzOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC1p ZXRmLXJ0Y3dlYi10cmFuc3BvcnRzLTA5I3JlZi1JLUQuaWV0Zi1ydGN3ZWItYWxwbiI+SS1ELmll dGYtcnRjd2ViLWFscG48L2E+XS48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj48c3BhbiBsYW5nPSJFTi1HQiIgc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1m YW1pbHk6Q29uc29sYXM7Y29sb3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9w Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tR0IiIHN0eWxlPSJmb250LXNp emU6MTEuMHB0O2ZvbnQtZmFtaWx5OkNvbnNvbGFzO2NvbG9yOiMxRjQ5N0QiPkNvbW1lbnRzPzxv OnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVO LUdCIiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTpDb25zb2xhcztjb2xvcjoj MUY0OTdEIj5SZWdhcmRzLDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPjxzcGFuIGxhbmc9IkVOLUdCIiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWls eTpDb25zb2xhcztjb2xvcjojMUY0OTdEIj5BbGJyZWNodDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLUdCIiBzdHlsZT0iZm9udC1zaXpl OjExLjBwdDtmb250LWZhbWlseTpDb25zb2xhcztjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwv bzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1HQiIg c3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6Q29uc29sYXM7Y29sb3I6IzFGNDk3 RCI+UFM8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBs YW5nPSJFTi1HQiIgc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6Q29uc29sYXM7 Y29sb3I6IzFGNDk3RCI+VXNpbmcgKEQpVExTIHRlcm1pbm9sb2d5IGFjY29yZGluZyB0bw0KPGEg aHJlZj0iaHR0cDovL3Rvb2xzLmlldGYub3JnL2lkL2RyYWZ0LWd1YmFsbGEtdGxzLXRlcm1pbm9s b2d5LTAxLnR4dCI+aHR0cDovL3Rvb2xzLmlldGYub3JnL2lkL2RyYWZ0LWd1YmFsbGEtdGxzLXRl cm1pbm9sb2d5LTAxLnR4dDwvYT4NCjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLUdCIiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250 LWZhbWlseTpDb25zb2xhcztjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48 L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1HQiIgc3R5bGU9ImZvbnQt c2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6Q29uc29sYXM7Y29sb3I6IzFGNDk3RCI+PG86cD4mbmJz cDs8L286cD48L3NwYW4+PC9wPg0KPGRpdj4NCjxkaXYgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRl ci10b3A6c29saWQgI0I1QzRERiAxLjBwdDtwYWRkaW5nOjMuMHB0IDBjbSAwY20gMGNtIj4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPjxiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXpl OjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtUYWhvbWEmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZx dW90OyI+RnJvbTo8L3NwYW4+PC9iPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXpl OjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtUYWhvbWEmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZx dW90OyI+IEJlcm5hcmQgQWJvYmEgWzxhIGhyZWY9Im1haWx0bzpiZXJuYXJkLmFib2JhQGdtYWls LmNvbSI+bWFpbHRvOmJlcm5hcmQuYWJvYmFAZ21haWwuY29tPC9hPl0NCjxicj4NCjxiPlNlbnQ6 PC9iPiBNaXR0d29jaCwgNS4gQXVndXN0IDIwMTUgMDQ6MDQ8YnI+DQo8Yj5Ubzo8L2I+IFJvbWFu IFNocG91bnQ8YnI+DQo8Yj5DYzo8L2I+IEFzdmVyZW4sIFRvbGdhOyBDaHJpc3RlciBIb2xtYmVy ZzsgRXJpYyBSZXNjb3JsYTsgU2Nod2FyeiwgQWxicmVjaHQgKEFsYnJlY2h0KTsgUmF1c2NoZW5i YWNoLCBVd2UgKE5va2lhIC0gREUvTXVuaWNoKTsgJmx0OzxhIGhyZWY9Im1haWx0bzpydGN3ZWJA aWV0Zi5vcmciPnJ0Y3dlYkBpZXRmLm9yZzwvYT4mZ3Q7PGJyPg0KPGI+U3ViamVjdDo8L2I+IFJl OiBbcnRjd2ViXSBXaGF0IHRoZSBnYXRld2F5IGRyYWZ0IHNob3VsZCBzYXkgYWJvdXQgbXV4L25v bi1tdXg8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tR0IiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4N CjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1HQiI+T24gQXVnIDQs IDIwMTUsIGF0IDE2OjMzLCBSb21hbiBTaHBvdW50ICZsdDs8YSBocmVmPSJtYWlsdG86cm9tYW5A dGVsdXJpeC5jb20iPnJvbWFuQHRlbHVyaXguY29tPC9hPiZndDsgd3JvdGU6PG86cD48L286cD48 L3NwYW4+PC9wPg0KPC9kaXY+DQo8YmxvY2txdW90ZSBzdHlsZT0ibWFyZ2luLXRvcDo1LjBwdDtt YXJnaW4tYm90dG9tOjUuMHB0Ij4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1HQiI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+ PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4t R0IiIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2Vy aWYmcXVvdDs7Y29sb3I6YmxhY2siPk1vc3Qgb2YgdGhlIHBlb3BsZSBpbXBsZW1lbnQgdGhpcyB3 cm9uZywgc2luY2UgeW91IG5lZWQgdG8gY3JlYXRlIHR3byBEVExTIHNlc3Npb25zOiBvbmUgZm9y IFJUUCBhbmQgYW5vdGhlciBmb3IgUlRDUC4gQW5kIHRoZW4gdXNlIGRpZmZlcmVudCBrZXlzIG9y IHBvc3NpYmx5IGV2ZW4NCiBlbmNyeXB0aW9uIHByb2ZpbGVzIGZvciBSVFAgYW5kIFJUQ1AuIEkg Y29tbW9ubHkgc2VlIG9uZSBzZXNzaW9uIGZvciBSVFAgYW5kIGtleXMgbmVnb3RpYXRlZCB0aGVy ZSB1c2VkIGZvciBib3RoIFJUUCBhbmQgUlRDUCwgd2hpY2ggaXMgd3JvbmcuPC9zcGFuPjxzcGFu IGxhbmc9IkVOLUdCIj48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9k aXY+DQo8L2Rpdj4NCjwvYmxvY2txdW90ZT4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxh bmc9IkVOLUdCIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tR0IiPltCQV0gWWVzLCB0aGF0IGlzIG9ubHkgb25l IG9mIHNldmVyYWwgY29tbW9uIG1pc3Rha2VzLiAmbmJzcDtVbmZvcnR1bmF0ZWx5LCBSRkMgNTc2 NCBkb2VzIG5vdCBydWxlIG91dCBhbGwgb2YgdGhlc2UgYW5kIHRoZSBzZWN1cml0eSBkb2N1bWVu dHMgYXJlIG5vdCBjcnlzdGFsIGNsZWFyIG9uIGhvdyB0aGluZ3MgbXVzdCBiZSBkb25lLiBJdCBp cyBtdWNoIGhhcmRlciB0byBtZXNzIHVwDQogUlRQL1JUQ1AgbXV4LiAmbmJzcDtHaXZlbiB3aGF0 IEkndmUgc2VlbiBzbyBmYXIsIG5vbi1tdXggY291bGQgYmVjb21lIGEgc3VwcG9ydCBuaWdodG1h cmUuJm5ic3A7PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwvYm9keT4N CjwvaHRtbD4NCg== --_000_7594FB04B1934943A5C02806D1A2204B348E8E9FESESSMB209erics_-- From nobody Wed Aug 5 01:17:14 2015 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CB8DC1B2D93; Wed, 5 Aug 2015 01:17:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.909 X-Spam-Level: X-Spam-Status: No, score=-6.909 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, 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 xljVL1EfJhUm; Wed, 5 Aug 2015 01:17:00 -0700 (PDT) Received: from smtp-fr.alcatel-lucent.com (fr-hpgre-esg-01.alcatel-lucent.com [135.245.210.22]) (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 689BD1B2DA3; Wed, 5 Aug 2015 01:16:59 -0700 (PDT) Received: from fr711usmtp1.zeu.alcatel-lucent.com (unknown [135.239.2.122]) by Websense Email Security Gateway with ESMTPS id 977C4DB24FF8B; Wed, 5 Aug 2015 08:16:56 +0000 (GMT) Received: from FR711WXCHHUB02.zeu.alcatel-lucent.com (fr711wxchhub02.zeu.alcatel-lucent.com [135.239.2.112]) by fr711usmtp1.zeu.alcatel-lucent.com (GMO) with ESMTP id t758Gvrw008305 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Wed, 5 Aug 2015 10:16:57 +0200 Received: from FR711WXCHMBA03.zeu.alcatel-lucent.com ([169.254.3.123]) by FR711WXCHHUB02.zeu.alcatel-lucent.com ([135.239.2.112]) with mapi id 14.03.0195.001; Wed, 5 Aug 2015 10:16:57 +0200 From: "Schwarz, Albrecht (Albrecht)" To: Christer Holmberg , "" Thread-Topic: [rtcweb] Number of DTLS sessions/DTLS connections; RE: What the gateway draft should say about mux/non-mux Thread-Index: AQHQz1aGMlfTH2VOiEWUETQoEL7QIZ39Dwuw Date: Wed, 5 Aug 2015 08:16:56 +0000 Message-ID: <786615F3A85DF44AA2A76164A71FE1AC7ADB91EC@FR711WXCHMBA03.zeu.alcatel-lucent.com> References: <7594FB04B1934943A5C02806D1A2204B348E82CA@ESESSMB209.ericsson.se> <05B3C43B-2823-4590-889E-7A192FC8A3AD@gmail.com> <786615F3A85DF44AA2A76164A71FE1AC7ADB9197@FR711WXCHMBA03.zeu.alcatel-lucent.com> <7594FB04B1934943A5C02806D1A2204B348E8E9F@ESESSMB209.ericsson.se> In-Reply-To: <7594FB04B1934943A5C02806D1A2204B348E8E9F@ESESSMB209.ericsson.se> Accept-Language: de-DE, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [135.239.27.39] Content-Type: multipart/alternative; boundary="_000_786615F3A85DF44AA2A76164A71FE1AC7ADB91ECFR711WXCHMBA03z_" MIME-Version: 1.0 Archived-At: Cc: "TLS@ietf.org \(tls@ietf.org\)" Subject: Re: [rtcweb] Number of DTLS sessions/DTLS connections; RE: What the gateway draft should say about mux/non-mux X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 05 Aug 2015 08:17:10 -0000 --_000_786615F3A85DF44AA2A76164A71FE1AC7ADB91ECFR711WXCHMBA03z_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 Q2hyaXN0ZXIsDQpkbyBhZ3JlZSBvZiBjb3Vyc2UuDQpCdXQgaW5kZXBlbmRlbnQgb2YgdGhlIFJG QyA1NzY0IGNvcnJlY3Rpb24sIGJlbG93IGNsYXJpZmljYXRpb24gcHJvcG9zYWwgZm9yIHJ0Y3dl Yi10cmFuc3BvcnQgcmVtYWlucyB2YWxpZCAo4oCcZHVlIHRvIHRoZSBzaGFyaW5nIGFzc3VtcHRp b27igJ0pLg0KDQpSZWdhcmRzLA0KQWxicmVjaHQNCg0KRnJvbTogQ2hyaXN0ZXIgSG9sbWJlcmcg W21haWx0bzpjaHJpc3Rlci5ob2xtYmVyZ0Blcmljc3Nvbi5jb21dDQpTZW50OiBNaXR0d29jaCwg NS4gQXVndXN0IDIwMTUgMTA6MTMNClRvOiBTY2h3YXJ6LCBBbGJyZWNodCAoQWxicmVjaHQpOyA8 cnRjd2ViQGlldGYub3JnPg0KQ2M6IFRMU0BpZXRmLm9yZyAodGxzQGlldGYub3JnKQ0KU3ViamVj dDogUkU6IFtydGN3ZWJdIE51bWJlciBvZiBEVExTIHNlc3Npb25zL0RUTFMgY29ubmVjdGlvbnM7 IFJFOiBXaGF0IHRoZSBnYXRld2F5IGRyYWZ0IHNob3VsZCBzYXkgYWJvdXQgbXV4L25vbi1tdXgN Cg0KSGksDQoNCldlIHNoYWxsIG5vdCBtYWtlIFJGQyA1NzY0IGNvcnJlY3Rpb25zIGluIHRoZSBS VENXRUIgc3BlY3MuDQoNClJlZ2FyZHMsDQoNCkNocmlzdGVyDQoNCg0KDQpGcm9tOiBydGN3ZWIg W21haWx0bzpydGN3ZWItYm91bmNlc0BpZXRmLm9yZ10gT24gQmVoYWxmIE9mIFNjaHdhcnosIEFs YnJlY2h0IChBbGJyZWNodCkNClNlbnQ6IDUuIGVsb2t1dXRhIDIwMTUgMTE6MDQNClRvOiA8cnRj d2ViQGlldGYub3JnPG1haWx0bzpydGN3ZWJAaWV0Zi5vcmc+Pg0KQ2M6IFRMU0BpZXRmLm9yZzxt YWlsdG86VExTQGlldGYub3JnPiAodGxzQGlldGYub3JnPG1haWx0bzp0bHNAaWV0Zi5vcmc+KQ0K U3ViamVjdDogW3J0Y3dlYl0gTnVtYmVyIG9mIERUTFMgc2Vzc2lvbnMvRFRMUyBjb25uZWN0aW9u czsgUkU6IFdoYXQgdGhlIGdhdGV3YXkgZHJhZnQgc2hvdWxkIHNheSBhYm91dCBtdXgvbm9uLW11 eA0KDQpSb21hbiwgQmVybmFyZCwNCnJpZ2h0LCBSRkMgNTc2NCBpcyB0b28gdmFndWUgb24gdGhh dCBhc3BlY3QuIFRoYW5rcyBmb3IgY29uZmlybWluZyB0aGUgbnVtYmVyIG9mIERUTFMgc2Vzc2lv bnMsIHdoaWNoIGlzIGlubGluZSB3aXRoIG91ciB1bmRlcnN0YW5kaW5nLg0KV291bGQgYXBwcmVj aWF0ZSBpZiB0aGlzIGNvdWxkIGJlIHNvbWV3aGVyZSBmaXhlZCBpbiBhbiBydGN3ZWIgZHJhZnQg ZHVlIHRvIHNpZ25pZmljYW50IHNpZGUgZWZmZWN0cy4NClRoaXMgdG9waWMgaXMgYWxzbyBhbiBv bmdvaW5nIEZBUS4NCg0KVGhlIG1vc3Qgc2ltcGxlIGNhc2UgaXMgZ2l2ZW4gYnkgYSBzY2VuYXJp byB3aXRoIHVzYWdlIG9mIGJ1bmRsaW5nIHBsdXMgdXNhZ2Ugb2YgUlRQL1JUQ1AgdHJhbnNwb3J0 IG11bHRpcGxleGluZywgbGVhZGluZyB0byBhIHNpbmdsZSBEVExTIHNlc3Npb24vRFRMUyBjb25u ZWN0aW9uLCB3aGljaCBjb3VsZCBiZSB0aGVuIGFsc28gc2hhcmVkIGZvciBXZWJSVEMgZGF0YS4N Cg0KQm90aCBjYXBhYmlsaXRpZXMgYXJlIG1hbmRhdGVkIGluIHRoZSBydHAgdXNhZ2UgZHJhZnQ6 DQpodHRwczovL3Rvb2xzLmlldGYub3JnL2h0bWwvZHJhZnQtaWV0Zi1ydGN3ZWItcnRwLXVzYWdl LTI1I3NlY3Rpb24tNC40DQo9PiBidW5kbGluZw0KaHR0cHM6Ly90b29scy5pZXRmLm9yZy9odG1s L2RyYWZ0LWlldGYtcnRjd2ViLXJ0cC11c2FnZS0yNSNzZWN0aW9uLTQuNQ0KPT4gUlRQL1JUQ1Ag dHJhbnNwb3J0IG11bHRpcGxleGluZw0KDQpOb3csIElGIGJ1bmRsaW5nIGlzIG5vdCB1c2VkIE9S IFJUUC9SVENQIHRyYW5zcG9ydCBtdWx0aXBsZXhpbmcgaXMgbm90IHVzZWQgVEhFTiB0aGVyZSB3 aWxsIGJlIG1vcmUgdGhhbiBvbmUgRFRMUyBzZXNzaW9uL0RUTFMgY29ubmVjdGlvbiAoZWl0aGVy IDIgb3IgNCBpbiBjYXNlIG9mIGF1ZGlvICYgdmlkZW8pLg0KUmFpc2luZyB0aGUgcXVlc3Rpb24g d2hpY2ggRFRMUyBjb25uZWN0aW9uIGlzIHVzZWQgZm9yIGFkZGl0aW9uYWwgV2ViUlRDIGRhdGEg dHJhZmZpYz8gLSBCZWNhdXNlDQpodHRwczovL3Rvb2xzLmlldGYub3JnL2h0bWwvZHJhZnQtaWV0 Zi1ydGN3ZWItdHJhbnNwb3J0cy0wOSNzZWN0aW9uLTMuNQ0KaW5kaWNhdGVzIHRoZSBzaGFyaW5n IG9wdGlvbi4NCldvdWxkIHRoZW4gYmUgYSAzcmQgKG9yIDV0aCkgc2VsZi1jb250YWluZWQgRFRM UyBzZXNzaW9uL0RUTFMgY29ubmVjdGlvbiBmb3IgV2ViUlRDIGRhdGEgdHJhZmZpYz8NCg0KUHJv cG9zYWw6DQpBZGQgZXhwbGljaXQgdGV4dCB0byBjbGF1c2UgaHR0cHM6Ly90b29scy5pZXRmLm9y Zy9odG1sL2RyYWZ0LWlldGYtcnRjd2ViLXRyYW5zcG9ydHMtMDkjc2VjdGlvbi0zLjUNCmFib3V0 IChpbiByZWQpLCBzb21ldGhpbmcgbGlrZToNCg0KICAgV2ViUlRDIGltcGxlbWVudGF0aW9ucyBN VVNUIHN1cHBvcnQgbXVsdGlwbGV4aW5nIG9mIERUTFMgYW5kIFJUUCBvdmVyDQogICB0aGUgc2Ft ZSBwb3J0IHBhaXIsIGFzIGRlc2NyaWJlZCBpbiB0aGUgRFRMUy1TUlRQIHNwZWNpZmljYXRpb24N CiAgIFtSRkM1NzY0XSwgc2VjdGlvbiA1LjEuMjxodHRwczovL3Rvb2xzLmlldGYub3JnL2h0bWwv cmZjNTc2NCNzZWN0aW9uLTUuMS4yPi4gIEFsbCBhcHBsaWNhdGlvbiBsYXllciBwcm90b2NvbCBw YXlsb2Fkcw0KICAgb3ZlciB0aGlzIERUTFMgY29ubmVjdGlvbiBhcmUgU0NUUCBwYWNrZXRzLg0K DQoNCg0KICAgTm90ZSAxOiBUaGVyZSB3aWxsIGJlIHR3byBEVExTIHNlc3Npb25zL0RUTFMgY29u bmVjdGlvbnMgd2hlbiBSVFAvUlRDUCB0cmFuc3BvcnQgbXVsdGlwbGV4aW5nIGlzIG5vdCBhcHBs aWVkLiBXZWJSVEMgZGF0YSB0cmFmZmljIGNvdWxkIHN0aWxsIHNoYXJlIG9uZSBvZiB0aGVzZSBE VExTIGNvbm5lY3Rpb25zIOKApiAo4oCcd2hpY2ggb25lP+KAnSkg4oCmIG9yIFRoZXJlIHNob3Vs ZCBiZSB0aGVuIGEgc2VwYXJhdGUsIHNlbGYtY29udGFpbmVkIERUTFMgc2Vzc2lvbi9EVExTIGNv bm5lY3Rpb24gZXN0YWJsaXNoZWQgZXhjbHVzaXZlbHkgZm9yIFdlYlJUQyBkYXRhLg0KDQoNCg0K ICAgTm90ZSAyOiBUaGVyZSBhcmUgc2ltaWxhciBjb25zaWRlcmF0aW9ucyBpbiBjYXNlIG9mIGJ1 bmRsaW5nLg0KDQogICBQcm90b2NvbCBpZGVudGlmaWNhdGlvbiBNVVNUIGJlIHN1cHBsaWVkIGFz IHBhcnQgb2YgdGhlIERUTFMNCiAgIGhhbmRzaGFrZSwgYXMgc3BlY2lmaWVkIGluIFtJLUQuaWV0 Zi1ydGN3ZWItYWxwbjxodHRwczovL3Rvb2xzLmlldGYub3JnL2h0bWwvZHJhZnQtaWV0Zi1ydGN3 ZWItdHJhbnNwb3J0cy0wOSNyZWYtSS1ELmlldGYtcnRjd2ViLWFscG4+XS4NCg0KQ29tbWVudHM/ DQpSZWdhcmRzLA0KQWxicmVjaHQNCg0KUFMNClVzaW5nIChEKVRMUyB0ZXJtaW5vbG9neSBhY2Nv cmRpbmcgdG8gaHR0cDovL3Rvb2xzLmlldGYub3JnL2lkL2RyYWZ0LWd1YmFsbGEtdGxzLXRlcm1p bm9sb2d5LTAxLnR4dA0KDQoNCkZyb206IEJlcm5hcmQgQWJvYmEgW21haWx0bzpiZXJuYXJkLmFi b2JhQGdtYWlsLmNvbV0NClNlbnQ6IE1pdHR3b2NoLCA1LiBBdWd1c3QgMjAxNSAwNDowNA0KVG86 IFJvbWFuIFNocG91bnQNCkNjOiBBc3ZlcmVuLCBUb2xnYTsgQ2hyaXN0ZXIgSG9sbWJlcmc7IEVy aWMgUmVzY29ybGE7IFNjaHdhcnosIEFsYnJlY2h0IChBbGJyZWNodCk7IFJhdXNjaGVuYmFjaCwg VXdlIChOb2tpYSAtIERFL011bmljaCk7IDxydGN3ZWJAaWV0Zi5vcmc8bWFpbHRvOnJ0Y3dlYkBp ZXRmLm9yZz4+DQpTdWJqZWN0OiBSZTogW3J0Y3dlYl0gV2hhdCB0aGUgZ2F0ZXdheSBkcmFmdCBz aG91bGQgc2F5IGFib3V0IG11eC9ub24tbXV4DQoNCk9uIEF1ZyA0LCAyMDE1LCBhdCAxNjozMywg Um9tYW4gU2hwb3VudCA8cm9tYW5AdGVsdXJpeC5jb208bWFpbHRvOnJvbWFuQHRlbHVyaXguY29t Pj4gd3JvdGU6DQoNCk1vc3Qgb2YgdGhlIHBlb3BsZSBpbXBsZW1lbnQgdGhpcyB3cm9uZywgc2lu Y2UgeW91IG5lZWQgdG8gY3JlYXRlIHR3byBEVExTIHNlc3Npb25zOiBvbmUgZm9yIFJUUCBhbmQg YW5vdGhlciBmb3IgUlRDUC4gQW5kIHRoZW4gdXNlIGRpZmZlcmVudCBrZXlzIG9yIHBvc3NpYmx5 IGV2ZW4gZW5jcnlwdGlvbiBwcm9maWxlcyBmb3IgUlRQIGFuZCBSVENQLiBJIGNvbW1vbmx5IHNl ZSBvbmUgc2Vzc2lvbiBmb3IgUlRQIGFuZCBrZXlzIG5lZ290aWF0ZWQgdGhlcmUgdXNlZCBmb3Ig Ym90aCBSVFAgYW5kIFJUQ1AsIHdoaWNoIGlzIHdyb25nLg0KDQpbQkFdIFllcywgdGhhdCBpcyBv bmx5IG9uZSBvZiBzZXZlcmFsIGNvbW1vbiBtaXN0YWtlcy4gIFVuZm9ydHVuYXRlbHksIFJGQyA1 NzY0IGRvZXMgbm90IHJ1bGUgb3V0IGFsbCBvZiB0aGVzZSBhbmQgdGhlIHNlY3VyaXR5IGRvY3Vt ZW50cyBhcmUgbm90IGNyeXN0YWwgY2xlYXIgb24gaG93IHRoaW5ncyBtdXN0IGJlIGRvbmUuIEl0 IGlzIG11Y2ggaGFyZGVyIHRvIG1lc3MgdXAgUlRQL1JUQ1AgbXV4LiAgR2l2ZW4gd2hhdCBJJ3Zl IHNlZW4gc28gZmFyLCBub24tbXV4IGNvdWxkIGJlY29tZSBhIHN1cHBvcnQgbmlnaHRtYXJlLg0K --_000_786615F3A85DF44AA2A76164A71FE1AC7ADB91ECFR711WXCHMBA03z_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTIgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 IkNhbWJyaWEgTWF0aCI7DQoJcGFub3NlLTE6MiA0IDUgMyA1IDQgNiAzIDIgNDt9DQpAZm9udC1m YWNlDQoJe2ZvbnQtZmFtaWx5OkNhbGlicmk7DQoJcGFub3NlLTE6MiAxNSA1IDIgMiAyIDQgMyAy IDQ7fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseTpUYWhvbWE7DQoJcGFub3NlLTE6MiAxMSA2 IDQgMyA1IDQgNCAyIDQ7fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseTpDb25zb2xhczsNCglw YW5vc2UtMToyIDExIDYgOSAyIDIgNCAzIDIgNDt9DQovKiBTdHlsZSBEZWZpbml0aW9ucyAqLw0K cC5Nc29Ob3JtYWwsIGxpLk1zb05vcm1hbCwgZGl2Lk1zb05vcm1hbA0KCXttYXJnaW46MGNtOw0K CW1hcmdpbi1ib3R0b206LjAwMDFwdDsNCglmb250LXNpemU6MTIuMHB0Ow0KCWZvbnQtZmFtaWx5 OiJUaW1lcyBOZXcgUm9tYW4iLCJzZXJpZiI7fQ0KYTpsaW5rLCBzcGFuLk1zb0h5cGVybGluaw0K CXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6Ymx1ZTsNCgl0ZXh0LWRlY29yYXRpb246 dW5kZXJsaW5lO30NCmE6dmlzaXRlZCwgc3Bhbi5Nc29IeXBlcmxpbmtGb2xsb3dlZA0KCXttc28t c3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6cHVycGxlOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRl cmxpbmU7fQ0KcHJlDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgltc28tc3R5bGUtbGluazoi SFRNTCBQcmVmb3JtYXR0ZWQgQ2hhciI7DQoJbWFyZ2luOjBjbTsNCgltYXJnaW4tYm90dG9tOi4w MDAxcHQ7DQoJZm9udC1zaXplOjEwLjBwdDsNCglmb250LWZhbWlseToiQ291cmllciBOZXciO30N CnAuTXNvQWNldGF0ZSwgbGkuTXNvQWNldGF0ZSwgZGl2Lk1zb0FjZXRhdGUNCgl7bXNvLXN0eWxl LXByaW9yaXR5Ojk5Ow0KCW1zby1zdHlsZS1saW5rOiJCYWxsb29uIFRleHQgQ2hhciI7DQoJbWFy Z2luOjBjbTsNCgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJZm9udC1zaXplOjguMHB0Ow0KCWZv bnQtZmFtaWx5OiJUYWhvbWEiLCJzYW5zLXNlcmlmIjt9DQpwLk1zb0xpc3RQYXJhZ3JhcGgsIGxp Lk1zb0xpc3RQYXJhZ3JhcGgsIGRpdi5Nc29MaXN0UGFyYWdyYXBoDQoJe21zby1zdHlsZS1wcmlv cml0eTozNDsNCgltYXJnaW4tdG9wOjBjbTsNCgltYXJnaW4tcmlnaHQ6MGNtOw0KCW1hcmdpbi1i b3R0b206MGNtOw0KCW1hcmdpbi1sZWZ0OjM2LjBwdDsNCgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7 DQoJZm9udC1zaXplOjEyLjBwdDsNCglmb250LWZhbWlseToiVGltZXMgTmV3IFJvbWFuIiwic2Vy aWYiO30NCnNwYW4uSFRNTFByZWZvcm1hdHRlZENoYXINCgl7bXNvLXN0eWxlLW5hbWU6IkhUTUwg UHJlZm9ybWF0dGVkIENoYXIiOw0KCW1zby1zdHlsZS1wcmlvcml0eTo5OTsNCgltc28tc3R5bGUt bGluazoiSFRNTCBQcmVmb3JtYXR0ZWQiOw0KCWZvbnQtZmFtaWx5OiJDb3VyaWVyIE5ldyI7fQ0K c3Bhbi5CYWxsb29uVGV4dENoYXINCgl7bXNvLXN0eWxlLW5hbWU6IkJhbGxvb24gVGV4dCBDaGFy IjsNCgltc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJbXNvLXN0eWxlLWxpbms6IkJhbGxvb24gVGV4 dCI7DQoJZm9udC1mYW1pbHk6IlRhaG9tYSIsInNhbnMtc2VyaWYiO30NCnNwYW4uRW1haWxTdHls ZTIyDQoJe21zby1zdHlsZS10eXBlOnBlcnNvbmFsOw0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIiwi c2Fucy1zZXJpZiI7DQoJY29sb3I6IzFGNDk3RDt9DQpzcGFuLkVtYWlsU3R5bGUyMw0KCXttc28t c3R5bGUtdHlwZTpwZXJzb25hbDsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsInNhbnMtc2VyaWYi Ow0KCWNvbG9yOiMxRjQ5N0Q7fQ0Kc3Bhbi5FbWFpbFN0eWxlMjQNCgl7bXNvLXN0eWxlLXR5cGU6 cGVyc29uYWwtcmVwbHk7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLCJzYW5zLXNlcmlmIjsNCglj b2xvcjojMUY0OTdEO30NCi5Nc29DaHBEZWZhdWx0DQoJe21zby1zdHlsZS10eXBlOmV4cG9ydC1v bmx5Ow0KCWZvbnQtc2l6ZToxMC4wcHQ7fQ0KQHBhZ2UgV29yZFNlY3Rpb24xDQoJe3NpemU6NjEy LjBwdCA3OTIuMHB0Ow0KCW1hcmdpbjo3Mi4wcHQgNzIuMHB0IDcyLjBwdCA3Mi4wcHQ7fQ0KZGl2 LldvcmRTZWN0aW9uMQ0KCXtwYWdlOldvcmRTZWN0aW9uMTt9DQotLT48L3N0eWxlPjwhLS1baWYg Z3RlIG1zbyA5XT48eG1sPg0KPG86c2hhcGVkZWZhdWx0cyB2OmV4dD0iZWRpdCIgc3BpZG1heD0i MTAyNiIgLz4NCjwveG1sPjwhW2VuZGlmXS0tPjwhLS1baWYgZ3RlIG1zbyA5XT48eG1sPg0KPG86 c2hhcGVsYXlvdXQgdjpleHQ9ImVkaXQiPg0KPG86aWRtYXAgdjpleHQ9ImVkaXQiIGRhdGE9IjEi IC8+DQo8L286c2hhcGVsYXlvdXQ+PC94bWw+PCFbZW5kaWZdLS0+DQo8L2hlYWQ+DQo8Ym9keSBs YW5nPSJFTi1HQiIgbGluaz0iYmx1ZSIgdmxpbms9InB1cnBsZSI+DQo8ZGl2IGNsYXNzPSJXb3Jk U2VjdGlvbjEiPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTox MS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1 b3Q7O2NvbG9yOiMxRjQ5N0QiPkNocmlzdGVyLDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5 OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdE Ij5kbyBhZ3JlZSBvZiBjb3Vyc2UuPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7 Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPkJ1dCBp bmRlcGVuZGVudCBvZiB0aGUgUkZDIDU3NjQgY29ycmVjdGlvbiwgYmVsb3cgY2xhcmlmaWNhdGlv biBwcm9wb3NhbCBmb3IgcnRjd2ViLXRyYW5zcG9ydCByZW1haW5zIHZhbGlkICjigJxkdWUgdG8g dGhlIHNoYXJpbmcgYXNzdW1wdGlvbuKAnSkuPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6 JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0Qi PjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFu IHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDss JnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj5SZWdhcmRzLDxvOnA+PC9vOnA+ PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6 MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZx dW90Oztjb2xvcjojMUY0OTdEIj5BbGJyZWNodDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5 OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdE Ij48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8ZGl2Pg0KPGRpdiBzdHlsZT0iYm9yZGVy Om5vbmU7Ym9yZGVyLXRvcDpzb2xpZCAjQjVDNERGIDEuMHB0O3BhZGRpbmc6My4wcHQgMGNtIDBj bSAwY20iPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxl PSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O1RhaG9tYSZxdW90OywmcXVvdDtz YW5zLXNlcmlmJnF1b3Q7Ij5Gcm9tOjwvc3Bhbj48L2I+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxl PSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O1RhaG9tYSZxdW90OywmcXVvdDtz YW5zLXNlcmlmJnF1b3Q7Ij4gQ2hyaXN0ZXIgSG9sbWJlcmcgW21haWx0bzpjaHJpc3Rlci5ob2xt YmVyZ0Blcmljc3Nvbi5jb21dDQo8YnI+DQo8Yj5TZW50OjwvYj4gTWl0dHdvY2gsIDUuIEF1Z3Vz dCAyMDE1IDEwOjEzPGJyPg0KPGI+VG86PC9iPiBTY2h3YXJ6LCBBbGJyZWNodCAoQWxicmVjaHQp OyAmbHQ7cnRjd2ViQGlldGYub3JnJmd0Ozxicj4NCjxiPkNjOjwvYj4gVExTQGlldGYub3JnICh0 bHNAaWV0Zi5vcmcpPGJyPg0KPGI+U3ViamVjdDo8L2I+IFJFOiBbcnRjd2ViXSBOdW1iZXIgb2Yg RFRMUyBzZXNzaW9ucy9EVExTIGNvbm5lY3Rpb25zOyBSRTogV2hhdCB0aGUgZ2F0ZXdheSBkcmFm dCBzaG91bGQgc2F5IGFib3V0IG11eC9ub24tbXV4PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9k aXY+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRkkiIHN0eWxlPSJmb250LXNpemU6MTEu MHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90 Oztjb2xvcjojMUY0OTdEIj5IaSw8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj48c3BhbiBsYW5nPSJGSSIgc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1p bHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5 N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxz cGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVv dDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+V2Ug c2hhbGwgbm90IG1ha2UgUkZDIDU3NjQgY29ycmVjdGlvbnMgaW4gdGhlIFJUQ1dFQiBzcGVjcy48 bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJF Ti1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZx dW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9v OnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBz dHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZx dW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+UmVnYXJkcyw8bzpwPjwvbzpwPjwv c3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9 ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtz YW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwv cD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1z aXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2Vy aWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+Q2hyaXN0ZXI8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZTox MS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1 b3Q7O2NvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtm b250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29s b3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFt aWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0 OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8ZGl2Pg0KPGRpdiBzdHlsZT0iYm9y ZGVyOm5vbmU7Ym9yZGVyLXRvcDpzb2xpZCAjQjVDNERGIDEuMHB0O3BhZGRpbmc6My4wcHQgMGNt IDBjbSAwY20iPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0 eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O1RhaG9tYSZxdW90OywmcXVv dDtzYW5zLXNlcmlmJnF1b3Q7Ij5Gcm9tOjwvc3Bhbj48L2I+PHNwYW4gbGFuZz0iRU4tVVMiIHN0 eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O1RhaG9tYSZxdW90OywmcXVv dDtzYW5zLXNlcmlmJnF1b3Q7Ij4gcnRjd2ViIFs8YSBocmVmPSJtYWlsdG86cnRjd2ViLWJvdW5j ZXNAaWV0Zi5vcmciPm1haWx0bzpydGN3ZWItYm91bmNlc0BpZXRmLm9yZzwvYT5dDQo8Yj5PbiBC ZWhhbGYgT2YgPC9iPlNjaHdhcnosIEFsYnJlY2h0IChBbGJyZWNodCk8YnI+DQo8Yj5TZW50Ojwv Yj4gNS4gZWxva3V1dGEgMjAxNSAxMTowNDxicj4NCjxiPlRvOjwvYj4gJmx0OzxhIGhyZWY9Im1h aWx0bzpydGN3ZWJAaWV0Zi5vcmciPnJ0Y3dlYkBpZXRmLm9yZzwvYT4mZ3Q7PGJyPg0KPGI+Q2M6 PC9iPiA8YSBocmVmPSJtYWlsdG86VExTQGlldGYub3JnIj5UTFNAaWV0Zi5vcmc8L2E+ICg8YSBo cmVmPSJtYWlsdG86dGxzQGlldGYub3JnIj50bHNAaWV0Zi5vcmc8L2E+KTxicj4NCjxiPlN1Ympl Y3Q6PC9iPiBbcnRjd2ViXSBOdW1iZXIgb2YgRFRMUyBzZXNzaW9ucy9EVExTIGNvbm5lY3Rpb25z OyBSRTogV2hhdCB0aGUgZ2F0ZXdheSBkcmFmdCBzaG91bGQgc2F5IGFib3V0IG11eC9ub24tbXV4 PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPjxzcGFuIGxhbmc9IkZJIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTpD b25zb2xhcztjb2xvcjojMUY0OTdEIj5Sb21hbiwgQmVybmFyZCw8bzpwPjwvbzpwPjwvc3Bhbj48 L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtm b250LWZhbWlseTpDb25zb2xhcztjb2xvcjojMUY0OTdEIj5yaWdodCwgUkZDIDU3NjQgaXMgdG9v IHZhZ3VlIG9uIHRoYXQgYXNwZWN0LiBUaGFua3MgZm9yIGNvbmZpcm1pbmcgdGhlIG51bWJlciBv ZiBEVExTIHNlc3Npb25zLCB3aGljaCBpcyBpbmxpbmUgd2l0aCBvdXIgdW5kZXJzdGFuZGluZy48 bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0i Zm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTpDb25zb2xhcztjb2xvcjojMUY0OTdEIj5Xb3Vs ZCBhcHByZWNpYXRlIGlmIHRoaXMgY291bGQgYmUgc29tZXdoZXJlIGZpeGVkIGluIGFuIHJ0Y3dl YiBkcmFmdCBkdWUgdG8gc2lnbmlmaWNhbnQgc2lkZSBlZmZlY3RzLjxvOnA+PC9vOnA+PC9zcGFu PjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0 O2ZvbnQtZmFtaWx5OkNvbnNvbGFzO2NvbG9yOiMxRjQ5N0QiPlRoaXMgdG9waWMgaXMgYWxzbyBh biBvbmdvaW5nIEZBUS48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTpDb25zb2xhcztjb2xv cjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTpDb25zb2xhcztj b2xvcjojMUY0OTdEIj5UaGUgbW9zdCBzaW1wbGUgY2FzZSBpcyBnaXZlbiBieSBhIHNjZW5hcmlv IHdpdGggdXNhZ2Ugb2YgYnVuZGxpbmcgcGx1cyB1c2FnZSBvZiBSVFAvUlRDUCB0cmFuc3BvcnQg bXVsdGlwbGV4aW5nLCBsZWFkaW5nIHRvIGEgc2luZ2xlIERUTFMgc2Vzc2lvbi9EVExTIGNvbm5l Y3Rpb24sIHdoaWNoDQogY291bGQgYmUgdGhlbiBhbHNvIHNoYXJlZCBmb3IgV2ViUlRDIGRhdGEu PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9 ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6Q29uc29sYXM7Y29sb3I6IzFGNDk3RCI+PG86 cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5 bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6Q29uc29sYXM7Y29sb3I6IzFGNDk3RCI+ Qm90aCBjYXBhYmlsaXRpZXMgYXJlIG1hbmRhdGVkIGluIHRoZSBydHAgdXNhZ2UgZHJhZnQ6PG86 cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZv bnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6Q29uc29sYXM7Y29sb3I6IzFGNDk3RCI+PGEgaHJl Zj0iaHR0cHM6Ly90b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0LWlldGYtcnRjd2ViLXJ0cC11c2Fn ZS0yNSNzZWN0aW9uLTQuNCI+PHNwYW4gbGFuZz0iREUiPmh0dHBzOi8vdG9vbHMuaWV0Zi5vcmcv aHRtbC9kcmFmdC1pZXRmLXJ0Y3dlYi1ydHAtdXNhZ2UtMjUjc2VjdGlvbi00LjQ8L3NwYW4+PC9h Pg0KPC9zcGFuPjxzcGFuIGxhbmc9IkRFIiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZh bWlseTpDb25zb2xhcztjb2xvcjojMUY0OTdEIj48YnI+DQo9Jmd0OyBidW5kbGluZzxvOnA+PC9v OnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNp emU6MTEuMHB0O2ZvbnQtZmFtaWx5OkNvbnNvbGFzO2NvbG9yOiMxRjQ5N0QiPjxhIGhyZWY9Imh0 dHBzOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC1pZXRmLXJ0Y3dlYi1ydHAtdXNhZ2UtMjUj c2VjdGlvbi00LjUiPmh0dHBzOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC1pZXRmLXJ0Y3dl Yi1ydHAtdXNhZ2UtMjUjc2VjdGlvbi00LjU8L2E+DQo8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZh bWlseTpDb25zb2xhcztjb2xvcjojMUY0OTdEIj49Jmd0OyBSVFAvUlRDUCB0cmFuc3BvcnQgbXVs dGlwbGV4aW5nPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNw YW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6Q29uc29sYXM7Y29sb3I6IzFG NDk3RCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6Q29uc29sYXM7Y29sb3I6 IzFGNDk3RCI+Tm93LCBJRiBidW5kbGluZyBpcyBub3QgdXNlZCBPUiBSVFAvUlRDUCB0cmFuc3Bv cnQgbXVsdGlwbGV4aW5nIGlzIG5vdCB1c2VkIFRIRU4gdGhlcmUgd2lsbCBiZSBtb3JlIHRoYW4g b25lIERUTFMgc2Vzc2lvbi9EVExTIGNvbm5lY3Rpb24gKGVpdGhlciAyIG9yIDQgaW4gY2FzZSBv ZiBhdWRpbw0KICZhbXA7IHZpZGVvKS48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTpDb25z b2xhcztjb2xvcjojMUY0OTdEIj5SYWlzaW5nIHRoZSBxdWVzdGlvbiB3aGljaCBEVExTIGNvbm5l Y3Rpb24gaXMgdXNlZCBmb3IgYWRkaXRpb25hbCBXZWJSVEMgZGF0YSB0cmFmZmljPyAtIEJlY2F1 c2U8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHls ZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTpDb25zb2xhcztjb2xvcjojMUY0OTdEIj48 YSBocmVmPSJodHRwczovL3Rvb2xzLmlldGYub3JnL2h0bWwvZHJhZnQtaWV0Zi1ydGN3ZWItdHJh bnNwb3J0cy0wOSNzZWN0aW9uLTMuNSI+aHR0cHM6Ly90b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0 LWlldGYtcnRjd2ViLXRyYW5zcG9ydHMtMDkjc2VjdGlvbi0zLjU8L2E+DQo8bzpwPjwvbzpwPjwv c3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEx LjBwdDtmb250LWZhbWlseTpDb25zb2xhcztjb2xvcjojMUY0OTdEIj5pbmRpY2F0ZXMgdGhlIHNo YXJpbmcgb3B0aW9uLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OkNvbnNvbGFzO2NvbG9y OiMxRjQ5N0QiPldvdWxkIHRoZW4gYmUgYSAzPHN1cD5yZDwvc3VwPiAob3IgNTxzdXA+dGg8L3N1 cD4pIHNlbGYtY29udGFpbmVkIERUTFMgc2Vzc2lvbi9EVExTIGNvbm5lY3Rpb24gZm9yIFdlYlJU QyBkYXRhIHRyYWZmaWM/PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6Q29uc29sYXM7Y29s b3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6Q29uc29sYXM7 Y29sb3I6IzFGNDk3RCI+UHJvcG9zYWw6PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6Q29u c29sYXM7Y29sb3I6IzFGNDk3RCI+QWRkIGV4cGxpY2l0IHRleHQgdG8gY2xhdXNlDQo8YSBocmVm PSJodHRwczovL3Rvb2xzLmlldGYub3JnL2h0bWwvZHJhZnQtaWV0Zi1ydGN3ZWItdHJhbnNwb3J0 cy0wOSNzZWN0aW9uLTMuNSI+DQpodHRwczovL3Rvb2xzLmlldGYub3JnL2h0bWwvZHJhZnQtaWV0 Zi1ydGN3ZWItdHJhbnNwb3J0cy0wOSNzZWN0aW9uLTMuNTwvYT4gPG86cD4NCjwvbzpwPjwvc3Bh bj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBw dDtmb250LWZhbWlseTpDb25zb2xhcztjb2xvcjojMUY0OTdEIj5hYm91dCAoaW4gcmVkKSwgc29t ZXRoaW5nIGxpa2U6PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6Q29uc29sYXM7Y29sb3I6 IzFGNDk3RCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmll ciBOZXcmcXVvdDsiPiZuYnNwOyZuYnNwOyBXZWJSVEMgaW1wbGVtZW50YXRpb25zIE1VU1Qgc3Vw cG9ydCBtdWx0aXBsZXhpbmcgb2YgRFRMUyBhbmQgUlRQIG92ZXI8bzpwPjwvbzpwPjwvc3Bhbj48 L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtm b250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90OyI+Jm5ic3A7Jm5ic3A7IHRoZSBzYW1l IHBvcnQgcGFpciwgYXMgZGVzY3JpYmVkIGluIHRoZSBEVExTLVNSVFAgc3BlY2lmaWNhdGlvbjxv OnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJm b250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7Ij4mbmJz cDsmbmJzcDsgPGEgaHJlZj0iaHR0cHM6Ly90b29scy5pZXRmLm9yZy9odG1sL3JmYzU3NjQjc2Vj dGlvbi01LjEuMiI+DQpbUkZDNTc2NF0sIHNlY3Rpb24mbmJzcDs1LjEuMjwvYT4uJm5ic3A7IEFs bCBhcHBsaWNhdGlvbiBsYXllciBwcm90b2NvbCBwYXlsb2FkczxvOnA+PC9vOnA+PC9zcGFuPjwv cD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2Zv bnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7Ij4mbmJzcDsmbmJzcDsgb3ZlciB0aGlz IERUTFMgY29ubmVjdGlvbiBhcmUgU0NUUCBwYWNrZXRzLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4N CjxwcmU+PG86cD4mbmJzcDs8L286cD48L3ByZT4NCjxwcmU+PHNwYW4gc3R5bGU9ImNvbG9yOnJl ZCI+Jm5ic3A7Jm5ic3A7IE5vdGUgMTogVGhlcmUgd2lsbCBiZSB0d28gRFRMUyBzZXNzaW9ucy9E VExTIGNvbm5lY3Rpb25zIHdoZW4gUlRQL1JUQ1AgdHJhbnNwb3J0IG11bHRpcGxleGluZyBpcyBu b3QgYXBwbGllZC4gV2ViUlRDIGRhdGEgdHJhZmZpYyBjb3VsZCBzdGlsbCBzaGFyZSBvbmUgb2Yg dGhlc2UgRFRMUyBjb25uZWN0aW9ucyDigKYgPHNwYW4gc3R5bGU9ImJhY2tncm91bmQ6eWVsbG93 O21zby1oaWdobGlnaHQ6eWVsbG93Ij4o4oCcd2hpY2ggb25lP+KAnSk8L3NwYW4+IOKApiBvciBU aGVyZSBzaG91bGQgYmUgdGhlbiBhIHNlcGFyYXRlLCBzZWxmLWNvbnRhaW5lZCBEVExTIHNlc3Np b24vRFRMUyBjb25uZWN0aW9uIGVzdGFibGlzaGVkIGV4Y2x1c2l2ZWx5IGZvciBXZWJSVEMgZGF0 YS48bzpwPjwvbzpwPjwvc3Bhbj48L3ByZT4NCjxwcmU+PHNwYW4gc3R5bGU9ImNvbG9yOnJlZCI+ PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wcmU+DQo8cHJlPjxzcGFuIHN0eWxlPSJjb2xvcjpy ZWQiPiZuYnNwOyZuYnNwOyBOb3RlIDI6IFRoZXJlIGFyZSBzaW1pbGFyIGNvbnNpZGVyYXRpb25z IGluIGNhc2Ugb2YgYnVuZGxpbmcuPC9zcGFuPjxvOnA+PC9vOnA+PC9wcmU+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVv dDtDb3VyaWVyIE5ldyZxdW90OyI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6 JnF1b3Q7Q291cmllciBOZXcmcXVvdDsiPiZuYnNwOyZuYnNwOyBQcm90b2NvbCBpZGVudGlmaWNh dGlvbiBNVVNUIGJlIHN1cHBsaWVkIGFzIHBhcnQgb2YgdGhlIERUTFM8bzpwPjwvbzpwPjwvc3Bh bj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBw dDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90OyI+Jm5ic3A7Jm5ic3A7IGhhbmRz aGFrZSwgYXMgc3BlY2lmaWVkIGluIFs8YSBocmVmPSJodHRwczovL3Rvb2xzLmlldGYub3JnL2h0 bWwvZHJhZnQtaWV0Zi1ydGN3ZWItdHJhbnNwb3J0cy0wOSNyZWYtSS1ELmlldGYtcnRjd2ViLWFs cG4iPkktRC5pZXRmLXJ0Y3dlYi1hbHBuPC9hPl0uPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1p bHk6Q29uc29sYXM7Y29sb3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1m YW1pbHk6Q29uc29sYXM7Y29sb3I6IzFGNDk3RCI+Q29tbWVudHM/PG86cD48L286cD48L3NwYW4+ PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7 Zm9udC1mYW1pbHk6Q29uc29sYXM7Y29sb3I6IzFGNDk3RCI+UmVnYXJkcyw8bzpwPjwvbzpwPjwv c3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEx LjBwdDtmb250LWZhbWlseTpDb25zb2xhcztjb2xvcjojMUY0OTdEIj5BbGJyZWNodDxvOnA+PC9v OnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNp emU6MTEuMHB0O2ZvbnQtZmFtaWx5OkNvbnNvbGFzO2NvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7 PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250 LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OkNvbnNvbGFzO2NvbG9yOiMxRjQ5N0QiPlBTPG86cD48 L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQt c2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6Q29uc29sYXM7Y29sb3I6IzFGNDk3RCI+VXNpbmcgKEQp VExTIHRlcm1pbm9sb2d5IGFjY29yZGluZyB0bw0KPGEgaHJlZj0iaHR0cDovL3Rvb2xzLmlldGYu b3JnL2lkL2RyYWZ0LWd1YmFsbGEtdGxzLXRlcm1pbm9sb2d5LTAxLnR4dCI+aHR0cDovL3Rvb2xz LmlldGYub3JnL2lkL2RyYWZ0LWd1YmFsbGEtdGxzLXRlcm1pbm9sb2d5LTAxLnR4dDwvYT4NCjxv OnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJm b250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OkNvbnNvbGFzO2NvbG9yOiMxRjQ5N0QiPjxvOnA+ Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxl PSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OkNvbnNvbGFzO2NvbG9yOiMxRjQ5N0QiPjxv OnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxkaXY+DQo8ZGl2IHN0eWxlPSJib3JkZXI6bm9u ZTtib3JkZXItdG9wOnNvbGlkICNCNUM0REYgMS4wcHQ7cGFkZGluZzozLjBwdCAwY20gMGNtIDBj bSI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48Yj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZv bnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7VGFob21hJnF1b3Q7LCZxdW90O3NhbnMt c2VyaWYmcXVvdDsiPkZyb206PC9zcGFuPjwvYj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZv bnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7VGFob21hJnF1b3Q7LCZxdW90O3NhbnMt c2VyaWYmcXVvdDsiPiBCZXJuYXJkIEFib2JhIFs8YSBocmVmPSJtYWlsdG86YmVybmFyZC5hYm9i YUBnbWFpbC5jb20iPm1haWx0bzpiZXJuYXJkLmFib2JhQGdtYWlsLmNvbTwvYT5dDQo8YnI+DQo8 Yj5TZW50OjwvYj4gTWl0dHdvY2gsIDUuIEF1Z3VzdCAyMDE1IDA0OjA0PGJyPg0KPGI+VG86PC9i PiBSb21hbiBTaHBvdW50PGJyPg0KPGI+Q2M6PC9iPiBBc3ZlcmVuLCBUb2xnYTsgQ2hyaXN0ZXIg SG9sbWJlcmc7IEVyaWMgUmVzY29ybGE7IFNjaHdhcnosIEFsYnJlY2h0IChBbGJyZWNodCk7IFJh dXNjaGVuYmFjaCwgVXdlIChOb2tpYSAtIERFL011bmljaCk7ICZsdDs8YSBocmVmPSJtYWlsdG86 cnRjd2ViQGlldGYub3JnIj5ydGN3ZWJAaWV0Zi5vcmc8L2E+Jmd0Ozxicj4NCjxiPlN1YmplY3Q6 PC9iPiBSZTogW3J0Y3dlYl0gV2hhdCB0aGUgZ2F0ZXdheSBkcmFmdCBzaG91bGQgc2F5IGFib3V0 IG11eC9ub24tbXV4PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPGRpdj4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPk9uIEF1ZyA0LCAyMDE1LCBhdCAxNjozMywgUm9tYW4gU2hwb3VudCAmbHQ7PGEg aHJlZj0ibWFpbHRvOnJvbWFuQHRlbHVyaXguY29tIj5yb21hbkB0ZWx1cml4LmNvbTwvYT4mZ3Q7 IHdyb3RlOjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8YmxvY2txdW90ZSBzdHlsZT0ibWFyZ2lu LXRvcDo1LjBwdDttYXJnaW4tYm90dG9tOjUuMHB0Ij4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj4NCjxk aXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0K PGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTomcXVv dDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6YmxhY2siPk1vc3Qg b2YgdGhlIHBlb3BsZSBpbXBsZW1lbnQgdGhpcyB3cm9uZywgc2luY2UgeW91IG5lZWQgdG8gY3Jl YXRlIHR3byBEVExTIHNlc3Npb25zOiBvbmUgZm9yIFJUUCBhbmQgYW5vdGhlciBmb3IgUlRDUC4g QW5kIHRoZW4gdXNlIGRpZmZlcmVudCBrZXlzIG9yIHBvc3NpYmx5IGV2ZW4gZW5jcnlwdGlvbg0K IHByb2ZpbGVzIGZvciBSVFAgYW5kIFJUQ1AuIEkgY29tbW9ubHkgc2VlIG9uZSBzZXNzaW9uIGZv ciBSVFAgYW5kIGtleXMgbmVnb3RpYXRlZCB0aGVyZSB1c2VkIGZvciBib3RoIFJUUCBhbmQgUlRD UCwgd2hpY2ggaXMgd3JvbmcuPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4N CjwvZGl2Pg0KPC9kaXY+DQo8L2Jsb2NrcXVvdGU+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpw PiZuYnNwOzwvbzpwPjwvcD4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5bQkFdIFllcywg dGhhdCBpcyBvbmx5IG9uZSBvZiBzZXZlcmFsIGNvbW1vbiBtaXN0YWtlcy4gJm5ic3A7VW5mb3J0 dW5hdGVseSwgUkZDIDU3NjQgZG9lcyBub3QgcnVsZSBvdXQgYWxsIG9mIHRoZXNlIGFuZCB0aGUg c2VjdXJpdHkgZG9jdW1lbnRzIGFyZSBub3QgY3J5c3RhbCBjbGVhciBvbiBob3cgdGhpbmdzIG11 c3QgYmUgZG9uZS4gSXQgaXMgbXVjaCBoYXJkZXIgdG8gbWVzcyB1cCBSVFAvUlRDUCBtdXguICZu YnNwO0dpdmVuDQogd2hhdCBJJ3ZlIHNlZW4gc28gZmFyLCBub24tbXV4IGNvdWxkIGJlY29tZSBh IHN1cHBvcnQgbmlnaHRtYXJlLiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4N CjwvYm9keT4NCjwvaHRtbD4NCg== --_000_786615F3A85DF44AA2A76164A71FE1AC7ADB91ECFR711WXCHMBA03z_-- From nobody Wed Aug 5 01:47:50 2015 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C16BB1B2DB0 for ; Wed, 5 Aug 2015 01:47:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.9 X-Spam-Level: X-Spam-Status: No, score=-6.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, 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 oilcf1XDXVfK for ; Wed, 5 Aug 2015 01:47:48 -0700 (PDT) Received: from demumfd002.nsn-inter.net (demumfd002.nsn-inter.net [93.183.12.31]) (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 AB69C1B2DCA for ; Wed, 5 Aug 2015 01:47:47 -0700 (PDT) Received: from demuprx016.emea.nsn-intra.net ([10.150.129.55]) by demumfd002.nsn-inter.net (8.15.1/8.15.1) with ESMTPS id t758lghH013001 (version=TLSv1 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Wed, 5 Aug 2015 08:47:43 GMT Received: from DEMUHTC002.nsn-intra.net ([10.159.42.33]) by demuprx016.emea.nsn-intra.net (8.12.11.20060308/8.12.11) with ESMTP id t758ldco010984 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Wed, 5 Aug 2015 10:47:39 +0200 Received: from DEMUHTC008.nsn-intra.net (10.159.42.39) by DEMUHTC002.nsn-intra.net (10.159.42.33) with Microsoft SMTP Server (TLS) id 14.3.248.2; Wed, 5 Aug 2015 10:47:39 +0200 Received: from DEMUMBX005.nsn-intra.net ([169.254.5.210]) by DEMUHTC008.nsn-intra.net ([10.159.42.39]) with mapi id 14.03.0248.002; Wed, 5 Aug 2015 10:47:38 +0200 From: "Rauschenbach, Uwe (Nokia - DE/Munich)" To: ext Eric Rescorla , "Schwarz, Albrecht (Albrecht)" Thread-Topic: [rtcweb] What the gateway draft should say about mux/non-mux Thread-Index: AQHQy78tkj01AbA0AUWp46tuxkqao531yJ8AgAABlICAACJYIP//4XCAgAAh7oCAA9BpAIAAQVMAgAMaYwA= Date: Wed, 5 Aug 2015 08:47:38 +0000 Message-ID: <56C2F665D49E0341B9DF5938005ACDF81970EDC1@DEMUMBX005.nsn-intra.net> References: <7594FB04B1934943A5C02806D1A2204B348E29DA@ESESSMB209.ericsson.se> <67196805-ED4E-49EA-83AA-3F4C37B5BC50@gmail.com> <7594FB04B1934943A5C02806D1A2204B348E2D52@ESESSMB209.ericsson.se> <56C2F665D49E0341B9DF5938005ACDF8196FF3ED@DEMUMBX005.nsn-intra.net> <56C2F665D49E0341B9DF5938005ACDF8196FF450@DEMUMBX005.nsn-intra.net> <786615F3A85DF44AA2A76164A71FE1AC7ADB690D@FR711WXCHMBA03.zeu.alcatel-lucent.com> In-Reply-To: Accept-Language: de-DE, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.159.42.155] Content-Type: multipart/alternative; boundary="_000_56C2F665D49E0341B9DF5938005ACDF81970EDC1DEMUMBX005nsnin_" MIME-Version: 1.0 X-purgate-type: clean X-purgate-Ad: Categorized by eleven eXpurgate (R) http://www.eleven.de X-purgate: clean X-purgate: This mail is considered clean (visit http://www.eleven.de for further information) X-purgate-size: 12648 X-purgate-ID: 151667::1438764463-0000676C-71F108E6/0/0 Archived-At: Cc: "" Subject: Re: [rtcweb] What the gateway draft should say about mux/non-mux X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 05 Aug 2015 08:47:49 -0000 --_000_56C2F665D49E0341B9DF5938005ACDF81970EDC1DEMUMBX005nsnin_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 DQoNCkZyb206IGV4dCBFcmljIFJlc2NvcmxhIFttYWlsdG86ZWtyQHJ0Zm0uY29tXQ0KU2VudDog TW9uZGF5LCBBdWd1c3QgMDMsIDIwMTUgMToxMyBQTQ0KDQpJIGRvbid0IHNlZSBob3cgdGhpcyBj b25jbHVzaW9uIGZvbGxvd3MuDQoNCkkgdGhpbmsgdGhpcyBnb2VzIGJhY2sgdG8gdGhlIHF1ZXN0 aW9uIFBldGVyIGFuZCBDdWxsZW4gaGF2ZSBiZWVuIGFza2luZy4gV2hhdA0KY29uY3JldGUgc2Nl bmFyaW8gKGkuZS4sIHJlYWwgZXF1aXBtZW50KSB3aWxsIGZhaWwgdG8gaW50ZXJvcGVyYXRlIGlm IHdlIHNpbXBsZSByZXF1aXJlDQpNVVggYWxsIHRoZSB0aW1lPw0KDQotRWtyDQoNCg0KSGVsbG8g RWtyLA0KDQpNZWRpYSBnYXRld2F5IGltcGxlbWVudGF0aW9ucyBhY2NvcmRpbmcgdG8gM0dQUCBU UyAyMy4yMjggbWF5IG5vdCBzdXBwb3J0IHJ0Y3AtbXV4LCBhcyBydGNwLW11eCBpcyBvcHRpb25h bCB0aGVyZS4NClNvIGlmIHdlIGRyb3Agbm9uLW11eCBzdXBwb3J0IGZyb20gd2ViIGJyb3dzZXJz LCB0aG9zZSBtZWRpYSBnYXRld2F5cyB0aGF0IGhhdmUgbm90IGltcGxlbWVudGVkIHJ0Y3AtbXV4 IHdpbGwgc3RvcCBpbnRlcm9wZXJhdGluZy4NCg0KRnJvbSBUUyAyMy4yMjg6DQpVLjEuMy4zICAg ZVAtQ1NDRiAoUC1DU0NGIGVuaGFuY2VkIGZvciBXZWJSVEMpDQpUaGUgUC1DU0NGIGVuaGFuY2Vk IGZvciBXZWJSVEMgKGVQLUNTQ0YpIGlzIGEgUC1DU0NGIGluY2x1ZGluZyB0aGUgSU1TLUFMRyBm dW5jdGlvbmFsaXR5IGFuZCB3aXRoIHRoZSBmb2xsb3dpbmcgYWRkaXRpb25hbCBmdW5jdGlvbnM6 DQoNCuKApg0KDQotICAgICBUaGUgZVAtQ1NDRiBzaGFsbCBlbnN1cmUgdmlhIHNpZ25hbGxpbmcg dGhhdCBSVFAgc3RyZWFtcyBhcmUgbm90IG11bHRpcGxleGVkICgiYnVuZGxlZCIpIG9udG8gdGhl IHNhbWUgcG9ydC4NCg0KLSAgICAgVGhlIGVQLUNTQ0Ygc2hhbGwgZW5zdXJlIHZpYSBzaWduYWxs aW5nIHRoYXQgUlRQIGFuZCBSVENQIGZsb3dzIG9mIGFuIFJUUCBzdHJlYW0gYXJlIG5vdCBtdWx0 aXBsZXhlZCBvbnRvIHRoZSBzYW1lIHBvcnQgaWYgZW50aXRpZXMgYW5jaG9yaW5nIHRoZSBzZXNz aW9uIG1lZGlhIHBhdGggaW4gdGhlIElNUyBkb21haW4gZG8gbm90IHN1cHBvcnQgdGhhdCBjYXBh YmlsaXR5Lg0KDQpLaW5kIHJlZ2FyZHMsDQpVd2UNCg== --_000_56C2F665D49E0341B9DF5938005ACDF81970EDC1DEMUMBX005nsnin_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTIgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 IkNhbWJyaWEgTWF0aCI7DQoJcGFub3NlLTE6MiA0IDUgMyA1IDQgNiAzIDIgNDt9DQpAZm9udC1m YWNlDQoJe2ZvbnQtZmFtaWx5OkNhbGlicmk7DQoJcGFub3NlLTE6MiAxNSA1IDIgMiAyIDQgMyAy IDQ7fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseTpUYWhvbWE7DQoJcGFub3NlLTE6MiAxMSA2 IDQgMyA1IDQgNCAyIDQ7fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseTpDb25zb2xhczsNCglw YW5vc2UtMToyIDExIDYgOSAyIDIgNCAzIDIgNDt9DQovKiBTdHlsZSBEZWZpbml0aW9ucyAqLw0K cC5Nc29Ob3JtYWwsIGxpLk1zb05vcm1hbCwgZGl2Lk1zb05vcm1hbA0KCXttYXJnaW46MGNtOw0K CW1hcmdpbi1ib3R0b206LjAwMDFwdDsNCglmb250LXNpemU6MTIuMHB0Ow0KCWZvbnQtZmFtaWx5 OiJUaW1lcyBOZXcgUm9tYW4iLCJzZXJpZiI7fQ0KaDMNCgl7bXNvLXN0eWxlLXByaW9yaXR5Ojk7 DQoJbXNvLXN0eWxlLWxpbms6IkhlYWRpbmcgMyBDaGFyIjsNCgltYXJnaW4tdG9wOjYuMHB0Ow0K CW1hcmdpbi1yaWdodDowY207DQoJbWFyZ2luLWJvdHRvbTo5LjBwdDsNCgltYXJnaW4tbGVmdDoy LjBjbTsNCgl0ZXh0LWluZGVudDotMi4wY207DQoJcGFnZS1icmVhay1hZnRlcjphdm9pZDsNCglw dW5jdHVhdGlvbi13cmFwOnNpbXBsZTsNCgl0ZXh0LWF1dG9zcGFjZTpub25lOw0KCWZvbnQtc2l6 ZToxNC4wcHQ7DQoJZm9udC1mYW1pbHk6IkFyaWFsIiwic2Fucy1zZXJpZiI7DQoJZm9udC13ZWln aHQ6bm9ybWFsO30NCmE6bGluaywgc3Bhbi5Nc29IeXBlcmxpbmsNCgl7bXNvLXN0eWxlLXByaW9y aXR5Ojk5Ow0KCWNvbG9yOmJsdWU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQphOnZp c2l0ZWQsIHNwYW4uTXNvSHlwZXJsaW5rRm9sbG93ZWQNCgl7bXNvLXN0eWxlLXByaW9yaXR5Ojk5 Ow0KCWNvbG9yOnB1cnBsZTsNCgl0ZXh0LWRlY29yYXRpb246dW5kZXJsaW5lO30NCnANCgl7bXNv LXN0eWxlLXByaW9yaXR5Ojk5Ow0KCW1zby1tYXJnaW4tdG9wLWFsdDphdXRvOw0KCW1hcmdpbi1y aWdodDowY207DQoJbXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG87DQoJbWFyZ2luLWxlZnQ6MGNt Ow0KCWZvbnQtc2l6ZToxMi4wcHQ7DQoJZm9udC1mYW1pbHk6IlRpbWVzIE5ldyBSb21hbiIsInNl cmlmIjt9DQpwcmUNCgl7bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCW1zby1zdHlsZS1saW5rOiJI VE1MIFByZWZvcm1hdHRlZCBDaGFyIjsNCgltYXJnaW46MGNtOw0KCW1hcmdpbi1ib3R0b206LjAw MDFwdDsNCglmb250LXNpemU6MTAuMHB0Ow0KCWZvbnQtZmFtaWx5OiJDb3VyaWVyIE5ldyI7fQ0K cC5Nc29BY2V0YXRlLCBsaS5Nc29BY2V0YXRlLCBkaXYuTXNvQWNldGF0ZQ0KCXttc28tc3R5bGUt cHJpb3JpdHk6OTk7DQoJbXNvLXN0eWxlLWxpbms6IkJhbGxvb24gVGV4dCBDaGFyIjsNCgltYXJn aW46MGNtOw0KCW1hcmdpbi1ib3R0b206LjAwMDFwdDsNCglmb250LXNpemU6OC4wcHQ7DQoJZm9u dC1mYW1pbHk6IlRhaG9tYSIsInNhbnMtc2VyaWYiO30NCnNwYW4uSFRNTFByZWZvcm1hdHRlZENo YXINCgl7bXNvLXN0eWxlLW5hbWU6IkhUTUwgUHJlZm9ybWF0dGVkIENoYXIiOw0KCW1zby1zdHls ZS1wcmlvcml0eTo5OTsNCgltc28tc3R5bGUtbGluazoiSFRNTCBQcmVmb3JtYXR0ZWQiOw0KCWZv bnQtZmFtaWx5OkNvbnNvbGFzO30NCnNwYW4uRW1haWxTdHlsZTIwDQoJe21zby1zdHlsZS10eXBl OnBlcnNvbmFsLXJlcGx5Ow0KCWZvbnQtZmFtaWx5OiJBcmlhbCIsInNhbnMtc2VyaWYiOw0KCWNv bG9yOndpbmRvd3RleHQ7fQ0Kc3Bhbi5CYWxsb29uVGV4dENoYXINCgl7bXNvLXN0eWxlLW5hbWU6 IkJhbGxvb24gVGV4dCBDaGFyIjsNCgltc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJbXNvLXN0eWxl LWxpbms6IkJhbGxvb24gVGV4dCI7DQoJZm9udC1mYW1pbHk6IlRhaG9tYSIsInNhbnMtc2VyaWYi O30NCnNwYW4uSGVhZGluZzNDaGFyDQoJe21zby1zdHlsZS1uYW1lOiJIZWFkaW5nIDMgQ2hhciI7 DQoJbXNvLXN0eWxlLXByaW9yaXR5Ojk7DQoJbXNvLXN0eWxlLWxpbms6IkhlYWRpbmcgMyI7DQoJ Zm9udC1mYW1pbHk6IkFyaWFsIiwic2Fucy1zZXJpZiI7fQ0KcC5CMSwgbGkuQjEsIGRpdi5CMQ0K CXttc28tc3R5bGUtbmFtZTpCMTsNCgltYXJnaW4tdG9wOjBjbTsNCgltYXJnaW4tcmlnaHQ6MGNt Ow0KCW1hcmdpbi1ib3R0b206OS4wcHQ7DQoJbWFyZ2luLWxlZnQ6MjguNHB0Ow0KCXRleHQtaW5k ZW50Oi0xNC4ycHQ7DQoJcHVuY3R1YXRpb24td3JhcDpzaW1wbGU7DQoJdGV4dC1hdXRvc3BhY2U6 bm9uZTsNCglmb250LXNpemU6MTAuMHB0Ow0KCWZvbnQtZmFtaWx5OiJUaW1lcyBOZXcgUm9tYW4i LCJzZXJpZiI7fQ0KcC5CMiwgbGkuQjIsIGRpdi5CMg0KCXttc28tc3R5bGUtbmFtZTpCMjsNCglt YXJnaW4tdG9wOjBjbTsNCgltYXJnaW4tcmlnaHQ6MGNtOw0KCW1hcmdpbi1ib3R0b206OS4wcHQ7 DQoJbWFyZ2luLWxlZnQ6NDIuNTVwdDsNCgl0ZXh0LWluZGVudDotMTQuMnB0Ow0KCXB1bmN0dWF0 aW9uLXdyYXA6c2ltcGxlOw0KCXRleHQtYXV0b3NwYWNlOm5vbmU7DQoJZm9udC1zaXplOjEwLjBw dDsNCglmb250LWZhbWlseToiVGltZXMgTmV3IFJvbWFuIiwic2VyaWYiO30NCi5Nc29DaHBEZWZh dWx0DQoJe21zby1zdHlsZS10eXBlOmV4cG9ydC1vbmx5O30NCkBwYWdlIFdvcmRTZWN0aW9uMQ0K CXtzaXplOjYxMi4wcHQgNzkyLjBwdDsNCgltYXJnaW46NzIuMHB0IDcyLjBwdCA3Mi4wcHQgNzIu MHB0O30NCmRpdi5Xb3JkU2VjdGlvbjENCgl7cGFnZTpXb3JkU2VjdGlvbjE7fQ0KLS0+PC9zdHls ZT48IS0tW2lmIGd0ZSBtc28gOV0+PHhtbD4NCjxvOnNoYXBlZGVmYXVsdHMgdjpleHQ9ImVkaXQi IHNwaWRtYXg9IjEwMjYiIC8+DQo8L3htbD48IVtlbmRpZl0tLT48IS0tW2lmIGd0ZSBtc28gOV0+ PHhtbD4NCjxvOnNoYXBlbGF5b3V0IHY6ZXh0PSJlZGl0Ij4NCjxvOmlkbWFwIHY6ZXh0PSJlZGl0 IiBkYXRhPSIxIiAvPg0KPC9vOnNoYXBlbGF5b3V0PjwveG1sPjwhW2VuZGlmXS0tPg0KPC9oZWFk Pg0KPGJvZHkgbGFuZz0iRU4tVVMiIGxpbms9ImJsdWUiIHZsaW5rPSJwdXJwbGUiPg0KPGRpdiBj bGFzcz0iV29yZFNlY3Rpb24xIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJm b250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7LCZxdW90O3NhbnMt c2VyaWYmcXVvdDsiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0Fy aWFsJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFu PjwvcD4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48 Yj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtUYWhvbWEm cXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+RnJvbTo8L3NwYW4+PC9iPjxzcGFuIHN0eWxl PSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O1RhaG9tYSZxdW90OywmcXVvdDtz YW5zLXNlcmlmJnF1b3Q7Ij4gZXh0IEVyaWMgUmVzY29ybGEgW21haWx0bzpla3JAcnRmbS5jb21d DQo8YnI+DQo8Yj5TZW50OjwvYj4gTW9uZGF5LCBBdWd1c3QgMDMsIDIwMTUgMToxMyBQTTxicj4N Cjxicj4NCjwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPkkgZG9uJ3Qgc2VlIGhvdyB0aGlzIGNvbmNsdXNpb24gZm9sbG93cy4mbmJzcDs8 bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+ Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+SSB0 aGluayB0aGlzIGdvZXMgYmFjayB0byB0aGUgcXVlc3Rpb24gUGV0ZXIgYW5kIEN1bGxlbiBoYXZl IGJlZW4gYXNraW5nLiBXaGF0PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj5jb25jcmV0ZSBzY2VuYXJpbyAoaS5lLiwgcmVhbCBlcXVpcG1lbnQpIHdp bGwgZmFpbCB0byBpbnRlcm9wZXJhdGUgaWYgd2Ugc2ltcGxlIHJlcXVpcmU8bzpwPjwvbzpwPjwv cD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPk1VWCBhbGwgdGhlIHRpbWU/ PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpw PiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPi1F a3I8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250 LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7LCZxdW90O3NhbnMtc2Vy aWYmcXVvdDsiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0FyaWFs JnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwv cD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2Zv bnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPkhlbGxv IEVrciw8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBz dHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtBcmlhbCZxdW90OywmcXVv dDtzYW5zLXNlcmlmJnF1b3Q7Ij48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTom cXVvdDtBcmlhbCZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij5NZWRpYSBnYXRld2F5IGlt cGxlbWVudGF0aW9ucyBhY2NvcmRpbmcgdG8gM0dQUCBUUyAyMy4yMjg8L3NwYW4+PHNwYW4gc3R5 bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVv dDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPg0KPC9zcGFuPjxzcGFuIHN0eWxlPSJm b250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7LCZxdW90O3NhbnMt c2VyaWYmcXVvdDsiPm1heSBub3Qgc3VwcG9ydCBydGNwLW11eCwgYXMgcnRjcC1tdXggaXMgb3B0 aW9uYWwgdGhlcmUuPC9zcGFuPjxzcGFuIGxhbmc9IkVOLUdCIiBzdHlsZT0iZm9udC1zaXplOjEw LjBwdDtmb250LWZhbWlseTomcXVvdDtBcmlhbCZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7 Ij48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHls ZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtBcmlhbCZxdW90OywmcXVvdDtz YW5zLXNlcmlmJnF1b3Q7Ij5TbyBpZiB3ZSBkcm9wIG5vbi1tdXggc3VwcG9ydCBmcm9tIHdlYiBi cm93c2VycywgdGhvc2UgbWVkaWEgZ2F0ZXdheXMgdGhhdCBoYXZlIG5vdCBpbXBsZW1lbnRlZCBy dGNwLW11eCB3aWxsIHN0b3AgaW50ZXJvcGVyYXRpbmcuPG86cD48L286cD48L3NwYW4+PC9wPg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1m YW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+PG86cD4mbmJz cDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZv bnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDssJnF1b3Q7c2Fucy1z ZXJpZiZxdW90OyI+RnJvbSBUUyAyMy4yMjg6PG86cD48L286cD48L3NwYW4+PC9wPg0KPGgzPjxh IG5hbWU9Il9Ub2M0MjIyNDU2MTAiPjxzcGFuIGxhbmc9IkVOLUdCIj5VLjEuMy4zJm5ic3A7Jm5i c3A7IGVQLUNTQ0YgKFAtQ1NDRiBlbmhhbmNlZCBmb3IgV2ViUlRDKTwvc3Bhbj48L2E+PHNwYW4g bGFuZz0iRU4tR0IiPjxvOnA+PC9vOnA+PC9zcGFuPjwvaDM+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij5UaGUgUC1DU0NGIGVuaGFuY2VkIGZvciBXZWJSVEMgKGVQLUNTQ0YpIGlzIGEgUC1DU0NGIGlu Y2x1ZGluZyB0aGUgSU1TLUFMRyBmdW5jdGlvbmFsaXR5IGFuZCB3aXRoIHRoZSBmb2xsb3dpbmcg YWRkaXRpb25hbCBmdW5jdGlvbnM6PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iQjIiPjxzcGFu IGxhbmc9IkVOLUdCIj7igKY8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iQjEiPjxz cGFuIGxhbmc9IkVOLUdCIj4tJm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IFRoZSBlUC1DU0NGIHNo YWxsIGVuc3VyZSB2aWEgc2lnbmFsbGluZyB0aGF0IFJUUCBzdHJlYW1zIGFyZSBub3QgbXVsdGlw bGV4ZWQgKCZxdW90O2J1bmRsZWQmcXVvdDspIG9udG8gdGhlIHNhbWUgcG9ydC48bzpwPjwvbzpw Pjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iQjEiPjxzcGFuIGxhbmc9IkVOLUdCIj4tJm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7IFRoZSBlUC1DU0NGIHNoYWxsIGVuc3VyZSB2aWEgc2lnbmFsbGluZyB0 aGF0IFJUUCBhbmQgUlRDUCBmbG93cyBvZiBhbiBSVFAgc3RyZWFtIGFyZSBub3QgbXVsdGlwbGV4 ZWQgb250byB0aGUgc2FtZSBwb3J0IGlmIGVudGl0aWVzIGFuY2hvcmluZyB0aGUgc2Vzc2lvbiBt ZWRpYSBwYXRoIGluIHRoZSBJTVMgZG9tYWluIGRvIG5vdCBzdXBwb3J0IHRoYXQgY2FwYWJpbGl0 eS48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5n PSJFTi1HQiIgc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwm cXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9w Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9u dC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+S2luZCBy ZWdhcmRzLDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFu IHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7LCZx dW90O3NhbnMtc2VyaWYmcXVvdDsiPlV3ZQ0KPG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+ DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvYm9keT4NCjwvaHRtbD4NCg== --_000_56C2F665D49E0341B9DF5938005ACDF81970EDC1DEMUMBX005nsnin_-- From nobody Wed Aug 5 01:58:27 2015 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8A7271B2DE1 for ; Wed, 5 Aug 2015 01:58:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7fugq8qrtA8c for ; Wed, 5 Aug 2015 01:58:25 -0700 (PDT) Received: from mail-wi0-x22d.google.com (mail-wi0-x22d.google.com [IPv6:2a00:1450:400c:c05::22d]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 316DE1B2DDE for ; Wed, 5 Aug 2015 01:58:25 -0700 (PDT) Received: by wijp15 with SMTP id p15so39034675wij.0 for ; Wed, 05 Aug 2015 01:58:24 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=subject:to:references:from:message-id:date:user-agent:mime-version :in-reply-to:content-type; bh=1DVqkD/eQ1d2rjnKNf2HtYN7xZWWYM4JTBT0117/XU0=; b=cEJVImX2NWhcmc7bFtGfcvpyYEpd4Kn8b8UkWng1pFO7lLm0NVFvrTL5LHbhWHHULq pUwWOqaORxt3M9A4K/1Opq37rb7PoiNXQVTFS4kIuRuGh2OxoPcb2ok1cD4IXQ9xC8xO Kz3Hp7vUjYyqWUgYj6hiZG1+GxFF1Y5npSUqlJQcCPjOL6kn0aR+z7ydGevLCRjNpOn/ 8bTBqrINMFtH0YMQlud0zcvhG5DT8m37LsyN/26EV0BXxdWsNbWgrXN7piIQJQ5Ri3H4 c5Dlp3niw5Zu+T++AJpukHOlJYPWc97vI5IJfZUMDgc5fp5b6rPnRlHoXdhBgobVzoUV cHWg== X-Received: by 10.194.238.193 with SMTP id vm1mr17439682wjc.57.1438765103944; Wed, 05 Aug 2015 01:58:23 -0700 (PDT) Received: from [192.168.1.35] (164.Red-79-153-234.dynamicIP.rima-tde.net. [79.153.234.164]) by smtp.googlemail.com with ESMTPSA id fm8sm6521059wib.9.2015.08.05.01.58.22 for (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 05 Aug 2015 01:58:22 -0700 (PDT) To: rtcweb@ietf.org References: <67196805-ED4E-49EA-83AA-3F4C37B5BC50@gmail.com> <7594FB04B1934943A5C02806D1A2204B348E2D52@ESESSMB209.ericsson.se> <56C2F665D49E0341B9DF5938005ACDF8196FF3ED@DEMUMBX005.nsn-intra.net> <56C2F665D49E0341B9DF5938005ACDF8196FF450@DEMUMBX005.nsn-intra.net> <786615F3A85DF44AA2A76164A71FE1AC7ADB690D@FR711WXCHMBA03.zeu.alcatel-lucent.com> <56C2F665D49E0341B9DF5938005ACDF81970EDC1@DEMUMBX005.nsn-intra.net> From: Sergio Garcia Murillo Message-ID: <55C1D02E.9000800@gmail.com> Date: Wed, 5 Aug 2015 10:58:22 +0200 User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.0.1 MIME-Version: 1.0 In-Reply-To: <56C2F665D49E0341B9DF5938005ACDF81970EDC1@DEMUMBX005.nsn-intra.net> Content-Type: multipart/alternative; boundary="------------060000080500030801070105" Archived-At: Subject: Re: [rtcweb] What the gateway draft should say about mux/non-mux X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 05 Aug 2015 08:58:26 -0000 This is a multi-part message in MIME format. --------------060000080500030801070105 Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit On 05/08/2015 10:47, Rauschenbach, Uwe (Nokia - DE/Munich) wrote: > > So if we drop non-mux support from web browsers, those media gateways > that have not implemented rtcp-mux will stop interoperating. > Hi Uwe! Then just mandate the media gateways to support RTCP muxing if DTLS is enabled on 3GPP TS 23.228.. ;) Let's be realistic, anyone implementing a media gateway compatible with WebRTC today and pretend to have an stable version while the WebRTC specs are not yet finish and in constant evolution is a bit naive, and IMHO that should not be a showstopper for this kind of changes on WebRTC. (Disclaimer: I am myself the lead developer of media gateway) Best regards Sergio --------------060000080500030801070105 Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: 7bit
On 05/08/2015 10:47, Rauschenbach, Uwe (Nokia - DE/Munich) wrote:

So if we drop non-mux support from web browsers, those media gateways that have not implemented rtcp-mux will stop interoperating.


Hi Uwe!

Then just mandate the media gateways to support RTCP muxing if DTLS is enabled on 3GPP TS 23.228.. ;)

Let's be realistic, anyone implementing a media gateway compatible with WebRTC today and pretend to have an stable version while the WebRTC specs are not yet finish and in constant evolution is a bit naive, and IMHO that should not be a showstopper for this kind of changes on WebRTC. (Disclaimer: I am myself the lead developer of media gateway)

Best regards
Sergio
--------------060000080500030801070105-- From nobody Wed Aug 5 05:27:40 2015 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 693C61A8A60; Wed, 5 Aug 2015 05:27:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, SPF_HELO_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5C048BG8RQSZ; Wed, 5 Aug 2015 05:27:34 -0700 (PDT) Received: from na01-bn1-obe.outbound.protection.outlook.com (mail-bn1on0689.outbound.protection.outlook.com [IPv6:2a01:111:f400:fc10::689]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 76B431B2B5B; Wed, 5 Aug 2015 05:27:34 -0700 (PDT) Received: from SN1PR0301MB1551.namprd03.prod.outlook.com (10.162.129.157) by SN1PR0301MB1551.namprd03.prod.outlook.com (10.162.129.157) with Microsoft SMTP Server (TLS) id 15.1.225.19; Wed, 5 Aug 2015 12:27:17 +0000 Received: from SN1PR0301MB1551.namprd03.prod.outlook.com ([10.162.129.157]) by SN1PR0301MB1551.namprd03.prod.outlook.com ([10.162.129.157]) with mapi id 15.01.0225.018; Wed, 5 Aug 2015 12:27:17 +0000 From: "Asveren, Tolga" To: Christer Holmberg , "Schwarz, Albrecht (Albrecht)" , "" Thread-Topic: [rtcweb] Number of DTLS sessions/DTLS connections; RE: What the gateway draft should say about mux/non-mux Thread-Index: AQHQz1aJ68xKiZ7z/U6fhCvknvfFMp39Ujzg Date: Wed, 5 Aug 2015 12:27:17 +0000 Message-ID: References: <7594FB04B1934943A5C02806D1A2204B348E82CA@ESESSMB209.ericsson.se> <05B3C43B-2823-4590-889E-7A192FC8A3AD@gmail.com> <786615F3A85DF44AA2A76164A71FE1AC7ADB9197@FR711WXCHMBA03.zeu.alcatel-lucent.com> <7594FB04B1934943A5C02806D1A2204B348E8E9F@ESESSMB209.ericsson.se> In-Reply-To: <7594FB04B1934943A5C02806D1A2204B348E8E9F@ESESSMB209.ericsson.se> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=tasveren@sonusnet.com; x-originating-ip: [50.182.164.80] x-microsoft-exchange-diagnostics: 1; SN1PR0301MB1551; 5:WO9Y3l6qmC64JGgcHULo66c8SZOc264bWfnYxXJVtgRd5pm7tfcyZvO5QsFtGtrRhUwyNz3lBhhnNrF8CCUe6mrIsAGDy0kRxwEW9nNiCPXynG2swy207yqJhjQSmSuef3umCTUqaidGmzZE6OQnfQ==; 24:hS1oorcdN/+xA/UzI1egH0kT0sRzj2MJja8xdzLraUjznHu6P+wUEPX2ONlzg5CJJgB6EMd+2NCehNWov/7HKaHWrOZpIYN4pB8YjKn28wk=; 20:6QnentSRke1Fi5Qgg+K+COePM35kObiV8b8QAHw6cBzuNNLmWqG4JPmdQaIA8OkUMzAvlTuV4UYTt7Sh57T9OA== x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:SN1PR0301MB1551; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(108003899814671); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(601004)(5005006)(3002001); SRVR:SN1PR0301MB1551; BCL:0; PCL:0; RULEID:; SRVR:SN1PR0301MB1551; x-forefront-prvs: 06592CCE58 x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(377454003)(199003)(189002)(52604005)(501624003)(24454002)(164054003)(4001540100001)(19617315012)(76176999)(19300405004)(64706001)(561944003)(66066001)(54356999)(19580405001)(50986999)(16236675004)(74316001)(10400500002)(101416001)(33656002)(19609705001)(46102003)(2656002)(87936001)(19625215002)(19580395003)(5001860100001)(5002640100001)(5001830100001)(97736004)(86362001)(189998001)(81156007)(5001770100001)(62966003)(99286002)(93886004)(77156002)(105586002)(5003600100002)(106356001)(40100003)(76576001)(122556002)(92566002)(77096005)(5001960100002)(68736005)(106116001)(102836002)(2900100001)(15975445007)(2950100001)(491001); DIR:OUT; SFP:1101; SCL:1; SRVR:SN1PR0301MB1551; H:SN1PR0301MB1551.namprd03.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; A:1; MX:1; LANG:en; received-spf: None (protection.outlook.com: sonusnet.com does not designate permitted sender hosts) Content-Type: multipart/alternative; boundary="_000_SN1PR0301MB15511B00C3FE2072E861B044B2750SN1PR0301MB1551_" MIME-Version: 1.0 X-OriginatorOrg: sonusnet.com X-MS-Exchange-CrossTenant-originalarrivaltime: 05 Aug 2015 12:27:17.5751 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 29a671dc-ed7e-4a54-b1e5-8da1eb495dc3 X-MS-Exchange-Transport-CrossTenantHeadersStamped: SN1PR0301MB1551 Archived-At: Cc: "TLS@ietf.org \(tls@ietf.org\)" Subject: Re: [rtcweb] Number of DTLS sessions/DTLS connections; RE: What the gateway draft should say about mux/non-mux X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 05 Aug 2015 12:27:38 -0000 --_000_SN1PR0301MB15511B00C3FE2072E861B044B2750SN1PR0301MB1551_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 WWVzLCBjb21wbGV0ZWx5IGFncmVlLg0KDQpBbmQgSSB0aGluayB3aGF0IEFsYnJlY2h0IHByb3Bv c2VzIGJlbG93IGlzIHRoZSByaWdodCB3YXkgb2YgYWRkcmVzc2luZyB0aGUg4oCcbm8tcnRjcC1t dXggaW1wbGVtZW50YXRpb24gZGlmZmljdWx0aWVz4oCdIHByb2JsZW06IEFkZGluZyBjbGFyaWZp Y2F0aW9ucy9hbWVuZG1lbnRzIGluIHRoZSByZXNwZWN0aXZlIG5vcm1hdGl2ZSBzcGVjaWZpY2F0 aW9uIHJhdGhlciB0aGFuIGRpc2FsbG93aW5nIGEgY29tYmluYXRpb24gaW4gYSBwcm9maWxlIGJl Y2F1c2UgaXQgaXMg4oCcY29uZnVzaW5n4oCdLg0KSG9uZXN0bHksIEkgdGhpbmsgdGhlIG51bWJl ciBvZiBEVExTIGNvbm5lY3Rpb25zIHRvIHVzZSwgd2hlbiBidW5kbGluZy9tdXhpbmcgaXMgbm90 IHVzZWQsIGlzIG5vdCByZWFsbHkgdGhhdCBoYXJkIHRvIGZpZ3VyZSBvdXQgKGZvciBzb21lYm9k eSB3aG8gYWN0dWFsbHkgdW5kZXJzdGFuZHMgdGhlIHdob2xlIHN0b3J5KSBidXQgb2J2aW91c2x5 IG5vIGhhcm0gb2YgYWRkaW5nIHNvbWUgY2xhcmlmaWNhdGlvbnMuIERhdGFDaGFubmVsIGFzcGVj dHMgbmVlZCB0byBiZSBjcmlzcGx5IHNwZWNpZmllZCB0aG91Z2guIFdoYXQgaXMgdGhlIG1haW4g YWR2YW50YWdlIG9mIGxldHRpbmcgRGF0YUNoYW5uZWwgcG90ZW50aWFsbHkgdXNlIG9uZSBvZiB0 aGUgZXhzaXRpbmcgRFRMUyBjb25uZWN0aW9ucz8gSnVzdCB0byBzYXZlIHNvbWUgdGltZSBvbiBu ZWdvdGlhdGlvbj8NCg0KVGhhbmtzLA0KVG9sZ2ENCg0KRnJvbTogcnRjd2ViIFttYWlsdG86cnRj d2ViLWJvdW5jZXNAaWV0Zi5vcmddIE9uIEJlaGFsZiBPZiBDaHJpc3RlciBIb2xtYmVyZw0KU2Vu dDogV2VkbmVzZGF5LCBBdWd1c3QgMDUsIDIwMTUgNDoxMyBBTQ0KVG86IFNjaHdhcnosIEFsYnJl Y2h0IChBbGJyZWNodCkgPGFsYnJlY2h0LnNjaHdhcnpAYWxjYXRlbC1sdWNlbnQuY29tPjsgPHJ0 Y3dlYkBpZXRmLm9yZz4gPHJ0Y3dlYkBpZXRmLm9yZz4NCkNjOiBUTFNAaWV0Zi5vcmcgKHRsc0Bp ZXRmLm9yZykgPHRsc0BpZXRmLm9yZz4NClN1YmplY3Q6IFJlOiBbcnRjd2ViXSBOdW1iZXIgb2Yg RFRMUyBzZXNzaW9ucy9EVExTIGNvbm5lY3Rpb25zOyBSRTogV2hhdCB0aGUgZ2F0ZXdheSBkcmFm dCBzaG91bGQgc2F5IGFib3V0IG11eC9ub24tbXV4DQoNCkhpLA0KDQpXZSBzaGFsbCBub3QgbWFr ZSBSRkMgNTc2NCBjb3JyZWN0aW9ucyBpbiB0aGUgUlRDV0VCIHNwZWNzLg0KDQpSZWdhcmRzLA0K DQpDaHJpc3Rlcg0KDQoNCg0KRnJvbTogcnRjd2ViIFttYWlsdG86cnRjd2ViLWJvdW5jZXNAaWV0 Zi5vcmddIE9uIEJlaGFsZiBPZiBTY2h3YXJ6LCBBbGJyZWNodCAoQWxicmVjaHQpDQpTZW50OiA1 LiBlbG9rdXV0YSAyMDE1IDExOjA0DQpUbzogPHJ0Y3dlYkBpZXRmLm9yZzxtYWlsdG86cnRjd2Vi QGlldGYub3JnPj4NCkNjOiBUTFNAaWV0Zi5vcmc8bWFpbHRvOlRMU0BpZXRmLm9yZz4gKHRsc0Bp ZXRmLm9yZzxtYWlsdG86dGxzQGlldGYub3JnPikNClN1YmplY3Q6IFtydGN3ZWJdIE51bWJlciBv ZiBEVExTIHNlc3Npb25zL0RUTFMgY29ubmVjdGlvbnM7IFJFOiBXaGF0IHRoZSBnYXRld2F5IGRy YWZ0IHNob3VsZCBzYXkgYWJvdXQgbXV4L25vbi1tdXgNCg0KUm9tYW4sIEJlcm5hcmQsDQpyaWdo dCwgUkZDIDU3NjQgaXMgdG9vIHZhZ3VlIG9uIHRoYXQgYXNwZWN0LiBUaGFua3MgZm9yIGNvbmZp cm1pbmcgdGhlIG51bWJlciBvZiBEVExTIHNlc3Npb25zLCB3aGljaCBpcyBpbmxpbmUgd2l0aCBv dXIgdW5kZXJzdGFuZGluZy4NCldvdWxkIGFwcHJlY2lhdGUgaWYgdGhpcyBjb3VsZCBiZSBzb21l d2hlcmUgZml4ZWQgaW4gYW4gcnRjd2ViIGRyYWZ0IGR1ZSB0byBzaWduaWZpY2FudCBzaWRlIGVm ZmVjdHMuDQpUaGlzIHRvcGljIGlzIGFsc28gYW4gb25nb2luZyBGQVEuDQoNClRoZSBtb3N0IHNp bXBsZSBjYXNlIGlzIGdpdmVuIGJ5IGEgc2NlbmFyaW8gd2l0aCB1c2FnZSBvZiBidW5kbGluZyBw bHVzIHVzYWdlIG9mIFJUUC9SVENQIHRyYW5zcG9ydCBtdWx0aXBsZXhpbmcsIGxlYWRpbmcgdG8g YSBzaW5nbGUgRFRMUyBzZXNzaW9uL0RUTFMgY29ubmVjdGlvbiwgd2hpY2ggY291bGQgYmUgdGhl biBhbHNvIHNoYXJlZCBmb3IgV2ViUlRDIGRhdGEuDQoNCkJvdGggY2FwYWJpbGl0aWVzIGFyZSBt YW5kYXRlZCBpbiB0aGUgcnRwIHVzYWdlIGRyYWZ0Og0KaHR0cHM6Ly90b29scy5pZXRmLm9yZy9o dG1sL2RyYWZ0LWlldGYtcnRjd2ViLXJ0cC11c2FnZS0yNSNzZWN0aW9uLTQuNA0KPT4gYnVuZGxp bmcNCmh0dHBzOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC1pZXRmLXJ0Y3dlYi1ydHAtdXNh Z2UtMjUjc2VjdGlvbi00LjUNCj0+IFJUUC9SVENQIHRyYW5zcG9ydCBtdWx0aXBsZXhpbmcNCg0K Tm93LCBJRiBidW5kbGluZyBpcyBub3QgdXNlZCBPUiBSVFAvUlRDUCB0cmFuc3BvcnQgbXVsdGlw bGV4aW5nIGlzIG5vdCB1c2VkIFRIRU4gdGhlcmUgd2lsbCBiZSBtb3JlIHRoYW4gb25lIERUTFMg c2Vzc2lvbi9EVExTIGNvbm5lY3Rpb24gKGVpdGhlciAyIG9yIDQgaW4gY2FzZSBvZiBhdWRpbyAm IHZpZGVvKS4NClJhaXNpbmcgdGhlIHF1ZXN0aW9uIHdoaWNoIERUTFMgY29ubmVjdGlvbiBpcyB1 c2VkIGZvciBhZGRpdGlvbmFsIFdlYlJUQyBkYXRhIHRyYWZmaWM/IC0gQmVjYXVzZQ0KaHR0cHM6 Ly90b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0LWlldGYtcnRjd2ViLXRyYW5zcG9ydHMtMDkjc2Vj dGlvbi0zLjUNCmluZGljYXRlcyB0aGUgc2hhcmluZyBvcHRpb24uDQpXb3VsZCB0aGVuIGJlIGEg M3JkIChvciA1dGgpIHNlbGYtY29udGFpbmVkIERUTFMgc2Vzc2lvbi9EVExTIGNvbm5lY3Rpb24g Zm9yIFdlYlJUQyBkYXRhIHRyYWZmaWM/DQoNClByb3Bvc2FsOg0KQWRkIGV4cGxpY2l0IHRleHQg dG8gY2xhdXNlIGh0dHBzOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC1pZXRmLXJ0Y3dlYi10 cmFuc3BvcnRzLTA5I3NlY3Rpb24tMy41DQphYm91dCAoaW4gcmVkKSwgc29tZXRoaW5nIGxpa2U6 DQoNCiAgIFdlYlJUQyBpbXBsZW1lbnRhdGlvbnMgTVVTVCBzdXBwb3J0IG11bHRpcGxleGluZyBv ZiBEVExTIGFuZCBSVFAgb3Zlcg0KICAgdGhlIHNhbWUgcG9ydCBwYWlyLCBhcyBkZXNjcmliZWQg aW4gdGhlIERUTFMtU1JUUCBzcGVjaWZpY2F0aW9uDQogICBbUkZDNTc2NF0sIHNlY3Rpb24gNS4x LjI8aHR0cHM6Ly90b29scy5pZXRmLm9yZy9odG1sL3JmYzU3NjQjc2VjdGlvbi01LjEuMj4uICBB bGwgYXBwbGljYXRpb24gbGF5ZXIgcHJvdG9jb2wgcGF5bG9hZHMNCiAgIG92ZXIgdGhpcyBEVExT IGNvbm5lY3Rpb24gYXJlIFNDVFAgcGFja2V0cy4NCg0KDQoNCiAgIE5vdGUgMTogVGhlcmUgd2ls bCBiZSB0d28gRFRMUyBzZXNzaW9ucy9EVExTIGNvbm5lY3Rpb25zIHdoZW4gUlRQL1JUQ1AgdHJh bnNwb3J0IG11bHRpcGxleGluZyBpcyBub3QgYXBwbGllZC4gV2ViUlRDIGRhdGEgdHJhZmZpYyBj b3VsZCBzdGlsbCBzaGFyZSBvbmUgb2YgdGhlc2UgRFRMUyBjb25uZWN0aW9ucyDigKYgKOKAnHdo aWNoIG9uZT/igJ0pIOKApiBvciBUaGVyZSBzaG91bGQgYmUgdGhlbiBhIHNlcGFyYXRlLCBzZWxm LWNvbnRhaW5lZCBEVExTIHNlc3Npb24vRFRMUyBjb25uZWN0aW9uIGVzdGFibGlzaGVkIGV4Y2x1 c2l2ZWx5IGZvciBXZWJSVEMgZGF0YS4NCg0KDQoNCiAgIE5vdGUgMjogVGhlcmUgYXJlIHNpbWls YXIgY29uc2lkZXJhdGlvbnMgaW4gY2FzZSBvZiBidW5kbGluZy4NCg0KICAgUHJvdG9jb2wgaWRl bnRpZmljYXRpb24gTVVTVCBiZSBzdXBwbGllZCBhcyBwYXJ0IG9mIHRoZSBEVExTDQogICBoYW5k c2hha2UsIGFzIHNwZWNpZmllZCBpbiBbSS1ELmlldGYtcnRjd2ViLWFscG48aHR0cHM6Ly90b29s cy5pZXRmLm9yZy9odG1sL2RyYWZ0LWlldGYtcnRjd2ViLXRyYW5zcG9ydHMtMDkjcmVmLUktRC5p ZXRmLXJ0Y3dlYi1hbHBuPl0uDQoNCkNvbW1lbnRzPw0KUmVnYXJkcywNCkFsYnJlY2h0DQoNClBT DQpVc2luZyAoRClUTFMgdGVybWlub2xvZ3kgYWNjb3JkaW5nIHRvIGh0dHA6Ly90b29scy5pZXRm Lm9yZy9pZC9kcmFmdC1ndWJhbGxhLXRscy10ZXJtaW5vbG9neS0wMS50eHQNCg0KDQpGcm9tOiBC ZXJuYXJkIEFib2JhIFttYWlsdG86YmVybmFyZC5hYm9iYUBnbWFpbC5jb21dDQpTZW50OiBNaXR0 d29jaCwgNS4gQXVndXN0IDIwMTUgMDQ6MDQNClRvOiBSb21hbiBTaHBvdW50DQpDYzogQXN2ZXJl biwgVG9sZ2E7IENocmlzdGVyIEhvbG1iZXJnOyBFcmljIFJlc2NvcmxhOyBTY2h3YXJ6LCBBbGJy ZWNodCAoQWxicmVjaHQpOyBSYXVzY2hlbmJhY2gsIFV3ZSAoTm9raWEgLSBERS9NdW5pY2gpOyA8 cnRjd2ViQGlldGYub3JnPG1haWx0bzpydGN3ZWJAaWV0Zi5vcmc+Pg0KU3ViamVjdDogUmU6IFty dGN3ZWJdIFdoYXQgdGhlIGdhdGV3YXkgZHJhZnQgc2hvdWxkIHNheSBhYm91dCBtdXgvbm9uLW11 eA0KDQpPbiBBdWcgNCwgMjAxNSwgYXQgMTY6MzMsIFJvbWFuIFNocG91bnQgPHJvbWFuQHRlbHVy aXguY29tPG1haWx0bzpyb21hbkB0ZWx1cml4LmNvbT4+IHdyb3RlOg0KDQpNb3N0IG9mIHRoZSBw ZW9wbGUgaW1wbGVtZW50IHRoaXMgd3JvbmcsIHNpbmNlIHlvdSBuZWVkIHRvIGNyZWF0ZSB0d28g RFRMUyBzZXNzaW9uczogb25lIGZvciBSVFAgYW5kIGFub3RoZXIgZm9yIFJUQ1AuIEFuZCB0aGVu IHVzZSBkaWZmZXJlbnQga2V5cyBvciBwb3NzaWJseSBldmVuIGVuY3J5cHRpb24gcHJvZmlsZXMg Zm9yIFJUUCBhbmQgUlRDUC4gSSBjb21tb25seSBzZWUgb25lIHNlc3Npb24gZm9yIFJUUCBhbmQg a2V5cyBuZWdvdGlhdGVkIHRoZXJlIHVzZWQgZm9yIGJvdGggUlRQIGFuZCBSVENQLCB3aGljaCBp cyB3cm9uZy4NCg0KW0JBXSBZZXMsIHRoYXQgaXMgb25seSBvbmUgb2Ygc2V2ZXJhbCBjb21tb24g bWlzdGFrZXMuICBVbmZvcnR1bmF0ZWx5LCBSRkMgNTc2NCBkb2VzIG5vdCBydWxlIG91dCBhbGwg b2YgdGhlc2UgYW5kIHRoZSBzZWN1cml0eSBkb2N1bWVudHMgYXJlIG5vdCBjcnlzdGFsIGNsZWFy IG9uIGhvdyB0aGluZ3MgbXVzdCBiZSBkb25lLiBJdCBpcyBtdWNoIGhhcmRlciB0byBtZXNzIHVw IFJUUC9SVENQIG11eC4gIEdpdmVuIHdoYXQgSSd2ZSBzZWVuIHNvIGZhciwgbm9uLW11eCBjb3Vs ZCBiZWNvbWUgYSBzdXBwb3J0IG5pZ2h0bWFyZS4NCg== --_000_SN1PR0301MB15511B00C3FE2072E861B044B2750SN1PR0301MB1551_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 IkNhbWJyaWEgTWF0aCI7DQoJcGFub3NlLTE6MiA0IDUgMyA1IDQgNiAzIDIgNDt9DQpAZm9udC1m YWNlDQoJe2ZvbnQtZmFtaWx5OkNhbGlicmk7DQoJcGFub3NlLTE6MiAxNSA1IDIgMiAyIDQgMyAy IDQ7fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseTpDb25zb2xhczsNCglwYW5vc2UtMToyIDEx IDYgOSAyIDIgNCAzIDIgNDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OlRhaG9tYTsNCglw YW5vc2UtMToyIDExIDYgNCAzIDUgNCA0IDIgNDt9DQovKiBTdHlsZSBEZWZpbml0aW9ucyAqLw0K cC5Nc29Ob3JtYWwsIGxpLk1zb05vcm1hbCwgZGl2Lk1zb05vcm1hbA0KCXttYXJnaW46MGluOw0K CW1hcmdpbi1ib3R0b206LjAwMDFwdDsNCglmb250LXNpemU6MTIuMHB0Ow0KCWZvbnQtZmFtaWx5 OiJUaW1lcyBOZXcgUm9tYW4iLHNlcmlmO30NCmE6bGluaywgc3Bhbi5Nc29IeXBlcmxpbmsNCgl7 bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCWNvbG9yOmJsdWU7DQoJdGV4dC1kZWNvcmF0aW9uOnVu ZGVybGluZTt9DQphOnZpc2l0ZWQsIHNwYW4uTXNvSHlwZXJsaW5rRm9sbG93ZWQNCgl7bXNvLXN0 eWxlLXByaW9yaXR5Ojk5Ow0KCWNvbG9yOnB1cnBsZTsNCgl0ZXh0LWRlY29yYXRpb246dW5kZXJs aW5lO30NCnByZQ0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJbXNvLXN0eWxlLWxpbms6IkhU TUwgUHJlZm9ybWF0dGVkIENoYXIiOw0KCW1hcmdpbjowaW47DQoJbWFyZ2luLWJvdHRvbTouMDAw MXB0Ow0KCWZvbnQtc2l6ZToxMC4wcHQ7DQoJZm9udC1mYW1pbHk6IkNvdXJpZXIgTmV3Ijt9DQpw Lk1zb0FjZXRhdGUsIGxpLk1zb0FjZXRhdGUsIGRpdi5Nc29BY2V0YXRlDQoJe21zby1zdHlsZS1w cmlvcml0eTo5OTsNCgltc28tc3R5bGUtbGluazoiQmFsbG9vbiBUZXh0IENoYXIiOw0KCW1hcmdp bjowaW47DQoJbWFyZ2luLWJvdHRvbTouMDAwMXB0Ow0KCWZvbnQtc2l6ZTo4LjBwdDsNCglmb250 LWZhbWlseToiVGFob21hIixzYW5zLXNlcmlmO30NCnAuTXNvTGlzdFBhcmFncmFwaCwgbGkuTXNv TGlzdFBhcmFncmFwaCwgZGl2Lk1zb0xpc3RQYXJhZ3JhcGgNCgl7bXNvLXN0eWxlLXByaW9yaXR5 OjM0Ow0KCW1hcmdpbi10b3A6MGluOw0KCW1hcmdpbi1yaWdodDowaW47DQoJbWFyZ2luLWJvdHRv bTowaW47DQoJbWFyZ2luLWxlZnQ6LjVpbjsNCgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJZm9u dC1zaXplOjEyLjBwdDsNCglmb250LWZhbWlseToiVGltZXMgTmV3IFJvbWFuIixzZXJpZjt9DQpz cGFuLkhUTUxQcmVmb3JtYXR0ZWRDaGFyDQoJe21zby1zdHlsZS1uYW1lOiJIVE1MIFByZWZvcm1h dHRlZCBDaGFyIjsNCgltc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJbXNvLXN0eWxlLWxpbms6IkhU TUwgUHJlZm9ybWF0dGVkIjsNCglmb250LWZhbWlseToiQ291cmllciBOZXciO30NCnNwYW4uQmFs bG9vblRleHRDaGFyDQoJe21zby1zdHlsZS1uYW1lOiJCYWxsb29uIFRleHQgQ2hhciI7DQoJbXNv LXN0eWxlLXByaW9yaXR5Ojk5Ow0KCW1zby1zdHlsZS1saW5rOiJCYWxsb29uIFRleHQiOw0KCWZv bnQtZmFtaWx5OiJUYWhvbWEiLHNhbnMtc2VyaWY7fQ0Kc3Bhbi5FbWFpbFN0eWxlMjINCgl7bXNv LXN0eWxlLXR5cGU6cGVyc29uYWw7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLHNhbnMtc2VyaWY7 DQoJY29sb3I6IzFGNDk3RDt9DQpzcGFuLkVtYWlsU3R5bGUyMw0KCXttc28tc3R5bGUtdHlwZTpw ZXJzb25hbDsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsc2Fucy1zZXJpZjsNCgljb2xvcjojMUY0 OTdEO30NCnNwYW4uRW1haWxTdHlsZTI0DQoJe21zby1zdHlsZS10eXBlOnBlcnNvbmFsLXJlcGx5 Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIixzYW5zLXNlcmlmOw0KCWNvbG9yOiMxRjQ5N0Q7fQ0K Lk1zb0NocERlZmF1bHQNCgl7bXNvLXN0eWxlLXR5cGU6ZXhwb3J0LW9ubHk7DQoJZm9udC1zaXpl OjEwLjBwdDt9DQpAcGFnZSBXb3JkU2VjdGlvbjENCgl7c2l6ZTo4LjVpbiAxMS4waW47DQoJbWFy Z2luOjEuMGluIDEuMGluIDEuMGluIDEuMGluO30NCmRpdi5Xb3JkU2VjdGlvbjENCgl7cGFnZTpX b3JkU2VjdGlvbjE7fQ0KLS0+PC9zdHlsZT48IS0tW2lmIGd0ZSBtc28gOV0+PHhtbD4NCjxvOnNo YXBlZGVmYXVsdHMgdjpleHQ9ImVkaXQiIHNwaWRtYXg9IjEwMjYiIC8+DQo8L3htbD48IVtlbmRp Zl0tLT48IS0tW2lmIGd0ZSBtc28gOV0+PHhtbD4NCjxvOnNoYXBlbGF5b3V0IHY6ZXh0PSJlZGl0 Ij4NCjxvOmlkbWFwIHY6ZXh0PSJlZGl0IiBkYXRhPSIxIiAvPg0KPC9vOnNoYXBlbGF5b3V0Pjwv eG1sPjwhW2VuZGlmXS0tPg0KPC9oZWFkPg0KPGJvZHkgbGFuZz0iRU4tVVMiIGxpbms9ImJsdWUi IHZsaW5rPSJwdXJwbGUiPg0KPGRpdiBjbGFzcz0iV29yZFNlY3Rpb24xIj4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90 O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEIj5ZZXMsIGNvbXBsZXRlbHkg YWdyZWUuPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4g c3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90Oyxz YW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFt aWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEIj5BbmQgSSB0 aGluayB3aGF0IEFsYnJlY2h0IHByb3Bvc2VzIGJlbG93IGlzIHRoZSByaWdodCB3YXkgb2YgYWRk cmVzc2luZyB0aGUg4oCcbm8tcnRjcC1tdXggaW1wbGVtZW50YXRpb24gZGlmZmljdWx0aWVz4oCd IHByb2JsZW06IEFkZGluZyBjbGFyaWZpY2F0aW9ucy9hbWVuZG1lbnRzDQogaW4gdGhlIHJlc3Bl Y3RpdmUgbm9ybWF0aXZlIHNwZWNpZmljYXRpb24gcmF0aGVyIHRoYW4gZGlzYWxsb3dpbmcgYSBj b21iaW5hdGlvbiBpbiBhIHByb2ZpbGUgYmVjYXVzZSBpdCBpcyDigJxjb25mdXNpbmfigJ0uDQo8 bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0i Zm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2Vy aWY7Y29sb3I6IzFGNDk3RCI+SG9uZXN0bHksIEkgdGhpbmsgdGhlIG51bWJlciBvZiBEVExTIGNv bm5lY3Rpb25zIHRvIHVzZSwgd2hlbiBidW5kbGluZy9tdXhpbmcgaXMgbm90IHVzZWQsIGlzIG5v dCByZWFsbHkgdGhhdCBoYXJkIHRvIGZpZ3VyZSBvdXQgKGZvciBzb21lYm9keSB3aG8gYWN0dWFs bHkgdW5kZXJzdGFuZHMNCiB0aGUgd2hvbGUgc3RvcnkpIGJ1dCBvYnZpb3VzbHkgbm8gaGFybSBv ZiBhZGRpbmcgc29tZSBjbGFyaWZpY2F0aW9ucy4gRGF0YUNoYW5uZWwgYXNwZWN0cyBuZWVkIHRv IGJlIGNyaXNwbHkgc3BlY2lmaWVkIHRob3VnaC4gV2hhdCBpcyB0aGUgbWFpbiBhZHZhbnRhZ2Ug b2YgbGV0dGluZyBEYXRhQ2hhbm5lbCBwb3RlbnRpYWxseSB1c2Ugb25lIG9mIHRoZSBleHNpdGlu ZyBEVExTIGNvbm5lY3Rpb25zPyBKdXN0IHRvIHNhdmUgc29tZSB0aW1lIG9uDQogbmVnb3RpYXRp b24/IDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0 eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fu cy1zZXJpZjtjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWls eTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RCI+VGhhbmtzLDxv OnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJm b250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJp Zjtjb2xvcjojMUY0OTdEIj5Ub2xnYTxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90 O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpw Pjwvc3Bhbj48L3A+DQo8ZGl2IHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItbGVmdDpzb2xpZCBi bHVlIDEuNXB0O3BhZGRpbmc6MGluIDBpbiAwaW4gNC4wcHQiPg0KPGRpdj4NCjxkaXYgc3R5bGU9 ImJvcmRlcjpub25lO2JvcmRlci10b3A6c29saWQgI0UxRTFFMSAxLjBwdDtwYWRkaW5nOjMuMHB0 IDBpbiAwaW4gMGluIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxiPjxzcGFuIHN0eWxlPSJmb250 LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZiI+ RnJvbTo8L3NwYW4+PC9iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5 OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZiI+IHJ0Y3dlYiBbbWFpbHRvOnJ0Y3dlYi1i b3VuY2VzQGlldGYub3JnXQ0KPGI+T24gQmVoYWxmIE9mIDwvYj5DaHJpc3RlciBIb2xtYmVyZzxi cj4NCjxiPlNlbnQ6PC9iPiBXZWRuZXNkYXksIEF1Z3VzdCAwNSwgMjAxNSA0OjEzIEFNPGJyPg0K PGI+VG86PC9iPiBTY2h3YXJ6LCBBbGJyZWNodCAoQWxicmVjaHQpICZsdDthbGJyZWNodC5zY2h3 YXJ6QGFsY2F0ZWwtbHVjZW50LmNvbSZndDs7ICZsdDtydGN3ZWJAaWV0Zi5vcmcmZ3Q7ICZsdDty dGN3ZWJAaWV0Zi5vcmcmZ3Q7PGJyPg0KPGI+Q2M6PC9iPiBUTFNAaWV0Zi5vcmcgKHRsc0BpZXRm Lm9yZykgJmx0O3Rsc0BpZXRmLm9yZyZndDs8YnI+DQo8Yj5TdWJqZWN0OjwvYj4gUmU6IFtydGN3 ZWJdIE51bWJlciBvZiBEVExTIHNlc3Npb25zL0RUTFMgY29ubmVjdGlvbnM7IFJFOiBXaGF0IHRo ZSBnYXRld2F5IGRyYWZ0IHNob3VsZCBzYXkgYWJvdXQgbXV4L25vbi1tdXg8bzpwPjwvbzpwPjwv c3Bhbj48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJz cDs8L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJGSSIgc3R5bGU9 ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNl cmlmO2NvbG9yOiMxRjQ5N0QiPkhpLDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPjxzcGFuIGxhbmc9IkZJIiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZh bWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RCI+PG86cD4m bmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9 ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNl cmlmO2NvbG9yOiMxRjQ5N0QiPldlIHNoYWxsIG5vdCBtYWtlIFJGQyA1NzY0IGNvcnJlY3Rpb25z IGluIHRoZSBSVENXRUIgc3BlY3MuPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7 Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+ PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6 MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjoj MUY0OTdEIj5SZWdhcmRzLDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGli cmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bh bj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBw dDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3 RCI+Q2hyaXN0ZXI8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48 c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1 b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9w Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9u dC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0QiPjxv OnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0 eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fu cy1zZXJpZjtjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8ZGl2 Pg0KPGRpdiBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLXRvcDpzb2xpZCAjQjVDNERGIDEuMHB0 O3BhZGRpbmc6My4wcHQgMGluIDBpbiAwaW4iPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGI+PHNw YW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7VGFob21hJnF1b3Q7 LHNhbnMtc2VyaWYiPkZyb206PC9zcGFuPjwvYj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBw dDtmb250LWZhbWlseTomcXVvdDtUYWhvbWEmcXVvdDssc2Fucy1zZXJpZiI+IHJ0Y3dlYiBbPGEg aHJlZj0ibWFpbHRvOnJ0Y3dlYi1ib3VuY2VzQGlldGYub3JnIj5tYWlsdG86cnRjd2ViLWJvdW5j ZXNAaWV0Zi5vcmc8L2E+XQ0KPGI+T24gQmVoYWxmIE9mIDwvYj5TY2h3YXJ6LCBBbGJyZWNodCAo QWxicmVjaHQpPGJyPg0KPGI+U2VudDo8L2I+IDUuIGVsb2t1dXRhIDIwMTUgMTE6MDQ8YnI+DQo8 Yj5Ubzo8L2I+ICZsdDs8YSBocmVmPSJtYWlsdG86cnRjd2ViQGlldGYub3JnIj5ydGN3ZWJAaWV0 Zi5vcmc8L2E+Jmd0Ozxicj4NCjxiPkNjOjwvYj4gPGEgaHJlZj0ibWFpbHRvOlRMU0BpZXRmLm9y ZyI+VExTQGlldGYub3JnPC9hPiAoPGEgaHJlZj0ibWFpbHRvOnRsc0BpZXRmLm9yZyI+dGxzQGll dGYub3JnPC9hPik8YnI+DQo8Yj5TdWJqZWN0OjwvYj4gW3J0Y3dlYl0gTnVtYmVyIG9mIERUTFMg c2Vzc2lvbnMvRFRMUyBjb25uZWN0aW9uczsgUkU6IFdoYXQgdGhlIGdhdGV3YXkgZHJhZnQgc2hv dWxkIHNheSBhYm91dCBtdXgvbm9uLW11eDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0K PC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJGSSI+PG86cD4mbmJzcDs8 L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tR0Ii IHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OkNvbnNvbGFzO2NvbG9yOiMxRjQ5 N0QiPlJvbWFuLCBCZXJuYXJkLDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPjxzcGFuIGxhbmc9IkVOLUdCIiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZh bWlseTpDb25zb2xhcztjb2xvcjojMUY0OTdEIj5yaWdodCwgUkZDIDU3NjQgaXMgdG9vIHZhZ3Vl IG9uIHRoYXQgYXNwZWN0LiBUaGFua3MgZm9yIGNvbmZpcm1pbmcgdGhlIG51bWJlciBvZiBEVExT IHNlc3Npb25zLCB3aGljaCBpcyBpbmxpbmUgd2l0aCBvdXIgdW5kZXJzdGFuZGluZy48bzpwPjwv bzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1HQiIg c3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6Q29uc29sYXM7Y29sb3I6IzFGNDk3 RCI+V291bGQgYXBwcmVjaWF0ZSBpZiB0aGlzIGNvdWxkIGJlIHNvbWV3aGVyZSBmaXhlZCBpbiBh biBydGN3ZWIgZHJhZnQgZHVlIHRvIHNpZ25pZmljYW50IHNpZGUgZWZmZWN0cy48bzpwPjwvbzpw Pjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1HQiIgc3R5 bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6Q29uc29sYXM7Y29sb3I6IzFGNDk3RCI+ VGhpcyB0b3BpYyBpcyBhbHNvIGFuIG9uZ29pbmcgRkFRLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLUdCIiBzdHlsZT0iZm9udC1zaXpl OjExLjBwdDtmb250LWZhbWlseTpDb25zb2xhcztjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwv bzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1HQiIg c3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6Q29uc29sYXM7Y29sb3I6IzFGNDk3 RCI+VGhlIG1vc3Qgc2ltcGxlIGNhc2UgaXMgZ2l2ZW4gYnkgYSBzY2VuYXJpbyB3aXRoIHVzYWdl IG9mIGJ1bmRsaW5nIHBsdXMgdXNhZ2Ugb2YgUlRQL1JUQ1AgdHJhbnNwb3J0IG11bHRpcGxleGlu ZywgbGVhZGluZyB0byBhIHNpbmdsZSBEVExTIHNlc3Npb24vRFRMUyBjb25uZWN0aW9uLA0KIHdo aWNoIGNvdWxkIGJlIHRoZW4gYWxzbyBzaGFyZWQgZm9yIFdlYlJUQyBkYXRhLjxvOnA+PC9vOnA+ PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLUdCIiBzdHls ZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTpDb25zb2xhcztjb2xvcjojMUY0OTdEIj48 bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBs YW5nPSJFTi1HQiIgc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6Q29uc29sYXM7 Y29sb3I6IzFGNDk3RCI+Qm90aCBjYXBhYmlsaXRpZXMgYXJlIG1hbmRhdGVkIGluIHRoZSBydHAg dXNhZ2UgZHJhZnQ6PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ PHNwYW4gbGFuZz0iRU4tR0IiIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OkNv bnNvbGFzO2NvbG9yOiMxRjQ5N0QiPjxhIGhyZWY9Imh0dHBzOi8vdG9vbHMuaWV0Zi5vcmcvaHRt bC9kcmFmdC1pZXRmLXJ0Y3dlYi1ydHAtdXNhZ2UtMjUjc2VjdGlvbi00LjQiPjxzcGFuIGxhbmc9 IkRFIj5odHRwczovL3Rvb2xzLmlldGYub3JnL2h0bWwvZHJhZnQtaWV0Zi1ydGN3ZWItcnRwLXVz YWdlLTI1I3NlY3Rpb24tNC40PC9zcGFuPjwvYT4NCjwvc3Bhbj48c3BhbiBsYW5nPSJERSIgc3R5 bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6Q29uc29sYXM7Y29sb3I6IzFGNDk3RCI+ PGJyPg0KPSZndDsgYnVuZGxpbmc8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj48c3BhbiBsYW5nPSJFTi1HQiIgc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1m YW1pbHk6Q29uc29sYXM7Y29sb3I6IzFGNDk3RCI+PGEgaHJlZj0iaHR0cHM6Ly90b29scy5pZXRm Lm9yZy9odG1sL2RyYWZ0LWlldGYtcnRjd2ViLXJ0cC11c2FnZS0yNSNzZWN0aW9uLTQuNSI+aHR0 cHM6Ly90b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0LWlldGYtcnRjd2ViLXJ0cC11c2FnZS0yNSNz ZWN0aW9uLTQuNTwvYT4NCjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPjxzcGFuIGxhbmc9IkVOLUdCIiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWls eTpDb25zb2xhcztjb2xvcjojMUY0OTdEIj49Jmd0OyBSVFAvUlRDUCB0cmFuc3BvcnQgbXVsdGlw bGV4aW5nPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4g bGFuZz0iRU4tR0IiIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OkNvbnNvbGFz O2NvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLUdCIiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250 LWZhbWlseTpDb25zb2xhcztjb2xvcjojMUY0OTdEIj5Ob3csIElGIGJ1bmRsaW5nIGlzIG5vdCB1 c2VkIE9SIFJUUC9SVENQIHRyYW5zcG9ydCBtdWx0aXBsZXhpbmcgaXMgbm90IHVzZWQgVEhFTiB0 aGVyZSB3aWxsIGJlIG1vcmUgdGhhbiBvbmUgRFRMUyBzZXNzaW9uL0RUTFMgY29ubmVjdGlvbiAo ZWl0aGVyIDIgb3IgNCBpbiBjYXNlDQogb2YgYXVkaW8gJmFtcDsgdmlkZW8pLjxvOnA+PC9vOnA+ PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLUdCIiBzdHls ZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTpDb25zb2xhcztjb2xvcjojMUY0OTdEIj5S YWlzaW5nIHRoZSBxdWVzdGlvbiB3aGljaCBEVExTIGNvbm5lY3Rpb24gaXMgdXNlZCBmb3IgYWRk aXRpb25hbCBXZWJSVEMgZGF0YSB0cmFmZmljPyAtIEJlY2F1c2U8bzpwPjwvbzpwPjwvc3Bhbj48 L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1HQiIgc3R5bGU9ImZvbnQt c2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6Q29uc29sYXM7Y29sb3I6IzFGNDk3RCI+PGEgaHJlZj0i aHR0cHM6Ly90b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0LWlldGYtcnRjd2ViLXRyYW5zcG9ydHMt MDkjc2VjdGlvbi0zLjUiPmh0dHBzOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC1pZXRmLXJ0 Y3dlYi10cmFuc3BvcnRzLTA5I3NlY3Rpb24tMy41PC9hPg0KPG86cD48L286cD48L3NwYW4+PC9w Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tR0IiIHN0eWxlPSJmb250LXNp emU6MTEuMHB0O2ZvbnQtZmFtaWx5OkNvbnNvbGFzO2NvbG9yOiMxRjQ5N0QiPmluZGljYXRlcyB0 aGUgc2hhcmluZyBvcHRpb24uPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+PHNwYW4gbGFuZz0iRU4tR0IiIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFt aWx5OkNvbnNvbGFzO2NvbG9yOiMxRjQ5N0QiPldvdWxkIHRoZW4gYmUgYSAzPHN1cD5yZDwvc3Vw PiAob3IgNTxzdXA+dGg8L3N1cD4pIHNlbGYtY29udGFpbmVkIERUTFMgc2Vzc2lvbi9EVExTIGNv bm5lY3Rpb24gZm9yIFdlYlJUQyBkYXRhIHRyYWZmaWM/PG86cD48L286cD48L3NwYW4+PC9wPg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tR0IiIHN0eWxlPSJmb250LXNpemU6 MTEuMHB0O2ZvbnQtZmFtaWx5OkNvbnNvbGFzO2NvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9v OnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLUdCIiBz dHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTpDb25zb2xhcztjb2xvcjojMUY0OTdE Ij5Qcm9wb3NhbDo8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48 c3BhbiBsYW5nPSJFTi1HQiIgc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6Q29u c29sYXM7Y29sb3I6IzFGNDk3RCI+QWRkIGV4cGxpY2l0IHRleHQgdG8gY2xhdXNlDQo8YSBocmVm PSJodHRwczovL3Rvb2xzLmlldGYub3JnL2h0bWwvZHJhZnQtaWV0Zi1ydGN3ZWItdHJhbnNwb3J0 cy0wOSNzZWN0aW9uLTMuNSI+DQpodHRwczovL3Rvb2xzLmlldGYub3JnL2h0bWwvZHJhZnQtaWV0 Zi1ydGN3ZWItdHJhbnNwb3J0cy0wOSNzZWN0aW9uLTMuNTwvYT4gPG86cD4NCjwvbzpwPjwvc3Bh bj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1HQiIgc3R5bGU9ImZv bnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6Q29uc29sYXM7Y29sb3I6IzFGNDk3RCI+YWJvdXQg KGluIHJlZCksIHNvbWV0aGluZyBsaWtlOjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLUdCIiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtm b250LWZhbWlseTpDb25zb2xhcztjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bh bj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1HQiIgc3R5bGU9ImZv bnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDsiPiZuYnNw OyZuYnNwOyBXZWJSVEMgaW1wbGVtZW50YXRpb25zIE1VU1Qgc3VwcG9ydCBtdWx0aXBsZXhpbmcg b2YgRFRMUyBhbmQgUlRQIG92ZXI8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj48c3BhbiBsYW5nPSJFTi1HQiIgc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1m YW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDsiPiZuYnNwOyZuYnNwOyB0aGUgc2FtZSBwb3J0 IHBhaXIsIGFzIGRlc2NyaWJlZCBpbiB0aGUgRFRMUy1TUlRQIHNwZWNpZmljYXRpb248bzpwPjwv bzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1HQiIg c3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVv dDsiPiZuYnNwOyZuYnNwOw0KPGEgaHJlZj0iaHR0cHM6Ly90b29scy5pZXRmLm9yZy9odG1sL3Jm YzU3NjQjc2VjdGlvbi01LjEuMiI+W1JGQzU3NjRdLCBzZWN0aW9uJm5ic3A7NS4xLjI8L2E+LiZu YnNwOyBBbGwgYXBwbGljYXRpb24gbGF5ZXIgcHJvdG9jb2wgcGF5bG9hZHM8bzpwPjwvbzpwPjwv c3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1HQiIgc3R5bGU9 ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDsiPiZu YnNwOyZuYnNwOyBvdmVyIHRoaXMgRFRMUyBjb25uZWN0aW9uIGFyZSBTQ1RQIHBhY2tldHMuPG86 cD48L286cD48L3NwYW4+PC9wPg0KPHByZT48c3BhbiBsYW5nPSJFTi1HQiI+PG86cD4mbmJzcDs8 L286cD48L3NwYW4+PC9wcmU+DQo8cHJlPjxzcGFuIGxhbmc9IkVOLUdCIiBzdHlsZT0iY29sb3I6 cmVkIj4mbmJzcDsmbmJzcDsgTm90ZSAxOiBUaGVyZSB3aWxsIGJlIHR3byBEVExTIHNlc3Npb25z L0RUTFMgY29ubmVjdGlvbnMgd2hlbiBSVFAvUlRDUCB0cmFuc3BvcnQgbXVsdGlwbGV4aW5nIGlz IG5vdCBhcHBsaWVkLiBXZWJSVEMgZGF0YSB0cmFmZmljIGNvdWxkIHN0aWxsIHNoYXJlIG9uZSBv ZiB0aGVzZSBEVExTIGNvbm5lY3Rpb25zIOKApiA8c3BhbiBzdHlsZT0iYmFja2dyb3VuZDp5ZWxs b3c7bXNvLWhpZ2hsaWdodDp5ZWxsb3ciPijigJx3aGljaCBvbmU/4oCdKTwvc3Bhbj4g4oCmIG9y IFRoZXJlIHNob3VsZCBiZSB0aGVuIGEgc2VwYXJhdGUsIHNlbGYtY29udGFpbmVkIERUTFMgc2Vz c2lvbi9EVExTIGNvbm5lY3Rpb24gZXN0YWJsaXNoZWQgZXhjbHVzaXZlbHkgZm9yIFdlYlJUQyBk YXRhLjxvOnA+PC9vOnA+PC9zcGFuPjwvcHJlPg0KPHByZT48c3BhbiBsYW5nPSJFTi1HQiIgc3R5 bGU9ImNvbG9yOnJlZCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wcmU+DQo8cHJlPjxzcGFu IGxhbmc9IkVOLUdCIiBzdHlsZT0iY29sb3I6cmVkIj4mbmJzcDsmbmJzcDsgTm90ZSAyOiBUaGVy ZSBhcmUgc2ltaWxhciBjb25zaWRlcmF0aW9ucyBpbiBjYXNlIG9mIGJ1bmRsaW5nLjwvc3Bhbj48 c3BhbiBsYW5nPSJFTi1HQiI+PG86cD48L286cD48L3NwYW4+PC9wcmU+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj48c3BhbiBsYW5nPSJFTi1HQiIgc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1m YW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDsiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwv cD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLUdCIiBzdHlsZT0iZm9udC1z aXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90OyI+Jm5ic3A7Jm5i c3A7IFByb3RvY29sIGlkZW50aWZpY2F0aW9uIE1VU1QgYmUgc3VwcGxpZWQgYXMgcGFydCBvZiB0 aGUgRFRMUzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFu IGxhbmc9IkVOLUdCIiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtD b3VyaWVyIE5ldyZxdW90OyI+Jm5ic3A7Jm5ic3A7IGhhbmRzaGFrZSwgYXMgc3BlY2lmaWVkIGlu IFs8YSBocmVmPSJodHRwczovL3Rvb2xzLmlldGYub3JnL2h0bWwvZHJhZnQtaWV0Zi1ydGN3ZWIt dHJhbnNwb3J0cy0wOSNyZWYtSS1ELmlldGYtcnRjd2ViLWFscG4iPkktRC5pZXRmLXJ0Y3dlYi1h bHBuPC9hPl0uPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNw YW4gbGFuZz0iRU4tR0IiIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OkNvbnNv bGFzO2NvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLUdCIiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtm b250LWZhbWlseTpDb25zb2xhcztjb2xvcjojMUY0OTdEIj5Db21tZW50cz88bzpwPjwvbzpwPjwv c3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1HQiIgc3R5bGU9 ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6Q29uc29sYXM7Y29sb3I6IzFGNDk3RCI+UmVn YXJkcyw8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBs YW5nPSJFTi1HQiIgc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6Q29uc29sYXM7 Y29sb3I6IzFGNDk3RCI+QWxicmVjaHQ8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1HQiIgc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9u dC1mYW1pbHk6Q29uc29sYXM7Y29sb3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+ PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tR0IiIHN0eWxlPSJmb250 LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OkNvbnNvbGFzO2NvbG9yOiMxRjQ5N0QiPlBTPG86cD48 L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tR0Ii IHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OkNvbnNvbGFzO2NvbG9yOiMxRjQ5 N0QiPlVzaW5nIChEKVRMUyB0ZXJtaW5vbG9neSBhY2NvcmRpbmcgdG8NCjxhIGhyZWY9Imh0dHA6 Ly90b29scy5pZXRmLm9yZy9pZC9kcmFmdC1ndWJhbGxhLXRscy10ZXJtaW5vbG9neS0wMS50eHQi Pmh0dHA6Ly90b29scy5pZXRmLm9yZy9pZC9kcmFmdC1ndWJhbGxhLXRscy10ZXJtaW5vbG9neS0w MS50eHQ8L2E+DQo8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48 c3BhbiBsYW5nPSJFTi1HQiIgc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6Q29u c29sYXM7Y29sb3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tR0IiIHN0eWxlPSJmb250LXNpemU6MTEuMHB0 O2ZvbnQtZmFtaWx5OkNvbnNvbGFzO2NvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9z cGFuPjwvcD4NCjxkaXY+DQo8ZGl2IHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItdG9wOnNvbGlk ICNCNUM0REYgMS4wcHQ7cGFkZGluZzozLjBwdCAwaW4gMGluIDBpbiI+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj48Yj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVv dDtUYWhvbWEmcXVvdDssc2Fucy1zZXJpZiI+RnJvbTo8L3NwYW4+PC9iPjxzcGFuIHN0eWxlPSJm b250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O1RhaG9tYSZxdW90OyxzYW5zLXNlcmlm Ij4gQmVybmFyZCBBYm9iYSBbPGEgaHJlZj0ibWFpbHRvOmJlcm5hcmQuYWJvYmFAZ21haWwuY29t Ij5tYWlsdG86YmVybmFyZC5hYm9iYUBnbWFpbC5jb208L2E+XQ0KPGJyPg0KPGI+U2VudDo8L2I+ IE1pdHR3b2NoLCA1LiBBdWd1c3QgMjAxNSAwNDowNDxicj4NCjxiPlRvOjwvYj4gUm9tYW4gU2hw b3VudDxicj4NCjxiPkNjOjwvYj4gQXN2ZXJlbiwgVG9sZ2E7IENocmlzdGVyIEhvbG1iZXJnOyBF cmljIFJlc2NvcmxhOyBTY2h3YXJ6LCBBbGJyZWNodCAoQWxicmVjaHQpOyBSYXVzY2hlbmJhY2gs IFV3ZSAoTm9raWEgLSBERS9NdW5pY2gpOyAmbHQ7PGEgaHJlZj0ibWFpbHRvOnJ0Y3dlYkBpZXRm Lm9yZyI+cnRjd2ViQGlldGYub3JnPC9hPiZndDs8YnI+DQo8Yj5TdWJqZWN0OjwvYj4gUmU6IFty dGN3ZWJdIFdoYXQgdGhlIGdhdGV3YXkgZHJhZnQgc2hvdWxkIHNheSBhYm91dCBtdXgvbm9uLW11 eDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj48c3BhbiBsYW5nPSJFTi1HQiI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPGRp dj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLUdCIj5PbiBBdWcgNCwgMjAx NSwgYXQgMTY6MzMsIFJvbWFuIFNocG91bnQgJmx0OzxhIGhyZWY9Im1haWx0bzpyb21hbkB0ZWx1 cml4LmNvbSI+cm9tYW5AdGVsdXJpeC5jb208L2E+Jmd0OyB3cm90ZTo8bzpwPjwvbzpwPjwvc3Bh bj48L3A+DQo8L2Rpdj4NCjxibG9ja3F1b3RlIHN0eWxlPSJtYXJnaW4tdG9wOjUuMHB0O21hcmdp bi1ib3R0b206NS4wcHQiPg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLUdCIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+ DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1HQiIg c3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjpi bGFjayI+TW9zdCBvZiB0aGUgcGVvcGxlIGltcGxlbWVudCB0aGlzIHdyb25nLCBzaW5jZSB5b3Ug bmVlZCB0byBjcmVhdGUgdHdvIERUTFMgc2Vzc2lvbnM6IG9uZSBmb3IgUlRQIGFuZCBhbm90aGVy IGZvciBSVENQLiBBbmQgdGhlbiB1c2UgZGlmZmVyZW50IGtleXMgb3IgcG9zc2libHkgZXZlbg0K IGVuY3J5cHRpb24gcHJvZmlsZXMgZm9yIFJUUCBhbmQgUlRDUC4gSSBjb21tb25seSBzZWUgb25l IHNlc3Npb24gZm9yIFJUUCBhbmQga2V5cyBuZWdvdGlhdGVkIHRoZXJlIHVzZWQgZm9yIGJvdGgg UlRQIGFuZCBSVENQLCB3aGljaCBpcyB3cm9uZy48L3NwYW4+PHNwYW4gbGFuZz0iRU4tR0IiPjxv OnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9i bG9ja3F1b3RlPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tR0IiPjxvOnA+ Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3Bh biBsYW5nPSJFTi1HQiI+W0JBXSBZZXMsIHRoYXQgaXMgb25seSBvbmUgb2Ygc2V2ZXJhbCBjb21t b24gbWlzdGFrZXMuICZuYnNwO1VuZm9ydHVuYXRlbHksIFJGQyA1NzY0IGRvZXMgbm90IHJ1bGUg b3V0IGFsbCBvZiB0aGVzZSBhbmQgdGhlIHNlY3VyaXR5IGRvY3VtZW50cyBhcmUgbm90IGNyeXN0 YWwgY2xlYXIgb24gaG93IHRoaW5ncyBtdXN0IGJlIGRvbmUuIEl0IGlzIG11Y2ggaGFyZGVyIHRv IG1lc3MgdXANCiBSVFAvUlRDUCBtdXguICZuYnNwO0dpdmVuIHdoYXQgSSd2ZSBzZWVuIHNvIGZh ciwgbm9uLW11eCBjb3VsZCBiZWNvbWUgYSBzdXBwb3J0IG5pZ2h0bWFyZS4mbmJzcDs8bzpwPjwv bzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2JvZHk+DQo8L2h0bWw+ DQo= --_000_SN1PR0301MB15511B00C3FE2072E861B044B2750SN1PR0301MB1551_-- From nobody Wed Aug 5 05:39:20 2015 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F23571B2E41; Wed, 5 Aug 2015 05:39:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.2 X-Spam-Level: X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id r6fmQIGrG47I; Wed, 5 Aug 2015 05:39:16 -0700 (PDT) Received: from sessmg22.ericsson.net (sessmg22.ericsson.net [193.180.251.58]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 998001A89C5; Wed, 5 Aug 2015 05:39:14 -0700 (PDT) X-AuditID: c1b4fb3a-f79356d000006281-96-55c203f0936d Received: from ESESSHC008.ericsson.se (Unknown_Domain [153.88.253.124]) by sessmg22.ericsson.net (Symantec Mail Security) with SMTP id F6.E4.25217.0F302C55; Wed, 5 Aug 2015 14:39:12 +0200 (CEST) Received: from ESESSMB209.ericsson.se ([169.254.9.36]) by ESESSHC008.ericsson.se ([153.88.183.42]) with mapi id 14.03.0210.002; Wed, 5 Aug 2015 14:39:12 +0200 From: Christer Holmberg To: "Asveren, Tolga" , "Schwarz, Albrecht (Albrecht)" , "" Thread-Topic: [rtcweb] Number of DTLS sessions/DTLS connections; RE: What the gateway draft should say about mux/non-mux Thread-Index: AQHQz1VVWzrNLwNmjUSvQIGN1uVQpZ39Df+ggAAl8YCAACS3wA== Date: Wed, 5 Aug 2015 12:39:10 +0000 Message-ID: <7594FB04B1934943A5C02806D1A2204B348E9576@ESESSMB209.ericsson.se> References: <7594FB04B1934943A5C02806D1A2204B348E82CA@ESESSMB209.ericsson.se> <05B3C43B-2823-4590-889E-7A192FC8A3AD@gmail.com> <786615F3A85DF44AA2A76164A71FE1AC7ADB9197@FR711WXCHMBA03.zeu.alcatel-lucent.com> <7594FB04B1934943A5C02806D1A2204B348E8E9F@ESESSMB209.ericsson.se> 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.16] Content-Type: multipart/alternative; boundary="_000_7594FB04B1934943A5C02806D1A2204B348E9576ESESSMB209erics_" MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFprKIsWRmVeSWpSXmKPExsUyM+Jvje4H5kOhBhsuaFn8af3FaLH2Xzu7 xezO90wWn853MTqweLQ+28vqsWTJTyaPS5//swcwR3HZpKTmZJalFunbJXBl9C9eyFTwaAlT xbxTG9kaGHvmMnUxcnJICJhI9P39zghhi0lcuLeeDcQWEjjKKLHmUngXIxeQvYhR4tbSJ0AN HBxsAhYS3f+0QeIiArMZJVZ/OAU2iFnAQOLvietgg4QFqiQOzrvPCmKLCFRLPDh1nR3CdpL4 0jGZGWQOi4CKxM5zfiBhXgFfiXOrVrBA7HrMIvF4zx+wIzgFEiUe71sANp8R6Ljvp9ZA7RKX uPVkPtQDAhJL9pxnhrBFJV4+/scKYStK7DzbzgxRny/x8tdSVohlghInZz5hmcAoOgvJqFlI ymYhKZsFdCqzgKbE+l36ECWKElO6H7JD2BoSrXPmsiOLL2BkX8UoWpxaXJybbmSkl1qUmVxc nJ+nl5dasokRGI8Ht/y22sF48LnjIUYBDkYlHl6FvIOhQqyJZcWVuYcYpTlYlMR5Z2zOCxUS SE8sSc1OTS1ILYovKs1JLT7EyMTBKdXA6La67PucjdlxH3fM/fHyV0nCv4smShcOqNZfenls 5gchzist1ZZBVxfFZx25krZnpV/EttxHpve5jKRPvc7UizEXntRy7UnIkxnRe63imUNv7A7J bCh8oXH1s9zUg9uVhZ6JxpxaEMzW2s0vkB7Go6gdtITfyCP/X9CVBeUl/Jd16vhfLTc+pMRS nJFoqMVcVJwIAISUnwSoAgAA Archived-At: Cc: "TLS@ietf.org \(tls@ietf.org\)" Subject: Re: [rtcweb] Number of DTLS sessions/DTLS connections; RE: What the gateway draft should say about mux/non-mux X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 05 Aug 2015 12:39:19 -0000 --_000_7594FB04B1934943A5C02806D1A2204B348E9576ESESSMB209erics_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SGksDQoNCkkgZ3Vlc3Mgd2UgY291bGQgYWRkIHNvbWUgY2xhcmlmaWNhdGlvbiB0ZXh0IHRvIHRo ZSBTRFAtRFRMUyBkcmFmdC4NCg0KUmVnYXJkcywNCg0KQ2hyaXN0ZXINCg0KRnJvbTogQXN2ZXJl biwgVG9sZ2EgW21haWx0bzp0YXN2ZXJlbkBzb251c25ldC5jb21dDQpTZW50OiA1LiBlbG9rdXV0 YSAyMDE1IDE1OjI3DQpUbzogQ2hyaXN0ZXIgSG9sbWJlcmc7IFNjaHdhcnosIEFsYnJlY2h0IChB bGJyZWNodCk7IDxydGN3ZWJAaWV0Zi5vcmc+DQpDYzogVExTQGlldGYub3JnICh0bHNAaWV0Zi5v cmcpDQpTdWJqZWN0OiBSRTogW3J0Y3dlYl0gTnVtYmVyIG9mIERUTFMgc2Vzc2lvbnMvRFRMUyBj b25uZWN0aW9uczsgUkU6IFdoYXQgdGhlIGdhdGV3YXkgZHJhZnQgc2hvdWxkIHNheSBhYm91dCBt dXgvbm9uLW11eA0KDQpZZXMsIGNvbXBsZXRlbHkgYWdyZWUuDQoNCkFuZCBJIHRoaW5rIHdoYXQg QWxicmVjaHQgcHJvcG9zZXMgYmVsb3cgaXMgdGhlIHJpZ2h0IHdheSBvZiBhZGRyZXNzaW5nIHRo ZSDigJxuby1ydGNwLW11eCBpbXBsZW1lbnRhdGlvbiBkaWZmaWN1bHRpZXPigJ0gcHJvYmxlbTog QWRkaW5nIGNsYXJpZmljYXRpb25zL2FtZW5kbWVudHMgaW4gdGhlIHJlc3BlY3RpdmUgbm9ybWF0 aXZlIHNwZWNpZmljYXRpb24gcmF0aGVyIHRoYW4gZGlzYWxsb3dpbmcgYSBjb21iaW5hdGlvbiBp biBhIHByb2ZpbGUgYmVjYXVzZSBpdCBpcyDigJxjb25mdXNpbmfigJ0uDQpIb25lc3RseSwgSSB0 aGluayB0aGUgbnVtYmVyIG9mIERUTFMgY29ubmVjdGlvbnMgdG8gdXNlLCB3aGVuIGJ1bmRsaW5n L211eGluZyBpcyBub3QgdXNlZCwgaXMgbm90IHJlYWxseSB0aGF0IGhhcmQgdG8gZmlndXJlIG91 dCAoZm9yIHNvbWVib2R5IHdobyBhY3R1YWxseSB1bmRlcnN0YW5kcyB0aGUgd2hvbGUgc3Rvcnkp IGJ1dCBvYnZpb3VzbHkgbm8gaGFybSBvZiBhZGRpbmcgc29tZSBjbGFyaWZpY2F0aW9ucy4gRGF0 YUNoYW5uZWwgYXNwZWN0cyBuZWVkIHRvIGJlIGNyaXNwbHkgc3BlY2lmaWVkIHRob3VnaC4gV2hh dCBpcyB0aGUgbWFpbiBhZHZhbnRhZ2Ugb2YgbGV0dGluZyBEYXRhQ2hhbm5lbCBwb3RlbnRpYWxs eSB1c2Ugb25lIG9mIHRoZSBleHNpdGluZyBEVExTIGNvbm5lY3Rpb25zPyBKdXN0IHRvIHNhdmUg c29tZSB0aW1lIG9uIG5lZ290aWF0aW9uPw0KDQpUaGFua3MsDQpUb2xnYQ0KDQpGcm9tOiBydGN3 ZWIgW21haWx0bzpydGN3ZWItYm91bmNlc0BpZXRmLm9yZ10gT24gQmVoYWxmIE9mIENocmlzdGVy IEhvbG1iZXJnDQpTZW50OiBXZWRuZXNkYXksIEF1Z3VzdCAwNSwgMjAxNSA0OjEzIEFNDQpUbzog U2Nod2FyeiwgQWxicmVjaHQgKEFsYnJlY2h0KSA8YWxicmVjaHQuc2Nod2FyekBhbGNhdGVsLWx1 Y2VudC5jb208bWFpbHRvOmFsYnJlY2h0LnNjaHdhcnpAYWxjYXRlbC1sdWNlbnQuY29tPj47IDxy dGN3ZWJAaWV0Zi5vcmc8bWFpbHRvOnJ0Y3dlYkBpZXRmLm9yZz4+IDxydGN3ZWJAaWV0Zi5vcmc8 bWFpbHRvOnJ0Y3dlYkBpZXRmLm9yZz4+DQpDYzogVExTQGlldGYub3JnPG1haWx0bzpUTFNAaWV0 Zi5vcmc+ICh0bHNAaWV0Zi5vcmc8bWFpbHRvOnRsc0BpZXRmLm9yZz4pIDx0bHNAaWV0Zi5vcmc8 bWFpbHRvOnRsc0BpZXRmLm9yZz4+DQpTdWJqZWN0OiBSZTogW3J0Y3dlYl0gTnVtYmVyIG9mIERU TFMgc2Vzc2lvbnMvRFRMUyBjb25uZWN0aW9uczsgUkU6IFdoYXQgdGhlIGdhdGV3YXkgZHJhZnQg c2hvdWxkIHNheSBhYm91dCBtdXgvbm9uLW11eA0KDQpIaSwNCg0KV2Ugc2hhbGwgbm90IG1ha2Ug UkZDIDU3NjQgY29ycmVjdGlvbnMgaW4gdGhlIFJUQ1dFQiBzcGVjcy4NCg0KUmVnYXJkcywNCg0K Q2hyaXN0ZXINCg0KDQoNCkZyb206IHJ0Y3dlYiBbbWFpbHRvOnJ0Y3dlYi1ib3VuY2VzQGlldGYu b3JnXSBPbiBCZWhhbGYgT2YgU2Nod2FyeiwgQWxicmVjaHQgKEFsYnJlY2h0KQ0KU2VudDogNS4g ZWxva3V1dGEgMjAxNSAxMTowNA0KVG86IDxydGN3ZWJAaWV0Zi5vcmc8bWFpbHRvOnJ0Y3dlYkBp ZXRmLm9yZz4+DQpDYzogVExTQGlldGYub3JnPG1haWx0bzpUTFNAaWV0Zi5vcmc+ICh0bHNAaWV0 Zi5vcmc8bWFpbHRvOnRsc0BpZXRmLm9yZz4pDQpTdWJqZWN0OiBbcnRjd2ViXSBOdW1iZXIgb2Yg RFRMUyBzZXNzaW9ucy9EVExTIGNvbm5lY3Rpb25zOyBSRTogV2hhdCB0aGUgZ2F0ZXdheSBkcmFm dCBzaG91bGQgc2F5IGFib3V0IG11eC9ub24tbXV4DQoNClJvbWFuLCBCZXJuYXJkLA0KcmlnaHQs IFJGQyA1NzY0IGlzIHRvbyB2YWd1ZSBvbiB0aGF0IGFzcGVjdC4gVGhhbmtzIGZvciBjb25maXJt aW5nIHRoZSBudW1iZXIgb2YgRFRMUyBzZXNzaW9ucywgd2hpY2ggaXMgaW5saW5lIHdpdGggb3Vy IHVuZGVyc3RhbmRpbmcuDQpXb3VsZCBhcHByZWNpYXRlIGlmIHRoaXMgY291bGQgYmUgc29tZXdo ZXJlIGZpeGVkIGluIGFuIHJ0Y3dlYiBkcmFmdCBkdWUgdG8gc2lnbmlmaWNhbnQgc2lkZSBlZmZl Y3RzLg0KVGhpcyB0b3BpYyBpcyBhbHNvIGFuIG9uZ29pbmcgRkFRLg0KDQpUaGUgbW9zdCBzaW1w bGUgY2FzZSBpcyBnaXZlbiBieSBhIHNjZW5hcmlvIHdpdGggdXNhZ2Ugb2YgYnVuZGxpbmcgcGx1 cyB1c2FnZSBvZiBSVFAvUlRDUCB0cmFuc3BvcnQgbXVsdGlwbGV4aW5nLCBsZWFkaW5nIHRvIGEg c2luZ2xlIERUTFMgc2Vzc2lvbi9EVExTIGNvbm5lY3Rpb24sIHdoaWNoIGNvdWxkIGJlIHRoZW4g YWxzbyBzaGFyZWQgZm9yIFdlYlJUQyBkYXRhLg0KDQpCb3RoIGNhcGFiaWxpdGllcyBhcmUgbWFu ZGF0ZWQgaW4gdGhlIHJ0cCB1c2FnZSBkcmFmdDoNCmh0dHBzOi8vdG9vbHMuaWV0Zi5vcmcvaHRt bC9kcmFmdC1pZXRmLXJ0Y3dlYi1ydHAtdXNhZ2UtMjUjc2VjdGlvbi00LjQNCj0+IGJ1bmRsaW5n DQpodHRwczovL3Rvb2xzLmlldGYub3JnL2h0bWwvZHJhZnQtaWV0Zi1ydGN3ZWItcnRwLXVzYWdl LTI1I3NlY3Rpb24tNC41DQo9PiBSVFAvUlRDUCB0cmFuc3BvcnQgbXVsdGlwbGV4aW5nDQoNCk5v dywgSUYgYnVuZGxpbmcgaXMgbm90IHVzZWQgT1IgUlRQL1JUQ1AgdHJhbnNwb3J0IG11bHRpcGxl eGluZyBpcyBub3QgdXNlZCBUSEVOIHRoZXJlIHdpbGwgYmUgbW9yZSB0aGFuIG9uZSBEVExTIHNl c3Npb24vRFRMUyBjb25uZWN0aW9uIChlaXRoZXIgMiBvciA0IGluIGNhc2Ugb2YgYXVkaW8gJiB2 aWRlbykuDQpSYWlzaW5nIHRoZSBxdWVzdGlvbiB3aGljaCBEVExTIGNvbm5lY3Rpb24gaXMgdXNl ZCBmb3IgYWRkaXRpb25hbCBXZWJSVEMgZGF0YSB0cmFmZmljPyAtIEJlY2F1c2UNCmh0dHBzOi8v dG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC1pZXRmLXJ0Y3dlYi10cmFuc3BvcnRzLTA5I3NlY3Rp b24tMy41DQppbmRpY2F0ZXMgdGhlIHNoYXJpbmcgb3B0aW9uLg0KV291bGQgdGhlbiBiZSBhIDNy ZCAob3IgNXRoKSBzZWxmLWNvbnRhaW5lZCBEVExTIHNlc3Npb24vRFRMUyBjb25uZWN0aW9uIGZv ciBXZWJSVEMgZGF0YSB0cmFmZmljPw0KDQpQcm9wb3NhbDoNCkFkZCBleHBsaWNpdCB0ZXh0IHRv IGNsYXVzZSBodHRwczovL3Rvb2xzLmlldGYub3JnL2h0bWwvZHJhZnQtaWV0Zi1ydGN3ZWItdHJh bnNwb3J0cy0wOSNzZWN0aW9uLTMuNQ0KYWJvdXQgKGluIHJlZCksIHNvbWV0aGluZyBsaWtlOg0K DQogICBXZWJSVEMgaW1wbGVtZW50YXRpb25zIE1VU1Qgc3VwcG9ydCBtdWx0aXBsZXhpbmcgb2Yg RFRMUyBhbmQgUlRQIG92ZXINCiAgIHRoZSBzYW1lIHBvcnQgcGFpciwgYXMgZGVzY3JpYmVkIGlu IHRoZSBEVExTLVNSVFAgc3BlY2lmaWNhdGlvbg0KICAgW1JGQzU3NjRdLCBzZWN0aW9uIDUuMS4y PGh0dHBzOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9yZmM1NzY0I3NlY3Rpb24tNS4xLjI+LiAgQWxs IGFwcGxpY2F0aW9uIGxheWVyIHByb3RvY29sIHBheWxvYWRzDQogICBvdmVyIHRoaXMgRFRMUyBj b25uZWN0aW9uIGFyZSBTQ1RQIHBhY2tldHMuDQoNCg0KDQogICBOb3RlIDE6IFRoZXJlIHdpbGwg YmUgdHdvIERUTFMgc2Vzc2lvbnMvRFRMUyBjb25uZWN0aW9ucyB3aGVuIFJUUC9SVENQIHRyYW5z cG9ydCBtdWx0aXBsZXhpbmcgaXMgbm90IGFwcGxpZWQuIFdlYlJUQyBkYXRhIHRyYWZmaWMgY291 bGQgc3RpbGwgc2hhcmUgb25lIG9mIHRoZXNlIERUTFMgY29ubmVjdGlvbnMg4oCmICjigJx3aGlj aCBvbmU/4oCdKSDigKYgb3IgVGhlcmUgc2hvdWxkIGJlIHRoZW4gYSBzZXBhcmF0ZSwgc2VsZi1j b250YWluZWQgRFRMUyBzZXNzaW9uL0RUTFMgY29ubmVjdGlvbiBlc3RhYmxpc2hlZCBleGNsdXNp dmVseSBmb3IgV2ViUlRDIGRhdGEuDQoNCg0KDQogICBOb3RlIDI6IFRoZXJlIGFyZSBzaW1pbGFy IGNvbnNpZGVyYXRpb25zIGluIGNhc2Ugb2YgYnVuZGxpbmcuDQoNCiAgIFByb3RvY29sIGlkZW50 aWZpY2F0aW9uIE1VU1QgYmUgc3VwcGxpZWQgYXMgcGFydCBvZiB0aGUgRFRMUw0KICAgaGFuZHNo YWtlLCBhcyBzcGVjaWZpZWQgaW4gW0ktRC5pZXRmLXJ0Y3dlYi1hbHBuPGh0dHBzOi8vdG9vbHMu aWV0Zi5vcmcvaHRtbC9kcmFmdC1pZXRmLXJ0Y3dlYi10cmFuc3BvcnRzLTA5I3JlZi1JLUQuaWV0 Zi1ydGN3ZWItYWxwbj5dLg0KDQpDb21tZW50cz8NClJlZ2FyZHMsDQpBbGJyZWNodA0KDQpQUw0K VXNpbmcgKEQpVExTIHRlcm1pbm9sb2d5IGFjY29yZGluZyB0byBodHRwOi8vdG9vbHMuaWV0Zi5v cmcvaWQvZHJhZnQtZ3ViYWxsYS10bHMtdGVybWlub2xvZ3ktMDEudHh0DQoNCg0KRnJvbTogQmVy bmFyZCBBYm9iYSBbbWFpbHRvOmJlcm5hcmQuYWJvYmFAZ21haWwuY29tXQ0KU2VudDogTWl0dHdv Y2gsIDUuIEF1Z3VzdCAyMDE1IDA0OjA0DQpUbzogUm9tYW4gU2hwb3VudA0KQ2M6IEFzdmVyZW4s IFRvbGdhOyBDaHJpc3RlciBIb2xtYmVyZzsgRXJpYyBSZXNjb3JsYTsgU2Nod2FyeiwgQWxicmVj aHQgKEFsYnJlY2h0KTsgUmF1c2NoZW5iYWNoLCBVd2UgKE5va2lhIC0gREUvTXVuaWNoKTsgPHJ0 Y3dlYkBpZXRmLm9yZzxtYWlsdG86cnRjd2ViQGlldGYub3JnPj4NClN1YmplY3Q6IFJlOiBbcnRj d2ViXSBXaGF0IHRoZSBnYXRld2F5IGRyYWZ0IHNob3VsZCBzYXkgYWJvdXQgbXV4L25vbi1tdXgN Cg0KT24gQXVnIDQsIDIwMTUsIGF0IDE2OjMzLCBSb21hbiBTaHBvdW50IDxyb21hbkB0ZWx1cml4 LmNvbTxtYWlsdG86cm9tYW5AdGVsdXJpeC5jb20+PiB3cm90ZToNCg0KTW9zdCBvZiB0aGUgcGVv cGxlIGltcGxlbWVudCB0aGlzIHdyb25nLCBzaW5jZSB5b3UgbmVlZCB0byBjcmVhdGUgdHdvIERU TFMgc2Vzc2lvbnM6IG9uZSBmb3IgUlRQIGFuZCBhbm90aGVyIGZvciBSVENQLiBBbmQgdGhlbiB1 c2UgZGlmZmVyZW50IGtleXMgb3IgcG9zc2libHkgZXZlbiBlbmNyeXB0aW9uIHByb2ZpbGVzIGZv ciBSVFAgYW5kIFJUQ1AuIEkgY29tbW9ubHkgc2VlIG9uZSBzZXNzaW9uIGZvciBSVFAgYW5kIGtl eXMgbmVnb3RpYXRlZCB0aGVyZSB1c2VkIGZvciBib3RoIFJUUCBhbmQgUlRDUCwgd2hpY2ggaXMg d3JvbmcuDQoNCltCQV0gWWVzLCB0aGF0IGlzIG9ubHkgb25lIG9mIHNldmVyYWwgY29tbW9uIG1p c3Rha2VzLiAgVW5mb3J0dW5hdGVseSwgUkZDIDU3NjQgZG9lcyBub3QgcnVsZSBvdXQgYWxsIG9m IHRoZXNlIGFuZCB0aGUgc2VjdXJpdHkgZG9jdW1lbnRzIGFyZSBub3QgY3J5c3RhbCBjbGVhciBv biBob3cgdGhpbmdzIG11c3QgYmUgZG9uZS4gSXQgaXMgbXVjaCBoYXJkZXIgdG8gbWVzcyB1cCBS VFAvUlRDUCBtdXguICBHaXZlbiB3aGF0IEkndmUgc2VlbiBzbyBmYXIsIG5vbi1tdXggY291bGQg YmVjb21lIGEgc3VwcG9ydCBuaWdodG1hcmUuDQo= --_000_7594FB04B1934943A5C02806D1A2204B348E9576ESESSMB209erics_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTQgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 Q2FsaWJyaTsNCglwYW5vc2UtMToyIDE1IDUgMiAyIDIgNCAzIDIgNDt9DQpAZm9udC1mYWNlDQoJ e2ZvbnQtZmFtaWx5OlRhaG9tYTsNCglwYW5vc2UtMToyIDExIDYgNCAzIDUgNCA0IDIgNDt9DQpA Zm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OkNvbnNvbGFzOw0KCXBhbm9zZS0xOjIgMTEgNiA5IDIg MiA0IDMgMiA0O30NCi8qIFN0eWxlIERlZmluaXRpb25zICovDQpwLk1zb05vcm1hbCwgbGkuTXNv Tm9ybWFsLCBkaXYuTXNvTm9ybWFsDQoJe21hcmdpbjowY207DQoJbWFyZ2luLWJvdHRvbTouMDAw MXB0Ow0KCWZvbnQtc2l6ZToxMi4wcHQ7DQoJZm9udC1mYW1pbHk6IlRpbWVzIE5ldyBSb21hbiIs InNlcmlmIjt9DQphOmxpbmssIHNwYW4uTXNvSHlwZXJsaW5rDQoJe21zby1zdHlsZS1wcmlvcml0 eTo5OTsNCgljb2xvcjpibHVlOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0KYTp2aXNp dGVkLCBzcGFuLk1zb0h5cGVybGlua0ZvbGxvd2VkDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsN Cgljb2xvcjpwdXJwbGU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQpwcmUNCgl7bXNv LXN0eWxlLXByaW9yaXR5Ojk5Ow0KCW1zby1zdHlsZS1saW5rOiJIVE1MIFByZWZvcm1hdHRlZCBD aGFyIjsNCgltYXJnaW46MGNtOw0KCW1hcmdpbi1ib3R0b206LjAwMDFwdDsNCglmb250LXNpemU6 MTAuMHB0Ow0KCWZvbnQtZmFtaWx5OiJDb3VyaWVyIE5ldyI7fQ0KcC5Nc29BY2V0YXRlLCBsaS5N c29BY2V0YXRlLCBkaXYuTXNvQWNldGF0ZQ0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJbXNv LXN0eWxlLWxpbms6IkJhbGxvb24gVGV4dCBDaGFyIjsNCgltYXJnaW46MGNtOw0KCW1hcmdpbi1i b3R0b206LjAwMDFwdDsNCglmb250LXNpemU6OC4wcHQ7DQoJZm9udC1mYW1pbHk6IlRhaG9tYSIs InNhbnMtc2VyaWYiO30NCnAuTXNvTGlzdFBhcmFncmFwaCwgbGkuTXNvTGlzdFBhcmFncmFwaCwg ZGl2Lk1zb0xpc3RQYXJhZ3JhcGgNCgl7bXNvLXN0eWxlLXByaW9yaXR5OjM0Ow0KCW1hcmdpbi10 b3A6MGNtOw0KCW1hcmdpbi1yaWdodDowY207DQoJbWFyZ2luLWJvdHRvbTowY207DQoJbWFyZ2lu LWxlZnQ6MzYuMHB0Ow0KCW1hcmdpbi1ib3R0b206LjAwMDFwdDsNCglmb250LXNpemU6MTIuMHB0 Ow0KCWZvbnQtZmFtaWx5OiJUaW1lcyBOZXcgUm9tYW4iLCJzZXJpZiI7fQ0Kc3Bhbi5IVE1MUHJl Zm9ybWF0dGVkQ2hhcg0KCXttc28tc3R5bGUtbmFtZToiSFRNTCBQcmVmb3JtYXR0ZWQgQ2hhciI7 DQoJbXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCW1zby1zdHlsZS1saW5rOiJIVE1MIFByZWZvcm1h dHRlZCI7DQoJZm9udC1mYW1pbHk6IkNvdXJpZXIgTmV3Ijt9DQpzcGFuLkJhbGxvb25UZXh0Q2hh cg0KCXttc28tc3R5bGUtbmFtZToiQmFsbG9vbiBUZXh0IENoYXIiOw0KCW1zby1zdHlsZS1wcmlv cml0eTo5OTsNCgltc28tc3R5bGUtbGluazoiQmFsbG9vbiBUZXh0IjsNCglmb250LWZhbWlseToi VGFob21hIiwic2Fucy1zZXJpZiI7fQ0Kc3Bhbi5FbWFpbFN0eWxlMjINCgl7bXNvLXN0eWxlLXR5 cGU6cGVyc29uYWw7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLCJzYW5zLXNlcmlmIjsNCgljb2xv cjojMUY0OTdEO30NCnNwYW4uRW1haWxTdHlsZTIzDQoJe21zby1zdHlsZS10eXBlOnBlcnNvbmFs Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIiwic2Fucy1zZXJpZiI7DQoJY29sb3I6IzFGNDk3RDt9 DQpzcGFuLkVtYWlsU3R5bGUyNA0KCXttc28tc3R5bGUtdHlwZTpwZXJzb25hbDsNCglmb250LWZh bWlseToiQ2FsaWJyaSIsInNhbnMtc2VyaWYiOw0KCWNvbG9yOiMxRjQ5N0Q7fQ0Kc3Bhbi5FbWFp bFN0eWxlMjUNCgl7bXNvLXN0eWxlLXR5cGU6cGVyc29uYWwtcmVwbHk7DQoJZm9udC1mYW1pbHk6 IkNhbGlicmkiLCJzYW5zLXNlcmlmIjsNCgljb2xvcjojMUY0OTdEO30NCi5Nc29DaHBEZWZhdWx0 DQoJe21zby1zdHlsZS10eXBlOmV4cG9ydC1vbmx5Ow0KCWZvbnQtc2l6ZToxMC4wcHQ7fQ0KQHBh Z2UgV29yZFNlY3Rpb24xDQoJe3NpemU6NjEyLjBwdCA3OTIuMHB0Ow0KCW1hcmdpbjo3Mi4wcHQg NzIuMHB0IDcyLjBwdCA3Mi4wcHQ7fQ0KZGl2LldvcmRTZWN0aW9uMQ0KCXtwYWdlOldvcmRTZWN0 aW9uMTt9DQotLT48L3N0eWxlPjwhLS1baWYgZ3RlIG1zbyA5XT48eG1sPg0KPG86c2hhcGVkZWZh dWx0cyB2OmV4dD0iZWRpdCIgc3BpZG1heD0iMTAyNiIgLz4NCjwveG1sPjwhW2VuZGlmXS0tPjwh LS1baWYgZ3RlIG1zbyA5XT48eG1sPg0KPG86c2hhcGVsYXlvdXQgdjpleHQ9ImVkaXQiPg0KPG86 aWRtYXAgdjpleHQ9ImVkaXQiIGRhdGE9IjEiIC8+DQo8L286c2hhcGVsYXlvdXQ+PC94bWw+PCFb ZW5kaWZdLS0+DQo8L2hlYWQ+DQo8Ym9keSBsYW5nPSJGSSIgbGluaz0iYmx1ZSIgdmxpbms9InB1 cnBsZSI+DQo8ZGl2IGNsYXNzPSJXb3JkU2VjdGlvbjEiPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZx dW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj5I aSw8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5n PSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJy aSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7 PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVT IiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7 LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+SSBndWVzcyB3ZSBjb3VsZCBh ZGQgc29tZSBjbGFyaWZpY2F0aW9uIHRleHQgdG8gdGhlIFNEUC1EVExTIGRyYWZ0LjxvOnA+PC9v OnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBz dHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZx dW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8L286cD48L3Nw YW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJm b250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fu cy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj5SZWdhcmRzLDxvOnA+PC9vOnA+PC9zcGFuPjwv cD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1z aXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2Vy aWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTEu MHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90 Oztjb2xvcjojMUY0OTdEIj5DaHJpc3RlcjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtm b250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29s b3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPGRpdj4NCjxkaXYgc3R5 bGU9ImJvcmRlcjpub25lO2JvcmRlci10b3A6c29saWQgI0I1QzRERiAxLjBwdDtwYWRkaW5nOjMu MHB0IDBjbSAwY20gMGNtIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxiPjxzcGFuIGxhbmc9IkVO LVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtUYWhvbWEmcXVv dDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+RnJvbTo8L3NwYW4+PC9iPjxzcGFuIGxhbmc9IkVO LVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtUYWhvbWEmcXVv dDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+IEFzdmVyZW4sIFRvbGdhIFttYWlsdG86dGFzdmVy ZW5Ac29udXNuZXQuY29tXQ0KPGJyPg0KPGI+U2VudDo8L2I+IDUuIGVsb2t1dXRhIDIwMTUgMTU6 Mjc8YnI+DQo8Yj5Ubzo8L2I+IENocmlzdGVyIEhvbG1iZXJnOyBTY2h3YXJ6LCBBbGJyZWNodCAo QWxicmVjaHQpOyAmbHQ7cnRjd2ViQGlldGYub3JnJmd0Ozxicj4NCjxiPkNjOjwvYj4gVExTQGll dGYub3JnICh0bHNAaWV0Zi5vcmcpPGJyPg0KPGI+U3ViamVjdDo8L2I+IFJFOiBbcnRjd2ViXSBO dW1iZXIgb2YgRFRMUyBzZXNzaW9ucy9EVExTIGNvbm5lY3Rpb25zOyBSRTogV2hhdCB0aGUgZ2F0 ZXdheSBkcmFmdCBzaG91bGQgc2F5IGFib3V0IG11eC9ub24tbXV4PG86cD48L286cD48L3NwYW4+ PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9v OnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJm b250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fu cy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj5ZZXMsIGNvbXBsZXRlbHkgYWdyZWUuPG86cD48 L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMi IHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDss JnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwv c3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9 ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtz YW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPkFuZCBJIHRoaW5rIHdoYXQgQWxicmVjaHQg cHJvcG9zZXMgYmVsb3cgaXMgdGhlIHJpZ2h0IHdheSBvZiBhZGRyZXNzaW5nIHRoZSDigJxuby1y dGNwLW11eCBpbXBsZW1lbnRhdGlvbiBkaWZmaWN1bHRpZXPigJ0gcHJvYmxlbTogQWRkaW5nIGNs YXJpZmljYXRpb25zL2FtZW5kbWVudHMNCiBpbiB0aGUgcmVzcGVjdGl2ZSBub3JtYXRpdmUgc3Bl Y2lmaWNhdGlvbiByYXRoZXIgdGhhbiBkaXNhbGxvd2luZyBhIGNvbWJpbmF0aW9uIGluIGEgcHJv ZmlsZSBiZWNhdXNlIGl0IGlzIOKAnGNvbmZ1c2luZ+KAnS4NCjxvOnA+PC9vOnA+PC9zcGFuPjwv cD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1z aXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2Vy aWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+SG9uZXN0bHksIEkgdGhpbmsgdGhlIG51bWJlciBvZiBE VExTIGNvbm5lY3Rpb25zIHRvIHVzZSwgd2hlbiBidW5kbGluZy9tdXhpbmcgaXMgbm90IHVzZWQs IGlzIG5vdCByZWFsbHkgdGhhdCBoYXJkIHRvIGZpZ3VyZSBvdXQgKGZvciBzb21lYm9keQ0KIHdo byBhY3R1YWxseSB1bmRlcnN0YW5kcyB0aGUgd2hvbGUgc3RvcnkpIGJ1dCBvYnZpb3VzbHkgbm8g aGFybSBvZiBhZGRpbmcgc29tZSBjbGFyaWZpY2F0aW9ucy4gRGF0YUNoYW5uZWwgYXNwZWN0cyBu ZWVkIHRvIGJlIGNyaXNwbHkgc3BlY2lmaWVkIHRob3VnaC4gV2hhdCBpcyB0aGUgbWFpbiBhZHZh bnRhZ2Ugb2YgbGV0dGluZyBEYXRhQ2hhbm5lbCBwb3RlbnRpYWxseSB1c2Ugb25lIG9mIHRoZSBl eHNpdGluZyBEVExTIGNvbm5lY3Rpb25zPw0KIEp1c3QgdG8gc2F2ZSBzb21lIHRpbWUgb24gbmVn b3RpYXRpb24/IDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxz cGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVv dDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+PG86 cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFu Zz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGli cmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj5UaGFua3MsPG86 cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4t VVMiIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVv dDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj5Ub2xnYTxvOnA+PC9vOnA+ PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHls ZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90 O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+ PC9wPg0KPGRpdiBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLWxlZnQ6c29saWQgYmx1ZSAxLjVw dDtwYWRkaW5nOjBjbSAwY20gMGNtIDQuMHB0Ij4NCjxkaXY+DQo8ZGl2IHN0eWxlPSJib3JkZXI6 bm9uZTtib3JkZXItdG9wOnNvbGlkICNFMUUxRTEgMS4wcHQ7cGFkZGluZzozLjBwdCAwY20gMGNt IDBjbSI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48Yj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9 ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtz YW5zLXNlcmlmJnF1b3Q7Ij5Gcm9tOjwvc3Bhbj48L2I+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxl PSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7 c2Fucy1zZXJpZiZxdW90OyI+IHJ0Y3dlYiBbPGEgaHJlZj0ibWFpbHRvOnJ0Y3dlYi1ib3VuY2Vz QGlldGYub3JnIj5tYWlsdG86cnRjd2ViLWJvdW5jZXNAaWV0Zi5vcmc8L2E+XQ0KPGI+T24gQmVo YWxmIE9mIDwvYj5DaHJpc3RlciBIb2xtYmVyZzxicj4NCjxiPlNlbnQ6PC9iPiBXZWRuZXNkYXks IEF1Z3VzdCAwNSwgMjAxNSA0OjEzIEFNPGJyPg0KPGI+VG86PC9iPiBTY2h3YXJ6LCBBbGJyZWNo dCAoQWxicmVjaHQpICZsdDs8YSBocmVmPSJtYWlsdG86YWxicmVjaHQuc2Nod2FyekBhbGNhdGVs LWx1Y2VudC5jb20iPmFsYnJlY2h0LnNjaHdhcnpAYWxjYXRlbC1sdWNlbnQuY29tPC9hPiZndDs7 ICZsdDs8YSBocmVmPSJtYWlsdG86cnRjd2ViQGlldGYub3JnIj5ydGN3ZWJAaWV0Zi5vcmc8L2E+ Jmd0OyAmbHQ7PGEgaHJlZj0ibWFpbHRvOnJ0Y3dlYkBpZXRmLm9yZyI+cnRjd2ViQGlldGYub3Jn PC9hPiZndDs8YnI+DQo8Yj5DYzo8L2I+IDxhIGhyZWY9Im1haWx0bzpUTFNAaWV0Zi5vcmciPlRM U0BpZXRmLm9yZzwvYT4gKDxhIGhyZWY9Im1haWx0bzp0bHNAaWV0Zi5vcmciPnRsc0BpZXRmLm9y ZzwvYT4pICZsdDs8YSBocmVmPSJtYWlsdG86dGxzQGlldGYub3JnIj50bHNAaWV0Zi5vcmc8L2E+ Jmd0Ozxicj4NCjxiPlN1YmplY3Q6PC9iPiBSZTogW3J0Y3dlYl0gTnVtYmVyIG9mIERUTFMgc2Vz c2lvbnMvRFRMUyBjb25uZWN0aW9uczsgUkU6IFdoYXQgdGhlIGdhdGV3YXkgZHJhZnQgc2hvdWxk IHNheSBhYm91dCBtdXgvbm9uLW11eDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPC9k aXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyI+PG86cD4mbmJzcDs8 L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQt c2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNl cmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPkhpLDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5 OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdE Ij48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3Bh biBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7 Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPldlIHNo YWxsIG5vdCBtYWtlIFJGQyA1NzY0IGNvcnJlY3Rpb25zIGluIHRoZSBSVENXRUIgc3BlY3MuPG86 cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4t VVMiIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVv dDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpw Pjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5 bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVv dDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPlJlZ2FyZHMsPG86cD48L286cD48L3Nw YW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJm b250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fu cy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6 ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlm JnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPkNocmlzdGVyPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTEu MHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90 Oztjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9u dC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9y OiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWls eTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3 RCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPGRpdj4NCjxkaXYgc3R5bGU9ImJvcmRl cjpub25lO2JvcmRlci10b3A6c29saWQgI0I1QzRERiAxLjBwdDtwYWRkaW5nOjMuMHB0IDBjbSAw Y20gMGNtIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHls ZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtUYWhvbWEmcXVvdDssJnF1b3Q7 c2Fucy1zZXJpZiZxdW90OyI+RnJvbTo8L3NwYW4+PC9iPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHls ZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtUYWhvbWEmcXVvdDssJnF1b3Q7 c2Fucy1zZXJpZiZxdW90OyI+IHJ0Y3dlYiBbPGEgaHJlZj0ibWFpbHRvOnJ0Y3dlYi1ib3VuY2Vz QGlldGYub3JnIj5tYWlsdG86cnRjd2ViLWJvdW5jZXNAaWV0Zi5vcmc8L2E+XQ0KPGI+T24gQmVo YWxmIE9mIDwvYj5TY2h3YXJ6LCBBbGJyZWNodCAoQWxicmVjaHQpPGJyPg0KPGI+U2VudDo8L2I+ IDUuIGVsb2t1dXRhIDIwMTUgMTE6MDQ8YnI+DQo8Yj5Ubzo8L2I+ICZsdDs8YSBocmVmPSJtYWls dG86cnRjd2ViQGlldGYub3JnIj5ydGN3ZWJAaWV0Zi5vcmc8L2E+Jmd0Ozxicj4NCjxiPkNjOjwv Yj4gPGEgaHJlZj0ibWFpbHRvOlRMU0BpZXRmLm9yZyI+VExTQGlldGYub3JnPC9hPiAoPGEgaHJl Zj0ibWFpbHRvOnRsc0BpZXRmLm9yZyI+dGxzQGlldGYub3JnPC9hPik8YnI+DQo8Yj5TdWJqZWN0 OjwvYj4gW3J0Y3dlYl0gTnVtYmVyIG9mIERUTFMgc2Vzc2lvbnMvRFRMUyBjb25uZWN0aW9uczsg UkU6IFdoYXQgdGhlIGdhdGV3YXkgZHJhZnQgc2hvdWxkIHNheSBhYm91dCBtdXgvbm9uLW11eDxv OnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9 IkVOLUdCIiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTpDb25zb2xhcztjb2xv cjojMUY0OTdEIj5Sb21hbiwgQmVybmFyZCw8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1HQiIgc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7 Zm9udC1mYW1pbHk6Q29uc29sYXM7Y29sb3I6IzFGNDk3RCI+cmlnaHQsIFJGQyA1NzY0IGlzIHRv byB2YWd1ZSBvbiB0aGF0IGFzcGVjdC4gVGhhbmtzIGZvciBjb25maXJtaW5nIHRoZSBudW1iZXIg b2YgRFRMUyBzZXNzaW9ucywgd2hpY2ggaXMgaW5saW5lIHdpdGggb3VyIHVuZGVyc3RhbmRpbmcu PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0i RU4tR0IiIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OkNvbnNvbGFzO2NvbG9y OiMxRjQ5N0QiPldvdWxkIGFwcHJlY2lhdGUgaWYgdGhpcyBjb3VsZCBiZSBzb21ld2hlcmUgZml4 ZWQgaW4gYW4gcnRjd2ViIGRyYWZ0IGR1ZSB0byBzaWduaWZpY2FudCBzaWRlIGVmZmVjdHMuPG86 cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4t R0IiIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OkNvbnNvbGFzO2NvbG9yOiMx RjQ5N0QiPlRoaXMgdG9waWMgaXMgYWxzbyBhbiBvbmdvaW5nIEZBUS48bzpwPjwvbzpwPjwvc3Bh bj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1HQiIgc3R5bGU9ImZv bnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6Q29uc29sYXM7Y29sb3I6IzFGNDk3RCI+PG86cD4m bmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0i RU4tR0IiIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OkNvbnNvbGFzO2NvbG9y OiMxRjQ5N0QiPlRoZSBtb3N0IHNpbXBsZSBjYXNlIGlzIGdpdmVuIGJ5IGEgc2NlbmFyaW8gd2l0 aCB1c2FnZSBvZiBidW5kbGluZyBwbHVzIHVzYWdlIG9mIFJUUC9SVENQIHRyYW5zcG9ydCBtdWx0 aXBsZXhpbmcsIGxlYWRpbmcgdG8gYSBzaW5nbGUgRFRMUyBzZXNzaW9uL0RUTFMgY29ubmVjdGlv biwNCiB3aGljaCBjb3VsZCBiZSB0aGVuIGFsc28gc2hhcmVkIGZvciBXZWJSVEMgZGF0YS48bzpw PjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1H QiIgc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6Q29uc29sYXM7Y29sb3I6IzFG NDk3RCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ PHNwYW4gbGFuZz0iRU4tR0IiIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OkNv bnNvbGFzO2NvbG9yOiMxRjQ5N0QiPkJvdGggY2FwYWJpbGl0aWVzIGFyZSBtYW5kYXRlZCBpbiB0 aGUgcnRwIHVzYWdlIGRyYWZ0OjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPjxzcGFuIGxhbmc9IkVOLUdCIiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZh bWlseTpDb25zb2xhcztjb2xvcjojMUY0OTdEIj48YSBocmVmPSJodHRwczovL3Rvb2xzLmlldGYu b3JnL2h0bWwvZHJhZnQtaWV0Zi1ydGN3ZWItcnRwLXVzYWdlLTI1I3NlY3Rpb24tNC40Ij48c3Bh biBsYW5nPSJERSI+aHR0cHM6Ly90b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0LWlldGYtcnRjd2Vi LXJ0cC11c2FnZS0yNSNzZWN0aW9uLTQuNDwvc3Bhbj48L2E+DQo8L3NwYW4+PHNwYW4gbGFuZz0i REUiIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OkNvbnNvbGFzO2NvbG9yOiMx RjQ5N0QiPjxicj4NCj0mZ3Q7IGJ1bmRsaW5nPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tR0IiIHN0eWxlPSJmb250LXNpemU6MTEuMHB0 O2ZvbnQtZmFtaWx5OkNvbnNvbGFzO2NvbG9yOiMxRjQ5N0QiPjxhIGhyZWY9Imh0dHBzOi8vdG9v bHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC1pZXRmLXJ0Y3dlYi1ydHAtdXNhZ2UtMjUjc2VjdGlvbi00 LjUiPmh0dHBzOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC1pZXRmLXJ0Y3dlYi1ydHAtdXNh Z2UtMjUjc2VjdGlvbi00LjU8L2E+DQo8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1HQiIgc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9u dC1mYW1pbHk6Q29uc29sYXM7Y29sb3I6IzFGNDk3RCI+PSZndDsgUlRQL1JUQ1AgdHJhbnNwb3J0 IG11bHRpcGxleGluZzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PjxzcGFuIGxhbmc9IkVOLUdCIiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTpD b25zb2xhcztjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1HQiIgc3R5bGU9ImZvbnQtc2l6ZToxMS4w cHQ7Zm9udC1mYW1pbHk6Q29uc29sYXM7Y29sb3I6IzFGNDk3RCI+Tm93LCBJRiBidW5kbGluZyBp cyBub3QgdXNlZCBPUiBSVFAvUlRDUCB0cmFuc3BvcnQgbXVsdGlwbGV4aW5nIGlzIG5vdCB1c2Vk IFRIRU4gdGhlcmUgd2lsbCBiZSBtb3JlIHRoYW4gb25lIERUTFMgc2Vzc2lvbi9EVExTIGNvbm5l Y3Rpb24gKGVpdGhlciAyIG9yIDQgaW4gY2FzZQ0KIG9mIGF1ZGlvICZhbXA7IHZpZGVvKS48bzpw PjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1H QiIgc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6Q29uc29sYXM7Y29sb3I6IzFG NDk3RCI+UmFpc2luZyB0aGUgcXVlc3Rpb24gd2hpY2ggRFRMUyBjb25uZWN0aW9uIGlzIHVzZWQg Zm9yIGFkZGl0aW9uYWwgV2ViUlRDIGRhdGEgdHJhZmZpYz8gLSBCZWNhdXNlPG86cD48L286cD48 L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tR0IiIHN0eWxl PSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OkNvbnNvbGFzO2NvbG9yOiMxRjQ5N0QiPjxh IGhyZWY9Imh0dHBzOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC1pZXRmLXJ0Y3dlYi10cmFu c3BvcnRzLTA5I3NlY3Rpb24tMy41Ij5odHRwczovL3Rvb2xzLmlldGYub3JnL2h0bWwvZHJhZnQt aWV0Zi1ydGN3ZWItdHJhbnNwb3J0cy0wOSNzZWN0aW9uLTMuNTwvYT4NCjxvOnA+PC9vOnA+PC9z cGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLUdCIiBzdHlsZT0i Zm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTpDb25zb2xhcztjb2xvcjojMUY0OTdEIj5pbmRp Y2F0ZXMgdGhlIHNoYXJpbmcgb3B0aW9uLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLUdCIiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtm b250LWZhbWlseTpDb25zb2xhcztjb2xvcjojMUY0OTdEIj5Xb3VsZCB0aGVuIGJlIGEgMzxzdXA+ cmQ8L3N1cD4gKG9yIDU8c3VwPnRoPC9zdXA+KSBzZWxmLWNvbnRhaW5lZCBEVExTIHNlc3Npb24v RFRMUyBjb25uZWN0aW9uIGZvciBXZWJSVEMgZGF0YSB0cmFmZmljPzxvOnA+PC9vOnA+PC9zcGFu PjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLUdCIiBzdHlsZT0iZm9u dC1zaXplOjExLjBwdDtmb250LWZhbWlseTpDb25zb2xhcztjb2xvcjojMUY0OTdEIj48bzpwPiZu YnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJF Ti1HQiIgc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6Q29uc29sYXM7Y29sb3I6 IzFGNDk3RCI+UHJvcG9zYWw6PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+PHNwYW4gbGFuZz0iRU4tR0IiIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFt aWx5OkNvbnNvbGFzO2NvbG9yOiMxRjQ5N0QiPkFkZCBleHBsaWNpdCB0ZXh0IHRvIGNsYXVzZQ0K PGEgaHJlZj0iaHR0cHM6Ly90b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0LWlldGYtcnRjd2ViLXRy YW5zcG9ydHMtMDkjc2VjdGlvbi0zLjUiPg0KaHR0cHM6Ly90b29scy5pZXRmLm9yZy9odG1sL2Ry YWZ0LWlldGYtcnRjd2ViLXRyYW5zcG9ydHMtMDkjc2VjdGlvbi0zLjU8L2E+IDxvOnA+DQo8L286 cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tR0IiIHN0 eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OkNvbnNvbGFzO2NvbG9yOiMxRjQ5N0Qi PmFib3V0IChpbiByZWQpLCBzb21ldGhpbmcgbGlrZTo8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1HQiIgc3R5bGU9ImZvbnQtc2l6ZTox MS4wcHQ7Zm9udC1mYW1pbHk6Q29uc29sYXM7Y29sb3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8L286 cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tR0IiIHN0 eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7 Ij4mbmJzcDsmbmJzcDsgV2ViUlRDIGltcGxlbWVudGF0aW9ucyBNVVNUIHN1cHBvcnQgbXVsdGlw bGV4aW5nIG9mIERUTFMgYW5kIFJUUCBvdmVyPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tR0IiIHN0eWxlPSJmb250LXNpemU6MTAuMHB0 O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7Ij4mbmJzcDsmbmJzcDsgdGhlIHNh bWUgcG9ydCBwYWlyLCBhcyBkZXNjcmliZWQgaW4gdGhlIERUTFMtU1JUUCBzcGVjaWZpY2F0aW9u PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0i RU4tR0IiIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIg TmV3JnF1b3Q7Ij4mbmJzcDsmbmJzcDsNCjxhIGhyZWY9Imh0dHBzOi8vdG9vbHMuaWV0Zi5vcmcv aHRtbC9yZmM1NzY0I3NlY3Rpb24tNS4xLjIiPltSRkM1NzY0XSwgc2VjdGlvbiZuYnNwOzUuMS4y PC9hPi4mbmJzcDsgQWxsIGFwcGxpY2F0aW9uIGxheWVyIHByb3RvY29sIHBheWxvYWRzPG86cD48 L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tR0Ii IHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1 b3Q7Ij4mbmJzcDsmbmJzcDsgb3ZlciB0aGlzIERUTFMgY29ubmVjdGlvbiBhcmUgU0NUUCBwYWNr ZXRzLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwcmU+PHNwYW4gbGFuZz0iRU4tR0IiPjxvOnA+ Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcHJlPg0KPHByZT48c3BhbiBsYW5nPSJFTi1HQiIgc3R5bGU9 ImNvbG9yOnJlZCI+Jm5ic3A7Jm5ic3A7IE5vdGUgMTogVGhlcmUgd2lsbCBiZSB0d28gRFRMUyBz ZXNzaW9ucy9EVExTIGNvbm5lY3Rpb25zIHdoZW4gUlRQL1JUQ1AgdHJhbnNwb3J0IG11bHRpcGxl eGluZyBpcyBub3QgYXBwbGllZC4gV2ViUlRDIGRhdGEgdHJhZmZpYyBjb3VsZCBzdGlsbCBzaGFy ZSBvbmUgb2YgdGhlc2UgRFRMUyBjb25uZWN0aW9ucyDigKYgPHNwYW4gc3R5bGU9ImJhY2tncm91 bmQ6eWVsbG93O21zby1oaWdobGlnaHQ6eWVsbG93Ij4o4oCcd2hpY2ggb25lP+KAnSk8L3NwYW4+ IOKApiBvciBUaGVyZSBzaG91bGQgYmUgdGhlbiBhIHNlcGFyYXRlLCBzZWxmLWNvbnRhaW5lZCBE VExTIHNlc3Npb24vRFRMUyBjb25uZWN0aW9uIGVzdGFibGlzaGVkIGV4Y2x1c2l2ZWx5IGZvciBX ZWJSVEMgZGF0YS48bzpwPjwvbzpwPjwvc3Bhbj48L3ByZT4NCjxwcmU+PHNwYW4gbGFuZz0iRU4t R0IiIHN0eWxlPSJjb2xvcjpyZWQiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcHJlPg0KPHBy ZT48c3BhbiBsYW5nPSJFTi1HQiIgc3R5bGU9ImNvbG9yOnJlZCI+Jm5ic3A7Jm5ic3A7IE5vdGUg MjogVGhlcmUgYXJlIHNpbWlsYXIgY29uc2lkZXJhdGlvbnMgaW4gY2FzZSBvZiBidW5kbGluZy48 L3NwYW4+PHNwYW4gbGFuZz0iRU4tR0IiPjxvOnA+PC9vOnA+PC9zcGFuPjwvcHJlPg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tR0IiIHN0eWxlPSJmb250LXNpemU6MTAuMHB0 O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7Ij48bzpwPiZuYnNwOzwvbzpwPjwv c3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1HQiIgc3R5bGU9 ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDsiPiZu YnNwOyZuYnNwOyBQcm90b2NvbCBpZGVudGlmaWNhdGlvbiBNVVNUIGJlIHN1cHBsaWVkIGFzIHBh cnQgb2YgdGhlIERUTFM8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij48c3BhbiBsYW5nPSJFTi1HQiIgc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6 JnF1b3Q7Q291cmllciBOZXcmcXVvdDsiPiZuYnNwOyZuYnNwOyBoYW5kc2hha2UsIGFzIHNwZWNp ZmllZCBpbiBbPGEgaHJlZj0iaHR0cHM6Ly90b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0LWlldGYt cnRjd2ViLXRyYW5zcG9ydHMtMDkjcmVmLUktRC5pZXRmLXJ0Y3dlYi1hbHBuIj5JLUQuaWV0Zi1y dGN3ZWItYWxwbjwvYT5dLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPjxzcGFuIGxhbmc9IkVOLUdCIiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWls eTpDb25zb2xhcztjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1HQiIgc3R5bGU9ImZvbnQtc2l6ZTox MS4wcHQ7Zm9udC1mYW1pbHk6Q29uc29sYXM7Y29sb3I6IzFGNDk3RCI+Q29tbWVudHM/PG86cD48 L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tR0Ii IHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OkNvbnNvbGFzO2NvbG9yOiMxRjQ5 N0QiPlJlZ2FyZHMsPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ PHNwYW4gbGFuZz0iRU4tR0IiIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OkNv bnNvbGFzO2NvbG9yOiMxRjQ5N0QiPkFsYnJlY2h0PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tR0IiIHN0eWxlPSJmb250LXNpemU6MTEu MHB0O2ZvbnQtZmFtaWx5OkNvbnNvbGFzO2NvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+ PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLUdCIiBzdHls ZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTpDb25zb2xhcztjb2xvcjojMUY0OTdEIj5Q UzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9 IkVOLUdCIiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTpDb25zb2xhcztjb2xv cjojMUY0OTdEIj5Vc2luZyAoRClUTFMgdGVybWlub2xvZ3kgYWNjb3JkaW5nIHRvDQo8YSBocmVm PSJodHRwOi8vdG9vbHMuaWV0Zi5vcmcvaWQvZHJhZnQtZ3ViYWxsYS10bHMtdGVybWlub2xvZ3kt MDEudHh0Ij5odHRwOi8vdG9vbHMuaWV0Zi5vcmcvaWQvZHJhZnQtZ3ViYWxsYS10bHMtdGVybWlu b2xvZ3ktMDEudHh0PC9hPg0KPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+PHNwYW4gbGFuZz0iRU4tR0IiIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFt aWx5OkNvbnNvbGFzO2NvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLUdCIiBzdHlsZT0iZm9udC1zaXpl OjExLjBwdDtmb250LWZhbWlseTpDb25zb2xhcztjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwv bzpwPjwvc3Bhbj48L3A+DQo8ZGl2Pg0KPGRpdiBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLXRv cDpzb2xpZCAjQjVDNERGIDEuMHB0O3BhZGRpbmc6My4wcHQgMGNtIDBjbSAwY20iPg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+PGI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAu MHB0O2ZvbnQtZmFtaWx5OiZxdW90O1RhaG9tYSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7 Ij5Gcm9tOjwvc3Bhbj48L2I+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAu MHB0O2ZvbnQtZmFtaWx5OiZxdW90O1RhaG9tYSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7 Ij4gQmVybmFyZCBBYm9iYSBbPGEgaHJlZj0ibWFpbHRvOmJlcm5hcmQuYWJvYmFAZ21haWwuY29t Ij5tYWlsdG86YmVybmFyZC5hYm9iYUBnbWFpbC5jb208L2E+XQ0KPGJyPg0KPGI+U2VudDo8L2I+ IE1pdHR3b2NoLCA1LiBBdWd1c3QgMjAxNSAwNDowNDxicj4NCjxiPlRvOjwvYj4gUm9tYW4gU2hw b3VudDxicj4NCjxiPkNjOjwvYj4gQXN2ZXJlbiwgVG9sZ2E7IENocmlzdGVyIEhvbG1iZXJnOyBF cmljIFJlc2NvcmxhOyBTY2h3YXJ6LCBBbGJyZWNodCAoQWxicmVjaHQpOyBSYXVzY2hlbmJhY2gs IFV3ZSAoTm9raWEgLSBERS9NdW5pY2gpOyAmbHQ7PGEgaHJlZj0ibWFpbHRvOnJ0Y3dlYkBpZXRm Lm9yZyI+cnRjd2ViQGlldGYub3JnPC9hPiZndDs8YnI+DQo8Yj5TdWJqZWN0OjwvYj4gUmU6IFty dGN3ZWJdIFdoYXQgdGhlIGdhdGV3YXkgZHJhZnQgc2hvdWxkIHNheSBhYm91dCBtdXgvbm9uLW11 eDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj48c3BhbiBsYW5nPSJFTi1HQiI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPGRp dj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLUdCIj5PbiBBdWcgNCwgMjAx NSwgYXQgMTY6MzMsIFJvbWFuIFNocG91bnQgJmx0OzxhIGhyZWY9Im1haWx0bzpyb21hbkB0ZWx1 cml4LmNvbSI+cm9tYW5AdGVsdXJpeC5jb208L2E+Jmd0OyB3cm90ZTo8bzpwPjwvbzpwPjwvc3Bh bj48L3A+DQo8L2Rpdj4NCjxibG9ja3F1b3RlIHN0eWxlPSJtYXJnaW4tdG9wOjUuMHB0O21hcmdp bi1ib3R0b206NS4wcHQiPg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLUdCIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+ DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1HQiIg c3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZx dW90Oztjb2xvcjpibGFjayI+TW9zdCBvZiB0aGUgcGVvcGxlIGltcGxlbWVudCB0aGlzIHdyb25n LCBzaW5jZSB5b3UgbmVlZCB0byBjcmVhdGUgdHdvIERUTFMgc2Vzc2lvbnM6IG9uZSBmb3IgUlRQ IGFuZCBhbm90aGVyIGZvciBSVENQLiBBbmQgdGhlbiB1c2UgZGlmZmVyZW50IGtleXMgb3IgcG9z c2libHkgZXZlbg0KIGVuY3J5cHRpb24gcHJvZmlsZXMgZm9yIFJUUCBhbmQgUlRDUC4gSSBjb21t b25seSBzZWUgb25lIHNlc3Npb24gZm9yIFJUUCBhbmQga2V5cyBuZWdvdGlhdGVkIHRoZXJlIHVz ZWQgZm9yIGJvdGggUlRQIGFuZCBSVENQLCB3aGljaCBpcyB3cm9uZy48L3NwYW4+PHNwYW4gbGFu Zz0iRU4tR0IiPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4N CjwvZGl2Pg0KPC9ibG9ja3F1b3RlPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0i RU4tR0IiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxkaXY+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj48c3BhbiBsYW5nPSJFTi1HQiI+W0JBXSBZZXMsIHRoYXQgaXMgb25seSBvbmUgb2Yg c2V2ZXJhbCBjb21tb24gbWlzdGFrZXMuICZuYnNwO1VuZm9ydHVuYXRlbHksIFJGQyA1NzY0IGRv ZXMgbm90IHJ1bGUgb3V0IGFsbCBvZiB0aGVzZSBhbmQgdGhlIHNlY3VyaXR5IGRvY3VtZW50cyBh cmUgbm90IGNyeXN0YWwgY2xlYXIgb24gaG93IHRoaW5ncyBtdXN0IGJlIGRvbmUuIEl0IGlzIG11 Y2ggaGFyZGVyIHRvIG1lc3MgdXANCiBSVFAvUlRDUCBtdXguICZuYnNwO0dpdmVuIHdoYXQgSSd2 ZSBzZWVuIHNvIGZhciwgbm9uLW11eCBjb3VsZCBiZWNvbWUgYSBzdXBwb3J0IG5pZ2h0bWFyZS4m bmJzcDs8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Jv ZHk+DQo8L2h0bWw+DQo= --_000_7594FB04B1934943A5C02806D1A2204B348E9576ESESSMB209erics_-- From nobody Wed Aug 5 06:06:23 2015 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0F4301A013B; Wed, 5 Aug 2015 06:06:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oStc4x56Xoyb; Wed, 5 Aug 2015 06:06:19 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 3DEAA1A0389; Wed, 5 Aug 2015 06:06:07 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "Stephen Farrell" To: "The IESG" X-Test-IDTracker: no X-IETF-IDTracker: 6.3.0.p1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20150805130607.20844.70680.idtracker@ietfa.amsl.com> Date: Wed, 05 Aug 2015 06:06:07 -0700 Archived-At: Cc: draft-ietf-rtcweb-stun-consent-freshness.ad@ietf.org, rtcweb@ietf.org, draft-ietf-rtcweb-stun-consent-freshness@ietf.org, rtcweb-chairs@ietf.org, draft-ietf-rtcweb-stun-consent-freshness.shepherd@ietf.org Subject: [rtcweb] Stephen Farrell's Discuss on draft-ietf-rtcweb-stun-consent-freshness-15: (with DISCUSS and COMMENT) X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 05 Aug 2015 13:06:21 -0000 Stephen Farrell has entered the following ballot position for draft-ietf-rtcweb-stun-consent-freshness-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-rtcweb-stun-consent-freshness/ ---------------------------------------------------------------------- DISCUSS: ---------------------------------------------------------------------- Apologies that these discuss points are maybe asking fairly fundamental questions. That could be that this is really the first of the new security things required by rtcweb to get to the IESG. Or maybe I'm misreading stuff here, if so, sorry;-) (1) Why call this "consent?" That term is (ab)used in many ways on the web, and adding another variation without a definition that distinguishes this from "click ok to my 200 page anti-privacy policy" or "remember that example.com is allowed use my camera/mic" seems like a terrible idea. I also don't see how this can ever be something to which a normal person can "consent" (i.e. consciously agree while fully understanding) so the term is IMO very misleading, and will I fear be used to mislead further. (See also some of the comments below - I do not think we ought be as fast and loose with this aleady terribly badly used term.) To summarise: I'd love if you did s/consent/anything-else/g but if not, please define consent here in a way that clearly and unambiguously distinguishes this usage from other abuses of the term. (2) WebRTC does not require STUN or TURN servers for some calls, even if it does for many. Why is it ok to require such a server be present in all calls (which I think this means) espcially when that means exposing additional meta-data (calling parties in a case where the servers weren't needed and call duration in all cases) to those servers when that is not always necessary? (3) (end of p5) You have a MUST NOT here that is depenedent on current browser implementations. Why is that an IETF thing and not a W3C thing? But more interestingly, can one securely use this protocol without the kind of JS vs. browser sandboxing etc that's needed in the web? If the answer is "no" then don't you need to say that this protocol can only safely be used for such implementations? (In section 2, which almost but not quite says that.) (4) Section 8: Where are these 96 bits defined? I think this "requires..." statement needs a precise reference to the place in some ICE/TURN/STUN RFC where it's defined. (And I forget where that is, sorry:-) This should be an easy fix. (5) Why is it ok to approve this while the rtcweb-security-arch and rtcweb-security are still developing? There are section-specific references here along the lines of: "doing this is ok because of section x.x" of both of those drafts. Why is it ok to approve this now, when the underlying architecture and overall security model on which this depends are still in-flux? I'm not asking about editorial changes here nor about timing, but about why it's ok to approve this when the basic security concepts have yet to undergo IETF last call, and so could change significantly. I do not think it would be acceptable for a comment/discuss on the security documents to be received with "yes, but you approved consent-freshness and so we implemented and deployed that so you're too late to make that comment/discuss and expect some change." ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- - abstract: why is only sending "media" mentioned here? What about data channels? And the body of the document in fact says this all applies to any non-ICE data and not only media. - intro: "initial consent to send by performing STUN" I do not find the word consent in either rfc5245 or 3489, but perhaps it is used somewhere else. Where? And with what meaning? - section 4, 2nd last para - I think the conclusion is bogus. An implementation knows when the keying it's using can not involve >1 (nominally operating) party. - 5.1, 3rd para: "Explicit consent to send is obtained..." is misleading. That is not a concept that an implementation of STUN will embody. - 5.1, What is the "Note" about TCP for? Why is this needed? From nobody Wed Aug 5 06:22:11 2015 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 987E81A1B49; Wed, 5 Aug 2015 06:22:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.201 X-Spam-Level: X-Spam-Status: No, score=-4.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GiOBXOEMGxbc; Wed, 5 Aug 2015 06:22:06 -0700 (PDT) Received: from sessmg22.ericsson.net (sessmg22.ericsson.net [193.180.251.58]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D878C1A1A60; Wed, 5 Aug 2015 06:22:04 -0700 (PDT) X-AuditID: c1b4fb3a-f79356d000006281-8d-55c20dfa7677 Received: from ESESSHC021.ericsson.se (Unknown_Domain [153.88.253.124]) by sessmg22.ericsson.net (Symantec Mail Security) with SMTP id 7B.BC.25217.AFD02C55; Wed, 5 Aug 2015 15:22:03 +0200 (CEST) Received: from ESESSMB209.ericsson.se ([169.254.9.36]) by ESESSHC021.ericsson.se ([153.88.183.81]) with mapi id 14.03.0210.002; Wed, 5 Aug 2015 15:22:02 +0200 From: Christer Holmberg To: Stephen Farrell , The IESG Thread-Topic: [rtcweb] Stephen Farrell's Discuss on draft-ietf-rtcweb-stun-consent-freshness-15: (with DISCUSS and COMMENT) Thread-Index: AQHQz3+KPHF90ErmFk+lirKPCDNxv539Y5Rg Date: Wed, 5 Aug 2015 13:22:02 +0000 Message-ID: <7594FB04B1934943A5C02806D1A2204B348E9691@ESESSMB209.ericsson.se> References: <20150805130607.20844.70680.idtracker@ietfa.amsl.com> In-Reply-To: <20150805130607.20844.70680.idtracker@ietfa.amsl.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [153.88.183.16] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFmpjkeLIzCtJLcpLzFFi42KZGfG3Rvc376FQg8VvOC2uTfjObHHh0mpm ix3PG1gtZvyZyGzR8/YGi8Xaf+3sFtP3XmN3YPdY232VzWPJkp9MAUxRXDYpqTmZZalF+nYJ XBl3G28zF/xnqbi66xJTA+MP5i5GDg4JAROJpWvEuxg5gUwxiQv31rN1MXJxCAkcZZSYebWR BcJZxChx6vQLRpAGNgELie5/2iANIgKeEg/7ToHVMAvsZJaY8HAOO0hCWKBG4tKN2YwQRbUS d3c3skHYRhLbL04Gq2ERUJE4evwUmM0r4CvRtfcaK4gtJOAo0XKsEyzOKeAkcfzHQTCbEei6 76fWMIHYzALiEreezGeCuFpAYsme88wQtqjEy8f/WCFsRYmdZ9uZIep1JBbs/sQGYWtLLFv4 mhlir6DEyZlPWCYwis1CMnYWkpZZSFpmIWlZwMiyilG0OLW4ODfdyEgvtSgzubg4P08vL7Vk EyMw4g5u+W21g/Hgc8dDjAIcjEo8vAp5B0OFWBPLiitzDzFKc7AoifPO2JwXKiSQnliSmp2a WpBaFF9UmpNafIiRiYNTqoFx4Tbv9EtORrN73xbcn9yps/qcsZGMxcuQkKSkOw45i09Oy9H3 n3E+oE+XhXXvli3z3z3/8f/F1GzDl3nbnAudN7xgCzG4UuFQW3i7RGL1Y98lsSLVr4/8bJLp WH41qqjiyP5D07J0dA5verxzfv6Bdzmr1qgfV3Q+Y1izf5mns+3N5SxqX+5zKLEUZyQaajEX FScCAGN9hhCZAgAA Archived-At: Cc: "draft-ietf-rtcweb-stun-consent-freshness.shepherd@ietf.org" , "rtcweb@ietf.org" , "draft-ietf-rtcweb-stun-consent-freshness@ietf.org" , "rtcweb-chairs@ietf.org" , "draft-ietf-rtcweb-stun-consent-freshness.ad@ietf.org" Subject: Re: [rtcweb] Stephen Farrell's Discuss on draft-ietf-rtcweb-stun-consent-freshness-15: (with DISCUSS and COMMENT) X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 05 Aug 2015 13:22:07 -0000 Hi Stephen, >(2) WebRTC does not require STUN or TURN servers for some calls, even if i= t does for many. Why is it ok to require such a server be present in all ca= lls (which I think this means) espcially=20 >when that means exposing additional meta-data (calling parties in a case w= here the servers weren't needed and call duration in all >cases) to those servers when that is not always necessary?=20 Could you please refer to the text which you think mandates STUN or TURN se= rvers? If there are no NATs, the STUN requests can be sent between the endpoints, = without STUN or TURN servers. Regards, Christer From nobody Wed Aug 5 08:02:12 2015 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 704FD1B3065 for ; Wed, 5 Aug 2015 08:02:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.977 X-Spam-Level: X-Spam-Status: No, score=-1.977 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7] autolearn=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 wi_lxXc7RAGg for ; Wed, 5 Aug 2015 08:01:56 -0700 (PDT) Received: from mail-wi0-f169.google.com (mail-wi0-f169.google.com [209.85.212.169]) (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 7EC011B306C for ; Wed, 5 Aug 2015 08:01:34 -0700 (PDT) Received: by wicne3 with SMTP id ne3so8579357wic.1 for ; Wed, 05 Aug 2015 08:01:33 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type; bh=sTuVwlf0M4Hjy1kAK2+7n4/XNPYGg5O0wTzDDa+n81g=; b=h2WVU4Jlxb0mmGKXTGSw05yeakj9mIKw6fXD0rg57cUB8cFdheeXDpGbEISpQmVZGN +Gb3i9i04ay7uy9x3Az7HS6B+P/LsYl/jTVJcSZ624635I97deCUTpPstnRnXbvZjRbA lA69bMWk4ZCdAa1OyqGKjdgvGyJEcCvu3azqAxvahP2fXoQgQz7hg7Ydk7lInXe0iRwX BVsGDmHZvqY1QteCJZTuCJ+jdLsTaIXbGPvSCWAxKP0b2CoUpq37W156hLitJvWfolBB nBj87kBRugZSt98mMmpVqzG/5Qo2Ge3GJ+0XKNYiez3swDxW/XoJ1suIR0RqxjGm/X7e UVwQ== X-Gm-Message-State: ALoCoQlF39JEvWS9LcO8dM/C1PnIg9xshgnuKsZGJ2qLfxDMwuOEAAZVaqamfk48Khs7Ljl+zUzX X-Received: by 10.194.79.225 with SMTP id m1mr20898100wjx.8.1438786893183; Wed, 05 Aug 2015 08:01:33 -0700 (PDT) MIME-Version: 1.0 Received: by 10.27.85.86 with HTTP; Wed, 5 Aug 2015 08:00:53 -0700 (PDT) In-Reply-To: <20150805130607.20844.70680.idtracker@ietfa.amsl.com> References: <20150805130607.20844.70680.idtracker@ietfa.amsl.com> From: Eric Rescorla Date: Wed, 5 Aug 2015 08:00:53 -0700 Message-ID: To: Stephen Farrell Content-Type: multipart/alternative; boundary=047d7b10c903ad14a3051c91ade0 Archived-At: Cc: draft-ietf-rtcweb-stun-consent-freshness@ietf.org, rtcweb-chairs@ietf.org, draft-ietf-rtcweb-stun-consent-freshness.shepherd@ietf.org, "rtcweb@ietf.org" , The IESG , draft-ietf-rtcweb-stun-consent-freshness.ad@ietf.org Subject: Re: [rtcweb] Stephen Farrell's Discuss on draft-ietf-rtcweb-stun-consent-freshness-15: (with DISCUSS and COMMENT) X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 05 Aug 2015 15:02:04 -0000 --047d7b10c903ad14a3051c91ade0 Content-Type: text/plain; charset=UTF-8 On Wed, Aug 5, 2015 at 6:06 AM, Stephen Farrell wrote: > Stephen Farrell has entered the following ballot position for > draft-ietf-rtcweb-stun-consent-freshness-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-rtcweb-stun-consent-freshness/ > > > > ---------------------------------------------------------------------- > DISCUSS: > ---------------------------------------------------------------------- > > > > Apologies that these discuss points are maybe asking > fairly fundamental questions. That could be that this > is really the first of the new security things required > by rtcweb to get to the IESG. Or maybe I'm misreading > stuff here, if so, sorry;-) > > (1) Why call this "consent?" That term is (ab)used in > many ways on the web, and adding another variation > without a definition that distinguishes this from "click > ok to my 200 page anti-privacy policy" or "remember that > example.com is allowed use my camera/mic" seems like a > terrible idea. I also don't see how this can ever be > something to which a normal person can "consent" (i.e. > consciously agree while fully understanding) so the term > is IMO very misleading, and will I fear be used to > mislead further. (See also some of the comments below - > I do not think we ought be as fast and loose with this > aleady terribly badly used term.) To summarise: I'd love > if you did s/consent/anything-else/g but if not, please > define consent here in a way that clearly and > unambiguously distinguishes this usage from other abuses > of the term. > You should probably propose a new term at this point. (2) WebRTC does not require STUN or TURN servers for > some calls, even if it does for many. Why is it ok to > require such a server be present in all calls (which I > think this means) espcially when that means exposing > additional meta-data (calling parties in a case where > the servers weren't needed and call duration in all > cases) to those servers when that is not always > necessary? > I'm not sure what you mean by "OK" and "require". The physics of the situation is that if you want to do a call between two people not on the same network, then you minimally need STUN. If you want it to (almost) always work you need TURN. This isn't a spec requirement but just a result of the network topology. As far as I know, the specs don't require that the site supply a STUN/TURN server and the implementations don't either, but I'm not sure what else you're looking for. > (3) (end of p5) You have a MUST NOT here that is > depenedent on current browser implementations. Why is > that an IETF thing and not a W3C thing? But more > interestingly, can one securely use this protocol > without the kind of JS vs. browser sandboxing etc that's > needed in the web? If the answer is "no" then don't you > need to say that this protocol can only safely be used > for such implementations? (In section 2, which almost > but not quite says that.) > This is just only relevant in this case. It doesn't apply to non-JS implementations. -Ekr ---------------------------------------------------------------------- > COMMENT: > ---------------------------------------------------------------------- > > > - abstract: why is only sending "media" mentioned here? > What about data channels? And the body of the document > in fact says this all applies to any non-ICE data and > not only media. > > - intro: "initial consent to send by performing STUN" I > do not find the word consent in either rfc5245 or 3489, > but perhaps it is used somewhere else. Where? And with > what meaning? > > - section 4, 2nd last para - I think the conclusion is > bogus. An implementation knows when the keying it's > using can not involve >1 (nominally operating) party. > > - 5.1, 3rd para: "Explicit consent to send is > obtained..." is misleading. That is not a concept that > an implementation of STUN will embody. > > - 5.1, What is the "Note" about TCP for? Why is this > needed? > > > _______________________________________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/listinfo/rtcweb > --047d7b10c903ad14a3051c91ade0 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


On Wed, Aug 5, 2015 at 6:06 AM, Stephen Farrell <<= a href=3D"mailto:stephen.farrell@cs.tcd.ie" target=3D"_blank">stephen.farre= ll@cs.tcd.ie> wrote:
Stephe= n Farrell has entered the following ballot position for
draft-ietf-rtcweb-stun-consent-freshness-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/s= tatement/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.o= rg/doc/draft-ietf-rtcweb-stun-consent-freshness/



----------------------------------------------------------------------
DISCUSS:
----------------------------------------------------------------------



Apologies that these discuss points are maybe asking
fairly fundamental questions.=C2=A0 That could be that this
is really the first of the new security things required
by rtcweb to get to the IESG.=C2=A0 Or maybe I'm misreading
stuff here, if so, sorry;-)

(1) Why call this "consent?" That term is (ab)used in
many ways on the web, and adding another variation
without a definition that distinguishes this from "click
ok to my 200 page anti-privacy policy" or "remember that
example= .com is allowed use my camera/mic" seems like a
terrible idea. I also don't see how this can ever be
something to which a normal person can "consent" (i.e.
consciously agree while fully understanding) so the term
is IMO very misleading, and will I fear be used to
mislead further.=C2=A0 (See also some of the comments below -
I do not think we ought be as fast and loose with this
aleady terribly badly used term.) To summarise: I'd love
if you did s/consent/anything-else/g but if not, please
define consent here in a way that clearly and
unambiguously distinguishes this usage from other abuses
of the term.

You should probably propos= e a new term at this point.


(2) WebRTC does not require STUN or TURN servers for
some calls, even if it does for many. Why is it ok to
require such a server be present in all calls (which I
think this means) espcially when that means exposing
additional meta-data (calling parties in a case where
the servers weren't needed and call duration in all
cases) to those servers when that is not always
necessary?

I'm not sure what you me= an by "OK" and "require". The physics of the situation<= /div>
is that if you want to do a call between two people not on the sa= me network,
then you minimally need STUN. If you want it to (almo= st) always work you
need TURN. This isn't a spec requirement = but just a result of the network
topology. As far as I know, the = specs don't require that the site supply
a STUN/TURN server a= nd the implementations don't either, but I'm not
sure wha= t else you're looking for.


=C2= =A0
(3) (end of p5) You have a MUST NOT here that is
depenedent on current browser implementations. Why is
that an IETF thing and not a W3C thing? But more
interestingly, can one securely use this protocol
without the kind of JS vs. browser sandboxing etc that's
needed in the web? If the answer is "no" then don't you
need to say that this protocol can only safely be used
for such implementations? (In section 2, which almost
but not quite says that.)

This is just = only relevant in this case. It doesn't apply to non-JS
implem= entations.

-Ekr

----------------------------------------------------------------------
COMMENT:
----------------------------------------------------------------------


- abstract: why is only sending "media" mentioned here?
What about data channels?=C2=A0 And the body of the document
in fact says this all applies to any non-ICE data and
not only media.

- intro: "initial consent to send by performing STUN" I
do not find the word consent in either rfc5245 or 3489,
but perhaps it is used somewhere else. Where?=C2=A0 And with
what meaning?

- section 4, 2nd last para - I think the conclusion is
bogus.=C2=A0 An implementation knows when the keying it's
using can not involve >1 (nominally operating) party.

- 5.1, 3rd para: "Explicit consent to send is
obtained..." is misleading. That is not a concept that
an implementation of STUN will embody.

- 5.1, What is the "Note" about TCP for? Why is this
needed?


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

--047d7b10c903ad14a3051c91ade0-- From nobody Wed Aug 5 08:17:23 2015 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7C5231A3BA3 for ; Wed, 5 Aug 2015 08:17:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.89 X-Spam-Level: X-Spam-Status: No, score=-1.89 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, J_CHICKENPOX_34=0.6, RCVD_IN_DNSWL_LOW=-0.7, T_DKIM_INVALID=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 MTa7gBkshHqI for ; Wed, 5 Aug 2015 08:17:20 -0700 (PDT) Received: from hs8.name.com (hs8.name.com [173.193.131.170]) (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 D184A1A00B6 for ; Wed, 5 Aug 2015 08:17:19 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=ranjitvoip.com; s=default; h=Message-ID:References:In-Reply-To:Reply-To:Subject:Cc:To:From:Date:Content-Transfer-Encoding:Content-Type:MIME-Version; bh=zfgP3vyRDyGIJ9Z7jrIiL0cYffUKOkxNgGNri4ttul4=; b=omkFWcObzfJ4sX19/iqSTm+Y4b6+I33hSS196wWAzDtgV8OxYKyeNeuhAl6Fk5FaPawHXgvf8KWSJbvSOuvN2hTmUSxQWVHzW00aQwukhng9/v96xsHW91SdhJLZM8aVI0PE2OiIZ30UDP7fM53flmWq/Iz6Cb+ITtOj0+N4De8QwKq1fdrfgnmVSR1iadJFXedNZGsc4mHdvKUHP9fIxgKXBXVMJMmBFKEvQjbi2Vy/GEzfk+wQg8il3q8PBOCXLBNwC7u50sjCWgiCeXZLDfe1Wz6TuJgDtSwsDkImjfZpiQHt1b/3tA7bmUcC2yIYVTdoaBRbX6A3RiQG06YJBQ==; Received: from localhost ([127.0.0.1]:21231 helo=webmail.ranjitvoip.com) by hs8.name.com with esmtpa (Exim 4.85) (envelope-from ) id 1ZN0RS-003Yjj-6U; Wed, 05 Aug 2015 09:17:18 -0600 MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit Date: Wed, 05 Aug 2015 10:17:18 -0500 From: Ranjit Avasarala To: "Schwarz, Albrecht (Albrecht)" Mail-Reply-To: ranjit@ranjitvoip.com In-Reply-To: <786615F3A85DF44AA2A76164A71FE1AC7ADB690D@FR711WXCHMBA03.zeu.alcatel-lucent.com> References: <7594FB04B1934943A5C02806D1A2204B348E29DA@ESESSMB209.ericsson.se> <67196805-ED4E-49EA-83AA-3F4C37B5BC50@gmail.com> <7594FB04B1934943A5C02806D1A2204B348E2D52@ESESSMB209.ericsson.se> <56C2F665D49E0341B9DF5938005ACDF8196FF3ED@DEMUMBX005.nsn-intra.net> <56C2F665D49E0341B9DF5938005ACDF8196FF450@DEMUMBX005.nsn-intra.net> <786615F3A85DF44AA2A76164A71FE1AC7ADB690D@FR711WXCHMBA03.zeu.alcatel-lucent.com> Message-ID: <7d3593e2f0bfe422745eca98d41ce927@ranjitvoip.com> X-Sender: ranjit@ranjitvoip.com User-Agent: Roundcube Webmail/1.0.5 X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - hs8.name.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - ranjitvoip.com X-Get-Message-Sender-Via: hs8.name.com: authenticated_id: ranjit@ranjitvoip.com Archived-At: Cc: rtcweb@ietf.org Subject: Re: [rtcweb] What the gateway draft should say about mux/non-mux X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: ranjit@ranjitvoip.com List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 05 Aug 2015 15:17:22 -0000 Given a case where one side of the WebRTC GW supports DTLS-SRTp and the other end supports SDES, then should WebRTC take care of doing the conversion? Regards Ranjit On 2015-08-03 2:19 am, Schwarz, Albrecht (Albrecht) wrote: > The primary justification of webrtc gateways is to increase the > propability of successfully end-to-end webrtc calls; - > > between webrtc and non-webrtc clients, between two webrtc clients with > different capability support. > > That said, the supported capabilities of a webrtc gateway should not > lead to an inherent reduction of the successful webrtc call > establishment rate, i.e., not negatively impact the call control level > negotiation procedures. > > Conclusion: the webrtc gateway MUST support RTCP transport multiplexed > and RTCP transport unmultiplexed modes, as well as the interworking > between both modes. > > Regards, > > Albrecht > > PS > > With regards to DTLS-SRTP, i.e., the DTLS-based key management scheme > for SRTP: > > A webrtc gateway might need to support interworking between a webrtc > domain with DTLS-SRTP and a non-webrtc domain with SDES-based key > management scheme, i.e. a scenario of type SRTP-to-SRTP interworking. > But I guess that use case is beyond the IETF gateway draft. > > FROM: rtcweb [mailto:rtcweb-bounces@ietf.org] ON BEHALF OF > Rauschenbach, Uwe (Nokia - DE/Munich) > SENT: Freitag, 31. Juli 2015 21:08 > TO: ext Asveren, Tolga; Christer Holmberg; Bernard Aboba; Roman > Shpount > CC: > SUBJECT: Re: [rtcweb] What the gateway draft should say about > mux/non-mux > > Yes, agreed, these are in two different categories. > > RTCP mux is an optimization – not supporting it doubles the number > of ports to be used, and slows down ICE gathering. > > Whereas ICE non-support is a showstopper > > Let me have some internal discussions on this topic and get back to > the list next week. > > Kind regards, > > Uwe > > FROM: ext Asveren, Tolga [mailto:tasveren@sonusnet.com] > SENT: Friday, July 31, 2015 12:03 PM > TO: Rauschenbach, Uwe (Nokia - DE/Munich); Christer Holmberg; Bernard > Aboba; Roman Shpount > CC: > SUBJECT: RE: [rtcweb] What the gateway draft should say about > mux/non-mux > > Yes, completely agree on the “new” v.s. “the way things used to > work for many years” point as far as rtcp-mux is concerned. > > Furthermore, -for example-, not mandating ICE would have serious > impact as far as “making things work from end user perspective” is > concerned. OTOH, the same does not necessarily hold true for rtcp-mux. > Two WebRTC elements, which do not want to use it can communicate > successfully. > > Thanks, > > Tolga > > FROM: Rauschenbach, Uwe (Nokia - DE/Munich) > [mailto:uwe.rauschenbach@nokia.com] > SENT: Friday, July 31, 2015 2:58 PM > TO: Asveren, Tolga ; Christer Holmberg > ; Bernard Aboba > ; Roman Shpount > CC: > SUBJECT: RE: [rtcweb] What the gateway draft should say about > mux/non-mux > > Well: non-mux is not a “new thing” that we mandate the whole > universe to support – it is on the contrary the way RTCP/RTP used to > function since the beginning. > > MUXing is the “new thing”. > > Of course you can take away legacy support if no-one is interested in > supporting it anymore. > > I think this is the core of the discussion that we are having – do > we want to retire the original way RTP+RTCP were working w.r.t. port > usage? > > I have my doubts (for the time being). > > Kind regards, > > Uwe > > FROM: rtcweb [mailto:rtcweb-bounces@ietf.org] ON BEHALF OF ext > Asveren, Tolga > SENT: Friday, July 31, 2015 11:49 AM > TO: Christer Holmberg; Bernard Aboba; Roman Shpount > CC: > SUBJECT: Re: [rtcweb] What the gateway draft should say about > mux/non-mux > > Yes, you *COULD* mandate the whole universe to support it, that > shouldn’t be too difficult to describe on paper ;-) > > OTOH, why? If there are folks, for whom no-rtcp-mux is just fine (for > whatever reason), let their implementations function that way (and let > them suffer if this is really such a terrible thing from > implementation difficulty perspective). And it will be their problem > if that causes interoperability issues for them, e.g. they won’t be > able to talk to browsers, which mandate use of rtcp-mux. > > Browsers (or any other implementation) always mandate use of rtcp-mux > by always offering it and terminating a session if the answer > indicates no rtcp-mux support. Similarly, they can reject offers with > rtcp-mux. > > Thanks, > > Tolga > > FROM: rtcweb [mailto:rtcweb-bounces@ietf.org] ON BEHALF OF Christer > Holmberg > SENT: Friday, July 31, 2015 2:44 PM > TO: Bernard Aboba ; Roman Shpount > > CC: > SUBJECT: Re: [rtcweb] What the gateway draft should say about > mux/non-mux > > Hi, > > If we choose to mandate usage of rtcp-mux, we could also mandate > gateways to support it. > > Regards, > > Christer > > FROM: rtcweb [mailto:rtcweb-bounces@ietf.org] ON BEHALF OF Bernard > Aboba > SENT: 31 July 2015 21:32 > TO: Roman Shpount > CC: > SUBJECT: Re: [rtcweb] What the gateway draft should say about > mux/non-mux > > On Jul 31, 2015, at 10:57, Roman Shpount wrote: > >> Why would the gateway need to negotiate non-mux if rtcp-mux is >> supported? > > [BA] IMHO, Gateways should be required to support mux like any other > WEBRTC endpoint, but this is not what it says in Section 2 of > https://tools.ietf.org/html/draft-ietf-rtcweb-gateways [1] : > > "If a gateway serves as a media relay into another RTP domain, it MAY > choose to support only features available in that network. This means > that it MAY choose to not support Bundle and any of the RTP/ RTCP > extensions related to it, RTCP-Mux, or Trickle Ice. However, the > gateway MUST support DTLS-SRTP, since this is required for > interworking with WebRTC endpoints." > > Assuming that browsers remove or do not implement non-mux, it seems > prudent to require gateways to support mux so as to avoid negotiation > failures. If we make that change then gateways would always negotiate > RTCP-mux with browsers. > > > Links: > ------ > [1] https://tools.ietf.org/html/draft-ietf-rtcweb-gateways > > _______________________________________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/listinfo/rtcweb -- Regards Ranjit From nobody Wed Aug 5 08:27:03 2015 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2D6C81B30AA for ; Wed, 5 Aug 2015 08:27:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.377 X-Spam-Level: X-Spam-Status: No, score=-1.377 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, J_CHICKENPOX_34=0.6, RCVD_IN_DNSWL_LOW=-0.7] 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 yfO0W8j7q-ib for ; Wed, 5 Aug 2015 08:26:58 -0700 (PDT) Received: from mail-wi0-f173.google.com (mail-wi0-f173.google.com [209.85.212.173]) (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 C2D921B30C1 for ; Wed, 5 Aug 2015 08:26:12 -0700 (PDT) Received: by wicgj17 with SMTP id gj17so197451422wic.1 for ; Wed, 05 Aug 2015 08:26:11 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type; bh=pMNchtURwVRVBGqtlp+IBzDdNxfzxrn4GvVom2+D8Ls=; b=RvrwCaZNGmZBHKdMH4KCCHqPEeGA3BWzuY/n2n1Q4u0jD9G+C43R9w7k1lJ2AVJuR6 r8tZxbKHpQIx68RXvL1/DfRcI62We5YQ319s20eNxoL6lGO2SSKOMbIVgTubA8DszMRV wU6T+vR5DWW29RKFgjSp8/xzV5Gv6XsMoyrgaqk48HmdKcly4cgSFZFOVmEo1KD9bHgc Tap9hK+9f6Lts28BRkvqq8hEQpzX9HYizf1WP0RqjEvpIdQLtdrCdozLOnhGt80mlaJ6 mBEjEwgInbdnGfxeliK2PhbLdu8MxbhmyGYaQLaVtOumZp3oBSYtcrNlE2pyipgtEbAC QhBQ== X-Gm-Message-State: ALoCoQkckO5iNK3wj9b6KM0LMluX2Rajw5uvYQHMWovBLWCa3K/HRTxhTyWkJjvJ/VNJmqEH6zTd X-Received: by 10.180.83.137 with SMTP id q9mr11773597wiy.68.1438788371345; Wed, 05 Aug 2015 08:26:11 -0700 (PDT) MIME-Version: 1.0 Received: by 10.27.85.86 with HTTP; Wed, 5 Aug 2015 08:25:31 -0700 (PDT) In-Reply-To: <7d3593e2f0bfe422745eca98d41ce927@ranjitvoip.com> References: <7594FB04B1934943A5C02806D1A2204B348E29DA@ESESSMB209.ericsson.se> <67196805-ED4E-49EA-83AA-3F4C37B5BC50@gmail.com> <7594FB04B1934943A5C02806D1A2204B348E2D52@ESESSMB209.ericsson.se> <56C2F665D49E0341B9DF5938005ACDF8196FF3ED@DEMUMBX005.nsn-intra.net> <56C2F665D49E0341B9DF5938005ACDF8196FF450@DEMUMBX005.nsn-intra.net> <786615F3A85DF44AA2A76164A71FE1AC7ADB690D@FR711WXCHMBA03.zeu.alcatel-lucent.com> <7d3593e2f0bfe422745eca98d41ce927@ranjitvoip.com> From: Eric Rescorla Date: Wed, 5 Aug 2015 08:25:31 -0700 Message-ID: To: ranjit@ranjitvoip.com Content-Type: multipart/alternative; boundary=f46d04440196c8063e051c920558 Archived-At: Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] What the gateway draft should say about mux/non-mux X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 05 Aug 2015 15:27:01 -0000 --f46d04440196c8063e051c920558 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable No. That's the gateway's job. -Ekr On Wed, Aug 5, 2015 at 8:17 AM, Ranjit Avasarala wrote: > Given a case where one side of the WebRTC GW supports DTLS-SRTp and the > other end supports SDES, then should WebRTC take care of doing the > conversion? > > Regards > Ranjit > > On 2015-08-03 2:19 am, Schwarz, Albrecht (Albrecht) wrote: > >> The primary justification of webrtc gateways is to increase the >> propability of successfully end-to-end webrtc calls; - >> >> between webrtc and non-webrtc clients, between two webrtc clients with >> different capability support. >> >> That said, the supported capabilities of a webrtc gateway should not >> lead to an inherent reduction of the successful webrtc call >> establishment rate, i.e., not negatively impact the call control level >> negotiation procedures. >> >> Conclusion: the webrtc gateway MUST support RTCP transport multiplexed >> and RTCP transport unmultiplexed modes, as well as the interworking >> between both modes. >> >> Regards, >> >> Albrecht >> >> PS >> >> With regards to DTLS-SRTP, i.e., the DTLS-based key management scheme >> for SRTP: >> >> A webrtc gateway might need to support interworking between a webrtc >> domain with DTLS-SRTP and a non-webrtc domain with SDES-based key >> management scheme, i.e. a scenario of type SRTP-to-SRTP interworking. >> But I guess that use case is beyond the IETF gateway draft. >> >> FROM: rtcweb [mailto:rtcweb-bounces@ietf.org] ON BEHALF OF >> Rauschenbach, Uwe (Nokia - DE/Munich) >> SENT: Freitag, 31. Juli 2015 21:08 >> TO: ext Asveren, Tolga; Christer Holmberg; Bernard Aboba; Roman >> Shpount >> CC: >> SUBJECT: Re: [rtcweb] What the gateway draft should say about >> mux/non-mux >> >> Yes, agreed, these are in two different categories. >> >> RTCP mux is an optimization =E2=80=93 not supporting it doubles the numb= er >> of ports to be used, and slows down ICE gathering. >> >> Whereas ICE non-support is a showstopper >> >> Let me have some internal discussions on this topic and get back to >> the list next week. >> >> Kind regards, >> >> Uwe >> >> FROM: ext Asveren, Tolga [mailto:tasveren@sonusnet.com] >> SENT: Friday, July 31, 2015 12:03 PM >> TO: Rauschenbach, Uwe (Nokia - DE/Munich); Christer Holmberg; Bernard >> Aboba; Roman Shpount >> CC: >> SUBJECT: RE: [rtcweb] What the gateway draft should say about >> mux/non-mux >> >> Yes, completely agree on the =E2=80=9Cnew=E2=80=9D v.s. =E2=80=9Cthe way= things used to >> work for many years=E2=80=9D point as far as rtcp-mux is concerned. >> >> Furthermore, -for example-, not mandating ICE would have serious >> impact as far as =E2=80=9Cmaking things work from end user perspective= =E2=80=9D is >> concerned. OTOH, the same does not necessarily hold true for rtcp-mux. >> Two WebRTC elements, which do not want to use it can communicate >> successfully. >> >> Thanks, >> >> Tolga >> >> FROM: Rauschenbach, Uwe (Nokia - DE/Munich) >> [mailto:uwe.rauschenbach@nokia.com] >> SENT: Friday, July 31, 2015 2:58 PM >> TO: Asveren, Tolga ; Christer Holmberg >> ; Bernard Aboba >> ; Roman Shpount >> CC: >> SUBJECT: RE: [rtcweb] What the gateway draft should say about >> mux/non-mux >> >> Well: non-mux is not a =E2=80=9Cnew thing=E2=80=9D that we mandate the w= hole >> universe to support =E2=80=93 it is on the contrary the way RTCP/RTP use= d to >> function since the beginning. >> >> MUXing is the =E2=80=9Cnew thing=E2=80=9D. >> >> Of course you can take away legacy support if no-one is interested in >> supporting it anymore. >> >> I think this is the core of the discussion that we are having =E2=80=93 = do >> we want to retire the original way RTP+RTCP were working w.r.t. port >> usage? >> >> I have my doubts (for the time being). >> >> Kind regards, >> >> Uwe >> >> FROM: rtcweb [mailto:rtcweb-bounces@ietf.org] ON BEHALF OF ext >> Asveren, Tolga >> SENT: Friday, July 31, 2015 11:49 AM >> TO: Christer Holmberg; Bernard Aboba; Roman Shpount >> CC: >> SUBJECT: Re: [rtcweb] What the gateway draft should say about >> mux/non-mux >> >> Yes, you *COULD* mandate the whole universe to support it, that >> shouldn=E2=80=99t be too difficult to describe on paper ;-) >> >> OTOH, why? If there are folks, for whom no-rtcp-mux is just fine (for >> whatever reason), let their implementations function that way (and let >> them suffer if this is really such a terrible thing from >> implementation difficulty perspective). And it will be their problem >> if that causes interoperability issues for them, e.g. they won=E2=80=99t= be >> able to talk to browsers, which mandate use of rtcp-mux. >> >> Browsers (or any other implementation) always mandate use of rtcp-mux >> by always offering it and terminating a session if the answer >> indicates no rtcp-mux support. Similarly, they can reject offers with >> rtcp-mux. >> >> Thanks, >> >> Tolga >> >> FROM: rtcweb [mailto:rtcweb-bounces@ietf.org] ON BEHALF OF Christer >> Holmberg >> SENT: Friday, July 31, 2015 2:44 PM >> TO: Bernard Aboba ; Roman Shpount >> >> CC: >> SUBJECT: Re: [rtcweb] What the gateway draft should say about >> mux/non-mux >> >> Hi, >> >> If we choose to mandate usage of rtcp-mux, we could also mandate >> gateways to support it. >> >> Regards, >> >> Christer >> >> FROM: rtcweb [mailto:rtcweb-bounces@ietf.org] ON BEHALF OF Bernard >> Aboba >> SENT: 31 July 2015 21:32 >> TO: Roman Shpount >> CC: >> SUBJECT: Re: [rtcweb] What the gateway draft should say about >> mux/non-mux >> >> On Jul 31, 2015, at 10:57, Roman Shpount wrote: >> >> Why would the gateway need to negotiate non-mux if rtcp-mux is >>> supported? >>> >> >> [BA] IMHO, Gateways should be required to support mux like any other >> WEBRTC endpoint, but this is not what it says in Section 2 of >> https://tools.ietf.org/html/draft-ietf-rtcweb-gateways [1] : >> >> "If a gateway serves as a media relay into another RTP domain, it MAY >> choose to support only features available in that network. This means >> that it MAY choose to not support Bundle and any of the RTP/ RTCP >> extensions related to it, RTCP-Mux, or Trickle Ice. However, the >> gateway MUST support DTLS-SRTP, since this is required for >> interworking with WebRTC endpoints." >> >> Assuming that browsers remove or do not implement non-mux, it seems >> prudent to require gateways to support mux so as to avoid negotiation >> failures. If we make that change then gateways would always negotiate >> RTCP-mux with browsers. >> >> >> Links: >> ------ >> [1] https://tools.ietf.org/html/draft-ietf-rtcweb-gateways >> >> _______________________________________________ >> rtcweb mailing list >> rtcweb@ietf.org >> https://www.ietf.org/mailman/listinfo/rtcweb >> > > -- > Regards > Ranjit > > > _______________________________________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/listinfo/rtcweb > --f46d04440196c8063e051c920558 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
No. That's the gateway's job.

-= Ekr


On Wed, Aug 5, 2015 at 8:17 AM, Ranjit Avasarala <ranjit@= ranjitvoip.com> wrote:
Give= n a case where one side of the WebRTC GW supports DTLS-SRTp and the other e= nd supports SDES, then should WebRTC take care of doing the conversion?

Regards
Ranjit

On 2015-08-03 2:19 am, Schwarz, Albrecht (Albrecht) wrote:
The primary justification of webrtc gateways is to increase the
propability of successfully end-to-end webrtc calls; -

between webrtc and non-webrtc clients, between two webrtc clients with
different capability support.

That said, the supported capabilities of a webrtc gateway should not
lead to an inherent reduction of the successful webrtc call
establishment rate, i.e., not negatively impact the call control level
negotiation procedures.

Conclusion: the webrtc gateway MUST support RTCP transport multiplexed
and RTCP transport unmultiplexed modes, as well as the interworking
between both modes.

Regards,

Albrecht

PS

With regards to DTLS-SRTP, i.e., the DTLS-based key management scheme
for SRTP:

A webrtc gateway might need to support interworking between a webrtc
domain with DTLS-SRTP and a non-webrtc domain with SDES-based key
management scheme, i.e. a scenario of type SRTP-to-SRTP interworking.
But I guess that use case is beyond the IETF gateway draft.

 FROM: rtcweb [mailto:rtcweb-bounces@ietf.org] ON BEHALF OF
Rauschenbach, Uwe (Nokia - DE/Munich)
 =C2=A0SENT: Freitag, 31. Juli 2015 21:08
=C2=A0TO: ext Asveren, Tolga; Christer Holmberg; Bernard Aboba; Roman
Shpount
=C2=A0CC: <rtcweb@i= etf.org>
=C2=A0SUBJECT: Re: [rtcweb] What the gateway draft should say about
mux/non-mux

Yes, agreed, these are in two different categories.

RTCP mux is an optimization =E2=80=93 not supporting it doubles the number<= br> of ports to be used, and slows down ICE gathering.

Whereas ICE non-support is a showstopper

Let me have some internal discussions on this topic and get back to
the list next week.

Kind regards,

Uwe

 FROM: ext Asveren, Tolga [mailto:tasveren@sonusnet.com]
=C2=A0SENT: Friday, July 31, 2015 12:03 PM
=C2=A0TO: Rauschenbach, Uwe (Nokia - DE/Munich); Christer Holmberg; Bernard=
Aboba; Roman Shpount
=C2=A0CC: <rtcweb@i= etf.org>
=C2=A0SUBJECT: RE: [rtcweb] What the gateway draft should say about
mux/non-mux

Yes, completely agree on the =E2=80=9Cnew=E2=80=9D v.s. =E2=80=9Cthe way th= ings used to
work for many years=E2=80=9D point as far as rtcp-mux is concerned.

Furthermore, -for example-, not mandating ICE would have serious
impact as far as =E2=80=9Cmaking things work from end user perspective=E2= =80=9D is
concerned. OTOH, the same does not necessarily hold true for rtcp-mux.
Two WebRTC elements, which do not want to use it can communicate
successfully.

Thanks,

Tolga

 FROM: Rauschenbach, Uwe (Nokia - DE/Munich)
[mailto:uwe= .rauschenbach@nokia.com]
=C2=A0SENT: Friday, July 31, 2015 2:58 PM
=C2=A0TO: Asveren, Tolga <tasveren@sonusnet.com>; Christer Holmberg
<chr= ister.holmberg@ericsson.com>; Bernard Aboba
<bernard.ab= oba@gmail.com>; Roman Shpount <roman@telurix.com>
 =C2=A0CC: <rtcweb@i= etf.org> <rt= cweb@ietf.org>
=C2=A0SUBJECT: RE: [rtcweb] What the gateway draft should say about
mux/non-mux

Well: non-mux is not a =E2=80=9Cnew thing=E2=80=9D that we mandate the whol= e
universe to support =E2=80=93 it is on the contrary the way RTCP/RTP used t= o
function since the beginning.

MUXing is the =E2=80=9Cnew thing=E2=80=9D.

Of course you can take away legacy support if no-one is interested in
supporting it anymore.

I think this is the core of the discussion that we are having =E2=80=93 do<= br> we want to retire the original way RTP+RTCP were working w.r.t. port
usage?

I have my doubts (for the time being).

Kind regards,

Uwe

 FROM: rtcweb [mailto:rtcweb-bounces@ietf.org] ON BEHALF OF ext
Asveren, Tolga
=C2=A0SENT: Friday, July 31, 2015 11:49 AM
=C2=A0TO: Christer Holmberg; Bernard Aboba; Roman Shpount
=C2=A0CC: <rtcweb@i= etf.org>
=C2=A0SUBJECT: Re: [rtcweb] What the gateway draft should say about
mux/non-mux

Yes, you *COULD* mandate the whole universe to support it, that
shouldn=E2=80=99t be too difficult to describe on paper ;-)

OTOH, why? If there are folks, for whom no-rtcp-mux is just fine (for
whatever reason), let their implementations function that way (and let
them suffer if this is really such a terrible thing from
implementation difficulty perspective). And it will be their problem
if that causes interoperability issues for them, e.g. they won=E2=80=99t be=
able to talk to browsers, which mandate use of rtcp-mux.

Browsers (or any other implementation) always mandate use of rtcp-mux
by always offering it and terminating a session if the answer
indicates no rtcp-mux support. Similarly, they can reject offers with
rtcp-mux.

Thanks,

Tolga

 FROM: rtcweb [mailto:rtcweb-bounces@ietf.org] ON BEHALF OF Christer
Holmberg
=C2=A0SENT: Friday, July 31, 2015 2:44 PM
=C2=A0TO: Bernard Aboba <bernard.aboba@gmail.com>; Roman Shpount
<roman@telurix.co= m>
=C2=A0CC: <rtcweb@i= etf.org> <rt= cweb@ietf.org>
=C2=A0SUBJECT: Re: [rtcweb] What the gateway draft should say about
mux/non-mux

Hi,

If we choose to mandate usage of rtcp-mux, we could also mandate
gateways to support it.

Regards,

Christer

 FROM: rtcweb [mailto:rtcweb-bounces@ietf.org] ON BEHALF OF Bernard
Aboba
=C2=A0SENT: 31 July 2015 21:32
=C2=A0TO: Roman Shpount <roman@telurix.com>
=C2=A0CC: <rtcweb@i= etf.org> <rt= cweb@ietf.org>
=C2=A0SUBJECT: Re: [rtcweb] What the gateway draft should say about
mux/non-mux

On Jul 31, 2015, at 10:57, Roman Shpount <roman@telurix.com> wrote:

Why would the gateway need to negotiate non-mux if rtcp-mux is
supported?

[BA] IMHO, Gateways should be required to support mux like any other
WEBRTC endpoint, but this is not what it says in Section 2 of
https://tools.ietf.org/html/draft-ietf-= rtcweb-gateways [1] :

"If a gateway serves as a media relay into another RTP domain, it MAY<= br> choose to support only features available in that network. This means
that it MAY choose to not support Bundle and any of the RTP/ RTCP
extensions related to it, RTCP-Mux, or Trickle Ice. However, the
gateway MUST support DTLS-SRTP, since this is required for
interworking with WebRTC endpoints."

Assuming that browsers remove or do not implement non-mux, it seems
prudent to require gateways to support mux so as to avoid negotiation
failures. If we make that change then gateways would always negotiate
RTCP-mux with browsers.


 Links:
------
[1] https://tools.ietf.org/html/draft-ietf-rt= cweb-gateways

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

--
Regards
Ranjit


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

--f46d04440196c8063e051c920558-- From nobody Wed Aug 5 08:42:53 2015 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 52C051B30D5 for ; Wed, 5 Aug 2015 08:42:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1 X-Spam-Level: X-Spam-Status: No, score=-1 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, FREEMAIL_REPLY=1, 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 mZwWWjxFYp_A for ; Wed, 5 Aug 2015 08:42:50 -0700 (PDT) Received: from mail-la0-x235.google.com (mail-la0-x235.google.com [IPv6:2a00:1450:4010:c03::235]) (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 848CF1B30C7 for ; Wed, 5 Aug 2015 08:42:50 -0700 (PDT) Received: by labkb6 with SMTP id kb6so9636758lab.2 for ; Wed, 05 Aug 2015 08:42:49 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; bh=8CWvytglDq5CH+VVtxCwSLU6O4MA2HkGiClI1ZzANr4=; b=TOFXXAWTt+8cD6cddQGm1dpCwR2B12Xy18lSyMdwTLVf6HfrYdKPseDDw3oCizDplp LK7RWSgS/4DnYVt5bZvCPkaXHy5WWIPG50IKVz1fmD7HLFOXgpzlzJ5H/mSJ1ytZrV2y gPrpcoehVuRZoae3VD38+nGL5LJKLIbRn9SedWj+ukr0ZFWeHPAmSu15mpCQUYxnLqOi gmQeMJLM2PxihQmh5W/8F6fl3cISaNE0Yxg0f5J74VttKE+8HD2Rs9xB729aZr64iQA8 3fOgWT7kDzK7hPRpSyOG8HjyriPeN5q98ZhVdbY+JToV/n2oZPy1D8ZR8umDjgXMrXej KX1w== MIME-Version: 1.0 X-Received: by 10.112.42.172 with SMTP id p12mr6059815lbl.52.1438789369020; Wed, 05 Aug 2015 08:42:49 -0700 (PDT) Received: by 10.25.197.87 with HTTP; Wed, 5 Aug 2015 08:42:48 -0700 (PDT) In-Reply-To: <786615F3A85DF44AA2A76164A71FE1AC7ADB9197@FR711WXCHMBA03.zeu.alcatel-lucent.com> References: <7594FB04B1934943A5C02806D1A2204B348E82CA@ESESSMB209.ericsson.se> <05B3C43B-2823-4590-889E-7A192FC8A3AD@gmail.com> <786615F3A85DF44AA2A76164A71FE1AC7ADB9197@FR711WXCHMBA03.zeu.alcatel-lucent.com> Date: Wed, 5 Aug 2015 08:42:48 -0700 Message-ID: From: Martin Thomson To: "Schwarz, Albrecht (Albrecht)" Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Archived-At: Cc: "" Subject: Re: [rtcweb] [TLS] Number of DTLS sessions/DTLS connections; RE: What the gateway draft should say about mux/non-mux X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 05 Aug 2015 15:42:52 -0000 -tls@ My reading is that we are close to concluding that rtcpmux is required. Therefore, this becomes a non-issue. On 5 August 2015 at 01:03, Schwarz, Albrecht (Albrecht) wrote: > Roman, Bernard, > > right, RFC 5764 is too vague on that aspect. Thanks for confirming the > number of DTLS sessions, which is inline with our understanding. > > Would appreciate if this could be somewhere fixed in an rtcweb draft due = to > significant side effects. > > This topic is also an ongoing FAQ. > > > > The most simple case is given by a scenario with usage of bundling plus > usage of RTP/RTCP transport multiplexing, leading to a single DTLS > session/DTLS connection, which could be then also shared for WebRTC data. > > > > Both capabilities are mandated in the rtp usage draft: > > https://tools.ietf.org/html/draft-ietf-rtcweb-rtp-usage-25#section-4.4 > =3D> bundling > > https://tools.ietf.org/html/draft-ietf-rtcweb-rtp-usage-25#section-4.5 > > =3D> RTP/RTCP transport multiplexing > > > > Now, IF bundling is not used OR RTP/RTCP transport multiplexing is not us= ed > THEN there will be more than one DTLS session/DTLS connection (either 2 o= r 4 > in case of audio & video). > > Raising the question which DTLS connection is used for additional WebRTC > data traffic? - Because > > https://tools.ietf.org/html/draft-ietf-rtcweb-transports-09#section-3.5 > > indicates the sharing option. > > Would then be a 3rd (or 5th) self-contained DTLS session/DTLS connection = for > WebRTC data traffic? > > > > Proposal: > > Add explicit text to clause > https://tools.ietf.org/html/draft-ietf-rtcweb-transports-09#section-3.5 > > about (in red), something like: > > > > WebRTC implementations MUST support multiplexing of DTLS and RTP over > > the same port pair, as described in the DTLS-SRTP specification > > [RFC5764], section 5.1.2. All application layer protocol payloads > > over this DTLS connection are SCTP packets. > > > > Note 1: There will be two DTLS sessions/DTLS connections when RTP/RTCP > transport multiplexing is not applied. WebRTC data traffic could still sh= are > one of these DTLS connections =E2=80=A6 (=E2=80=9Cwhich one?=E2=80=9D) = =E2=80=A6 or There should be then a > separate, self-contained DTLS session/DTLS connection established > exclusively for WebRTC data. > > > > Note 2: There are similar considerations in case of bundling. > > > > Protocol identification MUST be supplied as part of the DTLS > > handshake, as specified in [I-D.ietf-rtcweb-alpn]. > > > > Comments? > > Regards, > > Albrecht > > > > PS > > Using (D)TLS terminology according to > http://tools.ietf.org/id/draft-guballa-tls-terminology-01.txt > > > > > > From: Bernard Aboba [mailto:bernard.aboba@gmail.com] > Sent: Mittwoch, 5. August 2015 04:04 > To: Roman Shpount > Cc: Asveren, Tolga; Christer Holmberg; Eric Rescorla; Schwarz, Albrecht > (Albrecht); Rauschenbach, Uwe (Nokia - DE/Munich); > Subject: Re: [rtcweb] What the gateway draft should say about mux/non-mux > > > > On Aug 4, 2015, at 16:33, Roman Shpount wrote: > > > > Most of the people implement this wrong, since you need to create two DTL= S > sessions: one for RTP and another for RTCP. And then use different keys o= r > possibly even encryption profiles for RTP and RTCP. I commonly see one > session for RTP and keys negotiated there used for both RTP and RTCP, whi= ch > is wrong. > > > > [BA] Yes, that is only one of several common mistakes. Unfortunately, RF= C > 5764 does not rule out all of these and the security documents are not > crystal clear on how things must be done. It is much harder to mess up > RTP/RTCP mux. Given what I've seen so far, non-mux could become a suppor= t > nightmare. > > > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls > From nobody Wed Aug 5 09:13:42 2015 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5839D1B312C for ; Wed, 5 Aug 2015 09:13:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.791 X-Spam-Level: X-Spam-Status: No, score=0.791 tagged_above=-999 required=5 tests=[BAYES_50=0.8, T_RP_MATCHES_RCVD=-0.01, WEIRD_PORT=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 IEuCX_VRJtYZ for ; Wed, 5 Aug 2015 09:13:39 -0700 (PDT) Received: from lo.psyced.org (lost.in.psyced.org [188.40.42.221]) (using TLSv1 with cipher ECDHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 26C531B3136 for ; Wed, 5 Aug 2015 09:13:38 -0700 (PDT) Received: from lo.psyced.org (localhost [127.0.0.1]) by lo.psyced.org (8.14.3/8.14.3/Debian-9.4) with ESMTP id t75GDj9T019578 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Wed, 5 Aug 2015 18:13:46 +0200 Received: (from lynx@localhost) by lo.psyced.org (8.14.3/8.14.3/Submit) id t75GDjnO019575 for rtcweb@ietf.org; Wed, 5 Aug 2015 18:13:45 +0200 Date: Wed, 5 Aug 2015 18:13:45 +0200 From: carlo von lynX To: rtcweb@ietf.org Message-ID: <20150805161344.GA19492@lo.psyced.org> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit User-Agent: Mutt/1.5.20 (2009-06-14) Archived-At: Subject: [rtcweb] LAST CALL: Systematically de-anonymize dissidents with WebRTC (HOWTO) X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 05 Aug 2015 16:13:41 -0000 Last chance to rebuke the following paragraph or to introduce a prompt that says something like "Do you want to allow to activate direct/ P2P communications?" before I go noisy... >From https://webrtchacks.com/webrtc-notify/ > Nefarious websites could potentially use this information to fingerprint individuals who do not want to be tracked. That is not the main concern. Nefarious websites could systematically gather which visitors are using VPNs or Tor… which in some countries indicates they are very probably dissidents. With the real IP address in the pockets the authorities can go visit the potential dissident and see what she or he has been up to. They will most probably find evidence on the computer since dissidents in poor countries aren't particularely educated in operational security. Therefore a plugin that they first need to know about will not fix the problem in time. Thousands (or according to the other poster, millions) may be endangered by the introduction of WebRTC… even if these people never asked for any WebRTC in their browsers and weren't planning to use it for anything. -- E-mail is public! Talk to me in private using encryption: http://loupsycedyglgamf.onion/LynX/ irc://loupsycedyglgamf.onion:67/lynX https://psyced.org:34443/LynX/ From nobody Wed Aug 5 09:28:46 2015 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A40911A0203 for ; Wed, 5 Aug 2015 09:28:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.978 X-Spam-Level: X-Spam-Status: No, score=-1.978 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, 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 YtmyhLVqtm_h for ; Wed, 5 Aug 2015 09:28:43 -0700 (PDT) Received: from mail-io0-f169.google.com (mail-io0-f169.google.com [209.85.223.169]) (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 8ADCA1B3182 for ; Wed, 5 Aug 2015 09:28:34 -0700 (PDT) Received: by ioii16 with SMTP id i16so54689808ioi.0 for ; Wed, 05 Aug 2015 09:28:34 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=Rg1GkqfT8TFGT4kyTyFAMnDBfveJ6SlkuV0W8aQIQBs=; b=b4RNq77W6uc7heaaM5xiTnVQ5zhELH5bIHhBTqVi0U+68zVx6nVj0aRDaU/K8hO02z 4jUHGuGLwqanMljXzHZz1wszqevNfTvgwzoEoJfV79+4dvpbfc6K5Hw4Hv0nBnQmK68i jWRDuS2HpxdFKGEiA4STTMicKSmleRuZxK4wFOr6FurbtRCT45janFrcGcy35vEDO5JC WQOm/5uQW7//LTKZsedENV/6EMXSSky5u1sl2ahzMWM+hvICZ+uGeCSrZvPTPo7NTUJm Z0yMyBHrar8rSk4nluP8y7DeFEr6GkrFw9TKzoNflZT2NkdPEbCHiQce2hFkvrbf/qe3 u9UQ== X-Gm-Message-State: ALoCoQlLQDbGvywmw6ayoSe6gMBmj4ulEQBUdv+IaoaFJ3t/NtEJHJU/+QIJS6KVCHpIMENAbwJ8 X-Received: by 10.107.169.105 with SMTP id s102mr10866320ioe.151.1438792113992; Wed, 05 Aug 2015 09:28:33 -0700 (PDT) Received: from mail-ig0-f181.google.com (mail-ig0-f181.google.com. [209.85.213.181]) by smtp.gmail.com with ESMTPSA id g9sm2697920igg.5.2015.08.05.09.28.32 for (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 05 Aug 2015 09:28:32 -0700 (PDT) Received: by igbpg9 with SMTP id pg9so36531938igb.0 for ; Wed, 05 Aug 2015 09:28:32 -0700 (PDT) MIME-Version: 1.0 X-Received: by 10.50.61.179 with SMTP id q19mr162214igr.24.1438792112497; Wed, 05 Aug 2015 09:28:32 -0700 (PDT) Received: by 10.36.89.70 with HTTP; Wed, 5 Aug 2015 09:28:32 -0700 (PDT) In-Reply-To: <56C2F665D49E0341B9DF5938005ACDF81970EDC1@DEMUMBX005.nsn-intra.net> References: <7594FB04B1934943A5C02806D1A2204B348E29DA@ESESSMB209.ericsson.se> <67196805-ED4E-49EA-83AA-3F4C37B5BC50@gmail.com> <7594FB04B1934943A5C02806D1A2204B348E2D52@ESESSMB209.ericsson.se> <56C2F665D49E0341B9DF5938005ACDF8196FF3ED@DEMUMBX005.nsn-intra.net> <56C2F665D49E0341B9DF5938005ACDF8196FF450@DEMUMBX005.nsn-intra.net> <786615F3A85DF44AA2A76164A71FE1AC7ADB690D@FR711WXCHMBA03.zeu.alcatel-lucent.com> <56C2F665D49E0341B9DF5938005ACDF81970EDC1@DEMUMBX005.nsn-intra.net> Date: Wed, 5 Aug 2015 12:28:32 -0400 Message-ID: From: Roman Shpount To: "Rauschenbach, Uwe (Nokia - DE/Munich)" Content-Type: multipart/alternative; boundary=047d7bdc109ec56e3d051c92e4cb Archived-At: Cc: "" Subject: Re: [rtcweb] What the gateway draft should say about mux/non-mux X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 05 Aug 2015 16:28:44 -0000 --047d7bdc109ec56e3d051c92e4cb Content-Type: text/plain; charset=UTF-8 On Wed, Aug 5, 2015 at 4:47 AM, Rauschenbach, Uwe (Nokia - DE/Munich) < uwe.rauschenbach@nokia.com> wrote: > Media gateway implementations according to 3GPP TS 23.228 may not support > rtcp-mux, as rtcp-mux is optional there. > > So if we drop non-mux support from web browsers, those media gateways that > have not implemented rtcp-mux will stop interoperating. > > > First of all, do you know of any WebRTC to IMS gateways that do not implement rtcp-mux on the WebRTC side? I strongly suspect there are none. Second, the only reasons not to use rtcp-mux that I can think of are the following: 1. Using different QOS settings for RTCP vs RTP 2. Sending RTCP to a different device from RTP I do not think the first use case warrants making rtcp-mux optional, since, practically no one does this. Second use case is also fairly marginal. Plus it can be handled by the gateway which can send RTCP to one device and RTP to another. So, unless someone can come up with a use case why RTP and RTCP should use different transports, I think rtcp-mux should be mandatory. Regards, ______________ Roman Shpount --047d7bdc109ec56e3d051c92e4cb Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On W= ed, Aug 5, 2015 at 4:47 AM, Rauschenbach, Uwe (Nokia - DE/Munich) <uwe.rauschenbach@nokia.com> wrote:

Media gateway implementations according to 3GPP TS 23.228 may not = support rtcp-mux, as rtcp-mux is optional there.

So if we drop non-mux support from web br= owsers, those media gateways that have not implemented rtcp-mux will stop i= nteroperating.=C2=A0



First of all, do you know of any WebRTC to IMS gateways that do not = implement rtcp-mux on the WebRTC side? I strongly suspect there are none.

Second, the only reasons not to use rtcp-mux that I= can think of are the following:

1. Using differen= t QOS settings for RTCP vs RTP
2. Sending RTCP to a different dev= ice from RTP

I do not think the first use case war= rants making rtcp-mux optional, since, practically no one does this.
<= div>Second use case is also fairly marginal. Plus it can be handled by the = gateway which can send RTCP to one device and RTP to another.
So, unless someone can come up with a use case why RTP and RTCP= should use different transports, I think rtcp-mux should be mandatory.

Regards,
______________
Roman Shp= ount
--047d7bdc109ec56e3d051c92e4cb-- From nobody Wed Aug 5 09:37:16 2015 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D90AD1A6F3F for ; Wed, 5 Aug 2015 09:37:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.977 X-Spam-Level: X-Spam-Status: No, score=-1.977 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, WEIRD_PORT=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 QwPLllMjyXQU for ; Wed, 5 Aug 2015 09:37:13 -0700 (PDT) Received: from mail-ig0-f180.google.com (mail-ig0-f180.google.com [209.85.213.180]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id F0A481A21AE for ; Wed, 5 Aug 2015 09:37:12 -0700 (PDT) Received: by igbij6 with SMTP id ij6so98752723igb.1 for ; Wed, 05 Aug 2015 09:37:12 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=pCfmf4lY3B7NIleZ/wgL8ABfKNL/h+x4gdSizN3MrtI=; b=cpx/mEswgZyZUzYdjxt54cN72i1OfvKVnIiexkRQvOBeiiBJpWKVueyV2ECUjWB6cx dpPDOrMjJaA/XrZmNDZMz6CV9RYM7WdDwpwkTvUeai3lPVZ9v47ZAF9J54IeWCvL5EBY wc4TtJYHmVciKuVJy8a6pnTKP1j2PGL0v1+Vkqncx+tF6lVWGMiwNN6bgRDfIYFAGjTM UWIsHXmiUMMKMVHAq6A/McRKMMJBEckCwYVT0DaFjo0y9K10MQ9vOGlbwdjd2Jt1+4P4 MYrKY1YpfmRtjO8rC/mhFAaTmIM2JPxJCCbaElgbir505Rj9QOBJHBvRVHTmvTBel6A3 QqPw== X-Gm-Message-State: ALoCoQn8Iy84oyh1c3JFiLjGLz+FzUlOJvniXmMZW/l7RGyUrJPspUT6v2JixXuBdhS4ZDhkLKGb X-Received: by 10.50.122.41 with SMTP id lp9mr183125igb.56.1438792632352; Wed, 05 Aug 2015 09:37:12 -0700 (PDT) Received: from mail-io0-f177.google.com (mail-io0-f177.google.com. [209.85.223.177]) by smtp.gmail.com with ESMTPSA id d3sm4007983igx.5.2015.08.05.09.37.11 for (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 05 Aug 2015 09:37:11 -0700 (PDT) Received: by ioea135 with SMTP id a135so54890866ioe.1 for ; Wed, 05 Aug 2015 09:37:11 -0700 (PDT) MIME-Version: 1.0 X-Received: by 10.107.131.91 with SMTP id f88mr11383714iod.190.1438792631317; Wed, 05 Aug 2015 09:37:11 -0700 (PDT) Received: by 10.64.57.116 with HTTP; Wed, 5 Aug 2015 09:37:11 -0700 (PDT) In-Reply-To: <20150805161344.GA19492@lo.psyced.org> References: <20150805161344.GA19492@lo.psyced.org> Date: Wed, 5 Aug 2015 12:37:11 -0400 Message-ID: From: Benjamin Schwartz To: carlo von lynX Content-Type: multipart/alternative; boundary=001a113ecd56b22764051c9303ea Archived-At: Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] LAST CALL: Systematically de-anonymize dissidents with WebRTC (HOWTO) X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 05 Aug 2015 16:37:15 -0000 --001a113ecd56b22764051c9303ea Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Tor does not claim to protect against hostile websites unless you are using the Tor Browser Bundle, which is not subject to this issue (it already disables WebRTC). Hyperbole is not a helpful tactic here. On Wed, Aug 5, 2015 at 12:13 PM, carlo von lynX < lynX@i.know.you.are.psyced.org> wrote: > Last chance to rebuke the following paragraph or > to introduce a prompt that says something like > "Do you want to allow to activate direct/ > P2P communications?" before I go noisy... > > >From https://webrtchacks.com/webrtc-notify/ > > Nefarious websites could potentially use this information to fingerprin= t > individuals who do not want to be tracked. > > That is not the main concern. Nefarious websites could systematically > gather which visitors are using VPNs or Tor=E2=80=A6 which in some countr= ies > indicates they are very probably dissidents. With the real IP address in > the pockets the authorities can go visit the potential dissident and see > what she or he has been up to. They will most probably find evidence on t= he > computer since dissidents in poor countries aren't particularely educated > in operational security. Therefore a plugin that they first need to know > about will not fix the problem in time. Thousands (or according to the > other poster, millions) may be endangered by the introduction of WebRTC= =E2=80=A6 > even if these people never asked for any WebRTC in their browsers and > weren't planning to use it for anything. > > > -- > E-mail is public! Talk to me in private using encryption: > http://loupsycedyglgamf.onion/LynX/ > irc://loupsycedyglgamf.onion:67/lynX > https://psyced.org:34443/LynX/ > > _______________________________________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/listinfo/rtcweb > --001a113ecd56b22764051c9303ea Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Tor does not claim to protect against hostile websites unl= ess you are using the Tor Browser Bundle, which is not subject to this issu= e (it already disables WebRTC).

Hyperbole is not a helpf= ul tactic here.

On Wed, Aug 5, 2015 at 12:13 PM, carlo von lynX <ly= nX@i.know.you.are.psyced.org> wrote:
Last chance to rebuke the following paragraph or
to introduce a prompt that says something like
"Do you want to allow <domain> to activate direct/
P2P communications?" before I go noisy...

>From https://webrtchacks.com/webrtc-notify/
> Nefarious websites could potentially use this information to fingerpri= nt individuals who do not want to be tracked.

That is not the main concern. Nefarious websites could systematically gathe= r which visitors are using VPNs or Tor=E2=80=A6 which in some countries ind= icates they are very probably dissidents. With the real IP address in the p= ockets the authorities can go visit the potential dissident and see what sh= e or he has been up to. They will most probably find evidence on the comput= er since dissidents in poor countries aren't particularely educated in = operational security. Therefore a plugin that they first need to know about= will not fix the problem in time. Thousands (or according to the other pos= ter, millions) may be endangered by the introduction of WebRTC=E2=80=A6 eve= n if these people never asked for any WebRTC in their browsers and weren= 9;t planning to use it for anything.


--
=C2=A0 E-mail is public! Talk to me in private using encryption:
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0http://loupsycedyglgamf.onion/L= ynX/
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 irc://loupsycedyglgamf.onion:67/lynX
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0https://psyced.org:34443/LynX/
_______________________________________________
rtcweb mailing list
rtcweb@ietf.org
https://www.ietf.org/mailman/listinfo/rtcweb

--001a113ecd56b22764051c9303ea-- From nobody Wed Aug 5 09:42:57 2015 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E595F1B3192 for ; Wed, 5 Aug 2015 09:42:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.91 X-Spam-Level: X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id n4cQGU5sjsOH for ; Wed, 5 Aug 2015 09:42:52 -0700 (PDT) Received: from lo.psyced.org (lost.in.psyced.org [188.40.42.221]) (using TLSv1 with cipher ECDHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2C00F1B31B4 for ; Wed, 5 Aug 2015 09:42:49 -0700 (PDT) Received: from lo.psyced.org (localhost [127.0.0.1]) by lo.psyced.org (8.14.3/8.14.3/Debian-9.4) with ESMTP id t75Ggva7020542 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Wed, 5 Aug 2015 18:42:57 +0200 Received: (from lynx@localhost) by lo.psyced.org (8.14.3/8.14.3/Submit) id t75Ggv6M020541 for rtcweb@ietf.org; Wed, 5 Aug 2015 18:42:57 +0200 Date: Wed, 5 Aug 2015 18:42:57 +0200 From: carlo von lynX To: rtcweb@ietf.org Message-ID: <20150805164256.GB19492@lo.psyced.org> References: <20150805161344.GA19492@lo.psyced.org> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: User-Agent: Mutt/1.5.20 (2009-06-14) Archived-At: Subject: Re: [rtcweb] LAST CALL: Systematically de-anonymize dissidents with WebRTC (HOWTO) X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 05 Aug 2015 16:42:54 -0000 On Wed, Aug 05, 2015 at 12:37:11PM -0400, Benjamin Schwartz wrote: > Tor does not claim to protect against hostile websites unless you are using > the Tor Browser Bundle, which is not subject to this issue (it already > disables WebRTC). Disclaimers are irrelevant here. The question is what the dissidents are using. Probably they are using Chrome with VPN, or Firefox and VPN. >From what I heard they aren't even using Tor. Maybe we should ask the libtech folks what these people are actually using - but from the last things I learned at the OpenITP meetings that would be it. > Hyperbole is not a helpful tactic here. Friendly people seem to be even easier to ignore on unconfortable topics. > On Wed, Aug 5, 2015 at 12:13 PM, carlo von lynX < > lynX@i.know.you.are.psyced.org> wrote: > > > Last chance to rebuke the following paragraph or > > to introduce a prompt that says something like > > "Do you want to allow to activate direct/ > > P2P communications?" before I go noisy... > > > > >From https://webrtchacks.com/webrtc-notify/ > > > Nefarious websites could potentially use this information to fingerprint > > individuals who do not want to be tracked. > > > > That is not the main concern. Nefarious websites could systematically > > gather which visitors are using VPNs or Tor… which in some countries > > indicates they are very probably dissidents. With the real IP address in > > the pockets the authorities can go visit the potential dissident and see > > what she or he has been up to. They will most probably find evidence on the > > computer since dissidents in poor countries aren't particularely educated > > in operational security. Therefore a plugin that they first need to know > > about will not fix the problem in time. Thousands (or according to the > > other poster, millions) may be endangered by the introduction of WebRTC… > > even if these people never asked for any WebRTC in their browsers and > > weren't planning to use it for anything. > > From nobody Wed Aug 5 09:55:28 2015 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 52FDF1A870B; Wed, 5 Aug 2015 09:55:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.311 X-Spam-Level: X-Spam-Status: No, score=-4.311 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_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Ypmbmqrzny3T; Wed, 5 Aug 2015 09:55:27 -0700 (PDT) Received: from mercury.scss.tcd.ie (mercury.scss.tcd.ie [134.226.56.6]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 240581A8033; Wed, 5 Aug 2015 09:55:27 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id D197CBE8E; Wed, 5 Aug 2015 17:55:25 +0100 (IST) Received: from mercury.scss.tcd.ie ([127.0.0.1]) by localhost (mercury.scss.tcd.ie [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9e4TJo3aaqK7; Wed, 5 Aug 2015 17:55:25 +0100 (IST) Received: from [134.226.36.180] (stephen-think.dsg.cs.tcd.ie [134.226.36.180]) by mercury.scss.tcd.ie (Postfix) with ESMTPSA id 7A79BBE35; Wed, 5 Aug 2015 17:55:25 +0100 (IST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cs.tcd.ie; s=mail; t=1438793725; bh=PirNRDcV4JMcz4cbK9pRAbPBO9b+lyYWZe8am087+Qk=; h=Date:From:To:CC:Subject:References:In-Reply-To:From; b=ReAyQ5EbRfxTXVIKl51gNluQzHFh8qAvK85p571BDdgzKo5Y+lJ0ITMb1CvCE1kHt 4bUW1t9zH9xT5HlMPtH2ncFW47Azb5j4bf9adTq24hBxkHWjtPu6wgZmbHXg61v02M QTLelXxHrAWI17yc+Fs3a5hKaLtfbZwjb3LacsmI= Message-ID: <55C23FFD.8070201@cs.tcd.ie> Date: Wed, 05 Aug 2015 17:55:25 +0100 From: Stephen Farrell User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.8.0 MIME-Version: 1.0 To: Christer Holmberg , The IESG References: <20150805130607.20844.70680.idtracker@ietfa.amsl.com> <7594FB04B1934943A5C02806D1A2204B348E9691@ESESSMB209.ericsson.se> In-Reply-To: <7594FB04B1934943A5C02806D1A2204B348E9691@ESESSMB209.ericsson.se> OpenPGP: id=D66EA7906F0B897FB2E97D582F3C8736805F8DA2; url= Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Archived-At: Cc: "draft-ietf-rtcweb-stun-consent-freshness.ad@ietf.org" , "rtcweb@ietf.org" , "draft-ietf-rtcweb-stun-consent-freshness@ietf.org" , "rtcweb-chairs@ietf.org" , "draft-ietf-rtcweb-stun-consent-freshness.shepherd@ietf.org" Subject: Re: [rtcweb] Stephen Farrell's Discuss on draft-ietf-rtcweb-stun-consent-freshness-15: (with DISCUSS and COMMENT) X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 05 Aug 2015 16:55:28 -0000 Hiya, On 05/08/15 14:22, Christer Holmberg wrote: > Hi Stephen, > >> (2) WebRTC does not require STUN or TURN servers for some calls, >> even if it does for many. Why is it ok to require such a server be >> present in all calls (which I think this means) espcially when that >> means exposing additional meta-data (calling parties in a case >> where the servers weren't needed and call duration in all cases) to >> those servers when that is not always necessary? > > Could you please refer to the text which you think mandates STUN or > TURN servers? Sure, I think there were a couple of places, but I'd have to track 'em down. I'll try update the ballot with that if it turns out to be needed. (Be tomorrow before I get to that, sorry.) > > If there are no NATs, the STUN requests can be sent between the > endpoints, without STUN or TURN servers. Really - so browsers will be able to act like a STUN server or something? I didn't know that. Where's that described? S. > > Regards, > > Christer > From nobody Wed Aug 5 10:02:25 2015 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BA54E1B31FC for ; Wed, 5 Aug 2015 10:02:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.977 X-Spam-Level: X-Spam-Status: No, score=-1.977 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7] autolearn=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 bIYOaWLcRWaa for ; Wed, 5 Aug 2015 10:02:12 -0700 (PDT) Received: from mail-wi0-f180.google.com (mail-wi0-f180.google.com [209.85.212.180]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1F6B01B31FD for ; Wed, 5 Aug 2015 10:02:08 -0700 (PDT) Received: by wibxm9 with SMTP id xm9so76007473wib.1 for ; Wed, 05 Aug 2015 10:02:06 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type; bh=69VGBoY1PHVbcW0xwqQn87r7KRT5GyKuYs98slcJIZI=; b=FKlabCNeLXiXFOoVbLmVFCuDrUgcikqDjhHnBg0P0OfYym6XUbwG/SmaAYSvpINlF2 AWLpELvoqNfFbpCogoEURNC59g2LUP1VHx+LRy9dEmELy9Yo+haP6yGm882nxVfmoCzI hYqF/s3z/Lnxgj5d9J2qtJAb9cgiVRtMwmO2+TtC6ypCTSZ6w/icH5WmxI7M6rUzoZQP UPA9rx78NePrZIULVNcEe3Ax1homV9cwqB7eyHFcv7FEuG+3EpRPaTJm38LBYVTokoe1 q+oLS/J1zysXoKu8w7jAu3bKpQLV4P5vxvP67GXVOxEUXmroFIO35V6m8HWELftJriyq 6vmA== X-Gm-Message-State: ALoCoQnTCC98wkJj1F6AaV4EnBhfLk/yozJWESiuhEjb7RPww4Y7b96quqPnE/2rM/nJzfIT+6h5 X-Received: by 10.194.133.73 with SMTP id pa9mr21759847wjb.148.1438794126696; Wed, 05 Aug 2015 10:02:06 -0700 (PDT) MIME-Version: 1.0 Received: by 10.27.85.86 with HTTP; Wed, 5 Aug 2015 10:01:27 -0700 (PDT) In-Reply-To: <55C23FFD.8070201@cs.tcd.ie> References: <20150805130607.20844.70680.idtracker@ietfa.amsl.com> <7594FB04B1934943A5C02806D1A2204B348E9691@ESESSMB209.ericsson.se> <55C23FFD.8070201@cs.tcd.ie> From: Eric Rescorla Date: Wed, 5 Aug 2015 10:01:27 -0700 Message-ID: To: Stephen Farrell Content-Type: multipart/alternative; boundary=089e011771a9d3bc7a051c935c0e Archived-At: Cc: "draft-ietf-rtcweb-stun-consent-freshness@ietf.org" , "rtcweb-chairs@ietf.org" , "draft-ietf-rtcweb-stun-consent-freshness.shepherd@ietf.org" , "rtcweb@ietf.org" , The IESG , "draft-ietf-rtcweb-stun-consent-freshness.ad@ietf.org" Subject: Re: [rtcweb] Stephen Farrell's Discuss on draft-ietf-rtcweb-stun-consent-freshness-15: (with DISCUSS and COMMENT) X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 05 Aug 2015 17:02:13 -0000 --089e011771a9d3bc7a051c935c0e Content-Type: text/plain; charset=UTF-8 On Wed, Aug 5, 2015 at 9:55 AM, Stephen Farrell wrote: > > Hiya, > > On 05/08/15 14:22, Christer Holmberg wrote: > > Hi Stephen, > > > >> (2) WebRTC does not require STUN or TURN servers for some calls, > >> even if it does for many. Why is it ok to require such a server be > >> present in all calls (which I think this means) espcially when that > >> means exposing additional meta-data (calling parties in a case > >> where the servers weren't needed and call duration in all cases) to > >> those servers when that is not always necessary? > > > > Could you please refer to the text which you think mandates STUN or > > TURN servers? > > Sure, I think there were a couple of places, but I'd have to > track 'em down. I'll try update the ballot with that if it > turns out to be needed. (Be tomorrow before I get to that, > sorry.) > > > > > If there are no NATs, the STUN requests can be sent between the > > endpoints, without STUN or TURN servers. > > Really - so browsers will be able to act like a STUN server or > something? I didn't know that. Where's that described? ICE uses STUN in three ways: 1. For address discovery 2. To talk to TURN servers (TURN is based on STUN) 3. For ICE connectivity checks. Christer is referring to #3. -Ekr > S. > > > > > > Regards, > > > > Christer > > > > _______________________________________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/listinfo/rtcweb > --089e011771a9d3bc7a051c935c0e Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


On Wed, Aug 5, 2015 at 9:55 AM, Stephen Farrell <<= a href=3D"mailto:stephen.farrell@cs.tcd.ie" target=3D"_blank">stephen.farre= ll@cs.tcd.ie> wrote:

Hiya,

On 05/08/15 14:22, Christer Holmberg wrote:
> Hi Stephen,
>
>> (2) WebRTC does not require STUN or TURN servers for some calls, >> even if it does for many. Why is it ok to require such a server be=
>> present in all calls (which I think this means) espcially when tha= t
>> means exposing additional meta-data (calling parties in a case
>> where the servers weren't needed and call duration in all case= s) to
>> those servers when that is not always necessary?
>
> Could you please refer to the text which you think mandates STUN or > TURN servers?

Sure, I think there were a couple of places, but I'd have to
track 'em down. I'll try update the ballot with that if it
turns out to be needed. (Be tomorrow before I get to that,
sorry.)

>
> If there are no NATs, the STUN requests can be sent between the
> endpoints, without STUN or TURN servers.

Really - so browsers will be able to act like a STUN server or
something? I didn't know that. Where's that described?
=

ICE uses STUN in three ways:

1= . For address discovery
2. To talk to TURN servers (TURN is based= on STUN)
3. For ICE connectivity checks.

Christer is referring to #3.

-Ekr

=

S.


>
> Regards,
>
> Christer
>

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

--089e011771a9d3bc7a051c935c0e-- From nobody Wed Aug 5 10:06:37 2015 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 000561B3209; Wed, 5 Aug 2015 10:06:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.311 X-Spam-Level: X-Spam-Status: No, score=-4.311 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_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id f3HvCJBlhUIH; Wed, 5 Aug 2015 10:06:30 -0700 (PDT) Received: from mercury.scss.tcd.ie (mercury.scss.tcd.ie [134.226.56.6]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 07F781B31F7; Wed, 5 Aug 2015 10:06:30 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id C9263BE7C; Wed, 5 Aug 2015 18:06:28 +0100 (IST) Received: from mercury.scss.tcd.ie ([127.0.0.1]) by localhost (mercury.scss.tcd.ie [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9sVBYnnrFkyP; Wed, 5 Aug 2015 18:06:28 +0100 (IST) Received: from [134.226.36.180] (stephen-think.dsg.cs.tcd.ie [134.226.36.180]) by mercury.scss.tcd.ie (Postfix) with ESMTPSA id 6A11FBE88; Wed, 5 Aug 2015 18:06:27 +0100 (IST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cs.tcd.ie; s=mail; t=1438794387; bh=O692CJL1Mfbe8PyzEw5u0kavUQiU/jYbz0gJe+I4uOw=; h=Date:From:To:CC:Subject:References:In-Reply-To:From; b=uUo5kNZnY4cnilNhfMzmf4dbb3BGtxX7wK2UMU2g2ZQufHWFfGUoFkjwJjRGiQsTr nJGUVn4ZrjuEq77nz6rJrP4TX2yzAgiWFAEfpPe6Oi8nG2Wc8QX+0wSZBrQOLPLz7x +YhRWtyqCUue8s9HRqXscOx+ecKBZ/bY3OZD0HZU= Message-ID: <55C24293.5000603@cs.tcd.ie> Date: Wed, 05 Aug 2015 18:06:27 +0100 From: Stephen Farrell User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.8.0 MIME-Version: 1.0 To: Eric Rescorla References: <20150805130607.20844.70680.idtracker@ietfa.amsl.com> In-Reply-To: OpenPGP: id=D66EA7906F0B897FB2E97D582F3C8736805F8DA2; url= Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Archived-At: Cc: draft-ietf-rtcweb-stun-consent-freshness@ietf.org, rtcweb-chairs@ietf.org, draft-ietf-rtcweb-stun-consent-freshness.shepherd@ietf.org, "rtcweb@ietf.org" , The IESG , draft-ietf-rtcweb-stun-consent-freshness.ad@ietf.org Subject: Re: [rtcweb] Stephen Farrell's Discuss on draft-ietf-rtcweb-stun-consent-freshness-15: (with DISCUSS and COMMENT) X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 05 Aug 2015 17:06:33 -0000 Hiya. On 05/08/15 16:00, Eric Rescorla wrote: > On Wed, Aug 5, 2015 at 6:06 AM, Stephen Farrell > wrote: > >> Stephen Farrell has entered the following ballot position for >> draft-ietf-rtcweb-stun-consent-freshness-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-rtcweb-stun-consent-freshness/ >> >> >> >> ---------------------------------------------------------------------- >> DISCUSS: >> ---------------------------------------------------------------------- >> >> >> >> Apologies that these discuss points are maybe asking >> fairly fundamental questions. That could be that this >> is really the first of the new security things required >> by rtcweb to get to the IESG. Or maybe I'm misreading >> stuff here, if so, sorry;-) >> >> (1) Why call this "consent?" That term is (ab)used in >> many ways on the web, and adding another variation >> without a definition that distinguishes this from "click >> ok to my 200 page anti-privacy policy" or "remember that >> example.com is allowed use my camera/mic" seems like a >> terrible idea. I also don't see how this can ever be >> something to which a normal person can "consent" (i.e. >> consciously agree while fully understanding) so the term >> is IMO very misleading, and will I fear be used to >> mislead further. (See also some of the comments below - >> I do not think we ought be as fast and loose with this >> aleady terribly badly used term.) To summarise: I'd love >> if you did s/consent/anything-else/g but if not, please >> define consent here in a way that clearly and >> unambiguously distinguishes this usage from other abuses >> of the term. >> > > You should probably propose a new term at this point. Really? Happy to try (and fail:-) How'd "willing to take rtcweb traffic" work? I suspect it wouldn't though. But I'm not clear if you're agreeing that that term is problematic or just asking me to suggest something in the hope I realise the futility of what I'm requesting? > > > (2) WebRTC does not require STUN or TURN servers for >> some calls, even if it does for many. Why is it ok to >> require such a server be present in all calls (which I >> think this means) espcially when that means exposing >> additional meta-data (calling parties in a case where >> the servers weren't needed and call duration in all >> cases) to those servers when that is not always >> necessary? >> > > I'm not sure what you mean by "OK" and "require". > The physics of the > situation > is that if you want to do a call between two people not on the same network, > then you minimally need STUN. Sure. But if they're on the same n/w? Do we agree that in that case, there shouldn't be a need for a new STUN or TURN server in the call? And that if this draft meant such a server was needed even in that case, then that'd be an issue? > If you want it to (almost) always work you > need TURN. This isn't a spec requirement but just a result of the network > topology. As far as I know, the specs don't require that the site supply > a STUN/TURN server and the implementations don't either, but I'm not > sure what else you're looking for. So one non-inevitable consequence of the how this draft is written is that the STUN/TURN server gets to know the call duration. That could have been avoided I think if some other design had been chosen. Part of my question then is why exposing that additional meta-data to a server that most users won't know exists, and that is likely controlled by some entity the user has no clue is even involved in their calls, is acceptable. >> (3) (end of p5) You have a MUST NOT here that is >> depenedent on current browser implementations. Why is >> that an IETF thing and not a W3C thing? But more >> interestingly, can one securely use this protocol >> without the kind of JS vs. browser sandboxing etc that's >> needed in the web? If the answer is "no" then don't you >> need to say that this protocol can only safely be used >> for such implementations? (In section 2, which almost >> but not quite says that.) >> > > This is just only relevant in this case. It doesn't apply to non-JS > implementations. Not sure I'm following. Are you saying that this protocol would be safe even if there wasn't the split between JS and non-JS code running on the browser? If so, that's good. Cheers, S. > > -Ekr > > ---------------------------------------------------------------------- >> COMMENT: >> ---------------------------------------------------------------------- >> >> >> - abstract: why is only sending "media" mentioned here? >> What about data channels? And the body of the document >> in fact says this all applies to any non-ICE data and >> not only media. >> >> - intro: "initial consent to send by performing STUN" I >> do not find the word consent in either rfc5245 or 3489, >> but perhaps it is used somewhere else. Where? And with >> what meaning? >> >> - section 4, 2nd last para - I think the conclusion is >> bogus. An implementation knows when the keying it's >> using can not involve >1 (nominally operating) party. >> >> - 5.1, 3rd para: "Explicit consent to send is >> obtained..." is misleading. That is not a concept that >> an implementation of STUN will embody. >> >> - 5.1, What is the "Note" about TCP for? Why is this >> needed? >> >> >> _______________________________________________ >> rtcweb mailing list >> rtcweb@ietf.org >> https://www.ietf.org/mailman/listinfo/rtcweb >> > From nobody Wed Aug 5 10:12:35 2015 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B56531B32D1 for ; Wed, 5 Aug 2015 10:12:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SHgMMHR__Jdl for ; Wed, 5 Aug 2015 10:12:32 -0700 (PDT) Received: from mail.eeph.com (mail.eeph.com [192.135.198.155]) by ietfa.amsl.com (Postfix) with ESMTP id B5D421B32A6 for ; Wed, 5 Aug 2015 10:11:04 -0700 (PDT) Received: from [IPv6:2001:5a8:4:39d0:d5fe:6e06:c62e:6418] (unknown [IPv6:2001:5a8:4:39d0:d5fe:6e06:c62e:6418]) (Authenticated sender: matthew@eeph.com) by mail.eeph.com (Postfix) with ESMTPSA id B672E54841C for ; Wed, 5 Aug 2015 10:11:03 -0700 (PDT) Message-ID: <55C243AA.50309@matthew.at> Date: Wed, 05 Aug 2015 10:11:06 -0700 From: Matthew Kaufman User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.7.0 MIME-Version: 1.0 To: rtcweb@ietf.org References: <20150805161344.GA19492@lo.psyced.org> In-Reply-To: <20150805161344.GA19492@lo.psyced.org> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Archived-At: Subject: Re: [rtcweb] LAST CALL: Systematically de-anonymize dissidents with WebRTC (HOWTO) X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 05 Aug 2015 17:12:34 -0000 I don't believe this is how the IETF document editing process works. Please work with the authors on suggested changes, or submit a draft of your own. Matthew Kaufman On 8/5/2015 9:13 AM, carlo von lynX wrote: > Last chance to rebuke the following paragraph or > to introduce a prompt that says something like > "Do you want to allow to activate direct/ > P2P communications?" before I go noisy... > > >From https://webrtchacks.com/webrtc-notify/ >> Nefarious websites could potentially use this information to fingerprint individuals who do not want to be tracked. > That is not the main concern. Nefarious websites could systematically gather which visitors are using VPNs or Tor… which in some countries indicates they are very probably dissidents. With the real IP address in the pockets the authorities can go visit the potential dissident and see what she or he has been up to. They will most probably find evidence on the computer since dissidents in poor countries aren't particularely educated in operational security. Therefore a plugin that they first need to know about will not fix the problem in time. Thousands (or according to the other poster, millions) may be endangered by the introduction of WebRTC… even if these people never asked for any WebRTC in their browsers and weren't planning to use it for anything. > > From nobody Wed Aug 5 10:20:02 2015 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 007821A8769; Wed, 5 Aug 2015 10:19:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.311 X-Spam-Level: X-Spam-Status: No, score=-4.311 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_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9oOXwHFvWLVm; Wed, 5 Aug 2015 10:19:56 -0700 (PDT) Received: from mercury.scss.tcd.ie (mercury.scss.tcd.ie [134.226.56.6]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5EB901A6FED; Wed, 5 Aug 2015 10:19:56 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id 28E9ABE80; Wed, 5 Aug 2015 18:19:55 +0100 (IST) Received: from mercury.scss.tcd.ie ([127.0.0.1]) by localhost (mercury.scss.tcd.ie [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4kXSD0q7eWCj; Wed, 5 Aug 2015 18:19:55 +0100 (IST) Received: from [134.226.36.180] (stephen-think.dsg.cs.tcd.ie [134.226.36.180]) by mercury.scss.tcd.ie (Postfix) with ESMTPSA id E7AE9BE79; Wed, 5 Aug 2015 18:19:54 +0100 (IST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cs.tcd.ie; s=mail; t=1438795194; bh=qcYFQOEo6kl4gub+Mr9ef1623XBZ2k35LdQAclsSslY=; h=Date:From:To:CC:Subject:References:In-Reply-To:From; b=0zX+UBiN8IN+Kyf7BvIqONSlVqOtq8pd/KAZ4lmgm0rWuMe2cuMqu60urrBN8dInQ hhGxxKygfGJGIh1VcffvPAN2PLsCtmbnP7YoHsjuhVqAT0pZSfjwLiU1MbX8/AmAfA vq6KR6VdNkT5sQfNDbrudlU3V7xhIX4qPQMUBj9A= Message-ID: <55C245BA.9000504@cs.tcd.ie> Date: Wed, 05 Aug 2015 18:19:54 +0100 From: Stephen Farrell User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.8.0 MIME-Version: 1.0 To: Eric Rescorla References: <20150805130607.20844.70680.idtracker@ietfa.amsl.com> <7594FB04B1934943A5C02806D1A2204B348E9691@ESESSMB209.ericsson.se> <55C23FFD.8070201@cs.tcd.ie> In-Reply-To: OpenPGP: id=D66EA7906F0B897FB2E97D582F3C8736805F8DA2; url= Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Archived-At: Cc: "draft-ietf-rtcweb-stun-consent-freshness@ietf.org" , "rtcweb-chairs@ietf.org" , "draft-ietf-rtcweb-stun-consent-freshness.shepherd@ietf.org" , "rtcweb@ietf.org" , The IESG , "draft-ietf-rtcweb-stun-consent-freshness.ad@ietf.org" Subject: Re: [rtcweb] Stephen Farrell's Discuss on draft-ietf-rtcweb-stun-consent-freshness-15: (with DISCUSS and COMMENT) X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 05 Aug 2015 17:19:58 -0000 On 05/08/15 18:01, Eric Rescorla wrote: > On Wed, Aug 5, 2015 at 9:55 AM, Stephen Farrell > wrote: > >> >> Hiya, >> >> On 05/08/15 14:22, Christer Holmberg wrote: >>> Hi Stephen, >>> >>>> (2) WebRTC does not require STUN or TURN servers for some calls, >>>> even if it does for many. Why is it ok to require such a server be >>>> present in all calls (which I think this means) espcially when that >>>> means exposing additional meta-data (calling parties in a case >>>> where the servers weren't needed and call duration in all cases) to >>>> those servers when that is not always necessary? >>> >>> Could you please refer to the text which you think mandates STUN or >>> TURN servers? >> >> Sure, I think there were a couple of places, but I'd have to >> track 'em down. I'll try update the ballot with that if it >> turns out to be needed. (Be tomorrow before I get to that, >> sorry.) >> >>> >>> If there are no NATs, the STUN requests can be sent between the >>> endpoints, without STUN or TURN servers. >> >> Really - so browsers will be able to act like a STUN server or >> something? I didn't know that. Where's that described? > > > ICE uses STUN in three ways: > > 1. For address discovery > 2. To talk to TURN servers (TURN is based on STUN) > 3. For ICE connectivity checks. > > Christer is referring to #3. Ok, and what happens with this freshness stuff in that scenario? (Apologies if its in this or some other draft and I missed it) S > > -Ekr > > >> S. >> >> >>> >>> Regards, >>> >>> Christer >>> >> >> _______________________________________________ >> rtcweb mailing list >> rtcweb@ietf.org >> https://www.ietf.org/mailman/listinfo/rtcweb >> > From nobody Wed Aug 5 10:23:15 2015 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 210F01B324D for ; Wed, 5 Aug 2015 10:23:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.977 X-Spam-Level: X-Spam-Status: No, score=-1.977 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mYSZ5kO7TejY for ; Wed, 5 Aug 2015 10:23:10 -0700 (PDT) Received: from mail-wi0-f170.google.com (mail-wi0-f170.google.com [209.85.212.170]) (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 107121B321C for ; Wed, 5 Aug 2015 10:23:10 -0700 (PDT) Received: by wicgj17 with SMTP id gj17so201639866wic.1 for ; Wed, 05 Aug 2015 10:23:08 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type; bh=YdKL5HwRtOo3PGtkUwMmjF0okCIrWJQ6TAir300SQT8=; b=apQf6cV0dgUKR5Vktu/mr9fFi4Pu8Dh1Q8L9xGLfRKugJrva7pr0QJ/CRtyzj1PN04 EI/2LPnTjJonZs/puqlLp3QqCWnXNqYLhvSzl5joa0EXPKbibW00bfkYdTuDKu9XCU1a 0mBrbhnude01SETKOO2D4R7sNMkJDXS/TLn84vV16SeJSw6pvHmZ/1PUO28WqsVYBs8n Ky+7s706J54E7VuEHdp86ENOhrwUQQbBCZi10zT2/mgMGilP9bL8Q36D0dx8MJodt8yp RU3KhwHZM6EZnm3REiKVIvxxV3wT3UXwg/sYJb2dK5pGqCPur7AyrHHYo9qLUfK6cwc+ excQ== X-Gm-Message-State: ALoCoQlzN8L+6CrTLicQ/jFKl/LqnrUQg/enyUne+5W1ZFQyDXkboLZdVk+aT8GcgiAf3SIhfIPf X-Received: by 10.180.74.148 with SMTP id t20mr585994wiv.31.1438795388820; Wed, 05 Aug 2015 10:23:08 -0700 (PDT) MIME-Version: 1.0 Received: by 10.27.85.86 with HTTP; Wed, 5 Aug 2015 10:22:29 -0700 (PDT) In-Reply-To: <55C245BA.9000504@cs.tcd.ie> References: <20150805130607.20844.70680.idtracker@ietfa.amsl.com> <7594FB04B1934943A5C02806D1A2204B348E9691@ESESSMB209.ericsson.se> <55C23FFD.8070201@cs.tcd.ie> <55C245BA.9000504@cs.tcd.ie> From: Eric Rescorla Date: Wed, 5 Aug 2015 10:22:29 -0700 Message-ID: To: Stephen Farrell Content-Type: multipart/alternative; boundary=f46d043c7f5c0e3501051c93a822 Archived-At: Cc: "draft-ietf-rtcweb-stun-consent-freshness@ietf.org" , "rtcweb-chairs@ietf.org" , "draft-ietf-rtcweb-stun-consent-freshness.shepherd@ietf.org" , "rtcweb@ietf.org" , The IESG , "draft-ietf-rtcweb-stun-consent-freshness.ad@ietf.org" Subject: Re: [rtcweb] Stephen Farrell's Discuss on draft-ietf-rtcweb-stun-consent-freshness-15: (with DISCUSS and COMMENT) X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 05 Aug 2015 17:23:12 -0000 --f46d043c7f5c0e3501051c93a822 Content-Type: text/plain; charset=UTF-8 This freshness stuff is also about #3. Namely, it's about the endpoints doing continual STUN connectivity checks between each other. -Ekr On Wed, Aug 5, 2015 at 10:19 AM, Stephen Farrell wrote: > > > On 05/08/15 18:01, Eric Rescorla wrote: > > On Wed, Aug 5, 2015 at 9:55 AM, Stephen Farrell < > stephen.farrell@cs.tcd.ie> > > wrote: > > > >> > >> Hiya, > >> > >> On 05/08/15 14:22, Christer Holmberg wrote: > >>> Hi Stephen, > >>> > >>>> (2) WebRTC does not require STUN or TURN servers for some calls, > >>>> even if it does for many. Why is it ok to require such a server be > >>>> present in all calls (which I think this means) espcially when that > >>>> means exposing additional meta-data (calling parties in a case > >>>> where the servers weren't needed and call duration in all cases) to > >>>> those servers when that is not always necessary? > >>> > >>> Could you please refer to the text which you think mandates STUN or > >>> TURN servers? > >> > >> Sure, I think there were a couple of places, but I'd have to > >> track 'em down. I'll try update the ballot with that if it > >> turns out to be needed. (Be tomorrow before I get to that, > >> sorry.) > >> > >>> > >>> If there are no NATs, the STUN requests can be sent between the > >>> endpoints, without STUN or TURN servers. > >> > >> Really - so browsers will be able to act like a STUN server or > >> something? I didn't know that. Where's that described? > > > > > > ICE uses STUN in three ways: > > > > 1. For address discovery > > 2. To talk to TURN servers (TURN is based on STUN) > > 3. For ICE connectivity checks. > > > > Christer is referring to #3. > > Ok, and what happens with this freshness stuff in that > scenario? (Apologies if its in this or some other draft > and I missed it) > > S > > > > > -Ekr > > > > > >> S. > >> > >> > >>> > >>> Regards, > >>> > >>> Christer > >>> > >> > >> _______________________________________________ > >> rtcweb mailing list > >> rtcweb@ietf.org > >> https://www.ietf.org/mailman/listinfo/rtcweb > >> > > > --f46d043c7f5c0e3501051c93a822 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
This freshness stuff is also about #3. Namely, it's ab= out the endpoints
doing continual STUN connectivity checks between each= other.

-Ekr


On Wed, Aug 5, 2015 at 10:19 AM, Stephen= Farrell <stephen.farrell@cs.tcd.ie> wrote:


On 05/08/15 18:01, Eric Rescorla wrote:
> On Wed, Aug 5, 2015 at 9:55 AM, Stephen Farrell <stephen.farrell@cs.tcd.ie>
> wrote:
>
>>
>> Hiya,
>>
>> On 05/08/15 14:22, Christer Holmberg wrote:
>>> Hi Stephen,
>>>
>>>> (2) WebRTC does not require STUN or TURN servers for some = calls,
>>>> even if it does for many. Why is it ok to require such a s= erver be
>>>> present in all calls (which I think this means) espcially = when that
>>>> means exposing additional meta-data (calling parties in a = case
>>>> where the servers weren't needed and call duration in = all cases) to
>>>> those servers when that is not always necessary?
>>>
>>> Could you please refer to the text which you think mandates ST= UN or
>>> TURN servers?
>>
>> Sure, I think there were a couple of places, but I'd have to >> track 'em down. I'll try update the ballot with that if it=
>> turns out to be needed. (Be tomorrow before I get to that,
>> sorry.)
>>
>>>
>>> If there are no NATs, the STUN requests can be sent between th= e
>>> endpoints, without STUN or TURN servers.
>>
>> Really - so browsers will be able to act like a STUN server or
>> something? I didn't know that. Where's that described?
>
>
> ICE uses STUN in three ways:
>
> 1. For address discovery
> 2. To talk to TURN servers (TURN is based on STUN)
> 3. For ICE connectivity checks.
>
> Christer is referring to #3.

Ok, and what happens with this freshness stuff in that
scenario? (Apologies if its in this or some other draft
and I missed it)

S

>
> -Ekr
>
>
>> S.
>>
>>
>>>
>>> Regards,
>>>
>>> Christer
>>>
>>
>> _______________________________________________
>> rtcweb mailing list
>> rtcweb@ietf.org
>> https://www.ietf.org/mailman/listinfo/rtcweb
>>
>

--f46d043c7f5c0e3501051c93a822-- From nobody Wed Aug 5 10:39:46 2015 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C44B81A88A5 for ; Wed, 5 Aug 2015 10:39:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.977 X-Spam-Level: X-Spam-Status: No, score=-1.977 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7] autolearn=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 YnQdVFlO_WLA for ; Wed, 5 Aug 2015 10:39:42 -0700 (PDT) Received: from mail-wi0-f177.google.com (mail-wi0-f177.google.com [209.85.212.177]) (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 BCE891A888A for ; Wed, 5 Aug 2015 10:39:38 -0700 (PDT) Received: by wibhh20 with SMTP id hh20so34692487wib.0 for ; Wed, 05 Aug 2015 10:39:37 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type; bh=7cmZKhVAsb38nHb0gqG6qnIx+CgHnbYo50qQnDl9VV8=; b=jTxX6OblKl+R5gKj08RU8sl2bZSHAjeveI7fy27s/wpHAtFVt7SE6plECJhsqK2/D+ Jjno8iSJyDlO7ZlKkgux77d+1Zs7lCAxtyEiUOjytXuqlMMY1CQrbY+EWbJFmmtCPa0k XTgYrch7HiMmGnS8gTjD6L+YtcsZGAq6jf4dVwfBujRKoG9gZwZvfirA9VSsyYhLdpx9 QASECsLRsgUgWQdIpVaa/R9978CHMGRgmn+E7ZcRd3JMmnkYI4f+9ct6tf3/lf1Do6Y1 cyoxnYPn79KQ37CFeKa7mi6wTVqn1zbp+CbpO8YzHM+8pVOkT5rOYAPAHcBS+B/H1vsH 4lVQ== X-Gm-Message-State: ALoCoQmbpMUvFyPiq03nG2NdjOzjTxfUDfjCBv/Kxm2hvwO6vZQcPkmYlueA/k8p6WQz/mWp9xdr X-Received: by 10.180.75.78 with SMTP id a14mr798860wiw.68.1438796377097; Wed, 05 Aug 2015 10:39:37 -0700 (PDT) MIME-Version: 1.0 Received: by 10.27.85.86 with HTTP; Wed, 5 Aug 2015 10:38:57 -0700 (PDT) In-Reply-To: <55C24293.5000603@cs.tcd.ie> References: <20150805130607.20844.70680.idtracker@ietfa.amsl.com> <55C24293.5000603@cs.tcd.ie> From: Eric Rescorla Date: Wed, 5 Aug 2015 10:38:57 -0700 Message-ID: To: Stephen Farrell Content-Type: multipart/alternative; boundary=f46d0438eb9df6feb1051c93e2ba Archived-At: Cc: draft-ietf-rtcweb-stun-consent-freshness , rtcweb-chairs@ietf.org, "draft-ietf-rtcweb-stun-consent-freshness.shepherd" , "rtcweb@ietf.org" , The IESG , "draft-ietf-rtcweb-stun-consent-freshness.ad" Subject: Re: [rtcweb] Stephen Farrell's Discuss on draft-ietf-rtcweb-stun-consent-freshness-15: (with DISCUSS and COMMENT) X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 05 Aug 2015 17:39:44 -0000 --f46d0438eb9df6feb1051c93e2ba Content-Type: text/plain; charset=UTF-8 On Wed, Aug 5, 2015 at 10:06 AM, Stephen Farrell wrote: > > Hiya. > > On 05/08/15 16:00, Eric Rescorla wrote: > > On Wed, Aug 5, 2015 at 6:06 AM, Stephen Farrell < > stephen.farrell@cs.tcd.ie> > > wrote: > > > >> Stephen Farrell has entered the following ballot position for > >> draft-ietf-rtcweb-stun-consent-freshness-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-rtcweb-stun-consent-freshness/ > >> > >> > >> > >> ---------------------------------------------------------------------- > >> DISCUSS: > >> ---------------------------------------------------------------------- > >> > >> > >> > >> Apologies that these discuss points are maybe asking > >> fairly fundamental questions. That could be that this > >> is really the first of the new security things required > >> by rtcweb to get to the IESG. Or maybe I'm misreading > >> stuff here, if so, sorry;-) > >> > >> (1) Why call this "consent?" That term is (ab)used in > >> many ways on the web, and adding another variation > >> without a definition that distinguishes this from "click > >> ok to my 200 page anti-privacy policy" or "remember that > >> example.com is allowed use my camera/mic" seems like a > >> terrible idea. I also don't see how this can ever be > >> something to which a normal person can "consent" (i.e. > >> consciously agree while fully understanding) so the term > >> is IMO very misleading, and will I fear be used to > >> mislead further. (See also some of the comments below - > >> I do not think we ought be as fast and loose with this > >> aleady terribly badly used term.) To summarise: I'd love > >> if you did s/consent/anything-else/g but if not, please > >> define consent here in a way that clearly and > >> unambiguously distinguishes this usage from other abuses > >> of the term. > >> > > > > You should probably propose a new term at this point. > > Really? Happy to try (and fail:-) How'd "willing to take > rtcweb traffic" work? I suspect it wouldn't though. > > But I'm not clear if you're agreeing that that term > is problematic or just asking me to suggest something in > the hope I realise the futility of what I'm requesting? Maybe something between the two. > > I'm not sure what you mean by "OK" and "require". > > The physics of the > > situation > > is that if you want to do a call between two people not on the same > network, > > then you minimally need STUN. > > Sure. But if they're on the same n/w? Do we agree that > in that case, there shouldn't be a need for a new STUN > or TURN server in the call? Yes. > And that if this draft meant > such a server was needed even in that case, then that'd > be an issue? Yes, I think it shouldn't require that. > If you want it to (almost) always work you > > need TURN. This isn't a spec requirement but just a result of the network > > topology. As far as I know, the specs don't require that the site supply > > a STUN/TURN server and the implementations don't either, but I'm not > > sure what else you're looking for. > > So one non-inevitable consequence of the how this draft > is written is that the STUN/TURN server gets to know the > call duration. This isn't correct. The STUN server doesn't know and the TURN server only knows if the relay candidate is slected. > That could have been avoided I think if > some other design had been chosen. Part of my question > then is why exposing that additional meta-data to a server > that most users won't know exists, and that is likely > controlled by some entity the user has no clue is even > involved in their calls, is acceptable. I don't understand what you are concerned about here. >> (3) (end of p5) You have a MUST NOT here that is > >> depenedent on current browser implementations. Why is > >> that an IETF thing and not a W3C thing? But more > >> interestingly, can one securely use this protocol > >> without the kind of JS vs. browser sandboxing etc that's > >> needed in the web? If the answer is "no" then don't you > >> need to say that this protocol can only safely be used > >> for such implementations? (In section 2, which almost > >> but not quite says that.) > >> > > > > This is just only relevant in this case. It doesn't apply to non-JS > > implementations. > > Not sure I'm following. Are you saying that this protocol > would be safe even if there wasn't the split between JS > and non-JS code running on the browser? If so, that's good. > I'm saying that the primary concern of this document is that attackers will force people's Web browsers to spam other people with RTP traffic and that that isn't as big an issue in non-Web contexts, which is why we don't do continuing consent for (say) SIP + ICE. -Ekr > Cheers, > S. > > > > > -Ekr > > > > ---------------------------------------------------------------------- > >> COMMENT: > >> ---------------------------------------------------------------------- > >> > >> > >> - abstract: why is only sending "media" mentioned here? > >> What about data channels? And the body of the document > >> in fact says this all applies to any non-ICE data and > >> not only media. > >> > >> - intro: "initial consent to send by performing STUN" I > >> do not find the word consent in either rfc5245 or 3489, > >> but perhaps it is used somewhere else. Where? And with > >> what meaning? > >> > >> - section 4, 2nd last para - I think the conclusion is > >> bogus. An implementation knows when the keying it's > >> using can not involve >1 (nominally operating) party. > >> > >> - 5.1, 3rd para: "Explicit consent to send is > >> obtained..." is misleading. That is not a concept that > >> an implementation of STUN will embody. > >> > >> - 5.1, What is the "Note" about TCP for? Why is this > >> needed? > >> > >> > >> _______________________________________________ > >> rtcweb mailing list > >> rtcweb@ietf.org > >> https://www.ietf.org/mailman/listinfo/rtcweb > >> > > > --f46d0438eb9df6feb1051c93e2ba Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


On Wed, Aug 5, 2015 at 10:06 AM, Stephen Farrell <= stephen.farr= ell@cs.tcd.ie> wrote:

Hiya.

On 05/08/15 16:00, Eric Rescorla wrote:
> On Wed, Aug 5, 2015 at 6:06 AM, Stephen Farrell <stephen.farrell@cs.tcd.ie&= gt;
> wrote:
>
>> Stephen Farrell has entered the following ballot position for
>> draft-ietf-rtcweb-stun-consent-freshness-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.o= rg/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://datatrack= er.ietf.org/doc/draft-ietf-rtcweb-stun-consent-freshness/
>>
>>
>>
>> ------------------------------------------------------------------= ----
>> DISCUSS:
>> ------------------------------------------------------------------= ----
>>
>>
>>
>> Apologies that these discuss points are maybe asking
>> fairly fundamental questions.=C2=A0 That could be that this
>> is really the first of the new security things required
>> by rtcweb to get to the IESG.=C2=A0 Or maybe I'm misreading >> stuff here, if so, sorry;-)
>>
>> (1) Why call this "consent?" That term is (ab)used in >> many ways on the web, and adding another variation
>> without a definition that distinguishes this from "click
>> ok to my 200 page anti-privacy policy" or "remember that=
>> example.com is allowed use my camera/mic" seems like a
>> terrible idea. I also don't see how this can ever be
>> something to which a normal person can "consent" (i.e. >> consciously agree while fully understanding) so the term
>> is IMO very misleading, and will I fear be used to
>> mislead further.=C2=A0 (See also some of the comments below -
>> I do not think we ought be as fast and loose with this
>> aleady terribly badly used term.) To summarise: I'd love
>> if you did s/consent/anything-else/g but if not, please
>> define consent here in a way that clearly and
>> unambiguously distinguishes this usage from other abuses
>> of the term.
>>
>
> You should probably propose a new term at this point.

Really? Happy to try (and fail:-) How'd "willing to ta= ke
rtcweb traffic" work? I suspect it wouldn't though.

But I'm not clear if you're agreeing that that term
is problematic or just asking me to suggest something in
the hope I realise the futility of what I'm requesting?

Maybe something between the two.

=
=C2=A0
> I'm not sure what you mean by "OK" and "require&quo= t;.
> The physics of the
> situation
> is that if you want to do a call between two people not on the same ne= twork,
> then you minimally need STUN.

Sure. But if they're on the same n/w? Do we agree that
in that case, there shouldn't be a need for a new STUN
or TURN server in the call?

Yes.
=
=C2=A0
And that if this= draft meant
such a server was needed even in that case, then that'd
be an issue?

Yes, I think it shouldn't = require that.
=C2=A0

> If you want it to (almost) always work you
> need TURN. This isn't a spec requirement but just a result of the = network
> topology. As far as I know, the specs don't require that the site = supply
> a STUN/TURN server and the implementations don't either, but I'= ;m not
> sure what else you're looking for.

So one non-inevitable consequence of the how this draft
is written is that the STUN/TURN server gets to know the
call duration.

This isn't correct. The= STUN server doesn't know and the TURN server only
knows if t= he relay candidate is slected.


=C2= =A0
That could have been avoided I thin= k if
some other design had been chosen. Part of my question
then is why exposing that additional meta-data to a server
that most users won't know exists, and that is likely
controlled by some entity the user has no clue is even
involved in their calls, is acceptable.

I d= on't understand what you are concerned about here.

=



>> (3) (end of p5) You have a MUST NOT here that is
>> depenedent on current browser implementations. Why is
>> that an IETF thing and not a W3C thing? But more
>> interestingly, can one securely use this protocol
>> without the kind of JS vs. browser sandboxing etc that's
>> needed in the web? If the answer is "no" then don't = you
>> need to say that this protocol can only safely be used
>> for such implementations? (In section 2, which almost
>> but not quite says that.)
>>
>
> This is just only relevant in this case. It doesn't apply to non-J= S
> implementations.

Not sure I'm following. Are you saying that this protocol
would be safe even if there wasn't the split between JS
and non-JS code running on the browser? If so, that's good.

I'm saying that the primary concern of this do= cument is that attackers
will force people's Web browsers to = spam other people with RTP traffic
and that that isn't as big= an issue in non-Web contexts, which is why
we don't do conti= nuing consent for (say) SIP + ICE.

-Ekr
= =C2=A0
Cheers,
S.

>
> -Ekr
>
> ----------------------------------------------------------------------=
>> COMMENT:
>> ------------------------------------------------------------------= ----
>>
>>
>> - abstract: why is only sending "media" mentioned here?<= br> >> What about data channels?=C2=A0 And the body of the document
>> in fact says this all applies to any non-ICE data and
>> not only media.
>>
>> - intro: "initial consent to send by performing STUN" I<= br> >> do not find the word consent in either rfc5245 or 3489,
>> but perhaps it is used somewhere else. Where?=C2=A0 And with
>> what meaning?
>>
>> - section 4, 2nd last para - I think the conclusion is
>> bogus.=C2=A0 An implementation knows when the keying it's
>> using can not involve >1 (nominally operating) party.
>>
>> - 5.1, 3rd para: "Explicit consent to send is
>> obtained..." is misleading. That is not a concept that
>> an implementation of STUN will embody.
>>
>> - 5.1, What is the "Note" about TCP for? Why is this
>> needed?
>>
>>
>> _______________________________________________
>> rtcweb mailing list
>> rtcweb@ietf.o= rg
>> https://www.ietf.org/mailman/listinfo/rtcweb
>>
>

--f46d0438eb9df6feb1051c93e2ba-- From nobody Wed Aug 5 10:46:54 2015 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 744471A88E7 for ; Wed, 5 Aug 2015 10:46:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ADmtATgo08nK for ; Wed, 5 Aug 2015 10:46:51 -0700 (PDT) Received: from na01-bl2-obe.outbound.protection.outlook.com (mail-bl2on0063.outbound.protection.outlook.com [65.55.169.63]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A21EE1A88F9 for ; Wed, 5 Aug 2015 10:46:48 -0700 (PDT) Received: from SN1PR0301MB1551.namprd03.prod.outlook.com (10.162.129.157) by SN1PR0301MB1551.namprd03.prod.outlook.com (10.162.129.157) with Microsoft SMTP Server (TLS) id 15.1.225.19; Wed, 5 Aug 2015 17:46:46 +0000 Received: from SN1PR0301MB1551.namprd03.prod.outlook.com ([10.162.129.157]) by SN1PR0301MB1551.namprd03.prod.outlook.com ([10.162.129.157]) with mapi id 15.01.0225.018; Wed, 5 Aug 2015 17:46:46 +0000 From: "Asveren, Tolga" To: Roman Shpount , "Rauschenbach, Uwe (Nokia - DE/Munich)" Thread-Topic: [rtcweb] What the gateway draft should say about mux/non-mux Thread-Index: AQHQy8DcUgzWwtVCmk+8q67BCzjC45316kQQgAAD5oCAAACVsIAAAj2AgAPw2gCAAEFTAIAC/BgAgACAxgCAABQlsA== Date: Wed, 5 Aug 2015 17:46:46 +0000 Message-ID: References: <7594FB04B1934943A5C02806D1A2204B348E29DA@ESESSMB209.ericsson.se> <67196805-ED4E-49EA-83AA-3F4C37B5BC50@gmail.com> <7594FB04B1934943A5C02806D1A2204B348E2D52@ESESSMB209.ericsson.se> <56C2F665D49E0341B9DF5938005ACDF8196FF3ED@DEMUMBX005.nsn-intra.net> <56C2F665D49E0341B9DF5938005ACDF8196FF450@DEMUMBX005.nsn-intra.net> <786615F3A85DF44AA2A76164A71FE1AC7ADB690D@FR711WXCHMBA03.zeu.alcatel-lucent.com> <56C2F665D49E0341B9DF5938005ACDF81970EDC1@DEMUMBX005.nsn-intra.net> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=tasveren@sonusnet.com; x-originating-ip: [50.182.164.80] x-microsoft-exchange-diagnostics: 1; SN1PR0301MB1551; 5:hApPKpD3t7IkY5OyA61HEYxmP9X8RMPZYTkJG9Yi4D/JvRCJXP4WCWBmo2fwp2S7CzkqBimhH69G2jrgFqyvR6qwWWKYnC9SSkTKP8IlNy/Wl5U4cAjIuCTOSgZy/rZuqpl3DfTxycRI3gA8KIrrog==; 24:sNfjon5XQdMWGsOcTlONak75NMvi9W0xlYUxNGg19LysL/5jjqEUkAILZ8CITTxmRihquZ/sX581nzgDRtfhTQkDf9ic4YWNao7nalUxkRQ=; 20:eGrBkRx+zSRDWXfnt9MBJNmg4D7gGqnZHbMhJXjyWLRz+0C40aezRCbUYIwxOyqE8WXtJw4tdIuGyHJCTzk0eg== x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:SN1PR0301MB1551; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(108003899814671); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(601004)(5005006)(3002001); SRVR:SN1PR0301MB1551; BCL:0; PCL:0; RULEID:; SRVR:SN1PR0301MB1551; x-forefront-prvs: 06592CCE58 x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(24454002)(164054003)(189002)(377454003)(199003)(105586002)(77156002)(76576001)(122556002)(93886004)(106356001)(5003600100002)(40100003)(86362001)(189998001)(62966003)(5001830100001)(5002640100001)(5001770100001)(81156007)(97736004)(99286002)(5001860100001)(68736005)(102836002)(106116001)(2900100001)(15975445007)(2950100001)(77096005)(92566002)(5001960100002)(64706001)(54356999)(19580405001)(66066001)(4001540100001)(19300405004)(76176999)(101416001)(33656002)(74316001)(19609705001)(2656002)(19625215002)(46102003)(19580395003)(87936001)(10400500002)(16236675004)(50986999); DIR:OUT; SFP:1101; SCL:1; SRVR:SN1PR0301MB1551; H:SN1PR0301MB1551.namprd03.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; MX:1; A:1; LANG:en; received-spf: None (protection.outlook.com: sonusnet.com does not designate permitted sender hosts) Content-Type: multipart/alternative; boundary="_000_SN1PR0301MB15516198E46F9E8E3C0F2605B2750SN1PR0301MB1551_" MIME-Version: 1.0 X-OriginatorOrg: sonusnet.com X-MS-Exchange-CrossTenant-originalarrivaltime: 05 Aug 2015 17:46:46.1214 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 29a671dc-ed7e-4a54-b1e5-8da1eb495dc3 X-MS-Exchange-Transport-CrossTenantHeadersStamped: SN1PR0301MB1551 Archived-At: Cc: "" Subject: Re: [rtcweb] What the gateway draft should say about mux/non-mux X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 05 Aug 2015 17:46:53 -0000 --_000_SN1PR0301MB15516198E46F9E8E3C0F2605B2750SN1PR0301MB1551_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 aS0gSSBodW1ibHkgZGlzYWdyZWUgdGhhdCB1c2luZyBkaWZmZXJlbnQgUW9TIFJUQ1AvUlRQLCBl LmcuIGRpZmZlcmVudCBEaWZmU2VydiB2YWx1ZXMgLCBzaG91bGQgYmUgZGlzbWlzc2VkLg0KaWkt IExldCBtZSBhbHNvIGFkZCBhbm90aGVyIHJlYXNvbiB3aHkgbm8tcnRjcC1tdXggbWF5IGJlIG5l ZWRlZDogSW1wbGVtZW50YXRpb24gZGlmZmljdWx0aWVzIGluIGNlcnRhaW4gR1dzLg0KDQpDb25z aWRlcmluZyB0aGF0IHRoZXJlIGlzIGFscmVhZHkgYSBuZWdvdGlhdGlvbiBtZWNoYW5pc20gZm9y IHJ0Y3AtbXV4IHN1cHBvcnQsIHRoYXQgaXQgY2FuIGJlIGRlLWZhY3RvIG1hbmRhdGVkIGJ5IHRo ZSBjaG9pY2Ugb2YgYnJvd3NlcnMgZm9yIEludGVybmV0LCBJIHRoaW5rIHdoYXQgQ2hyaXN0ZXIv QWxicmVjaHQgc3VnZ2VzdGVkIGlzIHRoZSByaWdodCB3YXkgdG8gbW92ZSBmb3J3YXJkOiBwcm92 aWRlIGNsYXJpZmljYXRpb25zIGZvciB2YWd1ZSBwb2ludHMuIEkgZG9u4oCZdCB1bmRlcnN0YW5k IHdoeSBsYWNrIG9mIGNsYXJpdHkgaW4gZXhpc3Rpbmcgc3BlY2lmaWNhdGlvbnMgc2hvdWxkIGNh dXNlIGltcG9zaW5nIHJlc3RyaWN0aW9ucy4gVGhpcyB3b3VsZCBiZSBha2luIHRvIGRyb3BwaW5n IGEgZmVhdHVyZSBkdWUgdG8gYSBidWcuIEluIHRoaXMgY2FzZSwgdGhlIOKAnGJ1Z+KAnSBpcyBs YWNrIG9mIGNsYXJpdHkgaW4gbm9ybWF0aXZlIHNwZWNpZmljYXRpb25zIGFuZCBpdCBjYW4gYmUg YWRkcmVzc2VkIGJ5IGZ1cnRoZXIgc3BlY2lmaWNhdGlvbi4NCg0KVGhhbmtzLA0KVG9sZ2ENCg0K RnJvbTogUm9tYW4gU2hwb3VudCBbbWFpbHRvOnJvbWFuQHRlbHVyaXguY29tXQ0KU2VudDogV2Vk bmVzZGF5LCBBdWd1c3QgMDUsIDIwMTUgMTI6MjkgUE0NClRvOiBSYXVzY2hlbmJhY2gsIFV3ZSAo Tm9raWEgLSBERS9NdW5pY2gpIDx1d2UucmF1c2NoZW5iYWNoQG5va2lhLmNvbT4NCkNjOiBleHQg RXJpYyBSZXNjb3JsYSA8ZWtyQHJ0Zm0uY29tPjsgU2Nod2FyeiwgQWxicmVjaHQgKEFsYnJlY2h0 KSA8YWxicmVjaHQuc2Nod2FyekBhbGNhdGVsLWx1Y2VudC5jb20+OyBBc3ZlcmVuLCBUb2xnYSA8 dGFzdmVyZW5Ac29udXNuZXQuY29tPjsgQ2hyaXN0ZXIgSG9sbWJlcmcgPGNocmlzdGVyLmhvbG1i ZXJnQGVyaWNzc29uLmNvbT47IEJlcm5hcmQgQWJvYmEgPGJlcm5hcmQuYWJvYmFAZ21haWwuY29t PjsgPHJ0Y3dlYkBpZXRmLm9yZz4gPHJ0Y3dlYkBpZXRmLm9yZz4NClN1YmplY3Q6IFJlOiBbcnRj d2ViXSBXaGF0IHRoZSBnYXRld2F5IGRyYWZ0IHNob3VsZCBzYXkgYWJvdXQgbXV4L25vbi1tdXgN Cg0KT24gV2VkLCBBdWcgNSwgMjAxNSBhdCA0OjQ3IEFNLCBSYXVzY2hlbmJhY2gsIFV3ZSAoTm9r aWEgLSBERS9NdW5pY2gpIDx1d2UucmF1c2NoZW5iYWNoQG5va2lhLmNvbTxtYWlsdG86dXdlLnJh dXNjaGVuYmFjaEBub2tpYS5jb20+PiB3cm90ZToNCk1lZGlhIGdhdGV3YXkgaW1wbGVtZW50YXRp b25zIGFjY29yZGluZyB0byAzR1BQIFRTIDIzLjIyOCBtYXkgbm90IHN1cHBvcnQgcnRjcC1tdXgs IGFzIHJ0Y3AtbXV4IGlzIG9wdGlvbmFsIHRoZXJlLg0KU28gaWYgd2UgZHJvcCBub24tbXV4IHN1 cHBvcnQgZnJvbSB3ZWIgYnJvd3NlcnMsIHRob3NlIG1lZGlhIGdhdGV3YXlzIHRoYXQgaGF2ZSBu b3QgaW1wbGVtZW50ZWQgcnRjcC1tdXggd2lsbCBzdG9wIGludGVyb3BlcmF0aW5nLg0KDQoNCkZp cnN0IG9mIGFsbCwgZG8geW91IGtub3cgb2YgYW55IFdlYlJUQyB0byBJTVMgZ2F0ZXdheXMgdGhh dCBkbyBub3QgaW1wbGVtZW50IHJ0Y3AtbXV4IG9uIHRoZSBXZWJSVEMgc2lkZT8gSSBzdHJvbmds eSBzdXNwZWN0IHRoZXJlIGFyZSBub25lLg0KDQpTZWNvbmQsIHRoZSBvbmx5IHJlYXNvbnMgbm90 IHRvIHVzZSBydGNwLW11eCB0aGF0IEkgY2FuIHRoaW5rIG9mIGFyZSB0aGUgZm9sbG93aW5nOg0K DQoxLiBVc2luZyBkaWZmZXJlbnQgUU9TIHNldHRpbmdzIGZvciBSVENQIHZzIFJUUA0KMi4gU2Vu ZGluZyBSVENQIHRvIGEgZGlmZmVyZW50IGRldmljZSBmcm9tIFJUUA0KDQpJIGRvIG5vdCB0aGlu ayB0aGUgZmlyc3QgdXNlIGNhc2Ugd2FycmFudHMgbWFraW5nIHJ0Y3AtbXV4IG9wdGlvbmFsLCBz aW5jZSwgcHJhY3RpY2FsbHkgbm8gb25lIGRvZXMgdGhpcy4NClNlY29uZCB1c2UgY2FzZSBpcyBh bHNvIGZhaXJseSBtYXJnaW5hbC4gUGx1cyBpdCBjYW4gYmUgaGFuZGxlZCBieSB0aGUgZ2F0ZXdh eSB3aGljaCBjYW4gc2VuZCBSVENQIHRvIG9uZSBkZXZpY2UgYW5kIFJUUCB0byBhbm90aGVyLg0K DQpTbywgdW5sZXNzIHNvbWVvbmUgY2FuIGNvbWUgdXAgd2l0aCBhIHVzZSBjYXNlIHdoeSBSVFAg YW5kIFJUQ1Agc2hvdWxkIHVzZSBkaWZmZXJlbnQgdHJhbnNwb3J0cywgSSB0aGluayBydGNwLW11 eCBzaG91bGQgYmUgbWFuZGF0b3J5Lg0KDQpSZWdhcmRzLA0KX19fX19fX19fX19fX18NClJvbWFu IFNocG91bnQNCg== --_000_SN1PR0301MB15516198E46F9E8E3C0F2605B2750SN1PR0301MB1551_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 IkNhbWJyaWEgTWF0aCI7DQoJcGFub3NlLTE6MiA0IDUgMyA1IDQgNiAzIDIgNDt9DQpAZm9udC1m YWNlDQoJe2ZvbnQtZmFtaWx5OkNhbGlicmk7DQoJcGFub3NlLTE6MiAxNSA1IDIgMiAyIDQgMyAy IDQ7fQ0KLyogU3R5bGUgRGVmaW5pdGlvbnMgKi8NCnAuTXNvTm9ybWFsLCBsaS5Nc29Ob3JtYWws IGRpdi5Nc29Ob3JtYWwNCgl7bWFyZ2luOjBpbjsNCgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJ Zm9udC1zaXplOjEyLjBwdDsNCglmb250LWZhbWlseToiVGltZXMgTmV3IFJvbWFuIixzZXJpZjt9 DQphOmxpbmssIHNwYW4uTXNvSHlwZXJsaW5rDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCglj b2xvcjpibHVlOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0KYTp2aXNpdGVkLCBzcGFu Lk1zb0h5cGVybGlua0ZvbGxvd2VkDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgljb2xvcjpw dXJwbGU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQpzcGFuLkVtYWlsU3R5bGUxNw0K CXttc28tc3R5bGUtdHlwZTpwZXJzb25hbC1yZXBseTsNCglmb250LWZhbWlseToiQ2FsaWJyaSIs c2Fucy1zZXJpZjsNCgljb2xvcjojMUY0OTdEO30NCi5Nc29DaHBEZWZhdWx0DQoJe21zby1zdHls ZS10eXBlOmV4cG9ydC1vbmx5Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIixzYW5zLXNlcmlmO30N CkBwYWdlIFdvcmRTZWN0aW9uMQ0KCXtzaXplOjguNWluIDExLjBpbjsNCgltYXJnaW46MS4waW4g MS4waW4gMS4waW4gMS4waW47fQ0KZGl2LldvcmRTZWN0aW9uMQ0KCXtwYWdlOldvcmRTZWN0aW9u MTt9DQotLT48L3N0eWxlPjwhLS1baWYgZ3RlIG1zbyA5XT48eG1sPg0KPG86c2hhcGVkZWZhdWx0 cyB2OmV4dD0iZWRpdCIgc3BpZG1heD0iMTAyNiIgLz4NCjwveG1sPjwhW2VuZGlmXS0tPjwhLS1b aWYgZ3RlIG1zbyA5XT48eG1sPg0KPG86c2hhcGVsYXlvdXQgdjpleHQ9ImVkaXQiPg0KPG86aWRt YXAgdjpleHQ9ImVkaXQiIGRhdGE9IjEiIC8+DQo8L286c2hhcGVsYXlvdXQ+PC94bWw+PCFbZW5k aWZdLS0+DQo8L2hlYWQ+DQo8Ym9keSBsYW5nPSJFTi1VUyIgbGluaz0iYmx1ZSIgdmxpbms9InB1 cnBsZSI+DQo8ZGl2IGNsYXNzPSJXb3JkU2VjdGlvbjEiPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZx dW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0QiPmktIEkgaHVtYmx5IGRpc2FncmVlIHRoYXQg dXNpbmcgZGlmZmVyZW50IFFvUyBSVENQL1JUUCwgZS5nLiBkaWZmZXJlbnQgRGlmZlNlcnYgdmFs dWVzICwgc2hvdWxkIGJlIGRpc21pc3NlZC48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTom cXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RCI+aWktIExldCBtZSBh bHNvIGFkZCBhbm90aGVyIHJlYXNvbiB3aHkgbm8tcnRjcC1tdXggbWF5IGJlIG5lZWRlZDogSW1w bGVtZW50YXRpb24gZGlmZmljdWx0aWVzIGluIGNlcnRhaW4gR1dzLjxvOnA+PC9vOnA+PC9zcGFu PjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0 O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdE Ij48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3Bh biBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7 LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RCI+Q29uc2lkZXJpbmcgdGhhdCB0aGVyZSBpcyBhbHJl YWR5IGEgbmVnb3RpYXRpb24gbWVjaGFuaXNtIGZvciBydGNwLW11eCBzdXBwb3J0LCB0aGF0IGl0 IGNhbiBiZSBkZS1mYWN0byBtYW5kYXRlZCBieSB0aGUgY2hvaWNlIG9mIGJyb3dzZXJzIGZvciBJ bnRlcm5ldCwgSSB0aGluaw0KIHdoYXQgQ2hyaXN0ZXIvQWxicmVjaHQgc3VnZ2VzdGVkIGlzIHRo ZSByaWdodCB3YXkgdG8gbW92ZSBmb3J3YXJkOiBwcm92aWRlIGNsYXJpZmljYXRpb25zIGZvciB2 YWd1ZSBwb2ludHMuIEkgZG9u4oCZdCB1bmRlcnN0YW5kIHdoeSBsYWNrIG9mIGNsYXJpdHkgaW4g ZXhpc3Rpbmcgc3BlY2lmaWNhdGlvbnMgc2hvdWxkIGNhdXNlIGltcG9zaW5nIHJlc3RyaWN0aW9u cy4gVGhpcyB3b3VsZCBiZSBha2luIHRvIGRyb3BwaW5nIGEgZmVhdHVyZSBkdWUgdG8NCiBhIGJ1 Zy4gSW4gdGhpcyBjYXNlLCB0aGUg4oCcYnVn4oCdIGlzIGxhY2sgb2YgY2xhcml0eSBpbiBub3Jt YXRpdmUgc3BlY2lmaWNhdGlvbnMgYW5kIGl0IGNhbiBiZSBhZGRyZXNzZWQgYnkgZnVydGhlciBz cGVjaWZpY2F0aW9uLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkm cXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48 L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtm b250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RCI+ VGhhbmtzLDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFu IHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDss c2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEIj5Ub2xnYTxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFt aWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEIj48bzpwPiZu YnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8ZGl2IHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItbGVm dDpzb2xpZCBibHVlIDEuNXB0O3BhZGRpbmc6MGluIDBpbiAwaW4gNC4wcHQiPg0KPGRpdj4NCjxk aXYgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci10b3A6c29saWQgI0UxRTFFMSAxLjBwdDtwYWRk aW5nOjMuMHB0IDBpbiAwaW4gMGluIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxiPjxzcGFuIHN0 eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fu cy1zZXJpZiI+RnJvbTo8L3NwYW4+PC9iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2Zv bnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZiI+IFJvbWFuIFNocG91bnQg W21haWx0bzpyb21hbkB0ZWx1cml4LmNvbV0NCjxicj4NCjxiPlNlbnQ6PC9iPiBXZWRuZXNkYXks IEF1Z3VzdCAwNSwgMjAxNSAxMjoyOSBQTTxicj4NCjxiPlRvOjwvYj4gUmF1c2NoZW5iYWNoLCBV d2UgKE5va2lhIC0gREUvTXVuaWNoKSAmbHQ7dXdlLnJhdXNjaGVuYmFjaEBub2tpYS5jb20mZ3Q7 PGJyPg0KPGI+Q2M6PC9iPiBleHQgRXJpYyBSZXNjb3JsYSAmbHQ7ZWtyQHJ0Zm0uY29tJmd0Ozsg U2Nod2FyeiwgQWxicmVjaHQgKEFsYnJlY2h0KSAmbHQ7YWxicmVjaHQuc2Nod2FyekBhbGNhdGVs LWx1Y2VudC5jb20mZ3Q7OyBBc3ZlcmVuLCBUb2xnYSAmbHQ7dGFzdmVyZW5Ac29udXNuZXQuY29t Jmd0OzsgQ2hyaXN0ZXIgSG9sbWJlcmcgJmx0O2NocmlzdGVyLmhvbG1iZXJnQGVyaWNzc29uLmNv bSZndDs7IEJlcm5hcmQgQWJvYmEgJmx0O2Jlcm5hcmQuYWJvYmFAZ21haWwuY29tJmd0OzsgJmx0 O3J0Y3dlYkBpZXRmLm9yZyZndDsNCiAmbHQ7cnRjd2ViQGlldGYub3JnJmd0Ozxicj4NCjxiPlN1 YmplY3Q6PC9iPiBSZTogW3J0Y3dlYl0gV2hhdCB0aGUgZ2F0ZXdheSBkcmFmdCBzaG91bGQgc2F5 IGFib3V0IG11eC9ub24tbXV4PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8L2Rpdj4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPGRpdj4NCjxkaXY+ DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+T24gV2VkLCBBdWcgNSwgMjAxNSBhdCA0OjQ3 IEFNLCBSYXVzY2hlbmJhY2gsIFV3ZSAoTm9raWEgLSBERS9NdW5pY2gpICZsdDs8YSBocmVmPSJt YWlsdG86dXdlLnJhdXNjaGVuYmFjaEBub2tpYS5jb20iIHRhcmdldD0iX2JsYW5rIj51d2UucmF1 c2NoZW5iYWNoQG5va2lhLmNvbTwvYT4mZ3Q7IHdyb3RlOjxvOnA+PC9vOnA+PC9wPg0KPGJsb2Nr cXVvdGUgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci1sZWZ0OnNvbGlkICNDQ0NDQ0MgMS4wcHQ7 cGFkZGluZzowaW4gMGluIDBpbiA2LjBwdDttYXJnaW4tbGVmdDo0LjhwdDttYXJnaW4tcmlnaHQ6 MGluIj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJn aW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBzdHlsZT0i Zm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtBcmlhbCZxdW90OyxzYW5zLXNlcmlm Ij5NZWRpYSBnYXRld2F5IGltcGxlbWVudGF0aW9ucyBhY2NvcmRpbmcgdG8gM0dQUCBUUyAyMy4y Mjg8L3NwYW4+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7 Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0QiPg0KPC9zcGFuPjxzcGFuIHN0 eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7LHNhbnMt c2VyaWYiPm1heSBub3Qgc3VwcG9ydCBydGNwLW11eCwgYXMgcnRjcC1tdXggaXMgb3B0aW9uYWwg dGhlcmUuPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi IHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0 byI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwm cXVvdDssc2Fucy1zZXJpZiI+U28gaWYgd2UgZHJvcCBub24tbXV4IHN1cHBvcnQgZnJvbSB3ZWIg YnJvd3NlcnMsIHRob3NlIG1lZGlhIGdhdGV3YXlzIHRoYXQgaGF2ZSBub3QgaW1wbGVtZW50ZWQg cnRjcC1tdXggd2lsbCBzdG9wDQogaW50ZXJvcGVyYXRpbmcuJm5ic3A7PC9zcGFuPjxvOnA+PC9v OnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDph dXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwv ZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvYmxvY2txdW90ZT4NCjxkaXY+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPkZpcnN0IG9mIGFsbCwgZG8geW91IGtub3cgb2YgYW55IFdlYlJUQyB0byBJTVMg Z2F0ZXdheXMgdGhhdCBkbyBub3QgaW1wbGVtZW50IHJ0Y3AtbXV4IG9uIHRoZSBXZWJSVEMgc2lk ZT8gSSBzdHJvbmdseSBzdXNwZWN0IHRoZXJlIGFyZSBub25lLjxvOnA+PC9vOnA+PC9wPg0KPC9k aXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8 L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5TZWNvbmQsIHRoZSBvbmx5IHJlYXNv bnMgbm90IHRvIHVzZSBydGNwLW11eCB0aGF0IEkgY2FuIHRoaW5rIG9mIGFyZSB0aGUgZm9sbG93 aW5nOjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij4xLiBVc2luZyBkaWZmZXJlbnQgUU9TIHNldHRpbmdzIGZvciBSVENQIHZzIFJUUDxvOnA+PC9v OnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Mi4gU2VuZGluZyBS VENQIHRvIGEgZGlmZmVyZW50IGRldmljZSBmcm9tIFJUUDxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+ DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rp dj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5JIGRvIG5vdCB0aGluayB0aGUgZmlyc3Qg dXNlIGNhc2Ugd2FycmFudHMgbWFraW5nIHJ0Y3AtbXV4IG9wdGlvbmFsLCBzaW5jZSwgcHJhY3Rp Y2FsbHkgbm8gb25lIGRvZXMgdGhpcy48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPlNlY29uZCB1c2UgY2FzZSBpcyBhbHNvIGZhaXJseSBtYXJnaW5h bC4gUGx1cyBpdCBjYW4gYmUgaGFuZGxlZCBieSB0aGUgZ2F0ZXdheSB3aGljaCBjYW4gc2VuZCBS VENQIHRvIG9uZSBkZXZpY2UgYW5kIFJUUCB0byBhbm90aGVyLjxvOnA+PC9vOnA+PC9wPg0KPC9k aXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8 L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5TbywgdW5sZXNzIHNvbWVvbmUgY2Fu IGNvbWUgdXAgd2l0aCBhIHVzZSBjYXNlIHdoeSBSVFAgYW5kIFJUQ1Agc2hvdWxkIHVzZSBkaWZm ZXJlbnQgdHJhbnNwb3J0cywgSSB0aGluayBydGNwLW11eCBzaG91bGQgYmUgbWFuZGF0b3J5Ljxv OnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4m bmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5SZWdh cmRzLDxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ X19fX19fX19fX19fX188bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPlJvbWFuIFNocG91bnQ8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8 L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvYm9keT4NCjwvaHRtbD4NCg== --_000_SN1PR0301MB15516198E46F9E8E3C0F2605B2750SN1PR0301MB1551_-- From nobody Wed Aug 5 10:47:08 2015 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 37D461A8919; Wed, 5 Aug 2015 10:47:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 UCLo4TLjYZm6; Wed, 5 Aug 2015 10:47:00 -0700 (PDT) Received: from lo.psyced.org (lost.in.psyced.org [188.40.42.221]) (using TLSv1 with cipher ECDHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0483F1A88FE; Wed, 5 Aug 2015 10:46:59 -0700 (PDT) Received: from [192.168.1.202] (71-94-211-114.static.knwc.wa.charter.com [71.94.211.114]) (authenticated bits=0) by lo.psyced.org (8.14.3/8.14.3/Debian-9.4) with ESMTP id t75Hl6Nh022690 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NO); Wed, 5 Aug 2015 19:47:08 +0200 Message-ID: <55C24C09.8020404@goodadvice.pages.de> Date: Wed, 05 Aug 2015 10:46:49 -0700 From: Philipp Hancke User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.8.0 MIME-Version: 1.0 To: rtcweb@ietf.org References: <20150805130607.20844.70680.idtracker@ietfa.amsl.com> <55C24293.5000603@cs.tcd.ie> In-Reply-To: <55C24293.5000603@cs.tcd.ie> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Cc: tram@ietf.org Subject: [rtcweb] TURN permissions for private ips (was: Re: Stephen Farrell's Discuss on draft-ietf-rtcweb-stun-consent-freshness-15: (with DISCUSS and COMMENT)) X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 05 Aug 2015 17:47:05 -0000 Am 05.08.2015 um 10:06 schrieb Stephen Farrell: [...] > Part of my question > then is why exposing that additional meta-data to a server > that most users won't know exists, and that is likely > controlled by some entity the user has no clue is even > involved in their calls, is acceptable. There is an issue with TURN here, but it's not related to the consent freshness draft. If a peer sends candidates with IP addresses from the private space, permissions for those are created at the TURN server. Potentially not utilising transport encryption even. I doubt those candidates ever work, so from a privacy point of view it seems that clients should not create those permissions in the first place. And ICE should probably not try to create pairs. From nobody Wed Aug 5 11:07:18 2015 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F40D81A8ABC for ; Wed, 5 Aug 2015 11:07:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.51 X-Spam-Level: X-Spam-Status: No, score=-0.51 tagged_above=-999 required=5 tests=[BAYES_05=-0.5, 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 RDpmHA4WEzth for ; Wed, 5 Aug 2015 11:07:15 -0700 (PDT) Received: from nostrum.com (raven-v6.nostrum.com [IPv6:2001:470:d:1130::1]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B367B1A89FA for ; Wed, 5 Aug 2015 11:07:15 -0700 (PDT) Received: from Orochi.local (99-152-145-110.lightspeed.dllstx.sbcglobal.net [99.152.145.110]) (authenticated bits=0) by nostrum.com (8.15.2/8.14.9) with ESMTPSA id t75I7Au1069771 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NO); Wed, 5 Aug 2015 13:07:11 -0500 (CDT) (envelope-from adam@nostrum.com) X-Authentication-Warning: raven.nostrum.com: Host 99-152-145-110.lightspeed.dllstx.sbcglobal.net [99.152.145.110] claimed to be Orochi.local Message-ID: <55C250CE.3040309@nostrum.com> Date: Wed, 05 Aug 2015 13:07:10 -0500 From: Adam Roach User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:31.0) Gecko/20100101 Thunderbird/31.7.0 MIME-Version: 1.0 To: carlo von lynX , rtcweb@ietf.org References: <20150805161344.GA19492@lo.psyced.org> <20150805164256.GB19492@lo.psyced.org> In-Reply-To: <20150805164256.GB19492@lo.psyced.org> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [rtcweb] LAST CALL: Systematically de-anonymize dissidents with WebRTC (HOWTO) X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 05 Aug 2015 18:07:17 -0000 On 8/5/15 11:42, carlo von lynX wrote: > On Wed, Aug 05, 2015 at 12:37:11PM -0400, Benjamin Schwartz wrote: >> Tor does not claim to protect against hostile websites unless you are using >> the Tor Browser Bundle, which is not subject to this issue (it already >> disables WebRTC). > Disclaimers are irrelevant here. Bad advice is bad advice. If someone went around spreading the notion that one can protect one's identity with Tor or with a VPN running on the same machine as the browser, then that's no better than someone asserting that one can protect one's identity by disabling IPv6, running an ad blocker, using "private browsing mode," or wearing a hat coated with aluminum foil. This was true before WebRTC, and it would remain true if we removed every trace of WebRTC from the planet. If you're really interested helping the parties you're expressing concern for, and you have the energy to "go noisy" on a topic, your efforts would be best spent evangelizing TorBrowser or some other solution that provides some semblance of useful anonymity. I have sympathy for the problem you're highlighting, but your histrionics are undermining your point. We're trying to figure out a way to throw out the bathwater while keeping the baby. Your suggestion that we instead nuke the bathtub makes you sound like a kook. /a From nobody Wed Aug 5 11:33:06 2015 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 287D01B3441 for ; Wed, 5 Aug 2015 11:33:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.601 X-Spam-Level: X-Spam-Status: No, score=-2.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id eqcJe6gU3qLD for ; Wed, 5 Aug 2015 11:33:03 -0700 (PDT) Received: from mail-oi0-f46.google.com (mail-oi0-f46.google.com [209.85.218.46]) (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 54E721B3442 for ; Wed, 5 Aug 2015 11:32:44 -0700 (PDT) Received: by oio137 with SMTP id 137so23776456oio.0 for ; Wed, 05 Aug 2015 11:32:43 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:message-id:date:from:user-agent:mime-version:to :cc:subject:references:in-reply-to:content-type :content-transfer-encoding; bh=FGLOFRbYUJFVEPMzJkGE1j04ATEC0umTkvsqKe+mBpk=; b=PMvSezXevWvuQDrKLzHQWs8z8uc9uKCjcIHTZvDLsFHFWSSXWiD2ywXonrM1zKa4uh z8z2zpCHtYKAqkv2WqetuTZ4U8VqEgMhWksmfQSTAa2qcSs4pWW2wRE4PjTQvTLouYke wZQv1CtBrGObKIK3rm9XNvcLkmG5RbCyjl6WZosN7X09wLzRjWkCl5K/Jf/x3i/lZbGw uHDzJJ1kjqxImHQUpO+w71lSYDwO2dQB59V/eI4mp/5lM28H6SEcNil37n7gPV594t9G HotYPVuXAIcUEhzYkWntErPay97Eft9SAH0Qej9RJKdl06fK8oI2nhU3CjDmdoeBLLPD BJ7A== X-Gm-Message-State: ALoCoQkmd5c2ufeJPuRGa5HDusLQNCXppMGUhneaJbudz3pdRs85Hfd7/xnm298mx5+/hjj79Ffv X-Received: by 10.202.71.6 with SMTP id u6mr9008045oia.36.1438799563755; Wed, 05 Aug 2015 11:32:43 -0700 (PDT) Received: from Simons-MacBook-Air.local ([24.53.47.130]) by smtp.googlemail.com with ESMTPSA id l5sm2158006oey.5.2015.08.05.11.32.42 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 05 Aug 2015 11:32:43 -0700 (PDT) Message-ID: <55C256C8.80606@jive.com> Date: Wed, 05 Aug 2015 14:32:40 -0400 From: Simon Perreault User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:31.0) Gecko/20100101 Thunderbird/31.7.0 MIME-Version: 1.0 To: Philipp Hancke , rtcweb@ietf.org References: <20150805130607.20844.70680.idtracker@ietfa.amsl.com> <55C24293.5000603@cs.tcd.ie> <55C24C09.8020404@goodadvice.pages.de> In-Reply-To: <55C24C09.8020404@goodadvice.pages.de> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 8bit Archived-At: Cc: tram@ietf.org Subject: Re: [rtcweb] [tram] TURN permissions for private ips X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 05 Aug 2015 18:33:04 -0000 Le 2015-08-05 13:46, Philipp Hancke a crit : > If a peer sends candidates with IP addresses from the private space, > permissions for those are created at the TURN server. Potentially not > utilising transport encryption even. > > I doubt those candidates ever work, so from a privacy point of view it > seems that clients should not create those permissions in the first > place. And ICE should probably not try to create pairs. It's not up to the client to determine what addresses might not might not work for a given TURN server. There are lots of weird NAT configurations out there that play games with RFC1918 addresses and can easily trick clients into doing the wrong thing. Instead, the server should be the one doing that check because it only has access to reliable information. It should use the existing mechanism and return 403 Forbidden for addresses it doesn't like. See RFC 5766 section "9.2. Receiving a CreatePermission Request": The server MAY impose restrictions on the IP address allowed in the XOR-PEER-ADDRESS attribute -- if a value is not allowed, the server rejects the request with a 403 (Forbidden) error. Simon From nobody Wed Aug 5 12:48:08 2015 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A215D1A1B4C for ; Wed, 5 Aug 2015 12:48:06 -0700 (PDT) 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, RCVD_IN_DNSWL_LOW=-0.7] 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 trDXn7NPHA0n for ; Wed, 5 Aug 2015 12:48:04 -0700 (PDT) Received: from out5-smtp.messagingengine.com (out5-smtp.messagingengine.com [66.111.4.29]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 800B71A8737 for ; Wed, 5 Aug 2015 12:48:00 -0700 (PDT) Received: from compute3.internal (compute3.nyi.internal [10.202.2.43]) by mailout.nyi.internal (Postfix) with ESMTP id DEE7920439 for ; Wed, 5 Aug 2015 15:47:59 -0400 (EDT) Received: from frontend2 ([10.202.2.161]) by compute3.internal (MEProxy); Wed, 05 Aug 2015 15:47:59 -0400 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=AQCXq aP3N643lDsCrUluWao33DQ=; b=NE8eBhTM58l70HROtmEbHiDDFkVWvqHRpb5zz h3aMq8qaf9Sk4TewleqV8DhK8AbLivpEe5CvbFg2ctYejD2SQR0MNaaqL6URm4vS CS+pKjdnhbU2CIDAPJHHJgoNk71Omn9xphYYO5uuUz5ut1skoqdJnzAZQnh6TZae DmHazc= 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=AQCXqaP3N643lDsCrUluWao33DQ=; b=ZSniT gEXu/slylYhMa2dyjDdKZ0446+mCRVgTvtL3NIjLmlFNgtaxNdp1BfYUokQSRyFs 7Do/U/3VVbvCSA7a3rJNyx8/5PMfS7oInfGAWxMNF+4WSicF6aMVT6eeOqtwkyh1 FBGPksPLjPQkxx/vZE+wmO1BJ7NaQ+Vh8XSKZ8= X-Sasl-enc: y93aNCaAUObxnFoXBJjHBvQRehpcCP+wo5HXJ1p0d5pO 1438804079 Received: from dhcp-171-68-21-199.cisco.com (dhcp-171-68-21-199.cisco.com [171.68.21.199]) by mail.messagingengine.com (Postfix) with ESMTPA id 0695B6801C4; Wed, 5 Aug 2015 15:47:57 -0400 (EDT) Content-Type: multipart/alternative; boundary="Apple-Mail=_B305F156-EA90-430A-8ADA-37379D585D17" Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) From: Alissa Cooper In-Reply-To: <20150805130607.20844.70680.idtracker@ietfa.amsl.com> Date: Wed, 5 Aug 2015 12:47:59 -0700 Message-Id: References: <20150805130607.20844.70680.idtracker@ietfa.amsl.com> To: Stephen Farrell X-Mailer: Apple Mail (2.1878.6) Archived-At: Cc: draft-ietf-rtcweb-stun-consent-freshness@ietf.org, rtcweb-chairs@ietf.org, draft-ietf-rtcweb-stun-consent-freshness.shepherd@ietf.org, rtcweb@ietf.org, IESG , draft-ietf-rtcweb-stun-consent-freshness.ad@ietf.org Subject: Re: [rtcweb] Stephen Farrell's Discuss on draft-ietf-rtcweb-stun-consent-freshness-15: (with DISCUSS and COMMENT) X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 05 Aug 2015 19:48:06 -0000 --Apple-Mail=_B305F156-EA90-430A-8ADA-37379D585D17 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 Thanks Stephen, responding to a couple points below where others have = not chimed in yet. On Aug 5, 2015, at 6:06 AM, Stephen Farrell = wrote: > Stephen Farrell has entered the following ballot position for > draft-ietf-rtcweb-stun-consent-freshness-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-rtcweb-stun-consent-freshness/= >=20 >=20 >=20 > ---------------------------------------------------------------------- > DISCUSS: > ---------------------------------------------------------------------- >=20 >=20 >=20 > Apologies that these discuss points are maybe asking > fairly fundamental questions. That could be that this > is really the first of the new security things required > by rtcweb to get to the IESG. Or maybe I'm misreading > stuff here, if so, sorry;-) >=20 > (1) Why call this "consent?" That term is (ab)used in > many ways on the web, and adding another variation > without a definition that distinguishes this from "click > ok to my 200 page anti-privacy policy" or "remember that > example.com is allowed use my camera/mic" seems like a > terrible idea. I also don't see how this can ever be > something to which a normal person can "consent" (i.e. > consciously agree while fully understanding) so the term > is IMO very misleading, and will I fear be used to > mislead further. (See also some of the comments below - > I do not think we ought be as fast and loose with this > aleady terribly badly used term.) To summarise: I'd love > if you did s/consent/anything-else/g but if not, please > define consent here in a way that clearly and > unambiguously distinguishes this usage from other abuses > of the term. >=20 > (2) WebRTC does not require STUN or TURN servers for > some calls, even if it does for many. Why is it ok to > require such a server be present in all calls (which I > think this means) espcially when that means exposing > additional meta-data (calling parties in a case where > the servers weren't needed and call duration in all > cases) to those servers when that is not always > necessary?=20 >=20 > (3) (end of p5) You have a MUST NOT here that is > depenedent on current browser implementations. Why is > that an IETF thing and not a W3C thing? But more > interestingly, can one securely use this protocol > without the kind of JS vs. browser sandboxing etc that's > needed in the web? If the answer is "no" then don't you > need to say that this protocol can only safely be used > for such implementations? (In section 2, which almost > but not quite says that.) >=20 > (4) Section 8: Where are these 96 bits defined? I think > this "requires..." statement needs a precise reference > to the place in some ICE/TURN/STUN RFC where it's > defined. (And I forget where that is, sorry:-) This > should be an easy fix. https://tools.ietf.org/html/rfc5389#section-6 (as referenced in Section = 5.1) >=20 > (5) Why is it ok to approve this while the > rtcweb-security-arch and rtcweb-security are still > developing? There are section-specific references here > along the lines of: "doing this is ok because of section > x.x" of both of those drafts. Why is it ok to approve > this now, when the underlying architecture and overall > security model on which this depends are still in-flux? > I'm not asking about editorial changes here nor about > timing, but about why it's ok to approve this when the > basic security concepts have yet to undergo IETF last > call, and so could change significantly. I think it=92s worth looking at what the cross-references actually point = to. Section 2 says: "Section 4.4 and Section 5.3 of [I-D.ietf-rtcweb-security-arch] further explains the value of obtaining and maintaining consent.=94 Section 4.4 of draft-ietf-rtcweb-security-arch essentially says that = implementations MUST use the mechanism specified in = draft-ietf-stun-consent-freshness. Section 5.3 of = draft-ietf-rtcweb-security-arch establishes the normative requirement = that ICE be used and how it be used and explains the need for consent = freshness. Section 8 says: "Consent Verification to avoid attacks using a browser as an attack platform against machines is discussed in Sections 3.3 and 4.2 of [I-D.ietf-rtcweb-security].=94 Both of these references are about the need to obtain consent in the = first place, and as such I think they are provided more to give the = broader picture of where stun-consent-freshness fits into the RTCWEB = security story. Section 3.3 explains the threat model that motivates the = need to obtain communications consent. Section 4.2 explains how this = threat is mitigated, namely by using ICE.=20 The upshot of this is if the WG or the IETF decides before publishing = the security documents that communications consent isn=92t actually = necessary (seems highly unlikely to me), then maintaining consent = freshness won=92t make much sense, but having published this draft = wouldn=92t be particularly harmful either since it will basically be = meaningless. Likewise, I guess in theory consensus could emerge not to = use ICE. But in either of those cases, we could obsolete = draft-ietf-stun-consent-freshness if it had already been published. = Furthermore, if consensus does emerge not to use ICE, there will = probably be bigger problems with the RTCWEB document suite than the fact = that draft-ietf-stun-consent-freshness was published. If your concern is that the specific section numbers in the security = documents might change, I think those could be taken out without issue. Alissa > I do not think > it would be acceptable for a comment/discuss on the > security documents to be received with "yes, but you > approved consent-freshness and so we implemented and > deployed that so you're too late to make that > comment/discuss and expect some change." >=20 >=20 > ---------------------------------------------------------------------- > COMMENT: > ---------------------------------------------------------------------- >=20 >=20 > - abstract: why is only sending "media" mentioned here? > What about data channels? And the body of the document > in fact says this all applies to any non-ICE data and > not only media. >=20 > - intro: "initial consent to send by performing STUN" I > do not find the word consent in either rfc5245 or 3489, > but perhaps it is used somewhere else. Where? And with > what meaning? >=20 > - section 4, 2nd last para - I think the conclusion is > bogus. An implementation knows when the keying it's > using can not involve >1 (nominally operating) party. >=20 > - 5.1, 3rd para: "Explicit consent to send is > obtained..." is misleading. That is not a concept that > an implementation of STUN will embody.=20 >=20 > - 5.1, What is the "Note" about TCP for? Why is this > needed? >=20 >=20 --Apple-Mail=_B305F156-EA90-430A-8ADA-37379D585D17 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=windows-1252
Thanks Stephen, responding to a couple points = below where others have not chimed in yet.


Stephen Farrell has entered the following ballot position = for
draft-ietf-rtcweb-stun-consent-freshness-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-rtcweb-stun-consent-= freshness/



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



Apologies that = these discuss points are maybe asking
fairly fundamental questions. =  That could be that this
is really the first of the new security = things required
by rtcweb to get to the IESG.  Or maybe I'm = misreading
stuff here, if so, sorry;-)

(1) Why call this = "consent?" That term is (ab)used in
many ways on the web, and adding = another variation
without a definition that distinguishes this from = "click
ok to my 200 page anti-privacy policy" or "remember = that
example.com is allowed use my camera/mic" seems like = a
terrible idea. I also don't see how this can ever be
something = to which a normal person can "consent" (i.e.
consciously agree while = fully understanding) so the term
is IMO very misleading, and will I = fear be used to
mislead further.  (See also some of the comments = below -
I do not think we ought be as fast and loose with = this
aleady terribly badly used term.) To summarise: I'd love
if = you did s/consent/anything-else/g but if not, please
define consent = here in a way that clearly and
unambiguously distinguishes this usage = from other abuses
of the term.

(2) WebRTC does not require = STUN or TURN servers for
some calls, even if it does for many. Why is = it ok to
require such a server be present in all calls (which = I
think this means) espcially when that means exposing
additional = meta-data (calling parties in a case where
the servers weren't needed = and call duration in all
cases) to those servers when that is not = always
necessary?

(3) (end of p5) You have a MUST NOT here = that is
depenedent on current browser implementations. Why is
that = an IETF thing and not a W3C thing? But more
interestingly, can one = securely use this protocol
without the kind of JS vs. browser = sandboxing etc that's
needed in the web? If the answer is "no" then = don't you
need to say that this protocol can only safely be = used
for such implementations? (In section 2, which almost
but not = quite says that.)

(4) Section 8: Where are these 96 bits defined? = I think
this "requires..." statement needs a precise reference
to = the place in some ICE/TURN/STUN RFC where it's
defined. (And I forget = where that is, sorry:-) This
should be an easy = fix.

https://tools.ietf.= org/html/rfc5389#section-6 (as referenced in Section = 5.1)


(5) Why is it ok to approve = this while the
rtcweb-security-arch and rtcweb-security are = still
developing? There are section-specific references here
along = the lines of: "doing this is ok because of section
x.x" of both of = those drafts. Why is it ok to approve
this now, when the underlying = architecture and overall
security model on which this depends are = still in-flux?
I'm not asking about editorial changes here nor = about
timing, but about why it's ok to approve this when the
basic = security concepts have yet to undergo IETF last
call, and so could = change significantly.

I think it=92s = worth looking at what the cross-references actually point = to.

Section 2 = says:

"Section 4.4 and Section 5.3 = of
   [I-D.ietf-rtcweb-security-arch] further = explains the value of
   obtaining and maintaining = consent.=94

Section 4.4 of = draft-ietf-rtcweb-security-arch essentially says that implementations = MUST use the mechanism specified in draft-ietf-stun-consent-freshness. = Section 5.3 of draft-ietf-rtcweb-security-arch establishes the normative = requirement that ICE be used and how it be used and explains the need = for consent freshness.

Section 8 = says:

"Consent Verification to avoid attacks = using a browser as
   an attack platform against = machines is discussed in Sections 3.3 and
   4.2 of = [I-D.ietf-rtcweb-security].=94

Both of these = references are about the need to obtain consent in the first place, and = as such I think they are provided more to give the broader picture of = where stun-consent-freshness fits into the RTCWEB security story. = Section 3.3 explains the threat model that motivates the need to obtain = communications consent. Section 4.2 explains how this threat is = mitigated, namely by using ICE. 

The = upshot of this is if the WG or the IETF decides before publishing the = security documents that communications consent isn=92t actually = necessary (seems highly unlikely to me), then maintaining consent = freshness won=92t make much sense, but having published this draft = wouldn=92t be particularly harmful either since it will basically be = meaningless. Likewise, I guess in theory consensus could emerge not to = use ICE. But in either of those cases, we could obsolete = draft-ietf-stun-consent-freshness if it had already been published. = Furthermore, if consensus does emerge not to use ICE, there will = probably be bigger problems with the RTCWEB document suite than the fact = that draft-ietf-stun-consent-freshness was = published.

If your concern is that the specific = section numbers in the security documents might change, I think those = could be taken out without = issue.

Alissa


I do not think
it would be acceptable for a = comment/discuss on the
security documents to be received with "yes, = but you
approved consent-freshness and so we implemented = and
deployed that so you're too late to make that
comment/discuss = and expect some = change."


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


- abstract: why is only sending = "media" mentioned here?
What about data channels?  And the body = of the document
in fact says this all applies to any non-ICE data = and
not only media.

- intro: "initial consent to send by = performing STUN" I
do not find the word consent in either rfc5245 or = 3489,
but perhaps it is used somewhere else. Where?  And = with
what meaning?

- section 4, 2nd last para - I think the = conclusion is
bogus.  An implementation knows when the keying = it's
using can not involve >1 (nominally operating) = party.

- 5.1, 3rd para: "Explicit consent to send = is
obtained..." is misleading. That is not a concept that
an = implementation of STUN will embody.

- 5.1, What is the "Note" = about TCP for? Why is = this
needed?



= --Apple-Mail=_B305F156-EA90-430A-8ADA-37379D585D17-- From nobody Wed Aug 5 14:36:16 2015 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 728EF1AC3C4 for ; Wed, 5 Aug 2015 14:36:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.388 X-Spam-Level: X-Spam-Status: No, score=-1.388 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id f8NP_6p4y-PQ for ; Wed, 5 Aug 2015 14:36:13 -0700 (PDT) Received: from mail-vk0-x232.google.com (mail-vk0-x232.google.com [IPv6:2607:f8b0:400c:c05::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 4431F1AC3B9 for ; Wed, 5 Aug 2015 14:36:13 -0700 (PDT) Received: by vkgc186 with SMTP id c186so20612290vkg.0 for ; Wed, 05 Aug 2015 14:36:12 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=b5tC5lHKMcItaxMryofU/y98YlarzuGyw1wx4eR3Ppk=; b=IG0xlO1C1gygvT7H9baDQF9f3SrutAkmEQI9vcmnLjo11woQhHu+AcJoH14DUCnaMM eYJdaxWGlQHUkZRlFerGBUDezSNnUz2pQo6y340dS5zT9mQFTLOziQvYsq11E+H3DJGU 4YTcqklFTMaNVy9O0MAi/kscPdLB8ZUglXd/8j8GcoY94h5mb0yj0ac/89jwm9b89RoC eq3u2SVJ4/EF2mjytTR5A9S1D883tX4W/IsB4rfDLWRzqXhwvX9OlfvV38HfdiCdVMLk lIANbCcY0xtKVEoxDxszcj6eCV3haPs+NrM21d5BFdpd+zHuwhBNmfQrzMc77Zxqptuh A5kg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type; bh=b5tC5lHKMcItaxMryofU/y98YlarzuGyw1wx4eR3Ppk=; b=hPPXIAPIbbhgHIW+fxpmnY3LdJ7BKlV5CbZS1haM0o6E+0NAExJAPuDUuLwp0ditn2 Ah+xWqOclm8TaO2MWkPQm8YMDHXHlrWUrorhzfkRqfjePIDsqc7JROKIoHoWFctuRlmI fSTnZwchijnjM6MO2wK9jTN7ACngJrtCat1odtc628fI4p/NHr0Cz/DZey5w85YctJS8 bwHC7kuM3AyPpLZdcn01UPTu2DSwX1IS4s0jIO8zNc3tk8LQbKnu8LAVEIgM5aIZRwVX 4HeFXl4r1KN2UqE612xuNGtLjx/Xma1oGLIy2Y2tygpwjxD9F2B0zLbVXZZCLKokp5WQ zbmA== X-Gm-Message-State: ALoCoQm8Cm5/Zr46UVjUVwkQDLHf0NzjqMykARMj73ByXQ+59JbRUWqykGh8fOW5HGOvFbWT/sMD X-Received: by 10.52.163.50 with SMTP id yf18mr15407103vdb.93.1438810572398; Wed, 05 Aug 2015 14:36:12 -0700 (PDT) MIME-Version: 1.0 Received: by 10.31.191.87 with HTTP; Wed, 5 Aug 2015 14:35:52 -0700 (PDT) In-Reply-To: <55C256C8.80606@jive.com> References: <20150805130607.20844.70680.idtracker@ietfa.amsl.com> <55C24293.5000603@cs.tcd.ie> <55C24C09.8020404@goodadvice.pages.de> <55C256C8.80606@jive.com> From: Justin Uberti Date: Wed, 5 Aug 2015 14:35:52 -0700 Message-ID: To: Simon Perreault Content-Type: multipart/alternative; boundary=001a11c2ce381161c7051c97316c Archived-At: Cc: "rtcweb@ietf.org" , "tram@ietf.org" Subject: Re: [rtcweb] [tram] TURN permissions for private ips X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 05 Aug 2015 21:36:14 -0000 --001a11c2ce381161c7051c97316c Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On Wed, Aug 5, 2015 at 11:32 AM, Simon Perreault wrote: > Le 2015-08-05 13:46, Philipp Hancke a =C3=A9crit : > > If a peer sends candidates with IP addresses from the private space, > > permissions for those are created at the TURN server. Potentially not > > utilising transport encryption even. > > > > I doubt those candidates ever work, so from a privacy point of view it > > seems that clients should not create those permissions in the first > > place. And ICE should probably not try to create pairs. > > It's not up to the client to determine what addresses might not might > not work for a given TURN server. There are lots of weird NAT > configurations out there that play games with RFC1918 addresses and can > easily trick clients into doing the wrong thing. > I am somewhat sympathetic to that, but given that there is measurable downside here - extra candidate pairs that take time to check - can you supply a concrete example of where the client choosing not to pair a TURN candidate with a RFC1918 address would cause a problem? --001a11c2ce381161c7051c97316c Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


On Wed, Aug 5, 2015 at 11:32 AM, Simon Perreault <= sperreault@jive.co= m> wrote:
Le 2015-08-05 13:= 46, Philipp Hancke a =C3=A9crit :
> If a peer sends candidates with IP addresses from the private space, > permissions for those are created at the TURN server. Potentially not<= br> > utilising transport encryption even.
>
> I doubt those candidates ever work, so from a privacy point of view it=
> seems that clients should not create those permissions in the first > place. And ICE should probably not try to create pairs.

It's not up to the client to determine what addresses might not might not work for a given TURN server. There are lots of weird NAT
configurations out there that play games with RFC1918 addresses and can
easily trick clients into doing the wrong thing.

<= /div>
I am somewhat sympathetic to that, but given that there is measur= able downside here - extra candidate pairs that take time to check - can yo= u supply a concrete example of where the client choosing not to pair a TURN= candidate with a RFC1918 address would cause a problem?
<= /div> --001a11c2ce381161c7051c97316c-- From nobody Wed Aug 5 15:01:15 2015 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 802DB1ACD53 for ; Wed, 5 Aug 2015 15:01:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.601 X-Spam-Level: X-Spam-Status: No, score=-2.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=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 lhRnlTFK3yOo for ; Wed, 5 Aug 2015 15:01:11 -0700 (PDT) Received: from mail-qg0-f43.google.com (mail-qg0-f43.google.com [209.85.192.43]) (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 451411ACD4B for ; Wed, 5 Aug 2015 15:01:11 -0700 (PDT) Received: by qgj62 with SMTP id 62so15459406qgj.2 for ; Wed, 05 Aug 2015 15:01:10 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:message-id:date:from:user-agent:mime-version:to :cc:subject:references:in-reply-to:content-type :content-transfer-encoding; bh=m6ICfA/Dg3+j0wFcJY1BXxun9op/L4HqpmawJFHKsa4=; b=VJVY6xsdE9US2CvZiSdzPc1xnGVIgpwQD1FSxyRBOIpi3bLrm8TFvUE22fTrmid9+7 O09Wf808QLseHRxDuqpAe494ZfhTlC/BkqpoSENNg+BlybK+zJRn32ArOTWMlcbXD/sB n2rMml7NAYn3tvt9EJZcSwT4i4YFq/+oakI9/cSgRdDLclC0XnlPOEji6YjgNgCTvF5H zpguvbBmziWFLVobWDgNBoiMaWjOy0SV3KDgHCpxwBjUh5gJZ4yKbeFaFFPCvFUKb0Gq 7MZsAh/VCxQCU1oFyN55bIjS4oKfkeDGnhoZ+dVbl7MZXJuE3G6m51EQKEv+7om/hqRH I3JQ== X-Gm-Message-State: ALoCoQk4eKKcHeerBmhkXh4zXp6oRiudARepPL53EHrBLOLA0wMMDb2sDJChQ2hprH2a/V37HIuv X-Received: by 10.140.145.16 with SMTP id 16mr9823082qhr.34.1438812070515; Wed, 05 Aug 2015 15:01:10 -0700 (PDT) Received: from Simons-MacBook-Air.local ([2607:fa48:6eca:f820:8866:e37:fd1c:e865]) by smtp.googlemail.com with ESMTPSA id 71sm2094225qhg.37.2015.08.05.15.01.09 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 05 Aug 2015 15:01:09 -0700 (PDT) Message-ID: <55C287A4.8050600@jive.com> Date: Wed, 05 Aug 2015 18:01:08 -0400 From: Simon Perreault User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:31.0) Gecko/20100101 Thunderbird/31.7.0 MIME-Version: 1.0 To: Justin Uberti References: <20150805130607.20844.70680.idtracker@ietfa.amsl.com> <55C24293.5000603@cs.tcd.ie> <55C24C09.8020404@goodadvice.pages.de> <55C256C8.80606@jive.com> In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit Archived-At: Cc: "rtcweb@ietf.org" , "tram@ietf.org" Subject: Re: [rtcweb] [tram] TURN permissions for private ips X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 05 Aug 2015 22:01:12 -0000 Le 2015-08-05 17:35, Justin Uberti a écrit : > I am somewhat sympathetic to that, but given that there is measurable > downside here - extra candidate pairs that take time to check - can you > supply a concrete example of where the client choosing not to pair a > TURN candidate with a RFC1918 address would cause a problem? I can't! Philipp's proposal certainly does make practical sense when you consider it as an ugly optimization hack rather than something that is necessary to make things work. Phrase it so that this is clear and I'll be all for it. :) Simon From nobody Wed Aug 5 15:09:42 2015 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 815811ACDDE for ; Wed, 5 Aug 2015 15:09:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.977 X-Spam-Level: X-Spam-Status: No, score=-1.977 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7] autolearn=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 F7h4p_Xgqz-l for ; Wed, 5 Aug 2015 15:09:36 -0700 (PDT) Received: from mail-wi0-f170.google.com (mail-wi0-f170.google.com [209.85.212.170]) (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 C907E1ACD90 for ; Wed, 5 Aug 2015 15:08:56 -0700 (PDT) Received: by wibhh20 with SMTP id hh20so43205870wib.0 for ; Wed, 05 Aug 2015 15:08:55 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type; bh=scMeaxAYK6QixKG8huP9LX2WydgfT7c3sPy+ZkhGjIo=; b=Hsatma2WvbElmTBW4ENQYIZzb6gwOv4+g525AB9raoJQR+TJDNxEx38alSboKPvgux 7csr5NFv7elMjbAZJwqDZvdXz26DUQhiIq0wm3HGwx7oiMLOTgeYKZ7ex+xgdjhD/6qm oYuyBGyOVVBLOVkIEWl1BSEpKk0H4O81a3TyyXGk8nhYiDkh9t2z5qr8ror2aJRMlYeH t+txAqB7hp5Gm8BG1kICzIqAIlcyG1R24ELE8Hq9rqOmAhytUuI6C5TRlQ7u2GVaxgeT Yvo16A30o8eRQRNGrADrS821NKSQXvk4Fayl4jSKpJeoxxwB88ZDK1+lj+tVUPEY0Tlt uIsw== X-Gm-Message-State: ALoCoQlc7oOR+7PFwTFmYm8FzKuu6hyDyxt2u4dpt8U1bMJ9otcVy+kKDusTTIQX6OOmxNmupgDY X-Received: by 10.180.91.79 with SMTP id cc15mr297128wib.53.1438812535541; Wed, 05 Aug 2015 15:08:55 -0700 (PDT) MIME-Version: 1.0 Received: by 10.27.85.86 with HTTP; Wed, 5 Aug 2015 15:08:16 -0700 (PDT) In-Reply-To: <55C287A4.8050600@jive.com> References: <20150805130607.20844.70680.idtracker@ietfa.amsl.com> <55C24293.5000603@cs.tcd.ie> <55C24C09.8020404@goodadvice.pages.de> <55C256C8.80606@jive.com> <55C287A4.8050600@jive.com> From: Eric Rescorla Date: Wed, 5 Aug 2015 15:08:16 -0700 Message-ID: To: Simon Perreault Content-Type: multipart/alternative; boundary=f46d043be246146720051c97a664 Archived-At: Cc: "rtcweb@ietf.org" , "tram@ietf.org" Subject: Re: [rtcweb] [tram] TURN permissions for private ips X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 05 Aug 2015 22:09:38 -0000 --f46d043be246146720051c97a664 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable I think I too am in favor of this change. On Wed, Aug 5, 2015 at 3:01 PM, Simon Perreault wrote= : > Le 2015-08-05 17:35, Justin Uberti a =C3=A9crit : > > I am somewhat sympathetic to that, but given that there is measurable > > downside here - extra candidate pairs that take time to check - can you > > supply a concrete example of where the client choosing not to pair a > > TURN candidate with a RFC1918 address would cause a problem? > > I can't! > > Philipp's proposal certainly does make practical sense when you consider > it as an ugly optimization hack rather than something that is necessary > to make things work. Phrase it so that this is clear and I'll be all for > it. :) > > Simon > > _______________________________________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/listinfo/rtcweb > --f46d043be246146720051c97a664 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
I think I too am in favor of this change.

On Wed, Aug 5, 2015 at 3:01= PM, Simon Perreault <sperreault@jive.com> wrote:
Le 2015-08-05 17:35, Justin Uber= ti a =C3=A9crit :
> I am somewhat sympathetic to that, but given that there is measurable<= br> > downside here - extra candidate pairs that take time to check - can yo= u
> supply a concrete example of where the client choosing not to pair a > TURN candidate with a RFC1918 address would cause a problem?

I can't!

Philipp's proposal certainly does make practical sense when you conside= r
it as an ugly optimization hack rather than something that is necessary
to make things work. Phrase it so that this is clear and I'll be all fo= r
it. :)

Simon

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

--f46d043be246146720051c97a664-- From nobody Wed Aug 5 15:20:07 2015 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3EE941ACDDF; Wed, 5 Aug 2015 15:20:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 YDSOyEcXksq1; Wed, 5 Aug 2015 15:20:03 -0700 (PDT) Received: from lo.psyced.org (lost.in.psyced.org [188.40.42.221]) (using TLSv1 with cipher ECDHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 265501ACDDE; Wed, 5 Aug 2015 15:20:02 -0700 (PDT) Received: from [192.168.1.202] (71-94-211-114.static.knwc.wa.charter.com [71.94.211.114]) (authenticated bits=0) by lo.psyced.org (8.14.3/8.14.3/Debian-9.4) with ESMTP id t75MKAHQ028790 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NO); Thu, 6 Aug 2015 00:20:13 +0200 Message-ID: <55C28C05.1000901@goodadvice.pages.de> Date: Wed, 05 Aug 2015 15:19:49 -0700 From: Philipp Hancke User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.8.0 MIME-Version: 1.0 To: Simon Perreault , Justin Uberti References: <20150805130607.20844.70680.idtracker@ietfa.amsl.com> <55C24293.5000603@cs.tcd.ie> <55C24C09.8020404@goodadvice.pages.de> <55C256C8.80606@jive.com> <55C287A4.8050600@jive.com> In-Reply-To: <55C287A4.8050600@jive.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Archived-At: Cc: "rtcweb@ietf.org" , "tram@ietf.org" Subject: Re: [rtcweb] [tram] TURN permissions for private ips X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 05 Aug 2015 22:20:05 -0000 Am 05.08.2015 um 15:01 schrieb Simon Perreault: > Le 2015-08-05 17:35, Justin Uberti a écrit : >> I am somewhat sympathetic to that, but given that there is measurable >> downside here - extra candidate pairs that take time to check - can you >> supply a concrete example of where the client choosing not to pair a >> TURN candidate with a RFC1918 address would cause a problem? > > I can't! > > Philipp's proposal certainly does make practical sense when you consider > it as an ugly optimization hack rather than something that is necessary > to make things work. Phrase it so that this is clear and I'll be all for > it. :) incidentally, that's how I came up with it a while back: https://code.google.com/p/webrtc/issues/detail?id=4634 :-) From nobody Wed Aug 5 15:38:41 2015 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A75FA1ACE39; Wed, 5 Aug 2015 15:38:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MTIezEvVPWb9; Wed, 5 Aug 2015 15:38:37 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 03D291A8BB4; Wed, 5 Aug 2015 15:38:37 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "Stephen Farrell" To: "The IESG" X-Test-IDTracker: no X-IETF-IDTracker: 6.3.0.p1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20150805223837.26225.49192.idtracker@ietfa.amsl.com> Date: Wed, 05 Aug 2015 15:38:37 -0700 Archived-At: Cc: draft-ietf-rtcweb-stun-consent-freshness.ad@ietf.org, rtcweb@ietf.org, draft-ietf-rtcweb-stun-consent-freshness@ietf.org, rtcweb-chairs@ietf.org, draft-ietf-rtcweb-stun-consent-freshness.shepherd@ietf.org Subject: [rtcweb] Stephen Farrell's Discuss on draft-ietf-rtcweb-stun-consent-freshness-15: (with DISCUSS and COMMENT) X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 05 Aug 2015 22:38:38 -0000 Stephen Farrell has entered the following ballot position for draft-ietf-rtcweb-stun-consent-freshness-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-rtcweb-stun-consent-freshness/ ---------------------------------------------------------------------- DISCUSS: ---------------------------------------------------------------------- Apologies that these discuss points are maybe asking fairly fundamental questions. That could be that this is really the first of the new security things required by rtcweb to get to the IESG. Or maybe I'm misreading stuff here, if so, sorry;-) (1) Why call this "consent?" That term is (ab)used in many ways on the web, and adding another variation without a definition that distinguishes this from "click ok to my 200 page anti-privacy policy" or "remember that example.com is allowed use my camera/mic" seems like a terrible idea. I also don't see how this can ever be something to which a normal person can "consent" (i.e. consciously agree while fully understanding) so the term is IMO very misleading, and will I fear be used to mislead further. (See also some of the comments below - I do not think we ought be as fast and loose with this aleady terribly badly used term.) To summarise: I'd love if you did s/consent/anything-else/g but if not, please define consent here in a way that clearly and unambiguously distinguishes this usage from other abuses of the term. (2) WebRTC does not require STUN or TURN servers for some calls, even if it does for many. Why is it ok to require such a server be present in all calls (which I think this means) espcially when that means exposing additional meta-data (calling parties in a case where the servers weren't needed and call duration in all cases) to those servers when that is not always necessary? (3) (end of p5) You have a MUST NOT here that is depenedent on current browser implementations. Why is that an IETF thing and not a W3C thing? But more interestingly, can one securely use this protocol without the kind of JS vs. browser sandboxing etc that's needed in the web? If the answer is "no" then don't you need to say that this protocol can only safely be used for such implementations? (In section 2, which almost but not quite says that.) (4) Cleared. (5) Cleared. ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- (Was discuss point#4) "Section 8: Where are these 96 bits defined? I think this "requires..." statement needs a precise reference to the place in some ICE/TURN/STUN RFC where it's defined. (And I forget where that is, sorry:-) This should be an easy fix." Alissa gave me the reference [1] sothat's grand. It might be an idea to make that clearer if it wasn't just me missing it as I read, which is very possible;-) [1] https://tools.ietf.org/html/rfc5389#section-6 - abstract: why is only sending "media" mentioned here? What about data channels? And the body of the document in fact says this all applies to any non-ICE data and not only media. - intro: "initial consent to send by performing STUN" I do not find the word consent in either rfc5245 or 3489, but perhaps it is used somewhere else. Where? And with what meaning? - section 4, 2nd last para - I think the conclusion is bogus. An implementation knows when the keying it's using can not involve >1 (nominally operating) party. - 5.1, 3rd para: "Explicit consent to send is obtained..." is misleading. That is not a concept that an implementation of STUN will embody. - 5.1, What is the "Note" about TCP for? Why is this needed? From nobody Wed Aug 5 15:39:23 2015 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0097E1A1B3E; Wed, 5 Aug 2015 15:39:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.311 X-Spam-Level: X-Spam-Status: No, score=-4.311 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_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xVrnTjDbiA47; Wed, 5 Aug 2015 15:39:19 -0700 (PDT) Received: from mercury.scss.tcd.ie (mercury.scss.tcd.ie [134.226.56.6]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B150E1ACE16; Wed, 5 Aug 2015 15:39:18 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id A7186BE7D; Wed, 5 Aug 2015 23:39:16 +0100 (IST) X-Virus-Scanned: Debian amavisd-new at scss.tcd.ie Received: from mercury.scss.tcd.ie ([127.0.0.1]) by localhost (mercury.scss.tcd.ie [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lVDCY6b27bIe; Wed, 5 Aug 2015 23:39:15 +0100 (IST) Received: from [10.87.48.73] (unknown [86.42.29.233]) by mercury.scss.tcd.ie (Postfix) with ESMTPSA id AD1D0BE7C; Wed, 5 Aug 2015 23:39:14 +0100 (IST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cs.tcd.ie; s=mail; t=1438814354; bh=ocv787+mJ5g2s4xr8+WgiDcADqIQnXqO01RkN4t4yoY=; h=Date:From:To:CC:Subject:References:In-Reply-To:From; b=ts9YXhGklQojVWeSGmByL2OKVIRUJzgvJxR2uXK7Vw1YtlbKeL53rQmyCUEoaR3WE XndF4IMVhi3eJMqMMAe7EsqBgdP0YaRORTguLC9Oy6cpKrK/k5q4kz/UON33KcCCCe 0PjU5/wXrQIupgrmoqIdv2oTn/jA77GrphYkWVvM= Message-ID: <55C29092.1080703@cs.tcd.ie> Date: Wed, 05 Aug 2015 23:39:14 +0100 From: Stephen Farrell User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.8.0 MIME-Version: 1.0 To: Alissa Cooper References: <20150805130607.20844.70680.idtracker@ietfa.amsl.com> In-Reply-To: OpenPGP: id=D66EA7906F0B897FB2E97D582F3C8736805F8DA2; url= Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit Archived-At: Cc: draft-ietf-rtcweb-stun-consent-freshness@ietf.org, rtcweb-chairs@ietf.org, draft-ietf-rtcweb-stun-consent-freshness.shepherd@ietf.org, rtcweb@ietf.org, IESG , draft-ietf-rtcweb-stun-consent-freshness.ad@ietf.org Subject: Re: [rtcweb] Stephen Farrell's Discuss on draft-ietf-rtcweb-stun-consent-freshness-15: (with DISCUSS and COMMENT) X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 05 Aug 2015 22:39:22 -0000 Hiya, Thanks for that - I've cleared those points. Will come back to other discuss points tomorrow Cheers, S. On 05/08/15 20:47, Alissa Cooper wrote: > Thanks Stephen, responding to a couple points below where others have not chimed in yet. > > On Aug 5, 2015, at 6:06 AM, Stephen Farrell wrote: > >> Stephen Farrell has entered the following ballot position for >> draft-ietf-rtcweb-stun-consent-freshness-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-rtcweb-stun-consent-freshness/ >> >> >> >> ---------------------------------------------------------------------- >> DISCUSS: >> ---------------------------------------------------------------------- >> >> >> >> Apologies that these discuss points are maybe asking >> fairly fundamental questions. That could be that this >> is really the first of the new security things required >> by rtcweb to get to the IESG. Or maybe I'm misreading >> stuff here, if so, sorry;-) >> >> (1) Why call this "consent?" That term is (ab)used in >> many ways on the web, and adding another variation >> without a definition that distinguishes this from "click >> ok to my 200 page anti-privacy policy" or "remember that >> example.com is allowed use my camera/mic" seems like a >> terrible idea. I also don't see how this can ever be >> something to which a normal person can "consent" (i.e. >> consciously agree while fully understanding) so the term >> is IMO very misleading, and will I fear be used to >> mislead further. (See also some of the comments below - >> I do not think we ought be as fast and loose with this >> aleady terribly badly used term.) To summarise: I'd love >> if you did s/consent/anything-else/g but if not, please >> define consent here in a way that clearly and >> unambiguously distinguishes this usage from other abuses >> of the term. >> >> (2) WebRTC does not require STUN or TURN servers for >> some calls, even if it does for many. Why is it ok to >> require such a server be present in all calls (which I >> think this means) espcially when that means exposing >> additional meta-data (calling parties in a case where >> the servers weren't needed and call duration in all >> cases) to those servers when that is not always >> necessary? >> >> (3) (end of p5) You have a MUST NOT here that is >> depenedent on current browser implementations. Why is >> that an IETF thing and not a W3C thing? But more >> interestingly, can one securely use this protocol >> without the kind of JS vs. browser sandboxing etc that's >> needed in the web? If the answer is "no" then don't you >> need to say that this protocol can only safely be used >> for such implementations? (In section 2, which almost >> but not quite says that.) >> >> (4) Section 8: Where are these 96 bits defined? I think >> this "requires..." statement needs a precise reference >> to the place in some ICE/TURN/STUN RFC where it's >> defined. (And I forget where that is, sorry:-) This >> should be an easy fix. > > https://tools.ietf.org/html/rfc5389#section-6 (as referenced in Section 5.1) > >> >> (5) Why is it ok to approve this while the >> rtcweb-security-arch and rtcweb-security are still >> developing? There are section-specific references here >> along the lines of: "doing this is ok because of section >> x.x" of both of those drafts. Why is it ok to approve >> this now, when the underlying architecture and overall >> security model on which this depends are still in-flux? >> I'm not asking about editorial changes here nor about >> timing, but about why it's ok to approve this when the >> basic security concepts have yet to undergo IETF last >> call, and so could change significantly. > > I think it’s worth looking at what the cross-references actually point to. > > Section 2 says: > > "Section 4.4 and Section 5.3 of > [I-D.ietf-rtcweb-security-arch] further explains the value of > obtaining and maintaining consent.” > > Section 4.4 of draft-ietf-rtcweb-security-arch essentially says that implementations MUST use the mechanism specified in draft-ietf-stun-consent-freshness. Section 5.3 of draft-ietf-rtcweb-security-arch establishes the normative requirement that ICE be used and how it be used and explains the need for consent freshness. > > Section 8 says: > > "Consent Verification to avoid attacks using a browser as > an attack platform against machines is discussed in Sections 3.3 and > 4.2 of [I-D.ietf-rtcweb-security].” > > Both of these references are about the need to obtain consent in the first place, and as such I think they are provided more to give the broader picture of where stun-consent-freshness fits into the RTCWEB security story. Section 3.3 explains the threat model that motivates the need to obtain communications consent. Section 4.2 explains how this threat is mitigated, namely by using ICE. > > The upshot of this is if the WG or the IETF decides before publishing the security documents that communications consent isn’t actually necessary (seems highly unlikely to me), then maintaining consent freshness won’t make much sense, but having published this draft wouldn’t be particularly harmful either since it will basically be meaningless. Likewise, I guess in theory consensus could emerge not to use ICE. But in either of those cases, we could obsolete draft-ietf-stun-consent-freshness if it had already been published. Furthermore, if consensus does emerge not to use ICE, there will probably be bigger problems with the RTCWEB document suite than the fact that draft-ietf-stun-consent-freshness was published. > > If your concern is that the specific section numbers in the security documents might change, I think those could be taken out without issue. > > Alissa > > >> I do not think >> it would be acceptable for a comment/discuss on the >> security documents to be received with "yes, but you >> approved consent-freshness and so we implemented and >> deployed that so you're too late to make that >> comment/discuss and expect some change." >> >> >> ---------------------------------------------------------------------- >> COMMENT: >> ---------------------------------------------------------------------- >> >> >> - abstract: why is only sending "media" mentioned here? >> What about data channels? And the body of the document >> in fact says this all applies to any non-ICE data and >> not only media. >> >> - intro: "initial consent to send by performing STUN" I >> do not find the word consent in either rfc5245 or 3489, >> but perhaps it is used somewhere else. Where? And with >> what meaning? >> >> - section 4, 2nd last para - I think the conclusion is >> bogus. An implementation knows when the keying it's >> using can not involve >1 (nominally operating) party. >> >> - 5.1, 3rd para: "Explicit consent to send is >> obtained..." is misleading. That is not a concept that >> an implementation of STUN will embody. >> >> - 5.1, What is the "Note" about TCP for? Why is this >> needed? >> >> > > From nobody Wed Aug 5 15:54:46 2015 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2D1CD1ACEBB for ; Wed, 5 Aug 2015 15:54:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JD3jRP31LV_W for ; Wed, 5 Aug 2015 15:54:43 -0700 (PDT) Received: from mail-qg0-x236.google.com (mail-qg0-x236.google.com [IPv6:2607:f8b0:400d:c04::236]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 537EF1ACEB8 for ; Wed, 5 Aug 2015 15:54:43 -0700 (PDT) Received: by qgeg42 with SMTP id g42so4640142qge.1 for ; Wed, 05 Aug 2015 15:54:42 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=eR0aLrnu4vrQk/szc/Qy8k0noZcREs3FnpgqqwWHh1k=; b=XPkOw3fM1pD0ET1evfe7Td/WXw2ma+bvdpYgrzf+9PO8GBQgTGnkj9OFCf88M59Vx4 zpTlrl8cCb8cAYnq8msWVIL8kFsjuBLz3bYxy0vdVZwNX1eEtK6PGdfY1x6wzAJlbJ6m B9DLYVCvEm+KpAI9dIKBL1dvqrWNrkKuOS0z6uhSYOPF+00T1ClvGDZngmPf4/YMiLgx qHfoLOrJldD4N/ouD/LYx2wNWO+ADOOfcpwoAw34l/jZTdNtSmhlA7dlSEhMFD8tZip7 6IlHseXEtGr6rNO65RgmwsTgC3UkJx8Bf/fl0BzcnkxclvU3IGxa3lWOJnuHaUSbX+Dl RiMA== X-Received: by 10.140.25.136 with SMTP id 8mr20663158qgt.104.1438815282608; Wed, 05 Aug 2015 15:54:42 -0700 (PDT) MIME-Version: 1.0 Received: by 10.140.108.130 with HTTP; Wed, 5 Aug 2015 15:54:13 -0700 (PDT) In-Reply-To: <55C250CE.3040309@nostrum.com> References: <20150805161344.GA19492@lo.psyced.org> <20150805164256.GB19492@lo.psyced.org> <55C250CE.3040309@nostrum.com> From: Daniel Roesler Date: Wed, 5 Aug 2015 15:54:13 -0700 Message-ID: To: Adam Roach Content-Type: text/plain; charset=UTF-8 Archived-At: Cc: rtcweb@ietf.org Subject: Re: [rtcweb] LAST CALL: Systematically de-anonymize dissidents with WebRTC (HOWTO) X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 05 Aug 2015 22:54:45 -0000 While I'm not a fan of Carlo's antics, his concern is very valid and in my opinion it is highly concerning that members of this group are attacking his discourse and dismissing his point. Here's my understanding of his point: Before WebRTC: 1) Live in oppressive country 2) Buy one of the many popular anti-censorship VPNs 3) Visit NYTimes.com 4) Real IP address not accessible to NYTimes or advertisers After WebRTC: 1) Live in oppressive country 2) Buy one of the many popular anti-censorship VPNs 3) Visit NYTimes.com 4) Real IP address is leaked to NYTimes and advertisers Adam, can you please explain how this was possible before WebRTC? The threat model here is not a targeted attack looking to fingerprint a specific person. The threat model is that an oppressive regime can now find the exact IP address of censorship circumventing dissidents in their country by buying advertising on websites. This constitutes a real life-threatening scenario for many dissidents across the world. I completely understand why one would be quite mad at this working group for not acting when their life or friends'/family's lives are potentially on the line. Daniel On Wed, Aug 5, 2015 at 11:07 AM, Adam Roach wrote: > On 8/5/15 11:42, carlo von lynX wrote: >> >> On Wed, Aug 05, 2015 at 12:37:11PM -0400, Benjamin Schwartz wrote: >>> >>> Tor does not claim to protect against hostile websites unless you are >>> using >>> the Tor Browser Bundle, which is not subject to this issue (it already >>> disables WebRTC). >> >> Disclaimers are irrelevant here. > > > Bad advice is bad advice. If someone went around spreading the notion that > one can protect one's identity with Tor or with a VPN running on the same > machine as the browser, then that's no better than someone asserting that > one can protect one's identity by disabling IPv6, running an ad blocker, > using "private browsing mode," or wearing a hat coated with aluminum foil. > This was true before WebRTC, and it would remain true if we removed every > trace of WebRTC from the planet. > > If you're really interested helping the parties you're expressing concern > for, and you have the energy to "go noisy" on a topic, your efforts would be > best spent evangelizing TorBrowser or some other solution that provides some > semblance of useful anonymity. > > I have sympathy for the problem you're highlighting, but your histrionics > are undermining your point. We're trying to figure out a way to throw out > the bathwater while keeping the baby. Your suggestion that we instead nuke > the bathtub makes you sound like a kook. > > /a > > > _______________________________________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/listinfo/rtcweb From nobody Wed Aug 5 16:17:38 2015 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 22D521ACCE8 for ; Wed, 5 Aug 2015 16:17:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.978 X-Spam-Level: X-Spam-Status: No, score=-1.978 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, 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 jlW6nxEOG-C4 for ; Wed, 5 Aug 2015 16:17:35 -0700 (PDT) Received: from mail-ig0-f171.google.com (mail-ig0-f171.google.com [209.85.213.171]) (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 832151ACCE1 for ; Wed, 5 Aug 2015 16:17:35 -0700 (PDT) Received: by igbij6 with SMTP id ij6so564329igb.1 for ; Wed, 05 Aug 2015 16:17:35 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=NT5aeMJibJiWdS0G3vUtRqLIt34qaVbR2xVLNPh275k=; b=A2ZkCx89vd97v8vqKuGyYbHQYe8YucoWgGk/+yowqwjIGhUI1lIigdUWedpM4ALRDl ITGTY1TAgA7cDqXygMoJ/OYJxtYpAOr9P3iSiIiR4TO2VWYN0mBLbiIgItbkcL4pjQ9A xamb6wBL420OyKvs9IBsy7ve1wS7ZaCwojSQPz2zwwLSz0jKfPp1QGSwcDLMv4NJFCZW CONiY4rzu/dvVIGIF/NoDv28DEsuj6TGSIemj7GfRUUvMC8kEeL8CDgSseoJGQGqdno0 7n7nTESfELZHuWikWrBlZV5XL4NwSrWp30/dCId8RWmj2ty6qI/gvSyqys4aXQsNTUOX zBdw== X-Gm-Message-State: ALoCoQnFCepxtwN8F62RLyolH+PbrJympGsQLJ/5fluXxe80U/CyKZ2y/h0ppfBsfAU0u9fyhelD X-Received: by 10.50.43.193 with SMTP id y1mr110235igl.89.1438816654947; Wed, 05 Aug 2015 16:17:34 -0700 (PDT) Received: from mail-ig0-f173.google.com (mail-ig0-f173.google.com. [209.85.213.173]) by smtp.gmail.com with ESMTPSA id p8sm67824iga.13.2015.08.05.16.17.33 for (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 05 Aug 2015 16:17:33 -0700 (PDT) Received: by igbij6 with SMTP id ij6so564018igb.1 for ; Wed, 05 Aug 2015 16:17:33 -0700 (PDT) MIME-Version: 1.0 X-Received: by 10.50.138.231 with SMTP id qt7mr170141igb.96.1438816653562; Wed, 05 Aug 2015 16:17:33 -0700 (PDT) Received: by 10.36.89.70 with HTTP; Wed, 5 Aug 2015 16:17:33 -0700 (PDT) In-Reply-To: References: <20150805161344.GA19492@lo.psyced.org> <20150805164256.GB19492@lo.psyced.org> <55C250CE.3040309@nostrum.com> Date: Wed, 5 Aug 2015 19:17:33 -0400 Message-ID: From: Roman Shpount To: Daniel Roesler , carlo von lynX Content-Type: multipart/alternative; boundary=089e01184d5a885a8d051c989b68 Archived-At: Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] LAST CALL: Systematically de-anonymize dissidents with WebRTC (HOWTO) X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 05 Aug 2015 23:17:37 -0000 --089e01184d5a885a8d051c989b68 Content-Type: text/plain; charset=UTF-8 On Wed, Aug 5, 2015 at 6:54 PM, Daniel Roesler wrote: > While I'm not a fan of Carlo's antics, his concern is very valid and > in my opinion it is highly concerning that members of this group are > attacking his discourse and dismissing his point. > I am sorry, but what exactly do you or Carlo actually want? This group is not internet police. It cannot stop existing browser behavior. All this group can do is to adjust the standard, which it is already doing. If it is not doing it fast enough, well, it does not do anything fast. IETF is not designed for this. If you want to be productive, propose something and it will be discussed. This is all this group does -- discuss things and sometimes puts them into recommendations, which people can choose to follow (this is why they are called Requests For Comments, not laws written in stone). Also, anything that has anything to do with browser UI actually is not discussed here. It is managed by W3C. All the discussions on what should ask for user permission actually needs to go there. So all Carlo' comments are being dismissed because they are out of place and out of order, not because the topic is unimportant. His tone does not help either. _____________ Roman Shpount --089e01184d5a885a8d051c989b68 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On Wed, Aug 5, 2015 at 6:54 PM, Daniel Roesler=C2=A0<diaf= ygi@gmail.com>=C2=A0wrote:
While I'm = not a fan of Carlo's antics, his concern is very valid and
in my opi= nion it is highly concerning that members of this group are
attacking hi= s discourse and dismissing his point.

I am sorry, but what exactly do = you or Carlo actually want?

This group is not internet police. It cannot stop exi= sting browser behavior. All this group can do is to adjust the standard, wh= ich it is already doing. If it is not doing it fast enough, well, it does n= ot do anything fast. IETF is not designed for this. If you want to be produ= ctive, propose something and it will be discussed. This is all this group d= oes -- discuss things and sometimes puts them into recommendations, which p= eople can choose to follow (this is why they are called Requests For Commen= ts, not laws written in stone).

<= div class=3D"gmail_extra">Also, anything that has anything to do with brows= er UI actually is not discussed here. It is managed by W3C. All the discuss= ions on what should ask for user permission actually needs to go there.

So all Ca= rlo' comments are being dismissed because they are out of place and out= of order, not because the topic is unimportant. His tone does not help eit= her.
__= ___________
Roman Shpount

--089e01184d5a885a8d051c989b68-- From nobody Wed Aug 5 16:42:56 2015 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 532171B34BC for ; Wed, 5 Aug 2015 16:42:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id aBdL6A92wcDp for ; Wed, 5 Aug 2015 16:42:52 -0700 (PDT) Received: from mail-wi0-x230.google.com (mail-wi0-x230.google.com [IPv6:2a00:1450:400c:c05::230]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C1CE91B34B6 for ; Wed, 5 Aug 2015 16:42:51 -0700 (PDT) Received: by wicne3 with SMTP id ne3so1875106wic.1 for ; Wed, 05 Aug 2015 16:42:50 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=l4pHIh5E2Ijx6pkBN7ZcP+8l53o+r019hww1d6MQGDM=; b=bgEibfOUOAk8LmwXk7ZRijYxPuQg7poyToSmXiNkBH7A3BJD0GT+5Wb43Rmd6hdptA uSXsExhcRYUc3GpR5Db4HqLddqjCOkXzyhncTu1ICPwG90Qr6Gc97hWatIOlrUKVqFkH hG2lAEi98FLo6mHl9pk3SK3plDqsdc8TAB4EvTGSkQ51uY01V/4oU5x27sXB5Cmo8ORX pGvmgsQ3HH+/IrjQ8jyHFuAMjWCs/NCqkVH37god+e6zGTfrM8tfPiZ4he0CyjGz5HI1 +prm8aG+noecw7oTZcbMfcfIxEDdMsGSDQz+2vAVIFpdCVyI0a+C7aveQ1X32Vxoemmk ANEw== MIME-Version: 1.0 X-Received: by 10.194.122.97 with SMTP id lr1mr25089088wjb.26.1438818170535; Wed, 05 Aug 2015 16:42:50 -0700 (PDT) Received: by 10.194.17.68 with HTTP; Wed, 5 Aug 2015 16:42:50 -0700 (PDT) In-Reply-To: References: <20150805161344.GA19492@lo.psyced.org> <20150805164256.GB19492@lo.psyced.org> <55C250CE.3040309@nostrum.com> Date: Wed, 5 Aug 2015 16:42:50 -0700 Message-ID: From: Ted Hardie To: Daniel Roesler Content-Type: multipart/alternative; boundary=089e01228c70f3832a051c98f5ee Archived-At: Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] LAST CALL: Systematically de-anonymize dissidents with WebRTC (HOWTO) X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 05 Aug 2015 23:42:54 -0000 --089e01228c70f3832a051c98f5ee Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Daniel, On Wed, Aug 5, 2015 at 3:54 PM, Daniel Roesler wrote: > While I'm not a fan of Carlo's antics, his concern is very valid and > in my opinion it is highly concerning that members of this group are > attacking his discourse and dismissing his point. > > =E2=80=8BNo one is dismissing the issue, and both Chrome and Firefox have w= orked on code to provide short-term solution=E2=80=8Bs (see this work Justin pointed out to the list and Maire Reavy's post .) The group is actively discussing this topic and how to manage this going forward. A number of technical challenges have been pointed out (both in VPN configuration and the availability of information on network type to the browsers). Continuing to point out the severity of the problem in threads trying to resolve the problem is not helping progress; code, text, or data would. =E2=80=8Bregards, Ted Hardie=E2=80=8B =E2=80=8B =E2=80=8B --089e01228c70f3832a051c98f5ee Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Daniel,

=
On Wed, Aug 5, 2015 at 3:54 PM, Daniel Roesler <= span dir=3D"ltr"><diafygi@gmail.com> wrote:
= While I'm not a fan of Carlo's antics, his concern is very valid an= d
in my opinion it is highly concerning that members of this group are
attacking his discourse and dismissing his point.


=E2=80=8BNo one is dismissing the issue= , and both Chrome and Firefox have worked on code to provide short-term sol= ution=E2=80=8Bs (see thi= s work Justin pointed out to the list and Mair= e Reavy's post.)

The group is actively discu= ssing this topic and how to manage this going forward.=C2=A0 A number of te= chnical challenges have been pointed out (both in VPN configuration and the= availability of information on network type to the browsers).=C2=A0 Contin= uing to point out the severity of the problem in threads trying to resolve = the problem is not helping progress; code, text, or data would.=C2=A0
<= /div>
=E2=80=8Bregards,

Ted Hardie=E2= =80=8B

=E2=80=8B

=E2=80=8B
<= br>

--089e01228c70f3832a051c98f5ee-- From nobody Wed Aug 5 17:46:51 2015 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C48671B3540 for ; Wed, 5 Aug 2015 17:46:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id E6BG7_nJ5YrS for ; Wed, 5 Aug 2015 17:46:46 -0700 (PDT) Received: from mail.eeph.com (mail.eeph.com [192.135.198.155]) by ietfa.amsl.com (Postfix) with ESMTP id 899E11B353A for ; Wed, 5 Aug 2015 17:46:44 -0700 (PDT) Received: from [IPv6:2001:5a8:4:39d0:d5fe:6e06:c62e:6418] (unknown [IPv6:2001:5a8:4:39d0:d5fe:6e06:c62e:6418]) (Authenticated sender: matthew@eeph.com) by mail.eeph.com (Postfix) with ESMTPSA id 561C854872A for ; Wed, 5 Aug 2015 17:46:44 -0700 (PDT) Message-ID: <55C2AE77.6010603@matthew.at> Date: Wed, 05 Aug 2015 17:46:47 -0700 From: Matthew Kaufman User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.7.0 MIME-Version: 1.0 To: rtcweb@ietf.org References: <20150805161344.GA19492@lo.psyced.org> <20150805164256.GB19492@lo.psyced.org> <55C250CE.3040309@nostrum.com> In-Reply-To: Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [rtcweb] LAST CALL: Systematically de-anonymize dissidents with WebRTC (HOWTO) X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 06 Aug 2015 00:46:48 -0000 On 8/5/2015 3:54 PM, Daniel Roesler wrote: > While I'm not a fan of Carlo's antics, his concern is very valid and > in my opinion it is highly concerning that members of this group are > attacking his discourse and dismissing his point. > > Here's my understanding of his point: > > Before WebRTC: > 1) Live in oppressive country > 2) Buy one of the many popular anti-censorship VPNs > 3) Visit NYTimes.com > 4) Real IP address not accessible to NYTimes or advertisers Unless you have Flash Player 10.0 or later installed, in which case RTMFP and a cooperating server does this. Or you have any number of other plugins (e.g., Java) installed which can/will do this. Or NYTimes.com or an advertiser on there (or the proxy the oppressive country you live in transparently runs at the border) injects any number of zero-day drive-by attacks, any of which would give full access to your machine, including the ability to reveal the IP address (ref: http://www.zdnet.com/article/fbi-used-hacking-team-services-to-unmask-tor-user/ or https://blog.torproject.org/blog/tor-security-advisory-old-tor-browser-bundles-vulnerable). They'd probably also do other evil things, but it'd start by revealing your IP address. And that's if you simply limit to the browser case. In reality, before WebRTC you probably had one or another P2P applications, including possibly VoIP apps with P2P media capabilities, which are also routinely exposing the full set of addresses you have. > > After WebRTC: > 1) Live in oppressive country > 2) Buy one of the many popular anti-censorship VPNs > 3) Visit NYTimes.com > 4) Real IP address is leaked to NYTimes and advertisers > > Adam, can you please explain how this was possible before WebRTC? I'm not Adam, but see above. > > The threat model here is not a targeted attack looking to fingerprint > a specific person. The threat model is that an oppressive regime can > now find the exact IP address of censorship circumventing dissidents > in their country by buying advertising on websites. This constitutes a > real life-threatening scenario for many dissidents across the world. I > completely understand why one would be quite mad at this working group > for not acting when their life or friends'/family's lives are > potentially on the line. This working group isn't empowered to "act when their life or friends'/family's lives are potentially on the line". This is one of *two* working groups producing standards. One might think that these standards are being followed by the browser vendors, but in point of fact the browser vendors are writing and releasing code ahead of the publication of the standards, or in fact before full discussion has taken place here or in the corresponding W3C working group. If one of the IETF drafts itself poses a risk, please follow the processes we have for making changes to those documents prior to them becoming RFCs. In the meantime, to actually get this changed, that's up to the browser vendors to evaluate. Matthew Kaufman From nobody Wed Aug 5 19:31:32 2015 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C25551B2AED for ; Wed, 5 Aug 2015 19:31:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.91 X-Spam-Level: X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VEoU2it_W5a0 for ; Wed, 5 Aug 2015 19:31:29 -0700 (PDT) Received: from nostrum.com (raven-v6.nostrum.com [IPv6:2001:470:d:1130::1]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6D71E1B2AD9 for ; Wed, 5 Aug 2015 19:31:29 -0700 (PDT) Received: from Orochi.local (99-152-145-110.lightspeed.dllstx.sbcglobal.net [99.152.145.110]) (authenticated bits=0) by nostrum.com (8.15.2/8.14.9) with ESMTPSA id t762VS1i014245 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NO); Wed, 5 Aug 2015 21:31:28 -0500 (CDT) (envelope-from adam@nostrum.com) X-Authentication-Warning: raven.nostrum.com: Host 99-152-145-110.lightspeed.dllstx.sbcglobal.net [99.152.145.110] claimed to be Orochi.local Message-ID: <55C2C700.9000703@nostrum.com> Date: Wed, 05 Aug 2015 21:31:28 -0500 From: Adam Roach User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:31.0) Gecko/20100101 Thunderbird/31.7.0 MIME-Version: 1.0 To: Matthew Kaufman , rtcweb@ietf.org References: <20150805161344.GA19492@lo.psyced.org> <20150805164256.GB19492@lo.psyced.org> <55C250CE.3040309@nostrum.com> <55C2AE77.6010603@matthew.at> In-Reply-To: <55C2AE77.6010603@matthew.at> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [rtcweb] LAST CALL: Systematically de-anonymize dissidents with WebRTC (HOWTO) X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 06 Aug 2015 02:31:30 -0000 On 8/5/15 19:46, Matthew Kaufman wrote: > On 8/5/2015 3:54 PM, Daniel Roesler wrote: >> Adam, can you please explain how this was possible before WebRTC? > > I'm not Adam, but see above. > Thanks -- I think you covered the direct vectors pretty well. There are more subtle attacks than these, depending on the sophistication of your adversary; the "Anonymity and Security" section of the Tor FAQ [1] talks through some of these, many of which are applicable to VPNs at least as much as they are to Tor. I would highlight, in particular, the question titled "Is Tor like a VPN?". And lest the concerns about VPNs being a single point of privacy failure seem esoteric or far-fetched, I'll point out that they're far from theoretical [2]. /a ____ [1] https://www.torproject.org/docs/faq.html.en [2] A lot of electronic ink has been spilled on this one incident: https://encrypted.google.com/search?q=lulzsec+logs+nsa -- and, naturally, none has been spent on the cases that haven't come to light. From nobody Wed Aug 5 21:39:46 2015 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DDD561B3900 for ; Wed, 5 Aug 2015 21:39:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.8 X-Spam-Level: X-Spam-Status: No, score=0.8 tagged_above=-999 required=5 tests=[BAYES_50=0.8, RCVD_IN_DNSWL_NONE=-0.0001] 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 6nsVahzQ1-AJ for ; Wed, 5 Aug 2015 21:39:43 -0700 (PDT) Received: from ar-005-i192.relay.mailchannels.net (ar-005-i192.relay.mailchannels.net [162.253.144.74]) by ietfa.amsl.com (Postfix) with ESMTP id B02371B38FE for ; Wed, 5 Aug 2015 21:39:42 -0700 (PDT) X-Sender-Id: wwwh|x-authuser|randell@jesup.org Received: from r2-chicago.webserversystems.com (ip-10-204-4-183.us-west-2.compute.internal [10.204.4.183]) by relay.mailchannels.net (Postfix) with ESMTPA id 9FDF4120A67 for ; Thu, 6 Aug 2015 04:39:40 +0000 (UTC) X-Sender-Id: wwwh|x-authuser|randell@jesup.org Received: from r2-chicago.webserversystems.com (r2-chicago.webserversystems.com [10.244.170.40]) (using TLSv1 with cipher DHE-RSA-AES256-SHA) by 0.0.0.0:2500 (trex/5.5.1); Thu, 06 Aug 2015 04:39:41 +0000 X-MC-Relay: Neutral X-MailChannels-SenderId: wwwh|x-authuser|randell@jesup.org X-MailChannels-Auth-Id: wwwh X-MC-Loop-Signature: 1438835980838:2194910149 X-MC-Ingress-Time: 1438835980838 Received: from pool-96-227-119-208.phlapa.fios.verizon.net ([96.227.119.208]:51150 helo=[192.168.1.12]) by r2-chicago.webserversystems.com with esmtpsa (TLSv1:DHE-RSA-AES128-SHA:128) (Exim 4.85) (envelope-from ) id 1ZNCxu-0009ni-VJ for rtcweb@ietf.org; Wed, 05 Aug 2015 23:39:39 -0500 References: <20150805161344.GA19492@lo.psyced.org> <20150805164256.GB19492@lo.psyced.org> <55C250CE.3040309@nostrum.com> To: rtcweb@ietf.org From: Randell Jesup Message-ID: <55C2E4C5.2050805@jesup.org> Date: Thu, 6 Aug 2015 00:38:29 -0400 User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.1.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit X-AuthUser: randell@jesup.org Archived-At: Subject: Re: [rtcweb] LAST CALL: Systematically de-anonymize dissidents with WebRTC (HOWTO) X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 06 Aug 2015 04:39:46 -0000 On 8/5/2015 7:17 PM, Roman Shpount wrote: > On Wed, Aug 5, 2015 at 6:54 PM, Daniel Roesler > wrote: > > While I'm not a fan of Carlo's antics, his concern is very valid and > in my opinion it is highly concerning that members of this group are > attacking his discourse and dismissing his point. > > > I am sorry, but what exactly do you or Carlo actually want? > > This group is not internet police. It cannot stop existing browser > behavior. All this group can do is to adjust the standard, which it is > already doing. If it is not doing it fast enough, well, it does not do > anything fast. IETF is not designed for this. If you want to be > productive, propose something and it will be discussed. This is all > this group does -- discuss things and sometimes puts them into > recommendations, which people can choose to follow (this is why they > are called Requests For Comments, not laws written in stone). > > Also, anything that has anything to do with browser UI actually is not > discussed here. It is managed by W3C. All the discussions on what > should ask for user permission actually needs to go there. And per the announcements made on discuss-webrtc (the mailing list not involved with the standards process), both Chrome and Firefox are moving forward with enabling trial mitigations ahead of any changes in the standards. The current efforts are steps towards final solutions, so we can find out what the impacts are, and in the process make it possible for people to thwart such de-anonymizations proactively. Also: a government such as you describe can *trivially* determine who is using a VPN by simply buying their own accounts, looking at the VPN endpoint addresses, and monitoring traffic to those IP/IP-ranges from ISPs within their country. Tor avoids (some) of this type of attack, among other things. I'll note that anyone trying to be anonymous needs to actually follow some sort of advice on how to do so; they don't suddenly have a light-bulb go on and say "I need a VPN!". The default of browsers isn't "safe" for dissidents/etc. We can enable people to be (more, not totally) "safe", but we do need to balance that against other concerns. The advice given to people may need to change (use a VPN *and* this extension, or use a VPN *and* use private browsing mode - which BTW would likely be really good advice anyways! etc. Or (gasp) use the Tor browser bundle on a bootable USB stick (NOT on your HD!) (Note: We may well turn some of these mitigations on by default in private browsing mode, for example.) We can't make all "I think/hear I should be safe if I ..." methods users may be using actually *be* safe, though. See Adam's and Matthew's responses. We're also totally willing to consider other technical solutions, here or via a personal draft - though some might have to wait for additional spec updates - but as with most of WebRTC, the browsers have been way out ahead of the spec. Realize that if the suggestion is "disable the feature for the entire web", or to make it effectively unusable, it's not a good suggestion - and ironically may enable more control of populations by control of the remaining communications channels (phones, etc). WebRTC also has the potential to be leveraged into something that can bypass all sorts of authoritarian controls, and various forms of monitoring (using end-to-end encryption, Identity, and low-latency/cheap DataChannels), and people are working on such tools. > > So all Carlo' comments are being dismissed because they are out of > place and out of order, not because the topic is unimportant. His tone > does not help either. Agreed. -- Randell Jesup -- rjesup a t mozilla d o t com Please please please don't email randell-ietf@jesup.org! Way too much spam From nobody Wed Aug 5 21:56:31 2015 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AB15A1B3934; Wed, 5 Aug 2015 21:56:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.511 X-Spam-Level: X-Spam-Status: No, score=-14.511 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uvO9RBJLa4xl; Wed, 5 Aug 2015 21:56:24 -0700 (PDT) Received: from rcdn-iport-2.cisco.com (rcdn-iport-2.cisco.com [173.37.86.73]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 351B41B3933; Wed, 5 Aug 2015 21:56:24 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=6062; q=dns/txt; s=iport; t=1438836984; x=1440046584; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=0Z4OT6g2qLO0ve2jwDEAnfnQ4G4u4//WPcUaP5cpZRo=; b=aWz7gu4JoEchrXDne5WXGOkBJCMY8pWeil4ufViXuo/Gx0HhzN12Wav/ CK6DFMy28RQAEUDXfOkt9BF6rMg/UVu42Z4N6+3vSGXqkoSO9mvli21Dv RSoSCDWTUc3GdTMcI/LdlS2v9hfhDiZeP30hpmDm/0VWEMp2YVVMEz/fp s=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: A0A+AwCM58JV/4QNJK1bgxtUaQa8fQmCBoV3AoFMOBQBAQEBAQEBgQqEIwEBAQQ6PwwEAgEIEQECAQIfEDIXBggCBAENBYguDcxQAQEBAQEBAQEBAQEBAQEBAQEBAQEBEwSLT4QmEQFRAgUGhCYFhxyNZAGEfodXgUeEI5Aeg2Qmgj+BPm8BgQQCAwICFwccgQQBAQE X-IronPort-AV: E=Sophos;i="5.15,622,1432598400"; d="scan'208";a="21776194" Received: from alln-core-10.cisco.com ([173.36.13.132]) by rcdn-iport-2.cisco.com with ESMTP; 06 Aug 2015 04:56:23 +0000 Received: from XCH-RCD-011.cisco.com (xch-rcd-011.cisco.com [173.37.102.21]) by alln-core-10.cisco.com (8.14.5/8.14.5) with ESMTP id t764uNDb003023 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Thu, 6 Aug 2015 04:56:23 GMT Received: from xch-rcd-011.cisco.com (173.37.102.21) by XCH-RCD-011.cisco.com (173.37.102.21) with Microsoft SMTP Server (TLS) id 15.0.1104.5; Wed, 5 Aug 2015 23:56:22 -0500 Received: from xhc-aln-x07.cisco.com (173.36.12.81) by xch-rcd-011.cisco.com (173.37.102.21) with Microsoft SMTP Server (TLS) id 15.0.1104.5 via Frontend Transport; Wed, 5 Aug 2015 23:56:22 -0500 Received: from xmb-aln-x05.cisco.com ([169.254.11.9]) by xhc-aln-x07.cisco.com ([173.36.12.81]) with mapi id 14.03.0248.002; Wed, 5 Aug 2015 23:56:22 -0500 From: "Ram Mohan R (rmohanr)" To: Ben Campbell , The IESG Thread-Topic: Ben Campbell's Yes on draft-ietf-rtcweb-stun-consent-freshness-15: (with COMMENT) Thread-Index: AQHQ0AQ8gDhYCa2p6EiuA2gmHPEI0g== Date: Thu, 6 Aug 2015 04:56:21 +0000 Message-ID: References: <20150804220823.6096.97126.idtracker@ietfa.amsl.com> In-Reply-To: <20150804220823.6096.97126.idtracker@ietfa.amsl.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.5.3.150624 x-originating-ip: [173.37.102.17] Content-Type: text/plain; charset="us-ascii" Content-ID: <068CBEF11059E84AB442EC532D86A472@emea.cisco.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Cc: "draft-ietf-rtcweb-stun-consent-freshness.ad@ietf.org" , "rtcweb@ietf.org" , "draft-ietf-rtcweb-stun-consent-freshness@ietf.org" , "rtcweb-chairs@ietf.org" , "draft-ietf-rtcweb-stun-consent-freshness.shepherd@ietf.org" Subject: Re: [rtcweb] Ben Campbell's Yes on draft-ietf-rtcweb-stun-consent-freshness-15: (with COMMENT) X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 06 Aug 2015 04:56:26 -0000 Hi Ben, Thanks for your feedback. Please see my responses inline -----Original Message----- From: Ben Campbell Date: Wednesday, 5 August 2015 3:38 am To: The IESG Cc: "draft-ietf-rtcweb-stun-consent-freshness@ietf.org" , "rtcweb-chairs@ietf.org" , "draft-ietf-rtcweb-stun-consent-freshness.shepherd@ietf.org" , "draft-ietf-rtcweb-stun-consent-freshness.ad@ietf.org" , "rtcweb@ietf.org" Subject: Ben Campbell's Yes on draft-ietf-rtcweb-stun-consent-freshness-15: (with COMMENT) >Ben Campbell has entered the following ballot position for >draft-ietf-rtcweb-stun-consent-freshness-15: Yes > >When responding, please keep the subject line intact and reply to all >email addresses included in the To and CC lines. (Feel free to cut this >introductory paragraph, however.) > > >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-rtcweb-stun-consent-freshness/ > > > >---------------------------------------------------------------------- >COMMENT: >---------------------------------------------------------------------- > >This looks good overall. I have a few minor comments: > >-- General:=20 > >After re-reading this, and the relevant parts of >rtcweb-security-architecture, I think a novice reader might find the >meaning of "consent" a bit vague, especially in terms of how it might >differ from "reachability". Can you offer an example of when an otherwise >reachable peer might choose to withdraw consent? Reachability of a endpoint does not indicate that it is willing to receive traffic.=20 So if a peer has to continue sending data it must do consent. If the peer does not intend to send data, it can stop consent and later resume Whenever it wants to send data again. An example would be "As with a teacher in a classroom who grants consent to each student to speak words, consent is granted to each sender to transmit packets." > >-- section 1, first paragraph: > >I think readers are going to stumble over why we think a device that >plans to attack a peer is going to worry about consent. This makes more >sense in section 2. It might be helpful to move (or copy) the bit about >"... deployments of WebRTC..." and "... malicious javascript" forward to >the intro. Sure. I will move the text related to malicious javascript to first para of intro.=20 OLD: To prevent attacks on peers, endpoints have to ensure the remote peer is willing to receive traffic. This is performed both when the session is first established to the remote peer using Interactive Connectivity Establishment ICE [RFC5245] connectivity checks, and periodically for the duration of the session using the procedures defined in this document. NEW:=20 To prevent attacks on peers, endpoints have to ensure the remote peer is willing to receive traffic. Verification of peer consent before sending traffic is necessary in deployments like WebRTC to ensure that a malicious JavaScript cannot use the browser as a platform for launching attacks. This is performed both when the session is first established to the remote peer using Interactive Connectivity Establishment ICE [RFC5245] connectivity checks, and periodically for the duration of the session using the procedures defined in this document. > >- 4, 3rd paragraph: > >Should the reader infer that the receipt of a package that is strongly >assured to have come from a party implies consent from that party? If so, >it might be worth an explicit mention. No. Even in that case consent is needed. > >-- 5.1, first paragraph: > >The normative MUST feels wrong here, (and is probably redundant with >other normative language further down in the section.) For example, could >a sender just choose to stop sending? Sender can stop sending data on that pair at anytime. If the sender continues to send data, it must do consent other wise consent will expire. That is the reason the document says that consent must be maintained when application sends data. The other usage of normative statements are for timer selection which is needed to ensure that every implementation derives the timers based on the suggested range. > >-- 5.1, 5th paragraph: > >>From the next paragraph, I infer that you mean consent expires after 30 >seconds when you have been sending binding request every few seconds, not >30 seconds after sending any particular binding request. If that's >correct it might be helpful to add a few words to that effect. The next para discusses how the endpoint has to pace the bind requests for consent.=20 It mentions that the interval is between 4 - 6. > >-- 5.1, 6th paragraph: > >Does the "MUST NOT" refer to the general interval between checks prior to >randomization, or to the specific interval between a pair of checks after >Randomization? It is between a pair of checks after randomization. So essentially each request should be paced between 4 - 6 seconds after initial consent obtained (via ICE validation) > >Nits: > >-- 2, 2nd paragraph: "verify peer's consent" > >Missing article (or "verify peer consent") > >-- 5.1, paragraph 3: > >s/sending an stun binding/sending a stun binding > >-- 5.1, 7th paragraph: "Each STUN binding request for consent MUST use a >new STUN transaction > identifier for every consent binding request..." > >That's sort of redundant. I suggest something to the effect of "each >consent binding request MUST use a new stun transaction identifier. " Thanks. Will address all the nits above. Regards, Ram > > From nobody Wed Aug 5 21:56:58 2015 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2B04B1B3933; Wed, 5 Aug 2015 21:56:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cTY3wY56s6Zc; Wed, 5 Aug 2015 21:56:44 -0700 (PDT) Received: from mail-la0-x236.google.com (mail-la0-x236.google.com [IPv6:2a00:1450:4010:c03::236]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 34C961B3934; Wed, 5 Aug 2015 21:56:44 -0700 (PDT) Received: by labow3 with SMTP id ow3so41842700lab.1; Wed, 05 Aug 2015 21:56:42 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=6Z3axOxTBLIKq44svPmQNSP5L/NmMxmNM/Ae7R2sDf4=; b=TEf5b1FqQEJtoz/KAemyxYYTLZ5gPWKdGhCDhdRnNKiDO4I+M915zwzqncgW7VFexs krRiHM2EV8lg2Qa6vZofJ6DTvG6o8TH0wiGIKz+1dSHMvCaXN8Whc+YCikdf3CFljATm KbxmfDDI2Zgu4WkPZ0Ka1AT2xQAfIAMxnQ+zcJta7vT1nmVRQGrEFdgQCphMKwu0NFkx 0CskPvYt0O+KZMPhOWzUFLfWuJU9WlAWWoMxf+KHL064lo/NOFpxBrk3MA90+NUFrPHG J770XDpUflCsVu4U5tPkewWBnCeZjzVi9MGLFrjffAIsIefXW2OT2++BlSTwV470MGVD jFoQ== MIME-Version: 1.0 X-Received: by 10.112.120.134 with SMTP id lc6mr12994287lbb.86.1438837002721; Wed, 05 Aug 2015 21:56:42 -0700 (PDT) Received: by 10.25.141.213 with HTTP; Wed, 5 Aug 2015 21:56:42 -0700 (PDT) In-Reply-To: <20150805223837.26225.49192.idtracker@ietfa.amsl.com> References: <20150805223837.26225.49192.idtracker@ietfa.amsl.com> Date: Thu, 6 Aug 2015 10:26:42 +0530 Message-ID: From: Muthu Arul Mozhi Perumal To: Stephen Farrell Content-Type: multipart/alternative; boundary=047d7beb9f0c6fe155051c9d58a1 Archived-At: Cc: draft-ietf-rtcweb-stun-consent-freshness@ietf.org, rtcweb-chairs@ietf.org, draft-ietf-rtcweb-stun-consent-freshness.shepherd@ietf.org, "rtcweb@ietf.org" , The IESG , draft-ietf-rtcweb-stun-consent-freshness.ad@ietf.org Subject: Re: [rtcweb] Stephen Farrell's Discuss on draft-ietf-rtcweb-stun-consent-freshness-15: (with DISCUSS and COMMENT) X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 06 Aug 2015 04:56:51 -0000 --047d7beb9f0c6fe155051c9d58a1 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Hi Stephen, On Thu, Aug 6, 2015 at 4:08 AM, Stephen Farrell wrote: > Stephen Farrell has entered the following ballot position for > draft-ietf-rtcweb-stun-consent-freshness-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-rtcweb-stun-consent-freshness= / > > > > ---------------------------------------------------------------------- > DISCUSS: > ---------------------------------------------------------------------- > > > > Apologies that these discuss points are maybe asking > fairly fundamental questions. That could be that this > is really the first of the new security things required > by rtcweb to get to the IESG. Or maybe I'm misreading > stuff here, if so, sorry;-) > > (1) Why call this "consent?" That term is (ab)used in > many ways on the web, and adding another variation > without a definition that distinguishes this from "click > ok to my 200 page anti-privacy policy" or "remember that > example.com is allowed use my camera/mic" seems like a > terrible idea. I also don't see how this can ever be > something to which a normal person can "consent" (i.e. > consciously agree while fully understanding) so the term > is IMO very misleading, and will I fear be used to > mislead further. (See also some of the comments below - > I do not think we ought be as fast and loose with this > aleady terribly badly used term.) To summarise: I'd love > if you did s/consent/anything-else/g but if not, please > define consent here in a way that clearly and > unambiguously distinguishes this usage from other abuses > of the term. > =E2=80=8BThe document already has a clear and unambiguous definition of the= term, IMHO: =E2=80=8B =E2=80=8B Consent: The mechanism of obtaining permission from the remote endpoint to send non-ICE traffic to a remote transport address. Consent is obtained using ICE.=E2=80=8B =E2=80=8BIs that definition lacking something? =E2=80=8BI think finding an = alter term would be as hard as finding an alternate term for 'attack' as used in several RFCs [attack being (ab)used in many contexts, including in heart attack ;)] > > (2) WebRTC does not require STUN or TURN servers for > some calls, even if it does for many. Why is it ok to > require such a server be present in all calls (which I > think this means) espcially when that means exposing > additional meta-data (calling parties in a case where > the servers weren't needed and call duration in all > cases) to those servers when that is not always > necessary? > =E2=80=8BThat looks a misunderstanding. Consent freshness doesn't require s= uch server's to be present. Please point out to the text leading to the misunderstanding. > > (3) (end of p5) You have a MUST NOT here that is > depenedent on current browser implementations. Why is > that an IETF thing and not a W3C thing? But more > interestingly, can one securely use this protocol > without the kind of JS vs. browser sandboxing etc that's > needed in the web? =E2=80=8BYes, the mechanism has the same security properties within and out= side the WebRTC sandboxing. > If the answer is "no" then don't you > need to say that this protocol can only safely be used > for such implementations? (In section 2, which almost > but not quite says that.) > =E2=80=8BSection 2 doesn't say that. It only says WebRTC is the primary use= case for the mechanism at the moment and future use cases based on similar sandboxing models can make use of it. > > (4) Cleared. > > (5) Cleared. > > > ---------------------------------------------------------------------- > COMMENT: > ---------------------------------------------------------------------- > > > (Was discuss point#4) > "Section 8: Where are these 96 bits defined? I think > this "requires..." statement needs a precise reference > to the place in some ICE/TURN/STUN RFC where it's > defined. (And I forget where that is, sorry:-) This > should be an easy fix." > Alissa gave me the reference [1] sothat's grand. It > might be an idea to make that clearer if it wasn't > just me missing it as I read, which is very possible;-) > > [1] https://tools.ietf.org/html/rfc5389#section-6 > > - abstract: why is only sending "media" mentioned here? > What about data channels? And the body of the document > in fact says this all applies to any non-ICE data and > not only media. > =E2=80=8BAgree, that should be "traffic". > > - intro: "initial consent to send by performing STUN" I > do not find the word consent in either rfc5245 or 3489, > but perhaps it is used somewhere else. Where? And with > what meaning? > =E2=80=8BConsent is a new usage of STUN and is described in draft-ietf-rtcweb-security-arch, draft-ietf-rtcweb-security and in this document. > > - section 4, 2nd last para - I think the conclusion is > bogus. An implementation knows when the keying it's > using can not involve >1 (nominally operating) party. > That paragraph is here: =E2=80=8B=E2=80=8B When Secure Real-time Transport Protocol (SRTP) is use= d, the following considerations are applicable. SRTP is encrypted and authenticated with symmetric keys; that is, both sender and receiver know the keys. With two party sessions, receipt of an authenticated packet from the single remote party is a strong assurance the packet came from that party. However, when a session involves more than two parties, all of whom know each other's keys, any of those parties could have sent (or spoofed) the packet. Such shared key distributions are possible with some MIKEY [RFC3830] modes, Security Descriptions [RFC4568], and EKT [I-D.ietf-avtcore-srtp-ekt]. Thus, in such shared keying distributions, receipt of an authenticated SRTP packet is not sufficient to verify consent. =E2=80=8BI'll defer it to someone who has more knowledge that me on shared = key distribution.. > > - 5.1, 3rd para: "Explicit consent to send is > obtained..." is misleading. That is not a concept that > an implementation of STUN will embody. > =E2=80=8BAs said earlier, consent is a new STUN usage. How would the follow= ing? An endpoint that implements this specification obtains and maintains consent to send by sending STUN binding request... > > - 5.1, What is the "Note" about TCP for? Why is this > needed? > =E2=80=8BIt is needed because WebRTC data traffic sent over TCP could get c= onverted to UDP by TURN servers. It is somewhat similar to why we need application layer security when traffic is sent over IPSec. The later may not be end-to-end. Muthu --047d7beb9f0c6fe155051c9d58a1 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hi Stephen,

On Thu, Aug 6, 2015 at 4:08 AM, Stephen Farrell <stephen.farrell@cs.= tcd.ie> wrote:
Stephen Farrell has entered the following ballot p= osition for
draft-ietf-rtcweb-stun-consent-freshness-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/s= tatement/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.o= rg/doc/draft-ietf-rtcweb-stun-consent-freshness/



----------------------------------------------------------------------
DISCUSS:
----------------------------------------------------------------------



Apologies that these discuss points are maybe asking
fairly fundamental questions.=C2=A0 That could be that this
is really the first of the new security things required
by rtcweb to get to the IESG.=C2=A0 Or maybe I'm misreading
stuff here, if so, sorry;-)

(1) Why call this "consent?" That term is (ab)used in
many ways on the web, and adding another variation
without a definition that distinguishes this from "click
ok to my 200 page anti-privacy policy" or "remember that
example= .com is allowed use my camera/mic" seems like a
terrible idea. I also don't see how this can ever be
something to which a normal person can "consent" (i.e.
consciously agree while fully understanding) so the term
is IMO very misleading, and will I fear be used to
mislead further.=C2=A0 (See also some of the comments below -
I do not think we ought be as fast and loose with this
aleady terribly badly used term.) To summarise: I'd love
if you did s/consent/anything-else/g but if not, please
define consent here in a way that clearly and
unambiguously distinguishes this usage from other abuses
of the term.

=E2=80= =8BThe document already has a clear and unambiguous definition of the term,= IMHO: =E2=80=8B

=E2=80= =8B =C2=A0 Consent: =C2=A0The mechanism of obtaining permission from the re= mote
=C2=A0 =C2=A0 =C2=A0 endpoint to send non-ICE traffic to a rem= ote transport address.
=C2=A0 =C2=A0 =C2=A0 Consent= is obtained using ICE.=E2=80=8B

=E2= =80=8BIs that definition lacking something? =E2=80=8BI think finding an alt= er term would be as hard as finding an alternate term for 'attack' = as used in several RFCs [attack being (ab)used in many contexts, including = in heart attack ;)]
=C2=A0

(2) WebRTC does not require STUN or TURN servers for
some calls, even if it does for many. Why is it ok to
require such a server be present in all calls (which I
think this means) espcially when that means exposing
additional meta-data (calling parties in a case where
the servers weren't needed and call duration in all
cases) to those servers when that is not always
necessary?

=E2=80=8B= That looks a misunderstanding. Consent freshness doesn't require such s= erver's to be present. Please point out to the text leading to the misu= nderstanding.
=C2=A0

(3) (end of p5) You have a MUST NOT here that is
depenedent on current browser implementations. Why is
that an IETF thing and not a W3C thing? But more
interestingly, can one securely use this protocol
without the kind of JS vs. browser sandboxing etc that's
needed in the web?

=E2= =80=8BYes, the mechanism has the same security properties within and outsid= e the WebRTC sandboxing.
=C2=A0
If the answer is "no" then don't you
need to say that this protocol can only safely be used
for such implementations? (In section 2, which almost
but not quite says that.)

=E2=80=8BSection 2 doesn't say that. It only says WebRTC is the p= rimary use case for the mechanism at the moment and future use cases based = on similar sandboxing models can make use of it.=C2=A0
=C2= =A0

(4) Cleared.

(5) Cleared.


----------------------------------------------------------------------
COMMENT:
----------------------------------------------------------------------


(Was discuss point#4)
"Section 8: Where are these 96 bits defined? I think
this "requires..." statement needs a precise reference
to the place in some ICE/TURN/STUN RFC where it's
defined. (And I forget where that is, sorry:-) This
should be an easy fix."
Alissa gave me the reference [1] sothat's grand. It
might be an idea to make that clearer if it wasn't
just me missing it as I read, which is very possible;-)

[1] https://tools.ietf.org/html/rfc5389#section-6
- abstract: why is only sending "media" mentioned here?
What about data channels?=C2=A0 And the body of the document
in fact says this all applies to any non-ICE data and
not only media.

=E2= =80=8BAgree, that should be "traffic".
=C2=A0

- intro: "initial consent to send by performing STUN" I
do not find the word consent in either rfc5245 or 3489,
but perhaps it is used somewhere else. Where?=C2=A0 And with
what meaning?

=E2=80= =8BConsent is a new usage of STUN and is described in draft-ietf-rtcweb-sec= urity-arch, draft-ietf-rtcweb-security and in this document.
=C2=A0

- section 4, 2nd last para - I think the conclusion is
bogus.=C2=A0 An implementation knows when the keying it's
using can not involve >1 (nominally operating) party.

That paragraph is here:

=E2=80=8B=E2=80=8B =C2=A0 When Secure R= eal-time Transport Protocol (SRTP) is used, the
=C2=A0 =C2=A0follow= ing considerations are applicable.=C2=A0 SRTP is encrypted and
=C2= =A0 =C2=A0authenticated with symmetric keys; that is, both sender and recei= ver
=C2=A0 =C2=A0know the keys.=C2=A0 With two party sessions, rece= ipt of an authenticated
=C2=A0 =C2=A0packet from the single remote = party is a strong assurance the packet
=C2=A0 =C2=A0came from that = party.=C2=A0 However, when a session involves more than two
=C2=A0 = =C2=A0parties, all of whom know each other's keys, any of those parties=
=C2=A0 =C2=A0could have sent (or spoofed) the packet.=C2=A0 Such s= hared key
=C2=A0 =C2=A0distributions are possible with some MIKEY [= RFC3830] modes, Security
=C2=A0 =C2=A0Descriptions [RFC4568], and E= KT [I-D.ietf-avtcore-srtp-ekt].=C2=A0 Thus,
=C2=A0 =C2=A0in such sh= ared keying distributions, receipt of an authenticated SRTP
=C2=A0 = =C2=A0packet is not sufficient to verify consent.

=E2=80=8BI'll defer it to someone who has more knowledge = that me on shared key distribution..=C2=A0
=C2=A0

- 5.1, 3rd para: "Explicit consent to send is
obtained..." is misleading. That is not a concept that
an implementation of STUN will embody.

=
=E2=80=8BAs said earlier, consent is a new STUN usage. H= ow would the following?

=C2=A0 =C2=A0 An endpoint that implements this specification obtains and = maintains=C2=A0
=C2=A0 =C2=A0 consent to send b= y sending STUN binding request...
=C2=A0

- 5.1, What is the "Note" about TCP for? Why is this
needed?

=E2=80=8BIt is needed because WebRTC data traffic sent over TCP could ge= t converted to UDP by TURN servers. It is somewhat similar to why we need a= pplication layer security when traffic is sent over IPSec. The later may no= t be end-to-end.

Muthu
--047d7beb9f0c6fe155051c9d58a1-- From nobody Wed Aug 5 22:46:16 2015 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0B09E1B2A10; Wed, 5 Aug 2015 22:46:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.2 X-Spam-Level: X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5w_JoV7BKIUu; Wed, 5 Aug 2015 22:46:10 -0700 (PDT) Received: from sessmg22.ericsson.net (sessmg22.ericsson.net [193.180.251.58]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3792E1A8940; Wed, 5 Aug 2015 22:46:09 -0700 (PDT) X-AuditID: c1b4fb3a-f79356d000006281-8c-55c2f49ecb9d Received: from ESESSHC022.ericsson.se (Unknown_Domain [153.88.253.124]) by sessmg22.ericsson.net (Symantec Mail Security) with SMTP id 8F.5A.25217.E94F2C55; Thu, 6 Aug 2015 07:46:07 +0200 (CEST) Received: from ESESSMB209.ericsson.se ([169.254.9.36]) by ESESSHC022.ericsson.se ([153.88.183.84]) with mapi id 14.03.0210.002; Thu, 6 Aug 2015 07:46:06 +0200 From: Christer Holmberg To: Eric Rescorla , Stephen Farrell Thread-Topic: [rtcweb] Stephen Farrell's Discuss on draft-ietf-rtcweb-stun-consent-freshness-15: (with DISCUSS and COMMENT) Thread-Index: AQHQz3+KPHF90ErmFk+lirKPCDNxv539Y5RggAAa8oCAAAGvgIAABSgAgAAAuICAAPBjkA== Date: Thu, 6 Aug 2015 05:46:05 +0000 Message-ID: <7594FB04B1934943A5C02806D1A2204B348EA2EC@ESESSMB209.ericsson.se> References: <20150805130607.20844.70680.idtracker@ietfa.amsl.com> <7594FB04B1934943A5C02806D1A2204B348E9691@ESESSMB209.ericsson.se> <55C23FFD.8070201@cs.tcd.ie> <55C245BA.9000504@cs.tcd.ie> 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.16] Content-Type: multipart/alternative; boundary="_000_7594FB04B1934943A5C02806D1A2204B348EA2ECESESSMB209erics_" MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFlrJIsWRmVeSWpSXmKPExsUyM+Jvje78L4dCDa4s47O4NuE7s8WFS6uZ LXY8b2C1WPH6HLvFjD8TmS163t5gsVj7r53dYvrea+wOHB5ru6+yeSxZ8pPJY/LjNuYA5igu m5TUnMyy1CJ9uwSujOM/fzAVrKio+HZ1KWMDY0dpFyMnh4SAicTUDSdYIWwxiQv31rN1MXJx CAkcZZTofLydHcJZxCixePMOoAwHB5uAhUT3P22QBhEBX4m5D1oYQWqYBa4yS9w618sMkhAW qJG4dGM2I0RRrcTd3Y1sEHaYxPITO1hAbBYBFYmzt1+A1fMCDbp9bTsjxLKLTBIrlh8CK+IU CJT4+fU2E4jNCHTe91NrwGxmAXGJW0/mM0GcLSCxZM95ZghbVOLl439Q7yhK7DzbzgxRny+x cMdhFohlghInZz5hmcAoOgvJqFlIymYhKZsF9DOzgKbE+l36ECWKElO6H7JD2BoSrXPmsiOL L2BkX8UoWpxaXJybbmSkl1qUmVxcnJ+nl5dasokRGLcHt/y22sF48LnjIUYBDkYlHt4F+w+F CrEmlhVX5h5ilOZgURLnnbE5L1RIID2xJDU7NbUgtSi+qDQntfgQIxMHp1QD42TPzxVXW6o2 sNy1mib4TWayYr3CJs3XeX+4lotOv2Hx48DFJnnd//zVpf5x3rY2e5MY5aV+xL0zZnsZ//m+ 4sHc1quNHqw5L3tuZHdNWdTL4FzyyuGAzaTarbcspt8+auAzad7/szpnnsT3rUlbv+nBp3l/ Pv+YdZSRgYnXTCLpu6qM9h5ObiWW4oxEQy3mouJEAMW3cNa8AgAA Archived-At: Cc: "draft-ietf-rtcweb-stun-consent-freshness@ietf.org" , "rtcweb-chairs@ietf.org" , "draft-ietf-rtcweb-stun-consent-freshness.shepherd@ietf.org" , "rtcweb@ietf.org" , The IESG , "draft-ietf-rtcweb-stun-consent-freshness.ad@ietf.org" Subject: Re: [rtcweb] Stephen Farrell's Discuss on draft-ietf-rtcweb-stun-consent-freshness-15: (with DISCUSS and COMMENT) X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 06 Aug 2015 05:46:13 -0000 --_000_7594FB04B1934943A5C02806D1A2204B348EA2ECESESSMB209erics_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SGksDQoNCkNvcnJlY3QuDQoNCkZyb20gYSBTVFVOIHByb3RvY29sIHBlcnNwZWN0aXZlLCBjb25z ZW50IHJlcXVlc3RzIGFyZSBub3JtYWwgU1RVTiBjb25uZWN0aXZpdHkgY2hlY2tzLg0KDQpTbywg dGhlIGJyb3dzZXIgd2lsbCBiZSBhIOKAnHNlcnZlcuKAnSBpbiB0aGUgc2Vuc2UgdGhhdCBpdCBy ZWNlaXZlcyBhbmQgcHJvY2Vzc2VzIFNUVU4gY29ubmVjdGl2aXR5IGNoZWNrcywgYnV0IGl0IHdp bGwgbm90IGJlIGEg4oCcU1RVTiBzZXJ2ZXLigJ0gOikNCg0KUmVnYXJkcywNCg0KQ2hyaXN0ZXIN Cg0KRnJvbTogRXJpYyBSZXNjb3JsYSBbbWFpbHRvOmVrckBydGZtLmNvbV0NClNlbnQ6IDUuIGVs b2t1dXRhIDIwMTUgMjA6MjINClRvOiBTdGVwaGVuIEZhcnJlbGwNCkNjOiBkcmFmdC1pZXRmLXJ0 Y3dlYi1zdHVuLWNvbnNlbnQtZnJlc2huZXNzQGlldGYub3JnOyBydGN3ZWItY2hhaXJzQGlldGYu b3JnOyBkcmFmdC1pZXRmLXJ0Y3dlYi1zdHVuLWNvbnNlbnQtZnJlc2huZXNzLnNoZXBoZXJkQGll dGYub3JnOyBydGN3ZWJAaWV0Zi5vcmc7IFRoZSBJRVNHOyBDaHJpc3RlciBIb2xtYmVyZzsgZHJh ZnQtaWV0Zi1ydGN3ZWItc3R1bi1jb25zZW50LWZyZXNobmVzcy5hZEBpZXRmLm9yZw0KU3ViamVj dDogUmU6IFtydGN3ZWJdIFN0ZXBoZW4gRmFycmVsbCdzIERpc2N1c3Mgb24gZHJhZnQtaWV0Zi1y dGN3ZWItc3R1bi1jb25zZW50LWZyZXNobmVzcy0xNTogKHdpdGggRElTQ1VTUyBhbmQgQ09NTUVO VCkNCg0KVGhpcyBmcmVzaG5lc3Mgc3R1ZmYgaXMgYWxzbyBhYm91dCAjMy4gTmFtZWx5LCBpdCdz IGFib3V0IHRoZSBlbmRwb2ludHMNCmRvaW5nIGNvbnRpbnVhbCBTVFVOIGNvbm5lY3Rpdml0eSBj aGVja3MgYmV0d2VlbiBlYWNoIG90aGVyLg0KDQotRWtyDQoNCg0KT24gV2VkLCBBdWcgNSwgMjAx NSBhdCAxMDoxOSBBTSwgU3RlcGhlbiBGYXJyZWxsIDxzdGVwaGVuLmZhcnJlbGxAY3MudGNkLmll PG1haWx0bzpzdGVwaGVuLmZhcnJlbGxAY3MudGNkLmllPj4gd3JvdGU6DQoNCg0KT24gMDUvMDgv MTUgMTg6MDEsIEVyaWMgUmVzY29ybGEgd3JvdGU6DQo+IE9uIFdlZCwgQXVnIDUsIDIwMTUgYXQg OTo1NSBBTSwgU3RlcGhlbiBGYXJyZWxsIDxzdGVwaGVuLmZhcnJlbGxAY3MudGNkLmllPG1haWx0 bzpzdGVwaGVuLmZhcnJlbGxAY3MudGNkLmllPj4NCj4gd3JvdGU6DQo+DQo+Pg0KPj4gSGl5YSwN Cj4+DQo+PiBPbiAwNS8wOC8xNSAxNDoyMiwgQ2hyaXN0ZXIgSG9sbWJlcmcgd3JvdGU6DQo+Pj4g SGkgU3RlcGhlbiwNCj4+Pg0KPj4+PiAoMikgV2ViUlRDIGRvZXMgbm90IHJlcXVpcmUgU1RVTiBv ciBUVVJOIHNlcnZlcnMgZm9yIHNvbWUgY2FsbHMsDQo+Pj4+IGV2ZW4gaWYgaXQgZG9lcyBmb3Ig bWFueS4gV2h5IGlzIGl0IG9rIHRvIHJlcXVpcmUgc3VjaCBhIHNlcnZlciBiZQ0KPj4+PiBwcmVz ZW50IGluIGFsbCBjYWxscyAod2hpY2ggSSB0aGluayB0aGlzIG1lYW5zKSBlc3BjaWFsbHkgd2hl biB0aGF0DQo+Pj4+IG1lYW5zIGV4cG9zaW5nIGFkZGl0aW9uYWwgbWV0YS1kYXRhIChjYWxsaW5n IHBhcnRpZXMgaW4gYSBjYXNlDQo+Pj4+IHdoZXJlIHRoZSBzZXJ2ZXJzIHdlcmVuJ3QgbmVlZGVk IGFuZCBjYWxsIGR1cmF0aW9uIGluIGFsbCBjYXNlcykgdG8NCj4+Pj4gdGhvc2Ugc2VydmVycyB3 aGVuIHRoYXQgaXMgbm90IGFsd2F5cyBuZWNlc3Nhcnk/DQo+Pj4NCj4+PiBDb3VsZCB5b3UgcGxl YXNlIHJlZmVyIHRvIHRoZSB0ZXh0IHdoaWNoIHlvdSB0aGluayBtYW5kYXRlcyBTVFVOIG9yDQo+ Pj4gVFVSTiBzZXJ2ZXJzPw0KPj4NCj4+IFN1cmUsIEkgdGhpbmsgdGhlcmUgd2VyZSBhIGNvdXBs ZSBvZiBwbGFjZXMsIGJ1dCBJJ2QgaGF2ZSB0bw0KPj4gdHJhY2sgJ2VtIGRvd24uIEknbGwgdHJ5 IHVwZGF0ZSB0aGUgYmFsbG90IHdpdGggdGhhdCBpZiBpdA0KPj4gdHVybnMgb3V0IHRvIGJlIG5l ZWRlZC4gKEJlIHRvbW9ycm93IGJlZm9yZSBJIGdldCB0byB0aGF0LA0KPj4gc29ycnkuKQ0KPj4N Cj4+Pg0KPj4+IElmIHRoZXJlIGFyZSBubyBOQVRzLCB0aGUgU1RVTiByZXF1ZXN0cyBjYW4gYmUg c2VudCBiZXR3ZWVuIHRoZQ0KPj4+IGVuZHBvaW50cywgd2l0aG91dCBTVFVOIG9yIFRVUk4gc2Vy dmVycy4NCj4+DQo+PiBSZWFsbHkgLSBzbyBicm93c2VycyB3aWxsIGJlIGFibGUgdG8gYWN0IGxp a2UgYSBTVFVOIHNlcnZlciBvcg0KPj4gc29tZXRoaW5nPyBJIGRpZG4ndCBrbm93IHRoYXQuIFdo ZXJlJ3MgdGhhdCBkZXNjcmliZWQ/DQo+DQo+DQo+IElDRSB1c2VzIFNUVU4gaW4gdGhyZWUgd2F5 czoNCj4NCj4gMS4gRm9yIGFkZHJlc3MgZGlzY292ZXJ5DQo+IDIuIFRvIHRhbGsgdG8gVFVSTiBz ZXJ2ZXJzIChUVVJOIGlzIGJhc2VkIG9uIFNUVU4pDQo+IDMuIEZvciBJQ0UgY29ubmVjdGl2aXR5 IGNoZWNrcy4NCj4NCj4gQ2hyaXN0ZXIgaXMgcmVmZXJyaW5nIHRvICMzLg0KT2ssIGFuZCB3aGF0 IGhhcHBlbnMgd2l0aCB0aGlzIGZyZXNobmVzcyBzdHVmZiBpbiB0aGF0DQpzY2VuYXJpbz8gKEFw b2xvZ2llcyBpZiBpdHMgaW4gdGhpcyBvciBzb21lIG90aGVyIGRyYWZ0DQphbmQgSSBtaXNzZWQg aXQpDQoNClMNCg0KPg0KPiAtRWtyDQo+DQo+DQo+PiBTLg0KPj4NCj4+DQo+Pj4NCj4+PiBSZWdh cmRzLA0KPj4+DQo+Pj4gQ2hyaXN0ZXINCj4+Pg0KPj4NCj4+IF9fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fDQo+PiBydGN3ZWIgbWFpbGluZyBsaXN0DQo+PiBy dGN3ZWJAaWV0Zi5vcmc8bWFpbHRvOnJ0Y3dlYkBpZXRmLm9yZz4NCj4+IGh0dHBzOi8vd3d3Lmll dGYub3JnL21haWxtYW4vbGlzdGluZm8vcnRjd2ViDQo+Pg0KPg0KDQo= --_000_7594FB04B1934943A5C02806D1A2204B348EA2ECESESSMB209erics_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTQgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 Q2FsaWJyaTsNCglwYW5vc2UtMToyIDE1IDUgMiAyIDIgNCAzIDIgNDt9DQpAZm9udC1mYWNlDQoJ e2ZvbnQtZmFtaWx5OlRhaG9tYTsNCglwYW5vc2UtMToyIDExIDYgNCAzIDUgNCA0IDIgNDt9DQov KiBTdHlsZSBEZWZpbml0aW9ucyAqLw0KcC5Nc29Ob3JtYWwsIGxpLk1zb05vcm1hbCwgZGl2Lk1z b05vcm1hbA0KCXttYXJnaW46MGNtOw0KCW1hcmdpbi1ib3R0b206LjAwMDFwdDsNCglmb250LXNp emU6MTIuMHB0Ow0KCWZvbnQtZmFtaWx5OiJUaW1lcyBOZXcgUm9tYW4iLCJzZXJpZiI7fQ0KYTps aW5rLCBzcGFuLk1zb0h5cGVybGluaw0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6 Ymx1ZTsNCgl0ZXh0LWRlY29yYXRpb246dW5kZXJsaW5lO30NCmE6dmlzaXRlZCwgc3Bhbi5Nc29I eXBlcmxpbmtGb2xsb3dlZA0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6cHVycGxl Ow0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0Kc3Bhbi5ob2VuemINCgl7bXNvLXN0eWxl LW5hbWU6aG9lbnpiO30NCnNwYW4uRW1haWxTdHlsZTE4DQoJe21zby1zdHlsZS10eXBlOnBlcnNv bmFsLXJlcGx5Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIiwic2Fucy1zZXJpZiI7DQoJY29sb3I6 IzFGNDk3RDt9DQouTXNvQ2hwRGVmYXVsdA0KCXttc28tc3R5bGUtdHlwZTpleHBvcnQtb25seTsN Cglmb250LWZhbWlseToiQ2FsaWJyaSIsInNhbnMtc2VyaWYiOw0KCW1zby1mYXJlYXN0LWxhbmd1 YWdlOkVOLVVTO30NCkBwYWdlIFdvcmRTZWN0aW9uMQ0KCXtzaXplOjYxMi4wcHQgNzkyLjBwdDsN CgltYXJnaW46NzAuODVwdCAyLjBjbSA3MC44NXB0IDIuMGNtO30NCmRpdi5Xb3JkU2VjdGlvbjEN Cgl7cGFnZTpXb3JkU2VjdGlvbjE7fQ0KLS0+PC9zdHlsZT48IS0tW2lmIGd0ZSBtc28gOV0+PHht bD4NCjxvOnNoYXBlZGVmYXVsdHMgdjpleHQ9ImVkaXQiIHNwaWRtYXg9IjEwMjYiIC8+DQo8L3ht bD48IVtlbmRpZl0tLT48IS0tW2lmIGd0ZSBtc28gOV0+PHhtbD4NCjxvOnNoYXBlbGF5b3V0IHY6 ZXh0PSJlZGl0Ij4NCjxvOmlkbWFwIHY6ZXh0PSJlZGl0IiBkYXRhPSIxIiAvPg0KPC9vOnNoYXBl bGF5b3V0PjwveG1sPjwhW2VuZGlmXS0tPg0KPC9oZWFkPg0KPGJvZHkgbGFuZz0iRkkiIGxpbms9 ImJsdWUiIHZsaW5rPSJwdXJwbGUiPg0KPGRpdiBjbGFzcz0iV29yZFNlY3Rpb24xIj4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5 OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdE Ij5IaSw8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBz dHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZx dW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8L286cD48L3Nw YW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4w cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7 O2NvbG9yOiMxRjQ5N0QiPkNvcnJlY3QuPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1 b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPjxv OnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxh bmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxp YnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+RnJvbSBhIFNU VU4gcHJvdG9jb2wgcGVyc3BlY3RpdmUsIGNvbnNlbnQgcmVxdWVzdHMgYXJlIG5vcm1hbCBTVFVO IGNvbm5lY3Rpdml0eSBjaGVja3MuPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQt ZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjoj MUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6 JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0Qi PlNvLCB0aGUgYnJvd3NlciB3aWxsIGJlIGEg4oCcc2VydmVy4oCdIGluIHRoZSBzZW5zZSB0aGF0 IGl0IHJlY2VpdmVzIGFuZCBwcm9jZXNzZXMgU1RVTiBjb25uZWN0aXZpdHkgY2hlY2tzLCBidXQg aXQgd2lsbCBub3QgYmUgYSDigJxTVFVOIHNlcnZlcuKAnSA6KTxvOnA+PC9vOnA+PC9zcGFuPjwv cD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1z aXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2Vy aWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTEu MHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90 Oztjb2xvcjojMUY0OTdEIj5SZWdhcmRzLDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtm b250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29s b3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFt aWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0 OTdEIj5DaHJpc3RlcjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTom cXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+ PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGI+PHNw YW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90 O1RhaG9tYSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij5Gcm9tOjwvc3Bhbj48L2I+PHNw YW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90 O1RhaG9tYSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij4gRXJpYyBSZXNjb3JsYSBbbWFp bHRvOmVrckBydGZtLmNvbV0NCjxicj4NCjxiPlNlbnQ6PC9iPiA1LiBlbG9rdXV0YSAyMDE1IDIw OjIyPGJyPg0KPGI+VG86PC9iPiBTdGVwaGVuIEZhcnJlbGw8YnI+DQo8Yj5DYzo8L2I+IGRyYWZ0 LWlldGYtcnRjd2ViLXN0dW4tY29uc2VudC1mcmVzaG5lc3NAaWV0Zi5vcmc7IHJ0Y3dlYi1jaGFp cnNAaWV0Zi5vcmc7IGRyYWZ0LWlldGYtcnRjd2ViLXN0dW4tY29uc2VudC1mcmVzaG5lc3Muc2hl cGhlcmRAaWV0Zi5vcmc7IHJ0Y3dlYkBpZXRmLm9yZzsgVGhlIElFU0c7IENocmlzdGVyIEhvbG1i ZXJnOyBkcmFmdC1pZXRmLXJ0Y3dlYi1zdHVuLWNvbnNlbnQtZnJlc2huZXNzLmFkQGlldGYub3Jn PGJyPg0KPGI+U3ViamVjdDo8L2I+IFJlOiBbcnRjd2ViXSBTdGVwaGVuIEZhcnJlbGwncyBEaXNj dXNzIG9uIGRyYWZ0LWlldGYtcnRjd2ViLXN0dW4tY29uc2VudC1mcmVzaG5lc3MtMTU6ICh3aXRo IERJU0NVU1MgYW5kIENPTU1FTlQpPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+VGhpcyBmcmVzaG5lc3Mgc3R1ZmYgaXMgYWxzbyBhYm91dCAjMy4gTmFtZWx5LCBpdCdzIGFi b3V0IHRoZSBlbmRwb2ludHM8bzpwPjwvbzpwPjwvcD4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj5kb2luZyBjb250aW51YWwgU1RVTiBjb25uZWN0aXZpdHkgY2hlY2tzIGJldHdlZW4gZWFj aCBvdGhlci48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+LUVrcjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ PG86cD4mbmJzcDs8L286cD48L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+T24gV2Vk LCBBdWcgNSwgMjAxNSBhdCAxMDoxOSBBTSwgU3RlcGhlbiBGYXJyZWxsICZsdDs8YSBocmVmPSJt YWlsdG86c3RlcGhlbi5mYXJyZWxsQGNzLnRjZC5pZSIgdGFyZ2V0PSJfYmxhbmsiPnN0ZXBoZW4u ZmFycmVsbEBjcy50Y2QuaWU8L2E+Jmd0OyB3cm90ZTo8bzpwPjwvbzpwPjwvcD4NCjxkaXY+DQo8 ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1ib3R0b206MTIuMHB0Ij48 YnI+DQo8YnI+DQpPbiAwNS8wOC8xNSAxODowMSwgRXJpYyBSZXNjb3JsYSB3cm90ZTo8YnI+DQom Z3Q7IE9uIFdlZCwgQXVnIDUsIDIwMTUgYXQgOTo1NSBBTSwgU3RlcGhlbiBGYXJyZWxsICZsdDs8 YSBocmVmPSJtYWlsdG86c3RlcGhlbi5mYXJyZWxsQGNzLnRjZC5pZSI+c3RlcGhlbi5mYXJyZWxs QGNzLnRjZC5pZTwvYT4mZ3Q7PGJyPg0KJmd0OyB3cm90ZTo8YnI+DQomZ3Q7PGJyPg0KJmd0OyZn dDs8YnI+DQomZ3Q7Jmd0OyBIaXlhLDxicj4NCiZndDsmZ3Q7PGJyPg0KJmd0OyZndDsgT24gMDUv MDgvMTUgMTQ6MjIsIENocmlzdGVyIEhvbG1iZXJnIHdyb3RlOjxicj4NCiZndDsmZ3Q7Jmd0OyBI aSBTdGVwaGVuLDxicj4NCiZndDsmZ3Q7Jmd0Ozxicj4NCiZndDsmZ3Q7Jmd0OyZndDsgKDIpIFdl YlJUQyBkb2VzIG5vdCByZXF1aXJlIFNUVU4gb3IgVFVSTiBzZXJ2ZXJzIGZvciBzb21lIGNhbGxz LDxicj4NCiZndDsmZ3Q7Jmd0OyZndDsgZXZlbiBpZiBpdCBkb2VzIGZvciBtYW55LiBXaHkgaXMg aXQgb2sgdG8gcmVxdWlyZSBzdWNoIGEgc2VydmVyIGJlPGJyPg0KJmd0OyZndDsmZ3Q7Jmd0OyBw cmVzZW50IGluIGFsbCBjYWxscyAod2hpY2ggSSB0aGluayB0aGlzIG1lYW5zKSBlc3BjaWFsbHkg d2hlbiB0aGF0PGJyPg0KJmd0OyZndDsmZ3Q7Jmd0OyBtZWFucyBleHBvc2luZyBhZGRpdGlvbmFs IG1ldGEtZGF0YSAoY2FsbGluZyBwYXJ0aWVzIGluIGEgY2FzZTxicj4NCiZndDsmZ3Q7Jmd0OyZn dDsgd2hlcmUgdGhlIHNlcnZlcnMgd2VyZW4ndCBuZWVkZWQgYW5kIGNhbGwgZHVyYXRpb24gaW4g YWxsIGNhc2VzKSB0bzxicj4NCiZndDsmZ3Q7Jmd0OyZndDsgdGhvc2Ugc2VydmVycyB3aGVuIHRo YXQgaXMgbm90IGFsd2F5cyBuZWNlc3Nhcnk/PGJyPg0KJmd0OyZndDsmZ3Q7PGJyPg0KJmd0OyZn dDsmZ3Q7IENvdWxkIHlvdSBwbGVhc2UgcmVmZXIgdG8gdGhlIHRleHQgd2hpY2ggeW91IHRoaW5r IG1hbmRhdGVzIFNUVU4gb3I8YnI+DQomZ3Q7Jmd0OyZndDsgVFVSTiBzZXJ2ZXJzPzxicj4NCiZn dDsmZ3Q7PGJyPg0KJmd0OyZndDsgU3VyZSwgSSB0aGluayB0aGVyZSB3ZXJlIGEgY291cGxlIG9m IHBsYWNlcywgYnV0IEknZCBoYXZlIHRvPGJyPg0KJmd0OyZndDsgdHJhY2sgJ2VtIGRvd24uIEkn bGwgdHJ5IHVwZGF0ZSB0aGUgYmFsbG90IHdpdGggdGhhdCBpZiBpdDxicj4NCiZndDsmZ3Q7IHR1 cm5zIG91dCB0byBiZSBuZWVkZWQuIChCZSB0b21vcnJvdyBiZWZvcmUgSSBnZXQgdG8gdGhhdCw8 YnI+DQomZ3Q7Jmd0OyBzb3JyeS4pPGJyPg0KJmd0OyZndDs8YnI+DQomZ3Q7Jmd0OyZndDs8YnI+ DQomZ3Q7Jmd0OyZndDsgSWYgdGhlcmUgYXJlIG5vIE5BVHMsIHRoZSBTVFVOIHJlcXVlc3RzIGNh biBiZSBzZW50IGJldHdlZW4gdGhlPGJyPg0KJmd0OyZndDsmZ3Q7IGVuZHBvaW50cywgd2l0aG91 dCBTVFVOIG9yIFRVUk4gc2VydmVycy48YnI+DQomZ3Q7Jmd0Ozxicj4NCiZndDsmZ3Q7IFJlYWxs eSAtIHNvIGJyb3dzZXJzIHdpbGwgYmUgYWJsZSB0byBhY3QgbGlrZSBhIFNUVU4gc2VydmVyIG9y PGJyPg0KJmd0OyZndDsgc29tZXRoaW5nPyBJIGRpZG4ndCBrbm93IHRoYXQuIFdoZXJlJ3MgdGhh dCBkZXNjcmliZWQ/PGJyPg0KJmd0Ozxicj4NCiZndDs8YnI+DQomZ3Q7IElDRSB1c2VzIFNUVU4g aW4gdGhyZWUgd2F5czo8YnI+DQomZ3Q7PGJyPg0KJmd0OyAxLiBGb3IgYWRkcmVzcyBkaXNjb3Zl cnk8YnI+DQomZ3Q7IDIuIFRvIHRhbGsgdG8gVFVSTiBzZXJ2ZXJzIChUVVJOIGlzIGJhc2VkIG9u IFNUVU4pPGJyPg0KJmd0OyAzLiBGb3IgSUNFIGNvbm5lY3Rpdml0eSBjaGVja3MuPGJyPg0KJmd0 Ozxicj4NCiZndDsgQ2hyaXN0ZXIgaXMgcmVmZXJyaW5nIHRvICMzLjxvOnA+PC9vOnA+PC9wPg0K PC9kaXY+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPk9rLCBhbmQgd2hhdCBoYXBwZW5z IHdpdGggdGhpcyBmcmVzaG5lc3Mgc3R1ZmYgaW4gdGhhdDxicj4NCnNjZW5hcmlvPyAoQXBvbG9n aWVzIGlmIGl0cyBpbiB0aGlzIG9yIHNvbWUgb3RoZXIgZHJhZnQ8YnI+DQphbmQgSSBtaXNzZWQg aXQpPGJyPg0KPHNwYW4gc3R5bGU9ImNvbG9yOiM4ODg4ODgiPjxicj4NCjxzcGFuIGNsYXNzPSJo b2VuemIiPlM8L3NwYW4+PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPGRpdj4NCjxkaXY+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj48YnI+DQomZ3Q7PGJyPg0KJmd0OyAtRWtyPGJyPg0KJmd0Ozxicj4N CiZndDs8YnI+DQomZ3Q7Jmd0OyBTLjxicj4NCiZndDsmZ3Q7PGJyPg0KJmd0OyZndDs8YnI+DQom Z3Q7Jmd0OyZndDs8YnI+DQomZ3Q7Jmd0OyZndDsgUmVnYXJkcyw8YnI+DQomZ3Q7Jmd0OyZndDs8 YnI+DQomZ3Q7Jmd0OyZndDsgQ2hyaXN0ZXI8YnI+DQomZ3Q7Jmd0OyZndDs8YnI+DQomZ3Q7Jmd0 Ozxicj4NCiZndDsmZ3Q7IF9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fPGJyPg0KJmd0OyZndDsgcnRjd2ViIG1haWxpbmcgbGlzdDxicj4NCiZndDsmZ3Q7IDxh IGhyZWY9Im1haWx0bzpydGN3ZWJAaWV0Zi5vcmciPnJ0Y3dlYkBpZXRmLm9yZzwvYT48YnI+DQom Z3Q7Jmd0OyA8YSBocmVmPSJodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL3J0 Y3dlYiIgdGFyZ2V0PSJfYmxhbmsiPmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGlu Zm8vcnRjd2ViPC9hPjxicj4NCiZndDsmZ3Q7PGJyPg0KJmd0OzxvOnA+PC9vOnA+PC9wPg0KPC9k aXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286 cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvYm9keT4NCjwvaHRtbD4N Cg== --_000_7594FB04B1934943A5C02806D1A2204B348EA2ECESESSMB209erics_-- From nobody Wed Aug 5 23:45:02 2015 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 372491A1BAC for ; Wed, 5 Aug 2015 23:45:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.909 X-Spam-Level: X-Spam-Status: No, score=-6.909 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, 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 ksGa7L9wycgt for ; Wed, 5 Aug 2015 23:44:59 -0700 (PDT) Received: from smtp-fr.alcatel-lucent.com (fr-hpida-esg-02.alcatel-lucent.com [135.245.210.21]) (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 F3F251A1B9C for ; Wed, 5 Aug 2015 23:44:58 -0700 (PDT) Received: from fr712usmtp2.zeu.alcatel-lucent.com (unknown [135.239.2.42]) by Websense Email Security Gateway with ESMTPS id EC838230FAF9A; Thu, 6 Aug 2015 06:44:55 +0000 (GMT) Received: from FR712WXCHHUB03.zeu.alcatel-lucent.com (fr712wxchhub03.zeu.alcatel-lucent.com [135.239.2.74]) by fr712usmtp2.zeu.alcatel-lucent.com (GMO) with ESMTP id t766itei004405 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Thu, 6 Aug 2015 08:44:56 +0200 Received: from FR711WXCHMBA03.zeu.alcatel-lucent.com ([169.254.3.123]) by FR712WXCHHUB03.zeu.alcatel-lucent.com ([135.239.2.74]) with mapi id 14.03.0195.001; Thu, 6 Aug 2015 08:44:56 +0200 From: "Schwarz, Albrecht (Albrecht)" To: "Asveren, Tolga" , Roman Shpount , "Rauschenbach, Uwe (Nokia - DE/Munich)" Thread-Topic: [rtcweb] What the gateway draft should say about mux/non-mux Thread-Index: AQHQy78uKxT/0f1cqU+61qeHi7bRGJ31yJ8AgAABlICAAAJzgIAAAVWAgAABfoCABA9LcIAAIuEAgAL8GACAAIDGAIAAFdwAgAD3FfA= Date: Thu, 6 Aug 2015 06:44:54 +0000 Message-ID: <786615F3A85DF44AA2A76164A71FE1AC7ADB9E25@FR711WXCHMBA03.zeu.alcatel-lucent.com> References: <7594FB04B1934943A5C02806D1A2204B348E29DA@ESESSMB209.ericsson.se> <67196805-ED4E-49EA-83AA-3F4C37B5BC50@gmail.com> <7594FB04B1934943A5C02806D1A2204B348E2D52@ESESSMB209.ericsson.se> <56C2F665D49E0341B9DF5938005ACDF8196FF3ED@DEMUMBX005.nsn-intra.net> <56C2F665D49E0341B9DF5938005ACDF8196FF450@DEMUMBX005.nsn-intra.net> <786615F3A85DF44AA2A76164A71FE1AC7ADB690D@FR711WXCHMBA03.zeu.alcatel-lucent.com> <56C2F665D49E0341B9DF5938005ACDF81970EDC1@DEMUMBX005.nsn-intra.net> In-Reply-To: Accept-Language: de-DE, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [135.239.27.38] Content-Type: multipart/alternative; boundary="_000_786615F3A85DF44AA2A76164A71FE1AC7ADB9E25FR711WXCHMBA03z_" MIME-Version: 1.0 Archived-At: Cc: "" Subject: Re: [rtcweb] What the gateway draft should say about mux/non-mux X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 06 Aug 2015 06:45:02 -0000 --_000_786615F3A85DF44AA2A76164A71FE1AC7ADB9E25FR711WXCHMBA03z_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 VGhlIGNvbmNlcm5lZCAzR1BQIFdlYlJUQyBnYXRld2F5ICgzR1BQIDIzLjMzNC8yOS4zMzQpIHN1 cHBvcnRzIGFscmVhZHkgUlRQL1JUQ1AgdHJhbnNwb3J0IG11bHRpcGxleGluZyAoc2luY2UgM0dQ UCBSZWxlYXNlIDEyKSwgaS5lLiBzaG91bGQgbm90IGJlIHRoZSBsaW1pdGluZyBmYWN0b3IgaW4g dGhpcyBkaXNjdXNzaW9uLg0KRm9yIG9uZXMgaW50ZXJlc3RlZCBpbiB0aGUgUlRDUCBwb3J0IGFs bG9jYXRpb24gcnVsZXMsIHNlZSBILjI0OC41NzoNCmh0dHBzOi8vd3d3Lml0dS5pbnQvcmVjL2Rv bG9naW5fcHViLmFzcD9sYW5nPWUmaWQ9VC1SRUMtSC4yNDguNTctMjAxNDEwLUkhIVBERi1FJnR5 cGU9aXRlbXMNCkNsYXVzZSA3IGRlc2NyaWJlcyBSVFAvUlRDUCB0cmFuc3BvcnQgbXVsdGlwbGV4 aW5nLiBJVFUtVCBILjI0OC41NyBpcyBhbHJlYWR5IHN1cHBvcnRlZCBieSAzR1BQIDI5LjMzNC4N Cg0KVGhlIHJhdGlvbmFsZSBiZWhpbmQgdGhlIOKAnG9wdGlvbmFsIHRhZ2dpbmfigJ0gYnkgMjMu MjI4IGlzIGEgdGhpcmQgcmVhc29uLCBiZXlvbmQNCj4xLiBVc2luZyBkaWZmZXJlbnQgUU9TIHNl dHRpbmdzIGZvciBSVENQIHZzIFJUUA0KPjIuIFNlbmRpbmcgUlRDUCB0byBhIGRpZmZlcmVudCBk ZXZpY2UgZnJvbSBSVFANCg0KRG9u4oCZdCB3YW50IHRvIGdvIGluIHRoZSAzR1BQIHNwZWNpZmlj IGRldGFpbHMsIGJ1dCBpdCBoYXMgbm90aGluZyB0byBkbyB3aXRoIHRoZSAzR1BQIFVFLWVtYmVk ZGVkIFdlYlJUQyBjbGllbnQgbm9yIGFueSBjb25zdHJhaW50cyBieSAzR1BQIFdlYlJUQyBnYXRl d2F5cy4NCg0KVGh1cywgYSBXZWJSVEMgZ2F0ZXdheSBNVVNUIHN1cHBvcnQgUlRQL1JUQ1AgdHJh bnNwb3J0IG11bHRpcGxleGluZyBkdWUgdG8gaXRzIHB1cnBvc2UgaW4gaW50ZXJ3b3JraW5nIHN1 cHBvcnQuDQoNClJlZ2FyZHMsDQpBbGJyZWNodA0KDQoNCkZyb206IEFzdmVyZW4sIFRvbGdhIFtt YWlsdG86dGFzdmVyZW5Ac29udXNuZXQuY29tXQ0KU2VudDogTWl0dHdvY2gsIDUuIEF1Z3VzdCAy MDE1IDE5OjQ3DQpUbzogUm9tYW4gU2hwb3VudDsgUmF1c2NoZW5iYWNoLCBVd2UgKE5va2lhIC0g REUvTXVuaWNoKQ0KQ2M6IGV4dCBFcmljIFJlc2NvcmxhOyBTY2h3YXJ6LCBBbGJyZWNodCAoQWxi cmVjaHQpOyBDaHJpc3RlciBIb2xtYmVyZzsgQmVybmFyZCBBYm9iYTsgPHJ0Y3dlYkBpZXRmLm9y Zz4NClN1YmplY3Q6IFJFOiBbcnRjd2ViXSBXaGF0IHRoZSBnYXRld2F5IGRyYWZ0IHNob3VsZCBz YXkgYWJvdXQgbXV4L25vbi1tdXgNCg0KaS0gSSBodW1ibHkgZGlzYWdyZWUgdGhhdCB1c2luZyBk aWZmZXJlbnQgUW9TIFJUQ1AvUlRQLCBlLmcuIGRpZmZlcmVudCBEaWZmU2VydiB2YWx1ZXMgLCBz aG91bGQgYmUgZGlzbWlzc2VkLg0KaWktIExldCBtZSBhbHNvIGFkZCBhbm90aGVyIHJlYXNvbiB3 aHkgbm8tcnRjcC1tdXggbWF5IGJlIG5lZWRlZDogSW1wbGVtZW50YXRpb24gZGlmZmljdWx0aWVz IGluIGNlcnRhaW4gR1dzLg0KDQpDb25zaWRlcmluZyB0aGF0IHRoZXJlIGlzIGFscmVhZHkgYSBu ZWdvdGlhdGlvbiBtZWNoYW5pc20gZm9yIHJ0Y3AtbXV4IHN1cHBvcnQsIHRoYXQgaXQgY2FuIGJl IGRlLWZhY3RvIG1hbmRhdGVkIGJ5IHRoZSBjaG9pY2Ugb2YgYnJvd3NlcnMgZm9yIEludGVybmV0 LCBJIHRoaW5rIHdoYXQgQ2hyaXN0ZXIvQWxicmVjaHQgc3VnZ2VzdGVkIGlzIHRoZSByaWdodCB3 YXkgdG8gbW92ZSBmb3J3YXJkOiBwcm92aWRlIGNsYXJpZmljYXRpb25zIGZvciB2YWd1ZSBwb2lu dHMuIEkgZG9u4oCZdCB1bmRlcnN0YW5kIHdoeSBsYWNrIG9mIGNsYXJpdHkgaW4gZXhpc3Rpbmcg c3BlY2lmaWNhdGlvbnMgc2hvdWxkIGNhdXNlIGltcG9zaW5nIHJlc3RyaWN0aW9ucy4gVGhpcyB3 b3VsZCBiZSBha2luIHRvIGRyb3BwaW5nIGEgZmVhdHVyZSBkdWUgdG8gYSBidWcuIEluIHRoaXMg Y2FzZSwgdGhlIOKAnGJ1Z+KAnSBpcyBsYWNrIG9mIGNsYXJpdHkgaW4gbm9ybWF0aXZlIHNwZWNp ZmljYXRpb25zIGFuZCBpdCBjYW4gYmUgYWRkcmVzc2VkIGJ5IGZ1cnRoZXIgc3BlY2lmaWNhdGlv bi4NCg0KVGhhbmtzLA0KVG9sZ2ENCg0KRnJvbTogUm9tYW4gU2hwb3VudCBbbWFpbHRvOnJvbWFu QHRlbHVyaXguY29tXQ0KU2VudDogV2VkbmVzZGF5LCBBdWd1c3QgMDUsIDIwMTUgMTI6MjkgUE0N ClRvOiBSYXVzY2hlbmJhY2gsIFV3ZSAoTm9raWEgLSBERS9NdW5pY2gpIDx1d2UucmF1c2NoZW5i YWNoQG5va2lhLmNvbTxtYWlsdG86dXdlLnJhdXNjaGVuYmFjaEBub2tpYS5jb20+Pg0KQ2M6IGV4 dCBFcmljIFJlc2NvcmxhIDxla3JAcnRmbS5jb208bWFpbHRvOmVrckBydGZtLmNvbT4+OyBTY2h3 YXJ6LCBBbGJyZWNodCAoQWxicmVjaHQpIDxhbGJyZWNodC5zY2h3YXJ6QGFsY2F0ZWwtbHVjZW50 LmNvbTxtYWlsdG86YWxicmVjaHQuc2Nod2FyekBhbGNhdGVsLWx1Y2VudC5jb20+PjsgQXN2ZXJl biwgVG9sZ2EgPHRhc3ZlcmVuQHNvbnVzbmV0LmNvbTxtYWlsdG86dGFzdmVyZW5Ac29udXNuZXQu Y29tPj47IENocmlzdGVyIEhvbG1iZXJnIDxjaHJpc3Rlci5ob2xtYmVyZ0Blcmljc3Nvbi5jb208 bWFpbHRvOmNocmlzdGVyLmhvbG1iZXJnQGVyaWNzc29uLmNvbT4+OyBCZXJuYXJkIEFib2JhIDxi ZXJuYXJkLmFib2JhQGdtYWlsLmNvbTxtYWlsdG86YmVybmFyZC5hYm9iYUBnbWFpbC5jb20+Pjsg PHJ0Y3dlYkBpZXRmLm9yZzxtYWlsdG86cnRjd2ViQGlldGYub3JnPj4gPHJ0Y3dlYkBpZXRmLm9y ZzxtYWlsdG86cnRjd2ViQGlldGYub3JnPj4NClN1YmplY3Q6IFJlOiBbcnRjd2ViXSBXaGF0IHRo ZSBnYXRld2F5IGRyYWZ0IHNob3VsZCBzYXkgYWJvdXQgbXV4L25vbi1tdXgNCg0KT24gV2VkLCBB dWcgNSwgMjAxNSBhdCA0OjQ3IEFNLCBSYXVzY2hlbmJhY2gsIFV3ZSAoTm9raWEgLSBERS9NdW5p Y2gpIDx1d2UucmF1c2NoZW5iYWNoQG5va2lhLmNvbTxtYWlsdG86dXdlLnJhdXNjaGVuYmFjaEBu b2tpYS5jb20+PiB3cm90ZToNCk1lZGlhIGdhdGV3YXkgaW1wbGVtZW50YXRpb25zIGFjY29yZGlu ZyB0byAzR1BQIFRTIDIzLjIyOCBtYXkgbm90IHN1cHBvcnQgcnRjcC1tdXgsIGFzIHJ0Y3AtbXV4 IGlzIG9wdGlvbmFsIHRoZXJlLg0KU28gaWYgd2UgZHJvcCBub24tbXV4IHN1cHBvcnQgZnJvbSB3 ZWIgYnJvd3NlcnMsIHRob3NlIG1lZGlhIGdhdGV3YXlzIHRoYXQgaGF2ZSBub3QgaW1wbGVtZW50 ZWQgcnRjcC1tdXggd2lsbCBzdG9wIGludGVyb3BlcmF0aW5nLg0KDQoNCkZpcnN0IG9mIGFsbCwg ZG8geW91IGtub3cgb2YgYW55IFdlYlJUQyB0byBJTVMgZ2F0ZXdheXMgdGhhdCBkbyBub3QgaW1w bGVtZW50IHJ0Y3AtbXV4IG9uIHRoZSBXZWJSVEMgc2lkZT8gSSBzdHJvbmdseSBzdXNwZWN0IHRo ZXJlIGFyZSBub25lLg0KDQpTZWNvbmQsIHRoZSBvbmx5IHJlYXNvbnMgbm90IHRvIHVzZSBydGNw LW11eCB0aGF0IEkgY2FuIHRoaW5rIG9mIGFyZSB0aGUgZm9sbG93aW5nOg0KDQoxLiBVc2luZyBk aWZmZXJlbnQgUU9TIHNldHRpbmdzIGZvciBSVENQIHZzIFJUUA0KMi4gU2VuZGluZyBSVENQIHRv IGEgZGlmZmVyZW50IGRldmljZSBmcm9tIFJUUA0KDQpJIGRvIG5vdCB0aGluayB0aGUgZmlyc3Qg dXNlIGNhc2Ugd2FycmFudHMgbWFraW5nIHJ0Y3AtbXV4IG9wdGlvbmFsLCBzaW5jZSwgcHJhY3Rp Y2FsbHkgbm8gb25lIGRvZXMgdGhpcy4NClNlY29uZCB1c2UgY2FzZSBpcyBhbHNvIGZhaXJseSBt YXJnaW5hbC4gUGx1cyBpdCBjYW4gYmUgaGFuZGxlZCBieSB0aGUgZ2F0ZXdheSB3aGljaCBjYW4g c2VuZCBSVENQIHRvIG9uZSBkZXZpY2UgYW5kIFJUUCB0byBhbm90aGVyLg0KDQpTbywgdW5sZXNz IHNvbWVvbmUgY2FuIGNvbWUgdXAgd2l0aCBhIHVzZSBjYXNlIHdoeSBSVFAgYW5kIFJUQ1Agc2hv dWxkIHVzZSBkaWZmZXJlbnQgdHJhbnNwb3J0cywgSSB0aGluayBydGNwLW11eCBzaG91bGQgYmUg bWFuZGF0b3J5Lg0KDQpSZWdhcmRzLA0KX19fX19fX19fX19fX18NClJvbWFuIFNocG91bnQNCg== --_000_786615F3A85DF44AA2A76164A71FE1AC7ADB9E25FR711WXCHMBA03z_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTIgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 IkNhbWJyaWEgTWF0aCI7DQoJcGFub3NlLTE6MiA0IDUgMyA1IDQgNiAzIDIgNDt9DQpAZm9udC1m YWNlDQoJe2ZvbnQtZmFtaWx5OkNhbGlicmk7DQoJcGFub3NlLTE6MiAxNSA1IDIgMiAyIDQgMyAy IDQ7fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseTpUYWhvbWE7DQoJcGFub3NlLTE6MiAxMSA2 IDQgMyA1IDQgNCAyIDQ7fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseTpDb25zb2xhczsNCglw YW5vc2UtMToyIDExIDYgOSAyIDIgNCAzIDIgNDt9DQovKiBTdHlsZSBEZWZpbml0aW9ucyAqLw0K cC5Nc29Ob3JtYWwsIGxpLk1zb05vcm1hbCwgZGl2Lk1zb05vcm1hbA0KCXttYXJnaW46MGNtOw0K CW1hcmdpbi1ib3R0b206LjAwMDFwdDsNCglmb250LXNpemU6MTIuMHB0Ow0KCWZvbnQtZmFtaWx5 OiJUaW1lcyBOZXcgUm9tYW4iLCJzZXJpZiI7fQ0KYTpsaW5rLCBzcGFuLk1zb0h5cGVybGluaw0K CXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6Ymx1ZTsNCgl0ZXh0LWRlY29yYXRpb246 dW5kZXJsaW5lO30NCmE6dmlzaXRlZCwgc3Bhbi5Nc29IeXBlcmxpbmtGb2xsb3dlZA0KCXttc28t c3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6cHVycGxlOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRl cmxpbmU7fQ0KcC5Nc29BY2V0YXRlLCBsaS5Nc29BY2V0YXRlLCBkaXYuTXNvQWNldGF0ZQ0KCXtt c28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJbXNvLXN0eWxlLWxpbms6IkJhbGxvb24gVGV4dCBDaGFy IjsNCgltYXJnaW46MGNtOw0KCW1hcmdpbi1ib3R0b206LjAwMDFwdDsNCglmb250LXNpemU6OC4w cHQ7DQoJZm9udC1mYW1pbHk6IlRhaG9tYSIsInNhbnMtc2VyaWYiO30NCnNwYW4uRW1haWxTdHls ZTE3DQoJe21zby1zdHlsZS10eXBlOnBlcnNvbmFsOw0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIiwi c2Fucy1zZXJpZiI7DQoJY29sb3I6IzFGNDk3RDt9DQpzcGFuLkJhbGxvb25UZXh0Q2hhcg0KCXtt c28tc3R5bGUtbmFtZToiQmFsbG9vbiBUZXh0IENoYXIiOw0KCW1zby1zdHlsZS1wcmlvcml0eTo5 OTsNCgltc28tc3R5bGUtbGluazoiQmFsbG9vbiBUZXh0IjsNCglmb250LWZhbWlseToiVGFob21h Iiwic2Fucy1zZXJpZiI7fQ0Kc3Bhbi5FbWFpbFN0eWxlMjANCgl7bXNvLXN0eWxlLXR5cGU6cGVy c29uYWwtcmVwbHk7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLCJzYW5zLXNlcmlmIjsNCgljb2xv cjojMUY0OTdEO30NCi5Nc29DaHBEZWZhdWx0DQoJe21zby1zdHlsZS10eXBlOmV4cG9ydC1vbmx5 Ow0KCWZvbnQtc2l6ZToxMC4wcHQ7fQ0KQHBhZ2UgV29yZFNlY3Rpb24xDQoJe3NpemU6NjEyLjBw dCA3OTIuMHB0Ow0KCW1hcmdpbjo3Mi4wcHQgNzIuMHB0IDcyLjBwdCA3Mi4wcHQ7fQ0KZGl2Lldv cmRTZWN0aW9uMQ0KCXtwYWdlOldvcmRTZWN0aW9uMTt9DQotLT48L3N0eWxlPjwhLS1baWYgZ3Rl IG1zbyA5XT48eG1sPg0KPG86c2hhcGVkZWZhdWx0cyB2OmV4dD0iZWRpdCIgc3BpZG1heD0iMTAy NiIgLz4NCjwveG1sPjwhW2VuZGlmXS0tPjwhLS1baWYgZ3RlIG1zbyA5XT48eG1sPg0KPG86c2hh cGVsYXlvdXQgdjpleHQ9ImVkaXQiPg0KPG86aWRtYXAgdjpleHQ9ImVkaXQiIGRhdGE9IjEiIC8+ DQo8L286c2hhcGVsYXlvdXQ+PC94bWw+PCFbZW5kaWZdLS0+DQo8L2hlYWQ+DQo8Ym9keSBsYW5n PSJFTi1HQiIgbGluaz0iYmx1ZSIgdmxpbms9InB1cnBsZSI+DQo8ZGl2IGNsYXNzPSJXb3JkU2Vj dGlvbjEiPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4w cHQ7Zm9udC1mYW1pbHk6Q29uc29sYXM7Y29sb3I6IzFGNDk3RCI+VGhlIGNvbmNlcm5lZCAzR1BQ IFdlYlJUQyBnYXRld2F5ICgzR1BQIDIzLjMzNC8yOS4zMzQpIHN1cHBvcnRzIGFscmVhZHkgUlRQ L1JUQ1AgdHJhbnNwb3J0IG11bHRpcGxleGluZyAoc2luY2UgM0dQUCBSZWxlYXNlIDEyKSwgaS5l LiBzaG91bGQgbm90IGJlIHRoZSBsaW1pdGluZyBmYWN0b3IgaW4NCiB0aGlzIGRpc2N1c3Npb24u IDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxl PSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OkNvbnNvbGFzO2NvbG9yOiMxRjQ5N0QiPkZv ciBvbmVzIGludGVyZXN0ZWQgaW4gdGhlIFJUQ1AgcG9ydCBhbGxvY2F0aW9uIHJ1bGVzLCBzZWUg SC4yNDguNTc6PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNw YW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6Q29uc29sYXM7Y29sb3I6IzFG NDk3RCI+PGEgaHJlZj0iaHR0cHM6Ly93d3cuaXR1LmludC9yZWMvZG9sb2dpbl9wdWIuYXNwP2xh bmc9ZSZhbXA7aWQ9VC1SRUMtSC4yNDguNTctMjAxNDEwLUkhIVBERi1FJmFtcDt0eXBlPWl0ZW1z Ij5odHRwczovL3d3dy5pdHUuaW50L3JlYy9kb2xvZ2luX3B1Yi5hc3A/bGFuZz1lJmFtcDtpZD1U LVJFQy1ILjI0OC41Ny0yMDE0MTAtSSEhUERGLUUmYW1wO3R5cGU9aXRlbXM8L2E+DQo8bzpwPjwv bzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1z aXplOjExLjBwdDtmb250LWZhbWlseTpDb25zb2xhcztjb2xvcjojMUY0OTdEIj5DbGF1c2UgNyBk ZXNjcmliZXMgUlRQL1JUQ1AgdHJhbnNwb3J0IG11bHRpcGxleGluZy4gSVRVLVQgSC4yNDguNTcg aXMgYWxyZWFkeSBzdXBwb3J0ZWQgYnkgM0dQUCAyOS4zMzQuPG86cD48L286cD48L3NwYW4+PC9w Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9u dC1mYW1pbHk6Q29uc29sYXM7Y29sb3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+ PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7 Zm9udC1mYW1pbHk6Q29uc29sYXM7Y29sb3I6IzFGNDk3RCI+VGhlIHJhdGlvbmFsZSBiZWhpbmQg dGhlIOKAnG9wdGlvbmFsIHRhZ2dpbmfigJ0gYnkgMjMuMjI4IGlzIGEgdGhpcmQgcmVhc29uLCBi ZXlvbmQ8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBs YW5nPSJFTi1VUyI+Jmd0OzEuIFVzaW5nIGRpZmZlcmVudCBRT1Mgc2V0dGluZ3MgZm9yIFJUQ1Ag dnMgUlRQPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4g bGFuZz0iRU4tVVMiPiZndDsyLiBTZW5kaW5nIFJUQ1AgdG8gYSBkaWZmZXJlbnQgZGV2aWNlIGZy b20gUlRQPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4g bGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OkNvbnNvbGFz O2NvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OkNvbnNv bGFzO2NvbG9yOiMxRjQ5N0QiPkRvbuKAmXQgd2FudCB0byBnbyBpbiB0aGUgM0dQUCBzcGVjaWZp YyBkZXRhaWxzLCBidXQgaXQgaGFzIG5vdGhpbmcgdG8gZG8gd2l0aCB0aGUgM0dQUCBVRS1lbWJl ZGRlZCBXZWJSVEMgY2xpZW50IG5vciBhbnkgY29uc3RyYWludHMgYnkgM0dQUCBXZWJSVEMgZ2F0 ZXdheXMuPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4g c3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6Q29uc29sYXM7Y29sb3I6IzFGNDk3 RCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNw YW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6Q29uc29sYXM7Y29sb3I6IzFG NDk3RCI+VGh1cywgYSBXZWJSVEMgZ2F0ZXdheSBNVVNUIHN1cHBvcnQgUlRQL1JUQ1AgdHJhbnNw b3J0IG11bHRpcGxleGluZyBkdWUgdG8gaXRzIHB1cnBvc2UgaW4gaW50ZXJ3b3JraW5nIHN1cHBv cnQuPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5 bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6Q29uc29sYXM7Y29sb3I6IzFGNDk3RCI+ PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4g c3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6Q29uc29sYXM7Y29sb3I6IzFGNDk3 RCI+UmVnYXJkcyw8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48 c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTpDb25zb2xhcztjb2xvcjoj MUY0OTdEIj5BbGJyZWNodDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWls eTpDb25zb2xhcztjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZh bWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFG NDk3RCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPGRpdj4NCjxkaXYgc3R5bGU9ImJv cmRlcjpub25lO2JvcmRlci10b3A6c29saWQgI0I1QzRERiAxLjBwdDtwYWRkaW5nOjMuMHB0IDBj bSAwY20gMGNtIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxiPjxzcGFuIGxhbmc9IkVOLVVTIiBz dHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtUYWhvbWEmcXVvdDssJnF1 b3Q7c2Fucy1zZXJpZiZxdW90OyI+RnJvbTo8L3NwYW4+PC9iPjxzcGFuIGxhbmc9IkVOLVVTIiBz dHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtUYWhvbWEmcXVvdDssJnF1 b3Q7c2Fucy1zZXJpZiZxdW90OyI+IEFzdmVyZW4sIFRvbGdhIFttYWlsdG86dGFzdmVyZW5Ac29u dXNuZXQuY29tXQ0KPGJyPg0KPGI+U2VudDo8L2I+IE1pdHR3b2NoLCA1LiBBdWd1c3QgMjAxNSAx OTo0Nzxicj4NCjxiPlRvOjwvYj4gUm9tYW4gU2hwb3VudDsgUmF1c2NoZW5iYWNoLCBVd2UgKE5v a2lhIC0gREUvTXVuaWNoKTxicj4NCjxiPkNjOjwvYj4gZXh0IEVyaWMgUmVzY29ybGE7IFNjaHdh cnosIEFsYnJlY2h0IChBbGJyZWNodCk7IENocmlzdGVyIEhvbG1iZXJnOyBCZXJuYXJkIEFib2Jh OyAmbHQ7cnRjd2ViQGlldGYub3JnJmd0Ozxicj4NCjxiPlN1YmplY3Q6PC9iPiBSRTogW3J0Y3dl Yl0gV2hhdCB0aGUgZ2F0ZXdheSBkcmFmdCBzaG91bGQgc2F5IGFib3V0IG11eC9ub24tbXV4PG86 cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0i RU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkm cXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj5pLSBJIGh1bWJseSBk aXNhZ3JlZSB0aGF0IHVzaW5nIGRpZmZlcmVudCBRb1MgUlRDUC9SVFAsIGUuZy4gZGlmZmVyZW50 IERpZmZTZXJ2IHZhbHVlcyAsIHNob3VsZCBiZSBkaXNtaXNzZWQuPG86cD48L286cD48L3NwYW4+ PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250 LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1z ZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj5paS0gTGV0IG1lIGFsc28gYWRkIGFub3RoZXIgcmVh c29uIHdoeSBuby1ydGNwLW11eCBtYXkgYmUgbmVlZGVkOiBJbXBsZW1lbnRhdGlvbiBkaWZmaWN1 bHRpZXMgaW4gY2VydGFpbiBHV3MuPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQt ZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjoj MUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6 JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0Qi PkNvbnNpZGVyaW5nIHRoYXQgdGhlcmUgaXMgYWxyZWFkeSBhIG5lZ290aWF0aW9uIG1lY2hhbmlz bSBmb3IgcnRjcC1tdXggc3VwcG9ydCwgdGhhdCBpdCBjYW4gYmUgZGUtZmFjdG8gbWFuZGF0ZWQg YnkgdGhlIGNob2ljZSBvZiBicm93c2VycyBmb3INCiBJbnRlcm5ldCwgSSB0aGluayB3aGF0IENo cmlzdGVyL0FsYnJlY2h0IHN1Z2dlc3RlZCBpcyB0aGUgcmlnaHQgd2F5IHRvIG1vdmUgZm9yd2Fy ZDogcHJvdmlkZSBjbGFyaWZpY2F0aW9ucyBmb3IgdmFndWUgcG9pbnRzLiBJIGRvbuKAmXQgdW5k ZXJzdGFuZCB3aHkgbGFjayBvZiBjbGFyaXR5IGluIGV4aXN0aW5nIHNwZWNpZmljYXRpb25zIHNo b3VsZCBjYXVzZSBpbXBvc2luZyByZXN0cmljdGlvbnMuIFRoaXMgd291bGQgYmUgYWtpbiB0byBk cm9wcGluZw0KIGEgZmVhdHVyZSBkdWUgdG8gYSBidWcuIEluIHRoaXMgY2FzZSwgdGhlIOKAnGJ1 Z+KAnSBpcyBsYWNrIG9mIGNsYXJpdHkgaW4gbm9ybWF0aXZlIHNwZWNpZmljYXRpb25zIGFuZCBp dCBjYW4gYmUgYWRkcmVzc2VkIGJ5IGZ1cnRoZXIgc3BlY2lmaWNhdGlvbi48bzpwPjwvbzpwPjwv c3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9 ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtz YW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwv cD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1z aXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2Vy aWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+VGhhbmtzLDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEx LjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVv dDs7Y29sb3I6IzFGNDk3RCI+VG9sZ2E8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9u dC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9y OiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxkaXYgc3R5bGU9ImJvcmRl cjpub25lO2JvcmRlci1sZWZ0OnNvbGlkIGJsdWUgMS41cHQ7cGFkZGluZzowY20gMGNtIDBjbSA0 LjBwdCI+DQo8ZGl2Pg0KPGRpdiBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLXRvcDpzb2xpZCAj RTFFMUUxIDEuMHB0O3BhZGRpbmc6My4wcHQgMGNtIDBjbSAwY20iPg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+PGI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQt ZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+RnJvbTo8 L3NwYW4+PC9iPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250 LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPiBSb21h biBTaHBvdW50IFs8YSBocmVmPSJtYWlsdG86cm9tYW5AdGVsdXJpeC5jb20iPm1haWx0bzpyb21h bkB0ZWx1cml4LmNvbTwvYT5dDQo8YnI+DQo8Yj5TZW50OjwvYj4gV2VkbmVzZGF5LCBBdWd1c3Qg MDUsIDIwMTUgMTI6MjkgUE08YnI+DQo8Yj5Ubzo8L2I+IFJhdXNjaGVuYmFjaCwgVXdlIChOb2tp YSAtIERFL011bmljaCkgJmx0OzxhIGhyZWY9Im1haWx0bzp1d2UucmF1c2NoZW5iYWNoQG5va2lh LmNvbSI+dXdlLnJhdXNjaGVuYmFjaEBub2tpYS5jb208L2E+Jmd0Ozxicj4NCjxiPkNjOjwvYj4g ZXh0IEVyaWMgUmVzY29ybGEgJmx0OzxhIGhyZWY9Im1haWx0bzpla3JAcnRmbS5jb20iPmVrckBy dGZtLmNvbTwvYT4mZ3Q7OyBTY2h3YXJ6LCBBbGJyZWNodCAoQWxicmVjaHQpICZsdDs8YSBocmVm PSJtYWlsdG86YWxicmVjaHQuc2Nod2FyekBhbGNhdGVsLWx1Y2VudC5jb20iPmFsYnJlY2h0LnNj aHdhcnpAYWxjYXRlbC1sdWNlbnQuY29tPC9hPiZndDs7IEFzdmVyZW4sIFRvbGdhICZsdDs8YSBo cmVmPSJtYWlsdG86dGFzdmVyZW5Ac29udXNuZXQuY29tIj50YXN2ZXJlbkBzb251c25ldC5jb208 L2E+Jmd0OzsNCiBDaHJpc3RlciBIb2xtYmVyZyAmbHQ7PGEgaHJlZj0ibWFpbHRvOmNocmlzdGVy LmhvbG1iZXJnQGVyaWNzc29uLmNvbSI+Y2hyaXN0ZXIuaG9sbWJlcmdAZXJpY3Nzb24uY29tPC9h PiZndDs7IEJlcm5hcmQgQWJvYmEgJmx0OzxhIGhyZWY9Im1haWx0bzpiZXJuYXJkLmFib2JhQGdt YWlsLmNvbSI+YmVybmFyZC5hYm9iYUBnbWFpbC5jb208L2E+Jmd0OzsgJmx0OzxhIGhyZWY9Im1h aWx0bzpydGN3ZWJAaWV0Zi5vcmciPnJ0Y3dlYkBpZXRmLm9yZzwvYT4mZ3Q7ICZsdDs8YSBocmVm PSJtYWlsdG86cnRjd2ViQGlldGYub3JnIj5ydGN3ZWJAaWV0Zi5vcmc8L2E+Jmd0Ozxicj4NCjxi PlN1YmplY3Q6PC9iPiBSZTogW3J0Y3dlYl0gV2hhdCB0aGUgZ2F0ZXdheSBkcmFmdCBzaG91bGQg c2F5IGFib3V0IG11eC9ub24tbXV4PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8L2Rp dj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIj48bzpwPiZuYnNwOzwv bzpwPjwvc3Bhbj48L3A+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij48c3BhbiBsYW5nPSJFTi1VUyI+T24gV2VkLCBBdWcgNSwgMjAxNSBhdCA0OjQ3IEFNLCBSYXVz Y2hlbmJhY2gsIFV3ZSAoTm9raWEgLSBERS9NdW5pY2gpICZsdDs8YSBocmVmPSJtYWlsdG86dXdl LnJhdXNjaGVuYmFjaEBub2tpYS5jb20iIHRhcmdldD0iX2JsYW5rIj51d2UucmF1c2NoZW5iYWNo QG5va2lhLmNvbTwvYT4mZ3Q7IHdyb3RlOjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxibG9ja3F1 b3RlIHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItbGVmdDpzb2xpZCAjQ0NDQ0NDIDEuMHB0O3Bh ZGRpbmc6MGNtIDBjbSAwY20gNi4wcHQ7bWFyZ2luLWxlZnQ6NC44cHQ7bWFyZ2luLXRvcDo1LjBw dDttYXJnaW4tcmlnaHQ6MGNtO21hcmdpbi1ib3R0b206NS4wcHQiPg0KPGRpdj4NCjxkaXY+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1h cmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXpl OjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtBcmlhbCZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1 b3Q7Ij5NZWRpYSBnYXRld2F5IGltcGxlbWVudGF0aW9ucyBhY2NvcmRpbmcgdG8gM0dQUCBUUyAy My4yMjg8L3NwYW4+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2Zv bnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xv cjojMUY0OTdEIj4NCjwvc3Bhbj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZTox MC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90 OyI+bWF5IG5vdCBzdXBwb3J0IHJ0Y3AtbXV4LCBhcyBydGNwLW11eCBpcyBvcHRpb25hbCB0aGVy ZS48L3NwYW4+PHNwYW4gbGFuZz0iRU4tVVMiPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxkaXY+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNv LW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1z aXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtBcmlhbCZxdW90OywmcXVvdDtzYW5zLXNlcmlm JnF1b3Q7Ij5TbyBpZiB3ZSBkcm9wIG5vbi1tdXggc3VwcG9ydCBmcm9tIHdlYiBicm93c2Vycywg dGhvc2UgbWVkaWEgZ2F0ZXdheXMgdGhhdCBoYXZlIG5vdCBpbXBsZW1lbnRlZCBydGNwLW11eA0K IHdpbGwgc3RvcCBpbnRlcm9wZXJhdGluZy4mbmJzcDs8L3NwYW4+PHNwYW4gbGFuZz0iRU4tVVMi PjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28t bWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gbGFu Zz0iRU4tVVMiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8 L2Rpdj4NCjwvYmxvY2txdW90ZT4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBs YW5nPSJFTi1VUyI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiPkZpcnN0IG9mIGFsbCwgZG8g eW91IGtub3cgb2YgYW55IFdlYlJUQyB0byBJTVMgZ2F0ZXdheXMgdGhhdCBkbyBub3QgaW1wbGVt ZW50IHJ0Y3AtbXV4IG9uIHRoZSBXZWJSVEMgc2lkZT8gSSBzdHJvbmdseSBzdXNwZWN0IHRoZXJl IGFyZSBub25lLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48 L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1V UyI+U2Vjb25kLCB0aGUgb25seSByZWFzb25zIG5vdCB0byB1c2UgcnRjcC1tdXggdGhhdCBJIGNh biB0aGluayBvZiBhcmUgdGhlIGZvbGxvd2luZzo8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rp dj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyI+PG86cD4m bmJzcDs8L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+PHNwYW4gbGFuZz0iRU4tVVMiPjEuIFVzaW5nIGRpZmZlcmVudCBRT1Mgc2V0dGluZ3MgZm9y IFJUQ1AgdnMgUlRQPG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiPjIuIFNlbmRpbmcgUlRDUCB0byBhIGRp ZmZlcmVudCBkZXZpY2UgZnJvbSBSVFA8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxk aXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyI+PG86cD4mbmJzcDs8 L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNw YW4gbGFuZz0iRU4tVVMiPkkgZG8gbm90IHRoaW5rIHRoZSBmaXJzdCB1c2UgY2FzZSB3YXJyYW50 cyBtYWtpbmcgcnRjcC1tdXggb3B0aW9uYWwsIHNpbmNlLCBwcmFjdGljYWxseSBubyBvbmUgZG9l cyB0aGlzLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIj5TZWNvbmQgdXNlIGNhc2UgaXMgYWxzbyBmYWly bHkgbWFyZ2luYWwuIFBsdXMgaXQgY2FuIGJlIGhhbmRsZWQgYnkgdGhlIGdhdGV3YXkgd2hpY2gg Y2FuIHNlbmQgUlRDUCB0byBvbmUgZGV2aWNlIGFuZCBSVFAgdG8gYW5vdGhlci48bzpwPjwvbzpw Pjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBs YW5nPSJFTi1VUyI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiPlNvLCB1bmxlc3Mgc29tZW9u ZSBjYW4gY29tZSB1cCB3aXRoIGEgdXNlIGNhc2Ugd2h5IFJUUCBhbmQgUlRDUCBzaG91bGQgdXNl IGRpZmZlcmVudCB0cmFuc3BvcnRzLCBJIHRoaW5rIHJ0Y3AtbXV4IHNob3VsZCBiZSBtYW5kYXRv cnkuPG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjwv ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIj5SZWdh cmRzLDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIj5fX19fX19fX19fX19fXzxvOnA+PC9vOnA+PC9zcGFu PjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVO LVVTIj5Sb21hbiBTaHBvdW50PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8L2Rpdj4N CjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9ib2R5Pg0KPC9odG1sPg0K --_000_786615F3A85DF44AA2A76164A71FE1AC7ADB9E25FR711WXCHMBA03z_-- From nobody Thu Aug 6 00:06:54 2015 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 984E31A892F; Thu, 6 Aug 2015 00:06:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.201 X-Spam-Level: X-Spam-Status: No, score=-4.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Z4uy0cbqXllE; Thu, 6 Aug 2015 00:06:49 -0700 (PDT) Received: from sesbmg23.ericsson.net (sesbmg23.ericsson.net [193.180.251.37]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 139FC1A8946; Thu, 6 Aug 2015 00:06:47 -0700 (PDT) X-AuditID: c1b4fb25-f79446d000003bb1-4d-55c307858fd1 Received: from ESESSHC002.ericsson.se (Unknown_Domain [153.88.253.124]) by sesbmg23.ericsson.net (Symantec Mail Security) with SMTP id 6F.20.15281.58703C55; Thu, 6 Aug 2015 09:06:46 +0200 (CEST) Received: from ESESSMB209.ericsson.se ([169.254.9.36]) by ESESSHC002.ericsson.se ([153.88.183.24]) with mapi id 14.03.0210.002; Thu, 6 Aug 2015 09:06:44 +0200 From: Christer Holmberg To: Stephen Farrell , Eric Rescorla Thread-Topic: [rtcweb] Stephen Farrell's Discuss on draft-ietf-rtcweb-stun-consent-freshness-15: (with DISCUSS and COMMENT) Thread-Index: AdDQFfeL+XAGQdpbT/SGgoyclKTXyg== Date: Thu, 6 Aug 2015 07:06:43 +0000 Message-ID: <7594FB04B1934943A5C02806D1A2204B348EA6D5@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.16] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFvrOLMWRmVeSWpSXmKPExsUyM+JvjW4b++FQg1Ot/BbXJnxntrhwaTWz xY7nDawWK16fY7eY8Wcis0XP2xssFmv/tbNbTN97jd2Bw2Nt91U2jyVLfjJ5TH7cxhzAHMVl k5Kak1mWWqRvl8CVcX3LUdaCvdwV61ssGhhncHYxcnJICJhIdCzYwAhhi0lcuLeerYuRi0NI 4CijxKYdj6CcRYwS3Q/nMnUxcnCwCVhIdP/TBmkQEfCV+PF3P1gNs8BVZolb53qZQRLCAjUS l27MZoQoqpW4u7uRDcLWk/j38SUryBwWARWJNz9NQMK8QHMObpsF1soIdMT3U2uYQGxmAXGJ W0/mM0EcJyCxZM95ZghbVOLl43+sELaixM6z7cwQ9ToSC3Z/YoOwtSWWLXzNDDFfUOLkzCcs ExhFZiEZOwtJyywkLbOQtCxgZFnFKFqcWpyUm25krJdalJlcXJyfp5eXWrKJERhTB7f8Vt3B ePmN4yFGAQ5GJR7eBfsPhQqxJpYVV+YeYpTmYFES552xOS9USCA9sSQ1OzW1ILUovqg0J7X4 ECMTB6dUA2Plf0sZ1oOHLuqdnRabPzf4om6r9LFTcnf+HhIMfaD34XtL02Pjm3KcS3M9Xj3k a63nFxaIiQzUUZ53x2/C8jULgiy+Le2x1viWyj6FhdOk4Dqj3cNZFkZpzblxOVP816a9cA3f LPonRHJtg+zDi5l17ac/Gs15sutf3KXaz0ujNpTfPHP2jJUSS3FGoqEWc1FxIgDOhSitigIA AA== Archived-At: Cc: "draft-ietf-rtcweb-stun-consent-freshness@ietf.org" , "rtcweb-chairs@ietf.org" , "draft-ietf-rtcweb-stun-consent-freshness.shepherd@ietf.org" , "rtcweb@ietf.org" , The IESG , "draft-ietf-rtcweb-stun-consent-freshness.ad@ietf.org" Subject: Re: [rtcweb] Stephen Farrell's Discuss on draft-ietf-rtcweb-stun-consent-freshness-15: (with DISCUSS and COMMENT) X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 06 Aug 2015 07:06:50 -0000 Hi, >>> (1) Why call this "consent?" That term is (ab)used in many ways on=20 >>> the web, and adding another variation without a definition that=20 >>> distinguishes this from "click ok to my 200 page anti-privacy policy"=20 >>> or "remember that example.com is allowed use my camera/mic" seems=20 >>> like a terrible idea. I also don't see how this can ever be something=20 >>> to which a normal person can "consent" (i.e. >>> consciously agree while fully understanding) so the term is IMO very=20 >>> misleading, and will I fear be used to mislead further. (See also=20 >>> some of the comments below - I do not think we ought be as fast and=20 >>> loose with this aleady terribly badly used term.) To summarise: I'd=20 >>> love if you did s/consent/anything-else/g but if not, please define=20 >>> consent here in a way that clearly and unambiguously distinguishes=20 >>> this usage from other abuses of the term. >>> >>=20 >> You should probably propose a new term at this point. > > Really? Happy to try (and fail:-) How'd "willing to take rtcweb traffic"= work? I suspect it wouldn't though. This is IETF, so if you are going to use that many words you need to come u= p with a cool abbreviation :) Seriously, I am not sure "willing to" is any different from "consent". Isn'= t the important thing to make it clear that the draft doesn't talk about US= ER consent, but "application level" consent? Regards, Christer=20 From nobody Thu Aug 6 01:34:28 2015 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9C11F1ACEE1; Thu, 6 Aug 2015 01:34:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9PMhhewR4UA4; Thu, 6 Aug 2015 01:34:24 -0700 (PDT) Received: from mail-wi0-x235.google.com (mail-wi0-x235.google.com [IPv6:2a00:1450:400c:c05::235]) (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 7D59E1ACEA2; Thu, 6 Aug 2015 01:34:24 -0700 (PDT) Received: by wibxm9 with SMTP id xm9so13707981wib.1; Thu, 06 Aug 2015 01:34:23 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=wlggN7DnTIAZwd7VO4u6nrXZWN3r4jVjVad63zg/l8A=; b=wju5JjR7Def6BDizPqaOot+mFBGtTMBFsCsF4Lt5gUfiKsRwIxdhflTUZLffKmpgaE vSqUYYfhuQ/p1kq5Xdgy5jjA/0PzxbqKBHk2TTdlc0e6hFMOBmUBiUNxZk3t7lPxzYQV 3d63eIMPW9DUTQWPWDgAyxuZb1lYPAzpdfw2jfeQtQ9Sipa9nX9zsgDruClQ/sYZc6k1 1nx8q/2Y4J9TIVXq0mtpYPRYSxWHKailwHIvR1Ww1IVOxdI36z4He7fyKcMrN39rNI6f JEXL0I/BHvLjf3MOP+OHuMWlbCayOj6qeeJoAWvhlkUoa+YV4A+HacO5pz6XWPMo7Ikk PsQA== MIME-Version: 1.0 X-Received: by 10.180.83.72 with SMTP id o8mr328009wiy.27.1438850063196; Thu, 06 Aug 2015 01:34:23 -0700 (PDT) Received: by 10.194.24.193 with HTTP; Thu, 6 Aug 2015 01:34:23 -0700 (PDT) In-Reply-To: <7594FB04B1934943A5C02806D1A2204B348E9691@ESESSMB209.ericsson.se> References: <20150805130607.20844.70680.idtracker@ietfa.amsl.com> <7594FB04B1934943A5C02806D1A2204B348E9691@ESESSMB209.ericsson.se> Date: Thu, 6 Aug 2015 10:34:23 +0200 Message-ID: From: Xavier Marjou To: Christer Holmberg Content-Type: multipart/alternative; boundary=f46d0442887ee6e8c3051ca06272 Archived-At: Cc: "draft-ietf-rtcweb-stun-consent-freshness@ietf.org" , "rtcweb-chairs@ietf.org" , "draft-ietf-rtcweb-stun-consent-freshness.shepherd@ietf.org" , "rtcweb@ietf.org" , The IESG , "draft-ietf-rtcweb-stun-consent-freshness.ad@ietf.org" Subject: Re: [rtcweb] Stephen Farrell's Discuss on draft-ietf-rtcweb-stun-consent-freshness-15: (with DISCUSS and COMMENT) X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 06 Aug 2015 08:34:26 -0000 --f46d0442887ee6e8c3051ca06272 Content-Type: text/plain; charset=UTF-8 >(2) WebRTC does not require STUN or TURN servers for some calls, even if it does for many. In a typical WebRTC communication with A and B as WebRTC endpoints: 1 - Optionally A and/or B can use a STUN server to discover a public IP address ("server reflexive" address as per rfc5245) 2 - Optionally A and/or B can use a TURN server to tunnel/relay WebRTC messages with the help of a TURN server (c.f. draft-ietf-tram-turnbis-05) 3 - A and B have to implement ICE (rfc5245) and thus have to exchange STUN connectivity check messages between their candidates (to try "open" flows", ... and maybe even to transport "consent" information). Therefore, there can be STUN messages transported in three different "sectors" : 1 - between the WebRTC endpoint and its STUN server, if used 2 - between the WebRTC endpoint and its TURN server, if used (draft-ietf-tram-turnbis-05 states that "Most, though not all, TURN messages are STUN-formatted messages" so there are precisely "STUN-formatted", not "STUN", but I mention them to be exhaustive with different sort of messages appearing as STUN messages in tools like Wireshark). 3 - between the WebRTC endpoints (in this case, the STUN connectivity check messages are in the same flow that transports SCTP/DTLS and SRTP messages). Some newcomers think that STUN messages only happen in cases 1 and/or 2, they forget case 3. Maybe this explains the misunderstanding. On Wed, Aug 5, 2015 at 3:22 PM, Christer Holmberg < christer.holmberg@ericsson.com> wrote: > Hi Stephen, > > >(2) WebRTC does not require STUN or TURN servers for some calls, even if > it does for many. Why is it ok to require such a server be present in all > calls (which I think this means) espcially > >when that means exposing additional meta-data (calling parties in a case > where the servers weren't needed and call duration in all > >cases) to those servers when that is not always necessary? > > Could you please refer to the text which you think mandates STUN or TURN > servers? > > If there are no NATs, the STUN requests can be sent between the endpoints, > without STUN or TURN servers. > > Regards, > > Christer > > _______________________________________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/listinfo/rtcweb > --f46d0442887ee6e8c3051ca06272 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
>(2) WebRTC does not require STUN or TURN servers for some ca= lls, even if it does for many.=C2=A0

In a typica= l WebRTC communication with A and B as WebRTC endpoints:=C2=A0
1 - Opti= onally A and/or B can use a STUN server to discover a public IP address (&q= uot;server reflexive" address as per rfc5245)
2 - Optionally= A and/or B can use a TURN server to tunnel/relay WebRTC messages with the = help of a TURN server (c.f. draft-ietf-tram-turnbis-05)
3 - A= and B have to implement ICE (rfc5245) and thus have to exchange STUN conne= ctivity check messages between their candidates (to try "open" fl= ows", ... and maybe even to transport "consent" information)= .=C2=A0

Therefore, there can be STUN messages tran= sported in three different "sectors" :
1 - between the = WebRTC endpoint and its STUN server, if used
2 - between the WebR= TC endpoint and its TURN server, if used (draft-ietf-tram-turnbis-05 states= that "Most, though not all, TURN messages are STUN-formatted messages= " so there are precisely "STUN-formatted", not "STUN&qu= ot;, but I mention them to be exhaustive with different sort of messages ap= pearing as STUN messages in tools like Wireshark).
3 - between th= e WebRTC endpoints (in this case, the STUN connectivity check messages are = in the same flow that transports SCTP/DTLS and SRTP messages).
Some newcomers think that STUN messages only happen in cases 1= and/or 2, they forget case 3. Maybe this explains the misunderstanding.



On Wed, Aug 5, 2015 at 3:22 PM, Christer H= olmberg <christer.holmberg@ericsson.com> wrote:=
Hi Stephen,

>(2) WebRTC does not require STUN or TURN servers for some calls, even i= f it does for many. Why is it ok to require such a server be present in all= calls (which I think this means) espcially
>when that means exposing additional meta-data (calling parties in a cas= e where the servers weren't needed and call duration in all
>cases) to those servers when that is not always necessary?

Could you please refer to the text which you think mandates STUN or = TURN servers?

If there are no NATs, the STUN requests can be sent between the endpoints, = without STUN or TURN servers.

Regards,

Christer

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

--f46d0442887ee6e8c3051ca06272-- From nobody Thu Aug 6 02:18:14 2015 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A28EF1B2AF8 for ; Thu, 6 Aug 2015 02:18:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id p6n45W3IstfP for ; Thu, 6 Aug 2015 02:18:10 -0700 (PDT) Received: from na01-by2-obe.outbound.protection.outlook.com (mail-by2on0097.outbound.protection.outlook.com [207.46.100.97]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 989A81B2ABD for ; Thu, 6 Aug 2015 02:18:10 -0700 (PDT) Received: from SN1PR0301MB1551.namprd03.prod.outlook.com (10.162.129.157) by SN1PR0301MB1552.namprd03.prod.outlook.com (10.162.129.158) with Microsoft SMTP Server (TLS) id 15.1.225.19; Thu, 6 Aug 2015 09:18:08 +0000 Received: from SN1PR0301MB1551.namprd03.prod.outlook.com ([10.162.129.157]) by SN1PR0301MB1551.namprd03.prod.outlook.com ([10.162.129.157]) with mapi id 15.01.0225.018; Thu, 6 Aug 2015 09:18:07 +0000 From: "Asveren, Tolga" To: "Schwarz, Albrecht (Albrecht)" , Roman Shpount , "Rauschenbach, Uwe (Nokia - DE/Munich)" Thread-Topic: [rtcweb] What the gateway draft should say about mux/non-mux Thread-Index: AQHQy8DcUgzWwtVCmk+8q67BCzjC45316kQQgAAD5oCAAACVsIAAAj2AgAPw2gCAAEFTAIAC/BgAgACAxgCAABQlsIAA2x8AgAAp4Wc= Date: Thu, 6 Aug 2015 09:18:07 +0000 Message-ID: References: <7594FB04B1934943A5C02806D1A2204B348E29DA@ESESSMB209.ericsson.se> <67196805-ED4E-49EA-83AA-3F4C37B5BC50@gmail.com> <7594FB04B1934943A5C02806D1A2204B348E2D52@ESESSMB209.ericsson.se> <56C2F665D49E0341B9DF5938005ACDF8196FF3ED@DEMUMBX005.nsn-intra.net> <56C2F665D49E0341B9DF5938005ACDF8196FF450@DEMUMBX005.nsn-intra.net> <786615F3A85DF44AA2A76164A71FE1AC7ADB690D@FR711WXCHMBA03.zeu.alcatel-lucent.com> <56C2F665D49E0341B9DF5938005ACDF81970EDC1@DEMUMBX005.nsn-intra.net> , <786615F3A85DF44AA2A76164A71FE1AC7ADB9E25@FR711WXCHMBA03.zeu.alcatel-lucent.com> In-Reply-To: <786615F3A85DF44AA2A76164A71FE1AC7ADB9E25@FR711WXCHMBA03.zeu.alcatel-lucent.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=tasveren@sonusnet.com; x-originating-ip: [50.182.164.80] x-microsoft-exchange-diagnostics: 1; SN1PR0301MB1552; 5:F/kqgsLPk/Swj0src/OqG6NTgdWUML2r1zTBcUWONXIuN9aF55GvUOZpn0kyb1+U4xLgtl5Uint9EKcdnXxMx+oe19yoVJOkH/AjdrUExrnJ9fLoG40Ddgff2O5UlDgpZ8NAEEtRrQ2f5xqUvcdxyQ==; 24:81MLXRFK5+oWARHpsVr2e068NHV0mtPuoRrynXYs3WxL7N7r/VUBYsA3b6dmK6dDKG4/CVEUaC8DOESZjgqnH4yfEPq6z3KGpuGe8nJWI4c=; 20:AGJ2QTXMxYdOCdIP0IIKx4ImV1HJAt+8V2IPXZdWNH3oX09DuAviVdrA6lg7XveM9WDRGFpGo0RF0EqGOsx/SA== x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:SN1PR0301MB1552; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:; x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(601004)(5005006)(3002001); SRVR:SN1PR0301MB1552; BCL:0; PCL:0; RULEID:; SRVR:SN1PR0301MB1552; x-forefront-prvs: 06607E485E x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(189002)(24454002)(164054003)(199003)(377454003)(64706001)(2950100001)(2900100001)(66066001)(102836002)(77096005)(15975445007)(68736005)(106356001)(105586002)(99286002)(106116001)(92566002)(2656002)(5003600100002)(87936001)(19580405001)(19580395003)(5001960100002)(93886004)(86362001)(46102003)(19627405001)(19625215002)(76576001)(4001540100001)(97736004)(5001770100001)(50986999)(54356999)(101416001)(5001830100001)(5001860100001)(76176999)(33656002)(62966003)(5002640100001)(40100003)(122556002)(189998001)(74316001)(77156002)(19617315012)(16236675004)(10400500002)(81156007); DIR:OUT; SFP:1101; SCL:1; SRVR:SN1PR0301MB1552; H:SN1PR0301MB1551.namprd03.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; MX:1; A:1; LANG:en; received-spf: None (protection.outlook.com: sonusnet.com does not designate permitted sender hosts) Content-Type: multipart/alternative; boundary="_000_SN1PR0301MB1551FC140096D841F8B82418B2740SN1PR0301MB1551_" MIME-Version: 1.0 X-OriginatorOrg: sonusnet.com X-MS-Exchange-CrossTenant-originalarrivaltime: 06 Aug 2015 09:18:07.6710 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 29a671dc-ed7e-4a54-b1e5-8da1eb495dc3 X-MS-Exchange-Transport-CrossTenantHeadersStamped: SN1PR0301MB1552 Archived-At: Cc: "" Subject: Re: [rtcweb] What the gateway draft should say about mux/non-mux X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 06 Aug 2015 09:18:13 -0000 --_000_SN1PR0301MB1551FC140096D841F8B82418B2740SN1PR0301MB1551_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable Why should we consider 3GPP the sole "owner/user" of the term/entity WebRTC= -GW? I think it has a much more general meaning and use in practice. It can= refer to many different types of elements which can be deployed in many di= fferent environments, hence any attempt to define it strictly/restrict its = capabilities are futile IMHO. Thanks, Tolga ________________________________ From: Schwarz, Albrecht (Albrecht) Sent: Thursday, August 6, 2015 2:44 AM To: Asveren, Tolga; Roman Shpount; Rauschenbach, Uwe (Nokia - DE/Munich) Cc: ext Eric Rescorla; Christer Holmberg; Bernard Aboba; Subject: RE: [rtcweb] What the gateway draft should say about mux/non-mux The concerned 3GPP WebRTC gateway (3GPP 23.334/29.334) supports already RTP= /RTCP transport multiplexing (since 3GPP Release 12), i.e. should not be th= e limiting factor in this discussion. For ones interested in the RTCP port allocation rules, see H.248.57: https://www.itu.int/rec/dologin_pub.asp?lang=3De&id=3DT-REC-H.248.57-201410= -I!!PDF-E&type=3Ditems Clause 7 describes RTP/RTCP transport multiplexing. ITU-T H.248.57 is alrea= dy supported by 3GPP 29.334. The rationale behind the =93optional tagging=94 by 23.228 is a third reason= , beyond >1. Using different QOS settings for RTCP vs RTP >2. Sending RTCP to a different device from RTP Don=92t want to go in the 3GPP specific details, but it has nothing to do w= ith the 3GPP UE-embedded WebRTC client nor any constraints by 3GPP WebRTC g= ateways. Thus, a WebRTC gateway MUST support RTP/RTCP transport multiplexing due to = its purpose in interworking support. Regards, Albrecht From: Asveren, Tolga [mailto:tasveren@sonusnet.com] Sent: Mittwoch, 5. August 2015 19:47 To: Roman Shpount; Rauschenbach, Uwe (Nokia - DE/Munich) Cc: ext Eric Rescorla; Schwarz, Albrecht (Albrecht); Christer Holmberg; Ber= nard Aboba; Subject: RE: [rtcweb] What the gateway draft should say about mux/non-mux i- I humbly disagree that using different QoS RTCP/RTP, e.g. different Diff= Serv values , should be dismissed. ii- Let me also add another reason why no-rtcp-mux may be needed: Implement= ation difficulties in certain GWs. Considering that there is already a negotiation mechanism for rtcp-mux supp= ort, that it can be de-facto mandated by the choice of browsers for Interne= t, I think what Christer/Albrecht suggested is the right way to move forwar= d: provide clarifications for vague points. I don=92t understand why lack o= f clarity in existing specifications should cause imposing restrictions. Th= is would be akin to dropping a feature due to a bug. In this case, the =93b= ug=94 is lack of clarity in normative specifications and it can be addresse= d by further specification. Thanks, Tolga From: Roman Shpount [mailto:roman@telurix.com] Sent: Wednesday, August 05, 2015 12:29 PM To: Rauschenbach, Uwe (Nokia - DE/Munich) > Cc: ext Eric Rescorla >; Schwarz, Albrech= t (Albrecht) >; Asveren, Tolga >; Christer Holmberg >; Bernard Aboba >; > > Subject: Re: [rtcweb] What the gateway draft should say about mux/non-mux On Wed, Aug 5, 2015 at 4:47 AM, Rauschenbach, Uwe (Nokia - DE/Munich) > wrote: Media gateway implementations according to 3GPP TS 23.228 may not support r= tcp-mux, as rtcp-mux is optional there. So if we drop non-mux support from web browsers, those media gateways that = have not implemented rtcp-mux will stop interoperating. First of all, do you know of any WebRTC to IMS gateways that do not impleme= nt rtcp-mux on the WebRTC side? I strongly suspect there are none. Second, the only reasons not to use rtcp-mux that I can think of are the fo= llowing: 1. Using different QOS settings for RTCP vs RTP 2. Sending RTCP to a different device from RTP I do not think the first use case warrants making rtcp-mux optional, since,= practically no one does this. Second use case is also fairly marginal. Plus it can be handled by the gate= way which can send RTCP to one device and RTP to another. So, unless someone can come up with a use case why RTP and RTCP should use = different transports, I think rtcp-mux should be mandatory. Regards, ______________ Roman Shpount --_000_SN1PR0301MB1551FC140096D841F8B82418B2740SN1PR0301MB1551_ Content-Type: text/html; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable

Why should we consider 3GPP the sole "owner/user" of the term/= entity WebRTC-GW? I think it has a much more general meaning and use in pra= ctice. It can refer to many different types of elements which can be deploy= ed in many different environments, hence any attempt to define it strictly/restrict its capabilities are futile IMHO.


Thanks,

Tolga



From: Schwarz, Albrecht (Al= brecht) <albrecht.schwarz@alcatel-lucent.com>
Sent: Thursday, August 6, 2015 2:44 AM
To: Asveren, Tolga; Roman Shpount; Rauschenbach, Uwe (Nokia - DE/Mun= ich)
Cc: ext Eric Rescorla; Christer Holmberg; Bernard Aboba; <rtcweb@= ietf.org>
Subject: RE: [rtcweb] What the gateway draft should say about mux/no= n-mux
 

The c= oncerned 3GPP WebRTC gateway (3GPP 23.334/29.334) supports already RTP/RTCP= transport multiplexing (since 3GPP Release 12), i.e. should not be the lim= iting factor in this discussion.

For o= nes interested in the RTCP port allocation rules, see H.248.57:

https://www.itu.int/rec/dologin_pub.asp?lang=3De&id=3DT-R= EC-H.248.57-201410-I!!PDF-E&type=3Ditems

Claus= e 7 describes RTP/RTCP transport multiplexing. ITU-T H.248.57 is already su= pported by 3GPP 29.334.

 = ;

The r= ationale behind the =93optional tagging=94 by 23.228 is a third reason, bey= ond

>1. Using different QOS settings for RTCP vs RTP

>2. Sending RTCP to a different device from RTP

 

Don= =92t want to go in the 3GPP specific details, but it has nothing to do with= the 3GPP UE-embedded WebRTC client nor any constraints by 3GPP WebRTC gate= ways.

 = ;

Thus,= a WebRTC gateway MUST support RTP/RTCP transport multiplexing due to its p= urpose in interworking support.

 = ;

Regar= ds,

Albre= cht

 

 

From:  

i- I humbly disagree that using= different QoS RTCP/RTP, e.g. different DiffServ values , should be dismiss= ed.

ii- Let me also add another rea= son why no-rtcp-mux may be needed: Implementation difficulties in certain G= Ws.

 

Considering that there is alrea= dy a negotiation mechanism for rtcp-mux support, that it can be de-facto ma= ndated by the choice of browsers for Internet, I think what Christer/Albrecht suggested is the right way to move forward: provide clar= ifications for vague points. I don=92t understand why lack of clarity in ex= isting specifications should cause imposing restrictions. This would be aki= n to dropping a feature due to a bug. In this case, the =93bug=94 is lack of clarity in normative specifications= and it can be addressed by further specification.

 

Thanks,

Tolga

 

From: Roman Shpount [mailto:roman@telurix.com]
Sent: Wednesday, August 05, 2015 12:29 PM
To: Rauschenbach, Uwe (Nokia - DE/Munich) <= uwe.rauschenbach@nokia.com>
Cc: ext Eric Rescorla <ekr@rtfm.com>; Schwarz, Alb= recht (Albrecht) <albrecht.schwarz@alcate= l-lucent.com>; Asveren, Tolga <tasveren@sonusnet.com>; Christe= r Holmberg <christer.holmberg@ericsson.com= >; Bernard Aboba <bernard.aboba@gmail.com>; <= rtcweb@ietf.org> <rtcweb@ietf.org> Subject: Re: [rtcweb] What the gateway draft should say about mux/no= n-mux

 

On Wed, Aug 5, 2015 at 4:47 AM, Rauschenbach, Uwe (Nok= ia - DE/Munich) <uwe.rauschenbac= h@nokia.com> wrote:

Media gateway implementations according to 3GPP = TS 23.228 may not support rtcp-mux, as rtcp-mux is = optional there.

So if we drop non-mux support from web browsers,= those media gateways that have not implemented rtcp-mux will stop interope= rating. 

 

 

First of all, do you know of any WebRTC to IMS gateway= s that do not implement rtcp-mux on the WebRTC side? I strongly suspect the= re are none.

 

Second, the only reasons not to use rtcp-mux that I ca= n think of are the following:

 

1. Using different QOS settings for RTCP vs RTP=

2. Sending RTCP to a different device from RTP<= /p>

 

I do not think the first use case warrants making rtcp= -mux optional, since, practically no one does this.

Second use case is also fairly marginal. Plus it can b= e handled by the gateway which can send RTCP to one device and RTP to anoth= er.

 

So, unless someone can come up with a use case why RTP= and RTCP should use different transports, I think rtcp-mux should be manda= tory.

 

Regards,

______________

Roman Shpount

--_000_SN1PR0301MB1551FC140096D841F8B82418B2740SN1PR0301MB1551_-- From nobody Thu Aug 6 02:51:40 2015 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 16DA01B2B9C for ; Thu, 6 Aug 2015 02:51:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.2 X-Spam-Level: X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XTPgnhTGVf4x for ; Thu, 6 Aug 2015 02:51:33 -0700 (PDT) Received: from sesbmg22.ericsson.net (sesbmg22.ericsson.net [193.180.251.48]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7BD731B2B99 for ; Thu, 6 Aug 2015 02:51:32 -0700 (PDT) X-AuditID: c1b4fb30-f79706d000007227-6c-55c32e2257ae Received: from ESESSHC009.ericsson.se (Unknown_Domain [153.88.253.124]) by sesbmg22.ericsson.net (Symantec Mail Security) with SMTP id 41.51.29223.22E23C55; Thu, 6 Aug 2015 11:51:30 +0200 (CEST) Received: from ESESSMB209.ericsson.se ([169.254.9.36]) by ESESSHC009.ericsson.se ([153.88.183.45]) with mapi id 14.03.0210.002; Thu, 6 Aug 2015 11:51:30 +0200 From: Christer Holmberg To: "Asveren, Tolga" , "Schwarz, Albrecht (Albrecht)" , Roman Shpount , "Rauschenbach, Uwe (Nokia - DE/Munich)" Thread-Topic: [rtcweb] What the gateway draft should say about mux/non-mux Thread-Index: AQHQy78thNOz8AYdMEys1nzX7WTf2J316g6A///gJYCAAAJzgIAAAVWAgAABfoCAA/DZAIAAQVMAgAL8GACAAIDGAIAAFdwAgADZaQCAACrOgIAAJh8A Date: Thu, 6 Aug 2015 09:51:29 +0000 Message-ID: <7594FB04B1934943A5C02806D1A2204B348EAB88@ESESSMB209.ericsson.se> References: <7594FB04B1934943A5C02806D1A2204B348E29DA@ESESSMB209.ericsson.se> <67196805-ED4E-49EA-83AA-3F4C37B5BC50@gmail.com> <7594FB04B1934943A5C02806D1A2204B348E2D52@ESESSMB209.ericsson.se> <56C2F665D49E0341B9DF5938005ACDF8196FF3ED@DEMUMBX005.nsn-intra.net> <56C2F665D49E0341B9DF5938005ACDF8196FF450@DEMUMBX005.nsn-intra.net> <786615F3A85DF44AA2A76164A71FE1AC7ADB690D@FR711WXCHMBA03.zeu.alcatel-lucent.com> <56C2F665D49E0341B9DF5938005ACDF81970EDC1@DEMUMBX005.nsn-intra.net> , <786615F3A85DF44AA2A76164A71FE1AC7ADB9E25@FR711WXCHMBA03.zeu.alcatel-lucent.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.16] Content-Type: multipart/alternative; boundary="_000_7594FB04B1934943A5C02806D1A2204B348EAB88ESESSMB209erics_" MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFtrFIsWRmVeSWpSXmKPExsUyM+Jvja6S3uFQg113VC3+tP5itNiw7z+z xYrX59gtZlyYymyx9l87u8XszvdMFo8nn2J3YPdofbaX1WPnrLvsHkuW/GTyuHvrEpPH5Mdt zB6XPv9n97g1pSCAPYrLJiU1J7MstUjfLoEro//yPJaCvdcZKxYeucjcwNh1gLGLkZNDQsBE 4sub9UwQtpjEhXvr2boYuTiEBI4ySuw6toUVwlnEKNF2bA9QFQcHm4CFRPc/bZC4iMB9Ron+ XWdYQOLMAmUSqxZHgQwSFvCUuNW5GGyoiICXxLrv15gh6psYJRreTGQHSbAIqEjs2fGAGcTm FfCVWHJoGzPEsgZ+ieX/JoB1cwokSpz5vRasgRHovO+n1oDFmQXEJW49mQ91toDEkj3nmSFs UYmXj/+xQtiKEjvPtjND1OdL3Dt/CGqZoMTJmU9YJjCKzkIyahaSsllIyiDiOhILdn9ig7C1 JZYtfM0MY5858JgJWXwBI/sqRtHi1OKk3HQjI73Uoszk4uL8PL281JJNjMDIPrjlt8EOxpfP HQ8xCnAwKvHwLth/KFSINbGsuDL3EKM0B4uSOO+MzXmhQgLpiSWp2ampBalF8UWlOanFhxiZ ODilGhh1bLPWuAvOTlPIn1SX0L53s6ubfiT7deWlzH/dGNaHXOC4uviBPcOuqWxhcWar4x3X zvm6sso03iImMJzl8P88Q+uFPAnNO2rzp5lx3/whO8H+6I0bxU4b5rwoE9h+8wpnxYX1IglZ Jfr1J2vWRAellCTfC3860V5gReJda8e7TCe5BF6xRCuxFGckGmoxFxUnAgBTA94YzQIAAA== Archived-At: Cc: "" Subject: Re: [rtcweb] What the gateway draft should say about mux/non-mux X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 06 Aug 2015 09:51:38 -0000 --_000_7594FB04B1934943A5C02806D1A2204B348EAB88ESESSMB209erics_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi, No matter whether the gateway supports RTP/RTCP mux or not, there are cases= where the legacy network/endpoints will not use RTP/RTCP mux, so I guess p= eople then would want to be able to negotiate non-mux "end-to-end", rather = than having the gateway to demux/mux RTP and RTCP. Regards, Christer From: Asveren, Tolga [mailto:tasveren@sonusnet.com] Sent: 6. elokuuta 2015 12:18 To: Schwarz, Albrecht (Albrecht); Roman Shpount; Rauschenbach, Uwe (Nokia -= DE/Munich) Cc: ext Eric Rescorla; Christer Holmberg; Bernard Aboba; Subject: Re: [rtcweb] What the gateway draft should say about mux/non-mux Why should we consider 3GPP the sole "owner/user" of the term/entity WebRTC= -GW? I think it has a much more general meaning and use in practice. It can= refer to many different types of elements which can be deployed in many di= fferent environments, hence any attempt to define it strictly/restrict its = capabilities are futile IMHO. Thanks, Tolga ________________________________ From: Schwarz, Albrecht (Albrecht) > Sent: Thursday, August 6, 2015 2:44 AM To: Asveren, Tolga; Roman Shpount; Rauschenbach, Uwe (Nokia - DE/Munich) Cc: ext Eric Rescorla; Christer Holmberg; Bernard Aboba; > Subject: RE: [rtcweb] What the gateway draft should say about mux/non-mux The concerned 3GPP WebRTC gateway (3GPP 23.334/29.334) supports already RTP= /RTCP transport multiplexing (since 3GPP Release 12), i.e. should not be th= e limiting factor in this discussion. For ones interested in the RTCP port allocation rules, see H.248.57: https://www.itu.int/rec/dologin_pub.asp?lang=3De&id=3DT-REC-H.248.57-201410= -I!!PDF-E&type=3Ditems Clause 7 describes RTP/RTCP transport multiplexing. ITU-T H.248.57 is alrea= dy supported by 3GPP 29.334. The rationale behind the "optional tagging" by 23.228 is a third reason, be= yond >1. Using different QOS settings for RTCP vs RTP >2. Sending RTCP to a different device from RTP Don't want to go in the 3GPP specific details, but it has nothing to do wit= h the 3GPP UE-embedded WebRTC client nor any constraints by 3GPP WebRTC gat= eways. Thus, a WebRTC gateway MUST support RTP/RTCP transport multiplexing due to = its purpose in interworking support. Regards, Albrecht From: Asveren, Tolga [mailto:tasveren@sonusnet.com] Sent: Mittwoch, 5. August 2015 19:47 To: Roman Shpount; Rauschenbach, Uwe (Nokia - DE/Munich) Cc: ext Eric Rescorla; Schwarz, Albrecht (Albrecht); Christer Holmberg; Ber= nard Aboba; > Subject: RE: [rtcweb] What the gateway draft should say about mux/non-mux i- I humbly disagree that using different QoS RTCP/RTP, e.g. different Diff= Serv values , should be dismissed. ii- Let me also add another reason why no-rtcp-mux may be needed: Implement= ation difficulties in certain GWs. Considering that there is already a negotiation mechanism for rtcp-mux supp= ort, that it can be de-facto mandated by the choice of browsers for Interne= t, I think what Christer/Albrecht suggested is the right way to move forwar= d: provide clarifications for vague points. I don't understand why lack of = clarity in existing specifications should cause imposing restrictions. This= would be akin to dropping a feature due to a bug. In this case, the "bug" = is lack of clarity in normative specifications and it can be addressed by f= urther specification. Thanks, Tolga From: Roman Shpount [mailto:roman@telurix.com] Sent: Wednesday, August 05, 2015 12:29 PM To: Rauschenbach, Uwe (Nokia - DE/Munich) > Cc: ext Eric Rescorla >; Schwarz, Albrech= t (Albrecht) >; Asveren, Tolga >; Christer Holmberg >; Bernard Aboba >; > > Subject: Re: [rtcweb] What the gateway draft should say about mux/non-mux On Wed, Aug 5, 2015 at 4:47 AM, Rauschenbach, Uwe (Nokia - DE/Munich) > wrote: Media gateway implementations according to 3GPP TS 23.228 may not support r= tcp-mux, as rtcp-mux is optional there. So if we drop non-mux support from web browsers, those media gateways that = have not implemented rtcp-mux will stop interoperating. First of all, do you know of any WebRTC to IMS gateways that do not impleme= nt rtcp-mux on the WebRTC side? I strongly suspect there are none. Second, the only reasons not to use rtcp-mux that I can think of are the fo= llowing: 1. Using different QOS settings for RTCP vs RTP 2. Sending RTCP to a different device from RTP I do not think the first use case warrants making rtcp-mux optional, since,= practically no one does this. Second use case is also fairly marginal. Plus it can be handled by the gate= way which can send RTCP to one device and RTP to another. So, unless someone can come up with a use case why RTP and RTCP should use = different transports, I think rtcp-mux should be mandatory. Regards, ______________ Roman Shpount --_000_7594FB04B1934943A5C02806D1A2204B348EAB88ESESSMB209erics_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi,

 <= /p>

No matter = whether the gateway supports RTP/RTCP mux or not, there are cases where the= legacy network/endpoints will not use RTP/RTCP mux, so I guess people then would want to be able to negotiate non-mux “end-to= -end”, rather than having the gateway to demux/mux RTP and RTCP.=

 = ;

Regards,

 = ;

Christer

 = ;

From: Asveren, Tolga [mailto:tasveren@sonusnet.com]
Sent: 6. elokuuta 2015 12:18
To: Schwarz, Albrecht (Albrecht); Roman Shpount; Rauschenbach, Uwe (= Nokia - DE/Munich)
Cc: ext Eric Rescorla; Christer Holmberg; Bernard Aboba; <rtcweb@= ietf.org>
Subject: Re: [rtcweb] What the gateway draft should say about mux/no= n-mux

 

Why should we consider 3GPP the sole = "owner/user" of the term/entity WebRTC-GW? I think it has a much = more general meaning and use in practice. It can refer to many different types of elements which can be deployed in many different environments, he= nce any attempt to define it strictly/restrict its capabilities are futile = IMHO.

 

Thanks,

Tolga

 

From: Schwarz, Albrecht (Albrecht) &= lt;albrecht.schwarz@= alcatel-lucent.com>
Sent: Thursday, August 6, 2015 2:44 AM
To: Asveren, Tolga; Roman Shpount; Rauschenbach, Uwe (Nokia - DE/Mun= ich)
Cc: ext Eric Rescorla; Christer Holmberg; Bernard Aboba; <rtcweb@ietf.org>
Subject: RE: [rtcweb] What the gateway draft should say about mux/no= n-mux

 =

The concerned 3GPP WebRTC gateway (3GPP 23.334/29.33= 4) supports already RTP/RTCP transport multiplexing (since 3GPP Release 12)= , i.e. should not be the limiting factor in this discussion. <= /p>

For ones interested in the RTCP port allocation rule= s, see H.248.57:

https://w= ww.itu.int/rec/dologin_pub.asp?lang=3De&id=3DT-REC-H.248.57-201410-I!!P= DF-E&type=3Ditems

Clause 7 describes RTP/RTCP transport multiplexing. = ITU-T H.248.57 is already supported by 3GPP 29.334.

 =

The rationale behind the “optional taggingR= 21; by 23.228 is a third reason, beyond<= o:p>

&g= t;1. Using different QOS settings for RTCP vs RTP

&g= t;2. Sending RTCP to a different device from RTP

 

Don’t want to go in the 3GPP specific details,= but it has nothing to do with the 3GPP UE-embedded WebRTC client nor any c= onstraints by 3GPP WebRTC gateways.=

 =

Thus, a WebRTC gateway MUST support RTP/RTCP transpo= rt multiplexing due to its purpose in interworking support.

 =

Regards,

Albrecht

 

 

Fro= m: Asveren, Tolga [mailto:tasveren@sonusnet.com]
Sent: Mittwoch, 5. August 2015 19:47
To: Roman Shpount; Rauschenbach, Uwe (Nokia - DE/Munich)
Cc: ext Eric Rescorla; Schwarz, Albrecht (Albrecht); Christer Holmbe= rg; Bernard Aboba; <rtcweb@ietf.org>
Subject: RE: [rtcweb] What the gateway draft should say about mux/no= n-mux

 =

i- = I humbly disagree that using different QoS RTCP/RTP, e.g. different DiffSer= v values , should be dismissed.

ii-= Let me also add another reason why no-rtcp-mux may be needed: Implementati= on difficulties in certain GWs.

&nb= sp;

Con= sidering that there is already a negotiation mechanism for rtcp-mux support= , that it can be de-facto mandated by the choice of browsers for Internet, I think what Christer/Albrecht suggested is the right way to= move forward: provide clarifications for vague points. I don’t under= stand why lack of clarity in existing specifications should cause imposing = restrictions. This would be akin to dropping a feature due to a bug. In this case, the “bug” is lack of cla= rity in normative specifications and it can be addressed by further specifi= cation.

&nb= sp;

Tha= nks,

Tol= ga

&nb= sp;

Fr= om: Roman Shpount [mailto:roman@telurix.com]
Sent: Wednesday, August 05, 2015 12:29 PM
To: Rauschenbach, Uwe (Nokia - DE/Munich) <uwe.rauschenbach@nokia.com>
Cc: ext Eric Rescorla <ekr@rtfm.c= om>; Schwarz, Albrecht (Albrecht) <albrecht.schwarz@alcatel-lucent.com>; Asver= en, Tolga <tasveren@sonusnet.co= m>; Christer Holmberg <ch= rister.holmberg@ericsson.com>; Bernard Aboba <bernard.aboba@gmail.com>; <rtcweb@ietf.org> <rtcweb@ietf.org>
Subject: Re: [rtcweb] What the gateway draft should say about mux/no= n-mux

&n= bsp;

On= Wed, Aug 5, 2015 at 4:47 AM, Rauschenbach, Uwe (Nokia - DE/Munich) <uwe.rauschenba= ch@nokia.com> wrote:

Media g= ateway implementations according to 3GPP TS 23.228 may not support rtcp-mux, as r= tcp-mux is optional there.

So if w= e drop non-mux support from web browsers, those media gateways that have no= t implemented rtcp-mux will stop interoperating. 

&n= bsp;

&n= bsp;

Fi= rst of all, do you know of any WebRTC to IMS gateways that do not implement= rtcp-mux on the WebRTC side? I strongly suspect there are none.

&n= bsp;

Se= cond, the only reasons not to use rtcp-mux that I can think of are the foll= owing:

&n= bsp;

1.= Using different QOS settings for RTCP vs RTP

2.= Sending RTCP to a different device from RTP

&n= bsp;

I = do not think the first use case warrants making rtcp-mux optional, since, p= ractically no one does this.<= /span>

Se= cond use case is also fairly marginal. Plus it can be handled by the gatewa= y which can send RTCP to one device and RTP to another.

&n= bsp;

So= , unless someone can come up with a use case why RTP and RTCP should use di= fferent transports, I think rtcp-mux should be mandatory.

&n= bsp;

Re= gards,

__= ____________

Ro= man Shpount

--_000_7594FB04B1934943A5C02806D1A2204B348EAB88ESESSMB209erics_-- From nobody Thu Aug 6 03:37:09 2015 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B0F811B2C4A for ; Thu, 6 Aug 2015 03:37:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GyoaAfSbZ2ME for ; Thu, 6 Aug 2015 03:37:03 -0700 (PDT) Received: from na01-bn1-obe.outbound.protection.outlook.com (mail-bn1bon0690.outbound.protection.outlook.com [IPv6:2a01:111:f400:fc10::1:690]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6F8CA1B2C49 for ; Thu, 6 Aug 2015 03:37:03 -0700 (PDT) Received: from CY1PR0501MB1577.namprd05.prod.outlook.com (10.161.161.151) by CY1PR0501MB1738.namprd05.prod.outlook.com (10.163.140.20) with Microsoft SMTP Server (TLS) id 15.1.225.19; Thu, 6 Aug 2015 10:36:46 +0000 Received: from CY1PR0501MB1579.namprd05.prod.outlook.com (10.161.161.153) by CY1PR0501MB1577.namprd05.prod.outlook.com (10.161.161.151) with Microsoft SMTP Server (TLS) id 15.1.225.19; Thu, 6 Aug 2015 10:36:45 +0000 Received: from CY1PR0501MB1579.namprd05.prod.outlook.com ([10.161.161.153]) by CY1PR0501MB1579.namprd05.prod.outlook.com ([10.161.161.153]) with mapi id 15.01.0225.018; Thu, 6 Aug 2015 10:36:45 +0000 From: "Wyss, Felix" To: Christer Holmberg , "Asveren, Tolga" , "Schwarz, Albrecht (Albrecht)" , Roman Shpount , "Rauschenbach, Uwe (Nokia - DE/Munich)" Thread-Topic: [rtcweb] What the gateway draft should say about mux/non-mux Thread-Index: AQHQy78vOlSH3eQnGkC70OZ3dfRqQJ316iYAgAABlICAAAJzgIAAAVWAgAABfoCAA/DZAIAAQVMAgAL8GACAAIDGAIAAFdwAgADZaQCAACrOgIAACVOAgAAHsUg= Date: Thu, 6 Aug 2015 10:36:44 +0000 Message-ID: References: <7594FB04B1934943A5C02806D1A2204B348E29DA@ESESSMB209.ericsson.se> <67196805-ED4E-49EA-83AA-3F4C37B5BC50@gmail.com> <7594FB04B1934943A5C02806D1A2204B348E2D52@ESESSMB209.ericsson.se> <56C2F665D49E0341B9DF5938005ACDF8196FF3ED@DEMUMBX005.nsn-intra.net> <56C2F665D49E0341B9DF5938005ACDF8196FF450@DEMUMBX005.nsn-intra.net> <786615F3A85DF44AA2A76164A71FE1AC7ADB690D@FR711WXCHMBA03.zeu.alcatel-lucent.com> <56C2F665D49E0341B9DF5938005ACDF81970EDC1@DEMUMBX005.nsn-intra.net> , <786615F3A85DF44AA2A76164A71FE1AC7ADB9E25@FR711WXCHMBA03.zeu.alcatel-lucent.com> , <7594FB04B1934943A5C02806D1A2204B348EAB88@ESESSMB209.ericsson.se> In-Reply-To: <7594FB04B1934943A5C02806D1A2204B348EAB88@ESESSMB209.ericsson.se> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=Felix.Wyss@inin.com; x-ms-exchange-messagesentrepresentingtype: 1 x-originating-ip: [89.217.139.158] x-microsoft-exchange-diagnostics: 1; CY1PR0501MB1577; 5:6sp5ECTNtrMxRZJ6K6LwFQCUajrqYstBp5sZXW38GJR1VeyUpIWwFrMl18xyPW/VDHqK9P2xoBJT2Rhc2pG9Z+jJWXmEIDrueRgQ8nVfO4tuecLHgP18e6aGIz+79lqiMl6/4Xy+0NFkBAfz6JWYEA==; 24:QMOL8ljKy//Nv+aRz1RcqPFBrPjHry661YyBfcvnsjaF3K81HDIANsaqF9FEfXrtDe00pcPS6y/eT5Nj8yi+zhSw12wILy7KYTnPCkEZQcs=; 20:vESjxRIEyiBZ0aUwUgcCDSI7nU2DjYhCFBrSwpqEiowUz7SZSQ7eNy14eflkO9K6G4COEtmD1PKHMeKNAA2+0Q== x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:; SRVR:CY1PR0501MB1577; UriScan:; BCL:0; PCL:0; RULEID:; SRVR:CY1PR0501MB1738; inin-custom-wld: WL-D x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:; x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(601004)(5005006)(3002001); SRVR:CY1PR0501MB1577; BCL:0; PCL:0; RULEID:; SRVR:CY1PR0501MB1577; x-forefront-prvs: 06607E485E x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(24454002)(189002)(199003)(377454003)(164054003)(77156002)(19617315012)(2656002)(46102003)(101416001)(5002640100001)(33656002)(93886004)(19625215002)(19627405001)(62966003)(5003600100002)(5001770100001)(76176999)(5001960100002)(5001860100001)(87936001)(54356999)(86362001)(5001830100001)(77096005)(16236675004)(99286002)(68736005)(40100003)(76576001)(122556002)(50986999)(64706001)(81156007)(66066001)(106116001)(106356001)(10400500002)(2900100001)(74316001)(102836002)(15975445007)(2950100001)(97736004)(105586002)(19580395003)(189998001)(19580405001)(92566002)(4001540100001)(18121605002); DIR:OUT; SFP:1101; SCL:1; SRVR:CY1PR0501MB1577; H:CY1PR0501MB1579.namprd05.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; MX:1; A:1; LANG:en; received-spf: None (protection.outlook.com: inin.com does not designate permitted sender hosts) Content-Type: multipart/alternative; boundary="_000_CY1PR0501MB1579D163920667C126D223C2EB740CY1PR0501MB1579_" MIME-Version: 1.0 X-MS-Exchange-CrossTenant-originalarrivaltime: 06 Aug 2015 10:36:44.6632 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 8d07eb62-a903-4bae-bcc2-66c244e76b27 X-MS-Exchange-Transport-CrossTenantHeadersStamped: CY1PR0501MB1577 X-Microsoft-Exchange-Diagnostics: 1; CY1PR0501MB1738; 2:KaDmf2Rr+kubQINYlcyiOJ+kpGF352NwCW337pe7RtyvIvlZCnxJa6K3lzue4O6KT7HD/tQAQUywiqJXI/NSwa/8kj62TaZYWcOyfvuUqKNTIAD4kq/I1coJOu41GpglQYwaW3nJmc49YEUBN1+SNFqZuuNYcemkV+uTNW6tqOQ=; 3:Z3FeTeXRexvXVsNvETzYrinU/kwaqD/drw2NSLePdWAItvvPzoXrgs7q2dnJmaEqSZNYxHi4nZxmYbEAJsjQkZqRJcqr0YgIDukCrv6vSlWd0OZ1nkAtM8lYdiGbDkYt3JFACUD/ud7ILQy9y4wF/Q==; 25:ZF09lnEeYisEoWKx8OnHD0ykM0CbUxAO08Sxk8+I/gdet2UOvroJm/tT/mLNgCCSibmfJ52jFYz3c1pJIBHOJaOuEtyq7DDG6XOk8z2DGSkR+8s0kgoAF26rG/pTaucOAwbx2n9EIzy3/ezdFpUkwXfxyjL+gxWCh0TFJvRr/OnUVyvE9igMwMGA9PPv3/T+4ROxVkEE1L0jlELfJ5NH/FAqHaUI4z5X+rLIr8NrA84aSXlZMRtYLg/4G71v9hLK; 23:ezMG6XlTXtdSHVYk9A0sxVvglEikd2a/S92gDWauFMwTOayfRHtd+lRMoYrQaSChavFQ1uNDx7dAovtU+kCx+1o5Z+WT5Z72QPzzsAjVsVO/c81sYvEkIuGY8FMylUi5umjfWLXCQxebSd4203hIVK0Egm7tdyMfEPLT+BBQu35uebL+EQnOrOTVVrjG8B2BNGjMLytyQdbe/CiKcYHOr3WYofQZuaMChb938+EaUUyVtCOrKJGNlsnTOtgz2acW X-OriginatorOrg: inin.com Archived-At: Cc: "" Subject: Re: [rtcweb] What the gateway draft should say about mux/non-mux X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 06 Aug 2015 10:37:08 -0000 --_000_CY1PR0501MB1579D163920667C126D223C2EB740CY1PR0501MB1579_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable Why shouldn't the gateway be required to do the mux/demux? Making the WebR= TC endpoints a lot more complex just so the legacy interop might potentiall= y be a teeny-tiny bit easier makes no sense IMHO. Actually, the gateway wo= uld not be able to do "end-to-end" pass-through anyway as legacy equipment = will either be unencrypted or use SDES (RFC#4568) for key exchange. So the= gateway will have to perform DTLS-SRTP to SDES-SRTP transcryption--which a= lready is way more hassle than RTP/RTCP mux/demux. --Felix ________________________________ From: rtcweb on behalf of Christer Holmberg Sent: Thursday, August 6, 2015 05:51 To: Asveren, Tolga; Schwarz, Albrecht (Albrecht); Roman Shpount; Rauschenba= ch, Uwe (Nokia - DE/Munich) Cc: Subject: Re: [rtcweb] What the gateway draft should say about mux/non-mux Hi, No matter whether the gateway supports RTP/RTCP mux or not, there are cases= where the legacy network/endpoints will not use RTP/RTCP mux, so I guess p= eople then would want to be able to negotiate non-mux =93end-to-end=94, rat= her than having the gateway to demux/mux RTP and RTCP. Regards, Christer From: Asveren, Tolga [mailto:tasveren@sonusnet.com] Sent: 6. elokuuta 2015 12:18 To: Schwarz, Albrecht (Albrecht); Roman Shpount; Rauschenbach, Uwe (Nokia -= DE/Munich) Cc: ext Eric Rescorla; Christer Holmberg; Bernard Aboba; Subject: Re: [rtcweb] What the gateway draft should say about mux/non-mux Why should we consider 3GPP the sole "owner/user" of the term/entity WebRTC= -GW? I think it has a much more general meaning and use in practice. It can= refer to many different types of elements which can be deployed in many di= fferent environments, hence any attempt to define it strictly/restrict its = capabilities are futile IMHO. Thanks, Tolga ________________________________ From: Schwarz, Albrecht (Albrecht) > Sent: Thursday, August 6, 2015 2:44 AM To: Asveren, Tolga; Roman Shpount; Rauschenbach, Uwe (Nokia - DE/Munich) Cc: ext Eric Rescorla; Christer Holmberg; Bernard Aboba; > Subject: RE: [rtcweb] What the gateway draft should say about mux/non-mux The concerned 3GPP WebRTC gateway (3GPP 23.334/29.334) supports already RTP= /RTCP transport multiplexing (since 3GPP Release 12), i.e. should not be th= e limiting factor in this discussion. For ones interested in the RTCP port allocation rules, see H.248.57: https://www.itu.int/rec/dologin_pub.asp?lang=3De&id=3DT-REC-H.248.57-201410= -I!!PDF-E&type=3Ditems Clause 7 describes RTP/RTCP transport multiplexing. ITU-T H.248.57 is alrea= dy supported by 3GPP 29.334. The rationale behind the =93optional tagging=94 by 23.228 is a third reason= , beyond >1. Using different QOS settings for RTCP vs RTP >2. Sending RTCP to a different device from RTP Don=92t want to go in the 3GPP specific details, but it has nothing to do w= ith the 3GPP UE-embedded WebRTC client nor any constraints by 3GPP WebRTC g= ateways. Thus, a WebRTC gateway MUST support RTP/RTCP transport multiplexing due to = its purpose in interworking support. Regards, Albrecht From: Asveren, Tolga [mailto:tasveren@sonusnet.com] Sent: Mittwoch, 5. August 2015 19:47 To: Roman Shpount; Rauschenbach, Uwe (Nokia - DE/Munich) Cc: ext Eric Rescorla; Schwarz, Albrecht (Albrecht); Christer Holmberg; Ber= nard Aboba; > Subject: RE: [rtcweb] What the gateway draft should say about mux/non-mux i- I humbly disagree that using different QoS RTCP/RTP, e.g. different Diff= Serv values , should be dismissed. ii- Let me also add another reason why no-rtcp-mux may be needed: Implement= ation difficulties in certain GWs. Considering that there is already a negotiation mechanism for rtcp-mux supp= ort, that it can be de-facto mandated by the choice of browsers for Interne= t, I think what Christer/Albrecht suggested is the right way to move forwar= d: provide clarifications for vague points. I don=92t understand why lack o= f clarity in existing specifications should cause imposing restrictions. Th= is would be akin to dropping a feature due to a bug. In this case, the =93b= ug=94 is lack of clarity in normative specifications and it can be addresse= d by further specification. Thanks, Tolga From: Roman Shpount [mailto:roman@telurix.com] Sent: Wednesday, August 05, 2015 12:29 PM To: Rauschenbach, Uwe (Nokia - DE/Munich) > Cc: ext Eric Rescorla >; Schwarz, Albrech= t (Albrecht) >; Asveren, Tolga >; Christer Holmberg >; Bernard Aboba >; > > Subject: Re: [rtcweb] What the gateway draft should say about mux/non-mux On Wed, Aug 5, 2015 at 4:47 AM, Rauschenbach, Uwe (Nokia - DE/Munich) > wrote: Media gateway implementations according to 3GPP TS 23.228 may not support r= tcp-mux, as rtcp-mux is optional there. So if we drop non-mux support from web browsers, those media gateways that = have not implemented rtcp-mux will stop interoperating. First of all, do you know of any WebRTC to IMS gateways that do not impleme= nt rtcp-mux on the WebRTC side? I strongly suspect there are none. Second, the only reasons not to use rtcp-mux that I can think of are the fo= llowing: 1. Using different QOS settings for RTCP vs RTP 2. Sending RTCP to a different device from RTP I do not think the first use case warrants making rtcp-mux optional, since,= practically no one does this. Second use case is also fairly marginal. Plus it can be handled by the gate= way which can send RTCP to one device and RTP to another. So, unless someone can come up with a use case why RTP and RTCP should use = different transports, I think rtcp-mux should be mandatory. Regards, ______________ Roman Shpount --_000_CY1PR0501MB1579D163920667C126D223C2EB740CY1PR0501MB1579_ Content-Type: text/html; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable

Why shouldn't the gateway be required to do the mux/demux?  Making = the WebRTC endpoints a lot more complex just so the legacy interop might po= tentially be a teeny-tiny bit easier makes no sense IMHO.  Actually, t= he gateway would not be able to do "end-to-end" pass-through anyway as legacy equipment will either be unencrypted or use = SDES (RFC#4568) for key exchange.  So the gateway will have to perform= DTLS-SRTP to SDES-SRTP transcryption--which already is way more hassle tha= n RTP/RTCP mux/demux.


--Felix


From: rtcweb <rtcweb-b= ounces@ietf.org> on behalf of Christer Holmberg <christer.holmberg@er= icsson.com>
Sent: Thursday, August 6, 2015 05:51
To: Asveren, Tolga; Schwarz, Albrecht (Albrecht); Roman Shpount; Rau= schenbach, Uwe (Nokia - DE/Munich)
Cc: <rtcweb@ietf.org>
Subject: Re: [rtcweb] What the gateway draft should say about mux/no= n-mux
 

Hi,

 

No matter whether the gateway s= upports RTP/RTCP mux or not, there are cases where the legacy network/endpo= ints will not use RTP/RTCP mux, so I guess people then would want to be able to negotiate non-mux =93end-to-end=94, rather than having = the gateway to demux/mux RTP and RTCP.

 

Regards,

 

Christer

 

From:= Asveren, Tolga [mailto:tasveren@sonusnet.com]
Sent: 6. elokuuta 2015 12:18
To: Schwarz, Albrecht (Albrecht); Roman Shpount; Rauschenbach, Uwe (= Nokia - DE/Munich)
Cc: ext Eric Rescorla; Christer Holmberg; Bernard Aboba; <rtcweb@= ietf.org>
Subject: Re: [rtcweb] What the gateway draft should say about mux/no= n-mux

 

Why should we consider 3GPP the sole= "owner/user" of the term/entity WebRTC-GW? I think it has a much= more general meaning and use in practice. It can refer to many different types of elements which can be deployed in many different environments, he= nce any attempt to define it strictly/restrict its capabilities are futile = IMHO.

 

Thanks,

Tolga

 

From: S= chwarz, Albrecht (Albrecht) <albrecht.sch= warz@alcatel-lucent.com>
Sent: Thursday, August 6, 2015 2:44 AM
To: Asveren, Tolga; Roman Shpount; Rauschenbach, Uwe (Nokia - DE/Mun= ich)
Cc: ext Eric Rescorla; Christer Holmberg; Bernard Aboba; <rtcweb@ietf.org>
Subject: RE: [rtcweb] What the gateway draft should say about mux/no= n-mux

 

The concerned 3GPP WebRTC gateway (3GPP 23.334/29.= 334) supports already RTP/RTCP transport multiplexing (since 3GPP Release 1= 2), i.e. should not be the limiting factor in this discussion.

For ones interested in the RTCP port allocation ru= les, see H.248.57:

https://www.itu.int/rec/dologin_pub.asp?lang=3De&id= =3DT-REC-H.248.57-201410-I!!PDF-E&type=3Ditems

Clause 7 describes RTP/RTCP transport multiplexing= . ITU-T H.248.57 is already supported by 3GPP 29.334.

 

The rationale behind the =93optional tagging=94 by= 23.228 is a third reason, beyond=

&g= t;1. Using different QOS settings for RTCP vs RTP

&g= t;2. Sending RTCP to a different device from RTP

 

Don=92t want to go in the 3GPP specific details, b= ut it has nothing to do with the 3GPP UE-embedded WebRTC client nor any con= straints by 3GPP WebRTC gateways.=

 

Thus, a WebRTC gateway MUST support RTP/RTCP trans= port multiplexing due to its purpose in interworking support.

 

Regards,=

Albrecht=

 

 

F= rom: Asveren, Tolga [mailto:tasveren@sonusnet.com]
Sent: Mittwoch, 5. August 2015 19:47
To: Roman Shpount; Rauschenbach, Uwe (Nokia - DE/Munich)
Cc: ext Eric Rescorla; Schwarz, Albrecht (Albrecht); Christer Holmbe= rg; Bernard Aboba; <rtcweb@ietf.org>
Subject: RE: [rtcweb] What the gateway draft should say about mux/no= n-mux

 

i= - I humbly disagree that using different QoS RTCP/RTP, e.g. different DiffS= erv values , should be dismissed.=

i= i- Let me also add another reason why no-rtcp-mux may be needed: Implementa= tion difficulties in certain GWs.=

&= nbsp;

C= onsidering that there is already a negotiation mechanism for rtcp-mux suppo= rt, that it can be de-facto mandated by the choice of browsers for Internet, I think what Christer/Albrecht suggested is the right way to= move forward: provide clarifications for vague points. I don=92t understan= d why lack of clarity in existing specifications should cause imposing rest= rictions. This would be akin to dropping a feature due to a bug. In this case, the =93bug=94 is lack of clarity in = normative specifications and it can be addressed by further specification.<= /span>

&= nbsp;

T= hanks,

T= olga

&= nbsp;

= From: Roman Shpount [<= a style=3D"color: blue; text-decoration: underline;" href=3D"mailto:roman@t= elurix.com">mailto:roman@telurix.com]
Sent: Wednesday, August 05, 2015 12:29 PM
To: Rauschenbach, Uwe (Nokia - DE/Munich) <= uwe.rauschenbach@nokia.com>
Cc: ext Eric Rescorla <ekr@rtfm.com>; Schwarz, Alb= recht (Albrecht) <albrecht.schwarz@alcate= l-lucent.com>; Asveren, Tolga <tasveren@sonusnet.com>; Christe= r Holmberg <christer.holmberg@ericsson.com>; Bernard Aboba <bernard.aboba@gmail.com>; <= rtcweb@ietf.org> <rtcweb@ietf.org> Subject: Re: [rtcweb] What the gateway draft should say about mux/no= n-mux

&n= bsp;

On= Wed, Aug 5, 2015 at 4:47 AM, Rauschenbach, Uwe (Nokia - DE/Munich) <uwe.rauschenbach@nokia.com> wrote:

Media= gateway implementations according to 3GPP TS 23.228 may not support rtcp-mux, as= rtcp-mux is optional there.

So if= we drop non-mux support from web browsers, those media gateways that have = not implemented rtcp-mux will stop interoperating. 

&n= bsp;

&n= bsp;

Fi= rst of all, do you know of any WebRTC to IMS gateways that do not implement= rtcp-mux on the WebRTC side? I strongly suspect there are none.

&n= bsp;

Se= cond, the only reasons not to use rtcp-mux that I can think of are the foll= owing:

&n= bsp;

1.= Using different QOS settings for RTCP vs RTP

2.= Sending RTCP to a different device from RTP

&n= bsp;

I = do not think the first use case warrants making rtcp-mux optional, since, p= ractically no one does this.

Se= cond use case is also fairly marginal. Plus it can be handled by the gatewa= y which can send RTCP to one device and RTP to another.

&n= bsp;

So= , unless someone can come up with a use case why RTP and RTCP should use di= fferent transports, I think rtcp-mux should be mandatory.

&n= bsp;

Re= gards,

__= ____________

Ro= man Shpount

--_000_CY1PR0501MB1579D163920667C126D223C2EB740CY1PR0501MB1579_-- From nobody Thu Aug 6 04:44:24 2015 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 42AF11B2D9C for ; Thu, 6 Aug 2015 04:44:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id M8KswGPi34y1 for ; Thu, 6 Aug 2015 04:44:17 -0700 (PDT) Received: from na01-by2-obe.outbound.protection.outlook.com (mail-by2on0100.outbound.protection.outlook.com [207.46.100.100]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id F35D21B2DC3 for ; Thu, 6 Aug 2015 04:44:16 -0700 (PDT) Received: from SN1PR0301MB1550.namprd03.prod.outlook.com (10.162.129.156) by SN1PR0301MB1648.namprd03.prod.outlook.com (10.162.130.142) with Microsoft SMTP Server (TLS) id 15.1.225.19; Thu, 6 Aug 2015 11:44:15 +0000 Received: from SN1PR0301MB1551.namprd03.prod.outlook.com (10.162.129.157) by SN1PR0301MB1550.namprd03.prod.outlook.com (10.162.129.156) with Microsoft SMTP Server (TLS) id 15.1.225.19; Thu, 6 Aug 2015 11:44:13 +0000 Received: from SN1PR0301MB1551.namprd03.prod.outlook.com ([10.162.129.157]) by SN1PR0301MB1551.namprd03.prod.outlook.com ([10.162.129.157]) with mapi id 15.01.0225.018; Thu, 6 Aug 2015 11:44:13 +0000 From: "Asveren, Tolga" To: "Wyss, Felix" , Christer Holmberg , "Schwarz, Albrecht (Albrecht)" , Roman Shpount , "Rauschenbach, Uwe (Nokia - DE/Munich)" Thread-Topic: [rtcweb] What the gateway draft should say about mux/non-mux Thread-Index: AQHQy8DcUgzWwtVCmk+8q67BCzjC45316kQQgAAD5oCAAACVsIAAAj2AgAPw2gCAAEFTAIAC/BgAgACAxgCAABQlsIAA2x8AgAAp4WeAAApBgIAADKQAgAARK8A= Date: Thu, 6 Aug 2015 11:44:12 +0000 Message-ID: References: <7594FB04B1934943A5C02806D1A2204B348E29DA@ESESSMB209.ericsson.se> <67196805-ED4E-49EA-83AA-3F4C37B5BC50@gmail.com> <7594FB04B1934943A5C02806D1A2204B348E2D52@ESESSMB209.ericsson.se> <56C2F665D49E0341B9DF5938005ACDF8196FF3ED@DEMUMBX005.nsn-intra.net> <56C2F665D49E0341B9DF5938005ACDF8196FF450@DEMUMBX005.nsn-intra.net> <786615F3A85DF44AA2A76164A71FE1AC7ADB690D@FR711WXCHMBA03.zeu.alcatel-lucent.com> <56C2F665D49E0341B9DF5938005ACDF81970EDC1@DEMUMBX005.nsn-intra.net> , <786615F3A85DF44AA2A76164A71FE1AC7ADB9E25@FR711WXCHMBA03.zeu.alcatel-lucent.com> , <7594FB04B1934943A5C02806D1A2204B348EAB88@ESESSMB209.ericsson.se> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=tasveren@sonusnet.com; x-originating-ip: [50.182.164.80] x-microsoft-exchange-diagnostics: 1; SN1PR0301MB1550; 5:4DbZau86XJEUIZogU/EPmdQmDKpS0jqnJz4gXiFJ24G5ULhuwkfu5PjxaDjLwQnoCk8DIeh5RH72m8ONkm8gtQodYbN6DYD2UiZx/8vN2TYhLbwp34d+J0XVHKb87mhpD/zOlDVw5jgRGOwu0J4otQ==; 24:iGqC3VVXU4key6sK/jqat6V4akIhJDLv53U+umtQE/0Zzq9MZne5Yua63mmtDnZL/FGmua7gudlIPtWiiSmQ1pCRWYoVfhkl+GtO1W9P578=; 20:SdJfxh5Du2yoInqxguUZfjWX45OflgUSed1yUiKfsChFdUszpDEXraPUyekDjR12VT4D8N69CO6jbSal4fhwjw== x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:; SRVR:SN1PR0301MB1550; UriScan:; BCL:0; PCL:0; RULEID:; SRVR:SN1PR0301MB1648; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(108003899814671); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(601004)(5005006)(3002001); SRVR:SN1PR0301MB1550; BCL:0; PCL:0; RULEID:; SRVR:SN1PR0301MB1550; x-forefront-prvs: 06607E485E x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(189002)(199003)(377454003)(164054003)(24454002)(2950100001)(105586002)(5001830100001)(5001860100001)(2900100001)(33656002)(5003600100002)(76176999)(64706001)(66066001)(54356999)(101416001)(19580405001)(5001960100002)(189998001)(19609705001)(5002640100001)(102836002)(16236675004)(15975445007)(10400500002)(77096005)(74316001)(97736004)(81156007)(68736005)(76576001)(4001540100001)(5001770100001)(19625215002)(92566002)(106356001)(19580395003)(46102003)(106116001)(62966003)(93886004)(77156002)(99286002)(50986999)(122556002)(19300405004)(40100003)(86362001)(2656002)(87936001)(19617315012)(7059030); DIR:OUT; SFP:1101; SCL:1; SRVR:SN1PR0301MB1550; H:SN1PR0301MB1551.namprd03.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; MX:1; A:1; LANG:en; received-spf: None (protection.outlook.com: sonusnet.com does not designate permitted sender hosts) Content-Type: multipart/alternative; boundary="_000_SN1PR0301MB155140ECC254F1E407BA54ECB2740SN1PR0301MB1551_" MIME-Version: 1.0 X-MS-Exchange-CrossTenant-originalarrivaltime: 06 Aug 2015 11:44:12.8397 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 29a671dc-ed7e-4a54-b1e5-8da1eb495dc3 X-MS-Exchange-Transport-CrossTenantHeadersStamped: SN1PR0301MB1550 X-Microsoft-Exchange-Diagnostics: 1; SN1PR0301MB1648; 2:iUqEfZVZwFguMkOptSVrS5xXw7Lh1avCcLMLZ144W/FqR/oRPjA15XdER2NoGG2eJz4eThzBHvF/BKyHmOuG5G5/anaC4OVSAmOrCrVSqR8g70UzaK2PPfAk95m8lMLOHc0RZJBG1W0DEjYHDNjb7j9vf2XOV15DRD/nZNUGjhk=; 3:sGpAM5ZrKiRWLdPd6/RkiTxEfh9+ISvjKioWqgdBZnwphvnwsHDTk0cbs67RfNS6OnDkTyEGUryVV9ZVhjAO5yeqrabr8LyREe/ZS2YHfiUa1Xja9yb+mMEHS81avM1+MWvn8g1UpuqLv6R+nPMThA==; 25:kcVoCu2V/32XfvRW0AKoR6lrNdD797AAriY6gqGPsBhlW8+PAFS1/GuO5CfJi00Q2bS2ww8RR4b4wbG5K3hdeeTpLaQyM+2vq30iYTvhzf7Ds5AB1cVqsHY+kRfgC03hkUgB/kAI+GE8twQXciQtnrkF3YZpKcTeW/bj0jGv1yWB4Ea3q3Fg5KtKswaOatuFlksbDNZ6m/1gxdtUfonAIXiDb2oVISxlGOe4iOG6wDU+Xd1yvonNuFrO/Lecw/zoosiJLYxwc8opII0Kr07+Zw==; 23:Ld7O9JW6d9izYKBSMhW5jB4UxOmPjJJASi2KrdrF7SF1Oi7GHP1Ei5SbxrqeZb0jFQ3Vcp+ecruyCQPHluArZTYxyW1qpIBb1gPsOneKOGMjunnZcSXTMJAJ1L5mWB3s3YIshyd/EQDhzt0+bxYVJ8xkkirTL7L/BR+m7NexTg5ZE88q8lrefbvbGo4/JfjKzdpPVhS2al1unMNIO+hX5zqcsJMwWnIX+UPN8a19BcyxblUYzzbL6zz5GYTxr6yG X-OriginatorOrg: sonusnet.com Archived-At: Cc: "" Subject: Re: [rtcweb] What the gateway draft should say about mux/non-mux X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 06 Aug 2015 11:44:23 -0000 --_000_SN1PR0301MB155140ECC254F1E407BA54ECB2740SN1PR0301MB1551_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable These assumptions are not necessarily true in a universal sense (like almos= t any other assumption about different deployment models). Furthermore, and more importantly, there is nothing mandating WebRTC endpoi= nts to support non-rtcp-mux. It is a negotiated functionality. Any entity c= an enforce rtcp-mux as a local policy. The issue with supporting non-rtcp-mux seems to be lack of clarity in the r= elevant specifications. Fixing this -regardless of the outcome of any other= discussion- seems to be prudent IMHO. Thanks, Tolga From: Wyss, Felix [mailto:Felix.Wyss@inin.com] Sent: Thursday, August 06, 2015 6:37 AM To: Christer Holmberg ; Asveren, Tolga ; Schwarz, Albrecht (Albrecht) ; Roman Shpount ; Rauschenbach, Uwe (Nokia -= DE/Munich) Cc: Subject: Re: [rtcweb] What the gateway draft should say about mux/non-mux Why shouldn't the gateway be required to do the mux/demux? Making the WebR= TC endpoints a lot more complex just so the legacy interop might potentiall= y be a teeny-tiny bit easier makes no sense IMHO. Actually, the gateway wo= uld not be able to do "end-to-end" pass-through anyway as legacy equipment = will either be unencrypted or use SDES (RFC#4568) for key exchange. So the= gateway will have to perform DTLS-SRTP to SDES-SRTP transcryption--which a= lready is way more hassle than RTP/RTCP mux/demux. --Felix ________________________________ From: rtcweb > on b= ehalf of Christer Holmberg > Sent: Thursday, August 6, 2015 05:51 To: Asveren, Tolga; Schwarz, Albrecht (Albrecht); Roman Shpount; Rauschenba= ch, Uwe (Nokia - DE/Munich) Cc: > Subject: Re: [rtcweb] What the gateway draft should say about mux/non-mux Hi, No matter whether the gateway supports RTP/RTCP mux or not, there are cases= where the legacy network/endpoints will not use RTP/RTCP mux, so I guess p= eople then would want to be able to negotiate non-mux "end-to-end", rather = than having the gateway to demux/mux RTP and RTCP. Regards, Christer From: Asveren, Tolga [mailto:tasveren@sonusnet.com] Sent: 6. elokuuta 2015 12:18 To: Schwarz, Albrecht (Albrecht); Roman Shpount; Rauschenbach, Uwe (Nokia -= DE/Munich) Cc: ext Eric Rescorla; Christer Holmberg; Bernard Aboba; > Subject: Re: [rtcweb] What the gateway draft should say about mux/non-mux Why should we consider 3GPP the sole "owner/user" of the term/entity WebRTC= -GW? I think it has a much more general meaning and use in practice. It can= refer to many different types of elements which can be deployed in many di= fferent environments, hence any attempt to define it strictly/restrict its = capabilities are futile IMHO. Thanks, Tolga ________________________________ From: Schwarz, Albrecht (Albrecht) > Sent: Thursday, August 6, 2015 2:44 AM To: Asveren, Tolga; Roman Shpount; Rauschenbach, Uwe (Nokia - DE/Munich) Cc: ext Eric Rescorla; Christer Holmberg; Bernard Aboba; > Subject: RE: [rtcweb] What the gateway draft should say about mux/non-mux The concerned 3GPP WebRTC gateway (3GPP 23.334/29.334) supports already RTP= /RTCP transport multiplexing (since 3GPP Release 12), i.e. should not be th= e limiting factor in this discussion. For ones interested in the RTCP port allocation rules, see H.248.57: https://www.itu.int/rec/dologin_pub.asp?lang=3De&id=3DT-REC-H.248.57-201410= -I!!PDF-E&type=3Ditems Clause 7 describes RTP/RTCP transport multiplexing. ITU-T H.248.57 is alrea= dy supported by 3GPP 29.334. The rationale behind the "optional tagging" by 23.228 is a third reason, be= yond >1. Using different QOS settings for RTCP vs RTP >2. Sending RTCP to a different device from RTP Don't want to go in the 3GPP specific details, but it has nothing to do wit= h the 3GPP UE-embedded WebRTC client nor any constraints by 3GPP WebRTC gat= eways. Thus, a WebRTC gateway MUST support RTP/RTCP transport multiplexing due to = its purpose in interworking support. Regards, Albrecht From: Asveren, Tolga [mailto:tasveren@sonusnet.com] Sent: Mittwoch, 5. August 2015 19:47 To: Roman Shpount; Rauschenbach, Uwe (Nokia - DE/Munich) Cc: ext Eric Rescorla; Schwarz, Albrecht (Albrecht); Christer Holmberg; Ber= nard Aboba; > Subject: RE: [rtcweb] What the gateway draft should say about mux/non-mux i- I humbly disagree that using different QoS RTCP/RTP, e.g. different Diff= Serv values , should be dismissed. ii- Let me also add another reason why no-rtcp-mux may be needed: Implement= ation difficulties in certain GWs. Considering that there is already a negotiation mechanism for rtcp-mux supp= ort, that it can be de-facto mandated by the choice of browsers for Interne= t, I think what Christer/Albrecht suggested is the right way to move forwar= d: provide clarifications for vague points. I don't understand why lack of = clarity in existing specifications should cause imposing restrictions. This= would be akin to dropping a feature due to a bug. In this case, the "bug" = is lack of clarity in normative specifications and it can be addressed by f= urther specification. Thanks, Tolga From: Roman Shpount [mailto:roman@telurix.com] Sent: Wednesday, August 05, 2015 12:29 PM To: Rauschenbach, Uwe (Nokia - DE/Munich) > Cc: ext Eric Rescorla >; Schwarz, Albrech= t (Albrecht) >; Asveren, Tolga >; Christer Holmberg >; Bernard Aboba >; > > Subject: Re: [rtcweb] What the gateway draft should say about mux/non-mux On Wed, Aug 5, 2015 at 4:47 AM, Rauschenbach, Uwe (Nokia - DE/Munich) > wrote: Media gateway implementations according to 3GPP TS 23.228 may not support r= tcp-mux, as rtcp-mux is optional there. So if we drop non-mux support from web browsers, those media gateways that = have not implemented rtcp-mux will stop interoperating. First of all, do you know of any WebRTC to IMS gateways that do not impleme= nt rtcp-mux on the WebRTC side? I strongly suspect there are none. Second, the only reasons not to use rtcp-mux that I can think of are the fo= llowing: 1. Using different QOS settings for RTCP vs RTP 2. Sending RTCP to a different device from RTP I do not think the first use case warrants making rtcp-mux optional, since,= practically no one does this. Second use case is also fairly marginal. Plus it can be handled by the gate= way which can send RTCP to one device and RTP to another. So, unless someone can come up with a use case why RTP and RTCP should use = different transports, I think rtcp-mux should be mandatory. Regards, ______________ Roman Shpount --_000_SN1PR0301MB155140ECC254F1E407BA54ECB2740SN1PR0301MB1551_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

These assumptions are not necessarily= true in a universal sense (like almost any other assumption about differen= t deployment models).

 

Furthermore, and more importantly, th= ere is nothing mandating WebRTC endpoints to support non-rtcp-mux. It is a = negotiated functionality. Any entity can enforce rtcp-mux as a local policy.

 

The issue with supporting non-rtcp-mu= x seems to be lack of clarity in the relevant specifications. Fixing this &= #8211;regardless of the outcome of any other discussion- seems to be prudent IMHO.

 

Thanks,

Tolga

 

From: Wyss, Felix [mailto:Felix.Wyss= @inin.com]
Sent: Thursday, August 06, 2015 6:37 AM
To: Christer Holmberg <christer.holmberg@ericsson.com>; Asvere= n, Tolga <tasveren@sonusnet.com>; Schwarz, Albrecht (Albrecht) <al= brecht.schwarz@alcatel-lucent.com>; Roman Shpount <roman@telurix.com&= gt;; Rauschenbach, Uwe (Nokia - DE/Munich) <uwe.rauschenbach@nokia.com&g= t;
Cc: <rtcweb@ietf.org> <rtcweb@ietf.org>
Subject: Re: [rtcweb] What the gateway draft should say about mux/no= n-mux

 

Why shouldn't the gateway be required to do the m= ux/demux?  Making the WebRTC endpoints a lot more complex just so the = legacy interop might potentially be a teeny-tiny bit easier makes no sense IMHO.  Actually, the gateway would not be able = to do "end-to-end" pass-through anyway as legacy equipment will e= ither be unencrypted or use SDES (RFC#4568) for key exchange.  So the = gateway will have to perform DTLS-SRTP to SDES-SRTP transcryption--which already is way more hassle than RTP/RTCP mux/demux.

 

--Felix

 

From: rtcweb <= rtcweb-bounces@ietf.org> on behalf of Christer Holmberg <christer.holmberg@ericsson.com>
Sent: Thursday, August 6, 2015 05:51
To: Asveren, Tolga; Schwarz, Albrecht (Albrecht); Roman Shpount; Rau= schenbach, Uwe (Nokia - DE/Munich)
Cc: <rtcweb@ietf.org> Subject: Re: [rtcweb] What the gateway draft should say about mux/no= n-mux

 

Hi,

 

No matter whether the gateway = supports RTP/RTCP mux or not, there are cases where the legacy network/endp= oints will not use RTP/RTCP mux, so I guess people then would want to be able to negotiate non-mux “end-to-end”, = rather than having the gateway to demux/mux RTP and RTCP.

 

Regards,

 

Christer

 

From: A= sveren, Tolga [mailto:tasveren@son= usnet.com]
Sent: 6. elokuuta 2015 12:18
To: Schwarz, Albrecht (Albrecht); Roman Shpount; Rauschenbach, Uwe (= Nokia - DE/Munich)
Cc: ext Eric Rescorla; Christer Holmberg; Bernard Aboba; <rtcweb@ietf.org>
Subject: Re: [rtcweb] What the gateway draft should say about mux/no= n-mux

 =

Why should we consider 3GPP the sole "owner/= user" of the term/entity WebRTC-GW? I think it has a much more general= meaning and use in practice. It can refer to many different types of elements which can be deployed in many different environments, he= nce any attempt to define it strictly/restrict its capabilities are futile = IMHO.

 

Thanks,

Tolga

&nbs= p;

From: Schwarz, Albrecht (Albrecht) <albrecht.schwarz@alcatel-lucent.com>
Sent: Thursday, August 6, 2015 2:44 AM
To: Asveren, Tolga; Roman Shpount; Rauschenbach, Uwe (Nokia - DE/Mun= ich)
Cc: ext Eric Rescorla; Christer Holmberg; Bernard Aboba; <rtcweb@ietf.org>
Subject: RE: [rtcweb] What the gateway draft should say about mux/no= n-mux

&nbs= p;

The concerned 3GPP WebRTC gateway (3GPP 23.334/29.33= 4) supports already RTP/RTCP transport multiplexing (since 3GPP Release 12)= , i.e. should not be the limiting factor in this discussion.

For ones interested in the RTCP port allocation rule= s, see H.248.57:

https://www.itu.int/rec/dologin_pu= b.asp?lang=3De&id=3DT-REC-H.248.57-201410-I!!PDF-E&type=3Ditems

Clause 7 describes RTP/RTCP transport multiplexing. = ITU-T H.248.57 is already supported by 3GPP 29.334.

 

The rationale behind the “optional taggingR= 21; by 23.228 is a third reason, beyond

>1. Using different QOS settings for RTCP vs R= TP

>2. Sending RTCP to a different device from RT= P

 

Don’t want to go in the 3GPP specific details,= but it has nothing to do with the 3GPP UE-embedded WebRTC client nor any c= onstraints by 3GPP WebRTC gateways.

 

Thus, a WebRTC gateway MUST support RTP/RTCP transpo= rt multiplexing due to its purpose in interworking support.

 

Regards,

Albrecht

 

 

From: A= sveren, Tolga [mailto:tasveren@son= usnet.com]
Sent: Mittwoch, 5. August 2015 19:47
To: Roman Shpount; Rauschenbach, Uwe (Nokia - DE/Munich)
Cc: ext Eric Rescorla; Schwarz, Albrecht (Albrecht); Christer Holmbe= rg; Bernard Aboba; <rtcweb@ietf.org>
Subject: RE: [rtcweb] What the gateway draft should say about mux/no= n-mux

 

i- I humbly disagree that usin= g different QoS RTCP/RTP, e.g. different DiffServ values , should be dismis= sed.

ii- Let me also add another re= ason why no-rtcp-mux may be needed: Implementation difficulties in certain = GWs.

 

Considering that there is alre= ady a negotiation mechanism for rtcp-mux support, that it can be de-facto m= andated by the choice of browsers for Internet, I think what Christer/Albrecht suggested is the right way to move forward:= provide clarifications for vague points. I don’t understand why lack= of clarity in existing specifications should cause imposing restrictions. = This would be akin to dropping a feature due to a bug. In this case, the “bug” is lack of clarity in no= rmative specifications and it can be addressed by further specification.=

 

Thanks,

Tolga

 

From: Roman Shpount [mailto:roman@telurix= .com]
Sent: Wednesday, August 05, 2015 12:29 PM
To: Rauschenbach, Uwe (Nokia - DE/Munich) <uwe.rauschenbach@nokia.com>
Cc: ext Eric Rescorla <ekr@rtfm.c= om>; Schwarz, Albrecht (Albrecht) <albrecht.schwarz@alcatel-lucent.com>; Asver= en, Tolga <tasveren@sonusnet.co= m>; Christer Holmberg <ch= rister.holmberg@ericsson.com>; Bernard Aboba <bernard.aboba@gmail.com>; <rtcweb@ietf.org> <rtcweb@ietf.org>
Subject: Re: [rtcweb] What the gateway draft should say about mux/no= n-mux

 

On Wed, Aug 5, 2015 at 4:47 AM, Rauschenbach, Uwe= (Nokia - DE/Munich) <uwe.rauschenbach@nokia.com> wrote:

Media gateway implementations acco= rding to 3GPP TS 23.228 may not support rtcp-mux, as rtcp-mux is optional there.<= /span>

So if we drop non-mux support from= web browsers, those media gateways that have not implemented rtcp-mux will= stop interoperating. 

 

 

First of all, do you know of any WebRTC to IMS ga= teways that do not implement rtcp-mux on the WebRTC side? I strongly suspec= t there are none.

 

Second, the only reasons not to use rtcp-mux that= I can think of are the following:

 

1. Using different QOS settings for RTCP vs RTP

2. Sending RTCP to a different device from RTP

 

I do not think the first use case warrants making= rtcp-mux optional, since, practically no one does this.<= /p>

Second use case is also fairly marginal. Plus it = can be handled by the gateway which can send RTCP to one device and RTP to = another.

 

So, unless someone can come up with a use case wh= y RTP and RTCP should use different transports, I think rtcp-mux should be = mandatory.

 

Regards,

______________

Roman Shpount

--_000_SN1PR0301MB155140ECC254F1E407BA54ECB2740SN1PR0301MB1551_-- From nobody Thu Aug 6 05:53:17 2015 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8A3101B2EB5 for ; Thu, 6 Aug 2015 05:53:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id h1_HBV6R0dL4 for ; Thu, 6 Aug 2015 05:53:05 -0700 (PDT) Received: from smtp001.apm-internet.net (smtp001-out.apm-internet.net [85.119.248.222]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 02ECA1B2EB3 for ; Thu, 6 Aug 2015 05:53:03 -0700 (PDT) Received: (qmail 80604 invoked from network); 6 Aug 2015 12:53:01 -0000 X-AV-Scan: clean X-APM-Authkey: 83769/0 7032 Received: from unknown (HELO zimbra003.verygoodemail.com) (85.119.248.218) by smtp001.apm-internet.net with SMTP; 6 Aug 2015 12:53:01 -0000 Received: from zimbra003.verygoodemail.com (localhost [127.0.0.1]) by zimbra003.verygoodemail.com (Postfix) with ESMTP id 65B1E18A0EBC; Thu, 6 Aug 2015 13:52:54 +0100 (BST) Received: from [10.106.111.176] (unknown [66.71.232.48]) by zimbra003.verygoodemail.com (Postfix) with ESMTPSA id 261CF18A05D9; Thu, 6 Aug 2015 13:52:53 +0100 (BST) Content-Type: multipart/alternative; boundary="Apple-Mail=_EB52858E-BD97-4803-B593-A18EE599DE0C" Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2102\)) From: tim panton In-Reply-To: Date: Thu, 6 Aug 2015 07:52:51 -0500 Message-Id: References: <7594FB04B1934943A5C02806D1A2204B348E29DA@ESESSMB209.ericsson.se> <67196805-ED4E-49EA-83AA-3F4C37B5BC50@gmail.com> <7594FB04B1934943A5C02806D1A2204B34 8E2D52@ESESSMB209.ericsson.se> <56C2F665D49E0341B9DF5938005ACDF8196FF3ED@DEMUMBX005.nsn-intra.net> <56C2F665D49E0341B9DF5938005ACDF8196FF450@DEMUMBX005.nsn-intra.net> <786615F3A85DF44AA2A76164A71FE1AC7ADB690D@FR711WXCHMBA03.zeu.alcatel-lucent.com> <56C2F665D49E0341B9DF5938005ACDF81970EDC1@DEMUMBX005.nsn-intra.net> <786615F3A85DF44AA2A76164A71FE1AC7ADB9E25@FR711WXCHMBA03.zeu.alcatel-lucent.com> <7594FB04B1934943A5C02806D1A2204B348EAB88@ESESSMB209.ericsson.se> To: "Asveren, Tolga" X-Mailer: Apple Mail (2.2102) Archived-At: Cc: "" Subject: Re: [rtcweb] What the gateway draft should say about mux/non-mux X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 06 Aug 2015 12:53:12 -0000 --Apple-Mail=_EB52858E-BD97-4803-B593-A18EE599DE0C Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 So we are positing the existence of a webRTC gateway designed to support = thousands of calls which does ICE and DTLS but the designer decided deliberately to double the number of ICE sessions = required and double the number of DTLS sessions (and key=20 generation costs) so that they can run RTCP (over ICE and DTLS) on a = separate port. In my estimation that=E2=80=99s one poor decision and should not be used as the basis of this (or any) standard.=20 I=E2=80=99d rather not support rtcp-no-mux as I see zero advantages in = having it. (I know theoretically it might be possible to get a RTCP packet through a congested net on a different port with a = separate diffserv setting but that just seems so contrived). Tim. > On 6 Aug 2015, at 06:44, Asveren, Tolga wrote: >=20 > These assumptions are not necessarily true in a universal sense (like = almost any other assumption about different deployment models). > =20 > Furthermore, and more importantly, there is nothing mandating WebRTC = endpoints to support non-rtcp-mux. It is a negotiated functionality. Any = entity can enforce rtcp-mux as a local policy.=20 > =20 > The issue with supporting non-rtcp-mux seems to be lack of clarity in = the relevant specifications. Fixing this =E2=80=93regardless of the = outcome of any other discussion- seems to be prudent IMHO. > =20 > Thanks, > Tolga > =20 > From: Wyss, Felix [mailto:Felix.Wyss@inin.com]=20 > Sent: Thursday, August 06, 2015 6:37 AM > To: Christer Holmberg ; Asveren, Tolga = ; Schwarz, Albrecht (Albrecht) = ; Roman Shpount = ; Rauschenbach, Uwe (Nokia - DE/Munich) = > Cc: > Subject: Re: [rtcweb] What the gateway draft should say about = mux/non-mux > =20 > Why shouldn't the gateway be required to do the mux/demux? Making the = WebRTC endpoints a lot more complex just so the legacy interop might = potentially be a teeny-tiny bit easier makes no sense IMHO. Actually, = the gateway would not be able to do "end-to-end" pass-through anyway as = legacy equipment will either be unencrypted or use SDES (RFC#4568) for = key exchange. So the gateway will have to perform DTLS-SRTP to = SDES-SRTP transcryption--which already is way more hassle than RTP/RTCP = mux/demux. > =20 > --Felix > =20 > From: rtcweb > on behalf of Christer Holmberg = > > Sent: Thursday, August 6, 2015 05:51 > To: Asveren, Tolga; Schwarz, Albrecht (Albrecht); Roman Shpount; = Rauschenbach, Uwe (Nokia - DE/Munich) > Cc: > > Subject: Re: [rtcweb] What the gateway draft should say about = mux/non-mux > =20 > Hi, > =20 > No matter whether the gateway supports RTP/RTCP mux or not, there are = cases where the legacy network/endpoints will not use RTP/RTCP mux, so I = guess people then would want to be able to negotiate non-mux = =E2=80=9Cend-to-end=E2=80=9D, rather than having the gateway to = demux/mux RTP and RTCP. > =20 > Regards, > =20 > Christer > =20 > From: Asveren, Tolga [mailto:tasveren@sonusnet.com = ]=20 > Sent: 6. elokuuta 2015 12:18 > To: Schwarz, Albrecht (Albrecht); Roman Shpount; Rauschenbach, Uwe = (Nokia - DE/Munich) > Cc: ext Eric Rescorla; Christer Holmberg; Bernard Aboba; = > > Subject: Re: [rtcweb] What the gateway draft should say about = mux/non-mux > =20 > Why should we consider 3GPP the sole "owner/user" of the term/entity = WebRTC-GW? I think it has a much more general meaning and use in = practice. It can refer to many different types of elements which can be = deployed in many different environments, hence any attempt to define it = strictly/restrict its capabilities are futile IMHO. > =20 > Thanks, > Tolga > =20 > From: Schwarz, Albrecht (Albrecht) = > > Sent: Thursday, August 6, 2015 2:44 AM > To: Asveren, Tolga; Roman Shpount; Rauschenbach, Uwe (Nokia - = DE/Munich) > Cc: ext Eric Rescorla; Christer Holmberg; Bernard Aboba; = > > Subject: RE: [rtcweb] What the gateway draft should say about = mux/non-mux > =20 > The concerned 3GPP WebRTC gateway (3GPP 23.334/29.334) supports = already RTP/RTCP transport multiplexing (since 3GPP Release 12), i.e. = should not be the limiting factor in this discussion.=20 > For ones interested in the RTCP port allocation rules, see H.248.57: > = https://www.itu.int/rec/dologin_pub.asp?lang=3De&id=3DT-REC-H.248.57-20141= 0-I!!PDF-E&type=3Ditems = > Clause 7 describes RTP/RTCP transport multiplexing. ITU-T H.248.57 is = already supported by 3GPP 29.334. > =20 > The rationale behind the =E2=80=9Coptional tagging=E2=80=9D by 23.228 = is a third reason, beyond > >1. Using different QOS settings for RTCP vs RTP > >2. Sending RTCP to a different device from RTP > =20 > Don=E2=80=99t want to go in the 3GPP specific details, but it has = nothing to do with the 3GPP UE-embedded WebRTC client nor any = constraints by 3GPP WebRTC gateways. > =20 > Thus, a WebRTC gateway MUST support RTP/RTCP transport multiplexing = due to its purpose in interworking support. > =20 > Regards, > Albrecht > =20 > =20 > From: Asveren, Tolga [mailto:tasveren@sonusnet.com = ]=20 > Sent: Mittwoch, 5. August 2015 19:47 > To: Roman Shpount; Rauschenbach, Uwe (Nokia - DE/Munich) > Cc: ext Eric Rescorla; Schwarz, Albrecht (Albrecht); Christer = Holmberg; Bernard Aboba; > > Subject: RE: [rtcweb] What the gateway draft should say about = mux/non-mux > =20 > i- I humbly disagree that using different QoS RTCP/RTP, e.g. different = DiffServ values , should be dismissed. > ii- Let me also add another reason why no-rtcp-mux may be needed: = Implementation difficulties in certain GWs. > =20 > Considering that there is already a negotiation mechanism for rtcp-mux = support, that it can be de-facto mandated by the choice of browsers for = Internet, I think what Christer/Albrecht suggested is the right way to = move forward: provide clarifications for vague points. I don=E2=80=99t = understand why lack of clarity in existing specifications should cause = imposing restrictions. This would be akin to dropping a feature due to a = bug. In this case, the =E2=80=9Cbug=E2=80=9D is lack of clarity in = normative specifications and it can be addressed by further = specification. > =20 > Thanks, > Tolga > =20 > From: Roman Shpount [mailto:roman@telurix.com = ]=20 > Sent: Wednesday, August 05, 2015 12:29 PM > To: Rauschenbach, Uwe (Nokia - DE/Munich) > > Cc: ext Eric Rescorla >; Schwarz, = Albrecht (Albrecht) >; Asveren, Tolga = >; Christer = Holmberg >; Bernard Aboba = >; = > > > Subject: Re: [rtcweb] What the gateway draft should say about = mux/non-mux > =20 > On Wed, Aug 5, 2015 at 4:47 AM, Rauschenbach, Uwe (Nokia - DE/Munich) = > wrote: > Media gateway implementations according to 3GPP TS 23.228 may not = support rtcp-mux, as rtcp-mux is optional there. > So if we drop non-mux support from web browsers, those media gateways = that have not implemented rtcp-mux will stop interoperating.=20 > =20 > =20 > First of all, do you know of any WebRTC to IMS gateways that do not = implement rtcp-mux on the WebRTC side? I strongly suspect there are = none. > =20 > Second, the only reasons not to use rtcp-mux that I can think of are = the following: > =20 > 1. Using different QOS settings for RTCP vs RTP > 2. Sending RTCP to a different device from RTP > =20 > I do not think the first use case warrants making rtcp-mux optional, = since, practically no one does this. > Second use case is also fairly marginal. Plus it can be handled by the = gateway which can send RTCP to one device and RTP to another. > =20 > So, unless someone can come up with a use case why RTP and RTCP should = use different transports, I think rtcp-mux should be mandatory. > =20 > Regards, > ______________ > Roman Shpount > _______________________________________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/listinfo/rtcweb --Apple-Mail=_EB52858E-BD97-4803-B593-A18EE599DE0C Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 So we are positing the existence of a webRTC gateway designed = to support thousands of calls which does ICE and DTLS but the
designer decided deliberately to double the = number of ICE sessions required and double the number of DTLS sessions = (and key 
generation costs) so that they can = run RTCP (over ICE and DTLS) on a separate port. In my estimation = that=E2=80=99s one poor decision
and should not be = used as the basis of this (or any) standard. 

I=E2=80=99d rather not = support rtcp-no-mux as I see zero advantages in having it. (I know = theoretically it might be possible to get
a RTCP = packet through a congested net on a different port with a separate = diffserv setting but that just seems so contrived).

Tim.


On = 6 Aug 2015, at 06:44, Asveren, Tolga <tasveren@sonusnet.com> wrote:

These assumptions are not necessarily true = in a universal sense (like almost any other assumption about different = deployment models).
 
Furthermore, and more importantly, there = is nothing mandating WebRTC endpoints to support non-rtcp-mux. It is a = negotiated functionality. Any entity can enforce rtcp-mux as a local = policy. 
 
The issue with = supporting non-rtcp-mux seems to be lack of clarity in the relevant = specifications. Fixing this =E2=80=93regardless of the outcome of any = other discussion- seems to be prudent IMHO.
 
Thanks,
Tolga
 
From: Wyss, Felix [mailto:Felix.Wyss@inin.com] 
Sent: Thursday, August 06, 2015 = 6:37 AM
To: Christer Holmberg <christer.holmberg@ericsson.com>; Asveren, Tolga <tasveren@sonusnet.com>; Schwarz, Albrecht (Albrecht) = <albrecht.schwarz@alcatel-lucent.com>; Roman Shpount = <roman@telurix.com>; Rauschenbach, Uwe (Nokia - = DE/Munich) <uwe.rauschenbach@nokia.com>
Cc: <rtcweb@ietf.org> = <rtcweb@ietf.org>
Subject: Re: [rtcweb] What the = gateway draft should say about mux/non-mux
 
Why shouldn't the gateway be required = to do the mux/demux?  Making the WebRTC endpoints a lot more = complex just so the legacy interop might potentially be a teeny-tiny bit = easier makes no sense IMHO.  Actually, the gateway would not be = able to do "end-to-end" pass-through anyway as legacy equipment will = either be unencrypted or use SDES (RFC#4568) for key exchange.  So = the gateway will have to perform DTLS-SRTP to SDES-SRTP = transcryption--which already is way more hassle than RTP/RTCP = mux/demux.
 
--Felix
 
From: rtcweb <rtcweb-bounces@ietf.org> = on behalf of Christer Holmberg <christer.holmberg@ericsson.com>
Sent: Thursday, August 6, 2015 = 05:51
To: Asveren, Tolga; Schwarz, = Albrecht (Albrecht); Roman Shpount; Rauschenbach, Uwe (Nokia - = DE/Munich)
Cc: <rtcweb@ietf.org>
Subject: Re: [rtcweb] What the = gateway draft should say about mux/non-mux
 
Hi,
 
No = matter whether the gateway supports RTP/RTCP mux or not, there are cases = where the legacy network/endpoints will not use RTP/RTCP mux, so I guess = people then would want to be able to negotiate non-mux =E2=80=9Cend-to-end= =E2=80=9D, rather than having the gateway to demux/mux RTP and = RTCP.
 
Regards,
 
Christer
 
From: Asveren, Tolga [mailto:tasveren@sonusnet.com] 
Sent: 6. = elokuuta 2015 12:18
To: Schwarz, Albrecht = (Albrecht); Roman Shpount; Rauschenbach, Uwe (Nokia - DE/Munich)
Cc: ext Eric Rescorla; Christer = Holmberg; Bernard Aboba; <rtcweb@ietf.org>
Subject: Re: [rtcweb] What the = gateway draft should say about mux/non-mux
 
Why should we consider 3GPP the sole = "owner/user" of the term/entity WebRTC-GW? I think it has a much more = general meaning and use in practice. It can refer to many different = types of elements which can be deployed in many different environments, = hence any attempt to define it strictly/restrict its capabilities are = futile IMHO.
 
Thanks,
Tolga
 
From: Schwarz, Albrecht = (Albrecht) <albrecht.schwarz@alcatel-lucent.com>
Sent: Thursday, August 6, 2015 = 2:44 AM
To: Asveren, Tolga; Roman = Shpount; Rauschenbach, Uwe (Nokia - DE/Munich)
Cc: ext = Eric Rescorla; Christer Holmberg; Bernard Aboba; <rtcweb@ietf.org>
Subject: RE: [rtcweb] What the = gateway draft should say about mux/non-mux
 
The concerned 3GPP WebRTC gateway (3GPP = 23.334/29.334) supports already RTP/RTCP transport multiplexing (since = 3GPP Release 12), i.e. should not be the limiting factor in this = discussion. 
For ones = interested in the RTCP port allocation rules, see H.248.57:
https://www.itu.int/rec/dologin_pub.asp?lang=3De&id=3DT-REC= -H.248.57-201410-I!!PDF-E&type=3Ditems
Clause 7 = describes RTP/RTCP transport multiplexing. ITU-T H.248.57 is already = supported by 3GPP 29.334.
 
The rationale behind the =E2=80=9Coptional tagging=E2=80= =9D by 23.228 is a third reason, beyond
>1. Using = different QOS settings for RTCP vs RTP
>2. Sending RTCP to a different = device from RTP
 
Don=E2=80=99t want to go in the 3GPP specific details, = but it has nothing to do with the 3GPP UE-embedded WebRTC client nor any = constraints by 3GPP WebRTC gateways.
 
Thus, a WebRTC gateway MUST support RTP/RTCP transport = multiplexing due to its purpose in interworking support.
 
Regards,
Albrecht
 
 
From: Asveren, Tolga [mailto:tasveren@sonusnet.com] 
Sent: Mittwoch, 5. August 2015 = 19:47
To: Roman Shpount; = Rauschenbach, Uwe (Nokia - DE/Munich)
Cc: ext = Eric Rescorla; Schwarz, Albrecht (Albrecht); Christer Holmberg; Bernard = Aboba; <rtcweb@ietf.org>
Subject: RE: [rtcweb] What the = gateway draft should say about mux/non-mux
 
i- = I humbly disagree that using different QoS RTCP/RTP, e.g. different = DiffServ values , should be dismissed.
ii- Let me also add another reason why = no-rtcp-mux may be needed: Implementation difficulties in certain = GWs.
 
Considering that there is already a = negotiation mechanism for rtcp-mux support, that it can be de-facto = mandated by the choice of browsers for Internet, I think what = Christer/Albrecht suggested is the right way to move forward: provide = clarifications for vague points. I don=E2=80=99t understand why lack of = clarity in existing specifications should cause imposing restrictions. = This would be akin to dropping a feature due to a bug. In this case, the = =E2=80=9Cbug=E2=80=9D is lack of clarity in normative specifications and = it can be addressed by further specification.
 
Thanks,
Tolga
 
From: Roman Shpount [mailto:roman@telurix.com] 
Sent: Wednesday, August 05, 2015 = 12:29 PM
To: Rauschenbach, Uwe (Nokia - = DE/Munich) <uwe.rauschenbach@nokia.com>
Cc: ext = Eric Rescorla <ekr@rtfm.com>; = Schwarz, Albrecht (Albrecht) <albrecht.schwarz@alcatel-lucent.com>; Asveren, Tolga = <tasveren@sonusnet.com>; = Christer Holmberg <christer.holmberg@ericsson.com>; Bernard Aboba <bernard.aboba@gmail.com>; = <rtcweb@ietf.org> <rtcweb@ietf.org>
Subject: Re: [rtcweb] What the = gateway draft should say about mux/non-mux
 
On= Wed, Aug 5, 2015 at 4:47 AM, Rauschenbach, Uwe (Nokia - DE/Munich) = <uwe.rauschenbach@nokia.com> wrote:
Media gateway = implementations according to 3GPP TS 23.228 may not support = rtcp-mux, as rtcp-mux is optional there.
So if we drop non-mux support from web browsers, = those media gateways that have not implemented rtcp-mux will stop = interoperating. 
 
 
First of all, do you know of any WebRTC to IMS gateways that = do not implement rtcp-mux on the WebRTC side? I strongly suspect there = are none.
 
Second, the only reasons not to use = rtcp-mux that I can think of are the following:
 
1. Using different QOS settings for = RTCP vs RTP
2. Sending RTCP = to a different device from RTP
 
I do not think the first use case = warrants making rtcp-mux optional, since, practically no one does = this.
Second use case = is also fairly marginal. Plus it can be handled by the gateway which can = send RTCP to one device and RTP to another.
 
So, unless someone can come up with a = use case why RTP and RTCP should use different transports, I think = rtcp-mux should be mandatory.
 
Regards,
______________
Roman Shpount
_______________________________________________
rtcweb mailing list
rtcweb@ietf.org
https://www.ietf.org/mailman/listinfo/rtcweb

= --Apple-Mail=_EB52858E-BD97-4803-B593-A18EE599DE0C-- From nobody Thu Aug 6 06:08:18 2015 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 44A341B2EF5 for ; Thu, 6 Aug 2015 06:08:16 -0700 (PDT) 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, RCVD_IN_DNSWL_LOW=-0.7] 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 f5LyuoHpT7tM for ; Thu, 6 Aug 2015 06:08:12 -0700 (PDT) Received: from out5-smtp.messagingengine.com (out5-smtp.messagingengine.com [66.111.4.29]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 23BA21B2EF2 for ; Thu, 6 Aug 2015 06:08:12 -0700 (PDT) Received: from compute5.internal (compute5.nyi.internal [10.202.2.45]) by mailout.nyi.internal (Postfix) with ESMTP id 8EA6C204ED for ; Thu, 6 Aug 2015 09:08:11 -0400 (EDT) Received: from frontend2 ([10.202.2.161]) by compute5.internal (MEProxy); Thu, 06 Aug 2015 09:08:11 -0400 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=dmeWo thRuduKe3Pd3N6T7Af7jsw=; b=OW4YGN02A3sUcpQfYpmkjVGvGzdrGuBYMS/xx 93nrkMZQSHjhLu9bvlVYkgTcMOXldUP6pTDGQjnWziCBRuE67TTOFArD+E3Yewua 3D0gIMNHBCIl5+Eet/ODkWJ0mfO2nfWijRwypU9Ijc3aTW4phPVJ80HKBlGG+Q1g y4diPE= 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=dmeWothRuduKe3Pd3N6T7Af7jsw=; b=FFPci IQI3jlk4o9rle6jnBq8ryEjwgM4wePUIrVpURWKuchgGbR6m8QZQmUhEUU8SqdmC dHj+h+HYiFQssd0UPi8UYyuagzY3CDl4RovrjGUmTom4Qbl6Z/NSpCSswyqO56ri 8DCoWNqe6DrcbkyVPOwyMqoEQH9KSoFbDAIntU= X-Sasl-enc: 6v7pnseBNVEzWSFbqBhb0fulLqJGzHunN6jpczI7XvwR 1438866490 Received: from sjc-alcoop-8814.cisco.com (unknown [128.107.241.169]) by mail.messagingengine.com (Postfix) with ESMTPA id AC170680141; Thu, 6 Aug 2015 09:08:08 -0400 (EDT) Content-Type: multipart/alternative; boundary="Apple-Mail=_68B7BFDA-D38C-493C-AA40-373963E6B87D" Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) From: Alissa Cooper In-Reply-To: <55C24293.5000603@cs.tcd.ie> Date: Thu, 6 Aug 2015 06:08:08 -0700 Message-Id: <0ACC6069-AB51-4D19-A329-327640B2CCC1@cooperw.in> References: <20150805130607.20844.70680.idtracker@ietfa.amsl.com> <55C24293.5000603@cs.tcd.ie> To: Stephen Farrell X-Mailer: Apple Mail (2.1878.6) Archived-At: Cc: draft-ietf-rtcweb-stun-consent-freshness@ietf.org, rtcweb-chairs@ietf.org, draft-ietf-rtcweb-stun-consent-freshness.shepherd@ietf.org, "rtcweb@ietf.org" , IESG , draft-ietf-rtcweb-stun-consent-freshness.ad@ietf.org Subject: Re: [rtcweb] Stephen Farrell's Discuss on draft-ietf-rtcweb-stun-consent-freshness-15: (with DISCUSS and COMMENT) X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 06 Aug 2015 13:08:16 -0000 --Apple-Mail=_68B7BFDA-D38C-493C-AA40-373963E6B87D Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 Picking up on one more of these ... On Aug 5, 2015, at 10:06 AM, Stephen Farrell = wrote: >=20 > Hiya. >=20 > On 05/08/15 16:00, Eric Rescorla wrote: >> On Wed, Aug 5, 2015 at 6:06 AM, Stephen Farrell = >> wrote: >>=20 >>> Stephen Farrell has entered the following ballot position for >>> draft-ietf-rtcweb-stun-consent-freshness-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-rtcweb-stun-consent-freshness/= >>>=20 >>>=20 >>>=20 >>> = ---------------------------------------------------------------------- >>> DISCUSS: >>> = ---------------------------------------------------------------------- >>>=20 >>>=20 >>>=20 >>> Apologies that these discuss points are maybe asking >>> fairly fundamental questions. That could be that this >>> is really the first of the new security things required >>> by rtcweb to get to the IESG. Or maybe I'm misreading >>> stuff here, if so, sorry;-) >>>=20 >>> (1) Why call this "consent?" That term is (ab)used in >>> many ways on the web, and adding another variation >>> without a definition that distinguishes this from "click >>> ok to my 200 page anti-privacy policy" or "remember that >>> example.com is allowed use my camera/mic" seems like a >>> terrible idea. I also don't see how this can ever be >>> something to which a normal person can "consent" (i.e. >>> consciously agree while fully understanding) so the term >>> is IMO very misleading, and will I fear be used to >>> mislead further. (See also some of the comments below - >>> I do not think we ought be as fast and loose with this >>> aleady terribly badly used term.) To summarise: I'd love >>> if you did s/consent/anything-else/g but if not, please >>> define consent here in a way that clearly and >>> unambiguously distinguishes this usage from other abuses >>> of the term. >>>=20 >>=20 >> You should probably propose a new term at this point. >=20 > Really? Happy to try (and fail:-) How'd "willing to take > rtcweb traffic" work? I suspect it wouldn't though. I am sympathetic to the point about =93consent=94 but I=92m not sure = there is a single better word that connotes a machine agreeing to = something rather than a person doing so. I think =93permission=94 would = be an even worse choice in this case given that it has a very common = usage in WebRTC/browser land related to exactly what you cite above, = namely browser permissions to use camera, mic, etc. =93Willingness=94 = seems at least as human if not more so than =93consent.=94 There is already a definition of =93consent=94 in the draft: Consent: The mechanism of obtaining permission from the remote endpoint to send non-ICE traffic to a remote transport address. Consent is obtained using ICE. I would suggest adding one additional sentence to this: =93Note that this is an application-level consent; no human intervention = is involved.=94 Alissa >=20 > But I'm not clear if you're agreeing that that term > is problematic or just asking me to suggest something in > the hope I realise the futility of what I'm requesting? >=20 >=20 >>=20 >>=20 >> (2) WebRTC does not require STUN or TURN servers for >>> some calls, even if it does for many. Why is it ok to >>> require such a server be present in all calls (which I >>> think this means) espcially when that means exposing >>> additional meta-data (calling parties in a case where >>> the servers weren't needed and call duration in all >>> cases) to those servers when that is not always >>> necessary? >>>=20 >>=20 >> I'm not sure what you mean by "OK" and "require".=20 >> The physics of the >> situation >> is that if you want to do a call between two people not on the same = network, >> then you minimally need STUN.=20 >=20 > Sure. But if they're on the same n/w? Do we agree that > in that case, there shouldn't be a need for a new STUN > or TURN server in the call? And that if this draft meant > such a server was needed even in that case, then that'd > be an issue? >=20 >> If you want it to (almost) always work you >> need TURN. This isn't a spec requirement but just a result of the = network >> topology. As far as I know, the specs don't require that the site = supply >> a STUN/TURN server and the implementations don't either, but I'm not >> sure what else you're looking for. >=20 > So one non-inevitable consequence of the how this draft > is written is that the STUN/TURN server gets to know the > call duration. That could have been avoided I think if > some other design had been chosen. Part of my question > then is why exposing that additional meta-data to a server > that most users won't know exists, and that is likely > controlled by some entity the user has no clue is even > involved in their calls, is acceptable. >=20 >>> (3) (end of p5) You have a MUST NOT here that is >>> depenedent on current browser implementations. Why is >>> that an IETF thing and not a W3C thing? But more >>> interestingly, can one securely use this protocol >>> without the kind of JS vs. browser sandboxing etc that's >>> needed in the web? If the answer is "no" then don't you >>> need to say that this protocol can only safely be used >>> for such implementations? (In section 2, which almost >>> but not quite says that.) >>>=20 >>=20 >> This is just only relevant in this case. It doesn't apply to non-JS >> implementations. >=20 > Not sure I'm following. Are you saying that this protocol > would be safe even if there wasn't the split between JS > and non-JS code running on the browser? If so, that's good. >=20 > Cheers, > S. >=20 >>=20 >> -Ekr >>=20 >> = ---------------------------------------------------------------------- >>> COMMENT: >>> = ---------------------------------------------------------------------- >>>=20 >>>=20 >>> - abstract: why is only sending "media" mentioned here? >>> What about data channels? And the body of the document >>> in fact says this all applies to any non-ICE data and >>> not only media. >>>=20 >>> - intro: "initial consent to send by performing STUN" I >>> do not find the word consent in either rfc5245 or 3489, >>> but perhaps it is used somewhere else. Where? And with >>> what meaning? >>>=20 >>> - section 4, 2nd last para - I think the conclusion is >>> bogus. An implementation knows when the keying it's >>> using can not involve >1 (nominally operating) party. >>>=20 >>> - 5.1, 3rd para: "Explicit consent to send is >>> obtained..." is misleading. That is not a concept that >>> an implementation of STUN will embody. >>>=20 >>> - 5.1, What is the "Note" about TCP for? Why is this >>> needed? >>>=20 >>>=20 >>> _______________________________________________ >>> rtcweb mailing list >>> rtcweb@ietf.org >>> https://www.ietf.org/mailman/listinfo/rtcweb >>>=20 >>=20 --Apple-Mail=_68B7BFDA-D38C-493C-AA40-373963E6B87D Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=windows-1252
Picking up on one more of these = ...

On Aug 5, 2015, at 10:06 AM, Stephen Farrell = <stephen.farrell@cs.tcd.ie>= ; wrote:


Hiya.

On 05/08/15 16:00, Eric Rescorla = wrote:
On Wed, Aug 5, 2015 at 6:06 AM, = Stephen Farrell <stephen.farrell@cs.tcd.ie>= ;
wrote:

Stephen Farrell has entered = the following ballot position = for
draft-ietf-rtcweb-stun-consent-freshness-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-rtcweb-stun-consent-= freshness/



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



Apologies that = these discuss points are maybe asking
fairly fundamental questions. =  That could be that this
is really the first of the new security = things required
by rtcweb to get to the IESG.  Or maybe I'm = misreading
stuff here, if so, sorry;-)

(1) Why call this = "consent?" That term is (ab)used in
many ways on the web, and adding = another variation
without a definition that distinguishes this from = "click
ok to my 200 page anti-privacy policy" or "remember = that
example.com is allowed use my camera/mic" seems like = a
terrible idea. I also don't see how this can ever be
something = to which a normal person can "consent" (i.e.
consciously agree while = fully understanding) so the term
is IMO very misleading, and will I = fear be used to
mislead further.  (See also some of the comments = below -
I do not think we ought be as fast and loose with = this
aleady terribly badly used term.) To summarise: I'd love
if = you did s/consent/anything-else/g but if not, please
define consent = here in a way that clearly and
unambiguously distinguishes this usage = from other abuses
of the term.


You should = probably propose a new term at this point.

Really? = Happy to try (and fail:-) How'd "willing to take
rtcweb traffic" = work? I suspect it wouldn't = though.

I am sympathetic to the = point about =93consent=94 but I=92m not sure there is a single better = word that connotes a machine agreeing to something rather than a person = doing so. I think =93permission=94 would be an even worse choice in this = case given that it has a very common usage in WebRTC/browser land = related to exactly what you cite above, namely browser permissions to = use camera, mic, etc. =93Willingness=94 seems at least as human if not = more so than =93consent.=94

There is already a = definition of =93consent=94 in the draft:

Consent: =
 The mechanism of obtaining permission from the remote
      endpoint to send non-ICE traffic to a remote transport address.
      Consent is obtained using ICE.

I = would suggest adding one additional sentence to = this:

=93Note that this is an application-level = consent; no human intervention is = involved.=94

Alissa


But I'm not clear if you're agreeing that that = term
is problematic or just asking me to suggest something in
the = hope I realise the futility of what I'm = requesting?




(2) WebRTC does = not require STUN or TURN servers for
some = calls, even if it does for many. Why is it ok to
require such a = server be present in all calls (which I
think this means) espcially = when that means exposing
additional meta-data (calling parties in a = case where
the servers weren't needed and call duration in = all
cases) to those servers when that is not = always
necessary?


I'm not sure what you mean = by "OK" and "require".
The physics of the
situation
is that if = you want to do a call between two people not on the same = network,
then you minimally need STUN.

Sure. But = if they're on the same n/w? Do we agree that
in that case, there = shouldn't be a need for a new STUN
or TURN server in the call? And = that if this draft meant
such a server was needed even in that case, = then that'd
be an issue?

If you want = it to (almost) always work you
need TURN. This isn't a spec = requirement but just a result of the network
topology. As far as I = know, the specs don't require that the site supply
a STUN/TURN server = and the implementations don't either, but I'm not
sure what else = you're looking for.

So one non-inevitable = consequence of the how this draft
is written is that the STUN/TURN = server gets to know the
call duration. That could have been avoided I = think if
some other design had been chosen. Part of my = question
then is why exposing that additional meta-data to a = server
that most users won't know exists, and that is = likely
controlled by some entity the user has no clue is = even
involved in their calls, is acceptable.

(3) (end of p5) You have a MUST = NOT here that is
depenedent on current browser implementations. Why = is
that an IETF thing and not a W3C thing? But more
interestingly, = can one securely use this protocol
without the kind of JS vs. browser = sandboxing etc that's
needed in the web? If the answer is "no" then = don't you
need to say that this protocol can only safely be = used
for such implementations? (In section 2, which almost
but not = quite says that.)


This is just only relevant in = this case. It doesn't apply to = non-JS
implementations.

Not sure I'm following. = Are you saying that this protocol
would be safe even if there wasn't = the split between JS
and non-JS code running on the browser? If so, = that's good.

Cheers,
S.


-Ekr

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


- abstract: why is only sending = "media" mentioned here?
What about data channels?  And the body = of the document
in fact says this all applies to any non-ICE data = and
not only media.

- intro: "initial consent to send by = performing STUN" I
do not find the word consent in either rfc5245 or = 3489,
but perhaps it is used somewhere else. Where?  And = with
what meaning?

- section 4, 2nd last para - I think the = conclusion is
bogus.  An implementation knows when the keying = it's
using can not involve >1 (nominally operating) = party.

- 5.1, 3rd para: "Explicit consent to send = is
obtained..." is misleading. That is not a concept that
an = implementation of STUN will embody.

- 5.1, What is the "Note" = about TCP for? Why is = this
needed?


_______________________________________________=
rtcweb mailing list
rtcweb@ietf.org
https://www.ietf.or= g/mailman/listinfo/rtcweb



= --Apple-Mail=_68B7BFDA-D38C-493C-AA40-373963E6B87D-- From nobody Thu Aug 6 06:16:00 2015 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1B2DD1B2F16; Thu, 6 Aug 2015 06:15:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.311 X-Spam-Level: X-Spam-Status: No, score=-4.311 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_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZeXWhrJg2pYM; Thu, 6 Aug 2015 06:15:52 -0700 (PDT) Received: from mercury.scss.tcd.ie (mercury.scss.tcd.ie [134.226.56.6]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DFA201B2F14; Thu, 6 Aug 2015 06:15:51 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id 5BDACBE53; Thu, 6 Aug 2015 14:15:50 +0100 (IST) Received: from mercury.scss.tcd.ie ([127.0.0.1]) by localhost (mercury.scss.tcd.ie [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4YyddghYQovp; Thu, 6 Aug 2015 14:15:50 +0100 (IST) Received: from [134.226.36.180] (stephen-think.dsg.cs.tcd.ie [134.226.36.180]) by mercury.scss.tcd.ie (Postfix) with ESMTPSA id 2F4FABE4C; Thu, 6 Aug 2015 14:15:49 +0100 (IST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cs.tcd.ie; s=mail; t=1438866950; bh=m054BDeqU7Cw5jLcc5TCyNU/uSApq/hqJm6J4Y3JzT0=; h=Date:From:To:CC:Subject:References:In-Reply-To:From; b=hvus0lDHdZ/uXtYwKdBiHm0+P8aOH1NJZP1PUv7N3SI42zduUbOFKfCGNj9eGYopV I7cwl8ew2wc20Kyt6QgeK8MW5+JP3Le0JvQdWd0HOLD8mu3Ey8BXsyul3NR5mt6o5I ohLEDLBow/zxZe2ivk+8mGfrI+YYjpVI56OSd9/M= Message-ID: <55C35E04.3000307@cs.tcd.ie> Date: Thu, 06 Aug 2015 14:15:48 +0100 From: Stephen Farrell User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.8.0 MIME-Version: 1.0 To: Alissa Cooper References: <20150805130607.20844.70680.idtracker@ietfa.amsl.com> <55C24293.5000603@cs.tcd.ie> <0ACC6069-AB51-4D19-A329-327640B2CCC1@cooperw.in> In-Reply-To: <0ACC6069-AB51-4D19-A329-327640B2CCC1@cooperw.in> OpenPGP: id=D66EA7906F0B897FB2E97D582F3C8736805F8DA2; url= Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit Archived-At: Cc: draft-ietf-rtcweb-stun-consent-freshness@ietf.org, rtcweb-chairs@ietf.org, draft-ietf-rtcweb-stun-consent-freshness.shepherd@ietf.org, "rtcweb@ietf.org" , IESG , draft-ietf-rtcweb-stun-consent-freshness.ad@ietf.org Subject: Re: [rtcweb] Stephen Farrell's Discuss on draft-ietf-rtcweb-stun-consent-freshness-15: (with DISCUSS and COMMENT) X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 06 Aug 2015 13:15:56 -0000 Hiya, On 06/08/15 14:08, Alissa Cooper wrote: > Picking up on one more of these ... > > On Aug 5, 2015, at 10:06 AM, Stephen Farrell > wrote: > >> >> Hiya. >> >> On 05/08/15 16:00, Eric Rescorla wrote: >>> On Wed, Aug 5, 2015 at 6:06 AM, Stephen Farrell >>> wrote: >>> >>>> Stephen Farrell has entered the following ballot position for >>>> draft-ietf-rtcweb-stun-consent-freshness-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-rtcweb-stun-consent-freshness/ >>>> >>>> >>>> >>>> >>>> ---------------------------------------------------------------------- >>>> DISCUSS: >>>> ---------------------------------------------------------------------- >>>> >>>> >>>> >>>> >>>> Apologies that these discuss points are maybe asking >>>> fairly fundamental questions. That could be that this is >>>> really the first of the new security things required by rtcweb >>>> to get to the IESG. Or maybe I'm misreading stuff here, if so, >>>> sorry;-) >>>> >>>> (1) Why call this "consent?" That term is (ab)used in many ways >>>> on the web, and adding another variation without a definition >>>> that distinguishes this from "click ok to my 200 page >>>> anti-privacy policy" or "remember that example.com is allowed >>>> use my camera/mic" seems like a terrible idea. I also don't see >>>> how this can ever be something to which a normal person can >>>> "consent" (i.e. consciously agree while fully understanding) so >>>> the term is IMO very misleading, and will I fear be used to >>>> mislead further. (See also some of the comments below - I do >>>> not think we ought be as fast and loose with this aleady >>>> terribly badly used term.) To summarise: I'd love if you did >>>> s/consent/anything-else/g but if not, please define consent >>>> here in a way that clearly and unambiguously distinguishes this >>>> usage from other abuses of the term. >>>> >>> >>> You should probably propose a new term at this point. >> >> Really? Happy to try (and fail:-) How'd "willing to take rtcweb >> traffic" work? I suspect it wouldn't though. > > I am sympathetic to the point about “consent” but I’m not sure there > is a single better word that connotes a machine agreeing to something > rather than a person doing so. https://en.wikipedia.org/wiki/Clear_to_Send ? > I think “permission” would be an even > worse choice in this case given that it has a very common usage in > WebRTC/browser land related to exactly what you cite above, namely > browser permissions to use camera, mic, etc. “Willingness” seems at > least as human if not more so than “consent.” IMO anything that doesn't use the word consent is better than anything that does. To make a webrtc call a person is forced to consent to a whole bunch of pseudo-legal crap (by their OS, browser, IdP, and probably the web site) so entangling the protocol with any of that is a mistake. Once you stick with the term consent, I think such entanglement is inevitable and will be regretted. > > There is already a definition of “consent” in the draft: > > Consent: The mechanism of obtaining permission from the remote > endpoint to send non-ICE traffic to a remote transport address. > Consent is obtained using ICE. > > I would suggest adding one additional sentence to this: > > “Note that this is an application-level consent; no human > intervention is involved.” That would be good enough for me to clear yes. As a comment, I think though it'd be better as something more like: 'The only human level "consent" here is that the application developer (e.g. WebRTC browser implementer) has programmed their application to adhere to this specification. The actual end users who are involved in the call have not consented to anything just because their browser uses this protocol.' S. > > Alissa > >> >> But I'm not clear if you're agreeing that that term is problematic >> or just asking me to suggest something in the hope I realise the >> futility of what I'm requesting? >> >> >>> >>> >>> (2) WebRTC does not require STUN or TURN servers for >>>> some calls, even if it does for many. Why is it ok to require >>>> such a server be present in all calls (which I think this >>>> means) espcially when that means exposing additional meta-data >>>> (calling parties in a case where the servers weren't needed and >>>> call duration in all cases) to those servers when that is not >>>> always necessary? >>>> >>> >>> I'm not sure what you mean by "OK" and "require". The physics of >>> the situation is that if you want to do a call between two people >>> not on the same network, then you minimally need STUN. >> >> Sure. But if they're on the same n/w? Do we agree that in that >> case, there shouldn't be a need for a new STUN or TURN server in >> the call? And that if this draft meant such a server was needed >> even in that case, then that'd be an issue? >> >>> If you want it to (almost) always work you need TURN. This isn't >>> a spec requirement but just a result of the network topology. As >>> far as I know, the specs don't require that the site supply a >>> STUN/TURN server and the implementations don't either, but I'm >>> not sure what else you're looking for. >> >> So one non-inevitable consequence of the how this draft is written >> is that the STUN/TURN server gets to know the call duration. That >> could have been avoided I think if some other design had been >> chosen. Part of my question then is why exposing that additional >> meta-data to a server that most users won't know exists, and that >> is likely controlled by some entity the user has no clue is even >> involved in their calls, is acceptable. >> >>>> (3) (end of p5) You have a MUST NOT here that is depenedent on >>>> current browser implementations. Why is that an IETF thing and >>>> not a W3C thing? But more interestingly, can one securely use >>>> this protocol without the kind of JS vs. browser sandboxing etc >>>> that's needed in the web? If the answer is "no" then don't you >>>> need to say that this protocol can only safely be used for such >>>> implementations? (In section 2, which almost but not quite says >>>> that.) >>>> >>> >>> This is just only relevant in this case. It doesn't apply to >>> non-JS implementations. >> >> Not sure I'm following. Are you saying that this protocol would be >> safe even if there wasn't the split between JS and non-JS code >> running on the browser? If so, that's good. >> >> Cheers, S. >> >>> >>> -Ekr >>> >>> ---------------------------------------------------------------------- >>>> >>> COMMENT: >>>> ---------------------------------------------------------------------- >>>> >>>> >>>> >>>> - abstract: why is only sending "media" mentioned here? >>>> What about data channels? And the body of the document in fact >>>> says this all applies to any non-ICE data and not only media. >>>> >>>> - intro: "initial consent to send by performing STUN" I do not >>>> find the word consent in either rfc5245 or 3489, but perhaps it >>>> is used somewhere else. Where? And with what meaning? >>>> >>>> - section 4, 2nd last para - I think the conclusion is bogus. >>>> An implementation knows when the keying it's using can not >>>> involve >1 (nominally operating) party. >>>> >>>> - 5.1, 3rd para: "Explicit consent to send is obtained..." is >>>> misleading. That is not a concept that an implementation of >>>> STUN will embody. >>>> >>>> - 5.1, What is the "Note" about TCP for? Why is this needed? >>>> >>>> >>>> _______________________________________________ rtcweb mailing >>>> list rtcweb@ietf.org >>>> https://www.ietf.org/mailman/listinfo/rtcweb >>>> >>> > > From nobody Thu Aug 6 06:17:38 2015 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id ED0F51B2F23; Thu, 6 Aug 2015 06:17:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.311 X-Spam-Level: X-Spam-Status: No, score=-4.311 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_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id S4X362GDVKKd; Thu, 6 Aug 2015 06:17:36 -0700 (PDT) Received: from mercury.scss.tcd.ie (mercury.scss.tcd.ie [134.226.56.6]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C2A191B2F1F; Thu, 6 Aug 2015 06:17:36 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id 88DB0BE53; Thu, 6 Aug 2015 14:17:35 +0100 (IST) Received: from mercury.scss.tcd.ie ([127.0.0.1]) by localhost (mercury.scss.tcd.ie [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0mhoMEWy7xTr; Thu, 6 Aug 2015 14:17:35 +0100 (IST) Received: from [134.226.36.180] (stephen-think.dsg.cs.tcd.ie [134.226.36.180]) by mercury.scss.tcd.ie (Postfix) with ESMTPSA id 2890CBE4C; Thu, 6 Aug 2015 14:17:35 +0100 (IST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cs.tcd.ie; s=mail; t=1438867055; bh=Xr3WCyjsSkUjOJEAYH4+g+xAYWResvQLNtnZFB462Mo=; h=Date:From:To:CC:Subject:References:In-Reply-To:From; b=hOWGuYrMMY7B6dVTEn/kh+gIs337XRoVZ47awvejAd+hj1ksE0RNtWNzSOoZOuNAG TEIklE/K+bwm9Ra4PblyVnvQLNcvfr84LPYH/k3oIMSFjvQvIH9+8r6fLr5d74DisS kVeEvIGpC0MottoGLDGobpSxtuFFf66tJ7tcx4yA= Message-ID: <55C35E6E.6000206@cs.tcd.ie> Date: Thu, 06 Aug 2015 14:17:34 +0100 From: Stephen Farrell User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.8.0 MIME-Version: 1.0 To: Xavier Marjou , Christer Holmberg References: <20150805130607.20844.70680.idtracker@ietfa.amsl.com> <7594FB04B1934943A5C02806D1A2204B348E9691@ESESSMB209.ericsson.se> In-Reply-To: OpenPGP: id=D66EA7906F0B897FB2E97D582F3C8736805F8DA2; url= Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Archived-At: Cc: "draft-ietf-rtcweb-stun-consent-freshness@ietf.org" , "rtcweb-chairs@ietf.org" , "draft-ietf-rtcweb-stun-consent-freshness.shepherd@ietf.org" , "rtcweb@ietf.org" , The IESG , "draft-ietf-rtcweb-stun-consent-freshness.ad@ietf.org" Subject: Re: [rtcweb] Stephen Farrell's Discuss on draft-ietf-rtcweb-stun-consent-freshness-15: (with DISCUSS and COMMENT) X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 06 Aug 2015 13:17:38 -0000 On 06/08/15 09:34, Xavier Marjou wrote: > Some newcomers think that STUN messages only happen in cases 1 and/or 2, > they forget case 3. Maybe this explains the misunderstanding. Yep. So I think the action is on me to go back and pick out the bits of text that imply a server is needed, or say I tried and they're not really there:-) I'll get to that tomorrow. S. From nobody Thu Aug 6 06:30:35 2015 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D15721B2F5C for ; Thu, 6 Aug 2015 06:30:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.609 X-Spam-Level: X-Spam-Status: No, score=-2.609 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GT8BKWf3BKbO for ; Thu, 6 Aug 2015 06:30:29 -0700 (PDT) Received: from mx11.unify.com (mx11.unify.com [62.134.46.9]) by ietfa.amsl.com (Postfix) with ESMTP id 923C11B2F55 for ; Thu, 6 Aug 2015 06:30:28 -0700 (PDT) Received: from MCHP02HTC.global-ad.net (unknown [172.29.42.235]) by mx11.unify.com (Server) with ESMTP id 437091EB84F1; Thu, 6 Aug 2015 15:30:27 +0200 (CEST) Received: from MCHP04MSX.global-ad.net ([169.254.37.243]) by MCHP02HTC.global-ad.net ([172.29.42.235]) with mapi id 14.03.0248.002; Thu, 6 Aug 2015 15:30:27 +0200 From: "Hutton, Andrew" To: tim panton , "Asveren, Tolga" Thread-Topic: [rtcweb] What the gateway draft should say about mux/non-mux Thread-Index: AQHQ0EbjJarRmMWKQkuVevbl8oA2Mp3+9X1Q Date: Thu, 6 Aug 2015 13:30:25 +0000 Message-ID: <9F33F40F6F2CD847824537F3C4E37DDF1E826A00@MCHP04MSX.global-ad.net> References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [172.29.42.225] Content-Type: multipart/alternative; boundary="_000_9F33F40F6F2CD847824537F3C4E37DDF1E826A00MCHP04MSXglobal_" MIME-Version: 1.0 Archived-At: Cc: "" Subject: Re: [rtcweb] What the gateway draft should say about mux/non-mux X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 06 Aug 2015 13:30:34 -0000 --_000_9F33F40F6F2CD847824537F3C4E37DDF1E826A00MCHP04MSXglobal_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 KzEgdG8gd2hhdCBUaW0gc2FpZC4NCg0KSSBkb27igJl0IHRoaW5rIHRoaXMgZGlzY3Vzc2lvbiBp cyByZWFsbHkgYWJvdXQgZ2F0ZXdheXMgYXQgYWxsIGl0IGlzIHN1cmVseSBhYm91dCB3aGV0aGVy IFdlYlJUQyBicm93c2VycyBoYXZlIHRvIHN1cHBvcnQgbm9uLW11eCBhbmQgSSBkb27igJl0IHJl YWxseSBzZWUgYW55IGdvb2QgcmVhc29uIHdoeSB0aGV5IG5lZWQgdG8uDQoNCklmIHdlIGhhZCB0 aG91Z2h0IGFib3V0IHRoaXMgYXQgdGhlIHRpbWUgd2UgbWFuZGF0ZWQgRFRMUy1TUlRQIHRoZW4g d2Ugd291bGQgaGF2ZSBtYW5kYXRlZCBydHAtbXV4IGF0IHRoZSBzYW1lIHRpbWUgYnV0IHVuZm9y dHVuYXRlbHkgd2UgZGlkbuKAmXQgYnV0IHdlIGNhbiBmaXggdGhhdCBub3cuDQoNCkFuZHkNCg0K DQpGcm9tOiBydGN3ZWIgW21haWx0bzpydGN3ZWItYm91bmNlc0BpZXRmLm9yZ10gT24gQmVoYWxm IE9mIHRpbSBwYW50b24NClNlbnQ6IDA2IEF1Z3VzdCAyMDE1IDEzOjUzDQpUbzogQXN2ZXJlbiwg VG9sZ2ENCkNjOiA8cnRjd2ViQGlldGYub3JnPg0KU3ViamVjdDogUmU6IFtydGN3ZWJdIFdoYXQg dGhlIGdhdGV3YXkgZHJhZnQgc2hvdWxkIHNheSBhYm91dCBtdXgvbm9uLW11eA0KDQpTbyB3ZSBh cmUgcG9zaXRpbmcgdGhlIGV4aXN0ZW5jZSBvZiBhIHdlYlJUQyBnYXRld2F5IGRlc2lnbmVkIHRv IHN1cHBvcnQgdGhvdXNhbmRzIG9mIGNhbGxzIHdoaWNoIGRvZXMgSUNFIGFuZCBEVExTIGJ1dCB0 aGUNCmRlc2lnbmVyIGRlY2lkZWQgZGVsaWJlcmF0ZWx5IHRvIGRvdWJsZSB0aGUgbnVtYmVyIG9m IElDRSBzZXNzaW9ucyByZXF1aXJlZCBhbmQgZG91YmxlIHRoZSBudW1iZXIgb2YgRFRMUyBzZXNz aW9ucyAoYW5kIGtleQ0KZ2VuZXJhdGlvbiBjb3N0cykgc28gdGhhdCB0aGV5IGNhbiBydW4gUlRD UCAob3ZlciBJQ0UgYW5kIERUTFMpIG9uIGEgc2VwYXJhdGUgcG9ydC4gSW4gbXkgZXN0aW1hdGlv biB0aGF04oCZcyBvbmUgcG9vciBkZWNpc2lvbg0KYW5kIHNob3VsZCBub3QgYmUgdXNlZCBhcyB0 aGUgYmFzaXMgb2YgdGhpcyAob3IgYW55KSBzdGFuZGFyZC4NCg0KSeKAmWQgcmF0aGVyIG5vdCBz dXBwb3J0IHJ0Y3Atbm8tbXV4IGFzIEkgc2VlIHplcm8gYWR2YW50YWdlcyBpbiBoYXZpbmcgaXQu IChJIGtub3cgdGhlb3JldGljYWxseSBpdCBtaWdodCBiZSBwb3NzaWJsZSB0byBnZXQNCmEgUlRD UCBwYWNrZXQgdGhyb3VnaCBhIGNvbmdlc3RlZCBuZXQgb24gYSBkaWZmZXJlbnQgcG9ydCB3aXRo IGEgc2VwYXJhdGUgZGlmZnNlcnYgc2V0dGluZyBidXQgdGhhdCBqdXN0IHNlZW1zIHNvIGNvbnRy aXZlZCkuDQoNClRpbS4NCg0KDQpPbiA2IEF1ZyAyMDE1LCBhdCAwNjo0NCwgQXN2ZXJlbiwgVG9s Z2EgPHRhc3ZlcmVuQHNvbnVzbmV0LmNvbTxtYWlsdG86dGFzdmVyZW5Ac29udXNuZXQuY29tPj4g d3JvdGU6DQoNClRoZXNlIGFzc3VtcHRpb25zIGFyZSBub3QgbmVjZXNzYXJpbHkgdHJ1ZSBpbiBh IHVuaXZlcnNhbCBzZW5zZSAobGlrZSBhbG1vc3QgYW55IG90aGVyIGFzc3VtcHRpb24gYWJvdXQg ZGlmZmVyZW50IGRlcGxveW1lbnQgbW9kZWxzKS4NCg0KRnVydGhlcm1vcmUsIGFuZCBtb3JlIGlt cG9ydGFudGx5LCB0aGVyZSBpcyBub3RoaW5nIG1hbmRhdGluZyBXZWJSVEMgZW5kcG9pbnRzIHRv IHN1cHBvcnQgbm9uLXJ0Y3AtbXV4LiBJdCBpcyBhIG5lZ290aWF0ZWQgZnVuY3Rpb25hbGl0eS4g QW55IGVudGl0eSBjYW4gZW5mb3JjZSBydGNwLW11eCBhcyBhIGxvY2FsIHBvbGljeS4NCg0KVGhl IGlzc3VlIHdpdGggc3VwcG9ydGluZyBub24tcnRjcC1tdXggc2VlbXMgdG8gYmUgbGFjayBvZiBj bGFyaXR5IGluIHRoZSByZWxldmFudCBzcGVjaWZpY2F0aW9ucy4gRml4aW5nIHRoaXMg4oCTcmVn YXJkbGVzcyBvZiB0aGUgb3V0Y29tZSBvZiBhbnkgb3RoZXIgZGlzY3Vzc2lvbi0gc2VlbXMgdG8g YmUgcHJ1ZGVudCBJTUhPLg0KDQpUaGFua3MsDQpUb2xnYQ0KDQpGcm9tOiBXeXNzLCBGZWxpeCBb bWFpbHRvOkZlbGl4Lld5c3NAaW5pbi5jb21dDQpTZW50OiBUaHVyc2RheSwgQXVndXN0IDA2LCAy MDE1IDY6MzcgQU0NClRvOiBDaHJpc3RlciBIb2xtYmVyZyA8Y2hyaXN0ZXIuaG9sbWJlcmdAZXJp Y3Nzb24uY29tPG1haWx0bzpjaHJpc3Rlci5ob2xtYmVyZ0Blcmljc3Nvbi5jb20+PjsgQXN2ZXJl biwgVG9sZ2EgPHRhc3ZlcmVuQHNvbnVzbmV0LmNvbTxtYWlsdG86dGFzdmVyZW5Ac29udXNuZXQu Y29tPj47IFNjaHdhcnosIEFsYnJlY2h0IChBbGJyZWNodCkgPGFsYnJlY2h0LnNjaHdhcnpAYWxj YXRlbC1sdWNlbnQuY29tPG1haWx0bzphbGJyZWNodC5zY2h3YXJ6QGFsY2F0ZWwtbHVjZW50LmNv bT4+OyBSb21hbiBTaHBvdW50IDxyb21hbkB0ZWx1cml4LmNvbTxtYWlsdG86cm9tYW5AdGVsdXJp eC5jb20+PjsgUmF1c2NoZW5iYWNoLCBVd2UgKE5va2lhIC0gREUvTXVuaWNoKSA8dXdlLnJhdXNj aGVuYmFjaEBub2tpYS5jb208bWFpbHRvOnV3ZS5yYXVzY2hlbmJhY2hAbm9raWEuY29tPj4NCkNj OiA8cnRjd2ViQGlldGYub3JnPG1haWx0bzpydGN3ZWJAaWV0Zi5vcmc+PiA8cnRjd2ViQGlldGYu b3JnPG1haWx0bzpydGN3ZWJAaWV0Zi5vcmc+Pg0KU3ViamVjdDogUmU6IFtydGN3ZWJdIFdoYXQg dGhlIGdhdGV3YXkgZHJhZnQgc2hvdWxkIHNheSBhYm91dCBtdXgvbm9uLW11eA0KDQpXaHkgc2hv dWxkbid0IHRoZSBnYXRld2F5IGJlIHJlcXVpcmVkIHRvIGRvIHRoZSBtdXgvZGVtdXg/ICBNYWtp bmcgdGhlIFdlYlJUQyBlbmRwb2ludHMgYSBsb3QgbW9yZSBjb21wbGV4IGp1c3Qgc28gdGhlIGxl Z2FjeSBpbnRlcm9wIG1pZ2h0IHBvdGVudGlhbGx5IGJlIGEgdGVlbnktdGlueSBiaXQgZWFzaWVy IG1ha2VzIG5vIHNlbnNlIElNSE8uICBBY3R1YWxseSwgdGhlIGdhdGV3YXkgd291bGQgbm90IGJl IGFibGUgdG8gZG8gImVuZC10by1lbmQiIHBhc3MtdGhyb3VnaCBhbnl3YXkgYXMgbGVnYWN5IGVx dWlwbWVudCB3aWxsIGVpdGhlciBiZSB1bmVuY3J5cHRlZCBvciB1c2UgU0RFUyAoUkZDIzQ1Njgp IGZvciBrZXkgZXhjaGFuZ2UuICBTbyB0aGUgZ2F0ZXdheSB3aWxsIGhhdmUgdG8gcGVyZm9ybSBE VExTLVNSVFAgdG8gU0RFUy1TUlRQIHRyYW5zY3J5cHRpb24tLXdoaWNoIGFscmVhZHkgaXMgd2F5 IG1vcmUgaGFzc2xlIHRoYW4gUlRQL1JUQ1AgbXV4L2RlbXV4Lg0KDQotLUZlbGl4DQoNCl9fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fDQpGcm9tOiBydGN3ZWIgPHJ0Y3dlYi1ib3VuY2Vz QGlldGYub3JnPG1haWx0bzpydGN3ZWItYm91bmNlc0BpZXRmLm9yZz4+IG9uIGJlaGFsZiBvZiBD aHJpc3RlciBIb2xtYmVyZyA8Y2hyaXN0ZXIuaG9sbWJlcmdAZXJpY3Nzb24uY29tPG1haWx0bzpj aHJpc3Rlci5ob2xtYmVyZ0Blcmljc3Nvbi5jb20+Pg0KU2VudDogVGh1cnNkYXksIEF1Z3VzdCA2 LCAyMDE1IDA1OjUxDQpUbzogQXN2ZXJlbiwgVG9sZ2E7IFNjaHdhcnosIEFsYnJlY2h0IChBbGJy ZWNodCk7IFJvbWFuIFNocG91bnQ7IFJhdXNjaGVuYmFjaCwgVXdlIChOb2tpYSAtIERFL011bmlj aCkNCkNjOiA8cnRjd2ViQGlldGYub3JnPG1haWx0bzpydGN3ZWJAaWV0Zi5vcmc+Pg0KU3ViamVj dDogUmU6IFtydGN3ZWJdIFdoYXQgdGhlIGdhdGV3YXkgZHJhZnQgc2hvdWxkIHNheSBhYm91dCBt dXgvbm9uLW11eA0KDQpIaSwNCg0KTm8gbWF0dGVyIHdoZXRoZXIgdGhlIGdhdGV3YXkgc3VwcG9y dHMgUlRQL1JUQ1AgbXV4IG9yIG5vdCwgdGhlcmUgYXJlIGNhc2VzIHdoZXJlIHRoZSBsZWdhY3kg bmV0d29yay9lbmRwb2ludHMgd2lsbCBub3QgdXNlIFJUUC9SVENQIG11eCwgc28gSSBndWVzcyBw ZW9wbGUgdGhlbiB3b3VsZCB3YW50IHRvIGJlIGFibGUgdG8gbmVnb3RpYXRlIG5vbi1tdXgg4oCc ZW5kLXRvLWVuZOKAnSwgcmF0aGVyIHRoYW4gaGF2aW5nIHRoZSBnYXRld2F5IHRvIGRlbXV4L211 eCBSVFAgYW5kIFJUQ1AuDQoNClJlZ2FyZHMsDQoNCkNocmlzdGVyDQoNCkZyb206IEFzdmVyZW4s IFRvbGdhIFttYWlsdG86dGFzdmVyZW5Ac29udXNuZXQuY29tXQ0KU2VudDogNi4gZWxva3V1dGEg MjAxNSAxMjoxOA0KVG86IFNjaHdhcnosIEFsYnJlY2h0IChBbGJyZWNodCk7IFJvbWFuIFNocG91 bnQ7IFJhdXNjaGVuYmFjaCwgVXdlIChOb2tpYSAtIERFL011bmljaCkNCkNjOiBleHQgRXJpYyBS ZXNjb3JsYTsgQ2hyaXN0ZXIgSG9sbWJlcmc7IEJlcm5hcmQgQWJvYmE7IDxydGN3ZWJAaWV0Zi5v cmc8bWFpbHRvOnJ0Y3dlYkBpZXRmLm9yZz4+DQpTdWJqZWN0OiBSZTogW3J0Y3dlYl0gV2hhdCB0 aGUgZ2F0ZXdheSBkcmFmdCBzaG91bGQgc2F5IGFib3V0IG11eC9ub24tbXV4DQoNCldoeSBzaG91 bGQgd2UgY29uc2lkZXIgM0dQUCB0aGUgc29sZSAib3duZXIvdXNlciIgb2YgdGhlIHRlcm0vZW50 aXR5IFdlYlJUQy1HVz8gSSB0aGluayBpdCBoYXMgYSBtdWNoIG1vcmUgZ2VuZXJhbCBtZWFuaW5n IGFuZCB1c2UgaW4gcHJhY3RpY2UuIEl0IGNhbiByZWZlciB0byBtYW55IGRpZmZlcmVudCB0eXBl cyBvZiBlbGVtZW50cyB3aGljaCBjYW4gYmUgZGVwbG95ZWQgaW4gbWFueSBkaWZmZXJlbnQgZW52 aXJvbm1lbnRzLCBoZW5jZSBhbnkgYXR0ZW1wdCB0byBkZWZpbmUgaXQgc3RyaWN0bHkvcmVzdHJp Y3QgaXRzIGNhcGFiaWxpdGllcyBhcmUgZnV0aWxlIElNSE8uDQoNClRoYW5rcywNClRvbGdhDQoN Cl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQpGcm9tOiBTY2h3YXJ6LCBBbGJyZWNo dCAoQWxicmVjaHQpIDxhbGJyZWNodC5zY2h3YXJ6QGFsY2F0ZWwtbHVjZW50LmNvbTxtYWlsdG86 YWxicmVjaHQuc2Nod2FyekBhbGNhdGVsLWx1Y2VudC5jb20+Pg0KU2VudDogVGh1cnNkYXksIEF1 Z3VzdCA2LCAyMDE1IDI6NDQgQU0NClRvOiBBc3ZlcmVuLCBUb2xnYTsgUm9tYW4gU2hwb3VudDsg UmF1c2NoZW5iYWNoLCBVd2UgKE5va2lhIC0gREUvTXVuaWNoKQ0KQ2M6IGV4dCBFcmljIFJlc2Nv cmxhOyBDaHJpc3RlciBIb2xtYmVyZzsgQmVybmFyZCBBYm9iYTsgPHJ0Y3dlYkBpZXRmLm9yZzxt YWlsdG86cnRjd2ViQGlldGYub3JnPj4NClN1YmplY3Q6IFJFOiBbcnRjd2ViXSBXaGF0IHRoZSBn YXRld2F5IGRyYWZ0IHNob3VsZCBzYXkgYWJvdXQgbXV4L25vbi1tdXgNCg0KVGhlIGNvbmNlcm5l ZCAzR1BQIFdlYlJUQyBnYXRld2F5ICgzR1BQIDIzLjMzNC8yOS4zMzQpIHN1cHBvcnRzIGFscmVh ZHkgUlRQL1JUQ1AgdHJhbnNwb3J0IG11bHRpcGxleGluZyAoc2luY2UgM0dQUCBSZWxlYXNlIDEy KSwgaS5lLiBzaG91bGQgbm90IGJlIHRoZSBsaW1pdGluZyBmYWN0b3IgaW4gdGhpcyBkaXNjdXNz aW9uLg0KRm9yIG9uZXMgaW50ZXJlc3RlZCBpbiB0aGUgUlRDUCBwb3J0IGFsbG9jYXRpb24gcnVs ZXMsIHNlZSBILjI0OC41NzoNCmh0dHBzOi8vd3d3Lml0dS5pbnQvcmVjL2RvbG9naW5fcHViLmFz cD9sYW5nPWUmaWQ9VC1SRUMtSC4yNDguNTctMjAxNDEwLUkhIVBERi1FJnR5cGU9aXRlbXMNCkNs YXVzZSA3IGRlc2NyaWJlcyBSVFAvUlRDUCB0cmFuc3BvcnQgbXVsdGlwbGV4aW5nLiBJVFUtVCBI LjI0OC41NyBpcyBhbHJlYWR5IHN1cHBvcnRlZCBieSAzR1BQIDI5LjMzNC4NCg0KVGhlIHJhdGlv bmFsZSBiZWhpbmQgdGhlIOKAnG9wdGlvbmFsIHRhZ2dpbmfigJ0gYnkgMjMuMjI4IGlzIGEgdGhp cmQgcmVhc29uLCBiZXlvbmQNCj4xLiBVc2luZyBkaWZmZXJlbnQgUU9TIHNldHRpbmdzIGZvciBS VENQIHZzIFJUUA0KPjIuIFNlbmRpbmcgUlRDUCB0byBhIGRpZmZlcmVudCBkZXZpY2UgZnJvbSBS VFANCg0KRG9u4oCZdCB3YW50IHRvIGdvIGluIHRoZSAzR1BQIHNwZWNpZmljIGRldGFpbHMsIGJ1 dCBpdCBoYXMgbm90aGluZyB0byBkbyB3aXRoIHRoZSAzR1BQIFVFLWVtYmVkZGVkIFdlYlJUQyBj bGllbnQgbm9yIGFueSBjb25zdHJhaW50cyBieSAzR1BQIFdlYlJUQyBnYXRld2F5cy4NCg0KVGh1 cywgYSBXZWJSVEMgZ2F0ZXdheSBNVVNUIHN1cHBvcnQgUlRQL1JUQ1AgdHJhbnNwb3J0IG11bHRp cGxleGluZyBkdWUgdG8gaXRzIHB1cnBvc2UgaW4gaW50ZXJ3b3JraW5nIHN1cHBvcnQuDQoNClJl Z2FyZHMsDQpBbGJyZWNodA0KDQoNCkZyb206IEFzdmVyZW4sIFRvbGdhIFttYWlsdG86dGFzdmVy ZW5Ac29udXNuZXQuY29tXQ0KU2VudDogTWl0dHdvY2gsIDUuIEF1Z3VzdCAyMDE1IDE5OjQ3DQpU bzogUm9tYW4gU2hwb3VudDsgUmF1c2NoZW5iYWNoLCBVd2UgKE5va2lhIC0gREUvTXVuaWNoKQ0K Q2M6IGV4dCBFcmljIFJlc2NvcmxhOyBTY2h3YXJ6LCBBbGJyZWNodCAoQWxicmVjaHQpOyBDaHJp c3RlciBIb2xtYmVyZzsgQmVybmFyZCBBYm9iYTsgPHJ0Y3dlYkBpZXRmLm9yZzxtYWlsdG86cnRj d2ViQGlldGYub3JnPj4NClN1YmplY3Q6IFJFOiBbcnRjd2ViXSBXaGF0IHRoZSBnYXRld2F5IGRy YWZ0IHNob3VsZCBzYXkgYWJvdXQgbXV4L25vbi1tdXgNCg0KaS0gSSBodW1ibHkgZGlzYWdyZWUg dGhhdCB1c2luZyBkaWZmZXJlbnQgUW9TIFJUQ1AvUlRQLCBlLmcuIGRpZmZlcmVudCBEaWZmU2Vy diB2YWx1ZXMgLCBzaG91bGQgYmUgZGlzbWlzc2VkLg0KaWktIExldCBtZSBhbHNvIGFkZCBhbm90 aGVyIHJlYXNvbiB3aHkgbm8tcnRjcC1tdXggbWF5IGJlIG5lZWRlZDogSW1wbGVtZW50YXRpb24g ZGlmZmljdWx0aWVzIGluIGNlcnRhaW4gR1dzLg0KDQpDb25zaWRlcmluZyB0aGF0IHRoZXJlIGlz IGFscmVhZHkgYSBuZWdvdGlhdGlvbiBtZWNoYW5pc20gZm9yIHJ0Y3AtbXV4IHN1cHBvcnQsIHRo YXQgaXQgY2FuIGJlIGRlLWZhY3RvIG1hbmRhdGVkIGJ5IHRoZSBjaG9pY2Ugb2YgYnJvd3NlcnMg Zm9yIEludGVybmV0LCBJIHRoaW5rIHdoYXQgQ2hyaXN0ZXIvQWxicmVjaHQgc3VnZ2VzdGVkIGlz IHRoZSByaWdodCB3YXkgdG8gbW92ZSBmb3J3YXJkOiBwcm92aWRlIGNsYXJpZmljYXRpb25zIGZv ciB2YWd1ZSBwb2ludHMuIEkgZG9u4oCZdCB1bmRlcnN0YW5kIHdoeSBsYWNrIG9mIGNsYXJpdHkg aW4gZXhpc3Rpbmcgc3BlY2lmaWNhdGlvbnMgc2hvdWxkIGNhdXNlIGltcG9zaW5nIHJlc3RyaWN0 aW9ucy4gVGhpcyB3b3VsZCBiZSBha2luIHRvIGRyb3BwaW5nIGEgZmVhdHVyZSBkdWUgdG8gYSBi dWcuIEluIHRoaXMgY2FzZSwgdGhlIOKAnGJ1Z+KAnSBpcyBsYWNrIG9mIGNsYXJpdHkgaW4gbm9y bWF0aXZlIHNwZWNpZmljYXRpb25zIGFuZCBpdCBjYW4gYmUgYWRkcmVzc2VkIGJ5IGZ1cnRoZXIg c3BlY2lmaWNhdGlvbi4NCg0KVGhhbmtzLA0KVG9sZ2ENCg0KRnJvbTogUm9tYW4gU2hwb3VudCBb bWFpbHRvOnJvbWFuQHRlbHVyaXguY29tXQ0KU2VudDogV2VkbmVzZGF5LCBBdWd1c3QgMDUsIDIw MTUgMTI6MjkgUE0NClRvOiBSYXVzY2hlbmJhY2gsIFV3ZSAoTm9raWEgLSBERS9NdW5pY2gpIDx1 d2UucmF1c2NoZW5iYWNoQG5va2lhLmNvbTxtYWlsdG86dXdlLnJhdXNjaGVuYmFjaEBub2tpYS5j b20+Pg0KQ2M6IGV4dCBFcmljIFJlc2NvcmxhIDxla3JAcnRmbS5jb208bWFpbHRvOmVrckBydGZt LmNvbT4+OyBTY2h3YXJ6LCBBbGJyZWNodCAoQWxicmVjaHQpIDxhbGJyZWNodC5zY2h3YXJ6QGFs Y2F0ZWwtbHVjZW50LmNvbTxtYWlsdG86YWxicmVjaHQuc2Nod2FyekBhbGNhdGVsLWx1Y2VudC5j b20+PjsgQXN2ZXJlbiwgVG9sZ2EgPHRhc3ZlcmVuQHNvbnVzbmV0LmNvbTxtYWlsdG86dGFzdmVy ZW5Ac29udXNuZXQuY29tPj47IENocmlzdGVyIEhvbG1iZXJnIDxjaHJpc3Rlci5ob2xtYmVyZ0Bl cmljc3Nvbi5jb208bWFpbHRvOmNocmlzdGVyLmhvbG1iZXJnQGVyaWNzc29uLmNvbT4+OyBCZXJu YXJkIEFib2JhIDxiZXJuYXJkLmFib2JhQGdtYWlsLmNvbTxtYWlsdG86YmVybmFyZC5hYm9iYUBn bWFpbC5jb20+PjsgPHJ0Y3dlYkBpZXRmLm9yZzxtYWlsdG86cnRjd2ViQGlldGYub3JnPj4gPHJ0 Y3dlYkBpZXRmLm9yZzxtYWlsdG86cnRjd2ViQGlldGYub3JnPj4NClN1YmplY3Q6IFJlOiBbcnRj d2ViXSBXaGF0IHRoZSBnYXRld2F5IGRyYWZ0IHNob3VsZCBzYXkgYWJvdXQgbXV4L25vbi1tdXgN Cg0KT24gV2VkLCBBdWcgNSwgMjAxNSBhdCA0OjQ3IEFNLCBSYXVzY2hlbmJhY2gsIFV3ZSAoTm9r aWEgLSBERS9NdW5pY2gpIDx1d2UucmF1c2NoZW5iYWNoQG5va2lhLmNvbTxtYWlsdG86dXdlLnJh dXNjaGVuYmFjaEBub2tpYS5jb20+PiB3cm90ZToNCk1lZGlhIGdhdGV3YXkgaW1wbGVtZW50YXRp b25zIGFjY29yZGluZyB0byAzR1BQIFRTIDIzLjIyOCBtYXkgbm90IHN1cHBvcnQgcnRjcC1tdXgs IGFzIHJ0Y3AtbXV4IGlzIG9wdGlvbmFsIHRoZXJlLg0KU28gaWYgd2UgZHJvcCBub24tbXV4IHN1 cHBvcnQgZnJvbSB3ZWIgYnJvd3NlcnMsIHRob3NlIG1lZGlhIGdhdGV3YXlzIHRoYXQgaGF2ZSBu b3QgaW1wbGVtZW50ZWQgcnRjcC1tdXggd2lsbCBzdG9wIGludGVyb3BlcmF0aW5nLg0KDQoNCkZp cnN0IG9mIGFsbCwgZG8geW91IGtub3cgb2YgYW55IFdlYlJUQyB0byBJTVMgZ2F0ZXdheXMgdGhh dCBkbyBub3QgaW1wbGVtZW50IHJ0Y3AtbXV4IG9uIHRoZSBXZWJSVEMgc2lkZT8gSSBzdHJvbmds eSBzdXNwZWN0IHRoZXJlIGFyZSBub25lLg0KDQpTZWNvbmQsIHRoZSBvbmx5IHJlYXNvbnMgbm90 IHRvIHVzZSBydGNwLW11eCB0aGF0IEkgY2FuIHRoaW5rIG9mIGFyZSB0aGUgZm9sbG93aW5nOg0K DQoxLiBVc2luZyBkaWZmZXJlbnQgUU9TIHNldHRpbmdzIGZvciBSVENQIHZzIFJUUA0KMi4gU2Vu ZGluZyBSVENQIHRvIGEgZGlmZmVyZW50IGRldmljZSBmcm9tIFJUUA0KDQpJIGRvIG5vdCB0aGlu ayB0aGUgZmlyc3QgdXNlIGNhc2Ugd2FycmFudHMgbWFraW5nIHJ0Y3AtbXV4IG9wdGlvbmFsLCBz aW5jZSwgcHJhY3RpY2FsbHkgbm8gb25lIGRvZXMgdGhpcy4NClNlY29uZCB1c2UgY2FzZSBpcyBh bHNvIGZhaXJseSBtYXJnaW5hbC4gUGx1cyBpdCBjYW4gYmUgaGFuZGxlZCBieSB0aGUgZ2F0ZXdh eSB3aGljaCBjYW4gc2VuZCBSVENQIHRvIG9uZSBkZXZpY2UgYW5kIFJUUCB0byBhbm90aGVyLg0K DQpTbywgdW5sZXNzIHNvbWVvbmUgY2FuIGNvbWUgdXAgd2l0aCBhIHVzZSBjYXNlIHdoeSBSVFAg YW5kIFJUQ1Agc2hvdWxkIHVzZSBkaWZmZXJlbnQgdHJhbnNwb3J0cywgSSB0aGluayBydGNwLW11 eCBzaG91bGQgYmUgbWFuZGF0b3J5Lg0KDQpSZWdhcmRzLA0KX19fX19fX19fX19fX18NClJvbWFu IFNocG91bnQNCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f DQpydGN3ZWIgbWFpbGluZyBsaXN0DQpydGN3ZWJAaWV0Zi5vcmc8bWFpbHRvOnJ0Y3dlYkBpZXRm Lm9yZz4NCmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vcnRjd2ViDQoNCg== --_000_9F33F40F6F2CD847824537F3C4E37DDF1E826A00MCHP04MSXglobal_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTIgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPCEtLVtp ZiAhbXNvXT48c3R5bGU+dlw6KiB7YmVoYXZpb3I6dXJsKCNkZWZhdWx0I1ZNTCk7fQ0Kb1w6KiB7 YmVoYXZpb3I6dXJsKCNkZWZhdWx0I1ZNTCk7fQ0Kd1w6KiB7YmVoYXZpb3I6dXJsKCNkZWZhdWx0 I1ZNTCk7fQ0KLnNoYXBlIHtiZWhhdmlvcjp1cmwoI2RlZmF1bHQjVk1MKTt9DQo8L3N0eWxlPjwh W2VuZGlmXS0tPjxzdHlsZT48IS0tDQovKiBGb250IERlZmluaXRpb25zICovDQpAZm9udC1mYWNl DQoJe2ZvbnQtZmFtaWx5OkhlbHZldGljYTsNCglwYW5vc2UtMToyIDExIDYgNCAyIDIgMiAyIDIg NDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OiJDYW1icmlhIE1hdGgiOw0KCXBhbm9zZS0x OjIgNCA1IDMgNSA0IDYgMyAyIDQ7fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseTpDYWxpYnJp Ow0KCXBhbm9zZS0xOjIgMTUgNSAyIDIgMiA0IDMgMiA0O30NCkBmb250LWZhY2UNCgl7Zm9udC1m YW1pbHk6VGFob21hOw0KCXBhbm9zZS0xOjIgMTEgNiA0IDMgNSA0IDQgMiA0O30NCkBmb250LWZh Y2UNCgl7Zm9udC1mYW1pbHk6Q29uc29sYXM7DQoJcGFub3NlLTE6MiAxMSA2IDkgMiAyIDQgMyAy IDQ7fQ0KLyogU3R5bGUgRGVmaW5pdGlvbnMgKi8NCnAuTXNvTm9ybWFsLCBsaS5Nc29Ob3JtYWws IGRpdi5Nc29Ob3JtYWwNCgl7bWFyZ2luOjBjbTsNCgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJ Zm9udC1zaXplOjEyLjBwdDsNCglmb250LWZhbWlseToiVGltZXMgTmV3IFJvbWFuIiwic2VyaWYi O30NCmE6bGluaywgc3Bhbi5Nc29IeXBlcmxpbmsNCgl7bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0K CWNvbG9yOmJsdWU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQphOnZpc2l0ZWQsIHNw YW4uTXNvSHlwZXJsaW5rRm9sbG93ZWQNCgl7bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCWNvbG9y OnB1cnBsZTsNCgl0ZXh0LWRlY29yYXRpb246dW5kZXJsaW5lO30NCnAuTXNvQWNldGF0ZSwgbGku TXNvQWNldGF0ZSwgZGl2Lk1zb0FjZXRhdGUNCgl7bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCW1z by1zdHlsZS1saW5rOiJCYWxsb29uIFRleHQgQ2hhciI7DQoJbWFyZ2luOjBjbTsNCgltYXJnaW4t Ym90dG9tOi4wMDAxcHQ7DQoJZm9udC1zaXplOjguMHB0Ow0KCWZvbnQtZmFtaWx5OiJUYWhvbWEi LCJzYW5zLXNlcmlmIjt9DQpzcGFuLmFwcGxlLWNvbnZlcnRlZC1zcGFjZQ0KCXttc28tc3R5bGUt bmFtZTphcHBsZS1jb252ZXJ0ZWQtc3BhY2U7fQ0Kc3Bhbi5CYWxsb29uVGV4dENoYXINCgl7bXNv LXN0eWxlLW5hbWU6IkJhbGxvb24gVGV4dCBDaGFyIjsNCgltc28tc3R5bGUtcHJpb3JpdHk6OTk7 DQoJbXNvLXN0eWxlLWxpbms6IkJhbGxvb24gVGV4dCI7DQoJZm9udC1mYW1pbHk6IlRhaG9tYSIs InNhbnMtc2VyaWYiO30NCnNwYW4uRW1haWxTdHlsZTIwDQoJe21zby1zdHlsZS10eXBlOnBlcnNv bmFsLXJlcGx5Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIiwic2Fucy1zZXJpZiI7DQoJY29sb3I6 IzFGNDk3RDt9DQouTXNvQ2hwRGVmYXVsdA0KCXttc28tc3R5bGUtdHlwZTpleHBvcnQtb25seTsN Cglmb250LXNpemU6MTAuMHB0O30NCkBwYWdlIFdvcmRTZWN0aW9uMQ0KCXtzaXplOjYxMi4wcHQg NzkyLjBwdDsNCgltYXJnaW46NzIuMHB0IDcyLjBwdCA3Mi4wcHQgNzIuMHB0O30NCmRpdi5Xb3Jk U2VjdGlvbjENCgl7cGFnZTpXb3JkU2VjdGlvbjE7fQ0KLS0+PC9zdHlsZT48IS0tW2lmIGd0ZSBt c28gOV0+PHhtbD4NCjxvOnNoYXBlZGVmYXVsdHMgdjpleHQ9ImVkaXQiIHNwaWRtYXg9IjEwMjYi IC8+DQo8L3htbD48IVtlbmRpZl0tLT48IS0tW2lmIGd0ZSBtc28gOV0+PHhtbD4NCjxvOnNoYXBl bGF5b3V0IHY6ZXh0PSJlZGl0Ij4NCjxvOmlkbWFwIHY6ZXh0PSJlZGl0IiBkYXRhPSIxIiAvPg0K PC9vOnNoYXBlbGF5b3V0PjwveG1sPjwhW2VuZGlmXS0tPg0KPC9oZWFkPg0KPGJvZHkgbGFuZz0i RU4tVVMiIGxpbms9ImJsdWUiIHZsaW5rPSJwdXJwbGUiPg0KPGRpdiBjbGFzcz0iV29yZFNlY3Rp b24xIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0 O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztj b2xvcjojMUY0OTdEIj4mIzQzOzEgdG8gd2hhdCBUaW0gc2FpZC48bzpwPjwvbzpwPjwvc3Bhbj48 L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtm b250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29s b3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2Fs aWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPkkgZG9u4oCZ dCB0aGluayB0aGlzIGRpc2N1c3Npb24gaXMgcmVhbGx5IGFib3V0IGdhdGV3YXlzIGF0IGFsbCBp dCBpcyBzdXJlbHkgYWJvdXQgd2hldGhlciBXZWJSVEMgYnJvd3NlcnMgaGF2ZSB0byBzdXBwb3J0 IG5vbi1tdXggYW5kIEkgZG9u4oCZdCByZWFsbHkgc2VlIGFueQ0KIGdvb2QgcmVhc29uIHdoeSB0 aGV5IG5lZWQgdG8uPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZx dW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9v OnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNp emU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJp ZiZxdW90Oztjb2xvcjojMUY0OTdEIj5JZiB3ZSBoYWQgdGhvdWdodCBhYm91dCB0aGlzIGF0IHRo ZSB0aW1lIHdlIG1hbmRhdGVkIERUTFMtU1JUUCB0aGVuIHdlIHdvdWxkIGhhdmUgbWFuZGF0ZWQg cnRwLW11eCBhdCB0aGUgc2FtZSB0aW1lIGJ1dCB1bmZvcnR1bmF0ZWx5IHdlIGRpZG7igJl0IGJ1 dCB3ZSBjYW4gZml4DQogdGhhdCBub3cuPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1 b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPjxv OnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0 eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1 b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj5BbmR5PG86cD48L286cD48L3NwYW4+ PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7 Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2Nv bG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0Nh bGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj48bzpwPiZu YnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8ZGl2IHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItbGVm dDpzb2xpZCBibHVlIDEuNXB0O3BhZGRpbmc6MGNtIDBjbSAwY20gNC4wcHQiPg0KPGRpdj4NCjxk aXYgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci10b3A6c29saWQgI0I1QzRERiAxLjBwdDtwYWRk aW5nOjMuMHB0IDBjbSAwY20gMGNtIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxiPjxzcGFuIHN0 eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O1RhaG9tYSZxdW90OywmcXVv dDtzYW5zLXNlcmlmJnF1b3Q7Ij5Gcm9tOjwvc3Bhbj48L2I+PHNwYW4gc3R5bGU9ImZvbnQtc2l6 ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7VGFob21hJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYm cXVvdDsiPiBydGN3ZWIgW21haWx0bzpydGN3ZWItYm91bmNlc0BpZXRmLm9yZ10NCjxiPk9uIEJl aGFsZiBPZiA8L2I+dGltIHBhbnRvbjxicj4NCjxiPlNlbnQ6PC9iPiAwNiBBdWd1c3QgMjAxNSAx Mzo1Mzxicj4NCjxiPlRvOjwvYj4gQXN2ZXJlbiwgVG9sZ2E8YnI+DQo8Yj5DYzo8L2I+ICZsdDty dGN3ZWJAaWV0Zi5vcmcmZ3Q7PGJyPg0KPGI+U3ViamVjdDo8L2I+IFJlOiBbcnRjd2ViXSBXaGF0 IHRoZSBnYXRld2F5IGRyYWZ0IHNob3VsZCBzYXkgYWJvdXQgbXV4L25vbi1tdXg8bzpwPjwvbzpw Pjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4m bmJzcDs8L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5TbyB3ZSBhcmUgcG9zaXRpbmcg dGhlIGV4aXN0ZW5jZSBvZiBhIHdlYlJUQyBnYXRld2F5IGRlc2lnbmVkIHRvIHN1cHBvcnQgdGhv dXNhbmRzIG9mIGNhbGxzIHdoaWNoIGRvZXMgSUNFIGFuZCBEVExTIGJ1dCB0aGU8bzpwPjwvbzpw PjwvcD4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ZGVzaWduZXIgZGVjaWRl ZCBkZWxpYmVyYXRlbHkgdG8gZG91YmxlIHRoZSBudW1iZXIgb2YgSUNFIHNlc3Npb25zIHJlcXVp cmVkIGFuZCBkb3VibGUgdGhlIG51bWJlciBvZiBEVExTIHNlc3Npb25zIChhbmQga2V5Jm5ic3A7 PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5nZW5l cmF0aW9uIGNvc3RzKSBzbyB0aGF0IHRoZXkgY2FuIHJ1biBSVENQIChvdmVyIElDRSBhbmQgRFRM Uykgb24gYSBzZXBhcmF0ZSBwb3J0LiBJbiBteSBlc3RpbWF0aW9uIHRoYXTigJlzIG9uZSBwb29y IGRlY2lzaW9uPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj5hbmQgc2hvdWxkIG5vdCBiZSB1c2VkIGFzIHRoZSBiYXNpcyBvZiB0aGlzIChvciBhbnkp IHN0YW5kYXJkLiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj5J4oCZZCByYXRoZXIgbm90IHN1cHBvcnQgcnRjcC1uby1tdXggYXMgSSBz ZWUgemVybyBhZHZhbnRhZ2VzIGluIGhhdmluZyBpdC4gKEkga25vdyB0aGVvcmV0aWNhbGx5IGl0 IG1pZ2h0IGJlIHBvc3NpYmxlIHRvIGdldDxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+YSBSVENQIHBhY2tldCB0aHJvdWdoIGEgY29uZ2VzdGVkIG5l dCBvbiBhIGRpZmZlcmVudCBwb3J0IHdpdGggYSBzZXBhcmF0ZSBkaWZmc2VydiBzZXR0aW5nIGJ1 dCB0aGF0IGp1c3Qgc2VlbXMgc28gY29udHJpdmVkKS48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0K PGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+ DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+VGltLjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+ DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rp dj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwv ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8YmxvY2txdW90ZSBzdHlsZT0ibWFyZ2luLXRvcDo1LjBwdDtt YXJnaW4tYm90dG9tOjUuMHB0Ij4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5PbiA2IEF1 ZyAyMDE1LCBhdCAwNjo0NCwgQXN2ZXJlbiwgVG9sZ2EgJmx0OzxhIGhyZWY9Im1haWx0bzp0YXN2 ZXJlbkBzb251c25ldC5jb20iPnRhc3ZlcmVuQHNvbnVzbmV0LmNvbTwvYT4mZ3Q7IHdyb3RlOjxv OnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwv bzpwPjwvcD4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9 ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtz YW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPlRoZXNlIGFzc3VtcHRpb25zIGFyZSBub3Qg bmVjZXNzYXJpbHkgdHJ1ZSBpbiBhIHVuaXZlcnNhbCBzZW5zZSAobGlrZSBhbG1vc3QgYW55IG90 aGVyIGFzc3VtcHRpb24gYWJvdXQgZGlmZmVyZW50IGRlcGxveW1lbnQgbW9kZWxzKS48L3NwYW4+ PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3Bh biBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7 LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+Jm5ic3A7PC9zcGFuPjxvOnA+ PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5 bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVv dDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPkZ1cnRoZXJtb3JlLCBhbmQgbW9yZSBp bXBvcnRhbnRseSwgdGhlcmUgaXMgbm90aGluZyBtYW5kYXRpbmcgV2ViUlRDIGVuZHBvaW50cyB0 byBzdXBwb3J0IG5vbi1ydGNwLW11eC4gSXQgaXMgYSBuZWdvdGlhdGVkIGZ1bmN0aW9uYWxpdHku IEFueSBlbnRpdHkgY2FuIGVuZm9yY2UNCiBydGNwLW11eCBhcyBhIGxvY2FsIHBvbGljeS48c3Bh biBjbGFzcz0iYXBwbGUtY29udmVydGVkLXNwYWNlIj4mbmJzcDs8L3NwYW4+PC9zcGFuPjxvOnA+ PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5 bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVv dDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPiZuYnNwOzwvc3Bhbj48bzpwPjwvbzpw PjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJm b250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fu cy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj5UaGUgaXNzdWUgd2l0aCBzdXBwb3J0aW5nIG5v bi1ydGNwLW11eCBzZWVtcyB0byBiZSBsYWNrIG9mIGNsYXJpdHkgaW4gdGhlIHJlbGV2YW50IHNw ZWNpZmljYXRpb25zLiBGaXhpbmcgdGhpcyDigJNyZWdhcmRsZXNzIG9mIHRoZSBvdXRjb21lIG9m IGFueSBvdGhlciBkaXNjdXNzaW9uLQ0KIHNlZW1zIHRvIGJlIHBydWRlbnQgSU1ITy48L3NwYW4+ PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3Bh biBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7 LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+Jm5ic3A7PC9zcGFuPjxvOnA+ PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5 bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVv dDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPlRoYW5rcyw8L3NwYW4+PG86cD48L286 cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0i Zm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3Nh bnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+VG9sZ2E8L3NwYW4+PG86cD48L286cD48L3A+ DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1z aXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2Vy aWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+Jm5ic3A7PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9k aXY+DQo8ZGl2IHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItbGVmdDpzb2xpZCBibHVlIDEuNXB0 O3BhZGRpbmc6MGNtIDBjbSAwY20gNC4wcHQiPg0KPGRpdj4NCjxkaXYgc3R5bGU9ImJvcmRlcjpu b25lO2JvcmRlci10b3A6c29saWQgI0UxRTFFMSAxLjBwdDtwYWRkaW5nOjMuMHB0IDBjbSAwY20g MGNtIj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48Yj48c3BhbiBzdHlsZT0iZm9udC1z aXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2Vy aWYmcXVvdDsiPkZyb206PC9zcGFuPjwvYj48c3BhbiBjbGFzcz0iYXBwbGUtY29udmVydGVkLXNw YWNlIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxp YnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPiZuYnNwOzwvc3Bhbj48L3NwYW4+PHNw YW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90 OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij5XeXNzLA0KIEZlbGl4IFs8YSBocmVmPSJtYWlsdG86 RmVsaXguV3lzc0BpbmluLmNvbSI+bWFpbHRvOkZlbGl4Lld5c3NAaW5pbi5jb208L2E+XTxzcGFu IGNsYXNzPSJhcHBsZS1jb252ZXJ0ZWQtc3BhY2UiPiZuYnNwOzwvc3Bhbj48YnI+DQo8Yj5TZW50 OjwvYj48c3BhbiBjbGFzcz0iYXBwbGUtY29udmVydGVkLXNwYWNlIj4mbmJzcDs8L3NwYW4+VGh1 cnNkYXksIEF1Z3VzdCAwNiwgMjAxNSA2OjM3IEFNPGJyPg0KPGI+VG86PC9iPjxzcGFuIGNsYXNz PSJhcHBsZS1jb252ZXJ0ZWQtc3BhY2UiPiZuYnNwOzwvc3Bhbj5DaHJpc3RlciBIb2xtYmVyZyAm bHQ7PGEgaHJlZj0ibWFpbHRvOmNocmlzdGVyLmhvbG1iZXJnQGVyaWNzc29uLmNvbSI+Y2hyaXN0 ZXIuaG9sbWJlcmdAZXJpY3Nzb24uY29tPC9hPiZndDs7IEFzdmVyZW4sIFRvbGdhICZsdDs8YSBo cmVmPSJtYWlsdG86dGFzdmVyZW5Ac29udXNuZXQuY29tIj50YXN2ZXJlbkBzb251c25ldC5jb208 L2E+Jmd0OzsgU2Nod2FyeiwgQWxicmVjaHQNCiAoQWxicmVjaHQpICZsdDs8YSBocmVmPSJtYWls dG86YWxicmVjaHQuc2Nod2FyekBhbGNhdGVsLWx1Y2VudC5jb20iPmFsYnJlY2h0LnNjaHdhcnpA YWxjYXRlbC1sdWNlbnQuY29tPC9hPiZndDs7IFJvbWFuIFNocG91bnQgJmx0OzxhIGhyZWY9Im1h aWx0bzpyb21hbkB0ZWx1cml4LmNvbSI+cm9tYW5AdGVsdXJpeC5jb208L2E+Jmd0OzsgUmF1c2No ZW5iYWNoLCBVd2UgKE5va2lhIC0gREUvTXVuaWNoKSAmbHQ7PGEgaHJlZj0ibWFpbHRvOnV3ZS5y YXVzY2hlbmJhY2hAbm9raWEuY29tIj51d2UucmF1c2NoZW5iYWNoQG5va2lhLmNvbTwvYT4mZ3Q7 PGJyPg0KPGI+Q2M6PC9iPjxzcGFuIGNsYXNzPSJhcHBsZS1jb252ZXJ0ZWQtc3BhY2UiPiZuYnNw Ozwvc3Bhbj4mbHQ7PGEgaHJlZj0ibWFpbHRvOnJ0Y3dlYkBpZXRmLm9yZyI+cnRjd2ViQGlldGYu b3JnPC9hPiZndDsgJmx0OzxhIGhyZWY9Im1haWx0bzpydGN3ZWJAaWV0Zi5vcmciPnJ0Y3dlYkBp ZXRmLm9yZzwvYT4mZ3Q7PGJyPg0KPGI+U3ViamVjdDo8L2I+PHNwYW4gY2xhc3M9ImFwcGxlLWNv bnZlcnRlZC1zcGFjZSI+Jm5ic3A7PC9zcGFuPlJlOiBbcnRjd2ViXSBXaGF0IHRoZSBnYXRld2F5 IGRyYWZ0IHNob3VsZCBzYXkgYWJvdXQgbXV4L25vbi1tdXg8L3NwYW4+PG86cD48L286cD48L3A+ DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Jm5i c3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXYgaWQ9ImRpdnRhZ2RlZmF1bHR3cmFwcGVy Ij4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0iYmFja2dyb3VuZDp3aGl0ZSI+ PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1z ZXJpZiZxdW90OyI+V2h5IHNob3VsZG4ndCB0aGUgZ2F0ZXdheSBiZSByZXF1aXJlZCB0byBkbyB0 aGUgbXV4L2RlbXV4PyZuYnNwOyBNYWtpbmcgdGhlIFdlYlJUQyBlbmRwb2ludHMgYSBsb3QgbW9y ZSBjb21wbGV4IGp1c3Qgc28gdGhlIGxlZ2FjeSBpbnRlcm9wIG1pZ2h0IHBvdGVudGlhbGx5IGJl IGEgdGVlbnktdGlueQ0KIGJpdCBlYXNpZXIgbWFrZXMgbm8gc2Vuc2UgSU1ITy4mbmJzcDsgQWN0 dWFsbHksIHRoZSBnYXRld2F5IHdvdWxkIG5vdCBiZSBhYmxlIHRvIGRvICZxdW90O2VuZC10by1l bmQmcXVvdDsgcGFzcy10aHJvdWdoIGFueXdheSBhcyBsZWdhY3kgZXF1aXBtZW50IHdpbGwgZWl0 aGVyIGJlIHVuZW5jcnlwdGVkIG9yIHVzZSBTREVTIChSRkMjNDU2OCkgZm9yIGtleSBleGNoYW5n ZS4mbmJzcDsgU28gdGhlIGdhdGV3YXkgd2lsbCBoYXZlIHRvIHBlcmZvcm0gRFRMUy1TUlRQIHRv IFNERVMtU1JUUA0KIHRyYW5zY3J5cHRpb24tLXdoaWNoIGFscmVhZHkgaXMgd2F5IG1vcmUgaGFz c2xlIHRoYW4gUlRQL1JUQ1AgbXV4L2RlbXV4Ljwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2 Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJiYWNrZ3JvdW5kOndoaXRlIj48 c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNl cmlmJnF1b3Q7Ij4mbmJzcDs8L3NwYW4+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0iYmFja2dyb3VuZDp3aGl0ZSI+PHNwYW4gc3R5bGU9 ImZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+ LS1GZWxpeDwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiIHN0eWxlPSJiYWNrZ3JvdW5kOndoaXRlIj48c3BhbiBzdHlsZT0iZm9udC1mYW1p bHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij4mbmJzcDs8L3Nw YW4+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2IGNsYXNzPSJNc29Ob3JtYWwi IGFsaWduPSJjZW50ZXIiIHN0eWxlPSJ0ZXh0LWFsaWduOmNlbnRlcjtiYWNrZ3JvdW5kOndoaXRl Ij4NCjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3Nh bnMtc2VyaWYmcXVvdDsiPg0KPGhyIHNpemU9IjIiIHdpZHRoPSI5OCUiIGFsaWduPSJjZW50ZXIi Pg0KPC9zcGFuPjwvZGl2Pg0KPGRpdiBpZD0iZGl2UnBseUZ3ZE1zZyI+DQo8ZGl2Pg0KPHAgY2xh c3M9Ik1zb05vcm1hbCIgc3R5bGU9ImJhY2tncm91bmQ6d2hpdGUiPjxiPjxzcGFuIHN0eWxlPSJm b250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fu cy1zZXJpZiZxdW90OyI+RnJvbTo8L3NwYW4+PC9iPjxzcGFuIGNsYXNzPSJhcHBsZS1jb252ZXJ0 ZWQtc3BhY2UiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90 O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+Jm5ic3A7PC9zcGFuPjwvc3Bh bj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJp JnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPnJ0Y3dlYg0KICZsdDs8YSBocmVmPSJtYWls dG86cnRjd2ViLWJvdW5jZXNAaWV0Zi5vcmciPjxzcGFuIHN0eWxlPSJjb2xvcjpwdXJwbGUiPnJ0 Y3dlYi1ib3VuY2VzQGlldGYub3JnPC9zcGFuPjwvYT4mZ3Q7IG9uIGJlaGFsZiBvZiBDaHJpc3Rl ciBIb2xtYmVyZyAmbHQ7PGEgaHJlZj0ibWFpbHRvOmNocmlzdGVyLmhvbG1iZXJnQGVyaWNzc29u LmNvbSI+PHNwYW4gc3R5bGU9ImNvbG9yOnB1cnBsZSI+Y2hyaXN0ZXIuaG9sbWJlcmdAZXJpY3Nz b24uY29tPC9zcGFuPjwvYT4mZ3Q7PGJyPg0KPGI+U2VudDo8L2I+PHNwYW4gY2xhc3M9ImFwcGxl LWNvbnZlcnRlZC1zcGFjZSI+Jm5ic3A7PC9zcGFuPlRodXJzZGF5LCBBdWd1c3QgNiwgMjAxNSAw NTo1MTxicj4NCjxiPlRvOjwvYj48c3BhbiBjbGFzcz0iYXBwbGUtY29udmVydGVkLXNwYWNlIj4m bmJzcDs8L3NwYW4+QXN2ZXJlbiwgVG9sZ2E7IFNjaHdhcnosIEFsYnJlY2h0IChBbGJyZWNodCk7 IFJvbWFuIFNocG91bnQ7IFJhdXNjaGVuYmFjaCwgVXdlIChOb2tpYSAtIERFL011bmljaCk8YnI+ DQo8Yj5DYzo8L2I+PHNwYW4gY2xhc3M9ImFwcGxlLWNvbnZlcnRlZC1zcGFjZSI+Jm5ic3A7PC9z cGFuPiZsdDs8YSBocmVmPSJtYWlsdG86cnRjd2ViQGlldGYub3JnIj48c3BhbiBzdHlsZT0iY29s b3I6cHVycGxlIj5ydGN3ZWJAaWV0Zi5vcmc8L3NwYW4+PC9hPiZndDs8YnI+DQo8Yj5TdWJqZWN0 OjwvYj48c3BhbiBjbGFzcz0iYXBwbGUtY29udmVydGVkLXNwYWNlIj4mbmJzcDs8L3NwYW4+UmU6 IFtydGN3ZWJdIFdoYXQgdGhlIGdhdGV3YXkgZHJhZnQgc2hvdWxkIHNheSBhYm91dCBtdXgvbm9u LW11eDwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIiBzdHlsZT0iYmFja2dyb3VuZDp3aGl0ZSI+PHNwYW4gc3R5bGU9ImZvbnQt ZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+Jm5ic3A7 PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxk aXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9ImJhY2tncm91bmQ6d2hpdGUi PjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkm cXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj5IaSw8L3NwYW4+PG86 cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0i YmFja2dyb3VuZDp3aGl0ZSI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1p bHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5 N0QiPiZuYnNwOzwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiIHN0eWxlPSJiYWNrZ3JvdW5kOndoaXRlIj48c3BhbiBzdHlsZT0iZm9udC1z aXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2Vy aWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+Tm8gbWF0dGVyIHdoZXRoZXIgdGhlIGdhdGV3YXkgc3Vw cG9ydHMgUlRQL1JUQ1AgbXV4IG9yIG5vdCwgdGhlcmUgYXJlIGNhc2VzIHdoZXJlIHRoZSBsZWdh Y3kgbmV0d29yay9lbmRwb2ludHMgd2lsbCBub3QgdXNlIFJUUC9SVENQDQogbXV4LCBzbyBJIGd1 ZXNzIHBlb3BsZSB0aGVuIHdvdWxkIHdhbnQgdG8gYmUgYWJsZSB0byBuZWdvdGlhdGUgbm9uLW11 eCDigJxlbmQtdG8tZW5k4oCdLCByYXRoZXIgdGhhbiBoYXZpbmcgdGhlIGdhdGV3YXkgdG8gZGVt dXgvbXV4IFJUUCBhbmQgUlRDUC48L3NwYW4+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0iYmFja2dyb3VuZDp3aGl0ZSI+PHNwYW4gc3R5 bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVv dDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPiZuYnNwOzwvc3Bhbj48bzpwPjwvbzpw PjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJiYWNrZ3Jv dW5kOndoaXRlIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVv dDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+UmVn YXJkcyw8L3NwYW4+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIiBzdHlsZT0iYmFja2dyb3VuZDp3aGl0ZSI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTox MS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1 b3Q7O2NvbG9yOiMxRjQ5N0QiPiZuYnNwOzwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0K PGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJiYWNrZ3JvdW5kOndoaXRlIj48c3Bh biBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7 LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+Q2hyaXN0ZXI8L3NwYW4+PG86 cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0i YmFja2dyb3VuZDp3aGl0ZSI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1p bHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5 N0QiPiZuYnNwOzwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxkaXYgc3R5 bGU9ImJvcmRlcjpub25lO2JvcmRlci10b3A6c29saWQgI0I1QzRERiAxLjBwdDtwYWRkaW5nOjMu MHB0IDBjbSAwY20gMGNtIj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0iYmFj a2dyb3VuZDp3aGl0ZSI+PGI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1p bHk6JnF1b3Q7VGFob21hJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPkZyb206PC9zcGFu PjwvYj48c3BhbiBjbGFzcz0iYXBwbGUtY29udmVydGVkLXNwYWNlIj48c3BhbiBzdHlsZT0iZm9u dC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtUYWhvbWEmcXVvdDssJnF1b3Q7c2Fucy1z ZXJpZiZxdW90OyI+Jm5ic3A7PC9zcGFuPjwvc3Bhbj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEw LjBwdDtmb250LWZhbWlseTomcXVvdDtUYWhvbWEmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90 OyI+QXN2ZXJlbiwNCiBUb2xnYSBbPGEgaHJlZj0ibWFpbHRvOnRhc3ZlcmVuQHNvbnVzbmV0LmNv bSI+PHNwYW4gc3R5bGU9ImNvbG9yOnB1cnBsZSI+bWFpbHRvOnRhc3ZlcmVuQHNvbnVzbmV0LmNv bTwvc3Bhbj48L2E+XTxzcGFuIGNsYXNzPSJhcHBsZS1jb252ZXJ0ZWQtc3BhY2UiPiZuYnNwOzwv c3Bhbj48YnI+DQo8Yj5TZW50OjwvYj48c3BhbiBjbGFzcz0iYXBwbGUtY29udmVydGVkLXNwYWNl Ij4mbmJzcDs8L3NwYW4+Ni4gZWxva3V1dGEgMjAxNSAxMjoxODxicj4NCjxiPlRvOjwvYj48c3Bh biBjbGFzcz0iYXBwbGUtY29udmVydGVkLXNwYWNlIj4mbmJzcDs8L3NwYW4+U2Nod2FyeiwgQWxi cmVjaHQgKEFsYnJlY2h0KTsgUm9tYW4gU2hwb3VudDsgUmF1c2NoZW5iYWNoLCBVd2UgKE5va2lh IC0gREUvTXVuaWNoKTxicj4NCjxiPkNjOjwvYj48c3BhbiBjbGFzcz0iYXBwbGUtY29udmVydGVk LXNwYWNlIj4mbmJzcDs8L3NwYW4+ZXh0IEVyaWMgUmVzY29ybGE7IENocmlzdGVyIEhvbG1iZXJn OyBCZXJuYXJkIEFib2JhOyAmbHQ7PGEgaHJlZj0ibWFpbHRvOnJ0Y3dlYkBpZXRmLm9yZyI+PHNw YW4gc3R5bGU9ImNvbG9yOnB1cnBsZSI+cnRjd2ViQGlldGYub3JnPC9zcGFuPjwvYT4mZ3Q7PGJy Pg0KPGI+U3ViamVjdDo8L2I+PHNwYW4gY2xhc3M9ImFwcGxlLWNvbnZlcnRlZC1zcGFjZSI+Jm5i c3A7PC9zcGFuPlJlOiBbcnRjd2ViXSBXaGF0IHRoZSBnYXRld2F5IGRyYWZ0IHNob3VsZCBzYXkg YWJvdXQgbXV4L25vbi1tdXg8L3NwYW4+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0K PC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9ImJhY2tncm91bmQ6d2hp dGUiPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2IGlkPSJkaXZ0YWdkZWZhdWx0 d3JhcHBlciI+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9ImJhY2tncm91bmQ6 d2hpdGUiPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90 O3NhbnMtc2VyaWYmcXVvdDsiPldoeSBzaG91bGQgd2UgY29uc2lkZXIgM0dQUCB0aGUgc29sZSAm cXVvdDtvd25lci91c2VyJnF1b3Q7IG9mIHRoZSB0ZXJtL2VudGl0eSBXZWJSVEMtR1c/IEkgdGhp bmsgaXQgaGFzIGEgbXVjaCBtb3JlIGdlbmVyYWwgbWVhbmluZyBhbmQgdXNlIGluIHByYWN0aWNl LiBJdCBjYW4gcmVmZXIgdG8gbWFueQ0KIGRpZmZlcmVudCB0eXBlcyBvZiBlbGVtZW50cyB3aGlj aCBjYW4gYmUgZGVwbG95ZWQgaW4gbWFueSBkaWZmZXJlbnQgZW52aXJvbm1lbnRzLCBoZW5jZSBh bnkgYXR0ZW1wdCB0byBkZWZpbmUgaXQgc3RyaWN0bHkvcmVzdHJpY3QgaXRzIGNhcGFiaWxpdGll cyBhcmUgZnV0aWxlIElNSE8uPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0K PHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9ImJhY2tncm91bmQ6d2hpdGUiPjxzcGFuIHN0eWxl PSJmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsi PiZuYnNwOzwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiIHN0eWxlPSJiYWNrZ3JvdW5kOndoaXRlIj48c3BhbiBzdHlsZT0iZm9udC1mYW1p bHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij5UaGFua3MsPC9z cGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIg c3R5bGU9ImJhY2tncm91bmQ6d2hpdGUiPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtD YWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPlRvbGdhPC9zcGFuPjxvOnA+PC9v OnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9ImJhY2tn cm91bmQ6d2hpdGUiPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7 LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPiZuYnNwOzwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwv ZGl2Pg0KPGRpdj4NCjxkaXYgY2xhc3M9Ik1zb05vcm1hbCIgYWxpZ249ImNlbnRlciIgc3R5bGU9 InRleHQtYWxpZ246Y2VudGVyO2JhY2tncm91bmQ6d2hpdGUiPg0KPHNwYW4gc3R5bGU9ImZvbnQt ZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+DQo8aHIg c2l6ZT0iMiIgd2lkdGg9Ijk4JSIgYWxpZ249ImNlbnRlciI+DQo8L3NwYW4+PC9kaXY+DQo8ZGl2 IGlkPSJkaXZScGx5RndkTXNnIj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0i YmFja2dyb3VuZDp3aGl0ZSI+PGI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1m YW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij5Gcm9tOjwv c3Bhbj48L2I+PHNwYW4gY2xhc3M9ImFwcGxlLWNvbnZlcnRlZC1zcGFjZSI+PHNwYW4gc3R5bGU9 ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtz YW5zLXNlcmlmJnF1b3Q7Ij4mbmJzcDs8L3NwYW4+PC9zcGFuPjxzcGFuIHN0eWxlPSJmb250LXNp emU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJp ZiZxdW90OyI+U2Nod2FyeiwNCiBBbGJyZWNodCAoQWxicmVjaHQpICZsdDs8YSBocmVmPSJtYWls dG86YWxicmVjaHQuc2Nod2FyekBhbGNhdGVsLWx1Y2VudC5jb20iPjxzcGFuIHN0eWxlPSJjb2xv cjpwdXJwbGUiPmFsYnJlY2h0LnNjaHdhcnpAYWxjYXRlbC1sdWNlbnQuY29tPC9zcGFuPjwvYT4m Z3Q7PGJyPg0KPGI+U2VudDo8L2I+PHNwYW4gY2xhc3M9ImFwcGxlLWNvbnZlcnRlZC1zcGFjZSI+ Jm5ic3A7PC9zcGFuPlRodXJzZGF5LCBBdWd1c3QgNiwgMjAxNSAyOjQ0IEFNPGJyPg0KPGI+VG86 PC9iPjxzcGFuIGNsYXNzPSJhcHBsZS1jb252ZXJ0ZWQtc3BhY2UiPiZuYnNwOzwvc3Bhbj5Bc3Zl cmVuLCBUb2xnYTsgUm9tYW4gU2hwb3VudDsgUmF1c2NoZW5iYWNoLCBVd2UgKE5va2lhIC0gREUv TXVuaWNoKTxicj4NCjxiPkNjOjwvYj48c3BhbiBjbGFzcz0iYXBwbGUtY29udmVydGVkLXNwYWNl Ij4mbmJzcDs8L3NwYW4+ZXh0IEVyaWMgUmVzY29ybGE7IENocmlzdGVyIEhvbG1iZXJnOyBCZXJu YXJkIEFib2JhOyAmbHQ7PGEgaHJlZj0ibWFpbHRvOnJ0Y3dlYkBpZXRmLm9yZyI+PHNwYW4gc3R5 bGU9ImNvbG9yOnB1cnBsZSI+cnRjd2ViQGlldGYub3JnPC9zcGFuPjwvYT4mZ3Q7PGJyPg0KPGI+ U3ViamVjdDo8L2I+PHNwYW4gY2xhc3M9ImFwcGxlLWNvbnZlcnRlZC1zcGFjZSI+Jm5ic3A7PC9z cGFuPlJFOiBbcnRjd2ViXSBXaGF0IHRoZSBnYXRld2F5IGRyYWZ0IHNob3VsZCBzYXkgYWJvdXQg bXV4L25vbi1tdXg8L3NwYW4+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2Pg0K PHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9ImJhY2tncm91bmQ6d2hpdGUiPjxzcGFuIHN0eWxl PSJmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsi PiZuYnNwOzwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjxk aXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJiYWNrZ3JvdW5k OndoaXRlIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTpDb25zb2xh cztjb2xvcjojMUY0OTdEIj5UaGUgY29uY2VybmVkIDNHUFAgV2ViUlRDIGdhdGV3YXkgKDNHUFAg MjMuMzM0LzI5LjMzNCkgc3VwcG9ydHMgYWxyZWFkeSBSVFAvUlRDUCB0cmFuc3BvcnQgbXVsdGlw bGV4aW5nIChzaW5jZSAzR1BQIFJlbGVhc2UgMTIpLCBpLmUuIHNob3VsZCBub3QNCiBiZSB0aGUg bGltaXRpbmcgZmFjdG9yIGluIHRoaXMgZGlzY3Vzc2lvbi48c3BhbiBjbGFzcz0iYXBwbGUtY29u dmVydGVkLXNwYWNlIj4mbmJzcDs8L3NwYW4+PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+ DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9ImJhY2tncm91bmQ6d2hpdGUiPjxz cGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OkNvbnNvbGFzO2NvbG9yOiMx RjQ5N0QiPkZvciBvbmVzIGludGVyZXN0ZWQgaW4gdGhlIFJUQ1AgcG9ydCBhbGxvY2F0aW9uIHJ1 bGVzLCBzZWUgSC4yNDguNTc6PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0K PHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9ImJhY2tncm91bmQ6d2hpdGUiPjxzcGFuIHN0eWxl PSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OkNvbnNvbGFzO2NvbG9yOiMxRjQ5N0QiPjxh IGhyZWY9Imh0dHBzOi8vd3d3Lml0dS5pbnQvcmVjL2RvbG9naW5fcHViLmFzcD9sYW5nPWUmYW1w O2lkPVQtUkVDLUguMjQ4LjU3LTIwMTQxMC1JISFQREYtRSZhbXA7dHlwZT1pdGVtcyIgdGl0bGU9 IkNtZCYjNDM7Q2xpY2sgb3IgdGFwIHRvIGZvbGxvdyB0aGUgbGluayI+PHNwYW4gc3R5bGU9ImNv bG9yOnB1cnBsZSI+aHR0cHM6Ly93d3cuaXR1LmludC9yZWMvZG9sb2dpbl9wdWIuYXNwP2xhbmc9 ZSZhbXA7aWQ9VC1SRUMtSC4yNDguNTctMjAxNDEwLUkhIVBERi1FJmFtcDt0eXBlPWl0ZW1zPC9z cGFuPjwvYT48L3NwYW4+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIiBzdHlsZT0iYmFja2dyb3VuZDp3aGl0ZSI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6 ZToxMS4wcHQ7Zm9udC1mYW1pbHk6Q29uc29sYXM7Y29sb3I6IzFGNDk3RCI+Q2xhdXNlIDcgZGVz Y3JpYmVzIFJUUC9SVENQIHRyYW5zcG9ydCBtdWx0aXBsZXhpbmcuIElUVS1UIEguMjQ4LjU3IGlz IGFscmVhZHkgc3VwcG9ydGVkIGJ5IDNHUFAgMjkuMzM0Ljwvc3Bhbj48bzpwPjwvbzpwPjwvcD4N CjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJiYWNrZ3JvdW5kOndo aXRlIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTpDb25zb2xhcztj b2xvcjojMUY0OTdEIj4mbmJzcDs8L3NwYW4+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0iYmFja2dyb3VuZDp3aGl0ZSI+PHNwYW4gc3R5 bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6Q29uc29sYXM7Y29sb3I6IzFGNDk3RCI+ VGhlIHJhdGlvbmFsZSBiZWhpbmQgdGhlIOKAnG9wdGlvbmFsIHRhZ2dpbmfigJ0gYnkgMjMuMjI4 IGlzIGEgdGhpcmQgcmVhc29uLCBiZXlvbmQ8L3NwYW4+PG86cD48L286cD48L3A+DQo8L2Rpdj4N CjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0iYmFja2dyb3VuZDp3aGl0ZSI+PHNw YW4gc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJp ZiZxdW90OyI+Jmd0OzEuIFVzaW5nIGRpZmZlcmVudCBRT1Mgc2V0dGluZ3MgZm9yIFJUQ1AgdnMg UlRQPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05v cm1hbCIgc3R5bGU9ImJhY2tncm91bmQ6d2hpdGUiPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTom cXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPiZndDsyLiBTZW5kaW5n IFJUQ1AgdG8gYSBkaWZmZXJlbnQgZGV2aWNlIGZyb20gUlRQPC9zcGFuPjxvOnA+PC9vOnA+PC9w Pg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9ImJhY2tncm91bmQ6 d2hpdGUiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OkNvbnNvbGFz O2NvbG9yOiMxRjQ5N0QiPiZuYnNwOzwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRp dj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJiYWNrZ3JvdW5kOndoaXRlIj48c3BhbiBz dHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTpDb25zb2xhcztjb2xvcjojMUY0OTdE Ij5Eb27igJl0IHdhbnQgdG8gZ28gaW4gdGhlIDNHUFAgc3BlY2lmaWMgZGV0YWlscywgYnV0IGl0 IGhhcyBub3RoaW5nIHRvIGRvIHdpdGggdGhlIDNHUFAgVUUtZW1iZWRkZWQgV2ViUlRDIGNsaWVu dCBub3IgYW55IGNvbnN0cmFpbnRzIGJ5IDNHUFAgV2ViUlRDDQogZ2F0ZXdheXMuPC9zcGFuPjxv OnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9 ImJhY2tncm91bmQ6d2hpdGUiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFt aWx5OkNvbnNvbGFzO2NvbG9yOiMxRjQ5N0QiPiZuYnNwOzwvc3Bhbj48bzpwPjwvbzpwPjwvcD4N CjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJiYWNrZ3JvdW5kOndo aXRlIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTpDb25zb2xhcztj b2xvcjojMUY0OTdEIj5UaHVzLCBhIFdlYlJUQyBnYXRld2F5IE1VU1Qgc3VwcG9ydCBSVFAvUlRD UCB0cmFuc3BvcnQgbXVsdGlwbGV4aW5nIGR1ZSB0byBpdHMgcHVycG9zZSBpbiBpbnRlcndvcmtp bmcgc3VwcG9ydC48L3NwYW4+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIiBzdHlsZT0iYmFja2dyb3VuZDp3aGl0ZSI+PHNwYW4gc3R5bGU9ImZvbnQt c2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6Q29uc29sYXM7Y29sb3I6IzFGNDk3RCI+Jm5ic3A7PC9z cGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIg c3R5bGU9ImJhY2tncm91bmQ6d2hpdGUiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2Zv bnQtZmFtaWx5OkNvbnNvbGFzO2NvbG9yOiMxRjQ5N0QiPlJlZ2FyZHMsPC9zcGFuPjxvOnA+PC9v OnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9ImJhY2tn cm91bmQ6d2hpdGUiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OkNv bnNvbGFzO2NvbG9yOiMxRjQ5N0QiPkFsYnJlY2h0PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9k aXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9ImJhY2tncm91bmQ6d2hpdGUi PjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OkNvbnNvbGFzO2NvbG9y OiMxRjQ5N0QiPiZuYnNwOzwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJiYWNrZ3JvdW5kOndoaXRlIj48c3BhbiBzdHlsZT0i Zm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3Nh bnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+Jm5ic3A7PC9zcGFuPjxvOnA+PC9vOnA+PC9w Pg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdiBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLXRvcDpzb2xp ZCAjQjVDNERGIDEuMHB0O3BhZGRpbmc6My4wcHQgMGNtIDBjbSAwY20iPg0KPGRpdj4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJiYWNrZ3JvdW5kOndoaXRlIj48Yj48c3BhbiBzdHlsZT0i Zm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtUYWhvbWEmcXVvdDssJnF1b3Q7c2Fu cy1zZXJpZiZxdW90OyI+RnJvbTo8L3NwYW4+PC9iPjxzcGFuIGNsYXNzPSJhcHBsZS1jb252ZXJ0 ZWQtc3BhY2UiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90 O1RhaG9tYSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij4mbmJzcDs8L3NwYW4+PC9zcGFu PjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O1RhaG9tYSZx dW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij5Bc3ZlcmVuLA0KIFRvbGdhIFs8YSBocmVmPSJt YWlsdG86dGFzdmVyZW5Ac29udXNuZXQuY29tIj48c3BhbiBzdHlsZT0iY29sb3I6cHVycGxlIj5t YWlsdG86dGFzdmVyZW5Ac29udXNuZXQuY29tPC9zcGFuPjwvYT5dPHNwYW4gY2xhc3M9ImFwcGxl LWNvbnZlcnRlZC1zcGFjZSI+Jm5ic3A7PC9zcGFuPjxicj4NCjxiPlNlbnQ6PC9iPjxzcGFuIGNs YXNzPSJhcHBsZS1jb252ZXJ0ZWQtc3BhY2UiPiZuYnNwOzwvc3Bhbj5NaXR0d29jaCwgNS4gQXVn dXN0IDIwMTUgMTk6NDc8YnI+DQo8Yj5Ubzo8L2I+PHNwYW4gY2xhc3M9ImFwcGxlLWNvbnZlcnRl ZC1zcGFjZSI+Jm5ic3A7PC9zcGFuPlJvbWFuIFNocG91bnQ7IFJhdXNjaGVuYmFjaCwgVXdlIChO b2tpYSAtIERFL011bmljaCk8YnI+DQo8Yj5DYzo8L2I+PHNwYW4gY2xhc3M9ImFwcGxlLWNvbnZl cnRlZC1zcGFjZSI+Jm5ic3A7PC9zcGFuPmV4dCBFcmljIFJlc2NvcmxhOyBTY2h3YXJ6LCBBbGJy ZWNodCAoQWxicmVjaHQpOyBDaHJpc3RlciBIb2xtYmVyZzsgQmVybmFyZCBBYm9iYTsgJmx0Ozxh IGhyZWY9Im1haWx0bzpydGN3ZWJAaWV0Zi5vcmciPjxzcGFuIHN0eWxlPSJjb2xvcjpwdXJwbGUi PnJ0Y3dlYkBpZXRmLm9yZzwvc3Bhbj48L2E+Jmd0Ozxicj4NCjxiPlN1YmplY3Q6PC9iPjxzcGFu IGNsYXNzPSJhcHBsZS1jb252ZXJ0ZWQtc3BhY2UiPiZuYnNwOzwvc3Bhbj5SRTogW3J0Y3dlYl0g V2hhdCB0aGUgZ2F0ZXdheSBkcmFmdCBzaG91bGQgc2F5IGFib3V0IG11eC9ub24tbXV4PC9zcGFu PjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiIHN0eWxlPSJiYWNrZ3JvdW5kOndoaXRlIj48c3BhbiBzdHlsZT0iZm9udC1m YW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij4mbmJzcDs8 L3NwYW4+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFs IiBzdHlsZT0iYmFja2dyb3VuZDp3aGl0ZSI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7 Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2Nv bG9yOiMxRjQ5N0QiPmktIEkgaHVtYmx5IGRpc2FncmVlIHRoYXQgdXNpbmcgZGlmZmVyZW50IFFv UyBSVENQL1JUUCwgZS5nLiBkaWZmZXJlbnQgRGlmZlNlcnYgdmFsdWVzICwgc2hvdWxkIGJlIGRp c21pc3NlZC48L3NwYW4+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIiBzdHlsZT0iYmFja2dyb3VuZDp3aGl0ZSI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6 ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlm JnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPmlpLSBMZXQgbWUgYWxzbyBhZGQgYW5vdGhlciByZWFzb24g d2h5IG5vLXJ0Y3AtbXV4IG1heSBiZSBuZWVkZWQ6IEltcGxlbWVudGF0aW9uIGRpZmZpY3VsdGll cyBpbiBjZXJ0YWluIEdXcy48L3NwYW4+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0iYmFja2dyb3VuZDp3aGl0ZSI+PHNwYW4gc3R5bGU9 ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtz YW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPiZuYnNwOzwvc3Bhbj48bzpwPjwvbzpwPjwv cD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJiYWNrZ3JvdW5k OndoaXRlIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtD YWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+Q29uc2lk ZXJpbmcgdGhhdCB0aGVyZSBpcyBhbHJlYWR5IGEgbmVnb3RpYXRpb24gbWVjaGFuaXNtIGZvciBy dGNwLW11eCBzdXBwb3J0LCB0aGF0IGl0IGNhbiBiZSBkZS1mYWN0byBtYW5kYXRlZCBieSB0aGUg Y2hvaWNlIG9mIGJyb3dzZXJzDQogZm9yIEludGVybmV0LCBJIHRoaW5rIHdoYXQgQ2hyaXN0ZXIv QWxicmVjaHQgc3VnZ2VzdGVkIGlzIHRoZSByaWdodCB3YXkgdG8gbW92ZSBmb3J3YXJkOiBwcm92 aWRlIGNsYXJpZmljYXRpb25zIGZvciB2YWd1ZSBwb2ludHMuIEkgZG9u4oCZdCB1bmRlcnN0YW5k IHdoeSBsYWNrIG9mIGNsYXJpdHkgaW4gZXhpc3Rpbmcgc3BlY2lmaWNhdGlvbnMgc2hvdWxkIGNh dXNlIGltcG9zaW5nIHJlc3RyaWN0aW9ucy4gVGhpcyB3b3VsZCBiZSBha2luIHRvIGRyb3BwaW5n DQogYSBmZWF0dXJlIGR1ZSB0byBhIGJ1Zy4gSW4gdGhpcyBjYXNlLCB0aGUg4oCcYnVn4oCdIGlz IGxhY2sgb2YgY2xhcml0eSBpbiBub3JtYXRpdmUgc3BlY2lmaWNhdGlvbnMgYW5kIGl0IGNhbiBi ZSBhZGRyZXNzZWQgYnkgZnVydGhlciBzcGVjaWZpY2F0aW9uLjwvc3Bhbj48bzpwPjwvbzpwPjwv cD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJiYWNrZ3JvdW5k OndoaXRlIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtD YWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+Jm5ic3A7 PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1h bCIgc3R5bGU9ImJhY2tncm91bmQ6d2hpdGUiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0 O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztj b2xvcjojMUY0OTdEIj5UaGFua3MsPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2 Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9ImJhY2tncm91bmQ6d2hpdGUiPjxzcGFuIHN0 eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1 b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj5Ub2xnYTwvc3Bhbj48bzpwPjwvbzpw PjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJiYWNrZ3Jv dW5kOndoaXRlIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVv dDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+Jm5i c3A7PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2IHN0eWxlPSJib3JkZXI6bm9u ZTtib3JkZXItbGVmdDpzb2xpZCBibHVlIDEuNXB0O3BhZGRpbmc6MGNtIDBjbSAwY20gNC4wcHQi Pg0KPGRpdj4NCjxkaXYgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci10b3A6c29saWQgI0UxRTFF MSAxLjBwdDtwYWRkaW5nOjMuMHB0IDBjbSAwY20gMGNtIj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIiBzdHlsZT0iYmFja2dyb3VuZDp3aGl0ZSI+PGI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6 ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlm JnF1b3Q7Ij5Gcm9tOjwvc3Bhbj48L2I+PHNwYW4gY2xhc3M9ImFwcGxlLWNvbnZlcnRlZC1zcGFj ZSI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJy aSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij4mbmJzcDs8L3NwYW4+PC9zcGFuPjxzcGFu IHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDss JnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+Um9tYW4NCiBTaHBvdW50IFs8YSBocmVmPSJtYWlsdG86 cm9tYW5AdGVsdXJpeC5jb20iPjxzcGFuIHN0eWxlPSJjb2xvcjpwdXJwbGUiPm1haWx0bzpyb21h bkB0ZWx1cml4LmNvbTwvc3Bhbj48L2E+XTxzcGFuIGNsYXNzPSJhcHBsZS1jb252ZXJ0ZWQtc3Bh Y2UiPiZuYnNwOzwvc3Bhbj48YnI+DQo8Yj5TZW50OjwvYj48c3BhbiBjbGFzcz0iYXBwbGUtY29u dmVydGVkLXNwYWNlIj4mbmJzcDs8L3NwYW4+V2VkbmVzZGF5LCBBdWd1c3QgMDUsIDIwMTUgMTI6 MjkgUE08YnI+DQo8Yj5Ubzo8L2I+PHNwYW4gY2xhc3M9ImFwcGxlLWNvbnZlcnRlZC1zcGFjZSI+ Jm5ic3A7PC9zcGFuPlJhdXNjaGVuYmFjaCwgVXdlIChOb2tpYSAtIERFL011bmljaCkgJmx0Ozxh IGhyZWY9Im1haWx0bzp1d2UucmF1c2NoZW5iYWNoQG5va2lhLmNvbSI+PHNwYW4gc3R5bGU9ImNv bG9yOnB1cnBsZSI+dXdlLnJhdXNjaGVuYmFjaEBub2tpYS5jb208L3NwYW4+PC9hPiZndDs8YnI+ DQo8Yj5DYzo8L2I+PHNwYW4gY2xhc3M9ImFwcGxlLWNvbnZlcnRlZC1zcGFjZSI+Jm5ic3A7PC9z cGFuPmV4dCBFcmljIFJlc2NvcmxhICZsdDs8YSBocmVmPSJtYWlsdG86ZWtyQHJ0Zm0uY29tIj48 c3BhbiBzdHlsZT0iY29sb3I6cHVycGxlIj5la3JAcnRmbS5jb208L3NwYW4+PC9hPiZndDs7IFNj aHdhcnosIEFsYnJlY2h0IChBbGJyZWNodCkgJmx0OzxhIGhyZWY9Im1haWx0bzphbGJyZWNodC5z Y2h3YXJ6QGFsY2F0ZWwtbHVjZW50LmNvbSI+PHNwYW4gc3R5bGU9ImNvbG9yOnB1cnBsZSI+YWxi cmVjaHQuc2Nod2FyekBhbGNhdGVsLWx1Y2VudC5jb208L3NwYW4+PC9hPiZndDs7DQogQXN2ZXJl biwgVG9sZ2EgJmx0OzxhIGhyZWY9Im1haWx0bzp0YXN2ZXJlbkBzb251c25ldC5jb20iPjxzcGFu IHN0eWxlPSJjb2xvcjpwdXJwbGUiPnRhc3ZlcmVuQHNvbnVzbmV0LmNvbTwvc3Bhbj48L2E+Jmd0 OzsgQ2hyaXN0ZXIgSG9sbWJlcmcgJmx0OzxhIGhyZWY9Im1haWx0bzpjaHJpc3Rlci5ob2xtYmVy Z0Blcmljc3Nvbi5jb20iPjxzcGFuIHN0eWxlPSJjb2xvcjpwdXJwbGUiPmNocmlzdGVyLmhvbG1i ZXJnQGVyaWNzc29uLmNvbTwvc3Bhbj48L2E+Jmd0OzsgQmVybmFyZA0KIEFib2JhICZsdDs8YSBo cmVmPSJtYWlsdG86YmVybmFyZC5hYm9iYUBnbWFpbC5jb20iPjxzcGFuIHN0eWxlPSJjb2xvcjpw dXJwbGUiPmJlcm5hcmQuYWJvYmFAZ21haWwuY29tPC9zcGFuPjwvYT4mZ3Q7OyAmbHQ7PGEgaHJl Zj0ibWFpbHRvOnJ0Y3dlYkBpZXRmLm9yZyI+PHNwYW4gc3R5bGU9ImNvbG9yOnB1cnBsZSI+cnRj d2ViQGlldGYub3JnPC9zcGFuPjwvYT4mZ3Q7ICZsdDs8YSBocmVmPSJtYWlsdG86cnRjd2ViQGll dGYub3JnIj48c3BhbiBzdHlsZT0iY29sb3I6cHVycGxlIj5ydGN3ZWJAaWV0Zi5vcmc8L3NwYW4+ PC9hPiZndDs8YnI+DQo8Yj5TdWJqZWN0OjwvYj48c3BhbiBjbGFzcz0iYXBwbGUtY29udmVydGVk LXNwYWNlIj4mbmJzcDs8L3NwYW4+UmU6IFtydGN3ZWJdIFdoYXQgdGhlIGdhdGV3YXkgZHJhZnQg c2hvdWxkIHNheSBhYm91dCBtdXgvbm9uLW11eDwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2 Pg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0iYmFj a2dyb3VuZDp3aGl0ZSI+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVv dDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+Jm5ic3A7PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0K PC9kaXY+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIg c3R5bGU9ImJhY2tncm91bmQ6d2hpdGUiPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtD YWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPk9uIFdlZCwgQXVnIDUsIDIwMTUg YXQgNDo0NyBBTSwgUmF1c2NoZW5iYWNoLCBVd2UgKE5va2lhIC0gREUvTXVuaWNoKSAmbHQ7PGEg aHJlZj0ibWFpbHRvOnV3ZS5yYXVzY2hlbmJhY2hAbm9raWEuY29tIiB0YXJnZXQ9Il9ibGFuayI+ PHNwYW4gc3R5bGU9ImNvbG9yOnB1cnBsZSI+dXdlLnJhdXNjaGVuYmFjaEBub2tpYS5jb208L3Nw YW4+PC9hPiZndDsNCiB3cm90ZTo8L3NwYW4+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxibG9j a3F1b3RlIHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItbGVmdDpzb2xpZCAjQ0NDQ0NDIDEuMHB0 O3BhZGRpbmc6MGNtIDBjbSAwY20gNi4wcHQ7bWFyZ2luLWxlZnQ6NC44cHQ7bWFyZ2luLXRvcDo1 LjBwdDttYXJnaW4tcmlnaHQ6MGNtO21hcmdpbi1ib3R0b206NS4wcHQiPg0KPGRpdj4NCjxkaXY+ DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9ImJhY2tncm91bmQ6d2hpdGUiPjxz cGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7 LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPk1lZGlhIGdhdGV3YXkgaW1wbGVtZW50YXRpb25zIGFj Y29yZGluZyB0byAzR1BQIFRTIDIzLjIyODwvc3Bhbj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEx LjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVv dDs7Y29sb3I6IzFGNDk3RCI+Jm5ic3A7PC9zcGFuPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAu MHB0O2ZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsi Pm1heQ0KIG5vdCBzdXBwb3J0IHJ0Y3AtbXV4LCBhcyBydGNwLW11eCBpcyBvcHRpb25hbCB0aGVy ZS48L3NwYW4+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCIgc3R5bGU9ImJhY2tncm91bmQ6d2hpdGUiPjxzcGFuIHN0eWxlPSJmb250LXNp emU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYm cXVvdDsiPlNvIGlmIHdlIGRyb3Agbm9uLW11eCBzdXBwb3J0IGZyb20gd2ViIGJyb3dzZXJzLCB0 aG9zZSBtZWRpYSBnYXRld2F5cyB0aGF0IGhhdmUgbm90IGltcGxlbWVudGVkIHJ0Y3AtbXV4IHdp bGwgc3RvcCBpbnRlcm9wZXJhdGluZy4mbmJzcDs8L3NwYW4+PG86cD48L286cD48L3A+DQo8L2Rp dj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0iYmFja2dyb3VuZDp3aGl0ZSI+ PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1z ZXJpZiZxdW90OyI+Jm5ic3A7PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4N CjwvZGl2Pg0KPC9kaXY+DQo8L2Jsb2NrcXVvdGU+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiIHN0eWxlPSJiYWNrZ3JvdW5kOndoaXRlIj48c3BhbiBzdHlsZT0iZm9udC1mYW1p bHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij4mbmJzcDs8L3Nw YW4+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIiBzdHlsZT0iYmFja2dyb3VuZDp3aGl0ZSI+PHNwYW4gc3R5bGU9ImZvbnQt ZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+Rmlyc3Qg b2YgYWxsLCBkbyB5b3Uga25vdyBvZiBhbnkgV2ViUlRDIHRvIElNUyBnYXRld2F5cyB0aGF0IGRv IG5vdCBpbXBsZW1lbnQgcnRjcC1tdXggb24gdGhlIFdlYlJUQyBzaWRlPyBJIHN0cm9uZ2x5IHN1 c3BlY3QgdGhlcmUgYXJlIG5vbmUuPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rp dj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9ImJhY2tncm91bmQ6 d2hpdGUiPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90 O3NhbnMtc2VyaWYmcXVvdDsiPiZuYnNwOzwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0K PC9kaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJiYWNrZ3Jv dW5kOndoaXRlIj48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90Oywm cXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij5TZWNvbmQsIHRoZSBvbmx5IHJlYXNvbnMgbm90IHRvIHVz ZSBydGNwLW11eCB0aGF0IEkgY2FuIHRoaW5rIG9mIGFyZSB0aGUgZm9sbG93aW5nOjwvc3Bhbj48 bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiIHN0eWxlPSJiYWNrZ3JvdW5kOndoaXRlIj48c3BhbiBzdHlsZT0iZm9udC1mYW1p bHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij4mbmJzcDs8L3Nw YW4+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIiBzdHlsZT0iYmFja2dyb3VuZDp3aGl0ZSI+PHNwYW4gc3R5bGU9ImZvbnQt ZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+MS4gVXNp bmcgZGlmZmVyZW50IFFPUyBzZXR0aW5ncyBmb3IgUlRDUCB2cyBSVFA8L3NwYW4+PG86cD48L286 cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFs IiBzdHlsZT0iYmFja2dyb3VuZDp3aGl0ZSI+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90 O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+Mi4gU2VuZGluZyBSVENQIHRv IGEgZGlmZmVyZW50IGRldmljZSBmcm9tIFJUUDwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2 Pg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJiYWNr Z3JvdW5kOndoaXRlIj48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90 OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij4mbmJzcDs8L3NwYW4+PG86cD48L286cD48L3A+DQo8 L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0i YmFja2dyb3VuZDp3aGl0ZSI+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkm cXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+SSBkbyBub3QgdGhpbmsgdGhlIGZpcnN0IHVz ZSBjYXNlIHdhcnJhbnRzIG1ha2luZyBydGNwLW11eCBvcHRpb25hbCwgc2luY2UsIHByYWN0aWNh bGx5IG5vIG9uZSBkb2VzIHRoaXMuPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rp dj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9ImJhY2tncm91bmQ6 d2hpdGUiPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90 O3NhbnMtc2VyaWYmcXVvdDsiPlNlY29uZCB1c2UgY2FzZSBpcyBhbHNvIGZhaXJseSBtYXJnaW5h bC4gUGx1cyBpdCBjYW4gYmUgaGFuZGxlZCBieSB0aGUgZ2F0ZXdheSB3aGljaCBjYW4gc2VuZCBS VENQIHRvIG9uZSBkZXZpY2UgYW5kIFJUUCB0byBhbm90aGVyLjwvc3Bhbj48bzpwPjwvbzpwPjwv cD4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0 eWxlPSJiYWNrZ3JvdW5kOndoaXRlIj48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7Q2Fs aWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij4mbmJzcDs8L3NwYW4+PG86cD48L286 cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFs IiBzdHlsZT0iYmFja2dyb3VuZDp3aGl0ZSI+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90 O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+U28sIHVubGVzcyBzb21lb25l IGNhbiBjb21lIHVwIHdpdGggYSB1c2UgY2FzZSB3aHkgUlRQIGFuZCBSVENQIHNob3VsZCB1c2Ug ZGlmZmVyZW50IHRyYW5zcG9ydHMsIEkgdGhpbmsgcnRjcC1tdXggc2hvdWxkIGJlIG1hbmRhdG9y eS48L3NwYW4+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxkaXY+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0iYmFja2dyb3VuZDp3aGl0ZSI+PHNwYW4gc3R5bGU9 ImZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+ Jm5ic3A7PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2 Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9ImJhY2tncm91bmQ6d2hpdGUiPjxzcGFuIHN0 eWxlPSJmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVv dDsiPlJlZ2FyZHMsPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+ DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9ImJhY2tncm91bmQ6d2hpdGUiPjxz cGFuIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2Vy aWYmcXVvdDsiPl9fX19fX19fX19fX19fPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8 L2Rpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9ImJhY2tncm91 bmQ6d2hpdGUiPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZx dW90O3NhbnMtc2VyaWYmcXVvdDsiPlJvbWFuIFNocG91bnQ8L3NwYW4+PG86cD48L286cD48L3A+ DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4N CjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0K PC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjkuMHB0 O2ZvbnQtZmFtaWx5OiZxdW90O0hlbHZldGljYSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7 Ij5fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXzxicj4NCnJ0 Y3dlYiBtYWlsaW5nIGxpc3Q8YnI+DQo8YSBocmVmPSJtYWlsdG86cnRjd2ViQGlldGYub3JnIj5y dGN3ZWJAaWV0Zi5vcmc8L2E+PGJyPg0KPGEgaHJlZj0iaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFp bG1hbi9saXN0aW5mby9ydGN3ZWIiPmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGlu Zm8vcnRjd2ViPC9hPjwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9ibG9ja3F1b3Rl Pg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwv ZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9ib2R5Pg0KPC9odG1sPg0K --_000_9F33F40F6F2CD847824537F3C4E37DDF1E826A00MCHP04MSXglobal_-- From nobody Thu Aug 6 06:35:42 2015 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 878621B2F9C for ; Thu, 6 Aug 2015 06:35:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WWx9eSp3LFOG for ; Thu, 6 Aug 2015 06:35:32 -0700 (PDT) Received: from na01-bl2-obe.outbound.protection.outlook.com (mail-bl2on0098.outbound.protection.outlook.com [65.55.169.98]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0F9EE1B2F79 for ; Thu, 6 Aug 2015 06:35:31 -0700 (PDT) Received: from SN1PR0301MB1551.namprd03.prod.outlook.com (10.162.129.157) by SN1PR0301MB1552.namprd03.prod.outlook.com (10.162.129.158) with Microsoft SMTP Server (TLS) id 15.1.225.19; Thu, 6 Aug 2015 13:35:28 +0000 Received: from SN1PR0301MB1551.namprd03.prod.outlook.com ([10.162.129.157]) by SN1PR0301MB1551.namprd03.prod.outlook.com ([10.162.129.157]) with mapi id 15.01.0225.018; Thu, 6 Aug 2015 13:35:28 +0000 From: "Asveren, Tolga" To: "Hutton, Andrew" , tim panton Thread-Topic: [rtcweb] What the gateway draft should say about mux/non-mux Thread-Index: AQHQy8DcUgzWwtVCmk+8q67BCzjC45316kQQgAAD5oCAAACVsIAAAj2AgAPw2gCAAEFTAIAC/BgAgACAxgCAABQlsIAA2x8AgAAp4WeAAApBgIAADKQAgAARK8CAABTdgIAACn+AgAAAfPA= Date: Thu, 6 Aug 2015 13:35:28 +0000 Message-ID: References: <9F33F40F6F2CD847824537F3C4E37DDF1E826A00@MCHP04MSX.global-ad.net> In-Reply-To: <9F33F40F6F2CD847824537F3C4E37DDF1E826A00@MCHP04MSX.global-ad.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=tasveren@sonusnet.com; x-originating-ip: [50.182.164.80] x-microsoft-exchange-diagnostics: 1; SN1PR0301MB1552; 5:HiKdBxSfLoC5czF4wPmtfKpeKvV2hofSIWJaG6pusybZl2rL99WneJmtgbAcu5PRVZ7/QUBkOMCONbe4qA8QhdrXBMeZUeyTMu1YvJMwATmxJlWURdImsDu0YthCletu4nwU0+1PvMbZPMBnCkTgkA==; 24:du3ZCBa3bmihpfBaUMw5kThOtgzJNYAto991HTDGbmkJQ2APsMv4Zc4YC9/oUwFZ8ZR48NxoMGu8RAX5aUlrIfL2GN2bUrMiAS/e+GWnlag=; 20:vMC7ReQyhIbGGVY1PwD5mR0azUzZzS5S1VOKE5rp6ZsxaTUmeMc+dJxOYo05K0iLRt/M59PlsY5DPAAuyxCEAw== x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:SN1PR0301MB1552; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(108003899814671); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(601004)(5005006)(3002001); SRVR:SN1PR0301MB1552; BCL:0; PCL:0; RULEID:; SRVR:SN1PR0301MB1552; x-forefront-prvs: 06607E485E x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(377454003)(164054003)(189002)(24454002)(199003)(76176999)(33656002)(74316001)(189998001)(5002640100001)(77156002)(62966003)(19625215002)(4001540100001)(76576001)(122556002)(40100003)(50986999)(5001860100001)(101416001)(97736004)(54356999)(5001830100001)(5001770100001)(10400500002)(81156007)(19617315012)(16236675004)(15975445007)(106356001)(66066001)(102836002)(68736005)(105586002)(77096005)(2950100001)(2900100001)(64706001)(99286002)(87936001)(5001960100002)(46102003)(86362001)(92566002)(2656002)(106116001)(19300405004)(19609705001)(19580395003)(19580405001)(5003600100002); DIR:OUT; SFP:1101; SCL:1; SRVR:SN1PR0301MB1552; H:SN1PR0301MB1551.namprd03.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; MX:1; A:1; LANG:en; received-spf: None (protection.outlook.com: sonusnet.com does not designate permitted sender hosts) Content-Type: multipart/alternative; boundary="_000_SN1PR0301MB1551852C42AFEB308672D524B2740SN1PR0301MB1551_" MIME-Version: 1.0 X-OriginatorOrg: sonusnet.com X-MS-Exchange-CrossTenant-originalarrivaltime: 06 Aug 2015 13:35:28.0969 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 29a671dc-ed7e-4a54-b1e5-8da1eb495dc3 X-MS-Exchange-Transport-CrossTenantHeadersStamped: SN1PR0301MB1552 Archived-At: Cc: "" Subject: Re: [rtcweb] What the gateway draft should say about mux/non-mux X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 06 Aug 2015 13:35:37 -0000 --_000_SN1PR0301MB1551852C42AFEB308672D524B2740SN1PR0301MB1551_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 4oCcaXQgaXMgc3VyZWx5IGFib3V0IHdoZXRoZXIgV2ViUlRDIGJyb3dzZXJzIGhhdmUgdG8gc3Vw cG9ydCBub24tbXV44oCdDQpwcmVjaXNlbHkuDQoNCklmIHRoZXJlIGlzIGEgbmVlZCBmb3IgcHJv ZmlsaW5nLCBpdCBuZWVkcyB0byBiZSBkb25lIGFzIGFwcGxpY2FibGUgdG8gYnJvd3NlcnMuIFNv LCBhbnkgY2xhcmlmaWNhdGlvbi9zdGF0ZW1lbnQgZG9lcyBub3QgYmVsb25nIHRvIEdXLWRyYWZ0 IGJ1dCBzb21ld2hlcmUgZWxzZS4NCg0KQlRXLCDigJxmaXhpbmfigJ0gdGhlIGxhY2sgb2YgY2xh cml0eSBhYm91dCB1c2Ugb2YgRFRMUyB3aGVuIHJ0Y3AtbXV4IGlzIG5vdCB1c2VkL2ZvciBEYXRh Q2hhbm5lbCBpcyBhIHNlcGFyYXRlIGlzc3VlIGFuZCBzaG91bGQgYmUgYWRkcmVzc2VkIGFzIHdl bGwuDQoNClRoYW5rcywNClRvbGdhDQoNCkZyb206IEh1dHRvbiwgQW5kcmV3IFttYWlsdG86YW5k cmV3Lmh1dHRvbkB1bmlmeS5jb21dDQpTZW50OiBUaHVyc2RheSwgQXVndXN0IDA2LCAyMDE1IDk6 MzAgQU0NClRvOiB0aW0gcGFudG9uIDx0aW1AcGhvbmVmcm9taGVyZS5jb20+OyBBc3ZlcmVuLCBU b2xnYSA8dGFzdmVyZW5Ac29udXNuZXQuY29tPg0KQ2M6IDxydGN3ZWJAaWV0Zi5vcmc+IDxydGN3 ZWJAaWV0Zi5vcmc+DQpTdWJqZWN0OiBSRTogW3J0Y3dlYl0gV2hhdCB0aGUgZ2F0ZXdheSBkcmFm dCBzaG91bGQgc2F5IGFib3V0IG11eC9ub24tbXV4DQoNCisxIHRvIHdoYXQgVGltIHNhaWQuDQoN CkkgZG9u4oCZdCB0aGluayB0aGlzIGRpc2N1c3Npb24gaXMgcmVhbGx5IGFib3V0IGdhdGV3YXlz IGF0IGFsbCBpdCBpcyBzdXJlbHkgYWJvdXQgd2hldGhlciBXZWJSVEMgYnJvd3NlcnMgaGF2ZSB0 byBzdXBwb3J0IG5vbi1tdXggYW5kIEkgZG9u4oCZdCByZWFsbHkgc2VlIGFueSBnb29kIHJlYXNv biB3aHkgdGhleSBuZWVkIHRvLg0KDQpJZiB3ZSBoYWQgdGhvdWdodCBhYm91dCB0aGlzIGF0IHRo ZSB0aW1lIHdlIG1hbmRhdGVkIERUTFMtU1JUUCB0aGVuIHdlIHdvdWxkIGhhdmUgbWFuZGF0ZWQg cnRwLW11eCBhdCB0aGUgc2FtZSB0aW1lIGJ1dCB1bmZvcnR1bmF0ZWx5IHdlIGRpZG7igJl0IGJ1 dCB3ZSBjYW4gZml4IHRoYXQgbm93Lg0KDQpBbmR5DQoNCg0KRnJvbTogcnRjd2ViIFttYWlsdG86 cnRjd2ViLWJvdW5jZXNAaWV0Zi5vcmddIE9uIEJlaGFsZiBPZiB0aW0gcGFudG9uDQpTZW50OiAw NiBBdWd1c3QgMjAxNSAxMzo1Mw0KVG86IEFzdmVyZW4sIFRvbGdhDQpDYzogPHJ0Y3dlYkBpZXRm Lm9yZzxtYWlsdG86cnRjd2ViQGlldGYub3JnPj4NClN1YmplY3Q6IFJlOiBbcnRjd2ViXSBXaGF0 IHRoZSBnYXRld2F5IGRyYWZ0IHNob3VsZCBzYXkgYWJvdXQgbXV4L25vbi1tdXgNCg0KU28gd2Ug YXJlIHBvc2l0aW5nIHRoZSBleGlzdGVuY2Ugb2YgYSB3ZWJSVEMgZ2F0ZXdheSBkZXNpZ25lZCB0 byBzdXBwb3J0IHRob3VzYW5kcyBvZiBjYWxscyB3aGljaCBkb2VzIElDRSBhbmQgRFRMUyBidXQg dGhlDQpkZXNpZ25lciBkZWNpZGVkIGRlbGliZXJhdGVseSB0byBkb3VibGUgdGhlIG51bWJlciBv ZiBJQ0Ugc2Vzc2lvbnMgcmVxdWlyZWQgYW5kIGRvdWJsZSB0aGUgbnVtYmVyIG9mIERUTFMgc2Vz c2lvbnMgKGFuZCBrZXkNCmdlbmVyYXRpb24gY29zdHMpIHNvIHRoYXQgdGhleSBjYW4gcnVuIFJU Q1AgKG92ZXIgSUNFIGFuZCBEVExTKSBvbiBhIHNlcGFyYXRlIHBvcnQuIEluIG15IGVzdGltYXRp b24gdGhhdOKAmXMgb25lIHBvb3IgZGVjaXNpb24NCmFuZCBzaG91bGQgbm90IGJlIHVzZWQgYXMg dGhlIGJhc2lzIG9mIHRoaXMgKG9yIGFueSkgc3RhbmRhcmQuDQoNCknigJlkIHJhdGhlciBub3Qg c3VwcG9ydCBydGNwLW5vLW11eCBhcyBJIHNlZSB6ZXJvIGFkdmFudGFnZXMgaW4gaGF2aW5nIGl0 LiAoSSBrbm93IHRoZW9yZXRpY2FsbHkgaXQgbWlnaHQgYmUgcG9zc2libGUgdG8gZ2V0DQphIFJU Q1AgcGFja2V0IHRocm91Z2ggYSBjb25nZXN0ZWQgbmV0IG9uIGEgZGlmZmVyZW50IHBvcnQgd2l0 aCBhIHNlcGFyYXRlIGRpZmZzZXJ2IHNldHRpbmcgYnV0IHRoYXQganVzdCBzZWVtcyBzbyBjb250 cml2ZWQpLg0KDQpUaW0uDQoNCg0KT24gNiBBdWcgMjAxNSwgYXQgMDY6NDQsIEFzdmVyZW4sIFRv bGdhIDx0YXN2ZXJlbkBzb251c25ldC5jb208bWFpbHRvOnRhc3ZlcmVuQHNvbnVzbmV0LmNvbT4+ IHdyb3RlOg0KDQpUaGVzZSBhc3N1bXB0aW9ucyBhcmUgbm90IG5lY2Vzc2FyaWx5IHRydWUgaW4g YSB1bml2ZXJzYWwgc2Vuc2UgKGxpa2UgYWxtb3N0IGFueSBvdGhlciBhc3N1bXB0aW9uIGFib3V0 IGRpZmZlcmVudCBkZXBsb3ltZW50IG1vZGVscykuDQoNCkZ1cnRoZXJtb3JlLCBhbmQgbW9yZSBp bXBvcnRhbnRseSwgdGhlcmUgaXMgbm90aGluZyBtYW5kYXRpbmcgV2ViUlRDIGVuZHBvaW50cyB0 byBzdXBwb3J0IG5vbi1ydGNwLW11eC4gSXQgaXMgYSBuZWdvdGlhdGVkIGZ1bmN0aW9uYWxpdHku IEFueSBlbnRpdHkgY2FuIGVuZm9yY2UgcnRjcC1tdXggYXMgYSBsb2NhbCBwb2xpY3kuDQoNClRo ZSBpc3N1ZSB3aXRoIHN1cHBvcnRpbmcgbm9uLXJ0Y3AtbXV4IHNlZW1zIHRvIGJlIGxhY2sgb2Yg Y2xhcml0eSBpbiB0aGUgcmVsZXZhbnQgc3BlY2lmaWNhdGlvbnMuIEZpeGluZyB0aGlzIOKAk3Jl Z2FyZGxlc3Mgb2YgdGhlIG91dGNvbWUgb2YgYW55IG90aGVyIGRpc2N1c3Npb24tIHNlZW1zIHRv IGJlIHBydWRlbnQgSU1ITy4NCg0KVGhhbmtzLA0KVG9sZ2ENCg0KRnJvbTogV3lzcywgRmVsaXgg W21haWx0bzpGZWxpeC5XeXNzQGluaW4uY29tXQ0KU2VudDogVGh1cnNkYXksIEF1Z3VzdCAwNiwg MjAxNSA2OjM3IEFNDQpUbzogQ2hyaXN0ZXIgSG9sbWJlcmcgPGNocmlzdGVyLmhvbG1iZXJnQGVy aWNzc29uLmNvbTxtYWlsdG86Y2hyaXN0ZXIuaG9sbWJlcmdAZXJpY3Nzb24uY29tPj47IEFzdmVy ZW4sIFRvbGdhIDx0YXN2ZXJlbkBzb251c25ldC5jb208bWFpbHRvOnRhc3ZlcmVuQHNvbnVzbmV0 LmNvbT4+OyBTY2h3YXJ6LCBBbGJyZWNodCAoQWxicmVjaHQpIDxhbGJyZWNodC5zY2h3YXJ6QGFs Y2F0ZWwtbHVjZW50LmNvbTxtYWlsdG86YWxicmVjaHQuc2Nod2FyekBhbGNhdGVsLWx1Y2VudC5j b20+PjsgUm9tYW4gU2hwb3VudCA8cm9tYW5AdGVsdXJpeC5jb208bWFpbHRvOnJvbWFuQHRlbHVy aXguY29tPj47IFJhdXNjaGVuYmFjaCwgVXdlIChOb2tpYSAtIERFL011bmljaCkgPHV3ZS5yYXVz Y2hlbmJhY2hAbm9raWEuY29tPG1haWx0bzp1d2UucmF1c2NoZW5iYWNoQG5va2lhLmNvbT4+DQpD YzogPHJ0Y3dlYkBpZXRmLm9yZzxtYWlsdG86cnRjd2ViQGlldGYub3JnPj4gPHJ0Y3dlYkBpZXRm Lm9yZzxtYWlsdG86cnRjd2ViQGlldGYub3JnPj4NClN1YmplY3Q6IFJlOiBbcnRjd2ViXSBXaGF0 IHRoZSBnYXRld2F5IGRyYWZ0IHNob3VsZCBzYXkgYWJvdXQgbXV4L25vbi1tdXgNCg0KV2h5IHNo b3VsZG4ndCB0aGUgZ2F0ZXdheSBiZSByZXF1aXJlZCB0byBkbyB0aGUgbXV4L2RlbXV4PyAgTWFr aW5nIHRoZSBXZWJSVEMgZW5kcG9pbnRzIGEgbG90IG1vcmUgY29tcGxleCBqdXN0IHNvIHRoZSBs ZWdhY3kgaW50ZXJvcCBtaWdodCBwb3RlbnRpYWxseSBiZSBhIHRlZW55LXRpbnkgYml0IGVhc2ll ciBtYWtlcyBubyBzZW5zZSBJTUhPLiAgQWN0dWFsbHksIHRoZSBnYXRld2F5IHdvdWxkIG5vdCBi ZSBhYmxlIHRvIGRvICJlbmQtdG8tZW5kIiBwYXNzLXRocm91Z2ggYW55d2F5IGFzIGxlZ2FjeSBl cXVpcG1lbnQgd2lsbCBlaXRoZXIgYmUgdW5lbmNyeXB0ZWQgb3IgdXNlIFNERVMgKFJGQyM0NTY4 KSBmb3Iga2V5IGV4Y2hhbmdlLiAgU28gdGhlIGdhdGV3YXkgd2lsbCBoYXZlIHRvIHBlcmZvcm0g RFRMUy1TUlRQIHRvIFNERVMtU1JUUCB0cmFuc2NyeXB0aW9uLS13aGljaCBhbHJlYWR5IGlzIHdh eSBtb3JlIGhhc3NsZSB0aGFuIFJUUC9SVENQIG11eC9kZW11eC4NCg0KLS1GZWxpeA0KDQpfX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KRnJvbTogcnRjd2ViIDxydGN3ZWItYm91bmNl c0BpZXRmLm9yZzxtYWlsdG86cnRjd2ViLWJvdW5jZXNAaWV0Zi5vcmc+PiBvbiBiZWhhbGYgb2Yg Q2hyaXN0ZXIgSG9sbWJlcmcgPGNocmlzdGVyLmhvbG1iZXJnQGVyaWNzc29uLmNvbTxtYWlsdG86 Y2hyaXN0ZXIuaG9sbWJlcmdAZXJpY3Nzb24uY29tPj4NClNlbnQ6IFRodXJzZGF5LCBBdWd1c3Qg NiwgMjAxNSAwNTo1MQ0KVG86IEFzdmVyZW4sIFRvbGdhOyBTY2h3YXJ6LCBBbGJyZWNodCAoQWxi cmVjaHQpOyBSb21hbiBTaHBvdW50OyBSYXVzY2hlbmJhY2gsIFV3ZSAoTm9raWEgLSBERS9NdW5p Y2gpDQpDYzogPHJ0Y3dlYkBpZXRmLm9yZzxtYWlsdG86cnRjd2ViQGlldGYub3JnPj4NClN1Ympl Y3Q6IFJlOiBbcnRjd2ViXSBXaGF0IHRoZSBnYXRld2F5IGRyYWZ0IHNob3VsZCBzYXkgYWJvdXQg bXV4L25vbi1tdXgNCg0KSGksDQoNCk5vIG1hdHRlciB3aGV0aGVyIHRoZSBnYXRld2F5IHN1cHBv cnRzIFJUUC9SVENQIG11eCBvciBub3QsIHRoZXJlIGFyZSBjYXNlcyB3aGVyZSB0aGUgbGVnYWN5 IG5ldHdvcmsvZW5kcG9pbnRzIHdpbGwgbm90IHVzZSBSVFAvUlRDUCBtdXgsIHNvIEkgZ3Vlc3Mg cGVvcGxlIHRoZW4gd291bGQgd2FudCB0byBiZSBhYmxlIHRvIG5lZ290aWF0ZSBub24tbXV4IOKA nGVuZC10by1lbmTigJ0sIHJhdGhlciB0aGFuIGhhdmluZyB0aGUgZ2F0ZXdheSB0byBkZW11eC9t dXggUlRQIGFuZCBSVENQLg0KDQpSZWdhcmRzLA0KDQpDaHJpc3Rlcg0KDQpGcm9tOiBBc3ZlcmVu LCBUb2xnYSBbbWFpbHRvOnRhc3ZlcmVuQHNvbnVzbmV0LmNvbV0NClNlbnQ6IDYuIGVsb2t1dXRh IDIwMTUgMTI6MTgNClRvOiBTY2h3YXJ6LCBBbGJyZWNodCAoQWxicmVjaHQpOyBSb21hbiBTaHBv dW50OyBSYXVzY2hlbmJhY2gsIFV3ZSAoTm9raWEgLSBERS9NdW5pY2gpDQpDYzogZXh0IEVyaWMg UmVzY29ybGE7IENocmlzdGVyIEhvbG1iZXJnOyBCZXJuYXJkIEFib2JhOyA8cnRjd2ViQGlldGYu b3JnPG1haWx0bzpydGN3ZWJAaWV0Zi5vcmc+Pg0KU3ViamVjdDogUmU6IFtydGN3ZWJdIFdoYXQg dGhlIGdhdGV3YXkgZHJhZnQgc2hvdWxkIHNheSBhYm91dCBtdXgvbm9uLW11eA0KDQpXaHkgc2hv dWxkIHdlIGNvbnNpZGVyIDNHUFAgdGhlIHNvbGUgIm93bmVyL3VzZXIiIG9mIHRoZSB0ZXJtL2Vu dGl0eSBXZWJSVEMtR1c/IEkgdGhpbmsgaXQgaGFzIGEgbXVjaCBtb3JlIGdlbmVyYWwgbWVhbmlu ZyBhbmQgdXNlIGluIHByYWN0aWNlLiBJdCBjYW4gcmVmZXIgdG8gbWFueSBkaWZmZXJlbnQgdHlw ZXMgb2YgZWxlbWVudHMgd2hpY2ggY2FuIGJlIGRlcGxveWVkIGluIG1hbnkgZGlmZmVyZW50IGVu dmlyb25tZW50cywgaGVuY2UgYW55IGF0dGVtcHQgdG8gZGVmaW5lIGl0IHN0cmljdGx5L3Jlc3Ry aWN0IGl0cyBjYXBhYmlsaXRpZXMgYXJlIGZ1dGlsZSBJTUhPLg0KDQpUaGFua3MsDQpUb2xnYQ0K DQpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KRnJvbTogU2Nod2FyeiwgQWxicmVj aHQgKEFsYnJlY2h0KSA8YWxicmVjaHQuc2Nod2FyekBhbGNhdGVsLWx1Y2VudC5jb208bWFpbHRv OmFsYnJlY2h0LnNjaHdhcnpAYWxjYXRlbC1sdWNlbnQuY29tPj4NClNlbnQ6IFRodXJzZGF5LCBB dWd1c3QgNiwgMjAxNSAyOjQ0IEFNDQpUbzogQXN2ZXJlbiwgVG9sZ2E7IFJvbWFuIFNocG91bnQ7 IFJhdXNjaGVuYmFjaCwgVXdlIChOb2tpYSAtIERFL011bmljaCkNCkNjOiBleHQgRXJpYyBSZXNj b3JsYTsgQ2hyaXN0ZXIgSG9sbWJlcmc7IEJlcm5hcmQgQWJvYmE7IDxydGN3ZWJAaWV0Zi5vcmc8 bWFpbHRvOnJ0Y3dlYkBpZXRmLm9yZz4+DQpTdWJqZWN0OiBSRTogW3J0Y3dlYl0gV2hhdCB0aGUg Z2F0ZXdheSBkcmFmdCBzaG91bGQgc2F5IGFib3V0IG11eC9ub24tbXV4DQoNClRoZSBjb25jZXJu ZWQgM0dQUCBXZWJSVEMgZ2F0ZXdheSAoM0dQUCAyMy4zMzQvMjkuMzM0KSBzdXBwb3J0cyBhbHJl YWR5IFJUUC9SVENQIHRyYW5zcG9ydCBtdWx0aXBsZXhpbmcgKHNpbmNlIDNHUFAgUmVsZWFzZSAx MiksIGkuZS4gc2hvdWxkIG5vdCBiZSB0aGUgbGltaXRpbmcgZmFjdG9yIGluIHRoaXMgZGlzY3Vz c2lvbi4NCkZvciBvbmVzIGludGVyZXN0ZWQgaW4gdGhlIFJUQ1AgcG9ydCBhbGxvY2F0aW9uIHJ1 bGVzLCBzZWUgSC4yNDguNTc6DQpodHRwczovL3d3dy5pdHUuaW50L3JlYy9kb2xvZ2luX3B1Yi5h c3A/bGFuZz1lJmlkPVQtUkVDLUguMjQ4LjU3LTIwMTQxMC1JISFQREYtRSZ0eXBlPWl0ZW1zDQpD bGF1c2UgNyBkZXNjcmliZXMgUlRQL1JUQ1AgdHJhbnNwb3J0IG11bHRpcGxleGluZy4gSVRVLVQg SC4yNDguNTcgaXMgYWxyZWFkeSBzdXBwb3J0ZWQgYnkgM0dQUCAyOS4zMzQuDQoNClRoZSByYXRp b25hbGUgYmVoaW5kIHRoZSDigJxvcHRpb25hbCB0YWdnaW5n4oCdIGJ5IDIzLjIyOCBpcyBhIHRo aXJkIHJlYXNvbiwgYmV5b25kDQo+MS4gVXNpbmcgZGlmZmVyZW50IFFPUyBzZXR0aW5ncyBmb3Ig UlRDUCB2cyBSVFANCj4yLiBTZW5kaW5nIFJUQ1AgdG8gYSBkaWZmZXJlbnQgZGV2aWNlIGZyb20g UlRQDQoNCkRvbuKAmXQgd2FudCB0byBnbyBpbiB0aGUgM0dQUCBzcGVjaWZpYyBkZXRhaWxzLCBi dXQgaXQgaGFzIG5vdGhpbmcgdG8gZG8gd2l0aCB0aGUgM0dQUCBVRS1lbWJlZGRlZCBXZWJSVEMg Y2xpZW50IG5vciBhbnkgY29uc3RyYWludHMgYnkgM0dQUCBXZWJSVEMgZ2F0ZXdheXMuDQoNClRo dXMsIGEgV2ViUlRDIGdhdGV3YXkgTVVTVCBzdXBwb3J0IFJUUC9SVENQIHRyYW5zcG9ydCBtdWx0 aXBsZXhpbmcgZHVlIHRvIGl0cyBwdXJwb3NlIGluIGludGVyd29ya2luZyBzdXBwb3J0Lg0KDQpS ZWdhcmRzLA0KQWxicmVjaHQNCg0KDQpGcm9tOiBBc3ZlcmVuLCBUb2xnYSBbbWFpbHRvOnRhc3Zl cmVuQHNvbnVzbmV0LmNvbV0NClNlbnQ6IE1pdHR3b2NoLCA1LiBBdWd1c3QgMjAxNSAxOTo0Nw0K VG86IFJvbWFuIFNocG91bnQ7IFJhdXNjaGVuYmFjaCwgVXdlIChOb2tpYSAtIERFL011bmljaCkN CkNjOiBleHQgRXJpYyBSZXNjb3JsYTsgU2Nod2FyeiwgQWxicmVjaHQgKEFsYnJlY2h0KTsgQ2hy aXN0ZXIgSG9sbWJlcmc7IEJlcm5hcmQgQWJvYmE7IDxydGN3ZWJAaWV0Zi5vcmc8bWFpbHRvOnJ0 Y3dlYkBpZXRmLm9yZz4+DQpTdWJqZWN0OiBSRTogW3J0Y3dlYl0gV2hhdCB0aGUgZ2F0ZXdheSBk cmFmdCBzaG91bGQgc2F5IGFib3V0IG11eC9ub24tbXV4DQoNCmktIEkgaHVtYmx5IGRpc2FncmVl IHRoYXQgdXNpbmcgZGlmZmVyZW50IFFvUyBSVENQL1JUUCwgZS5nLiBkaWZmZXJlbnQgRGlmZlNl cnYgdmFsdWVzICwgc2hvdWxkIGJlIGRpc21pc3NlZC4NCmlpLSBMZXQgbWUgYWxzbyBhZGQgYW5v dGhlciByZWFzb24gd2h5IG5vLXJ0Y3AtbXV4IG1heSBiZSBuZWVkZWQ6IEltcGxlbWVudGF0aW9u IGRpZmZpY3VsdGllcyBpbiBjZXJ0YWluIEdXcy4NCg0KQ29uc2lkZXJpbmcgdGhhdCB0aGVyZSBp cyBhbHJlYWR5IGEgbmVnb3RpYXRpb24gbWVjaGFuaXNtIGZvciBydGNwLW11eCBzdXBwb3J0LCB0 aGF0IGl0IGNhbiBiZSBkZS1mYWN0byBtYW5kYXRlZCBieSB0aGUgY2hvaWNlIG9mIGJyb3dzZXJz IGZvciBJbnRlcm5ldCwgSSB0aGluayB3aGF0IENocmlzdGVyL0FsYnJlY2h0IHN1Z2dlc3RlZCBp cyB0aGUgcmlnaHQgd2F5IHRvIG1vdmUgZm9yd2FyZDogcHJvdmlkZSBjbGFyaWZpY2F0aW9ucyBm b3IgdmFndWUgcG9pbnRzLiBJIGRvbuKAmXQgdW5kZXJzdGFuZCB3aHkgbGFjayBvZiBjbGFyaXR5 IGluIGV4aXN0aW5nIHNwZWNpZmljYXRpb25zIHNob3VsZCBjYXVzZSBpbXBvc2luZyByZXN0cmlj dGlvbnMuIFRoaXMgd291bGQgYmUgYWtpbiB0byBkcm9wcGluZyBhIGZlYXR1cmUgZHVlIHRvIGEg YnVnLiBJbiB0aGlzIGNhc2UsIHRoZSDigJxidWfigJ0gaXMgbGFjayBvZiBjbGFyaXR5IGluIG5v cm1hdGl2ZSBzcGVjaWZpY2F0aW9ucyBhbmQgaXQgY2FuIGJlIGFkZHJlc3NlZCBieSBmdXJ0aGVy IHNwZWNpZmljYXRpb24uDQoNClRoYW5rcywNClRvbGdhDQoNCkZyb206IFJvbWFuIFNocG91bnQg W21haWx0bzpyb21hbkB0ZWx1cml4LmNvbV0NClNlbnQ6IFdlZG5lc2RheSwgQXVndXN0IDA1LCAy MDE1IDEyOjI5IFBNDQpUbzogUmF1c2NoZW5iYWNoLCBVd2UgKE5va2lhIC0gREUvTXVuaWNoKSA8 dXdlLnJhdXNjaGVuYmFjaEBub2tpYS5jb208bWFpbHRvOnV3ZS5yYXVzY2hlbmJhY2hAbm9raWEu Y29tPj4NCkNjOiBleHQgRXJpYyBSZXNjb3JsYSA8ZWtyQHJ0Zm0uY29tPG1haWx0bzpla3JAcnRm bS5jb20+PjsgU2Nod2FyeiwgQWxicmVjaHQgKEFsYnJlY2h0KSA8YWxicmVjaHQuc2Nod2FyekBh bGNhdGVsLWx1Y2VudC5jb208bWFpbHRvOmFsYnJlY2h0LnNjaHdhcnpAYWxjYXRlbC1sdWNlbnQu Y29tPj47IEFzdmVyZW4sIFRvbGdhIDx0YXN2ZXJlbkBzb251c25ldC5jb208bWFpbHRvOnRhc3Zl cmVuQHNvbnVzbmV0LmNvbT4+OyBDaHJpc3RlciBIb2xtYmVyZyA8Y2hyaXN0ZXIuaG9sbWJlcmdA ZXJpY3Nzb24uY29tPG1haWx0bzpjaHJpc3Rlci5ob2xtYmVyZ0Blcmljc3Nvbi5jb20+PjsgQmVy bmFyZCBBYm9iYSA8YmVybmFyZC5hYm9iYUBnbWFpbC5jb208bWFpbHRvOmJlcm5hcmQuYWJvYmFA Z21haWwuY29tPj47IDxydGN3ZWJAaWV0Zi5vcmc8bWFpbHRvOnJ0Y3dlYkBpZXRmLm9yZz4+IDxy dGN3ZWJAaWV0Zi5vcmc8bWFpbHRvOnJ0Y3dlYkBpZXRmLm9yZz4+DQpTdWJqZWN0OiBSZTogW3J0 Y3dlYl0gV2hhdCB0aGUgZ2F0ZXdheSBkcmFmdCBzaG91bGQgc2F5IGFib3V0IG11eC9ub24tbXV4 DQoNCk9uIFdlZCwgQXVnIDUsIDIwMTUgYXQgNDo0NyBBTSwgUmF1c2NoZW5iYWNoLCBVd2UgKE5v a2lhIC0gREUvTXVuaWNoKSA8dXdlLnJhdXNjaGVuYmFjaEBub2tpYS5jb208bWFpbHRvOnV3ZS5y YXVzY2hlbmJhY2hAbm9raWEuY29tPj4gd3JvdGU6DQpNZWRpYSBnYXRld2F5IGltcGxlbWVudGF0 aW9ucyBhY2NvcmRpbmcgdG8gM0dQUCBUUyAyMy4yMjggbWF5IG5vdCBzdXBwb3J0IHJ0Y3AtbXV4 LCBhcyBydGNwLW11eCBpcyBvcHRpb25hbCB0aGVyZS4NClNvIGlmIHdlIGRyb3Agbm9uLW11eCBz dXBwb3J0IGZyb20gd2ViIGJyb3dzZXJzLCB0aG9zZSBtZWRpYSBnYXRld2F5cyB0aGF0IGhhdmUg bm90IGltcGxlbWVudGVkIHJ0Y3AtbXV4IHdpbGwgc3RvcCBpbnRlcm9wZXJhdGluZy4NCg0KDQpG aXJzdCBvZiBhbGwsIGRvIHlvdSBrbm93IG9mIGFueSBXZWJSVEMgdG8gSU1TIGdhdGV3YXlzIHRo YXQgZG8gbm90IGltcGxlbWVudCBydGNwLW11eCBvbiB0aGUgV2ViUlRDIHNpZGU/IEkgc3Ryb25n bHkgc3VzcGVjdCB0aGVyZSBhcmUgbm9uZS4NCg0KU2Vjb25kLCB0aGUgb25seSByZWFzb25zIG5v dCB0byB1c2UgcnRjcC1tdXggdGhhdCBJIGNhbiB0aGluayBvZiBhcmUgdGhlIGZvbGxvd2luZzoN Cg0KMS4gVXNpbmcgZGlmZmVyZW50IFFPUyBzZXR0aW5ncyBmb3IgUlRDUCB2cyBSVFANCjIuIFNl bmRpbmcgUlRDUCB0byBhIGRpZmZlcmVudCBkZXZpY2UgZnJvbSBSVFANCg0KSSBkbyBub3QgdGhp bmsgdGhlIGZpcnN0IHVzZSBjYXNlIHdhcnJhbnRzIG1ha2luZyBydGNwLW11eCBvcHRpb25hbCwg c2luY2UsIHByYWN0aWNhbGx5IG5vIG9uZSBkb2VzIHRoaXMuDQpTZWNvbmQgdXNlIGNhc2UgaXMg YWxzbyBmYWlybHkgbWFyZ2luYWwuIFBsdXMgaXQgY2FuIGJlIGhhbmRsZWQgYnkgdGhlIGdhdGV3 YXkgd2hpY2ggY2FuIHNlbmQgUlRDUCB0byBvbmUgZGV2aWNlIGFuZCBSVFAgdG8gYW5vdGhlci4N Cg0KU28sIHVubGVzcyBzb21lb25lIGNhbiBjb21lIHVwIHdpdGggYSB1c2UgY2FzZSB3aHkgUlRQ IGFuZCBSVENQIHNob3VsZCB1c2UgZGlmZmVyZW50IHRyYW5zcG9ydHMsIEkgdGhpbmsgcnRjcC1t dXggc2hvdWxkIGJlIG1hbmRhdG9yeS4NCg0KUmVnYXJkcywNCl9fX19fX19fX19fX19fDQpSb21h biBTaHBvdW50DQpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f Xw0KcnRjd2ViIG1haWxpbmcgbGlzdA0KcnRjd2ViQGlldGYub3JnPG1haWx0bzpydGN3ZWJAaWV0 Zi5vcmc+DQpodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL3J0Y3dlYg0KDQo= --_000_SN1PR0301MB1551852C42AFEB308672D524B2740SN1PR0301MB1551_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPCEtLVtp ZiAhbXNvXT48c3R5bGU+dlw6KiB7YmVoYXZpb3I6dXJsKCNkZWZhdWx0I1ZNTCk7fQ0Kb1w6KiB7 YmVoYXZpb3I6dXJsKCNkZWZhdWx0I1ZNTCk7fQ0Kd1w6KiB7YmVoYXZpb3I6dXJsKCNkZWZhdWx0 I1ZNTCk7fQ0KLnNoYXBlIHtiZWhhdmlvcjp1cmwoI2RlZmF1bHQjVk1MKTt9DQo8L3N0eWxlPjwh W2VuZGlmXS0tPjxzdHlsZT48IS0tDQovKiBGb250IERlZmluaXRpb25zICovDQpAZm9udC1mYWNl DQoJe2ZvbnQtZmFtaWx5OkhlbHZldGljYTsNCglwYW5vc2UtMToyIDExIDYgNCAyIDIgMiAyIDIg NDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OiJDYW1icmlhIE1hdGgiOw0KCXBhbm9zZS0x OjIgNCA1IDMgNSA0IDYgMyAyIDQ7fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseTpDYWxpYnJp Ow0KCXBhbm9zZS0xOjIgMTUgNSAyIDIgMiA0IDMgMiA0O30NCkBmb250LWZhY2UNCgl7Zm9udC1m YW1pbHk6VGFob21hOw0KCXBhbm9zZS0xOjIgMTEgNiA0IDMgNSA0IDQgMiA0O30NCkBmb250LWZh Y2UNCgl7Zm9udC1mYW1pbHk6Q29uc29sYXM7DQoJcGFub3NlLTE6MiAxMSA2IDkgMiAyIDQgMyAy IDQ7fQ0KLyogU3R5bGUgRGVmaW5pdGlvbnMgKi8NCnAuTXNvTm9ybWFsLCBsaS5Nc29Ob3JtYWws IGRpdi5Nc29Ob3JtYWwNCgl7bWFyZ2luOjBpbjsNCgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJ Zm9udC1zaXplOjEyLjBwdDsNCglmb250LWZhbWlseToiVGltZXMgTmV3IFJvbWFuIixzZXJpZjt9 DQphOmxpbmssIHNwYW4uTXNvSHlwZXJsaW5rDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCglj b2xvcjpibHVlOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0KYTp2aXNpdGVkLCBzcGFu Lk1zb0h5cGVybGlua0ZvbGxvd2VkDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgljb2xvcjpw dXJwbGU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQpwLk1zb0FjZXRhdGUsIGxpLk1z b0FjZXRhdGUsIGRpdi5Nc29BY2V0YXRlDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgltc28t c3R5bGUtbGluazoiQmFsbG9vbiBUZXh0IENoYXIiOw0KCW1hcmdpbjowaW47DQoJbWFyZ2luLWJv dHRvbTouMDAwMXB0Ow0KCWZvbnQtc2l6ZTo4LjBwdDsNCglmb250LWZhbWlseToiVGFob21hIixz YW5zLXNlcmlmO30NCnNwYW4uQmFsbG9vblRleHRDaGFyDQoJe21zby1zdHlsZS1uYW1lOiJCYWxs b29uIFRleHQgQ2hhciI7DQoJbXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCW1zby1zdHlsZS1saW5r OiJCYWxsb29uIFRleHQiOw0KCWZvbnQtZmFtaWx5OiJUYWhvbWEiLHNhbnMtc2VyaWY7fQ0Kc3Bh bi5hcHBsZS1jb252ZXJ0ZWQtc3BhY2UNCgl7bXNvLXN0eWxlLW5hbWU6YXBwbGUtY29udmVydGVk LXNwYWNlO30NCnNwYW4uRW1haWxTdHlsZTIwDQoJe21zby1zdHlsZS10eXBlOnBlcnNvbmFsOw0K CWZvbnQtZmFtaWx5OiJDYWxpYnJpIixzYW5zLXNlcmlmOw0KCWNvbG9yOiMxRjQ5N0Q7fQ0Kc3Bh bi5FbWFpbFN0eWxlMjENCgl7bXNvLXN0eWxlLXR5cGU6cGVyc29uYWwtcmVwbHk7DQoJZm9udC1m YW1pbHk6IkNhbGlicmkiLHNhbnMtc2VyaWY7DQoJY29sb3I6IzFGNDk3RDt9DQouTXNvQ2hwRGVm YXVsdA0KCXttc28tc3R5bGUtdHlwZTpleHBvcnQtb25seTsNCglmb250LXNpemU6MTAuMHB0O30N CkBwYWdlIFdvcmRTZWN0aW9uMQ0KCXtzaXplOjguNWluIDExLjBpbjsNCgltYXJnaW46MS4waW4g MS4waW4gMS4waW4gMS4waW47fQ0KZGl2LldvcmRTZWN0aW9uMQ0KCXtwYWdlOldvcmRTZWN0aW9u MTt9DQotLT48L3N0eWxlPjwhLS1baWYgZ3RlIG1zbyA5XT48eG1sPg0KPG86c2hhcGVkZWZhdWx0 cyB2OmV4dD0iZWRpdCIgc3BpZG1heD0iMTAyNiIgLz4NCjwveG1sPjwhW2VuZGlmXS0tPjwhLS1b aWYgZ3RlIG1zbyA5XT48eG1sPg0KPG86c2hhcGVsYXlvdXQgdjpleHQ9ImVkaXQiPg0KPG86aWRt YXAgdjpleHQ9ImVkaXQiIGRhdGE9IjEiIC8+DQo8L286c2hhcGVsYXlvdXQ+PC94bWw+PCFbZW5k aWZdLS0+DQo8L2hlYWQ+DQo8Ym9keSBsYW5nPSJFTi1VUyIgbGluaz0iYmx1ZSIgdmxpbms9InB1 cnBsZSI+DQo8ZGl2IGNsYXNzPSJXb3JkU2VjdGlvbjEiPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZx dW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0QiPuKAnDwvc3Bhbj48c3BhbiBzdHlsZT0iZm9u dC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7 Y29sb3I6IzFGNDk3RCI+aXQgaXMgc3VyZWx5IGFib3V0IHdoZXRoZXIgV2ViUlRDIGJyb3dzZXJz IGhhdmUgdG8gc3VwcG9ydCBub24tbXV44oCdPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6 JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0QiPnByZWNpc2VseS48 bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0i Zm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2Vy aWY7Y29sb3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1 b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0QiPklmIHRoZXJlIGlzIGEg bmVlZCBmb3IgcHJvZmlsaW5nLCBpdCBuZWVkcyB0byBiZSBkb25lIGFzIGFwcGxpY2FibGUgdG8g YnJvd3NlcnMuIFNvLCBhbnkgY2xhcmlmaWNhdGlvbi9zdGF0ZW1lbnQgZG9lcyBub3QgYmVsb25n IHRvIEdXLWRyYWZ0IGJ1dCBzb21ld2hlcmUgZWxzZS48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZh bWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RCI+PG86cD4m bmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9 ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNl cmlmO2NvbG9yOiMxRjQ5N0QiPkJUVywg4oCcZml4aW5n4oCdIHRoZSBsYWNrIG9mIGNsYXJpdHkg YWJvdXQgdXNlIG9mIERUTFMgd2hlbiBydGNwLW11eCBpcyBub3QgdXNlZC9mb3IgRGF0YUNoYW5u ZWwgaXMgYSBzZXBhcmF0ZSBpc3N1ZSBhbmQgc2hvdWxkIGJlIGFkZHJlc3NlZCBhcyB3ZWxsLjxv OnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJm b250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJp Zjtjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVv dDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RCI+VGhhbmtzLDxvOnA+PC9v OnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNp emU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xv cjojMUY0OTdEIj5Ub2xnYTxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGli cmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bh bj48L3A+DQo8ZGl2IHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItbGVmdDpzb2xpZCBibHVlIDEu NXB0O3BhZGRpbmc6MGluIDBpbiAwaW4gNC4wcHQiPg0KPGRpdj4NCjxkaXYgc3R5bGU9ImJvcmRl cjpub25lO2JvcmRlci10b3A6c29saWQgI0UxRTFFMSAxLjBwdDtwYWRkaW5nOjMuMHB0IDBpbiAw aW4gMGluIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6 MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZiI+RnJvbTo8 L3NwYW4+PC9iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90 O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZiI+IEh1dHRvbiwgQW5kcmV3IFttYWlsdG86YW5kcmV3 Lmh1dHRvbkB1bmlmeS5jb21dDQo8YnI+DQo8Yj5TZW50OjwvYj4gVGh1cnNkYXksIEF1Z3VzdCAw NiwgMjAxNSA5OjMwIEFNPGJyPg0KPGI+VG86PC9iPiB0aW0gcGFudG9uICZsdDt0aW1AcGhvbmVm cm9taGVyZS5jb20mZ3Q7OyBBc3ZlcmVuLCBUb2xnYSAmbHQ7dGFzdmVyZW5Ac29udXNuZXQuY29t Jmd0Ozxicj4NCjxiPkNjOjwvYj4gJmx0O3J0Y3dlYkBpZXRmLm9yZyZndDsgJmx0O3J0Y3dlYkBp ZXRmLm9yZyZndDs8YnI+DQo8Yj5TdWJqZWN0OjwvYj4gUkU6IFtydGN3ZWJdIFdoYXQgdGhlIGdh dGV3YXkgZHJhZnQgc2hvdWxkIHNheSBhYm91dCBtdXgvbm9uLW11eDxvOnA+PC9vOnA+PC9zcGFu PjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwv bzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEu MHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0 OTdEIj4mIzQzOzEgdG8gd2hhdCBUaW0gc2FpZC48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWls eTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RCI+PG86cD4mbmJz cDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZv bnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlm O2NvbG9yOiMxRjQ5N0QiPkkgZG9u4oCZdCB0aGluayB0aGlzIGRpc2N1c3Npb24gaXMgcmVhbGx5 IGFib3V0IGdhdGV3YXlzIGF0IGFsbCBpdCBpcyBzdXJlbHkgYWJvdXQgd2hldGhlciBXZWJSVEMg YnJvd3NlcnMgaGF2ZSB0byBzdXBwb3J0IG5vbi1tdXggYW5kIEkgZG9u4oCZdCByZWFsbHkgc2Vl IGFueSBnb29kDQogcmVhc29uIHdoeSB0aGV5IG5lZWQgdG8uPG86cD48L286cD48L3NwYW4+PC9w Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9u dC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0QiPjxv OnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0 eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fu cy1zZXJpZjtjb2xvcjojMUY0OTdEIj5JZiB3ZSBoYWQgdGhvdWdodCBhYm91dCB0aGlzIGF0IHRo ZSB0aW1lIHdlIG1hbmRhdGVkIERUTFMtU1JUUCB0aGVuIHdlIHdvdWxkIGhhdmUgbWFuZGF0ZWQg cnRwLW11eCBhdCB0aGUgc2FtZSB0aW1lIGJ1dCB1bmZvcnR1bmF0ZWx5IHdlIGRpZG7igJl0IGJ1 dCB3ZSBjYW4gZml4DQogdGhhdCBub3cuPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1 b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9v OnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNp emU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xv cjojMUY0OTdEIj5BbmR5PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJy aSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFu PjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0 O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdE Ij48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8ZGl2IHN0eWxlPSJib3JkZXI6bm9uZTti b3JkZXItbGVmdDpzb2xpZCBibHVlIDEuNXB0O3BhZGRpbmc6MGluIDBpbiAwaW4gNC4wcHQiPg0K PGRpdj4NCjxkaXYgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci10b3A6c29saWQgI0I1QzRERiAx LjBwdDtwYWRkaW5nOjMuMHB0IDBpbiAwaW4gMGluIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxi PjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O1RhaG9tYSZx dW90OyxzYW5zLXNlcmlmIj5Gcm9tOjwvc3Bhbj48L2I+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTox MC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7VGFob21hJnF1b3Q7LHNhbnMtc2VyaWYiPiBydGN3ZWIg WzxhIGhyZWY9Im1haWx0bzpydGN3ZWItYm91bmNlc0BpZXRmLm9yZyI+bWFpbHRvOnJ0Y3dlYi1i b3VuY2VzQGlldGYub3JnPC9hPl0NCjxiPk9uIEJlaGFsZiBPZiA8L2I+dGltIHBhbnRvbjxicj4N CjxiPlNlbnQ6PC9iPiAwNiBBdWd1c3QgMjAxNSAxMzo1Mzxicj4NCjxiPlRvOjwvYj4gQXN2ZXJl biwgVG9sZ2E8YnI+DQo8Yj5DYzo8L2I+ICZsdDs8YSBocmVmPSJtYWlsdG86cnRjd2ViQGlldGYu b3JnIj5ydGN3ZWJAaWV0Zi5vcmc8L2E+Jmd0Ozxicj4NCjxiPlN1YmplY3Q6PC9iPiBSZTogW3J0 Y3dlYl0gV2hhdCB0aGUgZ2F0ZXdheSBkcmFmdCBzaG91bGQgc2F5IGFib3V0IG11eC9ub24tbXV4 PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+U28gd2UgYXJl IHBvc2l0aW5nIHRoZSBleGlzdGVuY2Ugb2YgYSB3ZWJSVEMgZ2F0ZXdheSBkZXNpZ25lZCB0byBz dXBwb3J0IHRob3VzYW5kcyBvZiBjYWxscyB3aGljaCBkb2VzIElDRSBhbmQgRFRMUyBidXQgdGhl PG86cD48L286cD48L3A+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPmRlc2ln bmVyIGRlY2lkZWQgZGVsaWJlcmF0ZWx5IHRvIGRvdWJsZSB0aGUgbnVtYmVyIG9mIElDRSBzZXNz aW9ucyByZXF1aXJlZCBhbmQgZG91YmxlIHRoZSBudW1iZXIgb2YgRFRMUyBzZXNzaW9ucyAoYW5k IGtleSZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+Z2VuZXJhdGlvbiBjb3N0cykgc28gdGhhdCB0aGV5IGNhbiBydW4gUlRDUCAob3ZlciBJ Q0UgYW5kIERUTFMpIG9uIGEgc2VwYXJhdGUgcG9ydC4gSW4gbXkgZXN0aW1hdGlvbiB0aGF04oCZ cyBvbmUgcG9vciBkZWNpc2lvbjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+YW5kIHNob3VsZCBub3QgYmUgdXNlZCBhcyB0aGUgYmFzaXMgb2YgdGhp cyAob3IgYW55KSBzdGFuZGFyZC4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2 Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+SeKAmWQgcmF0aGVyIG5vdCBzdXBwb3J0IHJ0Y3Atbm8t bXV4IGFzIEkgc2VlIHplcm8gYWR2YW50YWdlcyBpbiBoYXZpbmcgaXQuIChJIGtub3cgdGhlb3Jl dGljYWxseSBpdCBtaWdodCBiZSBwb3NzaWJsZSB0byBnZXQ8bzpwPjwvbzpwPjwvcD4NCjwvZGl2 Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPmEgUlRDUCBwYWNrZXQgdGhyb3VnaCBhIGNv bmdlc3RlZCBuZXQgb24gYSBkaWZmZXJlbnQgcG9ydCB3aXRoIGEgc2VwYXJhdGUgZGlmZnNlcnYg c2V0dGluZyBidXQgdGhhdCBqdXN0IHNlZW1zIHNvIGNvbnRyaXZlZCkuPG86cD48L286cD48L3A+ DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwv cD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPlRpbS48bzpwPjwvbzpwPjwv cD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+ PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286 cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2Pg0KPGJsb2NrcXVvdGUgc3R5bGU9Im1hcmdpbi10 b3A6NS4wcHQ7bWFyZ2luLWJvdHRvbTo1LjBwdCI+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+T24gNiBBdWcgMjAxNSwgYXQgMDY6NDQsIEFzdmVyZW4sIFRvbGdhICZsdDs8YSBocmVmPSJt YWlsdG86dGFzdmVyZW5Ac29udXNuZXQuY29tIj50YXN2ZXJlbkBzb251c25ldC5jb208L2E+Jmd0 OyB3cm90ZTo8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86 cD4mbmJzcDs8L286cD48L3A+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxz cGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVv dDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEIj5UaGVzZSBhc3N1bXB0aW9ucyBhcmUgbm90IG5l Y2Vzc2FyaWx5IHRydWUgaW4gYSB1bml2ZXJzYWwgc2Vuc2UgKGxpa2UgYWxtb3N0IGFueSBvdGhl ciBhc3N1bXB0aW9uIGFib3V0IGRpZmZlcmVudCBkZXBsb3ltZW50IG1vZGVscykuPC9zcGFuPjxv OnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4g c3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90Oyxz YW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0QiPiZuYnNwOzwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwv ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6 MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjoj MUY0OTdEIj5GdXJ0aGVybW9yZSwgYW5kIG1vcmUgaW1wb3J0YW50bHksIHRoZXJlIGlzIG5vdGhp bmcgbWFuZGF0aW5nIFdlYlJUQyBlbmRwb2ludHMgdG8gc3VwcG9ydCBub24tcnRjcC1tdXguIEl0 IGlzIGEgbmVnb3RpYXRlZCBmdW5jdGlvbmFsaXR5LiBBbnkgZW50aXR5IGNhbiBlbmZvcmNlDQog cnRjcC1tdXggYXMgYSBsb2NhbCBwb2xpY3kuPHNwYW4gY2xhc3M9ImFwcGxlLWNvbnZlcnRlZC1z cGFjZSI+Jm5ic3A7PC9zcGFuPjwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQt ZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEIj4mbmJz cDs8L3NwYW4+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxp YnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RCI+VGhlIGlzc3VlIHdpdGggc3VwcG9y dGluZyBub24tcnRjcC1tdXggc2VlbXMgdG8gYmUgbGFjayBvZiBjbGFyaXR5IGluIHRoZSByZWxl dmFudCBzcGVjaWZpY2F0aW9ucy4gRml4aW5nIHRoaXMg4oCTcmVnYXJkbGVzcyBvZiB0aGUgb3V0 Y29tZSBvZiBhbnkgb3RoZXIgZGlzY3Vzc2lvbi0NCiBzZWVtcyB0byBiZSBwcnVkZW50IElNSE8u PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJy aSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0QiPiZuYnNwOzwvc3Bhbj48bzpwPjwvbzpw PjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJm b250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJp Zjtjb2xvcjojMUY0OTdEIj5UaGFua3MsPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8 ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7 Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0Qi PlRvbGdhPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7 Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0QiPiZuYnNwOzwvc3Bhbj48bzpw PjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdiBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLWxlZnQ6 c29saWQgYmx1ZSAxLjVwdDtwYWRkaW5nOjBpbiAwaW4gMGluIDQuMHB0Ij4NCjxkaXY+DQo8ZGl2 IHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItdG9wOnNvbGlkICNFMUUxRTEgMS4wcHQ7cGFkZGlu ZzozLjBwdCAwaW4gMGluIDBpbiI+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGI+PHNw YW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90 OyxzYW5zLXNlcmlmIj5Gcm9tOjwvc3Bhbj48L2I+PHNwYW4gY2xhc3M9ImFwcGxlLWNvbnZlcnRl ZC1zcGFjZSI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7 Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmIj4mbmJzcDs8L3NwYW4+PC9zcGFuPjxzcGFuIHN0eWxl PSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1z ZXJpZiI+V3lzcywNCiBGZWxpeCBbPGEgaHJlZj0ibWFpbHRvOkZlbGl4Lld5c3NAaW5pbi5jb20i Pm1haWx0bzpGZWxpeC5XeXNzQGluaW4uY29tPC9hPl08c3BhbiBjbGFzcz0iYXBwbGUtY29udmVy dGVkLXNwYWNlIj4mbmJzcDs8L3NwYW4+PGJyPg0KPGI+U2VudDo8L2I+PHNwYW4gY2xhc3M9ImFw cGxlLWNvbnZlcnRlZC1zcGFjZSI+Jm5ic3A7PC9zcGFuPlRodXJzZGF5LCBBdWd1c3QgMDYsIDIw MTUgNjozNyBBTTxicj4NCjxiPlRvOjwvYj48c3BhbiBjbGFzcz0iYXBwbGUtY29udmVydGVkLXNw YWNlIj4mbmJzcDs8L3NwYW4+Q2hyaXN0ZXIgSG9sbWJlcmcgJmx0OzxhIGhyZWY9Im1haWx0bzpj aHJpc3Rlci5ob2xtYmVyZ0Blcmljc3Nvbi5jb20iPmNocmlzdGVyLmhvbG1iZXJnQGVyaWNzc29u LmNvbTwvYT4mZ3Q7OyBBc3ZlcmVuLCBUb2xnYSAmbHQ7PGEgaHJlZj0ibWFpbHRvOnRhc3ZlcmVu QHNvbnVzbmV0LmNvbSI+dGFzdmVyZW5Ac29udXNuZXQuY29tPC9hPiZndDs7IFNjaHdhcnosIEFs YnJlY2h0DQogKEFsYnJlY2h0KSAmbHQ7PGEgaHJlZj0ibWFpbHRvOmFsYnJlY2h0LnNjaHdhcnpA YWxjYXRlbC1sdWNlbnQuY29tIj5hbGJyZWNodC5zY2h3YXJ6QGFsY2F0ZWwtbHVjZW50LmNvbTwv YT4mZ3Q7OyBSb21hbiBTaHBvdW50ICZsdDs8YSBocmVmPSJtYWlsdG86cm9tYW5AdGVsdXJpeC5j b20iPnJvbWFuQHRlbHVyaXguY29tPC9hPiZndDs7IFJhdXNjaGVuYmFjaCwgVXdlIChOb2tpYSAt IERFL011bmljaCkgJmx0OzxhIGhyZWY9Im1haWx0bzp1d2UucmF1c2NoZW5iYWNoQG5va2lhLmNv bSI+dXdlLnJhdXNjaGVuYmFjaEBub2tpYS5jb208L2E+Jmd0Ozxicj4NCjxiPkNjOjwvYj48c3Bh biBjbGFzcz0iYXBwbGUtY29udmVydGVkLXNwYWNlIj4mbmJzcDs8L3NwYW4+Jmx0OzxhIGhyZWY9 Im1haWx0bzpydGN3ZWJAaWV0Zi5vcmciPnJ0Y3dlYkBpZXRmLm9yZzwvYT4mZ3Q7ICZsdDs8YSBo cmVmPSJtYWlsdG86cnRjd2ViQGlldGYub3JnIj5ydGN3ZWJAaWV0Zi5vcmc8L2E+Jmd0Ozxicj4N CjxiPlN1YmplY3Q6PC9iPjxzcGFuIGNsYXNzPSJhcHBsZS1jb252ZXJ0ZWQtc3BhY2UiPiZuYnNw Ozwvc3Bhbj5SZTogW3J0Y3dlYl0gV2hhdCB0aGUgZ2F0ZXdheSBkcmFmdCBzaG91bGQgc2F5IGFi b3V0IG11eC9ub24tbXV4PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwv ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0K PC9kaXY+DQo8ZGl2IGlkPSJkaXZ0YWdkZWZhdWx0d3JhcHBlciI+DQo8ZGl2Pg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCIgc3R5bGU9ImJhY2tncm91bmQ6d2hpdGUiPjxzcGFuIHN0eWxlPSJmb250LWZh bWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWYiPldoeSBzaG91bGRuJ3QgdGhlIGdh dGV3YXkgYmUgcmVxdWlyZWQgdG8gZG8gdGhlIG11eC9kZW11eD8mbmJzcDsgTWFraW5nIHRoZSBX ZWJSVEMgZW5kcG9pbnRzIGEgbG90IG1vcmUgY29tcGxleCBqdXN0IHNvIHRoZSBsZWdhY3kgaW50 ZXJvcCBtaWdodCBwb3RlbnRpYWxseSBiZSBhIHRlZW55LXRpbnkNCiBiaXQgZWFzaWVyIG1ha2Vz IG5vIHNlbnNlIElNSE8uJm5ic3A7IEFjdHVhbGx5LCB0aGUgZ2F0ZXdheSB3b3VsZCBub3QgYmUg YWJsZSB0byBkbyAmcXVvdDtlbmQtdG8tZW5kJnF1b3Q7IHBhc3MtdGhyb3VnaCBhbnl3YXkgYXMg bGVnYWN5IGVxdWlwbWVudCB3aWxsIGVpdGhlciBiZSB1bmVuY3J5cHRlZCBvciB1c2UgU0RFUyAo UkZDIzQ1NjgpIGZvciBrZXkgZXhjaGFuZ2UuJm5ic3A7IFNvIHRoZSBnYXRld2F5IHdpbGwgaGF2 ZSB0byBwZXJmb3JtIERUTFMtU1JUUCB0byBTREVTLVNSVFANCiB0cmFuc2NyeXB0aW9uLS13aGlj aCBhbHJlYWR5IGlzIHdheSBtb3JlIGhhc3NsZSB0aGFuIFJUUC9SVENQIG11eC9kZW11eC48L3Nw YW4+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBz dHlsZT0iYmFja2dyb3VuZDp3aGl0ZSI+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O0Nh bGlicmkmcXVvdDssc2Fucy1zZXJpZiI+Jm5ic3A7PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9k aXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9ImJhY2tncm91bmQ6d2hpdGUi PjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWYi Pi0tRmVsaXg8L3NwYW4+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIiBzdHlsZT0iYmFja2dyb3VuZDp3aGl0ZSI+PHNwYW4gc3R5bGU9ImZvbnQtZmFt aWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZiI+Jm5ic3A7PC9zcGFuPjxvOnA+PC9v OnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdiBjbGFzcz0iTXNvTm9ybWFsIiBhbGlnbj0iY2Vu dGVyIiBzdHlsZT0idGV4dC1hbGlnbjpjZW50ZXI7YmFja2dyb3VuZDp3aGl0ZSI+DQo8c3BhbiBz dHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmIj4NCjxociBz aXplPSIyIiB3aWR0aD0iOTglIiBhbGlnbj0iY2VudGVyIj4NCjwvc3Bhbj48L2Rpdj4NCjxkaXYg aWQ9ImRpdlJwbHlGd2RNc2ciPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJi YWNrZ3JvdW5kOndoaXRlIj48Yj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZh bWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWYiPkZyb206PC9zcGFuPjwvYj48c3Bh biBjbGFzcz0iYXBwbGUtY29udmVydGVkLXNwYWNlIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEx LjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWYiPiZuYnNwOzwv c3Bhbj48L3NwYW4+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1 b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmIj5ydGN3ZWINCiAmbHQ7PGEgaHJlZj0ibWFpbHRv OnJ0Y3dlYi1ib3VuY2VzQGlldGYub3JnIj48c3BhbiBzdHlsZT0iY29sb3I6cHVycGxlIj5ydGN3 ZWItYm91bmNlc0BpZXRmLm9yZzwvc3Bhbj48L2E+Jmd0OyBvbiBiZWhhbGYgb2YgQ2hyaXN0ZXIg SG9sbWJlcmcgJmx0OzxhIGhyZWY9Im1haWx0bzpjaHJpc3Rlci5ob2xtYmVyZ0Blcmljc3Nvbi5j b20iPjxzcGFuIHN0eWxlPSJjb2xvcjpwdXJwbGUiPmNocmlzdGVyLmhvbG1iZXJnQGVyaWNzc29u LmNvbTwvc3Bhbj48L2E+Jmd0Ozxicj4NCjxiPlNlbnQ6PC9iPjxzcGFuIGNsYXNzPSJhcHBsZS1j b252ZXJ0ZWQtc3BhY2UiPiZuYnNwOzwvc3Bhbj5UaHVyc2RheSwgQXVndXN0IDYsIDIwMTUgMDU6 NTE8YnI+DQo8Yj5Ubzo8L2I+PHNwYW4gY2xhc3M9ImFwcGxlLWNvbnZlcnRlZC1zcGFjZSI+Jm5i c3A7PC9zcGFuPkFzdmVyZW4sIFRvbGdhOyBTY2h3YXJ6LCBBbGJyZWNodCAoQWxicmVjaHQpOyBS b21hbiBTaHBvdW50OyBSYXVzY2hlbmJhY2gsIFV3ZSAoTm9raWEgLSBERS9NdW5pY2gpPGJyPg0K PGI+Q2M6PC9iPjxzcGFuIGNsYXNzPSJhcHBsZS1jb252ZXJ0ZWQtc3BhY2UiPiZuYnNwOzwvc3Bh bj4mbHQ7PGEgaHJlZj0ibWFpbHRvOnJ0Y3dlYkBpZXRmLm9yZyI+PHNwYW4gc3R5bGU9ImNvbG9y OnB1cnBsZSI+cnRjd2ViQGlldGYub3JnPC9zcGFuPjwvYT4mZ3Q7PGJyPg0KPGI+U3ViamVjdDo8 L2I+PHNwYW4gY2xhc3M9ImFwcGxlLWNvbnZlcnRlZC1zcGFjZSI+Jm5ic3A7PC9zcGFuPlJlOiBb cnRjd2ViXSBXaGF0IHRoZSBnYXRld2F5IGRyYWZ0IHNob3VsZCBzYXkgYWJvdXQgbXV4L25vbi1t dXg8L3NwYW4+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCIgc3R5bGU9ImJhY2tncm91bmQ6d2hpdGUiPjxzcGFuIHN0eWxlPSJmb250LWZh bWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWYiPiZuYnNwOzwvc3Bhbj48bzpwPjwv bzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJiYWNrZ3JvdW5kOndoaXRlIj48c3BhbiBzdHlsZT0i Zm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2Vy aWY7Y29sb3I6IzFGNDk3RCI+SGksPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2 Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9ImJhY2tncm91bmQ6d2hpdGUiPjxzcGFuIHN0 eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fu cy1zZXJpZjtjb2xvcjojMUY0OTdEIj4mbmJzcDs8L3NwYW4+PG86cD48L286cD48L3A+DQo8L2Rp dj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0iYmFja2dyb3VuZDp3aGl0ZSI+ PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZx dW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0QiPk5vIG1hdHRlciB3aGV0aGVyIHRoZSBnYXRl d2F5IHN1cHBvcnRzIFJUUC9SVENQIG11eCBvciBub3QsIHRoZXJlIGFyZSBjYXNlcyB3aGVyZSB0 aGUgbGVnYWN5IG5ldHdvcmsvZW5kcG9pbnRzIHdpbGwgbm90IHVzZSBSVFAvUlRDUA0KIG11eCwg c28gSSBndWVzcyBwZW9wbGUgdGhlbiB3b3VsZCB3YW50IHRvIGJlIGFibGUgdG8gbmVnb3RpYXRl IG5vbi1tdXgg4oCcZW5kLXRvLWVuZOKAnSwgcmF0aGVyIHRoYW4gaGF2aW5nIHRoZSBnYXRld2F5 IHRvIGRlbXV4L211eCBSVFAgYW5kIFJUQ1AuPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+ DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9ImJhY2tncm91bmQ6d2hpdGUiPjxz cGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVv dDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEIj4mbmJzcDs8L3NwYW4+PG86cD48L286cD48L3A+ DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0iYmFja2dyb3VuZDp3 aGl0ZSI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2Fs aWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0QiPlJlZ2FyZHMsPC9zcGFuPjxvOnA+ PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9ImJh Y2tncm91bmQ6d2hpdGUiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5 OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEIj4mbmJzcDs8L3Nw YW4+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBz dHlsZT0iYmFja2dyb3VuZDp3aGl0ZSI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9u dC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0QiPkNo cmlzdGVyPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1z b05vcm1hbCIgc3R5bGU9ImJhY2tncm91bmQ6d2hpdGUiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6 MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjoj MUY0OTdEIj4mbmJzcDs8L3NwYW4+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2 IHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItdG9wOnNvbGlkICNCNUM0REYgMS4wcHQ7cGFkZGlu ZzozLjBwdCAwaW4gMGluIDBpbiI+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9 ImJhY2tncm91bmQ6d2hpdGUiPjxiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQt ZmFtaWx5OiZxdW90O1RhaG9tYSZxdW90OyxzYW5zLXNlcmlmIj5Gcm9tOjwvc3Bhbj48L2I+PHNw YW4gY2xhc3M9ImFwcGxlLWNvbnZlcnRlZC1zcGFjZSI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTox MC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7VGFob21hJnF1b3Q7LHNhbnMtc2VyaWYiPiZuYnNwOzwv c3Bhbj48L3NwYW4+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1 b3Q7VGFob21hJnF1b3Q7LHNhbnMtc2VyaWYiPkFzdmVyZW4sDQogVG9sZ2EgWzxhIGhyZWY9Im1h aWx0bzp0YXN2ZXJlbkBzb251c25ldC5jb20iPjxzcGFuIHN0eWxlPSJjb2xvcjpwdXJwbGUiPm1h aWx0bzp0YXN2ZXJlbkBzb251c25ldC5jb208L3NwYW4+PC9hPl08c3BhbiBjbGFzcz0iYXBwbGUt Y29udmVydGVkLXNwYWNlIj4mbmJzcDs8L3NwYW4+PGJyPg0KPGI+U2VudDo8L2I+PHNwYW4gY2xh c3M9ImFwcGxlLWNvbnZlcnRlZC1zcGFjZSI+Jm5ic3A7PC9zcGFuPjYuIGVsb2t1dXRhIDIwMTUg MTI6MTg8YnI+DQo8Yj5Ubzo8L2I+PHNwYW4gY2xhc3M9ImFwcGxlLWNvbnZlcnRlZC1zcGFjZSI+ Jm5ic3A7PC9zcGFuPlNjaHdhcnosIEFsYnJlY2h0IChBbGJyZWNodCk7IFJvbWFuIFNocG91bnQ7 IFJhdXNjaGVuYmFjaCwgVXdlIChOb2tpYSAtIERFL011bmljaCk8YnI+DQo8Yj5DYzo8L2I+PHNw YW4gY2xhc3M9ImFwcGxlLWNvbnZlcnRlZC1zcGFjZSI+Jm5ic3A7PC9zcGFuPmV4dCBFcmljIFJl c2NvcmxhOyBDaHJpc3RlciBIb2xtYmVyZzsgQmVybmFyZCBBYm9iYTsgJmx0OzxhIGhyZWY9Im1h aWx0bzpydGN3ZWJAaWV0Zi5vcmciPjxzcGFuIHN0eWxlPSJjb2xvcjpwdXJwbGUiPnJ0Y3dlYkBp ZXRmLm9yZzwvc3Bhbj48L2E+Jmd0Ozxicj4NCjxiPlN1YmplY3Q6PC9iPjxzcGFuIGNsYXNzPSJh cHBsZS1jb252ZXJ0ZWQtc3BhY2UiPiZuYnNwOzwvc3Bhbj5SZTogW3J0Y3dlYl0gV2hhdCB0aGUg Z2F0ZXdheSBkcmFmdCBzaG91bGQgc2F5IGFib3V0IG11eC9ub24tbXV4PC9zcGFuPjxvOnA+PC9v OnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiIHN0eWxlPSJiYWNrZ3JvdW5kOndoaXRlIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2 Pg0KPGRpdiBpZD0iZGl2dGFnZGVmYXVsdHdyYXBwZXIiPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29O b3JtYWwiIHN0eWxlPSJiYWNrZ3JvdW5kOndoaXRlIj48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6 JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmIj5XaHkgc2hvdWxkIHdlIGNvbnNpZGVyIDNH UFAgdGhlIHNvbGUgJnF1b3Q7b3duZXIvdXNlciZxdW90OyBvZiB0aGUgdGVybS9lbnRpdHkgV2Vi UlRDLUdXPyBJIHRoaW5rIGl0IGhhcyBhIG11Y2ggbW9yZSBnZW5lcmFsIG1lYW5pbmcgYW5kIHVz ZSBpbiBwcmFjdGljZS4gSXQgY2FuIHJlZmVyIHRvIG1hbnkNCiBkaWZmZXJlbnQgdHlwZXMgb2Yg ZWxlbWVudHMgd2hpY2ggY2FuIGJlIGRlcGxveWVkIGluIG1hbnkgZGlmZmVyZW50IGVudmlyb25t ZW50cywgaGVuY2UgYW55IGF0dGVtcHQgdG8gZGVmaW5lIGl0IHN0cmljdGx5L3Jlc3RyaWN0IGl0 cyBjYXBhYmlsaXRpZXMgYXJlIGZ1dGlsZSBJTUhPLjwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwv ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJiYWNrZ3JvdW5kOndoaXRl Ij48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlm Ij4mbmJzcDs8L3NwYW4+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIiBzdHlsZT0iYmFja2dyb3VuZDp3aGl0ZSI+PHNwYW4gc3R5bGU9ImZvbnQtZmFt aWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZiI+VGhhbmtzLDwvc3Bhbj48bzpwPjwv bzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJiYWNr Z3JvdW5kOndoaXRlIj48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90 OyxzYW5zLXNlcmlmIj5Ub2xnYTwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJiYWNrZ3JvdW5kOndoaXRlIj48c3BhbiBzdHls ZT0iZm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmIj4mbmJzcDs8L3Nw YW4+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2IGNsYXNzPSJNc29Ob3JtYWwi IGFsaWduPSJjZW50ZXIiIHN0eWxlPSJ0ZXh0LWFsaWduOmNlbnRlcjtiYWNrZ3JvdW5kOndoaXRl Ij4NCjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2Vy aWYiPg0KPGhyIHNpemU9IjIiIHdpZHRoPSI5OCUiIGFsaWduPSJjZW50ZXIiPg0KPC9zcGFuPjwv ZGl2Pg0KPGRpdiBpZD0iZGl2UnBseUZ3ZE1zZyI+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1h bCIgc3R5bGU9ImJhY2tncm91bmQ6d2hpdGUiPjxiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEu MHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZiI+RnJvbTo8L3Nw YW4+PC9iPjxzcGFuIGNsYXNzPSJhcHBsZS1jb252ZXJ0ZWQtc3BhY2UiPjxzcGFuIHN0eWxlPSJm b250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJp ZiI+Jm5ic3A7PC9zcGFuPjwvc3Bhbj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250 LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWYiPlNjaHdhcnosDQogQWxicmVj aHQgKEFsYnJlY2h0KSAmbHQ7PGEgaHJlZj0ibWFpbHRvOmFsYnJlY2h0LnNjaHdhcnpAYWxjYXRl bC1sdWNlbnQuY29tIj48c3BhbiBzdHlsZT0iY29sb3I6cHVycGxlIj5hbGJyZWNodC5zY2h3YXJ6 QGFsY2F0ZWwtbHVjZW50LmNvbTwvc3Bhbj48L2E+Jmd0Ozxicj4NCjxiPlNlbnQ6PC9iPjxzcGFu IGNsYXNzPSJhcHBsZS1jb252ZXJ0ZWQtc3BhY2UiPiZuYnNwOzwvc3Bhbj5UaHVyc2RheSwgQXVn dXN0IDYsIDIwMTUgMjo0NCBBTTxicj4NCjxiPlRvOjwvYj48c3BhbiBjbGFzcz0iYXBwbGUtY29u dmVydGVkLXNwYWNlIj4mbmJzcDs8L3NwYW4+QXN2ZXJlbiwgVG9sZ2E7IFJvbWFuIFNocG91bnQ7 IFJhdXNjaGVuYmFjaCwgVXdlIChOb2tpYSAtIERFL011bmljaCk8YnI+DQo8Yj5DYzo8L2I+PHNw YW4gY2xhc3M9ImFwcGxlLWNvbnZlcnRlZC1zcGFjZSI+Jm5ic3A7PC9zcGFuPmV4dCBFcmljIFJl c2NvcmxhOyBDaHJpc3RlciBIb2xtYmVyZzsgQmVybmFyZCBBYm9iYTsgJmx0OzxhIGhyZWY9Im1h aWx0bzpydGN3ZWJAaWV0Zi5vcmciPjxzcGFuIHN0eWxlPSJjb2xvcjpwdXJwbGUiPnJ0Y3dlYkBp ZXRmLm9yZzwvc3Bhbj48L2E+Jmd0Ozxicj4NCjxiPlN1YmplY3Q6PC9iPjxzcGFuIGNsYXNzPSJh cHBsZS1jb252ZXJ0ZWQtc3BhY2UiPiZuYnNwOzwvc3Bhbj5SRTogW3J0Y3dlYl0gV2hhdCB0aGUg Z2F0ZXdheSBkcmFmdCBzaG91bGQgc2F5IGFib3V0IG11eC9ub24tbXV4PC9zcGFuPjxvOnA+PC9v OnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxl PSJiYWNrZ3JvdW5kOndoaXRlIj48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJy aSZxdW90OyxzYW5zLXNlcmlmIj4mbmJzcDs8L3NwYW4+PG86cD48L286cD48L3A+DQo8L2Rpdj4N CjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFs IiBzdHlsZT0iYmFja2dyb3VuZDp3aGl0ZSI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7 Zm9udC1mYW1pbHk6Q29uc29sYXM7Y29sb3I6IzFGNDk3RCI+VGhlIGNvbmNlcm5lZCAzR1BQIFdl YlJUQyBnYXRld2F5ICgzR1BQIDIzLjMzNC8yOS4zMzQpIHN1cHBvcnRzIGFscmVhZHkgUlRQL1JU Q1AgdHJhbnNwb3J0IG11bHRpcGxleGluZyAoc2luY2UgM0dQUCBSZWxlYXNlIDEyKSwgaS5lLiBz aG91bGQgbm90DQogYmUgdGhlIGxpbWl0aW5nIGZhY3RvciBpbiB0aGlzIGRpc2N1c3Npb24uPHNw YW4gY2xhc3M9ImFwcGxlLWNvbnZlcnRlZC1zcGFjZSI+Jm5ic3A7PC9zcGFuPjwvc3Bhbj48bzpw PjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJi YWNrZ3JvdW5kOndoaXRlIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWls eTpDb25zb2xhcztjb2xvcjojMUY0OTdEIj5Gb3Igb25lcyBpbnRlcmVzdGVkIGluIHRoZSBSVENQ IHBvcnQgYWxsb2NhdGlvbiBydWxlcywgc2VlIEguMjQ4LjU3Ojwvc3Bhbj48bzpwPjwvbzpwPjwv cD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJiYWNrZ3JvdW5k OndoaXRlIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTpDb25zb2xh cztjb2xvcjojMUY0OTdEIj48YSBocmVmPSJodHRwczovL3d3dy5pdHUuaW50L3JlYy9kb2xvZ2lu X3B1Yi5hc3A/bGFuZz1lJmFtcDtpZD1ULVJFQy1ILjI0OC41Ny0yMDE0MTAtSSEhUERGLUUmYW1w O3R5cGU9aXRlbXMiIHRpdGxlPSJDbWQmIzQzO0NsaWNrIG9yIHRhcCB0byBmb2xsb3cgdGhlIGxp bmsiPjxzcGFuIHN0eWxlPSJjb2xvcjpwdXJwbGUiPmh0dHBzOi8vd3d3Lml0dS5pbnQvcmVjL2Rv bG9naW5fcHViLmFzcD9sYW5nPWUmYW1wO2lkPVQtUkVDLUguMjQ4LjU3LTIwMTQxMC1JISFQREYt RSZhbXA7dHlwZT1pdGVtczwvc3Bhbj48L2E+PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+ DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9ImJhY2tncm91bmQ6d2hpdGUiPjxz cGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OkNvbnNvbGFzO2NvbG9yOiMx RjQ5N0QiPkNsYXVzZSA3IGRlc2NyaWJlcyBSVFAvUlRDUCB0cmFuc3BvcnQgbXVsdGlwbGV4aW5n LiBJVFUtVCBILjI0OC41NyBpcyBhbHJlYWR5IHN1cHBvcnRlZCBieSAzR1BQIDI5LjMzNC48L3Nw YW4+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBz dHlsZT0iYmFja2dyb3VuZDp3aGl0ZSI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9u dC1mYW1pbHk6Q29uc29sYXM7Y29sb3I6IzFGNDk3RCI+Jm5ic3A7PC9zcGFuPjxvOnA+PC9vOnA+ PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9ImJhY2tncm91 bmQ6d2hpdGUiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OkNvbnNv bGFzO2NvbG9yOiMxRjQ5N0QiPlRoZSByYXRpb25hbGUgYmVoaW5kIHRoZSDigJxvcHRpb25hbCB0 YWdnaW5n4oCdIGJ5IDIzLjIyOCBpcyBhIHRoaXJkIHJlYXNvbiwgYmV5b25kPC9zcGFuPjxvOnA+ PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9ImJh Y2tncm91bmQ6d2hpdGUiPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1 b3Q7LHNhbnMtc2VyaWYiPiZndDsxLiBVc2luZyBkaWZmZXJlbnQgUU9TIHNldHRpbmdzIGZvciBS VENQIHZzIFJUUDwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiIHN0eWxlPSJiYWNrZ3JvdW5kOndoaXRlIj48c3BhbiBzdHlsZT0iZm9udC1m YW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmIj4mZ3Q7Mi4gU2VuZGluZyBSVENQ IHRvIGEgZGlmZmVyZW50IGRldmljZSBmcm9tIFJUUDwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwv ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJiYWNrZ3JvdW5kOndoaXRl Ij48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTpDb25zb2xhcztjb2xv cjojMUY0OTdEIj4mbmJzcDs8L3NwYW4+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0iYmFja2dyb3VuZDp3aGl0ZSI+PHNwYW4gc3R5bGU9 ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6Q29uc29sYXM7Y29sb3I6IzFGNDk3RCI+RG9u 4oCZdCB3YW50IHRvIGdvIGluIHRoZSAzR1BQIHNwZWNpZmljIGRldGFpbHMsIGJ1dCBpdCBoYXMg bm90aGluZyB0byBkbyB3aXRoIHRoZSAzR1BQIFVFLWVtYmVkZGVkIFdlYlJUQyBjbGllbnQgbm9y IGFueSBjb25zdHJhaW50cyBieSAzR1BQIFdlYlJUQw0KIGdhdGV3YXlzLjwvc3Bhbj48bzpwPjwv bzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJiYWNr Z3JvdW5kOndoaXRlIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTpD b25zb2xhcztjb2xvcjojMUY0OTdEIj4mbmJzcDs8L3NwYW4+PG86cD48L286cD48L3A+DQo8L2Rp dj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0iYmFja2dyb3VuZDp3aGl0ZSI+ PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6Q29uc29sYXM7Y29sb3I6 IzFGNDk3RCI+VGh1cywgYSBXZWJSVEMgZ2F0ZXdheSBNVVNUIHN1cHBvcnQgUlRQL1JUQ1AgdHJh bnNwb3J0IG11bHRpcGxleGluZyBkdWUgdG8gaXRzIHB1cnBvc2UgaW4gaW50ZXJ3b3JraW5nIHN1 cHBvcnQuPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1z b05vcm1hbCIgc3R5bGU9ImJhY2tncm91bmQ6d2hpdGUiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6 MTEuMHB0O2ZvbnQtZmFtaWx5OkNvbnNvbGFzO2NvbG9yOiMxRjQ5N0QiPiZuYnNwOzwvc3Bhbj48 bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxl PSJiYWNrZ3JvdW5kOndoaXRlIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZh bWlseTpDb25zb2xhcztjb2xvcjojMUY0OTdEIj5SZWdhcmRzLDwvc3Bhbj48bzpwPjwvbzpwPjwv cD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJiYWNrZ3JvdW5k OndoaXRlIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTpDb25zb2xh cztjb2xvcjojMUY0OTdEIj5BbGJyZWNodDwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0K PGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJiYWNrZ3JvdW5kOndoaXRlIj48c3Bh biBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTpDb25zb2xhcztjb2xvcjojMUY0 OTdEIj4mbmJzcDs8L3NwYW4+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIiBzdHlsZT0iYmFja2dyb3VuZDp3aGl0ZSI+PHNwYW4gc3R5bGU9ImZvbnQt c2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2Nv bG9yOiMxRjQ5N0QiPiZuYnNwOzwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4N CjxkaXYgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci10b3A6c29saWQgI0I1QzRERiAxLjBwdDtw YWRkaW5nOjMuMHB0IDBpbiAwaW4gMGluIj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBz dHlsZT0iYmFja2dyb3VuZDp3aGl0ZSI+PGI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7 Zm9udC1mYW1pbHk6JnF1b3Q7VGFob21hJnF1b3Q7LHNhbnMtc2VyaWYiPkZyb206PC9zcGFuPjwv Yj48c3BhbiBjbGFzcz0iYXBwbGUtY29udmVydGVkLXNwYWNlIj48c3BhbiBzdHlsZT0iZm9udC1z aXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtUYWhvbWEmcXVvdDssc2Fucy1zZXJpZiI+Jm5i c3A7PC9zcGFuPjwvc3Bhbj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWls eTomcXVvdDtUYWhvbWEmcXVvdDssc2Fucy1zZXJpZiI+QXN2ZXJlbiwNCiBUb2xnYSBbPGEgaHJl Zj0ibWFpbHRvOnRhc3ZlcmVuQHNvbnVzbmV0LmNvbSI+PHNwYW4gc3R5bGU9ImNvbG9yOnB1cnBs ZSI+bWFpbHRvOnRhc3ZlcmVuQHNvbnVzbmV0LmNvbTwvc3Bhbj48L2E+XTxzcGFuIGNsYXNzPSJh cHBsZS1jb252ZXJ0ZWQtc3BhY2UiPiZuYnNwOzwvc3Bhbj48YnI+DQo8Yj5TZW50OjwvYj48c3Bh biBjbGFzcz0iYXBwbGUtY29udmVydGVkLXNwYWNlIj4mbmJzcDs8L3NwYW4+TWl0dHdvY2gsIDUu IEF1Z3VzdCAyMDE1IDE5OjQ3PGJyPg0KPGI+VG86PC9iPjxzcGFuIGNsYXNzPSJhcHBsZS1jb252 ZXJ0ZWQtc3BhY2UiPiZuYnNwOzwvc3Bhbj5Sb21hbiBTaHBvdW50OyBSYXVzY2hlbmJhY2gsIFV3 ZSAoTm9raWEgLSBERS9NdW5pY2gpPGJyPg0KPGI+Q2M6PC9iPjxzcGFuIGNsYXNzPSJhcHBsZS1j b252ZXJ0ZWQtc3BhY2UiPiZuYnNwOzwvc3Bhbj5leHQgRXJpYyBSZXNjb3JsYTsgU2Nod2Fyeiwg QWxicmVjaHQgKEFsYnJlY2h0KTsgQ2hyaXN0ZXIgSG9sbWJlcmc7IEJlcm5hcmQgQWJvYmE7ICZs dDs8YSBocmVmPSJtYWlsdG86cnRjd2ViQGlldGYub3JnIj48c3BhbiBzdHlsZT0iY29sb3I6cHVy cGxlIj5ydGN3ZWJAaWV0Zi5vcmc8L3NwYW4+PC9hPiZndDs8YnI+DQo8Yj5TdWJqZWN0OjwvYj48 c3BhbiBjbGFzcz0iYXBwbGUtY29udmVydGVkLXNwYWNlIj4mbmJzcDs8L3NwYW4+UkU6IFtydGN3 ZWJdIFdoYXQgdGhlIGdhdGV3YXkgZHJhZnQgc2hvdWxkIHNheSBhYm91dCBtdXgvbm9uLW11eDwv c3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0iYmFja2dyb3VuZDp3aGl0ZSI+PHNwYW4gc3R5bGU9ImZv bnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZiI+Jm5ic3A7PC9zcGFuPjxv OnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9 ImJhY2tncm91bmQ6d2hpdGUiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFt aWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEIj5pLSBJIGh1 bWJseSBkaXNhZ3JlZSB0aGF0IHVzaW5nIGRpZmZlcmVudCBRb1MgUlRDUC9SVFAsIGUuZy4gZGlm ZmVyZW50IERpZmZTZXJ2IHZhbHVlcyAsIHNob3VsZCBiZSBkaXNtaXNzZWQuPC9zcGFuPjxvOnA+ PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9ImJh Y2tncm91bmQ6d2hpdGUiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5 OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEIj5paS0gTGV0IG1l IGFsc28gYWRkIGFub3RoZXIgcmVhc29uIHdoeSBuby1ydGNwLW11eCBtYXkgYmUgbmVlZGVkOiBJ bXBsZW1lbnRhdGlvbiBkaWZmaWN1bHRpZXMgaW4gY2VydGFpbiBHV3MuPC9zcGFuPjxvOnA+PC9v OnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9ImJhY2tn cm91bmQ6d2hpdGUiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZx dW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEIj4mbmJzcDs8L3NwYW4+ PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHls ZT0iYmFja2dyb3VuZDp3aGl0ZSI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1m YW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0QiPkNvbnNp ZGVyaW5nIHRoYXQgdGhlcmUgaXMgYWxyZWFkeSBhIG5lZ290aWF0aW9uIG1lY2hhbmlzbSBmb3Ig cnRjcC1tdXggc3VwcG9ydCwgdGhhdCBpdCBjYW4gYmUgZGUtZmFjdG8gbWFuZGF0ZWQgYnkgdGhl IGNob2ljZSBvZiBicm93c2Vycw0KIGZvciBJbnRlcm5ldCwgSSB0aGluayB3aGF0IENocmlzdGVy L0FsYnJlY2h0IHN1Z2dlc3RlZCBpcyB0aGUgcmlnaHQgd2F5IHRvIG1vdmUgZm9yd2FyZDogcHJv dmlkZSBjbGFyaWZpY2F0aW9ucyBmb3IgdmFndWUgcG9pbnRzLiBJIGRvbuKAmXQgdW5kZXJzdGFu ZCB3aHkgbGFjayBvZiBjbGFyaXR5IGluIGV4aXN0aW5nIHNwZWNpZmljYXRpb25zIHNob3VsZCBj YXVzZSBpbXBvc2luZyByZXN0cmljdGlvbnMuIFRoaXMgd291bGQgYmUgYWtpbiB0byBkcm9wcGlu Zw0KIGEgZmVhdHVyZSBkdWUgdG8gYSBidWcuIEluIHRoaXMgY2FzZSwgdGhlIOKAnGJ1Z+KAnSBp cyBsYWNrIG9mIGNsYXJpdHkgaW4gbm9ybWF0aXZlIHNwZWNpZmljYXRpb25zIGFuZCBpdCBjYW4g YmUgYWRkcmVzc2VkIGJ5IGZ1cnRoZXIgc3BlY2lmaWNhdGlvbi48L3NwYW4+PG86cD48L286cD48 L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0iYmFja2dyb3Vu ZDp3aGl0ZSI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7 Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0QiPiZuYnNwOzwvc3Bhbj48bzpw PjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJi YWNrZ3JvdW5kOndoaXRlIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWls eTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RCI+VGhhbmtzLDwv c3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi IHN0eWxlPSJiYWNrZ3JvdW5kOndoaXRlIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtm b250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RCI+ VG9sZ2E8L3NwYW4+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIiBzdHlsZT0iYmFja2dyb3VuZDp3aGl0ZSI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTox MS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMx RjQ5N0QiPiZuYnNwOzwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdiBzdHlsZT0i Ym9yZGVyOm5vbmU7Ym9yZGVyLWxlZnQ6c29saWQgYmx1ZSAxLjVwdDtwYWRkaW5nOjBpbiAwaW4g MGluIDQuMHB0Ij4NCjxkaXY+DQo8ZGl2IHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItdG9wOnNv bGlkICNFMUUxRTEgMS4wcHQ7cGFkZGluZzozLjBwdCAwaW4gMGluIDBpbiI+DQo8ZGl2Pg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9ImJhY2tncm91bmQ6d2hpdGUiPjxiPjxzcGFuIHN0eWxl PSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1z ZXJpZiI+RnJvbTo8L3NwYW4+PC9iPjxzcGFuIGNsYXNzPSJhcHBsZS1jb252ZXJ0ZWQtc3BhY2Ui PjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkm cXVvdDssc2Fucy1zZXJpZiI+Jm5ic3A7PC9zcGFuPjwvc3Bhbj48c3BhbiBzdHlsZT0iZm9udC1z aXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWYiPlJv bWFuDQogU2hwb3VudCBbPGEgaHJlZj0ibWFpbHRvOnJvbWFuQHRlbHVyaXguY29tIj48c3BhbiBz dHlsZT0iY29sb3I6cHVycGxlIj5tYWlsdG86cm9tYW5AdGVsdXJpeC5jb208L3NwYW4+PC9hPl08 c3BhbiBjbGFzcz0iYXBwbGUtY29udmVydGVkLXNwYWNlIj4mbmJzcDs8L3NwYW4+PGJyPg0KPGI+ U2VudDo8L2I+PHNwYW4gY2xhc3M9ImFwcGxlLWNvbnZlcnRlZC1zcGFjZSI+Jm5ic3A7PC9zcGFu PldlZG5lc2RheSwgQXVndXN0IDA1LCAyMDE1IDEyOjI5IFBNPGJyPg0KPGI+VG86PC9iPjxzcGFu IGNsYXNzPSJhcHBsZS1jb252ZXJ0ZWQtc3BhY2UiPiZuYnNwOzwvc3Bhbj5SYXVzY2hlbmJhY2gs IFV3ZSAoTm9raWEgLSBERS9NdW5pY2gpICZsdDs8YSBocmVmPSJtYWlsdG86dXdlLnJhdXNjaGVu YmFjaEBub2tpYS5jb20iPjxzcGFuIHN0eWxlPSJjb2xvcjpwdXJwbGUiPnV3ZS5yYXVzY2hlbmJh Y2hAbm9raWEuY29tPC9zcGFuPjwvYT4mZ3Q7PGJyPg0KPGI+Q2M6PC9iPjxzcGFuIGNsYXNzPSJh cHBsZS1jb252ZXJ0ZWQtc3BhY2UiPiZuYnNwOzwvc3Bhbj5leHQgRXJpYyBSZXNjb3JsYSAmbHQ7 PGEgaHJlZj0ibWFpbHRvOmVrckBydGZtLmNvbSI+PHNwYW4gc3R5bGU9ImNvbG9yOnB1cnBsZSI+ ZWtyQHJ0Zm0uY29tPC9zcGFuPjwvYT4mZ3Q7OyBTY2h3YXJ6LCBBbGJyZWNodCAoQWxicmVjaHQp ICZsdDs8YSBocmVmPSJtYWlsdG86YWxicmVjaHQuc2Nod2FyekBhbGNhdGVsLWx1Y2VudC5jb20i PjxzcGFuIHN0eWxlPSJjb2xvcjpwdXJwbGUiPmFsYnJlY2h0LnNjaHdhcnpAYWxjYXRlbC1sdWNl bnQuY29tPC9zcGFuPjwvYT4mZ3Q7Ow0KIEFzdmVyZW4sIFRvbGdhICZsdDs8YSBocmVmPSJtYWls dG86dGFzdmVyZW5Ac29udXNuZXQuY29tIj48c3BhbiBzdHlsZT0iY29sb3I6cHVycGxlIj50YXN2 ZXJlbkBzb251c25ldC5jb208L3NwYW4+PC9hPiZndDs7IENocmlzdGVyIEhvbG1iZXJnICZsdDs8 YSBocmVmPSJtYWlsdG86Y2hyaXN0ZXIuaG9sbWJlcmdAZXJpY3Nzb24uY29tIj48c3BhbiBzdHls ZT0iY29sb3I6cHVycGxlIj5jaHJpc3Rlci5ob2xtYmVyZ0Blcmljc3Nvbi5jb208L3NwYW4+PC9h PiZndDs7IEJlcm5hcmQNCiBBYm9iYSAmbHQ7PGEgaHJlZj0ibWFpbHRvOmJlcm5hcmQuYWJvYmFA Z21haWwuY29tIj48c3BhbiBzdHlsZT0iY29sb3I6cHVycGxlIj5iZXJuYXJkLmFib2JhQGdtYWls LmNvbTwvc3Bhbj48L2E+Jmd0OzsgJmx0OzxhIGhyZWY9Im1haWx0bzpydGN3ZWJAaWV0Zi5vcmci PjxzcGFuIHN0eWxlPSJjb2xvcjpwdXJwbGUiPnJ0Y3dlYkBpZXRmLm9yZzwvc3Bhbj48L2E+Jmd0 OyAmbHQ7PGEgaHJlZj0ibWFpbHRvOnJ0Y3dlYkBpZXRmLm9yZyI+PHNwYW4gc3R5bGU9ImNvbG9y OnB1cnBsZSI+cnRjd2ViQGlldGYub3JnPC9zcGFuPjwvYT4mZ3Q7PGJyPg0KPGI+U3ViamVjdDo8 L2I+PHNwYW4gY2xhc3M9ImFwcGxlLWNvbnZlcnRlZC1zcGFjZSI+Jm5ic3A7PC9zcGFuPlJlOiBb cnRjd2ViXSBXaGF0IHRoZSBnYXRld2F5IGRyYWZ0IHNob3VsZCBzYXkgYWJvdXQgbXV4L25vbi1t dXg8L3NwYW4+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0K PHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9ImJhY2tncm91bmQ6d2hpdGUiPjxzcGFuIHN0eWxl PSJmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWYiPiZuYnNwOzwvc3Bh bj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJiYWNrZ3JvdW5kOndoaXRlIj48c3BhbiBzdHlsZT0i Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmIj5PbiBXZWQsIEF1ZyA1 LCAyMDE1IGF0IDQ6NDcgQU0sIFJhdXNjaGVuYmFjaCwgVXdlIChOb2tpYSAtIERFL011bmljaCkg Jmx0OzxhIGhyZWY9Im1haWx0bzp1d2UucmF1c2NoZW5iYWNoQG5va2lhLmNvbSIgdGFyZ2V0PSJf YmxhbmsiPjxzcGFuIHN0eWxlPSJjb2xvcjpwdXJwbGUiPnV3ZS5yYXVzY2hlbmJhY2hAbm9raWEu Y29tPC9zcGFuPjwvYT4mZ3Q7DQogd3JvdGU6PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+ DQo8YmxvY2txdW90ZSBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLWxlZnQ6c29saWQgI0NDQ0ND QyAxLjBwdDtwYWRkaW5nOjBpbiAwaW4gMGluIDYuMHB0O21hcmdpbi1sZWZ0OjQuOHB0O21hcmdp bi10b3A6NS4wcHQ7bWFyZ2luLXJpZ2h0OjBpbjttYXJnaW4tYm90dG9tOjUuMHB0Ij4NCjxkaXY+ DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJiYWNrZ3JvdW5kOndo aXRlIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtBcmlh bCZxdW90OyxzYW5zLXNlcmlmIj5NZWRpYSBnYXRld2F5IGltcGxlbWVudGF0aW9ucyBhY2NvcmRp bmcgdG8gM0dQUCBUUyAyMy4yMjg8L3NwYW4+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7 Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0Qi PiZuYnNwOzwvc3Bhbj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTom cXVvdDtBcmlhbCZxdW90OyxzYW5zLXNlcmlmIj5tYXkNCiBub3Qgc3VwcG9ydCBydGNwLW11eCwg YXMgcnRjcC1tdXggaXMgb3B0aW9uYWwgdGhlcmUuPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9k aXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJiYWNrZ3JvdW5k OndoaXRlIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtB cmlhbCZxdW90OyxzYW5zLXNlcmlmIj5TbyBpZiB3ZSBkcm9wIG5vbi1tdXggc3VwcG9ydCBmcm9t IHdlYiBicm93c2VycywgdGhvc2UgbWVkaWEgZ2F0ZXdheXMgdGhhdCBoYXZlIG5vdCBpbXBsZW1l bnRlZCBydGNwLW11eCB3aWxsIHN0b3AgaW50ZXJvcGVyYXRpbmcuJm5ic3A7PC9zcGFuPjxvOnA+ PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9ImJh Y2tncm91bmQ6d2hpdGUiPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1 b3Q7LHNhbnMtc2VyaWYiPiZuYnNwOzwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9k aXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9ibG9ja3F1b3RlPg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIiBzdHlsZT0iYmFja2dyb3VuZDp3aGl0ZSI+PHNwYW4gc3R5bGU9ImZvbnQt ZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZiI+Jm5ic3A7PC9zcGFuPjxvOnA+ PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05v cm1hbCIgc3R5bGU9ImJhY2tncm91bmQ6d2hpdGUiPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTom cXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWYiPkZpcnN0IG9mIGFsbCwgZG8geW91IGtub3cg b2YgYW55IFdlYlJUQyB0byBJTVMgZ2F0ZXdheXMgdGhhdCBkbyBub3QgaW1wbGVtZW50IHJ0Y3At bXV4IG9uIHRoZSBXZWJSVEMgc2lkZT8gSSBzdHJvbmdseSBzdXNwZWN0IHRoZXJlIGFyZSBub25l Ljwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdj4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJiYWNrZ3JvdW5kOndoaXRlIj48c3BhbiBzdHlsZT0i Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmIj4mbmJzcDs8L3NwYW4+ PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIiBzdHlsZT0iYmFja2dyb3VuZDp3aGl0ZSI+PHNwYW4gc3R5bGU9ImZvbnQtZmFt aWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZiI+U2Vjb25kLCB0aGUgb25seSByZWFz b25zIG5vdCB0byB1c2UgcnRjcC1tdXggdGhhdCBJIGNhbiB0aGluayBvZiBhcmUgdGhlIGZvbGxv d2luZzo8L3NwYW4+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxkaXY+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0iYmFja2dyb3VuZDp3aGl0ZSI+PHNwYW4gc3R5 bGU9ImZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZiI+Jm5ic3A7PC9z cGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xh c3M9Ik1zb05vcm1hbCIgc3R5bGU9ImJhY2tncm91bmQ6d2hpdGUiPjxzcGFuIHN0eWxlPSJmb250 LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWYiPjEuIFVzaW5nIGRpZmZlcmVu dCBRT1Mgc2V0dGluZ3MgZm9yIFJUQ1AgdnMgUlRQPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9k aXY+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9ImJh Y2tncm91bmQ6d2hpdGUiPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1 b3Q7LHNhbnMtc2VyaWYiPjIuIFNlbmRpbmcgUlRDUCB0byBhIGRpZmZlcmVudCBkZXZpY2UgZnJv bSBSVFA8L3NwYW4+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxkaXY+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0iYmFja2dyb3VuZDp3aGl0ZSI+PHNwYW4gc3R5 bGU9ImZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZiI+Jm5ic3A7PC9z cGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xh c3M9Ik1zb05vcm1hbCIgc3R5bGU9ImJhY2tncm91bmQ6d2hpdGUiPjxzcGFuIHN0eWxlPSJmb250 LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWYiPkkgZG8gbm90IHRoaW5rIHRo ZSBmaXJzdCB1c2UgY2FzZSB3YXJyYW50cyBtYWtpbmcgcnRjcC1tdXggb3B0aW9uYWwsIHNpbmNl LCBwcmFjdGljYWxseSBubyBvbmUgZG9lcyB0aGlzLjwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwv ZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJi YWNrZ3JvdW5kOndoaXRlIj48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZx dW90OyxzYW5zLXNlcmlmIj5TZWNvbmQgdXNlIGNhc2UgaXMgYWxzbyBmYWlybHkgbWFyZ2luYWwu IFBsdXMgaXQgY2FuIGJlIGhhbmRsZWQgYnkgdGhlIGdhdGV3YXkgd2hpY2ggY2FuIHNlbmQgUlRD UCB0byBvbmUgZGV2aWNlIGFuZCBSVFAgdG8gYW5vdGhlci48L3NwYW4+PG86cD48L286cD48L3A+ DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHls ZT0iYmFja2dyb3VuZDp3aGl0ZSI+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O0NhbGli cmkmcXVvdDssc2Fucy1zZXJpZiI+Jm5ic3A7PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+ DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9ImJhY2tn cm91bmQ6d2hpdGUiPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7 LHNhbnMtc2VyaWYiPlNvLCB1bmxlc3Mgc29tZW9uZSBjYW4gY29tZSB1cCB3aXRoIGEgdXNlIGNh c2Ugd2h5IFJUUCBhbmQgUlRDUCBzaG91bGQgdXNlIGRpZmZlcmVudCB0cmFuc3BvcnRzLCBJIHRo aW5rIHJ0Y3AtbXV4IHNob3VsZCBiZSBtYW5kYXRvcnkuPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0K PC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9 ImJhY2tncm91bmQ6d2hpdGUiPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtDYWxpYnJp JnF1b3Q7LHNhbnMtc2VyaWYiPiZuYnNwOzwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0K PC9kaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJiYWNrZ3Jv dW5kOndoaXRlIj48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90Oyxz YW5zLXNlcmlmIj5SZWdhcmRzLDwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+ DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJiYWNrZ3JvdW5kOndo aXRlIj48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNl cmlmIj5fX19fX19fX19fX19fXzwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+ DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJiYWNrZ3JvdW5kOndo aXRlIj48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNl cmlmIj5Sb21hbiBTaHBvdW50PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4N CjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0K PC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTo5LjBwdDtmb250LWZhbWlseTomcXVv dDtIZWx2ZXRpY2EmcXVvdDssc2Fucy1zZXJpZiI+X19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX188YnI+DQpydGN3ZWIgbWFpbGluZyBsaXN0PGJyPg0KPGEgaHJl Zj0ibWFpbHRvOnJ0Y3dlYkBpZXRmLm9yZyI+cnRjd2ViQGlldGYub3JnPC9hPjxicj4NCjxhIGhy ZWY9Imh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vcnRjd2ViIj5odHRwczov L3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL3J0Y3dlYjwvYT48L3NwYW4+PG86cD48L286 cD48L3A+DQo8L2Rpdj4NCjwvYmxvY2txdW90ZT4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4N CjwvZGl2Pg0KPC9ib2R5Pg0KPC9odG1sPg0K --_000_SN1PR0301MB1551852C42AFEB308672D524B2740SN1PR0301MB1551_-- From nobody Thu Aug 6 06:36:23 2015 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1F4911B2F79 for ; Thu, 6 Aug 2015 06:36:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.978 X-Spam-Level: X-Spam-Status: No, score=-1.978 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, 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 ME5ezz6ZmpQ8 for ; Thu, 6 Aug 2015 06:36:20 -0700 (PDT) Received: from mail-oi0-f41.google.com (mail-oi0-f41.google.com [209.85.218.41]) (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 70A1D1B2F89 for ; Thu, 6 Aug 2015 06:36:01 -0700 (PDT) Received: by oihn130 with SMTP id n130so39608937oih.2 for ; Thu, 06 Aug 2015 06:36:01 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=PkYkEnHt7lF6AuxXEN7rKon6kZVltKpL8neOf7QJMoQ=; b=hp9kw3iXm6ZP6cRsC6TAuRX8PvOpGnyApbLTzmMhm/uqf/w7O4XwwMvyMox9h7G2fr KY9JWJYr7DWUnR5uY1/SM0fYnLXN8jYkPoCEgwzMchLZg2nnyJMgzVknMLnu8J+YRvR5 toHgHMZw2M4zAW4mJUDtJ4E9vcry4A+z8dGjXRIsRAqCsUeZzioFFXtVnPjBpwqAt1Zt 9/BlaPJF1ErppAPHj6vX6uNwYmIEePWNwpGmFb097WCXXt/VoDvl676j7pDALdKSdJ3C 30grI9IFMlFOLUbM2Yb3a/gCygailbOCJB0d5on2Dd4u5ER1SbVByqG8+c0M6d5zRAwm ApFw== X-Gm-Message-State: ALoCoQmNXSJ8opnBZ7VRXczy9RTTDH4SivUKH4IEOBcMCndAMSzRzWiL3oaVltrc9nB4ZZ7SKjE+ X-Received: by 10.202.129.70 with SMTP id c67mr1492907oid.42.1438868160871; Thu, 06 Aug 2015 06:36:00 -0700 (PDT) Received: from mail-ob0-f177.google.com (mail-ob0-f177.google.com. [209.85.214.177]) by smtp.gmail.com with ESMTPSA id sx2sm3881986obc.0.2015.08.06.06.35.56 for (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 06 Aug 2015 06:35:57 -0700 (PDT) Received: by obbop1 with SMTP id op1so55714380obb.2 for ; Thu, 06 Aug 2015 06:35:56 -0700 (PDT) MIME-Version: 1.0 X-Received: by 10.60.78.230 with SMTP id e6mr1609742oex.24.1438868156469; Thu, 06 Aug 2015 06:35:56 -0700 (PDT) Received: by 10.76.83.167 with HTTP; Thu, 6 Aug 2015 06:35:56 -0700 (PDT) In-Reply-To: References: <20150805130607.20844.70680.idtracker@ietfa.amsl.com> <55C24293.5000603@cs.tcd.ie> <55C24C09.8020404@goodadvice.pages.de> <55C256C8.80606@jive.com> Date: Thu, 6 Aug 2015 06:35:56 -0700 Message-ID: From: Emil Ivov To: Justin Uberti Content-Type: multipart/alternative; boundary=089e0111b2a258a449051ca4990e Archived-At: Cc: "rtcweb@ietf.org" , "tram@ietf.org" Subject: Re: [rtcweb] [tram] TURN permissions for private ips X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 06 Aug 2015 13:36:22 -0000 --089e0111b2a258a449051ca4990e Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On Wednesday, August 5, 2015, Justin Uberti wrote: > > > On Wed, Aug 5, 2015 at 11:32 AM, Simon Perreault > wrote: > >> Le 2015-08-05 13:46, Philipp Hancke a =C3=A9crit : >> > If a peer sends candidates with IP addresses from the private space, >> > permissions for those are created at the TURN server. Potentially not >> > utilising transport encryption even. >> > >> > I doubt those candidates ever work, so from a privacy point of view it >> > seems that clients should not create those permissions in the first >> > place. And ICE should probably not try to create pairs. >> >> It's not up to the client to determine what addresses might not might >> not work for a given TURN server. There are lots of weird NAT >> configurations out there that play games with RFC1918 addresses and can >> easily trick clients into doing the wrong thing. >> > > I am somewhat sympathetic to that, but given that there is measurable > downside here - extra candidate pairs that take time to check - can you > supply a concrete example of where the client choosing not to pair a TURN > candidate with a RFC1918 address would cause a problem? > Isn't it enough to just have a route on the TURN server to a 1918 network? I don't know why someone would do this and what sort of DMZed configuration it would be but if they could then I don't think clients should try to make assumptions about the practicality of such a configuration. It is clearly much easier for the TURN server to check whether or not it has such a route and refuse to add the permission. Emil --=20 sent from my mobile --089e0111b2a258a449051ca4990e Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable

On Wednesday, August 5, 2015, Justin Uberti <juberti@google.com> wrote:


On Wed, Aug 5, 2015 at 11:32 AM, Simon Perreault <sperreault@jive.com> wro= te:
Le 2015-08-05 13:46, Philipp Hancke a= =C3=A9crit :
> If a peer sends candidates with IP addresses from the private space, > permissions for those are created at the TURN server. Potentially not<= br> > utilising transport encryption even.
>
> I doubt those candidates ever work, so from a privacy point of view it=
> seems that clients should not create those permissions in the first > place. And ICE should probably not try to create pairs.

It's not up to the client to determine what addresses might not might not work for a given TURN server. There are lots of weird NAT
configurations out there that play games with RFC1918 addresses and can
easily trick clients into doing the wrong thing.

<= /div>
I am somewhat sympathetic to that, but given that there is measur= able downside here - extra candidate pairs that take time to check - can yo= u supply a concrete example of where the client choosing not to pair a TURN= candidate with a RFC1918 address would cause a problem?
<= /div>

Isn't it enough to just have=C2= =A0a route on the TURN server to a 1918 network? I don't know why someo= ne would do this and what sort of DMZed configuration it would be=C2=A0but if they could then I don't think clients should try to mak= e assumptions about the practicality of such a configuration.
It is clearly much easier for the TURN server to check whether = or not it has such a route and refuse to add the permission.

=
Emil


--
sent from my mobile
--089e0111b2a258a449051ca4990e-- From nobody Thu Aug 6 06:42:43 2015 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3C5A71B2FD7 for ; Thu, 6 Aug 2015 06:42:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.601 X-Spam-Level: X-Spam-Status: No, score=-2.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NeouqHsO3u4M for ; Thu, 6 Aug 2015 06:42:40 -0700 (PDT) Received: from mail-oi0-f50.google.com (mail-oi0-f50.google.com [209.85.218.50]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BD7891B2FB6 for ; Thu, 6 Aug 2015 06:42:40 -0700 (PDT) Received: by oiev193 with SMTP id v193so8854625oie.3 for ; Thu, 06 Aug 2015 06:42:40 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:message-id:date:from:user-agent:mime-version:to :cc:subject:references:in-reply-to:content-type :content-transfer-encoding; bh=XfPE76xUEq7IvjovcIa9G07ErIndzGzOtWk4ymTwRY0=; b=TyNpaLehaUoaczE5ws4rUAnnBVmZ2ZMySZcBfzc1Yg3LkqD4N1qWp6x6X875p42+Nm AmZWZpS1+dWhJ8GkhP0mSFiSgYMytoOwjLoxWP1TbvQ3bWDlG8HZNDLYr1Dd7+7FKLfD P8oGQXk1kfMiuuoIVU/DQKeEjEkEKyIIibN7UxU/8tdEZm5jtzWMrtpecClRj0pg7Ae5 +WMeb7ajuKgPE2I5ycYNm8Fa5Roa60qBnb/QysB8fwaDoM8voU+4OxUAkYD0QxIVkD7U MIluGKLE4fsq0izDgIeOkEuT7poYU8BM0RDe8rUsoL0OCp1Vis6Ko50ysTsmK/ah+RlT BLeg== X-Gm-Message-State: ALoCoQl5IyPqHrutarKkGFIphXd89FPm1zGp27Ad88UtF24P7JMlUzEcqTac2lg+B1eHTfW2C7Ov X-Received: by 10.202.240.215 with SMTP id o206mr1499854oih.94.1438868560242; Thu, 06 Aug 2015 06:42:40 -0700 (PDT) Received: from [192.168.1.44] ([24.53.47.130]) by smtp.googlemail.com with ESMTPSA id i7sm3884218obe.8.2015.08.06.06.42.38 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 06 Aug 2015 06:42:39 -0700 (PDT) Message-ID: <55C3644D.8040903@jive.com> Date: Thu, 06 Aug 2015 09:42:37 -0400 From: Simon Perreault User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:31.0) Gecko/20100101 Thunderbird/31.7.0 MIME-Version: 1.0 To: "Hutton, Andrew" , tim panton , "Asveren, Tolga" References: <9F33F40F6F2CD847824537F3C4E37DDF1E826A00@MCHP04MSX.global-ad.net> In-Reply-To: <9F33F40F6F2CD847824537F3C4E37DDF1E826A00@MCHP04MSX.global-ad.net> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 8bit Archived-At: Cc: "" Subject: Re: [rtcweb] What the gateway draft should say about mux/non-mux X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 06 Aug 2015 13:42:42 -0000 Le 2015-08-06 09:30, Hutton, Andrew a crit : > If we had thought about this at the time we mandated DTLS-SRTP then we > would have mandated rtp-mux at the same time but unfortunately we didnt > but we can fix that now. To be clear, rtcp-mux is already mandatory. It's non-mux that needs to be made optional. https://tools.ietf.org/html/draft-ietf-rtcweb-rtp-usage-25#section-4.5 Text proposal: > --- text.old 2015-08-06 09:37:19.000000000 -0400 > +++ text.new 2015-08-06 09:40:03.000000000 -0400 > @@ -10,5 +10,5 @@ > Such RTP and RTCP multiplexing MUST be negotiated in the signalling > channel before it is used. If SDP is used for signalling, this > negotiation MUST use the attributes defined in [RFC5761]. For > - backwards compatibility, implementations are also REQUIRED to support > - RTP and RTCP sent on separate transport-layer flows. > + backwards compatibility, implementations MAY support RTP and RTCP > + sent on separate transport-layer flows. Simon From nobody Thu Aug 6 07:01:03 2015 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 72E731B3049 for ; Thu, 6 Aug 2015 07:01:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.61 X-Spam-Level: X-Spam-Status: No, score=-2.61 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TUacr1_iSGwM for ; Thu, 6 Aug 2015 07:00:56 -0700 (PDT) Received: from mx11.unify.com (mx11.unify.com [62.134.46.9]) by ietfa.amsl.com (Postfix) with ESMTP id 471DB1B3267 for ; Thu, 6 Aug 2015 07:00:42 -0700 (PDT) Received: from MCHP01HTC.global-ad.net (unknown [172.29.42.234]) by mx11.unify.com (Server) with ESMTP id 7F0D21EB848F; Thu, 6 Aug 2015 16:00:41 +0200 (CEST) Received: from MCHP04MSX.global-ad.net ([169.254.37.243]) by MCHP01HTC.global-ad.net ([172.29.42.234]) with mapi id 14.03.0248.002; Thu, 6 Aug 2015 16:00:41 +0200 From: "Hutton, Andrew" To: Simon Perreault , tim panton , "Asveren, Tolga" Thread-Topic: [rtcweb] What the gateway draft should say about mux/non-mux Thread-Index: AQHQ0EbjJarRmMWKQkuVevbl8oA2Mp3+9X1Q///j8YCAACZF0A== Date: Thu, 6 Aug 2015 14:00:40 +0000 Message-ID: <9F33F40F6F2CD847824537F3C4E37DDF1E826BC1@MCHP04MSX.global-ad.net> References: <9F33F40F6F2CD847824537F3C4E37DDF1E826A00@MCHP04MSX.global-ad.net> <55C3644D.8040903@jive.com> In-Reply-To: <55C3644D.8040903@jive.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [172.29.42.225] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Cc: "" Subject: Re: [rtcweb] What the gateway draft should say about mux/non-mux X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 06 Aug 2015 14:01:00 -0000 On: 06 August 2015 14:43 Simon Perreault Wrote: >=20 > To be clear, rtcp-mux is already mandatory. It's non-mux that needs to > be made optional. >=20 > https://tools.ietf.org/html/draft-ietf-rtcweb-rtp-usage-25#section-4.5 >=20 Agreed and that's what I meant to say sorry for not being clear. Andy From nobody Thu Aug 6 07:07:18 2015 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9D3801B360B for ; Thu, 6 Aug 2015 07:07:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IRmTIpcwJ65r for ; Thu, 6 Aug 2015 07:07:13 -0700 (PDT) Received: from smtp001.apm-internet.net (smtp001-out.apm-internet.net [85.119.248.222]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A5C611B360A for ; Thu, 6 Aug 2015 07:07:12 -0700 (PDT) Received: (qmail 35691 invoked from network); 6 Aug 2015 14:07:11 -0000 X-AV-Scan: clean X-APM-Authkey: 83769/0 8339 Received: from unknown (HELO zimbra003.verygoodemail.com) (85.119.248.218) by smtp001.apm-internet.net with SMTP; 6 Aug 2015 14:07:11 -0000 Received: from zimbra003.verygoodemail.com (localhost [127.0.0.1]) by zimbra003.verygoodemail.com (Postfix) with ESMTP id 09A4E18A10BD; Thu, 6 Aug 2015 15:07:08 +0100 (BST) Received: from [10.106.111.176] (unknown [66.71.232.48]) by zimbra003.verygoodemail.com (Postfix) with ESMTPSA id 3F14B18A0D12; Thu, 6 Aug 2015 15:07:07 +0100 (BST) Content-Type: multipart/alternative; boundary="Apple-Mail=_FBE937C5-6774-43AC-9FF4-6014018602FA" Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2102\)) From: tim panton In-Reply-To: <9F33F40F6F2CD847824537F3C4E37DDF1E826A00@MCHP04MSX.global-ad.net> Date: Thu, 6 Aug 2015 09:07:05 -0500 Message-Id: <7515AC50-14F3-43C4-B3D9-D785100FC9C5@phonefromhere.com> References: <9F33F40F6F2CD847824537F3C4E37DDF1E826A00@MCHP04MSX.global-ad.net> To: "Hutton, Andrew" X-Mailer: Apple Mail (2.2102) Archived-At: Cc: "" Subject: Re: [rtcweb] What the gateway draft should say about mux/non-mux X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 06 Aug 2015 14:07:17 -0000 --Apple-Mail=_FBE937C5-6774-43AC-9FF4-6014018602FA Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 > On 6 Aug 2015, at 08:30, Hutton, Andrew = wrote: >=20 > +1 to what Tim said. > =20 > I don=E2=80=99t think this discussion is really about gateways at all = it is surely about whether WebRTC browsers have to support non-mux and I = don=E2=80=99t really see any good reason why they need to. > =20 > If we had thought about this at the time we mandated DTLS-SRTP then we = would have mandated rtp-mux at the same time but unfortunately we = didn=E2=80=99t but we can fix that now. Sadly true, but the situation in a browser is manageable since you might = expect 10 peer connections, resulting=20 in a worst case of 60 UDP ports/DTLS sessions in use=20 (assuming voice+video+data unbundled and RTCP-non-mux vs the 10 needed). = We=20 also assume a relatively well endowed CPU - devoted largely to this = task. On the gateway you=E2=80=99d hope to have thousands of sessions and = presumably much less CPU/memory resource per channel. So while I think it is unfortunate that browsers can do non-mux, it = would be plain stupid to do that on a gateway. Do we=20 really want to encourage that ? T. > =20 > Andy > =20 > =20 > From: rtcweb [mailto:rtcweb-bounces@ietf.org] On Behalf Of tim panton > Sent: 06 August 2015 13:53 > To: Asveren, Tolga > Cc: > Subject: Re: [rtcweb] What the gateway draft should say about = mux/non-mux > =20 > So we are positing the existence of a webRTC gateway designed to = support thousands of calls which does ICE and DTLS but the > designer decided deliberately to double the number of ICE sessions = required and double the number of DTLS sessions (and key=20 > generation costs) so that they can run RTCP (over ICE and DTLS) on a = separate port. In my estimation that=E2=80=99s one poor decision > and should not be used as the basis of this (or any) standard.=20 > =20 > I=E2=80=99d rather not support rtcp-no-mux as I see zero advantages in = having it. (I know theoretically it might be possible to get > a RTCP packet through a congested net on a different port with a = separate diffserv setting but that just seems so contrived). > =20 > Tim. > =20 > =20 > On 6 Aug 2015, at 06:44, Asveren, Tolga > wrote: > =20 > These assumptions are not necessarily true in a universal sense (like = almost any other assumption about different deployment models). > =20 > Furthermore, and more importantly, there is nothing mandating WebRTC = endpoints to support non-rtcp-mux. It is a negotiated functionality. Any = entity can enforce rtcp-mux as a local policy.=20 > =20 > The issue with supporting non-rtcp-mux seems to be lack of clarity in = the relevant specifications. Fixing this =E2=80=93regardless of the = outcome of any other discussion- seems to be prudent IMHO. > =20 > Thanks, > Tolga > =20 > From: Wyss, Felix [mailto:Felix.Wyss@inin.com = ]=20 > Sent: Thursday, August 06, 2015 6:37 AM > To: Christer Holmberg >; Asveren, Tolga = >; Schwarz, = Albrecht (Albrecht) >; Roman Shpount = >; Rauschenbach, Uwe (Nokia = - DE/Munich) > > Cc: > > > Subject: Re: [rtcweb] What the gateway draft should say about = mux/non-mux > =20 > Why shouldn't the gateway be required to do the mux/demux? Making the = WebRTC endpoints a lot more complex just so the legacy interop might = potentially be a teeny-tiny bit easier makes no sense IMHO. Actually, = the gateway would not be able to do "end-to-end" pass-through anyway as = legacy equipment will either be unencrypted or use SDES (RFC#4568) for = key exchange. So the gateway will have to perform DTLS-SRTP to = SDES-SRTP transcryption--which already is way more hassle than RTP/RTCP = mux/demux. > =20 > --Felix > =20 > From: rtcweb > on behalf of Christer Holmberg = > > Sent: Thursday, August 6, 2015 05:51 > To: Asveren, Tolga; Schwarz, Albrecht (Albrecht); Roman Shpount; = Rauschenbach, Uwe (Nokia - DE/Munich) > Cc: > > Subject: Re: [rtcweb] What the gateway draft should say about = mux/non-mux > =20 > Hi, > =20 > No matter whether the gateway supports RTP/RTCP mux or not, there are = cases where the legacy network/endpoints will not use RTP/RTCP mux, so I = guess people then would want to be able to negotiate non-mux = =E2=80=9Cend-to-end=E2=80=9D, rather than having the gateway to = demux/mux RTP and RTCP. > =20 > Regards, > =20 > Christer > =20 > From: Asveren, Tolga [mailto:tasveren@sonusnet.com = ]=20 > Sent: 6. elokuuta 2015 12:18 > To: Schwarz, Albrecht (Albrecht); Roman Shpount; Rauschenbach, Uwe = (Nokia - DE/Munich) > Cc: ext Eric Rescorla; Christer Holmberg; Bernard Aboba; = > > Subject: Re: [rtcweb] What the gateway draft should say about = mux/non-mux > =20 > Why should we consider 3GPP the sole "owner/user" of the term/entity = WebRTC-GW? I think it has a much more general meaning and use in = practice. It can refer to many different types of elements which can be = deployed in many different environments, hence any attempt to define it = strictly/restrict its capabilities are futile IMHO. > =20 > Thanks, > Tolga > =20 > From: Schwarz, Albrecht (Albrecht) = > > Sent: Thursday, August 6, 2015 2:44 AM > To: Asveren, Tolga; Roman Shpount; Rauschenbach, Uwe (Nokia - = DE/Munich) > Cc: ext Eric Rescorla; Christer Holmberg; Bernard Aboba; = > > Subject: RE: [rtcweb] What the gateway draft should say about = mux/non-mux > =20 > The concerned 3GPP WebRTC gateway (3GPP 23.334/29.334) supports = already RTP/RTCP transport multiplexing (since 3GPP Release 12), i.e. = should not be the limiting factor in this discussion.=20 > For ones interested in the RTCP port allocation rules, see H.248.57: > = https://www.itu.int/rec/dologin_pub.asp?lang=3De&id=3DT-REC-H.248.57-20141= 0-I!!PDF-E&type=3Ditems = > Clause 7 describes RTP/RTCP transport multiplexing. ITU-T H.248.57 is = already supported by 3GPP 29.334. > =20 > The rationale behind the =E2=80=9Coptional tagging=E2=80=9D by 23.228 = is a third reason, beyond > >1. Using different QOS settings for RTCP vs RTP > >2. Sending RTCP to a different device from RTP > =20 > Don=E2=80=99t want to go in the 3GPP specific details, but it has = nothing to do with the 3GPP UE-embedded WebRTC client nor any = constraints by 3GPP WebRTC gateways. > =20 > Thus, a WebRTC gateway MUST support RTP/RTCP transport multiplexing = due to its purpose in interworking support. > =20 > Regards, > Albrecht > =20 > =20 > From: Asveren, Tolga [mailto:tasveren@sonusnet.com = ]=20 > Sent: Mittwoch, 5. August 2015 19:47 > To: Roman Shpount; Rauschenbach, Uwe (Nokia - DE/Munich) > Cc: ext Eric Rescorla; Schwarz, Albrecht (Albrecht); Christer = Holmberg; Bernard Aboba; > > Subject: RE: [rtcweb] What the gateway draft should say about = mux/non-mux > =20 > i- I humbly disagree that using different QoS RTCP/RTP, e.g. different = DiffServ values , should be dismissed. > ii- Let me also add another reason why no-rtcp-mux may be needed: = Implementation difficulties in certain GWs. > =20 > Considering that there is already a negotiation mechanism for rtcp-mux = support, that it can be de-facto mandated by the choice of browsers for = Internet, I think what Christer/Albrecht suggested is the right way to = move forward: provide clarifications for vague points. I don=E2=80=99t = understand why lack of clarity in existing specifications should cause = imposing restrictions. This would be akin to dropping a feature due to a = bug. In this case, the =E2=80=9Cbug=E2=80=9D is lack of clarity in = normative specifications and it can be addressed by further = specification. > =20 > Thanks, > Tolga > =20 > From: Roman Shpount [mailto:roman@telurix.com = ]=20 > Sent: Wednesday, August 05, 2015 12:29 PM > To: Rauschenbach, Uwe (Nokia - DE/Munich) > > Cc: ext Eric Rescorla >; Schwarz, = Albrecht (Albrecht) >; Asveren, Tolga = >; Christer = Holmberg >; Bernard Aboba = >; = > > > Subject: Re: [rtcweb] What the gateway draft should say about = mux/non-mux > =20 > On Wed, Aug 5, 2015 at 4:47 AM, Rauschenbach, Uwe (Nokia - DE/Munich) = > wrote: > Media gateway implementations according to 3GPP TS 23.228 may not = support rtcp-mux, as rtcp-mux is optional there. > So if we drop non-mux support from web browsers, those media gateways = that have not implemented rtcp-mux will stop interoperating.=20 > =20 > =20 > First of all, do you know of any WebRTC to IMS gateways that do not = implement rtcp-mux on the WebRTC side? I strongly suspect there are = none. > =20 > Second, the only reasons not to use rtcp-mux that I can think of are = the following: > =20 > 1. Using different QOS settings for RTCP vs RTP > 2. Sending RTCP to a different device from RTP > =20 > I do not think the first use case warrants making rtcp-mux optional, = since, practically no one does this. > Second use case is also fairly marginal. Plus it can be handled by the = gateway which can send RTCP to one device and RTP to another. > =20 > So, unless someone can come up with a use case why RTP and RTCP should = use different transports, I think rtcp-mux should be mandatory. > =20 > Regards, > ______________ > Roman Shpount > _______________________________________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/listinfo/rtcweb = > =20 --Apple-Mail=_FBE937C5-6774-43AC-9FF4-6014018602FA Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8
On 6 Aug 2015, at 08:30, Hutton, Andrew <andrew.hutton@unify.com> wrote:

+1 to what Tim said.

 

I don=E2=80=99t think this discussion = is really about gateways at all it is surely about whether WebRTC = browsers have to support non-mux and I don=E2=80=99t really see any good reason why they need to.

 

If we had thought about this at the = time we mandated DTLS-SRTP then we would have mandated rtp-mux at the = same time but unfortunately we didn=E2=80=99t but we can fix that now.


Sadly true, but the situation in a browser is = manageable since you might expect 10 peer connections, = resulting 
in a worst case of 60 UDP ports/DTLS sessions = in use 
(assuming voice+video+data unbundled and = RTCP-non-mux vs the 10 needed). We 
also assume a = relatively well endowed CPU - devoted largely to this = task.

On the gateway you=E2=80=99d = hope to have thousands of sessions and presumably much less CPU/memory = resource per channel.
So while I think it is unfortunate that = browsers can do non-mux, it would be plain stupid to do that on a = gateway. Do we 
really want to encourage that = ?

T.


 

Andy

 

 

From: rtcweb [mailto:rtcweb-bounces@ietf.org] On Behalf Of tim panton
Sent: 06 August 2015 13:53
To: Asveren, Tolga
Cc: <rtcweb@ietf.org>
Subject: Re: [rtcweb] What the gateway draft should = say about mux/non-mux

 

So we are positing the existence of a webRTC gateway = designed to support thousands of calls which does ICE and DTLS but = the

designer decided deliberately to = double the number of ICE sessions required and double the number of DTLS = sessions (and key 

generation costs) so that they = can run RTCP (over ICE and DTLS) on a separate port. In my estimation = that=E2=80=99s one poor decision

and should not be used as the = basis of this (or any) standard. 

 

I=E2=80=99d rather not support = rtcp-no-mux as I see zero advantages in having it. (I know theoretically = it might be possible to get

a RTCP packet through a congested = net on a different port with a separate diffserv setting but that just = seems so contrived).

 

Tim.

 

 

On 6 Aug 2015, at 06:44, Asveren, = Tolga <tasveren@sonusnet.com> wrote:

 

These assumptions are not necessarily = true in a universal sense (like almost any other assumption about = different deployment models).

 

Furthermore, and more importantly, = there is nothing mandating WebRTC endpoints to support non-rtcp-mux. It = is a negotiated functionality. Any entity can enforce rtcp-mux as a local policy. 

 

The issue with supporting non-rtcp-mux = seems to be lack of clarity in the relevant specifications. Fixing this = =E2=80=93regardless of the outcome of any other discussion- seems to be prudent IMHO.

 

Thanks,

Tolga

 

From: Wyss, Felix [mailto:Felix.Wyss@inin.com] 
Sent: Thursday, August 06, 2015 = 6:37 AM
To: Christer Holmberg <christer.holmberg@ericsson.com>; Asveren, Tolga <tasveren@sonusnet.com>; Schwarz, Albrecht (Albrecht) <albrecht.schwarz@alcatel-lucent.com>; Roman Shpount = <roman@telurix.com>; Rauschenbach, Uwe (Nokia - = DE/Munich) <uwe.rauschenbach@nokia.com>
Cc: <rtcweb@ietf.org> = <rtcweb@ietf.org>
Subject: Re: [rtcweb] What the = gateway draft should say about mux/non-mux

 

Why shouldn't the gateway be required to do the = mux/demux?  Making the WebRTC endpoints a lot more complex just so = the legacy interop might potentially be a teeny-tiny bit easier makes no sense IMHO.  Actually, the gateway would not = be able to do "end-to-end" pass-through anyway as legacy equipment will = either be unencrypted or use SDES (RFC#4568) for key exchange.  So = the gateway will have to perform DTLS-SRTP to SDES-SRTP transcryption--which already is way more hassle than RTP/RTCP = mux/demux.

 

--Felix

 

From: rtcweb <rtcweb-bounces@ietf.org> = on behalf of Christer Holmberg <christer.holmberg@ericsson.com>
Sent: Thursday, August 6, 2015 = 05:51
To: Asveren, Tolga; Schwarz, = Albrecht (Albrecht); Roman Shpount; Rauschenbach, Uwe (Nokia - = DE/Munich)
Cc: <rtcweb@ietf.org>
Subject: Re: [rtcweb] What the = gateway draft should say about mux/non-mux

 

Hi,

 

No matter whether the gateway supports = RTP/RTCP mux or not, there are cases where the legacy network/endpoints = will not use RTP/RTCP mux, so I guess people then would want to be able to negotiate non-mux = =E2=80=9Cend-to-end=E2=80=9D, rather than having the gateway to = demux/mux RTP and RTCP.

 

Regards,

=

 

Christer

=

 

From: Asveren, Tolga [mailto:tasveren@sonusnet.com] 
Sent: 6. elokuuta 2015 12:18
To: Schwarz, Albrecht = (Albrecht); Roman Shpount; Rauschenbach, Uwe (Nokia - DE/Munich)
Cc: ext Eric Rescorla; Christer = Holmberg; Bernard Aboba; <rtcweb@ietf.org>
Subject: Re: [rtcweb] What the = gateway draft should say about mux/non-mux

 

Why should we consider 3GPP the sole "owner/user" of the = term/entity WebRTC-GW? I think it has a much more general meaning and = use in practice. It can refer to many different types of elements which can be deployed in many different = environments, hence any attempt to define it strictly/restrict its = capabilities are futile IMHO.

 

Thanks,

Tolga

 

From: Schwarz, Albrecht (Albrecht) <albrecht.schwarz@alcatel-lucent.com>
Sent: Thursday, August 6, 2015 = 2:44 AM
To: Asveren, Tolga; Roman = Shpount; Rauschenbach, Uwe (Nokia - DE/Munich)
Cc: ext Eric Rescorla; Christer = Holmberg; Bernard Aboba; <rtcweb@ietf.org>
Subject: RE: [rtcweb] What the = gateway draft should say about mux/non-mux

 

The concerned 3GPP WebRTC gateway (3GPP 23.334/29.334) = supports already RTP/RTCP transport multiplexing (since 3GPP Release = 12), i.e. should not be the limiting factor in this discussion. 

For ones interested in the RTCP port allocation rules, see = H.248.57:

https://www.itu.int/rec/dologin_pub.asp?lang=3De&id=3DT-REC= -H.248.57-201410-I!!PDF-E&type=3Ditems

Clause 7 describes RTP/RTCP transport multiplexing. ITU-T = H.248.57 is already supported by 3GPP 29.334.

 

The rationale behind the =E2=80=9Coptional tagging=E2=80=9D = by 23.228 is a third reason, beyond

>1. Using different QOS settings for RTCP vs = RTP

>2. Sending RTCP to a different device from RTP

 

Don=E2=80=99t want to go in the 3GPP specific details, but it = has nothing to do with the 3GPP UE-embedded WebRTC client nor any = constraints by 3GPP WebRTC gateways.

 

Thus, a WebRTC gateway MUST support RTP/RTCP transport = multiplexing due to its purpose in interworking support.

 

Regards,

Albrecht

 

 

From: Asveren, Tolga [mailto:tasveren@sonusnet.com] 
Sent: Mittwoch, 5. August 2015 = 19:47
To: Roman Shpount; = Rauschenbach, Uwe (Nokia - DE/Munich)
Cc: ext Eric Rescorla; Schwarz, = Albrecht (Albrecht); Christer Holmberg; Bernard Aboba; <rtcweb@ietf.org>
Subject: RE: [rtcweb] What the = gateway draft should say about mux/non-mux

 

i- I humbly disagree that using = different QoS RTCP/RTP, e.g. different DiffServ values , should be = dismissed.

ii- Let me also add another reason why = no-rtcp-mux may be needed: Implementation difficulties in certain = GWs.

 

Considering that there is already a = negotiation mechanism for rtcp-mux support, that it can be de-facto = mandated by the choice of browsers for Internet, I think what Christer/Albrecht suggested is the right way = to move forward: provide clarifications for vague points. I don=E2=80=99t = understand why lack of clarity in existing specifications should cause = imposing restrictions. This would be akin to dropping a feature due to a bug. In this case, the =E2=80=9Cbug=E2=80=9D is lack = of clarity in normative specifications and it can be addressed by = further specification.

 

Thanks,

Tolga

 

From: Roman Shpount [mailto:roman@telurix.com] 
Sent: Wednesday, August 05, 2015 = 12:29 PM
To: Rauschenbach, Uwe (Nokia - = DE/Munich) <uwe.rauschenbach@nokia.com>
Cc: ext Eric Rescorla <ekr@rtfm.com>; Schwarz, Albrecht (Albrecht) = <albrecht.schwarz@alcatel-lucent.com>; Asveren, Tolga <tasveren@sonusnet.com>; Christer Holmberg = <christer.holmberg@ericsson.com>; Bernard Aboba <bernard.aboba@gmail.com>; = <rtcweb@ietf.org> <rtcweb@ietf.org>
Subject: Re: [rtcweb] What the = gateway draft should say about mux/non-mux

 

On Wed, Aug 5, 2015 at 4:47 AM, Rauschenbach, Uwe (Nokia - = DE/Munich) <uwe.rauschenbach@nokia.com> wrote:

Media gateway implementations according to 3GPP TS = 23.228 may not support rtcp-mux, as rtcp-mux is optional there.

So if we drop non-mux support from web browsers, those = media gateways that have not implemented rtcp-mux will stop = interoperating. 

 

 

First of all, do you know of any WebRTC to IMS gateways that = do not implement rtcp-mux on the WebRTC side? I strongly suspect there = are none.

 

Second, the only reasons not to use rtcp-mux that I can think = of are the following:

 

1. Using different QOS settings for RTCP vs RTP

2. Sending RTCP to a different device from RTP

 

I do not think the first use case warrants making rtcp-mux = optional, since, practically no one does this.

Second use case is also fairly marginal. Plus it can be = handled by the gateway which can send RTCP to one device and RTP to = another.

 

So, unless someone can come up with a use case why RTP and = RTCP should use different transports, I think rtcp-mux should be = mandatory.

 

Regards,

______________

Roman Shpount

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

 


= --Apple-Mail=_FBE937C5-6774-43AC-9FF4-6014018602FA-- From nobody Thu Aug 6 07:12:32 2015 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3BEE01A914E for ; Thu, 6 Aug 2015 07:12:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id L7qAVvQBuaXp for ; Thu, 6 Aug 2015 07:12:26 -0700 (PDT) Received: from na01-by2-obe.outbound.protection.outlook.com (mail-by2on0059.outbound.protection.outlook.com [207.46.100.59]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 363B11A9154 for ; Thu, 6 Aug 2015 07:12:25 -0700 (PDT) Received: from SN1PR0301MB1551.namprd03.prod.outlook.com (10.162.129.157) by SN1PR0301MB1549.namprd03.prod.outlook.com (10.162.129.155) with Microsoft SMTP Server (TLS) id 15.1.225.19; Thu, 6 Aug 2015 14:12:23 +0000 Received: from SN1PR0301MB1551.namprd03.prod.outlook.com ([10.162.129.157]) by SN1PR0301MB1551.namprd03.prod.outlook.com ([10.162.129.157]) with mapi id 15.01.0225.018; Thu, 6 Aug 2015 14:12:23 +0000 From: "Asveren, Tolga" To: tim panton , "Hutton, Andrew" Thread-Topic: [rtcweb] What the gateway draft should say about mux/non-mux Thread-Index: AQHQy8DcUgzWwtVCmk+8q67BCzjC45316kQQgAAD5oCAAACVsIAAAj2AgAPw2gCAAEFTAIAC/BgAgACAxgCAABQlsIAA2x8AgAAp4WeAAApBgIAADKQAgAARK8CAABTdgIAACn+AgAAKP4CAAACJUA== Date: Thu, 6 Aug 2015 14:12:23 +0000 Message-ID: References: <9F33F40F6F2CD847824537F3C4E37DDF1E826A00@MCHP04MSX.global-ad.net> <7515AC50-14F3-43C4-B3D9-D785100FC9C5@phonefromhere.com> In-Reply-To: <7515AC50-14F3-43C4-B3D9-D785100FC9C5@phonefromhere.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=tasveren@sonusnet.com; x-originating-ip: [50.182.164.80] x-microsoft-exchange-diagnostics: 1; SN1PR0301MB1549; 5:iZ06SeAdXTDZm2/BXz5jfGBNhRnzyKA9j8EzXMSGhDa1hcw8GWJz8dhs3SNoiRGo0lQxuwN7XXCRT6WxQKTBNapnJ2LUumjrKh9Z8vkylHW8TTj1IYYW0Tr91UEffb5vbSZqUQwWcl4Bj17fErw35A==; 24:Z4elridLT3GbL0Uk/+wwHoB60Q1YMc6quXX5qQnhwQjU2SOLtSwlHDax7nZq7y1l/EFAB38gPW2kxFa9HMSQUar9Xb4ltxVvfiKSIVNm41k=; 20:ZH+hgafawxW4QeYbyvBfgEX5DnH/BNT17wrx76HIzBvu0ayUB7aTV1Li/10WHbirSEIAAyFp5057In9POzwLsA== x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:SN1PR0301MB1549; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(108003899814671); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(601004)(5005006)(3002001); SRVR:SN1PR0301MB1549; BCL:0; PCL:0; RULEID:; SRVR:SN1PR0301MB1549; x-forefront-prvs: 06607E485E x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(164054003)(377454003)(199003)(189002)(24454002)(87936001)(2656002)(19609705001)(76576001)(76176999)(54356999)(10400500002)(50986999)(5001770100001)(86362001)(97736004)(4001540100001)(81156007)(106116001)(5001830100001)(5001860100001)(106356001)(105586002)(99286002)(5001960100002)(19580395003)(189998001)(122556002)(19300405004)(64706001)(19617315012)(66066001)(5003600100002)(93886004)(19580405001)(5002640100001)(77156002)(62966003)(16236675004)(33656002)(40100003)(92566002)(15975445007)(2900100001)(2950100001)(19625215002)(74316001)(77096005)(102836002)(68736005)(46102003)(101416001); DIR:OUT; SFP:1101; SCL:1; SRVR:SN1PR0301MB1549; H:SN1PR0301MB1551.namprd03.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; A:1; MX:1; LANG:en; received-spf: None (protection.outlook.com: sonusnet.com does not designate permitted sender hosts) Content-Type: multipart/alternative; boundary="_000_SN1PR0301MB1551A79D0AA05593987D8109B2740SN1PR0301MB1551_" MIME-Version: 1.0 X-OriginatorOrg: sonusnet.com X-MS-Exchange-CrossTenant-originalarrivaltime: 06 Aug 2015 14:12:23.0887 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 29a671dc-ed7e-4a54-b1e5-8da1eb495dc3 X-MS-Exchange-Transport-CrossTenantHeadersStamped: SN1PR0301MB1549 Archived-At: Cc: "" Subject: Re: [rtcweb] What the gateway draft should say about mux/non-mux X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 06 Aug 2015 14:12:31 -0000 --_000_SN1PR0301MB1551A79D0AA05593987D8109B2740SN1PR0301MB1551_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SSB0aGluayBpbXBsZW1lbnRlcnMgdGhlbXNlbHZlcyBjYW4gd2VpZ2ggb3V0IHRoZSBhZHZhbnRh Z2VzL2Rpc2FkdmFudGFnZWQvZGVwbG95bWVudCBtb2RlbHMgdGhleSBhcmUgdGFyZ2V0aW5nL2V0 Y+KApiBhbmQgZGVjaWRlIHdoYXQgdG8gc3VwcG9ydC9ub3QgdG8gc3VwcG9ydC4gSSBkb27igJl0 IHNlZSBhbnkgaXNzdWUgd2l0aCB0aGlzIGFzIGxvbmcgYXMgdGhlcmUgaXMgYSBuZWdvdGlhdGlv biBtZWNoYW5pc20gKHdoaWNoIHRoZXJlIGlzKS4gSSBkb27igJl0IHRoaW5rIHRoZSBhdmFpbGFi aWxpdHkgb2YgbmVnb3RpYXRpb24gaXMgZW5jb3VyYWdpbmcgcGVvcGxlIHRoaXMgb3IgdGhhdCB3 YXkuDQoNClRoYW5rcywNClRvbGdhDQoNCkZyb206IHRpbSBwYW50b24gW21haWx0bzp0aW1AcGhv bmVmcm9taGVyZS5jb21dDQpTZW50OiBUaHVyc2RheSwgQXVndXN0IDA2LCAyMDE1IDEwOjA3IEFN DQpUbzogSHV0dG9uLCBBbmRyZXcgPGFuZHJldy5odXR0b25AdW5pZnkuY29tPg0KQ2M6IEFzdmVy ZW4sIFRvbGdhIDx0YXN2ZXJlbkBzb251c25ldC5jb20+OyA8cnRjd2ViQGlldGYub3JnPiA8cnRj d2ViQGlldGYub3JnPg0KU3ViamVjdDogUmU6IFtydGN3ZWJdIFdoYXQgdGhlIGdhdGV3YXkgZHJh ZnQgc2hvdWxkIHNheSBhYm91dCBtdXgvbm9uLW11eA0KDQoNCk9uIDYgQXVnIDIwMTUsIGF0IDA4 OjMwLCBIdXR0b24sIEFuZHJldyA8YW5kcmV3Lmh1dHRvbkB1bmlmeS5jb208bWFpbHRvOmFuZHJl dy5odXR0b25AdW5pZnkuY29tPj4gd3JvdGU6DQoNCisxIHRvIHdoYXQgVGltIHNhaWQuDQoNCkkg ZG9u4oCZdCB0aGluayB0aGlzIGRpc2N1c3Npb24gaXMgcmVhbGx5IGFib3V0IGdhdGV3YXlzIGF0 IGFsbCBpdCBpcyBzdXJlbHkgYWJvdXQgd2hldGhlciBXZWJSVEMgYnJvd3NlcnMgaGF2ZSB0byBz dXBwb3J0IG5vbi1tdXggYW5kIEkgZG9u4oCZdCByZWFsbHkgc2VlIGFueSBnb29kIHJlYXNvbiB3 aHkgdGhleSBuZWVkIHRvLg0KDQpJZiB3ZSBoYWQgdGhvdWdodCBhYm91dCB0aGlzIGF0IHRoZSB0 aW1lIHdlIG1hbmRhdGVkIERUTFMtU1JUUCB0aGVuIHdlIHdvdWxkIGhhdmUgbWFuZGF0ZWQgcnRw LW11eCBhdCB0aGUgc2FtZSB0aW1lIGJ1dCB1bmZvcnR1bmF0ZWx5IHdlIGRpZG7igJl0IGJ1dCB3 ZSBjYW4gZml4IHRoYXQgbm93Lg0KDQpTYWRseSB0cnVlLCBidXQgdGhlIHNpdHVhdGlvbiBpbiBh IGJyb3dzZXIgaXMgbWFuYWdlYWJsZSBzaW5jZSB5b3UgbWlnaHQgZXhwZWN0IDEwIHBlZXIgY29u bmVjdGlvbnMsIHJlc3VsdGluZw0KaW4gYSB3b3JzdCBjYXNlIG9mIDYwIFVEUCBwb3J0cy9EVExT IHNlc3Npb25zIGluIHVzZQ0KKGFzc3VtaW5nIHZvaWNlK3ZpZGVvK2RhdGEgdW5idW5kbGVkIGFu ZCBSVENQLW5vbi1tdXggdnMgdGhlIDEwIG5lZWRlZCkuIFdlDQphbHNvIGFzc3VtZSBhIHJlbGF0 aXZlbHkgd2VsbCBlbmRvd2VkIENQVSAtIGRldm90ZWQgbGFyZ2VseSB0byB0aGlzIHRhc2suDQoN Ck9uIHRoZSBnYXRld2F5IHlvdeKAmWQgaG9wZSB0byBoYXZlIHRob3VzYW5kcyBvZiBzZXNzaW9u cyBhbmQgcHJlc3VtYWJseSBtdWNoIGxlc3MgQ1BVL21lbW9yeSByZXNvdXJjZSBwZXIgY2hhbm5l bC4NClNvIHdoaWxlIEkgdGhpbmsgaXQgaXMgdW5mb3J0dW5hdGUgdGhhdCBicm93c2VycyBjYW4g ZG8gbm9uLW11eCwgaXQgd291bGQgYmUgcGxhaW4gc3R1cGlkIHRvIGRvIHRoYXQgb24gYSBnYXRl d2F5LiBEbyB3ZQ0KcmVhbGx5IHdhbnQgdG8gZW5jb3VyYWdlIHRoYXQgPw0KDQpULg0KDQoNCg0K DQpBbmR5DQoNCg0KRnJvbTogcnRjd2ViIFttYWlsdG86cnRjd2ViLWJvdW5jZXNAaWV0Zi5vcmdd IE9uIEJlaGFsZiBPZiB0aW0gcGFudG9uDQpTZW50OiAwNiBBdWd1c3QgMjAxNSAxMzo1Mw0KVG86 IEFzdmVyZW4sIFRvbGdhDQpDYzogPHJ0Y3dlYkBpZXRmLm9yZzxtYWlsdG86cnRjd2ViQGlldGYu b3JnPj4NClN1YmplY3Q6IFJlOiBbcnRjd2ViXSBXaGF0IHRoZSBnYXRld2F5IGRyYWZ0IHNob3Vs ZCBzYXkgYWJvdXQgbXV4L25vbi1tdXgNCg0KU28gd2UgYXJlIHBvc2l0aW5nIHRoZSBleGlzdGVu Y2Ugb2YgYSB3ZWJSVEMgZ2F0ZXdheSBkZXNpZ25lZCB0byBzdXBwb3J0IHRob3VzYW5kcyBvZiBj YWxscyB3aGljaCBkb2VzIElDRSBhbmQgRFRMUyBidXQgdGhlDQpkZXNpZ25lciBkZWNpZGVkIGRl bGliZXJhdGVseSB0byBkb3VibGUgdGhlIG51bWJlciBvZiBJQ0Ugc2Vzc2lvbnMgcmVxdWlyZWQg YW5kIGRvdWJsZSB0aGUgbnVtYmVyIG9mIERUTFMgc2Vzc2lvbnMgKGFuZCBrZXkNCmdlbmVyYXRp b24gY29zdHMpIHNvIHRoYXQgdGhleSBjYW4gcnVuIFJUQ1AgKG92ZXIgSUNFIGFuZCBEVExTKSBv biBhIHNlcGFyYXRlIHBvcnQuIEluIG15IGVzdGltYXRpb24gdGhhdOKAmXMgb25lIHBvb3IgZGVj aXNpb24NCmFuZCBzaG91bGQgbm90IGJlIHVzZWQgYXMgdGhlIGJhc2lzIG9mIHRoaXMgKG9yIGFu eSkgc3RhbmRhcmQuDQoNCknigJlkIHJhdGhlciBub3Qgc3VwcG9ydCBydGNwLW5vLW11eCBhcyBJ IHNlZSB6ZXJvIGFkdmFudGFnZXMgaW4gaGF2aW5nIGl0LiAoSSBrbm93IHRoZW9yZXRpY2FsbHkg aXQgbWlnaHQgYmUgcG9zc2libGUgdG8gZ2V0DQphIFJUQ1AgcGFja2V0IHRocm91Z2ggYSBjb25n ZXN0ZWQgbmV0IG9uIGEgZGlmZmVyZW50IHBvcnQgd2l0aCBhIHNlcGFyYXRlIGRpZmZzZXJ2IHNl dHRpbmcgYnV0IHRoYXQganVzdCBzZWVtcyBzbyBjb250cml2ZWQpLg0KDQpUaW0uDQoNCg0KT24g NiBBdWcgMjAxNSwgYXQgMDY6NDQsIEFzdmVyZW4sIFRvbGdhIDx0YXN2ZXJlbkBzb251c25ldC5j b208bWFpbHRvOnRhc3ZlcmVuQHNvbnVzbmV0LmNvbT4+IHdyb3RlOg0KDQpUaGVzZSBhc3N1bXB0 aW9ucyBhcmUgbm90IG5lY2Vzc2FyaWx5IHRydWUgaW4gYSB1bml2ZXJzYWwgc2Vuc2UgKGxpa2Ug YWxtb3N0IGFueSBvdGhlciBhc3N1bXB0aW9uIGFib3V0IGRpZmZlcmVudCBkZXBsb3ltZW50IG1v ZGVscykuDQoNCkZ1cnRoZXJtb3JlLCBhbmQgbW9yZSBpbXBvcnRhbnRseSwgdGhlcmUgaXMgbm90 aGluZyBtYW5kYXRpbmcgV2ViUlRDIGVuZHBvaW50cyB0byBzdXBwb3J0IG5vbi1ydGNwLW11eC4g SXQgaXMgYSBuZWdvdGlhdGVkIGZ1bmN0aW9uYWxpdHkuIEFueSBlbnRpdHkgY2FuIGVuZm9yY2Ug cnRjcC1tdXggYXMgYSBsb2NhbCBwb2xpY3kuDQoNClRoZSBpc3N1ZSB3aXRoIHN1cHBvcnRpbmcg bm9uLXJ0Y3AtbXV4IHNlZW1zIHRvIGJlIGxhY2sgb2YgY2xhcml0eSBpbiB0aGUgcmVsZXZhbnQg c3BlY2lmaWNhdGlvbnMuIEZpeGluZyB0aGlzIOKAk3JlZ2FyZGxlc3Mgb2YgdGhlIG91dGNvbWUg b2YgYW55IG90aGVyIGRpc2N1c3Npb24tIHNlZW1zIHRvIGJlIHBydWRlbnQgSU1ITy4NCg0KVGhh bmtzLA0KVG9sZ2ENCg0KRnJvbTogV3lzcywgRmVsaXggW21haWx0bzpGZWxpeC5XeXNzQGluaW4u Y29tXQ0KU2VudDogVGh1cnNkYXksIEF1Z3VzdCAwNiwgMjAxNSA2OjM3IEFNDQpUbzogQ2hyaXN0 ZXIgSG9sbWJlcmcgPGNocmlzdGVyLmhvbG1iZXJnQGVyaWNzc29uLmNvbTxtYWlsdG86Y2hyaXN0 ZXIuaG9sbWJlcmdAZXJpY3Nzb24uY29tPj47IEFzdmVyZW4sIFRvbGdhIDx0YXN2ZXJlbkBzb251 c25ldC5jb208bWFpbHRvOnRhc3ZlcmVuQHNvbnVzbmV0LmNvbT4+OyBTY2h3YXJ6LCBBbGJyZWNo dCAoQWxicmVjaHQpIDxhbGJyZWNodC5zY2h3YXJ6QGFsY2F0ZWwtbHVjZW50LmNvbTxtYWlsdG86 YWxicmVjaHQuc2Nod2FyekBhbGNhdGVsLWx1Y2VudC5jb20+PjsgUm9tYW4gU2hwb3VudCA8cm9t YW5AdGVsdXJpeC5jb208bWFpbHRvOnJvbWFuQHRlbHVyaXguY29tPj47IFJhdXNjaGVuYmFjaCwg VXdlIChOb2tpYSAtIERFL011bmljaCkgPHV3ZS5yYXVzY2hlbmJhY2hAbm9raWEuY29tPG1haWx0 bzp1d2UucmF1c2NoZW5iYWNoQG5va2lhLmNvbT4+DQpDYzogPHJ0Y3dlYkBpZXRmLm9yZzxtYWls dG86cnRjd2ViQGlldGYub3JnPj4gPHJ0Y3dlYkBpZXRmLm9yZzxtYWlsdG86cnRjd2ViQGlldGYu b3JnPj4NClN1YmplY3Q6IFJlOiBbcnRjd2ViXSBXaGF0IHRoZSBnYXRld2F5IGRyYWZ0IHNob3Vs ZCBzYXkgYWJvdXQgbXV4L25vbi1tdXgNCg0KV2h5IHNob3VsZG4ndCB0aGUgZ2F0ZXdheSBiZSBy ZXF1aXJlZCB0byBkbyB0aGUgbXV4L2RlbXV4PyAgTWFraW5nIHRoZSBXZWJSVEMgZW5kcG9pbnRz IGEgbG90IG1vcmUgY29tcGxleCBqdXN0IHNvIHRoZSBsZWdhY3kgaW50ZXJvcCBtaWdodCBwb3Rl bnRpYWxseSBiZSBhIHRlZW55LXRpbnkgYml0IGVhc2llciBtYWtlcyBubyBzZW5zZSBJTUhPLiAg QWN0dWFsbHksIHRoZSBnYXRld2F5IHdvdWxkIG5vdCBiZSBhYmxlIHRvIGRvICJlbmQtdG8tZW5k IiBwYXNzLXRocm91Z2ggYW55d2F5IGFzIGxlZ2FjeSBlcXVpcG1lbnQgd2lsbCBlaXRoZXIgYmUg dW5lbmNyeXB0ZWQgb3IgdXNlIFNERVMgKFJGQyM0NTY4KSBmb3Iga2V5IGV4Y2hhbmdlLiAgU28g dGhlIGdhdGV3YXkgd2lsbCBoYXZlIHRvIHBlcmZvcm0gRFRMUy1TUlRQIHRvIFNERVMtU1JUUCB0 cmFuc2NyeXB0aW9uLS13aGljaCBhbHJlYWR5IGlzIHdheSBtb3JlIGhhc3NsZSB0aGFuIFJUUC9S VENQIG11eC9kZW11eC4NCg0KLS1GZWxpeA0KDQpfX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fXw0KRnJvbTogcnRjd2ViIDxydGN3ZWItYm91bmNlc0BpZXRmLm9yZzxtYWlsdG86cnRjd2Vi LWJvdW5jZXNAaWV0Zi5vcmc+PiBvbiBiZWhhbGYgb2YgQ2hyaXN0ZXIgSG9sbWJlcmcgPGNocmlz dGVyLmhvbG1iZXJnQGVyaWNzc29uLmNvbTxtYWlsdG86Y2hyaXN0ZXIuaG9sbWJlcmdAZXJpY3Nz b24uY29tPj4NClNlbnQ6IFRodXJzZGF5LCBBdWd1c3QgNiwgMjAxNSAwNTo1MQ0KVG86IEFzdmVy ZW4sIFRvbGdhOyBTY2h3YXJ6LCBBbGJyZWNodCAoQWxicmVjaHQpOyBSb21hbiBTaHBvdW50OyBS YXVzY2hlbmJhY2gsIFV3ZSAoTm9raWEgLSBERS9NdW5pY2gpDQpDYzogPHJ0Y3dlYkBpZXRmLm9y ZzxtYWlsdG86cnRjd2ViQGlldGYub3JnPj4NClN1YmplY3Q6IFJlOiBbcnRjd2ViXSBXaGF0IHRo ZSBnYXRld2F5IGRyYWZ0IHNob3VsZCBzYXkgYWJvdXQgbXV4L25vbi1tdXgNCg0KSGksDQoNCk5v IG1hdHRlciB3aGV0aGVyIHRoZSBnYXRld2F5IHN1cHBvcnRzIFJUUC9SVENQIG11eCBvciBub3Qs IHRoZXJlIGFyZSBjYXNlcyB3aGVyZSB0aGUgbGVnYWN5IG5ldHdvcmsvZW5kcG9pbnRzIHdpbGwg bm90IHVzZSBSVFAvUlRDUCBtdXgsIHNvIEkgZ3Vlc3MgcGVvcGxlIHRoZW4gd291bGQgd2FudCB0 byBiZSBhYmxlIHRvIG5lZ290aWF0ZSBub24tbXV4IOKAnGVuZC10by1lbmTigJ0sIHJhdGhlciB0 aGFuIGhhdmluZyB0aGUgZ2F0ZXdheSB0byBkZW11eC9tdXggUlRQIGFuZCBSVENQLg0KDQpSZWdh cmRzLA0KDQpDaHJpc3Rlcg0KDQpGcm9tOiBBc3ZlcmVuLCBUb2xnYSBbbWFpbHRvOnRhc3ZlcmVu QHNvbnVzbmV0LmNvbV0NClNlbnQ6IDYuIGVsb2t1dXRhIDIwMTUgMTI6MTgNClRvOiBTY2h3YXJ6 LCBBbGJyZWNodCAoQWxicmVjaHQpOyBSb21hbiBTaHBvdW50OyBSYXVzY2hlbmJhY2gsIFV3ZSAo Tm9raWEgLSBERS9NdW5pY2gpDQpDYzogZXh0IEVyaWMgUmVzY29ybGE7IENocmlzdGVyIEhvbG1i ZXJnOyBCZXJuYXJkIEFib2JhOyA8cnRjd2ViQGlldGYub3JnPG1haWx0bzpydGN3ZWJAaWV0Zi5v cmc+Pg0KU3ViamVjdDogUmU6IFtydGN3ZWJdIFdoYXQgdGhlIGdhdGV3YXkgZHJhZnQgc2hvdWxk IHNheSBhYm91dCBtdXgvbm9uLW11eA0KDQpXaHkgc2hvdWxkIHdlIGNvbnNpZGVyIDNHUFAgdGhl IHNvbGUgIm93bmVyL3VzZXIiIG9mIHRoZSB0ZXJtL2VudGl0eSBXZWJSVEMtR1c/IEkgdGhpbmsg aXQgaGFzIGEgbXVjaCBtb3JlIGdlbmVyYWwgbWVhbmluZyBhbmQgdXNlIGluIHByYWN0aWNlLiBJ dCBjYW4gcmVmZXIgdG8gbWFueSBkaWZmZXJlbnQgdHlwZXMgb2YgZWxlbWVudHMgd2hpY2ggY2Fu IGJlIGRlcGxveWVkIGluIG1hbnkgZGlmZmVyZW50IGVudmlyb25tZW50cywgaGVuY2UgYW55IGF0 dGVtcHQgdG8gZGVmaW5lIGl0IHN0cmljdGx5L3Jlc3RyaWN0IGl0cyBjYXBhYmlsaXRpZXMgYXJl IGZ1dGlsZSBJTUhPLg0KDQpUaGFua3MsDQpUb2xnYQ0KDQpfX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fXw0KRnJvbTogU2Nod2FyeiwgQWxicmVjaHQgKEFsYnJlY2h0KSA8YWxicmVjaHQu c2Nod2FyekBhbGNhdGVsLWx1Y2VudC5jb208bWFpbHRvOmFsYnJlY2h0LnNjaHdhcnpAYWxjYXRl bC1sdWNlbnQuY29tPj4NClNlbnQ6IFRodXJzZGF5LCBBdWd1c3QgNiwgMjAxNSAyOjQ0IEFNDQpU bzogQXN2ZXJlbiwgVG9sZ2E7IFJvbWFuIFNocG91bnQ7IFJhdXNjaGVuYmFjaCwgVXdlIChOb2tp YSAtIERFL011bmljaCkNCkNjOiBleHQgRXJpYyBSZXNjb3JsYTsgQ2hyaXN0ZXIgSG9sbWJlcmc7 IEJlcm5hcmQgQWJvYmE7IDxydGN3ZWJAaWV0Zi5vcmc8bWFpbHRvOnJ0Y3dlYkBpZXRmLm9yZz4+ DQpTdWJqZWN0OiBSRTogW3J0Y3dlYl0gV2hhdCB0aGUgZ2F0ZXdheSBkcmFmdCBzaG91bGQgc2F5 IGFib3V0IG11eC9ub24tbXV4DQoNClRoZSBjb25jZXJuZWQgM0dQUCBXZWJSVEMgZ2F0ZXdheSAo M0dQUCAyMy4zMzQvMjkuMzM0KSBzdXBwb3J0cyBhbHJlYWR5IFJUUC9SVENQIHRyYW5zcG9ydCBt dWx0aXBsZXhpbmcgKHNpbmNlIDNHUFAgUmVsZWFzZSAxMiksIGkuZS4gc2hvdWxkIG5vdCBiZSB0 aGUgbGltaXRpbmcgZmFjdG9yIGluIHRoaXMgZGlzY3Vzc2lvbi4NCkZvciBvbmVzIGludGVyZXN0 ZWQgaW4gdGhlIFJUQ1AgcG9ydCBhbGxvY2F0aW9uIHJ1bGVzLCBzZWUgSC4yNDguNTc6DQpodHRw czovL3d3dy5pdHUuaW50L3JlYy9kb2xvZ2luX3B1Yi5hc3A/bGFuZz1lJmlkPVQtUkVDLUguMjQ4 LjU3LTIwMTQxMC1JISFQREYtRSZ0eXBlPWl0ZW1zDQpDbGF1c2UgNyBkZXNjcmliZXMgUlRQL1JU Q1AgdHJhbnNwb3J0IG11bHRpcGxleGluZy4gSVRVLVQgSC4yNDguNTcgaXMgYWxyZWFkeSBzdXBw b3J0ZWQgYnkgM0dQUCAyOS4zMzQuDQoNClRoZSByYXRpb25hbGUgYmVoaW5kIHRoZSDigJxvcHRp b25hbCB0YWdnaW5n4oCdIGJ5IDIzLjIyOCBpcyBhIHRoaXJkIHJlYXNvbiwgYmV5b25kDQo+MS4g VXNpbmcgZGlmZmVyZW50IFFPUyBzZXR0aW5ncyBmb3IgUlRDUCB2cyBSVFANCj4yLiBTZW5kaW5n IFJUQ1AgdG8gYSBkaWZmZXJlbnQgZGV2aWNlIGZyb20gUlRQDQoNCkRvbuKAmXQgd2FudCB0byBn byBpbiB0aGUgM0dQUCBzcGVjaWZpYyBkZXRhaWxzLCBidXQgaXQgaGFzIG5vdGhpbmcgdG8gZG8g d2l0aCB0aGUgM0dQUCBVRS1lbWJlZGRlZCBXZWJSVEMgY2xpZW50IG5vciBhbnkgY29uc3RyYWlu dHMgYnkgM0dQUCBXZWJSVEMgZ2F0ZXdheXMuDQoNClRodXMsIGEgV2ViUlRDIGdhdGV3YXkgTVVT VCBzdXBwb3J0IFJUUC9SVENQIHRyYW5zcG9ydCBtdWx0aXBsZXhpbmcgZHVlIHRvIGl0cyBwdXJw b3NlIGluIGludGVyd29ya2luZyBzdXBwb3J0Lg0KDQpSZWdhcmRzLA0KQWxicmVjaHQNCg0KDQpG cm9tOiBBc3ZlcmVuLCBUb2xnYSBbbWFpbHRvOnRhc3ZlcmVuQHNvbnVzbmV0LmNvbV0NClNlbnQ6 IE1pdHR3b2NoLCA1LiBBdWd1c3QgMjAxNSAxOTo0Nw0KVG86IFJvbWFuIFNocG91bnQ7IFJhdXNj aGVuYmFjaCwgVXdlIChOb2tpYSAtIERFL011bmljaCkNCkNjOiBleHQgRXJpYyBSZXNjb3JsYTsg U2Nod2FyeiwgQWxicmVjaHQgKEFsYnJlY2h0KTsgQ2hyaXN0ZXIgSG9sbWJlcmc7IEJlcm5hcmQg QWJvYmE7IDxydGN3ZWJAaWV0Zi5vcmc8bWFpbHRvOnJ0Y3dlYkBpZXRmLm9yZz4+DQpTdWJqZWN0 OiBSRTogW3J0Y3dlYl0gV2hhdCB0aGUgZ2F0ZXdheSBkcmFmdCBzaG91bGQgc2F5IGFib3V0IG11 eC9ub24tbXV4DQoNCmktIEkgaHVtYmx5IGRpc2FncmVlIHRoYXQgdXNpbmcgZGlmZmVyZW50IFFv UyBSVENQL1JUUCwgZS5nLiBkaWZmZXJlbnQgRGlmZlNlcnYgdmFsdWVzICwgc2hvdWxkIGJlIGRp c21pc3NlZC4NCmlpLSBMZXQgbWUgYWxzbyBhZGQgYW5vdGhlciByZWFzb24gd2h5IG5vLXJ0Y3At bXV4IG1heSBiZSBuZWVkZWQ6IEltcGxlbWVudGF0aW9uIGRpZmZpY3VsdGllcyBpbiBjZXJ0YWlu IEdXcy4NCg0KQ29uc2lkZXJpbmcgdGhhdCB0aGVyZSBpcyBhbHJlYWR5IGEgbmVnb3RpYXRpb24g bWVjaGFuaXNtIGZvciBydGNwLW11eCBzdXBwb3J0LCB0aGF0IGl0IGNhbiBiZSBkZS1mYWN0byBt YW5kYXRlZCBieSB0aGUgY2hvaWNlIG9mIGJyb3dzZXJzIGZvciBJbnRlcm5ldCwgSSB0aGluayB3 aGF0IENocmlzdGVyL0FsYnJlY2h0IHN1Z2dlc3RlZCBpcyB0aGUgcmlnaHQgd2F5IHRvIG1vdmUg Zm9yd2FyZDogcHJvdmlkZSBjbGFyaWZpY2F0aW9ucyBmb3IgdmFndWUgcG9pbnRzLiBJIGRvbuKA mXQgdW5kZXJzdGFuZCB3aHkgbGFjayBvZiBjbGFyaXR5IGluIGV4aXN0aW5nIHNwZWNpZmljYXRp b25zIHNob3VsZCBjYXVzZSBpbXBvc2luZyByZXN0cmljdGlvbnMuIFRoaXMgd291bGQgYmUgYWtp biB0byBkcm9wcGluZyBhIGZlYXR1cmUgZHVlIHRvIGEgYnVnLiBJbiB0aGlzIGNhc2UsIHRoZSDi gJxidWfigJ0gaXMgbGFjayBvZiBjbGFyaXR5IGluIG5vcm1hdGl2ZSBzcGVjaWZpY2F0aW9ucyBh bmQgaXQgY2FuIGJlIGFkZHJlc3NlZCBieSBmdXJ0aGVyIHNwZWNpZmljYXRpb24uDQoNClRoYW5r cywNClRvbGdhDQoNCkZyb206IFJvbWFuIFNocG91bnQgW21haWx0bzpyb21hbkB0ZWx1cml4LmNv bV0NClNlbnQ6IFdlZG5lc2RheSwgQXVndXN0IDA1LCAyMDE1IDEyOjI5IFBNDQpUbzogUmF1c2No ZW5iYWNoLCBVd2UgKE5va2lhIC0gREUvTXVuaWNoKSA8dXdlLnJhdXNjaGVuYmFjaEBub2tpYS5j b208bWFpbHRvOnV3ZS5yYXVzY2hlbmJhY2hAbm9raWEuY29tPj4NCkNjOiBleHQgRXJpYyBSZXNj b3JsYSA8ZWtyQHJ0Zm0uY29tPG1haWx0bzpla3JAcnRmbS5jb20+PjsgU2Nod2FyeiwgQWxicmVj aHQgKEFsYnJlY2h0KSA8YWxicmVjaHQuc2Nod2FyekBhbGNhdGVsLWx1Y2VudC5jb208bWFpbHRv OmFsYnJlY2h0LnNjaHdhcnpAYWxjYXRlbC1sdWNlbnQuY29tPj47IEFzdmVyZW4sIFRvbGdhIDx0 YXN2ZXJlbkBzb251c25ldC5jb208bWFpbHRvOnRhc3ZlcmVuQHNvbnVzbmV0LmNvbT4+OyBDaHJp c3RlciBIb2xtYmVyZyA8Y2hyaXN0ZXIuaG9sbWJlcmdAZXJpY3Nzb24uY29tPG1haWx0bzpjaHJp c3Rlci5ob2xtYmVyZ0Blcmljc3Nvbi5jb20+PjsgQmVybmFyZCBBYm9iYSA8YmVybmFyZC5hYm9i YUBnbWFpbC5jb208bWFpbHRvOmJlcm5hcmQuYWJvYmFAZ21haWwuY29tPj47IDxydGN3ZWJAaWV0 Zi5vcmc8bWFpbHRvOnJ0Y3dlYkBpZXRmLm9yZz4+IDxydGN3ZWJAaWV0Zi5vcmc8bWFpbHRvOnJ0 Y3dlYkBpZXRmLm9yZz4+DQpTdWJqZWN0OiBSZTogW3J0Y3dlYl0gV2hhdCB0aGUgZ2F0ZXdheSBk cmFmdCBzaG91bGQgc2F5IGFib3V0IG11eC9ub24tbXV4DQoNCk9uIFdlZCwgQXVnIDUsIDIwMTUg YXQgNDo0NyBBTSwgUmF1c2NoZW5iYWNoLCBVd2UgKE5va2lhIC0gREUvTXVuaWNoKSA8dXdlLnJh dXNjaGVuYmFjaEBub2tpYS5jb208bWFpbHRvOnV3ZS5yYXVzY2hlbmJhY2hAbm9raWEuY29tPj4g d3JvdGU6DQpNZWRpYSBnYXRld2F5IGltcGxlbWVudGF0aW9ucyBhY2NvcmRpbmcgdG8gM0dQUCBU UyAyMy4yMjggbWF5IG5vdCBzdXBwb3J0IHJ0Y3AtbXV4LCBhcyBydGNwLW11eCBpcyBvcHRpb25h bCB0aGVyZS4NClNvIGlmIHdlIGRyb3Agbm9uLW11eCBzdXBwb3J0IGZyb20gd2ViIGJyb3dzZXJz LCB0aG9zZSBtZWRpYSBnYXRld2F5cyB0aGF0IGhhdmUgbm90IGltcGxlbWVudGVkIHJ0Y3AtbXV4 IHdpbGwgc3RvcCBpbnRlcm9wZXJhdGluZy4NCg0KDQpGaXJzdCBvZiBhbGwsIGRvIHlvdSBrbm93 IG9mIGFueSBXZWJSVEMgdG8gSU1TIGdhdGV3YXlzIHRoYXQgZG8gbm90IGltcGxlbWVudCBydGNw LW11eCBvbiB0aGUgV2ViUlRDIHNpZGU/IEkgc3Ryb25nbHkgc3VzcGVjdCB0aGVyZSBhcmUgbm9u ZS4NCg0KU2Vjb25kLCB0aGUgb25seSByZWFzb25zIG5vdCB0byB1c2UgcnRjcC1tdXggdGhhdCBJ IGNhbiB0aGluayBvZiBhcmUgdGhlIGZvbGxvd2luZzoNCg0KMS4gVXNpbmcgZGlmZmVyZW50IFFP UyBzZXR0aW5ncyBmb3IgUlRDUCB2cyBSVFANCjIuIFNlbmRpbmcgUlRDUCB0byBhIGRpZmZlcmVu dCBkZXZpY2UgZnJvbSBSVFANCg0KSSBkbyBub3QgdGhpbmsgdGhlIGZpcnN0IHVzZSBjYXNlIHdh cnJhbnRzIG1ha2luZyBydGNwLW11eCBvcHRpb25hbCwgc2luY2UsIHByYWN0aWNhbGx5IG5vIG9u ZSBkb2VzIHRoaXMuDQpTZWNvbmQgdXNlIGNhc2UgaXMgYWxzbyBmYWlybHkgbWFyZ2luYWwuIFBs dXMgaXQgY2FuIGJlIGhhbmRsZWQgYnkgdGhlIGdhdGV3YXkgd2hpY2ggY2FuIHNlbmQgUlRDUCB0 byBvbmUgZGV2aWNlIGFuZCBSVFAgdG8gYW5vdGhlci4NCg0KU28sIHVubGVzcyBzb21lb25lIGNh biBjb21lIHVwIHdpdGggYSB1c2UgY2FzZSB3aHkgUlRQIGFuZCBSVENQIHNob3VsZCB1c2UgZGlm ZmVyZW50IHRyYW5zcG9ydHMsIEkgdGhpbmsgcnRjcC1tdXggc2hvdWxkIGJlIG1hbmRhdG9yeS4N Cg0KUmVnYXJkcywNCl9fX19fX19fX19fX19fDQpSb21hbiBTaHBvdW50DQpfX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KcnRjd2ViIG1haWxpbmcgbGlzdA0K cnRjd2ViQGlldGYub3JnPG1haWx0bzpydGN3ZWJAaWV0Zi5vcmc+DQpodHRwczovL3d3dy5pZXRm Lm9yZy9tYWlsbWFuL2xpc3RpbmZvL3J0Y3dlYg0KDQoNCg== --_000_SN1PR0301MB1551A79D0AA05593987D8109B2740SN1PR0301MB1551_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPCEtLVtp ZiAhbXNvXT48c3R5bGU+dlw6KiB7YmVoYXZpb3I6dXJsKCNkZWZhdWx0I1ZNTCk7fQ0Kb1w6KiB7 YmVoYXZpb3I6dXJsKCNkZWZhdWx0I1ZNTCk7fQ0Kd1w6KiB7YmVoYXZpb3I6dXJsKCNkZWZhdWx0 I1ZNTCk7fQ0KLnNoYXBlIHtiZWhhdmlvcjp1cmwoI2RlZmF1bHQjVk1MKTt9DQo8L3N0eWxlPjwh W2VuZGlmXS0tPjxzdHlsZT48IS0tDQovKiBGb250IERlZmluaXRpb25zICovDQpAZm9udC1mYWNl DQoJe2ZvbnQtZmFtaWx5OkhlbHZldGljYTsNCglwYW5vc2UtMToyIDExIDYgNCAyIDIgMiAyIDIg NDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OiJDYW1icmlhIE1hdGgiOw0KCXBhbm9zZS0x OjIgNCA1IDMgNSA0IDYgMyAyIDQ7fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseTpDYWxpYnJp Ow0KCXBhbm9zZS0xOjIgMTUgNSAyIDIgMiA0IDMgMiA0O30NCkBmb250LWZhY2UNCgl7Zm9udC1m YW1pbHk6VGFob21hOw0KCXBhbm9zZS0xOjIgMTEgNiA0IDMgNSA0IDQgMiA0O30NCkBmb250LWZh Y2UNCgl7Zm9udC1mYW1pbHk6Q29uc29sYXM7DQoJcGFub3NlLTE6MiAxMSA2IDkgMiAyIDQgMyAy IDQ7fQ0KLyogU3R5bGUgRGVmaW5pdGlvbnMgKi8NCnAuTXNvTm9ybWFsLCBsaS5Nc29Ob3JtYWws IGRpdi5Nc29Ob3JtYWwNCgl7bWFyZ2luOjBpbjsNCgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJ Zm9udC1zaXplOjEyLjBwdDsNCglmb250LWZhbWlseToiVGltZXMgTmV3IFJvbWFuIixzZXJpZjt9 DQphOmxpbmssIHNwYW4uTXNvSHlwZXJsaW5rDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCglj b2xvcjpibHVlOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0KYTp2aXNpdGVkLCBzcGFu Lk1zb0h5cGVybGlua0ZvbGxvd2VkDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgljb2xvcjpw dXJwbGU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQpwLk1zb0FjZXRhdGUsIGxpLk1z b0FjZXRhdGUsIGRpdi5Nc29BY2V0YXRlDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgltc28t c3R5bGUtbGluazoiQmFsbG9vbiBUZXh0IENoYXIiOw0KCW1hcmdpbjowaW47DQoJbWFyZ2luLWJv dHRvbTouMDAwMXB0Ow0KCWZvbnQtc2l6ZTo4LjBwdDsNCglmb250LWZhbWlseToiVGFob21hIixz YW5zLXNlcmlmO30NCnNwYW4uQmFsbG9vblRleHRDaGFyDQoJe21zby1zdHlsZS1uYW1lOiJCYWxs b29uIFRleHQgQ2hhciI7DQoJbXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCW1zby1zdHlsZS1saW5r OiJCYWxsb29uIFRleHQiOw0KCWZvbnQtZmFtaWx5OiJUYWhvbWEiLHNhbnMtc2VyaWY7fQ0Kc3Bh bi5hcHBsZS1jb252ZXJ0ZWQtc3BhY2UNCgl7bXNvLXN0eWxlLW5hbWU6YXBwbGUtY29udmVydGVk LXNwYWNlO30NCnNwYW4uRW1haWxTdHlsZTIwDQoJe21zby1zdHlsZS10eXBlOnBlcnNvbmFsOw0K CWZvbnQtZmFtaWx5OiJDYWxpYnJpIixzYW5zLXNlcmlmOw0KCWNvbG9yOiMxRjQ5N0Q7fQ0Kc3Bh bi5FbWFpbFN0eWxlMjENCgl7bXNvLXN0eWxlLXR5cGU6cGVyc29uYWwtcmVwbHk7DQoJZm9udC1m YW1pbHk6IkNhbGlicmkiLHNhbnMtc2VyaWY7DQoJY29sb3I6IzFGNDk3RDt9DQouTXNvQ2hwRGVm YXVsdA0KCXttc28tc3R5bGUtdHlwZTpleHBvcnQtb25seTsNCglmb250LXNpemU6MTAuMHB0O30N CkBwYWdlIFdvcmRTZWN0aW9uMQ0KCXtzaXplOjguNWluIDExLjBpbjsNCgltYXJnaW46MS4waW4g MS4waW4gMS4waW4gMS4waW47fQ0KZGl2LldvcmRTZWN0aW9uMQ0KCXtwYWdlOldvcmRTZWN0aW9u MTt9DQotLT48L3N0eWxlPjwhLS1baWYgZ3RlIG1zbyA5XT48eG1sPg0KPG86c2hhcGVkZWZhdWx0 cyB2OmV4dD0iZWRpdCIgc3BpZG1heD0iMTAyNiIgLz4NCjwveG1sPjwhW2VuZGlmXS0tPjwhLS1b aWYgZ3RlIG1zbyA5XT48eG1sPg0KPG86c2hhcGVsYXlvdXQgdjpleHQ9ImVkaXQiPg0KPG86aWRt YXAgdjpleHQ9ImVkaXQiIGRhdGE9IjEiIC8+DQo8L286c2hhcGVsYXlvdXQ+PC94bWw+PCFbZW5k aWZdLS0+DQo8L2hlYWQ+DQo8Ym9keSBsYW5nPSJFTi1VUyIgbGluaz0iYmx1ZSIgdmxpbms9InB1 cnBsZSI+DQo8ZGl2IGNsYXNzPSJXb3JkU2VjdGlvbjEiPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZx dW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0QiPkkgdGhpbmsgaW1wbGVtZW50ZXJzIHRoZW1z ZWx2ZXMgY2FuIHdlaWdoIG91dCB0aGUgYWR2YW50YWdlcy9kaXNhZHZhbnRhZ2VkL2RlcGxveW1l bnQgbW9kZWxzIHRoZXkgYXJlIHRhcmdldGluZy9ldGPigKYgYW5kIGRlY2lkZSB3aGF0IHRvIHN1 cHBvcnQvbm90IHRvIHN1cHBvcnQuDQogSSBkb27igJl0IHNlZSBhbnkgaXNzdWUgd2l0aCB0aGlz IGFzIGxvbmcgYXMgdGhlcmUgaXMgYSBuZWdvdGlhdGlvbiBtZWNoYW5pc20gKHdoaWNoIHRoZXJl IGlzKS4gSSBkb27igJl0IHRoaW5rIHRoZSBhdmFpbGFiaWxpdHkgb2YgbmVnb3RpYXRpb24gaXMg ZW5jb3VyYWdpbmcgcGVvcGxlIHRoaXMgb3IgdGhhdCB3YXkuPG86cD48L286cD48L3NwYW4+PC9w Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9u dC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0QiPjxv OnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0 eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fu cy1zZXJpZjtjb2xvcjojMUY0OTdEIj5UaGFua3MsPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1p bHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0QiPlRvbGdhPG86 cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZv bnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlm O2NvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxkaXYgc3R5bGU9 ImJvcmRlcjpub25lO2JvcmRlci1sZWZ0OnNvbGlkIGJsdWUgMS41cHQ7cGFkZGluZzowaW4gMGlu IDBpbiA0LjBwdCI+DQo8ZGl2Pg0KPGRpdiBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLXRvcDpz b2xpZCAjRTFFMUUxIDEuMHB0O3BhZGRpbmc6My4wcHQgMGluIDBpbiAwaW4iPg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+PGI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6 JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmIj5Gcm9tOjwvc3Bhbj48L2I+PHNwYW4gc3R5 bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5z LXNlcmlmIj4gdGltIHBhbnRvbiBbbWFpbHRvOnRpbUBwaG9uZWZyb21oZXJlLmNvbV0NCjxicj4N CjxiPlNlbnQ6PC9iPiBUaHVyc2RheSwgQXVndXN0IDA2LCAyMDE1IDEwOjA3IEFNPGJyPg0KPGI+ VG86PC9iPiBIdXR0b24sIEFuZHJldyAmbHQ7YW5kcmV3Lmh1dHRvbkB1bmlmeS5jb20mZ3Q7PGJy Pg0KPGI+Q2M6PC9iPiBBc3ZlcmVuLCBUb2xnYSAmbHQ7dGFzdmVyZW5Ac29udXNuZXQuY29tJmd0 OzsgJmx0O3J0Y3dlYkBpZXRmLm9yZyZndDsgJmx0O3J0Y3dlYkBpZXRmLm9yZyZndDs8YnI+DQo8 Yj5TdWJqZWN0OjwvYj4gUmU6IFtydGN3ZWJdIFdoYXQgdGhlIGdhdGV3YXkgZHJhZnQgc2hvdWxk IHNheSBhYm91dCBtdXgvbm9uLW11eDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPC9k aXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPGRpdj4NCjxibG9ja3F1b3RlIHN0 eWxlPSJtYXJnaW4tdG9wOjUuMHB0O21hcmdpbi1ib3R0b206NS4wcHQiPg0KPGRpdj4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPk9uIDYgQXVnIDIwMTUsIGF0IDA4OjMwLCBIdXR0b24sIEFuZHJldyAm bHQ7PGEgaHJlZj0ibWFpbHRvOmFuZHJldy5odXR0b25AdW5pZnkuY29tIj5hbmRyZXcuaHV0dG9u QHVuaWZ5LmNvbTwvYT4mZ3Q7IHdyb3RlOjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6 JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0QiPiYjNDM7MSB0byB3 aGF0IFRpbSBzYWlkLjwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkm cXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEIj4mbmJzcDs8L3NwYW4+PG86cD48L286cD48 L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtm b250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RCI+ SSBkb27igJl0IHRoaW5rIHRoaXMgZGlzY3Vzc2lvbiBpcyByZWFsbHkgYWJvdXQgZ2F0ZXdheXMg YXQgYWxsIGl0IGlzIHN1cmVseSBhYm91dCB3aGV0aGVyIFdlYlJUQyBicm93c2VycyBoYXZlIHRv IHN1cHBvcnQgbm9uLW11eCBhbmQgSSBkb27igJl0IHJlYWxseSBzZWUgYW55IGdvb2QNCiByZWFz b24gd2h5IHRoZXkgbmVlZCB0by48L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtD YWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RCI+Jm5ic3A7PC9zcGFuPjxvOnA+ PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTox MS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMx RjQ5N0QiPklmIHdlIGhhZCB0aG91Z2h0IGFib3V0IHRoaXMgYXQgdGhlIHRpbWUgd2UgbWFuZGF0 ZWQgRFRMUy1TUlRQIHRoZW4gd2Ugd291bGQgaGF2ZSBtYW5kYXRlZCBydHAtbXV4IGF0IHRoZSBz YW1lIHRpbWUgYnV0IHVuZm9ydHVuYXRlbHkgd2UgZGlkbuKAmXQgYnV0IHdlIGNhbiBmaXgNCiB0 aGF0IG5vdy48L3NwYW4+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9ibG9ja3F1 b3RlPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0K PC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+U2FkbHkgdHJ1ZSwgYnV0IHRoZSBz aXR1YXRpb24gaW4gYSBicm93c2VyIGlzIG1hbmFnZWFibGUgc2luY2UgeW91IG1pZ2h0IGV4cGVj dCAxMCBwZWVyIGNvbm5lY3Rpb25zLCByZXN1bHRpbmcmbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwv ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPmluIGEgd29yc3QgY2FzZSBvZiA2MCBV RFAgcG9ydHMvRFRMUyBzZXNzaW9ucyBpbiB1c2UmbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2 Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPihhc3N1bWluZyB2b2ljZSYjNDM7dmlkZW8m IzQzO2RhdGEgdW5idW5kbGVkIGFuZCBSVENQLW5vbi1tdXggdnMgdGhlIDEwIG5lZWRlZCkuIFdl Jm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij5hbHNvIGFzc3VtZSBhIHJlbGF0aXZlbHkgd2VsbCBlbmRvd2VkIENQVSAtIGRldm90ZWQgbGFy Z2VseSB0byB0aGlzIHRhc2suPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPk9uIHRoZSBnYXRld2F5IHlvdeKAmWQgaG9wZSB0byBoYXZlIHRob3Vz YW5kcyBvZiBzZXNzaW9ucyBhbmQgcHJlc3VtYWJseSBtdWNoIGxlc3MgQ1BVL21lbW9yeSByZXNv dXJjZSBwZXIgY2hhbm5lbC48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPlNvIHdoaWxlIEkgdGhpbmsgaXQgaXMgdW5mb3J0dW5hdGUgdGhhdCBicm93 c2VycyBjYW4gZG8gbm9uLW11eCwgaXQgd291bGQgYmUgcGxhaW4gc3R1cGlkIHRvIGRvIHRoYXQg b24gYSBnYXRld2F5LiBEbyB3ZSZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+cmVhbGx5IHdhbnQgdG8gZW5jb3VyYWdlIHRoYXQgPzxvOnA+ PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJz cDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5ULjxvOnA+ PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJz cDs8L286cD48L3A+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxicj4NCjxicj4NCjxv OnA+PC9vOnA+PC9wPg0KPGJsb2NrcXVvdGUgc3R5bGU9Im1hcmdpbi10b3A6NS4wcHQ7bWFyZ2lu LWJvdHRvbTo1LjBwdCI+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFu IHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDss c2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEIj4mbmJzcDs8L3NwYW4+PG86cD48L286cD48L3A+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZh bWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RCI+QW5keTwv c3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJm b250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJp Zjtjb2xvcjojMUY0OTdEIj4mbmJzcDs8L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVv dDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RCI+Jm5ic3A7PC9zcGFuPjxv OnA+PC9vOnA+PC9wPg0KPGRpdiBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLWxlZnQ6c29saWQg Ymx1ZSAxLjVwdDtwYWRkaW5nOjBpbiAwaW4gMGluIDQuMHB0Ij4NCjxkaXY+DQo8ZGl2IHN0eWxl PSJib3JkZXI6bm9uZTtib3JkZXItdG9wOnNvbGlkICNCNUM0REYgMS4wcHQ7cGFkZGluZzozLjBw dCAwaW4gMGluIDBpbiI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48Yj48c3BhbiBzdHlsZT0iZm9u dC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtUYWhvbWEmcXVvdDssc2Fucy1zZXJpZiI+ RnJvbTo8L3NwYW4+PC9iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5 OiZxdW90O1RhaG9tYSZxdW90OyxzYW5zLXNlcmlmIj4gcnRjd2ViIFs8YSBocmVmPSJtYWlsdG86 cnRjd2ViLWJvdW5jZXNAaWV0Zi5vcmciPm1haWx0bzpydGN3ZWItYm91bmNlc0BpZXRmLm9yZzwv YT5dDQo8Yj5PbiBCZWhhbGYgT2YgPC9iPnRpbSBwYW50b248YnI+DQo8Yj5TZW50OjwvYj4gMDYg QXVndXN0IDIwMTUgMTM6NTM8YnI+DQo8Yj5Ubzo8L2I+IEFzdmVyZW4sIFRvbGdhPGJyPg0KPGI+ Q2M6PC9iPiAmbHQ7PGEgaHJlZj0ibWFpbHRvOnJ0Y3dlYkBpZXRmLm9yZyI+cnRjd2ViQGlldGYu b3JnPC9hPiZndDs8YnI+DQo8Yj5TdWJqZWN0OjwvYj4gUmU6IFtydGN3ZWJdIFdoYXQgdGhlIGdh dGV3YXkgZHJhZnQgc2hvdWxkIHNheSBhYm91dCBtdXgvbm9uLW11eDwvc3Bhbj48bzpwPjwvbzpw PjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4mbmJzcDs8bzpwPjwv bzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPlNvIHdlIGFyZSBwb3NpdGluZyB0aGUgZXhp c3RlbmNlIG9mIGEgd2ViUlRDIGdhdGV3YXkgZGVzaWduZWQgdG8gc3VwcG9ydCB0aG91c2FuZHMg b2YgY2FsbHMgd2hpY2ggZG9lcyBJQ0UgYW5kIERUTFMgYnV0IHRoZTxvOnA+PC9vOnA+PC9wPg0K PGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5kZXNpZ25lciBkZWNpZGVkIGRlbGli ZXJhdGVseSB0byBkb3VibGUgdGhlIG51bWJlciBvZiBJQ0Ugc2Vzc2lvbnMgcmVxdWlyZWQgYW5k IGRvdWJsZSB0aGUgbnVtYmVyIG9mIERUTFMgc2Vzc2lvbnMgKGFuZCBrZXkmbmJzcDs8bzpwPjwv bzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPmdlbmVyYXRpb24g Y29zdHMpIHNvIHRoYXQgdGhleSBjYW4gcnVuIFJUQ1AgKG92ZXIgSUNFIGFuZCBEVExTKSBvbiBh IHNlcGFyYXRlIHBvcnQuIEluIG15IGVzdGltYXRpb24gdGhhdOKAmXMgb25lIHBvb3IgZGVjaXNp b248bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPmFu ZCBzaG91bGQgbm90IGJlIHVzZWQgYXMgdGhlIGJhc2lzIG9mIHRoaXMgKG9yIGFueSkgc3RhbmRh cmQuJm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPknigJlkIHJhdGhlciBub3Qgc3VwcG9ydCBydGNwLW5vLW11eCBhcyBJIHNlZSB6ZXJv IGFkdmFudGFnZXMgaW4gaGF2aW5nIGl0LiAoSSBrbm93IHRoZW9yZXRpY2FsbHkgaXQgbWlnaHQg YmUgcG9zc2libGUgdG8gZ2V0PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj5hIFJUQ1AgcGFja2V0IHRocm91Z2ggYSBjb25nZXN0ZWQgbmV0IG9uIGEg ZGlmZmVyZW50IHBvcnQgd2l0aCBhIHNlcGFyYXRlIGRpZmZzZXJ2IHNldHRpbmcgYnV0IHRoYXQg anVzdCBzZWVtcyBzbyBjb250cml2ZWQpLjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5UaW0uPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRp dj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8 ZGl2Pg0KPGRpdj4NCjxibG9ja3F1b3RlIHN0eWxlPSJtYXJnaW4tdG9wOjUuMHB0O21hcmdpbi1i b3R0b206NS4wcHQiPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPk9uIDYgQXVnIDIwMTUs IGF0IDA2OjQ0LCBBc3ZlcmVuLCBUb2xnYSAmbHQ7PGEgaHJlZj0ibWFpbHRvOnRhc3ZlcmVuQHNv bnVzbmV0LmNvbSI+dGFzdmVyZW5Ac29udXNuZXQuY29tPC9hPiZndDsgd3JvdGU6PG86cD48L286 cD48L3A+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPiZuYnNwOzxvOnA+PC9vOnA+PC9w Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1z aXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29s b3I6IzFGNDk3RCI+VGhlc2UgYXNzdW1wdGlvbnMgYXJlIG5vdCBuZWNlc3NhcmlseSB0cnVlIGlu IGEgdW5pdmVyc2FsIHNlbnNlIChsaWtlIGFsbW9zdCBhbnkgb3RoZXIgYXNzdW1wdGlvbiBhYm91 dCBkaWZmZXJlbnQgZGVwbG95bWVudCBtb2RlbHMpLjwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwv ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6 MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjoj MUY0OTdEIj4mbmJzcDs8L3NwYW4+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWls eTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RCI+RnVydGhlcm1v cmUsIGFuZCBtb3JlIGltcG9ydGFudGx5LCB0aGVyZSBpcyBub3RoaW5nIG1hbmRhdGluZyBXZWJS VEMgZW5kcG9pbnRzIHRvIHN1cHBvcnQgbm9uLXJ0Y3AtbXV4LiBJdCBpcyBhIG5lZ290aWF0ZWQg ZnVuY3Rpb25hbGl0eS4gQW55IGVudGl0eSBjYW4gZW5mb3JjZQ0KIHJ0Y3AtbXV4IGFzIGEgbG9j YWwgcG9saWN5LjxzcGFuIGNsYXNzPSJhcHBsZS1jb252ZXJ0ZWQtc3BhY2UiPiZuYnNwOzwvc3Bh bj48L3NwYW4+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxp YnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RCI+Jm5ic3A7PC9zcGFuPjxvOnA+PC9v OnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9 ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNl cmlmO2NvbG9yOiMxRjQ5N0QiPlRoZSBpc3N1ZSB3aXRoIHN1cHBvcnRpbmcgbm9uLXJ0Y3AtbXV4 IHNlZW1zIHRvIGJlIGxhY2sgb2YgY2xhcml0eSBpbiB0aGUgcmVsZXZhbnQgc3BlY2lmaWNhdGlv bnMuIEZpeGluZyB0aGlzIOKAk3JlZ2FyZGxlc3Mgb2YgdGhlIG91dGNvbWUgb2YgYW55IG90aGVy IGRpc2N1c3Npb24tDQogc2VlbXMgdG8gYmUgcHJ1ZGVudCBJTUhPLjwvc3Bhbj48bzpwPjwvbzpw PjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJm b250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJp Zjtjb2xvcjojMUY0OTdEIj4mbmJzcDs8L3NwYW4+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxk aXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtm b250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RCI+ VGhhbmtzLDwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90 O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEIj5Ub2xnYTwvc3Bhbj48bzpw PjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0 eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fu cy1zZXJpZjtjb2xvcjojMUY0OTdEIj4mbmJzcDs8L3NwYW4+PG86cD48L286cD48L3A+DQo8L2Rp dj4NCjxkaXYgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci1sZWZ0OnNvbGlkIGJsdWUgMS41cHQ7 cGFkZGluZzowaW4gMGluIDBpbiA0LjBwdCI+DQo8ZGl2Pg0KPGRpdiBzdHlsZT0iYm9yZGVyOm5v bmU7Ym9yZGVyLXRvcDpzb2xpZCAjRTFFMUUxIDEuMHB0O3BhZGRpbmc6My4wcHQgMGluIDBpbiAw aW4iPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxiPjxzcGFuIHN0eWxlPSJmb250LXNp emU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZiI+RnJv bTo8L3NwYW4+PC9iPjxzcGFuIGNsYXNzPSJhcHBsZS1jb252ZXJ0ZWQtc3BhY2UiPjxzcGFuIHN0 eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fu cy1zZXJpZiI+Jm5ic3A7PC9zcGFuPjwvc3Bhbj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBw dDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWYiPld5c3MsDQogRmVs aXggWzxhIGhyZWY9Im1haWx0bzpGZWxpeC5XeXNzQGluaW4uY29tIj5tYWlsdG86RmVsaXguV3lz c0BpbmluLmNvbTwvYT5dPHNwYW4gY2xhc3M9ImFwcGxlLWNvbnZlcnRlZC1zcGFjZSI+Jm5ic3A7 PC9zcGFuPjxicj4NCjxiPlNlbnQ6PC9iPjxzcGFuIGNsYXNzPSJhcHBsZS1jb252ZXJ0ZWQtc3Bh Y2UiPiZuYnNwOzwvc3Bhbj5UaHVyc2RheSwgQXVndXN0IDA2LCAyMDE1IDY6MzcgQU08YnI+DQo8 Yj5Ubzo8L2I+PHNwYW4gY2xhc3M9ImFwcGxlLWNvbnZlcnRlZC1zcGFjZSI+Jm5ic3A7PC9zcGFu PkNocmlzdGVyIEhvbG1iZXJnICZsdDs8YSBocmVmPSJtYWlsdG86Y2hyaXN0ZXIuaG9sbWJlcmdA ZXJpY3Nzb24uY29tIj5jaHJpc3Rlci5ob2xtYmVyZ0Blcmljc3Nvbi5jb208L2E+Jmd0OzsgQXN2 ZXJlbiwgVG9sZ2EgJmx0OzxhIGhyZWY9Im1haWx0bzp0YXN2ZXJlbkBzb251c25ldC5jb20iPnRh c3ZlcmVuQHNvbnVzbmV0LmNvbTwvYT4mZ3Q7OyBTY2h3YXJ6LCBBbGJyZWNodA0KIChBbGJyZWNo dCkgJmx0OzxhIGhyZWY9Im1haWx0bzphbGJyZWNodC5zY2h3YXJ6QGFsY2F0ZWwtbHVjZW50LmNv bSI+YWxicmVjaHQuc2Nod2FyekBhbGNhdGVsLWx1Y2VudC5jb208L2E+Jmd0OzsgUm9tYW4gU2hw b3VudCAmbHQ7PGEgaHJlZj0ibWFpbHRvOnJvbWFuQHRlbHVyaXguY29tIj5yb21hbkB0ZWx1cml4 LmNvbTwvYT4mZ3Q7OyBSYXVzY2hlbmJhY2gsIFV3ZSAoTm9raWEgLSBERS9NdW5pY2gpICZsdDs8 YSBocmVmPSJtYWlsdG86dXdlLnJhdXNjaGVuYmFjaEBub2tpYS5jb20iPnV3ZS5yYXVzY2hlbmJh Y2hAbm9raWEuY29tPC9hPiZndDs8YnI+DQo8Yj5DYzo8L2I+PHNwYW4gY2xhc3M9ImFwcGxlLWNv bnZlcnRlZC1zcGFjZSI+Jm5ic3A7PC9zcGFuPiZsdDs8YSBocmVmPSJtYWlsdG86cnRjd2ViQGll dGYub3JnIj5ydGN3ZWJAaWV0Zi5vcmc8L2E+Jmd0OyAmbHQ7PGEgaHJlZj0ibWFpbHRvOnJ0Y3dl YkBpZXRmLm9yZyI+cnRjd2ViQGlldGYub3JnPC9hPiZndDs8YnI+DQo8Yj5TdWJqZWN0OjwvYj48 c3BhbiBjbGFzcz0iYXBwbGUtY29udmVydGVkLXNwYWNlIj4mbmJzcDs8L3NwYW4+UmU6IFtydGN3 ZWJdIFdoYXQgdGhlIGdhdGV3YXkgZHJhZnQgc2hvdWxkIHNheSBhYm91dCBtdXgvbm9uLW11eDwv c3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdiBpZD0i ZGl2dGFnZGVmYXVsdHdyYXBwZXIiPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxl PSJiYWNrZ3JvdW5kOndoaXRlIj48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJy aSZxdW90OyxzYW5zLXNlcmlmIj5XaHkgc2hvdWxkbid0IHRoZSBnYXRld2F5IGJlIHJlcXVpcmVk IHRvIGRvIHRoZSBtdXgvZGVtdXg/Jm5ic3A7IE1ha2luZyB0aGUgV2ViUlRDIGVuZHBvaW50cyBh IGxvdCBtb3JlIGNvbXBsZXgganVzdCBzbyB0aGUgbGVnYWN5IGludGVyb3AgbWlnaHQgcG90ZW50 aWFsbHkgYmUgYSB0ZWVueS10aW55DQogYml0IGVhc2llciBtYWtlcyBubyBzZW5zZSBJTUhPLiZu YnNwOyBBY3R1YWxseSwgdGhlIGdhdGV3YXkgd291bGQgbm90IGJlIGFibGUgdG8gZG8gJnF1b3Q7 ZW5kLXRvLWVuZCZxdW90OyBwYXNzLXRocm91Z2ggYW55d2F5IGFzIGxlZ2FjeSBlcXVpcG1lbnQg d2lsbCBlaXRoZXIgYmUgdW5lbmNyeXB0ZWQgb3IgdXNlIFNERVMgKFJGQyM0NTY4KSBmb3Iga2V5 IGV4Y2hhbmdlLiZuYnNwOyBTbyB0aGUgZ2F0ZXdheSB3aWxsIGhhdmUgdG8gcGVyZm9ybSBEVExT LVNSVFAgdG8gU0RFUy1TUlRQDQogdHJhbnNjcnlwdGlvbi0td2hpY2ggYWxyZWFkeSBpcyB3YXkg bW9yZSBoYXNzbGUgdGhhbiBSVFAvUlRDUCBtdXgvZGVtdXguPC9zcGFuPjxvOnA+PC9vOnA+PC9w Pg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9ImJhY2tncm91bmQ6 d2hpdGUiPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMt c2VyaWYiPiZuYnNwOzwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJiYWNrZ3JvdW5kOndoaXRlIj48c3BhbiBzdHlsZT0iZm9u dC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmIj4tLUZlbGl4PC9zcGFuPjxv OnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9 ImJhY2tncm91bmQ6d2hpdGUiPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtDYWxpYnJp JnF1b3Q7LHNhbnMtc2VyaWYiPiZuYnNwOzwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0K PGRpdj4NCjxkaXYgY2xhc3M9Ik1zb05vcm1hbCIgYWxpZ249ImNlbnRlciIgc3R5bGU9InRleHQt YWxpZ246Y2VudGVyO2JhY2tncm91bmQ6d2hpdGUiPg0KPHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5 OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZiI+DQo8aHIgc2l6ZT0iMiIgd2lkdGg9Ijk4 JSIgYWxpZ249ImNlbnRlciI+DQo8L3NwYW4+PC9kaXY+DQo8ZGl2IGlkPSJkaXZScGx5RndkTXNn Ij4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0iYmFja2dyb3VuZDp3aGl0ZSI+ PGI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJy aSZxdW90OyxzYW5zLXNlcmlmIj5Gcm9tOjwvc3Bhbj48L2I+PHNwYW4gY2xhc3M9ImFwcGxlLWNv bnZlcnRlZC1zcGFjZSI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6 JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmIj4mbmJzcDs8L3NwYW4+PC9zcGFuPjxzcGFu IHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDss c2Fucy1zZXJpZiI+cnRjd2ViDQogJmx0OzxhIGhyZWY9Im1haWx0bzpydGN3ZWItYm91bmNlc0Bp ZXRmLm9yZyI+PHNwYW4gc3R5bGU9ImNvbG9yOnB1cnBsZSI+cnRjd2ViLWJvdW5jZXNAaWV0Zi5v cmc8L3NwYW4+PC9hPiZndDsgb24gYmVoYWxmIG9mIENocmlzdGVyIEhvbG1iZXJnICZsdDs8YSBo cmVmPSJtYWlsdG86Y2hyaXN0ZXIuaG9sbWJlcmdAZXJpY3Nzb24uY29tIj48c3BhbiBzdHlsZT0i Y29sb3I6cHVycGxlIj5jaHJpc3Rlci5ob2xtYmVyZ0Blcmljc3Nvbi5jb208L3NwYW4+PC9hPiZn dDs8YnI+DQo8Yj5TZW50OjwvYj48c3BhbiBjbGFzcz0iYXBwbGUtY29udmVydGVkLXNwYWNlIj4m bmJzcDs8L3NwYW4+VGh1cnNkYXksIEF1Z3VzdCA2LCAyMDE1IDA1OjUxPGJyPg0KPGI+VG86PC9i PjxzcGFuIGNsYXNzPSJhcHBsZS1jb252ZXJ0ZWQtc3BhY2UiPiZuYnNwOzwvc3Bhbj5Bc3ZlcmVu LCBUb2xnYTsgU2Nod2FyeiwgQWxicmVjaHQgKEFsYnJlY2h0KTsgUm9tYW4gU2hwb3VudDsgUmF1 c2NoZW5iYWNoLCBVd2UgKE5va2lhIC0gREUvTXVuaWNoKTxicj4NCjxiPkNjOjwvYj48c3BhbiBj bGFzcz0iYXBwbGUtY29udmVydGVkLXNwYWNlIj4mbmJzcDs8L3NwYW4+Jmx0OzxhIGhyZWY9Im1h aWx0bzpydGN3ZWJAaWV0Zi5vcmciPjxzcGFuIHN0eWxlPSJjb2xvcjpwdXJwbGUiPnJ0Y3dlYkBp ZXRmLm9yZzwvc3Bhbj48L2E+Jmd0Ozxicj4NCjxiPlN1YmplY3Q6PC9iPjxzcGFuIGNsYXNzPSJh cHBsZS1jb252ZXJ0ZWQtc3BhY2UiPiZuYnNwOzwvc3Bhbj5SZTogW3J0Y3dlYl0gV2hhdCB0aGUg Z2F0ZXdheSBkcmFmdCBzaG91bGQgc2F5IGFib3V0IG11eC9ub24tbXV4PC9zcGFuPjxvOnA+PC9v OnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxl PSJiYWNrZ3JvdW5kOndoaXRlIj48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJy aSZxdW90OyxzYW5zLXNlcmlmIj4mbmJzcDs8L3NwYW4+PG86cD48L286cD48L3A+DQo8L2Rpdj4N CjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFs IiBzdHlsZT0iYmFja2dyb3VuZDp3aGl0ZSI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7 Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0Qi PkhpLDwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29O b3JtYWwiIHN0eWxlPSJiYWNrZ3JvdW5kOndoaXRlIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEx LjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFG NDk3RCI+Jm5ic3A7PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xh c3M9Ik1zb05vcm1hbCIgc3R5bGU9ImJhY2tncm91bmQ6d2hpdGUiPjxzcGFuIHN0eWxlPSJmb250 LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtj b2xvcjojMUY0OTdEIj5ObyBtYXR0ZXIgd2hldGhlciB0aGUgZ2F0ZXdheSBzdXBwb3J0cyBSVFAv UlRDUCBtdXggb3Igbm90LCB0aGVyZSBhcmUgY2FzZXMgd2hlcmUgdGhlIGxlZ2FjeSBuZXR3b3Jr L2VuZHBvaW50cyB3aWxsIG5vdCB1c2UgUlRQL1JUQ1ANCiBtdXgsIHNvIEkgZ3Vlc3MgcGVvcGxl IHRoZW4gd291bGQgd2FudCB0byBiZSBhYmxlIHRvIG5lZ290aWF0ZSBub24tbXV4IOKAnGVuZC10 by1lbmTigJ0sIHJhdGhlciB0aGFuIGhhdmluZyB0aGUgZ2F0ZXdheSB0byBkZW11eC9tdXggUlRQ IGFuZCBSVENQLjwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiIHN0eWxlPSJiYWNrZ3JvdW5kOndoaXRlIj48c3BhbiBzdHlsZT0iZm9udC1z aXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29s b3I6IzFGNDk3RCI+Jm5ic3A7PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0K PHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9ImJhY2tncm91bmQ6d2hpdGUiPjxzcGFuIHN0eWxl PSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1z ZXJpZjtjb2xvcjojMUY0OTdEIj5SZWdhcmRzLDwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2 Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJiYWNrZ3JvdW5kOndoaXRlIj48 c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1 b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RCI+Jm5ic3A7PC9zcGFuPjxvOnA+PC9vOnA+PC9w Pg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9ImJhY2tncm91bmQ6 d2hpdGUiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0Nh bGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEIj5DaHJpc3Rlcjwvc3Bhbj48bzpw PjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJi YWNrZ3JvdW5kOndoaXRlIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWls eTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RCI+Jm5ic3A7PC9z cGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdiBzdHlsZT0iYm9yZGVyOm5v bmU7Ym9yZGVyLXRvcDpzb2xpZCAjQjVDNERGIDEuMHB0O3BhZGRpbmc6My4wcHQgMGluIDBpbiAw aW4iPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJiYWNrZ3JvdW5kOndoaXRl Ij48Yj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtUYWhv bWEmcXVvdDssc2Fucy1zZXJpZiI+RnJvbTo8L3NwYW4+PC9iPjxzcGFuIGNsYXNzPSJhcHBsZS1j b252ZXJ0ZWQtc3BhY2UiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5 OiZxdW90O1RhaG9tYSZxdW90OyxzYW5zLXNlcmlmIj4mbmJzcDs8L3NwYW4+PC9zcGFuPjxzcGFu IHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O1RhaG9tYSZxdW90Oyxz YW5zLXNlcmlmIj5Bc3ZlcmVuLA0KIFRvbGdhIFs8YSBocmVmPSJtYWlsdG86dGFzdmVyZW5Ac29u dXNuZXQuY29tIj48c3BhbiBzdHlsZT0iY29sb3I6cHVycGxlIj5tYWlsdG86dGFzdmVyZW5Ac29u dXNuZXQuY29tPC9zcGFuPjwvYT5dPHNwYW4gY2xhc3M9ImFwcGxlLWNvbnZlcnRlZC1zcGFjZSI+ Jm5ic3A7PC9zcGFuPjxicj4NCjxiPlNlbnQ6PC9iPjxzcGFuIGNsYXNzPSJhcHBsZS1jb252ZXJ0 ZWQtc3BhY2UiPiZuYnNwOzwvc3Bhbj42LiBlbG9rdXV0YSAyMDE1IDEyOjE4PGJyPg0KPGI+VG86 PC9iPjxzcGFuIGNsYXNzPSJhcHBsZS1jb252ZXJ0ZWQtc3BhY2UiPiZuYnNwOzwvc3Bhbj5TY2h3 YXJ6LCBBbGJyZWNodCAoQWxicmVjaHQpOyBSb21hbiBTaHBvdW50OyBSYXVzY2hlbmJhY2gsIFV3 ZSAoTm9raWEgLSBERS9NdW5pY2gpPGJyPg0KPGI+Q2M6PC9iPjxzcGFuIGNsYXNzPSJhcHBsZS1j b252ZXJ0ZWQtc3BhY2UiPiZuYnNwOzwvc3Bhbj5leHQgRXJpYyBSZXNjb3JsYTsgQ2hyaXN0ZXIg SG9sbWJlcmc7IEJlcm5hcmQgQWJvYmE7ICZsdDs8YSBocmVmPSJtYWlsdG86cnRjd2ViQGlldGYu b3JnIj48c3BhbiBzdHlsZT0iY29sb3I6cHVycGxlIj5ydGN3ZWJAaWV0Zi5vcmc8L3NwYW4+PC9h PiZndDs8YnI+DQo8Yj5TdWJqZWN0OjwvYj48c3BhbiBjbGFzcz0iYXBwbGUtY29udmVydGVkLXNw YWNlIj4mbmJzcDs8L3NwYW4+UmU6IFtydGN3ZWJdIFdoYXQgdGhlIGdhdGV3YXkgZHJhZnQgc2hv dWxkIHNheSBhYm91dCBtdXgvbm9uLW11eDwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0K PC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0iYmFja2dy b3VuZDp3aGl0ZSI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXYgaWQ9ImRpdnRh Z2RlZmF1bHR3cmFwcGVyIj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0iYmFj a2dyb3VuZDp3aGl0ZSI+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVv dDssc2Fucy1zZXJpZiI+V2h5IHNob3VsZCB3ZSBjb25zaWRlciAzR1BQIHRoZSBzb2xlICZxdW90 O293bmVyL3VzZXImcXVvdDsgb2YgdGhlIHRlcm0vZW50aXR5IFdlYlJUQy1HVz8gSSB0aGluayBp dCBoYXMgYSBtdWNoIG1vcmUgZ2VuZXJhbCBtZWFuaW5nIGFuZCB1c2UgaW4gcHJhY3RpY2UuIEl0 IGNhbiByZWZlciB0byBtYW55DQogZGlmZmVyZW50IHR5cGVzIG9mIGVsZW1lbnRzIHdoaWNoIGNh biBiZSBkZXBsb3llZCBpbiBtYW55IGRpZmZlcmVudCBlbnZpcm9ubWVudHMsIGhlbmNlIGFueSBh dHRlbXB0IHRvIGRlZmluZSBpdCBzdHJpY3RseS9yZXN0cmljdCBpdHMgY2FwYWJpbGl0aWVzIGFy ZSBmdXRpbGUgSU1ITy48L3NwYW4+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0iYmFja2dyb3VuZDp3aGl0ZSI+PHNwYW4gc3R5bGU9ImZv bnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZiI+Jm5ic3A7PC9zcGFuPjxv OnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9 ImJhY2tncm91bmQ6d2hpdGUiPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtDYWxpYnJp JnF1b3Q7LHNhbnMtc2VyaWYiPlRoYW5rcyw8L3NwYW4+PG86cD48L286cD48L3A+DQo8L2Rpdj4N CjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0iYmFja2dyb3VuZDp3aGl0ZSI+PHNw YW4gc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZiI+VG9s Z2E8L3NwYW4+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIiBzdHlsZT0iYmFja2dyb3VuZDp3aGl0ZSI+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiZx dW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZiI+Jm5ic3A7PC9zcGFuPjxvOnA+PC9vOnA+PC9w Pg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdiBjbGFzcz0iTXNvTm9ybWFsIiBhbGlnbj0iY2VudGVyIiBz dHlsZT0idGV4dC1hbGlnbjpjZW50ZXI7YmFja2dyb3VuZDp3aGl0ZSI+DQo8c3BhbiBzdHlsZT0i Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmIj4NCjxociBzaXplPSIy IiB3aWR0aD0iOTglIiBhbGlnbj0iY2VudGVyIj4NCjwvc3Bhbj48L2Rpdj4NCjxkaXYgaWQ9ImRp dlJwbHlGd2RNc2ciPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJiYWNrZ3Jv dW5kOndoaXRlIj48Yj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTom cXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWYiPkZyb206PC9zcGFuPjwvYj48c3BhbiBjbGFz cz0iYXBwbGUtY29udmVydGVkLXNwYWNlIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtm b250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWYiPiZuYnNwOzwvc3Bhbj48 L3NwYW4+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2Fs aWJyaSZxdW90OyxzYW5zLXNlcmlmIj5TY2h3YXJ6LA0KIEFsYnJlY2h0IChBbGJyZWNodCkgJmx0 OzxhIGhyZWY9Im1haWx0bzphbGJyZWNodC5zY2h3YXJ6QGFsY2F0ZWwtbHVjZW50LmNvbSI+PHNw YW4gc3R5bGU9ImNvbG9yOnB1cnBsZSI+YWxicmVjaHQuc2Nod2FyekBhbGNhdGVsLWx1Y2VudC5j b208L3NwYW4+PC9hPiZndDs8YnI+DQo8Yj5TZW50OjwvYj48c3BhbiBjbGFzcz0iYXBwbGUtY29u dmVydGVkLXNwYWNlIj4mbmJzcDs8L3NwYW4+VGh1cnNkYXksIEF1Z3VzdCA2LCAyMDE1IDI6NDQg QU08YnI+DQo8Yj5Ubzo8L2I+PHNwYW4gY2xhc3M9ImFwcGxlLWNvbnZlcnRlZC1zcGFjZSI+Jm5i c3A7PC9zcGFuPkFzdmVyZW4sIFRvbGdhOyBSb21hbiBTaHBvdW50OyBSYXVzY2hlbmJhY2gsIFV3 ZSAoTm9raWEgLSBERS9NdW5pY2gpPGJyPg0KPGI+Q2M6PC9iPjxzcGFuIGNsYXNzPSJhcHBsZS1j b252ZXJ0ZWQtc3BhY2UiPiZuYnNwOzwvc3Bhbj5leHQgRXJpYyBSZXNjb3JsYTsgQ2hyaXN0ZXIg SG9sbWJlcmc7IEJlcm5hcmQgQWJvYmE7ICZsdDs8YSBocmVmPSJtYWlsdG86cnRjd2ViQGlldGYu b3JnIj48c3BhbiBzdHlsZT0iY29sb3I6cHVycGxlIj5ydGN3ZWJAaWV0Zi5vcmc8L3NwYW4+PC9h PiZndDs8YnI+DQo8Yj5TdWJqZWN0OjwvYj48c3BhbiBjbGFzcz0iYXBwbGUtY29udmVydGVkLXNw YWNlIj4mbmJzcDs8L3NwYW4+UkU6IFtydGN3ZWJdIFdoYXQgdGhlIGdhdGV3YXkgZHJhZnQgc2hv dWxkIHNheSBhYm91dCBtdXgvbm9uLW11eDwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0K PGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0iYmFja2dyb3VuZDp3aGl0 ZSI+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJp ZiI+Jm5ic3A7PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0K PGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9ImJhY2tncm91 bmQ6d2hpdGUiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OkNvbnNv bGFzO2NvbG9yOiMxRjQ5N0QiPlRoZSBjb25jZXJuZWQgM0dQUCBXZWJSVEMgZ2F0ZXdheSAoM0dQ UCAyMy4zMzQvMjkuMzM0KSBzdXBwb3J0cyBhbHJlYWR5IFJUUC9SVENQIHRyYW5zcG9ydCBtdWx0 aXBsZXhpbmcgKHNpbmNlIDNHUFAgUmVsZWFzZSAxMiksIGkuZS4gc2hvdWxkIG5vdA0KIGJlIHRo ZSBsaW1pdGluZyBmYWN0b3IgaW4gdGhpcyBkaXNjdXNzaW9uLjxzcGFuIGNsYXNzPSJhcHBsZS1j b252ZXJ0ZWQtc3BhY2UiPiZuYnNwOzwvc3Bhbj48L3NwYW4+PG86cD48L286cD48L3A+DQo8L2Rp dj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0iYmFja2dyb3VuZDp3aGl0ZSI+ PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6Q29uc29sYXM7Y29sb3I6 IzFGNDk3RCI+Rm9yIG9uZXMgaW50ZXJlc3RlZCBpbiB0aGUgUlRDUCBwb3J0IGFsbG9jYXRpb24g cnVsZXMsIHNlZSBILjI0OC41Nzo8L3NwYW4+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0iYmFja2dyb3VuZDp3aGl0ZSI+PHNwYW4gc3R5 bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6Q29uc29sYXM7Y29sb3I6IzFGNDk3RCI+ PGEgaHJlZj0iaHR0cHM6Ly93d3cuaXR1LmludC9yZWMvZG9sb2dpbl9wdWIuYXNwP2xhbmc9ZSZh bXA7aWQ9VC1SRUMtSC4yNDguNTctMjAxNDEwLUkhIVBERi1FJmFtcDt0eXBlPWl0ZW1zIiB0aXRs ZT0iQ21kJiM0MztDbGljayBvciB0YXAgdG8gZm9sbG93IHRoZSBsaW5rIj48c3BhbiBzdHlsZT0i Y29sb3I6cHVycGxlIj5odHRwczovL3d3dy5pdHUuaW50L3JlYy9kb2xvZ2luX3B1Yi5hc3A/bGFu Zz1lJmFtcDtpZD1ULVJFQy1ILjI0OC41Ny0yMDE0MTAtSSEhUERGLUUmYW1wO3R5cGU9aXRlbXM8 L3NwYW4+PC9hPjwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiIHN0eWxlPSJiYWNrZ3JvdW5kOndoaXRlIj48c3BhbiBzdHlsZT0iZm9udC1z aXplOjExLjBwdDtmb250LWZhbWlseTpDb25zb2xhcztjb2xvcjojMUY0OTdEIj5DbGF1c2UgNyBk ZXNjcmliZXMgUlRQL1JUQ1AgdHJhbnNwb3J0IG11bHRpcGxleGluZy4gSVRVLVQgSC4yNDguNTcg aXMgYWxyZWFkeSBzdXBwb3J0ZWQgYnkgM0dQUCAyOS4zMzQuPC9zcGFuPjxvOnA+PC9vOnA+PC9w Pg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9ImJhY2tncm91bmQ6 d2hpdGUiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OkNvbnNvbGFz O2NvbG9yOiMxRjQ5N0QiPiZuYnNwOzwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRp dj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJiYWNrZ3JvdW5kOndoaXRlIj48c3BhbiBz dHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTpDb25zb2xhcztjb2xvcjojMUY0OTdE Ij5UaGUgcmF0aW9uYWxlIGJlaGluZCB0aGUg4oCcb3B0aW9uYWwgdGFnZ2luZ+KAnSBieSAyMy4y MjggaXMgYSB0aGlyZCByZWFzb24sIGJleW9uZDwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2 Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJiYWNrZ3JvdW5kOndoaXRlIj48 c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmIj4m Z3Q7MS4gVXNpbmcgZGlmZmVyZW50IFFPUyBzZXR0aW5ncyBmb3IgUlRDUCB2cyBSVFA8L3NwYW4+ PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHls ZT0iYmFja2dyb3VuZDp3aGl0ZSI+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O0NhbGli cmkmcXVvdDssc2Fucy1zZXJpZiI+Jmd0OzIuIFNlbmRpbmcgUlRDUCB0byBhIGRpZmZlcmVudCBk ZXZpY2UgZnJvbSBSVFA8L3NwYW4+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0iYmFja2dyb3VuZDp3aGl0ZSI+PHNwYW4gc3R5bGU9ImZv bnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6Q29uc29sYXM7Y29sb3I6IzFGNDk3RCI+Jm5ic3A7 PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1h bCIgc3R5bGU9ImJhY2tncm91bmQ6d2hpdGUiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0 O2ZvbnQtZmFtaWx5OkNvbnNvbGFzO2NvbG9yOiMxRjQ5N0QiPkRvbuKAmXQgd2FudCB0byBnbyBp biB0aGUgM0dQUCBzcGVjaWZpYyBkZXRhaWxzLCBidXQgaXQgaGFzIG5vdGhpbmcgdG8gZG8gd2l0 aCB0aGUgM0dQUCBVRS1lbWJlZGRlZCBXZWJSVEMgY2xpZW50IG5vciBhbnkgY29uc3RyYWludHMg YnkgM0dQUCBXZWJSVEMNCiBnYXRld2F5cy48L3NwYW4+PG86cD48L286cD48L3A+DQo8L2Rpdj4N CjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0iYmFja2dyb3VuZDp3aGl0ZSI+PHNw YW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6Q29uc29sYXM7Y29sb3I6IzFG NDk3RCI+Jm5ic3A7PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xh c3M9Ik1zb05vcm1hbCIgc3R5bGU9ImJhY2tncm91bmQ6d2hpdGUiPjxzcGFuIHN0eWxlPSJmb250 LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OkNvbnNvbGFzO2NvbG9yOiMxRjQ5N0QiPlRodXMsIGEg V2ViUlRDIGdhdGV3YXkgTVVTVCBzdXBwb3J0IFJUUC9SVENQIHRyYW5zcG9ydCBtdWx0aXBsZXhp bmcgZHVlIHRvIGl0cyBwdXJwb3NlIGluIGludGVyd29ya2luZyBzdXBwb3J0Ljwvc3Bhbj48bzpw PjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJi YWNrZ3JvdW5kOndoaXRlIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWls eTpDb25zb2xhcztjb2xvcjojMUY0OTdEIj4mbmJzcDs8L3NwYW4+PG86cD48L286cD48L3A+DQo8 L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0iYmFja2dyb3VuZDp3aGl0 ZSI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6Q29uc29sYXM7Y29s b3I6IzFGNDk3RCI+UmVnYXJkcyw8L3NwYW4+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0iYmFja2dyb3VuZDp3aGl0ZSI+PHNwYW4gc3R5 bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6Q29uc29sYXM7Y29sb3I6IzFGNDk3RCI+ QWxicmVjaHQ8L3NwYW4+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIiBzdHlsZT0iYmFja2dyb3VuZDp3aGl0ZSI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6 ZToxMS4wcHQ7Zm9udC1mYW1pbHk6Q29uc29sYXM7Y29sb3I6IzFGNDk3RCI+Jm5ic3A7PC9zcGFu PjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5 bGU9ImJhY2tncm91bmQ6d2hpdGUiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQt ZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEIj4mbmJz cDs8L3NwYW4+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2IHN0eWxlPSJib3Jk ZXI6bm9uZTtib3JkZXItdG9wOnNvbGlkICNCNUM0REYgMS4wcHQ7cGFkZGluZzozLjBwdCAwaW4g MGluIDBpbiI+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9ImJhY2tncm91bmQ6 d2hpdGUiPjxiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90 O1RhaG9tYSZxdW90OyxzYW5zLXNlcmlmIj5Gcm9tOjwvc3Bhbj48L2I+PHNwYW4gY2xhc3M9ImFw cGxlLWNvbnZlcnRlZC1zcGFjZSI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1m YW1pbHk6JnF1b3Q7VGFob21hJnF1b3Q7LHNhbnMtc2VyaWYiPiZuYnNwOzwvc3Bhbj48L3NwYW4+ PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7VGFob21hJnF1 b3Q7LHNhbnMtc2VyaWYiPkFzdmVyZW4sDQogVG9sZ2EgWzxhIGhyZWY9Im1haWx0bzp0YXN2ZXJl bkBzb251c25ldC5jb20iPjxzcGFuIHN0eWxlPSJjb2xvcjpwdXJwbGUiPm1haWx0bzp0YXN2ZXJl bkBzb251c25ldC5jb208L3NwYW4+PC9hPl08c3BhbiBjbGFzcz0iYXBwbGUtY29udmVydGVkLXNw YWNlIj4mbmJzcDs8L3NwYW4+PGJyPg0KPGI+U2VudDo8L2I+PHNwYW4gY2xhc3M9ImFwcGxlLWNv bnZlcnRlZC1zcGFjZSI+Jm5ic3A7PC9zcGFuPk1pdHR3b2NoLCA1LiBBdWd1c3QgMjAxNSAxOTo0 Nzxicj4NCjxiPlRvOjwvYj48c3BhbiBjbGFzcz0iYXBwbGUtY29udmVydGVkLXNwYWNlIj4mbmJz cDs8L3NwYW4+Um9tYW4gU2hwb3VudDsgUmF1c2NoZW5iYWNoLCBVd2UgKE5va2lhIC0gREUvTXVu aWNoKTxicj4NCjxiPkNjOjwvYj48c3BhbiBjbGFzcz0iYXBwbGUtY29udmVydGVkLXNwYWNlIj4m bmJzcDs8L3NwYW4+ZXh0IEVyaWMgUmVzY29ybGE7IFNjaHdhcnosIEFsYnJlY2h0IChBbGJyZWNo dCk7IENocmlzdGVyIEhvbG1iZXJnOyBCZXJuYXJkIEFib2JhOyAmbHQ7PGEgaHJlZj0ibWFpbHRv OnJ0Y3dlYkBpZXRmLm9yZyI+PHNwYW4gc3R5bGU9ImNvbG9yOnB1cnBsZSI+cnRjd2ViQGlldGYu b3JnPC9zcGFuPjwvYT4mZ3Q7PGJyPg0KPGI+U3ViamVjdDo8L2I+PHNwYW4gY2xhc3M9ImFwcGxl LWNvbnZlcnRlZC1zcGFjZSI+Jm5ic3A7PC9zcGFuPlJFOiBbcnRjd2ViXSBXaGF0IHRoZSBnYXRl d2F5IGRyYWZ0IHNob3VsZCBzYXkgYWJvdXQgbXV4L25vbi1tdXg8L3NwYW4+PG86cD48L286cD48 L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIg c3R5bGU9ImJhY2tncm91bmQ6d2hpdGUiPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtD YWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWYiPiZuYnNwOzwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwv ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJiYWNrZ3JvdW5kOndoaXRl Ij48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJp JnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RCI+aS0gSSBodW1ibHkgZGlzYWdyZWUgdGhh dCB1c2luZyBkaWZmZXJlbnQgUW9TIFJUQ1AvUlRQLCBlLmcuIGRpZmZlcmVudCBEaWZmU2VydiB2 YWx1ZXMgLCBzaG91bGQgYmUgZGlzbWlzc2VkLjwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2 Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJiYWNrZ3JvdW5kOndoaXRlIj48 c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1 b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RCI+aWktIExldCBtZSBhbHNvIGFkZCBhbm90aGVy IHJlYXNvbiB3aHkgbm8tcnRjcC1tdXggbWF5IGJlIG5lZWRlZDogSW1wbGVtZW50YXRpb24gZGlm ZmljdWx0aWVzIGluIGNlcnRhaW4gR1dzLjwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0K PGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJiYWNrZ3JvdW5kOndoaXRlIj48c3Bh biBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7 LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RCI+Jm5ic3A7PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0K PC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9ImJhY2tncm91bmQ6d2hp dGUiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGli cmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEIj5Db25zaWRlcmluZyB0aGF0IHRoZXJl IGlzIGFscmVhZHkgYSBuZWdvdGlhdGlvbiBtZWNoYW5pc20gZm9yIHJ0Y3AtbXV4IHN1cHBvcnQs IHRoYXQgaXQgY2FuIGJlIGRlLWZhY3RvIG1hbmRhdGVkIGJ5IHRoZSBjaG9pY2Ugb2YgYnJvd3Nl cnMNCiBmb3IgSW50ZXJuZXQsIEkgdGhpbmsgd2hhdCBDaHJpc3Rlci9BbGJyZWNodCBzdWdnZXN0 ZWQgaXMgdGhlIHJpZ2h0IHdheSB0byBtb3ZlIGZvcndhcmQ6IHByb3ZpZGUgY2xhcmlmaWNhdGlv bnMgZm9yIHZhZ3VlIHBvaW50cy4gSSBkb27igJl0IHVuZGVyc3RhbmQgd2h5IGxhY2sgb2YgY2xh cml0eSBpbiBleGlzdGluZyBzcGVjaWZpY2F0aW9ucyBzaG91bGQgY2F1c2UgaW1wb3NpbmcgcmVz dHJpY3Rpb25zLiBUaGlzIHdvdWxkIGJlIGFraW4gdG8gZHJvcHBpbmcNCiBhIGZlYXR1cmUgZHVl IHRvIGEgYnVnLiBJbiB0aGlzIGNhc2UsIHRoZSDigJxidWfigJ0gaXMgbGFjayBvZiBjbGFyaXR5 IGluIG5vcm1hdGl2ZSBzcGVjaWZpY2F0aW9ucyBhbmQgaXQgY2FuIGJlIGFkZHJlc3NlZCBieSBm dXJ0aGVyIHNwZWNpZmljYXRpb24uPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2 Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9ImJhY2tncm91bmQ6d2hpdGUiPjxzcGFuIHN0 eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fu cy1zZXJpZjtjb2xvcjojMUY0OTdEIj4mbmJzcDs8L3NwYW4+PG86cD48L286cD48L3A+DQo8L2Rp dj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0iYmFja2dyb3VuZDp3aGl0ZSI+ PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZx dW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0QiPlRoYW5rcyw8L3NwYW4+PG86cD48L286cD48 L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0iYmFja2dyb3Vu ZDp3aGl0ZSI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7 Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0QiPlRvbGdhPC9zcGFuPjxvOnA+ PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9ImJh Y2tncm91bmQ6d2hpdGUiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5 OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEIj4mbmJzcDs8L3Nw YW4+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXYgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRl ci1sZWZ0OnNvbGlkIGJsdWUgMS41cHQ7cGFkZGluZzowaW4gMGluIDBpbiA0LjBwdCI+DQo8ZGl2 Pg0KPGRpdiBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLXRvcDpzb2xpZCAjRTFFMUUxIDEuMHB0 O3BhZGRpbmc6My4wcHQgMGluIDBpbiAwaW4iPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi IHN0eWxlPSJiYWNrZ3JvdW5kOndoaXRlIj48Yj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBw dDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWYiPkZyb206PC9zcGFu PjwvYj48c3BhbiBjbGFzcz0iYXBwbGUtY29udmVydGVkLXNwYWNlIj48c3BhbiBzdHlsZT0iZm9u dC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWYi PiZuYnNwOzwvc3Bhbj48L3NwYW4+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1m YW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmIj5Sb21hbg0KIFNocG91bnQgWzxh IGhyZWY9Im1haWx0bzpyb21hbkB0ZWx1cml4LmNvbSI+PHNwYW4gc3R5bGU9ImNvbG9yOnB1cnBs ZSI+bWFpbHRvOnJvbWFuQHRlbHVyaXguY29tPC9zcGFuPjwvYT5dPHNwYW4gY2xhc3M9ImFwcGxl LWNvbnZlcnRlZC1zcGFjZSI+Jm5ic3A7PC9zcGFuPjxicj4NCjxiPlNlbnQ6PC9iPjxzcGFuIGNs YXNzPSJhcHBsZS1jb252ZXJ0ZWQtc3BhY2UiPiZuYnNwOzwvc3Bhbj5XZWRuZXNkYXksIEF1Z3Vz dCAwNSwgMjAxNSAxMjoyOSBQTTxicj4NCjxiPlRvOjwvYj48c3BhbiBjbGFzcz0iYXBwbGUtY29u dmVydGVkLXNwYWNlIj4mbmJzcDs8L3NwYW4+UmF1c2NoZW5iYWNoLCBVd2UgKE5va2lhIC0gREUv TXVuaWNoKSAmbHQ7PGEgaHJlZj0ibWFpbHRvOnV3ZS5yYXVzY2hlbmJhY2hAbm9raWEuY29tIj48 c3BhbiBzdHlsZT0iY29sb3I6cHVycGxlIj51d2UucmF1c2NoZW5iYWNoQG5va2lhLmNvbTwvc3Bh bj48L2E+Jmd0Ozxicj4NCjxiPkNjOjwvYj48c3BhbiBjbGFzcz0iYXBwbGUtY29udmVydGVkLXNw YWNlIj4mbmJzcDs8L3NwYW4+ZXh0IEVyaWMgUmVzY29ybGEgJmx0OzxhIGhyZWY9Im1haWx0bzpl a3JAcnRmbS5jb20iPjxzcGFuIHN0eWxlPSJjb2xvcjpwdXJwbGUiPmVrckBydGZtLmNvbTwvc3Bh bj48L2E+Jmd0OzsgU2Nod2FyeiwgQWxicmVjaHQgKEFsYnJlY2h0KSAmbHQ7PGEgaHJlZj0ibWFp bHRvOmFsYnJlY2h0LnNjaHdhcnpAYWxjYXRlbC1sdWNlbnQuY29tIj48c3BhbiBzdHlsZT0iY29s b3I6cHVycGxlIj5hbGJyZWNodC5zY2h3YXJ6QGFsY2F0ZWwtbHVjZW50LmNvbTwvc3Bhbj48L2E+ Jmd0OzsNCiBBc3ZlcmVuLCBUb2xnYSAmbHQ7PGEgaHJlZj0ibWFpbHRvOnRhc3ZlcmVuQHNvbnVz bmV0LmNvbSI+PHNwYW4gc3R5bGU9ImNvbG9yOnB1cnBsZSI+dGFzdmVyZW5Ac29udXNuZXQuY29t PC9zcGFuPjwvYT4mZ3Q7OyBDaHJpc3RlciBIb2xtYmVyZyAmbHQ7PGEgaHJlZj0ibWFpbHRvOmNo cmlzdGVyLmhvbG1iZXJnQGVyaWNzc29uLmNvbSI+PHNwYW4gc3R5bGU9ImNvbG9yOnB1cnBsZSI+ Y2hyaXN0ZXIuaG9sbWJlcmdAZXJpY3Nzb24uY29tPC9zcGFuPjwvYT4mZ3Q7OyBCZXJuYXJkDQog QWJvYmEgJmx0OzxhIGhyZWY9Im1haWx0bzpiZXJuYXJkLmFib2JhQGdtYWlsLmNvbSI+PHNwYW4g c3R5bGU9ImNvbG9yOnB1cnBsZSI+YmVybmFyZC5hYm9iYUBnbWFpbC5jb208L3NwYW4+PC9hPiZn dDs7ICZsdDs8YSBocmVmPSJtYWlsdG86cnRjd2ViQGlldGYub3JnIj48c3BhbiBzdHlsZT0iY29s b3I6cHVycGxlIj5ydGN3ZWJAaWV0Zi5vcmc8L3NwYW4+PC9hPiZndDsgJmx0OzxhIGhyZWY9Im1h aWx0bzpydGN3ZWJAaWV0Zi5vcmciPjxzcGFuIHN0eWxlPSJjb2xvcjpwdXJwbGUiPnJ0Y3dlYkBp ZXRmLm9yZzwvc3Bhbj48L2E+Jmd0Ozxicj4NCjxiPlN1YmplY3Q6PC9iPjxzcGFuIGNsYXNzPSJh cHBsZS1jb252ZXJ0ZWQtc3BhY2UiPiZuYnNwOzwvc3Bhbj5SZTogW3J0Y3dlYl0gV2hhdCB0aGUg Z2F0ZXdheSBkcmFmdCBzaG91bGQgc2F5IGFib3V0IG11eC9ub24tbXV4PC9zcGFuPjxvOnA+PC9v OnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiIHN0eWxlPSJiYWNrZ3JvdW5kOndoaXRlIj48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1 b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmIj4mbmJzcDs8L3NwYW4+PG86cD48L286cD48L3A+ DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFs IiBzdHlsZT0iYmFja2dyb3VuZDp3aGl0ZSI+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90 O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZiI+T24gV2VkLCBBdWcgNSwgMjAxNSBhdCA0OjQ3IEFN LCBSYXVzY2hlbmJhY2gsIFV3ZSAoTm9raWEgLSBERS9NdW5pY2gpICZsdDs8YSBocmVmPSJtYWls dG86dXdlLnJhdXNjaGVuYmFjaEBub2tpYS5jb20iIHRhcmdldD0iX2JsYW5rIj48c3BhbiBzdHls ZT0iY29sb3I6cHVycGxlIj51d2UucmF1c2NoZW5iYWNoQG5va2lhLmNvbTwvc3Bhbj48L2E+Jmd0 Ow0KIHdyb3RlOjwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGJsb2NrcXVvdGUgc3R5 bGU9ImJvcmRlcjpub25lO2JvcmRlci1sZWZ0OnNvbGlkICNDQ0NDQ0MgMS4wcHQ7cGFkZGluZzow aW4gMGluIDBpbiA2LjBwdDttYXJnaW4tbGVmdDo0LjhwdDttYXJnaW4tdG9wOjUuMHB0O21hcmdp bi1yaWdodDowaW47bWFyZ2luLWJvdHRvbTo1LjBwdCI+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0iYmFja2dyb3VuZDp3aGl0ZSI+PHNwYW4gc3R5bGU9 ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDssc2Fucy1zZXJp ZiI+TWVkaWEgZ2F0ZXdheSBpbXBsZW1lbnRhdGlvbnMgYWNjb3JkaW5nIHRvIDNHUFAgVFMgMjMu MjI4PC9zcGFuPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90 O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEIj4mbmJzcDs8L3NwYW4+PHNw YW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDss c2Fucy1zZXJpZiI+bWF5DQogbm90IHN1cHBvcnQgcnRjcC1tdXgsIGFzIHJ0Y3AtbXV4IGlzIG9w dGlvbmFsIHRoZXJlLjwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxkaXY+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0iYmFja2dyb3VuZDp3aGl0ZSI+PHNwYW4gc3R5 bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDssc2Fucy1z ZXJpZiI+U28gaWYgd2UgZHJvcCBub24tbXV4IHN1cHBvcnQgZnJvbSB3ZWIgYnJvd3NlcnMsIHRo b3NlIG1lZGlhIGdhdGV3YXlzIHRoYXQgaGF2ZSBub3QgaW1wbGVtZW50ZWQgcnRjcC1tdXggd2ls bCBzdG9wIGludGVyb3BlcmF0aW5nLiZuYnNwOzwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2 Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJiYWNrZ3JvdW5kOndoaXRlIj48 c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmIj4m bmJzcDs8L3NwYW4+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rp dj4NCjwvYmxvY2txdW90ZT4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5 bGU9ImJhY2tncm91bmQ6d2hpdGUiPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtDYWxp YnJpJnF1b3Q7LHNhbnMtc2VyaWYiPiZuYnNwOzwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2 Pg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJiYWNr Z3JvdW5kOndoaXRlIj48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90 OyxzYW5zLXNlcmlmIj5GaXJzdCBvZiBhbGwsIGRvIHlvdSBrbm93IG9mIGFueSBXZWJSVEMgdG8g SU1TIGdhdGV3YXlzIHRoYXQgZG8gbm90IGltcGxlbWVudCBydGNwLW11eCBvbiB0aGUgV2ViUlRD IHNpZGU/IEkgc3Ryb25nbHkgc3VzcGVjdCB0aGVyZSBhcmUgbm9uZS48L3NwYW4+PG86cD48L286 cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFs IiBzdHlsZT0iYmFja2dyb3VuZDp3aGl0ZSI+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90 O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZiI+Jm5ic3A7PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0K PC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9 ImJhY2tncm91bmQ6d2hpdGUiPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtDYWxpYnJp JnF1b3Q7LHNhbnMtc2VyaWYiPlNlY29uZCwgdGhlIG9ubHkgcmVhc29ucyBub3QgdG8gdXNlIHJ0 Y3AtbXV4IHRoYXQgSSBjYW4gdGhpbmsgb2YgYXJlIHRoZSBmb2xsb3dpbmc6PC9zcGFuPjxvOnA+ PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05v cm1hbCIgc3R5bGU9ImJhY2tncm91bmQ6d2hpdGUiPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTom cXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWYiPiZuYnNwOzwvc3Bhbj48bzpwPjwvbzpwPjwv cD4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0 eWxlPSJiYWNrZ3JvdW5kOndoaXRlIj48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7Q2Fs aWJyaSZxdW90OyxzYW5zLXNlcmlmIj4xLiBVc2luZyBkaWZmZXJlbnQgUU9TIHNldHRpbmdzIGZv ciBSVENQIHZzIFJUUDwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2 Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJiYWNrZ3JvdW5kOndoaXRlIj48 c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmIj4y LiBTZW5kaW5nIFJUQ1AgdG8gYSBkaWZmZXJlbnQgZGV2aWNlIGZyb20gUlRQPC9zcGFuPjxvOnA+ PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05v cm1hbCIgc3R5bGU9ImJhY2tncm91bmQ6d2hpdGUiPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTom cXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWYiPiZuYnNwOzwvc3Bhbj48bzpwPjwvbzpwPjwv cD4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0 eWxlPSJiYWNrZ3JvdW5kOndoaXRlIj48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7Q2Fs aWJyaSZxdW90OyxzYW5zLXNlcmlmIj5JIGRvIG5vdCB0aGluayB0aGUgZmlyc3QgdXNlIGNhc2Ug d2FycmFudHMgbWFraW5nIHJ0Y3AtbXV4IG9wdGlvbmFsLCBzaW5jZSwgcHJhY3RpY2FsbHkgbm8g b25lIGRvZXMgdGhpcy48L3NwYW4+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRp dj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0iYmFja2dyb3VuZDp3aGl0ZSI+ PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZiI+ U2Vjb25kIHVzZSBjYXNlIGlzIGFsc28gZmFpcmx5IG1hcmdpbmFsLiBQbHVzIGl0IGNhbiBiZSBo YW5kbGVkIGJ5IHRoZSBnYXRld2F5IHdoaWNoIGNhbiBzZW5kIFJUQ1AgdG8gb25lIGRldmljZSBh bmQgUlRQIHRvIGFub3RoZXIuPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4N CjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9ImJhY2tncm91bmQ6d2hp dGUiPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2Vy aWYiPiZuYnNwOzwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0K PGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJiYWNrZ3JvdW5kOndoaXRlIj48c3Bh biBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmIj5Tbywg dW5sZXNzIHNvbWVvbmUgY2FuIGNvbWUgdXAgd2l0aCBhIHVzZSBjYXNlIHdoeSBSVFAgYW5kIFJU Q1Agc2hvdWxkIHVzZSBkaWZmZXJlbnQgdHJhbnNwb3J0cywgSSB0aGluayBydGNwLW11eCBzaG91 bGQgYmUgbWFuZGF0b3J5Ljwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8 ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJiYWNrZ3JvdW5kOndoaXRl Ij48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlm Ij4mbmJzcDs8L3NwYW4+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxk aXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0iYmFja2dyb3VuZDp3aGl0ZSI+PHNwYW4g c3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZiI+UmVnYXJk cyw8L3NwYW4+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxkaXY+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0iYmFja2dyb3VuZDp3aGl0ZSI+PHNwYW4gc3R5bGU9 ImZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZiI+X19fX19fX19fX19f X188L3NwYW4+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxkaXY+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0iYmFja2dyb3VuZDp3aGl0ZSI+PHNwYW4gc3R5bGU9 ImZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZiI+Um9tYW4gU2hwb3Vu dDwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0K PC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8 L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFu IHN0eWxlPSJmb250LXNpemU6OS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7SGVsdmV0aWNhJnF1b3Q7 LHNhbnMtc2VyaWYiPl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fPGJyPg0KcnRjd2ViIG1haWxpbmcgbGlzdDxicj4NCjxhIGhyZWY9Im1haWx0bzpydGN3ZWJA aWV0Zi5vcmciPnJ0Y3dlYkBpZXRmLm9yZzwvYT48YnI+DQo8YSBocmVmPSJodHRwczovL3d3dy5p ZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL3J0Y3dlYiI+aHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFp bG1hbi9saXN0aW5mby9ydGN3ZWI8L2E+PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8 L2Jsb2NrcXVvdGU+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPiZuYnNwOzxvOnA+PC9v OnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvYmxvY2tx dW90ZT4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+ DQo8L2Rpdj4NCjwvZGl2Pg0KPC9ib2R5Pg0KPC9odG1sPg0K --_000_SN1PR0301MB1551A79D0AA05593987D8109B2740SN1PR0301MB1551_-- From nobody Thu Aug 6 07:15:12 2015 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8485F1A0368; Thu, 6 Aug 2015 07:15:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.266 X-Spam-Level: X-Spam-Status: No, score=-2.266 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, IP_NOT_FRIENDLY=0.334, 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 qLXjGNd_vlBb; Thu, 6 Aug 2015 07:15:07 -0700 (PDT) Received: from mx0b-00198e01.pphosted.com (mx0b-00198e01.pphosted.com [67.231.157.197]) (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 292F51A002C; Thu, 6 Aug 2015 07:15:07 -0700 (PDT) Received: from pps.filterd (m0073110.ppops.net [127.0.0.1]) by mx0b-00198e01.pphosted.com (8.15.0.59/8.14.7) with SMTP id t76EAawV022509; Thu, 6 Aug 2015 10:15:01 -0400 Received: from mail.vidyo.com ([162.209.16.214]) by mx0b-00198e01.pphosted.com with ESMTP id 1w0h0utqxb-1 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Thu, 06 Aug 2015 10:15:00 -0400 Received: from 492132-EXCH1.vidyo.com ([fe80::50:56ff:fe85:4f77]) by 492133-EXCH2.vidyo.com ([fe80::50:56ff:fe85:6b62%13]) with mapi id 14.03.0195.001; Thu, 6 Aug 2015 09:14:59 -0500 From: Jonathan Lennox To: Justin Uberti Thread-Topic: [tram] [rtcweb] TURN permissions for private ips Thread-Index: AQHQ0FCLNCYkZhS0BUWVw9lyF0GfpZ3/V78A Date: Thu, 6 Aug 2015 14:14:59 +0000 Message-ID: References: <20150805130607.20844.70680.idtracker@ietfa.amsl.com> <55C24293.5000603@cs.tcd.ie> <55C24C09.8020404@goodadvice.pages.de> <55C256C8.80606@jive.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [198.200.77.253] Content-Type: multipart/alternative; boundary="_000_F144FF61AAC64E0AB08E0E3F9B487F1Bvidyocom_" MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:5.14.151, 1.0.33, 0.0.0000 definitions=2015-08-06_08:2015-08-06,2015-08-06,1970-01-01 signatures=0 X-Proofpoint-Spam-Details: rule=outbound_notspam policy=outbound score=0 spamscore=0 suspectscore=0 phishscore=0 adultscore=0 bulkscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=7.0.1-1506180000 definitions=main-1508060236 Archived-At: Cc: "rtcweb@ietf.org" , "tram@ietf.org" , mmusic Subject: Re: [rtcweb] [tram] TURN permissions for private ips X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 06 Aug 2015 14:15:10 -0000 --_000_F144FF61AAC64E0AB08E0E3F9B487F1Bvidyocom_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 DQpPbiBBdWcgNSwgMjAxNSwgYXQgNTozNSBQTSwgSnVzdGluIFViZXJ0aSA8anViZXJ0aUBnb29n bGUuY29tPG1haWx0bzpqdWJlcnRpQGdvb2dsZS5jb20+PiB3cm90ZToNCg0KT24gV2VkLCBBdWcg NSwgMjAxNSBhdCAxMTozMiBBTSwgU2ltb24gUGVycmVhdWx0IDxzcGVycmVhdWx0QGppdmUuY29t PG1haWx0bzpzcGVycmVhdWx0QGppdmUuY29tPj4gd3JvdGU6DQpMZSAyMDE1LTA4LTA1IDEzOjQ2 LCBQaGlsaXBwIEhhbmNrZSBhIMOpY3JpdCA6DQo+IElmIGEgcGVlciBzZW5kcyBjYW5kaWRhdGVz IHdpdGggSVAgYWRkcmVzc2VzIGZyb20gdGhlIHByaXZhdGUgc3BhY2UsDQo+IHBlcm1pc3Npb25z IGZvciB0aG9zZSBhcmUgY3JlYXRlZCBhdCB0aGUgVFVSTiBzZXJ2ZXIuIFBvdGVudGlhbGx5IG5v dA0KPiB1dGlsaXNpbmcgdHJhbnNwb3J0IGVuY3J5cHRpb24gZXZlbi4NCj4NCj4gSSBkb3VidCB0 aG9zZSBjYW5kaWRhdGVzIGV2ZXIgd29yaywgc28gZnJvbSBhIHByaXZhY3kgcG9pbnQgb2Ygdmll dyBpdA0KPiBzZWVtcyB0aGF0IGNsaWVudHMgc2hvdWxkIG5vdCBjcmVhdGUgdGhvc2UgcGVybWlz c2lvbnMgaW4gdGhlIGZpcnN0DQo+IHBsYWNlLiBBbmQgSUNFIHNob3VsZCBwcm9iYWJseSBub3Qg dHJ5IHRvIGNyZWF0ZSBwYWlycy4NCg0KSXQncyBub3QgdXAgdG8gdGhlIGNsaWVudCB0byBkZXRl cm1pbmUgd2hhdCBhZGRyZXNzZXMgbWlnaHQgbm90IG1pZ2h0DQpub3Qgd29yayBmb3IgYSBnaXZl biBUVVJOIHNlcnZlci4gVGhlcmUgYXJlIGxvdHMgb2Ygd2VpcmQgTkFUDQpjb25maWd1cmF0aW9u cyBvdXQgdGhlcmUgdGhhdCBwbGF5IGdhbWVzIHdpdGggUkZDMTkxOCBhZGRyZXNzZXMgYW5kIGNh bg0KZWFzaWx5IHRyaWNrIGNsaWVudHMgaW50byBkb2luZyB0aGUgd3JvbmcgdGhpbmcuDQoNCkkg YW0gc29tZXdoYXQgc3ltcGF0aGV0aWMgdG8gdGhhdCwgYnV0IGdpdmVuIHRoYXQgdGhlcmUgaXMg bWVhc3VyYWJsZSBkb3duc2lkZSBoZXJlIC0gZXh0cmEgY2FuZGlkYXRlIHBhaXJzIHRoYXQgdGFr ZSB0aW1lIHRvIGNoZWNrIC0gY2FuIHlvdSBzdXBwbHkgYSBjb25jcmV0ZSBleGFtcGxlIG9mIHdo ZXJlIHRoZSBjbGllbnQgY2hvb3Npbmcgbm90IHRvIHBhaXIgYSBUVVJOIGNhbmRpZGF0ZSB3aXRo IGEgUkZDMTkxOCBhZGRyZXNzIHdvdWxkIGNhdXNlIGEgcHJvYmxlbT8NCg0KVGhpcyBpcyByZWFs bHkgYW4gSUNFIHF1ZXN0aW9uLCBub3QgYSBUVVJOIHF1ZXN0aW9uLCBzbyBhZGRpbmcgTU1VU0lD Lg0KDQpDbGVhcmx5LCBpZiB5b3VyIFRVUk4gc2VydmVyIGlzIGFjdHVhbGx5IG9uIHRoZSBwdWJs aWMgaW50ZXJuZXQsIHBhaXJpbmcgUkZDMTkxOCBhZGRyZXNzIHdpdGggaXRzIGNhbmRpZGF0ZXMg d29u4oCZdCBkbyBhbnkgZ29vZC4gIEhvd2V2ZXIsIHRoZXJlIGNhbiBiZSBzY2VuYXJpb3Mgd2hl cmUgeW91IGhhdmUgYSBUVVJOIHNlcnZlciBzaXR0aW5nIGluIGEgRE1aIG9yIHRoZSBsaWtlLCB3 aGVyZSBpdCBjYW4gYWN0dWFsbHkgcm91dGUgdG8gUkZDIDE5MTggYWRkcmVzc2VzLiAgSSBzdXNw ZWN0IHRoaXMgd2lsbCBiZSByZWxldmFudCBpbiB0aGUgdmFyaW91cyBzY2VuYXJpb3Mgd2hlcmUg dGhlIFRVUk4gc2VydmVyIGlzIHRvcG9sb2dpY2FsbHkgZXF1aXZhbGVudCB0byBhIHdlYiBwcm94 eS4NCg0KQXMgSSByZWNhbGwgZnJvbSB0aGUgZGlzY3Vzc2lvbnMgYXJvdW5kIHRoZSBkZXZlbG9w bWVudCBvZiBJQ0UsIHRoZXJlIGFyZSBhY3R1YWxseSBhIGZhaXIgbnVtYmVyIG9mIG5ldHdvcmtz IG91dCB0aGVyZSB3aGljaCBoYXZlIHB1YmxpYyBJUHY0IGFuZCBSRkMxOTE4IGFkZHJlc3NlcyBk aXJlY3RseSByb3V0YWJsZSB0byBlYWNoIG90aGVyLiBUaGUgZXhhbXBsZXMgSSByZW1lbWJlciBj YW1lIGFib3V0IGFzIGEgcmVzdWx0IG9mIGNvcnBvcmF0ZSBtZXJnZXJzLCB3aGVyZSBvbmUgb2Yg dGhlIHByZS1tZXJnZXIgY29tcGFuaWVzIHdhcyB1c2luZyB0aGVpciBwdWJsaWMgYWRkcmVzcyBz cGFjZSBpbnRlcm5hbGx5LCBhbmQgdGhlIG90aGVyIHdhc27igJl0Lg0KDQoNCg== --_000_F144FF61AAC64E0AB08E0E3F9B487F1Bvidyocom_ Content-Type: text/html; charset="utf-8" Content-ID: <624D3DFFD369C44CA0966779E4E06CF4@vidyo.com> Content-Transfer-Encoding: base64 PGh0bWw+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIgY29udGVudD0i dGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjwvaGVhZD4NCjxib2R5IHN0eWxlPSJ3b3JkLXdy YXA6IGJyZWFrLXdvcmQ7IC13ZWJraXQtbmJzcC1tb2RlOiBzcGFjZTsgLXdlYmtpdC1saW5lLWJy ZWFrOiBhZnRlci13aGl0ZS1zcGFjZTsiIGNsYXNzPSIiPg0KPGJyIGNsYXNzPSIiPg0KPGRpdj4N CjxibG9ja3F1b3RlIHR5cGU9ImNpdGUiIGNsYXNzPSIiPg0KPGRpdiBjbGFzcz0iIj5PbiBBdWcg NSwgMjAxNSwgYXQgNTozNSBQTSwgSnVzdGluIFViZXJ0aSAmbHQ7PGEgaHJlZj0ibWFpbHRvOmp1 YmVydGlAZ29vZ2xlLmNvbSIgY2xhc3M9IiI+anViZXJ0aUBnb29nbGUuY29tPC9hPiZndDsgd3Jv dGU6PC9kaXY+DQo8ZGl2IGNsYXNzPSIiPg0KPGRpdiBkaXI9Imx0ciIgY2xhc3M9IiI+PGJyIGNs YXNzPSIiPg0KPGRpdiBjbGFzcz0iZ21haWxfZXh0cmEiPg0KPGRpdiBjbGFzcz0iZ21haWxfcXVv dGUiPk9uIFdlZCwgQXVnIDUsIDIwMTUgYXQgMTE6MzIgQU0sIFNpbW9uIFBlcnJlYXVsdCA8c3Bh biBkaXI9Imx0ciIgY2xhc3M9IiI+DQombHQ7PGEgaHJlZj0ibWFpbHRvOnNwZXJyZWF1bHRAaml2 ZS5jb20iIHRhcmdldD0iX2JsYW5rIiBjbGFzcz0iIj5zcGVycmVhdWx0QGppdmUuY29tPC9hPiZn dDs8L3NwYW4+IHdyb3RlOjxiciBjbGFzcz0iIj4NCjxibG9ja3F1b3RlIGNsYXNzPSJnbWFpbF9x dW90ZSIgc3R5bGU9Im1hcmdpbjowIDAgMCAuOGV4O2JvcmRlci1sZWZ0OjFweCAjY2NjIHNvbGlk O3BhZGRpbmctbGVmdDoxZXgiPg0KTGUgMjAxNS0wOC0wNSAxMzo0NiwgUGhpbGlwcCBIYW5ja2Ug YSDDqWNyaXQgOjxiciBjbGFzcz0iIj4NCiZndDsgSWYgYSBwZWVyIHNlbmRzIGNhbmRpZGF0ZXMg d2l0aCBJUCBhZGRyZXNzZXMgZnJvbSB0aGUgcHJpdmF0ZSBzcGFjZSw8YnIgY2xhc3M9IiI+DQom Z3Q7IHBlcm1pc3Npb25zIGZvciB0aG9zZSBhcmUgY3JlYXRlZCBhdCB0aGUgVFVSTiBzZXJ2ZXIu IFBvdGVudGlhbGx5IG5vdDxiciBjbGFzcz0iIj4NCiZndDsgdXRpbGlzaW5nIHRyYW5zcG9ydCBl bmNyeXB0aW9uIGV2ZW4uPGJyIGNsYXNzPSIiPg0KJmd0OzxiciBjbGFzcz0iIj4NCiZndDsgSSBk b3VidCB0aG9zZSBjYW5kaWRhdGVzIGV2ZXIgd29yaywgc28gZnJvbSBhIHByaXZhY3kgcG9pbnQg b2YgdmlldyBpdDxiciBjbGFzcz0iIj4NCiZndDsgc2VlbXMgdGhhdCBjbGllbnRzIHNob3VsZCBu b3QgY3JlYXRlIHRob3NlIHBlcm1pc3Npb25zIGluIHRoZSBmaXJzdDxiciBjbGFzcz0iIj4NCiZn dDsgcGxhY2UuIEFuZCBJQ0Ugc2hvdWxkIHByb2JhYmx5IG5vdCB0cnkgdG8gY3JlYXRlIHBhaXJz LjxiciBjbGFzcz0iIj4NCjxiciBjbGFzcz0iIj4NCkl0J3Mgbm90IHVwIHRvIHRoZSBjbGllbnQg dG8gZGV0ZXJtaW5lIHdoYXQgYWRkcmVzc2VzIG1pZ2h0IG5vdCBtaWdodDxiciBjbGFzcz0iIj4N Cm5vdCB3b3JrIGZvciBhIGdpdmVuIFRVUk4gc2VydmVyLiBUaGVyZSBhcmUgbG90cyBvZiB3ZWly ZCBOQVQ8YnIgY2xhc3M9IiI+DQpjb25maWd1cmF0aW9ucyBvdXQgdGhlcmUgdGhhdCBwbGF5IGdh bWVzIHdpdGggUkZDMTkxOCBhZGRyZXNzZXMgYW5kIGNhbjxiciBjbGFzcz0iIj4NCmVhc2lseSB0 cmljayBjbGllbnRzIGludG8gZG9pbmcgdGhlIHdyb25nIHRoaW5nLjxiciBjbGFzcz0iIj4NCjwv YmxvY2txdW90ZT4NCjxkaXYgY2xhc3M9IiI+PGJyIGNsYXNzPSIiPg0KPC9kaXY+DQo8ZGl2IGNs YXNzPSIiPkkgYW0gc29tZXdoYXQgc3ltcGF0aGV0aWMgdG8gdGhhdCwgYnV0IGdpdmVuIHRoYXQg dGhlcmUgaXMgbWVhc3VyYWJsZSBkb3duc2lkZSBoZXJlIC0gZXh0cmEgY2FuZGlkYXRlIHBhaXJz IHRoYXQgdGFrZSB0aW1lIHRvIGNoZWNrIC0gY2FuIHlvdSBzdXBwbHkgYSBjb25jcmV0ZSBleGFt cGxlIG9mIHdoZXJlIHRoZSBjbGllbnQgY2hvb3Npbmcgbm90IHRvIHBhaXIgYSBUVVJOIGNhbmRp ZGF0ZSB3aXRoIGEgUkZDMTkxOCBhZGRyZXNzDQogd291bGQgY2F1c2UgYSBwcm9ibGVtPzwvZGl2 Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Jsb2NrcXVvdGU+DQo8YnIgY2xh c3M9IiI+DQo8L2Rpdj4NCjxkaXY+VGhpcyBpcyByZWFsbHkgYW4gSUNFIHF1ZXN0aW9uLCBub3Qg YSBUVVJOIHF1ZXN0aW9uLCBzbyBhZGRpbmcgTU1VU0lDLjwvZGl2Pg0KPGRpdj48YnIgY2xhc3M9 IiI+DQo8L2Rpdj4NCjxkaXY+Q2xlYXJseSwgaWYgeW91ciBUVVJOIHNlcnZlciBpcyBhY3R1YWxs eSBvbiB0aGUgcHVibGljIGludGVybmV0LCBwYWlyaW5nIFJGQzE5MTggYWRkcmVzcyB3aXRoIGl0 cyBjYW5kaWRhdGVzIHdvbuKAmXQgZG8gYW55IGdvb2QuICZuYnNwO0hvd2V2ZXIsIHRoZXJlIGNh biBiZSBzY2VuYXJpb3Mgd2hlcmUgeW91IGhhdmUgYSBUVVJOIHNlcnZlciBzaXR0aW5nIGluIGEg RE1aIG9yIHRoZSBsaWtlLCB3aGVyZSBpdCBjYW4gYWN0dWFsbHkgcm91dGUgdG8gUkZDDQogMTkx OCBhZGRyZXNzZXMuICZuYnNwO0kgc3VzcGVjdCB0aGlzIHdpbGwgYmUgcmVsZXZhbnQgaW4gdGhl IHZhcmlvdXMgc2NlbmFyaW9zIHdoZXJlIHRoZSBUVVJOIHNlcnZlciBpcyB0b3BvbG9naWNhbGx5 IGVxdWl2YWxlbnQgdG8gYSB3ZWIgcHJveHkuJm5ic3A7PC9kaXY+DQo8ZGl2PjxiciBjbGFzcz0i Ij4NCjwvZGl2Pg0KPGRpdj5BcyBJIHJlY2FsbCBmcm9tIHRoZSBkaXNjdXNzaW9ucyBhcm91bmQg dGhlIGRldmVsb3BtZW50IG9mIElDRSwgdGhlcmUgYXJlIGFjdHVhbGx5IGEgZmFpciBudW1iZXIg b2YgbmV0d29ya3Mgb3V0IHRoZXJlIHdoaWNoIGhhdmUgcHVibGljIElQdjQgYW5kIFJGQzE5MTgg YWRkcmVzc2VzIGRpcmVjdGx5IHJvdXRhYmxlIHRvIGVhY2ggb3RoZXIuIFRoZSBleGFtcGxlcyBJ IHJlbWVtYmVyIGNhbWUgYWJvdXQgYXMgYSByZXN1bHQgb2YgY29ycG9yYXRlDQogbWVyZ2Vycywg d2hlcmUgb25lIG9mIHRoZSBwcmUtbWVyZ2VyIGNvbXBhbmllcyB3YXMgdXNpbmcgdGhlaXIgcHVi bGljIGFkZHJlc3Mgc3BhY2UgaW50ZXJuYWxseSwgYW5kIHRoZSBvdGhlciB3YXNu4oCZdC48L2Rp dj4NCjxkaXY+PGJyIGNsYXNzPSIiPg0KPC9kaXY+DQo8ZGl2PjxiciBjbGFzcz0iIj4NCjwvZGl2 Pg0KPC9ib2R5Pg0KPC9odG1sPg0K --_000_F144FF61AAC64E0AB08E0E3F9B487F1Bvidyocom_-- From nobody Thu Aug 6 07:23:21 2015 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D66581A1A60 for ; Thu, 6 Aug 2015 07:23:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kCUXnM80_xLF for ; Thu, 6 Aug 2015 07:23:19 -0700 (PDT) Received: from smtp001.apm-internet.net (smtp001-out.apm-internet.net [85.119.248.222]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D25761A1A58 for ; Thu, 6 Aug 2015 07:23:18 -0700 (PDT) Received: (qmail 75654 invoked from network); 6 Aug 2015 14:23:17 -0000 X-AV-Scan: clean X-APM-Authkey: 83769/0 8683 Received: from unknown (HELO zimbra003.verygoodemail.com) (85.119.248.218) by smtp001.apm-internet.net with SMTP; 6 Aug 2015 14:23:17 -0000 Received: from zimbra003.verygoodemail.com (localhost [127.0.0.1]) by zimbra003.verygoodemail.com (Postfix) with ESMTP id 530B618A0EC5; Thu, 6 Aug 2015 15:23:14 +0100 (BST) Received: from [10.106.111.176] (unknown [66.71.232.48]) by zimbra003.verygoodemail.com (Postfix) with ESMTPSA id CF9F218A0D38; Thu, 6 Aug 2015 15:23:13 +0100 (BST) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2102\)) From: tim panton In-Reply-To: Date: Thu, 6 Aug 2015 09:23:12 -0500 Content-Transfer-Encoding: quoted-printable Message-Id: References: <9F33F40F6F2CD847824537F3C4E37DDF1E826A00@MCHP04MSX.global-ad.net> <7515AC50-14F3-43C4-B3D9-D785100FC9C5@phonefromhere.com> To: "Asveren, Tolga" X-Mailer: Apple Mail (2.2102) Archived-At: Cc: "" Subject: Re: [rtcweb] What the gateway draft should say about mux/non-mux X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 06 Aug 2015 14:23:21 -0000 > On 6 Aug 2015, at 09:12, Asveren, Tolga wrote: >=20 > I think implementers themselves can weigh out the = advantages/disadvantaged/deployment models they are way. >=20 Certainly true for a standards track document, but if the gateway draft = ends up being Informational,=20 I do think would be appropriate to steer implementers in the direction = of sanity :-)=20 Tim.= From nobody Thu Aug 6 07:33:24 2015 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 66D191A887E for ; Thu, 6 Aug 2015 07:33:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.567 X-Spam-Level: X-Spam-Status: No, score=-1.567 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, IP_NOT_FRIENDLY=0.334, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id y8c1fpMWAzjh for ; Thu, 6 Aug 2015 07:33:22 -0700 (PDT) Received: from mx0a-00198e01.pphosted.com (mx0a-00198e01.pphosted.com [67.231.149.202]) (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 88AAC1A8827 for ; Thu, 6 Aug 2015 07:33:22 -0700 (PDT) Received: from pps.filterd (m0073109.ppops.net [127.0.0.1]) by mx0a-00198e01.pphosted.com (8.15.0.59/8.14.7) with SMTP id t76EWAwf008631; Thu, 6 Aug 2015 10:33:22 -0400 Received: from mail.vidyo.com ([162.209.16.214]) by mx0a-00198e01.pphosted.com with ESMTP id 1w1e1wj706-1 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Thu, 06 Aug 2015 10:33:22 -0400 Received: from 492132-EXCH1.vidyo.com ([fe80::50:56ff:fe85:4f77]) by 492133-EXCH2.vidyo.com ([fe80::50:56ff:fe85:6b62%13]) with mapi id 14.03.0195.001; Thu, 6 Aug 2015 09:33:21 -0500 From: Jonathan Lennox To: Simon Perreault Thread-Topic: [rtcweb] What the gateway draft should say about mux/non-mux Thread-Index: AQHQ0FMP6xP9QkYtW0impOxEEP9+l53/XNuA Date: Thu, 6 Aug 2015 14:33:20 +0000 Message-ID: References: <9F33F40F6F2CD847824537F3C4E37DDF1E826A00@MCHP04MSX.global-ad.net> <55C3644D.8040903@jive.com> In-Reply-To: <55C3644D.8040903@jive.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [198.200.77.253] Content-Type: text/plain; charset="Windows-1252" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:5.14.151, 1.0.33, 0.0.0000 definitions=2015-08-06_08:2015-08-06,2015-08-06,1970-01-01 signatures=0 X-Proofpoint-Spam-Details: rule=outbound_notspam policy=outbound score=0 spamscore=0 suspectscore=0 phishscore=0 adultscore=0 bulkscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=7.0.1-1506180000 definitions=main-1508060241 Archived-At: Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] What the gateway draft should say about mux/non-mux X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 06 Aug 2015 14:33:23 -0000 > On Aug 6, 2015, at 9:42 AM, Simon Perreault wrote: >=20 > Le 2015-08-06 09:30, Hutton, Andrew a =E9crit : >> If we had thought about this at the time we mandated DTLS-SRTP then we >> would have mandated rtp-mux at the same time but unfortunately we didn= =92t >> but we can fix that now. >=20 > To be clear, rtcp-mux is already mandatory. It's non-mux that needs to > be made optional. >=20 > https://tools.ietf.org/html/draft-ietf-rtcweb-rtp-usage-25#section-4.5 The problem is that there=92s no way in SDP for an offerer to express the d= ifference between =93I=92d like to do RTCP-mux, but I=92m willing to fall b= ack to non-muxed=94 and =93I only support RTCP-mux, and if you can=92t do i= t please reject my offer.=94 This is a general consequence of the fact that SDP has no comprehension-man= datory attributes. (We were able to get away with this for DTLS-SRTP becau= se the =93proto=94 field is single-valued and thus effectively comprehensio= n-mandatory.)= From nobody Thu Aug 6 07:36:42 2015 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 56B181A8911 for ; Thu, 6 Aug 2015 07:36:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.977 X-Spam-Level: X-Spam-Status: No, score=-1.977 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bmhF_mxE4oO1 for ; Thu, 6 Aug 2015 07:36:35 -0700 (PDT) Received: from mail-wi0-f178.google.com (mail-wi0-f178.google.com [209.85.212.178]) (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 37AB21A88C4 for ; Thu, 6 Aug 2015 07:36:35 -0700 (PDT) Received: by wijp15 with SMTP id p15so25297921wij.0 for ; Thu, 06 Aug 2015 07:36:34 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type; bh=4eZXkYKDNRDgfPBIdB72zotP5w4RzU4FWsxrzYStO7c=; b=NOKl0xeK/E1FN8Vwd626iXtK+LICJes8eZSDTUvipDZvnqagq1iPJ98Mk+4TdFJPaQ krEvDk8+GHg9lwfwuphM+q9hgt5zhobQ4yue91orZhoOXo1XCsRxV5/jX45o7Mk6YzvK ak/sJKamEF8wCGA6XAjSMkQ1BA+k1oQbKoQRKboPy3kbdjLb5S7EwKpahlN3pqD6BMnG P6K52DQyi6tUTOSvWJ1UTnRylzpDrHm+fHwa7LWTaWZdc8e4T0NiBOC9ddpzeq2wGxgD 9Su7clPBQ8cjZV1GlfDbwIU4/PTWqF7ZXMeD91rbAxA9UCKA3CaDvaBdxpNmToXw2j5H Ektw== X-Gm-Message-State: ALoCoQmwNSyETnOzppJim40ifwGN+bWpTgRuZ7gul0yQ7UJQucmt9QIljXW/+Aun0C5SAiHdnhLy X-Received: by 10.194.216.68 with SMTP id oo4mr3845527wjc.81.1438871793935; Thu, 06 Aug 2015 07:36:33 -0700 (PDT) MIME-Version: 1.0 Received: by 10.27.85.99 with HTTP; Thu, 6 Aug 2015 07:35:54 -0700 (PDT) In-Reply-To: References: <9F33F40F6F2CD847824537F3C4E37DDF1E826A00@MCHP04MSX.global-ad.net> <7515AC50-14F3-43C4-B3D9-D785100FC9C5@phonefromhere.com> From: Eric Rescorla Date: Thu, 6 Aug 2015 07:35:54 -0700 Message-ID: To: "Asveren, Tolga" Content-Type: multipart/alternative; boundary=089e0141a09227b107051ca5722f Archived-At: Cc: "" Subject: Re: [rtcweb] What the gateway draft should say about mux/non-mux X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 06 Aug 2015 14:36:40 -0000 --089e0141a09227b107051ca5722f Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable I feel like people are talking past each other here. The browser vendors (at least Chrome and Firefox) want to completely remove support for non-mux from their code. If we make this change, that means that there will be no way for a browser to do non-mux and so as a practical matter we might as well simply say that WebRTC is mux and hence for the WebRTC side of a WebRTC gateway, there is similarly no need to support non-mux, This only leaves the question of the non-WebRTC side of the gateway, but that's out of scope here. So, I'm not sure what you are asking for. WRT to the issue Jonathan raises about SDP being a negotiation, that's true, but as a practical matter we're already far down the road of WebRTC offerers offering SDP which in principle the answerer might choose not to accept but if it does so the connection will fail -Ekr On Thu, Aug 6, 2015 at 7:12 AM, Asveren, Tolga wrote: > I think implementers themselves can weigh out the > advantages/disadvantaged/deployment models they are targeting/etc=E2=80= =A6 and > decide what to support/not to support. I don=E2=80=99t see any issue with= this as > long as there is a negotiation mechanism (which there is). I don=E2=80=99= t think > the availability of negotiation is encouraging people this or that way. > > > > Thanks, > > Tolga > > > > *From:* tim panton [mailto:tim@phonefromhere.com] > *Sent:* Thursday, August 06, 2015 10:07 AM > *To:* Hutton, Andrew > *Cc:* Asveren, Tolga ; < > rtcweb@ietf.org> > > *Subject:* Re: [rtcweb] What the gateway draft should say about > mux/non-mux > > > > > > On 6 Aug 2015, at 08:30, Hutton, Andrew wrote: > > > > +1 to what Tim said. > > > > I don=E2=80=99t think this discussion is really about gateways at all it = is surely > about whether WebRTC browsers have to support non-mux and I don=E2=80=99t= really > see any good reason why they need to. > > > > If we had thought about this at the time we mandated DTLS-SRTP then we > would have mandated rtp-mux at the same time but unfortunately we didn=E2= =80=99t > but we can fix that now. > > > > Sadly true, but the situation in a browser is manageable since you might > expect 10 peer connections, resulting > > in a worst case of 60 UDP ports/DTLS sessions in use > > (assuming voice+video+data unbundled and RTCP-non-mux vs the 10 needed). > We > > also assume a relatively well endowed CPU - devoted largely to this task. > > > > On the gateway you=E2=80=99d hope to have thousands of sessions and presu= mably > much less CPU/memory resource per channel. > > So while I think it is unfortunate that browsers can do non-mux, it would > be plain stupid to do that on a gateway. Do we > > really want to encourage that ? > > > > T. > > > > > > > > Andy > > > > > > *From:* rtcweb [mailto:rtcweb-bounces@ietf.org ]= *On > Behalf Of *tim panton > *Sent:* 06 August 2015 13:53 > *To:* Asveren, Tolga > *Cc:* > *Subject:* Re: [rtcweb] What the gateway draft should say about > mux/non-mux > > > > So we are positing the existence of a webRTC gateway designed to support > thousands of calls which does ICE and DTLS but the > > designer decided deliberately to double the number of ICE sessions > required and double the number of DTLS sessions (and key > > generation costs) so that they can run RTCP (over ICE and DTLS) on a > separate port. In my estimation that=E2=80=99s one poor decision > > and should not be used as the basis of this (or any) standard. > > > > I=E2=80=99d rather not support rtcp-no-mux as I see zero advantages in ha= ving it. > (I know theoretically it might be possible to get > > a RTCP packet through a congested net on a different port with a separate > diffserv setting but that just seems so contrived). > > > > Tim. > > > > > > On 6 Aug 2015, at 06:44, Asveren, Tolga wrote: > > > > These assumptions are not necessarily true in a universal sense (like > almost any other assumption about different deployment models). > > > > Furthermore, and more importantly, there is nothing mandating WebRTC > endpoints to support non-rtcp-mux. It is a negotiated functionality. Any > entity can enforce rtcp-mux as a local policy. > > > > The issue with supporting non-rtcp-mux seems to be lack of clarity in the > relevant specifications. Fixing this =E2=80=93regardless of the outcome o= f any > other discussion- seems to be prudent IMHO. > > > > Thanks, > > Tolga > > > > *From:* Wyss, Felix [mailto:Felix.Wyss@inin.com ] > *Sent:* Thursday, August 06, 2015 6:37 AM > *To:* Christer Holmberg ; Asveren, Tolga = < > tasveren@sonusnet.com>; Schwarz, Albrecht (Albrecht) < > albrecht.schwarz@alcatel-lucent.com>; Roman Shpount ; > Rauschenbach, Uwe (Nokia - DE/Munich) > *Cc:* > *Subject:* Re: [rtcweb] What the gateway draft should say about > mux/non-mux > > > > Why shouldn't the gateway be required to do the mux/demux? Making the > WebRTC endpoints a lot more complex just so the legacy interop might > potentially be a teeny-tiny bit easier makes no sense IMHO. Actually, th= e > gateway would not be able to do "end-to-end" pass-through anyway as legac= y > equipment will either be unencrypted or use SDES (RFC#4568) for key > exchange. So the gateway will have to perform DTLS-SRTP to SDES-SRTP > transcryption--which already is way more hassle than RTP/RTCP mux/demux. > > > > --Felix > > > ------------------------------ > > *From:* rtcweb on behalf of Christer Holmberg < > christer.holmberg@ericsson.com> > *Sent:* Thursday, August 6, 2015 05:51 > *To:* Asveren, Tolga; Schwarz, Albrecht (Albrecht); Roman Shpount; > Rauschenbach, Uwe (Nokia - DE/Munich) > *Cc:* > *Subject:* Re: [rtcweb] What the gateway draft should say about > mux/non-mux > > > > Hi, > > > > No matter whether the gateway supports RTP/RTCP mux or not, there are > cases where the legacy network/endpoints will not use RTP/RTCP mux, so I > guess people then would want to be able to negotiate non-mux =E2=80=9Cend= -to-end=E2=80=9D, > rather than having the gateway to demux/mux RTP and RTCP. > > > > Regards, > > > > Christer > > > > *From:* Asveren, Tolga [mailto:tasveren@sonusnet.com > ] > *Sent:* 6. elokuuta 2015 12:18 > *To:* Schwarz, Albrecht (Albrecht); Roman Shpount; Rauschenbach, Uwe > (Nokia - DE/Munich) > *Cc:* ext Eric Rescorla; Christer Holmberg; Bernard Aboba; < > rtcweb@ietf.org> > *Subject:* Re: [rtcweb] What the gateway draft should say about > mux/non-mux > > > > Why should we consider 3GPP the sole "owner/user" of the term/entity > WebRTC-GW? I think it has a much more general meaning and use in practice= . > It can refer to many different types of elements which can be deployed in > many different environments, hence any attempt to define it > strictly/restrict its capabilities are futile IMHO. > > > > Thanks, > > Tolga > > > ------------------------------ > > *From:* Schwarz, Albrecht (Albrecht) > *Sent:* Thursday, August 6, 2015 2:44 AM > *To:* Asveren, Tolga; Roman Shpount; Rauschenbach, Uwe (Nokia - DE/Munich= ) > *Cc:* ext Eric Rescorla; Christer Holmberg; Bernard Aboba; < > rtcweb@ietf.org> > *Subject:* RE: [rtcweb] What the gateway draft should say about > mux/non-mux > > > > The concerned 3GPP WebRTC gateway (3GPP 23.334/29.334) supports already > RTP/RTCP transport multiplexing (since 3GPP Release 12), i.e. should not = be > the limiting factor in this discussion. > > For ones interested in the RTCP port allocation rules, see H.248.57: > > > https://www.itu.int/rec/dologin_pub.asp?lang=3De&id=3DT-REC-H.248.57-2014= 10-I!!PDF-E&type=3Ditems > > Clause 7 describes RTP/RTCP transport multiplexing. ITU-T H.248.57 is > already supported by 3GPP 29.334. > > > > The rationale behind the =E2=80=9Coptional tagging=E2=80=9D by 23.228 is = a third reason, > beyond > > >1. Using different QOS settings for RTCP vs RTP > > >2. Sending RTCP to a different device from RTP > > > > Don=E2=80=99t want to go in the 3GPP specific details, but it has nothing= to do > with the 3GPP UE-embedded WebRTC client nor any constraints by 3GPP WebRT= C > gateways. > > > > Thus, a WebRTC gateway MUST support RTP/RTCP transport multiplexing due t= o > its purpose in interworking support. > > > > Regards, > > Albrecht > > > > > > *From:* Asveren, Tolga [mailto:tasveren@sonusnet.com > ] > *Sent:* Mittwoch, 5. August 2015 19:47 > *To:* Roman Shpount; Rauschenbach, Uwe (Nokia - DE/Munich) > *Cc:* ext Eric Rescorla; Schwarz, Albrecht (Albrecht); Christer Holmberg; > Bernard Aboba; > *Subject:* RE: [rtcweb] What the gateway draft should say about > mux/non-mux > > > > i- I humbly disagree that using different QoS RTCP/RTP, e.g. different > DiffServ values , should be dismissed. > > ii- Let me also add another reason why no-rtcp-mux may be needed: > Implementation difficulties in certain GWs. > > > > Considering that there is already a negotiation mechanism for rtcp-mux > support, that it can be de-facto mandated by the choice of browsers for > Internet, I think what Christer/Albrecht suggested is the right way to mo= ve > forward: provide clarifications for vague points. I don=E2=80=99t underst= and why > lack of clarity in existing specifications should cause imposing > restrictions. This would be akin to dropping a feature due to a bug. In > this case, the =E2=80=9Cbug=E2=80=9D is lack of clarity in normative spec= ifications and it > can be addressed by further specification. > > > > Thanks, > > Tolga > > > > *From:* Roman Shpount [mailto:roman@telurix.com ] > *Sent:* Wednesday, August 05, 2015 12:29 PM > *To:* Rauschenbach, Uwe (Nokia - DE/Munich) > *Cc:* ext Eric Rescorla ; Schwarz, Albrecht (Albrecht) < > albrecht.schwarz@alcatel-lucent.com>; Asveren, Tolga < > tasveren@sonusnet.com>; Christer Holmberg ; > Bernard Aboba ; < > rtcweb@ietf.org> > *Subject:* Re: [rtcweb] What the gateway draft should say about > mux/non-mux > > > > On Wed, Aug 5, 2015 at 4:47 AM, Rauschenbach, Uwe (Nokia - DE/Munich) < > uwe.rauschenbach@nokia.com> wrote: > > Media gateway implementations according to 3GPP TS 23.228 may not support > rtcp-mux, as rtcp-mux is optional there. > > So if we drop non-mux support from web browsers, those media gateways tha= t > have not implemented rtcp-mux will stop interoperating. > > > > > > First of all, do you know of any WebRTC to IMS gateways that do not > implement rtcp-mux on the WebRTC side? I strongly suspect there are none. > > > > Second, the only reasons not to use rtcp-mux that I can think of are the > following: > > > > 1. Using different QOS settings for RTCP vs RTP > > 2. Sending RTCP to a different device from RTP > > > > I do not think the first use case warrants making rtcp-mux optional, > since, practically no one does this. > > Second use case is also fairly marginal. Plus it can be handled by the > gateway which can send RTCP to one device and RTP to another. > > > > So, unless someone can come up with a use case why RTP and RTCP should us= e > different transports, I think rtcp-mux should be mandatory. > > > > Regards, > > ______________ > > Roman Shpount > > _______________________________________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/listinfo/rtcweb > > > > > > _______________________________________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/listinfo/rtcweb > > --089e0141a09227b107051ca5722f Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
I feel like people are talking past each other here.
<= br>
The browser vendors (at least Chrome and Firefox) want to com= pletely remove support for
non-mux from their code. If we make th= is change, that means that there will be no way for a
browser to = do non-mux and so as a practical matter we might as well simply say that
WebRTC is mux and hence for the WebRTC side of a WebRTC gateway, th= ere is similarly no
need to support non-mux, This only leaves the= question of the non-WebRTC side of
the gateway, but that's o= ut of scope here. So, I'm not sure what you are asking for.
<= br>
WRT to the issue Jonathan raises about SDP being a negotiatio= n, that's true, but as
a practical matter we're already f= ar down the road of WebRTC offerers offering SDP
which in princip= le the answerer might choose not to accept but if it does so the
= connection will fail

-Ekr

On Thu, Aug 6, 2015 at 7:12 AM, Asveren, Tolga <tasveren@sonusnet.com= > wrote:

I think implementers themselves can w= eigh out the advantages/disadvantaged/deployment models they are targeting/= etc=E2=80=A6 and decide what to support/not to support. I don=E2=80=99t see any issue with this as long as there is a negotiation = mechanism (which there is). I don=E2=80=99t think the availability of negot= iation is encouraging people this or that way.

=C2=A0

Thanks,

Tolga

=C2=A0

From: tim panton [mailto:tim@phonefromhere.com]
Sent: Thursday, August 06, 2015 10:07 AM
To: Hutton, Andrew <andrew.hutton@unify.com>
Cc: Asveren, Tolga <tasveren@sonusnet.com>; <rtcweb@ietf.org> <rtcweb@ietf.org>


Subject: Re: [rtcweb] What the gateway draft should say about mux/no= n-mux

=C2=A0

=C2=A0

On 6 Aug 2015, at 08:30, Hutton, Andrew <andrew.hutton@unify.c= om> wrote:

=C2=A0

+1 to what Tim said.=

=C2=A0

I don=E2=80=99t think this discussion= is really about gateways at all it is surely about whether WebRTC browsers= have to support non-mux and I don=E2=80=99t really see any good reason why they need to.

=C2=A0

If we had thought about this at the t= ime we mandated DTLS-SRTP then we would have mandated rtp-mux at the same t= ime but unfortunately we didn=E2=80=99t but we can fix that now.

=C2=A0

Sadly true, but the situation in a browser is manage= able since you might expect 10 peer connections, resulting=C2=A0<= /u>

in a worst case of 60 UDP ports/DTLS sessions in use= =C2=A0

(assuming voice+video+data unbundled and RTCP-non-mu= x vs the 10 needed). We=C2=A0

also assume a relatively well endowed CPU - devoted = largely to this task.

=C2=A0

On the gateway you=E2=80=99d hope to have thousands = of sessions and presumably much less CPU/memory resource per channel.

So while I think it is unfortunate that browsers can= do non-mux, it would be plain stupid to do that on a gateway. Do we=C2=A0<= u>

really want to encourage that ?

=C2=A0

T.

=C2=A0



=C2=A0

Andy

=C2=A0

=C2=A0

From: rtcweb [mailto:rtcweb-bounces@ietf.org] On Behalf Of tim panton
Sent: 06 August 2015 13:53
To: Asveren, Tolga
Cc: <rtcweb@= ietf.org>
Subject: Re: [rtcweb] What the gateway draft should say about mux/no= n-mux

=C2=A0

So we are positing the existence of a webRTC gateway= designed to support thousands of calls which does ICE and DTLS but the<= /u>

designer decided deliberately to double the number o= f ICE sessions required and double the number of DTLS sessions (and key=C2= =A0

generation costs) so that they can run RTCP (over IC= E and DTLS) on a separate port. In my estimation that=E2=80=99s one poor de= cision

and should not be used as the basis of this (or any)= standard.=C2=A0

=C2=A0

I=E2=80=99d rather not support rtcp-no-mux as I see = zero advantages in having it. (I know theoretically it might be possible to= get

a RTCP packet through a congested net on a different= port with a separate diffserv setting but that just seems so contrived).

=C2=A0

Tim.

=C2=A0

=C2=A0

On 6 Aug 2015, at 06:44, Asveren, Tolga <tasveren@sonusnet.com> wrote:

=C2=A0

These assumptions are not necessarily= true in a universal sense (like almost any other assumption about differen= t deployment models).

=C2=A0

Furthermore, and more importantly, th= ere is nothing mandating WebRTC endpoints to support non-rtcp-mux. It is a = negotiated functionality. Any entity can enforce rtcp-mux as a local policy.=C2=A0

=C2=A0

The issue with supporting non-rtcp-mu= x seems to be lack of clarity in the relevant specifications. Fixing this = =E2=80=93regardless of the outcome of any other discussion- seems to be prudent IMHO.

=C2=A0

Thanks,

Tolga

=C2=A0

From:=C2=A0Wyss= , Felix [mailto:Fel= ix.Wyss@inin.com]=C2=A0
Sent:=C2=A0Thursday, August 06, 2015 6:37 AM
To:=C2=A0Christer Holmberg <christer.holmberg@ericsson.com<= /a>>; Asveren, Tolga <tasveren@sonusnet.com>; Schwarz, Albrecht (Albrecht) <albrecht.schwarz@alcatel-lucent.com>; Roman Shpount &l= t;roman@telurix.com<= /a>>; Rauschenbach, Uwe (Nokia - DE/Munich) <uwe.rauschenbach@nokia.com><= br> Cc:=C2=A0<rtcweb@ietf.org> <rtcweb@ietf.org>
Subject:=C2=A0Re: [rtcweb] What the gateway draft shoul= d say about mux/non-mux

=C2=A0

Why shouldn't the gateway be required= to do the mux/demux?=C2=A0 Making the WebRTC endpoints a lot more complex = just so the legacy interop might potentially be a teeny-tiny bit easier makes no sense IMHO.=C2=A0 Actually, the gateway would not be a= ble to do "end-to-end" pass-through anyway as legacy equipment wi= ll either be unencrypted or use SDES (RFC#4568) for key exchange.=C2=A0 So = the gateway will have to perform DTLS-SRTP to SDES-SRTP transcryption--which already is way more hassle than RTP/RTCP mux/demux.

=C2=A0

--Felix

=C2=A0

From:=C2=A0rtcweb <rtcweb-bounces@ietf.org> on behalf of Chr= ister Holmberg <christer.holmberg@ericsson.com>
Sent:=C2=A0Thursday, August 6, 2015 05:51
To:=C2=A0Asveren, Tolga; Schwarz, Albrecht (Albrecht); = Roman Shpount; Rauschenbach, Uwe (Nokia - DE/Munich)
Cc:=C2=A0<rtcweb@ietf.org>
Subject:=C2=A0Re: [rtcweb] What the gateway draft shoul= d say about mux/non-mux

=C2=A0

Hi,=

=C2=A0

No matter = whether the gateway supports RTP/RTCP mux or not, there are cases where the= legacy network/endpoints will not use RTP/RTCP mux, so I guess people then would want to be able to negotiate non-mux =E2= =80=9Cend-to-end=E2=80=9D, rather than having the gateway to demux/mux RTP = and RTCP.

=C2=A0

Regards,

=C2=A0

Christer

=C2=A0

From:= = =C2=A0Asveren, Tolga [mailto:tasveren@sonusnet.com]=C2=A0
Sent:=C2=A06. elokuuta 2015 12:18
To:=C2=A0Schwarz, Albrecht (Albrecht); Roman Shpount; R= auschenbach, Uwe (Nokia - DE/Munich)
Cc:=C2=A0ext Eric Rescorla; Christer Holmberg; Bernard = Aboba; <rtcweb@ietf.org>
Subject:=C2=A0Re: [rtcweb] What the gateway draft shoul= d say about mux/non-mux

=C2=A0

Why should we consider 3GPP the sole &quo= t;owner/user" of the term/entity WebRTC-GW? I think it has a much more= general meaning and use in practice. It can refer to many different types of elements which can be deployed in many different enviro= nments, hence any attempt to define it strictly/restrict its capabilities a= re futile IMHO.

=C2=A0

Thanks,

Tolga

=C2=A0

From:=C2=A0Schwarz, Albrecht (Albrecht) <albrecht.schwarz@alcate= l-lucent.com>
Sent:=C2=A0Thursday, August 6, 2015 2:44 AM
To:=C2=A0Asveren, Tolga; Roman Shpount; Rauschenbach, U= we (Nokia - DE/Munich)
Cc:=C2=A0ext Eric Rescorla; Christer Holmberg; Bernard = Aboba; <rtcweb@ietf.org>
Subject:=C2=A0RE: [rtcweb] What the gateway draft shoul= d say about mux/non-mux

=C2=A0

The concerned 3GPP WebRTC gatewa= y (3GPP 23.334/29.334) supports already RTP/RTCP transport multiplexing (si= nce 3GPP Release 12), i.e. should not be the limiting factor in this discussion.=C2=A0

For ones interested in the RTCP = port allocation rules, see H.248.57:

Clause 7 describes RTP/RTCP tran= sport multiplexing. ITU-T H.248.57 is already supported by 3GPP 29.334.

=C2=A0

The rationale behind the =E2=80= =9Coptional tagging=E2=80=9D by 23.228 is a third reason, beyond<= /u>

>1. Using different QOS settings for R= TCP vs RTP

>2. Sending RTCP to a different device= from RTP

=C2=A0

Don=E2=80=99t want to go in the = 3GPP specific details, but it has nothing to do with the 3GPP UE-embedded W= ebRTC client nor any constraints by 3GPP WebRTC gateways.

=C2=A0

Thus, a WebRTC gateway MUST supp= ort RTP/RTCP transport multiplexing due to its purpose in interworking supp= ort.

=C2=A0

Regards,

Albrecht

=C2=A0

=C2=A0

From:= = =C2=A0Asveren, Tolga [mailto:tasveren@sonusnet.com]=C2=A0
Sent:=C2=A0Mittwoch, 5. August 2015 19:47
To:=C2=A0Roman Shpount; Rauschenbach, Uwe (Nokia - DE/M= unich)
Cc:=C2=A0ext Eric Rescorla; Schwarz, Albrecht (Albrecht= ); Christer Holmberg; Bernard Aboba; <rtcweb@ietf.org&= gt;
Subject:=C2=A0RE: [rtcweb] What the gateway draft shoul= d say about mux/non-mux

=C2=A0

i- I humbl= y disagree that using different QoS RTCP/RTP, e.g. different DiffServ value= s , should be dismissed.

ii- Let me= also add another reason why no-rtcp-mux may be needed: Implementation diff= iculties in certain GWs.

=C2=A0

Considerin= g that there is already a negotiation mechanism for rtcp-mux support, that = it can be de-facto mandated by the choice of browsers for Internet, I think what Christer/Albrecht suggested is the right way to= move forward: provide clarifications for vague points. I don=E2=80=99t und= erstand why lack of clarity in existing specifications should cause imposin= g restrictions. This would be akin to dropping a feature due to a bug. In this case, the =E2=80=9Cbug=E2=80=9D is lack of= clarity in normative specifications and it can be addressed by further spe= cification.

=C2=A0

Thanks,

Tolga

=C2=A0

From:=C2=A0Roman Shpount [mailto:roman@telurix.com]=C2=A0<= br> Sent:=C2=A0Wednesday, August 05, 2015 12:29 PM
To:=C2=A0Rauschenbach, Uwe (Nokia - DE/Munich) <uwe.rauschenbach@nokia.com>
Cc:=C2=A0ext Eric Rescorla <ekr@rtfm.com<= /a>>; Schwarz, Albrecht (Albrecht) <albrec= ht.schwarz@alcatel-lucent.com>; Asveren, Tolga <tasveren@sonusnet.com>; Chri= ster Holmberg <christer.holmberg@ericsson.com>; Bernard Aboba <bernard.aboba@gmail.com>; <rtcweb@ietf.org> <rtcweb@ietf.org><= br> Subject:=C2=A0Re: [rtcweb] What the gateway draft shoul= d say about mux/non-mux

=C2=A0

On Wed, Aug 5, 2015 at 4:47 AM, Rauschenb= ach, Uwe (Nokia - DE/Munich) <uwe.rauschenbach@nokia.c= om> wrote:

Media gateway implementati= ons according to 3GPP TS 23.228=C2=A0may not support rtcp-mux, as rtcp-mux is optional there.<= /p>

So if we drop non-mux supp= ort from web browsers, those media gateways that have not implemented rtcp-= mux will stop interoperating.=C2=A0

=C2=A0

=C2=A0

First of all, do you know of any WebRTC t= o IMS gateways that do not implement rtcp-mux on the WebRTC side? I strongl= y suspect there are none.

=C2=A0

Second, the only reasons not to use rtcp-= mux that I can think of are the following:

=C2=A0

1. Using different QOS settings for RTCP = vs RTP

2. Sending RTCP to a different device fro= m RTP

=C2=A0

I do not think the first use case warrant= s making rtcp-mux optional, since, practically no one does this.<= /u>

Second use case is also fairly marginal. = Plus it can be handled by the gateway which can send RTCP to one device and= RTP to another.

=C2=A0

So, unless someone can come up with a use= case why RTP and RTCP should use different transports, I think rtcp-mux sh= ould be mandatory.

=C2=A0

Regards,

______________

Roman Shpount

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

=C2=A0

=C2=A0


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


--089e0141a09227b107051ca5722f-- From nobody Thu Aug 6 07:52:14 2015 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0698B1A1B12 for ; Thu, 6 Aug 2015 07:52:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, SPF_HELO_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id b4JiPGH2alQM for ; Thu, 6 Aug 2015 07:52:07 -0700 (PDT) Received: from na01-bn1-obe.outbound.protection.outlook.com (mail-bn1on0623.outbound.protection.outlook.com [IPv6:2a01:111:f400:fc10::623]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E9EC61A0366 for ; Thu, 6 Aug 2015 07:52:06 -0700 (PDT) Received: from SN1PR0301MB1551.namprd03.prod.outlook.com (10.162.129.157) by SN1PR0301MB1549.namprd03.prod.outlook.com (10.162.129.155) with Microsoft SMTP Server (TLS) id 15.1.225.19; Thu, 6 Aug 2015 14:51:46 +0000 Received: from SN1PR0301MB1551.namprd03.prod.outlook.com ([10.162.129.157]) by SN1PR0301MB1551.namprd03.prod.outlook.com ([10.162.129.157]) with mapi id 15.01.0225.018; Thu, 6 Aug 2015 14:51:46 +0000 From: "Asveren, Tolga" To: Eric Rescorla Thread-Topic: [rtcweb] What the gateway draft should say about mux/non-mux Thread-Index: AQHQy8DcUgzWwtVCmk+8q67BCzjC45316kQQgAAD5oCAAACVsIAAAj2AgAPw2gCAAEFTAIAC/BgAgACAxgCAABQlsIAA2x8AgAAp4WeAAApBgIAADKQAgAARK8CAABTdgIAACn+AgAAKP4CAAACJUIAAB4QAgAADM1A= Date: Thu, 6 Aug 2015 14:51:46 +0000 Message-ID: References: <9F33F40F6F2CD847824537F3C4E37DDF1E826A00@MCHP04MSX.global-ad.net> <7515AC50-14F3-43C4-B3D9-D785100FC9C5@phonefromhere.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=tasveren@sonusnet.com; x-originating-ip: [50.182.164.80] x-microsoft-exchange-diagnostics: 1; SN1PR0301MB1549; 5:daYId+v+AO+TWFP+NfBwG2qpE56rt0R7vqPOmjD69m662zG9DRavEzWl/Ysq8kdsHQ5jz/GzsLfaS+QnKcLqPH27QxqRBzdTeDuGJqT0FrLU+viTaafw8THjBJFJuRRfpieUU+l36jd0HQSnW8Of3w==; 24:+/4c3hNc0Iy/wl69a5hn8o2JboEyqd+u135ZNXO10gbhsXuNn5xHWPhzPsKSznDoujfpvpjBZPHqWti2lz4P7pw6Ed0j8+oJNEiLkLGD6Zg=; 20:bxDo7KRiPwBxcdFT2bWi2USkeWyuKD2FJxC+0H+Wr0D/jV9cSf2dc4GMv1+y8cjmFDHca6UxyYWiEO37WbG1iQ== x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:SN1PR0301MB1549; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(108003899814671); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(601004)(5005006)(3002001); SRVR:SN1PR0301MB1549; BCL:0; PCL:0; RULEID:; SRVR:SN1PR0301MB1549; x-forefront-prvs: 06607E485E x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(24454002)(164054003)(199003)(189002)(377454003)(16236675004)(62966003)(33656002)(19580405001)(5002640100001)(77156002)(40100003)(93886004)(92566002)(64706001)(19617315012)(189998001)(19300405004)(122556002)(5003600100002)(66066001)(46102003)(101416001)(15975445007)(2900100001)(2950100001)(102836002)(68736005)(77096005)(74316001)(19625215002)(50986999)(10400500002)(76176999)(54356999)(5001920100001)(2656002)(87936001)(76576001)(19609705001)(5001830100001)(5001860100001)(106356001)(106116001)(99286002)(19580395003)(5001960100002)(110136002)(105586002)(86362001)(4001540100001)(81156007)(97736004)(579004); DIR:OUT; SFP:1101; SCL:1; SRVR:SN1PR0301MB1549; H:SN1PR0301MB1551.namprd03.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; A:1; MX:1; LANG:en; received-spf: None (protection.outlook.com: sonusnet.com does not designate permitted sender hosts) Content-Type: multipart/alternative; boundary="_000_SN1PR0301MB1551DF26DBA0FEBB61A92107B2740SN1PR0301MB1551_" MIME-Version: 1.0 X-OriginatorOrg: sonusnet.com X-MS-Exchange-CrossTenant-originalarrivaltime: 06 Aug 2015 14:51:46.2255 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 29a671dc-ed7e-4a54-b1e5-8da1eb495dc3 X-MS-Exchange-Transport-CrossTenantHeadersStamped: SN1PR0301MB1549 Archived-At: Cc: "" Subject: Re: [rtcweb] What the gateway draft should say about mux/non-mux X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 06 Aug 2015 14:52:13 -0000 --_000_SN1PR0301MB1551DF26DBA0FEBB61A92107B2740SN1PR0301MB1551_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SW4gcHJhY3RpY2Ug4oCTaWYgbm90IGFzIGluaXRpYWxseSB0YXJnZXRlZC0gYSBXZWJSVEMtZW5k cG9pbnQgZG9lcyBub3QgbmVjZXNzYXJpbHkgbWVhbiBhIOKAnGJyb3dzZXLigJ0uIEkgY29tcGxl dGVseSBhZ3JlZSB3aXRoIG91ciBzdGF0ZW1lbnRzIGFib3V0IGJyb3dzZXIgYmFzZWQgZGVwbG95 bWVudHMgdGhvdWdoLiBBbGwgSSBhbSBzYXlpbmcgaXMg4oCcTGV0IHBlb3BsZSBkZWNpZGUgd2hh dCB0aGV5IHdhbnQgdG8gc3VwcG9ydCwgdGhleSBhcmUgc21hcnQgZW5vdWdoIHRvIGtub3cgd2hh dCBhIHBhcnRpY3VsYXIgZGVwbG95bWVudCBtb2RlbCByZXF1aXJlc+KAnS4gRm9yIGV4YW1wbGUs IHJlZ2FyZGxlc3Mgb2Ygd2hhdCBzcGVjaWZpY2F0aW9ucyBzYXksIG5vbi1icm93c2VyIGVxdWlw bWVudCB2ZW5kb3JzLCB3aG9zZSBwcm9kdWN0cyBuZWVkIHRvIGludGVyb3BlcmF0ZSB3aXRoIGJy b3dzZXJzLCBhcmUgZm9sbG93aW5nL2ltcGxlbWVudGluZyBob3cgQ2hyb21lL0ZpcmVmb3ggYXJl IGJlaGF2aW5nLg0KDQpUaGFua3MsDQpUb2xnYQ0KDQpGcm9tOiBFcmljIFJlc2NvcmxhIFttYWls dG86ZWtyQHJ0Zm0uY29tXQ0KU2VudDogVGh1cnNkYXksIEF1Z3VzdCAwNiwgMjAxNSAxMDozNiBB TQ0KVG86IEFzdmVyZW4sIFRvbGdhIDx0YXN2ZXJlbkBzb251c25ldC5jb20+DQpDYzogdGltIHBh bnRvbiA8dGltQHBob25lZnJvbWhlcmUuY29tPjsgSHV0dG9uLCBBbmRyZXcgPGFuZHJldy5odXR0 b25AdW5pZnkuY29tPjsgPHJ0Y3dlYkBpZXRmLm9yZz4gPHJ0Y3dlYkBpZXRmLm9yZz4NClN1Ympl Y3Q6IFJlOiBbcnRjd2ViXSBXaGF0IHRoZSBnYXRld2F5IGRyYWZ0IHNob3VsZCBzYXkgYWJvdXQg bXV4L25vbi1tdXgNCg0KSSBmZWVsIGxpa2UgcGVvcGxlIGFyZSB0YWxraW5nIHBhc3QgZWFjaCBv dGhlciBoZXJlLg0KDQpUaGUgYnJvd3NlciB2ZW5kb3JzIChhdCBsZWFzdCBDaHJvbWUgYW5kIEZp cmVmb3gpIHdhbnQgdG8gY29tcGxldGVseSByZW1vdmUgc3VwcG9ydCBmb3INCm5vbi1tdXggZnJv bSB0aGVpciBjb2RlLiBJZiB3ZSBtYWtlIHRoaXMgY2hhbmdlLCB0aGF0IG1lYW5zIHRoYXQgdGhl cmUgd2lsbCBiZSBubyB3YXkgZm9yIGENCmJyb3dzZXIgdG8gZG8gbm9uLW11eCBhbmQgc28gYXMg YSBwcmFjdGljYWwgbWF0dGVyIHdlIG1pZ2h0IGFzIHdlbGwgc2ltcGx5IHNheSB0aGF0DQpXZWJS VEMgaXMgbXV4IGFuZCBoZW5jZSBmb3IgdGhlIFdlYlJUQyBzaWRlIG9mIGEgV2ViUlRDIGdhdGV3 YXksIHRoZXJlIGlzIHNpbWlsYXJseSBubw0KbmVlZCB0byBzdXBwb3J0IG5vbi1tdXgsIFRoaXMg b25seSBsZWF2ZXMgdGhlIHF1ZXN0aW9uIG9mIHRoZSBub24tV2ViUlRDIHNpZGUgb2YNCnRoZSBn YXRld2F5LCBidXQgdGhhdCdzIG91dCBvZiBzY29wZSBoZXJlLiBTbywgSSdtIG5vdCBzdXJlIHdo YXQgeW91IGFyZSBhc2tpbmcgZm9yLg0KDQpXUlQgdG8gdGhlIGlzc3VlIEpvbmF0aGFuIHJhaXNl cyBhYm91dCBTRFAgYmVpbmcgYSBuZWdvdGlhdGlvbiwgdGhhdCdzIHRydWUsIGJ1dCBhcw0KYSBw cmFjdGljYWwgbWF0dGVyIHdlJ3JlIGFscmVhZHkgZmFyIGRvd24gdGhlIHJvYWQgb2YgV2ViUlRD IG9mZmVyZXJzIG9mZmVyaW5nIFNEUA0Kd2hpY2ggaW4gcHJpbmNpcGxlIHRoZSBhbnN3ZXJlciBt aWdodCBjaG9vc2Ugbm90IHRvIGFjY2VwdCBidXQgaWYgaXQgZG9lcyBzbyB0aGUNCmNvbm5lY3Rp b24gd2lsbCBmYWlsDQoNCi1Fa3INCg0KT24gVGh1LCBBdWcgNiwgMjAxNSBhdCA3OjEyIEFNLCBB c3ZlcmVuLCBUb2xnYSA8dGFzdmVyZW5Ac29udXNuZXQuY29tPG1haWx0bzp0YXN2ZXJlbkBzb251 c25ldC5jb20+PiB3cm90ZToNCkkgdGhpbmsgaW1wbGVtZW50ZXJzIHRoZW1zZWx2ZXMgY2FuIHdl aWdoIG91dCB0aGUgYWR2YW50YWdlcy9kaXNhZHZhbnRhZ2VkL2RlcGxveW1lbnQgbW9kZWxzIHRo ZXkgYXJlIHRhcmdldGluZy9ldGPigKYgYW5kIGRlY2lkZSB3aGF0IHRvIHN1cHBvcnQvbm90IHRv IHN1cHBvcnQuIEkgZG9u4oCZdCBzZWUgYW55IGlzc3VlIHdpdGggdGhpcyBhcyBsb25nIGFzIHRo ZXJlIGlzIGEgbmVnb3RpYXRpb24gbWVjaGFuaXNtICh3aGljaCB0aGVyZSBpcykuIEkgZG9u4oCZ dCB0aGluayB0aGUgYXZhaWxhYmlsaXR5IG9mIG5lZ290aWF0aW9uIGlzIGVuY291cmFnaW5nIHBl b3BsZSB0aGlzIG9yIHRoYXQgd2F5Lg0KDQpUaGFua3MsDQpUb2xnYQ0KDQpGcm9tOiB0aW0gcGFu dG9uIFttYWlsdG86dGltQHBob25lZnJvbWhlcmUuY29tPG1haWx0bzp0aW1AcGhvbmVmcm9taGVy ZS5jb20+XQ0KU2VudDogVGh1cnNkYXksIEF1Z3VzdCAwNiwgMjAxNSAxMDowNyBBTQ0KVG86IEh1 dHRvbiwgQW5kcmV3IDxhbmRyZXcuaHV0dG9uQHVuaWZ5LmNvbTxtYWlsdG86YW5kcmV3Lmh1dHRv bkB1bmlmeS5jb20+Pg0KQ2M6IEFzdmVyZW4sIFRvbGdhIDx0YXN2ZXJlbkBzb251c25ldC5jb208 bWFpbHRvOnRhc3ZlcmVuQHNvbnVzbmV0LmNvbT4+OyA8cnRjd2ViQGlldGYub3JnPG1haWx0bzpy dGN3ZWJAaWV0Zi5vcmc+PiA8cnRjd2ViQGlldGYub3JnPG1haWx0bzpydGN3ZWJAaWV0Zi5vcmc+ Pg0KDQpTdWJqZWN0OiBSZTogW3J0Y3dlYl0gV2hhdCB0aGUgZ2F0ZXdheSBkcmFmdCBzaG91bGQg c2F5IGFib3V0IG11eC9ub24tbXV4DQoNCg0KT24gNiBBdWcgMjAxNSwgYXQgMDg6MzAsIEh1dHRv biwgQW5kcmV3IDxhbmRyZXcuaHV0dG9uQHVuaWZ5LmNvbTxtYWlsdG86YW5kcmV3Lmh1dHRvbkB1 bmlmeS5jb20+PiB3cm90ZToNCg0KKzEgdG8gd2hhdCBUaW0gc2FpZC4NCg0KSSBkb27igJl0IHRo aW5rIHRoaXMgZGlzY3Vzc2lvbiBpcyByZWFsbHkgYWJvdXQgZ2F0ZXdheXMgYXQgYWxsIGl0IGlz IHN1cmVseSBhYm91dCB3aGV0aGVyIFdlYlJUQyBicm93c2VycyBoYXZlIHRvIHN1cHBvcnQgbm9u LW11eCBhbmQgSSBkb27igJl0IHJlYWxseSBzZWUgYW55IGdvb2QgcmVhc29uIHdoeSB0aGV5IG5l ZWQgdG8uDQoNCklmIHdlIGhhZCB0aG91Z2h0IGFib3V0IHRoaXMgYXQgdGhlIHRpbWUgd2UgbWFu ZGF0ZWQgRFRMUy1TUlRQIHRoZW4gd2Ugd291bGQgaGF2ZSBtYW5kYXRlZCBydHAtbXV4IGF0IHRo ZSBzYW1lIHRpbWUgYnV0IHVuZm9ydHVuYXRlbHkgd2UgZGlkbuKAmXQgYnV0IHdlIGNhbiBmaXgg dGhhdCBub3cuDQoNClNhZGx5IHRydWUsIGJ1dCB0aGUgc2l0dWF0aW9uIGluIGEgYnJvd3NlciBp cyBtYW5hZ2VhYmxlIHNpbmNlIHlvdSBtaWdodCBleHBlY3QgMTAgcGVlciBjb25uZWN0aW9ucywg cmVzdWx0aW5nDQppbiBhIHdvcnN0IGNhc2Ugb2YgNjAgVURQIHBvcnRzL0RUTFMgc2Vzc2lvbnMg aW4gdXNlDQooYXNzdW1pbmcgdm9pY2UrdmlkZW8rZGF0YSB1bmJ1bmRsZWQgYW5kIFJUQ1Atbm9u LW11eCB2cyB0aGUgMTAgbmVlZGVkKS4gV2UNCmFsc28gYXNzdW1lIGEgcmVsYXRpdmVseSB3ZWxs IGVuZG93ZWQgQ1BVIC0gZGV2b3RlZCBsYXJnZWx5IHRvIHRoaXMgdGFzay4NCg0KT24gdGhlIGdh dGV3YXkgeW914oCZZCBob3BlIHRvIGhhdmUgdGhvdXNhbmRzIG9mIHNlc3Npb25zIGFuZCBwcmVz dW1hYmx5IG11Y2ggbGVzcyBDUFUvbWVtb3J5IHJlc291cmNlIHBlciBjaGFubmVsLg0KU28gd2hp bGUgSSB0aGluayBpdCBpcyB1bmZvcnR1bmF0ZSB0aGF0IGJyb3dzZXJzIGNhbiBkbyBub24tbXV4 LCBpdCB3b3VsZCBiZSBwbGFpbiBzdHVwaWQgdG8gZG8gdGhhdCBvbiBhIGdhdGV3YXkuIERvIHdl DQpyZWFsbHkgd2FudCB0byBlbmNvdXJhZ2UgdGhhdCA/DQoNClQuDQoNCg0KDQpBbmR5DQoNCg0K RnJvbTogcnRjd2ViIFttYWlsdG86cnRjd2ViLWJvdW5jZXNAaWV0Zi5vcmddIE9uIEJlaGFsZiBP ZiB0aW0gcGFudG9uDQpTZW50OiAwNiBBdWd1c3QgMjAxNSAxMzo1Mw0KVG86IEFzdmVyZW4sIFRv bGdhDQpDYzogPHJ0Y3dlYkBpZXRmLm9yZzxtYWlsdG86cnRjd2ViQGlldGYub3JnPj4NClN1Ympl Y3Q6IFJlOiBbcnRjd2ViXSBXaGF0IHRoZSBnYXRld2F5IGRyYWZ0IHNob3VsZCBzYXkgYWJvdXQg bXV4L25vbi1tdXgNCg0KU28gd2UgYXJlIHBvc2l0aW5nIHRoZSBleGlzdGVuY2Ugb2YgYSB3ZWJS VEMgZ2F0ZXdheSBkZXNpZ25lZCB0byBzdXBwb3J0IHRob3VzYW5kcyBvZiBjYWxscyB3aGljaCBk b2VzIElDRSBhbmQgRFRMUyBidXQgdGhlDQpkZXNpZ25lciBkZWNpZGVkIGRlbGliZXJhdGVseSB0 byBkb3VibGUgdGhlIG51bWJlciBvZiBJQ0Ugc2Vzc2lvbnMgcmVxdWlyZWQgYW5kIGRvdWJsZSB0 aGUgbnVtYmVyIG9mIERUTFMgc2Vzc2lvbnMgKGFuZCBrZXkNCmdlbmVyYXRpb24gY29zdHMpIHNv IHRoYXQgdGhleSBjYW4gcnVuIFJUQ1AgKG92ZXIgSUNFIGFuZCBEVExTKSBvbiBhIHNlcGFyYXRl IHBvcnQuIEluIG15IGVzdGltYXRpb24gdGhhdOKAmXMgb25lIHBvb3IgZGVjaXNpb24NCmFuZCBz aG91bGQgbm90IGJlIHVzZWQgYXMgdGhlIGJhc2lzIG9mIHRoaXMgKG9yIGFueSkgc3RhbmRhcmQu DQoNCknigJlkIHJhdGhlciBub3Qgc3VwcG9ydCBydGNwLW5vLW11eCBhcyBJIHNlZSB6ZXJvIGFk dmFudGFnZXMgaW4gaGF2aW5nIGl0LiAoSSBrbm93IHRoZW9yZXRpY2FsbHkgaXQgbWlnaHQgYmUg cG9zc2libGUgdG8gZ2V0DQphIFJUQ1AgcGFja2V0IHRocm91Z2ggYSBjb25nZXN0ZWQgbmV0IG9u IGEgZGlmZmVyZW50IHBvcnQgd2l0aCBhIHNlcGFyYXRlIGRpZmZzZXJ2IHNldHRpbmcgYnV0IHRo YXQganVzdCBzZWVtcyBzbyBjb250cml2ZWQpLg0KDQpUaW0uDQoNCg0KT24gNiBBdWcgMjAxNSwg YXQgMDY6NDQsIEFzdmVyZW4sIFRvbGdhIDx0YXN2ZXJlbkBzb251c25ldC5jb208bWFpbHRvOnRh c3ZlcmVuQHNvbnVzbmV0LmNvbT4+IHdyb3RlOg0KDQpUaGVzZSBhc3N1bXB0aW9ucyBhcmUgbm90 IG5lY2Vzc2FyaWx5IHRydWUgaW4gYSB1bml2ZXJzYWwgc2Vuc2UgKGxpa2UgYWxtb3N0IGFueSBv dGhlciBhc3N1bXB0aW9uIGFib3V0IGRpZmZlcmVudCBkZXBsb3ltZW50IG1vZGVscykuDQoNCkZ1 cnRoZXJtb3JlLCBhbmQgbW9yZSBpbXBvcnRhbnRseSwgdGhlcmUgaXMgbm90aGluZyBtYW5kYXRp bmcgV2ViUlRDIGVuZHBvaW50cyB0byBzdXBwb3J0IG5vbi1ydGNwLW11eC4gSXQgaXMgYSBuZWdv dGlhdGVkIGZ1bmN0aW9uYWxpdHkuIEFueSBlbnRpdHkgY2FuIGVuZm9yY2UgcnRjcC1tdXggYXMg YSBsb2NhbCBwb2xpY3kuDQoNClRoZSBpc3N1ZSB3aXRoIHN1cHBvcnRpbmcgbm9uLXJ0Y3AtbXV4 IHNlZW1zIHRvIGJlIGxhY2sgb2YgY2xhcml0eSBpbiB0aGUgcmVsZXZhbnQgc3BlY2lmaWNhdGlv bnMuIEZpeGluZyB0aGlzIOKAk3JlZ2FyZGxlc3Mgb2YgdGhlIG91dGNvbWUgb2YgYW55IG90aGVy IGRpc2N1c3Npb24tIHNlZW1zIHRvIGJlIHBydWRlbnQgSU1ITy4NCg0KVGhhbmtzLA0KVG9sZ2EN Cg0KRnJvbTogV3lzcywgRmVsaXggW21haWx0bzpGZWxpeC5XeXNzQGluaW4uY29tXQ0KU2VudDog VGh1cnNkYXksIEF1Z3VzdCAwNiwgMjAxNSA2OjM3IEFNDQpUbzogQ2hyaXN0ZXIgSG9sbWJlcmcg PGNocmlzdGVyLmhvbG1iZXJnQGVyaWNzc29uLmNvbTxtYWlsdG86Y2hyaXN0ZXIuaG9sbWJlcmdA ZXJpY3Nzb24uY29tPj47IEFzdmVyZW4sIFRvbGdhIDx0YXN2ZXJlbkBzb251c25ldC5jb208bWFp bHRvOnRhc3ZlcmVuQHNvbnVzbmV0LmNvbT4+OyBTY2h3YXJ6LCBBbGJyZWNodCAoQWxicmVjaHQp IDxhbGJyZWNodC5zY2h3YXJ6QGFsY2F0ZWwtbHVjZW50LmNvbTxtYWlsdG86YWxicmVjaHQuc2No d2FyekBhbGNhdGVsLWx1Y2VudC5jb20+PjsgUm9tYW4gU2hwb3VudCA8cm9tYW5AdGVsdXJpeC5j b208bWFpbHRvOnJvbWFuQHRlbHVyaXguY29tPj47IFJhdXNjaGVuYmFjaCwgVXdlIChOb2tpYSAt IERFL011bmljaCkgPHV3ZS5yYXVzY2hlbmJhY2hAbm9raWEuY29tPG1haWx0bzp1d2UucmF1c2No ZW5iYWNoQG5va2lhLmNvbT4+DQpDYzogPHJ0Y3dlYkBpZXRmLm9yZzxtYWlsdG86cnRjd2ViQGll dGYub3JnPj4gPHJ0Y3dlYkBpZXRmLm9yZzxtYWlsdG86cnRjd2ViQGlldGYub3JnPj4NClN1Ympl Y3Q6IFJlOiBbcnRjd2ViXSBXaGF0IHRoZSBnYXRld2F5IGRyYWZ0IHNob3VsZCBzYXkgYWJvdXQg bXV4L25vbi1tdXgNCg0KV2h5IHNob3VsZG4ndCB0aGUgZ2F0ZXdheSBiZSByZXF1aXJlZCB0byBk byB0aGUgbXV4L2RlbXV4PyAgTWFraW5nIHRoZSBXZWJSVEMgZW5kcG9pbnRzIGEgbG90IG1vcmUg Y29tcGxleCBqdXN0IHNvIHRoZSBsZWdhY3kgaW50ZXJvcCBtaWdodCBwb3RlbnRpYWxseSBiZSBh IHRlZW55LXRpbnkgYml0IGVhc2llciBtYWtlcyBubyBzZW5zZSBJTUhPLiAgQWN0dWFsbHksIHRo ZSBnYXRld2F5IHdvdWxkIG5vdCBiZSBhYmxlIHRvIGRvICJlbmQtdG8tZW5kIiBwYXNzLXRocm91 Z2ggYW55d2F5IGFzIGxlZ2FjeSBlcXVpcG1lbnQgd2lsbCBlaXRoZXIgYmUgdW5lbmNyeXB0ZWQg b3IgdXNlIFNERVMgKFJGQyM0NTY4KSBmb3Iga2V5IGV4Y2hhbmdlLiAgU28gdGhlIGdhdGV3YXkg d2lsbCBoYXZlIHRvIHBlcmZvcm0gRFRMUy1TUlRQIHRvIFNERVMtU1JUUCB0cmFuc2NyeXB0aW9u LS13aGljaCBhbHJlYWR5IGlzIHdheSBtb3JlIGhhc3NsZSB0aGFuIFJUUC9SVENQIG11eC9kZW11 eC4NCg0KLS1GZWxpeA0KDQpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KRnJvbTog cnRjd2ViIDxydGN3ZWItYm91bmNlc0BpZXRmLm9yZzxtYWlsdG86cnRjd2ViLWJvdW5jZXNAaWV0 Zi5vcmc+PiBvbiBiZWhhbGYgb2YgQ2hyaXN0ZXIgSG9sbWJlcmcgPGNocmlzdGVyLmhvbG1iZXJn QGVyaWNzc29uLmNvbTxtYWlsdG86Y2hyaXN0ZXIuaG9sbWJlcmdAZXJpY3Nzb24uY29tPj4NClNl bnQ6IFRodXJzZGF5LCBBdWd1c3QgNiwgMjAxNSAwNTo1MQ0KVG86IEFzdmVyZW4sIFRvbGdhOyBT Y2h3YXJ6LCBBbGJyZWNodCAoQWxicmVjaHQpOyBSb21hbiBTaHBvdW50OyBSYXVzY2hlbmJhY2gs IFV3ZSAoTm9raWEgLSBERS9NdW5pY2gpDQpDYzogPHJ0Y3dlYkBpZXRmLm9yZzxtYWlsdG86cnRj d2ViQGlldGYub3JnPj4NClN1YmplY3Q6IFJlOiBbcnRjd2ViXSBXaGF0IHRoZSBnYXRld2F5IGRy YWZ0IHNob3VsZCBzYXkgYWJvdXQgbXV4L25vbi1tdXgNCg0KSGksDQoNCk5vIG1hdHRlciB3aGV0 aGVyIHRoZSBnYXRld2F5IHN1cHBvcnRzIFJUUC9SVENQIG11eCBvciBub3QsIHRoZXJlIGFyZSBj YXNlcyB3aGVyZSB0aGUgbGVnYWN5IG5ldHdvcmsvZW5kcG9pbnRzIHdpbGwgbm90IHVzZSBSVFAv UlRDUCBtdXgsIHNvIEkgZ3Vlc3MgcGVvcGxlIHRoZW4gd291bGQgd2FudCB0byBiZSBhYmxlIHRv IG5lZ290aWF0ZSBub24tbXV4IOKAnGVuZC10by1lbmTigJ0sIHJhdGhlciB0aGFuIGhhdmluZyB0 aGUgZ2F0ZXdheSB0byBkZW11eC9tdXggUlRQIGFuZCBSVENQLg0KDQpSZWdhcmRzLA0KDQpDaHJp c3Rlcg0KDQpGcm9tOiBBc3ZlcmVuLCBUb2xnYSBbbWFpbHRvOnRhc3ZlcmVuQHNvbnVzbmV0LmNv bV0NClNlbnQ6IDYuIGVsb2t1dXRhIDIwMTUgMTI6MTgNClRvOiBTY2h3YXJ6LCBBbGJyZWNodCAo QWxicmVjaHQpOyBSb21hbiBTaHBvdW50OyBSYXVzY2hlbmJhY2gsIFV3ZSAoTm9raWEgLSBERS9N dW5pY2gpDQpDYzogZXh0IEVyaWMgUmVzY29ybGE7IENocmlzdGVyIEhvbG1iZXJnOyBCZXJuYXJk IEFib2JhOyA8cnRjd2ViQGlldGYub3JnPG1haWx0bzpydGN3ZWJAaWV0Zi5vcmc+Pg0KU3ViamVj dDogUmU6IFtydGN3ZWJdIFdoYXQgdGhlIGdhdGV3YXkgZHJhZnQgc2hvdWxkIHNheSBhYm91dCBt dXgvbm9uLW11eA0KDQpXaHkgc2hvdWxkIHdlIGNvbnNpZGVyIDNHUFAgdGhlIHNvbGUgIm93bmVy L3VzZXIiIG9mIHRoZSB0ZXJtL2VudGl0eSBXZWJSVEMtR1c/IEkgdGhpbmsgaXQgaGFzIGEgbXVj aCBtb3JlIGdlbmVyYWwgbWVhbmluZyBhbmQgdXNlIGluIHByYWN0aWNlLiBJdCBjYW4gcmVmZXIg dG8gbWFueSBkaWZmZXJlbnQgdHlwZXMgb2YgZWxlbWVudHMgd2hpY2ggY2FuIGJlIGRlcGxveWVk IGluIG1hbnkgZGlmZmVyZW50IGVudmlyb25tZW50cywgaGVuY2UgYW55IGF0dGVtcHQgdG8gZGVm aW5lIGl0IHN0cmljdGx5L3Jlc3RyaWN0IGl0cyBjYXBhYmlsaXRpZXMgYXJlIGZ1dGlsZSBJTUhP Lg0KDQpUaGFua3MsDQpUb2xnYQ0KDQpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0K RnJvbTogU2Nod2FyeiwgQWxicmVjaHQgKEFsYnJlY2h0KSA8YWxicmVjaHQuc2Nod2FyekBhbGNh dGVsLWx1Y2VudC5jb208bWFpbHRvOmFsYnJlY2h0LnNjaHdhcnpAYWxjYXRlbC1sdWNlbnQuY29t Pj4NClNlbnQ6IFRodXJzZGF5LCBBdWd1c3QgNiwgMjAxNSAyOjQ0IEFNDQpUbzogQXN2ZXJlbiwg VG9sZ2E7IFJvbWFuIFNocG91bnQ7IFJhdXNjaGVuYmFjaCwgVXdlIChOb2tpYSAtIERFL011bmlj aCkNCkNjOiBleHQgRXJpYyBSZXNjb3JsYTsgQ2hyaXN0ZXIgSG9sbWJlcmc7IEJlcm5hcmQgQWJv YmE7IDxydGN3ZWJAaWV0Zi5vcmc8bWFpbHRvOnJ0Y3dlYkBpZXRmLm9yZz4+DQpTdWJqZWN0OiBS RTogW3J0Y3dlYl0gV2hhdCB0aGUgZ2F0ZXdheSBkcmFmdCBzaG91bGQgc2F5IGFib3V0IG11eC9u b24tbXV4DQoNClRoZSBjb25jZXJuZWQgM0dQUCBXZWJSVEMgZ2F0ZXdheSAoM0dQUCAyMy4zMzQv MjkuMzM0KSBzdXBwb3J0cyBhbHJlYWR5IFJUUC9SVENQIHRyYW5zcG9ydCBtdWx0aXBsZXhpbmcg KHNpbmNlIDNHUFAgUmVsZWFzZSAxMiksIGkuZS4gc2hvdWxkIG5vdCBiZSB0aGUgbGltaXRpbmcg ZmFjdG9yIGluIHRoaXMgZGlzY3Vzc2lvbi4NCkZvciBvbmVzIGludGVyZXN0ZWQgaW4gdGhlIFJU Q1AgcG9ydCBhbGxvY2F0aW9uIHJ1bGVzLCBzZWUgSC4yNDguNTc6DQpodHRwczovL3d3dy5pdHUu aW50L3JlYy9kb2xvZ2luX3B1Yi5hc3A/bGFuZz1lJmlkPVQtUkVDLUguMjQ4LjU3LTIwMTQxMC1J ISFQREYtRSZ0eXBlPWl0ZW1zDQpDbGF1c2UgNyBkZXNjcmliZXMgUlRQL1JUQ1AgdHJhbnNwb3J0 IG11bHRpcGxleGluZy4gSVRVLVQgSC4yNDguNTcgaXMgYWxyZWFkeSBzdXBwb3J0ZWQgYnkgM0dQ UCAyOS4zMzQuDQoNClRoZSByYXRpb25hbGUgYmVoaW5kIHRoZSDigJxvcHRpb25hbCB0YWdnaW5n 4oCdIGJ5IDIzLjIyOCBpcyBhIHRoaXJkIHJlYXNvbiwgYmV5b25kDQo+MS4gVXNpbmcgZGlmZmVy ZW50IFFPUyBzZXR0aW5ncyBmb3IgUlRDUCB2cyBSVFANCj4yLiBTZW5kaW5nIFJUQ1AgdG8gYSBk aWZmZXJlbnQgZGV2aWNlIGZyb20gUlRQDQoNCkRvbuKAmXQgd2FudCB0byBnbyBpbiB0aGUgM0dQ UCBzcGVjaWZpYyBkZXRhaWxzLCBidXQgaXQgaGFzIG5vdGhpbmcgdG8gZG8gd2l0aCB0aGUgM0dQ UCBVRS1lbWJlZGRlZCBXZWJSVEMgY2xpZW50IG5vciBhbnkgY29uc3RyYWludHMgYnkgM0dQUCBX ZWJSVEMgZ2F0ZXdheXMuDQoNClRodXMsIGEgV2ViUlRDIGdhdGV3YXkgTVVTVCBzdXBwb3J0IFJU UC9SVENQIHRyYW5zcG9ydCBtdWx0aXBsZXhpbmcgZHVlIHRvIGl0cyBwdXJwb3NlIGluIGludGVy d29ya2luZyBzdXBwb3J0Lg0KDQpSZWdhcmRzLA0KQWxicmVjaHQNCg0KDQpGcm9tOiBBc3ZlcmVu LCBUb2xnYSBbbWFpbHRvOnRhc3ZlcmVuQHNvbnVzbmV0LmNvbV0NClNlbnQ6IE1pdHR3b2NoLCA1 LiBBdWd1c3QgMjAxNSAxOTo0Nw0KVG86IFJvbWFuIFNocG91bnQ7IFJhdXNjaGVuYmFjaCwgVXdl IChOb2tpYSAtIERFL011bmljaCkNCkNjOiBleHQgRXJpYyBSZXNjb3JsYTsgU2Nod2FyeiwgQWxi cmVjaHQgKEFsYnJlY2h0KTsgQ2hyaXN0ZXIgSG9sbWJlcmc7IEJlcm5hcmQgQWJvYmE7IDxydGN3 ZWJAaWV0Zi5vcmc8bWFpbHRvOnJ0Y3dlYkBpZXRmLm9yZz4+DQpTdWJqZWN0OiBSRTogW3J0Y3dl Yl0gV2hhdCB0aGUgZ2F0ZXdheSBkcmFmdCBzaG91bGQgc2F5IGFib3V0IG11eC9ub24tbXV4DQoN CmktIEkgaHVtYmx5IGRpc2FncmVlIHRoYXQgdXNpbmcgZGlmZmVyZW50IFFvUyBSVENQL1JUUCwg ZS5nLiBkaWZmZXJlbnQgRGlmZlNlcnYgdmFsdWVzICwgc2hvdWxkIGJlIGRpc21pc3NlZC4NCmlp LSBMZXQgbWUgYWxzbyBhZGQgYW5vdGhlciByZWFzb24gd2h5IG5vLXJ0Y3AtbXV4IG1heSBiZSBu ZWVkZWQ6IEltcGxlbWVudGF0aW9uIGRpZmZpY3VsdGllcyBpbiBjZXJ0YWluIEdXcy4NCg0KQ29u c2lkZXJpbmcgdGhhdCB0aGVyZSBpcyBhbHJlYWR5IGEgbmVnb3RpYXRpb24gbWVjaGFuaXNtIGZv ciBydGNwLW11eCBzdXBwb3J0LCB0aGF0IGl0IGNhbiBiZSBkZS1mYWN0byBtYW5kYXRlZCBieSB0 aGUgY2hvaWNlIG9mIGJyb3dzZXJzIGZvciBJbnRlcm5ldCwgSSB0aGluayB3aGF0IENocmlzdGVy L0FsYnJlY2h0IHN1Z2dlc3RlZCBpcyB0aGUgcmlnaHQgd2F5IHRvIG1vdmUgZm9yd2FyZDogcHJv dmlkZSBjbGFyaWZpY2F0aW9ucyBmb3IgdmFndWUgcG9pbnRzLiBJIGRvbuKAmXQgdW5kZXJzdGFu ZCB3aHkgbGFjayBvZiBjbGFyaXR5IGluIGV4aXN0aW5nIHNwZWNpZmljYXRpb25zIHNob3VsZCBj YXVzZSBpbXBvc2luZyByZXN0cmljdGlvbnMuIFRoaXMgd291bGQgYmUgYWtpbiB0byBkcm9wcGlu ZyBhIGZlYXR1cmUgZHVlIHRvIGEgYnVnLiBJbiB0aGlzIGNhc2UsIHRoZSDigJxidWfigJ0gaXMg bGFjayBvZiBjbGFyaXR5IGluIG5vcm1hdGl2ZSBzcGVjaWZpY2F0aW9ucyBhbmQgaXQgY2FuIGJl IGFkZHJlc3NlZCBieSBmdXJ0aGVyIHNwZWNpZmljYXRpb24uDQoNClRoYW5rcywNClRvbGdhDQoN CkZyb206IFJvbWFuIFNocG91bnQgW21haWx0bzpyb21hbkB0ZWx1cml4LmNvbV0NClNlbnQ6IFdl ZG5lc2RheSwgQXVndXN0IDA1LCAyMDE1IDEyOjI5IFBNDQpUbzogUmF1c2NoZW5iYWNoLCBVd2Ug KE5va2lhIC0gREUvTXVuaWNoKSA8dXdlLnJhdXNjaGVuYmFjaEBub2tpYS5jb208bWFpbHRvOnV3 ZS5yYXVzY2hlbmJhY2hAbm9raWEuY29tPj4NCkNjOiBleHQgRXJpYyBSZXNjb3JsYSA8ZWtyQHJ0 Zm0uY29tPG1haWx0bzpla3JAcnRmbS5jb20+PjsgU2Nod2FyeiwgQWxicmVjaHQgKEFsYnJlY2h0 KSA8YWxicmVjaHQuc2Nod2FyekBhbGNhdGVsLWx1Y2VudC5jb208bWFpbHRvOmFsYnJlY2h0LnNj aHdhcnpAYWxjYXRlbC1sdWNlbnQuY29tPj47IEFzdmVyZW4sIFRvbGdhIDx0YXN2ZXJlbkBzb251 c25ldC5jb208bWFpbHRvOnRhc3ZlcmVuQHNvbnVzbmV0LmNvbT4+OyBDaHJpc3RlciBIb2xtYmVy ZyA8Y2hyaXN0ZXIuaG9sbWJlcmdAZXJpY3Nzb24uY29tPG1haWx0bzpjaHJpc3Rlci5ob2xtYmVy Z0Blcmljc3Nvbi5jb20+PjsgQmVybmFyZCBBYm9iYSA8YmVybmFyZC5hYm9iYUBnbWFpbC5jb208 bWFpbHRvOmJlcm5hcmQuYWJvYmFAZ21haWwuY29tPj47IDxydGN3ZWJAaWV0Zi5vcmc8bWFpbHRv OnJ0Y3dlYkBpZXRmLm9yZz4+IDxydGN3ZWJAaWV0Zi5vcmc8bWFpbHRvOnJ0Y3dlYkBpZXRmLm9y Zz4+DQpTdWJqZWN0OiBSZTogW3J0Y3dlYl0gV2hhdCB0aGUgZ2F0ZXdheSBkcmFmdCBzaG91bGQg c2F5IGFib3V0IG11eC9ub24tbXV4DQoNCk9uIFdlZCwgQXVnIDUsIDIwMTUgYXQgNDo0NyBBTSwg UmF1c2NoZW5iYWNoLCBVd2UgKE5va2lhIC0gREUvTXVuaWNoKSA8dXdlLnJhdXNjaGVuYmFjaEBu b2tpYS5jb208bWFpbHRvOnV3ZS5yYXVzY2hlbmJhY2hAbm9raWEuY29tPj4gd3JvdGU6DQpNZWRp YSBnYXRld2F5IGltcGxlbWVudGF0aW9ucyBhY2NvcmRpbmcgdG8gM0dQUCBUUyAyMy4yMjggbWF5 IG5vdCBzdXBwb3J0IHJ0Y3AtbXV4LCBhcyBydGNwLW11eCBpcyBvcHRpb25hbCB0aGVyZS4NClNv IGlmIHdlIGRyb3Agbm9uLW11eCBzdXBwb3J0IGZyb20gd2ViIGJyb3dzZXJzLCB0aG9zZSBtZWRp YSBnYXRld2F5cyB0aGF0IGhhdmUgbm90IGltcGxlbWVudGVkIHJ0Y3AtbXV4IHdpbGwgc3RvcCBp bnRlcm9wZXJhdGluZy4NCg0KDQpGaXJzdCBvZiBhbGwsIGRvIHlvdSBrbm93IG9mIGFueSBXZWJS VEMgdG8gSU1TIGdhdGV3YXlzIHRoYXQgZG8gbm90IGltcGxlbWVudCBydGNwLW11eCBvbiB0aGUg V2ViUlRDIHNpZGU/IEkgc3Ryb25nbHkgc3VzcGVjdCB0aGVyZSBhcmUgbm9uZS4NCg0KU2Vjb25k LCB0aGUgb25seSByZWFzb25zIG5vdCB0byB1c2UgcnRjcC1tdXggdGhhdCBJIGNhbiB0aGluayBv ZiBhcmUgdGhlIGZvbGxvd2luZzoNCg0KMS4gVXNpbmcgZGlmZmVyZW50IFFPUyBzZXR0aW5ncyBm b3IgUlRDUCB2cyBSVFANCjIuIFNlbmRpbmcgUlRDUCB0byBhIGRpZmZlcmVudCBkZXZpY2UgZnJv bSBSVFANCg0KSSBkbyBub3QgdGhpbmsgdGhlIGZpcnN0IHVzZSBjYXNlIHdhcnJhbnRzIG1ha2lu ZyBydGNwLW11eCBvcHRpb25hbCwgc2luY2UsIHByYWN0aWNhbGx5IG5vIG9uZSBkb2VzIHRoaXMu DQpTZWNvbmQgdXNlIGNhc2UgaXMgYWxzbyBmYWlybHkgbWFyZ2luYWwuIFBsdXMgaXQgY2FuIGJl IGhhbmRsZWQgYnkgdGhlIGdhdGV3YXkgd2hpY2ggY2FuIHNlbmQgUlRDUCB0byBvbmUgZGV2aWNl IGFuZCBSVFAgdG8gYW5vdGhlci4NCg0KU28sIHVubGVzcyBzb21lb25lIGNhbiBjb21lIHVwIHdp dGggYSB1c2UgY2FzZSB3aHkgUlRQIGFuZCBSVENQIHNob3VsZCB1c2UgZGlmZmVyZW50IHRyYW5z cG9ydHMsIEkgdGhpbmsgcnRjcC1tdXggc2hvdWxkIGJlIG1hbmRhdG9yeS4NCg0KUmVnYXJkcywN Cl9fX19fX19fX19fX19fDQpSb21hbiBTaHBvdW50DQpfX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fXw0KcnRjd2ViIG1haWxpbmcgbGlzdA0KcnRjd2ViQGlldGYu b3JnPG1haWx0bzpydGN3ZWJAaWV0Zi5vcmc+DQpodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFu L2xpc3RpbmZvL3J0Y3dlYg0KDQoNCg0KX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX18NCnJ0Y3dlYiBtYWlsaW5nIGxpc3QNCnJ0Y3dlYkBpZXRmLm9yZzxtYWls dG86cnRjd2ViQGlldGYub3JnPg0KaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5m by9ydGN3ZWINCg0K --_000_SN1PR0301MB1551DF26DBA0FEBB61A92107B2740SN1PR0301MB1551_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPCEtLVtp ZiAhbXNvXT48c3R5bGU+dlw6KiB7YmVoYXZpb3I6dXJsKCNkZWZhdWx0I1ZNTCk7fQ0Kb1w6KiB7 YmVoYXZpb3I6dXJsKCNkZWZhdWx0I1ZNTCk7fQ0Kd1w6KiB7YmVoYXZpb3I6dXJsKCNkZWZhdWx0 I1ZNTCk7fQ0KLnNoYXBlIHtiZWhhdmlvcjp1cmwoI2RlZmF1bHQjVk1MKTt9DQo8L3N0eWxlPjwh W2VuZGlmXS0tPjxzdHlsZT48IS0tDQovKiBGb250IERlZmluaXRpb25zICovDQpAZm9udC1mYWNl DQoJe2ZvbnQtZmFtaWx5OkhlbHZldGljYTsNCglwYW5vc2UtMToyIDExIDYgNCAyIDIgMiAyIDIg NDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OiJDYW1icmlhIE1hdGgiOw0KCXBhbm9zZS0x OjIgNCA1IDMgNSA0IDYgMyAyIDQ7fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseTpDYWxpYnJp Ow0KCXBhbm9zZS0xOjIgMTUgNSAyIDIgMiA0IDMgMiA0O30NCkBmb250LWZhY2UNCgl7Zm9udC1m YW1pbHk6VGFob21hOw0KCXBhbm9zZS0xOjIgMTEgNiA0IDMgNSA0IDQgMiA0O30NCkBmb250LWZh Y2UNCgl7Zm9udC1mYW1pbHk6Q29uc29sYXM7DQoJcGFub3NlLTE6MiAxMSA2IDkgMiAyIDQgMyAy IDQ7fQ0KLyogU3R5bGUgRGVmaW5pdGlvbnMgKi8NCnAuTXNvTm9ybWFsLCBsaS5Nc29Ob3JtYWws IGRpdi5Nc29Ob3JtYWwNCgl7bWFyZ2luOjBpbjsNCgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJ Zm9udC1zaXplOjEyLjBwdDsNCglmb250LWZhbWlseToiVGltZXMgTmV3IFJvbWFuIixzZXJpZjt9 DQphOmxpbmssIHNwYW4uTXNvSHlwZXJsaW5rDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCglj b2xvcjpibHVlOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0KYTp2aXNpdGVkLCBzcGFu Lk1zb0h5cGVybGlua0ZvbGxvd2VkDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgljb2xvcjpw dXJwbGU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQpwDQoJe21zby1zdHlsZS1wcmlv cml0eTo5OTsNCgltc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzsNCgltYXJnaW4tcmlnaHQ6MGluOw0K CW1zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvOw0KCW1hcmdpbi1sZWZ0OjBpbjsNCglmb250LXNp emU6MTIuMHB0Ow0KCWZvbnQtZmFtaWx5OiJUaW1lcyBOZXcgUm9tYW4iLHNlcmlmO30NCnNwYW4u RW1haWxTdHlsZTE4DQoJe21zby1zdHlsZS10eXBlOnBlcnNvbmFsLXJlcGx5Ow0KCWZvbnQtZmFt aWx5OiJDYWxpYnJpIixzYW5zLXNlcmlmOw0KCWNvbG9yOiMxRjQ5N0Q7fQ0KLk1zb0NocERlZmF1 bHQNCgl7bXNvLXN0eWxlLXR5cGU6ZXhwb3J0LW9ubHk7DQoJZm9udC1mYW1pbHk6IkNhbGlicmki LHNhbnMtc2VyaWY7fQ0KQHBhZ2UgV29yZFNlY3Rpb24xDQoJe3NpemU6OC41aW4gMTEuMGluOw0K CW1hcmdpbjoxLjBpbiAxLjBpbiAxLjBpbiAxLjBpbjt9DQpkaXYuV29yZFNlY3Rpb24xDQoJe3Bh Z2U6V29yZFNlY3Rpb24xO30NCi0tPjwvc3R5bGU+PCEtLVtpZiBndGUgbXNvIDldPjx4bWw+DQo8 bzpzaGFwZWRlZmF1bHRzIHY6ZXh0PSJlZGl0IiBzcGlkbWF4PSIxMDI2IiAvPg0KPC94bWw+PCFb ZW5kaWZdLS0+PCEtLVtpZiBndGUgbXNvIDldPjx4bWw+DQo8bzpzaGFwZWxheW91dCB2OmV4dD0i ZWRpdCI+DQo8bzppZG1hcCB2OmV4dD0iZWRpdCIgZGF0YT0iMSIgLz4NCjwvbzpzaGFwZWxheW91 dD48L3htbD48IVtlbmRpZl0tLT4NCjwvaGVhZD4NCjxib2R5IGxhbmc9IkVOLVVTIiBsaW5rPSJi bHVlIiB2bGluaz0icHVycGxlIj4NCjxkaXYgY2xhc3M9IldvcmRTZWN0aW9uMSI+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTom cXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RCI+SW4gcHJhY3RpY2Ug 4oCTaWYgbm90IGFzIGluaXRpYWxseSB0YXJnZXRlZC0gYSBXZWJSVEMtZW5kcG9pbnQgZG9lcyBu b3QgbmVjZXNzYXJpbHkgbWVhbiBhIOKAnGJyb3dzZXLigJ0uIEkgY29tcGxldGVseSBhZ3JlZSB3 aXRoIG91ciBzdGF0ZW1lbnRzIGFib3V0IGJyb3dzZXIgYmFzZWQNCiBkZXBsb3ltZW50cyB0aG91 Z2guIEFsbCBJIGFtIHNheWluZyBpcyDigJxMZXQgcGVvcGxlIGRlY2lkZSB3aGF0IHRoZXkgd2Fu dCB0byBzdXBwb3J0LCB0aGV5IGFyZSBzbWFydCBlbm91Z2ggdG8ga25vdyB3aGF0IGEgcGFydGlj dWxhciBkZXBsb3ltZW50IG1vZGVsIHJlcXVpcmVz4oCdLiBGb3IgZXhhbXBsZSwgcmVnYXJkbGVz cyBvZiB3aGF0IHNwZWNpZmljYXRpb25zIHNheSwgbm9uLWJyb3dzZXIgZXF1aXBtZW50IHZlbmRv cnMsIHdob3NlIHByb2R1Y3RzDQogbmVlZCB0byBpbnRlcm9wZXJhdGUgd2l0aCBicm93c2Vycywg YXJlIGZvbGxvd2luZy9pbXBsZW1lbnRpbmcgaG93IENocm9tZS9GaXJlZm94IGFyZSBiZWhhdmlu Zy48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHls ZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMt c2VyaWY7Y29sb3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6 JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0QiPlRoYW5rcyw8bzpw PjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9u dC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7 Y29sb3I6IzFGNDk3RCI+VG9sZ2E8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtD YWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8L286cD48 L3NwYW4+PC9wPg0KPGRpdiBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLWxlZnQ6c29saWQgYmx1 ZSAxLjVwdDtwYWRkaW5nOjBpbiAwaW4gMGluIDQuMHB0Ij4NCjxkaXY+DQo8ZGl2IHN0eWxlPSJi b3JkZXI6bm9uZTtib3JkZXItdG9wOnNvbGlkICNFMUUxRTEgMS4wcHQ7cGFkZGluZzozLjBwdCAw aW4gMGluIDBpbiI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48Yj48c3BhbiBzdHlsZT0iZm9udC1z aXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWYiPkZy b206PC9zcGFuPjwvYj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTom cXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWYiPiBFcmljIFJlc2NvcmxhIFttYWlsdG86ZWty QHJ0Zm0uY29tXQ0KPGJyPg0KPGI+U2VudDo8L2I+IFRodXJzZGF5LCBBdWd1c3QgMDYsIDIwMTUg MTA6MzYgQU08YnI+DQo8Yj5Ubzo8L2I+IEFzdmVyZW4sIFRvbGdhICZsdDt0YXN2ZXJlbkBzb251 c25ldC5jb20mZ3Q7PGJyPg0KPGI+Q2M6PC9iPiB0aW0gcGFudG9uICZsdDt0aW1AcGhvbmVmcm9t aGVyZS5jb20mZ3Q7OyBIdXR0b24sIEFuZHJldyAmbHQ7YW5kcmV3Lmh1dHRvbkB1bmlmeS5jb20m Z3Q7OyAmbHQ7cnRjd2ViQGlldGYub3JnJmd0OyAmbHQ7cnRjd2ViQGlldGYub3JnJmd0Ozxicj4N CjxiPlN1YmplY3Q6PC9iPiBSZTogW3J0Y3dlYl0gV2hhdCB0aGUgZ2F0ZXdheSBkcmFmdCBzaG91 bGQgc2F5IGFib3V0IG11eC9ub24tbXV4PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8 L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPGRpdj4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPkkgZmVlbCBsaWtlIHBlb3BsZSBhcmUgdGFsa2luZyBwYXN0 IGVhY2ggb3RoZXIgaGVyZS48bzpwPjwvbzpwPjwvcD4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPlRoZSBicm93c2VyIHZlbmRvcnMgKGF0IGxlYXN0IENocm9tZSBhbmQgRmlyZWZveCkg d2FudCB0byBjb21wbGV0ZWx5IHJlbW92ZSBzdXBwb3J0IGZvcjxvOnA+PC9vOnA+PC9wPg0KPC9k aXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+bm9uLW11eCBmcm9tIHRoZWlyIGNvZGUu IElmIHdlIG1ha2UgdGhpcyBjaGFuZ2UsIHRoYXQgbWVhbnMgdGhhdCB0aGVyZSB3aWxsIGJlIG5v IHdheSBmb3IgYTxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+YnJvd3NlciB0byBkbyBub24tbXV4IGFuZCBzbyBhcyBhIHByYWN0aWNhbCBtYXR0ZXIg d2UgbWlnaHQgYXMgd2VsbCBzaW1wbHkgc2F5IHRoYXQ8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0K PGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPldlYlJUQyBpcyBtdXggYW5kIGhlbmNlIGZvciB0 aGUgV2ViUlRDIHNpZGUgb2YgYSBXZWJSVEMgZ2F0ZXdheSwgdGhlcmUgaXMgc2ltaWxhcmx5IG5v PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5uZWVk IHRvIHN1cHBvcnQgbm9uLW11eCwgVGhpcyBvbmx5IGxlYXZlcyB0aGUgcXVlc3Rpb24gb2YgdGhl IG5vbi1XZWJSVEMgc2lkZSBvZjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+dGhlIGdhdGV3YXksIGJ1dCB0aGF0J3Mgb3V0IG9mIHNjb3BlIGhlcmUu IFNvLCBJJ20gbm90IHN1cmUgd2hhdCB5b3UgYXJlIGFza2luZyBmb3IuPG86cD48L286cD48L3A+ DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwv cD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPldSVCB0byB0aGUgaXNzdWUg Sm9uYXRoYW4gcmFpc2VzIGFib3V0IFNEUCBiZWluZyBhIG5lZ290aWF0aW9uLCB0aGF0J3MgdHJ1 ZSwgYnV0IGFzPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj5hIHByYWN0aWNhbCBtYXR0ZXIgd2UncmUgYWxyZWFkeSBmYXIgZG93biB0aGUgcm9hZCBv ZiBXZWJSVEMgb2ZmZXJlcnMgb2ZmZXJpbmcgU0RQPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxk aXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj53aGljaCBpbiBwcmluY2lwbGUgdGhlIGFuc3dlcmVy IG1pZ2h0IGNob29zZSBub3QgdG8gYWNjZXB0IGJ1dCBpZiBpdCBkb2VzIHNvIHRoZTxvOnA+PC9v OnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Y29ubmVjdGlvbiB3 aWxsIGZhaWw8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+LUVrcjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj5PbiBUaHUsIEF1ZyA2LCAyMDE1IGF0IDc6MTIgQU0sIEFzdmVyZW4sIFRvbGdhICZs dDs8YSBocmVmPSJtYWlsdG86dGFzdmVyZW5Ac29udXNuZXQuY29tIiB0YXJnZXQ9Il9ibGFuayI+ dGFzdmVyZW5Ac29udXNuZXQuY29tPC9hPiZndDsgd3JvdGU6PG86cD48L286cD48L3A+DQo8L2Rp dj4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj4NCjxibG9ja3F1b3RlIHN0eWxlPSJib3JkZXI6bm9uZTti b3JkZXItbGVmdDpzb2xpZCAjQ0NDQ0NDIDEuMHB0O3BhZGRpbmc6MGluIDBpbiAwaW4gNi4wcHQ7 bWFyZ2luLWxlZnQ6NC44cHQ7bWFyZ2luLXJpZ2h0OjBpbiI+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2lu LWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1p bHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0QiPkkgdGhpbmsg aW1wbGVtZW50ZXJzIHRoZW1zZWx2ZXMgY2FuIHdlaWdoIG91dCB0aGUgYWR2YW50YWdlcy9kaXNh ZHZhbnRhZ2VkL2RlcGxveW1lbnQgbW9kZWxzIHRoZXkgYXJlDQogdGFyZ2V0aW5nL2V0Y+KApiBh bmQgZGVjaWRlIHdoYXQgdG8gc3VwcG9ydC9ub3QgdG8gc3VwcG9ydC4gSSBkb27igJl0IHNlZSBh bnkgaXNzdWUgd2l0aCB0aGlzIGFzIGxvbmcgYXMgdGhlcmUgaXMgYSBuZWdvdGlhdGlvbiBtZWNo YW5pc20gKHdoaWNoIHRoZXJlIGlzKS4gSSBkb27igJl0IHRoaW5rIHRoZSBhdmFpbGFiaWxpdHkg b2YgbmVnb3RpYXRpb24gaXMgZW5jb3VyYWdpbmcgcGVvcGxlIHRoaXMgb3IgdGhhdCB3YXkuPC9z cGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJn aW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBzdHlsZT0i Zm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2Vy aWY7Y29sb3I6IzFGNDk3RCI+Jm5ic3A7PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90 dG9tLWFsdDphdXRvIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTom cXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RCI+VGhhbmtzLDwvc3Bh bj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2lu LXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gc3R5bGU9ImZv bnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlm O2NvbG9yOiMxRjQ5N0QiPlRvbGdhPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1z b05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9t LWFsdDphdXRvIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVv dDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RCI+Jm5ic3A7PC9zcGFuPjxv OnA+PC9vOnA+PC9wPg0KPGRpdiBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLWxlZnQ6c29saWQg Ymx1ZSAxLjVwdDtwYWRkaW5nOjBpbiAwaW4gMGluIDQuMHB0Ij4NCjxkaXY+DQo8ZGl2IHN0eWxl PSJib3JkZXI6bm9uZTtib3JkZXItdG9wOnNvbGlkICNFMUUxRTEgMS4wcHQ7cGFkZGluZzozLjBw dCAwaW4gMGluIDBpbiI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10 b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxiPjxzcGFuIHN0eWxlPSJm b250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJp ZiI+RnJvbTo8L3NwYW4+PC9iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFt aWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZiI+IHRpbSBwYW50b24gW21haWx0bzo8 YSBocmVmPSJtYWlsdG86dGltQHBob25lZnJvbWhlcmUuY29tIiB0YXJnZXQ9Il9ibGFuayI+dGlt QHBob25lZnJvbWhlcmUuY29tPC9hPl0NCjxicj4NCjxiPlNlbnQ6PC9iPiBUaHVyc2RheSwgQXVn dXN0IDA2LCAyMDE1IDEwOjA3IEFNPGJyPg0KPGI+VG86PC9iPiBIdXR0b24sIEFuZHJldyAmbHQ7 PGEgaHJlZj0ibWFpbHRvOmFuZHJldy5odXR0b25AdW5pZnkuY29tIiB0YXJnZXQ9Il9ibGFuayI+ YW5kcmV3Lmh1dHRvbkB1bmlmeS5jb208L2E+Jmd0Ozxicj4NCjxiPkNjOjwvYj4gQXN2ZXJlbiwg VG9sZ2EgJmx0OzxhIGhyZWY9Im1haWx0bzp0YXN2ZXJlbkBzb251c25ldC5jb20iIHRhcmdldD0i X2JsYW5rIj50YXN2ZXJlbkBzb251c25ldC5jb208L2E+Jmd0OzsgJmx0OzxhIGhyZWY9Im1haWx0 bzpydGN3ZWJAaWV0Zi5vcmciIHRhcmdldD0iX2JsYW5rIj5ydGN3ZWJAaWV0Zi5vcmc8L2E+Jmd0 OyAmbHQ7PGEgaHJlZj0ibWFpbHRvOnJ0Y3dlYkBpZXRmLm9yZyIgdGFyZ2V0PSJfYmxhbmsiPnJ0 Y3dlYkBpZXRmLm9yZzwvYT4mZ3Q7PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPGRpdj4NCjxkaXY+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48YnI+DQo8Yj5TdWJqZWN0OjwvYj4gUmU6IFtydGN3ZWJd IFdoYXQgdGhlIGdhdGV3YXkgZHJhZnQgc2hvdWxkIHNheSBhYm91dCBtdXgvbm9uLW11eDxvOnA+ PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdj4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28t bWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0 b20tYWx0OmF1dG8iPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPGRpdj4NCjxibG9ja3F1b3RlIHN0 eWxlPSJtYXJnaW4tdG9wOjUuMHB0O21hcmdpbi1ib3R0b206NS4wcHQiPg0KPGRpdj4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2lu LWJvdHRvbS1hbHQ6YXV0byI+T24gNiBBdWcgMjAxNSwgYXQgMDg6MzAsIEh1dHRvbiwgQW5kcmV3 ICZsdDs8YSBocmVmPSJtYWlsdG86YW5kcmV3Lmh1dHRvbkB1bmlmeS5jb20iIHRhcmdldD0iX2Js YW5rIj5hbmRyZXcuaHV0dG9uQHVuaWZ5LmNvbTwvYT4mZ3Q7IHdyb3RlOjxvOnA+PC9vOnA+PC9w Pg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0 OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0K PGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3At YWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIHN0eWxlPSJmb250LXNp emU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xv cjojMUY0OTdEIj4mIzQzOzEgdG8gd2hhdCBUaW0gc2FpZC48L3NwYW4+PG86cD48L286cD48L3A+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNv LW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2Zv bnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEIj4m bmJzcDs8L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0i bXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFu IHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDss c2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEIj5JIGRvbuKAmXQgdGhpbmsgdGhpcyBkaXNjdXNzaW9u IGlzIHJlYWxseSBhYm91dCBnYXRld2F5cyBhdCBhbGwgaXQgaXMgc3VyZWx5IGFib3V0IHdoZXRo ZXIgV2ViUlRDIGJyb3dzZXJzDQogaGF2ZSB0byBzdXBwb3J0IG5vbi1tdXggYW5kIEkgZG9u4oCZ dCByZWFsbHkgc2VlIGFueSBnb29kIHJlYXNvbiB3aHkgdGhleSBuZWVkIHRvLjwvc3Bhbj48bzpw PjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1h bHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6 ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9y OiMxRjQ5N0QiPiZuYnNwOzwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6 YXV0byI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2Fs aWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0QiPklmIHdlIGhhZCB0aG91Z2h0IGFi b3V0IHRoaXMgYXQgdGhlIHRpbWUgd2UgbWFuZGF0ZWQgRFRMUy1TUlRQIHRoZW4gd2Ugd291bGQg aGF2ZSBtYW5kYXRlZCBydHAtbXV4DQogYXQgdGhlIHNhbWUgdGltZSBidXQgdW5mb3J0dW5hdGVs eSB3ZSBkaWRu4oCZdCBidXQgd2UgY2FuIGZpeCB0aGF0IG5vdy48L3NwYW4+PG86cD48L286cD48 L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9ibG9ja3F1b3RlPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29O b3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1h bHQ6YXV0byI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0 b20tYWx0OmF1dG8iPlNhZGx5IHRydWUsIGJ1dCB0aGUgc2l0dWF0aW9uIGluIGEgYnJvd3NlciBp cyBtYW5hZ2VhYmxlIHNpbmNlIHlvdSBtaWdodCBleHBlY3QgMTAgcGVlciBjb25uZWN0aW9ucywg cmVzdWx0aW5nJm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0 b20tYWx0OmF1dG8iPmluIGEgd29yc3QgY2FzZSBvZiA2MCBVRFAgcG9ydHMvRFRMUyBzZXNzaW9u cyBpbiB1c2UmbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRv bS1hbHQ6YXV0byI+KGFzc3VtaW5nIHZvaWNlJiM0Mzt2aWRlbyYjNDM7ZGF0YSB1bmJ1bmRsZWQg YW5kIFJUQ1Atbm9uLW11eCB2cyB0aGUgMTAgbmVlZGVkKS4gV2UmbmJzcDs8bzpwPjwvbzpwPjwv cD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2lu LXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+YWxzbyBhc3N1bWUgYSBy ZWxhdGl2ZWx5IHdlbGwgZW5kb3dlZCBDUFUgLSBkZXZvdGVkIGxhcmdlbHkgdG8gdGhpcyB0YXNr LjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5 bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj4m bmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi IHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0 byI+T24gdGhlIGdhdGV3YXkgeW914oCZZCBob3BlIHRvIGhhdmUgdGhvdXNhbmRzIG9mIHNlc3Np b25zIGFuZCBwcmVzdW1hYmx5IG11Y2ggbGVzcyBDUFUvbWVtb3J5IHJlc291cmNlIHBlciBjaGFu bmVsLjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIg c3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRv Ij5TbyB3aGlsZSBJIHRoaW5rIGl0IGlzIHVuZm9ydHVuYXRlIHRoYXQgYnJvd3NlcnMgY2FuIGRv IG5vbi1tdXgsIGl0IHdvdWxkIGJlIHBsYWluIHN0dXBpZCB0byBkbyB0aGF0IG9uIGEgZ2F0ZXdh eS4gRG8gd2UmbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRv bS1hbHQ6YXV0byI+cmVhbGx5IHdhbnQgdG8gZW5jb3VyYWdlIHRoYXQgPzxvOnA+PC9vOnA+PC9w Pg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4t dG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj4mbmJzcDs8bzpwPjwvbzpw PjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFy Z2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+VC48bzpwPjwvbzpw PjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFy Z2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+Jm5ic3A7PG86cD48 L286cD48L3A+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2lu LXRvcC1hbHQ6YXV0bzttYXJnaW4tYm90dG9tOjEyLjBwdCI+PG86cD4mbmJzcDs8L286cD48L3A+ DQo8YmxvY2txdW90ZSBzdHlsZT0ibWFyZ2luLXRvcDo1LjBwdDttYXJnaW4tYm90dG9tOjUuMHB0 Ij4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4t dG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBzdHlsZT0iZm9u dC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7 Y29sb3I6IzFGNDk3RCI+Jm5ic3A7PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1z b05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9t LWFsdDphdXRvIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVv dDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RCI+QW5keTwvc3Bhbj48bzpw PjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1h bHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6 ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9y OiMxRjQ5N0QiPiZuYnNwOzwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6 YXV0byI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2Fs aWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0QiPiZuYnNwOzwvc3Bhbj48bzpwPjwv bzpwPjwvcD4NCjxkaXYgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci1sZWZ0OnNvbGlkIGJsdWUg MS41cHQ7cGFkZGluZzowaW4gMGluIDBpbiA0LjBwdCI+DQo8ZGl2Pg0KPGRpdiBzdHlsZT0iYm9y ZGVyOm5vbmU7Ym9yZGVyLXRvcDpzb2xpZCAjQjVDNERGIDEuMHB0O3BhZGRpbmc6My4wcHQgMGlu IDBpbiAwaW4iPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFs dDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48Yj48c3BhbiBzdHlsZT0iZm9udC1z aXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtUYWhvbWEmcXVvdDssc2Fucy1zZXJpZiI+RnJv bTo8L3NwYW4+PC9iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZx dW90O1RhaG9tYSZxdW90OyxzYW5zLXNlcmlmIj4gcnRjd2ViIFs8YSBocmVmPSJtYWlsdG86cnRj d2ViLWJvdW5jZXNAaWV0Zi5vcmciIHRhcmdldD0iX2JsYW5rIj5tYWlsdG86cnRjd2ViLWJvdW5j ZXNAaWV0Zi5vcmc8L2E+XQ0KPGI+T24gQmVoYWxmIE9mIDwvYj50aW0gcGFudG9uPGJyPg0KPGI+ U2VudDo8L2I+IDA2IEF1Z3VzdCAyMDE1IDEzOjUzPGJyPg0KPGI+VG86PC9iPiBBc3ZlcmVuLCBU b2xnYTxicj4NCjxiPkNjOjwvYj4gJmx0OzxhIGhyZWY9Im1haWx0bzpydGN3ZWJAaWV0Zi5vcmci IHRhcmdldD0iX2JsYW5rIj5ydGN3ZWJAaWV0Zi5vcmc8L2E+Jmd0Ozxicj4NCjxiPlN1YmplY3Q6 PC9iPiBSZTogW3J0Y3dlYl0gV2hhdCB0aGUgZ2F0ZXdheSBkcmFmdCBzaG91bGQgc2F5IGFib3V0 IG11eC9ub24tbXV4PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2lu LWJvdHRvbS1hbHQ6YXV0byI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0 OmF1dG8iPlNvIHdlIGFyZSBwb3NpdGluZyB0aGUgZXhpc3RlbmNlIG9mIGEgd2ViUlRDIGdhdGV3 YXkgZGVzaWduZWQgdG8gc3VwcG9ydCB0aG91c2FuZHMgb2YgY2FsbHMgd2hpY2ggZG9lcyBJQ0Ug YW5kIERUTFMgYnV0IHRoZTxvOnA+PC9vOnA+PC9wPg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0 b20tYWx0OmF1dG8iPmRlc2lnbmVyIGRlY2lkZWQgZGVsaWJlcmF0ZWx5IHRvIGRvdWJsZSB0aGUg bnVtYmVyIG9mIElDRSBzZXNzaW9ucyByZXF1aXJlZCBhbmQgZG91YmxlIHRoZSBudW1iZXIgb2Yg RFRMUyBzZXNzaW9ucyAoYW5kIGtleSZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2 Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21z by1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj5nZW5lcmF0aW9uIGNvc3RzKSBzbyB0aGF0IHRoZXkg Y2FuIHJ1biBSVENQIChvdmVyIElDRSBhbmQgRFRMUykgb24gYSBzZXBhcmF0ZSBwb3J0LiBJbiBt eSBlc3RpbWF0aW9uIHRoYXTigJlzIG9uZSBwb29yIGRlY2lzaW9uPG86cD48L286cD48L3A+DQo8 L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3At YWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPmFuZCBzaG91bGQgbm90IGJlIHVz ZWQgYXMgdGhlIGJhc2lzIG9mIHRoaXMgKG9yIGFueSkgc3RhbmRhcmQuJm5ic3A7PG86cD48L286 cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1h cmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPiZuYnNwOzxvOnA+ PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1z by1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj5J4oCZZCBy YXRoZXIgbm90IHN1cHBvcnQgcnRjcC1uby1tdXggYXMgSSBzZWUgemVybyBhZHZhbnRhZ2VzIGlu IGhhdmluZyBpdC4gKEkga25vdyB0aGVvcmV0aWNhbGx5IGl0IG1pZ2h0IGJlIHBvc3NpYmxlIHRv IGdldDxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIg c3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRv Ij5hIFJUQ1AgcGFja2V0IHRocm91Z2ggYSBjb25nZXN0ZWQgbmV0IG9uIGEgZGlmZmVyZW50IHBv cnQgd2l0aCBhIHNlcGFyYXRlIGRpZmZzZXJ2IHNldHRpbmcgYnV0IHRoYXQganVzdCBzZWVtcyBz byBjb250cml2ZWQpLjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1z b05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9t LWFsdDphdXRvIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJv dHRvbS1hbHQ6YXV0byI+VGltLjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xh c3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4t Ym90dG9tLWFsdDphdXRvIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFy Z2luLWJvdHRvbS1hbHQ6YXV0byI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+ DQo8ZGl2Pg0KPGJsb2NrcXVvdGUgc3R5bGU9Im1hcmdpbi10b3A6NS4wcHQ7bWFyZ2luLWJvdHRv bTo1LjBwdCI+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4t dG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj5PbiA2IEF1ZyAyMDE1LCBh dCAwNjo0NCwgQXN2ZXJlbiwgVG9sZ2EgJmx0OzxhIGhyZWY9Im1haWx0bzp0YXN2ZXJlbkBzb251 c25ldC5jb20iIHRhcmdldD0iX2JsYW5rIj50YXN2ZXJlbkBzb251c25ldC5jb208L2E+Jmd0OyB3 cm90ZTo8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9 Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj4mbmJz cDs8bzpwPjwvbzpwPjwvcD4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5 bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48 c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1 b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RCI+VGhlc2UgYXNzdW1wdGlvbnMgYXJlIG5vdCBu ZWNlc3NhcmlseSB0cnVlIGluIGEgdW5pdmVyc2FsIHNlbnNlIChsaWtlIGFsbW9zdCBhbnkgb3Ro ZXIgYXNzdW1wdGlvbiBhYm91dA0KIGRpZmZlcmVudCBkZXBsb3ltZW50IG1vZGVscykuPC9zcGFu PjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5 bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48 c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1 b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RCI+Jm5ic3A7PC9zcGFuPjxvOnA+PC9vOnA+PC9w Pg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4t dG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBzdHlsZT0iZm9u dC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7 Y29sb3I6IzFGNDk3RCI+RnVydGhlcm1vcmUsIGFuZCBtb3JlIGltcG9ydGFudGx5LCB0aGVyZSBp cyBub3RoaW5nIG1hbmRhdGluZyBXZWJSVEMgZW5kcG9pbnRzIHRvIHN1cHBvcnQgbm9uLXJ0Y3At bXV4Lg0KIEl0IGlzIGEgbmVnb3RpYXRlZCBmdW5jdGlvbmFsaXR5LiBBbnkgZW50aXR5IGNhbiBl bmZvcmNlIHJ0Y3AtbXV4IGFzIGEgbG9jYWwgcG9saWN5LiZuYnNwOzwvc3Bhbj48bzpwPjwvbzpw PjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFy Z2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gc3R5bGU9 ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNl cmlmO2NvbG9yOiMxRjQ5N0QiPiZuYnNwOzwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0K PGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0 bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4w cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5 N0QiPlRoZSBpc3N1ZSB3aXRoIHN1cHBvcnRpbmcgbm9uLXJ0Y3AtbXV4IHNlZW1zIHRvIGJlIGxh Y2sgb2YgY2xhcml0eSBpbiB0aGUgcmVsZXZhbnQgc3BlY2lmaWNhdGlvbnMuDQogRml4aW5nIHRo aXMg4oCTcmVnYXJkbGVzcyBvZiB0aGUgb3V0Y29tZSBvZiBhbnkgb3RoZXIgZGlzY3Vzc2lvbi0g c2VlbXMgdG8gYmUgcHJ1ZGVudCBJTUhPLjwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0K PGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0 bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4w cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5 N0QiPiZuYnNwOzwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJv dHRvbS1hbHQ6YXV0byI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6 JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0QiPlRoYW5rcyw8L3Nw YW4+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBz dHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8i PjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkm cXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEIj5Ub2xnYTwvc3Bhbj48bzpwPjwvbzpwPjwv cD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2lu LXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gc3R5bGU9ImZv bnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlm O2NvbG9yOiMxRjQ5N0QiPiZuYnNwOzwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRp diBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLWxlZnQ6c29saWQgYmx1ZSAxLjVwdDtwYWRkaW5n OjBpbiAwaW4gMGluIDQuMHB0Ij4NCjxkaXY+DQo8ZGl2IHN0eWxlPSJib3JkZXI6bm9uZTtib3Jk ZXItdG9wOnNvbGlkICNFMUUxRTEgMS4wcHQ7cGFkZGluZzozLjBwdCAwaW4gMGluIDBpbiI+DQo8 ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRv O21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48Yj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEx LjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWYiPkZyb206PC9z cGFuPjwvYj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtD YWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWYiPiZuYnNwO1d5c3MsIEZlbGl4IFs8YSBocmVmPSJtYWls dG86RmVsaXguV3lzc0BpbmluLmNvbSIgdGFyZ2V0PSJfYmxhbmsiPm1haWx0bzpGZWxpeC5XeXNz QGluaW4uY29tPC9hPl0mbmJzcDs8YnI+DQo8Yj5TZW50OjwvYj4mbmJzcDtUaHVyc2RheSwgQXVn dXN0IDA2LCAyMDE1IDY6MzcgQU08YnI+DQo8Yj5Ubzo8L2I+Jm5ic3A7Q2hyaXN0ZXIgSG9sbWJl cmcgJmx0OzxhIGhyZWY9Im1haWx0bzpjaHJpc3Rlci5ob2xtYmVyZ0Blcmljc3Nvbi5jb20iIHRh cmdldD0iX2JsYW5rIj5jaHJpc3Rlci5ob2xtYmVyZ0Blcmljc3Nvbi5jb208L2E+Jmd0OzsgQXN2 ZXJlbiwgVG9sZ2EgJmx0OzxhIGhyZWY9Im1haWx0bzp0YXN2ZXJlbkBzb251c25ldC5jb20iIHRh cmdldD0iX2JsYW5rIj50YXN2ZXJlbkBzb251c25ldC5jb208L2E+Jmd0OzsgU2Nod2FyeiwgQWxi cmVjaHQgKEFsYnJlY2h0KQ0KICZsdDs8YSBocmVmPSJtYWlsdG86YWxicmVjaHQuc2Nod2FyekBh bGNhdGVsLWx1Y2VudC5jb20iIHRhcmdldD0iX2JsYW5rIj5hbGJyZWNodC5zY2h3YXJ6QGFsY2F0 ZWwtbHVjZW50LmNvbTwvYT4mZ3Q7OyBSb21hbiBTaHBvdW50ICZsdDs8YSBocmVmPSJtYWlsdG86 cm9tYW5AdGVsdXJpeC5jb20iIHRhcmdldD0iX2JsYW5rIj5yb21hbkB0ZWx1cml4LmNvbTwvYT4m Z3Q7OyBSYXVzY2hlbmJhY2gsIFV3ZSAoTm9raWEgLSBERS9NdW5pY2gpICZsdDs8YSBocmVmPSJt YWlsdG86dXdlLnJhdXNjaGVuYmFjaEBub2tpYS5jb20iIHRhcmdldD0iX2JsYW5rIj51d2UucmF1 c2NoZW5iYWNoQG5va2lhLmNvbTwvYT4mZ3Q7PGJyPg0KPGI+Q2M6PC9iPiZuYnNwOyZsdDs8YSBo cmVmPSJtYWlsdG86cnRjd2ViQGlldGYub3JnIiB0YXJnZXQ9Il9ibGFuayI+cnRjd2ViQGlldGYu b3JnPC9hPiZndDsgJmx0OzxhIGhyZWY9Im1haWx0bzpydGN3ZWJAaWV0Zi5vcmciIHRhcmdldD0i X2JsYW5rIj5ydGN3ZWJAaWV0Zi5vcmc8L2E+Jmd0Ozxicj4NCjxiPlN1YmplY3Q6PC9iPiZuYnNw O1JlOiBbcnRjd2ViXSBXaGF0IHRoZSBnYXRld2F5IGRyYWZ0IHNob3VsZCBzYXkgYWJvdXQgbXV4 L25vbi1tdXg8L3NwYW4+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8 ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRv O21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2 Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10 b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG87YmFja2dyb3VuZDp3aGl0ZSI+ DQo8c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlm Ij5XaHkgc2hvdWxkbid0IHRoZSBnYXRld2F5IGJlIHJlcXVpcmVkIHRvIGRvIHRoZSBtdXgvZGVt dXg/Jm5ic3A7IE1ha2luZyB0aGUgV2ViUlRDIGVuZHBvaW50cyBhIGxvdCBtb3JlIGNvbXBsZXgg anVzdCBzbyB0aGUgbGVnYWN5IGludGVyb3AgbWlnaHQgcG90ZW50aWFsbHkgYmUgYSB0ZWVueS10 aW55IGJpdCBlYXNpZXIgbWFrZXMgbm8gc2Vuc2UgSU1ITy4mbmJzcDsgQWN0dWFsbHksDQogdGhl IGdhdGV3YXkgd291bGQgbm90IGJlIGFibGUgdG8gZG8gJnF1b3Q7ZW5kLXRvLWVuZCZxdW90OyBw YXNzLXRocm91Z2ggYW55d2F5IGFzIGxlZ2FjeSBlcXVpcG1lbnQgd2lsbCBlaXRoZXIgYmUgdW5l bmNyeXB0ZWQgb3IgdXNlIFNERVMgKFJGQyM0NTY4KSBmb3Iga2V5IGV4Y2hhbmdlLiZuYnNwOyBT byB0aGUgZ2F0ZXdheSB3aWxsIGhhdmUgdG8gcGVyZm9ybSBEVExTLVNSVFAgdG8gU0RFUy1TUlRQ IHRyYW5zY3J5cHRpb24tLXdoaWNoIGFscmVhZHkgaXMgd2F5IG1vcmUNCiBoYXNzbGUgdGhhbiBS VFAvUlRDUCBtdXgvZGVtdXguPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0K PHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1t YXJnaW4tYm90dG9tLWFsdDphdXRvO2JhY2tncm91bmQ6d2hpdGUiPg0KPHNwYW4gc3R5bGU9ImZv bnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZiI+Jm5ic3A7PC9zcGFuPjxv OnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9 Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvO2JhY2tn cm91bmQ6d2hpdGUiPg0KPHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVv dDssc2Fucy1zZXJpZiI+LS1GZWxpeDwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRp dj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bztt c28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0bztiYWNrZ3JvdW5kOndoaXRlIj4NCjxzcGFuIHN0eWxl PSJmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWYiPiZuYnNwOzwvc3Bh bj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxkaXYgY2xhc3M9Ik1zb05vcm1hbCIg YWxpZ249ImNlbnRlciIgc3R5bGU9InRleHQtYWxpZ246Y2VudGVyO2JhY2tncm91bmQ6d2hpdGUi Pg0KPHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJp ZiI+DQo8aHIgc2l6ZT0iMiIgd2lkdGg9Ijk4JSIgYWxpZ249ImNlbnRlciI+DQo8L3NwYW4+PC9k aXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2lu LXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0bztiYWNrZ3JvdW5kOndoaXRl Ij4NCjxiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0Nh bGlicmkmcXVvdDssc2Fucy1zZXJpZiI+RnJvbTo8L3NwYW4+PC9iPjxzcGFuIHN0eWxlPSJmb250 LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZiI+ Jm5ic3A7cnRjd2ViICZsdDs8YSBocmVmPSJtYWlsdG86cnRjd2ViLWJvdW5jZXNAaWV0Zi5vcmci IHRhcmdldD0iX2JsYW5rIj48c3BhbiBzdHlsZT0iY29sb3I6cHVycGxlIj5ydGN3ZWItYm91bmNl c0BpZXRmLm9yZzwvc3Bhbj48L2E+Jmd0Ow0KIG9uIGJlaGFsZiBvZiBDaHJpc3RlciBIb2xtYmVy ZyAmbHQ7PGEgaHJlZj0ibWFpbHRvOmNocmlzdGVyLmhvbG1iZXJnQGVyaWNzc29uLmNvbSIgdGFy Z2V0PSJfYmxhbmsiPjxzcGFuIHN0eWxlPSJjb2xvcjpwdXJwbGUiPmNocmlzdGVyLmhvbG1iZXJn QGVyaWNzc29uLmNvbTwvc3Bhbj48L2E+Jmd0Ozxicj4NCjxiPlNlbnQ6PC9iPiZuYnNwO1RodXJz ZGF5LCBBdWd1c3QgNiwgMjAxNSAwNTo1MTxicj4NCjxiPlRvOjwvYj4mbmJzcDtBc3ZlcmVuLCBU b2xnYTsgU2Nod2FyeiwgQWxicmVjaHQgKEFsYnJlY2h0KTsgUm9tYW4gU2hwb3VudDsgUmF1c2No ZW5iYWNoLCBVd2UgKE5va2lhIC0gREUvTXVuaWNoKTxicj4NCjxiPkNjOjwvYj4mbmJzcDsmbHQ7 PGEgaHJlZj0ibWFpbHRvOnJ0Y3dlYkBpZXRmLm9yZyIgdGFyZ2V0PSJfYmxhbmsiPjxzcGFuIHN0 eWxlPSJjb2xvcjpwdXJwbGUiPnJ0Y3dlYkBpZXRmLm9yZzwvc3Bhbj48L2E+Jmd0Ozxicj4NCjxi PlN1YmplY3Q6PC9iPiZuYnNwO1JlOiBbcnRjd2ViXSBXaGF0IHRoZSBnYXRld2F5IGRyYWZ0IHNo b3VsZCBzYXkgYWJvdXQgbXV4L25vbi1tdXg8L3NwYW4+PG86cD48L286cD48L3A+DQo8L2Rpdj4N CjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9w LWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvO2JhY2tncm91bmQ6d2hpdGUiPg0K PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZiI+ Jm5ic3A7PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRp dj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4t dG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvO2JhY2tncm91bmQ6d2hpdGUi Pg0KPHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJy aSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0QiPkhpLDwvc3Bhbj48bzpwPjwvbzpwPjwv cD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2lu LXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0bztiYWNrZ3JvdW5kOndoaXRl Ij4NCjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGli cmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEIj4mbmJzcDs8L3NwYW4+PG86cD48L286 cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1h cmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG87YmFja2dyb3VuZDp3 aGl0ZSI+DQo8c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtD YWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RCI+Tm8gbWF0dGVyIHdoZXRoZXIg dGhlIGdhdGV3YXkgc3VwcG9ydHMgUlRQL1JUQ1AgbXV4IG9yIG5vdCwgdGhlcmUgYXJlIGNhc2Vz IHdoZXJlIHRoZSBsZWdhY3kgbmV0d29yay9lbmRwb2ludHMgd2lsbCBub3QgdXNlIFJUUC9SVENQ IG11eCwgc28gSSBndWVzcyBwZW9wbGUgdGhlbiB3b3VsZCB3YW50IHRvIGJlIGFibGUNCiB0byBu ZWdvdGlhdGUgbm9uLW11eCDigJxlbmQtdG8tZW5k4oCdLCByYXRoZXIgdGhhbiBoYXZpbmcgdGhl IGdhdGV3YXkgdG8gZGVtdXgvbXV4IFJUUCBhbmQgUlRDUC48L3NwYW4+PG86cD48L286cD48L3A+ DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10 b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG87YmFja2dyb3VuZDp3aGl0ZSI+ DQo8c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJp JnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RCI+Jm5ic3A7PC9zcGFuPjxvOnA+PC9vOnA+ PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJn aW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvO2JhY2tncm91bmQ6d2hp dGUiPg0KPHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2Fs aWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0QiPlJlZ2FyZHMsPC9zcGFuPjxvOnA+ PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1z by1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvO2JhY2tncm91 bmQ6d2hpdGUiPg0KPHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1 b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0QiPiZuYnNwOzwvc3Bhbj48 bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxl PSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0bztiYWNr Z3JvdW5kOndoaXRlIj4NCjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5 OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEIj5DaHJpc3Rlcjwv c3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi IHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0 bztiYWNrZ3JvdW5kOndoaXRlIj4NCjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQt ZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEIj4mbmJz cDs8L3NwYW4+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2IHN0eWxlPSJib3Jk ZXI6bm9uZTtib3JkZXItdG9wOnNvbGlkICNCNUM0REYgMS4wcHQ7cGFkZGluZzozLjBwdCAwaW4g MGluIDBpbiI+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4t dG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvO2JhY2tncm91bmQ6d2hpdGUi Pg0KPGI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7VGFo b21hJnF1b3Q7LHNhbnMtc2VyaWYiPkZyb206PC9zcGFuPjwvYj48c3BhbiBzdHlsZT0iZm9udC1z aXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtUYWhvbWEmcXVvdDssc2Fucy1zZXJpZiI+Jm5i c3A7QXN2ZXJlbiwgVG9sZ2EgWzxhIGhyZWY9Im1haWx0bzp0YXN2ZXJlbkBzb251c25ldC5jb20i IHRhcmdldD0iX2JsYW5rIj48c3BhbiBzdHlsZT0iY29sb3I6cHVycGxlIj5tYWlsdG86dGFzdmVy ZW5Ac29udXNuZXQuY29tPC9zcGFuPjwvYT5dJm5ic3A7PGJyPg0KPGI+U2VudDo8L2I+Jm5ic3A7 Ni4gZWxva3V1dGEgMjAxNSAxMjoxODxicj4NCjxiPlRvOjwvYj4mbmJzcDtTY2h3YXJ6LCBBbGJy ZWNodCAoQWxicmVjaHQpOyBSb21hbiBTaHBvdW50OyBSYXVzY2hlbmJhY2gsIFV3ZSAoTm9raWEg LSBERS9NdW5pY2gpPGJyPg0KPGI+Q2M6PC9iPiZuYnNwO2V4dCBFcmljIFJlc2NvcmxhOyBDaHJp c3RlciBIb2xtYmVyZzsgQmVybmFyZCBBYm9iYTsgJmx0OzxhIGhyZWY9Im1haWx0bzpydGN3ZWJA aWV0Zi5vcmciIHRhcmdldD0iX2JsYW5rIj48c3BhbiBzdHlsZT0iY29sb3I6cHVycGxlIj5ydGN3 ZWJAaWV0Zi5vcmc8L3NwYW4+PC9hPiZndDs8YnI+DQo8Yj5TdWJqZWN0OjwvYj4mbmJzcDtSZTog W3J0Y3dlYl0gV2hhdCB0aGUgZ2F0ZXdheSBkcmFmdCBzaG91bGQgc2F5IGFib3V0IG11eC9ub24t bXV4PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28t bWFyZ2luLWJvdHRvbS1hbHQ6YXV0bztiYWNrZ3JvdW5kOndoaXRlIj4NCiZuYnNwOzxvOnA+PC9v OnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxl PSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0bztiYWNr Z3JvdW5kOndoaXRlIj4NCjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1 b3Q7LHNhbnMtc2VyaWYiPldoeSBzaG91bGQgd2UgY29uc2lkZXIgM0dQUCB0aGUgc29sZSAmcXVv dDtvd25lci91c2VyJnF1b3Q7IG9mIHRoZSB0ZXJtL2VudGl0eSBXZWJSVEMtR1c/IEkgdGhpbmsg aXQgaGFzIGEgbXVjaCBtb3JlIGdlbmVyYWwgbWVhbmluZyBhbmQgdXNlIGluIHByYWN0aWNlLiBJ dCBjYW4gcmVmZXIgdG8gbWFueSBkaWZmZXJlbnQgdHlwZXMgb2YgZWxlbWVudHMgd2hpY2ggY2Fu IGJlIGRlcGxveWVkDQogaW4gbWFueSBkaWZmZXJlbnQgZW52aXJvbm1lbnRzLCBoZW5jZSBhbnkg YXR0ZW1wdCB0byBkZWZpbmUgaXQgc3RyaWN0bHkvcmVzdHJpY3QgaXRzIGNhcGFiaWxpdGllcyBh cmUgZnV0aWxlIElNSE8uPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJn aW4tYm90dG9tLWFsdDphdXRvO2JhY2tncm91bmQ6d2hpdGUiPg0KPHNwYW4gc3R5bGU9ImZvbnQt ZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZiI+Jm5ic3A7PC9zcGFuPjxvOnA+ PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1z by1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvO2JhY2tncm91 bmQ6d2hpdGUiPg0KPHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDss c2Fucy1zZXJpZiI+VGhhbmtzLDwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28t bWFyZ2luLWJvdHRvbS1hbHQ6YXV0bztiYWNrZ3JvdW5kOndoaXRlIj4NCjxzcGFuIHN0eWxlPSJm b250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWYiPlRvbGdhPC9zcGFuPjxv OnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9 Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvO2JhY2tn cm91bmQ6d2hpdGUiPg0KPHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVv dDssc2Fucy1zZXJpZiI+Jm5ic3A7PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2 Pg0KPGRpdiBjbGFzcz0iTXNvTm9ybWFsIiBhbGlnbj0iY2VudGVyIiBzdHlsZT0idGV4dC1hbGln bjpjZW50ZXI7YmFja2dyb3VuZDp3aGl0ZSI+DQo8c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1 b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmIj4NCjxociBzaXplPSIyIiB3aWR0aD0iOTglIiBh bGlnbj0iY2VudGVyIj4NCjwvc3Bhbj48L2Rpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1z b05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9t LWFsdDphdXRvO2JhY2tncm91bmQ6d2hpdGUiPg0KPGI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTox MS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmIj5Gcm9tOjwv c3Bhbj48L2I+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7 Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmIj4mbmJzcDtTY2h3YXJ6LCBBbGJyZWNodCAoQWxicmVj aHQpICZsdDs8YSBocmVmPSJtYWlsdG86YWxicmVjaHQuc2Nod2FyekBhbGNhdGVsLWx1Y2VudC5j b20iIHRhcmdldD0iX2JsYW5rIj48c3BhbiBzdHlsZT0iY29sb3I6cHVycGxlIj5hbGJyZWNodC5z Y2h3YXJ6QGFsY2F0ZWwtbHVjZW50LmNvbTwvc3Bhbj48L2E+Jmd0Ozxicj4NCjxiPlNlbnQ6PC9i PiZuYnNwO1RodXJzZGF5LCBBdWd1c3QgNiwgMjAxNSAyOjQ0IEFNPGJyPg0KPGI+VG86PC9iPiZu YnNwO0FzdmVyZW4sIFRvbGdhOyBSb21hbiBTaHBvdW50OyBSYXVzY2hlbmJhY2gsIFV3ZSAoTm9r aWEgLSBERS9NdW5pY2gpPGJyPg0KPGI+Q2M6PC9iPiZuYnNwO2V4dCBFcmljIFJlc2NvcmxhOyBD aHJpc3RlciBIb2xtYmVyZzsgQmVybmFyZCBBYm9iYTsgJmx0OzxhIGhyZWY9Im1haWx0bzpydGN3 ZWJAaWV0Zi5vcmciIHRhcmdldD0iX2JsYW5rIj48c3BhbiBzdHlsZT0iY29sb3I6cHVycGxlIj5y dGN3ZWJAaWV0Zi5vcmc8L3NwYW4+PC9hPiZndDs8YnI+DQo8Yj5TdWJqZWN0OjwvYj4mbmJzcDtS RTogW3J0Y3dlYl0gV2hhdCB0aGUgZ2F0ZXdheSBkcmFmdCBzaG91bGQgc2F5IGFib3V0IG11eC9u b24tbXV4PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2lu LWJvdHRvbS1hbHQ6YXV0bztiYWNrZ3JvdW5kOndoaXRlIj4NCjxzcGFuIHN0eWxlPSJmb250LWZh bWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWYiPiZuYnNwOzwvc3Bhbj48bzpwPjwv bzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFy Z2luLWJvdHRvbS1hbHQ6YXV0bztiYWNrZ3JvdW5kOndoaXRlIj4NCjxzcGFuIHN0eWxlPSJmb250 LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OkNvbnNvbGFzO2NvbG9yOiMxRjQ5N0QiPlRoZSBjb25j ZXJuZWQgM0dQUCBXZWJSVEMgZ2F0ZXdheSAoM0dQUCAyMy4zMzQvMjkuMzM0KSBzdXBwb3J0cyBh bHJlYWR5IFJUUC9SVENQIHRyYW5zcG9ydCBtdWx0aXBsZXhpbmcgKHNpbmNlIDNHUFAgUmVsZWFz ZSAxMiksIGkuZS4gc2hvdWxkIG5vdCBiZSB0aGUgbGltaXRpbmcgZmFjdG9yIGluIHRoaXMgZGlz Y3Vzc2lvbi4mbmJzcDs8L3NwYW4+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdp bi1ib3R0b20tYWx0OmF1dG87YmFja2dyb3VuZDp3aGl0ZSI+DQo8c3BhbiBzdHlsZT0iZm9udC1z aXplOjExLjBwdDtmb250LWZhbWlseTpDb25zb2xhcztjb2xvcjojMUY0OTdEIj5Gb3Igb25lcyBp bnRlcmVzdGVkIGluIHRoZSBSVENQIHBvcnQgYWxsb2NhdGlvbiBydWxlcywgc2VlIEguMjQ4LjU3 Ojwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6 YXV0bztiYWNrZ3JvdW5kOndoaXRlIj4NCjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2Zv bnQtZmFtaWx5OkNvbnNvbGFzO2NvbG9yOiMxRjQ5N0QiPjxhIGhyZWY9Imh0dHBzOi8vd3d3Lml0 dS5pbnQvcmVjL2RvbG9naW5fcHViLmFzcD9sYW5nPWUmYW1wO2lkPVQtUkVDLUguMjQ4LjU3LTIw MTQxMC1JISFQREYtRSZhbXA7dHlwZT1pdGVtcyIgdGFyZ2V0PSJfYmxhbmsiIHRpdGxlPSJDbWQm IzQzO0NsaWNrIG9yIHRhcCB0byBmb2xsb3cgdGhlIGxpbmsiPjxzcGFuIHN0eWxlPSJjb2xvcjpw dXJwbGUiPmh0dHBzOi8vd3d3Lml0dS5pbnQvcmVjL2RvbG9naW5fcHViLmFzcD9sYW5nPWUmYW1w O2lkPVQtUkVDLUguMjQ4LjU3LTIwMTQxMC1JISFQREYtRSZhbXA7dHlwZT1pdGVtczwvc3Bhbj48 L2E+PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05v cm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFs dDphdXRvO2JhY2tncm91bmQ6d2hpdGUiPg0KPHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7 Zm9udC1mYW1pbHk6Q29uc29sYXM7Y29sb3I6IzFGNDk3RCI+Q2xhdXNlIDcgZGVzY3JpYmVzIFJU UC9SVENQIHRyYW5zcG9ydCBtdWx0aXBsZXhpbmcuIElUVS1UIEguMjQ4LjU3IGlzIGFscmVhZHkg c3VwcG9ydGVkIGJ5IDNHUFAgMjkuMzM0Ljwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0K PGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0 bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0bztiYWNrZ3JvdW5kOndoaXRlIj4NCjxzcGFuIHN0 eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OkNvbnNvbGFzO2NvbG9yOiMxRjQ5N0Qi PiZuYnNwOzwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRv bS1hbHQ6YXV0bztiYWNrZ3JvdW5kOndoaXRlIj4NCjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEu MHB0O2ZvbnQtZmFtaWx5OkNvbnNvbGFzO2NvbG9yOiMxRjQ5N0QiPlRoZSByYXRpb25hbGUgYmVo aW5kIHRoZSDigJxvcHRpb25hbCB0YWdnaW5n4oCdIGJ5IDIzLjIyOCBpcyBhIHRoaXJkIHJlYXNv biwgYmV5b25kPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90 dG9tLWFsdDphdXRvO2JhY2tncm91bmQ6d2hpdGUiPg0KPHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5 OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZiI+Jmd0OzEuIFVzaW5nIGRpZmZlcmVudCBR T1Mgc2V0dGluZ3MgZm9yIFJUQ1AgdnMgUlRQPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+ DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDph dXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvO2JhY2tncm91bmQ6d2hpdGUiPg0KPHNwYW4g c3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZiI+Jmd0OzIu IFNlbmRpbmcgUlRDUCB0byBhIGRpZmZlcmVudCBkZXZpY2UgZnJvbSBSVFA8L3NwYW4+PG86cD48 L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNv LW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG87YmFja2dyb3Vu ZDp3aGl0ZSI+DQo8c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTpDb25z b2xhcztjb2xvcjojMUY0OTdEIj4mbmJzcDs8L3NwYW4+PG86cD48L286cD48L3A+DQo8L2Rpdj4N CjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1 dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG87YmFja2dyb3VuZDp3aGl0ZSI+DQo8c3BhbiBz dHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTpDb25zb2xhcztjb2xvcjojMUY0OTdE Ij5Eb27igJl0IHdhbnQgdG8gZ28gaW4gdGhlIDNHUFAgc3BlY2lmaWMgZGV0YWlscywgYnV0IGl0 IGhhcyBub3RoaW5nIHRvIGRvIHdpdGggdGhlIDNHUFAgVUUtZW1iZWRkZWQgV2ViUlRDIGNsaWVu dCBub3IgYW55IGNvbnN0cmFpbnRzIGJ5IDNHUFAgV2ViUlRDIGdhdGV3YXlzLjwvc3Bhbj48bzpw PjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJt c28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0bztiYWNrZ3Jv dW5kOndoaXRlIj4NCjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OkNv bnNvbGFzO2NvbG9yOiMxRjQ5N0QiPiZuYnNwOzwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2 Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6 YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0bztiYWNrZ3JvdW5kOndoaXRlIj4NCjxzcGFu IHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OkNvbnNvbGFzO2NvbG9yOiMxRjQ5 N0QiPlRodXMsIGEgV2ViUlRDIGdhdGV3YXkgTVVTVCBzdXBwb3J0IFJUUC9SVENQIHRyYW5zcG9y dCBtdWx0aXBsZXhpbmcgZHVlIHRvIGl0cyBwdXJwb3NlIGluIGludGVyd29ya2luZyBzdXBwb3J0 Ljwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6 YXV0bztiYWNrZ3JvdW5kOndoaXRlIj4NCjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2Zv bnQtZmFtaWx5OkNvbnNvbGFzO2NvbG9yOiMxRjQ5N0QiPiZuYnNwOzwvc3Bhbj48bzpwPjwvbzpw PjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFy Z2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0bztiYWNrZ3JvdW5kOndo aXRlIj4NCjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OkNvbnNvbGFz O2NvbG9yOiMxRjQ5N0QiPlJlZ2FyZHMsPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8 ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRv O21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvO2JhY2tncm91bmQ6d2hpdGUiPg0KPHNwYW4gc3R5 bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6Q29uc29sYXM7Y29sb3I6IzFGNDk3RCI+ QWxicmVjaHQ8L3NwYW4+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0 b20tYWx0OmF1dG87YmFja2dyb3VuZDp3aGl0ZSI+DQo8c3BhbiBzdHlsZT0iZm9udC1zaXplOjEx LjBwdDtmb250LWZhbWlseTpDb25zb2xhcztjb2xvcjojMUY0OTdEIj4mbmJzcDs8L3NwYW4+PG86 cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0i bXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG87YmFja2dy b3VuZDp3aGl0ZSI+DQo8c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTom cXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RCI+Jm5ic3A7PC9zcGFu PjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdiBzdHlsZT0iYm9yZGVyOm5vbmU7 Ym9yZGVyLXRvcDpzb2xpZCAjQjVDNERGIDEuMHB0O3BhZGRpbmc6My4wcHQgMGluIDBpbiAwaW4i Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6 YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0bztiYWNrZ3JvdW5kOndoaXRlIj4NCjxiPjxz cGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O1RhaG9tYSZxdW90 OyxzYW5zLXNlcmlmIj5Gcm9tOjwvc3Bhbj48L2I+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4w cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7VGFob21hJnF1b3Q7LHNhbnMtc2VyaWYiPiZuYnNwO0FzdmVy ZW4sIFRvbGdhIFs8YSBocmVmPSJtYWlsdG86dGFzdmVyZW5Ac29udXNuZXQuY29tIiB0YXJnZXQ9 Il9ibGFuayI+PHNwYW4gc3R5bGU9ImNvbG9yOnB1cnBsZSI+bWFpbHRvOnRhc3ZlcmVuQHNvbnVz bmV0LmNvbTwvc3Bhbj48L2E+XSZuYnNwOzxicj4NCjxiPlNlbnQ6PC9iPiZuYnNwO01pdHR3b2No LCA1LiBBdWd1c3QgMjAxNSAxOTo0Nzxicj4NCjxiPlRvOjwvYj4mbmJzcDtSb21hbiBTaHBvdW50 OyBSYXVzY2hlbmJhY2gsIFV3ZSAoTm9raWEgLSBERS9NdW5pY2gpPGJyPg0KPGI+Q2M6PC9iPiZu YnNwO2V4dCBFcmljIFJlc2NvcmxhOyBTY2h3YXJ6LCBBbGJyZWNodCAoQWxicmVjaHQpOyBDaHJp c3RlciBIb2xtYmVyZzsgQmVybmFyZCBBYm9iYTsgJmx0OzxhIGhyZWY9Im1haWx0bzpydGN3ZWJA aWV0Zi5vcmciIHRhcmdldD0iX2JsYW5rIj48c3BhbiBzdHlsZT0iY29sb3I6cHVycGxlIj5ydGN3 ZWJAaWV0Zi5vcmc8L3NwYW4+PC9hPiZndDs8YnI+DQo8Yj5TdWJqZWN0OjwvYj4mbmJzcDtSRTog W3J0Y3dlYl0gV2hhdCB0aGUgZ2F0ZXdheSBkcmFmdCBzaG91bGQgc2F5IGFib3V0IG11eC9ub24t bXV4PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28t bWFyZ2luLWJvdHRvbS1hbHQ6YXV0bztiYWNrZ3JvdW5kOndoaXRlIj4NCjxzcGFuIHN0eWxlPSJm b250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWYiPiZuYnNwOzwvc3Bhbj48 bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxl PSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0bztiYWNr Z3JvdW5kOndoaXRlIj4NCjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5 OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEIj5pLSBJIGh1bWJs eSBkaXNhZ3JlZSB0aGF0IHVzaW5nIGRpZmZlcmVudCBRb1MgUlRDUC9SVFAsIGUuZy4gZGlmZmVy ZW50IERpZmZTZXJ2IHZhbHVlcyAsIHNob3VsZCBiZSBkaXNtaXNzZWQuPC9zcGFuPjxvOnA+PC9v OnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1t YXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvO2JhY2tncm91bmQ6 d2hpdGUiPg0KPHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7 Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0QiPmlpLSBMZXQgbWUgYWxzbyBh ZGQgYW5vdGhlciByZWFzb24gd2h5IG5vLXJ0Y3AtbXV4IG1heSBiZSBuZWVkZWQ6IEltcGxlbWVu dGF0aW9uIGRpZmZpY3VsdGllcyBpbiBjZXJ0YWluIEdXcy48L3NwYW4+PG86cD48L286cD48L3A+ DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10 b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG87YmFja2dyb3VuZDp3aGl0ZSI+ DQo8c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJp JnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RCI+Jm5ic3A7PC9zcGFuPjxvOnA+PC9vOnA+ PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJn aW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvO2JhY2tncm91bmQ6d2hp dGUiPg0KPHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2Fs aWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0QiPkNvbnNpZGVyaW5nIHRoYXQgdGhl cmUgaXMgYWxyZWFkeSBhIG5lZ290aWF0aW9uIG1lY2hhbmlzbSBmb3IgcnRjcC1tdXggc3VwcG9y dCwgdGhhdCBpdCBjYW4gYmUgZGUtZmFjdG8gbWFuZGF0ZWQgYnkgdGhlIGNob2ljZSBvZiBicm93 c2VycyBmb3IgSW50ZXJuZXQsIEkgdGhpbmsgd2hhdCBDaHJpc3Rlci9BbGJyZWNodA0KIHN1Z2dl c3RlZCBpcyB0aGUgcmlnaHQgd2F5IHRvIG1vdmUgZm9yd2FyZDogcHJvdmlkZSBjbGFyaWZpY2F0 aW9ucyBmb3IgdmFndWUgcG9pbnRzLiBJIGRvbuKAmXQgdW5kZXJzdGFuZCB3aHkgbGFjayBvZiBj bGFyaXR5IGluIGV4aXN0aW5nIHNwZWNpZmljYXRpb25zIHNob3VsZCBjYXVzZSBpbXBvc2luZyBy ZXN0cmljdGlvbnMuIFRoaXMgd291bGQgYmUgYWtpbiB0byBkcm9wcGluZyBhIGZlYXR1cmUgZHVl IHRvIGEgYnVnLiBJbiB0aGlzIGNhc2UsDQogdGhlIOKAnGJ1Z+KAnSBpcyBsYWNrIG9mIGNsYXJp dHkgaW4gbm9ybWF0aXZlIHNwZWNpZmljYXRpb25zIGFuZCBpdCBjYW4gYmUgYWRkcmVzc2VkIGJ5 IGZ1cnRoZXIgc3BlY2lmaWNhdGlvbi48L3NwYW4+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxk aXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87 bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG87YmFja2dyb3VuZDp3aGl0ZSI+DQo8c3BhbiBzdHls ZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMt c2VyaWY7Y29sb3I6IzFGNDk3RCI+Jm5ic3A7PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+ DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDph dXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvO2JhY2tncm91bmQ6d2hpdGUiPg0KPHNwYW4g c3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90Oyxz YW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0QiPlRoYW5rcyw8L3NwYW4+PG86cD48L286cD48L3A+DQo8 L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3At YWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG87YmFja2dyb3VuZDp3aGl0ZSI+DQo8 c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1 b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RCI+VG9sZ2E8L3NwYW4+PG86cD48L286cD48L3A+ DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10 b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG87YmFja2dyb3VuZDp3aGl0ZSI+ DQo8c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJp JnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RCI+Jm5ic3A7PC9zcGFuPjxvOnA+PC9vOnA+ PC9wPg0KPC9kaXY+DQo8ZGl2IHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItbGVmdDpzb2xpZCBi bHVlIDEuNXB0O3BhZGRpbmc6MGluIDBpbiAwaW4gNC4wcHQiPg0KPGRpdj4NCjxkaXYgc3R5bGU9 ImJvcmRlcjpub25lO2JvcmRlci10b3A6c29saWQgI0UxRTFFMSAxLjBwdDtwYWRkaW5nOjMuMHB0 IDBpbiAwaW4gMGluIj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1h cmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG87YmFja2dyb3VuZDp3 aGl0ZSI+DQo8Yj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVv dDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWYiPkZyb206PC9zcGFuPjwvYj48c3BhbiBzdHlsZT0i Zm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2Vy aWYiPiZuYnNwO1JvbWFuIFNocG91bnQgWzxhIGhyZWY9Im1haWx0bzpyb21hbkB0ZWx1cml4LmNv bSIgdGFyZ2V0PSJfYmxhbmsiPjxzcGFuIHN0eWxlPSJjb2xvcjpwdXJwbGUiPm1haWx0bzpyb21h bkB0ZWx1cml4LmNvbTwvc3Bhbj48L2E+XSZuYnNwOzxicj4NCjxiPlNlbnQ6PC9iPiZuYnNwO1dl ZG5lc2RheSwgQXVndXN0IDA1LCAyMDE1IDEyOjI5IFBNPGJyPg0KPGI+VG86PC9iPiZuYnNwO1Jh dXNjaGVuYmFjaCwgVXdlIChOb2tpYSAtIERFL011bmljaCkgJmx0OzxhIGhyZWY9Im1haWx0bzp1 d2UucmF1c2NoZW5iYWNoQG5va2lhLmNvbSIgdGFyZ2V0PSJfYmxhbmsiPjxzcGFuIHN0eWxlPSJj b2xvcjpwdXJwbGUiPnV3ZS5yYXVzY2hlbmJhY2hAbm9raWEuY29tPC9zcGFuPjwvYT4mZ3Q7PGJy Pg0KPGI+Q2M6PC9iPiZuYnNwO2V4dCBFcmljIFJlc2NvcmxhICZsdDs8YSBocmVmPSJtYWlsdG86 ZWtyQHJ0Zm0uY29tIiB0YXJnZXQ9Il9ibGFuayI+PHNwYW4gc3R5bGU9ImNvbG9yOnB1cnBsZSI+ ZWtyQHJ0Zm0uY29tPC9zcGFuPjwvYT4mZ3Q7OyBTY2h3YXJ6LCBBbGJyZWNodCAoQWxicmVjaHQp ICZsdDs8YSBocmVmPSJtYWlsdG86YWxicmVjaHQuc2Nod2FyekBhbGNhdGVsLWx1Y2VudC5jb20i IHRhcmdldD0iX2JsYW5rIj48c3BhbiBzdHlsZT0iY29sb3I6cHVycGxlIj5hbGJyZWNodC5zY2h3 YXJ6QGFsY2F0ZWwtbHVjZW50LmNvbTwvc3Bhbj48L2E+Jmd0OzsNCiBBc3ZlcmVuLCBUb2xnYSAm bHQ7PGEgaHJlZj0ibWFpbHRvOnRhc3ZlcmVuQHNvbnVzbmV0LmNvbSIgdGFyZ2V0PSJfYmxhbmsi PjxzcGFuIHN0eWxlPSJjb2xvcjpwdXJwbGUiPnRhc3ZlcmVuQHNvbnVzbmV0LmNvbTwvc3Bhbj48 L2E+Jmd0OzsgQ2hyaXN0ZXIgSG9sbWJlcmcgJmx0OzxhIGhyZWY9Im1haWx0bzpjaHJpc3Rlci5o b2xtYmVyZ0Blcmljc3Nvbi5jb20iIHRhcmdldD0iX2JsYW5rIj48c3BhbiBzdHlsZT0iY29sb3I6 cHVycGxlIj5jaHJpc3Rlci5ob2xtYmVyZ0Blcmljc3Nvbi5jb208L3NwYW4+PC9hPiZndDs7DQog QmVybmFyZCBBYm9iYSAmbHQ7PGEgaHJlZj0ibWFpbHRvOmJlcm5hcmQuYWJvYmFAZ21haWwuY29t IiB0YXJnZXQ9Il9ibGFuayI+PHNwYW4gc3R5bGU9ImNvbG9yOnB1cnBsZSI+YmVybmFyZC5hYm9i YUBnbWFpbC5jb208L3NwYW4+PC9hPiZndDs7ICZsdDs8YSBocmVmPSJtYWlsdG86cnRjd2ViQGll dGYub3JnIiB0YXJnZXQ9Il9ibGFuayI+PHNwYW4gc3R5bGU9ImNvbG9yOnB1cnBsZSI+cnRjd2Vi QGlldGYub3JnPC9zcGFuPjwvYT4mZ3Q7ICZsdDs8YSBocmVmPSJtYWlsdG86cnRjd2ViQGlldGYu b3JnIiB0YXJnZXQ9Il9ibGFuayI+PHNwYW4gc3R5bGU9ImNvbG9yOnB1cnBsZSI+cnRjd2ViQGll dGYub3JnPC9zcGFuPjwvYT4mZ3Q7PGJyPg0KPGI+U3ViamVjdDo8L2I+Jm5ic3A7UmU6IFtydGN3 ZWJdIFdoYXQgdGhlIGdhdGV3YXkgZHJhZnQgc2hvdWxkIHNheSBhYm91dCBtdXgvbm9uLW11eDwv c3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdp bi1ib3R0b20tYWx0OmF1dG87YmFja2dyb3VuZDp3aGl0ZSI+DQo8c3BhbiBzdHlsZT0iZm9udC1m YW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmIj4mbmJzcDs8L3NwYW4+PG86cD48 L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0 b20tYWx0OmF1dG87YmFja2dyb3VuZDp3aGl0ZSI+DQo8c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6 JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmIj5PbiBXZWQsIEF1ZyA1LCAyMDE1IGF0IDQ6 NDcgQU0sIFJhdXNjaGVuYmFjaCwgVXdlIChOb2tpYSAtIERFL011bmljaCkgJmx0OzxhIGhyZWY9 Im1haWx0bzp1d2UucmF1c2NoZW5iYWNoQG5va2lhLmNvbSIgdGFyZ2V0PSJfYmxhbmsiPjxzcGFu IHN0eWxlPSJjb2xvcjpwdXJwbGUiPnV3ZS5yYXVzY2hlbmJhY2hAbm9raWEuY29tPC9zcGFuPjwv YT4mZ3Q7IHdyb3RlOjwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGJsb2NrcXVvdGUg c3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci1sZWZ0OnNvbGlkICNDQ0NDQ0MgMS4wcHQ7cGFkZGlu ZzowaW4gMGluIDBpbiA2LjBwdDttYXJnaW4tbGVmdDo0LjhwdDttYXJnaW4tdG9wOjUuMHB0O21h cmdpbi1yaWdodDowaW47bWFyZ2luLWJvdHRvbTo1LjBwdCI+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNv LW1hcmdpbi1ib3R0b20tYWx0OmF1dG87YmFja2dyb3VuZDp3aGl0ZSI+DQo8c3BhbiBzdHlsZT0i Zm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtBcmlhbCZxdW90OyxzYW5zLXNlcmlm Ij5NZWRpYSBnYXRld2F5IGltcGxlbWVudGF0aW9ucyBhY2NvcmRpbmcgdG8gM0dQUCBUUyAyMy4y Mjg8L3NwYW4+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7 Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0QiPiZuYnNwOzwvc3Bhbj48c3Bh biBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtBcmlhbCZxdW90Oyxz YW5zLXNlcmlmIj5tYXkNCiBub3Qgc3VwcG9ydCBydGNwLW11eCwgYXMgcnRjcC1tdXggaXMgb3B0 aW9uYWwgdGhlcmUuPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdj4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28t bWFyZ2luLWJvdHRvbS1hbHQ6YXV0bztiYWNrZ3JvdW5kOndoaXRlIj4NCjxzcGFuIHN0eWxlPSJm b250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7LHNhbnMtc2VyaWYi PlNvIGlmIHdlIGRyb3Agbm9uLW11eCBzdXBwb3J0IGZyb20gd2ViIGJyb3dzZXJzLCB0aG9zZSBt ZWRpYSBnYXRld2F5cyB0aGF0IGhhdmUgbm90IGltcGxlbWVudGVkIHJ0Y3AtbXV4IHdpbGwgc3Rv cCBpbnRlcm9wZXJhdGluZy4mbmJzcDs8L3NwYW4+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxk aXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87 bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG87YmFja2dyb3VuZDp3aGl0ZSI+DQo8c3BhbiBzdHls ZT0iZm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmIj4mbmJzcDs8L3Nw YW4+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvYmxv Y2txdW90ZT4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1t YXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvO2JhY2tncm91bmQ6 d2hpdGUiPg0KPHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fu cy1zZXJpZiI+Jm5ic3A7PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxk aXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFs dDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvO2JhY2tncm91bmQ6d2hpdGUiPg0KPHNw YW4gc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZiI+Rmly c3Qgb2YgYWxsLCBkbyB5b3Uga25vdyBvZiBhbnkgV2ViUlRDIHRvIElNUyBnYXRld2F5cyB0aGF0 IGRvIG5vdCBpbXBsZW1lbnQgcnRjcC1tdXggb24gdGhlIFdlYlJUQyBzaWRlPyBJIHN0cm9uZ2x5 IHN1c3BlY3QgdGhlcmUgYXJlIG5vbmUuPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8 L2Rpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJn aW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvO2JhY2tncm91bmQ6d2hp dGUiPg0KPHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1z ZXJpZiI+Jm5ic3A7PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+ DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDph dXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvO2JhY2tncm91bmQ6d2hpdGUiPg0KPHNwYW4g c3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZiI+U2Vjb25k LCB0aGUgb25seSByZWFzb25zIG5vdCB0byB1c2UgcnRjcC1tdXggdGhhdCBJIGNhbiB0aGluayBv ZiBhcmUgdGhlIGZvbGxvd2luZzo8L3NwYW4+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2 Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10 b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG87YmFja2dyb3VuZDp3aGl0ZSI+ DQo8c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlm Ij4mbmJzcDs8L3NwYW4+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxk aXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87 bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG87YmFja2dyb3VuZDp3aGl0ZSI+DQo8c3BhbiBzdHls ZT0iZm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmIj4xLiBVc2luZyBk aWZmZXJlbnQgUU9TIHNldHRpbmdzIGZvciBSVENQIHZzIFJUUDwvc3Bhbj48bzpwPjwvbzpwPjwv cD4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0 eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0bzti YWNrZ3JvdW5kOndoaXRlIj4NCjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtDYWxpYnJp JnF1b3Q7LHNhbnMtc2VyaWYiPjIuIFNlbmRpbmcgUlRDUCB0byBhIGRpZmZlcmVudCBkZXZpY2Ug ZnJvbSBSVFA8L3NwYW4+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxk aXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87 bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG87YmFja2dyb3VuZDp3aGl0ZSI+DQo8c3BhbiBzdHls ZT0iZm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmIj4mbmJzcDs8L3Nw YW4+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1i b3R0b20tYWx0OmF1dG87YmFja2dyb3VuZDp3aGl0ZSI+DQo8c3BhbiBzdHlsZT0iZm9udC1mYW1p bHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmIj5JIGRvIG5vdCB0aGluayB0aGUgZmly c3QgdXNlIGNhc2Ugd2FycmFudHMgbWFraW5nIHJ0Y3AtbXV4IG9wdGlvbmFsLCBzaW5jZSwgcHJh Y3RpY2FsbHkgbm8gb25lIGRvZXMgdGhpcy48L3NwYW4+PG86cD48L286cD48L3A+DQo8L2Rpdj4N CjwvZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1h cmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG87YmFja2dyb3VuZDp3 aGl0ZSI+DQo8c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5z LXNlcmlmIj5TZWNvbmQgdXNlIGNhc2UgaXMgYWxzbyBmYWlybHkgbWFyZ2luYWwuIFBsdXMgaXQg Y2FuIGJlIGhhbmRsZWQgYnkgdGhlIGdhdGV3YXkgd2hpY2ggY2FuIHNlbmQgUlRDUCB0byBvbmUg ZGV2aWNlIGFuZCBSVFAgdG8gYW5vdGhlci48L3NwYW4+PG86cD48L286cD48L3A+DQo8L2Rpdj4N CjwvZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1h cmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG87YmFja2dyb3VuZDp3 aGl0ZSI+DQo8c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5z LXNlcmlmIj4mbmJzcDs8L3NwYW4+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRp dj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0 OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG87YmFja2dyb3VuZDp3aGl0ZSI+DQo8c3Bh biBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmIj5Tbywg dW5sZXNzIHNvbWVvbmUgY2FuIGNvbWUgdXAgd2l0aCBhIHVzZSBjYXNlIHdoeSBSVFAgYW5kIFJU Q1Agc2hvdWxkIHVzZSBkaWZmZXJlbnQgdHJhbnNwb3J0cywgSSB0aGluayBydGNwLW11eCBzaG91 bGQgYmUgbWFuZGF0b3J5Ljwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8 ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1h bHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0bztiYWNrZ3JvdW5kOndoaXRlIj4NCjxz cGFuIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWYiPiZu YnNwOzwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdj4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28t bWFyZ2luLWJvdHRvbS1hbHQ6YXV0bztiYWNrZ3JvdW5kOndoaXRlIj4NCjxzcGFuIHN0eWxlPSJm b250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWYiPlJlZ2FyZHMsPC9zcGFu PjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90 dG9tLWFsdDphdXRvO2JhY2tncm91bmQ6d2hpdGUiPg0KPHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5 OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZiI+X19fX19fX19fX19fX188L3NwYW4+PG86 cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20t YWx0OmF1dG87YmFja2dyb3VuZDp3aGl0ZSI+DQo8c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1 b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmIj5Sb21hbiBTaHBvdW50PC9zcGFuPjxvOnA+PC9v OnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0K PC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8 L2Rpdj4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9w LWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBzdHlsZT0iZm9udC1z aXplOjkuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0hlbHZldGljYSZxdW90OyxzYW5zLXNlcmlmIj5f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXzxicj4NCnJ0Y3dl YiBtYWlsaW5nIGxpc3Q8YnI+DQo8YSBocmVmPSJtYWlsdG86cnRjd2ViQGlldGYub3JnIiB0YXJn ZXQ9Il9ibGFuayI+cnRjd2ViQGlldGYub3JnPC9hPjxicj4NCjxhIGhyZWY9Imh0dHBzOi8vd3d3 LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vcnRjd2ViIiB0YXJnZXQ9Il9ibGFuayI+aHR0cHM6 Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9ydGN3ZWI8L2E+PC9zcGFuPjxvOnA+PC9v OnA+PC9wPg0KPC9kaXY+DQo8L2Jsb2NrcXVvdGU+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6 YXV0byI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rp dj4NCjwvZGl2Pg0KPC9ibG9ja3F1b3RlPg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBz dHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8i PiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8 L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tYm90dG9tOjEyLjBwdCI+ PGJyPg0KX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX188YnI+ DQpydGN3ZWIgbWFpbGluZyBsaXN0PGJyPg0KPGEgaHJlZj0ibWFpbHRvOnJ0Y3dlYkBpZXRmLm9y ZyI+cnRjd2ViQGlldGYub3JnPC9hPjxicj4NCjxhIGhyZWY9Imh0dHBzOi8vd3d3LmlldGYub3Jn L21haWxtYW4vbGlzdGluZm8vcnRjd2ViIiB0YXJnZXQ9Il9ibGFuayI+aHR0cHM6Ly93d3cuaWV0 Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9ydGN3ZWI8L2E+PG86cD48L286cD48L3A+DQo8L2Jsb2Nr cXVvdGU+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9w Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvYm9keT4NCjwvaHRt bD4NCg== --_000_SN1PR0301MB1551DF26DBA0FEBB61A92107B2740SN1PR0301MB1551_-- From nobody Thu Aug 6 07:55:44 2015 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5308E1A89C7 for ; Thu, 6 Aug 2015 07:55:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.749 X-Spam-Level: X-Spam-Status: No, score=-1.749 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_ENVFROM_END_DIGIT=0.25, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, 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 sKo6zU-HXvcu for ; Thu, 6 Aug 2015 07:55:41 -0700 (PDT) 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 BD99F1A87EB for ; Thu, 6 Aug 2015 07:55:41 -0700 (PDT) Received: by ykoo205 with SMTP id o205so64456637yko.0 for ; Thu, 06 Aug 2015 07:55:41 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:reply-to:in-reply-to:references:from:date:message-id :subject:to:cc:content-type; bh=96Wg9yOIJbcz/lgpRwlKF8yrhQIgea2fgoPbk8Yv0AE=; b=JBICtWfUpkKPF0Ta16kUh87RLnuH1ZkqiTAzpuZHsjbgGRXqy5s48UPMCIg0M48iTn zIwUygTeoCwkrY/om/OJHZsx05X/330bnH+7hMOcPVsqvcGiDeBlOpVFGnMtjw7G4g9m rxBvsjFXFY5UyzITpERHUgQSqr4rTxXkeXkeLJaVQzfY6yXGfHoRnF+crA5zeBEIMP3y /dzYpOT3KLMHtFJqwqnH1BYw/WXIbsbaeZou5AGRZddr14LJawMQFEANYIhSqw3W1Q4j AIhhE3VN41eMn1XlZYi3aZdavw8VQY66sBv9l+RVNpEWOa0GzZluy9aWZHO+g0LUYQGk hYoQ== X-Received: by 10.13.237.1 with SMTP id w1mr2200979ywe.132.1438872941080; Thu, 06 Aug 2015 07:55:41 -0700 (PDT) MIME-Version: 1.0 Received: by 10.13.195.129 with HTTP; Thu, 6 Aug 2015 07:55:21 -0700 (PDT) In-Reply-To: References: <20150805161344.GA19492@lo.psyced.org> <20150805164256.GB19492@lo.psyced.org> <55C250CE.3040309@nostrum.com> From: Michael Davey Date: Thu, 6 Aug 2015 15:55:21 +0100 Message-ID: To: Ted Hardie Content-Type: multipart/alternative; boundary=94eb2c0864a887da67051ca5b639 Archived-At: Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] LAST CALL: Systematically de-anonymize dissidents with WebRTC (HOWTO) X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: md84419@gmail.com List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 06 Aug 2015 14:55:43 -0000 --94eb2c0864a887da67051ca5b639 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Ted, Many thanks for your excellent email. I don't much care for the way that Carlo is going about trying to instigate change but as an outsider looking in on this interesting WebRTC project, an acknowledgement of this issue and the calm, constructive and pragmatic tone of your email is exactly what *I've* been hoping & waiting for. On 6 August 2015 at 00:42, Ted Hardie wrote: > Daniel, > > On Wed, Aug 5, 2015 at 3:54 PM, Daniel Roesler wrote: > >> While I'm not a fan of Carlo's antics, his concern is very valid and >> in my opinion it is highly concerning that members of this group are >> attacking his discourse and dismissing his point. >> >> > =E2=80=8BNo one is dismissing the issue, and both Chrome and Firefox have= worked > on code to provide short-term solution=E2=80=8Bs (see this work > > Justin pointed out to the list and Maire Reavy's post > .) > > The group is actively discussing this topic and how to manage this going > forward. A number of technical challenges have been pointed out (both in > VPN configuration and the availability of information on network type to > the browsers). Continuing to point out the severity of the problem in > threads trying to resolve the problem is not helping progress; code, text= , > or data would. > > =E2=80=8Bregards, > > Ted Hardie=E2=80=8B > > =E2=80=8B > > =E2=80=8B > > > > _______________________________________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/listinfo/rtcweb > > --94eb2c0864a887da67051ca5b639 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Ted,

Many thanks for your excellent ema= il.=C2=A0 I don't much care for the way that Carlo is going about tryin= g to instigate change but as an outsider looking in on this interesting Web= RTC project, an acknowledgement of this issue and the calm, constructive an= d pragmatic tone of your email is exactly what I've been hoping = & waiting for.

On 6 August 2015 at 00:42, Ted Hardie <ted.ie= tf@gmail.com> wrote:
Daniel,

On Wed, Aug 5, 2015 at 3:54 PM, Danie= l Roesler <diafygi@gmail.com> wrote:
While I'm not a fan of Carlo's antics, his concern is ve= ry valid and
in my opinion it is highly concerning that members of this group are
attacking his discourse and dismissing his point.


=E2=80=8BNo one is dismissing th= e issue, and both Chrome and Firefox have worked on code to provide short-t= erm solution=E2=80=8Bs (see this work Justin pointed out to the list and Maire Reavy's post.)

= The group is actively discussing this topic and how to manage this going fo= rward.=C2=A0 A number of technical challenges have been pointed out (both i= n VPN configuration and the availability of information on network type to = the browsers).=C2=A0 Continuing to point out the severity of the problem in= threads trying to resolve the problem is not helping progress; code, text,= or data would.=C2=A0

=E2=80=8Bregards,

Ted Hardie=E2=80=8B

=E2=80=8B

=E2=80=8B



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


--94eb2c0864a887da67051ca5b639-- From nobody Thu Aug 6 08:25:04 2015 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6C9A61B2A54 for ; Thu, 6 Aug 2015 08:25:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.977 X-Spam-Level: X-Spam-Status: No, score=-1.977 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id W2JbEKESjCke for ; Thu, 6 Aug 2015 08:24:55 -0700 (PDT) Received: from mail-wi0-f178.google.com (mail-wi0-f178.google.com [209.85.212.178]) (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 B0C481AD21C for ; Thu, 6 Aug 2015 08:24:19 -0700 (PDT) Received: by wijp15 with SMTP id p15so27121817wij.0 for ; Thu, 06 Aug 2015 08:24:18 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type; bh=T44bZpfStsviQUjWFGEirQFh61oAJoNjZ9A21FXG76o=; b=gvZ4o1U4/Z2i4muZjeVp3TB8UoxKSHOACNQO1+IYHd8mc5xrCHmOHsvcMFJ6iYQcpL e/QElMVvL0X01e3Pbsy/EpF7T5wy7hAYxw4cH8iJXbIalFdfIZLydZdqKZGkRHZbi9V5 a9iu8W0c8UhLiV6Aa4INi5PlgdVFI/6kT3O6nFG6im2b7tJwQSAKkXrXVzjfk5Pa+JDP PyispXZxiSNbAvN7h/2ghi8tOgw16PLAoohs56P6dRN1/N7TCEnRv2FqMrYMZsyD5lJp gkO4TeGAXoFlRjUNhfRI50qr6Acuz/A5zJLxXCjpKp2VUu5Vo9wJv4t2Xpu0KOQNWk6n 8xZg== X-Gm-Message-State: ALoCoQms01FWwnlS45c+eyVRCrw3lroTBZdwcbVKh17RIuP3NdHVZZ2+OedO1KI6wSQXzxF/nA78 X-Received: by 10.194.79.225 with SMTP id m1mr4530667wjx.8.1438874658455; Thu, 06 Aug 2015 08:24:18 -0700 (PDT) MIME-Version: 1.0 Received: by 10.27.85.99 with HTTP; Thu, 6 Aug 2015 08:23:38 -0700 (PDT) In-Reply-To: References: <9F33F40F6F2CD847824537F3C4E37DDF1E826A00@MCHP04MSX.global-ad.net> <7515AC50-14F3-43C4-B3D9-D785100FC9C5@phonefromhere.com> From: Eric Rescorla Date: Thu, 6 Aug 2015 08:23:38 -0700 Message-ID: To: "Asveren, Tolga" Content-Type: multipart/alternative; boundary=047d7b10c903e4d155051ca61c94 Archived-At: Cc: "" Subject: Re: [rtcweb] What the gateway draft should say about mux/non-mux X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 06 Aug 2015 15:25:00 -0000 --047d7b10c903e4d155051ca61c94 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On Thu, Aug 6, 2015 at 7:51 AM, Asveren, Tolga wrote: > In practice =E2=80=93if not as initially targeted- a WebRTC-endpoint does= not > necessarily mean a =E2=80=9Cbrowser=E2=80=9D. I completely agree with our= statements about > browser based deployments though. All I am saying is =E2=80=9CLet people = decide > what they want to support, they are smart enough to know what a particula= r > deployment model requires=E2=80=9D. > I don't think there's any material difference between "browsers can totally refuse to do non-mux" and "WebRTC is mux-only", but as a browser vendor, I also don't care if it's the first. -Ekr For example, regardless of what specifications say, non-browser equipment > vendors, whose products need to interoperate with browsers, are > following/implementing how Chrome/Firefox are behaving. > > > > Thanks, > > Tolga > > > > *From:* Eric Rescorla [mailto:ekr@rtfm.com] > *Sent:* Thursday, August 06, 2015 10:36 AM > *To:* Asveren, Tolga > *Cc:* tim panton ; Hutton, Andrew < > andrew.hutton@unify.com>; > > *Subject:* Re: [rtcweb] What the gateway draft should say about > mux/non-mux > > > > I feel like people are talking past each other here. > > > > The browser vendors (at least Chrome and Firefox) want to completely > remove support for > > non-mux from their code. If we make this change, that means that there > will be no way for a > > browser to do non-mux and so as a practical matter we might as well simpl= y > say that > > WebRTC is mux and hence for the WebRTC side of a WebRTC gateway, there is > similarly no > > need to support non-mux, This only leaves the question of the non-WebRTC > side of > > the gateway, but that's out of scope here. So, I'm not sure what you are > asking for. > > > > WRT to the issue Jonathan raises about SDP being a negotiation, that's > true, but as > > a practical matter we're already far down the road of WebRTC offerers > offering SDP > > which in principle the answerer might choose not to accept but if it does > so the > > connection will fail > > > > -Ekr > > > > On Thu, Aug 6, 2015 at 7:12 AM, Asveren, Tolga > wrote: > > I think implementers themselves can weigh out the > advantages/disadvantaged/deployment models they are targeting/etc=E2=80= =A6 and > decide what to support/not to support. I don=E2=80=99t see any issue with= this as > long as there is a negotiation mechanism (which there is). I don=E2=80=99= t think > the availability of negotiation is encouraging people this or that way. > > > > Thanks, > > Tolga > > > > *From:* tim panton [mailto:tim@phonefromhere.com] > *Sent:* Thursday, August 06, 2015 10:07 AM > *To:* Hutton, Andrew > *Cc:* Asveren, Tolga ; < > rtcweb@ietf.org> > > > *Subject:* Re: [rtcweb] What the gateway draft should say about > mux/non-mux > > > > > > On 6 Aug 2015, at 08:30, Hutton, Andrew wrote: > > > > +1 to what Tim said. > > > > I don=E2=80=99t think this discussion is really about gateways at all it = is surely > about whether WebRTC browsers have to support non-mux and I don=E2=80=99t= really > see any good reason why they need to. > > > > If we had thought about this at the time we mandated DTLS-SRTP then we > would have mandated rtp-mux at the same time but unfortunately we didn=E2= =80=99t > but we can fix that now. > > > > Sadly true, but the situation in a browser is manageable since you might > expect 10 peer connections, resulting > > in a worst case of 60 UDP ports/DTLS sessions in use > > (assuming voice+video+data unbundled and RTCP-non-mux vs the 10 needed). > We > > also assume a relatively well endowed CPU - devoted largely to this task. > > > > On the gateway you=E2=80=99d hope to have thousands of sessions and presu= mably > much less CPU/memory resource per channel. > > So while I think it is unfortunate that browsers can do non-mux, it would > be plain stupid to do that on a gateway. Do we > > really want to encourage that ? > > > > T. > > > > > > > > Andy > > > > > > *From:* rtcweb [mailto:rtcweb-bounces@ietf.org ]= *On > Behalf Of *tim panton > *Sent:* 06 August 2015 13:53 > *To:* Asveren, Tolga > *Cc:* > *Subject:* Re: [rtcweb] What the gateway draft should say about > mux/non-mux > > > > So we are positing the existence of a webRTC gateway designed to support > thousands of calls which does ICE and DTLS but the > > designer decided deliberately to double the number of ICE sessions > required and double the number of DTLS sessions (and key > > generation costs) so that they can run RTCP (over ICE and DTLS) on a > separate port. In my estimation that=E2=80=99s one poor decision > > and should not be used as the basis of this (or any) standard. > > > > I=E2=80=99d rather not support rtcp-no-mux as I see zero advantages in ha= ving it. > (I know theoretically it might be possible to get > > a RTCP packet through a congested net on a different port with a separate > diffserv setting but that just seems so contrived). > > > > Tim. > > > > > > On 6 Aug 2015, at 06:44, Asveren, Tolga wrote: > > > > These assumptions are not necessarily true in a universal sense (like > almost any other assumption about different deployment models). > > > > Furthermore, and more importantly, there is nothing mandating WebRTC > endpoints to support non-rtcp-mux. It is a negotiated functionality. Any > entity can enforce rtcp-mux as a local policy. > > > > The issue with supporting non-rtcp-mux seems to be lack of clarity in the > relevant specifications. Fixing this =E2=80=93regardless of the outcome o= f any > other discussion- seems to be prudent IMHO. > > > > Thanks, > > Tolga > > > > *From:* Wyss, Felix [mailto:Felix.Wyss@inin.com ] > *Sent:* Thursday, August 06, 2015 6:37 AM > *To:* Christer Holmberg ; Asveren, Tolga = < > tasveren@sonusnet.com>; Schwarz, Albrecht (Albrecht) < > albrecht.schwarz@alcatel-lucent.com>; Roman Shpount ; > Rauschenbach, Uwe (Nokia - DE/Munich) > *Cc:* > *Subject:* Re: [rtcweb] What the gateway draft should say about > mux/non-mux > > > > Why shouldn't the gateway be required to do the mux/demux? Making the > WebRTC endpoints a lot more complex just so the legacy interop might > potentially be a teeny-tiny bit easier makes no sense IMHO. Actually, th= e > gateway would not be able to do "end-to-end" pass-through anyway as legac= y > equipment will either be unencrypted or use SDES (RFC#4568) for key > exchange. So the gateway will have to perform DTLS-SRTP to SDES-SRTP > transcryption--which already is way more hassle than RTP/RTCP mux/demux. > > > > --Felix > > > ------------------------------ > > *From:* rtcweb on behalf of Christer Holmberg < > christer.holmberg@ericsson.com> > *Sent:* Thursday, August 6, 2015 05:51 > *To:* Asveren, Tolga; Schwarz, Albrecht (Albrecht); Roman Shpount; > Rauschenbach, Uwe (Nokia - DE/Munich) > *Cc:* > *Subject:* Re: [rtcweb] What the gateway draft should say about > mux/non-mux > > > > Hi, > > > > No matter whether the gateway supports RTP/RTCP mux or not, there are > cases where the legacy network/endpoints will not use RTP/RTCP mux, so I > guess people then would want to be able to negotiate non-mux =E2=80=9Cend= -to-end=E2=80=9D, > rather than having the gateway to demux/mux RTP and RTCP. > > > > Regards, > > > > Christer > > > > *From:* Asveren, Tolga [mailto:tasveren@sonusnet.com > ] > *Sent:* 6. elokuuta 2015 12:18 > *To:* Schwarz, Albrecht (Albrecht); Roman Shpount; Rauschenbach, Uwe > (Nokia - DE/Munich) > *Cc:* ext Eric Rescorla; Christer Holmberg; Bernard Aboba; < > rtcweb@ietf.org> > *Subject:* Re: [rtcweb] What the gateway draft should say about > mux/non-mux > > > > Why should we consider 3GPP the sole "owner/user" of the term/entity > WebRTC-GW? I think it has a much more general meaning and use in practice= . > It can refer to many different types of elements which can be deployed in > many different environments, hence any attempt to define it > strictly/restrict its capabilities are futile IMHO. > > > > Thanks, > > Tolga > > > ------------------------------ > > *From:* Schwarz, Albrecht (Albrecht) > *Sent:* Thursday, August 6, 2015 2:44 AM > *To:* Asveren, Tolga; Roman Shpount; Rauschenbach, Uwe (Nokia - DE/Munich= ) > *Cc:* ext Eric Rescorla; Christer Holmberg; Bernard Aboba; < > rtcweb@ietf.org> > *Subject:* RE: [rtcweb] What the gateway draft should say about > mux/non-mux > > > > The concerned 3GPP WebRTC gateway (3GPP 23.334/29.334) supports already > RTP/RTCP transport multiplexing (since 3GPP Release 12), i.e. should not = be > the limiting factor in this discussion. > > For ones interested in the RTCP port allocation rules, see H.248.57: > > > https://www.itu.int/rec/dologin_pub.asp?lang=3De&id=3DT-REC-H.248.57-2014= 10-I!!PDF-E&type=3Ditems > > Clause 7 describes RTP/RTCP transport multiplexing. ITU-T H.248.57 is > already supported by 3GPP 29.334. > > > > The rationale behind the =E2=80=9Coptional tagging=E2=80=9D by 23.228 is = a third reason, > beyond > > >1. Using different QOS settings for RTCP vs RTP > > >2. Sending RTCP to a different device from RTP > > > > Don=E2=80=99t want to go in the 3GPP specific details, but it has nothing= to do > with the 3GPP UE-embedded WebRTC client nor any constraints by 3GPP WebRT= C > gateways. > > > > Thus, a WebRTC gateway MUST support RTP/RTCP transport multiplexing due t= o > its purpose in interworking support. > > > > Regards, > > Albrecht > > > > > > *From:* Asveren, Tolga [mailto:tasveren@sonusnet.com > ] > *Sent:* Mittwoch, 5. August 2015 19:47 > *To:* Roman Shpount; Rauschenbach, Uwe (Nokia - DE/Munich) > *Cc:* ext Eric Rescorla; Schwarz, Albrecht (Albrecht); Christer Holmberg; > Bernard Aboba; > *Subject:* RE: [rtcweb] What the gateway draft should say about > mux/non-mux > > > > i- I humbly disagree that using different QoS RTCP/RTP, e.g. different > DiffServ values , should be dismissed. > > ii- Let me also add another reason why no-rtcp-mux may be needed: > Implementation difficulties in certain GWs. > > > > Considering that there is already a negotiation mechanism for rtcp-mux > support, that it can be de-facto mandated by the choice of browsers for > Internet, I think what Christer/Albrecht suggested is the right way to mo= ve > forward: provide clarifications for vague points. I don=E2=80=99t underst= and why > lack of clarity in existing specifications should cause imposing > restrictions. This would be akin to dropping a feature due to a bug. In > this case, the =E2=80=9Cbug=E2=80=9D is lack of clarity in normative spec= ifications and it > can be addressed by further specification. > > > > Thanks, > > Tolga > > > > *From:* Roman Shpount [mailto:roman@telurix.com ] > *Sent:* Wednesday, August 05, 2015 12:29 PM > *To:* Rauschenbach, Uwe (Nokia - DE/Munich) > *Cc:* ext Eric Rescorla ; Schwarz, Albrecht (Albrecht) < > albrecht.schwarz@alcatel-lucent.com>; Asveren, Tolga < > tasveren@sonusnet.com>; Christer Holmberg ; > Bernard Aboba ; < > rtcweb@ietf.org> > *Subject:* Re: [rtcweb] What the gateway draft should say about > mux/non-mux > > > > On Wed, Aug 5, 2015 at 4:47 AM, Rauschenbach, Uwe (Nokia - DE/Munich) < > uwe.rauschenbach@nokia.com> wrote: > > Media gateway implementations according to 3GPP TS 23.228 may not support > rtcp-mux, as rtcp-mux is optional there. > > So if we drop non-mux support from web browsers, those media gateways tha= t > have not implemented rtcp-mux will stop interoperating. > > > > > > First of all, do you know of any WebRTC to IMS gateways that do not > implement rtcp-mux on the WebRTC side? I strongly suspect there are none. > > > > Second, the only reasons not to use rtcp-mux that I can think of are the > following: > > > > 1. Using different QOS settings for RTCP vs RTP > > 2. Sending RTCP to a different device from RTP > > > > I do not think the first use case warrants making rtcp-mux optional, > since, practically no one does this. > > Second use case is also fairly marginal. Plus it can be handled by the > gateway which can send RTCP to one device and RTP to another. > > > > So, unless someone can come up with a use case why RTP and RTCP should us= e > different transports, I think rtcp-mux should be mandatory. > > > > Regards, > > ______________ > > Roman Shpount > > _______________________________________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/listinfo/rtcweb > > > > > > > _______________________________________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/listinfo/rtcweb > > > --047d7b10c903e4d155051ca61c94 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On T= hu, Aug 6, 2015 at 7:51 AM, Asveren, Tolga <tasveren@sonusnet.com&= gt; wrote:

In practice =E2=80=93if not as initia= lly targeted- a WebRTC-endpoint does not necessarily mean a =E2=80=9Cbrowse= r=E2=80=9D. I completely agree with our statements about browser based deployments though. All I am saying is =E2=80=9CLet people decide what the= y want to support, they are smart enough to know what a particular deployme= nt model requires=E2=80=9D.


I don't think there's any material difference between "= ;browsers can totally refuse
to do non-mux" and "WebRTC= is mux-only", but as a browser vendor, I also
don't car= e if it's the first.

-Ekr
=C2=A0

For exa= mple, regardless of what specifications say, non-browser equipment vendors,= whose products need to interoperate with browsers, are following/implementing how Chrome/= Firefox are behaving.

=C2=A0

Thanks,

Tolga

=C2=A0

From: Eric Rescorla [mailto:ekr@rtfm.com]
Sent: Thursday, August 06, 2015 10:36 AM
To: Asveren, Tolga <tasveren@sonusnet.com>
Cc: tim panton <tim@phonefromhere.com>; Hutton, Andrew <andrew.hutton@unify.com= >; <rtcweb@ietf.= org> <rtcweb= @ietf.org>


Subject: Re: [rtcweb] What the gateway draft should say about mux/no= n-mux

=C2=A0

I feel like people are talking past each other here.=

=C2=A0

The browser vendors (at least Chrome and Firefox) wa= nt to completely remove support for

non-mux from their code. If we make this change, tha= t means that there will be no way for a

browser to do non-mux and so as a practical matter w= e might as well simply say that

WebRTC is mux and hence for the WebRTC side of a Web= RTC gateway, there is similarly no

need to support non-mux, This only leaves the questi= on of the non-WebRTC side of

the gateway, but that's out of scope here. So, I= 'm not sure what you are asking for.

=C2=A0

WRT to the issue Jonathan raises about SDP being a n= egotiation, that's true, but as

a practical matter we're already far down the ro= ad of WebRTC offerers offering SDP

which in principle the answerer might choose not to = accept but if it does so the

connection will fail

=C2=A0

-Ekr

=C2=A0

On Thu, Aug 6, 2015 at 7:12 AM, Asveren, Tolga <<= a href=3D"mailto:tasveren@sonusnet.com" target=3D"_blank">tasveren@sonusnet= .com> wrote:

I think implementers themselves can w= eigh out the advantages/disadvantaged/deployment models they are targeting/etc=E2=80=A6 and decide what to support/not to support. I don=E2= =80=99t see any issue with this as long as there is a negotiation mechanism= (which there is). I don=E2=80=99t think the availability of negotiation is= encouraging people this or that way.

=C2=A0

Thanks,

Tolga

=C2=A0

From: tim panton [mailto:tim@phonefromhere.com]
Sent: Thursday, August 06, 2015 10:07 AM
To: Hutton, Andrew <andrew.hutton@unify.com>
Cc: Asveren, Tolga <tasveren@sonusnet.com>; <rtcweb@ietf.org> <rtcweb@ietf.org>


Subject: Re: [rtcweb] What the gateway draft should say about mux/no= n-mux

=C2=A0

=C2=A0

On 6 Aug 2015, at 08:30, Hutton, Andrew <andrew.hutton@unify.c= om> wrote:

=C2=A0

+1 to what Tim said.=

=C2=A0

I don=E2=80=99t think this discussion= is really about gateways at all it is surely about whether WebRTC browsers have to support non-mux and I don=E2=80=99t really see any good reason why= they need to.

=C2=A0

If we had thought about this at the t= ime we mandated DTLS-SRTP then we would have mandated rtp-mux at the same time but unfortunately we didn=E2=80=99t but we can fix that n= ow.

=C2=A0

Sadly true, but the situation in a browser is manage= able since you might expect 10 peer connections, resulting=C2=A0<= /u>

in a worst case of 60 UDP ports/DTLS sessions in use= =C2=A0

(assuming voice+video+data unbundled and RTCP-non-mu= x vs the 10 needed). We=C2=A0

also assume a relatively well endowed CPU - devoted = largely to this task.

=C2=A0

On the gateway you=E2=80=99d hope to have thousands = of sessions and presumably much less CPU/memory resource per channel.

So while I think it is unfortunate that browsers can= do non-mux, it would be plain stupid to do that on a gateway. Do we=C2=A0<= u>

really want to encourage that ?

=C2=A0

T.

=C2=A0

=C2=A0<= /p>

=C2=A0

Andy

=C2=A0

=C2=A0

From: rtcweb [mailto:rtcweb-bounces@ietf.org] On Behalf Of tim panton
Sent: 06 August 2015 13:53
To: Asveren, Tolga
Cc: <rtcweb@= ietf.org>
Subject: Re: [rtcweb] What the gateway draft should say about mux/no= n-mux

=C2=A0

So we are positing the existence of a webRTC gateway= designed to support thousands of calls which does ICE and DTLS but the<= /u>

designer decided deliberately to double the number o= f ICE sessions required and double the number of DTLS sessions (and key=C2= =A0

generation costs) so that they can run RTCP (over IC= E and DTLS) on a separate port. In my estimation that=E2=80=99s one poor de= cision

and should not be used as the basis of this (or any)= standard.=C2=A0

=C2=A0

I=E2=80=99d rather not support rtcp-no-mux as I see = zero advantages in having it. (I know theoretically it might be possible to= get

a RTCP packet through a congested net on a different= port with a separate diffserv setting but that just seems so contrived).

=C2=A0

Tim.

=C2=A0

=C2=A0

On 6 Aug 2015, at 06:44, Asveren, Tolga <tasveren@sonusnet.com> wrote:

=C2=A0

These assumptions are not necessarily= true in a universal sense (like almost any other assumption about different deployment models).

=C2=A0

Furthermore, and more importantly, th= ere is nothing mandating WebRTC endpoints to support non-rtcp-mux. It is a negotiated functionality. Any entity can enforce rtcp-mux as a loc= al policy.=C2=A0

=C2=A0

The issue with supporting non-rtcp-mu= x seems to be lack of clarity in the relevant specifications. Fixing this =E2=80=93regardless of the outcome of any other discussion- se= ems to be prudent IMHO.

=C2=A0

Thanks,

Tolga

=C2=A0

From:=C2=A0Wyss, Felix [mailto:Felix.Wyss@inin.com= ]=C2=A0
Sent:=C2=A0Thursday, August 06, 2015 6:37 AM
To:=C2=A0Christer Holmberg <christer.holmberg@ericsson.com>; Asve= ren, Tolga <t= asveren@sonusnet.com>; Schwarz, Albrecht (Albrecht) <albrecht.schwarz@alcatel-lucent.com>; Roman Shpount <roman@telurix.com>; = Rauschenbach, Uwe (Nokia - DE/Munich) <uwe.rauschenbach@nokia.com>
Cc:=C2=A0<rt= cweb@ietf.org> <rtcweb@ietf.org>
Subject:=C2=A0Re: [rtcweb] What the gateway draft should say about m= ux/non-mux

=C2=A0

Why shouldn'= t the gateway be required to do the mux/demux?=C2=A0 Making the WebRTC endp= oints a lot more complex just so the legacy interop might potentially be a = teeny-tiny bit easier makes no sense IMHO.=C2=A0 Actually, the gateway would not be able to do "end-to-end" pass-through an= yway as legacy equipment will either be unencrypted or use SDES (RFC#4568) = for key exchange.=C2=A0 So the gateway will have to perform DTLS-SRTP to SD= ES-SRTP transcryption--which already is way more hassle than RTP/RTCP mux/demux.

=C2=A0=

--Felix

=C2=A0=

From:=C2=A0rtcweb <rtcweb-bounces@ietf.or= g> on behalf of Christer Holmberg <christer.holmberg= @ericsson.com>
Sent:=C2=A0Thursday, August 6, 2015 05:51
To:=C2=A0Asveren, Tolga; Schwarz, Albrecht (Albrecht); Roman Shpount= ; Rauschenbach, Uwe (Nokia - DE/Munich)
Cc:=C2=A0<rtcweb@ietf.org>
Subject:=C2=A0Re: [rtcweb] What the gateway draft should say about m= ux/non-mux

=C2=A0=

Hi,

=C2=A0

No matter whether the gateway supports RTP/RTCP mux or not, = there are cases where the legacy network/endpoints will not use RTP/RTCP mu= x, so I guess people then would want to be able to negotiate non-mux =E2=80=9Cend-to-end=E2=80=9D, rather than having the = gateway to demux/mux RTP and RTCP.

=C2=A0

Regards,

=C2=A0

Christer

=C2=A0

From:=C2=A0Asveren, Tolga [mailto:tasveren@sonus= net.com]=C2=A0
Sent:=C2=A06. elokuuta 2015 12:18
To:=C2=A0Schwarz, Albrecht (Albrecht); Roman Shpount; Rauschenbach, = Uwe (Nokia - DE/Munich)
Cc:=C2=A0ext Eric Rescorla; Christer Holmberg; Bernard Aboba; <rtcweb@ietf.org>
Subject:=C2=A0Re: [rtcweb] What the gateway draft should say about m= ux/non-mux

=C2=A0

Why should we co= nsider 3GPP the sole "owner/user" of the term/entity WebRTC-GW? I= think it has a much more general meaning and use in practice. It can refer= to many different types of elements which can be deployed in many different environments, hence any attempt to define it strictly/re= strict its capabilities are futile IMHO.

=C2=A0=

Thanks,

Tolga<= /u>

=C2=A0=

From:=C2=A0Schwarz, Albrecht (Albrecht) <albrecht.schwarz@alcatel-lucent.com>
Sent:=C2=A0Thursday, August 6, 2015 2:44 AM
To:=C2=A0Asveren, Tolga; Roman Shpount; Rauschenbach, Uwe (Nokia - D= E/Munich)
Cc:=C2=A0ext Eric Rescorla; Christer Holmberg; Bernard Aboba; <rtcweb@ietf.org>
Subject:=C2=A0RE: [rtcweb] What the gateway draft should say about m= ux/non-mux

=C2=A0=

The con= cerned 3GPP WebRTC gateway (3GPP 23.334/29.334) supports already RTP/RTCP t= ransport multiplexing (since 3GPP Release 12), i.e. should not be the limit= ing factor in this discussion.=C2=A0

For one= s interested in the RTCP port allocation rules, see H.248.57:=

Clause = 7 describes RTP/RTCP transport multiplexing. ITU-T H.248.57 is already supp= orted by 3GPP 29.334.

=C2=A0<= /span>

The rat= ionale behind the =E2=80=9Coptional tagging=E2=80=9D by 23.228 is a third r= eason, beyond

>1. Using dif= ferent QOS settings for RTCP vs RTP

>2. Sending R= TCP to a different device from RTP

=C2=A0<= /span>

Don=E2= =80=99t want to go in the 3GPP specific details, but it has nothing to do w= ith the 3GPP UE-embedded WebRTC client nor any constraints by 3GPP WebRTC g= ateways.

=C2=A0<= /span>

Thus, a= WebRTC gateway MUST support RTP/RTCP transport multiplexing due to its pur= pose in interworking support.

=C2=A0<= /span>

Regards= ,

Albrech= t

=C2=A0<= /span>

=C2=A0

From:=C2=A0Asveren, Tolga [mailto:tasveren@sonus= net.com]=C2=A0
Sent:=C2=A0Mittwoch, 5. August 2015 19:47
To:=C2=A0Roman Shpount; Rauschenbach, Uwe (Nokia - DE/Munich)
Cc:=C2=A0ext Eric Rescorla; Schwarz, Albrecht (Albrecht); Christer H= olmberg; Bernard Aboba; <rtcweb@ietf.org>
Subject:=C2=A0RE: [rtcweb] What the gateway draft should say about m= ux/non-mux

=C2=A0=

i- I humbly disagree that using different QoS RTCP/RTP, e.g.= different DiffServ values , should be dismissed.

ii- Let me also add another reason why no-rtcp-mux may be ne= eded: Implementation difficulties in certain GWs.

=C2=A0

Considering that there is already a negotiation mechanism fo= r rtcp-mux support, that it can be de-facto mandated by the choice of brows= ers for Internet, I think what Christer/Albrecht suggested is the right way to move forward: provide clarifications for vag= ue points. I don=E2=80=99t understand why lack of clarity in existing speci= fications should cause imposing restrictions. This would be akin to droppin= g a feature due to a bug. In this case, the =E2=80=9Cbug=E2=80=9D is lack of clarity in normative specifications a= nd it can be addressed by further specification.

=C2=A0

Thanks,

Tolga

=C2=A0

From:=C2=A0Roman Shpount [mailto:roman@telurix.com= ]=C2=A0
Sent:=C2=A0Wednesday, August 05, 2015 12:29 PM
To:=C2=A0Rauschenbach, Uwe (Nokia - DE/Munich) <uwe.rauschenbach@nokia.com>
Cc:=C2=A0ext Eric Rescorla <ekr@rtfm.com>; Schw= arz, Albrecht (Albrecht) <albrecht.schwarz@al= catel-lucent.com>; Asveren, Tolga <tasveren@sonusnet.com>; Chri= ster Holmberg <christer.holmberg@ericsson.com>; Bernard Aboba <bernard.aboba@gmail.com>; &= lt;rtcweb@ietf.org> <rtcweb@ietf.org<= /a>>
Subject:=C2=A0Re: [rtcweb] What the gateway draft should say about m= ux/non-mux

=C2=A0=

M= edia gateway implementations according to 3GPP TS 23.228=C2=A0may not support rtcp-mux, as rtcp-mux is optional there.<= /p>

S= o if we drop non-mux support from web browsers, those media gateways that h= ave not implemented rtcp-mux will stop interoperating.=C2=A0<= u>

=C2=A0=

=C2=A0=

First of all, do= you know of any WebRTC to IMS gateways that do not implement rtcp-mux on t= he WebRTC side? I strongly suspect there are none.

=C2=A0=

Second, the only= reasons not to use rtcp-mux that I can think of are the following:<= u>

=C2=A0=

1. Using differe= nt QOS settings for RTCP vs RTP

2. Sending RTCP = to a different device from RTP

=C2=A0=

I do not think t= he first use case warrants making rtcp-mux optional, since, practically no = one does this.

Second use case = is also fairly marginal. Plus it can be handled by the gateway which can se= nd RTCP to one device and RTP to another.

=C2=A0=

So, unless someo= ne can come up with a use case why RTP and RTCP should use different transp= orts, I think rtcp-mux should be mandatory.

=C2=A0=

Regards,<= u>

______________

Roman Shpount

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

=C2=A0

=C2=A0


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

=C2=A0


--047d7b10c903e4d155051ca61c94-- From nobody Thu Aug 6 09:51:41 2015 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 463841B3152 for ; Thu, 6 Aug 2015 09:51:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.2 X-Spam-Level: X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id udfWPaW0EhcU for ; Thu, 6 Aug 2015 09:51:35 -0700 (PDT) Received: from sesbmg22.ericsson.net (sesbmg22.ericsson.net [193.180.251.48]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D4AD31B314D for ; Thu, 6 Aug 2015 09:51:33 -0700 (PDT) X-AuditID: c1b4fb30-f79706d000007227-70-55c39093772b Received: from ESESSHC009.ericsson.se (Unknown_Domain [153.88.253.124]) by sesbmg22.ericsson.net (Symantec Mail Security) with SMTP id BB.76.29223.39093C55; Thu, 6 Aug 2015 18:51:31 +0200 (CEST) Received: from ESESSMB209.ericsson.se ([169.254.9.36]) by ESESSHC009.ericsson.se ([153.88.183.45]) with mapi id 14.03.0210.002; Thu, 6 Aug 2015 18:51:30 +0200 From: Christer Holmberg To: "Asveren, Tolga" , Eric Rescorla Thread-Topic: [rtcweb] What the gateway draft should say about mux/non-mux Thread-Index: AQHQy78thNOz8AYdMEys1nzX7WTf2J316g6A///gJYCAAAJzgIAAAVWAgAABfoCAA/DZAIAAQVMAgAL8GACAAIDGAIAAFdwAgADZaQCAACrOgIAAJh8A///v2QCAABLZAIAAEy6AgAAKf4CAAAo/gIAAAXuAgAAGkgCAAARvAIAAQvzH Date: Thu, 6 Aug 2015 16:51:30 +0000 Message-ID: <7594FB04B1934943A5C02806D1A2204B348EB645@ESESSMB209.ericsson.se> References: <9F33F40F6F2CD847824537F3C4E37DDF1E826A00@MCHP04MSX.global-ad.net> <7515AC50-14F3-43C4-B3D9-D785100FC9C5@phonefromhere.com> , In-Reply-To: Accept-Language: en-US Content-Language: en-GB X-MS-Has-Attach: X-MS-TNEF-Correlator: Content-Type: multipart/alternative; boundary="_000_7594FB04B1934943A5C02806D1A2204B348EB645ESESSMB209erics_" MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFmphkeLIzCtJLcpLzFFi42KZGfG3RnfyhMOhBsvfWluseH2O3WLtv3Z2 i9md75kcmD2WLPnJ5DH5cRuzx6XP/9kDmKO4bFJSczLLUov07RK4Mvb8vcJWMGsXc8WxLSdZ Gxg/NDN3MXJySAiYSFxZeRDKFpO4cG89G4gtJHCUUeLe//IuRi4gexGjxI+fX5m6GDk42AQs JLr/aYOYIgJeEo+25oCUMwtoSkxYtgusVVjAU+JW52ImEBukZN33a8wQ9j5Gic0/9UBsFgEV iXnNL8BqeAV8JWbvO8AOsaqPRaJz6RmwBKdAosS9412MIDYj0G3fT61hglgmLtH0ZSUrxM0C Ekv2nIe6X1Ti5eN/rBA1+RI3Lj5khVggKHFy5hOWCYwis5C0z0JSNgtJGUTcQOLL+9tQtrbE soWvmSFsfYnu96eZkMUXMLKvYhQtTi1Oyk03MtJLLcpMLi7Oz9PLSy3ZxAiMtoNbfhvsYHz5 3PEQowAHoxIP74L9h0KFWBPLiitzDzFKc7AoifPO2JwXKiSQnliSmp2aWpBaFF9UmpNafIiR iYNTqoFxJo+EyENFsy1Oq3ee90jaZsX0pucFd4l1RliW50mfmqDtSRc5XGJk1G2PHCi6cswk VeBH1rUnZxynlNTLf9u7aXlgnvLrDu+Lk39XCcseV198Q9t37bSZ/x41b1/gHvLkx/YnR6pE kzWWG5ZFL195+gcj2+xJ965HVNi7XfmrkKjdsKA7f5KJEktxRqKhFnNRcSIAzmIRKZcCAAA= Archived-At: Cc: "" Subject: Re: [rtcweb] What the gateway draft should say about mux/non-mux X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 06 Aug 2015 16:51:40 -0000 --_000_7594FB04B1934943A5C02806D1A2204B348EB645ESESSMB209erics_ Content-Type: text/plain; charset="windows-1256" Content-Transfer-Encoding: quoted-printable Hi, As an implementer, and as an IETF participant, I don't want a standard whic= h says "look what the browsers do and follow". That will only cause trouble= - especially if different browsers do different things. I want a standard,= when correctly implemented, ensures interoperability with browsers (and ot= her types of WebRTC entities). Implementations that only need to work in specific environments can of cour= se do whatever they want, but I don't think we consider e.g. Chrome and Fir= efox such implementations. Regards, Christer Sent from my Windows Phone ________________________________ From: Asveren, Tolga Sent: =FD06/=FD08/=FD2015 17:52 To: Eric Rescorla Cc: Subject: Re: [rtcweb] What the gateway draft should say about mux/non-mux In practice =96if not as initially targeted- a WebRTC-endpoint does not nec= essarily mean a =93browser=94. I completely agree with our statements about= browser based deployments though. All I am saying is =93Let people decide = what they want to support, they are smart enough to know what a particular = deployment model requires=94. For example, regardless of what specification= s say, non-browser equipment vendors, whose products need to interoperate w= ith browsers, are following/implementing how Chrome/Firefox are behaving. Thanks, Tolga From: Eric Rescorla [mailto:ekr@rtfm.com] Sent: Thursday, August 06, 2015 10:36 AM To: Asveren, Tolga Cc: tim panton ; Hutton, Andrew ; Subject: Re: [rtcweb] What the gateway draft should say about mux/non-mux I feel like people are talking past each other here. The browser vendors (at least Chrome and Firefox) want to completely remove= support for non-mux from their code. If we make this change, that means that there will= be no way for a browser to do non-mux and so as a practical matter we might as well simply = say that WebRTC is mux and hence for the WebRTC side of a WebRTC gateway, there is s= imilarly no need to support non-mux, This only leaves the question of the non-WebRTC si= de of the gateway, but that's out of scope here. So, I'm not sure what you are as= king for. WRT to the issue Jonathan raises about SDP being a negotiation, that's true= , but as a practical matter we're already far down the road of WebRTC offerers offer= ing SDP which in principle the answerer might choose not to accept but if it does s= o the connection will fail -Ekr On Thu, Aug 6, 2015 at 7:12 AM, Asveren, Tolga > wrote: I think implementers themselves can weigh out the advantages/disadvantaged/= deployment models they are targeting/etc=85 and decide what to support/not = to support. I don=92t see any issue with this as long as there is a negotia= tion mechanism (which there is). I don=92t think the availability of negoti= ation is encouraging people this or that way. Thanks, Tolga From: tim panton [mailto:tim@phonefromhere.com] Sent: Thursday, August 06, 2015 10:07 AM To: Hutton, Andrew = > Cc: Asveren, Tolga >; <= rtcweb@ietf.org> > Subject: Re: [rtcweb] What the gateway draft should say about mux/non-mux On 6 Aug 2015, at 08:30, Hutton, Andrew > wrote: +1 to what Tim said. I don=92t think this discussion is really about gateways at all it is surel= y about whether WebRTC browsers have to support non-mux and I don=92t reall= y see any good reason why they need to. If we had thought about this at the time we mandated DTLS-SRTP then we woul= d have mandated rtp-mux at the same time but unfortunately we didn=92t but = we can fix that now. Sadly true, but the situation in a browser is manageable since you might ex= pect 10 peer connections, resulting in a worst case of 60 UDP ports/DTLS sessions in use (assuming voice+video+data unbundled and RTCP-non-mux vs the 10 needed). We also assume a relatively well endowed CPU - devoted largely to this task. On the gateway you=92d hope to have thousands of sessions and presumably mu= ch less CPU/memory resource per channel. So while I think it is unfortunate that browsers can do non-mux, it would b= e plain stupid to do that on a gateway. Do we really want to encourage that ? T. Andy From: rtcweb [mailto:rtcweb-bounces@ietf.org] On Behalf Of tim panton Sent: 06 August 2015 13:53 To: Asveren, Tolga Cc: > Subject: Re: [rtcweb] What the gateway draft should say about mux/non-mux So we are positing the existence of a webRTC gateway designed to support th= ousands of calls which does ICE and DTLS but the designer decided deliberately to double the number of ICE sessions required= and double the number of DTLS sessions (and key generation costs) so that they can run RTCP (over ICE and DTLS) on a separa= te port. In my estimation that=92s one poor decision and should not be used as the basis of this (or any) standard. I=92d rather not support rtcp-no-mux as I see zero advantages in having it.= (I know theoretically it might be possible to get a RTCP packet through a congested net on a different port with a separate d= iffserv setting but that just seems so contrived). Tim. On 6 Aug 2015, at 06:44, Asveren, Tolga > wrote: These assumptions are not necessarily true in a universal sense (like almos= t any other assumption about different deployment models). Furthermore, and more importantly, there is nothing mandating WebRTC endpoi= nts to support non-rtcp-mux. It is a negotiated functionality. Any entity c= an enforce rtcp-mux as a local policy. The issue with supporting non-rtcp-mux seems to be lack of clarity in the r= elevant specifications. Fixing this =96regardless of the outcome of any oth= er discussion- seems to be prudent IMHO. Thanks, Tolga From: Wyss, Felix [mailto:Felix.Wyss@inin.com] Sent: Thursday, August 06, 2015 6:37 AM To: Christer Holmberg >; Asveren, Tolga >; Schwarz, Albrecht (Albrecht) >; Roman Shpount >; Rauschenbach, Uwe (Nokia - DE/Munich)= > Cc: > > Subject: Re: [rtcweb] What the gateway draft should say about mux/non-mux Why shouldn't the gateway be required to do the mux/demux? Making the WebR= TC endpoints a lot more complex just so the legacy interop might potentiall= y be a teeny-tiny bit easier makes no sense IMHO. Actually, the gateway wo= uld not be able to do "end-to-end" pass-through anyway as legacy equipment = will either be unencrypted or use SDES (RFC#4568) for key exchange. So the= gateway will have to perform DTLS-SRTP to SDES-SRTP transcryption--which a= lready is way more hassle than RTP/RTCP mux/demux. --Felix ________________________________ From: rtcweb > on b= ehalf of Christer Holmberg > Sent: Thursday, August 6, 2015 05:51 To: Asveren, Tolga; Schwarz, Albrecht (Albrecht); Roman Shpount; Rauschenba= ch, Uwe (Nokia - DE/Munich) Cc: > Subject: Re: [rtcweb] What the gateway draft should say about mux/non-mux Hi, No matter whether the gateway supports RTP/RTCP mux or not, there are cases= where the legacy network/endpoints will not use RTP/RTCP mux, so I guess p= eople then would want to be able to negotiate non-mux =93end-to-end=94, rat= her than having the gateway to demux/mux RTP and RTCP. Regards, Christer From: Asveren, Tolga [mailto:tasveren@sonusnet.com] Sent: 6. elokuuta 2015 12:18 To: Schwarz, Albrecht (Albrecht); Roman Shpount; Rauschenbach, Uwe (Nokia -= DE/Munich) Cc: ext Eric Rescorla; Christer Holmberg; Bernard Aboba; > Subject: Re: [rtcweb] What the gateway draft should say about mux/non-mux Why should we consider 3GPP the sole "owner/user" of the term/entity WebRTC= -GW? I think it has a much more general meaning and use in practice. It can= refer to many different types of elements which can be deployed in many di= fferent environments, hence any attempt to define it strictly/restrict its = capabilities are futile IMHO. Thanks, Tolga ________________________________ From: Schwarz, Albrecht (Albrecht) > Sent: Thursday, August 6, 2015 2:44 AM To: Asveren, Tolga; Roman Shpount; Rauschenbach, Uwe (Nokia - DE/Munich) Cc: ext Eric Rescorla; Christer Holmberg; Bernard Aboba; > Subject: RE: [rtcweb] What the gateway draft should say about mux/non-mux The concerned 3GPP WebRTC gateway (3GPP 23.334/29.334) supports already RTP= /RTCP transport multiplexing (since 3GPP Release 12), i.e. should not be th= e limiting factor in this discussion. For ones interested in the RTCP port allocation rules, see H.248.57: https://www.itu.int/rec/dologin_pub.asp?lang=3De&id=3DT-REC-H.248.57-201410= -I!!PDF-E&type=3Ditems Clause 7 describes RTP/RTCP transport multiplexing. ITU-T H.248.57 is alrea= dy supported by 3GPP 29.334. The rationale behind the =93optional tagging=94 by 23.228 is a third reason= , beyond >1. Using different QOS settings for RTCP vs RTP >2. Sending RTCP to a different device from RTP Don=92t want to go in the 3GPP specific details, but it has nothing to do w= ith the 3GPP UE-embedded WebRTC client nor any constraints by 3GPP WebRTC g= ateways. Thus, a WebRTC gateway MUST support RTP/RTCP transport multiplexing due to = its purpose in interworking support. Regards, Albrecht From: Asveren, Tolga [mailto:tasveren@sonusnet.com] Sent: Mittwoch, 5. August 2015 19:47 To: Roman Shpount; Rauschenbach, Uwe (Nokia - DE/Munich) Cc: ext Eric Rescorla; Schwarz, Albrecht (Albrecht); Christer Holmberg; Ber= nard Aboba; > Subject: RE: [rtcweb] What the gateway draft should say about mux/non-mux i- I humbly disagree that using different QoS RTCP/RTP, e.g. different Diff= Serv values , should be dismissed. ii- Let me also add another reason why no-rtcp-mux may be needed: Implement= ation difficulties in certain GWs. Considering that there is already a negotiation mechanism for rtcp-mux supp= ort, that it can be de-facto mandated by the choice of browsers for Interne= t, I think what Christer/Albrecht suggested is the right way to move forwar= d: provide clarifications for vague points. I don=92t understand why lack o= f clarity in existing specifications should cause imposing restrictions. Th= is would be akin to dropping a feature due to a bug. In this case, the =93b= ug=94 is lack of clarity in normative specifications and it can be addresse= d by further specification. Thanks, Tolga From: Roman Shpount [mailto:roman@telurix.com] Sent: Wednesday, August 05, 2015 12:29 PM To: Rauschenbach, Uwe (Nokia - DE/Munich) > Cc: ext Eric Rescorla >; Schwarz, Albrech= t (Albrecht) >; Asveren, Tolga >; Christer Holmberg >; Bernard Aboba >; > > Subject: Re: [rtcweb] What the gateway draft should say about mux/non-mux On Wed, Aug 5, 2015 at 4:47 AM, Rauschenbach, Uwe (Nokia - DE/Munich) > wrote: Media gateway implementations according to 3GPP TS 23.228 may not support r= tcp-mux, as rtcp-mux is optional there. So if we drop non-mux support from web browsers, those media gateways that = have not implemented rtcp-mux will stop interoperating. First of all, do you know of any WebRTC to IMS gateways that do not impleme= nt rtcp-mux on the WebRTC side? I strongly suspect there are none. Second, the only reasons not to use rtcp-mux that I can think of are the fo= llowing: 1. Using different QOS settings for RTCP vs RTP 2. Sending RTCP to a different device from RTP I do not think the first use case warrants making rtcp-mux optional, since,= practically no one does this. Second use case is also fairly marginal. Plus it can be handled by the gate= way which can send RTCP to one device and RTP to another. So, unless someone can come up with a use case why RTP and RTCP should use = different transports, I think rtcp-mux should be mandatory. Regards, ______________ Roman Shpount _______________________________________________ rtcweb mailing list rtcweb@ietf.org https://www.ietf.org/mailman/listinfo/rtcweb _______________________________________________ rtcweb mailing list rtcweb@ietf.org https://www.ietf.org/mailman/listinfo/rtcweb --_000_7594FB04B1934943A5C02806D1A2204B348EB645ESESSMB209erics_ Content-Type: text/html; charset="windows-1256" Content-Transfer-Encoding: quoted-printable
Hi,

As an implementer, and as an IETF participant, I don't want a standard whic= h says "look what the browsers do and follow". That will only cau= se trouble - especially if different browsers do different things. I want a= standard, when correctly implemented, ensures interoperability with browsers (and other types of WebRTC entities).

Implementations that only need to work in specific environments can of cour= se do whatever they want, but I don't think we consider e.g. Chrome and Fir= efox such implementations.

Regards,

Christer

Sent from my Windows Phone
From: Asveren, Tolga
Sent: =FD06= /=FD08/=FD2015 17:52
To: Eric Rescorla
Cc: <rtcweb@ietf.org>
Subject: Re: [= rtcweb] What the gateway draft should say about mux/non-mux

In practice =96if not as initially = targeted- a WebRTC-endpoint does not necessarily mean a =93browser=94. I co= mpletely agree with our statements about browser based deployments though. All I am saying is =93Let people decide what they want= to support, they are smart enough to know what a particular deployment mod= el requires=94. For example, regardless of what specifications say, non-bro= wser equipment vendors, whose products need to interoperate with browsers, are following/implementing how Chrome/= Firefox are behaving.

 

Thanks,

Tolga

 

From: Eric Rescorla [mailto:ekr@rt= fm.com]
Sent: Thursday, August 06, 2015 10:36 AM
To: Asveren, Tolga <tasveren@sonusnet.com>
Cc: tim panton <tim@phonefromhere.com>; Hutton, Andrew <and= rew.hutton@unify.com>; <rtcweb@ietf.org> <rtcweb@ietf.org> Subject: Re: [rtcweb] What the gateway draft should say about mux/no= n-mux

 

I feel like people are talking past each other here.=

 

The browser vendors (at least Chrome and Firefox) wa= nt to completely remove support for

non-mux from their code. If we make this change, tha= t means that there will be no way for a

browser to do non-mux and so as a practical matter w= e might as well simply say that

WebRTC is mux and hence for the WebRTC side of a Web= RTC gateway, there is similarly no

need to support non-mux, This only leaves the questi= on of the non-WebRTC side of

the gateway, but that's out of scope here. So, I'm n= ot sure what you are asking for.

 

WRT to the issue Jonathan raises about SDP being a n= egotiation, that's true, but as

a practical matter we're already far down the road o= f WebRTC offerers offering SDP

which in principle the answerer might choose not to = accept but if it does so the

connection will fail

 

-Ekr

 

On Thu, Aug 6, 2015 at 7:12 AM, Asveren, Tolga <<= a href=3D"mailto:tasveren@sonusnet.com" target=3D"_blank">tasveren@sonusnet= .com> wrote:

I think implementers the= mselves can weigh out the advantages/disadvantaged/deployment models they a= re targeting/etc=85 and decide what to support/not to support. I don=92t see any issue with this as long as there is a negoti= ation mechanism (which there is). I don=92t think the availability of negot= iation is encouraging people this or that way.

 

Thanks,

Tolga

 

From: tim panton [mailt= o:tim@phonefromh= ere.com]
Sent: Thursday, August 06, 2015 10:07 AM
To: Hutton, Andrew <andrew.hutton@unify.com>
Cc: Asveren, Tolga <tasveren@sonusnet.com>; <rtcweb@ietf.org> <rtcweb@ietf.org>


Subject: Re: [rtcweb] What the gateway draft should say about mux/no= n-mux

 

 

On 6 Aug 2015, at 08:30, Hutton, Andrew &= lt;andrew.hutt= on@unify.com> wrote:

 

+1 to what Tim said.=

 

I don=92t think this dis= cussion is really about gateways at all it is surely about whether WebRTC b= rowsers have to support non-mux and I don=92t really see any good reason why they need to.

 

If we had thought about = this at the time we mandated DTLS-SRTP then we would have mandated rtp-mux = at the same time but unfortunately we didn=92t but we can fix that now.

 

Sadly true, but the situation in a browse= r is manageable since you might expect 10 peer connections, resulting =

in a worst case of 60 UDP ports/DTLS sess= ions in use 

(assuming voice+video+data unbund= led and RTCP-non-mux vs the 10 needed). We 

also assume a relatively well endowed CPU= - devoted largely to this task.

 

On the gateway you=92d hope to have thous= ands of sessions and presumably much less CPU/memory resource per channel.<= /p>

So while I think it is unfortunate that b= rowsers can do non-mux, it would be plain stupid to do that on a gateway. D= o we 

really want to encourage that ?

 

T.

 

 

 

Andy

 

 

From: rtcweb [mailto:rtcweb-bounces@iet= f.org] On Behalf Of tim panton
Sent: 06 August 2015 13:53
To: Asveren, Tolga
Cc: <rtcweb@= ietf.org>
Subject: Re: [rtcweb] What the gateway draft should say about mux/no= n-mux

 

So we are positing the existence of a web= RTC gateway designed to support thousands of calls which does ICE and DTLS = but the

designer decided deliberately to double t= he number of ICE sessions required and double the number of DTLS sessions (= and key 

generation costs) so that they can run RT= CP (over ICE and DTLS) on a separate port. In my estimation that=92s one po= or decision

and should not be used as the basis of th= is (or any) standard. 

 

I=92d rather not support rtcp-no-mux as I= see zero advantages in having it. (I know theoretically it might be possib= le to get

a RTCP packet through a congested net on = a different port with a separate diffserv setting but that just seems so co= ntrived).

 

Tim.

 

 

On 6 Aug 2015, at 06:44, Asveren, Tolga &= lt;tasveren@sonu= snet.com> wrote:

 

These assumptions are no= t necessarily true in a universal sense (like almost any other assumption a= bout different deployment models).

 

Furthermore, and more im= portantly, there is nothing mandating WebRTC endpoints to support non-rtcp-= mux. It is a negotiated functionality. Any entity can enforce rtcp-mux as a local policy. 

 

The issue with supportin= g non-rtcp-mux seems to be lack of clarity in the relevant specifications. = Fixing this =96regardless of the outcome of any other discussion- seems to be prudent IMHO.

 

Thanks,

Tolga

 

From: Wyss, Felix = [mailto:Felix.Wyss= @inin.com] 
Sent: Thursday, August 06, 2015 6:37 AM
To: Christer Holmberg <christer.holmberg@ericsson.com>; Asve= ren, Tolga <t= asveren@sonusnet.com>; Schwarz, Albrecht (Albrecht) <albrecht.schwarz@alcatel-lucent.com>; Roman Shpount <roman@telurix.com>; = Rauschenbach, Uwe (Nokia - DE/Munich) <uwe.rauschenbach@nokia.com>
Cc: <rt= cweb@ietf.org> <rtcweb@ietf.org>
Subject: Re: [rtcweb] What the gateway draft should say about m= ux/non-mux

 

Why shouldn't the gateway be required to = do the mux/demux?  Making the WebRTC endpoints a lot more complex just= so the legacy interop might potentially be a teeny-tiny bit easier makes no sense IMHO.  Actually, the gateway would not be a= ble to do "end-to-end" pass-through anyway as legacy equipment wi= ll either be unencrypted or use SDES (RFC#4568) for key exchange.  So = the gateway will have to perform DTLS-SRTP to SDES-SRTP transcryption--which already is way more hassle than RTP/RTCP mux/demux.

 

--Felix

 

From:&n= bsp;rtcweb <rtcweb-bounces@ietf.org> on behalf of Christer Holmberg <christer.holmberg= @ericsson.com>
Sent: Thursday, August 6, 2015 05:51
To: Asveren, Tolga; Schwarz, Albrecht (Albrecht); Roman Shpount= ; Rauschenbach, Uwe (Nokia - DE/Munich)
Cc: <rtcweb@ietf.org>
Subject: Re: [rtcweb] What the gateway draft should say about m= ux/non-mux

 

Hi,

 

No matte= r whether the gateway supports RTP/RTCP mux or not, there are cases where t= he legacy network/endpoints will not use RTP/RTCP mux, so I guess people then would want to be able to negotiate non-mux =93= end-to-end=94, rather than having the gateway to demux/mux RTP and RTCP.

 

Regards,=

 

Christer=

 

From:&nbs= p;Asveren, Tolga [mailto:tasveren@sonusnet.com]&nbs= p;
Sent: 6. elokuuta 2015 12:18
To: Schwarz, Albrecht (Albrecht); Roman Shpount; Rauschenbach, = Uwe (Nokia - DE/Munich)
Cc: ext Eric Rescorla; Christer Holmberg; Bernard Aboba; <rtcweb@ietf.org>
Subject: Re: [rtcweb] What the gateway draft should say about m= ux/non-mux

 

Why should we consider 3GPP the sole &quo= t;owner/user" of the term/entity WebRTC-GW? I think it has a much more= general meaning and use in practice. It can refer to many different types of elements which can be deployed in many different enviro= nments, hence any attempt to define it strictly/restrict its capabilities a= re futile IMHO.

 

Thanks,

Tolga

 

From:&n= bsp;Schwarz, Albrecht (Albrecht) <albrecht.sc= hwarz@alcatel-lucent.com>
Sent: Thursday, August 6, 2015 2:44 AM
To: Asveren, Tolga; Roman Shpount; Rauschenbach, Uwe (Nokia - D= E/Munich)
Cc: ext Eric Rescorla; Christer Holmberg; Bernard Aboba; <rtcweb@ietf.org>
Subject: RE: [rtcweb] What the gateway draft should say about m= ux/non-mux

 

The concerned 3GPP WebRTC gate= way (3GPP 23.334/29.334) supports already RTP/RTCP transport multiplexing (= since 3GPP Release 12), i.e. should not be the limiting factor in this discussion. 

For ones interested in the RTC= P port allocation rules, see H.248.57:

Clause 7 describes RTP/RTCP tr= ansport multiplexing. ITU-T H.248.57 is already supported by 3GPP 29.334.

 

The rationale behind the =93op= tional tagging=94 by 23.228 is a third reason, beyond

>1. Using different QOS settings for R= TCP vs RTP

>2. Sending RTCP to a different device= from RTP

 

Don=92t want to go in the 3GPP= specific details, but it has nothing to do with the 3GPP UE-embedded WebRT= C client nor any constraints by 3GPP WebRTC gateways.

 

Thus, a WebRTC gateway MUST su= pport RTP/RTCP transport multiplexing due to its purpose in interworking su= pport.

 

Regards,

Albrecht

 

 

From:&nbs= p;Asveren, Tolga [mailto:tasveren@sonusnet.com]&nbs= p;
Sent: Mittwoch, 5. August 2015 19:47
To: Roman Shpount; Rauschenbach, Uwe (Nokia - DE/Munich)
Cc: ext Eric Rescorla; Schwarz, Albrecht (Albrecht); Christer H= olmberg; Bernard Aboba; <rtcweb@ietf.org>
Subject: RE: [rtcweb] What the gateway draft should say about m= ux/non-mux

 

i- I hum= bly disagree that using different QoS RTCP/RTP, e.g. different DiffServ val= ues , should be dismissed.

ii- Let = me also add another reason why no-rtcp-mux may be needed: Implementation di= fficulties in certain GWs.

 

Consider= ing that there is already a negotiation mechanism for rtcp-mux support, tha= t it can be de-facto mandated by the choice of browsers for Internet, I think what Christer/Albrecht suggested is the right way to= move forward: provide clarifications for vague points. I don=92t understan= d why lack of clarity in existing specifications should cause imposing rest= rictions. This would be akin to dropping a feature due to a bug. In this case, the =93bug=94 is lack of clarity in = normative specifications and it can be addressed by further specification.<= /span>

 

Thanks,<= /span>

Tolga

 

From:&n= bsp;Roman Shpount [<= span style=3D"color:purple">mailto:roman@telurix.com] 
Sent: Wednesday, August 05, 2015 12:29 PM
To: Rauschenbach, Uwe (Nokia - DE/Munich) <uwe.rauschenbach@nokia.com>
Cc: ext Eric Rescorla <ekr@rtfm.com>; Schw= arz, Albrecht (Albrecht) <albrecht.schwarz@al= catel-lucent.com>; Asveren, Tolga <tasveren@sonusnet.com>; Chri= ster Holmberg <christer.holmberg@ericsson.com>; Bernard Aboba <bernard.aboba@gmail.com>; &= lt;rtcweb@ietf.org> <rtcweb@ietf.org<= /a>>
Subject: Re: [rtcweb] What the gateway draft should say about m= ux/non-mux

 

Media gateway implementat= ions according to 3GPP TS 23.228 may not support rtcp-mux, as rtcp-mux is optional there.

So if we drop non-mux sup= port from web browsers, those media gateways that have not implemented rtcp= -mux will stop interoperating. 

 

 

First of all, do you know of any WebRTC t= o IMS gateways that do not implement rtcp-mux on the WebRTC side? I strongl= y suspect there are none.

 

Second, the only reasons not to use rtcp-= mux that I can think of are the following:

 

1. Using different QOS settings for RTCP = vs RTP

2. Sending RTCP to a different device fro= m RTP

 

I do not think the first use case warrant= s making rtcp-mux optional, since, practically no one does this.

Second use case is also fairly marginal. = Plus it can be handled by the gateway which can send RTCP to one device and= RTP to another.

 

So, unless someone can come up with a use= case why RTP and RTCP should use different transports, I think rtcp-mux sh= ould be mandatory.

 

Regards,

______________

Roman Shpount

______________________________________= _________
rtcweb mailing list
rtcweb@ietf.org = https://www.ietf.org/mailman/listinfo/rtcweb

 

 


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

 

--_000_7594FB04B1934943A5C02806D1A2204B348EB645ESESSMB209erics_-- From nobody Thu Aug 6 10:07:29 2015 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BF4EA1B3C43 for ; Thu, 6 Aug 2015 10:07:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.2 X-Spam-Level: X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NifQiG7Z5J1O for ; Thu, 6 Aug 2015 10:07:22 -0700 (PDT) Received: from sessmg22.ericsson.net (sessmg22.ericsson.net [193.180.251.58]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A1EE11B3C42 for ; Thu, 6 Aug 2015 10:07:20 -0700 (PDT) X-AuditID: c1b4fb3a-f79356d000006281-58-55c39446b686 Received: from ESESSHC017.ericsson.se (Unknown_Domain [153.88.253.124]) by sessmg22.ericsson.net (Symantec Mail Security) with SMTP id 72.1D.25217.64493C55; Thu, 6 Aug 2015 19:07:19 +0200 (CEST) Received: from ESESSMB209.ericsson.se ([169.254.9.36]) by ESESSHC017.ericsson.se ([153.88.183.69]) with mapi id 14.03.0210.002; Thu, 6 Aug 2015 19:07:18 +0200 From: Christer Holmberg To: Eric Rescorla , "Asveren, Tolga" Thread-Topic: [rtcweb] What the gateway draft should say about mux/non-mux Thread-Index: AQHQy78thNOz8AYdMEys1nzX7WTf2J316g6A///gJYCAAAJzgIAAAVWAgAABfoCAA/DZAIAAQVMAgAL8GACAAIDGAIAAFdwAgADZaQCAACrOgIAAJh8A///v2QCAABLZAIAAEy6AgAAKf4CAAAo/gIAAAXuAgAAGkgCAAEvTpw== Date: Thu, 6 Aug 2015 17:07:16 +0000 Message-ID: <7594FB04B1934943A5C02806D1A2204B348EB6A3@ESESSMB209.ericsson.se> References: <9F33F40F6F2CD847824537F3C4E37DDF1E826A00@MCHP04MSX.global-ad.net> <7515AC50-14F3-43C4-B3D9-D785100FC9C5@phonefromhere.com> , In-Reply-To: Accept-Language: en-US Content-Language: en-GB X-MS-Has-Attach: X-MS-TNEF-Correlator: Content-Type: multipart/alternative; boundary="_000_7594FB04B1934943A5C02806D1A2204B348EB6A3ESESSMB209erics_" MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFmplkeLIzCtJLcpLzFFi42KZGfG3Rtd9yuFQg4mTGS1WvD7HbrH2Xzu7 xezO90wOzB5Llvxk8pj8uI3Z49Ln/+wBzFFcNimpOZllqUX6dglcGStvH2csuLeIueLWtAaW BsZHH5m6GDk5JARMJGZ+P8kCYYtJXLi3nq2LkYtDSOAoo8Tcs3eZIJxFjBJX9y0Hcjg42AQs JLr/aYM0iAh4SSz+/oQdxGYW0JSYsGwXG4gtLOApcatzMRNMzbrv15hB5ogI7GKU2LP+CyNI gkVARWLprZlgNq+Ar8SsbW+glm1nlth5fBkrSIJTIFBi56cTzCA2I9B530+tYYLYJi7R9GUl K8TZAhJL9pxnhrBFJV4+/scKciizQL7E7LvCEPMFJU7OfMIygVFkFpLuWQhVs5BUQZQYSHx5 fxvK1pZYtvA1M4StL9H9/jQTsvgCRvZVjKLFqcXFuelGRnqpRZnJxcX5eXp5qSWbGIHxdnDL b6sdjAefOx5iFOBgVOLhXbD/UKgQa2JZcWXuIUZpDhYlcd4Zm/NChQTSE0tSs1NTC1KL4otK c1KLDzEycXBKNTAmfuj/PWmG+cxnUbnvoh0rcvQXzpvvLObs7HG3x91GWvTBjNpK/sJP/Gyf 1U+zW8tdmm36au/WDWdvr/60X8nHsDu+7p5W6r0n4tMbzpd/Yz9um9eUsjphI6v/zdaAhf91 A7Lsf2RXOfuu0xPKuOdXW7R1i9oE3oCbL0P5hKac7as6oV2WuECJpTgj0VCLuag4EQAs+U9o mAIAAA== Archived-At: Cc: "" Subject: Re: [rtcweb] What the gateway draft should say about mux/non-mux X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 06 Aug 2015 17:07:27 -0000 --_000_7594FB04B1934943A5C02806D1A2204B348EB6A3ESESSMB209erics_ Content-Type: text/plain; charset="windows-1256" Content-Transfer-Encoding: quoted-printable The SDP issue applies also to e.g. codecs: you can't mandate a codec in an = SDP offer, but you can do it in a specification. Regards, Christer Sent from my Windows Phone ________________________________ From: Eric Rescorla Sent: =FD06/=FD08/=FD2015 17:36 To: Asveren, Tolga Cc: Subject: Re: [rtcweb] What the gateway draft should say about mux/non-mux I feel like people are talking past each other here. The browser vendors (at least Chrome and Firefox) want to completely remove= support for non-mux from their code. If we make this change, that means that there will= be no way for a browser to do non-mux and so as a practical matter we might as well simply = say that WebRTC is mux and hence for the WebRTC side of a WebRTC gateway, there is s= imilarly no need to support non-mux, This only leaves the question of the non-WebRTC si= de of the gateway, but that's out of scope here. So, I'm not sure what you are as= king for. WRT to the issue Jonathan raises about SDP being a negotiation, that's true= , but as a practical matter we're already far down the road of WebRTC offerers offer= ing SDP which in principle the answerer might choose not to accept but if it does s= o the connection will fail -Ekr On Thu, Aug 6, 2015 at 7:12 AM, Asveren, Tolga > wrote: I think implementers themselves can weigh out the advantages/disadvantaged/= deployment models they are targeting/etc=85 and decide what to support/not = to support. I don=92t see any issue with this as long as there is a negotia= tion mechanism (which there is). I don=92t think the availability of negoti= ation is encouraging people this or that way. Thanks, Tolga From: tim panton [mailto:tim@phonefromhere.com] Sent: Thursday, August 06, 2015 10:07 AM To: Hutton, Andrew = > Cc: Asveren, Tolga >; <= rtcweb@ietf.org> > Subject: Re: [rtcweb] What the gateway draft should say about mux/non-mux On 6 Aug 2015, at 08:30, Hutton, Andrew > wrote: +1 to what Tim said. I don=92t think this discussion is really about gateways at all it is surel= y about whether WebRTC browsers have to support non-mux and I don=92t reall= y see any good reason why they need to. If we had thought about this at the time we mandated DTLS-SRTP then we woul= d have mandated rtp-mux at the same time but unfortunately we didn=92t but = we can fix that now. Sadly true, but the situation in a browser is manageable since you might ex= pect 10 peer connections, resulting in a worst case of 60 UDP ports/DTLS sessions in use (assuming voice+video+data unbundled and RTCP-non-mux vs the 10 needed). We also assume a relatively well endowed CPU - devoted largely to this task. On the gateway you=92d hope to have thousands of sessions and presumably mu= ch less CPU/memory resource per channel. So while I think it is unfortunate that browsers can do non-mux, it would b= e plain stupid to do that on a gateway. Do we really want to encourage that ? T. Andy From: rtcweb [mailto:rtcweb-bounces@ietf.org] On Behalf Of tim panton Sent: 06 August 2015 13:53 To: Asveren, Tolga Cc: > Subject: Re: [rtcweb] What the gateway draft should say about mux/non-mux So we are positing the existence of a webRTC gateway designed to support th= ousands of calls which does ICE and DTLS but the designer decided deliberately to double the number of ICE sessions required= and double the number of DTLS sessions (and key generation costs) so that they can run RTCP (over ICE and DTLS) on a separa= te port. In my estimation that=92s one poor decision and should not be used as the basis of this (or any) standard. I=92d rather not support rtcp-no-mux as I see zero advantages in having it.= (I know theoretically it might be possible to get a RTCP packet through a congested net on a different port with a separate d= iffserv setting but that just seems so contrived). Tim. On 6 Aug 2015, at 06:44, Asveren, Tolga > wrote: These assumptions are not necessarily true in a universal sense (like almos= t any other assumption about different deployment models). Furthermore, and more importantly, there is nothing mandating WebRTC endpoi= nts to support non-rtcp-mux. It is a negotiated functionality. Any entity c= an enforce rtcp-mux as a local policy. The issue with supporting non-rtcp-mux seems to be lack of clarity in the r= elevant specifications. Fixing this =96regardless of the outcome of any oth= er discussion- seems to be prudent IMHO. Thanks, Tolga From: Wyss, Felix [mailto:Felix.Wyss@inin.com] Sent: Thursday, August 06, 2015 6:37 AM To: Christer Holmberg >; Asveren, Tolga >; Schwarz, Albrecht (Albrecht) >; Roman Shpount >; Rauschenbach, Uwe (Nokia - DE/Munich)= > Cc: > > Subject: Re: [rtcweb] What the gateway draft should say about mux/non-mux Why shouldn't the gateway be required to do the mux/demux? Making the WebR= TC endpoints a lot more complex just so the legacy interop might potentiall= y be a teeny-tiny bit easier makes no sense IMHO. Actually, the gateway wo= uld not be able to do "end-to-end" pass-through anyway as legacy equipment = will either be unencrypted or use SDES (RFC#4568) for key exchange. So the= gateway will have to perform DTLS-SRTP to SDES-SRTP transcryption--which a= lready is way more hassle than RTP/RTCP mux/demux. --Felix ________________________________ From: rtcweb > on b= ehalf of Christer Holmberg > Sent: Thursday, August 6, 2015 05:51 To: Asveren, Tolga; Schwarz, Albrecht (Albrecht); Roman Shpount; Rauschenba= ch, Uwe (Nokia - DE/Munich) Cc: > Subject: Re: [rtcweb] What the gateway draft should say about mux/non-mux Hi, No matter whether the gateway supports RTP/RTCP mux or not, there are cases= where the legacy network/endpoints will not use RTP/RTCP mux, so I guess p= eople then would want to be able to negotiate non-mux =93end-to-end=94, rat= her than having the gateway to demux/mux RTP and RTCP. Regards, Christer From: Asveren, Tolga [mailto:tasveren@sonusnet.com] Sent: 6. elokuuta 2015 12:18 To: Schwarz, Albrecht (Albrecht); Roman Shpount; Rauschenbach, Uwe (Nokia -= DE/Munich) Cc: ext Eric Rescorla; Christer Holmberg; Bernard Aboba; > Subject: Re: [rtcweb] What the gateway draft should say about mux/non-mux Why should we consider 3GPP the sole "owner/user" of the term/entity WebRTC= -GW? I think it has a much more general meaning and use in practice. It can= refer to many different types of elements which can be deployed in many di= fferent environments, hence any attempt to define it strictly/restrict its = capabilities are futile IMHO. Thanks, Tolga ________________________________ From: Schwarz, Albrecht (Albrecht) > Sent: Thursday, August 6, 2015 2:44 AM To: Asveren, Tolga; Roman Shpount; Rauschenbach, Uwe (Nokia - DE/Munich) Cc: ext Eric Rescorla; Christer Holmberg; Bernard Aboba; > Subject: RE: [rtcweb] What the gateway draft should say about mux/non-mux The concerned 3GPP WebRTC gateway (3GPP 23.334/29.334) supports already RTP= /RTCP transport multiplexing (since 3GPP Release 12), i.e. should not be th= e limiting factor in this discussion. For ones interested in the RTCP port allocation rules, see H.248.57: https://www.itu.int/rec/dologin_pub.asp?lang=3De&id=3DT-REC-H.248.57-201410= -I!!PDF-E&type=3Ditems Clause 7 describes RTP/RTCP transport multiplexing. ITU-T H.248.57 is alrea= dy supported by 3GPP 29.334. The rationale behind the =93optional tagging=94 by 23.228 is a third reason= , beyond >1. Using different QOS settings for RTCP vs RTP >2. Sending RTCP to a different device from RTP Don=92t want to go in the 3GPP specific details, but it has nothing to do w= ith the 3GPP UE-embedded WebRTC client nor any constraints by 3GPP WebRTC g= ateways. Thus, a WebRTC gateway MUST support RTP/RTCP transport multiplexing due to = its purpose in interworking support. Regards, Albrecht From: Asveren, Tolga [mailto:tasveren@sonusnet.com] Sent: Mittwoch, 5. August 2015 19:47 To: Roman Shpount; Rauschenbach, Uwe (Nokia - DE/Munich) Cc: ext Eric Rescorla; Schwarz, Albrecht (Albrecht); Christer Holmberg; Ber= nard Aboba; > Subject: RE: [rtcweb] What the gateway draft should say about mux/non-mux i- I humbly disagree that using different QoS RTCP/RTP, e.g. different Diff= Serv values , should be dismissed. ii- Let me also add another reason why no-rtcp-mux may be needed: Implement= ation difficulties in certain GWs. Considering that there is already a negotiation mechanism for rtcp-mux supp= ort, that it can be de-facto mandated by the choice of browsers for Interne= t, I think what Christer/Albrecht suggested is the right way to move forwar= d: provide clarifications for vague points. I don=92t understand why lack o= f clarity in existing specifications should cause imposing restrictions. Th= is would be akin to dropping a feature due to a bug. In this case, the =93b= ug=94 is lack of clarity in normative specifications and it can be addresse= d by further specification. Thanks, Tolga From: Roman Shpount [mailto:roman@telurix.com] Sent: Wednesday, August 05, 2015 12:29 PM To: Rauschenbach, Uwe (Nokia - DE/Munich) > Cc: ext Eric Rescorla >; Schwarz, Albrech= t (Albrecht) >; Asveren, Tolga >; Christer Holmberg >; Bernard Aboba >; > > Subject: Re: [rtcweb] What the gateway draft should say about mux/non-mux On Wed, Aug 5, 2015 at 4:47 AM, Rauschenbach, Uwe (Nokia - DE/Munich) > wrote: Media gateway implementations according to 3GPP TS 23.228 may not support r= tcp-mux, as rtcp-mux is optional there. So if we drop non-mux support from web browsers, those media gateways that = have not implemented rtcp-mux will stop interoperating. First of all, do you know of any WebRTC to IMS gateways that do not impleme= nt rtcp-mux on the WebRTC side? I strongly suspect there are none. Second, the only reasons not to use rtcp-mux that I can think of are the fo= llowing: 1. Using different QOS settings for RTCP vs RTP 2. Sending RTCP to a different device from RTP I do not think the first use case warrants making rtcp-mux optional, since,= practically no one does this. Second use case is also fairly marginal. Plus it can be handled by the gate= way which can send RTCP to one device and RTP to another. So, unless someone can come up with a use case why RTP and RTCP should use = different transports, I think rtcp-mux should be mandatory. Regards, ______________ Roman Shpount _______________________________________________ rtcweb mailing list rtcweb@ietf.org https://www.ietf.org/mailman/listinfo/rtcweb _______________________________________________ rtcweb mailing list rtcweb@ietf.org https://www.ietf.org/mailman/listinfo/rtcweb --_000_7594FB04B1934943A5C02806D1A2204B348EB6A3ESESSMB209erics_ Content-Type: text/html; charset="windows-1256" Content-Transfer-Encoding: quoted-printable
The SDP issue= applies also to e.g. codecs: you can't mandate a codec in an SDP offer, bu= t you can do it in a specification.

Regards,

Christer

Sent from my Windows Phone
From: Eric Rescorla
Sent: =FD06= /=FD08/=FD2015 17:36
To: Asveren, Tolga
Cc: <rtcweb@ietf.org>
Subject: Re: [= rtcweb] What the gateway draft should say about mux/non-mux

I feel like people are talking past each other here.

The browser vendors (at least Chrome and Firefox) want to completely r= emove support for
non-mux from their code. If we make this change, that means that there= will be no way for a
browser to do non-mux and so as a practical matter we might as well si= mply say that
WebRTC is mux and hence for the WebRTC side of a WebRTC gateway, there= is similarly no
need to support non-mux, This only leaves the question of the non-WebR= TC side of
the gateway, but that's out of scope here. So, I'm not sure what you a= re asking for.

WRT to the issue Jonathan raises about SDP being a negotiation, that's= true, but as
a practical matter we're already far down the road of WebRTC offerers = offering SDP
which in principle the answerer might choose not to accept but if it d= oes so the
connection will fail

-Ekr

On Thu, Aug 6, 2015 at 7:12 AM, Asveren, Tolga <<= a href=3D"mailto:tasveren@sonusnet.com" target=3D"_blank">tasveren@sonusnet= .com> wrote:

I think implementers themselves can= weigh out the advantages/disadvantaged/deployment models they are targetin= g/etc=85 and decide what to support/not to support. I don=92t see any issue with this as long as there is a negotiation mechan= ism (which there is). I don=92t think the availability of negotiation is en= couraging people this or that way.

 

Thanks,

Tolga

 

From: tim panton [mailto:tim@phonefromhere.com]
Sent: Thursday, August 06, 2015 10:07 AM
To: Hutton, Andrew <andrew.hutton@unify.com>
Cc: Asveren, Tolga <tasveren@sonusnet.com>; <rtcweb@ietf.org> <rtcweb@ietf.org>


Subject: Re: [rtcweb] What the gateway draft should say about mux/no= n-mux

 

 

On 6 Aug 2015, at 08:30, Hutton, Andrew <andrew.hutton@unify.c= om> wrote:

 

+1 to what Tim said.<= /u>

 

I don=92t think this discussion is = really about gateways at all it is surely about whether WebRTC browsers hav= e to support non-mux and I don=92t really see any good reason why they need to.

 

If we had thought about this at the= time we mandated DTLS-SRTP then we would have mandated rtp-mux at the same= time but unfortunately we didn=92t but we can fix that now.

 

Sadly true, but the situation in a browser is manage= able since you might expect 10 peer connections, resulting <= /u>

in a worst case of 60 UDP ports/DTLS sessions in use=  

(assuming voice+video+data unbundled and RTC= P-non-mux vs the 10 needed). We 

also assume a relatively well endowed CPU - devoted = largely to this task.

 

On the gateway you=92d hope to have thousands of ses= sions and presumably much less CPU/memory resource per channel.

So while I think it is unfortunate that browsers can= do non-mux, it would be plain stupid to do that on a gateway. Do we <= u>

really want to encourage that ?

 

T.

 



 

Andy

 

 

From: rtcweb [mailto:rtcweb-bounces@ietf.org] On Behalf Of tim panton
Sent: 06 August 2015 13:53
To: Asveren, Tolga
Cc: <rtcweb@= ietf.org>
Subject: Re: [rtcweb] What the gateway draft should say about mux/no= n-mux

 

So we are positing the existence of a webRTC gateway= designed to support thousands of calls which does ICE and DTLS but the<= /u>

designer decided deliberately to double the number o= f ICE sessions required and double the number of DTLS sessions (and key&nbs= p;

generation costs) so that they can run RTCP (over IC= E and DTLS) on a separate port. In my estimation that=92s one poor decision=

and should not be used as the basis of this (or any)= standard. 

 

I=92d rather not support rtcp-no-mux as I see zero a= dvantages in having it. (I know theoretically it might be possible to get

a RTCP packet through a congested net on a different= port with a separate diffserv setting but that just seems so contrived).

 

Tim.

 

 

On 6 Aug 2015, at 06:44, Asveren, Tolga <tasveren@sonusnet.com> wrote:

 

These assumptions are not necessari= ly true in a universal sense (like almost any other assumption about differ= ent deployment models).

 

Furthermore, and more importantly, = there is nothing mandating WebRTC endpoints to support non-rtcp-mux. It is = a negotiated functionality. Any entity can enforce rtcp-mux as a local policy. 

 

The issue with supporting non-rtcp-= mux seems to be lack of clarity in the relevant specifications. Fixing this= =96regardless of the outcome of any other discussion- seems to be prudent IMHO.

 

Thanks,

Tolga

 

From: W= yss, Felix [mailto:Fel= ix.Wyss@inin.com] 
Sent: Thursday, August 06, 2015 6:37 AM
To: Christer Holmberg <christer.holmberg@ericsson.com<= /a>>; Asveren, Tolga <tasveren@sonusnet.com>; Schwarz, Albrecht (Albrecht) <albrecht.schwarz@alcatel-lucent.com>; Roman Shpount &l= t;roman@telurix.com<= /a>>; Rauschenbach, Uwe (Nokia - DE/Munich) <uwe.rauschenbach@nokia.com><= br> Cc: <rtcweb@ietf.org> <rtcweb@ietf.org>
Subject: Re: [rtcweb] What the gateway draft shoul= d say about mux/non-mux

 

Why shouldn't the gateway be required to = do the mux/demux?  Making the WebRTC endpoints a lot more complex just= so the legacy interop might potentially be a teeny-tiny bit easier makes no sense IMHO.  Actually, the gateway would not be a= ble to do "end-to-end" pass-through anyway as legacy equipment wi= ll either be unencrypted or use SDES (RFC#4568) for key exchange.  So = the gateway will have to perform DTLS-SRTP to SDES-SRTP transcryption--which already is way more hassle than RTP/RTCP mux/demux.

 

--Felix

 

From: rtcweb <rtcweb-bounces@ietf.org> on behalf of Chr= ister Holmberg <christer.holmberg@ericsson.com>
Sent: Thursday, August 6, 2015 05:51
To: Asveren, Tolga; Schwarz, Albrecht (Albrecht); = Roman Shpount; Rauschenbach, Uwe (Nokia - DE/Munich)
Cc: <rtcweb@ietf.org>
Subject: Re: [rtcweb] What the gateway draft shoul= d say about mux/non-mux

 

Hi,

 

No matte= r whether the gateway supports RTP/RTCP mux or not, there are cases where t= he legacy network/endpoints will not use RTP/RTCP mux, so I guess people then would want to be able to negotiate non-mux =93= end-to-end=94, rather than having the gateway to demux/mux RTP and RTCP.

 

Regards,=

 

Christer=

 

From:Asveren, Tolga [mailto:tasveren@sonusnet.com] 
Sent: 6. elokuuta 2015 12:18
To: Schwarz, Albrecht (Albrecht); Roman Shpount; R= auschenbach, Uwe (Nokia - DE/Munich)
Cc: ext Eric Rescorla; Christer Holmberg; Bernard = Aboba; <rtcweb@ietf.org>
Subject: Re: [rtcweb] What the gateway draft shoul= d say about mux/non-mux

 

Why should we consider 3GPP the sole &quo= t;owner/user" of the term/entity WebRTC-GW? I think it has a much more= general meaning and use in practice. It can refer to many different types of elements which can be deployed in many different enviro= nments, hence any attempt to define it strictly/restrict its capabilities a= re futile IMHO.

 

Thanks,

Tolga

 

From: Schwarz, Albrecht (Albrecht) <albrecht.schwarz@alcate= l-lucent.com>
Sent: Thursday, August 6, 2015 2:44 AM
To: Asveren, Tolga; Roman Shpount; Rauschenbach, U= we (Nokia - DE/Munich)
Cc: ext Eric Rescorla; Christer Holmberg; Bernard = Aboba; <rtcweb@ietf.org>
Subject: RE: [rtcweb] What the gateway draft shoul= d say about mux/non-mux

 

The concerned 3GPP WebRTC gate= way (3GPP 23.334/29.334) supports already RTP/RTCP transport multiplexing (= since 3GPP Release 12), i.e. should not be the limiting factor in this discussion. 

For ones interested in the RTC= P port allocation rules, see H.248.57:

Clause 7 describes RTP/RTCP tr= ansport multiplexing. ITU-T H.248.57 is already supported by 3GPP 29.334.

 

The rationale behind the =93op= tional tagging=94 by 23.228 is a third reason, beyond<= /p>

>1. Using different QOS settings for R= TCP vs RTP

>2. Sending RTCP to a different device= from RTP

 

Don=92t want to go in the 3GPP= specific details, but it has nothing to do with the 3GPP UE-embedded WebRT= C client nor any constraints by 3GPP WebRTC gateways.

 

Thus, a WebRTC gateway MUST su= pport RTP/RTCP transport multiplexing due to its purpose in interworking su= pport.

 

Regards,<= /p>

Albrecht<= /p>

 

 

From:Asveren, Tolga [mailto:tasveren@sonusnet.com] 
Sent: Mittwoch, 5. August 2015 19:47
To: Roman Shpount; Rauschenbach, Uwe (Nokia - DE/M= unich)
Cc: ext Eric Rescorla; Schwarz, Albrecht (Albrecht= ); Christer Holmberg; Bernard Aboba; <rtcweb@ietf.org&= gt;
Subject: RE: [rtcweb] What the gateway draft shoul= d say about mux/non-mux

 

i- I hum= bly disagree that using different QoS RTCP/RTP, e.g. different DiffServ val= ues , should be dismissed.

ii- Let = me also add another reason why no-rtcp-mux may be needed: Implementation di= fficulties in certain GWs.

 

Consider= ing that there is already a negotiation mechanism for rtcp-mux support, tha= t it can be de-facto mandated by the choice of browsers for Internet, I think what Christer/Albrecht suggested is the right way to= move forward: provide clarifications for vague points. I don=92t understan= d why lack of clarity in existing specifications should cause imposing rest= rictions. This would be akin to dropping a feature due to a bug. In this case, the =93bug=94 is lack of clarity in = normative specifications and it can be addressed by further specification.<= /span>

 

Thanks,<= /span>

Tolga

 

 

Media gateway implementat= ions according to 3GPP TS 23.228 may not support rtcp-mux, as rtcp-mux is optional there.<= /p>

So if we drop non-mux sup= port from web browsers, those media gateways that have not implemented rtcp= -mux will stop interoperating. 

 

 

First of all, do you know of any WebRTC t= o IMS gateways that do not implement rtcp-mux on the WebRTC side? I strongl= y suspect there are none.

 

Second, the only reasons not to use rtcp-= mux that I can think of are the following:

 

1. Using different QOS settings for RTCP = vs RTP

2. Sending RTCP to a different device fro= m RTP

 

I do not think the first use case warrant= s making rtcp-mux optional, since, practically no one does this.<= /u>

Second use case is also fairly marginal. = Plus it can be handled by the gateway which can send RTCP to one device and= RTP to another.

 

So, unless someone can come up with a use= case why RTP and RTCP should use different transports, I think rtcp-mux sh= ould be mandatory.

 

Regards,

______________

Roman Shpount

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

 

 


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


--_000_7594FB04B1934943A5C02806D1A2204B348EB6A3ESESSMB209erics_-- From nobody Thu Aug 6 10:15:46 2015 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 324021B3181 for ; Thu, 6 Aug 2015 10:15:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.2 X-Spam-Level: X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QQY-ETsYs09X for ; Thu, 6 Aug 2015 10:15:40 -0700 (PDT) Received: from sessmg23.ericsson.net (sessmg23.ericsson.net [193.180.251.45]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9449B1B319A for ; Thu, 6 Aug 2015 10:15:39 -0700 (PDT) X-AuditID: c1b4fb2d-f79176d00000321c-c6-55c39639a15c Received: from ESESSHC022.ericsson.se (Unknown_Domain [153.88.253.124]) by sessmg23.ericsson.net (Symantec Mail Security) with SMTP id 9B.39.12828.93693C55; Thu, 6 Aug 2015 19:15:37 +0200 (CEST) Received: from ESESSMB209.ericsson.se ([169.254.9.36]) by ESESSHC022.ericsson.se ([153.88.183.84]) with mapi id 14.03.0210.002; Thu, 6 Aug 2015 19:15:37 +0200 From: Christer Holmberg To: tim panton , "Hutton, Andrew" Thread-Topic: [rtcweb] What the gateway draft should say about mux/non-mux Thread-Index: AQHQy78thNOz8AYdMEys1nzX7WTf2J316g6A///gJYCAAAJzgIAAAVWAgAABfoCAA/DZAIAAQVMAgAL8GACAAIDGAIAAFdwAgADZaQCAACrOgIAAJh8A///v2QCAABLZAIAAEy6AgAAKf4CAAAo/gIAAVjMH Date: Thu, 6 Aug 2015 17:15:36 +0000 Message-ID: <7594FB04B1934943A5C02806D1A2204B348EB700@ESESSMB209.ericsson.se> References: <9F33F40F6F2CD847824537F3C4E37DDF1E826A00@MCHP04MSX.global-ad.net>, <7515AC50-14F3-43C4-B3D9-D785100FC9C5@phonefromhere.com> In-Reply-To: <7515AC50-14F3-43C4-B3D9-D785100FC9C5@phonefromhere.com> Accept-Language: en-US Content-Language: en-GB X-MS-Has-Attach: X-MS-TNEF-Correlator: Content-Type: multipart/alternative; boundary="_000_7594FB04B1934943A5C02806D1A2204B348EB700ESESSMB209erics_" MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFmplkeLIzCtJLcpLzFFi42KZGfG3Rtdy2uFQgxU/TC22bSi1WPuvnd3i 4vZbjA7MHkuW/GTyWDKpkc1je89jlgDmKC6blNSczLLUIn27BK6MJWdPsBSsm81cMaVnM3sD 49U3TF2MnBwSAiYS9xY8YYOwxSQu3FsPZHNxCAkcZZRYcvgRE4SziFGic3ovcxcjBwebgIVE 9z9tkAYRgRCJn539zCA2s4CmxIRlu8AGCQt4StzqXMwEUeMlse77NWYIexWjxOeXSSA2i4CK xOV9qxhBbF4BX4lHp5ezQuyaySTR9uk0C0iCU8BV4kVTI9hQRqDrvp9awwSxTFyi6ctKVoir BSSW7DnPDGGLSrx8/I8VoiZfYvfpl8wQCwQlTs58wjKBUWQWkvZZSMpmISmDiBtIfHl/G8rW lli28DUzhK0v0f3+NBOy+AJG9lWMosWpxcW56UbGeqlFmcnFxfl5enmpJZsYgfF2cMtv3R2M q187HmIU4GBU4uFdsP9QqBBrYllxZe4hRmkOFiVx3hmb80KFBNITS1KzU1MLUovii0pzUosP MTJxcEo1MC6deTP+hArD0hl3cuWYhC+eYEi7Ernhn+vfredFQ0sK/x5nWKjyS3/ltbNmZzqq ny5NMqwIdWEqfszSanh8wz6Ji/fnF6q8OpD7Z//El75/u0133xL+dyl3BdeNhgMGffekT8nG HnSX9Td64fp7/yV9MZt230kGivNZStaYmixVMkrKOL9400olluKMREMt5qLiRACpl6CYmAIA AA== Archived-At: Cc: "" Subject: Re: [rtcweb] What the gateway draft should say about mux/non-mux X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 06 Aug 2015 17:15:45 -0000 --_000_7594FB04B1934943A5C02806D1A2204B348EB700ESESSMB209erics_ Content-Type: text/plain; charset="windows-1256" Content-Transfer-Encoding: quoted-printable Hi Tim, When it comes to gateways towards legacy network, in many cases there will = only be audio, so even without bundle and/or rtcp-mux the number of ports w= on't be an issue. Regards, Christer Sent from my Windows Phone ________________________________ From: tim panton Sent: =FD06/=FD08/=FD2015 17:07 To: Hutton, Andrew Cc: Subject: Re: [rtcweb] What the gateway draft should say about mux/non-mux On 6 Aug 2015, at 08:30, Hutton, Andrew > wrote: +1 to what Tim said. I don=92t think this discussion is really about gateways at all it is surel= y about whether WebRTC browsers have to support non-mux and I don=92t reall= y see any good reason why they need to. If we had thought about this at the time we mandated DTLS-SRTP then we woul= d have mandated rtp-mux at the same time but unfortunately we didn=92t but = we can fix that now. Sadly true, but the situation in a browser is manageable since you might ex= pect 10 peer connections, resulting in a worst case of 60 UDP ports/DTLS sessions in use (assuming voice+video+data unbundled and RTCP-non-mux vs the 10 needed). We also assume a relatively well endowed CPU - devoted largely to this task. On the gateway you=92d hope to have thousands of sessions and presumably mu= ch less CPU/memory resource per channel. So while I think it is unfortunate that browsers can do non-mux, it would b= e plain stupid to do that on a gateway. Do we really want to encourage that ? T. Andy From: rtcweb [mailto:rtcweb-bounces@ietf.org] On Behalf Of tim panton Sent: 06 August 2015 13:53 To: Asveren, Tolga Cc: > Subject: Re: [rtcweb] What the gateway draft should say about mux/non-mux So we are positing the existence of a webRTC gateway designed to support th= ousands of calls which does ICE and DTLS but the designer decided deliberately to double the number of ICE sessions required= and double the number of DTLS sessions (and key generation costs) so that they can run RTCP (over ICE and DTLS) on a separa= te port. In my estimation that=92s one poor decision and should not be used as the basis of this (or any) standard. I=92d rather not support rtcp-no-mux as I see zero advantages in having it.= (I know theoretically it might be possible to get a RTCP packet through a congested net on a different port with a separate d= iffserv setting but that just seems so contrived). Tim. On 6 Aug 2015, at 06:44, Asveren, Tolga > wrote: These assumptions are not necessarily true in a universal sense (like almos= t any other assumption about different deployment models). Furthermore, and more importantly, there is nothing mandating WebRTC endpoi= nts to support non-rtcp-mux. It is a negotiated functionality. Any entity c= an enforce rtcp-mux as a local policy. The issue with supporting non-rtcp-mux seems to be lack of clarity in the r= elevant specifications. Fixing this =96regardless of the outcome of any oth= er discussion- seems to be prudent IMHO. Thanks, Tolga From: Wyss, Felix [mailto:Felix.Wyss@inin.com] Sent: Thursday, August 06, 2015 6:37 AM To: Christer Holmberg >; Asveren, Tolga >; Schwarz, Albrecht (Albrecht) >; Roman Shpount >; Rauschenbach, Uwe (Nokia - DE/Munich)= > Cc: > > Subject: Re: [rtcweb] What the gateway draft should say about mux/non-mux Why shouldn't the gateway be required to do the mux/demux? Making the WebR= TC endpoints a lot more complex just so the legacy interop might potentiall= y be a teeny-tiny bit easier makes no sense IMHO. Actually, the gateway wo= uld not be able to do "end-to-end" pass-through anyway as legacy equipment = will either be unencrypted or use SDES (RFC#4568) for key exchange. So the= gateway will have to perform DTLS-SRTP to SDES-SRTP transcryption--which a= lready is way more hassle than RTP/RTCP mux/demux. --Felix ________________________________ From: rtcweb > on b= ehalf of Christer Holmberg > Sent: Thursday, August 6, 2015 05:51 To: Asveren, Tolga; Schwarz, Albrecht (Albrecht); Roman Shpount; Rauschenba= ch, Uwe (Nokia - DE/Munich) Cc: > Subject: Re: [rtcweb] What the gateway draft should say about mux/non-mux Hi, No matter whether the gateway supports RTP/RTCP mux or not, there are cases= where the legacy network/endpoints will not use RTP/RTCP mux, so I guess p= eople then would want to be able to negotiate non-mux =93end-to-end=94, rat= her than having the gateway to demux/mux RTP and RTCP. Regards, Christer From: Asveren, Tolga [mailto:tasveren@sonusnet.com] Sent: 6. elokuuta 2015 12:18 To: Schwarz, Albrecht (Albrecht); Roman Shpount; Rauschenbach, Uwe (Nokia -= DE/Munich) Cc: ext Eric Rescorla; Christer Holmberg; Bernard Aboba; > Subject: Re: [rtcweb] What the gateway draft should say about mux/non-mux Why should we consider 3GPP the sole "owner/user" of the term/entity WebRTC= -GW? I think it has a much more general meaning and use in practice. It can= refer to many different types of elements which can be deployed in many di= fferent environments, hence any attempt to define it strictly/restrict its = capabilities are futile IMHO. Thanks, Tolga ________________________________ From: Schwarz, Albrecht (Albrecht) > Sent: Thursday, August 6, 2015 2:44 AM To: Asveren, Tolga; Roman Shpount; Rauschenbach, Uwe (Nokia - DE/Munich) Cc: ext Eric Rescorla; Christer Holmberg; Bernard Aboba; > Subject: RE: [rtcweb] What the gateway draft should say about mux/non-mux The concerned 3GPP WebRTC gateway (3GPP 23.334/29.334) supports already RTP= /RTCP transport multiplexing (since 3GPP Release 12), i.e. should not be th= e limiting factor in this discussion. For ones interested in the RTCP port allocation rules, see H.248.57: https://www.itu.int/rec/dologin_pub.asp?lang=3De&id=3DT-REC-H.248.57-201410= -I!!PDF-E&type=3Ditems Clause 7 describes RTP/RTCP transport multiplexing. ITU-T H.248.57 is alrea= dy supported by 3GPP 29.334. The rationale behind the =93optional tagging=94 by 23.228 is a third reason= , beyond >1. Using different QOS settings for RTCP vs RTP >2. Sending RTCP to a different device from RTP Don=92t want to go in the 3GPP specific details, but it has nothing to do w= ith the 3GPP UE-embedded WebRTC client nor any constraints by 3GPP WebRTC g= ateways. Thus, a WebRTC gateway MUST support RTP/RTCP transport multiplexing due to = its purpose in interworking support. Regards, Albrecht From: Asveren, Tolga [mailto:tasveren@sonusnet.com] Sent: Mittwoch, 5. August 2015 19:47 To: Roman Shpount; Rauschenbach, Uwe (Nokia - DE/Munich) Cc: ext Eric Rescorla; Schwarz, Albrecht (Albrecht); Christer Holmberg; Ber= nard Aboba; > Subject: RE: [rtcweb] What the gateway draft should say about mux/non-mux i- I humbly disagree that using different QoS RTCP/RTP, e.g. different Diff= Serv values , should be dismissed. ii- Let me also add another reason why no-rtcp-mux may be needed: Implement= ation difficulties in certain GWs. Considering that there is already a negotiation mechanism for rtcp-mux supp= ort, that it can be de-facto mandated by the choice of browsers for Interne= t, I think what Christer/Albrecht suggested is the right way to move forwar= d: provide clarifications for vague points. I don=92t understand why lack o= f clarity in existing specifications should cause imposing restrictions. Th= is would be akin to dropping a feature due to a bug. In this case, the =93b= ug=94 is lack of clarity in normative specifications and it can be addresse= d by further specification. Thanks, Tolga From: Roman Shpount [mailto:roman@telurix.com] Sent: Wednesday, August 05, 2015 12:29 PM To: Rauschenbach, Uwe (Nokia - DE/Munich) > Cc: ext Eric Rescorla >; Schwarz, Albrech= t (Albrecht) >; Asveren, Tolga >; Christer Holmberg >; Bernard Aboba >; > > Subject: Re: [rtcweb] What the gateway draft should say about mux/non-mux On Wed, Aug 5, 2015 at 4:47 AM, Rauschenbach, Uwe (Nokia - DE/Munich) > wrote: Media gateway implementations according to 3GPP TS 23.228 may not support r= tcp-mux, as rtcp-mux is optional there. So if we drop non-mux support from web browsers, those media gateways that = have not implemented rtcp-mux will stop interoperating. First of all, do you know of any WebRTC to IMS gateways that do not impleme= nt rtcp-mux on the WebRTC side? I strongly suspect there are none. Second, the only reasons not to use rtcp-mux that I can think of are the fo= llowing: 1. Using different QOS settings for RTCP vs RTP 2. Sending RTCP to a different device from RTP I do not think the first use case warrants making rtcp-mux optional, since,= practically no one does this. Second use case is also fairly marginal. Plus it can be handled by the gate= way which can send RTCP to one device and RTP to another. So, unless someone can come up with a use case why RTP and RTCP should use = different transports, I think rtcp-mux should be mandatory. Regards, ______________ Roman Shpount _______________________________________________ rtcweb mailing list rtcweb@ietf.org https://www.ietf.org/mailman/listinfo/rtcweb --_000_7594FB04B1934943A5C02806D1A2204B348EB700ESESSMB209erics_ Content-Type: text/html; charset="windows-1256" Content-Transfer-Encoding: quoted-printable
Hi Tim,

When it comes to gateways towards legacy network, in many cases there will = only be audio, so even without bundle and/or rtcp-mux the number of ports w= on't be an issue.

Regards,

Christer

Sent from my Windows Phone
From: tim panton
Sent: =FD06= /=FD08/=FD2015 17:07
To: Hutton, Andrew
Cc: <rtcweb@ietf.org>
Subject: Re: [= rtcweb] What the gateway draft should say about mux/non-mux


On 6 Aug 2015, at 08:30, Hutton, Andrew <andrew.hutton@unify.com> wrot= e:

+1 to wh= at Tim said.

 

I don=92t th= ink this discussion is really about gateways at all it is surely about whet= her WebRTC browsers have to support non-mux and I don=92t really see any good reason why they need to.

 

If we had th= ought about this at the time we mandated DTLS-SRTP then we would have manda= ted rtp-mux at the same time but unfortunately we didn=92t but we can fix that now.


Sadly true, but the situation in a browser is manageable since you mig= ht expect 10 peer connections, resulting 
in a worst case of 60 UDP ports/DTLS sessions in use 
(assuming voice+video+data unbundled and RTCP-non-mux vs the 1= 0 needed). We 
also assume a relatively well endowed CPU - devoted largely to this ta= sk.

On the gateway you=92d hope to have thousands of sessions and presumab= ly much less CPU/memory resource per channel.
So while I think it is unfortunate that browsers can do non-mux, it wo= uld be plain stupid to do that on a gateway. Do we 
really want to encourage that ?

T.


 

Andy<= /p>

 

 

From: rtcweb [mailto:rtcweb-bounces@ietf.org] On Behalf Of tim panton
Sent: 06 August 2015 13:53
To: Asveren, Tolga
Cc: <rtc= web@ietf.org>
Subject: Re: [rtcweb] What the gateway draft should say a= bout mux/non-mux

 

So we are positing the existence of a webRTC gateway= designed to support thousands of calls which does ICE and DTLS but the

designer decided deliberately to double the number o= f ICE sessions required and double the number of DTLS sessions (and key&nbs= p;

generation costs) so that they can run RTCP (over IC= E and DTLS) on a separate port. In my estimation that=92s one poor decision=

and should not be used as the basis of this (or any)= standard. 

 

I=92d rather not support rtcp-no-mux as I see zero a= dvantages in having it. (I know theoretically it might be possible to get

a RTCP packet through a congested net on a different= port with a separate diffserv setting but that just seems so contrived).

 

Tim.

 

 

On 6 Aug 2015, at 06:44, Asveren, Tolga <tasveren@sonusnet.com> = wrote:

 

These assump= tions are not necessarily true in a universal sense (like almost any other = assumption about different deployment models).

 

Furthermore,= and more importantly, there is nothing mandating WebRTC endpoints to suppo= rt non-rtcp-mux. It is a negotiated functionality. Any entity can enforce rtcp-mux as a local policy. 

 

The issue wi= th supporting non-rtcp-mux seems to be lack of clarity in the relevant spec= ifications. Fixing this =96regardless of the outcome of any other discussion- seems to be prudent IMHO.

 

Thanks,

Tolga=

 

From:<= /b> Wyss, Felix [mailto:Felix.Wyss= @inin.com] 
Sent: T= hursday, August 06, 2015 6:37 AM
To: Chr= ister Holmberg <christer.holmberg@ericsson.com>; Asveren, Tolga <tasveren@sonusnet.com>; Schwarz, Albrecht (Albrecht) <albrecht.schwarz@alcatel-lucent.com>; Roman= Shpount <roman@telurix.= com>; Rauschenbach, Uwe (Nokia - DE/Munich) <uwe.rauschenbach@nokia.com>
Cc: <= ;rtcweb@ietf.org> <= rtcweb@ietf.org>
Subject: Re: [rtcweb] What the gateway draft should say about mux/non-mux

 

Why shouldn't the = gateway be required to do the mux/demux?  Making the WebRTC endpoints = a lot more complex just so the legacy interop might potentially be a teeny-tiny bit easier makes no sense IMHO.  Actually, the gateway w= ould not be able to do "end-to-end" pass-through anyway as legacy= equipment will either be unencrypted or use SDES (RFC#4568) for key exchan= ge.  So the gateway will have to perform DTLS-SRTP to SDES-SRTP transcryption--which already is way more hassle than RTP/RTCP= mux/demux.

 

--Felix

 

From: rtcweb <rtcweb-bounces@ietf.org> on behalf of= Christer Holmberg <christer.holmberg@ericsson= .com>
Sent: T= hursday, August 6, 2015 05:51
To: Asv= eren, Tolga; Schwarz, Albrecht (Albrecht); Roman Shpount; Rauschenbach, Uwe= (Nokia - DE/Munich)
Cc: <= ;rtcweb@ietf.org>
Subject: Re: [rtcweb] What the gateway draft should say about mux/non-mux

 

Hi,

 

No matter whether the gateway supports RTP/RTCP mux or not, = there are cases where the legacy network/endpoints will not use RTP/RTCP mux, so I guess people then would want to be able to negotiat= e non-mux =93end-to-end=94, rather than having the gateway to demux/mux RTP= and RTCP.

 

Regards,

 

Christer

 

From: Asveren, Tolga [mailto:tasveren@sonusnet.com] 
Sent: 6= . elokuuta 2015 12:18
To: Sch= warz, Albrecht (Albrecht); Roman Shpount; Rauschenbach, Uwe (Nokia - DE/Mun= ich)
Cc: ext= Eric Rescorla; Christer Holmberg; Bernard Aboba; <rtcweb@iet= f.org>
Subject: Re: [rtcweb] What the gateway draft should say about mux/non-mux

 

Why should we cons= ider 3GPP the sole "owner/user" of the term/entity WebRTC-GW? I t= hink it has a much more general meaning and use in practice. It can refer to many different types of elements which can be deployed in many differen= t environments, hence any attempt to define it strictly/restrict its capabi= lities are futile IMHO.

 

Thanks,

Tolga

 

From: Schwarz, Albrecht (Albrecht) <albrecht.schwarz@al= catel-lucent.com>
Sent: T= hursday, August 6, 2015 2:44 AM
To: Asv= eren, Tolga; Roman Shpount; Rauschenbach, Uwe (Nokia - DE/Munich)
Cc: ext= Eric Rescorla; Christer Holmberg; Bernard Aboba; <rtcweb@iet= f.org>
Subject: RE: [rtcweb] What the gateway draft should say about mux/non-mux

 

The concerned 3GPP = WebRTC gateway (3GPP 23.334/29.334) supports already RTP/RTCP transport mul= tiplexing (since 3GPP Release 12), i.e. should not be the limiting factor in this discussion. 

For ones interested= in the RTCP port allocation rules, see H.248.57:

https://www.itu.int/rec/d= ologin_pub.asp?lang=3De&id=3DT-REC-H.248.57-201410-I!!PDF-E&type=3D= items

Clause 7 describes = RTP/RTCP transport multiplexing. ITU-T H.248.57 is already supported by 3GP= P 29.334.

 

The rationale behin= d the =93optional tagging=94 by 23.228 is a third reason, beyond

>1. Using diffe= rent QOS settings for RTCP vs RTP

>2. Sending RTC= P to a different device from RTP

 

Don=92t want to go = in the 3GPP specific details, but it has nothing to do with the 3GPP UE-emb= edded WebRTC client nor any constraints by 3GPP WebRTC gateways.

 

Thus, a WebRTC gate= way MUST support RTP/RTCP transport multiplexing due to its purpose in inte= rworking support.

 

Regards,

Albrecht

 

 

From: Asveren, Tolga [mailto:tasveren@sonusnet.com] 
Sent: M= ittwoch, 5. August 2015 19:47
To: Rom= an Shpount; Rauschenbach, Uwe (Nokia - DE/Munich)
Cc: ext= Eric Rescorla; Schwarz, Albrecht (Albrecht); Christer Holmberg; Bernard Ab= oba; <rtcweb@ietf.org>
Subject: RE: [rtcweb] What the gateway draft should say about mux/non-mux

 

i- I humbly disagree that using different QoS RTCP/RTP, e.g.= different DiffServ values , should be dismissed.

ii- Let me also add another reason why no-rtcp-mux may be ne= eded: Implementation difficulties in certain GWs.

 

Considering that there is already a negotiation mechanism fo= r rtcp-mux support, that it can be de-facto mandated by the choice of browsers for Internet, I think what Christer/Albrecht suggested = is the right way to move forward: provide clarifications for vague points. = I don=92t understand why lack of clarity in existing specifications should = cause imposing restrictions. This would be akin to dropping a feature due to a bug. In this case, the =93bug= =94 is lack of clarity in normative specifications and it can be addressed = by further specification.

 

Thanks,

Tolga

 

From: Roman Shpount [mailto:roman@telurix.com] 
Sent: W= ednesday, August 05, 2015 12:29 PM
To: Rau= schenbach, Uwe (Nokia - DE/Munich) <uwe.rauschenba= ch@nokia.com>
Cc: ext= Eric Rescorla <ekr@rtfm.com>; Schwarz, Albrecht= (Albrecht) <albrecht.schwarz@alcatel-luc= ent.com>; Asveren, Tolga <tasveren@sonusnet.com>; = Christer Holmberg <christer.holmberg@ericsson.= com>; Bernard Aboba <bernard.aboba@gmail.com>= ;; <rtcweb@ietf.org> <rtcweb@ietf= .org>
Subject: Re: [rtcweb] What the gateway draft should say about mux/non-mux

 

On Wed, Aug 5, 201= 5 at 4:47 AM, Rauschenbach, Uwe (Nokia - DE/Munich) <uwe.rauschenbach@nokia.com> wrote:

Me= dia gateway implementations according to 3GPP TS 23.228 may not support rtcp-mux, as rtcp-mux is optional there.

So= if we drop non-mux support from web browsers, those media gateways that ha= ve not implemented rtcp-mux will stop interoperating. 

 

 

First of all, do y= ou know of any WebRTC to IMS gateways that do not implement rtcp-mux on the= WebRTC side? I strongly suspect there are none.

 

Second, the only r= easons not to use rtcp-mux that I can think of are the following:

 

1. Using different= QOS settings for RTCP vs RTP

2. Sending RTCP to= a different device from RTP

 

I do not think the= first use case warrants making rtcp-mux optional, since, practically no on= e does this.

Second use case is= also fairly marginal. Plus it can be handled by the gateway which can send= RTCP to one device and RTP to another.

 

So, unless someone= can come up with a use case why RTP and RTCP should use different transpor= ts, I think rtcp-mux should be mandatory.

 

Regards,

______________

Roman Shpount

__________________________= _____________________
rtcweb mailing list
rtcweb@ietf.org
https:/= /www.ietf.org/mailman/listinfo/rtcweb

 


--_000_7594FB04B1934943A5C02806D1A2204B348EB700ESESSMB209erics_-- From nobody Thu Aug 6 10:36:23 2015 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 62CB41A86F6 for ; Thu, 6 Aug 2015 10:36:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.266 X-Spam-Level: X-Spam-Status: No, score=-2.266 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, IP_NOT_FRIENDLY=0.334, 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 rCKM5X3ccNHL for ; Thu, 6 Aug 2015 10:36:15 -0700 (PDT) Received: from mx0b-00198e01.pphosted.com (mx0b-00198e01.pphosted.com [67.231.157.197]) (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 C7DCD1B31C4 for ; Thu, 6 Aug 2015 10:36:02 -0700 (PDT) Received: from pps.filterd (m0073110.ppops.net [127.0.0.1]) by mx0b-00198e01.pphosted.com (8.15.0.59/8.14.7) with SMTP id t76Ha2ph032188; Thu, 6 Aug 2015 13:36:02 -0400 Received: from mail.vidyo.com ([162.209.16.214]) by mx0b-00198e01.pphosted.com with ESMTP id 1w0h0uttv5-1 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Thu, 06 Aug 2015 13:36:01 -0400 Received: from 492132-EXCH1.vidyo.com ([fe80::50:56ff:fe85:4f77]) by 492133-EXCH2.vidyo.com ([fe80::50:56ff:fe85:6b62%13]) with mapi id 14.03.0195.001; Thu, 6 Aug 2015 12:35:58 -0500 From: Jonathan Lennox To: Eric Rescorla Thread-Topic: [rtcweb] What the gateway draft should say about mux/non-mux Thread-Index: AQHQ0FUy6xP9QkYtW0impOxEEP9+l53/j9SA Date: Thu, 6 Aug 2015 17:35:58 +0000 Message-ID: References: <9F33F40F6F2CD847824537F3C4E37DDF1E826A00@MCHP04MSX.global-ad.net> <7515AC50-14F3-43C4-B3D9-D785100FC9C5@phonefromhere.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [198.200.77.253] Content-Type: multipart/alternative; boundary="_000_A85FE9071A214F5FB671922FAF68DA1Cvidyocom_" MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:5.14.151, 1.0.33, 0.0.0000 definitions=2015-08-06_10:2015-08-06,2015-08-06,1970-01-01 signatures=0 X-Proofpoint-Spam-Details: rule=outbound_notspam policy=outbound score=0 spamscore=0 suspectscore=0 phishscore=0 adultscore=0 bulkscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=7.0.1-1506180000 definitions=main-1508060278 Archived-At: Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] What the gateway draft should say about mux/non-mux X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 06 Aug 2015 17:36:20 -0000 --_000_A85FE9071A214F5FB671922FAF68DA1Cvidyocom_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 DQpPbiBBdWcgNiwgMjAxNSwgYXQgMTA6MzUgQU0sIEVyaWMgUmVzY29ybGEgPGVrckBydGZtLmNv bTxtYWlsdG86ZWtyQHJ0Zm0uY29tPj4gd3JvdGU6DQoNCldSVCB0byB0aGUgaXNzdWUgSm9uYXRo YW4gcmFpc2VzIGFib3V0IFNEUCBiZWluZyBhIG5lZ290aWF0aW9uLCB0aGF0J3MgdHJ1ZSwgYnV0 IGFzDQphIHByYWN0aWNhbCBtYXR0ZXIgd2UncmUgYWxyZWFkeSBmYXIgZG93biB0aGUgcm9hZCBv ZiBXZWJSVEMgb2ZmZXJlcnMgb2ZmZXJpbmcgU0RQDQp3aGljaCBpbiBwcmluY2lwbGUgdGhlIGFu c3dlcmVyIG1pZ2h0IGNob29zZSBub3QgdG8gYWNjZXB0IGJ1dCBpZiBpdCBkb2VzIHNvIHRoZQ0K Y29ubmVjdGlvbiB3aWxsIGZhaWwNCg0KSeKAmW0gbm90IHN1cmUgd2hhdCB5b3UgbWVhbiBoZXJl IOKAlCB3aGF0IGFyZSB0aGUgc2NlbmFyaW9zIHdoZXJlIHlvdSBjYW7igJl0IHRha2UgYSBXZWJS VEMgb2ZmZXIsIHB1dCBpdCBpbiBhIFNJUCBJTlZJVEUsIGFuZCBhbnkgc3RhbmRhcmRzLWNvbXBs aWFudCAzMjY0IGFuc3dlciB0byB0aGUgbWVzc2FnZSBpc27igJl0IGFsbG93ZWQgZm9yIFdlYlJU Qz8NCg0KVGhlIG9ubHkgb25lIEkgY2FuIHRoaW5rIG9mIGN1cnJlbnRseSBpcyB0aGUgYW5zd2Vy ZXIgZGVjbGluaW5nIHRvIGRvIElDRSDigJQgc28gdGhhdCBoeXBvdGhldGljYWwgU0lQIElOVklU RSB3b3VsZCBoYXZlIHRvIGhhdmUg4oCcUmVxdWlyZTogaWNl4oCdIChSRkMgNTc2OCkgaW4gaXQu DQoNCklmIHlvdSB3YW50IHRvIHNheSB0aGF0IFdlYlJUQyBicm93c2VycyBNVVNUIE5PVCBzdXBw b3J0IG5vbi1SVENQLW11eCwgdGhhdOKAmXMgZmluZSAoYW5kIHdvdWxkIG1lYW4gaW1wbGljaXRs eSBkZWZpbmluZyDigJxSZXF1aXJlOiBydGNwLW11eOKAnSkuICBCdXQgaWYgeW91IHdhbnQgdG8g c2F5IHRoYXQgYnJvd3NlcnMgTUFZIHN1cHBvcnQgbm9uLXJ0Y3AtbXV4LCB0aGVyZSBuZWVkcyB0 byBiZSBzb21lIHdheSBmb3IgYXBwbGljYXRpb25zIHRvIGRpc2NvdmVyIHdoZXRoZXIgdGhlIGJy b3dzZXIgZG9lcyBpbmRlZWQgc3VwcG9ydCBpdCwgb3IgZWxzZSB0aGVyZeKAmXMgbm8gcG9pbnQu IEFuZCBJIGJlbGlldmUgdGhhdCBTRFAgZG9lc27igJl0IGN1cnJlbnRseSBoYXZlIGFueSBleHBs aWNpdCBzeW50YXggZm9yIHRoaXMsIGFuZCB0aGUgbmF0dXJlIG9mIFNEUCBtZWFucyBpdOKAmXMg c29tZXdoYXQgaGFyZCB0byBkZWZpbmUuDQoNCkZvciBpbXBsaWNpdCBzeW50YXgsIEkgZ3Vlc3Mg dGhlIGFwcGxpY2F0aW9uIGNvdWxkIGNoZWNrIHdoZXRoZXIgUlRDUCBtdXggaXMgc3VwcG9ydGVk IGJ5IGNoZWNraW5nIHdoZXRoZXIgdGhlIG9mZmVyIGNvbnRhaW5zIGFueSBJQ0UgY2FuZGlkYXRl cyBmb3IgY29tcG9uZW50IDIuICBCdXQgdGhpcyB0aWVzIElDRSBhbmQgUlRDUC1tdXggdG9nZXRo ZXIgaW4gSU1PIGFuIHVuZm9ydHVuYXRlIHdheS4NCg0KDQotRWtyDQoNCk9uIFRodSwgQXVnIDYs IDIwMTUgYXQgNzoxMiBBTSwgQXN2ZXJlbiwgVG9sZ2EgPHRhc3ZlcmVuQHNvbnVzbmV0LmNvbTxt YWlsdG86dGFzdmVyZW5Ac29udXNuZXQuY29tPj4gd3JvdGU6DQpJIHRoaW5rIGltcGxlbWVudGVy cyB0aGVtc2VsdmVzIGNhbiB3ZWlnaCBvdXQgdGhlIGFkdmFudGFnZXMvZGlzYWR2YW50YWdlZC9k ZXBsb3ltZW50IG1vZGVscyB0aGV5IGFyZSB0YXJnZXRpbmcvZXRj4oCmIGFuZCBkZWNpZGUgd2hh dCB0byBzdXBwb3J0L25vdCB0byBzdXBwb3J0LiBJIGRvbuKAmXQgc2VlIGFueSBpc3N1ZSB3aXRo IHRoaXMgYXMgbG9uZyBhcyB0aGVyZSBpcyBhIG5lZ290aWF0aW9uIG1lY2hhbmlzbSAod2hpY2gg dGhlcmUgaXMpLiBJIGRvbuKAmXQgdGhpbmsgdGhlIGF2YWlsYWJpbGl0eSBvZiBuZWdvdGlhdGlv biBpcyBlbmNvdXJhZ2luZyBwZW9wbGUgdGhpcyBvciB0aGF0IHdheS4NCg0KVGhhbmtzLA0KVG9s Z2ENCg0KRnJvbTogdGltIHBhbnRvbiBbbWFpbHRvOnRpbUBwaG9uZWZyb21oZXJlLmNvbTxtYWls dG86dGltQHBob25lZnJvbWhlcmUuY29tPl0NClNlbnQ6IFRodXJzZGF5LCBBdWd1c3QgMDYsIDIw MTUgMTA6MDcgQU0NClRvOiBIdXR0b24sIEFuZHJldyA8YW5kcmV3Lmh1dHRvbkB1bmlmeS5jb208 bWFpbHRvOmFuZHJldy5odXR0b25AdW5pZnkuY29tPj4NCkNjOiBBc3ZlcmVuLCBUb2xnYSA8dGFz dmVyZW5Ac29udXNuZXQuY29tPG1haWx0bzp0YXN2ZXJlbkBzb251c25ldC5jb20+PjsgPHJ0Y3dl YkBpZXRmLm9yZzxtYWlsdG86cnRjd2ViQGlldGYub3JnPj4gPHJ0Y3dlYkBpZXRmLm9yZzxtYWls dG86cnRjd2ViQGlldGYub3JnPj4NCg0KU3ViamVjdDogUmU6IFtydGN3ZWJdIFdoYXQgdGhlIGdh dGV3YXkgZHJhZnQgc2hvdWxkIHNheSBhYm91dCBtdXgvbm9uLW11eA0KDQoNCg0KT24gNiBBdWcg MjAxNSwgYXQgMDg6MzAsIEh1dHRvbiwgQW5kcmV3IDxhbmRyZXcuaHV0dG9uQHVuaWZ5LmNvbTxt YWlsdG86YW5kcmV3Lmh1dHRvbkB1bmlmeS5jb20+PiB3cm90ZToNCg0KKzEgdG8gd2hhdCBUaW0g c2FpZC4NCg0KSSBkb27igJl0IHRoaW5rIHRoaXMgZGlzY3Vzc2lvbiBpcyByZWFsbHkgYWJvdXQg Z2F0ZXdheXMgYXQgYWxsIGl0IGlzIHN1cmVseSBhYm91dCB3aGV0aGVyIFdlYlJUQyBicm93c2Vy cyBoYXZlIHRvIHN1cHBvcnQgbm9uLW11eCBhbmQgSSBkb27igJl0IHJlYWxseSBzZWUgYW55IGdv b2QgcmVhc29uIHdoeSB0aGV5IG5lZWQgdG8uDQoNCklmIHdlIGhhZCB0aG91Z2h0IGFib3V0IHRo aXMgYXQgdGhlIHRpbWUgd2UgbWFuZGF0ZWQgRFRMUy1TUlRQIHRoZW4gd2Ugd291bGQgaGF2ZSBt YW5kYXRlZCBydHAtbXV4IGF0IHRoZSBzYW1lIHRpbWUgYnV0IHVuZm9ydHVuYXRlbHkgd2UgZGlk buKAmXQgYnV0IHdlIGNhbiBmaXggdGhhdCBub3cuDQoNClNhZGx5IHRydWUsIGJ1dCB0aGUgc2l0 dWF0aW9uIGluIGEgYnJvd3NlciBpcyBtYW5hZ2VhYmxlIHNpbmNlIHlvdSBtaWdodCBleHBlY3Qg MTAgcGVlciBjb25uZWN0aW9ucywgcmVzdWx0aW5nDQppbiBhIHdvcnN0IGNhc2Ugb2YgNjAgVURQ IHBvcnRzL0RUTFMgc2Vzc2lvbnMgaW4gdXNlDQooYXNzdW1pbmcgdm9pY2UrdmlkZW8rZGF0YSB1 bmJ1bmRsZWQgYW5kIFJUQ1Atbm9uLW11eCB2cyB0aGUgMTAgbmVlZGVkKS4gV2UNCmFsc28gYXNz dW1lIGEgcmVsYXRpdmVseSB3ZWxsIGVuZG93ZWQgQ1BVIC0gZGV2b3RlZCBsYXJnZWx5IHRvIHRo aXMgdGFzay4NCg0KT24gdGhlIGdhdGV3YXkgeW914oCZZCBob3BlIHRvIGhhdmUgdGhvdXNhbmRz IG9mIHNlc3Npb25zIGFuZCBwcmVzdW1hYmx5IG11Y2ggbGVzcyBDUFUvbWVtb3J5IHJlc291cmNl IHBlciBjaGFubmVsLg0KU28gd2hpbGUgSSB0aGluayBpdCBpcyB1bmZvcnR1bmF0ZSB0aGF0IGJy b3dzZXJzIGNhbiBkbyBub24tbXV4LCBpdCB3b3VsZCBiZSBwbGFpbiBzdHVwaWQgdG8gZG8gdGhh dCBvbiBhIGdhdGV3YXkuIERvIHdlDQpyZWFsbHkgd2FudCB0byBlbmNvdXJhZ2UgdGhhdCA/DQoN ClQuDQoNCg0KDQoNCkFuZHkNCg0KDQpGcm9tOiBydGN3ZWIgW21haWx0bzpydGN3ZWItYm91bmNl c0BpZXRmLm9yZ10gT24gQmVoYWxmIE9mIHRpbSBwYW50b24NClNlbnQ6IDA2IEF1Z3VzdCAyMDE1 IDEzOjUzDQpUbzogQXN2ZXJlbiwgVG9sZ2ENCkNjOiA8cnRjd2ViQGlldGYub3JnPG1haWx0bzpy dGN3ZWJAaWV0Zi5vcmc+Pg0KU3ViamVjdDogUmU6IFtydGN3ZWJdIFdoYXQgdGhlIGdhdGV3YXkg ZHJhZnQgc2hvdWxkIHNheSBhYm91dCBtdXgvbm9uLW11eA0KDQpTbyB3ZSBhcmUgcG9zaXRpbmcg dGhlIGV4aXN0ZW5jZSBvZiBhIHdlYlJUQyBnYXRld2F5IGRlc2lnbmVkIHRvIHN1cHBvcnQgdGhv dXNhbmRzIG9mIGNhbGxzIHdoaWNoIGRvZXMgSUNFIGFuZCBEVExTIGJ1dCB0aGUNCmRlc2lnbmVy IGRlY2lkZWQgZGVsaWJlcmF0ZWx5IHRvIGRvdWJsZSB0aGUgbnVtYmVyIG9mIElDRSBzZXNzaW9u cyByZXF1aXJlZCBhbmQgZG91YmxlIHRoZSBudW1iZXIgb2YgRFRMUyBzZXNzaW9ucyAoYW5kIGtl eQ0KZ2VuZXJhdGlvbiBjb3N0cykgc28gdGhhdCB0aGV5IGNhbiBydW4gUlRDUCAob3ZlciBJQ0Ug YW5kIERUTFMpIG9uIGEgc2VwYXJhdGUgcG9ydC4gSW4gbXkgZXN0aW1hdGlvbiB0aGF04oCZcyBv bmUgcG9vciBkZWNpc2lvbg0KYW5kIHNob3VsZCBub3QgYmUgdXNlZCBhcyB0aGUgYmFzaXMgb2Yg dGhpcyAob3IgYW55KSBzdGFuZGFyZC4NCg0KSeKAmWQgcmF0aGVyIG5vdCBzdXBwb3J0IHJ0Y3At bm8tbXV4IGFzIEkgc2VlIHplcm8gYWR2YW50YWdlcyBpbiBoYXZpbmcgaXQuIChJIGtub3cgdGhl b3JldGljYWxseSBpdCBtaWdodCBiZSBwb3NzaWJsZSB0byBnZXQNCmEgUlRDUCBwYWNrZXQgdGhy b3VnaCBhIGNvbmdlc3RlZCBuZXQgb24gYSBkaWZmZXJlbnQgcG9ydCB3aXRoIGEgc2VwYXJhdGUg ZGlmZnNlcnYgc2V0dGluZyBidXQgdGhhdCBqdXN0IHNlZW1zIHNvIGNvbnRyaXZlZCkuDQoNClRp bS4NCg0KDQpPbiA2IEF1ZyAyMDE1LCBhdCAwNjo0NCwgQXN2ZXJlbiwgVG9sZ2EgPHRhc3ZlcmVu QHNvbnVzbmV0LmNvbTxtYWlsdG86dGFzdmVyZW5Ac29udXNuZXQuY29tPj4gd3JvdGU6DQoNClRo ZXNlIGFzc3VtcHRpb25zIGFyZSBub3QgbmVjZXNzYXJpbHkgdHJ1ZSBpbiBhIHVuaXZlcnNhbCBz ZW5zZSAobGlrZSBhbG1vc3QgYW55IG90aGVyIGFzc3VtcHRpb24gYWJvdXQgZGlmZmVyZW50IGRl cGxveW1lbnQgbW9kZWxzKS4NCg0KRnVydGhlcm1vcmUsIGFuZCBtb3JlIGltcG9ydGFudGx5LCB0 aGVyZSBpcyBub3RoaW5nIG1hbmRhdGluZyBXZWJSVEMgZW5kcG9pbnRzIHRvIHN1cHBvcnQgbm9u LXJ0Y3AtbXV4LiBJdCBpcyBhIG5lZ290aWF0ZWQgZnVuY3Rpb25hbGl0eS4gQW55IGVudGl0eSBj YW4gZW5mb3JjZSBydGNwLW11eCBhcyBhIGxvY2FsIHBvbGljeS4NCg0KVGhlIGlzc3VlIHdpdGgg c3VwcG9ydGluZyBub24tcnRjcC1tdXggc2VlbXMgdG8gYmUgbGFjayBvZiBjbGFyaXR5IGluIHRo ZSByZWxldmFudCBzcGVjaWZpY2F0aW9ucy4gRml4aW5nIHRoaXMg4oCTcmVnYXJkbGVzcyBvZiB0 aGUgb3V0Y29tZSBvZiBhbnkgb3RoZXIgZGlzY3Vzc2lvbi0gc2VlbXMgdG8gYmUgcHJ1ZGVudCBJ TUhPLg0KDQpUaGFua3MsDQpUb2xnYQ0KDQpGcm9tOiBXeXNzLCBGZWxpeCBbbWFpbHRvOkZlbGl4 Lld5c3NAaW5pbi5jb21dDQpTZW50OiBUaHVyc2RheSwgQXVndXN0IDA2LCAyMDE1IDY6MzcgQU0N ClRvOiBDaHJpc3RlciBIb2xtYmVyZyA8Y2hyaXN0ZXIuaG9sbWJlcmdAZXJpY3Nzb24uY29tPG1h aWx0bzpjaHJpc3Rlci5ob2xtYmVyZ0Blcmljc3Nvbi5jb20+PjsgQXN2ZXJlbiwgVG9sZ2EgPHRh c3ZlcmVuQHNvbnVzbmV0LmNvbTxtYWlsdG86dGFzdmVyZW5Ac29udXNuZXQuY29tPj47IFNjaHdh cnosIEFsYnJlY2h0IChBbGJyZWNodCkgPGFsYnJlY2h0LnNjaHdhcnpAYWxjYXRlbC1sdWNlbnQu Y29tPG1haWx0bzphbGJyZWNodC5zY2h3YXJ6QGFsY2F0ZWwtbHVjZW50LmNvbT4+OyBSb21hbiBT aHBvdW50IDxyb21hbkB0ZWx1cml4LmNvbTxtYWlsdG86cm9tYW5AdGVsdXJpeC5jb20+PjsgUmF1 c2NoZW5iYWNoLCBVd2UgKE5va2lhIC0gREUvTXVuaWNoKSA8dXdlLnJhdXNjaGVuYmFjaEBub2tp YS5jb208bWFpbHRvOnV3ZS5yYXVzY2hlbmJhY2hAbm9raWEuY29tPj4NCkNjOiA8cnRjd2ViQGll dGYub3JnPG1haWx0bzpydGN3ZWJAaWV0Zi5vcmc+PiA8cnRjd2ViQGlldGYub3JnPG1haWx0bzpy dGN3ZWJAaWV0Zi5vcmc+Pg0KU3ViamVjdDogUmU6IFtydGN3ZWJdIFdoYXQgdGhlIGdhdGV3YXkg ZHJhZnQgc2hvdWxkIHNheSBhYm91dCBtdXgvbm9uLW11eA0KDQpXaHkgc2hvdWxkbid0IHRoZSBn YXRld2F5IGJlIHJlcXVpcmVkIHRvIGRvIHRoZSBtdXgvZGVtdXg/ICBNYWtpbmcgdGhlIFdlYlJU QyBlbmRwb2ludHMgYSBsb3QgbW9yZSBjb21wbGV4IGp1c3Qgc28gdGhlIGxlZ2FjeSBpbnRlcm9w IG1pZ2h0IHBvdGVudGlhbGx5IGJlIGEgdGVlbnktdGlueSBiaXQgZWFzaWVyIG1ha2VzIG5vIHNl bnNlIElNSE8uICBBY3R1YWxseSwgdGhlIGdhdGV3YXkgd291bGQgbm90IGJlIGFibGUgdG8gZG8g ImVuZC10by1lbmQiIHBhc3MtdGhyb3VnaCBhbnl3YXkgYXMgbGVnYWN5IGVxdWlwbWVudCB3aWxs IGVpdGhlciBiZSB1bmVuY3J5cHRlZCBvciB1c2UgU0RFUyAoUkZDIzQ1NjgpIGZvciBrZXkgZXhj aGFuZ2UuICBTbyB0aGUgZ2F0ZXdheSB3aWxsIGhhdmUgdG8gcGVyZm9ybSBEVExTLVNSVFAgdG8g U0RFUy1TUlRQIHRyYW5zY3J5cHRpb24tLXdoaWNoIGFscmVhZHkgaXMgd2F5IG1vcmUgaGFzc2xl IHRoYW4gUlRQL1JUQ1AgbXV4L2RlbXV4Lg0KDQotLUZlbGl4DQoNCl9fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fDQpGcm9tOiBydGN3ZWIgPHJ0Y3dlYi1ib3VuY2VzQGlldGYub3JnPG1h aWx0bzpydGN3ZWItYm91bmNlc0BpZXRmLm9yZz4+IG9uIGJlaGFsZiBvZiBDaHJpc3RlciBIb2xt YmVyZyA8Y2hyaXN0ZXIuaG9sbWJlcmdAZXJpY3Nzb24uY29tPG1haWx0bzpjaHJpc3Rlci5ob2xt YmVyZ0Blcmljc3Nvbi5jb20+Pg0KU2VudDogVGh1cnNkYXksIEF1Z3VzdCA2LCAyMDE1IDA1OjUx DQpUbzogQXN2ZXJlbiwgVG9sZ2E7IFNjaHdhcnosIEFsYnJlY2h0IChBbGJyZWNodCk7IFJvbWFu IFNocG91bnQ7IFJhdXNjaGVuYmFjaCwgVXdlIChOb2tpYSAtIERFL011bmljaCkNCkNjOiA8cnRj d2ViQGlldGYub3JnPG1haWx0bzpydGN3ZWJAaWV0Zi5vcmc+Pg0KU3ViamVjdDogUmU6IFtydGN3 ZWJdIFdoYXQgdGhlIGdhdGV3YXkgZHJhZnQgc2hvdWxkIHNheSBhYm91dCBtdXgvbm9uLW11eA0K DQpIaSwNCg0KTm8gbWF0dGVyIHdoZXRoZXIgdGhlIGdhdGV3YXkgc3VwcG9ydHMgUlRQL1JUQ1Ag bXV4IG9yIG5vdCwgdGhlcmUgYXJlIGNhc2VzIHdoZXJlIHRoZSBsZWdhY3kgbmV0d29yay9lbmRw b2ludHMgd2lsbCBub3QgdXNlIFJUUC9SVENQIG11eCwgc28gSSBndWVzcyBwZW9wbGUgdGhlbiB3 b3VsZCB3YW50IHRvIGJlIGFibGUgdG8gbmVnb3RpYXRlIG5vbi1tdXgg4oCcZW5kLXRvLWVuZOKA nSwgcmF0aGVyIHRoYW4gaGF2aW5nIHRoZSBnYXRld2F5IHRvIGRlbXV4L211eCBSVFAgYW5kIFJU Q1AuDQoNClJlZ2FyZHMsDQoNCkNocmlzdGVyDQoNCkZyb206IEFzdmVyZW4sIFRvbGdhIFttYWls dG86dGFzdmVyZW5Ac29udXNuZXQuY29tXQ0KU2VudDogNi4gZWxva3V1dGEgMjAxNSAxMjoxOA0K VG86IFNjaHdhcnosIEFsYnJlY2h0IChBbGJyZWNodCk7IFJvbWFuIFNocG91bnQ7IFJhdXNjaGVu YmFjaCwgVXdlIChOb2tpYSAtIERFL011bmljaCkNCkNjOiBleHQgRXJpYyBSZXNjb3JsYTsgQ2hy aXN0ZXIgSG9sbWJlcmc7IEJlcm5hcmQgQWJvYmE7IDxydGN3ZWJAaWV0Zi5vcmc8bWFpbHRvOnJ0 Y3dlYkBpZXRmLm9yZz4+DQpTdWJqZWN0OiBSZTogW3J0Y3dlYl0gV2hhdCB0aGUgZ2F0ZXdheSBk cmFmdCBzaG91bGQgc2F5IGFib3V0IG11eC9ub24tbXV4DQoNCldoeSBzaG91bGQgd2UgY29uc2lk ZXIgM0dQUCB0aGUgc29sZSAib3duZXIvdXNlciIgb2YgdGhlIHRlcm0vZW50aXR5IFdlYlJUQy1H Vz8gSSB0aGluayBpdCBoYXMgYSBtdWNoIG1vcmUgZ2VuZXJhbCBtZWFuaW5nIGFuZCB1c2UgaW4g cHJhY3RpY2UuIEl0IGNhbiByZWZlciB0byBtYW55IGRpZmZlcmVudCB0eXBlcyBvZiBlbGVtZW50 cyB3aGljaCBjYW4gYmUgZGVwbG95ZWQgaW4gbWFueSBkaWZmZXJlbnQgZW52aXJvbm1lbnRzLCBo ZW5jZSBhbnkgYXR0ZW1wdCB0byBkZWZpbmUgaXQgc3RyaWN0bHkvcmVzdHJpY3QgaXRzIGNhcGFi aWxpdGllcyBhcmUgZnV0aWxlIElNSE8uDQoNClRoYW5rcywNClRvbGdhDQoNCl9fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fDQpGcm9tOiBTY2h3YXJ6LCBBbGJyZWNodCAoQWxicmVjaHQp IDxhbGJyZWNodC5zY2h3YXJ6QGFsY2F0ZWwtbHVjZW50LmNvbTxtYWlsdG86YWxicmVjaHQuc2No d2FyekBhbGNhdGVsLWx1Y2VudC5jb20+Pg0KU2VudDogVGh1cnNkYXksIEF1Z3VzdCA2LCAyMDE1 IDI6NDQgQU0NClRvOiBBc3ZlcmVuLCBUb2xnYTsgUm9tYW4gU2hwb3VudDsgUmF1c2NoZW5iYWNo LCBVd2UgKE5va2lhIC0gREUvTXVuaWNoKQ0KQ2M6IGV4dCBFcmljIFJlc2NvcmxhOyBDaHJpc3Rl ciBIb2xtYmVyZzsgQmVybmFyZCBBYm9iYTsgPHJ0Y3dlYkBpZXRmLm9yZzxtYWlsdG86cnRjd2Vi QGlldGYub3JnPj4NClN1YmplY3Q6IFJFOiBbcnRjd2ViXSBXaGF0IHRoZSBnYXRld2F5IGRyYWZ0 IHNob3VsZCBzYXkgYWJvdXQgbXV4L25vbi1tdXgNCg0KVGhlIGNvbmNlcm5lZCAzR1BQIFdlYlJU QyBnYXRld2F5ICgzR1BQIDIzLjMzNC8yOS4zMzQpIHN1cHBvcnRzIGFscmVhZHkgUlRQL1JUQ1Ag dHJhbnNwb3J0IG11bHRpcGxleGluZyAoc2luY2UgM0dQUCBSZWxlYXNlIDEyKSwgaS5lLiBzaG91 bGQgbm90IGJlIHRoZSBsaW1pdGluZyBmYWN0b3IgaW4gdGhpcyBkaXNjdXNzaW9uLg0KRm9yIG9u ZXMgaW50ZXJlc3RlZCBpbiB0aGUgUlRDUCBwb3J0IGFsbG9jYXRpb24gcnVsZXMsIHNlZSBILjI0 OC41NzoNCmh0dHBzOi8vd3d3Lml0dS5pbnQvcmVjL2RvbG9naW5fcHViLmFzcD9sYW5nPWUmaWQ9 VC1SRUMtSC4yNDguNTctMjAxNDEwLUkhIVBERi1FJnR5cGU9aXRlbXMNCkNsYXVzZSA3IGRlc2Ny aWJlcyBSVFAvUlRDUCB0cmFuc3BvcnQgbXVsdGlwbGV4aW5nLiBJVFUtVCBILjI0OC41NyBpcyBh bHJlYWR5IHN1cHBvcnRlZCBieSAzR1BQIDI5LjMzNC4NCg0KVGhlIHJhdGlvbmFsZSBiZWhpbmQg dGhlIOKAnG9wdGlvbmFsIHRhZ2dpbmfigJ0gYnkgMjMuMjI4IGlzIGEgdGhpcmQgcmVhc29uLCBi ZXlvbmQNCj4xLiBVc2luZyBkaWZmZXJlbnQgUU9TIHNldHRpbmdzIGZvciBSVENQIHZzIFJUUA0K PjIuIFNlbmRpbmcgUlRDUCB0byBhIGRpZmZlcmVudCBkZXZpY2UgZnJvbSBSVFANCg0KRG9u4oCZ dCB3YW50IHRvIGdvIGluIHRoZSAzR1BQIHNwZWNpZmljIGRldGFpbHMsIGJ1dCBpdCBoYXMgbm90 aGluZyB0byBkbyB3aXRoIHRoZSAzR1BQIFVFLWVtYmVkZGVkIFdlYlJUQyBjbGllbnQgbm9yIGFu eSBjb25zdHJhaW50cyBieSAzR1BQIFdlYlJUQyBnYXRld2F5cy4NCg0KVGh1cywgYSBXZWJSVEMg Z2F0ZXdheSBNVVNUIHN1cHBvcnQgUlRQL1JUQ1AgdHJhbnNwb3J0IG11bHRpcGxleGluZyBkdWUg dG8gaXRzIHB1cnBvc2UgaW4gaW50ZXJ3b3JraW5nIHN1cHBvcnQuDQoNClJlZ2FyZHMsDQpBbGJy ZWNodA0KDQoNCkZyb206IEFzdmVyZW4sIFRvbGdhIFttYWlsdG86dGFzdmVyZW5Ac29udXNuZXQu Y29tXQ0KU2VudDogTWl0dHdvY2gsIDUuIEF1Z3VzdCAyMDE1IDE5OjQ3DQpUbzogUm9tYW4gU2hw b3VudDsgUmF1c2NoZW5iYWNoLCBVd2UgKE5va2lhIC0gREUvTXVuaWNoKQ0KQ2M6IGV4dCBFcmlj IFJlc2NvcmxhOyBTY2h3YXJ6LCBBbGJyZWNodCAoQWxicmVjaHQpOyBDaHJpc3RlciBIb2xtYmVy ZzsgQmVybmFyZCBBYm9iYTsgPHJ0Y3dlYkBpZXRmLm9yZzxtYWlsdG86cnRjd2ViQGlldGYub3Jn Pj4NClN1YmplY3Q6IFJFOiBbcnRjd2ViXSBXaGF0IHRoZSBnYXRld2F5IGRyYWZ0IHNob3VsZCBz YXkgYWJvdXQgbXV4L25vbi1tdXgNCg0KaS0gSSBodW1ibHkgZGlzYWdyZWUgdGhhdCB1c2luZyBk aWZmZXJlbnQgUW9TIFJUQ1AvUlRQLCBlLmcuIGRpZmZlcmVudCBEaWZmU2VydiB2YWx1ZXMgLCBz aG91bGQgYmUgZGlzbWlzc2VkLg0KaWktIExldCBtZSBhbHNvIGFkZCBhbm90aGVyIHJlYXNvbiB3 aHkgbm8tcnRjcC1tdXggbWF5IGJlIG5lZWRlZDogSW1wbGVtZW50YXRpb24gZGlmZmljdWx0aWVz IGluIGNlcnRhaW4gR1dzLg0KDQpDb25zaWRlcmluZyB0aGF0IHRoZXJlIGlzIGFscmVhZHkgYSBu ZWdvdGlhdGlvbiBtZWNoYW5pc20gZm9yIHJ0Y3AtbXV4IHN1cHBvcnQsIHRoYXQgaXQgY2FuIGJl IGRlLWZhY3RvIG1hbmRhdGVkIGJ5IHRoZSBjaG9pY2Ugb2YgYnJvd3NlcnMgZm9yIEludGVybmV0 LCBJIHRoaW5rIHdoYXQgQ2hyaXN0ZXIvQWxicmVjaHQgc3VnZ2VzdGVkIGlzIHRoZSByaWdodCB3 YXkgdG8gbW92ZSBmb3J3YXJkOiBwcm92aWRlIGNsYXJpZmljYXRpb25zIGZvciB2YWd1ZSBwb2lu dHMuIEkgZG9u4oCZdCB1bmRlcnN0YW5kIHdoeSBsYWNrIG9mIGNsYXJpdHkgaW4gZXhpc3Rpbmcg c3BlY2lmaWNhdGlvbnMgc2hvdWxkIGNhdXNlIGltcG9zaW5nIHJlc3RyaWN0aW9ucy4gVGhpcyB3 b3VsZCBiZSBha2luIHRvIGRyb3BwaW5nIGEgZmVhdHVyZSBkdWUgdG8gYSBidWcuIEluIHRoaXMg Y2FzZSwgdGhlIOKAnGJ1Z+KAnSBpcyBsYWNrIG9mIGNsYXJpdHkgaW4gbm9ybWF0aXZlIHNwZWNp ZmljYXRpb25zIGFuZCBpdCBjYW4gYmUgYWRkcmVzc2VkIGJ5IGZ1cnRoZXIgc3BlY2lmaWNhdGlv bi4NCg0KVGhhbmtzLA0KVG9sZ2ENCg0KRnJvbTogUm9tYW4gU2hwb3VudCBbbWFpbHRvOnJvbWFu QHRlbHVyaXguY29tXQ0KU2VudDogV2VkbmVzZGF5LCBBdWd1c3QgMDUsIDIwMTUgMTI6MjkgUE0N ClRvOiBSYXVzY2hlbmJhY2gsIFV3ZSAoTm9raWEgLSBERS9NdW5pY2gpIDx1d2UucmF1c2NoZW5i YWNoQG5va2lhLmNvbTxtYWlsdG86dXdlLnJhdXNjaGVuYmFjaEBub2tpYS5jb20+Pg0KQ2M6IGV4 dCBFcmljIFJlc2NvcmxhIDxla3JAcnRmbS5jb208bWFpbHRvOmVrckBydGZtLmNvbT4+OyBTY2h3 YXJ6LCBBbGJyZWNodCAoQWxicmVjaHQpIDxhbGJyZWNodC5zY2h3YXJ6QGFsY2F0ZWwtbHVjZW50 LmNvbTxtYWlsdG86YWxicmVjaHQuc2Nod2FyekBhbGNhdGVsLWx1Y2VudC5jb20+PjsgQXN2ZXJl biwgVG9sZ2EgPHRhc3ZlcmVuQHNvbnVzbmV0LmNvbTxtYWlsdG86dGFzdmVyZW5Ac29udXNuZXQu Y29tPj47IENocmlzdGVyIEhvbG1iZXJnIDxjaHJpc3Rlci5ob2xtYmVyZ0Blcmljc3Nvbi5jb208 bWFpbHRvOmNocmlzdGVyLmhvbG1iZXJnQGVyaWNzc29uLmNvbT4+OyBCZXJuYXJkIEFib2JhIDxi ZXJuYXJkLmFib2JhQGdtYWlsLmNvbTxtYWlsdG86YmVybmFyZC5hYm9iYUBnbWFpbC5jb20+Pjsg PHJ0Y3dlYkBpZXRmLm9yZzxtYWlsdG86cnRjd2ViQGlldGYub3JnPj4gPHJ0Y3dlYkBpZXRmLm9y ZzxtYWlsdG86cnRjd2ViQGlldGYub3JnPj4NClN1YmplY3Q6IFJlOiBbcnRjd2ViXSBXaGF0IHRo ZSBnYXRld2F5IGRyYWZ0IHNob3VsZCBzYXkgYWJvdXQgbXV4L25vbi1tdXgNCg0KT24gV2VkLCBB dWcgNSwgMjAxNSBhdCA0OjQ3IEFNLCBSYXVzY2hlbmJhY2gsIFV3ZSAoTm9raWEgLSBERS9NdW5p Y2gpIDx1d2UucmF1c2NoZW5iYWNoQG5va2lhLmNvbTxtYWlsdG86dXdlLnJhdXNjaGVuYmFjaEBu b2tpYS5jb20+PiB3cm90ZToNCk1lZGlhIGdhdGV3YXkgaW1wbGVtZW50YXRpb25zIGFjY29yZGlu ZyB0byAzR1BQIFRTIDIzLjIyOCBtYXkgbm90IHN1cHBvcnQgcnRjcC1tdXgsIGFzIHJ0Y3AtbXV4 IGlzIG9wdGlvbmFsIHRoZXJlLg0KU28gaWYgd2UgZHJvcCBub24tbXV4IHN1cHBvcnQgZnJvbSB3 ZWIgYnJvd3NlcnMsIHRob3NlIG1lZGlhIGdhdGV3YXlzIHRoYXQgaGF2ZSBub3QgaW1wbGVtZW50 ZWQgcnRjcC1tdXggd2lsbCBzdG9wIGludGVyb3BlcmF0aW5nLg0KDQoNCkZpcnN0IG9mIGFsbCwg ZG8geW91IGtub3cgb2YgYW55IFdlYlJUQyB0byBJTVMgZ2F0ZXdheXMgdGhhdCBkbyBub3QgaW1w bGVtZW50IHJ0Y3AtbXV4IG9uIHRoZSBXZWJSVEMgc2lkZT8gSSBzdHJvbmdseSBzdXNwZWN0IHRo ZXJlIGFyZSBub25lLg0KDQpTZWNvbmQsIHRoZSBvbmx5IHJlYXNvbnMgbm90IHRvIHVzZSBydGNw LW11eCB0aGF0IEkgY2FuIHRoaW5rIG9mIGFyZSB0aGUgZm9sbG93aW5nOg0KDQoxLiBVc2luZyBk aWZmZXJlbnQgUU9TIHNldHRpbmdzIGZvciBSVENQIHZzIFJUUA0KMi4gU2VuZGluZyBSVENQIHRv IGEgZGlmZmVyZW50IGRldmljZSBmcm9tIFJUUA0KDQpJIGRvIG5vdCB0aGluayB0aGUgZmlyc3Qg dXNlIGNhc2Ugd2FycmFudHMgbWFraW5nIHJ0Y3AtbXV4IG9wdGlvbmFsLCBzaW5jZSwgcHJhY3Rp Y2FsbHkgbm8gb25lIGRvZXMgdGhpcy4NClNlY29uZCB1c2UgY2FzZSBpcyBhbHNvIGZhaXJseSBt YXJnaW5hbC4gUGx1cyBpdCBjYW4gYmUgaGFuZGxlZCBieSB0aGUgZ2F0ZXdheSB3aGljaCBjYW4g c2VuZCBSVENQIHRvIG9uZSBkZXZpY2UgYW5kIFJUUCB0byBhbm90aGVyLg0KDQpTbywgdW5sZXNz IHNvbWVvbmUgY2FuIGNvbWUgdXAgd2l0aCBhIHVzZSBjYXNlIHdoeSBSVFAgYW5kIFJUQ1Agc2hv dWxkIHVzZSBkaWZmZXJlbnQgdHJhbnNwb3J0cywgSSB0aGluayBydGNwLW11eCBzaG91bGQgYmUg bWFuZGF0b3J5Lg0KDQpSZWdhcmRzLA0KX19fX19fX19fX19fX18NClJvbWFuIFNocG91bnQNCl9f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQpydGN3ZWIgbWFp bGluZyBsaXN0DQpydGN3ZWJAaWV0Zi5vcmc8bWFpbHRvOnJ0Y3dlYkBpZXRmLm9yZz4NCmh0dHBz Oi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vcnRjd2ViDQoNCg0KDQpfX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KcnRjd2ViIG1haWxpbmcgbGlz dA0KcnRjd2ViQGlldGYub3JnPG1haWx0bzpydGN3ZWJAaWV0Zi5vcmc+DQpodHRwczovL3d3dy5p ZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL3J0Y3dlYg0KDQoNCl9fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fDQpydGN3ZWIgbWFpbGluZyBsaXN0DQpydGN3ZWJA aWV0Zi5vcmc8bWFpbHRvOnJ0Y3dlYkBpZXRmLm9yZz4NCmh0dHBzOi8vd3d3LmlldGYub3JnL21h aWxtYW4vbGlzdGluZm8vcnRjd2ViDQoNCg== --_000_A85FE9071A214F5FB671922FAF68DA1Cvidyocom_ Content-Type: text/html; charset="utf-8" Content-ID: <33E3CBCFAD97A64C8D6B28C774AFC7A4@vidyo.com> Content-Transfer-Encoding: base64 PGh0bWw+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIgY29udGVudD0i dGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjwvaGVhZD4NCjxib2R5IHN0eWxlPSJ3b3JkLXdy YXA6IGJyZWFrLXdvcmQ7IC13ZWJraXQtbmJzcC1tb2RlOiBzcGFjZTsgLXdlYmtpdC1saW5lLWJy ZWFrOiBhZnRlci13aGl0ZS1zcGFjZTsiIGNsYXNzPSIiPg0KPGJyIGNsYXNzPSIiPg0KPGRpdj4N CjxibG9ja3F1b3RlIHR5cGU9ImNpdGUiIGNsYXNzPSIiPg0KPGRpdiBjbGFzcz0iIj5PbiBBdWcg NiwgMjAxNSwgYXQgMTA6MzUgQU0sIEVyaWMgUmVzY29ybGEgJmx0OzxhIGhyZWY9Im1haWx0bzpl a3JAcnRmbS5jb20iIGNsYXNzPSIiPmVrckBydGZtLmNvbTwvYT4mZ3Q7IHdyb3RlOjwvZGl2Pg0K PGRpdiBjbGFzcz0iIj4NCjxkaXYgZGlyPSJsdHIiIGNsYXNzPSIiPg0KPGRpdiBjbGFzcz0iIj48 YnIgY2xhc3M9IiI+DQo8L2Rpdj4NCjxkaXYgY2xhc3M9IiI+V1JUIHRvIHRoZSBpc3N1ZSBKb25h dGhhbiByYWlzZXMgYWJvdXQgU0RQIGJlaW5nIGEgbmVnb3RpYXRpb24sIHRoYXQncyB0cnVlLCBi dXQgYXM8L2Rpdj4NCjxkaXYgY2xhc3M9IiI+YSBwcmFjdGljYWwgbWF0dGVyIHdlJ3JlIGFscmVh ZHkgZmFyIGRvd24gdGhlIHJvYWQgb2YgV2ViUlRDIG9mZmVyZXJzIG9mZmVyaW5nIFNEUDwvZGl2 Pg0KPGRpdiBjbGFzcz0iIj53aGljaCBpbiBwcmluY2lwbGUgdGhlIGFuc3dlcmVyIG1pZ2h0IGNo b29zZSBub3QgdG8gYWNjZXB0IGJ1dCBpZiBpdCBkb2VzIHNvIHRoZTwvZGl2Pg0KPGRpdiBjbGFz cz0iIj5jb25uZWN0aW9uIHdpbGwgZmFpbDwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvYmxvY2tx dW90ZT4NCjxkaXY+PGJyIGNsYXNzPSIiPg0KPC9kaXY+DQo8ZGl2PknigJltIG5vdCBzdXJlIHdo YXQgeW91IG1lYW4gaGVyZSDigJQgd2hhdCBhcmUgdGhlIHNjZW5hcmlvcyB3aGVyZSB5b3UgY2Fu 4oCZdCB0YWtlIGEgV2ViUlRDIG9mZmVyLCBwdXQgaXQgaW4gYSBTSVAgSU5WSVRFLCBhbmQgYW55 IHN0YW5kYXJkcy1jb21wbGlhbnQgMzI2NCBhbnN3ZXIgdG8gdGhlIG1lc3NhZ2UgaXNu4oCZdCBh bGxvd2VkIGZvciBXZWJSVEM/PC9kaXY+DQo8ZGl2PjxiciBjbGFzcz0iIj4NCjwvZGl2Pg0KPGRp dj5UaGUgb25seSBvbmUgSSBjYW4gdGhpbmsgb2YgY3VycmVudGx5IGlzIHRoZSBhbnN3ZXJlciBk ZWNsaW5pbmcgdG8gZG8gSUNFIOKAlCBzbyB0aGF0IGh5cG90aGV0aWNhbCBTSVAgSU5WSVRFIHdv dWxkIGhhdmUgdG8gaGF2ZSDigJxSZXF1aXJlOiBpY2XigJ0gKFJGQyA1NzY4KSBpbiBpdC48L2Rp dj4NCjxkaXY+PGJyIGNsYXNzPSIiPg0KPC9kaXY+DQo8ZGl2PklmIHlvdSB3YW50IHRvIHNheSB0 aGF0IFdlYlJUQyBicm93c2VycyBNVVNUIE5PVCBzdXBwb3J0IG5vbi1SVENQLW11eCwgdGhhdOKA mXMgZmluZSAoYW5kIHdvdWxkIG1lYW4gaW1wbGljaXRseSBkZWZpbmluZyDigJxSZXF1aXJlOiBy dGNwLW11eOKAnSkuICZuYnNwO0J1dCBpZiB5b3Ugd2FudCB0byBzYXkgdGhhdCBicm93c2VycyBN QVkgc3VwcG9ydCBub24tcnRjcC1tdXgsIHRoZXJlIG5lZWRzIHRvIGJlIHNvbWUgd2F5IGZvciBh cHBsaWNhdGlvbnMgdG8NCiBkaXNjb3ZlciB3aGV0aGVyIHRoZSBicm93c2VyIGRvZXMgaW5kZWVk IHN1cHBvcnQgaXQsIG9yIGVsc2UgdGhlcmXigJlzIG5vIHBvaW50LiBBbmQgSSBiZWxpZXZlIHRo YXQgU0RQIGRvZXNu4oCZdCBjdXJyZW50bHkgaGF2ZSBhbnkgZXhwbGljaXQgc3ludGF4IGZvciB0 aGlzLCBhbmQgdGhlIG5hdHVyZSBvZiBTRFAgbWVhbnMgaXTigJlzIHNvbWV3aGF0IGhhcmQgdG8g ZGVmaW5lLjwvZGl2Pg0KPGRpdj48YnIgY2xhc3M9IiI+DQo8L2Rpdj4NCjxkaXY+Rm9yIGltcGxp Y2l0IHN5bnRheCwgSSBndWVzcyB0aGUgYXBwbGljYXRpb24gY291bGQgY2hlY2sgd2hldGhlciBS VENQIG11eCBpcyBzdXBwb3J0ZWQgYnkgY2hlY2tpbmcgd2hldGhlciB0aGUgb2ZmZXIgY29udGFp bnMgYW55IElDRSBjYW5kaWRhdGVzIGZvciBjb21wb25lbnQgMi4gJm5ic3A7QnV0IHRoaXMgdGll cyBJQ0UgYW5kIFJUQ1AtbXV4IHRvZ2V0aGVyIGluIElNTyBhbiB1bmZvcnR1bmF0ZSB3YXkuPC9k aXY+DQo8YnIgY2xhc3M9IiI+DQo8YmxvY2txdW90ZSB0eXBlPSJjaXRlIiBjbGFzcz0iIj4NCjxk aXYgY2xhc3M9IiI+DQo8ZGl2IGRpcj0ibHRyIiBjbGFzcz0iIj4NCjxkaXYgY2xhc3M9IiI+PGJy IGNsYXNzPSIiPg0KPC9kaXY+DQo8ZGl2IGNsYXNzPSIiPi1Fa3I8L2Rpdj4NCjxkaXYgY2xhc3M9 IiI+PGJyIGNsYXNzPSIiPg0KPC9kaXY+DQo8ZGl2IGNsYXNzPSIiPk9uIFRodSwgQXVnIDYsIDIw MTUgYXQgNzoxMiBBTSwgQXN2ZXJlbiwgVG9sZ2EgPHNwYW4gZGlyPSJsdHIiIGNsYXNzPSIiPg0K Jmx0OzxhIGhyZWY9Im1haWx0bzp0YXN2ZXJlbkBzb251c25ldC5jb20iIHRhcmdldD0iX2JsYW5r IiBjbGFzcz0iIj50YXN2ZXJlbkBzb251c25ldC5jb208L2E+Jmd0Ozwvc3Bhbj4gd3JvdGU6PGJy IGNsYXNzPSIiPg0KPC9kaXY+DQo8ZGl2IGNsYXNzPSIiPg0KPGRpdiBjbGFzcz0iZ21haWxfZXh0 cmEiPg0KPGRpdiBjbGFzcz0iZ21haWxfcXVvdGUiPg0KPGJsb2NrcXVvdGUgY2xhc3M9ImdtYWls X3F1b3RlIiBzdHlsZT0ibWFyZ2luOjAgMCAwIC44ZXg7Ym9yZGVyLWxlZnQ6MXB4ICNjY2Mgc29s aWQ7cGFkZGluZy1sZWZ0OjFleCI+DQo8ZGl2IGxhbmc9IkVOLVVTIiBsaW5rPSJibHVlIiB2bGlu az0icHVycGxlIiBjbGFzcz0iIj4NCjxkaXYgY2xhc3M9IiI+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJp JnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFmNDk3ZCIgY2xhc3M9IiI+SSB0aGluayBpbXBsZW1l bnRlcnMgdGhlbXNlbHZlcyBjYW4gd2VpZ2ggb3V0IHRoZSBhZHZhbnRhZ2VzL2Rpc2FkdmFudGFn ZWQvZGVwbG95bWVudCBtb2RlbHMgdGhleSBhcmUgdGFyZ2V0aW5nL2V0Y+KApiBhbmQgZGVjaWRl IHdoYXQgdG8gc3VwcG9ydC9ub3QgdG8NCiBzdXBwb3J0LiBJIGRvbuKAmXQgc2VlIGFueSBpc3N1 ZSB3aXRoIHRoaXMgYXMgbG9uZyBhcyB0aGVyZSBpcyBhIG5lZ290aWF0aW9uIG1lY2hhbmlzbSAo d2hpY2ggdGhlcmUgaXMpLiBJIGRvbuKAmXQgdGhpbmsgdGhlIGF2YWlsYWJpbGl0eSBvZiBuZWdv dGlhdGlvbiBpcyBlbmNvdXJhZ2luZyBwZW9wbGUgdGhpcyBvciB0aGF0IHdheS48dSBjbGFzcz0i Ij48L3U+PHUgY2xhc3M9IiI+PC91Pjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48 c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1 b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFmNDk3ZCIgY2xhc3M9IiI+PHUgY2xhc3M9IiI+PC91PiZu YnNwOzx1IGNsYXNzPSIiPjwvdT48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNw YW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90 OyxzYW5zLXNlcmlmO2NvbG9yOiMxZjQ5N2QiIGNsYXNzPSIiPlRoYW5rcyw8dSBjbGFzcz0iIj48 L3U+PHUgY2xhc3M9IiI+PC91Pjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3Bh biBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7 LHNhbnMtc2VyaWY7Y29sb3I6IzFmNDk3ZCIgY2xhc3M9IiI+VG9sZ2E8dSBjbGFzcz0iIj48L3U+ PHUgY2xhc3M9IiI+PC91Pjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBz dHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNh bnMtc2VyaWY7Y29sb3I6IzFmNDk3ZCIgY2xhc3M9IiI+PHUgY2xhc3M9IiI+PC91PiZuYnNwOzx1 IGNsYXNzPSIiPjwvdT48L3NwYW4+PC9wPg0KPGRpdiBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVy LWxlZnQ6c29saWQgYmx1ZSAxLjVwdDtwYWRkaW5nOjBpbiAwaW4gMGluIDQuMHB0IiBjbGFzcz0i Ij4NCjxkaXYgY2xhc3M9IiI+DQo8ZGl2IHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItdG9wOnNv bGlkICNlMWUxZTEgMS4wcHQ7cGFkZGluZzozLjBwdCAwaW4gMGluIDBpbiIgY2xhc3M9IiI+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj48YiBjbGFzcz0iIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEx LjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWYiIGNsYXNzPSIi PkZyb206PC9zcGFuPjwvYj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWls eTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWYiIGNsYXNzPSIiPiB0aW0gcGFudG9uIFtt YWlsdG86PGEgaHJlZj0ibWFpbHRvOnRpbUBwaG9uZWZyb21oZXJlLmNvbSIgdGFyZ2V0PSJfYmxh bmsiIGNsYXNzPSIiPnRpbUBwaG9uZWZyb21oZXJlLmNvbTwvYT5dDQo8YnIgY2xhc3M9IiI+DQo8 YiBjbGFzcz0iIj5TZW50OjwvYj4gVGh1cnNkYXksIEF1Z3VzdCAwNiwgMjAxNSAxMDowNyBBTTxi ciBjbGFzcz0iIj4NCjxiIGNsYXNzPSIiPlRvOjwvYj4gSHV0dG9uLCBBbmRyZXcgJmx0OzxhIGhy ZWY9Im1haWx0bzphbmRyZXcuaHV0dG9uQHVuaWZ5LmNvbSIgdGFyZ2V0PSJfYmxhbmsiIGNsYXNz PSIiPmFuZHJldy5odXR0b25AdW5pZnkuY29tPC9hPiZndDs8YnIgY2xhc3M9IiI+DQo8YiBjbGFz cz0iIj5DYzo8L2I+IEFzdmVyZW4sIFRvbGdhICZsdDs8YSBocmVmPSJtYWlsdG86dGFzdmVyZW5A c29udXNuZXQuY29tIiB0YXJnZXQ9Il9ibGFuayIgY2xhc3M9IiI+dGFzdmVyZW5Ac29udXNuZXQu Y29tPC9hPiZndDs7ICZsdDs8YSBocmVmPSJtYWlsdG86cnRjd2ViQGlldGYub3JnIiB0YXJnZXQ9 Il9ibGFuayIgY2xhc3M9IiI+cnRjd2ViQGlldGYub3JnPC9hPiZndDsgJmx0OzxhIGhyZWY9Im1h aWx0bzpydGN3ZWJAaWV0Zi5vcmciIHRhcmdldD0iX2JsYW5rIiBjbGFzcz0iIj5ydGN3ZWJAaWV0 Zi5vcmc8L2E+Jmd0Ozwvc3Bhbj48L3A+DQo8ZGl2IGNsYXNzPSIiPg0KPGRpdiBjbGFzcz0iaDUi PjxiciBjbGFzcz0iIj4NCjxiIGNsYXNzPSIiPlN1YmplY3Q6PC9iPiBSZTogW3J0Y3dlYl0gV2hh dCB0aGUgZ2F0ZXdheSBkcmFmdCBzaG91bGQgc2F5IGFib3V0IG11eC9ub24tbXV4PHUgY2xhc3M9 IiI+PC91Pjx1IGNsYXNzPSIiPjwvdT48L2Rpdj4NCjwvZGl2Pg0KPGRpdiBjbGFzcz0iIj48YnIg Y2xhc3M9IndlYmtpdC1ibG9jay1wbGFjZWhvbGRlciI+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+ DQo8ZGl2IGNsYXNzPSIiPg0KPGRpdiBjbGFzcz0iaDUiPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ PHUgY2xhc3M9IiI+PC91PiZuYnNwOzx1IGNsYXNzPSIiPjwvdT48L3A+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj48dSBjbGFzcz0iIj48L3U+Jm5ic3A7PHUgY2xhc3M9IiI+PC91PjwvcD4NCjxkaXYg Y2xhc3M9IiI+DQo8YmxvY2txdW90ZSBzdHlsZT0ibWFyZ2luLXRvcDo1LjBwdDttYXJnaW4tYm90 dG9tOjUuMHB0IiBjbGFzcz0iIj4NCjxkaXYgY2xhc3M9IiI+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij5PbiA2IEF1ZyAyMDE1LCBhdCAwODozMCwgSHV0dG9uLCBBbmRyZXcgJmx0OzxhIGhyZWY9Im1h aWx0bzphbmRyZXcuaHV0dG9uQHVuaWZ5LmNvbSIgdGFyZ2V0PSJfYmxhbmsiIGNsYXNzPSIiPmFu ZHJldy5odXR0b25AdW5pZnkuY29tPC9hPiZndDsgd3JvdGU6PHUgY2xhc3M9IiI+PC91Pjx1IGNs YXNzPSIiPjwvdT48L3A+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjx1IGNsYXNzPSIi PjwvdT4mbmJzcDs8dSBjbGFzcz0iIj48L3U+PC9wPg0KPGRpdiBjbGFzcz0iIj4NCjxkaXYgY2xh c3M9IiI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBw dDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFmNDk3 ZCIgY2xhc3M9IiI+JiM0MzsxIHRvIHdoYXQgVGltIHNhaWQuPC9zcGFuPjx1IGNsYXNzPSIiPjwv dT48dSBjbGFzcz0iIj48L3U+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9 ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNl cmlmO2NvbG9yOiMxZjQ5N2QiIGNsYXNzPSIiPiZuYnNwOzwvc3Bhbj48dSBjbGFzcz0iIj48L3U+ PHUgY2xhc3M9IiI+PC91PjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJm b250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJp Zjtjb2xvcjojMWY0OTdkIiBjbGFzcz0iIj5JIGRvbuKAmXQgdGhpbmsgdGhpcyBkaXNjdXNzaW9u IGlzIHJlYWxseSBhYm91dCBnYXRld2F5cyBhdCBhbGwgaXQgaXMgc3VyZWx5IGFib3V0IHdoZXRo ZXIgV2ViUlRDIGJyb3dzZXJzIGhhdmUgdG8gc3VwcG9ydCBub24tbXV4IGFuZCBJIGRvbuKAmXQg cmVhbGx5IHNlZQ0KIGFueSBnb29kIHJlYXNvbiB3aHkgdGhleSBuZWVkIHRvLjwvc3Bhbj48dSBj bGFzcz0iIj48L3U+PHUgY2xhc3M9IiI+PC91PjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxz cGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVv dDssc2Fucy1zZXJpZjtjb2xvcjojMWY0OTdkIiBjbGFzcz0iIj4mbmJzcDs8L3NwYW4+PHUgY2xh c3M9IiI+PC91Pjx1IGNsYXNzPSIiPjwvdT48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3Bh biBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7 LHNhbnMtc2VyaWY7Y29sb3I6IzFmNDk3ZCIgY2xhc3M9IiI+SWYgd2UgaGFkIHRob3VnaHQgYWJv dXQgdGhpcyBhdCB0aGUgdGltZSB3ZSBtYW5kYXRlZCBEVExTLVNSVFAgdGhlbiB3ZSB3b3VsZCBo YXZlIG1hbmRhdGVkIHJ0cC1tdXggYXQgdGhlIHNhbWUgdGltZSBidXQgdW5mb3J0dW5hdGVseSB3 ZSBkaWRu4oCZdCBidXQgd2UNCiBjYW4gZml4IHRoYXQgbm93Ljwvc3Bhbj48dSBjbGFzcz0iIj48 L3U+PHUgY2xhc3M9IiI+PC91PjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Jsb2NrcXVvdGU+DQo8 ZGl2IGNsYXNzPSIiPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHUgY2xhc3M9IiI+PC91PiZuYnNw Ozx1IGNsYXNzPSIiPjwvdT48L3A+DQo8L2Rpdj4NCjxkaXYgY2xhc3M9IiI+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj5TYWRseSB0cnVlLCBidXQgdGhlIHNpdHVhdGlvbiBpbiBhIGJyb3dzZXIgaXMg bWFuYWdlYWJsZSBzaW5jZSB5b3UgbWlnaHQgZXhwZWN0IDEwIHBlZXIgY29ubmVjdGlvbnMsIHJl c3VsdGluZyZuYnNwOzx1IGNsYXNzPSIiPjwvdT48dSBjbGFzcz0iIj48L3U+PC9wPg0KPC9kaXY+ DQo8ZGl2IGNsYXNzPSIiPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+aW4gYSB3b3JzdCBjYXNlIG9m IDYwIFVEUCBwb3J0cy9EVExTIHNlc3Npb25zIGluIHVzZSZuYnNwOzx1IGNsYXNzPSIiPjwvdT48 dSBjbGFzcz0iIj48L3U+PC9wPg0KPC9kaXY+DQo8ZGl2IGNsYXNzPSIiPg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+KGFzc3VtaW5nIHZvaWNlJiM0Mzt2aWRlbyYjNDM7ZGF0YSB1bmJ1bmRsZWQgYW5k IFJUQ1Atbm9uLW11eCB2cyB0aGUgMTAgbmVlZGVkKS4gV2UmbmJzcDs8dSBjbGFzcz0iIj48L3U+ PHUgY2xhc3M9IiI+PC91PjwvcD4NCjwvZGl2Pg0KPGRpdiBjbGFzcz0iIj4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPmFsc28gYXNzdW1lIGEgcmVsYXRpdmVseSB3ZWxsIGVuZG93ZWQgQ1BVIC0gZGV2 b3RlZCBsYXJnZWx5IHRvIHRoaXMgdGFzay48dSBjbGFzcz0iIj48L3U+PHUgY2xhc3M9IiI+PC91 PjwvcD4NCjwvZGl2Pg0KPGRpdiBjbGFzcz0iIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjx1IGNs YXNzPSIiPjwvdT4mbmJzcDs8dSBjbGFzcz0iIj48L3U+PC9wPg0KPC9kaXY+DQo8ZGl2IGNsYXNz PSIiPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+T24gdGhlIGdhdGV3YXkgeW914oCZZCBob3BlIHRv IGhhdmUgdGhvdXNhbmRzIG9mIHNlc3Npb25zIGFuZCBwcmVzdW1hYmx5IG11Y2ggbGVzcyBDUFUv bWVtb3J5IHJlc291cmNlIHBlciBjaGFubmVsLjx1IGNsYXNzPSIiPjwvdT48dSBjbGFzcz0iIj48 L3U+PC9wPg0KPC9kaXY+DQo8ZGl2IGNsYXNzPSIiPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+U28g d2hpbGUgSSB0aGluayBpdCBpcyB1bmZvcnR1bmF0ZSB0aGF0IGJyb3dzZXJzIGNhbiBkbyBub24t bXV4LCBpdCB3b3VsZCBiZSBwbGFpbiBzdHVwaWQgdG8gZG8gdGhhdCBvbiBhIGdhdGV3YXkuIERv IHdlJm5ic3A7PHUgY2xhc3M9IiI+PC91Pjx1IGNsYXNzPSIiPjwvdT48L3A+DQo8L2Rpdj4NCjxk aXYgY2xhc3M9IiI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5yZWFsbHkgd2FudCB0byBlbmNvdXJh Z2UgdGhhdCA/PHUgY2xhc3M9IiI+PC91Pjx1IGNsYXNzPSIiPjwvdT48L3A+DQo8L2Rpdj4NCjxk aXYgY2xhc3M9IiI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48dSBjbGFzcz0iIj48L3U+Jm5ic3A7 PHUgY2xhc3M9IiI+PC91PjwvcD4NCjwvZGl2Pg0KPGRpdiBjbGFzcz0iIj4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPlQuPHUgY2xhc3M9IiI+PC91Pjx1IGNsYXNzPSIiPjwvdT48L3A+DQo8L2Rpdj4N CjxkaXYgY2xhc3M9IiI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48dSBjbGFzcz0iIj48L3U+Jm5i c3A7PHUgY2xhc3M9IiI+PC91PjwvcD4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGJy IGNsYXNzPSIiPg0KPGJyIGNsYXNzPSIiPg0KPHUgY2xhc3M9IiI+PC91Pjx1IGNsYXNzPSIiPjwv dT48L3A+DQo8YmxvY2txdW90ZSBzdHlsZT0ibWFyZ2luLXRvcDo1LjBwdDttYXJnaW4tYm90dG9t OjUuMHB0IiBjbGFzcz0iIj4NCjxkaXYgY2xhc3M9IiI+DQo8ZGl2IGNsYXNzPSIiPg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6 JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxZjQ5N2QiIGNsYXNzPSIiPiZu YnNwOzwvc3Bhbj48dSBjbGFzcz0iIj48L3U+PHUgY2xhc3M9IiI+PC91PjwvcD4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZx dW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMWY0OTdkIiBjbGFzcz0iIj5BbmR5 PC9zcGFuPjx1IGNsYXNzPSIiPjwvdT48dSBjbGFzcz0iIj48L3U+PC9wPg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7 Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxZjQ5N2QiIGNsYXNzPSIiPiZuYnNwOzwv c3Bhbj48dSBjbGFzcz0iIj48L3U+PHUgY2xhc3M9IiI+PC91PjwvcD4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0Nh bGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMWY0OTdkIiBjbGFzcz0iIj4mbmJzcDs8L3Nw YW4+PHUgY2xhc3M9IiI+PC91Pjx1IGNsYXNzPSIiPjwvdT48L3A+DQo8ZGl2IHN0eWxlPSJib3Jk ZXI6bm9uZTtib3JkZXItbGVmdDpzb2xpZCBibHVlIDEuNXB0O3BhZGRpbmc6MGluIDBpbiAwaW4g NC4wcHQiIGNsYXNzPSIiPg0KPGRpdiBjbGFzcz0iIj4NCjxkaXYgc3R5bGU9ImJvcmRlcjpub25l O2JvcmRlci10b3A6c29saWQgI2I1YzRkZiAxLjBwdDtwYWRkaW5nOjMuMHB0IDBpbiAwaW4gMGlu IiBjbGFzcz0iIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxiIGNsYXNzPSIiPjxzcGFuIHN0eWxl PSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O1RhaG9tYSZxdW90OyxzYW5zLXNl cmlmIiBjbGFzcz0iIj5Gcm9tOjwvc3Bhbj48L2I+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4w cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7VGFob21hJnF1b3Q7LHNhbnMtc2VyaWYiIGNsYXNzPSIiPiBy dGN3ZWIgWzxhIGhyZWY9Im1haWx0bzpydGN3ZWItYm91bmNlc0BpZXRmLm9yZyIgdGFyZ2V0PSJf YmxhbmsiIGNsYXNzPSIiPm1haWx0bzpydGN3ZWItYm91bmNlc0BpZXRmLm9yZzwvYT5dDQo8YiBj bGFzcz0iIj5PbiBCZWhhbGYgT2YgPC9iPnRpbSBwYW50b248YnIgY2xhc3M9IiI+DQo8YiBjbGFz cz0iIj5TZW50OjwvYj4gMDYgQXVndXN0IDIwMTUgMTM6NTM8YnIgY2xhc3M9IiI+DQo8YiBjbGFz cz0iIj5Ubzo8L2I+IEFzdmVyZW4sIFRvbGdhPGJyIGNsYXNzPSIiPg0KPGIgY2xhc3M9IiI+Q2M6 PC9iPiAmbHQ7PGEgaHJlZj0ibWFpbHRvOnJ0Y3dlYkBpZXRmLm9yZyIgdGFyZ2V0PSJfYmxhbmsi IGNsYXNzPSIiPnJ0Y3dlYkBpZXRmLm9yZzwvYT4mZ3Q7PGJyIGNsYXNzPSIiPg0KPGIgY2xhc3M9 IiI+U3ViamVjdDo8L2I+IFJlOiBbcnRjd2ViXSBXaGF0IHRoZSBnYXRld2F5IGRyYWZ0IHNob3Vs ZCBzYXkgYWJvdXQgbXV4L25vbi1tdXg8L3NwYW4+PHUgY2xhc3M9IiI+PC91Pjx1IGNsYXNzPSIi PjwvdT48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Jm5ic3A7PHUg Y2xhc3M9IiI+PC91Pjx1IGNsYXNzPSIiPjwvdT48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5T byB3ZSBhcmUgcG9zaXRpbmcgdGhlIGV4aXN0ZW5jZSBvZiBhIHdlYlJUQyBnYXRld2F5IGRlc2ln bmVkIHRvIHN1cHBvcnQgdGhvdXNhbmRzIG9mIGNhbGxzIHdoaWNoIGRvZXMgSUNFIGFuZCBEVExT IGJ1dCB0aGU8dSBjbGFzcz0iIj48L3U+PHUgY2xhc3M9IiI+PC91PjwvcD4NCjxkaXYgY2xhc3M9 IiI+DQo8ZGl2IGNsYXNzPSIiPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ZGVzaWduZXIgZGVjaWRl ZCBkZWxpYmVyYXRlbHkgdG8gZG91YmxlIHRoZSBudW1iZXIgb2YgSUNFIHNlc3Npb25zIHJlcXVp cmVkIGFuZCBkb3VibGUgdGhlIG51bWJlciBvZiBEVExTIHNlc3Npb25zIChhbmQga2V5Jm5ic3A7 PHUgY2xhc3M9IiI+PC91Pjx1IGNsYXNzPSIiPjwvdT48L3A+DQo8L2Rpdj4NCjxkaXYgY2xhc3M9 IiI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5nZW5lcmF0aW9uIGNvc3RzKSBzbyB0aGF0IHRoZXkg Y2FuIHJ1biBSVENQIChvdmVyIElDRSBhbmQgRFRMUykgb24gYSBzZXBhcmF0ZSBwb3J0LiBJbiBt eSBlc3RpbWF0aW9uIHRoYXTigJlzIG9uZSBwb29yIGRlY2lzaW9uPHUgY2xhc3M9IiI+PC91Pjx1 IGNsYXNzPSIiPjwvdT48L3A+DQo8L2Rpdj4NCjxkaXYgY2xhc3M9IiI+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj5hbmQgc2hvdWxkIG5vdCBiZSB1c2VkIGFzIHRoZSBiYXNpcyBvZiB0aGlzIChvciBh bnkpIHN0YW5kYXJkLiZuYnNwOzx1IGNsYXNzPSIiPjwvdT48dSBjbGFzcz0iIj48L3U+PC9wPg0K PC9kaXY+DQo8ZGl2IGNsYXNzPSIiPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Jm5ic3A7PHUgY2xh c3M9IiI+PC91Pjx1IGNsYXNzPSIiPjwvdT48L3A+DQo8L2Rpdj4NCjxkaXYgY2xhc3M9IiI+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj5J4oCZZCByYXRoZXIgbm90IHN1cHBvcnQgcnRjcC1uby1tdXgg YXMgSSBzZWUgemVybyBhZHZhbnRhZ2VzIGluIGhhdmluZyBpdC4gKEkga25vdyB0aGVvcmV0aWNh bGx5IGl0IG1pZ2h0IGJlIHBvc3NpYmxlIHRvIGdldDx1IGNsYXNzPSIiPjwvdT48dSBjbGFzcz0i Ij48L3U+PC9wPg0KPC9kaXY+DQo8ZGl2IGNsYXNzPSIiPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ YSBSVENQIHBhY2tldCB0aHJvdWdoIGEgY29uZ2VzdGVkIG5ldCBvbiBhIGRpZmZlcmVudCBwb3J0 IHdpdGggYSBzZXBhcmF0ZSBkaWZmc2VydiBzZXR0aW5nIGJ1dCB0aGF0IGp1c3Qgc2VlbXMgc28g Y29udHJpdmVkKS48dSBjbGFzcz0iIj48L3U+PHUgY2xhc3M9IiI+PC91PjwvcD4NCjwvZGl2Pg0K PGRpdiBjbGFzcz0iIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPiZuYnNwOzx1IGNsYXNzPSIiPjwv dT48dSBjbGFzcz0iIj48L3U+PC9wPg0KPC9kaXY+DQo8ZGl2IGNsYXNzPSIiPg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+VGltLjx1IGNsYXNzPSIiPjwvdT48dSBjbGFzcz0iIj48L3U+PC9wPg0KPC9k aXY+DQo8ZGl2IGNsYXNzPSIiPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Jm5ic3A7PHUgY2xhc3M9 IiI+PC91Pjx1IGNsYXNzPSIiPjwvdT48L3A+DQo8L2Rpdj4NCjxkaXYgY2xhc3M9IiI+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj4mbmJzcDs8dSBjbGFzcz0iIj48L3U+PHUgY2xhc3M9IiI+PC91Pjwv cD4NCjwvZGl2Pg0KPGRpdiBjbGFzcz0iIj4NCjxkaXYgY2xhc3M9IiI+DQo8YmxvY2txdW90ZSBz dHlsZT0ibWFyZ2luLXRvcDo1LjBwdDttYXJnaW4tYm90dG9tOjUuMHB0IiBjbGFzcz0iIj4NCjxk aXYgY2xhc3M9IiI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5PbiA2IEF1ZyAyMDE1LCBhdCAwNjo0 NCwgQXN2ZXJlbiwgVG9sZ2EgJmx0OzxhIGhyZWY9Im1haWx0bzp0YXN2ZXJlbkBzb251c25ldC5j b20iIHRhcmdldD0iX2JsYW5rIiBjbGFzcz0iIj50YXN2ZXJlbkBzb251c25ldC5jb208L2E+Jmd0 OyB3cm90ZTo8dSBjbGFzcz0iIj48L3U+PHUgY2xhc3M9IiI+PC91PjwvcD4NCjwvZGl2Pg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+Jm5ic3A7PHUgY2xhc3M9IiI+PC91Pjx1IGNsYXNzPSIiPjwvdT48 L3A+DQo8ZGl2IGNsYXNzPSIiPg0KPGRpdiBjbGFzcz0iIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkm cXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMWY0OTdkIiBjbGFzcz0iIj5UaGVzZSBhc3N1bXB0aW9u cyBhcmUgbm90IG5lY2Vzc2FyaWx5IHRydWUgaW4gYSB1bml2ZXJzYWwgc2Vuc2UgKGxpa2UgYWxt b3N0IGFueSBvdGhlciBhc3N1bXB0aW9uIGFib3V0IGRpZmZlcmVudCBkZXBsb3ltZW50IG1vZGVs cykuPC9zcGFuPjx1IGNsYXNzPSIiPjwvdT48dSBjbGFzcz0iIj48L3U+PC9wPg0KPC9kaXY+DQo8 ZGl2IGNsYXNzPSIiPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6 ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9y OiMxZjQ5N2QiIGNsYXNzPSIiPiZuYnNwOzwvc3Bhbj48dSBjbGFzcz0iIj48L3U+PHUgY2xhc3M9 IiI+PC91PjwvcD4NCjwvZGl2Pg0KPGRpdiBjbGFzcz0iIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkm cXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMWY0OTdkIiBjbGFzcz0iIj5GdXJ0aGVybW9yZSwgYW5k IG1vcmUgaW1wb3J0YW50bHksIHRoZXJlIGlzIG5vdGhpbmcgbWFuZGF0aW5nIFdlYlJUQyBlbmRw b2ludHMgdG8gc3VwcG9ydCBub24tcnRjcC1tdXguIEl0IGlzIGEgbmVnb3RpYXRlZCBmdW5jdGlv bmFsaXR5LiBBbnkgZW50aXR5DQogY2FuIGVuZm9yY2UgcnRjcC1tdXggYXMgYSBsb2NhbCBwb2xp Y3kuPHNwYW4gY2xhc3M9IiI+Jm5ic3A7PC9zcGFuPjwvc3Bhbj48dSBjbGFzcz0iIj48L3U+PHUg Y2xhc3M9IiI+PC91PjwvcD4NCjwvZGl2Pg0KPGRpdiBjbGFzcz0iIj4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0Nh bGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMWY0OTdkIiBjbGFzcz0iIj4mbmJzcDs8L3Nw YW4+PHUgY2xhc3M9IiI+PC91Pjx1IGNsYXNzPSIiPjwvdT48L3A+DQo8L2Rpdj4NCjxkaXYgY2xh c3M9IiI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBw dDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFmNDk3 ZCIgY2xhc3M9IiI+VGhlIGlzc3VlIHdpdGggc3VwcG9ydGluZyBub24tcnRjcC1tdXggc2VlbXMg dG8gYmUgbGFjayBvZiBjbGFyaXR5IGluIHRoZSByZWxldmFudCBzcGVjaWZpY2F0aW9ucy4gRml4 aW5nIHRoaXMg4oCTcmVnYXJkbGVzcyBvZiB0aGUgb3V0Y29tZSBvZiBhbnkgb3RoZXINCiBkaXNj dXNzaW9uLSBzZWVtcyB0byBiZSBwcnVkZW50IElNSE8uPC9zcGFuPjx1IGNsYXNzPSIiPjwvdT48 dSBjbGFzcz0iIj48L3U+PC9wPg0KPC9kaXY+DQo8ZGl2IGNsYXNzPSIiPg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7 Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxZjQ5N2QiIGNsYXNzPSIiPiZuYnNwOzwv c3Bhbj48dSBjbGFzcz0iIj48L3U+PHUgY2xhc3M9IiI+PC91PjwvcD4NCjwvZGl2Pg0KPGRpdiBj bGFzcz0iIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEu MHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMWY0 OTdkIiBjbGFzcz0iIj5UaGFua3MsPC9zcGFuPjx1IGNsYXNzPSIiPjwvdT48dSBjbGFzcz0iIj48 L3U+PC9wPg0KPC9kaXY+DQo8ZGl2IGNsYXNzPSIiPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNw YW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90 OyxzYW5zLXNlcmlmO2NvbG9yOiMxZjQ5N2QiIGNsYXNzPSIiPlRvbGdhPC9zcGFuPjx1IGNsYXNz PSIiPjwvdT48dSBjbGFzcz0iIj48L3U+PC9wPg0KPC9kaXY+DQo8ZGl2IGNsYXNzPSIiPg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1p bHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxZjQ5N2QiIGNsYXNzPSIi PiZuYnNwOzwvc3Bhbj48dSBjbGFzcz0iIj48L3U+PHUgY2xhc3M9IiI+PC91PjwvcD4NCjwvZGl2 Pg0KPGRpdiBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLWxlZnQ6c29saWQgYmx1ZSAxLjVwdDtw YWRkaW5nOjBpbiAwaW4gMGluIDQuMHB0IiBjbGFzcz0iIj4NCjxkaXYgY2xhc3M9IiI+DQo8ZGl2 IHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItdG9wOnNvbGlkICNlMWUxZTEgMS4wcHQ7cGFkZGlu ZzozLjBwdCAwaW4gMGluIDBpbiIgY2xhc3M9IiI+DQo8ZGl2IGNsYXNzPSIiPg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+PGIgY2xhc3M9IiI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9u dC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmIiBjbGFzcz0iIj5Gcm9tOjwv c3Bhbj48L2I+PHNwYW4gY2xhc3M9IiI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9u dC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmIiBjbGFzcz0iIj4mbmJzcDs8 L3NwYW4+PC9zcGFuPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZx dW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZiIgY2xhc3M9IiI+V3lzcywNCiBGZWxpeCBbPGEg aHJlZj0ibWFpbHRvOkZlbGl4Lld5c3NAaW5pbi5jb20iIHRhcmdldD0iX2JsYW5rIiBjbGFzcz0i Ij5tYWlsdG86RmVsaXguV3lzc0BpbmluLmNvbTwvYT5dPHNwYW4gY2xhc3M9IiI+Jm5ic3A7PC9z cGFuPjxiciBjbGFzcz0iIj4NCjxiIGNsYXNzPSIiPlNlbnQ6PC9iPjxzcGFuIGNsYXNzPSIiPiZu YnNwOzwvc3Bhbj5UaHVyc2RheSwgQXVndXN0IDA2LCAyMDE1IDY6MzcgQU08YnIgY2xhc3M9IiI+ DQo8YiBjbGFzcz0iIj5Ubzo8L2I+PHNwYW4gY2xhc3M9IiI+Jm5ic3A7PC9zcGFuPkNocmlzdGVy IEhvbG1iZXJnICZsdDs8YSBocmVmPSJtYWlsdG86Y2hyaXN0ZXIuaG9sbWJlcmdAZXJpY3Nzb24u Y29tIiB0YXJnZXQ9Il9ibGFuayIgY2xhc3M9IiI+Y2hyaXN0ZXIuaG9sbWJlcmdAZXJpY3Nzb24u Y29tPC9hPiZndDs7IEFzdmVyZW4sIFRvbGdhICZsdDs8YSBocmVmPSJtYWlsdG86dGFzdmVyZW5A c29udXNuZXQuY29tIiB0YXJnZXQ9Il9ibGFuayIgY2xhc3M9IiI+dGFzdmVyZW5Ac29udXNuZXQu Y29tPC9hPiZndDs7DQogU2Nod2FyeiwgQWxicmVjaHQgKEFsYnJlY2h0KSAmbHQ7PGEgaHJlZj0i bWFpbHRvOmFsYnJlY2h0LnNjaHdhcnpAYWxjYXRlbC1sdWNlbnQuY29tIiB0YXJnZXQ9Il9ibGFu ayIgY2xhc3M9IiI+YWxicmVjaHQuc2Nod2FyekBhbGNhdGVsLWx1Y2VudC5jb208L2E+Jmd0Ozsg Um9tYW4gU2hwb3VudCAmbHQ7PGEgaHJlZj0ibWFpbHRvOnJvbWFuQHRlbHVyaXguY29tIiB0YXJn ZXQ9Il9ibGFuayIgY2xhc3M9IiI+cm9tYW5AdGVsdXJpeC5jb208L2E+Jmd0OzsgUmF1c2NoZW5i YWNoLA0KIFV3ZSAoTm9raWEgLSBERS9NdW5pY2gpICZsdDs8YSBocmVmPSJtYWlsdG86dXdlLnJh dXNjaGVuYmFjaEBub2tpYS5jb20iIHRhcmdldD0iX2JsYW5rIiBjbGFzcz0iIj51d2UucmF1c2No ZW5iYWNoQG5va2lhLmNvbTwvYT4mZ3Q7PGJyIGNsYXNzPSIiPg0KPGIgY2xhc3M9IiI+Q2M6PC9i PjxzcGFuIGNsYXNzPSIiPiZuYnNwOzwvc3Bhbj4mbHQ7PGEgaHJlZj0ibWFpbHRvOnJ0Y3dlYkBp ZXRmLm9yZyIgdGFyZ2V0PSJfYmxhbmsiIGNsYXNzPSIiPnJ0Y3dlYkBpZXRmLm9yZzwvYT4mZ3Q7 ICZsdDs8YSBocmVmPSJtYWlsdG86cnRjd2ViQGlldGYub3JnIiB0YXJnZXQ9Il9ibGFuayIgY2xh c3M9IiI+cnRjd2ViQGlldGYub3JnPC9hPiZndDs8YnIgY2xhc3M9IiI+DQo8YiBjbGFzcz0iIj5T dWJqZWN0OjwvYj48c3BhbiBjbGFzcz0iIj4mbmJzcDs8L3NwYW4+UmU6IFtydGN3ZWJdIFdoYXQg dGhlIGdhdGV3YXkgZHJhZnQgc2hvdWxkIHNheSBhYm91dCBtdXgvbm9uLW11eDwvc3Bhbj48dSBj bGFzcz0iIj48L3U+PHUgY2xhc3M9IiI+PC91PjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4N CjxkaXYgY2xhc3M9IiI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4mbmJzcDs8dSBjbGFzcz0iIj48 L3U+PHUgY2xhc3M9IiI+PC91PjwvcD4NCjwvZGl2Pg0KPGRpdiBjbGFzcz0iIj4NCjxkaXYgY2xh c3M9IiI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0iYmFja2dyb3VuZDp3aGl0ZSI+PHNw YW4gc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZiIgY2xh c3M9IiI+V2h5IHNob3VsZG4ndCB0aGUgZ2F0ZXdheSBiZSByZXF1aXJlZCB0byBkbyB0aGUgbXV4 L2RlbXV4PyZuYnNwOyBNYWtpbmcgdGhlIFdlYlJUQyBlbmRwb2ludHMgYSBsb3QgbW9yZSBjb21w bGV4IGp1c3Qgc28gdGhlIGxlZ2FjeSBpbnRlcm9wIG1pZ2h0IHBvdGVudGlhbGx5IGJlDQogYSB0 ZWVueS10aW55IGJpdCBlYXNpZXIgbWFrZXMgbm8gc2Vuc2UgSU1ITy4mbmJzcDsgQWN0dWFsbHks IHRoZSBnYXRld2F5IHdvdWxkIG5vdCBiZSBhYmxlIHRvIGRvICZxdW90O2VuZC10by1lbmQmcXVv dDsgcGFzcy10aHJvdWdoIGFueXdheSBhcyBsZWdhY3kgZXF1aXBtZW50IHdpbGwgZWl0aGVyIGJl IHVuZW5jcnlwdGVkIG9yIHVzZSBTREVTIChSRkMjNDU2OCkgZm9yIGtleSBleGNoYW5nZS4mbmJz cDsgU28gdGhlIGdhdGV3YXkgd2lsbCBoYXZlIHRvIHBlcmZvcm0gRFRMUy1TUlRQDQogdG8gU0RF Uy1TUlRQIHRyYW5zY3J5cHRpb24tLXdoaWNoIGFscmVhZHkgaXMgd2F5IG1vcmUgaGFzc2xlIHRo YW4gUlRQL1JUQ1AgbXV4L2RlbXV4Ljwvc3Bhbj48dSBjbGFzcz0iIj48L3U+PHUgY2xhc3M9IiI+ PC91PjwvcD4NCjwvZGl2Pg0KPGRpdiBjbGFzcz0iIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0 eWxlPSJiYWNrZ3JvdW5kOndoaXRlIj48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7Q2Fs aWJyaSZxdW90OyxzYW5zLXNlcmlmIiBjbGFzcz0iIj4mbmJzcDs8L3NwYW4+PHUgY2xhc3M9IiI+ PC91Pjx1IGNsYXNzPSIiPjwvdT48L3A+DQo8L2Rpdj4NCjxkaXYgY2xhc3M9IiI+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIiBzdHlsZT0iYmFja2dyb3VuZDp3aGl0ZSI+PHNwYW4gc3R5bGU9ImZvbnQt ZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZiIgY2xhc3M9IiI+LS1GZWxpeDwv c3Bhbj48dSBjbGFzcz0iIj48L3U+PHUgY2xhc3M9IiI+PC91PjwvcD4NCjwvZGl2Pg0KPGRpdiBj bGFzcz0iIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJiYWNrZ3JvdW5kOndoaXRlIj48 c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmIiBj bGFzcz0iIj4mbmJzcDs8L3NwYW4+PHUgY2xhc3M9IiI+PC91Pjx1IGNsYXNzPSIiPjwvdT48L3A+ DQo8L2Rpdj4NCjxkaXYgY2xhc3M9IiI+DQo8ZGl2IGNsYXNzPSJNc29Ob3JtYWwiIGFsaWduPSJj ZW50ZXIiIHN0eWxlPSJ0ZXh0LWFsaWduOmNlbnRlcjtiYWNrZ3JvdW5kOndoaXRlIj4NCjxzcGFu IHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWYiIGNsYXNz PSIiPg0KPGhyIHNpemU9IjIiIHdpZHRoPSI5OCUiIGFsaWduPSJjZW50ZXIiIGNsYXNzPSIiPg0K PC9zcGFuPjwvZGl2Pg0KPGRpdiBjbGFzcz0iIj4NCjxkaXYgY2xhc3M9IiI+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIiBzdHlsZT0iYmFja2dyb3VuZDp3aGl0ZSI+PGIgY2xhc3M9IiI+PHNwYW4gc3R5 bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5z LXNlcmlmIiBjbGFzcz0iIj5Gcm9tOjwvc3Bhbj48L2I+PHNwYW4gY2xhc3M9IiI+PHNwYW4gc3R5 bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5z LXNlcmlmIiBjbGFzcz0iIj4mbmJzcDs8L3NwYW4+PC9zcGFuPjxzcGFuIHN0eWxlPSJmb250LXNp emU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZiIgY2xh c3M9IiI+cnRjd2ViDQogJmx0OzxhIGhyZWY9Im1haWx0bzpydGN3ZWItYm91bmNlc0BpZXRmLm9y ZyIgdGFyZ2V0PSJfYmxhbmsiIGNsYXNzPSIiPjxzcGFuIHN0eWxlPSJjb2xvcjpwdXJwbGUiIGNs YXNzPSIiPnJ0Y3dlYi1ib3VuY2VzQGlldGYub3JnPC9zcGFuPjwvYT4mZ3Q7IG9uIGJlaGFsZiBv ZiBDaHJpc3RlciBIb2xtYmVyZyAmbHQ7PGEgaHJlZj0ibWFpbHRvOmNocmlzdGVyLmhvbG1iZXJn QGVyaWNzc29uLmNvbSIgdGFyZ2V0PSJfYmxhbmsiIGNsYXNzPSIiPjxzcGFuIHN0eWxlPSJjb2xv cjpwdXJwbGUiIGNsYXNzPSIiPmNocmlzdGVyLmhvbG1iZXJnQGVyaWNzc29uLmNvbTwvc3Bhbj48 L2E+Jmd0OzxiciBjbGFzcz0iIj4NCjxiIGNsYXNzPSIiPlNlbnQ6PC9iPjxzcGFuIGNsYXNzPSIi PiZuYnNwOzwvc3Bhbj5UaHVyc2RheSwgQXVndXN0IDYsIDIwMTUgMDU6NTE8YnIgY2xhc3M9IiI+ DQo8YiBjbGFzcz0iIj5Ubzo8L2I+PHNwYW4gY2xhc3M9IiI+Jm5ic3A7PC9zcGFuPkFzdmVyZW4s IFRvbGdhOyBTY2h3YXJ6LCBBbGJyZWNodCAoQWxicmVjaHQpOyBSb21hbiBTaHBvdW50OyBSYXVz Y2hlbmJhY2gsIFV3ZSAoTm9raWEgLSBERS9NdW5pY2gpPGJyIGNsYXNzPSIiPg0KPGIgY2xhc3M9 IiI+Q2M6PC9iPjxzcGFuIGNsYXNzPSIiPiZuYnNwOzwvc3Bhbj4mbHQ7PGEgaHJlZj0ibWFpbHRv OnJ0Y3dlYkBpZXRmLm9yZyIgdGFyZ2V0PSJfYmxhbmsiIGNsYXNzPSIiPjxzcGFuIHN0eWxlPSJj b2xvcjpwdXJwbGUiIGNsYXNzPSIiPnJ0Y3dlYkBpZXRmLm9yZzwvc3Bhbj48L2E+Jmd0OzxiciBj bGFzcz0iIj4NCjxiIGNsYXNzPSIiPlN1YmplY3Q6PC9iPjxzcGFuIGNsYXNzPSIiPiZuYnNwOzwv c3Bhbj5SZTogW3J0Y3dlYl0gV2hhdCB0aGUgZ2F0ZXdheSBkcmFmdCBzaG91bGQgc2F5IGFib3V0 IG11eC9ub24tbXV4PC9zcGFuPjx1IGNsYXNzPSIiPjwvdT48dSBjbGFzcz0iIj48L3U+PC9wPg0K PC9kaXY+DQo8ZGl2IGNsYXNzPSIiPg0KPGRpdiBjbGFzcz0iIj4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiIHN0eWxlPSJiYWNrZ3JvdW5kOndoaXRlIj48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1 b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmIiBjbGFzcz0iIj4mbmJzcDs8L3NwYW4+PHUgY2xh c3M9IiI+PC91Pjx1IGNsYXNzPSIiPjwvdT48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8 ZGl2IGNsYXNzPSIiPg0KPGRpdiBjbGFzcz0iIj4NCjxkaXYgY2xhc3M9IiI+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIiBzdHlsZT0iYmFja2dyb3VuZDp3aGl0ZSI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6 ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9y OiMxZjQ5N2QiIGNsYXNzPSIiPkhpLDwvc3Bhbj48dSBjbGFzcz0iIj48L3U+PHUgY2xhc3M9IiI+ PC91PjwvcD4NCjwvZGl2Pg0KPGRpdiBjbGFzcz0iIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0 eWxlPSJiYWNrZ3JvdW5kOndoaXRlIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250 LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFmNDk3ZCIgY2xh c3M9IiI+Jm5ic3A7PC9zcGFuPjx1IGNsYXNzPSIiPjwvdT48dSBjbGFzcz0iIj48L3U+PC9wPg0K PC9kaXY+DQo8ZGl2IGNsYXNzPSIiPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9ImJhY2tn cm91bmQ6d2hpdGUiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZx dW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMWY0OTdkIiBjbGFzcz0iIj5ObyBt YXR0ZXIgd2hldGhlciB0aGUgZ2F0ZXdheSBzdXBwb3J0cyBSVFAvUlRDUCBtdXggb3Igbm90LCB0 aGVyZSBhcmUgY2FzZXMgd2hlcmUgdGhlIGxlZ2FjeSBuZXR3b3JrL2VuZHBvaW50cyB3aWxsIG5v dCB1c2UNCiBSVFAvUlRDUCBtdXgsIHNvIEkgZ3Vlc3MgcGVvcGxlIHRoZW4gd291bGQgd2FudCB0 byBiZSBhYmxlIHRvIG5lZ290aWF0ZSBub24tbXV4IOKAnGVuZC10by1lbmTigJ0sIHJhdGhlciB0 aGFuIGhhdmluZyB0aGUgZ2F0ZXdheSB0byBkZW11eC9tdXggUlRQIGFuZCBSVENQLjwvc3Bhbj48 dSBjbGFzcz0iIj48L3U+PHUgY2xhc3M9IiI+PC91PjwvcD4NCjwvZGl2Pg0KPGRpdiBjbGFzcz0i Ij4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJiYWNrZ3JvdW5kOndoaXRlIj48c3BhbiBz dHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNh bnMtc2VyaWY7Y29sb3I6IzFmNDk3ZCIgY2xhc3M9IiI+Jm5ic3A7PC9zcGFuPjx1IGNsYXNzPSIi PjwvdT48dSBjbGFzcz0iIj48L3U+PC9wPg0KPC9kaXY+DQo8ZGl2IGNsYXNzPSIiPg0KPHAgY2xh c3M9Ik1zb05vcm1hbCIgc3R5bGU9ImJhY2tncm91bmQ6d2hpdGUiPjxzcGFuIHN0eWxlPSJmb250 LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtj b2xvcjojMWY0OTdkIiBjbGFzcz0iIj5SZWdhcmRzLDwvc3Bhbj48dSBjbGFzcz0iIj48L3U+PHUg Y2xhc3M9IiI+PC91PjwvcD4NCjwvZGl2Pg0KPGRpdiBjbGFzcz0iIj4NCjxwIGNsYXNzPSJNc29O b3JtYWwiIHN0eWxlPSJiYWNrZ3JvdW5kOndoaXRlIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEx LjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFm NDk3ZCIgY2xhc3M9IiI+Jm5ic3A7PC9zcGFuPjx1IGNsYXNzPSIiPjwvdT48dSBjbGFzcz0iIj48 L3U+PC9wPg0KPC9kaXY+DQo8ZGl2IGNsYXNzPSIiPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5 bGU9ImJhY2tncm91bmQ6d2hpdGUiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQt ZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMWY0OTdkIiBjbGFz cz0iIj5DaHJpc3Rlcjwvc3Bhbj48dSBjbGFzcz0iIj48L3U+PHUgY2xhc3M9IiI+PC91PjwvcD4N CjwvZGl2Pg0KPGRpdiBjbGFzcz0iIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJiYWNr Z3JvdW5kOndoaXRlIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTom cXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFmNDk3ZCIgY2xhc3M9IiI+Jm5i c3A7PC9zcGFuPjx1IGNsYXNzPSIiPjwvdT48dSBjbGFzcz0iIj48L3U+PC9wPg0KPC9kaXY+DQo8 ZGl2IGNsYXNzPSIiPg0KPGRpdiBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLXRvcDpzb2xpZCAj YjVjNGRmIDEuMHB0O3BhZGRpbmc6My4wcHQgMGluIDBpbiAwaW4iIGNsYXNzPSIiPg0KPGRpdiBj bGFzcz0iIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJiYWNrZ3JvdW5kOndoaXRlIj48 YiBjbGFzcz0iIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVv dDtUYWhvbWEmcXVvdDssc2Fucy1zZXJpZiIgY2xhc3M9IiI+RnJvbTo8L3NwYW4+PC9iPjxzcGFu IGNsYXNzPSIiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90 O1RhaG9tYSZxdW90OyxzYW5zLXNlcmlmIiBjbGFzcz0iIj4mbmJzcDs8L3NwYW4+PC9zcGFuPjxz cGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O1RhaG9tYSZxdW90 OyxzYW5zLXNlcmlmIiBjbGFzcz0iIj5Bc3ZlcmVuLA0KIFRvbGdhIFs8YSBocmVmPSJtYWlsdG86 dGFzdmVyZW5Ac29udXNuZXQuY29tIiB0YXJnZXQ9Il9ibGFuayIgY2xhc3M9IiI+PHNwYW4gc3R5 bGU9ImNvbG9yOnB1cnBsZSIgY2xhc3M9IiI+bWFpbHRvOnRhc3ZlcmVuQHNvbnVzbmV0LmNvbTwv c3Bhbj48L2E+XTxzcGFuIGNsYXNzPSIiPiZuYnNwOzwvc3Bhbj48YnIgY2xhc3M9IiI+DQo8YiBj bGFzcz0iIj5TZW50OjwvYj48c3BhbiBjbGFzcz0iIj4mbmJzcDs8L3NwYW4+Ni4gZWxva3V1dGEg MjAxNSAxMjoxODxiciBjbGFzcz0iIj4NCjxiIGNsYXNzPSIiPlRvOjwvYj48c3BhbiBjbGFzcz0i Ij4mbmJzcDs8L3NwYW4+U2Nod2FyeiwgQWxicmVjaHQgKEFsYnJlY2h0KTsgUm9tYW4gU2hwb3Vu dDsgUmF1c2NoZW5iYWNoLCBVd2UgKE5va2lhIC0gREUvTXVuaWNoKTxiciBjbGFzcz0iIj4NCjxi IGNsYXNzPSIiPkNjOjwvYj48c3BhbiBjbGFzcz0iIj4mbmJzcDs8L3NwYW4+ZXh0IEVyaWMgUmVz Y29ybGE7IENocmlzdGVyIEhvbG1iZXJnOyBCZXJuYXJkIEFib2JhOyAmbHQ7PGEgaHJlZj0ibWFp bHRvOnJ0Y3dlYkBpZXRmLm9yZyIgdGFyZ2V0PSJfYmxhbmsiIGNsYXNzPSIiPjxzcGFuIHN0eWxl PSJjb2xvcjpwdXJwbGUiIGNsYXNzPSIiPnJ0Y3dlYkBpZXRmLm9yZzwvc3Bhbj48L2E+Jmd0Ozxi ciBjbGFzcz0iIj4NCjxiIGNsYXNzPSIiPlN1YmplY3Q6PC9iPjxzcGFuIGNsYXNzPSIiPiZuYnNw Ozwvc3Bhbj5SZTogW3J0Y3dlYl0gV2hhdCB0aGUgZ2F0ZXdheSBkcmFmdCBzaG91bGQgc2F5IGFi b3V0IG11eC9ub24tbXV4PC9zcGFuPjx1IGNsYXNzPSIiPjwvdT48dSBjbGFzcz0iIj48L3U+PC9w Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdiBjbGFzcz0iIj4NCjxwIGNsYXNzPSJNc29O b3JtYWwiIHN0eWxlPSJiYWNrZ3JvdW5kOndoaXRlIj4mbmJzcDs8dSBjbGFzcz0iIj48L3U+PHUg Y2xhc3M9IiI+PC91PjwvcD4NCjwvZGl2Pg0KPGRpdiBjbGFzcz0iIj4NCjxkaXYgY2xhc3M9IiI+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0iYmFja2dyb3VuZDp3aGl0ZSI+PHNwYW4gc3R5 bGU9ImZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZiIgY2xhc3M9IiI+ V2h5IHNob3VsZCB3ZSBjb25zaWRlciAzR1BQIHRoZSBzb2xlICZxdW90O293bmVyL3VzZXImcXVv dDsgb2YgdGhlIHRlcm0vZW50aXR5IFdlYlJUQy1HVz8gSSB0aGluayBpdCBoYXMgYSBtdWNoIG1v cmUgZ2VuZXJhbCBtZWFuaW5nIGFuZCB1c2UgaW4gcHJhY3RpY2UuIEl0IGNhbiByZWZlcg0KIHRv IG1hbnkgZGlmZmVyZW50IHR5cGVzIG9mIGVsZW1lbnRzIHdoaWNoIGNhbiBiZSBkZXBsb3llZCBp biBtYW55IGRpZmZlcmVudCBlbnZpcm9ubWVudHMsIGhlbmNlIGFueSBhdHRlbXB0IHRvIGRlZmlu ZSBpdCBzdHJpY3RseS9yZXN0cmljdCBpdHMgY2FwYWJpbGl0aWVzIGFyZSBmdXRpbGUgSU1ITy48 L3NwYW4+PHUgY2xhc3M9IiI+PC91Pjx1IGNsYXNzPSIiPjwvdT48L3A+DQo8L2Rpdj4NCjxkaXYg Y2xhc3M9IiI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0iYmFja2dyb3VuZDp3aGl0ZSI+ PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZiIg Y2xhc3M9IiI+Jm5ic3A7PC9zcGFuPjx1IGNsYXNzPSIiPjwvdT48dSBjbGFzcz0iIj48L3U+PC9w Pg0KPC9kaXY+DQo8ZGl2IGNsYXNzPSIiPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9ImJh Y2tncm91bmQ6d2hpdGUiPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1 b3Q7LHNhbnMtc2VyaWYiIGNsYXNzPSIiPlRoYW5rcyw8L3NwYW4+PHUgY2xhc3M9IiI+PC91Pjx1 IGNsYXNzPSIiPjwvdT48L3A+DQo8L2Rpdj4NCjxkaXYgY2xhc3M9IiI+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIiBzdHlsZT0iYmFja2dyb3VuZDp3aGl0ZSI+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5 OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZiIgY2xhc3M9IiI+VG9sZ2E8L3NwYW4+PHUg Y2xhc3M9IiI+PC91Pjx1IGNsYXNzPSIiPjwvdT48L3A+DQo8L2Rpdj4NCjxkaXYgY2xhc3M9IiI+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0iYmFja2dyb3VuZDp3aGl0ZSI+PHNwYW4gc3R5 bGU9ImZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZiIgY2xhc3M9IiI+ Jm5ic3A7PC9zcGFuPjx1IGNsYXNzPSIiPjwvdT48dSBjbGFzcz0iIj48L3U+PC9wPg0KPC9kaXY+ DQo8ZGl2IGNsYXNzPSIiPg0KPGRpdiBjbGFzcz0iTXNvTm9ybWFsIiBhbGlnbj0iY2VudGVyIiBz dHlsZT0idGV4dC1hbGlnbjpjZW50ZXI7YmFja2dyb3VuZDp3aGl0ZSI+DQo8c3BhbiBzdHlsZT0i Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmIiBjbGFzcz0iIj4NCjxo ciBzaXplPSIyIiB3aWR0aD0iOTglIiBhbGlnbj0iY2VudGVyIiBjbGFzcz0iIj4NCjwvc3Bhbj48 L2Rpdj4NCjxkaXYgY2xhc3M9IiI+DQo8ZGl2IGNsYXNzPSIiPg0KPHAgY2xhc3M9Ik1zb05vcm1h bCIgc3R5bGU9ImJhY2tncm91bmQ6d2hpdGUiPjxiIGNsYXNzPSIiPjxzcGFuIHN0eWxlPSJmb250 LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZiIg Y2xhc3M9IiI+RnJvbTo8L3NwYW4+PC9iPjxzcGFuIGNsYXNzPSIiPjxzcGFuIHN0eWxlPSJmb250 LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZiIg Y2xhc3M9IiI+Jm5ic3A7PC9zcGFuPjwvc3Bhbj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBw dDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWYiIGNsYXNzPSIiPlNj aHdhcnosDQogQWxicmVjaHQgKEFsYnJlY2h0KSAmbHQ7PGEgaHJlZj0ibWFpbHRvOmFsYnJlY2h0 LnNjaHdhcnpAYWxjYXRlbC1sdWNlbnQuY29tIiB0YXJnZXQ9Il9ibGFuayIgY2xhc3M9IiI+PHNw YW4gc3R5bGU9ImNvbG9yOnB1cnBsZSIgY2xhc3M9IiI+YWxicmVjaHQuc2Nod2FyekBhbGNhdGVs LWx1Y2VudC5jb208L3NwYW4+PC9hPiZndDs8YnIgY2xhc3M9IiI+DQo8YiBjbGFzcz0iIj5TZW50 OjwvYj48c3BhbiBjbGFzcz0iIj4mbmJzcDs8L3NwYW4+VGh1cnNkYXksIEF1Z3VzdCA2LCAyMDE1 IDI6NDQgQU08YnIgY2xhc3M9IiI+DQo8YiBjbGFzcz0iIj5Ubzo8L2I+PHNwYW4gY2xhc3M9IiI+ Jm5ic3A7PC9zcGFuPkFzdmVyZW4sIFRvbGdhOyBSb21hbiBTaHBvdW50OyBSYXVzY2hlbmJhY2gs IFV3ZSAoTm9raWEgLSBERS9NdW5pY2gpPGJyIGNsYXNzPSIiPg0KPGIgY2xhc3M9IiI+Q2M6PC9i PjxzcGFuIGNsYXNzPSIiPiZuYnNwOzwvc3Bhbj5leHQgRXJpYyBSZXNjb3JsYTsgQ2hyaXN0ZXIg SG9sbWJlcmc7IEJlcm5hcmQgQWJvYmE7ICZsdDs8YSBocmVmPSJtYWlsdG86cnRjd2ViQGlldGYu b3JnIiB0YXJnZXQ9Il9ibGFuayIgY2xhc3M9IiI+PHNwYW4gc3R5bGU9ImNvbG9yOnB1cnBsZSIg Y2xhc3M9IiI+cnRjd2ViQGlldGYub3JnPC9zcGFuPjwvYT4mZ3Q7PGJyIGNsYXNzPSIiPg0KPGIg Y2xhc3M9IiI+U3ViamVjdDo8L2I+PHNwYW4gY2xhc3M9IiI+Jm5ic3A7PC9zcGFuPlJFOiBbcnRj d2ViXSBXaGF0IHRoZSBnYXRld2F5IGRyYWZ0IHNob3VsZCBzYXkgYWJvdXQgbXV4L25vbi1tdXg8 L3NwYW4+PHUgY2xhc3M9IiI+PC91Pjx1IGNsYXNzPSIiPjwvdT48L3A+DQo8L2Rpdj4NCjxkaXYg Y2xhc3M9IiI+DQo8ZGl2IGNsYXNzPSIiPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9ImJh Y2tncm91bmQ6d2hpdGUiPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1 b3Q7LHNhbnMtc2VyaWYiIGNsYXNzPSIiPiZuYnNwOzwvc3Bhbj48dSBjbGFzcz0iIj48L3U+PHUg Y2xhc3M9IiI+PC91PjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXYgY2xhc3M9IiI+ DQo8ZGl2IGNsYXNzPSIiPg0KPGRpdiBjbGFzcz0iIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0 eWxlPSJiYWNrZ3JvdW5kOndoaXRlIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250 LWZhbWlseTpDb25zb2xhcztjb2xvcjojMWY0OTdkIiBjbGFzcz0iIj5UaGUgY29uY2VybmVkIDNH UFAgV2ViUlRDIGdhdGV3YXkgKDNHUFAgMjMuMzM0LzI5LjMzNCkgc3VwcG9ydHMgYWxyZWFkeSBS VFAvUlRDUCB0cmFuc3BvcnQgbXVsdGlwbGV4aW5nIChzaW5jZSAzR1BQIFJlbGVhc2UgMTIpLCBp LmUuIHNob3VsZA0KIG5vdCBiZSB0aGUgbGltaXRpbmcgZmFjdG9yIGluIHRoaXMgZGlzY3Vzc2lv bi48c3BhbiBjbGFzcz0iIj4mbmJzcDs8L3NwYW4+PC9zcGFuPjx1IGNsYXNzPSIiPjwvdT48dSBj bGFzcz0iIj48L3U+PC9wPg0KPC9kaXY+DQo8ZGl2IGNsYXNzPSIiPg0KPHAgY2xhc3M9Ik1zb05v cm1hbCIgc3R5bGU9ImJhY2tncm91bmQ6d2hpdGUiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEu MHB0O2ZvbnQtZmFtaWx5OkNvbnNvbGFzO2NvbG9yOiMxZjQ5N2QiIGNsYXNzPSIiPkZvciBvbmVz IGludGVyZXN0ZWQgaW4gdGhlIFJUQ1AgcG9ydCBhbGxvY2F0aW9uIHJ1bGVzLCBzZWUgSC4yNDgu NTc6PC9zcGFuPjx1IGNsYXNzPSIiPjwvdT48dSBjbGFzcz0iIj48L3U+PC9wPg0KPC9kaXY+DQo8 ZGl2IGNsYXNzPSIiPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9ImJhY2tncm91bmQ6d2hp dGUiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OkNvbnNvbGFzO2Nv bG9yOiMxZjQ5N2QiIGNsYXNzPSIiPjxhIGhyZWY9Imh0dHBzOi8vd3d3Lml0dS5pbnQvcmVjL2Rv bG9naW5fcHViLmFzcD9sYW5nPWUmYW1wO2lkPVQtUkVDLUguMjQ4LjU3LTIwMTQxMC1JISFQREYt RSZhbXA7dHlwZT1pdGVtcyIgdGl0bGU9IkNtZCYjNDM7Q2xpY2sgb3IgdGFwIHRvIGZvbGxvdyB0 aGUgbGluayIgdGFyZ2V0PSJfYmxhbmsiIGNsYXNzPSIiPjxzcGFuIHN0eWxlPSJjb2xvcjpwdXJw bGUiIGNsYXNzPSIiPmh0dHBzOi8vd3d3Lml0dS5pbnQvcmVjL2RvbG9naW5fcHViLmFzcD9sYW5n PWUmYW1wO2lkPVQtUkVDLUguMjQ4LjU3LTIwMTQxMC1JISFQREYtRSZhbXA7dHlwZT1pdGVtczwv c3Bhbj48L2E+PC9zcGFuPjx1IGNsYXNzPSIiPjwvdT48dSBjbGFzcz0iIj48L3U+PC9wPg0KPC9k aXY+DQo8ZGl2IGNsYXNzPSIiPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9ImJhY2tncm91 bmQ6d2hpdGUiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OkNvbnNv bGFzO2NvbG9yOiMxZjQ5N2QiIGNsYXNzPSIiPkNsYXVzZSA3IGRlc2NyaWJlcyBSVFAvUlRDUCB0 cmFuc3BvcnQgbXVsdGlwbGV4aW5nLiBJVFUtVCBILjI0OC41NyBpcyBhbHJlYWR5IHN1cHBvcnRl ZCBieSAzR1BQIDI5LjMzNC48L3NwYW4+PHUgY2xhc3M9IiI+PC91Pjx1IGNsYXNzPSIiPjwvdT48 L3A+DQo8L2Rpdj4NCjxkaXYgY2xhc3M9IiI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0i YmFja2dyb3VuZDp3aGl0ZSI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1p bHk6Q29uc29sYXM7Y29sb3I6IzFmNDk3ZCIgY2xhc3M9IiI+Jm5ic3A7PC9zcGFuPjx1IGNsYXNz PSIiPjwvdT48dSBjbGFzcz0iIj48L3U+PC9wPg0KPC9kaXY+DQo8ZGl2IGNsYXNzPSIiPg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9ImJhY2tncm91bmQ6d2hpdGUiPjxzcGFuIHN0eWxlPSJm b250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OkNvbnNvbGFzO2NvbG9yOiMxZjQ5N2QiIGNsYXNz PSIiPlRoZSByYXRpb25hbGUgYmVoaW5kIHRoZSDigJxvcHRpb25hbCB0YWdnaW5n4oCdIGJ5IDIz LjIyOCBpcyBhIHRoaXJkIHJlYXNvbiwgYmV5b25kPC9zcGFuPjx1IGNsYXNzPSIiPjwvdT48dSBj bGFzcz0iIj48L3U+PC9wPg0KPC9kaXY+DQo8ZGl2IGNsYXNzPSIiPg0KPHAgY2xhc3M9Ik1zb05v cm1hbCIgc3R5bGU9ImJhY2tncm91bmQ6d2hpdGUiPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTom cXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWYiIGNsYXNzPSIiPiZndDsxLiBVc2luZyBkaWZm ZXJlbnQgUU9TIHNldHRpbmdzIGZvciBSVENQIHZzIFJUUDwvc3Bhbj48dSBjbGFzcz0iIj48L3U+ PHUgY2xhc3M9IiI+PC91PjwvcD4NCjwvZGl2Pg0KPGRpdiBjbGFzcz0iIj4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiIHN0eWxlPSJiYWNrZ3JvdW5kOndoaXRlIj48c3BhbiBzdHlsZT0iZm9udC1mYW1p bHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmIiBjbGFzcz0iIj4mZ3Q7Mi4gU2VuZGlu ZyBSVENQIHRvIGEgZGlmZmVyZW50IGRldmljZSBmcm9tIFJUUDwvc3Bhbj48dSBjbGFzcz0iIj48 L3U+PHUgY2xhc3M9IiI+PC91PjwvcD4NCjwvZGl2Pg0KPGRpdiBjbGFzcz0iIj4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiIHN0eWxlPSJiYWNrZ3JvdW5kOndoaXRlIj48c3BhbiBzdHlsZT0iZm9udC1z aXplOjExLjBwdDtmb250LWZhbWlseTpDb25zb2xhcztjb2xvcjojMWY0OTdkIiBjbGFzcz0iIj4m bmJzcDs8L3NwYW4+PHUgY2xhc3M9IiI+PC91Pjx1IGNsYXNzPSIiPjwvdT48L3A+DQo8L2Rpdj4N CjxkaXYgY2xhc3M9IiI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0iYmFja2dyb3VuZDp3 aGl0ZSI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6Q29uc29sYXM7 Y29sb3I6IzFmNDk3ZCIgY2xhc3M9IiI+RG9u4oCZdCB3YW50IHRvIGdvIGluIHRoZSAzR1BQIHNw ZWNpZmljIGRldGFpbHMsIGJ1dCBpdCBoYXMgbm90aGluZyB0byBkbyB3aXRoIHRoZSAzR1BQIFVF LWVtYmVkZGVkIFdlYlJUQyBjbGllbnQgbm9yIGFueSBjb25zdHJhaW50cyBieSAzR1BQDQogV2Vi UlRDIGdhdGV3YXlzLjwvc3Bhbj48dSBjbGFzcz0iIj48L3U+PHUgY2xhc3M9IiI+PC91PjwvcD4N CjwvZGl2Pg0KPGRpdiBjbGFzcz0iIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJiYWNr Z3JvdW5kOndoaXRlIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTpD b25zb2xhcztjb2xvcjojMWY0OTdkIiBjbGFzcz0iIj4mbmJzcDs8L3NwYW4+PHUgY2xhc3M9IiI+ PC91Pjx1IGNsYXNzPSIiPjwvdT48L3A+DQo8L2Rpdj4NCjxkaXYgY2xhc3M9IiI+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIiBzdHlsZT0iYmFja2dyb3VuZDp3aGl0ZSI+PHNwYW4gc3R5bGU9ImZvbnQt c2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6Q29uc29sYXM7Y29sb3I6IzFmNDk3ZCIgY2xhc3M9IiI+ VGh1cywgYSBXZWJSVEMgZ2F0ZXdheSBNVVNUIHN1cHBvcnQgUlRQL1JUQ1AgdHJhbnNwb3J0IG11 bHRpcGxleGluZyBkdWUgdG8gaXRzIHB1cnBvc2UgaW4gaW50ZXJ3b3JraW5nIHN1cHBvcnQuPC9z cGFuPjx1IGNsYXNzPSIiPjwvdT48dSBjbGFzcz0iIj48L3U+PC9wPg0KPC9kaXY+DQo8ZGl2IGNs YXNzPSIiPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9ImJhY2tncm91bmQ6d2hpdGUiPjxz cGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OkNvbnNvbGFzO2NvbG9yOiMx ZjQ5N2QiIGNsYXNzPSIiPiZuYnNwOzwvc3Bhbj48dSBjbGFzcz0iIj48L3U+PHUgY2xhc3M9IiI+ PC91PjwvcD4NCjwvZGl2Pg0KPGRpdiBjbGFzcz0iIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0 eWxlPSJiYWNrZ3JvdW5kOndoaXRlIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250 LWZhbWlseTpDb25zb2xhcztjb2xvcjojMWY0OTdkIiBjbGFzcz0iIj5SZWdhcmRzLDwvc3Bhbj48 dSBjbGFzcz0iIj48L3U+PHUgY2xhc3M9IiI+PC91PjwvcD4NCjwvZGl2Pg0KPGRpdiBjbGFzcz0i Ij4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJiYWNrZ3JvdW5kOndoaXRlIj48c3BhbiBz dHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTpDb25zb2xhcztjb2xvcjojMWY0OTdk IiBjbGFzcz0iIj5BbGJyZWNodDwvc3Bhbj48dSBjbGFzcz0iIj48L3U+PHUgY2xhc3M9IiI+PC91 PjwvcD4NCjwvZGl2Pg0KPGRpdiBjbGFzcz0iIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxl PSJiYWNrZ3JvdW5kOndoaXRlIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZh bWlseTpDb25zb2xhcztjb2xvcjojMWY0OTdkIiBjbGFzcz0iIj4mbmJzcDs8L3NwYW4+PHUgY2xh c3M9IiI+PC91Pjx1IGNsYXNzPSIiPjwvdT48L3A+DQo8L2Rpdj4NCjxkaXYgY2xhc3M9IiI+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0iYmFja2dyb3VuZDp3aGl0ZSI+PHNwYW4gc3R5bGU9 ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNl cmlmO2NvbG9yOiMxZjQ5N2QiIGNsYXNzPSIiPiZuYnNwOzwvc3Bhbj48dSBjbGFzcz0iIj48L3U+ PHUgY2xhc3M9IiI+PC91PjwvcD4NCjwvZGl2Pg0KPGRpdiBjbGFzcz0iIj4NCjxkaXYgc3R5bGU9 ImJvcmRlcjpub25lO2JvcmRlci10b3A6c29saWQgI2I1YzRkZiAxLjBwdDtwYWRkaW5nOjMuMHB0 IDBpbiAwaW4gMGluIiBjbGFzcz0iIj4NCjxkaXYgY2xhc3M9IiI+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIiBzdHlsZT0iYmFja2dyb3VuZDp3aGl0ZSI+PGIgY2xhc3M9IiI+PHNwYW4gc3R5bGU9ImZv bnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7VGFob21hJnF1b3Q7LHNhbnMtc2VyaWYi IGNsYXNzPSIiPkZyb206PC9zcGFuPjwvYj48c3BhbiBjbGFzcz0iIj48c3BhbiBzdHlsZT0iZm9u dC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtUYWhvbWEmcXVvdDssc2Fucy1zZXJpZiIg Y2xhc3M9IiI+Jm5ic3A7PC9zcGFuPjwvc3Bhbj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBw dDtmb250LWZhbWlseTomcXVvdDtUYWhvbWEmcXVvdDssc2Fucy1zZXJpZiIgY2xhc3M9IiI+QXN2 ZXJlbiwNCiBUb2xnYSBbPGEgaHJlZj0ibWFpbHRvOnRhc3ZlcmVuQHNvbnVzbmV0LmNvbSIgdGFy Z2V0PSJfYmxhbmsiIGNsYXNzPSIiPjxzcGFuIHN0eWxlPSJjb2xvcjpwdXJwbGUiIGNsYXNzPSIi Pm1haWx0bzp0YXN2ZXJlbkBzb251c25ldC5jb208L3NwYW4+PC9hPl08c3BhbiBjbGFzcz0iIj4m bmJzcDs8L3NwYW4+PGJyIGNsYXNzPSIiPg0KPGIgY2xhc3M9IiI+U2VudDo8L2I+PHNwYW4gY2xh c3M9IiI+Jm5ic3A7PC9zcGFuPk1pdHR3b2NoLCA1LiBBdWd1c3QgMjAxNSAxOTo0NzxiciBjbGFz cz0iIj4NCjxiIGNsYXNzPSIiPlRvOjwvYj48c3BhbiBjbGFzcz0iIj4mbmJzcDs8L3NwYW4+Um9t YW4gU2hwb3VudDsgUmF1c2NoZW5iYWNoLCBVd2UgKE5va2lhIC0gREUvTXVuaWNoKTxiciBjbGFz cz0iIj4NCjxiIGNsYXNzPSIiPkNjOjwvYj48c3BhbiBjbGFzcz0iIj4mbmJzcDs8L3NwYW4+ZXh0 IEVyaWMgUmVzY29ybGE7IFNjaHdhcnosIEFsYnJlY2h0IChBbGJyZWNodCk7IENocmlzdGVyIEhv bG1iZXJnOyBCZXJuYXJkIEFib2JhOyAmbHQ7PGEgaHJlZj0ibWFpbHRvOnJ0Y3dlYkBpZXRmLm9y ZyIgdGFyZ2V0PSJfYmxhbmsiIGNsYXNzPSIiPjxzcGFuIHN0eWxlPSJjb2xvcjpwdXJwbGUiIGNs YXNzPSIiPnJ0Y3dlYkBpZXRmLm9yZzwvc3Bhbj48L2E+Jmd0OzxiciBjbGFzcz0iIj4NCjxiIGNs YXNzPSIiPlN1YmplY3Q6PC9iPjxzcGFuIGNsYXNzPSIiPiZuYnNwOzwvc3Bhbj5SRTogW3J0Y3dl Yl0gV2hhdCB0aGUgZ2F0ZXdheSBkcmFmdCBzaG91bGQgc2F5IGFib3V0IG11eC9ub24tbXV4PC9z cGFuPjx1IGNsYXNzPSIiPjwvdT48dSBjbGFzcz0iIj48L3U+PC9wPg0KPC9kaXY+DQo8L2Rpdj4N CjwvZGl2Pg0KPGRpdiBjbGFzcz0iIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJiYWNr Z3JvdW5kOndoaXRlIj48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90 OyxzYW5zLXNlcmlmIiBjbGFzcz0iIj4mbmJzcDs8L3NwYW4+PHUgY2xhc3M9IiI+PC91Pjx1IGNs YXNzPSIiPjwvdT48L3A+DQo8L2Rpdj4NCjxkaXYgY2xhc3M9IiI+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIiBzdHlsZT0iYmFja2dyb3VuZDp3aGl0ZSI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4w cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxZjQ5 N2QiIGNsYXNzPSIiPmktIEkgaHVtYmx5IGRpc2FncmVlIHRoYXQgdXNpbmcgZGlmZmVyZW50IFFv UyBSVENQL1JUUCwgZS5nLiBkaWZmZXJlbnQgRGlmZlNlcnYgdmFsdWVzICwgc2hvdWxkIGJlIGRp c21pc3NlZC48L3NwYW4+PHUgY2xhc3M9IiI+PC91Pjx1IGNsYXNzPSIiPjwvdT48L3A+DQo8L2Rp dj4NCjxkaXYgY2xhc3M9IiI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0iYmFja2dyb3Vu ZDp3aGl0ZSI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7 Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxZjQ5N2QiIGNsYXNzPSIiPmlpLSBMZXQg bWUgYWxzbyBhZGQgYW5vdGhlciByZWFzb24gd2h5IG5vLXJ0Y3AtbXV4IG1heSBiZSBuZWVkZWQ6 IEltcGxlbWVudGF0aW9uIGRpZmZpY3VsdGllcyBpbiBjZXJ0YWluIEdXcy48L3NwYW4+PHUgY2xh c3M9IiI+PC91Pjx1IGNsYXNzPSIiPjwvdT48L3A+DQo8L2Rpdj4NCjxkaXYgY2xhc3M9IiI+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0iYmFja2dyb3VuZDp3aGl0ZSI+PHNwYW4gc3R5bGU9 ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNl cmlmO2NvbG9yOiMxZjQ5N2QiIGNsYXNzPSIiPiZuYnNwOzwvc3Bhbj48dSBjbGFzcz0iIj48L3U+ PHUgY2xhc3M9IiI+PC91PjwvcD4NCjwvZGl2Pg0KPGRpdiBjbGFzcz0iIj4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiIHN0eWxlPSJiYWNrZ3JvdW5kOndoaXRlIj48c3BhbiBzdHlsZT0iZm9udC1zaXpl OjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6 IzFmNDk3ZCIgY2xhc3M9IiI+Q29uc2lkZXJpbmcgdGhhdCB0aGVyZSBpcyBhbHJlYWR5IGEgbmVn b3RpYXRpb24gbWVjaGFuaXNtIGZvciBydGNwLW11eCBzdXBwb3J0LCB0aGF0IGl0IGNhbiBiZSBk ZS1mYWN0byBtYW5kYXRlZCBieSB0aGUgY2hvaWNlDQogb2YgYnJvd3NlcnMgZm9yIEludGVybmV0 LCBJIHRoaW5rIHdoYXQgQ2hyaXN0ZXIvQWxicmVjaHQgc3VnZ2VzdGVkIGlzIHRoZSByaWdodCB3 YXkgdG8gbW92ZSBmb3J3YXJkOiBwcm92aWRlIGNsYXJpZmljYXRpb25zIGZvciB2YWd1ZSBwb2lu dHMuIEkgZG9u4oCZdCB1bmRlcnN0YW5kIHdoeSBsYWNrIG9mIGNsYXJpdHkgaW4gZXhpc3Rpbmcg c3BlY2lmaWNhdGlvbnMgc2hvdWxkIGNhdXNlIGltcG9zaW5nIHJlc3RyaWN0aW9ucy4gVGhpcyB3 b3VsZCBiZQ0KIGFraW4gdG8gZHJvcHBpbmcgYSBmZWF0dXJlIGR1ZSB0byBhIGJ1Zy4gSW4gdGhp cyBjYXNlLCB0aGUg4oCcYnVn4oCdIGlzIGxhY2sgb2YgY2xhcml0eSBpbiBub3JtYXRpdmUgc3Bl Y2lmaWNhdGlvbnMgYW5kIGl0IGNhbiBiZSBhZGRyZXNzZWQgYnkgZnVydGhlciBzcGVjaWZpY2F0 aW9uLjwvc3Bhbj48dSBjbGFzcz0iIj48L3U+PHUgY2xhc3M9IiI+PC91PjwvcD4NCjwvZGl2Pg0K PGRpdiBjbGFzcz0iIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJiYWNrZ3JvdW5kOndo aXRlIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxp YnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFmNDk3ZCIgY2xhc3M9IiI+Jm5ic3A7PC9zcGFu Pjx1IGNsYXNzPSIiPjwvdT48dSBjbGFzcz0iIj48L3U+PC9wPg0KPC9kaXY+DQo8ZGl2IGNsYXNz PSIiPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9ImJhY2tncm91bmQ6d2hpdGUiPjxzcGFu IHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDss c2Fucy1zZXJpZjtjb2xvcjojMWY0OTdkIiBjbGFzcz0iIj5UaGFua3MsPC9zcGFuPjx1IGNsYXNz PSIiPjwvdT48dSBjbGFzcz0iIj48L3U+PC9wPg0KPC9kaXY+DQo8ZGl2IGNsYXNzPSIiPg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9ImJhY2tncm91bmQ6d2hpdGUiPjxzcGFuIHN0eWxlPSJm b250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJp Zjtjb2xvcjojMWY0OTdkIiBjbGFzcz0iIj5Ub2xnYTwvc3Bhbj48dSBjbGFzcz0iIj48L3U+PHUg Y2xhc3M9IiI+PC91PjwvcD4NCjwvZGl2Pg0KPGRpdiBjbGFzcz0iIj4NCjxwIGNsYXNzPSJNc29O b3JtYWwiIHN0eWxlPSJiYWNrZ3JvdW5kOndoaXRlIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEx LjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFm NDk3ZCIgY2xhc3M9IiI+Jm5ic3A7PC9zcGFuPjx1IGNsYXNzPSIiPjwvdT48dSBjbGFzcz0iIj48 L3U+PC9wPg0KPC9kaXY+DQo8ZGl2IHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItbGVmdDpzb2xp ZCBibHVlIDEuNXB0O3BhZGRpbmc6MGluIDBpbiAwaW4gNC4wcHQiIGNsYXNzPSIiPg0KPGRpdiBj bGFzcz0iIj4NCjxkaXYgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci10b3A6c29saWQgI2UxZTFl MSAxLjBwdDtwYWRkaW5nOjMuMHB0IDBpbiAwaW4gMGluIiBjbGFzcz0iIj4NCjxkaXYgY2xhc3M9 IiI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0iYmFja2dyb3VuZDp3aGl0ZSI+PGIgY2xh c3M9IiI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2Fs aWJyaSZxdW90OyxzYW5zLXNlcmlmIiBjbGFzcz0iIj5Gcm9tOjwvc3Bhbj48L2I+PHNwYW4gY2xh c3M9IiI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2Fs aWJyaSZxdW90OyxzYW5zLXNlcmlmIiBjbGFzcz0iIj4mbmJzcDs8L3NwYW4+PC9zcGFuPjxzcGFu IHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDss c2Fucy1zZXJpZiIgY2xhc3M9IiI+Um9tYW4NCiBTaHBvdW50IFs8YSBocmVmPSJtYWlsdG86cm9t YW5AdGVsdXJpeC5jb20iIHRhcmdldD0iX2JsYW5rIiBjbGFzcz0iIj48c3BhbiBzdHlsZT0iY29s b3I6cHVycGxlIiBjbGFzcz0iIj5tYWlsdG86cm9tYW5AdGVsdXJpeC5jb208L3NwYW4+PC9hPl08 c3BhbiBjbGFzcz0iIj4mbmJzcDs8L3NwYW4+PGJyIGNsYXNzPSIiPg0KPGIgY2xhc3M9IiI+U2Vu dDo8L2I+PHNwYW4gY2xhc3M9IiI+Jm5ic3A7PC9zcGFuPldlZG5lc2RheSwgQXVndXN0IDA1LCAy MDE1IDEyOjI5IFBNPGJyIGNsYXNzPSIiPg0KPGIgY2xhc3M9IiI+VG86PC9iPjxzcGFuIGNsYXNz PSIiPiZuYnNwOzwvc3Bhbj5SYXVzY2hlbmJhY2gsIFV3ZSAoTm9raWEgLSBERS9NdW5pY2gpICZs dDs8YSBocmVmPSJtYWlsdG86dXdlLnJhdXNjaGVuYmFjaEBub2tpYS5jb20iIHRhcmdldD0iX2Js YW5rIiBjbGFzcz0iIj48c3BhbiBzdHlsZT0iY29sb3I6cHVycGxlIiBjbGFzcz0iIj51d2UucmF1 c2NoZW5iYWNoQG5va2lhLmNvbTwvc3Bhbj48L2E+Jmd0OzxiciBjbGFzcz0iIj4NCjxiIGNsYXNz PSIiPkNjOjwvYj48c3BhbiBjbGFzcz0iIj4mbmJzcDs8L3NwYW4+ZXh0IEVyaWMgUmVzY29ybGEg Jmx0OzxhIGhyZWY9Im1haWx0bzpla3JAcnRmbS5jb20iIHRhcmdldD0iX2JsYW5rIiBjbGFzcz0i Ij48c3BhbiBzdHlsZT0iY29sb3I6cHVycGxlIiBjbGFzcz0iIj5la3JAcnRmbS5jb208L3NwYW4+ PC9hPiZndDs7IFNjaHdhcnosIEFsYnJlY2h0IChBbGJyZWNodCkgJmx0OzxhIGhyZWY9Im1haWx0 bzphbGJyZWNodC5zY2h3YXJ6QGFsY2F0ZWwtbHVjZW50LmNvbSIgdGFyZ2V0PSJfYmxhbmsiIGNs YXNzPSIiPjxzcGFuIHN0eWxlPSJjb2xvcjpwdXJwbGUiIGNsYXNzPSIiPmFsYnJlY2h0LnNjaHdh cnpAYWxjYXRlbC1sdWNlbnQuY29tPC9zcGFuPjwvYT4mZ3Q7Ow0KIEFzdmVyZW4sIFRvbGdhICZs dDs8YSBocmVmPSJtYWlsdG86dGFzdmVyZW5Ac29udXNuZXQuY29tIiB0YXJnZXQ9Il9ibGFuayIg Y2xhc3M9IiI+PHNwYW4gc3R5bGU9ImNvbG9yOnB1cnBsZSIgY2xhc3M9IiI+dGFzdmVyZW5Ac29u dXNuZXQuY29tPC9zcGFuPjwvYT4mZ3Q7OyBDaHJpc3RlciBIb2xtYmVyZyAmbHQ7PGEgaHJlZj0i bWFpbHRvOmNocmlzdGVyLmhvbG1iZXJnQGVyaWNzc29uLmNvbSIgdGFyZ2V0PSJfYmxhbmsiIGNs YXNzPSIiPjxzcGFuIHN0eWxlPSJjb2xvcjpwdXJwbGUiIGNsYXNzPSIiPmNocmlzdGVyLmhvbG1i ZXJnQGVyaWNzc29uLmNvbTwvc3Bhbj48L2E+Jmd0OzsNCiBCZXJuYXJkIEFib2JhICZsdDs8YSBo cmVmPSJtYWlsdG86YmVybmFyZC5hYm9iYUBnbWFpbC5jb20iIHRhcmdldD0iX2JsYW5rIiBjbGFz cz0iIj48c3BhbiBzdHlsZT0iY29sb3I6cHVycGxlIiBjbGFzcz0iIj5iZXJuYXJkLmFib2JhQGdt YWlsLmNvbTwvc3Bhbj48L2E+Jmd0OzsgJmx0OzxhIGhyZWY9Im1haWx0bzpydGN3ZWJAaWV0Zi5v cmciIHRhcmdldD0iX2JsYW5rIiBjbGFzcz0iIj48c3BhbiBzdHlsZT0iY29sb3I6cHVycGxlIiBj bGFzcz0iIj5ydGN3ZWJAaWV0Zi5vcmc8L3NwYW4+PC9hPiZndDsNCiAmbHQ7PGEgaHJlZj0ibWFp bHRvOnJ0Y3dlYkBpZXRmLm9yZyIgdGFyZ2V0PSJfYmxhbmsiIGNsYXNzPSIiPjxzcGFuIHN0eWxl PSJjb2xvcjpwdXJwbGUiIGNsYXNzPSIiPnJ0Y3dlYkBpZXRmLm9yZzwvc3Bhbj48L2E+Jmd0Ozxi ciBjbGFzcz0iIj4NCjxiIGNsYXNzPSIiPlN1YmplY3Q6PC9iPjxzcGFuIGNsYXNzPSIiPiZuYnNw Ozwvc3Bhbj5SZTogW3J0Y3dlYl0gV2hhdCB0aGUgZ2F0ZXdheSBkcmFmdCBzaG91bGQgc2F5IGFi b3V0IG11eC9ub24tbXV4PC9zcGFuPjx1IGNsYXNzPSIiPjwvdT48dSBjbGFzcz0iIj48L3U+PC9w Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdiBjbGFzcz0iIj4NCjxwIGNsYXNzPSJNc29O b3JtYWwiIHN0eWxlPSJiYWNrZ3JvdW5kOndoaXRlIj48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6 JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmIiBjbGFzcz0iIj4mbmJzcDs8L3NwYW4+PHUg Y2xhc3M9IiI+PC91Pjx1IGNsYXNzPSIiPjwvdT48L3A+DQo8L2Rpdj4NCjxkaXYgY2xhc3M9IiI+ DQo8ZGl2IGNsYXNzPSIiPg0KPGRpdiBjbGFzcz0iIj4NCjxkaXYgY2xhc3M9IiI+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIiBzdHlsZT0iYmFja2dyb3VuZDp3aGl0ZSI+PHNwYW4gc3R5bGU9ImZvbnQt ZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZiIgY2xhc3M9IiI+T24gV2VkLCBB dWcgNSwgMjAxNSBhdCA0OjQ3IEFNLCBSYXVzY2hlbmJhY2gsIFV3ZSAoTm9raWEgLSBERS9NdW5p Y2gpICZsdDs8YSBocmVmPSJtYWlsdG86dXdlLnJhdXNjaGVuYmFjaEBub2tpYS5jb20iIHRhcmdl dD0iX2JsYW5rIiBjbGFzcz0iIj48c3BhbiBzdHlsZT0iY29sb3I6cHVycGxlIiBjbGFzcz0iIj51 d2UucmF1c2NoZW5iYWNoQG5va2lhLmNvbTwvc3Bhbj48L2E+Jmd0Ow0KIHdyb3RlOjwvc3Bhbj48 dSBjbGFzcz0iIj48L3U+PHUgY2xhc3M9IiI+PC91PjwvcD4NCjwvZGl2Pg0KPGJsb2NrcXVvdGUg c3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci1sZWZ0OnNvbGlkICNjY2NjY2MgMS4wcHQ7cGFkZGlu ZzowaW4gMGluIDBpbiA2LjBwdDttYXJnaW4tbGVmdDo0LjhwdDttYXJnaW4tdG9wOjUuMHB0O21h cmdpbi1yaWdodDowaW47bWFyZ2luLWJvdHRvbTo1LjBwdCIgY2xhc3M9IiI+DQo8ZGl2IGNsYXNz PSIiPg0KPGRpdiBjbGFzcz0iIj4NCjxkaXYgY2xhc3M9IiI+DQo8cCBjbGFzcz0iTXNvTm9ybWFs IiBzdHlsZT0iYmFja2dyb3VuZDp3aGl0ZSI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7 Zm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDssc2Fucy1zZXJpZiIgY2xhc3M9IiI+TWVkaWEg Z2F0ZXdheSBpbXBsZW1lbnRhdGlvbnMgYWNjb3JkaW5nIHRvIDNHUFAgVFMgMjMuMjI4PC9zcGFu PjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkm cXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMWY0OTdkIiBjbGFzcz0iIj4mbmJzcDs8L3NwYW4+PHNw YW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDss c2Fucy1zZXJpZiIgY2xhc3M9IiI+bWF5DQogbm90IHN1cHBvcnQgcnRjcC1tdXgsIGFzIHJ0Y3At bXV4IGlzIG9wdGlvbmFsIHRoZXJlLjwvc3Bhbj48dSBjbGFzcz0iIj48L3U+PHUgY2xhc3M9IiI+ PC91PjwvcD4NCjwvZGl2Pg0KPGRpdiBjbGFzcz0iIj4NCjxkaXYgY2xhc3M9IiI+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIiBzdHlsZT0iYmFja2dyb3VuZDp3aGl0ZSI+PHNwYW4gc3R5bGU9ImZvbnQt c2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDssc2Fucy1zZXJpZiIgY2xh c3M9IiI+U28gaWYgd2UgZHJvcCBub24tbXV4IHN1cHBvcnQgZnJvbSB3ZWIgYnJvd3NlcnMsIHRo b3NlIG1lZGlhIGdhdGV3YXlzIHRoYXQgaGF2ZSBub3QgaW1wbGVtZW50ZWQgcnRjcC1tdXggd2ls bCBzdG9wIGludGVyb3BlcmF0aW5nLiZuYnNwOzwvc3Bhbj48dSBjbGFzcz0iIj48L3U+PHUgY2xh c3M9IiI+PC91PjwvcD4NCjwvZGl2Pg0KPGRpdiBjbGFzcz0iIj4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiIHN0eWxlPSJiYWNrZ3JvdW5kOndoaXRlIj48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1 b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmIiBjbGFzcz0iIj4mbmJzcDs8L3NwYW4+PHUgY2xh c3M9IiI+PC91Pjx1IGNsYXNzPSIiPjwvdT48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8 L2Rpdj4NCjwvYmxvY2txdW90ZT4NCjxkaXYgY2xhc3M9IiI+DQo8ZGl2IGNsYXNzPSIiPg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9ImJhY2tncm91bmQ6d2hpdGUiPjxzcGFuIHN0eWxlPSJm b250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWYiIGNsYXNzPSIiPiZuYnNw Ozwvc3Bhbj48dSBjbGFzcz0iIj48L3U+PHUgY2xhc3M9IiI+PC91PjwvcD4NCjwvZGl2Pg0KPC9k aXY+DQo8ZGl2IGNsYXNzPSIiPg0KPGRpdiBjbGFzcz0iIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi IHN0eWxlPSJiYWNrZ3JvdW5kOndoaXRlIj48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7 Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmIiBjbGFzcz0iIj5GaXJzdCBvZiBhbGwsIGRvIHlvdSBr bm93IG9mIGFueSBXZWJSVEMgdG8gSU1TIGdhdGV3YXlzIHRoYXQgZG8gbm90IGltcGxlbWVudCBy dGNwLW11eCBvbiB0aGUgV2ViUlRDIHNpZGU/IEkgc3Ryb25nbHkgc3VzcGVjdCB0aGVyZSBhcmUg bm9uZS48L3NwYW4+PHUgY2xhc3M9IiI+PC91Pjx1IGNsYXNzPSIiPjwvdT48L3A+DQo8L2Rpdj4N CjwvZGl2Pg0KPGRpdiBjbGFzcz0iIj4NCjxkaXYgY2xhc3M9IiI+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIiBzdHlsZT0iYmFja2dyb3VuZDp3aGl0ZSI+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiZx dW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZiIgY2xhc3M9IiI+Jm5ic3A7PC9zcGFuPjx1IGNs YXNzPSIiPjwvdT48dSBjbGFzcz0iIj48L3U+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXYgY2xh c3M9IiI+DQo8ZGl2IGNsYXNzPSIiPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9ImJhY2tn cm91bmQ6d2hpdGUiPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7 LHNhbnMtc2VyaWYiIGNsYXNzPSIiPlNlY29uZCwgdGhlIG9ubHkgcmVhc29ucyBub3QgdG8gdXNl IHJ0Y3AtbXV4IHRoYXQgSSBjYW4gdGhpbmsgb2YgYXJlIHRoZSBmb2xsb3dpbmc6PC9zcGFuPjx1 IGNsYXNzPSIiPjwvdT48dSBjbGFzcz0iIj48L3U+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXYg Y2xhc3M9IiI+DQo8ZGl2IGNsYXNzPSIiPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9ImJh Y2tncm91bmQ6d2hpdGUiPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1 b3Q7LHNhbnMtc2VyaWYiIGNsYXNzPSIiPiZuYnNwOzwvc3Bhbj48dSBjbGFzcz0iIj48L3U+PHUg Y2xhc3M9IiI+PC91PjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2IGNsYXNzPSIiPg0KPGRpdiBj bGFzcz0iIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJiYWNrZ3JvdW5kOndoaXRlIj48 c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmIiBj bGFzcz0iIj4xLiBVc2luZyBkaWZmZXJlbnQgUU9TIHNldHRpbmdzIGZvciBSVENQIHZzIFJUUDwv c3Bhbj48dSBjbGFzcz0iIj48L3U+PHUgY2xhc3M9IiI+PC91PjwvcD4NCjwvZGl2Pg0KPC9kaXY+ DQo8ZGl2IGNsYXNzPSIiPg0KPGRpdiBjbGFzcz0iIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0 eWxlPSJiYWNrZ3JvdW5kOndoaXRlIj48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7Q2Fs aWJyaSZxdW90OyxzYW5zLXNlcmlmIiBjbGFzcz0iIj4yLiBTZW5kaW5nIFJUQ1AgdG8gYSBkaWZm ZXJlbnQgZGV2aWNlIGZyb20gUlRQPC9zcGFuPjx1IGNsYXNzPSIiPjwvdT48dSBjbGFzcz0iIj48 L3U+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXYgY2xhc3M9IiI+DQo8ZGl2IGNsYXNzPSIiPg0K PHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9ImJhY2tncm91bmQ6d2hpdGUiPjxzcGFuIHN0eWxl PSJmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWYiIGNsYXNzPSIiPiZu YnNwOzwvc3Bhbj48dSBjbGFzcz0iIj48L3U+PHUgY2xhc3M9IiI+PC91PjwvcD4NCjwvZGl2Pg0K PC9kaXY+DQo8ZGl2IGNsYXNzPSIiPg0KPGRpdiBjbGFzcz0iIj4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiIHN0eWxlPSJiYWNrZ3JvdW5kOndoaXRlIj48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1 b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmIiBjbGFzcz0iIj5JIGRvIG5vdCB0aGluayB0aGUg Zmlyc3QgdXNlIGNhc2Ugd2FycmFudHMgbWFraW5nIHJ0Y3AtbXV4IG9wdGlvbmFsLCBzaW5jZSwg cHJhY3RpY2FsbHkgbm8gb25lIGRvZXMgdGhpcy48L3NwYW4+PHUgY2xhc3M9IiI+PC91Pjx1IGNs YXNzPSIiPjwvdT48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdiBjbGFzcz0iIj4NCjxkaXYgY2xh c3M9IiI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0iYmFja2dyb3VuZDp3aGl0ZSI+PHNw YW4gc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZiIgY2xh c3M9IiI+U2Vjb25kIHVzZSBjYXNlIGlzIGFsc28gZmFpcmx5IG1hcmdpbmFsLiBQbHVzIGl0IGNh biBiZSBoYW5kbGVkIGJ5IHRoZSBnYXRld2F5IHdoaWNoIGNhbiBzZW5kIFJUQ1AgdG8gb25lIGRl dmljZSBhbmQgUlRQIHRvIGFub3RoZXIuPC9zcGFuPjx1IGNsYXNzPSIiPjwvdT48dSBjbGFzcz0i Ij48L3U+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXYgY2xhc3M9IiI+DQo8ZGl2IGNsYXNzPSIi Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9ImJhY2tncm91bmQ6d2hpdGUiPjxzcGFuIHN0 eWxlPSJmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWYiIGNsYXNzPSIi PiZuYnNwOzwvc3Bhbj48dSBjbGFzcz0iIj48L3U+PHUgY2xhc3M9IiI+PC91PjwvcD4NCjwvZGl2 Pg0KPC9kaXY+DQo8ZGl2IGNsYXNzPSIiPg0KPGRpdiBjbGFzcz0iIj4NCjxwIGNsYXNzPSJNc29O b3JtYWwiIHN0eWxlPSJiYWNrZ3JvdW5kOndoaXRlIj48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6 JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmIiBjbGFzcz0iIj5TbywgdW5sZXNzIHNvbWVv bmUgY2FuIGNvbWUgdXAgd2l0aCBhIHVzZSBjYXNlIHdoeSBSVFAgYW5kIFJUQ1Agc2hvdWxkIHVz ZSBkaWZmZXJlbnQgdHJhbnNwb3J0cywgSSB0aGluayBydGNwLW11eCBzaG91bGQgYmUgbWFuZGF0 b3J5Ljwvc3Bhbj48dSBjbGFzcz0iIj48L3U+PHUgY2xhc3M9IiI+PC91PjwvcD4NCjwvZGl2Pg0K PC9kaXY+DQo8ZGl2IGNsYXNzPSIiPg0KPGRpdiBjbGFzcz0iIj4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiIHN0eWxlPSJiYWNrZ3JvdW5kOndoaXRlIj48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1 b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmIiBjbGFzcz0iIj4mbmJzcDs8L3NwYW4+PHUgY2xh c3M9IiI+PC91Pjx1IGNsYXNzPSIiPjwvdT48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdiBjbGFz cz0iIj4NCjxkaXYgY2xhc3M9IiI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0iYmFja2dy b3VuZDp3aGl0ZSI+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDss c2Fucy1zZXJpZiIgY2xhc3M9IiI+UmVnYXJkcyw8L3NwYW4+PHUgY2xhc3M9IiI+PC91Pjx1IGNs YXNzPSIiPjwvdT48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdiBjbGFzcz0iIj4NCjxkaXYgY2xh c3M9IiI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0iYmFja2dyb3VuZDp3aGl0ZSI+PHNw YW4gc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZiIgY2xh c3M9IiI+X19fX19fX19fX19fX188L3NwYW4+PHUgY2xhc3M9IiI+PC91Pjx1IGNsYXNzPSIiPjwv dT48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdiBjbGFzcz0iIj4NCjxkaXYgY2xhc3M9IiI+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0iYmFja2dyb3VuZDp3aGl0ZSI+PHNwYW4gc3R5bGU9 ImZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZiIgY2xhc3M9IiI+Um9t YW4gU2hwb3VudDwvc3Bhbj48dSBjbGFzcz0iIj48L3U+PHUgY2xhc3M9IiI+PC91PjwvcD4NCjwv ZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9k aXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rp dj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6OS4wcHQ7Zm9u dC1mYW1pbHk6JnF1b3Q7SGVsdmV0aWNhJnF1b3Q7LHNhbnMtc2VyaWYiIGNsYXNzPSIiPl9fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fPGJyIGNsYXNzPSIiPg0K cnRjd2ViIG1haWxpbmcgbGlzdDxiciBjbGFzcz0iIj4NCjxhIGhyZWY9Im1haWx0bzpydGN3ZWJA aWV0Zi5vcmciIHRhcmdldD0iX2JsYW5rIiBjbGFzcz0iIj5ydGN3ZWJAaWV0Zi5vcmc8L2E+PGJy IGNsYXNzPSIiPg0KPGEgaHJlZj0iaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5m by9ydGN3ZWIiIHRhcmdldD0iX2JsYW5rIiBjbGFzcz0iIj5odHRwczovL3d3dy5pZXRmLm9yZy9t YWlsbWFuL2xpc3RpbmZvL3J0Y3dlYjwvYT48L3NwYW4+PHUgY2xhc3M9IiI+PC91Pjx1IGNsYXNz PSIiPjwvdT48L3A+DQo8L2Rpdj4NCjwvYmxvY2txdW90ZT4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+Jm5ic3A7PHUgY2xhc3M9IiI+PC91Pjx1IGNsYXNzPSIiPjwvdT48L3A+DQo8L2Rp dj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9ibG9ja3F1b3RlPg0KPC9kaXY+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48dSBjbGFzcz0iIj48L3U+Jm5ic3A7PHUgY2xhc3M9IiI+ PC91PjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8YnIgY2xh c3M9IiI+DQpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXzxi ciBjbGFzcz0iIj4NCnJ0Y3dlYiBtYWlsaW5nIGxpc3Q8YnIgY2xhc3M9IiI+DQo8YSBocmVmPSJt YWlsdG86cnRjd2ViQGlldGYub3JnIiBjbGFzcz0iIj5ydGN3ZWJAaWV0Zi5vcmc8L2E+PGJyIGNs YXNzPSIiPg0KPGEgaHJlZj0iaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9y dGN3ZWIiIHJlbD0ibm9yZWZlcnJlciIgdGFyZ2V0PSJfYmxhbmsiIGNsYXNzPSIiPmh0dHBzOi8v d3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vcnRjd2ViPC9hPjxiciBjbGFzcz0iIj4NCjxi ciBjbGFzcz0iIj4NCjwvYmxvY2txdW90ZT4NCjwvZGl2Pg0KPGJyIGNsYXNzPSIiPg0KPC9kaXY+ DQo8L2Rpdj4NCjwvZGl2Pg0KX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX188YnIgY2xhc3M9IiI+DQpydGN3ZWIgbWFpbGluZyBsaXN0PGJyIGNsYXNzPSIiPg0K PGEgaHJlZj0ibWFpbHRvOnJ0Y3dlYkBpZXRmLm9yZyIgY2xhc3M9IiI+cnRjd2ViQGlldGYub3Jn PC9hPjxiciBjbGFzcz0iIj4NCmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8v cnRjd2ViPGJyIGNsYXNzPSIiPg0KPC9kaXY+DQo8L2Jsb2NrcXVvdGU+DQo8L2Rpdj4NCjxiciBj bGFzcz0iIj4NCjwvYm9keT4NCjwvaHRtbD4NCg== --_000_A85FE9071A214F5FB671922FAF68DA1Cvidyocom_-- From nobody Thu Aug 6 10:38:33 2015 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B90431B3CA5 for ; Thu, 6 Aug 2015 10:38:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HmMK87Xiai4p for ; Thu, 6 Aug 2015 10:38:26 -0700 (PDT) Received: from na01-by2-obe.outbound.protection.outlook.com (mail-by2on0070.outbound.protection.outlook.com [207.46.100.70]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1F4551B31DD for ; Thu, 6 Aug 2015 10:38:26 -0700 (PDT) Received: from SN1PR0301MB1551.namprd03.prod.outlook.com (10.162.129.157) by SN1PR0301MB1549.namprd03.prod.outlook.com (10.162.129.155) with Microsoft SMTP Server (TLS) id 15.1.225.19; Thu, 6 Aug 2015 17:38:23 +0000 Received: from SN1PR0301MB1551.namprd03.prod.outlook.com ([10.162.129.157]) by SN1PR0301MB1551.namprd03.prod.outlook.com ([10.162.129.157]) with mapi id 15.01.0225.018; Thu, 6 Aug 2015 17:38:23 +0000 From: "Asveren, Tolga" To: Christer Holmberg , Eric Rescorla Thread-Topic: [rtcweb] What the gateway draft should say about mux/non-mux Thread-Index: AQHQy8DcUgzWwtVCmk+8q67BCzjC45316kQQgAAD5oCAAACVsIAAAj2AgAPw2gCAAEFTAIAC/BgAgACAxgCAABQlsIAA2x8AgAAp4WeAAApBgIAADKQAgAARK8CAABTdgIAACn+AgAAKP4CAAACJUIAAB4QAgAADM1CAACKwAIAACiqQ Date: Thu, 6 Aug 2015 17:38:23 +0000 Message-ID: References: <9F33F40F6F2CD847824537F3C4E37DDF1E826A00@MCHP04MSX.global-ad.net> <7515AC50-14F3-43C4-B3D9-D785100FC9C5@phonefromhere.com> , <7594FB04B1934943A5C02806D1A2204B348EB645@ESESSMB209.ericsson.se> In-Reply-To: <7594FB04B1934943A5C02806D1A2204B348EB645@ESESSMB209.ericsson.se> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=tasveren@sonusnet.com; x-originating-ip: [50.182.164.80] x-microsoft-exchange-diagnostics: 1; SN1PR0301MB1549; 5:v9E1AK0QSLePprbcsVI5Lh88tgkTt5XgEbOdyhuzCUtuwxyx6Dm0bwOEQZc3rEr8dmG/J15eQIU8uipCYF46wCCtNou4PkcUxHUNsGZ1JE+TVOXxiqz/8h8Pz79h7GTZBPlPAZGiGfO95yZUXYUJ6g==; 24:aEROMJivXgGt8hMDrqKDysFwHuv3Aqwy/Uf3gDT3xvMazY/5dEXR/tguk8grpO/i7uwdI68z9w9bM/Y2CpY7RxJthMLaTvYShutIYOuU9tc=; 20:urVgjoRM6HoLMVqhdsSjxTKVwGhXGAHmz6rJdUccFYozh1kPmkg6vUwwbwH4nOQNk949fifPj45ilCpiVXl2kg== x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:SN1PR0301MB1549; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(108003899814671); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(601004)(5005006)(3002001); SRVR:SN1PR0301MB1549; BCL:0; PCL:0; RULEID:; SRVR:SN1PR0301MB1549; x-forefront-prvs: 06607E485E x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(164054003)(189002)(377454003)(199003)(24454002)(87936001)(76576001)(19609705001)(2656002)(10400500002)(76176999)(54356999)(86362001)(97736004)(50986999)(5001770100001)(4001540100001)(81156007)(5001860100001)(5001830100001)(106356001)(105586002)(19580395003)(99286002)(106116001)(5001960100002)(19300405004)(122556002)(189998001)(64706001)(19617315012)(66066001)(5003600100002)(5002640100001)(19580405001)(77156002)(16236675004)(33656002)(62966003)(40100003)(92566002)(93886004)(77096005)(15975445007)(68736005)(2950100001)(74316001)(19625215002)(102836002)(2900100001)(46102003)(101416001)(579004); DIR:OUT; SFP:1101; SCL:1; SRVR:SN1PR0301MB1549; H:SN1PR0301MB1551.namprd03.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; MX:1; A:1; LANG:en; received-spf: None (protection.outlook.com: sonusnet.com does not designate permitted sender hosts) Content-Type: multipart/alternative; boundary="_000_SN1PR0301MB155138665B1A591BFD715892B2740SN1PR0301MB1551_" MIME-Version: 1.0 X-OriginatorOrg: sonusnet.com X-MS-Exchange-CrossTenant-originalarrivaltime: 06 Aug 2015 17:38:23.6971 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 29a671dc-ed7e-4a54-b1e5-8da1eb495dc3 X-MS-Exchange-Transport-CrossTenantHeadersStamped: SN1PR0301MB1549 Archived-At: Cc: "" Subject: Re: [rtcweb] What the gateway draft should say about mux/non-mux X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 06 Aug 2015 17:38:31 -0000 --_000_SN1PR0301MB155138665B1A591BFD715892B2740SN1PR0301MB1551_ Content-Type: text/plain; charset="windows-1255" Content-Transfer-Encoding: quoted-printable =93I don't want a standard which says "look what the browsers do and follow= ".=94 I don=92t want this either. =93I want a standard, when correctly implemented, ensures interoperability = with browsers (and other types of WebRTC entities).=94 And isn=92t this achieved mainly by rtcp-mux being a negotiated functionali= ty? Or maybe we have a different understanding of what =93interoperability= =94 means and you are referring to what I would call =93profiling=94, i.e. = selecting a subset of functionality from a (set of) specification(s) and ma= ndating it on elements, which claim to be compliant to that particular prof= ile. Thanks, Tolga From: Christer Holmberg [mailto:christer.holmberg@ericsson.com] Sent: Thursday, August 06, 2015 12:52 PM To: Asveren, Tolga ; Eric Rescorla Cc: Subject: RE: [rtcweb] What the gateway draft should say about mux/non-mux Hi, As an implementer, and as an IETF participant, I don't want a standard whic= h says "look what the browsers do and follow". That will only cause trouble= - especially if different browsers do different things. I want a standard,= when correctly implemented, ensures interoperability with browsers (and ot= her types of WebRTC entities). Implementations that only need to work in specific environments can of cour= se do whatever they want, but I don't think we consider e.g. Chrome and Fir= efox such implementations. Regards, Christer Sent from my Windows Phone ________________________________ From: Asveren, Tolga Sent: =FD06/=FD08/=FD2015 17:52 To: Eric Rescorla Cc: Subject: Re: [rtcweb] What the gateway draft should say about mux/non-mux In practice =96if not as initially targeted- a WebRTC-endpoint does not nec= essarily mean a =93browser=94. I completely agree with our statements about= browser based deployments though. All I am saying is =93Let people decide = what they want to support, they are smart enough to know what a particular = deployment model requires=94. For example, regardless of what specification= s say, non-browser equipment vendors, whose products need to interoperate w= ith browsers, are following/implementing how Chrome/Firefox are behaving. Thanks, Tolga From: Eric Rescorla [mailto:ekr@rtfm.com] Sent: Thursday, August 06, 2015 10:36 AM To: Asveren, Tolga > Cc: tim panton >; Hutto= n, Andrew >; > > Subject: Re: [rtcweb] What the gateway draft should say about mux/non-mux I feel like people are talking past each other here. The browser vendors (at least Chrome and Firefox) want to completely remove= support for non-mux from their code. If we make this change, that means that there will= be no way for a browser to do non-mux and so as a practical matter we might as well simply = say that WebRTC is mux and hence for the WebRTC side of a WebRTC gateway, there is s= imilarly no need to support non-mux, This only leaves the question of the non-WebRTC si= de of the gateway, but that's out of scope here. So, I'm not sure what you are as= king for. WRT to the issue Jonathan raises about SDP being a negotiation, that's true= , but as a practical matter we're already far down the road of WebRTC offerers offer= ing SDP which in principle the answerer might choose not to accept but if it does s= o the connection will fail -Ekr On Thu, Aug 6, 2015 at 7:12 AM, Asveren, Tolga > wrote: I think implementers themselves can weigh out the advantages/disadvantaged/= deployment models they are targeting/etc=85 and decide what to support/not = to support. I don=92t see any issue with this as long as there is a negotia= tion mechanism (which there is). I don=92t think the availability of negoti= ation is encouraging people this or that way. Thanks, Tolga From: tim panton [mailto:tim@phonefromhere.com] Sent: Thursday, August 06, 2015 10:07 AM To: Hutton, Andrew = > Cc: Asveren, Tolga >; <= rtcweb@ietf.org> > Subject: Re: [rtcweb] What the gateway draft should say about mux/non-mux On 6 Aug 2015, at 08:30, Hutton, Andrew > wrote: +1 to what Tim said. I don=92t think this discussion is really about gateways at all it is surel= y about whether WebRTC browsers have to support non-mux and I don=92t reall= y see any good reason why they need to. If we had thought about this at the time we mandated DTLS-SRTP then we woul= d have mandated rtp-mux at the same time but unfortunately we didn=92t but = we can fix that now. Sadly true, but the situation in a browser is manageable since you might ex= pect 10 peer connections, resulting in a worst case of 60 UDP ports/DTLS sessions in use (assuming voice+video+data unbundled and RTCP-non-mux vs the 10 needed). We also assume a relatively well endowed CPU - devoted largely to this task. On the gateway you=92d hope to have thousands of sessions and presumably mu= ch less CPU/memory resource per channel. So while I think it is unfortunate that browsers can do non-mux, it would b= e plain stupid to do that on a gateway. Do we really want to encourage that ? T. Andy From: rtcweb [mailto:rtcweb-bounces@ietf.org] On Behalf Of tim panton Sent: 06 August 2015 13:53 To: Asveren, Tolga Cc: > Subject: Re: [rtcweb] What the gateway draft should say about mux/non-mux So we are positing the existence of a webRTC gateway designed to support th= ousands of calls which does ICE and DTLS but the designer decided deliberately to double the number of ICE sessions required= and double the number of DTLS sessions (and key generation costs) so that they can run RTCP (over ICE and DTLS) on a separa= te port. In my estimation that=92s one poor decision and should not be used as the basis of this (or any) standard. I=92d rather not support rtcp-no-mux as I see zero advantages in having it.= (I know theoretically it might be possible to get a RTCP packet through a congested net on a different port with a separate d= iffserv setting but that just seems so contrived). Tim. On 6 Aug 2015, at 06:44, Asveren, Tolga > wrote: These assumptions are not necessarily true in a universal sense (like almos= t any other assumption about different deployment models). Furthermore, and more importantly, there is nothing mandating WebRTC endpoi= nts to support non-rtcp-mux. It is a negotiated functionality. Any entity c= an enforce rtcp-mux as a local policy. The issue with supporting non-rtcp-mux seems to be lack of clarity in the r= elevant specifications. Fixing this =96regardless of the outcome of any oth= er discussion- seems to be prudent IMHO. Thanks, Tolga From: Wyss, Felix [mailto:Felix.Wyss@inin.com] Sent: Thursday, August 06, 2015 6:37 AM To: Christer Holmberg >; Asveren, Tolga >; Schwarz, Albrecht (Albrecht) >; Roman Shpount >; Rauschenbach, Uwe (Nokia - DE/Munich)= > Cc: > > Subject: Re: [rtcweb] What the gateway draft should say about mux/non-mux Why shouldn't the gateway be required to do the mux/demux? Making the WebR= TC endpoints a lot more complex just so the legacy interop might potentiall= y be a teeny-tiny bit easier makes no sense IMHO. Actually, the gateway wo= uld not be able to do "end-to-end" pass-through anyway as legacy equipment = will either be unencrypted or use SDES (RFC#4568) for key exchange. So the= gateway will have to perform DTLS-SRTP to SDES-SRTP transcryption--which a= lready is way more hassle than RTP/RTCP mux/demux. --Felix ________________________________ From: rtcweb > on b= ehalf of Christer Holmberg > Sent: Thursday, August 6, 2015 05:51 To: Asveren, Tolga; Schwarz, Albrecht (Albrecht); Roman Shpount; Rauschenba= ch, Uwe (Nokia - DE/Munich) Cc: > Subject: Re: [rtcweb] What the gateway draft should say about mux/non-mux Hi, No matter whether the gateway supports RTP/RTCP mux or not, there are cases= where the legacy network/endpoints will not use RTP/RTCP mux, so I guess p= eople then would want to be able to negotiate non-mux =93end-to-end=94, rat= her than having the gateway to demux/mux RTP and RTCP. Regards, Christer From: Asveren, Tolga [mailto:tasveren@sonusnet.com] Sent: 6. elokuuta 2015 12:18 To: Schwarz, Albrecht (Albrecht); Roman Shpount; Rauschenbach, Uwe (Nokia -= DE/Munich) Cc: ext Eric Rescorla; Christer Holmberg; Bernard Aboba; > Subject: Re: [rtcweb] What the gateway draft should say about mux/non-mux Why should we consider 3GPP the sole "owner/user" of the term/entity WebRTC= -GW? I think it has a much more general meaning and use in practice. It can= refer to many different types of elements which can be deployed in many di= fferent environments, hence any attempt to define it strictly/restrict its = capabilities are futile IMHO. Thanks, Tolga ________________________________ From: Schwarz, Albrecht (Albrecht) > Sent: Thursday, August 6, 2015 2:44 AM To: Asveren, Tolga; Roman Shpount; Rauschenbach, Uwe (Nokia - DE/Munich) Cc: ext Eric Rescorla; Christer Holmberg; Bernard Aboba; > Subject: RE: [rtcweb] What the gateway draft should say about mux/non-mux The concerned 3GPP WebRTC gateway (3GPP 23.334/29.334) supports already RTP= /RTCP transport multiplexing (since 3GPP Release 12), i.e. should not be th= e limiting factor in this discussion. For ones interested in the RTCP port allocation rules, see H.248.57: https://www.itu.int/rec/dologin_pub.asp?lang=3De&id=3DT-REC-H.248.57-201410= -I!!PDF-E&type=3Ditems Clause 7 describes RTP/RTCP transport multiplexing. ITU-T H.248.57 is alrea= dy supported by 3GPP 29.334. The rationale behind the =93optional tagging=94 by 23.228 is a third reason= , beyond >1. Using different QOS settings for RTCP vs RTP >2. Sending RTCP to a different device from RTP Don=92t want to go in the 3GPP specific details, but it has nothing to do w= ith the 3GPP UE-embedded WebRTC client nor any constraints by 3GPP WebRTC g= ateways. Thus, a WebRTC gateway MUST support RTP/RTCP transport multiplexing due to = its purpose in interworking support. Regards, Albrecht From: Asveren, Tolga [mailto:tasveren@sonusnet.com] Sent: Mittwoch, 5. August 2015 19:47 To: Roman Shpount; Rauschenbach, Uwe (Nokia - DE/Munich) Cc: ext Eric Rescorla; Schwarz, Albrecht (Albrecht); Christer Holmberg; Ber= nard Aboba; > Subject: RE: [rtcweb] What the gateway draft should say about mux/non-mux i- I humbly disagree that using different QoS RTCP/RTP, e.g. different Diff= Serv values , should be dismissed. ii- Let me also add another reason why no-rtcp-mux may be needed: Implement= ation difficulties in certain GWs. Considering that there is already a negotiation mechanism for rtcp-mux supp= ort, that it can be de-facto mandated by the choice of browsers for Interne= t, I think what Christer/Albrecht suggested is the right way to move forwar= d: provide clarifications for vague points. I don=92t understand why lack o= f clarity in existing specifications should cause imposing restrictions. Th= is would be akin to dropping a feature due to a bug. In this case, the =93b= ug=94 is lack of clarity in normative specifications and it can be addresse= d by further specification. Thanks, Tolga From: Roman Shpount [mailto:roman@telurix.com] Sent: Wednesday, August 05, 2015 12:29 PM To: Rauschenbach, Uwe (Nokia - DE/Munich) > Cc: ext Eric Rescorla >; Schwarz, Albrech= t (Albrecht) >; Asveren, Tolga >; Christer Holmberg >; Bernard Aboba >; > > Subject: Re: [rtcweb] What the gateway draft should say about mux/non-mux On Wed, Aug 5, 2015 at 4:47 AM, Rauschenbach, Uwe (Nokia - DE/Munich) > wrote: Media gateway implementations according to 3GPP TS 23.228 may not support r= tcp-mux, as rtcp-mux is optional there. So if we drop non-mux support from web browsers, those media gateways that = have not implemented rtcp-mux will stop interoperating. First of all, do you know of any WebRTC to IMS gateways that do not impleme= nt rtcp-mux on the WebRTC side? I strongly suspect there are none. Second, the only reasons not to use rtcp-mux that I can think of are the fo= llowing: 1. Using different QOS settings for RTCP vs RTP 2. Sending RTCP to a different device from RTP I do not think the first use case warrants making rtcp-mux optional, since,= practically no one does this. Second use case is also fairly marginal. Plus it can be handled by the gate= way which can send RTCP to one device and RTP to another. So, unless someone can come up with a use case why RTP and RTCP should use = different transports, I think rtcp-mux should be mandatory. Regards, ______________ Roman Shpount _______________________________________________ rtcweb mailing list rtcweb@ietf.org https://www.ietf.org/mailman/listinfo/rtcweb _______________________________________________ rtcweb mailing list rtcweb@ietf.org https://www.ietf.org/mailman/listinfo/rtcweb --_000_SN1PR0301MB155138665B1A591BFD715892B2740SN1PR0301MB1551_ Content-Type: text/html; charset="windows-1255" Content-Transfer-Encoding: quoted-printable

=93I don't want a standard which says "look wh= at the browsers do and follow".=94

I don=92t want this either.

 

=93I want a standard, when correctly implemented, e= nsures interoperability with browsers (and other types of WebRTC entities).= =94

And isn=92t this achieved mainly by rtcp-mux being = a negotiated functionality? Or maybe we have a different understanding of w= hat =93interoperability=94 means and you are referring to what I would call =93profiling=94, i.e. selecting a subset of functiona= lity from a (set of) specification(s) and mandating it on elements, which c= laim to be compliant to that particular profile.

 

Thanks,

Tolga

 

 

From: Christer Holmberg [mailto:chri= ster.holmberg@ericsson.com]
Sent: Thursday, August 06, 2015 12:52 PM
To: Asveren, Tolga <tasveren@sonusnet.com>; Eric Rescorla <= ekr@rtfm.com>
Cc: <rtcweb@ietf.org> <rtcweb@ietf.org>
Subject: RE: [rtcweb] What the gateway draft should say about mux/no= n-mux

 

Hi,

As an implementer, and as an IETF participant, I don't want a standard whic= h says "look what the browsers do and follow". That will only cau= se trouble - especially if different browsers do different things. I want a= standard, when correctly implemented, ensures interoperability with browsers (and other types of WebRTC entities).

Implementations that only need to work in specific environments can of cour= se do whatever they want, but I don't think we consider e.g. Chrome and Fir= efox such implementations.

Regards,

Christer

Sent from my Windows Phone

From: Asveren, Tolga
Sent: =FD06/=FD08/=FD2015 17:52
To: Eric Rescorla
Cc: <rtcweb@ietf.org&= gt;
Subject: Re: [rtcweb] What the gateway draft should say about mux/non-mux

In practice =96if not as initially ta= rgeted- a WebRTC-endpoint does not necessarily mean a =93browser=94. I comp= letely agree with our statements about browser based deployments though. All I am saying is =93Let people decide what they want= to support, they are smart enough to know what a particular deployment mod= el requires=94. For example, regardless of what specifications say, non-bro= wser equipment vendors, whose products need to interoperate with browsers, are following/implementing how Chrome/= Firefox are behaving.

 

Thanks,

Tolga

 

From: Eric Rescorla [mailto:ekr@rtfm.com]
Sent: Thursday, August 06, 2015 10:36 AM
To: Asveren, Tolga <tasv= eren@sonusnet.com>
Cc: tim panton <tim@phon= efromhere.com>; Hutton, Andrew <andrew.hutton@unify.com>; <rtcweb@ietf.org> <rtcwe= b@ietf.org>
Subject: Re: [rtcweb] What the gateway draft should say about mux/no= n-mux

 

I feel like people are talking past each other here.=

 

The browser vendors (at least Chrome and Firefox) wa= nt to completely remove support for

non-mux from their code. If we make this change, tha= t means that there will be no way for a

browser to do non-mux and so as a practical matter w= e might as well simply say that

WebRTC is mux and hence for the WebRTC side of a Web= RTC gateway, there is similarly no

need to support non-mux, This only leaves the questi= on of the non-WebRTC side of

the gateway, but that's out of scope here. So, I'm n= ot sure what you are asking for.

 

WRT to the issue Jonathan raises about SDP being a n= egotiation, that's true, but as

a practical matter we're already far down the road o= f WebRTC offerers offering SDP

which in principle the answerer might choose not to = accept but if it does so the

connection will fail

 

-Ekr

 

On Thu, Aug 6, 2015 at 7:12 AM, Asveren, Tolga <<= a href=3D"mailto:tasveren@sonusnet.com" target=3D"_blank">tasveren@sonusnet= .com> wrote:

I think implementers themselves can w= eigh out the advantages/disadvantaged/deployment models they are targeting/= etc=85 and decide what to support/not to support. I don=92t see any issue with this as long as there is a negotiation mechan= ism (which there is). I don=92t think the availability of negotiation is en= couraging people this or that way.

 

Thanks,

Tolga

 

From: tim panton [mailto:tim@phonefromhere.com]
Sent: Thursday, August 06, 2015 10:07 AM
To: Hutton, Andrew <andrew.hutton@unify.com>
Cc: Asveren, Tolga <tasveren@sonusnet.com>; <rtcweb@ietf.org> <rtcweb@ietf.org><= /p>


Subject: Re: [rtcweb] What the gateway draft should say about mux/no= n-mux

 

 

On 6 Aug 2015, at 08:30, Hutton, Andrew <andrew.hutton@unify.c= om> wrote:

 

+1 to what Tim said.<= /o:p>

 

I don=92t think this discussion is re= ally about gateways at all it is surely about whether WebRTC browsers have = to support non-mux and I don=92t really see any good reason why they need to.

 

If we had thought about this at the t= ime we mandated DTLS-SRTP then we would have mandated rtp-mux at the same t= ime but unfortunately we didn=92t but we can fix that now.

 

Sadly true, but the situation in a browser is manage= able since you might expect 10 peer connections, resulting =

in a worst case of 60 UDP ports/DTLS sessions in use=  

(assuming voice+video+data unbundled and RTC= P-non-mux vs the 10 needed). We 

also assume a relatively well endowed CPU - devoted = largely to this task.

 

On the gateway you=92d hope to have thousands of ses= sions and presumably much less CPU/memory resource per channel.<= /p>

So while I think it is unfortunate that browsers can= do non-mux, it would be plain stupid to do that on a gateway. Do we <= o:p>

really want to encourage that ?

 

T.

 

 

 

Andy

 

 

From: rtcweb [mailto:rtcweb-bounces@ietf.org] On Behalf Of tim panton
Sent: 06 August 2015 13:53
To: Asveren, Tolga
Cc: <rtcweb@= ietf.org>
Subject: Re: [rtcweb] What the gateway draft should say about mux/no= n-mux

 

So we are positing the existence of a webRTC gateway= designed to support thousands of calls which does ICE and DTLS but the

designer decided deliberately to double the number o= f ICE sessions required and double the number of DTLS sessions (and key&nbs= p;

generation costs) so that they can run RTCP (over IC= E and DTLS) on a separate port. In my estimation that=92s one poor decision=

and should not be used as the basis of this (or any)= standard. 

 

I=92d rather not support rtcp-no-mux as I see zero a= dvantages in having it. (I know theoretically it might be possible to get

a RTCP packet through a congested net on a different= port with a separate diffserv setting but that just seems so contrived).

 

Tim.

 

 

On 6 Aug 2015, at 06:44, Asveren, Tolga <tasveren@sonusnet.com> wrote:

 

These assumptions are not necessarily= true in a universal sense (like almost any other assumption about differen= t deployment models).

 

Furthermore, and more importantly, th= ere is nothing mandating WebRTC endpoints to support non-rtcp-mux. It is a = negotiated functionality. Any entity can enforce rtcp-mux as a local policy. 

 

The issue with supporting non-rtcp-mu= x seems to be lack of clarity in the relevant specifications. Fixing this = =96regardless of the outcome of any other discussion- seems to be prudent IMHO.

 

Thanks,

Tolga

 

From: Wyss, Felix [mailto:Felix.Wyss@inin.com= ] 
Sent: Thursday, August 06, 2015 6:37 AM
To: Christer Holmberg <christer.holmberg@ericsson.com>; Asve= ren, Tolga <t= asveren@sonusnet.com>; Schwarz, Albrecht (Albrecht) <albrecht.schwarz@alcatel-lucent.com>; Roman Shpount <roman@telurix.com>; = Rauschenbach, Uwe (Nokia - DE/Munich) <uwe.rauschenbach@nokia.com>
Cc: <rt= cweb@ietf.org> <rtcweb@ietf.org>
Subject: Re: [rtcweb] What the gateway draft should say about m= ux/non-mux

 

Why shouldn't the gateway be required to = do the mux/demux?  Making the WebRTC endpoints a lot more complex just= so the legacy interop might potentially be a teeny-tiny bit easier makes no sense IMHO.  Actually, the gateway would not be a= ble to do "end-to-end" pass-through anyway as legacy equipment wi= ll either be unencrypted or use SDES (RFC#4568) for key exchange.  So = the gateway will have to perform DTLS-SRTP to SDES-SRTP transcryption--which already is way more hassle than RTP/RTCP mux/demux.

 

--Felix

 

From:&nbs= p;rtcweb <<= span style=3D"color:purple">rtcweb-bounces@ietf.org> on behalf of Christer Holmberg <christer.holmberg= @ericsson.com>
Sent: Thursday, August 6, 2015 05:51
To: Asveren, Tolga; Schwarz, Albrecht (Albrecht); Roman Shpount= ; Rauschenbach, Uwe (Nokia - DE/Munich)
Cc: <rtcweb@ietf.org>
Subject: Re: [rtcweb] What the gateway draft should say about m= ux/non-mux

 

Hi,=

 

No matter = whether the gateway supports RTP/RTCP mux or not, there are cases where the= legacy network/endpoints will not use RTP/RTCP mux, so I guess people then would want to be able to negotiate non-mux =93= end-to-end=94, rather than having the gateway to demux/mux RTP and RTCP.

 

Regards,

 

Christer

 

From: = Asveren, Tolga [= mailto:tasveren@sonusnet.com] =
Sent: 6. elokuuta 2015 12:18
To: Schwarz, Albrecht (Albrecht); Roman Shpount; Rauschenbach, = Uwe (Nokia - DE/Munich)
Cc: ext Eric Rescorla; Christer Holmberg; Bernard Aboba; <rtcweb@ietf.org>
Subject: Re: [rtcweb] What the gateway draft should say about m= ux/non-mux

 

Why should we consider 3GPP the sole &quo= t;owner/user" of the term/entity WebRTC-GW? I think it has a much more= general meaning and use in practice. It can refer to many different types of elements which can be deployed in many different enviro= nments, hence any attempt to define it strictly/restrict its capabilities a= re futile IMHO.

 

Thanks,

Tolga

 

From:&nbs= p;Schwarz, Albrecht (Albrecht) <albrecht.schw= arz@alcatel-lucent.com>
Sent: Thursday, August 6, 2015 2:44 AM
To: Asveren, Tolga; Roman Shpount; Rauschenbach, Uwe (Nokia - D= E/Munich)
Cc: ext Eric Rescorla; Christer Holmberg; Bernard Aboba; <rtcweb@ietf.org>
Subject: RE: [rtcweb] What the gateway draft should say about m= ux/non-mux

 

The concerned 3GPP WebRTC gatewa= y (3GPP 23.334/29.334) supports already RTP/RTCP transport multiplexing (si= nce 3GPP Release 12), i.e. should not be the limiting factor in this discussion. 

For ones interested in the RTCP = port allocation rules, see H.248.57:

Clause 7 describes RTP/RTCP tran= sport multiplexing. ITU-T H.248.57 is already supported by 3GPP 29.334.

 

The rationale behind the =93opti= onal tagging=94 by 23.228 is a third reason, beyond

>1. Using different QOS settings for R= TCP vs RTP

>2. Sending RTCP to a different device= from RTP

 

Don=92t want to go in the 3GPP s= pecific details, but it has nothing to do with the 3GPP UE-embedded WebRTC = client nor any constraints by 3GPP WebRTC gateways.

 

Thus, a WebRTC gateway MUST supp= ort RTP/RTCP transport multiplexing due to its purpose in interworking supp= ort.

 

Regards,

Albrecht

 

 

From: = Asveren, Tolga [= mailto:tasveren@sonusnet.com] =
Sent: Mittwoch, 5. August 2015 19:47
To: Roman Shpount; Rauschenbach, Uwe (Nokia - DE/Munich)
Cc: ext Eric Rescorla; Schwarz, Albrecht (Albrecht); Christer H= olmberg; Bernard Aboba; <rtcweb@ietf.org>
Subject: RE: [rtcweb] What the gateway draft should say about m= ux/non-mux

 

i- I humbl= y disagree that using different QoS RTCP/RTP, e.g. different DiffServ value= s , should be dismissed.

ii- Let me= also add another reason why no-rtcp-mux may be needed: Implementation diff= iculties in certain GWs.

 

Considerin= g that there is already a negotiation mechanism for rtcp-mux support, that = it can be de-facto mandated by the choice of browsers for Internet, I think what Christer/Albrecht suggested is the right way to= move forward: provide clarifications for vague points. I don=92t understan= d why lack of clarity in existing specifications should cause imposing rest= rictions. This would be akin to dropping a feature due to a bug. In this case, the =93bug=94 is lack of clarity in = normative specifications and it can be addressed by further specification.<= /span>

 

Thanks,

Tolga

 

From:&nbs= p;Roman Shpount [mailto:roman@telurix.com] 
Sent: Wednesday, August 05, 2015 12:29 PM
To: Rauschenbach, Uwe (Nokia - DE/Munich) <uwe.rauschenbach@nokia.com>
Cc: ext Eric Rescorla <ekr@rtfm.com>; Schw= arz, Albrecht (Albrecht) <albrecht.schwarz@al= catel-lucent.com>; Asveren, Tolga <tasveren@sonusnet.com>; Chri= ster Holmberg <christer.holmberg@ericsson.com>; Bernard Aboba <bernard.aboba@gmail.com>; &= lt;rtcweb@ietf.org> <rtcweb@ietf.org<= /a>>
Subject: Re: [rtcweb] What the gateway draft should say about m= ux/non-mux

 

Media gateway implementati= ons according to 3GPP TS 23.228 may not support rtcp-mux, as rtcp-mux is optional there.

So if we drop non-mux supp= ort from web browsers, those media gateways that have not implemented rtcp-= mux will stop interoperating. 

 

 

First of all, do you know of any WebRTC t= o IMS gateways that do not implement rtcp-mux on the WebRTC side? I strongl= y suspect there are none.

 

Second, the only reasons not to use rtcp-= mux that I can think of are the following:

 

1. Using different QOS settings for RTCP = vs RTP

2. Sending RTCP to a different device fro= m RTP

 

I do not think the first use case warrant= s making rtcp-mux optional, since, practically no one does this.

Second use case is also fairly marginal. = Plus it can be handled by the gateway which can send RTCP to one device and= RTP to another.

 

So, unless someone can come up with a use= case why RTP and RTCP should use different transports, I think rtcp-mux sh= ould be mandatory.

 

Regards,

______________

Roman Shpount

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

 

 


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

 

--_000_SN1PR0301MB155138665B1A591BFD715892B2740SN1PR0301MB1551_-- From nobody Thu Aug 6 10:44:05 2015 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9B3171A21AC for ; Thu, 6 Aug 2015 10:44:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.388 X-Spam-Level: X-Spam-Status: No, score=-1.388 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id r-uozHAleh9u for ; Thu, 6 Aug 2015 10:44:02 -0700 (PDT) Received: from mail-oi0-x22c.google.com (mail-oi0-x22c.google.com [IPv6:2607:f8b0:4003:c06::22c]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CF4F01B31D7 for ; Thu, 6 Aug 2015 10:44:01 -0700 (PDT) Received: by oio137 with SMTP id 137so40302974oio.0 for ; Thu, 06 Aug 2015 10:44:01 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=BnWGr20W2LV3/bsE+4X5fHT1dG/qLM5+REqs0R3QJWA=; b=ms7yqDCSAjHyjIqVjzr5IR+e6fvk71srcJGnYuYjZG5Rlmds0fLl8HpVFW0efIWH3e YSeQYwaXg3iAcekk6BzK5RhwDHmVPA4fKUMs8djjj2U20Uz0VWjfqiWSiJditv5P1/g/ JsAmzaCA1ByF/fPfu7oT1RyXpQY2hnQtXIyIgBgnSzHecs2CPQLDBc8Uz7YKJRWFNx9m GXwxwFG2NU5DQWWPbJOEYgL+aNX0b76ByA2ubxjZ38yeBW3DS7xSJL8VzFpD1EYvctvG 5GMsysaTPLPpCl2OdsHrSabetILiJR8de9x3fxfprV8kOmQo9l3frjJKTI8EYjuPd5fh SSLQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type; bh=BnWGr20W2LV3/bsE+4X5fHT1dG/qLM5+REqs0R3QJWA=; b=HSG4L1gX8nF00d5EuQMbqG49tqQHwZc1oSR/Wsx3Mnmv/w6S3TsAy2s4FXI8AlmE6t IllohSjMcASIZxsR4gCcb6aItX9V5W4ANcP+17dOzoepfYjAwP0/XBwuW6C221X1t0Gp DVOft/aE8YGdLXQ1/nhCYhiwD/MVjy7kiZr0hT2wxXL6zhsSFMUr+elfz5yubnhHIcPQ qDwPSoenqIEbu7DrKSYR3rIuk+BH3sLA8Frh/Lwu+1HosC2wTPAtkfadWtMTpuFS2S3k OJBi/Ue0RCwltONFw0iwu4yMh91XnvMld1g5dfBbKkHA1zmvu1A4/16+La3IMPRYFzeC 2PoQ== X-Gm-Message-State: ALoCoQkhwKAPW6m8io4V//3/wFsje78cu+OPrCh4tsVRR8jqyTbgCl+0cZdUE/wfvXHMDQuRoXHU X-Received: by 10.202.15.11 with SMTP id 11mr2681440oip.127.1438883041245; Thu, 06 Aug 2015 10:44:01 -0700 (PDT) MIME-Version: 1.0 Received: by 10.76.62.110 with HTTP; Thu, 6 Aug 2015 10:43:21 -0700 (PDT) In-Reply-To: References: <9F33F40F6F2CD847824537F3C4E37DDF1E826A00@MCHP04MSX.global-ad.net> <55C3644D.8040903@jive.com> From: Peter Thatcher Date: Thu, 6 Aug 2015 10:43:21 -0700 Message-ID: To: Jonathan Lennox Content-Type: multipart/alternative; boundary=001a113d1d388c348a051ca81052 Archived-At: Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] What the gateway draft should say about mux/non-mux X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 06 Aug 2015 17:44:03 -0000 --001a113d1d388c348a051ca81052 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable We have "bundle-only". It would be pretty simply to define "rtcp-mux-only", if we think it's worth the effort. On Thu, Aug 6, 2015 at 7:33 AM, Jonathan Lennox wrote: > > > On Aug 6, 2015, at 9:42 AM, Simon Perreault wrote= : > > > > Le 2015-08-06 09:30, Hutton, Andrew a =C3=A9crit : > >> If we had thought about this at the time we mandated DTLS-SRTP then we > >> would have mandated rtp-mux at the same time but unfortunately we didn= =E2=80=99t > >> but we can fix that now. > > > > To be clear, rtcp-mux is already mandatory. It's non-mux that needs to > > be made optional. > > > > https://tools.ietf.org/html/draft-ietf-rtcweb-rtp-usage-25#section-4.5 > > The problem is that there=E2=80=99s no way in SDP for an offerer to expre= ss the > difference between =E2=80=9CI=E2=80=99d like to do RTCP-mux, but I=E2=80= =99m willing to fall back > to non-muxed=E2=80=9D and =E2=80=9CI only support RTCP-mux, and if you ca= n=E2=80=99t do it please > reject my offer.=E2=80=9D > > This is a general consequence of the fact that SDP has no > comprehension-mandatory attributes. (We were able to get away with this > for DTLS-SRTP because the =E2=80=9Cproto=E2=80=9D field is single-valued = and thus > effectively comprehension-mandatory.) > _______________________________________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/listinfo/rtcweb > --001a113d1d388c348a051ca81052 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
We have "bundle-only".=C2=A0 It would be pret= ty simply to define "rtcp-mux-only", if we think it's worth t= he effort.=C2=A0

On Thu, Aug 6, 2015 at 7:33 AM, Jonathan Lennox <jonathan@vidy= o.com> wrote:

> On Aug 6, 2015, at 9:42 AM, Simon Perreault <sperreault@jive.com> wrote:
>
> Le 2015-08-06 09:30, Hutton, Andrew a =C3=A9crit :
>> If we had thought about this at the time we mandated DTLS-SRTP the= n we
>> would have mandated rtp-mux at the same time but unfortunately we = didn=E2=80=99t
>> but we can fix that now.
>
> To be clear, rtcp-mux is already mandatory. It's non-mux that need= s to
> be made optional.
>
> https://tools.ietf.org/ht= ml/draft-ietf-rtcweb-rtp-usage-25#section-4.5

The problem is that there=E2=80=99s no way in SDP for an offerer to = express the difference between =E2=80=9CI=E2=80=99d like to do RTCP-mux, bu= t I=E2=80=99m willing to fall back to non-muxed=E2=80=9D and =E2=80=9CI onl= y support RTCP-mux, and if you can=E2=80=99t do it please reject my offer.= =E2=80=9D

This is a general consequence of the fact that SDP has no comprehension-man= datory attributes.=C2=A0 (We were able to get away with this for DTLS-SRTP = because the =E2=80=9Cproto=E2=80=9D field is single-valued and thus effecti= vely comprehension-mandatory.)
___________________________________= ____________
rtcweb mailing list
rtcweb@ietf.org
https://www.ietf.org/mailman/listinfo/rtcweb

--001a113d1d388c348a051ca81052-- From nobody Thu Aug 6 12:18:25 2015 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 32AE31A8AFB for ; Thu, 6 Aug 2015 12:18:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.2 X-Spam-Level: X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WLu_ZOhiQf1G for ; Thu, 6 Aug 2015 12:18:22 -0700 (PDT) Received: from sesbmg22.ericsson.net (sesbmg22.ericsson.net [193.180.251.48]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BC6D31A8AF4 for ; Thu, 6 Aug 2015 12:18:21 -0700 (PDT) X-AuditID: c1b4fb30-f79706d000007227-51-55c3b2fba731 Received: from ESESSHC007.ericsson.se (Unknown_Domain [153.88.253.124]) by sesbmg22.ericsson.net (Symantec Mail Security) with SMTP id 1A.23.29223.BF2B3C55; Thu, 6 Aug 2015 21:18:20 +0200 (CEST) Received: from ESESSMB209.ericsson.se ([169.254.9.36]) by ESESSHC007.ericsson.se ([153.88.183.39]) with mapi id 14.03.0210.002; Thu, 6 Aug 2015 21:18:19 +0200 From: Christer Holmberg To: Peter Thatcher , Jonathan Lennox Thread-Topic: [rtcweb] What the gateway draft should say about mux/non-mux Thread-Index: AQHQy78thNOz8AYdMEys1nzX7WTf2J316g6A///gJYCAAAJzgIAAAVWAgAABfoCAA/DZAIAAQVMAgAL8GACAAIDGAIAAFdwAgADZaQCAACrOgIAAJh8A///v2QCAABLZAIAAEy6AgAAKf4CAAANpgIAADisAgAA1GICAADwP5w== Date: Thu, 6 Aug 2015 19:18:18 +0000 Message-ID: <7594FB04B1934943A5C02806D1A2204B348EB8DD@ESESSMB209.ericsson.se> References: <9F33F40F6F2CD847824537F3C4E37DDF1E826A00@MCHP04MSX.global-ad.net> <55C3644D.8040903@jive.com> , In-Reply-To: Accept-Language: en-US Content-Language: en-GB X-MS-Has-Attach: X-MS-TNEF-Correlator: Content-Type: multipart/alternative; boundary="_000_7594FB04B1934943A5C02806D1A2204B348EB8DDESESSMB209erics_" MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFmpkkeLIzCtJLcpLzFFi42KZGfG3RvfPpsOhBpvyLfYvPs9scW35a1aL tf/a2R2YPRZsKvVYsuQnk0fbszvsAcxRXDYpqTmZZalF+nYJXBkd+3eyFLwwqui/85uxgbFF p4uRk0NCwESia8cZVghbTOLCvfVsXYxcHEICRxklts7fxgThLGKUWH9qE3sXIwcHm4CFRPc/ bZAGEYFAiZk3vzKC2MwC6hJ3Fp9jB7GFBTwlbnUuZoKo8ZJY9/0aM8gcEYFdjBKfZr4HK2IR UJG42HSSEWQmr4CvRNd1JYhd35gkljzbwwwS5wRaMHFLKkg5I9Bx30+tYYLYJS7R9GUl1NEC Ekv2nGeGsEUlXj7+xwpRky+xb+IEsFW8AoISJ2c+YZnAKDILSfssJGWzkJRBxA0kvry/DWVr Syxb+JoZwtaX6H5/mglZfAEj+ypG0eLU4qTcdCMjvdSizOTi4vw8vbzUkk2MwDg7uOW3wQ7G l88dDzEKcDAq8fAu2H8oVIg1say4MvcQozQHi5I474zNeaFCAumJJanZqakFqUXxRaU5qcWH GJk4OKUaGH2OrEl8wXzw8SKpIs5Jto3/fbZcW2613HTTjKur/pd1ljHYrr/MOEklIyj0ic/F Bfftp31riO2ZGCAmp7pk5oF1W35dPXb493v9xKxTq36fcfzAtD3mQJ6krdnauFyDff7z8raL PZnn2h9weNLWDn316O1VgQvv+e062JlqOPdKhvRe7YTN9dOUWIozEg21mIuKEwE8VXVmlAIA AA== Archived-At: Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] What the gateway draft should say about mux/non-mux X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 06 Aug 2015 19:18:24 -0000 --_000_7594FB04B1934943A5C02806D1A2204B348EB8DDESESSMB209erics_ Content-Type: text/plain; charset="windows-1256" Content-Transfer-Encoding: quoted-printable I don't think we should do that, or soon people would want to have "only ta= gs" for every possible extension... :) bundle-only makes sense, because you can use it to ensure that you won't e= nd up with a large number of media 5-tuples. Regards, Christer Sent from my Windows Phone ________________________________ From: Peter Thatcher Sent: =FD06/=FD08/=FD2015 20:44 To: Jonathan Lennox Cc: rtcweb@ietf.org Subject: Re: [rtcweb] What the gateway draft should say about mux/non-mux We have "bundle-only". It would be pretty simply to define "rtcp-mux-only"= , if we think it's worth the effort. On Thu, Aug 6, 2015 at 7:33 AM, Jonathan Lennox > wrote: > On Aug 6, 2015, at 9:42 AM, Simon Perreault > wrote: > > Le 2015-08-06 09:30, Hutton, Andrew a =E9crit : >> If we had thought about this at the time we mandated DTLS-SRTP then we >> would have mandated rtp-mux at the same time but unfortunately we didn= =92t >> but we can fix that now. > > To be clear, rtcp-mux is already mandatory. It's non-mux that needs to > be made optional. > > https://tools.ietf.org/html/draft-ietf-rtcweb-rtp-usage-25#section-4.5 The problem is that there=92s no way in SDP for an offerer to express the d= ifference between =93I=92d like to do RTCP-mux, but I=92m willing to fall b= ack to non-muxed=94 and =93I only support RTCP-mux, and if you can=92t do i= t please reject my offer.=94 This is a general consequence of the fact that SDP has no comprehension-man= datory attributes. (We were able to get away with this for DTLS-SRTP becau= se the =93proto=94 field is single-valued and thus effectively comprehensio= n-mandatory.) _______________________________________________ rtcweb mailing list rtcweb@ietf.org https://www.ietf.org/mailman/listinfo/rtcweb --_000_7594FB04B1934943A5C02806D1A2204B348EB8DDESESSMB209erics_ Content-Type: text/html; charset="windows-1256" Content-Transfer-Encoding: quoted-printable
I don't think= we should do that, or soon people would want to have "only tags"= for every possible extension... :)

bundle-only makes sense,  because you can use it to ensure that you wo= n't end up with a large number of media 5-tuples.

Regards,

Christer

Sent from my Windows Phone
From: Peter Thatcher
Sent: =FD06= /=FD08/=FD2015 20:44
To: Jonathan Lennox
Cc: rtcweb@ietf.org
Subject: Re: [= rtcweb] What the gateway draft should say about mux/non-mux

 --001a11c245209cc3da051d4b8347-- From nobody Sun Aug 16 00:25:00 2015 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B9E431A8991 for ; Sun, 16 Aug 2015 00:24:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.201 X-Spam-Level: X-Spam-Status: No, score=-4.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YNZfovkCxZ9A for ; Sun, 16 Aug 2015 00:24:58 -0700 (PDT) Received: from sesbmg22.ericsson.net (sesbmg22.ericsson.net [193.180.251.48]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 85CA71A870B for ; Sun, 16 Aug 2015 00:24:57 -0700 (PDT) X-AuditID: c1b4fb30-f79626d000006adf-84-55d03ac78c01 Received: from ESESSHC001.ericsson.se (Unknown_Domain [153.88.253.124]) by sesbmg22.ericsson.net (Symantec Mail Security) with SMTP id BB.B3.27359.7CA30D55; Sun, 16 Aug 2015 09:24:55 +0200 (CEST) Received: from [127.0.0.1] (153.88.183.153) by smtp.internal.ericsson.com (153.88.183.23) with Microsoft SMTP Server id 14.3.210.2; Sun, 16 Aug 2015 09:24:54 +0200 To: Peter Thatcher , "" References: From: Magnus Westerlund Message-ID: <55D03AC6.4080100@ericsson.com> Date: Sun, 16 Aug 2015 09:24:54 +0200 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.1.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset="windows-1252"; format=flowed Content-Transfer-Encoding: 8bit X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFprKLMWRmVeSWpSXmKPExsUyM+Jvje5xqwuhBu+Oq1pcW/6a1WLtv3Z2 ByaPBZtKPZYs+ckUwBTFZZOSmpNZllqkb5fAlXH8nmTBAvGKj72bWRoYdwl1MXJwSAiYSFxo YO1i5AQyxSQu3FvP1sXIxSEkcJRRonviBBYIZzmjxJpd79lBqoQFPCVuL9wNZosIBEl0XpsE 1i0kECCx/f4HFhCbTcBC4uaPRjYQm1dAW6KltYcZxGYRUJV4eW4fE4gtKhAjMX/FdGaIGkGJ kzOfgPVyCgRKfPh4kgXkOGYBe4kHW8tAwswC8hLNW2czQ6zSlmho6mCdwCgwC0n3LISOWUg6 FjAyr2IULU4tTspNNzLSSy3KTC4uzs/Ty0st2cQIDMeDW34b7GB8+dzxEKMAB6MSD++Cd+dD hVgTy4orcw8xSnOwKInzzticFyokkJ5YkpqdmlqQWhRfVJqTWnyIkYmDU6qB0V61xn1yo+WB y2duhcssTWe2q2Nkess892wb19Hk/vNHubTi7Jw2+l8rEz/pLm007aP/vcCX/0283qdw2PBH 2O08o/BRL/DxpE1fv/FKdlz4qPiar/Me1/rl1T4TGvRXMDfOP6zlmB5m8/Fv2Kb7qcdmnGJY 2ZRduFbfUeRtUswuI8Mti7MWKrEUZyQaajEXFScCAIgG+yIoAgAA Archived-At: Subject: Re: [rtcweb] Do we have consensus on not requiring rtcp-non-mux? X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 16 Aug 2015 07:24:59 -0000 Hi, I am on vacation and just happened to see this. I will not follow up on on this until I am back in 1.5 weeks time (27th of Aug). So I do request that no conclusions are made until after I have had time to follow up on the discussion. I object to this change. It appears that no one remembers why it is important for a WebRTC endpoint to support the non-muxed mode for RTP and RTCP. Yes, this was discussed 3 years back and motivated. I think the interim in Stockholm is when we made this decision. The reason is why I see it is as very important that WebRTC endpoints support non-mux is that otherwise one creates an interoperability issue, possible future one. RTCP Mux can only work under some restrictions regarding the Payload Type (PT) assignment. A gateway between an endpoint doing mux and one not doing it will thus have be capable of rewriting PTs. As PTs sometimes have been included in RTCP formats, that requires the Gateway to understand and be capable of rewriting them. Thus, the gateway MUST understand everything that goes into the RTCP packet. This requirement prevents changes or additions to RTCP across gateways as it means that also the gateway has to be updated, not only having the capability in both endpoints. It also increases the complexity of the gateway. Cheers Magnus Den 2015-08-07 kl. 23:39, skrev Peter Thatcher: > After lots of discussion, it appears we have three options: > > 1. Endpoints MAY implement rtcp-non-mux (we change the spec and can > delete the ugly code) > > 2. Endpoints MUST NOT implement rtcp-non-mux (we change the spec and > must delete the ugly code, and our non-compliant until we do) > > 3. Endpoints MUST implement rtcp-non-mux (we don't change the spec and > keep around the ugly code) > > > My reading of the discussion is that most people want #1 or #2, and very > few people still want #3. Between #1 and #2, while some people would > prefer #2, there are good reasons to just do #1, and most seem to prefer > #1. Further, I'm guessing that most people who wanted #2 could live > with #1. > > > TL;DR: I think we may have rough consensus on #1, saying endpoints MAY > rtcp-non-mux (but may choose to delete all that ugly code instead). > > > So, is everyone happy with #1? > > > > > > _______________________________________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/listinfo/rtcweb > -- Magnus Westerlund ---------------------------------------------------------------------- Services, Media and Network features, Ericsson Research EAB/TXM ---------------------------------------------------------------------- Ericsson AB | Phone +46 10 7148287 Frgatan 6 | Mobile +46 73 0949079 SE-164 80 Stockholm, Sweden | mailto: magnus.westerlund@ericsson.com ---------------------------------------------------------------------- From nobody Sun Aug 16 20:44:30 2015 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 806A41B2AF6 for ; Sun, 16 Aug 2015 20:44:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.511 X-Spam-Level: X-Spam-Status: No, score=-14.511 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KzsFxASWnV_Z for ; Sun, 16 Aug 2015 20:44:28 -0700 (PDT) Received: from alln-iport-2.cisco.com (alln-iport-2.cisco.com [173.37.142.89]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 32A851B2AF3 for ; Sun, 16 Aug 2015 20:44:28 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=981; q=dns/txt; s=iport; t=1439783068; x=1440992668; h=from:to:subject:date:message-id:references:in-reply-to: content-id:content-transfer-encoding:mime-version; bh=BmIhn0mT9Y79gc18bK1djpdT1GWH4sBOgdn119E27CE=; b=Clto5lSFeBSmOXFvh8RM+cAQg80eQYnfvt1KnQcLMkySDw6cu7OO7DHi eo4THGkKH1Fds2CUPZriOb99SkGc0n1yJrhZEOhlvxeHTdfAHLv74lHN8 tdO0ivSh2wLPtjXrV2dr7foOGMNxLU1f6qXlM3pFKp3Hkwo/qbXOBZVxs o=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: A0CIAgDWV9FV/51dJa1dgxtUaQa9XwEJgWsKhS9KAoEqOBQBAQEBAQEBgQqEIwEBAQQBAQEaURcEAgEIEQMBAi8nCx0IAgQBEoguDc5cAQEBAQEBAQEBAQEBAQEBAQEBAQEBEwSLUoUQBoQmBZUdAYxrgUqEK5BLg2cmg31xgUiBBAEBAQ X-IronPort-AV: E=Sophos;i="5.15,692,1432598400"; d="scan'208";a="178612483" Received: from rcdn-core-6.cisco.com ([173.37.93.157]) by alln-iport-2.cisco.com with ESMTP; 17 Aug 2015 03:44:27 +0000 Received: from XCH-ALN-005.cisco.com (xch-aln-005.cisco.com [173.36.7.15]) by rcdn-core-6.cisco.com (8.14.5/8.14.5) with ESMTP id t7H3iRqR015618 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Mon, 17 Aug 2015 03:44:27 GMT Received: from xch-aln-005.cisco.com (173.36.7.15) by XCH-ALN-005.cisco.com (173.36.7.15) with Microsoft SMTP Server (TLS) id 15.0.1104.5; Sun, 16 Aug 2015 22:44:26 -0500 Received: from xhc-rcd-x15.cisco.com (173.37.183.89) by xch-aln-005.cisco.com (173.36.7.15) with Microsoft SMTP Server (TLS) id 15.0.1104.5 via Frontend Transport; Sun, 16 Aug 2015 22:44:26 -0500 Received: from xmb-aln-x05.cisco.com ([169.254.11.9]) by xhc-rcd-x15.cisco.com ([173.37.183.89]) with mapi id 14.03.0248.002; Sun, 16 Aug 2015 22:44:26 -0500 From: "Ram Mohan R (rmohanr)" To: Sean Turner , "rtcweb@ietf.org" Thread-Topic: [rtcweb] Call for WG adoption: draft-nandakumar-rtcweb-sdp Thread-Index: AQHQ2J8CwvJWLVUBqEeqDLWsvSJjtA== Date: Mon, 17 Aug 2015 03:44:25 +0000 Message-ID: References: <2C6E529A-7ECC-4919-973F-5ADFDEE4FA57@ieca.com> In-Reply-To: <2C6E529A-7ECC-4919-973F-5ADFDEE4FA57@ieca.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.5.3.150624 x-originating-ip: [173.36.7.18] Content-Type: text/plain; charset="Windows-1252" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Subject: Re: [rtcweb] Call for WG adoption: draft-nandakumar-rtcweb-sdp X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 17 Aug 2015 03:44:29 -0000 I support the adoption of this draft. Ram -----Original Message----- From: rtcweb on behalf of Sean Turner Date: Friday, 14 August 2015 7:09 pm To: "rtcweb@ietf.org" Subject: [rtcweb] Call for WG adoption: draft-nandakumar-rtcweb-sdp >All, > >At the second IETF 93 RTCweb session, we agreed to send a call for WG >adoption of draft-nandakumar-rtcweb-sdp after a week of review. Well >it=B9s been two weeks. So without further ado =8A Please respond to say >whether you support adoption of this work as a working group work item >and whether you will participate in the discussion. If you are opposed >to this draft becoming a WG document, please say so (and say why). >Please have your response in by 20150821 23:59 UTC. > >Thanks in advance! > >spt >_______________________________________________ >rtcweb mailing list >rtcweb@ietf.org >https://www.ietf.org/mailman/listinfo/rtcweb From nobody Sun Aug 16 21:11:25 2015 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 47A231A0099 for ; Sun, 16 Aug 2015 21:11:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.511 X-Spam-Level: X-Spam-Status: No, score=-14.511 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MdRL3mD2281l for ; Sun, 16 Aug 2015 21:11:22 -0700 (PDT) Received: from alln-iport-8.cisco.com (alln-iport-8.cisco.com [173.37.142.95]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D68A11A0095 for ; Sun, 16 Aug 2015 21:11:21 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1480; q=dns/txt; s=iport; t=1439784681; x=1440994281; h=from:to:subject:date:message-id:references:in-reply-to: content-transfer-encoding:mime-version; bh=HYLSBCo4x+pZ6Yk0t5bFWVUZa1UjTsQH0uMfw1oAqv0=; b=YA6xLc1jsJuvpwSDvphneZ8aiFHYhtuiNRjZbcVoRHtv9P1jVIhzkN20 wUacRrTts8yysREsHxDAOndPkcYPCkyoj3+EaX3kPxZdpGG5fScD2tgmF dCzUtu+2Q09qGC9QnpcRpNsuDrK+6nbBUGS8fAZ5xMzLL/IbWgOfM9pI6 0=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: A0CIAgAoXtFV/5FdJa1dgxtUaQa9XwEJgWsKhS9KAoEqOBQBAQEBAQEBgQqEIwEBAQQBAQEaURcEAgEIEQMBAQELHQcnCxQJCAIEARIIiCYNzl8BAQEBAQEBAQEBAQEBAQEBAQEBAQETBItShFg4BoMSgRQFlR0BjjWEK5BLg2cmg31xgUiBBAEBAQ X-IronPort-AV: E=Sophos;i="5.15,692,1432598400"; d="scan'208";a="179192902" Received: from rcdn-core-9.cisco.com ([173.37.93.145]) by alln-iport-8.cisco.com with ESMTP; 17 Aug 2015 04:11:21 +0000 Received: from XCH-ALN-005.cisco.com (xch-aln-005.cisco.com [173.36.7.15]) by rcdn-core-9.cisco.com (8.14.5/8.14.5) with ESMTP id t7H4BLOj012370 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Mon, 17 Aug 2015 04:11:21 GMT Received: from xch-aln-005.cisco.com (173.36.7.15) by XCH-ALN-005.cisco.com (173.36.7.15) with Microsoft SMTP Server (TLS) id 15.0.1104.5; Sun, 16 Aug 2015 23:11:20 -0500 Received: from xhc-aln-x05.cisco.com (173.36.12.79) by xch-aln-005.cisco.com (173.36.7.15) with Microsoft SMTP Server (TLS) id 15.0.1104.5 via Frontend Transport; Sun, 16 Aug 2015 23:11:20 -0500 Received: from xmb-rcd-x10.cisco.com ([169.254.15.53]) by xhc-aln-x05.cisco.com ([173.36.12.79]) with mapi id 14.03.0248.002; Sun, 16 Aug 2015 23:11:20 -0500 From: "Tirumaleswar Reddy (tireddy)" To: "Ram Mohan R (rmohanr)" , Sean Turner , "rtcweb@ietf.org" Thread-Topic: [rtcweb] Call for WG adoption: draft-nandakumar-rtcweb-sdp Thread-Index: AQHQ1pbBjNhq/44T2U6ixcyYEp3UhZ4P5KmA//+zo5A= Date: Mon, 17 Aug 2015 04:11:19 +0000 Message-ID: <913383AAA69FF945B8F946018B75898A478BFD5B@xmb-rcd-x10.cisco.com> References: <2C6E529A-7ECC-4919-973F-5ADFDEE4FA57@ieca.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.65.42.117] Content-Type: text/plain; charset="windows-1257" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Subject: Re: [rtcweb] Call for WG adoption: draft-nandakumar-rtcweb-sdp X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 17 Aug 2015 04:11:23 -0000 +1 -Tiru > -----Original Message----- > From: rtcweb [mailto:rtcweb-bounces@ietf.org] On Behalf Of Ram Mohan R > (rmohanr) > Sent: Monday, August 17, 2015 9:14 AM > To: Sean Turner; rtcweb@ietf.org > Subject: Re: [rtcweb] Call for WG adoption: draft-nandakumar-rtcweb-sdp >=20 > I support the adoption of this draft. >=20 > Ram >=20 > -----Original Message----- > From: rtcweb on behalf of Sean Turner > > Date: Friday, 14 August 2015 7:09 pm > To: "rtcweb@ietf.org" > Subject: [rtcweb] Call for WG adoption: draft-nandakumar-rtcweb-sdp >=20 > >All, > > > >At the second IETF 93 RTCweb session, we agreed to send a call for WG > >adoption of draft-nandakumar-rtcweb-sdp after a week of review. Well > >it=B9s been two weeks. So without further ado =D0 Please respond to say > >whether you support adoption of this work as a working group work item > >and whether you will participate in the discussion. If you are opposed > >to this draft becoming a WG document, please say so (and say why). > >Please have your response in by 20150821 23:59 UTC. > > > >Thanks in advance! > > > >spt > >_______________________________________________ > >rtcweb mailing list > >rtcweb@ietf.org > >https://www.ietf.org/mailman/listinfo/rtcweb >=20 > _______________________________________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/listinfo/rtcweb From nobody Mon Aug 17 01:39:48 2015 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D6F6B1A88AE for ; Mon, 17 Aug 2015 01:39:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.91 X-Spam-Level: X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wtl-3rUclIi9 for ; Mon, 17 Aug 2015 01:39:45 -0700 (PDT) Received: from mork.alvestrand.no (mork.alvestrand.no [IPv6:2001:700:1:2::117]) by ietfa.amsl.com (Postfix) with ESMTP id A11DB1A88AD for ; Mon, 17 Aug 2015 01:39:45 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mork.alvestrand.no (Postfix) with ESMTP id D3A567C36C0 for ; Mon, 17 Aug 2015 10:39:44 +0200 (CEST) X-Virus-Scanned: Debian amavisd-new at alvestrand.no Received: from mork.alvestrand.no ([127.0.0.1]) by localhost (mork.alvestrand.no [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zk71sqFHtgT9 for ; Mon, 17 Aug 2015 10:39:43 +0200 (CEST) Received: from hta-hippo.lul.corp.google.com (unknown [IPv6:2620:0:1043:1:7807:495b:62cb:90c2]) by mork.alvestrand.no (Postfix) with ESMTPSA id 9A6A47C35A2 for ; Mon, 17 Aug 2015 10:39:43 +0200 (CEST) Message-ID: <55D19DCF.3000406@alvestrand.no> Date: Mon, 17 Aug 2015 10:39:43 +0200 From: Harald Alvestrand User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.8.0 MIME-Version: 1.0 To: rtcweb@ietf.org References: <2C6E529A-7ECC-4919-973F-5ADFDEE4FA57@ieca.com> In-Reply-To: <2C6E529A-7ECC-4919-973F-5ADFDEE4FA57@ieca.com> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 8bit Archived-At: Subject: Re: [rtcweb] Call for WG adoption: draft-nandakumar-rtcweb-sdp X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 17 Aug 2015 08:39:47 -0000 I support adoption of this draft as a WG document. On 08/14/2015 03:39 PM, Sean Turner wrote: > All, > > At the second IETF 93 RTCweb session, we agreed to send a call for WG adoption of draft-nandakumar-rtcweb-sdp after a week of review. Well its been two weeks. So without further ado Please respond to say whether you support adoption of this work as a working group work item and whether you will participate in the discussion. If you are opposed to this draft becoming a WG document, please say so (and say why). Please have your response in by 20150821 23:59 UTC. > > Thanks in advance! > > spt > _______________________________________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/listinfo/rtcweb From nobody Mon Aug 17 12:13:54 2015 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 032B91A1A79 for ; Mon, 17 Aug 2015 12:13:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.201 X-Spam-Level: X-Spam-Status: No, score=-4.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DFXBmHTE2z-w for ; Mon, 17 Aug 2015 12:13:52 -0700 (PDT) Received: from sesbmg23.ericsson.net (sesbmg23.ericsson.net [193.180.251.37]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2A3711B2F39 for ; Mon, 17 Aug 2015 12:13:51 -0700 (PDT) X-AuditID: c1b4fb25-f79a26d00000149a-7a-55d2326ee23f Received: from ESESSHC023.ericsson.se (Unknown_Domain [153.88.253.124]) by sesbmg23.ericsson.net (Symantec Mail Security) with SMTP id 38.C9.05274.E6232D55; Mon, 17 Aug 2015 21:13:50 +0200 (CEST) Received: from ESESSMB209.ericsson.se ([169.254.9.111]) by ESESSHC023.ericsson.se ([153.88.183.87]) with mapi id 14.03.0210.002; Mon, 17 Aug 2015 21:13:49 +0200 From: Christer Holmberg To: "Tirumaleswar Reddy (tireddy)" , "Ram Mohan R (rmohanr)" , Sean Turner , "rtcweb@ietf.org" Thread-Topic: [rtcweb] Call for WG adoption: draft-nandakumar-rtcweb-sdp Thread-Index: AQHQ1pbAOHeUy2NEC02T3isNMIAbEZ4Pb1CAgAAHhICAAR25IA== Date: Mon, 17 Aug 2015 19:13:49 +0000 Message-ID: <7594FB04B1934943A5C02806D1A2204B34931CAD@ESESSMB209.ericsson.se> References: <2C6E529A-7ECC-4919-973F-5ADFDEE4FA57@ieca.com> <913383AAA69FF945B8F946018B75898A478BFD5B@xmb-rcd-x10.cisco.com> In-Reply-To: <913383AAA69FF945B8F946018B75898A478BFD5B@xmb-rcd-x10.cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [153.88.183.148] Content-Type: text/plain; charset="windows-1257" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFvrELMWRmVeSWpSXmKPExsUyM+JvjW6e0aVQgzvbxCyWd+1gtFj7r53d 4sTubYwWO85NYHFg8ZjyeyOrx505H1g9liz5yRTAHMVlk5Kak1mWWqRvl8CVsfnAZcaCI/wV l37PYW1g/MLTxcjJISFgIvFu/hdWCFtM4sK99WxdjFwcQgJHGSX2rX3CAuEsYZT4cu8Acxcj BwebgIVE9z9tkLiIwBpGiQNfLrKBdAsLuEtcW3cdbJKIgIfE8b42JgjbSeLV9B9gNSwCqhLr OyaA1fAK+Eq8670LtW0xo8SR1Y2MIAlOkMT67ewgNiPQSd9PrQEbxCwgLnHryXwmiFMFJJbs Oc8MYYtKvHz8D+oFJYnGJU9YIeoNJA6cWcoIYWtLLFv4mhlisaDEyZlPWCYwis5CMnYWkpZZ SFpmIWlZwMiyilG0OLU4KTfdyFgvtSgzubg4P08vL7VkEyMwkg5u+a26g/HyG8dDjAIcjEo8 vA/YL4YKsSaWFVfmHmKU5mBREuedsTkvVEggPbEkNTs1tSC1KL6oNCe1+BAjEwenVANjs0L/ Ub0Jz95za4Uzb91gfL5bMzLwh1rvZJOSS05eD4Xvivx5uXFT2OO1369cX7b45ac7C24dvCEv ff3+kXSR2bEt5o8N/+6eUCAyLfoKzw4+pjzOxvrtwa/Xtm+/5hxncFeA086enVXlI8u/Zc7e 7QwSqhxBpxO6jK79l0p+J/Lco++f5mtlJZbijERDLeai4kQAlFnmkoUCAAA= Archived-At: Subject: Re: [rtcweb] Call for WG adoption: draft-nandakumar-rtcweb-sdp X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 17 Aug 2015 19:13:54 -0000 +1 Regards, Christer -----Original Message----- From: rtcweb [mailto:rtcweb-bounces@ietf.org] On Behalf Of Tirumaleswar Red= dy (tireddy) Sent: 17 August 2015 07:11 To: Ram Mohan R (rmohanr) ; Sean Turner ; rtcweb@ietf.org Subject: Re: [rtcweb] Call for WG adoption: draft-nandakumar-rtcweb-sdp +1 -Tiru > -----Original Message----- > From: rtcweb [mailto:rtcweb-bounces@ietf.org] On Behalf Of Ram Mohan R > (rmohanr) > Sent: Monday, August 17, 2015 9:14 AM > To: Sean Turner; rtcweb@ietf.org > Subject: Re: [rtcweb] Call for WG adoption:=20 > draft-nandakumar-rtcweb-sdp >=20 > I support the adoption of this draft. >=20 > Ram >=20 > -----Original Message----- > From: rtcweb on behalf of Sean Turner=20 > > Date: Friday, 14 August 2015 7:09 pm > To: "rtcweb@ietf.org" > Subject: [rtcweb] Call for WG adoption: draft-nandakumar-rtcweb-sdp >=20 > >All, > > > >At the second IETF 93 RTCweb session, we agreed to send a call for WG=20 > >adoption of draft-nandakumar-rtcweb-sdp after a week of review. Well=20 > >it=B9s been two weeks. So without further ado =D0 Please respond to say= =20 > >whether you support adoption of this work as a working group work item > >and whether you will participate in the discussion. If you are opposed > >to this draft becoming a WG document, please say so (and say why). > >Please have your response in by 20150821 23:59 UTC. > > > >Thanks in advance! > > > >spt > >_______________________________________________ > >rtcweb mailing list > >rtcweb@ietf.org > >https://www.ietf.org/mailman/listinfo/rtcweb >=20 > _______________________________________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/listinfo/rtcweb _______________________________________________ rtcweb mailing list rtcweb@ietf.org https://www.ietf.org/mailman/listinfo/rtcweb From nobody Mon Aug 17 15:54:37 2015 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9A4BE1ACEF9 for ; Mon, 17 Aug 2015 15:54:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.388 X-Spam-Level: X-Spam-Status: No, score=-1.388 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PHNPq3jmMRDo for ; Mon, 17 Aug 2015 15:54:27 -0700 (PDT) Received: from mail-ob0-x22c.google.com (mail-ob0-x22c.google.com [IPv6:2607:f8b0:4003:c01::22c]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CF27F1ACEF4 for ; Mon, 17 Aug 2015 15:54:21 -0700 (PDT) Received: by obbhe7 with SMTP id he7so125838899obb.0 for ; Mon, 17 Aug 2015 15:54:21 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=OMa5levttaDq8/nb4JotNDr9BgWE6rZ11BM6zGV5b6w=; b=j6sPvnsDV0Poe5ARVIHiUOHhgdXLPe0kcclqe/N41LBfyZYh2iJp2m1WdlIz84P+h5 DHhJwTJBx2vmBE1rzhVxhAyU8BdRoraCP+90kqme73F5zBRNrCWDtwdu0Uz9ICd794YS /mwLX1IGCDl8zX1HfpS4Fc7+PvBmcSScYxxNjv4wrSIvu6nIl8VZa3hNIy7g0sfgkBFa WyhoAMcAiPlE4PmM7tS9gfL1HgRYAUAeI66RKNnC4qPUt/k4KU41vgXZds6ufMNJ9AqD IrWwVpP9HbZiD28AwUVikXvoQG3zVuOGWjQCzakLlkO4Cp/MsLuCY3ztQigV92qV2/vM weNw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type; bh=OMa5levttaDq8/nb4JotNDr9BgWE6rZ11BM6zGV5b6w=; b=HwJOK8NJsYIo8Yau80YhZiIBHtciyoeqlogqYy5rhEY28hzLWzR83OMjJAc/VlvqFc 2EbXwlw4OHcYIfF69n7Zoop2XPKISjkokDZZZ6I7wDp7gFf4faA/Wlk5vgZ4lDvgR4ln 755Ghk0HsoZVqomouRqbXPN6doqLHOCGlyxbPTSjfX64cpoHAy+JcaMBuMWw8r58z/yU 1+t6CXdQigD7kSYUJCJjlfwjeJH4DaEAzoLr4i+3wnRH3LUK6AMraNe0E+SoF7pW0AjY qxt4k4VLGqG6CuFtLunm6wVa8xu4VL8/BPZMk+bYAKqmTKyKOewPiZrQWEw3OHlgkM0j 9CxQ== X-Gm-Message-State: ALoCoQk9kMECWeGdfJ5XX1q4dobCZntFTgy9DG1hmOtRMkUrBR2v88H9oGtaZC/6VzsAqz9qFEYm X-Received: by 10.60.79.193 with SMTP id l1mr3156822oex.60.1439852061115; Mon, 17 Aug 2015 15:54:21 -0700 (PDT) MIME-Version: 1.0 Received: by 10.76.62.110 with HTTP; Mon, 17 Aug 2015 15:53:41 -0700 (PDT) In-Reply-To: <55D03AC6.4080100@ericsson.com> References: <55D03AC6.4080100@ericsson.com> From: Peter Thatcher Date: Mon, 17 Aug 2015 15:53:41 -0700 Message-ID: To: Magnus Westerlund Content-Type: multipart/alternative; boundary=089e01177373a22b25051d89aeab Archived-At: Cc: "" Subject: Re: [rtcweb] Do we have consensus on not requiring rtcp-non-mux? X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 17 Aug 2015 22:54:29 -0000 --089e01177373a22b25051d89aeab Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On Sun, Aug 16, 2015 at 12:24 AM, Magnus Westerlund < magnus.westerlund@ericsson.com> wrote: > Hi, > > I am on vacation and just happened to see this. I will not follow up on o= n > this until I am back in 1.5 weeks time (27th of Aug). So I do request tha= t > no conclusions are made until after I have had time to follow up on the > discussion. > > I object to this change. It appears that no one remembers why it is > important for a WebRTC endpoint to support the non-muxed mode for RTP and > RTCP. Yes, this was discussed 3 years back and motivated. I think the > interim in Stockholm is when we made this decision. > =E2=80=8BThere are meaningful differences between then and now that made th= is discussion appropriate: 1. DTLS is mandatory. 2. At IETF 93, Cullen said he looked into it thoroughly and found that every endpoint that he could find that can speak DTLS can also speak RTCP-mux. 3. Our multi-year implementation experience is that RTCP non-mux has a very significant code complexity cost. > The reason is why I see it is as very important that WebRTC endpoints > support non-mux is that otherwise one creates an interoperability issue, > possible future one. RTCP Mux can only work under some restrictions > regarding the Payload Type (PT) assignment. A gateway between an endpoint > doing mux and one not doing it will thus have be capable of rewriting PTs= . > As PTs sometimes have been included in RTCP formats, that requires the > Gateway to understand and be capable of rewriting them. Thus, the gateway > MUST understand everything that goes into the RTCP packet. This requireme= nt > prevents changes or additions to RTCP across gateways as it means that al= so > the gateway has to be updated, not only having the capability in both > endpoints. It also increases the complexity of the gateway. > > =E2=80=8BPlease correct me if I'm wrong, but I believe this is only a probl= em if the RTP endpoints choose PTs in the range 64-95. RFC 5761 says "for the choice of RTP payload type values ... values in the range 64-95 MUST NOT be used". If so, are we really only concerning ourselves with code complexity for gateways that speak to RTCWEB endpoints one end and legacy RTP endpoints that don't follow 5761 on the other end? If it's a question of "possible future" code complexity in gateways versus very real code complexity that is slowing down RTCWEB implementations today, I'm in favor of removing the real code complexity we have now and taking the chance on the possible future code complexity, because it's a very real possibility that possible future code complexity will never be necessary. In the end, it might be easier to just not choose PTs inside the range 64-95. > Cheers > > Magnus > > > > Den 2015-08-07 kl. 23:39, skrev Peter Thatcher: > >> After lots of discussion, it appears we have three options: >> >> 1. Endpoints MAY implement rtcp-non-mux (we change the spec and can >> delete the ugly code) >> >> 2. Endpoints MUST NOT implement rtcp-non-mux (we change the spec and >> must delete the ugly code, and our non-compliant until we do) >> >> 3. Endpoints MUST implement rtcp-non-mux (we don't change the spec and >> keep around the ugly code) >> >> >> My reading of the discussion is that most people want #1 or #2, and very >> few people still want #3. Between #1 and #2, while some people would >> prefer #2, there are good reasons to just do #1, and most seem to prefer >> #1. Further, I'm guessing that most people who wanted #2 could live >> with #1. >> >> >> TL;DR: I think we may have rough consensus on #1, saying endpoints MAY >> rtcp-non-mux (but may choose to delete all that ugly code instead). >> >> >> So, is everyone happy with #1? >> >> >> >> >> >> _______________________________________________ >> rtcweb mailing list >> rtcweb@ietf.org >> https://www.ietf.org/mailman/listinfo/rtcweb >> >> > > -- > > Magnus Westerlund > > ---------------------------------------------------------------------- > Services, Media and Network features, Ericsson Research EAB/TXM > ---------------------------------------------------------------------- > Ericsson AB | Phone +46 10 7148287 > F=C3=A4r=C3=B6gatan 6 | Mobile +46 73 0949079 > SE-164 80 Stockholm, Sweden | mailto: magnus.westerlund@ericsson.com > ---------------------------------------------------------------------- > > --089e01177373a22b25051d89aeab Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


On Sun, Aug 16, 2015 at 12:24 AM, Magnus Westerlund <magnus.westerlund@ericsson.com> wrote:
Hi,

I am on vacation and just happened to see this. I will not follow up on on = this until I am back in 1.5 weeks time (27th of Aug). So I do request that = no conclusions are made until after I have had time to follow up on the dis= cussion.

I object to this change. It appears that no one remembers why it is importa= nt for a WebRTC endpoint to support the non-muxed mode for RTP and RTCP. Ye= s, this was discussed 3 years back and motivated. I think the interim in St= ockholm is when we made this decision.

=
=E2=80=8BThere are meaningful differences between then and now that made= this discussion appropriate:

1.=C2=A0 DTLS is mandato= ry.

2.=C2=A0 At IETF 93, Cullen said he looked into it= thoroughly and found that every endpoint that he could find that can speak= DTLS can also speak RTCP-mux.

3.=C2=A0 Our multi-year= implementation experience is that RTCP non-mux has a very significant code= complexity cost.

=C2=A0
The reason is why I see it is as very important that WebRTC endpoints suppo= rt non-mux is that otherwise one creates an interoperability issue, possibl= e future one. RTCP Mux can only work under some restrictions regarding the = Payload Type (PT) assignment. A gateway between an endpoint doing mux and o= ne not doing it will thus have be capable of rewriting PTs. As PTs sometime= s have been included in RTCP formats, that requires the Gateway to understa= nd and be capable of rewriting them. Thus, the gateway MUST understand ever= ything that goes into the RTCP packet. This requirement prevents changes or= additions to RTCP across gateways as it means that also the gateway has to= be updated, not only having the capability in both endpoints. It also incr= eases the complexity of the gateway.


=E2=80=8BPlease correct me if I'= ;m wrong, but I believe this is only a problem if the RTP endpoints choose = PTs in the range 64-95.=C2=A0 RFC 5761 says "for the choice of RTP pay= load type values ... values in the range 64-95 MUST NOT be used".=C2= =A0 If so, are we really only concerning ourselves with code complexity for= gateways that speak to RTCWEB endpoints one end and legacy RTP endpoints t= hat don't follow 5761 on the other end?=C2=A0

If i= t's a question of "possible future" code complexity in gatewa= ys versus very real code complexity that is slowing down RTCWEB implementat= ions today, I'm in favor of removing the real code complexity we have n= ow and taking the chance on the possible future code complexity, because it= 's a very real possibility that possible future code complexity will ne= ver be necessary. =C2=A0 In the end, it might be easier to just not choose = PTs inside the range 64-95.
=C2=A0=C2=A0

=C2=A0
Cheers

Magnus



Den 2015-08-07 kl. 23:39, skrev Peter Thatcher:
After lots of discussion, it appears we have three options:

1.=C2=A0 Endpoints MAY implement rtcp-non-mux (we change the spec and can delete the ugly code)

2.=C2=A0 Endpoints MUST NOT implement rtcp-non-mux (we change the spec and<= br> must delete the ugly code, and our non-compliant until we do)

3.=C2=A0 Endpoints MUST implement rtcp-non-mux (we don't change the spe= c and
keep around the ugly code)


My reading of the discussion is that most people want #1 or #2, and very few people still want #3.=C2=A0 =C2=A0Between #1 and #2, while some people = would
prefer #2, there are good reasons to just do #1, and most seem to prefer #1.=C2=A0 Further, I'm guessing that most people who wanted #2 could li= ve
with #1.


TL;DR:=C2=A0 I think we may have rough consensus on #1, saying endpoints MA= Y
rtcp-non-mux (but may choose to delete all that ugly code instead).


So, is everyone happy with #1?





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



--

Magnus Westerlund

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


We have "bundle-only".  It would be pretty simply to defi= ne "rtcp-mux-only", if we think it's worth the effort. 

On Thu, Aug 6, 2015 at 7:33 AM, Jonathan Lennox = <jonathan@vidyo.= com> wrote:

> On Aug 6, 2015, at 9:42 AM, Simon Perreault <sperreault@jive.com> wrote:
>
> Le 2015-08-06 09:30, Hutton, Andrew a =E9crit :
>> If we had thought about this at the time we mandated DTLS-SRTP the= n we
>> would have mandated rtp-mux at the same time but unfortunately we = didn=92t
>> but we can fix that now.
>
> To be clear, rtcp-mux is already mandatory. It's non-mux that needs to=
> be made optional.
>
> https://tools.ietf.org/html/draft-ietf-rtcweb-rtp-usage-25#section-4.5<= br>
The problem is that there=92s no way in SDP for an offerer to expres= s the difference between =93I=92d like to do RTCP-mux, but I=92m willing to= fall back to non-muxed=94 and =93I only support RTCP-mux, and if you can= =92t do it please reject my offer.=94

This is a general consequence of the fact that SDP has no comprehension-man= datory attributes.  (We were able to get away with this for DTLS-SRTP = because the =93proto=94 field is single-valued and thus effectively compreh= ension-mandatory.)
_______________________________________________
rtcweb mailing list
rtcweb@ietf.org
https://www.ietf.org/mailman/listinfo/rtcweb

--_000_7594FB04B1934943A5C02806D1A2204B348EB8DDESESSMB209erics_-- From nobody Thu Aug 6 12:23:18 2015 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7B3181A905F for ; Thu, 6 Aug 2015 12:23:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.2 X-Spam-Level: X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ohA46DZIVU2u for ; Thu, 6 Aug 2015 12:23:10 -0700 (PDT) Received: from sessmg22.ericsson.net (sessmg22.ericsson.net [193.180.251.58]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5C41C1A9053 for ; Thu, 6 Aug 2015 12:23:09 -0700 (PDT) X-AuditID: c1b4fb3a-f79356d000006281-a4-55c3b41be18c Received: from ESESSHC015.ericsson.se (Unknown_Domain [153.88.253.124]) by sessmg22.ericsson.net (Symantec Mail Security) with SMTP id B9.48.25217.B14B3C55; Thu, 6 Aug 2015 21:23:07 +0200 (CEST) Received: from ESESSMB209.ericsson.se ([169.254.9.36]) by ESESSHC015.ericsson.se ([153.88.183.63]) with mapi id 14.03.0210.002; Thu, 6 Aug 2015 21:23:07 +0200 From: Christer Holmberg To: "Asveren, Tolga" , Eric Rescorla Thread-Topic: [rtcweb] What the gateway draft should say about mux/non-mux Thread-Index: AQHQy78thNOz8AYdMEys1nzX7WTf2J316g6A///gJYCAAAJzgIAAAVWAgAABfoCAA/DZAIAAQVMAgAL8GACAAIDGAIAAFdwAgADZaQCAACrOgIAAJh8A///v2QCAABLZAIAAEy6AgAAKf4CAAAo/gIAAAXuAgAAGkgCAAARvAIAAQvzH///rkYAAB9lLBw== Date: Thu, 6 Aug 2015 19:23:06 +0000 Message-ID: <7594FB04B1934943A5C02806D1A2204B348EB92E@ESESSMB209.ericsson.se> References: <9F33F40F6F2CD847824537F3C4E37DDF1E826A00@MCHP04MSX.global-ad.net> <7515AC50-14F3-43C4-B3D9-D785100FC9C5@phonefromhere.com> , <7594FB04B1934943A5C02806D1A2204B348EB645@ESESSMB209.ericsson.se>, In-Reply-To: Accept-Language: en-US Content-Language: en-GB X-MS-Has-Attach: X-MS-TNEF-Correlator: Content-Type: multipart/alternative; boundary="_000_7594FB04B1934943A5C02806D1A2204B348EB92EESESSMB209erics_" MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFmphkeLIzCtJLcpLzFFi42KZGfG3Rld6y+FQg4U9GhYrXp9jt1j7r53d YnbneyYHZo8lS34yeUx+3Mbscenzf/YA5igum5TUnMyy1CJ9uwSujL93djMWHH7JXDHjRCtL A+P8dcxdjJwcEgImEo1Lb0HZYhIX7q1n62Lk4hASOMooseR1ByOEs4hR4vzSuyxdjBwcbAIW Et3/tEFMEQEviUdbc0B6mQU0JSYs28UGYgsLeErc6lzMBGKDlKz7fo0ZZIyIwDlGiU+HjrGA JFgEVCTerX8K1sAr4Ctx5fN7Fohdy1klOtZsB0twCiRKzPpwkhXEZgS67vupNUwQ28Qlmr6s ZIW4WkBiyZ7zUB+ISrx8/I8V5DhmgXyJnmUcEPMFJU7OfMIygVFkFpLuWQhVs5BUQZQYSJzb vpEdwtaWWLbwNTOErS+x/fZMVmTxBYzsqxhFi1OLi3PTjYz0Uosyk4uL8/P08lJLNjECo+3g lt9WOxgPPnc8xCjAwajEw7tg/6FQIdbEsuLK3EOM0hwsSuK8MzbnhQoJpCeWpGanphakFsUX leakFh9iZOLglGpg7NlUlzlHLf7YU/vzjL9nCH3kZE9crVN3xs35ZZXYlsQtN6/E3dj480ba 9p/vf3yt2nmEh5lbMm+G/WfdKa5xzwV8Nr6u/9yuvl6okUFDkYnrsqUN35Wnr5gdvvZODGWU O93Ff/oIW1mJ8iqb86dZk6QYl17PPrnc0qOO7/qKq/JhEbe1DQ/sU2Ipzkg01GIuKk4EAPvi Z2CXAgAA Archived-At: Cc: "" Subject: Re: [rtcweb] What the gateway draft should say about mux/non-mux X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 06 Aug 2015 19:23:16 -0000 --_000_7594FB04B1934943A5C02806D1A2204B348EB92EESESSMB209erics_ Content-Type: text/plain; charset="windows-1255" Content-Transfer-Encoding: quoted-printable Hi, Interoperability is achieved if implementations support the outcome of what= is negotiated. Regards, Christer Sent from my Windows Phone ________________________________ From: Asveren, Tolga Sent: =FD06/=FD08/=FD2015 20:38 To: Christer Holmberg; Eric Rescorla= Cc: Subject: RE: [rtcweb] What the gateway draft should say about mux/non-mux =93I don't want a standard which says "look what the browsers do and follow= ".=94 I don=92t want this either. =93I want a standard, when correctly implemented, ensures interoperability = with browsers (and other types of WebRTC entities).=94 And isn=92t this achieved mainly by rtcp-mux being a negotiated functionali= ty? Or maybe we have a different understanding of what =93interoperability= =94 means and you are referring to what I would call =93profiling=94, i.e. = selecting a subset of functionality from a (set of) specification(s) and ma= ndating it on elements, which claim to be compliant to that particular prof= ile. Thanks, Tolga From: Christer Holmberg [mailto:christer.holmberg@ericsson.com] Sent: Thursday, August 06, 2015 12:52 PM To: Asveren, Tolga ; Eric Rescorla Cc: Subject: RE: [rtcweb] What the gateway draft should say about mux/non-mux Hi, As an implementer, and as an IETF participant, I don't want a standard whic= h says "look what the browsers do and follow". That will only cause trouble= - especially if different browsers do different things. I want a standard,= when correctly implemented, ensures interoperability with browsers (and ot= her types of WebRTC entities). Implementations that only need to work in specific environments can of cour= se do whatever they want, but I don't think we consider e.g. Chrome and Fir= efox such implementations. Regards, Christer Sent from my Windows Phone ________________________________ From: Asveren, Tolga Sent: =FD06/=FD08/=FD2015 17:52 To: Eric Rescorla Cc: Subject: Re: [rtcweb] What the gateway draft should say about mux/non-mux In practice =96if not as initially targeted- a WebRTC-endpoint does not nec= essarily mean a =93browser=94. I completely agree with our statements about= browser based deployments though. All I am saying is =93Let people decide = what they want to support, they are smart enough to know what a particular = deployment model requires=94. For example, regardless of what specification= s say, non-browser equipment vendors, whose products need to interoperate w= ith browsers, are following/implementing how Chrome/Firefox are behaving. Thanks, Tolga From: Eric Rescorla [mailto:ekr@rtfm.com] Sent: Thursday, August 06, 2015 10:36 AM To: Asveren, Tolga > Cc: tim panton >; Hutto= n, Andrew >; > > Subject: Re: [rtcweb] What the gateway draft should say about mux/non-mux I feel like people are talking past each other here. The browser vendors (at least Chrome and Firefox) want to completely remove= support for non-mux from their code. If we make this change, that means that there will= be no way for a browser to do non-mux and so as a practical matter we might as well simply = say that WebRTC is mux and hence for the WebRTC side of a WebRTC gateway, there is s= imilarly no need to support non-mux, This only leaves the question of the non-WebRTC si= de of the gateway, but that's out of scope here. So, I'm not sure what you are as= king for. WRT to the issue Jonathan raises about SDP being a negotiation, that's true= , but as a practical matter we're already far down the road of WebRTC offerers offer= ing SDP which in principle the answerer might choose not to accept but if it does s= o the connection will fail -Ekr On Thu, Aug 6, 2015 at 7:12 AM, Asveren, Tolga > wrote: I think implementers themselves can weigh out the advantages/disadvantaged/= deployment models they are targeting/etc=85 and decide what to support/not = to support. I don=92t see any issue with this as long as there is a negotia= tion mechanism (which there is). I don=92t think the availability of negoti= ation is encouraging people this or that way. Thanks, Tolga From: tim panton [mailto:tim@phonefromhere.com] Sent: Thursday, August 06, 2015 10:07 AM To: Hutton, Andrew = > Cc: Asveren, Tolga >; <= rtcweb@ietf.org> > Subject: Re: [rtcweb] What the gateway draft should say about mux/non-mux On 6 Aug 2015, at 08:30, Hutton, Andrew > wrote: +1 to what Tim said. I don=92t think this discussion is really about gateways at all it is surel= y about whether WebRTC browsers have to support non-mux and I don=92t reall= y see any good reason why they need to. If we had thought about this at the time we mandated DTLS-SRTP then we woul= d have mandated rtp-mux at the same time but unfortunately we didn=92t but = we can fix that now. Sadly true, but the situation in a browser is manageable since you might ex= pect 10 peer connections, resulting in a worst case of 60 UDP ports/DTLS sessions in use (assuming voice+video+data unbundled and RTCP-non-mux vs the 10 needed). We also assume a relatively well endowed CPU - devoted largely to this task. On the gateway you=92d hope to have thousands of sessions and presumably mu= ch less CPU/memory resource per channel. So while I think it is unfortunate that browsers can do non-mux, it would b= e plain stupid to do that on a gateway. Do we really want to encourage that ? T. Andy From: rtcweb [mailto:rtcweb-bounces@ietf.org] On Behalf Of tim panton Sent: 06 August 2015 13:53 To: Asveren, Tolga Cc: > Subject: Re: [rtcweb] What the gateway draft should say about mux/non-mux So we are positing the existence of a webRTC gateway designed to support th= ousands of calls which does ICE and DTLS but the designer decided deliberately to double the number of ICE sessions required= and double the number of DTLS sessions (and key generation costs) so that they can run RTCP (over ICE and DTLS) on a separa= te port. In my estimation that=92s one poor decision and should not be used as the basis of this (or any) standard. I=92d rather not support rtcp-no-mux as I see zero advantages in having it.= (I know theoretically it might be possible to get a RTCP packet through a congested net on a different port with a separate d= iffserv setting but that just seems so contrived). Tim. On 6 Aug 2015, at 06:44, Asveren, Tolga > wrote: These assumptions are not necessarily true in a universal sense (like almos= t any other assumption about different deployment models). Furthermore, and more importantly, there is nothing mandating WebRTC endpoi= nts to support non-rtcp-mux. It is a negotiated functionality. Any entity c= an enforce rtcp-mux as a local policy. The issue with supporting non-rtcp-mux seems to be lack of clarity in the r= elevant specifications. Fixing this =96regardless of the outcome of any oth= er discussion- seems to be prudent IMHO. Thanks, Tolga From: Wyss, Felix [mailto:Felix.Wyss@inin.com] Sent: Thursday, August 06, 2015 6:37 AM To: Christer Holmberg >; Asveren, Tolga >; Schwarz, Albrecht (Albrecht) >; Roman Shpount >; Rauschenbach, Uwe (Nokia - DE/Munich)= > Cc: > > Subject: Re: [rtcweb] What the gateway draft should say about mux/non-mux Why shouldn't the gateway be required to do the mux/demux? Making the WebR= TC endpoints a lot more complex just so the legacy interop might potentiall= y be a teeny-tiny bit easier makes no sense IMHO. Actually, the gateway wo= uld not be able to do "end-to-end" pass-through anyway as legacy equipment = will either be unencrypted or use SDES (RFC#4568) for key exchange. So the= gateway will have to perform DTLS-SRTP to SDES-SRTP transcryption--which a= lready is way more hassle than RTP/RTCP mux/demux. --Felix ________________________________ From: rtcweb > on b= ehalf of Christer Holmberg > Sent: Thursday, August 6, 2015 05:51 To: Asveren, Tolga; Schwarz, Albrecht (Albrecht); Roman Shpount; Rauschenba= ch, Uwe (Nokia - DE/Munich) Cc: > Subject: Re: [rtcweb] What the gateway draft should say about mux/non-mux Hi, No matter whether the gateway supports RTP/RTCP mux or not, there are cases= where the legacy network/endpoints will not use RTP/RTCP mux, so I guess p= eople then would want to be able to negotiate non-mux =93end-to-end=94, rat= her than having the gateway to demux/mux RTP and RTCP. Regards, Christer From: Asveren, Tolga [mailto:tasveren@sonusnet.com] Sent: 6. elokuuta 2015 12:18 To: Schwarz, Albrecht (Albrecht); Roman Shpount; Rauschenbach, Uwe (Nokia -= DE/Munich) Cc: ext Eric Rescorla; Christer Holmberg; Bernard Aboba; > Subject: Re: [rtcweb] What the gateway draft should say about mux/non-mux Why should we consider 3GPP the sole "owner/user" of the term/entity WebRTC= -GW? I think it has a much more general meaning and use in practice. It can= refer to many different types of elements which can be deployed in many di= fferent environments, hence any attempt to define it strictly/restrict its = capabilities are futile IMHO. Thanks, Tolga ________________________________ From: Schwarz, Albrecht (Albrecht) > Sent: Thursday, August 6, 2015 2:44 AM To: Asveren, Tolga; Roman Shpount; Rauschenbach, Uwe (Nokia - DE/Munich) Cc: ext Eric Rescorla; Christer Holmberg; Bernard Aboba; > Subject: RE: [rtcweb] What the gateway draft should say about mux/non-mux The concerned 3GPP WebRTC gateway (3GPP 23.334/29.334) supports already RTP= /RTCP transport multiplexing (since 3GPP Release 12), i.e. should not be th= e limiting factor in this discussion. For ones interested in the RTCP port allocation rules, see H.248.57: https://www.itu.int/rec/dologin_pub.asp?lang=3De&id=3DT-REC-H.248.57-201410= -I!!PDF-E&type=3Ditems Clause 7 describes RTP/RTCP transport multiplexing. ITU-T H.248.57 is alrea= dy supported by 3GPP 29.334. The rationale behind the =93optional tagging=94 by 23.228 is a third reason= , beyond >1. Using different QOS settings for RTCP vs RTP >2. Sending RTCP to a different device from RTP Don=92t want to go in the 3GPP specific details, but it has nothing to do w= ith the 3GPP UE-embedded WebRTC client nor any constraints by 3GPP WebRTC g= ateways. Thus, a WebRTC gateway MUST support RTP/RTCP transport multiplexing due to = its purpose in interworking support. Regards, Albrecht From: Asveren, Tolga [mailto:tasveren@sonusnet.com] Sent: Mittwoch, 5. August 2015 19:47 To: Roman Shpount; Rauschenbach, Uwe (Nokia - DE/Munich) Cc: ext Eric Rescorla; Schwarz, Albrecht (Albrecht); Christer Holmberg; Ber= nard Aboba; > Subject: RE: [rtcweb] What the gateway draft should say about mux/non-mux i- I humbly disagree that using different QoS RTCP/RTP, e.g. different Diff= Serv values , should be dismissed. ii- Let me also add another reason why no-rtcp-mux may be needed: Implement= ation difficulties in certain GWs. Considering that there is already a negotiation mechanism for rtcp-mux supp= ort, that it can be de-facto mandated by the choice of browsers for Interne= t, I think what Christer/Albrecht suggested is the right way to move forwar= d: provide clarifications for vague points. I don=92t understand why lack o= f clarity in existing specifications should cause imposing restrictions. Th= is would be akin to dropping a feature due to a bug. In this case, the =93b= ug=94 is lack of clarity in normative specifications and it can be addresse= d by further specification. Thanks, Tolga From: Roman Shpount [mailto:roman@telurix.com] Sent: Wednesday, August 05, 2015 12:29 PM To: Rauschenbach, Uwe (Nokia - DE/Munich) > Cc: ext Eric Rescorla >; Schwarz, Albrech= t (Albrecht) >; Asveren, Tolga >; Christer Holmberg >; Bernard Aboba >; > > Subject: Re: [rtcweb] What the gateway draft should say about mux/non-mux On Wed, Aug 5, 2015 at 4:47 AM, Rauschenbach, Uwe (Nokia - DE/Munich) > wrote: Media gateway implementations according to 3GPP TS 23.228 may not support r= tcp-mux, as rtcp-mux is optional there. So if we drop non-mux support from web browsers, those media gateways that = have not implemented rtcp-mux will stop interoperating. First of all, do you know of any WebRTC to IMS gateways that do not impleme= nt rtcp-mux on the WebRTC side? I strongly suspect there are none. Second, the only reasons not to use rtcp-mux that I can think of are the fo= llowing: 1. Using different QOS settings for RTCP vs RTP 2. Sending RTCP to a different device from RTP I do not think the first use case warrants making rtcp-mux optional, since,= practically no one does this. Second use case is also fairly marginal. Plus it can be handled by the gate= way which can send RTCP to one device and RTP to another. So, unless someone can come up with a use case why RTP and RTCP should use = different transports, I think rtcp-mux should be mandatory. Regards, ______________ Roman Shpount _______________________________________________ rtcweb mailing list rtcweb@ietf.org https://www.ietf.org/mailman/listinfo/rtcweb _______________________________________________ rtcweb mailing list rtcweb@ietf.org https://www.ietf.org/mailman/listinfo/rtcweb --_000_7594FB04B1934943A5C02806D1A2204B348EB92EESESSMB209erics_ Content-Type: text/html; charset="windows-1255" Content-Transfer-Encoding: quoted-printable
Hi,

Interoperability is achieved if implementations support the outcome of what= is negotiated.

Regards,

Christer

Sent from my Windows Phone
From: Asveren, Tolga
Sent: =FD06= /=FD08/=FD2015 20:38
To: Christer Holmberg; Eric Rescorla
Cc: <rtcweb@ietf.org>
Subject: RE: [= rtcweb] What the gateway draft should say about mux/non-mux

=93I don't want a standard which says "look w= hat the browsers do and follow".=94

I don=92t want this either.

 

=93I want a standard, when correctly implemented, = ensures interoperability with browsers (and other types of WebRTC entities)= .=94

And isn=92t this achieved mainly by rtcp-mux being= a negotiated functionality? Or maybe we have a different understanding of = what =93interoperability=94 means and you are referring to what I would call =93profiling=94, i.e. selecting a subset of functiona= lity from a (set of) specification(s) and mandating it on elements, which c= laim to be compliant to that particular profile.

 

Thanks,

Tolga

 

 

From: Christer Holmberg [mailto:ch= rister.holmberg@ericsson.com]
Sent: Thursday, August 06, 2015 12:52 PM
To: Asveren, Tolga <tasveren@sonusnet.com>; Eric Rescorla <= ekr@rtfm.com>
Cc: <rtcweb@ietf.org> <rtcweb@ietf.org>
Subject: RE: [rtcweb] What the gateway draft should say about mux/no= n-mux

 

Hi,

As an implementer, and as an IETF participant, I don't want a standard whic= h says "look what the browsers do and follow". That will only cau= se trouble - especially if different browsers do different things. I want a= standard, when correctly implemented, ensures interoperability with browsers (and other types of WebRTC entities).

Implementations that only need to work in specific environments can of cour= se do whatever they want, but I don't think we consider e.g. Chrome and Fir= efox such implementations.

Regards,

Christer

Sent from my Windows Phone

From: Asveren, Tolga
Sent: =FD06/=FD08/=FD2015 17:52
To: Eric Rescorla
Cc: <rtcweb@ietf.or= g>
Subject: Re: [rtcweb] What the gateway draft should say about mux/non-mux

In practice =96if not as initially = targeted- a WebRTC-endpoint does not necessarily mean a =93browser=94. I co= mpletely agree with our statements about browser based deployments though. All I am saying is =93Let people decide what they want= to support, they are smart enough to know what a particular deployment mod= el requires=94. For example, regardless of what specifications say, non-bro= wser equipment vendors, whose products need to interoperate with browsers, are following/implementing how Chrome/= Firefox are behaving.

 

Thanks,

Tolga

 

From: Eric Rescorla [mailto:ekr@rtfm.com]
Sent: Thursday, August 06, 2015 10:36 AM
To: Asveren, Tolga <tasv= eren@sonusnet.com>
Cc: tim panton <tim@phon= efromhere.com>; Hutton, Andrew <andrew.hutton@unify.com>; <rtcweb@ietf.org> <rtcwe= b@ietf.org>
Subject: Re: [rtcweb] What the gateway draft should say about mux/no= n-mux

 

I feel like people are talking past each other here.=

 

The browser vendors (at least Chrome and Firefox) wa= nt to completely remove support for

non-mux from their code. If we make this change, tha= t means that there will be no way for a

browser to do non-mux and so as a practical matter w= e might as well simply say that

WebRTC is mux and hence for the WebRTC side of a Web= RTC gateway, there is similarly no

need to support non-mux, This only leaves the questi= on of the non-WebRTC side of

the gateway, but that's out of scope here. So, I'm n= ot sure what you are asking for.

 

WRT to the issue Jonathan raises about SDP being a n= egotiation, that's true, but as

a practical matter we're already far down the road o= f WebRTC offerers offering SDP

which in principle the answerer might choose not to = accept but if it does so the

connection will fail

 

-Ekr

 

On Thu, Aug 6, 2015 at 7:12 AM, Asveren, Tolga <<= a href=3D"mailto:tasveren@sonusnet.com" target=3D"_blank">tasveren@sonusnet= .com> wrote:

I think implementers themselves can= weigh out the advantages/disadvantaged/deployment models they are targetin= g/etc=85 and decide what to support/not to support. I don=92t see any issue with this as long as there is a negotiation mechan= ism (which there is). I don=92t think the availability of negotiation is en= couraging people this or that way.

 

Thanks,

Tolga

 

From: tim panton [mailto:tim@phonefromhere.com]
Sent: Thursday, August 06, 2015 10:07 AM
To: Hutton, Andrew <andrew.hutton@unify.com>
Cc: Asveren, Tolga <tasveren@sonusnet.com>; <rtcweb@ietf.org> <rtcweb@ietf.org>


Subject: Re: [rtcweb] What the gateway draft should say about mux/no= n-mux

 

 

On 6 Aug 2015, at 08:30, Hutton, Andrew <andrew.hutton@unify.c= om> wrote:

 

+1 to what Tim said.

 

I don=92t think this discussion is = really about gateways at all it is surely about whether WebRTC browsers hav= e to support non-mux and I don=92t really see any good reason why they need to.

 

If we had thought about this at the= time we mandated DTLS-SRTP then we would have mandated rtp-mux at the same= time but unfortunately we didn=92t but we can fix that now.

 

Sadly true, but the situation in a browser is manage= able since you might expect 10 peer connections, resulting 

in a worst case of 60 UDP ports/DTLS sessions in use=  

(assuming voice+video+data unbundled and RTC= P-non-mux vs the 10 needed). We 

also assume a relatively well endowed CPU - devoted = largely to this task.

 

On the gateway you=92d hope to have thousands of ses= sions and presumably much less CPU/memory resource per channel.

So while I think it is unfortunate that browsers can= do non-mux, it would be plain stupid to do that on a gateway. Do we <= /p>

really want to encourage that ?

 

T.

 

 

 

Andy

 

 

From: rtcweb [mailto:rtcweb-bounces@ietf.org] On Behalf Of tim panton
Sent: 06 August 2015 13:53
To: Asveren, Tolga
Cc: <rtcweb@= ietf.org>
Subject: Re: [rtcweb] What the gateway draft should say about mux/no= n-mux

 

So we are positing the existence of a webRTC gateway= designed to support thousands of calls which does ICE and DTLS but the

designer decided deliberately to double the number o= f ICE sessions required and double the number of DTLS sessions (and key&nbs= p;

generation costs) so that they can run RTCP (over IC= E and DTLS) on a separate port. In my estimation that=92s one poor decision=

and should not be used as the basis of this (or any)= standard. 

 

I=92d rather not support rtcp-no-mux as I see zero a= dvantages in having it. (I know theoretically it might be possible to get

a RTCP packet through a congested net on a different= port with a separate diffserv setting but that just seems so contrived).

 

Tim.

 

 

On 6 Aug 2015, at 06:44, Asveren, Tolga <tasveren@sonusnet.com> wrote:

 

These assumptions are not necessari= ly true in a universal sense (like almost any other assumption about differ= ent deployment models).

 

Furthermore, and more importantly, = there is nothing mandating WebRTC endpoints to support non-rtcp-mux. It is = a negotiated functionality. Any entity can enforce rtcp-mux as a local policy. 

 

The issue with supporting non-rtcp-= mux seems to be lack of clarity in the relevant specifications. Fixing this= =96regardless of the outcome of any other discussion- seems to be prudent IMHO.

 

Thanks,

Tolga

 

From: Wyss, Felix [mailto:Felix.Wyss@inin.com] 
Sent: Thursday, August 06, 2015 6:37 AM
To: Christer Holmberg <christer.holmberg@ericsson.com>; Asve= ren, Tolga <t= asveren@sonusnet.com>; Schwarz, Albrecht (Albrecht) <albrecht.schwarz@alcatel-lucent.com>; Roman Shpount <roman@telurix.com>; = Rauschenbach, Uwe (Nokia - DE/Munich) <uwe.rauschenbach@nokia.com>
Cc: <rt= cweb@ietf.org> <rtcweb@ietf.org>
Subject: Re: [rtcweb] What the gateway draft should say about m= ux/non-mux

 

Why shouldn't the gateway be required to = do the mux/demux?  Making the WebRTC endpoints a lot more complex just= so the legacy interop might potentially be a teeny-tiny bit easier makes no sense IMHO.  Actually, the gateway would not be a= ble to do "end-to-end" pass-through anyway as legacy equipment wi= ll either be unencrypted or use SDES (RFC#4568) for key exchange.  So = the gateway will have to perform DTLS-SRTP to SDES-SRTP transcryption--which already is way more hassle than RTP/RTCP mux/demux.

 

--Felix

 

From:&n= bsp;rtcweb <rtcweb-bounces@ietf.org> on behalf of Christer Holmberg <christer.holmberg= @ericsson.com>
Sent: Thursday, August 6, 2015 05:51
To: Asveren, Tolga; Schwarz, Albrecht (Albrecht); Roman Shpount= ; Rauschenbach, Uwe (Nokia - DE/Munich)
Cc: <rtcweb@ietf.org>
Subject: Re: [rtcweb] What the gateway draft should say about m= ux/non-mux

 

Hi,

 

No matte= r whether the gateway supports RTP/RTCP mux or not, there are cases where t= he legacy network/endpoints will not use RTP/RTCP mux, so I guess people then would want to be able to negotiate non-mux =93= end-to-end=94, rather than having the gateway to demux/mux RTP and RTCP.

 

Regards,=

 

Christer=

 

From:&nbs= p;Asveren, Tolga [mailto:tasveren@sonusnet.com]&nbs= p;
Sent: 6. elokuuta 2015 12:18
To: Schwarz, Albrecht (Albrecht); Roman Shpount; Rauschenbach, = Uwe (Nokia - DE/Munich)
Cc: ext Eric Rescorla; Christer Holmberg; Bernard Aboba; <rtcweb@ietf.org>
Subject: Re: [rtcweb] What the gateway draft should say about m= ux/non-mux

 

Why should we consider 3GPP the sole &quo= t;owner/user" of the term/entity WebRTC-GW? I think it has a much more= general meaning and use in practice. It can refer to many different types of elements which can be deployed in many different enviro= nments, hence any attempt to define it strictly/restrict its capabilities a= re futile IMHO.

 

Thanks,

Tolga

 

From:&n= bsp;Schwarz, Albrecht (Albrecht) <albrecht.sc= hwarz@alcatel-lucent.com>
Sent: Thursday, August 6, 2015 2:44 AM
To: Asveren, Tolga; Roman Shpount; Rauschenbach, Uwe (Nokia - D= E/Munich)
Cc: ext Eric Rescorla; Christer Holmberg; Bernard Aboba; <rtcweb@ietf.org>
Subject: RE: [rtcweb] What the gateway draft should say about m= ux/non-mux

 

The concerned 3GPP WebRTC gate= way (3GPP 23.334/29.334) supports already RTP/RTCP transport multiplexing (= since 3GPP Release 12), i.e. should not be the limiting factor in this discussion. 

For ones interested in the RTC= P port allocation rules, see H.248.57:

Clause 7 describes RTP/RTCP tr= ansport multiplexing. ITU-T H.248.57 is already supported by 3GPP 29.334.

 

The rationale behind the =93op= tional tagging=94 by 23.228 is a third reason, beyond

>1. Using different QOS settings for R= TCP vs RTP

>2. Sending RTCP to a different device= from RTP

 

Don=92t want to go in the 3GPP= specific details, but it has nothing to do with the 3GPP UE-embedded WebRT= C client nor any constraints by 3GPP WebRTC gateways.

 

Thus, a WebRTC gateway MUST su= pport RTP/RTCP transport multiplexing due to its purpose in interworking su= pport.

 

Regards,

Albrecht

 

 

From:&nbs= p;Asveren, Tolga [mailto:tasveren@sonusnet.com]&nbs= p;
Sent: Mittwoch, 5. August 2015 19:47
To: Roman Shpount; Rauschenbach, Uwe (Nokia - DE/Munich)
Cc: ext Eric Rescorla; Schwarz, Albrecht (Albrecht); Christer H= olmberg; Bernard Aboba; <rtcweb@ietf.org>
Subject: RE: [rtcweb] What the gateway draft should say about m= ux/non-mux

 

i- I hum= bly disagree that using different QoS RTCP/RTP, e.g. different DiffServ val= ues , should be dismissed.

ii- Let = me also add another reason why no-rtcp-mux may be needed: Implementation di= fficulties in certain GWs.

 

Consider= ing that there is already a negotiation mechanism for rtcp-mux support, tha= t it can be de-facto mandated by the choice of browsers for Internet, I think what Christer/Albrecht suggested is the right way to= move forward: provide clarifications for vague points. I don=92t understan= d why lack of clarity in existing specifications should cause imposing rest= rictions. This would be akin to dropping a feature due to a bug. In this case, the =93bug=94 is lack of clarity in = normative specifications and it can be addressed by further specification.<= /span>

 

Thanks,<= /span>

Tolga

 

From:&n= bsp;Roman Shpount [<= span style=3D"color:purple">mailto:roman@telurix.com] 
Sent: Wednesday, August 05, 2015 12:29 PM
To: Rauschenbach, Uwe (Nokia - DE/Munich) <uwe.rauschenbach@nokia.com>
Cc: ext Eric Rescorla <ekr@rtfm.com>; Schw= arz, Albrecht (Albrecht) <albrecht.schwarz@al= catel-lucent.com>; Asveren, Tolga <tasveren@sonusnet.com>; Chri= ster Holmberg <christer.holmberg@ericsson.com>; Bernard Aboba <bernard.aboba@gmail.com>; &= lt;rtcweb@ietf.org> <rtcweb@ietf.org<= /a>>
Subject: Re: [rtcweb] What the gateway draft should say about m= ux/non-mux

 

Media gateway implementat= ions according to 3GPP TS 23.228 may not support rtcp-mux, as rtcp-mux is optional there.

So if we drop non-mux sup= port from web browsers, those media gateways that have not implemented rtcp= -mux will stop interoperating. 

 

 

First of all, do you know of any WebRTC t= o IMS gateways that do not implement rtcp-mux on the WebRTC side? I strongl= y suspect there are none.

 

Second, the only reasons not to use rtcp-= mux that I can think of are the following:

 

1. Using different QOS settings for RTCP = vs RTP

2. Sending RTCP to a different device fro= m RTP

 

I do not think the first use case warrant= s making rtcp-mux optional, since, practically no one does this.

Second use case is also fairly marginal. = Plus it can be handled by the gateway which can send RTCP to one device and= RTP to another.

 

So, unless someone can come up with a use= case why RTP and RTCP should use different transports, I think rtcp-mux sh= ould be mandatory.

 

Regards,

______________

Roman Shpount

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

 

 


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

 

--_000_7594FB04B1934943A5C02806D1A2204B348EB92EESESSMB209erics_-- From nobody Thu Aug 6 12:26:31 2015 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 003BA1B310C for ; Thu, 6 Aug 2015 12:26:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PgFa6S-cmevZ for ; Thu, 6 Aug 2015 12:26:26 -0700 (PDT) Received: from na01-bl2-obe.outbound.protection.outlook.com (mail-bl2on0070.outbound.protection.outlook.com [65.55.169.70]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8BAD81A92EC for ; Thu, 6 Aug 2015 12:26:26 -0700 (PDT) Received: from SN1PR0301MB1551.namprd03.prod.outlook.com (10.162.129.157) by SN1PR0301MB1549.namprd03.prod.outlook.com (10.162.129.155) with Microsoft SMTP Server (TLS) id 15.1.225.19; Thu, 6 Aug 2015 19:26:18 +0000 Received: from SN1PR0301MB1551.namprd03.prod.outlook.com ([10.162.129.157]) by SN1PR0301MB1551.namprd03.prod.outlook.com ([10.162.129.157]) with mapi id 15.01.0225.018; Thu, 6 Aug 2015 19:26:18 +0000 From: "Asveren, Tolga" To: Christer Holmberg , Peter Thatcher , Jonathan Lennox Thread-Topic: [rtcweb] What the gateway draft should say about mux/non-mux Thread-Index: AQHQy8DcUgzWwtVCmk+8q67BCzjC45316g6A///gJYCAAAJzgIAAAVWAgAABfoCAA/DZAIAAQVMAgAL8GACAAIDGAIAAFdwAgADZaQCAACrOgIAAJh8A///v2QCAABLZAIAAEy6AgAAKf4CAAANpgIAADisAgAA1GICAADwP54AAAaqQ Date: Thu, 6 Aug 2015 19:26:18 +0000 Message-ID: References: <9F33F40F6F2CD847824537F3C4E37DDF1E826A00@MCHP04MSX.global-ad.net> <55C3644D.8040903@jive.com> , <7594FB04B1934943A5C02806D1A2204B348EB8DD@ESESSMB209.ericsson.se> In-Reply-To: <7594FB04B1934943A5C02806D1A2204B348EB8DD@ESESSMB209.ericsson.se> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=tasveren@sonusnet.com; x-originating-ip: [50.182.164.80] x-microsoft-exchange-diagnostics: 1; SN1PR0301MB1549; 5:3wqX5xQk0PE53XMUgTLskdxTGOaj4Ba2TxCELDQTlvbf84bxkCygWaAhUdbFhQ7V3nZaUpPtt6bflcctIrK/JTnWroodyXqJlQcVz4DCqF0eXIhIIHZt9YVa4KlchA10KI8JKRMUzY+i5eHSsC+OFQ==; 24:+8b++r/rF9EtkT/aJt4YbU9mCqC5mBX4E9ycfTrHIZtspTAcystAs7qW4WQBhX+wCit4hXQu0IRyccOJzAgTdn217Hz2tj8BrUuoV/WgTb4=; 20:e9B16mbVT0v9SeeuvkrbqluANg9strShg8LqSIKkVHe4UQEtqTXtAT2LKST4QF6+Suy5pj48ig66px45HIzqYQ== x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:SN1PR0301MB1549; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(108003899814671); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(601004)(5005006)(3002001); SRVR:SN1PR0301MB1549; BCL:0; PCL:0; RULEID:; SRVR:SN1PR0301MB1549; x-forefront-prvs: 06607E485E x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(377424004)(24454002)(164054003)(377454003)(199003)(189002)(33656002)(62966003)(77156002)(19580405001)(16236675004)(92566002)(93886004)(40100003)(66066001)(19617315012)(122556002)(19300405004)(64706001)(189998001)(5002640100001)(5003600100002)(46102003)(101416001)(2900100001)(77096005)(15975445007)(2950100001)(68736005)(102836002)(74316001)(19625215002)(76176999)(54356999)(10400500002)(5001920100001)(76576001)(87936001)(19609705001)(2656002)(106356001)(5001860100001)(5001830100001)(99286002)(19580395003)(5001960100002)(106116001)(105586002)(86362001)(81156007)(4001540100001)(97736004)(50986999)(5001770100001); DIR:OUT; SFP:1101; SCL:1; SRVR:SN1PR0301MB1549; H:SN1PR0301MB1551.namprd03.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; A:1; MX:1; LANG:en; received-spf: None (protection.outlook.com: sonusnet.com does not designate permitted sender hosts) Content-Type: multipart/alternative; boundary="_000_SN1PR0301MB155156414DA13AA9562D1427B2740SN1PR0301MB1551_" MIME-Version: 1.0 X-OriginatorOrg: sonusnet.com X-MS-Exchange-CrossTenant-originalarrivaltime: 06 Aug 2015 19:26:18.6897 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 29a671dc-ed7e-4a54-b1e5-8da1eb495dc3 X-MS-Exchange-Transport-CrossTenantHeadersStamped: SN1PR0301MB1549 Archived-At: Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] What the gateway draft should say about mux/non-mux X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 06 Aug 2015 19:26:29 -0000 --_000_SN1PR0301MB155156414DA13AA9562D1427B2740SN1PR0301MB1551_ Content-Type: text/plain; charset="windows-1256" Content-Transfer-Encoding: quoted-printable I agree with you if you mean =93no new tag/no paper enforced behavior=94, i= .e. let the negotiation mechanism handle the interoperability. Thanks, Tolga From: rtcweb [mailto:rtcweb-bounces@ietf.org] On Behalf Of Christer Holmber= g Sent: Thursday, August 06, 2015 3:18 PM To: Peter Thatcher ; Jonathan Lennox Cc: rtcweb@ietf.org Subject: Re: [rtcweb] What the gateway draft should say about mux/non-mux I don't think we should do that, or soon people would want to have "only ta= gs" for every possible extension... :) bundle-only makes sense, because you can use it to ensure that you won't e= nd up with a large number of media 5-tuples. Regards, Christer Sent from my Windows Phone ________________________________ From: Peter Thatcher Sent: =FD06/=FD08/=FD2015 20:44 To: Jonathan Lennox Cc: rtcweb@ietf.org Subject: Re: [rtcweb] What the gateway draft should say about mux/non-mux We have "bundle-only". It would be pretty simply to define "rtcp-mux-only"= , if we think it's worth the effort. On Thu, Aug 6, 2015 at 7:33 AM, Jonathan Lennox > wrote: > On Aug 6, 2015, at 9:42 AM, Simon Perreault > wrote: > > Le 2015-08-06 09:30, Hutton, Andrew a =E9crit : >> If we had thought about this at the time we mandated DTLS-SRTP then we >> would have mandated rtp-mux at the same time but unfortunately we didn= =92t >> but we can fix that now. > > To be clear, rtcp-mux is already mandatory. It's non-mux that needs to > be made optional. > > https://tools.ietf.org/html/draft-ietf-rtcweb-rtp-usage-25#section-4.5 The problem is that there=92s no way in SDP for an offerer to express the d= ifference between =93I=92d like to do RTCP-mux, but I=92m willing to fall b= ack to non-muxed=94 and =93I only support RTCP-mux, and if you can=92t do i= t please reject my offer.=94 This is a general consequence of the fact that SDP has no comprehension-man= datory attributes. (We were able to get away with this for DTLS-SRTP becau= se the =93proto=94 field is single-valued and thus effectively comprehensio= n-mandatory.) _______________________________________________ rtcweb mailing list rtcweb@ietf.org https://www.ietf.org/mailman/listinfo/rtcweb --_000_SN1PR0301MB155156414DA13AA9562D1427B2740SN1PR0301MB1551_ Content-Type: text/html; charset="windows-1256" Content-Transfer-Encoding: quoted-printable

I agree with you if you mean =93no ne= w tag/no paper enforced behavior=94, i.e. let the negotiation mechanism han= dle the interoperability.

 

Thanks,

Tolga

 

From: rtcweb [mailto:rtcweb-bounces@= ietf.org] On Behalf Of Christer Holmberg
Sent: Thursday, August 06, 2015 3:18 PM
To: Peter Thatcher <pthatcher@google.com>; Jonathan Lennox <= ;jonathan@vidyo.com>
Cc: rtcweb@ietf.org
Subject: Re: [rtcweb] What the gateway draft should say about mux/no= n-mux

 

I don't think we should do that, or soon people wou= ld want to have "only tags" for every possible extension... :)
bundle-only makes sense,  because you can use it to ensure that you wo= n't end up with a large number of media 5-tuples.

Regards,

Christer

Sent from my Windows Phone

From: Peter Thatcher
Sent: =FD06/=FD08/=FD2015 20:44
To: Jonathan Lennox
Cc: rtcweb@ietf.org<= /span>
Subject: Re: [rtcweb] What the gateway draft should say about mux/non-mux

We have "bundle-only".  It would be pretty simply to de= fine "rtcp-mux-only", if we think it's worth the effort. 

 

On Thu, Aug 6, 2015 at 7:33 AM, Jonathan Lennox <= jonathan@vidyo.com<= /a>> wrote:


> On Aug 6, 2015, at 9:42 AM, Simon Perreault <sperreault@jive.com> wrote:
>
> Le 2015-08-06 09:30, Hutton, Andrew a =E9crit :
>> If we had thought about this at the time we mandated DTLS-SRTP the= n we
>> would have mandated rtp-mux at the same time but unfortunately we = didn=92t
>> but we can fix that now.
>
> To be clear, rtcp-mux is already mandatory. It's non-mux that needs to=
> be made optional.
>
> https://tools.ietf.org/html/draft-ietf-rtcweb-rtp-usage-25#section-4.5<= br>
The problem is that there=92s no way in SDP for an offerer to express the d= ifference between =93I=92d like to do RTCP-mux, but I=92m willing to fall b= ack to non-muxed=94 and =93I only support RTCP-mux, and if you can=92t do i= t please reject my offer.=94

This is a general consequence of the fact that SDP has no comprehension-man= datory attributes.  (We were able to get away with this for DTLS-SRTP = because the =93proto=94 field is single-valued and thus effectively compreh= ension-mandatory.)

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

 

--_000_SN1PR0301MB155156414DA13AA9562D1427B2740SN1PR0301MB1551_-- From nobody Thu Aug 6 12:59:56 2015 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 432CE1ACD16 for ; Thu, 6 Aug 2015 12:59:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.2 X-Spam-Level: X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CGY1KPkShN2f for ; Thu, 6 Aug 2015 12:59:53 -0700 (PDT) Received: from sessmg23.ericsson.net (sessmg23.ericsson.net [193.180.251.45]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 550781ACD13 for ; Thu, 6 Aug 2015 12:59:52 -0700 (PDT) X-AuditID: c1b4fb2d-f79176d00000321c-bd-55c3bcb6308d Received: from ESESSHC009.ericsson.se (Unknown_Domain [153.88.253.124]) by sessmg23.ericsson.net (Symantec Mail Security) with SMTP id 17.D5.12828.6BCB3C55; Thu, 6 Aug 2015 21:59:50 +0200 (CEST) Received: from ESESSMB209.ericsson.se ([169.254.9.36]) by ESESSHC009.ericsson.se ([153.88.183.45]) with mapi id 14.03.0210.002; Thu, 6 Aug 2015 21:59:48 +0200 From: Christer Holmberg To: "Asveren, Tolga" , Peter Thatcher , Jonathan Lennox Thread-Topic: [rtcweb] What the gateway draft should say about mux/non-mux Thread-Index: AQHQy78thNOz8AYdMEys1nzX7WTf2J316g6A///gJYCAAAJzgIAAAVWAgAABfoCAA/DZAIAAQVMAgAL8GACAAIDGAIAAFdwAgADZaQCAACrOgIAAJh8A///v2QCAABLZAIAAEy6AgAAKf4CAAANpgIAADisAgAA1GICAADwP5///4LQAAAVchsc= Date: Thu, 6 Aug 2015 19:59:48 +0000 Message-ID: <7594FB04B1934943A5C02806D1A2204B348EB9DA@ESESSMB209.ericsson.se> References: <9F33F40F6F2CD847824537F3C4E37DDF1E826A00@MCHP04MSX.global-ad.net> <55C3644D.8040903@jive.com> , <7594FB04B1934943A5C02806D1A2204B348EB8DD@ESESSMB209.ericsson.se>, In-Reply-To: Accept-Language: en-US Content-Language: en-GB X-MS-Has-Attach: X-MS-TNEF-Correlator: Content-Type: multipart/alternative; boundary="_000_7594FB04B1934943A5C02806D1A2204B348EB9DAESESSMB209erics_" MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFuplkeLIzCtJLcpLzFFi42KZGfG3RnfbnsOhBo2Nshb7F59ntri2/DWr xdp/7ewWszvfMzmweCzYVOqxZMlPJo9Ln/+ze7Q9u8MewBLFZZOSmpNZllqkb5fAlTF5zQeW gsMxFVveLmJtYJwd2MXIySEhYCJxo+UeC4QtJnHh3nq2LkYuDiGBo4wSD5YsYYZwFjFK3N17 HijDwcEmYCHR/U8bpEFEoFpi6+Pp7CA2s4C6xJ3F58BsYQFPiVudi5kgarwk1n2/xgxhH2OU mLZXBMRmEVCRmHf0EFg9r4CvxPMfp1ggdk1ikfj/4RojSIJTIFHiYsdfsOsYga77fmoNE8Qy cYmmLytZIa4WkFiy5zwzhC0q8fLxP1aImnyJxc9OMEMsEJQ4OfMJywRGkVlI2mchKZuFpAwi biDx5f1tKFtbYtnC18wQtr5E9/vTTMjiCxjZVzGKFqcWF+emGxnrpRZlJhcX5+fp5aWWbGIE xt/BLb91dzCufu14iFGAg1GJh3fB/kOhQqyJZcWVuYcYpTlYlMR5Z2zOCxUSSE8sSc1OTS1I LYovKs1JLT7EyMTBKdXAWGgjm/lddpWcoMn1jgTByimdJatnluXtibX/fr559qcnzx7/b8if a9XEtl6ocmPEp4endrhN5nI2v3nkSP6flXsVpVl05tT6elYcPN24Tbe1/WLvo5biG6r97z52 nDqzTq/MyWAvS+bVusLZxx3DYvuy1/CbFR8pOzlH/M9LLubLU8qfbWFxUWIpzkg01GIuKk4E AKH7asWgAgAA Archived-At: Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] What the gateway draft should say about mux/non-mux X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 06 Aug 2015 19:59:55 -0000 --_000_7594FB04B1934943A5C02806D1A2204B348EB9DAESESSMB209erics_ Content-Type: text/plain; charset="windows-1256" Content-Transfer-Encoding: quoted-printable My comment was only regarding a new tag. Whatever the outcome of the muc di= scussion is, I don't think we shall define rtcp-mux-only tags. Regards, Christer Sent from my Windows Phone ________________________________ From: Asveren, Tolga Sent: =FD06/=FD08/=FD2015 22:26 To: Christer Holmberg; Peter Thatche= r; Jonathan Lennox Cc: rtcweb@ietf.org Subject: RE: [rtcweb] What the gateway draft should say about mux/non-mux I agree with you if you mean =93no new tag/no paper enforced behavior=94, i= .e. let the negotiation mechanism handle the interoperability. Thanks, Tolga From: rtcweb [mailto:rtcweb-bounces@ietf.org] On Behalf Of Christer Holmber= g Sent: Thursday, August 06, 2015 3:18 PM To: Peter Thatcher ; Jonathan Lennox Cc: rtcweb@ietf.org Subject: Re: [rtcweb] What the gateway draft should say about mux/non-mux I don't think we should do that, or soon people would want to have "only ta= gs" for every possible extension... :) bundle-only makes sense, because you can use it to ensure that you won't e= nd up with a large number of media 5-tuples. Regards, Christer Sent from my Windows Phone ________________________________ From: Peter Thatcher Sent: =FD06/=FD08/=FD2015 20:44 To: Jonathan Lennox Cc: rtcweb@ietf.org Subject: Re: [rtcweb] What the gateway draft should say about mux/non-mux We have "bundle-only". It would be pretty simply to define "rtcp-mux-only"= , if we think it's worth the effort. On Thu, Aug 6, 2015 at 7:33 AM, Jonathan Lennox > wrote: > On Aug 6, 2015, at 9:42 AM, Simon Perreault > wrote: > > Le 2015-08-06 09:30, Hutton, Andrew a =E9crit : >> If we had thought about this at the time we mandated DTLS-SRTP then we >> would have mandated rtp-mux at the same time but unfortunately we didn= =92t >> but we can fix that now. > > To be clear, rtcp-mux is already mandatory. It's non-mux that needs to > be made optional. > > https://tools.ietf.org/html/draft-ietf-rtcweb-rtp-usage-25#section-4.5 The problem is that there=92s no way in SDP for an offerer to express the d= ifference between =93I=92d like to do RTCP-mux, but I=92m willing to fall b= ack to non-muxed=94 and =93I only support RTCP-mux, and if you can=92t do i= t please reject my offer.=94 This is a general consequence of the fact that SDP has no comprehension-man= datory attributes. (We were able to get away with this for DTLS-SRTP becau= se the =93proto=94 field is single-valued and thus effectively comprehensio= n-mandatory.) _______________________________________________ rtcweb mailing list rtcweb@ietf.org https://www.ietf.org/mailman/listinfo/rtcweb --_000_7594FB04B1934943A5C02806D1A2204B348EB9DAESESSMB209erics_ Content-Type: text/html; charset="windows-1256" Content-Transfer-Encoding: quoted-printable
My comment wa= s only regarding a new tag. Whatever the outcome of the muc discussion is, = I don't think we shall define rtcp-mux-only tags.

Regards,

Christer

Sent from my Windows Phone
From: Asveren, Tolga
Sent: =FD06= /=FD08/=FD2015 22:26
To: Christer Holmberg; Peter Thatcher; Jonathan Lennox
Cc: rtcweb@ietf.org
Subject: RE: [= rtcweb] What the gateway draft should say about mux/non-mux

I agree with you if you mean =93no = new tag/no paper enforced behavior=94, i.e. let the negotiation mechanism h= andle the interoperability.

 

Thanks,

Tolga

 

From: rtcweb [mailto:rtcweb-bounce= s@ietf.org] On Behalf Of Christer Holmberg
Sent: Thursday, August 06, 2015 3:18 PM
To: Peter Thatcher <pthatcher@google.com>; Jonathan Lennox <= ;jonathan@vidyo.com>
Cc: rtcweb@ietf.org
Subject: Re: [rtcweb] What the gateway draft should say about mux/no= n-mux

 

I don't think we should do that, or soon people wo= uld want to have "only tags" for every possible extension... :)
bundle-only makes sense,  because you can use it to ensure that you wo= n't end up with a large number of media 5-tuples.

Regards,

Christer

Sent from my Windows Phone

We have "bundle-only".  It would be pretty simply to de= fine "rtcp-mux-only", if we think it's worth the effort. 

 

On Thu, Aug 6, 2015 at 7:33 AM, Jonathan Lennox <= jonathan@vidyo.com<= /a>> wrote:


> On Aug 6, 2015, at 9:42 AM, Simon Perreault <sperreault@jive.com> wrote:
>
> Le 2015-08-06 09:30, Hutton, Andrew a =E9crit :
>> If we had thought about this at the time we mandated DTLS-SRTP the= n we
>> would have mandated rtp-mux at the same time but unfortunately we = didn=92t
>> but we can fix that now.
>
> To be clear, rtcp-mux is already mandatory. It's non-mux that needs to=
> be made optional.
>
> https://tools.ietf.org/html/draft-ietf-rtcweb-rtp-usage-25#section-4.5<= br>
The problem is that there=92s no way in SDP for an offerer to express the d= ifference between =93I=92d like to do RTCP-mux, but I=92m willing to fall b= ack to non-muxed=94 and =93I only support RTCP-mux, and if you can=92t do i= t please reject my offer.=94

This is a general consequence of the fact that SDP has no comprehension-man= datory attributes.  (We were able to get away with this for DTLS-SRTP = because the =93proto=94 field is single-valued and thus effectively compreh= ension-mandatory.)

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

 

--_000_7594FB04B1934943A5C02806D1A2204B348EB9DAESESSMB209erics_-- From nobody Thu Aug 6 13:10:11 2015 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BEC581B32EC for ; Thu, 6 Aug 2015 13:10:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.388 X-Spam-Level: X-Spam-Status: No, score=-1.388 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Jm5mvR3duNN1 for ; Thu, 6 Aug 2015 13:10:05 -0700 (PDT) Received: from mail-vk0-x232.google.com (mail-vk0-x232.google.com [IPv6:2607:f8b0:400c:c05::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 D60D01A882E for ; Thu, 6 Aug 2015 13:08:43 -0700 (PDT) Received: by vkhg129 with SMTP id g129so31009990vkh.2 for ; Thu, 06 Aug 2015 13:08:43 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=5JF2zEDoBMNncmCmEQZNbKUosIlo7/QbK9t7OhJdAMk=; b=jbeVQ94r7Q5Y0uqH/ecTCAOJDn3vJHcM/6Sjy3j9ZtbHlusnWGHBKKBzRjahSBMq06 Of0Dp5AuptNeDLj8U6/VPzu0xQVqd2Dm9yYO5upp9wSrFNoUqJritE21ukdoSE3oV/oj TihTktxxEOB9VrSfFL+pp2YvUtNTzKuSyEfbz6ECy6vbDtRFt3ybpcUC8y7PkoFNzKrX OlPGVRHCGQwTI5S37ImBYbJDnh5ZRga3NjIRvwiq88jaXBht3JHbrZTMpdR3dV+qO0SV OqZ27AB9R7tI6sJ3KsInUw8k83gp5Z25/0w6DBLH3sCLP8ym0EWu+tSo3p4dk16eboZ1 59DA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type; bh=5JF2zEDoBMNncmCmEQZNbKUosIlo7/QbK9t7OhJdAMk=; b=mCR1p8x8YlVGzTvvVVH5L0ZBF70pjHtbYNeDUWKF9415j6ZZ8URavwzPvLf+gkw1kX TnXVUGZDIhlU4P2M0G+Ok4EaFwlFtKUoRZa5KBAS2WK/Hq23By/mhwlJe57qxFnCvXg1 4qsFkaw2jhopVXkfJiGAWahcFxQs1qwAgwAm1aENHn5+AVbq/M59ZBEU6rt8f3aaNbBG 0n6tvko7DAkAqpb9AzS+PCoOSklC0Tsm8gIjWIr9eP9F20VOudn2fmvGVkPwy5vEkOyX 9lNe3xSiz8xuCx9cjL1ne9DLZVZF8SuRDJXMhu6lX7HUuI/KeKFL4LJR6kZNlaLhOIsh YmLg== X-Gm-Message-State: ALoCoQmIwtbv/vy7yxorEqzaxt0yuNGeNn7U0wXTHfXtEvEUEdYFPSm/I9S0KFwYI/s7pYnUSzgg X-Received: by 10.52.186.10 with SMTP id fg10mr4518513vdc.84.1438891722957; Thu, 06 Aug 2015 13:08:42 -0700 (PDT) MIME-Version: 1.0 Received: by 10.31.191.87 with HTTP; Thu, 6 Aug 2015 13:08:23 -0700 (PDT) In-Reply-To: References: <20150805130607.20844.70680.idtracker@ietfa.amsl.com> <55C24293.5000603@cs.tcd.ie> <55C24C09.8020404@goodadvice.pages.de> <55C256C8.80606@jive.com> From: Justin Uberti Date: Thu, 6 Aug 2015 13:08:23 -0700 Message-ID: To: Jonathan Lennox Content-Type: multipart/alternative; boundary=bcaec54864ba04a9a9051caa16bf Archived-At: Cc: "rtcweb@ietf.org" , "tram@ietf.org" , mmusic Subject: Re: [rtcweb] [tram] TURN permissions for private ips X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 06 Aug 2015 20:10:10 -0000 --bcaec54864ba04a9a9051caa16bf Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Agree regarding "proxy-like" border TURN servers. I think that a candidate obtained from this sort of TURN server should be paired with RFC 1918 addresses, but I think that we should be able to avoid pairing candidates obtained from application TURN servers with RFC 1918 addresses. The app/browser clearly knows which is which. On Thu, Aug 6, 2015 at 7:14 AM, Jonathan Lennox wrote: > > On Aug 5, 2015, at 5:35 PM, Justin Uberti wrote: > > On Wed, Aug 5, 2015 at 11:32 AM, Simon Perreault > wrote: > >> Le 2015-08-05 13:46, Philipp Hancke a =C3=A9crit : >> > If a peer sends candidates with IP addresses from the private space, >> > permissions for those are created at the TURN server. Potentially not >> > utilising transport encryption even. >> > >> > I doubt those candidates ever work, so from a privacy point of view it >> > seems that clients should not create those permissions in the first >> > place. And ICE should probably not try to create pairs. >> >> It's not up to the client to determine what addresses might not might >> not work for a given TURN server. There are lots of weird NAT >> configurations out there that play games with RFC1918 addresses and can >> easily trick clients into doing the wrong thing. >> > > I am somewhat sympathetic to that, but given that there is measurable > downside here - extra candidate pairs that take time to check - can you > supply a concrete example of where the client choosing not to pair a TURN > candidate with a RFC1918 address would cause a problem? > > > This is really an ICE question, not a TURN question, so adding MMUSIC. > > Clearly, if your TURN server is actually on the public internet, pairing > RFC1918 address with its candidates won=E2=80=99t do any good. However, = there can > be scenarios where you have a TURN server sitting in a DMZ or the like, > where it can actually route to RFC 1918 addresses. I suspect this will b= e > relevant in the various scenarios where the TURN server is topologically > equivalent to a web proxy. > > As I recall from the discussions around the development of ICE, there are > actually a fair number of networks out there which have public IPv4 and > RFC1918 addresses directly routable to each other. The examples I remembe= r > came about as a result of corporate mergers, where one of the pre-merger > companies was using their public address space internally, and the other > wasn=E2=80=99t. > > > --bcaec54864ba04a9a9051caa16bf Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Agree regarding "proxy-like" border TURN servers= . I think that a candidate obtained from this sort of TURN server should be= paired with RFC 1918 addresses, but I think that we should be able to avoi= d pairing candidates obtained from application TURN servers with RFC 1918 a= ddresses. The app/browser clearly knows which is which.

On Thu, Aug 6, 2015 at 7:14 AM,= Jonathan Lennox <jonathan@vidyo.com> wrote:

On Aug 5, 2015, at 5:35 PM, Justin Uberti <juberti@google.com> wrote:

On Wed, Aug 5, 2015 at 11:32 AM, Simon Perreault= <sperreault@jiv= e.com> wrote:
Le 2015-08-05 13:46, Philipp Hancke a =C3=A9crit :
> If a peer sends candidates with IP addresses from the private space, > permissions for those are created at the TURN server. Potentially not<= br> > utilising transport encryption even.
>
> I doubt those candidates ever work, so from a privacy point of view it=
> seems that clients should not create those permissions in the first > place. And ICE should probably not try to create pairs.

It's not up to the client to determine what addresses might not might not work for a given TURN server. There are lots of weird NAT
configurations out there that play games with RFC1918 addresses and can
easily trick clients into doing the wrong thing.

I am somewhat sympathetic to that, but given that there is measurable = downside here - extra candidate pairs that take time to check - can you sup= ply a concrete example of where the client choosing not to pair a TURN cand= idate with a RFC1918 address would cause a problem?

This is really an ICE question, not a TURN question, so ad= ding MMUSIC.

Clearly, if your TURN server is actually on the public internet, pairi= ng RFC1918 address with its candidates won=E2=80=99t do any good.=C2=A0 How= ever, there can be scenarios where you have a TURN server sitting in a DMZ = or the like, where it can actually route to RFC 1918 addresses.=C2=A0 I suspect this will be relevant in the various scena= rios where the TURN server is topologically equivalent to a web proxy.=C2= =A0

As I recall from the discussions around the development of ICE, there = are actually a fair number of networks out there which have public IPv4 and= RFC1918 addresses directly routable to each other. The examples I remember= came about as a result of corporate mergers, where one of the pre-merger companies was using their public addr= ess space internally, and the other wasn=E2=80=99t.



--bcaec54864ba04a9a9051caa16bf-- From nobody Thu Aug 6 13:51:57 2015 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B23081B32FA; Thu, 6 Aug 2015 13:51:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cgvXOTimBOyS; Thu, 6 Aug 2015 13:51:52 -0700 (PDT) Received: from mail-lb0-x234.google.com (mail-lb0-x234.google.com [IPv6:2a00:1450:4010:c04::234]) (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 131B71B32FC; Thu, 6 Aug 2015 13:51:52 -0700 (PDT) Received: by lbbyj8 with SMTP id yj8so49857617lbb.0; Thu, 06 Aug 2015 13:51:50 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=WB6o88qL/fXEOLZiSFomzUP+RsoPUgYwLUgic+aeQVU=; b=olEqV7g+1nJUAikCBdfcIfm3+V6J0bpa356buWsvAGBA8hweeE9Ohm1IXh0ZsbSJ0j TVLOh+m1T0Q8vwFYXWs2ipDbV3/kI7GzDhGTlXd2rsY1YORmqwf7fFgFK9aIFSa0O/tX sfwN3S5BjkSVJsFqRHuG1YRLlrhDI0735nbxQTg+mQJM0Kc/rteuguNtgqxz3159BTK8 BkRKtf4FgQDvuPtq+IYbtpJpfBVp7/skNGNgQETmNr0w1PSwU0b3PKd4ZZLh1Jyk6/sO QZlRG0dUPqPM4z8tQbEmxROVjxxxo89eHJlZpEnfUfgHAdfWCrwCWwjbbJLVDPYdWcoF BSBw== MIME-Version: 1.0 X-Received: by 10.152.179.42 with SMTP id dd10mr4233835lac.89.1438894310528; Thu, 06 Aug 2015 13:51:50 -0700 (PDT) Received: by 10.25.197.87 with HTTP; Thu, 6 Aug 2015 13:51:50 -0700 (PDT) In-Reply-To: References: <20150805130607.20844.70680.idtracker@ietfa.amsl.com> <55C24293.5000603@cs.tcd.ie> <55C24C09.8020404@goodadvice.pages.de> <55C256C8.80606@jive.com> Date: Thu, 6 Aug 2015 13:51:50 -0700 Message-ID: From: Martin Thomson To: Justin Uberti Content-Type: text/plain; charset=UTF-8 Archived-At: Cc: Jonathan Lennox , "rtcweb@ietf.org" , "tram@ietf.org" , mmusic Subject: Re: [rtcweb] [tram] TURN permissions for private ips X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 06 Aug 2015 20:51:53 -0000 On 6 August 2015 at 13:08, Justin Uberti wrote: > I think that we should be able to avoid pairing candidates obtained from > application TURN servers with RFC 1918 addresses. The app/browser clearly > knows which is which. I'm concerned here that if we let the application choose, we lose the defence we were looking to gain. I think that perhaps 1918 pairing could be restricted to TURN servers that are configured/discovered, "proxy"-style. From nobody Thu Aug 6 14:09:02 2015 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 88E851A8843; Thu, 6 Aug 2015 14:09:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.567 X-Spam-Level: X-Spam-Status: No, score=-1.567 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, IP_NOT_FRIENDLY=0.334, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id l2WZykYQ-I9N; Thu, 6 Aug 2015 14:09:00 -0700 (PDT) Received: from mx0a-00198e01.pphosted.com (mx0a-00198e01.pphosted.com [67.231.149.202]) (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 D49191A87C7; Thu, 6 Aug 2015 14:09:00 -0700 (PDT) Received: from pps.filterd (m0073109.ppops.net [127.0.0.1]) by mx0a-00198e01.pphosted.com (8.15.0.59/8.14.7) with SMTP id t76L6Jfk013010; Thu, 6 Aug 2015 17:08:56 -0400 Received: from mail.vidyo.com ([162.209.16.214]) by mx0a-00198e01.pphosted.com with ESMTP id 1w1e1wjchw-1 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Thu, 06 Aug 2015 17:08:56 -0400 Received: from 492132-EXCH1.vidyo.com ([fe80::50:56ff:fe85:4f77]) by 492133-EXCH2.vidyo.com ([fe80::50:56ff:fe85:6b62%13]) with mapi id 14.03.0195.001; Thu, 6 Aug 2015 16:08:55 -0500 From: Jonathan Lennox To: Martin Thomson Thread-Topic: [rtcweb] [tram] TURN permissions for private ips Thread-Index: AQHQ0Im5K1zUyQsgpEy93n8RXczXUZ3/yvCA Date: Thu, 6 Aug 2015 21:08:55 +0000 Message-ID: References: <20150805130607.20844.70680.idtracker@ietfa.amsl.com> <55C24293.5000603@cs.tcd.ie> <55C24C09.8020404@goodadvice.pages.de> <55C256C8.80606@jive.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [198.200.77.253] Content-Type: text/plain; charset="utf-8" Content-ID: Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:5.14.151, 1.0.33, 0.0.0000 definitions=2015-08-06_11:2015-08-06,2015-08-06,1970-01-01 signatures=0 X-Proofpoint-Spam-Details: rule=outbound_notspam policy=outbound score=0 spamscore=0 suspectscore=0 phishscore=0 adultscore=0 bulkscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=7.0.1-1506180000 definitions=main-1508060327 Archived-At: Cc: mmusic , "rtcweb@ietf.org" , "tram@ietf.org" Subject: Re: [rtcweb] [tram] TURN permissions for private ips X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 06 Aug 2015 21:09:01 -0000 DQo+IE9uIEF1ZyA2LCAyMDE1LCBhdCA0OjUxIFBNLCBNYXJ0aW4gVGhvbXNvbiA8bWFydGluLnRo b21zb25AZ21haWwuY29tPiB3cm90ZToNCj4gDQo+IE9uIDYgQXVndXN0IDIwMTUgYXQgMTM6MDgs IEp1c3RpbiBVYmVydGkgPGp1YmVydGlAZ29vZ2xlLmNvbT4gd3JvdGU6DQo+PiBJIHRoaW5rIHRo YXQgd2Ugc2hvdWxkIGJlIGFibGUgdG8gYXZvaWQgcGFpcmluZyBjYW5kaWRhdGVzIG9idGFpbmVk IGZyb20NCj4+IGFwcGxpY2F0aW9uIFRVUk4gc2VydmVycyB3aXRoIFJGQyAxOTE4IGFkZHJlc3Nl cy4gVGhlIGFwcC9icm93c2VyIGNsZWFybHkNCj4+IGtub3dzIHdoaWNoIGlzIHdoaWNoLg0KPiAN Cj4gSSdtIGNvbmNlcm5lZCBoZXJlIHRoYXQgaWYgd2UgbGV0IHRoZSBhcHBsaWNhdGlvbiBjaG9v c2UsIHdlIGxvc2UgdGhlDQo+IGRlZmVuY2Ugd2Ugd2VyZSBsb29raW5nIHRvIGdhaW4uICBJIHRo aW5rIHRoYXQgcGVyaGFwcyAxOTE4IHBhaXJpbmcNCj4gY291bGQgYmUgcmVzdHJpY3RlZCB0byBU VVJOIHNlcnZlcnMgdGhhdCBhcmUgY29uZmlndXJlZC9kaXNjb3ZlcmVkLA0KPiAicHJveHkiLXN0 eWxlLg0KDQpXaGF0IGlzIHRoZSB0aHJlYXQgbW9kZWwvY29uY2VybiBoZXJlPyAgQXJlIHlvdSB0 cnlpbmcgdG8gc2F2ZSAyMCBtcyBmb3IgdGhlIGNvbm5lY3Rpdml0eSBjaGVjaywgb3IgYXJlIHlv dSBjb25jZXJuZWQgdGhhdCB0aGUgcmVtb3RlIGNhbmRpZGF0ZXMgYXJlIHZpc2libGUgb24gdGhl IHdpcmUgYW5kIHRvIHRoZSB0dXJuIHNlcnZlcj8NCg0KT2J2aW91c2x5LCBsb2NhbCBhbmQgcmVt b3RlIGNhbmRpZGF0ZXMgYXJlIGFsd2F5cyB2aXNpYmxlIHRvIGFuIGFwcGxpY2F0aW9uLCBzbyB0 aGlzIGlzbuKAmXQgYSBjaXJjdW1zdGFuY2Ugd2hlcmUgd29ycnlpbmcgYWJvdXQgaG9zdGlsZSBh cHBsaWNhdGlvbnMgaXMgcGFydGljdWxhcmx5IHJlbGV2YW50Lg0KDQpJIGNhbiBjZXJ0YWlubHkg aW1hZ2luZSBjb3Jwb3JhdGUgV2ViUlRDIGFwcGxpY2F0aW9ucyB3aXRoIGFuIGFwcGxpY2F0aW9u LWNvbmZpZ3VyZWQgVFVSTiBzZXJ2ZXIgaW4gYSBETVouICBBbm90aGVyIGV4YW1wbGUgbWlnaHQg YmUgYSBjbG91ZCBzZXJ2aWNlIHdoaWNoIHdhbnRzIGFsbCBpdHMgdHJhZmZpYyB0byBjb21lIGlu IHRocm91Z2ggYSBzaW5nbGUgcG9ydCwgc28gaXQgY29uZmlndXJlcyBhbGwgYXBwbGljYXRpb25z IHRvIGNvbm5lY3QgdG8gaXQgdGhyb3VnaCBhIFRVUk4gcG9ydCBhbmQgdXNlcyBSRkMgMTkxOCBh ZGRyZXNzZXMgaW50ZXJuYWxseS4= From nobody Thu Aug 6 14:16:52 2015 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6D5421A8861 for ; Thu, 6 Aug 2015 14:16:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.978 X-Spam-Level: X-Spam-Status: No, score=-1.978 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, 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 nlkP6p8OQ0_K for ; Thu, 6 Aug 2015 14:16:49 -0700 (PDT) Received: from mail-ig0-f173.google.com (mail-ig0-f173.google.com [209.85.213.173]) (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 A637A1A885C for ; Thu, 6 Aug 2015 14:16:47 -0700 (PDT) Received: by igr7 with SMTP id 7so19612019igr.0 for ; Thu, 06 Aug 2015 14:16:47 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=I7fxBiddcNwivLcpjcwtDXtH9Ti8Uw2BkIO7Wn+j9eY=; b=Igb6aT7HHiDUJ6qUBAcBOUwUKgC18BLiVOYSx4NT5kfe3xMl5mN6IGJEW+eBGpFbyi ps7+/yPR83tP+r3BmNwhqN0qytamRNGnk2X0RHMMtHrhnC/d/U9l0+m/ZFNIaG6C8Yie YLeaVmTIKB1cST6IJINqpqtYIYajZODLVVF8i443t3Fz0bx3Vgu4MECarTmeWms+WgZ1 v0BjPlBn5tqY4KfMI47faLtvDmE7rU923WayBdsI0N0F76yIFIIjolsmSq9pa4dzJZYS 3xaIzIbukrGNqAiqj29RHtJeD+yi8vnwforHDGYmvyXg9DGQ8stSnDSR+L1yGw/w8FtV F0og== X-Gm-Message-State: ALoCoQlBE2XI1IsjI9lnQPwYKcDHnqcTICiZcm1IjMuin1BjouVTGeOX/GzYuvqB122AM4i9Lflz X-Received: by 10.50.132.39 with SMTP id or7mr6653730igb.90.1438895807061; Thu, 06 Aug 2015 14:16:47 -0700 (PDT) Received: from mail-ig0-f182.google.com (mail-ig0-f182.google.com. [209.85.213.182]) by smtp.gmail.com with ESMTPSA id g123sm5363838iog.31.2015.08.06.14.16.46 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 06 Aug 2015 14:16:46 -0700 (PDT) Received: by igk11 with SMTP id 11so19986834igk.1; Thu, 06 Aug 2015 14:16:45 -0700 (PDT) MIME-Version: 1.0 X-Received: by 10.50.61.179 with SMTP id q19mr6532581igr.24.1438895805860; Thu, 06 Aug 2015 14:16:45 -0700 (PDT) Received: by 10.36.89.70 with HTTP; Thu, 6 Aug 2015 14:16:45 -0700 (PDT) In-Reply-To: References: <20150805130607.20844.70680.idtracker@ietfa.amsl.com> <55C24293.5000603@cs.tcd.ie> <55C24C09.8020404@goodadvice.pages.de> <55C256C8.80606@jive.com> Date: Thu, 6 Aug 2015 17:16:45 -0400 Message-ID: From: Roman Shpount To: Jonathan Lennox Content-Type: multipart/alternative; boundary=047d7bdc109e609473051cab0986 Archived-At: Cc: "rtcweb@ietf.org" , mmusic , "tram@ietf.org" Subject: Re: [rtcweb] [tram] TURN permissions for private ips X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 06 Aug 2015 21:16:50 -0000 --047d7bdc109e609473051cab0986 Content-Type: text/plain; charset=UTF-8 On Thu, Aug 6, 2015 at 5:08 PM, Jonathan Lennox wrote: > > I can certainly imagine corporate WebRTC applications with an > application-configured TURN server in a DMZ. Another example might be a > cloud service which wants all its traffic to come in through a single port, > so it configures all applications to connect to it through a TURN port and > uses RFC 1918 addresses internally. > There are also countries like North Korea (not that a very popular place by a long shot, but it still exists) which runs their entire country in RFC 1918 address space: http://www.theregister.co.uk/2015/07/21/north_koreas_internet/ _____________ Roman Shpount --047d7bdc109e609473051cab0986 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On T= hu, Aug 6, 2015 at 5:08 PM, Jonathan Lennox <jonathan@vidyo.com>= wrote:

I can certainly imagin= e corporate WebRTC applications with an application-configured TURN server = in a DMZ.=C2=A0 Another example might be a cloud service which wants all it= s traffic to come in through a single port, so it configures all applicatio= ns to connect to it through a TURN port and uses RFC 1918 addresses interna= lly.

There are also countries like Nort= h Korea (not that a very popular place by a long shot, but it still exists)= which runs their entire country in RFC 1918 address space:=C2=A0http://www= .theregister.co.uk/2015/07/21/north_koreas_internet/
_____________
Roman Shpount
=C2= =A0
--047d7bdc109e609473051cab0986-- From nobody Thu Aug 6 14:36:45 2015 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1E1751A894E; Thu, 6 Aug 2015 14:36:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Jzt4Ho5fRqMO; Thu, 6 Aug 2015 14:36:34 -0700 (PDT) Received: from mail-la0-x22a.google.com (mail-la0-x22a.google.com [IPv6:2a00:1450:4010:c03::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 7A5F61A8951; Thu, 6 Aug 2015 14:36:34 -0700 (PDT) Received: by labjt7 with SMTP id jt7so39479784lab.0; Thu, 06 Aug 2015 14:36:32 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=6oakczvHVMr/nD3LkUJmJrDW6l0K9fzkG/FFurHHiNk=; b=bm8j2EeTScXDjLzgHq+Wq4/Vd8YDdrRMVbPhlvcAdRhfLWiVmsKgMO9pi0rg80UtoS /V6Zp1EZK3Lk0GYH022BnoDwzphpYhRRmKV95Cbekfkt3oPPgTJ+UoTPigbl1FJXIjCr GGQsEjd/XKf4pDBw9pFILaSanu7BpH4lyrKoFkqLM3JGvokF9xpkJtqYm5CLur2++XuE MBrGKsVr78dYVWeFcl0MyAL6HoHAAZ2EhE1gMwuYhJTPQ/afSvyfGrWeykqLMeun4HU8 h2SMB0KODFeC2EtMV1kbcabJQ127onsUNseNwDeLcUlcdRlkSjMMIrfiaSrU8ssG42WO mPwQ== MIME-Version: 1.0 X-Received: by 10.152.121.4 with SMTP id lg4mr4374404lab.112.1438896989786; Thu, 06 Aug 2015 14:36:29 -0700 (PDT) Received: by 10.25.197.87 with HTTP; Thu, 6 Aug 2015 14:36:29 -0700 (PDT) In-Reply-To: References: <20150805130607.20844.70680.idtracker@ietfa.amsl.com> <55C24293.5000603@cs.tcd.ie> <55C24C09.8020404@goodadvice.pages.de> <55C256C8.80606@jive.com> Date: Thu, 6 Aug 2015 14:36:29 -0700 Message-ID: From: Martin Thomson To: Jonathan Lennox Content-Type: text/plain; charset=UTF-8 Archived-At: Cc: mmusic , "rtcweb@ietf.org" , "tram@ietf.org" Subject: Re: [rtcweb] [tram] TURN permissions for private ips X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 06 Aug 2015 21:36:36 -0000 On 6 August 2015 at 14:08, Jonathan Lennox wrote: > What is the threat model/concern here? Are you trying to save 20 ms for the connectivity check, or are you concerned that the remote candidates are visible on the wire and to the turn server? Well, perhaps I'd missed the point of the thread, but my understanding was that attempting to pair TURN candidates with private address ranges had several negative characteristics: 1. they are unlikely to work 2. they expose the 1918 address to the TURN server 3. they expose the 1918 address to others (depending on whether DTLS is used to the TURN server and how far a check toward that address actually makes it through the network) 4. they consume a check slot Obviously, a lot of this hinges on the first point. If there is a reasonable chance that the pairing works, then maybe the other costs can be borne. From nobody Thu Aug 6 16:20:59 2015 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6D4641ACE4A for ; Thu, 6 Aug 2015 16:20:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sqDw30-l51f0 for ; Thu, 6 Aug 2015 16:20:57 -0700 (PDT) Received: from mail-wi0-x22c.google.com (mail-wi0-x22c.google.com [IPv6:2a00:1450:400c:c05::22c]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DA6D01ACE41 for ; Thu, 6 Aug 2015 16:20:55 -0700 (PDT) Received: by wibxm9 with SMTP id xm9so43824996wib.1 for ; Thu, 06 Aug 2015 16:20:54 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:date:message-id:subject:from:to:content-type; bh=Z8HnicNVZt7KVWbndhw//smXx8b/1WPqvjwS+sza7SQ=; b=gF60sl3vCUzuG6L/Om7P7dMPbSCm/lD01hhIAy4FjGKNXU3NbwnIm5bZplXoTMdH3z /Js3E0lkjqe+XLgTNEGgPGIECg9ivnDyzh7ME0W04dRj8nb4+x4z6BTtL/rNJXZ31oyA Qk0+47GVuZHYyErbLdYdkEM08DNQkBWncvwd0OX8rgFEOL+nPIPTE8JdN38LpioTykyQ 0zGEOxRjrxJkqQRiV2sE8nBAY+buQzpHHoLUtqudVoJ3gulnnRuiSPOjm9bs8rsqB41U FUDyTCbQm+pBbJixoJtwXx4qLJ6nz8iDnRxWqHwZ9P1LQwz+v8pN8GjnpIsqc6tnYJmv Ia4A== MIME-Version: 1.0 X-Received: by 10.194.108.232 with SMTP id hn8mr8152008wjb.154.1438903254604; Thu, 06 Aug 2015 16:20:54 -0700 (PDT) Received: by 10.194.17.68 with HTTP; Thu, 6 Aug 2015 16:20:54 -0700 (PDT) Date: Thu, 6 Aug 2015 16:20:54 -0700 Message-ID: From: Ted Hardie To: "rtcweb@ietf.org" Content-Type: multipart/alternative; boundary=047d7bf198a05b6582051cacc57a Archived-At: Subject: [rtcweb] Minutes review X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 06 Aug 2015 23:20:58 -0000 --047d7bf198a05b6582051cacc57a Content-Type: text/plain; charset=UTF-8 Howdy, The draft minutes are available for review here: https://www.ietf.org/proceedings/93/minutes/minutes-93-rtcweb There is a section of discussion related to the FEC presentation which did not get minuted, and if folks have notes on that, they would be appreciated (the audio in the meetecho recording is a valuable resource, but additional notes welcome). thanks, Ted --047d7bf198a05b6582051cacc57a Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Howdy,

The draft minutes = are available for review here:

https://www.ietf.org/proceedings/93/mi= nutes/minutes-93-rtcweb

There is a section of di= scussion related to the FEC presentation which did not get minuted, and if = folks have notes on that, they would be appreciated (the audio in the meete= cho recording is a valuable resource, but additional notes welcome).
thanks,

Ted
--047d7bf198a05b6582051cacc57a-- From nobody Thu Aug 6 17:01:26 2015 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 590DF1B3D74 for ; Thu, 6 Aug 2015 17:01:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.388 X-Spam-Level: X-Spam-Status: No, score=-1.388 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oGXVssupG-Ms for ; Thu, 6 Aug 2015 17:01:24 -0700 (PDT) Received: from mail-vk0-x233.google.com (mail-vk0-x233.google.com [IPv6:2607:f8b0:400c:c05::233]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2CADE1B3D7D for ; Thu, 6 Aug 2015 17:01:24 -0700 (PDT) Received: by vkhl6 with SMTP id l6so32999949vkh.1 for ; Thu, 06 Aug 2015 17:01:23 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=+jvOtPiCLesNSSM3LOjkJIqc2tv5/rdaGiTjAxd/OXQ=; b=Z12dJog1Bt5k4sEN9+FjGIcjd7bQHCSQb+RSOmLSVIzRXGaEBTEdB71HQX5Jtnt4JD rsoWu8GGRDLZ3GNONa2L0Cw+SC1YPMMKbGIXuQ2wnFPulbPIFX0ZWgHJUuRseLkwdOF4 i5gZTKJp+0+O5WWxqGk8beCxNwgT3W3nQQltST6qNrw9iPHQrRnQHCNENyGPCIDhyCG7 0A41bi1Ndx5oyuObGU/CQa6xjLWn3bcgPWxkURiX89vXrO3T4zninA3cY4IeRxqEt1Pt RvwuhLkcnSLSdfEXE+N5/QO6zcdtB5MwniJRHc5CVPc//TgcY6pg9Lk3Um/x2v2Sw8VI LSrg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type; bh=+jvOtPiCLesNSSM3LOjkJIqc2tv5/rdaGiTjAxd/OXQ=; b=cCuo2L6TI87kpbk2yMIFG49DKjMEzKwrivML9VO4zlKukM+4LSmpogoQxD6aEyq1nh taq5tTcMmJjDy2BplRW46YjQZoJReDq1ume3kfz2P7k56k/qN1w8VgxniIpxjsvQTZyv ka+3dJtXNTtaEyuY15NlsSkGZ869kOVfvneKeUNoi9uM2+fO7+uPzKb0oENLn9rouzCj OdUBGhnn4BkL6wgpB6aMKKLyeOCuf0zkHMtzuz4T/9m9RL6iaq4mzSsHllZv5srZwbgb bxByEbFbcxQuGgTlTyGkiczaQESlbXr1LzMJDOh6vUcurslFmpCbH6edGNWbvbdx0y++ 91Qw== X-Gm-Message-State: ALoCoQlLdKBQu94P/yXS3hVZvPuYi/g18eTujICXxKtPReD0ZQyWH48WpAeV4HJBP/Zk4ZgoDSKT X-Received: by 10.52.186.72 with SMTP id fi8mr5242407vdc.19.1438905683283; Thu, 06 Aug 2015 17:01:23 -0700 (PDT) MIME-Version: 1.0 Received: by 10.31.191.87 with HTTP; Thu, 6 Aug 2015 17:01:03 -0700 (PDT) In-Reply-To: References: <20150805130607.20844.70680.idtracker@ietfa.amsl.com> <55C24293.5000603@cs.tcd.ie> <55C24C09.8020404@goodadvice.pages.de> <55C256C8.80606@jive.com> From: Justin Uberti Date: Thu, 6 Aug 2015 17:01:03 -0700 Message-ID: To: Martin Thomson Content-Type: multipart/alternative; boundary=bcaec548a8211e4346051cad56b4 Archived-At: Cc: Jonathan Lennox , "rtcweb@ietf.org" , "tram@ietf.org" , mmusic Subject: Re: [rtcweb] [tram] TURN permissions for private ips X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 07 Aug 2015 00:01:25 -0000 --bcaec548a8211e4346051cad56b4 Content-Type: text/plain; charset=UTF-8 On Thu, Aug 6, 2015 at 1:51 PM, Martin Thomson wrote: > On 6 August 2015 at 13:08, Justin Uberti wrote: > > I think that we should be able to avoid pairing candidates obtained from > > application TURN servers with RFC 1918 addresses. The app/browser clearly > > knows which is which. > > I'm concerned here that if we let the application choose, we lose the > defence we were looking to gain. I think that perhaps 1918 pairing > could be restricted to TURN servers that are configured/discovered, > "proxy"-style. > Sorry, that is what I was trying to say. The browser knows which turn servers are "proxies" vs app servers, and can apply the 1918 filtering on the pairings from the candidates from the app TURN server. Agree with your enumeration of concerns as well. Also #5, they consume bandwidth (at least from client to TURN server), which affects maximum check rate in some cases. --bcaec548a8211e4346051cad56b4 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


On Thu, Aug 6, 2015 at 1:51 PM, Martin Thomson <martin.thomson@= gmail.com> wrote:
On 6 August 2015 at 13:08, Justin Uberti <juberti@google.com> wrote:
> I think that we should be able to avoid pairing candidates obtained fr= om
> application TURN servers with RFC 1918 addresses. The app/browser clea= rly
> knows which is which.

I'm concerned here that if we let the application choose, we los= e the
defence we were looking to gain.=C2=A0 I think that perhaps 1918 pairing could be restricted to TURN servers that are configured/discovered,
"proxy"-style.

Sorry, that is= what I was trying to say. The browser knows which turn servers are "p= roxies" vs app servers, and can apply the 1918 filtering on the pairin= gs from the candidates from the app TURN server.

A= gree with your enumeration of concerns as well. Also #5, they consume bandw= idth (at least from client to TURN server), which affects maximum check rat= e in some cases.

--bcaec548a8211e4346051cad56b4-- From nobody Thu Aug 6 17:12:17 2015 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CA4AA1A1BF4 for ; Thu, 6 Aug 2015 17:12:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.979 X-Spam-Level: X-Spam-Status: No, score=-1.979 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, 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 Oaucb4L03LaE for ; Thu, 6 Aug 2015 17:12:14 -0700 (PDT) Received: from mail-oi0-f46.google.com (mail-oi0-f46.google.com [209.85.218.46]) (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 0A7A91A1B47 for ; Thu, 6 Aug 2015 17:12:13 -0700 (PDT) Received: by oio137 with SMTP id 137so45235044oio.0 for ; Thu, 06 Aug 2015 17:12:13 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type; bh=Pxr/LuCD3rDOKSXP/EZUedVgPCzhxZ3Q6hpeb/ktcdk=; b=hjUkxBVtJBywhDDxsWYjXmauOWowWWoIYEw0l/GiQHb+PyeIVXPGSc/aUGqZH6Qwfl lklhUOtkJbFV23stydsIXfFgLml93+BO600S5DXRbcrDp/kA+WS3twONk750VygPXFgP Lh0nFSg35/fLC66ZnkSa/rrDdTQp4YtrO+nlyA8Vxf4zwj0L9HFGu/MnF/Ukh3wshVri CqFKhcnztXpFNQkTAsk04dsfGpznntPKBeqi2xiogCRiVZy4jjGS1ab+PlMy7OKyNSY0 GaBl1lNZkxBlMBfXcNZ+auXyMDbWYary/DMZk+noYmD+F02NbO5e/uKy3+N6540KCyaZ CsNQ== X-Gm-Message-State: ALoCoQmNbSnqJWnHdTWppDAzs6pbBEu1Yfnz/BfMVbXpdrmL668f5FTvPeJO+43VknlwBqwk273y X-Received: by 10.202.175.143 with SMTP id y137mr2053223oie.22.1438906333104; Thu, 06 Aug 2015 17:12:13 -0700 (PDT) Received: from mail-ob0-f178.google.com (mail-ob0-f178.google.com. [209.85.214.178]) by smtp.gmail.com with ESMTPSA id h128sm5026211oic.0.2015.08.06.17.12.12 for (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 06 Aug 2015 17:12:12 -0700 (PDT) Received: by obbfr1 with SMTP id fr1so31398090obb.1 for ; Thu, 06 Aug 2015 17:12:12 -0700 (PDT) X-Received: by 10.182.213.227 with SMTP id nv3mr4094704obc.10.1438906332349; Thu, 06 Aug 2015 17:12:12 -0700 (PDT) MIME-Version: 1.0 Received: by 10.76.83.167 with HTTP; Thu, 6 Aug 2015 17:11:52 -0700 (PDT) In-Reply-To: References: <20150805130607.20844.70680.idtracker@ietfa.amsl.com> <55C24293.5000603@cs.tcd.ie> <55C24C09.8020404@goodadvice.pages.de> <55C256C8.80606@jive.com> From: Emil Ivov Date: Thu, 6 Aug 2015 17:11:52 -0700 Message-ID: To: Justin Uberti Content-Type: text/plain; charset=UTF-8 Archived-At: Cc: Jonathan Lennox , mmusic , "tram@ietf.org" , "rtcweb@ietf.org" Subject: Re: [rtcweb] [tram] TURN permissions for private ips X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 07 Aug 2015 00:12:16 -0000 On Thu, Aug 6, 2015 at 5:01 PM, Justin Uberti wrote: > > > On Thu, Aug 6, 2015 at 1:51 PM, Martin Thomson > wrote: >> >> On 6 August 2015 at 13:08, Justin Uberti wrote: >> > I think that we should be able to avoid pairing candidates obtained from >> > application TURN servers with RFC 1918 addresses. The app/browser >> > clearly >> > knows which is which. >> >> I'm concerned here that if we let the application choose, we lose the >> defence we were looking to gain. I think that perhaps 1918 pairing >> could be restricted to TURN servers that are configured/discovered, >> "proxy"-style. > > > Sorry, that is what I was trying to say. The browser knows which turn > servers are "proxies" vs app servers, and can apply the 1918 filtering on > the pairings from the candidates from the app TURN server. I don't think Jonathan's concerns only apply to proxies though. You can just as well have apps developed for specific networks and there is no reason to prevent those from working. > Agree with your enumeration of concerns as well. Also #5, they consume > bandwidth (at least from client to TURN server), which affects maximum check > rate in some cases. Why can't we address this by TURN servers simply refusing to create permissions for candidates they know they won't be able to reach? Emil -- https://jitsi.org From nobody Thu Aug 6 17:46:31 2015 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D34411ACDC7 for ; Thu, 6 Aug 2015 17:46:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.388 X-Spam-Level: X-Spam-Status: No, score=-1.388 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KRFF5yDJsgp6 for ; Thu, 6 Aug 2015 17:46:28 -0700 (PDT) Received: from mail-vk0-x22b.google.com (mail-vk0-x22b.google.com [IPv6:2607:f8b0:400c:c05::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 552FE1ACDB9 for ; Thu, 6 Aug 2015 17:46:28 -0700 (PDT) Received: by vkci6 with SMTP id i6so33734704vkc.3 for ; Thu, 06 Aug 2015 17:46:27 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=SuIeVYvp28UUfKlQhc9k3RUSCYOQW2f6eFVKgdTRSs8=; b=nylZ7C2/lCD1DGh4b5rCaOVQoL6J4Zs2XNxYDlUGVP59e/YihsYX+gFTxTEZjKol82 zW/FINu7oTpJZ7Pq94YlPSfCC8JyEdaVYocqsJhUKhNK+U5S0IwEUfNuUvd5fqNOX0ab G1fHYbhwy2Zm/p7N7L4B2H22/6wnYyWfYQGe2Kwqq5SPbD8ypRyXZ8eY+BTGO3/GcYuM XZbS+gMo05vDnOiPJJcBaAMee9+vCNn0uCM6Gq0yq6T4BfoxOelDd60NWkSRt6iRIRFA Cwdp6s2k6sCUo7ll53JpHMBPqaa+cD5n6WlrvbZuVY8awKrQUfVUI78gcDLs8YS9+cQx 7jDQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type; bh=SuIeVYvp28UUfKlQhc9k3RUSCYOQW2f6eFVKgdTRSs8=; b=OrAp6GZNWRyHnRBG67Vz41g1Etw/6qPF+6XynL9prkvlrc6epMxgF0fX08ajoX0Gps gfE6u4gB93MfM9AWL9nTs47yOASt68GszCbihz/I6kfoTMvzn51gRpj7VVxth/AJ1v8a tE7DsFncS2GzvBRxhPSG6tEdol80esMVY6xPRgVR5dFAX3jsev+Une4gAlPpQAlw4auj mk6DrMdR3Znpz6NPuOZlxdGXGwdw0Fqu961Gjuri100RNf2hvtnQ61HlzgU8h3Ed4BZB lJbpLkxsWJDYgprKgjggI05PwE+ZS9Zx0kwZ8J1F7Swzx0n0lvwApmxe9fXqbEq/6M2s EqbA== X-Gm-Message-State: ALoCoQmh4YUeYaBKumcMp9no0iSvJC0Xf6j+A4REQCgCbXHavSkQMrafUz3EW4BXZAsGuZgvEWrm X-Received: by 10.52.186.72 with SMTP id fi8mr5393953vdc.19.1438908387526; Thu, 06 Aug 2015 17:46:27 -0700 (PDT) MIME-Version: 1.0 Received: by 10.31.191.87 with HTTP; Thu, 6 Aug 2015 17:46:08 -0700 (PDT) In-Reply-To: References: <20150805130607.20844.70680.idtracker@ietfa.amsl.com> <55C24293.5000603@cs.tcd.ie> <55C24C09.8020404@goodadvice.pages.de> <55C256C8.80606@jive.com> From: Justin Uberti Date: Thu, 6 Aug 2015 17:46:08 -0700 Message-ID: To: Emil Ivov Content-Type: multipart/alternative; boundary=bcaec548a8214dbe34051cadf779 Archived-At: Cc: Jonathan Lennox , mmusic , "tram@ietf.org" , "rtcweb@ietf.org" Subject: Re: [rtcweb] [tram] TURN permissions for private ips X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 07 Aug 2015 00:46:30 -0000 --bcaec548a8214dbe34051cadf779 Content-Type: text/plain; charset=UTF-8 On Thu, Aug 6, 2015 at 5:11 PM, Emil Ivov wrote: > On Thu, Aug 6, 2015 at 5:01 PM, Justin Uberti wrote: > > > > > > On Thu, Aug 6, 2015 at 1:51 PM, Martin Thomson > > > wrote: > >> > >> On 6 August 2015 at 13:08, Justin Uberti wrote: > >> > I think that we should be able to avoid pairing candidates obtained > from > >> > application TURN servers with RFC 1918 addresses. The app/browser > >> > clearly > >> > knows which is which. > >> > >> I'm concerned here that if we let the application choose, we lose the > >> defence we were looking to gain. I think that perhaps 1918 pairing > >> could be restricted to TURN servers that are configured/discovered, > >> "proxy"-style. > > > > > > Sorry, that is what I was trying to say. The browser knows which turn > > servers are "proxies" vs app servers, and can apply the 1918 filtering on > > the pairings from the candidates from the app TURN server. > > I don't think Jonathan's concerns only apply to proxies though. You > can just as well have apps developed for specific networks and there > is no reason to prevent those from working. > > > Agree with your enumeration of concerns as well. Also #5, they consume > > bandwidth (at least from client to TURN server), which affects maximum > check > > rate in some cases. > > Why can't we address this by TURN servers simply refusing to create > permissions for candidates they know they won't be able to reach? That is one potential solution, which would solve #1/#4/#5. --bcaec548a8214dbe34051cadf779 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


On Thu, Aug 6, 2015 at 5:11 PM, Emil Ivov <emcho@jitsi.org> wrote:
On Thu, Aug 6, = 2015 at 5:01 PM, Justin Uberti <ju= berti@google.com> wrote:
>
>
> On Thu, Aug 6, 2015 at 1:51 PM, Martin Thomson <martin.thomson@gmail.com>
> wrote:
>>
>> On 6 August 2015 at 13:08, Justin Uberti <juberti@google.com> wrote:
>> > I think that we should be able to avoid pairing candidates ob= tained from
>> > application TURN servers with RFC 1918 addresses. The app/bro= wser
>> > clearly
>> > knows which is which.
>>
>> I'm concerned here that if we let the application choose, we l= ose the
>> defence we were looking to gain.=C2=A0 I think that perhaps 1918 p= airing
>> could be restricted to TURN servers that are configured/discovered= ,
>> "proxy"-style.
>
>
> Sorry, that is what I was trying to say. The browser knows which turn<= br> > servers are "proxies" vs app servers, and can apply the 1918= filtering on
> the pairings from the candidates from the app TURN server.

I don't think Jonathan's concerns only apply to proxies thou= gh. You
can just as well have apps developed for specific networks and there
is no reason to prevent those from working.

> Agree with your enumeration of concerns as well. Also #5, they consume=
> bandwidth (at least from client to TURN server), which affects maximum= check
> rate in some cases.

Why can't we address this by TURN servers simply refusing to cre= ate
permissions for candidates they know they won't be able to reach?

That is one potential solution, which would solv= e #1/#4/#5.
--bcaec548a8214dbe34051cadf779-- From nobody Thu Aug 6 19:25:25 2015 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 453FA1B4065 for ; Thu, 6 Aug 2015 19:25:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.979 X-Spam-Level: X-Spam-Status: No, score=-1.979 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, 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 lSC4VP5luZF1 for ; Thu, 6 Aug 2015 19:25:20 -0700 (PDT) Received: from mail-ob0-f180.google.com (mail-ob0-f180.google.com [209.85.214.180]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D961F1B4066 for ; Thu, 6 Aug 2015 19:25:18 -0700 (PDT) Received: by obdeg2 with SMTP id eg2so69962425obd.0 for ; Thu, 06 Aug 2015 19:25:17 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type; bh=bYdfo3I6vDImBvXmPvh2vGuDIbWwHwXpG6o3Aa7z7tU=; b=RxeluiQ4iFQea7DBOcHXG738QTbAxcxWuElkb7DDX++JjSoUCNTkhuqIxZBDhzH5SB SYThZvDyDXmIBxKTGTaHWsYeNbbDHRAS8HnrXnBHI4DWk+rvCvqDH57MVR6TdFbcYzpA 3k4JAG9srzQ21IXfSBgJMG9Xflpml6FiaeX0xwhamFuRWkqlxl4eJwayJa7cdzGNW0iB kCytJcO7fxwI73vdRS5BaQg2XpkcgMf7ktdxIJzh1F/39TPIuU3GY90ypO0Hkb8SSQOB UIy1SA+ZtXhG/yGUTh2/VwI72uwc5nN/nMNOp79FxYkd3fCKGH7fqLbeCtdBpQMG+EO7 PpDg== X-Gm-Message-State: ALoCoQnTHkCE9C1N3dodM42KRoxDdsq9SJ/2nFBgfM2kgFwSblO0HjXOUIXEbx4RBhgE2egibkPx X-Received: by 10.60.132.108 with SMTP id ot12mr4658924oeb.44.1438914317486; Thu, 06 Aug 2015 19:25:17 -0700 (PDT) Received: from mail-oi0-f49.google.com (mail-oi0-f49.google.com. [209.85.218.49]) by smtp.gmail.com with ESMTPSA id os15sm5159989oeb.8.2015.08.06.19.25.16 for (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 06 Aug 2015 19:25:17 -0700 (PDT) Received: by oihn130 with SMTP id n130so49762996oih.2 for ; Thu, 06 Aug 2015 19:25:16 -0700 (PDT) X-Received: by 10.202.77.144 with SMTP id a138mr4313768oib.32.1438914316644; Thu, 06 Aug 2015 19:25:16 -0700 (PDT) MIME-Version: 1.0 Received: by 10.76.83.167 with HTTP; Thu, 6 Aug 2015 19:24:57 -0700 (PDT) In-Reply-To: References: <20150805130607.20844.70680.idtracker@ietfa.amsl.com> <55C24293.5000603@cs.tcd.ie> <55C24C09.8020404@goodadvice.pages.de> <55C256C8.80606@jive.com> From: Emil Ivov Date: Thu, 6 Aug 2015 19:24:57 -0700 Message-ID: To: Justin Uberti Content-Type: text/plain; charset=UTF-8 Archived-At: Cc: Jonathan Lennox , mmusic , "tram@ietf.org" , "rtcweb@ietf.org" Subject: Re: [rtcweb] [tram] TURN permissions for private ips X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 07 Aug 2015 02:25:21 -0000 On Thu, Aug 6, 2015 at 5:46 PM, Justin Uberti wrote: > > > On Thu, Aug 6, 2015 at 5:11 PM, Emil Ivov wrote: >> >> On Thu, Aug 6, 2015 at 5:01 PM, Justin Uberti wrote: >> > >> > >> > On Thu, Aug 6, 2015 at 1:51 PM, Martin Thomson >> > >> > wrote: >> >> >> >> On 6 August 2015 at 13:08, Justin Uberti wrote: >> >> > I think that we should be able to avoid pairing candidates obtained >> >> > from >> >> > application TURN servers with RFC 1918 addresses. The app/browser >> >> > clearly >> >> > knows which is which. >> >> >> >> I'm concerned here that if we let the application choose, we lose the >> >> defence we were looking to gain. I think that perhaps 1918 pairing >> >> could be restricted to TURN servers that are configured/discovered, >> >> "proxy"-style. >> > >> > >> > Sorry, that is what I was trying to say. The browser knows which turn >> > servers are "proxies" vs app servers, and can apply the 1918 filtering >> > on >> > the pairings from the candidates from the app TURN server. >> >> I don't think Jonathan's concerns only apply to proxies though. You >> can just as well have apps developed for specific networks and there >> is no reason to prevent those from working. >> >> > Agree with your enumeration of concerns as well. Also #5, they consume >> > bandwidth (at least from client to TURN server), which affects maximum >> > check >> > rate in some cases. >> >> Why can't we address this by TURN servers simply refusing to create >> permissions for candidates they know they won't be able to reach? > > > That is one potential solution, which would solve #1/#4/#5. So, let's say that Alice calls Bob using SuperApp. Alice sends her 10.0.0.1 address to SuperApp's server, which then sends it to Bob. So Bob and SuperApp now know about Alice's 10.0.0.1 but there's no way around this. Bob, could be in the same network as Alice so it has to try her private address. Next, Bob installs 10.0.0.1 on the TURN server provided by SuperApp, which also now learns about 10.0.0.1. As long as that server is hosted by the same people as SuperApp (which we can probably consider as the common case) then we haven't leaked anything. If the TURN server is hosted by a third party (SuperTURN) then SuperTURN do get to learn a little bit of extra information, namely that Alice's public address has a private network in the 10.0.0.0 range behind it and that 10.0.0.1 is being used by someone. That's all though. SuperTURN should have no other information regarding Alice and what little it just learned was not hard to guess any way. So I am not sure exactly what we are trying to solve here. Emil -- https://jitsi.org From nobody Fri Aug 7 00:47:40 2015 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 688A41B381E; Fri, 7 Aug 2015 00:47:38 -0700 (PDT) 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 PDPXeSSC28CL; Fri, 7 Aug 2015 00:47:36 -0700 (PDT) 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 510961B3817; Fri, 7 Aug 2015 00:47:36 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=24592; q=dns/txt; s=iport; t=1438933656; x=1440143256; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=9N81s85Sn+NI7nU9oy8haMMLbh6itUeUvZTrZIxUceg=; b=c9pQG4SbdyfrCeGJKkk5eR+1hRwItCkVOj7fvEbkp8nND8VgOEvkXU0N gyZzYSuvyY4BdSmX0oKNMkD20u3w+tzkuLU2OTyvybvFtYcCwarFSGddD QvofPUn+S0gd3JLy3HVxX54RG+7ukR1oau7BGF+ajvKZDQGCZqu9N48cc o=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: A0A8BQAZYcRV/4QNJK1bgk5NVGkGgx26AYF6AQmFL0oCHIEkOhIBAQEBAQEBgQqEJAEBBAEBASBJAggDEAIBCA4qBwMCAgIfBgsUEQIEDgWIGQMSDbcqkHANhSwBAQEBAQEBAQEBAQEBAQEBAQEBAQETBItPgk+Bb0cEB4JpL4EUBZUHAYR+hW+Ba4FHkHyDTYNkJoN9b4FIgQQBAQE X-IronPort-AV: E=Sophos;i="5.15,628,1432598400"; d="scan'208,217";a="176330403" Received: from alln-core-10.cisco.com ([173.36.13.132]) by alln-iport-6.cisco.com with ESMTP; 07 Aug 2015 07:47:35 +0000 Received: from XCH-RCD-008.cisco.com (xch-rcd-008.cisco.com [173.37.102.18]) by alln-core-10.cisco.com (8.14.5/8.14.5) with ESMTP id t777lZXI029690 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Fri, 7 Aug 2015 07:47:35 GMT Received: from xch-rcd-008.cisco.com (173.37.102.18) by XCH-RCD-008.cisco.com (173.37.102.18) with Microsoft SMTP Server (TLS) id 15.0.1104.5; Fri, 7 Aug 2015 02:47:34 -0500 Received: from xhc-aln-x06.cisco.com (173.36.12.80) by xch-rcd-008.cisco.com (173.37.102.18) with Microsoft SMTP Server (TLS) id 15.0.1104.5 via Frontend Transport; Fri, 7 Aug 2015 02:47:34 -0500 Received: from xmb-rcd-x06.cisco.com ([169.254.6.133]) by xhc-aln-x06.cisco.com ([173.36.12.80]) with mapi id 14.03.0248.002; Fri, 7 Aug 2015 02:47:34 -0500 From: "Pal Martinsen (palmarti)" To: Emil Ivov Thread-Topic: [rtcweb] [tram] TURN permissions for private ips Thread-Index: AQHQ0KQ4GdSUE5mBkES+Q0lZrOYQnJ3//dsAgAB/T4A= Date: Fri, 7 Aug 2015 07:47:33 +0000 Message-ID: <3F10035A-70A4-46AE-AB44-4499541AC7C6@cisco.com> References: <20150805130607.20844.70680.idtracker@ietfa.amsl.com> <55C24293.5000603@cs.tcd.ie> <55C24C09.8020404@goodadvice.pages.de> <55C256C8.80606@jive.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [173.37.102.23] Content-Type: multipart/alternative; boundary="_000_3F10035A70A446AEAB444499541AC7C6ciscocom_" MIME-Version: 1.0 Archived-At: Cc: Jonathan Lennox , "rtcweb@ietf.org" , "tram@ietf.org" , mmusic Subject: Re: [rtcweb] [tram] TURN permissions for private ips X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 07 Aug 2015 07:47:38 -0000 --_000_3F10035A70A446AEAB444499541AC7C6ciscocom_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 DQpPbiAwNyBBdWcgMjAxNSwgYXQgMDI6MTEsIEVtaWwgSXZvdiA8ZW1jaG9Aaml0c2kub3JnPG1h aWx0bzplbWNob0BqaXRzaS5vcmc+PiB3cm90ZToNCg0KT24gVGh1LCBBdWcgNiwgMjAxNSBhdCA1 OjAxIFBNLCBKdXN0aW4gVWJlcnRpIDxqdWJlcnRpQGdvb2dsZS5jb208bWFpbHRvOmp1YmVydGlA Z29vZ2xlLmNvbT4+IHdyb3RlOg0KDQoNCk9uIFRodSwgQXVnIDYsIDIwMTUgYXQgMTo1MSBQTSwg TWFydGluIFRob21zb24gPG1hcnRpbi50aG9tc29uQGdtYWlsLmNvbTxtYWlsdG86bWFydGluLnRo b21zb25AZ21haWwuY29tPj4NCndyb3RlOg0KDQpPbiA2IEF1Z3VzdCAyMDE1IGF0IDEzOjA4LCBK dXN0aW4gVWJlcnRpIDxqdWJlcnRpQGdvb2dsZS5jb208bWFpbHRvOmp1YmVydGlAZ29vZ2xlLmNv bT4+IHdyb3RlOg0KSSB0aGluayB0aGF0IHdlIHNob3VsZCBiZSBhYmxlIHRvIGF2b2lkIHBhaXJp bmcgY2FuZGlkYXRlcyBvYnRhaW5lZCBmcm9tDQphcHBsaWNhdGlvbiBUVVJOIHNlcnZlcnMgd2l0 aCBSRkMgMTkxOCBhZGRyZXNzZXMuIFRoZSBhcHAvYnJvd3Nlcg0KY2xlYXJseQ0Ka25vd3Mgd2hp Y2ggaXMgd2hpY2guDQoNCkknbSBjb25jZXJuZWQgaGVyZSB0aGF0IGlmIHdlIGxldCB0aGUgYXBw bGljYXRpb24gY2hvb3NlLCB3ZSBsb3NlIHRoZQ0KZGVmZW5jZSB3ZSB3ZXJlIGxvb2tpbmcgdG8g Z2Fpbi4gIEkgdGhpbmsgdGhhdCBwZXJoYXBzIDE5MTggcGFpcmluZw0KY291bGQgYmUgcmVzdHJp Y3RlZCB0byBUVVJOIHNlcnZlcnMgdGhhdCBhcmUgY29uZmlndXJlZC9kaXNjb3ZlcmVkLA0KInBy b3h5Ii1zdHlsZS4NCg0KDQpTb3JyeSwgdGhhdCBpcyB3aGF0IEkgd2FzIHRyeWluZyB0byBzYXku IFRoZSBicm93c2VyIGtub3dzIHdoaWNoIHR1cm4NCnNlcnZlcnMgYXJlICJwcm94aWVzIiB2cyBh cHAgc2VydmVycywgYW5kIGNhbiBhcHBseSB0aGUgMTkxOCBmaWx0ZXJpbmcgb24NCnRoZSBwYWly aW5ncyBmcm9tIHRoZSBjYW5kaWRhdGVzIGZyb20gdGhlIGFwcCBUVVJOIHNlcnZlci4NCg0KSSBk b24ndCB0aGluayBKb25hdGhhbidzIGNvbmNlcm5zIG9ubHkgYXBwbHkgdG8gcHJveGllcyB0aG91 Z2guIFlvdQ0KY2FuIGp1c3QgYXMgd2VsbCBoYXZlIGFwcHMgZGV2ZWxvcGVkIGZvciBzcGVjaWZp YyBuZXR3b3JrcyBhbmQgdGhlcmUNCmlzIG5vIHJlYXNvbiB0byBwcmV2ZW50IHRob3NlIGZyb20g d29ya2luZy4NCg0KQWdyZWUgd2l0aCB5b3VyIGVudW1lcmF0aW9uIG9mIGNvbmNlcm5zIGFzIHdl bGwuIEFsc28gIzUsIHRoZXkgY29uc3VtZQ0KYmFuZHdpZHRoIChhdCBsZWFzdCBmcm9tIGNsaWVu dCB0byBUVVJOIHNlcnZlciksIHdoaWNoIGFmZmVjdHMgbWF4aW11bSBjaGVjaw0KcmF0ZSBpbiBz b21lIGNhc2VzLg0KDQpXaHkgY2FuJ3Qgd2UgYWRkcmVzcyB0aGlzIGJ5IFRVUk4gc2VydmVycyBz aW1wbHkgcmVmdXNpbmcgdG8gY3JlYXRlDQpwZXJtaXNzaW9ucyBmb3IgY2FuZGlkYXRlcyB0aGV5 IGtub3cgdGhleSB3b24ndCBiZSBhYmxlIHRvIHJlYWNoPw0KDQpIb3cgZG8geW91IHJlbGlhYmx5 IGFuZCBzaW1wbHkgZG8gdGhhdCB3aXRob3V0IGEgY29ubmVjdGl2aXR5IGNoZWNrPw0KDQpJZiB0 aGUgbWFpbiBjb25jZXJuIGlzIGluZm9ybWF0aW9uIGxlYWthZ2UsIGlzbuKAmXQgdGhhdCB1cCB0 byB0aGUgY2xpZW50IHRvIGRlY2lkZSB3aGF0IGl0IHdhbnQgdG8gcmV2ZWFsIHRvIHRoZSBUVVJO IHNlcnZlciBhbmQgdGhlIHJlbW90ZSBjbGllbnQ/DQoNCkd1ZXNzIHdoYXQgSSBhbSBzYXlpbmcg aXMgdGhhdCBJIHRoaW5rIGl0IGlzIGEgZ29vZCB0aGluZyB0byBoYXZlIGEg4oCcdGhpY2vigJ0g Y2xpZW50IGFuZCByZWxhdGl2ZWx5IHNpbXBsZSBuZXR3b3JrIGNvbXBvbmVudHMuDQoNCi4tLg0K UMOlbC1FcmlrDQoNCg0KRW1pbA0KDQotLQ0KaHR0cHM6Ly9qaXRzaS5vcmc8aHR0cHM6Ly9qaXRz aS5vcmcvPg0KDQpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f Xw0KcnRjd2ViIG1haWxpbmcgbGlzdA0KcnRjd2ViQGlldGYub3JnPG1haWx0bzpydGN3ZWJAaWV0 Zi5vcmc+DQpodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL3J0Y3dlYg0KDQo= --_000_3F10035A70A446AEAB444499541AC7C6ciscocom_ Content-Type: text/html; charset="utf-8" Content-ID: Content-Transfer-Encoding: base64 PGh0bWw+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIgY29udGVudD0i dGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjwvaGVhZD4NCjxib2R5IHN0eWxlPSJ3b3JkLXdy YXA6IGJyZWFrLXdvcmQ7IC13ZWJraXQtbmJzcC1tb2RlOiBzcGFjZTsgLXdlYmtpdC1saW5lLWJy ZWFrOiBhZnRlci13aGl0ZS1zcGFjZTsiIGNsYXNzPSIiPg0KPGJyIGNsYXNzPSIiPg0KPGRpdj4N CjxibG9ja3F1b3RlIHR5cGU9ImNpdGUiIGNsYXNzPSIiPg0KPGRpdiBjbGFzcz0iIj5PbiAwNyBB dWcgMjAxNSwgYXQgMDI6MTEsIEVtaWwgSXZvdiAmbHQ7PGEgaHJlZj0ibWFpbHRvOmVtY2hvQGpp dHNpLm9yZyIgY2xhc3M9IiI+ZW1jaG9Aaml0c2kub3JnPC9hPiZndDsgd3JvdGU6PC9kaXY+DQo8 YnIgY2xhc3M9IkFwcGxlLWludGVyY2hhbmdlLW5ld2xpbmUiPg0KPGRpdiBjbGFzcz0iIj48c3Bh biBzdHlsZT0iZm9udC1mYW1pbHk6IEhlbHZldGljYTsgZm9udC1zaXplOiAxMnB4OyBmb250LXN0 eWxlOiBub3JtYWw7IGZvbnQtdmFyaWFudDogbm9ybWFsOyBmb250LXdlaWdodDogbm9ybWFsOyBs ZXR0ZXItc3BhY2luZzogbm9ybWFsOyBsaW5lLWhlaWdodDogbm9ybWFsOyBvcnBoYW5zOiBhdXRv OyB0ZXh0LWFsaWduOiBzdGFydDsgdGV4dC1pbmRlbnQ6IDBweDsgdGV4dC10cmFuc2Zvcm06IG5v bmU7IHdoaXRlLXNwYWNlOiBub3JtYWw7IHdpZG93czogYXV0bzsgd29yZC1zcGFjaW5nOiAwcHg7 IC13ZWJraXQtdGV4dC1zdHJva2Utd2lkdGg6IDBweDsgZmxvYXQ6IG5vbmU7IGRpc3BsYXk6IGlu bGluZSAhaW1wb3J0YW50OyIgY2xhc3M9IiI+T24NCiBUaHUsIEF1ZyA2LCAyMDE1IGF0IDU6MDEg UE0sIEp1c3RpbiBVYmVydGkgJmx0Ozwvc3Bhbj48YSBocmVmPSJtYWlsdG86anViZXJ0aUBnb29n bGUuY29tIiBzdHlsZT0iZm9udC1mYW1pbHk6IEhlbHZldGljYTsgZm9udC1zaXplOiAxMnB4OyBm b250LXN0eWxlOiBub3JtYWw7IGZvbnQtdmFyaWFudDogbm9ybWFsOyBmb250LXdlaWdodDogbm9y bWFsOyBsZXR0ZXItc3BhY2luZzogbm9ybWFsOyBsaW5lLWhlaWdodDogbm9ybWFsOyBvcnBoYW5z OiBhdXRvOyB0ZXh0LWFsaWduOiBzdGFydDsgdGV4dC1pbmRlbnQ6IDBweDsgdGV4dC10cmFuc2Zv cm06IG5vbmU7IHdoaXRlLXNwYWNlOiBub3JtYWw7IHdpZG93czogYXV0bzsgd29yZC1zcGFjaW5n OiAwcHg7IC13ZWJraXQtdGV4dC1zdHJva2Utd2lkdGg6IDBweDsiIGNsYXNzPSIiPmp1YmVydGlA Z29vZ2xlLmNvbTwvYT48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6IEhlbHZldGljYTsgZm9udC1z aXplOiAxMnB4OyBmb250LXN0eWxlOiBub3JtYWw7IGZvbnQtdmFyaWFudDogbm9ybWFsOyBmb250 LXdlaWdodDogbm9ybWFsOyBsZXR0ZXItc3BhY2luZzogbm9ybWFsOyBsaW5lLWhlaWdodDogbm9y bWFsOyBvcnBoYW5zOiBhdXRvOyB0ZXh0LWFsaWduOiBzdGFydDsgdGV4dC1pbmRlbnQ6IDBweDsg dGV4dC10cmFuc2Zvcm06IG5vbmU7IHdoaXRlLXNwYWNlOiBub3JtYWw7IHdpZG93czogYXV0bzsg d29yZC1zcGFjaW5nOiAwcHg7IC13ZWJraXQtdGV4dC1zdHJva2Utd2lkdGg6IDBweDsgZmxvYXQ6 IG5vbmU7IGRpc3BsYXk6IGlubGluZSAhaW1wb3J0YW50OyIgY2xhc3M9IiI+Jmd0Ow0KIHdyb3Rl Ojwvc3Bhbj48YnIgc3R5bGU9ImZvbnQtZmFtaWx5OiBIZWx2ZXRpY2E7IGZvbnQtc2l6ZTogMTJw eDsgZm9udC1zdHlsZTogbm9ybWFsOyBmb250LXZhcmlhbnQ6IG5vcm1hbDsgZm9udC13ZWlnaHQ6 IG5vcm1hbDsgbGV0dGVyLXNwYWNpbmc6IG5vcm1hbDsgbGluZS1oZWlnaHQ6IG5vcm1hbDsgb3Jw aGFuczogYXV0bzsgdGV4dC1hbGlnbjogc3RhcnQ7IHRleHQtaW5kZW50OiAwcHg7IHRleHQtdHJh bnNmb3JtOiBub25lOyB3aGl0ZS1zcGFjZTogbm9ybWFsOyB3aWRvd3M6IGF1dG87IHdvcmQtc3Bh Y2luZzogMHB4OyAtd2Via2l0LXRleHQtc3Ryb2tlLXdpZHRoOiAwcHg7IiBjbGFzcz0iIj4NCjxi bG9ja3F1b3RlIHR5cGU9ImNpdGUiIHN0eWxlPSJmb250LWZhbWlseTogSGVsdmV0aWNhOyBmb250 LXNpemU6IDEycHg7IGZvbnQtc3R5bGU6IG5vcm1hbDsgZm9udC12YXJpYW50OiBub3JtYWw7IGZv bnQtd2VpZ2h0OiBub3JtYWw7IGxldHRlci1zcGFjaW5nOiBub3JtYWw7IGxpbmUtaGVpZ2h0OiBu b3JtYWw7IG9ycGhhbnM6IGF1dG87IHRleHQtYWxpZ246IHN0YXJ0OyB0ZXh0LWluZGVudDogMHB4 OyB0ZXh0LXRyYW5zZm9ybTogbm9uZTsgd2hpdGUtc3BhY2U6IG5vcm1hbDsgd2lkb3dzOiBhdXRv OyB3b3JkLXNwYWNpbmc6IDBweDsgLXdlYmtpdC10ZXh0LXN0cm9rZS13aWR0aDogMHB4OyIgY2xh c3M9IiI+DQo8YnIgY2xhc3M9IiI+DQo8YnIgY2xhc3M9IiI+DQpPbiBUaHUsIEF1ZyA2LCAyMDE1 IGF0IDE6NTEgUE0sIE1hcnRpbiBUaG9tc29uICZsdDs8YSBocmVmPSJtYWlsdG86bWFydGluLnRo b21zb25AZ21haWwuY29tIiBjbGFzcz0iIj5tYXJ0aW4udGhvbXNvbkBnbWFpbC5jb208L2E+Jmd0 OzxiciBjbGFzcz0iIj4NCndyb3RlOjxiciBjbGFzcz0iIj4NCjxibG9ja3F1b3RlIHR5cGU9ImNp dGUiIGNsYXNzPSIiPjxiciBjbGFzcz0iIj4NCk9uIDYgQXVndXN0IDIwMTUgYXQgMTM6MDgsIEp1 c3RpbiBVYmVydGkgJmx0OzxhIGhyZWY9Im1haWx0bzpqdWJlcnRpQGdvb2dsZS5jb20iIGNsYXNz PSIiPmp1YmVydGlAZ29vZ2xlLmNvbTwvYT4mZ3Q7IHdyb3RlOjxiciBjbGFzcz0iIj4NCjxibG9j a3F1b3RlIHR5cGU9ImNpdGUiIGNsYXNzPSIiPkkgdGhpbmsgdGhhdCB3ZSBzaG91bGQgYmUgYWJs ZSB0byBhdm9pZCBwYWlyaW5nIGNhbmRpZGF0ZXMgb2J0YWluZWQgZnJvbTxiciBjbGFzcz0iIj4N CmFwcGxpY2F0aW9uIFRVUk4gc2VydmVycyB3aXRoIFJGQyAxOTE4IGFkZHJlc3Nlcy4gVGhlIGFw cC9icm93c2VyPGJyIGNsYXNzPSIiPg0KY2xlYXJseTxiciBjbGFzcz0iIj4NCmtub3dzIHdoaWNo IGlzIHdoaWNoLjxiciBjbGFzcz0iIj4NCjwvYmxvY2txdW90ZT4NCjxiciBjbGFzcz0iIj4NCkkn bSBjb25jZXJuZWQgaGVyZSB0aGF0IGlmIHdlIGxldCB0aGUgYXBwbGljYXRpb24gY2hvb3NlLCB3 ZSBsb3NlIHRoZTxiciBjbGFzcz0iIj4NCmRlZmVuY2Ugd2Ugd2VyZSBsb29raW5nIHRvIGdhaW4u ICZuYnNwO0kgdGhpbmsgdGhhdCBwZXJoYXBzIDE5MTggcGFpcmluZzxiciBjbGFzcz0iIj4NCmNv dWxkIGJlIHJlc3RyaWN0ZWQgdG8gVFVSTiBzZXJ2ZXJzIHRoYXQgYXJlIGNvbmZpZ3VyZWQvZGlz Y292ZXJlZCw8YnIgY2xhc3M9IiI+DQomcXVvdDtwcm94eSZxdW90Oy1zdHlsZS48YnIgY2xhc3M9 IiI+DQo8L2Jsb2NrcXVvdGU+DQo8YnIgY2xhc3M9IiI+DQo8YnIgY2xhc3M9IiI+DQpTb3JyeSwg dGhhdCBpcyB3aGF0IEkgd2FzIHRyeWluZyB0byBzYXkuIFRoZSBicm93c2VyIGtub3dzIHdoaWNo IHR1cm48YnIgY2xhc3M9IiI+DQpzZXJ2ZXJzIGFyZSAmcXVvdDtwcm94aWVzJnF1b3Q7IHZzIGFw cCBzZXJ2ZXJzLCBhbmQgY2FuIGFwcGx5IHRoZSAxOTE4IGZpbHRlcmluZyBvbjxiciBjbGFzcz0i Ij4NCnRoZSBwYWlyaW5ncyBmcm9tIHRoZSBjYW5kaWRhdGVzIGZyb20gdGhlIGFwcCBUVVJOIHNl cnZlci48YnIgY2xhc3M9IiI+DQo8L2Jsb2NrcXVvdGU+DQo8YnIgc3R5bGU9ImZvbnQtZmFtaWx5 OiBIZWx2ZXRpY2E7IGZvbnQtc2l6ZTogMTJweDsgZm9udC1zdHlsZTogbm9ybWFsOyBmb250LXZh cmlhbnQ6IG5vcm1hbDsgZm9udC13ZWlnaHQ6IG5vcm1hbDsgbGV0dGVyLXNwYWNpbmc6IG5vcm1h bDsgbGluZS1oZWlnaHQ6IG5vcm1hbDsgb3JwaGFuczogYXV0bzsgdGV4dC1hbGlnbjogc3RhcnQ7 IHRleHQtaW5kZW50OiAwcHg7IHRleHQtdHJhbnNmb3JtOiBub25lOyB3aGl0ZS1zcGFjZTogbm9y bWFsOyB3aWRvd3M6IGF1dG87IHdvcmQtc3BhY2luZzogMHB4OyAtd2Via2l0LXRleHQtc3Ryb2tl LXdpZHRoOiAwcHg7IiBjbGFzcz0iIj4NCjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTogSGVsdmV0 aWNhOyBmb250LXNpemU6IDEycHg7IGZvbnQtc3R5bGU6IG5vcm1hbDsgZm9udC12YXJpYW50OiBu b3JtYWw7IGZvbnQtd2VpZ2h0OiBub3JtYWw7IGxldHRlci1zcGFjaW5nOiBub3JtYWw7IGxpbmUt aGVpZ2h0OiBub3JtYWw7IG9ycGhhbnM6IGF1dG87IHRleHQtYWxpZ246IHN0YXJ0OyB0ZXh0LWlu ZGVudDogMHB4OyB0ZXh0LXRyYW5zZm9ybTogbm9uZTsgd2hpdGUtc3BhY2U6IG5vcm1hbDsgd2lk b3dzOiBhdXRvOyB3b3JkLXNwYWNpbmc6IDBweDsgLXdlYmtpdC10ZXh0LXN0cm9rZS13aWR0aDog MHB4OyBmbG9hdDogbm9uZTsgZGlzcGxheTogaW5saW5lICFpbXBvcnRhbnQ7IiBjbGFzcz0iIj5J DQogZG9uJ3QgdGhpbmsgSm9uYXRoYW4ncyBjb25jZXJucyBvbmx5IGFwcGx5IHRvIHByb3hpZXMg dGhvdWdoLiBZb3U8L3NwYW4+PGJyIHN0eWxlPSJmb250LWZhbWlseTogSGVsdmV0aWNhOyBmb250 LXNpemU6IDEycHg7IGZvbnQtc3R5bGU6IG5vcm1hbDsgZm9udC12YXJpYW50OiBub3JtYWw7IGZv bnQtd2VpZ2h0OiBub3JtYWw7IGxldHRlci1zcGFjaW5nOiBub3JtYWw7IGxpbmUtaGVpZ2h0OiBu b3JtYWw7IG9ycGhhbnM6IGF1dG87IHRleHQtYWxpZ246IHN0YXJ0OyB0ZXh0LWluZGVudDogMHB4 OyB0ZXh0LXRyYW5zZm9ybTogbm9uZTsgd2hpdGUtc3BhY2U6IG5vcm1hbDsgd2lkb3dzOiBhdXRv OyB3b3JkLXNwYWNpbmc6IDBweDsgLXdlYmtpdC10ZXh0LXN0cm9rZS13aWR0aDogMHB4OyIgY2xh c3M9IiI+DQo8c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6IEhlbHZldGljYTsgZm9udC1zaXplOiAx MnB4OyBmb250LXN0eWxlOiBub3JtYWw7IGZvbnQtdmFyaWFudDogbm9ybWFsOyBmb250LXdlaWdo dDogbm9ybWFsOyBsZXR0ZXItc3BhY2luZzogbm9ybWFsOyBsaW5lLWhlaWdodDogbm9ybWFsOyBv cnBoYW5zOiBhdXRvOyB0ZXh0LWFsaWduOiBzdGFydDsgdGV4dC1pbmRlbnQ6IDBweDsgdGV4dC10 cmFuc2Zvcm06IG5vbmU7IHdoaXRlLXNwYWNlOiBub3JtYWw7IHdpZG93czogYXV0bzsgd29yZC1z cGFjaW5nOiAwcHg7IC13ZWJraXQtdGV4dC1zdHJva2Utd2lkdGg6IDBweDsgZmxvYXQ6IG5vbmU7 IGRpc3BsYXk6IGlubGluZSAhaW1wb3J0YW50OyIgY2xhc3M9IiI+Y2FuDQoganVzdCBhcyB3ZWxs IGhhdmUgYXBwcyBkZXZlbG9wZWQgZm9yIHNwZWNpZmljIG5ldHdvcmtzIGFuZCB0aGVyZTwvc3Bh bj48YnIgc3R5bGU9ImZvbnQtZmFtaWx5OiBIZWx2ZXRpY2E7IGZvbnQtc2l6ZTogMTJweDsgZm9u dC1zdHlsZTogbm9ybWFsOyBmb250LXZhcmlhbnQ6IG5vcm1hbDsgZm9udC13ZWlnaHQ6IG5vcm1h bDsgbGV0dGVyLXNwYWNpbmc6IG5vcm1hbDsgbGluZS1oZWlnaHQ6IG5vcm1hbDsgb3JwaGFuczog YXV0bzsgdGV4dC1hbGlnbjogc3RhcnQ7IHRleHQtaW5kZW50OiAwcHg7IHRleHQtdHJhbnNmb3Jt OiBub25lOyB3aGl0ZS1zcGFjZTogbm9ybWFsOyB3aWRvd3M6IGF1dG87IHdvcmQtc3BhY2luZzog MHB4OyAtd2Via2l0LXRleHQtc3Ryb2tlLXdpZHRoOiAwcHg7IiBjbGFzcz0iIj4NCjxzcGFuIHN0 eWxlPSJmb250LWZhbWlseTogSGVsdmV0aWNhOyBmb250LXNpemU6IDEycHg7IGZvbnQtc3R5bGU6 IG5vcm1hbDsgZm9udC12YXJpYW50OiBub3JtYWw7IGZvbnQtd2VpZ2h0OiBub3JtYWw7IGxldHRl ci1zcGFjaW5nOiBub3JtYWw7IGxpbmUtaGVpZ2h0OiBub3JtYWw7IG9ycGhhbnM6IGF1dG87IHRl eHQtYWxpZ246IHN0YXJ0OyB0ZXh0LWluZGVudDogMHB4OyB0ZXh0LXRyYW5zZm9ybTogbm9uZTsg d2hpdGUtc3BhY2U6IG5vcm1hbDsgd2lkb3dzOiBhdXRvOyB3b3JkLXNwYWNpbmc6IDBweDsgLXdl YmtpdC10ZXh0LXN0cm9rZS13aWR0aDogMHB4OyBmbG9hdDogbm9uZTsgZGlzcGxheTogaW5saW5l ICFpbXBvcnRhbnQ7IiBjbGFzcz0iIj5pcw0KIG5vIHJlYXNvbiB0byBwcmV2ZW50IHRob3NlIGZy b20gd29ya2luZy48L3NwYW4+PGJyIHN0eWxlPSJmb250LWZhbWlseTogSGVsdmV0aWNhOyBmb250 LXNpemU6IDEycHg7IGZvbnQtc3R5bGU6IG5vcm1hbDsgZm9udC12YXJpYW50OiBub3JtYWw7IGZv bnQtd2VpZ2h0OiBub3JtYWw7IGxldHRlci1zcGFjaW5nOiBub3JtYWw7IGxpbmUtaGVpZ2h0OiBu b3JtYWw7IG9ycGhhbnM6IGF1dG87IHRleHQtYWxpZ246IHN0YXJ0OyB0ZXh0LWluZGVudDogMHB4 OyB0ZXh0LXRyYW5zZm9ybTogbm9uZTsgd2hpdGUtc3BhY2U6IG5vcm1hbDsgd2lkb3dzOiBhdXRv OyB3b3JkLXNwYWNpbmc6IDBweDsgLXdlYmtpdC10ZXh0LXN0cm9rZS13aWR0aDogMHB4OyIgY2xh c3M9IiI+DQo8YnIgc3R5bGU9ImZvbnQtZmFtaWx5OiBIZWx2ZXRpY2E7IGZvbnQtc2l6ZTogMTJw eDsgZm9udC1zdHlsZTogbm9ybWFsOyBmb250LXZhcmlhbnQ6IG5vcm1hbDsgZm9udC13ZWlnaHQ6 IG5vcm1hbDsgbGV0dGVyLXNwYWNpbmc6IG5vcm1hbDsgbGluZS1oZWlnaHQ6IG5vcm1hbDsgb3Jw aGFuczogYXV0bzsgdGV4dC1hbGlnbjogc3RhcnQ7IHRleHQtaW5kZW50OiAwcHg7IHRleHQtdHJh bnNmb3JtOiBub25lOyB3aGl0ZS1zcGFjZTogbm9ybWFsOyB3aWRvd3M6IGF1dG87IHdvcmQtc3Bh Y2luZzogMHB4OyAtd2Via2l0LXRleHQtc3Ryb2tlLXdpZHRoOiAwcHg7IiBjbGFzcz0iIj4NCjxi bG9ja3F1b3RlIHR5cGU9ImNpdGUiIHN0eWxlPSJmb250LWZhbWlseTogSGVsdmV0aWNhOyBmb250 LXNpemU6IDEycHg7IGZvbnQtc3R5bGU6IG5vcm1hbDsgZm9udC12YXJpYW50OiBub3JtYWw7IGZv bnQtd2VpZ2h0OiBub3JtYWw7IGxldHRlci1zcGFjaW5nOiBub3JtYWw7IGxpbmUtaGVpZ2h0OiBu b3JtYWw7IG9ycGhhbnM6IGF1dG87IHRleHQtYWxpZ246IHN0YXJ0OyB0ZXh0LWluZGVudDogMHB4 OyB0ZXh0LXRyYW5zZm9ybTogbm9uZTsgd2hpdGUtc3BhY2U6IG5vcm1hbDsgd2lkb3dzOiBhdXRv OyB3b3JkLXNwYWNpbmc6IDBweDsgLXdlYmtpdC10ZXh0LXN0cm9rZS13aWR0aDogMHB4OyIgY2xh c3M9IiI+DQpBZ3JlZSB3aXRoIHlvdXIgZW51bWVyYXRpb24gb2YgY29uY2VybnMgYXMgd2VsbC4g QWxzbyAjNSwgdGhleSBjb25zdW1lPGJyIGNsYXNzPSIiPg0KYmFuZHdpZHRoIChhdCBsZWFzdCBm cm9tIGNsaWVudCB0byBUVVJOIHNlcnZlciksIHdoaWNoIGFmZmVjdHMgbWF4aW11bSBjaGVjazxi ciBjbGFzcz0iIj4NCnJhdGUgaW4gc29tZSBjYXNlcy48YnIgY2xhc3M9IiI+DQo8L2Jsb2NrcXVv dGU+DQo8YnIgc3R5bGU9ImZvbnQtZmFtaWx5OiBIZWx2ZXRpY2E7IGZvbnQtc2l6ZTogMTJweDsg Zm9udC1zdHlsZTogbm9ybWFsOyBmb250LXZhcmlhbnQ6IG5vcm1hbDsgZm9udC13ZWlnaHQ6IG5v cm1hbDsgbGV0dGVyLXNwYWNpbmc6IG5vcm1hbDsgbGluZS1oZWlnaHQ6IG5vcm1hbDsgb3JwaGFu czogYXV0bzsgdGV4dC1hbGlnbjogc3RhcnQ7IHRleHQtaW5kZW50OiAwcHg7IHRleHQtdHJhbnNm b3JtOiBub25lOyB3aGl0ZS1zcGFjZTogbm9ybWFsOyB3aWRvd3M6IGF1dG87IHdvcmQtc3BhY2lu ZzogMHB4OyAtd2Via2l0LXRleHQtc3Ryb2tlLXdpZHRoOiAwcHg7IiBjbGFzcz0iIj4NCjxzcGFu IHN0eWxlPSJmb250LWZhbWlseTogSGVsdmV0aWNhOyBmb250LXNpemU6IDEycHg7IGZvbnQtc3R5 bGU6IG5vcm1hbDsgZm9udC12YXJpYW50OiBub3JtYWw7IGZvbnQtd2VpZ2h0OiBub3JtYWw7IGxl dHRlci1zcGFjaW5nOiBub3JtYWw7IGxpbmUtaGVpZ2h0OiBub3JtYWw7IG9ycGhhbnM6IGF1dG87 IHRleHQtYWxpZ246IHN0YXJ0OyB0ZXh0LWluZGVudDogMHB4OyB0ZXh0LXRyYW5zZm9ybTogbm9u ZTsgd2hpdGUtc3BhY2U6IG5vcm1hbDsgd2lkb3dzOiBhdXRvOyB3b3JkLXNwYWNpbmc6IDBweDsg LXdlYmtpdC10ZXh0LXN0cm9rZS13aWR0aDogMHB4OyBmbG9hdDogbm9uZTsgZGlzcGxheTogaW5s aW5lICFpbXBvcnRhbnQ7IiBjbGFzcz0iIj5XaHkNCiBjYW4ndCB3ZSBhZGRyZXNzIHRoaXMgYnkg VFVSTiBzZXJ2ZXJzIHNpbXBseSByZWZ1c2luZyB0byBjcmVhdGU8L3NwYW4+PGJyIHN0eWxlPSJm b250LWZhbWlseTogSGVsdmV0aWNhOyBmb250LXNpemU6IDEycHg7IGZvbnQtc3R5bGU6IG5vcm1h bDsgZm9udC12YXJpYW50OiBub3JtYWw7IGZvbnQtd2VpZ2h0OiBub3JtYWw7IGxldHRlci1zcGFj aW5nOiBub3JtYWw7IGxpbmUtaGVpZ2h0OiBub3JtYWw7IG9ycGhhbnM6IGF1dG87IHRleHQtYWxp Z246IHN0YXJ0OyB0ZXh0LWluZGVudDogMHB4OyB0ZXh0LXRyYW5zZm9ybTogbm9uZTsgd2hpdGUt c3BhY2U6IG5vcm1hbDsgd2lkb3dzOiBhdXRvOyB3b3JkLXNwYWNpbmc6IDBweDsgLXdlYmtpdC10 ZXh0LXN0cm9rZS13aWR0aDogMHB4OyIgY2xhc3M9IiI+DQo8c3BhbiBzdHlsZT0iZm9udC1mYW1p bHk6IEhlbHZldGljYTsgZm9udC1zaXplOiAxMnB4OyBmb250LXN0eWxlOiBub3JtYWw7IGZvbnQt dmFyaWFudDogbm9ybWFsOyBmb250LXdlaWdodDogbm9ybWFsOyBsZXR0ZXItc3BhY2luZzogbm9y bWFsOyBsaW5lLWhlaWdodDogbm9ybWFsOyBvcnBoYW5zOiBhdXRvOyB0ZXh0LWFsaWduOiBzdGFy dDsgdGV4dC1pbmRlbnQ6IDBweDsgdGV4dC10cmFuc2Zvcm06IG5vbmU7IHdoaXRlLXNwYWNlOiBu b3JtYWw7IHdpZG93czogYXV0bzsgd29yZC1zcGFjaW5nOiAwcHg7IC13ZWJraXQtdGV4dC1zdHJv a2Utd2lkdGg6IDBweDsgZmxvYXQ6IG5vbmU7IGRpc3BsYXk6IGlubGluZSAhaW1wb3J0YW50OyIg Y2xhc3M9IiI+cGVybWlzc2lvbnMNCiBmb3IgY2FuZGlkYXRlcyB0aGV5IGtub3cgdGhleSB3b24n dCBiZSBhYmxlIHRvIHJlYWNoPzwvc3Bhbj48YnIgc3R5bGU9ImZvbnQtZmFtaWx5OiBIZWx2ZXRp Y2E7IGZvbnQtc2l6ZTogMTJweDsgZm9udC1zdHlsZTogbm9ybWFsOyBmb250LXZhcmlhbnQ6IG5v cm1hbDsgZm9udC13ZWlnaHQ6IG5vcm1hbDsgbGV0dGVyLXNwYWNpbmc6IG5vcm1hbDsgbGluZS1o ZWlnaHQ6IG5vcm1hbDsgb3JwaGFuczogYXV0bzsgdGV4dC1hbGlnbjogc3RhcnQ7IHRleHQtaW5k ZW50OiAwcHg7IHRleHQtdHJhbnNmb3JtOiBub25lOyB3aGl0ZS1zcGFjZTogbm9ybWFsOyB3aWRv d3M6IGF1dG87IHdvcmQtc3BhY2luZzogMHB4OyAtd2Via2l0LXRleHQtc3Ryb2tlLXdpZHRoOiAw cHg7IiBjbGFzcz0iIj4NCjxiciBzdHlsZT0iZm9udC1mYW1pbHk6IEhlbHZldGljYTsgZm9udC1z aXplOiAxMnB4OyBmb250LXN0eWxlOiBub3JtYWw7IGZvbnQtdmFyaWFudDogbm9ybWFsOyBmb250 LXdlaWdodDogbm9ybWFsOyBsZXR0ZXItc3BhY2luZzogbm9ybWFsOyBsaW5lLWhlaWdodDogbm9y bWFsOyBvcnBoYW5zOiBhdXRvOyB0ZXh0LWFsaWduOiBzdGFydDsgdGV4dC1pbmRlbnQ6IDBweDsg dGV4dC10cmFuc2Zvcm06IG5vbmU7IHdoaXRlLXNwYWNlOiBub3JtYWw7IHdpZG93czogYXV0bzsg d29yZC1zcGFjaW5nOiAwcHg7IC13ZWJraXQtdGV4dC1zdHJva2Utd2lkdGg6IDBweDsiIGNsYXNz PSIiPg0KPC9kaXY+DQo8L2Jsb2NrcXVvdGU+DQo8ZGl2PkhvdyBkbyB5b3UgcmVsaWFibHkgYW5k IHNpbXBseSBkbyB0aGF0IHdpdGhvdXQgYSBjb25uZWN0aXZpdHkgY2hlY2s/PC9kaXY+DQo8ZGl2 PjxiciBjbGFzcz0iIj4NCjwvZGl2Pg0KPGRpdj5JZiB0aGUgbWFpbiBjb25jZXJuIGlzIGluZm9y bWF0aW9uIGxlYWthZ2UsIGlzbuKAmXQgdGhhdCB1cCB0byB0aGUgY2xpZW50IHRvIGRlY2lkZSB3 aGF0IGl0IHdhbnQgdG8gcmV2ZWFsIHRvIHRoZSBUVVJOIHNlcnZlciBhbmQgdGhlIHJlbW90ZSBj bGllbnQ/PC9kaXY+DQo8ZGl2PjxiciBjbGFzcz0iIj4NCjwvZGl2Pg0KPGRpdj5HdWVzcyB3aGF0 IEkgYW0gc2F5aW5nIGlzIHRoYXQgSSB0aGluayBpdCBpcyBhIGdvb2QgdGhpbmcgdG8gaGF2ZSBh IOKAnHRoaWNr4oCdIGNsaWVudCBhbmQgcmVsYXRpdmVseSBzaW1wbGUgbmV0d29yayBjb21wb25l bnRzLjwvZGl2Pg0KPGRpdj48YnIgY2xhc3M9IiI+DQo8L2Rpdj4NCjxkaXY+Li0uPC9kaXY+DQo8 ZGl2PlDDpWwtRXJpayZuYnNwOzwvZGl2Pg0KPGRpdj48YnIgY2xhc3M9IiI+DQo8L2Rpdj4NCjxi ciBjbGFzcz0iIj4NCjxibG9ja3F1b3RlIHR5cGU9ImNpdGUiIGNsYXNzPSIiPg0KPGRpdiBjbGFz cz0iIj48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6IEhlbHZldGljYTsgZm9udC1zaXplOiAxMnB4 OyBmb250LXN0eWxlOiBub3JtYWw7IGZvbnQtdmFyaWFudDogbm9ybWFsOyBmb250LXdlaWdodDog bm9ybWFsOyBsZXR0ZXItc3BhY2luZzogbm9ybWFsOyBsaW5lLWhlaWdodDogbm9ybWFsOyBvcnBo YW5zOiBhdXRvOyB0ZXh0LWFsaWduOiBzdGFydDsgdGV4dC1pbmRlbnQ6IDBweDsgdGV4dC10cmFu c2Zvcm06IG5vbmU7IHdoaXRlLXNwYWNlOiBub3JtYWw7IHdpZG93czogYXV0bzsgd29yZC1zcGFj aW5nOiAwcHg7IC13ZWJraXQtdGV4dC1zdHJva2Utd2lkdGg6IDBweDsgZmxvYXQ6IG5vbmU7IGRp c3BsYXk6IGlubGluZSAhaW1wb3J0YW50OyIgY2xhc3M9IiI+RW1pbDwvc3Bhbj48YnIgc3R5bGU9 ImZvbnQtZmFtaWx5OiBIZWx2ZXRpY2E7IGZvbnQtc2l6ZTogMTJweDsgZm9udC1zdHlsZTogbm9y bWFsOyBmb250LXZhcmlhbnQ6IG5vcm1hbDsgZm9udC13ZWlnaHQ6IG5vcm1hbDsgbGV0dGVyLXNw YWNpbmc6IG5vcm1hbDsgbGluZS1oZWlnaHQ6IG5vcm1hbDsgb3JwaGFuczogYXV0bzsgdGV4dC1h bGlnbjogc3RhcnQ7IHRleHQtaW5kZW50OiAwcHg7IHRleHQtdHJhbnNmb3JtOiBub25lOyB3aGl0 ZS1zcGFjZTogbm9ybWFsOyB3aWRvd3M6IGF1dG87IHdvcmQtc3BhY2luZzogMHB4OyAtd2Via2l0 LXRleHQtc3Ryb2tlLXdpZHRoOiAwcHg7IiBjbGFzcz0iIj4NCjxiciBzdHlsZT0iZm9udC1mYW1p bHk6IEhlbHZldGljYTsgZm9udC1zaXplOiAxMnB4OyBmb250LXN0eWxlOiBub3JtYWw7IGZvbnQt dmFyaWFudDogbm9ybWFsOyBmb250LXdlaWdodDogbm9ybWFsOyBsZXR0ZXItc3BhY2luZzogbm9y bWFsOyBsaW5lLWhlaWdodDogbm9ybWFsOyBvcnBoYW5zOiBhdXRvOyB0ZXh0LWFsaWduOiBzdGFy dDsgdGV4dC1pbmRlbnQ6IDBweDsgdGV4dC10cmFuc2Zvcm06IG5vbmU7IHdoaXRlLXNwYWNlOiBu b3JtYWw7IHdpZG93czogYXV0bzsgd29yZC1zcGFjaW5nOiAwcHg7IC13ZWJraXQtdGV4dC1zdHJv a2Utd2lkdGg6IDBweDsiIGNsYXNzPSIiPg0KPHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiBIZWx2 ZXRpY2E7IGZvbnQtc2l6ZTogMTJweDsgZm9udC1zdHlsZTogbm9ybWFsOyBmb250LXZhcmlhbnQ6 IG5vcm1hbDsgZm9udC13ZWlnaHQ6IG5vcm1hbDsgbGV0dGVyLXNwYWNpbmc6IG5vcm1hbDsgbGlu ZS1oZWlnaHQ6IG5vcm1hbDsgb3JwaGFuczogYXV0bzsgdGV4dC1hbGlnbjogc3RhcnQ7IHRleHQt aW5kZW50OiAwcHg7IHRleHQtdHJhbnNmb3JtOiBub25lOyB3aGl0ZS1zcGFjZTogbm9ybWFsOyB3 aWRvd3M6IGF1dG87IHdvcmQtc3BhY2luZzogMHB4OyAtd2Via2l0LXRleHQtc3Ryb2tlLXdpZHRo OiAwcHg7IGZsb2F0OiBub25lOyBkaXNwbGF5OiBpbmxpbmUgIWltcG9ydGFudDsiIGNsYXNzPSIi Pi0tPHNwYW4gY2xhc3M9IkFwcGxlLWNvbnZlcnRlZC1zcGFjZSI+Jm5ic3A7PC9zcGFuPjwvc3Bh bj48YnIgc3R5bGU9ImZvbnQtZmFtaWx5OiBIZWx2ZXRpY2E7IGZvbnQtc2l6ZTogMTJweDsgZm9u dC1zdHlsZTogbm9ybWFsOyBmb250LXZhcmlhbnQ6IG5vcm1hbDsgZm9udC13ZWlnaHQ6IG5vcm1h bDsgbGV0dGVyLXNwYWNpbmc6IG5vcm1hbDsgbGluZS1oZWlnaHQ6IG5vcm1hbDsgb3JwaGFuczog YXV0bzsgdGV4dC1hbGlnbjogc3RhcnQ7IHRleHQtaW5kZW50OiAwcHg7IHRleHQtdHJhbnNmb3Jt OiBub25lOyB3aGl0ZS1zcGFjZTogbm9ybWFsOyB3aWRvd3M6IGF1dG87IHdvcmQtc3BhY2luZzog MHB4OyAtd2Via2l0LXRleHQtc3Ryb2tlLXdpZHRoOiAwcHg7IiBjbGFzcz0iIj4NCjxhIGhyZWY9 Imh0dHBzOi8vaml0c2kub3JnLyIgc3R5bGU9ImZvbnQtZmFtaWx5OiBIZWx2ZXRpY2E7IGZvbnQt c2l6ZTogMTJweDsgZm9udC1zdHlsZTogbm9ybWFsOyBmb250LXZhcmlhbnQ6IG5vcm1hbDsgZm9u dC13ZWlnaHQ6IG5vcm1hbDsgbGV0dGVyLXNwYWNpbmc6IG5vcm1hbDsgbGluZS1oZWlnaHQ6IG5v cm1hbDsgb3JwaGFuczogYXV0bzsgdGV4dC1hbGlnbjogc3RhcnQ7IHRleHQtaW5kZW50OiAwcHg7 IHRleHQtdHJhbnNmb3JtOiBub25lOyB3aGl0ZS1zcGFjZTogbm9ybWFsOyB3aWRvd3M6IGF1dG87 IHdvcmQtc3BhY2luZzogMHB4OyAtd2Via2l0LXRleHQtc3Ryb2tlLXdpZHRoOiAwcHg7IiBjbGFz cz0iIj5odHRwczovL2ppdHNpLm9yZzwvYT48YnIgc3R5bGU9ImZvbnQtZmFtaWx5OiBIZWx2ZXRp Y2E7IGZvbnQtc2l6ZTogMTJweDsgZm9udC1zdHlsZTogbm9ybWFsOyBmb250LXZhcmlhbnQ6IG5v cm1hbDsgZm9udC13ZWlnaHQ6IG5vcm1hbDsgbGV0dGVyLXNwYWNpbmc6IG5vcm1hbDsgbGluZS1o ZWlnaHQ6IG5vcm1hbDsgb3JwaGFuczogYXV0bzsgdGV4dC1hbGlnbjogc3RhcnQ7IHRleHQtaW5k ZW50OiAwcHg7IHRleHQtdHJhbnNmb3JtOiBub25lOyB3aGl0ZS1zcGFjZTogbm9ybWFsOyB3aWRv d3M6IGF1dG87IHdvcmQtc3BhY2luZzogMHB4OyAtd2Via2l0LXRleHQtc3Ryb2tlLXdpZHRoOiAw cHg7IiBjbGFzcz0iIj4NCjxiciBzdHlsZT0iZm9udC1mYW1pbHk6IEhlbHZldGljYTsgZm9udC1z aXplOiAxMnB4OyBmb250LXN0eWxlOiBub3JtYWw7IGZvbnQtdmFyaWFudDogbm9ybWFsOyBmb250 LXdlaWdodDogbm9ybWFsOyBsZXR0ZXItc3BhY2luZzogbm9ybWFsOyBsaW5lLWhlaWdodDogbm9y bWFsOyBvcnBoYW5zOiBhdXRvOyB0ZXh0LWFsaWduOiBzdGFydDsgdGV4dC1pbmRlbnQ6IDBweDsg dGV4dC10cmFuc2Zvcm06IG5vbmU7IHdoaXRlLXNwYWNlOiBub3JtYWw7IHdpZG93czogYXV0bzsg d29yZC1zcGFjaW5nOiAwcHg7IC13ZWJraXQtdGV4dC1zdHJva2Utd2lkdGg6IDBweDsiIGNsYXNz PSIiPg0KPHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiBIZWx2ZXRpY2E7IGZvbnQtc2l6ZTogMTJw eDsgZm9udC1zdHlsZTogbm9ybWFsOyBmb250LXZhcmlhbnQ6IG5vcm1hbDsgZm9udC13ZWlnaHQ6 IG5vcm1hbDsgbGV0dGVyLXNwYWNpbmc6IG5vcm1hbDsgbGluZS1oZWlnaHQ6IG5vcm1hbDsgb3Jw aGFuczogYXV0bzsgdGV4dC1hbGlnbjogc3RhcnQ7IHRleHQtaW5kZW50OiAwcHg7IHRleHQtdHJh bnNmb3JtOiBub25lOyB3aGl0ZS1zcGFjZTogbm9ybWFsOyB3aWRvd3M6IGF1dG87IHdvcmQtc3Bh Y2luZzogMHB4OyAtd2Via2l0LXRleHQtc3Ryb2tlLXdpZHRoOiAwcHg7IGZsb2F0OiBub25lOyBk aXNwbGF5OiBpbmxpbmUgIWltcG9ydGFudDsiIGNsYXNzPSIiPl9fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fPC9zcGFuPjxiciBzdHlsZT0iZm9udC1mYW1pbHk6 IEhlbHZldGljYTsgZm9udC1zaXplOiAxMnB4OyBmb250LXN0eWxlOiBub3JtYWw7IGZvbnQtdmFy aWFudDogbm9ybWFsOyBmb250LXdlaWdodDogbm9ybWFsOyBsZXR0ZXItc3BhY2luZzogbm9ybWFs OyBsaW5lLWhlaWdodDogbm9ybWFsOyBvcnBoYW5zOiBhdXRvOyB0ZXh0LWFsaWduOiBzdGFydDsg dGV4dC1pbmRlbnQ6IDBweDsgdGV4dC10cmFuc2Zvcm06IG5vbmU7IHdoaXRlLXNwYWNlOiBub3Jt YWw7IHdpZG93czogYXV0bzsgd29yZC1zcGFjaW5nOiAwcHg7IC13ZWJraXQtdGV4dC1zdHJva2Ut d2lkdGg6IDBweDsiIGNsYXNzPSIiPg0KPHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiBIZWx2ZXRp Y2E7IGZvbnQtc2l6ZTogMTJweDsgZm9udC1zdHlsZTogbm9ybWFsOyBmb250LXZhcmlhbnQ6IG5v cm1hbDsgZm9udC13ZWlnaHQ6IG5vcm1hbDsgbGV0dGVyLXNwYWNpbmc6IG5vcm1hbDsgbGluZS1o ZWlnaHQ6IG5vcm1hbDsgb3JwaGFuczogYXV0bzsgdGV4dC1hbGlnbjogc3RhcnQ7IHRleHQtaW5k ZW50OiAwcHg7IHRleHQtdHJhbnNmb3JtOiBub25lOyB3aGl0ZS1zcGFjZTogbm9ybWFsOyB3aWRv d3M6IGF1dG87IHdvcmQtc3BhY2luZzogMHB4OyAtd2Via2l0LXRleHQtc3Ryb2tlLXdpZHRoOiAw cHg7IGZsb2F0OiBub25lOyBkaXNwbGF5OiBpbmxpbmUgIWltcG9ydGFudDsiIGNsYXNzPSIiPnJ0 Y3dlYg0KIG1haWxpbmcgbGlzdDwvc3Bhbj48YnIgc3R5bGU9ImZvbnQtZmFtaWx5OiBIZWx2ZXRp Y2E7IGZvbnQtc2l6ZTogMTJweDsgZm9udC1zdHlsZTogbm9ybWFsOyBmb250LXZhcmlhbnQ6IG5v cm1hbDsgZm9udC13ZWlnaHQ6IG5vcm1hbDsgbGV0dGVyLXNwYWNpbmc6IG5vcm1hbDsgbGluZS1o ZWlnaHQ6IG5vcm1hbDsgb3JwaGFuczogYXV0bzsgdGV4dC1hbGlnbjogc3RhcnQ7IHRleHQtaW5k ZW50OiAwcHg7IHRleHQtdHJhbnNmb3JtOiBub25lOyB3aGl0ZS1zcGFjZTogbm9ybWFsOyB3aWRv d3M6IGF1dG87IHdvcmQtc3BhY2luZzogMHB4OyAtd2Via2l0LXRleHQtc3Ryb2tlLXdpZHRoOiAw cHg7IiBjbGFzcz0iIj4NCjxhIGhyZWY9Im1haWx0bzpydGN3ZWJAaWV0Zi5vcmciIHN0eWxlPSJm b250LWZhbWlseTogSGVsdmV0aWNhOyBmb250LXNpemU6IDEycHg7IGZvbnQtc3R5bGU6IG5vcm1h bDsgZm9udC12YXJpYW50OiBub3JtYWw7IGZvbnQtd2VpZ2h0OiBub3JtYWw7IGxldHRlci1zcGFj aW5nOiBub3JtYWw7IGxpbmUtaGVpZ2h0OiBub3JtYWw7IG9ycGhhbnM6IGF1dG87IHRleHQtYWxp Z246IHN0YXJ0OyB0ZXh0LWluZGVudDogMHB4OyB0ZXh0LXRyYW5zZm9ybTogbm9uZTsgd2hpdGUt c3BhY2U6IG5vcm1hbDsgd2lkb3dzOiBhdXRvOyB3b3JkLXNwYWNpbmc6IDBweDsgLXdlYmtpdC10 ZXh0LXN0cm9rZS13aWR0aDogMHB4OyIgY2xhc3M9IiI+cnRjd2ViQGlldGYub3JnPC9hPjxiciBz dHlsZT0iZm9udC1mYW1pbHk6IEhlbHZldGljYTsgZm9udC1zaXplOiAxMnB4OyBmb250LXN0eWxl OiBub3JtYWw7IGZvbnQtdmFyaWFudDogbm9ybWFsOyBmb250LXdlaWdodDogbm9ybWFsOyBsZXR0 ZXItc3BhY2luZzogbm9ybWFsOyBsaW5lLWhlaWdodDogbm9ybWFsOyBvcnBoYW5zOiBhdXRvOyB0 ZXh0LWFsaWduOiBzdGFydDsgdGV4dC1pbmRlbnQ6IDBweDsgdGV4dC10cmFuc2Zvcm06IG5vbmU7 IHdoaXRlLXNwYWNlOiBub3JtYWw7IHdpZG93czogYXV0bzsgd29yZC1zcGFjaW5nOiAwcHg7IC13 ZWJraXQtdGV4dC1zdHJva2Utd2lkdGg6IDBweDsiIGNsYXNzPSIiPg0KPGEgaHJlZj0iaHR0cHM6 Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9ydGN3ZWIiIHN0eWxlPSJmb250LWZhbWls eTogSGVsdmV0aWNhOyBmb250LXNpemU6IDEycHg7IGZvbnQtc3R5bGU6IG5vcm1hbDsgZm9udC12 YXJpYW50OiBub3JtYWw7IGZvbnQtd2VpZ2h0OiBub3JtYWw7IGxldHRlci1zcGFjaW5nOiBub3Jt YWw7IGxpbmUtaGVpZ2h0OiBub3JtYWw7IG9ycGhhbnM6IGF1dG87IHRleHQtYWxpZ246IHN0YXJ0 OyB0ZXh0LWluZGVudDogMHB4OyB0ZXh0LXRyYW5zZm9ybTogbm9uZTsgd2hpdGUtc3BhY2U6IG5v cm1hbDsgd2lkb3dzOiBhdXRvOyB3b3JkLXNwYWNpbmc6IDBweDsgLXdlYmtpdC10ZXh0LXN0cm9r ZS13aWR0aDogMHB4OyIgY2xhc3M9IiI+aHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0 aW5mby9ydGN3ZWI8L2E+PC9kaXY+DQo8L2Jsb2NrcXVvdGU+DQo8L2Rpdj4NCjxiciBjbGFzcz0i Ij4NCjwvYm9keT4NCjwvaHRtbD4NCg== --_000_3F10035A70A446AEAB444499541AC7C6ciscocom_-- From nobody Fri Aug 7 07:48:15 2015 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 833281A877F; Fri, 7 Aug 2015 07:48:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wuFhvqCC_z-F; Fri, 7 Aug 2015 07:48:11 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 4F3BC1A0545; Fri, 7 Aug 2015 07:48:11 -0700 (PDT) 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.4.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20150807144811.21691.26832.idtracker@ietfa.amsl.com> Date: Fri, 07 Aug 2015 07:48:11 -0700 Archived-At: Cc: rtcweb@ietf.org Subject: [rtcweb] I-D Action: draft-ietf-rtcweb-audio-codecs-for-interop-02.txt X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 07 Aug 2015 14:48:12 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Real-Time Communication in WEB-browsers Working Group of the IETF. Title : Additional WebRTC audio codecs for interoperability. Authors : Stephane Proust Espen Berger Bernhard Feiten Bo Burman Kalyani Bogineni Miao Lei Enrico Marocco Filename : draft-ietf-rtcweb-audio-codecs-for-interop-02.txt Pages : 10 Date : 2015-08-07 Abstract: To ensure a baseline level of interoperability between WebRTC clients, [I-D.ietf-rtcweb-audio] requires a minimum set of codecs. However, to maximize the possibility to establish the session without the need for audio transcoding, it is also recommended to include in the offer other suitable audio codecs that are available to the browser. This document provides some guidelines on the suitable codecs to be considered for WebRTC clients to address the most relevant interoperability use cases. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-rtcweb-audio-codecs-for-interop/ There's also a htmlized version available at: https://tools.ietf.org/html/draft-ietf-rtcweb-audio-codecs-for-interop-02 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-rtcweb-audio-codecs-for-interop-02 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 Aug 7 07:57:29 2015 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2218F1B2ADD for ; Fri, 7 Aug 2015 07:57:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, UNPARSEABLE_RELAY=0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YS_QB0-6G5hB for ; Fri, 7 Aug 2015 07:57:26 -0700 (PDT) Received: from relais-inet.francetelecom.com (relais-ias91.francetelecom.com [193.251.215.91]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1264B1B2A1A for ; Fri, 7 Aug 2015 07:57:26 -0700 (PDT) Received: from omfedm07.si.francetelecom.fr (unknown [xx.xx.xx.3]) by omfedm14.si.francetelecom.fr (ESMTP service) with ESMTP id 57A0122CADB for ; Fri, 7 Aug 2015 16:57:24 +0200 (CEST) Received: from Exchangemail-eme2.itn.ftgroup (unknown [10.114.31.31]) by omfedm07.si.francetelecom.fr (ESMTP service) with ESMTP id 3D4514C05D for ; Fri, 7 Aug 2015 16:57:24 +0200 (CEST) Received: from OPEXCLILM44.corporate.adroot.infra.ftgroup ([fe80::b08d:5b75:e92c:a45f]) by OPEXCLILM22.corporate.adroot.infra.ftgroup ([fe80::8c90:f4e9:be28:2a1%19]) with mapi id 14.03.0248.002; Fri, 7 Aug 2015 16:57:24 +0200 From: To: "rtcweb@ietf.org" Thread-Topic: [rtcweb] I-D Action: draft-ietf-rtcweb-audio-codecs-for-interop-02.txt Thread-Index: AQHQ0SAsJrCxwjjtA021hNrtCPzQ0J4AnusA Date: Fri, 7 Aug 2015 14:57:23 +0000 Message-ID: <11066_1438959444_55C4C754_11066_418_1_2842AD9A45C83B44B57635FD4831E60A0CCB9471@OPEXCLILM44.corporate.adroot.infra.ftgroup> References: <20150807144811.21691.26832.idtracker@ietfa.amsl.com> In-Reply-To: <20150807144811.21691.26832.idtracker@ietfa.amsl.com> Accept-Language: fr-FR, en-US Content-Language: fr-FR X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.168.234.5] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-PMX-Version: 6.2.1.2478543, Antispam-Engine: 2.7.2.2107409, Antispam-Data: 2015.7.16.85415 Archived-At: Subject: Re: [rtcweb] I-D Action: draft-ietf-rtcweb-audio-codecs-for-interop-02.txt X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 07 Aug 2015 14:57:28 -0000 Dear all, This revision is to replace -01 that has expired with very minor clean up a= nd edits to update some references and some informative codec deployment fi= gures (that dated from 2013) St=E9phane=20 -----Message d'origine----- De=A0: rtcweb [mailto:rtcweb-bounces@ietf.org] De la part de internet-draft= s@ietf.org Envoy=E9=A0: vendredi 7 ao=FBt 2015 16:48 =C0=A0: i-d-announce@ietf.org Cc=A0: rtcweb@ietf.org Objet=A0: [rtcweb] I-D Action: draft-ietf-rtcweb-audio-codecs-for-interop-0= 2.txt A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the Real-Time Communication in WEB-browsers W= orking Group of the IETF. Title : Additional WebRTC audio codecs for interoperabili= ty. Authors : Stephane Proust Espen Berger Bernhard Feiten Bo Burman Kalyani Bogineni Miao Lei Enrico Marocco Filename : draft-ietf-rtcweb-audio-codecs-for-interop-02.txt Pages : 10 Date : 2015-08-07 Abstract: To ensure a baseline level of interoperability between WebRTC clients, [I-D.ietf-rtcweb-audio] requires a minimum set of codecs. However, to maximize the possibility to establish the session without the need for audio transcoding, it is also recommended to include in the offer other suitable audio codecs that are available to the browser. This document provides some guidelines on the suitable codecs to be considered for WebRTC clients to address the most relevant interoperability use cases. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-rtcweb-audio-codecs-for-interop/ There's also a htmlized version available at: https://tools.ietf.org/html/draft-ietf-rtcweb-audio-codecs-for-interop-02 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-rtcweb-audio-codecs-for-inte= rop-02 Please note that it may take a couple of minutes from the time of submissio= n until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ _______________________________________________ rtcweb mailing list rtcweb@ietf.org https://www.ietf.org/mailman/listinfo/rtcweb ___________________________________________________________________________= ______________________________________________ Ce message et ses pieces jointes peuvent contenir des informations confiden= tielles ou privilegiees et ne doivent donc pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu= ce message par erreur, veuillez le signaler a l'expediteur et le detruire ainsi que les pieces jointes. Les messages el= ectroniques etant susceptibles d'alteration, Orange decline toute responsabilite si ce message a ete altere, deforme ou = falsifie. Merci. This message and its attachments may contain confidential or privileged inf= ormation that may be protected by law; they should not be distributed, used or copied without authorisation. If you have received this email in error, please notify the sender and dele= te this message and its attachments. As emails may be altered, Orange is not liable for messages that have been = modified, changed or falsified. Thank you. From nobody Fri Aug 7 13:07:00 2015 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 508581A1BDA for ; Fri, 7 Aug 2015 13:06:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.791 X-Spam-Level: X-Spam-Status: No, score=0.791 tagged_above=-999 required=5 tests=[BAYES_50=0.8, T_RP_MATCHES_RCVD=-0.01, WEIRD_PORT=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 VH3kbFfOAEX6 for ; Fri, 7 Aug 2015 13:06:57 -0700 (PDT) Received: from lo.psyced.org (lost.in.psyced.org [188.40.42.221]) (using TLSv1 with cipher ECDHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 347721A1BA3 for ; Fri, 7 Aug 2015 13:06:56 -0700 (PDT) Received: from lo.psyced.org (localhost [127.0.0.1]) by lo.psyced.org (8.14.3/8.14.3/Debian-9.4) with ESMTP id t77K77OS020470 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Fri, 7 Aug 2015 22:07:07 +0200 Received: (from lynx@localhost) by lo.psyced.org (8.14.3/8.14.3/Submit) id t77K77w4020469 for rtcweb@ietf.org; Fri, 7 Aug 2015 22:07:07 +0200 Date: Fri, 7 Aug 2015 22:07:07 +0200 From: carlo von lynX To: rtcweb@ietf.org Message-ID: <20150807200706.GA2091@lo.psyced.org> References: <20150805161344.GA19492@lo.psyced.org> <20150805164256.GB19492@lo.psyced.org> <55C250CE.3040309@nostrum.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: User-Agent: Mutt/1.5.20 (2009-06-14) Archived-At: Subject: Re: [rtcweb] LAST CALL: Systematically de-anonymize dissidents with WebRTC (HOWTO) X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 07 Aug 2015 20:06:59 -0000 On Wed, Aug 05, 2015 at 04:42:50PM -0700, Ted Hardie wrote: > ​No one is dismissing the issue, and both Chrome and Firefox have worked on I can point you to several mails that did just that. > code to provide short-term solution​s (see this work > The problem are users of popular browsers that by default suddenly started leaking real IP numbers even when combined with VPN. The fact that these folks now need to install some extra add-ons is both an educational nightmare as a way to single them out. > Justin pointed out to the list and Maire Reavy's post > .) Same problem. As long as the default is to let external providers have the real IP, any website can be used to uncover dissidents. Maybe people doing this kind of work should first discuss with us what they intend to do so that we can tell them what works and what is pointless. > The group is actively discussing this topic and how to manage this going > forward. A number of technical challenges have been pointed out (both in > VPN configuration and the availability of information on network type to > the browsers). Continuing to point out the severity of the problem in > threads trying to resolve the problem is not helping progress; code, text, > or data would. What the people need to survive is a big fat pop-up prompt asking them whether they want to share their real IP with the website asking for it. It's really not complicated. So I still don't see why I am not granted the right to be angry. -- E-mail is public! Talk to me in private using encryption: http://loupsycedyglgamf.onion/LynX/ irc://loupsycedyglgamf.onion:67/lynX https://psyced.org:34443/LynX/ From nobody Fri Aug 7 13:54:52 2015 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2E4191A0390 for ; Fri, 7 Aug 2015 13:54:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.59 X-Spam-Level: X-Spam-Status: No, score=0.59 tagged_above=-999 required=5 tests=[BAYES_40=-0.001, J_CHICKENPOX_31=0.6, T_RP_MATCHES_RCVD=-0.01, WEIRD_PORT=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 Eqi6pdshx1t8 for ; Fri, 7 Aug 2015 13:54:49 -0700 (PDT) Received: from lo.psyced.org (lost.in.psyced.org [188.40.42.221]) (using TLSv1 with cipher ECDHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 59F431A0382 for ; Fri, 7 Aug 2015 13:54:49 -0700 (PDT) Received: from lo.psyced.org (localhost [127.0.0.1]) by lo.psyced.org (8.14.3/8.14.3/Debian-9.4) with ESMTP id t77KsxTV022585 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Fri, 7 Aug 2015 22:55:00 +0200 Received: (from lynx@localhost) by lo.psyced.org (8.14.3/8.14.3/Submit) id t77KsxeN022583 for rtcweb@ietf.org; Fri, 7 Aug 2015 22:54:59 +0200 Date: Fri, 7 Aug 2015 22:54:59 +0200 From: carlo von lynX To: rtcweb@ietf.org Message-ID: <20150807205458.GB2091@lo.psyced.org> References: <20150805161344.GA19492@lo.psyced.org> <20150805164256.GB19492@lo.psyced.org> <55C250CE.3040309@nostrum.com> <55C2AE77.6010603@matthew.at> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <55C2AE77.6010603@matthew.at> User-Agent: Mutt/1.5.20 (2009-06-14) Archived-At: Subject: Re: [rtcweb] LAST CALL: Systematically de-anonymize dissidents with WebRTC (HOWTO) X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 07 Aug 2015 20:54:51 -0000 On Wed, Aug 05, 2015 at 05:46:47PM -0700, Matthew Kaufman wrote: > Unless you have Flash Player 10.0 or later installed, in which case > RTMFP and a cooperating server does this. Which oppressive regimes did not know until you wrote it here. Excellent. Now we can only hope that most installations have already trashed the Flash plugin, otherwise we have yet another big problem. If it is correct that you are the author of the technically quite remarkable RTM*P protocol family, respect to you from a technical perspective but I must also thank you for having created a major problem and admitting it only in the process of dealing with another major problem. From my perspective you are making a very cynical impression if the risk of people getting jailed or killed leaves you this cold. > Or you have any number of other plugins (e.g., Java) installed which > can/will do this. Java of course has an API for this at https://docs.oracle.com/javase/tutorial/networking/nifs/index.html but https://docs.oracle.com/javase/tutorial/deployment/applet/security.html doesn't sound like those enumeration APIs are available to plain applets. We want facts, not allegations. > Or NYTimes.com or an advertiser on there (or the proxy the > oppressive country you live in transparently runs at the border) Man-in-the-middle attacks systematically on all international connections? We would have heard of that. I'm the author of Certificate Patrol and only rarely do I receive news of certs actually getting falsified. You must already be a target to experience that, and in that case it is easier for such governments to simply visit you at home. > injects any number of zero-day drive-by attacks, any of which would Can those countries afford to buy zero-day backdoors? And can they systematically detect dissidents this way? No they can't - because using zero-day backdoors in drive-by attacks on the entire population in order to be able to detect dissidents would enable some people to detect the operation, talk about it and report the zero-day so that it be fixed upstream. So what you describe here would be an effective way to waste an expensive zero-day without achieving anything of the intended goal. But thanks for starting to think about the scenario at all. > give full access to your machine, including the ability to reveal > the IP address (ref: http://www.zdnet.com/article/fbi-used-hacking-team-services-to-unmask-tor-user/ Please, Matthew. Read the articles you post before posting them. Of course authorities can find out the real IP *if they have* *already compromised the target's system*. So that is completely outside the scenario that I have brought up. The FBI merely asked an embarassangly incompetent question. > or https://blog.torproject.org/blog/tor-security-advisory-old-tor-browser-bundles-vulnerable). Again irrelevant since the people we are talking about in the scenario aren't using TBB. > They'd probably also do other evil things, but it'd start by > revealing your IP address. Nope, none of the methods you listed are as dangerous as WebRTC and... since a few days also Flash! > And that's if you simply limit to the browser case. In reality, > before WebRTC you probably had one or another P2P applications, > including possibly VoIP apps with P2P media capabilities, which are > also routinely exposing the full set of addresses you have. Sure, dissidents may even be using Skype while also having a VPN configured for their browser, but Skype does not expose the VPN IP if it isn't configured to use it, so the correlation fails. Why don't you think harder of the things you write? On 8/5/2015 3:54 PM, Daniel Roesler wrote: > >The threat model here is not a targeted attack looking to fingerprint > >a specific person. The threat model is that an oppressive regime can > >now find the exact IP address of censorship circumventing dissidents > >in their country by buying advertising on websites. This constitutes a > >real life-threatening scenario for many dissidents across the world. I > >completely understand why one would be quite mad at this working group > >for not acting when their life or friends'/family's lives are > >potentially on the line. Excellent, Daniel! I hadn't thought of the scenario that a government could simply buy advertising instead of having to lure people onto their own websites. That makes the scenario I described even worse. > This working group isn't empowered to "act when their life or > friends'/family's lives are potentially on the line". This is one of Eh well, I think there one or two RFCs out there that give some ethical guidelines to *all* working groups, and you shouldn't lightheartedly dismiss those. > *two* working groups producing standards. One might think that these > standards are being followed by the browser vendors, but in point of > fact the browser vendors are writing and releasing code ahead of the > publication of the standards, or in fact before full discussion has > taken place here or in the corresponding W3C working group. Yes, which is putting people's lives in danger. So please stop argueing and simply get them to put a pop-up warning in their that asks the users whether a website is allowed to bypass the regular networking routes. -- E-mail is public! Talk to me in private using encryption: http://loupsycedyglgamf.onion/LynX/ irc://loupsycedyglgamf.onion:67/lynX https://psyced.org:34443/LynX/ From nobody Fri Aug 7 14:23:18 2015 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 083BC1A1B9A for ; Fri, 7 Aug 2015 14:23:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xpkxwL0Vv1Ae for ; Fri, 7 Aug 2015 14:23:16 -0700 (PDT) Received: from mail-wi0-x233.google.com (mail-wi0-x233.google.com [IPv6:2a00:1450:400c:c05::233]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 37C841A1B73 for ; Fri, 7 Aug 2015 14:23:16 -0700 (PDT) Received: by wicne3 with SMTP id ne3so73978683wic.1 for ; Fri, 07 Aug 2015 14:23:15 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=t/EnEgwyqpf5WkYpnmWddniClpdSKrKJMqnXii4I12g=; b=IZiF9b3fuRWw4GJ2ofvRrdZ5qkLL/uRk0YgGUfdoTF1ZtTOL3JkST7gzDU7Xseh/gy pRM73H1WEv/B6NxMxFS2EKU4kh6EXsbzEu9RlNYiJsoZNi6z7Cgf37r3apTUCjQsPs3/ 6T++3aV929/i/OyS1WvQUwU6uZ65PbZcNAV7pCZ9Y6KTaS8+d33smCKz/qGuew7ix/LA p7Ja6rXunZEvOqOZuGsjIDYMCxBgDfujVxjDZsTB0DCl5xcHz5vAlNwHX+ZxV1cxKPuh z2/jRe+GtiEssjVcIIIRnenAb8fDu+/yK5Le8bTOIUWezVTgiWiCX28KImeuSwtgQix2 Ms1A== MIME-Version: 1.0 X-Received: by 10.194.122.97 with SMTP id lr1mr19018786wjb.26.1438982594947; Fri, 07 Aug 2015 14:23:14 -0700 (PDT) Received: by 10.194.17.68 with HTTP; Fri, 7 Aug 2015 14:23:14 -0700 (PDT) In-Reply-To: <20150807200706.GA2091@lo.psyced.org> References: <20150805161344.GA19492@lo.psyced.org> <20150805164256.GB19492@lo.psyced.org> <55C250CE.3040309@nostrum.com> <20150807200706.GA2091@lo.psyced.org> Date: Fri, 7 Aug 2015 14:23:14 -0700 Message-ID: From: Ted Hardie To: carlo von lynX Content-Type: multipart/alternative; boundary=089e01228c7068f0ac051cbf3e15 Archived-At: Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] LAST CALL: Systematically de-anonymize dissidents with WebRTC (HOWTO) X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 07 Aug 2015 21:23:18 -0000 --089e01228c7068f0ac051cbf3e15 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On Fri, Aug 7, 2015 at 1:07 PM, carlo von lynX < lynX@i.know.you.are.psyced.org> wrote: > > What the people need to survive is a big fat pop-up prompt asking > them whether they want to share their real IP with the website > asking for it. > =E2=80=8B This working group discusses the wire protocols for WebRTC. As noted above, folks are actively gathering data on what changes to those might help here and what the impact of each possibility is on the rest of the operation of the protocol machinery. If you wish in the mean time to discuss issues of warnings which might come from browser chrome, you are not talking to the right group. regards, Ted Hardie=E2=80=8B --089e01228c7068f0ac051cbf3e15 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On Fri, Aug 7, 2015 at 1:07 PM,= carlo von lynX <lynX@i.know.you.are.psyced.org> wrote:

What the people need to survive is a big fat pop-up prompt asking them whether they want to share their real IP with the website
asking for it.
=E2=80=8B
This working group discusses the wire protocols for WebRTC.=C2=A0 As noted= above, folks are actively gathering data on what changes to those might he= lp here and what the impact of each possibility is on the rest of the opera= tion of the protocol machinery.=C2=A0

If you wish in the mean time = to discuss issues of warnings which might come from browser chrome, you are= not talking to the right group.

regards,

Ted Hardie=E2=80=8B

--089e01228c7068f0ac051cbf3e15-- From nobody Fri Aug 7 14:39:48 2015 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AB7101A0119 for ; Fri, 7 Aug 2015 14:39:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.012 X-Spam-Level: X-Spam-Status: No, score=0.012 tagged_above=-999 required=5 tests=[BAYES_05=-0.5, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Nz_8l1OF9z9U for ; Fri, 7 Aug 2015 14:39:46 -0700 (PDT) Received: from mail-oi0-x234.google.com (mail-oi0-x234.google.com [IPv6:2607:f8b0:4003:c06::234]) (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 AF82B1A010C for ; Fri, 7 Aug 2015 14:39:46 -0700 (PDT) Received: by oip136 with SMTP id 136so60620471oip.1 for ; Fri, 07 Aug 2015 14:39:46 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:from:date:message-id:subject:to:content-type; bh=Tce2Eca8+AISDlHyO1s7E8MHXXapyj2OayOVY+1qPhA=; b=LDiEAW2jomc3iTbJOOgd5u+3rA96BKTHxBbtc9J/WRDM5cbIj2XjTzCXp6yhSfqKWV tBjErRfwSRo4oM5xTz+zKr53ruXrdinj24NRSJeL5cK7C9RmTbW0YRczXhCLWsGxuW0o Gmz/y2/9sm21yKcSpItHTb/ev+Mh0jTfPgVMd3hr6SSmVxEInHdjTTAVfteTDaWkWcXE aCe3TYYCuAenMJ4p1cjOvWH/CbAy4opnyzkI5BrjiQYvQ9z+ttUEeefuxkzBsYj8MyMw w99oPEmBWK2EImgkl+88J/U34RNDgnGZ7hJai0Se1/DzkB2Fi87SavPZ+cXohxMHMvIe HshA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:from:date:message-id:subject:to :content-type; bh=Tce2Eca8+AISDlHyO1s7E8MHXXapyj2OayOVY+1qPhA=; b=hD99ch+TtEH/F7s8P2nTyF2UK2VS79dEWzTAMcTFum/KykO/Xm9IsqDKvYzRrDxtpM SRC1cKzmJdMIb8Ivq7eCBsJN1xIqrdlaynfSnuyv87BLgT66YKTt62UAFO4qmf9ditYr uC9v2QPUEurBpAtr5vmEZIuXNW7GcQf7ekUoXCod3Yj2A7yYU9V4LGxc5Olv0pzJXbCU 7PvepWNqwEsLcUw15sE1FvgJ3vN3buNNB0AvsFrPNQ8SNmHdWFWFcK5jf4QvmAOI9s1X zb6xZ6Z8BLGeLHU37JncHcaxtrwsW4OUIyGaowvcgHgv2LmB00kCy2UEuntZRO+PMsLP 5BcQ== X-Gm-Message-State: ALoCoQnRB+28RNG+QfqQ/vqknfewnDq32996TI3P8n6j6gylfNIM16JMOERTjj7u1WPcuoMIJawo X-Received: by 10.202.15.11 with SMTP id 11mr8473142oip.127.1438983586082; Fri, 07 Aug 2015 14:39:46 -0700 (PDT) MIME-Version: 1.0 Received: by 10.76.62.110 with HTTP; Fri, 7 Aug 2015 14:39:06 -0700 (PDT) From: Peter Thatcher Date: Fri, 7 Aug 2015 14:39:06 -0700 Message-ID: To: "" Content-Type: multipart/alternative; boundary=001a113d1d387cb510051cbf79b6 Archived-At: Subject: [rtcweb] Do we have consensus on not requiring rtcp-non-mux? X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 07 Aug 2015 21:39:47 -0000 --001a113d1d387cb510051cbf79b6 Content-Type: text/plain; charset=UTF-8 After lots of discussion, it appears we have three options: 1. Endpoints MAY implement rtcp-non-mux (we change the spec and can delete the ugly code) 2. Endpoints MUST NOT implement rtcp-non-mux (we change the spec and must delete the ugly code, and our non-compliant until we do) 3. Endpoints MUST implement rtcp-non-mux (we don't change the spec and keep around the ugly code) My reading of the discussion is that most people want #1 or #2, and very few people still want #3. Between #1 and #2, while some people would prefer #2, there are good reasons to just do #1, and most seem to prefer #1. Further, I'm guessing that most people who wanted #2 could live with #1. TL;DR: I think we may have rough consensus on #1, saying endpoints MAY rtcp-non-mux (but may choose to delete all that ugly code instead). So, is everyone happy with #1? --001a113d1d387cb510051cbf79b6 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
After lots of discussion, it appears we have three opti= ons:

1.=C2=A0 Endpoints MAY implement rtcp-non-mux (we= change the spec and can delete the ugly code)

2.=C2= =A0 Endpoints MUST NOT implement rtcp-non-mux (we change the spec and must = delete the ugly code, and our non-compliant until we do)

=
3.=C2=A0 Endpoints MUST implement rtcp-non-mux (we don't change the = spec and keep around the ugly code)


My re= ading of the discussion is that most people want #1 or #2, and very few peo= ple still want #3. =C2=A0 Between #1 and #2, while some people would prefer= #2, there are good reasons to just do #1, and most seem to prefer #1.=C2= =A0 Further, I'm guessing that most people who wanted #2 could live wit= h #1.


TL;DR: =C2=A0I think we may have ro= ugh consensus on #1, saying endpoints MAY rtcp-non-mux (but may choose to d= elete all that ugly code instead). =C2=A0


So, is everyone happy with #1?



--001a113d1d387cb510051cbf79b6-- From nobody Fri Aug 7 15:25:41 2015 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B2AB21A1E0F for ; Fri, 7 Aug 2015 15:25:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6uHIj_SgR3bT for ; Fri, 7 Aug 2015 15:25:38 -0700 (PDT) Received: from mail-la0-x229.google.com (mail-la0-x229.google.com [IPv6:2a00:1450:4010:c03::229]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EC5201A8768 for ; Fri, 7 Aug 2015 15:19:01 -0700 (PDT) Received: by lagz9 with SMTP id z9so29361612lag.3 for ; Fri, 07 Aug 2015 15:19:00 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=NaOq0nwnW16uB+/LODIKa6NH0mKRjJ+Wxv+JED37r68=; b=zPl20QZZ8OHxETq3zu2t+wqNWszFXrvHcrZE9fqZK5S6npsIJNjM8EZQnJxH1+4T/0 B9MrZ6maqVfxupCMkZ339Gjw6yxtff7hDHJEd9NkDnzZML2M0u2KrDMviNLKxZ3EBTpa 6Lc8y5zmrOcnxACtTsKyikTMwX0OhZnQKc4pDoEi6XZZjzhnVI2A3UvQu/iJNvXv8Rxa f2iyJGjV7/eadHnzvurn7fHWHJI2Ussbw3XmBzidlaL0UTw0HrbGuWYqnJHfqUJG4fWm rvtsZpdBJJMTYFgom7UW8Erxoghxpv8DG+MvQswXeHM6u+lsqKVl/QKKn5g9xCwPLJih mEDg== MIME-Version: 1.0 X-Received: by 10.112.219.200 with SMTP id pq8mr10177067lbc.110.1438985940398; Fri, 07 Aug 2015 15:19:00 -0700 (PDT) Received: by 10.25.197.87 with HTTP; Fri, 7 Aug 2015 15:19:00 -0700 (PDT) In-Reply-To: References: Date: Fri, 7 Aug 2015 15:19:00 -0700 Message-ID: From: Martin Thomson To: Peter Thatcher Content-Type: text/plain; charset=UTF-8 Archived-At: Cc: "" Subject: Re: [rtcweb] Do we have consensus on not requiring rtcp-non-mux? X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 07 Aug 2015 22:25:39 -0000 Yes, #1. It might be bad to choose #2 and immediately invalidate every implementation that is currently compliant. On 7 August 2015 at 14:39, Peter Thatcher wrote: > After lots of discussion, it appears we have three options: > > 1. Endpoints MAY implement rtcp-non-mux (we change the spec and can delete > the ugly code) > > 2. Endpoints MUST NOT implement rtcp-non-mux (we change the spec and must > delete the ugly code, and our non-compliant until we do) > > 3. Endpoints MUST implement rtcp-non-mux (we don't change the spec and keep > around the ugly code) > > > My reading of the discussion is that most people want #1 or #2, and very few > people still want #3. Between #1 and #2, while some people would prefer > #2, there are good reasons to just do #1, and most seem to prefer #1. > Further, I'm guessing that most people who wanted #2 could live with #1. > > > TL;DR: I think we may have rough consensus on #1, saying endpoints MAY > rtcp-non-mux (but may choose to delete all that ugly code instead). > > > So, is everyone happy with #1? > > > > > _______________________________________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/listinfo/rtcweb > From nobody Fri Aug 7 15:27:47 2015 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EAE5B1A1BC0 for ; Fri, 7 Aug 2015 15:27:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.977 X-Spam-Level: X-Spam-Status: No, score=-1.977 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4k53CMmNqUNO for ; Fri, 7 Aug 2015 15:27:44 -0700 (PDT) Received: from mail-wi0-f180.google.com (mail-wi0-f180.google.com [209.85.212.180]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B02FB1A1B3D for ; Fri, 7 Aug 2015 15:26:52 -0700 (PDT) Received: by wicgj17 with SMTP id gj17so77064410wic.1 for ; Fri, 07 Aug 2015 15:26:51 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type; bh=H5x65gLMXF783oel792HTSXqowkDT5kAZ8Y9t2g9k1U=; b=U19mHHl2jfTJCD4Ya33KIN+x65JEleMvyH8wsiPi2F7V0rWDVGuoAtHX6z2N9B0r0l 1dK200nbj7Br+DTInp+hI/lITl460LHFYw2hiBY5qs6XaS4RvO1dATWgE0Jkw8oSbhRY +TPAd8qA4oghGfSIR0GGEhYqNpGHq+s+SwRnW8T+xIHa/lBoLCCKAXUI2TqMg7Ocbe7M PaH4KkUxcze8B69W+n3vozUH34hbvEEiOEvoj+FKGS9/L0GSTM4TGZl96D9eIMxGECc4 JFIw5zzr7B6T0/IGz4WRnTkD4Ib86LFm8JpnSat684S2OW7J1faKzj5Px5JYLs64N1uV ualw== X-Gm-Message-State: ALoCoQk+5qaOjFX4IVq2QYgwAuJ48Go9/JCmr1DGeySe6ziaJf1xsetAbbajETIO7GRW01HLfhPW X-Received: by 10.180.74.148 with SMTP id t20mr855874wiv.31.1438986411498; Fri, 07 Aug 2015 15:26:51 -0700 (PDT) MIME-Version: 1.0 Received: by 10.27.85.99 with HTTP; Fri, 7 Aug 2015 15:26:12 -0700 (PDT) In-Reply-To: References: From: Eric Rescorla Date: Fri, 7 Aug 2015 15:26:12 -0700 Message-ID: To: Martin Thomson Content-Type: multipart/alternative; boundary=f46d043c7f5ce4f454051cc0213a Archived-At: Cc: "" Subject: Re: [rtcweb] Do we have consensus on not requiring rtcp-non-mux? X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 07 Aug 2015 22:27:46 -0000 --f46d043c7f5ce4f454051cc0213a Content-Type: text/plain; charset=UTF-8 #1 is fine with me. -Ekr On Fri, Aug 7, 2015 at 3:19 PM, Martin Thomson wrote: > Yes, #1. It might be bad to choose #2 and immediately invalidate > every implementation that is currently compliant. > > On 7 August 2015 at 14:39, Peter Thatcher wrote: > > After lots of discussion, it appears we have three options: > > > > 1. Endpoints MAY implement rtcp-non-mux (we change the spec and can > delete > > the ugly code) > > > > 2. Endpoints MUST NOT implement rtcp-non-mux (we change the spec and > must > > delete the ugly code, and our non-compliant until we do) > > > > 3. Endpoints MUST implement rtcp-non-mux (we don't change the spec and > keep > > around the ugly code) > > > > > > My reading of the discussion is that most people want #1 or #2, and very > few > > people still want #3. Between #1 and #2, while some people would prefer > > #2, there are good reasons to just do #1, and most seem to prefer #1. > > Further, I'm guessing that most people who wanted #2 could live with #1. > > > > > > TL;DR: I think we may have rough consensus on #1, saying endpoints MAY > > rtcp-non-mux (but may choose to delete all that ugly code instead). > > > > > > So, is everyone happy with #1? > > > > > > > > > > _______________________________________________ > > rtcweb mailing list > > rtcweb@ietf.org > > https://www.ietf.org/mailman/listinfo/rtcweb > > > > _______________________________________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/listinfo/rtcweb > --f46d043c7f5ce4f454051cc0213a Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
#1 is fine with me.

-Ekr

=

On Fr= i, Aug 7, 2015 at 3:19 PM, Martin Thomson <martin.thomson@gmail.com= > wrote:
Yes, #1.=C2=A0 It = might be bad to choose #2 and immediately invalidate
every implementation that is currently compliant.

On 7 August 2015 at 14:39, Peter Thatcher <pthatcher@google.com> wrote:
> After lots of discussion, it appears we have three options:
>
> 1.=C2=A0 Endpoints MAY implement rtcp-non-mux (we change the spec and = can delete
> the ugly code)
>
> 2.=C2=A0 Endpoints MUST NOT implement rtcp-non-mux (we change the spec= and must
> delete the ugly code, and our non-compliant until we do)
>
> 3.=C2=A0 Endpoints MUST implement rtcp-non-mux (we don't change th= e spec and keep
> around the ugly code)
>
>
> My reading of the discussion is that most people want #1 or #2, and ve= ry few
> people still want #3.=C2=A0 =C2=A0Between #1 and #2, while some people= would prefer
> #2, there are good reasons to just do #1, and most seem to prefer #1.<= br> > Further, I'm guessing that most people who wanted #2 could live wi= th #1.
>
>
> TL;DR:=C2=A0 I think we may have rough consensus on #1, saying endpoin= ts MAY
> rtcp-non-mux (but may choose to delete all that ugly code instead). >
>
> So, is everyone happy with #1?
>
>
>
>
> _______________________________________________
> rtcweb mailing list
> rtcweb@ietf.org
> https://www.ietf.org/mailman/listinfo/rtcweb >

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

--f46d043c7f5ce4f454051cc0213a-- From nobody Fri Aug 7 15:29:56 2015 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8703B1A1BF5 for ; Fri, 7 Aug 2015 15:29:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, SPF_HELO_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ys_VtIj95ehY for ; Fri, 7 Aug 2015 15:29:52 -0700 (PDT) Received: from na01-bn1-obe.outbound.protection.outlook.com (mail-bn1on0668.outbound.protection.outlook.com [IPv6:2a01:111:f400:fc10::668]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5CCE31A1BD4 for ; Fri, 7 Aug 2015 15:29:52 -0700 (PDT) Received: from SN1PR0301MB1551.namprd03.prod.outlook.com (10.162.129.157) by SN1PR0301MB1551.namprd03.prod.outlook.com (10.162.129.157) with Microsoft SMTP Server (TLS) id 15.1.225.19; Fri, 7 Aug 2015 22:29:34 +0000 Received: from SN1PR0301MB1551.namprd03.prod.outlook.com ([10.162.129.157]) by SN1PR0301MB1551.namprd03.prod.outlook.com ([10.162.129.157]) with mapi id 15.01.0225.018; Fri, 7 Aug 2015 22:29:34 +0000 From: "Asveren, Tolga" To: Eric Rescorla , Martin Thomson Thread-Topic: [rtcweb] Do we have consensus on not requiring rtcp-non-mux? Thread-Index: AQHQ0WAG9sT639xdM0GLFaO8u8tbX54BHWEAgAAA5LM= Date: Fri, 7 Aug 2015 22:29:34 +0000 Message-ID: References: , In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=tasveren@sonusnet.com; x-originating-ip: [50.182.164.80] x-microsoft-exchange-diagnostics: 1; SN1PR0301MB1551; 5:AHS8qq3vwD6ptsELC79l25bBTnYRPCzWaDC4c1tiWLvUkujnwEvnrep4LhqKk5xQdlcxXxurRcuL7KzAJ5btQL7ftEXfMARQsamwvi9SLqE59iqARxWXJkJGLAyql96JGp00KBWVbEKfTNUPjRruYw==; 24:K+xNRSwdr+QoFDCrY/WJS8RLv3+G10/QczG7VA7L5cySg+uT+Kwx6EawqayVflQZAYQwNwUQZuHSQ37FuW+pCiRfdt4Zmlf59pAusZII4qw=; 20:ZOeR4mRJIMyU8Tf1t2VLzRlCn4H1BWARvr6KeE4o9qUSYgBt/KMIJ5ad7ZqY6fAXrsF3aFh69p42hEb95esncg== x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:SN1PR0301MB1551; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:; x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(601004)(5005006)(3002001); SRVR:SN1PR0301MB1551; BCL:0; PCL:0; RULEID:; SRVR:SN1PR0301MB1551; x-forefront-prvs: 066153096A x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(164054003)(24454002)(189002)(377454003)(199003)(54356999)(5001830100001)(76176999)(19580395003)(2656002)(10400500002)(50986999)(101416001)(92566002)(122556002)(66066001)(106356001)(5003600100002)(76576001)(99286002)(62966003)(105586002)(40100003)(19617315012)(64706001)(230783001)(77156002)(106116001)(16236675004)(19580405001)(77096005)(5001920100001)(2900100001)(2950100001)(86362001)(97736004)(33656002)(102836002)(68736005)(87936001)(19625215002)(5001770100001)(15975445007)(5001860100001)(5001960100002)(189998001)(19627405001)(81156007)(5002640100001)(46102003)(74316001)(4001540100001); DIR:OUT; SFP:1101; SCL:1; SRVR:SN1PR0301MB1551; H:SN1PR0301MB1551.namprd03.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; MX:1; A:1; LANG:en; received-spf: None (protection.outlook.com: sonusnet.com does not designate permitted sender hosts) Content-Type: multipart/alternative; boundary="_000_SN1PR0301MB1551848FA8812088CA575206B2730SN1PR0301MB1551_" MIME-Version: 1.0 X-OriginatorOrg: sonusnet.com X-MS-Exchange-CrossTenant-originalarrivaltime: 07 Aug 2015 22:29:34.5056 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 29a671dc-ed7e-4a54-b1e5-8da1eb495dc3 X-MS-Exchange-Transport-CrossTenantHeadersStamped: SN1PR0301MB1551 Archived-At: Cc: "" Subject: Re: [rtcweb] Do we have consensus on not requiring rtcp-non-mux? X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 07 Aug 2015 22:29:54 -0000 --_000_SN1PR0301MB1551848FA8812088CA575206B2730SN1PR0301MB1551_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable The same here. Thanks, Tolga ________________________________ From: rtcweb on behalf of Eric Rescorla Sent: Friday, August 7, 2015 6:26 PM To: Martin Thomson Cc: Subject: Re: [rtcweb] Do we have consensus on not requiring rtcp-non-mux? #1 is fine with me. -Ekr On Fri, Aug 7, 2015 at 3:19 PM, Martin Thomson > wrote: Yes, #1. It might be bad to choose #2 and immediately invalidate every implementation that is currently compliant. On 7 August 2015 at 14:39, Peter Thatcher > wrote: > After lots of discussion, it appears we have three options: > > 1. Endpoints MAY implement rtcp-non-mux (we change the spec and can dele= te > the ugly code) > > 2. Endpoints MUST NOT implement rtcp-non-mux (we change the spec and mus= t > delete the ugly code, and our non-compliant until we do) > > 3. Endpoints MUST implement rtcp-non-mux (we don't change the spec and k= eep > around the ugly code) > > > My reading of the discussion is that most people want #1 or #2, and very = few > people still want #3. Between #1 and #2, while some people would prefer > #2, there are good reasons to just do #1, and most seem to prefer #1. > Further, I'm guessing that most people who wanted #2 could live with #1. > > > TL;DR: I think we may have rough consensus on #1, saying endpoints MAY > rtcp-non-mux (but may choose to delete all that ugly code instead). > > > So, is everyone happy with #1? > > > > > _______________________________________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/listinfo/rtcweb > _______________________________________________ rtcweb mailing list rtcweb@ietf.org https://www.ietf.org/mailman/listinfo/rtcweb --_000_SN1PR0301MB1551848FA8812088CA575206B2730SN1PR0301MB1551_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

The same here.


Thanks,

Tolga



From: rtcweb <rtcweb-bou= nces@ietf.org> on behalf of Eric Rescorla <ekr@rtfm.com>
Sent: Friday, August 7, 2015 6:26 PM
To: Martin Thomson
Cc: <rtcweb@ietf.org>
Subject: Re: [rtcweb] Do we have consensus on not requiring rtcp-non= -mux?
 
#1 is fine with me.

-Ekr


On Fri, Aug 7, 2015 at 3:19 PM, Martin Thomson <= span dir=3D"ltr"> <martin.th= omson@gmail.com> wrote:
Yes, #1.  It might be bad to choose #2 and immediately invalidate
every implementation that is currently compliant.

On 7 August 2015 at 14:39, Peter Thatcher <pthatcher@google.com> wrote:
> After lots of discussion, it appears we have three options:
>
> 1.  Endpoints MAY implement rtcp-non-mux (we change the spec and = can delete
> the ugly code)
>
> 2.  Endpoints MUST NOT implement rtcp-non-mux (we change the spec= and must
> delete the ugly code, and our non-compliant until we do)
>
> 3.  Endpoints MUST implement rtcp-non-mux (we don't change the sp= ec and keep
> around the ugly code)
>
>
> My reading of the discussion is that most people want #1 or #2, and ve= ry few
> people still want #3.   Between #1 and #2, while some people= would prefer
> #2, there are good reasons to just do #1, and most seem to prefer #1.<= br> > Further, I'm guessing that most people who wanted #2 could live with #= 1.
>
>
> TL;DR:  I think we may have rough consensus on #1, saying endpoin= ts MAY
> rtcp-non-mux (but may choose to delete all that ugly code instead). >
>
> So, is everyone happy with #1?
>
>
>
>
> _______________________________________________
> rtcweb mailing list
> rtcweb@ietf.org
> https://www.ietf.org/mailman/listinfo/rtcweb
>

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

--_000_SN1PR0301MB1551848FA8812088CA575206B2730SN1PR0301MB1551_-- From nobody Fri Aug 7 15:37:28 2015 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 07FD11A871C for ; Fri, 7 Aug 2015 15:37:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qK935tgDFWHE for ; Fri, 7 Aug 2015 15:37:25 -0700 (PDT) Received: from mail.eeph.com (mail.eeph.com [IPv6:2001:470:826a:d2::3]) by ietfa.amsl.com (Postfix) with ESMTP id 597351A871A for ; Fri, 7 Aug 2015 15:37:25 -0700 (PDT) Received: from [IPv6:2001:470:826a:d0:d5fe:6e06:c62e:6418] (unknown [IPv6:2001:470:826a:d0:d5fe:6e06:c62e:6418]) (Authenticated sender: matthew@eeph.com) by mail.eeph.com (Postfix) with ESMTPSA id 2CB6D549260 for ; Fri, 7 Aug 2015 15:37:25 -0700 (PDT) Message-ID: <55C53328.6050308@matthew.at> Date: Fri, 07 Aug 2015 15:37:28 -0700 From: Matthew Kaufman User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.7.0 MIME-Version: 1.0 To: rtcweb@ietf.org References: <20150805161344.GA19492@lo.psyced.org> <20150805164256.GB19492@lo.psyced.org> <55C250CE.3040309@nostrum.com> <55C2AE77.6010603@matthew.at> <20150807205458.GB2091@lo.psyced.org> In-Reply-To: <20150807205458.GB2091@lo.psyced.org> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [rtcweb] LAST CALL: Systematically de-anonymize dissidents with WebRTC (HOWTO) X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 07 Aug 2015 22:37:27 -0000 On 8/7/2015 1:54 PM, carlo von lynX wrote: > Yes, which is putting people's lives in danger. So please stop > argueing and simply get them to put a pop-up warning in their that > asks the users whether a website is allowed to bypass the regular > networking routes. This IETF working group cannot "simply get them" to do *anything*. That's not how standards bodies work. Now, if you'd like to write a draft, or submit changes to the security considerations draft, that would be welcome. Matthew Kaufman From nobody Fri Aug 7 15:50:37 2015 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 362761A8781 for ; Fri, 7 Aug 2015 15:50:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.978 X-Spam-Level: X-Spam-Status: No, score=-1.978 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, 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 ouxqCYZjUwFd for ; Fri, 7 Aug 2015 15:50:35 -0700 (PDT) Received: from mail-qg0-f46.google.com (mail-qg0-f46.google.com [209.85.192.46]) (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 E1EBF1A877E for ; Fri, 7 Aug 2015 15:50:34 -0700 (PDT) Received: by qgeh16 with SMTP id h16so84680779qge.3 for ; Fri, 07 Aug 2015 15:50:34 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=R+XlRbUdLm1fPd+eLgfU8WumJejrgRg+7c+2bZYIgsI=; b=Tq/k1A6QMPlSEGK9RwdoPaz4IGiu6xpg7+Bi+xE0G3S3o3VsWdRQXIyCxkzJEOdhit Uwel0NeuH+YtLjOZ/pCVerY1dal2F/beyU7Or89JErdmz3MygogAHCmnbrCYwb9sQVz8 s8LuTRWqKTiIToAheoWiESUbF/tOrZU7BOGFI/jdxvXKzWFOu59E7usN4rwQg6FMBGgg t4035mUV1k94yt7u7b5+0UrsXcqrPIseUTsKwalbtNKqqVS/I5FV7jwmRfxGqYnrglSU 1dI1nROMadd3L77tgsxcBtr9L7WLad/wrpWE3ZI+DnNW8uGTQMgLnR5ER6vEs/7Y0+up tOkw== X-Gm-Message-State: ALoCoQltWdFbPhHFm8+Fn8bnPInvVVUOIoY0pAZZ1ZjUA50qVOM0cqATLZPPioaTtqTASJMd4Pun X-Received: by 10.140.196.8 with SMTP id r8mr18697145qha.25.1438987833953; Fri, 07 Aug 2015 15:50:33 -0700 (PDT) Received: from mail-qk0-f181.google.com (mail-qk0-f181.google.com. [209.85.220.181]) by smtp.gmail.com with ESMTPSA id s5sm5714377qgs.1.2015.08.07.15.50.32 for (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 07 Aug 2015 15:50:32 -0700 (PDT) Received: by qkdg63 with SMTP id g63so42075454qkd.0 for ; Fri, 07 Aug 2015 15:50:32 -0700 (PDT) MIME-Version: 1.0 X-Received: by 10.55.43.231 with SMTP id r100mr17835338qkr.54.1438987832381; Fri, 07 Aug 2015 15:50:32 -0700 (PDT) Received: by 10.96.165.71 with HTTP; Fri, 7 Aug 2015 15:50:32 -0700 (PDT) In-Reply-To: References: Date: Fri, 7 Aug 2015 18:50:32 -0400 Message-ID: From: Roman Shpount To: Peter Thatcher Content-Type: multipart/alternative; boundary=001a1149430095dbb3051cc0761c Archived-At: Cc: "" Subject: Re: [rtcweb] Do we have consensus on not requiring rtcp-non-mux? X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 07 Aug 2015 22:50:36 -0000 --001a1149430095dbb3051cc0761c Content-Type: text/plain; charset=UTF-8 I would vote for 1 with the caveat that implementations MUST accept rtcp-mux if offered. _____________ Roman Shpount --001a1149430095dbb3051cc0761c Content-Type: text/html; charset=UTF-8
I would vote for 1 with the caveat that implementations MUST accept rtcp-mux if offered.

_____________
Roman Shpount
--001a1149430095dbb3051cc0761c-- From nobody Fri Aug 7 16:09:13 2015 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 820AC1A87D1 for ; Fri, 7 Aug 2015 16:09:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id d28oDNSuHQAp for ; Fri, 7 Aug 2015 16:09:10 -0700 (PDT) Received: from mail-lb0-x236.google.com (mail-lb0-x236.google.com [IPv6:2a00:1450:4010:c04::236]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 50CD41A87A6 for ; Fri, 7 Aug 2015 16:09:10 -0700 (PDT) Received: by lbbtg9 with SMTP id tg9so30692453lbb.1 for ; Fri, 07 Aug 2015 16:09:08 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=IQ5dyX/MEMimEg+tSjFS/K0w5zK40ez7iJz0ODXvTlc=; b=rHJ0RhYl4vb47sPmBVtATsrWaD1A+NkVW78FG1qYZmqpYHDqDkgpqddMnAQdoHGFIO wMbbk+AXHxlB7NVaPgI7wmdFiQstzScsACifC3Qs56BGIjqUWUB+NdgENmX4HH47qAT2 H/CK0bo9XKI+aTW4frkuhLDZtSS1WV4AohZqnrvVDsIeLX20C/iCDdo9vpCCYPRRP+wP ssWx+b1NJVUnFJ4FL3sLkkAt7UApV/GeSlbrNFGTwfSErUbvMRlmY6lgmFhCKnceLwh0 kDMSsZSwAnIP8dGpDEpaNHWaDffyEq/LnQBHQZuMY7vpML/T6M9SPz6MVJMTwsILFuGN gvPw== MIME-Version: 1.0 X-Received: by 10.112.72.8 with SMTP id z8mr10334385lbu.24.1438988948682; Fri, 07 Aug 2015 16:09:08 -0700 (PDT) Received: by 10.25.197.87 with HTTP; Fri, 7 Aug 2015 16:09:08 -0700 (PDT) In-Reply-To: References: Date: Fri, 7 Aug 2015 16:09:08 -0700 Message-ID: From: Martin Thomson To: Roman Shpount Content-Type: text/plain; charset=UTF-8 Archived-At: Cc: "" Subject: Re: [rtcweb] Do we have consensus on not requiring rtcp-non-mux? X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 07 Aug 2015 23:09:12 -0000 On 7 August 2015 at 15:50, Roman Shpount wrote: > I would vote for 1 with the caveat that implementations MUST accept rtcp-mux > if offered. I'd be OK with an additional stipulation, though I'll note that we don't actually need more inventive to select rtcp-mux. From nobody Fri Aug 7 16:36:01 2015 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 88E171A8AE7 for ; Fri, 7 Aug 2015 16:35:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.978 X-Spam-Level: X-Spam-Status: No, score=-1.978 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, 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 lax-C1UrFpLC for ; Fri, 7 Aug 2015 16:35:57 -0700 (PDT) Received: from mail-io0-f174.google.com (mail-io0-f174.google.com [209.85.223.174]) (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 5B1CA1A8AE5 for ; Fri, 7 Aug 2015 16:35:57 -0700 (PDT) Received: by iodb91 with SMTP id b91so65784212iod.1 for ; Fri, 07 Aug 2015 16:35:56 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=xFM5yDMzm3aXd2yK+e8qmN1URg+soX8f6jAdl25aymY=; b=K7Z2PhH9rUnpYHelCvJS4bWubRIChnhxNwvvJE5624Glh0D1xEaBGgsbYCPd/rH1t/ MIzYl4BrJsAAQKmIS8BupYWiUTVrl8MXf8epS/HgQi/uRadKZYtEsmNIl23B8wCcAttd 7AtejwoJXGAFE42v4A/KDrQoyYKbr46MmLo3zko80N8l0vhfORCIHiQdpHf314J8rl2/ o6zp3DxaqIrK7JyjfhKYyuvAfovnsOhAxTG9qRyz0WlO1S4bcm8Qk7JWqTbbtM2+rVwV +6Rwd3hTPPWBfl8JNp2Narz4V7tm1AutSvVd83Lt5OLXh8CsygnNgxuYrtcD00h1XAWt VhHw== X-Gm-Message-State: ALoCoQm65FTYKH4fhqCMvxIenfM/W65neX15UsB8g6D2bIBl7FYxraVLNCoH7QVaJlhfcZmzfppS X-Received: by 10.107.132.215 with SMTP id o84mr11666883ioi.36.1438990556760; Fri, 07 Aug 2015 16:35:56 -0700 (PDT) Received: from mail-io0-f175.google.com (mail-io0-f175.google.com. [209.85.223.175]) by smtp.gmail.com with ESMTPSA id a133sm7902335ioe.34.2015.08.07.16.35.55 for (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 07 Aug 2015 16:35:55 -0700 (PDT) Received: by ioeg141 with SMTP id g141so125644956ioe.3 for ; Fri, 07 Aug 2015 16:35:55 -0700 (PDT) MIME-Version: 1.0 X-Received: by 10.107.13.201 with SMTP id 192mr11184517ion.70.1438990555582; Fri, 07 Aug 2015 16:35:55 -0700 (PDT) Received: by 10.36.89.70 with HTTP; Fri, 7 Aug 2015 16:35:55 -0700 (PDT) In-Reply-To: References: Date: Fri, 7 Aug 2015 19:35:55 -0400 Message-ID: From: Roman Shpount To: Martin Thomson Content-Type: multipart/alternative; boundary=001a113fd5e0e69c3e051cc11890 Archived-At: Cc: "" Subject: Re: [rtcweb] Do we have consensus on not requiring rtcp-non-mux? X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 07 Aug 2015 23:35:58 -0000 --001a113fd5e0e69c3e051cc11890 Content-Type: text/plain; charset=UTF-8 On Fri, Aug 7, 2015 at 7:09 PM, Martin Thomson wrote: > On 7 August 2015 at 15:50, Roman Shpount wrote: > > I would vote for 1 with the caveat that implementations MUST accept > rtcp-mux > > if offered. > > I'd be OK with an additional stipulation, though I'll note that we > don't actually need more inventive to select rtcp-mux. > What I was trying to say is that endpoints MAY implement rtcp-non-mux but MUST not use it if rtcp-mux is available from the remote end point. Which means MUST offer rtcp-mux and MUST accept rtcp-mux if offered. At this point we can delete the ugly code. _____________ Roman Shpount --001a113fd5e0e69c3e051cc11890 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On F= ri, Aug 7, 2015 at 7:09 PM, Martin Thomson <martin.thomson@gmail.co= m> wrote:
= On 7 August 2015 at 15:50, Roman Shpount <roman@telurix.com> wrote:
> I would vote for 1 with the caveat that implementations MUST accept rt= cp-mux
> if offered.

I'd be OK with an additional stipulation, though I'll note t= hat we
don't actually need more inventive to select rtcp-mux.

What I was trying t= o say is that endpoints=C2=A0MAY implement rtcp-n= on-mux but MUST not use it if rtcp-mux is available from the remote end poi= nt. Which means MUST offer rtcp-mux and MUST accept rtcp-mux if offered. At= this point we can delete the ugly code.
_____________
Roman Shpount

--001a113fd5e0e69c3e051cc11890-- From nobody Fri Aug 7 17:49:55 2015 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E743D1A1A92 for ; Fri, 7 Aug 2015 17:49:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KRzITwaoM5wY for ; Fri, 7 Aug 2015 17:49:52 -0700 (PDT) Received: from mail-pa0-x22e.google.com (mail-pa0-x22e.google.com [IPv6:2607:f8b0:400e:c03::22e]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id F344C1A1A9A for ; Fri, 7 Aug 2015 17:49:51 -0700 (PDT) Received: by pabyb7 with SMTP id yb7so66041911pab.0 for ; Fri, 07 Aug 2015 17:49:51 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=references:mime-version:in-reply-to:content-type :content-transfer-encoding:message-id:cc:from:subject:date:to; bh=6/54frYX2MgCvu43A+zQhw1aApAwWBp9vcuauo5w55Q=; b=oyhjvNcrotuzpKqiP/JJEiX94AcD/xz8ri7LKj772rM+3G6GDZLnx7TbvjKrF892B8 yZKa3cnbfqs0h6MQKdik8ed/w+FoXFVO+KZ9xprXJpdZ68ufFTmEHe/QnNK0j+S1vG1f H5lrx/YoOpr31j86USGTK4vyamNH0418Bpmk4fWoUHP/KyjjikCqCEsZMk+rqHjb8Iv2 dL6DpiYCF0kAdKeOxjpAwOJQZIzLxLAaJfduWXEl3rCqRRO0xvVl+L/Tw+ZZis+kbjBo kU0MYTSa+2Ya3JU0FQyB4GtysmKGm+z3ktR9DQ5GaJrzyLIUlp4vuVifC27gnxd2KIKo YyXA== X-Received: by 10.66.121.163 with SMTP id ll3mr20854433pab.100.1438994991690; Fri, 07 Aug 2015 17:49:51 -0700 (PDT) Received: from [10.70.106.12] (mobile-166-176-184-72.mycingular.net. [166.176.184.72]) by smtp.gmail.com with ESMTPSA id b10sm11454514pdo.84.2015.08.07.17.49.50 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Fri, 07 Aug 2015 17:49:50 -0700 (PDT) References: Mime-Version: 1.0 (1.0) In-Reply-To: Content-Type: multipart/alternative; boundary=Apple-Mail-77E3C377-D108-4983-845C-6402BFE4C4E2 Content-Transfer-Encoding: 7bit Message-Id: X-Mailer: iPhone Mail (12H143) From: Bernard Aboba Date: Fri, 7 Aug 2015 17:49:45 -0700 To: Eric Rescorla Archived-At: Cc: "" Subject: Re: [rtcweb] Do we have consensus on not requiring rtcp-non-mux? X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 08 Aug 2015 00:49:54 -0000 --Apple-Mail-77E3C377-D108-4983-845C-6402BFE4C4E2 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable +1. > On Aug 7, 2015, at 3:26 PM, Eric Rescorla wrote: >=20 > #1 is fine with me. >=20 > -Ekr >=20 >=20 >> On Fri, Aug 7, 2015 at 3:19 PM, Martin Thomson = wrote: >> Yes, #1. It might be bad to choose #2 and immediately invalidate >> every implementation that is currently compliant. >>=20 >> On 7 August 2015 at 14:39, Peter Thatcher wrote: >> > After lots of discussion, it appears we have three options: >> > >> > 1. Endpoints MAY implement rtcp-non-mux (we change the spec and can de= lete >> > the ugly code) >> > >> > 2. Endpoints MUST NOT implement rtcp-non-mux (we change the spec and m= ust >> > delete the ugly code, and our non-compliant until we do) >> > >> > 3. Endpoints MUST implement rtcp-non-mux (we don't change the spec and= keep >> > around the ugly code) >> > >> > >> > My reading of the discussion is that most people want #1 or #2, and ver= y few >> > people still want #3. Between #1 and #2, while some people would pref= er >> > #2, there are good reasons to just do #1, and most seem to prefer #1. >> > Further, I'm guessing that most people who wanted #2 could live with #1= . >> > >> > >> > TL;DR: I think we may have rough consensus on #1, saying endpoints MAY= >> > rtcp-non-mux (but may choose to delete all that ugly code instead). >> > >> > >> > So, is everyone happy with #1? >> > >> > >> > >> > >> > _______________________________________________ >> > rtcweb mailing list >> > rtcweb@ietf.org >> > https://www.ietf.org/mailman/listinfo/rtcweb >> > >>=20 >> _______________________________________________ >> rtcweb mailing list >> rtcweb@ietf.org >> https://www.ietf.org/mailman/listinfo/rtcweb >=20 > _______________________________________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/listinfo/rtcweb --Apple-Mail-77E3C377-D108-4983-845C-6402BFE4C4E2 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 7bit
+1.



On Aug 7, 2015, at 3:26 PM, Eric Rescorla <ekr@rtfm.com> wrote:

#1 is fine with me.

-Ekr


On Fri, Aug 7, 2015 at 3:19 PM, Martin Thomson <martin.thomson@gmail.com> wrote:
Yes, #1.  It might be bad to choose #2 and immediately invalidate
every implementation that is currently compliant.

On 7 August 2015 at 14:39, Peter Thatcher <pthatcher@google.com> wrote:
> After lots of discussion, it appears we have three options:
>
> 1.  Endpoints MAY implement rtcp-non-mux (we change the spec and can delete
> the ugly code)
>
> 2.  Endpoints MUST NOT implement rtcp-non-mux (we change the spec and must
> delete the ugly code, and our non-compliant until we do)
>
> 3.  Endpoints MUST implement rtcp-non-mux (we don't change the spec and keep
> around the ugly code)
>
>
> My reading of the discussion is that most people want #1 or #2, and very few
> people still want #3.   Between #1 and #2, while some people would prefer
> #2, there are good reasons to just do #1, and most seem to prefer #1.
> Further, I'm guessing that most people who wanted #2 could live with #1.
>
>
> TL;DR:  I think we may have rough consensus on #1, saying endpoints MAY
> rtcp-non-mux (but may choose to delete all that ugly code instead).
>
>
> So, is everyone happy with #1?
>
>
>
>
> _______________________________________________
> rtcweb mailing list
> rtcweb@ietf.org
> https://www.ietf.org/mailman/listinfo/rtcweb
>

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

_______________________________________________
rtcweb mailing list
rtcweb@ietf.org
https://www.ietf.org/mailman/listinfo/rtcweb
--Apple-Mail-77E3C377-D108-4983-845C-6402BFE4C4E2-- From nobody Fri Aug 7 23:47:40 2015 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 358F31ACE56 for ; Fri, 7 Aug 2015 23:47:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.749 X-Spam-Level: X-Spam-Status: No, score=-1.749 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_ENVFROM_END_DIGIT=0.25, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, 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 sTx3Fqkxkkvn for ; Fri, 7 Aug 2015 23:47:37 -0700 (PDT) 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 619021ACE55 for ; Fri, 7 Aug 2015 23:47:37 -0700 (PDT) Received: by ykdt205 with SMTP id t205so24500017ykd.1 for ; Fri, 07 Aug 2015 23:47:36 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:reply-to:in-reply-to:references:date:message-id :subject:from:to:cc:content-type; bh=7mEfDZLb+5EVdDVcjBOnTlEztUuUM14uf2subb31/So=; b=gKvTj0SS/frgjBXHfohB49bkG66wQHxppKvGdteaF8PZr4SOjPqlzW/B16wVz5cRsJ vJdABbC8kVHdcDkqg59T7ps7I+AcBciU+22Ekqw5U89IB4PGNiPOr80Wf7zCvAYNkRJd vIe4kN23oxpEVnkR5B++dgYAhwbx9kC2nTYyc8RXWngA7VCEhrYmJV/iwOPw+TSzhxq2 rc2PZSP/vMxOv0DibAdgWVNl9768aJwirVvx/E5WFFXEDymmC/shnlN5YzwWC/TKi5tV OswD7T9xVqYevg+nXbm2D9Ytkpld2hp2E6+XOdjscUBkjx8fhvBxZh2jf48mXQa23M74 d9sw== MIME-Version: 1.0 X-Received: by 10.170.134.214 with SMTP id a205mr76370ykc.89.1439016456716; Fri, 07 Aug 2015 23:47:36 -0700 (PDT) Received: by 10.13.195.129 with HTTP; Fri, 7 Aug 2015 23:47:36 -0700 (PDT) Received: by 10.13.195.129 with HTTP; Fri, 7 Aug 2015 23:47:36 -0700 (PDT) In-Reply-To: References: Date: Sat, 8 Aug 2015 07:47:36 +0100 Message-ID: From: Michael Davey To: Bernard Aboba Content-Type: multipart/alternative; boundary=001a113948e2ba8a18051cc72036 Archived-At: Cc: rtcweb@ietf.org Subject: Re: [rtcweb] Do we have consensus on not requiring rtcp-non-mux? X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: md84419@gmail.com List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 08 Aug 2015 06:47:39 -0000 --001a113948e2ba8a18051cc72036 Content-Type: text/plain; charset=UTF-8 Isn't MAY implicit anyway? Vendors are free to extend as they wish as long as they remain compliant with the spec and compatible with products that strictly conform to the spec. and don't extend it. Sounds like we are making the spec. needlessly complicated. On 8 Aug 2015 02:50, "Bernard Aboba" wrote: > +1. > > > > On Aug 7, 2015, at 3:26 PM, Eric Rescorla wrote: > > #1 is fine with me. > > -Ekr > > > On Fri, Aug 7, 2015 at 3:19 PM, Martin Thomson > wrote: > >> Yes, #1. It might be bad to choose #2 and immediately invalidate >> every implementation that is currently compliant. >> >> On 7 August 2015 at 14:39, Peter Thatcher wrote: >> > After lots of discussion, it appears we have three options: >> > >> > 1. Endpoints MAY implement rtcp-non-mux (we change the spec and can >> delete >> > the ugly code) >> > >> > 2. Endpoints MUST NOT implement rtcp-non-mux (we change the spec and >> must >> > delete the ugly code, and our non-compliant until we do) >> > >> > 3. Endpoints MUST implement rtcp-non-mux (we don't change the spec and >> keep >> > around the ugly code) >> > >> > >> > My reading of the discussion is that most people want #1 or #2, and >> very few >> > people still want #3. Between #1 and #2, while some people would >> prefer >> > #2, there are good reasons to just do #1, and most seem to prefer #1. >> > Further, I'm guessing that most people who wanted #2 could live with #1. >> > >> > >> > TL;DR: I think we may have rough consensus on #1, saying endpoints MAY >> > rtcp-non-mux (but may choose to delete all that ugly code instead). >> > >> > >> > So, is everyone happy with #1? >> > >> > >> > >> > >> > _______________________________________________ >> > rtcweb mailing list >> > rtcweb@ietf.org >> > https://www.ietf.org/mailman/listinfo/rtcweb >> > >> >> _______________________________________________ >> rtcweb mailing list >> rtcweb@ietf.org >> https://www.ietf.org/mailman/listinfo/rtcweb >> > > _______________________________________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/listinfo/rtcweb > > > _______________________________________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/listinfo/rtcweb > > --001a113948e2ba8a18051cc72036 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable

Isn't MAY implicit anyway?=C2=A0 Vendors are free to ext= end as they wish as long as they remain compliant with the spec and compati= ble with products that strictly conform to the spec. and don't extend i= t.

Sounds like we are making the spec. needlessly complicated.<= /p>

On 8 Aug 2015 02:50, "Bernard Aboba" &= lt;bernard.aboba@gmail.com&g= t; wrote:
+1.



On Aug 7, 2015, at 3:26 PM, Er= ic Rescorla <ekr@rtfm.= com> wrote:

#1 is fine with me.

-Ekr

=

On Fri, Aug 7, 20= 15 at 3:19 PM, Martin Thomson <martin.thomson@gmail.com> wrote:
Yes, #1.=C2=A0 It might be bad= to choose #2 and immediately invalidate
every implementation that is currently compliant.

On 7 August 2015 at 14:39, Peter Thatcher <pthatcher@google.com> wrote:
> After lots of discussion, it appears we have three options:
>
> 1.=C2=A0 Endpoints MAY implement rtcp-non-mux (we change the spec and = can delete
> the ugly code)
>
> 2.=C2=A0 Endpoints MUST NOT implement rtcp-non-mux (we change the spec= and must
> delete the ugly code, and our non-compliant until we do)
>
> 3.=C2=A0 Endpoints MUST implement rtcp-non-mux (we don't change th= e spec and keep
> around the ugly code)
>
>
> My reading of the discussion is that most people want #1 or #2, and ve= ry few
> people still want #3.=C2=A0 =C2=A0Between #1 and #2, while some people= would prefer
> #2, there are good reasons to just do #1, and most seem to prefer #1.<= br> > Further, I'm guessing that most people who wanted #2 could live wi= th #1.
>
>
> TL;DR:=C2=A0 I think we may have rough consensus on #1, saying endpoin= ts MAY
> rtcp-non-mux (but may choose to delete all that ugly code instead). >
>
> So, is everyone happy with #1?
>
>
>
>
> _______________________________________________
> rtcweb mailing list
> rtcweb@ietf.org
> https://www.ietf.org/mailman/listinfo/rtcweb >

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

___________________= ____________________________
rtcweb mailing list
= rtcweb@ietf.org<= /a>
https://www.ietf.org/mailman/listinfo/rtcweb=

__________________________________________= _____
rtcweb mailing list
rtcweb@ietf.org
https://www.ietf.org/mailman/listinfo/rtcweb

--001a113948e2ba8a18051cc72036-- From nobody Sat Aug 8 01:35:32 2015 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0C3A91A0100 for ; Sat, 8 Aug 2015 01:35:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.791 X-Spam-Level: X-Spam-Status: No, score=0.791 tagged_above=-999 required=5 tests=[BAYES_50=0.8, T_RP_MATCHES_RCVD=-0.01, WEIRD_PORT=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 Qe-wnExbHVaC for ; Sat, 8 Aug 2015 01:35:28 -0700 (PDT) Received: from lo.psyced.org (lost.in.psyced.org [188.40.42.221]) (using TLSv1 with cipher ECDHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 75C921A0110 for ; Sat, 8 Aug 2015 01:35:28 -0700 (PDT) Received: from lo.psyced.org (localhost [127.0.0.1]) by lo.psyced.org (8.14.3/8.14.3/Debian-9.4) with ESMTP id t788ZTlJ011952 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Sat, 8 Aug 2015 10:35:30 +0200 Received: (from lynx@localhost) by lo.psyced.org (8.14.3/8.14.3/Submit) id t788ZTxT011951 for rtcweb@ietf.org; Sat, 8 Aug 2015 10:35:29 +0200 Date: Sat, 8 Aug 2015 10:35:29 +0200 From: carlo von lynX To: rtcweb@ietf.org Message-ID: <20150808083529.GA20640@lo.psyced.org> References: <20150805161344.GA19492@lo.psyced.org> <20150805164256.GB19492@lo.psyced.org> <55C250CE.3040309@nostrum.com> <55C2E4C5.2050805@jesup.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <55C2E4C5.2050805@jesup.org> User-Agent: Mutt/1.5.20 (2009-06-14) Archived-At: Subject: Re: [rtcweb] LAST CALL: Systematically de-anonymize dissidents with WebRTC (HOWTO) X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 08 Aug 2015 08:35:31 -0000 On Thu, Aug 06, 2015 at 12:38:29AM -0400, Randell Jesup wrote: > proactively. Also: a government such as you describe can > *trivially* determine who is using a VPN by simply buying their own > accounts, looking at the VPN endpoint addresses, and monitoring > traffic to those IP/IP-ranges from ISPs within their country. Tor > avoids (some) of this type of attack, among other things. If VPN has been working for dissidents so far apparently this *trivial* method didn't work out. It would only show which people use that specific brand of VPN, but not serve to de-anonymize specific users, if I understand your scenario correctly. > I'll note that anyone trying to be anonymous needs to actually > follow some sort of advice on how to do so; they don't suddenly have > a light-bulb go on and say "I need a VPN!". The default of browsers Sometime during before arab spring word got around on how to do it. It may be difficult to "update" this word because browsers suddenly changed their safety features, downgrading a previously safe config into a dangerous one. > isn't "safe" for dissidents/etc. We can enable people to be (more, Used to be, actually... whatever browsers did, they used to respect proxy configurations. WebRTC is the thing that thinks it can bypass proxy and roll its own networking. Maybe it should be disabled by default whenever any sort of proxy is configured. > not totally) "safe", but we do need to balance that against other > concerns. The advice given to people may need to change (use a VPN > *and* this extension, or use a VPN *and* use private browsing mode - Nobody has a list of all dissidents, so the info travels word by mouth. Risk too high of arriving too late if a new threat is *deliberately* introduced on a formerly working configuration... That is so against user expectations as can be. > which BTW would likely be really good advice anyways! etc. Or > (gasp) use the Tor browser bundle on a bootable USB stick (NOT on > your HD!) (Note: We may well turn some of these mitigations on by > default in private browsing mode, for example.) Yes, that would be good.. although I'm not sure if the traffic of a TAILS or such is sufficiently *different* from regular users that it can bring you trouble. I don't dare to speak for them on anything like this - I just presume that breaking a formerly safe configuration is a VERY BAD IDEA. > We can't make all "I think/hear I should be safe if I ..." methods > users may be using actually *be* safe, though. See Adam's and > Matthew's responses. Which both didn't quite cut it. The problem is that people expect a formerly safe construct to remain safe. It's bad enough if new bugs are found.. but deliberately breaking the security that people are relying on is rather.. reckless. > We're also totally willing to consider other technical solutions, > here or via a personal draft - though some might have to wait for > additional spec updates - but as with most of WebRTC, the browsers > have been way out ahead of the spec. Realize that if the suggestion And it is to be expected that these browser developers are reading in on this thread and may possibly understand that having optional add-ons does not tackle the problem at all. > is "disable the feature for the entire web", or to make it > effectively unusable, it's not a good suggestion - and ironically Lives should be put in the first place, or otherwise you are actively promoting cynical thinking. But actually it's enough to extend the permission pop-up from mic/cam to also proxy- bypassing networking... I would assume that there are ways for the browsers to figure out if they are supposed to go through a SOCKS or other proxy and therefore automatically disable interface listings. So it is *really not that hard* and it could have been fixed about a year ago already! > may enable more control of populations by control of the remaining > communications channels (phones, etc). WebRTC also has the Eh? Regimes do not start abusing another channel when one no longer works.. they abuse everything they can afford to abuse. FireChat works in Hong Kong because it doesn't use the Internet, but which things work in which place depends on a lot of parameters that are to a large extend unresearched. The circumvention folks are the experts in this area. Browser vendors should talk this out with them before coding up random things to make a good impression but without achieving anything. Tactical tech could be suitable people to interact with. > potential to be leveraged into something that can bypass all sorts > of authoritarian controls, and various forms of monitoring (using > end-to-end encryption, Identity, and low-latency/cheap > DataChannels), and people are working on such tools. The assumption that the server providing the JS code can be kept in safe conditions remains one weak point of this architecture. Also the lack of an evolved built-in distributed hashtable system. There are reasons why tools like GNUnet took 12 years to be developed. WebRTC doesn't provide 5% of the necessary code to do proper end-to-end encrypted, sybil-attack resistant P2P. > >So all Carlo' comments are being dismissed because they are out of > >place and out of order, not because the topic is unimportant. His > >tone does not help either. > > Agreed. Sorry for the tone that has worked so far to get you out of complacency but you haven't successfully rebuked any of my "comments." -- E-mail is public! Talk to me in private using encryption: http://loupsycedyglgamf.onion/LynX/ irc://loupsycedyglgamf.onion:67/lynX https://psyced.org:34443/LynX/ From nobody Sat Aug 8 01:46:40 2015 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A27461A1B87 for ; Sat, 8 Aug 2015 01:46:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.909 X-Spam-Level: X-Spam-Status: No, score=-1.909 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, T_RP_MATCHES_RCVD=-0.01, WEIRD_PORT=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 XtgFQMHPyKEW for ; Sat, 8 Aug 2015 01:46:37 -0700 (PDT) Received: from lo.psyced.org (lost.in.psyced.org [188.40.42.221]) (using TLSv1 with cipher ECDHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B20541A1B84 for ; Sat, 8 Aug 2015 01:46:36 -0700 (PDT) Received: from lo.psyced.org (localhost [127.0.0.1]) by lo.psyced.org (8.14.3/8.14.3/Debian-9.4) with ESMTP id t788kcEI012231 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Sat, 8 Aug 2015 10:46:38 +0200 Received: (from lynx@localhost) by lo.psyced.org (8.14.3/8.14.3/Submit) id t788kcHO012230 for rtcweb@ietf.org; Sat, 8 Aug 2015 10:46:38 +0200 Date: Sat, 8 Aug 2015 10:46:38 +0200 From: carlo von lynX To: rtcweb@ietf.org Message-ID: <20150808084638.GA12082@lo.psyced.org> References: <20150805161344.GA19492@lo.psyced.org> <20150805164256.GB19492@lo.psyced.org> <55C250CE.3040309@nostrum.com> <55C2AE77.6010603@matthew.at> <20150807205458.GB2091@lo.psyced.org> <55C53328.6050308@matthew.at> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <55C53328.6050308@matthew.at> User-Agent: Mutt/1.5.20 (2009-06-14) Archived-At: Subject: Re: [rtcweb] LAST CALL: Systematically de-anonymize dissidents with WebRTC (HOWTO) X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 08 Aug 2015 08:46:38 -0000 On Fri, Aug 07, 2015 at 03:37:28PM -0700, Matthew Kaufman wrote: > This IETF working group cannot "simply get them" to do *anything*. > That's not how standards bodies work. > > Now, if you'd like to write a draft, or submit changes to the > security considerations draft, that would be welcome. I take this as a long-awaited acknowledgment that the danger scenario for dissidents truly exists and truly is introduced by the WebRTC API. That was the answer I seeked out to get several months ago when I first came here to ensure this scenario is being dealt with. Now it wasn't my intention to spend all this time on it. Feels like I opened Pandora's box by asking unwelcome questions. Now that you understood the problem, can I count on you to work things out or do I need to get my hands dirty and co-author IETF documents? Do you really want that? -- E-mail is public! Talk to me in private using encryption: http://loupsycedyglgamf.onion/LynX/ irc://loupsycedyglgamf.onion:67/lynX https://psyced.org:34443/LynX/ From nobody Sat Aug 8 04:20:10 2015 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E5A331A8920 for ; Sat, 8 Aug 2015 04:20:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KuwW16wpi7rr for ; Sat, 8 Aug 2015 04:20:03 -0700 (PDT) Received: from mailstore06.sysedata.no (b.mail.tornado.no [195.159.29.130]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C9A191A8924 for ; Sat, 8 Aug 2015 04:20:02 -0700 (PDT) Received: from [95.90.246.189] (helo=[192.168.0.2]) by mailstore06.sysedata.no with esmtpsa (TLS1.0:DHE_RSA_AES_128_CBC_SHA1:16) (Exim 4.71) (envelope-from ) id 1ZO2AR-0005JV-NA; Sat, 08 Aug 2015 13:19:59 +0200 Message-ID: <55C5E5DF.50704@db.org> Date: Sat, 08 Aug 2015 13:19:59 +0200 From: "Alfred E. Heggestad" User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Icedove/31.7.0 MIME-Version: 1.0 To: Martin Thomson , Peter Thatcher References: In-Reply-To: Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Cc: "" Subject: Re: [rtcweb] Do we have consensus on not requiring rtcp-non-mux? X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 08 Aug 2015 11:20:05 -0000 On 08/08/2015 12:19 AM, Martin Thomson wrote: > Yes, #1. It might be bad to choose #2 and immediately invalidate > every implementation that is currently compliant. > > On 7 August 2015 at 14:39, Peter Thatcher wrote: >> After lots of discussion, it appears we have three options: >> >> 1. Endpoints MAY implement rtcp-non-mux (we change the spec and can delete >> the ugly code) >> >> 2. Endpoints MUST NOT implement rtcp-non-mux (we change the spec and must >> delete the ugly code, and our non-compliant until we do) >> >> 3. Endpoints MUST implement rtcp-non-mux (we don't change the spec and keep >> around the ugly code) >> >> I support option #1 /alfred From nobody Sat Aug 8 08:19:58 2015 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7211E1A0419 for ; Sat, 8 Aug 2015 08:19:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wmZAhaGiVsJc for ; Sat, 8 Aug 2015 08:19:56 -0700 (PDT) Received: from mail-pa0-x22b.google.com (mail-pa0-x22b.google.com [IPv6:2607:f8b0:400e:c03::22b]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7BBD01A040C for ; Sat, 8 Aug 2015 08:19:56 -0700 (PDT) Received: by pawu10 with SMTP id u10so108977429paw.1 for ; Sat, 08 Aug 2015 08:19:56 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=content-type:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=3O0QHMZ1Yp6edBg03RbzeHmVEsDM37v94U0gzNwWzUY=; b=uGMcW6LRmPdZS5zrz9dJz0xsT58FtVZwhOI4BF6eSH5GiY5O/A4EHphauEi2HJqaAB 0Sr+YXfhSAYGSnSc+6hJv8Dqq8ql6gEW3Rew2O4sydhOULLj0U0DyOeJuOqFD+ui5V+Y Zl6KotiO4i41kA3nsiiQVEXJc00ZZ/t4Dvi8QywdK4IhuZ+ZAETY5g1BUWd2yX8pXuof CrNIrxMtJBvFl3XUpOpouICGrXJeC/v1aRNtL97o8KiMpr0WDnOJIvT5dfdsHNN+hz4t l/zOJcfxYdzOjTPwUZ6mCbWDIZSughfuYvzo27LlqzlF2y9D55mwTk1RGsLXVtd2Xot/ 7fNw== X-Received: by 10.68.117.173 with SMTP id kf13mr26992966pbb.96.1439047196149; Sat, 08 Aug 2015 08:19:56 -0700 (PDT) Received: from [192.168.1.110] (c-71-227-237-49.hsd1.wa.comcast.net. [71.227.237.49]) by smtp.gmail.com with ESMTPSA id y2sm13881853pdi.80.2015.08.08.08.19.55 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Sat, 08 Aug 2015 08:19:55 -0700 (PDT) Content-Type: multipart/alternative; boundary=Apple-Mail-9DDB8F2D-C3C8-420D-993E-86212DE95979 Mime-Version: 1.0 (1.0) From: Bernard Aboba X-Mailer: iPad Mail (12H143) In-Reply-To: Date: Sat, 8 Aug 2015 08:19:54 -0700 Content-Transfer-Encoding: 7bit Message-Id: <15C276FD-5BB9-45C5-8452-BFC99A25E0AC@gmail.com> References: To: "md84419@gmail.com" Archived-At: Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] Do we have consensus on not requiring rtcp-non-mux? X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 08 Aug 2015 15:19:57 -0000 --Apple-Mail-9DDB8F2D-C3C8-420D-993E-86212DE95979 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable On Aug 7, 2015, at 23:47, Michael Davey wrote: > Isn't MAY implicit anyway?=20 >=20 [BA] No, it is not because the RTP-Usage document makes support for RTP/RTCP= non-mux mandatory. We are talking about changing that text from MUST to MA= Y.= --Apple-Mail-9DDB8F2D-C3C8-420D-993E-86212DE95979 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 7bit
On Aug 7, 2015, at 23:47, Michael Davey <md84419@gmail.com> wrote:

Isn't MAY implicit anyway? 

[BA] No, it is not because the RTP-Usage document makes support for RTP/RTCP non-mux mandatory.  We are talking about changing that text from MUST to MAY.
--Apple-Mail-9DDB8F2D-C3C8-420D-993E-86212DE95979-- From nobody Sat Aug 8 12:25:42 2015 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0B2FA1ACD3C for ; Sat, 8 Aug 2015 12:25:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.5 X-Spam-Level: X-Spam-Status: No, score=-0.5 tagged_above=-999 required=5 tests=[BAYES_05=-0.5, RCVD_IN_DNSWL_NONE=-0.0001] 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 ttQnGVNlPBOr for ; Sat, 8 Aug 2015 12:25:39 -0700 (PDT) Received: from ar-005-i178.relay.mailchannels.net (ar-005-i178.relay.mailchannels.net [162.253.144.63]) by ietfa.amsl.com (Postfix) with ESMTP id 9CB411A1A2F for ; Sat, 8 Aug 2015 12:25:38 -0700 (PDT) X-Sender-Id: wwwh|x-authuser|randell@jesup.org Received: from r2-chicago.webserversystems.com (ip-10-229-11-165.us-west-2.compute.internal [10.229.11.165]) by relay.mailchannels.net (Postfix) with ESMTPA id 894801204F6 for ; Sat, 8 Aug 2015 19:25:36 +0000 (UTC) X-Sender-Id: wwwh|x-authuser|randell@jesup.org Received: from r2-chicago.webserversystems.com (r2-chicago.webserversystems.com [10.232.141.54]) (using TLSv1 with cipher DHE-RSA-AES256-SHA) by 0.0.0.0:2500 (trex/5.5.1); Sat, 08 Aug 2015 19:25:36 +0000 X-MC-Relay: Neutral X-MailChannels-SenderId: wwwh|x-authuser|randell@jesup.org X-MailChannels-Auth-Id: wwwh X-MC-Loop-Signature: 1439061936740:1924782731 X-MC-Ingress-Time: 1439061936740 Received: from pool-96-227-119-208.phlapa.fios.verizon.net ([96.227.119.208]:48237 helo=[192.168.1.12]) by r2-chicago.webserversystems.com with esmtpsa (TLSv1:DHE-RSA-AES128-SHA:128) (Exim 4.85) (envelope-from ) id 1ZO9kM-0009Xn-Kt for rtcweb@ietf.org; Sat, 08 Aug 2015 14:25:34 -0500 References: <20150805161344.GA19492@lo.psyced.org> <20150805164256.GB19492@lo.psyced.org> <55C250CE.3040309@nostrum.com> <55C2E4C5.2050805@jesup.org> <20150808083529.GA20640@lo.psyced.org> To: rtcweb@ietf.org From: Randell Jesup Message-ID: <55C65777.8090309@jesup.org> Date: Sat, 8 Aug 2015 15:24:39 -0400 User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.1.0 MIME-Version: 1.0 In-Reply-To: <20150808083529.GA20640@lo.psyced.org> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit X-AuthUser: randell@jesup.org Archived-At: Subject: Re: [rtcweb] LAST CALL: Systematically de-anonymize dissidents with WebRTC (HOWTO) X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 08 Aug 2015 19:25:41 -0000 On 8/8/2015 4:35 AM, carlo von lynX wrote: > On Thu, Aug 06, 2015 at 12:38:29AM -0400, Randell Jesup wrote: >> proactively. Also: a government such as you describe can >> *trivially* determine who is using a VPN by simply buying their own >> accounts, looking at the VPN endpoint addresses, and monitoring >> traffic to those IP/IP-ranges from ISPs within their country. Tor >> avoids (some) of this type of attack, among other things. > If VPN has been working for dissidents so far apparently this > *trivial* method didn't work out. It would only show which people > use that specific brand of VPN, but not serve to de-anonymize > specific users, if I understand your scenario correctly. It will show you who's using different VPNs (traffic analysis can likely correlate VPN use with inbound traffic to specific sites: put a content (or an ad) on a site with a specific set of images, and then correlate fetches of those and the sizes/timings with traffic to/from the VPN, and you can (close enough for this work) deduce who's using a VPN to browser these sites. If you have the data, it's not hard. This is not NSA-level analysis; any moderately competent network programmer could work out how to implement it given access to packet logs of VPN traffic from ISPs, which one has to presume they can get. Similar attacks have been made on Tor IIRC, but side-effects and design features of Tor make this attack harder (not impossible IIRC) against it. >> I'll note that anyone trying to be anonymous needs to actually >> follow some sort of advice on how to do so; they don't suddenly have >> a light-bulb go on and say "I need a VPN!". The default of browsers > Sometime during before arab spring word got around on how to do it. > It may be difficult to "update" this word because browsers suddenly > changed their safety features, downgrading a previously safe config > into a dangerous one. Well, things change, and not just browsers. People intercepting traffic learn new tricks too. Freezing the world because people may rely on outdated info is not a great answer. Finding a way to update the info they rely on is a much better answer. I do understand the concerns. Part of the answer may be to have tighter controls by default in Private Browsing mode (which they really, really should be using before they even get to the point of thinking of a VPN, otherwise someone says "give me your computer" (or even "let me see your computer history", and you're sunk). >> isn't "safe" for dissidents/etc. We can enable people to be (more, > Used to be, actually... whatever browsers did, they used to respect > proxy configurations. WebRTC is the thing that thinks it can bypass > proxy and roll its own networking. Maybe it should be disabled by > default whenever any sort of proxy is configured. Proxies were never intended as a security or anonymity measure for users; they were created because many organizations used proxies to a) limit traffic in/out of their network, and b) they used proxy-caches (like Squid) to reduce bandwidth by providing a large, shared cache to an organization. Transparent proxies mostly replaced b. HTTPS traffic bypasses (or at least just gets piped through) proxies, of course. That people found another way to use them is cool, but don't assume their security properties match the use-case of the users, since it's not part of the design. >> not totally) "safe", but we do need to balance that against other >> concerns. The advice given to people may need to change (use a VPN >> *and* this extension, or use a VPN *and* use private browsing mode - > Nobody has a list of all dissidents, so the info travels word by > mouth. Risk too high of arriving too late if a new threat is > *deliberately* introduced on a formerly working configuration... > That is so against user expectations as can be. There is this thing called the web, where information on best-security-practices for dissidents can be WIDELY published, and then those who have it can tell others; exchange thumbdrives, etc. I've heard the web is effective for this. >> We're also totally willing to consider other technical solutions, >> here or via a personal draft - though some might have to wait for >> additional spec updates - but as with most of WebRTC, the browsers >> have been way out ahead of the spec. Realize that if the suggestion > And it is to be expected that these browser developers are > reading in on this thread and may possibly understand that having > optional add-ons does not tackle the problem at all. You should realize many of the people speaking on this thread largely *are* the browser developers (though this group is not the one that defines the interfaces and UI requirements, just the on-wire protocols). >> potential to be leveraged into something that can bypass all sorts >> of authoritarian controls, and various forms of monitoring (using >> end-to-end encryption, Identity, and low-latency/cheap >> DataChannels), and people are working on such tools. > The assumption that the server providing the JS code can be kept > in safe conditions remains one weak point of this architecture. No, it's assumed for this sort of thing you may bootstrap from servers, but that the code can be stored and run from local storage. No central server at all. (Which means no single-point-blocking ala twitter/etc). -- Randell Jesup -- rjesup a t mozilla d o t com Please please please don't email randell-ietf@jesup.org! Way too much spam From nobody Sun Aug 9 00:05:23 2015 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D8CE51ACD8C for ; Sun, 9 Aug 2015 00:05:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.909 X-Spam-Level: X-Spam-Status: No, score=-1.909 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pwJ6GkmQsaTQ for ; Sun, 9 Aug 2015 00:05:19 -0700 (PDT) Received: from mork.alvestrand.no (mork.alvestrand.no [IPv6:2001:700:1:2::117]) by ietfa.amsl.com (Postfix) with ESMTP id 3996F1ACD88 for ; Sun, 9 Aug 2015 00:05:19 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mork.alvestrand.no (Postfix) with ESMTP id 68C167C35F4 for ; Sun, 9 Aug 2015 09:05:18 +0200 (CEST) X-Virus-Scanned: Debian amavisd-new at alvestrand.no Received: from mork.alvestrand.no ([127.0.0.1]) by localhost (mork.alvestrand.no [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pd_8OmT-MXjj for ; Sun, 9 Aug 2015 09:05:16 +0200 (CEST) Received: from [IPv6:2001:470:de0a:27:5811:b2f4:1863:23e4] (unknown [IPv6:2001:470:de0a:27:5811:b2f4:1863:23e4]) by mork.alvestrand.no (Postfix) with ESMTPSA id 25E567C07BF for ; Sun, 9 Aug 2015 09:05:16 +0200 (CEST) Message-ID: <55C6FBAB.6050009@alvestrand.no> Date: Sun, 09 Aug 2015 09:05:15 +0200 From: Harald Alvestrand User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.7.0 MIME-Version: 1.0 To: rtcweb@ietf.org References: In-Reply-To: Content-Type: multipart/alternative; boundary="------------090908050607090809080102" Archived-At: Subject: Re: [rtcweb] Do we have consensus on not requiring rtcp-non-mux? X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 09 Aug 2015 07:05:22 -0000 This is a multi-part message in MIME format. --------------090908050607090809080102 Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable I am happy to live with #1. There's a particular style of gateway (one that takes calls from WebRTC devices and non-WebRTC, non-RTCP-mux devices at the same responding port) that would have a hard time claiming WebRTC conformance under #2; not a huge argument, but makes me a little more happy with #1 than #2. On 08/07/2015 11:39 PM, Peter Thatcher wrote: > After lots of discussion, it appears we have three options: > > 1. Endpoints MAY implement rtcp-non-mux (we change the spec and can > delete the ugly code) > > 2. Endpoints MUST NOT implement rtcp-non-mux (we change the spec and > must delete the ugly code, and our non-compliant until we do) > > 3. Endpoints MUST implement rtcp-non-mux (we don't change the spec > and keep around the ugly code) > > > My reading of the discussion is that most people want #1 or #2, and > very few people still want #3. Between #1 and #2, while some people > would prefer #2, there are good reasons to just do #1, and most seem > to prefer #1. Further, I'm guessing that most people who wanted #2 > could live with #1. > > > TL;DR: I think we may have rough consensus on #1, saying endpoints > MAY rtcp-non-mux (but may choose to delete all that ugly code instead).= =20 > > > So, is everyone happy with #1? > > > > > > _______________________________________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/listinfo/rtcweb --=20 Surveillance is pervasive. Go Dark. --------------090908050607090809080102 Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: 8bit
I am happy to live with #1.

There's a particular style of gateway (one that takes calls from WebRTC devices and non-WebRTC, non-RTCP-mux devices at the same responding port) that would have a hard time claiming WebRTC conformance under #2; not a huge argument, but makes me a little more happy with #1 than #2.

On 08/07/2015 11:39 PM, Peter Thatcher wrote:
After lots of discussion, it appears we have three options:

1. Endpoints MAY implement rtcp-non-mux (we change the spec and can delete the ugly code)

2. Endpoints MUST NOT implement rtcp-non-mux (we change the spec and must delete the ugly code, and our non-compliant until we do)

3. Endpoints MUST implement rtcp-non-mux (we don't change the spec and keep around the ugly code)


My reading of the discussion is that most people want #1 or #2, and very few people still want #3. Between #1 and #2, while some people would prefer #2, there are good reasons to just do #1, and most seem to prefer #1. Further, I'm guessing that most people who wanted #2 could live with #1.


TL;DR: I think we may have rough consensus on #1, saying endpoints MAY rtcp-non-mux (but may choose to delete all that ugly code instead).


So, is everyone happy with #1?





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



-- 
Surveillance is pervasive. Go Dark.
--------------090908050607090809080102-- From nobody Sun Aug 9 09:43:21 2015 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BD51D1AD289 for ; Sun, 9 Aug 2015 09:43:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.791 X-Spam-Level: X-Spam-Status: No, score=0.791 tagged_above=-999 required=5 tests=[BAYES_50=0.8, T_RP_MATCHES_RCVD=-0.01, WEIRD_PORT=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 UaXHHKpEcgvB for ; Sun, 9 Aug 2015 09:43:18 -0700 (PDT) Received: from lo.psyced.org (lost.in.psyced.org [188.40.42.221]) (using TLSv1 with cipher ECDHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CFEA31A7028 for ; Sun, 9 Aug 2015 09:43:17 -0700 (PDT) Received: from lo.psyced.org (localhost [127.0.0.1]) by lo.psyced.org (8.14.3/8.14.3/Debian-9.4) with ESMTP id t79GhDYe003316 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Sun, 9 Aug 2015 18:43:15 +0200 Received: (from lynx@localhost) by lo.psyced.org (8.14.3/8.14.3/Submit) id t79GhDif003315 for rtcweb@ietf.org; Sun, 9 Aug 2015 18:43:13 +0200 Date: Sun, 9 Aug 2015 18:43:12 +0200 From: carlo von lynX To: rtcweb@ietf.org Message-ID: <20150809164311.GA2858@lo.psyced.org> References: <20150805161344.GA19492@lo.psyced.org> <20150805164256.GB19492@lo.psyced.org> <55C250CE.3040309@nostrum.com> <55C2E4C5.2050805@jesup.org> <20150808083529.GA20640@lo.psyced.org> <55C65777.8090309@jesup.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <55C65777.8090309@jesup.org> User-Agent: Mutt/1.5.20 (2009-06-14) Archived-At: Subject: Re: [rtcweb] LAST CALL: Systematically de-anonymize dissidents with WebRTC (HOWTO) X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 09 Aug 2015 16:43:20 -0000 On Sat, Aug 08, 2015 at 03:24:39PM -0400, Randell Jesup wrote: > On 8/8/2015 4:35 AM, carlo von lynX wrote: > >On Thu, Aug 06, 2015 at 12:38:29AM -0400, Randell Jesup wrote: > >>proactively. Also: a government such as you describe can > >>*trivially* determine who is using a VPN by simply buying their own > >>accounts, looking at the VPN endpoint addresses, and monitoring > >>traffic to those IP/IP-ranges from ISPs within their country. Tor > >>avoids (some) of this type of attack, among other things. > >If VPN has been working for dissidents so far apparently this > >*trivial* method didn't work out. It would only show which people > >use that specific brand of VPN, but not serve to de-anonymize > >specific users, if I understand your scenario correctly. > > It will show you who's using different VPNs (traffic analysis can > likely correlate VPN use with inbound traffic to specific sites: put > a content (or an ad) on a site with a specific set of images, and > then correlate fetches of those and the sizes/timings with traffic > to/from the VPN, and you can (close enough for this work) deduce > who's using a VPN to browser these sites. If you have the data, > it's not hard. This is not NSA-level analysis; any moderately > competent network programmer could work out how to implement it > given access to packet logs of VPN traffic from ISPs, which one has > to presume they can get. Similar attacks have been made on Tor > IIRC, but side-effects and design features of Tor make this attack > harder (not impossible IIRC) against it. Yes, with a person as competent as you this attack scenario is likely. So far governments of such countries are unlikely to have the necessary competence to correlate traffic like that. Hey, we are talking of governments not competent enough to develop something trashy like "Galileo." They rather buy it! > >>I'll note that anyone trying to be anonymous needs to actually > >>follow some sort of advice on how to do so; they don't suddenly have > >>a light-bulb go on and say "I need a VPN!". The default of browsers > >Sometime during before arab spring word got around on how to do it. > >It may be difficult to "update" this word because browsers suddenly > >changed their safety features, downgrading a previously safe config > >into a dangerous one. > > Well, things change, and not just browsers. People intercepting > traffic learn new tricks too. Freezing the world because people You are responsible of THIS specific change and the solution is really simple. WHY do you want to pursue something that puts lives at risk if you can simply fix the problem? WHY are you spending so much time trying to find excuses for yourself and everybody in the WebRTC business? I am fully aware of being the only person in here without a business interest in WebRTC, so I'm not surprised if I'm fighting this battle alone. > may rely on outdated info is not a great answer. Finding a way to > update the info they rely on is a much better answer. I do > understand the concerns. Part of the answer may be to have tighter First you make the browser safe by being conservative in the way it does networking in the case of proxy configuration, if necessary also with an additional pop-up.. then you spend some time and money to get in touch with people who *WORK* with dissidents in those countries everyday (you can even get in touch with several US government institutions on that topic!) and find out *IF* you can figure out a solution that suits your business interests better. But don't go the Monsanto way of first breaking everyhing and then only stepping half a step back if all of the world got angry. > controls by default in Private Browsing mode (which they really, > really should be using before they even get to the point of thinking > of a VPN, otherwise someone says "give me your computer" (or even > "let me see your computer history", and you're sunk). They may be using Private Browsing mode. Is WebRTC fully disabled in PBM? > >>isn't "safe" for dissidents/etc. We can enable people to be (more, > >Used to be, actually... whatever browsers did, they used to respect > >proxy configurations. WebRTC is the thing that thinks it can bypass > >proxy and roll its own networking. Maybe it should be disabled by > >default whenever any sort of proxy is configured. > > Proxies were never intended as a security or anonymity measure for That doesn't matter. You can't tell those young folks that ran the Tunesian revolution that they shouldn't have done it because they used proxies in an unintentional way. > users; they were created because many organizations used proxies to > a) limit traffic in/out of their network, and b) they used > proxy-caches (like Squid) to reduce bandwidth by providing a large, > shared cache to an organization. Transparent proxies mostly > replaced b. HTTPS traffic bypasses (or at least just gets piped > through) proxies, of course. That people found another way to use > them is cool, but don't assume their security properties match the > use-case of the users, since it's not part of the design. So your idea of business ethics is - if you used it to fight for democracy in your country you are on your own because we have other plans. Your revolution doesn't fit our business plan. > >>not totally) "safe", but we do need to balance that against other > >>concerns. The advice given to people may need to change (use a VPN > >>*and* this extension, or use a VPN *and* use private browsing mode - > >Nobody has a list of all dissidents, so the info travels word by > >mouth. Risk too high of arriving too late if a new threat is > >*deliberately* introduced on a formerly working configuration... > >That is so against user expectations as can be. > > There is this thing called the web, where information on > best-security-practices for dissidents can be WIDELY published, and > then those who have it can tell others; exchange thumbdrives, etc. > I've heard the web is effective for this. Only if they can access the web safely.. if the Chrome update comes before those websites written in their respective languages are updated, then authorities will have a way to find out who accesses those websites before they can fix their setups. Boom, doomed by having used the web for exactly what you describe. Your logic is circularely flawed. > >>We're also totally willing to consider other technical solutions, > >>here or via a personal draft - though some might have to wait for > >>additional spec updates - but as with most of WebRTC, the browsers > >>have been way out ahead of the spec. Realize that if the suggestion > >And it is to be expected that these browser developers are > >reading in on this thread and may possibly understand that having > >optional add-ons does not tackle the problem at all. > > You should realize many of the people speaking on this thread > largely *are* the browser developers (though this group is not the > one that defines the interfaces and UI requirements, just the > on-wire protocols). Which is good, so we are walking through all possible reasons not to fix the browser - one by one. By showing you how none of them really handle the problem or make the problem go away, we slowly get you to understand how serious the issue is and how much it is insufficient or unethical to just offer some optional plugin for a few paranoid nerds. > >>potential to be leveraged into something that can bypass all sorts > >>of authoritarian controls, and various forms of monitoring (using > >>end-to-end encryption, Identity, and low-latency/cheap > >>DataChannels), and people are working on such tools. > >The assumption that the server providing the JS code can be kept > >in safe conditions remains one weak point of this architecture. > > No, it's assumed for this sort of thing you may bootstrap from > servers, but that the code can be stored and run from local storage. > No central server at all. (Which means no single-point-blocking ala > twitter/etc). So far all server bootstrap architectures implied that servers can MITM the communication. And then Snowden says metadata protection is the most important thing - and WebRTC has not a vague clue on how to fix that. -- E-mail is public! Talk to me in private using encryption: http://loupsycedyglgamf.onion/LynX/ irc://loupsycedyglgamf.onion:67/lynX https://psyced.org:34443/LynX/ From nobody Sun Aug 9 18:40:09 2015 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 133671B32CD for ; Sun, 9 Aug 2015 18:40:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.311 X-Spam-Level: X-Spam-Status: No, score=-4.311 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_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Qg_jhGrOiX1V for ; Sun, 9 Aug 2015 18:40:07 -0700 (PDT) Received: from mercury.scss.tcd.ie (mercury.scss.tcd.ie [134.226.56.6]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 02D071B32CC for ; Sun, 9 Aug 2015 18:40:07 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id B9B1EBE4D; Mon, 10 Aug 2015 02:40:05 +0100 (IST) X-Virus-Scanned: Debian amavisd-new at scss.tcd.ie Received: from mercury.scss.tcd.ie ([127.0.0.1]) by localhost (mercury.scss.tcd.ie [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id W8330wjlfMlZ; Mon, 10 Aug 2015 02:40:04 +0100 (IST) Received: from [10.87.48.73] (unknown [86.46.29.218]) by mercury.scss.tcd.ie (Postfix) with ESMTPSA id A9EDDBE3F; Mon, 10 Aug 2015 02:40:04 +0100 (IST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cs.tcd.ie; s=mail; t=1439170804; bh=ThtVwk9d/Vv4Hxpy3iz8Pilkh9i/rFaQib2DHYfxLhI=; h=Date:From:To:Subject:References:In-Reply-To:From; b=3WhKuYkp/JX+Zzl0kgbAVDavjOpSu384p9z4KuFYXI9JwBZiAMURNGv2YCuCvvP+n Fm0HJ5oIyZcE0Yfshhjrp5bAe5wN7cWr7XC7g6wXwNKXZuZ1OqyVNiapfeveikBv06 QOT3XjN9CNEjkTIqUPtr+oytea6lTwbp2jIbmJDg= Message-ID: <55C800F4.5080706@cs.tcd.ie> Date: Mon, 10 Aug 2015 02:40:04 +0100 From: Stephen Farrell User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.8.0 MIME-Version: 1.0 To: carlo von lynX , rtcweb@ietf.org References: <20150805161344.GA19492@lo.psyced.org> <20150805164256.GB19492@lo.psyced.org> <55C250CE.3040309@nostrum.com> <55C2AE77.6010603@matthew.at> <20150807205458.GB2091@lo.psyced.org> <55C53328.6050308@matthew.at> <20150808084638.GA12082@lo.psyced.org> In-Reply-To: <20150808084638.GA12082@lo.psyced.org> OpenPGP: id=D66EA7906F0B897FB2E97D582F3C8736805F8DA2; url= Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [rtcweb] LAST CALL: Systematically de-anonymize dissidents with WebRTC (HOWTO) X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 10 Aug 2015 01:40:08 -0000 On 08/08/15 09:46, carlo von lynX wrote: > do I need to get my hands dirty and > co-author IETF documents? Do you really want that? > Yes. Of course we want that. People have said it >1 time. That is how we do stuff and part (not all) of the reason why you've been having a hard time getting change - when someone says "hey you over there need to do some work I've defined" I think it's safe to say that generates a negative reaction from IETFers. That said, for you crafting text to work in *this* context, you'd have to not be in clean-slate mode whilst writing that specific text:-) S. From nobody Mon Aug 10 02:11:02 2015 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E12DB1A8A9C for ; Mon, 10 Aug 2015 02:11:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.609 X-Spam-Level: X-Spam-Status: No, score=-2.609 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wou6TVh58U3B for ; Mon, 10 Aug 2015 02:10:58 -0700 (PDT) Received: from mx11.unify.com (mx11.unify.com [62.134.46.9]) by ietfa.amsl.com (Postfix) with ESMTP id 287FE1B337B for ; Mon, 10 Aug 2015 02:10:58 -0700 (PDT) Received: from MCHP02HTC.global-ad.net (unknown [172.29.42.235]) by mx11.unify.com (Server) with ESMTP id BCCCA1EB8433; Mon, 10 Aug 2015 11:10:56 +0200 (CEST) Received: from MCHP04MSX.global-ad.net ([169.254.37.243]) by MCHP02HTC.global-ad.net ([172.29.42.235]) with mapi id 14.03.0248.002; Mon, 10 Aug 2015 11:10:56 +0200 From: "Hutton, Andrew" To: Harald Alvestrand , "rtcweb@ietf.org" Thread-Topic: [rtcweb] Do we have consensus on not requiring rtcp-non-mux? Thread-Index: AQHQ0VmZykpCDL/O5UCzT5SMAv9Ph54DH0GAgAHWVJA= Date: Mon, 10 Aug 2015 09:10:56 +0000 Message-ID: <9F33F40F6F2CD847824537F3C4E37DDF1E83584F@MCHP04MSX.global-ad.net> References: <55C6FBAB.6050009@alvestrand.no> In-Reply-To: <55C6FBAB.6050009@alvestrand.no> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [172.29.42.225] Content-Type: multipart/alternative; boundary="_000_9F33F40F6F2CD847824537F3C4E37DDF1E83584FMCHP04MSXglobal_" MIME-Version: 1.0 Archived-At: Subject: Re: [rtcweb] Do we have consensus on not requiring rtcp-non-mux? X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 10 Aug 2015 09:11:01 -0000 --_000_9F33F40F6F2CD847824537F3C4E37DDF1E83584FMCHP04MSXglobal_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable If we have consensus for #1 then I assume we need to pull the -rtp-usage- d= raft back from the RFC Editor Queue (See https://tools.ietf.org/html/draft-= ietf-rtcweb-rtp-usage-25#section-4.5 ) Andy From: rtcweb [mailto:rtcweb-bounces@ietf.org] On Behalf Of Harald Alvestran= d Sent: 09 August 2015 08:05 To: rtcweb@ietf.org Subject: Re: [rtcweb] Do we have consensus on not requiring rtcp-non-mux? I am happy to live with #1. There's a particular style of gateway (one that takes calls from WebRTC dev= ices and non-WebRTC, non-RTCP-mux devices at the same responding port) that= would have a hard time claiming WebRTC conformance under #2; not a huge ar= gument, but makes me a little more happy with #1 than #2. On 08/07/2015 11:39 PM, Peter Thatcher wrote: After lots of discussion, it appears we have three options: 1. Endpoints MAY implement rtcp-non-mux (we change the spec and can delete= the ugly code) 2. Endpoints MUST NOT implement rtcp-non-mux (we change the spec and must = delete the ugly code, and our non-compliant until we do) 3. Endpoints MUST implement rtcp-non-mux (we don't change the spec and kee= p around the ugly code) My reading of the discussion is that most people want #1 or #2, and very fe= w people still want #3. Between #1 and #2, while some people would prefer= #2, there are good reasons to just do #1, and most seem to prefer #1. Fur= ther, I'm guessing that most people who wanted #2 could live with #1. TL;DR: I think we may have rough consensus on #1, saying endpoints MAY rtc= p-non-mux (but may choose to delete all that ugly code instead). So, is everyone happy with #1? _______________________________________________ rtcweb mailing list rtcweb@ietf.org https://www.ietf.org/mailman/listinfo/rtcweb -- Surveillance is pervasive. Go Dark. --_000_9F33F40F6F2CD847824537F3C4E37DDF1E83584FMCHP04MSXglobal_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

If we have consensus for = #1 then I assume we need to pull the –rtp-usage- draft back from the = RFC Editor Queue (See https://tools.ietf.org/html/draft-ietf-rtcweb-rtp-usage-25#section-4.5 = )

 <= /p>

Andy

 <= /p>

 <= /p>

 <= /p>

 <= /p>

From: rtcweb [mailto:rtcweb-bounces@ietf.org] On Behalf Of Harald Alvestrand
Sent: 09 August 2015 08:05
To: rtcweb@ietf.org
Subject: Re: [rtcweb] Do we have consensus on not requiring rtcp-non= -mux?

 

I am happy to live with #1.

There's a particular style of gateway (one that takes calls from WebRTC dev= ices and non-WebRTC, non-RTCP-mux devices at the same responding port) that= would have a hard time claiming WebRTC conformance under #2; not a huge ar= gument, but makes me a little more happy with #1 than #2.

On 08/07/2015 11:39 PM, Peter Thatcher wrote:

After lots of discussion, it appears we have three options= :

 

1.  Endpoints MAY implement rtcp-non-mux (we change t= he spec and can delete the ugly code)

 

2.  Endpoints MUST NOT implement rtcp-non-mux (we cha= nge the spec and must delete the ugly code, and our non-compliant until we = do)

 

3.  Endpoints MUST implement rtcp-non-mux (we don't c= hange the spec and keep around the ugly code)

 

 

My reading of the discussion is that most people want #1 o= r #2, and very few people still want #3.   Between #1 and #2, while so= me people would prefer #2, there are good reasons to just do #1, and most seem to prefer #1.  Further, I'm guessing that most peop= le who wanted #2 could live with #1.

 

 

TL;DR:  I think we may have rough consensus on #1, sa= ying endpoints MAY rtcp-non-mux (but may choose to delete all that ugly cod= e instead).  

 

 

So, is everyone happy with #1?

 

 

 




_______________________________________________
rtcweb mailing list
rtcweb@ietf.org

https://www.i=
etf.org/mailman/listinfo/rtcweb






-- 
Surveillance is pervasive. Go Dark.
--_000_9F33F40F6F2CD847824537F3C4E37DDF1E83584FMCHP04MSXglobal_-- From nobody Mon Aug 10 02:18:18 2015 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E12681B3396 for ; Mon, 10 Aug 2015 02:18:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.2 X-Spam-Level: X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OIspC5LLBnsE for ; Mon, 10 Aug 2015 02:18:14 -0700 (PDT) Received: from sesbmg22.ericsson.net (sesbmg22.ericsson.net [193.180.251.48]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9FD0A1B3390 for ; Mon, 10 Aug 2015 02:18:13 -0700 (PDT) X-AuditID: c1b4fb30-f79706d000007227-10-55c86c53398e Received: from ESESSHC011.ericsson.se (Unknown_Domain [153.88.253.124]) by sesbmg22.ericsson.net (Symantec Mail Security) with SMTP id 69.E3.29223.35C68C55; Mon, 10 Aug 2015 11:18:11 +0200 (CEST) Received: from ESESSMB209.ericsson.se ([169.254.9.36]) by ESESSHC011.ericsson.se ([153.88.183.51]) with mapi id 14.03.0210.002; Mon, 10 Aug 2015 11:18:11 +0200 From: Christer Holmberg To: "Hutton, Andrew" , Harald Alvestrand , "rtcweb@ietf.org" Thread-Topic: [rtcweb] Do we have consensus on not requiring rtcp-non-mux? Thread-Index: AQHQ0VmYDqTJnTo+aUua9ybij+PWb54DH0GAgAG1cgCAACMGwA== Date: Mon, 10 Aug 2015 09:18:10 +0000 Message-ID: <7594FB04B1934943A5C02806D1A2204B348EEA9C@ESESSMB209.ericsson.se> References: <55C6FBAB.6050009@alvestrand.no> <9F33F40F6F2CD847824537F3C4E37DDF1E83584F@MCHP04MSX.global-ad.net> In-Reply-To: <9F33F40F6F2CD847824537F3C4E37DDF1E83584F@MCHP04MSX.global-ad.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [153.88.183.147] Content-Type: multipart/alternative; boundary="_000_7594FB04B1934943A5C02806D1A2204B348EEA9CESESSMB209erics_" MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFvrDLMWRmVeSWpSXmKPExsUyM+JvjW5wzolQg/fLLCy2bSi1ONbXxWax 9l87uwOzx5UJV1g9liz5yeSxvecxSwBzFJdNSmpOZllqkb5dAlfG1+XiBVvLK25MWsjYwNiT 1cXIySEhYCJxf/UaJghbTOLCvfVsILaQwFFGiWs/3SDsxYwSk56pdjFycLAJWEh0/9MGMUUE 6iW+fWcFqRAW8JT4v/QpmC0i4CXxasYFJogSJ4nnx4RBwiwCqhLXn9wDC/MK+EpMaIjpYuQC mr2DUWL95K+MIDWcAv4Sm4/fZQexGYGO+X4K4jBmAXGJW0/mQx0pILFkz3lmCFtU4uXjf6wg MyUElCSmbU2DKM+X+Lkf4jJeAUGJkzOfsExgFJmFZNIsJGWzkJRBxHUkFuz+xAZha0ssW/ia GcY+c+AxE7L4Akb2VYyixanFSbnpRkZ6qUWZycXF+Xl6eaklmxiB0XVwy2+DHYwvnzseYhTg YFTi4U04ezxUiDWxrLgy9xCjNAeLkjjvjM15oUIC6YklqdmpqQWpRfFFpTmpxYcYmTg4pRoY Z2xjjNhadIOz/Ga911X/IxsLl21Veaiw+5Yl8+NFa6okpZrXnVGd+WnWrjpGy0bPjDe1Ezse 5+mJ2a39p/R99Ym1zSKiIVk1iqKLvM2iji1JmJOynvvvssu1kU8vP0g9K/suYZHEnWbO4K3d gTeE739Kd3oz9YzUtpMO250lNft2MBi+dLrtoMRSnJFoqMVcVJwIAJRZtT+PAgAA Archived-At: Subject: Re: [rtcweb] Do we have consensus on not requiring rtcp-non-mux? X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 10 Aug 2015 09:18:17 -0000 --_000_7594FB04B1934943A5C02806D1A2204B348EEA9CESESSMB209erics_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi, As there are still people on vacation, I'd like to wait for a while before = making the decision. There are e.g. radio folks that I'd like to get some i= nput from. Regards, Christer From: rtcweb [mailto:rtcweb-bounces@ietf.org] On Behalf Of Hutton, Andrew Sent: 10. elokuuta 2015 12:11 To: Harald Alvestrand; rtcweb@ietf.org Subject: Re: [rtcweb] Do we have consensus on not requiring rtcp-non-mux? If we have consensus for #1 then I assume we need to pull the -rtp-usage- d= raft back from the RFC Editor Queue (See https://tools.ietf.org/html/draft-= ietf-rtcweb-rtp-usage-25#section-4.5 ) Andy From: rtcweb [mailto:rtcweb-bounces@ietf.org] On Behalf Of Harald Alvestran= d Sent: 09 August 2015 08:05 To: rtcweb@ietf.org Subject: Re: [rtcweb] Do we have consensus on not requiring rtcp-non-mux? I am happy to live with #1. There's a particular style of gateway (one that takes calls from WebRTC dev= ices and non-WebRTC, non-RTCP-mux devices at the same responding port) that= would have a hard time claiming WebRTC conformance under #2; not a huge ar= gument, but makes me a little more happy with #1 than #2. On 08/07/2015 11:39 PM, Peter Thatcher wrote: After lots of discussion, it appears we have three options: 1. Endpoints MAY implement rtcp-non-mux (we change the spec and can delete= the ugly code) 2. Endpoints MUST NOT implement rtcp-non-mux (we change the spec and must = delete the ugly code, and our non-compliant until we do) 3. Endpoints MUST implement rtcp-non-mux (we don't change the spec and kee= p around the ugly code) My reading of the discussion is that most people want #1 or #2, and very fe= w people still want #3. Between #1 and #2, while some people would prefer= #2, there are good reasons to just do #1, and most seem to prefer #1. Fur= ther, I'm guessing that most people who wanted #2 could live with #1. TL;DR: I think we may have rough consensus on #1, saying endpoints MAY rtc= p-non-mux (but may choose to delete all that ugly code instead). So, is everyone happy with #1? _______________________________________________ rtcweb mailing list rtcweb@ietf.org https://www.ietf.org/mailman/listinfo/rtcweb -- Surveillance is pervasive. Go Dark. --_000_7594FB04B1934943A5C02806D1A2204B348EEA9CESESSMB209erics_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi,

 = ;

As there a= re still people on vacation, I’d like to wait for a while before maki= ng the decision. There are e.g. radio folks that I’d like to get some input from.

 = ;

Regards,

 = ;

Christer

 = ;

From:= rtcweb [mailto:rtcw= eb-bounces@ietf.org] On Behalf Of Hutton, Andrew
Sent: 10. elokuuta 2015 12:11
To: Harald Alvestrand; rtcweb@ietf.org
Subject: Re: [rtcweb] Do we have consensus on not requiring rtcp-non= -mux?

 

If we have= consensus for #1 then I assume we need to pull the –rtp-usage- draft= back from the RFC Editor Queue (See https://tools.ietf.org/html/draft-ietf-rtcweb-rtp-usage-25#section-4.5 = )

 = ;

Andy<= /o:p>

 = ;

 = ;

 = ;

 = ;

From:= rtcweb [mailto:rtcweb-bounces@ietf.org] On Behalf Of Harald Alvestrand
Sent: 09 August 2015 08:05
To: rtcweb@ietf.org
Subject: Re: [rtcweb] Do we have consensus on not requiring rtcp-non= -mux?

 

I am happy to live with #1.

There's a particular style of gateway (one that takes calls from WebRTC dev= ices and non-WebRTC, non-RTCP-mux devices at the same responding port) that= would have a hard time claiming WebRTC conformance under #2; not a huge ar= gument, but makes me a little more happy with #1 than #2.

On 08/07/2015 11:39 PM, Peter Thatcher wrote:

After lots of discussion, it appears we hav= e three options:

 

1.  Endpoints MAY implement rtcp-non-m= ux (we change the spec and can delete the ugly code)

 

2.  Endpoints MUST NOT implement rtcp-= non-mux (we change the spec and must delete the ugly code, and our non-comp= liant until we do)

 

3.  Endpoints MUST implement rtcp-non-= mux (we don't change the spec and keep around the ugly code)

 

 

My reading of the discussion is that most p= eople want #1 or #2, and very few people still want #3.   Between #1 a= nd #2, while some people would prefer #2, there are good reasons to just do #1, and most seem to prefer #1.  Further, I'm guessing tha= t most people who wanted #2 could live with #1.

 

 

TL;DR:  I think we may have rough cons= ensus on #1, saying endpoints MAY rtcp-non-mux (but may choose to delete al= l that ugly code instead).  

 

 

So, is everyone happy with #1?

 

 

 

= 

_______________________________________________
rtcweb mailing list
rtcweb@ietf.or=
g
https://www.ietf.org/mailman/listinfo/rtcweb<=
/pre>

= 

-- 
Surveillance is pervasive. Go Dark.
--_000_7594FB04B1934943A5C02806D1A2204B348EEA9CESESSMB209erics_-- From nobody Mon Aug 10 03:43:41 2015 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 19E821A005A for ; Mon, 10 Aug 2015 03:43:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=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 IYRP3F3YWE0C for ; Mon, 10 Aug 2015 03:43:37 -0700 (PDT) Received: from haggis.mythic-beasts.com (haggis.mythic-beasts.com [IPv6:2a00:1098:0:86:1000:0:2:1]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5098C1A0045 for ; Mon, 10 Aug 2015 03:43:37 -0700 (PDT) Received: from [130.209.247.112] (port=61270 helo=mangole.dcs.gla.ac.uk) by haggis.mythic-beasts.com with esmtpsa (TLS1.0:RSA_AES_128_CBC_SHA1:128) (Exim 4.80) (envelope-from ) id 1ZOkYI-0003Br-7w; Mon, 10 Aug 2015 11:43:35 +0100 Content-Type: multipart/alternative; boundary="Apple-Mail=_08D6D508-D59E-4E06-A59C-426C49F9DF4C" Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) From: Colin Perkins In-Reply-To: <9F33F40F6F2CD847824537F3C4E37DDF1E83584F@MCHP04MSX.global-ad.net> Date: Mon, 10 Aug 2015 11:43:43 +0100 Message-Id: References: <55C6FBAB.6050009@alvestrand.no> <9F33F40F6F2CD847824537F3C4E37DDF1E83584F@MCHP04MSX.global-ad.net> To: "Hutton, Andrew" X-Mailer: Apple Mail (2.1878.6) X-BlackCat-Spam-Score: -28 X-Mythic-Debug: Threshold = On = Archived-At: Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] Do we have consensus on not requiring rtcp-non-mux? X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 10 Aug 2015 10:43:40 -0000 --Apple-Mail=_08D6D508-D59E-4E06-A59C-426C49F9DF4C Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 We might be able to make the edits in AUTH48, with AD approval, rather = than pull the draft back from the RFC Editor, but those are process = steps we'll figure out.=20 What I'd most like to understand is the exact text change that is being = proposed for the rtp-usage draft. Can someone state what is believed to = be the consensus? Colin On 10 Aug 2015, at 10:10, Hutton, Andrew = wrote: > If we have consensus for #1 then I assume we need to pull the = =96rtp-usage- draft back from the RFC Editor Queue (See = https://tools.ietf.org/html/draft-ietf-rtcweb-rtp-usage-25#section-4.5 ) > =20 > Andy > =20 > =20 > =20 > =20 > From: rtcweb [mailto:rtcweb-bounces@ietf.org] On Behalf Of Harald = Alvestrand > Sent: 09 August 2015 08:05 > To: rtcweb@ietf.org > Subject: Re: [rtcweb] Do we have consensus on not requiring = rtcp-non-mux? > =20 > I am happy to live with #1. >=20 > There's a particular style of gateway (one that takes calls from = WebRTC devices and non-WebRTC, non-RTCP-mux devices at the same = responding port) that would have a hard time claiming WebRTC conformance = under #2; not a huge argument, but makes me a little more happy with #1 = than #2. >=20 > On 08/07/2015 11:39 PM, Peter Thatcher wrote: > After lots of discussion, it appears we have three options: > =20 > 1. Endpoints MAY implement rtcp-non-mux (we change the spec and can = delete the ugly code) > =20 > 2. Endpoints MUST NOT implement rtcp-non-mux (we change the spec and = must delete the ugly code, and our non-compliant until we do) > =20 > 3. Endpoints MUST implement rtcp-non-mux (we don't change the spec = and keep around the ugly code) > =20 > =20 > My reading of the discussion is that most people want #1 or #2, and = very few people still want #3. Between #1 and #2, while some people = would prefer #2, there are good reasons to just do #1, and most seem to = prefer #1. Further, I'm guessing that most people who wanted #2 could = live with #1. > =20 > =20 > TL;DR: I think we may have rough consensus on #1, saying endpoints = MAY rtcp-non-mux (but may choose to delete all that ugly code instead). =20= > =20 > =20 > So, is everyone happy with #1? > =20 > =20 > =20 >=20 >=20 >=20 > _______________________________________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/listinfo/rtcweb >=20 >=20 >=20 > --=20 > Surveillance is pervasive. Go Dark. > _______________________________________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/listinfo/rtcweb --=20 Colin Perkins https://csperkins.org/ --Apple-Mail=_08D6D508-D59E-4E06-A59C-426C49F9DF4C Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=windows-1252
We might be able to make the edits in AUTH48, = with AD approval, rather than pull the draft back from the RFC Editor, = but those are process steps we'll figure = out. 

What I'd most like to understand is = the exact text change that is being proposed for the rtp-usage draft. = Can someone state what is believed to be the = consensus?

Colin




On 10 Aug 2015, at 10:10, Hutton, Andrew = <andrew.hutton@unify.com> = wrote:

If we have consensus for #1 then I assume we need = to pull the =96rtp-usage- draft back from the RFC Editor Queue (See = https://tools.ietf.org/html/draft-ietf-rtcweb-rtp-usage-25#section-4.5= )

 

Andy

 

 

 

 

From: rtcweb [mailto:rtcweb-bounces@ietf.org= ] On Behalf Of Harald Alvestrand
Sent: 09 August 2015 08:05
To: rtcweb@ietf.org
Subject: Re: [rtcweb] Do we have consensus on not requiring = rtcp-non-mux?

 

I am happy to live with #1.

There's a particular style of gateway (one that takes calls from WebRTC = devices and non-WebRTC, non-RTCP-mux devices at the same responding = port) that would have a hard time claiming WebRTC conformance under #2; = not a huge argument, but makes me a little more happy with #1 than #2.

On 08/07/2015 11:39 PM, Peter Thatcher wrote:

After = lots of discussion, it appears we have three = options:

 

1.  = Endpoints MAY implement rtcp-non-mux (we change the spec and can delete = the ugly code)

 

2.  = Endpoints MUST NOT implement rtcp-non-mux (we change the spec and must = delete the ugly code, and our non-compliant until we = do)

 

3.  = Endpoints MUST implement rtcp-non-mux (we don't change the spec and keep = around the ugly code)

 

 

My = reading of the discussion is that most people want #1 or #2, and very = few people still want #3.   Between #1 and #2, while some people = would prefer #2, there are good reasons to just do #1, and most seem to prefer #1.  Further, I'm guessing that most = people who wanted #2 could live with #1.

 

 

TL;DR: =  I think we may have rough consensus on #1, saying endpoints MAY = rtcp-non-mux (but may choose to delete all that ugly code instead). =  

 

 

So, is = everyone happy with #1?

 

 

 




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




-- 
Surveillance is pervasive. Go Dark.
_______________________________________________
rtcweb mailing = list
rtcweb@ietf.org
https://www.ietf.or= g/mailman/listinfo/rtcweb



-- 
Colin Perkins

<= /div>


= --Apple-Mail=_08D6D508-D59E-4E06-A59C-426C49F9DF4C-- From nobody Mon Aug 10 04:29:10 2015 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6F5DA1ACD14 for ; Mon, 10 Aug 2015 04:29:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.91 X-Spam-Level: X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JT7XtCfa_zgl for ; Mon, 10 Aug 2015 04:29:07 -0700 (PDT) Received: from mork.alvestrand.no (mork.alvestrand.no [IPv6:2001:700:1:2::117]) by ietfa.amsl.com (Postfix) with ESMTP id CC9B41ACCE4 for ; Mon, 10 Aug 2015 04:29:04 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mork.alvestrand.no (Postfix) with ESMTP id 0A6B07C53F2; Mon, 10 Aug 2015 13:29:04 +0200 (CEST) X-Virus-Scanned: Debian amavisd-new at alvestrand.no Received: from mork.alvestrand.no ([127.0.0.1]) by localhost (mork.alvestrand.no [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WzSYSdBrSiLz; Mon, 10 Aug 2015 13:29:03 +0200 (CEST) Received: from [IPv6:2001:470:de0a:27:b1be:b4a3:ec58:4864] (unknown [IPv6:2001:470:de0a:27:b1be:b4a3:ec58:4864]) by mork.alvestrand.no (Postfix) with ESMTPSA id 052207C53F0; Mon, 10 Aug 2015 13:29:02 +0200 (CEST) Message-ID: <55C88AFE.1020204@alvestrand.no> Date: Mon, 10 Aug 2015 13:29:02 +0200 From: Harald Alvestrand User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.8.0 MIME-Version: 1.0 To: Colin Perkins , "Hutton, Andrew" References: <55C6FBAB.6050009@alvestrand.no> <9F33F40F6F2CD847824537F3C4E37DDF1E83584F@MCHP04MSX.global-ad.net> In-Reply-To: Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit Archived-At: Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] Do we have consensus on not requiring rtcp-non-mux? X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 10 Aug 2015 11:29:08 -0000 Den 10. aug. 2015 12:43, skrev Colin Perkins: > We might be able to make the edits in AUTH48, with AD approval, rather > than pull the draft back from the RFC Editor, but those are process > steps we'll figure out. > > What I'd most like to understand is the exact text change that is being > proposed for the rtp-usage draft. Can someone state what is believed to > be the consensus? This sentence (4.5) needs to be deleted for all variants proposed: For backwards compatibility, implementations are also REQUIRED to support RTP and RTCP sent on separate transport-layer flows. I *think* that my favorite solution, #1, can replace it with Implementations MAY support RTP and RTCP sent on separate transport-layer flows. They MAY also refuse to do so, in which case any negotiation that results in multiplexing not being negotiated is treated as a failure. This is based on the theory that "failure is always an option", which saves us from adding extra protocol machinery to deal with this case. From nobody Mon Aug 10 06:05:01 2015 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 99B4C1B3510 for ; Mon, 10 Aug 2015 06:05:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.601 X-Spam-Level: X-Spam-Status: No, score=-2.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id d3Vnde9113P8 for ; Mon, 10 Aug 2015 06:04:59 -0700 (PDT) Received: from mail-qg0-f42.google.com (mail-qg0-f42.google.com [209.85.192.42]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 483511B350C for ; Mon, 10 Aug 2015 06:04:59 -0700 (PDT) Received: by qgdd90 with SMTP id d90so15539024qgd.3 for ; Mon, 10 Aug 2015 06:04:58 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:message-id:date:from:user-agent:mime-version:to :cc:subject:references:in-reply-to:content-type :content-transfer-encoding; bh=nHlEk2M0OfoBtPtURbey2YAtIPB0omgbFPmTxbVZPnI=; b=gXaAjooY4UDzI3X2cuXDjfS8sZCIvtTVljcMfWjUV131knLeG+sXk6uZBaeLVyeq4R RRJ+2Jy/CFvjZWGzf5sgQZ51/cewf2HaLbIhM+lbdWGDRizaK6UCW/neyslZYb3wRyKB XSGIXcEOisr1m693lqMg0fngrXKuPO1w6iobg1bRJU3hnvLVN/jQaHusVQVugl3js/vY /7h85C07uygexF25Jati7JM4FBX9t6BxERTDhMRDPZNWpYUC5vnPRv8U3fCXdGrSEyKA GY+9mkJAnhJ07Sud4aiJ4plAQw0uFerzP0Q45dKSx2U1+OYb83NuRSD5CDAs7UBBcnlf 8L0g== X-Gm-Message-State: ALoCoQkzpML1dL2pMEjVLfH4M36tRdTjv0HES3M9sbJkIYXrarEUW87Mi2Z8BGfYO9Ickl6DKZcW X-Received: by 10.140.201.66 with SMTP id w63mr40151063qha.36.1439211898361; Mon, 10 Aug 2015 06:04:58 -0700 (PDT) Received: from ?IPv6:2607:fa48:6eca:f820:21b3:8d73:a030:10d7? ([2607:fa48:6eca:f820:21b3:8d73:a030:10d7]) by smtp.googlemail.com with ESMTPSA id 67sm3783957qhs.8.2015.08.10.06.04.57 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 10 Aug 2015 06:04:57 -0700 (PDT) Message-ID: <55C8A175.7080703@jive.com> Date: Mon, 10 Aug 2015 09:04:53 -0400 From: Simon Perreault User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:31.0) Gecko/20100101 Thunderbird/31.7.0 MIME-Version: 1.0 To: Harald Alvestrand , Colin Perkins , "Hutton, Andrew" References: <55C6FBAB.6050009@alvestrand.no> <9F33F40F6F2CD847824537F3C4E37DDF1E83584F@MCHP04MSX.global-ad.net> <55C88AFE.1020204@alvestrand.no> In-Reply-To: <55C88AFE.1020204@alvestrand.no> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 8bit Archived-At: Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] Do we have consensus on not requiring rtcp-non-mux? X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 10 Aug 2015 13:05:00 -0000 Le 2015-08-10 07:29, Harald Alvestrand a crit : > This sentence (4.5) needs to be deleted for all variants proposed: > > For > backwards compatibility, implementations are also REQUIRED to support > RTP and RTCP sent on separate transport-layer flows. > > I *think* that my favorite solution, #1, can replace it with > > Implementations MAY support > RTP and RTCP sent on separate transport-layer flows. They MAY also > refuse to do so, in which case any negotiation that results in > multiplexing not being negotiated is treated as a failure. > > This is based on the theory that "failure is always an option", which > saves us from adding extra protocol machinery to deal with this case. +1 Simon From nobody Mon Aug 10 06:33:44 2015 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 669071B356E for ; Mon, 10 Aug 2015 06:33:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XZhrgXZIrOr1 for ; Mon, 10 Aug 2015 06:33:40 -0700 (PDT) Received: from mail-wi0-x22a.google.com (mail-wi0-x22a.google.com [IPv6:2a00:1450: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 6AEF31B3572 for ; Mon, 10 Aug 2015 06:33:40 -0700 (PDT) Received: by wicja10 with SMTP id ja10so25931364wic.1 for ; Mon, 10 Aug 2015 06:33:39 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type; bh=8wvkvSSS1M3uwooh2Z2mG2Y3B77NaVihXsvfHWixGfg=; b=mptMiQrBMoWMamx3ubeF4kvg4jl1pCVL+7fS5jZzO/ryZYUnIQW6H0fc/t0+JhfhR5 g4ruSkFFoXdhxdtkNSklp1yji7zoGhRJJpV9bVfgAQQ7GOHCJdXQs8yBT3nXAuyeatyj uduygX4cR8qlJGo2F+v5arvXJHYItJownpBF73bj4ZcTlTqmRWCSTyLnY+Td+U6B974Z OhVXN/R05YXy8Gmkk00YYYnwHik9GOpbfSp15gYhIh9x8JErwrWVmhts3PJCvxphWfuJ LfJHpEVRDeVohE3mmPcyk3ucstL6MlmA2OH9qHgU4169Xk9OnFl6hB/qa5/KzVapUZK+ yX5Q== MIME-Version: 1.0 X-Received: by 10.180.90.65 with SMTP id bu1mr25234094wib.0.1439213618969; Mon, 10 Aug 2015 06:33:38 -0700 (PDT) Received: by 10.28.20.132 with HTTP; Mon, 10 Aug 2015 06:33:38 -0700 (PDT) In-Reply-To: References: Date: Mon, 10 Aug 2015 15:33:38 +0200 Message-ID: From: Victor Pascual Avila To: "" Content-Type: multipart/alternative; boundary=f46d043bdf5a83c4a0051cf5088c Archived-At: Subject: Re: [rtcweb] Do we have consensus on not requiring rtcp-non-mux? X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 10 Aug 2015 13:33:42 -0000 --f46d043bdf5a83c4a0051cf5088c Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable +1 On Sat, Aug 8, 2015 at 12:26 AM, Eric Rescorla wrote: > #1 is fine with me. > > -Ekr > > > On Fri, Aug 7, 2015 at 3:19 PM, Martin Thomson > wrote: > >> Yes, #1. It might be bad to choose #2 and immediately invalidate >> every implementation that is currently compliant. >> >> On 7 August 2015 at 14:39, Peter Thatcher wrote: >> > After lots of discussion, it appears we have three options: >> > >> > 1. Endpoints MAY implement rtcp-non-mux (we change the spec and can >> delete >> > the ugly code) >> > >> > 2. Endpoints MUST NOT implement rtcp-non-mux (we change the spec and >> must >> > delete the ugly code, and our non-compliant until we do) >> > >> > 3. Endpoints MUST implement rtcp-non-mux (we don't change the spec an= d >> keep >> > around the ugly code) >> > >> > >> > My reading of the discussion is that most people want #1 or #2, and >> very few >> > people still want #3. Between #1 and #2, while some people would >> prefer >> > #2, there are good reasons to just do #1, and most seem to prefer #1. >> > Further, I'm guessing that most people who wanted #2 could live with #= 1. >> > >> > >> > TL;DR: I think we may have rough consensus on #1, saying endpoints MA= Y >> > rtcp-non-mux (but may choose to delete all that ugly code instead). >> > >> > >> > So, is everyone happy with #1? >> > >> > >> > >> > >> > _______________________________________________ >> > rtcweb mailing list >> > rtcweb@ietf.org >> > https://www.ietf.org/mailman/listinfo/rtcweb >> > >> >> _______________________________________________ >> rtcweb mailing list >> rtcweb@ietf.org >> https://www.ietf.org/mailman/listinfo/rtcweb >> > > > _______________________________________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/listinfo/rtcweb > > --=20 Victor Pascual =C3=81vila --f46d043bdf5a83c4a0051cf5088c Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
+1

On Sat, Aug 8, 2015 at 12:26 AM, Eric Rescorla <= ekr@rtfm.com> wrote:
#1 is fine wit= h me.

-Ekr


On Fri, Aug 7, 2015 at 3:19 PM, Martin Thomson <martin.thomson@= gmail.com> wrote:
Yes, #1.= =C2=A0 It might be bad to choose #2 and immediately invalidate
every implementation that is currently compliant.

On 7 August 2015 at 14:39, Peter Thatcher <pthatcher@google.com> wrote:
> After lots of discussion, it appears we have three options:
>
> 1.=C2=A0 Endpoints MAY implement rtcp-non-mux (we change the spec and = can delete
> the ugly code)
>
> 2.=C2=A0 Endpoints MUST NOT implement rtcp-non-mux (we change the spec= and must
> delete the ugly code, and our non-compliant until we do)
>
> 3.=C2=A0 Endpoints MUST implement rtcp-non-mux (we don't change th= e spec and keep
> around the ugly code)
>
>
> My reading of the discussion is that most people want #1 or #2, and ve= ry few
> people still want #3.=C2=A0 =C2=A0Between #1 and #2, while some people= would prefer
> #2, there are good reasons to just do #1, and most seem to prefer #1.<= br> > Further, I'm guessing that most people who wanted #2 could live wi= th #1.
>
>
> TL;DR:=C2=A0 I think we may have rough consensus on #1, saying endpoin= ts MAY
> rtcp-non-mux (but may choose to delete all that ugly code instead). >
>
> So, is everyone happy with #1?
>
>
>
>
> _______________________________________________
> rtcweb mailing list
> rtcweb@ietf.org
> https://www.ietf.org/mailman/listinfo/rtcweb >

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


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




--
Victor Pascual =C3=81vila
--f46d043bdf5a83c4a0051cf5088c-- From nobody Mon Aug 10 06:39:48 2015 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C09611B358B for ; Mon, 10 Aug 2015 06:39:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.901 X-Spam-Level: X-Spam-Status: No, score=-3.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mZ5WXMnMt8jZ for ; Mon, 10 Aug 2015 06:39:45 -0700 (PDT) Received: from sessmg22.ericsson.net (sessmg22.ericsson.net [193.180.251.58]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 89AD71B358A for ; Mon, 10 Aug 2015 06:39:43 -0700 (PDT) X-AuditID: c1b4fb3a-f79356d000006281-e1-55c8a99d3d42 Received: from ESESSHC006.ericsson.se (Unknown_Domain [153.88.253.124]) by sessmg22.ericsson.net (Symantec Mail Security) with SMTP id B7.99.25217.D99A8C55; Mon, 10 Aug 2015 15:39:42 +0200 (CEST) Received: from ESESSMB209.ericsson.se ([169.254.9.36]) by ESESSHC006.ericsson.se ([153.88.183.36]) with mapi id 14.03.0210.002; Mon, 10 Aug 2015 15:39:41 +0200 From: =?utf-8?B?R8O2cmFuIEVyaWtzc29uIEFQ?= To: Christer Holmberg , "Hutton, Andrew" , Harald Alvestrand , "rtcweb@ietf.org" Thread-Topic: [rtcweb] Do we have consensus on not requiring rtcp-non-mux? Thread-Index: AQHQ0VmYb2xhCwP+WUWJ+cOxaDFvi54DH0GAgAG1cgCAAAIFAIAAapmA Date: Mon, 10 Aug 2015 13:39:40 +0000 Message-ID: References: <55C6FBAB.6050009@alvestrand.no> <9F33F40F6F2CD847824537F3C4E37DDF1E83584F@MCHP04MSX.global-ad.net> <7594FB04B1934943A5C02806D1A2204B348EEA9C@ESESSMB209.ericsson.se> In-Reply-To: <7594FB04B1934943A5C02806D1A2204B348EEA9C@ESESSMB209.ericsson.se> Accept-Language: sv-SE, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.5.3.150624 x-originating-ip: [153.88.183.146] Content-Type: text/plain; charset="utf-8" Content-ID: <3AA8D391CA100940BB9A44A570D9B1B2@ericsson.com> Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFupjkeLIzCtJLcpLzFFi42KZGfG3RnfeyhOhBq27+Sy2bSi1ONbXxWax 9l87uwOzx5UJV1g9liz5yeSxvecxSwBzFJdNSmpOZllqkb5dAldGw9IZzAWbFCvO7TrC1sB4 RKGLkYNDQsBE4tCssi5GTiBTTOLCvfVsXYxcHEICRxkltj3bxgLhLGaUmN/6gRGkik3AW6Kt 5TBYQkRgK6PEkrcLWEASwgKeErcX7mYHsUUEvCRezbjABGG7Sbyd/IINxGYRUJXYdOgMmM0r YC1x9MI/qA1/GCVmrZ4GNohTwE9i7envYEWMArIS97/fA4szC4hL3HoynwniVgGJJXvOM0PY ohIvH/9jBbFFBfQkPp34yAIRV5L4seESC8ibzAKaEut36UOMsZbY/ryLDcJWlJjS/ZAd4h5B iZMzn7BMYBSfhWTbLITuWUi6ZyHpnoWkewEj6ypG0eLU4uLcdCMjvdSizOTi4vw8vbzUkk2M wAg8uOW31Q7Gg88dDzEKcDAq8fAmnD0eKsSaWFZcmXuIUZqDRUmcd8bmvFAhgfTEktTs1NSC 1KL4otKc1OJDjEwcnFINjOYL/hp4Vcebnhaz9lnbHKWz7v0lL5VNTyfcWBK64GxrmsrOmIRy k48MgtXr/+Q8nhOx4cPGsKM87kLP3jFrr6mdYSNgd37iuQ6h7xlLk8Sas/2mrp0WOu3Lh7ud LXeOJf3eKpKh9XHtwRnVkzvdNl6dLP2g+9p7rSDmH7uPH0kqnvmrdc62gy1KLMUZiYZazEXF iQBC/yG/oQIAAA== Archived-At: Subject: Re: [rtcweb] Do we have consensus on not requiring rtcp-non-mux? X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 10 Aug 2015 13:39:46 -0000 UGVyc29uYWwgb3BpbmlvbjoNCg0KTWlnaHQgYmUgYW4gaXNzdWUgZm9yIGxvdy1iaXRyYXRlIGF1 ZGlvIHVzZSBjYXNlcyBpbiB3aXJlbGVzcyBuZXR3b3Jrcy4gSQ0KY2FuIGltYWdpbmUgc2NlbmFy aW9zIHdoZXJlIHRoZSBydHAgYW5kIHJ0Y3AgcGFja2V0cyBhcmUgYmVzdCBjYXJyaWVkIG9uDQpk aWZmZXJlbnQgcmFkaW8gYmVhcmVycywgd2hpY2ggaXMgdHJpY2t5IG9mIHRoZXkgYXJlIG11bHRp cGxleGVkIG9udG8gdGhlDQpzYW1lIDUtdHVwbGUgKGFuZCBJIGFtIG5vdCBzdXJlIEkgZGFyZSBy ZWx5IG9uIERTIG1hcmtpbmcgdG8gc29sdmUgdGhpcykuDQpJIGRvIG5vdCBoYXZlIG1vcmUgZGF0 YSBpbiB0aGUgYWN0dWFsIGltcGFjdCBlYXNpbHkgYXQgaGFuZC4NCg0KU2luY2UgbG93LWJpdHJh dGUgYXVkaW8gdXNlIGNhc2VzLCBlLmcuIFJUQ1dlYi0yLVJUQ1dlYiwgaGFzIG5vdCBiZWVuIGEN CnByaW9yaXRpc2VkIGNhdGVnb3J5IGluIFdlYlJUQzEuMCwgcGVyaGFwcyBpdCBpcyBPSyB3aXRo ICMxIChpbiB0aGUgUlRDV2ViDQpzdGFjayBXZWJSVEMxLjAgQVBJKS4NCg0KUmVnYXJkcw0KR8O2 cmFuDQoNCg0KPkhpLA0KPiANCj5BcyB0aGVyZSBhcmUgc3RpbGwgcGVvcGxlIG9uIHZhY2F0aW9u LCBJ4oCZZCBsaWtlIHRvIHdhaXQgZm9yIGEgd2hpbGUNCj5iZWZvcmUgbWFraW5nIHRoZSBkZWNp c2lvbi4gVGhlcmUgYXJlIGUuZy4gcmFkaW8gZm9sa3MgdGhhdCBJ4oCZZCBsaWtlIHRvDQo+Z2V0 DQo+IHNvbWUgaW5wdXQgZnJvbS4NCj4gDQo+UmVnYXJkcywNCj4gDQo+Q2hyaXN0ZXINCj4gDQo+ RnJvbTogcnRjd2ViIFttYWlsdG86cnRjd2ViLWJvdW5jZXNAaWV0Zi5vcmddDQo+T24gQmVoYWxm IE9mIEh1dHRvbiwgQW5kcmV3DQo+U2VudDogMTAuIGVsb2t1dXRhIDIwMTUgMTI6MTENCj5Ubzog SGFyYWxkIEFsdmVzdHJhbmQ7IHJ0Y3dlYkBpZXRmLm9yZw0KPlN1YmplY3Q6IFJlOiBbcnRjd2Vi XSBEbyB3ZSBoYXZlIGNvbnNlbnN1cyBvbiBub3QgcmVxdWlyaW5nIHJ0Y3Atbm9uLW11eD8NCj4N Cj4NCj4gDQo+SWYgd2UgaGF2ZSBjb25zZW5zdXMgZm9yICMxIHRoZW4gSSBhc3N1bWUgd2UgbmVl ZCB0byBwdWxsIHRoZSDigJNydHAtdXNhZ2UtDQo+ZHJhZnQgYmFjayBmcm9tIHRoZSBSRkMgRWRp dG9yIFF1ZXVlIChTZWUNCj4NCj5odHRwczovL3Rvb2xzLmlldGYub3JnL2h0bWwvZHJhZnQtaWV0 Zi1ydGN3ZWItcnRwLXVzYWdlLTI1I3NlY3Rpb24tNC41DQo+PGh0dHBzOi8vdG9vbHMuaWV0Zi5v cmcvaHRtbC9kcmFmdC1pZXRmLXJ0Y3dlYi1ydHAtdXNhZ2UtMjUjc2VjdGlvbi00LjU+ICkNCj4g DQo+QW5keQ0KPiANCj4gDQo+IA0KPiANCj5Gcm9tOiBydGN3ZWIgW21haWx0bzpydGN3ZWItYm91 bmNlc0BpZXRmLm9yZ10NCj5PbiBCZWhhbGYgT2YgSGFyYWxkIEFsdmVzdHJhbmQNCj5TZW50OiAw OSBBdWd1c3QgMjAxNSAwODowNQ0KPlRvOiBydGN3ZWJAaWV0Zi5vcmcNCj5TdWJqZWN0OiBSZTog W3J0Y3dlYl0gRG8gd2UgaGF2ZSBjb25zZW5zdXMgb24gbm90IHJlcXVpcmluZyBydGNwLW5vbi1t dXg/DQo+DQo+DQo+IA0KPkkgYW0gaGFwcHkgdG8gbGl2ZSB3aXRoICMxLg0KPg0KPlRoZXJlJ3Mg YSBwYXJ0aWN1bGFyIHN0eWxlIG9mIGdhdGV3YXkgKG9uZSB0aGF0IHRha2VzIGNhbGxzIGZyb20g V2ViUlRDDQo+ZGV2aWNlcyBhbmQgbm9uLVdlYlJUQywgbm9uLVJUQ1AtbXV4IGRldmljZXMgYXQg dGhlIHNhbWUgcmVzcG9uZGluZyBwb3J0KQ0KPnRoYXQgd291bGQgaGF2ZSBhIGhhcmQgdGltZSBj bGFpbWluZyBXZWJSVEMgY29uZm9ybWFuY2UgdW5kZXIgIzI7IG5vdCBhDQo+aHVnZSBhcmd1bWVu dCwgYnV0IG1ha2VzIG1lIGEgbGl0dGxlIG1vcmUNCj4gaGFwcHkgd2l0aCAjMSB0aGFuICMyLg0K Pg0KPk9uIDA4LzA3LzIwMTUgMTE6MzkgUE0sIFBldGVyIFRoYXRjaGVyIHdyb3RlOg0KPg0KPg0K PkFmdGVyIGxvdHMgb2YgZGlzY3Vzc2lvbiwgaXQgYXBwZWFycyB3ZSBoYXZlIHRocmVlIG9wdGlv bnM6DQo+DQo+IA0KPg0KPjEuICBFbmRwb2ludHMgTUFZIGltcGxlbWVudCBydGNwLW5vbi1tdXgg KHdlIGNoYW5nZSB0aGUgc3BlYyBhbmQgY2FuDQo+ZGVsZXRlIHRoZSB1Z2x5IGNvZGUpDQo+DQo+ IA0KPg0KPjIuICBFbmRwb2ludHMgTVVTVCBOT1QgaW1wbGVtZW50IHJ0Y3Atbm9uLW11eCAod2Ug Y2hhbmdlIHRoZSBzcGVjIGFuZA0KPm11c3QgZGVsZXRlIHRoZSB1Z2x5IGNvZGUsIGFuZCBvdXIg bm9uLWNvbXBsaWFudCB1bnRpbCB3ZSBkbykNCj4NCj4gDQo+DQo+My4gIEVuZHBvaW50cyBNVVNU IGltcGxlbWVudCBydGNwLW5vbi1tdXggKHdlIGRvbid0IGNoYW5nZSB0aGUgc3BlYyBhbmQNCj5r ZWVwIGFyb3VuZCB0aGUgdWdseSBjb2RlKQ0KPg0KPiANCj4NCj4gDQo+DQo+TXkgcmVhZGluZyBv ZiB0aGUgZGlzY3Vzc2lvbiBpcyB0aGF0IG1vc3QgcGVvcGxlIHdhbnQgIzEgb3IgIzIsIGFuZCB2 ZXJ5DQo+ZmV3IHBlb3BsZSBzdGlsbCB3YW50ICMzLiAgIEJldHdlZW4gIzEgYW5kICMyLCB3aGls ZSBzb21lIHBlb3BsZSB3b3VsZA0KPnByZWZlciAjMiwgdGhlcmUgYXJlIGdvb2QgcmVhc29ucw0K PiB0byBqdXN0IGRvICMxLCBhbmQgbW9zdCBzZWVtIHRvIHByZWZlciAjMS4gIEZ1cnRoZXIsIEkn bSBndWVzc2luZyB0aGF0DQo+bW9zdCBwZW9wbGUgd2hvIHdhbnRlZCAjMiBjb3VsZCBsaXZlIHdp dGggIzEuDQo+DQo+IA0KPg0KPiANCj4NCj5UTDtEUjogIEkgdGhpbmsgd2UgbWF5IGhhdmUgcm91 Z2ggY29uc2Vuc3VzIG9uICMxLCBzYXlpbmcgZW5kcG9pbnRzIE1BWQ0KPnJ0Y3Atbm9uLW11eCAo YnV0IG1heSBjaG9vc2UgdG8gZGVsZXRlIGFsbCB0aGF0IHVnbHkgY29kZSBpbnN0ZWFkKS4NCj4N Cj4gDQo+DQo+IA0KPg0KPlNvLCBpcyBldmVyeW9uZSBoYXBweSB3aXRoICMxPw0KPg0KPiANCj4N Cj4gDQo+DQo+IA0KPg0KPg0KPg0KPg0KPg0KPl9fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fcnRjd2ViIG1haWxpbmcNCj5saXN0cnRjd2ViQGlldGYub3JnaHR0 cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9ydGN3ZWINCj4NCj4NCj4NCj4NCj4t LSBTdXJ2ZWlsbGFuY2UgaXMgcGVydmFzaXZlLiBHbyBEYXJrLg0KPg0KDQo= From nobody Mon Aug 10 07:46:20 2015 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B325F1A039D for ; Mon, 10 Aug 2015 07:46:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.496 X-Spam-Level: X-Spam-Status: No, score=-1.496 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, IP_NOT_FRIENDLY=0.334, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_SORBS_WEB=0.77, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8QcGJJloCitR for ; Mon, 10 Aug 2015 07:46:17 -0700 (PDT) Received: from mx0b-00198e01.pphosted.com (mx0b-00198e01.pphosted.com [67.231.157.197]) (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 6FC2D1B366C for ; Mon, 10 Aug 2015 07:45:48 -0700 (PDT) Received: from pps.filterd (m0073110.ppops.net [127.0.0.1]) by mx0b-00198e01.pphosted.com (8.15.0.59/8.14.7) with SMTP id t7AEgCsH003482 for ; Mon, 10 Aug 2015 10:45:47 -0400 Received: from mail.vidyo.com ([162.209.16.214]) by mx0b-00198e01.pphosted.com with ESMTP id 1w0h0uvhkp-2 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT) for ; Mon, 10 Aug 2015 10:45:47 -0400 Received: from 492132-EXCH1.vidyo.com ([fe80::50:56ff:fe85:4f77]) by 492133-EXCH2.vidyo.com ([fe80::50:56ff:fe85:6b62%13]) with mapi id 14.03.0195.001; Mon, 10 Aug 2015 09:45:46 -0500 From: Jonathan Lennox To: Google-Peter Thatcher Thread-Topic: [rtcweb] Do we have consensus on not requiring rtcp-non-mux? Thread-Index: AQHQ03qu29AkjWHTmE6I1pAkHgCelJ4Fo2SA Date: Mon, 10 Aug 2015 14:45:45 +0000 Message-ID: <8A69E109-3F93-4C61-95F2-375FF2103EAB@vidyo.com> References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [160.79.219.114] Content-Type: multipart/alternative; boundary="_000_8A69E1093F934C6195F2375FF2103EABvidyocom_" MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:5.14.151, 1.0.33, 0.0.0000 definitions=2015-08-10_02:2015-08-10,2015-08-10,1970-01-01 signatures=0 X-Proofpoint-Spam-Details: rule=outbound_notspam policy=outbound score=0 spamscore=0 suspectscore=0 phishscore=0 adultscore=0 bulkscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=7.0.1-1506180000 definitions=main-1508100221 Archived-At: Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] Do we have consensus on not requiring rtcp-non-mux? X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 10 Aug 2015 14:46:18 -0000 --_000_8A69E1093F934C6195F2375FF2103EABvidyocom_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 IzEgc2VlbXMgYmVzdCB0byBtZSwgYnV0IHRoZXJlIG5lZWRzIHRvIGJlIHNvbWUgd2VsbC1zcGVj aWZpZWQgd2F5IGZvciBKUyBhcHBsaWNhdGlvbnMgYW5kIG9mZmVyL2Fuc3dlciBwZWVycyB0byBk aXNjb3Zlci91bmRlcnN0YW5kIHdoZXRoZXIgcnRjcC1ub24tbXV4IGlzIGluZGVlZCBzdXBwb3J0 ZWQuICBPdGhlcndpc2UgdGhlcmXigJlzIG5vIHByYWN0aWNhbCBkaWZmZXJlbmNlIGJldHdlZW4g IzEgYW5kICMyLg0KDQpPbiBBdWcgNywgMjAxNSwgYXQgNTozOSBQTSwgUGV0ZXIgVGhhdGNoZXIg PHB0aGF0Y2hlckBnb29nbGUuY29tPG1haWx0bzpwdGhhdGNoZXJAZ29vZ2xlLmNvbT4+IHdyb3Rl Og0KDQpBZnRlciBsb3RzIG9mIGRpc2N1c3Npb24sIGl0IGFwcGVhcnMgd2UgaGF2ZSB0aHJlZSBv cHRpb25zOg0KDQoxLiAgRW5kcG9pbnRzIE1BWSBpbXBsZW1lbnQgcnRjcC1ub24tbXV4ICh3ZSBj aGFuZ2UgdGhlIHNwZWMgYW5kIGNhbiBkZWxldGUgdGhlIHVnbHkgY29kZSkNCg0KMi4gIEVuZHBv aW50cyBNVVNUIE5PVCBpbXBsZW1lbnQgcnRjcC1ub24tbXV4ICh3ZSBjaGFuZ2UgdGhlIHNwZWMg YW5kIG11c3QgZGVsZXRlIHRoZSB1Z2x5IGNvZGUsIGFuZCBvdXIgbm9uLWNvbXBsaWFudCB1bnRp bCB3ZSBkbykNCg0KMy4gIEVuZHBvaW50cyBNVVNUIGltcGxlbWVudCBydGNwLW5vbi1tdXggKHdl IGRvbid0IGNoYW5nZSB0aGUgc3BlYyBhbmQga2VlcCBhcm91bmQgdGhlIHVnbHkgY29kZSkNCg0K DQpNeSByZWFkaW5nIG9mIHRoZSBkaXNjdXNzaW9uIGlzIHRoYXQgbW9zdCBwZW9wbGUgd2FudCAj MSBvciAjMiwgYW5kIHZlcnkgZmV3IHBlb3BsZSBzdGlsbCB3YW50ICMzLiAgIEJldHdlZW4gIzEg YW5kICMyLCB3aGlsZSBzb21lIHBlb3BsZSB3b3VsZCBwcmVmZXIgIzIsIHRoZXJlIGFyZSBnb29k IHJlYXNvbnMgdG8ganVzdCBkbyAjMSwgYW5kIG1vc3Qgc2VlbSB0byBwcmVmZXIgIzEuICBGdXJ0 aGVyLCBJJ20gZ3Vlc3NpbmcgdGhhdCBtb3N0IHBlb3BsZSB3aG8gd2FudGVkICMyIGNvdWxkIGxp dmUgd2l0aCAjMS4NCg0KDQpUTDtEUjogIEkgdGhpbmsgd2UgbWF5IGhhdmUgcm91Z2ggY29uc2Vu c3VzIG9uICMxLCBzYXlpbmcgZW5kcG9pbnRzIE1BWSBydGNwLW5vbi1tdXggKGJ1dCBtYXkgY2hv b3NlIHRvIGRlbGV0ZSBhbGwgdGhhdCB1Z2x5IGNvZGUgaW5zdGVhZCkuDQoNCg0KU28sIGlzIGV2 ZXJ5b25lIGhhcHB5IHdpdGggIzE/DQoNCg0KDQpfX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fXw0KcnRjd2ViIG1haWxpbmcgbGlzdA0KcnRjd2ViQGlldGYub3Jn PG1haWx0bzpydGN3ZWJAaWV0Zi5vcmc+DQpodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xp c3RpbmZvL3J0Y3dlYg0KDQo= --_000_8A69E1093F934C6195F2375FF2103EABvidyocom_ Content-Type: text/html; charset="utf-8" Content-ID: <88CD7383F51AFA419FE27F6324813D59@vidyo.com> Content-Transfer-Encoding: base64 PGh0bWw+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIgY29udGVudD0i dGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjwvaGVhZD4NCjxib2R5IHN0eWxlPSJ3b3JkLXdy YXA6IGJyZWFrLXdvcmQ7IC13ZWJraXQtbmJzcC1tb2RlOiBzcGFjZTsgLXdlYmtpdC1saW5lLWJy ZWFrOiBhZnRlci13aGl0ZS1zcGFjZTsiIGNsYXNzPSIiPg0KIzEgc2VlbXMgYmVzdCB0byBtZSwg YnV0IHRoZXJlIG5lZWRzIHRvIGJlIHNvbWUgd2VsbC1zcGVjaWZpZWQgd2F5IGZvciBKUyBhcHBs aWNhdGlvbnMgYW5kIG9mZmVyL2Fuc3dlciBwZWVycyB0byBkaXNjb3Zlci91bmRlcnN0YW5kIHdo ZXRoZXIgcnRjcC1ub24tbXV4IGlzIGluZGVlZCBzdXBwb3J0ZWQuICZuYnNwO090aGVyd2lzZSB0 aGVyZeKAmXMgbm8gcHJhY3RpY2FsIGRpZmZlcmVuY2UgYmV0d2VlbiAjMSBhbmQgIzIuPGJyIGNs YXNzPSIiPg0KPGRpdj48YnIgY2xhc3M9IiI+DQo8YmxvY2txdW90ZSB0eXBlPSJjaXRlIiBjbGFz cz0iIj4NCjxkaXYgY2xhc3M9IiI+T24gQXVnIDcsIDIwMTUsIGF0IDU6MzkgUE0sIFBldGVyIFRo YXRjaGVyICZsdDs8YSBocmVmPSJtYWlsdG86cHRoYXRjaGVyQGdvb2dsZS5jb20iIGNsYXNzPSIi PnB0aGF0Y2hlckBnb29nbGUuY29tPC9hPiZndDsgd3JvdGU6PC9kaXY+DQo8YnIgY2xhc3M9IkFw cGxlLWludGVyY2hhbmdlLW5ld2xpbmUiPg0KPGRpdiBjbGFzcz0iIj4NCjxkaXYgZGlyPSJsdHIi IGNsYXNzPSIiPg0KPGRpdiBjbGFzcz0iZ21haWxfZGVmYXVsdCIgc3R5bGU9ImZvbnQtZmFtaWx5 OmFyaWFsLGhlbHZldGljYSxzYW5zLXNlcmlmIj5BZnRlciBsb3RzIG9mIGRpc2N1c3Npb24sIGl0 IGFwcGVhcnMgd2UgaGF2ZSB0aHJlZSBvcHRpb25zOjwvZGl2Pg0KPGRpdiBjbGFzcz0iZ21haWxf ZGVmYXVsdCIgc3R5bGU9ImZvbnQtZmFtaWx5OmFyaWFsLGhlbHZldGljYSxzYW5zLXNlcmlmIj48 YnIgY2xhc3M9IiI+DQo8L2Rpdj4NCjxkaXYgY2xhc3M9ImdtYWlsX2RlZmF1bHQiIHN0eWxlPSJm b250LWZhbWlseTphcmlhbCxoZWx2ZXRpY2Esc2Fucy1zZXJpZiI+MS4mbmJzcDsgRW5kcG9pbnRz IE1BWSBpbXBsZW1lbnQgcnRjcC1ub24tbXV4ICh3ZSBjaGFuZ2UgdGhlIHNwZWMgYW5kIGNhbiBk ZWxldGUgdGhlIHVnbHkgY29kZSk8L2Rpdj4NCjxkaXYgY2xhc3M9ImdtYWlsX2RlZmF1bHQiIHN0 eWxlPSJmb250LWZhbWlseTphcmlhbCxoZWx2ZXRpY2Esc2Fucy1zZXJpZiI+PGJyIGNsYXNzPSIi Pg0KPC9kaXY+DQo8ZGl2IGNsYXNzPSJnbWFpbF9kZWZhdWx0IiBzdHlsZT0iZm9udC1mYW1pbHk6 YXJpYWwsaGVsdmV0aWNhLHNhbnMtc2VyaWYiPjIuJm5ic3A7IEVuZHBvaW50cyBNVVNUIE5PVCBp bXBsZW1lbnQgcnRjcC1ub24tbXV4ICh3ZSBjaGFuZ2UgdGhlIHNwZWMgYW5kIG11c3QgZGVsZXRl IHRoZSB1Z2x5IGNvZGUsIGFuZCBvdXIgbm9uLWNvbXBsaWFudCB1bnRpbCB3ZSBkbyk8L2Rpdj4N CjxkaXYgY2xhc3M9ImdtYWlsX2RlZmF1bHQiIHN0eWxlPSJmb250LWZhbWlseTphcmlhbCxoZWx2 ZXRpY2Esc2Fucy1zZXJpZiI+PGJyIGNsYXNzPSIiPg0KPC9kaXY+DQo8ZGl2IGNsYXNzPSJnbWFp bF9kZWZhdWx0IiBzdHlsZT0iZm9udC1mYW1pbHk6YXJpYWwsaGVsdmV0aWNhLHNhbnMtc2VyaWYi PjMuJm5ic3A7IEVuZHBvaW50cyBNVVNUIGltcGxlbWVudCBydGNwLW5vbi1tdXggKHdlIGRvbid0 IGNoYW5nZSB0aGUgc3BlYyBhbmQga2VlcCBhcm91bmQgdGhlIHVnbHkgY29kZSk8L2Rpdj4NCjxk aXYgY2xhc3M9ImdtYWlsX2RlZmF1bHQiIHN0eWxlPSJmb250LWZhbWlseTphcmlhbCxoZWx2ZXRp Y2Esc2Fucy1zZXJpZiI+PGJyIGNsYXNzPSIiPg0KPC9kaXY+DQo8ZGl2IGNsYXNzPSJnbWFpbF9k ZWZhdWx0IiBzdHlsZT0iZm9udC1mYW1pbHk6YXJpYWwsaGVsdmV0aWNhLHNhbnMtc2VyaWYiPjxi ciBjbGFzcz0iIj4NCjwvZGl2Pg0KPGRpdiBjbGFzcz0iZ21haWxfZGVmYXVsdCIgc3R5bGU9ImZv bnQtZmFtaWx5OmFyaWFsLGhlbHZldGljYSxzYW5zLXNlcmlmIj5NeSByZWFkaW5nIG9mIHRoZSBk aXNjdXNzaW9uIGlzIHRoYXQgbW9zdCBwZW9wbGUgd2FudCAjMSBvciAjMiwgYW5kIHZlcnkgZmV3 IHBlb3BsZSBzdGlsbCB3YW50ICMzLiAmbmJzcDsgQmV0d2VlbiAjMSBhbmQgIzIsIHdoaWxlIHNv bWUgcGVvcGxlIHdvdWxkIHByZWZlciAjMiwgdGhlcmUgYXJlIGdvb2QgcmVhc29ucyB0byBqdXN0 DQogZG8gIzEsIGFuZCBtb3N0IHNlZW0gdG8gcHJlZmVyICMxLiZuYnNwOyBGdXJ0aGVyLCBJJ20g Z3Vlc3NpbmcgdGhhdCBtb3N0IHBlb3BsZSB3aG8gd2FudGVkICMyIGNvdWxkIGxpdmUgd2l0aCAj MS48L2Rpdj4NCjxkaXYgY2xhc3M9ImdtYWlsX2RlZmF1bHQiIHN0eWxlPSJmb250LWZhbWlseTph cmlhbCxoZWx2ZXRpY2Esc2Fucy1zZXJpZiI+PGJyIGNsYXNzPSIiPg0KPC9kaXY+DQo8ZGl2IGNs YXNzPSJnbWFpbF9kZWZhdWx0IiBzdHlsZT0iZm9udC1mYW1pbHk6YXJpYWwsaGVsdmV0aWNhLHNh bnMtc2VyaWYiPjxiciBjbGFzcz0iIj4NCjwvZGl2Pg0KPGRpdiBjbGFzcz0iZ21haWxfZGVmYXVs dCIgc3R5bGU9ImZvbnQtZmFtaWx5OmFyaWFsLGhlbHZldGljYSxzYW5zLXNlcmlmIj5UTDtEUjog Jm5ic3A7SSB0aGluayB3ZSBtYXkgaGF2ZSByb3VnaCBjb25zZW5zdXMgb24gIzEsIHNheWluZyBl bmRwb2ludHMgTUFZIHJ0Y3Atbm9uLW11eCAoYnV0IG1heSBjaG9vc2UgdG8gZGVsZXRlIGFsbCB0 aGF0IHVnbHkgY29kZSBpbnN0ZWFkKS4gJm5ic3A7PC9kaXY+DQo8ZGl2IGNsYXNzPSJnbWFpbF9k ZWZhdWx0IiBzdHlsZT0iZm9udC1mYW1pbHk6YXJpYWwsaGVsdmV0aWNhLHNhbnMtc2VyaWYiPjxi ciBjbGFzcz0iIj4NCjwvZGl2Pg0KPGRpdiBjbGFzcz0iZ21haWxfZGVmYXVsdCIgc3R5bGU9ImZv bnQtZmFtaWx5OmFyaWFsLGhlbHZldGljYSxzYW5zLXNlcmlmIj48YnIgY2xhc3M9IiI+DQo8L2Rp dj4NCjxkaXYgY2xhc3M9ImdtYWlsX2RlZmF1bHQiIHN0eWxlPSJmb250LWZhbWlseTphcmlhbCxo ZWx2ZXRpY2Esc2Fucy1zZXJpZiI+U28sIGlzIGV2ZXJ5b25lIGhhcHB5IHdpdGggIzE/PC9kaXY+ DQo8ZGl2IGNsYXNzPSJnbWFpbF9kZWZhdWx0IiBzdHlsZT0iZm9udC1mYW1pbHk6YXJpYWwsaGVs dmV0aWNhLHNhbnMtc2VyaWYiPjxiciBjbGFzcz0iIj4NCjwvZGl2Pg0KPGRpdiBjbGFzcz0iZ21h aWxfZGVmYXVsdCIgc3R5bGU9ImZvbnQtZmFtaWx5OmFyaWFsLGhlbHZldGljYSxzYW5zLXNlcmlm Ij48YnIgY2xhc3M9IiI+DQo8L2Rpdj4NCjxkaXYgY2xhc3M9ImdtYWlsX2RlZmF1bHQiIHN0eWxl PSJmb250LWZhbWlseTphcmlhbCxoZWx2ZXRpY2Esc2Fucy1zZXJpZiI+PGJyIGNsYXNzPSIiPg0K PC9kaXY+DQo8L2Rpdj4NCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fPGJyIGNsYXNzPSIiPg0KcnRjd2ViIG1haWxpbmcgbGlzdDxiciBjbGFzcz0iIj4NCjxh IGhyZWY9Im1haWx0bzpydGN3ZWJAaWV0Zi5vcmciIGNsYXNzPSIiPnJ0Y3dlYkBpZXRmLm9yZzwv YT48YnIgY2xhc3M9IiI+DQpodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL3J0 Y3dlYjxiciBjbGFzcz0iIj4NCjwvZGl2Pg0KPC9ibG9ja3F1b3RlPg0KPC9kaXY+DQo8YnIgY2xh c3M9IiI+DQo8L2JvZHk+DQo8L2h0bWw+DQo= --_000_8A69E1093F934C6195F2375FF2103EABvidyocom_-- From nobody Mon Aug 10 08:39:40 2015 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 35EC21A8839 for ; Mon, 10 Aug 2015 08:39:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.2 X-Spam-Level: X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MKFJpveGewnP for ; Mon, 10 Aug 2015 08:39:37 -0700 (PDT) Received: from sesbmg23.ericsson.net (sesbmg23.ericsson.net [193.180.251.37]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 020F51B366E for ; Mon, 10 Aug 2015 08:39:36 -0700 (PDT) X-AuditID: c1b4fb25-f79446d000003bb1-33-55c8c5b710c4 Received: from ESESSHC004.ericsson.se (Unknown_Domain [153.88.253.124]) by sesbmg23.ericsson.net (Symantec Mail Security) with SMTP id CA.2E.15281.7B5C8C55; Mon, 10 Aug 2015 17:39:35 +0200 (CEST) Received: from ESESSMB209.ericsson.se ([169.254.9.36]) by ESESSHC004.ericsson.se ([153.88.183.30]) with mapi id 14.03.0210.002; Mon, 10 Aug 2015 17:39:34 +0200 From: Christer Holmberg To: Jonathan Lennox , Google-Peter Thatcher Thread-Topic: [rtcweb] Do we have consensus on not requiring rtcp-non-mux? Thread-Index: AQHQ0VmYDqTJnTo+aUua9ybij+PWb54FMj+AgAAwkME= Date: Mon, 10 Aug 2015 15:39:33 +0000 Message-ID: <7594FB04B1934943A5C02806D1A2204B348EF447@ESESSMB209.ericsson.se> References: , <8A69E109-3F93-4C61-95F2-375FF2103EAB@vidyo.com> In-Reply-To: <8A69E109-3F93-4C61-95F2-375FF2103EAB@vidyo.com> Accept-Language: en-US Content-Language: en-GB X-MS-Has-Attach: X-MS-TNEF-Correlator: Content-Type: multipart/alternative; boundary="_000_7594FB04B1934943A5C02806D1A2204B348EF447ESESSMB209erics_" MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFmpmkeLIzCtJLcpLzFFi42KZGfG3Rnf70ROhBhceCFrsX3ye2eLa8tes Fmv/tbM7MHss2FTqsWTJTyaPtmd32AOYo7hsUlJzMstSi/TtErgy9m7tYC44ZF3x6e5BpgbG dpMuRk4OCQETif8HfrJC2GISF+6tZ+ti5OIQEjjKKLGm7RsrhLOYUeL870eMXYwcHGwCFhLd /7RBGkQEIiTOtL5hBrGZBdQl7iw+xw5iCwt4Svxf+pQVosZL4tWMC0wQtpXEz02/wepZBFQl Vk3+wQhi8wr4Sqz+8RJqcSOjxKRdfWwgCU4BW4mVPR/BBjECXff91BomiGXiEk1fVkJdLSCx ZM95ZghbVOLl43+sEDX5Eg0L/rBALBCUODnzCcsERpFZSNpnISmbhaQMIm4g8eX9bShbW2LZ wtfMELa+RPf700zI4gsY2VcxihanFiflphsZ66UWZSYXF+fn6eWllmxiBMbawS2/VXcwXn7j eIhRgINRiYc34ezxUCHWxLLiytxDjNIcLErivDM254UKCaQnlqRmp6YWpBbFF5XmpBYfYmTi 4JRqYOxd/cvEcskLjpLGq/x96RImp3az23eEuLfbrhPReLP3flpx2zohU68w+SsVPGFs+fNu fPq7/Fgar+XX2S0bFv+dwz0ppkD0ia03x/fnj24KMB+ctzU39qOs5vl5Vac/TJN9aXhh+oG+ afd0z5pfWq+myBM9+dmCCy9OmSdonTi1XbBsscoXC2clluKMREMt5qLiRAAuRKU8lgIAAA== Archived-At: Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] Do we have consensus on not requiring rtcp-non-mux? X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 10 Aug 2015 15:39:39 -0000 --_000_7594FB04B1934943A5C02806D1A2204B348EF447ESESSMB209erics_ Content-Type: text/plain; charset="windows-1256" Content-Transfer-Encoding: quoted-printable Hi Jonathan, Why can't we simply say that entities MUST insert the SDP attribute in offe= rs and answers? Regards, Christer Sent from my Windows Phone ________________________________ From: Jonathan Lennox Sent: =FD10/=FD08/=FD2015 17:46 To: Google-Peter Thatcher Cc: rtcweb@ietf.org Subject: Re: [rtcweb] Do we have consensus on not requiring rtcp-non-mux? #1 seems best to me, but there needs to be some well-specified way for JS a= pplications and offer/answer peers to discover/understand whether rtcp-non-= mux is indeed supported. Otherwise there=92s no practical difference betwe= en #1 and #2. On Aug 7, 2015, at 5:39 PM, Peter Thatcher > wrote: After lots of discussion, it appears we have three options: 1. Endpoints MAY implement rtcp-non-mux (we change the spec and can delete= the ugly code) 2. Endpoints MUST NOT implement rtcp-non-mux (we change the spec and must = delete the ugly code, and our non-compliant until we do) 3. Endpoints MUST implement rtcp-non-mux (we don't change the spec and kee= p around the ugly code) My reading of the discussion is that most people want #1 or #2, and very fe= w people still want #3. Between #1 and #2, while some people would prefer= #2, there are good reasons to just do #1, and most seem to prefer #1. Fur= ther, I'm guessing that most people who wanted #2 could live with #1. TL;DR: I think we may have rough consensus on #1, saying endpoints MAY rtc= p-non-mux (but may choose to delete all that ugly code instead). So, is everyone happy with #1? _______________________________________________ rtcweb mailing list rtcweb@ietf.org https://www.ietf.org/mailman/listinfo/rtcweb --_000_7594FB04B1934943A5C02806D1A2204B348EF447ESESSMB209erics_ Content-Type: text/html; charset="windows-1256" Content-Transfer-Encoding: quoted-printable
Hi Jonathan,<= br>
Why can't we simply say that entities MUST insert the SDP attribute in offe= rs and answers?

Regards,

Christer

Sent from my Windows Phone
From: Jonathan Lennox
Sent: =FD10= /=FD08/=FD2015 17:46
To: Google-Peter Thatcher
Cc: rtcweb@ietf.org
Subject: Re: [= rtcweb] Do we have consensus on not requiring rtcp-non-mux?

#1 seems best to me, but there needs to be some well-specified way for= JS applications and offer/answer peers to discover/understand whether rtcp= -non-mux is indeed supported.  Otherwise there=92s no practical differ= ence between #1 and #2.

On Aug 7, 2015, at 5:39 PM, Peter Thatcher <pthatcher@google.com> wrote:<= /div>
After lots of discussion, it appears we have three options:

1.  Endpoints MAY implement rtcp-non-mux (we change the spec and ca= n delete the ugly code)

2.  Endpoints MUST NOT implement rtcp-non-mux (we change the spec a= nd must delete the ugly code, and our non-compliant until we do)

3.  Endpoints MUST implement rtcp-non-mux (we don't change the spec= and keep around the ugly code)


My reading of the discussion is that most people want #1 or #2, and very= few people still want #3.   Between #1 and #2, while some people woul= d prefer #2, there are good reasons to just do #1, and most seem to prefer #1.  Further, I'm guessing that most p= eople who wanted #2 could live with #1.


TL;DR:  I think we may have rough consensus on #1, saying endpoints= MAY rtcp-non-mux (but may choose to delete all that ugly code instead). &n= bsp;


So, is everyone happy with #1?



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

--_000_7594FB04B1934943A5C02806D1A2204B348EF447ESESSMB209erics_-- From nobody Mon Aug 10 08:47:18 2015 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AB7301B3737 for ; Mon, 10 Aug 2015 08:47:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.496 X-Spam-Level: X-Spam-Status: No, score=-1.496 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, IP_NOT_FRIENDLY=0.334, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_SORBS_WEB=0.77, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id S8K1ZNKTNi6T for ; Mon, 10 Aug 2015 08:47:16 -0700 (PDT) Received: from mx0a-00198e01.pphosted.com (mx0a-00198e01.pphosted.com [67.231.149.202]) (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 994DF1B3724 for ; Mon, 10 Aug 2015 08:47:15 -0700 (PDT) Received: from pps.filterd (m0073109.ppops.net [127.0.0.1]) by mx0a-00198e01.pphosted.com (8.15.0.59/8.14.7) with SMTP id t7AFjfA7013918; Mon, 10 Aug 2015 11:47:10 -0400 Received: from mail.vidyo.com ([162.209.16.214]) by mx0a-00198e01.pphosted.com with ESMTP id 1w1e1wm144-2 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Mon, 10 Aug 2015 11:47:10 -0400 Received: from 492132-EXCH1.vidyo.com ([fe80::50:56ff:fe85:4f77]) by 492133-EXCH2.vidyo.com ([fe80::50:56ff:fe85:6b62%13]) with mapi id 14.03.0195.001; Mon, 10 Aug 2015 10:47:08 -0500 From: Jonathan Lennox To: Christer Holmberg Thread-Topic: [rtcweb] Do we have consensus on not requiring rtcp-non-mux? Thread-Index: AQHQ03qu29AkjWHTmE6I1pAkHgCelJ4Fo2SAgAAO+oCAAAIsAA== Date: Mon, 10 Aug 2015 15:47:08 +0000 Message-ID: <58198CC2-984C-4236-8B90-D20BF050A241@vidyo.com> References: <8A69E109-3F93-4C61-95F2-375FF2103EAB@vidyo.com> <7594FB04B1934943A5C02806D1A2204B348EF447@ESESSMB209.ericsson.se> In-Reply-To: <7594FB04B1934943A5C02806D1A2204B348EF447@ESESSMB209.ericsson.se> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [160.79.219.114] Content-Type: multipart/alternative; boundary="_000_58198CC2984C42368B90D20BF050A241vidyocom_" MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:5.14.151, 1.0.33, 0.0.0000 definitions=2015-08-10_02:2015-08-10,2015-08-10,1970-01-01 signatures=0 X-Proofpoint-Spam-Details: rule=outbound_notspam policy=outbound score=0 spamscore=0 suspectscore=0 phishscore=0 adultscore=0 bulkscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=7.0.1-1506180000 definitions=main-1508100237 Archived-At: Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] Do we have consensus on not requiring rtcp-non-mux? X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 10 Aug 2015 15:47:17 -0000 --_000_58198CC2984C42368B90D20BF050A241vidyocom_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 VGhlIHdob2xlIHBvaW50IG9mIHN1cHBvcnRpbmcgbm9uLU1VWCBtb2RlIGlzIHRvIGFsbG93IGFu c3dlcmVycyB0byBjaG9vc2Ugbm90IHRvIGluc2VydCB0aGUgU0RQIGF0dHJpYnV0ZS4NCg0KV2l0 aCBvcHRpb24gMSwgdGhlIGlkZWEgaXMgdGhhdCBzb21lIGVuZHBvaW50cyB3aWxsIG9mZmVyIE1V WCwgYnV0IHN1cHBvcnQgZmFsbGJhY2sgdG8gbm9uLU1VWCBpZiB0aGUgcGVlciBjaG9vc2VzIG5v dCB0byBkbyBpdC4NCg0KU29tZSBvdGhlciBlbmRwb2ludHMgd2lsbCByZXF1aXJlIHRoYXQgTVVY IGJlIHN1cHBvcnRlZCwgYW5kIGlmIGEgcGVlciBkb2VzbuKAmXQgdW5kZXJzdGFuZCB0aGlzIHRo ZW4gdGhpbmdzIHdpbGwgZmFpbCBpbiBpbnRlcmVzdGluZyB3YXlzLg0KDQpJZiBJ4oCZbSAoc2F5 KSBhIGdhdGV3YXkgdGhhdCB3b3VsZCByYXRoZXIgZG8gbm9uLU1VWCAodG8ga2VlcCBteSBsaWZl IGVhc2llciB3aGVuIGdhdGV3YXlpbmcgdG8gbGVnYWN5IGVxdWlwbWVudCksIGJ1dCBpcyB3aWxs aW5nIHRvIGRvIE1VWCBpZiBuZWNlc3NhcnksIEkgbmVlZCB0byBrbm93IHdoaWNoIHNvcnQgb2Yg ZW5kcG9pbnQgSeKAmW0gdGFsa2luZyB0by4NCg0KSG93ZXZlciwgYm90aCB0eXBlcyBvZiBlbmRw b2ludHMgd2lsbCBoYXZlIGluc2VydGVkIHRoZSBhdHRyaWJ1dGUgaW4gdGhlaXIgb2ZmZXIuDQoN CklmIHlvdSByZXF1aXJlIHRoYXQgYWxsIGVudGl0aWVzIE1VU1QgYWx3YXlzIGluc2VydCB0aGUg U0RQIGF0dHJpYnV0ZSBpbiBib3RoIG9mZmVycyAqYW5kIGFuc3dlcnMqLCB0aGVuIHlvdeKAmXJl IGNob29zaW5nIG9wdGlvbiAyLiAoQSBzdGFuZGFyZCB0aGF0IHNheXMg4oCceW91IE1BWSBoYXZl IGNvZGUgdGhhdCBpbXBsZW1lbnRzIHRoaXMgbW9kZSwgYnV0IHlvdSBNVVNUIE5PVCBldmVyIHVz ZSBpdOKAnSBpcyBwcmV0dHkgcG9pbnRsZXNzLikNCg0KDQpPbiBBdWcgMTAsIDIwMTUsIGF0IDEx OjM5IEFNLCBDaHJpc3RlciBIb2xtYmVyZyA8Y2hyaXN0ZXIuaG9sbWJlcmdAZXJpY3Nzb24uY29t PG1haWx0bzpjaHJpc3Rlci5ob2xtYmVyZ0Blcmljc3Nvbi5jb20+PiB3cm90ZToNCg0KSGkgSm9u YXRoYW4sDQoNCldoeSBjYW4ndCB3ZSBzaW1wbHkgc2F5IHRoYXQgZW50aXRpZXMgTVVTVCBpbnNl cnQgdGhlIFNEUCBhdHRyaWJ1dGUgaW4gb2ZmZXJzIGFuZCBhbnN3ZXJzPw0KDQpSZWdhcmRzLA0K DQpDaHJpc3Rlcg0KDQpTZW50IGZyb20gbXkgV2luZG93cyBQaG9uZQ0KX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX18NCkZyb206IEpvbmF0aGFuIExlbm5veDxtYWlsdG86am9uYXRoYW5A dmlkeW8uY29tPg0KU2VudDog4oCOMTAv4oCOMDgv4oCOMjAxNSAxNzo0Ng0KVG86IEdvb2dsZS1Q ZXRlciBUaGF0Y2hlcjxtYWlsdG86cHRoYXRjaGVyQGdvb2dsZS5jb20+DQpDYzogcnRjd2ViQGll dGYub3JnPG1haWx0bzpydGN3ZWJAaWV0Zi5vcmc+DQpTdWJqZWN0OiBSZTogW3J0Y3dlYl0gRG8g d2UgaGF2ZSBjb25zZW5zdXMgb24gbm90IHJlcXVpcmluZyBydGNwLW5vbi1tdXg/DQoNCiMxIHNl ZW1zIGJlc3QgdG8gbWUsIGJ1dCB0aGVyZSBuZWVkcyB0byBiZSBzb21lIHdlbGwtc3BlY2lmaWVk IHdheSBmb3IgSlMgYXBwbGljYXRpb25zIGFuZCBvZmZlci9hbnN3ZXIgcGVlcnMgdG8gZGlzY292 ZXIvdW5kZXJzdGFuZCB3aGV0aGVyIHJ0Y3Atbm9uLW11eCBpcyBpbmRlZWQgc3VwcG9ydGVkLiAg T3RoZXJ3aXNlIHRoZXJl4oCZcyBubyBwcmFjdGljYWwgZGlmZmVyZW5jZSBiZXR3ZWVuICMxIGFu ZCAjMi4NCg0KT24gQXVnIDcsIDIwMTUsIGF0IDU6MzkgUE0sIFBldGVyIFRoYXRjaGVyIDxwdGhh dGNoZXJAZ29vZ2xlLmNvbTxtYWlsdG86cHRoYXRjaGVyQGdvb2dsZS5jb20+PiB3cm90ZToNCg0K QWZ0ZXIgbG90cyBvZiBkaXNjdXNzaW9uLCBpdCBhcHBlYXJzIHdlIGhhdmUgdGhyZWUgb3B0aW9u czoNCg0KMS4gIEVuZHBvaW50cyBNQVkgaW1wbGVtZW50IHJ0Y3Atbm9uLW11eCAod2UgY2hhbmdl IHRoZSBzcGVjIGFuZCBjYW4gZGVsZXRlIHRoZSB1Z2x5IGNvZGUpDQoNCjIuICBFbmRwb2ludHMg TVVTVCBOT1QgaW1wbGVtZW50IHJ0Y3Atbm9uLW11eCAod2UgY2hhbmdlIHRoZSBzcGVjIGFuZCBt dXN0IGRlbGV0ZSB0aGUgdWdseSBjb2RlLCBhbmQgb3VyIG5vbi1jb21wbGlhbnQgdW50aWwgd2Ug ZG8pDQoNCjMuICBFbmRwb2ludHMgTVVTVCBpbXBsZW1lbnQgcnRjcC1ub24tbXV4ICh3ZSBkb24n dCBjaGFuZ2UgdGhlIHNwZWMgYW5kIGtlZXAgYXJvdW5kIHRoZSB1Z2x5IGNvZGUpDQoNCg0KTXkg cmVhZGluZyBvZiB0aGUgZGlzY3Vzc2lvbiBpcyB0aGF0IG1vc3QgcGVvcGxlIHdhbnQgIzEgb3Ig IzIsIGFuZCB2ZXJ5IGZldyBwZW9wbGUgc3RpbGwgd2FudCAjMy4gICBCZXR3ZWVuICMxIGFuZCAj Miwgd2hpbGUgc29tZSBwZW9wbGUgd291bGQgcHJlZmVyICMyLCB0aGVyZSBhcmUgZ29vZCByZWFz b25zIHRvIGp1c3QgZG8gIzEsIGFuZCBtb3N0IHNlZW0gdG8gcHJlZmVyICMxLiAgRnVydGhlciwg SSdtIGd1ZXNzaW5nIHRoYXQgbW9zdCBwZW9wbGUgd2hvIHdhbnRlZCAjMiBjb3VsZCBsaXZlIHdp dGggIzEuDQoNCg0KVEw7RFI6ICBJIHRoaW5rIHdlIG1heSBoYXZlIHJvdWdoIGNvbnNlbnN1cyBv biAjMSwgc2F5aW5nIGVuZHBvaW50cyBNQVkgcnRjcC1ub24tbXV4IChidXQgbWF5IGNob29zZSB0 byBkZWxldGUgYWxsIHRoYXQgdWdseSBjb2RlIGluc3RlYWQpLg0KDQoNClNvLCBpcyBldmVyeW9u ZSBoYXBweSB3aXRoICMxPw0KDQoNCg0KX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX18NCnJ0Y3dlYiBtYWlsaW5nIGxpc3QNCnJ0Y3dlYkBpZXRmLm9yZzxtYWls dG86cnRjd2ViQGlldGYub3JnPg0KaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5m by9ydGN3ZWINCg0KDQo= --_000_58198CC2984C42368B90D20BF050A241vidyocom_ Content-Type: text/html; charset="utf-8" Content-ID: Content-Transfer-Encoding: base64 PGh0bWw+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIgY29udGVudD0i dGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjwvaGVhZD4NCjxib2R5IHN0eWxlPSJ3b3JkLXdy YXA6IGJyZWFrLXdvcmQ7IC13ZWJraXQtbmJzcC1tb2RlOiBzcGFjZTsgLXdlYmtpdC1saW5lLWJy ZWFrOiBhZnRlci13aGl0ZS1zcGFjZTsiIGNsYXNzPSIiPg0KPGRpdiBjbGFzcz0iIj5UaGUgd2hv bGUgcG9pbnQgb2Ygc3VwcG9ydGluZyBub24tTVVYIG1vZGUgaXMgdG8gYWxsb3cgYW5zd2VyZXJz IHRvIGNob29zZSBub3QgdG8gaW5zZXJ0IHRoZSBTRFAgYXR0cmlidXRlLjwvZGl2Pg0KPGRpdiBj bGFzcz0iIj48YnIgY2xhc3M9IiI+DQo8L2Rpdj4NCjxkaXYgY2xhc3M9IiI+V2l0aCBvcHRpb24g MSwgdGhlIGlkZWEgaXMgdGhhdCBzb21lIGVuZHBvaW50cyB3aWxsIG9mZmVyIE1VWCwgYnV0IHN1 cHBvcnQgZmFsbGJhY2sgdG8gbm9uLU1VWCBpZiB0aGUgcGVlciBjaG9vc2VzIG5vdCB0byBkbyBp dC48L2Rpdj4NCjxkaXYgY2xhc3M9IiI+PGJyIGNsYXNzPSIiPg0KPC9kaXY+DQo8ZGl2IGNsYXNz PSIiPlNvbWUgb3RoZXIgZW5kcG9pbnRzIHdpbGwgcmVxdWlyZSB0aGF0IE1VWCBiZSBzdXBwb3J0 ZWQsIGFuZCBpZiBhIHBlZXIgZG9lc27igJl0IHVuZGVyc3RhbmQgdGhpcyB0aGVuIHRoaW5ncyB3 aWxsIGZhaWwgaW4gaW50ZXJlc3Rpbmcgd2F5cy48L2Rpdj4NCjxkaXYgY2xhc3M9IiI+PGJyIGNs YXNzPSIiPg0KPC9kaXY+DQo8ZGl2IGNsYXNzPSIiPklmIEnigJltIChzYXkpIGEgZ2F0ZXdheSB0 aGF0IHdvdWxkIHJhdGhlciBkbyBub24tTVVYICh0byBrZWVwIG15IGxpZmUgZWFzaWVyIHdoZW4g Z2F0ZXdheWluZyB0byBsZWdhY3kgZXF1aXBtZW50KSwgYnV0IGlzIHdpbGxpbmcgdG8gZG8gTVVY IGlmIG5lY2Vzc2FyeSwgSSBuZWVkIHRvIGtub3cgd2hpY2ggc29ydCBvZiBlbmRwb2ludCBJ4oCZ bSB0YWxraW5nIHRvLjwvZGl2Pg0KPGRpdiBjbGFzcz0iIj48YnIgY2xhc3M9IiI+DQo8L2Rpdj4N CjxkaXYgY2xhc3M9IiI+SG93ZXZlciwgYm90aCB0eXBlcyBvZiBlbmRwb2ludHMgd2lsbCBoYXZl IGluc2VydGVkIHRoZSBhdHRyaWJ1dGUgaW4gdGhlaXIgb2ZmZXIuPC9kaXY+DQo8ZGl2IGNsYXNz PSIiPjxiciBjbGFzcz0iIj4NCjwvZGl2Pg0KPGRpdiBjbGFzcz0iIj5JZiB5b3UgcmVxdWlyZSB0 aGF0IGFsbCBlbnRpdGllcyBNVVNUIGFsd2F5cyBpbnNlcnQgdGhlIFNEUCBhdHRyaWJ1dGUgaW4g Ym90aCBvZmZlcnMgKmFuZCBhbnN3ZXJzKiwgdGhlbiB5b3XigJlyZSBjaG9vc2luZyBvcHRpb24g Mi4gKEEgc3RhbmRhcmQgdGhhdCBzYXlzIOKAnHlvdSBNQVkgaGF2ZSBjb2RlIHRoYXQgaW1wbGVt ZW50cyB0aGlzIG1vZGUsIGJ1dCB5b3UgTVVTVCBOT1QgZXZlciB1c2UgaXTigJ0gaXMgcHJldHR5 IHBvaW50bGVzcy4pPC9kaXY+DQo8ZGl2IGNsYXNzPSIiPjxiciBjbGFzcz0iIj4NCjwvZGl2Pg0K PGJyIGNsYXNzPSIiPg0KPGRpdj4NCjxibG9ja3F1b3RlIHR5cGU9ImNpdGUiIGNsYXNzPSIiPg0K PGRpdiBjbGFzcz0iIj5PbiBBdWcgMTAsIDIwMTUsIGF0IDExOjM5IEFNLCBDaHJpc3RlciBIb2xt YmVyZyAmbHQ7PGEgaHJlZj0ibWFpbHRvOmNocmlzdGVyLmhvbG1iZXJnQGVyaWNzc29uLmNvbSIg Y2xhc3M9IiI+Y2hyaXN0ZXIuaG9sbWJlcmdAZXJpY3Nzb24uY29tPC9hPiZndDsgd3JvdGU6PC9k aXY+DQo8YnIgY2xhc3M9IkFwcGxlLWludGVyY2hhbmdlLW5ld2xpbmUiPg0KPGRpdiBjbGFzcz0i Ij4NCjxkaXYgY2xhc3M9IiIgc3R5bGU9IndvcmQtd3JhcDpicmVhay13b3JkIj4NCjxkaXYgY2xh c3M9IiI+DQo8ZGl2IHN0eWxlPSJmb250LWZhbWlseTpDYWxpYnJpLHNhbnMtc2VyaWY7IGZvbnQt c2l6ZToxMXB0IiBjbGFzcz0iIj5IaSBKb25hdGhhbiw8YnIgY2xhc3M9IiI+DQo8YnIgY2xhc3M9 IiI+DQpXaHkgY2FuJ3Qgd2Ugc2ltcGx5IHNheSB0aGF0IGVudGl0aWVzIE1VU1QgaW5zZXJ0IHRo ZSBTRFAgYXR0cmlidXRlIGluIG9mZmVycyBhbmQgYW5zd2Vycz88YnIgY2xhc3M9IiI+DQo8YnIg Y2xhc3M9IiI+DQpSZWdhcmRzLDxiciBjbGFzcz0iIj4NCjxiciBjbGFzcz0iIj4NCkNocmlzdGVy PGJyIGNsYXNzPSIiPg0KPGJyIGNsYXNzPSIiPg0KU2VudCBmcm9tIG15IFdpbmRvd3MgUGhvbmU8 L2Rpdj4NCjwvZGl2Pg0KPGRpdiBkaXI9Imx0ciIgY2xhc3M9IiI+DQo8aHIgY2xhc3M9IiI+DQo8 c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6Q2FsaWJyaSxzYW5zLXNlcmlmOyBmb250LXNpemU6MTFw dDsgZm9udC13ZWlnaHQ6Ym9sZCIgY2xhc3M9IiI+RnJvbToNCjwvc3Bhbj48c3BhbiBzdHlsZT0i Zm9udC1mYW1pbHk6Q2FsaWJyaSxzYW5zLXNlcmlmOyBmb250LXNpemU6MTFwdCIgY2xhc3M9IiI+ PGEgaHJlZj0ibWFpbHRvOmpvbmF0aGFuQHZpZHlvLmNvbSIgY2xhc3M9IiI+Sm9uYXRoYW4gTGVu bm94PC9hPjwvc3Bhbj48YnIgY2xhc3M9IiI+DQo8c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6Q2Fs aWJyaSxzYW5zLXNlcmlmOyBmb250LXNpemU6MTFwdDsgZm9udC13ZWlnaHQ6Ym9sZCIgY2xhc3M9 IiI+U2VudDoNCjwvc3Bhbj48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6Q2FsaWJyaSxzYW5zLXNl cmlmOyBmb250LXNpemU6MTFwdCIgY2xhc3M9IiI+4oCOMTAv4oCOMDgv4oCOMjAxNSAxNzo0Njwv c3Bhbj48YnIgY2xhc3M9IiI+DQo8c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6Q2FsaWJyaSxzYW5z LXNlcmlmOyBmb250LXNpemU6MTFwdDsgZm9udC13ZWlnaHQ6Ym9sZCIgY2xhc3M9IiI+VG86DQo8 L3NwYW4+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OkNhbGlicmksc2Fucy1zZXJpZjsgZm9udC1z aXplOjExcHQiIGNsYXNzPSIiPjxhIGhyZWY9Im1haWx0bzpwdGhhdGNoZXJAZ29vZ2xlLmNvbSIg Y2xhc3M9IiI+R29vZ2xlLVBldGVyIFRoYXRjaGVyPC9hPjwvc3Bhbj48YnIgY2xhc3M9IiI+DQo8 c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6Q2FsaWJyaSxzYW5zLXNlcmlmOyBmb250LXNpemU6MTFw dDsgZm9udC13ZWlnaHQ6Ym9sZCIgY2xhc3M9IiI+Q2M6DQo8L3NwYW4+PHNwYW4gc3R5bGU9ImZv bnQtZmFtaWx5OkNhbGlicmksc2Fucy1zZXJpZjsgZm9udC1zaXplOjExcHQiIGNsYXNzPSIiPjxh IGhyZWY9Im1haWx0bzpydGN3ZWJAaWV0Zi5vcmciIGNsYXNzPSIiPnJ0Y3dlYkBpZXRmLm9yZzwv YT48L3NwYW4+PGJyIGNsYXNzPSIiPg0KPHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OkNhbGlicmks c2Fucy1zZXJpZjsgZm9udC1zaXplOjExcHQ7IGZvbnQtd2VpZ2h0OmJvbGQiIGNsYXNzPSIiPlN1 YmplY3Q6DQo8L3NwYW4+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OkNhbGlicmksc2Fucy1zZXJp ZjsgZm9udC1zaXplOjExcHQiIGNsYXNzPSIiPlJlOiBbcnRjd2ViXSBEbyB3ZSBoYXZlIGNvbnNl bnN1cyBvbiBub3QgcmVxdWlyaW5nIHJ0Y3Atbm9uLW11eD88L3NwYW4+PGJyIGNsYXNzPSIiPg0K PGJyIGNsYXNzPSIiPg0KPC9kaXY+DQo8ZGl2IGNsYXNzPSIiPiMxIHNlZW1zIGJlc3QgdG8gbWUs IGJ1dCB0aGVyZSBuZWVkcyB0byBiZSBzb21lIHdlbGwtc3BlY2lmaWVkIHdheSBmb3IgSlMgYXBw bGljYXRpb25zIGFuZCBvZmZlci9hbnN3ZXIgcGVlcnMgdG8gZGlzY292ZXIvdW5kZXJzdGFuZCB3 aGV0aGVyIHJ0Y3Atbm9uLW11eCBpcyBpbmRlZWQgc3VwcG9ydGVkLiAmbmJzcDtPdGhlcndpc2Ug dGhlcmXigJlzIG5vIHByYWN0aWNhbCBkaWZmZXJlbmNlIGJldHdlZW4gIzEgYW5kICMyLjxiciBj bGFzcz0iIj4NCjxkaXYgY2xhc3M9IiI+PGJyIGNsYXNzPSIiPg0KPGJsb2NrcXVvdGUgdHlwZT0i Y2l0ZSIgY2xhc3M9IiI+DQo8ZGl2IGNsYXNzPSIiPk9uIEF1ZyA3LCAyMDE1LCBhdCA1OjM5IFBN LCBQZXRlciBUaGF0Y2hlciAmbHQ7PGEgaHJlZj0ibWFpbHRvOnB0aGF0Y2hlckBnb29nbGUuY29t IiBjbGFzcz0iIj5wdGhhdGNoZXJAZ29vZ2xlLmNvbTwvYT4mZ3Q7IHdyb3RlOjwvZGl2Pg0KPGJy IGNsYXNzPSJBcHBsZS1pbnRlcmNoYW5nZS1uZXdsaW5lIj4NCjxkaXYgY2xhc3M9IiI+DQo8ZGl2 IGRpcj0ibHRyIiBjbGFzcz0iIj4NCjxkaXYgY2xhc3M9ImdtYWlsX2RlZmF1bHQiIHN0eWxlPSJm b250LWZhbWlseTphcmlhbCxoZWx2ZXRpY2Esc2Fucy1zZXJpZiI+QWZ0ZXIgbG90cyBvZiBkaXNj dXNzaW9uLCBpdCBhcHBlYXJzIHdlIGhhdmUgdGhyZWUgb3B0aW9uczo8L2Rpdj4NCjxkaXYgY2xh c3M9ImdtYWlsX2RlZmF1bHQiIHN0eWxlPSJmb250LWZhbWlseTphcmlhbCxoZWx2ZXRpY2Esc2Fu cy1zZXJpZiI+PGJyIGNsYXNzPSIiPg0KPC9kaXY+DQo8ZGl2IGNsYXNzPSJnbWFpbF9kZWZhdWx0 IiBzdHlsZT0iZm9udC1mYW1pbHk6YXJpYWwsaGVsdmV0aWNhLHNhbnMtc2VyaWYiPjEuJm5ic3A7 IEVuZHBvaW50cyBNQVkgaW1wbGVtZW50IHJ0Y3Atbm9uLW11eCAod2UgY2hhbmdlIHRoZSBzcGVj IGFuZCBjYW4gZGVsZXRlIHRoZSB1Z2x5IGNvZGUpPC9kaXY+DQo8ZGl2IGNsYXNzPSJnbWFpbF9k ZWZhdWx0IiBzdHlsZT0iZm9udC1mYW1pbHk6YXJpYWwsaGVsdmV0aWNhLHNhbnMtc2VyaWYiPjxi ciBjbGFzcz0iIj4NCjwvZGl2Pg0KPGRpdiBjbGFzcz0iZ21haWxfZGVmYXVsdCIgc3R5bGU9ImZv bnQtZmFtaWx5OmFyaWFsLGhlbHZldGljYSxzYW5zLXNlcmlmIj4yLiZuYnNwOyBFbmRwb2ludHMg TVVTVCBOT1QgaW1wbGVtZW50IHJ0Y3Atbm9uLW11eCAod2UgY2hhbmdlIHRoZSBzcGVjIGFuZCBt dXN0IGRlbGV0ZSB0aGUgdWdseSBjb2RlLCBhbmQgb3VyIG5vbi1jb21wbGlhbnQgdW50aWwgd2Ug ZG8pPC9kaXY+DQo8ZGl2IGNsYXNzPSJnbWFpbF9kZWZhdWx0IiBzdHlsZT0iZm9udC1mYW1pbHk6 YXJpYWwsaGVsdmV0aWNhLHNhbnMtc2VyaWYiPjxiciBjbGFzcz0iIj4NCjwvZGl2Pg0KPGRpdiBj bGFzcz0iZ21haWxfZGVmYXVsdCIgc3R5bGU9ImZvbnQtZmFtaWx5OmFyaWFsLGhlbHZldGljYSxz YW5zLXNlcmlmIj4zLiZuYnNwOyBFbmRwb2ludHMgTVVTVCBpbXBsZW1lbnQgcnRjcC1ub24tbXV4 ICh3ZSBkb24ndCBjaGFuZ2UgdGhlIHNwZWMgYW5kIGtlZXAgYXJvdW5kIHRoZSB1Z2x5IGNvZGUp PC9kaXY+DQo8ZGl2IGNsYXNzPSJnbWFpbF9kZWZhdWx0IiBzdHlsZT0iZm9udC1mYW1pbHk6YXJp YWwsaGVsdmV0aWNhLHNhbnMtc2VyaWYiPjxiciBjbGFzcz0iIj4NCjwvZGl2Pg0KPGRpdiBjbGFz cz0iZ21haWxfZGVmYXVsdCIgc3R5bGU9ImZvbnQtZmFtaWx5OmFyaWFsLGhlbHZldGljYSxzYW5z LXNlcmlmIj48YnIgY2xhc3M9IiI+DQo8L2Rpdj4NCjxkaXYgY2xhc3M9ImdtYWlsX2RlZmF1bHQi IHN0eWxlPSJmb250LWZhbWlseTphcmlhbCxoZWx2ZXRpY2Esc2Fucy1zZXJpZiI+TXkgcmVhZGlu ZyBvZiB0aGUgZGlzY3Vzc2lvbiBpcyB0aGF0IG1vc3QgcGVvcGxlIHdhbnQgIzEgb3IgIzIsIGFu ZCB2ZXJ5IGZldyBwZW9wbGUgc3RpbGwgd2FudCAjMy4gJm5ic3A7IEJldHdlZW4gIzEgYW5kICMy LCB3aGlsZSBzb21lIHBlb3BsZSB3b3VsZCBwcmVmZXIgIzIsIHRoZXJlIGFyZSBnb29kIHJlYXNv bnMgdG8ganVzdA0KIGRvICMxLCBhbmQgbW9zdCBzZWVtIHRvIHByZWZlciAjMS4mbmJzcDsgRnVy dGhlciwgSSdtIGd1ZXNzaW5nIHRoYXQgbW9zdCBwZW9wbGUgd2hvIHdhbnRlZCAjMiBjb3VsZCBs aXZlIHdpdGggIzEuPC9kaXY+DQo8ZGl2IGNsYXNzPSJnbWFpbF9kZWZhdWx0IiBzdHlsZT0iZm9u dC1mYW1pbHk6YXJpYWwsaGVsdmV0aWNhLHNhbnMtc2VyaWYiPjxiciBjbGFzcz0iIj4NCjwvZGl2 Pg0KPGRpdiBjbGFzcz0iZ21haWxfZGVmYXVsdCIgc3R5bGU9ImZvbnQtZmFtaWx5OmFyaWFsLGhl bHZldGljYSxzYW5zLXNlcmlmIj48YnIgY2xhc3M9IiI+DQo8L2Rpdj4NCjxkaXYgY2xhc3M9Imdt YWlsX2RlZmF1bHQiIHN0eWxlPSJmb250LWZhbWlseTphcmlhbCxoZWx2ZXRpY2Esc2Fucy1zZXJp ZiI+VEw7RFI6ICZuYnNwO0kgdGhpbmsgd2UgbWF5IGhhdmUgcm91Z2ggY29uc2Vuc3VzIG9uICMx LCBzYXlpbmcgZW5kcG9pbnRzIE1BWSBydGNwLW5vbi1tdXggKGJ1dCBtYXkgY2hvb3NlIHRvIGRl bGV0ZSBhbGwgdGhhdCB1Z2x5IGNvZGUgaW5zdGVhZCkuICZuYnNwOzwvZGl2Pg0KPGRpdiBjbGFz cz0iZ21haWxfZGVmYXVsdCIgc3R5bGU9ImZvbnQtZmFtaWx5OmFyaWFsLGhlbHZldGljYSxzYW5z LXNlcmlmIj48YnIgY2xhc3M9IiI+DQo8L2Rpdj4NCjxkaXYgY2xhc3M9ImdtYWlsX2RlZmF1bHQi IHN0eWxlPSJmb250LWZhbWlseTphcmlhbCxoZWx2ZXRpY2Esc2Fucy1zZXJpZiI+PGJyIGNsYXNz PSIiPg0KPC9kaXY+DQo8ZGl2IGNsYXNzPSJnbWFpbF9kZWZhdWx0IiBzdHlsZT0iZm9udC1mYW1p bHk6YXJpYWwsaGVsdmV0aWNhLHNhbnMtc2VyaWYiPlNvLCBpcyBldmVyeW9uZSBoYXBweSB3aXRo ICMxPzwvZGl2Pg0KPGRpdiBjbGFzcz0iZ21haWxfZGVmYXVsdCIgc3R5bGU9ImZvbnQtZmFtaWx5 OmFyaWFsLGhlbHZldGljYSxzYW5zLXNlcmlmIj48YnIgY2xhc3M9IiI+DQo8L2Rpdj4NCjxkaXYg Y2xhc3M9ImdtYWlsX2RlZmF1bHQiIHN0eWxlPSJmb250LWZhbWlseTphcmlhbCxoZWx2ZXRpY2Es c2Fucy1zZXJpZiI+PGJyIGNsYXNzPSIiPg0KPC9kaXY+DQo8ZGl2IGNsYXNzPSJnbWFpbF9kZWZh dWx0IiBzdHlsZT0iZm9udC1mYW1pbHk6YXJpYWwsaGVsdmV0aWNhLHNhbnMtc2VyaWYiPjxiciBj bGFzcz0iIj4NCjwvZGl2Pg0KPC9kaXY+DQpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fXzxiciBjbGFzcz0iIj4NCnJ0Y3dlYiBtYWlsaW5nIGxpc3Q8YnIgY2xh c3M9IiI+DQo8YSBocmVmPSJtYWlsdG86cnRjd2ViQGlldGYub3JnIiBjbGFzcz0iIj5ydGN3ZWJA aWV0Zi5vcmc8L2E+PGJyIGNsYXNzPSIiPg0KPGEgaHJlZj0iaHR0cHM6Ly93d3cuaWV0Zi5vcmcv bWFpbG1hbi9saXN0aW5mby9ydGN3ZWIiIGNsYXNzPSIiPmh0dHBzOi8vd3d3LmlldGYub3JnL21h aWxtYW4vbGlzdGluZm8vcnRjd2ViPC9hPjxiciBjbGFzcz0iIj4NCjwvZGl2Pg0KPC9ibG9ja3F1 b3RlPg0KPC9kaXY+DQo8YnIgY2xhc3M9IiI+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Js b2NrcXVvdGU+DQo8L2Rpdj4NCjxiciBjbGFzcz0iIj4NCjwvYm9keT4NCjwvaHRtbD4NCg== --_000_58198CC2984C42368B90D20BF050A241vidyocom_-- From nobody Mon Aug 10 10:00:17 2015 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6FBFE1ACF18 for ; Mon, 10 Aug 2015 10:00:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zvsOrWht0WPN for ; Mon, 10 Aug 2015 10:00:13 -0700 (PDT) Received: from na01-by2-obe.outbound.protection.outlook.com (mail-by2on0060.outbound.protection.outlook.com [207.46.100.60]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5D9B01ABC0F for ; Mon, 10 Aug 2015 10:00:13 -0700 (PDT) Received: from SN1PR0301MB1551.namprd03.prod.outlook.com (10.162.129.157) by SN1PR0301MB1551.namprd03.prod.outlook.com (10.162.129.157) with Microsoft SMTP Server (TLS) id 15.1.225.19; Mon, 10 Aug 2015 17:00:11 +0000 Received: from SN1PR0301MB1551.namprd03.prod.outlook.com ([10.162.129.157]) by SN1PR0301MB1551.namprd03.prod.outlook.com ([10.162.129.157]) with mapi id 15.01.0225.018; Mon, 10 Aug 2015 17:00:11 +0000 From: "Asveren, Tolga" To: Harald Alvestrand , Colin Perkins , "Hutton, Andrew" Thread-Topic: [rtcweb] Do we have consensus on not requiring rtcp-non-mux? Thread-Index: AQHQ0nG99sT639xdM0GLFaO8u8tbX54FDgJ1gAAMngCAAFwU0A== Date: Mon, 10 Aug 2015 17:00:11 +0000 Message-ID: References: <55C6FBAB.6050009@alvestrand.no> <9F33F40F6F2CD847824537F3C4E37DDF1E83584F@MCHP04MSX.global-ad.net> <55C88AFE.1020204@alvestrand.no> In-Reply-To: <55C88AFE.1020204@alvestrand.no> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=tasveren@sonusnet.com; x-originating-ip: [50.182.164.80] x-microsoft-exchange-diagnostics: 1; SN1PR0301MB1551; 5:s7qtzEwfnLHGOT9kwMhH4kD5zwoDcjjZPPkAhVkjTyItX7K0HYyeg5U4W+fA+3si9KY6/irnTodqEtsKaR2Barfwfio+c4+1aBwdCjkPCpN+hXn96G475rk9i3+xyLs/tPBek6rADP0YpUxWhyTTwA==; 24:z3X/odn9h3HEKhnqruno5oy9mrD7iErytTxsAJuSGYSXAJyS+op4n/3FtQW3mbbA774j8Hr/S6Smb+0o34WR45DpUmC2W1HJ5It/T3rFKtg=; 20:IN9CBF0KsgKEdsCXgezFsyELzc3fLWI48J0W7v8fR/tLNY4YwXuTe4AfpWau+EEzVahXbtea1DAAEhzsauayjQ== x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:SN1PR0301MB1551; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:; x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(601004)(5005006)(3002001); SRVR:SN1PR0301MB1551; BCL:0; PCL:0; RULEID:; SRVR:SN1PR0301MB1551; x-forefront-prvs: 06640999CA x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(6009001)(13464003)(199003)(164054003)(189002)(377454003)(74316001)(19580405001)(92566002)(86362001)(5002640100001)(2950100001)(77096005)(2900100001)(15975445007)(68736005)(5001960100002)(5001830100001)(81156007)(4001540100001)(5001770100001)(46102003)(97736004)(102836002)(5001860100001)(189998001)(33656002)(10400500002)(87936001)(19580395003)(64706001)(54356999)(101416001)(561944003)(2656002)(76176999)(50986999)(99286002)(93886004)(77156002)(106356001)(106116001)(40100003)(230783001)(122556002)(5003600100002)(62966003)(76576001)(105586002)(66066001); DIR:OUT; SFP:1101; SCL:1; SRVR:SN1PR0301MB1551; H:SN1PR0301MB1551.namprd03.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; A:1; MX:1; LANG:en; received-spf: None (protection.outlook.com: sonusnet.com does not designate permitted sender hosts) spamdiagnosticoutput: 1:23 spamdiagnosticmetadata: NSPM Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: sonusnet.com X-MS-Exchange-CrossTenant-originalarrivaltime: 10 Aug 2015 17:00:11.5317 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 29a671dc-ed7e-4a54-b1e5-8da1eb495dc3 X-MS-Exchange-Transport-CrossTenantHeadersStamped: SN1PR0301MB1551 Archived-At: Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] Do we have consensus on not requiring rtcp-non-mux? X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 10 Aug 2015 17:00:15 -0000 Harald's proposal sounds good to me. It economically and gracefully reflect= s my understanding of the current (rough) consensus. Thanks, Tolga > -----Original Message----- > From: rtcweb [mailto:rtcweb-bounces@ietf.org] On Behalf Of Harald > Alvestrand > Sent: Monday, August 10, 2015 7:29 AM > To: Colin Perkins ; Hutton, Andrew > > Cc: rtcweb@ietf.org > Subject: Re: [rtcweb] Do we have consensus on not requiring rtcp-non-mux? >=20 > Den 10. aug. 2015 12:43, skrev Colin Perkins: > > We might be able to make the edits in AUTH48, with AD approval, rather > > than pull the draft back from the RFC Editor, but those are process > > steps we'll figure out. > > > > What I'd most like to understand is the exact text change that is > > being proposed for the rtp-usage draft. Can someone state what is > > believed to be the consensus? >=20 > This sentence (4.5) needs to be deleted for all variants proposed: >=20 > For > backwards compatibility, implementations are also REQUIRED to support > RTP and RTCP sent on separate transport-layer flows. >=20 > I *think* that my favorite solution, #1, can replace it with >=20 > Implementations MAY support > RTP and RTCP sent on separate transport-layer flows. They MAY also > refuse to do so, in which case any negotiation that results in > multiplexing not being negotiated is treated as a failure. >=20 > This is based on the theory that "failure is always an option", which sav= es us > from adding extra protocol machinery to deal with this case. >=20 > _______________________________________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/listinfo/rtcweb From nobody Mon Aug 10 10:03:45 2015 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AC5BF1B3678 for ; Mon, 10 Aug 2015 10:03:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.978 X-Spam-Level: X-Spam-Status: No, score=-1.978 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, 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 qCS2vlxEAAic for ; Mon, 10 Aug 2015 10:03:43 -0700 (PDT) Received: from mail-io0-f179.google.com (mail-io0-f179.google.com [209.85.223.179]) (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 9A6E91B39E3 for ; Mon, 10 Aug 2015 10:03:39 -0700 (PDT) Received: by ioeg141 with SMTP id g141so175821218ioe.3 for ; Mon, 10 Aug 2015 10:03:39 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=eDmX4FuaQQ+szVp9KiccdMQhqHZ32zE4Yz2Gg6euF5M=; b=j9seSSTISIuSJwT4Kzfcm43GnqRYpqPj4ToSX9+/zBK0bb5xIYFhNXp7O3LTPOyFvD ElFiaX9fmmy22insa6JtvLOL+PSGC4fQZxbwzbFq672kD+pELk7CT4OL8/+z1YdbbbWr AhMVIFmglTy2h/EXpkna32C0nEIpqlgzguiU/EmIK46YNQwB9m3YUHS1b+MjImF9nyWJ TvYAOs62lSFG/4kFnHN6/aN1fmkMfWfdiGMu2WBsNzlm8q/cncpE76nI3OXYnptQbFyA HaDQVuFt/CxJm3AEmJe72eKkVb1V3/vuicCYhSMVxyDXyeWrL8+gZs1l1oC9wD9rLKgW cpOg== X-Gm-Message-State: ALoCoQn6T1kKbd50MHxFyHhzUQh3f4BRozE690P1HJ4fpiR5hjd+P+zlOzJwunOVLDRpSCE5UQKB X-Received: by 10.107.131.22 with SMTP id f22mr21108138iod.73.1439226219037; Mon, 10 Aug 2015 10:03:39 -0700 (PDT) Received: from mail-ig0-f179.google.com (mail-ig0-f179.google.com. [209.85.213.179]) by smtp.gmail.com with ESMTPSA id lp3sm6199118igb.12.2015.08.10.10.03.37 for (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 10 Aug 2015 10:03:37 -0700 (PDT) Received: by igbpg9 with SMTP id pg9so73700184igb.0 for ; Mon, 10 Aug 2015 10:03:37 -0700 (PDT) MIME-Version: 1.0 X-Received: by 10.50.141.164 with SMTP id rp4mr12465565igb.2.1439226217192; Mon, 10 Aug 2015 10:03:37 -0700 (PDT) Received: by 10.36.89.70 with HTTP; Mon, 10 Aug 2015 10:03:37 -0700 (PDT) In-Reply-To: <55C88AFE.1020204@alvestrand.no> References: <55C6FBAB.6050009@alvestrand.no> <9F33F40F6F2CD847824537F3C4E37DDF1E83584F@MCHP04MSX.global-ad.net> <55C88AFE.1020204@alvestrand.no> Date: Mon, 10 Aug 2015 13:03:37 -0400 Message-ID: From: Roman Shpount To: Harald Alvestrand Content-Type: multipart/alternative; boundary=089e012953806d65e6051cf7f739 Archived-At: Cc: "rtcweb@ietf.org" , Colin Perkins Subject: Re: [rtcweb] Do we have consensus on not requiring rtcp-non-mux? X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 10 Aug 2015 17:03:44 -0000 --089e012953806d65e6051cf7f739 Content-Type: text/plain; charset=UTF-8 On Mon, Aug 10, 2015 at 7:29 AM, Harald Alvestrand wrote: > This sentence (4.5) needs to be deleted for all variants proposed: > > For > backwards compatibility, implementations are also REQUIRED to support > RTP and RTCP sent on separate transport-layer flows. > > I *think* that my favorite solution, #1, can replace it with > > Implementations MAY support > RTP and RTCP sent on separate transport-layer flows. They MAY also > refuse to do so, in which case any negotiation that results in > multiplexing not being negotiated is treated as a failure. > > This is based on the theory that "failure is always an option", which > saves us from adding extra protocol machinery to deal with this case. > > +1 _____________ Roman Shpount --089e012953806d65e6051cf7f739 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On M= on, Aug 10, 2015 at 7:29 AM, Harald Alvestrand <harald@alvestrand.no> wrote:
This sentence (4.5) n= eeds to be deleted for all variants proposed:

=C2=A0 =C2=A0For
=C2=A0 =C2=A0backwards compatibility, implementations are also REQUIRED to = support
=C2=A0 =C2=A0RTP and RTCP sent on separate transport-layer flows.

I *think* that my favorite solution, #1, can replace it with

=C2=A0 =C2=A0Implementations MAY support
=C2=A0 =C2=A0RTP and RTCP sent on separate transport-layer flows. They MAY = also
=C2=A0 =C2=A0refuse to do so, in which case any negotiation that results in=
=C2=A0 =C2=A0multiplexing not being negotiated is treated as a failure.

This is based on the theory that "failure is always an option", w= hich
saves us from adding extra protocol machinery to deal with this case.

<= br>
+1=C2=A0
_____________
Roman Shpount

<= /div>
--089e012953806d65e6051cf7f739-- From nobody Mon Aug 10 11:02:17 2015 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5081F1B386F for ; Mon, 10 Aug 2015 11:02:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.2 X-Spam-Level: X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5O33mPa17o1L for ; Mon, 10 Aug 2015 11:02:13 -0700 (PDT) Received: from sessmg23.ericsson.net (sessmg23.ericsson.net [193.180.251.45]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 79EC11B3874 for ; Mon, 10 Aug 2015 11:02:11 -0700 (PDT) X-AuditID: c1b4fb2d-f79176d00000321c-bb-55c8e7214223 Received: from ESESSHC010.ericsson.se (Unknown_Domain [153.88.253.124]) by sessmg23.ericsson.net (Symantec Mail Security) with SMTP id B0.39.12828.127E8C55; Mon, 10 Aug 2015 20:02:09 +0200 (CEST) Received: from ESESSMB209.ericsson.se ([169.254.9.36]) by ESESSHC010.ericsson.se ([153.88.183.48]) with mapi id 14.03.0210.002; Mon, 10 Aug 2015 20:02:08 +0200 From: Christer Holmberg To: Jonathan Lennox Thread-Topic: [rtcweb] Do we have consensus on not requiring rtcp-non-mux? Thread-Index: AQHQ0VmYDqTJnTo+aUua9ybij+PWb54FMj+AgAAwkMH//+CXAIAARQ4Q Date: Mon, 10 Aug 2015 18:02:07 +0000 Message-ID: <7594FB04B1934943A5C02806D1A2204B348EFB2F@ESESSMB209.ericsson.se> References: <8A69E109-3F93-4C61-95F2-375FF2103EAB@vidyo.com> <7594FB04B1934943A5C02806D1A2204B348EF447@ESESSMB209.ericsson.se> <58198CC2-984C-4236-8B90-D20BF050A241@vidyo.com> In-Reply-To: <58198CC2-984C-4236-8B90-D20BF050A241@vidyo.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [153.88.183.154] Content-Type: multipart/alternative; boundary="_000_7594FB04B1934943A5C02806D1A2204B348EFB2FESESSMB209erics_" MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFupnkeLIzCtJLcpLzFFi42KZGfG3Rlfx+YlQgxOTpSz2Lz7PbHFt+WtW i7X/2tkdmD0WbCr1WLLkJ5NH27M77AHMUVw2Kak5mWWpRfp2CVwZUy69YinYsomx4uLmWWwN jFfWMnYxcnJICJhIrNkzhwXCFpO4cG89WxcjF4eQwFFGiaaZZ8ASQgKLGSWm7zfuYuTgYBOw kOj+pw0SFhHQkLj47AMbiM0sEC7x/OQMJhBbWMBT4v/Sp6wQNV4Sr2ZcYIKw3SR2tt4CG8ki oCrx/ccLsF5eAV+JM28mM0Hs/cUoceLjZ7DjOAVsJb5/usMMYjMCHff91BomiGXiEreezGeC OFpAYsme88wQtqjEy8f/WCFsJYlFtz9D1edLPL/0iAlimaDEyZlPWCYwis5CMmoWkrJZSMpm Ab3MLKApsX6XPkSJosSU7ofsELaGROucuezI4gsY2VcxihanFhfnphsZ66UWZSYXF+fn6eWl lmxiBMbgwS2/dXcwrn7teIhRgINRiYc38ezxUCHWxLLiytxDjNIcLErivDM254UKCaQnlqRm p6YWpBbFF5XmpBYfYmTi4JRqYJQ7Ku58y4hdmFdrTjJv5uwDpsyVJfWXzxtsWtCXGhu2ZMaO 90rfVXLuqjydp7d9Ea/Azp9FdXJHMx+t6t+0/OQvFruZRtMLnVf8k/Ox5Nj0Ss97OkvMBN7e U+ffLJ8bknk6Y700KxPPSdlza9dU3Xa6FSAi3pTPfsqWcVKlU+f+vfFdE5w6vJRYijMSDbWY i4oTAdpHLHaiAgAA Archived-At: Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] Do we have consensus on not requiring rtcp-non-mux? X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 10 Aug 2015 18:02:15 -0000 --_000_7594FB04B1934943A5C02806D1A2204B348EFB2FESESSMB209erics_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SGksDQoNCj5UaGUgd2hvbGUgcG9pbnQgb2Ygc3VwcG9ydGluZyBub24tTVVYIG1vZGUgaXMgdG8g YWxsb3cgYW5zd2VyZXJzIHRvIGNob29zZSBub3QgdG8gaW5zZXJ0IHRoZSBTRFAgYXR0cmlidXRl Lg0KDQpGcm9tIGEgcHJvdG9jb2wgcGVyc3BlY3RpdmUsIHllcy4gQnV0LCBpZiB3ZSBzYXkgdGhh dCBhIFdlYlJUQyBlbnRpdHkgTVVTVCBzdXBwb3J0L3VzZSBydGNwLW11eCwgdGhlbiBpdCBtZWFu cyB0aGF0IGl0IE1VU1QgaW5jbHVkZSB0aGUgYXR0cmlidXRlIOKAkyBFVkVOIGlmIHRoZSBwcm90 b2NvbCBhbGxvd3MgaXQgbm90IHRvLg0KDQo+V2l0aCBvcHRpb24gMSwgdGhlIGlkZWEgaXMgdGhh dCBzb21lIGVuZHBvaW50cyB3aWxsIG9mZmVyIE1VWCwgYnV0IHN1cHBvcnQgZmFsbGJhY2sgdG8g bm9uLU1VWCBpZiB0aGUgcGVlciBjaG9vc2VzIG5vdCB0byBkbyBpdC4NCg0KTXkgdW5kZXJzdGFu ZGluZyBvZiBvcHRpb24gMSBpcyB0aGF0IHNvbWUgZW5kcG9pbnRzIHdpbGwgKk9OTFkqIGltcGxl bWVudCBNVVgsIGFuZCB3aWxsIE5PVCBmYWxsYmFjayB0byBub24tTVVYIGlmIHRoZSBwZWVyIChh IG5vbi1XZWJSVEMgZW50aXR5KSBjaG9vc2VzIG5vdCB0byBkbyBpdC4NCg0KPlNvbWUgb3RoZXIg ZW5kcG9pbnRzIHdpbGwgcmVxdWlyZSB0aGF0IE1VWCBiZSBzdXBwb3J0ZWQsIGFuZCBpZiBhIHBl ZXIgZG9lc27igJl0IHVuZGVyc3RhbmQgdGhpcyB0aGVuIHRoaW5ncyB3aWxsIGZhaWwgaW4gaW50 ZXJlc3RpbmcgPndheXMuDQoNCldlbGwsIHRoZSBlbmRwb2ludCB0aGF0IHdhbnRzIE1VWCB3aWxs IGhhdmUgdG8gdGVybWluYXRlIHRoZSBjYWxsLg0KDQo+SWYgSeKAmW0gKHNheSkgYSBnYXRld2F5 IHRoYXQgd291bGQgcmF0aGVyIGRvIG5vbi1NVVggKHRvIGtlZXAgbXkgbGlmZSBlYXNpZXIgd2hl biBnYXRld2F5aW5nIHRvIGxlZ2FjeSBlcXVpcG1lbnQpLCBidXQgaXMgd2lsbGluZyB0byA+ZG8g TVVYIGlmIG5lY2Vzc2FyeSwgSSBuZWVkIHRvIGtub3cgd2hpY2ggc29ydCBvZiBlbmRwb2ludCBJ 4oCZbSB0YWxraW5nIHRvLg0KDQpNeSB1bmRlcnN0YW5kaW5nIG9mICMxIGlzIHRoYXQgdGhlcmUg aXMgbm8gc3VjaCB0aGluZ3MgYXMg4oCcd291bGQgcmF0aGVyIGRvIG5vbi1NVVjigJ0uIEFzIGEg V2ViUlRDIGdhdGV3YXksIHlvdSB3b3VsZCBhbHdheXMgZG8gTVVYIChhdCBsZWFzdCB0b3dhcmRz IHRoZSBXZWJSVEMgZW5kcG9pbnRzKS4NCg0KPkhvd2V2ZXIsIGJvdGggdHlwZXMgb2YgZW5kcG9p bnRzIHdpbGwgaGF2ZSBpbnNlcnRlZCB0aGUgYXR0cmlidXRlIGluIHRoZWlyIG9mZmVyLg0KDQpB bmQsIGFzIGEgV2ViUlRDIGVuZHBvaW50LCB5b3Ugd2lsbCBhbHdheXMgaW5zZXJ0IHRoZSBhdHRy aWJ1dGUgaW4gdGhlIGFuc3dlci4NCg0KPklmIHlvdSByZXF1aXJlIHRoYXQgYWxsIGVudGl0aWVz IE1VU1QgYWx3YXlzIGluc2VydCB0aGUgU0RQIGF0dHJpYnV0ZSBpbiBib3RoIG9mZmVycyAqYW5k IGFuc3dlcnMqLCB0aGVuIHlvdeKAmXJlIGNob29zaW5nIG9wdGlvbiAyLiAoQSA+c3RhbmRhcmQg dGhhdCBzYXlzIOKAnHlvdSBNQVkgaGF2ZSBjb2RlIHRoYXQgaW1wbGVtZW50cyB0aGlzIG1vZGUs IGJ1dCB5b3UgTVVTVCBOT1QgZXZlciB1c2UgaXTigJ0gaXMgcHJldHR5IHBvaW50bGVzcy4pDQoN ClJlZ2FyZGluZyAjMiwgZW5kcG9pbnRzIGNhbiBpbXBsZW1lbnQgd2hhdGV2ZXIgdGhleSB3YW50 LiBUaGUgcG9pbnQgaXMgdGhhdCB0aGV5IHdvdWxkIG5ldmVyICpVU0UqIG5vbi1NVVguDQoNClJl Z2FyZHMsDQoNCkNocmlzdGVyDQoNCk9uIEF1ZyAxMCwgMjAxNSwgYXQgMTE6MzkgQU0sIENocmlz dGVyIEhvbG1iZXJnIDxjaHJpc3Rlci5ob2xtYmVyZ0Blcmljc3Nvbi5jb208bWFpbHRvOmNocmlz dGVyLmhvbG1iZXJnQGVyaWNzc29uLmNvbT4+IHdyb3RlOg0KDQpIaSBKb25hdGhhbiwNCg0KV2h5 IGNhbid0IHdlIHNpbXBseSBzYXkgdGhhdCBlbnRpdGllcyBNVVNUIGluc2VydCB0aGUgU0RQIGF0 dHJpYnV0ZSBpbiBvZmZlcnMgYW5kIGFuc3dlcnM/DQoNClJlZ2FyZHMsDQoNCkNocmlzdGVyDQoN ClNlbnQgZnJvbSBteSBXaW5kb3dzIFBob25lDQpfX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fXw0KRnJvbTogSm9uYXRoYW4gTGVubm94PG1haWx0bzpqb25hdGhhbkB2aWR5by5jb20+DQpT ZW50OiDigI4xMC/igI4wOC/igI4yMDE1IDE3OjQ2DQpUbzogR29vZ2xlLVBldGVyIFRoYXRjaGVy PG1haWx0bzpwdGhhdGNoZXJAZ29vZ2xlLmNvbT4NCkNjOiBydGN3ZWJAaWV0Zi5vcmc8bWFpbHRv OnJ0Y3dlYkBpZXRmLm9yZz4NClN1YmplY3Q6IFJlOiBbcnRjd2ViXSBEbyB3ZSBoYXZlIGNvbnNl bnN1cyBvbiBub3QgcmVxdWlyaW5nIHJ0Y3Atbm9uLW11eD8NCiMxIHNlZW1zIGJlc3QgdG8gbWUs IGJ1dCB0aGVyZSBuZWVkcyB0byBiZSBzb21lIHdlbGwtc3BlY2lmaWVkIHdheSBmb3IgSlMgYXBw bGljYXRpb25zIGFuZCBvZmZlci9hbnN3ZXIgcGVlcnMgdG8gZGlzY292ZXIvdW5kZXJzdGFuZCB3 aGV0aGVyIHJ0Y3Atbm9uLW11eCBpcyBpbmRlZWQgc3VwcG9ydGVkLiAgT3RoZXJ3aXNlIHRoZXJl 4oCZcyBubyBwcmFjdGljYWwgZGlmZmVyZW5jZSBiZXR3ZWVuICMxIGFuZCAjMi4NCg0KDQpPbiBB dWcgNywgMjAxNSwgYXQgNTozOSBQTSwgUGV0ZXIgVGhhdGNoZXIgPHB0aGF0Y2hlckBnb29nbGUu Y29tPG1haWx0bzpwdGhhdGNoZXJAZ29vZ2xlLmNvbT4+IHdyb3RlOg0KDQpBZnRlciBsb3RzIG9m IGRpc2N1c3Npb24sIGl0IGFwcGVhcnMgd2UgaGF2ZSB0aHJlZSBvcHRpb25zOg0KDQoxLiAgRW5k cG9pbnRzIE1BWSBpbXBsZW1lbnQgcnRjcC1ub24tbXV4ICh3ZSBjaGFuZ2UgdGhlIHNwZWMgYW5k IGNhbiBkZWxldGUgdGhlIHVnbHkgY29kZSkNCg0KMi4gIEVuZHBvaW50cyBNVVNUIE5PVCBpbXBs ZW1lbnQgcnRjcC1ub24tbXV4ICh3ZSBjaGFuZ2UgdGhlIHNwZWMgYW5kIG11c3QgZGVsZXRlIHRo ZSB1Z2x5IGNvZGUsIGFuZCBvdXIgbm9uLWNvbXBsaWFudCB1bnRpbCB3ZSBkbykNCg0KMy4gIEVu ZHBvaW50cyBNVVNUIGltcGxlbWVudCBydGNwLW5vbi1tdXggKHdlIGRvbid0IGNoYW5nZSB0aGUg c3BlYyBhbmQga2VlcCBhcm91bmQgdGhlIHVnbHkgY29kZSkNCg0KDQpNeSByZWFkaW5nIG9mIHRo ZSBkaXNjdXNzaW9uIGlzIHRoYXQgbW9zdCBwZW9wbGUgd2FudCAjMSBvciAjMiwgYW5kIHZlcnkg ZmV3IHBlb3BsZSBzdGlsbCB3YW50ICMzLiAgIEJldHdlZW4gIzEgYW5kICMyLCB3aGlsZSBzb21l IHBlb3BsZSB3b3VsZCBwcmVmZXIgIzIsIHRoZXJlIGFyZSBnb29kIHJlYXNvbnMgdG8ganVzdCBk byAjMSwgYW5kIG1vc3Qgc2VlbSB0byBwcmVmZXIgIzEuICBGdXJ0aGVyLCBJJ20gZ3Vlc3Npbmcg dGhhdCBtb3N0IHBlb3BsZSB3aG8gd2FudGVkICMyIGNvdWxkIGxpdmUgd2l0aCAjMS4NCg0KDQpU TDtEUjogIEkgdGhpbmsgd2UgbWF5IGhhdmUgcm91Z2ggY29uc2Vuc3VzIG9uICMxLCBzYXlpbmcg ZW5kcG9pbnRzIE1BWSBydGNwLW5vbi1tdXggKGJ1dCBtYXkgY2hvb3NlIHRvIGRlbGV0ZSBhbGwg dGhhdCB1Z2x5IGNvZGUgaW5zdGVhZCkuDQoNCg0KU28sIGlzIGV2ZXJ5b25lIGhhcHB5IHdpdGgg IzE/DQoNCg0KDQpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f Xw0KcnRjd2ViIG1haWxpbmcgbGlzdA0KcnRjd2ViQGlldGYub3JnPG1haWx0bzpydGN3ZWJAaWV0 Zi5vcmc+DQpodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL3J0Y3dlYg0KDQoN Cg== --_000_7594FB04B1934943A5C02806D1A2204B348EFB2FESESSMB209erics_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPCEtLVtp ZiAhbXNvXT48c3R5bGU+dlw6KiB7YmVoYXZpb3I6dXJsKCNkZWZhdWx0I1ZNTCk7fQ0Kb1w6KiB7 YmVoYXZpb3I6dXJsKCNkZWZhdWx0I1ZNTCk7fQ0Kd1w6KiB7YmVoYXZpb3I6dXJsKCNkZWZhdWx0 I1ZNTCk7fQ0KLnNoYXBlIHtiZWhhdmlvcjp1cmwoI2RlZmF1bHQjVk1MKTt9DQo8L3N0eWxlPjwh W2VuZGlmXS0tPjxzdHlsZT48IS0tDQovKiBGb250IERlZmluaXRpb25zICovDQpAZm9udC1mYWNl DQoJe2ZvbnQtZmFtaWx5OiJDYW1icmlhIE1hdGgiOw0KCXBhbm9zZS0xOjIgNCA1IDMgNSA0IDYg MyAyIDQ7fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseTpDYWxpYnJpOw0KCXBhbm9zZS0xOjIg MTUgNSAyIDIgMiA0IDMgMiA0O30NCi8qIFN0eWxlIERlZmluaXRpb25zICovDQpwLk1zb05vcm1h bCwgbGkuTXNvTm9ybWFsLCBkaXYuTXNvTm9ybWFsDQoJe21hcmdpbjowY207DQoJbWFyZ2luLWJv dHRvbTouMDAwMXB0Ow0KCWZvbnQtc2l6ZToxMi4wcHQ7DQoJZm9udC1mYW1pbHk6IlRpbWVzIE5l dyBSb21hbiIsc2VyaWY7fQ0KYTpsaW5rLCBzcGFuLk1zb0h5cGVybGluaw0KCXttc28tc3R5bGUt cHJpb3JpdHk6OTk7DQoJY29sb3I6Ymx1ZTsNCgl0ZXh0LWRlY29yYXRpb246dW5kZXJsaW5lO30N CmE6dmlzaXRlZCwgc3Bhbi5Nc29IeXBlcmxpbmtGb2xsb3dlZA0KCXttc28tc3R5bGUtcHJpb3Jp dHk6OTk7DQoJY29sb3I6cHVycGxlOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0Kc3Bh bi5FbWFpbFN0eWxlMTcNCgl7bXNvLXN0eWxlLXR5cGU6cGVyc29uYWw7DQoJZm9udC1mYW1pbHk6 IkNhbGlicmkiLHNhbnMtc2VyaWY7DQoJY29sb3I6IzFGNDk3RDt9DQpzcGFuLkVtYWlsU3R5bGUx OA0KCXttc28tc3R5bGUtdHlwZTpwZXJzb25hbC1jb21wb3NlOw0KCWZvbnQtZmFtaWx5OiJDYWxp YnJpIixzYW5zLXNlcmlmOw0KCWNvbG9yOndpbmRvd3RleHQ7fQ0KLk1zb0NocERlZmF1bHQNCgl7 bXNvLXN0eWxlLXR5cGU6ZXhwb3J0LW9ubHk7DQoJZm9udC1zaXplOjEwLjBwdDt9DQpAcGFnZSBX b3JkU2VjdGlvbjENCgl7c2l6ZTo2MTIuMHB0IDc5Mi4wcHQ7DQoJbWFyZ2luOjcyLjBwdCA3Mi4w cHQgNzIuMHB0IDcyLjBwdDt9DQpkaXYuV29yZFNlY3Rpb24xDQoJe3BhZ2U6V29yZFNlY3Rpb24x O30NCi0tPjwvc3R5bGU+PCEtLVtpZiBndGUgbXNvIDldPjx4bWw+DQo8bzpzaGFwZWRlZmF1bHRz IHY6ZXh0PSJlZGl0IiBzcGlkbWF4PSIxMDI2IiAvPg0KPC94bWw+PCFbZW5kaWZdLS0+PCEtLVtp ZiBndGUgbXNvIDldPjx4bWw+DQo8bzpzaGFwZWxheW91dCB2OmV4dD0iZWRpdCI+DQo8bzppZG1h cCB2OmV4dD0iZWRpdCIgZGF0YT0iMSIgLz4NCjwvbzpzaGFwZWxheW91dD48L3htbD48IVtlbmRp Zl0tLT4NCjwvaGVhZD4NCjxib2R5IGxhbmc9IkVOLUdCIiBsaW5rPSJibHVlIiB2bGluaz0icHVy cGxlIj4NCjxkaXYgY2xhc3M9IldvcmRTZWN0aW9uMSI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48 c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1 b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RDttc28tZmFyZWFzdC1sYW5ndWFnZTpFTi1VUyI+ SGksPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJz cDs8L286cD48L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Jmd0O1RoZSB3aG9sZSBw b2ludCBvZiBzdXBwb3J0aW5nIG5vbi1NVVggbW9kZSBpcyB0byBhbGxvdyBhbnN3ZXJlcnMgdG8g Y2hvb3NlIG5vdCB0byBpbnNlcnQgdGhlIFNEUCBhdHRyaWJ1dGUuPG86cD48L286cD48L3A+DQo8 L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQt ZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZiI+RnJvbSBhIHByb3RvY29sIHBl cnNwZWN0aXZlLCB5ZXMuIEJ1dCwgaWYgd2Ugc2F5IHRoYXQgYSBXZWJSVEMgZW50aXR5IE1VU1Qg c3VwcG9ydC91c2UgcnRjcC1tdXgsIHRoZW4gaXQgbWVhbnMgdGhhdCBpdCBNVVNUIGluY2x1ZGUg dGhlIGF0dHJpYnV0ZSDigJMgRVZFTiBpZiB0aGUgcHJvdG9jb2wgYWxsb3dzDQogaXQgbm90IHRv LjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxl PSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1z ZXJpZiI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+Jmd0O1dpdGggb3B0aW9uIDEsIHRoZSBpZGVhIGlzIHRoYXQgc29tZSBl bmRwb2ludHMgd2lsbCBvZmZlciBNVVgsIGJ1dCBzdXBwb3J0IGZhbGxiYWNrIHRvIG5vbi1NVVgg aWYgdGhlIHBlZXIgY2hvb3NlcyBub3QgdG8gZG8gaXQuPG86cD48L286cD48L3A+DQo8L2Rpdj4N CjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5 OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZiI+TXkgdW5kZXJzdGFuZGluZyBvZiBvcHRp b24gMSBpcyB0aGF0IHNvbWUgZW5kcG9pbnRzIHdpbGwgKjxiPk9OTFk8L2I+KiBpbXBsZW1lbnQg TVVYLCBhbmQgd2lsbCBOT1QgZmFsbGJhY2sgdG8gbm9uLU1VWCBpZiB0aGUgcGVlciAoYSBub24t V2ViUlRDIGVudGl0eSkgY2hvb3NlcyBub3QgdG8gZG8gaXQuDQo8bzpwPjwvbzpwPjwvc3Bhbj48 L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtm b250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWYiPjxvOnA+Jm5ic3A7PC9v OnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPiZndDtT b21lIG90aGVyIGVuZHBvaW50cyB3aWxsIHJlcXVpcmUgdGhhdCBNVVggYmUgc3VwcG9ydGVkLCBh bmQgaWYgYSBwZWVyIGRvZXNu4oCZdCB1bmRlcnN0YW5kIHRoaXMgdGhlbiB0aGluZ3Mgd2lsbCBm YWlsIGluIGludGVyZXN0aW5nICZndDt3YXlzLjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2 Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVv dDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWYiPldlbGwsIHRoZSBlbmRwb2ludCB0aGF0IHdhbnRz IE1VWCB3aWxsIGhhdmUgdG8gdGVybWluYXRlIHRoZSBjYWxsLg0KPG86cD48L286cD48L3NwYW4+ PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7 Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmIj48bzpwPiZuYnNwOzwv bzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4mZ3Q7 SWYgSeKAmW0gKHNheSkgYSBnYXRld2F5IHRoYXQgd291bGQgcmF0aGVyIGRvIG5vbi1NVVggKHRv IGtlZXAgbXkgbGlmZSBlYXNpZXIgd2hlbiBnYXRld2F5aW5nIHRvIGxlZ2FjeSBlcXVpcG1lbnQp LCBidXQgaXMgd2lsbGluZyB0byAmZ3Q7ZG8gTVVYIGlmIG5lY2Vzc2FyeSwgSSBuZWVkIHRvIGtu b3cgd2hpY2ggc29ydCBvZiBlbmRwb2ludCBJ4oCZbSB0YWxraW5nIHRvLjxvOnA+PC9vOnA+PC9w Pg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48 L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtm b250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWYiPk15IHVuZGVyc3RhbmRp bmcgb2YgIzEgaXMgdGhhdCB0aGVyZSBpcyBubyBzdWNoIHRoaW5ncyBhcyDigJx3b3VsZCByYXRo ZXIgZG8gbm9uLU1VWOKAnS4gQXMgYSBXZWJSVEMgZ2F0ZXdheSwgeW91IHdvdWxkIGFsd2F5cyBk byBNVVggKGF0IGxlYXN0IHRvd2FyZHMgdGhlIFdlYlJUQyBlbmRwb2ludHMpLjxvOnA+PC9vOnA+ PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6 MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZiI+PG86cD4m bmJzcDs8L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+Jmd0O0hvd2V2ZXIsIGJvdGggdHlwZXMgb2YgZW5kcG9pbnRzIHdpbGwgaGF2ZSBpbnNlcnRl ZCB0aGUgYXR0cmlidXRlIGluIHRoZWlyIG9mZmVyLjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8 ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTom cXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWYiPkFuZCwgYXMgYSBXZWJSVEMgZW5kcG9pbnQs IHlvdSB3aWxsIGFsd2F5cyBpbnNlcnQgdGhlIGF0dHJpYnV0ZSBpbiB0aGUgYW5zd2VyLjxvOnA+ PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250 LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZiI+ PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+Jmd0O0lmIHlvdSByZXF1aXJlIHRoYXQgYWxsIGVudGl0aWVzIE1VU1QgYWx3YXlz IGluc2VydCB0aGUgU0RQIGF0dHJpYnV0ZSBpbiBib3RoIG9mZmVycyAqYW5kIGFuc3dlcnMqLCB0 aGVuIHlvdeKAmXJlIGNob29zaW5nIG9wdGlvbiAyLiAoQSAmZ3Q7c3RhbmRhcmQgdGhhdCBzYXlz IOKAnHlvdSBNQVkgaGF2ZSBjb2RlIHRoYXQgaW1wbGVtZW50cyB0aGlzIG1vZGUsIGJ1dCB5b3Ug TVVTVCBOT1QgZXZlciB1c2UgaXTigJ0gaXMgcHJldHR5DQogcG9pbnRsZXNzLik8bzpwPjwvbzpw PjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9v OnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4w cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmIj5SZWdhcmRpbmcg IzIsIGVuZHBvaW50cyBjYW4gaW1wbGVtZW50IHdoYXRldmVyIHRoZXkgd2FudC4gVGhlIHBvaW50 IGlzIHRoYXQgdGhleSB3b3VsZCBuZXZlciAqPGI+VVNFPC9iPiogbm9uLU1VWC48bzpwPjwvbzpw Pjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9v OnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4w cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmIj5SZWdhcmRzLDxv OnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJm b250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJp ZiI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNw YW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90 OyxzYW5zLXNlcmlmIj5DaHJpc3RlcjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90 O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZiI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0K PGRpdj4NCjxibG9ja3F1b3RlIHN0eWxlPSJtYXJnaW4tdG9wOjUuMHB0O21hcmdpbi1ib3R0b206 NS4wcHQiPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPk9uIEF1ZyAxMCwgMjAxNSwgYXQg MTE6MzkgQU0sIENocmlzdGVyIEhvbG1iZXJnICZsdDs8YSBocmVmPSJtYWlsdG86Y2hyaXN0ZXIu aG9sbWJlcmdAZXJpY3Nzb24uY29tIj5jaHJpc3Rlci5ob2xtYmVyZ0Blcmljc3Nvbi5jb208L2E+ Jmd0OyB3cm90ZTo8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ PG86cD4mbmJzcDs8L286cD48L3A+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6 JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmIj5IaSBKb25hdGhhbiw8YnI+DQo8YnI+DQpX aHkgY2FuJ3Qgd2Ugc2ltcGx5IHNheSB0aGF0IGVudGl0aWVzIE1VU1QgaW5zZXJ0IHRoZSBTRFAg YXR0cmlidXRlIGluIG9mZmVycyBhbmQgYW5zd2Vycz88YnI+DQo8YnI+DQpSZWdhcmRzLDxicj4N Cjxicj4NCkNocmlzdGVyPGJyPg0KPGJyPg0KU2VudCBmcm9tIG15IFdpbmRvd3MgUGhvbmU8bzpw PjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxkaXYgY2xhc3M9Ik1z b05vcm1hbCIgYWxpZ249ImNlbnRlciIgc3R5bGU9InRleHQtYWxpZ246Y2VudGVyIj4NCjxociBz aXplPSIzIiB3aWR0aD0iMTAwJSIgYWxpZ249ImNlbnRlciI+DQo8L2Rpdj4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tYm90dG9tOjEyLjBwdCI+PGI+PHNwYW4gc3R5bGU9ImZv bnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlm Ij5Gcm9tOg0KPC9zcGFuPjwvYj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZh bWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWYiPjxhIGhyZWY9Im1haWx0bzpqb25h dGhhbkB2aWR5by5jb20iPkpvbmF0aGFuIExlbm5veDwvYT48L3NwYW4+PGJyPg0KPGI+PHNwYW4g c3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90Oyxz YW5zLXNlcmlmIj5TZW50OiA8L3NwYW4+PC9iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0 O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZiI+4oCOMTAv4oCOMDgv 4oCOMjAxNSAxNzo0Njwvc3Bhbj48YnI+DQo8Yj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBw dDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWYiPlRvOiA8L3NwYW4+ PC9iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGli cmkmcXVvdDssc2Fucy1zZXJpZiI+PGEgaHJlZj0ibWFpbHRvOnB0aGF0Y2hlckBnb29nbGUuY29t Ij5Hb29nbGUtUGV0ZXIgVGhhdGNoZXI8L2E+PC9zcGFuPjxicj4NCjxiPjxzcGFuIHN0eWxlPSJm b250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJp ZiI+Q2M6IDwvc3Bhbj48L2I+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1p bHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmIj48YSBocmVmPSJtYWlsdG86cnRjd2Vi QGlldGYub3JnIj5ydGN3ZWJAaWV0Zi5vcmc8L2E+PC9zcGFuPjxicj4NCjxiPjxzcGFuIHN0eWxl PSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1z ZXJpZiI+U3ViamVjdDogPC9zcGFuPg0KPC9iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0 O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZiI+UmU6IFtydGN3ZWJd IERvIHdlIGhhdmUgY29uc2Vuc3VzIG9uIG5vdCByZXF1aXJpbmcgcnRjcC1ub24tbXV4Pzwvc3Bh bj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPiMx IHNlZW1zIGJlc3QgdG8gbWUsIGJ1dCB0aGVyZSBuZWVkcyB0byBiZSBzb21lIHdlbGwtc3BlY2lm aWVkIHdheSBmb3IgSlMgYXBwbGljYXRpb25zIGFuZCBvZmZlci9hbnN3ZXIgcGVlcnMgdG8gZGlz Y292ZXIvdW5kZXJzdGFuZCB3aGV0aGVyIHJ0Y3Atbm9uLW11eCBpcyBpbmRlZWQgc3VwcG9ydGVk LiAmbmJzcDtPdGhlcndpc2UgdGhlcmXigJlzIG5vIHByYWN0aWNhbCBkaWZmZXJlbmNlIGJldHdl ZW4gIzEgYW5kICMyLjxvOnA+PC9vOnA+PC9wPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi Pjxicj4NCjxicj4NCjxvOnA+PC9vOnA+PC9wPg0KPGJsb2NrcXVvdGUgc3R5bGU9Im1hcmdpbi10 b3A6NS4wcHQ7bWFyZ2luLWJvdHRvbTo1LjBwdCI+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+T24gQXVnIDcsIDIwMTUsIGF0IDU6MzkgUE0sIFBldGVyIFRoYXRjaGVyICZsdDs8YSBocmVm PSJtYWlsdG86cHRoYXRjaGVyQGdvb2dsZS5jb20iPnB0aGF0Y2hlckBnb29nbGUuY29tPC9hPiZn dDsgd3JvdGU6PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxv OnA+Jm5ic3A7PC9vOnA+PC9wPg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7LHNhbnMtc2Vy aWYiPkFmdGVyIGxvdHMgb2YgZGlzY3Vzc2lvbiwgaXQgYXBwZWFycyB3ZSBoYXZlIHRocmVlIG9w dGlvbnM6PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7LHNhbnMt c2VyaWYiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtBcmlhbCZxdW90 OyxzYW5zLXNlcmlmIj4xLiZuYnNwOyBFbmRwb2ludHMgTUFZIGltcGxlbWVudCBydGNwLW5vbi1t dXggKHdlIGNoYW5nZSB0aGUgc3BlYyBhbmQgY2FuIGRlbGV0ZSB0aGUgdWdseSBjb2RlKTxvOnA+ PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxz cGFuIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtBcmlhbCZxdW90OyxzYW5zLXNlcmlmIj48bzpw PiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDssc2Fucy1zZXJp ZiI+Mi4mbmJzcDsgRW5kcG9pbnRzIE1VU1QgTk9UIGltcGxlbWVudCBydGNwLW5vbi1tdXggKHdl IGNoYW5nZSB0aGUgc3BlYyBhbmQgbXVzdCBkZWxldGUgdGhlIHVnbHkgY29kZSwgYW5kIG91ciBu b24tY29tcGxpYW50IHVudGlsIHdlIGRvKTxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0K PGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTomcXVv dDtBcmlhbCZxdW90OyxzYW5zLXNlcmlmIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8 L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1mYW1p bHk6JnF1b3Q7QXJpYWwmcXVvdDssc2Fucy1zZXJpZiI+My4mbmJzcDsgRW5kcG9pbnRzIE1VU1Qg aW1wbGVtZW50IHJ0Y3Atbm9uLW11eCAod2UgZG9uJ3QgY2hhbmdlIHRoZSBzcGVjIGFuZCBrZWVw IGFyb3VuZCB0aGUgdWdseSBjb2RlKTxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRp dj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtB cmlhbCZxdW90OyxzYW5zLXNlcmlmIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rp dj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6 JnF1b3Q7QXJpYWwmcXVvdDssc2Fucy1zZXJpZiI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9w Pg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQt ZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7LHNhbnMtc2VyaWYiPk15IHJlYWRpbmcgb2YgdGhlIGRp c2N1c3Npb24gaXMgdGhhdCBtb3N0IHBlb3BsZSB3YW50ICMxIG9yICMyLCBhbmQgdmVyeSBmZXcg cGVvcGxlIHN0aWxsIHdhbnQgIzMuICZuYnNwOyBCZXR3ZWVuICMxIGFuZCAjMiwgd2hpbGUgc29t ZSBwZW9wbGUgd291bGQgcHJlZmVyICMyLCB0aGVyZSBhcmUgZ29vZCByZWFzb25zIHRvIGp1c3Qg ZG8gIzEsDQogYW5kIG1vc3Qgc2VlbSB0byBwcmVmZXIgIzEuJm5ic3A7IEZ1cnRoZXIsIEknbSBn dWVzc2luZyB0aGF0IG1vc3QgcGVvcGxlIHdobyB3YW50ZWQgIzIgY291bGQgbGl2ZSB3aXRoICMx LjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtBcmlhbCZxdW90OyxzYW5zLXNlcmlm Ij48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDssc2Fu cy1zZXJpZiI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1 b3Q7LHNhbnMtc2VyaWYiPlRMO0RSOiAmbmJzcDtJIHRoaW5rIHdlIG1heSBoYXZlIHJvdWdoIGNv bnNlbnN1cyBvbiAjMSwgc2F5aW5nIGVuZHBvaW50cyBNQVkgcnRjcC1ub24tbXV4IChidXQgbWF5 IGNob29zZSB0byBkZWxldGUgYWxsIHRoYXQgdWdseSBjb2RlIGluc3RlYWQpLiAmbmJzcDs8bzpw PjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48 c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDssc2Fucy1zZXJpZiI+PG86 cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7LHNhbnMtc2Vy aWYiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtBcmlhbCZxdW90Oyxz YW5zLXNlcmlmIj5TbywgaXMgZXZlcnlvbmUgaGFwcHkgd2l0aCAjMT88bzpwPjwvbzpwPjwvc3Bh bj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0i Zm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDssc2Fucy1zZXJpZiI+PG86cD4mbmJzcDs8L286 cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4g c3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7LHNhbnMtc2VyaWYiPjxvOnA+Jm5i c3A7PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtBcmlhbCZxdW90OyxzYW5zLXNlcmlmIj48 bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX188 YnI+DQpydGN3ZWIgbWFpbGluZyBsaXN0PGJyPg0KPGEgaHJlZj0ibWFpbHRvOnJ0Y3dlYkBpZXRm Lm9yZyI+cnRjd2ViQGlldGYub3JnPC9hPjxicj4NCjxhIGhyZWY9Imh0dHBzOi8vd3d3LmlldGYu b3JnL21haWxtYW4vbGlzdGluZm8vcnRjd2ViIj5odHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFu L2xpc3RpbmZvL3J0Y3dlYjwvYT48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9ibG9ja3F1b3Rl Pg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwv ZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvYmxvY2txdW90ZT4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjwvYm9keT4NCjwvaHRtbD4N Cg== --_000_7594FB04B1934943A5C02806D1A2204B348EFB2FESESSMB209erics_-- From nobody Mon Aug 10 11:24:43 2015 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 43A371B3B60 for ; Mon, 10 Aug 2015 11:24:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.496 X-Spam-Level: X-Spam-Status: No, score=-1.496 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, IP_NOT_FRIENDLY=0.334, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_SORBS_WEB=0.77, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xoE5ZPpWVpgw for ; Mon, 10 Aug 2015 11:24:40 -0700 (PDT) Received: from mx0a-00198e01.pphosted.com (mx0a-00198e01.pphosted.com [67.231.149.202]) (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 8DC321B3B1A for ; Mon, 10 Aug 2015 11:24:20 -0700 (PDT) Received: from pps.filterd (m0073109.ppops.net [127.0.0.1]) by mx0a-00198e01.pphosted.com (8.15.0.59/8.14.7) with SMTP id t7AILWJI028489; Mon, 10 Aug 2015 14:24:16 -0400 Received: from mail.vidyo.com ([162.209.16.214]) by mx0a-00198e01.pphosted.com with ESMTP id 1w1e1wm39f-2 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Mon, 10 Aug 2015 14:24:16 -0400 Received: from 492132-EXCH1.vidyo.com ([fe80::50:56ff:fe85:4f77]) by 492133-EXCH2.vidyo.com ([fe80::50:56ff:fe85:6b62%13]) with mapi id 14.03.0195.001; Mon, 10 Aug 2015 13:24:14 -0500 From: Jonathan Lennox To: Christer Holmberg Thread-Topic: [rtcweb] Do we have consensus on not requiring rtcp-non-mux? Thread-Index: AQHQ03qu29AkjWHTmE6I1pAkHgCelJ4Fo2SAgAAO+oCAAAIsAIAAJamAgAAGO4A= Date: Mon, 10 Aug 2015 18:24:14 +0000 Message-ID: References: <8A69E109-3F93-4C61-95F2-375FF2103EAB@vidyo.com> <7594FB04B1934943A5C02806D1A2204B348EF447@ESESSMB209.ericsson.se> <58198CC2-984C-4236-8B90-D20BF050A241@vidyo.com> <7594FB04B1934943A5C02806D1A2204B348EFB2F@ESESSMB209.ericsson.se> In-Reply-To: <7594FB04B1934943A5C02806D1A2204B348EFB2F@ESESSMB209.ericsson.se> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [160.79.219.114] Content-Type: multipart/alternative; boundary="_000_D9B4F280E9FE401C81D20FCE3580BF82vidyocom_" MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:5.14.151, 1.0.33, 0.0.0000 definitions=2015-08-10_03:2015-08-10,2015-08-10,1970-01-01 signatures=0 X-Proofpoint-Spam-Details: rule=outbound_notspam policy=outbound score=0 spamscore=0 suspectscore=0 phishscore=0 adultscore=0 bulkscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=7.0.1-1506180000 definitions=main-1508100268 Archived-At: Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] Do we have consensus on not requiring rtcp-non-mux? X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 10 Aug 2015 18:24:42 -0000 --_000_D9B4F280E9FE401C81D20FCE3580BF82vidyocom_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 QXJlIHlvdSBzZXJpb3VzbHkgYWR2b2NhdGluZyDigJxNQVkgaW1wbGVtZW50LCBNVVNUIE5PVCB1 c2XigJ0/ICBIb3cgZG9lcyB0aGF0IG1ha2UgYW55IHNlbnNlIGF0IGFsbD8NCg0KQXMgSSB1bmRl cnN0b29kIFBldGVy4oCZcyBvcmlnaW5hbCBvcHRpb24gMSwgaGUgd2FzIHByb3Bvc2luZyB0byBj aGFuZ2UgdGhlIHNwZWMgdG8gYWxsb3cgdHdvIHR5cGVzIG9mIGltcGxlbWVudGF0aW9uczoNCg0K MS4gRW5kcG9pbnRzIHRoYXQgYWx3YXlzIG9mZmVyIG11eCwgYnV0IGFyZSBwcmVwYXJlZCBmb3Ig YW4gYW5zd2VyIHRoYXQgZGVjbGluZXMgdG8gZG8gaXQsIGF0IHdoaWNoIHBvaW50IHRoZXkgZmFs bCBiYWNrIHRvIG5vbi1tdXguIChUaGUgY3VycmVudCBkZWZhdWx0IGJlaGF2aW9yLCBhbmQgdGhl IGJlaGF2aW9yIHJlcXVpcmVkIGJ5IFJGQyA1NzYxLikNCg0KMi4gRW5kcG9pbnRzIHRoYXQgYWx3 YXlzIG9mZmVyIG11eCwgaW4gYSB3YXkgc3VjaCB0aGF0IHRoZXJlIGlzIG5vIHdheSB0byBmYWxs IGJhY2sgdG8gbm9uLW11eC4gIE5haXZlIGludGVyb3Agd2l0aCBhIG5vbi1ydGNwLW11eCBlbmRw b2ludCwgb3Igd2l0aCBhbiBlbmRwb2ludCB0aGF0IGRvZXNu4oCZdCB3YW50IHRvIGRvIG11eCwg d2lsbCBmYWlsLiAoVGhlIGN1cnJlbnQgcnRjcE11eFBvbGljeToicmVxdWlyZSIgYmVoYXZpb3Iu KQ0KDQpJZiB5b3Ugc2F5IHRoYXQgbm8gZW5kcG9pbnQgY2FuIGV2ZXIgZG8gZmFsbGJhY2sgdG8g bm9uLU1VWCwgSSBkb27igJl0IHNlZSB3aGF0IHRoZSBwb2ludCBpcy4gIFlvdeKAmXJlIGluc3Rl YWQgYWR2b2NhdGluZyBmb3IgUGV0ZXLigJlzIG9wdGlvbiAyLg0KDQpBcyBJIG1lbnRpb25lZCBl YXJsaWVyIGluIHRoaXMgdGhyZWFkLCBvbmUgc29sdXRpb24gdG8gbXkgcHJvYmxlbSDigJQgd2hp Y2ggSSBkb27igJl0IGxpa2UgdGhpcyBiZWNhdXNlIGl04oCZcyBtaXhpbmcgdXAgZmVhdHVyZXMg d2hpY2ggSU1PIHNob3VsZCBiZSBvcnRob2dvbmFsLCBidXQgSSB3b3VsZCBiZSBva2F5IHdpdGgg 4oCUIHdvdWxkIGJlIHRvIHNheSBzb21ldGhpbmcgbGlrZSDigJxvZmZlcnMgdGhhdCBzdXBwb3J0 IGZhbGxiYWNrIHRvIG5vbi1SVENQLW11eCBNVVNUIGluY2x1ZGUgc2VwYXJhdGUgSUNFIGNhbmRp ZGF0ZXMgZm9yIFJUQ1AsIGkuZS4gb24gY29tcG9uZW50IDI7IG9mZmVycyB0aGF0IGRvIG5vdCBz dXBwb3J0IHN1Y2ggZmFsbGJhY2sgTVVTVCBOT1QgaW5jbHVkZSBzdWNoIGNhbmRpZGF0ZXMu4oCd DQoNClRoZSBvbmx5IGRpZmZpY3VsdHkgd2l0aCB0aGlzIHNvbHV0aW9uIGlzIHRoYXQgaXQgY2Fu IGJlIGFtYmlndW91cyB3aGVuIHRyaWNrbGUgSUNFIGlzIGJlaW5nIHVzZWQsIHNpbmNlIGFuIG9m ZmVyIG1pZ2h0IG5vdCBpbmNsdWRlIGFueSBjYW5kaWRhdGVzIGF0IGFsbC4NCg0KT24gQXVnIDEw LCAyMDE1LCBhdCAyOjAyIFBNLCBDaHJpc3RlciBIb2xtYmVyZyA8Y2hyaXN0ZXIuaG9sbWJlcmdA ZXJpY3Nzb24uY29tPG1haWx0bzpjaHJpc3Rlci5ob2xtYmVyZ0Blcmljc3Nvbi5jb20+PiB3cm90 ZToNCg0KSGksDQoNCj5UaGUgd2hvbGUgcG9pbnQgb2Ygc3VwcG9ydGluZyBub24tTVVYIG1vZGUg aXMgdG8gYWxsb3cgYW5zd2VyZXJzIHRvIGNob29zZSBub3QgdG8gaW5zZXJ0IHRoZSBTRFAgYXR0 cmlidXRlLg0KDQpGcm9tIGEgcHJvdG9jb2wgcGVyc3BlY3RpdmUsIHllcy4gQnV0LCBpZiB3ZSBz YXkgdGhhdCBhIFdlYlJUQyBlbnRpdHkgTVVTVCBzdXBwb3J0L3VzZSBydGNwLW11eCwgdGhlbiBp dCBtZWFucyB0aGF0IGl0IE1VU1QgaW5jbHVkZSB0aGUgYXR0cmlidXRlIOKAkyBFVkVOIGlmIHRo ZSBwcm90b2NvbCBhbGxvd3MgaXQgbm90IHRvLg0KDQo+V2l0aCBvcHRpb24gMSwgdGhlIGlkZWEg aXMgdGhhdCBzb21lIGVuZHBvaW50cyB3aWxsIG9mZmVyIE1VWCwgYnV0IHN1cHBvcnQgZmFsbGJh Y2sgdG8gbm9uLU1VWCBpZiB0aGUgcGVlciBjaG9vc2VzIG5vdCB0byBkbyBpdC4NCg0KTXkgdW5k ZXJzdGFuZGluZyBvZiBvcHRpb24gMSBpcyB0aGF0IHNvbWUgZW5kcG9pbnRzIHdpbGwgKk9OTFkq IGltcGxlbWVudCBNVVgsIGFuZCB3aWxsIE5PVCBmYWxsYmFjayB0byBub24tTVVYIGlmIHRoZSBw ZWVyIChhIG5vbi1XZWJSVEMgZW50aXR5KSBjaG9vc2VzIG5vdCB0byBkbyBpdC4NCg0KPlNvbWUg b3RoZXIgZW5kcG9pbnRzIHdpbGwgcmVxdWlyZSB0aGF0IE1VWCBiZSBzdXBwb3J0ZWQsIGFuZCBp ZiBhIHBlZXIgZG9lc27igJl0IHVuZGVyc3RhbmQgdGhpcyB0aGVuIHRoaW5ncyB3aWxsIGZhaWwg aW4gaW50ZXJlc3RpbmcgPndheXMuDQoNCldlbGwsIHRoZSBlbmRwb2ludCB0aGF0IHdhbnRzIE1V WCB3aWxsIGhhdmUgdG8gdGVybWluYXRlIHRoZSBjYWxsLg0KDQo+SWYgSeKAmW0gKHNheSkgYSBn YXRld2F5IHRoYXQgd291bGQgcmF0aGVyIGRvIG5vbi1NVVggKHRvIGtlZXAgbXkgbGlmZSBlYXNp ZXIgd2hlbiBnYXRld2F5aW5nIHRvIGxlZ2FjeSBlcXVpcG1lbnQpLCBidXQgaXMgd2lsbGluZyB0 byA+ZG8gTVVYIGlmIG5lY2Vzc2FyeSwgSSBuZWVkIHRvIGtub3cgd2hpY2ggc29ydCBvZiBlbmRw b2ludCBJ4oCZbSB0YWxraW5nIHRvLg0KDQpNeSB1bmRlcnN0YW5kaW5nIG9mICMxIGlzIHRoYXQg dGhlcmUgaXMgbm8gc3VjaCB0aGluZ3MgYXMg4oCcd291bGQgcmF0aGVyIGRvIG5vbi1NVVjigJ0u IEFzIGEgV2ViUlRDIGdhdGV3YXksIHlvdSB3b3VsZCBhbHdheXMgZG8gTVVYIChhdCBsZWFzdCB0 b3dhcmRzIHRoZSBXZWJSVEMgZW5kcG9pbnRzKS4NCg0KPkhvd2V2ZXIsIGJvdGggdHlwZXMgb2Yg ZW5kcG9pbnRzIHdpbGwgaGF2ZSBpbnNlcnRlZCB0aGUgYXR0cmlidXRlIGluIHRoZWlyIG9mZmVy Lg0KDQpBbmQsIGFzIGEgV2ViUlRDIGVuZHBvaW50LCB5b3Ugd2lsbCBhbHdheXMgaW5zZXJ0IHRo ZSBhdHRyaWJ1dGUgaW4gdGhlIGFuc3dlci4NCg0KPklmIHlvdSByZXF1aXJlIHRoYXQgYWxsIGVu dGl0aWVzIE1VU1QgYWx3YXlzIGluc2VydCB0aGUgU0RQIGF0dHJpYnV0ZSBpbiBib3RoIG9mZmVy cyAqYW5kIGFuc3dlcnMqLCB0aGVuIHlvdeKAmXJlIGNob29zaW5nIG9wdGlvbiAyLiAoQSA+c3Rh bmRhcmQgdGhhdCBzYXlzIOKAnHlvdSBNQVkgaGF2ZSBjb2RlIHRoYXQgaW1wbGVtZW50cyB0aGlz IG1vZGUsIGJ1dCB5b3UgTVVTVCBOT1QgZXZlciB1c2UgaXTigJ0gaXMgcHJldHR5IHBvaW50bGVz cy4pDQoNClJlZ2FyZGluZyAjMiwgZW5kcG9pbnRzIGNhbiBpbXBsZW1lbnQgd2hhdGV2ZXIgdGhl eSB3YW50LiBUaGUgcG9pbnQgaXMgdGhhdCB0aGV5IHdvdWxkIG5ldmVyICpVU0UqIG5vbi1NVVgu DQoNClJlZ2FyZHMsDQoNCkNocmlzdGVyDQoNCk9uIEF1ZyAxMCwgMjAxNSwgYXQgMTE6MzkgQU0s IENocmlzdGVyIEhvbG1iZXJnIDxjaHJpc3Rlci5ob2xtYmVyZ0Blcmljc3Nvbi5jb208bWFpbHRv OmNocmlzdGVyLmhvbG1iZXJnQGVyaWNzc29uLmNvbT4+IHdyb3RlOg0KDQpIaSBKb25hdGhhbiwN Cg0KV2h5IGNhbid0IHdlIHNpbXBseSBzYXkgdGhhdCBlbnRpdGllcyBNVVNUIGluc2VydCB0aGUg U0RQIGF0dHJpYnV0ZSBpbiBvZmZlcnMgYW5kIGFuc3dlcnM/DQoNClJlZ2FyZHMsDQoNCkNocmlz dGVyDQoNClNlbnQgZnJvbSBteSBXaW5kb3dzIFBob25lDQpfX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fXw0KRnJvbTogSm9uYXRoYW4gTGVubm94PG1haWx0bzpqb25hdGhhbkB2aWR5by5j b20+DQpTZW50OiDigI4xMC/igI4wOC/igI4yMDE1IDE3OjQ2DQpUbzogR29vZ2xlLVBldGVyIFRo YXRjaGVyPG1haWx0bzpwdGhhdGNoZXJAZ29vZ2xlLmNvbT4NCkNjOiBydGN3ZWJAaWV0Zi5vcmc8 bWFpbHRvOnJ0Y3dlYkBpZXRmLm9yZz4NClN1YmplY3Q6IFJlOiBbcnRjd2ViXSBEbyB3ZSBoYXZl IGNvbnNlbnN1cyBvbiBub3QgcmVxdWlyaW5nIHJ0Y3Atbm9uLW11eD8NCiMxIHNlZW1zIGJlc3Qg dG8gbWUsIGJ1dCB0aGVyZSBuZWVkcyB0byBiZSBzb21lIHdlbGwtc3BlY2lmaWVkIHdheSBmb3Ig SlMgYXBwbGljYXRpb25zIGFuZCBvZmZlci9hbnN3ZXIgcGVlcnMgdG8gZGlzY292ZXIvdW5kZXJz dGFuZCB3aGV0aGVyIHJ0Y3Atbm9uLW11eCBpcyBpbmRlZWQgc3VwcG9ydGVkLiAgT3RoZXJ3aXNl IHRoZXJl4oCZcyBubyBwcmFjdGljYWwgZGlmZmVyZW5jZSBiZXR3ZWVuICMxIGFuZCAjMi4NCg0K DQpPbiBBdWcgNywgMjAxNSwgYXQgNTozOSBQTSwgUGV0ZXIgVGhhdGNoZXIgPHB0aGF0Y2hlckBn b29nbGUuY29tPG1haWx0bzpwdGhhdGNoZXJAZ29vZ2xlLmNvbT4+IHdyb3RlOg0KDQpBZnRlciBs b3RzIG9mIGRpc2N1c3Npb24sIGl0IGFwcGVhcnMgd2UgaGF2ZSB0aHJlZSBvcHRpb25zOg0KDQox LiAgRW5kcG9pbnRzIE1BWSBpbXBsZW1lbnQgcnRjcC1ub24tbXV4ICh3ZSBjaGFuZ2UgdGhlIHNw ZWMgYW5kIGNhbiBkZWxldGUgdGhlIHVnbHkgY29kZSkNCg0KMi4gIEVuZHBvaW50cyBNVVNUIE5P VCBpbXBsZW1lbnQgcnRjcC1ub24tbXV4ICh3ZSBjaGFuZ2UgdGhlIHNwZWMgYW5kIG11c3QgZGVs ZXRlIHRoZSB1Z2x5IGNvZGUsIGFuZCBvdXIgbm9uLWNvbXBsaWFudCB1bnRpbCB3ZSBkbykNCg0K My4gIEVuZHBvaW50cyBNVVNUIGltcGxlbWVudCBydGNwLW5vbi1tdXggKHdlIGRvbid0IGNoYW5n ZSB0aGUgc3BlYyBhbmQga2VlcCBhcm91bmQgdGhlIHVnbHkgY29kZSkNCg0KDQpNeSByZWFkaW5n IG9mIHRoZSBkaXNjdXNzaW9uIGlzIHRoYXQgbW9zdCBwZW9wbGUgd2FudCAjMSBvciAjMiwgYW5k IHZlcnkgZmV3IHBlb3BsZSBzdGlsbCB3YW50ICMzLiAgIEJldHdlZW4gIzEgYW5kICMyLCB3aGls ZSBzb21lIHBlb3BsZSB3b3VsZCBwcmVmZXIgIzIsIHRoZXJlIGFyZSBnb29kIHJlYXNvbnMgdG8g anVzdCBkbyAjMSwgYW5kIG1vc3Qgc2VlbSB0byBwcmVmZXIgIzEuICBGdXJ0aGVyLCBJJ20gZ3Vl c3NpbmcgdGhhdCBtb3N0IHBlb3BsZSB3aG8gd2FudGVkICMyIGNvdWxkIGxpdmUgd2l0aCAjMS4N Cg0KDQpUTDtEUjogIEkgdGhpbmsgd2UgbWF5IGhhdmUgcm91Z2ggY29uc2Vuc3VzIG9uICMxLCBz YXlpbmcgZW5kcG9pbnRzIE1BWSBydGNwLW5vbi1tdXggKGJ1dCBtYXkgY2hvb3NlIHRvIGRlbGV0 ZSBhbGwgdGhhdCB1Z2x5IGNvZGUgaW5zdGVhZCkuDQoNCg0KU28sIGlzIGV2ZXJ5b25lIGhhcHB5 IHdpdGggIzE/DQoNCg0KDQpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fXw0KcnRjd2ViIG1haWxpbmcgbGlzdA0KcnRjd2ViQGlldGYub3JnPG1haWx0bzpydGN3 ZWJAaWV0Zi5vcmc+DQpodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL3J0Y3dl Yg0KDQo= --_000_D9B4F280E9FE401C81D20FCE3580BF82vidyocom_ Content-Type: text/html; charset="utf-8" Content-ID: <0A0C531E0AA5C347841D9E76949B0BB8@vidyo.com> Content-Transfer-Encoding: base64 PGh0bWw+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIgY29udGVudD0i dGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjwvaGVhZD4NCjxib2R5IHN0eWxlPSJ3b3JkLXdy YXA6IGJyZWFrLXdvcmQ7IC13ZWJraXQtbmJzcC1tb2RlOiBzcGFjZTsgLXdlYmtpdC1saW5lLWJy ZWFrOiBhZnRlci13aGl0ZS1zcGFjZTsiIGNsYXNzPSIiPg0KPGRpdiBjbGFzcz0iIj5BcmUgeW91 IHNlcmlvdXNseSBhZHZvY2F0aW5nIOKAnE1BWSBpbXBsZW1lbnQsIE1VU1QgTk9UIHVzZeKAnT8g Jm5ic3A7SG93IGRvZXMgdGhhdCBtYWtlIGFueSBzZW5zZSBhdCBhbGw/PC9kaXY+DQo8ZGl2IGNs YXNzPSIiPjxiciBjbGFzcz0iIj4NCjwvZGl2Pg0KPGRpdiBjbGFzcz0iIj5BcyBJIHVuZGVyc3Rv b2QgUGV0ZXLigJlzIG9yaWdpbmFsIG9wdGlvbiAxLCBoZSB3YXMgcHJvcG9zaW5nIHRvIGNoYW5n ZSB0aGUgc3BlYyB0byBhbGxvdyB0d28gdHlwZXMgb2YgaW1wbGVtZW50YXRpb25zOjwvZGl2Pg0K PGRpdiBjbGFzcz0iIj48YnIgY2xhc3M9IiI+DQo8L2Rpdj4NCjxkaXYgY2xhc3M9IiI+MS4gRW5k cG9pbnRzIHRoYXQgYWx3YXlzIG9mZmVyIG11eCwgYnV0IGFyZSBwcmVwYXJlZCBmb3IgYW4gYW5z d2VyIHRoYXQgZGVjbGluZXMgdG8gZG8gaXQsIGF0IHdoaWNoIHBvaW50IHRoZXkgZmFsbCBiYWNr IHRvIG5vbi1tdXguIChUaGUgY3VycmVudCBkZWZhdWx0IGJlaGF2aW9yLCBhbmQgdGhlIGJlaGF2 aW9yIHJlcXVpcmVkIGJ5IFJGQyA1NzYxLik8L2Rpdj4NCjxkaXYgY2xhc3M9IiI+PGJyIGNsYXNz PSIiPg0KPC9kaXY+DQo8ZGl2IGNsYXNzPSIiPjIuIEVuZHBvaW50cyB0aGF0IGFsd2F5cyBvZmZl ciBtdXgsIGluIGEgd2F5IHN1Y2ggdGhhdCB0aGVyZSBpcyBubyB3YXkgdG8gZmFsbCBiYWNrIHRv IG5vbi1tdXguICZuYnNwO05haXZlIGludGVyb3Agd2l0aCBhIG5vbi1ydGNwLW11eCBlbmRwb2lu dCwgb3Igd2l0aCBhbiBlbmRwb2ludCB0aGF0IGRvZXNu4oCZdCB3YW50IHRvIGRvIG11eCwgd2ls bCBmYWlsLiAoVGhlIGN1cnJlbnQgcnRjcE11eFBvbGljeTomcXVvdDtyZXF1aXJlJnF1b3Q7IGJl aGF2aW9yLik8L2Rpdj4NCjxkaXYgY2xhc3M9IiI+PGJyIGNsYXNzPSIiPg0KPC9kaXY+DQo8ZGl2 IGNsYXNzPSIiPklmIHlvdSBzYXkgdGhhdCBubyBlbmRwb2ludCBjYW4gZXZlciBkbyBmYWxsYmFj ayB0byBub24tTVVYLCBJIGRvbuKAmXQgc2VlIHdoYXQgdGhlIHBvaW50IGlzLiAmbmJzcDtZb3Xi gJlyZSBpbnN0ZWFkIGFkdm9jYXRpbmcgZm9yIFBldGVy4oCZcyBvcHRpb24gMi48L2Rpdj4NCjxk aXYgY2xhc3M9IiI+PGJyIGNsYXNzPSIiPg0KPC9kaXY+DQo8ZGl2IGNsYXNzPSIiPkFzIEkgbWVu dGlvbmVkIGVhcmxpZXIgaW4gdGhpcyB0aHJlYWQsIG9uZSBzb2x1dGlvbiB0byBteSBwcm9ibGVt IOKAlCB3aGljaCBJIGRvbuKAmXQgbGlrZSB0aGlzIGJlY2F1c2UgaXTigJlzIG1peGluZyB1cCBm ZWF0dXJlcyB3aGljaCBJTU8gc2hvdWxkIGJlIG9ydGhvZ29uYWwsIGJ1dCBJIHdvdWxkIGJlIG9r YXkgd2l0aCDigJQgd291bGQgYmUgdG8gc2F5IHNvbWV0aGluZyBsaWtlIOKAnG9mZmVycyB0aGF0 IHN1cHBvcnQgZmFsbGJhY2sNCiB0byBub24tUlRDUC1tdXggTVVTVCBpbmNsdWRlIHNlcGFyYXRl IElDRSBjYW5kaWRhdGVzIGZvciBSVENQLCBpLmUuIG9uIGNvbXBvbmVudCAyOyBvZmZlcnMgdGhh dCBkbyBub3Qgc3VwcG9ydCBzdWNoIGZhbGxiYWNrIE1VU1QgTk9UIGluY2x1ZGUgc3VjaCBjYW5k aWRhdGVzLuKAnTwvZGl2Pg0KPGRpdiBjbGFzcz0iIj48YnIgY2xhc3M9IiI+DQo8L2Rpdj4NCjxk aXYgY2xhc3M9IiI+VGhlIG9ubHkgZGlmZmljdWx0eSB3aXRoIHRoaXMgc29sdXRpb24gaXMgdGhh dCBpdCBjYW4gYmUgYW1iaWd1b3VzIHdoZW4gdHJpY2tsZSBJQ0UgaXMgYmVpbmcgdXNlZCwgc2lu Y2UgYW4gb2ZmZXIgbWlnaHQgbm90IGluY2x1ZGUgYW55IGNhbmRpZGF0ZXMgYXQgYWxsLjwvZGl2 Pg0KPGRpdiBjbGFzcz0iIj48YnIgY2xhc3M9IiI+DQo8L2Rpdj4NCjxkaXY+DQo8YmxvY2txdW90 ZSB0eXBlPSJjaXRlIiBjbGFzcz0iIj4NCjxkaXYgY2xhc3M9IiI+T24gQXVnIDEwLCAyMDE1LCBh dCAyOjAyIFBNLCBDaHJpc3RlciBIb2xtYmVyZyAmbHQ7PGEgaHJlZj0ibWFpbHRvOmNocmlzdGVy LmhvbG1iZXJnQGVyaWNzc29uLmNvbSIgY2xhc3M9IiI+Y2hyaXN0ZXIuaG9sbWJlcmdAZXJpY3Nz b24uY29tPC9hPiZndDsgd3JvdGU6PC9kaXY+DQo8YnIgY2xhc3M9IkFwcGxlLWludGVyY2hhbmdl LW5ld2xpbmUiPg0KPGRpdiBjbGFzcz0iIj4NCjxkaXYgY2xhc3M9IldvcmRTZWN0aW9uMSIgc3R5 bGU9InBhZ2U6IFdvcmRTZWN0aW9uMTsgZm9udC1mYW1pbHk6IEhlbHZldGljYTsgZm9udC1zaXpl OiAxMnB4OyBmb250LXN0eWxlOiBub3JtYWw7IGZvbnQtdmFyaWFudDogbm9ybWFsOyBmb250LXdl aWdodDogbm9ybWFsOyBsZXR0ZXItc3BhY2luZzogbm9ybWFsOyBsaW5lLWhlaWdodDogbm9ybWFs OyBvcnBoYW5zOiBhdXRvOyB0ZXh0LWFsaWduOiBzdGFydDsgdGV4dC1pbmRlbnQ6IDBweDsgdGV4 dC10cmFuc2Zvcm06IG5vbmU7IHdoaXRlLXNwYWNlOiBub3JtYWw7IHdpZG93czogYXV0bzsgd29y ZC1zcGFjaW5nOiAwcHg7IC13ZWJraXQtdGV4dC1zdHJva2Utd2lkdGg6IDBweDsiPg0KPGRpdiBz dHlsZT0ibWFyZ2luOiAwY20gMGNtIDAuMDAwMXB0OyBmb250LXNpemU6IDEycHQ7IGZvbnQtZmFt aWx5OiAnVGltZXMgTmV3IFJvbWFuJywgc2VyaWY7IiBjbGFzcz0iIj4NCjxzcGFuIHN0eWxlPSJm b250LXNpemU6IDExcHQ7IGZvbnQtZmFtaWx5OiBDYWxpYnJpLCBzYW5zLXNlcmlmOyBjb2xvcjog cmdiKDMxLCA3MywgMTI1KTsiIGNsYXNzPSIiPkhpLDxvOnAgY2xhc3M9IiI+PC9vOnA+PC9zcGFu PjwvZGl2Pg0KPGRpdiBzdHlsZT0ibWFyZ2luOiAwY20gMGNtIDAuMDAwMXB0OyBmb250LXNpemU6 IDEycHQ7IGZvbnQtZmFtaWx5OiAnVGltZXMgTmV3IFJvbWFuJywgc2VyaWY7IiBjbGFzcz0iIj4N CjxvOnAgY2xhc3M9IiI+Jm5ic3A7PC9vOnA+PC9kaXY+DQo8ZGl2IGNsYXNzPSIiPg0KPGRpdiBz dHlsZT0ibWFyZ2luOiAwY20gMGNtIDAuMDAwMXB0OyBmb250LXNpemU6IDEycHQ7IGZvbnQtZmFt aWx5OiAnVGltZXMgTmV3IFJvbWFuJywgc2VyaWY7IiBjbGFzcz0iIj4NCiZndDtUaGUgd2hvbGUg cG9pbnQgb2Ygc3VwcG9ydGluZyBub24tTVVYIG1vZGUgaXMgdG8gYWxsb3cgYW5zd2VyZXJzIHRv IGNob29zZSBub3QgdG8gaW5zZXJ0IHRoZSBTRFAgYXR0cmlidXRlLjxvOnAgY2xhc3M9IiI+PC9v OnA+PC9kaXY+DQo8L2Rpdj4NCjxkaXYgY2xhc3M9IiI+DQo8ZGl2IHN0eWxlPSJtYXJnaW46IDBj bSAwY20gMC4wMDAxcHQ7IGZvbnQtc2l6ZTogMTJwdDsgZm9udC1mYW1pbHk6ICdUaW1lcyBOZXcg Um9tYW4nLCBzZXJpZjsiIGNsYXNzPSIiPg0KPG86cCBjbGFzcz0iIj4mbmJzcDs8L286cD48L2Rp dj4NCjxkaXYgc3R5bGU9Im1hcmdpbjogMGNtIDBjbSAwLjAwMDFwdDsgZm9udC1zaXplOiAxMnB0 OyBmb250LWZhbWlseTogJ1RpbWVzIE5ldyBSb21hbicsIHNlcmlmOyIgY2xhc3M9IiI+DQo8c3Bh biBzdHlsZT0iZm9udC1zaXplOiAxMXB0OyBmb250LWZhbWlseTogQ2FsaWJyaSwgc2Fucy1zZXJp ZjsiIGNsYXNzPSIiPkZyb20gYSBwcm90b2NvbCBwZXJzcGVjdGl2ZSwgeWVzLiBCdXQsIGlmIHdl IHNheSB0aGF0IGEgV2ViUlRDIGVudGl0eSBNVVNUIHN1cHBvcnQvdXNlIHJ0Y3AtbXV4LCB0aGVu IGl0IG1lYW5zIHRoYXQgaXQgTVVTVCBpbmNsdWRlIHRoZSBhdHRyaWJ1dGUg4oCTIEVWRU4gaWYg dGhlIHByb3RvY29sIGFsbG93cyBpdCBub3QNCiB0by48bzpwIGNsYXNzPSIiPjwvbzpwPjwvc3Bh bj48L2Rpdj4NCjxkaXYgc3R5bGU9Im1hcmdpbjogMGNtIDBjbSAwLjAwMDFwdDsgZm9udC1zaXpl OiAxMnB0OyBmb250LWZhbWlseTogJ1RpbWVzIE5ldyBSb21hbicsIHNlcmlmOyIgY2xhc3M9IiI+ DQo8c3BhbiBzdHlsZT0iZm9udC1zaXplOiAxMXB0OyBmb250LWZhbWlseTogQ2FsaWJyaSwgc2Fu cy1zZXJpZjsiIGNsYXNzPSIiPiZuYnNwOzwvc3Bhbj48L2Rpdj4NCjwvZGl2Pg0KPGRpdiBjbGFz cz0iIj4NCjxkaXYgc3R5bGU9Im1hcmdpbjogMGNtIDBjbSAwLjAwMDFwdDsgZm9udC1zaXplOiAx MnB0OyBmb250LWZhbWlseTogJ1RpbWVzIE5ldyBSb21hbicsIHNlcmlmOyIgY2xhc3M9IiI+DQom Z3Q7V2l0aCBvcHRpb24gMSwgdGhlIGlkZWEgaXMgdGhhdCBzb21lIGVuZHBvaW50cyB3aWxsIG9m ZmVyIE1VWCwgYnV0IHN1cHBvcnQgZmFsbGJhY2sgdG8gbm9uLU1VWCBpZiB0aGUgcGVlciBjaG9v c2VzIG5vdCB0byBkbyBpdC48bzpwIGNsYXNzPSIiPjwvbzpwPjwvZGl2Pg0KPC9kaXY+DQo8ZGl2 IGNsYXNzPSIiPg0KPGRpdiBzdHlsZT0ibWFyZ2luOiAwY20gMGNtIDAuMDAwMXB0OyBmb250LXNp emU6IDEycHQ7IGZvbnQtZmFtaWx5OiAnVGltZXMgTmV3IFJvbWFuJywgc2VyaWY7IiBjbGFzcz0i Ij4NCjxvOnAgY2xhc3M9IiI+Jm5ic3A7PC9vOnA+PC9kaXY+DQo8ZGl2IHN0eWxlPSJtYXJnaW46 IDBjbSAwY20gMC4wMDAxcHQ7IGZvbnQtc2l6ZTogMTJwdDsgZm9udC1mYW1pbHk6ICdUaW1lcyBO ZXcgUm9tYW4nLCBzZXJpZjsiIGNsYXNzPSIiPg0KPHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTogMTFw dDsgZm9udC1mYW1pbHk6IENhbGlicmksIHNhbnMtc2VyaWY7IiBjbGFzcz0iIj5NeSB1bmRlcnN0 YW5kaW5nIG9mIG9wdGlvbiAxIGlzIHRoYXQgc29tZSBlbmRwb2ludHMgd2lsbCAqPGIgY2xhc3M9 IiI+T05MWTwvYj4qIGltcGxlbWVudCBNVVgsIGFuZCB3aWxsIE5PVCBmYWxsYmFjayB0byBub24t TVVYIGlmIHRoZSBwZWVyIChhIG5vbi1XZWJSVEMgZW50aXR5KSBjaG9vc2VzIG5vdCB0byBkbyBp dC48bzpwIGNsYXNzPSIiPjwvbzpwPjwvc3Bhbj48L2Rpdj4NCjxkaXYgc3R5bGU9Im1hcmdpbjog MGNtIDBjbSAwLjAwMDFwdDsgZm9udC1zaXplOiAxMnB0OyBmb250LWZhbWlseTogJ1RpbWVzIE5l dyBSb21hbicsIHNlcmlmOyIgY2xhc3M9IiI+DQo8c3BhbiBzdHlsZT0iZm9udC1zaXplOiAxMXB0 OyBmb250LWZhbWlseTogQ2FsaWJyaSwgc2Fucy1zZXJpZjsiIGNsYXNzPSIiPiZuYnNwOzwvc3Bh bj48L2Rpdj4NCjwvZGl2Pg0KPGRpdiBjbGFzcz0iIj4NCjxkaXYgc3R5bGU9Im1hcmdpbjogMGNt IDBjbSAwLjAwMDFwdDsgZm9udC1zaXplOiAxMnB0OyBmb250LWZhbWlseTogJ1RpbWVzIE5ldyBS b21hbicsIHNlcmlmOyIgY2xhc3M9IiI+DQomZ3Q7U29tZSBvdGhlciBlbmRwb2ludHMgd2lsbCBy ZXF1aXJlIHRoYXQgTVVYIGJlIHN1cHBvcnRlZCwgYW5kIGlmIGEgcGVlciBkb2VzbuKAmXQgdW5k ZXJzdGFuZCB0aGlzIHRoZW4gdGhpbmdzIHdpbGwgZmFpbCBpbiBpbnRlcmVzdGluZyAmZ3Q7d2F5 cy48bzpwIGNsYXNzPSIiPjwvbzpwPjwvZGl2Pg0KPC9kaXY+DQo8ZGl2IGNsYXNzPSIiPg0KPGRp diBzdHlsZT0ibWFyZ2luOiAwY20gMGNtIDAuMDAwMXB0OyBmb250LXNpemU6IDEycHQ7IGZvbnQt ZmFtaWx5OiAnVGltZXMgTmV3IFJvbWFuJywgc2VyaWY7IiBjbGFzcz0iIj4NCjxvOnAgY2xhc3M9 IiI+Jm5ic3A7PC9vOnA+PC9kaXY+DQo8ZGl2IHN0eWxlPSJtYXJnaW46IDBjbSAwY20gMC4wMDAx cHQ7IGZvbnQtc2l6ZTogMTJwdDsgZm9udC1mYW1pbHk6ICdUaW1lcyBOZXcgUm9tYW4nLCBzZXJp ZjsiIGNsYXNzPSIiPg0KPHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTogMTFwdDsgZm9udC1mYW1pbHk6 IENhbGlicmksIHNhbnMtc2VyaWY7IiBjbGFzcz0iIj5XZWxsLCB0aGUgZW5kcG9pbnQgdGhhdCB3 YW50cyBNVVggd2lsbCBoYXZlIHRvIHRlcm1pbmF0ZSB0aGUgY2FsbC48bzpwIGNsYXNzPSIiPjwv bzpwPjwvc3Bhbj48L2Rpdj4NCjxkaXYgc3R5bGU9Im1hcmdpbjogMGNtIDBjbSAwLjAwMDFwdDsg Zm9udC1zaXplOiAxMnB0OyBmb250LWZhbWlseTogJ1RpbWVzIE5ldyBSb21hbicsIHNlcmlmOyIg Y2xhc3M9IiI+DQo8c3BhbiBzdHlsZT0iZm9udC1zaXplOiAxMXB0OyBmb250LWZhbWlseTogQ2Fs aWJyaSwgc2Fucy1zZXJpZjsiIGNsYXNzPSIiPiZuYnNwOzwvc3Bhbj48L2Rpdj4NCjwvZGl2Pg0K PGRpdiBjbGFzcz0iIj4NCjxkaXYgc3R5bGU9Im1hcmdpbjogMGNtIDBjbSAwLjAwMDFwdDsgZm9u dC1zaXplOiAxMnB0OyBmb250LWZhbWlseTogJ1RpbWVzIE5ldyBSb21hbicsIHNlcmlmOyIgY2xh c3M9IiI+DQomZ3Q7SWYgSeKAmW0gKHNheSkgYSBnYXRld2F5IHRoYXQgd291bGQgcmF0aGVyIGRv IG5vbi1NVVggKHRvIGtlZXAgbXkgbGlmZSBlYXNpZXIgd2hlbiBnYXRld2F5aW5nIHRvIGxlZ2Fj eSBlcXVpcG1lbnQpLCBidXQgaXMgd2lsbGluZyB0byAmZ3Q7ZG8gTVVYIGlmIG5lY2Vzc2FyeSwg SSBuZWVkIHRvIGtub3cgd2hpY2ggc29ydCBvZiBlbmRwb2ludCBJ4oCZbSB0YWxraW5nIHRvLjxv OnAgY2xhc3M9IiI+PC9vOnA+PC9kaXY+DQo8L2Rpdj4NCjxkaXYgY2xhc3M9IiI+DQo8ZGl2IHN0 eWxlPSJtYXJnaW46IDBjbSAwY20gMC4wMDAxcHQ7IGZvbnQtc2l6ZTogMTJwdDsgZm9udC1mYW1p bHk6ICdUaW1lcyBOZXcgUm9tYW4nLCBzZXJpZjsiIGNsYXNzPSIiPg0KPG86cCBjbGFzcz0iIj4m bmJzcDs8L286cD48L2Rpdj4NCjxkaXYgc3R5bGU9Im1hcmdpbjogMGNtIDBjbSAwLjAwMDFwdDsg Zm9udC1zaXplOiAxMnB0OyBmb250LWZhbWlseTogJ1RpbWVzIE5ldyBSb21hbicsIHNlcmlmOyIg Y2xhc3M9IiI+DQo8c3BhbiBzdHlsZT0iZm9udC1zaXplOiAxMXB0OyBmb250LWZhbWlseTogQ2Fs aWJyaSwgc2Fucy1zZXJpZjsiIGNsYXNzPSIiPk15IHVuZGVyc3RhbmRpbmcgb2YgIzEgaXMgdGhh dCB0aGVyZSBpcyBubyBzdWNoIHRoaW5ncyBhcyDigJx3b3VsZCByYXRoZXIgZG8gbm9uLU1VWOKA nS4gQXMgYSBXZWJSVEMgZ2F0ZXdheSwgeW91IHdvdWxkIGFsd2F5cyBkbyBNVVggKGF0IGxlYXN0 IHRvd2FyZHMgdGhlIFdlYlJUQyBlbmRwb2ludHMpLjxvOnAgY2xhc3M9IiI+PC9vOnA+PC9zcGFu PjwvZGl2Pg0KPGRpdiBzdHlsZT0ibWFyZ2luOiAwY20gMGNtIDAuMDAwMXB0OyBmb250LXNpemU6 IDEycHQ7IGZvbnQtZmFtaWx5OiAnVGltZXMgTmV3IFJvbWFuJywgc2VyaWY7IiBjbGFzcz0iIj4N CjxzcGFuIHN0eWxlPSJmb250LXNpemU6IDExcHQ7IGZvbnQtZmFtaWx5OiBDYWxpYnJpLCBzYW5z LXNlcmlmOyIgY2xhc3M9IiI+Jm5ic3A7PC9zcGFuPjwvZGl2Pg0KPC9kaXY+DQo8ZGl2IGNsYXNz PSIiPg0KPGRpdiBzdHlsZT0ibWFyZ2luOiAwY20gMGNtIDAuMDAwMXB0OyBmb250LXNpemU6IDEy cHQ7IGZvbnQtZmFtaWx5OiAnVGltZXMgTmV3IFJvbWFuJywgc2VyaWY7IiBjbGFzcz0iIj4NCiZn dDtIb3dldmVyLCBib3RoIHR5cGVzIG9mIGVuZHBvaW50cyB3aWxsIGhhdmUgaW5zZXJ0ZWQgdGhl IGF0dHJpYnV0ZSBpbiB0aGVpciBvZmZlci48bzpwIGNsYXNzPSIiPjwvbzpwPjwvZGl2Pg0KPC9k aXY+DQo8ZGl2IGNsYXNzPSIiPg0KPGRpdiBzdHlsZT0ibWFyZ2luOiAwY20gMGNtIDAuMDAwMXB0 OyBmb250LXNpemU6IDEycHQ7IGZvbnQtZmFtaWx5OiAnVGltZXMgTmV3IFJvbWFuJywgc2VyaWY7 IiBjbGFzcz0iIj4NCjxvOnAgY2xhc3M9IiI+Jm5ic3A7PC9vOnA+PC9kaXY+DQo8ZGl2IHN0eWxl PSJtYXJnaW46IDBjbSAwY20gMC4wMDAxcHQ7IGZvbnQtc2l6ZTogMTJwdDsgZm9udC1mYW1pbHk6 ICdUaW1lcyBOZXcgUm9tYW4nLCBzZXJpZjsiIGNsYXNzPSIiPg0KPHNwYW4gc3R5bGU9ImZvbnQt c2l6ZTogMTFwdDsgZm9udC1mYW1pbHk6IENhbGlicmksIHNhbnMtc2VyaWY7IiBjbGFzcz0iIj5B bmQsIGFzIGEgV2ViUlRDIGVuZHBvaW50LCB5b3Ugd2lsbCBhbHdheXMgaW5zZXJ0IHRoZSBhdHRy aWJ1dGUgaW4gdGhlIGFuc3dlci48bzpwIGNsYXNzPSIiPjwvbzpwPjwvc3Bhbj48L2Rpdj4NCjxk aXYgc3R5bGU9Im1hcmdpbjogMGNtIDBjbSAwLjAwMDFwdDsgZm9udC1zaXplOiAxMnB0OyBmb250 LWZhbWlseTogJ1RpbWVzIE5ldyBSb21hbicsIHNlcmlmOyIgY2xhc3M9IiI+DQo8c3BhbiBzdHls ZT0iZm9udC1zaXplOiAxMXB0OyBmb250LWZhbWlseTogQ2FsaWJyaSwgc2Fucy1zZXJpZjsiIGNs YXNzPSIiPiZuYnNwOzwvc3Bhbj48L2Rpdj4NCjwvZGl2Pg0KPGRpdiBjbGFzcz0iIj4NCjxkaXYg c3R5bGU9Im1hcmdpbjogMGNtIDBjbSAwLjAwMDFwdDsgZm9udC1zaXplOiAxMnB0OyBmb250LWZh bWlseTogJ1RpbWVzIE5ldyBSb21hbicsIHNlcmlmOyIgY2xhc3M9IiI+DQomZ3Q7SWYgeW91IHJl cXVpcmUgdGhhdCBhbGwgZW50aXRpZXMgTVVTVCBhbHdheXMgaW5zZXJ0IHRoZSBTRFAgYXR0cmli dXRlIGluIGJvdGggb2ZmZXJzICphbmQgYW5zd2VycyosIHRoZW4geW914oCZcmUgY2hvb3Npbmcg b3B0aW9uIDIuIChBICZndDtzdGFuZGFyZCB0aGF0IHNheXMg4oCceW91IE1BWSBoYXZlIGNvZGUg dGhhdCBpbXBsZW1lbnRzIHRoaXMgbW9kZSwgYnV0IHlvdSBNVVNUIE5PVCBldmVyIHVzZSBpdOKA nSBpcyBwcmV0dHkgcG9pbnRsZXNzLik8bzpwIGNsYXNzPSIiPjwvbzpwPjwvZGl2Pg0KPC9kaXY+ DQo8ZGl2IGNsYXNzPSIiPg0KPGRpdiBzdHlsZT0ibWFyZ2luOiAwY20gMGNtIDAuMDAwMXB0OyBm b250LXNpemU6IDEycHQ7IGZvbnQtZmFtaWx5OiAnVGltZXMgTmV3IFJvbWFuJywgc2VyaWY7IiBj bGFzcz0iIj4NCjxvOnAgY2xhc3M9IiI+Jm5ic3A7PC9vOnA+PC9kaXY+DQo8ZGl2IHN0eWxlPSJt YXJnaW46IDBjbSAwY20gMC4wMDAxcHQ7IGZvbnQtc2l6ZTogMTJwdDsgZm9udC1mYW1pbHk6ICdU aW1lcyBOZXcgUm9tYW4nLCBzZXJpZjsiIGNsYXNzPSIiPg0KPHNwYW4gc3R5bGU9ImZvbnQtc2l6 ZTogMTFwdDsgZm9udC1mYW1pbHk6IENhbGlicmksIHNhbnMtc2VyaWY7IiBjbGFzcz0iIj5SZWdh cmRpbmcgIzIsIGVuZHBvaW50cyBjYW4gaW1wbGVtZW50IHdoYXRldmVyIHRoZXkgd2FudC4gVGhl IHBvaW50IGlzIHRoYXQgdGhleSB3b3VsZCBuZXZlciAqPGIgY2xhc3M9IiI+VVNFPC9iPiogbm9u LU1VWC48bzpwIGNsYXNzPSIiPjwvbzpwPjwvc3Bhbj48L2Rpdj4NCjwvZGl2Pg0KPGRpdiBzdHls ZT0ibWFyZ2luOiAwY20gMGNtIDAuMDAwMXB0OyBmb250LXNpemU6IDEycHQ7IGZvbnQtZmFtaWx5 OiAnVGltZXMgTmV3IFJvbWFuJywgc2VyaWY7IiBjbGFzcz0iIj4NCjxvOnAgY2xhc3M9IiI+Jm5i c3A7PC9vOnA+PC9kaXY+DQo8ZGl2IHN0eWxlPSJtYXJnaW46IDBjbSAwY20gMC4wMDAxcHQ7IGZv bnQtc2l6ZTogMTJwdDsgZm9udC1mYW1pbHk6ICdUaW1lcyBOZXcgUm9tYW4nLCBzZXJpZjsiIGNs YXNzPSIiPg0KPHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTogMTFwdDsgZm9udC1mYW1pbHk6IENhbGli cmksIHNhbnMtc2VyaWY7IiBjbGFzcz0iIj5SZWdhcmRzLDxvOnAgY2xhc3M9IiI+PC9vOnA+PC9z cGFuPjwvZGl2Pg0KPGRpdiBzdHlsZT0ibWFyZ2luOiAwY20gMGNtIDAuMDAwMXB0OyBmb250LXNp emU6IDEycHQ7IGZvbnQtZmFtaWx5OiAnVGltZXMgTmV3IFJvbWFuJywgc2VyaWY7IiBjbGFzcz0i Ij4NCjxzcGFuIHN0eWxlPSJmb250LXNpemU6IDExcHQ7IGZvbnQtZmFtaWx5OiBDYWxpYnJpLCBz YW5zLXNlcmlmOyIgY2xhc3M9IiI+Jm5ic3A7PC9zcGFuPjwvZGl2Pg0KPGRpdiBzdHlsZT0ibWFy Z2luOiAwY20gMGNtIDAuMDAwMXB0OyBmb250LXNpemU6IDEycHQ7IGZvbnQtZmFtaWx5OiAnVGlt ZXMgTmV3IFJvbWFuJywgc2VyaWY7IiBjbGFzcz0iIj4NCjxzcGFuIHN0eWxlPSJmb250LXNpemU6 IDExcHQ7IGZvbnQtZmFtaWx5OiBDYWxpYnJpLCBzYW5zLXNlcmlmOyIgY2xhc3M9IiI+Q2hyaXN0 ZXI8bzpwIGNsYXNzPSIiPjwvbzpwPjwvc3Bhbj48L2Rpdj4NCjxkaXYgc3R5bGU9Im1hcmdpbjog MGNtIDBjbSAwLjAwMDFwdDsgZm9udC1zaXplOiAxMnB0OyBmb250LWZhbWlseTogJ1RpbWVzIE5l dyBSb21hbicsIHNlcmlmOyIgY2xhc3M9IiI+DQo8c3BhbiBzdHlsZT0iZm9udC1zaXplOiAxMXB0 OyBmb250LWZhbWlseTogQ2FsaWJyaSwgc2Fucy1zZXJpZjsiIGNsYXNzPSIiPiZuYnNwOzwvc3Bh bj48L2Rpdj4NCjxkaXYgY2xhc3M9IiI+DQo8YmxvY2txdW90ZSBzdHlsZT0ibWFyZ2luLXRvcDog NXB0OyBtYXJnaW4tYm90dG9tOiA1cHQ7IiBjbGFzcz0iIj4NCjxkaXYgY2xhc3M9IiI+DQo8ZGl2 IHN0eWxlPSJtYXJnaW46IDBjbSAwY20gMC4wMDAxcHQ7IGZvbnQtc2l6ZTogMTJwdDsgZm9udC1m YW1pbHk6ICdUaW1lcyBOZXcgUm9tYW4nLCBzZXJpZjsiIGNsYXNzPSIiPg0KT24gQXVnIDEwLCAy MDE1LCBhdCAxMTozOSBBTSwgQ2hyaXN0ZXIgSG9sbWJlcmcgJmx0OzxhIGhyZWY9Im1haWx0bzpj aHJpc3Rlci5ob2xtYmVyZ0Blcmljc3Nvbi5jb20iIHN0eWxlPSJjb2xvcjogcHVycGxlOyB0ZXh0 LWRlY29yYXRpb246IHVuZGVybGluZTsiIGNsYXNzPSIiPmNocmlzdGVyLmhvbG1iZXJnQGVyaWNz c29uLmNvbTwvYT4mZ3Q7IHdyb3RlOjxvOnAgY2xhc3M9IiI+PC9vOnA+PC9kaXY+DQo8L2Rpdj4N CjxkaXYgc3R5bGU9Im1hcmdpbjogMGNtIDBjbSAwLjAwMDFwdDsgZm9udC1zaXplOiAxMnB0OyBm b250LWZhbWlseTogJ1RpbWVzIE5ldyBSb21hbicsIHNlcmlmOyIgY2xhc3M9IiI+DQo8bzpwIGNs YXNzPSIiPiZuYnNwOzwvbzpwPjwvZGl2Pg0KPGRpdiBjbGFzcz0iIj4NCjxkaXYgY2xhc3M9IiI+ DQo8ZGl2IGNsYXNzPSIiPg0KPGRpdiBjbGFzcz0iIj4NCjxkaXYgc3R5bGU9Im1hcmdpbjogMGNt IDBjbSAwLjAwMDFwdDsgZm9udC1zaXplOiAxMnB0OyBmb250LWZhbWlseTogJ1RpbWVzIE5ldyBS b21hbicsIHNlcmlmOyIgY2xhc3M9IiI+DQo8c3BhbiBzdHlsZT0iZm9udC1zaXplOiAxMXB0OyBm b250LWZhbWlseTogQ2FsaWJyaSwgc2Fucy1zZXJpZjsiIGNsYXNzPSIiPkhpIEpvbmF0aGFuLDxi ciBjbGFzcz0iIj4NCjxiciBjbGFzcz0iIj4NCldoeSBjYW4ndCB3ZSBzaW1wbHkgc2F5IHRoYXQg ZW50aXRpZXMgTVVTVCBpbnNlcnQgdGhlIFNEUCBhdHRyaWJ1dGUgaW4gb2ZmZXJzIGFuZCBhbnN3 ZXJzPzxiciBjbGFzcz0iIj4NCjxiciBjbGFzcz0iIj4NClJlZ2FyZHMsPGJyIGNsYXNzPSIiPg0K PGJyIGNsYXNzPSIiPg0KQ2hyaXN0ZXI8YnIgY2xhc3M9IiI+DQo8YnIgY2xhc3M9IiI+DQpTZW50 IGZyb20gbXkgV2luZG93cyBQaG9uZTxvOnAgY2xhc3M9IiI+PC9vOnA+PC9zcGFuPjwvZGl2Pg0K PC9kaXY+DQo8L2Rpdj4NCjxkaXYgY2xhc3M9IiI+DQo8ZGl2IGNsYXNzPSJNc29Ob3JtYWwiIGFs aWduPSJjZW50ZXIiIHN0eWxlPSJtYXJnaW46IDBjbSAwY20gMC4wMDAxcHQ7IGZvbnQtc2l6ZTog MTJwdDsgZm9udC1mYW1pbHk6ICdUaW1lcyBOZXcgUm9tYW4nLCBzZXJpZjsgdGV4dC1hbGlnbjog Y2VudGVyOyI+DQo8aHIgc2l6ZT0iMyIgd2lkdGg9IjEwMCUiIGFsaWduPSJjZW50ZXIiIGNsYXNz PSIiPg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luOiAwY20gMGNt IDEycHQ7IGZvbnQtc2l6ZTogMTJwdDsgZm9udC1mYW1pbHk6ICdUaW1lcyBOZXcgUm9tYW4nLCBz ZXJpZjsiPg0KPGIgY2xhc3M9IiI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTogMTFwdDsgZm9udC1m YW1pbHk6IENhbGlicmksIHNhbnMtc2VyaWY7IiBjbGFzcz0iIj5Gcm9tOjxzcGFuIGNsYXNzPSJB cHBsZS1jb252ZXJ0ZWQtc3BhY2UiPiZuYnNwOzwvc3Bhbj48L3NwYW4+PC9iPjxzcGFuIHN0eWxl PSJmb250LXNpemU6IDExcHQ7IGZvbnQtZmFtaWx5OiBDYWxpYnJpLCBzYW5zLXNlcmlmOyIgY2xh c3M9IiI+PGEgaHJlZj0ibWFpbHRvOmpvbmF0aGFuQHZpZHlvLmNvbSIgc3R5bGU9ImNvbG9yOiBw dXJwbGU7IHRleHQtZGVjb3JhdGlvbjogdW5kZXJsaW5lOyIgY2xhc3M9IiI+Sm9uYXRoYW4NCiBM ZW5ub3g8L2E+PC9zcGFuPjxiciBjbGFzcz0iIj4NCjxiIGNsYXNzPSIiPjxzcGFuIHN0eWxlPSJm b250LXNpemU6IDExcHQ7IGZvbnQtZmFtaWx5OiBDYWxpYnJpLCBzYW5zLXNlcmlmOyIgY2xhc3M9 IiI+U2VudDo8c3BhbiBjbGFzcz0iQXBwbGUtY29udmVydGVkLXNwYWNlIj4mbmJzcDs8L3NwYW4+ PC9zcGFuPjwvYj48c3BhbiBzdHlsZT0iZm9udC1zaXplOiAxMXB0OyBmb250LWZhbWlseTogQ2Fs aWJyaSwgc2Fucy1zZXJpZjsiIGNsYXNzPSIiPuKAjjEwL+KAjjA4L+KAjjIwMTUgMTc6NDY8L3Nw YW4+PGJyIGNsYXNzPSIiPg0KPGIgY2xhc3M9IiI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTogMTFw dDsgZm9udC1mYW1pbHk6IENhbGlicmksIHNhbnMtc2VyaWY7IiBjbGFzcz0iIj5Ubzo8c3BhbiBj bGFzcz0iQXBwbGUtY29udmVydGVkLXNwYWNlIj4mbmJzcDs8L3NwYW4+PC9zcGFuPjwvYj48c3Bh biBzdHlsZT0iZm9udC1zaXplOiAxMXB0OyBmb250LWZhbWlseTogQ2FsaWJyaSwgc2Fucy1zZXJp ZjsiIGNsYXNzPSIiPjxhIGhyZWY9Im1haWx0bzpwdGhhdGNoZXJAZ29vZ2xlLmNvbSIgc3R5bGU9 ImNvbG9yOiBwdXJwbGU7IHRleHQtZGVjb3JhdGlvbjogdW5kZXJsaW5lOyIgY2xhc3M9IiI+R29v Z2xlLVBldGVyDQogVGhhdGNoZXI8L2E+PC9zcGFuPjxiciBjbGFzcz0iIj4NCjxiIGNsYXNzPSIi PjxzcGFuIHN0eWxlPSJmb250LXNpemU6IDExcHQ7IGZvbnQtZmFtaWx5OiBDYWxpYnJpLCBzYW5z LXNlcmlmOyIgY2xhc3M9IiI+Q2M6PHNwYW4gY2xhc3M9IkFwcGxlLWNvbnZlcnRlZC1zcGFjZSI+ Jm5ic3A7PC9zcGFuPjwvc3Bhbj48L2I+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTogMTFwdDsgZm9u dC1mYW1pbHk6IENhbGlicmksIHNhbnMtc2VyaWY7IiBjbGFzcz0iIj48YSBocmVmPSJtYWlsdG86 cnRjd2ViQGlldGYub3JnIiBzdHlsZT0iY29sb3I6IHB1cnBsZTsgdGV4dC1kZWNvcmF0aW9uOiB1 bmRlcmxpbmU7IiBjbGFzcz0iIj5ydGN3ZWJAaWV0Zi5vcmc8L2E+PC9zcGFuPjxiciBjbGFzcz0i Ij4NCjxiIGNsYXNzPSIiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6IDExcHQ7IGZvbnQtZmFtaWx5 OiBDYWxpYnJpLCBzYW5zLXNlcmlmOyIgY2xhc3M9IiI+U3ViamVjdDo8c3BhbiBjbGFzcz0iQXBw bGUtY29udmVydGVkLXNwYWNlIj4mbmJzcDs8L3NwYW4+PC9zcGFuPjwvYj48c3BhbiBzdHlsZT0i Zm9udC1zaXplOiAxMXB0OyBmb250LWZhbWlseTogQ2FsaWJyaSwgc2Fucy1zZXJpZjsiIGNsYXNz PSIiPlJlOiBbcnRjd2ViXSBEbyB3ZSBoYXZlIGNvbnNlbnN1cw0KIG9uIG5vdCByZXF1aXJpbmcg cnRjcC1ub24tbXV4Pzwvc3Bhbj48bzpwIGNsYXNzPSIiPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRp diBjbGFzcz0iIj4NCjxkaXYgc3R5bGU9Im1hcmdpbjogMGNtIDBjbSAwLjAwMDFwdDsgZm9udC1z aXplOiAxMnB0OyBmb250LWZhbWlseTogJ1RpbWVzIE5ldyBSb21hbicsIHNlcmlmOyIgY2xhc3M9 IiI+DQojMSBzZWVtcyBiZXN0IHRvIG1lLCBidXQgdGhlcmUgbmVlZHMgdG8gYmUgc29tZSB3ZWxs LXNwZWNpZmllZCB3YXkgZm9yIEpTIGFwcGxpY2F0aW9ucyBhbmQgb2ZmZXIvYW5zd2VyIHBlZXJz IHRvIGRpc2NvdmVyL3VuZGVyc3RhbmQgd2hldGhlciBydGNwLW5vbi1tdXggaXMgaW5kZWVkIHN1 cHBvcnRlZC4gJm5ic3A7T3RoZXJ3aXNlIHRoZXJl4oCZcyBubyBwcmFjdGljYWwgZGlmZmVyZW5j ZSBiZXR3ZWVuICMxIGFuZCAjMi48bzpwIGNsYXNzPSIiPjwvbzpwPjwvZGl2Pg0KPGRpdiBjbGFz cz0iIj4NCjxkaXYgc3R5bGU9Im1hcmdpbjogMGNtIDBjbSAwLjAwMDFwdDsgZm9udC1zaXplOiAx MnB0OyBmb250LWZhbWlseTogJ1RpbWVzIE5ldyBSb21hbicsIHNlcmlmOyIgY2xhc3M9IiI+DQo8 YnIgY2xhc3M9IiI+DQo8YnIgY2xhc3M9IiI+DQo8bzpwIGNsYXNzPSIiPjwvbzpwPjwvZGl2Pg0K PGJsb2NrcXVvdGUgc3R5bGU9Im1hcmdpbi10b3A6IDVwdDsgbWFyZ2luLWJvdHRvbTogNXB0OyIg Y2xhc3M9IiI+DQo8ZGl2IGNsYXNzPSIiPg0KPGRpdiBzdHlsZT0ibWFyZ2luOiAwY20gMGNtIDAu MDAwMXB0OyBmb250LXNpemU6IDEycHQ7IGZvbnQtZmFtaWx5OiAnVGltZXMgTmV3IFJvbWFuJywg c2VyaWY7IiBjbGFzcz0iIj4NCk9uIEF1ZyA3LCAyMDE1LCBhdCA1OjM5IFBNLCBQZXRlciBUaGF0 Y2hlciAmbHQ7PGEgaHJlZj0ibWFpbHRvOnB0aGF0Y2hlckBnb29nbGUuY29tIiBzdHlsZT0iY29s b3I6IHB1cnBsZTsgdGV4dC1kZWNvcmF0aW9uOiB1bmRlcmxpbmU7IiBjbGFzcz0iIj5wdGhhdGNo ZXJAZ29vZ2xlLmNvbTwvYT4mZ3Q7IHdyb3RlOjxvOnAgY2xhc3M9IiI+PC9vOnA+PC9kaXY+DQo8 L2Rpdj4NCjxkaXYgc3R5bGU9Im1hcmdpbjogMGNtIDBjbSAwLjAwMDFwdDsgZm9udC1zaXplOiAx MnB0OyBmb250LWZhbWlseTogJ1RpbWVzIE5ldyBSb21hbicsIHNlcmlmOyIgY2xhc3M9IiI+DQo8 bzpwIGNsYXNzPSIiPiZuYnNwOzwvbzpwPjwvZGl2Pg0KPGRpdiBjbGFzcz0iIj4NCjxkaXYgY2xh c3M9IiI+DQo8ZGl2IGNsYXNzPSIiPg0KPGRpdiBzdHlsZT0ibWFyZ2luOiAwY20gMGNtIDAuMDAw MXB0OyBmb250LXNpemU6IDEycHQ7IGZvbnQtZmFtaWx5OiAnVGltZXMgTmV3IFJvbWFuJywgc2Vy aWY7IiBjbGFzcz0iIj4NCjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTogQXJpYWwsIHNhbnMtc2Vy aWY7IiBjbGFzcz0iIj5BZnRlciBsb3RzIG9mIGRpc2N1c3Npb24sIGl0IGFwcGVhcnMgd2UgaGF2 ZSB0aHJlZSBvcHRpb25zOjxvOnAgY2xhc3M9IiI+PC9vOnA+PC9zcGFuPjwvZGl2Pg0KPC9kaXY+ DQo8ZGl2IGNsYXNzPSIiPg0KPGRpdiBzdHlsZT0ibWFyZ2luOiAwY20gMGNtIDAuMDAwMXB0OyBm b250LXNpemU6IDEycHQ7IGZvbnQtZmFtaWx5OiAnVGltZXMgTmV3IFJvbWFuJywgc2VyaWY7IiBj bGFzcz0iIj4NCjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTogQXJpYWwsIHNhbnMtc2VyaWY7IiBj bGFzcz0iIj4mbmJzcDs8L3NwYW4+PC9kaXY+DQo8L2Rpdj4NCjxkaXYgY2xhc3M9IiI+DQo8ZGl2 IHN0eWxlPSJtYXJnaW46IDBjbSAwY20gMC4wMDAxcHQ7IGZvbnQtc2l6ZTogMTJwdDsgZm9udC1m YW1pbHk6ICdUaW1lcyBOZXcgUm9tYW4nLCBzZXJpZjsiIGNsYXNzPSIiPg0KPHNwYW4gc3R5bGU9 ImZvbnQtZmFtaWx5OiBBcmlhbCwgc2Fucy1zZXJpZjsiIGNsYXNzPSIiPjEuJm5ic3A7IEVuZHBv aW50cyBNQVkgaW1wbGVtZW50IHJ0Y3Atbm9uLW11eCAod2UgY2hhbmdlIHRoZSBzcGVjIGFuZCBj YW4gZGVsZXRlIHRoZSB1Z2x5IGNvZGUpPG86cCBjbGFzcz0iIj48L286cD48L3NwYW4+PC9kaXY+ DQo8L2Rpdj4NCjxkaXYgY2xhc3M9IiI+DQo8ZGl2IHN0eWxlPSJtYXJnaW46IDBjbSAwY20gMC4w MDAxcHQ7IGZvbnQtc2l6ZTogMTJwdDsgZm9udC1mYW1pbHk6ICdUaW1lcyBOZXcgUm9tYW4nLCBz ZXJpZjsiIGNsYXNzPSIiPg0KPHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiBBcmlhbCwgc2Fucy1z ZXJpZjsiIGNsYXNzPSIiPiZuYnNwOzwvc3Bhbj48L2Rpdj4NCjwvZGl2Pg0KPGRpdiBjbGFzcz0i Ij4NCjxkaXYgc3R5bGU9Im1hcmdpbjogMGNtIDBjbSAwLjAwMDFwdDsgZm9udC1zaXplOiAxMnB0 OyBmb250LWZhbWlseTogJ1RpbWVzIE5ldyBSb21hbicsIHNlcmlmOyIgY2xhc3M9IiI+DQo8c3Bh biBzdHlsZT0iZm9udC1mYW1pbHk6IEFyaWFsLCBzYW5zLXNlcmlmOyIgY2xhc3M9IiI+Mi4mbmJz cDsgRW5kcG9pbnRzIE1VU1QgTk9UIGltcGxlbWVudCBydGNwLW5vbi1tdXggKHdlIGNoYW5nZSB0 aGUgc3BlYyBhbmQgbXVzdCBkZWxldGUgdGhlIHVnbHkgY29kZSwgYW5kIG91ciBub24tY29tcGxp YW50IHVudGlsIHdlIGRvKTxvOnAgY2xhc3M9IiI+PC9vOnA+PC9zcGFuPjwvZGl2Pg0KPC9kaXY+ DQo8ZGl2IGNsYXNzPSIiPg0KPGRpdiBzdHlsZT0ibWFyZ2luOiAwY20gMGNtIDAuMDAwMXB0OyBm b250LXNpemU6IDEycHQ7IGZvbnQtZmFtaWx5OiAnVGltZXMgTmV3IFJvbWFuJywgc2VyaWY7IiBj bGFzcz0iIj4NCjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTogQXJpYWwsIHNhbnMtc2VyaWY7IiBj bGFzcz0iIj4mbmJzcDs8L3NwYW4+PC9kaXY+DQo8L2Rpdj4NCjxkaXYgY2xhc3M9IiI+DQo8ZGl2 IHN0eWxlPSJtYXJnaW46IDBjbSAwY20gMC4wMDAxcHQ7IGZvbnQtc2l6ZTogMTJwdDsgZm9udC1m YW1pbHk6ICdUaW1lcyBOZXcgUm9tYW4nLCBzZXJpZjsiIGNsYXNzPSIiPg0KPHNwYW4gc3R5bGU9 ImZvbnQtZmFtaWx5OiBBcmlhbCwgc2Fucy1zZXJpZjsiIGNsYXNzPSIiPjMuJm5ic3A7IEVuZHBv aW50cyBNVVNUIGltcGxlbWVudCBydGNwLW5vbi1tdXggKHdlIGRvbid0IGNoYW5nZSB0aGUgc3Bl YyBhbmQga2VlcCBhcm91bmQgdGhlIHVnbHkgY29kZSk8bzpwIGNsYXNzPSIiPjwvbzpwPjwvc3Bh bj48L2Rpdj4NCjwvZGl2Pg0KPGRpdiBjbGFzcz0iIj4NCjxkaXYgc3R5bGU9Im1hcmdpbjogMGNt IDBjbSAwLjAwMDFwdDsgZm9udC1zaXplOiAxMnB0OyBmb250LWZhbWlseTogJ1RpbWVzIE5ldyBS b21hbicsIHNlcmlmOyIgY2xhc3M9IiI+DQo8c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6IEFyaWFs LCBzYW5zLXNlcmlmOyIgY2xhc3M9IiI+Jm5ic3A7PC9zcGFuPjwvZGl2Pg0KPC9kaXY+DQo8ZGl2 IGNsYXNzPSIiPg0KPGRpdiBzdHlsZT0ibWFyZ2luOiAwY20gMGNtIDAuMDAwMXB0OyBmb250LXNp emU6IDEycHQ7IGZvbnQtZmFtaWx5OiAnVGltZXMgTmV3IFJvbWFuJywgc2VyaWY7IiBjbGFzcz0i Ij4NCjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTogQXJpYWwsIHNhbnMtc2VyaWY7IiBjbGFzcz0i Ij4mbmJzcDs8L3NwYW4+PC9kaXY+DQo8L2Rpdj4NCjxkaXYgY2xhc3M9IiI+DQo8ZGl2IHN0eWxl PSJtYXJnaW46IDBjbSAwY20gMC4wMDAxcHQ7IGZvbnQtc2l6ZTogMTJwdDsgZm9udC1mYW1pbHk6 ICdUaW1lcyBOZXcgUm9tYW4nLCBzZXJpZjsiIGNsYXNzPSIiPg0KPHNwYW4gc3R5bGU9ImZvbnQt ZmFtaWx5OiBBcmlhbCwgc2Fucy1zZXJpZjsiIGNsYXNzPSIiPk15IHJlYWRpbmcgb2YgdGhlIGRp c2N1c3Npb24gaXMgdGhhdCBtb3N0IHBlb3BsZSB3YW50ICMxIG9yICMyLCBhbmQgdmVyeSBmZXcg cGVvcGxlIHN0aWxsIHdhbnQgIzMuICZuYnNwOyBCZXR3ZWVuICMxIGFuZCAjMiwgd2hpbGUgc29t ZSBwZW9wbGUgd291bGQgcHJlZmVyICMyLCB0aGVyZSBhcmUgZ29vZCByZWFzb25zIHRvIGp1c3Qg ZG8gIzEsIGFuZCBtb3N0DQogc2VlbSB0byBwcmVmZXIgIzEuJm5ic3A7IEZ1cnRoZXIsIEknbSBn dWVzc2luZyB0aGF0IG1vc3QgcGVvcGxlIHdobyB3YW50ZWQgIzIgY291bGQgbGl2ZSB3aXRoICMx LjxvOnAgY2xhc3M9IiI+PC9vOnA+PC9zcGFuPjwvZGl2Pg0KPC9kaXY+DQo8ZGl2IGNsYXNzPSIi Pg0KPGRpdiBzdHlsZT0ibWFyZ2luOiAwY20gMGNtIDAuMDAwMXB0OyBmb250LXNpemU6IDEycHQ7 IGZvbnQtZmFtaWx5OiAnVGltZXMgTmV3IFJvbWFuJywgc2VyaWY7IiBjbGFzcz0iIj4NCjxzcGFu IHN0eWxlPSJmb250LWZhbWlseTogQXJpYWwsIHNhbnMtc2VyaWY7IiBjbGFzcz0iIj4mbmJzcDs8 L3NwYW4+PC9kaXY+DQo8L2Rpdj4NCjxkaXYgY2xhc3M9IiI+DQo8ZGl2IHN0eWxlPSJtYXJnaW46 IDBjbSAwY20gMC4wMDAxcHQ7IGZvbnQtc2l6ZTogMTJwdDsgZm9udC1mYW1pbHk6ICdUaW1lcyBO ZXcgUm9tYW4nLCBzZXJpZjsiIGNsYXNzPSIiPg0KPHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiBB cmlhbCwgc2Fucy1zZXJpZjsiIGNsYXNzPSIiPiZuYnNwOzwvc3Bhbj48L2Rpdj4NCjwvZGl2Pg0K PGRpdiBjbGFzcz0iIj4NCjxkaXYgc3R5bGU9Im1hcmdpbjogMGNtIDBjbSAwLjAwMDFwdDsgZm9u dC1zaXplOiAxMnB0OyBmb250LWZhbWlseTogJ1RpbWVzIE5ldyBSb21hbicsIHNlcmlmOyIgY2xh c3M9IiI+DQo8c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6IEFyaWFsLCBzYW5zLXNlcmlmOyIgY2xh c3M9IiI+VEw7RFI6ICZuYnNwO0kgdGhpbmsgd2UgbWF5IGhhdmUgcm91Z2ggY29uc2Vuc3VzIG9u ICMxLCBzYXlpbmcgZW5kcG9pbnRzIE1BWSBydGNwLW5vbi1tdXggKGJ1dCBtYXkgY2hvb3NlIHRv IGRlbGV0ZSBhbGwgdGhhdCB1Z2x5IGNvZGUgaW5zdGVhZCkuICZuYnNwOzxvOnAgY2xhc3M9IiI+ PC9vOnA+PC9zcGFuPjwvZGl2Pg0KPC9kaXY+DQo8ZGl2IGNsYXNzPSIiPg0KPGRpdiBzdHlsZT0i bWFyZ2luOiAwY20gMGNtIDAuMDAwMXB0OyBmb250LXNpemU6IDEycHQ7IGZvbnQtZmFtaWx5OiAn VGltZXMgTmV3IFJvbWFuJywgc2VyaWY7IiBjbGFzcz0iIj4NCjxzcGFuIHN0eWxlPSJmb250LWZh bWlseTogQXJpYWwsIHNhbnMtc2VyaWY7IiBjbGFzcz0iIj4mbmJzcDs8L3NwYW4+PC9kaXY+DQo8 L2Rpdj4NCjxkaXYgY2xhc3M9IiI+DQo8ZGl2IHN0eWxlPSJtYXJnaW46IDBjbSAwY20gMC4wMDAx cHQ7IGZvbnQtc2l6ZTogMTJwdDsgZm9udC1mYW1pbHk6ICdUaW1lcyBOZXcgUm9tYW4nLCBzZXJp ZjsiIGNsYXNzPSIiPg0KPHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiBBcmlhbCwgc2Fucy1zZXJp ZjsiIGNsYXNzPSIiPiZuYnNwOzwvc3Bhbj48L2Rpdj4NCjwvZGl2Pg0KPGRpdiBjbGFzcz0iIj4N CjxkaXYgc3R5bGU9Im1hcmdpbjogMGNtIDBjbSAwLjAwMDFwdDsgZm9udC1zaXplOiAxMnB0OyBm b250LWZhbWlseTogJ1RpbWVzIE5ldyBSb21hbicsIHNlcmlmOyIgY2xhc3M9IiI+DQo8c3BhbiBz dHlsZT0iZm9udC1mYW1pbHk6IEFyaWFsLCBzYW5zLXNlcmlmOyIgY2xhc3M9IiI+U28sIGlzIGV2 ZXJ5b25lIGhhcHB5IHdpdGggIzE/PG86cCBjbGFzcz0iIj48L286cD48L3NwYW4+PC9kaXY+DQo8 L2Rpdj4NCjxkaXYgY2xhc3M9IiI+DQo8ZGl2IHN0eWxlPSJtYXJnaW46IDBjbSAwY20gMC4wMDAx cHQ7IGZvbnQtc2l6ZTogMTJwdDsgZm9udC1mYW1pbHk6ICdUaW1lcyBOZXcgUm9tYW4nLCBzZXJp ZjsiIGNsYXNzPSIiPg0KPHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiBBcmlhbCwgc2Fucy1zZXJp ZjsiIGNsYXNzPSIiPiZuYnNwOzwvc3Bhbj48L2Rpdj4NCjwvZGl2Pg0KPGRpdiBjbGFzcz0iIj4N CjxkaXYgc3R5bGU9Im1hcmdpbjogMGNtIDBjbSAwLjAwMDFwdDsgZm9udC1zaXplOiAxMnB0OyBm b250LWZhbWlseTogJ1RpbWVzIE5ldyBSb21hbicsIHNlcmlmOyIgY2xhc3M9IiI+DQo8c3BhbiBz dHlsZT0iZm9udC1mYW1pbHk6IEFyaWFsLCBzYW5zLXNlcmlmOyIgY2xhc3M9IiI+Jm5ic3A7PC9z cGFuPjwvZGl2Pg0KPC9kaXY+DQo8ZGl2IGNsYXNzPSIiPg0KPGRpdiBzdHlsZT0ibWFyZ2luOiAw Y20gMGNtIDAuMDAwMXB0OyBmb250LXNpemU6IDEycHQ7IGZvbnQtZmFtaWx5OiAnVGltZXMgTmV3 IFJvbWFuJywgc2VyaWY7IiBjbGFzcz0iIj4NCjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTogQXJp YWwsIHNhbnMtc2VyaWY7IiBjbGFzcz0iIj4mbmJzcDs8L3NwYW4+PC9kaXY+DQo8L2Rpdj4NCjwv ZGl2Pg0KPGRpdiBzdHlsZT0ibWFyZ2luOiAwY20gMGNtIDAuMDAwMXB0OyBmb250LXNpemU6IDEy cHQ7IGZvbnQtZmFtaWx5OiAnVGltZXMgTmV3IFJvbWFuJywgc2VyaWY7IiBjbGFzcz0iIj4NCl9f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fPGJyIGNsYXNzPSIi Pg0KcnRjd2ViIG1haWxpbmcgbGlzdDxiciBjbGFzcz0iIj4NCjxhIGhyZWY9Im1haWx0bzpydGN3 ZWJAaWV0Zi5vcmciIHN0eWxlPSJjb2xvcjogcHVycGxlOyB0ZXh0LWRlY29yYXRpb246IHVuZGVy bGluZTsiIGNsYXNzPSIiPnJ0Y3dlYkBpZXRmLm9yZzwvYT48YnIgY2xhc3M9IiI+DQo8YSBocmVm PSJodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL3J0Y3dlYiIgc3R5bGU9ImNv bG9yOiBwdXJwbGU7IHRleHQtZGVjb3JhdGlvbjogdW5kZXJsaW5lOyIgY2xhc3M9IiI+aHR0cHM6 Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9ydGN3ZWI8L2E+PC9kaXY+DQo8L2Rpdj4N CjwvYmxvY2txdW90ZT4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9ibG9ja3F1 b3RlPg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9ibG9ja3F1b3RlPg0KPC9kaXY+DQo8YnIg Y2xhc3M9IiI+DQo8L2JvZHk+DQo8L2h0bWw+DQo= --_000_D9B4F280E9FE401C81D20FCE3580BF82vidyocom_-- From nobody Mon Aug 10 11:44:00 2015 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6E85D1B29D7 for ; Mon, 10 Aug 2015 11:43:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.2 X-Spam-Level: X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SbkC3gGI4fxv for ; Mon, 10 Aug 2015 11:43:55 -0700 (PDT) Received: from sessmg23.ericsson.net (sessmg23.ericsson.net [193.180.251.45]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 84FFA1B3C9A for ; Mon, 10 Aug 2015 11:43:40 -0700 (PDT) X-AuditID: c1b4fb2d-f79626d000004282-ce-55c8f0da9d31 Received: from ESESSHC005.ericsson.se (Unknown_Domain [153.88.253.124]) by sessmg23.ericsson.net (Symantec Mail Security) with SMTP id E8.44.17026.AD0F8C55; Mon, 10 Aug 2015 20:43:38 +0200 (CEST) Received: from ESESSMB209.ericsson.se ([169.254.9.36]) by ESESSHC005.ericsson.se ([153.88.183.33]) with mapi id 14.03.0210.002; Mon, 10 Aug 2015 20:43:38 +0200 From: Christer Holmberg To: Jonathan Lennox Thread-Topic: [rtcweb] Do we have consensus on not requiring rtcp-non-mux? Thread-Index: AQHQ0VmYDqTJnTo+aUua9ybij+PWb54FMj+AgAAwkMH//+CXAIAARQ4Q///m1gCAACJ/oA== Date: Mon, 10 Aug 2015 18:43:37 +0000 Message-ID: <7594FB04B1934943A5C02806D1A2204B348EFCF9@ESESSMB209.ericsson.se> References: <8A69E109-3F93-4C61-95F2-375FF2103EAB@vidyo.com> <7594FB04B1934943A5C02806D1A2204B348EF447@ESESSMB209.ericsson.se> <58198CC2-984C-4236-8B90-D20BF050A241@vidyo.com> <7594FB04B1934943A5C02806D1A2204B348EFB2F@ESESSMB209.ericsson.se> 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: multipart/alternative; boundary="_000_7594FB04B1934943A5C02806D1A2204B348EFCF9ESESSMB209erics_" MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFprAIsWRmVeSWpSXmKPExsUyM+Jvje6tDydCDWa8N7bYv/g8s8W15a9Z Ldb+a2d3YPZYsKnUY8mSn0webc/usAcwR3HZpKTmZJalFunbJXBl9LV/YivY081U0f78O3sD 444Wpi5GTg4JAROJ/c1zWCFsMYkL99azdTFycQgJHGWUOLz+LzuEs5hRYu36ZsYuRg4ONgEL ie5/2iANIgIaEheffWADsZkFwiWen5wBNlRYwFPi/9KnrBA1XhKvZlxggrDDJNa+mAAWZxFQ lbg18TUjiM0r4Cvxed0nqF0fmSR2blkLNpRTwFbiS9tNZhCbEei676fWMEEsE5e49WQ+1AcC Ekv2nGeGsEUlXj7+B/WNksSi25+h6vMlJr7/wgSxTFDi5MwnLBMYRWchGTULSdksJGWzgF5m FtCUWL9LH6JEUWJK90N2CFtDonXOXHZk8QWM7KsYRYtTi4tz042M9VKLMpOLi/Pz9PJSSzYx AqPw4JbfujsYV792PMQowMGoxMObePZ4qBBrYllxZe4hRmkOFiVx3hmb80KFBNITS1KzU1ML Uovii0pzUosPMTJxcEo1MHYn//K49Z1vxe8La2cdKQ/MvLrYbBK/v3mEXIzAwpdGRTxls1SC tPcrXd1e9/jWzFX7P7H6cPOcfXZLX8nqt8zOJ6n9NaseiH6ev8sh5puUQqPfiux/xdu7TVbU +Wq77N8bO98whUUntdKlUrVved/iwMfWk9NYyldsa5lnX2+4dIeEsJpqqxJLcUaioRZzUXEi ALyD2SajAgAA Archived-At: Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] Do we have consensus on not requiring rtcp-non-mux? X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 10 Aug 2015 18:43:58 -0000 --_000_7594FB04B1934943A5C02806D1A2204B348EFCF9ESESSMB209erics_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SGksDQoNCj5BcmUgeW91IHNlcmlvdXNseSBhZHZvY2F0aW5nIOKAnE1BWSBpbXBsZW1lbnQsIE1V U1QgTk9UIHVzZeKAnT8gIEhvdyBkb2VzIHRoYXQgbWFrZSBhbnkgc2Vuc2UgYXQgYWxsPw0KPg0K PkFzIEkgdW5kZXJzdG9vZCBQZXRlcuKAmXMgb3JpZ2luYWwgb3B0aW9uIDEsIGhlIHdhcyBwcm9w b3NpbmcgdG8gY2hhbmdlIHRoZSBzcGVjIHRvIGFsbG93IHR3byB0eXBlcyBvZiBpbXBsZW1lbnRh dGlvbnM6DQo+DQo+MS4gRW5kcG9pbnRzIHRoYXQgYWx3YXlzIG9mZmVyIG11eCwgYnV0IGFyZSBw cmVwYXJlZCBmb3IgYW4gYW5zd2VyIHRoYXQgZGVjbGluZXMgdG8gZG8gaXQsIGF0IHdoaWNoIHBv aW50IHRoZXkgZmFsbCBiYWNrIHRvIG5vbi1tdXguID4oVGhlIGN1cnJlbnQgZGVmYXVsdCBiZWhh dmlvciwgYW5kIHRoZSBiZWhhdmlvciByZXF1aXJlZCBieSBSRkMgNTc2MS4pDQo+DQo+Mi4gRW5k cG9pbnRzIHRoYXQgYWx3YXlzIG9mZmVyIG11eCwgaW4gYSB3YXkgc3VjaCB0aGF0IHRoZXJlIGlz IG5vIHdheSB0byBmYWxsIGJhY2sgdG8gbm9uLW11eC4gIE5haXZlIGludGVyb3Agd2l0aCBhIG5v bi1ydGNwLW11eCA+ZW5kcG9pbnQsIG9yIHdpdGggYW4gZW5kcG9pbnQgdGhhdCBkb2VzbuKAmXQg d2FudCB0byBkbyBtdXgsIHdpbGwgZmFpbC4gKFRoZSBjdXJyZW50IHJ0Y3BNdXhQb2xpY3k6InJl cXVpcmUiIGJlaGF2aW9yLikNCj4NCj5JZiB5b3Ugc2F5IHRoYXQgbm8gZW5kcG9pbnQgY2FuIGV2 ZXIgZG8gZmFsbGJhY2sgdG8gbm9uLU1VWCwgSSBkb27igJl0IHNlZSB3aGF0IHRoZSBwb2ludCBp cy4gIFlvdeKAmXJlIGluc3RlYWQgYWR2b2NhdGluZyBmb3IgUGV0ZXLigJlzID5vcHRpb24gMi4N Cg0KRmFpciBlbm91Z2gsIEkgaGVhciB3aGF0IHlvdeKAmXJlIHNheWluZy4NCg0KU28sIGlmIHdl IHdhbnQgdG8gYWxsb3cgZmFsbGJhY2sgdG8gbm9uLU1VWCwgdGhlbiBJIERPIGFncmVlIHdpdGgg eW91IHRoYXQgd2UgbmVlZCBhIHdheSBmb3IgYW4gZW50aXR5IHRvIGluZGljYXRlIHRoYXQgaXQg YWxzbyBzdXBwb3J0cyBub24tbXV4Lg0KDQo+QXMgSSBtZW50aW9uZWQgZWFybGllciBpbiB0aGlz IHRocmVhZCwgb25lIHNvbHV0aW9uIHRvIG15IHByb2JsZW0g4oCUIHdoaWNoIEkgZG9u4oCZdCBs aWtlIHRoaXMgYmVjYXVzZSBpdOKAmXMgbWl4aW5nIHVwIGZlYXR1cmVzIHdoaWNoIElNTyA+c2hv dWxkIGJlIG9ydGhvZ29uYWwsIGJ1dCBJIHdvdWxkIGJlIG9rYXkgd2l0aCDigJQgd291bGQgYmUg dG8gc2F5IHNvbWV0aGluZyBsaWtlIOKAnG9mZmVycyB0aGF0IHN1cHBvcnQgZmFsbGJhY2sgdG8g bm9uLVJUQ1AtbXV4ID5NVVNUIGluY2x1ZGUgc2VwYXJhdGUgSUNFIGNhbmRpZGF0ZXMgZm9yIFJU Q1AsIGkuZS4gb24gY29tcG9uZW50IDI7IG9mZmVycyB0aGF0IGRvIG5vdCBzdXBwb3J0IHN1Y2gg ZmFsbGJhY2sgTVVTVCBOT1QgaW5jbHVkZSA+c3VjaCBjYW5kaWRhdGVzLuKAnQ0KDQpUaGF0IHdv dWxkIGJlIGFuIG9wdGlvbiDigJMgT1IgeW91IGluY2x1ZGUgUlRQIGFuZCBSVENQIGNhbmRpZGF0 ZXMgd2l0aCBpZGVudGljYWwgdmFsdWVzLg0KDQo+VGhlIG9ubHkgZGlmZmljdWx0eSB3aXRoIHRo aXMgc29sdXRpb24gaXMgdGhhdCBpdCBjYW4gYmUgYW1iaWd1b3VzIHdoZW4gdHJpY2tsZSBJQ0Ug aXMgYmVpbmcgdXNlZCwgc2luY2UgYW4gb2ZmZXIgbWlnaHQgbm90IGluY2x1ZGUgYW55ID5jYW5k aWRhdGVzIGF0IGFsbC4NCg0KPFRoaXMgaXMgdGhlIHBsYWNlIHdoZXJlIEVtaWwgd2lsbCByZXBs eSwgc2F5aW5nIHRoYXQgaGUgc2VlcyBubyBpc3N1ZSwgYW5kIGV4cGxhaW4gaG93IGl0IHdvdWxk IHdvcms+IDopDQoNClJlZ2FyZHMsDQoNCkNocmlzdGVyDQoNCg0KDQoNCg0KT24gQXVnIDEwLCAy MDE1LCBhdCAyOjAyIFBNLCBDaHJpc3RlciBIb2xtYmVyZyA8Y2hyaXN0ZXIuaG9sbWJlcmdAZXJp Y3Nzb24uY29tPG1haWx0bzpjaHJpc3Rlci5ob2xtYmVyZ0Blcmljc3Nvbi5jb20+PiB3cm90ZToN Cg0KSGksDQoNCj5UaGUgd2hvbGUgcG9pbnQgb2Ygc3VwcG9ydGluZyBub24tTVVYIG1vZGUgaXMg dG8gYWxsb3cgYW5zd2VyZXJzIHRvIGNob29zZSBub3QgdG8gaW5zZXJ0IHRoZSBTRFAgYXR0cmli dXRlLg0KDQpGcm9tIGEgcHJvdG9jb2wgcGVyc3BlY3RpdmUsIHllcy4gQnV0LCBpZiB3ZSBzYXkg dGhhdCBhIFdlYlJUQyBlbnRpdHkgTVVTVCBzdXBwb3J0L3VzZSBydGNwLW11eCwgdGhlbiBpdCBt ZWFucyB0aGF0IGl0IE1VU1QgaW5jbHVkZSB0aGUgYXR0cmlidXRlIOKAkyBFVkVOIGlmIHRoZSBw cm90b2NvbCBhbGxvd3MgaXQgbm90IHRvLg0KDQo+V2l0aCBvcHRpb24gMSwgdGhlIGlkZWEgaXMg dGhhdCBzb21lIGVuZHBvaW50cyB3aWxsIG9mZmVyIE1VWCwgYnV0IHN1cHBvcnQgZmFsbGJhY2sg dG8gbm9uLU1VWCBpZiB0aGUgcGVlciBjaG9vc2VzIG5vdCB0byBkbyBpdC4NCg0KTXkgdW5kZXJz dGFuZGluZyBvZiBvcHRpb24gMSBpcyB0aGF0IHNvbWUgZW5kcG9pbnRzIHdpbGwgKk9OTFkqIGlt cGxlbWVudCBNVVgsIGFuZCB3aWxsIE5PVCBmYWxsYmFjayB0byBub24tTVVYIGlmIHRoZSBwZWVy IChhIG5vbi1XZWJSVEMgZW50aXR5KSBjaG9vc2VzIG5vdCB0byBkbyBpdC4NCg0KPlNvbWUgb3Ro ZXIgZW5kcG9pbnRzIHdpbGwgcmVxdWlyZSB0aGF0IE1VWCBiZSBzdXBwb3J0ZWQsIGFuZCBpZiBh IHBlZXIgZG9lc27igJl0IHVuZGVyc3RhbmQgdGhpcyB0aGVuIHRoaW5ncyB3aWxsIGZhaWwgaW4g aW50ZXJlc3RpbmcgPndheXMuDQoNCldlbGwsIHRoZSBlbmRwb2ludCB0aGF0IHdhbnRzIE1VWCB3 aWxsIGhhdmUgdG8gdGVybWluYXRlIHRoZSBjYWxsLg0KDQo+SWYgSeKAmW0gKHNheSkgYSBnYXRl d2F5IHRoYXQgd291bGQgcmF0aGVyIGRvIG5vbi1NVVggKHRvIGtlZXAgbXkgbGlmZSBlYXNpZXIg d2hlbiBnYXRld2F5aW5nIHRvIGxlZ2FjeSBlcXVpcG1lbnQpLCBidXQgaXMgd2lsbGluZyB0byA+ ZG8gTVVYIGlmIG5lY2Vzc2FyeSwgSSBuZWVkIHRvIGtub3cgd2hpY2ggc29ydCBvZiBlbmRwb2lu dCBJ4oCZbSB0YWxraW5nIHRvLg0KDQpNeSB1bmRlcnN0YW5kaW5nIG9mICMxIGlzIHRoYXQgdGhl cmUgaXMgbm8gc3VjaCB0aGluZ3MgYXMg4oCcd291bGQgcmF0aGVyIGRvIG5vbi1NVVjigJ0uIEFz IGEgV2ViUlRDIGdhdGV3YXksIHlvdSB3b3VsZCBhbHdheXMgZG8gTVVYIChhdCBsZWFzdCB0b3dh cmRzIHRoZSBXZWJSVEMgZW5kcG9pbnRzKS4NCg0KPkhvd2V2ZXIsIGJvdGggdHlwZXMgb2YgZW5k cG9pbnRzIHdpbGwgaGF2ZSBpbnNlcnRlZCB0aGUgYXR0cmlidXRlIGluIHRoZWlyIG9mZmVyLg0K DQpBbmQsIGFzIGEgV2ViUlRDIGVuZHBvaW50LCB5b3Ugd2lsbCBhbHdheXMgaW5zZXJ0IHRoZSBh dHRyaWJ1dGUgaW4gdGhlIGFuc3dlci4NCg0KPklmIHlvdSByZXF1aXJlIHRoYXQgYWxsIGVudGl0 aWVzIE1VU1QgYWx3YXlzIGluc2VydCB0aGUgU0RQIGF0dHJpYnV0ZSBpbiBib3RoIG9mZmVycyAq YW5kIGFuc3dlcnMqLCB0aGVuIHlvdeKAmXJlIGNob29zaW5nIG9wdGlvbiAyLiAoQSA+c3RhbmRh cmQgdGhhdCBzYXlzIOKAnHlvdSBNQVkgaGF2ZSBjb2RlIHRoYXQgaW1wbGVtZW50cyB0aGlzIG1v ZGUsIGJ1dCB5b3UgTVVTVCBOT1QgZXZlciB1c2UgaXTigJ0gaXMgcHJldHR5IHBvaW50bGVzcy4p DQoNClJlZ2FyZGluZyAjMiwgZW5kcG9pbnRzIGNhbiBpbXBsZW1lbnQgd2hhdGV2ZXIgdGhleSB3 YW50LiBUaGUgcG9pbnQgaXMgdGhhdCB0aGV5IHdvdWxkIG5ldmVyICpVU0UqIG5vbi1NVVguDQoN ClJlZ2FyZHMsDQoNCkNocmlzdGVyDQoNCk9uIEF1ZyAxMCwgMjAxNSwgYXQgMTE6MzkgQU0sIENo cmlzdGVyIEhvbG1iZXJnIDxjaHJpc3Rlci5ob2xtYmVyZ0Blcmljc3Nvbi5jb208bWFpbHRvOmNo cmlzdGVyLmhvbG1iZXJnQGVyaWNzc29uLmNvbT4+IHdyb3RlOg0KDQpIaSBKb25hdGhhbiwNCg0K V2h5IGNhbid0IHdlIHNpbXBseSBzYXkgdGhhdCBlbnRpdGllcyBNVVNUIGluc2VydCB0aGUgU0RQ IGF0dHJpYnV0ZSBpbiBvZmZlcnMgYW5kIGFuc3dlcnM/DQoNClJlZ2FyZHMsDQoNCkNocmlzdGVy DQoNClNlbnQgZnJvbSBteSBXaW5kb3dzIFBob25lDQpfX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fXw0KRnJvbTogSm9uYXRoYW4gTGVubm94PG1haWx0bzpqb25hdGhhbkB2aWR5by5jb20+ DQpTZW50OiDigI4xMC/igI4wOC/igI4yMDE1IDE3OjQ2DQpUbzogR29vZ2xlLVBldGVyIFRoYXRj aGVyPG1haWx0bzpwdGhhdGNoZXJAZ29vZ2xlLmNvbT4NCkNjOiBydGN3ZWJAaWV0Zi5vcmc8bWFp bHRvOnJ0Y3dlYkBpZXRmLm9yZz4NClN1YmplY3Q6IFJlOiBbcnRjd2ViXSBEbyB3ZSBoYXZlIGNv bnNlbnN1cyBvbiBub3QgcmVxdWlyaW5nIHJ0Y3Atbm9uLW11eD8NCiMxIHNlZW1zIGJlc3QgdG8g bWUsIGJ1dCB0aGVyZSBuZWVkcyB0byBiZSBzb21lIHdlbGwtc3BlY2lmaWVkIHdheSBmb3IgSlMg YXBwbGljYXRpb25zIGFuZCBvZmZlci9hbnN3ZXIgcGVlcnMgdG8gZGlzY292ZXIvdW5kZXJzdGFu ZCB3aGV0aGVyIHJ0Y3Atbm9uLW11eCBpcyBpbmRlZWQgc3VwcG9ydGVkLiAgT3RoZXJ3aXNlIHRo ZXJl4oCZcyBubyBwcmFjdGljYWwgZGlmZmVyZW5jZSBiZXR3ZWVuICMxIGFuZCAjMi4NCg0KDQoN Ck9uIEF1ZyA3LCAyMDE1LCBhdCA1OjM5IFBNLCBQZXRlciBUaGF0Y2hlciA8cHRoYXRjaGVyQGdv b2dsZS5jb208bWFpbHRvOnB0aGF0Y2hlckBnb29nbGUuY29tPj4gd3JvdGU6DQoNCkFmdGVyIGxv dHMgb2YgZGlzY3Vzc2lvbiwgaXQgYXBwZWFycyB3ZSBoYXZlIHRocmVlIG9wdGlvbnM6DQoNCjEu ICBFbmRwb2ludHMgTUFZIGltcGxlbWVudCBydGNwLW5vbi1tdXggKHdlIGNoYW5nZSB0aGUgc3Bl YyBhbmQgY2FuIGRlbGV0ZSB0aGUgdWdseSBjb2RlKQ0KDQoyLiAgRW5kcG9pbnRzIE1VU1QgTk9U IGltcGxlbWVudCBydGNwLW5vbi1tdXggKHdlIGNoYW5nZSB0aGUgc3BlYyBhbmQgbXVzdCBkZWxl dGUgdGhlIHVnbHkgY29kZSwgYW5kIG91ciBub24tY29tcGxpYW50IHVudGlsIHdlIGRvKQ0KDQoz LiAgRW5kcG9pbnRzIE1VU1QgaW1wbGVtZW50IHJ0Y3Atbm9uLW11eCAod2UgZG9uJ3QgY2hhbmdl IHRoZSBzcGVjIGFuZCBrZWVwIGFyb3VuZCB0aGUgdWdseSBjb2RlKQ0KDQoNCk15IHJlYWRpbmcg b2YgdGhlIGRpc2N1c3Npb24gaXMgdGhhdCBtb3N0IHBlb3BsZSB3YW50ICMxIG9yICMyLCBhbmQg dmVyeSBmZXcgcGVvcGxlIHN0aWxsIHdhbnQgIzMuICAgQmV0d2VlbiAjMSBhbmQgIzIsIHdoaWxl IHNvbWUgcGVvcGxlIHdvdWxkIHByZWZlciAjMiwgdGhlcmUgYXJlIGdvb2QgcmVhc29ucyB0byBq dXN0IGRvICMxLCBhbmQgbW9zdCBzZWVtIHRvIHByZWZlciAjMS4gIEZ1cnRoZXIsIEknbSBndWVz c2luZyB0aGF0IG1vc3QgcGVvcGxlIHdobyB3YW50ZWQgIzIgY291bGQgbGl2ZSB3aXRoICMxLg0K DQoNClRMO0RSOiAgSSB0aGluayB3ZSBtYXkgaGF2ZSByb3VnaCBjb25zZW5zdXMgb24gIzEsIHNh eWluZyBlbmRwb2ludHMgTUFZIHJ0Y3Atbm9uLW11eCAoYnV0IG1heSBjaG9vc2UgdG8gZGVsZXRl IGFsbCB0aGF0IHVnbHkgY29kZSBpbnN0ZWFkKS4NCg0KDQpTbywgaXMgZXZlcnlvbmUgaGFwcHkg d2l0aCAjMT8NCg0KDQoNCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fDQpydGN3ZWIgbWFpbGluZyBsaXN0DQpydGN3ZWJAaWV0Zi5vcmc8bWFpbHRvOnJ0Y3dl YkBpZXRmLm9yZz4NCmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vcnRjd2Vi DQoNCg== --_000_7594FB04B1934943A5C02806D1A2204B348EFCF9ESESSMB209erics_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPCEtLVtp ZiAhbXNvXT48c3R5bGU+dlw6KiB7YmVoYXZpb3I6dXJsKCNkZWZhdWx0I1ZNTCk7fQ0Kb1w6KiB7 YmVoYXZpb3I6dXJsKCNkZWZhdWx0I1ZNTCk7fQ0Kd1w6KiB7YmVoYXZpb3I6dXJsKCNkZWZhdWx0 I1ZNTCk7fQ0KLnNoYXBlIHtiZWhhdmlvcjp1cmwoI2RlZmF1bHQjVk1MKTt9DQo8L3N0eWxlPjwh W2VuZGlmXS0tPjxzdHlsZT48IS0tDQovKiBGb250IERlZmluaXRpb25zICovDQpAZm9udC1mYWNl DQoJe2ZvbnQtZmFtaWx5OiJDYW1icmlhIE1hdGgiOw0KCXBhbm9zZS0xOjIgNCA1IDMgNSA0IDYg MyAyIDQ7fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseTpDYWxpYnJpOw0KCXBhbm9zZS0xOjIg MTUgNSAyIDIgMiA0IDMgMiA0O30NCi8qIFN0eWxlIERlZmluaXRpb25zICovDQpwLk1zb05vcm1h bCwgbGkuTXNvTm9ybWFsLCBkaXYuTXNvTm9ybWFsDQoJe21hcmdpbjowY207DQoJbWFyZ2luLWJv dHRvbTouMDAwMXB0Ow0KCWZvbnQtc2l6ZToxMi4wcHQ7DQoJZm9udC1mYW1pbHk6IlRpbWVzIE5l dyBSb21hbiIsc2VyaWY7fQ0KYTpsaW5rLCBzcGFuLk1zb0h5cGVybGluaw0KCXttc28tc3R5bGUt cHJpb3JpdHk6OTk7DQoJY29sb3I6Ymx1ZTsNCgl0ZXh0LWRlY29yYXRpb246dW5kZXJsaW5lO30N CmE6dmlzaXRlZCwgc3Bhbi5Nc29IeXBlcmxpbmtGb2xsb3dlZA0KCXttc28tc3R5bGUtcHJpb3Jp dHk6OTk7DQoJY29sb3I6cHVycGxlOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0Kc3Bh bi5hcHBsZS1jb252ZXJ0ZWQtc3BhY2UNCgl7bXNvLXN0eWxlLW5hbWU6YXBwbGUtY29udmVydGVk LXNwYWNlO30NCnNwYW4uRW1haWxTdHlsZTE4DQoJe21zby1zdHlsZS10eXBlOnBlcnNvbmFsOw0K CWZvbnQtZmFtaWx5OiJDYWxpYnJpIixzYW5zLXNlcmlmOw0KCWNvbG9yOiMxRjQ5N0Q7fQ0Kc3Bh bi5FbWFpbFN0eWxlMTkNCgl7bXNvLXN0eWxlLXR5cGU6cGVyc29uYWwtY29tcG9zZTsNCglmb250 LWZhbWlseToiQ2FsaWJyaSIsc2Fucy1zZXJpZjsNCgljb2xvcjp3aW5kb3d0ZXh0O30NCi5Nc29D aHBEZWZhdWx0DQoJe21zby1zdHlsZS10eXBlOmV4cG9ydC1vbmx5Ow0KCWZvbnQtc2l6ZToxMC4w cHQ7fQ0KQHBhZ2UgV29yZFNlY3Rpb24xDQoJe3NpemU6NjEyLjBwdCA3OTIuMHB0Ow0KCW1hcmdp bjo3Mi4wcHQgNzIuMHB0IDcyLjBwdCA3Mi4wcHQ7fQ0KZGl2LldvcmRTZWN0aW9uMQ0KCXtwYWdl OldvcmRTZWN0aW9uMTt9DQotLT48L3N0eWxlPjwhLS1baWYgZ3RlIG1zbyA5XT48eG1sPg0KPG86 c2hhcGVkZWZhdWx0cyB2OmV4dD0iZWRpdCIgc3BpZG1heD0iMTAyNiIgLz4NCjwveG1sPjwhW2Vu ZGlmXS0tPjwhLS1baWYgZ3RlIG1zbyA5XT48eG1sPg0KPG86c2hhcGVsYXlvdXQgdjpleHQ9ImVk aXQiPg0KPG86aWRtYXAgdjpleHQ9ImVkaXQiIGRhdGE9IjEiIC8+DQo8L286c2hhcGVsYXlvdXQ+ PC94bWw+PCFbZW5kaWZdLS0+DQo8L2hlYWQ+DQo8Ym9keSBsYW5nPSJFTi1HQiIgbGluaz0iYmx1 ZSIgdmxpbms9InB1cnBsZSI+DQo8ZGl2IGNsYXNzPSJXb3JkU2VjdGlvbjEiPg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1 b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0Q7bXNvLWZhcmVhc3QtbGFu Z3VhZ2U6RU4tVVMiPkhpLDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPiZn dDtBcmUgeW91IHNlcmlvdXNseSBhZHZvY2F0aW5nIOKAnE1BWSBpbXBsZW1lbnQsIE1VU1QgTk9U IHVzZeKAnT8gJm5ic3A7SG93IGRvZXMgdGhhdCBtYWtlIGFueSBzZW5zZSBhdCBhbGw/PG86cD48 L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4mZ3Q7PG86cD4m bmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4mZ3Q7 QXMgSSB1bmRlcnN0b29kIFBldGVy4oCZcyBvcmlnaW5hbCBvcHRpb24gMSwgaGUgd2FzIHByb3Bv c2luZyB0byBjaGFuZ2UgdGhlIHNwZWMgdG8gYWxsb3cgdHdvIHR5cGVzIG9mIGltcGxlbWVudGF0 aW9uczo8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PiZndDs8bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPiZndDsxLiBFbmRwb2ludHMgdGhhdCBhbHdheXMgb2ZmZXIgbXV4LCBidXQgYXJlIHBy ZXBhcmVkIGZvciBhbiBhbnN3ZXIgdGhhdCBkZWNsaW5lcyB0byBkbyBpdCwgYXQgd2hpY2ggcG9p bnQgdGhleSBmYWxsIGJhY2sgdG8gbm9uLW11eC4gJmd0OyhUaGUgY3VycmVudCBkZWZhdWx0IGJl aGF2aW9yLCBhbmQgdGhlIGJlaGF2aW9yIHJlcXVpcmVkIGJ5IFJGQyA1NzYxLik8bzpwPjwvbzpw PjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPiZndDs8bzpwPiZuYnNw OzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPiZndDsyLiBF bmRwb2ludHMgdGhhdCBhbHdheXMgb2ZmZXIgbXV4LCBpbiBhIHdheSBzdWNoIHRoYXQgdGhlcmUg aXMgbm8gd2F5IHRvIGZhbGwgYmFjayB0byBub24tbXV4LiAmbmJzcDtOYWl2ZSBpbnRlcm9wIHdp dGggYSBub24tcnRjcC1tdXggJmd0O2VuZHBvaW50LCBvciB3aXRoIGFuIGVuZHBvaW50IHRoYXQg ZG9lc27igJl0IHdhbnQgdG8gZG8gbXV4LCB3aWxsIGZhaWwuIChUaGUgY3VycmVudCBydGNwTXV4 UG9saWN5OiZxdW90O3JlcXVpcmUmcXVvdDsNCiBiZWhhdmlvci4pPG86cD48L286cD48L3A+DQo8 L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4mZ3Q7PG86cD4mbmJzcDs8L286cD48 L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4mZ3Q7SWYgeW91IHNheSB0aGF0IG5vIGVuZHBvaW50 IGNhbiBldmVyIGRvIGZhbGxiYWNrIHRvIG5vbi1NVVgsIEkgZG9u4oCZdCBzZWUgd2hhdCB0aGUg cG9pbnQgaXMuICZuYnNwO1lvdeKAmXJlIGluc3RlYWQgYWR2b2NhdGluZyBmb3IgUGV0ZXLigJlz ICZndDtvcHRpb24gMi48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+ Jm5ic3A7PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+RmFpciBlbm91Z2gsIEkgaGVh ciB3aGF0IHlvdeKAmXJlIHNheWluZy48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+U28sIGlmIHdl IHdhbnQgdG8gYWxsb3cgZmFsbGJhY2sgdG8gbm9uLU1VWCwgdGhlbiBJIERPIGFncmVlIHdpdGgg eW91IHRoYXQgd2UgbmVlZCBhIHdheSBmb3IgYW4gZW50aXR5IHRvIGluZGljYXRlIHRoYXQgaXQg YWxzbyBzdXBwb3J0cyBub24tbXV4LjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1p bHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bh bj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4mZ3Q7QXMgSSBtZW50 aW9uZWQgZWFybGllciBpbiB0aGlzIHRocmVhZCwgb25lIHNvbHV0aW9uIHRvIG15IHByb2JsZW0g 4oCUIHdoaWNoIEkgZG9u4oCZdCBsaWtlIHRoaXMgYmVjYXVzZSBpdOKAmXMgbWl4aW5nIHVwIGZl YXR1cmVzIHdoaWNoIElNTyAmZ3Q7c2hvdWxkIGJlIG9ydGhvZ29uYWwsIGJ1dCBJIHdvdWxkIGJl IG9rYXkgd2l0aCDigJQgd291bGQgYmUgdG8gc2F5IHNvbWV0aGluZyBsaWtlIOKAnG9mZmVycyB0 aGF0IHN1cHBvcnQNCiBmYWxsYmFjayB0byBub24tUlRDUC1tdXggJmd0O01VU1QgaW5jbHVkZSBz ZXBhcmF0ZSBJQ0UgY2FuZGlkYXRlcyBmb3IgUlRDUCwgaS5lLiBvbiBjb21wb25lbnQgMjsgb2Zm ZXJzIHRoYXQgZG8gbm90IHN1cHBvcnQgc3VjaCBmYWxsYmFjayBNVVNUIE5PVCBpbmNsdWRlICZn dDtzdWNoIGNhbmRpZGF0ZXMu4oCdPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJp JnF1b3Q7LHNhbnMtc2VyaWYiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1m YW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmIj5UaGF0IHdvdWxkIGJlIGFuIG9w dGlvbiDigJMgT1IgeW91IGluY2x1ZGUgUlRQIGFuZCBSVENQIGNhbmRpZGF0ZXMgd2l0aCBpZGVu dGljYWwgdmFsdWVzLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkm cXVvdDssc2Fucy1zZXJpZiI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+Jmd0O1RoZSBvbmx5IGRpZmZpY3VsdHkgd2l0aCB0aGlzIHNvbHV0aW9uIGlz IHRoYXQgaXQgY2FuIGJlIGFtYmlndW91cyB3aGVuIHRyaWNrbGUgSUNFIGlzIGJlaW5nIHVzZWQs IHNpbmNlIGFuIG9mZmVyIG1pZ2h0IG5vdCBpbmNsdWRlIGFueSAmZ3Q7Y2FuZGlkYXRlcyBhdCBh bGwuPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9u dC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWYi PjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFu IHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDss c2Fucy1zZXJpZiI+Jmx0O1RoaXMgaXMgdGhlIHBsYWNlIHdoZXJlIEVtaWwgd2lsbCByZXBseSwg c2F5aW5nIHRoYXQgaGUgc2VlcyBubyBpc3N1ZSwgYW5kIGV4cGxhaW4gaG93IGl0IHdvdWxkIHdv cmsmZ3Q7IDopPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNw YW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90 OyxzYW5zLXNlcmlmIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtD YWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWYiPlJlZ2FyZHMsPG86cD48L286cD48L3NwYW4+PC9wPg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1m YW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmIj48bzpwPiZuYnNwOzwvbzpwPjwv c3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEx LjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWYiPkNocmlzdGVy PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9 ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNl cmlmIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2Fs aWJyaSZxdW90OyxzYW5zLXNlcmlmIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWls eTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWYiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFu PjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0 O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZiI+PG86cD4mbmJzcDs8 L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86 cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8YmxvY2txdW90ZSBzdHlsZT0ibWFy Z2luLXRvcDo1LjBwdDttYXJnaW4tYm90dG9tOjUuMHB0Ij4NCjxkaXY+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj5PbiBBdWcgMTAsIDIwMTUsIGF0IDI6MDIgUE0sIENocmlzdGVyIEhvbG1iZXJnICZs dDs8YSBocmVmPSJtYWlsdG86Y2hyaXN0ZXIuaG9sbWJlcmdAZXJpY3Nzb24uY29tIj5jaHJpc3Rl ci5ob2xtYmVyZ0Blcmljc3Nvbi5jb208L2E+Jmd0OyB3cm90ZTo8bzpwPjwvbzpwPjwvcD4NCjwv ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8ZGl2Pg0K PGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0 O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdE Ij5IaSw8L3NwYW4+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj4mZ3Q7VGhlIHdob2xlIHBvaW50IG9mIHN1cHBvcnRpbmcgbm9uLU1V WCBtb2RlIGlzIHRvIGFsbG93IGFuc3dlcmVycyB0byBjaG9vc2Ugbm90IHRvIGluc2VydCB0aGUg U0RQIGF0dHJpYnV0ZS48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPGRp dj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8 ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7 Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmIj5Gcm9tIGEgcHJvdG9j b2wgcGVyc3BlY3RpdmUsIHllcy4gQnV0LCBpZiB3ZSBzYXkgdGhhdCBhIFdlYlJUQyBlbnRpdHkg TVVTVCBzdXBwb3J0L3VzZSBydGNwLW11eCwgdGhlbiBpdCBtZWFucyB0aGF0IGl0IE1VU1QgaW5j bHVkZSB0aGUgYXR0cmlidXRlIOKAkyBFVkVOIGlmIHRoZSBwcm90b2NvbCBhbGxvd3MNCiBpdCBu b3QgdG8uPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7 Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmIj4mbmJzcDs8L3NwYW4+PG86cD48L286cD48L3A+DQo8 L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4mZ3Q7V2l0 aCBvcHRpb24gMSwgdGhlIGlkZWEgaXMgdGhhdCBzb21lIGVuZHBvaW50cyB3aWxsIG9mZmVyIE1V WCwgYnV0IHN1cHBvcnQgZmFsbGJhY2sgdG8gbm9uLU1VWCBpZiB0aGUgcGVlciBjaG9vc2VzIG5v dCB0byBkbyBpdC48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdj4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2 Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9u dC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmIj5NeSB1bmRlcnN0YW5kaW5n IG9mIG9wdGlvbiAxIGlzIHRoYXQgc29tZSBlbmRwb2ludHMgd2lsbCAqPGI+T05MWTwvYj4qIGlt cGxlbWVudCBNVVgsIGFuZCB3aWxsIE5PVCBmYWxsYmFjayB0byBub24tTVVYIGlmIHRoZSBwZWVy IChhIG5vbi1XZWJSVEMgZW50aXR5KSBjaG9vc2VzIG5vdCB0byBkbyBpdC48L3NwYW4+PG86cD48 L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHls ZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMt c2VyaWYiPiZuYnNwOzwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2 Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPiZndDtTb21lIG90aGVyIGVuZHBvaW50cyB3 aWxsIHJlcXVpcmUgdGhhdCBNVVggYmUgc3VwcG9ydGVkLCBhbmQgaWYgYSBwZWVyIGRvZXNu4oCZ dCB1bmRlcnN0YW5kIHRoaXMgdGhlbiB0aGluZ3Mgd2lsbCBmYWlsIGluIGludGVyZXN0aW5nICZn dDt3YXlzLjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZh bWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWYiPldlbGwsIHRoZSBlbmRwb2ludCB0 aGF0IHdhbnRzIE1VWCB3aWxsIGhhdmUgdG8gdGVybWluYXRlIHRoZSBjYWxsLjwvc3Bhbj48bzpw PjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0 eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fu cy1zZXJpZiI+Jm5ic3A7PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxk aXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Jmd0O0lmIEnigJltIChzYXkpIGEgZ2F0 ZXdheSB0aGF0IHdvdWxkIHJhdGhlciBkbyBub24tTVVYICh0byBrZWVwIG15IGxpZmUgZWFzaWVy IHdoZW4gZ2F0ZXdheWluZyB0byBsZWdhY3kgZXF1aXBtZW50KSwgYnV0IGlzIHdpbGxpbmcgdG8g Jmd0O2RvIE1VWCBpZiBuZWNlc3NhcnksIEkgbmVlZCB0byBrbm93IHdoaWNoIHNvcnQgb2YgZW5k cG9pbnQgSeKAmW0gdGFsa2luZyB0by48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8 ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0K PC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6 ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmIj5NeSB1 bmRlcnN0YW5kaW5nIG9mICMxIGlzIHRoYXQgdGhlcmUgaXMgbm8gc3VjaCB0aGluZ3MgYXMg4oCc d291bGQgcmF0aGVyIGRvIG5vbi1NVVjigJ0uIEFzIGEgV2ViUlRDIGdhdGV3YXksIHlvdSB3b3Vs ZCBhbHdheXMgZG8gTVVYIChhdCBsZWFzdCB0b3dhcmRzIHRoZSBXZWJSVEMgZW5kcG9pbnRzKS48 L3NwYW4+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJp JnF1b3Q7LHNhbnMtc2VyaWYiPiZuYnNwOzwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0K PC9kaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPiZndDtIb3dldmVyLCBi b3RoIHR5cGVzIG9mIGVuZHBvaW50cyB3aWxsIGhhdmUgaW5zZXJ0ZWQgdGhlIGF0dHJpYnV0ZSBp biB0aGVpciBvZmZlci48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPGRp dj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8 ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7 Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmIj5BbmQsIGFzIGEgV2Vi UlRDIGVuZHBvaW50LCB5b3Ugd2lsbCBhbHdheXMgaW5zZXJ0IHRoZSBhdHRyaWJ1dGUgaW4gdGhl IGFuc3dlci48L3NwYW4+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVv dDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWYiPiZuYnNwOzwvc3Bhbj48bzpwPjwvbzpwPjwvcD4N CjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPiZndDtJ ZiB5b3UgcmVxdWlyZSB0aGF0IGFsbCBlbnRpdGllcyBNVVNUIGFsd2F5cyBpbnNlcnQgdGhlIFNE UCBhdHRyaWJ1dGUgaW4gYm90aCBvZmZlcnMgKmFuZCBhbnN3ZXJzKiwgdGhlbiB5b3XigJlyZSBj aG9vc2luZyBvcHRpb24gMi4gKEEgJmd0O3N0YW5kYXJkIHRoYXQgc2F5cyDigJx5b3UgTUFZIGhh dmUgY29kZSB0aGF0IGltcGxlbWVudHMgdGhpcyBtb2RlLCBidXQgeW91IE1VU1QgTk9UIGV2ZXIg dXNlIGl04oCdIGlzIHByZXR0eQ0KIHBvaW50bGVzcy4pPG86cD48L286cD48L3A+DQo8L2Rpdj4N CjwvZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4mbmJzcDs8bzpwPjwv bzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxl PSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1z ZXJpZiI+UmVnYXJkaW5nICMyLCBlbmRwb2ludHMgY2FuIGltcGxlbWVudCB3aGF0ZXZlciB0aGV5 IHdhbnQuIFRoZSBwb2ludCBpcyB0aGF0IHRoZXkgd291bGQgbmV2ZXIgKjxiPlVTRTwvYj4qIG5v bi1NVVguPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFt aWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZiI+UmVnYXJkcyw8L3NwYW4+PG86cD48 L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHls ZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMt c2VyaWYiPiZuYnNwOzwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5 OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZiI+Q2hyaXN0ZXI8L3NwYW4+PG86cD48L286 cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0i Zm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2Vy aWYiPiZuYnNwOzwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxibG9ja3F1 b3RlIHN0eWxlPSJtYXJnaW4tdG9wOjUuMHB0O21hcmdpbi1ib3R0b206NS4wcHQiPg0KPGRpdj4N CjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5PbiBBdWcgMTAsIDIwMTUsIGF0IDExOjM5IEFN LCBDaHJpc3RlciBIb2xtYmVyZyAmbHQ7PGEgaHJlZj0ibWFpbHRvOmNocmlzdGVyLmhvbG1iZXJn QGVyaWNzc29uLmNvbSI+PHNwYW4gc3R5bGU9ImNvbG9yOnB1cnBsZSI+Y2hyaXN0ZXIuaG9sbWJl cmdAZXJpY3Nzb24uY29tPC9zcGFuPjwvYT4mZ3Q7IHdyb3RlOjxvOnA+PC9vOnA+PC9wPg0KPC9k aXY+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4mbmJzcDs8bzpwPjwvbzpw PjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTom cXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWYiPkhpIEpvbmF0aGFuLDxicj4NCjxicj4NCldo eSBjYW4ndCB3ZSBzaW1wbHkgc2F5IHRoYXQgZW50aXRpZXMgTVVTVCBpbnNlcnQgdGhlIFNEUCBh dHRyaWJ1dGUgaW4gb2ZmZXJzIGFuZCBhbnN3ZXJzPzxicj4NCjxicj4NClJlZ2FyZHMsPGJyPg0K PGJyPg0KQ2hyaXN0ZXI8YnI+DQo8YnI+DQpTZW50IGZyb20gbXkgV2luZG93cyBQaG9uZTwvc3Bh bj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2IGNs YXNzPSJNc29Ob3JtYWwiIGFsaWduPSJjZW50ZXIiIHN0eWxlPSJ0ZXh0LWFsaWduOmNlbnRlciI+ DQo8aHIgc2l6ZT0iMyIgd2lkdGg9IjEwMCUiIGFsaWduPSJjZW50ZXIiPg0KPC9kaXY+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWJvdHRvbToxMi4wcHQiPjxiPjxzcGFuIHN0 eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fu cy1zZXJpZiI+RnJvbTo8c3BhbiBjbGFzcz0iYXBwbGUtY29udmVydGVkLXNwYWNlIj4mbmJzcDs8 L3NwYW4+PC9zcGFuPjwvYj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWls eTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWYiPjxhIGhyZWY9Im1haWx0bzpqb25hdGhh bkB2aWR5by5jb20iPjxzcGFuIHN0eWxlPSJjb2xvcjpwdXJwbGUiPkpvbmF0aGFuDQogTGVubm94 PC9zcGFuPjwvYT48L3NwYW4+PGJyPg0KPGI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7 Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmIj5TZW50OjxzcGFuIGNs YXNzPSJhcHBsZS1jb252ZXJ0ZWQtc3BhY2UiPiZuYnNwOzwvc3Bhbj48L3NwYW4+PC9iPjxzcGFu IHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDss c2Fucy1zZXJpZiI+4oCOMTAv4oCOMDgv4oCOMjAxNSAxNzo0Njwvc3Bhbj48YnI+DQo8Yj48c3Bh biBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7 LHNhbnMtc2VyaWYiPlRvOjxzcGFuIGNsYXNzPSJhcHBsZS1jb252ZXJ0ZWQtc3BhY2UiPiZuYnNw Ozwvc3Bhbj48L3NwYW4+PC9iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFt aWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZiI+PGEgaHJlZj0ibWFpbHRvOnB0aGF0 Y2hlckBnb29nbGUuY29tIj48c3BhbiBzdHlsZT0iY29sb3I6cHVycGxlIj5Hb29nbGUtUGV0ZXIN CiBUaGF0Y2hlcjwvc3Bhbj48L2E+PC9zcGFuPjxicj4NCjxiPjxzcGFuIHN0eWxlPSJmb250LXNp emU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZiI+Q2M6 PHNwYW4gY2xhc3M9ImFwcGxlLWNvbnZlcnRlZC1zcGFjZSI+Jm5ic3A7PC9zcGFuPjwvc3Bhbj48 L2I+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJy aSZxdW90OyxzYW5zLXNlcmlmIj48YSBocmVmPSJtYWlsdG86cnRjd2ViQGlldGYub3JnIj48c3Bh biBzdHlsZT0iY29sb3I6cHVycGxlIj5ydGN3ZWJAaWV0Zi5vcmc8L3NwYW4+PC9hPjwvc3Bhbj48 YnI+DQo8Yj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtD YWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWYiPlN1YmplY3Q6PHNwYW4gY2xhc3M9ImFwcGxlLWNvbnZl cnRlZC1zcGFjZSI+Jm5ic3A7PC9zcGFuPjwvc3Bhbj48L2I+PHNwYW4gc3R5bGU9ImZvbnQtc2l6 ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmIj5SZTog W3J0Y3dlYl0gRG8gd2UgaGF2ZSBjb25zZW5zdXMgb24gbm90IHJlcXVpcmluZyBydGNwLW5vbi1t dXg/PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPiMxIHNlZW1zIGJlc3QgdG8gbWUsIGJ1dCB0aGVyZSBuZWVkcyB0byBiZSBz b21lIHdlbGwtc3BlY2lmaWVkIHdheSBmb3IgSlMgYXBwbGljYXRpb25zIGFuZCBvZmZlci9hbnN3 ZXIgcGVlcnMgdG8gZGlzY292ZXIvdW5kZXJzdGFuZCB3aGV0aGVyIHJ0Y3Atbm9uLW11eCBpcyBp bmRlZWQgc3VwcG9ydGVkLiAmbmJzcDtPdGhlcndpc2UgdGhlcmXigJlzIG5vIHByYWN0aWNhbCBk aWZmZXJlbmNlIGJldHdlZW4gIzEgYW5kICMyLjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2 Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxicj4NCjxicj4NCjxicj4NCjxvOnA+PC9v OnA+PC9wPg0KPC9kaXY+DQo8YmxvY2txdW90ZSBzdHlsZT0ibWFyZ2luLXRvcDo1LjBwdDttYXJn aW4tYm90dG9tOjUuMHB0Ij4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+T24g QXVnIDcsIDIwMTUsIGF0IDU6MzkgUE0sIFBldGVyIFRoYXRjaGVyICZsdDs8YSBocmVmPSJtYWls dG86cHRoYXRjaGVyQGdvb2dsZS5jb20iPjxzcGFuIHN0eWxlPSJjb2xvcjpwdXJwbGUiPnB0aGF0 Y2hlckBnb29nbGUuY29tPC9zcGFuPjwvYT4mZ3Q7IHdyb3RlOjxvOnA+PC9vOnA+PC9wPg0KPC9k aXY+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4mbmJzcDs8bzpwPjwvbzpw PjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtBcmlhbCZxdW90OyxzYW5zLXNl cmlmIj5BZnRlciBsb3RzIG9mIGRpc2N1c3Npb24sIGl0IGFwcGVhcnMgd2UgaGF2ZSB0aHJlZSBv cHRpb25zOjwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPGRp dj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtB cmlhbCZxdW90OyxzYW5zLXNlcmlmIj4mbmJzcDs8L3NwYW4+PG86cD48L286cD48L3A+DQo8L2Rp dj4NCjwvZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHls ZT0iZm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDssc2Fucy1zZXJpZiI+MS4mbmJzcDsgRW5k cG9pbnRzIE1BWSBpbXBsZW1lbnQgcnRjcC1ub24tbXV4ICh3ZSBjaGFuZ2UgdGhlIHNwZWMgYW5k IGNhbiBkZWxldGUgdGhlIHVnbHkgY29kZSk8L3NwYW4+PG86cD48L286cD48L3A+DQo8L2Rpdj4N CjwvZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0i Zm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDssc2Fucy1zZXJpZiI+Jm5ic3A7PC9zcGFuPjxv OnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7LHNhbnMt c2VyaWYiPjIuJm5ic3A7IEVuZHBvaW50cyBNVVNUIE5PVCBpbXBsZW1lbnQgcnRjcC1ub24tbXV4 ICh3ZSBjaGFuZ2UgdGhlIHNwZWMgYW5kIG11c3QgZGVsZXRlIHRoZSB1Z2x5IGNvZGUsIGFuZCBv dXIgbm9uLWNvbXBsaWFudCB1bnRpbCB3ZSBkbyk8L3NwYW4+PG86cD48L286cD48L3A+DQo8L2Rp dj4NCjwvZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHls ZT0iZm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDssc2Fucy1zZXJpZiI+Jm5ic3A7PC9zcGFu PjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7LHNh bnMtc2VyaWYiPjMuJm5ic3A7IEVuZHBvaW50cyBNVVNUIGltcGxlbWVudCBydGNwLW5vbi1tdXgg KHdlIGRvbid0IGNoYW5nZSB0aGUgc3BlYyBhbmQga2VlcCBhcm91bmQgdGhlIHVnbHkgY29kZSk8 L3NwYW4+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVv dDssc2Fucy1zZXJpZiI+Jm5ic3A7PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rp dj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQt ZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7LHNhbnMtc2VyaWYiPiZuYnNwOzwvc3Bhbj48bzpwPjwv bzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtBcmlhbCZxdW90OyxzYW5zLXNlcmlm Ij5NeSByZWFkaW5nIG9mIHRoZSBkaXNjdXNzaW9uIGlzIHRoYXQgbW9zdCBwZW9wbGUgd2FudCAj MSBvciAjMiwgYW5kIHZlcnkgZmV3IHBlb3BsZSBzdGlsbCB3YW50ICMzLiAmbmJzcDsgQmV0d2Vl biAjMSBhbmQgIzIsIHdoaWxlIHNvbWUgcGVvcGxlIHdvdWxkIHByZWZlciAjMiwgdGhlcmUgYXJl IGdvb2QgcmVhc29ucyB0byBqdXN0IGRvICMxLA0KIGFuZCBtb3N0IHNlZW0gdG8gcHJlZmVyICMx LiZuYnNwOyBGdXJ0aGVyLCBJJ20gZ3Vlc3NpbmcgdGhhdCBtb3N0IHBlb3BsZSB3aG8gd2FudGVk ICMyIGNvdWxkIGxpdmUgd2l0aCAjMS48L3NwYW4+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwv ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9u dC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDssc2Fucy1zZXJpZiI+Jm5ic3A7PC9zcGFuPjxvOnA+ PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7LHNhbnMtc2Vy aWYiPiZuYnNwOzwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0K PGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTomcXVv dDtBcmlhbCZxdW90OyxzYW5zLXNlcmlmIj5UTDtEUjogJm5ic3A7SSB0aGluayB3ZSBtYXkgaGF2 ZSByb3VnaCBjb25zZW5zdXMgb24gIzEsIHNheWluZyBlbmRwb2ludHMgTUFZIHJ0Y3Atbm9uLW11 eCAoYnV0IG1heSBjaG9vc2UgdG8gZGVsZXRlIGFsbCB0aGF0IHVnbHkgY29kZSBpbnN0ZWFkKS4g Jm5ic3A7PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2 Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O0Fy aWFsJnF1b3Q7LHNhbnMtc2VyaWYiPiZuYnNwOzwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2 Pg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxl PSJmb250LWZhbWlseTomcXVvdDtBcmlhbCZxdW90OyxzYW5zLXNlcmlmIj4mbmJzcDs8L3NwYW4+ PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDssc2Fu cy1zZXJpZiI+U28sIGlzIGV2ZXJ5b25lIGhhcHB5IHdpdGggIzE/PC9zcGFuPjxvOnA+PC9vOnA+ PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7LHNhbnMtc2VyaWYiPiZu YnNwOzwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdj4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtBcmlh bCZxdW90OyxzYW5zLXNlcmlmIj4mbmJzcDs8L3NwYW4+PG86cD48L286cD48L3A+DQo8L2Rpdj4N CjwvZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0i Zm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDssc2Fucy1zZXJpZiI+Jm5ic3A7PC9zcGFuPjxv OnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f PGJyPg0KcnRjd2ViIG1haWxpbmcgbGlzdDxicj4NCjxhIGhyZWY9Im1haWx0bzpydGN3ZWJAaWV0 Zi5vcmciPjxzcGFuIHN0eWxlPSJjb2xvcjpwdXJwbGUiPnJ0Y3dlYkBpZXRmLm9yZzwvc3Bhbj48 L2E+PGJyPg0KPGEgaHJlZj0iaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9y dGN3ZWIiPjxzcGFuIHN0eWxlPSJjb2xvcjpwdXJwbGUiPmh0dHBzOi8vd3d3LmlldGYub3JnL21h aWxtYW4vbGlzdGluZm8vcnRjd2ViPC9zcGFuPjwvYT48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0K PC9kaXY+DQo8L2Jsb2NrcXVvdGU+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwv YmxvY2txdW90ZT4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Jsb2NrcXVvdGU+DQo8L2Rpdj4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2JvZHk+DQo8 L2h0bWw+DQo= --_000_7594FB04B1934943A5C02806D1A2204B348EFCF9ESESSMB209erics_-- From nobody Tue Aug 11 00:38:48 2015 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 69F921A1B14 for ; Tue, 11 Aug 2015 00:38:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CZO_6QamTj1u for ; Tue, 11 Aug 2015 00:38:37 -0700 (PDT) Received: from mail-oi0-x229.google.com (mail-oi0-x229.google.com [IPv6:2607:f8b0:4003:c06::229]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3D5041A1B03 for ; Tue, 11 Aug 2015 00:38:37 -0700 (PDT) Received: by oio137 with SMTP id 137so98364662oio.0 for ; Tue, 11 Aug 2015 00:38:36 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type; bh=44atKUwdg6fuyodoEtkzfS/1L76tkqP8TZ00iXAq1fY=; b=GU5jrbZdnHnV68F8DalFKaTi34XZ9SE1zEJPSoZ3zv9BTNQWunwdxFDdBjzlpZ394K Z53rKpTxATJh8dvX0Tbk2rD9gysrl04uKuHPx6/yy7XfOb5ROdOVoUTPGrgLe3JJxZ9+ WlO2/19ANqz/0RPbuF/a11zcGLn3Y5eABTaOQVw8gZp5ps8ZS5SV/BKwMr3z/CeDxoaE jQhN5zSyZflb6QSMKJRlrqxviJCeyyb++c0FD/E2NUuo4HQ/0QRhHcJNlZMwswNGccaA 6k6nOxfsgsq8OpusnwlRNRQ+Md8jBzxhE+qpVz2WBaGeNbOwtfC8aTPjlUimcC6ZCdnw Buaw== MIME-Version: 1.0 X-Received: by 10.202.108.142 with SMTP id h136mr22547232oic.86.1439278716612; Tue, 11 Aug 2015 00:38:36 -0700 (PDT) Received: by 10.202.230.212 with HTTP; Tue, 11 Aug 2015 00:38:36 -0700 (PDT) In-Reply-To: <7594FB04B1934943A5C02806D1A2204B348EFCF9@ESESSMB209.ericsson.se> References: <8A69E109-3F93-4C61-95F2-375FF2103EAB@vidyo.com> <7594FB04B1934943A5C02806D1A2204B348EF447@ESESSMB209.ericsson.se> <58198CC2-984C-4236-8B90-D20BF050A241@vidyo.com> <7594FB04B1934943A5C02806D1A2204B348EFB2F@ESESSMB209.ericsson.se> <7594FB04B1934943A5C02806D1A2204B348EFCF9@ESESSMB209.ericsson.se> Date: Tue, 11 Aug 2015 15:38:36 +0800 Message-ID: From: Alexandre GOUAILLARD To: "rtcweb@ietf.org" Content-Type: multipart/alternative; boundary=001a1142da9ca2f5f0051d043078 Archived-At: Subject: Re: [rtcweb] Do we have consensus on not requiring rtcp-non-mux? X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 11 Aug 2015 07:38:40 -0000 --001a1142da9ca2f5f0051d043078 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable +1 for #1 On Tue, Aug 11, 2015 at 2:43 AM, Christer Holmberg < christer.holmberg@ericsson.com> wrote: > Hi, > > > > >Are you seriously advocating =E2=80=9CMAY implement, MUST NOT use=E2=80= =9D? How does > that make any sense at all? > > > > > >As I understood Peter=E2=80=99s original option 1, he was proposing to c= hange the > spec to allow two types of implementations: > > > > > >1. Endpoints that always offer mux, but are prepared for an answer that > declines to do it, at which point they fall back to non-mux. >(The curren= t > default behavior, and the behavior required by RFC 5761.) > > > > > >2. Endpoints that always offer mux, in a way such that there is no way t= o > fall back to non-mux. Naive interop with a non-rtcp-mux >endpoint, or wi= th > an endpoint that doesn=E2=80=99t want to do mux, will fail. (The current > rtcpMuxPolicy:"require" behavior.) > > > > > >If you say that no endpoint can ever do fallback to non-MUX, I don=E2=80= =99t see > what the point is. You=E2=80=99re instead advocating for Peter=E2=80=99s= >option 2. > > > > Fair enough, I hear what you=E2=80=99re saying. > > > > So, if we want to allow fallback to non-MUX, then I DO agree with you tha= t > we need a way for an entity to indicate that it also supports non-mux. > > > > >As I mentioned earlier in this thread, one solution to my problem =E2=80= =94 which > I don=E2=80=99t like this because it=E2=80=99s mixing up features which I= MO >should be > orthogonal, but I would be okay with =E2=80=94 would be to say something = like > =E2=80=9Coffers that support fallback to non-RTCP-mux >MUST include separ= ate ICE > candidates for RTCP, i.e. on component 2; offers that do not support such > fallback MUST NOT include >such candidates.=E2=80=9D > > > > That would be an option =E2=80=93 OR you include RTP and RTCP candidates = with > identical values. > > > > >The only difficulty with this solution is that it can be ambiguous when > trickle ICE is being used, since an offer might not include any >candidat= es > at all. > > > > and explain how it would work> :) > > > > Regards, > > > > Christer > > > > > > > > > > > > On Aug 10, 2015, at 2:02 PM, Christer Holmberg < > christer.holmberg@ericsson.com> wrote: > > > > Hi, > > > > >The whole point of supporting non-MUX mode is to allow answerers to > choose not to insert the SDP attribute. > > > > From a protocol perspective, yes. But, if we say that a WebRTC entity MUS= T > support/use rtcp-mux, then it means that it MUST include the attribute = =E2=80=93 > EVEN if the protocol allows it not to. > > > > >With option 1, the idea is that some endpoints will offer MUX, but > support fallback to non-MUX if the peer chooses not to do it. > > > > My understanding of option 1 is that some endpoints will **ONLY** > implement MUX, and will NOT fallback to non-MUX if the peer (a non-WebRTC > entity) chooses not to do it. > > > > >Some other endpoints will require that MUX be supported, and if a peer > doesn=E2=80=99t understand this then things will fail in interesting >way= s. > > > > Well, the endpoint that wants MUX will have to terminate the call. > > > > >If I=E2=80=99m (say) a gateway that would rather do non-MUX (to keep my = life > easier when gatewaying to legacy equipment), but is willing to >do MUX if > necessary, I need to know which sort of endpoint I=E2=80=99m talking to. > > > > My understanding of #1 is that there is no such things as =E2=80=9Cwould = rather do > non-MUX=E2=80=9D. As a WebRTC gateway, you would always do MUX (at least = towards > the WebRTC endpoints). > > > > >However, both types of endpoints will have inserted the attribute in > their offer. > > > > And, as a WebRTC endpoint, you will always insert the attribute in the > answer. > > > > >If you require that all entities MUST always insert the SDP attribute in > both offers *and answers*, then you=E2=80=99re choosing option 2. (A >sta= ndard that > says =E2=80=9Cyou MAY have code that implements this mode, but you MUST N= OT ever > use it=E2=80=9D is pretty pointless.) > > > > Regarding #2, endpoints can implement whatever they want. The point is > that they would never **USE** non-MUX. > > > > Regards, > > > > Christer > > > > On Aug 10, 2015, at 11:39 AM, Christer Holmberg < > christer.holmberg@ericsson.com> wrote: > > > > Hi Jonathan, > > Why can't we simply say that entities MUST insert the SDP attribute in > offers and answers? > > Regards, > > Christer > > Sent from my Windows Phone > ------------------------------ > > *From: *Jonathan Lennox > *Sent: *=E2=80=8E10/=E2=80=8E08/=E2=80=8E2015 17:46 > *To: *Google-Peter Thatcher > *Cc: *rtcweb@ietf.org > *Subject: *Re: [rtcweb] Do we have consensus on not requiring > rtcp-non-mux? > > #1 seems best to me, but there needs to be some well-specified way for JS > applications and offer/answer peers to discover/understand whether > rtcp-non-mux is indeed supported. Otherwise there=E2=80=99s no practical > difference between #1 and #2. > > > > > On Aug 7, 2015, at 5:39 PM, Peter Thatcher wrote: > > > > After lots of discussion, it appears we have three options: > > > > 1. Endpoints MAY implement rtcp-non-mux (we change the spec and can > delete the ugly code) > > > > 2. Endpoints MUST NOT implement rtcp-non-mux (we change the spec and mus= t > delete the ugly code, and our non-compliant until we do) > > > > 3. Endpoints MUST implement rtcp-non-mux (we don't change the spec and > keep around the ugly code) > > > > > > My reading of the discussion is that most people want #1 or #2, and very > few people still want #3. Between #1 and #2, while some people would > prefer #2, there are good reasons to just do #1, and most seem to prefer > #1. Further, I'm guessing that most people who wanted #2 could live with > #1. > > > > > > TL;DR: I think we may have rough consensus on #1, saying endpoints MAY > rtcp-non-mux (but may choose to delete all that ugly code instead). > > > > > > So, is everyone happy with #1? > > > > > > > > _______________________________________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/listinfo/rtcweb > > > > _______________________________________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/listinfo/rtcweb > > --=20 Alex. Gouaillard, PhD, PhD, MBA ---------------------------------------------------------------------------= --------- CTO - Temasys Communications, S'pore / Mountain View President - CoSMo Software, Cambridge, MA ---------------------------------------------------------------------------= --------- sg.linkedin.com/agouaillard - --001a1142da9ca2f5f0051d043078 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
+1 for #1

On Tue, Aug 11, 2015 at 2:43 AM, Christer Holmberg <christer.holmberg@ericsson.com> wrote:

Hi,

=C2=A0

>Are you seriously advocating =E2=80=9CMAY implem= ent, MUST NOT use=E2=80=9D?=C2=A0 How does that make any sense at all?

>=C2=A0

>As I understood Peter=E2=80=99s original option = 1, he was proposing to change the spec to allow two types of implementation= s:

>=C2=A0

>1. Endpoints that always offer mux, but are prep= ared for an answer that declines to do it, at which point they fall back to= non-mux. >(The current default behavior, and the behavior required by R= FC 5761.)

>=C2=A0

>2. Endpoints that always offer mux, in a way suc= h that there is no way to fall back to non-mux.=C2=A0 Naive interop with a = non-rtcp-mux >endpoint, or with an endpoint that doesn=E2=80=99t want to= do mux, will fail. (The current rtcpMuxPolicy:"require" behavior.)

>=C2=A0

>If you say that no endpoint can ever do fallback= to non-MUX, I don=E2=80=99t see what the point is.=C2=A0 You=E2=80=99re in= stead advocating for Peter=E2=80=99s >option 2.

=C2=A0

Fair enough, I hear what you=E2=80=99re sayin= g.

=C2=A0

So, if we want to allow fallback to non-MUX, then I = DO agree with you that we need a way for an entity to indicate that it also= supports non-mux.

=C2=A0

>As I mentioned earlier in this thread, one solut= ion to my problem =E2=80=94 which I don=E2=80=99t like this because it=E2= =80=99s mixing up features which IMO >should be orthogonal, but I would = be okay with =E2=80=94 would be to say something like =E2=80=9Coffers that = support fallback to non-RTCP-mux >MUST include separate ICE candidates for RTCP= , i.e. on component 2; offers that do not support such fallback MUST NOT in= clude >such candidates.=E2=80=9D

=C2=A0

That would be an option =E2=80=93 OR you inc= lude RTP and RTCP candidates with identical values.

=C2=A0

>The only difficulty with this solution is that i= t can be ambiguous when trickle ICE is being used, since an offer might not= include any >candidates at all.

=C2=A0

<This is the place where Emil will reply,= saying that he sees no issue, and explain how it would work> :)<= u>

=C2=A0

Regards,

=C2=A0

Christer

=C2=A0

=C2=A0

=C2=A0

=C2=A0

=C2=A0

On Aug 10, 2015, at 2:02 PM, Christer Holmberg <<= a href=3D"mailto:christer.holmberg@ericsson.com" target=3D"_blank">christer= .holmberg@ericsson.com> wrote:

=C2=A0

Hi,

=C2=A0

>The whole point of supporting non-MUX mode is to= allow answerers to choose not to insert the SDP attribute.

=C2=A0

From a protocol perspective, yes. But, if we say th= at a WebRTC entity MUST support/use rtcp-mux, then it means that it MUST in= clude the attribute =E2=80=93 EVEN if the protocol allows it not to.

=C2=A0

>With option 1, the idea is that some endpoints w= ill offer MUX, but support fallback to non-MUX if the peer chooses not to d= o it.

=C2=A0

My understanding of option 1 is that some endpoints= will *ONLY* implement MUX, and will NOT fallback to non-MUX if the = peer (a non-WebRTC entity) chooses not to do it.

=C2=A0

>Some other endpoints will require that MUX be su= pported, and if a peer doesn=E2=80=99t understand this then things will fai= l in interesting >ways.

=C2=A0

Well, the endpoint that wants MUX will have to term= inate the call.

=C2=A0

>If I=E2=80=99m (say) a gateway that would rather= do non-MUX (to keep my life easier when gatewaying to legacy equipment), b= ut is willing to >do MUX if necessary, I need to know which sort of endp= oint I=E2=80=99m talking to.

=C2=A0

My understanding of #1 is that there is no such thi= ngs as =E2=80=9Cwould rather do non-MUX=E2=80=9D. As a WebRTC gateway, you = would always do MUX (at least towards the WebRTC endpoints).<= u>

=C2=A0

>However, both types of endpoints will have inser= ted the attribute in their offer.

=C2=A0

And, as a WebRTC endpoint, you will always insert t= he attribute in the answer.

=C2=A0

>If you require that all entities MUST always ins= ert the SDP attribute in both offers *and answers*, then you=E2=80=99re cho= osing option 2. (A >standard that says =E2=80=9Cyou MAY have code that i= mplements this mode, but you MUST NOT ever use it=E2=80=9D is pretty pointless.)

=C2=A0

Regarding #2, endpoints can implement whatever they= want. The point is that they would never *USE* non-MUX.

=C2=A0

Regards,

=C2=A0

Christer

=C2=A0

On Aug 10, 2015, at 11:39 AM, Christer Holmberg <= christer.holmberg@ericsson.com> wrote:<= u>

=C2=A0

Hi Jonathan,

Why can't we simply say that entities MUST insert the SDP attribute in = offers and answers?

Regards,

Christer

Sent from my Windows Phone

From:=C2=A0= = Jonathan Lennox
Sent:=C2=A0=E2=80=8E10/=E2=80=8E08/=E2=80=8E20= 15 17:46
To:=C2=A0Google-Peter Thatcher
Cc:=C2=A0rtcweb@ietf.org
Subject:=C2=A0Re: [rtcweb] Do we have consensu= s on not requiring rtcp-non-mux?

#1 seems best to me, but there needs to be some well= -specified way for JS applications and offer/answer peers to discover/under= stand whether rtcp-non-mux is indeed supported.=C2=A0 Otherwise there=E2=80= =99s no practical difference between #1 and #2.




On Aug 7, 2015, at 5:39 PM, Peter Thatcher <pthatcher@google.com> wrote:

=C2=A0

After lots of discussion, it appears we have three options:<= /u>

=C2=A0

1.=C2=A0 Endpoints MAY implement rtcp-non-mux (we change the spec and = can delete the ugly code)

=C2=A0

2.=C2=A0 Endpoints MUST NOT implement rtcp-non-mux (we change the spec= and must delete the ugly code, and our non-compliant until we do)

=C2=A0

3.=C2=A0 Endpoints MUST implement rtcp-non-mux (we don't change th= e spec and keep around the ugly code)

=C2=A0

=C2=A0

My reading of the discussion is that most people want #1 or #2, and ve= ry few people still want #3. =C2=A0 Between #1 and #2, while some people wo= uld prefer #2, there are good reasons to just do #1, and most seem to prefer #1.=C2=A0 Further, I'm guessing that most peop= le who wanted #2 could live with #1.

=C2=A0

=C2=A0

TL;DR: =C2=A0I think we may have rough consensus on #1, saying endpoin= ts MAY rtcp-non-mux (but may choose to delete all that ugly code instead). = =C2=A0

=C2=A0

=C2=A0

So, is everyone happy with #1?

=C2=A0

=C2=A0

=C2=A0

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

=C2=A0


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




--
Alex. Gouaillard, PhD, PhD, MBA--------------------------------------------------------------------------= ----------
CTO - Temasys Communications, S'pore / Mountain Vi= ew
President - CoSMo Software, Cambridge, MA
----------= --------------------------------------------------------------------------<= /div>

--001a1142da9ca2f5f0051d043078-- From nobody Tue Aug 11 02:32:54 2015 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BCEA51A21C4; Tue, 11 Aug 2015 02:32:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.511 X-Spam-Level: X-Spam-Status: No, score=-14.511 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wgMdqgMKRc_5; Tue, 11 Aug 2015 02:32:48 -0700 (PDT) Received: from rcdn-iport-9.cisco.com (rcdn-iport-9.cisco.com [173.37.86.80]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id ECF931A21C3; Tue, 11 Aug 2015 02:32:47 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1571; q=dns/txt; s=iport; t=1439285568; x=1440495168; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=pWCC7njxSYJjRLxJO7ciW3VlTzLdJOlUxG+wQdDuRmM=; b=VMp+nlhY2cILJe5XdYdy5bDh8KGWkoiDjLcAtwMOzHoOJ1cjv0ZzhL7u iPvpo+1BuOgmGbfZsfgbXrLF36Z/vt5r0dzzKAI2JEZJvZGNpwjVhHwSU 3/RtzAnJ3PtCQ0ADLrFT3Zh7yACrkZt+4bXWKEmNcg5Qi8GKKxNStHhn9 Q=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: A0AeAwB5wMlV/4wNJK1dgxtUaQa9UAmCB4V3AoE2OBQBAQEBAQEBgQqEIwEBAQQ6PwwEAgEIEQMBAgEeECERHQgCBAENBYgZAxINyTgNhUYBAQEBAQEBAQEBAQEBAQEBAQEBAQETBItRgk+COgcGhCYBBJUQAYUDhXqBbJJXhzMmgg8cFYE+cYFIgQQBAQE X-IronPort-AV: E=Sophos;i="5.15,652,1432598400"; d="scan'208";a="17549002" Received: from alln-core-7.cisco.com ([173.36.13.140]) by rcdn-iport-9.cisco.com with ESMTP; 11 Aug 2015 09:32:46 +0000 Received: from XCH-RCD-006.cisco.com (xch-rcd-006.cisco.com [173.37.102.16]) by alln-core-7.cisco.com (8.14.5/8.14.5) with ESMTP id t7B9WkVW001914 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Tue, 11 Aug 2015 09:32:46 GMT Received: from xch-rcd-006.cisco.com (173.37.102.16) by XCH-RCD-006.cisco.com (173.37.102.16) with Microsoft SMTP Server (TLS) id 15.0.1104.5; Tue, 11 Aug 2015 04:32:45 -0500 Received: from xhc-rcd-x12.cisco.com (173.37.183.86) by xch-rcd-006.cisco.com (173.37.102.16) with Microsoft SMTP Server (TLS) id 15.0.1104.5 via Frontend Transport; Tue, 11 Aug 2015 04:32:45 -0500 Received: from xmb-aln-x05.cisco.com ([169.254.11.9]) by xhc-rcd-x12.cisco.com ([173.37.183.86]) with mapi id 14.03.0248.002; Tue, 11 Aug 2015 04:32:45 -0500 From: "Ram Mohan R (rmohanr)" To: Barry Leiba , "rtcweb@ietf.org" Thread-Topic: Barry Leiba's No Objection on draft-ietf-rtcweb-stun-consent-freshness-15: (with COMMENT) Thread-Index: AQHQ1BitR6+6SgaXpkuHM+kmGQ+b0A== Date: Tue, 11 Aug 2015 09:32:45 +0000 Message-ID: References: <20150728123512.3082.72636.idtracker@ietfa.amsl.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.5.3.150624 x-originating-ip: [173.36.7.24] Content-Type: text/plain; charset="us-ascii" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Cc: "draft-ietf-rtcweb-stun-consent-freshness@ietf.org" , "rtcweb-chairs@ietf.org" , "draft-ietf-rtcweb-stun-consent-freshness.shepherd@ietf.org" , The IESG , "draft-ietf-rtcweb-stun-consent-freshness.ad@ietf.org" Subject: Re: [rtcweb] Barry Leiba's No Objection on draft-ietf-rtcweb-stun-consent-freshness-15: (with COMMENT) X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 11 Aug 2015 09:32:49 -0000 I have updated this comment to Consent draft - https://github.com/rmohanr/Consentfreshness-Barry/commit/c4a0eb2fb9b610cf71 ee9c6706409308b4d2dd58 Ram -----Original Message----- From: Martin Thomson Date: Tuesday, 28 July 2015 6:52 pm To: Barry Leiba Cc: "draft-ietf-rtcweb-stun-consent-freshness@ietf.org" , "rtcweb-chairs@ietf.org" , "draft-ietf-rtcweb-stun-consent-freshness.shepherd@ietf.org" , "rtcweb@ietf.org" , The IESG , "draft-ietf-rtcweb-stun-consent-freshness.ad@ietf.org" Subject: Re: Barry Leiba's No Objection on draft-ietf-rtcweb-stun-consent-freshness-15: (with COMMENT) >On 28 July 2015 at 15:07, Barry Leiba wrote: >> That's why I think the *other* MUSTs and SHOULDs are fine. But *this* >> one says "MUST use the procedure in this document", which doesn't seem >> right. (But, as I said, a minor comment.) > >I don't think that we lose anything by changing the "MUST be" to "is": > >> A full ICE implementation obtains consent to send using ICE. After >> ICE concludes on a particular candidate pair and whenever the >> endpoint sends application data on that pair consent is >> maintained following the procedure described in this document. > >Axiomatic wins against prescriptive generally for me. From nobody Tue Aug 11 02:48:18 2015 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 89FFC1A6EF0; Tue, 11 Aug 2015 02:48:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.511 X-Spam-Level: X-Spam-Status: No, score=-14.511 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MfTX5L8YjSkv; Tue, 11 Aug 2015 02:48:14 -0700 (PDT) Received: from rcdn-iport-4.cisco.com (rcdn-iport-4.cisco.com [173.37.86.75]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 10A6C1A6EEC; Tue, 11 Aug 2015 02:48:14 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=7187; q=dns/txt; s=iport; t=1439286494; x=1440496094; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=oeXbO/wyssJzQ1TvPx5MKIIABltim3228Vc6XmKRLdU=; b=ZZwtDzlZlGAxNVuFmsLdvlyc+lFe7+9GQhg/sN8cY3pHkfFTV54o+b/D 6IEmp19cXtUBHd8RFM5XbSAa/ADsaSnfrIwK9U0N1JNKix7oxe+qkbXjw vsEWJR0RptbGEY709XUtJoRI3ORQpZR9aYbyoGY87zCi6vKFnsVytEIBl Q=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: A0AeAwAyxMlV/4wNJK1dgxtUaQa9UAmCB4UtSgKBNjgUAQEBAQEBAYEKhCMBAQEEOj8MBAIBCBEBAgECHxAyFwYIAgQBDQWILg3OfgEBAQEBAQEBAQEBAQEBAQEBAQEBARMEi1GEJhEBUQIFBoQmBYccjXQBhQOHZoFJhCaQNYNmJoJAgT5xAYEEAgMCAhcHHIEEAQEB X-IronPort-AV: E=Sophos;i="5.15,652,1432598400"; d="scan'208";a="19503375" Received: from alln-core-7.cisco.com ([173.36.13.140]) by rcdn-iport-4.cisco.com with ESMTP; 11 Aug 2015 09:48:13 +0000 Received: from XCH-RCD-003.cisco.com (xch-rcd-003.cisco.com [173.37.102.13]) by alln-core-7.cisco.com (8.14.5/8.14.5) with ESMTP id t7B9mC6m011199 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Tue, 11 Aug 2015 09:48:12 GMT Received: from xch-rcd-003.cisco.com (173.37.102.13) by XCH-RCD-003.cisco.com (173.37.102.13) with Microsoft SMTP Server (TLS) id 15.0.1104.5; Tue, 11 Aug 2015 04:48:11 -0500 Received: from xhc-aln-x12.cisco.com (173.36.12.86) by xch-rcd-003.cisco.com (173.37.102.13) with Microsoft SMTP Server (TLS) id 15.0.1104.5 via Frontend Transport; Tue, 11 Aug 2015 04:48:11 -0500 Received: from xmb-aln-x05.cisco.com ([169.254.11.9]) by xhc-aln-x12.cisco.com ([173.36.12.86]) with mapi id 14.03.0248.002; Tue, 11 Aug 2015 04:48:11 -0500 From: "Ram Mohan R (rmohanr)" To: Ben Campbell , The IESG Thread-Topic: Ben Campbell's Yes on draft-ietf-rtcweb-stun-consent-freshness-15: (with COMMENT) Thread-Index: AQHQ1BrVr8kbfba+WkijIl0HeusmsA== Date: Tue, 11 Aug 2015 09:48:10 +0000 Message-ID: References: <20150804220823.6096.97126.idtracker@ietfa.amsl.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.5.3.150624 x-originating-ip: [173.36.7.24] Content-Type: text/plain; charset="us-ascii" Content-ID: <6DC563B7690FE547AABB2F99667467DE@emea.cisco.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Cc: "draft-ietf-rtcweb-stun-consent-freshness.ad@ietf.org" , "rtcweb@ietf.org" , "draft-ietf-rtcweb-stun-consent-freshness@ietf.org" , "rtcweb-chairs@ietf.org" , "draft-ietf-rtcweb-stun-consent-freshness.shepherd@ietf.org" Subject: Re: [rtcweb] Ben Campbell's Yes on draft-ietf-rtcweb-stun-consent-freshness-15: (with COMMENT) X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 11 Aug 2015 09:48:16 -0000 Hi Ben, Here is the diffs with your comments updated. https://github.com/Draft-Mafia/Consentfreshness/compare/ConsentDraftBenComm ents Once other comments from Stephen are resolved, I will send a consolidated diff. Ram -----Original Message----- From: Cisco Employee Date: Thursday, 6 August 2015 10:26 am To: Ben Campbell , The IESG Cc: "draft-ietf-rtcweb-stun-consent-freshness@ietf.org" , "rtcweb-chairs@ietf.org" , "draft-ietf-rtcweb-stun-consent-freshness.shepherd@ietf.org" , "draft-ietf-rtcweb-stun-consent-freshness.ad@ietf.org" , "rtcweb@ietf.org" Subject: Re: Ben Campbell's Yes on draft-ietf-rtcweb-stun-consent-freshness-15: (with COMMENT) >Hi Ben, > >Thanks for your feedback. Please see my responses inline > >-----Original Message----- >From: Ben Campbell >Date: Wednesday, 5 August 2015 3:38 am >To: The IESG >Cc: "draft-ietf-rtcweb-stun-consent-freshness@ietf.org" >, >"rtcweb-chairs@ietf.org" , >"draft-ietf-rtcweb-stun-consent-freshness.shepherd@ietf.org" >, >"draft-ietf-rtcweb-stun-consent-freshness.ad@ietf.org" >, "rtcweb@ietf.org" > >Subject: Ben Campbell's Yes on >draft-ietf-rtcweb-stun-consent-freshness-15: (with COMMENT) > >>Ben Campbell has entered the following ballot position for >>draft-ietf-rtcweb-stun-consent-freshness-15: Yes >> >>When responding, please keep the subject line intact and reply to all >>email addresses included in the To and CC lines. (Feel free to cut this >>introductory paragraph, however.) >> >> >>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-rtcweb-stun-consent-freshness >>/ >> >> >> >>---------------------------------------------------------------------- >>COMMENT: >>---------------------------------------------------------------------- >> >>This looks good overall. I have a few minor comments: >> >>-- General:=20 >> >>After re-reading this, and the relevant parts of >>rtcweb-security-architecture, I think a novice reader might find the >>meaning of "consent" a bit vague, especially in terms of how it might >>differ from "reachability". Can you offer an example of when an otherwise >>reachable peer might choose to withdraw consent? > >Reachability of a endpoint does not indicate that it is willing to receive >traffic.=20 >So if a peer has to continue sending data it must do consent. >If the peer does not intend to send data, it can stop consent and later >resume Whenever it wants to send data again. >An example would be "As with a teacher in a classroom who grants consent >to each student to speak words, consent is granted to each sender to >transmit packets." > > > >> >>-- section 1, first paragraph: >> >>I think readers are going to stumble over why we think a device that >>plans to attack a peer is going to worry about consent. This makes more >>sense in section 2. It might be helpful to move (or copy) the bit about >>"... deployments of WebRTC..." and "... malicious javascript" forward to >>the intro. > >Sure. I will move the text related to malicious javascript to first para >of intro.=20 > >OLD: >To prevent attacks on peers, endpoints have to ensure the remote peer > is willing to receive traffic. This is performed both when the > session is first established to the remote peer using Interactive > Connectivity Establishment ICE [RFC5245] connectivity checks, and > periodically for the duration of the session using the procedures > defined in this document. > > >NEW:=20 >To prevent attacks on peers, endpoints have to ensure the remote peer > is willing to receive traffic. Verification of peer consent before >sending traffic is necessary in deployments like WebRTC to ensure that >a malicious JavaScript cannot use the browser as a platform for launching >attacks. This is performed both when the session is first established to >the > remote peer using Interactive Connectivity Establishment ICE [RFC5245] >connectivity checks, and periodically for the duration of the session >using the procedures defined in this document. > > > >> >>- 4, 3rd paragraph: >> >>Should the reader infer that the receipt of a package that is strongly >>assured to have come from a party implies consent from that party? If so, >>it might be worth an explicit mention. > >No. Even in that case consent is needed. > > > >> >>-- 5.1, first paragraph: >> >>The normative MUST feels wrong here, (and is probably redundant with >>other normative language further down in the section.) For example, could >>a sender just choose to stop sending? > >Sender can stop sending data on that pair at anytime. If >the sender continues to send data, it must do consent other wise consent >will expire. That is the reason the document says that consent >must be maintained when application sends data. The other usage of >normative statements are for timer selection which is needed >to ensure that every implementation derives the timers based >on the suggested range. > > >> >>-- 5.1, 5th paragraph: >> >>>From the next paragraph, I infer that you mean consent expires after 30 >>seconds when you have been sending binding request every few seconds, not >>30 seconds after sending any particular binding request. If that's >>correct it might be helpful to add a few words to that effect. > >The next para discusses how the endpoint has to pace the bind requests for >consent.=20 >It mentions that the interval is between 4 - 6. > > > > >> >>-- 5.1, 6th paragraph: >> >>Does the "MUST NOT" refer to the general interval between checks prior to >>randomization, or to the specific interval between a pair of checks after >>Randomization? > >It is between a pair of checks after randomization. So essentially each >request should be paced between 4 - 6 seconds after initial consent >obtained (via ICE validation) > > >> >>Nits: >> >>-- 2, 2nd paragraph: "verify peer's consent" >> >>Missing article (or "verify peer consent") >> >>-- 5.1, paragraph 3: >> >>s/sending an stun binding/sending a stun binding >> >>-- 5.1, 7th paragraph: "Each STUN binding request for consent MUST use a >>new STUN transaction >> identifier for every consent binding request..." >> >>That's sort of redundant. I suggest something to the effect of "each >>consent binding request MUST use a new stun transaction identifier. " > >Thanks. Will address all the nits above. > >Regards, >Ram > > >> >> > From nobody Tue Aug 11 06:32:38 2015 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 479BA1A8A93 for ; Tue, 11 Aug 2015 06:32:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.979 X-Spam-Level: X-Spam-Status: No, score=-1.979 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, 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 XJzF1oXyqTCW for ; Tue, 11 Aug 2015 06:32:34 -0700 (PDT) Received: from mail-oi0-f54.google.com (mail-oi0-f54.google.com [209.85.218.54]) (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 8F5FF1A8A87 for ; Tue, 11 Aug 2015 06:32:32 -0700 (PDT) Received: by oiev193 with SMTP id v193so74301691oie.3 for ; Tue, 11 Aug 2015 06:32:32 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type:content-transfer-encoding; bh=oBog2TBuvP1PhJ8odLGCSgBFb7+sT5hGtDUVYq1FoOU=; b=hwIUorG0pYCV5yMtaqL8LOcHtG91Sxruu79ASvQlSDkqJBnbHN7PEoVYq+levJfVN2 HIW750ZxtsH2ZDlWV7UvvTyBc7eQ5dv1yeFz+9AY+w6M6+hr2nRp3+kvrzWvKaq2tnlE OvqvUkOnTgA/u0UkP+1wsWutz3vjS+TKwvamreQzBhq/cSx4wodFqeCCklICoEWRLQwO qQV11Rpp995SqjyLxKMTbFLzAIhw1dR/cZFzhsmAnSHie0zIiLxGV17wk+JS1USasN0S vzTYcTGop4vaTdUtmzrpqfuTxY0Www7ItqD1sVUxB9g4lf0+Zymvc4TKCMJV0ze7OSZW jwPA== X-Gm-Message-State: ALoCoQlBy6TbwGxxtc+y6SehKVfwXpZto5KLkuzRPhHxOkfutUOggDTXWs8K3XumZm9Y1CELlYgL X-Received: by 10.202.55.7 with SMTP id e7mr23362295oia.56.1439299951951; Tue, 11 Aug 2015 06:32:31 -0700 (PDT) Received: from mail-ob0-f178.google.com (mail-ob0-f178.google.com. [209.85.214.178]) by smtp.gmail.com with ESMTPSA id ix8sm1644057obc.7.2015.08.11.06.32.30 for (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 11 Aug 2015 06:32:31 -0700 (PDT) Received: by obbhe7 with SMTP id he7so51857756obb.0 for ; Tue, 11 Aug 2015 06:32:30 -0700 (PDT) X-Received: by 10.182.215.226 with SMTP id ol2mr24296811obc.56.1439299950383; Tue, 11 Aug 2015 06:32:30 -0700 (PDT) MIME-Version: 1.0 Received: by 10.76.83.167 with HTTP; Tue, 11 Aug 2015 06:32:10 -0700 (PDT) In-Reply-To: <3F10035A-70A4-46AE-AB44-4499541AC7C6@cisco.com> References: <20150805130607.20844.70680.idtracker@ietfa.amsl.com> <55C24293.5000603@cs.tcd.ie> <55C24C09.8020404@goodadvice.pages.de> <55C256C8.80606@jive.com> <3F10035A-70A4-46AE-AB44-4499541AC7C6@cisco.com> From: Emil Ivov Date: Tue, 11 Aug 2015 08:32:10 -0500 Message-ID: To: "Pal Martinsen (palmarti)" Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Archived-At: Cc: Jonathan Lennox , "rtcweb@ietf.org" , "tram@ietf.org" , mmusic Subject: Re: [rtcweb] [tram] TURN permissions for private ips X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 11 Aug 2015 13:32:36 -0000 Hey Pal, On Fri, Aug 7, 2015 at 2:47 AM, Pal Martinsen (palmarti) wrote: > > On 07 Aug 2015, at 02:11, Emil Ivov wrote: > > On Thu, Aug 6, 2015 at 5:01 PM, Justin Uberti wrote: > > > > On Thu, Aug 6, 2015 at 1:51 PM, Martin Thomson > wrote: > > > On 6 August 2015 at 13:08, Justin Uberti wrote: > > I think that we should be able to avoid pairing candidates obtained from > application TURN servers with RFC 1918 addresses. The app/browser > clearly > knows which is which. > > > I'm concerned here that if we let the application choose, we lose the > defence we were looking to gain. I think that perhaps 1918 pairing > could be restricted to TURN servers that are configured/discovered, > "proxy"-style. > > > > Sorry, that is what I was trying to say. The browser knows which turn > servers are "proxies" vs app servers, and can apply the 1918 filtering on > the pairings from the candidates from the app TURN server. > > > I don't think Jonathan's concerns only apply to proxies though. You > can just as well have apps developed for specific networks and there > is no reason to prevent those from working. > > Agree with your enumeration of concerns as well. Also #5, they consume > bandwidth (at least from client to TURN server), which affects maximum ch= eck > rate in some cases. > > > Why can't we address this by TURN servers simply refusing to create > permissions for candidates they know they won't be able to reach? > > How do you reliably and simply do that without a connectivity check? There are a few ways a TURN server could be smart about this (e.g. checking the routing table for local interfaces for example, or looking into ARP tables) but ultimately they should allow for this to be configured. > If the main concern is information leakage, isn=E2=80=99t that up to the = client to > decide what it want to reveal to the TURN server and the remote client? I don't know that the main concern is leakage (see my previous mail). I don't see how an application can be worried that the TURN server it chose is going to find out that there's one of three NATed ranged behind a certain IP. The TURN server had a 1 in 4 chance of guessing that even without the app. That said, I am not opposed to giving JavaScript apps a way to explicitly signal the stack not to pair certain addresses with TURN. I just don't want the stack to assume this. Emil > Guess what I am saying is that I think it is a good thing to have a =E2= =80=9Cthick=E2=80=9D > client and relatively simple network components. > > .-. > P=C3=A5l-Erik > > > Emil > > -- > https://jitsi.org > > _______________________________________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/listinfo/rtcweb > > --=20 https://jitsi.org From nobody Tue Aug 11 07:31:39 2015 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A412A1A8BB3; Tue, 11 Aug 2015 07:31:37 -0700 (PDT) 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 XWHtsrvICst6; Tue, 11 Aug 2015 07:31:34 -0700 (PDT) Received: from rcdn-iport-4.cisco.com (rcdn-iport-4.cisco.com [173.37.86.75]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 69C721A8AFB; Tue, 11 Aug 2015 07:31:28 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=39050; q=dns/txt; s=iport; t=1439303488; x=1440513088; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=atGMnIdWdF6QDj/HyhSIXUOSD4C0mk+mHcAJTdF/Oz4=; b=er7MkWE4uviTXFJRunosjioGLm9dxHNBmFqF/KSVsLhJwVsq+UEJxzzb ebJSLlu2XZKzE4q7nA5m4WDVLJKswyGxSVpubwFeykZjK3+RdkIAbgDdf gI7nwSdyLWpPvl1P1PKmNadRGH7sDiMRw+A7mMRoLAKMBq1eZZIViacyD Y=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: A0CUBQD3BcpV/4sNJK1dgk5NVGkGgx66PIF4hS1KAhyBGjkTAQEBAQEBAYEKhCMBAQEEIwpMEAIBBgIRBAEBCxYDBAMCAgIfERQJCAIEAQ0FCIgRAxINm1OdHZBNDYU9AQEBAQEBAQEBAQEBAQEBAQEBAQEBF4tRgk+BVxEBBhoWFwQGAQmCYC+BFAWHHI10AYUDhXqDNUaDYIMZiU+DTYNmJoIPHBWBPnEBgQ06gQQBAQE X-IronPort-AV: E=Sophos; i="5.15,653,1432598400"; d="scan'208,217"; a="19582531" Received: from alln-core-6.cisco.com ([173.36.13.139]) by rcdn-iport-4.cisco.com with ESMTP; 11 Aug 2015 14:31:27 +0000 Received: from XCH-ALN-012.cisco.com (xch-aln-012.cisco.com [173.36.7.22]) by alln-core-6.cisco.com (8.14.5/8.14.5) with ESMTP id t7BEVRsF012852 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Tue, 11 Aug 2015 14:31:27 GMT Received: from xch-aln-012.cisco.com (173.36.7.22) by XCH-ALN-012.cisco.com (173.36.7.22) with Microsoft SMTP Server (TLS) id 15.0.1104.5; Tue, 11 Aug 2015 09:31:25 -0500 Received: from xhc-aln-x14.cisco.com (173.36.12.88) by xch-aln-012.cisco.com (173.36.7.22) with Microsoft SMTP Server (TLS) id 15.0.1104.5 via Frontend Transport; Tue, 11 Aug 2015 09:31:25 -0500 Received: from xmb-rcd-x10.cisco.com ([169.254.15.53]) by xhc-aln-x14.cisco.com ([173.36.12.88]) with mapi id 14.03.0248.002; Tue, 11 Aug 2015 09:31:25 -0500 From: "Tirumaleswar Reddy (tireddy)" To: Muthu Arul Mozhi Perumal , Stephen Farrell Thread-Topic: Stephen Farrell's Discuss on draft-ietf-rtcweb-stun-consent-freshness-15: (with DISCUSS and COMMENT) Thread-Index: AQHQz896cUUM6/+DvkK800ZtmpZrm53+vMUAgAgihqA= Date: Tue, 11 Aug 2015 14:31:25 +0000 Message-ID: <913383AAA69FF945B8F946018B75898A478BCD7E@xmb-rcd-x10.cisco.com> References: <20150805223837.26225.49192.idtracker@ietfa.amsl.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [173.36.7.24] Content-Type: multipart/alternative; boundary="_000_913383AAA69FF945B8F946018B75898A478BCD7Exmbrcdx10ciscoc_" MIME-Version: 1.0 Archived-At: Cc: "draft-ietf-rtcweb-stun-consent-freshness@ietf.org" , "rtcweb-chairs@ietf.org" , "draft-ietf-rtcweb-stun-consent-freshness.shepherd@ietf.org" , "rtcweb@ietf.org" , The IESG , "draft-ietf-rtcweb-stun-consent-freshness.ad@ietf.org" Subject: Re: [rtcweb] Stephen Farrell's Discuss on draft-ietf-rtcweb-stun-consent-freshness-15: (with DISCUSS and COMMENT) X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 11 Aug 2015 14:31:38 -0000 --_000_913383AAA69FF945B8F946018B75898A478BCD7Exmbrcdx10ciscoc_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SGkgU3RlcGhlbiwNCg0KVXBkYXRlZCBkcmFmdCB0byBhZGRyZXNzIHlvdXIgY29tbWVudHMgaHR0 cHM6Ly9naXRodWIuY29tL0RyYWZ0LU1hZmlhL0NvbnNlbnRmcmVzaG5lc3MvY29tcGFyZS9tYXN0 ZXIuLi5ybW9oYW5yLVN0ZXBoZW5Db25zZW50RnJlc2huZXNzLCBQbGVhc2UgaGF2ZSBhIGxvb2su DQpBbHNvIHNlZSBpbmxpbmUgW1RSXQ0KDQpGcm9tOiBNdXRodSBBcnVsIE1vemhpIFBlcnVtYWwg W21haWx0bzptdXRodS5hcnVsQGdtYWlsLmNvbV0NClNlbnQ6IFRodXJzZGF5LCBBdWd1c3QgMDYs IDIwMTUgMTA6MjcgQU0NClRvOiBTdGVwaGVuIEZhcnJlbGwNCkNjOiBUaGUgSUVTRzsgZHJhZnQt aWV0Zi1ydGN3ZWItc3R1bi1jb25zZW50LWZyZXNobmVzc0BpZXRmLm9yZzsgcnRjd2ViLWNoYWly c0BpZXRmLm9yZzsgZHJhZnQtaWV0Zi1ydGN3ZWItc3R1bi1jb25zZW50LWZyZXNobmVzcy5zaGVw aGVyZEBpZXRmLm9yZzsgZHJhZnQtaWV0Zi1ydGN3ZWItc3R1bi1jb25zZW50LWZyZXNobmVzcy5h ZEBpZXRmLm9yZzsgcnRjd2ViQGlldGYub3JnDQpTdWJqZWN0OiBSZTogU3RlcGhlbiBGYXJyZWxs J3MgRGlzY3VzcyBvbiBkcmFmdC1pZXRmLXJ0Y3dlYi1zdHVuLWNvbnNlbnQtZnJlc2huZXNzLTE1 OiAod2l0aCBESVNDVVNTIGFuZCBDT01NRU5UKQ0KDQpIaSBTdGVwaGVuLA0KDQpPbiBUaHUsIEF1 ZyA2LCAyMDE1IGF0IDQ6MDggQU0sIFN0ZXBoZW4gRmFycmVsbCA8c3RlcGhlbi5mYXJyZWxsQGNz LnRjZC5pZTxtYWlsdG86c3RlcGhlbi5mYXJyZWxsQGNzLnRjZC5pZT4+IHdyb3RlOg0KU3RlcGhl biBGYXJyZWxsIGhhcyBlbnRlcmVkIHRoZSBmb2xsb3dpbmcgYmFsbG90IHBvc2l0aW9uIGZvcg0K ZHJhZnQtaWV0Zi1ydGN3ZWItc3R1bi1jb25zZW50LWZyZXNobmVzcy0xNTogRGlzY3Vzcw0KDQpX aGVuIHJlc3BvbmRpbmcsIHBsZWFzZSBrZWVwIHRoZSBzdWJqZWN0IGxpbmUgaW50YWN0IGFuZCBy ZXBseSB0byBhbGwNCmVtYWlsIGFkZHJlc3NlcyBpbmNsdWRlZCBpbiB0aGUgVG8gYW5kIENDIGxp bmVzLiAoRmVlbCBmcmVlIHRvIGN1dCB0aGlzDQppbnRyb2R1Y3RvcnkgcGFyYWdyYXBoLCBob3dl dmVyLikNCg0KDQpQbGVhc2UgcmVmZXIgdG8gaHR0cHM6Ly93d3cuaWV0Zi5vcmcvaWVzZy9zdGF0 ZW1lbnQvZGlzY3Vzcy1jcml0ZXJpYS5odG1sDQpmb3IgbW9yZSBpbmZvcm1hdGlvbiBhYm91dCBJ RVNHIERJU0NVU1MgYW5kIENPTU1FTlQgcG9zaXRpb25zLg0KDQoNClRoZSBkb2N1bWVudCwgYWxv bmcgd2l0aCBvdGhlciBiYWxsb3QgcG9zaXRpb25zLCBjYW4gYmUgZm91bmQgaGVyZToNCmh0dHBz Oi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcvZG9jL2RyYWZ0LWlldGYtcnRjd2ViLXN0dW4tY29uc2Vu dC1mcmVzaG5lc3MvDQoNCg0KDQotLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tDQpESVNDVVNTOg0KLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LQ0KDQoNCg0KQXBvbG9naWVzIHRoYXQgdGhlc2UgZGlzY3VzcyBwb2ludHMgYXJlIG1heWJlIGFz a2luZw0KZmFpcmx5IGZ1bmRhbWVudGFsIHF1ZXN0aW9ucy4gIFRoYXQgY291bGQgYmUgdGhhdCB0 aGlzDQppcyByZWFsbHkgdGhlIGZpcnN0IG9mIHRoZSBuZXcgc2VjdXJpdHkgdGhpbmdzIHJlcXVp cmVkDQpieSBydGN3ZWIgdG8gZ2V0IHRvIHRoZSBJRVNHLiAgT3IgbWF5YmUgSSdtIG1pc3JlYWRp bmcNCnN0dWZmIGhlcmUsIGlmIHNvLCBzb3JyeTstKQ0KDQooMSkgV2h5IGNhbGwgdGhpcyAiY29u c2VudD8iIFRoYXQgdGVybSBpcyAoYWIpdXNlZCBpbg0KbWFueSB3YXlzIG9uIHRoZSB3ZWIsIGFu ZCBhZGRpbmcgYW5vdGhlciB2YXJpYXRpb24NCndpdGhvdXQgYSBkZWZpbml0aW9uIHRoYXQgZGlz dGluZ3Vpc2hlcyB0aGlzIGZyb20gImNsaWNrDQpvayB0byBteSAyMDAgcGFnZSBhbnRpLXByaXZh Y3kgcG9saWN5IiBvciAicmVtZW1iZXIgdGhhdA0KZXhhbXBsZS5jb208aHR0cDovL2V4YW1wbGUu Y29tPiBpcyBhbGxvd2VkIHVzZSBteSBjYW1lcmEvbWljIiBzZWVtcyBsaWtlIGENCnRlcnJpYmxl IGlkZWEuIEkgYWxzbyBkb24ndCBzZWUgaG93IHRoaXMgY2FuIGV2ZXIgYmUNCnNvbWV0aGluZyB0 byB3aGljaCBhIG5vcm1hbCBwZXJzb24gY2FuICJjb25zZW50IiAoaS5lLg0KY29uc2Npb3VzbHkg YWdyZWUgd2hpbGUgZnVsbHkgdW5kZXJzdGFuZGluZykgc28gdGhlIHRlcm0NCmlzIElNTyB2ZXJ5 IG1pc2xlYWRpbmcsIGFuZCB3aWxsIEkgZmVhciBiZSB1c2VkIHRvDQptaXNsZWFkIGZ1cnRoZXIu ICAoU2VlIGFsc28gc29tZSBvZiB0aGUgY29tbWVudHMgYmVsb3cgLQ0KSSBkbyBub3QgdGhpbmsg d2Ugb3VnaHQgYmUgYXMgZmFzdCBhbmQgbG9vc2Ugd2l0aCB0aGlzDQphbGVhZHkgdGVycmlibHkg YmFkbHkgdXNlZCB0ZXJtLikgVG8gc3VtbWFyaXNlOiBJJ2QgbG92ZQ0KaWYgeW91IGRpZCBzL2Nv bnNlbnQvYW55dGhpbmctZWxzZS9nIGJ1dCBpZiBub3QsIHBsZWFzZQ0KZGVmaW5lIGNvbnNlbnQg aGVyZSBpbiBhIHdheSB0aGF0IGNsZWFybHkgYW5kDQp1bmFtYmlndW91c2x5IGRpc3Rpbmd1aXNo ZXMgdGhpcyB1c2FnZSBmcm9tIG90aGVyIGFidXNlcw0Kb2YgdGhlIHRlcm0uDQoNCg0KW1RSXSBV cGRhdGVkIENvbnNlbnQgZGVmaW5pdGlvbi4NCg0K4oCLVGhlIGRvY3VtZW50IGFscmVhZHkgaGFz IGEgY2xlYXIgYW5kIHVuYW1iaWd1b3VzIGRlZmluaXRpb24gb2YgdGhlIHRlcm0sIElNSE86IOKA iw0KDQrigIsgICBDb25zZW50OiAgVGhlIG1lY2hhbmlzbSBvZiBvYnRhaW5pbmcgcGVybWlzc2lv biBmcm9tIHRoZSByZW1vdGUNCiAgICAgIGVuZHBvaW50IHRvIHNlbmQgbm9uLUlDRSB0cmFmZmlj IHRvIGEgcmVtb3RlIHRyYW5zcG9ydCBhZGRyZXNzLg0KICAgICAgQ29uc2VudCBpcyBvYnRhaW5l ZCB1c2luZyBJQ0Uu4oCLDQoNCuKAi0lzIHRoYXQgZGVmaW5pdGlvbiBsYWNraW5nIHNvbWV0aGlu Zz8g4oCLSSB0aGluayBmaW5kaW5nIGFuIGFsdGVyIHRlcm0gd291bGQgYmUgYXMgaGFyZCBhcyBm aW5kaW5nIGFuIGFsdGVybmF0ZSB0ZXJtIGZvciAnYXR0YWNrJyBhcyB1c2VkIGluIHNldmVyYWwg UkZDcyBbYXR0YWNrIGJlaW5nIChhYil1c2VkIGluIG1hbnkgY29udGV4dHMsIGluY2x1ZGluZyBp biBoZWFydCBhdHRhY2sgOyldDQoNCg0KKDIpIFdlYlJUQyBkb2VzIG5vdCByZXF1aXJlIFNUVU4g b3IgVFVSTiBzZXJ2ZXJzIGZvcg0Kc29tZSBjYWxscywgZXZlbiBpZiBpdCBkb2VzIGZvciBtYW55 LiBXaHkgaXMgaXQgb2sgdG8NCnJlcXVpcmUgc3VjaCBhIHNlcnZlciBiZSBwcmVzZW50IGluIGFs bCBjYWxscyAod2hpY2ggSQ0KdGhpbmsgdGhpcyBtZWFucykgZXNwY2lhbGx5IHdoZW4gdGhhdCBt ZWFucyBleHBvc2luZw0KYWRkaXRpb25hbCBtZXRhLWRhdGEgKGNhbGxpbmcgcGFydGllcyBpbiBh IGNhc2Ugd2hlcmUNCnRoZSBzZXJ2ZXJzIHdlcmVuJ3QgbmVlZGVkIGFuZCBjYWxsIGR1cmF0aW9u IGluIGFsbA0KY2FzZXMpIHRvIHRob3NlIHNlcnZlcnMgd2hlbiB0aGF0IGlzIG5vdCBhbHdheXMN Cm5lY2Vzc2FyeT8NCg0K4oCLVGhhdCBsb29rcyBhIG1pc3VuZGVyc3RhbmRpbmcuIENvbnNlbnQg ZnJlc2huZXNzIGRvZXNuJ3QgcmVxdWlyZSBzdWNoIHNlcnZlcidzIHRvIGJlIHByZXNlbnQuIFBs ZWFzZSBwb2ludCBvdXQgdG8gdGhlIHRleHQgbGVhZGluZyB0byB0aGUgbWlzdW5kZXJzdGFuZGlu Zy4NCg0KDQooMykgKGVuZCBvZiBwNSkgWW91IGhhdmUgYSBNVVNUIE5PVCBoZXJlIHRoYXQgaXMN CmRlcGVuZWRlbnQgb24gY3VycmVudCBicm93c2VyIGltcGxlbWVudGF0aW9ucy4gV2h5IGlzDQp0 aGF0IGFuIElFVEYgdGhpbmcgYW5kIG5vdCBhIFczQyB0aGluZz8gQnV0IG1vcmUNCmludGVyZXN0 aW5nbHksIGNhbiBvbmUgc2VjdXJlbHkgdXNlIHRoaXMgcHJvdG9jb2wNCndpdGhvdXQgdGhlIGtp bmQgb2YgSlMgdnMuIGJyb3dzZXIgc2FuZGJveGluZyBldGMgdGhhdCdzDQpuZWVkZWQgaW4gdGhl IHdlYj8NCg0K4oCLWWVzLCB0aGUgbWVjaGFuaXNtIGhhcyB0aGUgc2FtZSBzZWN1cml0eSBwcm9w ZXJ0aWVzIHdpdGhpbiBhbmQgb3V0c2lkZSB0aGUgV2ViUlRDIHNhbmRib3hpbmcuDQoNCklmIHRo ZSBhbnN3ZXIgaXMgIm5vIiB0aGVuIGRvbid0IHlvdQ0KbmVlZCB0byBzYXkgdGhhdCB0aGlzIHBy b3RvY29sIGNhbiBvbmx5IHNhZmVseSBiZSB1c2VkDQpmb3Igc3VjaCBpbXBsZW1lbnRhdGlvbnM/ IChJbiBzZWN0aW9uIDIsIHdoaWNoIGFsbW9zdA0KYnV0IG5vdCBxdWl0ZSBzYXlzIHRoYXQuKQ0K DQrigItTZWN0aW9uIDIgZG9lc24ndCBzYXkgdGhhdC4gSXQgb25seSBzYXlzIFdlYlJUQyBpcyB0 aGUgcHJpbWFyeSB1c2UgY2FzZSBmb3IgdGhlIG1lY2hhbmlzbSBhdCB0aGUgbW9tZW50IGFuZCBm dXR1cmUgdXNlIGNhc2VzIGJhc2VkIG9uIHNpbWlsYXIgc2FuZGJveGluZyBtb2RlbHMgY2FuIG1h a2UgdXNlIG9mIGl0Lg0KDQoNCig0KSBDbGVhcmVkLg0KDQooNSkgQ2xlYXJlZC4NCg0KDQotLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tDQpDT01NRU5UOg0KLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLQ0KDQoNCihXYXMgZGlzY3VzcyBwb2lu dCM0KQ0KIlNlY3Rpb24gODogV2hlcmUgYXJlIHRoZXNlIDk2IGJpdHMgZGVmaW5lZD8gSSB0aGlu aw0KdGhpcyAicmVxdWlyZXMuLi4iIHN0YXRlbWVudCBuZWVkcyBhIHByZWNpc2UgcmVmZXJlbmNl DQp0byB0aGUgcGxhY2UgaW4gc29tZSBJQ0UvVFVSTi9TVFVOIFJGQyB3aGVyZSBpdCdzDQpkZWZp bmVkLiAoQW5kIEkgZm9yZ2V0IHdoZXJlIHRoYXQgaXMsIHNvcnJ5Oi0pIFRoaXMNCnNob3VsZCBi ZSBhbiBlYXN5IGZpeC4iDQpBbGlzc2EgZ2F2ZSBtZSB0aGUgcmVmZXJlbmNlIFsxXSBzb3RoYXQn cyBncmFuZC4gSXQNCm1pZ2h0IGJlIGFuIGlkZWEgdG8gbWFrZSB0aGF0IGNsZWFyZXIgaWYgaXQg d2Fzbid0DQpqdXN0IG1lIG1pc3NpbmcgaXQgYXMgSSByZWFkLCB3aGljaCBpcyB2ZXJ5IHBvc3Np YmxlOy0pDQoNClsxXSBodHRwczovL3Rvb2xzLmlldGYub3JnL2h0bWwvcmZjNTM4OSNzZWN0aW9u LTYNCg0KLSBhYnN0cmFjdDogd2h5IGlzIG9ubHkgc2VuZGluZyAibWVkaWEiIG1lbnRpb25lZCBo ZXJlPw0KV2hhdCBhYm91dCBkYXRhIGNoYW5uZWxzPyAgQW5kIHRoZSBib2R5IG9mIHRoZSBkb2N1 bWVudA0KaW4gZmFjdCBzYXlzIHRoaXMgYWxsIGFwcGxpZXMgdG8gYW55IG5vbi1JQ0UgZGF0YSBh bmQNCm5vdCBvbmx5IG1lZGlhLg0KDQrigItBZ3JlZSwgdGhhdCBzaG91bGQgYmUgInRyYWZmaWMi Lg0KDQoNCi0gaW50cm86ICJpbml0aWFsIGNvbnNlbnQgdG8gc2VuZCBieSBwZXJmb3JtaW5nIFNU VU4iIEkNCmRvIG5vdCBmaW5kIHRoZSB3b3JkIGNvbnNlbnQgaW4gZWl0aGVyIHJmYzUyNDUgb3Ig MzQ4OSwNCmJ1dCBwZXJoYXBzIGl0IGlzIHVzZWQgc29tZXdoZXJlIGVsc2UuIFdoZXJlPyAgQW5k IHdpdGgNCndoYXQgbWVhbmluZz8NCg0K4oCLQ29uc2VudCBpcyBhIG5ldyB1c2FnZSBvZiBTVFVO IGFuZCBpcyBkZXNjcmliZWQgaW4gZHJhZnQtaWV0Zi1ydGN3ZWItc2VjdXJpdHktYXJjaCwgZHJh ZnQtaWV0Zi1ydGN3ZWItc2VjdXJpdHkgYW5kIGluIHRoaXMgZG9jdW1lbnQuDQoNCg0KLSBzZWN0 aW9uIDQsIDJuZCBsYXN0IHBhcmEgLSBJIHRoaW5rIHRoZSBjb25jbHVzaW9uIGlzDQpib2d1cy4g IEFuIGltcGxlbWVudGF0aW9uIGtub3dzIHdoZW4gdGhlIGtleWluZyBpdCdzDQp1c2luZyBjYW4g bm90IGludm9sdmUgPjEgKG5vbWluYWxseSBvcGVyYXRpbmcpIHBhcnR5Lg0KDQpUaGF0IHBhcmFn cmFwaCBpcyBoZXJlOg0KDQrigIvigIsgICBXaGVuIFNlY3VyZSBSZWFsLXRpbWUgVHJhbnNwb3J0 IFByb3RvY29sIChTUlRQKSBpcyB1c2VkLCB0aGUNCiAgIGZvbGxvd2luZyBjb25zaWRlcmF0aW9u cyBhcmUgYXBwbGljYWJsZS4gIFNSVFAgaXMgZW5jcnlwdGVkIGFuZA0KICAgYXV0aGVudGljYXRl ZCB3aXRoIHN5bW1ldHJpYyBrZXlzOyB0aGF0IGlzLCBib3RoIHNlbmRlciBhbmQgcmVjZWl2ZXIN CiAgIGtub3cgdGhlIGtleXMuICBXaXRoIHR3byBwYXJ0eSBzZXNzaW9ucywgcmVjZWlwdCBvZiBh biBhdXRoZW50aWNhdGVkDQogICBwYWNrZXQgZnJvbSB0aGUgc2luZ2xlIHJlbW90ZSBwYXJ0eSBp cyBhIHN0cm9uZyBhc3N1cmFuY2UgdGhlIHBhY2tldA0KICAgY2FtZSBmcm9tIHRoYXQgcGFydHku ICBIb3dldmVyLCB3aGVuIGEgc2Vzc2lvbiBpbnZvbHZlcyBtb3JlIHRoYW4gdHdvDQogICBwYXJ0 aWVzLCBhbGwgb2Ygd2hvbSBrbm93IGVhY2ggb3RoZXIncyBrZXlzLCBhbnkgb2YgdGhvc2UgcGFy dGllcw0KICAgY291bGQgaGF2ZSBzZW50IChvciBzcG9vZmVkKSB0aGUgcGFja2V0LiAgU3VjaCBz aGFyZWQga2V5DQogICBkaXN0cmlidXRpb25zIGFyZSBwb3NzaWJsZSB3aXRoIHNvbWUgTUlLRVkg W1JGQzM4MzBdIG1vZGVzLCBTZWN1cml0eQ0KICAgRGVzY3JpcHRpb25zIFtSRkM0NTY4XSwgYW5k IEVLVCBbSS1ELmlldGYtYXZ0Y29yZS1zcnRwLWVrdF0uICBUaHVzLA0KICAgaW4gc3VjaCBzaGFy ZWQga2V5aW5nIGRpc3RyaWJ1dGlvbnMsIHJlY2VpcHQgb2YgYW4gYXV0aGVudGljYXRlZCBTUlRQ DQogICBwYWNrZXQgaXMgbm90IHN1ZmZpY2llbnQgdG8gdmVyaWZ5IGNvbnNlbnQuDQoNCuKAi0kn bGwgZGVmZXIgaXQgdG8gc29tZW9uZSB3aG8gaGFzIG1vcmUga25vd2xlZGdlIHRoYXQgbWUgb24g c2hhcmVkIGtleSBkaXN0cmlidXRpb24uLg0KDQpbVFJdIFRoZSBpZGVhIGJlaGluZCB0aGUgYWJv dmUgcGFyYWdyYXBoIGlzIHRvIHVzZSBTVFVOIGNvbnNlbnQgY2hlY2tzIGluIGJvdGggdHdvIHBh cnR5IGFuZCBtdWx0aS1wYXJ0eSBzZXNzaW9ucy4gQ29uc2VudCBjaGVja3MgdXNlcw0KcG9pbnQt dG8tcG9pbnQga2V5cyBzbyB0aGUgZW5kcG9pbnQga25vd3MgaWYgZWFjaCByZW1vdGUgcGVlciBp biB0aGUgY2FsbCBpcyB3aWxsaW5nIHRvIHJlY2VpdmUgdHJhZmZpYyBvciBub3QuDQoNCi1UaXJ1 DQoNCg0KLSA1LjEsIDNyZCBwYXJhOiAiRXhwbGljaXQgY29uc2VudCB0byBzZW5kIGlzDQpvYnRh aW5lZC4uLiIgaXMgbWlzbGVhZGluZy4gVGhhdCBpcyBub3QgYSBjb25jZXB0IHRoYXQNCmFuIGlt cGxlbWVudGF0aW9uIG9mIFNUVU4gd2lsbCBlbWJvZHkuDQoNCuKAi0FzIHNhaWQgZWFybGllciwg Y29uc2VudCBpcyBhIG5ldyBTVFVOIHVzYWdlLiBIb3cgd291bGQgdGhlIGZvbGxvd2luZz8NCg0K ICAgIEFuIGVuZHBvaW50IHRoYXQgaW1wbGVtZW50cyB0aGlzIHNwZWNpZmljYXRpb24gb2J0YWlu cyBhbmQgbWFpbnRhaW5zDQogICAgY29uc2VudCB0byBzZW5kIGJ5IHNlbmRpbmcgU1RVTiBiaW5k aW5nIHJlcXVlc3QuLi4NCg0KDQotIDUuMSwgV2hhdCBpcyB0aGUgIk5vdGUiIGFib3V0IFRDUCBm b3I/IFdoeSBpcyB0aGlzDQpuZWVkZWQ/DQoNCuKAi0l0IGlzIG5lZWRlZCBiZWNhdXNlIFdlYlJU QyBkYXRhIHRyYWZmaWMgc2VudCBvdmVyIFRDUCBjb3VsZCBnZXQgY29udmVydGVkIHRvIFVEUCBi eSBUVVJOIHNlcnZlcnMuIEl0IGlzIHNvbWV3aGF0IHNpbWlsYXIgdG8gd2h5IHdlIG5lZWQgYXBw bGljYXRpb24gbGF5ZXIgc2VjdXJpdHkgd2hlbiB0cmFmZmljIGlzIHNlbnQgb3ZlciBJUFNlYy4g VGhlIGxhdGVyIG1heSBub3QgYmUgZW5kLXRvLWVuZC4NCg0KTXV0aHUNCg== --_000_913383AAA69FF945B8F946018B75898A478BCD7Exmbrcdx10ciscoc_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTQgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 Q2FsaWJyaTsNCglwYW5vc2UtMToyIDE1IDUgMiAyIDIgNCAzIDIgNDt9DQpAZm9udC1mYWNlDQoJ e2ZvbnQtZmFtaWx5OlRhaG9tYTsNCglwYW5vc2UtMToyIDExIDYgNCAzIDUgNCA0IDIgNDt9DQov KiBTdHlsZSBEZWZpbml0aW9ucyAqLw0KcC5Nc29Ob3JtYWwsIGxpLk1zb05vcm1hbCwgZGl2Lk1z b05vcm1hbA0KCXttYXJnaW46MGluOw0KCW1hcmdpbi1ib3R0b206LjAwMDFwdDsNCglmb250LXNp emU6MTIuMHB0Ow0KCWZvbnQtZmFtaWx5OiJUaW1lcyBOZXcgUm9tYW4iLCJzZXJpZiI7fQ0KYTps aW5rLCBzcGFuLk1zb0h5cGVybGluaw0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6 Ymx1ZTsNCgl0ZXh0LWRlY29yYXRpb246dW5kZXJsaW5lO30NCmE6dmlzaXRlZCwgc3Bhbi5Nc29I eXBlcmxpbmtGb2xsb3dlZA0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6cHVycGxl Ow0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0Kc3Bhbi5FbWFpbFN0eWxlMTcNCgl7bXNv LXN0eWxlLXR5cGU6cGVyc29uYWwtcmVwbHk7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLCJzYW5z LXNlcmlmIjsNCgljb2xvcjojMUY0OTdEO30NCi5Nc29DaHBEZWZhdWx0DQoJe21zby1zdHlsZS10 eXBlOmV4cG9ydC1vbmx5Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIiwic2Fucy1zZXJpZiI7fQ0K QHBhZ2UgV29yZFNlY3Rpb24xDQoJe3NpemU6OC41aW4gMTEuMGluOw0KCW1hcmdpbjoxLjBpbiAx LjBpbiAxLjBpbiAxLjBpbjt9DQpkaXYuV29yZFNlY3Rpb24xDQoJe3BhZ2U6V29yZFNlY3Rpb24x O30NCi0tPjwvc3R5bGU+PCEtLVtpZiBndGUgbXNvIDldPjx4bWw+DQo8bzpzaGFwZWRlZmF1bHRz IHY6ZXh0PSJlZGl0IiBzcGlkbWF4PSIxMDI2IiAvPg0KPC94bWw+PCFbZW5kaWZdLS0+PCEtLVtp ZiBndGUgbXNvIDldPjx4bWw+DQo8bzpzaGFwZWxheW91dCB2OmV4dD0iZWRpdCI+DQo8bzppZG1h cCB2OmV4dD0iZWRpdCIgZGF0YT0iMSIgLz4NCjwvbzpzaGFwZWxheW91dD48L3htbD48IVtlbmRp Zl0tLT4NCjwvaGVhZD4NCjxib2R5IGxhbmc9IkVOLVVTIiBsaW5rPSJibHVlIiB2bGluaz0icHVy cGxlIj4NCjxkaXYgY2xhc3M9IldvcmRTZWN0aW9uMSI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48 c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1 b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+SGkgU3RlcGhlbiw8bzpw PjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9u dC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMt c2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1m YW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMx RjQ5N0QiPlVwZGF0ZWQgZHJhZnQgdG8gYWRkcmVzcyB5b3VyIGNvbW1lbnRzDQo8YSBocmVmPSJo dHRwczovL2dpdGh1Yi5jb20vRHJhZnQtTWFmaWEvQ29uc2VudGZyZXNobmVzcy9jb21wYXJlL21h c3Rlci4uLnJtb2hhbnItU3RlcGhlbkNvbnNlbnRGcmVzaG5lc3MiPg0KaHR0cHM6Ly9naXRodWIu Y29tL0RyYWZ0LU1hZmlhL0NvbnNlbnRmcmVzaG5lc3MvY29tcGFyZS9tYXN0ZXIuLi5ybW9oYW5y LVN0ZXBoZW5Db25zZW50RnJlc2huZXNzPC9hPiwgUGxlYXNlIGhhdmUgYSBsb29rLjxvOnA+PC9v OnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNp emU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJp ZiZxdW90Oztjb2xvcjojMUY0OTdEIj5BbHNvIHNlZSBpbmxpbmUgW1RSXTxvOnA+PC9vOnA+PC9z cGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEu MHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90 Oztjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8ZGl2IHN0eWxl PSJib3JkZXI6bm9uZTtib3JkZXItbGVmdDpzb2xpZCBibHVlIDEuNXB0O3BhZGRpbmc6MGluIDBp biAwaW4gNC4wcHQiPg0KPGRpdj4NCjxkaXYgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci10b3A6 c29saWQgI0I1QzRERiAxLjBwdDtwYWRkaW5nOjMuMHB0IDBpbiAwaW4gMGluIj4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPjxiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5 OiZxdW90O1RhaG9tYSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij5Gcm9tOjwvc3Bhbj48 L2I+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7VGFob21h JnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPiBNdXRodSBBcnVsIE1vemhpIFBlcnVtYWwg W21haWx0bzptdXRodS5hcnVsQGdtYWlsLmNvbV0NCjxicj4NCjxiPlNlbnQ6PC9iPiBUaHVyc2Rh eSwgQXVndXN0IDA2LCAyMDE1IDEwOjI3IEFNPGJyPg0KPGI+VG86PC9iPiBTdGVwaGVuIEZhcnJl bGw8YnI+DQo8Yj5DYzo8L2I+IFRoZSBJRVNHOyBkcmFmdC1pZXRmLXJ0Y3dlYi1zdHVuLWNvbnNl bnQtZnJlc2huZXNzQGlldGYub3JnOyBydGN3ZWItY2hhaXJzQGlldGYub3JnOyBkcmFmdC1pZXRm LXJ0Y3dlYi1zdHVuLWNvbnNlbnQtZnJlc2huZXNzLnNoZXBoZXJkQGlldGYub3JnOyBkcmFmdC1p ZXRmLXJ0Y3dlYi1zdHVuLWNvbnNlbnQtZnJlc2huZXNzLmFkQGlldGYub3JnOyBydGN3ZWJAaWV0 Zi5vcmc8YnI+DQo8Yj5TdWJqZWN0OjwvYj4gUmU6IFN0ZXBoZW4gRmFycmVsbCdzIERpc2N1c3Mg b24gZHJhZnQtaWV0Zi1ydGN3ZWItc3R1bi1jb25zZW50LWZyZXNobmVzcy0xNTogKHdpdGggRElT Q1VTUyBhbmQgQ09NTUVOVCk8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8ZGl2Pg0KPGRpdj4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtBcmlh bCZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij5IaSBTdGVwaGVuLDxvOnA+PC9vOnA+PC9z cGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxl PSJmb250LWZhbWlseTomcXVvdDtBcmlhbCZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij48 bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDssJnF1b3Q7 c2Fucy1zZXJpZiZxdW90OyI+T24gVGh1LCBBdWcgNiwgMjAxNSBhdCA0OjA4IEFNLCBTdGVwaGVu IEZhcnJlbGwgJmx0OzxhIGhyZWY9Im1haWx0bzpzdGVwaGVuLmZhcnJlbGxAY3MudGNkLmllIiB0 YXJnZXQ9Il9ibGFuayI+c3RlcGhlbi5mYXJyZWxsQGNzLnRjZC5pZTwvYT4mZ3Q7IHdyb3RlOjxv OnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxkaXY+DQo8YmxvY2txdW90ZSBz dHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLWxlZnQ6c29saWQgI0NDQ0NDQyAxLjBwdDtwYWRkaW5n OjBpbiAwaW4gMGluIDYuMHB0O21hcmdpbi1sZWZ0OjQuOHB0O21hcmdpbi1yaWdodDowaW4iPg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+U3RlcGhlbiBGYXJyZWxsIGhhcyBlbnRlcmVkIHRoZSBmb2xs b3dpbmcgYmFsbG90IHBvc2l0aW9uIGZvcjxicj4NCmRyYWZ0LWlldGYtcnRjd2ViLXN0dW4tY29u c2VudC1mcmVzaG5lc3MtMTU6IERpc2N1c3M8YnI+DQo8YnI+DQpXaGVuIHJlc3BvbmRpbmcsIHBs ZWFzZSBrZWVwIHRoZSBzdWJqZWN0IGxpbmUgaW50YWN0IGFuZCByZXBseSB0byBhbGw8YnI+DQpl bWFpbCBhZGRyZXNzZXMgaW5jbHVkZWQgaW4gdGhlIFRvIGFuZCBDQyBsaW5lcy4gKEZlZWwgZnJl ZSB0byBjdXQgdGhpczxicj4NCmludHJvZHVjdG9yeSBwYXJhZ3JhcGgsIGhvd2V2ZXIuKTxicj4N Cjxicj4NCjxicj4NClBsZWFzZSByZWZlciB0byA8YSBocmVmPSJodHRwczovL3d3dy5pZXRmLm9y Zy9pZXNnL3N0YXRlbWVudC9kaXNjdXNzLWNyaXRlcmlhLmh0bWwiIHRhcmdldD0iX2JsYW5rIj4N Cmh0dHBzOi8vd3d3LmlldGYub3JnL2llc2cvc3RhdGVtZW50L2Rpc2N1c3MtY3JpdGVyaWEuaHRt bDwvYT48YnI+DQpmb3IgbW9yZSBpbmZvcm1hdGlvbiBhYm91dCBJRVNHIERJU0NVU1MgYW5kIENP TU1FTlQgcG9zaXRpb25zLjxicj4NCjxicj4NCjxicj4NClRoZSBkb2N1bWVudCwgYWxvbmcgd2l0 aCBvdGhlciBiYWxsb3QgcG9zaXRpb25zLCBjYW4gYmUgZm91bmQgaGVyZTo8YnI+DQo8YSBocmVm PSJodHRwczovL2RhdGF0cmFja2VyLmlldGYub3JnL2RvYy9kcmFmdC1pZXRmLXJ0Y3dlYi1zdHVu LWNvbnNlbnQtZnJlc2huZXNzLyIgdGFyZ2V0PSJfYmxhbmsiPmh0dHBzOi8vZGF0YXRyYWNrZXIu aWV0Zi5vcmcvZG9jL2RyYWZ0LWlldGYtcnRjd2ViLXN0dW4tY29uc2VudC1mcmVzaG5lc3MvPC9h Pjxicj4NCjxicj4NCjxicj4NCjxicj4NCi0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS08YnI+DQpESVNDVVNTOjxicj4N Ci0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS08YnI+DQo8YnI+DQo8YnI+DQo8YnI+DQpBcG9sb2dpZXMgdGhhdCB0aGVz ZSBkaXNjdXNzIHBvaW50cyBhcmUgbWF5YmUgYXNraW5nPGJyPg0KZmFpcmx5IGZ1bmRhbWVudGFs IHF1ZXN0aW9ucy4mbmJzcDsgVGhhdCBjb3VsZCBiZSB0aGF0IHRoaXM8YnI+DQppcyByZWFsbHkg dGhlIGZpcnN0IG9mIHRoZSBuZXcgc2VjdXJpdHkgdGhpbmdzIHJlcXVpcmVkPGJyPg0KYnkgcnRj d2ViIHRvIGdldCB0byB0aGUgSUVTRy4mbmJzcDsgT3IgbWF5YmUgSSdtIG1pc3JlYWRpbmc8YnI+ DQpzdHVmZiBoZXJlLCBpZiBzbywgc29ycnk7LSk8YnI+DQo8YnI+DQooMSkgV2h5IGNhbGwgdGhp cyAmcXVvdDtjb25zZW50PyZxdW90OyBUaGF0IHRlcm0gaXMgKGFiKXVzZWQgaW48YnI+DQptYW55 IHdheXMgb24gdGhlIHdlYiwgYW5kIGFkZGluZyBhbm90aGVyIHZhcmlhdGlvbjxicj4NCndpdGhv dXQgYSBkZWZpbml0aW9uIHRoYXQgZGlzdGluZ3Vpc2hlcyB0aGlzIGZyb20gJnF1b3Q7Y2xpY2s8 YnI+DQpvayB0byBteSAyMDAgcGFnZSBhbnRpLXByaXZhY3kgcG9saWN5JnF1b3Q7IG9yICZxdW90 O3JlbWVtYmVyIHRoYXQ8YnI+DQo8YSBocmVmPSJodHRwOi8vZXhhbXBsZS5jb20iIHRhcmdldD0i X2JsYW5rIj5leGFtcGxlLmNvbTwvYT4gaXMgYWxsb3dlZCB1c2UgbXkgY2FtZXJhL21pYyZxdW90 OyBzZWVtcyBsaWtlIGE8YnI+DQp0ZXJyaWJsZSBpZGVhLiBJIGFsc28gZG9uJ3Qgc2VlIGhvdyB0 aGlzIGNhbiBldmVyIGJlPGJyPg0Kc29tZXRoaW5nIHRvIHdoaWNoIGEgbm9ybWFsIHBlcnNvbiBj YW4gJnF1b3Q7Y29uc2VudCZxdW90OyAoaS5lLjxicj4NCmNvbnNjaW91c2x5IGFncmVlIHdoaWxl IGZ1bGx5IHVuZGVyc3RhbmRpbmcpIHNvIHRoZSB0ZXJtPGJyPg0KaXMgSU1PIHZlcnkgbWlzbGVh ZGluZywgYW5kIHdpbGwgSSBmZWFyIGJlIHVzZWQgdG88YnI+DQptaXNsZWFkIGZ1cnRoZXIuJm5i c3A7IChTZWUgYWxzbyBzb21lIG9mIHRoZSBjb21tZW50cyBiZWxvdyAtPGJyPg0KSSBkbyBub3Qg dGhpbmsgd2Ugb3VnaHQgYmUgYXMgZmFzdCBhbmQgbG9vc2Ugd2l0aCB0aGlzPGJyPg0KYWxlYWR5 IHRlcnJpYmx5IGJhZGx5IHVzZWQgdGVybS4pIFRvIHN1bW1hcmlzZTogSSdkIGxvdmU8YnI+DQpp ZiB5b3UgZGlkIHMvY29uc2VudC9hbnl0aGluZy1lbHNlL2cgYnV0IGlmIG5vdCwgcGxlYXNlPGJy Pg0KZGVmaW5lIGNvbnNlbnQgaGVyZSBpbiBhIHdheSB0aGF0IGNsZWFybHkgYW5kPGJyPg0KdW5h bWJpZ3VvdXNseSBkaXN0aW5ndWlzaGVzIHRoaXMgdXNhZ2UgZnJvbSBvdGhlciBhYnVzZXM8YnI+ DQpvZiB0aGUgdGVybS48bzpwPjwvbzpwPjwvcD4NCjwvYmxvY2txdW90ZT4NCjxkaXY+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iY29sb3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8 L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQt c2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNl cmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFt aWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0 OTdEIj5bVFJdIFVwZGF0ZWQgQ29uc2VudCBkZWZpbml0aW9uLg0KPG86cD48L286cD48L3NwYW4+ PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7 Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2Nv bG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4N CjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1 b3Q7QXJpYWwmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+4oCLVGhlIGRvY3VtZW50IGFs cmVhZHkgaGFzIGEgY2xlYXIgYW5kIHVuYW1iaWd1b3VzIGRlZmluaXRpb24gb2YgdGhlIHRlcm0s IElNSE86IOKAizxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+ DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiZx dW90O0FyaWFsJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPuKAiyAmbmJzcDsgQ29uc2Vu dDogJm5ic3A7VGhlIG1lY2hhbmlzbSBvZiBvYnRhaW5pbmcgcGVybWlzc2lvbiBmcm9tIHRoZSBy ZW1vdGU8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDssJnF1b3Q7 c2Fucy1zZXJpZiZxdW90OyI+Jm5ic3A7ICZuYnNwOyAmbmJzcDsgZW5kcG9pbnQgdG8gc2VuZCBu b24tSUNFIHRyYWZmaWMgdG8gYSByZW1vdGUgdHJhbnNwb3J0IGFkZHJlc3MuPG86cD48L286cD48 L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5 bGU9ImZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsi PiZuYnNwOyAmbmJzcDsgJm5ic3A7IENvbnNlbnQgaXMgb2J0YWluZWQgdXNpbmcgSUNFLuKAizxv OnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4m bmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7LCZxdW90O3NhbnMt c2VyaWYmcXVvdDsiPuKAi0lzIHRoYXQgZGVmaW5pdGlvbiBsYWNraW5nIHNvbWV0aGluZz8g4oCL SSB0aGluayBmaW5kaW5nIGFuIGFsdGVyIHRlcm0gd291bGQgYmUgYXMgaGFyZCBhcyBmaW5kaW5n IGFuIGFsdGVybmF0ZSB0ZXJtIGZvciAnYXR0YWNrJyBhcyB1c2VkIGluIHNldmVyYWwgUkZDcyBb YXR0YWNrIGJlaW5nIChhYil1c2VkIGluIG1hbnkgY29udGV4dHMsDQogaW5jbHVkaW5nIGluIGhl YXJ0IGF0dGFjayA7KV08bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRp dj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8 YmxvY2txdW90ZSBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLWxlZnQ6c29saWQgI0NDQ0NDQyAx LjBwdDtwYWRkaW5nOjBpbiAwaW4gMGluIDYuMHB0O21hcmdpbi1sZWZ0OjQuOHB0O21hcmdpbi1y aWdodDowaW4iPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGJyPg0KKDIpIFdlYlJUQyBkb2VzIG5v dCByZXF1aXJlIFNUVU4gb3IgVFVSTiBzZXJ2ZXJzIGZvcjxicj4NCnNvbWUgY2FsbHMsIGV2ZW4g aWYgaXQgZG9lcyBmb3IgbWFueS4gV2h5IGlzIGl0IG9rIHRvPGJyPg0KcmVxdWlyZSBzdWNoIGEg c2VydmVyIGJlIHByZXNlbnQgaW4gYWxsIGNhbGxzICh3aGljaCBJPGJyPg0KdGhpbmsgdGhpcyBt ZWFucykgZXNwY2lhbGx5IHdoZW4gdGhhdCBtZWFucyBleHBvc2luZzxicj4NCmFkZGl0aW9uYWwg bWV0YS1kYXRhIChjYWxsaW5nIHBhcnRpZXMgaW4gYSBjYXNlIHdoZXJlPGJyPg0KdGhlIHNlcnZl cnMgd2VyZW4ndCBuZWVkZWQgYW5kIGNhbGwgZHVyYXRpb24gaW4gYWxsPGJyPg0KY2FzZXMpIHRv IHRob3NlIHNlcnZlcnMgd2hlbiB0aGF0IGlzIG5vdCBhbHdheXM8YnI+DQpuZWNlc3Nhcnk/PG86 cD48L286cD48L3A+DQo8L2Jsb2NrcXVvdGU+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7LCZxdW90 O3NhbnMtc2VyaWYmcXVvdDsiPuKAi1RoYXQgbG9va3MgYSBtaXN1bmRlcnN0YW5kaW5nLiBDb25z ZW50IGZyZXNobmVzcyBkb2Vzbid0IHJlcXVpcmUgc3VjaCBzZXJ2ZXIncyB0byBiZSBwcmVzZW50 LiBQbGVhc2UgcG9pbnQgb3V0IHRvIHRoZSB0ZXh0IGxlYWRpbmcgdG8gdGhlIG1pc3VuZGVyc3Rh bmRpbmcuPG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGJsb2NrcXVv dGUgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci1sZWZ0OnNvbGlkICNDQ0NDQ0MgMS4wcHQ7cGFk ZGluZzowaW4gMGluIDBpbiA2LjBwdDttYXJnaW4tbGVmdDo0LjhwdDttYXJnaW4tcmlnaHQ6MGlu Ij4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxicj4NCigzKSAoZW5kIG9mIHA1KSBZb3UgaGF2ZSBh IE1VU1QgTk9UIGhlcmUgdGhhdCBpczxicj4NCmRlcGVuZWRlbnQgb24gY3VycmVudCBicm93c2Vy IGltcGxlbWVudGF0aW9ucy4gV2h5IGlzPGJyPg0KdGhhdCBhbiBJRVRGIHRoaW5nIGFuZCBub3Qg YSBXM0MgdGhpbmc/IEJ1dCBtb3JlPGJyPg0KaW50ZXJlc3RpbmdseSwgY2FuIG9uZSBzZWN1cmVs eSB1c2UgdGhpcyBwcm90b2NvbDxicj4NCndpdGhvdXQgdGhlIGtpbmQgb2YgSlMgdnMuIGJyb3dz ZXIgc2FuZGJveGluZyBldGMgdGhhdCdzPGJyPg0KbmVlZGVkIGluIHRoZSB3ZWI/IDxvOnA+PC9v OnA+PC9wPg0KPC9ibG9ja3F1b3RlPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+ Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtBcmlhbCZxdW90OywmcXVvdDtzYW5z LXNlcmlmJnF1b3Q7Ij7igItZZXMsIHRoZSBtZWNoYW5pc20gaGFzIHRoZSBzYW1lIHNlY3VyaXR5 IHByb3BlcnRpZXMgd2l0aGluIGFuZCBvdXRzaWRlIHRoZSBXZWJSVEMgc2FuZGJveGluZy48bzpw PjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8YmxvY2txdW90ZSBzdHlsZT0i Ym9yZGVyOm5vbmU7Ym9yZGVyLWxlZnQ6c29saWQgI0NDQ0NDQyAxLjBwdDtwYWRkaW5nOjBpbiAw aW4gMGluIDYuMHB0O21hcmdpbi1sZWZ0OjQuOHB0O21hcmdpbi1yaWdodDowaW4iPg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+SWYgdGhlIGFuc3dlciBpcyAmcXVvdDtubyZxdW90OyB0aGVuIGRvbid0 IHlvdTxicj4NCm5lZWQgdG8gc2F5IHRoYXQgdGhpcyBwcm90b2NvbCBjYW4gb25seSBzYWZlbHkg YmUgdXNlZDxicj4NCmZvciBzdWNoIGltcGxlbWVudGF0aW9ucz8gKEluIHNlY3Rpb24gMiwgd2hp Y2ggYWxtb3N0PGJyPg0KYnV0IG5vdCBxdWl0ZSBzYXlzIHRoYXQuKTxvOnA+PC9vOnA+PC9wPg0K PC9ibG9ja3F1b3RlPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9v OnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFu IHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtBcmlhbCZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1 b3Q7Ij7igItTZWN0aW9uIDIgZG9lc24ndCBzYXkgdGhhdC4gSXQgb25seSBzYXlzIFdlYlJUQyBp cyB0aGUgcHJpbWFyeSB1c2UgY2FzZSBmb3IgdGhlIG1lY2hhbmlzbSBhdCB0aGUgbW9tZW50IGFu ZCBmdXR1cmUgdXNlIGNhc2VzIGJhc2VkIG9uIHNpbWlsYXIgc2FuZGJveGluZyBtb2RlbHMgY2Fu IG1ha2UgdXNlIG9mIGl0LiZuYnNwOzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPC9k aXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8 L2Rpdj4NCjxibG9ja3F1b3RlIHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItbGVmdDpzb2xpZCAj Q0NDQ0NDIDEuMHB0O3BhZGRpbmc6MGluIDBpbiAwaW4gNi4wcHQ7bWFyZ2luLWxlZnQ6NC44cHQ7 bWFyZ2luLXJpZ2h0OjBpbiI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48YnI+DQooNCkgQ2xlYXJl ZC48YnI+DQo8YnI+DQooNSkgQ2xlYXJlZC48YnI+DQo8YnI+DQo8YnI+DQotLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t PGJyPg0KQ09NTUVOVDo8YnI+DQotLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tPGJyPg0KPGJyPg0KPGJyPg0KKFdhcyBk aXNjdXNzIHBvaW50IzQpPGJyPg0KJnF1b3Q7U2VjdGlvbiA4OiBXaGVyZSBhcmUgdGhlc2UgOTYg Yml0cyBkZWZpbmVkPyBJIHRoaW5rPGJyPg0KdGhpcyAmcXVvdDtyZXF1aXJlcy4uLiZxdW90OyBz dGF0ZW1lbnQgbmVlZHMgYSBwcmVjaXNlIHJlZmVyZW5jZTxicj4NCnRvIHRoZSBwbGFjZSBpbiBz b21lIElDRS9UVVJOL1NUVU4gUkZDIHdoZXJlIGl0J3M8YnI+DQpkZWZpbmVkLiAoQW5kIEkgZm9y Z2V0IHdoZXJlIHRoYXQgaXMsIHNvcnJ5Oi0pIFRoaXM8YnI+DQpzaG91bGQgYmUgYW4gZWFzeSBm aXguJnF1b3Q7PGJyPg0KQWxpc3NhIGdhdmUgbWUgdGhlIHJlZmVyZW5jZSBbMV0gc290aGF0J3Mg Z3JhbmQuIEl0PGJyPg0KbWlnaHQgYmUgYW4gaWRlYSB0byBtYWtlIHRoYXQgY2xlYXJlciBpZiBp dCB3YXNuJ3Q8YnI+DQpqdXN0IG1lIG1pc3NpbmcgaXQgYXMgSSByZWFkLCB3aGljaCBpcyB2ZXJ5 IHBvc3NpYmxlOy0pPGJyPg0KPGJyPg0KWzFdIDxhIGhyZWY9Imh0dHBzOi8vdG9vbHMuaWV0Zi5v cmcvaHRtbC9yZmM1Mzg5I3NlY3Rpb24tNiIgdGFyZ2V0PSJfYmxhbmsiPmh0dHBzOi8vdG9vbHMu aWV0Zi5vcmcvaHRtbC9yZmM1Mzg5I3NlY3Rpb24tNjwvYT48YnI+DQo8YnI+DQotIGFic3RyYWN0 OiB3aHkgaXMgb25seSBzZW5kaW5nICZxdW90O21lZGlhJnF1b3Q7IG1lbnRpb25lZCBoZXJlPzxi cj4NCldoYXQgYWJvdXQgZGF0YSBjaGFubmVscz8mbmJzcDsgQW5kIHRoZSBib2R5IG9mIHRoZSBk b2N1bWVudDxicj4NCmluIGZhY3Qgc2F5cyB0aGlzIGFsbCBhcHBsaWVzIHRvIGFueSBub24tSUNF IGRhdGEgYW5kPGJyPg0Kbm90IG9ubHkgbWVkaWEuPG86cD48L286cD48L3A+DQo8L2Jsb2NrcXVv dGU+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8 L2Rpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZv bnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPuKAi0Fn cmVlLCB0aGF0IHNob3VsZCBiZSAmcXVvdDt0cmFmZmljJnF1b3Q7LjxvOnA+PC9vOnA+PC9zcGFu PjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Jm5ic3A7 PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxibG9ja3F1b3RlIHN0eWxlPSJib3JkZXI6bm9uZTti b3JkZXItbGVmdDpzb2xpZCAjQ0NDQ0NDIDEuMHB0O3BhZGRpbmc6MGluIDBpbiAwaW4gNi4wcHQ7 bWFyZ2luLWxlZnQ6NC44cHQ7bWFyZ2luLXJpZ2h0OjBpbiI+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij48YnI+DQotIGludHJvOiAmcXVvdDtpbml0aWFsIGNvbnNlbnQgdG8gc2VuZCBieSBwZXJmb3Jt aW5nIFNUVU4mcXVvdDsgSTxicj4NCmRvIG5vdCBmaW5kIHRoZSB3b3JkIGNvbnNlbnQgaW4gZWl0 aGVyIHJmYzUyNDUgb3IgMzQ4OSw8YnI+DQpidXQgcGVyaGFwcyBpdCBpcyB1c2VkIHNvbWV3aGVy ZSBlbHNlLiBXaGVyZT8mbmJzcDsgQW5kIHdpdGg8YnI+DQp3aGF0IG1lYW5pbmc/PG86cD48L286 cD48L3A+DQo8L2Jsb2NrcXVvdGU+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4m bmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7LCZxdW90O3NhbnMt c2VyaWYmcXVvdDsiPuKAi0NvbnNlbnQgaXMgYSBuZXcgdXNhZ2Ugb2YgU1RVTiBhbmQgaXMgZGVz Y3JpYmVkIGluIGRyYWZ0LWlldGYtcnRjd2ViLXNlY3VyaXR5LWFyY2gsIGRyYWZ0LWlldGYtcnRj d2ViLXNlY3VyaXR5IGFuZCBpbiB0aGlzIGRvY3VtZW50LjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4N CjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Jm5ic3A7PG86cD48 L286cD48L3A+DQo8L2Rpdj4NCjxibG9ja3F1b3RlIHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXIt bGVmdDpzb2xpZCAjQ0NDQ0NDIDEuMHB0O3BhZGRpbmc6MGluIDBpbiAwaW4gNi4wcHQ7bWFyZ2lu LWxlZnQ6NC44cHQ7bWFyZ2luLXJpZ2h0OjBpbiI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48YnI+ DQotIHNlY3Rpb24gNCwgMm5kIGxhc3QgcGFyYSAtIEkgdGhpbmsgdGhlIGNvbmNsdXNpb24gaXM8 YnI+DQpib2d1cy4mbmJzcDsgQW4gaW1wbGVtZW50YXRpb24ga25vd3Mgd2hlbiB0aGUga2V5aW5n IGl0J3M8YnI+DQp1c2luZyBjYW4gbm90IGludm9sdmUgJmd0OzEgKG5vbWluYWxseSBvcGVyYXRp bmcpIHBhcnR5LjxvOnA+PC9vOnA+PC9wPg0KPC9ibG9ja3F1b3RlPg0KPGRpdj4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdj4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtBcmlh bCZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij5UaGF0IHBhcmFncmFwaCBpcyBoZXJlOjxv OnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1 b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPuKAi+KAiyAmbmJzcDsgV2hlbiBTZWN1cmUgUmVh bC10aW1lIFRyYW5zcG9ydCBQcm90b2NvbCAoU1JUUCkgaXMgdXNlZCwgdGhlPG86cD48L286cD48 L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5 bGU9ImZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsi PiZuYnNwOyAmbmJzcDtmb2xsb3dpbmcgY29uc2lkZXJhdGlvbnMgYXJlIGFwcGxpY2FibGUuJm5i c3A7IFNSVFAgaXMgZW5jcnlwdGVkIGFuZDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0K PGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTomcXVv dDtBcmlhbCZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij4mbmJzcDsgJm5ic3A7YXV0aGVu dGljYXRlZCB3aXRoIHN5bW1ldHJpYyBrZXlzOyB0aGF0IGlzLCBib3RoIHNlbmRlciBhbmQgcmVj ZWl2ZXI8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDssJnF1b3Q7 c2Fucy1zZXJpZiZxdW90OyI+Jm5ic3A7ICZuYnNwO2tub3cgdGhlIGtleXMuJm5ic3A7IFdpdGgg dHdvIHBhcnR5IHNlc3Npb25zLCByZWNlaXB0IG9mIGFuIGF1dGhlbnRpY2F0ZWQ8bzpwPjwvbzpw Pjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBz dHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90 OyI+Jm5ic3A7ICZuYnNwO3BhY2tldCBmcm9tIHRoZSBzaW5nbGUgcmVtb3RlIHBhcnR5IGlzIGEg c3Ryb25nIGFzc3VyYW5jZSB0aGUgcGFja2V0PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+ DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiZx dW90O0FyaWFsJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPiZuYnNwOyAmbmJzcDtjYW1l IGZyb20gdGhhdCBwYXJ0eS4mbmJzcDsgSG93ZXZlciwgd2hlbiBhIHNlc3Npb24gaW52b2x2ZXMg bW9yZSB0aGFuIHR3bzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtBcmlhbCZxdW90 OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij4mbmJzcDsgJm5ic3A7cGFydGllcywgYWxsIG9mIHdo b20ga25vdyBlYWNoIG90aGVyJ3Mga2V5cywgYW55IG9mIHRob3NlIHBhcnRpZXM8bzpwPjwvbzpw Pjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBz dHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90 OyI+Jm5ic3A7ICZuYnNwO2NvdWxkIGhhdmUgc2VudCAob3Igc3Bvb2ZlZCkgdGhlIHBhY2tldC4m bmJzcDsgU3VjaCBzaGFyZWQga2V5PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2 Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O0Fy aWFsJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPiZuYnNwOyAmbmJzcDtkaXN0cmlidXRp b25zIGFyZSBwb3NzaWJsZSB3aXRoIHNvbWUgTUlLRVkgW1JGQzM4MzBdIG1vZGVzLCBTZWN1cml0 eTxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtBcmlhbCZxdW90OywmcXVvdDtzYW5z LXNlcmlmJnF1b3Q7Ij4mbmJzcDsgJm5ic3A7RGVzY3JpcHRpb25zIFtSRkM0NTY4XSwgYW5kIEVL VCBbSS1ELmlldGYtYXZ0Y29yZS1zcnRwLWVrdF0uJm5ic3A7IFRodXMsPG86cD48L286cD48L3Nw YW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9 ImZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPiZu YnNwOyAmbmJzcDtpbiBzdWNoIHNoYXJlZCBrZXlpbmcgZGlzdHJpYnV0aW9ucywgcmVjZWlwdCBv ZiBhbiBhdXRoZW50aWNhdGVkIFNSVFA8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxk aXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7 QXJpYWwmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+Jm5ic3A7ICZuYnNwO3BhY2tldCBp cyBub3Qgc3VmZmljaWVudCB0byB2ZXJpZnkgY29uc2VudC48bzpwPjwvbzpwPjwvc3Bhbj48L3A+ DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9k aXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250 LWZhbWlseTomcXVvdDtBcmlhbCZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij7igItJJ2xs IGRlZmVyIGl0IHRvIHNvbWVvbmUgd2hvIGhhcyBtb3JlIGtub3dsZWRnZSB0aGF0IG1lIG9uIHNo YXJlZCBrZXkgZGlzdHJpYnV0aW9uLi4mbmJzcDs8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWls eTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3 RCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5 bGU9Im1hcmdpbi1sZWZ0OjUuNXB0Ij48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250 LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6 IzFGNDk3RCI+W1RSXSBUaGUgaWRlYSBiZWhpbmQgdGhlIGFib3ZlIHBhcmFncmFwaCBpcyB0byB1 c2UgU1RVTiBjb25zZW50IGNoZWNrcyBpbiBib3RoIHR3byBwYXJ0eSBhbmQgbXVsdGktcGFydHkg c2Vzc2lvbnMuIENvbnNlbnQgY2hlY2tzDQogdXNlcyA8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWxlZnQ6NS41cHQiPjxzcGFuIHN0eWxl PSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7 c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj5wb2ludC10by1wb2ludCBrZXlzIHNvIHRo ZSBlbmRwb2ludCBrbm93cyBpZiBlYWNoIHJlbW90ZSBwZWVyIGluIHRoZSBjYWxsIGlzIHdpbGxp bmcgdG8gcmVjZWl2ZSB0cmFmZmljIG9yIG5vdC48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWxlZnQ6NS41cHQiPjxzcGFuIHN0eWxlPSJm b250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fu cy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWxlZnQ6NS41cHQiPjxzcGFuIHN0 eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1 b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj4tVGlydTxvOnA+PC9vOnA+PC9zcGFu PjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Jm5ic3A7 PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxibG9ja3F1b3RlIHN0eWxlPSJib3JkZXI6bm9uZTti b3JkZXItbGVmdDpzb2xpZCAjQ0NDQ0NDIDEuMHB0O3BhZGRpbmc6MGluIDBpbiAwaW4gNi4wcHQ7 bWFyZ2luLWxlZnQ6NC44cHQ7bWFyZ2luLXJpZ2h0OjBpbiI+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij48YnI+DQotIDUuMSwgM3JkIHBhcmE6ICZxdW90O0V4cGxpY2l0IGNvbnNlbnQgdG8gc2VuZCBp czxicj4NCm9idGFpbmVkLi4uJnF1b3Q7IGlzIG1pc2xlYWRpbmcuIFRoYXQgaXMgbm90IGEgY29u Y2VwdCB0aGF0PGJyPg0KYW4gaW1wbGVtZW50YXRpb24gb2YgU1RVTiB3aWxsIGVtYm9keS48bzpw PjwvbzpwPjwvcD4NCjwvYmxvY2txdW90ZT4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48 bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDssJnF1b3Q7 c2Fucy1zZXJpZiZxdW90OyI+4oCLQXMgc2FpZCBlYXJsaWVyLCBjb25zZW50IGlzIGEgbmV3IFNU VU4gdXNhZ2UuIEhvdyB3b3VsZCB0aGUgZm9sbG93aW5nPzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4N CjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LWZh bWlseTomcXVvdDtBcmlhbCZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij48bzpwPiZuYnNw OzwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48 c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDssJnF1b3Q7c2Fucy1zZXJp ZiZxdW90OyI+Jm5ic3A7ICZuYnNwOyBBbiBlbmRwb2ludCB0aGF0IGltcGxlbWVudHMgdGhpcyBz cGVjaWZpY2F0aW9uIG9idGFpbnMgYW5kIG1haW50YWlucyZuYnNwOzxvOnA+PC9vOnA+PC9zcGFu PjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJm b250LWZhbWlseTomcXVvdDtBcmlhbCZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij4mbmJz cDsgJm5ic3A7IGNvbnNlbnQgdG8gc2VuZCBieSBzZW5kaW5nIFNUVU4gYmluZGluZyByZXF1ZXN0 Li4uPG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGJsb2NrcXVvdGUg c3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci1sZWZ0OnNvbGlkICNDQ0NDQ0MgMS4wcHQ7cGFkZGlu ZzowaW4gMGluIDBpbiA2LjBwdDttYXJnaW4tbGVmdDo0LjhwdDttYXJnaW4tcmlnaHQ6MGluIj4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxicj4NCi0gNS4xLCBXaGF0IGlzIHRoZSAmcXVvdDtOb3Rl JnF1b3Q7IGFib3V0IFRDUCBmb3I/IFdoeSBpcyB0aGlzPGJyPg0KbmVlZGVkPzxvOnA+PC9vOnA+ PC9wPg0KPC9ibG9ja3F1b3RlPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5i c3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtBcmlhbCZxdW90OywmcXVvdDtzYW5zLXNl cmlmJnF1b3Q7Ij7igItJdCBpcyBuZWVkZWQgYmVjYXVzZSBXZWJSVEMgZGF0YSB0cmFmZmljIHNl bnQgb3ZlciBUQ1AgY291bGQgZ2V0IGNvbnZlcnRlZCB0byBVRFAgYnkgVFVSTiBzZXJ2ZXJzLiBJ dCBpcyBzb21ld2hhdCBzaW1pbGFyIHRvIHdoeSB3ZSBuZWVkIGFwcGxpY2F0aW9uIGxheWVyIHNl Y3VyaXR5IHdoZW4gdHJhZmZpYyBpcyBzZW50IG92ZXINCiBJUFNlYy4gVGhlIGxhdGVyIG1heSBu b3QgYmUgZW5kLXRvLWVuZC48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0K PGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1mYW1p bHk6JnF1b3Q7QXJpYWwmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+PG86cD4mbmJzcDs8 L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7LCZx dW90O3NhbnMtc2VyaWYmcXVvdDsiPk11dGh1PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+ DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2JvZHk+ DQo8L2h0bWw+DQo= --_000_913383AAA69FF945B8F946018B75898A478BCD7Exmbrcdx10ciscoc_-- From nobody Tue Aug 11 10:05:26 2015 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 68CB41ACDB7; Tue, 11 Aug 2015 10:05:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uY0aoTSKkAKB; Tue, 11 Aug 2015 10:05:19 -0700 (PDT) Received: from mail-lb0-x22b.google.com (mail-lb0-x22b.google.com [IPv6:2a00:1450:4010:c04::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 351A41ACDC6; Tue, 11 Aug 2015 10:05:15 -0700 (PDT) Received: by lbcbn3 with SMTP id bn3so22575502lbc.2; Tue, 11 Aug 2015 10:05:13 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=0cLOR3q29YeTTIXuDWdPgPvnNeO4Rh6nNzb61+4bwZk=; b=umFRw7+LvF2hXaXTRMx8MbkjVu/nIYwG542GGzDJ3U+x1VTzIvzf61DXmW4BYNyldi ZImMz2lIqSeblfIWeZapVe/7gML5MBCKYEBGP0x51uT5qjaW1zXIVSvX4yi+Qzbu3Ifb cvBO18fpXUse7jB7tmdJVXDfH+P/ldQzuQIQ8cMAg+RaX4nLqCClQ30cIj1nHMr/fKgX Nn7S6sNRY7so1svLgq1vhxZdjbuFAdBu19DhZ23kjoE9KGGmkCblk7d+2Cgyp2CZ+Vsv uhT4dB+OWXZBj0AA0JQFo4oXbiLUGyqtS0rs3mrqItnpIVPoDYYaAnkHOjjqhgi57bH8 YXKw== MIME-Version: 1.0 X-Received: by 10.152.22.133 with SMTP id d5mr20929434laf.112.1439312713651; Tue, 11 Aug 2015 10:05:13 -0700 (PDT) Received: by 10.25.162.198 with HTTP; Tue, 11 Aug 2015 10:05:13 -0700 (PDT) In-Reply-To: <913383AAA69FF945B8F946018B75898A478BCD7E@xmb-rcd-x10.cisco.com> References: <20150805223837.26225.49192.idtracker@ietfa.amsl.com> <913383AAA69FF945B8F946018B75898A478BCD7E@xmb-rcd-x10.cisco.com> Date: Tue, 11 Aug 2015 10:05:13 -0700 Message-ID: From: Martin Thomson To: "Tirumaleswar Reddy (tireddy)" Content-Type: text/plain; charset=UTF-8 Archived-At: Cc: "draft-ietf-rtcweb-stun-consent-freshness@ietf.org" , "rtcweb-chairs@ietf.org" , "draft-ietf-rtcweb-stun-consent-freshness.shepherd@ietf.org" , "rtcweb@ietf.org" , The IESG , "draft-ietf-rtcweb-stun-consent-freshness.ad@ietf.org" Subject: Re: [rtcweb] Stephen Farrell's Discuss on draft-ietf-rtcweb-stun-consent-freshness-15: (with DISCUSS and COMMENT) X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 11 Aug 2015 17:05:22 -0000 You can strike all of this: "The only human level "consent" here is that the application + developer (e.g. WebRTC browser implementer) has programmed their + application to adhere to this specification. The actual end users + who are involved in the call have not consented to anything just + because their browser uses this protocol." On 11 August 2015 at 07:31, Tirumaleswar Reddy (tireddy) wrote: > Hi Stephen, > > > > Updated draft to address your comments > https://github.com/Draft-Mafia/Consentfreshness/compare/master...rmohanr-StephenConsentFreshness, > Please have a look. > > Also see inline [TR] > > > > From: Muthu Arul Mozhi Perumal [mailto:muthu.arul@gmail.com] > Sent: Thursday, August 06, 2015 10:27 AM > To: Stephen Farrell > Cc: The IESG; draft-ietf-rtcweb-stun-consent-freshness@ietf.org; > rtcweb-chairs@ietf.org; > draft-ietf-rtcweb-stun-consent-freshness.shepherd@ietf.org; > draft-ietf-rtcweb-stun-consent-freshness.ad@ietf.org; rtcweb@ietf.org > Subject: Re: Stephen Farrell's Discuss on > draft-ietf-rtcweb-stun-consent-freshness-15: (with DISCUSS and COMMENT) > > > > Hi Stephen, > > > > On Thu, Aug 6, 2015 at 4:08 AM, Stephen Farrell > wrote: > > Stephen Farrell has entered the following ballot position for > draft-ietf-rtcweb-stun-consent-freshness-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-rtcweb-stun-consent-freshness/ > > > > ---------------------------------------------------------------------- > DISCUSS: > ---------------------------------------------------------------------- > > > > Apologies that these discuss points are maybe asking > fairly fundamental questions. That could be that this > is really the first of the new security things required > by rtcweb to get to the IESG. Or maybe I'm misreading > stuff here, if so, sorry;-) > > (1) Why call this "consent?" That term is (ab)used in > many ways on the web, and adding another variation > without a definition that distinguishes this from "click > ok to my 200 page anti-privacy policy" or "remember that > example.com is allowed use my camera/mic" seems like a > terrible idea. I also don't see how this can ever be > something to which a normal person can "consent" (i.e. > consciously agree while fully understanding) so the term > is IMO very misleading, and will I fear be used to > mislead further. (See also some of the comments below - > I do not think we ought be as fast and loose with this > aleady terribly badly used term.) To summarise: I'd love > if you did s/consent/anything-else/g but if not, please > define consent here in a way that clearly and > unambiguously distinguishes this usage from other abuses > of the term. > > > > > > [TR] Updated Consent definition. > > > > The document already has a clear and unambiguous definition of the term, > IMHO: > > > > Consent: The mechanism of obtaining permission from the remote > > endpoint to send non-ICE traffic to a remote transport address. > > Consent is obtained using ICE. > > > > Is that definition lacking something? I think finding an alter term would be > as hard as finding an alternate term for 'attack' as used in several RFCs > [attack being (ab)used in many contexts, including in heart attack ;)] > > > > > (2) WebRTC does not require STUN or TURN servers for > some calls, even if it does for many. Why is it ok to > require such a server be present in all calls (which I > think this means) espcially when that means exposing > additional meta-data (calling parties in a case where > the servers weren't needed and call duration in all > cases) to those servers when that is not always > necessary? > > > > That looks a misunderstanding. Consent freshness doesn't require such > server's to be present. Please point out to the text leading to the > misunderstanding. > > > > > (3) (end of p5) You have a MUST NOT here that is > depenedent on current browser implementations. Why is > that an IETF thing and not a W3C thing? But more > interestingly, can one securely use this protocol > without the kind of JS vs. browser sandboxing etc that's > needed in the web? > > > > Yes, the mechanism has the same security properties within and outside the > WebRTC sandboxing. > > > > If the answer is "no" then don't you > need to say that this protocol can only safely be used > for such implementations? (In section 2, which almost > but not quite says that.) > > > > Section 2 doesn't say that. It only says WebRTC is the primary use case for > the mechanism at the moment and future use cases based on similar sandboxing > models can make use of it. > > > > > (4) Cleared. > > (5) Cleared. > > > ---------------------------------------------------------------------- > COMMENT: > ---------------------------------------------------------------------- > > > (Was discuss point#4) > "Section 8: Where are these 96 bits defined? I think > this "requires..." statement needs a precise reference > to the place in some ICE/TURN/STUN RFC where it's > defined. (And I forget where that is, sorry:-) This > should be an easy fix." > Alissa gave me the reference [1] sothat's grand. It > might be an idea to make that clearer if it wasn't > just me missing it as I read, which is very possible;-) > > [1] https://tools.ietf.org/html/rfc5389#section-6 > > - abstract: why is only sending "media" mentioned here? > What about data channels? And the body of the document > in fact says this all applies to any non-ICE data and > not only media. > > > > Agree, that should be "traffic". > > > > > - intro: "initial consent to send by performing STUN" I > do not find the word consent in either rfc5245 or 3489, > but perhaps it is used somewhere else. Where? And with > what meaning? > > > > Consent is a new usage of STUN and is described in > draft-ietf-rtcweb-security-arch, draft-ietf-rtcweb-security and in this > document. > > > > > - section 4, 2nd last para - I think the conclusion is > bogus. An implementation knows when the keying it's > using can not involve >1 (nominally operating) party. > > > > That paragraph is here: > > > > When Secure Real-time Transport Protocol (SRTP) is used, the > > following considerations are applicable. SRTP is encrypted and > > authenticated with symmetric keys; that is, both sender and receiver > > know the keys. With two party sessions, receipt of an authenticated > > packet from the single remote party is a strong assurance the packet > > came from that party. However, when a session involves more than two > > parties, all of whom know each other's keys, any of those parties > > could have sent (or spoofed) the packet. Such shared key > > distributions are possible with some MIKEY [RFC3830] modes, Security > > Descriptions [RFC4568], and EKT [I-D.ietf-avtcore-srtp-ekt]. Thus, > > in such shared keying distributions, receipt of an authenticated SRTP > > packet is not sufficient to verify consent. > > > > I'll defer it to someone who has more knowledge that me on shared key > distribution.. > > > > [TR] The idea behind the above paragraph is to use STUN consent checks in > both two party and multi-party sessions. Consent checks uses > > point-to-point keys so the endpoint knows if each remote peer in the call is > willing to receive traffic or not. > > > > -Tiru > > > > > - 5.1, 3rd para: "Explicit consent to send is > obtained..." is misleading. That is not a concept that > an implementation of STUN will embody. > > > > As said earlier, consent is a new STUN usage. How would the following? > > > > An endpoint that implements this specification obtains and maintains > > consent to send by sending STUN binding request... > > > > > - 5.1, What is the "Note" about TCP for? Why is this > needed? > > > > It is needed because WebRTC data traffic sent over TCP could get converted > to UDP by TURN servers. It is somewhat similar to why we need application > layer security when traffic is sent over IPSec. The later may not be > end-to-end. > > > > Muthu From nobody Tue Aug 11 13:37:12 2015 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 69FF01B2A63 for ; Tue, 11 Aug 2015 13:37:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.909 X-Spam-Level: X-Spam-Status: No, score=-1.909 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, T_RP_MATCHES_RCVD=-0.01, WEIRD_PORT=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 Uinp_LXhz2gd for ; Tue, 11 Aug 2015 13:37:07 -0700 (PDT) Received: from lo.psyced.org (lost.in.psyced.org [188.40.42.221]) (using TLSv1 with cipher ECDHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C6B391B2A6A for ; Tue, 11 Aug 2015 13:37:04 -0700 (PDT) Received: from lo.psyced.org (localhost [127.0.0.1]) by lo.psyced.org (8.14.3/8.14.3/Debian-9.4) with ESMTP id t7BKb5Ac018893 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Tue, 11 Aug 2015 22:37:06 +0200 Received: (from lynx@localhost) by lo.psyced.org (8.14.3/8.14.3/Submit) id t7BKb58E018891 for rtcweb@ietf.org; Tue, 11 Aug 2015 22:37:05 +0200 Date: Tue, 11 Aug 2015 22:37:04 +0200 From: carlo von lynX To: rtcweb@ietf.org Message-ID: <20150811203704.GA18822@lo.psyced.org> References: <20150805161344.GA19492@lo.psyced.org> <20150805164256.GB19492@lo.psyced.org> <55C250CE.3040309@nostrum.com> <55C2AE77.6010603@matthew.at> <20150807205458.GB2091@lo.psyced.org> <55C53328.6050308@matthew.at> <20150808084638.GA12082@lo.psyced.org> <55C800F4.5080706@cs.tcd.ie> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <55C800F4.5080706@cs.tcd.ie> User-Agent: Mutt/1.5.20 (2009-06-14) Archived-At: Subject: Re: [rtcweb] LAST CALL: Systematically de-anonymize dissidents with WebRTC (HOWTO) X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 11 Aug 2015 20:37:10 -0000 On Mon, Aug 10, 2015 at 02:40:04AM +0100, Stephen Farrell wrote: > Yes. Of course we want that. People have said it >1 time. Then I need to know if there actually is a consensus on the practical recommendation of - disabling the network interface API when proxy is configured - otherwise asking user for permission to access such API And if it's just words in a working draft of something or if browser vendors will care to comply. -- E-mail is public! Talk to me in private using encryption: http://loupsycedyglgamf.onion/LynX/ irc://loupsycedyglgamf.onion:67/lynX https://psyced.org:34443/LynX/ From nobody Tue Aug 11 14:02:03 2015 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 684D51B2AAC for ; Tue, 11 Aug 2015 14:02:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.9 X-Spam-Level: X-Spam-Status: No, score=-3.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, WEIRD_PORT=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 DKEhaAyWUoFZ for ; Tue, 11 Aug 2015 14:02:00 -0700 (PDT) Received: from sessmg22.ericsson.net (sessmg22.ericsson.net [193.180.251.58]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3A2CB1B2AAF for ; Tue, 11 Aug 2015 14:02:00 -0700 (PDT) X-AuditID: c1b4fb3a-f79136d0000071e2-a2-55ca62c55d42 Received: from ESESSHC001.ericsson.se (Unknown_Domain [153.88.253.124]) by sessmg22.ericsson.net (Symantec Mail Security) with SMTP id A1.3D.29154.5C26AC55; Tue, 11 Aug 2015 23:01:58 +0200 (CEST) Received: from ESESSMB209.ericsson.se ([169.254.9.36]) by ESESSHC001.ericsson.se ([153.88.183.21]) with mapi id 14.03.0210.002; Tue, 11 Aug 2015 23:01:57 +0200 From: =?utf-8?B?R8O2cmFuIEVyaWtzc29uIEFQ?= To: carlo von lynX , "rtcweb@ietf.org" Thread-Topic: [rtcweb] LAST CALL: Systematically de-anonymize dissidents with WebRTC (HOWTO) Thread-Index: AQHQz5z/XEK/e2Y4EEOV2Qr/GVqONJ39es+AgAAXiACAAFAzgIAAH3OAgALj5oCAAByjAIAAqjMAgAKtewCAAtABAIAAKHmA Date: Tue, 11 Aug 2015 21:01:56 +0000 Message-ID: References: <20150805161344.GA19492@lo.psyced.org> <20150805164256.GB19492@lo.psyced.org> <55C250CE.3040309@nostrum.com> <55C2AE77.6010603@matthew.at> <20150807205458.GB2091@lo.psyced.org> <55C53328.6050308@matthew.at> <20150808084638.GA12082@lo.psyced.org> <55C800F4.5080706@cs.tcd.ie> <20150811203704.GA18822@lo.psyced.org> In-Reply-To: <20150811203704.GA18822@lo.psyced.org> Accept-Language: sv-SE, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.5.3.150624 x-originating-ip: [153.88.183.149] Content-Type: text/plain; charset="utf-8" Content-ID: <59181D8B76A13440A7DD5CE5CB3F026E@ericsson.com> Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFmpikeLIzCtJLcpLzFFi42KZGfG3RvdY0qlQg+bbXBZXOrYwWqz9187u wOTxv/0lq8eSJT+ZApiiuGxSUnMyy1KL9O0SuDIOfdUoWCFSMXveYdYGxifCXYycHBICJhJ3 1/5ghLDFJC7cW8/WxcjFISRwlFFi86tzTCAJIYHFjBIX51iC2GwC3hJtLYdZQGwRgSiJN78n gNUIC8RKNDdegIrHSVy58o4dws6TeLinnRnEZhFQlTj9YSfQAg4OXgFricVbcyF23WaWeLj3 LFg9p4CxxMOrp8HmMArIStz/fg/MZhYQl7j1ZD4TxKECEkv2nGeGsEUlXj7+xwpiiwroSXw6 8ZEFIq4ksfbwdhaQXcwCmhLrd+lDjLGW6D8wiRHCVpSY0v0QbC2vgKDEyZlPWCYwis9Csm0W QvcsJN2zkHTPQtK9gJF1FaNocWpxcW66kZFealFmcnFxfp5eXmrJJkZgpB3c8ttqB+PB546H GAU4GJV4eBXCT4YKsSaWFVfmHmKU5mBREuedsTkvVEggPbEkNTs1tSC1KL6oNCe1+BAjEwen VAPj8o8/LMLVzgnlfi+U/vdmw5/gQ+82P+15sqW7nqtwfYPqC5HtEVHCK2sde3eohVWc6tjB rzVN5/M92bNbfKdN+lkdxrG2V9JHQySYhe+U70PjmPbIuZFuS/8vXnjx6re2BQ8i3Jjsq0VD hA5/ebphNWviQf8dX+Zrm93Vzph6RFrNe4bODOFTSizFGYmGWsxFxYkAw0Uti5UCAAA= Archived-At: Subject: Re: [rtcweb] LAST CALL: Systematically de-anonymize dissidents with WebRTC (HOWTO) X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 11 Aug 2015 21:02:02 -0000 SGksDQoNCllvdSBoYXZlIGEgY2hvaWNlIGhlcmUgSSB0aGluazoNCg0KQSkgR28gZm9yIGEgc29s dXRpb24gZHJhZnQgZGV0YWlsaW5nIGV4YWN0bHkgaG93IHRoaXMgc2hvdWxkIGxvb2sgbGlrZS4N CllvdSBtYXkgbmVlZCB0byBjb3ZlciBib3RoIElFVEYgUlRDV0VCIFdHIGFzIHdlbGwgYXMgVzND IFdlYlJUQyBXRy4gT2Z0ZW4NCnRoaXMgcmVxdWlyZXMgYSBjb25zaWRlcmFibGUgYW1vdW50IG9m IHdvcmssIGNvbnNlbnN1cyBhbmQgb2Z0ZW4gYWxzbw0KZXhwZXJpbWVudGF0aW9uLiBOb3Qgc2F5 aW5nIHRoYXQgdGhhdCBtdXN0IGJlIHRoZSBjYXNlIGhlcmUgYnV0Li4uDQoNCkIpIE1ha2UgYW4g aW5mb3JtYXRpb25hbCBkcmFmdCBhYm91dCB0aGUgcHJvYmxlbShzKSB3aXRoIHNvbWUgZXhhbXBs ZSB1c2UNCmNhc2VzL2RlcGxveW1lbnRzLiBNYXkgYWxzbyBpbmNsdWRlIGEgY2hhcHRlciBvZiBw cm9wb3NlZCBzb2x1dGlvbnMgYXMNCmlucHV0IHRvIGRpc2N1c3Npb24uDQoNCkhhdmUgdGhpcyBx dWVzdGlvbiBzb2NpYWxpemVkL2Rpc2N1c3NlZCBhdCBJRVRGOTQgWW9rb2hhbWEuIFBlcmhhcHMg aW4gdGhlDQpSVENXZWIgV0cgb3IgdGhlIFNhYUctbWVldGluZyB1c2luZyB0aGUg4oCYZHJhZnTi gJkgYXMgaW5wdXQuDQoNCg0KSSB0aGluayBwdXR0aW5nIGRvd24gdGhpcyBkaXNjdXNzaW9uIGlu IGEgYnJpZWYgKGxlc3MgaXMgbW9yZSBZb3Uga25vdykNCmRyYWZ0IHdpbGwgYmUgaGVscGZ1bCB0 byBtb3ZlIHRoaXMgZm9yd2FyZC4NCg0KUmVnYXJkcw0KR8O2cmFuDQoNCg0KLS0tLS1PcmlnaW5h bCBNZXNzYWdlLS0tLS0NCkZyb206IHJ0Y3dlYiA8cnRjd2ViLWJvdW5jZXNAaWV0Zi5vcmc+IG9u IGJlaGFsZiBvZiBjYXJsbyB2b24gbHluWA0KPGx5blhAaS5rbm93LnlvdS5hcmUucHN5Y2VkLm9y Zz4NCkRhdGU6IFR1ZXNkYXkgMTEgQXVndXN0IDIwMTUgMjI6MzcNClRvOiBJRVRGIFJUQ1dFQiA8 cnRjd2ViQGlldGYub3JnPg0KU3ViamVjdDogUmU6IFtydGN3ZWJdIExBU1QgQ0FMTDogU3lzdGVt YXRpY2FsbHkgZGUtYW5vbnltaXplIGRpc3NpZGVudHMNCndpdGggV2ViUlRDIChIT1dUTykNCg0K Pk9uIE1vbiwgQXVnIDEwLCAyMDE1IGF0IDAyOjQwOjA0QU0gKzAxMDAsIFN0ZXBoZW4gRmFycmVs bCB3cm90ZToNCj4+IFllcy4gT2YgY291cnNlIHdlIHdhbnQgdGhhdC4gUGVvcGxlIGhhdmUgc2Fp ZCBpdCA+MSB0aW1lLg0KPg0KPlRoZW4gSSBuZWVkIHRvIGtub3cgaWYgdGhlcmUgYWN0dWFsbHkg aXMgYSBjb25zZW5zdXMgb24NCj50aGUgcHJhY3RpY2FsIHJlY29tbWVuZGF0aW9uIG9mDQo+ICAg IC0gZGlzYWJsaW5nIHRoZSBuZXR3b3JrIGludGVyZmFjZSBBUEkgd2hlbiBwcm94eSBpcyBjb25m aWd1cmVkDQo+ICAgIC0gb3RoZXJ3aXNlIGFza2luZyB1c2VyIGZvciBwZXJtaXNzaW9uIHRvIGFj Y2VzcyBzdWNoIEFQSQ0KPg0KPkFuZCBpZiBpdCdzIGp1c3Qgd29yZHMgaW4gYSB3b3JraW5nIGRy YWZ0IG9mIHNvbWV0aGluZyBvcg0KPmlmIGJyb3dzZXIgdmVuZG9ycyB3aWxsIGNhcmUgdG8gY29t cGx5Lg0KPg0KPg0KPi0tIA0KPiAgRS1tYWlsIGlzIHB1YmxpYyEgVGFsayB0byBtZSBpbiBwcml2 YXRlIHVzaW5nIGVuY3J5cHRpb246DQo+ICAgICAgICAgaHR0cDovL2xvdXBzeWNlZHlnbGdhbWYu b25pb24vTHluWC8NCj4gICAgICAgICAgaXJjOi8vbG91cHN5Y2VkeWdsZ2FtZi5vbmlvbjo2Ny9s eW5YDQo+ICAgICAgICAgaHR0cHM6Ly9wc3ljZWQub3JnOjM0NDQzL0x5blgvDQo+DQo+X19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCj5ydGN3ZWIgbWFpbGlu ZyBsaXN0DQo+cnRjd2ViQGlldGYub3JnDQo+aHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9s aXN0aW5mby9ydGN3ZWINCg0K From nobody Tue Aug 11 14:59:49 2015 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 60FC71B2AFD for ; Tue, 11 Aug 2015 14:59:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.91 X-Spam-Level: X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RTEsN1DiwvpL for ; Tue, 11 Aug 2015 14:59:46 -0700 (PDT) Received: from nostrum.com (raven-v6.nostrum.com [IPv6:2001:470:d:1130::1]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C57691A895C for ; Tue, 11 Aug 2015 14:59:46 -0700 (PDT) Received: from Orochi.local (99-152-145-110.lightspeed.dllstx.sbcglobal.net [99.152.145.110]) (authenticated bits=0) by nostrum.com (8.15.2/8.14.9) with ESMTPSA id t7BLxgo9015758 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NO); Tue, 11 Aug 2015 16:59:42 -0500 (CDT) (envelope-from adam@nostrum.com) X-Authentication-Warning: raven.nostrum.com: Host 99-152-145-110.lightspeed.dllstx.sbcglobal.net [99.152.145.110] claimed to be Orochi.local Message-ID: <55CA704D.7030902@nostrum.com> Date: Tue, 11 Aug 2015 16:59:41 -0500 From: Adam Roach User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:31.0) Gecko/20100101 Thunderbird/31.7.0 MIME-Version: 1.0 To: carlo von lynX , rtcweb@ietf.org References: <20150805161344.GA19492@lo.psyced.org> <20150805164256.GB19492@lo.psyced.org> <55C250CE.3040309@nostrum.com> <55C2AE77.6010603@matthew.at> <20150807205458.GB2091@lo.psyced.org> <55C53328.6050308@matthew.at> <20150808084638.GA12082@lo.psyced.org> <55C800F4.5080706@cs.tcd.ie> <20150811203704.GA18822@lo.psyced.org> In-Reply-To: <20150811203704.GA18822@lo.psyced.org> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [rtcweb] LAST CALL: Systematically de-anonymize dissidents with WebRTC (HOWTO) X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 11 Aug 2015 21:59:48 -0000 On 8/11/15 15:37, carlo von lynX wrote: > Then I need to know if there actually is a consensus on > the practical recommendation of > - disabling the network interface API when proxy is configured I'm not sure this has been discussed in earnest here or elsewhere. There's been some discussion of maybe pushing all RTP traffic through am HTTP proxy when one is configured [3], but this has been highly controversial. The problem is that, while HTTP proxies were designed with a number of purposes in mind -- see page 10 of [1], and section 2 of [2] -- none of them were "making it appear that a user is in a different part of the network than he really is." They can be *used* to do that (with a lot of caveats [3]), but their primary purposes lie elsewhere. What you're advocating only makes sense in the context of appearing to come from a part of the network that you're not in. It's kind of a tail-wagging-the-dog approach: if you're using proxies for their designed purpose, then this disabling is not what you want to happen. In the intended use cases, what you want is the ability to discover some kind of local TURN server that does for RTP what HTTP proxies are designed to do for HTTP (again, see section 2 of [2]). However, that raises a potentially interesting approach. One of the things we're working on in the TRAM working group is exactly this kind of TURN server discovery. If we had some means of learning this from a configured HTTP proxy (and a means of this field saying "and only use relayed candidates"), then the web browser might be able to use it as an alternate discovery mechanism. If we add this kind of discovery, then proxies that are deployed for the purposes you care about -- appearing to come from a different part of the network than the one you're in -- can point your browser to a TURN server that is colocated with the HTTP proxy. That way, WebRTC traffic will originate from the same point in the network as HTTP traffic. It also seems possible that we could include some way for this field to basically say "don't use WebRTC if you're using this proxy." > - otherwise asking user for permission to access such API Based on discussions that I've seen so far, I believe that more people oppose such a proposal than support it -- but it's not clear to me that there's consensus in either direction. It's easier to call for consensus around text in an internet-draft, though, than suggestions in an email. At the very least, it would be the first step in determining what kind of compromise might be reached. /a ____ [0] https://tools.ietf.org/html/draft-hutton-rtcweb-nat-firewall-considerations-03 [1] https://tools.ietf.org/html/rfc7230 [2] https://tools.ietf.org/html/draft-nottingham-http-proxy-problem-01 [3] For example, what would you make of a connection that originates from an IP address in Ireland, but has a date that appears to be in UTC+3:30, and a language setting of "fa-IR"? From nobody Tue Aug 11 20:06:16 2015 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 11E961A87BB; Tue, 11 Aug 2015 20:06:12 -0700 (PDT) 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, FREEMAIL_FROM=0.001, 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 Rt2PlIHfCFW9; Tue, 11 Aug 2015 20:06:05 -0700 (PDT) Received: from mail-la0-f50.google.com (mail-la0-f50.google.com [209.85.215.50]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E7EF81A87A1; Tue, 11 Aug 2015 20:06:04 -0700 (PDT) Received: by lalv9 with SMTP id v9so2106210lal.0; Tue, 11 Aug 2015 20:05:18 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=MsQsRAWHpQ5o4nXo+uEBDBsE6TvenP9pS/RA9tuX3iw=; b=a0Jl2kC5Dzg2/grXzswEAROaIFMXojxd6uDX9M1GbRNtda/A4TQns6oCtWDUYHPBaG BminHAXwa9Q2eer1mQ621tOpvRoikLk/O7b7SzB5YzZtMQaoxvhpczR/0B7XTQZejr2r ti5CL7dEoIk5Rxm9wENDBrC1TFIRmblUrHRgnnXB6xaY/HWBHsAsxK8Xbg/LFCbnDarG ffekrWt0RLExHu3Z7dCPwZ7gVe+g+iR9ohAELN2J1gbpLBXlW4uqCNEX9lIu210sHBfA gHk2OB8QKTXNlEHeU3Udb3eIXT51brEvZoLRq5fQ/W3GFqUXai93cwbI1L30HPfNho9U 0nQQ== MIME-Version: 1.0 X-Received: by 10.152.10.148 with SMTP id i20mr29552040lab.63.1439348718454; Tue, 11 Aug 2015 20:05:18 -0700 (PDT) Received: by 10.25.141.213 with HTTP; Tue, 11 Aug 2015 20:05:18 -0700 (PDT) In-Reply-To: References: <20150805223837.26225.49192.idtracker@ietfa.amsl.com> <913383AAA69FF945B8F946018B75898A478BCD7E@xmb-rcd-x10.cisco.com> Date: Wed, 12 Aug 2015 08:35:18 +0530 Message-ID: From: Muthu Arul Mozhi Perumal To: Martin Thomson Content-Type: multipart/alternative; boundary=001a11331df0124d9e051d147d43 Archived-At: Cc: "draft-ietf-rtcweb-stun-consent-freshness@ietf.org" , "rtcweb-chairs@ietf.org" , "draft-ietf-rtcweb-stun-consent-freshness.shepherd@ietf.org" , "rtcweb@ietf.org" , The IESG , "draft-ietf-rtcweb-stun-consent-freshness.ad@ietf.org" Subject: Re: [rtcweb] Stephen Farrell's Discuss on draft-ietf-rtcweb-stun-consent-freshness-15: (with DISCUSS and COMMENT) X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 12 Aug 2015 03:06:12 -0000 --001a11331df0124d9e051d147d43 Content-Type: text/plain; charset=UTF-8 +1 Rest of the changes look good to me.. thanks, Muthu On Tue, Aug 11, 2015 at 10:35 PM, Martin Thomson wrote: > You can strike all of this: > > "The only human level "consent" here is that the application + > developer (e.g. WebRTC browser implementer) has programmed their + > application to adhere to this specification. The actual end users + > who are involved in the call have not consented to anything just + > because their browser uses this protocol." > > > > On 11 August 2015 at 07:31, Tirumaleswar Reddy (tireddy) > wrote: > > Hi Stephen, > > > > > > > > Updated draft to address your comments > > > https://github.com/Draft-Mafia/Consentfreshness/compare/master...rmohanr-StephenConsentFreshness > , > > Please have a look. > > > > Also see inline [TR] > > > > > > > > From: Muthu Arul Mozhi Perumal [mailto:muthu.arul@gmail.com] > > Sent: Thursday, August 06, 2015 10:27 AM > > To: Stephen Farrell > > Cc: The IESG; draft-ietf-rtcweb-stun-consent-freshness@ietf.org; > > rtcweb-chairs@ietf.org; > > draft-ietf-rtcweb-stun-consent-freshness.shepherd@ietf.org; > > draft-ietf-rtcweb-stun-consent-freshness.ad@ietf.org; rtcweb@ietf.org > > Subject: Re: Stephen Farrell's Discuss on > > draft-ietf-rtcweb-stun-consent-freshness-15: (with DISCUSS and COMMENT) > > > > > > > > Hi Stephen, > > > > > > > > On Thu, Aug 6, 2015 at 4:08 AM, Stephen Farrell < > stephen.farrell@cs.tcd.ie> > > wrote: > > > > Stephen Farrell has entered the following ballot position for > > draft-ietf-rtcweb-stun-consent-freshness-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-rtcweb-stun-consent-freshness/ > > > > > > > > ---------------------------------------------------------------------- > > DISCUSS: > > ---------------------------------------------------------------------- > > > > > > > > Apologies that these discuss points are maybe asking > > fairly fundamental questions. That could be that this > > is really the first of the new security things required > > by rtcweb to get to the IESG. Or maybe I'm misreading > > stuff here, if so, sorry;-) > > > > (1) Why call this "consent?" That term is (ab)used in > > many ways on the web, and adding another variation > > without a definition that distinguishes this from "click > > ok to my 200 page anti-privacy policy" or "remember that > > example.com is allowed use my camera/mic" seems like a > > terrible idea. I also don't see how this can ever be > > something to which a normal person can "consent" (i.e. > > consciously agree while fully understanding) so the term > > is IMO very misleading, and will I fear be used to > > mislead further. (See also some of the comments below - > > I do not think we ought be as fast and loose with this > > aleady terribly badly used term.) To summarise: I'd love > > if you did s/consent/anything-else/g but if not, please > > define consent here in a way that clearly and > > unambiguously distinguishes this usage from other abuses > > of the term. > > > > > > > > > > > > [TR] Updated Consent definition. > > > > > > > > The document already has a clear and unambiguous definition of the term, > > IMHO: > > > > > > > > Consent: The mechanism of obtaining permission from the remote > > > > endpoint to send non-ICE traffic to a remote transport address. > > > > Consent is obtained using ICE. > > > > > > > > Is that definition lacking something? I think finding an alter term > would be > > as hard as finding an alternate term for 'attack' as used in several RFCs > > [attack being (ab)used in many contexts, including in heart attack ;)] > > > > > > > > > > (2) WebRTC does not require STUN or TURN servers for > > some calls, even if it does for many. Why is it ok to > > require such a server be present in all calls (which I > > think this means) espcially when that means exposing > > additional meta-data (calling parties in a case where > > the servers weren't needed and call duration in all > > cases) to those servers when that is not always > > necessary? > > > > > > > > That looks a misunderstanding. Consent freshness doesn't require such > > server's to be present. Please point out to the text leading to the > > misunderstanding. > > > > > > > > > > (3) (end of p5) You have a MUST NOT here that is > > depenedent on current browser implementations. Why is > > that an IETF thing and not a W3C thing? But more > > interestingly, can one securely use this protocol > > without the kind of JS vs. browser sandboxing etc that's > > needed in the web? > > > > > > > > Yes, the mechanism has the same security properties within and outside > the > > WebRTC sandboxing. > > > > > > > > If the answer is "no" then don't you > > need to say that this protocol can only safely be used > > for such implementations? (In section 2, which almost > > but not quite says that.) > > > > > > > > Section 2 doesn't say that. It only says WebRTC is the primary use case > for > > the mechanism at the moment and future use cases based on similar > sandboxing > > models can make use of it. > > > > > > > > > > (4) Cleared. > > > > (5) Cleared. > > > > > > ---------------------------------------------------------------------- > > COMMENT: > > ---------------------------------------------------------------------- > > > > > > (Was discuss point#4) > > "Section 8: Where are these 96 bits defined? I think > > this "requires..." statement needs a precise reference > > to the place in some ICE/TURN/STUN RFC where it's > > defined. (And I forget where that is, sorry:-) This > > should be an easy fix." > > Alissa gave me the reference [1] sothat's grand. It > > might be an idea to make that clearer if it wasn't > > just me missing it as I read, which is very possible;-) > > > > [1] https://tools.ietf.org/html/rfc5389#section-6 > > > > - abstract: why is only sending "media" mentioned here? > > What about data channels? And the body of the document > > in fact says this all applies to any non-ICE data and > > not only media. > > > > > > > > Agree, that should be "traffic". > > > > > > > > > > - intro: "initial consent to send by performing STUN" I > > do not find the word consent in either rfc5245 or 3489, > > but perhaps it is used somewhere else. Where? And with > > what meaning? > > > > > > > > Consent is a new usage of STUN and is described in > > draft-ietf-rtcweb-security-arch, draft-ietf-rtcweb-security and in this > > document. > > > > > > > > > > - section 4, 2nd last para - I think the conclusion is > > bogus. An implementation knows when the keying it's > > using can not involve >1 (nominally operating) party. > > > > > > > > That paragraph is here: > > > > > > > > When Secure Real-time Transport Protocol (SRTP) is used, the > > > > following considerations are applicable. SRTP is encrypted and > > > > authenticated with symmetric keys; that is, both sender and receiver > > > > know the keys. With two party sessions, receipt of an authenticated > > > > packet from the single remote party is a strong assurance the packet > > > > came from that party. However, when a session involves more than two > > > > parties, all of whom know each other's keys, any of those parties > > > > could have sent (or spoofed) the packet. Such shared key > > > > distributions are possible with some MIKEY [RFC3830] modes, Security > > > > Descriptions [RFC4568], and EKT [I-D.ietf-avtcore-srtp-ekt]. Thus, > > > > in such shared keying distributions, receipt of an authenticated SRTP > > > > packet is not sufficient to verify consent. > > > > > > > > I'll defer it to someone who has more knowledge that me on shared key > > distribution.. > > > > > > > > [TR] The idea behind the above paragraph is to use STUN consent checks in > > both two party and multi-party sessions. Consent checks uses > > > > point-to-point keys so the endpoint knows if each remote peer in the > call is > > willing to receive traffic or not. > > > > > > > > -Tiru > > > > > > > > > > - 5.1, 3rd para: "Explicit consent to send is > > obtained..." is misleading. That is not a concept that > > an implementation of STUN will embody. > > > > > > > > As said earlier, consent is a new STUN usage. How would the following? > > > > > > > > An endpoint that implements this specification obtains and maintains > > > > consent to send by sending STUN binding request... > > > > > > > > > > - 5.1, What is the "Note" about TCP for? Why is this > > needed? > > > > > > > > It is needed because WebRTC data traffic sent over TCP could get > converted > > to UDP by TURN servers. It is somewhat similar to why we need application > > layer security when traffic is sent over IPSec. The later may not be > > end-to-end. > > > > > > > > Muthu > --001a11331df0124d9e051d147d43 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
+1

Rest of the changes look good to me..

thanks,
Muthu

On Tue, Aug 11, = 2015 at 10:35 PM, Martin Thomson <martin.thomson@gmail.com><= /span> wrote:
You can strike all of this:=

"The only human level "consent" here is that the application= +
developer (e.g. WebRTC browser implementer) has programmed their +
application to adhere to this specification. The actual end users +
who are involved in the call have not consented to anything just +
because their browser uses this protocol."



On 11 August 2015 at 07:31, Tirumaleswar Reddy (tireddy)
<tireddy@cisco.com> wrote:
> Hi Stephen,
>
>
>
> Updated draft to address your comments
> https://github.com/Draft-Mafia/Consentfreshness/compare/master...rmohanr-S= tephenConsentFreshness,
> Please have a look.
>
> Also see inline [TR]
>
>
>
> From: Muthu Arul Mozhi Perumal [mailto:muthu.arul@gmail.com]
> Sent: Thursday, August 06, 2015 10:27 AM
> To: Stephen Farrell
> Cc: The IESG; draft-ietf-rtcweb-stun-consent-freshness@ietf.org;
> rtcweb-chairs@ietf.org;<= br> > draft-ietf-rtcweb-stun-consent-freshness.shepherd@ietf.org;
> draft-ietf-rtcweb-stun-consent-freshness.ad@ietf.org; rtcweb@ietf.org
> Subject: Re: Stephen Farrell's Discuss on
> draft-ietf-rtcweb-stun-consent-freshness-15: (with DISCUSS and COMMENT= )
>
>
>
> Hi Stephen,
>
>
>
> On Thu, Aug 6, 2015 at 4:08 AM, Stephen Farrell <stephen.farrell@cs.tcd.ie>
> wrote:
>
> Stephen Farrell has entered the following ballot position for
> draft-ietf-rtcweb-stun-consent-freshness-15: Discuss
>
> When responding, please keep the subject line intact and reply to all<= br> > email addresses included in the To and CC lines. (Feel free to cut thi= s
> introductory paragraph, however.)
>
>
> Please refer to https://www.ietf.org/i= esg/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.i= etf.org/doc/draft-ietf-rtcweb-stun-consent-freshness/
>
>
>
> ----------------------------------------------------------------------=
> DISCUSS:
> ----------------------------------------------------------------------=
>
>
>
> Apologies that these discuss points are maybe asking
> fairly fundamental questions.=C2=A0 That could be that this
> is really the first of the new security things required
> by rtcweb to get to the IESG.=C2=A0 Or maybe I'm misreading
> stuff here, if so, sorry;-)
>
> (1) Why call this "consent?" That term is (ab)used in
> many ways on the web, and adding another variation
> without a definition that distinguishes this from "click
> ok to my 200 page anti-privacy policy" or "remember that
> ex= ample.com is allowed use my camera/mic" seems like a
> terrible idea. I also don't see how this can ever be
> something to which a normal person can "consent" (i.e.
> consciously agree while fully understanding) so the term
> is IMO very misleading, and will I fear be used to
> mislead further.=C2=A0 (See also some of the comments below -
> I do not think we ought be as fast and loose with this
> aleady terribly badly used term.) To summarise: I'd love
> if you did s/consent/anything-else/g but if not, please
> define consent here in a way that clearly and
> unambiguously distinguishes this usage from other abuses
> of the term.
>
>
>
>
>
> [TR] Updated Consent definition.
>
>
>
> The document already has a clear and unambiguous definition of the ter= m,
> IMHO:
>
>
>
>=C2=A0 =C2=A0Consent:=C2=A0 The mechanism of obtaining permission from = the remote
>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0endpoint to send non-ICE traffic to a remote= transport address.
>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0Consent is obtained using ICE.
>
>
>
> Is that definition lacking something? I think finding an alter term wo= uld be
> as hard as finding an alternate term for 'attack' as used in s= everal RFCs
> [attack being (ab)used in many contexts, including in heart attack ;)]=
>
>
>
>
> (2) WebRTC does not require STUN or TURN servers for
> some calls, even if it does for many. Why is it ok to
> require such a server be present in all calls (which I
> think this means) espcially when that means exposing
> additional meta-data (calling parties in a case where
> the servers weren't needed and call duration in all
> cases) to those servers when that is not always
> necessary?
>
>
>
> That looks a misunderstanding. Consent freshness doesn't require s= uch
> server's to be present. Please point out to the text leading to th= e
> misunderstanding.
>
>
>
>
> (3) (end of p5) You have a MUST NOT here that is
> depenedent on current browser implementations. Why is
> that an IETF thing and not a W3C thing? But more
> interestingly, can one securely use this protocol
> without the kind of JS vs. browser sandboxing etc that's
> needed in the web?
>
>
>
> Yes, the mechanism has the same security properties within and outside= the
> WebRTC sandboxing.
>
>
>
> If the answer is "no" then don't you
> need to say that this protocol can only safely be used
> for such implementations? (In section 2, which almost
> but not quite says that.)
>
>
>
> Section 2 doesn't say that. It only says WebRTC is the primary use= case for
> the mechanism at the moment and future use cases based on similar sand= boxing
> models can make use of it.
>
>
>
>
> (4) Cleared.
>
> (5) Cleared.
>
>
> ----------------------------------------------------------------------=
> COMMENT:
> ----------------------------------------------------------------------=
>
>
> (Was discuss point#4)
> "Section 8: Where are these 96 bits defined? I think
> this "requires..." statement needs a precise reference
> to the place in some ICE/TURN/STUN RFC where it's
> defined. (And I forget where that is, sorry:-) This
> should be an easy fix."
> Alissa gave me the reference [1] sothat's grand. It
> might be an idea to make that clearer if it wasn't
> just me missing it as I read, which is very possible;-)
>
> [1] https://tools.ietf.org/html/rfc5389#section-6<= /a>
>
> - abstract: why is only sending "media" mentioned here?
> What about data channels?=C2=A0 And the body of the document
> in fact says this all applies to any non-ICE data and
> not only media.
>
>
>
> Agree, that should be "traffic".
>
>
>
>
> - intro: "initial consent to send by performing STUN" I
> do not find the word consent in either rfc5245 or 3489,
> but perhaps it is used somewhere else. Where?=C2=A0 And with
> what meaning?
>
>
>
> Consent is a new usage of STUN and is described in
> draft-ietf-rtcweb-security-arch, draft-ietf-rtcweb-security and in thi= s
> document.
>
>
>
>
> - section 4, 2nd last para - I think the conclusion is
> bogus.=C2=A0 An implementation knows when the keying it's
> using can not involve >1 (nominally operating) party.
>
>
>
> That paragraph is here:
>
>
>
>=C2=A0 =C2=A0When Secure Real-time Transport Protocol (SRTP) is used, t= he
>
>=C2=A0 =C2=A0 following considerations are applicable.=C2=A0 SRTP is en= crypted and
>
>=C2=A0 =C2=A0 authenticated with symmetric keys; that is, both sender a= nd receiver
>
>=C2=A0 =C2=A0 know the keys.=C2=A0 With two party sessions, receipt of = an authenticated
>
>=C2=A0 =C2=A0 packet from the single remote party is a strong assurance= the packet
>
>=C2=A0 =C2=A0 came from that party.=C2=A0 However, when a session invol= ves more than two
>
>=C2=A0 =C2=A0 parties, all of whom know each other's keys, any of t= hose parties
>
>=C2=A0 =C2=A0 could have sent (or spoofed) the packet.=C2=A0 Such share= d key
>
>=C2=A0 =C2=A0 distributions are possible with some MIKEY [RFC3830] mode= s, Security
>
>=C2=A0 =C2=A0 Descriptions [RFC4568], and EKT [I-D.ietf-avtcore-srtp-ek= t].=C2=A0 Thus,
>
>=C2=A0 =C2=A0 in such shared keying distributions, receipt of an authen= ticated SRTP
>
>=C2=A0 =C2=A0 packet is not sufficient to verify consent.
>
>
>
> I'll defer it to someone who has more knowledge that me on shared = key
> distribution..
>
>
>
> [TR] The idea behind the above paragraph is to use STUN consent checks= in
> both two party and multi-party sessions. Consent checks uses
>
> point-to-point keys so the endpoint knows if each remote peer in the c= all is
> willing to receive traffic or not.
>
>
>
> -Tiru
>
>
>
>
> - 5.1, 3rd para: "Explicit consent to send is
> obtained..." is misleading. That is not a concept that
> an implementation of STUN will embody.
>
>
>
> As said earlier, consent is a new STUN usage. How would the following?=
>
>
>
>=C2=A0 =C2=A0 =C2=A0An endpoint that implements this specification obta= ins and maintains
>
>=C2=A0 =C2=A0 =C2=A0consent to send by sending STUN binding request...<= br> >
>
>
>
> - 5.1, What is the "Note" about TCP for? Why is this
> needed?
>
>
>
> It is needed because WebRTC data traffic sent over TCP could get conve= rted
> to UDP by TURN servers. It is somewhat similar to why we need applicat= ion
> layer security when traffic is sent over IPSec. The later may not be > end-to-end.
>
>
>
> Muthu

--001a11331df0124d9e051d147d43-- From nobody Wed Aug 12 08:07:53 2015 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 510FB1A8837; Tue, 11 Aug 2015 20:21:23 -0700 (PDT) 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 xqTVHvWsB9pO; Tue, 11 Aug 2015 20:21:19 -0700 (PDT) Received: from rcdn-iport-5.cisco.com (rcdn-iport-5.cisco.com [173.37.86.76]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B147D1A8826; Tue, 11 Aug 2015 20:21:18 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=27961; q=dns/txt; s=iport; t=1439349679; x=1440559279; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=u50FJFAAYkRgdiM+ybe1I9oGHbR1wSGLhsmjyglwjvo=; b=iepKU9qOm/6TIaZRxtoeJSzvXtTy9hEdigKuSZtvDrS3dC1++0H5c/LC VGRXod8EVSwLwDvu+Upw+3SN5i/d56OquPrq0khxBaeU+pUTmcgRpD6Bp hZnkN+zOpnlneP9wyWWhYRUCQ3y0DMy0q/BPIuvDt2VCBPl/XPNOxxXoV s=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: A0ArAwA7u8pV/5NdJa1dgk5NVGkGvWEJgXiFLUoCgUk4FAEBAQEBAQGBCoQjAQEBBHkQAgEIEQMBAQEBIAMEByERFAkIAgQBDQWIGQMSDcoGDYVFAQEBAQEBAQEBAQEBAQEBAQEBAQEBF4tRgk+BVxEBBjoNBAcJhCMFhxyNdAGFA4V6gWyBSkaDYIMZiU+DTYNmJoIPHBWBPnEBgQ06gQQBAQE X-IronPort-AV: E=Sophos; i="5.15,658,1432598400"; d="scan'208,217"; a="19760730" Received: from rcdn-core-11.cisco.com ([173.37.93.147]) by rcdn-iport-5.cisco.com with ESMTP; 12 Aug 2015 03:21:16 +0000 Received: from XCH-ALN-015.cisco.com (xch-aln-015.cisco.com [173.36.7.25]) by rcdn-core-11.cisco.com (8.14.5/8.14.5) with ESMTP id t7C3LGV5022124 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Wed, 12 Aug 2015 03:21:16 GMT Received: from xch-aln-015.cisco.com (173.36.7.25) by XCH-ALN-015.cisco.com (173.36.7.25) with Microsoft SMTP Server (TLS) id 15.0.1104.5; Tue, 11 Aug 2015 22:21:15 -0500 Received: from xhc-aln-x08.cisco.com (173.36.12.82) by xch-aln-015.cisco.com (173.36.7.25) with Microsoft SMTP Server (TLS) id 15.0.1104.5 via Frontend Transport; Tue, 11 Aug 2015 22:21:15 -0500 Received: from xmb-aln-x05.cisco.com ([169.254.11.9]) by xhc-aln-x08.cisco.com ([173.36.12.82]) with mapi id 14.03.0248.002; Tue, 11 Aug 2015 22:21:15 -0500 From: "Ram Mohan R (rmohanr)" To: Muthu Arul Mozhi Perumal , Martin Thomson Thread-Topic: Stephen Farrell's Discuss on draft-ietf-rtcweb-stun-consent-freshness-15: (with DISCUSS and COMMENT) Thread-Index: AQHQ1K3xturUziTeo0O4VCdPhz6XSQ== Date: Wed, 12 Aug 2015 03:21:14 +0000 Message-ID: References: <20150805223837.26225.49192.idtracker@ietfa.amsl.com> <913383AAA69FF945B8F946018B75898A478BCD7E@xmb-rcd-x10.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.3.150624 x-originating-ip: [173.36.7.24] Content-Type: multipart/alternative; boundary="_000_D1F0B7F83C254rmohanrciscocom_" MIME-Version: 1.0 Archived-At: X-Mailman-Approved-At: Wed, 12 Aug 2015 08:07:52 -0700 Cc: "draft-ietf-rtcweb-stun-consent-freshness@ietf.org" , "rtcweb-chairs@ietf.org" , "draft-ietf-rtcweb-stun-consent-freshness.shepherd@ietf.org" , "rtcweb@ietf.org" , The IESG , "draft-ietf-rtcweb-stun-consent-freshness.ad@ietf.org" Subject: Re: [rtcweb] Stephen Farrell's Discuss on draft-ietf-rtcweb-stun-consent-freshness-15: (with DISCUSS and COMMENT) X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 12 Aug 2015 03:21:23 -0000 --_000_D1F0B7F83C254rmohanrciscocom_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Ok.removed that para. Here is the updated diff. https://github.com/Draft-Mafia/Consentfreshness/compare/master...rmohanr-St= ephenConsentFreshness Thanks, Ram From: Muthu Arul Mozhi Perumal > Date: Wednesday, 12 August 2015 8:35 am To: Martin Thomson > Cc: "Tirumaleswar Reddy (tireddy)" >, Stephen Farrell >, The IESG >, "draft-ietf-rtcw= eb-stun-consent-freshness@ietf.org" >, "rtcweb-chairs@ietf.= org" >, "draft-ietf-rtcweb-stun-consent-freshness.shepherd@ietf.o= rg" >, "draft-ietf-rtcweb-stun-c= onsent-freshness.ad@ietf.org" >, "rtcweb@ietf.org<= mailto:rtcweb@ietf.org>" > Subject: Re: Stephen Farrell's Discuss on draft-ietf-rtcweb-stun-consent-fr= eshness-15: (with DISCUSS and COMMENT) +1 Rest of the changes look good to me.. thanks, Muthu On Tue, Aug 11, 2015 at 10:35 PM, Martin Thomson > wrote: You can strike all of this: "The only human level "consent" here is that the application + developer (e.g. WebRTC browser implementer) has programmed their + application to adhere to this specification. The actual end users + who are involved in the call have not consented to anything just + because their browser uses this protocol." On 11 August 2015 at 07:31, Tirumaleswar Reddy (tireddy) > wrote: > Hi Stephen, > > > > Updated draft to address your comments > https://github.com/Draft-Mafia/Consentfreshness/compare/master...rmohanr-= StephenConsentFreshness, > Please have a look. > > Also see inline [TR] > > > > From: Muthu Arul Mozhi Perumal [mailto:muthu.arul@gmail.com] > Sent: Thursday, August 06, 2015 10:27 AM > To: Stephen Farrell > Cc: The IESG; draft-ietf-rtcweb-stun-consent-freshness@ietf.org; > rtcweb-chairs@ietf.org; > draft-ietf-rtcweb-stun-consent-freshness.shepherd@ietf.org; > draft-ietf-rtcweb-stun-consent-freshness.ad@ietf.org; rtcweb@ietf.org > Subject: Re: Stephen Farrell's Discuss on > draft-ietf-rtcweb-stun-consent-freshness-15: (with DISCUSS and COMMENT) > > > > Hi Stephen, > > > > On Thu, Aug 6, 2015 at 4:08 AM, Stephen Farrell > > wrote: > > Stephen Farrell has entered the following ballot position for > draft-ietf-rtcweb-stun-consent-freshness-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-rtcweb-stun-consent-freshness= / > > > > ---------------------------------------------------------------------- > DISCUSS: > ---------------------------------------------------------------------- > > > > Apologies that these discuss points are maybe asking > fairly fundamental questions. That could be that this > is really the first of the new security things required > by rtcweb to get to the IESG. Or maybe I'm misreading > stuff here, if so, sorry;-) > > (1) Why call this "consent?" That term is (ab)used in > many ways on the web, and adding another variation > without a definition that distinguishes this from "click > ok to my 200 page anti-privacy policy" or "remember that > example.com is allowed use my camera/mic" seems like = a > terrible idea. I also don't see how this can ever be > something to which a normal person can "consent" (i.e. > consciously agree while fully understanding) so the term > is IMO very misleading, and will I fear be used to > mislead further. (See also some of the comments below - > I do not think we ought be as fast and loose with this > aleady terribly badly used term.) To summarise: I'd love > if you did s/consent/anything-else/g but if not, please > define consent here in a way that clearly and > unambiguously distinguishes this usage from other abuses > of the term. > > > > > > [TR] Updated Consent definition. > > > > The document already has a clear and unambiguous definition of the term, > IMHO: > > > > Consent: The mechanism of obtaining permission from the remote > > endpoint to send non-ICE traffic to a remote transport address. > > Consent is obtained using ICE. > > > > Is that definition lacking something? I think finding an alter term would= be > as hard as finding an alternate term for 'attack' as used in several RFCs > [attack being (ab)used in many contexts, including in heart attack ;)] > > > > > (2) WebRTC does not require STUN or TURN servers for > some calls, even if it does for many. Why is it ok to > require such a server be present in all calls (which I > think this means) espcially when that means exposing > additional meta-data (calling parties in a case where > the servers weren't needed and call duration in all > cases) to those servers when that is not always > necessary? > > > > That looks a misunderstanding. Consent freshness doesn't require such > server's to be present. Please point out to the text leading to the > misunderstanding. > > > > > (3) (end of p5) You have a MUST NOT here that is > depenedent on current browser implementations. Why is > that an IETF thing and not a W3C thing? But more > interestingly, can one securely use this protocol > without the kind of JS vs. browser sandboxing etc that's > needed in the web? > > > > Yes, the mechanism has the same security properties within and outside th= e > WebRTC sandboxing. > > > > If the answer is "no" then don't you > need to say that this protocol can only safely be used > for such implementations? (In section 2, which almost > but not quite says that.) > > > > Section 2 doesn't say that. It only says WebRTC is the primary use case f= or > the mechanism at the moment and future use cases based on similar sandbox= ing > models can make use of it. > > > > > (4) Cleared. > > (5) Cleared. > > > ---------------------------------------------------------------------- > COMMENT: > ---------------------------------------------------------------------- > > > (Was discuss point#4) > "Section 8: Where are these 96 bits defined? I think > this "requires..." statement needs a precise reference > to the place in some ICE/TURN/STUN RFC where it's > defined. (And I forget where that is, sorry:-) This > should be an easy fix." > Alissa gave me the reference [1] sothat's grand. It > might be an idea to make that clearer if it wasn't > just me missing it as I read, which is very possible;-) > > [1] https://tools.ietf.org/html/rfc5389#section-6 > > - abstract: why is only sending "media" mentioned here? > What about data channels? And the body of the document > in fact says this all applies to any non-ICE data and > not only media. > > > > Agree, that should be "traffic". > > > > > - intro: "initial consent to send by performing STUN" I > do not find the word consent in either rfc5245 or 3489, > but perhaps it is used somewhere else. Where? And with > what meaning? > > > > Consent is a new usage of STUN and is described in > draft-ietf-rtcweb-security-arch, draft-ietf-rtcweb-security and in this > document. > > > > > - section 4, 2nd last para - I think the conclusion is > bogus. An implementation knows when the keying it's > using can not involve >1 (nominally operating) party. > > > > That paragraph is here: > > > > When Secure Real-time Transport Protocol (SRTP) is used, the > > following considerations are applicable. SRTP is encrypted and > > authenticated with symmetric keys; that is, both sender and receiver > > know the keys. With two party sessions, receipt of an authenticated > > packet from the single remote party is a strong assurance the packet > > came from that party. However, when a session involves more than two > > parties, all of whom know each other's keys, any of those parties > > could have sent (or spoofed) the packet. Such shared key > > distributions are possible with some MIKEY [RFC3830] modes, Security > > Descriptions [RFC4568], and EKT [I-D.ietf-avtcore-srtp-ekt]. Thus, > > in such shared keying distributions, receipt of an authenticated SRTP > > packet is not sufficient to verify consent. > > > > I'll defer it to someone who has more knowledge that me on shared key > distribution.. > > > > [TR] The idea behind the above paragraph is to use STUN consent checks in > both two party and multi-party sessions. Consent checks uses > > point-to-point keys so the endpoint knows if each remote peer in the call= is > willing to receive traffic or not. > > > > -Tiru > > > > > - 5.1, 3rd para: "Explicit consent to send is > obtained..." is misleading. That is not a concept that > an implementation of STUN will embody. > > > > As said earlier, consent is a new STUN usage. How would the following? > > > > An endpoint that implements this specification obtains and maintains > > consent to send by sending STUN binding request... > > > > > - 5.1, What is the "Note" about TCP for? Why is this > needed? > > > > It is needed because WebRTC data traffic sent over TCP could get converte= d > to UDP by TURN servers. It is somewhat similar to why we need application > layer security when traffic is sent over IPSec. The later may not be > end-to-end. > > > > Muthu --_000_D1F0B7F83C254rmohanrciscocom_ Content-Type: text/html; charset="us-ascii" Content-ID: Content-Transfer-Encoding: quoted-printable
Ok.removed that para. Here is the updated diff.

https://github.com/Draft-Mafia/Consentfreshness/compare/master...rmoha= nr-StephenConsentFreshness

Thanks,
Ram

From: Muthu Arul Mozhi Perumal <= muthu.arul@gmail.com>
Date: Wednesday, 12 August 2015 8:3= 5 am
To: Martin Thomson <martin.thomson@gmail.com>
Cc: "Tirumaleswar Reddy (tired= dy)" <tireddy@cisco.com>= ;, Stephen Farrell <stephen= .farrell@cs.tcd.ie>, The IESG <i= esg@ietf.org>, "draft-ietf-rtcweb-stun-consent-freshness@ietf.org" <draft-ietf-rtcwe= b-stun-consent-freshness@ietf.org>, "rtcweb-chairs@ietf.org" <rtcweb-chairs@ietf.org&g= t;, "draft-ietf-rtcweb-stun-consent-freshness.shepherd@ietf.org= " <draft-ietf-rtcweb-stun-consent-freshness.shepherd@ietf.org>, "draft-ietf-rtcweb-stun-consent-freshness.ad@ietf.org" <draft-i= etf-rtcweb-stun-consent-freshness.ad@ietf.org>, "rtcweb@ietf.org" <rtcweb@ietf.org>
Subject: Re: Stephen Farrell's Disc= uss on draft-ietf-rtcweb-stun-consent-freshness-15: (with DISCUSS and COMME= NT)

+1

Rest of the changes look good to me..

thanks,
Muthu

On Tue, Aug 11, 2015 at 10:35 PM, Martin Thomson= <martin.th= omson@gmail.com> wrote:
You can strike all of this:

"The only human level "consent" here is that the application= +
developer (e.g. WebRTC browser implementer) has programmed their +
application to adhere to this specification. The actual end users +
who are involved in the call have not consented to anything just +
because their browser uses this protocol."



On 11 August 2015 at 07:31, Tirumaleswar Reddy (tireddy)
<tireddy@cisco.co= m> wrote:
> Hi Stephen,
>
>
>
> Updated draft to address your comments
> https://github.com/Draft-Mafia/Consentfreshness/compare/master...rmohanr-St= ephenConsentFreshness,
> Please have a look.
>
> Also see inline [TR]
>
>
>
> From: Muthu Arul Mozhi Perumal [mailto:muthu.arul@gmail.com]
> Sent: Thursday, August 06, 2015 10:27 AM
> To: Stephen Farrell
> Cc: The IESG; draft-ietf-rtcweb-stun-consent-freshness@ietf.org;
> rtcweb-chairs@ietf.org;<= br> > draft-ietf-rtcweb-stun-consent-freshness.shepherd@ietf.org;
> draft-ietf-rtcweb-stun-consent-freshness.ad@ietf.org; rtcweb@ietf.org
> Subject: Re: Stephen Farrell's Discuss on
> draft-ietf-rtcweb-stun-consent-freshness-15: (with DISCUSS and COMMENT= )
>
>
>
> Hi Stephen,
>
>
>
> On Thu, Aug 6, 2015 at 4:08 AM, Stephen Farrell <stephen.farrell@cs.tcd.ie>
> wrote:
>
> Stephen Farrell has entered the following ballot position for
> draft-ietf-rtcweb-stun-consent-freshness-15: Discuss
>
> When responding, please keep the subject line intact and reply to all<= br> > email addresses included in the To and CC lines. (Feel free to cut thi= s
> 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-rtcweb-stun-consent-freshness/<= /a>
>
>
>
> ----------------------------------------------------------------------=
> DISCUSS:
> ----------------------------------------------------------------------=
>
>
>
> Apologies that these discuss points are maybe asking
> fairly fundamental questions.  That could be that this
> is really the first of the new security things required
> by rtcweb to get to the IESG.  Or maybe I'm misreading
> stuff here, if so, sorry;-)
>
> (1) Why call this "consent?" That term is (ab)used in
> many ways on the web, and adding another variation
> without a definition that distinguishes this from "click
> ok to my 200 page anti-privacy policy" or "remember that
> ex= ample.com is allowed use my camera/mic" seems like a
> terrible idea. I also don't see how this can ever be
> something to which a normal person can "consent" (i.e.
> consciously agree while fully understanding) so the term
> is IMO very misleading, and will I fear be used to
> mislead further.  (See also some of the comments below -
> I do not think we ought be as fast and loose with this
> aleady terribly badly used term.) To summarise: I'd love
> if you did s/consent/anything-else/g but if not, please
> define consent here in a way that clearly and
> unambiguously distinguishes this usage from other abuses
> of the term.
>
>
>
>
>
> [TR] Updated Consent definition.
>
>
>
> The document already has a clear and unambiguous definition of the ter= m,
> IMHO:
>
>
>
>   Consent:  The mechanism of obtaining permission from = the remote
>
>       endpoint to send non-ICE traffic to a remote= transport address.
>
>       Consent is obtained using ICE.
>
>
>
> Is that definition lacking something? I think finding an alter term wo= uld be
> as hard as finding an alternate term for 'attack' as used in several R= FCs
> [attack being (ab)used in many contexts, including in heart attack ;)]=
>
>
>
>
> (2) WebRTC does not require STUN or TURN servers for
> some calls, even if it does for many. Why is it ok to
> require such a server be present in all calls (which I
> think this means) espcially when that means exposing
> additional meta-data (calling parties in a case where
> the servers weren't needed and call duration in all
> cases) to those servers when that is not always
> necessary?
>
>
>
> That looks a misunderstanding. Consent freshness doesn't require such<= br> > server's to be present. Please point out to the text leading to the > misunderstanding.
>
>
>
>
> (3) (end of p5) You have a MUST NOT here that is
> depenedent on current browser implementations. Why is
> that an IETF thing and not a W3C thing? But more
> interestingly, can one securely use this protocol
> without the kind of JS vs. browser sandboxing etc that's
> needed in the web?
>
>
>
> Yes, the mechanism has the same security properties within and outside= the
> WebRTC sandboxing.
>
>
>
> If the answer is "no" then don't you
> need to say that this protocol can only safely be used
> for such implementations? (In section 2, which almost
> but not quite says that.)
>
>
>
> Section 2 doesn't say that. It only says WebRTC is the primary use cas= e for
> the mechanism at the moment and future use cases based on similar sand= boxing
> models can make use of it.
>
>
>
>
> (4) Cleared.
>
> (5) Cleared.
>
>
> ----------------------------------------------------------------------=
> COMMENT:
> ----------------------------------------------------------------------=
>
>
> (Was discuss point#4)
> "Section 8: Where are these 96 bits defined? I think
> this "requires..." statement needs a precise reference
> to the place in some ICE/TURN/STUN RFC where it's
> defined. (And I forget where that is, sorry:-) This
> should be an easy fix."
> Alissa gave me the reference [1] sothat's grand. It
> might be an idea to make that clearer if it wasn't
> just me missing it as I read, which is very possible;-)
>
> [1] https://tools.ietf.org/html/rfc5389#section-6
>
> - abstract: why is only sending "media" mentioned here?
> What about data channels?  And the body of the document
> in fact says this all applies to any non-ICE data and
> not only media.
>
>
>
> Agree, that should be "traffic".
>
>
>
>
> - intro: "initial consent to send by performing STUN" I
> do not find the word consent in either rfc5245 or 3489,
> but perhaps it is used somewhere else. Where?  And with
> what meaning?
>
>
>
> Consent is a new usage of STUN and is described in
> draft-ietf-rtcweb-security-arch, draft-ietf-rtcweb-security and in thi= s
> document.
>
>
>
>
> - section 4, 2nd last para - I think the conclusion is
> bogus.  An implementation knows when the keying it's
> using can not involve >1 (nominally operating) party.
>
>
>
> That paragraph is here:
>
>
>
>   When Secure Real-time Transport Protocol (SRTP) is used, t= he
>
>    following considerations are applicable.  SRTP is en= crypted and
>
>    authenticated with symmetric keys; that is, both sender a= nd receiver
>
>    know the keys.  With two party sessions, receipt of = an authenticated
>
>    packet from the single remote party is a strong assurance= the packet
>
>    came from that party.  However, when a session invol= ves more than two
>
>    parties, all of whom know each other's keys, any of those= parties
>
>    could have sent (or spoofed) the packet.  Such share= d key
>
>    distributions are possible with some MIKEY [RFC3830] mode= s, Security
>
>    Descriptions [RFC4568], and EKT [I-D.ietf-avtcore-srtp-ek= t].  Thus,
>
>    in such shared keying distributions, receipt of an authen= ticated SRTP
>
>    packet is not sufficient to verify consent.
>
>
>
> I'll defer it to someone who has more knowledge that me on shared key<= br> > distribution..
>
>
>
> [TR] The idea behind the above paragraph is to use STUN consent checks= in
> both two party and multi-party sessions. Consent checks uses
>
> point-to-point keys so the endpoint knows if each remote peer in the c= all is
> willing to receive traffic or not.
>
>
>
> -Tiru
>
>
>
>
> - 5.1, 3rd para: "Explicit consent to send is
> obtained..." is misleading. That is not a concept that
> an implementation of STUN will embody.
>
>
>
> As said earlier, consent is a new STUN usage. How would the following?=
>
>
>
>     An endpoint that implements this specification obta= ins and maintains
>
>     consent to send by sending STUN binding request...<= br> >
>
>
>
> - 5.1, What is the "Note" about TCP for? Why is this
> needed?
>
>
>
> It is needed because WebRTC data traffic sent over TCP could get conve= rted
> to UDP by TURN servers. It is somewhat similar to why we need applicat= ion
> layer security when traffic is sent over IPSec. The later may not be > end-to-end.
>
>
>
> Muthu

--_000_D1F0B7F83C254rmohanrciscocom_-- From nobody Thu Aug 13 07:12:30 2015 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5FDDF1B3909; Thu, 13 Aug 2015 07:12:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Ph2OQL2win0s; Thu, 13 Aug 2015 07:12:27 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 782221B38FE; Thu, 13 Aug 2015 07:11:38 -0700 (PDT) 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.4.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20150813141138.20318.32082.idtracker@ietfa.amsl.com> Date: Thu, 13 Aug 2015 07:11:38 -0700 Archived-At: Cc: rtcweb@ietf.org Subject: [rtcweb] I-D Action: draft-ietf-rtcweb-stun-consent-freshness-16.txt X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 13 Aug 2015 14:12:28 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Real-Time Communication in WEB-browsers Working Group of the IETF. Title : STUN Usage for Consent Freshness Authors : Muthu Arul Mozhi Perumal Dan Wing Ram Mohan Ravindranath Tirumaleswar Reddy Martin Thomson Filename : draft-ietf-rtcweb-stun-consent-freshness-16.txt Pages : 10 Date : 2015-08-13 Abstract: To prevent WebRTC applications, such as browsers, from launching attacks by sending traffic to unwilling victims, periodic consent to send needs to be obtained from remote endpoints. This document describes a consent mechanism using a new Session Traversal Utilities for NAT (STUN) usage. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-rtcweb-stun-consent-freshness/ There's also a htmlized version available at: https://tools.ietf.org/html/draft-ietf-rtcweb-stun-consent-freshness-16 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-rtcweb-stun-consent-freshness-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 Thu Aug 13 07:15:42 2015 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1B2671B3964; Thu, 13 Aug 2015 07:15:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -13.911 X-Spam-Level: X-Spam-Status: No, score=-13.911 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, J_CHICKENPOX_27=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 I_AcCP_d3uIB; Thu, 13 Aug 2015 07:15:38 -0700 (PDT) Received: from rcdn-iport-4.cisco.com (rcdn-iport-4.cisco.com [173.37.86.75]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1EDCF1B38E0; Thu, 13 Aug 2015 07:13:34 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=13098; q=dns/txt; s=iport; t=1439475214; x=1440684814; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=TDMrFCeFu5BRhAtArjmT4rquDe64ygk9n+30nQgxCPA=; b=ZSYzQQvwrRiNqcuHINs5TDQuk/x1j4BFZ8SsyxxrRQ/hCu2j1UIvqJXX pwvbIFQvSm1OU3sS/hJz8Vj4zcy0Q8s6BXRQnlgLFkhEY08Xjq+8GVx2t MtqM7glLGHvncqiXC0fpS/rWgRuFO8/4XFvAUJ4KusTwrVLrx4gDpL3EJ s=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: A0B1AgAJpcxV/4oNJK1dgxtUaQa9egEJgXeFLUoCgTw4FAEBAQEBAQGBCoQjAQEBBDo/DAQCAQgRAwEBAQEeBQQHIREUCQgCBA4FiBkDEg3LUA2FUwEBAQEBAQEBAQEBAQEBAQEBAQEBAReLU4JPgVcRAQZLAgUGhCYFhx2NfQGFA4V7gW2BSkaDZYMZiV6DT4NnJoIOHBWBPnEBgQ06gQQBAQE X-IronPort-AV: E=Sophos;i="5.15,670,1432598400"; d="scan'208";a="20212356" Received: from alln-core-5.cisco.com ([173.36.13.138]) by rcdn-iport-4.cisco.com with ESMTP; 13 Aug 2015 14:13:32 +0000 Received: from XCH-RCD-010.cisco.com (xch-rcd-010.cisco.com [173.37.102.20]) by alln-core-5.cisco.com (8.14.5/8.14.5) with ESMTP id t7DEDWUu018435 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Thu, 13 Aug 2015 14:13:32 GMT Received: from xch-rcd-010.cisco.com (173.37.102.20) by XCH-RCD-010.cisco.com (173.37.102.20) with Microsoft SMTP Server (TLS) id 15.0.1104.5; Thu, 13 Aug 2015 09:13:31 -0500 Received: from xhc-rcd-x15.cisco.com (173.37.183.89) by xch-rcd-010.cisco.com (173.37.102.20) with Microsoft SMTP Server (TLS) id 15.0.1104.5 via Frontend Transport; Thu, 13 Aug 2015 09:13:31 -0500 Received: from xmb-aln-x05.cisco.com ([169.254.11.9]) by xhc-rcd-x15.cisco.com ([173.37.183.89]) with mapi id 14.03.0248.002; Thu, 13 Aug 2015 09:13:31 -0500 From: "Ram Mohan R (rmohanr)" To: Stephen Farrell Thread-Topic: Stephen Farrell's Discuss on draft-ietf-rtcweb-stun-consent-freshness-15: (with DISCUSS and COMMENT) Thread-Index: AQHQ1dI7DObEBXFEYUSbDl2WILxRTw== Date: Thu, 13 Aug 2015 14:13:30 +0000 Message-ID: References: <20150805223837.26225.49192.idtracker@ietfa.amsl.com> <913383AAA69FF945B8F946018B75898A478BCD7E@xmb-rcd-x10.cisco.com> <55CC9502.4080909@cs.tcd.ie> In-Reply-To: <55CC9502.4080909@cs.tcd.ie> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.5.3.150624 x-originating-ip: [173.36.7.16] Content-Type: text/plain; charset="us-ascii" Content-ID: <3CD830D4D6ED4240B711529446A76E5F@emea.cisco.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Cc: "draft-ietf-rtcweb-stun-consent-freshness@ietf.org" , "rtcweb-chairs@ietf.org" , "draft-ietf-rtcweb-stun-consent-freshness.shepherd@ietf.org" , "rtcweb@ietf.org" , The IESG , "draft-ietf-rtcweb-stun-consent-freshness.ad@ietf.org" Subject: Re: [rtcweb] Stephen Farrell's Discuss on draft-ietf-rtcweb-stun-consent-freshness-15: (with DISCUSS and COMMENT) X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 13 Aug 2015 14:15:41 -0000 Hi Stephen, Thanks for your review. Here is the new revision with the below diffs published. https://datatracker.ietf.org/doc/draft-ietf-rtcweb-stun-consent-freshness/ Regards, Ram -----Original Message----- From: Stephen Farrell Date: Thursday, 13 August 2015 6:30 pm To: Cisco Employee , Muthu Arul Mozhi Perumal , Martin Thomson Cc: "Tirumaleswar Reddy (tireddy)" , The IESG , "draft-ietf-rtcweb-stun-consent-freshness@ietf.org" , "rtcweb-chairs@ietf.org" , "draft-ietf-rtcweb-stun-consent-freshness.shepherd@ietf.org" , "draft-ietf-rtcweb-stun-consent-freshness.ad@ietf.org" , "rtcweb@ietf.org" Subject: Re: Stephen Farrell's Discuss on draft-ietf-rtcweb-stun-consent-freshness-15: (with DISCUSS and COMMENT) > >Hi Folks, > >Sorry for being slow, but I've now had another read of the draft >and if you submit those changes I'll be fine to clear. > >Thanks, >S. > > >On 12/08/15 04:21, Ram Mohan R (rmohanr) wrote: >> Ok.removed that para. Here is the updated diff. >>=20 >>=20 >>https://github.com/Draft-Mafia/Consentfreshness/compare/master...rmohanr- >>StephenConsentFreshness >>=20 >> Thanks, >> Ram >>=20 >> From: Muthu Arul Mozhi Perumal >>> >> Date: Wednesday, 12 August 2015 8:35 am >> To: Martin Thomson >>> >> Cc: "Tirumaleswar Reddy (tireddy)" >>>, Stephen Farrell >>>, The IESG >>>, >>"draft-ietf-rtcweb-stun-consent-freshness@ietf.org>eb-stun-consent-freshness@ietf.org>" >>>eb-stun-consent-freshness@ietf.org>>, >>"rtcweb-chairs@ietf.org" >>>, >>"draft-ietf-rtcweb-stun-consent-freshness.shepherd@ietf.org>ietf-rtcweb-stun-consent-freshness.shepherd@ietf.org>" >>>ietf-rtcweb-stun-consent-freshness.shepherd@ietf.org>>, >>"draft-ietf-rtcweb-stun-consent-freshness.ad@ietf.org>tcweb-stun-consent-freshness.ad@ietf.org>" >>>tcweb-s > t >un-consent-freshness.ad@ietf.org>>, >"rtcweb@ietf.org" >> >> Subject: Re: Stephen Farrell's Discuss on >>draft-ietf-rtcweb-stun-consent-freshness-15: (with DISCUSS and COMMENT) >>=20 >> +1 >>=20 >> Rest of the changes look good to me.. >>=20 >> thanks, >> Muthu >>=20 >> On Tue, Aug 11, 2015 at 10:35 PM, Martin Thomson >>> wrote: >> You can strike all of this: >>=20 >> "The only human level "consent" here is that the application + >> developer (e.g. WebRTC browser implementer) has programmed their + >> application to adhere to this specification. The actual end users + >> who are involved in the call have not consented to anything just + >> because their browser uses this protocol." >>=20 >>=20 >>=20 >> On 11 August 2015 at 07:31, Tirumaleswar Reddy (tireddy) >> > wrote: >>> Hi Stephen, >>> >>> >>> >>> Updated draft to address your comments >>>=20 >>>https://github.com/Draft-Mafia/Consentfreshness/compare/master...rmohanr >>>-StephenConsentFreshness, >>> Please have a look. >>> >>> Also see inline [TR] >>> >>> >>> >>> From: Muthu Arul Mozhi Perumal >>>[mailto:muthu.arul@gmail.com] >>> Sent: Thursday, August 06, 2015 10:27 AM >>> To: Stephen Farrell >>> Cc: The IESG;=20 >>>draft-ietf-rtcweb-stun-consent-freshness@ietf.org>>eb-stun-consent-freshness@ietf.org>; >>> rtcweb-chairs@ietf.org; >>>=20 >>>draft-ietf-rtcweb-stun-consent-freshness.shepherd@ietf.org>>ietf-rtcweb-stun-consent-freshness.shepherd@ietf.org>; >>>=20 >>>draft-ietf-rtcweb-stun-consent-freshness.ad@ietf.org>>tcweb-stun-consent-freshness.ad@ietf.org>; >>>rtcweb@ietf.org >>> Subject: Re: Stephen Farrell's Discuss on >>> draft-ietf-rtcweb-stun-consent-freshness-15: (with DISCUSS and COMMENT) >>> >>> >>> >>> Hi Stephen, >>> >>> >>> >>> On Thu, Aug 6, 2015 at 4:08 AM, Stephen Farrell >>>> >>> wrote: >>> >>> Stephen Farrell has entered the following ballot position for >>> draft-ietf-rtcweb-stun-consent-freshness-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: >>>=20 >>>https://datatracker.ietf.org/doc/draft-ietf-rtcweb-stun-consent-freshnes >>>s/ >>> >>> >>> >>> ---------------------------------------------------------------------- >>> DISCUSS: >>> ---------------------------------------------------------------------- >>> >>> >>> >>> Apologies that these discuss points are maybe asking >>> fairly fundamental questions. That could be that this >>> is really the first of the new security things required >>> by rtcweb to get to the IESG. Or maybe I'm misreading >>> stuff here, if so, sorry;-) >>> >>> (1) Why call this "consent?" That term is (ab)used in >>> many ways on the web, and adding another variation >>> without a definition that distinguishes this from "click >>> ok to my 200 page anti-privacy policy" or "remember that >>> example.com is allowed use my camera/mic" seems >>>like a >>> terrible idea. I also don't see how this can ever be >>> something to which a normal person can "consent" (i.e. >>> consciously agree while fully understanding) so the term >>> is IMO very misleading, and will I fear be used to >>> mislead further. (See also some of the comments below - >>> I do not think we ought be as fast and loose with this >>> aleady terribly badly used term.) To summarise: I'd love >>> if you did s/consent/anything-else/g but if not, please >>> define consent here in a way that clearly and >>> unambiguously distinguishes this usage from other abuses >>> of the term. >>> >>> >>> >>> >>> >>> [TR] Updated Consent definition. >>> >>> >>> >>> The document already has a clear and unambiguous definition of the >>>term, >>> IMHO: >>> >>> >>> >>> Consent: The mechanism of obtaining permission from the remote >>> >>> endpoint to send non-ICE traffic to a remote transport address. >>> >>> Consent is obtained using ICE. >>> >>> >>> >>> Is that definition lacking something? I think finding an alter term >>>would be >>> as hard as finding an alternate term for 'attack' as used in several >>>RFCs >>> [attack being (ab)used in many contexts, including in heart attack ;)] >>> >>> >>> >>> >>> (2) WebRTC does not require STUN or TURN servers for >>> some calls, even if it does for many. Why is it ok to >>> require such a server be present in all calls (which I >>> think this means) espcially when that means exposing >>> additional meta-data (calling parties in a case where >>> the servers weren't needed and call duration in all >>> cases) to those servers when that is not always >>> necessary? >>> >>> >>> >>> That looks a misunderstanding. Consent freshness doesn't require such >>> server's to be present. Please point out to the text leading to the >>> misunderstanding. >>> >>> >>> >>> >>> (3) (end of p5) You have a MUST NOT here that is >>> depenedent on current browser implementations. Why is >>> that an IETF thing and not a W3C thing? But more >>> interestingly, can one securely use this protocol >>> without the kind of JS vs. browser sandboxing etc that's >>> needed in the web? >>> >>> >>> >>> Yes, the mechanism has the same security properties within and outside >>>the >>> WebRTC sandboxing. >>> >>> >>> >>> If the answer is "no" then don't you >>> need to say that this protocol can only safely be used >>> for such implementations? (In section 2, which almost >>> but not quite says that.) >>> >>> >>> >>> Section 2 doesn't say that. It only says WebRTC is the primary use >>>case for >>> the mechanism at the moment and future use cases based on similar >>>sandboxing >>> models can make use of it. >>> >>> >>> >>> >>> (4) Cleared. >>> >>> (5) Cleared. >>> >>> >>> ---------------------------------------------------------------------- >>> COMMENT: >>> ---------------------------------------------------------------------- >>> >>> >>> (Was discuss point#4) >>> "Section 8: Where are these 96 bits defined? I think >>> this "requires..." statement needs a precise reference >>> to the place in some ICE/TURN/STUN RFC where it's >>> defined. (And I forget where that is, sorry:-) This >>> should be an easy fix." >>> Alissa gave me the reference [1] sothat's grand. It >>> might be an idea to make that clearer if it wasn't >>> just me missing it as I read, which is very possible;-) >>> >>> [1] https://tools.ietf.org/html/rfc5389#section-6 >>> >>> - abstract: why is only sending "media" mentioned here? >>> What about data channels? And the body of the document >>> in fact says this all applies to any non-ICE data and >>> not only media. >>> >>> >>> >>> Agree, that should be "traffic". >>> >>> >>> >>> >>> - intro: "initial consent to send by performing STUN" I >>> do not find the word consent in either rfc5245 or 3489, >>> but perhaps it is used somewhere else. Where? And with >>> what meaning? >>> >>> >>> >>> Consent is a new usage of STUN and is described in >>> draft-ietf-rtcweb-security-arch, draft-ietf-rtcweb-security and in this >>> document. >>> >>> >>> >>> >>> - section 4, 2nd last para - I think the conclusion is >>> bogus. An implementation knows when the keying it's >>> using can not involve >1 (nominally operating) party. >>> >>> >>> >>> That paragraph is here: >>> >>> >>> >>> When Secure Real-time Transport Protocol (SRTP) is used, the >>> >>> following considerations are applicable. SRTP is encrypted and >>> >>> authenticated with symmetric keys; that is, both sender and receiver >>> >>> know the keys. With two party sessions, receipt of an authenticated >>> >>> packet from the single remote party is a strong assurance the packet >>> >>> came from that party. However, when a session involves more than >>>two >>> >>> parties, all of whom know each other's keys, any of those parties >>> >>> could have sent (or spoofed) the packet. Such shared key >>> >>> distributions are possible with some MIKEY [RFC3830] modes, Security >>> >>> Descriptions [RFC4568], and EKT [I-D.ietf-avtcore-srtp-ekt]. Thus, >>> >>> in such shared keying distributions, receipt of an authenticated >>>SRTP >>> >>> packet is not sufficient to verify consent. >>> >>> >>> >>> I'll defer it to someone who has more knowledge that me on shared key >>> distribution.. >>> >>> >>> >>> [TR] The idea behind the above paragraph is to use STUN consent checks >>>in >>> both two party and multi-party sessions. Consent checks uses >>> >>> point-to-point keys so the endpoint knows if each remote peer in the >>>call is >>> willing to receive traffic or not. >>> >>> >>> >>> -Tiru >>> >>> >>> >>> >>> - 5.1, 3rd para: "Explicit consent to send is >>> obtained..." is misleading. That is not a concept that >>> an implementation of STUN will embody. >>> >>> >>> >>> As said earlier, consent is a new STUN usage. How would the following? >>> >>> >>> >>> An endpoint that implements this specification obtains and >>>maintains >>> >>> consent to send by sending STUN binding request... >>> >>> >>> >>> >>> - 5.1, What is the "Note" about TCP for? Why is this >>> needed? >>> >>> >>> >>> It is needed because WebRTC data traffic sent over TCP could get >>>converted >>> to UDP by TURN servers. It is somewhat similar to why we need >>>application >>> layer security when traffic is sent over IPSec. The later may not be >>> end-to-end. >>> >>> >>> >>> Muthu >>=20 >>=20 From nobody Thu Aug 13 09:37:52 2015 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 69B461A0264; Thu, 13 Aug 2015 09:37:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id c5y7JJz_g47S; Thu, 13 Aug 2015 09:37:49 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 370B71A01F4; Thu, 13 Aug 2015 09:37:49 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "Stephen Farrell" To: "The IESG" X-Test-IDTracker: no X-IETF-IDTracker: 6.4.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20150813163749.3719.31044.idtracker@ietfa.amsl.com> Date: Thu, 13 Aug 2015 09:37:49 -0700 Archived-At: Cc: draft-ietf-rtcweb-stun-consent-freshness.ad@ietf.org, rtcweb@ietf.org, draft-ietf-rtcweb-stun-consent-freshness@ietf.org, rtcweb-chairs@ietf.org, draft-ietf-rtcweb-stun-consent-freshness.shepherd@ietf.org Subject: [rtcweb] Stephen Farrell's No Objection on draft-ietf-rtcweb-stun-consent-freshness-16: (with COMMENT) X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 13 Aug 2015 16:37:50 -0000 Stephen Farrell has entered the following ballot position for draft-ietf-rtcweb-stun-consent-freshness-16: 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-rtcweb-stun-consent-freshness/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- Thanks for putting up with my partly silly discuss/comments. From nobody Thu Aug 13 10:08:12 2015 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9558D1A1BAE; Thu, 13 Aug 2015 06:00:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.501 X-Spam-Level: X-Spam-Status: No, score=-3.501 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, J_CHICKENPOX_27=0.6, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_DKIM_INVALID=0.01, 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 v_ZFk2UOMXJM; Thu, 13 Aug 2015 06:00:55 -0700 (PDT) Received: from mercury.scss.tcd.ie (mercury.scss.tcd.ie [134.226.56.6]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 90F7E1A1BAF; Thu, 13 Aug 2015 06:00:54 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id 57780BEC6; Thu, 13 Aug 2015 14:00:53 +0100 (IST) X-Virus-Scanned: Debian amavisd-new at scss.tcd.ie Received: from mercury.scss.tcd.ie ([127.0.0.1]) by localhost (mercury.scss.tcd.ie [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4rdNBjNHBZfJ; Thu, 13 Aug 2015 14:00:50 +0100 (IST) Received: from [10.87.48.73] (unknown [86.46.29.218]) by mercury.scss.tcd.ie (Postfix) with ESMTPSA id 8430DBEA0; Thu, 13 Aug 2015 14:00:50 +0100 (IST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cs.tcd.ie; s=mail; t=1439470850; bh=L4FJ3HHwZJtDTH2c6MKIaocclpSMdISDD7Ua7iM7VHg=; h=Date:From:To:CC:Subject:References:In-Reply-To:From; b=p3mp1WWD8rLMwMZZdNrZ8jQUeYh4E1vxsmi2UbDgbpiRPJFmOkahNF6USVoTv0SON ILdn7tmA5O+TIUmt3kbIajRnbTCV5RN8Mz/7lqOy6uX9fhzU7zXFlY3xCH1vkg6s45 WawiYBHAIoHz/C+INZiPHUuT76V8DFAgNrzJ7xuY= Message-ID: <55CC9502.4080909@cs.tcd.ie> Date: Thu, 13 Aug 2015 14:00:50 +0100 From: Stephen Farrell User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.8.0 MIME-Version: 1.0 To: "Ram Mohan R (rmohanr)" , Muthu Arul Mozhi Perumal , Martin Thomson References: <20150805223837.26225.49192.idtracker@ietfa.amsl.com> <913383AAA69FF945B8F946018B75898A478BCD7E@xmb-rcd-x10.cisco.com> In-Reply-To: OpenPGP: id=D66EA7906F0B897FB2E97D582F3C8736805F8DA2; url= Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Archived-At: X-Mailman-Approved-At: Thu, 13 Aug 2015 10:08:10 -0700 Cc: "draft-ietf-rtcweb-stun-consent-freshness@ietf.org" , "rtcweb-chairs@ietf.org" , "draft-ietf-rtcweb-stun-consent-freshness.shepherd@ietf.org" , "rtcweb@ietf.org" , The IESG , "draft-ietf-rtcweb-stun-consent-freshness.ad@ietf.org" Subject: Re: [rtcweb] Stephen Farrell's Discuss on draft-ietf-rtcweb-stun-consent-freshness-15: (with DISCUSS and COMMENT) X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 13 Aug 2015 13:00:58 -0000 Hi Folks, Sorry for being slow, but I've now had another read of the draft and if you submit those changes I'll be fine to clear. Thanks, S. On 12/08/15 04:21, Ram Mohan R (rmohanr) wrote: > Ok.removed that para. Here is the updated diff. > > https://github.com/Draft-Mafia/Consentfreshness/compare/master...rmohanr-StephenConsentFreshness > > Thanks, > Ram > > From: Muthu Arul Mozhi Perumal > > Date: Wednesday, 12 August 2015 8:35 am > To: Martin Thomson > > Cc: "Tirumaleswar Reddy (tireddy)" >, Stephen Farrell >, The IESG >, "draft-ietf-rtcweb-stun-consent-freshness@ietf.org" >, "rtcweb-chairs@ietf.org" >, "draft-ietf-rtcweb-stun-consent-freshness.shepherd@ietf.org" >, "draft-ietf-rtcweb-stun-consent-freshness.ad@ietf.org" >, "rtcweb@ietf.org" > > Subject: Re: Stephen Farrell's Discuss on draft-ietf-rtcweb-stun-consent-freshness-15: (with DISCUSS and COMMENT) > > +1 > > Rest of the changes look good to me.. > > thanks, > Muthu > > On Tue, Aug 11, 2015 at 10:35 PM, Martin Thomson > wrote: > You can strike all of this: > > "The only human level "consent" here is that the application + > developer (e.g. WebRTC browser implementer) has programmed their + > application to adhere to this specification. The actual end users + > who are involved in the call have not consented to anything just + > because their browser uses this protocol." > > > > On 11 August 2015 at 07:31, Tirumaleswar Reddy (tireddy) > > wrote: >> Hi Stephen, >> >> >> >> Updated draft to address your comments >> https://github.com/Draft-Mafia/Consentfreshness/compare/master...rmohanr-StephenConsentFreshness, >> Please have a look. >> >> Also see inline [TR] >> >> >> >> From: Muthu Arul Mozhi Perumal [mailto:muthu.arul@gmail.com] >> Sent: Thursday, August 06, 2015 10:27 AM >> To: Stephen Farrell >> Cc: The IESG; draft-ietf-rtcweb-stun-consent-freshness@ietf.org; >> rtcweb-chairs@ietf.org; >> draft-ietf-rtcweb-stun-consent-freshness.shepherd@ietf.org; >> draft-ietf-rtcweb-stun-consent-freshness.ad@ietf.org; rtcweb@ietf.org >> Subject: Re: Stephen Farrell's Discuss on >> draft-ietf-rtcweb-stun-consent-freshness-15: (with DISCUSS and COMMENT) >> >> >> >> Hi Stephen, >> >> >> >> On Thu, Aug 6, 2015 at 4:08 AM, Stephen Farrell > >> wrote: >> >> Stephen Farrell has entered the following ballot position for >> draft-ietf-rtcweb-stun-consent-freshness-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-rtcweb-stun-consent-freshness/ >> >> >> >> ---------------------------------------------------------------------- >> DISCUSS: >> ---------------------------------------------------------------------- >> >> >> >> Apologies that these discuss points are maybe asking >> fairly fundamental questions. That could be that this >> is really the first of the new security things required >> by rtcweb to get to the IESG. Or maybe I'm misreading >> stuff here, if so, sorry;-) >> >> (1) Why call this "consent?" That term is (ab)used in >> many ways on the web, and adding another variation >> without a definition that distinguishes this from "click >> ok to my 200 page anti-privacy policy" or "remember that >> example.com is allowed use my camera/mic" seems like a >> terrible idea. I also don't see how this can ever be >> something to which a normal person can "consent" (i.e. >> consciously agree while fully understanding) so the term >> is IMO very misleading, and will I fear be used to >> mislead further. (See also some of the comments below - >> I do not think we ought be as fast and loose with this >> aleady terribly badly used term.) To summarise: I'd love >> if you did s/consent/anything-else/g but if not, please >> define consent here in a way that clearly and >> unambiguously distinguishes this usage from other abuses >> of the term. >> >> >> >> >> >> [TR] Updated Consent definition. >> >> >> >> The document already has a clear and unambiguous definition of the term, >> IMHO: >> >> >> >> Consent: The mechanism of obtaining permission from the remote >> >> endpoint to send non-ICE traffic to a remote transport address. >> >> Consent is obtained using ICE. >> >> >> >> Is that definition lacking something? I think finding an alter term would be >> as hard as finding an alternate term for 'attack' as used in several RFCs >> [attack being (ab)used in many contexts, including in heart attack ;)] >> >> >> >> >> (2) WebRTC does not require STUN or TURN servers for >> some calls, even if it does for many. Why is it ok to >> require such a server be present in all calls (which I >> think this means) espcially when that means exposing >> additional meta-data (calling parties in a case where >> the servers weren't needed and call duration in all >> cases) to those servers when that is not always >> necessary? >> >> >> >> That looks a misunderstanding. Consent freshness doesn't require such >> server's to be present. Please point out to the text leading to the >> misunderstanding. >> >> >> >> >> (3) (end of p5) You have a MUST NOT here that is >> depenedent on current browser implementations. Why is >> that an IETF thing and not a W3C thing? But more >> interestingly, can one securely use this protocol >> without the kind of JS vs. browser sandboxing etc that's >> needed in the web? >> >> >> >> Yes, the mechanism has the same security properties within and outside the >> WebRTC sandboxing. >> >> >> >> If the answer is "no" then don't you >> need to say that this protocol can only safely be used >> for such implementations? (In section 2, which almost >> but not quite says that.) >> >> >> >> Section 2 doesn't say that. It only says WebRTC is the primary use case for >> the mechanism at the moment and future use cases based on similar sandboxing >> models can make use of it. >> >> >> >> >> (4) Cleared. >> >> (5) Cleared. >> >> >> ---------------------------------------------------------------------- >> COMMENT: >> ---------------------------------------------------------------------- >> >> >> (Was discuss point#4) >> "Section 8: Where are these 96 bits defined? I think >> this "requires..." statement needs a precise reference >> to the place in some ICE/TURN/STUN RFC where it's >> defined. (And I forget where that is, sorry:-) This >> should be an easy fix." >> Alissa gave me the reference [1] sothat's grand. It >> might be an idea to make that clearer if it wasn't >> just me missing it as I read, which is very possible;-) >> >> [1] https://tools.ietf.org/html/rfc5389#section-6 >> >> - abstract: why is only sending "media" mentioned here? >> What about data channels? And the body of the document >> in fact says this all applies to any non-ICE data and >> not only media. >> >> >> >> Agree, that should be "traffic". >> >> >> >> >> - intro: "initial consent to send by performing STUN" I >> do not find the word consent in either rfc5245 or 3489, >> but perhaps it is used somewhere else. Where? And with >> what meaning? >> >> >> >> Consent is a new usage of STUN and is described in >> draft-ietf-rtcweb-security-arch, draft-ietf-rtcweb-security and in this >> document. >> >> >> >> >> - section 4, 2nd last para - I think the conclusion is >> bogus. An implementation knows when the keying it's >> using can not involve >1 (nominally operating) party. >> >> >> >> That paragraph is here: >> >> >> >> When Secure Real-time Transport Protocol (SRTP) is used, the >> >> following considerations are applicable. SRTP is encrypted and >> >> authenticated with symmetric keys; that is, both sender and receiver >> >> know the keys. With two party sessions, receipt of an authenticated >> >> packet from the single remote party is a strong assurance the packet >> >> came from that party. However, when a session involves more than two >> >> parties, all of whom know each other's keys, any of those parties >> >> could have sent (or spoofed) the packet. Such shared key >> >> distributions are possible with some MIKEY [RFC3830] modes, Security >> >> Descriptions [RFC4568], and EKT [I-D.ietf-avtcore-srtp-ekt]. Thus, >> >> in such shared keying distributions, receipt of an authenticated SRTP >> >> packet is not sufficient to verify consent. >> >> >> >> I'll defer it to someone who has more knowledge that me on shared key >> distribution.. >> >> >> >> [TR] The idea behind the above paragraph is to use STUN consent checks in >> both two party and multi-party sessions. Consent checks uses >> >> point-to-point keys so the endpoint knows if each remote peer in the call is >> willing to receive traffic or not. >> >> >> >> -Tiru >> >> >> >> >> - 5.1, 3rd para: "Explicit consent to send is >> obtained..." is misleading. That is not a concept that >> an implementation of STUN will embody. >> >> >> >> As said earlier, consent is a new STUN usage. How would the following? >> >> >> >> An endpoint that implements this specification obtains and maintains >> >> consent to send by sending STUN binding request... >> >> >> >> >> - 5.1, What is the "Note" about TCP for? Why is this >> needed? >> >> >> >> It is needed because WebRTC data traffic sent over TCP could get converted >> to UDP by TURN servers. It is somewhat similar to why we need application >> layer security when traffic is sent over IPSec. The later may not be >> end-to-end. >> >> >> >> Muthu > > From nobody Thu Aug 13 10:52:16 2015 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 79FFC1A9027 for ; Thu, 13 Aug 2015 10:52:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Bp64bpfvUyIr for ; Thu, 13 Aug 2015 10:52:13 -0700 (PDT) Received: from mail-io0-x22c.google.com (mail-io0-x22c.google.com [IPv6:2607:f8b0:4001:c06::22c]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 323341A8F49 for ; Thu, 13 Aug 2015 10:52:13 -0700 (PDT) Received: by iodt126 with SMTP id t126so60304748iod.2 for ; Thu, 13 Aug 2015 10:52:12 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:date:message-id:subject:from:to:content-type; bh=ZxDVSxGseyKpupP11TSqSD+dST5udRyRa99dFUvQPLg=; b=oJWctVLi9TlN7wsuSxYMjZfQPvrtYGmu2hx884cwNax5Vn1HtddvCedOT3qjjYSXi8 E2CSsTxOnpSt2hR65uc+V0LASHg9MxKTfaE7nZTcpEM8S5HiGbc/Y47sRy+k4PMTUW2I Pd9vfSj5beWjjYLANC4eKxke+CTapMrXJ68UaWW9bHNAwgnCxGnoS4aa3L3/VHva/KXy iyJkIdogWgmFhotHoWH+elWPpBHY7RUgsRfarJ4DhV/+PER4sXpDg0cm6R7S5hpX8XaE JafDYNyjBAS3UCYza2XYX844y//vAnzix3QSsK+iDSWGkt+u2rpSVqVxcTLs9dQ+JJmm r7wA== MIME-Version: 1.0 X-Received: by 10.107.9.150 with SMTP id 22mr13095858ioj.27.1439488332580; Thu, 13 Aug 2015 10:52:12 -0700 (PDT) Received: by 10.36.120.83 with HTTP; Thu, 13 Aug 2015 10:52:12 -0700 (PDT) Date: Thu, 13 Aug 2015 10:52:12 -0700 Message-ID: From: Ted Hardie To: "rtcweb@ietf.org" , Cullen Jennings , Sean Turner Content-Type: multipart/alternative; boundary=001a113f8fa8b8cc53051d34fea1 Archived-At: Subject: [rtcweb] Interim meeting X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 13 Aug 2015 17:52:14 -0000 --001a113f8fa8b8cc53051d34fea1 Content-Type: text/plain; charset=UTF-8 Though sentiment about holding an interim meeting near the upcoming WebRTC meeting was general positive, the number of responses was very low. This is likely just the result of vacation season, but given that the work to prepare for the interim would also get hit by the same season, the chairs believe it will be better to hold an interim meeting later in September. We will post a doodle poll in a week or so, but the anticipated timing is in the last two weeks of September, with a goal of 2 1/2 to 3 hours focused on JSEP. regards, Ted, Cullen, Sean --001a113f8fa8b8cc53051d34fea1 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Though sentiment about holding an interim meetin= g near the upcoming WebRTC meeting was general positive, the number of resp= onses was very low.=C2=A0 This is likely just the result of vacation season= , but given that the work to prepare for the interim would also get hit by = the same season, the chairs believe it will be better to hold an interim me= eting later in September.

We will post a doodle po= ll in a week or so, but the anticipated timing is in the last two weeks of = September, with a goal of 2 1/2 to 3 hours focused on JSEP.

regards,

Ted, Cullen, Sean
--001a113f8fa8b8cc53051d34fea1-- From nobody Thu Aug 13 12:47:34 2015 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 64EBF1B3A2C; Thu, 13 Aug 2015 12:47:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.9 X-Spam-Level: X-Spam-Status: No, score=-101.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, USER_IN_WHITELIST=-100] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id g9SSzX-RfCui; Thu, 13 Aug 2015 12:47:32 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 3D9151B3A44; Thu, 13 Aug 2015 12:47:30 -0700 (PDT) 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.4.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20150813194730.19312.72212.idtracker@ietfa.amsl.com> Date: Thu, 13 Aug 2015 12:47:30 -0700 Archived-At: Cc: rtcweb mailing list , rtcweb chair , RFC Editor Subject: [rtcweb] Protocol Action: 'STUN Usage for Consent Freshness' to Proposed Standard (draft-ietf-rtcweb-stun-consent-freshness-16.txt) X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 13 Aug 2015 19:47:33 -0000 The IESG has approved the following document: - 'STUN Usage for Consent Freshness' (draft-ietf-rtcweb-stun-consent-freshness-16.txt) as Proposed Standard This document is the product of the Real-Time Communication in WEB-browsers 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-rtcweb-stun-consent-freshness/ Technical Summary In WebRTC contexts, peers send media traffic to each other. To prevent attacks on peers, endpoints have to ensure the remote peer is willing to receive traffic. This is performed both when the session is first established to the remote peer and periodically for the duration of the session. This document defines a method for confirming consent using a new STUN usage. Working Group Summary One of the consistent issues within the WebRTC ecosystem is the extent to which requirements from deployed systems impact the working of the protocol. In this context, discussion of how ICE-lite entities should behave consumed a good bit of time, but I believe that the document represents the WG's general understanding. After a set of external reviews by directorates the documented was updated and a new working group last call issued. No new issues were identified during the final working group last call. Document Quality The document was reviewed by a number of implementors and implementations are planned or under way. This document did not require expert review of the type mentioned above, but Christer Holmberg's review is called out in the document for its thoroughness. Personnel Ted Hardie is the Document Shepherd; Alissa Cooper is the Responsible Area Director. From nobody Thu Aug 13 13:14:00 2015 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 160DC1ACD11 for ; Thu, 13 Aug 2015 13:13:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.909 X-Spam-Level: X-Spam-Status: No, score=-1.909 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3JEk9VrYOEk2 for ; Thu, 13 Aug 2015 13:13:57 -0700 (PDT) Received: from nostrum.com (raven-v6.nostrum.com [IPv6:2001:470:d:1130::1]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9E8951A87A4 for ; Thu, 13 Aug 2015 13:13:57 -0700 (PDT) Received: from Orochi.local (99-152-145-110.lightspeed.dllstx.sbcglobal.net [99.152.145.110]) (authenticated bits=0) by nostrum.com (8.15.2/8.14.9) with ESMTPSA id t7DKDu1j068686 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NO) for ; Thu, 13 Aug 2015 15:13:56 -0500 (CDT) (envelope-from adam@nostrum.com) X-Authentication-Warning: raven.nostrum.com: Host 99-152-145-110.lightspeed.dllstx.sbcglobal.net [99.152.145.110] claimed to be Orochi.local Message-ID: <55CCFA84.4010905@nostrum.com> Date: Thu, 13 Aug 2015 15:13:56 -0500 From: Adam Roach User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:31.0) Gecko/20100101 Thunderbird/31.7.0 MIME-Version: 1.0 To: rtcweb@ietf.org References: In-Reply-To: Content-Type: multipart/alternative; boundary="------------060404090303060208090701" Archived-At: Subject: Re: [rtcweb] Interim meeting X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 13 Aug 2015 20:13:59 -0000 This is a multi-part message in MIME format. --------------060404090303060208090701 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Can you clarify whether this is planned to be a face-to-face interim meeting or a teleconference? Thanks. /a On 8/13/15 12:52, Ted Hardie wrote: > Though sentiment about holding an interim meeting near the upcoming > WebRTC meeting was general positive, the number of responses was very > low. This is likely just the result of vacation season, but given > that the work to prepare for the interim would also get hit by the > same season, the chairs believe it will be better to hold an interim > meeting later in September. > > We will post a doodle poll in a week or so, but the anticipated timing > is in the last two weeks of September, with a goal of 2 1/2 to 3 hours > focused on JSEP. > > regards, > > Ted, Cullen, Sean > > > _______________________________________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/listinfo/rtcweb --------------060404090303060208090701 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit
Can you clarify whether this is planned to be a face-to-face interim meeting or a teleconference?

Thanks.

/a

On 8/13/15 12:52, Ted Hardie wrote:
Though sentiment about holding an interim meeting near the upcoming WebRTC meeting was general positive, the number of responses was very low.  This is likely just the result of vacation season, but given that the work to prepare for the interim would also get hit by the same season, the chairs believe it will be better to hold an interim meeting later in September.

We will post a doodle poll in a week or so, but the anticipated timing is in the last two weeks of September, with a goal of 2 1/2 to 3 hours focused on JSEP.

regards,

Ted, Cullen, Sean


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

--------------060404090303060208090701-- From nobody Thu Aug 13 13:21:26 2015 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5FCDC1B3ABC for ; Thu, 13 Aug 2015 13:21:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.601 X-Spam-Level: X-Spam-Status: No, score=-2.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 533lzpuDaS5T for ; Thu, 13 Aug 2015 13:21:24 -0700 (PDT) Received: from mail-io0-f177.google.com (mail-io0-f177.google.com [209.85.223.177]) (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 DB77E1B3A5F for ; Thu, 13 Aug 2015 13:21:23 -0700 (PDT) Received: by iods203 with SMTP id s203so64515847iod.0 for ; Thu, 13 Aug 2015 13:21:23 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:subject:to:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-type :content-transfer-encoding; bh=N696Q0YHbiK4CCkYsmiKjxfCbOnR4WhL1YAOaRiOKaU=; b=fSDjBfxjjcwMI7DuuDwqBgtJaKjDS1iiZqs39SjI/av7l0Z5FipE7bv+8qTU+8Qq7g sMBnmxCSMBgyfiQfFh540nxuZs/rTolOwsqoRiCOwXTDhIRbpH/lPLsFnD8TVukUOKE5 z9nAE5GDgiaukrVuToHeUBDWicbV3hLRL7tYP3lvQW7mPU/19jMLUxkj0TXApROCafMT vSfZPzAMMHiyqBH0+am2oVYf7OkK1S5EmZMFPzPXVoSar1O6/8w1OpZvqL+ZHfB1fHNP djaoFJfi2bG5vFY5e6efaZMM5c9mP7xpb0o1KMeUqtowIjFq5vf/vxeKuqEs9NYpPArX 4uPg== X-Gm-Message-State: ALoCoQmonn1MaoN8F0BiOhj5m+oPGHKM4RQZhOKi6L6GaoAhv5TBKWEwjPxUMMF78rTtU/kB7Xp/ X-Received: by 10.107.137.208 with SMTP id t77mr38213633ioi.2.1439497283157; Thu, 13 Aug 2015 13:21:23 -0700 (PDT) Received: from aither.local ([2601:282:4201:ef5b:5d6c:f720:e58b:cd82]) by smtp.googlemail.com with ESMTPSA id o66sm2236305ioo.5.2015.08.13.13.21.21 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 13 Aug 2015 13:21:21 -0700 (PDT) To: Adam Roach , rtcweb@ietf.org References: <55CCFA84.4010905@nostrum.com> From: Peter Saint-Andre - &yet Message-ID: <55CCFC3F.8080407@andyet.net> Date: Thu, 13 Aug 2015 14:21:19 -0600 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:38.0) Gecko/20100101 Thunderbird/38.1.0 MIME-Version: 1.0 In-Reply-To: <55CCFA84.4010905@nostrum.com> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [rtcweb] Interim meeting X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 13 Aug 2015 20:21:25 -0000 I had understood it to be a teleconference. On 8/13/15 2:13 PM, Adam Roach wrote: > Can you clarify whether this is planned to be a face-to-face interim > meeting or a teleconference? > > Thanks. > > /a > > On 8/13/15 12:52, Ted Hardie wrote: >> Though sentiment about holding an interim meeting near the upcoming >> WebRTC meeting was general positive, the number of responses was very >> low. This is likely just the result of vacation season, but given >> that the work to prepare for the interim would also get hit by the >> same season, the chairs believe it will be better to hold an interim >> meeting later in September. >> >> We will post a doodle poll in a week or so, but the anticipated timing >> is in the last two weeks of September, with a goal of 2 1/2 to 3 hours >> focused on JSEP. >> >> regards, >> >> Ted, Cullen, Sean >> From nobody Thu Aug 13 13:39:43 2015 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 310CF1B3ADB for ; Thu, 13 Aug 2015 13:39:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 75Fx6jP5rl7R for ; Thu, 13 Aug 2015 13:39:40 -0700 (PDT) Received: from mail-ig0-x234.google.com (mail-ig0-x234.google.com [IPv6:2607:f8b0:4001:c05::234]) (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 181B21B3ADE for ; Thu, 13 Aug 2015 13:39:38 -0700 (PDT) Received: by igfj19 with SMTP id j19so44547274igf.1 for ; Thu, 13 Aug 2015 13:39:37 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=oRYg8RdbTAILTaHINiDgr2AlMHySgei4cO1utXqNRbk=; b=veyi66MSTllQCmnN+XKh3j1nEe7nIkQe4WnzDmkwK0OPcCUJtwKQThciR3tQhZan2r ywImDy7M+ixxmAsUejDRgF/saO5V89hpxHH0iVogBhq4OROIGNqkyu24ckspMFnLOYxx Mm5wb+UqjP5TAUQ9LEY4vuYx56GAzrbCXoMFa6uCo9MjJYfMPnQsCLf6n3uasEU6SxmL sjQizHv14kNjeTRqsunZTqgGPPjZjYHkz/r+kg63+qHMTc1SLlLyLpqhjWV2C3yYP0Ka NICridiixZx7FzKSmhxk1v/xGKXIS8S1WqeaEe2Sksxm1awUemXG7wfkj16sUDJxdOFX IIyw== MIME-Version: 1.0 X-Received: by 10.50.56.104 with SMTP id z8mr4823685igp.45.1439498377505; Thu, 13 Aug 2015 13:39:37 -0700 (PDT) Received: by 10.36.120.83 with HTTP; Thu, 13 Aug 2015 13:39:37 -0700 (PDT) In-Reply-To: <55CCFA84.4010905@nostrum.com> References: <55CCFA84.4010905@nostrum.com> Date: Thu, 13 Aug 2015 13:39:37 -0700 Message-ID: From: Ted Hardie To: Adam Roach Content-Type: multipart/alternative; boundary=089e0158a842723358051d375519 Archived-At: Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] Interim meeting X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 13 Aug 2015 20:39:42 -0000 --089e0158a842723358051d375519 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On Thu, Aug 13, 2015 at 1:13 PM, Adam Roach wrote: > Can you clarify whether this is planned to be a face-to-face interim > meeting or a teleconference? > > Thanks. > > =E2=80=8BMy apologies for any confusion. We are currently planning for a teleconference/electronic interim, not a face-to-face meeting. regards, Ted Hardie=E2=80=8B > /a > > > On 8/13/15 12:52, Ted Hardie wrote: > > Though sentiment about holding an interim meeting near the upcoming WebRT= C > meeting was general positive, the number of responses was very low. This > is likely just the result of vacation season, but given that the work to > prepare for the interim would also get hit by the same season, the chairs > believe it will be better to hold an interim meeting later in September. > > We will post a doodle poll in a week or so, but the anticipated timing is > in the last two weeks of September, with a goal of 2 1/2 to 3 hours focus= ed > on JSEP. > > regards, > > Ted, Cullen, Sean > > > _______________________________________________ > rtcweb mailing listrtcweb@ietf.orghttps://www.ietf.org/mailman/listinfo/r= tcweb > > > > _______________________________________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/listinfo/rtcweb > > --089e0158a842723358051d375519 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On Thu, Aug 13, 2015 at 1:13 PM= , Adam Roach <adam@nostrum.com> wrote:
=20 =20 =20
Can you clarify whether this is planned to be a face-to-face interim meeting or a teleconference?

Thanks.


=E2=80=8BMy apologies= for any confusion.=C2=A0 We are currently planning for a teleconference/el= ectronic interim, not a face-to-face meeting.

regard= s,

Ted Hardie=E2=80=8B

=C2=A0
/a


On 8/13/15 12:52, Ted Hardie wrote:
Though sentiment about holding an interim meeting near the upcoming WebRTC meeting was general positive, the number of responses was very low.=C2=A0 This is likely just the result of vacation season, but given that the work to prepare for the interim would also get hit by the same season, the chairs believe it will be better to hold an interim meeting later in September.

We wil= l post a doodle poll in a week or so, but the anticipated timing is in the last two weeks of September, with a goal of 2 1/2 to 3 hours focused on JSEP.

regard= s,

Ted, Cullen, Sean


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


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


--089e0158a842723358051d375519-- From nobody Thu Aug 13 16:23:00 2015 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 46E051ACEC1 for ; Thu, 13 Aug 2015 16:22:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.388 X-Spam-Level: X-Spam-Status: No, score=-1.388 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qy-R1V63cBRz for ; Thu, 13 Aug 2015 16:22:56 -0700 (PDT) Received: from mail-vk0-x230.google.com (mail-vk0-x230.google.com [IPv6:2607:f8b0:400c:c05::230]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 77A541ACEBB for ; Thu, 13 Aug 2015 16:22:54 -0700 (PDT) Received: by vkfi73 with SMTP id i73so24068224vkf.2 for ; Thu, 13 Aug 2015 16:22:53 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=9+hGRRBfb5OinAaa5UBLca7nPDvPQquRQppVQGa8STw=; b=O2bNnwaRPqiv1SbpxmPS1psYgAbAaMPbMb6yk5sULP4gV5qLIv++ZYhLchha+cq4Wv c8uveFpH4nPDhYOTD3vQX8eK8vwU3DX3T7C7OY/Rs3O7c8zyaWgTk4rAcGo5mIkD/Kgg fKcjXq5HTxNFH4jWR2hhfDZK0ptIN62xHRIYIyI9UiMB6vyusmTukKa9k4aibQA6TcXz /ghd4e1GpRd/MOB61Z+FCPVn/7VRo2L2YcCXZk9EpIuB6ZB7FdOduzBD6VUfyxBY3YrX 5cTAKeqy60AK2pNzsBRuk+1iyLPi0opnwTUf1g/TdiyCCp3bavyrGgW74rx559JTgk9Q aVGA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type; bh=9+hGRRBfb5OinAaa5UBLca7nPDvPQquRQppVQGa8STw=; b=lJSq7ogvUWWLKalcygoRU7uNqPjnJ4aykxFZaoMI+qtT+N5qsCwcqJGuOkyg6yrFpQ zRe5g7OvpqU0M4QziVGW4rfFOTpvgTO2xl+MpuKmd/gOLbyyha060gyx48WzTkVdcjTH /J/wgZM+M4rTvuzaCkIniegBw8HFAD0Pf2rMwTkSKLZgi3PKEAcmCCQfCntBkMrJIIZ+ 4Q6CSBGkM+NrjkVy0DlaLp3sVOJofHw7up7DaRFzRuqi6oa4qmGr/FCRpHrbCo35BF7m 9emSdUusPAXFHcnOnh50F2duKYfjBuOSDTsrSK+ik3tzjI5d0OtC7cFPd5noFpWUk1fX ddRg== X-Gm-Message-State: ALoCoQl5Tt7RHovO/OTcoYKsjHD2AcGltiBOl5YCXbx27TmFkcI2DyBSc3IFPxgWf/HASthS/0O/ X-Received: by 10.52.116.67 with SMTP id ju3mr50119033vdb.66.1439508173584; Thu, 13 Aug 2015 16:22:53 -0700 (PDT) MIME-Version: 1.0 Received: by 10.31.191.87 with HTTP; Thu, 13 Aug 2015 16:22:34 -0700 (PDT) In-Reply-To: References: <20150805130607.20844.70680.idtracker@ietfa.amsl.com> <55C24293.5000603@cs.tcd.ie> <55C24C09.8020404@goodadvice.pages.de> <55C256C8.80606@jive.com> <3F10035A-70A4-46AE-AB44-4499541AC7C6@cisco.com> From: Justin Uberti Date: Thu, 13 Aug 2015 16:22:34 -0700 Message-ID: To: Emil Ivov Content-Type: multipart/alternative; boundary=bcaec548aa5956a37e051d399d4b Archived-At: Cc: Jonathan Lennox , "rtcweb@ietf.org" , mmusic , "tram@ietf.org" Subject: Re: [rtcweb] [tram] TURN permissions for private ips X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 13 Aug 2015 23:22:58 -0000 --bcaec548aa5956a37e051d399d4b Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable For now I think we will follow the suggestion of letting the server enforce this policy, and return 403 in the case where the target IP would be considered unreachable by the server. Chrome will also need to be updated to actually do the right thing on this 403... On Tue, Aug 11, 2015 at 6:32 AM, Emil Ivov wrote: > Hey Pal, > > On Fri, Aug 7, 2015 at 2:47 AM, Pal Martinsen (palmarti) > wrote: > > > > On 07 Aug 2015, at 02:11, Emil Ivov wrote: > > > > On Thu, Aug 6, 2015 at 5:01 PM, Justin Uberti > wrote: > > > > > > > > On Thu, Aug 6, 2015 at 1:51 PM, Martin Thomson > > > wrote: > > > > > > On 6 August 2015 at 13:08, Justin Uberti wrote: > > > > I think that we should be able to avoid pairing candidates obtained fro= m > > application TURN servers with RFC 1918 addresses. The app/browser > > clearly > > knows which is which. > > > > > > I'm concerned here that if we let the application choose, we lose the > > defence we were looking to gain. I think that perhaps 1918 pairing > > could be restricted to TURN servers that are configured/discovered, > > "proxy"-style. > > > > > > > > Sorry, that is what I was trying to say. The browser knows which turn > > servers are "proxies" vs app servers, and can apply the 1918 filtering = on > > the pairings from the candidates from the app TURN server. > > > > > > I don't think Jonathan's concerns only apply to proxies though. You > > can just as well have apps developed for specific networks and there > > is no reason to prevent those from working. > > > > Agree with your enumeration of concerns as well. Also #5, they consume > > bandwidth (at least from client to TURN server), which affects maximum > check > > rate in some cases. > > > > > > Why can't we address this by TURN servers simply refusing to create > > permissions for candidates they know they won't be able to reach? > > > > How do you reliably and simply do that without a connectivity check? > > There are a few ways a TURN server could be smart about this (e.g. > checking the routing table for local interfaces for example, or > looking into ARP tables) but ultimately they should allow for this to > be configured. > > > If the main concern is information leakage, isn=E2=80=99t that up to th= e client > to > > decide what it want to reveal to the TURN server and the remote client? > > I don't know that the main concern is leakage (see my previous mail). > I don't see how an application can be worried that the TURN server it > chose is going to find out that there's one of three NATed ranged > behind a certain IP. The TURN server had a 1 in 4 chance of guessing > that even without the app. > > That said, I am not opposed to giving JavaScript apps a way to > explicitly signal the stack not to pair certain addresses with TURN. > > I just don't want the stack to assume this. > > Emil > > > Guess what I am saying is that I think it is a good thing to have a > =E2=80=9Cthick=E2=80=9D > > client and relatively simple network components. > > > > .-. > > P=C3=A5l-Erik > > > > > > Emil > > > > -- > > https://jitsi.org > > > > _______________________________________________ > > rtcweb mailing list > > rtcweb@ietf.org > > https://www.ietf.org/mailman/listinfo/rtcweb > > > > > > > > -- > https://jitsi.org > --bcaec548aa5956a37e051d399d4b Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
For now I think we will follow the suggestion of letting t= he server enforce this policy, and return 403 in the case where the target = IP would be considered unreachable by the server.

Chrome= will also need to be updated to actually do the right thing on this 403...=

On Tu= e, Aug 11, 2015 at 6:32 AM, Emil Ivov <emcho@jitsi.org> wrote:=
Hey Pal,

On Fri, Aug 7, 2015 at 2:47 AM, Pal Martinsen (palmarti)
<palmarti@cisco.com> wrote:=
>
> On 07 Aug 2015, at 02:11, Emil Ivov <emcho@jitsi.org> wrote:
>
> On Thu, Aug 6, 2015 at 5:01 PM, Justin Uberti <juberti@google.com> wrote:
>
>
>
> On Thu, Aug 6, 2015 at 1:51 PM, Martin Thomson <martin.thomson@gmail.com>
> wrote:
>
>
> On 6 August 2015 at 13:08, Justin Uberti <juberti@google.com> wrote:
>
> I think that we should be able to avoid pairing candidates obtained fr= om
> application TURN servers with RFC 1918 addresses. The app/browser
> clearly
> knows which is which.
>
>
> I'm concerned here that if we let the application choose, we lose = the
> defence we were looking to gain.=C2=A0 I think that perhaps 1918 pairi= ng
> could be restricted to TURN servers that are configured/discovered, > "proxy"-style.
>
>
>
> Sorry, that is what I was trying to say. The browser knows which turn<= br> > servers are "proxies" vs app servers, and can apply the 1918= filtering on
> the pairings from the candidates from the app TURN server.
>
>
> I don't think Jonathan's concerns only apply to proxies though= . You
> can just as well have apps developed for specific networks and there > is no reason to prevent those from working.
>
> Agree with your enumeration of concerns as well. Also #5, they consume=
> bandwidth (at least from client to TURN server), which affects maximum= check
> rate in some cases.
>
>
> Why can't we address this by TURN servers simply refusing to creat= e
> permissions for candidates they know they won't be able to reach?<= br> >
> How do you reliably and simply do that without a connectivity check?
There are a few ways a TURN server could be smart about this (e= .g.
checking the routing table for local interfaces for example, or
looking into ARP tables) but ultimately they should allow for this to
be configured.

> If the main concern is information leakage, isn=E2=80=99t that up to t= he client to
> decide what it want to reveal to the TURN server and the remote client= ?

I don't know that the main concern is leakage (see my previous m= ail).
I don't see how an application can be worried that the TURN server it chose is going to find out that there's one of three NATed ranged
behind a certain IP. The TURN server had a 1 in 4 chance of guessing
that even without the app.

That said, I am not opposed to giving JavaScript apps a way to
explicitly signal the stack not to pair certain addresses with TURN.

I just don't want the stack to assume this.

Emil

> Guess what I am saying is that I think it is a good thing to have a = =E2=80=9Cthick=E2=80=9D
> client and relatively simple network components.
>
> .-.
> P=C3=A5l-Erik
>
>
> Emil
>
> --
> htt= ps://jitsi.org
>
> _______________________________________________
> rtcweb mailing list
> rtcweb@ietf.org
> https://www.ietf.org/mailman/listinfo/rtcweb >
>



--
https://= jitsi.org

--bcaec548aa5956a37e051d399d4b-- From nobody Fri Aug 14 06:40:00 2015 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 40DB41A1B57 for ; Fri, 14 Aug 2015 06:39:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.002 X-Spam-Level: X-Spam-Status: No, score=-0.002 tagged_above=-999 required=5 tests=[BAYES_40=-0.001, 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 TwEoHVBUZh4D for ; Fri, 14 Aug 2015 06:39:56 -0700 (PDT) Received: from gateway32.websitewelcome.com (gateway32.websitewelcome.com [192.185.145.181]) (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 997D11A1B3E for ; Fri, 14 Aug 2015 06:39:51 -0700 (PDT) Received: by gateway32.websitewelcome.com (Postfix, from userid 500) id 1E2EBE0FEE402; Fri, 14 Aug 2015 08:39:51 -0500 (CDT) Received: from gator3286.hostgator.com (gator3286.hostgator.com [198.57.247.250]) by gateway32.websitewelcome.com (Postfix) with ESMTP id 0A7B6E0FEE382 for ; Fri, 14 Aug 2015 08:39:51 -0500 (CDT) Received: from [96.231.216.201] (port=55146 helo=[172.16.0.112]) by gator3286.hostgator.com with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.85) (envelope-from ) id 1ZQFD4-000Epd-Al for rtcweb@ietf.org; Fri, 14 Aug 2015 08:39:50 -0500 From: Sean Turner Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Message-Id: <2C6E529A-7ECC-4919-973F-5ADFDEE4FA57@ieca.com> Date: Fri, 14 Aug 2015 09:39:48 -0400 To: rtcweb@ietf.org Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) X-Mailer: Apple Mail (2.1878.6) X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - gator3286.hostgator.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - ieca.com X-BWhitelist: no X-Source-IP: 96.231.216.201 X-Exim-ID: 1ZQFD4-000Epd-Al X-Source: X-Source-Args: X-Source-Dir: X-Source-Sender: ([172.16.0.112]) [96.231.216.201]:55146 X-Source-Auth: sean.turner@ieca.com X-Email-Count: 2 X-Source-Cap: ZG9tbWdyNDg7ZG9tbWdyNDg7Z2F0b3IzMjg2Lmhvc3RnYXRvci5jb20= Archived-At: Subject: [rtcweb] Call for WG adoption: draft-nandakumar-rtcweb-sdp X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 14 Aug 2015 13:39:58 -0000 All, At the second IETF 93 RTCweb session, we agreed to send a call for WG = adoption of draft-nandakumar-rtcweb-sdp after a week of review. Well = it=92s been two weeks. So without further ado =85 Please respond to say = whether you support adoption of this work as a working group work item = and whether you will participate in the discussion. If you are opposed = to this draft becoming a WG document, please say so (and say why). = Please have your response in by 20150821 23:59 UTC. Thanks in advance! spt= From nobody Fri Aug 14 07:30:40 2015 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 805011A8960 for ; Fri, 14 Aug 2015 07:30:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id K-mVStNQFd_4 for ; Fri, 14 Aug 2015 07:30:38 -0700 (PDT) Received: from mail-wi0-x22e.google.com (mail-wi0-x22e.google.com [IPv6:2a00:1450:400c:c05::22e]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B35CC1A895B for ; Fri, 14 Aug 2015 07:30:37 -0700 (PDT) Received: by wicja10 with SMTP id ja10so19933789wic.1 for ; Fri, 14 Aug 2015 07:30:36 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=YbqZ8FdEp/h/exsbroTVaAbVreuWVolNnhysgAwD5K0=; b=uHokWEdLbSWjYqlfSHnlIBCrbCeYo3FDda3Dohu9+izb3S1lVoGuxmhfoARgBmsp4c IvxaF9rm3NEBti8VZwmFsS8C6aVCjqpkqpoYlUsYPhv8rFpY7EWguh21nkJY7z+VA0+W nkcluuGXX6T12QNH8ShWuBzaUhIm3hAsk/53yJogaNjHXVn0kAL8hOZOX2vQjDcEOV0D mV2N9Tlx7Dkbh1h3cd7sKbHwhEba11J5F4R/WYmLQ2yA34GmMA37ZM24t9El5uTDuSB/ A4Jzjb2Xsxm6Y30V7W4eO+zObvLGOveqIPBnsnWAvk+K8g6M+GjizgVOTWluoLuVc3a8 5Lpw== MIME-Version: 1.0 X-Received: by 10.194.94.73 with SMTP id da9mr419772wjb.97.1439562636501; Fri, 14 Aug 2015 07:30:36 -0700 (PDT) Received: by 10.28.20.132 with HTTP; Fri, 14 Aug 2015 07:30:36 -0700 (PDT) In-Reply-To: <2C6E529A-7ECC-4919-973F-5ADFDEE4FA57@ieca.com> References: <2C6E529A-7ECC-4919-973F-5ADFDEE4FA57@ieca.com> Date: Fri, 14 Aug 2015 16:30:36 +0200 Message-ID: From: Victor Pascual Avila To: Sean Turner Content-Type: multipart/alternative; boundary=047d7bb04efe94aad0051d464b7e Archived-At: Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] Call for WG adoption: draft-nandakumar-rtcweb-sdp X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 14 Aug 2015 14:30:39 -0000 --047d7bb04efe94aad0051d464b7e Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable I support the adoption of this document as a WG item -Victor On Fri, Aug 14, 2015 at 3:39 PM, Sean Turner wrote: > All, > > At the second IETF 93 RTCweb session, we agreed to send a call for WG > adoption of draft-nandakumar-rtcweb-sdp after a week of review. Well it= =E2=80=99s > been two weeks. So without further ado =E2=80=A6 Please respond to say w= hether you > support adoption of this work as a working group work item and whether yo= u > will participate in the discussion. If you are opposed to this draft > becoming a WG document, please say so (and say why). Please have your > response in by 20150821 23:59 UTC. > > Thanks in advance! > > spt > _______________________________________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/listinfo/rtcweb --047d7bb04efe94aad0051d464b7e Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
I support the adoption of this document as a WG item
<= br>
-Victor

On Fri, Aug 14, 2015 at 3:39 PM, Sean Turner <= turners@ieca.com&= gt; wrote:
All,

At the second IETF 93 RTCweb session, we agreed to send a call for WG adopt= ion of draft-nandakumar-rtcweb-sdp after a week of review.=C2=A0 Well it=E2= =80=99s been two weeks.=C2=A0 So without further ado =E2=80=A6 Please respo= nd to say whether you support adoption of this work as a working group work= item and whether you will participate in the discussion.=C2=A0 =C2=A0If yo= u are opposed to this draft becoming a WG document, please say so (and say = why).=C2=A0 Please have your response in by 20150821 23:59 UTC.

Thanks in advance!

spt
_______________________________________________
rtcweb mailing list
rtcweb@ietf.org
https://www.ietf.org/mailman/listinfo/rtcweb
--047d7bb04efe94aad0051d464b7e-- From nobody Fri Aug 14 08:22:46 2015 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4DDB41AC3D6 for ; Fri, 14 Aug 2015 08:22:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, 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 NV64538F-bhY for ; Fri, 14 Aug 2015 08:22:44 -0700 (PDT) Received: from smtp121.ord1c.emailsrvr.com (smtp121.ord1c.emailsrvr.com [108.166.43.121]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E6C591ABD3B for ; Fri, 14 Aug 2015 08:22:43 -0700 (PDT) Received: from smtp24.relay.ord1c.emailsrvr.com (localhost.localdomain [127.0.0.1]) by smtp24.relay.ord1c.emailsrvr.com (SMTP Server) with ESMTP id 5F2CB803D3; Fri, 14 Aug 2015 11:22:43 -0400 (EDT) Received: by smtp24.relay.ord1c.emailsrvr.com (Authenticated sender: fluffy-AT-iii.ca) with ESMTPSA id E2137803C5; Fri, 14 Aug 2015 11:22:42 -0400 (EDT) X-Sender-Id: fluffy@iii.ca Received: from [172.20.10.2] ([UNAVAILABLE]. [209.52.88.8]) (using TLSv1 with cipher DHE-RSA-AES256-SHA) by 0.0.0.0:465 (trex/5.4.2); Fri, 14 Aug 2015 15:22:43 GMT Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2102\)) Content-Type: text/plain; charset=us-ascii From: Cullen Jennings In-Reply-To: Date: Fri, 14 Aug 2015 08:22:41 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <682D1D83-A821-4D7D-ADE4-672040CBBF1D@iii.ca> References: To: Peter Thatcher X-Mailer: Apple Mail (2.2102) Archived-At: Cc: "" Subject: Re: [rtcweb] Do we have consensus on not requiring rtcp-non-mux? X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 14 Aug 2015 15:22:45 -0000 I think you are confusing two discussions here. One is what we do ice = bis and one is rtcweb. They are a bit different.=20 > On Aug 7, 2015, at 2:39 PM, Peter Thatcher = wrote: >=20 > After lots of discussion, it appears we have three options: >=20 > 1. Endpoints MAY implement rtcp-non-mux (we change the spec and can = delete the ugly code) >=20 > 2. Endpoints MUST NOT implement rtcp-non-mux (we change the spec and = must delete the ugly code, and our non-compliant until we do) >=20 > 3. Endpoints MUST implement rtcp-non-mux (we don't change the spec = and keep around the ugly code) >=20 >=20 > My reading of the discussion is that most people want #1 or #2, and = very few people still want #3. Between #1 and #2, while some people = would prefer #2, there are good reasons to just do #1, and most seem to = prefer #1. Further, I'm guessing that most people who wanted #2 could = live with #1. >=20 >=20 > TL;DR: I think we may have rough consensus on #1, saying endpoints = MAY rtcp-non-mux (but may choose to delete all that ugly code instead). =20= >=20 >=20 > So, is everyone happy with #1? >=20 >=20 >=20 > _______________________________________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/listinfo/rtcweb From nobody Fri Aug 14 08:26:29 2015 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D359C1A924C for ; Fri, 14 Aug 2015 08:26:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, 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 0Wx8nRbmvhDA for ; Fri, 14 Aug 2015 08:26:27 -0700 (PDT) Received: from smtp81.iad3a.emailsrvr.com (smtp81.iad3a.emailsrvr.com [173.203.187.81]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DC1341A9244 for ; Fri, 14 Aug 2015 08:26:26 -0700 (PDT) Received: from smtp11.relay.iad3a.emailsrvr.com (localhost.localdomain [127.0.0.1]) by smtp11.relay.iad3a.emailsrvr.com (SMTP Server) with ESMTP id 0D65B100604; Fri, 14 Aug 2015 11:26:26 -0400 (EDT) Received: by smtp11.relay.iad3a.emailsrvr.com (Authenticated sender: fluffy-AT-iii.ca) with ESMTPSA id 73A7A100635; Fri, 14 Aug 2015 11:26:25 -0400 (EDT) X-Sender-Id: fluffy@iii.ca Received: from [172.20.10.2] ([UNAVAILABLE]. [209.52.88.8]) (using TLSv1 with cipher DHE-RSA-AES256-SHA) by 0.0.0.0:465 (trex/5.4.2); Fri, 14 Aug 2015 15:26:26 GMT Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2102\)) Content-Type: text/plain; charset=windows-1252 From: Cullen Jennings In-Reply-To: Date: Fri, 14 Aug 2015 08:26:23 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <6BB5E1D7-B5FC-484E-A1E4-DD6697D9926D@iii.ca> References: <55C6FBAB.6050009@alvestrand.no> <9F33F40F6F2CD847824537F3C4E37DDF1E83584F@MCHP04MSX.global-ad.net> To: Colin Perkins X-Mailer: Apple Mail (2.2102) Archived-At: Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] Do we have consensus on not requiring rtcp-non-mux? X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 14 Aug 2015 15:26:28 -0000 > On Aug 10, 2015, at 3:43 AM, Colin Perkins wrote: >=20 > We might be able to make the edits in AUTH48, with AD approval, rather = than pull the draft back from the RFC Editor, but those are process = steps we'll figure out.=20 >=20 > What I'd most like to understand is the exact text change that is = being proposed for the rtp-usage draft. Can someone state what is = believed to be the consensus? >=20 > Colin >=20 >=20 There was a discussion at last IETF about what we do with ice bis where = this can make sense but I think we would want to talk to the WebRTC GW = vendors a bit before changing the RTCWeb stuff.=20 From nobody Fri Aug 14 08:39:45 2015 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9915E1ACD46 for ; Fri, 14 Aug 2015 08:39:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, 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 IYrD0GB-5Gc9 for ; Fri, 14 Aug 2015 08:39:41 -0700 (PDT) Received: from smtp89.ord1c.emailsrvr.com (smtp89.ord1c.emailsrvr.com [108.166.43.89]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 12EE41ACD3C for ; Fri, 14 Aug 2015 08:39:41 -0700 (PDT) Received: from smtp12.relay.ord1c.emailsrvr.com (localhost.localdomain [127.0.0.1]) by smtp12.relay.ord1c.emailsrvr.com (SMTP Server) with ESMTP id 4B2AE380340; Fri, 14 Aug 2015 11:39:40 -0400 (EDT) Received: by smtp12.relay.ord1c.emailsrvr.com (Authenticated sender: fluffy-AT-iii.ca) with ESMTPSA id A5A8E3803DA; Fri, 14 Aug 2015 11:39:38 -0400 (EDT) X-Sender-Id: fluffy@iii.ca Received: from [172.20.10.2] ([UNAVAILABLE]. [209.52.88.8]) (using TLSv1 with cipher DHE-RSA-AES256-SHA) by 0.0.0.0:465 (trex/5.4.2); Fri, 14 Aug 2015 15:39:39 GMT Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2102\)) Content-Type: text/plain; charset=utf-8 From: Cullen Jennings In-Reply-To: Date: Fri, 14 Aug 2015 08:39:37 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: References: <20150805130607.20844.70680.idtracker@ietfa.amsl.com> <55C24293.5000603@cs.tcd.ie> <55C24C09.8020404@goodadvice.pages.de> <55C256C8.80606@jive.com> To: Jonathan Lennox X-Mailer: Apple Mail (2.2102) Archived-At: Cc: mmusic , "rtcweb@ietf.org" , "tram@ietf.org" Subject: Re: [rtcweb] [tram] TURN permissions for private ips X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 14 Aug 2015 15:39:42 -0000 > On Aug 6, 2015, at 7:14 AM, Jonathan Lennox = wrote: >=20 >=20 >> On Aug 5, 2015, at 5:35 PM, Justin Uberti wrote: >>=20 >> On Wed, Aug 5, 2015 at 11:32 AM, Simon Perreault = wrote: >> Le 2015-08-05 13:46, Philipp Hancke a =C3=A9crit : >> > If a peer sends candidates with IP addresses from the private = space, >> > permissions for those are created at the TURN server. Potentially = not >> > utilising transport encryption even. >> > >> > I doubt those candidates ever work, so from a privacy point of view = it >> > seems that clients should not create those permissions in the first >> > place. And ICE should probably not try to create pairs. >>=20 >> It's not up to the client to determine what addresses might not might >> not work for a given TURN server. There are lots of weird NAT >> configurations out there that play games with RFC1918 addresses and = can >> easily trick clients into doing the wrong thing. >>=20 >> I am somewhat sympathetic to that, but given that there is measurable = downside here - extra candidate pairs that take time to check - can you = supply a concrete example of where the client choosing not to pair a = TURN candidate with a RFC1918 address would cause a problem? >=20 > This is really an ICE question, not a TURN question, so adding MMUSIC. >=20 > Clearly, if your TURN server is actually on the public internet, = pairing RFC1918 address with its candidates won=E2=80=99t do any good. = However, there can be scenarios where you have a TURN server sitting in = a DMZ or the like, where it can actually route to RFC 1918 addresses. I = suspect this will be relevant in the various scenarios where the TURN = server is topologically equivalent to a web proxy.=20 >=20 > As I recall from the discussions around the development of ICE, there = are actually a fair number of networks out there which have public IPv4 = and RFC1918 addresses directly routable to each other. The examples I = remember came about as a result of corporate mergers, where one of the = pre-merger companies was using their public address space internally, = and the other wasn=E2=80=99t. >=20 Some SPs are putting all their customers behind CGN (carrier grade NAT) = and then looking at running cloud data centers where other people can = rent servers (AWS style) where those servers have public IPs and at the = same time they are directly routable to the all the NATed clients. That = allows you to run media servers (STUN, TURN, Conferences MCU / Switches, = caches etc) that have a low latency connectivity to the SP's customers = endpoints. Note the customers's themselves often deploy an additional = layer of residential NAT.=20 So scenarios like this might be getting more common .... From nobody Fri Aug 14 09:22:55 2015 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 010E61A879F for ; Fri, 14 Aug 2015 09:22:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.511 X-Spam-Level: X-Spam-Status: No, score=-14.511 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id o90JuHrw6T-q for ; Fri, 14 Aug 2015 09:22:52 -0700 (PDT) Received: from rcdn-iport-8.cisco.com (rcdn-iport-8.cisco.com [173.37.86.79]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A3B991A879E for ; Fri, 14 Aug 2015 09:22:52 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1496; q=dns/txt; s=iport; t=1439569372; x=1440778972; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=0AWBUVz1PcxAjegthy3ZDe5U2IJFIa3dFZA9lw4IxT8=; b=OWAz7XLnDqiKsOzwixqeovqQ4do7vyP4QchmbMdoh7qDTnz/UX9Lqoss O01fdmIn4jwKnS5DY4Hg3rPCkqZdxAU2UdS8W8Lq5NDh8fVK4lBsD8rqr OLnj06yDz3pnezZs/n491cZkHADgfSnx9e3liOEW5NOnMtfPtteREoRRy I=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: A0C2BQC9FM5V/5BdJa1dgxtUaQaDHrpugWsKhS9KAhyBLTkTAQEBAQEBAYEKhCMBAQEDAQEBARoGEToLBQsCAQgYAgImAgICHwYLFRACBA4FiBkDCggNuVmQUA2FVQEBAQEBAQEBAQEBAQEBAQEBAQEBARMEgSKKMYJPggcYGweCaS+BFAWSDoMNAYp+gW2BSoQrjHmDT4NnJoN9cQGBR4EEAQEB X-IronPort-AV: E=Sophos;i="5.15,678,1432598400"; d="scan'208";a="18678523" Received: from rcdn-core-8.cisco.com ([173.37.93.144]) by rcdn-iport-8.cisco.com with ESMTP; 14 Aug 2015 16:22:51 +0000 Received: from XCH-ALN-009.cisco.com (xch-aln-009.cisco.com [173.36.7.19]) by rcdn-core-8.cisco.com (8.14.5/8.14.5) with ESMTP id t7EGMptn019344 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Fri, 14 Aug 2015 16:22:51 GMT Received: from xch-aln-009.cisco.com (173.36.7.19) by XCH-ALN-009.cisco.com (173.36.7.19) with Microsoft SMTP Server (TLS) id 15.0.1104.5; Fri, 14 Aug 2015 11:22:51 -0500 Received: from xhc-rcd-x04.cisco.com (173.37.183.78) by xch-aln-009.cisco.com (173.36.7.19) with Microsoft SMTP Server (TLS) id 15.0.1104.5 via Frontend Transport; Fri, 14 Aug 2015 11:22:51 -0500 Received: from xmb-rcd-x04.cisco.com ([169.254.8.103]) by xhc-rcd-x04.cisco.com ([173.37.183.78]) with mapi id 14.03.0248.002; Fri, 14 Aug 2015 11:22:50 -0500 From: "Gonzalo Salgueiro (gsalguei)" To: Victor Pascual Thread-Topic: [rtcweb] Call for WG adoption: draft-nandakumar-rtcweb-sdp Thread-Index: AQHQ1pbBxbTRJzFk0U+vwMUYmBTs4p4L4jUAgAAfXgA= Date: Fri, 14 Aug 2015 16:22:50 +0000 Message-ID: <9E1724C8-A135-4814-80C4-6CF6E99E0D9C@cisco.com> References: <2C6E529A-7ECC-4919-973F-5ADFDEE4FA57@ieca.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [173.37.102.18] Content-Type: text/plain; charset="utf-8" Content-ID: <18C1510181217E45B7ED83DC94294469@emea.cisco.com> Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] Call for WG adoption: draft-nandakumar-rtcweb-sdp X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 14 Aug 2015 16:22:54 -0000 SSBzdXBwb3J0IGFkb3B0aW9uLg0KDQotRw0KDQoNCj4gT24gQXVnIDE0LCAyMDE1LCBhdCAxMDoz MCBBTSwgVmljdG9yIFBhc2N1YWwgQXZpbGEgPHZpY3Rvci5wYXNjdWFsLmF2aWxhQGdtYWlsLmNv bT4gd3JvdGU6DQo+IA0KPiBJIHN1cHBvcnQgdGhlIGFkb3B0aW9uIG9mIHRoaXMgZG9jdW1lbnQg YXMgYSBXRyBpdGVtDQo+IA0KPiAtVmljdG9yDQo+IA0KPiBPbiBGcmksIEF1ZyAxNCwgMjAxNSBh dCAzOjM5IFBNLCBTZWFuIFR1cm5lciA8dHVybmVyc0BpZWNhLmNvbT4gd3JvdGU6DQo+IEFsbCwN Cj4gDQo+IEF0IHRoZSBzZWNvbmQgSUVURiA5MyBSVEN3ZWIgc2Vzc2lvbiwgd2UgYWdyZWVkIHRv IHNlbmQgYSBjYWxsIGZvciBXRyBhZG9wdGlvbiBvZiBkcmFmdC1uYW5kYWt1bWFyLXJ0Y3dlYi1z ZHAgYWZ0ZXIgYSB3ZWVrIG9mIHJldmlldy4gIFdlbGwgaXTigJlzIGJlZW4gdHdvIHdlZWtzLiAg U28gd2l0aG91dCBmdXJ0aGVyIGFkbyDigKYgUGxlYXNlIHJlc3BvbmQgdG8gc2F5IHdoZXRoZXIg eW91IHN1cHBvcnQgYWRvcHRpb24gb2YgdGhpcyB3b3JrIGFzIGEgd29ya2luZyBncm91cCB3b3Jr IGl0ZW0gYW5kIHdoZXRoZXIgeW91IHdpbGwgcGFydGljaXBhdGUgaW4gdGhlIGRpc2N1c3Npb24u ICAgSWYgeW91IGFyZSBvcHBvc2VkIHRvIHRoaXMgZHJhZnQgYmVjb21pbmcgYSBXRyBkb2N1bWVu dCwgcGxlYXNlIHNheSBzbyAoYW5kIHNheSB3aHkpLiAgUGxlYXNlIGhhdmUgeW91ciByZXNwb25z ZSBpbiBieSAyMDE1MDgyMSAyMzo1OSBVVEMuDQo+IA0KPiBUaGFua3MgaW4gYWR2YW5jZSENCj4g DQo+IHNwdA0KPiBfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f Xw0KPiBydGN3ZWIgbWFpbGluZyBsaXN0DQo+IHJ0Y3dlYkBpZXRmLm9yZw0KPiBodHRwczovL3d3 dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL3J0Y3dlYg0KPiBfX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KPiBydGN3ZWIgbWFpbGluZyBsaXN0DQo+IHJ0 Y3dlYkBpZXRmLm9yZw0KPiBodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL3J0 Y3dlYg0KDQo= From nobody Fri Aug 14 09:29:51 2015 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0B9A41A8838 for ; Fri, 14 Aug 2015 09:29:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.712 X-Spam-Level: X-Spam-Status: No, score=-2.712 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_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 AOpxL-Phzt2h for ; Fri, 14 Aug 2015 09:29:43 -0700 (PDT) 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 004801A87EB for ; Fri, 14 Aug 2015 09:29:42 -0700 (PDT) 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.14.9/8.14.9) with ESMTP id t7EGTcOP013272 (version=TLSv1/SSLv3 cipher=ECDHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 14 Aug 2015 12:29:39 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=packetizer.com; s=dublin; t=1439569779; bh=SCd64J5pkSkFf/1GmB+VHjoQULymrUJXpevjf6ozezw=; h=From:To:Subject:Date:In-Reply-To:Reply-To; b=X0lVZratGO7XS1a96tzjwZffbN+KxWFQvaJQcFb6UrTVAedHALsPUqaCJ9XYwGTZP sPMbUJtiS92mQDcQoYmU5mo3ELfvPxT+M12pB8Zfs0hF7LUlvWq+iXEsgzUqE+0WJh HVIHo/3HKf7rQn3M/MVxUnHs6P4WIPw+whxhB36c= From: "Paul E. Jones" To: "Sean Turner" , rtcweb@ietf.org Date: Fri, 14 Aug 2015 16:30:02 +0000 Message-Id: In-Reply-To: <2C6E529A-7ECC-4919-973F-5ADFDEE4FA57@ieca.com> User-Agent: eM_Client/6.0.22344.0 Mime-Version: 1.0 Content-Type: text/plain; format=flowed; charset=utf-8 Content-Transfer-Encoding: quoted-printable Archived-At: Subject: Re: [rtcweb] Call for WG adoption: draft-nandakumar-rtcweb-sdp X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: "Paul E. Jones" List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 14 Aug 2015 16:29:45 -0000 I support the adoption. Paul ------ Original Message ------ From: "Sean Turner" To: rtcweb@ietf.org Sent: 8/14/2015 9:39:48 AM Subject: [rtcweb] Call for WG adoption: draft-nandakumar-rtcweb-sdp >All, > >At the second IETF 93 RTCweb session, we agreed to send a call for WG=20 >adoption of draft-nandakumar-rtcweb-sdp after a week of review. Well=20 >it=E2=80=99s been two weeks. So without further ado =E2=80=A6 Please resp= ond to say=20 >whether you support adoption of this work as a working group work item=20 >and whether you will participate in the discussion. If you are=20 >opposed to this draft becoming a WG document, please say so (and say=20 >why). Please have your response in by 20150821 23:59 UTC. > >Thanks in advance! > >spt >_______________________________________________ >rtcweb mailing list >rtcweb@ietf.org >https://www.ietf.org/mailman/listinfo/rtcweb From nobody Fri Aug 14 09:50:40 2015 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id ABFD81A8A47 for ; Fri, 14 Aug 2015 09:50:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.511 X-Spam-Level: X-Spam-Status: No, score=-14.511 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jA8YrmvIpFpL for ; Fri, 14 Aug 2015 09:50:25 -0700 (PDT) Received: from rcdn-iport-5.cisco.com (rcdn-iport-5.cisco.com [173.37.86.76]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 91B811A88E4 for ; Fri, 14 Aug 2015 09:50:25 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=926; q=dns/txt; s=iport; t=1439571025; x=1440780625; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=W0uT3qux5VnbgU5ZJLlmcPFAVZUYeXU3X7vrMiG5tEw=; b=dVO8P8a9QXAQC8ZZKRHH5eW2F10apbPNP5K7Jt/8wGpFXr7aWPTEDG7u ZGW4m98ej2/h6zQutYefBANMg/zE6OGEjnouUsmwFzK3Ca1j3dTUKOoTL LcR6XvhAtdnnqHWotxJmuicnQQ03lEx+9B0ZEpi630EgAlPwrgWlUFomU 8=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: A0CRAgDUG85V/4cNJK1dgxtUab4IAQmBawqFL0oCgUo4FAEBAQEBAQGBCoQkAQEEAQEBGlELEAIBCEYnCyUCBA4FiC4N0AwBAQEBAQEBAQEBAQEBAQEBAQEBAQETBItThFYzB4MYgRQFkg6DDQGMa4FKhCuQSINnJoN9cYJMAQEB X-IronPort-AV: E=Sophos;i="5.15,678,1432598400"; d="scan'208";a="20583203" Received: from alln-core-2.cisco.com ([173.36.13.135]) by rcdn-iport-5.cisco.com with ESMTP; 14 Aug 2015 16:50:24 +0000 Received: from XCH-RCD-001.cisco.com (xch-rcd-001.cisco.com [173.37.102.11]) by alln-core-2.cisco.com (8.14.5/8.14.5) with ESMTP id t7EGoOQk029277 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Fri, 14 Aug 2015 16:50:24 GMT Received: from xch-rcd-001.cisco.com (173.37.102.11) by XCH-RCD-001.cisco.com (173.37.102.11) with Microsoft SMTP Server (TLS) id 15.0.1104.5; Fri, 14 Aug 2015 11:50:24 -0500 Received: from xhc-aln-x01.cisco.com (173.36.12.75) by xch-rcd-001.cisco.com (173.37.102.11) with Microsoft SMTP Server (TLS) id 15.0.1104.5 via Frontend Transport; Fri, 14 Aug 2015 11:50:24 -0500 Received: from xmb-rcd-x14.cisco.com ([169.254.4.116]) by xhc-aln-x01.cisco.com ([173.36.12.75]) with mapi id 14.03.0248.002; Fri, 14 Aug 2015 11:50:23 -0500 From: "Mo Zanaty (mzanaty)" To: Sean Turner Thread-Topic: [rtcweb] Call for WG adoption: draft-nandakumar-rtcweb-sdp Thread-Index: AQHQ1pbBOKRKcIUgS0msbcMfZip7Np4LtXK5 Date: Fri, 14 Aug 2015 16:50:23 +0000 Message-ID: <0605FF0F-8704-403D-8B83-D6316BA77324@cisco.com> References: <2C6E529A-7ECC-4919-973F-5ADFDEE4FA57@ieca.com> In-Reply-To: <2C6E529A-7ECC-4919-973F-5ADFDEE4FA57@ieca.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] Call for WG adoption: draft-nandakumar-rtcweb-sdp X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 14 Aug 2015 16:50:31 -0000 I support adoption and will participate in discussion and review. This is v= ery useful to see SDP for various cases before or after reading lots of spe= cs on detailed rules.=20 Mo On Aug 14, 2015, at 9:40 AM, Sean Turner wrote: All, At the second IETF 93 RTCweb session, we agreed to send a call for WG adopt= ion of draft-nandakumar-rtcweb-sdp after a week of review. Well it=92s bee= n two weeks. So without further ado =85 Please respond to say whether you = support adoption of this work as a working group work item and whether you = will participate in the discussion. If you are opposed to this draft beco= ming a WG document, please say so (and say why). Please have your response= in by 20150821 23:59 UTC. Thanks in advance! spt _______________________________________________ rtcweb mailing list rtcweb@ietf.org https://www.ietf.org/mailman/listinfo/rtcweb From nobody Fri Aug 14 10:06:06 2015 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 078EF1B2A4B for ; Fri, 14 Aug 2015 10:06:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001] 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 DLtnbykyaTjm for ; Fri, 14 Aug 2015 10:06:03 -0700 (PDT) Received: from aso-006-i442.relay.mailchannels.net (aso-006-i442.relay.mailchannels.net [23.91.64.123]) by ietfa.amsl.com (Postfix) with ESMTP id 3F7141B2A59 for ; Fri, 14 Aug 2015 10:06:02 -0700 (PDT) X-Sender-Id: wwwh|x-authuser|randell@jesup.org Received: from r2-chicago.webserversystems.com (ip-10-229-11-165.us-west-2.compute.internal [10.229.11.165]) by relay.mailchannels.net (Postfix) with ESMTPA id CF986120B03 for ; Fri, 14 Aug 2015 17:05:59 +0000 (UTC) X-Sender-Id: wwwh|x-authuser|randell@jesup.org Received: from r2-chicago.webserversystems.com (r2-chicago.webserversystems.com [10.232.141.54]) (using TLSv1 with cipher DHE-RSA-AES256-SHA) by 0.0.0.0:2500 (trex/5.5.1); Fri, 14 Aug 2015 17:06:01 +0000 X-MC-Relay: Neutral X-MailChannels-SenderId: wwwh|x-authuser|randell@jesup.org X-MailChannels-Auth-Id: wwwh X-MC-Loop-Signature: 1439571961016:1497758581 X-MC-Ingress-Time: 1439571961016 Received: from pool-96-227-119-208.phlapa.fios.verizon.net ([96.227.119.208]:59765 helo=[192.168.1.12]) by r2-chicago.webserversystems.com with esmtpsa (TLSv1:DHE-RSA-AES128-SHA:128) (Exim 4.85) (envelope-from ) id 1ZQIQX-000AEz-OX for rtcweb@ietf.org; Fri, 14 Aug 2015 12:05:57 -0500 References: <2C6E529A-7ECC-4919-973F-5ADFDEE4FA57@ieca.com> To: rtcweb@ietf.org From: Randell Jesup Message-ID: <55CE1FA0.8020400@jesup.org> Date: Fri, 14 Aug 2015 13:04:32 -0400 User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.1.0 MIME-Version: 1.0 In-Reply-To: <2C6E529A-7ECC-4919-973F-5ADFDEE4FA57@ieca.com> Content-Type: text/plain; charset=windows-1252; format=flowed X-AuthUser: randell@jesup.org Content-Transfer-Encoding: quoted-printable Archived-At: Subject: Re: [rtcweb] Call for WG adoption: draft-nandakumar-rtcweb-sdp X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 14 Aug 2015 17:06:05 -0000 I support adoption as a WG item On 8/14/2015 9:39 AM, Sean Turner wrote: > At the second IETF 93 RTCweb session, we agreed to send a call for WG a= doption of draft-nandakumar-rtcweb-sdp after a week of review. Well it=92= s been two weeks. So without further ado =85 Please respond to say wheth= er you support adoption of this work as a working group work item and whe= ther you will participate in the discussion. If you are opposed to this= draft becoming a WG document, please say so (and say why). Please have = your response in by 20150821 23:59 UTC. --=20 Randell Jesup -- rjesup a t mozilla d o t com Please please please don't email randell-ietf@jesup.org! Way too much sp= am From nobody Fri Aug 14 10:09:46 2015 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 371401ACE8C for ; Fri, 14 Aug 2015 10:09:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001] 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 xb6Ki5gGqms9 for ; Fri, 14 Aug 2015 10:09:43 -0700 (PDT) Received: from nov-007-i590.relay.mailchannels.net (nov-007-i590.relay.mailchannels.net [46.232.183.144]) by ietfa.amsl.com (Postfix) with ESMTP id 0036D1B2A6E for ; Fri, 14 Aug 2015 10:09:41 -0700 (PDT) X-Sender-Id: wwwh|x-authuser|mdr%reavy.org@r2-chicago.webserversystems.com Received: from r2-chicago.webserversystems.com (ip-10-220-9-73.us-west-2.compute.internal [10.220.9.73]) by relay.mailchannels.net (Postfix) with ESMTPA id 165C4A13B1 for ; Fri, 14 Aug 2015 17:09:36 +0000 (UTC) X-Sender-Id: wwwh|x-authuser|mdr%reavy.org@r2-chicago.webserversystems.com Received: from r2-chicago.webserversystems.com (r2-chicago.webserversystems.com [10.45.8.167]) (using TLSv1 with cipher DHE-RSA-AES256-SHA) by 0.0.0.0:2500 (trex/5.5.1); Fri, 14 Aug 2015 17:09:37 +0000 X-MC-Relay: Neutral X-MailChannels-SenderId: wwwh|x-authuser|mdr%reavy.org@r2-chicago.webserversystems.com X-MailChannels-Auth-Id: wwwh X-MC-Loop-Signature: 1439572177280:165198346 X-MC-Ingress-Time: 1439572177280 Received: from pool-96-227-119-208.phlapa.fios.verizon.net ([96.227.119.208]:54070 helo=[192.168.1.22]) by r2-chicago.webserversystems.com with esmtpsa (TLSv1:DHE-RSA-AES128-SHA:128) (Exim 4.85) (envelope-from ) id 1ZQIU2-000Bbg-Te for rtcweb@ietf.org; Fri, 14 Aug 2015 12:09:34 -0500 To: rtcweb@ietf.org References: <2C6E529A-7ECC-4919-973F-5ADFDEE4FA57@ieca.com> From: Maire Reavy Message-ID: <55CE20C3.3080201@reavy.org> Date: Fri, 14 Aug 2015 13:09:23 -0400 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.0.1 MIME-Version: 1.0 In-Reply-To: <2C6E529A-7ECC-4919-973F-5ADFDEE4FA57@ieca.com> Content-Type: text/plain; charset=windows-1252; format=flowed X-AuthUser: mdr%reavy.org@r2-chicago.webserversystems.com Content-Transfer-Encoding: quoted-printable Archived-At: Subject: Re: [rtcweb] Call for WG adoption: draft-nandakumar-rtcweb-sdp X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 14 Aug 2015 17:09:46 -0000 I support adoption. On 8/14/2015 9:39 AM, Sean Turner wrote: > All, > > At the second IETF 93 RTCweb session, we agreed to send a call for WG a= doption of draft-nandakumar-rtcweb-sdp after a week of review. Well it=92= s been two weeks. So without further ado =85 Please respond to say wheth= er you support adoption of this work as a working group work item and whe= ther you will participate in the discussion. If you are opposed to this= draft becoming a WG document, please say so (and say why). Please have = your response in by 20150821 23:59 UTC. > > Thanks in advance! > > spt > _______________________________________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/listinfo/rtcweb From nobody Fri Aug 14 11:50:39 2015 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 615D31A0398 for ; Fri, 14 Aug 2015 11:50:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.91 X-Spam-Level: X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FLSUfSixnaI0 for ; Fri, 14 Aug 2015 11:50:36 -0700 (PDT) Received: from nostrum.com (raven-v6.nostrum.com [IPv6:2001:470:d:1130::1]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CA6DC1A039D for ; Fri, 14 Aug 2015 11:50:35 -0700 (PDT) Received: from Orochi.local (99-152-145-110.lightspeed.dllstx.sbcglobal.net [99.152.145.110]) (authenticated bits=0) by nostrum.com (8.15.2/8.14.9) with ESMTPSA id t7EIoWbg007558 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NO); Fri, 14 Aug 2015 13:50:32 -0500 (CDT) (envelope-from adam@nostrum.com) X-Authentication-Warning: raven.nostrum.com: Host 99-152-145-110.lightspeed.dllstx.sbcglobal.net [99.152.145.110] claimed to be Orochi.local Message-ID: <55CE3877.6030005@nostrum.com> Date: Fri, 14 Aug 2015 13:50:31 -0500 From: Adam Roach User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:31.0) Gecko/20100101 Thunderbird/31.7.0 MIME-Version: 1.0 To: Sean Turner , rtcweb@ietf.org References: <2C6E529A-7ECC-4919-973F-5ADFDEE4FA57@ieca.com> In-Reply-To: <2C6E529A-7ECC-4919-973F-5ADFDEE4FA57@ieca.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Archived-At: Subject: Re: [rtcweb] Call for WG adoption: draft-nandakumar-rtcweb-sdp X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 14 Aug 2015 18:50:37 -0000 This looks like a useful kind of document to have, and I think the current version forms a good basis to work from. I support the working group taking this document on for publication. /a On 8/14/15 08:39, Sean Turner wrote: > All, > > At the second IETF 93 RTCweb session, we agreed to send a call for WG adoption of draft-nandakumar-rtcweb-sdp after a week of review. Well it’s been two weeks. So without further ado … Please respond to say whether you support adoption of this work as a working group work item and whether you will participate in the discussion. If you are opposed to this draft becoming a WG document, please say so (and say why). Please have your response in by 20150821 23:59 UTC. > > Thanks in advance! > > spt > _______________________________________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/listinfo/rtcweb From nobody Fri Aug 14 13:41:24 2015 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3EF261A8973 for ; Fri, 14 Aug 2015 13:41:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.388 X-Spam-Level: X-Spam-Status: No, score=-1.388 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4y1ZV1ZL0lVW for ; Fri, 14 Aug 2015 13:41:21 -0700 (PDT) Received: from mail-vk0-x22d.google.com (mail-vk0-x22d.google.com [IPv6:2607:f8b0:400c:c05::22d]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7E02C1A896B for ; Fri, 14 Aug 2015 13:41:21 -0700 (PDT) Received: by vkfi73 with SMTP id i73so34683073vkf.2 for ; Fri, 14 Aug 2015 13:41:20 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=5TEPXqy91DSOyt8m+GDlYRXKvLYN3rdin7uuqqIiOX0=; b=ZoyStcHF9dE9TnPxgoIdaxCQHgGwjzApozWHoKdJ6zWg54WGYiDNi1jXiSnQeTRtrR fFjZZK1+jAMaBtB+U7mh24mc4fX09y641Aalwmca595wQCvDqFzB2/trCIjXRL4crFDI F3XMFcd1MTbcjeShPrnkqIzkmKJX+MHZzelPhz9IgMK3MgEPqowP68atK4/TrsJtt38s Y/uSGe3rqBqO0cA2L0xJlrmPdss48gEtmW6I2eak70UcbX3hzZXu4zAy3nCpTt62SNnx qH8vJ5AdMV4Qz0BvY5TGV1J7oFl3VdbaY/jyHuvmzjOs19bMfOBYlA7FHCx+rHd7veUq Prog== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type; bh=5TEPXqy91DSOyt8m+GDlYRXKvLYN3rdin7uuqqIiOX0=; b=bp60RSHDEXpmAllzoR2HInm86DQmE5JbEJlrtykPjwXdm6klI2z+1osQm2h4OG+5eN Stak+nbE1F6QVbzdvab/bwL/U0mPc5WC1btJl6xfPYT2veoccgd7dq0EKQiwXFVBJbb7 3bP9kheOYT3gsD+yjQK78yMw/N5Els5WpEgRHK6thYUdIekBZVRuQ4HUF6x1pZsQJaht g+QUb3+LJqRAFHYiM2a5yOjWw4vtzxosaR7dLBAP3FNLtUqsr0FrLP94+fBcMgDJFgL2 bEBseySkUCa+EeFpgJpDuxSaTS20pIPJiuRAWFWIkW/oZ+SvI/yoHg57VP1KEoDKl1xf Ljvg== X-Gm-Message-State: ALoCoQnJy+2hVNJSbL2470hMy5MsMy0maS7htHNAFtaf9UrFe1T/2awfGuWI7raNG9xHveL02yUv X-Received: by 10.52.186.72 with SMTP id fi8mr56186482vdc.19.1439584880597; Fri, 14 Aug 2015 13:41:20 -0700 (PDT) MIME-Version: 1.0 Received: by 10.31.191.87 with HTTP; Fri, 14 Aug 2015 13:41:00 -0700 (PDT) In-Reply-To: References: <20150805130607.20844.70680.idtracker@ietfa.amsl.com> <55C24293.5000603@cs.tcd.ie> <55C24C09.8020404@goodadvice.pages.de> <55C256C8.80606@jive.com> From: Justin Uberti Date: Fri, 14 Aug 2015 13:41:00 -0700 Message-ID: To: Cullen Jennings Content-Type: multipart/alternative; boundary=bcaec548a8216eea60051d4b7941 Archived-At: Cc: Jonathan Lennox , "rtcweb@ietf.org" , "tram@ietf.org" , mmusic Subject: Re: [rtcweb] [tram] TURN permissions for private ips X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 14 Aug 2015 20:41:23 -0000 --bcaec548a8216eea60051d4b7941 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Makes sense, although not sure that the apps will want to disclose the private IPs of the media servers to endpoints. Overall I think enough arguments have been made that it is safer for the server to enforce this policy than clients, since the TURN server should be more aware of the application topology. On Fri, Aug 14, 2015 at 8:39 AM, Cullen Jennings wrote: > > > On Aug 6, 2015, at 7:14 AM, Jonathan Lennox wrote: > > > > > >> On Aug 5, 2015, at 5:35 PM, Justin Uberti wrote: > >> > >> On Wed, Aug 5, 2015 at 11:32 AM, Simon Perreault > wrote: > >> Le 2015-08-05 13:46, Philipp Hancke a =C3=A9crit : > >> > If a peer sends candidates with IP addresses from the private space, > >> > permissions for those are created at the TURN server. Potentially no= t > >> > utilising transport encryption even. > >> > > >> > I doubt those candidates ever work, so from a privacy point of view = it > >> > seems that clients should not create those permissions in the first > >> > place. And ICE should probably not try to create pairs. > >> > >> It's not up to the client to determine what addresses might not might > >> not work for a given TURN server. There are lots of weird NAT > >> configurations out there that play games with RFC1918 addresses and ca= n > >> easily trick clients into doing the wrong thing. > >> > >> I am somewhat sympathetic to that, but given that there is measurable > downside here - extra candidate pairs that take time to check - can you > supply a concrete example of where the client choosing not to pair a TURN > candidate with a RFC1918 address would cause a problem? > > > > This is really an ICE question, not a TURN question, so adding MMUSIC. > > > > Clearly, if your TURN server is actually on the public internet, pairin= g > RFC1918 address with its candidates won=E2=80=99t do any good. However, = there can > be scenarios where you have a TURN server sitting in a DMZ or the like, > where it can actually route to RFC 1918 addresses. I suspect this will b= e > relevant in the various scenarios where the TURN server is topologically > equivalent to a web proxy. > > > > As I recall from the discussions around the development of ICE, there > are actually a fair number of networks out there which have public IPv4 a= nd > RFC1918 addresses directly routable to each other. The examples I remembe= r > came about as a result of corporate mergers, where one of the pre-merger > companies was using their public address space internally, and the other > wasn=E2=80=99t. > > > > Some SPs are putting all their customers behind CGN (carrier grade NAT) > and then looking at running cloud data centers where other people can ren= t > servers (AWS style) where those servers have public IPs and at the same > time they are directly routable to the all the NATed clients. That allows > you to run media servers (STUN, TURN, Conferences MCU / Switches, caches > etc) that have a low latency connectivity to the SP's customers endpoints= . > Note the customers's themselves often deploy an additional layer of > residential NAT. > > So scenarios like this might be getting more common .... > > > > > --bcaec548a8216eea60051d4b7941 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Makes sense, although not sure that the apps will want to = disclose the private IPs of the media servers to endpoints.

<= div>Overall I think enough arguments have been made that it is safer for th= e server to enforce this policy than clients, since the TURN server should = be more aware of the application topology.=C2=A0

<= br>

On= Fri, Aug 14, 2015 at 8:39 AM, Cullen Jennings <fluffy@iii.ca> w= rote:

> On Aug 6, 2015, at 7:14 AM, Jonathan Lennox <jonathan@vidyo.com> wrote:
>
>
>> On Aug 5, 2015, at 5:35 PM, Justin Uberti <juberti@google.com> wrote:
>>
>> On Wed, Aug 5, 2015 at 11:32 AM, Simon Perreault <sperreault@jive.com> wrote:
>> Le 2015-08-05 13:46, Philipp Hancke a =C3=A9crit :
>> > If a peer sends candidates with IP addresses from the private= space,
>> > permissions for those are created at the TURN server. Potenti= ally not
>> > utilising transport encryption even.
>> >
>> > I doubt those candidates ever work, so from a privacy point o= f view it
>> > seems that clients should not create those permissions in the= first
>> > place. And ICE should probably not try to create pairs.
>>
>> It's not up to the client to determine what addresses might no= t might
>> not work for a given TURN server. There are lots of weird NAT
>> configurations out there that play games with RFC1918 addresses an= d can
>> easily trick clients into doing the wrong thing.
>>
>> I am somewhat sympathetic to that, but given that there is measura= ble downside here - extra candidate pairs that take time to check - can you= supply a concrete example of where the client choosing not to pair a TURN = candidate with a RFC1918 address would cause a problem?
>
> This is really an ICE question, not a TURN question, so adding MMUSIC.=
>
> Clearly, if your TURN server is actually on the public internet, pairi= ng RFC1918 address with its candidates won=E2=80=99t do any good.=C2=A0 How= ever, there can be scenarios where you have a TURN server sitting in a DMZ = or the like, where it can actually route to RFC 1918 addresses.=C2=A0 I sus= pect this will be relevant in the various scenarios where the TURN server i= s topologically equivalent to a web proxy.
>
> As I recall from the discussions around the development of ICE, there = are actually a fair number of networks out there which have public IPv4 and= RFC1918 addresses directly routable to each other. The examples I remember= came about as a result of corporate mergers, where one of the pre-merger c= ompanies was using their public address space internally, and the other was= n=E2=80=99t.
>

Some SPs are putting all their customers behind CGN (carrier gr= ade NAT) and then looking at running cloud data centers where other people = can rent servers (AWS style) where those servers have public IPs and at the= same time they are directly routable to the all the NATed clients. That al= lows you to run media servers (STUN, TURN, Conferences MCU / Switches, cach= es etc) that have a low latency connectivity to the SP's customers endp= oints. Note the customers's themselves often deploy an additional layer= of residential NAT.

So scenarios like this might be getting more common ....





--bcaec548a8216eea60051d4b7941-- From nobody Fri Aug 14 13:44:17 2015 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 637CB1A893E for ; Fri, 14 Aug 2015 13:44:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.388 X-Spam-Level: X-Spam-Status: No, score=-1.388 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PZYU7lnur3CS for ; Fri, 14 Aug 2015 13:44:12 -0700 (PDT) Received: from mail-vk0-x235.google.com (mail-vk0-x235.google.com [IPv6:2607:f8b0:400c:c05::235]) (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 315381A88A5 for ; Fri, 14 Aug 2015 13:44:12 -0700 (PDT) Received: by vkbf67 with SMTP id f67so34084203vkb.3 for ; Fri, 14 Aug 2015 13:44:11 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=64FEPO0OW8LMDW9TzxZifnm2MWBXoTA130r4XLpcapA=; b=Moy3LK4oDeQEGEEeiHAZojE+XwFDYmA4y32ovaBfNAhcRGZW3crAD2H1zNmHpMLm7r VkY2kmbHEKuh5zpINCmg3Qop5rsAV9Ok1hDmWxXdf3CUkZvGYv58qsm89o71yi/gEOzC uSZrnx7ZIKJurJf6wQ3OsYLPeyUeT49d5ipGKrToPw/TbiJtgq8ZmKrrC4p6F9S0M3i6 C32RL6aJFFImk0TtOKnmRNXmBmp9MTn7DmYqdGy3ct6tdvjXMjpB2T+FLp9KRi9bkBRX a4ahYW+h7SqjqVviFLUta0kvpRCFwaKEVk7zKJrI3uHoMkEbhYRSAq4hSa5xg/08jZKt RoJw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type; bh=64FEPO0OW8LMDW9TzxZifnm2MWBXoTA130r4XLpcapA=; b=AZZlHBQwRcONsSJVHMkwzmHK5R40utKaqt5LMY+JtKZ4q6PbKaUHyafmn+rJYtEpDz ++t6MLJFb1NAx9LyUusDhbZYR6q9PezE406+JZemfBK0gJ04GSHVbDrwy3lor3n4t9MP LzPCj2RI79EOTULCTya1Efdoswzmql6dq8IZ0u7NJPNj4YtLpl0/UZJsBuWuo6mKo2p4 b3oXYu3Z2+nqHhBVLVXIXi0qgU8gvqrhDjJdGTQKOFFkirVPbQ/x47Lca4a3ljRgFeg7 TuK/UESiO3+123RuFAacYQQsWmUwPvxMZYzTsjoyd6qqaKy8zk/gKvrd+QvrlN0Gt7lq T4Xw== X-Gm-Message-State: ALoCoQkMmSrIsxpq67ENujhTb9gZDg1qmD0JPlRBhB6ebcvcSi7wXIAy44LPd5Lc1CrtfcgjLv+f X-Received: by 10.52.163.133 with SMTP id yi5mr56015701vdb.26.1439585051383; Fri, 14 Aug 2015 13:44:11 -0700 (PDT) MIME-Version: 1.0 Received: by 10.31.191.87 with HTTP; Fri, 14 Aug 2015 13:43:51 -0700 (PDT) In-Reply-To: References: <8A69E109-3F93-4C61-95F2-375FF2103EAB@vidyo.com> <7594FB04B1934943A5C02806D1A2204B348EF447@ESESSMB209.ericsson.se> <58198CC2-984C-4236-8B90-D20BF050A241@vidyo.com> <7594FB04B1934943A5C02806D1A2204B348EFB2F@ESESSMB209.ericsson.se> <7594FB04B1934943A5C02806D1A2204B348EFCF9@ESESSMB209.ericsson.se> From: Justin Uberti Date: Fri, 14 Aug 2015 13:43:51 -0700 Message-ID: To: Alexandre GOUAILLARD Content-Type: multipart/alternative; boundary=001a11c245209cc3da051d4b8347 Archived-At: Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] Do we have consensus on not requiring rtcp-non-mux? X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 14 Aug 2015 20:44:15 -0000 --001a11c245209cc3da051d4b8347 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable I am happy with proposal #1 and Harald's proposed text change. On Tue, Aug 11, 2015 at 12:38 AM, Alexandre GOUAILLARD < agouaillard@gmail.com> wrote: > +1 for #1 > > On Tue, Aug 11, 2015 at 2:43 AM, Christer Holmberg < > christer.holmberg@ericsson.com> wrote: > >> Hi, >> >> >> >> >Are you seriously advocating =E2=80=9CMAY implement, MUST NOT use=E2=80= =9D? How does >> that make any sense at all? >> >> > >> >> >As I understood Peter=E2=80=99s original option 1, he was proposing to = change >> the spec to allow two types of implementations: >> >> > >> >> >1. Endpoints that always offer mux, but are prepared for an answer that >> declines to do it, at which point they fall back to non-mux. >(The curre= nt >> default behavior, and the behavior required by RFC 5761.) >> >> > >> >> >2. Endpoints that always offer mux, in a way such that there is no way >> to fall back to non-mux. Naive interop with a non-rtcp-mux >endpoint, o= r >> with an endpoint that doesn=E2=80=99t want to do mux, will fail. (The cu= rrent >> rtcpMuxPolicy:"require" behavior.) >> >> > >> >> >If you say that no endpoint can ever do fallback to non-MUX, I don=E2= =80=99t see >> what the point is. You=E2=80=99re instead advocating for Peter=E2=80=99= s >option 2. >> >> >> >> Fair enough, I hear what you=E2=80=99re saying. >> >> >> >> So, if we want to allow fallback to non-MUX, then I DO agree with you >> that we need a way for an entity to indicate that it also supports non-m= ux. >> >> >> >> >As I mentioned earlier in this thread, one solution to my problem =E2= =80=94 >> which I don=E2=80=99t like this because it=E2=80=99s mixing up features = which IMO >should >> be orthogonal, but I would be okay with =E2=80=94 would be to say someth= ing like >> =E2=80=9Coffers that support fallback to non-RTCP-mux >MUST include sepa= rate ICE >> candidates for RTCP, i.e. on component 2; offers that do not support suc= h >> fallback MUST NOT include >such candidates.=E2=80=9D >> >> >> >> That would be an option =E2=80=93 OR you include RTP and RTCP candidates= with >> identical values. >> >> >> >> >The only difficulty with this solution is that it can be ambiguous when >> trickle ICE is being used, since an offer might not include any >candida= tes >> at all. >> >> >> >> > and explain how it would work> :) >> >> >> >> Regards, >> >> >> >> Christer >> >> >> >> >> >> >> >> >> >> >> >> On Aug 10, 2015, at 2:02 PM, Christer Holmberg < >> christer.holmberg@ericsson.com> wrote: >> >> >> >> Hi, >> >> >> >> >The whole point of supporting non-MUX mode is to allow answerers to >> choose not to insert the SDP attribute. >> >> >> >> From a protocol perspective, yes. But, if we say that a WebRTC entity >> MUST support/use rtcp-mux, then it means that it MUST include the attrib= ute >> =E2=80=93 EVEN if the protocol allows it not to. >> >> >> >> >With option 1, the idea is that some endpoints will offer MUX, but >> support fallback to non-MUX if the peer chooses not to do it. >> >> >> >> My understanding of option 1 is that some endpoints will **ONLY** >> implement MUX, and will NOT fallback to non-MUX if the peer (a non-WebRT= C >> entity) chooses not to do it. >> >> >> >> >Some other endpoints will require that MUX be supported, and if a peer >> doesn=E2=80=99t understand this then things will fail in interesting >wa= ys. >> >> >> >> Well, the endpoint that wants MUX will have to terminate the call. >> >> >> >> >If I=E2=80=99m (say) a gateway that would rather do non-MUX (to keep my= life >> easier when gatewaying to legacy equipment), but is willing to >do MUX i= f >> necessary, I need to know which sort of endpoint I=E2=80=99m talking to. >> >> >> >> My understanding of #1 is that there is no such things as =E2=80=9Cwould= rather >> do non-MUX=E2=80=9D. As a WebRTC gateway, you would always do MUX (at le= ast towards >> the WebRTC endpoints). >> >> >> >> >However, both types of endpoints will have inserted the attribute in >> their offer. >> >> >> >> And, as a WebRTC endpoint, you will always insert the attribute in the >> answer. >> >> >> >> >If you require that all entities MUST always insert the SDP attribute i= n >> both offers *and answers*, then you=E2=80=99re choosing option 2. (A >st= andard that >> says =E2=80=9Cyou MAY have code that implements this mode, but you MUST = NOT ever >> use it=E2=80=9D is pretty pointless.) >> >> >> >> Regarding #2, endpoints can implement whatever they want. The point is >> that they would never **USE** non-MUX. >> >> >> >> Regards, >> >> >> >> Christer >> >> >> >> On Aug 10, 2015, at 11:39 AM, Christer Holmberg < >> christer.holmberg@ericsson.com> wrote: >> >> >> >> Hi Jonathan, >> >> Why can't we simply say that entities MUST insert the SDP attribute in >> offers and answers? >> >> Regards, >> >> Christer >> >> Sent from my Windows Phone >> ------------------------------ >> >> *From: *Jonathan Lennox >> *Sent: *=E2=80=8E10/=E2=80=8E08/=E2=80=8E2015 17:46 >> *To: *Google-Peter Thatcher >> *Cc: *rtcweb@ietf.org >> *Subject: *Re: [rtcweb] Do we have consensus on not requiring >> rtcp-non-mux? >> >> #1 seems best to me, but there needs to be some well-specified way for J= S >> applications and offer/answer peers to discover/understand whether >> rtcp-non-mux is indeed supported. Otherwise there=E2=80=99s no practica= l >> difference between #1 and #2. >> >> >> >> >> On Aug 7, 2015, at 5:39 PM, Peter Thatcher wrote: >> >> >> >> After lots of discussion, it appears we have three options: >> >> >> >> 1. Endpoints MAY implement rtcp-non-mux (we change the spec and can >> delete the ugly code) >> >> >> >> 2. Endpoints MUST NOT implement rtcp-non-mux (we change the spec and >> must delete the ugly code, and our non-compliant until we do) >> >> >> >> 3. Endpoints MUST implement rtcp-non-mux (we don't change the spec and >> keep around the ugly code) >> >> >> >> >> >> My reading of the discussion is that most people want #1 or #2, and very >> few people still want #3. Between #1 and #2, while some people would >> prefer #2, there are good reasons to just do #1, and most seem to prefer >> #1. Further, I'm guessing that most people who wanted #2 could live wit= h >> #1. >> >> >> >> >> >> TL;DR: I think we may have rough consensus on #1, saying endpoints MAY >> rtcp-non-mux (but may choose to delete all that ugly code instead). >> >> >> >> >> >> So, is everyone happy with #1? >> >> >> >> >> >> >> >> _______________________________________________ >> rtcweb mailing list >> rtcweb@ietf.org >> https://www.ietf.org/mailman/listinfo/rtcweb >> >> >> >> _______________________________________________ >> rtcweb mailing list >> rtcweb@ietf.org >> https://www.ietf.org/mailman/listinfo/rtcweb >> >> > > > -- > Alex. Gouaillard, PhD, PhD, MBA > > -------------------------------------------------------------------------= ----------- > CTO - Temasys Communications, S'pore / Mountain View > President - CoSMo Software, Cambridge, MA > > -------------------------------------------------------------------------= ----------- > sg.linkedin.com/agouaillard > > - > > > _______________________________________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/listinfo/rtcweb > > --001a11c245209cc3da051d4b8347 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
I am happy with proposal #1 and Harald's proposed text= change.

On = Tue, Aug 11, 2015 at 12:38 AM, Alexandre GOUAILLARD <<= a href=3D"mailto:agouaillard@gmail.com" target=3D"_blank">agouaillard@gmail= .com> wrote:
+1 for #1

On Tue, Aug 11, 2015 at 2:43 AM, Christer Holmberg = <christer.holmberg@ericsson.com> wrote:

Hi,

=C2=A0

>Are you seriously advocating =E2=80=9CMAY implem= ent, MUST NOT use=E2=80=9D?=C2=A0 How does that make any sense at all?

>=C2=A0

>As I understood Peter=E2=80=99s original option = 1, he was proposing to change the spec to allow two types of implementation= s:

>=C2=A0

>1. Endpoints that always offer mux, but are prep= ared for an answer that declines to do it, at which point they fall back to= non-mux. >(The current default behavior, and the behavior required by R= FC 5761.)

>=C2=A0

>2. Endpoints that always offer mux, in a way suc= h that there is no way to fall back to non-mux.=C2=A0 Naive interop with a = non-rtcp-mux >endpoint, or with an endpoint that doesn=E2=80=99t want to= do mux, will fail. (The current rtcpMuxPolicy:"require" behavior.)

>=C2=A0

>If you say that no endpoint can ever do fallback= to non-MUX, I don=E2=80=99t see what the point is.=C2=A0 You=E2=80=99re in= stead advocating for Peter=E2=80=99s >option 2.

=C2=A0

Fair enough, I hear what you=E2=80=99re sayin= g.

=C2=A0

So, if we want to allow fallback to non-MUX, then I = DO agree with you that we need a way for an entity to indicate that it also= supports non-mux.

=C2=A0

>As I mentioned earlier in this thread, one solut= ion to my problem =E2=80=94 which I don=E2=80=99t like this because it=E2= =80=99s mixing up features which IMO >should be orthogonal, but I would = be okay with =E2=80=94 would be to say something like =E2=80=9Coffers that = support fallback to non-RTCP-mux >MUST include separate ICE candidates for RTCP= , i.e. on component 2; offers that do not support such fallback MUST NOT in= clude >such candidates.=E2=80=9D

=C2=A0

That would be an option =E2=80=93 OR you inc= lude RTP and RTCP candidates with identical values.

=C2=A0

>The only difficulty with this solution is that i= t can be ambiguous when trickle ICE is being used, since an offer might not= include any >candidates at all.

=C2=A0

<This is the place where Emil will reply,= saying that he sees no issue, and explain how it would work> :)<= u>

=C2=A0

Regards,

=C2=A0

Christer

=C2=A0

=C2=A0

=C2=A0

=C2=A0

=C2=A0

On Aug 10, 2015, at 2:02 PM, Christer Holmberg <<= a href=3D"mailto:christer.holmberg@ericsson.com" target=3D"_blank">christer= .holmberg@ericsson.com> wrote:

=C2=A0

Hi,

=C2=A0

>The whole point of supporting non-MUX mode is to= allow answerers to choose not to insert the SDP attribute.

=C2=A0

From a protocol perspective, yes. But, if we say th= at a WebRTC entity MUST support/use rtcp-mux, then it means that it MUST in= clude the attribute =E2=80=93 EVEN if the protocol allows it not to.

=C2=A0

>With option 1, the idea is that some endpoints w= ill offer MUX, but support fallback to non-MUX if the peer chooses not to d= o it.

=C2=A0

My understanding of option 1 is that some endpoints= will *ONLY* implement MUX, and will NOT fallback to non-MUX if the = peer (a non-WebRTC entity) chooses not to do it.

=C2=A0

>Some other endpoints will require that MUX be su= pported, and if a peer doesn=E2=80=99t understand this then things will fai= l in interesting >ways.

=C2=A0

Well, the endpoint that wants MUX will have to term= inate the call.

=C2=A0

>If I=E2=80=99m (say) a gateway that would rather= do non-MUX (to keep my life easier when gatewaying to legacy equipment), b= ut is willing to >do MUX if necessary, I need to know which sort of endp= oint I=E2=80=99m talking to.

=C2=A0

My understanding of #1 is that there is no such thi= ngs as =E2=80=9Cwould rather do non-MUX=E2=80=9D. As a WebRTC gateway, you = would always do MUX (at least towards the WebRTC endpoints).<= u>

=C2=A0

>However, both types of endpoints will have inser= ted the attribute in their offer.

=C2=A0

And, as a WebRTC endpoint, you will always insert t= he attribute in the answer.

=C2=A0

>If you require that all entities MUST always ins= ert the SDP attribute in both offers *and answers*, then you=E2=80=99re cho= osing option 2. (A >standard that says =E2=80=9Cyou MAY have code that i= mplements this mode, but you MUST NOT ever use it=E2=80=9D is pretty pointless.)

=C2=A0

Regarding #2, endpoints can implement whatever they= want. The point is that they would never *USE* non-MUX.

=C2=A0

Regards,

=C2=A0

Christer

=C2=A0

On Aug 10, 2015, at 11:39 AM, Christer Holmberg <= christer.holmberg@ericsson.com> wrote:<= u>

=C2=A0

Hi Jonathan,

Why can't we simply say that entities MUST insert the SDP attribute in = offers and answers?

Regards,

Christer

Sent from my Windows Phone

From:=C2=A0= = Jonathan Lennox
Sent:=C2=A0=E2=80=8E10/=E2=80=8E08/=E2=80=8E20= 15 17:46
To:=C2=A0Google-Peter Thatcher
Cc:=C2=A0rtcweb@ietf.org
Subject:=C2=A0Re: [rtcweb] Do we have consensu= s on not requiring rtcp-non-mux?

#1 seems best to me, but there needs to be some well= -specified way for JS applications and offer/answer peers to discover/under= stand whether rtcp-non-mux is indeed supported.=C2=A0 Otherwise there=E2=80= =99s no practical difference between #1 and #2.




On Aug 7, 2015, at 5:39 PM, Peter Thatcher <pthatcher@google.com> wrote:

=C2=A0

After lots of discussion, it appears we have three options:<= /u>

=C2=A0

1.=C2=A0 Endpoints MAY implement rtcp-non-mux (we change the spec and = can delete the ugly code)

=C2=A0

2.=C2=A0 Endpoints MUST NOT implement rtcp-non-mux (we change the spec= and must delete the ugly code, and our non-compliant until we do)

=C2=A0

3.=C2=A0 Endpoints MUST implement rtcp-non-mux (we don't change th= e spec and keep around the ugly code)

=C2=A0

=C2=A0

My reading of the discussion is that most people want #1 or #2, and ve= ry few people still want #3. =C2=A0 Between #1 and #2, while some people wo= uld prefer #2, there are good reasons to just do #1, and most seem to prefer #1.=C2=A0 Further, I'm guessing that most peop= le who wanted #2 could live with #1.

=C2=A0

=C2=A0

TL;DR: =C2=A0I think we may have rough consensus on #1, saying endpoin= ts MAY rtcp-non-mux (but may choose to delete all that ugly code instead). = =C2=A0

=C2=A0

=C2=A0

So, is everyone happy with #1?

=C2=A0

=C2=A0

=C2=A0

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

=C2=A0


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




--
Al= ex. Gouaillard, PhD, PhD, MBA
-----------------------------------------= -------------------------------------------
CTO - Temasys Communi= cations, S'pore / Mountain View
President - CoSMo Software, C= ambridge, MA
----------------------------------------------------= --------------------------------
=


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


--089e01177373a22b25051d89aeab-- From nobody Tue Aug 18 02:16:36 2015 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 456341B2FA1 for ; Tue, 18 Aug 2015 02:16:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.909 X-Spam-Level: X-Spam-Status: No, score=-1.909 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gh_dWu-3nOxz for ; Tue, 18 Aug 2015 02:16:32 -0700 (PDT) Received: from mork.alvestrand.no (mork.alvestrand.no [IPv6:2001:700:1:2::117]) by ietfa.amsl.com (Postfix) with ESMTP id 1FBC01B2F7B for ; Tue, 18 Aug 2015 02:16:32 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mork.alvestrand.no (Postfix) with ESMTP id 4D6077C5330 for ; Tue, 18 Aug 2015 11:16:31 +0200 (CEST) X-Virus-Scanned: Debian amavisd-new at alvestrand.no Received: from mork.alvestrand.no ([127.0.0.1]) by localhost (mork.alvestrand.no [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id e8CYxNd2hUj4 for ; Tue, 18 Aug 2015 11:16:29 +0200 (CEST) Received: from hta-hippo.lul.corp.google.com (unknown [IPv6:2620:0:1043:1:e96a:9d62:39a1:7a85]) by mork.alvestrand.no (Postfix) with ESMTPSA id 589317C5325 for ; Tue, 18 Aug 2015 11:16:29 +0200 (CEST) Message-ID: <55D2F7EC.2050001@alvestrand.no> Date: Tue, 18 Aug 2015 11:16:28 +0200 From: Harald Alvestrand User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.8.0 MIME-Version: 1.0 To: rtcweb@ietf.org References: <55D03AC6.4080100@ericsson.com> In-Reply-To: Content-Type: multipart/alternative; boundary="------------090603030607000503090809" Archived-At: Subject: Re: [rtcweb] Do we have consensus on not requiring rtcp-non-mux? X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 18 Aug 2015 09:16:35 -0000 This is a multi-part message in MIME format. --------------090603030607000503090809 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit On 08/18/2015 12:53 AM, Peter Thatcher wrote: > > > . > > > > The reason is why I see it is as very important that WebRTC > endpoints support non-mux is that otherwise one creates an > interoperability issue, possible future one. RTCP Mux can only > work under some restrictions regarding the Payload Type (PT) > assignment. A gateway between an endpoint doing mux and one not > doing it will thus have be capable of rewriting PTs. As PTs > sometimes have been included in RTCP formats, that requires the > Gateway to understand and be capable of rewriting them. Thus, the > gateway MUST understand everything that goes into the RTCP packet. > This requirement prevents changes or additions to RTCP across > gateways as it means that also the gateway has to be updated, not > only having the capability in both endpoints. It also increases > the complexity of the gateway. > > > ​Please correct me if I'm wrong, but I believe this is only a problem > if the RTP endpoints choose PTs in the range 64-95. RFC 5761 says > "for the choice of RTP payload type values ... values in the range > 64-95 MUST NOT be used". If so, are we really only concerning > ourselves with code complexity for gateways that speak to RTCWEB > endpoints one end and legacy RTP endpoints that don't follow 5761 on > the other end? > > If it's a question of "possible future" code complexity in gateways > versus very real code complexity that is slowing down RTCWEB > implementations today, I'm in favor of removing the real code > complexity we have now and taking the chance on the possible future > code complexity, because it's a very real possibility that possible > future code complexity will never be necessary. In the end, it might > be easier to just not choose PTs inside the range 64-95. I believe the conclusion of Cullen's review was that there was no implementation that offered ICE and not RTCPMUX. Thus, anything that creates issues must come in via a gateway. For argument's sake, let's say it's a gateway where the non-WebRTC side is using SDP offer/answer. In the case where the offer comes from WebRTC, there is no problem; the WebRTC-generated offer will never contain PT values in the range 64-95, and therefore the answer will not either. In the case where the offer comes from the other side, there are two cases: - Offer contains RTCPMUX, and does not use PT values in the 64-95 range. Not A Problem. - Offer does not contain RTCPMUX, but does not use PT values in the 64-95 range. Gateway adds in RTCPMUX, and sets up to mux/demux packets during the call. Not A Problem. - Offer does not contain RTCPMUX, and uses PT values in the 64-95 range. This may be a problem. A protocol-valid implementation choice is for the gateway to strip out those PT values from the offer. This will likely result in an useless offer (because the payload one wants to send can't be sent). If the "outside" system is able to handle a reversing of the offer/answer direction, a valid response is to reject the outside offer and let the gateway construct a counteroffer without the "wrong" PT values. If the "outside" system isn't able to do so, AND the gateway isn't capable of doing the RTCP manipulation that Magnus alludes to, the offer just has to be rejected at the gateway. How important is this case? And over time - will this case become more or less important? (My bet is on "less important" - any new product will have RTCPMUX from the get-go. I could be wrong.) Harald --------------090603030607000503090809 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: 8bit
On 08/18/2015 12:53 AM, Peter Thatcher wrote:


<snip>
.

 
The reason is why I see it is as very important that WebRTC endpoints support non-mux is that otherwise one creates an interoperability issue, possible future one. RTCP Mux can only work under some restrictions regarding the Payload Type (PT) assignment. A gateway between an endpoint doing mux and one not doing it will thus have be capable of rewriting PTs. As PTs sometimes have been included in RTCP formats, that requires the Gateway to understand and be capable of rewriting them. Thus, the gateway MUST understand everything that goes into the RTCP packet. This requirement prevents changes or additions to RTCP across gateways as it means that also the gateway has to be updated, not only having the capability in both endpoints. It also increases the complexity of the gateway.


​Please correct me if I'm wrong, but I believe this is only a problem if the RTP endpoints choose PTs in the range 64-95.  RFC 5761 says "for the choice of RTP payload type values ... values in the range 64-95 MUST NOT be used".  If so, are we really only concerning ourselves with code complexity for gateways that speak to RTCWEB endpoints one end and legacy RTP endpoints that don't follow 5761 on the other end? 

If it's a question of "possible future" code complexity in gateways versus very real code complexity that is slowing down RTCWEB implementations today, I'm in favor of removing the real code complexity we have now and taking the chance on the possible future code complexity, because it's a very real possibility that possible future code complexity will never be necessary.   In the end, it might be easier to just not choose PTs inside the range 64-95.

I believe the conclusion of Cullen's review was that there was no implementation that offered ICE and not RTCPMUX. Thus, anything that creates issues must come in via a gateway.

For argument's sake, let's say it's a gateway where the non-WebRTC side is using SDP offer/answer.

In the case where the offer comes from WebRTC, there is no problem; the WebRTC-generated offer will never contain PT values in the range 64-95, and therefore the answer will not either.

In the case where the offer comes from the other side, there are two cases:

- Offer contains RTCPMUX, and does not use PT values in the 64-95 range. Not A Problem.
- Offer does not contain RTCPMUX, but does not use PT values in the 64-95 range. Gateway adds in RTCPMUX, and sets up to mux/demux packets during the call. Not A Problem.
- Offer does not contain RTCPMUX, and uses PT values in the 64-95 range. This may be a problem.

A protocol-valid implementation choice is for the gateway to strip out those PT values from the offer. This will likely result in an useless offer (because the payload one wants to send can't be sent).

If the "outside" system is able to handle a reversing of the offer/answer direction, a valid response is to reject the outside offer and let the gateway construct a counteroffer without the "wrong" PT values.

If the "outside" system isn't able to do so, AND the gateway isn't capable of doing the RTCP manipulation that Magnus alludes to, the offer just has to be rejected at the gateway.

How important is this case?
And over time - will this case become more or less important?
(My bet is on "less important" - any new product will have RTCPMUX from the get-go. I could be wrong.)

Harald

--------------090603030607000503090809-- From nobody Tue Aug 18 02:28:14 2015 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 800261B32C9 for ; Tue, 18 Aug 2015 02:28:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lEkHFxGh_3oG for ; Tue, 18 Aug 2015 02:28:10 -0700 (PDT) Received: from smtp001.apm-internet.net (smtp001-out.apm-internet.net [85.119.248.222]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E82091B32CB for ; Tue, 18 Aug 2015 02:28:09 -0700 (PDT) Received: (qmail 72941 invoked from network); 18 Aug 2015 09:28:08 -0000 X-AV-Scan: clean X-APM-Authkey: 83769/0 3780 Received: from unknown (HELO zimbra003.verygoodemail.com) (85.119.248.218) by smtp001.apm-internet.net with SMTP; 18 Aug 2015 09:28:08 -0000 Received: from zimbra003.verygoodemail.com (localhost [127.0.0.1]) by zimbra003.verygoodemail.com (Postfix) with ESMTP id 231B318A0A31; Tue, 18 Aug 2015 10:28:08 +0100 (BST) Received: from limit.westhawk.co.uk (unknown [192.67.4.33]) by zimbra003.verygoodemail.com (Postfix) with ESMTPSA id F14BD18A0514; Tue, 18 Aug 2015 10:28:07 +0100 (BST) Content-Type: multipart/alternative; boundary="Apple-Mail=_ADE59268-AC71-4D7C-84F1-1CC93A1ADEC5" Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2102\)) From: Tim Panton In-Reply-To: <55D2F7EC.2050001@alvestrand.no> Date: Tue, 18 Aug 2015 10:28:36 +0100 Message-Id: <5E8AFC8C-AFC5-4DE8-B9B5-6B24D70E830A@phonefromhere.com> References: <55D03AC6.4080100@ericsson.com> <55D2F7EC.2050001@alvestrand.no> To: Harald Alvestrand X-Mailer: Apple Mail (2.2102) Archived-At: Cc: rtcweb@ietf.org Subject: Re: [rtcweb] Do we have consensus on not requiring rtcp-non-mux? X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 18 Aug 2015 09:28:13 -0000 --Apple-Mail=_ADE59268-AC71-4D7C-84F1-1CC93A1ADEC5 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 > On 18 Aug 2015, at 10:16, Harald Alvestrand > wrote: >=20 > On 08/18/2015 12:53 AM, Peter Thatcher wrote: >>=20 >>=20 > >> . >>=20 >> =20 >> The reason is why I see it is as very important that WebRTC endpoints = support non-mux is that otherwise one creates an interoperability issue, = possible future one. RTCP Mux can only work under some restrictions = regarding the Payload Type (PT) assignment. A gateway between an = endpoint doing mux and one not doing it will thus have be capable of = rewriting PTs. As PTs sometimes have been included in RTCP formats, that = requires the Gateway to understand and be capable of rewriting them. = Thus, the gateway MUST understand everything that goes into the RTCP = packet. This requirement prevents changes or additions to RTCP across = gateways as it means that also the gateway has to be updated, not only = having the capability in both endpoints. It also increases the = complexity of the gateway. >>=20 >>=20 >> =E2=80=8BPlease correct me if I'm wrong, but I believe this is only a = problem if the RTP endpoints choose PTs in the range 64-95. RFC 5761 = says "for the choice of RTP payload type values ... values in the range = 64-95 MUST NOT be used". If so, are we really only concerning ourselves = with code complexity for gateways that speak to RTCWEB endpoints one end = and legacy RTP endpoints that don't follow 5761 on the other end?=20 >>=20 >> If it's a question of "possible future" code complexity in gateways = versus very real code complexity that is slowing down RTCWEB = implementations today, I'm in favor of removing the real code complexity = we have now and taking the chance on the possible future code = complexity, because it's a very real possibility that possible future = code complexity will never be necessary. In the end, it might be = easier to just not choose PTs inside the range 64-95. >=20 > I believe the conclusion of Cullen's review was that there was no = implementation that offered ICE and not RTCPMUX. Thus, anything that = creates issues must come in via a gateway. >=20 > For argument's sake, let's say it's a gateway where the non-WebRTC = side is using SDP offer/answer. >=20 > In the case where the offer comes from WebRTC, there is no problem; = the WebRTC-generated offer will never contain PT values in the range = 64-95, and therefore the answer will not either. >=20 > In the case where the offer comes from the other side, there are two = cases: >=20 > - Offer contains RTCPMUX, and does not use PT values in the 64-95 = range. Not A Problem. > - Offer does not contain RTCPMUX, but does not use PT values in the = 64-95 range. Gateway adds in RTCPMUX, and sets up to mux/demux packets = during the call. Not A Problem. > - Offer does not contain RTCPMUX, and uses PT values in the 64-95 = range. This may be a problem. >=20 > A protocol-valid implementation choice is for the gateway to strip out = those PT values from the offer. This will likely result in an useless = offer (because the payload one wants to send can't be sent). >=20 > If the "outside" system is able to handle a reversing of the = offer/answer direction, a valid response is to reject the outside offer = and let the gateway construct a counteroffer without the "wrong" PT = values. >=20 > If the "outside" system isn't able to do so, AND the gateway isn't = capable of doing the RTCP manipulation that Magnus alludes to, the offer = just has to be rejected at the gateway. >=20 > How important is this case? > And over time - will this case become more or less important? > (My bet is on "less important" - any new product will have RTCPMUX = from the get-go. I could be wrong.) Agreed. What=E2=80=99s more the gateway can always be configured to work = around the problem by: a) transcoding - the chances are that such a gateway is probably capable = of transcoding from amr-wb to opus (or similar) - it can transcode and fix the pt value as a side effect. b) just re-write the the ptype - in effect transcoding from ulaw to ulaw = but updating the ptype.=20 (If I remember correctly we wrote a gateway that did this 3 years ago). Tim. >=20 > Harald >=20 > _______________________________________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/listinfo/rtcweb Tim Panton - Web/VoIP consultant and implementor www.westhawk.co.uk --Apple-Mail=_ADE59268-AC71-4D7C-84F1-1CC93A1ADEC5 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8
On 18 Aug 2015, at 10:16, Harald Alvestrand = <harald@alvestrand.no> wrote:

=20 =20
On 08/18/2015 12:53 AM, Peter = Thatcher wrote:


<snip>
.

 
The reason is why I see it is as very important that WebRTC endpoints support non-mux is that otherwise one creates an interoperability issue, possible future one. RTCP Mux can only work under some restrictions regarding the Payload Type (PT) assignment. A gateway between an endpoint doing mux and one not doing it will thus have be capable of rewriting PTs. As PTs sometimes have been included in RTCP formats, that requires the Gateway to understand and be capable of rewriting them. Thus, the gateway MUST understand everything that goes into the RTCP packet. This requirement prevents changes or additions to RTCP across gateways as it means that also the gateway has to be updated, not only having the capability in both endpoints. It also increases the complexity of the gateway.


=E2=80=8BPlease correct me if I'm wrong, but I believe this is only a problem if the RTP endpoints choose PTs in the range 64-95.  RFC 5761 says "for the choice of RTP = payload type values ... values in the range 64-95 MUST NOT be used".  If so, are we really only concerning = ourselves with code complexity for gateways that speak to RTCWEB endpoints one end and legacy RTP endpoints that don't follow 5761 on the other end? 

If it's a question of "possible future" code complexity in gateways versus very real code complexity that is slowing down RTCWEB implementations today, I'm in favor of removing the real code complexity we have now and taking the chance on the possible future code complexity, because it's a very real possibility that possible future code complexity will never be necessary.   In the end, it might be easier to just not choose = PTs inside the range 64-95.

I believe the conclusion of Cullen's review was that there was no implementation that offered ICE and not RTCPMUX. Thus, anything that creates issues must come in via a gateway.

For argument's sake, let's say it's a gateway where the non-WebRTC side is using SDP offer/answer.

In the case where the offer comes from WebRTC, there is no problem; the WebRTC-generated offer will never contain PT values in the range 64-95, and therefore the answer will not either.

In the case where the offer comes from the other side, there are two cases:

- Offer contains RTCPMUX, and does not use PT values in the 64-95 range. Not A Problem.
- Offer does not contain RTCPMUX, but does not use PT values in the 64-95 range. Gateway adds in RTCPMUX, and sets up to mux/demux packets during the call. Not A Problem.
- Offer does not contain RTCPMUX, and uses PT values in the 64-95 range. This may be a problem.

A protocol-valid implementation choice is for the gateway to strip out those PT values from the offer. This will likely result in an useless offer (because the payload one wants to send can't be = sent).

If the "outside" system is able to handle a reversing of the offer/answer direction, a valid response is to reject the outside offer and let the gateway construct a counteroffer without the "wrong" PT values.

If the "outside" system isn't able to do so, AND the gateway isn't capable of doing the RTCP manipulation that Magnus alludes to, the offer just has to be rejected at the gateway.

How important is this case?
And over time - will this case become more or less important?
(My bet is on "less important" - any new product will have RTCPMUX from the get-go. I could be wrong.)

Agreed. What=E2=80=99s more the gateway = can always be configured to work around the problem by:
a) transcoding - the chances are that such a gateway is = probably capable of transcoding from amr-wb to opus (or similar) - it = can transcode and
fix the pt value as a side = effect.
b) just re-write the the ptype - in effect = transcoding from ulaw to ulaw but updating the ptype. 
(If I remember correctly we wrote a gateway that did this 3 = years ago).

Tim.


Harald

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

Tim Panton - = Web/VoIP consultant and implementor
www.westhawk.co.uk



= --Apple-Mail=_ADE59268-AC71-4D7C-84F1-1CC93A1ADEC5-- From nobody Tue Aug 18 05:40:16 2015 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 915A21A1B7F for ; Tue, 18 Aug 2015 05:40:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.909 X-Spam-Level: X-Spam-Status: No, score=-6.909 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, 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 n5XwAHyKHVB2 for ; Tue, 18 Aug 2015 05:40:12 -0700 (PDT) Received: from smtp-fr.alcatel-lucent.com (fr-hpida-esg-02.alcatel-lucent.com [135.245.210.21]) (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 34E721A1B5B for ; Tue, 18 Aug 2015 05:40:12 -0700 (PDT) Received: from fr712usmtp2.zeu.alcatel-lucent.com (unknown [135.239.2.42]) by Websense Email Security Gateway with ESMTPS id F2A942E893450; Tue, 18 Aug 2015 12:40:07 +0000 (GMT) Received: from FR711WXCHHUB01.zeu.alcatel-lucent.com (fr711wxchhub01.zeu.alcatel-lucent.com [135.239.2.111]) by fr712usmtp2.zeu.alcatel-lucent.com (GMO) with ESMTP id t7ICdxrD014027 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Tue, 18 Aug 2015 14:40:08 +0200 Received: from FR711WXCHMBA03.zeu.alcatel-lucent.com ([169.254.3.123]) by FR711WXCHHUB01.zeu.alcatel-lucent.com ([135.239.2.111]) with mapi id 14.03.0195.001; Tue, 18 Aug 2015 14:40:04 +0200 From: "Schwarz, Albrecht (Albrecht)" To: Tim Panton , Harald Alvestrand Thread-Topic: [rtcweb] Do we have consensus on not requiring rtcp-non-mux? Thread-Index: AQHQ0VmYmsgq0idJGkiPJknB0367TZ4OJRAAgANlgSf//+G4AIAAU9XQ Date: Tue, 18 Aug 2015 12:40:03 +0000 Message-ID: <786615F3A85DF44AA2A76164A71FE1AC7ADC1ADA@FR711WXCHMBA03.zeu.alcatel-lucent.com> References: <55D03AC6.4080100@ericsson.com> <55D2F7EC.2050001@alvestrand.no> <5E8AFC8C-AFC5-4DE8-B9B5-6B24D70E830A@phonefromhere.com> In-Reply-To: <5E8AFC8C-AFC5-4DE8-B9B5-6B24D70E830A@phonefromhere.com> Accept-Language: de-DE, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [135.239.27.41] Content-Type: multipart/alternative; boundary="_000_786615F3A85DF44AA2A76164A71FE1AC7ADC1ADAFR711WXCHMBA03z_" MIME-Version: 1.0 Archived-At: Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] Do we have consensus on not requiring rtcp-non-mux? X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 18 Aug 2015 12:40:15 -0000 --_000_786615F3A85DF44AA2A76164A71FE1AC7ADC1ADAFR711WXCHMBA03z_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 Q29uY3VyIHRvIHRoZSBldmFsdWF0aW9uIG9mIFRpbSwgSGFyYWxkIGFuZCBDdWxsZW4uDQpUaGUg bWVkaWEgcGxhbmUgV2ViUlRDIGdhdGV3YXkgcHJvdmlkZXMgYSBzcGVjaWZpYyDigJxSVFAgdG9w b2xvZ3nigJ0gZm9yIHRoZSBpbnRlcndvcmtpbmcgb2YgYWxsIFJUUC1iYXNlZCBXZWJSVEMgc2Vy dmljZSBjb21wb25lbnRzLg0KRWl0aGVyIGFuDQphKSBSVFAgTWVkaWEgVHJhbnNsYXRvciAoUlRQ TVQpIG9yIEJhY2stdG8tQmFjayBSVFAgRW5kc3lzdGVtIChCMkJSRSkgaW4gY2FzZSBvZiBtZWRp YSBwcm9jZXNzaW5nIChzdWNoIGFzIHRyYW5zY29kaW5nKQ0KPT4gbm8gaXNzdWUNCmIpIFJUUCBU cmFuc3BvcnQgVHJhbnNsYXRvciAoUlRQTVQpICh3aGljaCBtYXkgYmUgYWxzbyBjb3ZlcmVkIGJ5 IGEgQmFjay10by1CYWNrIFJUUCBFbmRzeXN0ZW0gKEIyQlJFKSkNCj0+IG5vIGlzc3VlIChiZWNh dXNlIFBUIG1hcHBpbmcgaXMgaW5jbHVkZWQgaW4gdGhpcyBtb2RlKQ0Kb3INCmMpIFJUUCBUcmFu c3BhcmVudCBGb3J3YXJkaW5nIChURikg4oCmDQoNClRoZSBwYXJ0aWN1bGFyIFJUUCB0b3BvbG9n eSBkZXBlbmRzIG9uIHRoZSB0d28g4oCcUlRQIHByb2ZpbGVz4oCdIGFwcGxpZWQgaW4gdGhlIFdl YlJUQyBhbmQgbm9uLVdlYlJUQyBkb21haW4uDQpUaGUgc2VsZWN0ZWQgUlRQIHRvcG9sb2d5IGlz IG1lZGlhLXR5cGUgZGVwZW5kZW50LCBpLmUuIHRoZXJl4oCZbGwgYmUgYSBzcGVjaWZpYyBSVFAg dG9wb2xvZ3kgZm9yIGF1ZGlvIGFuZCB2aWRlbyAo4oCcYW5kIGJvdGggbWlnaHQgYmUgZGlmZmVy ZW504oCdKS4NCg0KVGh1cywgYWxzbyBmYWlsIHRvIHNlZSBhbnkgcmVhbCBpc3N1ZXMsDQpBbGJy ZWNodA0KDQpGcm9tOiBydGN3ZWIgW21haWx0bzpydGN3ZWItYm91bmNlc0BpZXRmLm9yZ10gT24g QmVoYWxmIE9mIFRpbSBQYW50b24NClNlbnQ6IERpZW5zdGFnLCAxOC4gQXVndXN0IDIwMTUgMTE6 MjkNClRvOiBIYXJhbGQgQWx2ZXN0cmFuZA0KQ2M6IHJ0Y3dlYkBpZXRmLm9yZw0KU3ViamVjdDog UmU6IFtydGN3ZWJdIERvIHdlIGhhdmUgY29uc2Vuc3VzIG9uIG5vdCByZXF1aXJpbmcgcnRjcC1u b24tbXV4Pw0KDQoNCk9uIDE4IEF1ZyAyMDE1LCBhdCAxMDoxNiwgSGFyYWxkIEFsdmVzdHJhbmQg PGhhcmFsZEBhbHZlc3RyYW5kLm5vPG1haWx0bzpoYXJhbGRAYWx2ZXN0cmFuZC5ubz4+IHdyb3Rl Og0KDQpPbiAwOC8xOC8yMDE1IDEyOjUzIEFNLCBQZXRlciBUaGF0Y2hlciB3cm90ZToNCg0KDQo8 c25pcD4NCg0KLg0KDQoNClRoZSByZWFzb24gaXMgd2h5IEkgc2VlIGl0IGlzIGFzIHZlcnkgaW1w b3J0YW50IHRoYXQgV2ViUlRDIGVuZHBvaW50cyBzdXBwb3J0IG5vbi1tdXggaXMgdGhhdCBvdGhl cndpc2Ugb25lIGNyZWF0ZXMgYW4gaW50ZXJvcGVyYWJpbGl0eSBpc3N1ZSwgcG9zc2libGUgZnV0 dXJlIG9uZS4gUlRDUCBNdXggY2FuIG9ubHkgd29yayB1bmRlciBzb21lIHJlc3RyaWN0aW9ucyBy ZWdhcmRpbmcgdGhlIFBheWxvYWQgVHlwZSAoUFQpIGFzc2lnbm1lbnQuIEEgZ2F0ZXdheSBiZXR3 ZWVuIGFuIGVuZHBvaW50IGRvaW5nIG11eCBhbmQgb25lIG5vdCBkb2luZyBpdCB3aWxsIHRodXMg aGF2ZSBiZSBjYXBhYmxlIG9mIHJld3JpdGluZyBQVHMuIEFzIFBUcyBzb21ldGltZXMgaGF2ZSBi ZWVuIGluY2x1ZGVkIGluIFJUQ1AgZm9ybWF0cywgdGhhdCByZXF1aXJlcyB0aGUgR2F0ZXdheSB0 byB1bmRlcnN0YW5kIGFuZCBiZSBjYXBhYmxlIG9mIHJld3JpdGluZyB0aGVtLiBUaHVzLCB0aGUg Z2F0ZXdheSBNVVNUIHVuZGVyc3RhbmQgZXZlcnl0aGluZyB0aGF0IGdvZXMgaW50byB0aGUgUlRD UCBwYWNrZXQuIFRoaXMgcmVxdWlyZW1lbnQgcHJldmVudHMgY2hhbmdlcyBvciBhZGRpdGlvbnMg dG8gUlRDUCBhY3Jvc3MgZ2F0ZXdheXMgYXMgaXQgbWVhbnMgdGhhdCBhbHNvIHRoZSBnYXRld2F5 IGhhcyB0byBiZSB1cGRhdGVkLCBub3Qgb25seSBoYXZpbmcgdGhlIGNhcGFiaWxpdHkgaW4gYm90 aCBlbmRwb2ludHMuIEl0IGFsc28gaW5jcmVhc2VzIHRoZSBjb21wbGV4aXR5IG9mIHRoZSBnYXRl d2F5Lg0KDQrigItQbGVhc2UgY29ycmVjdCBtZSBpZiBJJ20gd3JvbmcsIGJ1dCBJIGJlbGlldmUg dGhpcyBpcyBvbmx5IGEgcHJvYmxlbSBpZiB0aGUgUlRQIGVuZHBvaW50cyBjaG9vc2UgUFRzIGlu IHRoZSByYW5nZSA2NC05NS4gIFJGQyA1NzYxIHNheXMgImZvciB0aGUgY2hvaWNlIG9mIFJUUCBw YXlsb2FkIHR5cGUgdmFsdWVzIC4uLiB2YWx1ZXMgaW4gdGhlIHJhbmdlIDY0LTk1IE1VU1QgTk9U IGJlIHVzZWQiLiAgSWYgc28sIGFyZSB3ZSByZWFsbHkgb25seSBjb25jZXJuaW5nIG91cnNlbHZl cyB3aXRoIGNvZGUgY29tcGxleGl0eSBmb3IgZ2F0ZXdheXMgdGhhdCBzcGVhayB0byBSVENXRUIg ZW5kcG9pbnRzIG9uZSBlbmQgYW5kIGxlZ2FjeSBSVFAgZW5kcG9pbnRzIHRoYXQgZG9uJ3QgZm9s bG93IDU3NjEgb24gdGhlIG90aGVyIGVuZD8NCg0KSWYgaXQncyBhIHF1ZXN0aW9uIG9mICJwb3Nz aWJsZSBmdXR1cmUiIGNvZGUgY29tcGxleGl0eSBpbiBnYXRld2F5cyB2ZXJzdXMgdmVyeSByZWFs IGNvZGUgY29tcGxleGl0eSB0aGF0IGlzIHNsb3dpbmcgZG93biBSVENXRUIgaW1wbGVtZW50YXRp b25zIHRvZGF5LCBJJ20gaW4gZmF2b3Igb2YgcmVtb3ZpbmcgdGhlIHJlYWwgY29kZSBjb21wbGV4 aXR5IHdlIGhhdmUgbm93IGFuZCB0YWtpbmcgdGhlIGNoYW5jZSBvbiB0aGUgcG9zc2libGUgZnV0 dXJlIGNvZGUgY29tcGxleGl0eSwgYmVjYXVzZSBpdCdzIGEgdmVyeSByZWFsIHBvc3NpYmlsaXR5 IHRoYXQgcG9zc2libGUgZnV0dXJlIGNvZGUgY29tcGxleGl0eSB3aWxsIG5ldmVyIGJlIG5lY2Vz c2FyeS4gICBJbiB0aGUgZW5kLCBpdCBtaWdodCBiZSBlYXNpZXIgdG8ganVzdCBub3QgY2hvb3Nl IFBUcyBpbnNpZGUgdGhlIHJhbmdlIDY0LTk1Lg0KDQpJIGJlbGlldmUgdGhlIGNvbmNsdXNpb24g b2YgQ3VsbGVuJ3MgcmV2aWV3IHdhcyB0aGF0IHRoZXJlIHdhcyBubyBpbXBsZW1lbnRhdGlvbiB0 aGF0IG9mZmVyZWQgSUNFIGFuZCBub3QgUlRDUE1VWC4gVGh1cywgYW55dGhpbmcgdGhhdCBjcmVh dGVzIGlzc3VlcyBtdXN0IGNvbWUgaW4gdmlhIGEgZ2F0ZXdheS4NCg0KRm9yIGFyZ3VtZW50J3Mg c2FrZSwgbGV0J3Mgc2F5IGl0J3MgYSBnYXRld2F5IHdoZXJlIHRoZSBub24tV2ViUlRDIHNpZGUg aXMgdXNpbmcgU0RQIG9mZmVyL2Fuc3dlci4NCg0KSW4gdGhlIGNhc2Ugd2hlcmUgdGhlIG9mZmVy IGNvbWVzIGZyb20gV2ViUlRDLCB0aGVyZSBpcyBubyBwcm9ibGVtOyB0aGUgV2ViUlRDLWdlbmVy YXRlZCBvZmZlciB3aWxsIG5ldmVyIGNvbnRhaW4gUFQgdmFsdWVzIGluIHRoZSByYW5nZSA2NC05 NSwgYW5kIHRoZXJlZm9yZSB0aGUgYW5zd2VyIHdpbGwgbm90IGVpdGhlci4NCg0KSW4gdGhlIGNh c2Ugd2hlcmUgdGhlIG9mZmVyIGNvbWVzIGZyb20gdGhlIG90aGVyIHNpZGUsIHRoZXJlIGFyZSB0 d28gY2FzZXM6DQoNCi0gT2ZmZXIgY29udGFpbnMgUlRDUE1VWCwgYW5kIGRvZXMgbm90IHVzZSBQ VCB2YWx1ZXMgaW4gdGhlIDY0LTk1IHJhbmdlLiBOb3QgQSBQcm9ibGVtLg0KLSBPZmZlciBkb2Vz IG5vdCBjb250YWluIFJUQ1BNVVgsIGJ1dCBkb2VzIG5vdCB1c2UgUFQgdmFsdWVzIGluIHRoZSA2 NC05NSByYW5nZS4gR2F0ZXdheSBhZGRzIGluIFJUQ1BNVVgsIGFuZCBzZXRzIHVwIHRvIG11eC9k ZW11eCBwYWNrZXRzIGR1cmluZyB0aGUgY2FsbC4gTm90IEEgUHJvYmxlbS4NCi0gT2ZmZXIgZG9l cyBub3QgY29udGFpbiBSVENQTVVYLCBhbmQgdXNlcyBQVCB2YWx1ZXMgaW4gdGhlIDY0LTk1IHJh bmdlLiBUaGlzIG1heSBiZSBhIHByb2JsZW0uDQoNCkEgcHJvdG9jb2wtdmFsaWQgaW1wbGVtZW50 YXRpb24gY2hvaWNlIGlzIGZvciB0aGUgZ2F0ZXdheSB0byBzdHJpcCBvdXQgdGhvc2UgUFQgdmFs dWVzIGZyb20gdGhlIG9mZmVyLiBUaGlzIHdpbGwgbGlrZWx5IHJlc3VsdCBpbiBhbiB1c2VsZXNz IG9mZmVyIChiZWNhdXNlIHRoZSBwYXlsb2FkIG9uZSB3YW50cyB0byBzZW5kIGNhbid0IGJlIHNl bnQpLg0KDQpJZiB0aGUgIm91dHNpZGUiIHN5c3RlbSBpcyBhYmxlIHRvIGhhbmRsZSBhIHJldmVy c2luZyBvZiB0aGUgb2ZmZXIvYW5zd2VyIGRpcmVjdGlvbiwgYSB2YWxpZCByZXNwb25zZSBpcyB0 byByZWplY3QgdGhlIG91dHNpZGUgb2ZmZXIgYW5kIGxldCB0aGUgZ2F0ZXdheSBjb25zdHJ1Y3Qg YSBjb3VudGVyb2ZmZXIgd2l0aG91dCB0aGUgIndyb25nIiBQVCB2YWx1ZXMuDQoNCklmIHRoZSAi b3V0c2lkZSIgc3lzdGVtIGlzbid0IGFibGUgdG8gZG8gc28sIEFORCB0aGUgZ2F0ZXdheSBpc24n dCBjYXBhYmxlIG9mIGRvaW5nIHRoZSBSVENQIG1hbmlwdWxhdGlvbiB0aGF0IE1hZ251cyBhbGx1 ZGVzIHRvLCB0aGUgb2ZmZXIganVzdCBoYXMgdG8gYmUgcmVqZWN0ZWQgYXQgdGhlIGdhdGV3YXku DQoNCkhvdyBpbXBvcnRhbnQgaXMgdGhpcyBjYXNlPw0KQW5kIG92ZXIgdGltZSAtIHdpbGwgdGhp cyBjYXNlIGJlY29tZSBtb3JlIG9yIGxlc3MgaW1wb3J0YW50Pw0KKE15IGJldCBpcyBvbiAibGVz cyBpbXBvcnRhbnQiIC0gYW55IG5ldyBwcm9kdWN0IHdpbGwgaGF2ZSBSVENQTVVYIGZyb20gdGhl IGdldC1nby4gSSBjb3VsZCBiZSB3cm9uZy4pDQoNCkFncmVlZC4gV2hhdOKAmXMgbW9yZSB0aGUg Z2F0ZXdheSBjYW4gYWx3YXlzIGJlIGNvbmZpZ3VyZWQgdG8gd29yayBhcm91bmQgdGhlIHByb2Js ZW0gYnk6DQphKSB0cmFuc2NvZGluZyAtIHRoZSBjaGFuY2VzIGFyZSB0aGF0IHN1Y2ggYSBnYXRl d2F5IGlzIHByb2JhYmx5IGNhcGFibGUgb2YgdHJhbnNjb2RpbmcgZnJvbSBhbXItd2IgdG8gb3B1 cyAob3Igc2ltaWxhcikgLSBpdCBjYW4gdHJhbnNjb2RlIGFuZA0KZml4IHRoZSBwdCB2YWx1ZSBh cyBhIHNpZGUgZWZmZWN0Lg0KYikganVzdCByZS13cml0ZSB0aGUgdGhlIHB0eXBlIC0gaW4gZWZm ZWN0IHRyYW5zY29kaW5nIGZyb20gdWxhdyB0byB1bGF3IGJ1dCB1cGRhdGluZyB0aGUgcHR5cGUu DQooSWYgSSByZW1lbWJlciBjb3JyZWN0bHkgd2Ugd3JvdGUgYSBnYXRld2F5IHRoYXQgZGlkIHRo aXMgMyB5ZWFycyBhZ28pLg0KDQpUaW0uDQoNCg0KSGFyYWxkDQpfX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KcnRjd2ViIG1haWxpbmcgbGlzdA0KcnRjd2Vi QGlldGYub3JnPG1haWx0bzpydGN3ZWJAaWV0Zi5vcmc+DQpodHRwczovL3d3dy5pZXRmLm9yZy9t YWlsbWFuL2xpc3RpbmZvL3J0Y3dlYg0KDQpUaW0gUGFudG9uIC0gV2ViL1ZvSVAgY29uc3VsdGFu dCBhbmQgaW1wbGVtZW50b3INCnd3dy53ZXN0aGF3ay5jby51azxodHRwOi8vd3d3Lndlc3RoYXdr LmNvLnVrPg0KDQoNCg0K --_000_786615F3A85DF44AA2A76164A71FE1AC7ADC1ADAFR711WXCHMBA03z_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTIgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 SGVsdmV0aWNhOw0KCXBhbm9zZS0xOjIgMTEgNiA0IDIgMiAyIDIgMiA0O30NCkBmb250LWZhY2UN Cgl7Zm9udC1mYW1pbHk6IkNhbWJyaWEgTWF0aCI7DQoJcGFub3NlLTE6MiA0IDUgMyA1IDQgNiAz IDIgNDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OkNhbGlicmk7DQoJcGFub3NlLTE6MiAx NSA1IDIgMiAyIDQgMyAyIDQ7fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseTpUYWhvbWE7DQoJ cGFub3NlLTE6MiAxMSA2IDQgMyA1IDQgNCAyIDQ7fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWls eTpDb25zb2xhczsNCglwYW5vc2UtMToyIDExIDYgOSAyIDIgNCAzIDIgNDt9DQovKiBTdHlsZSBE ZWZpbml0aW9ucyAqLw0KcC5Nc29Ob3JtYWwsIGxpLk1zb05vcm1hbCwgZGl2Lk1zb05vcm1hbA0K CXttYXJnaW46MGNtOw0KCW1hcmdpbi1ib3R0b206LjAwMDFwdDsNCglmb250LXNpemU6MTIuMHB0 Ow0KCWZvbnQtZmFtaWx5OiJUaW1lcyBOZXcgUm9tYW4iLCJzZXJpZiI7fQ0KYTpsaW5rLCBzcGFu Lk1zb0h5cGVybGluaw0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6Ymx1ZTsNCgl0 ZXh0LWRlY29yYXRpb246dW5kZXJsaW5lO30NCmE6dmlzaXRlZCwgc3Bhbi5Nc29IeXBlcmxpbmtG b2xsb3dlZA0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6cHVycGxlOw0KCXRleHQt ZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0Kc3Bhbi5hcHBsZS1zdHlsZS1zcGFuDQoJe21zby1zdHls ZS1uYW1lOmFwcGxlLXN0eWxlLXNwYW47fQ0Kc3Bhbi5FbWFpbFN0eWxlMTgNCgl7bXNvLXN0eWxl LXR5cGU6cGVyc29uYWwtcmVwbHk7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLCJzYW5zLXNlcmlm IjsNCgljb2xvcjojMUY0OTdEO30NCi5Nc29DaHBEZWZhdWx0DQoJe21zby1zdHlsZS10eXBlOmV4 cG9ydC1vbmx5Ow0KCWZvbnQtc2l6ZToxMC4wcHQ7fQ0KQHBhZ2UgV29yZFNlY3Rpb24xDQoJe3Np emU6NjEyLjBwdCA3OTIuMHB0Ow0KCW1hcmdpbjo3Mi4wcHQgNzIuMHB0IDcyLjBwdCA3Mi4wcHQ7 fQ0KZGl2LldvcmRTZWN0aW9uMQ0KCXtwYWdlOldvcmRTZWN0aW9uMTt9DQotLT48L3N0eWxlPjwh LS1baWYgZ3RlIG1zbyA5XT48eG1sPg0KPG86c2hhcGVkZWZhdWx0cyB2OmV4dD0iZWRpdCIgc3Bp ZG1heD0iMTAyNiIgLz4NCjwveG1sPjwhW2VuZGlmXS0tPjwhLS1baWYgZ3RlIG1zbyA5XT48eG1s Pg0KPG86c2hhcGVsYXlvdXQgdjpleHQ9ImVkaXQiPg0KPG86aWRtYXAgdjpleHQ9ImVkaXQiIGRh dGE9IjEiIC8+DQo8L286c2hhcGVsYXlvdXQ+PC94bWw+PCFbZW5kaWZdLS0+DQo8L2hlYWQ+DQo8 Ym9keSBsYW5nPSJFTi1HQiIgbGluaz0iYmx1ZSIgdmxpbms9InB1cnBsZSI+DQo8ZGl2IGNsYXNz PSJXb3JkU2VjdGlvbjEiPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQt c2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6Q29uc29sYXM7Y29sb3I6IzFGNDk3RCI+Q29uY3VyIHRv IHRoZSBldmFsdWF0aW9uIG9mIFRpbSwgSGFyYWxkIGFuZCBDdWxsZW4uPG86cD48L286cD48L3Nw YW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4w cHQ7Zm9udC1mYW1pbHk6Q29uc29sYXM7Y29sb3I6IzFGNDk3RCI+VGhlIG1lZGlhIHBsYW5lIFdl YlJUQyBnYXRld2F5IHByb3ZpZGVzIGEgc3BlY2lmaWMg4oCcPGI+UlRQIHRvcG9sb2d5PC9iPuKA nSBmb3IgdGhlIGludGVyd29ya2luZyBvZiBhbGwgUlRQLWJhc2VkIFdlYlJUQyBzZXJ2aWNlIGNv bXBvbmVudHMuPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNw YW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6Q29uc29sYXM7Y29sb3I6IzFG NDk3RCI+RWl0aGVyIGFuPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6Q29uc29sYXM7Y29s b3I6IzFGNDk3RCI+YSkNCjxiPlJUUCBNZWRpYSBUcmFuc2xhdG9yPC9iPiAoUlRQTVQpIG9yIDxi PkJhY2stdG8tQmFjayBSVFAgRW5kc3lzdGVtPC9iPiAoQjJCUkUpIGluIGNhc2Ugb2YgbWVkaWEg cHJvY2Vzc2luZyAoc3VjaCBhcyB0cmFuc2NvZGluZyk8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZh bWlseTpDb25zb2xhcztjb2xvcjojMUY0OTdEIj49Jmd0OyBubyBpc3N1ZTxvOnA+PC9vOnA+PC9z cGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEu MHB0O2ZvbnQtZmFtaWx5OkNvbnNvbGFzO2NvbG9yOiMxRjQ5N0QiPmIpDQo8Yj5SVFAgVHJhbnNw b3J0IFRyYW5zbGF0b3I8L2I+IChSVFBNVCkgKHdoaWNoIG1heSBiZSBhbHNvIGNvdmVyZWQgYnkg YSA8Yj5CYWNrLXRvLUJhY2sgUlRQIEVuZHN5c3RlbTwvYj4gKEIyQlJFKSk8YnI+DQo9Jmd0OyBu byBpc3N1ZSAoYmVjYXVzZSBQVCBtYXBwaW5nIGlzIGluY2x1ZGVkIGluIHRoaXMgbW9kZSk8bzpw PjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9u dC1zaXplOjExLjBwdDtmb250LWZhbWlseTpDb25zb2xhcztjb2xvcjojMUY0OTdEIj5vcjxvOnA+ PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250 LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OkNvbnNvbGFzO2NvbG9yOiMxRjQ5N0QiPmMpDQo8Yj5S VFAgVHJhbnNwYXJlbnQgRm9yd2FyZGluZzwvYj4gKFRGKSDigKYgPG86cD48L286cD48L3NwYW4+ PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7 Zm9udC1mYW1pbHk6Q29uc29sYXM7Y29sb3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8L286cD48L3Nw YW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4w cHQ7Zm9udC1mYW1pbHk6Q29uc29sYXM7Y29sb3I6IzFGNDk3RCI+VGhlIHBhcnRpY3VsYXIgUlRQ IHRvcG9sb2d5IGRlcGVuZHMgb24gdGhlIHR3byDigJxSVFAgcHJvZmlsZXPigJ0gYXBwbGllZCBp biB0aGUgV2ViUlRDIGFuZCBub24tV2ViUlRDIGRvbWFpbi48bzpwPjwvbzpwPjwvc3Bhbj48L3A+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250 LWZhbWlseTpDb25zb2xhcztjb2xvcjojMUY0OTdEIj5UaGUgc2VsZWN0ZWQgUlRQIHRvcG9sb2d5 IGlzIG1lZGlhLXR5cGUgZGVwZW5kZW50LCBpLmUuIHRoZXJl4oCZbGwgYmUgYSBzcGVjaWZpYyBS VFAgdG9wb2xvZ3kgZm9yIGF1ZGlvIGFuZCB2aWRlbyAo4oCcYW5kIGJvdGggbWlnaHQgYmUgZGlm ZmVyZW504oCdKS48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48 c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTpDb25zb2xhcztjb2xvcjoj MUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTpDb25zb2xhcztjb2xv cjojMUY0OTdEIj5UaHVzLCBhbHNvIGZhaWwgdG8gc2VlIGFueSByZWFsIGlzc3Vlcyw8bzpwPjwv bzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1z aXplOjExLjBwdDtmb250LWZhbWlseTpDb25zb2xhcztjb2xvcjojMUY0OTdEIj5BbGJyZWNodDwv c3Bhbj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxp YnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+PG86cD48L286 cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6 ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlm JnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxkaXY+ DQo8ZGl2IHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItdG9wOnNvbGlkICNCNUM0REYgMS4wcHQ7 cGFkZGluZzozLjBwdCAwY20gMGNtIDBjbSI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48Yj48c3Bh biBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7 VGFob21hJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPkZyb206PC9zcGFuPjwvYj48c3Bh biBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7 VGFob21hJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPiBydGN3ZWIgW21haWx0bzpydGN3 ZWItYm91bmNlc0BpZXRmLm9yZ10NCjxiPk9uIEJlaGFsZiBPZiA8L2I+VGltIFBhbnRvbjxicj4N CjxiPlNlbnQ6PC9iPiBEaWVuc3RhZywgMTguIEF1Z3VzdCAyMDE1IDExOjI5PGJyPg0KPGI+VG86 PC9iPiBIYXJhbGQgQWx2ZXN0cmFuZDxicj4NCjxiPkNjOjwvYj4gcnRjd2ViQGlldGYub3JnPGJy Pg0KPGI+U3ViamVjdDo8L2I+IFJlOiBbcnRjd2ViXSBEbyB3ZSBoYXZlIGNvbnNlbnN1cyBvbiBu b3QgcmVxdWlyaW5nIHJ0Y3Atbm9uLW11eD88bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4N CjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxkaXY+DQo8YmxvY2txdW90 ZSBzdHlsZT0ibWFyZ2luLXRvcDo1LjBwdDttYXJnaW4tYm90dG9tOjUuMHB0Ij4NCjxkaXY+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj5PbiAxOCBBdWcgMjAxNSwgYXQgMTA6MTYsIEhhcmFsZCBBbHZl c3RyYW5kICZsdDs8YSBocmVmPSJtYWlsdG86aGFyYWxkQGFsdmVzdHJhbmQubm8iPmhhcmFsZEBh bHZlc3RyYW5kLm5vPC9hPiZndDsgd3JvdGU6PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPGRpdj4NCjxkaXY+DQo8ZGl2 Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+T24gMDgvMTgvMjAxNSAxMjo1MyBBTSwgUGV0ZXIgVGhh dGNoZXIgd3JvdGU6PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxibG9ja3F1b3RlIHN0eWxlPSJt YXJnaW4tdG9wOjUuMHB0O21hcmdpbi1ib3R0b206NS4wcHQiPg0KPGRpdj4NCjxkaXY+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVv dDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0K PC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+ DQo8L2Rpdj4NCjwvZGl2Pg0KPC9ibG9ja3F1b3RlPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Jmx0 O3NuaXAmZ3Q7PGJyPg0KPGJyPg0KPG86cD48L286cD48L3A+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4uIDxvOnA+PC9vOnA+PC9wPg0KPGRpdj4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxibG9ja3F1b3Rl IHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItbGVmdDpzb2xpZCAjQ0NDQ0NDIDEuMHB0O3BhZGRp bmc6MGNtIDBjbSAwY20gNi4wcHQ7bWFyZ2luLWxlZnQ6NC44cHQ7bWFyZ2luLXJpZ2h0OjBjbSI+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWJvdHRvbToxMi4wcHQiPlRoZSBy ZWFzb24gaXMgd2h5IEkgc2VlIGl0IGlzIGFzIHZlcnkgaW1wb3J0YW50IHRoYXQgV2ViUlRDIGVu ZHBvaW50cyBzdXBwb3J0IG5vbi1tdXggaXMgdGhhdCBvdGhlcndpc2Ugb25lIGNyZWF0ZXMgYW4g aW50ZXJvcGVyYWJpbGl0eSBpc3N1ZSwgcG9zc2libGUgZnV0dXJlIG9uZS4gUlRDUCBNdXggY2Fu IG9ubHkgd29yayB1bmRlciBzb21lIHJlc3RyaWN0aW9ucw0KIHJlZ2FyZGluZyB0aGUgUGF5bG9h ZCBUeXBlIChQVCkgYXNzaWdubWVudC4gQSBnYXRld2F5IGJldHdlZW4gYW4gZW5kcG9pbnQgZG9p bmcgbXV4IGFuZCBvbmUgbm90IGRvaW5nIGl0IHdpbGwgdGh1cyBoYXZlIGJlIGNhcGFibGUgb2Yg cmV3cml0aW5nIFBUcy4gQXMgUFRzIHNvbWV0aW1lcyBoYXZlIGJlZW4gaW5jbHVkZWQgaW4gUlRD UCBmb3JtYXRzLCB0aGF0IHJlcXVpcmVzIHRoZSBHYXRld2F5IHRvIHVuZGVyc3RhbmQgYW5kIGJl IGNhcGFibGUNCiBvZiByZXdyaXRpbmcgdGhlbS4gVGh1cywgdGhlIGdhdGV3YXkgTVVTVCB1bmRl cnN0YW5kIGV2ZXJ5dGhpbmcgdGhhdCBnb2VzIGludG8gdGhlIFJUQ1AgcGFja2V0LiBUaGlzIHJl cXVpcmVtZW50IHByZXZlbnRzIGNoYW5nZXMgb3IgYWRkaXRpb25zIHRvIFJUQ1AgYWNyb3NzIGdh dGV3YXlzIGFzIGl0IG1lYW5zIHRoYXQgYWxzbyB0aGUgZ2F0ZXdheSBoYXMgdG8gYmUgdXBkYXRl ZCwgbm90IG9ubHkgaGF2aW5nIHRoZSBjYXBhYmlsaXR5IGluIGJvdGgNCiBlbmRwb2ludHMuIEl0 IGFsc28gaW5jcmVhc2VzIHRoZSBjb21wbGV4aXR5IG9mIHRoZSBnYXRld2F5LjxvOnA+PC9vOnA+ PC9wPg0KPC9ibG9ja3F1b3RlPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5i c3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtBcmlhbCZxdW90OywmcXVvdDtzYW5zLXNl cmlmJnF1b3Q7Ij7igItQbGVhc2UgY29ycmVjdCBtZSBpZiBJJ20gd3JvbmcsIGJ1dCBJIGJlbGll dmUgdGhpcyBpcyBvbmx5IGEgcHJvYmxlbSBpZiB0aGUgUlRQIGVuZHBvaW50cyBjaG9vc2UgUFRz IGluIHRoZSByYW5nZSA2NC05NS4mbmJzcDsgUkZDIDU3NjEgc2F5cyAmcXVvdDtmb3IgdGhlIGNo b2ljZSBvZiBSVFAgcGF5bG9hZCB0eXBlIHZhbHVlcyAuLi4gdmFsdWVzDQogaW4gdGhlIHJhbmdl IDY0LTk1IE1VU1QgTk9UIGJlIHVzZWQmcXVvdDsuJm5ic3A7IElmIHNvLCBhcmUgd2UgcmVhbGx5 IG9ubHkgY29uY2VybmluZyBvdXJzZWx2ZXMgd2l0aCBjb2RlIGNvbXBsZXhpdHkgZm9yIGdhdGV3 YXlzIHRoYXQgc3BlYWsgdG8gUlRDV0VCIGVuZHBvaW50cyBvbmUgZW5kIGFuZCBsZWdhY3kgUlRQ IGVuZHBvaW50cyB0aGF0IGRvbid0IGZvbGxvdyA1NzYxIG9uIHRoZSBvdGhlciBlbmQ/Jm5ic3A7 PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7LCZxdW90O3NhbnMt c2VyaWYmcXVvdDsiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtBcmlh bCZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij5JZiBpdCdzIGEgcXVlc3Rpb24gb2YgJnF1 b3Q7cG9zc2libGUgZnV0dXJlJnF1b3Q7IGNvZGUgY29tcGxleGl0eSBpbiBnYXRld2F5cyB2ZXJz dXMgdmVyeSByZWFsIGNvZGUgY29tcGxleGl0eSB0aGF0IGlzIHNsb3dpbmcgZG93biBSVENXRUIg aW1wbGVtZW50YXRpb25zIHRvZGF5LCBJJ20gaW4gZmF2b3Igb2YgcmVtb3ZpbmcgdGhlIHJlYWwg Y29kZQ0KIGNvbXBsZXhpdHkgd2UgaGF2ZSBub3cgYW5kIHRha2luZyB0aGUgY2hhbmNlIG9uIHRo ZSBwb3NzaWJsZSBmdXR1cmUgY29kZSBjb21wbGV4aXR5LCBiZWNhdXNlIGl0J3MgYSB2ZXJ5IHJl YWwgcG9zc2liaWxpdHkgdGhhdCBwb3NzaWJsZSBmdXR1cmUgY29kZSBjb21wbGV4aXR5IHdpbGwg bmV2ZXIgYmUgbmVjZXNzYXJ5LiAmbmJzcDsgSW4gdGhlIGVuZCwgaXQgbWlnaHQgYmUgZWFzaWVy IHRvIGp1c3Qgbm90IGNob29zZSBQVHMgaW5zaWRlIHRoZSByYW5nZQ0KIDY0LTk1LjxvOnA+PC9v OnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj48YnI+DQpJIGJlbGlldmUgdGhlIGNvbmNsdXNpb24gb2YgQ3Vs bGVuJ3MgcmV2aWV3IHdhcyB0aGF0IHRoZXJlIHdhcyBubyBpbXBsZW1lbnRhdGlvbiB0aGF0IG9m ZmVyZWQgSUNFIGFuZCBub3QgUlRDUE1VWC4gVGh1cywgYW55dGhpbmcgdGhhdCBjcmVhdGVzIGlz c3VlcyBtdXN0IGNvbWUgaW4gdmlhIGEgZ2F0ZXdheS48YnI+DQo8YnI+DQpGb3IgYXJndW1lbnQn cyBzYWtlLCBsZXQncyBzYXkgaXQncyBhIGdhdGV3YXkgd2hlcmUgdGhlIG5vbi1XZWJSVEMgc2lk ZSBpcyB1c2luZyBTRFAgb2ZmZXIvYW5zd2VyLjxicj4NCjxicj4NCkluIHRoZSBjYXNlIHdoZXJl IHRoZSBvZmZlciBjb21lcyBmcm9tIFdlYlJUQywgdGhlcmUgaXMgbm8gcHJvYmxlbTsgdGhlIFdl YlJUQy1nZW5lcmF0ZWQgb2ZmZXIgd2lsbCBuZXZlciBjb250YWluIFBUIHZhbHVlcyBpbiB0aGUg cmFuZ2UgNjQtOTUsIGFuZCB0aGVyZWZvcmUgdGhlIGFuc3dlciB3aWxsIG5vdCBlaXRoZXIuPGJy Pg0KPGJyPg0KSW4gdGhlIGNhc2Ugd2hlcmUgdGhlIG9mZmVyIGNvbWVzIGZyb20gdGhlIG90aGVy IHNpZGUsIHRoZXJlIGFyZSB0d28gY2FzZXM6PGJyPg0KPGJyPg0KLSBPZmZlciBjb250YWlucyBS VENQTVVYLCBhbmQgZG9lcyBub3QgdXNlIFBUIHZhbHVlcyBpbiB0aGUgNjQtOTUgcmFuZ2UuIE5v dCBBIFByb2JsZW0uPGJyPg0KLSBPZmZlciBkb2VzIG5vdCBjb250YWluIFJUQ1BNVVgsIGJ1dCBk b2VzIG5vdCB1c2UgUFQgdmFsdWVzIGluIHRoZSA2NC05NSByYW5nZS4gR2F0ZXdheSBhZGRzIGlu IFJUQ1BNVVgsIGFuZCBzZXRzIHVwIHRvIG11eC9kZW11eCBwYWNrZXRzIGR1cmluZyB0aGUgY2Fs bC4gTm90IEEgUHJvYmxlbS48YnI+DQotIE9mZmVyIGRvZXMgbm90IGNvbnRhaW4gUlRDUE1VWCwg YW5kIHVzZXMgUFQgdmFsdWVzIGluIHRoZSA2NC05NSByYW5nZS4gVGhpcyBtYXkgYmUgYSBwcm9i bGVtLjxicj4NCjxicj4NCkEgcHJvdG9jb2wtdmFsaWQgaW1wbGVtZW50YXRpb24gY2hvaWNlIGlz IGZvciB0aGUgZ2F0ZXdheSB0byBzdHJpcCBvdXQgdGhvc2UgUFQgdmFsdWVzIGZyb20gdGhlIG9m ZmVyLiBUaGlzIHdpbGwgbGlrZWx5IHJlc3VsdCBpbiBhbiB1c2VsZXNzIG9mZmVyIChiZWNhdXNl IHRoZSBwYXlsb2FkIG9uZSB3YW50cyB0byBzZW5kIGNhbid0IGJlIHNlbnQpLjxicj4NCjxicj4N CklmIHRoZSAmcXVvdDtvdXRzaWRlJnF1b3Q7IHN5c3RlbSBpcyBhYmxlIHRvIGhhbmRsZSBhIHJl dmVyc2luZyBvZiB0aGUgb2ZmZXIvYW5zd2VyIGRpcmVjdGlvbiwgYSB2YWxpZCByZXNwb25zZSBp cyB0byByZWplY3QgdGhlIG91dHNpZGUgb2ZmZXIgYW5kIGxldCB0aGUgZ2F0ZXdheSBjb25zdHJ1 Y3QgYSBjb3VudGVyb2ZmZXIgd2l0aG91dCB0aGUgJnF1b3Q7d3JvbmcmcXVvdDsgUFQgdmFsdWVz Ljxicj4NCjxicj4NCklmIHRoZSAmcXVvdDtvdXRzaWRlJnF1b3Q7IHN5c3RlbSBpc24ndCBhYmxl IHRvIGRvIHNvLCBBTkQgdGhlIGdhdGV3YXkgaXNuJ3QgY2FwYWJsZSBvZiBkb2luZyB0aGUgUlRD UCBtYW5pcHVsYXRpb24gdGhhdCBNYWdudXMgYWxsdWRlcyB0bywgdGhlIG9mZmVyIGp1c3QgaGFz IHRvIGJlIHJlamVjdGVkIGF0IHRoZSBnYXRld2F5Ljxicj4NCjxicj4NCkhvdyBpbXBvcnRhbnQg aXMgdGhpcyBjYXNlPzxicj4NCkFuZCBvdmVyIHRpbWUgLSB3aWxsIHRoaXMgY2FzZSBiZWNvbWUg bW9yZSBvciBsZXNzIGltcG9ydGFudD88YnI+DQooTXkgYmV0IGlzIG9uICZxdW90O2xlc3MgaW1w b3J0YW50JnF1b3Q7IC0gYW55IG5ldyBwcm9kdWN0IHdpbGwgaGF2ZSBSVENQTVVYIGZyb20gdGhl IGdldC1nby4gSSBjb3VsZCBiZSB3cm9uZy4pPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2 Pg0KPC9ibG9ja3F1b3RlPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7 PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+QWdyZWVkLiBX aGF04oCZcyBtb3JlIHRoZSBnYXRld2F5IGNhbiBhbHdheXMgYmUgY29uZmlndXJlZCB0byB3b3Jr IGFyb3VuZCB0aGUgcHJvYmxlbSBieTo8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPmEpIHRyYW5zY29kaW5nIC0gdGhlIGNoYW5jZXMgYXJlIHRoYXQg c3VjaCBhIGdhdGV3YXkgaXMgcHJvYmFibHkgY2FwYWJsZSBvZiB0cmFuc2NvZGluZyBmcm9tIGFt ci13YiB0byBvcHVzIChvciBzaW1pbGFyKSAtIGl0IGNhbiB0cmFuc2NvZGUgYW5kPG86cD48L286 cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5maXggdGhlIHB0IHZh bHVlIGFzIGEgc2lkZSBlZmZlY3QuPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj5iKSBqdXN0IHJlLXdyaXRlIHRoZSB0aGUgcHR5cGUgLSBpbiBlZmZl Y3QgdHJhbnNjb2RpbmcgZnJvbSB1bGF3IHRvIHVsYXcgYnV0IHVwZGF0aW5nIHRoZSBwdHlwZS4m bmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PihJZiBJIHJlbWVtYmVyIGNvcnJlY3RseSB3ZSB3cm90ZSBhIGdhdGV3YXkgdGhhdCBkaWQgdGhp cyAzIHllYXJzIGFnbykuPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPlRpbS48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8YmxvY2txdW90ZSBz dHlsZT0ibWFyZ2luLXRvcDo1LjBwdDttYXJnaW4tYm90dG9tOjUuMHB0Ij4NCjxkaXY+DQo8ZGl2 Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1ib3R0b206MTIuMHB0Ij48YnI+ DQpIYXJhbGQ8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+X19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX188YnI+DQpydGN3ZWIg bWFpbGluZyBsaXN0PGJyPg0KPGEgaHJlZj0ibWFpbHRvOnJ0Y3dlYkBpZXRmLm9yZyI+cnRjd2Vi QGlldGYub3JnPC9hPjxicj4NCjxhIGhyZWY9Imh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4v bGlzdGluZm8vcnRjd2ViIj5odHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL3J0 Y3dlYjwvYT48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9ibG9ja3F1b3RlPg0KPC9kaXY+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxkaXY+DQo8ZGl2Pg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTo5LjBwdDtmb250LWZh bWlseTomcXVvdDtIZWx2ZXRpY2EmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjpi bGFjayI+VGltIFBhbnRvbiAtIFdlYi9Wb0lQIGNvbnN1bHRhbnQgYW5kIGltcGxlbWVudG9yPG86 cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTo5LjBwdDtmb250LWZhbWlseTomcXVvdDtIZWx2ZXRpY2Em cXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjpibGFjayI+PGEgaHJlZj0iaHR0cDov L3d3dy53ZXN0aGF3ay5jby51ayI+d3d3Lndlc3RoYXdrLmNvLnVrPC9hPjxvOnA+PC9vOnA+PC9z cGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxl PSJmb250LXNpemU6OS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7SGVsdmV0aWNhJnF1b3Q7LCZxdW90 O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6YmxhY2siPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwv cD4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8 L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+ DQo8L2JvZHk+DQo8L2h0bWw+DQo= --_000_786615F3A85DF44AA2A76164A71FE1AC7ADC1ADAFR711WXCHMBA03z_-- From nobody Tue Aug 18 07:35:36 2015 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AA3091A888A for ; Tue, 18 Aug 2015 07:35:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5UHhzpsJVYV5 for ; Tue, 18 Aug 2015 07:35:34 -0700 (PDT) Received: from mail-pd0-x22c.google.com (mail-pd0-x22c.google.com [IPv6:2607:f8b0:400e:c02::22c]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 860381A8886 for ; Tue, 18 Aug 2015 07:35:34 -0700 (PDT) Received: by pdrh1 with SMTP id h1so69581399pdr.0 for ; Tue, 18 Aug 2015 07:35:34 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=content-type:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=1z4D2rKbyYoIzsIOSLd5KN2kVzFqES7BM5QdnEmTZIE=; b=DaSZmg36Q1moUpmaMZ77bZSMH5sD9TGOG7OEVrn6sa1fIitKDjOXxFm9SyXmGaTOkn R16ZBTiCzeG/Kqebybk68YrEjJBCEqNgv0PNe+o60DaH7Etyl11QpGSKWExwT+xn42xd fNPIygDB2ziRa1e49JrNu4zNmGZ/ycbwFE8hdvFCWpv4jXZb8JdhO+8BbGNXTFf0xZvN 0aRYwZB0KIBlRCeG/raq+yDFZW3iOvxfBMCSJ08MDhx/X+b5IzkcjDUI7tCFCX4Fx93i NR2HGrtVrIRIQu/WDis8aHPzTWRflmelEozhjV+nVMOIEiU2kaeZuOcUT0SLkFC92qQ+ rH6Q== X-Received: by 10.70.51.7 with SMTP id g7mr14057771pdo.46.1439908534224; Tue, 18 Aug 2015 07:35:34 -0700 (PDT) Received: from [192.168.1.110] (c-71-227-237-49.hsd1.wa.comcast.net. [71.227.237.49]) by smtp.gmail.com with ESMTPSA id pe1sm18337323pbb.28.2015.08.18.07.35.33 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Tue, 18 Aug 2015 07:35:33 -0700 (PDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (1.0) From: Bernard Aboba X-Mailer: iPad Mail (12H321) In-Reply-To: <55D2F7EC.2050001@alvestrand.no> Date: Tue, 18 Aug 2015 07:35:32 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <09F82C19-75FF-4809-8921-D74CB7C54B53@gmail.com> References: <55D03AC6.4080100@ericsson.com> <55D2F7EC.2050001@alvestrand.no> To: Harald Alvestrand Archived-At: Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] Do we have consensus on not requiring rtcp-non-mux? X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 18 Aug 2015 14:35:35 -0000 On Aug 18, 2015, at 02:16, Harald Alvestrand wrote: >=20 > How important is this case? > And over time - will this case become more or less important? > (My bet is on "less important" - any new product will have RTCPMUX from th= e get-go. I could be wrong.) [BA] The case you describe *could* be encountered in a situation where each s= imulcast/SVC stream in a conference needed to use a distinct payload type. L= uckily, no conferencing system I am aware of uses PTs in that profligate way= (multiplexing by SSRC is much more common) - though the suggestion has now b= een introduced into the WEBRTC WG. As the old joke says: Patient: It hurts when I do this. Doctor: Then don't do that.= From nobody Tue Aug 18 10:24:13 2015 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 688061A8AA7 for ; Tue, 18 Aug 2015 10:24:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.388 X-Spam-Level: X-Spam-Status: No, score=-1.388 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3MYLFDtj4X00 for ; Tue, 18 Aug 2015 10:24:05 -0700 (PDT) Received: from mail-ob0-x229.google.com (mail-ob0-x229.google.com [IPv6:2607:f8b0:4003:c01::229]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0464B1A8AA5 for ; Tue, 18 Aug 2015 10:24:05 -0700 (PDT) Received: by obbop1 with SMTP id op1so147404514obb.2 for ; Tue, 18 Aug 2015 10:24:04 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=NwSdDm6D4Wvr0Mg66FTVRKXtBx1q25Q8t8CRJFEeQ0Q=; b=kmQFl+FRh6uPiW4pxqGJkDgOH/ucgLDv4Kgopxy3gsV33JqsQKVF/EEENSbU2bHhU5 y+zWJxsuPdq0VDZWyw9abORvWGEi4rz9/is3uzq0rJ2LGfrhfcW4AdL6IAlRMQYpw0tp Pi0RTlLLtRAPG0c7ChKoaBkTGeICRqobBvjAVzcoVTjXH3KKD17V2xK4DT9Otda5L6Q4 D6+T4JVkbvXJeGpFMGcgk7+mfYZkrbROWcgf4JEIe2s7ozWGcsgMLF7WdbLfAOIxWVNE FhTPjb/HkWmw8Mkuy8/FJPaWDGs16vW3Y+MejqQqrsAgdrdObScipeCs504mwt4FuhM1 2l7w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type; bh=NwSdDm6D4Wvr0Mg66FTVRKXtBx1q25Q8t8CRJFEeQ0Q=; b=lLwBtX7fMGTHVHhyknKrTlWx4dND62DpVQboixzuqZxSaqomL/T7MsLwI297FWqoVy O21ajffS/1mnKky+fXlEM8nreHHj0uQgj53m7bhBjRQFp1MwafFMcmz4TqupxFlh0KPw mDYa2qvd7ALAEzLnUUJW3ITdkTr0h4XFewsAVybdQEnmMjJSl8cqfe5y2+sd5/JFdpiw FUzasfLrksZfCXGlNudZdZad1odYwotn8/n4juaGyXsD5+FvLg/wxIRWpR6o6DpWIGaZ vbxUXmhskVbY5B4Sc8PBjVF4xe3WO2OY9RFpiY3RVBoZG3wIoTNJRH4dArRlBGyBKZeM 3xFQ== X-Gm-Message-State: ALoCoQmklg2xefet+wEDO19MLxjpG0c/bn4YZ4F1t8cyk92m/6aEMFYoBq5NTfk9f1GmTL5ewsex X-Received: by 10.182.236.102 with SMTP id ut6mr7055411obc.75.1439918644458; Tue, 18 Aug 2015 10:24:04 -0700 (PDT) MIME-Version: 1.0 Received: by 10.76.62.110 with HTTP; Tue, 18 Aug 2015 10:23:21 -0700 (PDT) In-Reply-To: <09F82C19-75FF-4809-8921-D74CB7C54B53@gmail.com> References: <55D03AC6.4080100@ericsson.com> <55D2F7EC.2050001@alvestrand.no> <09F82C19-75FF-4809-8921-D74CB7C54B53@gmail.com> From: Peter Thatcher Date: Tue, 18 Aug 2015 10:23:21 -0700 Message-ID: To: Bernard Aboba Content-Type: multipart/alternative; boundary=001a11c3124e4f7688051d992f93 Archived-At: Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] Do we have consensus on not requiring rtcp-non-mux? X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 18 Aug 2015 17:24:06 -0000 --001a11c3124e4f7688051d992f93 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On Tue, Aug 18, 2015 at 7:35 AM, Bernard Aboba wrote: > On Aug 18, 2015, at 02:16, Harald Alvestrand wrote= : > > > > How important is this case? > > And over time - will this case become more or less important? > > (My bet is on "less important" - any new product will have RTCPMUX from > the get-go. I could be wrong.) > > [BA] The case you describe *could* be encountered in a situation where > each simulcast/SVC stream in a conference needed to use a distinct payloa= d > type. Luckily, no conferencing system I am aware of uses PTs in that > profligate way (multiplexing by SSRC is much more common) - though the > suggestion has now been introduced into the WEBRTC WG. > > As the old joke says: > > Patient: It hurts when I do this. > Doctor: Then don't do that. > =E2=80=8BThat's exactly the joke I think of whenever someone says "but what= about PTs in the range 64-95?"=E2=80=8B. I hope someday (soon?) that joke will apply to non-muxed RTCP. > _______________________________________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/listinfo/rtcweb > --001a11c3124e4f7688051d992f93 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


On Tue, Aug 18, 2015 at 7:35 AM, Bernard Aboba <bernard= .aboba@gmail.com> wrote:
On Aug 18, 2015, at 02:16, Harald Alvestrand <harald@alvestrand.no> wrote:
>
> How important is this case?
> And over time - will this case become more or less important?
> (My bet is on "less important" - any new product will have R= TCPMUX from the get-go. I could be wrong.)

[BA] The case you describe *could* be encountered in a situation whe= re each simulcast/SVC stream in a conference needed to use a distinct paylo= ad type. Luckily, no conferencing system I am aware of uses PTs in that pro= fligate way (multiplexing by SSRC is much more common) - though the suggest= ion has now been introduced into the WEBRTC WG.

As the old joke says:

Patient: It hurts when I do this.
Doctor: Then don't do that.

=E2= =80=8BThat's exactly the joke I think of whenever someone says "bu= t what about PTs in the range=C2=A064-95?"=E2=80=8B.=C2=A0
=

I hope someday (soon?) that joke will apply to non-muxed RT= CP.=C2=A0


=C2=A0
_______________________________________________
rtcweb mailing list
rtcweb@ietf.org https://www.ietf.org/mailman/listinfo/rtcweb

--001a11c3124e4f7688051d992f93-- From nobody Tue Aug 18 12:34:39 2015 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A83BE1A894E for ; Tue, 18 Aug 2015 12:34:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.909 X-Spam-Level: X-Spam-Status: No, score=-1.909 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id I2De-VZjd29L for ; Tue, 18 Aug 2015 12:34:36 -0700 (PDT) Received: from nostrum.com (raven-v6.nostrum.com [IPv6:2001:470:d:1130::1]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 95E3F1A88B3 for ; Tue, 18 Aug 2015 12:34:36 -0700 (PDT) Received: from Svantevit.roach.at (99-152-145-110.lightspeed.dllstx.sbcglobal.net [99.152.145.110]) (authenticated bits=0) by nostrum.com (8.15.2/8.14.9) with ESMTPSA id t7IJYShp036327 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NO); Tue, 18 Aug 2015 14:34:29 -0500 (CDT) (envelope-from adam@nostrum.com) X-Authentication-Warning: raven.nostrum.com: Host 99-152-145-110.lightspeed.dllstx.sbcglobal.net [99.152.145.110] claimed to be Svantevit.roach.at Message-ID: <55D388C4.6040003@nostrum.com> Date: Tue, 18 Aug 2015 14:34:28 -0500 From: Adam Roach User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:31.0) Gecko/20100101 Thunderbird/31.7.0 MIME-Version: 1.0 To: Bernard Aboba , Harald Alvestrand References: <55D03AC6.4080100@ericsson.com> <55D2F7EC.2050001@alvestrand.no> <09F82C19-75FF-4809-8921-D74CB7C54B53@gmail.com> In-Reply-To: <09F82C19-75FF-4809-8921-D74CB7C54B53@gmail.com> Content-Type: multipart/alternative; boundary="------------030604080609020608070806" Archived-At: Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] Do we have consensus on not requiring rtcp-non-mux? X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 18 Aug 2015 19:34:37 -0000 This is a multi-part message in MIME format. --------------030604080609020608070806 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit On 8/18/15 9:35 AM, Bernard Aboba wrote: > [BA] The case you describe*could* be encountered in a situation where each simulcast/SVC stream in a conference needed to use a distinct payload type. Luckily, no conferencing system I am aware of uses PTs in that profligate way (multiplexing by SSRC is much more common) - though the suggestion has now been introduced into the WEBRTC WG. You misspelled "MMUSIC." /a --------------030604080609020608070806 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 7bit
On 8/18/15 9:35 AM, Bernard Aboba wrote:
[BA] The case you describe *could* be encountered in a situation where each simulcast/SVC stream in a conference needed to use a distinct payload type. Luckily, no conferencing system I am aware of uses PTs in that profligate way (multiplexing by SSRC is much more common) - though the suggestion has now been introduced into the WEBRTC WG.

You misspelled "MMUSIC."

/a
--------------030604080609020608070806-- From nobody Wed Aug 19 07:52:21 2015 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 48BE91B29EB for ; Wed, 19 Aug 2015 07:52:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.591 X-Spam-Level: X-Spam-Status: No, score=-0.591 tagged_above=-999 required=5 tests=[BAYES_40=-0.001, DKIM_SIGNED=0.1, RCVD_IN_DNSWL_LOW=-0.7, T_DKIM_INVALID=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 OqKJB36k9ik6 for ; Wed, 19 Aug 2015 07:52:17 -0700 (PDT) Received: from hs8.name.com (hs8.name.com [173.193.131.170]) (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 6103C1AD35F for ; Wed, 19 Aug 2015 07:52:17 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=ranjitvoip.com; s=default; h=Message-ID:References:In-Reply-To:Reply-To:Subject:Cc:To:From:Date:Content-Transfer-Encoding:Content-Type:MIME-Version; bh=1yt5QaDLNg+v+oKwff0rguzmDMH6e7FjPFBFaihRPDY=; b=dtqfmTMrU4wPqvhQ9rrhmazoCCizEV/amCadd7PueQNJlsDm/yNiwgq2C9byo/JIf2m8s0TFggi41m20gvB1rJrDk5fyar40AeByTuDl51MZI6WaKPav2vdJsVLZvE1+jpgrIO5mMPNUqYg2o3Hz89rQK0gFzAAm6Z7BMMoarjxyflraZBKS27/uBCwMF7nYpYH3/EflWQHNDYyCymYi0gqVihB/4FgGHNtwMg/XNRw3Evq4PAao2pDF/rJV4JOg5OWLyAyaCQq2y+pF35+TmljaPULpZYl6T8N6uImzHFTyCkgOqQqX/psDHU296QAe6S2/MavO5VfIrO2pStfLBg==; Received: from localhost ([127.0.0.1]:15027 helo=webmail.ranjitvoip.com) by hs8.name.com with esmtpa (Exim 4.85) (envelope-from ) id 1ZS4iu-00219W-35; Wed, 19 Aug 2015 08:52:16 -0600 MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit Date: Wed, 19 Aug 2015 09:52:15 -0500 From: Ranjit Avasarala To: Sean Turner Mail-Reply-To: ranjit@ranjitvoip.com In-Reply-To: <2C6E529A-7ECC-4919-973F-5ADFDEE4FA57@ieca.com> References: <2C6E529A-7ECC-4919-973F-5ADFDEE4FA57@ieca.com> Message-ID: <4c805d6f264e58935c1fcf22276d8e8b@ranjitvoip.com> X-Sender: ranjit@ranjitvoip.com User-Agent: Roundcube Webmail/1.0.5 X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - hs8.name.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - ranjitvoip.com X-Get-Message-Sender-Via: hs8.name.com: authenticated_id: ranjit@ranjitvoip.com Archived-At: Cc: rtcweb@ietf.org Subject: Re: [rtcweb] Call for WG adoption: draft-nandakumar-rtcweb-sdp X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: ranjit@ranjitvoip.com List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 19 Aug 2015 14:52:19 -0000 Hi Sean I support adoption of this draft as WG work item. regards Ranjit On 2015-08-14 8:39 am, Sean Turner wrote: > All, > > At the second IETF 93 RTCweb session, we agreed to send a call for WG > adoption of draft-nandakumar-rtcweb-sdp after a week of review. Well > it’s been two weeks. So without further ado … Please respond to say > whether you support adoption of this work as a working group work item > and whether you will participate in the discussion. If you are > opposed to this draft becoming a WG document, please say so (and say > why). Please have your response in by 20150821 23:59 UTC. > > Thanks in advance! > > spt > _______________________________________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/listinfo/rtcweb -- Regards Ranjit From nobody Thu Aug 20 10:46:26 2015 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A14121A1A9D for ; Thu, 20 Aug 2015 10:46:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.2 X-Spam-Level: X-Spam-Status: No, score=-6.2 tagged_above=-999 required=5 tests=[BAYES_50=0.8, GB_I_INVITATION=-2, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_REMOTE_IMAGE=0.01, 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 KVC7L5pCRGSL for ; Thu, 20 Aug 2015 10:46:22 -0700 (PDT) Received: from worker1.doodle.com (worker1.doodle.com [94.230.219.151]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4E87A1A1A90 for ; Thu, 20 Aug 2015 10:46:22 -0700 (PDT) Received: from worker1.doodle.com (localhost [127.0.0.1]) by worker1.doodle.com (Postfix) with ESMTP id 4504F104E35F for ; Thu, 20 Aug 2015 19:46:20 +0200 (CEST) Date: Thu, 20 Aug 2015 19:46:20 +0200 (CEST) From: "Sean Turner (via Doodle)" To: rtcweb@ietf.org Message-ID: <1346562718.670335.1440092780280@worker1> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_Part_670334_258725178.1440092780279" Archived-At: Subject: [rtcweb] Fall '15 RTCweb Virtual Interim X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: Sean Turner List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 20 Aug 2015 17:46:24 -0000 ------=_Part_670334_258725178.1440092780279 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Hi there, Sean Turner (turners@ieca.com) invites you to participate in the Doodle poll "Fall '15 RTCweb Virtual Interim." Participate now https://doodle.com/i4zu2iwkkngu29gz?tmail=3Dpoll_invitecontact_participant_= invitation&tlink=3Dpollbtn What is Doodle? Doodle is a web service that helps Sean Turner to find a suitable date for meeting with a group of people. Learn more about how Doodle works. (https://doodle.com/features?tlink=3DcheckOutLink&tmail=3Dpoll_invitecontac= t_participant_invitation) ---------------------------------------------------------------------- You have received this e-mail because "Sean Turner" has invited you to participate in the Doodle poll "Fall '15 RTCweb Virtual Interim." ---- Doodle is also available for iOS and Android. ---- Doodle AG, Werdstrasse 21, 8021 Z=C3=BCrich ------=_Part_670334_258725178.1440092780279 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable =
=09
Sean Turner invites you to = participate in the Doodle poll "Fall '15 RTCweb Virtual Interim.&q= uot;
=09
=09 =09 =09
=09 =09=09 =09=09 =09=09=09=09=09=09=09 =09=09 =09=09=09=09=09 =09=09=09=09=09=09=09=09 =09=09=09=09=09=09=09=09 =09
=20
=09=09 =09=09=09 =09=09=09=09 =09=09=09=09=09
=09=09=09=09=09=09
=09=09 =09=09=09 =09=09=09=09 =09=09=09=09=09 =09=09=09=09=09=09=09=09 =09=09=09=09=09=09=09=09 =09 =09=09=09=09=09=09=09=09 =09 =09=09=09=09=09=09=09=09 =09 =09=09=09=09=09=09=09=09 =09=09=09=09=09=09=09=09
=09=09=09=09=09=09
=09=09 =09=09=09 =09=09=09=09 =09=09=09=09=09 =09=09=09=09 =09=09=09 =09=09
=09=09=09=09=09=09
"Fall '15 RTC= web Virtual Interim." =09=09=09=09=09=09
=09=09=09=09=09
=09
=09=09 =09=09=09 =09=09=09=09 =09=09=09=09=09 =09=09=09=09 =09=09=09=09 =09=09=09=09=09 =09=09=09=09 =09=09=09=09 =09=09=09=09=09 =09=09=09=09 =09=09=09 =09=09
=
=09=09=09=09=09=09 =09=09=09=09=09=09 =09=09=09=09=09=09=09 =09=09=09=09=09=09 =09=09=09=09=09
=09=09=09=09=09=09=09=09Participate now =09=09=09=09=09=09=09
=09=09=09=09=09
=
=09
=09=09 =09=09=09 =09=09=09=09 =09=09=09=09=09 =09=09=09=09=09 =09=09=09=09 =09=09=09 =09=09
=09=09=09=09=09=09 =09=09=09=09=09 =09=09=09=09=09=09
=09=09=09=09=09=09=09 What is Doodle? Doodle is a web service that helps Sean Turner to find a suitable date f= or meeting with a group of people. = Learn more about how Doodle works.
=09=09=09=09=09=09
=09=09=09=09=09
=09
=09=09 =09=09 =09 =09=09 =09=09 =09=09 =09 =09=09 =09 =09=09 =09 =09=09 =09=09 =09=09 =09 =09=09 =09=09
=09=09 =09You have received this e-mail because "Sean Turner&qu= ot; has invited you to participate in the Doodle poll "Fall '15 RT= Cweb Virtual Interim." =09=09
=09
Doodle is also available for iOS and Android.
Doodle AG, Werdstrasse 21, 8021 Z=C3=BCrich

------=_Part_670334_258725178.1440092780279-- From nobody Fri Aug 21 07:09:09 2015 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 87C971A90F4 for ; Fri, 21 Aug 2015 07:09:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.496 X-Spam-Level: X-Spam-Status: No, score=-1.496 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, IP_NOT_FRIENDLY=0.334, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_SORBS_WEB=0.77, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pz32io7EFdDq for ; Fri, 21 Aug 2015 07:09:07 -0700 (PDT) Received: from mx0b-00198e01.pphosted.com (mx0b-00198e01.pphosted.com [67.231.157.197]) (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 531831A9068 for ; Fri, 21 Aug 2015 07:09:06 -0700 (PDT) Received: from pps.filterd (m0073110.ppops.net [127.0.0.1]) by mx0b-00198e01.pphosted.com (8.15.0.59/8.14.7) with SMTP id t7LE4eUA016307; Fri, 21 Aug 2015 10:09:03 -0400 Received: from mail.vidyo.com ([162.209.16.214]) by mx0b-00198e01.pphosted.com with ESMTP id 1w92un3rhj-1 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Fri, 21 Aug 2015 10:09:03 -0400 Received: from 492132-EXCH1.vidyo.com ([fe80::50:56ff:fe85:4f77]) by 492133-EXCH2.vidyo.com ([fe80::50:56ff:fe85:6b62%13]) with mapi id 14.03.0195.001; Fri, 21 Aug 2015 09:09:02 -0500 From: Jonathan Lennox To: Sean Turner Thread-Topic: [rtcweb] Fall '15 RTCweb Virtual Interim Thread-Index: AQHQ3Bps2d1vMh5WIUabGXx9oo+HkJ4W0XqA Date: Fri, 21 Aug 2015 14:09:02 +0000 Message-ID: <7FCEDD18-0C8D-478B-BAC1-DFB86E0806C9@vidyo.com> References: <1346562718.670335.1440092780280@worker1> In-Reply-To: <1346562718.670335.1440092780280@worker1> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [160.79.219.114] Content-Type: multipart/alternative; boundary="_000_7FCEDD180C8D478BBAC1DFB86E0806C9vidyocom_" MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:5.14.151, 1.0.33, 0.0.0000 definitions=2015-08-21_08:2015-08-21,2015-08-21,1970-01-01 signatures=0 X-Proofpoint-Spam-Details: rule=outbound_notspam policy=outbound score=0 spamscore=0 suspectscore=0 phishscore=0 adultscore=0 bulkscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=7.0.1-1508030000 definitions=main-1508210221 Archived-At: Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] Fall '15 RTCweb Virtual Interim X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 21 Aug 2015 14:09:08 -0000 --_000_7FCEDD180C8D478BBAC1DFB86E0806C9vidyocom_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable On Aug 20, 2015, at 1:46 PM, Sean Turner (via Doodle) > wrote: Sean Turner (turners@ieca.com) invites you to part= icipate in the Doodle poll "Fall '15 RTCweb Virtual Interim." The header of the poll says that the proposed dates are 16, 17, 18, and 28 = of September. However, the particular time options shown are for the 16, 17, 18, and 27 o= f September, September 27 being a Sunday. Is there actually a proposal to meet on Sunday 27 September? Or is this an = error setting up the doodle? --_000_7FCEDD180C8D478BBAC1DFB86E0806C9vidyocom_ Content-Type: text/html; charset="us-ascii" Content-ID: <60C3DE004C015E4396CCB7B509BE09D9@vidyo.com> Content-Transfer-Encoding: quoted-printable
On Aug 20, 2015, at 1:46 PM, Sean Turner (via Doodle) <<= a href=3D"mailto:mailer@doodle.com" class=3D"">mailer@doodle.com> wr= ote:

Sean Turner (turners@ieca.co= m) invites you to participate in the Doodle poll "Fall '15 RTCweb Virtual Interim."

The header of the poll says that the proposed dates are 16,= 17, 18, and 28 of September.

However, the particular time options shown are for the 16, = 17, 18, and 27 of September, September 27 being a Sunday.

Is there actually a proposal to meet on Sunday 27 September= ? Or is this an error setting up the doodle?
--_000_7FCEDD180C8D478BBAC1DFB86E0806C9vidyocom_-- From nobody Tue Aug 25 12:13:26 2015 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BB42B1A8A59 for ; Tue, 25 Aug 2015 12:13:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -114.511 X-Spam-Level: X-Spam-Status: No, score=-114.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, USER_IN_WHITELIST=-100] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bCv80xw2MNiJ for ; Tue, 25 Aug 2015 12:13:23 -0700 (PDT) Received: from rcdn-iport-1.cisco.com (rcdn-iport-1.cisco.com [173.37.86.72]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 918421A6FF0 for ; Tue, 25 Aug 2015 12:13:23 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=989; q=dns/txt; s=iport; t=1440530004; x=1441739604; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=1ge/vMj8XhRRJcYnTN5QhLhLkU76Cb/tGO/3WSxsS5I=; b=iGDfGtsFQKWiVmEvv6C28MeaClyS3sZzAS8Oq432Vv3JRy+d+sep9lYp cfm7L9gz5dMBV30ya74lVTiMNl47qlX5NcAym4orPygdFQ7BZ208SXP18 zm6EhF/HNwyLObGH1nUd6SQGFkzRcHi3wxOc0e/vunQBmPSpGt2wTGVVn 8=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: A0B5AgDPvdxV/5pdJa1dgxtUaQa+BQEJgW0KhTFKAoE2OBQBAQEBAQEBgQqEIwEBAQMBAQEBNzQLBQsCAQgYHhAnCyUCBAENBYgmCA3ILwEBAQEBAQEBAQEBAQEBAQEBAQEBARMEi1eEVzMHgxiBFAEElTcBjHEBmlMmg35xgUiBBAEBAQ X-IronPort-AV: E=Sophos;i="5.17,747,1437436800"; d="scan'208";a="27237069" Received: from rcdn-core-3.cisco.com ([173.37.93.154]) by rcdn-iport-1.cisco.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 25 Aug 2015 19:13:23 +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 t7PJDLeK016208 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Tue, 25 Aug 2015 19:13:22 GMT Received: from xch-rcd-013.cisco.com (173.37.102.23) by XCH-RCD-013.cisco.com (173.37.102.23) with Microsoft SMTP Server (TLS) id 15.0.1104.5; Tue, 25 Aug 2015 14:13:21 -0500 Received: from xhc-aln-x03.cisco.com (173.36.12.77) by xch-rcd-013.cisco.com (173.37.102.23) with Microsoft SMTP Server (TLS) id 15.0.1104.5 via Frontend Transport; Tue, 25 Aug 2015 14:13:21 -0500 Received: from xmb-aln-x02.cisco.com ([169.254.5.3]) by xhc-aln-x03.cisco.com ([173.36.12.77]) with mapi id 14.03.0248.002; Tue, 25 Aug 2015 14:13:20 -0500 From: "Cullen Jennings (fluffy)" To: Jonathan Lennox , Sean Turner Thread-Topic: [rtcweb] Fall '15 RTCweb Virtual Interim Thread-Index: AQHQ32oamvaaSRDDEUi3HekZnwkxaQ== Date: Tue, 25 Aug 2015 19:13:19 +0000 Message-ID: References: <1346562718.670335.1440092780280@worker1> <7FCEDD18-0C8D-478B-BAC1-DFB86E0806C9@vidyo.com> In-Reply-To: <7FCEDD18-0C8D-478B-BAC1-DFB86E0806C9@vidyo.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [173.36.7.13] Content-Type: text/plain; charset="us-ascii" Content-ID: <4D63B130A545D74294FE62E6A381A980@emea.cisco.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] Fall '15 RTCweb Virtual Interim X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 25 Aug 2015 19:13:25 -0000 That was a mess up on setting up the doodle ... but not sure how Sean will = want fix it. If it turns out we can get most people on one of the 16-18th s= lots, we could just go with that.=20 > On Aug 21, 2015, at 8:09 AM, Jonathan Lennox wrote: >=20 >=20 >> On Aug 20, 2015, at 1:46 PM, Sean Turner (via Doodle) wrote: >>=20 >> Sean Turner (turners@ieca.com) invites you to participate in the Doodle = poll "Fall '15 RTCweb Virtual Interim." >=20 > The header of the poll says that the proposed dates are 16, 17, 18, and 2= 8 of September. >=20 > However, the particular time options shown are for the 16, 17, 18, and 27= of September, September 27 being a Sunday. >=20 > Is there actually a proposal to meet on Sunday 27 September? Or is this a= n error setting up the doodle? > _______________________________________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/listinfo/rtcweb From nobody Tue Aug 25 19:43:06 2015 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2B8331A1BFF for ; Tue, 25 Aug 2015 19:43:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 h5Y5hhceBdvV for ; Tue, 25 Aug 2015 19:43:04 -0700 (PDT) Received: from gateway23.websitewelcome.com (gateway23.websitewelcome.com [192.185.48.104]) (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 017401A1BBB for ; Tue, 25 Aug 2015 19:43:04 -0700 (PDT) Received: by gateway23.websitewelcome.com (Postfix, from userid 500) id 65DF076AE790; Tue, 25 Aug 2015 21:43:03 -0500 (CDT) Received: from gator3286.hostgator.com (gator3286.hostgator.com [198.57.247.250]) by gateway23.websitewelcome.com (Postfix) with ESMTP id 5209376AE770 for ; Tue, 25 Aug 2015 21:43:03 -0500 (CDT) Received: from [96.231.216.201] (port=49728 helo=[172.16.0.112]) by gator3286.hostgator.com with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.85) (envelope-from ) id 1ZUQg1-000Xvs-4n; Tue, 25 Aug 2015 21:43:01 -0500 Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) From: Sean Turner In-Reply-To: <7FCEDD18-0C8D-478B-BAC1-DFB86E0806C9@vidyo.com> Date: Tue, 25 Aug 2015 22:39:11 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: References: <1346562718.670335.1440092780280@worker1> <7FCEDD18-0C8D-478B-BAC1-DFB86E0806C9@vidyo.com> To: "rtcweb@ietf.org" X-Mailer: Apple Mail (2.1878.6) X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - gator3286.hostgator.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - ieca.com X-BWhitelist: no X-Source-IP: 96.231.216.201 X-Exim-ID: 1ZUQg1-000Xvs-4n X-Source: X-Source-Args: X-Source-Dir: X-Source-Sender: ([172.16.0.112]) [96.231.216.201]:49728 X-Source-Auth: sean.turner@ieca.com X-Email-Count: 5 X-Source-Cap: ZG9tbWdyNDg7ZG9tbWdyNDg7Z2F0b3IzMjg2Lmhvc3RnYXRvci5jb20= Archived-At: Cc: Jonathan Lennox Subject: Re: [rtcweb] Fall '15 RTCweb Virtual Interim X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 26 Aug 2015 02:43:05 -0000 Okay I finally got around to fixing this. Please go ahead and update = your responses to show your availability on the 28th of September - a = Monday. Thanks for catching this. spt On Aug 21, 2015, at 10:09, Jonathan Lennox wrote: >=20 >> On Aug 20, 2015, at 1:46 PM, Sean Turner (via Doodle) = wrote: >>=20 >> Sean Turner (turners@ieca.com) invites you to participate in the = Doodle poll "Fall '15 RTCweb Virtual Interim." >=20 > The header of the poll says that the proposed dates are 16, 17, 18, = and 28 of September. >=20 > However, the particular time options shown are for the 16, 17, 18, and = 27 of September, September 27 being a Sunday. >=20 > Is there actually a proposal to meet on Sunday 27 September? Or is = this an error setting up the doodle?