From nobody Tue Jan 3 11:44:01 2017 Return-Path: X-Original-To: ice@ietfa.amsl.com Delivered-To: ice@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2C047129B2F; Tue, 3 Jan 2017 11:44:00 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -17.621 X-Spam-Level: X-Spam-Status: No, score=-17.621 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, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-3.1, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id f26emO4Wpzm5; Tue, 3 Jan 2017 11:43:58 -0800 (PST) Received: from alln-iport-7.cisco.com (alln-iport-7.cisco.com [173.37.142.94]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id F342C129B2E; Tue, 3 Jan 2017 11:43:57 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=21506; q=dns/txt; s=iport; t=1483472638; x=1484682238; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=Z/PV3QGOqmSkyPeAQbegnhws/PnoTOMk3VHnEO7RaAU=; b=XV0UL5Wf/Zoo57ZrN88eZTySPu28h7+J76D0c/XkciS6M6Gtlu5y5jRj +JZ9Y3lIlbSAWpoSrvycbQ7yzKqt4oLX3Q9GcGjInBrFAD/9aV5TxZl+n 6VchY5ImBL37bUsvO65gaRJGFOHMlFbfYgI6VcALLCdwz3UVnV6xVAyyo 8=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0BHAQAd/mtY/4sNJK1dGQEBAQEBAQEBA?= =?us-ascii?q?QEBBwEBAQEBgnFGAQEBAQEfX4EMB41QlEeHe4d4gxmCD4IIKoV4AhqBMj8UAQI?= =?us-ascii?q?BAQEBAQEBYiiEaAEBAQQjVhACAQgRAwECKAMCAgIfERQJCAIEDgUbiDoDGA6vL?= =?us-ascii?q?4IlK4cPDYJkAQEBAQEBAQEBAQEBAQEBAQEBAQEBGAWIR4FZgQaCToIYFoJOLYI?= =?us-ascii?q?wBZUJhT81AYZThnGDeZBViXOEO4QOAR84gSo8AYVOcgGHMIENAQEB?= X-IronPort-AV: E=Sophos;i="5.33,456,1477958400"; d="scan'208,217";a="368110480" Received: from alln-core-6.cisco.com ([173.36.13.139]) by alln-iport-7.cisco.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 03 Jan 2017 19:43:57 +0000 Received: from XCH-RCD-019.cisco.com (xch-rcd-019.cisco.com [173.37.102.29]) by alln-core-6.cisco.com (8.14.5/8.14.5) with ESMTP id v03JhuSg013608 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Tue, 3 Jan 2017 19:43:57 GMT Received: from xch-aln-018.cisco.com (173.36.7.28) by XCH-RCD-019.cisco.com (173.37.102.29) with Microsoft SMTP Server (TLS) id 15.0.1210.3; Tue, 3 Jan 2017 13:43:56 -0600 Received: from xch-aln-018.cisco.com ([173.36.7.28]) by XCH-ALN-018.cisco.com ([173.36.7.28]) with mapi id 15.00.1210.000; Tue, 3 Jan 2017 13:43:56 -0600 From: "Charles Eckel (eckelcu)" To: Roman Shpount Thread-Topic: [MMUSIC] [bfcpbis] m= line protocol in case of ICE Thread-Index: AQHSZfm46LjmSy7T7UmDYerMTbGdsg== Date: Tue, 3 Jan 2017 19:43:55 +0000 Message-ID: <633D3491-83B1-421F-B48C-0A61B1314E99@cisco.com> References: <7594FB04B1934943A5C02806D1A2204B4BE3AE83@ESESSMB209.ericsson.se> <16B5D8FF-F132-4B09-84D6-AE964CA7858D@cisco.com> <64E8A5CF-89ED-4673-AF23-2C960395C3EF@cisco.com> In-Reply-To: <64E8A5CF-89ED-4673-AF23-2C960395C3EF@cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/f.1d.0.161209 x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.156.130.138] Content-Type: multipart/alternative; boundary="_000_633D349183B1421FB48C0A61B1314E99ciscocom_" MIME-Version: 1.0 Archived-At: Cc: "bfcpbis@ietf.org" , Christer Holmberg , "mmusic@ietf.org" , "ice@ietf.org" Subject: Re: [Ice] [MMUSIC] [bfcpbis] m= line protocol in case of ICE X-BeenThere: ice@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Interactive Connectivity Establishment \(ICE\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 Jan 2017 19:44:00 -0000 --_000_633D349183B1421FB48C0A61B1314E99ciscocom_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 Q3JpY2tldHPigKYNCklmIG5vIG9uZSBpcyBvciBoYXMgcGxhbnMgZm9yIHVzaW5nIElDRSB3aXRo IFRDUC9CRkNQLCBwZXJoYXBzIGl0IGlzIGJlc3QgdG8gc3RhdGUgdGhhdCBhcyBvZiB0aGlzIHJl diBvZiB0aGUgQkZDUCBzcGVjLCBCRkNQIHdpdGggVENQIGNhbmRpZGF0ZXMgaXMgbm90IGRlZmlu ZWQuIEZ1dHVyZSB1cGRhdGVzIHRvIHRoZSBzcGVjIG1heSBkZWZpbmUgdGhpcyB1c2FnZS4NCg0K Q2hlZXJzLA0KQ2hhcmxlcw0KDQpGcm9tOiBtbXVzaWMgPG1tdXNpYy1ib3VuY2VzQGlldGYub3Jn PiBvbiBiZWhhbGYgb2YgQ2hhcmxlcyBFY2tlbCA8ZWNrZWxjdUBjaXNjby5jb20+DQpEYXRlOiBG cmlkYXksIERlY2VtYmVyIDIsIDIwMTYgYXQgNDowMSBQTQ0KVG86IFJvbWFuIFNocG91bnQgPHJv bWFuQHRlbHVyaXguY29tPg0KQ2M6ICJpY2VAaWV0Zi5vcmciIDxpY2VAaWV0Zi5vcmc+LCAiYmZj cGJpc0BpZXRmLm9yZyIgPGJmY3BiaXNAaWV0Zi5vcmc+LCBDaHJpc3RlciBIb2xtYmVyZyA8Y2hy aXN0ZXIuaG9sbWJlcmdAZXJpY3Nzb24uY29tPiwgIm1tdXNpY0BpZXRmLm9yZyIgPG1tdXNpY0Bp ZXRmLm9yZz4NClN1YmplY3Q6IFJlOiBbTU1VU0lDXSBbYmZjcGJpc10gbT0gbGluZSBwcm90b2Nv bCBpbiBjYXNlIG9mIElDRQ0KDQpJIGhhdmUgbm8gZXhwZXJpZW5jZSB3aXRoIElDRSB3aXRoIFRD UCBjYW5kaWRhdGVzIHNvIGhvcGVmdWxseSBvdGhlcnMgY2FuIGNoaW1lIGluIGFzIHRvIHdoYXQg dGhleSB0aGluayBpcyBhIHdvcmthYmxlIHNvbHV0aW9uLg0KDQpDaGVlcnMsDQpDaGFybGVzDQoN CkZyb206IFJvbWFuIFNocG91bnQgPHJvbWFuQHRlbHVyaXguY29tPg0KRGF0ZTogVGh1cnNkYXks IERlY2VtYmVyIDEsIDIwMTYgYXQgMTI6MzQgUE0NClRvOiBDaGFybGVzIEVja2VsIDxlY2tlbGN1 QGNpc2NvLmNvbT4NCkNjOiBBbGFuIEZvcmQgPGFsYW4uZm9yZEBnbWFpbC5jb20+LCAiYmZjcGJp c0BpZXRmLm9yZyIgPGJmY3BiaXNAaWV0Zi5vcmc+LCAiaWNlQGlldGYub3JnIiA8aWNlQGlldGYu b3JnPiwgIm1tdXNpY0BpZXRmLm9yZyIgPG1tdXNpY0BpZXRmLm9yZz4sIENocmlzdGVyIEhvbG1i ZXJnIDxjaHJpc3Rlci5ob2xtYmVyZ0Blcmljc3Nvbi5jb20+DQpTdWJqZWN0OiBSZTogW2JmY3Bi aXNdIFtNTVVTSUNdIG09IGxpbmUgcHJvdG9jb2wgaW4gY2FzZSBvZiBJQ0UNCg0KQ2hhcmxlcywN Cg0KUkZDIDY1NDQgU2VuZGluZyBNZWRpYSAoaHR0cHM6Ly90b29scy5pZXRmLm9yZy9odG1sL3Jm YzY1NDQjc2VjdGlvbi0xMC4xKSBzYXlzIHRoYXQgIlRoZSBmcmFtaW5nIGRlZmluZWQgaW4gUkZD IDQ1NzE8aHR0cHM6Ly90b29scy5pZXRmLm9yZy9odG1sL3JmYzQ1NzE+IE1VU1QgYmUgdXNlZCB3 aGVuIHNlbmRpbmcgbWVkaWEuIiBUaGlzIG1lYW5zIHRoZSBwcm90b2NvbCB1c2VkIGlzIG5vdCBU Q1AvQkZDUCB3aGljaCBpcyB1c2luZyBhcHBsaWNhdGlvbiBsZXZlbCBmcmFtaW5nLiBJIGJlbGll dmUgdGhhdCBTVFVOL01lZGlhIGRlbXVsdGlwbGV4aW5nIHJlcXVpcmVtZW50cyB3b3VsZCBwcmV2 ZW50IHVzaW5nIFRDUC9CRkNQIGRpcmVjdGx5IHdpdGggaWNlIHRjcCBjYW5kaWRhdGVzIHdpdGhv dXQgcmVkZXNpZ24gb2YgZWl0aGVyIElDRSBUQ1Agb3IgVENQL0JGQ1AuDQoNCkZ1cnRoZXJtb3Jl IHRoZXJlIGFyZSBvdGhlciBpbXBsaWVkIElDRSByZXF1aXJlbWVudHMgdGhhdCBJIG91dGxpbmVk IGJlZm9yZSAoc3dpdGNoaW5nIGJldHdlZW4gdWRwIGFuZCB0cGMgY2FuZGlkYXRlcywgZXhpc3Rl bmNlIG9mIFNCQyB3aGljaCB0ZXJtaW5hdGUgSUNFIG9ubHkgYnV0IGRvIG5vdCBzdXBwb3J0IHRo ZSBlbWJlZGRlZCBwcm90b2NvbCkgYmVjYXVzZSBvZiB3aGljaCBpY2UgdGNwIGlzIGNvbnNpZGVy ZWQgdW5yZWxpYWJsZSB0cmFuc3BvcnQgYW5kIHdpbGwgcmVxdWlyZSBmcmFnbWVudGF0aW9uIHN1 cHBvcnQgYW5kIHJlLXRyYW5zbWl0IHRpbWVycyB0aGF0IGFyZSBub3QgcGFydCBvZiBUQ1AvQkZD UC4NCg0KUmVnYXJkcywNCg0KX19fX19fX19fX19fXw0KUm9tYW4gU2hwb3VudA0KDQpPbiBUaHUs IERlYyAxLCAyMDE2IGF0IDM6MTcgUE0sIENoYXJsZXMgRWNrZWwgKGVja2VsY3UpIDxlY2tlbGN1 QGNpc2NvLmNvbTxtYWlsdG86ZWNrZWxjdUBjaXNjby5jb20+PiB3cm90ZToNClJvbWFuLA0KDQpX aHkgd291bGQgc2VsZWN0aW5nIFRDUC9CRkNQIGFzIHRyYW5zcG9ydCB2aW9sYXRlIFJGQyA2NTQ0 PyBQZXJoYXBzIGl0IGRvZXMsIGJ1dCBhZnRlciBhIHF1aWNrIHNjYW4gSSBhbSBub3Qgc3VyZSB3 aHkuDQoNCkNoZWVycywNCkNoYXJsZXMNCg0KRnJvbTogUm9tYW4gU2hwb3VudCA8cm9tYW5AdGVs dXJpeC5jb208bWFpbHRvOnJvbWFuQHRlbHVyaXguY29tPj4NCkRhdGU6IFR1ZXNkYXksIE5vdmVt YmVyIDI5LCAyMDE2IGF0IDEwOjM4IEFNDQpUbzogQ2hhcmxlcyBFY2tlbCA8ZWNrZWxjdUBjaXNj by5jb208bWFpbHRvOmVja2VsY3VAY2lzY28uY29tPj4NCkNjOiBBbGFuIEZvcmQgPGFsYW4uZm9y ZEBnbWFpbC5jb208bWFpbHRvOmFsYW4uZm9yZEBnbWFpbC5jb20+PiwgImJmY3BiaXNAaWV0Zi5v cmc8bWFpbHRvOmJmY3BiaXNAaWV0Zi5vcmc+IiA8YmZjcGJpc0BpZXRmLm9yZzxtYWlsdG86YmZj cGJpc0BpZXRmLm9yZz4+LCAiaWNlQGlldGYub3JnPG1haWx0bzppY2VAaWV0Zi5vcmc+IiA8aWNl QGlldGYub3JnPG1haWx0bzppY2VAaWV0Zi5vcmc+PiwgIm1tdXNpY0BpZXRmLm9yZzxtYWlsdG86 bW11c2ljQGlldGYub3JnPiIgPG1tdXNpY0BpZXRmLm9yZzxtYWlsdG86bW11c2ljQGlldGYub3Jn Pj4sIENocmlzdGVyIEhvbG1iZXJnIDxjaHJpc3Rlci5ob2xtYmVyZ0Blcmljc3Nvbi5jb208bWFp bHRvOmNocmlzdGVyLmhvbG1iZXJnQGVyaWNzc29uLmNvbT4+DQpTdWJqZWN0OiBSZTogW2JmY3Bi aXNdIFtNTVVTSUNdIG09IGxpbmUgcHJvdG9jb2wgaW4gY2FzZSBvZiBJQ0UNCg0KT24gVHVlLCBO b3YgMjksIDIwMTYgYXQgMTI6NDggUE0sIENoYXJsZXMgRWNrZWwgKGVja2VsY3UpIDxlY2tlbGN1 QGNpc2NvLmNvbTxtYWlsdG86ZWNrZWxjdUBjaXNjby5jb20+PiB3cm90ZToNCkl0IHNlZW1zIHRv IG1lIHRoYXQgdGhlIG1vc3Qgc3RyYWlnaHRmb3J3YXJkIGFwcHJvYWNoIHdvdWxkIGJlIHRvIG1h bmRhdGUgc3VwcG9ydCBmb3IgQkZDUCBvdmVyIFVEUCB3aGVuIHVzaW5nIElDRSwgdXNlIFVEUCBh cyB0aGUgZGVmYXVsdCBjYW5kaWRhdGUsIGFuZCBzaWduYWwgdGhlIEJGQ1AgbS1saW5lIGFzIGlm IGl0IGlzIEJGQ1Agb3ZlciBVRFAuIElmIHdlIGNhbiBtYW5kYXRlIHRoZSB1c2Ugb2YgRFRMUywg dGhhdCB3b3VsZCBiZSBldmVuIGJldHRlci4NClRob3VnaHRzPw0KDQoNCkkgYWdyZWUuDQoNClRo ZSBvbmx5IGlzc3VlIHRoYXQgSSBzdGlsbCBoYXZlLCBpZiBEVExTIGlzIG5vdCB1c2VkLCB3aGF0 IHByb3RvY29sIGlzIHVzZWQgd2hlbiBJQ0UgdGNwIGNhbmRpZGF0ZSBpcyBzZWxlY3RlZCBmb3Ig dHJhbnNwb3J0LiBJcyB0aGlzIFRDUC9CRkNQICh3aGljaCBnb2VzIGFnYWluc3QgUkZDNjU0NCkg IG9yIGlzIGl0IFVEUC9CRkNQIHdpdGggUkZDNDU3MSBmcmFtaW5nPyBJZiBpdCBpcyBVRFAvQkZD UCB3aXRoIFJGQzQ1NzEgZnJhbWluZywgd2hhdCB0cmFuc3BvcnQgdGFnIHNob3VsZCBiZSB1c2Vk IGluIHRoZSByZS1JTlZJVEUgd2hpY2ggaXMgc2VudCBhZnRlciBJQ0Ugbm9taW5hdGlvbiB3aXRo IG9ubHkgc2VsZWN0ZWQgY2FuZGlkYXRlPyBTaG91bGQgaXQgYmUgVENQL1VEUC9CRkNQIG9yIHNv bWV0aGluZyBzaW1pbGFyPw0KDQpSZWdhcmRzLA0KX19fX19fX19fX19fXw0KUm9tYW4gU2hwb3Vu dA0KDQoNCg== --_000_633D349183B1421FB48C0A61B1314E99ciscocom_ Content-Type: text/html; charset="utf-8" Content-ID: <26F517D76A00684796153C9920564741@emea.cisco.com> Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6bz0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6b2ZmaWNlIiB4 bWxuczp3PSJ1cm46c2NoZW1hcy1taWNyb3NvZnQtY29tOm9mZmljZTp3b3JkIiB4bWxuczptPSJo dHRwOi8vc2NoZW1hcy5taWNyb3NvZnQuY29tL29mZmljZS8yMDA0LzEyL29tbWwiIHhtbG5zPSJo dHRwOi8vd3d3LnczLm9yZy9UUi9SRUMtaHRtbDQwIj4NCjxoZWFkPg0KPG1ldGEgaHR0cC1lcXVp dj0iQ29udGVudC1UeXBlIiBjb250ZW50PSJ0ZXh0L2h0bWw7IGNoYXJzZXQ9dXRmLTgiPg0KPG1l dGEgbmFtZT0iVGl0bGUiIGNvbnRlbnQ9IiI+DQo8bWV0YSBuYW1lPSJLZXl3b3JkcyIgY29udGVu dD0iIj4NCjxtZXRhIG5hbWU9IkdlbmVyYXRvciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUg KGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxlPjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8N CkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6IkNhbWJyaWEgTWF0aCI7DQoJcGFub3NlLTE6MiA0 IDUgMyA1IDQgNiAzIDIgNDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OkNhbGlicmk7DQoJ cGFub3NlLTE6MiAxNSA1IDIgMiAyIDQgMyAyIDQ7fQ0KLyogU3R5bGUgRGVmaW5pdGlvbnMgKi8N CnAuTXNvTm9ybWFsLCBsaS5Nc29Ob3JtYWwsIGRpdi5Nc29Ob3JtYWwNCgl7bWFyZ2luOjBpbjsN CgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJZm9udC1zaXplOjEyLjBwdDsNCglmb250LWZhbWls eToiVGltZXMgTmV3IFJvbWFuIjt9DQphOmxpbmssIHNwYW4uTXNvSHlwZXJsaW5rDQoJe21zby1z dHlsZS1wcmlvcml0eTo5OTsNCgljb2xvcjpibHVlOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxp bmU7fQ0KYTp2aXNpdGVkLCBzcGFuLk1zb0h5cGVybGlua0ZvbGxvd2VkDQoJe21zby1zdHlsZS1w cmlvcml0eTo5OTsNCgljb2xvcjpwdXJwbGU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9 DQpzcGFuLkVtYWlsU3R5bGUxNw0KCXttc28tc3R5bGUtdHlwZTpwZXJzb25hbDsNCglmb250LWZh bWlseToiVGltZXMgTmV3IFJvbWFuIjsNCgljb2xvcjp3aW5kb3d0ZXh0O30NCnNwYW4uRW1haWxT dHlsZTE4DQoJe21zby1zdHlsZS10eXBlOnBlcnNvbmFsLXJlcGx5Ow0KCWZvbnQtZmFtaWx5OiJU aW1lcyBOZXcgUm9tYW4iOw0KCWNvbG9yOndpbmRvd3RleHQ7fQ0Kc3Bhbi5tc29JbnMNCgl7bXNv LXN0eWxlLXR5cGU6ZXhwb3J0LW9ubHk7DQoJbXNvLXN0eWxlLW5hbWU6IiI7DQoJdGV4dC1kZWNv cmF0aW9uOnVuZGVybGluZTsNCgljb2xvcjp0ZWFsO30NCi5Nc29DaHBEZWZhdWx0DQoJe21zby1z dHlsZS10eXBlOmV4cG9ydC1vbmx5Ow0KCWZvbnQtc2l6ZToxMC4wcHQ7fQ0KQHBhZ2UgV29yZFNl Y3Rpb24xDQoJe3NpemU6OC41aW4gMTEuMGluOw0KCW1hcmdpbjoxLjBpbiAxLjBpbiAxLjBpbiAx LjBpbjt9DQpkaXYuV29yZFNlY3Rpb24xDQoJe3BhZ2U6V29yZFNlY3Rpb24xO30NCi0tPjwvc3R5 bGU+DQo8L2hlYWQ+DQo8Ym9keSBiZ2NvbG9yPSJ3aGl0ZSIgbGFuZz0iRU4tVVMiIGxpbms9ImJs dWUiIHZsaW5rPSJwdXJwbGUiPg0KPGRpdiBjbGFzcz0iV29yZFNlY3Rpb24xIj4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPkNyaWNrZXRz4oCmPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj5JZiBubyBvbmUgaXMgb3IgaGFzIHBsYW5zIGZvciB1c2luZyBJQ0Ugd2l0aCBUQ1AvQkZD UCwgcGVyaGFwcyBpdCBpcyBiZXN0IHRvIHN0YXRlIHRoYXQgYXMgb2YgdGhpcyByZXYgb2YgdGhl IEJGQ1Agc3BlYywgQkZDUCB3aXRoIFRDUCBjYW5kaWRhdGVzIGlzIG5vdCBkZWZpbmVkLiBGdXR1 cmUgdXBkYXRlcyB0byB0aGUgc3BlYyBtYXkgZGVmaW5lIHRoaXMgdXNhZ2UuPG86cD48L286cD48 L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPkNoZWVycyw8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PkNoYXJsZXM8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7 PC9vOnA+PC9wPg0KPGJsb2NrcXVvdGUgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci1sZWZ0OnNv bGlkICNCNUM0REYgNC41cHQ7cGFkZGluZzowaW4gMGluIDBpbiA0LjBwdDttYXJnaW4tbGVmdDoz Ljc1cHQ7bWFyZ2luLXJpZ2h0OjBpbiI+DQo8ZGl2IHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXIt dG9wOnNvbGlkICNCNUM0REYgMS4wcHQ7cGFkZGluZzozLjBwdCAwaW4gMGluIDBpbiI+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj48Yj48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6Q2FsaWJyaTtjb2xv cjpibGFjayI+RnJvbTogPC9zcGFuPg0KPC9iPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTpDYWxp YnJpO2NvbG9yOmJsYWNrIj5tbXVzaWMgJmx0O21tdXNpYy1ib3VuY2VzQGlldGYub3JnJmd0OyBv biBiZWhhbGYgb2YgQ2hhcmxlcyBFY2tlbCAmbHQ7ZWNrZWxjdUBjaXNjby5jb20mZ3Q7PGJyPg0K PGI+RGF0ZTogPC9iPkZyaWRheSwgRGVjZW1iZXIgMiwgMjAxNiBhdCA0OjAxIFBNPGJyPg0KPGI+ VG86IDwvYj5Sb21hbiBTaHBvdW50ICZsdDtyb21hbkB0ZWx1cml4LmNvbSZndDs8YnI+DQo8Yj5D YzogPC9iPiZxdW90O2ljZUBpZXRmLm9yZyZxdW90OyAmbHQ7aWNlQGlldGYub3JnJmd0OywgJnF1 b3Q7YmZjcGJpc0BpZXRmLm9yZyZxdW90OyAmbHQ7YmZjcGJpc0BpZXRmLm9yZyZndDssIENocmlz dGVyIEhvbG1iZXJnICZsdDtjaHJpc3Rlci5ob2xtYmVyZ0Blcmljc3Nvbi5jb20mZ3Q7LCAmcXVv dDttbXVzaWNAaWV0Zi5vcmcmcXVvdDsgJmx0O21tdXNpY0BpZXRmLm9yZyZndDs8YnI+DQo8Yj5T dWJqZWN0OiA8L2I+UmU6IFtNTVVTSUNdIFtiZmNwYmlzXSBtPSBsaW5lIHByb3RvY29sIGluIGNh c2Ugb2YgSUNFPG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPkkgaGF2ZSBubyBleHBlcmllbmNlIHdpdGggSUNFIHdpdGggVENQIGNhbmRpZGF0ZXMg c28gaG9wZWZ1bGx5IG90aGVycyBjYW4gY2hpbWUgaW4gYXMgdG8gd2hhdCB0aGV5IHRoaW5rIGlz IGEgd29ya2FibGUgc29sdXRpb24uDQo8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Q2hlZXJzLDxv OnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Q2hhcmxlczxvOnA+PC9vOnA+PC9w Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8YmxvY2txdW90 ZSBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLWxlZnQ6c29saWQgI0I1QzRERiA0LjVwdDtwYWRk aW5nOjBpbiAwaW4gMGluIDQuMHB0O21hcmdpbi1sZWZ0OjMuNzVwdDttYXJnaW4tdG9wOjUuMHB0 O21hcmdpbi1yaWdodDowaW47bWFyZ2luLWJvdHRvbTo1LjBwdCI+DQo8ZGl2IHN0eWxlPSJib3Jk ZXI6bm9uZTtib3JkZXItdG9wOnNvbGlkICNCNUM0REYgMS4wcHQ7cGFkZGluZzozLjBwdCAwaW4g MGluIDBpbiI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48Yj48c3BhbiBzdHlsZT0iZm9udC1mYW1p bHk6Q2FsaWJyaTtjb2xvcjpibGFjayI+RnJvbTogPC9zcGFuPg0KPC9iPjxzcGFuIHN0eWxlPSJm b250LWZhbWlseTpDYWxpYnJpO2NvbG9yOmJsYWNrIj5Sb21hbiBTaHBvdW50ICZsdDtyb21hbkB0 ZWx1cml4LmNvbSZndDs8YnI+DQo8Yj5EYXRlOiA8L2I+VGh1cnNkYXksIERlY2VtYmVyIDEsIDIw MTYgYXQgMTI6MzQgUE08YnI+DQo8Yj5UbzogPC9iPkNoYXJsZXMgRWNrZWwgJmx0O2Vja2VsY3VA Y2lzY28uY29tJmd0Ozxicj4NCjxiPkNjOiA8L2I+QWxhbiBGb3JkICZsdDthbGFuLmZvcmRAZ21h aWwuY29tJmd0OywgJnF1b3Q7YmZjcGJpc0BpZXRmLm9yZyZxdW90OyAmbHQ7YmZjcGJpc0BpZXRm Lm9yZyZndDssICZxdW90O2ljZUBpZXRmLm9yZyZxdW90OyAmbHQ7aWNlQGlldGYub3JnJmd0Oywg JnF1b3Q7bW11c2ljQGlldGYub3JnJnF1b3Q7ICZsdDttbXVzaWNAaWV0Zi5vcmcmZ3Q7LCBDaHJp c3RlciBIb2xtYmVyZyAmbHQ7Y2hyaXN0ZXIuaG9sbWJlcmdAZXJpY3Nzb24uY29tJmd0Ozxicj4N CjxiPlN1YmplY3Q6IDwvYj5SZTogW2JmY3BiaXNdIFtNTVVTSUNdIG09IGxpbmUgcHJvdG9jb2wg aW4gY2FzZSBvZiBJQ0U8L3NwYW4+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPkNoYXJsZXMsIDxvOnA+PC9vOnA+PC9wPg0KPGRpdj4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+UkZDIDY1NDQgU2VuZGluZyBNZWRpYSAoPGEgaHJlZj0iaHR0cHM6 Ly90b29scy5pZXRmLm9yZy9odG1sL3JmYzY1NDQjc2VjdGlvbi0xMC4xIj5odHRwczovL3Rvb2xz LmlldGYub3JnL2h0bWwvcmZjNjU0NCNzZWN0aW9uLTEwLjE8L2E+KSZuYnNwO3NheXMgdGhhdCAm cXVvdDs8c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtjb2xvcjpibGFjayI+VGhlIGZyYW1p bmcgZGVmaW5lZCBpbg0KPC9zcGFuPjxhIGhyZWY9Imh0dHBzOi8vdG9vbHMuaWV0Zi5vcmcvaHRt bC9yZmM0NTcxIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdCI+UkZDIDQ1NzE8L3NwYW4+ PC9hPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2NvbG9yOmJsYWNrIj4gTVVTVCBiZSB1 c2VkIHdoZW4gc2VuZGluZyBtZWRpYS4mcXVvdDsgVGhpcyBtZWFucyB0aGUgcHJvdG9jb2wgdXNl ZCBpcyBub3QgVENQL0JGQ1Agd2hpY2ggaXMgdXNpbmcgYXBwbGljYXRpb24gbGV2ZWwNCiBmcmFt aW5nLiBJIGJlbGlldmUgdGhhdCBTVFVOL01lZGlhIGRlbXVsdGlwbGV4aW5nIHJlcXVpcmVtZW50 cyB3b3VsZCBwcmV2ZW50IHVzaW5nIFRDUC9CRkNQIGRpcmVjdGx5IHdpdGggaWNlIHRjcCBjYW5k aWRhdGVzIHdpdGhvdXQgcmVkZXNpZ24gb2YgZWl0aGVyIElDRSBUQ1Agb3IgVENQL0JGQ1AuPC9z cGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ Jm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtjb2xvcjpibGFjayI+RnVydGhlcm1vcmUm bmJzcDt0aGVyZSBhcmUgb3RoZXIgaW1wbGllZCBJQ0UgcmVxdWlyZW1lbnRzIHRoYXQgSSBvdXRs aW5lZCBiZWZvcmUgKHN3aXRjaGluZyBiZXR3ZWVuIHVkcCBhbmQgdHBjIGNhbmRpZGF0ZXMsIGV4 aXN0ZW5jZSBvZiBTQkMgd2hpY2ggdGVybWluYXRlIElDRSBvbmx5IGJ1dCBkbyBub3Qgc3VwcG9y dCB0aGUgZW1iZWRkZWQNCiBwcm90b2NvbCkgYmVjYXVzZSBvZiB3aGljaCBpY2UgdGNwIGlzIGNv bnNpZGVyZWQgdW5yZWxpYWJsZSB0cmFuc3BvcnQgYW5kIHdpbGwgcmVxdWlyZSBmcmFnbWVudGF0 aW9uIHN1cHBvcnQgYW5kIHJlLXRyYW5zbWl0IHRpbWVycyB0aGF0IGFyZSBub3QgcGFydCBvZiBU Q1AvQkZDUC48L3NwYW4+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2NvbG9yOmJsYWNrIj5S ZWdhcmRzLDwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+PGJyIGNsZWFyPSJhbGwiPg0KPG86cD48L286cD48L3A+DQo8ZGl2 Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPl9fX19fX19fX19fX188YnI+DQpSb21hbiBT aHBvdW50PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+T24g VGh1LCBEZWMgMSwgMjAxNiBhdCAzOjE3IFBNLCBDaGFybGVzIEVja2VsIChlY2tlbGN1KSAmbHQ7 PGEgaHJlZj0ibWFpbHRvOmVja2VsY3VAY2lzY28uY29tIiB0YXJnZXQ9Il9ibGFuayI+ZWNrZWxj dUBjaXNjby5jb208L2E+Jmd0OyB3cm90ZTo8bzpwPjwvbzpwPjwvcD4NCjxibG9ja3F1b3RlIHN0 eWxlPSJib3JkZXI6bm9uZTtib3JkZXItbGVmdDpzb2xpZCAjQ0NDQ0NDIDEuMHB0O3BhZGRpbmc6 MGluIDBpbiAwaW4gNi4wcHQ7bWFyZ2luLWxlZnQ6NC44cHQ7bWFyZ2luLXRvcDo1LjBwdDttYXJn aW4tcmlnaHQ6MGluO21hcmdpbi1ib3R0b206NS4wcHQiPg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1i b3R0b20tYWx0OmF1dG8iPlJvbWFuLDxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1h bCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDph dXRvIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJt c28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+V2h5IHdv dWxkIHNlbGVjdGluZyBUQ1AvQkZDUCBhcyB0cmFuc3BvcnQgdmlvbGF0ZSBSRkMgNjU0ND8gUGVy aGFwcyBpdCBkb2VzLCBidXQgYWZ0ZXIgYSBxdWljayBzY2FuIEkgYW0gbm90IHN1cmUgd2h5Ljxv OnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9w LWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj4mbmJzcDs8bzpwPjwvbzpwPjwv cD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bztt c28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+Q2hlZXJzLDxvOnA+PC9vOnA+PC9wPg0KPHAgY2xh c3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4t Ym90dG9tLWFsdDphdXRvIj5DaGFybGVzPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0 OmF1dG8iPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPGJsb2NrcXVvdGUgc3R5bGU9ImJvcmRlcjpu b25lO2JvcmRlci1sZWZ0OnNvbGlkICNCNUM0REYgNC41cHQ7cGFkZGluZzowaW4gMGluIDBpbiA0 LjBwdDttYXJnaW4tbGVmdDozLjc1cHQ7bWFyZ2luLXRvcDo1LjBwdDttYXJnaW4tcmlnaHQ6MGlu O21hcmdpbi1ib3R0b206NS4wcHQiPg0KPGRpdiBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLXRv cDpzb2xpZCAjQjVDNERGIDEuMHB0O3BhZGRpbmc6My4wcHQgMGluIDBpbiAwaW4iPg0KPHAgY2xh c3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4t Ym90dG9tLWFsdDphdXRvIj48Yj48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6Q2FsaWJyaTtjb2xv cjpibGFjayI+RnJvbToNCjwvc3Bhbj48L2I+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OkNhbGli cmk7Y29sb3I6YmxhY2siPlJvbWFuIFNocG91bnQgJmx0OzxhIGhyZWY9Im1haWx0bzpyb21hbkB0 ZWx1cml4LmNvbSIgdGFyZ2V0PSJfYmxhbmsiPnJvbWFuQHRlbHVyaXguY29tPC9hPiZndDs8YnI+ DQo8Yj5EYXRlOiA8L2I+VHVlc2RheSwgTm92ZW1iZXIgMjksIDIwMTYgYXQgMTA6MzggQU08YnI+ DQo8Yj5UbzogPC9iPkNoYXJsZXMgRWNrZWwgJmx0OzxhIGhyZWY9Im1haWx0bzplY2tlbGN1QGNp c2NvLmNvbSIgdGFyZ2V0PSJfYmxhbmsiPmVja2VsY3VAY2lzY28uY29tPC9hPiZndDs8YnI+DQo8 Yj5DYzogPC9iPkFsYW4gRm9yZCAmbHQ7PGEgaHJlZj0ibWFpbHRvOmFsYW4uZm9yZEBnbWFpbC5j b20iIHRhcmdldD0iX2JsYW5rIj5hbGFuLmZvcmRAZ21haWwuY29tPC9hPiZndDssICZxdW90Ozxh IGhyZWY9Im1haWx0bzpiZmNwYmlzQGlldGYub3JnIiB0YXJnZXQ9Il9ibGFuayI+YmZjcGJpc0Bp ZXRmLm9yZzwvYT4mcXVvdDsgJmx0OzxhIGhyZWY9Im1haWx0bzpiZmNwYmlzQGlldGYub3JnIiB0 YXJnZXQ9Il9ibGFuayI+YmZjcGJpc0BpZXRmLm9yZzwvYT4mZ3Q7LCAmcXVvdDs8YSBocmVmPSJt YWlsdG86aWNlQGlldGYub3JnIiB0YXJnZXQ9Il9ibGFuayI+aWNlQGlldGYub3JnPC9hPiZxdW90 Ow0KICZsdDs8YSBocmVmPSJtYWlsdG86aWNlQGlldGYub3JnIiB0YXJnZXQ9Il9ibGFuayI+aWNl QGlldGYub3JnPC9hPiZndDssICZxdW90OzxhIGhyZWY9Im1haWx0bzptbXVzaWNAaWV0Zi5vcmci IHRhcmdldD0iX2JsYW5rIj5tbXVzaWNAaWV0Zi5vcmc8L2E+JnF1b3Q7ICZsdDs8YSBocmVmPSJt YWlsdG86bW11c2ljQGlldGYub3JnIiB0YXJnZXQ9Il9ibGFuayI+bW11c2ljQGlldGYub3JnPC9h PiZndDssIENocmlzdGVyIEhvbG1iZXJnICZsdDs8YSBocmVmPSJtYWlsdG86Y2hyaXN0ZXIuaG9s bWJlcmdAZXJpY3Nzb24uY29tIiB0YXJnZXQ9Il9ibGFuayI+Y2hyaXN0ZXIuaG9sbWJlcmdAZXJp Y3Nzb24uY29tPC9hPiZndDs8YnI+DQo8Yj5TdWJqZWN0OiA8L2I+UmU6IFtiZmNwYmlzXSBbTU1V U0lDXSBtPSBsaW5lIHByb3RvY29sIGluIGNhc2Ugb2YgSUNFPC9zcGFuPjxvOnA+PC9vOnA+PC9w Pg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4t dG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj4mbmJzcDs8bzpwPjwvbzpw PjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29O b3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1h bHQ6YXV0byI+T24gVHVlLCBOb3YgMjksIDIwMTYgYXQgMTI6NDggUE0sIENoYXJsZXMgRWNrZWwg KGVja2VsY3UpICZsdDs8YSBocmVmPSJtYWlsdG86ZWNrZWxjdUBjaXNjby5jb20iIHRhcmdldD0i X2JsYW5rIj5lY2tlbGN1QGNpc2NvLmNvbTwvYT4mZ3Q7IHdyb3RlOjxvOnA+PC9vOnA+PC9wPg0K PC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj4NCjxibG9ja3F1b3RlIHN0eWxlPSJi b3JkZXI6bm9uZTtib3JkZXItbGVmdDpzb2xpZCAjQ0NDQ0NDIDEuMHB0O3BhZGRpbmc6MGluIDBp biAwaW4gNi4wcHQ7bWFyZ2luLWxlZnQ6NC44cHQ7bWFyZ2luLXRvcDo1LjBwdDttYXJnaW4tcmln aHQ6MGluO21hcmdpbi1ib3R0b206NS4wcHQiPg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20t YWx0OmF1dG8iPkl0IHNlZW1zIHRvIG1lIHRoYXQgdGhlIG1vc3Qgc3RyYWlnaHRmb3J3YXJkIGFw cHJvYWNoIHdvdWxkIGJlIHRvIG1hbmRhdGUgc3VwcG9ydCBmb3IgQkZDUCBvdmVyIFVEUCB3aGVu IHVzaW5nIElDRSwgdXNlIFVEUCBhcyB0aGUgZGVmYXVsdCBjYW5kaWRhdGUsIGFuZCBzaWduYWwg dGhlIEJGQ1AgbS1saW5lDQogYXMgaWYgaXQgaXMgQkZDUCBvdmVyIFVEUC4gSWYgd2UgY2FuIG1h bmRhdGUgdGhlIHVzZSBvZiBEVExTLCB0aGF0IHdvdWxkIGJlIGV2ZW4gYmV0dGVyLjxvOnA+PC9v OnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDph dXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj5UaG91Z2h0cz88bzpwPjwvbzpwPjwvcD4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28t bWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwv ZGl2Pg0KPC9ibG9ja3F1b3RlPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJt c28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+Jm5ic3A7 PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHls ZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPkkg YWdyZWUuPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFs IiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1 dG8iPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05v cm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFs dDphdXRvIj5UaGUgb25seSBpc3N1ZSB0aGF0IEkgc3RpbGwgaGF2ZSwgaWYgRFRMUyBpcyBub3Qg dXNlZCwgd2hhdCBwcm90b2NvbCBpcyB1c2VkIHdoZW4gSUNFIHRjcCBjYW5kaWRhdGUgaXMmbmJz cDtzZWxlY3RlZCBmb3IgdHJhbnNwb3J0LiBJcyB0aGlzIFRDUC9CRkNQICh3aGljaCBnb2VzIGFn YWluc3QgUkZDNjU0NCkgJm5ic3A7b3INCiBpcyBpdCBVRFAvQkZDUCB3aXRoIFJGQzQ1NzEgZnJh bWluZz8gSWYgaXQgaXMgVURQL0JGQ1Agd2l0aCBSRkM0NTcxIGZyYW1pbmcsIHdoYXQgdHJhbnNw b3J0IHRhZyBzaG91bGQgYmUgdXNlZCBpbiB0aGUgcmUtSU5WSVRFIHdoaWNoIGlzIHNlbnQgYWZ0 ZXIgSUNFIG5vbWluYXRpb24gd2l0aCBvbmx5IHNlbGVjdGVkIGNhbmRpZGF0ZT8gU2hvdWxkIGl0 IGJlIFRDUC9VRFAvQkZDUCBvciBzb21ldGhpbmcgc2ltaWxhcj88bzpwPjwvbzpwPjwvcD4NCjwv ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1h bHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+Jm5ic3A7PG86cD48L286cD48L3A+ DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10 b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPlJlZ2FyZHMsPG86cD48L286 cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9 Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj5fX19f X19fX19fX19fPGJyPg0KUm9tYW4gU2hwb3VudDxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rp dj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0 OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0K PC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9ibG9ja3F1 b3RlPg0KPC9kaXY+DQo8L2Rpdj4NCjwvYmxvY2txdW90ZT4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvYmxvY2txdW90ZT4NCjwv YmxvY2txdW90ZT4NCjwvZGl2Pg0KPC9ib2R5Pg0KPC9odG1sPg0K --_000_633D349183B1421FB48C0A61B1314E99ciscocom_-- From nobody Tue Jan 3 12:08:11 2017 Return-Path: X-Original-To: ice@ietfa.amsl.com Delivered-To: ice@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9D8DC129B68 for ; Tue, 3 Jan 2017 12:08:09 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.099 X-Spam-Level: X-Spam-Status: No, score=-2.099 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_SORBS_SPAM=0.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=telurix-com.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UQutXNnIcbxo for ; Tue, 3 Jan 2017 12:08:07 -0800 (PST) Received: from mail-qk0-x235.google.com (mail-qk0-x235.google.com [IPv6:2607:f8b0:400d:c09::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 3393C129B77 for ; Tue, 3 Jan 2017 12:08:07 -0800 (PST) Received: by mail-qk0-x235.google.com with SMTP id n21so380867158qka.3 for ; Tue, 03 Jan 2017 12:08:07 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=telurix-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=7y3H8XNkvR1aeMz8bkAx3Ee0MwlRaiQOFINbX/t73r8=; b=LmqFjgGnJpEAT8293nLy+iZwrWMh6/9AtnJ3EJzHJ/CEpEA7F73DgS6q1ac1enCr9J d/omcMmi6YnB9Y6A/qRtFRIuzO8ZPbW9E48imMy/H5aMFqGcP/e+b3Pl2l0Ps3HAb8Su ONbKOomO6rn211o/OWEReNUkoeE42tVcIBdEFGEeGYGKF82lddUGcyVi0pQmxosKAD45 HOZ45Bs4HShG1QfFxHffGDqtAKqpJJ8JHcuWJglY2AO69SOjOVTUZd/5J+K3sbiEF/RN LrXYbIQyqfWSYYKaoOhiw3J2k+v3n8Bk7DgUJ0ZgqCRt7e9dW+QiQJq5i2Xu9sHEccyf PyTg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=7y3H8XNkvR1aeMz8bkAx3Ee0MwlRaiQOFINbX/t73r8=; b=dir8sqc0dsBKxhWsR9/nADwMT9O2BdHoehgKCne7FauSD44W9te4Bx7akrxN+z5FeL VKynGVyMU9n4dEwoWIbZYAjsDP9YgN2aAOmoUTMKwK5UTr7RlW+wcP3HrXlvyUTusRwT dDpwSXrijdUkWfw6AldiZ1FjuYXV2FwdTKd0Gx+bQNeOUfwgePgTJ68JhfQE75SOFd8W toAlQVa8EDOdBFyMGN5zprzqhemZY4aRCXOTluSTXU4NR2oJAe2AdOxdKiFiQs68T73I TR6LF1XgI+FsqlqbRsZNnKPH4qecPAm3p59JkFFRi7zL375+D+YyN+6wh4ahsyFGuSpg JZSQ== X-Gm-Message-State: AIkVDXJi563pHPye0tOU6RaCd022ADW9B6lDWWvC+QbtvFhWpKB242735CgJdZddweguUw== X-Received: by 10.55.185.133 with SMTP id j127mr59738566qkf.39.1483474086212; Tue, 03 Jan 2017 12:08:06 -0800 (PST) Received: from mail-qt0-f169.google.com (mail-qt0-f169.google.com. [209.85.216.169]) by smtp.gmail.com with ESMTPSA id k143sm17289079qke.37.2017.01.03.12.08.05 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 03 Jan 2017 12:08:05 -0800 (PST) Received: by mail-qt0-f169.google.com with SMTP id k15so233896116qtg.3; Tue, 03 Jan 2017 12:08:05 -0800 (PST) X-Received: by 10.200.45.144 with SMTP id p16mr589450qta.141.1483474085308; Tue, 03 Jan 2017 12:08:05 -0800 (PST) MIME-Version: 1.0 Received: by 10.12.136.230 with HTTP; Tue, 3 Jan 2017 12:08:04 -0800 (PST) In-Reply-To: <633D3491-83B1-421F-B48C-0A61B1314E99@cisco.com> References: <7594FB04B1934943A5C02806D1A2204B4BE3AE83@ESESSMB209.ericsson.se> <16B5D8FF-F132-4B09-84D6-AE964CA7858D@cisco.com> <64E8A5CF-89ED-4673-AF23-2C960395C3EF@cisco.com> <633D3491-83B1-421F-B48C-0A61B1314E99@cisco.com> From: Roman Shpount Date: Tue, 3 Jan 2017 15:08:04 -0500 X-Gmail-Original-Message-ID: Message-ID: To: "Charles Eckel (eckelcu)" Content-Type: multipart/alternative; boundary=001a1140396ce390540545363931 Archived-At: Cc: "bfcpbis@ietf.org" , Christer Holmberg , "mmusic@ietf.org" , "ice@ietf.org" Subject: Re: [Ice] [MMUSIC] [bfcpbis] m= line protocol in case of ICE X-BeenThere: ice@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Interactive Connectivity Establishment \(ICE\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 Jan 2017 20:08:09 -0000 --001a1140396ce390540545363931 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Charles, I do not think not supporting ICE tcp candidates will quite work since it will reduce the usability considerably. The simplest way to move forward is to define a different transport tag for BFCP with RFC 4571 over TCP not to confuse it with TCP/BFCP. It can be TCP/UDP/BFCP (I know this looks strange and I am open to other suggestions, such as calling all packet based protocols DBFCP). In general what I am proposing is: TCP/BFCP -- existing BFCP over TCP TLS/BFCP -- exisitng BFCP over TLS UDP/BFCP -- BFCP over UDP or ICE udp candidates TCP/UDP/BFCP -- BFCP with RFC 4571 framing over TCP or over ICE tcp candidates UDP/DTLS/BFCP -- BFCP over DTLS or over ICE udp candidates TCP/DTLS/BFCP -- BFCP over DTLS with RFC 4571 framing over TCP or over ICE tcp candidates Legacy BFCP over TCP or TLS cannot work with ICE or NAT. Other protocols can work with NAT or ICE using normal ICE procedures. If we call all packet based protocols DBFCP then transport tags will be: TCP/BFCP -- existing BFCP over TCP TLS/BFCP -- exisitng BFCP over TLS UDP/DBFCP -- DBFCP over UDP or ICE udp candidates TCP/DBFCP -- DBFCP with RFC 4571 framing over TCP or over ICE tcp candidate= s UDP/DTLS/DBFCP -- DBFCP over DTLS or over ICE udp candidates TCP/DTLS/DBFCP -- DBFCP over DTLS with RFC 4571 framing over TCP or over ICE tcp candidates Since BFCP over UDP (or other packet based protocols) is quite different due to timers and transmission restrictions, it can have a different transport tag and even be defined in a separate RFC. Regards, _____________ Roman Shpount On Tue, Jan 3, 2017 at 2:43 PM, Charles Eckel (eckelcu) wrote: > Crickets=E2=80=A6 > > If no one is or has plans for using ICE with TCP/BFCP, perhaps it is best > to state that as of this rev of the BFCP spec, BFCP with TCP candidates i= s > not defined. Future updates to the spec may define this usage. > > > > Cheers, > > Charles > > > > *From: *mmusic on behalf of Charles Eckel < > eckelcu@cisco.com> > *Date: *Friday, December 2, 2016 at 4:01 PM > *To: *Roman Shpount > *Cc: *"ice@ietf.org" , "bfcpbis@ietf.org" , > Christer Holmberg , "mmusic@ietf.org" < > mmusic@ietf.org> > *Subject: *Re: [MMUSIC] [bfcpbis] m=3D line protocol in case of ICE > > > > I have no experience with ICE with TCP candidates so hopefully others can > chime in as to what they think is a workable solution. > > > > Cheers, > > Charles > > > > *From: *Roman Shpount > *Date: *Thursday, December 1, 2016 at 12:34 PM > *To: *Charles Eckel > *Cc: *Alan Ford , "bfcpbis@ietf.org" < > bfcpbis@ietf.org>, "ice@ietf.org" , "mmusic@ietf.org" < > mmusic@ietf.org>, Christer Holmberg > *Subject: *Re: [bfcpbis] [MMUSIC] m=3D line protocol in case of ICE > > > > Charles, > > > > RFC 6544 Sending Media (https://tools.ietf.org/html/rfc6544#section-10.1)= says > that "The framing defined in RFC 4571 > MUST be used when sending media." > This means the protocol used is not TCP/BFCP which is using application > level framing. I believe that STUN/Media demultiplexing requirements woul= d > prevent using TCP/BFCP directly with ice tcp candidates without redesign = of > either ICE TCP or TCP/BFCP. > > > > Furthermore there are other implied ICE requirements that I outlined > before (switching between udp and tpc candidates, existence of SBC which > terminate ICE only but do not support the embedded protocol) because of > which ice tcp is considered unreliable transport and will require > fragmentation support and re-transmit timers that are not part of TCP/BFC= P. > > > > Regards, > > > _____________ > Roman Shpount > > > > On Thu, Dec 1, 2016 at 3:17 PM, Charles Eckel (eckelcu) > wrote: > > Roman, > > > > Why would selecting TCP/BFCP as transport violate RFC 6544? Perhaps it > does, but after a quick scan I am not sure why. > > > > Cheers, > > Charles > > > > *From: *Roman Shpount > *Date: *Tuesday, November 29, 2016 at 10:38 AM > *To: *Charles Eckel > *Cc: *Alan Ford , "bfcpbis@ietf.org" < > bfcpbis@ietf.org>, "ice@ietf.org" , "mmusic@ietf.org" < > mmusic@ietf.org>, Christer Holmberg > *Subject: *Re: [bfcpbis] [MMUSIC] m=3D line protocol in case of ICE > > > > On Tue, Nov 29, 2016 at 12:48 PM, Charles Eckel (eckelcu) < > eckelcu@cisco.com> wrote: > > It seems to me that the most straightforward approach would be to mandate > support for BFCP over UDP when using ICE, use UDP as the default candidat= e, > and signal the BFCP m-line as if it is BFCP over UDP. If we can mandate t= he > use of DTLS, that would be even better. > > Thoughts? > > > > > > I agree. > > > > The only issue that I still have, if DTLS is not used, what protocol is > used when ICE tcp candidate is selected for transport. Is this TCP/BFCP > (which goes against RFC6544) or is it UDP/BFCP with RFC4571 framing? If = it > is UDP/BFCP with RFC4571 framing, what transport tag should be used in th= e > re-INVITE which is sent after ICE nomination with only selected candidate= ? > Should it be TCP/UDP/BFCP or something similar? > > > > Regards, > > _____________ > Roman Shpount > > > > > > --001a1140396ce390540545363931 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Charles,

I do not think not supporting = ICE tcp candidates will quite work since it will reduce the usability consi= derably. The simplest way to move forward is to define a different transpor= t tag for BFCP =C2=A0with RFC 4571 over TCP not to confuse it with TCP/BFCP= . It can be TCP/UDP/BFCP (I know this looks strange and I am open to other = suggestions, such as calling all packet based protocols DBFCP).=C2=A0
=

In general what I am proposing is:

=
TCP/BFCP -- existing BFCP over TCP
TLS/BFCP -- exisitng BFCP= over TLS
UDP/BFCP -- BFCP over UDP or ICE udp candidates
TCP/UDP/BFCP -- BFCP with RFC 4571 framing=C2=A0over TCP or over ICE tcp= candidates
UDP/DTLS/BFCP -- BFCP over DTLS or over ICE udp c= andidates
TCP/DTLS/BFCP -- BFCP over DTLS with RFC 4571 framing= =C2=A0over TCP or over ICE tcp candidates

Legacy B= FCP over TCP or TLS cannot work with ICE or NAT. Other protocols can work w= ith NAT or ICE using normal ICE procedures.

If we = call all packet based protocols DBFCP then transport tags will be:

TCP/BFCP -- existing BFCP over TCP
TLS/BFCP= -- exisitng BFCP over TLS
UDP/DBFCP -- DBFCP over UDP or ICE udp= candidates
TCP/DBFCP -- DBFCP with RFC 4571 framing=C2=A0over TC= P or over ICE tcp candidates
UDP/DTLS/DBFCP -- DBFCP over DTL= S or over ICE udp candidates
TCP/DTLS/DBFCP -- DBFCP over DTLS wi= th RFC 4571 framing=C2=A0over TCP or over ICE tcp candidates

=
Since BFCP over UDP (or other packet based protocols) is q= uite different due to timers and transmission restrictions, it can have a d= ifferent transport tag and even be defined in a separate RFC.
Regards,

__= ___________
Roman Shpount

On Tue, Jan 3, 2017 at 2:43 PM, Charles Ecke= l (eckelcu) <eckelcu@cisco.com> wrote:

Crickets=E2=80=A6

If no one is or has plans for using ICE with TCP/BFC= P, perhaps it is best to state that as of this rev of the BFCP spec, BFCP w= ith TCP candidates is not defined. Future updates to the spec may define th= is usage.

=C2=A0

Cheers,

Charles

=C2=A0

F= rom: mmusic <mmusic-bounces@ietf.org> on behalf of Charles Eckel <eckelcu@cisco.com>
Date: Friday, December 2, 2016 at 4:01 PM
To: Roman Shpount <roman@telurix.com>
Cc: "ice@ietf= .org" <ice@ie= tf.org>, "bfcpbis@ietf.org" <bfcpbis@ietf.org>, Christer Holmberg <christer.holmberg@eric= sson.com>, "mmusic@ietf.org" <mmusic@ietf.org>
Subject: Re: [MMUSIC] [bfcpbis] m=3D line protocol in case of ICE=

=C2=A0

I have no experience with ICE with TCP candidates so= hopefully others can chime in as to what they think is a workable solution= .

=C2=A0

Cheers,

Charles

=C2=A0

F= rom: Roman Shpount <roman@telurix.com>=
Date: Thursday, December 1, 2016 at 12:34 PM
To: Charles Eckel <eckelcu@cisco.com>
Cc: Alan Ford <alan.ford@gmail.com>, "bfcpbis@ietf.org" <bfcpbis@ietf.org>, "ice@ietf.org" <ice@ietf.org>, "mmusic@ietf.org" <= ;mmusic@ietf.org&g= t;, Christer Holmberg <christer.holmberg@ericsson.com>
Subject: Re: [bfcpbis] [MMUSIC] m=3D line protocol in case of ICE

=C2=A0

Charles,

=C2=A0

RFC 6544 Sending Media (https://tools.ietf.org/h= tml/rfc6544#section-10.1)=C2=A0says that "The framing defined in RFC 4571 MUST be used when sending media." This means the = protocol used is not TCP/BFCP which is using application level framing. I believe that STUN/Media demultiplexing requirements would preve= nt using TCP/BFCP directly with ice tcp candidates without redesign of eith= er ICE TCP or TCP/BFCP.

=C2=A0

Further= more=C2=A0there are other implied ICE requirements that I outlined before (= switching between udp and tpc candidates, existence of SBC which terminate = ICE only but do not support the embedded protocol) because of which ice tcp is considered unreliable transport and = will require fragmentation support and re-transmit timers that are not part= of TCP/BFCP.

=C2=A0

Regards= ,


_____________
Roman Shpount

=C2=A0

On Thu, Dec 1, 2016 at 3:17 PM, Charles Eckel (eckel= cu) <eckelcu@cisc= o.com> wrote:

Roman,

=C2=A0

Why would selecting TCP/BFCP as transport violate RF= C 6544? Perhaps it does, but after a quick scan I am not sure why.

=C2=A0

Cheers,

Charles

=C2=A0

F= rom: Roman Shpount &l= t;roman@telurix.com<= /a>>
Date: Tuesday, November 29, 2016 at 10:38 AM
To: Charles Eckel <eckelcu@cisco.com>
Cc: Alan Ford <alan.ford@gmail.com>, "bfcpbis@ietf.org" <bfcpbis@ietf.org>, "ice@ietf.org" <ice@ietf.org>= , "mmusic@ietf.or= g" <mmusic= @ietf.org>, Christer Holmberg <christer.holmberg@ericsson.com&g= t;
Subject: Re: [bfcpbis] [MMUSIC] m=3D line protocol in case of ICE

=C2=A0

On Tue, Nov 29, 2016 at 12:48 PM, Charles Eckel (eck= elcu) <eckelcu@ci= sco.com> wrote:

It seems to me that the most straightforward approac= h would be to mandate support for BFCP over UDP when using ICE, use UDP as = the default candidate, and signal the BFCP m-line as if it is BFCP over UDP. If we can mandate the use of DTLS, that would b= e even better.

Thoughts?

=C2=A0

=C2=A0

I agree.

=C2=A0

The only issue that I still have, if DTLS is not use= d, what protocol is used when ICE tcp candidate is=C2=A0selected for transp= ort. Is this TCP/BFCP (which goes against RFC6544) =C2=A0or is it UDP/BFCP with RFC4571 framing? If it is UDP/BFCP with RFC4571 framin= g, what transport tag should be used in the re-INVITE which is sent after I= CE nomination with only selected candidate? Should it be TCP/UDP/BFCP or so= mething similar?

=C2=A0

Regards,

_____________
Roman Shpount

=C2=A0

=C2=A0


--001a1140396ce390540545363931-- From nobody Tue Jan 3 15:23:57 2017 Return-Path: X-Original-To: ice@ietfa.amsl.com Delivered-To: ice@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6505C1296D2; Tue, 3 Jan 2017 15:23:42 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id e1W2VjBQ6l5K; Tue, 3 Jan 2017 15:23:39 -0800 (PST) Received: from mail-wm0-x242.google.com (mail-wm0-x242.google.com [IPv6:2a00:1450:400c:c09::242]) (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 1AD26129489; Tue, 3 Jan 2017 15:23:39 -0800 (PST) Received: by mail-wm0-x242.google.com with SMTP id c85so50636396wmi.1; Tue, 03 Jan 2017 15:23:39 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:subject:from:in-reply-to:date:cc:message-id:references :to; bh=AkHARHZY+XfXLQV3sHh78JQyhU1tfmZeiNhVSbXkLnc=; b=R8b7nx3h9sjcj8vW/+hkDlOT6Q+PMl5eew0oKWnCYFX2X62ZpULrNBXW70XYsT6En8 rLTbhkWDo05p4yKyJWMlyTm8svY8B05hipzFtfEqYiXt5+EHihhxB1dyAAPKYqKqS5cR araqhUnU/xO6Ik91bgCr0Ck0D2i6O1j8fW/QNhlGebIIjmgUQfrM72cbtrVcN4Y6donc /ZqHAx1grpnNnRCfwEOrXPvUyZkmbtCf1tQHVeV5chswBqjrJcR+jOlZg8Y9H3FaktOP YCJaJd9J2GQwYJlmSqkqWfnx62VENZE6OH2Acvm6+Jlo1NHP3vkfRhB9Wp9AKNFvtvvb T22g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :message-id:references:to; bh=AkHARHZY+XfXLQV3sHh78JQyhU1tfmZeiNhVSbXkLnc=; b=ggq2jWtHqeJQ55QzYpK50DCWqzYlh/Pg1VR14VXR3kS3LmS5fRgeL2QUxItuSjSWVp q//nyHJCtWBvDfogYSyraleCAifzEd/LlmMUCSHnboZsv24skVONxb32ldL5gW0BYU9I HC74Sz+x4wmTCDGbMl0DuJopN4UiSrfQw2SkQdnxC3wnrHcQ5dD/zsBj3RC4kkTISXyu Pszt7KcGI8Etby0x3ZFiqmKVq4u8uKKWeycXxJqDir5upXF3gxduakZJi9sFSqjpBGA7 EsyGQA7cEhcXCdkl49YxSmSA09nN41buyBzjVEHU8zjOXZEN90ouvqKvsy1i249vdYEX ek/A== X-Gm-Message-State: AIkVDXJfyrrdfWKKoy8TJtjJcId+3xOi7iuPB6xM8FZfMVosOEX15KFpfvNY2nuPe43tGw== X-Received: by 10.28.9.80 with SMTP id 77mr56746324wmj.68.1483485817526; Tue, 03 Jan 2017 15:23:37 -0800 (PST) Received: from alans-mbp.lan ([37.152.254.113]) by smtp.gmail.com with ESMTPSA id u78sm91845081wma.11.2017.01.03.15.23.36 (version=TLS1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Tue, 03 Jan 2017 15:23:36 -0800 (PST) Content-Type: multipart/alternative; boundary="Apple-Mail=_08AEB35B-C7EA-4835-939D-0F9C88F9998B" Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) From: Alan Ford In-Reply-To: Date: Tue, 3 Jan 2017 23:23:35 +0000 Message-Id: <739486DE-BDFA-48FD-ACBA-41E45D208748@gmail.com> References: <7594FB04B1934943A5C02806D1A2204B4BE3AE83@ESESSMB209.ericsson.se> <16B5D8FF-F132-4B09-84D6-AE964CA7858D@cisco.com> <64E8A5CF-89ED-4673-AF23-2C960395C3EF@cisco.com> <633D3491-83B1-421F-B48C-0A61B1314E99@cisco.com> To: Roman Shpount X-Mailer: Apple Mail (2.3124) Archived-At: Cc: "ice@ietf.org" , "mmusic@ietf.org" , "bfcpbis@ietf.org" , "Charles Eckel \(eckelcu\)" , Christer Holmberg Subject: Re: [Ice] [bfcpbis] [MMUSIC] m= line protocol in case of ICE X-BeenThere: ice@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Interactive Connectivity Establishment \(ICE\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 Jan 2017 23:23:42 -0000 --Apple-Mail=_08AEB35B-C7EA-4835-939D-0F9C88F9998B Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Roman, Do any of those work for having both tcp and udp ICE candidates? I = assume any with ICE (+ 4571 framing) would be acceptable for that case? Ideally we need to support the case where an answer=E2=80=99s m-line = protocol does not match any of the candidates, so that an answer could = only support TCP (say) when the offerer supported both (and used a UDP = m-line protocol). If Christer=E2=80=99s proposed change which permitted = an answer not to match the m-line protocol in the ICE candidates was = accepted, that would resolve this case. Do you see any problems here? Regards, Alan > On 3 Jan 2017, at 20:08, Roman Shpount wrote: >=20 > Charles, >=20 > I do not think not supporting ICE tcp candidates will quite work since = it will reduce the usability considerably. The simplest way to move = forward is to define a different transport tag for BFCP with RFC 4571 = over TCP not to confuse it with TCP/BFCP. It can be TCP/UDP/BFCP (I know = this looks strange and I am open to other suggestions, such as calling = all packet based protocols DBFCP).=20 >=20 > In general what I am proposing is: >=20 > TCP/BFCP -- existing BFCP over TCP > TLS/BFCP -- exisitng BFCP over TLS > UDP/BFCP -- BFCP over UDP or ICE udp candidates > TCP/UDP/BFCP -- BFCP with RFC 4571 framing over TCP or over ICE tcp = candidates > UDP/DTLS/BFCP -- BFCP over DTLS or over ICE udp candidates > TCP/DTLS/BFCP -- BFCP over DTLS with RFC 4571 framing over TCP or over = ICE tcp candidates >=20 > Legacy BFCP over TCP or TLS cannot work with ICE or NAT. Other = protocols can work with NAT or ICE using normal ICE procedures. >=20 > If we call all packet based protocols DBFCP then transport tags will = be: >=20 > TCP/BFCP -- existing BFCP over TCP > TLS/BFCP -- exisitng BFCP over TLS > UDP/DBFCP -- DBFCP over UDP or ICE udp candidates > TCP/DBFCP -- DBFCP with RFC 4571 framing over TCP or over ICE tcp = candidates > UDP/DTLS/DBFCP -- DBFCP over DTLS or over ICE udp candidates > TCP/DTLS/DBFCP -- DBFCP over DTLS with RFC 4571 framing over TCP or = over ICE tcp candidates >=20 > Since BFCP over UDP (or other packet based protocols) is quite = different due to timers and transmission restrictions, it can have a = different transport tag and even be defined in a separate RFC. >=20 > Regards, >=20 > _____________ > Roman Shpount >=20 > On Tue, Jan 3, 2017 at 2:43 PM, Charles Eckel (eckelcu) = > wrote: > Crickets=E2=80=A6 >=20 > If no one is or has plans for using ICE with TCP/BFCP, perhaps it is = best to state that as of this rev of the BFCP spec, BFCP with TCP = candidates is not defined. Future updates to the spec may define this = usage. >=20 > =20 >=20 > Cheers, >=20 > Charles >=20 > =20 >=20 > From: mmusic > on behalf of Charles Eckel = > > Date: Friday, December 2, 2016 at 4:01 PM > To: Roman Shpount > > Cc: "ice@ietf.org " >, "bfcpbis@ietf.org " = >, Christer Holmberg = >, "mmusic@ietf.org = " > > Subject: Re: [MMUSIC] [bfcpbis] m=3D line protocol in case of ICE >=20 > =20 >=20 > I have no experience with ICE with TCP candidates so hopefully others = can chime in as to what they think is a workable solution. >=20 > =20 >=20 > Cheers, >=20 > Charles >=20 > =20 >=20 > From: Roman Shpount > > Date: Thursday, December 1, 2016 at 12:34 PM > To: Charles Eckel > > Cc: Alan Ford >, = "bfcpbis@ietf.org " >, "ice@ietf.org " = >, "mmusic@ietf.org = " >, = Christer Holmberg > > Subject: Re: [bfcpbis] [MMUSIC] m=3D line protocol in case of ICE >=20 > =20 >=20 > Charles, >=20 > =20 >=20 > RFC 6544 Sending Media = (https://tools.ietf.org/html/rfc6544#section-10.1 = ) says that "The = framing defined in RFC 4571 MUST = be used when sending media." This means the protocol used is not = TCP/BFCP which is using application level framing. I believe that = STUN/Media demultiplexing requirements would prevent using TCP/BFCP = directly with ice tcp candidates without redesign of either ICE TCP or = TCP/BFCP. >=20 > =20 >=20 > Furthermore there are other implied ICE requirements that I outlined = before (switching between udp and tpc candidates, existence of SBC which = terminate ICE only but do not support the embedded protocol) because of = which ice tcp is considered unreliable transport and will require = fragmentation support and re-transmit timers that are not part of = TCP/BFCP. >=20 > =20 >=20 > Regards, >=20 >=20 >=20 > _____________ > Roman Shpount >=20 > =20 >=20 > On Thu, Dec 1, 2016 at 3:17 PM, Charles Eckel (eckelcu) = > wrote: >=20 > Roman, >=20 > =20 >=20 > Why would selecting TCP/BFCP as transport violate RFC 6544? Perhaps it = does, but after a quick scan I am not sure why. >=20 > =20 >=20 > Cheers, >=20 > Charles >=20 > =20 >=20 > From: Roman Shpount > > Date: Tuesday, November 29, 2016 at 10:38 AM > To: Charles Eckel > > Cc: Alan Ford >, = "bfcpbis@ietf.org " >, "ice@ietf.org " = >, "mmusic@ietf.org = " >, = Christer Holmberg > > Subject: Re: [bfcpbis] [MMUSIC] m=3D line protocol in case of ICE >=20 > =20 >=20 > On Tue, Nov 29, 2016 at 12:48 PM, Charles Eckel (eckelcu) = > wrote: >=20 > It seems to me that the most straightforward approach would be to = mandate support for BFCP over UDP when using ICE, use UDP as the default = candidate, and signal the BFCP m-line as if it is BFCP over UDP. If we = can mandate the use of DTLS, that would be even better. >=20 > Thoughts? >=20 > =20 >=20 > =20 >=20 > I agree. >=20 > =20 >=20 > The only issue that I still have, if DTLS is not used, what protocol = is used when ICE tcp candidate is selected for transport. Is this = TCP/BFCP (which goes against RFC6544) or is it UDP/BFCP with RFC4571 = framing? If it is UDP/BFCP with RFC4571 framing, what transport tag = should be used in the re-INVITE which is sent after ICE nomination with = only selected candidate? Should it be TCP/UDP/BFCP or something similar? >=20 > =20 >=20 > Regards, >=20 > _____________ > Roman Shpount >=20 > =20 >=20 > =20 >=20 >=20 > _______________________________________________ > bfcpbis mailing list > bfcpbis@ietf.org > https://www.ietf.org/mailman/listinfo/bfcpbis --Apple-Mail=_08AEB35B-C7EA-4835-939D-0F9C88F9998B Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 Roman,

Do = any of those work for having both tcp and udp ICE candidates? I assume = any with ICE (+ 4571 framing) would be acceptable for that = case?

Ideally = we need to support the case where an answer=E2=80=99s m-line protocol = does not match any of the candidates, so that an answer could only = support TCP (say) when the offerer supported both (and used a UDP m-line = protocol). If Christer=E2=80=99s proposed change which permitted an = answer not to match the m-line protocol in the ICE candidates was = accepted, that would resolve this case. Do you see any problems = here?

Regards,
Alan

On = 3 Jan 2017, at 20:08, Roman Shpount <roman@telurix.com> = wrote:

Charles,

I do not think not supporting ICE tcp candidates will quite = work since it will reduce the usability considerably. The simplest way = to move forward is to define a different transport tag for BFCP =  with RFC 4571 over TCP not to confuse it with TCP/BFCP. It can be = TCP/UDP/BFCP (I know this looks strange and I am open to other = suggestions, such as calling all packet based protocols = DBFCP). 

In= general what I am proposing is:

TCP/BFCP -- existing BFCP over = TCP
TLS/BFCP -- exisitng BFCP over TLS
UDP/BFCP -- BFCP over UDP or ICE udp candidates
TCP/UDP/BFCP -- BFCP with RFC 4571 framing over TCP or = over ICE tcp candidates
UDP/DTLS/BFCP = -- BFCP over DTLS or over ICE udp candidates
TCP/DTLS/BFCP -- BFCP over DTLS with RFC 4571 = framing over TCP or over ICE tcp candidates

Legacy BFCP over TCP or TLS cannot work = with ICE or NAT. Other protocols can work with NAT or ICE using normal = ICE procedures.

If we call all packet based protocols DBFCP then transport = tags will be:

TCP/BFCP -- existing BFCP over TCP
TLS/BFCP -- exisitng BFCP over TLS
UDP/DBFCP -- DBFCP over UDP or ICE udp candidates
TCP/DBFCP -- DBFCP with RFC 4571 framing over TCP or = over ICE tcp candidates
UDP/DTLS/DBFCP= -- DBFCP over DTLS or over ICE udp candidates
TCP/DTLS/DBFCP -- DBFCP over DTLS with RFC 4571 = framing over TCP or over ICE tcp candidates

Since BFCP over UDP (or other = packet based protocols) is quite different due to timers and = transmission restrictions, it can have a different transport tag and = even be defined in a separate RFC.

Regards,

_____________
Roman = Shpount

On Tue, Jan 3, 2017 at 2:43 = PM, Charles Eckel (eckelcu) <eckelcu@cisco.com> wrote:

Crickets=E2=80=A6

If no one is or has plans for = using ICE with TCP/BFCP, perhaps it is best to state that as of this rev = of the BFCP spec, BFCP with TCP candidates is not defined. Future = updates to the spec may define this usage.

 

Cheers,

Charles

 

From: mmusic <mmusic-bounces@ietf.org> on behalf of Charles Eckel = <eckelcu@cisco.com>
Date: Friday, December 2, 2016 at 4:01 PM
= To: Roman Shpount <roman@telurix.com>
Cc: "ice@ietf.org" <ice@ietf.org>, "bfcpbis@ietf.org" <bfcpbis@ietf.org>, Christer Holmberg = <christer.holmberg@ericsson.com>, "mmusic@ietf.org" <mmusic@ietf.org>
Subject: Re: [MMUSIC] [bfcpbis] m=3D line protocol in = case of ICE

 

I have no experience with ICE with TCP = candidates so hopefully others can chime in as to what they think is a = workable solution.

 

Cheers,

Charles

 

From: Roman Shpount = <roman@telurix.com>
Date: Thursday, December 1, 2016 at 12:34 PM
To: Charles Eckel <eckelcu@cisco.com>
Cc: Alan Ford <alan.ford@gmail.com>, "bfcpbis@ietf.org" <bfcpbis@ietf.org>, "ice@ietf.org" <ice@ietf.org>, "mmusic@ietf.org" <mmusic@ietf.org>, Christer Holmberg = <christer.holmberg@ericsson.com>
Subject: Re: [bfcpbis] [MMUSIC] m=3D line protocol in = case of ICE

 

Charles,

 

RFC 6544 Sending Media (https://tools.ietf.org/html/rfc6544#section-10.1) says that "The framing defined in RFC = 4571 MUST be used = when sending media." This means the protocol used is not TCP/BFCP which = is using application level framing. I believe that STUN/Media demultiplexing requirements would = prevent using TCP/BFCP directly with ice tcp candidates without redesign = of either ICE TCP or TCP/BFCP.

 

Furthermore there are other implied ICE requirements = that I outlined before (switching between udp and tpc candidates, = existence of SBC which terminate ICE only but do not support the = embedded protocol) because of which ice tcp is considered unreliable transport = and will require fragmentation support and re-transmit timers that are = not part of TCP/BFCP.

 

Regards,


_____________
Roman Shpount

 

On Thu, Dec 1, 2016 at 3:17 PM, = Charles Eckel (eckelcu) <eckelcu@cisco.com> wrote:

Roman,

 

Why would selecting TCP/BFCP = as transport violate RFC 6544? Perhaps it does, but after a quick scan I = am not sure why.

 

Cheers,

Charles

 

From: Roman = Shpount <roman@telurix.com>
Date: Tuesday, November 29, 2016 at 10:38 AM
To: Charles Eckel <eckelcu@cisco.com>
Cc: Alan Ford <alan.ford@gmail.com>, "bfcpbis@ietf.org" <bfcpbis@ietf.org>, "ice@ietf.org" <ice@ietf.org>, "mmusic@ietf.org" <mmusic@ietf.org>, Christer Holmberg <christer.holmberg@ericsson.com>
Subject: Re: [bfcpbis] [MMUSIC] m=3D line protocol in = case of ICE

 

On Tue, Nov 29, 2016 at 12:48 PM, = Charles Eckel (eckelcu) <eckelcu@cisco.com> wrote:

It seems to me that the most = straightforward approach would be to mandate support for BFCP over UDP = when using ICE, use UDP as the default candidate, and signal the BFCP = m-line as if it is BFCP over UDP. If we can mandate the use of DTLS, that = would be even better.

Thoughts?

 

 

I agree.

 

The only issue that I still have, = if DTLS is not used, what protocol is used when ICE tcp candidate = is selected for transport. Is this TCP/BFCP (which goes against = RFC6544)  or is it UDP/BFCP with RFC4571 framing? If it is UDP/BFCP with RFC4571 = framing, what transport tag should be used in the re-INVITE which is = sent after ICE nomination with only selected candidate? Should it be = TCP/UDP/BFCP or something similar?

=

 

Regards,

_____________
Roman Shpount

 

 


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

= --Apple-Mail=_08AEB35B-C7EA-4835-939D-0F9C88F9998B-- From nobody Tue Jan 3 15:45:02 2017 Return-Path: X-Original-To: ice@ietfa.amsl.com Delivered-To: ice@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D6C5E1294CA for ; Tue, 3 Jan 2017 15:44:59 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.099 X-Spam-Level: X-Spam-Status: No, score=-2.099 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_SORBS_SPAM=0.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=telurix-com.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mXM16-Mc-j8z for ; Tue, 3 Jan 2017 15:44:57 -0800 (PST) Received: from mail-qk0-x235.google.com (mail-qk0-x235.google.com [IPv6:2607:f8b0:400d:c09::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 C1E4B12943C for ; Tue, 3 Jan 2017 15:44:56 -0800 (PST) Received: by mail-qk0-x235.google.com with SMTP id t184so391765939qkd.0 for ; Tue, 03 Jan 2017 15:44:56 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=telurix-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=Pu65gb48CRUseGZeKNMMzv6tCkKbSWV0Ws0de+ymHPo=; b=zGLQWuWu0mSpnnBjaDzrRoTOfcCKYUHR0QA3LtOCT2Mguswwdw7ZnOGyTm50pnTVPI o5VFN59gSOxeDD16TnB1X+/qj9nWTKc8wXvf5pmWEavUnAlmIJc7c/5WZNFwwl7J1HNl pcsPZ7m2OMfPD51G/jimxNFK1WF+YBSF0cRh1ZldZtvvpaUghQw038NK4nkzDOrWXH38 +uiB6OmZvA1olfaCq1AJzXNb49XcraYubUV4pbYc4J0vX5RgGDSc8u3xpI58kcTTEK1O pm2sgDN83w2QhDOM9jzHB1ACi1GQAzwIvj74oyIcddLeD+sN7StTDBQqoG6eSz3PYJdm 0eVQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=Pu65gb48CRUseGZeKNMMzv6tCkKbSWV0Ws0de+ymHPo=; b=q3XdGe1firulNh08P2pCGYeTxVDOH9GCZdAkPS4yQ8EGVlt22THyj0Xe0E8NrOlu5K BLorYaB1TyYHHAjRlGS8RyDdnNznSrAr3TL1aSdECeJPwGoHVuUuh1p3Ri2U4tww+H34 1ohml234/ltRtCo/QfVh7Qx+6bCgM3ipOthkCOv13BgAVM/C5BYrLvtJtgPhbT5mvnC7 iNge3H5O0STIECCntpMtKoAN9kZmyi8871SKDVo1SJJHqzdA91HshyoFNQDUKwqPDWmX /kSeR2g6wsJtth53ovqeasoiOtfao8CqoWgzasMcI7zxsH0/pbVEjSg9Z+Qg+jVUkgRC cIxw== X-Gm-Message-State: AIkVDXJDEHvm9LU08fXwAc+Z8Jvt0Nin7FsoFfawIN0XuU75ZYwmtnRKHfi+26TDKqbEJw== X-Received: by 10.55.110.69 with SMTP id j66mr70590785qkc.92.1483487095868; Tue, 03 Jan 2017 15:44:55 -0800 (PST) Received: from mail-qk0-f177.google.com (mail-qk0-f177.google.com. [209.85.220.177]) by smtp.gmail.com with ESMTPSA id h47sm44734971qtc.27.2017.01.03.15.44.55 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 03 Jan 2017 15:44:55 -0800 (PST) Received: by mail-qk0-f177.google.com with SMTP id t184so391765693qkd.0; Tue, 03 Jan 2017 15:44:55 -0800 (PST) X-Received: by 10.55.142.1 with SMTP id q1mr59800932qkd.225.1483487095063; Tue, 03 Jan 2017 15:44:55 -0800 (PST) MIME-Version: 1.0 Received: by 10.12.136.230 with HTTP; Tue, 3 Jan 2017 15:44:54 -0800 (PST) In-Reply-To: <739486DE-BDFA-48FD-ACBA-41E45D208748@gmail.com> References: <7594FB04B1934943A5C02806D1A2204B4BE3AE83@ESESSMB209.ericsson.se> <16B5D8FF-F132-4B09-84D6-AE964CA7858D@cisco.com> <64E8A5CF-89ED-4673-AF23-2C960395C3EF@cisco.com> <633D3491-83B1-421F-B48C-0A61B1314E99@cisco.com> <739486DE-BDFA-48FD-ACBA-41E45D208748@gmail.com> From: Roman Shpount Date: Tue, 3 Jan 2017 18:44:54 -0500 X-Gmail-Original-Message-ID: Message-ID: To: Alan Ford Content-Type: multipart/alternative; boundary=94eb2c0830de5493180545394135 Archived-At: Cc: "ice@ietf.org" , "mmusic@ietf.org" , "bfcpbis@ietf.org" , "Charles Eckel \(eckelcu\)" , Christer Holmberg Subject: Re: [Ice] [bfcpbis] [MMUSIC] m= line protocol in case of ICE X-BeenThere: ice@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Interactive Connectivity Establishment \(ICE\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 Jan 2017 23:45:00 -0000 --94eb2c0830de5493180545394135 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Alan, TCP/BFCP and TLS/BFCP will not work with ICE. Or, to be more precise, will not work without some specification changes either in ICE tcp or in BFCP. One pair of protocols which will work with ICE is UDP/DTLS/BFCP and TCP/DTLS/BFCP. It will support both tcp and udp candidates. I think this pair should be recommended since it provides encryption. Another pair that will work with ICE is UDP/BFCP and TCP/UDP/BFCP. It will also support tcp and udp candidates. It is not something I would use over public internet since it will transmit data in the clear text. Finally, I prefer that any end point which implement BFCP and supports ICE and DTLS, MUST support UDP/DTLS/BFCP and use it for default candidate. Any endpoint which implements BFCP and ICE, but does not support DTLS, MUST support UDP/BFCP and use it as a default candidate. Once the ICE candidate pair is selected, the transport matching the selected candidate pair should be used in the SDP. There is no practical need for the asymmetric transport tags. I think the whole thing is coming from the confusion that TCP/BFCP can be used with ICE tcp candidates. It cannot without some specification changes. Also, there is no reason to use TCP/DTLS/BFCP or TCP/UDP/BFCP, unless ICE is used. Because of this, there is no reason to use either of those transports for default candidate, since default candidate is selected for interop with end points not supporting ICE. Regards, _____________ Roman Shpount On Tue, Jan 3, 2017 at 6:23 PM, Alan Ford wrote: > Roman, > > Do any of those work for having both tcp and udp ICE candidates? I assume > any with ICE (+ 4571 framing) would be acceptable for that case? > > Ideally we need to support the case where an answer=E2=80=99s m-line prot= ocol does > not match any of the candidates, so that an answer could only support TCP > (say) when the offerer supported both (and used a UDP m-line protocol). I= f > Christer=E2=80=99s proposed change which permitted an answer not to match= the > m-line protocol in the ICE candidates was accepted, that would resolve th= is > case. Do you see any problems here? > > Regards, > Alan > > On 3 Jan 2017, at 20:08, Roman Shpount wrote: > > Charles, > > I do not think not supporting ICE tcp candidates will quite work since it > will reduce the usability considerably. The simplest way to move forward = is > to define a different transport tag for BFCP with RFC 4571 over TCP not = to > confuse it with TCP/BFCP. It can be TCP/UDP/BFCP (I know this looks stran= ge > and I am open to other suggestions, such as calling all packet based > protocols DBFCP). > > In general what I am proposing is: > > TCP/BFCP -- existing BFCP over TCP > TLS/BFCP -- exisitng BFCP over TLS > UDP/BFCP -- BFCP over UDP or ICE udp candidates > TCP/UDP/BFCP -- BFCP with RFC 4571 framing over TCP or over ICE tcp > candidates > UDP/DTLS/BFCP -- BFCP over DTLS or over ICE udp candidates > TCP/DTLS/BFCP -- BFCP over DTLS with RFC 4571 framing over TCP or over IC= E > tcp candidates > > Legacy BFCP over TCP or TLS cannot work with ICE or NAT. Other protocols > can work with NAT or ICE using normal ICE procedures. > > If we call all packet based protocols DBFCP then transport tags will be: > > TCP/BFCP -- existing BFCP over TCP > TLS/BFCP -- exisitng BFCP over TLS > UDP/DBFCP -- DBFCP over UDP or ICE udp candidates > TCP/DBFCP -- DBFCP with RFC 4571 framing over TCP or over ICE tcp > candidates > UDP/DTLS/DBFCP -- DBFCP over DTLS or over ICE udp candidates > TCP/DTLS/DBFCP -- DBFCP over DTLS with RFC 4571 framing over TCP or over > ICE tcp candidates > > Since BFCP over UDP (or other packet based protocols) is quite different > due to timers and transmission restrictions, it can have a different > transport tag and even be defined in a separate RFC. > > Regards, > > _____________ > Roman Shpount > > On Tue, Jan 3, 2017 at 2:43 PM, Charles Eckel (eckelcu) > wrote: > >> Crickets=E2=80=A6 >> >> If no one is or has plans for using ICE with TCP/BFCP, perhaps it is bes= t >> to state that as of this rev of the BFCP spec, BFCP with TCP candidates = is >> not defined. Future updates to the spec may define this usage. >> >> >> >> Cheers, >> >> Charles >> >> >> >> *From: *mmusic on behalf of Charles Eckel < >> eckelcu@cisco.com> >> *Date: *Friday, December 2, 2016 at 4:01 PM >> *To: *Roman Shpount >> *Cc: *"ice@ietf.org" , "bfcpbis@ietf.org" , >> Christer Holmberg , "mmusic@ietf.org" < >> mmusic@ietf.org> >> *Subject: *Re: [MMUSIC] [bfcpbis] m=3D line protocol in case of ICE >> >> >> >> I have no experience with ICE with TCP candidates so hopefully others ca= n >> chime in as to what they think is a workable solution. >> >> >> >> Cheers, >> >> Charles >> >> >> >> *From: *Roman Shpount >> *Date: *Thursday, December 1, 2016 at 12:34 PM >> *To: *Charles Eckel >> *Cc: *Alan Ford , "bfcpbis@ietf.org" < >> bfcpbis@ietf.org>, "ice@ietf.org" , "mmusic@ietf.org" < >> mmusic@ietf.org>, Christer Holmberg >> *Subject: *Re: [bfcpbis] [MMUSIC] m=3D line protocol in case of ICE >> >> >> >> Charles, >> >> >> >> RFC 6544 Sending Media (https://tools.ietf.org/html/rfc6544#section-10.1= ) says >> that "The framing defined in RFC 4571 >> MUST be used when sending media." >> This means the protocol used is not TCP/BFCP which is using application >> level framing. I believe that STUN/Media demultiplexing requirements wou= ld >> prevent using TCP/BFCP directly with ice tcp candidates without redesign= of >> either ICE TCP or TCP/BFCP. >> >> >> >> Furthermore there are other implied ICE requirements that I outlined >> before (switching between udp and tpc candidates, existence of SBC which >> terminate ICE only but do not support the embedded protocol) because of >> which ice tcp is considered unreliable transport and will require >> fragmentation support and re-transmit timers that are not part of TCP/BF= CP. >> >> >> >> Regards, >> >> >> _____________ >> Roman Shpount >> >> >> >> On Thu, Dec 1, 2016 at 3:17 PM, Charles Eckel (eckelcu) < >> eckelcu@cisco.com> wrote: >> >> Roman, >> >> >> >> Why would selecting TCP/BFCP as transport violate RFC 6544? Perhaps it >> does, but after a quick scan I am not sure why. >> >> >> >> Cheers, >> >> Charles >> >> >> >> *From: *Roman Shpount >> *Date: *Tuesday, November 29, 2016 at 10:38 AM >> *To: *Charles Eckel >> *Cc: *Alan Ford , "bfcpbis@ietf.org" < >> bfcpbis@ietf.org>, "ice@ietf.org" , "mmusic@ietf.org" < >> mmusic@ietf.org>, Christer Holmberg >> *Subject: *Re: [bfcpbis] [MMUSIC] m=3D line protocol in case of ICE >> >> >> >> On Tue, Nov 29, 2016 at 12:48 PM, Charles Eckel (eckelcu) < >> eckelcu@cisco.com> wrote: >> >> It seems to me that the most straightforward approach would be to mandat= e >> support for BFCP over UDP when using ICE, use UDP as the default candida= te, >> and signal the BFCP m-line as if it is BFCP over UDP. If we can mandate = the >> use of DTLS, that would be even better. >> >> Thoughts? >> >> >> >> >> >> I agree. >> >> >> >> The only issue that I still have, if DTLS is not used, what protocol is >> used when ICE tcp candidate is selected for transport. Is this TCP/BFCP >> (which goes against RFC6544) or is it UDP/BFCP with RFC4571 framing? If= it >> is UDP/BFCP with RFC4571 framing, what transport tag should be used in t= he >> re-INVITE which is sent after ICE nomination with only selected candidat= e? >> Should it be TCP/UDP/BFCP or something similar? >> >> >> >> Regards, >> >> _____________ >> Roman Shpount >> >> >> >> >> >> > _______________________________________________ > bfcpbis mailing list > bfcpbis@ietf.org > https://www.ietf.org/mailman/listinfo/bfcpbis > > > --94eb2c0830de5493180545394135 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Alan,

TCP/BFCP and=C2=A0TLS/BFCP will not work with ICE. Or, to be more precise, w= ill not work without some specification changes either in ICE tcp or in BFC= P.

<= /span>
One pair= of protocols which will work with ICE is UDP/DTLS/BFCP and=C2=A0TCP/DTLS/BFCP. It wil= l support both tcp and udp candidates. I think this pair should be recommen= ded since it provides encryption.=C2=A0

= Another pair that = will work with ICE is=C2=A0UDP/BFCP and=C2=A0TCP/UDP/BFCP. It will also support tcp and udp candidates. = It is not something I would use over public internet since it will transmit= data in the clear text.

Finally, I prefer that any end point which implement BFCP= and supports ICE and DTLS, MUST support=C2=A0UDP/DTLS/BFCP and use it=C2=A0for default candidate. Any e= ndpoint which implements=C2=A0BFCP and ICE, but does not support DTLS, MUST= support UDP/BFCP and use it as a default candidate.=C2=A0

Once the ICE candidate pair is selected, the transport matching the select= ed candidate pair should be used in the SDP.

=
There is no p= ractical need for the asymmetric transport tags. I think the whole thing is= coming from =C2=A0the confusion that TCP/BFCP can be used with ICE tcp can= didates. It cannot without some specification changes. Also, there is no re= ason to use=C2=A0TCP/DTLS/BFCP or=C2=A0TCP/UDP/BFCP, unless ICE is used. Because of this, there is no re= ason to use either of those transports for default candidate, since default= candidate is selected for interop with end points not supporting ICE.

<= /span>
Regards,

_____________
Roman Shpount

On Tue, Jan 3, 2017 at 6:23 PM, Alan Ford <alan.ford@gmail.com> wrote:
Roman,

Do any of = those work for having both tcp and udp ICE candidates? I assume any with IC= E (+ 4571 framing) would be acceptable for that case?

<= div>Ideally we need to support the case where an answer=E2=80=99s m-line pr= otocol does not match any of the candidates, so that an answer could only s= upport TCP (say) when the offerer supported both (and used a UDP m-line pro= tocol). If Christer=E2=80=99s proposed change which permitted an answer not= to match the m-line protocol in the ICE candidates was accepted, that woul= d resolve this case. Do you see any problems here?

Regards,
Alan

=
On 3 Jan 2017, at 20:08, Roman Shpount <roman@telurix.com> w= rote:

Charles,

I do not think not supporting ICE tcp candidates will quite work si= nce it will reduce the usability considerably. The simplest way to move for= ward is to define a different transport tag for BFCP =C2=A0with RFC 4571 ov= er TCP not to confuse it with TCP/BFCP. It can be TCP/UDP/BFCP (I know this= looks strange and I am open to other suggestions, such as calling all pack= et based protocols DBFCP).=C2=A0

In general what I= am proposing is:

TCP/BFCP -- existing BFCP over T= CP
TLS/BFCP -- exisitng BFCP over TLS
UDP/BFCP -- BFCP = over UDP or ICE udp candidates
TCP/UDP/BFCP -- BFCP with RFC 4571= framing=C2=A0over TCP or over ICE tcp candidates
UDP/DTLS/BF= CP -- BFCP over DTLS or over ICE udp candidates
TCP/DTLS/BFCP -- = BFCP over DTLS with RFC 4571 framing=C2=A0over TCP or over ICE tcp candidat= es

Legacy BFCP over TCP or TLS cannot work with IC= E or NAT. Other protocols can work with NAT or ICE using normal ICE procedu= res.

If we call all packet based protocols DBFCP t= hen transport tags will be:

TCP/BFCP -- exist= ing BFCP over TCP
TLS/BFCP -- exisitng BFCP over TLS
UD= P/DBFCP -- DBFCP over UDP or ICE udp candidates
TCP/DBFCP -- DBFC= P with RFC 4571 framing=C2=A0over TCP or over ICE tcp candidates
<= div>UDP/DTLS/DBFCP -- DBFCP over DTLS or over ICE udp candidates
= TCP/DTLS/DBFCP -- DBFCP over DTLS with RFC 4571 framing=C2=A0over TCP or ov= er ICE tcp candidates

Since BFCP over UDP (o= r other packet based protocols) is quite different due to timers and transm= ission restrictions, it can have a different transport tag and even be defi= ned in a separate RFC.

Regards,

_____________
Ro= man Shpount

On Tue, Jan 3, 2017 at 2:43 PM, Charles Ecke= l (eckelcu) <eckelcu@cisco.com> wrote:

Crickets=E2=80=A6

If no one is or has plans for using ICE with TCP/BFCP, perhaps it is best= to state that as of this rev of the BFCP spec, BFCP with TCP candidates is= not defined. Future updates to the spec may define this usage.

=C2=A0

Cheers,

Charles

<= p class=3D"MsoNormal">=C2=A0

From= : mmusic <mmusic-bounces@ietf.org> on beh= alf of Charles Eckel <eckelcu@cisco.com>
Date: Friday, December 2, 2016 at 4:01 PM
To: Roman Shpount <roman@telurix.com>
Cc: "ice@ietf= .org" <ice@ie= tf.org>, "bfcpbis@ietf.org" <bfcpbis@ietf.org>, Christer Holmberg <christer.holmberg@eric= sson.com>, "mmusic@ietf.org" <mmusic@ietf.org>
Subject: Re: [MMUSIC] [bfcpbis] m=3D line protocol in case of ICE=

=C2=A0

I have no experience with ICE with TCP candida= tes so hopefully others can chime in as to what they think is a workable so= lution.

=C2=A0

Cheers,

Charles

=C2=A0

From= : Roman Shpount <roman@telurix.com>
Date: Thursday, December 1, 2016 at 12:34 PM
To: Charles Eckel <eckelcu@cisco.com>
Cc: Alan Ford <alan.ford@gmail.com>, "bfcpbis@ietf.org" <bfcpbis@ietf.org>, "ice@ietf.org" <ice@ietf.org>, "mmusic@ietf.org" <= ;mmusic@ietf.org&g= t;, Christer Holmberg <christer.holmberg@ericsson.com>
Subject: Re: [bfcpbis] [MMUSIC] m=3D line protocol in case of ICE

=C2=A0

Charles,

=C2=A0

RFC 6544 Sending Media (https://tools.ietf.= org/html/rfc6544#section-10.1)=C2=A0says that "The framing defined in RFC 4571 MUST be used when sending media." This means the protocol used = is not TCP/BFCP which is using application level framing. I believe that STUN/Media demultiplexing requirements would preve= nt using TCP/BFCP directly with ice tcp candidates without redesign of eith= er ICE TCP or TCP/BFCP.

=C2=A0

Furthermore=C2= =A0there are other implied ICE requirements that I outlined before (switchi= ng between udp and tpc candidates, existence of SBC which terminate ICE onl= y but do not support the embedded protocol) because of which ice tcp is considered unreliable transport and = will require fragmentation support and re-transmit timers that are not part= of TCP/BFCP.

=C2=A0

Regards,<= u>


_____________
Roman Shpount

=C2=A0

On Thu, Dec 1, 2016 at 3:17 PM, Charles Eckel (= eckelcu) <eckelcu= @cisco.com> wrote:

Roman,

= =C2=A0

Why would selecting TCP/BFCP= as transport violate RFC 6544? Perhaps it does, but after a quick scan I a= m not sure why.

=C2=A0

Cheers,

Charles

=C2=A0

From= : Roman Shpount <roman@telurix.com>
Date: Tuesday, November 29, 2016 at 10:38 AM
To: Charles Eckel <eckelcu@cisco.com>
Cc: Alan Ford <alan.ford@gmail.com>, "bfcpbis@ietf.org" <bfcpbis@ietf.org>, "ice@ietf.org" <ice@ietf.org>= , "mmusic@ietf.or= g" <mmusic= @ietf.org>, Christer Holmberg <christer.holmberg@ericsson.com&g= t;
Subject: Re: [bfcpbis] [MMUSIC] m=3D line protocol in case of ICE

=C2=A0

On Tue, Nov 29, 2016 at 12:48 PM, Charles Eckel= (eckelcu) <eckel= cu@cisco.com> wrote:

It seems to me that the most straightforward ap= proach would be to mandate support for BFCP over UDP when using ICE, use UD= P as the default candidate, and signal the BFCP m-line as if it is BFCP over UDP. If we can mandate the use of DTLS, that would b= e even better.

Thoughts?<= /u>

=C2=A0

=C2=A0

I agree.

=C2=A0

The only issue that I still have, if DTLS is no= t used, what protocol is used when ICE tcp candidate is=C2=A0selected for t= ransport. Is this TCP/BFCP (which goes against RFC6544) =C2=A0or is it UDP/BFCP with RFC4571 framing? If it is UDP/BFCP with RFC4571 framin= g, what transport tag should be used in the re-INVITE which is sent after I= CE nomination with only selected candidate? Should it be TCP/UDP/BFCP or so= mething similar?

=C2=A0

Regards,

_____________
Roman Shpount

=C2=A0

=C2=A0


_______________________________________________
bfcpbis mailing lis= t
bfcpbis@ietf.org=
https://www.ietf.org/mailman/listinfo/bfcpbis


--94eb2c0830de5493180545394135-- From nobody Wed Jan 4 19:04:37 2017 Return-Path: X-Original-To: ice@ietfa.amsl.com Delivered-To: ice@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 787F112986F for ; Wed, 4 Jan 2017 19:04:36 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.002 X-Spam-Level: X-Spam-Status: No, score=-5.002 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-3.1, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3eeW4zs2opQy for ; Wed, 4 Jan 2017 19:04:34 -0800 (PST) Received: from stpeter.im (mailhost.stpeter.im [207.210.219.225]) by ietfa.amsl.com (Postfix) with ESMTP id A498B129866 for ; Wed, 4 Jan 2017 19:04:34 -0800 (PST) Received: from aither.local (unknown [76.25.4.24]) (Authenticated sender: stpeter) by stpeter.im (Postfix) with ESMTPSA id 36526400E0; Wed, 4 Jan 2017 20:07:52 -0700 (MST) To: Taylor Brandstetter , draft-ietf-ice-trickle@tools.ietf.org References: From: Peter Saint-Andre Message-ID: Date: Wed, 4 Jan 2017 20:04:32 -0700 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.12; rv:45.0) Gecko/20100101 Thunderbird/45.6.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit Archived-At: Cc: ice@ietf.org Subject: Re: [Ice] Comments on draft-ietf-ice-trickle-04 (Taylor) X-BeenThere: ice@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Interactive Connectivity Establishment \(ICE\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Jan 2017 03:04:36 -0000 Hi Taylor, Emil and I are working through all feedback now and might have a few more comments beyond those which you can find inline. On 10/19/16 12:53 PM, Taylor Brandstetter wrote: > I reviewed draft-ietf-ice-trickle-04 and noted various > comments/questions as I went along. Looking back, many of these are the > same things Christer mentioned a week ago, or are purely editorial. But > my major takeaways were: > > 1. Many sections need to be changed in order to not directly prescribe > the SDP offer/answer model. Though I feel it's fine to use SDP > offer/answer in examples. That approach will be reflected in -05. > 2. There are still some problems with the freezing/unfreezing rules as I > understand them. > > Anyway, here are my comments, grouped by section: > > *Section 2 - Terminology* > > * Here and throughout the document, UPnP based port allocation and > XMPP Jingle Relay Nodes are mentioned, which not even ICEbis > references. Should these be removed? Yes. > * The concept of a “generation of candidates” is not defined anywhere, > even though I intuitively know what it means. Subject to discussion with my co-authors, I've provisionally changed this to "batch". The term "generation" is used in a different sense within the original documentation of the trickle concept (XEP-0176), so I'd prefer not to use it here. > I recommend defining > it in ICEbis. The phrase “ICE negotiation session” is also used > later, referring to (I think) the same thing. My understanding of those terms is that they're not referring to the same thing. > * It’s stated that Trickle ICE is not defined “in terms of SDP or the > offer/answer model”. But it is, throughout the entire document. The > document needs to be changed to refer to “candidate exchanges”, for > example, instead of offers/answers. Yes, those changes are underway, and Emil and I will smooth over any rough edges that result. > *Section 4 - Sending the Initial Offer* > > * “An agent starts gathering candidates as soon as it has an > indication that communication is imminent”. This isn’t always true. > There are even examples later of the opposite happening (candidates > being gathered well in advance). Maybe just say “an agent > *generally* starts gathering…” I like "An agent can start gathering candidates as soon..." It's really an application decision. > * “A host candidate at a media relay”. Is that really a host > candidate? Where is this described in ICEbis? I suggest we remove "host" here. > * There is discussion around hiding host candidates for privacy > implications. This isn’t specific to Trickle ICE though, so it > should go in ICEbis or somewhere else. Perhaps. It was just a side-comment here, and in any case (per comments by Bernard Aboba) we will probably remove that paragraph. > * “Methods for calculating priorities and foundations, as well as > determining redundancy of candidates, work just as with ICEbis.” Not > the redundancy part, since there are the special prflx rules. Good catch. > *Section 5.2 - Forming Check Lists and Beginning Connectivity Checks* > > * There is talk about unfreezing candidates. But the concept of > freezing a candidate doesn't make sense to me; only pairs are > unfrozen. Is this meant to say “candidate pairs”? I actually notice > the same problem in ICEbis. Will fix. > * The "first checklist with a candidate pair wins" unfreezing rule > means that the initial unfrozen checklist could be different between > the initiating and responding agents due to racy trickling, leading > to at least one of the checklists failing. Suppose for example that > checklist 1 has only pairs with foundation A and checklist 2 has > only pairs with foundation B; there's no guarantee on ordering > between foundations. Why not just "first checklist starts as active, > all others frozen"? I'm not completely clear on the implications of that change and will discuss it with my co-authors. > * “With regard to pruning of duplicate candidate pairs, a Trickle ICE > agent SHOULD follow a policy of ‘first one wins’.” Is this out of > date? In “Pairing Newly Learned Candidates and Updating Check Lists” > there are rules for handling duplicate candidates. There are other > places where this “first one wins” policy is mentioned that should > be updated. Yes, that was out of date. Will be fixed in -05. > * The concepts of “active” and “frozen” check lists are used here, but > the definitions are only elaborated upon in “Check List and Timer > State Updates”. Actually those descriptions (not states) are described in Section 5.1.3.1 of rfc5245bis, so we could just point there. > *Section 7.2 - Check List and Timer State Updates* > > * The definitions of active/frozen are a SHOULD rather than a MUST. If > the unfreezing algorithm is vital, as stated elsewhere, shouldn’t it > be a MUST? I'm fine with MUST. > * “A Trickle ICE agent SHOULD consider a check list to be active … > when the check list is empty.” Wouldn’t that mean that everything > begins as active, in the common case where you start with 0 pairs? I > think the intent here is that an empty check list may be considered > active or frozen, but that’s not exactly what’s written. Also, if > that *is* the intent, the specification should explain exactly when > an empty frozen checklist becomes an empty active checklist. I > believe those conditions are: > o Another checklist is completely finished (every pair Successful > or Failed). > o Another checklist has a valid pair for all components. That seems reasonable, and the authors will discuss to see if we agree. > *Section 8 - Discovering and Sending Additional Local Candidates* > > * In my opinion, the rule that you MUST NOT pair a local candidate > until it's been trickled is not clear enough. Though it's heavily > implied. Yes, we need to make that explicit. > * The rule that you must trickle candidates in the order of > components, to protect the freezing algorithm, is not enough. I > believe you'd also need to trickle them in order of media stream and > priority since this also affects which pair is initially unfrozen. It seems that we've modified this text a bit in our working version of -05 and that it might no longer be in this section (or in the document at all). We'll track this down before posting -05. > *Section 8.1 - Pairing Newly Learned Candidates and Updating Check Lists* > > * If a checklist is active, the new pair is set to “Waiting” if it’s > the first pair in that list with that foundation. This puts pairs in > the Waiting state much more aggressively than ICEbis; if a pair for > the first media stream/component is still in the Waiting state, it > will basically be ignored when pairs with that foundation are added > for other media streams, and they'll all end up as "Waiting". Should > we effectively replace “if no pair in this checklist has a matching > foundation” with “if no pair in *any* checklist has a matching > foundation”? To be discussed among the authors. We'll post further. > * Even with the above change, the unfreezing rules don’t exactly match > ICEbis. So a race between candidate signaling and connectivity > checks could cause a pair to be Frozen on one side and Waiting on > the other. Are we ok with this? That sounds sub-optimal to me. > *Section 8.2 - Announcing End of Candidates* > > * “When an end-of-candidates indication is sent as part of an offer of > an answer, it can be considered to apply to the session as a whole, > which is equivalent to having it apply to all media streams.” Again, > shouldn’t be getting into offer/answer semantics in this document. > But even so, this is incorrect. “a=end-of-candidates” is media-level. Yes, I think we will delete that paragraph before we submit -05. > *Section 11 - Trickle ICE and Peer Reflexive Candidates* > > * This section doesn’t seem to take into account the recent changes, > where peer reflexive candidates can be replaced by server reflexive > candidates. I think we've subsequently fixed that, but we'll double-check. > *Section 18 - Acknowledgements* > > * I don’t think I deserve my own paragraph, I hardly did anything. :) But now you've done more! ;-) Peter From nobody Thu Jan 5 10:27:07 2017 Return-Path: X-Original-To: ice@ietfa.amsl.com Delivered-To: ice@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8AAE8129420 for ; Thu, 5 Jan 2017 10:27:03 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.1 X-Spam-Level: X-Spam-Status: No, score=-2.1 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HEADER_FROM_DIFFERENT_DOMAINS=0.001, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_SORBS_SPAM=0.5, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=jitsi-org.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wl5AU0j92VoE for ; Thu, 5 Jan 2017 10:26:52 -0800 (PST) Received: from mail-wm0-x233.google.com (mail-wm0-x233.google.com [IPv6:2a00:1450:400c:c09::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 B078F129BB2 for ; Thu, 5 Jan 2017 10:26:51 -0800 (PST) Received: by mail-wm0-x233.google.com with SMTP id a197so442499335wmd.0 for ; Thu, 05 Jan 2017 10:26:51 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=jitsi-org.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-transfer-encoding; bh=fi6UnppkNP3AxM1DywpNtHyjXNG4cTYd417K954CtfA=; b=2JarFuERS1QPmStODUxbJm/BDhOQq5Krdw7GP9bax9CfW+lCxD8vdJmtOsP11FNaqm 7oQ4s8LBEAGagfKITL8JJr9zMw69771mfluHwGEmB0LCKWDsU3B+lFVmXA3bATmFa2v+ HVMg5POsTNYmmfL4Cb5o9QvFflkdwY3UrM+U3lTSwb7efz3fF5x+9KfGIkO0OMdKp+U9 h4+EzqgGUkOv8V0HERYc5JUW7jeweDcNIu78V14+iHoN/nMjTqXFPumF/HmL1q6hPpjL Zm3WQzqKcVyE+sA8ZmBrh+wVGM3t0xZV49EVgDufNxl1YOJmRzR8wVAZy5MsAKddMVdB uC8Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-transfer-encoding; bh=fi6UnppkNP3AxM1DywpNtHyjXNG4cTYd417K954CtfA=; b=hDyrhmi2BF5ox1Hr92618ziV6hsMbqEexi5feL9Tw1LdpJlVExISlnsd7QOsTuO7HG NBSsA8ZvPxYuz+goZ7t3jNRqTBM4LPQzFIXxtcQZeU/GJqU8EKgtqDBJJsr7H//kkoiU V8xHcTmq4VVMWrku8iVIxmSLzC9eMezJwUqgRBXemN2UNK4ZZmVKlcpeZD9Y00OSq0mC xWKQLngTkQ3rRiwsJJ8Vb9HJZVaHlkfd3iKSbUnS5V2vIsVh0GZJynqaXJMe7iMiXvlL QvSEH9IqI5R3Le04aSwJtvTqL31TPi2nyeZBRIcUYZWBuMCsvvSMEyTLMUhKcJQUcHSM naag== X-Gm-Message-State: AIkVDXLSorCCPgVB6U2M6qiK8IHFghZxsz1b2Tl9BgCeAM1CszxSNKxrbN2+Lay9f9223Q== X-Received: by 10.28.230.194 with SMTP id e63mr56678216wmi.25.1483640809759; Thu, 05 Jan 2017 10:26:49 -0800 (PST) Received: from mail-wm0-f41.google.com (mail-wm0-f41.google.com. [74.125.82.41]) by smtp.gmail.com with ESMTPSA id cj1sm34162557wjd.46.2017.01.05.10.26.49 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 05 Jan 2017 10:26:49 -0800 (PST) Received: by mail-wm0-f41.google.com with SMTP id t79so495244889wmt.0 for ; Thu, 05 Jan 2017 10:26:49 -0800 (PST) X-Received: by 10.28.10.201 with SMTP id 192mr5503511wmk.56.1483640808608; Thu, 05 Jan 2017 10:26:48 -0800 (PST) MIME-Version: 1.0 Received: by 10.80.183.38 with HTTP; Thu, 5 Jan 2017 10:26:28 -0800 (PST) In-Reply-To: References: From: Emil Ivov Date: Thu, 5 Jan 2017 12:26:28 -0600 X-Gmail-Original-Message-ID: Message-ID: To: Peter Saint-Andre Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Archived-At: Cc: ice@ietf.org, draft-ietf-ice-trickle@tools.ietf.org, Taylor Brandstetter Subject: Re: [Ice] Comments on draft-ietf-ice-trickle-04 (Taylor) X-BeenThere: ice@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Interactive Connectivity Establishment \(ICE\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Jan 2017 18:27:03 -0000 On Wed, Jan 4, 2017 at 9:04 PM, Peter Saint-Andre wrot= e: > Hi Taylor, Emil and I are working through all feedback now and might have= a > few more comments beyond those which you can find inline. > > On 10/19/16 12:53 PM, Taylor Brandstetter wrote: >> >> I reviewed draft-ietf-ice-trickle-04 and noted various >> comments/questions as I went along. Looking back, many of these are the >> same things Christer mentioned a week ago, or are purely editorial. But >> my major takeaways were: >> >> 1. Many sections need to be changed in order to not directly prescribe >> the SDP offer/answer model. Though I feel it's fine to use SDP >> offer/answer in examples. > > > That approach will be reflected in -05. > >> 2. There are still some problems with the freezing/unfreezing rules as I >> understand them. >> >> Anyway, here are my comments, grouped by section: >> >> *Section 2 - Terminology* >> >> * Here and throughout the document, UPnP based port allocation and >> XMPP Jingle Relay Nodes are mentioned, which not even ICEbis >> references. Should these be removed? > > > Yes. I don't see why. Those are informational references and provide good examples of things that take time during gathering. Is there any problem with having them? >> * The concept of a =E2=80=9Cgeneration of candidates=E2=80=9D is not d= efined anywhere, >> even though I intuitively know what it means. > > > Subject to discussion with my co-authors, I've provisionally changed this= to > "batch". > > The term "generation" is used in a different sense within the original > documentation of the trickle concept (XEP-0176), so I'd prefer not to use= it > here. I believe it was the same concept. I find batch more confusing here since it could also mean any subset of candidates in a single generation. I think it would be easier to just define generation as the full set of candidates used by one agent during a full ICE negotiation session >> I recommend defining >> it in ICEbis. The phrase =E2=80=9CICE negotiation session=E2=80=9D i= s also used >> later, referring to (I think) the same thing. > > > My understanding of those terms is that they're not referring to the same > thing. Agreed. >> * It=E2=80=99s stated that Trickle ICE is not defined =E2=80=9Cin term= s of SDP or the >> offer/answer model=E2=80=9D. But it is, throughout the entire docume= nt. The >> document needs to be changed to refer to =E2=80=9Ccandidate exchange= s=E2=80=9D, for >> example, instead of offers/answers. > > > Yes, those changes are underway, and Emil and I will smooth over any roug= h > edges that result. > >> *Section 4 - Sending the Initial Offer* >> >> * =E2=80=9CAn agent starts gathering candidates as soon as it has an >> indication that communication is imminent=E2=80=9D. This isn=E2=80= =99t always true. >> There are even examples later of the opposite happening (candidates >> being gathered well in advance). Maybe just say =E2=80=9Can agent >> *generally* starts gathering=E2=80=A6=E2=80=9D > > > I like "An agent can start gathering candidates as soon..." It's really a= n > application decision. > >> * =E2=80=9CA host candidate at a media relay=E2=80=9D. Is that really = a host >> candidate? Where is this described in ICEbis? > > > I suggest we remove "host" here. > >> * There is discussion around hiding host candidates for privacy >> implications. This isn=E2=80=99t specific to Trickle ICE though, so = it >> should go in ICEbis or somewhere else. > > > Perhaps. It was just a side-comment here, and in any case (per comments b= y > Bernard Aboba) we will probably remove that paragraph. > >> * =E2=80=9CMethods for calculating priorities and foundations, as well= as >> determining redundancy of candidates, work just as with ICEbis.=E2= =80=9D Not >> the redundancy part, since there are the special prflx rules. > > > Good catch. > >> *Section 5.2 - Forming Check Lists and Beginning Connectivity Checks* >> >> * There is talk about unfreezing candidates. But the concept of >> freezing a candidate doesn't make sense to me; only pairs are >> unfrozen. Is this meant to say =E2=80=9Ccandidate pairs=E2=80=9D? I = actually notice >> the same problem in ICEbis. > > > Will fix. > >> * The "first checklist with a candidate pair wins" unfreezing rule >> means that the initial unfrozen checklist could be different between >> the initiating and responding agents due to racy trickling, leading >> to at least one of the checklists failing. Suppose for example that >> checklist 1 has only pairs with foundation A and checklist 2 has >> only pairs with foundation B; there's no guarantee on ordering >> between foundations. Why not just "first checklist starts as active, >> all others frozen"? > > > I'm not completely clear on the implications of that change and will disc= uss > it with my co-authors. What we discussed in Berlin was that once you unfreeze "the first one", anything that comes in the list before the unfrozen pair, will automatically be unfrozen too. This actually removes the importance of "trickling in order" and makes it a mere optimization. We have moved this to an annex and we have sort of clarified the pairing section but at this point I am beginning to think that this entire part needs a full rewrite, possible explaining it more around foundations and the tables we discussed in Berlin. >> * =E2=80=9CWith regard to pruning of duplicate candidate pairs, a Tric= kle ICE >> agent SHOULD follow a policy of =E2=80=98first one wins=E2=80=99.=E2= =80=9D Is this out of >> date? In =E2=80=9CPairing Newly Learned Candidates and Updating Chec= k Lists=E2=80=9D >> there are rules for handling duplicate candidates. There are other >> places where this =E2=80=9Cfirst one wins=E2=80=9D policy is mention= ed that should >> be updated. > > > Yes, that was out of date. Will be fixed in -05. > >> * The concepts of =E2=80=9Cactive=E2=80=9D and =E2=80=9Cfrozen=E2=80= =9D check lists are used here, but >> the definitions are only elaborated upon in =E2=80=9CCheck List and = Timer >> State Updates=E2=80=9D. > > > Actually those descriptions (not states) are described in Section 5.1.3.1= of > rfc5245bis, so we could just point there. We have a trickle specific definition of checklist states: https://tools.ietf.org/html/draft-ietf-mmusic-trickle-ice-02#section-8.1 >> *Section 7.2 - Check List and Timer State Updates* >> >> * The definitions of active/frozen are a SHOULD rather than a MUST. If >> the unfreezing algorithm is vital, as stated elsewhere, shouldn=E2= =80=99t it >> be a MUST? > > > I'm fine with MUST. Agreed >> * =E2=80=9CA Trickle ICE agent SHOULD consider a check list to be acti= ve =E2=80=A6 >> when the check list is empty.=E2=80=9D Wouldn=E2=80=99t that mean th= at everything >> begins as active, Where exactly are you reading this? I can't find the exact wording but the idea was simply to convey that a checklist can be both "Active" and empty with trickle ICE (contrary to vanilla ice). > in the common case where you start with 0 pairs? Right, this wasn't the intent. > I >> think the intent here is that an empty check list may be considered >> active or frozen, but that=E2=80=99s not exactly what=E2=80=99s writ= ten. Also, if >> that *is* the intent, the specification should explain exactly when >> an empty frozen checklist becomes an empty active checklist. I >> believe those conditions are: >> o Another checklist is completely finished (every pair Successful >> or Failed). >> o Another checklist has a valid pair for all components. I think the spec does explain that already at the bottom of 8.1. I would slightly modify the last sentence to fix the part with "when that couldn't happen" because that's not currently super clear. > That seems reasonable, and the authors will discuss to see if we agree. > >> *Section 8 - Discovering and Sending Additional Local Candidates* >> >> * In my opinion, the rule that you MUST NOT pair a local candidate >> until it's been trickled is not clear enough. Though it's heavily >> implied. > > Yes, we need to make that explicit. I don't see why this is a MUST or even a SHOULD. There are examples of apps that never trickle any of their local candidates and rely on their peer to discover them as peer-reflexive. >> * The rule that you must trickle candidates in the order of >> components, to protect the freezing algorithm, is not enough. I >> believe you'd also need to trickle them in order of media stream and >> priority since this also affects which pair is initially unfrozen. > > It seems that we've modified this text a bit in our working version of -0= 5 > and that it might no longer be in this section (or in the document at all= ). > We'll track this down before posting -05. Yup. Gotten rid of that part as explained above. >> *Section 8.1 - Pairing Newly Learned Candidates and Updating Check Lists= * >> >> * If a checklist is active, the new pair is set to =E2=80=9CWaiting=E2= =80=9D if it=E2=80=99s >> the first pair in that list with that foundation. This puts pairs in >> the Waiting state much more aggressively than ICEbis; if a pair for >> the first media stream/component is still in the Waiting state, it >> will basically be ignored when pairs with that foundation are added >> for other media streams, and they'll all end up as "Waiting". Should >> we effectively replace =E2=80=9Cif no pair in this checklist has a m= atching >> foundation=E2=80=9D with =E2=80=9Cif no pair in *any* checklist has = a matching >> foundation=E2=80=9D? > > > To be discussed among the authors. We'll post further. Yes, that is the section that I meant was currently very bad, and that we'll probably end up rewriting. >> * Even with the above change, the unfreezing rules don=E2=80=99t exact= ly match >> ICEbis. So a race between candidate signaling and connectivity >> checks could cause a pair to be Frozen on one side and Waiting on >> the other. Are we ok with this? I think the race is eliminated as long as you say that, for every foundation that has an unfrozen pair, anything that comes in before that pair is also automatically unfrozen. I was actually thinking of asking ICE bis to introduce foundation freeze states but we could also get away with only doing this in trickle. > That sounds sub-optimal to me. > >> *Section 8.2 - Announcing End of Candidates* >> >> * =E2=80=9CWhen an end-of-candidates indication is sent as part of an = offer of >> an answer, it can be considered to apply to the session as a whole, >> which is equivalent to having it apply to all media streams.=E2=80= =9D Again, >> shouldn=E2=80=99t be getting into offer/answer semantics in this doc= ument. >> But even so, this is incorrect. =E2=80=9Ca=3Dend-of-candidates=E2=80= =9D is media-level. The intent was to also allow use of end-of-candidates as a session level attribute but I see now that JSEP doesn't go through that effort, so I guess we could dump this indeed. Cheers, Emil > Yes, I think we will delete that paragraph before we submit -05. > >> *Section 11 - Trickle ICE and Peer Reflexive Candidates* >> >> * This section doesn=E2=80=99t seem to take into account the recent ch= anges, >> where peer reflexive candidates can be replaced by server reflexive >> candidates. > > > I think we've subsequently fixed that, but we'll double-check. > >> *Section 18 - Acknowledgements* >> >> * I don=E2=80=99t think I deserve my own paragraph, I hardly did anyth= ing. :) > > > But now you've done more! ;-) > > Peter > > > _______________________________________________ > Ice mailing list > Ice@ietf.org > https://www.ietf.org/mailman/listinfo/ice --=20 https://jitsi.org From nobody Thu Jan 5 15:06:07 2017 Return-Path: X-Original-To: ice@ietfa.amsl.com Delivered-To: ice@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6E4081296FA for ; Thu, 5 Jan 2017 15:06:05 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.002 X-Spam-Level: X-Spam-Status: No, score=-5.002 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-3.1, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id e7P02DV13Wfm for ; Thu, 5 Jan 2017 15:06:04 -0800 (PST) Received: from stpeter.im (mailhost.stpeter.im [207.210.219.225]) by ietfa.amsl.com (Postfix) with ESMTP id 378E4129713 for ; Thu, 5 Jan 2017 15:06:04 -0800 (PST) Received: from aither.local (unknown [76.25.4.24]) (Authenticated sender: stpeter) by stpeter.im (Postfix) with ESMTPSA id A8B53400E0; Thu, 5 Jan 2017 16:09:24 -0700 (MST) To: Emil Ivov References: From: Peter Saint-Andre Message-ID: <6459894a-cb35-4e86-2e75-ad19412b0a14@stpeter.im> Date: Thu, 5 Jan 2017 16:06:00 -0700 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.12; rv:45.0) Gecko/20100101 Thunderbird/45.6.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Archived-At: Cc: Taylor Brandstetter , draft-ietf-ice-trickle@tools.ietf.org, ice@ietf.org Subject: Re: [Ice] Comments on draft-ietf-ice-trickle-04 (Taylor) X-BeenThere: ice@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Interactive Connectivity Establishment \(ICE\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Jan 2017 23:06:05 -0000 Comments inline, areas of agreement elided. On 1/5/17 11:26 AM, Emil Ivov wrote: > On Wed, Jan 4, 2017 at 9:04 PM, Peter Saint-Andre wrote: >> Hi Taylor, Emil and I are working through all feedback now and might have a >> few more comments beyond those which you can find inline. >> >> On 10/19/16 12:53 PM, Taylor Brandstetter wrote: >>> >>> I reviewed draft-ietf-ice-trickle-04 and noted various >>> comments/questions as I went along. Looking back, many of these are the >>> same things Christer mentioned a week ago, or are purely editorial. But >>> my major takeaways were: >>> >>> 1. Many sections need to be changed in order to not directly prescribe >>> the SDP offer/answer model. Though I feel it's fine to use SDP >>> offer/answer in examples. >> >> >> That approach will be reflected in -05. >> >>> 2. There are still some problems with the freezing/unfreezing rules as I >>> understand them. >>> >>> Anyway, here are my comments, grouped by section: >>> >>> *Section 2 - Terminology* >>> >>> * Here and throughout the document, UPnP based port allocation and >>> XMPP Jingle Relay Nodes are mentioned, which not even ICEbis >>> references. Should these be removed? >> >> >> Yes. > > I don't see why. Those are informational references and provide good > examples of things that take time during gathering. Is there any > problem with having them? It's not a hill for me to die on. :-) >>> * The concept of a “generation of candidates†is not defined anywhere, >>> even though I intuitively know what it means. >> >> >> Subject to discussion with my co-authors, I've provisionally changed this to >> "batch". >> >> The term "generation" is used in a different sense within the original >> documentation of the trickle concept (XEP-0176), so I'd prefer not to use it >> here. > > I believe it was the same concept. I find batch more confusing here > since it could also mean any subset of candidates in a single > generation. I think it would be easier to just define generation as > the full set of candidates used by one agent during a full ICE > negotiation session In XEP-0176, a "generation" consists of all the candidates that are sent before an ICE restart. Here, a "generation" seems to be the first set/batch/group of candidates that are sent (which can be followed by more candidates that are trickled over time). I'm happy to work with you on better text here, though! >>> I recommend defining >>> it in ICEbis. The phrase “ICE negotiation session†is also used >>> later, referring to (I think) the same thing. >> >> >> My understanding of those terms is that they're not referring to the same >> thing. > > Agreed. The term "ICE negotiation session" seems reasonable to me. We need to make it clear that such a session ends with an ICE restart (but that some information can be assumed true across sessions, e.g., whether the parties support trickle). >>> * The "first checklist with a candidate pair wins" unfreezing rule >>> means that the initial unfrozen checklist could be different between >>> the initiating and responding agents due to racy trickling, leading >>> to at least one of the checklists failing. Suppose for example that >>> checklist 1 has only pairs with foundation A and checklist 2 has >>> only pairs with foundation B; there's no guarantee on ordering >>> between foundations. Why not just "first checklist starts as active, >>> all others frozen"? >> >> >> I'm not completely clear on the implications of that change and will discuss >> it with my co-authors. > > What we discussed in Berlin was that once you unfreeze "the first > one", anything that comes in the list before the unfrozen pair, will > automatically be unfrozen too. > > This actually removes the importance of "trickling in order" and makes > it a mere optimization. We have moved this to an annex and we have > sort of clarified the pairing section but at this point I am beginning > to think that this entire part needs a full rewrite, possible > explaining it more around foundations and the tables we discussed in > Berlin. That sounds good. You and I can work on that together and propose some text to the WG. >>> * “A Trickle ICE agent SHOULD consider a check list to be active … >>> when the check list is empty.†Wouldn’t that mean that everything >>> begins as active, > > Where exactly are you reading this? I can't find the exact wording but > the idea was simply to convey that a checklist can be both "Active" > and empty with trickle ICE (contrary to vanilla ice). > >> in the common case where you start with 0 pairs? > > Right, this wasn't the intent. > >> I >>> think the intent here is that an empty check list may be considered >>> active or frozen, but that’s not exactly what’s written. Also, if >>> that *is* the intent, the specification should explain exactly when >>> an empty frozen checklist becomes an empty active checklist. I >>> believe those conditions are: >>> o Another checklist is completely finished (every pair Successful >>> or Failed). >>> o Another checklist has a valid pair for all components. > > I think the spec does explain that already at the bottom of 8.1. I > would slightly modify the last sentence to fix the part with "when > that couldn't happen" because that's not currently super clear. +1 > >> That seems reasonable, and the authors will discuss to see if we agree. >> >>> *Section 8 - Discovering and Sending Additional Local Candidates* >>> >>> * In my opinion, the rule that you MUST NOT pair a local candidate >>> until it's been trickled is not clear enough. Though it's heavily >>> implied. >> >> Yes, we need to make that explicit. > > I don't see why this is a MUST or even a SHOULD. There are examples of > apps that never trickle any of their local candidates and rely on > their peer to discover them as peer-reflexive. I think Taylor was referring to pairing, not trickling. If you decide not to trickle, there's never a need to pair, right? >>> *Section 8.1 - Pairing Newly Learned Candidates and Updating Check Lists* >>> >>> * If a checklist is active, the new pair is set to “Waiting†if it’s >>> the first pair in that list with that foundation. This puts pairs in >>> the Waiting state much more aggressively than ICEbis; if a pair for >>> the first media stream/component is still in the Waiting state, it >>> will basically be ignored when pairs with that foundation are added >>> for other media streams, and they'll all end up as "Waiting". Should >>> we effectively replace “if no pair in this checklist has a matching >>> foundation†with “if no pair in *any* checklist has a matching >>> foundationâ€? >> >> >> To be discussed among the authors. We'll post further. > > Yes, that is the section that I meant was currently very bad, and that > we'll probably end up rewriting. +1 >>> * Even with the above change, the unfreezing rules don’t exactly match >>> ICEbis. So a race between candidate signaling and connectivity >>> checks could cause a pair to be Frozen on one side and Waiting on >>> the other. Are we ok with this? > > I think the race is eliminated as long as you say that, for every > foundation that has an unfrozen pair, anything that comes in before > that pair is also automatically unfrozen. I think that would work. > I was actually thinking of asking ICE bis to introduce foundation > freeze states but we could also get away with only doing this in > trickle. It does seem to apply more directly to trickle. >>> *Section 8.2 - Announcing End of Candidates* >>> >>> * “When an end-of-candidates indication is sent as part of an offer of >>> an answer, it can be considered to apply to the session as a whole, >>> which is equivalent to having it apply to all media streams.†Again, >>> shouldn’t be getting into offer/answer semantics in this document. >>> But even so, this is incorrect. “a=end-of-candidates†is media-level. > > The intent was to also allow use of end-of-candidates as a session > level attribute but I see now that JSEP doesn't go through that > effort, so I guess we could dump this indeed. Agreed. Peter From nobody Tue Jan 10 12:17:14 2017 Return-Path: X-Original-To: ice@ietfa.amsl.com Delivered-To: ice@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5562C129443; Tue, 10 Jan 2017 12:17:08 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -17.72 X-Spam-Level: X-Spam-Status: No, score=-17.72 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, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-3.199, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VkvwU9YiBm78; Tue, 10 Jan 2017 12:17:05 -0800 (PST) Received: from alln-iport-8.cisco.com (alln-iport-8.cisco.com [173.37.142.95]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6591F120727; Tue, 10 Jan 2017 12:17:05 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=47598; q=dns/txt; s=iport; t=1484079425; x=1485289025; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=XWhq5eaa9K+x4mckfiOdKk/oFpuV31hCuixldInHA9k=; b=TT1HCXDYBGWYvv1Cs0WrXD5NSu2MAl1t8rHsU6nthovoHhar2a9YzTdf Cu2ESx5vypj6YtT98VPN13VuU3x54sK5XegmvQHtJw57Sk6hrRbeda+xH 4WgXVGt4hsyUW3ZtbOp9th/OAG6yCRntq1Gi2LvlTgB06QYdVaRYGTygD 8=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0AmAQA2QHVY/40NJK1dGQEBAQEBAQEBA?= =?us-ascii?q?QEBBwEBAQEBgnFJAQEBAQEfX4ENB4NIigiSKId/jSiCCAMfAQqFLkoCGoFpPxQ?= =?us-ascii?q?BAgEBAQEBAQFjKIRpAQEBBAEBIUsLEAIBCBEDAQIhAQYDAgICHwYLFAkIAgQBD?= =?us-ascii?q?QUbiDoDGA6wU4IlK4cXDYJIAQEBAQEBAQEBAQEBAQEBAQEBAQEBGAWIRwiBUYE?= =?us-ascii?q?Ggk6BVEQWglItgjEFlSOFSDgBhlqGeIN/CoFtjmqIEIF7hECEEgEfOIFAFTgQA?= =?us-ascii?q?YYccwGGKIEwgQ0BAQE?= X-IronPort-AV: E=Sophos;i="5.33,344,1477958400"; d="scan'208,217";a="370875217" Received: from alln-core-8.cisco.com ([173.36.13.141]) by alln-iport-8.cisco.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 10 Jan 2017 20:17:04 +0000 Received: from XCH-ALN-012.cisco.com (xch-aln-012.cisco.com [173.36.7.22]) by alln-core-8.cisco.com (8.14.5/8.14.5) with ESMTP id v0AKH4DH026005 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Tue, 10 Jan 2017 20:17:04 GMT Received: from xch-aln-018.cisco.com (173.36.7.28) by XCH-ALN-012.cisco.com (173.36.7.22) with Microsoft SMTP Server (TLS) id 15.0.1210.3; Tue, 10 Jan 2017 14:17:03 -0600 Received: from xch-aln-018.cisco.com ([173.36.7.28]) by XCH-ALN-018.cisco.com ([173.36.7.28]) with mapi id 15.00.1210.000; Tue, 10 Jan 2017 14:17:03 -0600 From: "Charles Eckel (eckelcu)" To: Roman Shpount , Alan Ford , "Tom Kristensen (tomkrist)" , Tom Kristensen <2mkristensen@gmail.com> Thread-Topic: [bfcpbis] [MMUSIC] m= line protocol in case of ICE Thread-Index: AQHSZhtknFAwOo6gtkq09SOaLvmbNKEyD0MA Date: Tue, 10 Jan 2017 20:17:03 +0000 Message-ID: References: <7594FB04B1934943A5C02806D1A2204B4BE3AE83@ESESSMB209.ericsson.se> <16B5D8FF-F132-4B09-84D6-AE964CA7858D@cisco.com> <64E8A5CF-89ED-4673-AF23-2C960395C3EF@cisco.com> <633D3491-83B1-421F-B48C-0A61B1314E99@cisco.com> <739486DE-BDFA-48FD-ACBA-41E45D208748@gmail.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/f.1d.0.161209 x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.156.130.222] Content-Type: multipart/alternative; boundary="_000_E141AB908F354786B443DF7682F3D5FAciscocom_" MIME-Version: 1.0 Archived-At: Cc: "ice@ietf.org" , "bfcpbis@ietf.org" , "mmusic@ietf.org" , Christer Holmberg Subject: Re: [Ice] [bfcpbis] [MMUSIC] m= line protocol in case of ICE X-BeenThere: ice@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Interactive Connectivity Establishment \(ICE\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Jan 2017 20:17:08 -0000 --_000_E141AB908F354786B443DF7682F3D5FAciscocom_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 Um9tYW4sDQoNClRoYW5rcyBmb3Igc2hhcmluZyB0aGlzIHZlcnkgY2xlYXIgcHJvcG9zYWwuIFVu bGVzcyBzb21lb25lIHNlZXMgYW4gaXNzdWUgd2l0aCBpdCwgSSB0aGluayBpdCBzaG91bGQgYmUg aW5jb3Jwb3JhdGVkIGludG8gZHJhZnQtaWV0Zi1iZmNwYmlzLXJmYzQ1ODNiaXMuIFN1cHBvcnQg Zm9yIERUTFMgaXMgcmVxdWlyZWQgYnkgZHJhZnQtaWV0Zi1iZmNwYmlzLXJmYzQ1ODJiaXMgZm9y IHRyYW5zcG9ydCBvZiBCRkNQIG92ZXIgVURQLCBzbyByZXF1aXJpbmcgc3VwcG9ydCBmb3IgVURQ L0RUTFMvQkZDUCBhcyB0aGUgZGVmYXVsdCBjYW5kaWRhdGUgd2hlbiB1c2luZyBJQ0UgYW5kIERU TFMgYW5kIHJlcXVpcmluZyBzdXBwb3J0IGZvciBVRFAvQkZDUCBhcyB0aGUgZGVmYXVsdCBjYW5k aWRhdGUgb3RoZXJ3aXNlIHNob3VsZCBiZSBmaW5lLg0KDQpJIGJlbGlldmUgdGhlIGNoYW5nZXMg cmVxdWlyZWQgdG8gYWRkIHlvdXIgcHJvcG9zYWwgYXJlIGxpbWl0ZWQgdG8gZHJhZnQtaWV0Zi1i ZmNwYmlzLXJmYzQ1ODNiaXMuIFJvbWFuLCBjYW4geW91IHdvcmsgd2l0aCBUb20gS3Jpc3RlbnNl biB0byBtYWtlIHN1cmUgeW91ciBwcm9wb3NhbCBpcyBjYXB0dXJlZCBjb3JyZWN0bHkgaW4gdXBk YXRlIHRvIGRyYWZ0LWlldGYtYmZjcGJpcy1yZmM0NTgzYmlzPw0KDQpDaGVlcnMsDQpDaGFybGVz DQoNCkZyb206IFJvbWFuIFNocG91bnQgPHJvbWFuQHRlbHVyaXguY29tPg0KRGF0ZTogVHVlc2Rh eSwgSmFudWFyeSAzLCAyMDE3IGF0IDM6NDQgUE0NClRvOiBBbGFuIEZvcmQgPGFsYW4uZm9yZEBn bWFpbC5jb20+DQpDYzogQ2hhcmxlcyBFY2tlbCA8ZWNrZWxjdUBjaXNjby5jb20+LCAiYmZjcGJp c0BpZXRmLm9yZyIgPGJmY3BiaXNAaWV0Zi5vcmc+LCBDaHJpc3RlciBIb2xtYmVyZyA8Y2hyaXN0 ZXIuaG9sbWJlcmdAZXJpY3Nzb24uY29tPiwgIm1tdXNpY0BpZXRmLm9yZyIgPG1tdXNpY0BpZXRm Lm9yZz4sICJpY2VAaWV0Zi5vcmciIDxpY2VAaWV0Zi5vcmc+DQpTdWJqZWN0OiBSZTogW2JmY3Bi aXNdIFtNTVVTSUNdIG09IGxpbmUgcHJvdG9jb2wgaW4gY2FzZSBvZiBJQ0UNCg0KQWxhbiwNCg0K VENQL0JGQ1AgYW5kIFRMUy9CRkNQIHdpbGwgbm90IHdvcmsgd2l0aCBJQ0UuIE9yLCB0byBiZSBt b3JlIHByZWNpc2UsIHdpbGwgbm90IHdvcmsgd2l0aG91dCBzb21lIHNwZWNpZmljYXRpb24gY2hh bmdlcyBlaXRoZXIgaW4gSUNFIHRjcCBvciBpbiBCRkNQLg0KDQpPbmUgcGFpciBvZiBwcm90b2Nv bHMgd2hpY2ggd2lsbCB3b3JrIHdpdGggSUNFIGlzIFVEUC9EVExTL0JGQ1AgYW5kIFRDUC9EVExT L0JGQ1AuIEl0IHdpbGwgc3VwcG9ydCBib3RoIHRjcCBhbmQgdWRwIGNhbmRpZGF0ZXMuIEkgdGhp bmsgdGhpcyBwYWlyIHNob3VsZCBiZSByZWNvbW1lbmRlZCBzaW5jZSBpdCBwcm92aWRlcyBlbmNy eXB0aW9uLg0KDQpBbm90aGVyIHBhaXIgdGhhdCB3aWxsIHdvcmsgd2l0aCBJQ0UgaXMgVURQL0JG Q1AgYW5kIFRDUC9VRFAvQkZDUC4gSXQgd2lsbCBhbHNvIHN1cHBvcnQgdGNwIGFuZCB1ZHAgY2Fu ZGlkYXRlcy4gSXQgaXMgbm90IHNvbWV0aGluZyBJIHdvdWxkIHVzZSBvdmVyIHB1YmxpYyBpbnRl cm5ldCBzaW5jZSBpdCB3aWxsIHRyYW5zbWl0IGRhdGEgaW4gdGhlIGNsZWFyIHRleHQuDQoNCkZp bmFsbHksIEkgcHJlZmVyIHRoYXQgYW55IGVuZCBwb2ludCB3aGljaCBpbXBsZW1lbnQgQkZDUCBh bmQgc3VwcG9ydHMgSUNFIGFuZCBEVExTLCBNVVNUIHN1cHBvcnQgVURQL0RUTFMvQkZDUCBhbmQg dXNlIGl0IGZvciBkZWZhdWx0IGNhbmRpZGF0ZS4gQW55IGVuZHBvaW50IHdoaWNoIGltcGxlbWVu dHMgQkZDUCBhbmQgSUNFLCBidXQgZG9lcyBub3Qgc3VwcG9ydCBEVExTLCBNVVNUIHN1cHBvcnQg VURQL0JGQ1AgYW5kIHVzZSBpdCBhcyBhIGRlZmF1bHQgY2FuZGlkYXRlLg0KDQpPbmNlIHRoZSBJ Q0UgY2FuZGlkYXRlIHBhaXIgaXMgc2VsZWN0ZWQsIHRoZSB0cmFuc3BvcnQgbWF0Y2hpbmcgdGhl IHNlbGVjdGVkIGNhbmRpZGF0ZSBwYWlyIHNob3VsZCBiZSB1c2VkIGluIHRoZSBTRFAuDQoNClRo ZXJlIGlzIG5vIHByYWN0aWNhbCBuZWVkIGZvciB0aGUgYXN5bW1ldHJpYyB0cmFuc3BvcnQgdGFn cy4gSSB0aGluayB0aGUgd2hvbGUgdGhpbmcgaXMgY29taW5nIGZyb20gIHRoZSBjb25mdXNpb24g dGhhdCBUQ1AvQkZDUCBjYW4gYmUgdXNlZCB3aXRoIElDRSB0Y3AgY2FuZGlkYXRlcy4gSXQgY2Fu bm90IHdpdGhvdXQgc29tZSBzcGVjaWZpY2F0aW9uIGNoYW5nZXMuIEFsc28sIHRoZXJlIGlzIG5v IHJlYXNvbiB0byB1c2UgVENQL0RUTFMvQkZDUCBvciBUQ1AvVURQL0JGQ1AsIHVubGVzcyBJQ0Ug aXMgdXNlZC4gQmVjYXVzZSBvZiB0aGlzLCB0aGVyZSBpcyBubyByZWFzb24gdG8gdXNlIGVpdGhl ciBvZiB0aG9zZSB0cmFuc3BvcnRzIGZvciBkZWZhdWx0IGNhbmRpZGF0ZSwgc2luY2UgZGVmYXVs dCBjYW5kaWRhdGUgaXMgc2VsZWN0ZWQgZm9yIGludGVyb3Agd2l0aCBlbmQgcG9pbnRzIG5vdCBz dXBwb3J0aW5nIElDRS4NCg0KUmVnYXJkcywNCg0KX19fX19fX19fX19fXw0KUm9tYW4gU2hwb3Vu dA0KDQpPbiBUdWUsIEphbiAzLCAyMDE3IGF0IDY6MjMgUE0sIEFsYW4gRm9yZCA8YWxhbi5mb3Jk QGdtYWlsLmNvbTxtYWlsdG86YWxhbi5mb3JkQGdtYWlsLmNvbT4+IHdyb3RlOg0KUm9tYW4sDQoN CkRvIGFueSBvZiB0aG9zZSB3b3JrIGZvciBoYXZpbmcgYm90aCB0Y3AgYW5kIHVkcCBJQ0UgY2Fu ZGlkYXRlcz8gSSBhc3N1bWUgYW55IHdpdGggSUNFICgrIDQ1NzEgZnJhbWluZykgd291bGQgYmUg YWNjZXB0YWJsZSBmb3IgdGhhdCBjYXNlPw0KDQpJZGVhbGx5IHdlIG5lZWQgdG8gc3VwcG9ydCB0 aGUgY2FzZSB3aGVyZSBhbiBhbnN3ZXLigJlzIG0tbGluZSBwcm90b2NvbCBkb2VzIG5vdCBtYXRj aCBhbnkgb2YgdGhlIGNhbmRpZGF0ZXMsIHNvIHRoYXQgYW4gYW5zd2VyIGNvdWxkIG9ubHkgc3Vw cG9ydCBUQ1AgKHNheSkgd2hlbiB0aGUgb2ZmZXJlciBzdXBwb3J0ZWQgYm90aCAoYW5kIHVzZWQg YSBVRFAgbS1saW5lIHByb3RvY29sKS4gSWYgQ2hyaXN0ZXLigJlzIHByb3Bvc2VkIGNoYW5nZSB3 aGljaCBwZXJtaXR0ZWQgYW4gYW5zd2VyIG5vdCB0byBtYXRjaCB0aGUgbS1saW5lIHByb3RvY29s IGluIHRoZSBJQ0UgY2FuZGlkYXRlcyB3YXMgYWNjZXB0ZWQsIHRoYXQgd291bGQgcmVzb2x2ZSB0 aGlzIGNhc2UuIERvIHlvdSBzZWUgYW55IHByb2JsZW1zIGhlcmU/DQoNClJlZ2FyZHMsDQpBbGFu DQoNCk9uIDMgSmFuIDIwMTcsIGF0IDIwOjA4LCBSb21hbiBTaHBvdW50IDxyb21hbkB0ZWx1cml4 LmNvbTxtYWlsdG86cm9tYW5AdGVsdXJpeC5jb20+PiB3cm90ZToNCg0KQ2hhcmxlcywNCg0KSSBk byBub3QgdGhpbmsgbm90IHN1cHBvcnRpbmcgSUNFIHRjcCBjYW5kaWRhdGVzIHdpbGwgcXVpdGUg d29yayBzaW5jZSBpdCB3aWxsIHJlZHVjZSB0aGUgdXNhYmlsaXR5IGNvbnNpZGVyYWJseS4gVGhl IHNpbXBsZXN0IHdheSB0byBtb3ZlIGZvcndhcmQgaXMgdG8gZGVmaW5lIGEgZGlmZmVyZW50IHRy YW5zcG9ydCB0YWcgZm9yIEJGQ1AgIHdpdGggUkZDIDQ1NzEgb3ZlciBUQ1Agbm90IHRvIGNvbmZ1 c2UgaXQgd2l0aCBUQ1AvQkZDUC4gSXQgY2FuIGJlIFRDUC9VRFAvQkZDUCAoSSBrbm93IHRoaXMg bG9va3Mgc3RyYW5nZSBhbmQgSSBhbSBvcGVuIHRvIG90aGVyIHN1Z2dlc3Rpb25zLCBzdWNoIGFz IGNhbGxpbmcgYWxsIHBhY2tldCBiYXNlZCBwcm90b2NvbHMgREJGQ1ApLg0KDQpJbiBnZW5lcmFs IHdoYXQgSSBhbSBwcm9wb3NpbmcgaXM6DQoNClRDUC9CRkNQIC0tIGV4aXN0aW5nIEJGQ1Agb3Zl ciBUQ1ANClRMUy9CRkNQIC0tIGV4aXNpdG5nIEJGQ1Agb3ZlciBUTFMNClVEUC9CRkNQIC0tIEJG Q1Agb3ZlciBVRFAgb3IgSUNFIHVkcCBjYW5kaWRhdGVzDQpUQ1AvVURQL0JGQ1AgLS0gQkZDUCB3 aXRoIFJGQyA0NTcxIGZyYW1pbmcgb3ZlciBUQ1Agb3Igb3ZlciBJQ0UgdGNwIGNhbmRpZGF0ZXMN ClVEUC9EVExTL0JGQ1AgLS0gQkZDUCBvdmVyIERUTFMgb3Igb3ZlciBJQ0UgdWRwIGNhbmRpZGF0 ZXMNClRDUC9EVExTL0JGQ1AgLS0gQkZDUCBvdmVyIERUTFMgd2l0aCBSRkMgNDU3MSBmcmFtaW5n IG92ZXIgVENQIG9yIG92ZXIgSUNFIHRjcCBjYW5kaWRhdGVzDQoNCkxlZ2FjeSBCRkNQIG92ZXIg VENQIG9yIFRMUyBjYW5ub3Qgd29yayB3aXRoIElDRSBvciBOQVQuIE90aGVyIHByb3RvY29scyBj YW4gd29yayB3aXRoIE5BVCBvciBJQ0UgdXNpbmcgbm9ybWFsIElDRSBwcm9jZWR1cmVzLg0KDQpJ ZiB3ZSBjYWxsIGFsbCBwYWNrZXQgYmFzZWQgcHJvdG9jb2xzIERCRkNQIHRoZW4gdHJhbnNwb3J0 IHRhZ3Mgd2lsbCBiZToNCg0KVENQL0JGQ1AgLS0gZXhpc3RpbmcgQkZDUCBvdmVyIFRDUA0KVExT L0JGQ1AgLS0gZXhpc2l0bmcgQkZDUCBvdmVyIFRMUw0KVURQL0RCRkNQIC0tIERCRkNQIG92ZXIg VURQIG9yIElDRSB1ZHAgY2FuZGlkYXRlcw0KVENQL0RCRkNQIC0tIERCRkNQIHdpdGggUkZDIDQ1 NzEgZnJhbWluZyBvdmVyIFRDUCBvciBvdmVyIElDRSB0Y3AgY2FuZGlkYXRlcw0KVURQL0RUTFMv REJGQ1AgLS0gREJGQ1Agb3ZlciBEVExTIG9yIG92ZXIgSUNFIHVkcCBjYW5kaWRhdGVzDQpUQ1Av RFRMUy9EQkZDUCAtLSBEQkZDUCBvdmVyIERUTFMgd2l0aCBSRkMgNDU3MSBmcmFtaW5nIG92ZXIg VENQIG9yIG92ZXIgSUNFIHRjcCBjYW5kaWRhdGVzDQoNClNpbmNlIEJGQ1Agb3ZlciBVRFAgKG9y IG90aGVyIHBhY2tldCBiYXNlZCBwcm90b2NvbHMpIGlzIHF1aXRlIGRpZmZlcmVudCBkdWUgdG8g dGltZXJzIGFuZCB0cmFuc21pc3Npb24gcmVzdHJpY3Rpb25zLCBpdCBjYW4gaGF2ZSBhIGRpZmZl cmVudCB0cmFuc3BvcnQgdGFnIGFuZCBldmVuIGJlIGRlZmluZWQgaW4gYSBzZXBhcmF0ZSBSRkMu DQoNClJlZ2FyZHMsDQoNCl9fX19fX19fX19fX18NClJvbWFuIFNocG91bnQNCg0KT24gVHVlLCBK YW4gMywgMjAxNyBhdCAyOjQzIFBNLCBDaGFybGVzIEVja2VsIChlY2tlbGN1KSA8ZWNrZWxjdUBj aXNjby5jb208bWFpbHRvOmVja2VsY3VAY2lzY28uY29tPj4gd3JvdGU6DQpDcmlja2V0c+KApg0K SWYgbm8gb25lIGlzIG9yIGhhcyBwbGFucyBmb3IgdXNpbmcgSUNFIHdpdGggVENQL0JGQ1AsIHBl cmhhcHMgaXQgaXMgYmVzdCB0byBzdGF0ZSB0aGF0IGFzIG9mIHRoaXMgcmV2IG9mIHRoZSBCRkNQ IHNwZWMsIEJGQ1Agd2l0aCBUQ1AgY2FuZGlkYXRlcyBpcyBub3QgZGVmaW5lZC4gRnV0dXJlIHVw ZGF0ZXMgdG8gdGhlIHNwZWMgbWF5IGRlZmluZSB0aGlzIHVzYWdlLg0KDQpDaGVlcnMsDQpDaGFy bGVzDQoNCkZyb206IG1tdXNpYyA8bW11c2ljLWJvdW5jZXNAaWV0Zi5vcmc8bWFpbHRvOm1tdXNp Yy1ib3VuY2VzQGlldGYub3JnPj4gb24gYmVoYWxmIG9mIENoYXJsZXMgRWNrZWwgPGVja2VsY3VA Y2lzY28uY29tPG1haWx0bzplY2tlbGN1QGNpc2NvLmNvbT4+DQpEYXRlOiBGcmlkYXksIERlY2Vt YmVyIDIsIDIwMTYgYXQgNDowMSBQTQ0KVG86IFJvbWFuIFNocG91bnQgPHJvbWFuQHRlbHVyaXgu Y29tPG1haWx0bzpyb21hbkB0ZWx1cml4LmNvbT4+DQpDYzogImljZUBpZXRmLm9yZzxtYWlsdG86 aWNlQGlldGYub3JnPiIgPGljZUBpZXRmLm9yZzxtYWlsdG86aWNlQGlldGYub3JnPj4sICJiZmNw YmlzQGlldGYub3JnPG1haWx0bzpiZmNwYmlzQGlldGYub3JnPiIgPGJmY3BiaXNAaWV0Zi5vcmc8 bWFpbHRvOmJmY3BiaXNAaWV0Zi5vcmc+PiwgQ2hyaXN0ZXIgSG9sbWJlcmcgPGNocmlzdGVyLmhv bG1iZXJnQGVyaWNzc29uLmNvbTxtYWlsdG86Y2hyaXN0ZXIuaG9sbWJlcmdAZXJpY3Nzb24uY29t Pj4sICJtbXVzaWNAaWV0Zi5vcmc8bWFpbHRvOm1tdXNpY0BpZXRmLm9yZz4iIDxtbXVzaWNAaWV0 Zi5vcmc8bWFpbHRvOm1tdXNpY0BpZXRmLm9yZz4+DQpTdWJqZWN0OiBSZTogW01NVVNJQ10gW2Jm Y3BiaXNdIG09IGxpbmUgcHJvdG9jb2wgaW4gY2FzZSBvZiBJQ0UNCg0KSSBoYXZlIG5vIGV4cGVy aWVuY2Ugd2l0aCBJQ0Ugd2l0aCBUQ1AgY2FuZGlkYXRlcyBzbyBob3BlZnVsbHkgb3RoZXJzIGNh biBjaGltZSBpbiBhcyB0byB3aGF0IHRoZXkgdGhpbmsgaXMgYSB3b3JrYWJsZSBzb2x1dGlvbi4N Cg0KQ2hlZXJzLA0KQ2hhcmxlcw0KDQpGcm9tOiBSb21hbiBTaHBvdW50IDxyb21hbkB0ZWx1cml4 LmNvbTxtYWlsdG86cm9tYW5AdGVsdXJpeC5jb20+Pg0KRGF0ZTogVGh1cnNkYXksIERlY2VtYmVy IDEsIDIwMTYgYXQgMTI6MzQgUE0NClRvOiBDaGFybGVzIEVja2VsIDxlY2tlbGN1QGNpc2NvLmNv bTxtYWlsdG86ZWNrZWxjdUBjaXNjby5jb20+Pg0KQ2M6IEFsYW4gRm9yZCA8YWxhbi5mb3JkQGdt YWlsLmNvbTxtYWlsdG86YWxhbi5mb3JkQGdtYWlsLmNvbT4+LCAiYmZjcGJpc0BpZXRmLm9yZzxt YWlsdG86YmZjcGJpc0BpZXRmLm9yZz4iIDxiZmNwYmlzQGlldGYub3JnPG1haWx0bzpiZmNwYmlz QGlldGYub3JnPj4sICJpY2VAaWV0Zi5vcmc8bWFpbHRvOmljZUBpZXRmLm9yZz4iIDxpY2VAaWV0 Zi5vcmc8bWFpbHRvOmljZUBpZXRmLm9yZz4+LCAibW11c2ljQGlldGYub3JnPG1haWx0bzptbXVz aWNAaWV0Zi5vcmc+IiA8bW11c2ljQGlldGYub3JnPG1haWx0bzptbXVzaWNAaWV0Zi5vcmc+Piwg Q2hyaXN0ZXIgSG9sbWJlcmcgPGNocmlzdGVyLmhvbG1iZXJnQGVyaWNzc29uLmNvbTxtYWlsdG86 Y2hyaXN0ZXIuaG9sbWJlcmdAZXJpY3Nzb24uY29tPj4NClN1YmplY3Q6IFJlOiBbYmZjcGJpc10g W01NVVNJQ10gbT0gbGluZSBwcm90b2NvbCBpbiBjYXNlIG9mIElDRQ0KDQpDaGFybGVzLA0KDQpS RkMgNjU0NCBTZW5kaW5nIE1lZGlhIChodHRwczovL3Rvb2xzLmlldGYub3JnL2h0bWwvcmZjNjU0 NCNzZWN0aW9uLTEwLjEpIHNheXMgdGhhdCAiVGhlIGZyYW1pbmcgZGVmaW5lZCBpbiBSRkMgNDU3 MTxodHRwczovL3Rvb2xzLmlldGYub3JnL2h0bWwvcmZjNDU3MT4gTVVTVCBiZSB1c2VkIHdoZW4g c2VuZGluZyBtZWRpYS4iIFRoaXMgbWVhbnMgdGhlIHByb3RvY29sIHVzZWQgaXMgbm90IFRDUC9C RkNQIHdoaWNoIGlzIHVzaW5nIGFwcGxpY2F0aW9uIGxldmVsIGZyYW1pbmcuIEkgYmVsaWV2ZSB0 aGF0IFNUVU4vTWVkaWEgZGVtdWx0aXBsZXhpbmcgcmVxdWlyZW1lbnRzIHdvdWxkIHByZXZlbnQg dXNpbmcgVENQL0JGQ1AgZGlyZWN0bHkgd2l0aCBpY2UgdGNwIGNhbmRpZGF0ZXMgd2l0aG91dCBy ZWRlc2lnbiBvZiBlaXRoZXIgSUNFIFRDUCBvciBUQ1AvQkZDUC4NCg0KRnVydGhlcm1vcmUgdGhl cmUgYXJlIG90aGVyIGltcGxpZWQgSUNFIHJlcXVpcmVtZW50cyB0aGF0IEkgb3V0bGluZWQgYmVm b3JlIChzd2l0Y2hpbmcgYmV0d2VlbiB1ZHAgYW5kIHRwYyBjYW5kaWRhdGVzLCBleGlzdGVuY2Ug b2YgU0JDIHdoaWNoIHRlcm1pbmF0ZSBJQ0Ugb25seSBidXQgZG8gbm90IHN1cHBvcnQgdGhlIGVt YmVkZGVkIHByb3RvY29sKSBiZWNhdXNlIG9mIHdoaWNoIGljZSB0Y3AgaXMgY29uc2lkZXJlZCB1 bnJlbGlhYmxlIHRyYW5zcG9ydCBhbmQgd2lsbCByZXF1aXJlIGZyYWdtZW50YXRpb24gc3VwcG9y dCBhbmQgcmUtdHJhbnNtaXQgdGltZXJzIHRoYXQgYXJlIG5vdCBwYXJ0IG9mIFRDUC9CRkNQLg0K DQpSZWdhcmRzLA0KDQpfX19fX19fX19fX19fDQpSb21hbiBTaHBvdW50DQoNCk9uIFRodSwgRGVj IDEsIDIwMTYgYXQgMzoxNyBQTSwgQ2hhcmxlcyBFY2tlbCAoZWNrZWxjdSkgPGVja2VsY3VAY2lz Y28uY29tPG1haWx0bzplY2tlbGN1QGNpc2NvLmNvbT4+IHdyb3RlOg0KUm9tYW4sDQoNCldoeSB3 b3VsZCBzZWxlY3RpbmcgVENQL0JGQ1AgYXMgdHJhbnNwb3J0IHZpb2xhdGUgUkZDIDY1NDQ/IFBl cmhhcHMgaXQgZG9lcywgYnV0IGFmdGVyIGEgcXVpY2sgc2NhbiBJIGFtIG5vdCBzdXJlIHdoeS4N Cg0KQ2hlZXJzLA0KQ2hhcmxlcw0KDQpGcm9tOiBSb21hbiBTaHBvdW50IDxyb21hbkB0ZWx1cml4 LmNvbTxtYWlsdG86cm9tYW5AdGVsdXJpeC5jb20+Pg0KRGF0ZTogVHVlc2RheSwgTm92ZW1iZXIg MjksIDIwMTYgYXQgMTA6MzggQU0NClRvOiBDaGFybGVzIEVja2VsIDxlY2tlbGN1QGNpc2NvLmNv bTxtYWlsdG86ZWNrZWxjdUBjaXNjby5jb20+Pg0KQ2M6IEFsYW4gRm9yZCA8YWxhbi5mb3JkQGdt YWlsLmNvbTxtYWlsdG86YWxhbi5mb3JkQGdtYWlsLmNvbT4+LCAiYmZjcGJpc0BpZXRmLm9yZzxt YWlsdG86YmZjcGJpc0BpZXRmLm9yZz4iIDxiZmNwYmlzQGlldGYub3JnPG1haWx0bzpiZmNwYmlz QGlldGYub3JnPj4sICJpY2VAaWV0Zi5vcmc8bWFpbHRvOmljZUBpZXRmLm9yZz4iIDxpY2VAaWV0 Zi5vcmc8bWFpbHRvOmljZUBpZXRmLm9yZz4+LCAibW11c2ljQGlldGYub3JnPG1haWx0bzptbXVz aWNAaWV0Zi5vcmc+IiA8bW11c2ljQGlldGYub3JnPG1haWx0bzptbXVzaWNAaWV0Zi5vcmc+Piwg Q2hyaXN0ZXIgSG9sbWJlcmcgPGNocmlzdGVyLmhvbG1iZXJnQGVyaWNzc29uLmNvbTxtYWlsdG86 Y2hyaXN0ZXIuaG9sbWJlcmdAZXJpY3Nzb24uY29tPj4NClN1YmplY3Q6IFJlOiBbYmZjcGJpc10g W01NVVNJQ10gbT0gbGluZSBwcm90b2NvbCBpbiBjYXNlIG9mIElDRQ0KDQpPbiBUdWUsIE5vdiAy OSwgMjAxNiBhdCAxMjo0OCBQTSwgQ2hhcmxlcyBFY2tlbCAoZWNrZWxjdSkgPGVja2VsY3VAY2lz Y28uY29tPG1haWx0bzplY2tlbGN1QGNpc2NvLmNvbT4+IHdyb3RlOg0KSXQgc2VlbXMgdG8gbWUg dGhhdCB0aGUgbW9zdCBzdHJhaWdodGZvcndhcmQgYXBwcm9hY2ggd291bGQgYmUgdG8gbWFuZGF0 ZSBzdXBwb3J0IGZvciBCRkNQIG92ZXIgVURQIHdoZW4gdXNpbmcgSUNFLCB1c2UgVURQIGFzIHRo ZSBkZWZhdWx0IGNhbmRpZGF0ZSwgYW5kIHNpZ25hbCB0aGUgQkZDUCBtLWxpbmUgYXMgaWYgaXQg aXMgQkZDUCBvdmVyIFVEUC4gSWYgd2UgY2FuIG1hbmRhdGUgdGhlIHVzZSBvZiBEVExTLCB0aGF0 IHdvdWxkIGJlIGV2ZW4gYmV0dGVyLg0KVGhvdWdodHM/DQoNCg0KSSBhZ3JlZS4NCg0KVGhlIG9u bHkgaXNzdWUgdGhhdCBJIHN0aWxsIGhhdmUsIGlmIERUTFMgaXMgbm90IHVzZWQsIHdoYXQgcHJv dG9jb2wgaXMgdXNlZCB3aGVuIElDRSB0Y3AgY2FuZGlkYXRlIGlzIHNlbGVjdGVkIGZvciB0cmFu c3BvcnQuIElzIHRoaXMgVENQL0JGQ1AgKHdoaWNoIGdvZXMgYWdhaW5zdCBSRkM2NTQ0KSAgb3Ig aXMgaXQgVURQL0JGQ1Agd2l0aCBSRkM0NTcxIGZyYW1pbmc/IElmIGl0IGlzIFVEUC9CRkNQIHdp dGggUkZDNDU3MSBmcmFtaW5nLCB3aGF0IHRyYW5zcG9ydCB0YWcgc2hvdWxkIGJlIHVzZWQgaW4g dGhlIHJlLUlOVklURSB3aGljaCBpcyBzZW50IGFmdGVyIElDRSBub21pbmF0aW9uIHdpdGggb25s eSBzZWxlY3RlZCBjYW5kaWRhdGU/IFNob3VsZCBpdCBiZSBUQ1AvVURQL0JGQ1Agb3Igc29tZXRo aW5nIHNpbWlsYXI/DQoNClJlZ2FyZHMsDQpfX19fX19fX19fX19fDQpSb21hbiBTaHBvdW50DQoN Cg0KDQpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KYmZj cGJpcyBtYWlsaW5nIGxpc3QNCmJmY3BiaXNAaWV0Zi5vcmc8bWFpbHRvOmJmY3BiaXNAaWV0Zi5v cmc+DQpodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL2JmY3BiaXMNCg0KDQo= --_000_E141AB908F354786B443DF7682F3D5FAciscocom_ Content-Type: text/html; charset="utf-8" Content-ID: <5027D39C22CEB444A67E2D8E12300CDD@emea.cisco.com> Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6bz0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6b2ZmaWNlIiB4 bWxuczp3PSJ1cm46c2NoZW1hcy1taWNyb3NvZnQtY29tOm9mZmljZTp3b3JkIiB4bWxuczptPSJo dHRwOi8vc2NoZW1hcy5taWNyb3NvZnQuY29tL29mZmljZS8yMDA0LzEyL29tbWwiIHhtbG5zPSJo dHRwOi8vd3d3LnczLm9yZy9UUi9SRUMtaHRtbDQwIj4NCjxoZWFkPg0KPG1ldGEgaHR0cC1lcXVp dj0iQ29udGVudC1UeXBlIiBjb250ZW50PSJ0ZXh0L2h0bWw7IGNoYXJzZXQ9dXRmLTgiPg0KPG1l dGEgbmFtZT0iVGl0bGUiIGNvbnRlbnQ9IiI+DQo8bWV0YSBuYW1lPSJLZXl3b3JkcyIgY29udGVu dD0iIj4NCjxtZXRhIG5hbWU9IkdlbmVyYXRvciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUg KGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxlPjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8N CkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6IkNhbWJyaWEgTWF0aCI7DQoJcGFub3NlLTE6MiA0 IDUgMyA1IDQgNiAzIDIgNDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OkNhbGlicmk7DQoJ cGFub3NlLTE6MiAxNSA1IDIgMiAyIDQgMyAyIDQ7fQ0KLyogU3R5bGUgRGVmaW5pdGlvbnMgKi8N CnAuTXNvTm9ybWFsLCBsaS5Nc29Ob3JtYWwsIGRpdi5Nc29Ob3JtYWwNCgl7bWFyZ2luOjBpbjsN CgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJZm9udC1zaXplOjEyLjBwdDsNCglmb250LWZhbWls eToiVGltZXMgTmV3IFJvbWFuIjt9DQphOmxpbmssIHNwYW4uTXNvSHlwZXJsaW5rDQoJe21zby1z dHlsZS1wcmlvcml0eTo5OTsNCgljb2xvcjpibHVlOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxp bmU7fQ0KYTp2aXNpdGVkLCBzcGFuLk1zb0h5cGVybGlua0ZvbGxvd2VkDQoJe21zby1zdHlsZS1w cmlvcml0eTo5OTsNCgljb2xvcjpwdXJwbGU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9 DQpzcGFuLkVtYWlsU3R5bGUxNw0KCXttc28tc3R5bGUtdHlwZTpwZXJzb25hbC1yZXBseTsNCglm b250LWZhbWlseToiVGltZXMgTmV3IFJvbWFuIjsNCgljb2xvcjp3aW5kb3d0ZXh0O30NCnNwYW4u bXNvSW5zDQoJe21zby1zdHlsZS10eXBlOmV4cG9ydC1vbmx5Ow0KCW1zby1zdHlsZS1uYW1lOiIi Ow0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7DQoJY29sb3I6dGVhbDt9DQouTXNvQ2hwRGVm YXVsdA0KCXttc28tc3R5bGUtdHlwZTpleHBvcnQtb25seTsNCglmb250LXNpemU6MTAuMHB0O30N CkBwYWdlIFdvcmRTZWN0aW9uMQ0KCXtzaXplOjguNWluIDExLjBpbjsNCgltYXJnaW46MS4waW4g MS4waW4gMS4waW4gMS4waW47fQ0KZGl2LldvcmRTZWN0aW9uMQ0KCXtwYWdlOldvcmRTZWN0aW9u MTt9DQotLT48L3N0eWxlPg0KPC9oZWFkPg0KPGJvZHkgYmdjb2xvcj0id2hpdGUiIGxhbmc9IkVO LVVTIiBsaW5rPSJibHVlIiB2bGluaz0icHVycGxlIj4NCjxkaXYgY2xhc3M9IldvcmRTZWN0aW9u MSI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5Sb21hbiw8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ VGhhbmtzIGZvciBzaGFyaW5nIHRoaXMgdmVyeSBjbGVhciBwcm9wb3NhbC4gVW5sZXNzIHNvbWVv bmUgc2VlcyBhbiBpc3N1ZSB3aXRoIGl0LCBJIHRoaW5rIGl0IHNob3VsZCBiZSBpbmNvcnBvcmF0 ZWQgaW50byBkcmFmdC1pZXRmLWJmY3BiaXMtcmZjNDU4M2Jpcy4gU3VwcG9ydCBmb3IgRFRMUyBp cyByZXF1aXJlZCBieSBkcmFmdC1pZXRmLWJmY3BiaXMtcmZjNDU4MmJpcyBmb3IgdHJhbnNwb3J0 IG9mIEJGQ1ANCiBvdmVyIFVEUCwgc28gcmVxdWlyaW5nIHN1cHBvcnQgZm9yIFVEUC9EVExTL0JG Q1AgYXMgdGhlIGRlZmF1bHQgY2FuZGlkYXRlIHdoZW4gdXNpbmcgSUNFIGFuZCBEVExTIGFuZCBy ZXF1aXJpbmcgc3VwcG9ydCBmb3IgVURQL0JGQ1AgYXMgdGhlIGRlZmF1bHQgY2FuZGlkYXRlIG90 aGVyd2lzZSBzaG91bGQgYmUgZmluZS48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+SSBiZWxpZXZl IHRoZSBjaGFuZ2VzIHJlcXVpcmVkIHRvIGFkZCB5b3VyIHByb3Bvc2FsIGFyZSBsaW1pdGVkIHRv IGRyYWZ0LWlldGYtYmZjcGJpcy1yZmM0NTgzYmlzLiBSb21hbiwgY2FuIHlvdSB3b3JrIHdpdGgg VG9tIEtyaXN0ZW5zZW4gdG8gbWFrZSBzdXJlIHlvdXIgcHJvcG9zYWwgaXMgY2FwdHVyZWQgY29y cmVjdGx5IGluIHVwZGF0ZSB0byBkcmFmdC1pZXRmLWJmY3BiaXMtcmZjNDU4M2Jpcz88bzpwPjwv bzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+Q2hlZXJzLDxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+Q2hhcmxlczxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4m bmJzcDs8L286cD48L3A+DQo8YmxvY2txdW90ZSBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLWxl ZnQ6c29saWQgI0I1QzRERiA0LjVwdDtwYWRkaW5nOjBpbiAwaW4gMGluIDQuMHB0O21hcmdpbi1s ZWZ0OjMuNzVwdDttYXJnaW4tcmlnaHQ6MGluIj4NCjxkaXYgc3R5bGU9ImJvcmRlcjpub25lO2Jv cmRlci10b3A6c29saWQgI0I1QzRERiAxLjBwdDtwYWRkaW5nOjMuMHB0IDBpbiAwaW4gMGluIj4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxiPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTpDYWxpYnJp O2NvbG9yOmJsYWNrIj5Gcm9tOiA8L3NwYW4+DQo8L2I+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5 OkNhbGlicmk7Y29sb3I6YmxhY2siPlJvbWFuIFNocG91bnQgJmx0O3JvbWFuQHRlbHVyaXguY29t Jmd0Ozxicj4NCjxiPkRhdGU6IDwvYj5UdWVzZGF5LCBKYW51YXJ5IDMsIDIwMTcgYXQgMzo0NCBQ TTxicj4NCjxiPlRvOiA8L2I+QWxhbiBGb3JkICZsdDthbGFuLmZvcmRAZ21haWwuY29tJmd0Ozxi cj4NCjxiPkNjOiA8L2I+Q2hhcmxlcyBFY2tlbCAmbHQ7ZWNrZWxjdUBjaXNjby5jb20mZ3Q7LCAm cXVvdDtiZmNwYmlzQGlldGYub3JnJnF1b3Q7ICZsdDtiZmNwYmlzQGlldGYub3JnJmd0OywgQ2hy aXN0ZXIgSG9sbWJlcmcgJmx0O2NocmlzdGVyLmhvbG1iZXJnQGVyaWNzc29uLmNvbSZndDssICZx dW90O21tdXNpY0BpZXRmLm9yZyZxdW90OyAmbHQ7bW11c2ljQGlldGYub3JnJmd0OywgJnF1b3Q7 aWNlQGlldGYub3JnJnF1b3Q7ICZsdDtpY2VAaWV0Zi5vcmcmZ3Q7PGJyPg0KPGI+U3ViamVjdDog PC9iPlJlOiBbYmZjcGJpc10gW01NVVNJQ10gbT0gbGluZSBwcm90b2NvbCBpbiBjYXNlIG9mIElD RTxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+QWxhbiwgPG86cD48L286cD48L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij48c3BhbiBzdHlsZT0iZm9udC1zaXplOjkuNXB0O2NvbG9yOmJsYWNrIj5UQ1AvQkZDUCBhbmQm bmJzcDtUTFMvQkZDUCB3aWxsIG5vdCB3b3JrIHdpdGggSUNFLiBPciwgdG8gYmUgbW9yZSBwcmVj aXNlLCB3aWxsIG5vdCB3b3JrIHdpdGhvdXQgc29tZSBzcGVjaWZpY2F0aW9uIGNoYW5nZXMgZWl0 aGVyIGluIElDRSB0Y3Agb3IgaW4gQkZDUC48L3NwYW4+PG86cD48L286cD48L3A+DQo8L2Rpdj4N CjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2 Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6OS41 cHQ7Y29sb3I6YmxhY2siPk9uZSBwYWlyIG9mIHByb3RvY29scyB3aGljaCB3aWxsIHdvcmsgd2l0 aCBJQ0UgaXMgVURQL0RUTFMvQkZDUCBhbmQmbmJzcDtUQ1AvRFRMUy9CRkNQLiBJdCB3aWxsIHN1 cHBvcnQgYm90aCB0Y3AgYW5kIHVkcCBjYW5kaWRhdGVzLiBJIHRoaW5rIHRoaXMgcGFpciBzaG91 bGQgYmUgcmVjb21tZW5kZWQgc2luY2UgaXQgcHJvdmlkZXMgZW5jcnlwdGlvbi4mbmJzcDs8L3Nw YW4+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48 bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PjxzcGFuIHN0eWxlPSJmb250LXNpemU6OS41cHQ7Y29sb3I6YmxhY2siPkFub3RoZXIgcGFpciB0 aGF0IHdpbGwgd29yayB3aXRoIElDRSBpcyZuYnNwO1VEUC9CRkNQIGFuZCZuYnNwO1RDUC9VRFAv QkZDUC4gSXQgd2lsbCBhbHNvIHN1cHBvcnQgdGNwIGFuZCB1ZHAgY2FuZGlkYXRlcy4gSXQgaXMg bm90IHNvbWV0aGluZyBJIHdvdWxkIHVzZSBvdmVyIHB1YmxpYyBpbnRlcm5ldCBzaW5jZSBpdCB3 aWxsIHRyYW5zbWl0IGRhdGEgaW4NCiB0aGUgY2xlYXIgdGV4dC48L3NwYW4+PG86cD48L286cD48 L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpw PjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJm b250LXNpemU6OS41cHQ7Y29sb3I6YmxhY2siPkZpbmFsbHksIEkgcHJlZmVyIHRoYXQgYW55IGVu ZCBwb2ludCB3aGljaCBpbXBsZW1lbnQgQkZDUCBhbmQgc3VwcG9ydHMgSUNFIGFuZCBEVExTLCBN VVNUIHN1cHBvcnQmbmJzcDtVRFAvRFRMUy9CRkNQIGFuZCB1c2UgaXQmbmJzcDtmb3IgZGVmYXVs dCBjYW5kaWRhdGUuIEFueSBlbmRwb2ludCB3aGljaCBpbXBsZW1lbnRzJm5ic3A7QkZDUCBhbmQg SUNFLCBidXQNCiBkb2VzIG5vdCBzdXBwb3J0IERUTFMsIE1VU1Qgc3VwcG9ydCBVRFAvQkZDUCBh bmQgdXNlIGl0IGFzIGEgZGVmYXVsdCBjYW5kaWRhdGUuJm5ic3A7PC9zcGFuPjxvOnA+PC9vOnA+ PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286 cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0i Zm9udC1zaXplOjkuNXB0O2NvbG9yOmJsYWNrIj5PbmNlIHRoZSBJQ0UgY2FuZGlkYXRlIHBhaXIg aXMgc2VsZWN0ZWQsIHRoZSB0cmFuc3BvcnQgbWF0Y2hpbmcgdGhlIHNlbGVjdGVkIGNhbmRpZGF0 ZSBwYWlyIHNob3VsZCBiZSB1c2VkIGluIHRoZSBTRFAuPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0K PC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+ DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1z aXplOjkuNXB0O2NvbG9yOmJsYWNrIj5UaGVyZSBpcyBubyBwcmFjdGljYWwgbmVlZCBmb3IgdGhl IGFzeW1tZXRyaWMgdHJhbnNwb3J0IHRhZ3MuIEkgdGhpbmsgdGhlIHdob2xlIHRoaW5nIGlzIGNv bWluZyBmcm9tICZuYnNwO3RoZSBjb25mdXNpb24gdGhhdCBUQ1AvQkZDUCBjYW4gYmUgdXNlZCB3 aXRoIElDRSB0Y3AgY2FuZGlkYXRlcy4gSXQgY2Fubm90IHdpdGhvdXQgc29tZSBzcGVjaWZpY2F0 aW9uDQogY2hhbmdlcy4gQWxzbywgdGhlcmUgaXMgbm8gcmVhc29uIHRvIHVzZSZuYnNwO1RDUC9E VExTL0JGQ1Agb3ImbmJzcDtUQ1AvVURQL0JGQ1AsIHVubGVzcyBJQ0UgaXMgdXNlZC4gQmVjYXVz ZSBvZiB0aGlzLCB0aGVyZSBpcyBubyByZWFzb24gdG8gdXNlIGVpdGhlciBvZiB0aG9zZSB0cmFu c3BvcnRzIGZvciBkZWZhdWx0IGNhbmRpZGF0ZSwgc2luY2UgZGVmYXVsdCBjYW5kaWRhdGUgaXMg c2VsZWN0ZWQgZm9yIGludGVyb3Agd2l0aCBlbmQgcG9pbnRzIG5vdCBzdXBwb3J0aW5nDQogSUNF Ljwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTo5LjVwdDtjb2xvcjpibGFjayI+UmVnYXJkcyw8 L3NwYW4+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPjxiciBjbGVhcj0iYWxsIj4NCjxvOnA+PC9vOnA+PC9wPg0KPGRpdj4NCjxkaXY+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5fX19fX19fX19fX19fPGJyPg0KUm9tYW4gU2hwb3VudDxv OnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+ Jm5ic3A7PC9vOnA+PC9wPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPk9uIFR1ZSwgSmFu IDMsIDIwMTcgYXQgNjoyMyBQTSwgQWxhbiBGb3JkICZsdDs8YSBocmVmPSJtYWlsdG86YWxhbi5m b3JkQGdtYWlsLmNvbSIgdGFyZ2V0PSJfYmxhbmsiPmFsYW4uZm9yZEBnbWFpbC5jb208L2E+Jmd0 OyB3cm90ZTo8bzpwPjwvbzpwPjwvcD4NCjxibG9ja3F1b3RlIHN0eWxlPSJib3JkZXI6bm9uZTti b3JkZXItbGVmdDpzb2xpZCAjQ0NDQ0NDIDEuMHB0O3BhZGRpbmc6MGluIDBpbiAwaW4gNi4wcHQ7 bWFyZ2luLWxlZnQ6NC44cHQ7bWFyZ2luLXJpZ2h0OjBpbiI+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+Um9tYW4sIDxvOnA+PC9vOnA+PC9wPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+RG8gYW55IG9mIHRob3NlIHdvcmsgZm9yIGhhdmluZyBib3RoIHRjcCBhbmQgdWRwIElD RSBjYW5kaWRhdGVzPyBJIGFzc3VtZSBhbnkgd2l0aCBJQ0UgKCYjNDM7IDQ1NzEgZnJhbWluZykg d291bGQgYmUgYWNjZXB0YWJsZSBmb3IgdGhhdCBjYXNlPzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+ DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rp dj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5JZGVhbGx5IHdlIG5lZWQgdG8gc3VwcG9y dCB0aGUgY2FzZSB3aGVyZSBhbiBhbnN3ZXLigJlzIG0tbGluZSBwcm90b2NvbCBkb2VzIG5vdCBt YXRjaCBhbnkgb2YgdGhlIGNhbmRpZGF0ZXMsIHNvIHRoYXQgYW4gYW5zd2VyIGNvdWxkIG9ubHkg c3VwcG9ydCBUQ1AgKHNheSkgd2hlbiB0aGUgb2ZmZXJlciBzdXBwb3J0ZWQgYm90aCAoYW5kIHVz ZWQgYSBVRFAgbS1saW5lIHByb3RvY29sKS4gSWYgQ2hyaXN0ZXLigJlzIHByb3Bvc2VkDQogY2hh bmdlIHdoaWNoIHBlcm1pdHRlZCBhbiBhbnN3ZXIgbm90IHRvIG1hdGNoIHRoZSBtLWxpbmUgcHJv dG9jb2wgaW4gdGhlIElDRSBjYW5kaWRhdGVzIHdhcyBhY2NlcHRlZCwgdGhhdCB3b3VsZCByZXNv bHZlIHRoaXMgY2FzZS4gRG8geW91IHNlZSBhbnkgcHJvYmxlbXMgaGVyZT88bzpwPjwvbzpwPjwv cD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+ PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+UmVnYXJkcyw8bzpwPjwv bzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPkFsYW48bzpwPjwv bzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7 PC9vOnA+PC9wPg0KPGRpdj4NCjxibG9ja3F1b3RlIHN0eWxlPSJtYXJnaW4tdG9wOjUuMHB0O21h cmdpbi1ib3R0b206NS4wcHQiPg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+T24gMyBKYW4gMjAxNywgYXQgMjA6MDgsIFJvbWFuIFNocG91bnQgJmx0OzxhIGhyZWY9 Im1haWx0bzpyb21hbkB0ZWx1cml4LmNvbSIgdGFyZ2V0PSJfYmxhbmsiPnJvbWFuQHRlbHVyaXgu Y29tPC9hPiZndDsgd3JvdGU6PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2 Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5DaGFybGVzLCA8bzpwPjwvbzpw PjwvcD4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4N CjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPkkgZG8gbm90IHRoaW5rIG5vdCBz dXBwb3J0aW5nIElDRSB0Y3AgY2FuZGlkYXRlcyB3aWxsIHF1aXRlIHdvcmsgc2luY2UgaXQgd2ls bCByZWR1Y2UgdGhlIHVzYWJpbGl0eSBjb25zaWRlcmFibHkuIFRoZSBzaW1wbGVzdCB3YXkgdG8g bW92ZSBmb3J3YXJkIGlzIHRvIGRlZmluZSBhIGRpZmZlcmVudCB0cmFuc3BvcnQgdGFnIGZvciBC RkNQICZuYnNwO3dpdGggUkZDIDQ1NzEgb3ZlciBUQ1Agbm90IHRvIGNvbmZ1c2UgaXQNCiB3aXRo IFRDUC9CRkNQLiBJdCBjYW4gYmUgVENQL1VEUC9CRkNQIChJIGtub3cgdGhpcyBsb29rcyBzdHJh bmdlIGFuZCBJIGFtIG9wZW4gdG8gb3RoZXIgc3VnZ2VzdGlvbnMsIHN1Y2ggYXMgY2FsbGluZyBh bGwgcGFja2V0IGJhc2VkIHByb3RvY29scyBEQkZDUCkuJm5ic3A7PG86cD48L286cD48L3A+DQo8 L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4N CjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPkluIGdlbmVyYWwgd2hhdCBJIGFt IHByb3Bvc2luZyBpczo8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+VENQL0JGQ1AgLS0gZXhpc3RpbmcgQkZDUCBvdmVyIFRDUDxvOnA+PC9vOnA+ PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+VExTL0JGQ1AgLS0gZXhp c2l0bmcgQkZDUCBvdmVyIFRMUzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+VURQL0JGQ1AgLS0gQkZDUCBvdmVyIFVEUCBvciBJQ0UgdWRwIGNhbmRp ZGF0ZXM8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PlRDUC9VRFAvQkZDUCAtLSBCRkNQIHdpdGggUkZDIDQ1NzEgZnJhbWluZyZuYnNwO292ZXIgVENQ IG9yIG92ZXIgSUNFIHRjcCBjYW5kaWRhdGVzPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5VRFAvRFRMUy9CRkNQIC0tIEJGQ1Agb3ZlciBEVExTIG9y IG92ZXIgSUNFIHVkcCBjYW5kaWRhdGVzPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj5UQ1AvRFRMUy9CRkNQIC0tIEJGQ1Agb3ZlciBEVExTIHdpdGgg UkZDIDQ1NzEgZnJhbWluZyZuYnNwO292ZXIgVENQIG9yIG92ZXIgSUNFIHRjcCBjYW5kaWRhdGVz PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpw PiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPkxl Z2FjeSBCRkNQIG92ZXIgVENQIG9yIFRMUyBjYW5ub3Qgd29yayB3aXRoIElDRSBvciBOQVQuIE90 aGVyIHByb3RvY29scyBjYW4gd29yayB3aXRoIE5BVCBvciBJQ0UgdXNpbmcgbm9ybWFsIElDRSBw cm9jZWR1cmVzLjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj5JZiB3ZSBjYWxsIGFsbCBwYWNrZXQgYmFzZWQgcHJvdG9jb2xzIERCRkNQIHRoZW4g dHJhbnNwb3J0IHRhZ3Mgd2lsbCBiZTo8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0K PGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPlRDUC9CRkNQIC0tIGV4aXN0aW5nIEJGQ1Agb3Zl ciBUQ1A8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PlRMUy9CRkNQIC0tIGV4aXNpdG5nIEJGQ1Agb3ZlciBUTFM8bzpwPjwvbzpwPjwvcD4NCjwvZGl2 Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPlVEUC9EQkZDUCAtLSBEQkZDUCBvdmVyIFVE UCBvciBJQ0UgdWRwIGNhbmRpZGF0ZXM8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPlRDUC9EQkZDUCAtLSBEQkZDUCB3aXRoIFJGQyA0NTcxIGZyYW1p bmcmbmJzcDtvdmVyIFRDUCBvciBvdmVyIElDRSB0Y3AgY2FuZGlkYXRlczxvOnA+PC9vOnA+PC9w Pg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+VURQL0RUTFMvREJGQ1AgLS0g REJGQ1Agb3ZlciBEVExTIG9yIG92ZXIgSUNFIHVkcCBjYW5kaWRhdGVzPG86cD48L286cD48L3A+ DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5UQ1AvRFRMUy9EQkZDUCAtLSBE QkZDUCBvdmVyIERUTFMgd2l0aCBSRkMgNDU3MSBmcmFtaW5nJm5ic3A7b3ZlciBUQ1Agb3Igb3Zl ciBJQ0UgdGNwIGNhbmRpZGF0ZXM8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxk aXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5TaW5jZSBCRkNQIG92ZXIgVURQIChvciBvdGhlciBw YWNrZXQgYmFzZWQgcHJvdG9jb2xzKSBpcyBxdWl0ZSBkaWZmZXJlbnQgZHVlIHRvIHRpbWVycyBh bmQgdHJhbnNtaXNzaW9uIHJlc3RyaWN0aW9ucywgaXQgY2FuIGhhdmUgYSBkaWZmZXJlbnQgdHJh bnNwb3J0IHRhZyBhbmQgZXZlbiBiZSBkZWZpbmVkIGluIGEgc2VwYXJhdGUgUkZDLjxvOnA+PC9v OnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8 L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5SZWdhcmRzLDxv OnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij48YnIgY2xlYXI9ImFsbCI+DQo8bzpwPjwvbzpwPjwvcD4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+X19fX19fX19fX19fXzxicj4NClJvbWFuIFNocG91bnQ8bzpwPjwvbzpw PjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwv bzpwPjwvcD4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5PbiBUdWUsIEphbiAzLCAyMDE3 IGF0IDI6NDMgUE0sIENoYXJsZXMgRWNrZWwgKGVja2VsY3UpICZsdDs8YSBocmVmPSJtYWlsdG86 ZWNrZWxjdUBjaXNjby5jb20iIHRhcmdldD0iX2JsYW5rIj5lY2tlbGN1QGNpc2NvLmNvbTwvYT4m Z3Q7IHdyb3RlOjxvOnA+PC9vOnA+PC9wPg0KPGJsb2NrcXVvdGUgc3R5bGU9ImJvcmRlcjpub25l O2JvcmRlci1sZWZ0OnNvbGlkICNDQ0NDQ0MgMS4wcHQ7cGFkZGluZzowaW4gMGluIDBpbiA2LjBw dDttYXJnaW4tbGVmdDo0LjhwdDttYXJnaW4tcmlnaHQ6MGluIj4NCjxkaXY+DQo8ZGl2Pg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJn aW4tYm90dG9tLWFsdDphdXRvIj5Dcmlja2V0c+KApjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90 dG9tLWFsdDphdXRvIj5JZiBubyBvbmUgaXMgb3IgaGFzIHBsYW5zIGZvciB1c2luZyBJQ0Ugd2l0 aCBUQ1AvQkZDUCwgcGVyaGFwcyBpdCBpcyBiZXN0IHRvIHN0YXRlIHRoYXQgYXMgb2YgdGhpcyBy ZXYgb2YgdGhlIEJGQ1Agc3BlYywgQkZDUCB3aXRoIFRDUCBjYW5kaWRhdGVzIGlzIG5vdCBkZWZp bmVkLiBGdXR1cmUgdXBkYXRlcw0KIHRvIHRoZSBzcGVjIG1heSBkZWZpbmUgdGhpcyB1c2FnZS48 bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRv cC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+Jm5ic3A7PG86cD48L286cD48 L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87 bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPkNoZWVycyw8bzpwPjwvbzpwPjwvcD4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2lu LWJvdHRvbS1hbHQ6YXV0byI+Q2hhcmxlczxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05v cm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFs dDphdXRvIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjxibG9ja3F1b3RlIHN0eWxlPSJib3JkZXI6 bm9uZTtib3JkZXItbGVmdDpzb2xpZCAjQjVDNERGIDQuNXB0O3BhZGRpbmc6MGluIDBpbiAwaW4g NC4wcHQ7bWFyZ2luLWxlZnQ6My43NXB0O21hcmdpbi10b3A6NS4wcHQ7bWFyZ2luLXJpZ2h0OjBp bjttYXJnaW4tYm90dG9tOjUuMHB0Ij4NCjxkaXYgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci10 b3A6c29saWQgI0I1QzRERiAxLjBwdDtwYWRkaW5nOjMuMHB0IDBpbiAwaW4gMGluIj4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2lu LWJvdHRvbS1hbHQ6YXV0byI+PGI+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OkNhbGlicmkiPkZy b206DQo8L3NwYW4+PC9iPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTpDYWxpYnJpIj5tbXVzaWMg Jmx0OzxhIGhyZWY9Im1haWx0bzptbXVzaWMtYm91bmNlc0BpZXRmLm9yZyIgdGFyZ2V0PSJfYmxh bmsiPm1tdXNpYy1ib3VuY2VzQGlldGYub3JnPC9hPiZndDsgb24gYmVoYWxmIG9mIENoYXJsZXMg RWNrZWwgJmx0OzxhIGhyZWY9Im1haWx0bzplY2tlbGN1QGNpc2NvLmNvbSIgdGFyZ2V0PSJfYmxh bmsiPmVja2VsY3VAY2lzY28uY29tPC9hPiZndDs8YnI+DQo8Yj5EYXRlOiA8L2I+RnJpZGF5LCBE ZWNlbWJlciAyLCAyMDE2IGF0IDQ6MDEgUE08YnI+DQo8Yj5UbzogPC9iPlJvbWFuIFNocG91bnQg Jmx0OzxhIGhyZWY9Im1haWx0bzpyb21hbkB0ZWx1cml4LmNvbSIgdGFyZ2V0PSJfYmxhbmsiPnJv bWFuQHRlbHVyaXguY29tPC9hPiZndDs8YnI+DQo8Yj5DYzogPC9iPiZxdW90OzxhIGhyZWY9Im1h aWx0bzppY2VAaWV0Zi5vcmciIHRhcmdldD0iX2JsYW5rIj5pY2VAaWV0Zi5vcmc8L2E+JnF1b3Q7 ICZsdDs8YSBocmVmPSJtYWlsdG86aWNlQGlldGYub3JnIiB0YXJnZXQ9Il9ibGFuayI+aWNlQGll dGYub3JnPC9hPiZndDssICZxdW90OzxhIGhyZWY9Im1haWx0bzpiZmNwYmlzQGlldGYub3JnIiB0 YXJnZXQ9Il9ibGFuayI+YmZjcGJpc0BpZXRmLm9yZzwvYT4mcXVvdDsgJmx0OzxhIGhyZWY9Im1h aWx0bzpiZmNwYmlzQGlldGYub3JnIiB0YXJnZXQ9Il9ibGFuayI+YmZjcGJpc0BpZXRmLm9yZzwv YT4mZ3Q7LA0KIENocmlzdGVyIEhvbG1iZXJnICZsdDs8YSBocmVmPSJtYWlsdG86Y2hyaXN0ZXIu aG9sbWJlcmdAZXJpY3Nzb24uY29tIiB0YXJnZXQ9Il9ibGFuayI+Y2hyaXN0ZXIuaG9sbWJlcmdA ZXJpY3Nzb24uY29tPC9hPiZndDssICZxdW90OzxhIGhyZWY9Im1haWx0bzptbXVzaWNAaWV0Zi5v cmciIHRhcmdldD0iX2JsYW5rIj5tbXVzaWNAaWV0Zi5vcmc8L2E+JnF1b3Q7ICZsdDs8YSBocmVm PSJtYWlsdG86bW11c2ljQGlldGYub3JnIiB0YXJnZXQ9Il9ibGFuayI+bW11c2ljQGlldGYub3Jn PC9hPiZndDs8YnI+DQo8Yj5TdWJqZWN0OiA8L2I+UmU6IFtNTVVTSUNdIFtiZmNwYmlzXSBtPSBs aW5lIHByb3RvY29sIGluIGNhc2Ugb2YgSUNFPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+ DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1h cmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPiZuYnNwOzxvOnA+ PC9vOnA+PC9wPg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdp bi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPkkgaGF2ZSBubyBleHBl cmllbmNlIHdpdGggSUNFIHdpdGggVENQIGNhbmRpZGF0ZXMgc28gaG9wZWZ1bGx5IG90aGVycyBj YW4gY2hpbWUgaW4gYXMgdG8gd2hhdCB0aGV5IHRoaW5rIGlzIGEgd29ya2FibGUgc29sdXRpb24u DQo8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2lu LXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+Jm5ic3A7PG86cD48L286 cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1 dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPkNoZWVycyw8bzpwPjwvbzpwPjwvcD4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFy Z2luLWJvdHRvbS1hbHQ6YXV0byI+Q2hhcmxlczxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1z b05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9t LWFsdDphdXRvIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjxibG9ja3F1b3RlIHN0eWxlPSJib3Jk ZXI6bm9uZTtib3JkZXItbGVmdDpzb2xpZCAjQjVDNERGIDQuNXB0O3BhZGRpbmc6MGluIDBpbiAw aW4gNC4wcHQ7bWFyZ2luLWxlZnQ6My43NXB0O21hcmdpbi10b3A6NS4wcHQ7bWFyZ2luLXJpZ2h0 OjBpbjttYXJnaW4tYm90dG9tOjUuMHB0Ij4NCjxkaXYgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRl ci10b3A6c29saWQgI0I1QzRERiAxLjBwdDtwYWRkaW5nOjMuMHB0IDBpbiAwaW4gMGluIj4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFy Z2luLWJvdHRvbS1hbHQ6YXV0byI+PGI+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OkNhbGlicmki PkZyb206DQo8L3NwYW4+PC9iPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTpDYWxpYnJpIj5Sb21h biBTaHBvdW50ICZsdDs8YSBocmVmPSJtYWlsdG86cm9tYW5AdGVsdXJpeC5jb20iIHRhcmdldD0i X2JsYW5rIj5yb21hbkB0ZWx1cml4LmNvbTwvYT4mZ3Q7PGJyPg0KPGI+RGF0ZTogPC9iPlRodXJz ZGF5LCBEZWNlbWJlciAxLCAyMDE2IGF0IDEyOjM0IFBNPGJyPg0KPGI+VG86IDwvYj5DaGFybGVz IEVja2VsICZsdDs8YSBocmVmPSJtYWlsdG86ZWNrZWxjdUBjaXNjby5jb20iIHRhcmdldD0iX2Js YW5rIj5lY2tlbGN1QGNpc2NvLmNvbTwvYT4mZ3Q7PGJyPg0KPGI+Q2M6IDwvYj5BbGFuIEZvcmQg Jmx0OzxhIGhyZWY9Im1haWx0bzphbGFuLmZvcmRAZ21haWwuY29tIiB0YXJnZXQ9Il9ibGFuayI+ YWxhbi5mb3JkQGdtYWlsLmNvbTwvYT4mZ3Q7LCAmcXVvdDs8YSBocmVmPSJtYWlsdG86YmZjcGJp c0BpZXRmLm9yZyIgdGFyZ2V0PSJfYmxhbmsiPmJmY3BiaXNAaWV0Zi5vcmc8L2E+JnF1b3Q7ICZs dDs8YSBocmVmPSJtYWlsdG86YmZjcGJpc0BpZXRmLm9yZyIgdGFyZ2V0PSJfYmxhbmsiPmJmY3Bi aXNAaWV0Zi5vcmc8L2E+Jmd0OywgJnF1b3Q7PGEgaHJlZj0ibWFpbHRvOmljZUBpZXRmLm9yZyIg dGFyZ2V0PSJfYmxhbmsiPmljZUBpZXRmLm9yZzwvYT4mcXVvdDsNCiAmbHQ7PGEgaHJlZj0ibWFp bHRvOmljZUBpZXRmLm9yZyIgdGFyZ2V0PSJfYmxhbmsiPmljZUBpZXRmLm9yZzwvYT4mZ3Q7LCAm cXVvdDs8YSBocmVmPSJtYWlsdG86bW11c2ljQGlldGYub3JnIiB0YXJnZXQ9Il9ibGFuayI+bW11 c2ljQGlldGYub3JnPC9hPiZxdW90OyAmbHQ7PGEgaHJlZj0ibWFpbHRvOm1tdXNpY0BpZXRmLm9y ZyIgdGFyZ2V0PSJfYmxhbmsiPm1tdXNpY0BpZXRmLm9yZzwvYT4mZ3Q7LCBDaHJpc3RlciBIb2xt YmVyZyAmbHQ7PGEgaHJlZj0ibWFpbHRvOmNocmlzdGVyLmhvbG1iZXJnQGVyaWNzc29uLmNvbSIg dGFyZ2V0PSJfYmxhbmsiPmNocmlzdGVyLmhvbG1iZXJnQGVyaWNzc29uLmNvbTwvYT4mZ3Q7PGJy Pg0KPGI+U3ViamVjdDogPC9iPlJlOiBbYmZjcGJpc10gW01NVVNJQ10gbT0gbGluZSBwcm90b2Nv bCBpbiBjYXNlIG9mIElDRTwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFy Z2luLWJvdHRvbS1hbHQ6YXV0byI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNv LW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPkNoYXJsZXMsDQo8bzpwPjwvbzpwPjwvcD4NCjxkaXY+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNv LW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8 ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRv O21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj5SRkMgNjU0NCBTZW5kaW5nIE1lZGlhICg8YSBo cmVmPSJodHRwczovL3Rvb2xzLmlldGYub3JnL2h0bWwvcmZjNjU0NCNzZWN0aW9uLTEwLjEiIHRh cmdldD0iX2JsYW5rIj5odHRwczovL3Rvb2xzLmlldGYub3JnL2h0bWwvcmZjNjU0NCNzZWN0aW9u LTEwLjE8L2E+KSZuYnNwO3NheXMgdGhhdCAmcXVvdDs8c3BhbiBzdHlsZT0iZm9udC1zaXplOjEw LjBwdCI+VGhlDQogZnJhbWluZyBkZWZpbmVkIGluIDwvc3Bhbj48YSBocmVmPSJodHRwczovL3Rv b2xzLmlldGYub3JnL2h0bWwvcmZjNDU3MSIgdGFyZ2V0PSJfYmxhbmsiPjxzcGFuIHN0eWxlPSJm b250LXNpemU6MTAuMHB0Ij5SRkMgNDU3MTwvc3Bhbj48L2E+PHNwYW4gc3R5bGU9ImZvbnQtc2l6 ZToxMC4wcHQiPiBNVVNUIGJlIHVzZWQgd2hlbiBzZW5kaW5nIG1lZGlhLiZxdW90OyBUaGlzIG1l YW5zIHRoZSBwcm90b2NvbCB1c2VkIGlzIG5vdCBUQ1AvQkZDUCB3aGljaCBpcw0KIHVzaW5nIGFw cGxpY2F0aW9uIGxldmVsIGZyYW1pbmcuIEkgYmVsaWV2ZSB0aGF0IFNUVU4vTWVkaWEgZGVtdWx0 aXBsZXhpbmcgcmVxdWlyZW1lbnRzIHdvdWxkIHByZXZlbnQgdXNpbmcgVENQL0JGQ1AgZGlyZWN0 bHkgd2l0aCBpY2UgdGNwIGNhbmRpZGF0ZXMgd2l0aG91dCByZWRlc2lnbiBvZiBlaXRoZXIgSUNF IFRDUCBvciBUQ1AvQkZDUC48L3NwYW4+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1h cmdpbi1ib3R0b20tYWx0OmF1dG8iPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2 Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21z by1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdCI+ RnVydGhlcm1vcmUmbmJzcDt0aGVyZSBhcmUgb3RoZXIgaW1wbGllZCBJQ0UgcmVxdWlyZW1lbnRz IHRoYXQgSSBvdXRsaW5lZCBiZWZvcmUgKHN3aXRjaGluZyBiZXR3ZWVuIHVkcCBhbmQgdHBjIGNh bmRpZGF0ZXMsIGV4aXN0ZW5jZSBvZiBTQkMgd2hpY2ggdGVybWluYXRlDQogSUNFIG9ubHkgYnV0 IGRvIG5vdCBzdXBwb3J0IHRoZSBlbWJlZGRlZCBwcm90b2NvbCkgYmVjYXVzZSBvZiB3aGljaCBp Y2UgdGNwIGlzIGNvbnNpZGVyZWQgdW5yZWxpYWJsZSB0cmFuc3BvcnQgYW5kIHdpbGwgcmVxdWly ZSBmcmFnbWVudGF0aW9uIHN1cHBvcnQgYW5kIHJlLXRyYW5zbWl0IHRpbWVycyB0aGF0IGFyZSBu b3QgcGFydCBvZiBUQ1AvQkZDUC48L3NwYW4+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNv LW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8 ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRv O21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBw dCI+UmVnYXJkcyw8L3NwYW4+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28t bWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PGJyIGNsZWFyPSJhbGwiPg0KPG86cD48L286cD48L3A+ DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRv cC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+X19fX19fX19fX19fXzxicj4N ClJvbWFuIFNocG91bnQ8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0 b20tYWx0OmF1dG8iPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29O b3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1h bHQ6YXV0byI+T24gVGh1LCBEZWMgMSwgMjAxNiBhdCAzOjE3IFBNLCBDaGFybGVzIEVja2VsIChl Y2tlbGN1KSAmbHQ7PGEgaHJlZj0ibWFpbHRvOmVja2VsY3VAY2lzY28uY29tIiB0YXJnZXQ9Il9i bGFuayI+ZWNrZWxjdUBjaXNjby5jb208L2E+Jmd0OyB3cm90ZTo8bzpwPjwvbzpwPjwvcD4NCjxi bG9ja3F1b3RlIHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItbGVmdDpzb2xpZCAjQ0NDQ0NDIDEu MHB0O3BhZGRpbmc6MGluIDBpbiAwaW4gNi4wcHQ7bWFyZ2luLWxlZnQ6NC44cHQ7bWFyZ2luLXRv cDo1LjBwdDttYXJnaW4tcmlnaHQ6MGluO21hcmdpbi1ib3R0b206NS4wcHQiPg0KPGRpdj4NCjxk aXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87 bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPlJvbWFuLDxvOnA+PC9vOnA+PC9wPg0KPHAgY2xh c3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4t Ym90dG9tLWFsdDphdXRvIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6 YXV0byI+V2h5IHdvdWxkIHNlbGVjdGluZyBUQ1AvQkZDUCBhcyB0cmFuc3BvcnQgdmlvbGF0ZSBS RkMgNjU0ND8gUGVyaGFwcyBpdCBkb2VzLCBidXQgYWZ0ZXIgYSBxdWljayBzY2FuIEkgYW0gbm90 IHN1cmUgd2h5LjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1z by1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj4mbmJzcDs8 bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRv cC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+Q2hlZXJzLDxvOnA+PC9vOnA+ PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRv O21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj5DaGFybGVzPG86cD48L286cD48L3A+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdp bi1ib3R0b20tYWx0OmF1dG8iPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPGJsb2NrcXVvdGUgc3R5 bGU9ImJvcmRlcjpub25lO2JvcmRlci1sZWZ0OnNvbGlkICNCNUM0REYgNC41cHQ7cGFkZGluZzow aW4gMGluIDBpbiA0LjBwdDttYXJnaW4tbGVmdDozLjc1cHQ7bWFyZ2luLXRvcDo1LjBwdDttYXJn aW4tcmlnaHQ6MGluO21hcmdpbi1ib3R0b206NS4wcHQiPg0KPGRpdiBzdHlsZT0iYm9yZGVyOm5v bmU7Ym9yZGVyLXRvcDpzb2xpZCAjQjVDNERGIDEuMHB0O3BhZGRpbmc6My4wcHQgMGluIDBpbiAw aW4iPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRv O21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48Yj48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6 Q2FsaWJyaSI+RnJvbToNCjwvc3Bhbj48L2I+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OkNhbGli cmkiPlJvbWFuIFNocG91bnQgJmx0OzxhIGhyZWY9Im1haWx0bzpyb21hbkB0ZWx1cml4LmNvbSIg dGFyZ2V0PSJfYmxhbmsiPnJvbWFuQHRlbHVyaXguY29tPC9hPiZndDs8YnI+DQo8Yj5EYXRlOiA8 L2I+VHVlc2RheSwgTm92ZW1iZXIgMjksIDIwMTYgYXQgMTA6MzggQU08YnI+DQo8Yj5UbzogPC9i PkNoYXJsZXMgRWNrZWwgJmx0OzxhIGhyZWY9Im1haWx0bzplY2tlbGN1QGNpc2NvLmNvbSIgdGFy Z2V0PSJfYmxhbmsiPmVja2VsY3VAY2lzY28uY29tPC9hPiZndDs8YnI+DQo8Yj5DYzogPC9iPkFs YW4gRm9yZCAmbHQ7PGEgaHJlZj0ibWFpbHRvOmFsYW4uZm9yZEBnbWFpbC5jb20iIHRhcmdldD0i X2JsYW5rIj5hbGFuLmZvcmRAZ21haWwuY29tPC9hPiZndDssICZxdW90OzxhIGhyZWY9Im1haWx0 bzpiZmNwYmlzQGlldGYub3JnIiB0YXJnZXQ9Il9ibGFuayI+YmZjcGJpc0BpZXRmLm9yZzwvYT4m cXVvdDsgJmx0OzxhIGhyZWY9Im1haWx0bzpiZmNwYmlzQGlldGYub3JnIiB0YXJnZXQ9Il9ibGFu ayI+YmZjcGJpc0BpZXRmLm9yZzwvYT4mZ3Q7LCAmcXVvdDs8YSBocmVmPSJtYWlsdG86aWNlQGll dGYub3JnIiB0YXJnZXQ9Il9ibGFuayI+aWNlQGlldGYub3JnPC9hPiZxdW90Ow0KICZsdDs8YSBo cmVmPSJtYWlsdG86aWNlQGlldGYub3JnIiB0YXJnZXQ9Il9ibGFuayI+aWNlQGlldGYub3JnPC9h PiZndDssICZxdW90OzxhIGhyZWY9Im1haWx0bzptbXVzaWNAaWV0Zi5vcmciIHRhcmdldD0iX2Js YW5rIj5tbXVzaWNAaWV0Zi5vcmc8L2E+JnF1b3Q7ICZsdDs8YSBocmVmPSJtYWlsdG86bW11c2lj QGlldGYub3JnIiB0YXJnZXQ9Il9ibGFuayI+bW11c2ljQGlldGYub3JnPC9hPiZndDssIENocmlz dGVyIEhvbG1iZXJnICZsdDs8YSBocmVmPSJtYWlsdG86Y2hyaXN0ZXIuaG9sbWJlcmdAZXJpY3Nz b24uY29tIiB0YXJnZXQ9Il9ibGFuayI+Y2hyaXN0ZXIuaG9sbWJlcmdAZXJpY3Nzb24uY29tPC9h PiZndDs8YnI+DQo8Yj5TdWJqZWN0OiA8L2I+UmU6IFtiZmNwYmlzXSBbTU1VU0lDXSBtPSBsaW5l IHByb3RvY29sIGluIGNhc2Ugb2YgSUNFPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8 ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRv O21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2 Pg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxl PSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+T24g VHVlLCBOb3YgMjksIDIwMTYgYXQgMTI6NDggUE0sIENoYXJsZXMgRWNrZWwgKGVja2VsY3UpICZs dDs8YSBocmVmPSJtYWlsdG86ZWNrZWxjdUBjaXNjby5jb20iIHRhcmdldD0iX2JsYW5rIj5lY2tl bGN1QGNpc2NvLmNvbTwvYT4mZ3Q7IHdyb3RlOjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rp dj4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj4NCjxibG9ja3F1b3RlIHN0eWxlPSJib3JkZXI6bm9uZTti b3JkZXItbGVmdDpzb2xpZCAjQ0NDQ0NDIDEuMHB0O3BhZGRpbmc6MGluIDBpbiAwaW4gNi4wcHQ7 bWFyZ2luLWxlZnQ6NC44cHQ7bWFyZ2luLXRvcDo1LjBwdDttYXJnaW4tcmlnaHQ6MGluO21hcmdp bi1ib3R0b206NS4wcHQiPg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHls ZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPkl0 IHNlZW1zIHRvIG1lIHRoYXQgdGhlIG1vc3Qgc3RyYWlnaHRmb3J3YXJkIGFwcHJvYWNoIHdvdWxk IGJlIHRvIG1hbmRhdGUgc3VwcG9ydCBmb3IgQkZDUCBvdmVyIFVEUCB3aGVuIHVzaW5nIElDRSwg dXNlIFVEUCBhcyB0aGUgZGVmYXVsdCBjYW5kaWRhdGUsIGFuZCBzaWduYWwgdGhlIEJGQ1AgbS1s aW5lDQogYXMgaWYgaXQgaXMgQkZDUCBvdmVyIFVEUC4gSWYgd2UgY2FuIG1hbmRhdGUgdGhlIHVz ZSBvZiBEVExTLCB0aGF0IHdvdWxkIGJlIGV2ZW4gYmV0dGVyLjxvOnA+PC9vOnA+PC9wPg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJn aW4tYm90dG9tLWFsdDphdXRvIj5UaG91Z2h0cz88bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRv bS1hbHQ6YXV0byI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9ibG9j a3F1b3RlPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRv cC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+Jm5ic3A7PG86cD48L286cD48 L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdp bi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPkkgYWdyZWUuPG86cD48 L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNv LW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPiZuYnNwOzxv OnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9 Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj5UaGUg b25seSBpc3N1ZSB0aGF0IEkgc3RpbGwgaGF2ZSwgaWYgRFRMUyBpcyBub3QgdXNlZCwgd2hhdCBw cm90b2NvbCBpcyB1c2VkIHdoZW4gSUNFIHRjcCBjYW5kaWRhdGUgaXMmbmJzcDtzZWxlY3RlZCBm b3IgdHJhbnNwb3J0LiBJcyB0aGlzIFRDUC9CRkNQICh3aGljaCBnb2VzIGFnYWluc3QgUkZDNjU0 NCkgJm5ic3A7b3INCiBpcyBpdCBVRFAvQkZDUCB3aXRoIFJGQzQ1NzEgZnJhbWluZz8gSWYgaXQg aXMgVURQL0JGQ1Agd2l0aCBSRkM0NTcxIGZyYW1pbmcsIHdoYXQgdHJhbnNwb3J0IHRhZyBzaG91 bGQgYmUgdXNlZCBpbiB0aGUgcmUtSU5WSVRFIHdoaWNoIGlzIHNlbnQgYWZ0ZXIgSUNFIG5vbWlu YXRpb24gd2l0aCBvbmx5IHNlbGVjdGVkIGNhbmRpZGF0ZT8gU2hvdWxkIGl0IGJlIFRDUC9VRFAv QkZDUCBvciBzb21ldGhpbmcgc2ltaWxhcj88bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28t bWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxk aXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87 bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPlJlZ2FyZHMsPG86cD48L286cD48L3A+DQo8L2Rp dj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4t dG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj5fX19fX19fX19fX19fPGJy Pg0KUm9tYW4gU2hwb3VudDxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1h cmdpbi1ib3R0b20tYWx0OmF1dG8iPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rp dj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9ibG9ja3F1b3RlPg0KPC9kaXY+ DQo8L2Rpdj4NCjwvYmxvY2txdW90ZT4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5 bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj4m bmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9ibG9ja3F1b3RlPg0KPC9kaXY+DQo8L2Rp dj4NCjwvYmxvY2txdW90ZT4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Jsb2NrcXVvdGU+DQo8L2Rpdj4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rp dj4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+X19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX188YnI+DQpiZmNwYmlzIG1haWxpbmcgbGlzdDxicj4NCjxh IGhyZWY9Im1haWx0bzpiZmNwYmlzQGlldGYub3JnIiB0YXJnZXQ9Il9ibGFuayI+YmZjcGJpc0Bp ZXRmLm9yZzwvYT48YnI+DQo8YSBocmVmPSJodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xp c3RpbmZvL2JmY3BiaXMiIHRhcmdldD0iX2JsYW5rIj5odHRwczovL3d3dy5pZXRmLm9yZy9tYWls bWFuL2xpc3RpbmZvL2JmY3BiaXM8L2E+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvYmxvY2tx dW90ZT4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+ DQo8L2Rpdj4NCjwvZGl2Pg0KPC9ibG9ja3F1b3RlPg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9ibG9ja3F1b3RlPg0KPC9kaXY+ DQo8L2JvZHk+DQo8L2h0bWw+DQo= --_000_E141AB908F354786B443DF7682F3D5FAciscocom_-- From nobody Mon Jan 23 00:33:43 2017 Return-Path: X-Original-To: ice@ietfa.amsl.com Delivered-To: ice@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EDF081294A1 for ; Mon, 23 Jan 2017 00:33:41 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.221 X-Spam-Level: X-Spam-Status: No, score=-4.221 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wr48EjT3TzE9 for ; Mon, 23 Jan 2017 00:33:40 -0800 (PST) Received: from sessmg23.ericsson.net (sessmg23.ericsson.net [193.180.251.45]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5B18B12949E for ; Mon, 23 Jan 2017 00:33:40 -0800 (PST) X-AuditID: c1b4fb2d-db0c19800000646e-58-5885bfe2d01b Received: from ESESSHC005.ericsson.se (Unknown_Domain [153.88.183.33]) by (Symantec Mail Security) with SMTP id DB.2B.25710.2EFB5885; Mon, 23 Jan 2017 09:33:38 +0100 (CET) Received: from ESESSMB205.ericsson.se ([169.254.5.218]) by ESESSHC005.ericsson.se ([153.88.183.33]) with mapi id 14.03.0319.002; Mon, 23 Jan 2017 09:31:07 +0100 From: =?iso-8859-1?Q?Ari_Ker=E4nen?= To: "ice@ietf.org" Thread-Topic: No ICE WG session planned for IETF 98 Thread-Index: AQHSdVMK+6zaqIsODUuJ6j+zowmUVg== Date: Mon, 23 Jan 2017 08:31:05 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [153.88.183.154] Content-Type: text/plain; charset="iso-8859-1" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFvrFLMWRmVeSWpSXmKPExsUyM2K7ou6j/a0RBj+fKFh8u1BrcW35a1YH Jo8Fm0o9liz5yRTAFMVlk5Kak1mWWqRvl8CV0fTxIWPBH5aKtg0HWRsYvzB3MXJySAiYSFw+ 0cPYxcjFISSwjlHiRXcHE4SzhFHi1rFnbCBVbAL2EpPXfGQEsUUEFCVmtjwD62YW0JS4f3Ih O4gtLKAn8ez6LlaIGmOJnZfXANkcQLaexN/XaiBhFgFVieWr1oGV8wKN7D20kwnEZhQQk/h+ ag0TxEhxiVtP5jNBHCcgsWTPeahDRSVePv7HCmErSSy6/RmqXk/ixtQpbBC2tUTb843sELa2 xLKFr5khdglKnJz5hGUCo8gsJCtmIWmfhaR9FpL2WUjaFzCyrmIULU4tLs5NNzLWSy3KTC4u zs/Ty0st2cQIjJGDW37r7mBc/drxEKMAB6MSD68BY2uEEGtiWXFl7iFGCQ5mJRFelm1AId6U xMqq1KL8+KLSnNTiQ4zSHCxK4rxmK++HCwmkJ5akZqemFqQWwWSZODilGhg1Mm0+cejMyag0 lY2bHW8VzZ93VihjZv+lpxIuImuizmkYhU22vvXD1GXqCi3XKJeIIxzS9paFLievCK9VdpDu etGsML1TR6S84qvVffdI/hSfs+c1rq25slCz+/mDW723Zzb/uPV86rRzHH/KFiw8LhK4pmxl 4oVnK351XK849mqVg/PC92eVWIozEg21mIuKEwHo2HMpjQIAAA== Archived-At: Cc: Peter Thatcher Subject: [Ice] No ICE WG session planned for IETF 98 X-BeenThere: ice@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Interactive Connectivity Establishment \(ICE\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Jan 2017 08:33:42 -0000 Hi all, Seems that none of our active WG documents have any open issues needing fac= e-to-face discussion time, and there are no other documents actively being = discussed, so we are planning to *not* request a session slot at the IETF 9= 8. The deadline for WG session requests is 10th of February so if you believe = there is need for ICE WG f2f-time, please let us know as soon as possible. Note that ICE-bis has been recently updated with quite many modifications a= nd a new version of Trickle ICE will be submitted soon, so please read them= and send your comments to the mailing list. Thanks, Ari & Peter= From nobody Mon Jan 23 11:28:41 2017 Return-Path: X-Original-To: ice@ietfa.amsl.com Delivered-To: ice@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 63B771297C3 for ; Mon, 23 Jan 2017 11:28:40 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -17.72 X-Spam-Level: X-Spam-Status: No, score=-17.72 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, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-3.199, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kCemlsc_H5PW for ; Mon, 23 Jan 2017 11:28:38 -0800 (PST) Received: from alln-iport-6.cisco.com (alln-iport-6.cisco.com [173.37.142.93]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 792551296D8 for ; Mon, 23 Jan 2017 11:28:38 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=9498; q=dns/txt; s=iport; t=1485199718; x=1486409318; h=from:to:subject:date:message-id:references:mime-version; bh=JQE240Kjva+G1mki3KPDxRipTeBffk03ukD8vZQHOz8=; b=VUkSN0SIofbmhSxQYuVAVTmsb6MtCRzY1eRFwsEzQ7kvYFahrTqT21eq FdU2ojHjq9/b0a6Aeg77ui7X0NhdkLqkTEDajrnqgs/KBXAa/oZVvGTIL 5fuK/FcHXF+ZH5hp5rHdi1YecOuVxenImLwab4i+HOcZizZpaGqOVxMZa U=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0CyAQAfWYZY/49dJa1eGQEBAQEBAQEBA?= =?us-ascii?q?QEBBwEBAQEBgz0BAQEBAR9ggQkHg0yKCJIFkAOFK4INLIV2AhqBaT8YAQIBAQE?= =?us-ascii?q?BAQEBYx0LhGkBBiNmAgEZAwECKAMCAgIwFAkIAgQTiQwOrQCCJYpOAQEBAQEBA?= =?us-ascii?q?QMBAQEBAQEBASCGS4IFh2qCUC2CMQWPLIwfAYZhiwiBd1KEPYloknUBDxA4gUc?= =?us-ascii?q?VGCIQAYQoHIFhcwGHDoENAQEB?= X-IronPort-AV: E=Sophos;i="5.33,275,1477958400"; d="scan'208,217";a="376257249" Received: from rcdn-core-7.cisco.com ([173.37.93.143]) by alln-iport-6.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 23 Jan 2017 19:28:37 +0000 Received: from XCH-RTP-020.cisco.com (xch-rtp-020.cisco.com [64.101.220.160]) by rcdn-core-7.cisco.com (8.14.5/8.14.5) with ESMTP id v0NJSbZt017256 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL) for ; Mon, 23 Jan 2017 19:28:37 GMT Received: from xch-rtp-019.cisco.com (64.101.220.159) by XCH-RTP-020.cisco.com (64.101.220.160) with Microsoft SMTP Server (TLS) id 15.0.1210.3; Mon, 23 Jan 2017 14:28:36 -0500 Received: from xch-rtp-019.cisco.com ([64.101.220.159]) by XCH-RTP-019.cisco.com ([64.101.220.159]) with mapi id 15.00.1210.000; Mon, 23 Jan 2017 14:28:36 -0500 From: "Pal Martinsen (palmarti)" To: "ice@ietf.org" Thread-Topic: TLS Candidates Thread-Index: AQHSda7ktWsuPgxC8k2HyWHn5eDITw== Date: Mon, 23 Jan 2017 19:28:36 +0000 Message-ID: <9731EE32-8E08-447A-B028-A9B57ADD1A99@cisco.com> References: <148491768993.13355.16722423940569276403.idtracker@ietfa.amsl.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.61.65.127] Content-Type: multipart/alternative; boundary="_000_9731EE328E08447AB028A9B57ADD1A99ciscocom_" MIME-Version: 1.0 Archived-At: Subject: [Ice] TLS Candidates X-BeenThere: ice@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Interactive Connectivity Establishment \(ICE\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Jan 2017 19:28:40 -0000 --_000_9731EE328E08447AB028A9B57ADD1A99ciscocom_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SGkgYWxsLA0KDQpUaGVyZSBpcyBhIG5lZWQgZm9yIFRMUyBjYW5kaWRhdGVzLiBXZSBkaWQgYW4g aW1wbGVtZW50YXRpb25zLCBzbyB3ZSB0aG91Z2h0IGlzIHdhcyBhIGdvb2QgaWRlYSB0byB3cml0 ZSB1cCBhIGRyYWZ0Lg0KDQpJcyB0aGlzIHNvbWV0aGluZyBvdGhlcnMgYXJlIGludGVyZXN0ZWQg aW4gYXMgd2VsbD8NCihBcyB0aGVyZSBzZWVtcyB0byBiZSBubyBJQ0UgbWVldGluZyBuZXh0IElF VEYgaXQgd291bGQgYmUgbmljZSB0byBnZXQgdGhlIGRpc2N1c3Npb24gc3RhcnRlZCBvbiB0aGUg bGlzdCkNCg0KLi0uDQpQw6VsLUVyaWsNCg0KQmVnaW4gZm9yd2FyZGVkIG1lc3NhZ2U6DQoNCkZy b206IDxpbnRlcm5ldC1kcmFmdHNAaWV0Zi5vcmc8bWFpbHRvOmludGVybmV0LWRyYWZ0c0BpZXRm Lm9yZz4+DQpTdWJqZWN0OiBOZXcgVmVyc2lvbiBOb3RpZmljYXRpb24gZm9yIGRyYWZ0LW1hcnRp bnNlbi1pY2UtdGxzLWNhbmRpZGF0ZXMtMDAudHh0DQpEYXRlOiAyMCBKYW51YXJ5IDIwMTcgYXQg MTQ6MDg6MDkgR01UKzENClRvOiBOYXRoYW4gQnVja2xlcyA8bmJ1Y2tsZXNAY2lzY28uY29tPG1h aWx0bzpuYnVja2xlc0BjaXNjby5jb20+PiwgUGFhbC1FcmlrIE1hcnRpbnNlbiA8cGFsbWFydGlA Y2lzY28uY29tPG1haWx0bzpwYWxtYXJ0aUBjaXNjby5jb20+Pg0KDQoNCkEgbmV3IHZlcnNpb24g b2YgSS1ELCBkcmFmdC1tYXJ0aW5zZW4taWNlLXRscy1jYW5kaWRhdGVzLTAwLnR4dA0KaGFzIGJl ZW4gc3VjY2Vzc2Z1bGx5IHN1Ym1pdHRlZCBieSBQYWFsLUVyaWsgTWFydGluc2VuIGFuZCBwb3N0 ZWQgdG8gdGhlDQpJRVRGIHJlcG9zaXRvcnkuDQoNCk5hbWU6IGRyYWZ0LW1hcnRpbnNlbi1pY2Ut dGxzLWNhbmRpZGF0ZXMNClJldmlzaW9uOiAwMA0KVGl0bGU6IFRMUyBDYW5kaWRhdGVzIGZvciBJ Q0UNCkRvY3VtZW50IGRhdGU6IDIwMTctMDEtMjANCkdyb3VwOiBJbmRpdmlkdWFsIFN1Ym1pc3Np b24NClBhZ2VzOiA2DQpVUkw6ICAgICAgICAgICAgaHR0cHM6Ly93d3cuaWV0Zi5vcmcvaW50ZXJu ZXQtZHJhZnRzL2RyYWZ0LW1hcnRpbnNlbi1pY2UtdGxzLWNhbmRpZGF0ZXMtMDAudHh0DQpTdGF0 dXM6ICAgICAgICAgaHR0cHM6Ly9kYXRhdHJhY2tlci5pZXRmLm9yZy9kb2MvZHJhZnQtbWFydGlu c2VuLWljZS10bHMtY2FuZGlkYXRlcy8NCkh0bWxpemVkOiAgICAgICBodHRwczovL3Rvb2xzLmll dGYub3JnL2h0bWwvZHJhZnQtbWFydGluc2VuLWljZS10bHMtY2FuZGlkYXRlcy0wMA0KDQoNCkFi c3RyYWN0Og0KICBUaGlzIGRvY3VtZW50IGludHJvZHVjZXMgVExTIGNhbmRpZGF0ZXMgdG8gSUNF Lg0KDQoNCg0KDQpQbGVhc2Ugbm90ZSB0aGF0IGl0IG1heSB0YWtlIGEgY291cGxlIG9mIG1pbnV0 ZXMgZnJvbSB0aGUgdGltZSBvZiBzdWJtaXNzaW9uDQp1bnRpbCB0aGUgaHRtbGl6ZWQgdmVyc2lv biBhbmQgZGlmZiBhcmUgYXZhaWxhYmxlIGF0IHRvb2xzLmlldGYub3JnPGh0dHA6Ly90b29scy5p ZXRmLm9yZz4uDQoNClRoZSBJRVRGIFNlY3JldGFyaWF0DQoNCg0K --_000_9731EE328E08447AB028A9B57ADD1A99ciscocom_ Content-Type: text/html; charset="utf-8" Content-ID: Content-Transfer-Encoding: base64 PGh0bWw+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIgY29udGVudD0i dGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjwvaGVhZD4NCjxib2R5IHN0eWxlPSJ3b3JkLXdy YXA6IGJyZWFrLXdvcmQ7IC13ZWJraXQtbmJzcC1tb2RlOiBzcGFjZTsgLXdlYmtpdC1saW5lLWJy ZWFrOiBhZnRlci13aGl0ZS1zcGFjZTsiIGNsYXNzPSIiPg0KSGkgYWxsLA0KPGRpdiBjbGFzcz0i Ij48YnIgY2xhc3M9IiI+DQo8L2Rpdj4NCjxkaXYgY2xhc3M9IiI+VGhlcmUgaXMgYSBuZWVkIGZv ciBUTFMgY2FuZGlkYXRlcy4gV2UgZGlkIGFuIGltcGxlbWVudGF0aW9ucywgc28gd2UgdGhvdWdo dCBpcyB3YXMgYSBnb29kIGlkZWEgdG8gd3JpdGUgdXAgYSBkcmFmdC48L2Rpdj4NCjxkaXYgY2xh c3M9IiI+PGJyIGNsYXNzPSIiPg0KPC9kaXY+DQo8ZGl2IGNsYXNzPSIiPklzIHRoaXMgc29tZXRo aW5nIG90aGVycyBhcmUgaW50ZXJlc3RlZCBpbiBhcyB3ZWxsPzwvZGl2Pg0KPGRpdiBjbGFzcz0i Ij4oQXMgdGhlcmUgc2VlbXMgdG8gYmUgbm8gSUNFIG1lZXRpbmcgbmV4dCBJRVRGIGl0IHdvdWxk IGJlIG5pY2UgdG8gZ2V0IHRoZSBkaXNjdXNzaW9uIHN0YXJ0ZWQgb24gdGhlIGxpc3QpPC9kaXY+ DQo8ZGl2IGNsYXNzPSIiPjxiciBjbGFzcz0iIj4NCjwvZGl2Pg0KPGRpdiBjbGFzcz0iIj4uLS48 L2Rpdj4NCjxkaXYgY2xhc3M9IiI+UMOlbC1FcmlrPGJyIGNsYXNzPSIiPg0KPGRpdj48YnIgY2xh c3M9IiI+DQo8YmxvY2txdW90ZSB0eXBlPSJjaXRlIiBjbGFzcz0iIj4NCjxkaXYgY2xhc3M9IiI+ QmVnaW4gZm9yd2FyZGVkIG1lc3NhZ2U6PC9kaXY+DQo8YnIgY2xhc3M9IkFwcGxlLWludGVyY2hh bmdlLW5ld2xpbmUiPg0KPGRpdiBzdHlsZT0ibWFyZ2luLXRvcDogMHB4OyBtYXJnaW4tcmlnaHQ6 IDBweDsgbWFyZ2luLWJvdHRvbTogMHB4OyBtYXJnaW4tbGVmdDogMHB4OyIgY2xhc3M9IiI+DQo8 c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6IC13ZWJraXQtc3lzdGVtLWZvbnQsIEhlbHZldGljYSBO ZXVlLCBIZWx2ZXRpY2EsIHNhbnMtc2VyaWY7IGNvbG9yOnJnYmEoMCwgMCwgMCwgMS4wKTsiIGNs YXNzPSIiPjxiIGNsYXNzPSIiPkZyb206DQo8L2I+PC9zcGFuPjxzcGFuIHN0eWxlPSJmb250LWZh bWlseTogLXdlYmtpdC1zeXN0ZW0tZm9udCwgSGVsdmV0aWNhIE5ldWUsIEhlbHZldGljYSwgc2Fu cy1zZXJpZjsiIGNsYXNzPSIiPiZsdDs8YSBocmVmPSJtYWlsdG86aW50ZXJuZXQtZHJhZnRzQGll dGYub3JnIiBjbGFzcz0iIj5pbnRlcm5ldC1kcmFmdHNAaWV0Zi5vcmc8L2E+Jmd0OzxiciBjbGFz cz0iIj4NCjwvc3Bhbj48L2Rpdj4NCjxkaXYgc3R5bGU9Im1hcmdpbi10b3A6IDBweDsgbWFyZ2lu LXJpZ2h0OiAwcHg7IG1hcmdpbi1ib3R0b206IDBweDsgbWFyZ2luLWxlZnQ6IDBweDsiIGNsYXNz PSIiPg0KPHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiAtd2Via2l0LXN5c3RlbS1mb250LCBIZWx2 ZXRpY2EgTmV1ZSwgSGVsdmV0aWNhLCBzYW5zLXNlcmlmOyBjb2xvcjpyZ2JhKDAsIDAsIDAsIDEu MCk7IiBjbGFzcz0iIj48YiBjbGFzcz0iIj5TdWJqZWN0Og0KPC9iPjwvc3Bhbj48c3BhbiBzdHls ZT0iZm9udC1mYW1pbHk6IC13ZWJraXQtc3lzdGVtLWZvbnQsIEhlbHZldGljYSBOZXVlLCBIZWx2 ZXRpY2EsIHNhbnMtc2VyaWY7IiBjbGFzcz0iIj48YiBjbGFzcz0iIj5OZXcgVmVyc2lvbiBOb3Rp ZmljYXRpb24gZm9yIGRyYWZ0LW1hcnRpbnNlbi1pY2UtdGxzLWNhbmRpZGF0ZXMtMDAudHh0PC9i PjxiciBjbGFzcz0iIj4NCjwvc3Bhbj48L2Rpdj4NCjxkaXYgc3R5bGU9Im1hcmdpbi10b3A6IDBw eDsgbWFyZ2luLXJpZ2h0OiAwcHg7IG1hcmdpbi1ib3R0b206IDBweDsgbWFyZ2luLWxlZnQ6IDBw eDsiIGNsYXNzPSIiPg0KPHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiAtd2Via2l0LXN5c3RlbS1m b250LCBIZWx2ZXRpY2EgTmV1ZSwgSGVsdmV0aWNhLCBzYW5zLXNlcmlmOyBjb2xvcjpyZ2JhKDAs IDAsIDAsIDEuMCk7IiBjbGFzcz0iIj48YiBjbGFzcz0iIj5EYXRlOg0KPC9iPjwvc3Bhbj48c3Bh biBzdHlsZT0iZm9udC1mYW1pbHk6IC13ZWJraXQtc3lzdGVtLWZvbnQsIEhlbHZldGljYSBOZXVl LCBIZWx2ZXRpY2EsIHNhbnMtc2VyaWY7IiBjbGFzcz0iIj4yMCBKYW51YXJ5IDIwMTcgYXQgMTQ6 MDg6MDkgR01UJiM0MzsxPGJyIGNsYXNzPSIiPg0KPC9zcGFuPjwvZGl2Pg0KPGRpdiBzdHlsZT0i bWFyZ2luLXRvcDogMHB4OyBtYXJnaW4tcmlnaHQ6IDBweDsgbWFyZ2luLWJvdHRvbTogMHB4OyBt YXJnaW4tbGVmdDogMHB4OyIgY2xhc3M9IiI+DQo8c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6IC13 ZWJraXQtc3lzdGVtLWZvbnQsIEhlbHZldGljYSBOZXVlLCBIZWx2ZXRpY2EsIHNhbnMtc2VyaWY7 IGNvbG9yOnJnYmEoMCwgMCwgMCwgMS4wKTsiIGNsYXNzPSIiPjxiIGNsYXNzPSIiPlRvOg0KPC9i Pjwvc3Bhbj48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6IC13ZWJraXQtc3lzdGVtLWZvbnQsIEhl bHZldGljYSBOZXVlLCBIZWx2ZXRpY2EsIHNhbnMtc2VyaWY7IiBjbGFzcz0iIj5OYXRoYW4gQnVj a2xlcyAmbHQ7PGEgaHJlZj0ibWFpbHRvOm5idWNrbGVzQGNpc2NvLmNvbSIgY2xhc3M9IiI+bmJ1 Y2tsZXNAY2lzY28uY29tPC9hPiZndDssIFBhYWwtRXJpayBNYXJ0aW5zZW4gJmx0OzxhIGhyZWY9 Im1haWx0bzpwYWxtYXJ0aUBjaXNjby5jb20iIGNsYXNzPSIiPnBhbG1hcnRpQGNpc2NvLmNvbTwv YT4mZ3Q7PGJyIGNsYXNzPSIiPg0KPC9zcGFuPjwvZGl2Pg0KPGJyIGNsYXNzPSIiPg0KPGRpdiBj bGFzcz0iIj4NCjxkaXYgY2xhc3M9IiI+PGJyIGNsYXNzPSIiPg0KQSBuZXcgdmVyc2lvbiBvZiBJ LUQsIGRyYWZ0LW1hcnRpbnNlbi1pY2UtdGxzLWNhbmRpZGF0ZXMtMDAudHh0PGJyIGNsYXNzPSIi Pg0KaGFzIGJlZW4gc3VjY2Vzc2Z1bGx5IHN1Ym1pdHRlZCBieSBQYWFsLUVyaWsgTWFydGluc2Vu IGFuZCBwb3N0ZWQgdG8gdGhlPGJyIGNsYXNzPSIiPg0KSUVURiByZXBvc2l0b3J5LjxiciBjbGFz cz0iIj4NCjxiciBjbGFzcz0iIj4NCk5hbWU6PHNwYW4gY2xhc3M9IkFwcGxlLXRhYi1zcGFuIiBz dHlsZT0id2hpdGUtc3BhY2U6cHJlIj4gPC9zcGFuPjxzcGFuIGNsYXNzPSJBcHBsZS10YWItc3Bh biIgc3R5bGU9IndoaXRlLXNwYWNlOnByZSI+PC9zcGFuPmRyYWZ0LW1hcnRpbnNlbi1pY2UtdGxz LWNhbmRpZGF0ZXM8YnIgY2xhc3M9IiI+DQpSZXZpc2lvbjo8c3BhbiBjbGFzcz0iQXBwbGUtdGFi LXNwYW4iIHN0eWxlPSJ3aGl0ZS1zcGFjZTpwcmUiPiA8L3NwYW4+MDA8YnIgY2xhc3M9IiI+DQpU aXRsZTo8c3BhbiBjbGFzcz0iQXBwbGUtdGFiLXNwYW4iIHN0eWxlPSJ3aGl0ZS1zcGFjZTpwcmUi PiA8L3NwYW4+PHNwYW4gY2xhc3M9IkFwcGxlLXRhYi1zcGFuIiBzdHlsZT0id2hpdGUtc3BhY2U6 cHJlIj48L3NwYW4+VExTIENhbmRpZGF0ZXMgZm9yIElDRTxiciBjbGFzcz0iIj4NCkRvY3VtZW50 IGRhdGU6PHNwYW4gY2xhc3M9IkFwcGxlLXRhYi1zcGFuIiBzdHlsZT0id2hpdGUtc3BhY2U6cHJl Ij4gPC9zcGFuPjIwMTctMDEtMjA8YnIgY2xhc3M9IiI+DQpHcm91cDo8c3BhbiBjbGFzcz0iQXBw bGUtdGFiLXNwYW4iIHN0eWxlPSJ3aGl0ZS1zcGFjZTpwcmUiPiA8L3NwYW4+PHNwYW4gY2xhc3M9 IkFwcGxlLXRhYi1zcGFuIiBzdHlsZT0id2hpdGUtc3BhY2U6cHJlIj48L3NwYW4+SW5kaXZpZHVh bCBTdWJtaXNzaW9uPGJyIGNsYXNzPSIiPg0KUGFnZXM6PHNwYW4gY2xhc3M9IkFwcGxlLXRhYi1z cGFuIiBzdHlsZT0id2hpdGUtc3BhY2U6cHJlIj4gPC9zcGFuPjxzcGFuIGNsYXNzPSJBcHBsZS10 YWItc3BhbiIgc3R5bGU9IndoaXRlLXNwYWNlOnByZSI+PC9zcGFuPjY8YnIgY2xhc3M9IiI+DQpV Ukw6ICZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOzxhIGhyZWY9Imh0dHBzOi8vd3d3LmlldGYub3JnL2ludGVybmV0LWRyYWZ0 cy9kcmFmdC1tYXJ0aW5zZW4taWNlLXRscy1jYW5kaWRhdGVzLTAwLnR4dCIgY2xhc3M9IiI+aHR0 cHM6Ly93d3cuaWV0Zi5vcmcvaW50ZXJuZXQtZHJhZnRzL2RyYWZ0LW1hcnRpbnNlbi1pY2UtdGxz LWNhbmRpZGF0ZXMtMDAudHh0PC9hPjxiciBjbGFzcz0iIj4NClN0YXR1czogJm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7PGEgaHJlZj0iaHR0cHM6Ly9kYXRh dHJhY2tlci5pZXRmLm9yZy9kb2MvZHJhZnQtbWFydGluc2VuLWljZS10bHMtY2FuZGlkYXRlcy8i IGNsYXNzPSIiPmh0dHBzOi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcvZG9jL2RyYWZ0LW1hcnRpbnNl bi1pY2UtdGxzLWNhbmRpZGF0ZXMvPC9hPjxiciBjbGFzcz0iIj4NCkh0bWxpemVkOiAmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDs8YSBocmVmPSJodHRwczovL3Rvb2xzLmlldGYu b3JnL2h0bWwvZHJhZnQtbWFydGluc2VuLWljZS10bHMtY2FuZGlkYXRlcy0wMCIgY2xhc3M9IiI+ aHR0cHM6Ly90b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0LW1hcnRpbnNlbi1pY2UtdGxzLWNhbmRp ZGF0ZXMtMDA8L2E+PGJyIGNsYXNzPSIiPg0KPGJyIGNsYXNzPSIiPg0KPGJyIGNsYXNzPSIiPg0K QWJzdHJhY3Q6PGJyIGNsYXNzPSIiPg0KJm5ic3A7Jm5ic3A7VGhpcyBkb2N1bWVudCBpbnRyb2R1 Y2VzIFRMUyBjYW5kaWRhdGVzIHRvIElDRS48YnIgY2xhc3M9IiI+DQo8YnIgY2xhc3M9IiI+DQo8 YnIgY2xhc3M9IiI+DQo8YnIgY2xhc3M9IiI+DQo8YnIgY2xhc3M9IiI+DQpQbGVhc2Ugbm90ZSB0 aGF0IGl0IG1heSB0YWtlIGEgY291cGxlIG9mIG1pbnV0ZXMgZnJvbSB0aGUgdGltZSBvZiBzdWJt aXNzaW9uPGJyIGNsYXNzPSIiPg0KdW50aWwgdGhlIGh0bWxpemVkIHZlcnNpb24gYW5kIGRpZmYg YXJlIGF2YWlsYWJsZSBhdCA8YSBocmVmPSJodHRwOi8vdG9vbHMuaWV0Zi5vcmciIGNsYXNzPSIi Pg0KdG9vbHMuaWV0Zi5vcmc8L2E+LjxiciBjbGFzcz0iIj4NCjxiciBjbGFzcz0iIj4NClRoZSBJ RVRGIFNlY3JldGFyaWF0PGJyIGNsYXNzPSIiPg0KPGJyIGNsYXNzPSIiPg0KPC9kaXY+DQo8L2Rp dj4NCjwvYmxvY2txdW90ZT4NCjwvZGl2Pg0KPGJyIGNsYXNzPSIiPg0KPC9kaXY+DQo8L2JvZHk+ DQo8L2h0bWw+DQo= --_000_9731EE328E08447AB028A9B57ADD1A99ciscocom_-- From nobody Mon Jan 23 11:44:13 2017 Return-Path: X-Original-To: ice@ietfa.amsl.com Delivered-To: ice@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 769C81297EE for ; Mon, 23 Jan 2017 11:44:12 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.099 X-Spam-Level: X-Spam-Status: No, score=-2.099 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_SORBS_SPAM=0.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=telurix-com.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id iIRo4UVnQl71 for ; Mon, 23 Jan 2017 11:44:10 -0800 (PST) Received: from mail-qt0-x231.google.com (mail-qt0-x231.google.com [IPv6:2607:f8b0:400d:c0d::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 613D11297E9 for ; Mon, 23 Jan 2017 11:44:10 -0800 (PST) Received: by mail-qt0-x231.google.com with SMTP id v23so142332755qtb.0 for ; Mon, 23 Jan 2017 11:44:10 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=telurix-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=uGEIf3cfwrOOdDTIchwegH95HOKMlyPAzdi87D7Br80=; b=MOLr1dblVLS85sOWOfAWzKD71XtpjQNC3iynPzePnSEWCQkE/YkKVAbjUCEXYZu+xg jNzU7ZNGAk1XpjEHkfCtMRJkXlqP2wWUwfWYnFbjuX/tLW0MB8/vvjw6rxCCZ9pjcoQJ x5r7cyPxUD2Y9DJp0+B03sZWValebnkTBFZcm3wqWVbTD5g+wg9P33kClPWi3onR1fGh nmszqbW+ZeBDx/RYOcKReD313z/mZPJ7ffFk3gy7kl1THOZHvEAQE/q3zTmhTnktQdK1 Bm2+QKy43Dx1S1Fhde3ggPtP4/SKOnnSYqdt2snRi4ZlwDu9eyWpM9hj7Bg1awBbZo6L z2vA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=uGEIf3cfwrOOdDTIchwegH95HOKMlyPAzdi87D7Br80=; b=j4ovyWHM0MtOJjri02fM6TchOqg8IiOxf40ctadAIofVmNWsr7iiQor9a2ZYT5tAxP t4Y15mDQ0luQSZ4wDr9Ke6crPwaSgIO1Rta2UZixuz+0wYCvnWYyUSe1GrUVWisLVmsr P6MAiuoLY0RHGLGzdIGKU3jWPTM400e0grlbxHx2P0jpD+zKhRESfmUVuemsbSLNEsYG SXdZM7L4e/QIBJT+/9e/jB3t2Ia1EGaaZ0CObVnRJlXNVU4/L37V7fv39gYxHb2tlq1T HoqJI/s+ibl/Cah39a2K5mRqbQNxZsx1Ez94/L/dsG2aMxh2Lq7xbyPXoyCvO7uN61IS 3gpQ== X-Gm-Message-State: AIkVDXIy4/xrWdKqDcyKe73PDl2T57GfwEb/VLU9b4xw6W2bIu7WjyBPSbUCuwfvkW10ow== X-Received: by 10.55.12.67 with SMTP id 64mr25089746qkm.171.1485200649021; Mon, 23 Jan 2017 11:44:09 -0800 (PST) Received: from mail-qt0-f173.google.com (mail-qt0-f173.google.com. [209.85.216.173]) by smtp.gmail.com with ESMTPSA id l51sm13981255qtb.13.2017.01.23.11.44.08 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 23 Jan 2017 11:44:08 -0800 (PST) Received: by mail-qt0-f173.google.com with SMTP id x49so141557336qtc.2 for ; Mon, 23 Jan 2017 11:44:08 -0800 (PST) X-Received: by 10.200.55.173 with SMTP id d42mr24472812qtc.168.1485200647953; Mon, 23 Jan 2017 11:44:07 -0800 (PST) MIME-Version: 1.0 Received: by 10.12.131.66 with HTTP; Mon, 23 Jan 2017 11:44:07 -0800 (PST) In-Reply-To: <9731EE32-8E08-447A-B028-A9B57ADD1A99@cisco.com> References: <148491768993.13355.16722423940569276403.idtracker@ietfa.amsl.com> <9731EE32-8E08-447A-B028-A9B57ADD1A99@cisco.com> From: Roman Shpount Date: Mon, 23 Jan 2017 14:44:07 -0500 X-Gmail-Original-Message-ID: Message-ID: To: "Pal Martinsen (palmarti)" Content-Type: multipart/alternative; boundary=001a113e609a0aad5c0546c839b4 Archived-At: Cc: "ice@ietf.org" Subject: Re: [Ice] TLS Candidates X-BeenThere: ice@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Interactive Connectivity Establishment \(ICE\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Jan 2017 19:44:12 -0000 --001a113e609a0aad5c0546c839b4 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable This is something we are interested in as well. We had looked at TLS ICE candidates to help traverse some of the more restrictive firewalls. Regards, _____________ Roman Shpount On Mon, Jan 23, 2017 at 2:28 PM, Pal Martinsen (palmarti) < palmarti@cisco.com> wrote: > Hi all, > > There is a need for TLS candidates. We did an implementations, so we > thought is was a good idea to write up a draft. > > Is this something others are interested in as well? > (As there seems to be no ICE meeting next IETF it would be nice to get th= e > discussion started on the list) > > .-. > P=C3=A5l-Erik > > Begin forwarded message: > > *From: * > *Subject: **New Version Notification for > draft-martinsen-ice-tls-candidates-00.txt* > *Date: *20 January 2017 at 14:08:09 GMT+1 > *To: *Nathan Buckles , Paal-Erik Martinsen < > palmarti@cisco.com> > > > A new version of I-D, draft-martinsen-ice-tls-candidates-00.txt > has been successfully submitted by Paal-Erik Martinsen and posted to the > IETF repository. > > Name: draft-martinsen-ice-tls-candidates > Revision: 00 > Title: TLS Candidates for ICE > Document date: 2017-01-20 > Group: Individual Submission > Pages: 6 > URL: https://www.ietf.org/internet-drafts/draft- > martinsen-ice-tls-candidates-00.txt > Status: https://datatracker.ietf.org/doc/draft-martinsen- > ice-tls-candidates/ > Htmlized: https://tools.ietf.org/html/draft-martinsen-ice-tls- > candidates-00 > > > Abstract: > This document introduces TLS candidates to ICE. > > > > > Please note that it may take a couple of minutes from the time of > submission > until the htmlized version and diff are available at tools.ietf.org. > > The IETF Secretariat > > > > _______________________________________________ > Ice mailing list > Ice@ietf.org > https://www.ietf.org/mailman/listinfo/ice > > --001a113e609a0aad5c0546c839b4 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
This is something we are interested in as well. We had loo= ked at TLS ICE candidates to help traverse some of the more restrictive fir= ewalls.

Regards,
<= br clear=3D"all">
_____________
Roman Shpount

On Mon, Jan 23, 2017 at 2:28 PM, Pal Martins= en (palmarti) <palmarti@cisco.com> wrote:
Hi all,

There is a need for TLS candidates. We did an implementations, so we t= hought is was a good idea to write up a draft.

Is this something others are interested in as well?
(As there seems to be no ICE meeting next IETF it would be nice to get= the discussion started on the list)

.-.
P=C3=A5l-Erik

Begin forwarded message:

Subject: New Version Notification for draft-martinsen-ice-tls= -candidates-00.txt
Date: 20 January 2017 at 14:08:09 GMT+1
To: Nathan Buckles <nbuckles@cisco.com>, Paal-Erik Martinsen <palmarti@cisco.com= >


A new version of I-D, draft-martinsen-ice-tls-candidates-00.txt
has been successfully submitted by Paal-Erik Martinsen and posted to the IETF repository.

Name: draft-martinsen-ice-tls-candidates=
Revision: 00
Title: TLS Candidates for ICE
Document date: 2017-01-20
Group: Individual Submission
Pages: 6
URL: =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0https://www.ietf.org/internet-drafts/dra= ft-martinsen-ice-tls-candidates-00.txt
Status: =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0https://datatracker.ietf.org/doc/draft-martinsen-ice-tls-can= didates/
Htmlized: =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0https://= tools.ietf.org/html/draft-martinsen-ice-tls-candidates-00


Abstract:
=C2=A0=C2=A0This document introduces TLS candidates to ICE.




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.

The IETF Secretariat



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


--001a113e609a0aad5c0546c839b4-- From nobody Mon Jan 23 12:13:53 2017 Return-Path: X-Original-To: ice@ietfa.amsl.com Delivered-To: ice@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5F16F129C4B for ; Mon, 23 Jan 2017 12:13:52 -0800 (PST) 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, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=jive-com.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id c0j_euzdqxG4 for ; Mon, 23 Jan 2017 12:13:51 -0800 (PST) Received: from mail-qt0-x22f.google.com (mail-qt0-x22f.google.com [IPv6:2607:f8b0:400d:c0d::22f]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AC7E4129C55 for ; Mon, 23 Jan 2017 12:12:16 -0800 (PST) Received: by mail-qt0-x22f.google.com with SMTP id v23so143734259qtb.0 for ; Mon, 23 Jan 2017 12:12:16 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=jive-com.20150623.gappssmtp.com; s=20150623; h=subject:to:references:cc:from:message-id:date:user-agent :mime-version:in-reply-to:content-transfer-encoding; bh=HjA+DsZkhCFT+g29oyqUxtPBWH5K1Maw5UqUTmPAydg=; b=06jYZWFi5nNQtCEZG8h3bd+sFah5cE48tdA+JiYl2xD/exkPqHeP1qcwSOSYGPFUTP CKXG/haZ5yvrbTEyqeuRo7gxlLBSvZUNK8uV3+UiubD/tbY89P0ZaYHCUB9JLVxN+7zt YS6yPIICpmcbjXfq23h9xIYZyMBreOGo0W/5Pw4++5sM7QA/slISi9VYZBih6S71wXgk rJNE6jdp04rkL9XkNKh/WNnaTlN6TbbYCgZpTpLSNY5aS4Vwvw9S0wIWVvmXPY70PRj5 8tmB7PCTMb3wHOMonidNWjVt6uDN1qGPhlg4v1DamkrdGn9GvyhEeGCZKycoduISV78Y GJ0Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:references:cc:from:message-id:date :user-agent:mime-version:in-reply-to:content-transfer-encoding; bh=HjA+DsZkhCFT+g29oyqUxtPBWH5K1Maw5UqUTmPAydg=; b=iT1o7nVNlLtyoGsMqbM0iNw0pqr5mqjOT0M90mphCj2IKEVUkfrOig1L/YTBdmk4lq pmYaL6cHFwLZnc7xUgsifasC+x1+2G0rzvQFW40gUyQWnEMuVsv9EGmEAfMPunetEB4v yEaC9VLl9+y62qZ14OFL0jVfFqHdC/4ASbaK6MZvMIaLDCaeLtsPbQSKzFm6KNsY0jZw WotVr5HeT2KF3pHDaSgsRcMH93mKFhes8cL3fRKwIq+iuu1gIc+RQw+CM79xFr/ilril 5YGJukvqrAKxt+bi9nOReYFDtYukO6Nlm/I3uzrdzKHosOLePhQl4g4u9259BeTAjp96 SSwg== X-Gm-Message-State: AIkVDXJRzKNQqrRZOzvMQbBOGT/6bEgCQoBmRYv8/yhEsPFTV1d3g927EStrnxvnscYTkAezewHcKw2eCTkAjIWgzFJ/FAmLhqniMFeaKsgez0y0XavCiT8gRWsdnc3xxbwiAUnsT6UZQwv0y7Y30isRiohlcTzI24UgNOO8eg== X-Received: by 10.237.34.125 with SMTP id o58mr25066683qtc.95.1485202335374; Mon, 23 Jan 2017 12:12:15 -0800 (PST) Received: from MacBook-Pro-de-Simon.local ([2001:470:b161:0:c4db:a443:8736:3b14]) by smtp.gmail.com with ESMTPSA id w44sm6712748qta.4.2017.01.23.12.12.14 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 23 Jan 2017 12:12:14 -0800 (PST) To: Roman Shpount , "Pal Martinsen (palmarti)" References: <148491768993.13355.16722423940569276403.idtracker@ietfa.amsl.com> <9731EE32-8E08-447A-B028-A9B57ADD1A99@cisco.com> From: Simon Perreault Message-ID: Date: Mon, 23 Jan 2017 15:12:13 -0500 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.11; rv:45.0) Gecko/20100101 Thunderbird/45.6.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 8bit Archived-At: Cc: "ice@ietf.org" Subject: Re: [Ice] TLS Candidates X-BeenThere: ice@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Interactive Connectivity Establishment \(ICE\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Jan 2017 20:13:52 -0000 Le 2017-01-23 à 14:44, Roman Shpount a écrit : > This is something we are interested in as well. We had looked at TLS ICE > candidates to help traverse some of the more restrictive firewalls. Interesting! Pål-Erik, is your use case also about firewall traversal? -- Simon Perreault Director of Engineering, Platform | Jive Communications, Inc. https://jive.com | +1 418 478 0989 ext. 1241 | sperreault@jive.com From nobody Tue Jan 24 03:57:39 2017 Return-Path: X-Original-To: ice@ietfa.amsl.com Delivered-To: ice@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 09B8B129581 for ; Tue, 24 Jan 2017 03:57:37 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -17.721 X-Spam-Level: X-Spam-Status: No, score=-17.721 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-3.199, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id haZcseP2v5U0 for ; Tue, 24 Jan 2017 03:57:36 -0800 (PST) Received: from alln-iport-2.cisco.com (alln-iport-2.cisco.com [173.37.142.89]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C68E41294F8 for ; Tue, 24 Jan 2017 03:57:35 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1204; q=dns/txt; s=iport; t=1485259055; x=1486468655; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=OQeFvjCfhNycTE3ADUcX/POV0E+Sn4mTJ/eM28xr1Pk=; b=BmQTTvG4EYPRJJhYIR2gEVf2iyjQtWU2C1db5SNhZfJegAwMbwTlA68E jSwoK7JTrEx39lsn6IsNlTBQCntVibzcNCWu+IR1lXKdOVIi/A3qvvuon EPDTdoiP7OD4AYjAfpSFcqskhJR2FYIBjKStDjO6kj+xlOMBOBKMjp704 4=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0CoBABCQIdY/4ENJK1bAxkBAQEBAQEBA?= =?us-ascii?q?QEBAQcBAQEBAYM0AQEBAQEfYIEJB4NMm3AflzsihgACGoF6QhUBAgEBAQEBAQF?= =?us-ascii?q?iKEIOhBkBAQEDASMRRQULAgEIDgoCAiYCAgIwFRACBA4FiRIIrVWCJYpbAQEBA?= =?us-ascii?q?QEBAQEBAQEBAQEBAQEBAQEBGAWBC4VAggUIgmKESRcKJoI/LoIxBZtNAYZhiwq?= =?us-ascii?q?QbpJ2ATUigUgVSgGGKHODWIJwgQ0BAQE?= X-IronPort-AV: E=Sophos;i="5.33,278,1477958400"; d="scan'208";a="375027374" Received: from alln-core-9.cisco.com ([173.36.13.129]) by alln-iport-2.cisco.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 24 Jan 2017 11:57:35 +0000 Received: from XCH-RTP-016.cisco.com (xch-rtp-016.cisco.com [64.101.220.156]) by alln-core-9.cisco.com (8.14.5/8.14.5) with ESMTP id v0OBvYKv032003 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Tue, 24 Jan 2017 11:57:35 GMT Received: from xch-rtp-019.cisco.com (64.101.220.159) by XCH-RTP-016.cisco.com (64.101.220.156) with Microsoft SMTP Server (TLS) id 15.0.1210.3; Tue, 24 Jan 2017 06:57:34 -0500 Received: from xch-rtp-019.cisco.com ([64.101.220.159]) by XCH-RTP-019.cisco.com ([64.101.220.159]) with mapi id 15.00.1210.000; Tue, 24 Jan 2017 06:57:33 -0500 From: "Pal Martinsen (palmarti)" To: Simon Perreault Thread-Topic: [Ice] TLS Candidates Thread-Index: AQHSda7kVoaWhrafREGY+pScEtsCSKFGypKAgAAH2YCAAQgggA== Date: Tue, 24 Jan 2017 11:57:33 +0000 Message-ID: References: <148491768993.13355.16722423940569276403.idtracker@ietfa.amsl.com> <9731EE32-8E08-447A-B028-A9B57ADD1A99@cisco.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.61.211.89] Content-Type: text/plain; charset="utf-8" Content-ID: <00C300B6907BE54B8DEA23927DCE1C77@emea.cisco.com> Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: Cc: Roman Shpount , "ice@ietf.org" Subject: Re: [Ice] TLS Candidates X-BeenThere: ice@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Interactive Connectivity Establishment \(ICE\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 Jan 2017 11:57:37 -0000 DQo+IE9uIDIzIEphbiAyMDE3LCBhdCAyMToxMiwgU2ltb24gUGVycmVhdWx0IDxzcGVycmVhdWx0 QGppdmUuY29tPiB3cm90ZToNCj4gDQo+IExlIDIwMTctMDEtMjMgw6AgMTQ6NDQsIFJvbWFuIFNo cG91bnQgYSDDqWNyaXQgOg0KPj4gVGhpcyBpcyBzb21ldGhpbmcgd2UgYXJlIGludGVyZXN0ZWQg aW4gYXMgd2VsbC4gV2UgaGFkIGxvb2tlZCBhdCBUTFMgSUNFDQo+PiBjYW5kaWRhdGVzIHRvIGhl bHAgdHJhdmVyc2Ugc29tZSBvZiB0aGUgbW9yZSByZXN0cmljdGl2ZSBmaXJld2FsbHMuDQo+IA0K PiBJbnRlcmVzdGluZyENCj4gDQo+IFDDpWwtRXJpaywgaXMgeW91ciB1c2UgY2FzZSBhbHNvIGFi b3V0IGZpcmV3YWxsIHRyYXZlcnNhbD8NCg0KWWVzLg0KDQpNYWluIHVzZS1jYXNlIGlzIHdoZXJl IHdlIHRlcm1pbmF0ZSBtZWRpYSBhdCBhIElDRS1saXRlIG5vZGUgYW5kIGRvIG5vdCB3YW50IHRv IHVzZSBhIFRVUk4gcmVsYXkuDQooSW4gdGhpcyBjYXNlIHdlIGRvIG5vdCB3YW50IHRoZSBleHRy YSBjb21wbGV4aXR5IHJ1bm5pbmcgYSBzZXQgb2YgVFVSTiBzZXJ2ZXJzIGdpdmVzIHVzKQ0KDQpB IGxvdCBvZiBlbnRlcnByaXNlcyBzZWVtcyB0byBsb2NrIGRvd24gdG8gVExTIDQ0MyBhbmQgZXZl biBhIEhUVFAgcHJveHkuDQooUHJveGllcyBhcmUgYnJpZWZseSBtZW50aW9uZWQgaW4gdGhlIGRy YWZ0KQ0KDQouLS4NClDDpWwtRXJpaw0KDQo+IA0KPiAtLSANCj4gU2ltb24gUGVycmVhdWx0DQo+ IERpcmVjdG9yIG9mIEVuZ2luZWVyaW5nLCBQbGF0Zm9ybSB8IEppdmUgQ29tbXVuaWNhdGlvbnMs IEluYy4NCj4gaHR0cHM6Ly9qaXZlLmNvbSB8ICsxIDQxOCA0NzggMDk4OSBleHQuIDEyNDEgfCBz cGVycmVhdWx0QGppdmUuY29tDQoNCg== From nobody Tue Jan 24 13:22:08 2017 Return-Path: X-Original-To: ice@ietfa.amsl.com Delivered-To: ice@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 60F351297F0 for ; Tue, 24 Jan 2017 13:22:07 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.899 X-Spam-Level: X-Spam-Status: No, score=-5.899 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, RP_MATCHES_RCVD=-3.199, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=google.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LVaC_n1NRTbt for ; Tue, 24 Jan 2017 13:22:05 -0800 (PST) Received: from mail-io0-x22b.google.com (mail-io0-x22b.google.com [IPv6:2607:f8b0:4001:c06::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 B3E801297E9 for ; Tue, 24 Jan 2017 13:22:05 -0800 (PST) Received: by mail-io0-x22b.google.com with SMTP id j13so145957455iod.3 for ; Tue, 24 Jan 2017 13:22:05 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=C8cdSzLKg1aCKJzblFwafeKnU/Db8RChC1Fi/p71d7E=; b=XeDhb0E18OzPqDaiTrjFPXBnSOE0xK+E9PDy6Ss9Xeb7udCgbdEA0s8uPj4+h2jiIV ER0ykp8BkeKY0kUn971D2QT3Hg9kOIbeZycIr+R3aUCYkV+UdprPEkrZFFQo7lTHVTWt HYa2u8D2qtxSXoRRmFX1r6fClk8VFt44V/L2Ew0+7HAquhCFQ8n19yBESmH+4yZmxLkX 2utzQHGbvSNYud1qhsn7KYB7YVn3POTgUs7gbB0ae/R6hxWH4U9LGCIGwd6CUsRfxYiF FnKO8qn+2SSovUaRwKqMsPZXOcsymXqkooRySr1uScOzoXubynL9bVk3JMjD5YmHNBL9 m+Ug== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=C8cdSzLKg1aCKJzblFwafeKnU/Db8RChC1Fi/p71d7E=; b=t6CTrbkvOusVsVYn0zFmuOSyEv9/OPx2Ad1IXh6bELvxirEPyvU5fZ9c5r55T2eiAh 8/QfVrsDb88yA2E5vaG3vxzitlbUgkuRkiNiL0jK7LJ7HjXDw8huvrlCo/3AwB5dGk3x jpo+dViUNxKFobgf2OmiFCDM5/igz1LG64PNeNJ7wDZcSKrmXZupAtqsllxmGSVeXQqH AJMndUQwSy2uITkGkSjTbYVGcOqgL6AeFDcJTH0wSMcuqhmVQSt8w+dK4lkkXp4DwPbb mKe1pNApBpRK0CJorcjYAYF1vNtApHhm6cdfKdzA65nu7r/k59xWtV90Bws0Uhp9ICk7 TrWQ== X-Gm-Message-State: AIkVDXJ/bXoaeDt9/fZfg2j0HFXYWSEAcN1hMmcxdAkbz/66J7Lup9jJ2OWkaPIj2BuKmKDCJ8Kb+9j54KMOUak/ X-Received: by 10.107.181.200 with SMTP id e191mr26594515iof.217.1485292924741; Tue, 24 Jan 2017 13:22:04 -0800 (PST) MIME-Version: 1.0 References: <148491768993.13355.16722423940569276403.idtracker@ietfa.amsl.com> <9731EE32-8E08-447A-B028-A9B57ADD1A99@cisco.com> In-Reply-To: From: Peter Thatcher Date: Tue, 24 Jan 2017 21:21:53 +0000 Message-ID: To: "Pal Martinsen (palmarti)" , Simon Perreault Content-Type: multipart/alternative; boundary=001a11443b722b170f0546ddb56c Archived-At: Cc: Roman Shpount , "ice@ietf.org" Subject: Re: [Ice] TLS Candidates X-BeenThere: ice@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Interactive Connectivity Establishment \(ICE\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 Jan 2017 21:22:07 -0000 --001a11443b722b170f0546ddb56c Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Our implementation of ICE has a type of candidate called "SSLTCP" which does a fake TLS handshake to get through firewalls that only allow TLS connections. We've been using it for years. And I'm guessing some of our web products would appreciate that being in other browsers as well, so we may be interested in seeing it as part of the standard (or a less fake version of it). But I don't have any stats about how often those work but normal TCP candidates don't, so I can't say for sure how useful it really is. On Tue, Jan 24, 2017 at 3:57 AM Pal Martinsen (palmarti) wrote: > On 23 Jan 2017, at 21:12, Simon Perreault wrote: > > Le 2017-01-23 =C3=A0 14:44, Roman Shpount a =C3=A9crit : >> This is something we are interested in as well. We had looked at TLS ICE >> candidates to help traverse some of the more restrictive firewalls. > > Interesting! > > P=C3=A5l-Erik, is your use case also about firewall traversal? Yes. Main use-case is where we terminate media at a ICE-lite node and do not want to use a TURN relay. (In this case we do not want the extra complexity running a set of TURN servers gives us) A lot of enterprises seems to lock down to TLS 443 and even a HTTP proxy. (Proxies are briefly mentioned in the draft) .-. P=C3=A5l-Erik > > -- > Simon Perreault > Director of Engineering, Platform | Jive Communications, Inc. > https://jive.com | +1 418 478 0989 ext. 1241 <(418)%20478-0989> | sperreault@jive.com _______________________________________________ Ice mailing list Ice@ietf.org https://www.ietf.org/mailman/listinfo/ice --001a11443b722b170f0546ddb56c Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Our implementation of= ICE has a type of candidate called "SSLTCP" which does a fake TL= S handshake to get through firewalls that only allow TLS connections.=C2=A0= We've been using it for years.=C2=A0 And I'm guessing some of our = web products would appreciate that being in other browsers as well, so we m= ay be interested in seeing it as part of the standard (or a less fake versi= on of it).=C2=A0 But I don't have any stats about how often those work = but normal TCP candidates don't, so I can't say for sure how useful= it really is.

On Tue, Jan 24, 2017 at 3:57 AM = Pal Martinsen (palmarti) <palmarti@cisco.com> wrote:

> On 23 Jan 2017, at 21:12, Simon Perreault <sperreault@jive.com> wrote:
>
> Le 2017-01-23 =C3=A0 14:44, Roman Shpount a =C3=A9crit :
>> This is something we are interested in as well. We had looked at T= LS ICE
>> candidates to help traverse some of the more restrictive firewalls= .
>
> Interesting!
>
> P=C3=A5l-Erik, is your use case also about firewall traversal?

Yes.

Main use-case is where we terminate media at a ICE-lite node and do not wan= t to use a TURN relay.
(In this case we do not want the extra complexity running a set of TURN ser= vers gives us)

A lot of enterprises seems to lock down to TLS 443 and even a HTTP proxy. (Proxies are briefly mentioned in the draft)

.-.
P=C3=A5l-Erik

>
> --
> Simon Perreault
> Director of Engineering, Platform | Jive Communications, Inc.
> https://jive.com | +1 418 478 0989 e= xt. 1241 | sperreault@jive.com

_______________________________________________
Ice mailing list
Ice@i= etf.org
https://www.ietf.org/mailman/listinfo/i= ce
--001a11443b722b170f0546ddb56c-- From nobody Tue Jan 24 13:56:42 2017 Return-Path: X-Original-To: ice@ietfa.amsl.com Delivered-To: ice@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E03931293F8 for ; Tue, 24 Jan 2017 13:56:41 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.099 X-Spam-Level: X-Spam-Status: No, score=-2.099 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_SORBS_SPAM=0.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=telurix-com.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8u015fMLs6GY for ; Tue, 24 Jan 2017 13:56:40 -0800 (PST) Received: from mail-yw0-x229.google.com (mail-yw0-x229.google.com [IPv6:2607:f8b0:4002:c05::229]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0FC8E1293FC for ; Tue, 24 Jan 2017 13:56:39 -0800 (PST) Received: by mail-yw0-x229.google.com with SMTP id u68so174880ywg.0 for ; Tue, 24 Jan 2017 13:56:39 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=telurix-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=JyCV8V+ouDzuZGw0X6eF6Fxatm7vuM6CRsTtZUXdMsI=; b=IAqquF0BIvdTwJRxz7AuNKjIe086gyN1m0OjgTQKUwah8P8CHbdLV5reoIa5xbua13 RlDrnvU6NLWNQqySa1BCAGnm2onjJUwQVWmS1QGr+HNxSMFOnpH6tsPVa4FbgY8ozSWz BFPtgkUkLCcm607TahQrYFkeP6Wg/PW+nK5GY4v7Nc4k4q1fMO4bfiCRp07qBYOtVPYC JSdyTGLyiV0csN1rnKOcZ5ENVfzSD6irRne7P75cf7DeK82K2xQz+YhzCsWmopgnwqVG k0ok3enXQA5pMdYOg38IykTP/odrh0U+ng1ZdigxnH0u91RiMdh+NRonm7GlFfqRY3fB ipow== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=JyCV8V+ouDzuZGw0X6eF6Fxatm7vuM6CRsTtZUXdMsI=; b=eq2c0dxjC2EUpKJj4CCRLeQbKblZyQLCzCaq8EZgkYK5+8o6MxXpc160SLQtBXQfiv 11Tu66MWelfDHThEzkjT9WLYPo7Pa38m6s3Au0Ctvybk8K5tby6MN5XEVmq3pwb4/lN5 qU7e/B5umaWvo1UwDs40l1jaW4BW5kMW+4LK850QTaTGJ1zFaIpNiIuWK8F2R2Mq8Vpw FNMrZEkJnEIA74sKmvv3JNIFSqMXrPdoFAO9Kwy+WdFnsvgfe54RKTkSABp68A1Wpp4M hT9NtcHq2nrgy8JzNRhQLakwBNMns6lCk+4rlzxFQ5p5/ItHeD52ncF68siSlOxGS+ML Xo/Q== X-Gm-Message-State: AIkVDXJMmydQbMMs+ItGK3odKTbdJd0mnG49S8yKVYPwkN4gVGhYrlR8p/MxdMDPCzFY3Q== X-Received: by 10.129.101.195 with SMTP id z186mr27704794ywb.340.1485294958775; Tue, 24 Jan 2017 13:55:58 -0800 (PST) Received: from mail-yb0-f181.google.com (mail-yb0-f181.google.com. [209.85.213.181]) by smtp.gmail.com with ESMTPSA id h127sm1149750ywd.20.2017.01.24.13.55.58 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 24 Jan 2017 13:55:58 -0800 (PST) Received: by mail-yb0-f181.google.com with SMTP id j82so313016ybg.1 for ; Tue, 24 Jan 2017 13:55:58 -0800 (PST) X-Received: by 10.55.11.13 with SMTP id 13mr33982502qkl.201.1485294952466; Tue, 24 Jan 2017 13:55:52 -0800 (PST) MIME-Version: 1.0 Received: by 10.12.131.66 with HTTP; Tue, 24 Jan 2017 13:55:51 -0800 (PST) In-Reply-To: References: <148491768993.13355.16722423940569276403.idtracker@ietfa.amsl.com> <9731EE32-8E08-447A-B028-A9B57ADD1A99@cisco.com> From: Roman Shpount Date: Tue, 24 Jan 2017 16:55:51 -0500 X-Gmail-Original-Message-ID: Message-ID: To: Peter Thatcher Content-Type: multipart/alternative; boundary=001a114d7c7a075a9d0546de2e0a Archived-At: Cc: Simon Perreault , "Pal Martinsen \(palmarti\)" , "ice@ietf.org" Subject: Re: [Ice] TLS Candidates X-BeenThere: ice@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Interactive Connectivity Establishment \(ICE\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 Jan 2017 21:56:42 -0000 --001a114d7c7a075a9d0546de2e0a Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable We have encountered a few large corporate installations that only allowed TLS connections to port 443. Running TURNS server on port 443 or nonstandard TLS ICE candidates was the only way to connect calls from these deployments to the outside world. These installation were few thousand seats each and belonged to Fortune 100 company. At least for us it was enough of the incentive to find a solution. Regards, _____________ Roman Shpount On Tue, Jan 24, 2017 at 4:21 PM, Peter Thatcher wrote: > Our implementation of ICE has a type of candidate called "SSLTCP" which > does a fake TLS handshake to get through firewalls that only allow TLS > connections. We've been using it for years. And I'm guessing some of ou= r > web products would appreciate that being in other browsers as well, so we > may be interested in seeing it as part of the standard (or a less fake > version of it). But I don't have any stats about how often those work bu= t > normal TCP candidates don't, so I can't say for sure how useful it really > is. > > On Tue, Jan 24, 2017 at 3:57 AM Pal Martinsen (palmarti) < > palmarti@cisco.com> wrote: > > > > On 23 Jan 2017, at 21:12, Simon Perreault wrote: > > > > Le 2017-01-23 =C3=A0 14:44, Roman Shpount a =C3=A9crit : > >> This is something we are interested in as well. We had looked at TLS I= CE > >> candidates to help traverse some of the more restrictive firewalls. > > > > Interesting! > > > > P=C3=A5l-Erik, is your use case also about firewall traversal? > > Yes. > > Main use-case is where we terminate media at a ICE-lite node and do not > want to use a TURN relay. > (In this case we do not want the extra complexity running a set of TURN > servers gives us) > > A lot of enterprises seems to lock down to TLS 443 and even a HTTP proxy. > (Proxies are briefly mentioned in the draft) > > .-. > P=C3=A5l-Erik > > > > > -- > > Simon Perreault > > Director of Engineering, Platform | Jive Communications, Inc. > > https://jive.com | +1 418 478 0989 ext. 1241 <(418)%20478-0989> | > sperreault@jive.com > > _______________________________________________ > Ice mailing list > Ice@ietf.org > https://www.ietf.org/mailman/listinfo/ice > > --001a114d7c7a075a9d0546de2e0a Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
We have encountered a few large corporate installations th= at only allowed TLS connections to port 443. Running TURNS server on port 4= 43 or nonstandard TLS ICE candidates was the only way to connect calls from= these deployments to the outside world. These installation were few thousa= nd seats each and belonged to Fortune 100 company. At least for us it was e= nough of the incentive to find a solution.

Regards,

_____________
Roman Shpo= unt

On Tue, Jan 24, 2017 at 4:21 PM, Peter Thatc= her <pthatcher@google.com> wrote:
Our implementation of ICE has a type of candidate called "= SSLTCP" which does a fake TLS handshake to get through firewalls that = only allow TLS connections.=C2=A0 We've been using it for years.=C2=A0 = And I'm guessing some of our web products would appreciate that being i= n other browsers as well, so we may be interested in seeing it as part of t= he standard (or a less fake version of it).=C2=A0 But I don't have any = stats about how often those work but normal TCP candidates don't, so I = can't say for sure how useful it really is.

On Tue, Jan 24, 2017 at 3:57 AM Pal Martinsen (palmarti) <= ;palmarti@cisco.com> wrote:

> On 23 Jan 2017, at 21:12, Simon Perreault <= sperreault@jive.com> wrote:
>
> Le 2017-01-23 =C3=A0 14:44, Roman Shpount a =C3=A9crit :
>> This is something we are interested in as well. We had looked at T= LS ICE
>> candidates to help traverse some of the more restrictive firewalls= .
>
> Interesting!
>
> P=C3=A5l-Erik, is your use case also about firewall traversal?

Yes.

Main use-case is where we terminate media at a ICE-lite node and do not wan= t to use a TURN relay.
(In this case we do not want the extra complexity running a set of TURN ser= vers gives us)

A lot of enterprises seems to lock down to TLS 443 and even a HTTP proxy. (Proxies are briefly mentioned in the draft)

.-.
P=C3=A5l-Erik

>
> --
> Simon Perreault
> Director of Engineering, Platform | Jive Communications, Inc.
> https://jive.com | +1 418 478 0989 ext. 1241 | sperreault@jive.com

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

--001a114d7c7a075a9d0546de2e0a-- From nobody Tue Jan 31 18:52:06 2017 Return-Path: X-Original-To: ice@ietf.org Delivered-To: ice@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 4E31B129801; Tue, 31 Jan 2017 18:52:05 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: X-Test-IDTracker: no X-IETF-IDTracker: 6.41.1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <148591752531.5914.16465128025947813650.idtracker@ietfa.amsl.com> Date: Tue, 31 Jan 2017 18:52:05 -0800 Archived-At: Cc: ice@ietf.org Subject: [Ice] I-D Action: draft-ietf-ice-trickle-05.txt X-BeenThere: ice@ietf.org X-Mailman-Version: 2.1.17 List-Id: "Interactive Connectivity Establishment \(ICE\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 01 Feb 2017 02:52:05 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Interactive Connectivity Establishment of the IETF. Title : Trickle ICE: Incremental Provisioning of Candidates for the Interactive Connectivity Establishment (ICE) Protocol Authors : Emil Ivov Eric Rescorla Justin Uberti Peter Saint-Andre Filename : draft-ietf-ice-trickle-05.txt Pages : 27 Date : 2017-01-31 Abstract: This document describes "Trickle ICE", an extension to the Interactive Connectivity Establishment (ICE) protocol that enables ICE agents to send and receive candidates incrementally rather than exchanging complete lists. With such incremental provisioning, ICE agents can begin connectivity checks while they are still gathering candidates and considerably shorten the time necessary for ICE processing to complete. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-ice-trickle/ There's also a htmlized version available at: https://tools.ietf.org/html/draft-ietf-ice-trickle-05 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-ice-trickle-05 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 Tue Jan 31 18:55:34 2017 Return-Path: X-Original-To: ice@ietfa.amsl.com Delivered-To: ice@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4F77112984C for ; Tue, 31 Jan 2017 18:55:33 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=stpeter.im header.b=fJZX04zW; dkim=pass (1024-bit key) header.d=messagingengine.com header.b=OpUKUfGW Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5P1Sra68SSTS for ; Tue, 31 Jan 2017 18:55:31 -0800 (PST) Received: from new2-smtp.messagingengine.com (new2-smtp.messagingengine.com [66.111.4.224]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9623F129801 for ; Tue, 31 Jan 2017 18:55:31 -0800 (PST) Received: from compute2.internal (compute2.nyi.internal [10.202.2.42]) by mailnew.nyi.internal (Postfix) with ESMTP id 180FC1ED0; Tue, 31 Jan 2017 21:55:30 -0500 (EST) Received: from frontend1 ([10.202.2.160]) by compute2.internal (MEProxy); Tue, 31 Jan 2017 21:55:30 -0500 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=stpeter.im; h= content-transfer-encoding:content-type:date:from:in-reply-to :message-id:mime-version:references:subject:to:x-me-sender :x-me-sender:x-sasl-enc:x-sasl-enc; s=mesmtp; bh=UYyuUHF2txHbCzH s7n+h5Xgr7lE=; b=fJZX04zWCYGRSe+esk8ukp/L8rtKelF47FUr5+NCrg2jUVC 4Z2YhrnUTRme74pRXqpVJjZZtJio/aqw+QqGXJdXNBibZGY9oU/cwVSMqu+1nPyv XMT8WF5gkPgieVIwQG6v8IdgR+CLibn+/ssnmjPEXcQjVSEXfvYe7EOmyGPM= DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d= messagingengine.com; h=content-transfer-encoding:content-type :date:from:in-reply-to:message-id:mime-version:references :subject:to:x-me-sender:x-me-sender:x-sasl-enc:x-sasl-enc; s= smtpout; bh=UYyuUHF2txHbCzHs7n+h5Xgr7lE=; b=OpUKUfGWFK8Y7KDng8oK /W650Ifve93vAMa+N8fTLY29zoeOCVTjutO6B6Fekz/4FULkoDtEgnwpNeoh9Pm6 t5vb3Z0tuobaiwc6dDHJ2R0esjvTsxAUmAarKZPBF9aPpfsxFhoxXx0KHXONCDqp Vw0PSOdYf2mGfoXbwLq9814= X-ME-Sender: X-Sasl-enc: oZE4MARLPwa1TZ7C/0N4Gzoro7DU/1xmqELHDq2o9ep2 1485917729 Received: from aither.local (unknown [76.25.4.24]) by mail.messagingengine.com (Postfix) with ESMTPA id 930387E4B0; Tue, 31 Jan 2017 21:55:29 -0500 (EST) To: ice@ietf.org References: <148591752531.5914.16465128025947813650.idtracker@ietfa.amsl.com> From: Peter Saint-Andre Message-ID: Date: Tue, 31 Jan 2017 19:55:28 -0700 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.12; rv:45.0) Gecko/20100101 Thunderbird/45.7.0 MIME-Version: 1.0 In-Reply-To: <148591752531.5914.16465128025947813650.idtracker@ietfa.amsl.com> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [Ice] I-D Action: draft-ietf-ice-trickle-05.txt X-BeenThere: ice@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Interactive Connectivity Establishment \(ICE\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 01 Feb 2017 02:55:33 -0000 On 1/31/17 7:52 PM, internet-drafts@ietf.org wrote: > The IETF datatracker status page for this draft is: > https://datatracker.ietf.org/doc/draft-ietf-ice-trickle/ > > There's also a htmlized version available at: > https://tools.ietf.org/html/draft-ietf-ice-trickle-05 > > A diff from the previous version is available at: > https://www.ietf.org/rfcdiff?url2=draft-ietf-ice-trickle-05 This version addresses almost all feedback received since October. Emil and I are still working on much-improved text for Section 8.1 (pairing new candidates and updating check lists), but we didn't want to hold up publication of the other fixes any further. Thanks! Peter