From nobody Wed Mar 1 00: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 AB1F61294DA for ; Wed, 1 Mar 2017 00:43:59 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.521 X-Spam-Level: X-Spam-Status: No, score=-14.521 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=-0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=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 uyKnli4bIflJ for ; Wed, 1 Mar 2017 00:43:57 -0800 (PST) Received: from rcdn-iport-2.cisco.com (rcdn-iport-2.cisco.com [173.37.86.73]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9C9FF1294BF for ; Wed, 1 Mar 2017 00:43:57 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=15992; q=dns/txt; s=iport; t=1488357837; x=1489567437; h=from:to:subject:date:message-id:references:in-reply-to: mime-version; bh=udShlwQ/nhjfBiu6662mCciy5fYkFgubKbg0Q03md/M=; b=H+oSCeool2GO0JBUpg5rCDiAxClZbd+CyIPzx8Igg+oJBkVSBwyhibBQ TFQ2ekQYo7kdyrRBc5W00a6gjg5or9t/KfERKSHpF8Qfhg8XL/+0lSVTV sLvcGSoh7xHKAV1xRlHspvpEDy6PBOVAp4N7xRlJQZYQ+W1y5HqICAOBN M=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0BCAgAribZY/49dJa1eGQEBAQEBAQEBA?= =?us-ascii?q?QEBBwEBAQEBg1BhgQkHg1SKCJFkiAyHfYUsgg0fAQyEHIFaAhqCFz8YAQIBAQE?= =?us-ascii?q?BAQEBYh0LhHABAQEEAQEhSxsCAQgRAwECKAMCAgIfBgsUCQgCBBMbiUYDFQ6xO?= =?us-ascii?q?oImhzoNg14BAQEBAQEBAQEBAQEBAQEBAQEBAQEdhkyCBYJqglGCIxaCUC6CMQW?= =?us-ascii?q?PVYwZOgGGdIcUhCmBe1OEToNThi2KTIhnAQ8QODxFVBUYJhEBhAQ5HYFhdQGIZ?= =?us-ascii?q?IENAQEB?= X-IronPort-AV: E=Sophos;i="5.35,224,1484006400"; d="scan'208,217";a="217500617" Received: from rcdn-core-7.cisco.com ([173.37.93.143]) by rcdn-iport-2.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 01 Mar 2017 08:43:56 +0000 Received: from XCH-RTP-019.cisco.com (xch-rtp-019.cisco.com [64.101.220.159]) by rcdn-core-7.cisco.com (8.14.5/8.14.5) with ESMTP id v218ht0c002846 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL) for ; Wed, 1 Mar 2017 08:43:56 GMT Received: from xch-rtp-019.cisco.com (64.101.220.159) by XCH-RTP-019.cisco.com (64.101.220.159) with Microsoft SMTP Server (TLS) id 15.0.1210.3; Wed, 1 Mar 2017 03:43:55 -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; Wed, 1 Mar 2017 03:43:55 -0500 From: "Pal Martinsen (palmarti)" To: "ice@ietf.org" Thread-Topic: [Ice] TLS Candidates Thread-Index: AQHSda7kVoaWhrafREGY+pScEtsCSKFuOZiAgBH+xgA= Date: Wed, 1 Mar 2017 08:43:54 +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.197.153] Content-Type: multipart/alternative; boundary="_000_BF16804446C148C2BC6C6C606722CBAEciscocom_" MIME-Version: 1.0 Archived-At: 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: Wed, 01 Mar 2017 08:43:59 -0000 --_000_BF16804446C148C2BC6C6C606722CBAEciscocom_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SGksDQoNClNlZW1zIGxpa2Ugd2UgaGF2ZSByb3VnaCBjb25zZW5zdXMgdGhhdCB0aGlzIGlzIHNv bWV0aGluZyB0aGF0IGlzIHVzZWZ1bC4NCg0KDQpXZSBjdXJyZW50bHkgaGF2ZToNCi0gQSBwcm9i bGVtIHRoYXQgdGhlIFdHIGlzIHdpbGxpbmcgdG8gd29yayBvbiBhbmQgc29sdmUuDQotIEEgZHJh ZnQgdGhhdCBkZXNjcmliZXMgYSBwb3NzaWJsZSBzb2x1dGlvbnMgKFRleHQgYW5kIG90aGVyIGRy YWZ0cyBhcmUgb2YtY291cnNlIHdlbGNvbWUpLg0KLSBBIHdvcmtpbmcgaW1wbGVtZW50YXRpb24u IChMaWJyYXJ5IGlzIG9wZW4gc291cmNlLCBubyBvcGVuIHNvdXJjZSBjbGllbnQgdXNlcyBpdCB5 ZXQuLikNCi0gRGlzY3Vzc2lvbiBvbiBsaXN0IG9uIHdoYXRzIHdvcmtpbmcgYW5kIHdoYXRzIG5v dC4NCg0KU2VlbXMgbGlrZSBhIGdvb2QgcmVjaXBlIGZvciBhIFJGQy4NCg0KV2hhdCBlciBvdXIg b3B0aW9ucyB0byBzcGVlZCB1cCB0aGUgcHJvY2VzcyBzaW5jZSB3ZSBhcmUgbm90IG1lZXRpbmcg ZHVyaW5nIHRoZSBuZXh0IElFVEY/DQpUaGVyZSBpcyBubyBuZWVkIHRvIHJ1c2gsIGJ1dCBhbHdh eXMgZ29vZCB0byBnZXQgd29yayBkb25lIGFuZCBmaW5pc2hlZC4gRXNwZWNpYWxseSBzaW5jZSB0 aGlzIHRvdWNoZXMgb24gY29ubmVjdGl2aXR5IGFuZCBub3Qgb3B0aW1pc2F0aW9uLg0KDQouLS4N ClDDpWwtRXJpaw0KDQpPbiAxNyBGZWIgMjAxNywgYXQgMjI6NTUsIEJlcm5hcmQgQWJvYmEgPGJl cm5hcmQuYWJvYmFAZ21haWwuY29tPG1haWx0bzpiZXJuYXJkLmFib2JhQGdtYWlsLmNvbT4+IHdy b3RlOg0KDQpJIGhhdmUgcmVhZCB0aGlzIGRyYWZ0LCBhbmQgbGlrZSBpdC4gIEluIHByYWN0aWNl IHRoZXJlIGFyZSBlbm91Z2ggY3VzdG9tZXJzIHJlc3RyaWN0aW5nIGNvbm5lY3Rpdml0eSB2aWEg VURQIG9yIFRMUyB0byBtYWtlIGl0IHdvcnRod2hpbGUgdG8gaW1wbGVtZW50IFRMUyBjYW5kaWRh dGVzLg0KDQpNeSBleHBlcmllbmNlIGlzIHRoYXQgY3VzdG9tZXJzIHdobyBvbmx5IGFsbG93IFRM UyB0byBwb3J0IDQ0MyBhbHNvIHRlbmQgdG8gaW1wb3NlIG90aGVyIHJlc3RyaWN0aW9ucywgc3Vj aCBhcyBmb3JjaW5nIGNvbm5lY3Rpb25zIHRocm91Z2ggYW4gSFRUUFMgcHJveHkgb2Ygc29tZSBr aW5kLiAgU28gdGhlIGNvbnNpZGVyYXRpb25zIGRpc2N1c3NlZCBpbiBTZWN0aW9uIDYgYXJlIHF1 aXRlIGltcG9ydGFudC4NCg0KT24gTW9uLCBKYW4gMjMsIDIwMTcgYXQgMTE6MjggQU0sIFBhbCBN YXJ0aW5zZW4gKHBhbG1hcnRpKSA8cGFsbWFydGlAY2lzY28uY29tPG1haWx0bzpwYWxtYXJ0aUBj aXNjby5jb20+PiB3cm90ZToNCkhpIGFsbCwNCg0KVGhlcmUgaXMgYSBuZWVkIGZvciBUTFMgY2Fu ZGlkYXRlcy4gV2UgZGlkIGFuIGltcGxlbWVudGF0aW9ucywgc28gd2UgdGhvdWdodCBpcyB3YXMg YSBnb29kIGlkZWEgdG8gd3JpdGUgdXAgYSBkcmFmdC4NCg0KSXMgdGhpcyBzb21ldGhpbmcgb3Ro ZXJzIGFyZSBpbnRlcmVzdGVkIGluIGFzIHdlbGw/DQooQXMgdGhlcmUgc2VlbXMgdG8gYmUgbm8g SUNFIG1lZXRpbmcgbmV4dCBJRVRGIGl0IHdvdWxkIGJlIG5pY2UgdG8gZ2V0IHRoZSBkaXNjdXNz aW9uIHN0YXJ0ZWQgb24gdGhlIGxpc3QpDQoNCi4tLg0KUMOlbC1FcmlrDQoNCkJlZ2luIGZvcndh cmRlZCBtZXNzYWdlOg0KDQpGcm9tOiA8aW50ZXJuZXQtZHJhZnRzQGlldGYub3JnPG1haWx0bzpp bnRlcm5ldC1kcmFmdHNAaWV0Zi5vcmc+Pg0KU3ViamVjdDogTmV3IFZlcnNpb24gTm90aWZpY2F0 aW9uIGZvciBkcmFmdC1tYXJ0aW5zZW4taWNlLXRscy1jYW5kaWRhdGVzLTAwLnR4dA0KRGF0ZTog MjAgSmFudWFyeSAyMDE3IGF0IDE0OjA4OjA5IEdNVCsxDQpUbzogTmF0aGFuIEJ1Y2tsZXMgPG5i dWNrbGVzQGNpc2NvLmNvbTxtYWlsdG86bmJ1Y2tsZXNAY2lzY28uY29tPj4sIFBhYWwtRXJpayBN YXJ0aW5zZW4gPHBhbG1hcnRpQGNpc2NvLmNvbTxtYWlsdG86cGFsbWFydGlAY2lzY28uY29tPj4N Cg0KDQpBIG5ldyB2ZXJzaW9uIG9mIEktRCwgZHJhZnQtbWFydGluc2VuLWljZS10bHMtY2FuZGlk YXRlcy0wMC50eHQNCmhhcyBiZWVuIHN1Y2Nlc3NmdWxseSBzdWJtaXR0ZWQgYnkgUGFhbC1Fcmlr IE1hcnRpbnNlbiBhbmQgcG9zdGVkIHRvIHRoZQ0KSUVURiByZXBvc2l0b3J5Lg0KDQpOYW1lOiBk cmFmdC1tYXJ0aW5zZW4taWNlLXRscy1jYW5kaWRhdGVzDQpSZXZpc2lvbjogMDANClRpdGxlOiBU TFMgQ2FuZGlkYXRlcyBmb3IgSUNFDQpEb2N1bWVudCBkYXRlOiAyMDE3LTAxLTIwDQpHcm91cDog SW5kaXZpZHVhbCBTdWJtaXNzaW9uDQpQYWdlczogNg0KVVJMOiAgICAgICAgICAgIGh0dHBzOi8v d3d3LmlldGYub3JnL2ludGVybmV0LWRyYWZ0cy9kcmFmdC1tYXJ0aW5zZW4taWNlLXRscy1jYW5k aWRhdGVzLTAwLnR4dA0KU3RhdHVzOiAgICAgICAgIGh0dHBzOi8vZGF0YXRyYWNrZXIuaWV0Zi5v cmcvZG9jL2RyYWZ0LW1hcnRpbnNlbi1pY2UtdGxzLWNhbmRpZGF0ZXMvDQpIdG1saXplZDogICAg ICAgaHR0cHM6Ly90b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0LW1hcnRpbnNlbi1pY2UtdGxzLWNh bmRpZGF0ZXMtMDANCg0KDQpBYnN0cmFjdDoNCiAgVGhpcyBkb2N1bWVudCBpbnRyb2R1Y2VzIFRM UyBjYW5kaWRhdGVzIHRvIElDRS4NCg0KDQoNCg0KUGxlYXNlIG5vdGUgdGhhdCBpdCBtYXkgdGFr ZSBhIGNvdXBsZSBvZiBtaW51dGVzIGZyb20gdGhlIHRpbWUgb2Ygc3VibWlzc2lvbg0KdW50aWwg dGhlIGh0bWxpemVkIHZlcnNpb24gYW5kIGRpZmYgYXJlIGF2YWlsYWJsZSBhdCB0b29scy5pZXRm Lm9yZzxodHRwOi8vdG9vbHMuaWV0Zi5vcmcvPi4NCg0KVGhlIElFVEYgU2VjcmV0YXJpYXQNCg0K DQoNCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQpJY2Ug bWFpbGluZyBsaXN0DQpJY2VAaWV0Zi5vcmc8bWFpbHRvOkljZUBpZXRmLm9yZz4NCmh0dHBzOi8v d3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vaWNlDQoNCg0KDQo= --_000_BF16804446C148C2BC6C6C606722CBAEciscocom_ Content-Type: text/html; charset="utf-8" Content-ID: Content-Transfer-Encoding: base64 PGh0bWw+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIgY29udGVudD0i dGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjwvaGVhZD4NCjxib2R5IHN0eWxlPSJ3b3JkLXdy YXA6IGJyZWFrLXdvcmQ7IC13ZWJraXQtbmJzcC1tb2RlOiBzcGFjZTsgLXdlYmtpdC1saW5lLWJy ZWFrOiBhZnRlci13aGl0ZS1zcGFjZTsiIGNsYXNzPSIiPg0KPGRpdiBjbGFzcz0iIj5IaSw8L2Rp dj4NCjxkaXYgY2xhc3M9IiI+PGJyIGNsYXNzPSIiPg0KPC9kaXY+DQo8ZGl2IGNsYXNzPSIiPlNl ZW1zIGxpa2Ugd2UgaGF2ZSByb3VnaCBjb25zZW5zdXMgdGhhdCB0aGlzIGlzIHNvbWV0aGluZyB0 aGF0IGlzIHVzZWZ1bC48L2Rpdj4NCjxkaXYgY2xhc3M9IiI+PGJyIGNsYXNzPSIiPg0KPC9kaXY+ DQo8ZGl2IGNsYXNzPSIiPjxiciBjbGFzcz0iIj4NCjwvZGl2Pg0KPGRpdiBjbGFzcz0iIj5XZSBj dXJyZW50bHkgaGF2ZTo8L2Rpdj4NCjxkaXYgY2xhc3M9IiI+LSBBIHByb2JsZW0gdGhhdCB0aGUg V0cgaXMgd2lsbGluZyB0byB3b3JrIG9uIGFuZCBzb2x2ZS48L2Rpdj4NCjxkaXYgY2xhc3M9IiI+ LSBBIGRyYWZ0IHRoYXQgZGVzY3JpYmVzIGEgcG9zc2libGUgc29sdXRpb25zIChUZXh0IGFuZCBv dGhlciBkcmFmdHMgYXJlIG9mLWNvdXJzZSB3ZWxjb21lKS48L2Rpdj4NCjxkaXYgY2xhc3M9IiI+ LSBBIHdvcmtpbmcgaW1wbGVtZW50YXRpb24uIChMaWJyYXJ5IGlzIG9wZW4gc291cmNlLCBubyBv cGVuIHNvdXJjZSBjbGllbnQgdXNlcyBpdCB5ZXQuLik8L2Rpdj4NCjxkaXYgY2xhc3M9IiI+LSBE aXNjdXNzaW9uIG9uIGxpc3Qgb24gd2hhdHMgd29ya2luZyBhbmQgd2hhdHMgbm90LiZuYnNwOzwv ZGl2Pg0KPGRpdiBjbGFzcz0iIj48YnIgY2xhc3M9IiI+DQo8L2Rpdj4NCjxkaXYgY2xhc3M9IiI+ U2VlbXMgbGlrZSBhIGdvb2QgcmVjaXBlIGZvciBhIFJGQy48L2Rpdj4NCjxkaXYgY2xhc3M9IiI+ PGJyIGNsYXNzPSIiPg0KPC9kaXY+DQo8ZGl2IGNsYXNzPSIiPldoYXQgZXIgb3VyIG9wdGlvbnMg dG8gc3BlZWQgdXAgdGhlIHByb2Nlc3Mgc2luY2Ugd2UgYXJlIG5vdCBtZWV0aW5nIGR1cmluZyB0 aGUgbmV4dCBJRVRGPzwvZGl2Pg0KPGRpdiBjbGFzcz0iIj5UaGVyZSBpcyBubyBuZWVkIHRvIHJ1 c2gsIGJ1dCBhbHdheXMgZ29vZCB0byBnZXQgd29yayBkb25lIGFuZCBmaW5pc2hlZC4gRXNwZWNp YWxseSBzaW5jZSB0aGlzIHRvdWNoZXMgb24gY29ubmVjdGl2aXR5IGFuZCBub3Qgb3B0aW1pc2F0 aW9uLiZuYnNwOzwvZGl2Pg0KPGRpdiBjbGFzcz0iIj48YnIgY2xhc3M9IiI+DQo8L2Rpdj4NCjxk aXYgY2xhc3M9IiI+Li0uPC9kaXY+DQo8ZGl2IGNsYXNzPSIiPlDDpWwtRXJpazwvZGl2Pg0KPGRp diBjbGFzcz0iIj48YnIgY2xhc3M9IiI+DQo8L2Rpdj4NCjxkaXY+DQo8YmxvY2txdW90ZSB0eXBl PSJjaXRlIiBjbGFzcz0iIj4NCjxkaXYgY2xhc3M9IiI+T24gMTcgRmViIDIwMTcsIGF0IDIyOjU1 LCBCZXJuYXJkIEFib2JhICZsdDs8YSBocmVmPSJtYWlsdG86YmVybmFyZC5hYm9iYUBnbWFpbC5j b20iIGNsYXNzPSIiPmJlcm5hcmQuYWJvYmFAZ21haWwuY29tPC9hPiZndDsgd3JvdGU6PC9kaXY+ DQo8YnIgY2xhc3M9IkFwcGxlLWludGVyY2hhbmdlLW5ld2xpbmUiPg0KPGRpdiBjbGFzcz0iIj4N CjxkaXYgZGlyPSJsdHIiIGNsYXNzPSIiPkkgaGF2ZSByZWFkIHRoaXMgZHJhZnQsIGFuZCBsaWtl IGl0LiZuYnNwOyBJbiBwcmFjdGljZSB0aGVyZSBhcmUgZW5vdWdoIGN1c3RvbWVycyByZXN0cmlj dGluZyBjb25uZWN0aXZpdHkgdmlhIFVEUCBvciBUTFMgdG8gbWFrZSBpdCB3b3J0aHdoaWxlIHRv IGltcGxlbWVudCBUTFMgY2FuZGlkYXRlcy4NCjxkaXYgY2xhc3M9IiI+PGJyIGNsYXNzPSIiPg0K PC9kaXY+DQo8ZGl2IGNsYXNzPSIiPk15IGV4cGVyaWVuY2UgaXMgdGhhdCBjdXN0b21lcnMgd2hv IG9ubHkgYWxsb3cgVExTIHRvIHBvcnQgNDQzIGFsc28gdGVuZCB0byBpbXBvc2Ugb3RoZXIgcmVz dHJpY3Rpb25zLCBzdWNoIGFzIGZvcmNpbmcgY29ubmVjdGlvbnMgdGhyb3VnaCBhbiBIVFRQUyBw cm94eSBvZiBzb21lIGtpbmQuJm5ic3A7IFNvIHRoZSBjb25zaWRlcmF0aW9ucyBkaXNjdXNzZWQg aW4gU2VjdGlvbiA2IGFyZSBxdWl0ZSBpbXBvcnRhbnQuJm5ic3A7PC9kaXY+DQo8L2Rpdj4NCjxk aXYgY2xhc3M9ImdtYWlsX2V4dHJhIj48YnIgY2xhc3M9IiI+DQo8ZGl2IGNsYXNzPSJnbWFpbF9x dW90ZSI+T24gTW9uLCBKYW4gMjMsIDIwMTcgYXQgMTE6MjggQU0sIFBhbCBNYXJ0aW5zZW4gKHBh bG1hcnRpKQ0KPHNwYW4gZGlyPSJsdHIiIGNsYXNzPSIiPiZsdDs8YSBocmVmPSJtYWlsdG86cGFs bWFydGlAY2lzY28uY29tIiB0YXJnZXQ9Il9ibGFuayIgY2xhc3M9IiI+cGFsbWFydGlAY2lzY28u Y29tPC9hPiZndDs8L3NwYW4+IHdyb3RlOjxiciBjbGFzcz0iIj4NCjxibG9ja3F1b3RlIGNsYXNz PSJnbWFpbF9xdW90ZSIgc3R5bGU9Im1hcmdpbjowIDAgMCAuOGV4O2JvcmRlci1sZWZ0OjFweCAj Y2NjIHNvbGlkO3BhZGRpbmctbGVmdDoxZXgiPg0KPGRpdiBzdHlsZT0id29yZC13cmFwOmJyZWFr LXdvcmQiIGNsYXNzPSIiPkhpIGFsbCwNCjxkaXYgY2xhc3M9IiI+PGJyIGNsYXNzPSIiPg0KPC9k aXY+DQo8ZGl2IGNsYXNzPSIiPlRoZXJlIGlzIGEgbmVlZCBmb3IgVExTIGNhbmRpZGF0ZXMuIFdl IGRpZCBhbiBpbXBsZW1lbnRhdGlvbnMsIHNvIHdlIHRob3VnaHQgaXMgd2FzIGEgZ29vZCBpZGVh IHRvIHdyaXRlIHVwIGEgZHJhZnQuPC9kaXY+DQo8ZGl2IGNsYXNzPSIiPjxiciBjbGFzcz0iIj4N CjwvZGl2Pg0KPGRpdiBjbGFzcz0iIj5JcyB0aGlzIHNvbWV0aGluZyBvdGhlcnMgYXJlIGludGVy ZXN0ZWQgaW4gYXMgd2VsbD88L2Rpdj4NCjxkaXYgY2xhc3M9IiI+KEFzIHRoZXJlIHNlZW1zIHRv IGJlIG5vIElDRSBtZWV0aW5nIG5leHQgSUVURiBpdCB3b3VsZCBiZSBuaWNlIHRvIGdldCB0aGUg ZGlzY3Vzc2lvbiBzdGFydGVkIG9uIHRoZSBsaXN0KTwvZGl2Pg0KPGRpdiBjbGFzcz0iIj48YnIg Y2xhc3M9IiI+DQo8L2Rpdj4NCjxkaXYgY2xhc3M9IiI+Li0uPC9kaXY+DQo8ZGl2IGNsYXNzPSIi PlDDpWwtRXJpazxiciBjbGFzcz0iIj4NCjxkaXYgY2xhc3M9IiI+PGJyIGNsYXNzPSIiPg0KPGJs b2NrcXVvdGUgdHlwZT0iY2l0ZSIgY2xhc3M9IiI+DQo8ZGl2IGNsYXNzPSIiPkJlZ2luIGZvcndh cmRlZCBtZXNzYWdlOjwvZGl2Pg0KPGJyIGNsYXNzPSJtXy0zNjIyODMzNTgzNDI0Mjk2NjQxQXBw bGUtaW50ZXJjaGFuZ2UtbmV3bGluZSI+DQo8ZGl2IHN0eWxlPSJtYXJnaW4tdG9wOjBweDttYXJn aW4tcmlnaHQ6MHB4O21hcmdpbi1ib3R0b206MHB4O21hcmdpbi1sZWZ0OjBweCIgY2xhc3M9IiI+ DQo8c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6IC13ZWJraXQtc3lzdGVtLWZvbnQsICdIZWx2ZXRp Y2EgTmV1ZScsIEhlbHZldGljYSwgc2Fucy1zZXJpZjsiIGNsYXNzPSIiPjxiIGNsYXNzPSIiPkZy b206DQo8L2I+PC9zcGFuPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTotd2Via2l0LXN5c3RlbS1m b250LEhlbHZldGljYSBOZXVlLEhlbHZldGljYSxzYW5zLXNlcmlmIiBjbGFzcz0iIj4mbHQ7PGEg aHJlZj0ibWFpbHRvOmludGVybmV0LWRyYWZ0c0BpZXRmLm9yZyIgdGFyZ2V0PSJfYmxhbmsiIGNs YXNzPSIiPmludGVybmV0LWRyYWZ0c0BpZXRmLm9yZzwvYT4mZ3Q7PGJyIGNsYXNzPSIiPg0KPC9z cGFuPjwvZGl2Pg0KPGRpdiBzdHlsZT0ibWFyZ2luLXRvcDowcHg7bWFyZ2luLXJpZ2h0OjBweDtt YXJnaW4tYm90dG9tOjBweDttYXJnaW4tbGVmdDowcHgiIGNsYXNzPSIiPg0KPHNwYW4gc3R5bGU9 ImZvbnQtZmFtaWx5OiAtd2Via2l0LXN5c3RlbS1mb250LCAnSGVsdmV0aWNhIE5ldWUnLCBIZWx2 ZXRpY2EsIHNhbnMtc2VyaWY7IiBjbGFzcz0iIj48YiBjbGFzcz0iIj5TdWJqZWN0Og0KPC9iPjwv c3Bhbj48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6LXdlYmtpdC1zeXN0ZW0tZm9udCxIZWx2ZXRp Y2EgTmV1ZSxIZWx2ZXRpY2Esc2Fucy1zZXJpZiIgY2xhc3M9IiI+PGIgY2xhc3M9IiI+TmV3IFZl cnNpb24gTm90aWZpY2F0aW9uIGZvciBkcmFmdC1tYXJ0aW5zZW4taWNlLXRscy08d2JyIGNsYXNz PSIiPmNhbmRpZGF0ZXMtMDAudHh0PC9iPjxiciBjbGFzcz0iIj4NCjwvc3Bhbj48L2Rpdj4NCjxk aXYgc3R5bGU9Im1hcmdpbi10b3A6MHB4O21hcmdpbi1yaWdodDowcHg7bWFyZ2luLWJvdHRvbTow cHg7bWFyZ2luLWxlZnQ6MHB4IiBjbGFzcz0iIj4NCjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTog LXdlYmtpdC1zeXN0ZW0tZm9udCwgJ0hlbHZldGljYSBOZXVlJywgSGVsdmV0aWNhLCBzYW5zLXNl cmlmOyIgY2xhc3M9IiI+PGIgY2xhc3M9IiI+RGF0ZToNCjwvYj48L3NwYW4+PHNwYW4gc3R5bGU9 ImZvbnQtZmFtaWx5Oi13ZWJraXQtc3lzdGVtLWZvbnQsSGVsdmV0aWNhIE5ldWUsSGVsdmV0aWNh LHNhbnMtc2VyaWYiIGNsYXNzPSIiPjIwIEphbnVhcnkgMjAxNyBhdCAxNDowODowOSBHTVQmIzQz OzE8YnIgY2xhc3M9IiI+DQo8L3NwYW4+PC9kaXY+DQo8ZGl2IHN0eWxlPSJtYXJnaW4tdG9wOjBw eDttYXJnaW4tcmlnaHQ6MHB4O21hcmdpbi1ib3R0b206MHB4O21hcmdpbi1sZWZ0OjBweCIgY2xh c3M9IiI+DQo8c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6IC13ZWJraXQtc3lzdGVtLWZvbnQsICdI ZWx2ZXRpY2EgTmV1ZScsIEhlbHZldGljYSwgc2Fucy1zZXJpZjsiIGNsYXNzPSIiPjxiIGNsYXNz PSIiPlRvOg0KPC9iPjwvc3Bhbj48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6LXdlYmtpdC1zeXN0 ZW0tZm9udCxIZWx2ZXRpY2EgTmV1ZSxIZWx2ZXRpY2Esc2Fucy1zZXJpZiIgY2xhc3M9IiI+TmF0 aGFuIEJ1Y2tsZXMgJmx0OzxhIGhyZWY9Im1haWx0bzpuYnVja2xlc0BjaXNjby5jb20iIHRhcmdl dD0iX2JsYW5rIiBjbGFzcz0iIj5uYnVja2xlc0BjaXNjby5jb208L2E+Jmd0OywgUGFhbC1Fcmlr IE1hcnRpbnNlbiAmbHQ7PGEgaHJlZj0ibWFpbHRvOnBhbG1hcnRpQGNpc2NvLmNvbSIgdGFyZ2V0 PSJfYmxhbmsiIGNsYXNzPSIiPnBhbG1hcnRpQGNpc2NvLmNvbTwvYT4mZ3Q7PGJyIGNsYXNzPSIi Pg0KPC9zcGFuPjwvZGl2Pg0KPGJyIGNsYXNzPSIiPg0KPGRpdiBjbGFzcz0iIj4NCjxkaXYgY2xh c3M9IiI+PGJyIGNsYXNzPSIiPg0KQSBuZXcgdmVyc2lvbiBvZiBJLUQsIGRyYWZ0LW1hcnRpbnNl bi1pY2UtdGxzLTx3YnIgY2xhc3M9IiI+Y2FuZGlkYXRlcy0wMC50eHQ8YnIgY2xhc3M9IiI+DQpo YXMgYmVlbiBzdWNjZXNzZnVsbHkgc3VibWl0dGVkIGJ5IFBhYWwtRXJpayBNYXJ0aW5zZW4gYW5k IHBvc3RlZCB0byB0aGU8YnIgY2xhc3M9IiI+DQpJRVRGIHJlcG9zaXRvcnkuPGJyIGNsYXNzPSIi Pg0KPGJyIGNsYXNzPSIiPg0KTmFtZTo8c3BhbiBjbGFzcz0ibV8tMzYyMjgzMzU4MzQyNDI5NjY0 MUFwcGxlLXRhYi1zcGFuIiBzdHlsZT0id2hpdGUtc3BhY2U6cHJlLXdyYXAiPg0KPC9zcGFuPjxz cGFuIGNsYXNzPSJtXy0zNjIyODMzNTgzNDI0Mjk2NjQxQXBwbGUtdGFiLXNwYW4iIHN0eWxlPSJ3 aGl0ZS1zcGFjZTpwcmUtd3JhcCI+PC9zcGFuPmRyYWZ0LW1hcnRpbnNlbi1pY2UtdGxzLTx3YnIg Y2xhc3M9IiI+Y2FuZGlkYXRlczxiciBjbGFzcz0iIj4NClJldmlzaW9uOjxzcGFuIGNsYXNzPSJt Xy0zNjIyODMzNTgzNDI0Mjk2NjQxQXBwbGUtdGFiLXNwYW4iIHN0eWxlPSJ3aGl0ZS1zcGFjZTpw cmUtd3JhcCI+DQo8L3NwYW4+MDA8YnIgY2xhc3M9IiI+DQpUaXRsZTo8c3BhbiBjbGFzcz0ibV8t MzYyMjgzMzU4MzQyNDI5NjY0MUFwcGxlLXRhYi1zcGFuIiBzdHlsZT0id2hpdGUtc3BhY2U6cHJl LXdyYXAiPg0KPC9zcGFuPjxzcGFuIGNsYXNzPSJtXy0zNjIyODMzNTgzNDI0Mjk2NjQxQXBwbGUt dGFiLXNwYW4iIHN0eWxlPSJ3aGl0ZS1zcGFjZTpwcmUtd3JhcCI+PC9zcGFuPlRMUyBDYW5kaWRh dGVzIGZvciBJQ0U8YnIgY2xhc3M9IiI+DQpEb2N1bWVudCBkYXRlOjxzcGFuIGNsYXNzPSJtXy0z NjIyODMzNTgzNDI0Mjk2NjQxQXBwbGUtdGFiLXNwYW4iIHN0eWxlPSJ3aGl0ZS1zcGFjZTpwcmUt d3JhcCI+DQo8L3NwYW4+MjAxNy0wMS0yMDxiciBjbGFzcz0iIj4NCkdyb3VwOjxzcGFuIGNsYXNz PSJtXy0zNjIyODMzNTgzNDI0Mjk2NjQxQXBwbGUtdGFiLXNwYW4iIHN0eWxlPSJ3aGl0ZS1zcGFj ZTpwcmUtd3JhcCI+DQo8L3NwYW4+PHNwYW4gY2xhc3M9Im1fLTM2MjI4MzM1ODM0MjQyOTY2NDFB cHBsZS10YWItc3BhbiIgc3R5bGU9IndoaXRlLXNwYWNlOnByZS13cmFwIj48L3NwYW4+SW5kaXZp ZHVhbCBTdWJtaXNzaW9uPGJyIGNsYXNzPSIiPg0KUGFnZXM6PHNwYW4gY2xhc3M9Im1fLTM2MjI4 MzM1ODM0MjQyOTY2NDFBcHBsZS10YWItc3BhbiIgc3R5bGU9IndoaXRlLXNwYWNlOnByZS13cmFw Ij4NCjwvc3Bhbj48c3BhbiBjbGFzcz0ibV8tMzYyMjgzMzU4MzQyNDI5NjY0MUFwcGxlLXRhYi1z cGFuIiBzdHlsZT0id2hpdGUtc3BhY2U6cHJlLXdyYXAiPjwvc3Bhbj42PGJyIGNsYXNzPSIiPg0K VVJMOiAmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDs8YSBocmVmPSJodHRwczovL3d3dy5pZXRmLm9yZy9pbnRlcm5ldC1kcmFm dHMvZHJhZnQtbWFydGluc2VuLWljZS10bHMtY2FuZGlkYXRlcy0wMC50eHQiIHRhcmdldD0iX2Js YW5rIiBjbGFzcz0iIj5odHRwczovL3d3dy5pZXRmLjx3YnIgY2xhc3M9IiI+b3JnL2ludGVybmV0 LWRyYWZ0cy9kcmFmdC08d2JyIGNsYXNzPSIiPm1hcnRpbnNlbi1pY2UtdGxzLWNhbmRpZGF0ZXMt PHdiciBjbGFzcz0iIj4wMC50eHQ8L2E+PGJyIGNsYXNzPSIiPg0KU3RhdHVzOiAmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDs8YSBocmVmPSJodHRwczovL2Rh dGF0cmFja2VyLmlldGYub3JnL2RvYy9kcmFmdC1tYXJ0aW5zZW4taWNlLXRscy1jYW5kaWRhdGVz LyIgdGFyZ2V0PSJfYmxhbmsiIGNsYXNzPSIiPmh0dHBzOi8vZGF0YXRyYWNrZXIuPHdiciBjbGFz cz0iIj5pZXRmLm9yZy9kb2MvZHJhZnQtbWFydGluc2VuLTx3YnIgY2xhc3M9IiI+aWNlLXRscy1j YW5kaWRhdGVzLzwvYT48YnIgY2xhc3M9IiI+DQpIdG1saXplZDogJm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7PGEgaHJlZj0iaHR0cHM6Ly90b29scy5pZXRmLm9yZy9odG1sL2Ry YWZ0LW1hcnRpbnNlbi1pY2UtdGxzLWNhbmRpZGF0ZXMtMDAiIHRhcmdldD0iX2JsYW5rIiBjbGFz cz0iIj5odHRwczovL3Rvb2xzLmlldGYub3JnLzx3YnIgY2xhc3M9IiI+aHRtbC9kcmFmdC1tYXJ0 aW5zZW4taWNlLXRscy08d2JyIGNsYXNzPSIiPmNhbmRpZGF0ZXMtMDA8L2E+PGJyIGNsYXNzPSIi Pg0KPGJyIGNsYXNzPSIiPg0KPGJyIGNsYXNzPSIiPg0KQWJzdHJhY3Q6PGJyIGNsYXNzPSIiPg0K Jm5ic3A7Jm5ic3A7VGhpcyBkb2N1bWVudCBpbnRyb2R1Y2VzIFRMUyBjYW5kaWRhdGVzIHRvIElD RS48YnIgY2xhc3M9IiI+DQo8YnIgY2xhc3M9IiI+DQo8YnIgY2xhc3M9IiI+DQo8YnIgY2xhc3M9 IiI+DQo8YnIgY2xhc3M9IiI+DQpQbGVhc2Ugbm90ZSB0aGF0IGl0IG1heSB0YWtlIGEgY291cGxl IG9mIG1pbnV0ZXMgZnJvbSB0aGUgdGltZSBvZiBzdWJtaXNzaW9uPGJyIGNsYXNzPSIiPg0KdW50 aWwgdGhlIGh0bWxpemVkIHZlcnNpb24gYW5kIGRpZmYgYXJlIGF2YWlsYWJsZSBhdCA8YSBocmVm PSJodHRwOi8vdG9vbHMuaWV0Zi5vcmcvIiB0YXJnZXQ9Il9ibGFuayIgY2xhc3M9IiI+DQp0b29s cy5pZXRmLm9yZzwvYT4uPGJyIGNsYXNzPSIiPg0KPGJyIGNsYXNzPSIiPg0KVGhlIElFVEYgU2Vj cmV0YXJpYXQ8YnIgY2xhc3M9IiI+DQo8YnIgY2xhc3M9IiI+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9i bG9ja3F1b3RlPg0KPC9kaXY+DQo8YnIgY2xhc3M9IiI+DQo8L2Rpdj4NCjwvZGl2Pg0KPGJyIGNs YXNzPSIiPg0KX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fPHdiciBjbGFzcz0iIj5fX19f X19fX19fX19fX19fXzxiciBjbGFzcz0iIj4NCkljZSBtYWlsaW5nIGxpc3Q8YnIgY2xhc3M9IiI+ DQo8YSBocmVmPSJtYWlsdG86SWNlQGlldGYub3JnIiBjbGFzcz0iIj5JY2VAaWV0Zi5vcmc8L2E+ PGJyIGNsYXNzPSIiPg0KPGEgaHJlZj0iaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0 aW5mby9pY2UiIHJlbD0ibm9yZWZlcnJlciIgdGFyZ2V0PSJfYmxhbmsiIGNsYXNzPSIiPmh0dHBz Oi8vd3d3LmlldGYub3JnL21haWxtYW4vPHdiciBjbGFzcz0iIj5saXN0aW5mby9pY2U8L2E+PGJy IGNsYXNzPSIiPg0KPGJyIGNsYXNzPSIiPg0KPC9ibG9ja3F1b3RlPg0KPC9kaXY+DQo8YnIgY2xh c3M9IiI+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9ibG9ja3F1b3RlPg0KPC9kaXY+DQo8YnIgY2xhc3M9 IiI+DQo8L2JvZHk+DQo8L2h0bWw+DQo= --_000_BF16804446C148C2BC6C6C606722CBAEciscocom_-- From nobody Wed Mar 22 08:11:03 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 090D3129464 for ; Wed, 22 Mar 2017 08:11:02 -0700 (PDT) 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 pM9FhnR94bK6 for ; Wed, 22 Mar 2017 08:11:00 -0700 (PDT) Received: from sessmg22.ericsson.net (sessmg22.ericsson.net [193.180.251.58]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BC833126C25 for ; Wed, 22 Mar 2017 08:10:59 -0700 (PDT) X-AuditID: c1b4fb3a-0f3ff70000003958-5c-58d293feb294 Received: from ESESSHC008.ericsson.se (Unknown_Domain [153.88.183.42]) by (Symantec Mail Security) with SMTP id 6E.86.14680.EF392D85; Wed, 22 Mar 2017 16:10:57 +0100 (CET) Received: from ESESSMB109.ericsson.se ([169.254.9.242]) by ESESSHC008.ericsson.se ([153.88.183.42]) with mapi id 14.03.0319.002; Wed, 22 Mar 2017 16:10:54 +0100 From: =?utf-8?B?QXJpIEtlcsOkbmVu?= To: "Pal Martinsen (palmarti)" CC: "ice@ietf.org" Thread-Topic: [Ice] TLS Candidates Thread-Index: AQHSda7ktWsuPgxC8k2HyWHn5eDIT6Ft1QOAgBH+xgCAIW0UgA== Date: Wed, 22 Mar 2017 15:10:53 +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-originating-ip: [153.88.183.150] Content-Type: text/plain; charset="utf-8" Content-ID: <470F357BB33FCA458CB5F220484866F7@ericsson.com> Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFprAIsWRmVeSWpSXmKPExsUyM2K7li7jlEsRBmfWGFt8u1Br8f76ShYH Jo8pvzeyeixZ8pMpgCmKyyYlNSezLLVI3y6BK2PPtyUsBT80KhrvzGBrYPyg3sXIySEhYCLx +s8+5i5GLg4hgXWMEmuv3WEHSQgJLGGUaL1iD2KzCdhKPGndxwpiiwgYSzQfOQpUw8HBLKAo 8XKvGkhYGMj8c3MXE0SJksT8Cxugyp0kpl9axApSziKgKtF5TBokzCtgL/HkSQM7xNrfjBLX n+xnBElwAq16vusrM4jNKCAm8f3UGrCZzALiEreezGeCuFlAYsme88wQtqjEy8f/WCFsJYkV 2y8xQpymKbF+lz5Eq7XE8pl3WCBsRYkp3Q/ZIW4QlDg58wnLBEaxWUg2zELonoWkexaS7llI uhcwsq5iFC1OLS7OTTcy0kstykwuLs7P08tLLdnECIyng1t+W+1gPPjc8RCjAAejEg9vwcRL EUKsiWXFlbmHGCU4mJVEeJ+BhHhTEiurUovy44tKc1KLDzFKc7AoifM67LsQISSQnliSmp2a WpBaBJNl4uCUamCsfbj++x1rQw/BuM3nFI+9VtP5fipz6cmq73F/fBY9Z37geD/WtG1/qeuF 23dSty47Gaz+q+PxHCvmyifKOx1Tp4fnGvYf2OPG67tvuvmbVXxZdc+mqufKHFpXVXtUy543 7dqtpTZVF2wSs+cqG3xuDFfgM77nEuz/qIBxy+wNfyK+Nwp/bbNTYinOSDTUYi4qTgQAQWut SKMCAAA= Archived-At: Subject: Re: [Ice] TLS Candidates X-BeenThere: ice@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "Interactive Connectivity Establishment \(ICE\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 22 Mar 2017 15:11:02 -0000 SGkgUMOlbC1FcmlrIGV0IGFsLA0KDQpJbmRlZWQgdGhlcmUgc2VlbXMgdG8gYmUgaW50ZXJlc3Qg aW4gdGhpcyB0b3BpYy4gSW4gb3JkZXIgdG8gcHJvZ3Jlc3Mgb24gdGhpcywgd2hpbGUgdGhlIHRv cGljIGlzIGluIG91ciBjaGFydGVyLCB3ZSB3b3VsZCBldmVudHVhbGx5IG5lZWQgYSBuZXcgbWls ZXN0b25lIGZvciBpdC4gUmlnaHQgbm93IHRoZXJlIGhhcyBiZWVuIGZldyBpbmRpdmlkdWFscyB3 aG8gYWdyZWUgdGhpcyBpcyBhbiBpbnRlcmVzdGluZyB0b3BpYywgYnV0IHdvdWxkIGJlIGdvb2Qg dG8gaGF2ZSBtb3JlIHBlb3BsZSB2b2ljZSBvdXQgb24gdGhlIGxpc3QgdGhhdCB0aGV5IGNvbnNp ZGVyIHRoaXMgaW1wb3J0YW50Lg0KDQpFdmVuIHRob3VnaCB3ZSBkb24ndCBoYXZlIGFuIElDRSBt ZWV0aW5nIGF0IENoaWNhZ28sIHlvdSBjb3VsZCBjb25zaWRlciBoYXZpbmcgYSBzaWRlIG1lZXRp bmcgdG8gZ2V0IG1vcmUgZm9sa3MgaW52b2x2ZWQuDQoNCg0KQ2hlZXJzLA0KQXJpDQoNCj4gT24g MDEgTWFyIDIwMTcsIGF0IDEwOjQzLCBQYWwgTWFydGluc2VuIChwYWxtYXJ0aSkgPHBhbG1hcnRp QGNpc2NvLmNvbT4gd3JvdGU6DQo+IA0KPiBIaSwNCj4gDQo+IFNlZW1zIGxpa2Ugd2UgaGF2ZSBy b3VnaCBjb25zZW5zdXMgdGhhdCB0aGlzIGlzIHNvbWV0aGluZyB0aGF0IGlzIHVzZWZ1bC4NCj4g DQo+IA0KPiBXZSBjdXJyZW50bHkgaGF2ZToNCj4gLSBBIHByb2JsZW0gdGhhdCB0aGUgV0cgaXMg d2lsbGluZyB0byB3b3JrIG9uIGFuZCBzb2x2ZS4NCj4gLSBBIGRyYWZ0IHRoYXQgZGVzY3JpYmVz IGEgcG9zc2libGUgc29sdXRpb25zIChUZXh0IGFuZCBvdGhlciBkcmFmdHMgYXJlIG9mLWNvdXJz ZSB3ZWxjb21lKS4NCj4gLSBBIHdvcmtpbmcgaW1wbGVtZW50YXRpb24uIChMaWJyYXJ5IGlzIG9w ZW4gc291cmNlLCBubyBvcGVuIHNvdXJjZSBjbGllbnQgdXNlcyBpdCB5ZXQuLikNCj4gLSBEaXNj dXNzaW9uIG9uIGxpc3Qgb24gd2hhdHMgd29ya2luZyBhbmQgd2hhdHMgbm90LiANCj4gDQo+IFNl ZW1zIGxpa2UgYSBnb29kIHJlY2lwZSBmb3IgYSBSRkMuDQo+IA0KPiBXaGF0IGVyIG91ciBvcHRp b25zIHRvIHNwZWVkIHVwIHRoZSBwcm9jZXNzIHNpbmNlIHdlIGFyZSBub3QgbWVldGluZyBkdXJp bmcgdGhlIG5leHQgSUVURj8NCj4gVGhlcmUgaXMgbm8gbmVlZCB0byBydXNoLCBidXQgYWx3YXlz IGdvb2QgdG8gZ2V0IHdvcmsgZG9uZSBhbmQgZmluaXNoZWQuIEVzcGVjaWFsbHkgc2luY2UgdGhp cyB0b3VjaGVzIG9uIGNvbm5lY3Rpdml0eSBhbmQgbm90IG9wdGltaXNhdGlvbi4gDQo+IA0KPiAu LS4NCj4gUMOlbC1FcmlrDQo+IA0KPj4gT24gMTcgRmViIDIwMTcsIGF0IDIyOjU1LCBCZXJuYXJk IEFib2JhIDxiZXJuYXJkLmFib2JhQGdtYWlsLmNvbT4gd3JvdGU6DQo+PiANCj4+IEkgaGF2ZSBy ZWFkIHRoaXMgZHJhZnQsIGFuZCBsaWtlIGl0LiAgSW4gcHJhY3RpY2UgdGhlcmUgYXJlIGVub3Vn aCBjdXN0b21lcnMgcmVzdHJpY3RpbmcgY29ubmVjdGl2aXR5IHZpYSBVRFAgb3IgVExTIHRvIG1h a2UgaXQgd29ydGh3aGlsZSB0byBpbXBsZW1lbnQgVExTIGNhbmRpZGF0ZXMuDQo+PiANCj4+IE15 IGV4cGVyaWVuY2UgaXMgdGhhdCBjdXN0b21lcnMgd2hvIG9ubHkgYWxsb3cgVExTIHRvIHBvcnQg NDQzIGFsc28gdGVuZCB0byBpbXBvc2Ugb3RoZXIgcmVzdHJpY3Rpb25zLCBzdWNoIGFzIGZvcmNp bmcgY29ubmVjdGlvbnMgdGhyb3VnaCBhbiBIVFRQUyBwcm94eSBvZiBzb21lIGtpbmQuICBTbyB0 aGUgY29uc2lkZXJhdGlvbnMgZGlzY3Vzc2VkIGluIFNlY3Rpb24gNiBhcmUgcXVpdGUgaW1wb3J0 YW50LiANCj4+IA0KPj4gT24gTW9uLCBKYW4gMjMsIDIwMTcgYXQgMTE6MjggQU0sIFBhbCBNYXJ0 aW5zZW4gKHBhbG1hcnRpKSA8cGFsbWFydGlAY2lzY28uY29tPiB3cm90ZToNCj4+IEhpIGFsbCwN Cj4+IA0KPj4gVGhlcmUgaXMgYSBuZWVkIGZvciBUTFMgY2FuZGlkYXRlcy4gV2UgZGlkIGFuIGlt cGxlbWVudGF0aW9ucywgc28gd2UgdGhvdWdodCBpcyB3YXMgYSBnb29kIGlkZWEgdG8gd3JpdGUg dXAgYSBkcmFmdC4NCj4+IA0KPj4gSXMgdGhpcyBzb21ldGhpbmcgb3RoZXJzIGFyZSBpbnRlcmVz dGVkIGluIGFzIHdlbGw/DQo+PiAoQXMgdGhlcmUgc2VlbXMgdG8gYmUgbm8gSUNFIG1lZXRpbmcg bmV4dCBJRVRGIGl0IHdvdWxkIGJlIG5pY2UgdG8gZ2V0IHRoZSBkaXNjdXNzaW9uIHN0YXJ0ZWQg b24gdGhlIGxpc3QpDQo+PiANCj4+IC4tLg0KPj4gUMOlbC1FcmlrDQo+PiANCj4+PiBCZWdpbiBm b3J3YXJkZWQgbWVzc2FnZToNCj4+PiANCj4+PiBGcm9tOiA8aW50ZXJuZXQtZHJhZnRzQGlldGYu b3JnPg0KPj4+IFN1YmplY3Q6IE5ldyBWZXJzaW9uIE5vdGlmaWNhdGlvbiBmb3IgZHJhZnQtbWFy dGluc2VuLWljZS10bHMtY2FuZGlkYXRlcy0wMC50eHQNCj4+PiBEYXRlOiAyMCBKYW51YXJ5IDIw MTcgYXQgMTQ6MDg6MDkgR01UKzENCj4+PiBUbzogTmF0aGFuIEJ1Y2tsZXMgPG5idWNrbGVzQGNp c2NvLmNvbT4sIFBhYWwtRXJpayBNYXJ0aW5zZW4gPHBhbG1hcnRpQGNpc2NvLmNvbT4NCj4+PiAN Cj4+PiANCj4+PiBBIG5ldyB2ZXJzaW9uIG9mIEktRCwgZHJhZnQtbWFydGluc2VuLWljZS10bHMt Y2FuZGlkYXRlcy0wMC50eHQNCj4+PiBoYXMgYmVlbiBzdWNjZXNzZnVsbHkgc3VibWl0dGVkIGJ5 IFBhYWwtRXJpayBNYXJ0aW5zZW4gYW5kIHBvc3RlZCB0byB0aGUNCj4+PiBJRVRGIHJlcG9zaXRv cnkuDQo+Pj4gDQo+Pj4gTmFtZToNCj4+PiBkcmFmdC1tYXJ0aW5zZW4taWNlLXRscy1jYW5kaWRh dGVzDQo+Pj4gUmV2aXNpb246DQo+Pj4gMDANCj4+PiBUaXRsZToNCj4+PiBUTFMgQ2FuZGlkYXRl cyBmb3IgSUNFDQo+Pj4gRG9jdW1lbnQgZGF0ZToNCj4+PiAyMDE3LTAxLTIwDQo+Pj4gR3JvdXA6 DQo+Pj4gSW5kaXZpZHVhbCBTdWJtaXNzaW9uDQo+Pj4gUGFnZXM6DQo+Pj4gNg0KPj4+IFVSTDog ICAgICAgICAgICBodHRwczovL3d3dy5pZXRmLm9yZy9pbnRlcm5ldC1kcmFmdHMvZHJhZnQtbWFy dGluc2VuLWljZS10bHMtY2FuZGlkYXRlcy0wMC50eHQNCj4+PiBTdGF0dXM6ICAgICAgICAgaHR0 cHM6Ly9kYXRhdHJhY2tlci5pZXRmLm9yZy9kb2MvZHJhZnQtbWFydGluc2VuLWljZS10bHMtY2Fu ZGlkYXRlcy8NCj4+PiBIdG1saXplZDogICAgICAgaHR0cHM6Ly90b29scy5pZXRmLm9yZy9odG1s L2RyYWZ0LW1hcnRpbnNlbi1pY2UtdGxzLWNhbmRpZGF0ZXMtMDANCj4+PiANCj4+PiANCj4+PiBB YnN0cmFjdDoNCj4+PiAgIFRoaXMgZG9jdW1lbnQgaW50cm9kdWNlcyBUTFMgY2FuZGlkYXRlcyB0 byBJQ0UuDQo+Pj4gDQo+Pj4gDQo+Pj4gDQo+Pj4gDQo+Pj4gUGxlYXNlIG5vdGUgdGhhdCBpdCBt YXkgdGFrZSBhIGNvdXBsZSBvZiBtaW51dGVzIGZyb20gdGhlIHRpbWUgb2Ygc3VibWlzc2lvbg0K Pj4+IHVudGlsIHRoZSBodG1saXplZCB2ZXJzaW9uIGFuZCBkaWZmIGFyZSBhdmFpbGFibGUgYXQg dG9vbHMuaWV0Zi5vcmcuDQo+Pj4gDQo+Pj4gVGhlIElFVEYgU2VjcmV0YXJpYXQNCj4+PiANCj4+ IA0KPj4gDQo+PiBfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f Xw0KPj4gSWNlIG1haWxpbmcgbGlzdA0KPj4gSWNlQGlldGYub3JnDQo+PiBodHRwczovL3d3dy5p ZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL2ljZQ0KPj4gDQo+PiANCj4gDQo+IF9fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQo+IEljZSBtYWlsaW5nIGxpc3QN Cj4gSWNlQGlldGYub3JnDQo+IGh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8v aWNlDQoNCg== From nobody Sat Mar 25 20:09:48 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 740031294D4 for ; Sat, 25 Mar 2017 20:09:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.001 X-Spam-Level: X-Spam-Status: No, score=-2.001 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-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=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 bKjiNTIqgpMc for ; Sat, 25 Mar 2017 20:09:45 -0700 (PDT) Received: from mail-qt0-x230.google.com (mail-qt0-x230.google.com [IPv6:2607:f8b0:400d:c0d::230]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C36E91293E9 for ; Sat, 25 Mar 2017 20:09:44 -0700 (PDT) Received: by mail-qt0-x230.google.com with SMTP id n21so16515845qta.1 for ; Sat, 25 Mar 2017 20:09:44 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:from:date:message-id:subject:to; bh=Xi6s7oj1vtTqanFocC2iaYqEiY8QA+cVDW4AGUsM45A=; b=vzf7yuOI5UTk+GzlOOG+UsNrgCO1jDosl1VZM70KSAvwCl5rrJhA7AG0rjH/M6Gd/4 ImfYO3g9ubc1f3/cvdhPf5DfLpykVFM4eVS06Ke7/+/Rzmdd8nMZR06fPsusY6Ndxxw0 gNyiNKDxsjfitNIPzjnZOy5+UXtp2Q0XfnP+y4m90kyTNt0rHRXgJTHQnVpjwbS/LGr5 BgAkUcGtgn9842/u2KZHNop2RwtcHcJ6Dnt3IzQmBRmOFGNX3CjosuH2L6gdS5H808lc 9ILhC2cCOGTXGtOFThQF4nY1gdT5+rHEnUzS4VpdSt82Xiv6qz2AhgEqDn43sK/6jlra GOYQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:from:date:message-id:subject:to; bh=Xi6s7oj1vtTqanFocC2iaYqEiY8QA+cVDW4AGUsM45A=; b=os+qwo4li/q04D4Do+XQsmKJgL2QemQqk/7nBNr21IzdaV66ZT9bGuNdQREKKCNO42 GdzhcXfuqmZg2CVjIRiDAcTSCEZ8pSloNAlrpqhaHr9Pc/+46l4GIa183Q5WOIeZFOPj HtBvwCl2B9e5CWQlnMGhafELkxZlMr4vcvIOczrML8WFTFP7ci63dXt3MuOIq3I8xIG4 Fc3ubTLA4SEXkR8RcgmpN2LmLvXZF64FaOc5PoNJ8jGt2CeH2F3TYrIlm5AHTknDXE37 SQMDgbi6NWwMsLHCo8r5iYowT2/SKJM/JAj6JeHQ6COm97L/8lTLtkTk7R8kkiizjEY+ 4XoA== X-Gm-Message-State: AFeK/H3udtIvc/kLzg1x47GKuFkUrMdcdizZQClNIK42Jgux3us2kEP8pcrrO8/bUHf4xLL/LOTUEAfXteW4pUgW X-Received: by 10.200.53.150 with SMTP id k22mr14285636qtb.154.1490497783654; Sat, 25 Mar 2017 20:09:43 -0700 (PDT) MIME-Version: 1.0 From: Peter Thatcher Date: Sun, 26 Mar 2017 03:09:33 +0000 Message-ID: To: "ice@ietf.org" Content-Type: multipart/alternative; boundary=001a113e2c0cef479e054b998eb3 Archived-At: Subject: [Ice] Trickle ICE review X-BeenThere: ice@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "Interactive Connectivity Establishment \(ICE\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 26 Mar 2017 03:09:46 -0000 --001a113e2c0cef479e054b998eb3 Content-Type: text/plain; charset=UTF-8 Ari and I reviewed the latest Trickle ICE draft in preparation for going to WGLC and found a few more things worth considering fixing: - Some minor editorial issues that have separately been sent to the authors. - The name "ICE negotiation session" with definition of "A virtual session ..." is confusing. I understand that we need a word for "period between restarts" and "period across restarts". But what does "virtual" mean in this context? And what does "negotiation" mean in "ICE negotiation session"? Here's a possible suggestion: call it "single-exchange session". A single-exchange session is the period from a single exchange of ICE description until the next exchange. A "normal" ICE session is basically a multi-exchange session. - In the phrase " A Trickle ICE agent MUST NOT pair a local candidate until it has been trickled to the remote agent.", what does "has been trickled" mean? That it's been sent on the network? When it's been acked by the remote side? When it is in queue such that it will later be put on the network? It seems really hard to pin down an appropriate time when something "has been trickled". And then in a WebRTC context, the app might never signal a candidate (in a client->server use case). What then? And it's not clear to me why this is even useful. Can we just remove it? Or is there something important here? - The paragraph "Note: So that both agents will have the same view of candidate priorities, it is important to replacing existing pairs with seemingly equivalent higher-priority ones and to always update peer-reflexive candidates if equivalent alternatives are received through signaling." seems duplicate with other parts in the doc. Do we even need this paragraph? - "Either agent MAY generate a subsequent ICE description at any time allowed by RFC3264". This causes ICE to be dependent on SDP, which we were trying to avoid. Was this just one place where we missed removing a dependency on SDP? I would suggest removing it or replacing it with the phrase "Either agent MAY generate subsequent ICE descriptions at any time", unless there is a clear time when an ICE agent cannot (and I can't think of one). As soon as these are resolved, we believe we can go to WGLC. --001a113e2c0cef479e054b998eb3 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Ari and= I reviewed the latest Trickle ICE draft in preparation for going to WGLC a= nd found a few mo= re things worth considering fixing:

- Some minor editorial issues that have separately been sent to the a= uthors.

- The name "ICE n= egotiation session" with definition of "A virtual session ...&quo= t; is confusing. =C2=A0 I understand that we need a word for "period b= etween restarts" and "period across restarts".=C2=A0 But wha= t does "virtual" mean in this context?=C2=A0 And what does "= negotiation" mean in "ICE negotiation session"?=C2=A0 Here&#= 39;s a possible suggestion: call it "single-exchange session". = =C2=A0 A single-exchange session is the period from a single exchange of IC= E description until the next exchange.=C2=A0 A "normal" ICE sessi= on is basically a multi-exchange session.

- In the= phrase " A Trickle ICE agent MUST NOT pair a local candidate until it= has been trickled to the remote agent.", what does "has been tri= ckled" mean?=C2=A0 That it's been sent on the network?=C2=A0 When = it's been acked by the remote side?=C2=A0 When it is in queue such that= it will later be put on the network?=C2=A0 It seems really hard to pin dow= n an appropriate time when something "has been trickled".=C2=A0 A= nd then in a WebRTC context, the app might never signal a candidate (in a c= lient->server use case).=C2=A0 What then? =C2=A0 And it's not clear = to me why this is even useful. =C2=A0 Can we just remove it?=C2=A0 Or is th= ere something important here?

- The paragraph "Note: So that both agents will have the same view o= f candidate priorities, it is important to replacing existing pairs with se= emingly equivalent higher-priority ones and to always update peer-reflexive= candidates if equivalent alternatives are received through signaling."= ; seems duplicate with other parts in the doc.=C2=A0 Do we even need this p= aragraph?

- "Either age= nt MAY generate a subsequent ICE description at any time allowed by RFC3264= ".=C2=A0 This causes ICE to be dependent on SDP, which we were trying = to avoid.=C2=A0 Was this just one place where we missed removing a dependen= cy on SDP?=C2=A0 I would suggest removing it or replacing it with the phras= e "Either agent MAY generate subsequent ICE descriptions at any time&q= uot;, unless there is a clear time when an ICE agent cannot (and I can'= t think of one).=C2=A0


As soon as these are resolved, we believe we can go to WGLC.


--001a113e2c0cef479e054b998eb3-- From nobody Sun Mar 26 11:48:52 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 A9D89129408 for ; Sun, 26 Mar 2017 11:48:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.721 X-Spam-Level: X-Spam-Status: No, score=-2.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_LOW=-0.7, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=stpeter.im header.b=SMhKZppp; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=Yrp63sL0 Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TWoqwFcjUQbY for ; Sun, 26 Mar 2017 11:48:50 -0700 (PDT) Received: from out1-smtp.messagingengine.com (out1-smtp.messagingengine.com [66.111.4.25]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A0745129440 for ; Sun, 26 Mar 2017 11:48:48 -0700 (PDT) Received: from compute2.internal (compute2.nyi.internal [10.202.2.42]) by mailout.nyi.internal (Postfix) with ESMTP id 1A24920ABD; Sun, 26 Mar 2017 14:48:48 -0400 (EDT) Received: from frontend2 ([10.202.2.161]) by compute2.internal (MEProxy); Sun, 26 Mar 2017 14:48:48 -0400 DKIM-Signature: v=1; a=rsa-sha256; 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=fm1; bh=+faaOoYPXNUtdoslb1 aZ4zdpmGCfOWEew9y6ySYBERQ=; b=SMhKZppp2zahBCIwifBe3nqLG9nHa49GrE fHocC8ynTy7arHtllt/MRyn0CjdtbVLOACf05mcI3jKC0HqNiTMi8qjxfEt2jaQL sT67UGB6XUpCS5EUNKjF+CAoCrggUmfPUhShf6YDAFvTWoI/zkQFkv+XbyWPH/iz qTtVaQm5WjwQ04IObRCPxgch7Now5HvsnRRgX1GmCHkvWi4d0RCx43NOTgqlX2/t RSmaP3dUSFlqhfdb2EeVdu6Dukem3B76rrDARqDc4qEDVySR2dwImVflY09jEpor I7QsMvuOmBk5ylJ1wIAwL1AJGHKOn1CwfHCAtanDfzBzNPz4LG5Q== DKIM-Signature: v=1; a=rsa-sha256; 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= fm1; bh=+faaOoYPXNUtdoslb1aZ4zdpmGCfOWEew9y6ySYBERQ=; b=Yrp63sL0 yqsmtXKmyjUjMDfJVsy+NUCj8SkqF1nlm2153fbsCpwrHlCBUv/l2JmmhMjSTalX 6NJEuaKl824fojxBbnNFZCrdRgqEVWjpuUuk65tw5GyqJsVfiEwj1BRGG6lKbNMQ UABFhI8Zi6/5CmvOVvNAN8b1xFAn4z9NdJfqvLxbr4UNgNm6JC4rFz5dwonOxGxj w+uY2szTz6QtfXayL9Km1X1NkAtB6CVy7LtAACiFBBGrRDZ0NO+wNzF+tBIUQAPr 0DMTWh+qjGyPDvQeIm/7BYVVoNIp+YyqjbYqVirJ0uu0Qn6Ww8H+ZxDJ1ThBsrgw YVOsM0QFmu68/Q== X-ME-Sender: X-Sasl-enc: K6ZaRCF+wp2RUdtihZqyv6hTfga3aznb7ounsG25kAHY 1490554127 Received: from aither.local (unknown [76.25.4.24]) by mail.messagingengine.com (Postfix) with ESMTPA id 9493B24614; Sun, 26 Mar 2017 14:48:47 -0400 (EDT) To: Peter Thatcher , "ice@ietf.org" References: From: Peter Saint-Andre Message-ID: <7ebb3254-a882-6e05-3159-0ec56614831b@stpeter.im> Date: Sun, 26 Mar 2017 12:48:46 -0600 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.12; rv:45.0) Gecko/20100101 Thunderbird/45.8.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 8bit Archived-At: Subject: Re: [Ice] Trickle ICE review X-BeenThere: ice@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "Interactive Connectivity Establishment \(ICE\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 26 Mar 2017 18:48:52 -0000 On 3/25/17 9:09 PM, Peter Thatcher wrote: > Ari and I reviewed the latest Trickle ICE draft in preparation for going > to WGLC and found a few more things worth considering fixing: > > - Some minor editorial issues that have separately been sent to the authors. Received. > - The name "ICE negotiation session" with definition of "A virtual > session ..." is confusing. I understand that we need a word for > "period between restarts" and "period across restarts". But what does > "virtual" mean in this context? And what does "negotiation" mean in > "ICE negotiation session"? Here's a possible suggestion: call it > "single-exchange session". A single-exchange session is the period > from a single exchange of ICE description until the next exchange. A > "normal" ICE session is basically a multi-exchange session. This might be clearer: ICE Session: All of the ICE-related interactions between ICE agents up until an ICE restart (if any). However, that definition probably belongs in 5245bis. The term as used in the Trickle specification is not limited to interactions between Trickle ICE agents. > - In the phrase " A Trickle ICE agent MUST NOT pair a local candidate > until it has been trickled to the remote agent.", what does "has been > trickled" mean? That it's been sent on the network? When it's been > acked by the remote side? When it is in queue such that it will later > be put on the network? It seems really hard to pin down an appropriate > time when something "has been trickled". In the interest of startup time, I'd say that a candidate has been trickled when it has been sent. Waiting for acks might slow things down. > And then in a WebRTC context, > the app might never signal a candidate (in a client->server use case). > What then? I don't think we had considered that case. > And it's not clear to me why this is even useful. Can we > just remove it? Or is there something important here? It doesn't seem critically important to me, but I might be missing something. > - The paragraph "Note: So that both agents will have the same view of > candidate priorities, it is important to replacing existing pairs with > seemingly equivalent higher-priority ones and to always update > peer-reflexive candidates if equivalent alternatives are received > through signaling." seems duplicate with other parts in the doc. Do we > even need this paragraph? You're right, these guidelines are indeed mentioned elsewhere. Let's remove them here. > - "Either agent MAY generate a subsequent ICE description at any time > allowed by RFC3264". This causes ICE to be dependent on SDP, which we > were trying to avoid. Was this just one place where we missed removing > a dependency on SDP? I would suggest removing it or replacing it with > the phrase "Either agent MAY generate subsequent ICE descriptions at any > time", unless there is a clear time when an ICE agent cannot (and I > can't think of one). This seems to be a stray mention of RFC 3264 that was not removed in earlier editing. Perhaps "Either agent MAY generate a subsequent ICE description at any time allowed by the signaling protocol in use" (we don't want to override any other protocol's rules here). > As soon as these are resolved, we believe we can go to WGLC. Great. Thanks for the review. Peter From nobody Sun Mar 26 13:54:23 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 46C241296C4 for ; Sun, 26 Mar 2017 13:54:21 -0700 (PDT) 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 lQH0lhBEwacm for ; Sun, 26 Mar 2017 13:54:19 -0700 (PDT) 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 94A071296B7 for ; Sun, 26 Mar 2017 13:54:19 -0700 (PDT) X-AuditID: c1b4fb2d-25fff70000005be8-63-58d82a76de7b Received: from ESESSHC007.ericsson.se (Unknown_Domain [153.88.183.39]) by (Symantec Mail Security) with SMTP id F5.C6.23528.67A28D85; Sun, 26 Mar 2017 22:54:17 +0200 (CEST) Received: from ESESSMB109.ericsson.se ([169.254.9.242]) by ESESSHC007.ericsson.se ([153.88.183.39]) with mapi id 14.03.0339.000; Sun, 26 Mar 2017 22:53:55 +0200 From: =?iso-8859-1?Q?Ari_Ker=E4nen?= To: Peter Saint-Andre CC: Peter Thatcher , "ice@ietf.org" Thread-Topic: [Ice] Trickle ICE review Thread-Index: AQHSpd5vIiCBbI09wke1uNKUfji82aGnVe4AgAAi9gA= Date: Sun, 26 Mar 2017 20:53:55 +0000 Message-ID: <2ECA03A3-EEB8-42E3-AEEF-45C0A0ACB838@ericsson.com> References: <7ebb3254-a882-6e05-3159-0ec56614831b@stpeter.im> In-Reply-To: <7ebb3254-a882-6e05-3159-0ec56614831b@stpeter.im> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [153.88.183.149] Content-Type: text/plain; charset="iso-8859-1" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFprHIsWRmVeSWpSXmKPExsUyM2K7um6l1o0Ig5a/phbfLtRaXFv+mtXi 2J5+ZgdmjwWbSj2WLPnJ5DF3zwvmAOYoLpuU1JzMstQifbsEroz3U/+wF1znr3i47AZrA+N+ ni5GTg4JAROJ57uWsHYxcnEICaxnlJh6rZUJwlnCKLF5UyMLSBWbgL3E5DUfGUFsEQEtiUvX +thBbGYBD4kvWxrBbGEBVYnrGx6wQ9SoSVyc0cMGYVtJ7Pp6ghnEZgGq6T+7EyzOCzRz6+XD UMtaGCUWbX4HtoBTwE7iy7KVrCA2o4CYxPdTa5gglolL3HoynwnibAGJJXvOM0PYohIvH/9j hbCVJNYe3s4CUa8ncWPqFDYI21rizNZLUHO0JZYtfM0McYSgxMmZT1gmMIrNQrJiFpL2WUja ZyFpn4WkfQEj6ypG0eLU4uLcdCNjvdSizOTi4vw8vbzUkk2MwFg7uOW37g7G1a8dDzEKcDAq 8fAa7LsWIcSaWFZcmXuIUYKDWUmE92IlUIg3JbGyKrUoP76oNCe1+BCjNAeLkjivw74LEUIC 6YklqdmpqQWpRTBZJg5OqQZGnRlZR/atCZm9VvSl3/25z8WmpR9KTl773OdTkoJ4+j2Vz6/8 p800zfny6cLLguX/p2wr1Kua/jn0rqOqp08ya1PQ8eWucv5KYRlbnu5e8fbz14JVmj+SFjTn xTZs9mcLl/dY4vJp8ludvycq9BQcgl4wJXQ42du8/Fp18M71DZmyJ+5z/WOYp8RSnJFoqMVc VJwIAMMGgm6xAgAA Archived-At: Subject: Re: [Ice] Trickle ICE review X-BeenThere: ice@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "Interactive Connectivity Establishment \(ICE\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 26 Mar 2017 20:54:21 -0000 > On 26 Mar 2017, at 13:48, Peter Saint-Andre wrote: > On 3/25/17 9:09 PM, Peter Thatcher wrote: [...] >> - The name "ICE negotiation session" with definition of "A virtual >> session ..." is confusing. I understand that we need a word for >> "period between restarts" and "period across restarts". But what does >> "virtual" mean in this context? And what does "negotiation" mean in >> "ICE negotiation session"? Here's a possible suggestion: call it >> "single-exchange session". A single-exchange session is the period >> from a single exchange of ICE description until the next exchange. A >> "normal" ICE session is basically a multi-exchange session. >=20 > This might be clearer: >=20 > ICE Session: All of the ICE-related interactions between ICE agents > up until an ICE restart (if any). >=20 > However, that definition probably belongs in 5245bis. The term as used > in the Trickle specification is not limited to interactions between > Trickle ICE agents. Agree. Let's add this to ICE-bis.=20 I noticed that ICE-bis actually uses this term already, but didn't define i= t in terminology. Let's fix that. [...] >> - "Either agent MAY generate a subsequent ICE description at any time >> allowed by RFC3264". This causes ICE to be dependent on SDP, which we >> were trying to avoid. Was this just one place where we missed removing >> a dependency on SDP? I would suggest removing it or replacing it with >> the phrase "Either agent MAY generate subsequent ICE descriptions at any >> time", unless there is a clear time when an ICE agent cannot (and I >> can't think of one).=20 >=20 > This seems to be a stray mention of RFC 3264 that was not removed in > earlier editing. Perhaps "Either agent MAY generate a subsequent ICE > description at any time allowed by the signaling protocol in use" (we > don't want to override any other protocol's rules here). Sounds good to me. Thanks, Ari (chair hat off) From nobody Sun Mar 26 14:03:47 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 775101296C0 for ; Sun, 26 Mar 2017 14:03:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.721 X-Spam-Level: X-Spam-Status: No, score=-2.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_LOW=-0.7, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=stpeter.im header.b=UfhPhXtl; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=CXGs5svy Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2_lzPtlumlp7 for ; Sun, 26 Mar 2017 14:03:44 -0700 (PDT) Received: from out1-smtp.messagingengine.com (out1-smtp.messagingengine.com [66.111.4.25]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4508B1296C5 for ; Sun, 26 Mar 2017 14:03:44 -0700 (PDT) Received: from compute2.internal (compute2.nyi.internal [10.202.2.42]) by mailout.nyi.internal (Postfix) with ESMTP id AD21C20A6E; Sun, 26 Mar 2017 17:03:43 -0400 (EDT) Received: from frontend2 ([10.202.2.161]) by compute2.internal (MEProxy); Sun, 26 Mar 2017 17:03:43 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=stpeter.im; h=cc :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=fm1; bh=DOWA+W6Y0i0Vudj/xC 1XwZxAwBWLiGaiP1rxCAYRqmE=; b=UfhPhXtlNQeExktmZr2RvZH/gTBBL1tIUv jJQJAX6bnKalTrYWMjOUwMjOcDPzqfmB/4tEpha6KZDu4u9J4qLI4rz9Vym/MrYj 6XXB1Ng20xUWgpwyolRVvkFT/WCTdFXBJWAq4XccPLCsy9H1GorBvmH/MlswW6T0 VntGfjLt+BqX86QPRn90MkwW1IzDQwCMNpvCc+nAHJx3uDM1I/iuC7eqSMC9yJma aaJVVVIdk93bZjFzPnJpdnvFE/FX3daCiuBKhswb1Q76Aym/EhXxoYDkdXw1PC2/ MY5mUUPIuxomY10sLiHX1jhSJm2lyISVw3kyL4gL1PqW/GvkQDrA== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:content-transfer-encoding:content-type :date:from:in-reply-to:message-id:mime-version:references :subject:to:x-me-sender:x-me-sender:x-sasl-enc:x-sasl-enc; s= fm1; bh=DOWA+W6Y0i0Vudj/xC1XwZxAwBWLiGaiP1rxCAYRqmE=; b=CXGs5svy 1Q++5wnn10z8iDf0Yyu3FaKsHXpRucvuWyvEKaW9ytawe77dnzbNrBfFub9ECUEL iIGEqrTgXh3pX9YKgkMLVITB9P8n/qQ0EdV5/uxn1gc/Ql5MLDb7JUuePlUmojQc cPjn29r5ekH0ZYEo1ju2Lj3A3lfVA/EhxcXSQunOtHvuns5kkweUR6NJ8S6QBlZN 0L5LqtUbbMmSAYyzTPffywtXz+oWz+WjK2am0LmLLo32AWmcOfLGTaQckL0XPCGr mPWydlvAOhdwmS54Iwu5lwumn2MUxbGackgj2hrEfQslZslAXLrAJ53iQU8rgFcz MvsvaBZH5plZRg== X-ME-Sender: X-Sasl-enc: BT4eZ/PdIrNsWZ4S3FSfGiyEd/zPQ/mcklL8FrZxp4gg 1490562223 Received: from aither.local (unknown [76.25.4.24]) by mail.messagingengine.com (Postfix) with ESMTPA id 2A6FE240B3; Sun, 26 Mar 2017 17:03:43 -0400 (EDT) To: =?UTF-8?Q?Ari_Ker=c3=a4nen?= References: <7ebb3254-a882-6e05-3159-0ec56614831b@stpeter.im> <2ECA03A3-EEB8-42E3-AEEF-45C0A0ACB838@ericsson.com> Cc: Peter Thatcher , "ice@ietf.org" From: Peter Saint-Andre Message-ID: <7029fd37-0767-8954-9156-72b999c07b62@stpeter.im> Date: Sun, 26 Mar 2017 15:03:42 -0600 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.12; rv:45.0) Gecko/20100101 Thunderbird/45.8.0 MIME-Version: 1.0 In-Reply-To: <2ECA03A3-EEB8-42E3-AEEF-45C0A0ACB838@ericsson.com> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 8bit Archived-At: Subject: Re: [Ice] Trickle ICE review X-BeenThere: ice@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "Interactive Connectivity Establishment \(ICE\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 26 Mar 2017 21:03:45 -0000 On 3/26/17 2:53 PM, Ari Keränen wrote: >> On 26 Mar 2017, at 13:48, Peter Saint-Andre wrote: >> On 3/25/17 9:09 PM, Peter Thatcher wrote: > [...] >>> - The name "ICE negotiation session" with definition of "A virtual >>> session ..." is confusing. I understand that we need a word for >>> "period between restarts" and "period across restarts". But what does >>> "virtual" mean in this context? And what does "negotiation" mean in >>> "ICE negotiation session"? Here's a possible suggestion: call it >>> "single-exchange session". A single-exchange session is the period >>> from a single exchange of ICE description until the next exchange. A >>> "normal" ICE session is basically a multi-exchange session. >> >> This might be clearer: >> >> ICE Session: All of the ICE-related interactions between ICE agents >> up until an ICE restart (if any). >> >> However, that definition probably belongs in 5245bis. The term as used >> in the Trickle specification is not limited to interactions between >> Trickle ICE agents. > > Agree. Let's add this to ICE-bis. > > I noticed that ICE-bis actually uses this term already, but didn't define it in terminology. Let's fix that. Great. I'll remove it from the Trickle spec. Peter From nobody Mon Mar 27 06:39:36 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 26B6D127698; Mon, 27 Mar 2017 06:39:35 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: Cc: ice@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.48.1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <149062197514.30570.2435765130844692924@ietfa.amsl.com> Date: Mon, 27 Mar 2017 06:39:35 -0700 Archived-At: Subject: [Ice] I-D Action: draft-ietf-ice-trickle-08.txt X-BeenThere: ice@ietf.org X-Mailman-Version: 2.1.22 List-Id: "Interactive Connectivity Establishment \(ICE\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 27 Mar 2017 13:39:35 -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-08.txt Pages : 28 Date : 2017-03-27 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 are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-ice-trickle-08 https://datatracker.ietf.org/doc/html/draft-ietf-ice-trickle-08 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-ice-trickle-08 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Mon Mar 27 06:41:17 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 A556D12783A for ; Mon, 27 Mar 2017 06:41:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.72 X-Spam-Level: X-Spam-Status: No, score=-2.72 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, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=stpeter.im header.b=MBmBYR9/; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=kLLEV3R3 Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rRrsQgau95VI for ; Mon, 27 Mar 2017 06:41:13 -0700 (PDT) Received: from out1-smtp.messagingengine.com (out1-smtp.messagingengine.com [66.111.4.25]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8CE9D128C83 for ; Mon, 27 Mar 2017 06:41:13 -0700 (PDT) Received: from compute2.internal (compute2.nyi.internal [10.202.2.42]) by mailout.nyi.internal (Postfix) with ESMTP id 0097B20C13; Mon, 27 Mar 2017 09:41:13 -0400 (EDT) Received: from frontend1 ([10.202.2.160]) by compute2.internal (MEProxy); Mon, 27 Mar 2017 09:41:13 -0400 DKIM-Signature: v=1; a=rsa-sha256; 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=fm1; bh=K+PnmjEGZlkyuV+reE 29rLaqP1dz85HmO8cEm+PCPK0=; b=MBmBYR9/KkLzQ2c0eMXullp27njGi/P0lz 279HUpHMHSLrd41HFBQKtn29VJtrtCQrJWLgNBUHa7fi3nW1KwrDr14BWbfasnLY Cw9/NZb3phId2ZhPDXdBdet+CnBCWfhD+rShHVZIF298P2xmh/LdUi252h85EKIG gaY9hirATUsbmCcqjIvoMGOOLYyY4s+yEj2DQuc3Y4rNyMdESrt9QYiE7j0UTPKx 6Jq97owf6Jtqj/UeQnmeuYe//QbA9y3uAWFfEGSVNZNUP42l+b/JuQjiXn1MWq6Y ulw9JAfaP7p9jvokPYefDt38O15YicrVWIk2uvpGnkBudxjBjP3g== DKIM-Signature: v=1; a=rsa-sha256; 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= fm1; bh=K+PnmjEGZlkyuV+reE29rLaqP1dz85HmO8cEm+PCPK0=; b=kLLEV3R3 mm4sSd1+44YzgfUt8L+gWhdeX2mSV3HeehK4MuX2SYrZeG//qm0F5I3tRrSUo/pG oVEaXvHySfxzWte49CBQu8qxqsOS+mAmatewYLBLG0vS7DjOdSdIlRqcsNyZ9wMR 3QD2CEaGISRt3cq1MRpDI9FnSHA3zGqzo0G2P0Zt5BDOcxF9yzcwn5pLQ/L9g46F bzME3McXJPL0c+U9T70KR4pirwh8pbDTDlpvJtOeyMhtla6jF4PtGYWYuu3Rgkre U4FMdb+sacqyQvMrj1KdWiDLKFDFkSqHqGpP6cOo/fCRE1jddVZjaoqqpflEBOKx I4wGF8nLcmmWDg== X-ME-Sender: X-Sasl-enc: GA7dbEpiT3OdOrWxq7Xa+L9XtO6rLiZY+lONaihnOuXb 1490622072 Received: from aither.local (unknown [76.25.4.24]) by mail.messagingengine.com (Postfix) with ESMTPA id 7F60C7E352; Mon, 27 Mar 2017 09:41:12 -0400 (EDT) To: ice@ietf.org References: <149062197514.30570.2435765130844692924@ietfa.amsl.com> From: Peter Saint-Andre Message-ID: <07cb31ab-fbad-8640-b6e4-415f82e1d90b@stpeter.im> Date: Mon, 27 Mar 2017 07:41:11 -0600 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.12; rv:45.0) Gecko/20100101 Thunderbird/45.8.0 MIME-Version: 1.0 In-Reply-To: <149062197514.30570.2435765130844692924@ietfa.amsl.com> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [Ice] I-D Action: draft-ietf-ice-trickle-08.txt X-BeenThere: ice@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "Interactive Connectivity Establishment \(ICE\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 27 Mar 2017 13:41:16 -0000 This version addresses feedback from the chairs' review. Peter On 3/27/17 7:39 AM, internet-drafts@ietf.org wrote: > > 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-08.txt > Pages : 28 > Date : 2017-03-27 > > 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 are also htmlized versions available at: > https://tools.ietf.org/html/draft-ietf-ice-trickle-08 > https://datatracker.ietf.org/doc/html/draft-ietf-ice-trickle-08 > > A diff from the previous version is available at: > https://www.ietf.org/rfcdiff?url2=draft-ietf-ice-trickle-08 > > > 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/ > > _______________________________________________ > Ice mailing list > Ice@ietf.org > https://www.ietf.org/mailman/listinfo/ice > From nobody Mon Mar 27 07:14:20 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 2A706124282 for ; Mon, 27 Mar 2017 07:14:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.521 X-Spam-Level: X-Spam-Status: No, score=-14.521 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=-0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=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 2_3dVxKTlLjy for ; Mon, 27 Mar 2017 07:14:16 -0700 (PDT) Received: from rcdn-iport-2.cisco.com (rcdn-iport-2.cisco.com [173.37.86.73]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9144A129713 for ; Mon, 27 Mar 2017 07:14:07 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1850; q=dns/txt; s=iport; t=1490624047; x=1491833647; h=from:to:subject:date:message-id:mime-version; bh=xWgIjKhXm14zF0kNuBPx9VYLrw1Ig+y+rBk8OHy/Z9E=; b=ZIwuMnp+hkQuPnieY1rMz/q5rtRAb07H1qLsLRTolKTHBJ/e7XV4TUE2 GFz0LKCCHsJPS0M+9ePZ9O1AwXjmhJJJn9+PmDT+cWVVJwXU9P+NPqVlh repominQU2hM+OKpvVa62AL4Q/GDqAvW4USNbX5CokQUjPJOYVATgmznH U=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0B8AwAWHdlY/5JdJa1cHAEBBAEBCgEBg?= =?us-ascii?q?1RhgRKDW4oPoWiDIYIPgg4qhhSCeT8YAQIBAQEBAQEBax0LhQwzaAELAT4CBDA?= =?us-ascii?q?nBIoaDptCkAaCJoo8AQEBAQEBAQMBAQEBAQEBAQEBARgFhk6CBYpELoIxBZxbA?= =?us-ascii?q?YZ6i1GBfIUqiguTZAEfOD5GWRVSAYZGiR2BDQEBAQ?= X-IronPort-AV: E=Sophos;i="5.36,231,1486425600"; d="scan'208,217";a="228353733" Received: from rcdn-core-10.cisco.com ([173.37.93.146]) by rcdn-iport-2.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 27 Mar 2017 14:14:06 +0000 Received: from XCH-RTP-017.cisco.com (xch-rtp-017.cisco.com [64.101.220.157]) by rcdn-core-10.cisco.com (8.14.5/8.14.5) with ESMTP id v2REE5UJ024306 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL) for ; Mon, 27 Mar 2017 14:14:05 GMT Received: from xch-rtp-019.cisco.com (64.101.220.159) by XCH-RTP-017.cisco.com (64.101.220.157) with Microsoft SMTP Server (TLS) id 15.0.1210.3; Mon, 27 Mar 2017 10:14:04 -0400 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, 27 Mar 2017 10:14:04 -0400 From: "Pal Martinsen (palmarti)" To: "ice@ietf.org" Thread-Topic: ICE on the Side (Side meeting IETF Chicago) Thread-Index: AQHSpwRjSayhNbvjuUGZirWWaTsoFQ== Date: Mon, 27 Mar 2017 14:14:04 +0000 Message-ID: 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.163.52] Content-Type: multipart/alternative; boundary="_000_D9F0C07DA89B448BA4DAD1798971B69Aciscocom_" MIME-Version: 1.0 Archived-At: Subject: [Ice] ICE on the Side (Side meeting IETF Chicago) X-BeenThere: ice@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "Interactive Connectivity Establishment \(ICE\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 27 Mar 2017 14:14:19 -0000 --_000_D9F0C07DA89B448BA4DAD1798971B69Aciscocom_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SGksDQoNCklmIHRoZXJlIGlzIGFueSBpbnRlcmVzdCBvZiBhIHF1aWNrIOKAnElDRSBvbiB0aGUg c2lkZeKAnSBtZXRpbmcgSSBoYXZlIGNyZWF0ZWQgYSBkb29kbGUgcG9sbCBhdDoNCmh0dHBzOi8v ZG9vZGxlLmNvbS9wb2xsL3p5djk4cXB2end6MnhmNnINCg0KDQooQW5kIGlmIHlvdSBoYXZlIGFu eSBJQ0UgVExTIGNhbmRpZGF0ZXMgY29tbWVudHMgcGxlYXNlIGdyYWIgbWUgaW4gdGhlIGhhbGx3 YXlzLikNCi4tLg0KUMOlbC1FcmlrDQoNCg0K --_000_D9F0C07DA89B448BA4DAD1798971B69Aciscocom_ Content-Type: text/html; charset="utf-8" Content-ID: <1AA47371846F654FAE1F6D78A119FDE6@emea.cisco.com> Content-Transfer-Encoding: base64 PGh0bWw+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIgY29udGVudD0i dGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjwvaGVhZD4NCjxib2R5IHN0eWxlPSJ3b3JkLXdy YXA6IGJyZWFrLXdvcmQ7IC13ZWJraXQtbmJzcC1tb2RlOiBzcGFjZTsgLXdlYmtpdC1saW5lLWJy ZWFrOiBhZnRlci13aGl0ZS1zcGFjZTsiIGNsYXNzPSIiPg0KSGksDQo8ZGl2IGNsYXNzPSIiPjxi ciBjbGFzcz0iIj4NCjwvZGl2Pg0KPGRpdiBjbGFzcz0iIj5JZiB0aGVyZSBpcyBhbnkgaW50ZXJl c3Qgb2YgYSBxdWljayDigJxJQ0Ugb24gdGhlIHNpZGXigJ0gbWV0aW5nIEkgaGF2ZSBjcmVhdGVk IGEgZG9vZGxlIHBvbGwgYXQ6PC9kaXY+DQo8ZGl2IGNsYXNzPSIiPjxhIGhyZWY9Imh0dHBzOi8v ZG9vZGxlLmNvbS9wb2xsL3p5djk4cXB2end6MnhmNnIiIGNsYXNzPSIiPmh0dHBzOi8vZG9vZGxl LmNvbS9wb2xsL3p5djk4cXB2end6MnhmNnI8L2E+PC9kaXY+DQo8ZGl2IGNsYXNzPSIiPjxiciBj bGFzcz0iIj4NCjwvZGl2Pg0KPGRpdiBjbGFzcz0iIj48YnIgY2xhc3M9IiI+DQo8L2Rpdj4NCjxk aXYgY2xhc3M9IiI+KEFuZCBpZiB5b3UgaGF2ZSBhbnkgSUNFIFRMUyBjYW5kaWRhdGVzIGNvbW1l bnRzIHBsZWFzZSBncmFiIG1lIGluIHRoZSBoYWxsd2F5cy4pPC9kaXY+DQo8ZGl2IGNsYXNzPSIi Pi4tLjwvZGl2Pg0KPGRpdiBjbGFzcz0iIj5Qw6VsLUVyaWs8L2Rpdj4NCjxkaXYgY2xhc3M9IiI+ PGJyIGNsYXNzPSIiPg0KPC9kaXY+DQo8ZGl2IGNsYXNzPSIiPjxiciBjbGFzcz0iIj4NCjwvZGl2 Pg0KPC9ib2R5Pg0KPC9odG1sPg0K --_000_D9F0C07DA89B448BA4DAD1798971B69Aciscocom_-- From nobody Mon Mar 27 09:21:15 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 460DE127B57 for ; Mon, 27 Mar 2017 09:21:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.888 X-Spam-Level: X-Spam-Status: No, score=-1.888 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_NONE=-0.0001, T_SPF_PERMERROR=0.01, URIBL_BLOCKED=0.001] 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 7iQr5pzjTPZY for ; Mon, 27 Mar 2017 09:21:12 -0700 (PDT) Received: from mail-pg0-x230.google.com (mail-pg0-x230.google.com [IPv6:2607:f8b0:400e:c05::230]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 420D5127201 for ; Mon, 27 Mar 2017 09:21:12 -0700 (PDT) Received: by mail-pg0-x230.google.com with SMTP id 81so30241108pgh.2 for ; Mon, 27 Mar 2017 09:21:12 -0700 (PDT) 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=L9HMQTF5uSHOX1LABbhj7yRoULuzWTRPwYkE//Ada6c=; b=DQHEOtH9U/X2Y+etk82OIsO3Eyb0gYceiWsYsv/XPIV8KD7I+yS833DveX7W8jy7AO bDBvEE/IWsh9Ny+D7lo4tDfowGzWv4UAAWkNj4Rs63XSZ+kNfS82bTZ9ETYs/mZxNCiL tZVN3oR/Ch1S5jvC/fdJ9pFrhEd+iXuec3EQ2CxdUoBEoGIFZv/8VHRp78fOw5fGoljL HDuEneFhaHEY9r2fEWPexhGSqsUmYkIlOJhRzenYQtAGZu1cEfnRKBk7+0fcS0ER5b3x PMVHNV14jx0NEvxfQEk1vYTsfrWHnXk7lUKGKs5Gd3tJ1Mdw83Z2YGp/Z5zMNDq2Okb7 1aVA== 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=L9HMQTF5uSHOX1LABbhj7yRoULuzWTRPwYkE//Ada6c=; b=pdWfIlz9hHkQ4cwhfihvnZdnur9mC+w26Z7Fu5WPUPFAWFJJ2Paqtyiun2XzBJIYTy EMm2hDa4HneCheOp2uBq19EW0fK4/w47+R9U+rNRzap2YhnzXHLm9j+4AGD9MfJrc27Z D+XOmzYwp1jB9D3IyZ0bPlMMgXSovmA9mEP7TK74qBsCI2FarHhI8mWgQ4JmHV19nn4/ avV7HIi4Ex4XTYOqrpZZ5PQudP7kUzX9rsChbg43IS+tJ0YeR5NuLRWZf/6SdMAN+dVp OIIt9TKGLCwgGEflHi5+JmFRHCbu2sISGhnjBj+OtIF/bORvpmX8YON0yFNAux6wrBQj wW0A== X-Gm-Message-State: AFeK/H3NfR4DNYyf5JCDtMn7NAdiO6ZdsDqoaFqwqp7aYbZR/1CCwU43hmspgC8gnWlP1Q== X-Received: by 10.98.138.132 with SMTP id o4mr26688098pfk.70.1490631671744; Mon, 27 Mar 2017 09:21:11 -0700 (PDT) Received: from mail-pg0-f53.google.com (mail-pg0-f53.google.com. [74.125.83.53]) by smtp.gmail.com with ESMTPSA id 198sm2107459pgb.51.2017.03.27.09.21.11 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 27 Mar 2017 09:21:11 -0700 (PDT) Received: by mail-pg0-f53.google.com with SMTP id 21so44814722pgg.1 for ; Mon, 27 Mar 2017 09:21:11 -0700 (PDT) X-Received: by 10.99.225.5 with SMTP id z5mr25224826pgh.145.1490631670948; Mon, 27 Mar 2017 09:21:10 -0700 (PDT) MIME-Version: 1.0 Received: by 10.100.145.151 with HTTP; Mon, 27 Mar 2017 09:21:10 -0700 (PDT) In-Reply-To: References: From: Roman Shpount Date: Mon, 27 Mar 2017 12:21:10 -0400 X-Gmail-Original-Message-ID: Message-ID: To: "Pal Martinsen (palmarti)" Cc: "ice@ietf.org" Content-Type: multipart/alternative; boundary=001a114e93a43cee62054bb8bbff Archived-At: Subject: Re: [Ice] ICE on the Side (Side meeting IETF Chicago) X-BeenThere: ice@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "Interactive Connectivity Establishment \(ICE\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 27 Mar 2017 16:21:14 -0000 --001a114e93a43cee62054bb8bbff Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Is there any way to participate in this remotely? _____________ Roman Shpount On Mon, Mar 27, 2017 at 10:14 AM, Pal Martinsen (palmarti) < palmarti@cisco.com> wrote: > Hi, > > If there is any interest of a quick =E2=80=9CICE on the side=E2=80=9D met= ing I have > created a doodle poll at: > https://doodle.com/poll/zyv98qpvzwz2xf6r > > > (And if you have any ICE TLS candidates comments please grab me in the > hallways.) > .-. > P=C3=A5l-Erik > > > > _______________________________________________ > Ice mailing list > Ice@ietf.org > https://www.ietf.org/mailman/listinfo/ice > > --001a114e93a43cee62054bb8bbff Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Is there any way to participate in this remotely?

_____________
Roman Shpount
<= /div>
On Mon, Mar 27, 2017 at 10:14 AM, Pal Martin= sen (palmarti) <palmarti@cisco.com> wrote:
Hi,

If there is any interest of a quick =E2=80=9CICE on the side=E2=80=9D = meting I have created a doodle poll at:


(And if you have any ICE TLS candidates comments please grab me in the= hallways.)
.-.
P=C3=A5l-Erik



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


--001a114e93a43cee62054bb8bbff-- From nobody Mon Mar 27 11:35:10 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 1E4B3126C22 for ; Mon, 27 Mar 2017 11:35:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.521 X-Spam-Level: X-Spam-Status: No, score=-14.521 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=-0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=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 ViAJRWcBc0aa for ; Mon, 27 Mar 2017 11:35:07 -0700 (PDT) Received: from alln-iport-5.cisco.com (alln-iport-5.cisco.com [173.37.142.92]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 51F5C1294F9 for ; Mon, 27 Mar 2017 11:35:05 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=4012; q=dns/txt; s=iport; t=1490639705; x=1491849305; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=aKU6KkofN9wLRIH4CImOlv5BG4bcCa3IaTTNxEczeyo=; b=nI/PzpmmxajTxggKmSbx+A5Ph0LcbZSQSjNuOG/7hnR7Wy8ef4gQaUy5 VmbsjogF4OIBcrfNQBQ/l1pB6QRujoyV6ZvzPQffQby7Em2kCYDp3OeBM kJSCU03XG3D2bP2cUNqcPKAiZx47qcDCqtRiNPOyHxBKMVuxCIcMzO++1 c=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0DQAgACWtlY/4gNJK1dGQEBAQEBAQEBA?= =?us-ascii?q?QEBBwEBAQEBgm5mYYELB4YnmRGEAQEDjBaFMIIOHwEKhXgCgxlAFwECAQEBAQE?= =?us-ascii?q?BAWsohRUBAQEBAwEBbAsQAgEIBA0EAQEKHgcPGAsUCQgCBA4FigcOriiKTwEBA?= =?us-ascii?q?QEBAQEBAQEBAQEBAQEBAQEBARgFhk6Eb4UKhS8FjUqCV4Vrhk8BhnqLUYF8hSq?= =?us-ascii?q?KC5NkASABNj5GWRVBhB+COXWIKIENAQEB?= X-IronPort-AV: E=Sophos;i="5.36,232,1486425600"; d="scan'208,217";a="401956611" Received: from alln-core-3.cisco.com ([173.36.13.136]) by alln-iport-5.cisco.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 27 Mar 2017 18:35:04 +0000 Received: from XCH-RTP-017.cisco.com (xch-rtp-017.cisco.com [64.101.220.157]) by alln-core-3.cisco.com (8.14.5/8.14.5) with ESMTP id v2RIZ4QD026305 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Mon, 27 Mar 2017 18:35:04 GMT Received: from xch-rtp-019.cisco.com (64.101.220.159) by XCH-RTP-017.cisco.com (64.101.220.157) with Microsoft SMTP Server (TLS) id 15.0.1210.3; Mon, 27 Mar 2017 14:35:03 -0400 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, 27 Mar 2017 14:35:03 -0400 From: "Pal Martinsen (palmarti)" To: Roman Shpount CC: "ice@ietf.org" Thread-Topic: [Ice] ICE on the Side (Side meeting IETF Chicago) Thread-Index: AQHSpwRlL1iYSblGvEOCI0UMkQbO/6GpIU8A///hP1I= Date: Mon, 27 Mar 2017 18:35:03 +0000 Message-ID: <1490639703264.61625@cisco.com> References: , In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.24.100.235] Content-Type: multipart/alternative; boundary="_000_149063970326461625ciscocom_" MIME-Version: 1.0 Archived-At: Subject: Re: [Ice] ICE on the Side (Side meeting IETF Chicago) X-BeenThere: ice@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "Interactive Connectivity Establishment \(ICE\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 27 Mar 2017 18:35:09 -0000 --_000_149063970326461625ciscocom_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Doodle poll closed and it seems like Monday at 15:30 Chicago time suits all= . See you all i the IETF lobby. For remote participants try: https://appear.in/iceontheside? .-. P=E5l-Erik ________________________________ From: Roman Shpount Sent: Monday, March 27, 2017 11:21 AM To: Pal Martinsen (palmarti) Cc: ice@ietf.org Subject: Re: [Ice] ICE on the Side (Side meeting IETF Chicago) Is there any way to participate in this remotely? _____________ Roman Shpount On Mon, Mar 27, 2017 at 10:14 AM, Pal Martinsen (palmarti) > wrote: Hi, If there is any interest of a quick "ICE on the side" meting I have created= a doodle poll at: https://doodle.com/poll/zyv98qpvzwz2xf6r (And if you have any ICE TLS candidates comments please grab me in the hall= ways.) .-. P=E5l-Erik _______________________________________________ Ice mailing list Ice@ietf.org https://www.ietf.org/mailman/listinfo/ice --_000_149063970326461625ciscocom_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

Doodle poll closed and it seems like Monday at 15:30 Chicago time suits = all.


See you all i the IETF lobby.

For remote participants try:
https://appear.in/iceontheside​


.-.

P=E5l-Erik


 --_000_149063970326461625ciscocom_-- From nobody Mon Mar 27 12:53:40 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 09FBA1293D6 for ; Mon, 27 Mar 2017 12:53:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.442 X-Spam-Level: X-Spam-Status: No, score=-0.442 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RDNS_NONE=0.793, SPF_HELO_PASS=-0.001, SPF_SOFTFAIL=0.665, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4OHhOSFC7mRP for ; Mon, 27 Mar 2017 12:53:36 -0700 (PDT) Received: from implementers.org (unknown [IPv6:2001:4b98:dc0:45:216:3eff:fe7f:7abd]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3B78A129498 for ; Mon, 27 Mar 2017 12:53:36 -0700 (PDT) Received: from [IPv6:2001:67c:370:128:de53:60ff:feda:8cf2] (s2001067c03700128de5360fffeda8cf2.v6.meeting.ietf.org [IPv6:2001:67c:370:128:de53:60ff:feda:8cf2]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "Marc Petit-Huguenin", Issuer "implementers.org" (verified OK)) by implementers.org (Postfix) with ESMTPS id E6596AEB2F; Mon, 27 Mar 2017 21:53:33 +0200 (CEST) To: "Pal Martinsen (palmarti)" , Roman Shpount References: <1490639703264.61625@cisco.com> Cc: "ice@ietf.org" From: Marc Petit-Huguenin Message-ID: <29ccb451-c8ab-d24c-d3bf-b89e88aded41@acm.org> Date: Mon, 27 Mar 2017 14:54:24 -0500 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.8.0 MIME-Version: 1.0 In-Reply-To: <1490639703264.61625@cisco.com> Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="BAfErdchaRglPDVnVW0uE5IQ5gnqmUqSM" Archived-At: Subject: Re: [Ice] ICE on the Side (Side meeting IETF Chicago) X-BeenThere: ice@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "Interactive Connectivity Establishment \(ICE\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 27 Mar 2017 19:53:38 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --BAfErdchaRglPDVnVW0uE5IQ5gnqmUqSM Content-Type: multipart/mixed; boundary="1HTlUJ5HfsxkUxQ4WwrVjhtg1Lcm3kxEV"; protected-headers="v1" From: Marc Petit-Huguenin To: "Pal Martinsen (palmarti)" , Roman Shpount Cc: "ice@ietf.org" Message-ID: <29ccb451-c8ab-d24c-d3bf-b89e88aded41@acm.org> Subject: Re: [Ice] ICE on the Side (Side meeting IETF Chicago) References: <1490639703264.61625@cisco.com> In-Reply-To: <1490639703264.61625@cisco.com> --1HTlUJ5HfsxkUxQ4WwrVjhtg1Lcm3kxEV Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable On 03/27/2017 01:35 PM, Pal Martinsen (palmarti) wrote: > Doodle poll closed and it seems like Monday at 15:30 Chicago time suits= all. >=20 >=20 > See you all i the IETF lobby. I suppose that by lobby you mean IETF registration, right? >=20 > For remote participants try: > https://appear.in/iceontheside=E2=80=8B >=20 >=20 > .-. >=20 > P=C3=A5l-Erik >=20 >=20 > -----------------------------------------------------------------------= --------- > *From:* Roman Shpount > *Sent:* Monday, March 27, 2017 11:21 AM > *To:* Pal Martinsen (palmarti) > *Cc:* ice@ietf.org > *Subject:* Re: [Ice] ICE on the Side (Side meeting IETF Chicago) > Is there any way to participate in this remotely? >=20 > _____________ > Roman Shpount >=20 > On Mon, Mar 27, 2017 at 10:14 AM, Pal Martinsen (palmarti) > wrote: >=20 > Hi, >=20 > If there is any interest of a quick =E2=80=9CICE on the side=E2=80=9D= meting I have created > a doodle poll at: > https://doodle.com/poll/zyv98qpvzwz2xf6r > >=20 >=20 > (And if you have any ICE TLS candidates comments please grab me in = the > hallways.) > .-. > P=C3=A5l-Erik >=20 >=20 >=20 > _______________________________________________ > Ice mailing list > Ice@ietf.org > https://www.ietf.org/mailman/listinfo/ice > >=20 >=20 >=20 >=20 > _______________________________________________ > Ice mailing list > Ice@ietf.org > https://www.ietf.org/mailman/listinfo/ice >=20 --1HTlUJ5HfsxkUxQ4WwrVjhtg1Lcm3kxEV-- --BAfErdchaRglPDVnVW0uE5IQ5gnqmUqSM Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- iQIzBAEBCAAdFiEEBSI+IuCHU8MsI1GjKcRFldZqfsQFAljZbfAACgkQKcRFldZq fsQ+LA//TuYzTcPzEBWmoyKwD/yPcdAf8mTtbi7P0hWsGomxe21LElD8JvUeoJWf uPGqTD7luiRCFnKTJ7IzssLW3IxLAGeQMkb9xRKrjZgW0mxtXxhx7Tq6TOQzFtVJ COroH/27zs/UZFpCC4M7WTQFE1Y++3jzrj8WzKYD5gdZEyr9T0R44R077xGfVMtV wQo6d1iUFquY6MQnv/Okxm9SMQM221jp1myD7fzzFLJp04oXAVIUoW+soBNg4APE 75+1IYdnj3aknL80EYVGU236XEHyFUAqbNABX6AvMxEU6huBT02J++/n4wxClRQ7 Ndjq1uLzGq/siORy2NsE7rNmjy/LMGEI8UvmDBmA5PpyUsEFNjgtYCmW0SmD9ixY hdZGCgmEECtdbe19QBFhOWGwoLASgYGZvRxfbx0JBHbtuYKPJF7RW5wYe8W+a0kA GcRIOEoTRX2YrRffOwmB+NHtZBCvF6kptwdPn1MF03ODgHkZqNz8plPcYOg9pp/P 2DeIbRHSBQtStMkVX6ezlJwD+6D9f7ckcsLRmi7pLIerWZxALbLDS/3WBs5YVxkE DHKTMa0LaoswaBb+Cd6bQXaLbWXMM7AbohjThRsSdYQOS/FXYqJRGT/X5X1jHVML o84sQ0fxM542j5ycWFCJi3IH+d9QF/R4bFtY6ZUYPyVQBV+x31E= =V6mN -----END PGP SIGNATURE----- --BAfErdchaRglPDVnVW0uE5IQ5gnqmUqSM-- From nobody Mon Mar 27 13:21: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 B28201294C8 for ; Mon, 27 Mar 2017 13:21:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.522 X-Spam-Level: X-Spam-Status: No, score=-14.522 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=-0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=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 j6exXapaWZ8i for ; Mon, 27 Mar 2017 13:21:03 -0700 (PDT) Received: from alln-iport-5.cisco.com (alln-iport-5.cisco.com [173.37.142.92]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 883E0127071 for ; Mon, 27 Mar 2017 13:21:03 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2554; q=dns/txt; s=iport; t=1490646063; x=1491855663; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=OE/izeGfNfucx9shSMEHDdjKNUq5U4ysEu1G67hrckU=; b=bDy0cV7Sf5Cw3i1gShVi4BJg6r4NUsLJXSm/ndjpffLq7agGE1yIerFs woORgsaXIYx+Z2ltmrpWfh9sJ4xPJjWvWtpffxEBwGYlrAOeExXnp8NyP fOraYjVbX8+ujh8SvkQ+jOetkWQ+Li9eUKk2KWiWCB79bwWJl6orYkJl2 c=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0BVBQDHc9lY/4sNJK1dGQEBAQEBAQEBA?= =?us-ascii?q?QEBBwEBAQEBg1RhgQsHg1ubXZVLgg4fC4V4AhqDAkAXAQIBAQEBAQEBayiFFQE?= =?us-ascii?q?BAQECAQEBIRE6CwULAgEIEQQBAQECAiMDAgICJQsUAQgIAgQOBYl/CA6sCoImi?= =?us-ascii?q?k8BAQEBAQEBAQEBAQEBAQEBAQEBAQEYBYELhUOCBYJqhFQXgm8ugjEFiR6TPQG?= =?us-ascii?q?GeotRgXyFKooLk2QBIQE1gQRZFUERAYZGdYhggQ0BAQE?= X-IronPort-AV: E=Sophos;i="5.36,233,1486425600"; d="scan'208";a="401999609" Received: from alln-core-6.cisco.com ([173.36.13.139]) by alln-iport-5.cisco.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 27 Mar 2017 20:20:54 +0000 Received: from XCH-RTP-020.cisco.com (xch-rtp-020.cisco.com [64.101.220.160]) by alln-core-6.cisco.com (8.14.5/8.14.5) with ESMTP id v2RKKrts022653 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Mon, 27 Mar 2017 20:20:54 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, 27 Mar 2017 16:20:52 -0400 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, 27 Mar 2017 16:20:53 -0400 From: "Pal Martinsen (palmarti)" To: Marc Petit-Huguenin CC: Roman Shpount , "ice@ietf.org" Thread-Topic: [Ice] ICE on the Side (Side meeting IETF Chicago) Thread-Index: AQHSpwRlL1iYSblGvEOCI0UMkQbO/6GpIU8A///hP1KAAFpVAIAAByqA Date: Mon, 27 Mar 2017 20:20:53 +0000 Message-ID: <043179B9-2EBE-4BC3-A040-2FF380FAEA51@cisco.com> References: <1490639703264.61625@cisco.com> <29ccb451-c8ab-d24c-d3bf-b89e88aded41@acm.org> In-Reply-To: <29ccb451-c8ab-d24c-d3bf-b89e88aded41@acm.org> 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.24.114.77] Content-Type: text/plain; charset="utf-8" Content-ID: Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: Subject: Re: [Ice] ICE on the Side (Side meeting IETF Chicago) X-BeenThere: ice@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "Interactive Connectivity Establishment \(ICE\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 27 Mar 2017 20:21:06 -0000 DQo+IE9uIDI3IE1hciAyMDE3LCBhdCAxNDo1NCwgTWFyYyBQZXRpdC1IdWd1ZW5pbiA8cGV0aXRo dWdAYWNtLm9yZz4gd3JvdGU6DQo+IA0KPiBPbiAwMy8yNy8yMDE3IDAxOjM1IFBNLCBQYWwgTWFy dGluc2VuIChwYWxtYXJ0aSkgd3JvdGU6DQo+PiBEb29kbGUgcG9sbCBjbG9zZWQgYW5kIGl0IHNl ZW1zIGxpa2UgTW9uZGF5IGF0IDE1OjMwIENoaWNhZ28gdGltZSBzdWl0cyBhbGwuDQo+PiANCj4+ IA0KPj4gU2VlIHlvdSBhbGwgaSB0aGUgSUVURiBsb2JieS4NCj4gDQo+IEkgc3VwcG9zZSB0aGF0 IGJ5IGxvYmJ5IHlvdSBtZWFuIElFVEYgcmVnaXN0cmF0aW9uLCByaWdodD8NCj4gDQoNClRoZSB3 b3JkIEkgd2FzIGludGVuZGluZyB0byB1c2Ugd2FzIGxvdW5nZeKApiBTYW1lIGZsb29yIGFzIHRo ZSByZWdpc3RyYXRpb24gYnV0IHRoZSBvdGhlciBlbmQuDQoNCklFVEYgbG91bmdlDQoNCi4tLg0K UMOlbC1FcmlrDQoNCg0KPj4gDQo+PiBGb3IgcmVtb3RlIHBhcnRpY2lwYW50cyB0cnk6DQo+PiBo dHRwczovL2FwcGVhci5pbi9pY2VvbnRoZXNpZGXigIsNCj4+IA0KPj4gDQo+PiAuLS4NCj4+IA0K Pj4gUMOlbC1FcmlrDQo+PiANCj4+IA0KPj4gLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0NCj4+ICpG cm9tOiogUm9tYW4gU2hwb3VudCA8cm9tYW5AdGVsdXJpeC5jb20+DQo+PiAqU2VudDoqIE1vbmRh eSwgTWFyY2ggMjcsIDIwMTcgMTE6MjEgQU0NCj4+ICpUbzoqIFBhbCBNYXJ0aW5zZW4gKHBhbG1h cnRpKQ0KPj4gKkNjOiogaWNlQGlldGYub3JnDQo+PiAqU3ViamVjdDoqIFJlOiBbSWNlXSBJQ0Ug b24gdGhlIFNpZGUgKFNpZGUgbWVldGluZyBJRVRGIENoaWNhZ28pDQo+PiBJcyB0aGVyZSBhbnkg d2F5IHRvIHBhcnRpY2lwYXRlIGluIHRoaXMgcmVtb3RlbHk/DQo+PiANCj4+IF9fX19fX19fX19f X18NCj4+IFJvbWFuIFNocG91bnQNCj4+IA0KPj4gT24gTW9uLCBNYXIgMjcsIDIwMTcgYXQgMTA6 MTQgQU0sIFBhbCBNYXJ0aW5zZW4gKHBhbG1hcnRpKSA8cGFsbWFydGlAY2lzY28uY29tIA0KPj4g PG1haWx0bzpwYWxtYXJ0aUBjaXNjby5jb20+PiB3cm90ZToNCj4+IA0KPj4gIEhpLA0KPj4gDQo+ PiAgSWYgdGhlcmUgaXMgYW55IGludGVyZXN0IG9mIGEgcXVpY2sg4oCcSUNFIG9uIHRoZSBzaWRl 4oCdIG1ldGluZyBJIGhhdmUgY3JlYXRlZA0KPj4gIGEgZG9vZGxlIHBvbGwgYXQ6DQo+PiAgaHR0 cHM6Ly9kb29kbGUuY29tL3BvbGwvenl2OThxcHZ6d3oyeGY2cg0KPj4gIDxodHRwczovL2Rvb2Rs ZS5jb20vcG9sbC96eXY5OHFwdnp3ejJ4ZjZyPg0KPj4gDQo+PiANCj4+ICAoQW5kIGlmIHlvdSBo YXZlIGFueSBJQ0UgVExTIGNhbmRpZGF0ZXMgY29tbWVudHMgcGxlYXNlIGdyYWIgbWUgaW4gdGhl DQo+PiAgaGFsbHdheXMuKQ0KPj4gIC4tLg0KPj4gIFDDpWwtRXJpaw0KPj4gDQo+PiANCj4+IA0K Pj4gIF9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQo+PiAg SWNlIG1haWxpbmcgbGlzdA0KPj4gIEljZUBpZXRmLm9yZyA8bWFpbHRvOkljZUBpZXRmLm9yZz4N Cj4+ICBodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL2ljZQ0KPj4gIDxodHRw czovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL2ljZT4NCj4+IA0KPj4gDQo+PiANCj4+ IA0KPj4gX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCj4+ IEljZSBtYWlsaW5nIGxpc3QNCj4+IEljZUBpZXRmLm9yZw0KPj4gaHR0cHM6Ly93d3cuaWV0Zi5v cmcvbWFpbG1hbi9saXN0aW5mby9pY2UNCj4+IA0KPiANCj4gDQoNCg== From nobody Mon Mar 27 13:45: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 8CD5612965B for ; Mon, 27 Mar 2017 13:45:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.388 X-Spam-Level: X-Spam-Status: No, score=-1.388 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_SORBS_SPAM=0.5, T_SPF_PERMERROR=0.01, URIBL_BLOCKED=0.001] autolearn=no 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 N7m0CAv1ts2N for ; Mon, 27 Mar 2017 13:45:37 -0700 (PDT) Received: from mail-pg0-x232.google.com (mail-pg0-x232.google.com [IPv6:2607:f8b0:400e:c05::232]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CECC912963D for ; Mon, 27 Mar 2017 13:45:37 -0700 (PDT) Received: by mail-pg0-x232.google.com with SMTP id 21so51166423pgg.1 for ; Mon, 27 Mar 2017 13:45:37 -0700 (PDT) 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=UNJv4dUjThDPYrVhxVri2kHvv7UbbwTaRDwaDp3NfPc=; b=BE2GTSE0FetkCGBtK9GK/p2EyE+3oVq1qCgPx2tKs6+DpVuXIFJTfHAPj/mpPhtgO+ 13dQkvgNjoFZQq/sfSbYcxv5xLvIn6jgfj3qrcA6tHX64YY2mK1qxlzMNL+U90caqH4X KENf/o/QLzFrUHlyUqN6Im3gCZWaKd3iZ9Ss7MSrUw5F3jh0IaNHAUuOdzrUdttO2DY0 a8xIK2B+daJPmWXi4mlJcrcFObqIvz2E58zoNXjwbyeE2OHb85f0GJ3Jp0cRMMNKPlgY sfNUa6xBOpqiihI3iTqwJeXl4ugvXuRm0kULP/tehhAZV8kuwwkj0s8VOuMVueCyCtmI Freg== 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=UNJv4dUjThDPYrVhxVri2kHvv7UbbwTaRDwaDp3NfPc=; b=eFfgKKVBbuY6AsomN9Nv5nTtoYTm/phWURJVFgkoqJ78Ff/Zx1/IXwgie5PHuzzAiS oX4vDnRnSELO34kQDmOJKM20kVYyDGccV8p8JQsOEJrDJl36odwL2VsAQ+5YJVOEyTFH lfb8gubRgFlQxLQ/wFLBwsIjWyAWJw7N0h6SEUVbPFRsrWGOcxYs7DFWakGngqRvp5MU 3AeAsd+BBpFc3nJMifLYYaLi6A7qi17v1s6HS2//l7NEn4sKHAXgxAND8eoCtqa0wgFD RdGm3oYn1+INx96YK7Zg0FdoNI75hlbpAtBsKM3AkeW9weqHEk4WStQLnnKghh8Bdcv5 V0HQ== X-Gm-Message-State: AFeK/H1hBXer9ADdSaOUOsQd6dGQ6ehwUvkMeJEshVDifW/W6z6rn/okh4z3fEbVxW49wg== X-Received: by 10.99.44.209 with SMTP id s200mr13478258pgs.25.1490647537183; Mon, 27 Mar 2017 13:45:37 -0700 (PDT) Received: from mail-pg0-f49.google.com (mail-pg0-f49.google.com. [74.125.83.49]) by smtp.gmail.com with ESMTPSA id g5sm2878566pgn.18.2017.03.27.13.45.36 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 27 Mar 2017 13:45:36 -0700 (PDT) Received: by mail-pg0-f49.google.com with SMTP id n5so43475058pgh.0 for ; Mon, 27 Mar 2017 13:45:36 -0700 (PDT) X-Received: by 10.84.169.227 with SMTP id h90mr31625120plb.155.1490647536188; Mon, 27 Mar 2017 13:45:36 -0700 (PDT) MIME-Version: 1.0 Received: by 10.100.145.151 with HTTP; Mon, 27 Mar 2017 13:45:35 -0700 (PDT) In-Reply-To: <1490639703264.61625@cisco.com> References: <1490639703264.61625@cisco.com> From: Roman Shpount Date: Mon, 27 Mar 2017 16:45:35 -0400 X-Gmail-Original-Message-ID: Message-ID: To: "Pal Martinsen (palmarti)" Cc: "ice@ietf.org" Content-Type: multipart/alternative; boundary=94eb2c11ba5ae1485f054bbc6c12 Archived-At: Subject: Re: [Ice] ICE on the Side (Side meeting IETF Chicago) X-BeenThere: ice@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "Interactive Connectivity Establishment \(ICE\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 27 Mar 2017 20:45:40 -0000 --94eb2c11ba5ae1485f054bbc6c12 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable I assume appear.in is not working since I am the only person there. Regards, _____________ Roman Shpount On Mon, Mar 27, 2017 at 2:35 PM, Pal Martinsen (palmarti) < palmarti@cisco.com> wrote: > Doodle poll closed and it seems like Monday at 15:30 Chicago time suits > all. > > > See you all i the IETF lobby. > > For remote participants try: > https://appear.in/iceontheside=E2=80=8B > > > .-. > > P=C3=A5l-Erik > > > ------------------------------ > *From:* Roman Shpount > *Sent:* Monday, March 27, 2017 11:21 AM > *To:* Pal Martinsen (palmarti) > *Cc:* ice@ietf.org > *Subject:* Re: [Ice] ICE on the Side (Side meeting IETF Chicago) > > Is there any way to participate in this remotely? > > _____________ > Roman Shpount > > On Mon, Mar 27, 2017 at 10:14 AM, Pal Martinsen (palmarti) < > palmarti@cisco.com> wrote: > >> Hi, >> >> If there is any interest of a quick =E2=80=9CICE on the side=E2=80=9D me= ting I have >> created a doodle poll at: >> https://doodle.com/poll/zyv98qpvzwz2xf6r >> >> >> (And if you have any ICE TLS candidates comments please grab me in the >> hallways.) >> .-. >> P=C3=A5l-Erik >> >> >> >> _______________________________________________ >> Ice mailing list >> Ice@ietf.org >> https://www.ietf.org/mailman/listinfo/ice >> >> > --94eb2c11ba5ae1485f054bbc6c12 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
I assume appear.in is not= working since I am the only person there.

Regards,

_____________
Roman Shpo= unt

On Mon, Mar 27, 2017 at 2:35 PM, Pal Martins= en (palmarti) <palmarti@cisco.com> wrote:

Doodle poll closed and it seems like Monday at 15:30 Chicago time suits = all.


See you all i the IETF lobby.

For remote participants try:
https://appear= .in/iceontheside=E2=80=8B


.-.

P=C3=A5l-Erik


From:= Roman Shpount <r= oman@telurix.com>
Sent: Monday, March 27, 2017 11:21 AM
To: Pal Martinsen (palmarti)
Cc: ice@ietf.org
Subject: Re: [Ice] ICE on the Side (Side meeting IETF Chicago)
=C2=A0
Is there any way to participate in this remotely?

_____________
Roman Shpount

On Mon, Mar 27, 2017 at 10:14 AM, Pal Martinsen = (palmarti) <palmarti@cisco.com> wrote:
Hi,

If there is any interest of a quick =E2=80=9CICE on the side=E2=80=9D = meting I have created a doodle poll at:


(And if you have any ICE TLS candidates comments please grab me in the= hallways.)
.-.
P=C3=A5l-Erik



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



--94eb2c11ba5ae1485f054bbc6c12-- From nobody Mon Mar 27 13:57:44 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 63EC3129642 for ; Mon, 27 Mar 2017 13:57:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.22 X-Spam-Level: X-Spam-Status: No, score=-4.22 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cEOlFBFEAyhD for ; Mon, 27 Mar 2017 13:57:41 -0700 (PDT) Received: from sessmg22.ericsson.net (sessmg22.ericsson.net [193.180.251.58]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0EF1112963D for ; Mon, 27 Mar 2017 13:57:40 -0700 (PDT) X-AuditID: c1b4fb3a-0f3ff70000003958-91-58d97cc2f2eb Received: from ESESSHC003.ericsson.se (Unknown_Domain [153.88.183.27]) by (Symantec Mail Security) with SMTP id 84.0B.14680.2CC79D85; Mon, 27 Mar 2017 22:57:39 +0200 (CEST) Received: from ESESSMB109.ericsson.se ([169.254.9.242]) by ESESSHC003.ericsson.se ([153.88.183.27]) with mapi id 14.03.0339.000; Mon, 27 Mar 2017 22:57:38 +0200 From: Christer Holmberg To: "Pal Martinsen (palmarti)" , Marc Petit-Huguenin CC: Roman Shpount , "ice@ietf.org" Thread-Topic: [Ice] ICE on the Side (Side meeting IETF Chicago) Thread-Index: AQHSpwRjSayhNbvjuUGZirWWaTsoFaGovLoAgAAlaICAABYrAIAAB2eAgAArnPA= Date: Mon, 27 Mar 2017 20:57:38 +0000 Message-ID: <7594FB04B1934943A5C02806D1A2204B4CB30AB4@ESESSMB109.ericsson.se> References: <1490639703264.61625@cisco.com> <29ccb451-c8ab-d24c-d3bf-b89e88aded41@acm.org> <043179B9-2EBE-4BC3-A040-2FF380FAEA51@cisco.com> In-Reply-To: <043179B9-2EBE-4BC3-A040-2FF380FAEA51@cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [153.88.183.154] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFupmkeLIzCtJLcpLzFFi42KZGbFdWvdwzc0Ig6dfBSy+Xai1eH99JYvF hTV3mSxmXJjK7MDicfmKt8eU3xtZPZYs+cnkcWtKQQBLFJdNSmpOZllqkb5dAlfG4nWOBd8k K9avPMPUwLhAsouRk0NCwERiyrZprF2MXBxCAusZJR4+WMEC4SxhlHh96CJjFyMHB5uAhUT3 P22QBhGBWInWKetZQWxmAReJH/e/MoHYwgJ2Euc/PWCDqLGXeLNhMQuE7SfRea+dGcRmEVCV uL5/Olgvr4CvxKWN+xkhdnUySfyfsRWsmVPAVuLblWlgDYwCYhLfT61hglgmLnHryXwmiKsF JJbsOc8MYYtKvHz8jxXCVpJYdPszE8jNzAKaEut36UO0KkpM6X7IDrFXUOLkzCcsExhFZyGZ OguhYxaSjllIOhYwsqxiFC1OLS7OTTcy0kstykwuLs7P08tLLdnECIyig1t+W+1gPPjc8RCj AAejEg/vA6mbEUKsiWXFlbmHGCU4mJVEeL9xA4V4UxIrq1KL8uOLSnNSiw8xSnOwKInzOuy7 ECEkkJ5YkpqdmlqQWgSTZeLglGpg5DoTZyxbGXhaw3Oh5Mubeo1ZzxY6/ZtfG/hqInu/0m6u ZSuL+2U4JTODwiLDI9YdeRy76uW07cdNZxywCt7/6VupwtrV89i9023lPqvqdsR9zYp8Jeol vrx9U6PbEbmnJ2K3X1ko9NXzlwHL9LSs1Tedz4VG8/meWJpVy/jE68Q1jvylp/8dUWIpzkg0 1GIuKk4EAMbKTnGeAgAA Archived-At: Subject: Re: [Ice] ICE on the Side (Side meeting IETF Chicago) X-BeenThere: ice@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "Interactive Connectivity Establishment \(ICE\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 27 Mar 2017 20:57:43 -0000 SGksDQoNCkkgZGlkbid0IHNlZSB5b3VyIGUtbWFpbCB1bnRpbCBub3csIHNvIHVuZm9ydHVuYXRl bHkgSSBtaXNzZWQgdGhlIG1lZXRpbmcgOiggU29ycnkgZm9yIHRoYXQuDQoNClJlZ2FyZHMsDQoN CkNocmlzdGVyDQoNCi0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQpGcm9tOiBJY2UgW21haWx0 bzppY2UtYm91bmNlc0BpZXRmLm9yZ10gT24gQmVoYWxmIE9mIFBhbCBNYXJ0aW5zZW4gKHBhbG1h cnRpKQ0KU2VudDogMjcgTWFyY2ggMjAxNyAyMzoyMQ0KVG86IE1hcmMgUGV0aXQtSHVndWVuaW4g PHBldGl0aHVnQGFjbS5vcmc+DQpDYzogUm9tYW4gU2hwb3VudCA8cm9tYW5AdGVsdXJpeC5jb20+ OyBpY2VAaWV0Zi5vcmcNClN1YmplY3Q6IFJlOiBbSWNlXSBJQ0Ugb24gdGhlIFNpZGUgKFNpZGUg bWVldGluZyBJRVRGIENoaWNhZ28pDQoNCg0KPiBPbiAyNyBNYXIgMjAxNywgYXQgMTQ6NTQsIE1h cmMgUGV0aXQtSHVndWVuaW4gPHBldGl0aHVnQGFjbS5vcmc+IHdyb3RlOg0KPiANCj4gT24gMDMv MjcvMjAxNyAwMTozNSBQTSwgUGFsIE1hcnRpbnNlbiAocGFsbWFydGkpIHdyb3RlOg0KPj4gRG9v ZGxlIHBvbGwgY2xvc2VkIGFuZCBpdCBzZWVtcyBsaWtlIE1vbmRheSBhdCAxNTozMCBDaGljYWdv IHRpbWUgc3VpdHMgYWxsLg0KPj4gDQo+PiANCj4+IFNlZSB5b3UgYWxsIGkgdGhlIElFVEYgbG9i YnkuDQo+IA0KPiBJIHN1cHBvc2UgdGhhdCBieSBsb2JieSB5b3UgbWVhbiBJRVRGIHJlZ2lzdHJh dGlvbiwgcmlnaHQ/DQo+IA0KDQpUaGUgd29yZCBJIHdhcyBpbnRlbmRpbmcgdG8gdXNlIHdhcyBs b3VuZ2XigKYgU2FtZSBmbG9vciBhcyB0aGUgcmVnaXN0cmF0aW9uIGJ1dCB0aGUgb3RoZXIgZW5k Lg0KDQpJRVRGIGxvdW5nZQ0KDQouLS4NClDDpWwtRXJpaw0KDQoNCj4+IA0KPj4gRm9yIHJlbW90 ZSBwYXJ0aWNpcGFudHMgdHJ5Og0KPj4gaHR0cHM6Ly9hcHBlYXIuaW4vaWNlb250aGVzaWRl4oCL DQo+PiANCj4+IA0KPj4gLi0uDQo+PiANCj4+IFDDpWwtRXJpaw0KPj4gDQo+PiANCj4+IC0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLQ0KPj4gLS0tLS0tLS0tLS0NCj4+ICpGcm9tOiogUm9tYW4gU2hwb3VudCA8cm9tYW5A dGVsdXJpeC5jb20+DQo+PiAqU2VudDoqIE1vbmRheSwgTWFyY2ggMjcsIDIwMTcgMTE6MjEgQU0N Cj4+ICpUbzoqIFBhbCBNYXJ0aW5zZW4gKHBhbG1hcnRpKQ0KPj4gKkNjOiogaWNlQGlldGYub3Jn DQo+PiAqU3ViamVjdDoqIFJlOiBbSWNlXSBJQ0Ugb24gdGhlIFNpZGUgKFNpZGUgbWVldGluZyBJ RVRGIENoaWNhZ28pIElzIA0KPj4gdGhlcmUgYW55IHdheSB0byBwYXJ0aWNpcGF0ZSBpbiB0aGlz IHJlbW90ZWx5Pw0KPj4gDQo+PiBfX19fX19fX19fX19fDQo+PiBSb21hbiBTaHBvdW50DQo+PiAN Cj4+IE9uIE1vbiwgTWFyIDI3LCAyMDE3IGF0IDEwOjE0IEFNLCBQYWwgTWFydGluc2VuIChwYWxt YXJ0aSkgDQo+PiA8cGFsbWFydGlAY2lzY28uY29tIDxtYWlsdG86cGFsbWFydGlAY2lzY28uY29t Pj4gd3JvdGU6DQo+PiANCj4+ICBIaSwNCj4+IA0KPj4gIElmIHRoZXJlIGlzIGFueSBpbnRlcmVz dCBvZiBhIHF1aWNrIOKAnElDRSBvbiB0aGUgc2lkZeKAnSBtZXRpbmcgSSBoYXZlIA0KPj4gY3Jl YXRlZCAgYSBkb29kbGUgcG9sbCBhdDoNCj4+ICBodHRwczovL2Rvb2RsZS5jb20vcG9sbC96eXY5 OHFwdnp3ejJ4ZjZyDQo+PiAgPGh0dHBzOi8vZG9vZGxlLmNvbS9wb2xsL3p5djk4cXB2end6Mnhm NnI+DQo+PiANCj4+IA0KPj4gIChBbmQgaWYgeW91IGhhdmUgYW55IElDRSBUTFMgY2FuZGlkYXRl cyBjb21tZW50cyBwbGVhc2UgZ3JhYiBtZSBpbiANCj4+IHRoZQ0KPj4gIGhhbGx3YXlzLikNCj4+ ICAuLS4NCj4+ICBQw6VsLUVyaWsNCj4+IA0KPj4gDQo+PiANCj4+ICBfX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KPj4gIEljZSBtYWlsaW5nIGxpc3QNCj4+ ICBJY2VAaWV0Zi5vcmcgPG1haWx0bzpJY2VAaWV0Zi5vcmc+DQo+PiAgaHR0cHM6Ly93d3cuaWV0 Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9pY2UNCj4+ICA8aHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFp bG1hbi9saXN0aW5mby9pY2U+DQo+PiANCj4+IA0KPj4gDQo+PiANCj4+IF9fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQo+PiBJY2UgbWFpbGluZyBsaXN0DQo+ PiBJY2VAaWV0Zi5vcmcNCj4+IGh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8v aWNlDQo+PiANCj4gDQo+IA0KDQpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fXw0KSWNlIG1haWxpbmcgbGlzdA0KSWNlQGlldGYub3JnDQpodHRwczovL3d3dy5p ZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL2ljZQ0K From nobody Mon Mar 27 14:05:50 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 B3DB512967F for ; Mon, 27 Mar 2017 14:05:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.888 X-Spam-Level: X-Spam-Status: No, score=-1.888 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, T_SPF_PERMERROR=0.01, URIBL_BLOCKED=0.001] 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 HgZOWoD1Kxs1 for ; Mon, 27 Mar 2017 14:05:46 -0700 (PDT) Received: from mail-pg0-x229.google.com (mail-pg0-x229.google.com [IPv6:2607:f8b0:400e: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 337CD1286AB for ; Mon, 27 Mar 2017 14:05:46 -0700 (PDT) Received: by mail-pg0-x229.google.com with SMTP id 81so37060055pgh.2 for ; Mon, 27 Mar 2017 14:05:46 -0700 (PDT) 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=/oCpl7aowB9zIhy+IvJ50J+dZCOuoZAi2hNDAJmQpfU=; b=fQT6b4swGX7Pcxgaw+W6MeqoDwvyRzJsinQcaN7ZTIvHNI+SqwpfnMX/0PUGfeFjh9 o+Kcv4GmE0r9ZOT98kW7k8yw3TwlHCqrTRUuhiB2q1jWiaQHTOUdsf/GWgoscN/fV/yy sNpu1mBF4h2O6JO1eK7XiY/xw1cphm2cWLGwo8vF1KwDop2a2LG/eW6izf8nbt5fAQcM 4BL7k1B/fg0XRACNIoW9a5lLBUzr/nkO7FgQ/xs7rEXjLNQUj22syF6bl3pf3q8wDZ12 GMRkbyEkpyrlfQfBRF4usxHFrs1i1dlRKfuAWQ+hxsjzD1vwLnCBgNWzZ8v9vZYhhIiL Ku3g== 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=/oCpl7aowB9zIhy+IvJ50J+dZCOuoZAi2hNDAJmQpfU=; b=DzQ10hRQZ8dCAKVCF6C3atqbXW+BL5wHyoazOBPK2W54pEhCo+zU1UxZ4IpRQ1fH48 mo885JpBw35Fl0BYulvF58Az3T8JfOjuFqvSjAn8fEiinUvh9mDpLvJKgdCpG9qmV7KN OQBmlhXWkF7zgoRm45GuTX9QfePxWYg7cEr1uPpyBGWSvtNVSYb+DFJXwm25BlPqBsao agUudnY02ena7UjiR/AVT81tlc5up9YqBl1lwLVUMxudQo8rJ92fUiKyNhH5lnF1NjxL hHQynu0vf63T1Jad/zQ5d65kCMnAxXxuv23UEqX++/U6ZeY+O8Q0jrCG0DMp9Pck7yc9 5azg== X-Gm-Message-State: AFeK/H3GOxJVbPQWiO2E4ONROnhTihpzQ934Zn8PkSS/JJZjtQkpMCT105QApuCyJzvZCw== X-Received: by 10.99.247.83 with SMTP id f19mr25765098pgk.158.1490648745556; Mon, 27 Mar 2017 14:05:45 -0700 (PDT) Received: from mail-pg0-f51.google.com (mail-pg0-f51.google.com. [74.125.83.51]) by smtp.gmail.com with ESMTPSA id x65sm2855499pfb.111.2017.03.27.14.05.44 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 27 Mar 2017 14:05:45 -0700 (PDT) Received: by mail-pg0-f51.google.com with SMTP id n5so43924833pgh.0 for ; Mon, 27 Mar 2017 14:05:44 -0700 (PDT) X-Received: by 10.98.216.202 with SMTP id e193mr27280753pfg.80.1490648744731; Mon, 27 Mar 2017 14:05:44 -0700 (PDT) MIME-Version: 1.0 Received: by 10.100.145.151 with HTTP; Mon, 27 Mar 2017 14:05:44 -0700 (PDT) In-Reply-To: <7594FB04B1934943A5C02806D1A2204B4CB30AB4@ESESSMB109.ericsson.se> References: <1490639703264.61625@cisco.com> <29ccb451-c8ab-d24c-d3bf-b89e88aded41@acm.org> <043179B9-2EBE-4BC3-A040-2FF380FAEA51@cisco.com> <7594FB04B1934943A5C02806D1A2204B4CB30AB4@ESESSMB109.ericsson.se> From: Roman Shpount Date: Mon, 27 Mar 2017 17:05:44 -0400 X-Gmail-Original-Message-ID: Message-ID: To: Christer Holmberg Cc: "Pal Martinsen (palmarti)" , Marc Petit-Huguenin , "ice@ietf.org" Content-Type: multipart/alternative; boundary=001a114672beea30b3054bbcb467 Archived-At: Subject: Re: [Ice] ICE on the Side (Side meeting IETF Chicago) X-BeenThere: ice@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "Interactive Connectivity Establishment \(ICE\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 27 Mar 2017 21:05:49 -0000 --001a114672beea30b3054bbcb467 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Hi, Well, this is what I get for not coming to Chicago. I guess I will see the results of the meeting on the list. Regards, _____________ Roman Shpount On Mon, Mar 27, 2017 at 4:57 PM, Christer Holmberg < christer.holmberg@ericsson.com> wrote: > Hi, > > I didn't see your e-mail until now, so unfortunately I missed the meeting > :( Sorry for that. > > Regards, > > Christer > > -----Original Message----- > From: Ice [mailto:ice-bounces@ietf.org] On Behalf Of Pal Martinsen > (palmarti) > Sent: 27 March 2017 23:21 > To: Marc Petit-Huguenin > Cc: Roman Shpount ; ice@ietf.org > Subject: Re: [Ice] ICE on the Side (Side meeting IETF Chicago) > > > > On 27 Mar 2017, at 14:54, Marc Petit-Huguenin wrote: > > > > On 03/27/2017 01:35 PM, Pal Martinsen (palmarti) wrote: > >> Doodle poll closed and it seems like Monday at 15:30 Chicago time suit= s > all. > >> > >> > >> See you all i the IETF lobby. > > > > I suppose that by lobby you mean IETF registration, right? > > > > The word I was intending to use was lounge=E2=80=A6 Same floor as the reg= istration > but the other end. > > IETF lounge > > .-. > P=C3=A5l-Erik > > > >> > >> For remote participants try: > >> https://appear.in/iceontheside=E2=80=8B > >> > >> > >> .-. > >> > >> P=C3=A5l-Erik > >> > >> > >> --------------------------------------------------------------------- > >> ----------- > >> *From:* Roman Shpount > >> *Sent:* Monday, March 27, 2017 11:21 AM > >> *To:* Pal Martinsen (palmarti) > >> *Cc:* ice@ietf.org > >> *Subject:* Re: [Ice] ICE on the Side (Side meeting IETF Chicago) Is > >> there any way to participate in this remotely? > >> > >> _____________ > >> Roman Shpount > >> > >> On Mon, Mar 27, 2017 at 10:14 AM, Pal Martinsen (palmarti) > >> > wrote: > >> > >> Hi, > >> > >> If there is any interest of a quick =E2=80=9CICE on the side=E2=80=9D= meting I have > >> created a doodle poll at: > >> https://doodle.com/poll/zyv98qpvzwz2xf6r > >> > >> > >> > >> (And if you have any ICE TLS candidates comments please grab me in > >> the > >> hallways.) > >> .-. > >> P=C3=A5l-Erik > >> > >> > >> > >> _______________________________________________ > >> Ice mailing list > >> Ice@ietf.org > >> https://www.ietf.org/mailman/listinfo/ice > >> > >> > >> > >> > >> > >> _______________________________________________ > >> Ice mailing list > >> Ice@ietf.org > >> https://www.ietf.org/mailman/listinfo/ice > >> > > > > > > _______________________________________________ > Ice mailing list > Ice@ietf.org > https://www.ietf.org/mailman/listinfo/ice > --001a114672beea30b3054bbcb467 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hi,

Well, this is what I get for not co= ming to Chicago.

I guess I will see the results of= the meeting on the list.

Regards,

_____________
Roman Shpount

On Mon, Mar 27, 2017 at 4:57 PM, Christer Ho= lmberg <christer.holmberg@ericsson.com> wrote:<= br>
Hi,

I didn't see your e-mail until now, so unfortunately I missed the meeti= ng :( Sorry for that.

Regards,

Christer

-----Original Message-----
From: Ice [mailto:ice-bounces@ietf.= org] On Behalf Of Pal Martinsen (palmarti)
Sent: 27 March 2017 23:21
To: Marc Petit-Huguenin <petithug@ac= m.org>
Cc: Roman Shpount <roman@telurix.co= m>; ice@ietf.org
Subject: Re: [Ice] ICE on the Side (Side meeting IETF Chicago)


> On 27 Mar 2017, at 14:54, Marc Petit-Huguenin <petithug@acm.org> wrote:
>
> On 03/27/2017 01:35 PM, Pal Martinsen (palmarti) wrote:
>> Doodle poll closed and it seems like Monday at 15:30 Chicago time = suits all.
>>
>>
>> See you all i the IETF lobby.
>
> I suppose that by lobby you mean IETF registration, right?
>

The word I was intending to use was lounge=E2=80=A6 Same floor as the regis= tration but the other end.

IETF lounge

.-.
P=C3=A5l-Erik


>>
>> For remote participants try:
>> https://appear.in/iceontheside=E2=80=8B
>>
>>
>> .-.
>>
>> P=C3=A5l-Erik
>>
>>
>> ------------------------------------------------------------<= wbr>---------
>> -----------
>> *From:* Roman Shpount <rom= an@telurix.com>
>> *Sent:* Monday, March 27, 2017 11:21 AM
>> *To:* Pal Martinsen (palmarti)
>> *Cc:* ice@ietf.org
>> *Subject:* Re: [Ice] ICE on the Side (Side meeting IETF Chicago) I= s
>> there any way to participate in this remotely?
>>
>> _____________
>> Roman Shpount
>>
>> On Mon, Mar 27, 2017 at 10:14 AM, Pal Martinsen (palmarti)
>> <palmarti@cisco.com &= lt;mailto:palmarti@cisco.com>&= gt; wrote:
>>
>>=C2=A0 Hi,
>>
>>=C2=A0 If there is any interest of a quick =E2=80=9CICE on the side= =E2=80=9D meting I have
>> created=C2=A0 a doodle poll at:
>>=C2=A0 https://doodle.com/poll/zyv98qpvzwz2xf6r=
>>=C2=A0 <https://doodle.com/poll/zyv98qpvzwz2= xf6r>
>>
>>
>>=C2=A0 (And if you have any ICE TLS candidates comments please grab= me in
>> the
>>=C2=A0 hallways.)
>>=C2=A0 .-.
>>=C2=A0 P=C3=A5l-Erik
>>
>>
>>
>>=C2=A0 _______________________________________________
>>=C2=A0 Ice mailing list
>>=C2=A0 Ice@ietf.org <mailto:= Ice@ietf.org>
>>=C2=A0 https://www.ietf.org/mailman/listinfo/i= ce
>>=C2=A0 <https://www.ietf.org/mailman/listin= fo/ice>
>>
>>
>>
>>
>> _______________________________________________
>> Ice mailing list
>> Ice@ietf.org
>> https://www.ietf.org/mailman/listinfo/ice=
>>
>
>

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

--001a114672beea30b3054bbcb467-- From nobody Mon Mar 27 14:08:16 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 634F412967A for ; Mon, 27 Mar 2017 14:08:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HEADER_FROM_DIFFERENT_DOMAINS=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=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 NhQWtasemlr2 for ; Mon, 27 Mar 2017 14:08:11 -0700 (PDT) Received: from mail-wr0-x235.google.com (mail-wr0-x235.google.com [IPv6:2a00:1450:400c:c0c::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 813AC12962E for ; Mon, 27 Mar 2017 14:08:08 -0700 (PDT) Received: by mail-wr0-x235.google.com with SMTP id w43so62681650wrb.0 for ; Mon, 27 Mar 2017 14:08:08 -0700 (PDT) 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=4ilt2Ur5ydjnQ2Z2XlQva4kQwc1gw27tkVGSmU6aHUs=; b=eUnFHLyblWTyn17crYqH7figv5VWwKYs48xMF54iU1MF6YQ9ZklwF9p5PvTcI6UjmU Fcl1j8sJS1s8L9hINZLJqXYXPF3ra32/eAI2vpAQfNDoIYo2oZCFkUJ/1qKT6xV9Apyc bDpxwxhkEe1pmzBTOJz8YWyw9A7fj6D80Xj1G8L1OmZFka5XTXoN4SggpKAyJGUbs2ZR kX6lc7p57JDqe4NcevsYDdvNpXI37e5EDxrRa2DcJneLy+dIswS09QvXWZRhakS1njaw 9XjBEFonXuwZKhoI/fWJNFTLf2ddZXV4sVUnyiUziG7CBPTlkd+01yEdmuf4heMsums7 +OXA== 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=4ilt2Ur5ydjnQ2Z2XlQva4kQwc1gw27tkVGSmU6aHUs=; b=Z7us464OcB4AL6APoY+83ioHsUzvB3xuHrnOIWr/raYK6+WlXhXuEteYXh5hrDMr6Q 1Uy/6LJ3qcMyYJzNdNxoc7De03OWY9Y1tFWcdKwVQtUWT/wvdRWhsP0mSPxq8CiCLz+4 MRAj04GERT2RNnYF4oHijxvTBxptA0iKBGvMAebRVjgbAIKqB4gn2fZfupQfkAsuMenw 8Unn8vGCNr51vKm014CXGMbuR37E/FNxt49Vc9k2x8r46gnU8sDrbIM9xbfRJ2sqjJN7 Wos5qszg33sXOBelAv6EckZIi80FRIjQVsd8xNpsjwhqfpVzo79D27DaG33dZHURcFFJ Un7Q== X-Gm-Message-State: AFeK/H0CSfDgOjDsLaeHKMEm9Y4k1rvm6Oj9pLNEYhAgRObOmQAXSOaLk6/K19Ui4IP+2w== X-Received: by 10.223.136.214 with SMTP id g22mr21064049wrg.37.1490648886601; Mon, 27 Mar 2017 14:08:06 -0700 (PDT) Received: from mail-wr0-f171.google.com (mail-wr0-f171.google.com. [209.85.128.171]) by smtp.gmail.com with ESMTPSA id x131sm899956wme.28.2017.03.27.14.08.06 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 27 Mar 2017 14:08:06 -0700 (PDT) Received: by mail-wr0-f171.google.com with SMTP id w43so62681061wrb.0 for ; Mon, 27 Mar 2017 14:08:06 -0700 (PDT) X-Received: by 10.28.29.88 with SMTP id d85mr11104467wmd.56.1490648886124; Mon, 27 Mar 2017 14:08:06 -0700 (PDT) MIME-Version: 1.0 Received: by 10.80.186.6 with HTTP; Mon, 27 Mar 2017 14:07:45 -0700 (PDT) In-Reply-To: <7594FB04B1934943A5C02806D1A2204B4CB30AB4@ESESSMB109.ericsson.se> References: <1490639703264.61625@cisco.com> <29ccb451-c8ab-d24c-d3bf-b89e88aded41@acm.org> <043179B9-2EBE-4BC3-A040-2FF380FAEA51@cisco.com> <7594FB04B1934943A5C02806D1A2204B4CB30AB4@ESESSMB109.ericsson.se> From: Emil Ivov Date: Mon, 27 Mar 2017 16:07:45 -0500 X-Gmail-Original-Message-ID: Message-ID: To: Christer Holmberg Cc: "Pal Martinsen (palmarti)" , Marc Petit-Huguenin , Roman Shpount , "ice@ietf.org" Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Archived-At: Subject: Re: [Ice] ICE on the Side (Side meeting IETF Chicago) X-BeenThere: ice@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "Interactive Connectivity Establishment \(ICE\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 27 Mar 2017 21:08:15 -0000 Same here. Saw this mail too late. Maybe we can schedule another one? On Mon, Mar 27, 2017 at 3:57 PM, Christer Holmberg wrote: > Hi, > > I didn't see your e-mail until now, so unfortunately I missed the meeting= :( Sorry for that. > > Regards, > > Christer > > -----Original Message----- > From: Ice [mailto:ice-bounces@ietf.org] On Behalf Of Pal Martinsen (palma= rti) > Sent: 27 March 2017 23:21 > To: Marc Petit-Huguenin > Cc: Roman Shpount ; ice@ietf.org > Subject: Re: [Ice] ICE on the Side (Side meeting IETF Chicago) > > >> On 27 Mar 2017, at 14:54, Marc Petit-Huguenin wrote: >> >> On 03/27/2017 01:35 PM, Pal Martinsen (palmarti) wrote: >>> Doodle poll closed and it seems like Monday at 15:30 Chicago time suits= all. >>> >>> >>> See you all i the IETF lobby. >> >> I suppose that by lobby you mean IETF registration, right? >> > > The word I was intending to use was lounge=E2=80=A6 Same floor as the reg= istration but the other end. > > IETF lounge > > .-. > P=C3=A5l-Erik > > >>> >>> For remote participants try: >>> https://appear.in/iceontheside >>> >>> >>> .-. >>> >>> P=C3=A5l-Erik >>> >>> >>> --------------------------------------------------------------------- >>> ----------- >>> *From:* Roman Shpount >>> *Sent:* Monday, March 27, 2017 11:21 AM >>> *To:* Pal Martinsen (palmarti) >>> *Cc:* ice@ietf.org >>> *Subject:* Re: [Ice] ICE on the Side (Side meeting IETF Chicago) Is >>> there any way to participate in this remotely? >>> >>> _____________ >>> Roman Shpount >>> >>> On Mon, Mar 27, 2017 at 10:14 AM, Pal Martinsen (palmarti) >>> > wrote: >>> >>> Hi, >>> >>> If there is any interest of a quick =E2=80=9CICE on the side=E2=80=9D = meting I have >>> created a doodle poll at: >>> https://doodle.com/poll/zyv98qpvzwz2xf6r >>> >>> >>> >>> (And if you have any ICE TLS candidates comments please grab me in >>> the >>> hallways.) >>> .-. >>> P=C3=A5l-Erik >>> >>> >>> >>> _______________________________________________ >>> Ice mailing list >>> Ice@ietf.org >>> https://www.ietf.org/mailman/listinfo/ice >>> >>> >>> >>> >>> >>> _______________________________________________ >>> Ice mailing list >>> Ice@ietf.org >>> https://www.ietf.org/mailman/listinfo/ice >>> >> >> > > _______________________________________________ > Ice mailing list > Ice@ietf.org > https://www.ietf.org/mailman/listinfo/ice > _______________________________________________ > Ice mailing list > Ice@ietf.org > https://www.ietf.org/mailman/listinfo/ice --=20 https://jitsi.org From nobody Mon Mar 27 22:17: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 30147126D85 for ; Mon, 27 Mar 2017 22:17:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.701 X-Spam-Level: X-Spam-Status: No, score=-2.701 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-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=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 B1V12fTl9u9a for ; Mon, 27 Mar 2017 22:17:08 -0700 (PDT) Received: from mail-qk0-x22b.google.com (mail-qk0-x22b.google.com [IPv6:2607:f8b0:400d:c09::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 EC1D8128AB0 for ; Mon, 27 Mar 2017 22:17:07 -0700 (PDT) Received: by mail-qk0-x22b.google.com with SMTP id d10so50774145qke.1 for ; Mon, 27 Mar 2017 22:17:07 -0700 (PDT) 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; bh=8KFHPQNNA0VrogajEjIVChXa+BeU+TjBZ6XjHx7B2uY=; b=FVVaftz+HMN9fK6rjBFRh2zcAkNFdFHFJyAJ+07Auul0mbmjJoEMlzs4b3YVTLEMcG AQ/xSSMWtM4K6fVZ4phiNssmkzhs7niKtWYtc8KskE93GYcxu7MBsBam7N6UcBaK1QMt 96YdcyamhwYk5Lhxc9VlkYvar+aSbsIfAMqvfNcgtlJccTiT+ffznBXGOV/iec2erHDK 7ppS4qu7XmcQjyga8VB00XmCAJ2FZ0HiQqZ7mfQGWH6qCxc1WGIKYHq3GRfa9b/HCSFS Y+t65B//40Chpwf+PqrPjlKNpxQZP2hUngW9QUuQuGncr0/Nlz4kl7yuz59+NqPRVjFf ydDg== 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; bh=8KFHPQNNA0VrogajEjIVChXa+BeU+TjBZ6XjHx7B2uY=; b=Qwh5s/CdjEip5yZO0+G1Ni9h6M2BZPm6veiDfzqljhGeL/nI0BflBPNrd47NV6GDVP zDg8LZxLXEZaCiUrvFrr3FrtJu/laFtQEhWhtYxfq4vjj/ShTgZSSXTmDQgf06BrD/MN zWL6wri68HkyhVMZt+7+Rnt6cy1V+WBfnBvcxSdNSNRATpt7jy0HObpaIqK/Y6vNkneW 0x+bLN0n/fG+5JwijCYvK/294qAh/OFBZbNi8WeY35fpUTRyfRyCn7FN0lCoZwB53uKY HVvxzXTkdS6dq91++iEGuK6qdHK5JagZpCmZ9Iu2CjmPn/oX2ryP59fgR5UqDlvPhfg/ sRsw== X-Gm-Message-State: AFeK/H0BygDtKqPYnaVsZz6H4OWpSaRRaTvIPQ8svBbJWEcnyjqSNxvTEFt73Lbaz3HAONCmRPfTrbmqv+y7xwW9 X-Received: by 10.55.183.133 with SMTP id h127mr24809751qkf.121.1490678226914; Mon, 27 Mar 2017 22:17:06 -0700 (PDT) MIME-Version: 1.0 References: <7ebb3254-a882-6e05-3159-0ec56614831b@stpeter.im> In-Reply-To: <7ebb3254-a882-6e05-3159-0ec56614831b@stpeter.im> From: Peter Thatcher Date: Tue, 28 Mar 2017 05:16:56 +0000 Message-ID: To: Peter Saint-Andre , "ice@ietf.org" Content-Type: multipart/alternative; boundary=94eb2c0600563114dc054bc392e4 Archived-At: Subject: Re: [Ice] Trickle ICE review X-BeenThere: ice@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "Interactive Connectivity Establishment \(ICE\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 28 Mar 2017 05:17:10 -0000 --94eb2c0600563114dc054bc392e4 Content-Type: text/plain; charset=UTF-8 On Sun, Mar 26, 2017 at 11:48 AM Peter Saint-Andre wrote: > On 3/25/17 9:09 PM, Peter Thatcher wrote: > > Ari and I reviewed the latest Trickle ICE draft in preparation for going > > to WGLC and found a few more things worth considering fixing: > > > > - Some minor editorial issues that have separately been sent to the > authors. > > Received. > > > - The name "ICE negotiation session" with definition of "A virtual > > session ..." is confusing. I understand that we need a word for > > "period between restarts" and "period across restarts". But what does > > "virtual" mean in this context? And what does "negotiation" mean in > > "ICE negotiation session"? Here's a possible suggestion: call it > > "single-exchange session". A single-exchange session is the period > > from a single exchange of ICE description until the next exchange. A > > "normal" ICE session is basically a multi-exchange session. > > This might be clearer: > > ICE Session: All of the ICE-related interactions between ICE agents > up until an ICE restart (if any). > > However, that definition probably belongs in 5245bis. The term as used > in the Trickle specification is not limited to interactions between > Trickle ICE agents. > > I like that idea of using "ICE session" to mean the thing between restarts as long as it's compatible with 5245 and 5245bis and it doesn't cause confusion such that people think an "ICE session" is the time period across all ICE restarts. I originally thought it should go in 5245bis also, but Ari thought it didn't make sense there since it would never use the term after defining it. > > - In the phrase " A Trickle ICE agent MUST NOT pair a local candidate > > until it has been trickled to the remote agent.", what does "has been > > trickled" mean? That it's been sent on the network? When it's been > > acked by the remote side? When it is in queue such that it will later > > be put on the network? It seems really hard to pin down an appropriate > > time when something "has been trickled". > > In the interest of startup time, I'd say that a candidate has been > trickled when it has been sent. Waiting for acks might slow things down. > > > And then in a WebRTC context, > > the app might never signal a candidate (in a client->server use case). > > What then? > > I don't think we had considered that case. > > > And it's not clear to me why this is even useful. Can we > > just remove it? Or is there something important here? > > It doesn't seem critically important to me, but I might be missing > something. > I think there's still the issue of what does "sent" mean? In the network buffer of the OS kernel ready to go out? In a queue on a "network thread" that's going to give it to the OS kernel to go out? Does it actually have to be on the network or just queued to be so later? If we don't need it, I'd say we just remove it. Doubly so if we can't even be sure what it means. > > > - The paragraph "Note: So that both agents will have the same view of > > candidate priorities, it is important to replacing existing pairs with > > seemingly equivalent higher-priority ones and to always update > > peer-reflexive candidates if equivalent alternatives are received > > through signaling." seems duplicate with other parts in the doc. Do we > > even need this paragraph? > > You're right, these guidelines are indeed mentioned elsewhere. Let's > remove them here. > > > - "Either agent MAY generate a subsequent ICE description at any time > > allowed by RFC3264". This causes ICE to be dependent on SDP, which we > > were trying to avoid. Was this just one place where we missed removing > > a dependency on SDP? I would suggest removing it or replacing it with > > the phrase "Either agent MAY generate subsequent ICE descriptions at any > > time", unless there is a clear time when an ICE agent cannot (and I > > can't think of one). > > This seems to be a stray mention of RFC 3264 that was not removed in > earlier editing. Perhaps "Either agent MAY generate a subsequent ICE > description at any time allowed by the signaling protocol in use" (we > don't want to override any other protocol's rules here). > > Deferring to the signaling protocol sounds like a good idea. And should it be "generate" or "send" a subsequent ICE description? > > As soon as these are resolved, we believe we can go to WGLC. > > Great. Thanks for the review. > > Peter > > --94eb2c0600563114dc054bc392e4 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


On Sun= , Mar 26, 2017 at 11:48 AM Peter Saint-Andre <stpeter@stpeter.im> wrote:
On 3/25/17 9:09 PM, Peter Thatcher wrote:
> Ari and I reviewed the latest Trickle ICE draft in preparation for goi= ng
> to WGLC and found a few more things worth considering fixing:
>
> - Some minor editorial issues that have separately been sent to the au= thors.

Received.

> - The name "ICE negotiation session" with definition of &quo= t;A virtual
> session ..." is confusing.=C2=A0 =C2=A0I understand that we need = a word for
> "period between restarts" and "period across restarts&q= uot;.=C2=A0 But what does
> "virtual" mean in this context?=C2=A0 And what does "ne= gotiation" mean in
> "ICE negotiation session"?=C2=A0 Here's a possible sugge= stion: call it
> "single-exchange session".=C2=A0 =C2=A0A single-exchange ses= sion is the period
> from a single exchange of ICE description until the next exchange.=C2= =A0 A
> "normal" ICE session is basically a multi-exchange session.<= br class=3D"gmail_msg">
This might be clearer:

=C2=A0 =C2=A0ICE Session:=C2=A0 All of the ICE-related interactions between= ICE agents
=C2=A0 =C2=A0 =C2=A0 up until an ICE restart (if any).

However, that definition probably belongs in 5245bis. The term as used
in the Trickle specification is not limited to interactions between
Trickle ICE agents.


I like that idea o= f using "ICE session" to mean the thing between restarts as long = as it's compatible with 5245 and 5245bis and it doesn't cause confu= sion such that people think an "ICE session" is the time period a= cross all ICE restarts.

I originally thought it sh= ould go in 5245bis also, but Ari thought it didn't make sense there sin= ce it would never use the term after defining it. =C2=A0
=C2=A0
> - In the phrase " A Trickle ICE agent MUST NOT pair a local candi= date
> until it has been trickled to the remote agent.", what does "= ;has been
> trickled" mean?=C2=A0 That it's been sent on the network?=C2= =A0 When it's been
> acked by the remote side?=C2=A0 When it is in queue such that it will = later
> be put on the network?=C2=A0 It seems really hard to pin down an appro= priate
> time when something "has been trickled".

In the interest of startup time, I'd say that a candidate has been
trickled when it has been sent. Waiting for acks might slow things down.
> And then in a WebRTC context,
> the app might never signal a candidate (in a client->server use cas= e).
> What then?

I don't think we had considered that case.

> And it's not clear to me why this is even useful.=C2=A0 =C2=A0Can = we
> just remove it?=C2=A0 Or is there something important here?

It doesn't seem critically important to me, but I might be missing
something.

I think = there's still the issue of what does "sent" mean?=C2=A0 In th= e network buffer of the OS kernel ready to go out?=C2=A0 In a queue on a &q= uot;network thread" that's going to give it to the OS kernel to go= out? =C2=A0 Does it actually have to be on the network or just queued to b= e so later? =C2=A0

If we don't need it, I'= d say we just remove it.=C2=A0 Doubly so if we can't even be sure what = it means.
=C2=A0

> - The paragraph "Note: So that both agents will have the same vie= w of
> candidate priorities, it is important to replacing existing pairs with=
> seemingly equivalent higher-priority ones and to always update
> peer-reflexive candidates if equivalent alternatives are received
> through signaling." seems duplicate with other parts in the doc.= =C2=A0 Do we
> even need this paragraph?

You're right, these guidelines are indeed mentioned elsewhere. Let'= s
remove them here.

> - "Either agent MAY generate a subsequent ICE description at any = time
> allowed by RFC3264".=C2=A0 This causes ICE to be dependent on SDP= , which we
> were trying to avoid.=C2=A0 Was this just one place where we missed re= moving
> a dependency on SDP?=C2=A0 I would suggest removing it or replacing it= with
> the phrase "Either agent MAY generate subsequent ICE descriptions= at any
> time", unless there is a clear time when an ICE agent cannot (and= I
> can't think of one).

This seems to be a stray mention of RFC 3264 that was not removed in
earlier editing. Perhaps "Either agent MAY generate a subsequent ICE description at any time allowed by the signaling protocol in use" (we<= br class=3D"gmail_msg"> don't want to override any other protocol's rules here).


Deferring to the s= ignaling protocol sounds like a good idea.

And sho= uld it be "generate" or "send" a subsequent ICE descrip= tion? =C2=A0=C2=A0
=C2=A0
> As soon as these are resolved, we believe we can go to WGLC.

Great. Thanks for the review.

Peter

--94eb2c0600563114dc054bc392e4-- From nobody Mon Mar 27 22:26:54 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 560F5127735 for ; Mon, 27 Mar 2017 22:26:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.001 X-Spam-Level: X-Spam-Status: No, score=-2.001 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-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=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 qpecTxgGZBJu for ; Mon, 27 Mar 2017 22:26:49 -0700 (PDT) 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 B968A129682 for ; Mon, 27 Mar 2017 22:26:44 -0700 (PDT) Received: by mail-qt0-x231.google.com with SMTP id i34so55620936qtc.0 for ; Mon, 27 Mar 2017 22:26:44 -0700 (PDT) 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=R817saAAJFxje6NwJ4euCQtUJ3m5nC1XzS+esMnUn0g=; b=d1lWhSDIBilKokuP2cMIowmCQN/sCpNnckygbXoKOYH+5dNaNUiiy7XKFVfP2wzqSt +lxz6c2Qfiaa5E0boXKiTavvY9WUXMdLMnCSOoi2b0SWj5EQ8RZUemTE10sM6+e27XVk yzpZBud4NqE7XCLdKNo71oT7D1Rske9LUkirO/XMzLhHNV1oih8fq6PUCi/lRDfl2S3D wfwMIcGgUrbdW8xrYDcC/ymv7OCZVAeBdwBb+FEkXWdRHzbm1l3uq8bMH/W6TSeLxwvo lRC7LR7xV7s3EQjAr1KTw11tsgJXJ3zxvXL/yFkS/24pdOfK/8D3kDARhUlKaPuYoRwY tSxg== 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=R817saAAJFxje6NwJ4euCQtUJ3m5nC1XzS+esMnUn0g=; b=sZAfcCrO1PWwvnepa8vaDFYfT9Q+nm/SDjMjW9jmaWUsuvxjgqH7oo6EyH9iu0yOHX 4rDzv7m5QQFn0QSyZeEKvtVEFKmmZcVAw1buSvL7tBDy4W3xAjWQ3INFz/BsiuW20E+I 3CB4wxNZlWnCC+BXs7fmSoBK+OR2lx/LJe/z60ywLKQhyBj4XuwaOTYAlZGH5u/8ijz/ RPVK2RTR6azwyvyJ4lTj2TSb9ULGfD6apGw7o9N2NJI+6tqdO+snRqw28DRHuARh6bf0 gmiWG2SywYZCqG/fJAy/4f59h8zLIx83lzJm3sKILCMufC1KwdGAcxqFLOID3drsP1sw yFdw== X-Gm-Message-State: AFeK/H0hHcrSfslemD0RWOhgiZh43LzfX8tdT1sCCKoXIWh7nULfLPqNHCgI81QU/B35oEtCjW+dSWXFgrxe4YG0 X-Received: by 10.237.36.53 with SMTP id r50mr2759726qtc.46.1490678803712; Mon, 27 Mar 2017 22:26:43 -0700 (PDT) MIME-Version: 1.0 References: <1490639703264.61625@cisco.com> <29ccb451-c8ab-d24c-d3bf-b89e88aded41@acm.org> <043179B9-2EBE-4BC3-A040-2FF380FAEA51@cisco.com> <7594FB04B1934943A5C02806D1A2204B4CB30AB4@ESESSMB109.ericsson.se> In-Reply-To: From: Peter Thatcher Date: Tue, 28 Mar 2017 05:26:33 +0000 Message-ID: To: Emil Ivov , Christer Holmberg Cc: Marc Petit-Huguenin , "Pal Martinsen (palmarti)" , Roman Shpount , "ice@ietf.org" Content-Type: multipart/alternative; boundary=001a113c7148924464054bc3b464 Archived-At: Subject: Re: [Ice] ICE on the Side (Side meeting IETF Chicago) X-BeenThere: ice@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "Interactive Connectivity Establishment \(ICE\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 28 Mar 2017 05:26:52 -0000 --001a113c7148924464054bc3b464 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Same here. I would gladly join remotely this week. Sorry to have missed this one. On Mon, Mar 27, 2017 at 2:08 PM Emil Ivov wrote: > Same here. Saw this mail too late. Maybe we can schedule another one? > > On Mon, Mar 27, 2017 at 3:57 PM, Christer Holmberg > wrote: > > Hi, > > > > I didn't see your e-mail until now, so unfortunately I missed the > meeting :( Sorry for that. > > > > Regards, > > > > Christer > > > > -----Original Message----- > > From: Ice [mailto:ice-bounces@ietf.org] On Behalf Of Pal Martinsen > (palmarti) > > Sent: 27 March 2017 23:21 > > To: Marc Petit-Huguenin > > Cc: Roman Shpount ; ice@ietf.org > > Subject: Re: [Ice] ICE on the Side (Side meeting IETF Chicago) > > > > > >> On 27 Mar 2017, at 14:54, Marc Petit-Huguenin wrote= : > >> > >> On 03/27/2017 01:35 PM, Pal Martinsen (palmarti) wrote: > >>> Doodle poll closed and it seems like Monday at 15:30 Chicago time > suits all. > >>> > >>> > >>> See you all i the IETF lobby. > >> > >> I suppose that by lobby you mean IETF registration, right? > >> > > > > The word I was intending to use was lounge=E2=80=A6 Same floor as the > registration but the other end. > > > > IETF lounge > > > > .-. > > P=C3=A5l-Erik > > > > > >>> > >>> For remote participants try: > >>> https://appear.in/iceontheside > >>> > >>> > >>> .-. > >>> > >>> P=C3=A5l-Erik > >>> > >>> > >>> --------------------------------------------------------------------- > >>> ----------- > >>> *From:* Roman Shpount > >>> *Sent:* Monday, March 27, 2017 11:21 AM > >>> *To:* Pal Martinsen (palmarti) > >>> *Cc:* ice@ietf.org > >>> *Subject:* Re: [Ice] ICE on the Side (Side meeting IETF Chicago) Is > >>> there any way to participate in this remotely? > >>> > >>> _____________ > >>> Roman Shpount > >>> > >>> On Mon, Mar 27, 2017 at 10:14 AM, Pal Martinsen (palmarti) > >>> > wrote: > >>> > >>> Hi, > >>> > >>> If there is any interest of a quick =E2=80=9CICE on the side=E2=80= =9D meting I have > >>> created a doodle poll at: > >>> https://doodle.com/poll/zyv98qpvzwz2xf6r > >>> > >>> > >>> > >>> (And if you have any ICE TLS candidates comments please grab me in > >>> the > >>> hallways.) > >>> .-. > >>> P=C3=A5l-Erik > >>> > >>> > >>> > >>> _______________________________________________ > >>> Ice mailing list > >>> Ice@ietf.org > >>> https://www.ietf.org/mailman/listinfo/ice > >>> > >>> > >>> > >>> > >>> > >>> _______________________________________________ > >>> Ice mailing list > >>> Ice@ietf.org > >>> https://www.ietf.org/mailman/listinfo/ice > >>> > >> > >> > > > > _______________________________________________ > > Ice mailing list > > Ice@ietf.org > > https://www.ietf.org/mailman/listinfo/ice > > _______________________________________________ > > Ice mailing list > > Ice@ietf.org > > https://www.ietf.org/mailman/listinfo/ice > > > > -- > https://jitsi.org > > _______________________________________________ > Ice mailing list > Ice@ietf.org > https://www.ietf.org/mailman/listinfo/ice > --001a113c7148924464054bc3b464 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Same here.=C2=A0 I would gladly join remotely this week. = =C2=A0

Sorry to have missed this one.

On Mon, Mar 27, 2017 at 2:08 PM Em= il Ivov <emcho@jitsi.org> wrot= e:
Same here. Saw this mail too lat= e. Maybe we can schedule another one?

On Mon, Mar 27, 2017 at 3:57 PM, Christer Holmberg
<christer.holmberg@ericsson.com> wrote:
> Hi,
>
> I didn't see your e-mail until now, so unfortunately I missed the = meeting :( Sorry for that.
>
> Regards,
>
> Christer
>
> -----Original Message-----
> From: Ice [mailto:ice-bounces@ietf.org] On Behalf Of Pal Martin= sen (palmarti)
> Sent: 27 March 2017 23:21
> To: Marc Petit-Huguenin <petithug@acm.org>
> Cc: Roman Shpount <roman@telurix.com>; ice@ietf.org
> Subject: Re: [Ice] ICE on the Side (Side meeting IETF Chicago)
>
>
>> On 27 Mar 2017, at 14:54, Marc Petit-Huguenin <petithug@acm.org<= /a>> wrote:
>>
>> On 03/27/2017 01:35 PM, Pal Martinsen (palmarti) wrote:
>>> Doodle poll closed and it seems like Monday at 15:30 Chicago t= ime suits all.
>>>
>>>
>>> See you all i the IETF lobby.
>>
>> I suppose that by lobby you mean IETF registration, right?
>>
>
> The word I was intending to use was lounge=E2=80=A6 Same floor as the = registration but the other end.
>
> IETF lounge
>
> .-.
> P=C3=A5l-Erik
>
>
>>>
>>> For remote participants try:
>>> https://appear.in/iceontheside >>>
>>>
>>> .-.
>>>
>>> P=C3=A5l-Erik
>>>
>>>
>>> --------------------------------------------------------------= -------
>>> -----------
>>> *From:* Roman Shpount <roman@telurix.com>
>>> *Sent:* Monday, March 27, 2017 11:21 AM
>>> *To:* Pal Martinsen (palmarti)
>>> *Cc:* ice@ietf.org
>>> *Subject:* Re: [Ice] ICE on the Side (Side meeting IETF Chicag= o) Is
>>> there any way to participate in this remotely?
>>>
>>> _____________
>>> Roman Shpount
>>>
>>> On Mon, Mar 27, 2017 at 10:14 AM, Pal Martinsen (palmarti)
>>> <palmarti@cisco.com <mailto:palmarti@cisco.com= >> wrote:
>>>
>>>=C2=A0 Hi,
>>>
>>>=C2=A0 If there is any interest of a quick =E2=80=9CICE on the = side=E2=80=9D meting I have
>>> created=C2=A0 a doodle poll at:
>>>=C2=A0 https://doodle.com/po= ll/zyv98qpvzwz2xf6r
>>>=C2=A0 <https://doodle.co= m/poll/zyv98qpvzwz2xf6r>
>>>
>>>
>>>=C2=A0 (And if you have any ICE TLS candidates comments please = grab me in
>>> the
>>>=C2=A0 hallways.)
>>>=C2=A0 .-.
>>>=C2=A0 P=C3=A5l-Erik
>>>
>>>
>>>
>>>=C2=A0 _______________________________________________
>>>=C2=A0 Ice mailing list
>>>=C2=A0 Ice@ietf.org <mailto:Ice@ietf.org>
>>>=C2=A0 https://www.ietf.org= /mailman/listinfo/ice
>>>=C2=A0 <https://www.ietf= .org/mailman/listinfo/ice>
>>>
>>>
>>>
>>>
>>> _______________________________________________
>>> Ice mailing list
>>> Ice@ietf.org
>>> https://www.ietf.org/mailm= an/listinfo/ice
>>>
>>
>>
>
> _______________________________________________
> Ice mailing list
> = Ice@ietf.org
> https://www.ietf.org/mailman/listi= nfo/ice
> _______________________________________________
> Ice mailing list
> = Ice@ietf.org
> https://www.ietf.org/mailman/listi= nfo/ice



--
https://jitsi.org

_______________________________________________
Ice mailing list
Ice@i= etf.org
https://www.ietf.org/mailman/listinfo/i= ce
--001a113c7148924464054bc3b464-- From nobody Tue Mar 28 07:29:45 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 3083D129545 for ; Tue, 28 Mar 2017 07:29:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.523 X-Spam-Level: X-Spam-Status: No, score=-14.523 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=-0.001, 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 g3x2bBrFbBYO for ; Tue, 28 Mar 2017 07:29:42 -0700 (PDT) Received: from rcdn-iport-8.cisco.com (rcdn-iport-8.cisco.com [173.37.86.79]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AF33E1294CD for ; Tue, 28 Mar 2017 07:29:42 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1126; q=dns/txt; s=iport; t=1490711382; x=1491920982; h=from:to:subject:date:message-id:content-id: content-transfer-encoding:mime-version; bh=x26PSMp8Aij0q9sAVeXiQNC44OxwsLTyiCYNeuxnQ0I=; b=JjDf7m7rMO6CxN5D45g22/DHgmGbemmQA/yenrHZGnYjNaFpxOS6EK0N NP6YQKbRhZr5mo0v9hUozrjAvjiet9JK33jcRy0cS7tLCTFQipoOvxEp6 ux5X1mRC9M5yrhHjFL5ghtzf6GMTwa9B4UhjREuCoo+BEVUR6towlQ/1I Y=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0BRAwAVctpY/5pdJa1dGwEBAQMBAQEJA?= =?us-ascii?q?QEBg1SBc4Nbig+RMpVrgg6GPoMHPxgBAgEBAQEBAQFrHQuFPxFXASICJgIEMBU?= =?us-ascii?q?SBIoanGOQBoImikoBAQEBAQUBAQEBAQEBASCBC4VDggUIijwugjEFnGABjUyFA?= =?us-ascii?q?oF8GIUSiFOBOpNpAR84PkZZFVIBhkaJVYENAQEB?= X-IronPort-AV: E=Sophos;i="5.36,236,1486425600"; d="scan'208";a="223965978" Received: from rcdn-core-3.cisco.com ([173.37.93.154]) by rcdn-iport-8.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 28 Mar 2017 14:29:41 +0000 Received: from XCH-RTP-017.cisco.com (xch-rtp-017.cisco.com [64.101.220.157]) by rcdn-core-3.cisco.com (8.14.5/8.14.5) with ESMTP id v2SETfGc001346 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL) for ; Tue, 28 Mar 2017 14:29:41 GMT Received: from xch-rtp-019.cisco.com (64.101.220.159) by XCH-RTP-017.cisco.com (64.101.220.157) with Microsoft SMTP Server (TLS) id 15.0.1210.3; Tue, 28 Mar 2017 10:29:40 -0400 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, 28 Mar 2017 10:29:40 -0400 From: "Pal Martinsen (palmarti)" To: "ice@ietf.org" Thread-Topic: ICE on the side IETF98 summary Thread-Index: AQHSp8+8f/1Mfa0C8UOuFXwruya+kA== Date: Tue, 28 Mar 2017 14:29:40 +0000 Message-ID: <20FECD32-A610-4649-B6C3-EF5491D5CBE6@cisco.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.24.23.94] Content-Type: text/plain; charset="utf-8" Content-ID: Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: Subject: [Ice] ICE on the side IETF98 summary X-BeenThere: ice@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "Interactive Connectivity Establishment \(ICE\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 28 Mar 2017 14:29:44 -0000 SGksDQoNCkFwb2xvZ2llcyBmb3Igc2hvcnQgbm90aWNlIGFuZCB0aGUgcG9vcmx5IHBsYW5uZWQg cmVtb3RlIHBhcnRpY2lwYXRpb24gb3B0aW9ucy4NCg0KRGlzY2xhaW1lciwgdGhpcyB3YXMgbm90 IGFuIG9mZmljaWFsIFdHIG1lZXRpbmcgYW5kIHdhcyBqdXN0IGluZm9ybWFsIGRpc2N1c3Npb25z LCBidXQgb3Blbm5lc3MgaXMgYWx3YXlzIGdvb2Qgc28gcG9zdGluZyBhIHN1bW1hcnkgaGVyZS4N Cg0KSUNFIFRMUw0KLSBEZW11eCBwb2ludCB3aGVuIHJ1bm5pbmcgNDQzLiBXaGF0IGNhbGwgaXMg dGhlIGluY29tbWluZyBjb25uZWN0aW9uIGZvcj8NCi0gQUxQTg0KDQpPdGhlcg0KLSBJUFY2IGFu ZCBJQ0UtVENQPyBCZXR0ZXIgY29ubmVjdGl2aXR5Pw0KLSBXaGF0IGRvIElTUCBkbyB3aGVuIGRl cGxveWluZz8gRlc/IEVtdWxhdGUgTkFUIGJlaGF2aW91cj8gRmlsdGVyIHBvcnRzDQoNCklDRSB2 Mg0KLSBTdGFydCByZXF1aXJlbWVudHMgZG9jdW1lbnQ/DQogICAtIENvbnRpbnVvdXMgcmUtbm9t aW5hdGlvbg0KICAgLSBXaGVuIGNhbiBsb2NhbCBzb2NrZXRzIGJlIGNsb3NlZD8NCiAgIC0gRHlu YW1pYyBiZWhhdmlvdXIgKEJldHRlciBwYXRoIGF2YWlsYWJsZSkNCiAgIC0gR2VuZXJhbCBtdWx0 aXBhdGggc3VwcG9ydCAoSVAsIFRDUCwgVExTKQ0KICAgLSBNb2JpbGl0eQ0KDQpQYXRoIE1UVSBk aXNjb3ZlcnkNCi0gUHVzaGVkIHRvIElDRSBieSBESVNQQUNUSA0KLSBIb3csIHdoZW4gZXRjLi4N Cg0KLSBISVAgV29ya2luZ2dyb3VwDQogIC0gSUNFIGZvciBISVAgZHJhZnQgKFBsZWFzZSByZXZp ZXcpDQoNCg0KLi0uDQpQw6VsLUVyaWs= From nobody Tue Mar 28 08:45:04 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 22F2612945C for ; Tue, 28 Mar 2017 08:45:03 -0700 (PDT) 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 SUK5IilUASTU for ; Tue, 28 Mar 2017 08:44:54 -0700 (PDT) Received: from sesbmg23.ericsson.net (sesbmg23.ericsson.net [193.180.251.37]) (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 8877F129568 for ; Tue, 28 Mar 2017 08:44:50 -0700 (PDT) X-AuditID: c1b4fb25-0b71498000002d78-a5-58da84f0abe8 Received: from ESESSHC007.ericsson.se (Unknown_Domain [153.88.183.39]) by (Symantec Mail Security) with SMTP id 91.0D.11640.0F48AD85; Tue, 28 Mar 2017 17:44:48 +0200 (CEST) Received: from ESESSMB109.ericsson.se ([169.254.9.242]) by ESESSHC007.ericsson.se ([153.88.183.39]) with mapi id 14.03.0339.000; Tue, 28 Mar 2017 17:43:23 +0200 From: =?iso-8859-1?Q?Ari_Ker=E4nen?= To: "ice@ietf.org" Thread-Topic: [Ice] ICE on the side IETF98 summary Thread-Index: AQHSp8+8f/1Mfa0C8UOuFXwruya+kKGqQueA Date: Tue, 28 Mar 2017 15:43:22 +0000 Message-ID: References: <20FECD32-A610-4649-B6C3-EF5491D5CBE6@cisco.com> In-Reply-To: <20FECD32-A610-4649-B6C3-EF5491D5CBE6@cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [153.88.183.149] Content-Type: text/plain; charset="iso-8859-1" Content-ID: <6AC41D5279570D418859F4DD637C0820@ericsson.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFvrNLMWRmVeSWpSXmKPExsUyM2K7uu6HllsRBo/fGFl8u1DrwOixZMlP pgDGKC6blNSczLLUIn27BK6Mb1uNC6YwV7w6L9bAeIqpi5GTQ0LAROLDv7NANheHkMB6RolJ u/pZIJwljBLnFm9nAaliE7CXmLzmIyOILSKgKDGz5RkziC0sYChxb/9/Zoi4kcSjQ0/YYeyZ v/+xdTFycLAIqEr8fiINEuYFGvPt5j2wxUICNhLXLneD2ZwCthJPDq8GW8UoICbx/dQasDiz gLjErSfzoQ4VkFiy5zwzhC0q8fLxP1YIW0li7WGIM5kF9CRuTJ3CBmFbS6ybuJsdwtaWWLbw NTPEDYISJ2c+YZnAKDoLyYpZSNpnIWmfhaR9FpL2BYysqxhFi1OLk3LTjYz1Uosyk4uL8/P0 8lJLNjECo+Tglt+qOxgvv3E8xCjAwajEw/tA6maEEGtiWXFl7iFGCQ5mJRHeb9xAId6UxMqq 1KL8+KLSnNTiQ4zSHCxK4ryO+y5ECAmkJ5akZqemFqQWwWSZODilGhgZMoRc1jV7Cyatj281 3tnw8J7ULKdnSqYTts+J02LcIvg15UqGal1KT4elzH6rWdd/SVlaGzlmvXAz+TjF9vnj1VXr HmmZ33s5VbvIgjfR/3YQf/ulrmlcVuK/CtbOUOOvctnqrq/Pv7o0+Iue38F9PXNlYmI4GDIO lqhk6Kso19XNi9uzTImlOCPRUIu5qDgRAMcUBQOOAgAA Archived-At: Subject: Re: [Ice] ICE on the side IETF98 summary X-BeenThere: ice@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "Interactive Connectivity Establishment \(ICE\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 28 Mar 2017 15:45:03 -0000 > On 28 Mar 2017, at 09:29, Pal Martinsen (palmarti) w= rote: >=20 > - ICE for HIP draft (Please review) Here's the latest revision: https://tools.ietf.org/html/draft-ietf-hip-nati= ve-nat-traversal-19 The draft is currently in WGLC and was just updated to address review comme= nts. Please send comments to the HIP WG mailing list (hipsec@ietf.org). Thanks, Ari= From nobody Tue Mar 28 09:27:49 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 88D0512945F for ; Tue, 28 Mar 2017 09:27:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.721 X-Spam-Level: X-Spam-Status: No, score=-2.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_LOW=-0.7, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=stpeter.im header.b=kCZE5x3I; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=eR3VFR75 Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ILNEPKyW9wNo for ; Tue, 28 Mar 2017 09:27:45 -0700 (PDT) Received: from out1-smtp.messagingengine.com (out1-smtp.messagingengine.com [66.111.4.25]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2600D12944B for ; Tue, 28 Mar 2017 09:27:45 -0700 (PDT) Received: from compute2.internal (compute2.nyi.internal [10.202.2.42]) by mailout.nyi.internal (Postfix) with ESMTP id 9480120804; Tue, 28 Mar 2017 12:27:44 -0400 (EDT) Received: from frontend2 ([10.202.2.161]) by compute2.internal (MEProxy); Tue, 28 Mar 2017 12:27:44 -0400 DKIM-Signature: v=1; a=rsa-sha256; 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=fm1; bh=ogwqFhVPDctdgMR3Td dpVjo2nQ6ZdGR8MWes59IFoiA=; b=kCZE5x3IUWXXD77zLh+W8Pjx1NJFvVqd1G OABZUFKlPZqUa1fQxRn2VZGEbSLsdcnIuYfp4TnDP4T32isZCpq2N5lJ0ndRMZOQ 3wwfuFQFx5GQw0YTufbiY2s1AlwQNREGHdoaSDrh7iL4d5rekePh6FuGwq42JWck b8POihKGtLroQWyAqU9MvbPcGa1XoFuAwqDA7A8tuUDQUGYWuqaJvIlmlbKoXUN/ kWeofiD7sJIkcKGkaH3X90KolandYNz66tKGp9hpsXjgzrBLR16cpMHYI66OiG3e rL8E7dsCUCBYYHa/QvS5a1rXT0U1BYgZzAc2FNohE1VunMSXBaRA== DKIM-Signature: v=1; a=rsa-sha256; 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= fm1; bh=ogwqFhVPDctdgMR3TddpVjo2nQ6ZdGR8MWes59IFoiA=; b=eR3VFR75 ioJ3hXDNkwReij5ayvpGjIR9ogjWvtgjFOoui6RjuC5+7QpAcWBkpf+4Abo/MA0R Mpu1pl5Ybda0eVFGuekk0Fb/WbKkB3+nqa44dG0fasBabIU1y1R+krgBBccCvz4L uqewi9gk54FcwkFENLm1/AYkB85iyo/1VWuP9hxEeaIBedfQAj3tw9FypCUT+Cyb J6rH6PDKRXAqHMfX8+gINK1ayEDJqCTXBsskCrkj3hUTwNHjXmod7QnQgKGvhBdq i2rys/AN++fX3luTe3LI/YxQn8fnfqhzadV2TGp7liRa7mJExjxwD/fEWd8vQdKR GR7eXqG7/TenjA== X-ME-Sender: X-Sasl-enc: dKEAVgKZ5zqhWNfmaVJzzemTMCI/+unJ2jvqVyCJ3wH3 1490718464 Received: from aither.local (c-98-245-40-52.hsd1.co.comcast.net [98.245.40.52]) by mail.messagingengine.com (Postfix) with ESMTPA id 02894246CA; Tue, 28 Mar 2017 12:27:43 -0400 (EDT) To: Peter Thatcher , "ice@ietf.org" References: <7ebb3254-a882-6e05-3159-0ec56614831b@stpeter.im> From: Peter Saint-Andre Message-ID: <7e9e8188-2add-0497-e94f-14ee41afe02d@stpeter.im> Date: Tue, 28 Mar 2017 10:27:43 -0600 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.12; rv:45.0) Gecko/20100101 Thunderbird/45.8.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [Ice] Trickle ICE review X-BeenThere: ice@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "Interactive Connectivity Establishment \(ICE\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 28 Mar 2017 16:27:48 -0000 On 3/27/17 11:16 PM, Peter Thatcher wrote: > > > On Sun, Mar 26, 2017 at 11:48 AM Peter Saint-Andre > wrote: > > On 3/25/17 9:09 PM, Peter Thatcher wrote: > > Ari and I reviewed the latest Trickle ICE draft in preparation for > going > > to WGLC and found a few more things worth considering fixing: > > > > - Some minor editorial issues that have separately been sent to > the authors. > > Received. > > > - The name "ICE negotiation session" with definition of "A virtual > > session ..." is confusing. I understand that we need a word for > > "period between restarts" and "period across restarts". But what does > > "virtual" mean in this context? And what does "negotiation" mean in > > "ICE negotiation session"? Here's a possible suggestion: call it > > "single-exchange session". A single-exchange session is the period > > from a single exchange of ICE description until the next exchange. A > > "normal" ICE session is basically a multi-exchange session. > > This might be clearer: > > ICE Session: All of the ICE-related interactions between ICE agents > up until an ICE restart (if any). > > However, that definition probably belongs in 5245bis. The term as used > in the Trickle specification is not limited to interactions between > Trickle ICE agents. > > > I like that idea of using "ICE session" to mean the thing between > restarts as long as it's compatible with 5245 and 5245bis and it doesn't > cause confusion such that people think an "ICE session" is the time > period across all ICE restarts. > > I originally thought it should go in 5245bis also, but Ari thought it > didn't make sense there since it would never use the term after defining > it. It's already used in 5245bis, isn't it? But we can continue to define it in Trickle. > > - In the phrase " A Trickle ICE agent MUST NOT pair a local candidate > > until it has been trickled to the remote agent.", what does "has been > > trickled" mean? That it's been sent on the network? When it's been > > acked by the remote side? When it is in queue such that it will later > > be put on the network? It seems really hard to pin down an > appropriate > > time when something "has been trickled". > > In the interest of startup time, I'd say that a candidate has been > trickled when it has been sent. Waiting for acks might slow things down. > > > And then in a WebRTC context, > > the app might never signal a candidate (in a client->server use case). > > What then? > > I don't think we had considered that case. > > > And it's not clear to me why this is even useful. Can we > > just remove it? Or is there something important here? > > It doesn't seem critically important to me, but I might be missing > something. > > > I think there's still the issue of what does "sent" mean? In the > network buffer of the OS kernel ready to go out? In a queue on a > "network thread" that's going to give it to the OS kernel to go out? > Does it actually have to be on the network or just queued to be so later? > > If we don't need it, I'd say we just remove it. Doubly so if we can't > even be sure what it means. I'd say let's cut it. > > - The paragraph "Note: So that both agents will have the same view of > > candidate priorities, it is important to replacing existing pairs with > > seemingly equivalent higher-priority ones and to always update > > peer-reflexive candidates if equivalent alternatives are received > > through signaling." seems duplicate with other parts in the doc. > Do we > > even need this paragraph? > > You're right, these guidelines are indeed mentioned elsewhere. Let's > remove them here. > > > - "Either agent MAY generate a subsequent ICE description at any time > > allowed by RFC3264". This causes ICE to be dependent on SDP, which we > > were trying to avoid. Was this just one place where we missed > removing > > a dependency on SDP? I would suggest removing it or replacing it with > > the phrase "Either agent MAY generate subsequent ICE descriptions > at any > > time", unless there is a clear time when an ICE agent cannot (and I > > can't think of one). > > This seems to be a stray mention of RFC 3264 that was not removed in > earlier editing. Perhaps "Either agent MAY generate a subsequent ICE > description at any time allowed by the signaling protocol in use" (we > don't want to override any other protocol's rules here). > > > Deferring to the signaling protocol sounds like a good idea. > > And should it be "generate" or "send" a subsequent ICE description? I thought we didn't know the meaning of send. :-) Peter From nobody Tue Mar 28 09:32: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 1C117129446 for ; Tue, 28 Mar 2017 09:32:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.389 X-Spam-Level: X-Spam-Status: No, score=-1.389 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_NONE=-0.0001, RCVD_IN_SORBS_SPAM=0.5, T_SPF_PERMERROR=0.01] autolearn=no 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 M79inUUjXM5n for ; Tue, 28 Mar 2017 09:32:04 -0700 (PDT) Received: from mail-pg0-x233.google.com (mail-pg0-x233.google.com [IPv6:2607:f8b0:400e:c05::233]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CFA8B126C26 for ; Tue, 28 Mar 2017 09:32:03 -0700 (PDT) Received: by mail-pg0-x233.google.com with SMTP id 21so77521192pgg.1 for ; Tue, 28 Mar 2017 09:32:03 -0700 (PDT) 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=bgynMkPQ50qJ8ciI/kR3x8G4zhTcHki0XEkg1kXHDU0=; b=RqhReia7levFQ+n28VFMNFpqK/KGUJn3RtrwmY9nJCWcCPX4t9eKbUjctlQoSXLtm8 4QCvDE8BAhiZ/NitYnq361RWSaAAeNFMWF48LagcJ+DiVxCIY0HDxfVk1ZI7drsOXGKq FyoxTahg54dI6qPlfuvzPy+xEIveW485evYMnOqJ08gnLXvUzQr+oj1c3vHqhun+OOHe DG3kb99I3k7a66tTEqp4tJ3NqtrTxSqlIYPjMSazckvI8d6g8alN+eKA/Oe+QQxF619z FQ1H3sHb61sQHN8mBdHpZn9/Gyl05tdP6CceOK/j5jLyg3y8yN4upFHZGOmuDGCwjCGC at9g== 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=bgynMkPQ50qJ8ciI/kR3x8G4zhTcHki0XEkg1kXHDU0=; b=dDq0wv0N6b/PPURvyre9ZR3QY6S7oDqbFZNYSjogRG4wGY+IW/Va6WiLOK7uvTnPqz Bzu16nmLMur8TtNN+IlOzh4o4M0GRJkmCwL89lXU/G/E4wVsR72OW0gRLMkVLA7GrEET OannlK3ynKInw2WOe86DbH9R4q2HVZgmy4/BWdNFnuMu4ByBlU/VeBx+NXEJtJYsR/TN zoM3B6f4Ejjv96roIGuunsaEHmFcryI6JMEZNRGU94J2bXu9joOKxL56XLku/ApQcbrb /MP/ze4ajO7oUHiow8tyVAquGR/PADFlCwGJKeyfwErbuB9G9Pp/j9fGwtBfzk7qk2em zXOg== X-Gm-Message-State: AFeK/H1mEdIlHyh7VmPJJqV+49IEc04IMz2Sa9f/pns1FmTRt3IitJEeX9wL4VSqTNYh0Q== X-Received: by 10.84.237.22 with SMTP id s22mr38029838plk.145.1490718723130; Tue, 28 Mar 2017 09:32:03 -0700 (PDT) Received: from mail-pg0-f48.google.com (mail-pg0-f48.google.com. [74.125.83.48]) by smtp.gmail.com with ESMTPSA id t15sm8485480pfl.25.2017.03.28.09.32.02 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 28 Mar 2017 09:32:02 -0700 (PDT) Received: by mail-pg0-f48.google.com with SMTP id 21so77520608pgg.1 for ; Tue, 28 Mar 2017 09:32:02 -0700 (PDT) X-Received: by 10.99.225.5 with SMTP id z5mr31217129pgh.145.1490718722216; Tue, 28 Mar 2017 09:32:02 -0700 (PDT) MIME-Version: 1.0 Received: by 10.100.145.151 with HTTP; Tue, 28 Mar 2017 09:32:01 -0700 (PDT) In-Reply-To: <20FECD32-A610-4649-B6C3-EF5491D5CBE6@cisco.com> References: <20FECD32-A610-4649-B6C3-EF5491D5CBE6@cisco.com> From: Roman Shpount Date: Tue, 28 Mar 2017 12:32:01 -0400 X-Gmail-Original-Message-ID: Message-ID: To: "Pal Martinsen (palmarti)" Cc: "ice@ietf.org" Content-Type: multipart/alternative; boundary=001a114e93a4e5e03b054bccffcd Archived-At: Subject: Re: [Ice] ICE on the side IETF98 summary X-BeenThere: ice@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "Interactive Connectivity Establishment \(ICE\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 28 Mar 2017 16:32:06 -0000 --001a114e93a4e5e03b054bccffcd Content-Type: text/plain; charset=UTF-8 On Tue, Mar 28, 2017 at 10:29 AM, Pal Martinsen (palmarti) < palmarti@cisco.com> wrote: > ICE TLS > - Demux point when running 443. What call is the incomming connection for? > This can be no different then ICE-TCP. TLS connection is accepted and once STUN BIND message is received this connection, connection is assigned to a specific call based on ufrag in the STUN message. I have a related question -- do we want to validate certificates for this TLS connection, i.e. do something similar to fingerprint? I would assume not. Regards, _____________ Roman Shpount --001a114e93a4e5e03b054bccffcd Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On Tue, Mar 28, 2017 at 10:29 AM, Pal Martinsen (palmarti) <palmar= ti@cisco.com> wrote:
ICE TLS
- Demux point when running 443. What call is the incomming connection for?<= br>

This can be no different then ICE-TCP. = TLS connection is accepted and once STUN BIND message is received this conn= ection, connection is assigned to a specific call based on ufrag in the STU= N message.

I have a related question -- do we want= to validate certificates for this TLS connection, i.e. do something simila= r to fingerprint? I would assume not.

Regards,
_____________
Roman Shpount
<= /div>
=C2=A0
--001a114e93a4e5e03b054bccffcd-- From nobody Tue Mar 28 09:43:12 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 E498C12944B for ; Tue, 28 Mar 2017 09:43:10 -0700 (PDT) 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 wmQja-U39B6t for ; Tue, 28 Mar 2017 09:43:09 -0700 (PDT) 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 192E5129449 for ; Tue, 28 Mar 2017 09:43:08 -0700 (PDT) X-AuditID: c1b4fb2d-64c6598000005be8-c0-58da929b825f Received: from ESESSHC019.ericsson.se (Unknown_Domain [153.88.183.75]) by (Symantec Mail Security) with SMTP id 49.FD.23528.B929AD85; Tue, 28 Mar 2017 18:43:07 +0200 (CEST) Received: from ESESSMB109.ericsson.se ([169.254.9.242]) by ESESSHC019.ericsson.se ([153.88.183.75]) with mapi id 14.03.0339.000; Tue, 28 Mar 2017 18:43:06 +0200 From: =?iso-8859-1?Q?Ari_Ker=E4nen?= To: Peter Saint-Andre , Peter Thatcher CC: "ice@ietf.org" Thread-Topic: [Ice] Trickle ICE review Thread-Index: AQHSpd5vIiCBbI09wke1uNKUfji82aGnVe4AgAJB1wCAALtqgIAABEuA Date: Tue, 28 Mar 2017 16:43:06 +0000 Message-ID: References: <7ebb3254-a882-6e05-3159-0ec56614831b@stpeter.im> <7e9e8188-2add-0497-e94f-14ee41afe02d@stpeter.im> In-Reply-To: <7e9e8188-2add-0497-e94f-14ee41afe02d@stpeter.im> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [153.88.183.149] Content-Type: text/plain; charset="iso-8859-1" Content-ID: <240E01D555215740A2F74E6C7E11BED4@ericsson.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFprFIsWRmVeSWpSXmKPExsUyM2K7t+7sSbciDK43SVp8u1BrcW35a1aL Y3v6mR2YPRZsKvVYsuQnk8fcPS+YA5ijuGxSUnMyy1KL9O0SuDLu9S9hLmjkrVi2ZSJzA+N8 ri5GDg4JAROJTQtYuhi5OIQE1jNKfH18hg3CWcIocXT/WcYuRk4ONgF7iclrPoLZIgLBEvd/ bmIDaWYWUJR4uVcNJCwsoCpxfcMDdogSNYmLM3rYIGw3ifvrN4LZLEA1L9btYAGxeYFGtt34 zwix6z+jxJqr/8GaOQXsJLrnPGQGsRkFxCS+n1rDBGIzC4hL3HoyH8yWEBCQWLLnPDOELSrx 8vE/VghbSWLt4e0sEPV6EjemToG601qi7QUfRFhbYtnC18wQNwhKnJz5hGUCo9gsJBtmIeme hdA9C0n3LCTdCxhZVzGKFqcWF+emGxnrpRZlJhcX5+fp5aWWbGIExtjBLb91dzCufu14iFGA g1GJh/eB1M0IIdbEsuLK3EOMEhzMSiK837iBQrwpiZVVqUX58UWlOanFhxilOViUxHkd9l2I EBJITyxJzU5NLUgtgskycXBKNTDK5pnctv+4Z6rwls0X47P2W/NnfxJQefxOWrRuYaCu1qZb px9sf6C080ihrukO78tWTOoOFZOfn5h4yfjA9mX3nzkcur1k00OZhD/vIvey9SiY9YS99DTo ibBr331jlkLQhFsnKrfq3azaz1tduE/51hM7w2jVYw4BdW+n/GcQOpTlO/v2nU2flFiKMxIN tZiLihMB2d0Gla0CAAA= Archived-At: Subject: Re: [Ice] Trickle ICE review X-BeenThere: ice@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "Interactive Connectivity Establishment \(ICE\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 28 Mar 2017 16:43:11 -0000 > On 28 Mar 2017, at 11:27, Peter Saint-Andre wrote: >=20 >>> - The name "ICE negotiation session" with definition of "A virtual >>> session ..." is confusing. I understand that we need a word for >>> "period between restarts" and "period across restarts". But what does >>> "virtual" mean in this context? And what does "negotiation" mean in >>> "ICE negotiation session"? Here's a possible suggestion: call it >>> "single-exchange session". A single-exchange session is the period >>> from a single exchange of ICE description until the next exchange. A >>> "normal" ICE session is basically a multi-exchange session. >>=20 >> This might be clearer: >>=20 >> ICE Session: All of the ICE-related interactions between ICE agen= ts >> up until an ICE restart (if any). >>=20 >> However, that definition probably belongs in 5245bis. The term as use= d >> in the Trickle specification is not limited to interactions between >> Trickle ICE agents. >>=20 >>=20 >> I like that idea of using "ICE session" to mean the thing between >> restarts as long as it's compatible with 5245 and 5245bis and it doesn't >> cause confusion such that people think an "ICE session" is the time >> period across all ICE restarts. >>=20 >> I originally thought it should go in 5245bis also, but Ari thought it >> didn't make sense there since it would never use the term after defining >> it. =20 >=20 > It's already used in 5245bis, isn't it? But we can continue to define it > in Trickle. It's used but not defined actually. We'll add this to the terminology of 52= 45bis. Cheers, Ari= From nobody Tue Mar 28 10:05:28 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 3A262129454 for ; Tue, 28 Mar 2017 10:05:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.721 X-Spam-Level: X-Spam-Status: No, score=-2.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_LOW=-0.7, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=stpeter.im header.b=Z5eNsURs; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=Yo6oyuAb Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id eeIxL-3AXqa5 for ; Tue, 28 Mar 2017 10:05:25 -0700 (PDT) Received: from out1-smtp.messagingengine.com (out1-smtp.messagingengine.com [66.111.4.25]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 59146128C84 for ; Tue, 28 Mar 2017 10:05:25 -0700 (PDT) Received: from compute2.internal (compute2.nyi.internal [10.202.2.42]) by mailout.nyi.internal (Postfix) with ESMTP id C448E20C31; Tue, 28 Mar 2017 13:05:24 -0400 (EDT) Received: from frontend1 ([10.202.2.160]) by compute2.internal (MEProxy); Tue, 28 Mar 2017 13:05:24 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=stpeter.im; h=cc :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=fm1; bh=3DRqqXl07QiCrqW/fo K8fQYCdH1z/H8EbeOLVULQWbY=; b=Z5eNsURsoPrpAtzHQVs1FVcyWbH69jDHLr 1DRLqYX4jk/Rpplp8CKMoP5Rk0qRSEWYAwKUzMjsDka5cKSWvTnX6k3bAuGu7MLC eTj9rz8tGIsiaIVHTZXwsWo2ULcgNlneuvKaxY3oec4kczOxNQtHpXR7XO8+VVs1 fxbQsiZJVx67DDe8I6VDK3ovCrTdssFxcaQQmEcJHpXFL875VZtg0NcGweIjwMWr J/BVAK409pmYkIhbt8AxnLSf8TZ69+QZHvajA+2T66D4OQmAOYr7KkOqEx7tJUZ5 LOGXWgt98EaHUjzzlIbGqLgArDPveIv5t/jxmHhuUA6/30pzMEKA== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:content-transfer-encoding:content-type :date:from:in-reply-to:message-id:mime-version:references :subject:to:x-me-sender:x-me-sender:x-sasl-enc:x-sasl-enc; s= fm1; bh=3DRqqXl07QiCrqW/foK8fQYCdH1z/H8EbeOLVULQWbY=; b=Yo6oyuAb s/hRss57aJI0nwuw9wiLfAwIoOInaLPdCc9Uvp1iyTI9YuvbjXtv7FD/gfnO/q0J gY/mUI7OSuXJ5HUdzWOiHH3RqDYMpah3+vwW3BbYgjYgdYtSVGs8e0TQVnb4vVqF Ah26qG3x1F9CylCdstzRCx/cqmiDVkHBb7tAX34jBdZSuv1GgNyqPVtzFCbOKZ/X xv24f4S/Rh9ppWpobNB7EoWp/WX/I/mFLw5x3WLhl7eXFgc2CiiF4oiR6UMRCVMo b4dBEeuKJKb0dDRcceIX6L0AxHgwlrxER6c0mWEW4XMTg45g6a63pfQf+BiGDvO6 5zCQtaftgXE7oA== X-ME-Sender: X-Sasl-enc: 94SfEs/LuOHTAd4sE6EklKzMGtDp3cYUoGrUmLIG7XzG 1490720724 Received: from aither.local (c-98-245-40-52.hsd1.co.comcast.net [98.245.40.52]) by mail.messagingengine.com (Postfix) with ESMTPA id 443017E5D9; Tue, 28 Mar 2017 13:05:24 -0400 (EDT) To: =?UTF-8?Q?Ari_Ker=c3=a4nen?= , Peter Thatcher References: <7ebb3254-a882-6e05-3159-0ec56614831b@stpeter.im> <7e9e8188-2add-0497-e94f-14ee41afe02d@stpeter.im> Cc: "ice@ietf.org" From: Peter Saint-Andre Message-ID: <0c989dea-9318-b87c-3a90-0f6083efa16a@stpeter.im> Date: Tue, 28 Mar 2017 11:05:23 -0600 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.12; rv:45.0) Gecko/20100101 Thunderbird/45.8.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 8bit Archived-At: Subject: Re: [Ice] Trickle ICE review X-BeenThere: ice@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "Interactive Connectivity Establishment \(ICE\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 28 Mar 2017 17:05:27 -0000 On 3/28/17 10:43 AM, Ari Keränen wrote: > >> On 28 Mar 2017, at 11:27, Peter Saint-Andre wrote: >> >>>> - The name "ICE negotiation session" with definition of "A virtual >>>> session ..." is confusing. I understand that we need a word for >>>> "period between restarts" and "period across restarts". But what does >>>> "virtual" mean in this context? And what does "negotiation" mean in >>>> "ICE negotiation session"? Here's a possible suggestion: call it >>>> "single-exchange session". A single-exchange session is the period >>>> from a single exchange of ICE description until the next exchange. A >>>> "normal" ICE session is basically a multi-exchange session. >>> >>> This might be clearer: >>> >>> ICE Session: All of the ICE-related interactions between ICE agents >>> up until an ICE restart (if any). >>> >>> However, that definition probably belongs in 5245bis. The term as used >>> in the Trickle specification is not limited to interactions between >>> Trickle ICE agents. >>> >>> >>> I like that idea of using "ICE session" to mean the thing between >>> restarts as long as it's compatible with 5245 and 5245bis and it doesn't >>> cause confusion such that people think an "ICE session" is the time >>> period across all ICE restarts. >>> >>> I originally thought it should go in 5245bis also, but Ari thought it >>> didn't make sense there since it would never use the term after defining >>> it. >> >> It's already used in 5245bis, isn't it? But we can continue to define it >> in Trickle. > > It's used but not defined actually. We'll add this to the terminology of 5245bis. Right, I think that's the best place for it. Thanks! Peter From nobody Tue Mar 28 11:20: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 AA8131297CC for ; Tue, 28 Mar 2017 11:20:00 -0700 (PDT) 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 iyKTQe72-sgW for ; Tue, 28 Mar 2017 11:19:58 -0700 (PDT) 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 4A2CA12947C for ; Tue, 28 Mar 2017 11:19:58 -0700 (PDT) X-AuditID: c1b4fb2d-25fff70000005be8-cd-58daa94a05cf Received: from ESESSHC009.ericsson.se (Unknown_Domain [153.88.183.45]) by (Symantec Mail Security) with SMTP id 8E.69.23528.A49AAD85; Tue, 28 Mar 2017 20:19:56 +0200 (CEST) Received: from ESESSMB109.ericsson.se ([169.254.9.242]) by ESESSHC009.ericsson.se ([153.88.183.45]) with mapi id 14.03.0339.000; Tue, 28 Mar 2017 20:19:54 +0200 From: Christer Holmberg To: =?iso-8859-1?Q?Ari_Ker=E4nen?= , "Peter Saint-Andre" , Peter Thatcher CC: "ice@ietf.org" Thread-Topic: [Ice] Trickle ICE review Thread-Index: AQHSpd5vLfPb95agJ06E1TropZKa9qGnVe4AgAJB1wCAALtqgIAABEwAgAA6hcA= Date: Tue, 28 Mar 2017 18:19:53 +0000 Message-ID: <7594FB04B1934943A5C02806D1A2204B4CB330A0@ESESSMB109.ericsson.se> References: <7ebb3254-a882-6e05-3159-0ec56614831b@stpeter.im> <7e9e8188-2add-0497-e94f-14ee41afe02d@stpeter.im> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [153.88.183.148] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFmpmkeLIzCtJLcpLzFFi42KZGbFdV9dn5a0Ig+n31C2+Xai1uLb8NavF sT39zA7MHgs2lXosWfKTyWPunhfMAcxRXDYpqTmZZalF+nYJXBm/f79hLbggUrHv/E6WBsat Al2MHBwSAiYSp/9ldzFycQgJrGeUaO5tYIVwljBK9DZcZAUpYhOwkOj+pw0SFxGYwCjx7uYs FpA4s4CixMu9al2MnBzCAqoS82ZeZgOxRQTUJC7O6IGy/SR2ftrFCGKzANWcWrSGFcTmFfCV ePFzJQuILSSwlUlibp87iM0p4CCx/ssSsDijgJjE91NrmEBsZgFxiVtP5oPZEgICEkv2nGeG sEUlXj7+xwphK0k0LnnCClGvJ3Fj6hQ2CFtbYtnC18wQewUlTs58wjKBUXQWkrGzkLTMQtIy C0nLAkaWVYyixanFxbnpRsZ6qUWZycXF+Xl6eaklmxiBUXNwy2/dHYyrXzseYhTgYFTi4V2w 5FaEEGtiWXFl7iFGCQ5mJRHeX3OAQrwpiZVVqUX58UWlOanFhxilOViUxHkd9l2IEBJITyxJ zU5NLUgtgskycXBKNTBmn04KbKsOMP4nlcu2SD7135mH5b1HEwQltqfMiRB+wKr0Kmu7fyJD bMirn0fFxS+u0/dvaX1z6aP8mpKuqOsa7AylsnH7r9y4t5pjqePan5YzTI+sZb6wt83ggrft yd8bmoRn682wmvZEh/PVyjXNLfKNTxhnhRRGyniECdzuCeObH+K8fLYSS3FGoqEWc1FxIgBq 2yp9lgIAAA== Archived-At: Subject: Re: [Ice] Trickle ICE review X-BeenThere: ice@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "Interactive Connectivity Establishment \(ICE\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 28 Mar 2017 18:20:01 -0000 Hi, I agree that adding a definition of "ICE session" to 5245bis is a good idea= . However, I am not sure simply saying "until a re-start would actually work"= . You may never do a re-start - often you simply terminate the session. Also, in RFC 7675 we have the following text: "That means that a new session, or an ICE restart,..." ...which seems to suggest that a new session and an ICE restart are not rel= ated. However, that's probably a minor issue, and we can fix that with an e= rrata if needed. Regards, Christer -----Original Message----- From: Ice [mailto:ice-bounces@ietf.org] On Behalf Of Ari Ker=E4nen Sent: 28 March 2017 19:43 To: Peter Saint-Andre ; Peter Thatcher Cc: ice@ietf.org Subject: Re: [Ice] Trickle ICE review > On 28 Mar 2017, at 11:27, Peter Saint-Andre wrote: >=20 >>> - The name "ICE negotiation session" with definition of "A virtual >>> session ..." is confusing. I understand that we need a word for >>> "period between restarts" and "period across restarts". But what=20 >>> does "virtual" mean in this context? And what does "negotiation"=20 >>> mean in "ICE negotiation session"? Here's a possible suggestion: call = it >>> "single-exchange session". A single-exchange session is the period >>> from a single exchange of ICE description until the next exchange. =20 >>> A "normal" ICE session is basically a multi-exchange session. >>=20 >> This might be clearer: >>=20 >> ICE Session: All of the ICE-related interactions between ICE agen= ts >> up until an ICE restart (if any). >>=20 >> However, that definition probably belongs in 5245bis. The term as use= d >> in the Trickle specification is not limited to interactions between >> Trickle ICE agents. >>=20 >>=20 >> I like that idea of using "ICE session" to mean the thing between=20 >> restarts as long as it's compatible with 5245 and 5245bis and it=20 >> doesn't cause confusion such that people think an "ICE session" is=20 >> the time period across all ICE restarts. >>=20 >> I originally thought it should go in 5245bis also, but Ari thought it=20 >> didn't make sense there since it would never use the term after=20 >> defining it. >=20 > It's already used in 5245bis, isn't it? But we can continue to define=20 > it in Trickle. It's used but not defined actually. We'll add this to the terminology of 52= 45bis. Cheers, Ari _______________________________________________ Ice mailing list Ice@ietf.org https://www.ietf.org/mailman/listinfo/ice From nobody Tue Mar 28 15:06:03 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 E7E26129686 for ; Tue, 28 Mar 2017 15:06:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.523 X-Spam-Level: X-Spam-Status: No, score=-14.523 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=-0.001, 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 wfzF5VZVQ9rE for ; Tue, 28 Mar 2017 15:06:01 -0700 (PDT) Received: from alln-iport-3.cisco.com (alln-iport-3.cisco.com [173.37.142.90]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 36206129684 for ; Tue, 28 Mar 2017 15:06:01 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1598; q=dns/txt; s=iport; t=1490738761; x=1491948361; h=from:to:cc:subject:date:message-id:content-id: content-transfer-encoding:mime-version; bh=kqCqmI5QND191pXefdnsbUgJV9PZ3ty/NwQPoGZh/Eo=; b=fw2z8NFysEDueSMgRhKwMjNH6dn/XN7uuH3vM2dhj+ewB5ZSccUIEI2I rPe21MqJ0tBZpe8FTSaVWHUdhIl0gweHKwPso2C0Cv1fue+FiC7A0uFfe jPnxhWObdodkoraLd59Vq5/1YYsjB+ueybUorU0UxLn1f7ItQQFWVlNil I=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0AqBwDp3dpY/5xdJa1dGQEBAQEBAQEBA?= =?us-ascii?q?QEBBwEBAQEBg1SBbAeDW5tCH5VMgg6GIhyDC0EWAQIBAQEBAQEBax0LhRUBAQI?= =?us-ascii?q?CASMRRQUNAQYCGAICJgIEMBUSBA4FiX8IkBmdW4Imik0BAQEBAQEBAQEBAQEBA?= =?us-ascii?q?QEBAQEBAQEdgQuFQ4IFCIJih1ougjEBBI9hjH8Bkk6RM5NpASYMJYEEWRVSAYR?= =?us-ascii?q?FHoFjdYcXK4EDgQ0BAQE?= X-IronPort-AV: E=Sophos;i="5.36,238,1486425600"; d="scan'208";a="403677338" Received: from rcdn-core-5.cisco.com ([173.37.93.156]) by alln-iport-3.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 28 Mar 2017 22:06:00 +0000 Received: from XCH-RTP-020.cisco.com (xch-rtp-020.cisco.com [64.101.220.160]) by rcdn-core-5.cisco.com (8.14.5/8.14.5) with ESMTP id v2SM60gk013874 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Tue, 28 Mar 2017 22:06:00 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; Tue, 28 Mar 2017 18:05:59 -0400 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, 28 Mar 2017 18:05:58 -0400 From: "Pal Martinsen (palmarti)" To: "ice@ietf.org" CC: Roman Shpount Thread-Topic: [Ice] ICE on the side IETF98 summary Thread-Index: AQHSqA96A8x1lypJBUysUcVPc+DtvA== Date: Tue, 28 Mar 2017 22:05:58 +0000 Message-ID: <281D54EB-314D-4163-93BB-F2EFD34E216A@cisco.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.24.9.157] Content-Type: text/plain; charset="utf-8" Content-ID: <9F1116833B5F1C46A33A4CD2A5D65EEF@emea.cisco.com> Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: Subject: Re: [Ice] ICE on the side IETF98 summary X-BeenThere: ice@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "Interactive Connectivity Establishment \(ICE\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 28 Mar 2017 22:06:03 -0000 DQo+IE9uIDI4IE1hciAyMDE3LCBhdCAxMTozMiwgUm9tYW4gU2hwb3VudCA8cm9tYW5AdGVsdXJp eC5jb20+IHdyb3RlOg0KPiANCj4gT24gVHVlLCBNYXIgMjgsIDIwMTcgYXQgMTA6MjkgQU0sIFBh bCBNYXJ0aW5zZW4gKHBhbG1hcnRpKSA8cGFsbWFydGlAY2lzY28uY29tPiB3cm90ZToNCj4gSUNF IFRMUw0KPiAtIERlbXV4IHBvaW50IHdoZW4gcnVubmluZyA0NDMuIFdoYXQgY2FsbCBpcyB0aGUg aW5jb21taW5nIGNvbm5lY3Rpb24gZm9yPw0KPiANCj4gVGhpcyBjYW4gYmUgbm8gZGlmZmVyZW50 IHRoZW4gSUNFLVRDUC4gVExTIGNvbm5lY3Rpb24gaXMgYWNjZXB0ZWQgYW5kIG9uY2UgU1RVTiBC SU5EIG1lc3NhZ2UgaXMgcmVjZWl2ZWQgdGhpcyBjb25uZWN0aW9uLCBjb25uZWN0aW9uIGlzIGFz c2lnbmVkIHRvIGEgc3BlY2lmaWMgY2FsbCBiYXNlZCBvbiB1ZnJhZyBpbiB0aGUgU1RVTiBtZXNz YWdlLg0KPiANCg0KKzENCj4gSSBoYXZlIGEgcmVsYXRlZCBxdWVzdGlvbiAtLSBkbyB3ZSB3YW50 IHRvIHZhbGlkYXRlIGNlcnRpZmljYXRlcyBmb3IgdGhpcyBUTFMgY29ubmVjdGlvbiwgaS5lLiBk byBzb21ldGhpbmcgc2ltaWxhciB0byBmaW5nZXJwcmludD8gSSB3b3VsZCBhc3N1bWUgbm90Lg0K PiANCg0KVGhlIGN1cnJlbnQgdGV4dCBuIHRoZSBkcmFmdCBzYXlzOg0KIlRoZSBjZXJ0aWZpY2F0 ZXMgZXhjaGFuZ2VkIGFzIHBhcnQgb2YgdGhlIFRMUyBoYW5kc2hha2Ugc2hvdWxkIGJlDQogICB2 YWxpZGF0ZWQgYWdhaW5zdCB0aGUgZ2l2ZW4gZmluZ2VycHJpbnQgYXMgYSBtZWFucyBvZiBpZGVu dGlmeWluZyB0aGUNCiAgIHJlbW90ZSBUTFMgcGFydGljaXBhbnQu4oCdDQoNCnNob3VsZCA9IFNI T1VMRCBpbiB0aGUgc2VjdGlvbi4gSXMgdGhhdCB0byBzdHJvbmc/DQoNCk9uIGEgc2lkZSBub3Rl IHRoZSBBQk5GIGFsbG93cyBTSEEtMQ0KImV4dGVuc2lvbi1hdHQtbmFtZSA9ICJmaW5nZXJwcmlu dCINCiBleHRlbnNpb24tYXR0LXZhbHVlID0gaGFzaC1mdW5jICI7IiBmaW5nZXJwcmludA0KIGhh c2gtZnVuYyA9ICAic2hhLTEiIC8gInNoYS0yMjQiIC8gInNoYS0yNTYiIC8gdG9rZW4NCiBmaW5n ZXJwcmludCA9ICAyVUhFWCAqKOKAnDrigJ0gMlVIRVgpIg0KDQpSZW1vdmUgU0hBLTEgYWx0b2dl dGhlcj8NCg0KLi0uDQpQw6VsLUVyaWsNCg0K From nobody Tue Mar 28 16:04:10 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 AE365128E19 for ; Tue, 28 Mar 2017 16:04:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.389 X-Spam-Level: X-Spam-Status: No, score=-1.389 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_NONE=-0.0001, RCVD_IN_SORBS_SPAM=0.5, T_SPF_PERMERROR=0.01] autolearn=no 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 miawSi68p4aT for ; Tue, 28 Mar 2017 16:04:05 -0700 (PDT) Received: from mail-pg0-x230.google.com (mail-pg0-x230.google.com [IPv6:2607:f8b0:400e:c05::230]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C385712773A for ; Tue, 28 Mar 2017 16:04:05 -0700 (PDT) Received: by mail-pg0-x230.google.com with SMTP id 21so85597078pgg.1 for ; Tue, 28 Mar 2017 16:04:05 -0700 (PDT) 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=MB8baMojLOpHe7IY2rTI+IiEFAk1t5lny4Q0nI6frKk=; b=WUde4R609U83lbX//gsAQsgDqftopwlGzO85hVw30ht94ai9SvNqPexLfSgw206ptX 9KbNPKIhFDFWQX3fSOUcCOc5wAGk3HP2AHI+fQ31OCypWbifS3gqbbosCncODoSLUdnJ 3Yr8ve3OirnaulaYccPS8Yg+aQEhIUIcbA0nC9q2efTA5cvNokBT+M12bKslWBYasUEY h55DpyekorQTf1M6KfGLnBDioozcehxvYgMc2bEPs9bdwJUns/SxmB0Ps28D6A5LVsqB HfLzCzNL8ove+BpUHTtKxKatmG/cQ79Dfc2nLicThURs/fDGq1SfIn8FSWRl5rFKq2n0 wvYQ== 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=MB8baMojLOpHe7IY2rTI+IiEFAk1t5lny4Q0nI6frKk=; b=RpYTUy+ZLpxPApv41wQVrV/NuSB2iuTZZ/muF9fdmTLaDa90Pe2R/vNE7P52jbU3F0 uWMrGQt63nhgVqhYoqDSd/U+q495UaS4qRv6t+m++wvWnzT+h/D5U9D4BoVIkNELoQgR ZpGHoG8U09GN6bWODTF2EGwK6778nmU46TgsRnUaceWsmdCbvi7Vkly0SrWT5yUENIpK BNlV8dKeH8AVCz10OWT0ZMgf0thTLdkVKEit64hGpDp1ZMgiRJ3uORei7N9CLrsKnB1P HgXBezbkC1J9cy+BZVJZ/Y7eAZ+JlgCNkDv+7Ng7DHZZGyDEC9fJuxC+GTKI+CTniRUA PVFw== X-Gm-Message-State: AFeK/H2x2+lPBsv+Orw1zUmekkrFSRgesWTnoVPFfmXHdDfR1qGLjYoO4Us7duVtM40whw== X-Received: by 10.98.85.135 with SMTP id j129mr33191424pfb.79.1490742245208; Tue, 28 Mar 2017 16:04:05 -0700 (PDT) Received: from mail-pg0-f51.google.com (mail-pg0-f51.google.com. [74.125.83.51]) by smtp.gmail.com with ESMTPSA id v143sm9219740pgb.57.2017.03.28.16.04.04 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 28 Mar 2017 16:04:04 -0700 (PDT) Received: by mail-pg0-f51.google.com with SMTP id x125so1080564pgb.0 for ; Tue, 28 Mar 2017 16:04:04 -0700 (PDT) X-Received: by 10.98.212.91 with SMTP id u27mr4546595pfl.117.1490742244268; Tue, 28 Mar 2017 16:04:04 -0700 (PDT) MIME-Version: 1.0 Received: by 10.100.145.151 with HTTP; Tue, 28 Mar 2017 16:04:03 -0700 (PDT) In-Reply-To: <281D54EB-314D-4163-93BB-F2EFD34E216A@cisco.com> References: <281D54EB-314D-4163-93BB-F2EFD34E216A@cisco.com> From: Roman Shpount Date: Tue, 28 Mar 2017 19:04:03 -0400 X-Gmail-Original-Message-ID: Message-ID: To: "Pal Martinsen (palmarti)" Cc: "ice@ietf.org" Content-Type: multipart/alternative; boundary=f403045ec18cebf064054bd27903 Archived-At: Subject: Re: [Ice] ICE on the side IETF98 summary X-BeenThere: ice@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "Interactive Connectivity Establishment \(ICE\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 28 Mar 2017 23:04:08 -0000 --f403045ec18cebf064054bd27903 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On Tue, Mar 28, 2017 at 6:05 PM, Pal Martinsen (palmarti) < palmarti@cisco.com> wrote: > > > On 28 Mar 2017, at 11:32, Roman Shpount wrote: > > > > On Tue, Mar 28, 2017 at 10:29 AM, Pal Martinsen (palmarti) < > palmarti@cisco.com> wrote: > > ICE TLS > > - Demux point when running 443. What call is the incomming connection > for? > > > > This can be no different then ICE-TCP. TLS connection is accepted and > once STUN BIND message is received this connection, connection is assigne= d > to a specific call based on ufrag in the STUN message. > > > > +1 > > I have a related question -- do we want to validate certificates for > this TLS connection, i.e. do something similar to fingerprint? I would > assume not. > > > > The current text n the draft says: > "The certificates exchanged as part of the TLS handshake should be > validated against the given fingerprint as a means of identifying the > remote TLS participant.=E2=80=9D > > should =3D SHOULD in the section. Is that to strong? > > On a side note the ABNF allows SHA-1 > "extension-att-name =3D "fingerprint" > extension-att-value =3D hash-func ";" fingerprint > hash-func =3D "sha-1" / "sha-224" / "sha-256" / token > fingerprint =3D 2UHEX *(=E2=80=9C:=E2=80=9D 2UHEX)" > > Remove SHA-1 altogether? > 1. Please remove SHA-1. It should not be used for anything new. 2. Do end points really MUST include fingerprint in TLS candidates? I would prefer to make fingerprint optional. Fingerprint MUST match the certificate if fingerprint is included. The reason for optional is that typically TLS candidate is only needed for NAT traversal and will carry DTLS-SRTP which will be encrypted and authenticated as well. I do not think we will gain a lot by double checking the certificates. Also, if we are serious about authentication, we will need tls-id (see https://datatracker.ietf.org/doc/draft-thomson-avtcore-sdp-uks/ for more details). 3. Is there ever a use case for more then one fingerprint per candidate? I do not think so, but I might be missing something like situations when it is not known in advance which server gets the TCP connection because of the load balancer. 4. Finally, what is the m=3D line transport when TLS candidate is used? Are we going to use TLS/DTLS/RTP/SAVPF and TLS/DTLS/SCTP? This needs to be defined somewhere. Regards, _____________ Roman Shpount --f403045ec18cebf064054bd27903 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On Tue, Mar 28, 2017 at 6:05 PM, Pal Martin= sen (palmarti) <palmarti@cisco.com> wrote:
<= div class=3D"gmail_quote">

> On 28 Mar 2017, at 11:32, Roman Shpount <roman@telurix.com> wrote:
>
> On Tue, Mar 28, 2017 at 10:29 AM, Pal Martinsen (palmarti) <palmarti@cisco.com>= wrote:
> ICE TLS
> - Demux point when running 443. What call is the incomming connection = for?
>
> This can be no different then ICE-TCP. TLS connection is accepted and = once STUN BIND message is received this connection, connection is assigned = to a specific call based on ufrag in the STUN message.
>

+1
> I have a related que= stion -- do we want to validate certificates for this TLS connection, i.e. = do something similar to fingerprint? I would assume not.
>

The current text n the draft says:
"The certificates exchanged as part of the TLS handshake should be
=C2=A0 =C2=A0validated against the given fingerprint as a means of identify= ing the
=C2=A0 =C2=A0remote TLS participant.=E2=80=9D

should =3D SHOULD in the section. Is that to strong?

On a side note the ABNF allows SHA-1
"extension-att-name =3D "fingerprint"
=C2=A0extension-att-value =3D hash-func ";" fingerprint
=C2=A0hash-func =3D=C2=A0 "sha-1" / "sha-224" / "s= ha-256" / token
=C2=A0fingerprint =3D=C2=A0 2UHEX *(=E2=80=9C:=E2=80=9D 2UHEX)"

Remove SHA-1 altogether?

1. Please remo= ve SHA-1. It should not be used for anything new.

= 2. Do end points really MUST include fingerprint in TLS candidates?

I would prefer to make fingerprint optional. Fingerprint = MUST match the certificate if fingerprint is included. The reason for optio= nal is that typically TLS candidate is only needed for NAT traversal and wi= ll carry DTLS-SRTP which will be encrypted and authenticated as well. I do = not think we will gain a lot by double checking the certificates. Also, if = we are serious about authentication, we will need tls-id (see=C2=A0https://datatrack= er.ietf.org/doc/draft-thomson-avtcore-sdp-uks/=C2=A0for more = details).

3. Is there ever a use case for more the= n one fingerprint per candidate?
I do not think so, but I might b= e missing something like situations when it is not known in advance which s= erver gets the TCP connection because of the load balancer.

<= /div>
4. Finally, what is the m=3D line transport when TLS candidate is= used? Are we going to use TLS/DTLS/RTP/SAVPF and TLS/DTLS/SCTP? This needs= to be defined somewhere.

Regards,
_____________
Roman= Shpount
=C2=A0
--f403045ec18cebf064054bd27903-- From nobody Wed Mar 29 18:10: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 0905A126CE8 for ; Wed, 29 Mar 2017 18:10:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.701 X-Spam-Level: X-Spam-Status: No, score=-2.701 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-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=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 03QrWnnRIxOo for ; Wed, 29 Mar 2017 18:09:57 -0700 (PDT) Received: from mail-qk0-x230.google.com (mail-qk0-x230.google.com [IPv6:2607:f8b0:400d:c09::230]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 72D58126E3A for ; Wed, 29 Mar 2017 18:09:57 -0700 (PDT) Received: by mail-qk0-x230.google.com with SMTP id f11so28011008qkb.0 for ; Wed, 29 Mar 2017 18:09:57 -0700 (PDT) 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=NkCB4pbVAm22XQUAaVwYNnrvKDdqFYzCH3DTfIwmaes=; b=GwqbIY+zHjmCwvXq8cBqe0BN3nSegg466GgOLfL7yTZ3fqVfGFwrhqW0OYvYkzzkkA uammKmd2vLHbUuexNo25aMS8jE+gMscx3bJ4S2q1Nw8WWcjN7xoZckFeoH4Yu/wnj5bD lUPluSK+6RVx0qJKsEytQXFjoS+tfdCOlJGR9M7IJv7puVM9YOzOdDlkKaDesoJT9v8J k/zoLRmyvbgzh6j2z2xno46OTrrcsa+EMtVPBHENWL5fbdo7fZgNEgsOCjxIecGhYYsS BqJQAQyLwlCW4qtGMDa1I5R0/xbIE6G4UyR8qC32i73XUcYob7qgEuqivgbvDIxmjT0O HZ4Q== 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=NkCB4pbVAm22XQUAaVwYNnrvKDdqFYzCH3DTfIwmaes=; b=qQagCesSpIpH800fvgdIXaKcBs97QCKHf5Ed+VJdTIesptk0rTF61KN4y/Exst0lUa 17rDbnMlY8xLjPkHKV0KWOSs0xasInGOMNqHuTXLAGrvRtq4ZEUWgZukbGszIf+6xBQ1 VdCfntbSgy/u2Jo/YF5++ZVdFsb04dp4HQTffj7ibaqJBpIFy0zKnzD4wh6IFhNCay2H zguF/qyxZOMtH8FQrCjLhm73bOdLKoVxPFimRS4//C1QOOhrmVp1dTyRGHY+qSp66QGD Bk2tVDfs0lOAS7l12ZrcP4ny6KOUX5J0EbVxgKwcLbun8hXV6PKuXIz2ohYyGeaPj0qo DXrw== X-Gm-Message-State: AFeK/H3Qemvsh0oRSnnPrpmXR/kdYqxo1u70d4y/va53tsDwiMyHqwQ6qJwTJrntduDpsll5SjSaUAr7C/uweyxK X-Received: by 10.55.77.23 with SMTP id a23mr3753554qkb.208.1490836196515; Wed, 29 Mar 2017 18:09:56 -0700 (PDT) MIME-Version: 1.0 References: <7ebb3254-a882-6e05-3159-0ec56614831b@stpeter.im> <7e9e8188-2add-0497-e94f-14ee41afe02d@stpeter.im> <7594FB04B1934943A5C02806D1A2204B4CB330A0@ESESSMB109.ericsson.se> In-Reply-To: <7594FB04B1934943A5C02806D1A2204B4CB330A0@ESESSMB109.ericsson.se> From: Peter Thatcher Date: Thu, 30 Mar 2017 01:09:46 +0000 Message-ID: To: Christer Holmberg , =?UTF-8?B?QXJpIEtlcsOkbmVu?= , Peter Saint-Andre Cc: "ice@ietf.org" Content-Type: multipart/alternative; boundary=001a114a69cee99629054be85945 Archived-At: Subject: Re: [Ice] Trickle ICE review X-BeenThere: ice@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "Interactive Connectivity Establishment \(ICE\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 30 Mar 2017 01:10:00 -0000 --001a114a69cee99629054be85945 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Actually 7675 in the text seems to imply that "new session =3D=3D ICE resta= rt", which is exactly "until a restart" means. You're in one session until you make a new session by doing an ICE restart. It seems consistent to me. On Tue, Mar 28, 2017 at 11:19 AM Christer Holmberg < christer.holmberg@ericsson.com> wrote: > Hi, > > I agree that adding a definition of "ICE session" to 5245bis is a good > idea. > > However, I am not sure simply saying "until a re-start would actually > work". You may never do a re-start - often you simply terminate the sessi= on. > > Also, in RFC 7675 we have the following text: > > "That means that a new session, or an ICE restart,..." > > ...which seems to suggest that a new session and an ICE restart are not > related. However, that's probably a minor issue, and we can fix that with > an errata if needed. > > Regards, > > Christer > > > > > -----Original Message----- > From: Ice [mailto:ice-bounces@ietf.org] On Behalf Of Ari Ker=C3=A4nen > Sent: 28 March 2017 19:43 > To: Peter Saint-Andre ; Peter Thatcher < > pthatcher@google.com> > Cc: ice@ietf.org > Subject: Re: [Ice] Trickle ICE review > > > > On 28 Mar 2017, at 11:27, Peter Saint-Andre wrote: > > > >>> - The name "ICE negotiation session" with definition of "A virtual > >>> session ..." is confusing. I understand that we need a word for > >>> "period between restarts" and "period across restarts". But what > >>> does "virtual" mean in this context? And what does "negotiation" > >>> mean in "ICE negotiation session"? Here's a possible suggestion: cal= l > it > >>> "single-exchange session". A single-exchange session is the period > >>> from a single exchange of ICE description until the next exchange. > >>> A "normal" ICE session is basically a multi-exchange session. > >> > >> This might be clearer: > >> > >> ICE Session: All of the ICE-related interactions between ICE > agents > >> up until an ICE restart (if any). > >> > >> However, that definition probably belongs in 5245bis. The term as > used > >> in the Trickle specification is not limited to interactions between > >> Trickle ICE agents. > >> > >> > >> I like that idea of using "ICE session" to mean the thing between > >> restarts as long as it's compatible with 5245 and 5245bis and it > >> doesn't cause confusion such that people think an "ICE session" is > >> the time period across all ICE restarts. > >> > >> I originally thought it should go in 5245bis also, but Ari thought it > >> didn't make sense there since it would never use the term after > >> defining it. > > > > It's already used in 5245bis, isn't it? But we can continue to define > > it in Trickle. > > It's used but not defined actually. We'll add this to the terminology of > 5245bis. > > > Cheers, > Ari > _______________________________________________ > Ice mailing list > Ice@ietf.org > https://www.ietf.org/mailman/listinfo/ice > --001a114a69cee99629054be85945 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Actually 7675 in the text seems to imply that "new se= ssion =3D=3D ICE restart", which is exactly "until a restart"= ; means. =C2=A0 You're in one session until you make a new session by d= oing an ICE restart. =C2=A0 It seems consistent to me.

On Tue, Mar 28, 2017 at 11:19 AM Christer= Holmberg <christer.ho= lmberg@ericsson.com> wrote:
= Hi,

I agree that adding a definition of "ICE session" to 5245bis is a= good idea.

However, I am not sure simply saying "until a re-start would actually = work". You may never do a re-start - often you simply terminate the se= ssion.

Also, in RFC 7675 we have the following text:

"That means that a new session, or an ICE restart,..."

...which seems to suggest that a new session and an ICE restart are not rel= ated. However, that's probably a minor issue, and we can fix that with = an errata if needed.

Regards,

Christer




-----Original Message-----
From: Ice [mailto:ice-bounces@ietf.org] On Behalf Of Ari Ker=C3=A4ne= n
Sent: 28 March 2017 19:43
To: Peter Saint-Andre <stpeter@stpeter.im>; Peter Thatcher <<= a href=3D"mailto:pthatcher@google.com" class=3D"gmail_msg" target=3D"_blank= ">pthatcher@google.com>
Cc: i= ce@ietf.org
Subject: Re: [Ice] Trickle ICE review


> On 28 Mar 2017, at 11:27, Peter Saint-Andre <stpeter@stpeter.im> wrote:
>
>>> - The name "ICE negotiation session" with definition= of "A virtual
>>> session ..." is confusing.=C2=A0 =C2=A0I understand that = we need a word for
>>> "period between restarts" and "period across re= starts".=C2=A0 But what
>>> does "virtual" mean in this context?=C2=A0 And what = does "negotiation"
>>> mean in "ICE negotiation session"?=C2=A0 Here's = a possible suggestion: call it
>>> "single-exchange session".=C2=A0 =C2=A0A single-exch= ange session is the period
>>> from a single exchange of ICE description until the next excha= nge.
>>> A "normal" ICE session is basically a multi-exchange= session.
>>
>>=C2=A0 =C2=A0 This might be clearer:
>>
>>=C2=A0 =C2=A0 =C2=A0 =C2=A0ICE Session:=C2=A0 All of the ICE-relate= d interactions between ICE agents
>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 up until an ICE restart (if any)= .
>>
>>=C2=A0 =C2=A0 However, that definition probably belongs in 5245bis.= The term as used
>>=C2=A0 =C2=A0 in the Trickle specification is not limited to intera= ctions between
>>=C2=A0 =C2=A0 Trickle ICE agents.
>>
>>
>> I like that idea of using "ICE session" to mean the thin= g between
>> restarts as long as it's compatible with 5245 and 5245bis and = it
>> doesn't cause confusion such that people think an "ICE se= ssion" is
>> the time period across all ICE restarts.
>>
>> I originally thought it should go in 5245bis also, but Ari thought= it
>> didn't make sense there since it would never use the term afte= r
>> defining it.
>
> It's already used in 5245bis, isn't it? But we can continue to= define
> it in Trickle.

It's used but not defined actually. We'll add this to the terminolo= gy of 5245bis.


Cheers,
Ari
_______________________________________________
Ice mailing list
Ice@i= etf.org
https://www.ietf.org/mailman/listinfo/i= ce
--001a114a69cee99629054be85945-- From nobody Thu Mar 30 06:20:21 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 6C0801294E5 for ; Thu, 30 Mar 2017 06:20:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.22 X-Spam-Level: X-Spam-Status: No, score=-4.22 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, 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 v_z0Tqp6YTEb for ; Thu, 30 Mar 2017 06:20:18 -0700 (PDT) Received: from sesbmg23.ericsson.net (sesbmg23.ericsson.net [193.180.251.37]) (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 9B8021294AF for ; Thu, 30 Mar 2017 06:20:17 -0700 (PDT) X-AuditID: c1b4fb25-0b71498000002d78-7f-58dd060f3d4b Received: from ESESSHC001.ericsson.se (Unknown_Domain [153.88.183.21]) by (Symantec Mail Security) with SMTP id 96.29.11640.F060DD85; Thu, 30 Mar 2017 15:20:15 +0200 (CEST) Received: from ESESSMB109.ericsson.se ([169.254.9.242]) by ESESSHC001.ericsson.se ([153.88.183.21]) with mapi id 14.03.0339.000; Thu, 30 Mar 2017 15:19:20 +0200 From: Christer Holmberg To: Peter Thatcher , =?utf-8?B?QXJpIEtlcsOkbmVu?= , Peter Saint-Andre CC: "ice@ietf.org" Thread-Topic: [Ice] Trickle ICE review Thread-Index: AQHSpd5vLfPb95agJ06E1TropZKa9qGnVe4AgAJB1wCAALtqgIAABEwAgAA6hcCAAeVgAIAA7JYg Date: Thu, 30 Mar 2017 13:19:20 +0000 Message-ID: <7594FB04B1934943A5C02806D1A2204B4CB378CD@ESESSMB109.ericsson.se> References: <7ebb3254-a882-6e05-3159-0ec56614831b@stpeter.im> <7e9e8188-2add-0497-e94f-14ee41afe02d@stpeter.im> <7594FB04B1934943A5C02806D1A2204B4CB330A0@ESESSMB109.ericsson.se> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [153.88.183.150] Content-Type: multipart/alternative; boundary="_000_7594FB04B1934943A5C02806D1A2204B4CB378CDESESSMB109erics_" MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFprNIsWRmVeSWpSXmKPExsUyM2K7qC4/290Ig0vNIhbfLtRaXFv+mtXi 2J5+ZgdmjwWbSj2WLPnJ5DF3zwvmAOYoLpuU1JzMstQifbsEroxvPy4xFZypq/jcdoOtgXFG dRcjJ4eEgInEisWPGLsYuTiEBNYzSlw68IIJJCEksIRRYksLdxcjBwebgIVE9z9tkBoRgR5G iYsNU5hA4swCihIv96qBlAsLqErMm3mZDcQWEVCTuDijB8qOkpgyaTnYSBagmodNC5hBbF4B X4lLJ3YwQew9wCyxePoSsCJOgUCJ7fuegBUxCohJfD+1BizOLCAucevJfCaIowUkluw5zwxh i0q8fPyPFcJWklix/RIjRH2+xP45fxkhlglKnJz5hGUCo8gsJKNmISmbhaRsFthrmhLrd+lD lChKTOl+yA5ha0i0zpnLjiy+gJF9FaNocWpxUm66kbFealFmcnFxfp5eXmrJJkZglB3c8lt1 B+PlN46HGAU4GJV4eB/svR0hxJpYVlyZe4hRgoNZSYT35EqgEG9KYmVValF+fFFpTmrxIUZp DhYlcV7HfRcihATSE0tSs1NTC1KLYLJMHJxSDYycSexBqsdEVO7ITJ/HFuLOM8mj6+EpqUOT vxva2yZOPqHdvrTEWnA/R6Qz07bsWGHu4rINc9YIOXzeFNU2/YRAS9WUedFnFsXv2rfTKOeT +Q1J54kRu174xT6Uuie08Ei0fqqrCM/HjYt+uqgrHAoOeLUgQlkp6mys9b9bGa9un5JdFfT8 yUUlluKMREMt5qLiRABa1L/OrgIAAA== Archived-At: Subject: Re: [Ice] Trickle ICE review X-BeenThere: ice@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "Interactive Connectivity Establishment \(ICE\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 30 Mar 2017 13:20:20 -0000 --_000_7594FB04B1934943A5C02806D1A2204B4CB378CDESESSMB109erics_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SGksDQoNCk15IHBvaW50IGlzIHRoYXQgeW91IGNhbiBlbmQgYSBzZXNzaW9uIHdpdGhvdXQgZG9p bmcgYSByZS1zdGFydC4NCg0KUmVnYXJkcywNCg0KQ2hyaXN0ZXINCg0KRnJvbTogUGV0ZXIgVGhh dGNoZXIgW21haWx0bzpwdGhhdGNoZXJAZ29vZ2xlLmNvbV0NClNlbnQ6IDMwIE1hcmNoIDIwMTcg MDQ6MTANClRvOiBDaHJpc3RlciBIb2xtYmVyZyA8Y2hyaXN0ZXIuaG9sbWJlcmdAZXJpY3Nzb24u Y29tPjsgQXJpIEtlcsOkbmVuIDxhcmkua2VyYW5lbkBlcmljc3Nvbi5jb20+OyBQZXRlciBTYWlu dC1BbmRyZSA8c3RwZXRlckBzdHBldGVyLmltPg0KQ2M6IGljZUBpZXRmLm9yZw0KU3ViamVjdDog UmU6IFtJY2VdIFRyaWNrbGUgSUNFIHJldmlldw0KDQpBY3R1YWxseSA3Njc1IGluIHRoZSB0ZXh0 IHNlZW1zIHRvIGltcGx5IHRoYXQgIm5ldyBzZXNzaW9uID09IElDRSByZXN0YXJ0Iiwgd2hpY2gg aXMgZXhhY3RseSAidW50aWwgYSByZXN0YXJ0IiBtZWFucy4gICBZb3UncmUgaW4gb25lIHNlc3Np b24gdW50aWwgeW91IG1ha2UgYSBuZXcgc2Vzc2lvbiBieSBkb2luZyBhbiBJQ0UgcmVzdGFydC4g ICBJdCBzZWVtcyBjb25zaXN0ZW50IHRvIG1lLg0KDQpPbiBUdWUsIE1hciAyOCwgMjAxNyBhdCAx MToxOSBBTSBDaHJpc3RlciBIb2xtYmVyZyA8Y2hyaXN0ZXIuaG9sbWJlcmdAZXJpY3Nzb24uY29t PG1haWx0bzpjaHJpc3Rlci5ob2xtYmVyZ0Blcmljc3Nvbi5jb20+PiB3cm90ZToNCkhpLA0KDQpJ IGFncmVlIHRoYXQgYWRkaW5nIGEgZGVmaW5pdGlvbiBvZiAiSUNFIHNlc3Npb24iIHRvIDUyNDVi aXMgaXMgYSBnb29kIGlkZWEuDQoNCkhvd2V2ZXIsIEkgYW0gbm90IHN1cmUgc2ltcGx5IHNheWlu ZyAidW50aWwgYSByZS1zdGFydCB3b3VsZCBhY3R1YWxseSB3b3JrIi4gWW91IG1heSBuZXZlciBk byBhIHJlLXN0YXJ0IC0gb2Z0ZW4geW91IHNpbXBseSB0ZXJtaW5hdGUgdGhlIHNlc3Npb24uDQoN CkFsc28sIGluIFJGQyA3Njc1IHdlIGhhdmUgdGhlIGZvbGxvd2luZyB0ZXh0Og0KDQoiVGhhdCBt ZWFucyB0aGF0IGEgbmV3IHNlc3Npb24sIG9yIGFuIElDRSByZXN0YXJ0LC4uLiINCg0KLi4ud2hp Y2ggc2VlbXMgdG8gc3VnZ2VzdCB0aGF0IGEgbmV3IHNlc3Npb24gYW5kIGFuIElDRSByZXN0YXJ0 IGFyZSBub3QgcmVsYXRlZC4gSG93ZXZlciwgdGhhdCdzIHByb2JhYmx5IGEgbWlub3IgaXNzdWUs IGFuZCB3ZSBjYW4gZml4IHRoYXQgd2l0aCBhbiBlcnJhdGEgaWYgbmVlZGVkLg0KDQpSZWdhcmRz LA0KDQpDaHJpc3Rlcg0KDQoNCg0KDQotLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KRnJvbTog SWNlIFttYWlsdG86aWNlLWJvdW5jZXNAaWV0Zi5vcmc8bWFpbHRvOmljZS1ib3VuY2VzQGlldGYu b3JnPl0gT24gQmVoYWxmIE9mIEFyaSBLZXLDpG5lbg0KU2VudDogMjggTWFyY2ggMjAxNyAxOTo0 Mw0KVG86IFBldGVyIFNhaW50LUFuZHJlIDxzdHBldGVyQHN0cGV0ZXIuaW08bWFpbHRvOnN0cGV0 ZXJAc3RwZXRlci5pbT4+OyBQZXRlciBUaGF0Y2hlciA8cHRoYXRjaGVyQGdvb2dsZS5jb208bWFp bHRvOnB0aGF0Y2hlckBnb29nbGUuY29tPj4NCkNjOiBpY2VAaWV0Zi5vcmc8bWFpbHRvOmljZUBp ZXRmLm9yZz4NClN1YmplY3Q6IFJlOiBbSWNlXSBUcmlja2xlIElDRSByZXZpZXcNCg0KDQo+IE9u IDI4IE1hciAyMDE3LCBhdCAxMToyNywgUGV0ZXIgU2FpbnQtQW5kcmUgPHN0cGV0ZXJAc3RwZXRl ci5pbTxtYWlsdG86c3RwZXRlckBzdHBldGVyLmltPj4gd3JvdGU6DQo+DQo+Pj4gLSBUaGUgbmFt ZSAiSUNFIG5lZ290aWF0aW9uIHNlc3Npb24iIHdpdGggZGVmaW5pdGlvbiBvZiAiQSB2aXJ0dWFs DQo+Pj4gc2Vzc2lvbiAuLi4iIGlzIGNvbmZ1c2luZy4gICBJIHVuZGVyc3RhbmQgdGhhdCB3ZSBu ZWVkIGEgd29yZCBmb3INCj4+PiAicGVyaW9kIGJldHdlZW4gcmVzdGFydHMiIGFuZCAicGVyaW9k IGFjcm9zcyByZXN0YXJ0cyIuICBCdXQgd2hhdA0KPj4+IGRvZXMgInZpcnR1YWwiIG1lYW4gaW4g dGhpcyBjb250ZXh0PyAgQW5kIHdoYXQgZG9lcyAibmVnb3RpYXRpb24iDQo+Pj4gbWVhbiBpbiAi SUNFIG5lZ290aWF0aW9uIHNlc3Npb24iPyAgSGVyZSdzIGEgcG9zc2libGUgc3VnZ2VzdGlvbjog Y2FsbCBpdA0KPj4+ICJzaW5nbGUtZXhjaGFuZ2Ugc2Vzc2lvbiIuICAgQSBzaW5nbGUtZXhjaGFu Z2Ugc2Vzc2lvbiBpcyB0aGUgcGVyaW9kDQo+Pj4gZnJvbSBhIHNpbmdsZSBleGNoYW5nZSBvZiBJ Q0UgZGVzY3JpcHRpb24gdW50aWwgdGhlIG5leHQgZXhjaGFuZ2UuDQo+Pj4gQSAibm9ybWFsIiBJ Q0Ugc2Vzc2lvbiBpcyBiYXNpY2FsbHkgYSBtdWx0aS1leGNoYW5nZSBzZXNzaW9uLg0KPj4NCj4+ ICAgIFRoaXMgbWlnaHQgYmUgY2xlYXJlcjoNCj4+DQo+PiAgICAgICBJQ0UgU2Vzc2lvbjogIEFs bCBvZiB0aGUgSUNFLXJlbGF0ZWQgaW50ZXJhY3Rpb25zIGJldHdlZW4gSUNFIGFnZW50cw0KPj4g ICAgICAgICAgdXAgdW50aWwgYW4gSUNFIHJlc3RhcnQgKGlmIGFueSkuDQo+Pg0KPj4gICAgSG93 ZXZlciwgdGhhdCBkZWZpbml0aW9uIHByb2JhYmx5IGJlbG9uZ3MgaW4gNTI0NWJpcy4gVGhlIHRl cm0gYXMgdXNlZA0KPj4gICAgaW4gdGhlIFRyaWNrbGUgc3BlY2lmaWNhdGlvbiBpcyBub3QgbGlt aXRlZCB0byBpbnRlcmFjdGlvbnMgYmV0d2Vlbg0KPj4gICAgVHJpY2tsZSBJQ0UgYWdlbnRzLg0K Pj4NCj4+DQo+PiBJIGxpa2UgdGhhdCBpZGVhIG9mIHVzaW5nICJJQ0Ugc2Vzc2lvbiIgdG8gbWVh biB0aGUgdGhpbmcgYmV0d2Vlbg0KPj4gcmVzdGFydHMgYXMgbG9uZyBhcyBpdCdzIGNvbXBhdGli bGUgd2l0aCA1MjQ1IGFuZCA1MjQ1YmlzIGFuZCBpdA0KPj4gZG9lc24ndCBjYXVzZSBjb25mdXNp b24gc3VjaCB0aGF0IHBlb3BsZSB0aGluayBhbiAiSUNFIHNlc3Npb24iIGlzDQo+PiB0aGUgdGlt ZSBwZXJpb2QgYWNyb3NzIGFsbCBJQ0UgcmVzdGFydHMuDQo+Pg0KPj4gSSBvcmlnaW5hbGx5IHRo b3VnaHQgaXQgc2hvdWxkIGdvIGluIDUyNDViaXMgYWxzbywgYnV0IEFyaSB0aG91Z2h0IGl0DQo+ PiBkaWRuJ3QgbWFrZSBzZW5zZSB0aGVyZSBzaW5jZSBpdCB3b3VsZCBuZXZlciB1c2UgdGhlIHRl cm0gYWZ0ZXINCj4+IGRlZmluaW5nIGl0Lg0KPg0KPiBJdCdzIGFscmVhZHkgdXNlZCBpbiA1MjQ1 YmlzLCBpc24ndCBpdD8gQnV0IHdlIGNhbiBjb250aW51ZSB0byBkZWZpbmUNCj4gaXQgaW4gVHJp Y2tsZS4NCg0KSXQncyB1c2VkIGJ1dCBub3QgZGVmaW5lZCBhY3R1YWxseS4gV2UnbGwgYWRkIHRo aXMgdG8gdGhlIHRlcm1pbm9sb2d5IG9mIDUyNDViaXMuDQoNCg0KQ2hlZXJzLA0KQXJpDQpfX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KSWNlIG1haWxpbmcg bGlzdA0KSWNlQGlldGYub3JnPG1haWx0bzpJY2VAaWV0Zi5vcmc+DQpodHRwczovL3d3dy5pZXRm Lm9yZy9tYWlsbWFuL2xpc3RpbmZvL2ljZQ0K --_000_7594FB04B1934943A5C02806D1A2204B4CB378CDESESSMB109erics_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 IkNhbWJyaWEgTWF0aCI7DQoJcGFub3NlLTE6MiA0IDUgMyA1IDQgNiAzIDIgNDt9DQpAZm9udC1m YWNlDQoJe2ZvbnQtZmFtaWx5OkNhbGlicmk7DQoJcGFub3NlLTE6MiAxNSA1IDIgMiAyIDQgMyAy IDQ7fQ0KLyogU3R5bGUgRGVmaW5pdGlvbnMgKi8NCnAuTXNvTm9ybWFsLCBsaS5Nc29Ob3JtYWws IGRpdi5Nc29Ob3JtYWwNCgl7bWFyZ2luOjBjbTsNCgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJ Zm9udC1zaXplOjEyLjBwdDsNCglmb250LWZhbWlseToiVGltZXMgTmV3IFJvbWFuIixzZXJpZjt9 DQphOmxpbmssIHNwYW4uTXNvSHlwZXJsaW5rDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCglj b2xvcjpibHVlOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0KYTp2aXNpdGVkLCBzcGFu Lk1zb0h5cGVybGlua0ZvbGxvd2VkDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgljb2xvcjpw dXJwbGU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQpzcGFuLkVtYWlsU3R5bGUxNw0K CXttc28tc3R5bGUtdHlwZTpwZXJzb25hbC1yZXBseTsNCglmb250LWZhbWlseToiQ2FsaWJyaSIs c2Fucy1zZXJpZjsNCgljb2xvcjojMUY0OTdEO30NCi5Nc29DaHBEZWZhdWx0DQoJe21zby1zdHls ZS10eXBlOmV4cG9ydC1vbmx5Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIixzYW5zLXNlcmlmOw0K CW1zby1mYXJlYXN0LWxhbmd1YWdlOkVOLVVTO30NCkBwYWdlIFdvcmRTZWN0aW9uMQ0KCXtzaXpl OjYxMi4wcHQgNzkyLjBwdDsNCgltYXJnaW46NzIuMHB0IDcyLjBwdCA3Mi4wcHQgNzIuMHB0O30N CmRpdi5Xb3JkU2VjdGlvbjENCgl7cGFnZTpXb3JkU2VjdGlvbjE7fQ0KLS0+PC9zdHlsZT48IS0t W2lmIGd0ZSBtc28gOV0+PHhtbD4NCjxvOnNoYXBlZGVmYXVsdHMgdjpleHQ9ImVkaXQiIHNwaWRt YXg9IjEwMjYiIC8+DQo8L3htbD48IVtlbmRpZl0tLT48IS0tW2lmIGd0ZSBtc28gOV0+PHhtbD4N CjxvOnNoYXBlbGF5b3V0IHY6ZXh0PSJlZGl0Ij4NCjxvOmlkbWFwIHY6ZXh0PSJlZGl0IiBkYXRh PSIxIiAvPg0KPC9vOnNoYXBlbGF5b3V0PjwveG1sPjwhW2VuZGlmXS0tPg0KPC9oZWFkPg0KPGJv ZHkgbGFuZz0iRU4tR0IiIGxpbms9ImJsdWUiIHZsaW5rPSJwdXJwbGUiPg0KPGRpdiBjbGFzcz0i V29yZFNlY3Rpb24xIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNp emU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xv cjojMUY0OTdEO21zby1mYXJlYXN0LWxhbmd1YWdlOkVOLVVTIj5IaSw8bzpwPjwvbzpwPjwvc3Bh bj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBw dDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3 RDttc28tZmFyZWFzdC1sYW5ndWFnZTpFTi1VUyI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9w Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9u dC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0Q7bXNv LWZhcmVhc3QtbGFuZ3VhZ2U6RU4tVVMiPk15IHBvaW50IGlzIHRoYXQgeW91IGNhbiBlbmQgYSBz ZXNzaW9uIHdpdGhvdXQgZG9pbmcgYSByZS1zdGFydC48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZh bWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RDttc28tZmFy ZWFzdC1sYW5ndWFnZTpFTi1VUyI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6 JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0Q7bXNvLWZhcmVhc3Qt bGFuZ3VhZ2U6RU4tVVMiPlJlZ2FyZHMsPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1 b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0Q7bXNvLWZhcmVhc3QtbGFu Z3VhZ2U6RU4tVVMiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0Nh bGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEO21zby1mYXJlYXN0LWxhbmd1YWdl OkVOLVVTIj5DaHJpc3RlcjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPjxhIG5hbWU9Il9NYWlsRW5kQ29tcG9zZSI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4w cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5 N0Q7bXNvLWZhcmVhc3QtbGFuZ3VhZ2U6RU4tVVMiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwv YT48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48Yj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9 ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNl cmlmIj5Gcm9tOjwvc3Bhbj48L2I+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6 MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZiI+IFBldGVy IFRoYXRjaGVyIFttYWlsdG86cHRoYXRjaGVyQGdvb2dsZS5jb21dDQo8YnI+DQo8Yj5TZW50Ojwv Yj4gMzAgTWFyY2ggMjAxNyAwNDoxMDxicj4NCjxiPlRvOjwvYj4gQ2hyaXN0ZXIgSG9sbWJlcmcg Jmx0O2NocmlzdGVyLmhvbG1iZXJnQGVyaWNzc29uLmNvbSZndDs7IEFyaSBLZXLDpG5lbiAmbHQ7 YXJpLmtlcmFuZW5AZXJpY3Nzb24uY29tJmd0OzsgUGV0ZXIgU2FpbnQtQW5kcmUgJmx0O3N0cGV0 ZXJAc3RwZXRlci5pbSZndDs8YnI+DQo8Yj5DYzo8L2I+IGljZUBpZXRmLm9yZzxicj4NCjxiPlN1 YmplY3Q6PC9iPiBSZTogW0ljZV0gVHJpY2tsZSBJQ0UgcmV2aWV3PG86cD48L286cD48L3NwYW4+ PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8ZGl2Pg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+QWN0dWFsbHkgNzY3NSBpbiB0aGUgdGV4dCBzZWVtcyB0byBp bXBseSB0aGF0ICZxdW90O25ldyBzZXNzaW9uID09IElDRSByZXN0YXJ0JnF1b3Q7LCB3aGljaCBp cyBleGFjdGx5ICZxdW90O3VudGlsIGEgcmVzdGFydCZxdW90OyBtZWFucy4gJm5ic3A7IFlvdSdy ZSBpbiBvbmUgc2Vzc2lvbiB1bnRpbCB5b3UgbWFrZSBhIG5ldyBzZXNzaW9uIGJ5IGRvaW5nIGFu IElDRSByZXN0YXJ0LiAmbmJzcDsgSXQgc2VlbXMgY29uc2lzdGVudCB0byBtZS48bzpwPjwvbzpw PjwvcD4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+ DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPk9uIFR1ZSwgTWFyIDI4LCAyMDE3 IGF0IDExOjE5IEFNIENocmlzdGVyIEhvbG1iZXJnICZsdDs8YSBocmVmPSJtYWlsdG86Y2hyaXN0 ZXIuaG9sbWJlcmdAZXJpY3Nzb24uY29tIj5jaHJpc3Rlci5ob2xtYmVyZ0Blcmljc3Nvbi5jb208 L2E+Jmd0OyB3cm90ZTo8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGJsb2NrcXVvdGUgc3R5bGU9 ImJvcmRlcjpub25lO2JvcmRlci1sZWZ0OnNvbGlkICNDQ0NDQ0MgMS4wcHQ7cGFkZGluZzowY20g MGNtIDBjbSA2LjBwdDttYXJnaW4tbGVmdDo0LjhwdDttYXJnaW4tcmlnaHQ6MGNtIj4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPkhpLDxicj4NCjxicj4NCkkgYWdyZWUgdGhhdCBhZGRpbmcgYSBkZWZp bml0aW9uIG9mICZxdW90O0lDRSBzZXNzaW9uJnF1b3Q7IHRvIDUyNDViaXMgaXMgYSBnb29kIGlk ZWEuPGJyPg0KPGJyPg0KSG93ZXZlciwgSSBhbSBub3Qgc3VyZSBzaW1wbHkgc2F5aW5nICZxdW90 O3VudGlsIGEgcmUtc3RhcnQgd291bGQgYWN0dWFsbHkgd29yayZxdW90Oy4gWW91IG1heSBuZXZl ciBkbyBhIHJlLXN0YXJ0IC0gb2Z0ZW4geW91IHNpbXBseSB0ZXJtaW5hdGUgdGhlIHNlc3Npb24u PGJyPg0KPGJyPg0KQWxzbywgaW4gUkZDIDc2NzUgd2UgaGF2ZSB0aGUgZm9sbG93aW5nIHRleHQ6 PGJyPg0KPGJyPg0KJnF1b3Q7VGhhdCBtZWFucyB0aGF0IGEgbmV3IHNlc3Npb24sIG9yIGFuIElD RSByZXN0YXJ0LC4uLiZxdW90Ozxicj4NCjxicj4NCi4uLndoaWNoIHNlZW1zIHRvIHN1Z2dlc3Qg dGhhdCBhIG5ldyBzZXNzaW9uIGFuZCBhbiBJQ0UgcmVzdGFydCBhcmUgbm90IHJlbGF0ZWQuIEhv d2V2ZXIsIHRoYXQncyBwcm9iYWJseSBhIG1pbm9yIGlzc3VlLCBhbmQgd2UgY2FuIGZpeCB0aGF0 IHdpdGggYW4gZXJyYXRhIGlmIG5lZWRlZC48YnI+DQo8YnI+DQpSZWdhcmRzLDxicj4NCjxicj4N CkNocmlzdGVyPGJyPg0KPGJyPg0KPGJyPg0KPGJyPg0KPGJyPg0KLS0tLS1PcmlnaW5hbCBNZXNz YWdlLS0tLS08YnI+DQpGcm9tOiBJY2UgW21haWx0bzo8YSBocmVmPSJtYWlsdG86aWNlLWJvdW5j ZXNAaWV0Zi5vcmciIHRhcmdldD0iX2JsYW5rIj5pY2UtYm91bmNlc0BpZXRmLm9yZzwvYT5dIE9u IEJlaGFsZiBPZiBBcmkgS2Vyw6RuZW48YnI+DQpTZW50OiAyOCBNYXJjaCAyMDE3IDE5OjQzPGJy Pg0KVG86IFBldGVyIFNhaW50LUFuZHJlICZsdDs8YSBocmVmPSJtYWlsdG86c3RwZXRlckBzdHBl dGVyLmltIiB0YXJnZXQ9Il9ibGFuayI+c3RwZXRlckBzdHBldGVyLmltPC9hPiZndDs7IFBldGVy IFRoYXRjaGVyICZsdDs8YSBocmVmPSJtYWlsdG86cHRoYXRjaGVyQGdvb2dsZS5jb20iIHRhcmdl dD0iX2JsYW5rIj5wdGhhdGNoZXJAZ29vZ2xlLmNvbTwvYT4mZ3Q7PGJyPg0KQ2M6IDxhIGhyZWY9 Im1haWx0bzppY2VAaWV0Zi5vcmciIHRhcmdldD0iX2JsYW5rIj5pY2VAaWV0Zi5vcmc8L2E+PGJy Pg0KU3ViamVjdDogUmU6IFtJY2VdIFRyaWNrbGUgSUNFIHJldmlldzxicj4NCjxicj4NCjxicj4N CiZndDsgT24gMjggTWFyIDIwMTcsIGF0IDExOjI3LCBQZXRlciBTYWludC1BbmRyZSAmbHQ7PGEg aHJlZj0ibWFpbHRvOnN0cGV0ZXJAc3RwZXRlci5pbSIgdGFyZ2V0PSJfYmxhbmsiPnN0cGV0ZXJA c3RwZXRlci5pbTwvYT4mZ3Q7IHdyb3RlOjxicj4NCiZndDs8YnI+DQomZ3Q7Jmd0OyZndDsgLSBU aGUgbmFtZSAmcXVvdDtJQ0UgbmVnb3RpYXRpb24gc2Vzc2lvbiZxdW90OyB3aXRoIGRlZmluaXRp b24gb2YgJnF1b3Q7QSB2aXJ0dWFsPGJyPg0KJmd0OyZndDsmZ3Q7IHNlc3Npb24gLi4uJnF1b3Q7 IGlzIGNvbmZ1c2luZy4mbmJzcDsgJm5ic3A7SSB1bmRlcnN0YW5kIHRoYXQgd2UgbmVlZCBhIHdv cmQgZm9yPGJyPg0KJmd0OyZndDsmZ3Q7ICZxdW90O3BlcmlvZCBiZXR3ZWVuIHJlc3RhcnRzJnF1 b3Q7IGFuZCAmcXVvdDtwZXJpb2QgYWNyb3NzIHJlc3RhcnRzJnF1b3Q7LiZuYnNwOyBCdXQgd2hh dDxicj4NCiZndDsmZ3Q7Jmd0OyBkb2VzICZxdW90O3ZpcnR1YWwmcXVvdDsgbWVhbiBpbiB0aGlz IGNvbnRleHQ/Jm5ic3A7IEFuZCB3aGF0IGRvZXMgJnF1b3Q7bmVnb3RpYXRpb24mcXVvdDs8YnI+ DQomZ3Q7Jmd0OyZndDsgbWVhbiBpbiAmcXVvdDtJQ0UgbmVnb3RpYXRpb24gc2Vzc2lvbiZxdW90 Oz8mbmJzcDsgSGVyZSdzIGEgcG9zc2libGUgc3VnZ2VzdGlvbjogY2FsbCBpdDxicj4NCiZndDsm Z3Q7Jmd0OyAmcXVvdDtzaW5nbGUtZXhjaGFuZ2Ugc2Vzc2lvbiZxdW90Oy4mbmJzcDsgJm5ic3A7 QSBzaW5nbGUtZXhjaGFuZ2Ugc2Vzc2lvbiBpcyB0aGUgcGVyaW9kPGJyPg0KJmd0OyZndDsmZ3Q7 IGZyb20gYSBzaW5nbGUgZXhjaGFuZ2Ugb2YgSUNFIGRlc2NyaXB0aW9uIHVudGlsIHRoZSBuZXh0 IGV4Y2hhbmdlLjxicj4NCiZndDsmZ3Q7Jmd0OyBBICZxdW90O25vcm1hbCZxdW90OyBJQ0Ugc2Vz c2lvbiBpcyBiYXNpY2FsbHkgYSBtdWx0aS1leGNoYW5nZSBzZXNzaW9uLjxicj4NCiZndDsmZ3Q7 PGJyPg0KJmd0OyZndDsmbmJzcDsgJm5ic3A7IFRoaXMgbWlnaHQgYmUgY2xlYXJlcjo8YnI+DQom Z3Q7Jmd0Ozxicj4NCiZndDsmZ3Q7Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7SUNFIFNlc3Np b246Jm5ic3A7IEFsbCBvZiB0aGUgSUNFLXJlbGF0ZWQgaW50ZXJhY3Rpb25zIGJldHdlZW4gSUNF IGFnZW50czxicj4NCiZndDsmZ3Q7Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyB1 cCB1bnRpbCBhbiBJQ0UgcmVzdGFydCAoaWYgYW55KS48YnI+DQomZ3Q7Jmd0Ozxicj4NCiZndDsm Z3Q7Jm5ic3A7ICZuYnNwOyBIb3dldmVyLCB0aGF0IGRlZmluaXRpb24gcHJvYmFibHkgYmVsb25n cyBpbiA1MjQ1YmlzLiBUaGUgdGVybSBhcyB1c2VkPGJyPg0KJmd0OyZndDsmbmJzcDsgJm5ic3A7 IGluIHRoZSBUcmlja2xlIHNwZWNpZmljYXRpb24gaXMgbm90IGxpbWl0ZWQgdG8gaW50ZXJhY3Rp b25zIGJldHdlZW48YnI+DQomZ3Q7Jmd0OyZuYnNwOyAmbmJzcDsgVHJpY2tsZSBJQ0UgYWdlbnRz Ljxicj4NCiZndDsmZ3Q7PGJyPg0KJmd0OyZndDs8YnI+DQomZ3Q7Jmd0OyBJIGxpa2UgdGhhdCBp ZGVhIG9mIHVzaW5nICZxdW90O0lDRSBzZXNzaW9uJnF1b3Q7IHRvIG1lYW4gdGhlIHRoaW5nIGJl dHdlZW48YnI+DQomZ3Q7Jmd0OyByZXN0YXJ0cyBhcyBsb25nIGFzIGl0J3MgY29tcGF0aWJsZSB3 aXRoIDUyNDUgYW5kIDUyNDViaXMgYW5kIGl0PGJyPg0KJmd0OyZndDsgZG9lc24ndCBjYXVzZSBj b25mdXNpb24gc3VjaCB0aGF0IHBlb3BsZSB0aGluayBhbiAmcXVvdDtJQ0Ugc2Vzc2lvbiZxdW90 OyBpczxicj4NCiZndDsmZ3Q7IHRoZSB0aW1lIHBlcmlvZCBhY3Jvc3MgYWxsIElDRSByZXN0YXJ0 cy48YnI+DQomZ3Q7Jmd0Ozxicj4NCiZndDsmZ3Q7IEkgb3JpZ2luYWxseSB0aG91Z2h0IGl0IHNo b3VsZCBnbyBpbiA1MjQ1YmlzIGFsc28sIGJ1dCBBcmkgdGhvdWdodCBpdDxicj4NCiZndDsmZ3Q7 IGRpZG4ndCBtYWtlIHNlbnNlIHRoZXJlIHNpbmNlIGl0IHdvdWxkIG5ldmVyIHVzZSB0aGUgdGVy bSBhZnRlcjxicj4NCiZndDsmZ3Q7IGRlZmluaW5nIGl0Ljxicj4NCiZndDs8YnI+DQomZ3Q7IEl0 J3MgYWxyZWFkeSB1c2VkIGluIDUyNDViaXMsIGlzbid0IGl0PyBCdXQgd2UgY2FuIGNvbnRpbnVl IHRvIGRlZmluZTxicj4NCiZndDsgaXQgaW4gVHJpY2tsZS48YnI+DQo8YnI+DQpJdCdzIHVzZWQg YnV0IG5vdCBkZWZpbmVkIGFjdHVhbGx5LiBXZSdsbCBhZGQgdGhpcyB0byB0aGUgdGVybWlub2xv Z3kgb2YgNTI0NWJpcy48YnI+DQo8YnI+DQo8YnI+DQpDaGVlcnMsPGJyPg0KQXJpPGJyPg0KX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX188YnI+DQpJY2UgbWFp bGluZyBsaXN0PGJyPg0KPGEgaHJlZj0ibWFpbHRvOkljZUBpZXRmLm9yZyIgdGFyZ2V0PSJfYmxh bmsiPkljZUBpZXRmLm9yZzwvYT48YnI+DQo8YSBocmVmPSJodHRwczovL3d3dy5pZXRmLm9yZy9t YWlsbWFuL2xpc3RpbmZvL2ljZSIgdGFyZ2V0PSJfYmxhbmsiPmh0dHBzOi8vd3d3LmlldGYub3Jn L21haWxtYW4vbGlzdGluZm8vaWNlPC9hPjxvOnA+PC9vOnA+PC9wPg0KPC9ibG9ja3F1b3RlPg0K PC9kaXY+DQo8L2Rpdj4NCjwvYm9keT4NCjwvaHRtbD4NCg== --_000_7594FB04B1934943A5C02806D1A2204B4CB378CDESESSMB109erics_-- From nobody Thu Mar 30 08:46: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 017AA12956D for ; Thu, 30 Mar 2017 08:46:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.001 X-Spam-Level: X-Spam-Status: No, score=-2.001 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-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=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 aUaMEh3Cxndc for ; Thu, 30 Mar 2017 08:46:07 -0700 (PDT) Received: from mail-qt0-x22b.google.com (mail-qt0-x22b.google.com [IPv6:2607:f8b0:400d:c0d::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 6AA6D129533 for ; Thu, 30 Mar 2017 08:46:07 -0700 (PDT) Received: by mail-qt0-x22b.google.com with SMTP id n21so42800806qta.1 for ; Thu, 30 Mar 2017 08:46:07 -0700 (PDT) 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=VvRCyjotCcJk4P2SvEjmn7xLlr31+/OokTdpltp0tc8=; b=KIDe26/yZE/dgeuqdNlf2uQ2spvX3NpezPg8Ky3cJiKBgIye0hMC3tKGimhZGr35d+ ZhDkB29MnDSAGsE6wuPJmDdn8IMUBaIjeIvxMm/iYxYVgCp114crhhddfYP+IJGlVAFQ BSxSIH178jq5bQ6vM0VOibjta6ENUWdOERLXlDarWPL8wJBJ28jJyhSC4yYlIONY/tW8 UJCKPJ/1lLF876DGYmUKVNZpPXizhIVL6WgdbIoEs4xgdWIENuY05d5+fWZjZ/qDeiq+ smFAyezUNfS+7+EfxX0xLTROxBEvIRVEICNJd+ESwh9FV5lssgK06cCdABxrD6a7rhP8 mvAQ== 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=VvRCyjotCcJk4P2SvEjmn7xLlr31+/OokTdpltp0tc8=; b=RPDv7vD0a0E6T8gNn7p3tAs+jCy5rgZl/EAEDD8xgWEKm7uTz6A8ubXhazFi7TsKrp ta47NGGhJFZU23y3BKrJEqz8LZwZvjfPg8vPE0vPLlikmpMkZ7PzrAnKJtnj+JnMVsLS jfzlxRWyTgmUum3jll0a7bKff7C2S5MZNJmetSYMOCPGuU5oPEfBlxOcKoBoINRWCDl8 tbjws/BhBDma7b0pbz3/aqgg5RDY/nFcn2vudVBfVN3+7wB/iECLHwxqfg0lMPJTrSR4 0lhbv9lEUpsmi7Z7Qfue20t9eL0PjUUUCKodsXfXIHKwEqaKS6FVa5wGqhwQ757qz5sR z61Q== X-Gm-Message-State: AFeK/H1q7t6aDNg9Gt0BLeCuzN8CY3aPr1qqUt3v+E/nysyscRwq7mTEy5DhNMPiVhlG9NtHgR3Od/tD1pkRBRg9 X-Received: by 10.237.55.99 with SMTP id i90mr390479qtb.262.1490888766380; Thu, 30 Mar 2017 08:46:06 -0700 (PDT) MIME-Version: 1.0 References: <7ebb3254-a882-6e05-3159-0ec56614831b@stpeter.im> <7e9e8188-2add-0497-e94f-14ee41afe02d@stpeter.im> <7594FB04B1934943A5C02806D1A2204B4CB330A0@ESESSMB109.ericsson.se> <7594FB04B1934943A5C02806D1A2204B4CB378CD@ESESSMB109.ericsson.se> In-Reply-To: <7594FB04B1934943A5C02806D1A2204B4CB378CD@ESESSMB109.ericsson.se> From: Peter Thatcher Date: Thu, 30 Mar 2017 15:45:54 +0000 Message-ID: To: Christer Holmberg , =?UTF-8?B?QXJpIEtlcsOkbmVu?= , Peter Saint-Andre Cc: "ice@ietf.org" Content-Type: multipart/alternative; boundary=001a1140584e523b6c054bf497db Archived-At: Subject: Re: [Ice] Trickle ICE review X-BeenThere: ice@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "Interactive Connectivity Establishment \(ICE\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 30 Mar 2017 15:46:10 -0000 --001a1140584e523b6c054bf497db Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Ah, I see what you mean now. In that case, could we just define "ICE session" as the something like "stuff until the next ICE restart or the termination of all ICE activity by this agent"? On Thu, Mar 30, 2017 at 6:20 AM Christer Holmberg < christer.holmberg@ericsson.com> wrote: > Hi, > > > > My point is that you can end a session without doing a re-start. > > > > Regards, > > > > Christer > > > > *From:* Peter Thatcher [mailto:pthatcher@google.com] > *Sent:* 30 March 2017 04:10 > *To:* Christer Holmberg ; Ari Ker=C3=A4ne= n < > ari.keranen@ericsson.com>; Peter Saint-Andre > > > *Cc:* ice@ietf.org > *Subject:* Re: [Ice] Trickle ICE review > > > > Actually 7675 in the text seems to imply that "new session =3D=3D ICE > restart", which is exactly "until a restart" means. You're in one sessi= on > until you make a new session by doing an ICE restart. It seems consiste= nt > to me. > > > > On Tue, Mar 28, 2017 at 11:19 AM Christer Holmberg < > christer.holmberg@ericsson.com> wrote: > > Hi, > > I agree that adding a definition of "ICE session" to 5245bis is a good > idea. > > However, I am not sure simply saying "until a re-start would actually > work". You may never do a re-start - often you simply terminate the sessi= on. > > Also, in RFC 7675 we have the following text: > > "That means that a new session, or an ICE restart,..." > > ...which seems to suggest that a new session and an ICE restart are not > related. However, that's probably a minor issue, and we can fix that with > an errata if needed. > > Regards, > > Christer > > > > > -----Original Message----- > From: Ice [mailto:ice-bounces@ietf.org] On Behalf Of Ari Ker=C3=A4nen > Sent: 28 March 2017 19:43 > To: Peter Saint-Andre ; Peter Thatcher < > pthatcher@google.com> > Cc: ice@ietf.org > Subject: Re: [Ice] Trickle ICE review > > > > On 28 Mar 2017, at 11:27, Peter Saint-Andre wrote: > > > >>> - The name "ICE negotiation session" with definition of "A virtual > >>> session ..." is confusing. I understand that we need a word for > >>> "period between restarts" and "period across restarts". But what > >>> does "virtual" mean in this context? And what does "negotiation" > >>> mean in "ICE negotiation session"? Here's a possible suggestion: cal= l > it > >>> "single-exchange session". A single-exchange session is the period > >>> from a single exchange of ICE description until the next exchange. > >>> A "normal" ICE session is basically a multi-exchange session. > >> > >> This might be clearer: > >> > >> ICE Session: All of the ICE-related interactions between ICE > agents > >> up until an ICE restart (if any). > >> > >> However, that definition probably belongs in 5245bis. The term as > used > >> in the Trickle specification is not limited to interactions between > >> Trickle ICE agents. > >> > >> > >> I like that idea of using "ICE session" to mean the thing between > >> restarts as long as it's compatible with 5245 and 5245bis and it > >> doesn't cause confusion such that people think an "ICE session" is > >> the time period across all ICE restarts. > >> > >> I originally thought it should go in 5245bis also, but Ari thought it > >> didn't make sense there since it would never use the term after > >> defining it. > > > > It's already used in 5245bis, isn't it? But we can continue to define > > it in Trickle. > > It's used but not defined actually. We'll add this to the terminology of > 5245bis. > > > Cheers, > Ari > _______________________________________________ > Ice mailing list > Ice@ietf.org > https://www.ietf.org/mailman/listinfo/ice > > --001a1140584e523b6c054bf497db Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Ah, I see what you mean now. =C2=A0

In that c= ase, could we just define "ICE session" as the something like &qu= ot;stuff until the next ICE restart or the termination of all ICE activity = by this agent"? =C2=A0

On Thu, Mar 30, 2017 at 6:20 AM Christer Holmberg <christer.holmberg@ericsson.c= om> wrote:

Hi,

=C2=A0

My poin= t is that you can end a session without doing a re-start.

=C2=A0

Regards= ,

=C2=A0

Christe= r

=C2=A0

From: Peter= Thatcher [mailto:pthatcher@google.com]
Sent: 30 March 2017 04:10
To: Christer Holmberg <christer.= holmberg@ericsson.com>; Ari Ker=C3=A4nen <ari.keranen@eric= sson.com>; Peter Saint-Andre <stpeter@stpeter.im><= /p>


Cc: ice@ietf.org
Subject: Re: [Ice] Trickle ICE review

=C2=A0

Actually 7675 in the text seems to imply t= hat "new session =3D=3D ICE restart", which is exactly "unti= l a restart" means. =C2=A0 You're in one session until you make a = new session by doing an ICE restart. =C2=A0 It seems consistent to me.

=C2=A0

On Tue, Mar 28, 2017 at 11:19 AM Christer = Holmberg <christer.holmberg@ericsson.com> wrote:

Hi,

I agree that adding a definition of "ICE session" to 5245bis is a= good idea.

However, I am not sure simply saying "until a re-start would actually = work". You may never do a re-start - often you simply terminate the se= ssion.

Also, in RFC 7675 we have the following text:

"That means that a new session, or an ICE restart,..."

...which seems to suggest that a new session and an ICE restart are not rel= ated. However, that's probably a minor issue, and we can fix that with = an errata if needed.

Regards,

Christer




-----Original Message-----
From: Ice [mailto:ice-bounces@ietf.org] On Behalf Of Ari Ker=C3=A4ne= n
Sent: 28 March 2017 19:43
To: Peter Saint-Andre <stpeter@stpeter.im>; Peter Thatcher <<= a href=3D"mailto:pthatcher@google.com" class=3D"gmail_msg" target=3D"_blank= ">pthatcher@google.com>
Cc: i= ce@ietf.org
Subject: Re: [Ice] Trickle ICE review


> On 28 Mar 2017, at 11:27, Peter Saint-Andre <stpeter@stpeter.im> wrote:
>
>>> - The name "ICE negotiation session" with definition= of "A virtual
>>> session ..." is confusing.=C2=A0 =C2=A0I understand that = we need a word for
>>> "period between restarts" and "period across re= starts".=C2=A0 But what
>>> does "virtual" mean in this context?=C2=A0 And what = does "negotiation"
>>> mean in "ICE negotiation session"?=C2=A0 Here's = a possible suggestion: call it
>>> "single-exchange session".=C2=A0 =C2=A0A single-exch= ange session is the period
>>> from a single exchange of ICE description until the next excha= nge.
>>> A "normal" ICE session is basically a multi-exchange= session.
>>
>>=C2=A0 =C2=A0 This might be clearer:
>>
>>=C2=A0 =C2=A0 =C2=A0 =C2=A0ICE Session:=C2=A0 All of the ICE-relate= d interactions between ICE agents
>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 up until an ICE restart (if any)= .
>>
>>=C2=A0 =C2=A0 However, that definition probably belongs in 5245bis.= The term as used
>>=C2=A0 =C2=A0 in the Trickle specification is not limited to intera= ctions between
>>=C2=A0 =C2=A0 Trickle ICE agents.
>>
>>
>> I like that idea of using "ICE session" to mean the thin= g between
>> restarts as long as it's compatible with 5245 and 5245bis and = it
>> doesn't cause confusion such that people think an "ICE se= ssion" is
>> the time period across all ICE restarts.
>>
>> I originally thought it should go in 5245bis also, but Ari thought= it
>> didn't make sense there since it would never use the term afte= r
>> defining it.
>
> It's already used in 5245bis, isn't it? But we can continue to= define
> it in Trickle.

It's used but not defined actually. We'll add this to the terminolo= gy of 5245bis.


Cheers,
Ari
_______________________________________________
Ice mailing list
Ice@i= etf.org
https://www.ietf.org/mailman/listinfo/ice

--001a1140584e523b6c054bf497db-- From nobody Thu Mar 30 10:41:48 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 82DD1129639 for ; Thu, 30 Mar 2017 10:41:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.721 X-Spam-Level: X-Spam-Status: No, score=-2.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_LOW=-0.7, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=stpeter.im header.b=jb4oaVfS; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=lgEeQ/pM Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zeVutKtoXDck for ; Thu, 30 Mar 2017 10:41:37 -0700 (PDT) Received: from out1-smtp.messagingengine.com (out1-smtp.messagingengine.com [66.111.4.25]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E85D11293DA for ; Thu, 30 Mar 2017 10:41:36 -0700 (PDT) Received: from compute2.internal (compute2.nyi.internal [10.202.2.42]) by mailout.nyi.internal (Postfix) with ESMTP id 0BD1020A04; Thu, 30 Mar 2017 13:41:36 -0400 (EDT) Received: from frontend1 ([10.202.2.160]) by compute2.internal (MEProxy); Thu, 30 Mar 2017 13:41:36 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=stpeter.im; h=cc :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=fm1; bh=Hv02ko/Yv5epvC3KTd +7Oh9+ULpxFFpQjUWP/t1V/DA=; b=jb4oaVfSjL5FmSFKru1w1ArZIeDYeCBddR 1FAd45vCabsyuZOeQsTw/R31dBF4vSpXDHwA3mcAKU9SWvYRZWiqRzuf02szcIgN hEsSMh2MXBkdaHkxycPJAETeEZAeAFhgXXsR+frnxBZ/E2IPC+xRbImgSjl8U7P1 XU1jw2053T9SJ08r0q7Qh/kBrHnP1oypNuMAz6Aya4wDzbLpOFKHZq82Hd/1sEPz FI6JL5KMwjpHOB6LlmkeQ/uXxorQFVm52lFdYFvfKg431TQGqfv8oUU1sA2sR5j+ 5TQbae0RzlkyB++G+cAb3HBFd3u4Db4FOCb23dAVkRV0FLkbQUqw== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:content-transfer-encoding:content-type :date:from:in-reply-to:message-id:mime-version:references :subject:to:x-me-sender:x-me-sender:x-sasl-enc:x-sasl-enc; s= fm1; bh=Hv02ko/Yv5epvC3KTd+7Oh9+ULpxFFpQjUWP/t1V/DA=; b=lgEeQ/pM P45wd2Cd8MZnwqYYY7UisyJjSUqKacb3c2NI2Qq2mxGXS/ATbeZEXxWOOCIEBz+L IXb2e8x0q47sSZ/yzw/hlbyJw7dp9t6uAHAL7jiPVTd6GTqOUEuUro5NCI8yq0JI tjWg9bP5z+9hCf9CabVQkyjY5bhe9Pj6wSsu75D8uMR2fPrIQqyOcf9DrsAjisay ribvzJbnF+DXBHv9rE6n7QeObBy+A76+6/P0Dcl4fda7ma6B+O/AO0mdtaAg6gza UfH8J5LWjsgxs7KoV52A6lBHdOuzfB24GHmaaA4Z30R5/cn4g6iyIiUpTIlN3B6o g1kaJs1cJvxTRg== X-ME-Sender: X-Sasl-enc: R2WmgSYtbyIXRA5H7ZIFDSYkbULAt/+dHYpnaH3jD4gp 1490895695 Received: from aither.local (c-98-245-40-52.hsd1.co.comcast.net [98.245.40.52]) by mail.messagingengine.com (Postfix) with ESMTPA id 785137E70C; Thu, 30 Mar 2017 13:41:35 -0400 (EDT) To: Peter Thatcher , Christer Holmberg , =?UTF-8?Q?Ari_Ker=c3=a4nen?= References: <7ebb3254-a882-6e05-3159-0ec56614831b@stpeter.im> <7e9e8188-2add-0497-e94f-14ee41afe02d@stpeter.im> <7594FB04B1934943A5C02806D1A2204B4CB330A0@ESESSMB109.ericsson.se> <7594FB04B1934943A5C02806D1A2204B4CB378CD@ESESSMB109.ericsson.se> Cc: "ice@ietf.org" From: Peter Saint-Andre Message-ID: <0308af65-2cc9-c793-946d-6157d71db069@stpeter.im> Date: Thu, 30 Mar 2017 11:41:34 -0600 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.12; rv:45.0) Gecko/20100101 Thunderbird/45.8.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [Ice] Trickle ICE review X-BeenThere: ice@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "Interactive Connectivity Establishment \(ICE\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 30 Mar 2017 17:41:46 -0000 On 3/30/17 9:45 AM, Peter Thatcher wrote: > Ah, I see what you mean now. > > In that case, could we just define "ICE session" as the something like > "stuff until the next ICE restart or the termination of all ICE activity > by this agent"? Right, there's no "ICE session termination" message, so that'll have to do. Peter From nobody Thu Mar 30 10:54:12 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 ED561129639 for ; Thu, 30 Mar 2017 10:54:10 -0700 (PDT) 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 JCH8UdDK4dXP for ; Thu, 30 Mar 2017 10:54:09 -0700 (PDT) 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 1340312952F for ; Thu, 30 Mar 2017 10:54:08 -0700 (PDT) X-AuditID: c1b4fb2d-64c6598000005be8-b6-58dd463f2d4d Received: from ESESSHC001.ericsson.se (Unknown_Domain [153.88.183.21]) by (Symantec Mail Security) with SMTP id 9C.E8.23528.F364DD85; Thu, 30 Mar 2017 19:54:07 +0200 (CEST) Received: from ESESSMB109.ericsson.se ([169.254.9.242]) by ESESSHC001.ericsson.se ([153.88.183.21]) with mapi id 14.03.0339.000; Thu, 30 Mar 2017 19:53:31 +0200 From: Christer Holmberg To: Peter Saint-Andre , Peter Thatcher , =?utf-8?B?QXJpIEtlcsOkbmVu?= CC: "ice@ietf.org" Thread-Topic: [Ice] Trickle ICE review Thread-Index: AQHSpd5vLfPb95agJ06E1TropZKa9qGnVe4AgAJB1wCAALtqgIAABEwAgAA6hcCAAeVgAIAA7JYggAAINACAACBRAIAAJKPg Date: Thu, 30 Mar 2017 17:53:31 +0000 Message-ID: <7594FB04B1934943A5C02806D1A2204B4CB38EBB@ESESSMB109.ericsson.se> References: <7ebb3254-a882-6e05-3159-0ec56614831b@stpeter.im> <7e9e8188-2add-0497-e94f-14ee41afe02d@stpeter.im> <7594FB04B1934943A5C02806D1A2204B4CB330A0@ESESSMB109.ericsson.se> <7594FB04B1934943A5C02806D1A2204B4CB378CD@ESESSMB109.ericsson.se> <0308af65-2cc9-c793-946d-6157d71db069@stpeter.im> In-Reply-To: <0308af65-2cc9-c793-946d-6157d71db069@stpeter.im> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [153.88.183.149] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFmpikeLIzCtJLcpLzFFi42KZGbFdVNfe7W6EQd8cBYtvF2otri1/zWpx bE8/swOzx4JNpR5Llvxk8pi75wVzAHMUl01Kak5mWWqRvl0CV8a/C8tZC9o4K45fuMPYwPiC o4uRk0NCwERiY0MTaxcjF4eQwHpGiU37OpkhnCWMEp/ur2LvYuTgYBOwkOj+pw0SFxHoY5S4 PP0uK0icWUBR4uVeNZBBwgKqEvNmXmYDsUUE1CQuzuhhAykREciTWPcrCCTMAlTS9WUjK4jN K+Ar8X/ZNKi9/1kkLt/7xQ6S4BSwk1hzbAZYEaOAmMT3U2uYQGxmAXGJW0/mM0EcLSCxZM95 ZghbVOLl43+sELaSxNrD21kgTtOUWL9LH6JVUWJK90N2iL2CEidnPmGZwCg6C8nUWQgds5B0 zELSsYCRZRWjaHFqcXFuupGxXmpRZnJxcX6eXl5qySZGYMwc3PJbdwfj6teOhxgFOBiVeHgf 7L0dIcSaWFZcmXuIUYKDWUmE9+RKoBBvSmJlVWpRfnxRaU5q8SFGaQ4WJXFeh30XIoQE0hNL UrNTUwtSi2CyTBycUg2M1X/NPEofv2J1n3bH5rPnJQ3myn+3uyISDb44RDtucpHbn79L4PLe g37NV6U2T306S8rAbGdz6bvN51JrMov3dlhXpMuX2Xpf+S9o233v5W33toawL6ev/G26syff /u7yR2XqAmZLlO/+l7U5ffse75KL4WsVZ2kUef768+VTMffmggkFS9h3KrEUZyQaajEXFScC APLuKLiVAgAA Archived-At: Subject: Re: [Ice] Trickle ICE review X-BeenThere: ice@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "Interactive Connectivity Establishment \(ICE\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 30 Mar 2017 17:54:11 -0000 SGksDQoNClBlcmhhcHMgd2UgY291bGQgc2F5IHNvbWV0aGluZyBsaWtlICJyZS1zdGFydCBvciBv bmNlIGFsbCBjYW5kaWRhdGVzIGhhdmUgYmVlbiByZWxlYXNlZCIsIG9yIHNvbWV0aGluZyBsaWtl IHRoYXQuLi4gV2Ugc2VlbSB0byBhZ3JlZSwgc28gaXQncyBqdXN0IGFib3V0IHdvcmRpbmcgOikN Cg0KUmVnYXJkcywNCg0KQ2hyaXN0ZXINCg0KLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCkZy b206IFBldGVyIFNhaW50LUFuZHJlIFttYWlsdG86c3RwZXRlckBzdHBldGVyLmltXSANClNlbnQ6 IDMwIE1hcmNoIDIwMTcgMjA6NDINClRvOiBQZXRlciBUaGF0Y2hlciA8cHRoYXRjaGVyQGdvb2ds ZS5jb20+OyBDaHJpc3RlciBIb2xtYmVyZyA8Y2hyaXN0ZXIuaG9sbWJlcmdAZXJpY3Nzb24uY29t PjsgQXJpIEtlcsOkbmVuIDxhcmkua2VyYW5lbkBlcmljc3Nvbi5jb20+DQpDYzogaWNlQGlldGYu b3JnDQpTdWJqZWN0OiBSZTogW0ljZV0gVHJpY2tsZSBJQ0UgcmV2aWV3DQoNCk9uIDMvMzAvMTcg OTo0NSBBTSwgUGV0ZXIgVGhhdGNoZXIgd3JvdGU6DQo+IEFoLCBJIHNlZSB3aGF0IHlvdSBtZWFu IG5vdy4gIA0KPiANCj4gSW4gdGhhdCBjYXNlLCBjb3VsZCB3ZSBqdXN0IGRlZmluZSAiSUNFIHNl c3Npb24iIGFzIHRoZSBzb21ldGhpbmcgbGlrZSANCj4gInN0dWZmIHVudGlsIHRoZSBuZXh0IElD RSByZXN0YXJ0IG9yIHRoZSB0ZXJtaW5hdGlvbiBvZiBhbGwgSUNFIA0KPiBhY3Rpdml0eSBieSB0 aGlzIGFnZW50Ij8NCg0KUmlnaHQsIHRoZXJlJ3Mgbm8gIklDRSBzZXNzaW9uIHRlcm1pbmF0aW9u IiBtZXNzYWdlLCBzbyB0aGF0J2xsIGhhdmUgdG8gZG8uDQoNClBldGVyDQoNCg== From nobody Thu Mar 30 20:45: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 AC44112975C for ; Thu, 30 Mar 2017 20:45:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no 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 FWDNzplxZ8t9 for ; Thu, 30 Mar 2017 20:45:03 -0700 (PDT) Received: from mail-qt0-x229.google.com (mail-qt0-x229.google.com [IPv6:2607:f8b0:400d:c0d::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 8F37412978B for ; Thu, 30 Mar 2017 20:45:01 -0700 (PDT) Received: by mail-qt0-x229.google.com with SMTP id x35so55813005qtc.2 for ; Thu, 30 Mar 2017 20:45:01 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=XcglaDJLi8EY2aEZ2LXS9LkEz7JRzExWlMS8RErvSXs=; b=RGBqGOwULTZqdKxjivFWAB54tssrid6peyoUVM5KIiAvM/dYP0qilP+AEzYwDKSpif eOhj5/0J5k4fPy9dRn1dx3lAokwl1eaqVKRIwlzpQgLhsR7ciAX42QzYaCBmW8ffILmh Hz0bSBQjW0XrjVefecz0sZeccun6xaGprRwfeg3IwicTlmlhZK6/iHX836aKlFWingro VeTAxUaoVW9Rd4UE5ztIFCxNhTTfuqza90eDVSmw69HH3MOGSV2LsffZruqiEVo3yI7L sK6pbiGHdVAYiRJBTB2ZDpZKV+c5ADSZYrgCTEsJd4OqmGzFa5PK1tAHwHHejPK2zQQe Zu+g== 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=XcglaDJLi8EY2aEZ2LXS9LkEz7JRzExWlMS8RErvSXs=; b=kpOCb46fTSPYA6Enlvzw+lkXFm/m5Aw3xNZx3pLSWOwatbNZm/YkE/6x9AOMmmE8de SAQCwpkrqEL8XF8pAsaAEQOkpxwwwNJpnbXtMKzCiQjZGM0lZ1zJlOnjpgPkAB1KfTEq JILdt08gfMoa5k6lBGIXzMQFKsSt4SesYSM5PJTrDfkUuvy4VvN5CeYGSZyeRAptTvN0 6wdnuACafRLbjEIKAU1y5AN4iZ/vTDSeSffhLW2BUeuOEB04mpTzm+BKlpbrm7X1DEYQ epUrtIN5Znwex0eZeo4QLS0PE8gjKTuJSgGZIhU+Q+dHjLOJ2qajrsP83eSLBwDni5PR nHsA== X-Gm-Message-State: AFeK/H2Z2JpAXkZjBCvmP38F83cxSAZhVz6rfITJXkOmzaD28NZDiRdCr8PX6mi3ndH4tS8NR4C1OgbwprjLmXIo X-Received: by 10.237.41.7 with SMTP id s7mr740644qtd.64.1490931900601; Thu, 30 Mar 2017 20:45:00 -0700 (PDT) MIME-Version: 1.0 Received: by 10.12.154.209 with HTTP; Thu, 30 Mar 2017 20:45:00 -0700 (PDT) In-Reply-To: <7594FB04B1934943A5C02806D1A2204B4CB38EBB@ESESSMB109.ericsson.se> References: <7ebb3254-a882-6e05-3159-0ec56614831b@stpeter.im> <7e9e8188-2add-0497-e94f-14ee41afe02d@stpeter.im> <7594FB04B1934943A5C02806D1A2204B4CB330A0@ESESSMB109.ericsson.se> <7594FB04B1934943A5C02806D1A2204B4CB378CD@ESESSMB109.ericsson.se> <0308af65-2cc9-c793-946d-6157d71db069@stpeter.im> <7594FB04B1934943A5C02806D1A2204B4CB38EBB@ESESSMB109.ericsson.se> From: Taylor Brandstetter Date: Thu, 30 Mar 2017 20:45:00 -0700 Message-ID: To: Christer Holmberg Cc: Peter Saint-Andre , Peter Thatcher , =?UTF-8?B?QXJpIEtlcsOkbmVu?= , "ice@ietf.org" Content-Type: multipart/alternative; boundary=94eb2c06b00c52386a054bfea2fb Archived-At: Subject: Re: [Ice] Trickle ICE review X-BeenThere: ice@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "Interactive Connectivity Establishment \(ICE\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 31 Mar 2017 03:45:07 -0000 --94eb2c06b00c52386a054bfea2fb Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable > > In the phrase " A Trickle ICE agent MUST NOT pair a local candidate until > it has been trickled to the remote agent.", what does "has been trickled" > mean? Sorry I'm late at responding to this, but I assumed the main intention here was that candidates are paired in the same order that they're trickled, because that was necessary for the unfreezing logic to work. For example: suppose an endpoint already has remote candidates, and then gathers RTP and RTCP candidates. It pairs them in the order "RTCP, RTP" (maybe the STUN response for the RTCP candidate came back first), resulting in an RTCP pair being unfrozen first, but they're trickled in the order "RTP, RTCP" (as a result of the restrictions of section 16), resulting in the remote endpoint unfreezing the RTP pair first. Before, this would have resulted in things failing (as I recall). But this isn't as much of a problem now; I'm looking at the current section 8.1.1, and it would result in the local endpoint just unfreezing *both* pairs, so things would be able to proceed. But it still could result in extra pairs being unfrozen; is that acceptable? If not, I'd suggest moving this note to section 16, and making it more clear what the intention is. For example: "Candidates MUST be paired, following the procedures in section 8.1.1, in the same order that they're trickled." An important related question: There used to be a line that said "When trickle updates are sent, each candidate MUST be delivered to the receiving Trickle ICE implementation ... in the same order that they were sent." But the "in the same order that they were sent" part has been removed. Do we no longer require that the signaling mechanism preserves ordering? If so, Section 16 doesn't make sense any more; it requires a specific order of candidate trickling, but that can't be guaranteed if the signaling mechanism doesn't preserve ordering. All my ramblings above would be moot as well. On Thu, Mar 30, 2017 at 10:53 AM, Christer Holmberg < christer.holmberg@ericsson.com> wrote: > Hi, > > Perhaps we could say something like "re-start or once all candidates have > been released", or something like that... We seem to agree, so it's just > about wording :) > > Regards, > > Christer > > -----Original Message----- > From: Peter Saint-Andre [mailto:stpeter@stpeter.im] > Sent: 30 March 2017 20:42 > To: Peter Thatcher ; Christer Holmberg < > christer.holmberg@ericsson.com>; Ari Ker=C3=A4nen > Cc: ice@ietf.org > Subject: Re: [Ice] Trickle ICE review > > On 3/30/17 9:45 AM, Peter Thatcher wrote: > > Ah, I see what you mean now. > > > > In that case, could we just define "ICE session" as the something like > > "stuff until the next ICE restart or the termination of all ICE > > activity by this agent"? > > Right, there's no "ICE session termination" message, so that'll have to d= o. > > Peter > > _______________________________________________ > Ice mailing list > Ice@ietf.org > https://www.ietf.org/mailman/listinfo/ice > --94eb2c06b00c52386a054bfea2fb Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
In the phrase " A Trickle I= CE agent MUST NOT pair a local candidate until it has been trickled to the = remote agent.", what does "has been trickled" mean?

Sorry I'm late at responding to this, bu= t I assumed the main intention here was that candidates are paired in the s= ame order that they're trickled, because that was necessary for the unf= reezing logic to work. For example: suppose an endpoint already has remote = candidates, and then gathers RTP and RTCP candidates. It pairs them in the = order "RTCP, RTP" (maybe the STUN response for the RTCP candidate= came back first), resulting in an RTCP pair being unfrozen first, but they= 're trickled in the order "RTP, RTCP" (as a result of the res= trictions of section 16), resulting in the remote endpoint unfreezing the R= TP pair first.

Before, this would have resulted in= things failing (as I recall). But this isn't as much of a problem now;= I'm looking at the current section 8.1.1, and it would result in the l= ocal endpoint just unfreezing both=C2=A0pairs, so things would be ab= le to proceed.

But it still could result in extra = pairs being unfrozen; is that acceptable? If not, I'd suggest moving th= is note to section 16, and making it more clear what the intention is. For = example: "Candidates MUST be paired, following the procedures in secti= on 8.1.1, in the same order that they're trickled."

=
An important related question: There used to be a line that said= "When trickle updates are sent, each candidate MUST be delivered to t= he receiving Trickle ICE implementation ... in the same order that they wer= e sent." But the "in the same order that they were sent" par= t has been removed. Do we no longer require that the signaling mechanism pr= eserves ordering? If so, Section 16 doesn't make sense any more; it req= uires a specific order of candidate trickling, but that can't be guaran= teed if the signaling mechanism doesn't preserve ordering. All my rambl= ings above would be moot as well.
On Thu, Mar 30, 2017 at 10:53 AM, Christer Holm= berg <christer.holmberg@ericsson.com> wrote:
Hi,

Perhaps we could say something like "re-start or once all candidates h= ave been released", or something like that... We seem to agree, so it&= #39;s just about wording :)

Regards,

Christer

-----Original Message-----
From: Peter Saint-Andre [mailto:stpet= er@stpeter.im]
Sent: 30 March 2017 20:42
To: Peter Thatcher <pthatcher@go= ogle.com>; Christer Holmberg <christer.holmberg@ericsson.com>; Ari Ker=C3=A4ne= n <ari.keranen@ericsson.com<= /a>>
Cc: ice@ietf.org
Subject: Re: [Ice] Trickle ICE review

On 3/30/17 9:45 AM, Peter Th= atcher wrote:
> Ah, I see what you mean now.
>
> In that case, could we just define "ICE session" as the some= thing like
> "stuff until the next ICE restart or the termination of all ICE > activity by this agent"?

Right, there's no "ICE session termination" message, so that&= #39;ll have to do.

Peter

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

--94eb2c06b00c52386a054bfea2fb-- From nobody Thu Mar 30 22:28:50 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 B054E1297C4 for ; Thu, 30 Mar 2017 22:28:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.74 X-Spam-Level: X-Spam-Status: No, score=-1.74 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, HTML_OBFUSCATE_05_10=0.26, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=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 Y7FtNAF9ZTKh for ; Thu, 30 Mar 2017 22:28:45 -0700 (PDT) Received: from mail-qt0-x232.google.com (mail-qt0-x232.google.com [IPv6:2607:f8b0:400d:c0d::232]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7C39F1292D3 for ; Thu, 30 Mar 2017 22:28:44 -0700 (PDT) Received: by mail-qt0-x232.google.com with SMTP id n21so57145191qta.1 for ; Thu, 30 Mar 2017 22:28:44 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:from:date:message-id:subject:to; bh=HV9foFhaCCQHfGrQnFSLjJWIj0t2aUZwCvfVjg724mk=; b=BicZiRrrHoOakgDrbc0DbQKuyouXcruBVQuioM6N8pmsm/xFoOmUTs+TJPRfQj7RXB o5SJQoF/DCqc3lOlQvnOFTBbconXbfLBbabCb60U45ERQgG41PAoND+memWKQgfjlZPJ 8EXke4j39hvqsmJLSTkNOvrX61qHWIjWOfNRZo6/pFgRZPzjDyWK+o/Jz79k7Xq8ZU8D 8lR/pNU7H87xrqzYRSgiRTFmFzlRzoyjuaIDy5ovx4AgQA71gh4g7dz2GDU2rWhpdYHV BZm3uh2p76o2zsIQvauiBfq8/EUwMRYW11JGaFfVQ+YbS+HFRuae10ms8snZd9KiN5sb vwfQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:from:date:message-id:subject:to; bh=HV9foFhaCCQHfGrQnFSLjJWIj0t2aUZwCvfVjg724mk=; b=dTK4SMBo44pXRylEUrlxPU8GOYcDnQYQg08FcypQ36rQoFtQkeXfMM4gVZ9SaXLEBK 7iw7hS26hcRcK7SDdsfNCmyHXJ9X/hFfaEkrn5rtUa+5GGqKwqMXzb27Md9030+TLPRJ fhzwHw324Ay86lxfKwbrEqjIq0l3dK6CGmWc8qBumTltXgpXhrGEuVDLGtgXHdunHchg zdKNMP0mm7Z+yMhgOk90qI9jr2NdnmF3glhT/SvO04GSFe86MBQFsuxgeoEj2I03vWVP 9LOIByxeAJCm9+Y6oUWWbIRChYLpRQA6C5g4yRL18VxhGG2snrNVfQUMymKsxkcjmBUM qGBw== X-Gm-Message-State: AFeK/H0p9SPyj7HtwIijd4FQ2Ja3Wh/J0Pog75qTJwdGEkPtMz+13TX6fUCrIsfNAEQrBpVtkiC7exArbK3s2irU X-Received: by 10.200.50.112 with SMTP id y45mr977868qta.75.1490938123330; Thu, 30 Mar 2017 22:28:43 -0700 (PDT) MIME-Version: 1.0 Received: by 10.12.154.209 with HTTP; Thu, 30 Mar 2017 22:28:42 -0700 (PDT) From: Taylor Brandstetter Date: Thu, 30 Mar 2017 22:28:42 -0700 Message-ID: To: ice@ietf.org Content-Type: multipart/alternative; boundary=001a11403d68398d6f054c00153f Archived-At: Subject: [Ice] Taylor's review of draft-ietf-ice-trickle-08.txt X-BeenThere: ice@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "Interactive Connectivity Establishment \(ICE\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 31 Mar 2017 05:28:48 -0000 --001a11403d68398d6f054c00153f Content-Type: text/plain; charset=UTF-8 I reviewed Trickle ICE, and overall I think it's in pretty good shape. The main remaining areas I believe could be improved are: 1. Using terminology that's too SDP-specific. This has been improved a lot since I last reviewed, but in my opinion it could still be made a bit better. If it used the same sort of terminology as ICEbis ("convey the ICE parameters" as opposed to "send an ICE description"), I'd be happy. But I may be nitpicking too much. 2. The unfreezing logic still doesn't seem perfect. If there are people who still feel it's important, I'd be glad to explain the issues as I see them further and work on fixing them. Though, I'm fine with saying "what we have is good enough." The current unfreezing logic at least now clearly ensures that one candidate per foundation is always unfrozen. Here are the individual issues I found: - In the terminology section: - The definition of "ICE description" refers to SDP attributes like "ice-ufrag" by name. This should be changed to just say "username fragment" (for instance) and not rely on SDP terminology. - Also, in my opinion, using the terms "description," "session" and even "attribute" ties this too much to SDP. ICEbis uses the phrase "candidate information" to refer to the collection of information that's signaled; can Trickle ICE refer to this, and use similar terminology? ICEbis also says "parameter" rather than "attribute". - Related to the above: the concept of "sending an ICE description," used in many places, sounds too much like "sending an SDP offer" to me. ICEbis uses terminology like "the following parameters and their data types need to be conveyed as a part of the candidate exchange process," which is much less prescriptive of an offer/answer or message-based signaling protocol. Again; could Trickle ICE use similar terminology? - In section 5.2: "With regard to pruning of duplicate candidate pairs, a Trickle ICE agent SHOULD follow a policy of pruning the lower priority candidate unless it is peer reflexive." This makes it sound like peer reflexive candidates are *never* pruned, but it's the opposite; they're *always* pruned, as described in Section 8.1. Also, in ICEbis, candidates themselves aren't pruned, only candidate pairs are. - In section 7.2: "Therefore a Trickle ICE agent MUST monitor whether a check list is active or frozen independently of the state of the candidate pairs in the check list (since there might not be any pairs yet), and MUST consider a check list to be active whenever it adds the first candidate pair with a state of Waiting to the check list (see Section 8.1.1)." The first MUST seems redundant with the second. In earlier drafts, the purpose of monitoring the "active/frozen" state independently was so that if a check list is empty and frozen, the first pair added starts as "Frozen", while if it's empty and active, the first pair added starts as "Waiting." If the first pair *always* starts as "Waiting," then tracking the active/frozen state of a check list independently is no longer necessary. Though I don't see anything in Section 8.1.1 that relates specifically to this, so I'm not sure what "see Section 8.1.1" is referring to. - In section 8.1.1: In general I like the improvements that have been made. However: - The rules for how a new pair gets either a "Waiting" or "Frozen" state don't completely match standard ICE; at least the part where when one "media stream" completes, pairs from other media streams with matching foundations are unfrozen. With the current rules in section 8.1.1, only the topmost remaining pair in each foundation is guaranteed to be unfrozen. Is this difference acceptable? If it is, we should at least acknowledge it, and not give the wrong impression by saying "Trickle ICE preserves all of [the standard ICE] rules." - The rule that a pair changes to "Waiting" if a pair in a lower row is "Succeeded" means that if a pair in the lowermost row is unfrozen first (which is possible, if the signaling mechanism doesn't preserve ordering of candidates), all of the other pairs with its foundation would be unfrozen as soon as it's unfrozen. This seems odd. - As mentioned in a different email thread, Section 16 doesn't make sense any more if the signaling protocol isn't required to preserve candidate ordering. I also found a couple of really trivial things, which I made a PR for: https://github.com/ice-wg/trickle/pull/10 --001a11403d68398d6f054c00153f Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
I reviewed Trickle ICE, and overall I think it's = in pretty good shape. The main remaining areas I believe could be improved = are:
  1. Using terminology that's too SDP-specific. This has b= een improved a lot since I last reviewed, but in my opinion it could still = be made a bit better. If it used the same sort of terminology as ICEbis (&q= uot;convey the ICE parameters" as opposed to "send an ICE descrip= tion"), I'd be happy. But I may be nitpicking too much.
  2. Th= e unfreezing logic still doesn't seem perfect. If there are people who = still feel it's important, I'd be glad to explain the issues as I s= ee them further and work on fixing them. Though, I'm fine with saying &= quot;what we have is good enough." The current unfreezing logic at lea= st now clearly ensures that one candidate per foundation is always unfrozen= .
Here are the individual issues I found:
  • In the= terminology section:
    • The definition of "ICE description&q= uot; refers to SDP attributes like "ice-ufrag" by name. This shou= ld be changed to just say "username fragment" (for instance) and = not rely on SDP terminology.
    • Also, in my opinion, using the terms &= quot;description," "session" and even "attribute" = ties this too much to SDP. ICEbis uses the phrase "candidate informati= on" to refer to the collection of information that's signaled; can= Trickle ICE refer to this, and use similar terminology? ICEbis also says &= quot;parameter" rather than "attribute".
    • Related to = the above: the concept of "sending an ICE description," used in many places, sounds too much lik= e "sending an SDP offer" to me. ICEbis uses terminology like &quo= t;the=C2=A0following parameters and their data types need to be conv= eyed as a part of the candidate exchange process," which is much less = prescriptive of an offer/answer or message-based signaling protocol. Again;= could Trickle ICE use similar terminology?
  • In section 5.2: &q= uot;With regard to pruning of duplicate candidate pairs, a Trickle ICE agen= t SHOULD follow a policy of pruning the lower priority candidate unless it = is peer reflexive." This makes it sound like peer reflexive candidates= are never=C2=A0pruned, but it's the opposite; they're al= ways=C2=A0pruned, as described in Section 8.1. Also, in ICEbis, candida= tes themselves aren't pruned, only candidate pairs are.
  • In sect= ion 7.2: "Therefore a Trickle ICE agent MUST monitor whether a check l= ist is active or frozen independently of the state of the candidate pairs i= n the check list (since there might not be any pairs yet), and MUST conside= r a check list to be active whenever it adds the first candidate pair with = a state of Waiting to the check list (see Section 8.1.1)." The first M= UST seems redundant with the second. In earlier drafts, the purpose of moni= toring the "active/frozen" state independently was so that if a c= heck list is empty and frozen, the first pair added starts as "Frozen&= quot;, while if it's empty and active, the first pair added starts as &= quot;Waiting." If the first pair always=C2=A0starts as "Wa= iting," then tracking the active/frozen state of a check list independ= ently is no longer necessary. Though I don't see anything in Section 8.= 1.1 that relates specifically to this, so I'm not sure what "see S= ection 8.1.1" is referring to.
  • In section 8.1.1: In general I = like the improvements that have been made. However:
    • The rules f= or how a new pair gets either a "Waiting" or "Frozen" s= tate don't completely match standard ICE; at least the part where when = one "media stream" completes, pairs from other media streams with= matching foundations are unfrozen. With the current rules in section 8.1.1= , only the topmost remaining pair in each foundation is guaranteed to be un= frozen. Is this difference acceptable? If it is, we should at least acknowl= edge it, and not give the wrong impression by saying "Trickle ICE pres= erves all of [the standard ICE] rules."
    • The rule that a pair c= hanges to "Waiting" if a pair in a lower row is "Succeeded&q= uot; means that if a pair in the lowermost row is unfrozen first (which is = possible, if the signaling mechanism doesn't preserve ordering of candi= dates), all of the other pairs with its foundation would be unfrozen as soo= n as it's unfrozen. This seems odd.
  • As mentioned in a diff= erent email thread, Section 16 doesn't make sense any more if the signa= ling protocol isn't required to preserve candidate ordering.
<= div>I also found a couple of really trivial things, which I made a PR for:= =C2=A0https://github.= com/ice-wg/trickle/pull/10
--001a11403d68398d6f054c00153f-- From nobody Thu Mar 30 22:35:22 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 964071292D3 for ; Thu, 30 Mar 2017 22:35:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.74 X-Spam-Level: X-Spam-Status: No, score=-1.74 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, HTML_OBFUSCATE_05_10=0.26, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=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 2Tebzgv3nJtA for ; Thu, 30 Mar 2017 22:35:17 -0700 (PDT) Received: from mail-qk0-x229.google.com (mail-qk0-x229.google.com [IPv6:2607:f8b0:400d:c09::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 7632B128C81 for ; Thu, 30 Mar 2017 22:35:17 -0700 (PDT) Received: by mail-qk0-x229.google.com with SMTP id r142so58539590qke.2 for ; Thu, 30 Mar 2017 22:35:17 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to; bh=2AGrn5WpCQ6NdosbGxf4T/8Zw7QkT14hL1ySvAmAm2g=; b=it3MOdmi70Gku4lim8iy24T1FNd/tMHXU6hGv8ZIsoWHzbR4qrL39T0XsHWfeFrlbN zSDP8+d5/ybndMFWbUUpjSaiLsU/gydcMvZY6jtcHUuTUa+HrEw/XU6jK0MXvv4pxMZa VM51weslyVw4ZAOxDlrK6wDRZ+H71JmeQ6ydat12D3fTNGLrngQS5olpiWg1P6mJh3q2 4s2k0x+PsgUp0YT1VgO1Gk2GOF5w3nnEoe9KW3Kj+rMEIxpS3Emtjrz6xcgcdSVP8cTU GjbZyZ0t1yCIrnuA7WNIfViUgNa1gNiqD/XZIBWwDo/AQJ9lmPbq4o29lMKqYlHReoJx 8Jiw== 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; bh=2AGrn5WpCQ6NdosbGxf4T/8Zw7QkT14hL1ySvAmAm2g=; b=bnSfavoXVpy7KNebjQrRFgxxFErJ0G+sbmV7V92nO/xpmCFcj5ZpPoE9TeWmYmW3In 620TYcT4bKTnsAH10LpuQb4dCqfbi6LS0miW/IaldzjcOYti5onYl7+yUcFWEtO1nt19 tzD0ZnpRWCcYj5zyil+uXSHjJ+7+01hlKC6k39Jm/5Xr2wqDOwzuMdD9mUskzl4p25t+ Ocweb/kFZVv57+n/hrDgU97iu5R+7ZR6O0MgZiElj1jzokh8eKP7yAKoE9PLYY/1mpCz yZ1uGoMf8THWRFBSEDCeczZlKV0ycHmA+UaH55d9IINCrkl2dHhvYd3uDR0uIjt8ldrH vi+g== X-Gm-Message-State: AFeK/H2hePoIFoYlphO+YE8pWhijoFprnh3kj8N2wzTqjZDgJHGvf7WejZnWFwUm2Xp4KOsxyHFFwrlNI6r0Q4Jo X-Received: by 10.55.155.141 with SMTP id d135mr1009934qke.75.1490938516348; Thu, 30 Mar 2017 22:35:16 -0700 (PDT) MIME-Version: 1.0 Received: by 10.12.154.209 with HTTP; Thu, 30 Mar 2017 22:35:15 -0700 (PDT) In-Reply-To: References: From: Taylor Brandstetter Date: Thu, 30 Mar 2017 22:35:15 -0700 Message-ID: To: ice@ietf.org Content-Type: multipart/alternative; boundary=94eb2c07684aa68480054c002c6d Archived-At: Subject: Re: [Ice] Taylor's review of draft-ietf-ice-trickle-08.txt X-BeenThere: ice@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "Interactive Connectivity Establishment \(ICE\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 31 Mar 2017 05:35:20 -0000 --94eb2c07684aa68480054c002c6d Content-Type: text/plain; charset=UTF-8 Minor clarification: when I said "all of the other pairs with [the lowermost pair's] foundation would be unfrozen as soon as it's unfrozen", this would only occur if the other pairs are formed after the lowermost pair succeeds. Which makes this more of a corner case. On Thu, Mar 30, 2017 at 10:28 PM, Taylor Brandstetter wrote: > I reviewed Trickle ICE, and overall I think it's in pretty good shape. The > main remaining areas I believe could be improved are: > > 1. Using terminology that's too SDP-specific. This has been improved a > lot since I last reviewed, but in my opinion it could still be made a bit > better. If it used the same sort of terminology as ICEbis ("convey the ICE > parameters" as opposed to "send an ICE description"), I'd be happy. But I > may be nitpicking too much. > 2. The unfreezing logic still doesn't seem perfect. If there are > people who still feel it's important, I'd be glad to explain the issues as > I see them further and work on fixing them. Though, I'm fine with saying > "what we have is good enough." The current unfreezing logic at least now > clearly ensures that one candidate per foundation is always unfrozen. > > Here are the individual issues I found: > > - In the terminology section: > - The definition of "ICE description" refers to SDP attributes like > "ice-ufrag" by name. This should be changed to just say "username fragment" > (for instance) and not rely on SDP terminology. > - Also, in my opinion, using the terms "description," "session" and > even "attribute" ties this too much to SDP. ICEbis uses the phrase > "candidate information" to refer to the collection of information that's > signaled; can Trickle ICE refer to this, and use similar terminology? > ICEbis also says "parameter" rather than "attribute". > - Related to the above: the concept of "sending an ICE description," > used in many places, sounds too much like "sending an SDP offer" to me. > ICEbis uses terminology like "the following parameters and their > data types need to be conveyed as a part of the candidate exchange > process," which is much less prescriptive of an offer/answer or > message-based signaling protocol. Again; could Trickle ICE use similar > terminology? > - In section 5.2: "With regard to pruning of duplicate candidate > pairs, a Trickle ICE agent SHOULD follow a policy of pruning the lower > priority candidate unless it is peer reflexive." This makes it sound like > peer reflexive candidates are *never* pruned, but it's the opposite; > they're *always* pruned, as described in Section 8.1. Also, in ICEbis, > candidates themselves aren't pruned, only candidate pairs are. > - In section 7.2: "Therefore a Trickle ICE agent MUST monitor whether > a check list is active or frozen independently of the state of the > candidate pairs in the check list (since there might not be any pairs yet), > and MUST consider a check list to be active whenever it adds the first > candidate pair with a state of Waiting to the check list (see Section > 8.1.1)." The first MUST seems redundant with the second. In earlier drafts, > the purpose of monitoring the "active/frozen" state independently was so > that if a check list is empty and frozen, the first pair added starts as > "Frozen", while if it's empty and active, the first pair added starts as > "Waiting." If the first pair *always* starts as "Waiting," then > tracking the active/frozen state of a check list independently is no longer > necessary. Though I don't see anything in Section 8.1.1 that relates > specifically to this, so I'm not sure what "see Section 8.1.1" is referring > to. > - In section 8.1.1: In general I like the improvements that have been > made. However: > - The rules for how a new pair gets either a "Waiting" or "Frozen" > state don't completely match standard ICE; at least the part where when one > "media stream" completes, pairs from other media streams with matching > foundations are unfrozen. With the current rules in section 8.1.1, only the > topmost remaining pair in each foundation is guaranteed to be unfrozen. Is > this difference acceptable? If it is, we should at least acknowledge it, > and not give the wrong impression by saying "Trickle ICE preserves all of > [the standard ICE] rules." > - The rule that a pair changes to "Waiting" if a pair in a lower > row is "Succeeded" means that if a pair in the lowermost row is unfrozen > first (which is possible, if the signaling mechanism doesn't preserve > ordering of candidates), all of the other pairs with its foundation would > be unfrozen as soon as it's unfrozen. This seems odd. > - As mentioned in a different email thread, Section 16 doesn't make > sense any more if the signaling protocol isn't required to preserve > candidate ordering. > > I also found a couple of really trivial things, which I made a PR for: > https://github.com/ice-wg/trickle/pull/10 > --94eb2c07684aa68480054c002c6d Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Minor clarification: when I said "all of the other pairs with [the lowermost pair's] founda= tion would be unfrozen as soon as it's unfrozen", this would only = occur if the other pairs are formed after the lowermost pair succeeds. Whic= h makes this more of a corner case.
=
On Thu, Mar 30, 2017 at 10:28 PM, Taylor Bra= ndstetter <deadbeef@google.com> wrote:
I reviewed Trickle ICE, and overall I = think it's in pretty good shape. The main remaining areas I believe cou= ld be improved are:
  1. Using terminology that's too SDP-speci= fic. This has been improved a lot since I last reviewed, but in my opinion = it could still be made a bit better. If it used the same sort of terminolog= y as ICEbis ("convey the ICE parameters" as opposed to "send= an ICE description"), I'd be happy. But I may be nitpicking too m= uch.
  2. The unfreezing logic still doesn't seem perfect. If there = are people who still feel it's important, I'd be glad to explain th= e issues as I see them further and work on fixing them. Though, I'm fin= e with saying "what we have is good enough." The current unfreezi= ng logic at least now clearly ensures that one candidate per foundation is = always unfrozen.
Here are the individual issues I found:
  • In the terminology section:
    • The definition of "IC= E description" refers to SDP attributes like "ice-ufrag" by = name. This should be changed to just say "username fragment" (for= instance) and not rely on SDP terminology.
    • Also, in my opinion, us= ing the terms "description," "session" and even "a= ttribute" ties this too much to SDP. ICEbis uses the phrase "cand= idate information" to refer to the collection of information that'= s signaled; can Trickle ICE refer to this, and use similar terminology? ICE= bis also says "parameter" rather than "attribute".
      • =
    • Related to the above: the concept of "sending an ICE description," used in many places, soun= ds too much like "sending an SDP offer" to me. ICEbis uses termin= ology like "the=C2=A0following parameters and their data types = need to be conveyed as a part of the candidate exchange process," whic= h is much less prescriptive of an offer/answer or message-based signaling p= rotocol. Again; could Trickle ICE use similar terminology?
  • In = section 5.2: "With regard to pruning of duplicate candidate pairs, a T= rickle ICE agent SHOULD follow a policy of pruning the lower priority candi= date unless it is peer reflexive." This makes it sound like peer refle= xive candidates are never=C2=A0pruned, but it's the opposite; th= ey're always=C2=A0pruned, as described in Section 8.1. Also, in = ICEbis, candidates themselves aren't pruned, only candidate pairs are.<= /li>
  • In section 7.2: "Therefore a Trickle ICE agent MUST monitor wh= ether a check list is active or frozen independently of the state of the ca= ndidate pairs in the check list (since there might not be any pairs yet), a= nd MUST consider a check list to be active whenever it adds the first candi= date pair with a state of Waiting to the check list (see Section 8.1.1).&qu= ot; The first MUST seems redundant with the second. In earlier drafts, the = purpose of monitoring the "active/frozen" state independently was= so that if a check list is empty and frozen, the first pair added starts a= s "Frozen", while if it's empty and active, the first pair ad= ded starts as "Waiting." If the first pair always=C2=A0sta= rts as "Waiting," then tracking the active/frozen state of a chec= k list independently is no longer necessary. Though I don't see anythin= g in Section 8.1.1 that relates specifically to this, so I'm not sure w= hat "see Section 8.1.1" is referring to.
  • In section 8.1.1= : In general I like the improvements that have been made. However:
      • =
    • The rules for how a new pair gets either a "Waiting" or "= ;Frozen" state don't completely match standard ICE; at least the p= art where when one "media stream" completes, pairs from other med= ia streams with matching foundations are unfrozen. With the current rules i= n section 8.1.1, only the topmost remaining pair in each foundation is guar= anteed to be unfrozen. Is this difference acceptable? If it is, we should a= t least acknowledge it, and not give the wrong impression by saying "T= rickle ICE preserves all of [the standard ICE] rules."
    • The rul= e that a pair changes to "Waiting" if a pair in a lower row is &q= uot;Succeeded" means that if a pair in the lowermost row is unfrozen f= irst (which is possible, if the signaling mechanism doesn't preserve or= dering of candidates), all of the other pairs with its foundation would be = unfrozen as soon as it's unfrozen. This seems odd.
  • As ment= ioned in a different email thread, Section 16 doesn't make sense any mo= re if the signaling protocol isn't required to preserve candidate order= ing.
I also found a couple of really trivial things, which I = made a PR for:=C2=A0https://github.com/ice-wg/trickle/pull/10

--94eb2c07684aa68480054c002c6d-- From nobody Fri Mar 31 15:03:40 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 40DC1126C22 for ; Fri, 31 Mar 2017 15:03:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=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 VL23H72mEMVX for ; Fri, 31 Mar 2017 15:03:35 -0700 (PDT) Received: from mail-qk0-x22e.google.com (mail-qk0-x22e.google.com [IPv6:2607:f8b0:400d:c09::22e]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8C7431201F2 for ; Fri, 31 Mar 2017 15:03:35 -0700 (PDT) Received: by mail-qk0-x22e.google.com with SMTP id d10so78488006qke.1 for ; Fri, 31 Mar 2017 15:03:35 -0700 (PDT) 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=JRtCzXbFS3SHzDijcE8LObAaMZ5GfAZm9bsWn/E7bKw=; b=U/nbzM82wcY8pRmANFxv3PjF0t/3kwI4jsV04csKNWoIPHwF2T+CLx+oOssUeyhkJ/ h8IxtQ9yIqnlaQFh40A9e5UqZNSvXzHCflCEqyhw8yjGkJc3hPHXpKjph6pfKfqhfq63 P9xbAbuWlHUE3HA1WwIlmOJygfoUidm4hajTHOltq5atuW6VZZR/8Cl07FqEh2A1FAxO 8uq04dfYXgkbFp8u3v5pcLV9eNCbDEQT0UlwxUsiltn7TfTrLed9JpWzkWeuM8RYDc5N ByWBCMArImH9uWKbgFa3U+5ToJSr2P3O9R/C54l2jfFbxMHyKX4LrfSJtANDF3ZxbtOe XmAg== 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=JRtCzXbFS3SHzDijcE8LObAaMZ5GfAZm9bsWn/E7bKw=; b=lvMV39x+mU4ow8MwKd9GJFX3MbvO6Uw+b8xeeM0NA1iZuNjNlyKQtu0/vG5MZWclBv MSnwGgNqw5iVqPPEiWGD3nQE1x8dmQX4/kwZwLbEL/a1p9IXtwlBXnL2WIKoa93Oexyc o51c325J4znlQPiodR98ICFu5UBrVtThi97kLZBn8YMi/ghNZ5CW39iQeIXd1BK3YHFC UebEdAEN8s1qzoZGX1Sg28yttxMKQEcxtbi9vjjhoy2AWRnyusfYpaKn4ZpDrIFKxsu+ Q7YJCuiPzAKcXRPfi/YPrwcBjS2gZOFJ2xLUdB9gcsYtz7KwVEr0O2H9Id6QxfDeCRGm vR6A== X-Gm-Message-State: AFeK/H1jGwJ3VNXpx+3jX1M9+uLjNhiF6TK2KXnnOfjBFI+v7xZpJLzTgFv3l9MdTiTP2ZJKSSsd1TnzZiXl4oJZ X-Received: by 10.55.17.35 with SMTP id b35mr5061459qkh.275.1490997814541; Fri, 31 Mar 2017 15:03:34 -0700 (PDT) MIME-Version: 1.0 References: <7ebb3254-a882-6e05-3159-0ec56614831b@stpeter.im> <7e9e8188-2add-0497-e94f-14ee41afe02d@stpeter.im> <7594FB04B1934943A5C02806D1A2204B4CB330A0@ESESSMB109.ericsson.se> <7594FB04B1934943A5C02806D1A2204B4CB378CD@ESESSMB109.ericsson.se> <0308af65-2cc9-c793-946d-6157d71db069@stpeter.im> <7594FB04B1934943A5C02806D1A2204B4CB38EBB@ESESSMB109.ericsson.se> In-Reply-To: From: Peter Thatcher Date: Fri, 31 Mar 2017 22:03:23 +0000 Message-ID: To: Taylor Brandstetter , Christer Holmberg Cc: =?UTF-8?B?QXJpIEtlcsOkbmVu?= , Peter Saint-Andre , "ice@ietf.org" Content-Type: multipart/alternative; boundary=001a11475c6418e7d5054c0dfbfa Archived-At: Subject: Re: [Ice] Trickle ICE review X-BeenThere: ice@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "Interactive Connectivity Establishment \(ICE\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 31 Mar 2017 22:03:38 -0000 --001a11475c6418e7d5054c0dfbfa Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Ah, thanks for explaining this. I like your idea of making the real intention explicit (pair and trickle in the same order). I think that's much more clear and precise. On Thu, Mar 30, 2017 at 8:45 PM Taylor Brandstetter wrote: In the phrase " A Trickle ICE agent MUST NOT pair a local candidate until it has been trickled to the remote agent.", what does "has been trickled" mean? Sorry I'm late at responding to this, but I assumed the main intention here was that candidates are paired in the same order that they're trickled, because that was necessary for the unfreezing logic to work. For example: suppose an endpoint already has remote candidates, and then gathers RTP and RTCP candidates. It pairs them in the order "RTCP, RTP" (maybe the STUN response for the RTCP candidate came back first), resulting in an RTCP pair being unfrozen first, but they're trickled in the order "RTP, RTCP" (as a result of the restrictions of section 16), resulting in the remote endpoint unfreezing the RTP pair first. Before, this would have resulted in things failing (as I recall). But this isn't as much of a problem now; I'm looking at the current section 8.1.1, and it would result in the local endpoint just unfreezing *both* pairs, so things would be able to proceed. But it still could result in extra pairs being unfrozen; is that acceptable? If not, I'd suggest moving this note to section 16, and making it more clear what the intention is. For example: "Candidates MUST be paired, following the procedures in section 8.1.1, in the same order that they're trickled." An important related question: There used to be a line that said "When trickle updates are sent, each candidate MUST be delivered to the receiving Trickle ICE implementation ... in the same order that they were sent." But the "in the same order that they were sent" part has been removed. Do we no longer require that the signaling mechanism preserves ordering? If so, Section 16 doesn't make sense any more; it requires a specific order of candidate trickling, but that can't be guaranteed if the signaling mechanism doesn't preserve ordering. All my ramblings above would be moot as well. On Thu, Mar 30, 2017 at 10:53 AM, Christer Holmberg < christer.holmberg@ericsson.com> wrote: Hi, Perhaps we could say something like "re-start or once all candidates have been released", or something like that... We seem to agree, so it's just about wording :) Regards, Christer -----Original Message----- From: Peter Saint-Andre [mailto:stpeter@stpeter.im] Sent: 30 March 2017 20:42 To: Peter Thatcher ; Christer Holmberg < christer.holmberg@ericsson.com>; Ari Ker=C3=A4nen Cc: ice@ietf.org Subject: Re: [Ice] Trickle ICE review On 3/30/17 9:45 AM, Peter Thatcher wrote: > Ah, I see what you mean now. > > In that case, could we just define "ICE session" as the something like > "stuff until the next ICE restart or the termination of all ICE > activity by this agent"? Right, there's no "ICE session termination" message, so that'll have to do. Peter _______________________________________________ Ice mailing list Ice@ietf.org https://www.ietf.org/mailman/listinfo/ice --001a11475c6418e7d5054c0dfbfa Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Ah, thanks for explaining this.=C2=A0 = I like your idea of making the real intention explicit (pair and trickle in= the same order).=C2=A0 I think that's much more clear and precise.




On Thu, Mar 30, 2017 at = 8:45 PM Taylor Brandstetter <deadbeef@google.com> wrote:
In the phrase " A Trickle ICE agent MUST NOT pair a local candi= date until it has been trickled to the remote agent.", what does "= ;has been trickled" mean?
=
Sorry I'm late at responding to this, but I assu= med the main intention here was that candidates are paired in the same orde= r that they're trickled, because that was necessary for the unfreezing = logic to work. For example: suppose an endpoint already has remote candidat= es, and then gathers RTP and RTCP candidates. It pairs them in the order &q= uot;RTCP, RTP" (maybe the STUN response for the RTCP candidate came ba= ck first), resulting in an RTCP pair being unfrozen first, but they're = trickled in the order "RTP, RTCP" (as a result of the restriction= s of section 16), resulting in the remote endpoint unfreezing the RTP pair = first.

Before, this would have resulted in things failing (as I r= ecall). But this isn't as much of a problem now; I'm looking at the= current section 8.1.1, and it would result in the local endpoint just unfr= eezing both=C2=A0pairs, so things would be able = to proceed.

But it still could result in extra pairs being unfroz= en; is that acceptable? If not, I'd suggest moving this note to section= 16, and making it more clear what the intention is. For example: "Can= didates MUST be paired, following the procedures in section 8.1.1, in the s= ame order that they're trickled."
An important related q= uestion: There used to be a line that said "When trickle updates are s= ent, each candidate MUST be delivered to the receiving Trickle ICE implemen= tation ... in the same order that they were sent." But the "in th= e same order that they were sent" part has been removed. Do we no long= er require that the signaling mechanism preserves ordering? If so, Section = 16 doesn't make sense any more; it requires a specific order of candida= te trickling, but that can't be guaranteed if the signaling mechanism d= oesn't preserve ordering. All my ramblings above would be moot as well.=

On Thu, Mar 30, 2017 at 10:53= AM, Christer Holmberg <christer.holmberg@ericsson.com> wrote:
Hi,

Perhaps we could say something like "re-start or once all candidates h= ave been released", or something like that... We seem to agree, so it&= #39;s just about wording :)

Regards,

Christer

-----Original Message-----
From: Peter Saint-Andre [mailto:stpeter@stpeter.im]
Sent: 30 March 2017 20:42
To: Peter Thatcher <pthatcher@google.com>; Christer Holmberg &= lt;christer.holmberg@ericsson.com>; Ari Ker=C3=A4nen &l= t;ari.keranen@ericsson.com>
Cc: i= ce@ietf.org
Subject: Re: [Ice] Trickle ICE review

On 3/30= /17 9:45 AM, Peter Thatcher wrote:
> Ah, I see what you mean now.
>
> In that case, could we just define "ICE session" as the some= thing like
> "stuff until the next ICE restart or the termination of all ICE > activity by this agent"?

Right, there's no "ICE session termination" message, so that&= #39;ll have to do.

Peter

_______________________________________________
Ice mailing list
Ice@i= etf.org
https://www.ietf.org/mailman/listinfo/i= ce
--001a11475c6418e7d5054c0dfbfa--