Re: [Ice] Peter's review of ICEbis - Christer's input on the rest of Peter's comments

Christer Holmberg <christer.holmberg@ericsson.com> Mon, 29 May 2017 07:08 UTC

Return-Path: <christer.holmberg@ericsson.com>
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 7FF481293D9 for <ice@ietfa.amsl.com>; Mon, 29 May 2017 00:08:53 -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 k0PUcReqtAbO for <ice@ietfa.amsl.com>; Mon, 29 May 2017 00:08:52 -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 084991200F1 for <ice@ietf.org>; Mon, 29 May 2017 00:08:51 -0700 (PDT)
X-AuditID: c1b4fb25-73a9f9a0000055fe-06-592bc9028ec6
Received: from ESESSHC024.ericsson.se (Unknown_Domain [153.88.183.90]) by sesbmg23.ericsson.net (Symantec Mail Security) with SMTP id DA.B6.22014.209CB295; Mon, 29 May 2017 09:08:50 +0200 (CEST)
Received: from ESESSMB109.ericsson.se ([169.254.9.30]) by ESESSHC024.ericsson.se ([153.88.183.90]) with mapi id 14.03.0339.000; Mon, 29 May 2017 09:08:48 +0200
From: Christer Holmberg <christer.holmberg@ericsson.com>
To: Peter Thatcher <pthatcher@google.com>, "ice@ietf.org" <ice@ietf.org>
Thread-Topic: [Ice] Peter's review of ICEbis - Christer's input on the rest of Peter's comments
Thread-Index: AQHS2EpqeILDrRQvU0WPGJuXgYYlAQ==
Date: Mon, 29 May 2017 07:08:47 +0000
Message-ID: <D551A3B4.1D3D4%christer.holmberg@ericsson.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
user-agent: Microsoft-MacOutlook/14.7.4.170508
x-originating-ip: [153.88.183.18]
Content-Type: multipart/alternative; boundary="_000_D551A3B41D3D4christerholmbergericssoncom_"
MIME-Version: 1.0
X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFmplkeLIzCtJLcpLzFFi42KZGbE9SpfppHakwYrDIhbfLtRaXFv+mtWB yWPBplKPJUt+MgUwRXHZpKTmZJalFunbJXBlPH3YwliwR6Fi/9mZ7A2ML6S6GDk5JARMJD4u m8HexcjFISRwhFFi+7yjjBDOYkaJhZPPsnUxcnCwCVhIdP/TBmkQEfCQ2PxmORuILSyQIPH7 YCc7RDxR4tq+A0wQtp7E4rfrwOIsAqoSkyZ8BLN5BawlJr5oZASxGQXEJL6fWgNWzywgLnHr yXwmiIMEJJbsOc8MYYtKvHz8jxXkBFGgme/2e0KEFSU+vtrHCNGaIPFj3XtGiPGCEidnPmGZ wCg0C8nUWUjKZiEpg4jrSCzY/YkNwtaWWLbwNTOMfebAY6hea4nT954yI6tZwMixilG0OLU4 KTfdyFgvtSgzubg4P08vL7VkEyMwcg5u+a26g/HyG8dDjAIcjEo8vPLrtSOFWBPLiitzDzFK cDArifAKHQMK8aYkVlalFuXHF5XmpBYfYpTmYFES53XcdyFCSCA9sSQ1OzW1ILUIJsvEwSnV wMjaKnW6qIvhWWzjkStrwxqTb0Qem3Hn3OxTKew/8z4/dzFsYG2J3Mk9+67ywnXC0749fvl9 2h71Ps+NFotKPiW7WBnNbvq30/Hk2doLxW1iaiWqexL6XhjsPt3SYat/Prra7mHl249/045t vCAjOdG/5lpARPX3eVNbVLMjLVfVrS9+L3X1YL0SS3FGoqEWc1FxIgB+gzJVmAIAAA==
Archived-At: <https://mailarchive.ietf.org/arch/msg/ice/aqhf10sbQiLBRk6Bifkk0xQZdfE>
Subject: Re: [Ice] Peter's review of ICEbis - Christer's input on the rest of Peter's comments
X-BeenThere: ice@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: "Interactive Connectivity Establishment \(ICE\)" <ice.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/ice>, <mailto:ice-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/ice/>
List-Post: <mailto:ice@ietf.org>
List-Help: <mailto:ice-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ice>, <mailto:ice-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 29 May 2017 07:08:53 -0000

Hi,

> - The spec says it's only defined for one TURN server and one STUN server but then it says what to do when more than one TURN server or STUN server is used.  I'm guessing we should remove the part about one TURN server rather than the other way around.
> - Since we won't have aggressive nomination, do we still need the "three-second rule" for when candidates can be freed?
> - The concept of using a Data Indication for a keepalive seems outdated.  In RTCWEB, consent freshness requires the use of binding requests, not data indications.    Should we change this?
> - What does the phrase "through good box and software security on TURN servers." mean?
> - Do we still need all the UNASF stuff?

I have currently no input on the comments above.

> - Should we keep this "send another candidate exchange when you're Complete" thing?  It looks like it's just there to
> let signaling servers learn something, which I think should be out of scope for this document.  Let a SIP document specify that.

Where is this text?

> - The one example in the doc uses aggressive nomination, which no longer exists.

We need to fix that.

> - Do our "changes from 5245" section need to be updated?

Yes...

Regards,

Christer