From nobody Sat Sep 2 01:00:43 2017 Return-Path: X-Original-To: ice@ietfa.amsl.com Delivered-To: ice@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6458C13476A for ; Sat, 2 Sep 2017 01:00:35 -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 JIS_nUX3nMph for ; Sat, 2 Sep 2017 01:00:33 -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 B9910134769 for ; Sat, 2 Sep 2017 01:00:32 -0700 (PDT) X-AuditID: c1b4fb3a-9e1d49c0000051a3-5a-59aa651e69d7 Received: from ESESSHC001.ericsson.se (Unknown_Domain [153.88.183.21]) by sessmg22.ericsson.net (Symantec Mail Security) with SMTP id 62.9D.20899.E156AA95; Sat, 2 Sep 2017 10:00:30 +0200 (CEST) Received: from ESESSMB102.ericsson.se ([169.254.2.248]) by ESESSHC001.ericsson.se ([153.88.183.21]) with mapi id 14.03.0352.000; Sat, 2 Sep 2017 10:00:06 +0200 From: Christer Holmberg To: Bernard Aboba , Peter Thatcher CC: "ice@ietf.org" Thread-Topic: [Ice] Re-nomination and candidate pair switching in RFC 5245bis - PROPOSAL Thread-Index: AdMGx5vayPULxOekRUuarjHzPdbbFQayu7YAAAG4ewAAAKDJgAAAEW8AAAQIgIAAhTWxQA== Date: Sat, 2 Sep 2017 08:00:06 +0000 Message-ID: <7594FB04B1934943A5C02806D1A2204B5626F889@ESESSMB102.ericsson.se> References: <7594FB04B1934943A5C02806D1A2204B4CC9ED94@ESESSMB109.ericsson.se> <0447726F-82C7-43D8-99AE-5B72F0B55B6C@gmail.com> In-Reply-To: <0447726F-82C7-43D8-99AE-5B72F0B55B6C@gmail.com> 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-Transfer-Encoding: base64 MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFmpgkeLIzCtJLcpLzFFi42KZGbFdVFcudVWkwZonlhYb9v1ntvh2odbi 2vLXrA7MHjtn3WX3WLCp1GPJkp9MAcxRXDYpqTmZZalF+nYJXBnPz+xjLDjEVvGju5e1gXEN WxcjJ4eEgIlEw9seIJuLQ0jgCKPEgy132SGcxYwSW++/Y+1i5OBgE7CQ6P6nDdIgIhAi8W76 IbAws4CixMu9aiBhYYFIiX/rPzGChEUEoiTebsqEqA6TOPmhB2wVi4CKROuaLewgNq+Ar8TM 5UcYITbNYZZoevsFrJdTwFZixqJokBpGATGJ76fWMIHYzALiEreezGeCOFlAYsme88wQtqjE y8f/WCFsJYkV2y8xQlymKbF+lz5Eq6LElO6HUGsFJU7OfMIygVF0FpKpsxA6ZiHpmIWkYwEj yypG0eLU4uLcdCMjvdSizOTi4vw8vbzUkk2MwHg5uOW31Q7Gg88dDzEKcDAq8fDWXl8ZKcSa WFZcmXuIUYKDWUmEt8VtVaQQb0piZVVqUX58UWlOavEhRmkOFiVxXod9FyKEBNITS1KzU1ML UotgskwcnFINjBoPfwTW3lkZunJF54cTvLLG1w2bLOXjHnFyeEput1q1ds7NffN6r4hd/LN/ 94JpF6x/29875yXj8+HreW3Wg5vrfvHpl2+ZzMH58asVd8PffTcmzmS5e+XTNOECP8cmnvr1 4pyb19w61rHlnbXMAr9Vacm3Z//9cfGfkXZFkKSNrH7d0vyDE3YrsRRnJBpqMRcVJwIAaGJ/ 35MCAAA= Archived-At: Subject: Re: [Ice] Re-nomination and candidate pair switching in RFC 5245bis - PROPOSAL 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: Sat, 02 Sep 2017 08:00:35 -0000 SGkNCg0KPiBbQkFdIEl0IHNlZW1zIGxpa2UgdGhlIGRvY3VtZW50IHdvdWxkIGF0IGxlYXN0IG5l ZWQgdG8gdGFsayBhYm91dCBjb25zZW50IHRvIGluY2x1ZGUgYSAibWF5Ii4gQXMgaXQgaXMsIA0K PiBuZWdvdGlhdGluZyAiaWNlMiIgb25seSBtZWFucyB0aGF0IHlvdSdyZSB0YWxraW5nIHRvIGEg c2xpZ2h0bHkgcmVmdXJiaXNoZWQgUkZDIDUyNDUgaW1wbGVtZW50YXRpb24uIA0KPiBUaGF0J3Mg bGlrZSB0aGUgZGlmZmVyZW5jZSBiZXR3ZWVuIGEgbmV3IGNhciB3aXRoIGRyaXZlciBhc3Npc3Qg KGEgbW9kZXJuIFdlYlJUQyBJQ0UgaW1wbGVtZW50YXRpb24gDQo+d2l0aCBUcmlja2xlKSBhbmQg YW4gRWRzZWwgdGhhdCdzIGJlZW4gd2F4ZWQgYW5kIGdpdmVuIGFuIG9pbCBjaGFuZ2UuwqANCg0K VGhlIGlyb255IGlzIHRoYXQgImljZTIiIGlzIHVzZWQgdG8gcHJldmVudCBhIGxlZ2FjeSBJQ0Ug cGVlciBmcm9tIHVzaW5nIGFnZ3Jlc3NpdmUgbm9taW5hdGlvbi4gQnV0LCBpc24ndCBhbGxvd2lu ZyByZS1ub21pbmF0aW9uIG1vcmUgb3IgbGVzcyBicmluZ2luZyAiYWdncmVzc2l2ZSBub21pbmF0 aW9uIiBiYWNrPyA6KQ0KDQpSZWdhcmRzLA0KDQpDaHJpc3Rlcg0K From nobody Sun Sep 3 18:39:19 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 35917132812 for ; Sun, 3 Sep 2017 18:39:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dPsgvbpim0po for ; Sun, 3 Sep 2017 18:39:16 -0700 (PDT) Received: from mail-vk0-x234.google.com (mail-vk0-x234.google.com [IPv6:2607:f8b0:400c:c05::234]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2995413292E for ; Sun, 3 Sep 2017 18:39:16 -0700 (PDT) Received: by mail-vk0-x234.google.com with SMTP id j7so11129043vke.0 for ; Sun, 03 Sep 2017 18:39:16 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=PtmsutKHb9PwrsszBTbSsIiv245LxvQdbXm42rndKR4=; b=vFQiTttcK9xM6XPhFV2nfBZdpusOBqA5d3ZrpUZIPV8SwkGPplBqq23+nxfZS0k58b 5c9J4Cq0h+NjhfDhjAb5k7MVfXXSgl8EbdI7mpDQGZ16PhzJ+csM6vTSINAio2HRmbqH Sfpv7ZWjL9bnNTPLaQlSgr9Q7lJj6zI/O5rFQiTW936uXUx79iWDaQOygjqfYw+xOwyy Qhv0bD4/CrBR01pNIPaFU5JTwfGY7Y572bXhvvD4pi3qPEHXMrEOAXeTPaKxAU3dapvI wFiNezJdIPaH4cjCSvjrL5KXB7q8IydjC9+yJhO1u1ixP0fuI1j25poHqhWtQyPsPMrK hoXA== 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=PtmsutKHb9PwrsszBTbSsIiv245LxvQdbXm42rndKR4=; b=WDziB013IHTcI4eHfZbxj4cG/UZ7WI+jL3pSgrAmN9TvusM2PE42awDs7wksFYm5dZ xbeqEBC4WTf1V3Z2iqfBph8gEzxnRWMRQXZN18/418Vs4OEB+vDTwgn2UpJlxi4DEKe4 HXb7wGNgXdqXlsj3qVJvY0b7PQxYbd2Y8MYdbbrjQtkblKI+K/SiTWX38m/bV/aB3kFW mPfXGD/03aDy3vLhh2dJteCYs1lRuI+ABXfJhXWS+43JdlplecS2foLRDMByP/VzJXtN wpInn5hA5RPieYBk/cTEKSZMoqm3fqj0Xpd/oIw5+Fr9aNpHsn/6DXm27SyQTIKRIAXO UF9Q== X-Gm-Message-State: AHPjjUjUkZr9PvdfFlLyoJtqiZ4Yy4UAFOFBTrjkZgurj9gisMNpjRLs UNfdfgS3PThvfyqXVvvWyUOtwA0gUQ== X-Google-Smtp-Source: ADKCNb5ELFvigWBut/O6mEV83j9bze+jVYKXrZRwnK+ZXASyV9GjADtXFXhcuN+RKBfqKQmPL/bbwlkGfIVyvL8Mlr0= X-Received: by 10.31.16.22 with SMTP id g22mr3242854vki.130.1504489154886; Sun, 03 Sep 2017 18:39:14 -0700 (PDT) MIME-Version: 1.0 Received: by 10.176.74.23 with HTTP; Sun, 3 Sep 2017 18:38:54 -0700 (PDT) In-Reply-To: <7594FB04B1934943A5C02806D1A2204B5626F889@ESESSMB102.ericsson.se> References: <7594FB04B1934943A5C02806D1A2204B4CC9ED94@ESESSMB109.ericsson.se> <0447726F-82C7-43D8-99AE-5B72F0B55B6C@gmail.com> <7594FB04B1934943A5C02806D1A2204B5626F889@ESESSMB102.ericsson.se> From: Bernard Aboba Date: Sun, 3 Sep 2017 21:38:54 -0400 Message-ID: To: Christer Holmberg Cc: Peter Thatcher , "ice@ietf.org" , Emil Ivov Content-Type: multipart/alternative; boundary="001a11436218a540e40558532d59" Archived-At: Subject: Re: [Ice] Re-nomination and candidate pair switching in RFC 5245bis - PROPOSAL 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, 04 Sep 2017 01:39:18 -0000 --001a11436218a540e40558532d59 Content-Type: text/plain; charset="UTF-8" Christer said: "The irony is that "ice2" is used to prevent a legacy ICE peer from using aggressive nomination. But, isn't allowing re-nomination more or less bringing "aggressive nomination" back? :)" [BA] I think we need to carefully examine the implications of "passive aggressive" as well as the meaning of "nomination" in RFC 5245bis and make sure that the meaning (and its implications) of these notions are articulated. *Prior* to nomination, I believe that RFC 5245bis allows both the controlling and controlled sides to select validated pairs to send media on, and permits *either side* to switch between validated pairs. I don't think this is said explicitly anywhere, but it is true, isn't it? Wouldn't that also imply that the return path doesn't have to match the sending path? Again, not said anywhere explicitly, but it seems like it would be the case. That would also seem to imply that prior to nomination we have the flexibility for implementations to support mujlti-path RTP? (e.g. sending different RTP flows using different candidate pairs). Again, not said explicitly anywhere. Then somehow, *after* nomination, many of these magical properties vanish, for reasons that I find hard to justify. Again, the reasoning behind this is not explained in RFC 5245bis, nor are all the magical powers restored by the re-nomination document. The problem I think arises from a full articulation of the meaning of "nomination" in RFC 5245bis. For example, if we are removing the concept of resource release from nomination and basing it on consent instead, we need to explain the meaning of "nomination" encapsulated in the negotiation of "ice2". Which of the following statements are implied by "nomination"? 1. "I want to use this pair (and only this pair) to send" 2. "I want to receive using this pair (and only this pair)" 3. "I have selected a set of validated pairs for sending and will request consent for them" 4. "I have granted consent for a set of pairs suitable for receiving" 5. "The controlled side can release candidates that are neither receiving or sending consent requests"? Right now, it is not clear to me which of these statements are implied by RFC 5245bis (or which ones are implied by the renomination document). On Sat, Sep 2, 2017 at 4:00 AM, Christer Holmberg < christer.holmberg@ericsson.com> wrote: > Hi > > > [BA] It seems like the document would at least need to talk about > consent to include a "may". As it is, > > negotiating "ice2" only means that you're talking to a slightly > refurbished RFC 5245 implementation. > > That's like the difference between a new car with driver assist (a > modern WebRTC ICE implementation > >with Trickle) and an Edsel that's been waxed and given an oil change. > > The irony is that "ice2" is used to prevent a legacy ICE peer from using > aggressive nomination. But, isn't allowing re-nomination more or less > bringing "aggressive nomination" back? :) > > Regards, > > Christer > --001a11436218a540e40558532d59 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Christer said:=C2=A0

"The irony is that "ice2" is used to p= revent a legacy ICE peer from using aggressive nomination. But, isn't a= llowing re-nomination more or less bringing "aggressive nomination&quo= t; back? :)"
[BA] I think we need to= carefully examine the implications of "passive aggressive" as we= ll as the meaning of "nomination" in RFC 5245bis and make sure th= at the meaning (and its implications) of these notions are articulated.

*Prior*=C2=A0to nomination, I believe that RFC 5= 245bis allows both the controlling and controlled sides to select validated= pairs to send media on, and permits *either side* to switch between valida= ted pairs.=C2=A0 I don't think this is said explicitly anywhere, but it= is true, isn't it?
<= br>
Wouldn't that als= o imply that the return path doesn't have to match the sending path?=C2= =A0 Again, not said anywhere explicitly, but it seems like it would be the = case.=C2=A0

That would also seem to imply tha= t prior to nomination we have the flexibility for implementations to suppor= t mujlti-path RTP? (e.g. sending different RTP flows using different candid= ate pairs). Again, not said explicitly anywhere.=C2=A0

Then somehow, *after* nomination, many of these magical prop= erties vanish, for reasons that I find hard to justify.=C2=A0 =C2=A0Again, = the reasoning behind this is not explained in RFC 5245bis, nor are all the = magical powers restored by the re-nomination document.=C2=A0

The problem I think arises from a full articulation o= f the meaning of "nomination" in RFC 5245bis.=C2=A0
<= div>
For example, if we are removing the concept of resource re= lease from nomination and basing it on consent instead, we need to explain = the meaning of "nomination" encapsulated in the negotiation of &q= uot;ice2".=C2=A0 Which of the following statements are implied by &quo= t;nomination"?=C2=A0

1.=C2=A0 "I wa= nt to use this pair (and only this pair) to send"
2. "I want to receive using this pair (a= nd only this pair)"
= 3. "I have selected a set of validated pairs for sending and will requ= est consent for them"
4. "I have granted consent for a set of pairs suitable for receiving= "
5.=C2=A0"The controlled side can release candida= tes that are neither receiving or sending consent requests"?=C2=A0=C2= =A0

Right now, it is not clear to me which of= these statements are implied by RFC 5245bis (or which ones are implied by = the renomination document).=C2=A0


<= br>
On Sat, Sep 2, 2017 at 4:00 AM, Christer Holm= berg <christer.holmberg@ericsson.com> wrote:
Hi

> [BA] It seems like the document would at least need to talk about cons= ent to include a "may". As it is,
> negotiating "ice2" only means that you're talking to a s= lightly refurbished RFC 5245 implementation.
> That's like the difference between a new car with driver assist (a= modern WebRTC ICE implementation
>with Trickle) and an Edsel that's been waxed and given an oil chang= e.=C2=A0

The irony is that "ice2" is used to prevent a legacy ICE p= eer from using aggressive nomination. But, isn't allowing re-nomination= more or less bringing "aggressive nomination" back? :)

Regards,

Christer

--001a11436218a540e40558532d59-- From nobody Sun Sep 3 22:44:33 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 41F5E1243F6 for ; Sun, 3 Sep 2017 22:44:31 -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 Oi4kN0hkV_vd for ; Sun, 3 Sep 2017 22:44:29 -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 C124B1286C7 for ; Sun, 3 Sep 2017 22:44:28 -0700 (PDT) X-AuditID: c1b4fb3a-617ff700000051a3-c1-59ace83a2a60 Received: from ESESSHC005.ericsson.se (Unknown_Domain [153.88.183.33]) by sessmg22.ericsson.net (Symantec Mail Security) with SMTP id 53.CA.20899.A38ECA95; Mon, 4 Sep 2017 07:44:26 +0200 (CEST) Received: from ESESSMB109.ericsson.se ([169.254.9.194]) by ESESSHC005.ericsson.se ([153.88.183.33]) with mapi id 14.03.0352.000; Mon, 4 Sep 2017 07:44:26 +0200 From: Christer Holmberg To: Bernard Aboba CC: Peter Thatcher , "ice@ietf.org" , "Emil Ivov" Thread-Topic: [Ice] Re-nomination and candidate pair switching in RFC 5245bis - PROPOSAL Thread-Index: AdMGx5vayPULxOekRUuarjHzPdbbFQayu7YAAAG4ewAAAKDJgAAAEW8AAAQIgIAAhTWxQABTJ90AAAuoNvA= Date: Mon, 4 Sep 2017 05:44:25 +0000 Message-ID: <7594FB04B1934943A5C02806D1A2204B56289F26@ESESSMB109.ericsson.se> References: <7594FB04B1934943A5C02806D1A2204B4CC9ED94@ESESSMB109.ericsson.se> <0447726F-82C7-43D8-99AE-5B72F0B55B6C@gmail.com> <7594FB04B1934943A5C02806D1A2204B5626F889@ESESSMB102.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: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFupikeLIzCtJLcpLzFFi42KZGbFdUdfqxZpIg0ObLC027PvPbLFm5wQW i28Xai2uLX/N6sDisXPWXXaPBZtKPZYs+cnk8f9NYABLFJdNSmpOZllqkb5dAlfGy2crmAtO mFac7NvC0sA4w6SLkZNDQsBEYs+2NcxdjFwcQgJHGCX+Lm5ngnAWM0rMunQGKMPBwSZgIdH9 TxukQURAW6Lv2z4mEJtZIFNixZwVrCC2sECkxL/1nxhBykUEoiTebsqEMJMkbj2VAqlgEVCR mP3rIyOIzSvgK7Hq2FGoTctZJGYu6GQBSXAKBErsXHCPHcRmFBCT+H5qDdQqcYlbT+YzQdws ILFkz3lmCFtU4uXjf6wQtpLEiu2XwE5gFtCUWL9LH6JVUWJK90N2iL2CEidnPmGZwCg6C8nU WQgds5B0zELSsYCRZRWjaHFqcXFuupGRXmpRZnJxcX6eXl5qySZGYAwd3PLbagfjweeOhxgF OBiVeHgLb6+JFGJNLCuuzD3EKMHBrCTCK3EPKMSbklhZlVqUH19UmpNafIhRmoNFSZzXYd+F CCGB9MSS1OzU1ILUIpgsEwenVAPjVKNJHx2ylNIlZHo/f3n0Ni3+1qJJCeXnHyyr/f1Y8cnn /hSvn6uknveafdz0YamE4EfnrdprLzLsmqBwoOP+/egl30/wMjml/zxxd7l0jNtVucYbWiUN hndsFUJk7635os+ZabrZ4Wp/oo11wfo5psvtzaeZrAnfHp/d+dnefuKLMl8N02BTJZbijERD Leai4kQA5blx+50CAAA= Archived-At: Subject: Re: [Ice] Re-nomination and candidate pair switching in RFC 5245bis - PROPOSAL 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, 04 Sep 2017 05:44:31 -0000 SGksDQoNCj4iVGhlIGlyb255IGlzIHRoYXQgImljZTIiIGlzIHVzZWQgdG8gcHJldmVudCBhIGxl Z2FjeSBJQ0UgcGVlciBmcm9tIHVzaW5nIGFnZ3Jlc3NpdmUgbm9taW5hdGlvbi4gQnV0LCBpc24n dCBhbGxvd2luZyByZS1ub21pbmF0aW9uIG1vcmUgb3IgbGVzcyBicmluZ2luZyAiYWdncmVzc2l2 ZSA+bm9taW5hdGlvbiIgYmFjaz8gOikiDQo+DQo+W0JBXSBJIHRoaW5rIHdlIG5lZWQgdG8gY2Fy ZWZ1bGx5IGV4YW1pbmUgdGhlIGltcGxpY2F0aW9ucyBvZiAicGFzc2l2ZSBhZ2dyZXNzaXZlIiBh cyB3ZWxsIGFzIHRoZSBtZWFuaW5nIG9mICJub21pbmF0aW9uIiBpbiBSRkMgNTI0NWJpcyBhbmQg bWFrZSBzdXJlIHRoYXQgdGhlIG1lYW5pbmcgPihhbmQgaXRzIGltcGxpY2F0aW9ucykgb2YgdGhl c2Ugbm90aW9ucyBhcmUgYXJ0aWN1bGF0ZWQuDQo+DQo+KlByaW9yKsKgdG8gbm9taW5hdGlvbiwg SSBiZWxpZXZlIHRoYXQgUkZDIDUyNDViaXMgYWxsb3dzIGJvdGggdGhlIGNvbnRyb2xsaW5nIGFu ZCBjb250cm9sbGVkIHNpZGVzIHRvIHNlbGVjdCB2YWxpZGF0ZWQgcGFpcnMgdG8gc2VuZCBtZWRp YSBvbiwgYW5kIHBlcm1pdHMgKmVpdGhlciBzaWRlKiB0byA+c3dpdGNoIGJldHdlZW4gdmFsaWRh dGVkIHBhaXJzLsKgIEkgZG9uJ3QgdGhpbmsgdGhpcyBpcyBzYWlkIGV4cGxpY2l0bHkgYW55d2hl cmUsIGJ1dCBpdCBpcyB0cnVlLCBpc24ndCBpdD8NCg0KUGVyaGFwcyBpdCBjb3VsZCBiZSBtb3Jl IGNsZWFyLCBidXQgdGhlcmUgaXMgdGV4dDoNCg0KU2VjdGlvbiAxMS4xLjEgc2F5czoNCg0KICAg IkFnZW50cyBhbHdheXMgc2VuZCBtZWRpYSB1c2luZyBhIGNhbmRpZGF0ZSBwYWlyLCB1c2luZyBj YW5kaWRhdGUNCiAgIHBhaXJzIGluIHRoZSBWQUxJRCBMSVNULiAgT25jZSBhIGNhbmRpZGF0ZSBw YWlyIGhhcyBiZWVuIHNlbGVjdGVkDQogICBvbmx5IHRoYXQgY2FuZGlkYXRlIHBhaXIgKHJlZmVy cmVkIHRvIGFzIHNlbGVjdGVkIHBhaXIpIGlzIHVzZWQgZm9yDQogICBzZW5kaW5nIG1lZGlhLiIN Cg0KPldvdWxkbid0IHRoYXQgYWxzbyBpbXBseSB0aGF0IHRoZSByZXR1cm4gcGF0aCBkb2Vzbid0 IGhhdmUgdG8gbWF0Y2ggdGhlIHNlbmRpbmcgcGF0aD/CoCBBZ2Fpbiwgbm90IHNhaWQgYW55d2hl cmUgZXhwbGljaXRseSwgYnV0IGl0IHNlZW1zIGxpa2UgaXQgd291bGQgYmUgdGhlIGNhc2UuwqAN Cg0KVGhlcmUgaXMgbm8gdGV4dCBtYW5kYXRpbmcgdGhlIHBhdGhzIHRvIG1hdGNoIHByaW9yIHRv IG5vbWluYXRpb24uDQoNCj5UaGF0IHdvdWxkIGFsc28gc2VlbSB0byBpbXBseSB0aGF0IHByaW9y IHRvIG5vbWluYXRpb24gd2UgaGF2ZSB0aGUgZmxleGliaWxpdHkgZm9yIGltcGxlbWVudGF0aW9u cyB0byBzdXBwb3J0IG11amx0aS1wYXRoIFJUUD8gKGUuZy4gc2VuZGluZyBkaWZmZXJlbnQgUlRQ IGZsb3dzIHVzaW5nID5kaWZmZXJlbnQgY2FuZGlkYXRlIHBhaXJzKS4gQWdhaW4sIG5vdCBzYWlk IGV4cGxpY2l0bHkgYW55d2hlcmUuwqANCg0KV2hpbGUgSSBndWVzcyBpdCB3b3VsZCB0ZWNobmlj YWxseSBiZSBwb3NzaWJsZSwgSSBkb24ndCB0aGluayB0aGF0J3MgdGhlIGludGVudGlvbi4gDQoN CkV2ZXJ5IG5vdyBhbmQgdGhlbiB0aGVyZSBoYXZlIGJlZW4gZGlzY3Vzc2lvbiBhYm91dCBuZXZl ciBub21pbmF0aW5nLCBhbGxvd2luZyB1c2FnZSBvZiBtdWx0aXBsZSB2YWxpZCBwYWlycy4gQnV0 LCBpZiB1c2luZyBtdWx0aXBsZSB2YWxpZCBwYWlycyBpcyBzb21ldGhpbmcgcGVvcGxlIHdhbnQg dG8gZG8gSSB0aGluayB3ZSBzaG91bGQgcHJvcGVybHkgc3BlY2lmeSBob3cgaXQgaXMgZG9uZSwg c28gdGhhdCBwZW9wbGUgZG9uJ3QgaGF2ZSB0byBkbyBpdCB1c2luZyBoYWNrcy4NCg0KPiBUaGVu IHNvbWVob3csICphZnRlciogbm9taW5hdGlvbiwgbWFueSBvZiB0aGVzZSBtYWdpY2FsIHByb3Bl cnRpZXMgdmFuaXNoLCBmb3IgcmVhc29ucyB0aGF0IEkgZmluZCBoYXJkIHRvIGp1c3RpZnkuDQo+ DQo+IEFnYWluLCB0aGUgcmVhc29uaW5nIGJlaGluZCB0aGlzIGlzIG5vdCBleHBsYWluZWQgaW4g UkZDIDUyNDViaXMuLi4NCg0KVGhlIHJlYXNvbiBpcyB0aGF0IGVudGl0aWVzIGNhbiByZWxlYXNl IHJlc291cmNlcy4NCg0KPiwgbm9yIGFyZSBhbGwgdGhlIG1hZ2ljYWwgcG93ZXJzIHJlc3RvcmVk IGJ5IHRoZSByZS1ub21pbmF0aW9uIGRvY3VtZW50Lg0KDQpSZS1ub21pbmF0aW9uIGRvZXMgbm90 IG1lYW4gKEFGQUlVKSB0aGF0IHlvdSBzdWRkZW5seSBjYW4gc3RhcnQgc3dpdGNoaW5nIGJldHdl ZW4gdmFsaWQgcGFpcnMgLSBpdCBtZWFucyB0aGF0IHlvdSBjaGFuZ2UgdGhlIG9uZSB2YWxpZCBw YWlyIHRoYXQgeW91IGFyZSBnb2luZyB0byB1c2UgZm9yIG1lZGlhLg0KDQo+VGhlIHByb2JsZW0g SSB0aGluayBhcmlzZXMgZnJvbSBhIGZ1bGwgYXJ0aWN1bGF0aW9uIG9mIHRoZSBtZWFuaW5nIG9m ICJub21pbmF0aW9uIiBpbiBSRkMgNTI0NWJpcy7CoA0KPg0KPkZvciBleGFtcGxlLCBpZiB3ZSBh cmUgcmVtb3ZpbmcgdGhlIGNvbmNlcHQgb2YgcmVzb3VyY2UgcmVsZWFzZSBmcm9tIG5vbWluYXRp b24gYW5kIGJhc2luZyBpdCBvbiBjb25zZW50IGluc3RlYWQsIA0KDQpJIHRoaW5rIGl0J3Mgc3Rp bGwgZ29vZCB0byBleHBsaWNpdGx5IHNheSB0aGF0IGVuZHBvaW50cyBhcmUgYWxsb3dlZCB0byBy ZWxlYXNlIHJlc291cmNlcy4NCg0KQWxzbywgYWZ0ZXIgc29tZSB0aGlua2luZywgSSBhbSBub3Qg c3VyZSBhIHJlLW5vbWluYXRpb24gcmVhbGx5IHdvdWxkIG5lZWQgY29uc2VudC4gSWYgdGhlIHBl ZXIgcmVzcG9uZHMgdG8gYSBub21pbmF0aW9uIFNUVU4gcmVxdWVzdCBpdCBtZWFucyBpdCBhY2Nl cHRzIHRoZSAocmUtKW5vbWluYXRpb24uIA0KDQo+d2UgbmVlZCB0byBleHBsYWluIHRoZSBtZWFu aW5nIG9mICJub21pbmF0aW9uIiBlbmNhcHN1bGF0ZWQgaW4gdGhlIG5lZ290aWF0aW9uIG9mICJp Y2UyIi7CoCBXaGljaCBvZiB0aGUgZm9sbG93aW5nIHN0YXRlbWVudHMgYXJlIGltcGxpZWQgYnkg Im5vbWluYXRpb24iP8KgDQo+DQo+MS7CoCAiSSB3YW50IHRvIHVzZSB0aGlzIHBhaXIgKGFuZCBv bmx5IHRoaXMgcGFpcikgdG8gc2VuZCINCj4yLiAiSSB3YW50IHRvIHJlY2VpdmUgdXNpbmcgdGhp cyBwYWlyIChhbmQgb25seSB0aGlzIHBhaXIpIg0KPjMuICJJIGhhdmUgc2VsZWN0ZWQgYSBzZXQg b2YgdmFsaWRhdGVkIHBhaXJzIGZvciBzZW5kaW5nIGFuZCB3aWxsIHJlcXVlc3QgY29uc2VudCBm b3IgdGhlbSINCj40LiAiSSBoYXZlIGdyYW50ZWQgY29uc2VudCBmb3IgYSBzZXQgb2YgcGFpcnMg c3VpdGFibGUgZm9yIHJlY2VpdmluZyINCj41LsKgIlRoZSBjb250cm9sbGVkIHNpZGUgY2FuIHJl bGVhc2UgY2FuZGlkYXRlcyB0aGF0IGFyZSBuZWl0aGVyIHJlY2VpdmluZyBvciBzZW5kaW5nIGNv bnNlbnQgcmVxdWVzdHMiP8KgwqANCj4NCj5SaWdodCBub3csIGl0IGlzIG5vdCBjbGVhciB0byBt ZSB3aGljaCBvZiB0aGVzZSBzdGF0ZW1lbnRzIGFyZSBpbXBsaWVkIGJ5IFJGQyA1MjQ1YmlzIChv ciB3aGljaCBvbmVzIGFyZSBpbXBsaWVkIGJ5IHRoZSByZW5vbWluYXRpb24gZG9jdW1lbnQpLsKg DQoNCkknbGwgbGV0IG90aGVycyBzcGVhayBvbiBiZWhhbGYgb2YgdGhlIHJlLW5vbWluYXRpb24g ZG9jdW1lbnQuIEluIG15IHVuZGVyc3RhbmRpbmcsIDUyNDViaXMgY3VycmVudGx5IGltcGxpZXMs IG9uY2Ugbm9taW5hdGlvbiBvY2N1cnM6IDEsIDIqIGFuZCA1Lg0KDQoqIFNlY3Rpb24gMTEuMiBj b250YWlucyB0aGUgZm9sbG93aW5nIHRleHQ6DQoNCiAgICJFdmVuIHRob3VnaCBJQ0UgYWdlbnRz IGFyZSBvbmx5IGFsbG93ZWQgdG8gc2VuZCBtZWRpYSB1c2luZyB2YWxpZA0KICAgY2FuZGlkYXRl IHBhaXJzIChhbmQsIG9uY2UgYSBjYW5kaWRhdGUgcGFpciBoYXMgYmVlbiBzZWxlY3RlZCwgb25s eQ0KICAgb24gdGhlIHNlbGVjdGVkIHBhaXIpIElDRSBpbXBsZW1lbnRhdGlvbnMgU0hPVUxEIGJ5 IGRlZmF1bHQgYmUNCiAgIHByZXBhcmVkIHRvIHJlY2VpdmUgbWVkaWEgb24gYW55IG9mIHRoZSBj YW5kaWRhdGVzIHByb3ZpZGVkIGluIHRoZQ0KICAgbW9zdCByZWNlbnQgY2FuZGlkYXRlIGV4Y2hh bmdlIHdpdGggdGhlIHBlZXIuIg0KDQpJIHRoaW5rIHRoYXQgdGV4dCBpcyBjb25mdXNpbmcuIEFm dGVyIGEgcGFpciBoYXMgYmVlbiBzZWxlY3RlZCwgYW4gZW5kcG9pbnQgc2hvdWxkIG5vdCBoYXZl IGJlIHByZXBhcmVkIHRvIHJlY2VpdmUgbWVkaWEgb24gYW55IG9mIHRoZSBjYW5kaWRpYXRlcy4g DQoNClJlZ2FyZHMsDQoNCkNocmlzdGVyDQoNCg0KDQoNCk9uIFNhdCwgU2VwIDIsIDIwMTcgYXQg NDowMCBBTSwgQ2hyaXN0ZXIgSG9sbWJlcmcgPGNocmlzdGVyLmhvbG1iZXJnQGVyaWNzc29uLmNv bT4gd3JvdGU6DQpIaQ0KDQo+IFtCQV0gSXQgc2VlbXMgbGlrZSB0aGUgZG9jdW1lbnQgd291bGQg YXQgbGVhc3QgbmVlZCB0byB0YWxrIGFib3V0IGNvbnNlbnQgdG8gaW5jbHVkZSBhICJtYXkiLiBB cyBpdCBpcywNCj4gbmVnb3RpYXRpbmcgImljZTIiIG9ubHkgbWVhbnMgdGhhdCB5b3UncmUgdGFs a2luZyB0byBhIHNsaWdodGx5IHJlZnVyYmlzaGVkIFJGQyA1MjQ1IGltcGxlbWVudGF0aW9uLg0K PiBUaGF0J3MgbGlrZSB0aGUgZGlmZmVyZW5jZSBiZXR3ZWVuIGEgbmV3IGNhciB3aXRoIGRyaXZl ciBhc3Npc3QgKGEgbW9kZXJuIFdlYlJUQyBJQ0UgaW1wbGVtZW50YXRpb24NCj53aXRoIFRyaWNr bGUpIGFuZCBhbiBFZHNlbCB0aGF0J3MgYmVlbiB3YXhlZCBhbmQgZ2l2ZW4gYW4gb2lsIGNoYW5n ZS7CoA0KDQpUaGUgaXJvbnkgaXMgdGhhdCAiaWNlMiIgaXMgdXNlZCB0byBwcmV2ZW50IGEgbGVn YWN5IElDRSBwZWVyIGZyb20gdXNpbmcgYWdncmVzc2l2ZSBub21pbmF0aW9uLiBCdXQsIGlzbid0 IGFsbG93aW5nIHJlLW5vbWluYXRpb24gbW9yZSBvciBsZXNzIGJyaW5naW5nICJhZ2dyZXNzaXZl IG5vbWluYXRpb24iIGJhY2s/IDopDQoNClJlZ2FyZHMsDQoNCkNocmlzdGVyDQoNCg== From nobody Mon Sep 4 23:26:32 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 23B23132376 for ; Mon, 4 Sep 2017 23:26:31 -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 tcO36pHKN_ia for ; Mon, 4 Sep 2017 23:26:29 -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 23A6A120727 for ; Mon, 4 Sep 2017 23:26:28 -0700 (PDT) X-AuditID: c1b4fb25-94fff70000005333-05-59ae4393f2df Received: from ESESSHC009.ericsson.se (Unknown_Domain [153.88.183.45]) by sesbmg23.ericsson.net (Symantec Mail Security) with SMTP id 00.97.21299.3934EA95; Tue, 5 Sep 2017 08:26:27 +0200 (CEST) Received: from ESESSMB109.ericsson.se ([169.254.9.194]) by ESESSHC009.ericsson.se ([153.88.183.45]) with mapi id 14.03.0352.000; Tue, 5 Sep 2017 08:26:26 +0200 From: Christer Holmberg To: Christer Holmberg , Bernard Aboba CC: Emil Ivov , Peter Thatcher , "ice@ietf.org" Thread-Topic: [Ice] Re-nomination and candidate pair switching in RFC 5245bis - PROPOSAL Thread-Index: AdMGx5vayPULxOekRUuarjHzPdbbFQayu7YAAAG4ewAAAKDJgAAAEW8AAAQIgIAAhTWxQABTJ90AAAuoNvAANyDJAA== Date: Tue, 5 Sep 2017 06:26:26 +0000 Message-ID: References: <7594FB04B1934943A5C02806D1A2204B4CC9ED94@ESESSMB109.ericsson.se> <0447726F-82C7-43D8-99AE-5B72F0B55B6C@gmail.com> <7594FB04B1934943A5C02806D1A2204B5626F889@ESESSMB102.ericsson.se> <7594FB04B1934943A5C02806D1A2204B56289F26@ESESSMB109.ericsson.se> In-Reply-To: <7594FB04B1934943A5C02806D1A2204B56289F26@ESESSMB109.ericsson.se> 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.20] Content-Type: text/plain; charset="us-ascii" Content-ID: <691969BCA5F62C42A996965BCA0A7ABA@ericsson.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFlrHIsWRmVeSWpSXmKPExsUyM2K7ru5k53WRBos65Cw27PvPbLFm5wQW i28Xai2uLX/N6sDisXPWXXaPBZtKPZYs+cnk8f9NYABLFJdNSmpOZllqkb5dAlfGj2fv2Qqm 6Vd8P+3bwDhTrYuRk0NCwETiysQz7F2MXBxCAkcYJQ693cYM4SxmlFg69QdjFyMHB5uAhUT3 P22QBhGBRIlrcyawgdjMAukSby4cYQKxhQUiJT7Of8gKUi4iECXxdlMmRHmWxPn5E9lBbBYB FYmDcxeCTeQVsJaY+DUXYtNrFok1c26ygNRwCvhJTNn1gRHEZhQQk/h+ag0TxCpxiVtP5jNB 3CwgsWTPeWYIW1Ti5eN/YGtFBfQk3u33hAgrSlydvhyqVUdiwe5PUBdbS2y48Rkqri2xbOFr sDG8AoISJ2c+YZnAKD4LybZZSNpnIWmfhaR9FpL2BYysqxhFi1OLk3LTjYz1Uosyk4uL8/P0 8lJLNjECY/Hglt+qOxgvv3E8xCjAwajEwzvBZl2kEGtiWXFl7iFGCQ5mJRHebBOgEG9KYmVV alF+fFFpTmrxIUZpDhYlcV7HfRcihATSE0tSs1NTC1KLYLJMHJxSDYx9eX9bJhu+226s8+5o 8CdVd1mdWJHNC8+JniqfwOMoprt4zSWmrWty28V12cocVkemi1SvP2HsPD3K/eW/mBAuJu6U BoVjph9ulDasW+bx92eHwPU35z92nOUzVtXQX943afPjItnLVRMtc2dWGq6/d9vFatoxzpmv hJ7fyg3g2LBxw7edW58osRRnJBpqMRcVJwIAXzWUU8ECAAA= Archived-At: Subject: Re: [Ice] Re-nomination and candidate pair switching in RFC 5245bis - PROPOSAL 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, 05 Sep 2017 06:26:31 -0000 Peter (and others interested), IF you want some change to the current behaviour, where a re-nomination is NOT allowed, you need to participate in the discussion NOW. We are moving towards WGLC, and we should close the window for technical changes (non-bug fixing). If I understood Bernard correctly, he was asking for having multiple SIMULTANEOUS nominations, in order to do RTP multipath stuff etc. I personally think that is outside the scope of 5245bis. I think the question is whether we should allow re-nominations of single candidate pairs. Regards, Christer On 04/09/17 08:44, "Ice on behalf of Christer Holmberg" wrote: >Hi, > >>"The irony is that "ice2" is used to prevent a legacy ICE peer from >>using aggressive nomination. But, isn't allowing re-nomination more or >>less bringing "aggressive >nomination" back? :)" >> >>[BA] I think we need to carefully examine the implications of "passive >>aggressive" as well as the meaning of "nomination" in RFC 5245bis and >>make sure that the meaning >(and its implications) of these notions are >>articulated. >> >>*Prior* to nomination, I believe that RFC 5245bis allows both the >>controlling and controlled sides to select validated pairs to send media >>on, and permits *either side* to >switch between validated pairs. I >>don't think this is said explicitly anywhere, but it is true, isn't it? > >Perhaps it could be more clear, but there is text: > >Section 11.1.1 says: > > "Agents always send media using a candidate pair, using candidate > pairs in the VALID LIST. Once a candidate pair has been selected > only that candidate pair (referred to as selected pair) is used for > sending media." > >>Wouldn't that also imply that the return path doesn't have to match the >>sending path? Again, not said anywhere explicitly, but it seems like it >>would be the case. > >There is no text mandating the paths to match prior to nomination. > >>That would also seem to imply that prior to nomination we have the >>flexibility for implementations to support mujlti-path RTP? (e.g. >>sending different RTP flows using >different candidate pairs). Again, >>not said explicitly anywhere. > >While I guess it would technically be possible, I don't think that's the >intention.=20 > >Every now and then there have been discussion about never nominating, >allowing usage of multiple valid pairs. But, if using multiple valid >pairs is something people want to do I think we should properly specify >how it is done, so that people don't have to do it using hacks. > >> Then somehow, *after* nomination, many of these magical properties >>vanish, for reasons that I find hard to justify. >> >> Again, the reasoning behind this is not explained in RFC 5245bis... > >The reason is that entities can release resources. > >>, nor are all the magical powers restored by the re-nomination document. > >Re-nomination does not mean (AFAIU) that you suddenly can start switching >between valid pairs - it means that you change the one valid pair that >you are going to use for media. > >>The problem I think arises from a full articulation of the meaning of >>"nomination" in RFC 5245bis. >> >>For example, if we are removing the concept of resource release from >>nomination and basing it on consent instead, > >I think it's still good to explicitly say that endpoints are allowed to >release resources. > >Also, after some thinking, I am not sure a re-nomination really would >need consent. If the peer responds to a nomination STUN request it means >it accepts the (re-)nomination. > >>we need to explain the meaning of "nomination" encapsulated in the >>negotiation of "ice2". Which of the following statements are implied by >>"nomination"?=20 >> >>1. "I want to use this pair (and only this pair) to send" >>2. "I want to receive using this pair (and only this pair)" >>3. "I have selected a set of validated pairs for sending and will >>request consent for them" >>4. "I have granted consent for a set of pairs suitable for receiving" >>5. "The controlled side can release candidates that are neither >>receiving or sending consent requests"? >> >>Right now, it is not clear to me which of these statements are implied >>by RFC 5245bis (or which ones are implied by the renomination document). > >I'll let others speak on behalf of the re-nomination document. In my >understanding, 5245bis currently implies, once nomination occurs: 1, 2* >and 5. > >* Section 11.2 contains the following text: > > "Even though ICE agents are only allowed to send media using valid > candidate pairs (and, once a candidate pair has been selected, only > on the selected pair) ICE implementations SHOULD by default be > prepared to receive media on any of the candidates provided in the > most recent candidate exchange with the peer." > >I think that text is confusing. After a pair has been selected, an >endpoint should not have be prepared to receive media on any of the >candidiates.=20 > >Regards, > >Christer > > > > >On Sat, Sep 2, 2017 at 4:00 AM, Christer Holmberg > wrote: >Hi > >> [BA] It seems like the document would at least need to talk about >>consent to include a "may". As it is, >> negotiating "ice2" only means that you're talking to a slightly >>refurbished RFC 5245 implementation. >> That's like the difference between a new car with driver assist (a >>modern WebRTC ICE implementation >>with Trickle) and an Edsel that's been waxed and given an oil change. > >The irony is that "ice2" is used to prevent a legacy ICE peer from using >aggressive nomination. But, isn't allowing re-nomination more or less >bringing "aggressive nomination" back? :) > >Regards, > >Christer > >_______________________________________________ >Ice mailing list >Ice@ietf.org >https://www.ietf.org/mailman/listinfo/ice From nobody Tue Sep 5 00:55:26 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 86C8A132644 for ; Tue, 5 Sep 2017 00:55:25 -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 G0MIRRZv4VEb for ; Tue, 5 Sep 2017 00:55:24 -0700 (PDT) Received: from sesbmg22.ericsson.net (sesbmg22.ericsson.net [193.180.251.48]) (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 E78E41326DF for ; Tue, 5 Sep 2017 00:55:23 -0700 (PDT) X-AuditID: c1b4fb30-96f7a9c000005897-a5-59ae5869f51b Received: from ESESSHC023.ericsson.se (Unknown_Domain [153.88.183.87]) by sesbmg22.ericsson.net (Symantec Mail Security) with SMTP id B3.73.22679.9685EA95; Tue, 5 Sep 2017 09:55:21 +0200 (CEST) Received: from ESESSMB109.ericsson.se ([169.254.9.194]) by ESESSHC023.ericsson.se ([153.88.183.87]) with mapi id 14.03.0352.000; Tue, 5 Sep 2017 09:54:39 +0200 From: Christer Holmberg To: "ice@ietf.org" Thread-Topic: 5245bis: Clarification on receiving media Thread-Index: AQHTJhw5nxtCpphJMU+/wjHo8GYd4w== Date: Tue, 5 Sep 2017 07:54:39 +0000 Message-ID: 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.19] Content-Type: multipart/alternative; boundary="_000_D5D4340B20FDCchristerholmbergericssoncom_" MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFvrJLMWRmVeSWpSXmKPExsUyM2J7uG5mxLpIg6/rDCy+Xah1YPRYsuQn UwBjFJdNSmpOZllqkb5dAlfG73cX2Ar+SVSsavjD0sC4U7SLkZNDQsBE4mz/DcYuRi4OIYEj jBLn2zuZIJzFjBLr2+8wdzFycLAJWEh0/9MGaRARUJSY2fKMGcQWFjCS+L3jLDtIiYiAucSh vcIQpp7Ew7eBIBUsAioSn3dOZAexeQWsJQ68esIGYjMKiEl8P7WGCcRmFhCXuPVkPhPEOQIS S/acZ4awRSVePv7HCjJSFGjku/2eEGFFifanDYwQrQkSe2b8YIMYLyhxcuYTlgmMQrOQTJ2F pGwWkjKIuI7Egt2f2CBsbYllC18zw9hnDjwG6uUAsq0lfn42RVaygJFjFaNocWpxUm66kZFe alFmcnFxfp5eXmrJJkZghBzc8ttgB+PL546HGAU4GJV4eOXD10UKsSaWFVfmHmKU4GBWEuHt CAMK8aYkVlalFuXHF5XmpBYfYpTmYFES53XcdyFCSCA9sSQ1OzW1ILUIJsvEwSnVwFi7//45 Rq8H7DtKP6j9059TdPWL3ZXo/Qvf3JgjYPXtrYSYy4vcmRPaGG/wqlQ7teeUfOconNXq43uS YVvJxcar+U+ezI7olF1TVDrh0pvdOQp8q3ufBCrW6ym+nq789s4SvUe5rs1iR2cmFcdPv3te +VDjhgu33n2Ij7+95sVWU441x67wW0QqsRRnJBpqMRcVJwIAzQcMP4wCAAA= Archived-At: Subject: [Ice] 5245bis: Clarification on receiving media 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, 05 Sep 2017 07:55:25 -0000 --_000_D5D4340B20FDCchristerholmbergericssoncom_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi, Section 11.2 of 5245bis contains the following text: "Even though ICE agents are only allowed to send media using valid candidate pairs (and, once a candidate pair has been selected, only on the selected pair) ICE implementations SHOULD by default be prepared to receive media on any of the candidates provided in the most recent candidate exchange with the peer." I think we need to clarify that being prepared to receive media on any cand= idate also only applies until a candidate pair has been selected. Regards, Christer --_000_D5D4340B20FDCchristerholmbergericssoncom_ Content-Type: text/html; charset="us-ascii" Content-ID: <7589149CB80C6F40B58AADB1C019994D@ericsson.com> Content-Transfer-Encoding: quoted-printable
Hi,

Section 11.2 of 5245bis contains the following text:

   "Even though ICE agents are o=
nly allowed to send media using valid
   candidate pairs (and, once a candidate pair has been selected, only
   on the selected pair) ICE implementations SHOULD by default be
   prepared to receive media on any of the candidates provided in the
   most recent candidate exchange with the peer." 
I think we nee=
d to clarify that being prepared to receive media on any candidate als=
o only applies until a candidate pair has been selected.=

Regards,
Christer
--_000_D5D4340B20FDCchristerholmbergericssoncom_-- From nobody Tue Sep 5 05:04: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 5AF2513293F for ; Tue, 5 Sep 2017 05:04:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.699 X-Spam-Level: X-Spam-Status: No, score=-2.699 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wnKBDf8nbfOC for ; Tue, 5 Sep 2017 05:04:06 -0700 (PDT) Received: from mail-yw0-x22b.google.com (mail-yw0-x22b.google.com [IPv6:2607:f8b0:4002:c05::22b]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D01C2132939 for ; Tue, 5 Sep 2017 05:04:05 -0700 (PDT) Received: by mail-yw0-x22b.google.com with SMTP id k78so12029320ywe.1 for ; Tue, 05 Sep 2017 05:04:05 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=lWQrYfvcLapZsKSf4Sxnxf3XTiYIZRTmotzgnL4ArmE=; b=djaSmdY71nxPHrVcO5O486b51RxV8SFfvQ/dCbqLD/YLVuE2HuCbpCe0N6Hpzo1Ei7 VE8CqR2AhLJksuMarF4mFzJ3T5LY4c67h5grwTBVpXnT5l0fEFWvftEv7zqoom7aw4li SxaJvq7SuQaXe8Z4daLeAfe4INbOgvz0LeGDV8Bh9IAuqpIi9IVissEZvAOL9a5TLEE1 98DCNsLcCcqP2mgnUDOjQynXr/qKthZ2DSMVplHD5Jnq6aVXVXTtmaGqVcYc7IlkG+bW X/UaXC3zESp6ft1cTw9YbGWE1w8Rk53X0etp0sfyDVzk3KqDny3zM84RvRM6C8ngNqL2 0u7w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=lWQrYfvcLapZsKSf4Sxnxf3XTiYIZRTmotzgnL4ArmE=; b=CAtkmXaxKYI87El1FkSP0V2QkWYpQU/nhN8YTK3sYb2CYr/JcFurNTKwqkhdL/A++o kd47uV53isuYxLaHpmM9t5+0uwHUkmFVctQIBRB1J8mS15mWm1hB6SYsl9PeEDDY0tWz 22uyued855MCrSLYcfIjuPw1TAHoYHOTfQdpjwqgeUpbXb21/VOexjSR94OwLcLOqdlq FR+aEW9WRMDfB2MAPF/YXrwHEekjlCf/16ch0lpE92ZrYuSPiT4LQEOQHDGLgg+7u4pM 8sg2tH0ZaE6zSVJqfc5YSbgusgphWAS745o1Z9acjhwehVrp6EPWnZF5YZjrOmTN8YG8 2zyA== X-Gm-Message-State: AHPjjUgfpsSJBFVQOkPJ/Qs+qwTfaWebNz0g4buCq7dPrVyoNsvdhiD2 7tD1eLKpEIHYWo+esmI= X-Google-Smtp-Source: ADKCNb6kjbQXPDXN5a61wRtxz3v8o/Tm6sOioPDnsKqlF7oJ6bmi9PBK/PFxRcob16ht5KwQwBXiLw== X-Received: by 10.37.1.67 with SMTP id 64mr3227605ybb.4.1504613044634; Tue, 05 Sep 2017 05:04:04 -0700 (PDT) Received: from [10.244.223.102] (mobile-166-172-185-184.mycingular.net. [166.172.185.184]) by smtp.gmail.com with ESMTPSA id p125sm124891ywb.29.2017.09.05.05.04.03 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 05 Sep 2017 05:04:03 -0700 (PDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (1.0) From: Bernard Aboba X-Mailer: iPhone Mail (14G60) In-Reply-To: Date: Tue, 5 Sep 2017 08:04:02 -0400 Cc: Emil Ivov , Peter Thatcher , "ice@ietf.org" Content-Transfer-Encoding: quoted-printable Message-Id: References: <7594FB04B1934943A5C02806D1A2204B4CC9ED94@ESESSMB109.ericsson.se> <0447726F-82C7-43D8-99AE-5B72F0B55B6C@gmail.com> <7594FB04B1934943A5C02806D1A2204B5626F889@ESESSMB102.ericsson.se> <7594FB04B1934943A5C02806D1A2204B56289F26@ESESSMB109.ericsson.se> To: Christer Holmberg Archived-At: Subject: Re: [Ice] Re-nomination and candidate pair switching in RFC 5245bis - PROPOSAL 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, 05 Sep 2017 12:04:07 -0000 On Sep 5, 2017, at 2:26 AM, Christer Holmberg wrote: >=20 >=20 > Peter (and others interested), >=20 > IF you want some change to the current behaviour, where a re-nomination is= > NOT allowed, you need to participate in the discussion NOW. We are moving > towards WGLC, and we should close the window for technical changes > (non-bug fixing). >=20 > If I understood Bernard correctly, he was asking for having multiple > SIMULTANEOUS nominations, in order to do RTP multipath stuff etc. I > personally think that is outside the scope of 5245bis. I think the > question is whether we should allow re-nominations of single candidate > pairs. [BA] Actually, I was just trying to understand what the current draft allows= and why. As it stands, the draft appears to support multi-path RTP before n= omination, but not after.=20= From nobody Tue Sep 5 05:26:39 2017 Return-Path: X-Original-To: ice@ietfa.amsl.com Delivered-To: ice@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 015BF13294B for ; Tue, 5 Sep 2017 05:26:38 -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 v8mS--29m8F5 for ; Tue, 5 Sep 2017 05:26:36 -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 4E5BD132939 for ; Tue, 5 Sep 2017 05:26:36 -0700 (PDT) X-AuditID: c1b4fb25-d31059c000005333-5b-59ae97f9030d Received: from ESESSHC023.ericsson.se (Unknown_Domain [153.88.183.87]) by sesbmg23.ericsson.net (Symantec Mail Security) with SMTP id 8F.58.21299.9F79EA95; Tue, 5 Sep 2017 14:26:34 +0200 (CEST) Received: from ESESSMB109.ericsson.se ([169.254.9.194]) by ESESSHC023.ericsson.se ([153.88.183.87]) with mapi id 14.03.0352.000; Tue, 5 Sep 2017 14:26:33 +0200 From: Christer Holmberg To: Bernard Aboba CC: Emil Ivov , Peter Thatcher , "ice@ietf.org" Thread-Topic: [Ice] Re-nomination and candidate pair switching in RFC 5245bis - PROPOSAL Thread-Index: AdMGx5vayPULxOekRUuarjHzPdbbFQayu7YAAAG4ewAAAKDJgAAAEW8AAAQIgIAAhTWxQABTJ90AAAuoNvAANyDJAAAFVrwAAAc9HAA= Date: Tue, 5 Sep 2017 12:26:33 +0000 Message-ID: References: <7594FB04B1934943A5C02806D1A2204B4CC9ED94@ESESSMB109.ericsson.se> <0447726F-82C7-43D8-99AE-5B72F0B55B6C@gmail.com> <7594FB04B1934943A5C02806D1A2204B5626F889@ESESSMB102.ericsson.se> <7594FB04B1934943A5C02806D1A2204B56289F26@ESESSMB109.ericsson.se> In-Reply-To: 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.19] Content-Type: text/plain; charset="us-ascii" Content-ID: <068386B30F415E4EBE59C540DCF6465B@ericsson.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFlrPIsWRmVeSWpSXmKPExsUyM2J7uO6v6esiDb5PYbLYsO8/s8WanRNY LL5dqLW4tvw1qwOLx85Zd9k9Fmwq9Viy5CeTx/83gQEsUVw2Kak5mWWpRfp2CVwZzacuMhb8 YK/4vaCHsYFxFVsXIyeHhICJxPpVR1m6GLk4hASOMEoc/HgOylnMKLHzy2kgh4ODTcBCovuf NkiDiIC2RN+3fUwgNrNAusSbC0fAbGGBSImP8x+ygpSLCERJvN2UCVFeJrH81lawXSwCKhJL bt0AK+cVsJb4d/o5I8SqC6wSty9OAevlFLCVmLy4CKSGUUBM4vupNVCrxCVuPZnPBHGzgMSS PeeZIWxRiZeP/4G1igroSbzb7wkRVpRof9rACNGqI7Fg9yc2CNta4tni/SwQtrbEsoWvmSHO EZQ4OfMJywRG8VlIts1C0j4LSfssJO2zkLQvYGRdxShanFqclJtuZKyXWpSZXFycn6eXl1qy iREYjQe3/FbdwXj5jeMhRgEORiUe3h8l6yKFWBPLiitzDzFKcDArifAemAwU4k1JrKxKLcqP LyrNSS0+xCjNwaIkzuu470KEkEB6YklqdmpqQWoRTJaJg1OqgbHSICqV+ZO48FrNE6Gmhx5r l3zr9DINyf9TvneLps3u5FOTS0PUDYoaraS2Zz9WCb217wX/k78O1Qffpou1+8b+PML265RF 3fvZB+a55n3SPNwy53RCZiWL9K2GJ0zlKn5OE0/XH7izS+TMH8UfuhaM9xyWGFzqsgnQDNiV wVSrYHC2yWGGghJLcUaioRZzUXEiAM+pOKnCAgAA Archived-At: Subject: Re: [Ice] Re-nomination and candidate pair switching in RFC 5245bis - PROPOSAL 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, 05 Sep 2017 12:26:38 -0000 Hi, >>Peter (and others interested), >>=20 >> IF you want some change to the current behaviour, where a re-nomination >>is >> NOT allowed, you need to participate in the discussion NOW. We are >>moving >> towards WGLC, and we should close the window for technical changes >> (non-bug fixing). >>=20 >> If I understood Bernard correctly, he was asking for having multiple >> SIMULTANEOUS nominations, in order to do RTP multipath stuff etc. I >> personally think that is outside the scope of 5245bis. I think the >> question is whether we should allow re-nominations of single candidate >> pairs. > >[BA] Actually, I was just trying to understand what the current draft >allows and why. As it stands, the draft appears to support multi-path RTP >before nomination, but not after. Currently, the draft allows switching between pairs before nomination, yes. As for WHY, I assume it is to allow media transport before the ICE procedures have finished. Regards, Christer >=20 From nobody Tue Sep 5 16:49:09 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 78D85132198 for ; Tue, 5 Sep 2017 16:49:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=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=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 SWpKH0610ZtV for ; Tue, 5 Sep 2017 16:49:05 -0700 (PDT) Received: from mail-qt0-x235.google.com (mail-qt0-x235.google.com [IPv6:2607:f8b0:400d:c0d::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 90B4512426E for ; Tue, 5 Sep 2017 16:49:05 -0700 (PDT) Received: by mail-qt0-x235.google.com with SMTP id m35so16150648qte.1 for ; Tue, 05 Sep 2017 16:49:05 -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=VtubS2C/82Lbz7jDAUKBLItA9L+r00drZRrnCu55qso=; b=fImqeA8WKMpe0mRk+hhgnErprqdbSOyPpWxp2BOJ5OLZlMwN++yb2mkA4ZIixUW7I0 MXbmg9IQGkxJjHPWN3JTWsaighU4OaXva+pQTjuffM8GtGkpGcjDrbuARVRYW6JJ0TjZ kQIlDaGVeA2Oe6BaP2VkTZ/iPde64meHq6uCh1MJFAYsATzJjo/X5D43SAW5/4HU84OL LSNCsWos4S4/junPHD+SP1JJjySyisGvkmnLS2wL506IjQvC6Doxy5uCaYn7cv+Tj9YP IOLoaYhoZiMhNRk4QOjFNbaHdvHOAGT6tpqjB2dJTIRMPRLAmffS6qMKXyaFSj0hHvGi LsHQ== 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=VtubS2C/82Lbz7jDAUKBLItA9L+r00drZRrnCu55qso=; b=L2LMZr6in8Meht7dWnj52V/AzVvSiMrugAAV4+OwY2QHvPPShJ24X04qCKixqYLqKE tSNwauKzZZ+qx6MmZp6xEcUAy4DQcd5XBsyQV/WIJq2tgjfvhMCKWWElAJ91nbmrG/tm VduTWz+IrvpYErUXnVxQokfN/ly8C45Z4NLJKcR21WPsbvdUHmJEjO6nBVgrzerjQD3p h2xdlhv6JqPASsmuJmDPKF+/b35HvuVOqSGbM0MUgwg0mvcNJOqo5RZ3j1zSv+OzZXJ7 CAnosRc2FOK2oIYDgRBXGKVONbha8lXJovkl0WNeRJW1Z0YlSz7blZ2ZhSZvjMV2QG/d Xk9w== X-Gm-Message-State: AHPjjUgc4f6xhKlLgoBWmiEF6U8b+yF/JCdwXxvjK9hNMqiFBJyiLkau fOdMDZUhPa6c7CS+uUgIz4ji1VZQ7KWx X-Google-Smtp-Source: AOwi7QDJ7TGQxYxIg2L38wPQk66e7eDdQwHV54Ub0FYTv89blXKeboTlPpiRnT9Qc+EVht7xjtTaYumb+h3LVdvFRI8= X-Received: by 10.200.39.185 with SMTP id w54mr1104251qtw.234.1504655344580; Tue, 05 Sep 2017 16:49:04 -0700 (PDT) MIME-Version: 1.0 References: <7594FB04B1934943A5C02806D1A2204B4CC9ED94@ESESSMB109.ericsson.se> <0447726F-82C7-43D8-99AE-5B72F0B55B6C@gmail.com> <7594FB04B1934943A5C02806D1A2204B5626F889@ESESSMB102.ericsson.se> <7594FB04B1934943A5C02806D1A2204B56289F26@ESESSMB109.ericsson.se> In-Reply-To: From: Peter Thatcher Date: Tue, 05 Sep 2017 23:48:53 +0000 Message-ID: To: Christer Holmberg , Bernard Aboba Cc: Emil Ivov , "ice@ietf.org" Content-Type: multipart/alternative; boundary="001a1135a2de532f31055879df0d" Archived-At: Subject: Re: [Ice] Re-nomination and candidate pair switching in RFC 5245bis - PROPOSAL 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, 05 Sep 2017 23:49:07 -0000 --001a1135a2de532f31055879df0d Content-Type: text/plain; charset="UTF-8" Thinking about this some more: I think it's fine if 5245bis says that you can't renominate. We could say "an ICE option or extension may allow renomination", but we could just put that in a new ICE option or extension (like https://tools.ietf.org/html/draft-thatcher-ice-renomination-01). Then it's clear that without the extension, you can't, but with the extension you can. On Tue, Sep 5, 2017 at 5:26 AM Christer Holmberg < christer.holmberg@ericsson.com> wrote: > Hi, > > >>Peter (and others interested), > >> > >> IF you want some change to the current behaviour, where a re-nomination > >>is > >> NOT allowed, you need to participate in the discussion NOW. We are > >>moving > >> towards WGLC, and we should close the window for technical changes > >> (non-bug fixing). > >> > >> If I understood Bernard correctly, he was asking for having multiple > >> SIMULTANEOUS nominations, in order to do RTP multipath stuff etc. I > >> personally think that is outside the scope of 5245bis. I think the > >> question is whether we should allow re-nominations of single candidate > >> pairs. > > > >[BA] Actually, I was just trying to understand what the current draft > >allows and why. As it stands, the draft appears to support multi-path RTP > >before nomination, but not after. > > Currently, the draft allows switching between pairs before nomination, > yes. As for WHY, I assume it is to allow media transport before the ICE > procedures have finished. > > Regards, > > Christer > > > > > > > > > --001a1135a2de532f31055879df0d Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Thinking about this some more: I think it's fine if 52= 45bis says that you can't renominate.=C2=A0 We could say "an ICE o= ption or extension may allow renomination", but we could just put that= in a new ICE option or extension (like=C2=A0https://tools.ietf.org/html/dr= aft-thatcher-ice-renomination-01).=C2=A0 Then it's clear that witho= ut the extension, you can't, but with the extension you can.



On= Tue, Sep 5, 2017 at 5:26 AM Christer Holmberg <christer.holmberg@ericsson.com> wrote:
=
Hi,

>>Peter (and others interested),
>>
>> IF you want some change to the current behaviour, where a re-nomin= ation
>>is
>> NOT allowed, you need to participate in the discussion NOW. We are=
>>moving
>> towards WGLC, and we should close the window for technical changes=
>> (non-bug fixing).
>>
>> If I understood Bernard correctly, he was asking for having multip= le
>> SIMULTANEOUS nominations, in order to do RTP multipath stuff etc. = I
>> personally think that is outside the scope of 5245bis. I think the=
>> question is whether we should allow re-nominations of single candi= date
>> pairs.
>
>[BA] Actually, I was just trying to understand what the current draft >allows and why. As it stands, the draft appears to support multi-path R= TP
>before nomination, but not after.

Currently, the draft allows switching between pairs before nomination,
yes. As for WHY, I assume it is to allow media transport before the ICE
procedures have finished.

Regards,

Christer





>

--001a1135a2de532f31055879df0d-- From nobody Tue Sep 5 16:50: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 B3ADA13219A for ; Tue, 5 Sep 2017 16:50:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.699 X-Spam-Level: X-Spam-Status: No, score=-2.699 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, 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 REuSYpCIbuuv for ; Tue, 5 Sep 2017 16:50:37 -0700 (PDT) Received: from mail-qk0-x236.google.com (mail-qk0-x236.google.com [IPv6:2607:f8b0:400d:c09::236]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6E47412426E for ; Tue, 5 Sep 2017 16:50:37 -0700 (PDT) Received: by mail-qk0-x236.google.com with SMTP id a128so15745575qkc.5 for ; Tue, 05 Sep 2017 16:50:37 -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=D0TsjMjkAY0vObdniIWX+6HaQmUFGs1HWqioJOdj73o=; b=nnxq8NInDBhhIhSWDhcaaeIfgzVLaRFxdYCnDjNA54s3nJbWMR335qD2W0qylL7NdY PGpAsdDaM+XILx7hnlJYJ4CaC55nXf45uckyjfHmhJUpKqgTKjJedE5hpMHwuSK012ZB rMLHA+8PoyQZHCQpX5MbnAown7IJ4/MvG7slqPULqRVJJKwxe3eah2Xhn3CiCGQz2MKw syDuixzrHdp/uV9ZlEykSZ/HiaQvlbqC9POty8HgKdnSAH2BLmYqjPKvgYecHW82AEMg 28l3u4hFnhKv3RLRxa+38/DV1iu9P3yIpE5N7GwEQ/tr3KvujTyha6OkriclewIQpIiv bP0w== 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=D0TsjMjkAY0vObdniIWX+6HaQmUFGs1HWqioJOdj73o=; b=Hdkv6EKXeuUP2OrV86FdEI7x2JrjkXSoXKufrXDntDnkKOqJRnrVW4XVuPzZG71LJF 1npapjhEd7CP6JlR5HCnkzPck4x/4Xna3FFa5CyzgwMNr3w+NS0Zo6XNKBSCTcZ1dITH S2S2qxAoiFw12fvaBfIjA712juMPWN86EgpwVdD8v0VDcdFxQA4hlDzSwuKPibosQXgj UZM/eJToPW9aoff2GlmgnatS7L5uBOilxEj3wVSC3aftmv1xIDACi4EuYVcP934GzdMY KVeizFh+7EpPyGD6AzYaHMspnCrvuGQGgmpTriRv2AxZvoapx2ceaw/Ib/3U2O/QsBUp eGsA== X-Gm-Message-State: AHPjjUhainmPnsG2UUXBWMOlS0AjpE05ki3XTJYuKqAdS2brh73Hfptn cNcFjcM9rUm+my2bfpOJUnwtZpK+WfhoFBU= X-Google-Smtp-Source: ADKCNb6/22awvbTA5gvZYi4kS3zGU7bhonawbF0b3qL2bFoh+qLJwLhCwxmP5FPf3NRoPgMTzRLqDazlOZMeeLAYy2E= X-Received: by 10.55.54.13 with SMTP id d13mr1022062qka.218.1504655436442; Tue, 05 Sep 2017 16:50:36 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Peter Thatcher Date: Tue, 05 Sep 2017 23:50:25 +0000 Message-ID: To: Christer Holmberg , "ice@ietf.org" Content-Type: multipart/alternative; boundary="001a1147150ecd01e6055879e460" Archived-At: Subject: Re: [Ice] 5245bis: Clarification on receiving media 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, 05 Sep 2017 23:50:41 -0000 --001a1147150ecd01e6055879e460 Content-Type: text/plain; charset="UTF-8" I think that's implied by the fact that resources can be release upon nomination. Plus it's only "SHOULD". But if I'd be OK with adding a phrase to make it more explicit. On Tue, Sep 5, 2017 at 12:55 AM Christer Holmberg < christer.holmberg@ericsson.com> wrote: > Hi, > > Section 11.2 of 5245bis contains the following text: > > "Even though ICE agents are only allowed to send media using valid > candidate pairs (and, once a candidate pair has been selected, only > on the selected pair) ICE implementations SHOULD by default be > prepared to receive media on any of the candidates provided in the > most recent candidate exchange with the peer." > > I think we need to clarify that being prepared to receive media on any candidate also only applies until a candidate pair has been selected. > > Regards, > > Christer > > _______________________________________________ > Ice mailing list > Ice@ietf.org > https://www.ietf.org/mailman/listinfo/ice > --001a1147150ecd01e6055879e460 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
I think that's implied by the fact that resources can = be release upon nomination.=C2=A0 Plus it's only "SHOULD".=C2= =A0 But if I'd be OK with adding a phrase to make it more explicit.
On Tue, Sep 5, 2017 at 12= :55 AM Christer Holmberg <christer.holmberg@ericsson.com> wrote:
Hi,

Section 11.2 of 5245bis contains the following text:

=
   "Even though ICE agents are only allowed to send media using valid
   candidate pairs (and, once a candidate pair has been selected, only
   on the selected pair) ICE implementations SHOULD by default be
   prepared to receive media on any of the candidates provided in the
   most recent candidate exchange with the peer." 
I think w=
e need to clarify that being prepared to receive media on any=C2=A0candidat=
e also only applies until a=C2=A0candidate pair has been selected.
Regards,<=
/font>
Christer
_______________________________________________
Ice mailing list
Ice@ietf.org
https://www.ietf.org/mailman/listinfo/ice
--001a1147150ecd01e6055879e460-- From nobody Tue Sep 5 16:51:59 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 2AD9212426E for ; Tue, 5 Sep 2017 16:51:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=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=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 9UP199TOPujz for ; Tue, 5 Sep 2017 16:51:56 -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 40523132199 for ; Tue, 5 Sep 2017 16:51:56 -0700 (PDT) Received: by mail-qt0-x230.google.com with SMTP id b52so11610790qtb.3 for ; Tue, 05 Sep 2017 16:51:56 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:references:from:date:message-id:subject:to; bh=nzkvwEK3g6ayWPCHk8C0ljEUEmjKBAVC4CI3u/nWc4Q=; b=FHec+alLaOSKjNC6Q8KPulFriQ2KspGbcCLd8xvOXvDQfW+3voHnvsR0Ivr1IZhVpr fU+iPwrDJaMldx2qmH34sK3krjs5bGW9wtH7HlOiBL5+Z0C1U+aSXYXf1lex0OONx3QO q2cxVG7lIx7xRuDKANybOo97VeAM7UXnVBUpqx8dIrTZ8fx/fGbrKQnK7TJyVv1zYdON w5OEv7pRmKJl5q5hR5iD29B6tmtgyBG5v5Yuo3IjGxzCuNraIvEruK6cRVF5m6mROfLD 6v85o5EXkVi3vfj2Y4JFRtZh+dmGNEEhIZaRVl1PbYg9Hmcbbsw420PuGrhxgPRKyMe8 RtpQ== 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:from:date:message-id :subject:to; bh=nzkvwEK3g6ayWPCHk8C0ljEUEmjKBAVC4CI3u/nWc4Q=; b=dPQCZV5pbtYwLzNO5tIus+pOGOAVS8kHbXDfxNZwjcgBmkOl9YW45a4SCzXCps6G46 eJheESgEfw/M415lTWJiAaqNqN68iWnNcRMCk095fJ9kokPDp+muQMK84g/FsapobBD9 BqSiM1iQqtA4AQc0bdh71A516jwCoIlrEk8hMyShmOFcmLozd+mvRyvoU1s3SHGuBWjv wxerSFOqvSb2x3rrDeMtfVQc2GYgId440ZLtEKbQvo9Vv8ogmqzZQinT9avF6iIq3g/R +VdYOzIYnCRUXwUN591iZV1gsPTElTPrS7FhvgC9nHgJT+iKg/MbY5WjH6MK1JMarb0h suBQ== X-Gm-Message-State: AHPjjUjPbX0zXJWJDm/ztHgZ6M3Pjzq5YZRW81q+KoGp3Y2G/3lEciMD 1iBjTYWChh3R0C1IpcWZVmIJzJo/EEZP X-Google-Smtp-Source: AOwi7QBJe4ffQ0t8+PhXo03TJnvUj2nIKS4u9TldpuaTJBmdQAQzlZF1LqEzjWRtOjvZ86PNMgbruyIXPawU+9XS1HE= X-Received: by 10.237.45.7 with SMTP id h7mr1150713qtd.158.1504655515320; Tue, 05 Sep 2017 16:51:55 -0700 (PDT) MIME-Version: 1.0 References: From: Peter Thatcher Date: Tue, 05 Sep 2017 23:51:44 +0000 Message-ID: To: Christer Holmberg , "ice@ietf.org" Content-Type: multipart/alternative; boundary="94eb2c124a40807068055879e93c" Archived-At: Subject: Re: [Ice] 5245bis: Clarification on receiving media 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, 05 Sep 2017 23:51:58 -0000 --94eb2c124a40807068055879e93c Content-Type: text/plain; charset="UTF-8" Actually, it gets a little complicated, because if the controlling side should probably still be prepared to receive media until the binding response from the nomination, to make sure the controlled side knows to stop sending before the controlling side stops receiving. On Tue, Sep 5, 2017 at 4:50 PM Peter Thatcher wrote: > I think that's implied by the fact that resources can be release upon > nomination. Plus it's only "SHOULD". But if I'd be OK with adding a > phrase to make it more explicit. > > On Tue, Sep 5, 2017 at 12:55 AM Christer Holmberg < > christer.holmberg@ericsson.com> wrote: > >> Hi, >> >> Section 11.2 of 5245bis contains the following text: >> >> "Even though ICE agents are only allowed to send media using valid >> candidate pairs (and, once a candidate pair has been selected, only >> on the selected pair) ICE implementations SHOULD by default be >> prepared to receive media on any of the candidates provided in the >> most recent candidate exchange with the peer." >> >> I think we need to clarify that being prepared to receive media on any candidate also only applies until a candidate pair has been selected. >> >> Regards, >> >> Christer >> >> _______________________________________________ >> Ice mailing list >> Ice@ietf.org >> https://www.ietf.org/mailman/listinfo/ice >> > --94eb2c124a40807068055879e93c Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Actually, it gets a little complicated, because if the con= trolling side should probably still be prepared to receive media until the = binding response from the nomination, to make sure the controlled side know= s to stop sending before the controlling side stops receiving.

On Tue, Sep 5, 2017 at 4:50 PM Pet= er Thatcher <pthatcher@google.co= m> wrote:
I= think that's implied by the fact that resources can be release upon no= mination.=C2=A0 Plus it's only "SHOULD".=C2=A0 But if I'd= be OK with adding a phrase to make it more explicit.

On Tue, Sep 5, 2017 at 12:55 AM Christer = Holmberg <christer.hol= mberg@ericsson.com> wrote:
Hi,

Section 11.2 of 5245bis contains the following text:

=
   "Even though ICE agents are only allowed to send media using valid
   candidate pairs (and, once a candidate pair has been selected, only
   on the selected pair) ICE implementations SHOULD by default be
   prepared to receive media on any of the candidates provided in the
   most recent candidate exchange with the peer." 
I think w=
e need to clarify that being prepared to receive media on any=C2=A0candidat=
e also only applies until a=C2=A0candidate pair has been selected.
Regards,<=
/font>
Christer
_______________________________________________
Ice mailing list
Ice@ietf.org
https://www.ietf.org/mailman/listinfo/ice
--94eb2c124a40807068055879e93c-- From nobody Tue Sep 5 17:52: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 C32F213214D for ; Tue, 5 Sep 2017 17:52:07 -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=m7VOIOBA; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=Oc6eXhGy Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PO5QDiFfmFdy for ; Tue, 5 Sep 2017 17:52:05 -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 A07DD132E3C for ; Tue, 5 Sep 2017 17:52:05 -0700 (PDT) Received: from compute2.internal (compute2.nyi.internal [10.202.2.42]) by mailout.nyi.internal (Postfix) with ESMTP id CD195217B1; Tue, 5 Sep 2017 20:52:04 -0400 (EDT) Received: from frontend1 ([10.202.2.160]) by compute2.internal (MEProxy); Tue, 05 Sep 2017 20:52:04 -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=mdWP2A+HHyKPPmWxiK +YV3Rt4gVI2YkM982gt/CXABE=; b=m7VOIOBArlKPRO9fcqRsn0aAS6PsEbCJ/i Sh0QK5mNfEuVctO91hVTx86Ypw71FLAcUrHzT8X9t+d62fILISln6wTyWM5QeOfB AvFSN7DE2ovfm5DecqYoniondHOCUw3Qg1iWIgF4CP8gIb4qu3ABu4Y5wAy9mtoP B9whqRhoNpL07xjplWmpGdB58N2nAPtB6IvtB8Q3WUosDk9msbguTXENvCYS2AMq wl4G/s/EQ3C0AlCjhxT8uwC0RLDoc0P2Qx6im34chq1zCmvKVteL0acZIFWLE+Xh NUG8jS5iCdcJyDcaKWfMvMUq5ZmWgePkg01sMiBLw6ulMqhbzJhA== 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=mdWP2A+HHyKPPmWxiK+YV3Rt4gVI2YkM982gt/CXABE=; b=Oc6eXhGy lWLcXlMNQkunxYzV4xds544439Oi6pImrX0FYXeo3oNZUtAzTamPUQGnbCG1JpTR uhwXmkTGC98CHsyl0RWD2RbLIwIm4nnHlvq2ws2moC1KflnOuojMH2x1FwN2E8F3 rVlWgs/QouKaR2RxP7WgDZ0XbjLELfm/w7QeMbJDZm1btbNCztgMAUlj4WekpFUM LGqwpz57wPOenoaQpplNGlVC2zlnDEvIJCP9FkPqJjtcA7LXqi11RXVqHjTS0Xcw INXPNXh53oPodJThLJ26o2KjvL/f2XBRPKFD4FJDngsghQAyJ3UFAs0aMME9fpcB 9V9H51gnMGnoyQ== X-ME-Sender: X-Sasl-enc: jMgpZ7IeiKjzENLHx010cRYAth5jzaGyVtJC5v4CKP9U 1504659124 Received: from aither.local (unknown [76.25.4.24]) by mail.messagingengine.com (Postfix) with ESMTPA id E26557E6DB; Tue, 5 Sep 2017 20:52:03 -0400 (EDT) To: Peter Thatcher , Christer Holmberg , Bernard Aboba Cc: Emil Ivov , "ice@ietf.org" References: <7594FB04B1934943A5C02806D1A2204B4CC9ED94@ESESSMB109.ericsson.se> <0447726F-82C7-43D8-99AE-5B72F0B55B6C@gmail.com> <7594FB04B1934943A5C02806D1A2204B5626F889@ESESSMB102.ericsson.se> <7594FB04B1934943A5C02806D1A2204B56289F26@ESESSMB109.ericsson.se> From: Peter Saint-Andre Message-ID: <8eef2b6e-f412-681f-adee-e5e5aea16071@stpeter.im> Date: Tue, 5 Sep 2017 18:52:02 -0600 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.12; rv:52.0) Gecko/20100101 Thunderbird/52.3.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 8bit Archived-At: Subject: Re: [Ice] Re-nomination and candidate pair switching in RFC 5245bis - PROPOSAL 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, 06 Sep 2017 00:52:08 -0000 On 9/5/17 5:48 PM, Peter Thatcher wrote: > Thinking about this some more: I think it's fine if 5245bis says that > you can't renominate.  We could say "an ICE option or extension may > allow renomination", but we could just put that in a new ICE option or > extension > (like https://tools.ietf.org/html/draft-thatcher-ice-renomination-01).  > Then it's clear that without the extension, you can't, but with the > extension you can. +1 Peter From nobody Tue Sep 5 17:54:57 2017 Return-Path: X-Original-To: ice@ietfa.amsl.com Delivered-To: ice@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C243113214D for ; Tue, 5 Sep 2017 17:54:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=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 (1024-bit key) header.d=mozilla.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 Xz0DlD2ODsO8 for ; Tue, 5 Sep 2017 17:54:53 -0700 (PDT) Received: from mail-pg0-x22d.google.com (mail-pg0-x22d.google.com [IPv6:2607:f8b0:400e:c05::22d]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 173A31252BA for ; Tue, 5 Sep 2017 17:54:53 -0700 (PDT) Received: by mail-pg0-x22d.google.com with SMTP id 63so3318801pgc.1 for ; Tue, 05 Sep 2017 17:54:52 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mozilla.com; s=google; h=from:message-id:mime-version:subject:date:in-reply-to:cc:to :references; bh=qON/Qg9M7UEWtqRJE2NOLpEpw01g+YS+xYYY2cV7mik=; b=TWWlaYyO/rm17FGEXIvyICY5t5blCfcUg/ZL3IF9Wwgq9E2788NuKL1uTA/9jM/vYv nV6eutvnRGQJTgmuLOekmmmmu7oZap9xO8V7lGplr55AiUNcvkySBBP4jZ0tQARlxgHv B9ydm9Gbg6DDJdkWpWJt+TL/WrXG6Xl/BuWJY= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:message-id:mime-version:subject:date :in-reply-to:cc:to:references; bh=qON/Qg9M7UEWtqRJE2NOLpEpw01g+YS+xYYY2cV7mik=; b=E3pooLBA05mUfzHEbwEZvMKw5BopHxU73llYl4VksQ0J/WEhd7ZOcTGLU3eoVkI70k xiS1g3e7sFxuL6fi79kx3bz+CE6NY3pvAhPlPr6WRU0ilOgR1qnlYr1/1/w5zewqvk5B qGCyFYP6paevE44JJoIh7StUmhleiCvdspO0PAlbSPDoHLrsS73EMvL7ttGb3ZaebgUU zrvt06RWoAl6p05Ld4bHTHvNn8zkGR+qpNhVxvV43Xi5xlYkZ9H3Bu+wRoDYpkVAd2lr ngMZfpS85ZlLcFP9hOQ6g1xP7fNkFdJ52V7NpQCsW8bfwDLQOrvXt0EvO/K9Ne/ryNsv wMfg== X-Gm-Message-State: AHPjjUjxM1X4ZGUUBhJTLN7sdr6EfXvFBbytsSP6a8M1MKeFii0ikVBi BDwz3AZNcr95bc4l X-Google-Smtp-Source: ADKCNb5/ydWQK14pH6mm1lYq3sbHXM8uVaHIr3Ox1tiyGcIIFcX6SO37BPfQ4Y/wmH0a5pUmCDJ++g== X-Received: by 10.98.71.153 with SMTP id p25mr5557819pfi.84.1504659292551; Tue, 05 Sep 2017 17:54:52 -0700 (PDT) Received: from [192.168.2.22] (c-107-3-154-7.hsd1.ca.comcast.net. [107.3.154.7]) by smtp.gmail.com with ESMTPSA id m24sm233746pfg.31.2017.09.05.17.54.50 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 05 Sep 2017 17:54:51 -0700 (PDT) From: Nils Ohlmeier Message-Id: Content-Type: multipart/signed; boundary="Apple-Mail=_51407FE9-02D8-4015-8E49-AB5D259FBDD2"; protocol="application/pgp-signature"; micalg=pgp-sha512 Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) Date: Tue, 5 Sep 2017 17:54:49 -0700 In-Reply-To: Cc: Christer Holmberg , Bernard Aboba , Emil Ivov , "ice@ietf.org" To: Peter Thatcher References: <7594FB04B1934943A5C02806D1A2204B4CC9ED94@ESESSMB109.ericsson.se> <0447726F-82C7-43D8-99AE-5B72F0B55B6C@gmail.com> <7594FB04B1934943A5C02806D1A2204B5626F889@ESESSMB102.ericsson.se> <7594FB04B1934943A5C02806D1A2204B56289F26@ESESSMB109.ericsson.se> X-Mailer: Apple Mail (2.3273) Archived-At: Subject: Re: [Ice] Re-nomination and candidate pair switching in RFC 5245bis - PROPOSAL 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, 06 Sep 2017 00:54:56 -0000 --Apple-Mail=_51407FE9-02D8-4015-8E49-AB5D259FBDD2 Content-Type: multipart/alternative; boundary="Apple-Mail=_ACA20FCB-123B-4CC4-A42A-0CFDAADDEAF1" --Apple-Mail=_ACA20FCB-123B-4CC4-A42A-0CFDAADDEAF1 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii > On Sep 5, 2017, at 16:48, Peter Thatcher wrote: >=20 > Thinking about this some more: I think it's fine if 5245bis says that = you can't renominate. We could say "an ICE option or extension may = allow renomination", but we could just put that in a new ICE option or = extension (like = https://tools.ietf.org/html/draft-thatcher-ice-renomination-01 = ). Then = it's clear that without the extension, you can't, but with the extension = you can. +1 Nils Ohlmeier >=20 >=20 > On Tue, Sep 5, 2017 at 5:26 AM Christer Holmberg = > = wrote: > Hi, >=20 > >>Peter (and others interested), > >> > >> IF you want some change to the current behaviour, where a = re-nomination > >>is > >> NOT allowed, you need to participate in the discussion NOW. We are > >>moving > >> towards WGLC, and we should close the window for technical changes > >> (non-bug fixing). > >> > >> If I understood Bernard correctly, he was asking for having = multiple > >> SIMULTANEOUS nominations, in order to do RTP multipath stuff etc. I > >> personally think that is outside the scope of 5245bis. I think the > >> question is whether we should allow re-nominations of single = candidate > >> pairs. > > > >[BA] Actually, I was just trying to understand what the current draft > >allows and why. As it stands, the draft appears to support multi-path = RTP > >before nomination, but not after. >=20 > Currently, the draft allows switching between pairs before nomination, > yes. As for WHY, I assume it is to allow media transport before the = ICE > procedures have finished. >=20 > Regards, >=20 > Christer >=20 >=20 >=20 >=20 >=20 > > >=20 > _______________________________________________ > Ice mailing list > Ice@ietf.org > https://www.ietf.org/mailman/listinfo/ice --Apple-Mail=_ACA20FCB-123B-4CC4-A42A-0CFDAADDEAF1 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii
On Sep 5, 2017, at 16:48, Peter Thatcher <pthatcher@google.com> wrote:

Thinking about this some more: I think it's fine if 5245bis = says that you can't renominate.  We could say "an ICE option or = extension may allow renomination", but we could just put that in a new = ICE option or extension (like https://tools.ietf.org/html/draft-thatcher-ice-renomination-01<= /a>).  Then it's clear that without the extension, you can't, but = with the extension you can.

+1



On Tue, Sep 5, 2017 at 5:26 AM Christer Holmberg = <christer.holmberg@ericsson.com> wrote:
Hi,

>>Peter (and others interested),
>>
>> IF you want some change to the current behaviour, where a = re-nomination
>>is
>> NOT allowed, you need to participate in the discussion NOW. We = are
>>moving
>> towards WGLC, and we should close the window for technical = changes
>> (non-bug fixing).
>>
>> If I understood Bernard correctly, he was asking for having = multiple
>> SIMULTANEOUS nominations, in order to do RTP multipath stuff = etc. I
>> personally think that is outside the scope of 5245bis. I think = the
>> question is whether we should allow re-nominations of single = candidate
>> pairs.
>
>[BA] Actually, I was just trying to understand what the current = draft
>allows and why. As it stands, the draft appears to support = multi-path RTP
>before nomination, but not after.

Currently, the draft allows switching between pairs before = nomination,
yes. As for WHY, I assume it is to allow media transport before the = ICE
procedures have finished.

Regards,

Christer





>

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

= --Apple-Mail=_ACA20FCB-123B-4CC4-A42A-0CFDAADDEAF1-- --Apple-Mail=_51407FE9-02D8-4015-8E49-AB5D259FBDD2 Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP -----BEGIN PGP SIGNATURE----- iQIcBAEBCgAGBQJZr0daAAoJEGNqP1ZsyfihrRcQANmvi2rlcPzaJf6KUzZnxSo/ CEYq1AM1tJp5xHjJyJySK28ZYBL2cWy8BBeIiIuYk3ahZELY3EEtSUsmXROXTSrA FAa0/56g5WSlRJup/CdIJiZboqdQwzyYFyQLWeLlbvGF6hVzN8AmBEAF50IEMnb0 E6p9hhn4alJSxLgrsgpjbGq8sKqi+b2k26mhh3BVz6gnzgBaoc45pNGFSZazY4v0 KjhYFrMUwBHpr3/cG9YKk0D5/5dVrLQoG4lQbZD28XRTDKaQLTMufCTcsDBYSvEs 1JSYdy+Im7+92NdhkwSYjtQQe6Exr+5j0nDltWv0+dO8I0l6hryfGD+Y9xFxrbGq K/2KYXu9n8/ApzTuc2Qx7myKclErOZK/l9g5e7YawYNgiO02h1xZKlH+4wi/MwOl IHKSVjxjwKU4trKopGut2OI47gQUIzKC7S5f8O3s8D6kZ7sGH/1b5AE97nkzVfV1 KY2Ucs07uN2KXh4xdYe1dPPQ3GJhC5TDxgXUO+2Cul+4J0MGJvdKUwv1cEHBjs4H 1+PvU8UYFEEOW7+SrWnYg6fmcBCQL5hDYSLoV0QFSvwLmf3iVKS/setaaL96LVEl JY7lbfY4RFWaLMvjeLEbDmi+rsLOhCiLenL13+CWcW+rTbG79RhIRX22KI6vnjb4 lrMh3/u6Yw9dTE32ANNy =Blhe -----END PGP SIGNATURE----- --Apple-Mail=_51407FE9-02D8-4015-8E49-AB5D259FBDD2-- From nobody Wed Sep 6 03:03: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 0901B132703 for ; Wed, 6 Sep 2017 03:03: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, 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 RywfCbveS7_V for ; Wed, 6 Sep 2017 03:03:41 -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 D69EC1270AB for ; Wed, 6 Sep 2017 03:03:40 -0700 (PDT) X-AuditID: c1b4fb2d-103ff700000057a4-41-59afc7fa048f Received: from ESESSHC016.ericsson.se (Unknown_Domain [153.88.183.66]) by sessmg23.ericsson.net (Symantec Mail Security) with SMTP id AF.84.22436.AF7CFA95; Wed, 6 Sep 2017 12:03:38 +0200 (CEST) Received: from ESESSMB109.ericsson.se ([169.254.9.194]) by ESESSHC016.ericsson.se ([153.88.183.66]) with mapi id 14.03.0352.000; Wed, 6 Sep 2017 12:03:38 +0200 From: Christer Holmberg To: Peter Thatcher , "ice@ietf.org" Thread-Topic: [Ice] 5245bis: Clarification on receiving media Thread-Index: AQHTJhw5nxtCpphJMU+/wjHo8GYd46Km1b2AgAAh9niAAL0AAA== Date: Wed, 6 Sep 2017 10:03:38 +0000 Message-ID: References: In-Reply-To: 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.147] Content-Type: multipart/alternative; boundary="_000_D5D5A2EE21108christerholmbergericssoncom_" MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFprNIsWRmVeSWpSXmKPExsUyM2K7k+6v4+sjDea+sLb4dqHW4try16wO TB4LNpV6LFnykymAKYrLJiU1J7MstUjfLoEr43OvdMFF/YrTC7tZGxhnaXYxcnJICJhI/Pm5 j7WLkYtDSOAIo8Sy179YIJzFjBIH9+5m72Lk4GATsJDo/qcN0iAi4CGx+c1yNhBbWMBGYvuK I4wQcVuJGZ09rBC2k8TdM5vBbBYBFYlt7y+D2bwC1hK9HWeZQWwhgZOMErMWSIPYnAKBEqfe v2AHsRkFxCS+n1rDBGIzC4hL3HoynwniUAGJJXvOM0PYohIvH/9jBTlNVEBP4t1+TxBTQkBJ YtrWNIjOBImJjxqYIbYKSpyc+YRlAqPILCRDZyEpm4WkDCKuI7Fg9yc2CFtbYtnC18ww9pkD j6F6rSW2nNvJiKxmASPHKkbR4tTi4tx0I2O91KLM5OLi/Dy9vNSSTYzAKDu45bfuDsbVrx0P MQpwMCrx8G46vD5SiDWxrLgy9xCjBAezkgjv4wNAId6UxMqq1KL8+KLSnNTiQ4zSHCxK4rwO +y5ECAmkJ5akZqemFqQWwWSZODilGhiDa07vDbN6X6ji2jxvptIma5cTP7MMyxsNy4zfTZhj o/WhkDnwlsP1TOe4iWrzNmaaREyqKHxnts27d8661T/mrt94brbFlNhX2YtYQxV171y7aFyQ 53J+YYH7M85XT5s3F5j6Fzlt9DzptvG5ywNlY74VFeevyb+6ucDfgn3+T/6ebesOXp+lxFKc kWioxVxUnAgAir4esa4CAAA= Archived-At: Subject: Re: [Ice] 5245bis: Clarification on receiving media 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, 06 Sep 2017 10:03:43 -0000 --_000_D5D5A2EE21108christerholmbergericssoncom_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi, >Actually, it gets a little complicated, because if the controlling side sh= ould probably still be prepared to receive media until the binding response= from the nomination, to make sure the controlled side knows to stop sendin= g before the controlling side stops receiving. Sure. But, before nomination, why should an endpoint be prepared to receive media= on ANY candidate? Media should only be send on VALID pairs. Regards, Christer On Tue, Sep 5, 2017 at 4:50 PM Peter Thatcher > wrote: I think that's implied by the fact that resources can be release upon nomin= ation. Plus it's only "SHOULD". But if I'd be OK with adding a phrase to = make it more explicit. On Tue, Sep 5, 2017 at 12:55 AM Christer Holmberg > wrote: Hi, Section 11.2 of 5245bis contains the following text: "Even though ICE agents are only allowed to send media using valid candidate pairs (and, once a candidate pair has been selected, only on the selected pair) ICE implementations SHOULD by default be prepared to receive media on any of the candidates provided in the most recent candidate exchange with the peer." I think we need to clarify that being prepared to receive media on any cand= idate also only applies until a candidate pair has been selected. Regards, Christer _______________________________________________ Ice mailing list Ice@ietf.org https://www.ietf.org/mailman/listinfo/ice --_000_D5D5A2EE21108christerholmbergericssoncom_ Content-Type: text/html; charset="us-ascii" Content-ID: Content-Transfer-Encoding: quoted-printable
Hi,

>Actually, it gets a little complicated, because if the= controlling side should probably still be prepared to receive media until = the binding response from the nomination, to make sure the controlled side = knows to stop sending before the controlling side stops receiving.

Sure.

But, before nomination, why should an endpoint be prepared to receive = media on ANY candidate? Media should only be send on VALID pairs.

Regards,

Christer



On Tue, Sep 5, 2017 at 4:50 PM Peter Thatcher <pthatcher@google.com> wrote:
I think that's implied by the fact that resources can be r= elease upon nomination.  Plus it's only "SHOULD".  But = if I'd be OK with adding a phrase to make it more explicit.

On Tue, Sep 5, 2017 at 12:55 AM Christer Holmberg <christer.holmberg@ericsson.co= m> wrote:
Hi,

Section 11.2 of 5245bis contains the following text:

=
   "Even though ICE agents are only allowed to send media using valid
   candidate pairs (and, once a candidate pair has been selected, only
   on the selected pair) ICE implementations SHOULD by default be
   prepared to receive media on any of the candidates provided in the
   most recent candidate exchange with the peer." 
I think w=
e need to clarify that being prepared to receive media on any candidat=
e also only applies until a candidate pair has been selected.
Regards,<=
/font>
Christer
_______________________________________________
Ice mailing list
Ice@ietf.org
https://www.ietf.org/mailman/listinfo/ice
 --_000_D5D5A2EE21108christerholmbergericssoncom_-- From nobody Wed Sep 6 17:41:36 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 05FCD132D4F for ; Wed, 6 Sep 2017 17:41:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.739 X-Spam-Level: X-Spam-Status: No, score=-1.739 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, 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 iwQ8NIC9bY4S for ; Wed, 6 Sep 2017 17:41:33 -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 4D1C5132D5A for ; Wed, 6 Sep 2017 17:41:33 -0700 (PDT) Received: by mail-qt0-x231.google.com with SMTP id h15so24033316qta.4 for ; Wed, 06 Sep 2017 17:41:33 -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=SjjS46rCICDA9T5FysNIJKTXrfC9CbPRxMtWp9KZxAM=; b=n1VR11yZ11mS13Vs71+1nRIvjKz7FdxKB5LLRSgkx1UodEzQ8r7hJOq46OkpqMnjIr oE9xkw1RW7N10ULXtY2E+Mcqy5NBr7qho4ZFstiSVacsquBNPD3sETVm/Wc7YAw0goBp HkAszrq1b22Sbh7yqJrz3JiA6C8hmG5O7BGyrbjaRNybCEwYRZy02/sniu/0lWfqpUp7 uHUK1n76USq4IZ31j3rREspDiG5vnM8SPK+qW688nZ0ODtqBS+w98SbM4PsIEa2yLg8e jf4jJFAlvcnAyIglKlCKEBYfwRI+VFqGCbeUK11CVelAMtWtXIIgMMeUuLXjyZYwNbpk GXUw== 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=SjjS46rCICDA9T5FysNIJKTXrfC9CbPRxMtWp9KZxAM=; b=X6olvk2vW2c/cnetdFbMXtRMwXejbq9Fa2sVkcF7oSJq01QTeaP093t68QeVwUsRKY 3tRyj7B+NVpPzlHqVFxr43ey0HEaD5tER7EApfnisyCbz8O2ymJzWBu55skYE97AEVZH 7RhyTccpt3n47iCxa/kYleMnAawVcHr5sZsdPrRnNTzGGFNt1WzjiYAD/wF7k7ow37Bh P7hg8hPSYxKdFf/aYmUOXSII67tFoB6HAc6gKw71t1rzRar2+Wq+W6iA787Hgs2UONQl xl+Yoch+l4vDwljSkjaVJGqyqS/6015xktFz0eKBFYeAgAEY6wWatapYZgFQ6aY6IX5H f8iA== X-Gm-Message-State: AHPjjUizs6uZ1ps0BI7juWGiyXv/epdzOIRV0YbOw71MLtXBVGuQlIS2 Kf8GetvYQmMQEAhZDK+yUXl7cyagTguT4Rs= X-Google-Smtp-Source: ADKCNb4tewv0xXZgXghJrBON1A9Or7n1Lq6aOq8Ex/ZIm13O/QbZoXlxLLfkMT00e42ZnbiJ3L5JnVrVZedg0iwkKRg= X-Received: by 10.237.45.7 with SMTP id h7mr1431658qtd.158.1504744892103; Wed, 06 Sep 2017 17:41:32 -0700 (PDT) MIME-Version: 1.0 From: Peter Thatcher Date: Thu, 07 Sep 2017 00:41:21 +0000 Message-ID: To: ICE WG Content-Type: multipart/alternative; boundary="94eb2c124a40c6033105588eb8d2" Archived-At: Subject: [Ice] I updated PR 38 and I have a question about nomination/selection 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, 07 Sep 2017 00:41:35 -0000 --94eb2c124a40c6033105588eb8d2 Content-Type: text/plain; charset="UTF-8" I updated https://github.com/ice-wg/rfc5245bis/pull/38/files from all of the comments at IETF 99. I think I have everything resolved except for the whole "when can you free a candidate" thing. Take a look for more details. And my question is this: Selection on the controlled side is only SHOULD strength, meaning the controlled side can simply ignore nominations from the controlling side. Does that mean that controlled side can choose to never select a candidate pair? And if an agent never selects a candidate pair, can it not always send on any valid candidate pair of its choosing? In other words, if an agent chooses to ignore all nominations and never select a candidate pair, but instead to send on candidate pairs without selecting them and switch between candidate pairs as its sees fit, is that agent still spec-compliant? --94eb2c124a40c6033105588eb8d2 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
I updated=C2=A0https://github.com/ice-wg/rfc5245bis/pull/38/files= =C2=A0from all of the comments at IETF 99.=C2=A0 I think I have everything = resolved except for the whole "when can you free a candidate" thi= ng. =C2=A0 =C2=A0Take a look for more details.

And my qu= estion is this: =C2=A0Selection on the controlled side is only SHOULD stren= gth, meaning the controlled side can simply ignore nominations from the con= trolling side.=C2=A0 Does that mean that controlled side can choose to neve= r select a candidate pair?=C2=A0 And if an agent never selects a candidate = pair, can it not always send on any valid candidate pair of its choosing? = =C2=A0=C2=A0

In other words, if an agent chooses t= o ignore all nominations and never select a candidate pair, but instead to = send on candidate pairs without selecting them and switch between candidate= pairs as its sees fit, is that agent still spec-compliant?
--94eb2c124a40c6033105588eb8d2-- From nobody Wed Sep 6 23:15:27 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 0811C132A05 for ; Wed, 6 Sep 2017 23:15:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.219 X-Spam-Level: X-Spam-Status: No, score=-4.219 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, 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 prLeoE9rpLgJ for ; Wed, 6 Sep 2017 23:15:24 -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 E12AE132139 for ; Wed, 6 Sep 2017 23:15:23 -0700 (PDT) X-AuditID: c1b4fb2d-4e93a9c0000057a4-7c-59b0e3f9dbad Received: from ESESSHC005.ericsson.se (Unknown_Domain [153.88.183.33]) by sessmg23.ericsson.net (Symantec Mail Security) with SMTP id 53.80.22436.9F3E0B95; Thu, 7 Sep 2017 08:15:22 +0200 (CEST) Received: from ESESSMB109.ericsson.se ([169.254.9.194]) by ESESSHC005.ericsson.se ([153.88.183.33]) with mapi id 14.03.0352.000; Thu, 7 Sep 2017 08:15:11 +0200 From: Christer Holmberg To: Peter Thatcher , ICE WG Thread-Topic: [Ice] I updated PR 38 and I have a question about nomination/selection Thread-Index: AQHTJ3IRYv+AapMhGE+46WiPlX+3FqKpBIwA Date: Thu, 7 Sep 2017 06:15:11 +0000 Message-ID: References: In-Reply-To: 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_D5D6BF102119Bchristerholmbergericssoncom_" MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFprGIsWRmVeSWpSXmKPExsUyM2K7ou6vxxsiDRZc4rL4dqHW4try16wO TB4LNpV6LFnykymAKYrLJiU1J7MstUjfLoErY/fJ6SwFb1Qq/h6+wtrAeFK+i5GDQ0LARGL7 l6IuRk4OIYEjjBLLD7J2MXIB2YsZJdadOs8EUsMmYCHR/U8bxBQRcJBoOBoHYgoLhEo82C8G EQ2TaN5tBzJERMBI4v3vy8wgNouAisTcJfdZQWxeAWuJpl8vmSEWBUhsvzABzOYUCJTYPn0J O4jNKCAm8f3UGiYQm1lAXOLWk/lgtoSAgMSSPeeZIWxRiZeP/7GCrBUV0JN4t98TIqwo8fHV PkaQMLNAgsSkU6oQWwUlTs58wjKBUWQWkqGzEKpmIamCKDGQeH9uPjOErS2xbOFrKFtfYuOX s4wQtrXEpJ/b2JHVLGDkWMUoWpxaXJybbmSsl1qUmVxcnJ+nl5dasokRGFsHt/zW3cG4+rXj IUYBDkYlHt5j9zdECrEmlhVX5h5ilOBgVhLhPQkS4k1JrKxKLcqPLyrNSS0+xCjNwaIkzuuw 70KEkEB6YklqdmpqQWoRTJaJg1OqgXHVz9bq12evHqjxzz1rt+qt4Zq5BfuLH7KF5uXm7Hy6 Yqb+rasvDPdvOLCOmbt1r+gWq55P05hYREPdApoDFd+E/rwisuQXS0XzufMFnE93X5i0Tvlv KO+W2OSqP7Zr9v77O5M702vKB7kEj60+RXkZ5y25PA51dfkw1h9NO/Pf4Akn5/XYxzOUWIoz Eg21mIuKEwHfGrjWqQIAAA== Archived-At: Subject: Re: [Ice] I updated PR 38 and I have a question about nomination/selection 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, 07 Sep 2017 06:15:26 -0000 --_000_D5D6BF102119Bchristerholmbergericssoncom_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable Hi, If the controlled side, for whatever reason, doesn=92t accept the nominatio= n, it should reject the nomination request. In my opinion, once a pair has = been selected, it must be used. Regards, Christer From: Ice > on behalf of = "pthatcher@google.com" > Date: Thursday 7 September 2017 at 03:41 To: "ice@ietf.org" > Subject: [Ice] I updated PR 38 and I have a question about nomination/selec= tion I updated https://github.com/ice-wg/rfc5245bis/pull/38/files from all of th= e comments at IETF 99. I think I have everything resolved except for the w= hole "when can you free a candidate" thing. Take a look for more details= . And my question is this: Selection on the controlled side is only SHOULD s= trength, meaning the controlled side can simply ignore nominations from the= controlling side. Does that mean that controlled side can choose to never= select a candidate pair? And if an agent never selects a candidate pair, = can it not always send on any valid candidate pair of its choosing? In other words, if an agent chooses to ignore all nominations and never sel= ect a candidate pair, but instead to send on candidate pairs without select= ing them and switch between candidate pairs as its sees fit, is that agent = still spec-compliant? --_000_D5D6BF102119Bchristerholmbergericssoncom_ Content-Type: text/html; charset="Windows-1252" Content-ID: Content-Transfer-Encoding: quoted-printable
Hi,

If the controlled side, for whatever reason, doesn=92t accept the nomi= nation, it should reject the nomination request. In my opinion, once a pair= has been selected, it must be used.

Regards,

Christer

From: Ice <ice-bounces@ietf.org> on behalf of "pthatcher@google.com" <pthatcher@google.com>
Date: Thursday 7 September 2017 at = 03:41
To: "ice@ietf.org" <ice@ietf.= org>
Subject: [Ice] I updated PR 38 and = I have a question about nomination/selection

I updated https://github.com/ice-wg/rfc5245bis/pull/38/files&= nbsp;from all of the comments at IETF 99.  I think I have everything r= esolved except for the whole "when can you free a candidate" thing.    Take a look for more details.

And my question is this:  Selection on the controlled side is onl= y SHOULD strength, meaning the controlled side can simply ignore nomination= s from the controlling side.  Does that mean that controlled side can = choose to never select a candidate pair?  And if an agent never selects a candidate pair, can it not always send on = any valid candidate pair of its choosing?   

In other words, if an agent chooses to ignore all nominations and neve= r select a candidate pair, but instead to send on candidate pairs without s= electing them and switch between candidate pairs as its sees fit, is that a= gent still spec-compliant?
 --_000_D5D6BF102119Bchristerholmbergericssoncom_-- From nobody Wed Sep 6 23:20:27 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 34D5F132A05 for ; Wed, 6 Sep 2017 23:20:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.998 X-Spam-Level: X-Spam-Status: No, score=-1.998 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, 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=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NO5Zr60wKB8o for ; Wed, 6 Sep 2017 23:20:19 -0700 (PDT) Received: from mail-ua0-x22c.google.com (mail-ua0-x22c.google.com [IPv6:2607:f8b0:400c:c08::22c]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 70244132139 for ; Wed, 6 Sep 2017 23:20:19 -0700 (PDT) Received: by mail-ua0-x22c.google.com with SMTP id c27so17437740uah.2 for ; Wed, 06 Sep 2017 23:20:19 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=t22axD/ab6ePnEyqSzfvOR7/n9IBalXB13kIk6hNbM4=; b=F2vZkqUICN2dBafZD0CLNmLq26GYR4CJ46CqHTvUK8DQd3yqG/Z5ahNlkErBTKkeDX 2oCRIOGSeM9OKpKfcryZpsEYdMsgrige0r296ffjN5W7Vn4+OPb4hxzN7bl/3bbs9ZRH LiVQ4swXn9w5vpS6XseBZpfKOaWllZdIPtD1PYSTO2rHXDGfv6AmC2y5F2TuuKSMcNRK iuAQLxKODNHyGWv5fGyPkAF7ZlsgpjFyWKlmKsoTaIkCcQWFoXKHEgXwZmiv4X8Q7n3o oX0YTlkK5/xdufb4Uss08UEahT5y48pXsg0y4tPt5hlaIX38RCJLb1BhNrq18SfVGILk 49QA== 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=t22axD/ab6ePnEyqSzfvOR7/n9IBalXB13kIk6hNbM4=; b=PLqG0yiGIaHNakyafBTIhp28VvvFkZ+r3EjSYJtMGpJxvQ+6HGd2G/tZxQ15yG7eVo lx6uBpDSLvcj2PspiRr9+jpogCmAu8I9QABQoN4p1lrr+g3Ujb8Qen8hSbPnSmPafIIK 07PW6jN705rzXnZeBB2M5hba/HSOhVqdOoxdBbqkaIFh2IfnxRD7n3s9TS8+pVcjvFe4 H1FG3eCgmPVpKIu3iiD+mXYqc2Spy3TC4ozxgUxS3D3NYsw7KACPbCAEL6TKfGDii3Fr hUypE4txQNFR8yYomjbfVO9pDd8JBmL1jSbWN5tQGZ4Cs1+4QiHMQlY/RjvtyQIN6g/D Ak4w== X-Gm-Message-State: AHPjjUhXNjkFJd8wdTluCR0aASXzQvmv0+lfT4710RDr72FOGHtjjVrk bovwgrpffY+g+sZghZSg+uuMei8/2Q== X-Google-Smtp-Source: ADKCNb7jBmFqzULjsFmQxqt59ZWsR2oRBPawZk8+BmcLR4ZFiShD9Ws/xUgHTXK3N0J49ubnUWbCll6qcqewIOjBXxw= X-Received: by 10.176.7.3 with SMTP id h3mr1182130uah.66.1504765218298; Wed, 06 Sep 2017 23:20:18 -0700 (PDT) MIME-Version: 1.0 Received: by 10.176.74.23 with HTTP; Wed, 6 Sep 2017 23:19:57 -0700 (PDT) In-Reply-To: References: From: Bernard Aboba Date: Wed, 6 Sep 2017 23:19:57 -0700 Message-ID: To: Peter Thatcher Cc: ICE WG Content-Type: multipart/alternative; boundary="94eb2c123cb44e9ffe0558937492" Archived-At: Subject: Re: [Ice] I updated PR 38 and I have a question about nomination/selection 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, 07 Sep 2017 06:20:26 -0000 --94eb2c123cb44e9ffe0558937492 Content-Type: text/plain; charset="UTF-8" Peter said: "And my question is this: Selection on the controlled side is only SHOULD strength, meaning the controlled side can simply ignore nominations from the controlling side. Does that mean that controlled side can choose to never select a candidate pair?" [BA] "Ignoring nominations" might mean several things: a. Not being prepared to receive on the selected pair. b. Retaining resources outside the selected pair c. Choosing to send on a validated pair other than the selected pair (presumably with consent) I would suggest that b) and c) are acceptable behaviors, but that a) is not. "And if an agent never selects a candidate pair, can it not always send on any valid candidate pair of its choosing?" [BA] Without nomination *either* controlled or controlling sides can send on any valid candidate pair, and there is not even a requirement for symmetry. It is even possible for either side to simultaneously send streams on different valid candidate pairs (e.g. multi-path RTP). Either side can release resources by refusing consent on a candidate that they would prefer not to receive with, or by no longer requesting consent for a candidate they no longer wish to send with. The downside is the potential for consent failures that RFC 7675 insists results in pair invalidation. So if you don't want to keep a WWAN interface up to save power, unless there is a way to explicitly "remove" and then "add" it back, then candidates involving that interface will be released. TURN mobility offers a way to quickly bring up media flow using an awakened interface, but if all other pairs involving that interface have been invalidated, then you're stuck with the relay candidate unless you do an ICE restart. Ugh. "In other words, if an agent chooses to ignore all nominations and never select a candidate pair, but instead to send on candidate pairs without selecting them and switch between candidate pairs as its sees fit, is that agent still spec-compliant?" [BA] I think it's ok for the controlling side not to nominate a pair, but if it does, then the controlled side needs to be prepared to receive on that pair. On Wed, Sep 6, 2017 at 5:41 PM, Peter Thatcher wrote: > I updated https://github.com/ice-wg/rfc5245bis/pull/38/files from all of > the comments at IETF 99. I think I have everything resolved except for the > whole "when can you free a candidate" thing. Take a look for more > details. > > And my question is this: Selection on the controlled side is only SHOULD > strength, meaning the controlled side can simply ignore nominations from > the controlling side. Does that mean that controlled side can choose to > never select a candidate pair? And if an agent never selects a candidate > pair, can it not always send on any valid candidate pair of its choosing? > > In other words, if an agent chooses to ignore all nominations and never > select a candidate pair, but instead to send on candidate pairs without > selecting them and switch between candidate pairs as its sees fit, is that > agent still spec-compliant? > > _______________________________________________ > Ice mailing list > Ice@ietf.org > https://www.ietf.org/mailman/listinfo/ice > > --94eb2c123cb44e9ffe0558937492 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Peter said:=C2=A0

"And my question is this: =C2=A0Selection on the controlle= d side is only SHOULD strength, meaning the controlled side can simply igno= re nominations from the controlling side.=C2=A0Does that mean that controlled side can choose to never select = a candidate pair?"
<= br>
[BA] "Ignoring n= ominations" might mean several things:=C2=A0

a. Not being prepared to receive on the selected pair.=C2=A0
b. Retaining resources outside the= selected pair
c. Choosin= g to send on a validated pair other than the selected pair (presumably with= consent)

I would suggest that b) and c) are = acceptable behaviors, but that a) is not.=C2=A0


=C2=A0"And i= f an agent never selects a candidate pair, can it not always send on any va= lid candidate pair of its choosing?"

[BA= ] Without nomination *either* controlled or controlling sides can send on a= ny valid candidate pair, and there is not even a requirement for symmetry. = It is even possible for either side to simultaneously send streams on diffe= rent valid candidate pairs =C2=A0(e.g. multi-path RTP). Either side can rel= ease resources by refusing consent on a candidate that they would prefer no= t to receive with, or by no longer requesting consent for a candidate they = no longer wish to send with.=C2=A0

The downsi= de is the potential for consent failures that RFC 7675 insists results in p= air invalidation. So if you don't want to keep a WWAN interface up to s= ave power, unless there is a way to explicitly "remove" and then = "add" it back, then candidates involving that interface will be r= eleased. TURN mobility offers a way to quickly bring up media flow using an= awakened interface, but if all other pairs involving that interface have b= een invalidated, then you're stuck with the relay candidate unless you = do an ICE restart.=C2=A0 Ugh.=C2=A0

"In = other words, if an agent chooses to ignore all nominations and never select= a candidate pair, but instead to send on candidate pairs without selecting= them and switch between candidate pairs as its sees fit, is that agent sti= ll spec-compliant?"

[BA] I think it= 9;s ok for the controlling side not to nominate a pair, but if it does, the= n the controlled side needs to be prepared to receive on that pair.=C2=A0

On Wed,= Sep 6, 2017 at 5:41 PM, Peter Thatcher <pthatcher@google.com> wrote:
I updated= =C2=A0https://github.com/ice-wg/rfc5245bis/pull/38/files=C2=A0from all of the comments at IETF 99.=C2=A0 I think I have everything= resolved except for the whole "when can you free a candidate" th= ing. =C2=A0 =C2=A0Take a look for more details.

And my q= uestion is this: =C2=A0Selection on the controlled side is only SHOULD stre= ngth, meaning the controlled side can simply ignore nominations from the co= ntrolling side.=C2=A0 Does that mean that controlled side can choose to nev= er select a candidate pair?=C2=A0 And if an agent never selects a candidate= pair, can it not always send on any valid candidate pair of its choosing? = =C2=A0=C2=A0

In other words, if an agent chooses t= o ignore all nominations and never select a candidate pair, but instead to = send on candidate pairs without selecting them and switch between candidate= pairs as its sees fit, is that agent still spec-compliant?

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


--94eb2c123cb44e9ffe0558937492-- From nobody Wed Sep 6 23:43:37 2017 Return-Path: X-Original-To: ice@ietfa.amsl.com Delivered-To: ice@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7898B120721 for ; Wed, 6 Sep 2017 23:43:35 -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 e3egySR0K5wW for ; Wed, 6 Sep 2017 23:43:33 -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 4AF981321BB for ; Wed, 6 Sep 2017 23:43:33 -0700 (PDT) X-AuditID: c1b4fb25-967ff70000005333-23-59b0ea936214 Received: from ESESSHC010.ericsson.se (Unknown_Domain [153.88.183.48]) by sesbmg23.ericsson.net (Symantec Mail Security) with SMTP id F1.20.21299.39AE0B95; Thu, 7 Sep 2017 08:43:31 +0200 (CEST) Received: from ESESSMB109.ericsson.se ([169.254.9.194]) by ESESSHC010.ericsson.se ([153.88.183.48]) with mapi id 14.03.0352.000; Thu, 7 Sep 2017 08:43:31 +0200 From: Christer Holmberg To: Bernard Aboba , Peter Thatcher CC: ICE WG Thread-Topic: [Ice] I updated PR 38 and I have a question about nomination/selection Thread-Index: AQHTJ3IRYv+AapMhGE+46WiPlX+3FqKo0jyAgAA6OYA= Date: Thu, 7 Sep 2017 06:43:30 +0000 Message-ID: References: In-Reply-To: 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.147] Content-Type: multipart/alternative; boundary="_000_D5D6C308211A4christerholmbergericssoncom_" MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFtrIIsWRmVeSWpSXmKPExsUyM2K7ge7kVxsiDZ5tVbXYsO8/s8W3C7UW 15a/ZnVg9tg56y67x4JNpR5LlvxkCmCO4rJJSc3JLEst0rdL4Mr4ceQOU0Gje8XE7j+MDYxb rbsYOTkkBEwkbq3+xNbFyMUhJHCEUeL+5RfsEM5iRoneV99Zuhg5ONgELCS6/2mDNIgIhEi8 m36IFcRmFpCUWPt5KTtIibBAqMSD/WIgpohAmETzbjuIaiuJx7ffsoDYLAIqEr/v3GIHsXkF rCUO7Wligtg0nVFi9plOZpAEp0CgRPPLU2wgNqOAmMT3U2uYIFaJS9x6Mp8J4mYBiSV7zjND 2KISLx//YwXZKyqgJ/FuvyeIKSGgJDFtaxpEZ4LEt00HmSHWCkqcnPmEZQKj6CwkQ2chKZuF pAwibiDx/tx8ZghbW2LZwtdQtr7Exi9nGSFsa4klu/YxIqtZwMixilG0OLU4KTfdyFgvtSgz ubg4P08vL7VkEyMwIg9u+a26g/HyG8dDjAIcjEo8vEH3NkQKsSaWFVfmHmKU4GBWEuH1fQkU 4k1JrKxKLcqPLyrNSS0+xCjNwaIkzuu470KEkEB6YklqdmpqQWoRTJaJg1OqgTH41uZfFU0m 2//ZZe5zaAor8i7jminCf/njc/1VB1x25WT/5Hygde4Hw3eRiWc0c/SDlu/MPWVcubnKTSIt 43X2b+M/LlvyGpjMrzJ7cQbk9KubPli53SQu/19txrwOU/59K1XPJDwWr+s0fb4r4wBbwVGD WTsYlzoHPXYI+Xprc8u681Uxv5RYijMSDbWYi4oTAQ0VnfbEAgAA Archived-At: Subject: Re: [Ice] I updated PR 38 and I have a question about nomination/selection 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, 07 Sep 2017 06:43:35 -0000 --_000_D5D6C308211A4christerholmbergericssoncom_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable Hi, >Peter said: > >"And my question is this: Selection on the controlled side is only SHOULD= strength, meaning the controlled side can simply ignore nominations from t= he controlling side. Does that mean that controlled side can choose to neve= r select a candidate pair?" > >[BA] "Ignoring nominations" might mean several things: > >a. Not being prepared to receive on the selected pair. >b. Retaining resources outside the selected pair >c. Choosing to send on a validated pair other than the selected pair (pres= umably with consent) > >I would suggest that b) and c) are acceptable behaviors, but that a) is no= t. I don=92t think we should allow c). We can of course not prevent implementa= tions from doing so, but it should not be 5245bis-endorsed behaviour. We se= lect a pair, and then we use it. > "And if an agent never selects a candidate pair, can it not always send o= n any valid candidate pair of its choosing?" > >[BA] Without nomination *either* controlled or controlling sides can send = on any valid candidate pair, and there is not even a requirement for symmet= ry. It is even possible for either side to simultaneously send streams on d= ifferent valid candidate pairs (e.g. multi-path RTP). I am not sure whether the intent ever was to allow simultaneous streams. If it=92s needed, I think some ICE-considerations-for-multipath-RTP should = enhance ICE, and define how multiple pairs can be used both before and afte= r nomination (or specify that nomination is never done). As far as 5245bis = is concerned, I think we should say that only one pair is used at any given= time, and that the controlling endpoint MUST nominate within a =93reasonab= le=94 time. >Either side can release resources by refusing consent on a candidate that = they would prefer not to receive with, or by no longer requesting consent f= or a candidate they no longer wish to send with. > >The downside is the potential for consent failures that RFC 7675 insists r= esults in pair invalidation. So if you don't want to keep a WWAN interface = up to save power, unless there is a way to explicitly "remove" and then "ad= d" it back, then candidates involving that >interface will be released. TURN mobility offers a way to quickly bring up= media flow using an awakened interface, but if all other pairs involving t= hat interface have been invalidated, then you're stuck with the relay candi= date unless you do an ICE restart. Ugh. >"In other words, if an agent chooses to ignore all nominations and never s= elect a candidate pair, but instead to send on candidate pairs without sele= cting them and switch between candidate pairs as its sees fit, is that agen= t still spec-compliant?" > >[BA] I think it's ok for the controlling side not to nominate a pair, but = if it does, then the controlled side needs to be prepared to receive on tha= t pair. And if it isn=92t, it shouldn=92t reply to the nomination request. Now, THA= T is not really covered in the spec =96 the assumption seems to be that, as= the nominated pair is in the valid list, the nomination will always succee= d. Regards, Christer --_000_D5D6C308211A4christerholmbergericssoncom_ Content-Type: text/html; charset="Windows-1252" Content-ID: <48980029F7EEEB4CB360C35CFAC0066C@ericsson.com> Content-Transfer-Encoding: quoted-printable
Hi,

>Peter said: 
>
>"And my question is this: &n= bsp;Selection on the controlled side is only SHOULD strength, meaning the c= ontrolled side can simply ignore nominations from the controlling side.&nbs= p;Does that mean that controlled side can choose to never select a candidate pair?"
>
>[BA] "Ignoring nominations&q= uot; might mean several things: 
>
>a. Not being prepared to receive = on the selected pair. 
>b. Retaining resources outside th= e selected pair
>c. Choosing to send on a validate= d pair other than the selected pair (presumably with consent)
>
>I would suggest that b) and c) ar= e acceptable behaviors, but that a) is not. 

I don=92t think we should allow c). We can of course not prevent imple= mentations from doing so, but it should not be 5245bis-endorsed behaviour. = We select a pair, and then we use it.

> "And if an agent never sele= cts a candidate pair, can it not always send on any valid candidate pair of= its choosing?"
>
>[BA] Without nomination *either* = controlled or controlling sides can send on any valid candidate pair, and t= here is not even a requirement for symmetry. It is even possible for either= side to simultaneously send streams on different valid candidate pairs  (e.g. multi-path RTP).

I am not sure whether the intent ever was to allow simultaneous stream= s. 

If it=92s needed, I think some ICE-considerations-for-multipath-RTP sh= ould enhance ICE, and define how multiple pairs can be used both before and= after nomination (or specify that nomination is never done). As far as 524= 5bis is concerned, I think we should say that only one pair is used at any given time, and that the controlling= endpoint MUST nominate within a =93reasonable=94 time.
>Either side can release resourc= es by refusing consent on a candidate that they would prefer not to receive= with, or by no longer requesting consent for a candidate they no longer wi= sh to send with. 
>
>The downside is the potential for= consent failures that RFC 7675 insists results in pair invalidation. So if= you don't want to keep a WWAN interface up to save power, unless there is = a way to explicitly "remove" and then "add" it back, then candidates involving that
>interface will be released. TUR= N mobility offers a way to quickly bring up media flow using an awakened in= terface, but if all other pairs involving that interface have been invalida= ted, then you're stuck with the relay candidate unless you do an ICE restart.  Ugh. 

>"In other words, if an agent= chooses to ignore all nominations and never select a candidate pair, but i= nstead to send on candidate pairs without selecting them and switch between= candidate pairs as its sees fit, is that agent still spec-compliant?"
>
>[BA] I think it's ok for the controlling side not to nominate a pa= ir, but if it does, then the controlled side needs to be prepared to receiv= e on that pair. 

And if it isn=92t, it shouldn=92t reply to the nomination request. Now= , THAT is not really covered in the spec =96 the assumption seems to be tha= t, as the nominated pair is in the valid list, the nomination will always s= ucceed.

Regards,

Christer

--_000_D5D6C308211A4christerholmbergericssoncom_-- From nobody Wed Sep 6 23:52:53 2017 Return-Path: X-Original-To: ice@ietfa.amsl.com Delivered-To: ice@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6D22C132332 for ; Wed, 6 Sep 2017 23:52:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=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 rqaTEKe_7mLh for ; Wed, 6 Sep 2017 23:52:50 -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 57B311321F5 for ; Wed, 6 Sep 2017 23:52:50 -0700 (PDT) Received: by mail-qt0-x229.google.com with SMTP id q8so20972562qtb.5 for ; Wed, 06 Sep 2017 23:52:50 -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=wOOilBOq4Ynd2Gr6dK6oyJO/wnFhIoZ/AXxxgFVWIFw=; b=Ub8/6KCJncXCHbBChV7BELWJnT+LtFfZeXeneu4yKY05+H9iEA3o2Ueyi1fu8UlT69 sIfekNE70kZny+TlOoTt4g8AKsQV6bF8BWjS/+giKWe06uUKw/2uTfXESBsCPEIO1dDL YKjuzwGYMW0qbpCMQw6KLkt9CGzaLMN7OG/lgDXZjB48KqsQAbo0/gooqD0HkTgLqo1m R1v3XoMUSsWCO/VsMAQuCfEY/0K6zWNJpwSBQUhGvXgh0u+MPDxOqc5DXkQl8NJOFspR QNPfv2Np0eRttHGEyGxfsMC/a+1JTXx1Uak+QxOPdVM6KKSAAEZAnPI6425+WUwJ4nTJ Pnmw== 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=wOOilBOq4Ynd2Gr6dK6oyJO/wnFhIoZ/AXxxgFVWIFw=; b=ncGKjMPcgWJKMB5hQ15Fn8Cc4DvV5ROJO/dbF7XMUPJGE9AeH8N0DW5vkp74r/t5Uz lDYe3Y52dyD9Bo0lxdHjpRtVYeGy0IPj91UpNlHREA0jxDV0a1xDCkRi8jnzyXRD9CHc I2tALh8RPC1zsW6YQxFGllnwYu52w+d/wmSjVOmYZzAwm5gMtHu/5HQG6zJlczogzJKE oD2YRSmWS8JzBj0dhwQ4ozz2RqdE3TMqambuMeGonBxyNc4XmV+ymehf1kd0VgncQuvl 1GSzTz58UZouHiDyiaxAkvlt+3Ke5s9U8v/d0Oh5GrSBH1fbB0yRsnULssws1Nfghz+3 N4AA== X-Gm-Message-State: AHPjjUgbCL2kYYNBIOqQuCiaAXY/krlOsP6UtgBnkwGtzYB4PgyWhMOD 90YDLUqps81N4aBBlSnzZyNGUV5ocAe+ X-Google-Smtp-Source: ADKCNb7955pg8QE6Mxba3AZQtMT8tkR284ulSjFHk5Xx8jrEDNukgT+dZ3j0qgZcKY03iyiPoKdT9lz0zG3048tM/MI= X-Received: by 10.237.35.175 with SMTP id j44mr2347346qtc.140.1504767169319; Wed, 06 Sep 2017 23:52:49 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Peter Thatcher Date: Thu, 07 Sep 2017 06:52:37 +0000 Message-ID: To: Christer Holmberg , ICE WG Content-Type: multipart/alternative; boundary="001a1141b400993e6a055893e8b3" Archived-At: Subject: Re: [Ice] I updated PR 38 and I have a question about nomination/selection 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, 07 Sep 2017 06:52:52 -0000 --001a1141b400993e6a055893e8b3 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable The spec says nothing about accepting or rejecting a nomination. You are correct that once a pair is selected, the spec says, but the spec does not say that the controlling side needs to either accept or reject a nomination. It can simply ignore it and still be compliant (according to my reading of the document). On Wed, Sep 6, 2017 at 11:15 PM Christer Holmberg < christer.holmberg@ericsson.com> wrote: > Hi, > > If the controlled side, for whatever reason, doesn=E2=80=99t accept the > nomination, it should reject the nomination request. In my opinion, once = a > pair has been selected, it must be used. > > Regards, > > Christer > > From: Ice on behalf of "pthatcher@google.com" < > pthatcher@google.com> > Date: Thursday 7 September 2017 at 03:41 > To: "ice@ietf.org" > Subject: [Ice] I updated PR 38 and I have a question about > nomination/selection > > I updated https://github.com/ice-wg/rfc5245bis/pull/38/files from all of > the comments at IETF 99. I think I have everything resolved except for t= he > whole "when can you free a candidate" thing. Take a look for more > details. > > And my question is this: Selection on the controlled side is only SHOULD > strength, meaning the controlled side can simply ignore nominations from > the controlling side. Does that mean that controlled side can choose to > never select a candidate pair? And if an agent never selects a candidate > pair, can it not always send on any valid candidate pair of its choosing? > > In other words, if an agent chooses to ignore all nominations and never > select a candidate pair, but instead to send on candidate pairs without > selecting them and switch between candidate pairs as its sees fit, is tha= t > agent still spec-compliant? > --001a1141b400993e6a055893e8b3 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
The spec says nothing about accepting or rejecting a nomin= ation.=C2=A0 You are correct that once a pair is selected, the spec says, b= ut the spec does not say that the controlling side needs to either accept o= r reject a nomination.=C2=A0 It can simply ignore it and still be compliant= (according to my reading of the document).

On Wed, Sep 6, 2017 at 11:15 PM Christer Holmberg <<= a href=3D"mailto:christer.holmberg@ericsson.com">christer.holmberg@ericsson= .com> wrote:
Hi,

If the controlled side, for whatever reason, doesn=E2=80=99t accept th= e nomination, it should reject the nomination request. In my opinion, once = a pair has been selected, it must be used.

Regards,

Christer

From: Ice <ice-bounces@ietf.org> on behalf= of "pthatch= er@google.com" <pthatcher@google.com>
Date: Thursday 7 September 2017 at = 03:41
To: "ice@ietf.org" <ice@ietf.org>
Subject: [Ice] I updated PR 38 and = I have a question about nomination/selection

I updated=C2=A0https://github.com/ice-wg/rfc5245bis/= pull/38/files=C2=A0from all of the comments at IETF 99.=C2=A0 I think I= have everything resolved except for the whole "when can you free a ca= ndidate" thing. =C2=A0 =C2=A0Take a look for more details.

And my question is this: =C2=A0Selection on the controlled side is onl= y SHOULD strength, meaning the controlled side can simply ignore nomination= s from the controlling side.=C2=A0 Does that mean that controlled side can = choose to never select a candidate pair?=C2=A0 And if an agent never selects a candidate pair, can it not always send on = any valid candidate pair of its choosing? =C2=A0=C2=A0

In other words, if an agent chooses to ignore all nominations and neve= r select a candidate pair, but instead to send on candidate pairs without s= electing them and switch between candidate pairs as its sees fit, is that a= gent still spec-compliant?
--001a1141b400993e6a055893e8b3-- From nobody Thu Sep 7 00:02: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 A6B251241F3 for ; Thu, 7 Sep 2017 00:02:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.699 X-Spam-Level: X-Spam-Status: No, score=-2.699 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, 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 OTmHbBAqr5I5 for ; Thu, 7 Sep 2017 00:02:44 -0700 (PDT) Received: from mail-qk0-x22c.google.com (mail-qk0-x22c.google.com [IPv6:2607:f8b0:400d:c09::22c]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3D962132A85 for ; Thu, 7 Sep 2017 00:02:44 -0700 (PDT) Received: by mail-qk0-x22c.google.com with SMTP id a128so24804557qkc.5 for ; Thu, 07 Sep 2017 00:02: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=UevtjXI+L60m/uJYspYGAl4NxZE5xVJKRUTp3tnMtIM=; b=g2fp0kC+ZWXxHolZz9Bmow041UcuC5HNfTOJp14Vd2zvYIKqbEWD/YiwgfFAIqIbYS xDG3R/YKUqeovU49WoTTq10kzCEBhOcr/dI6Kh/tTjjvYIFCWLizjmfVaeOQ76/DxJvs w6J51S3q/fNb8fKEZxGK6ppD445YGI0D60UqClucCxN9ea4muMclJt7Cy+3gKXSl4On/ kTTO10udLxBGapZWy/3ODEFMLhCXecIcLIuUd5Jfk5Y0IdL5Z9vMnMuLOoIGvVsEi5tu E/G/EwT7zE9Fi5fYlBgwDru/FfeTn5P+w44A02Py+Lw56e5hIzx96kwxYrzitpu19bPK 3fjg== 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=UevtjXI+L60m/uJYspYGAl4NxZE5xVJKRUTp3tnMtIM=; b=egeDxLVNxgozEfxfj5OUOT7gUS8nFPtbHnOfaElnJ08HE2ZbiT0UrYO9OLX5pjSC5x O17b2skc8lkfGMNr+2MBBJV3iPGhWhbjG4N3sBgTY/VLg0PWzzDXY2XGdFa9BK6z5PWK 6aBYzTe2GbOUJQhjgSjLTovadDTCQDE6zjkh4AgPIQYbtqllQ/FwLFyH1Eh/fK8+C0o1 auEhMcV1zfshotitzsM8V5RPMFJXMeiIhyIkXvzqjNQsgHC6p0hX+LL/3LI/OvjjMpuI 9jQExc62FWlmkGL4OyxP6fgyOdYR2GLT5O9VrzycojDQPIjuGu+0CgWTmfTIasq8RKDa Lp+g== X-Gm-Message-State: AHPjjUht607UxHfQqTwJa/8XxetRXpHIeN71fyEHxvyl0z8CEMbAv9Wh wOx3BWL0kDutaZ1VgL4FEyG0urBLpMfA X-Google-Smtp-Source: AOwi7QBIEiDIBBTamFXpr8C9RN7OyWQY+grG8C17IfWoJOerD/U42QFvwMP03btwpkxLLaN088mmJjcMh9mebv4HfgQ= X-Received: by 10.233.232.8 with SMTP id a8mr2090919qkg.265.1504767763203; Thu, 07 Sep 2017 00:02:43 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Peter Thatcher Date: Thu, 07 Sep 2017 07:02:32 +0000 Message-ID: To: Bernard Aboba Cc: ICE WG Content-Type: multipart/alternative; boundary="94eb2c034350ff76760558940b41" Archived-At: Subject: Re: [Ice] I updated PR 38 and I have a question about nomination/selection 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, 07 Sep 2017 07:02:47 -0000 --94eb2c034350ff76760558940b41 Content-Type: text/plain; charset="UTF-8" On Wed, Sep 6, 2017 at 11:20 PM Bernard Aboba wrote: > Peter said: > > "And my question is this: Selection on the controlled side is only > SHOULD strength, meaning the controlled side can simply ignore nominations > from the controlling side. Does that mean that controlled side can choose > to never select a candidate pair?" > > [BA] "Ignoring nominations" might mean several things: > > a. Not being prepared to receive on the selected pair. > b. Retaining resources outside the selected pair > c. Choosing to send on a validated pair other than the selected pair > (presumably with consent) > Or d. Not selecting a candidate pair But that implies b) and c) are possible. > > I would suggest that b) and c) are acceptable behaviors, but that a) is > not. > > > "And if an agent never selects a candidate pair, can it not always send > on any valid candidate pair of its choosing?" > > [BA] Without nomination *either* controlled or controlling sides can send > on any valid candidate pair, and there is not even a requirement for > symmetry. > I'm not saying there is no nomination. I'm saying the controlling side nominates, but the controlled side doesn't select (the spect doesn't require it to). > It is even possible for either side to simultaneously send streams on > different valid candidate pairs (e.g. multi-path RTP). Either side can > release resources by refusing consent on a candidate that they would prefer > not to receive with, or by no longer requesting consent for a candidate > they no longer wish to send with. > > The downside is the potential for consent failures that RFC 7675 insists > results in pair invalidation. So if you don't want to keep a WWAN interface > up to save power, unless there is a way to explicitly "remove" and then > "add" it back, then candidates involving that interface will be released. > TURN mobility offers a way to quickly bring up media flow using an awakened > interface, but if all other pairs involving that interface have been > invalidated, then you're stuck with the relay candidate unless you do an > ICE restart. Ugh. > > "In other words, if an agent chooses to ignore all nominations and never > select a candidate pair, but instead to send on candidate pairs without > selecting them and switch between candidate pairs as its sees fit, is that > agent still spec-compliant?" > > [BA] I think it's ok for the controlling side not to nominate a pair, but > if it does, then the controlled side needs to be prepared to receive on > that pair. > > The spec says that an agent can't release candidates until it goes to the Completed state (per check list), so I think it wouldn't be allowed to release candidates until it selects, which means that if it doesn't select, it must be able to receive on that pair (and, well, all pairs). > On Wed, Sep 6, 2017 at 5:41 PM, Peter Thatcher > wrote: > >> I updated https://github.com/ice-wg/rfc5245bis/pull/38/files from all of >> the comments at IETF 99. I think I have everything resolved except for the >> whole "when can you free a candidate" thing. Take a look for more >> details. >> >> And my question is this: Selection on the controlled side is only SHOULD >> strength, meaning the controlled side can simply ignore nominations from >> the controlling side. Does that mean that controlled side can choose to >> never select a candidate pair? And if an agent never selects a candidate >> pair, can it not always send on any valid candidate pair of its choosing? >> >> In other words, if an agent chooses to ignore all nominations and never >> select a candidate pair, but instead to send on candidate pairs without >> selecting them and switch between candidate pairs as its sees fit, is that >> agent still spec-compliant? >> >> _______________________________________________ >> Ice mailing list >> Ice@ietf.org >> https://www.ietf.org/mailman/listinfo/ice >> >> > --94eb2c034350ff76760558940b41 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


On Wed= , Sep 6, 2017 at 11:20 PM Bernard Aboba <bernard.aboba@gmail.com> wrote:
Peter said:=C2=A0

"= ;And my question is this: =C2=A0Selection = on the controlled side is only SHOULD strength, meaning the controlled side= can simply ignore nominations from the controlling side.=C2=A0Does that mean that controlled side can choose = to never select a candidate pair?"

[BA] "Ignoring nominations" might mean several = things:=C2=A0

=
a. Not being prepared to receiv= e on the selected pair.=C2=A0
b. Retaining resources outside the selected pair
c. Choosing to send on a validated pair other = than the selected pair (presumably with consent)

Or

d.=C2=A0 Not selecting= a candidate pair

But that implies b) and c) are p= ossible. =C2=A0
=C2=A0

I would suggest that b) and c) are acceptable = behaviors, but that a) is not.=C2=A0


=C2= =A0"And if an agent never selects a candidate pair, can it not always = send on any valid candidate pair of its choosing?"

[BA] Without nomination *either* controll= ed or controlling sides can send on any valid candidate pair, and there is = not even a requirement for symmetry.
I'm not saying there is no nomination.=C2=A0 I'm sayin= g the controlling side nominates, but the controlled side doesn't selec= t (the spect doesn't require it to). =C2=A0
=C2=A0
It is even possible for either side to simultaneously send streams o= n different valid candidate pairs =C2=A0(e.g. multi-path RTP). Either side = can release resources by refusing consent on a candidate that they would pr= efer not to receive with, or by no longer requesting consent for a candidat= e they no longer wish to send with.=C2=A0

The downsid= e is the potential for consent failures that RFC 7675 insists results in pa= ir invalidation. So if you don't want to keep a WWAN interface up to sa= ve power, unless there is a way to explicitly "remove" and then &= quot;add" it back, then candidates involving that interface will be re= leased. TURN mobility offers a way to quickly bring up media flow using an = awakened interface, but if all other pairs involving that interface have be= en invalidated, then you're stuck with the relay candidate unless you d= o an ICE restart.=C2=A0 Ugh.=C2=A0

"In other wor= ds, if an agent chooses to ignore all nominations and never select a candid= ate pair, but instead to send on candidate pairs without selecting them and= switch between candidate pairs as its sees fit, is that agent still spec-c= ompliant?"

[BA]= I think it's ok for the controlling side not to nominate a pair, but i= f it does, then the controlled side needs to be prepared to receive on that= pair.=C2=A0

<= div>
The spec says that an agent can't release candidates= until it goes to the Completed state (per check list), so I think it would= n't be allowed to release candidates until it selects, which means that= if it doesn't select, it must be able to receive on that pair (and, we= ll, all pairs). =C2=A0

=C2=A0
<= /div>
On Wed, Se= p 6, 2017 at 5:41 PM, Peter Thatcher <pthatcher@google.com> wrote:
I updated=C2=A0h= ttps://github.com/ice-wg/rfc5245bis/pull/38/files=C2=A0from all of the = comments at IETF 99.=C2=A0 I think I have everything resolved except for th= e whole "when can you free a candidate" thing. =C2=A0 =C2=A0Take = a look for more details.

And my question is this: =C2=A0= Selection on the controlled side is only SHOULD strength, meaning the contr= olled side can simply ignore nominations from the controlling side.=C2=A0 D= oes that mean that controlled side can choose to never select a candidate p= air?=C2=A0 And if an agent never selects a candidate pair, can it not alway= s send on any valid candidate pair of its choosing? =C2=A0=C2=A0
=
In other words, if an agent chooses to ignore all nomination= s and never select a candidate pair, but instead to send on candidate pairs= without selecting them and switch between candidate pairs as its sees fit,= is that agent still spec-compliant?

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


--94eb2c034350ff76760558940b41-- From nobody Thu Sep 7 00:07: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 7DC02132D59 for ; Thu, 7 Sep 2017 00:07:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.699 X-Spam-Level: X-Spam-Status: No, score=-2.699 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, 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 LndurvApjG64 for ; Thu, 7 Sep 2017 00:07:40 -0700 (PDT) Received: from mail-qk0-x234.google.com (mail-qk0-x234.google.com [IPv6:2607:f8b0:400d:c09::234]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 220F11321A5 for ; Thu, 7 Sep 2017 00:07:40 -0700 (PDT) Received: by mail-qk0-x234.google.com with SMTP id o129so24933347qkd.0 for ; Thu, 07 Sep 2017 00:07:40 -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=wr6Pj2ej3VRu76OkOG4J7O19R2q9ymstqkxuxIIHbec=; b=marlob+IrJlxYD4eWSJZnlcLREB2JVYmTXi0Wfvw50mvfrnsUWSuNaHvSAkTE0pgL/ oDawq/F7StoaU5Wb/+qYpzHwtJT3xa/8fpc0Yqt3k/6CLcZBc/d9gsNqBmyhgM0q+Ort 5H4EjkXgi8yhEmpYEJ7qnIV0uAbgvJzi1PjKqBfXqR+whbMrsN4FXYEnWGcldDoRK/y3 17bnv/ex/a5joCo3VGYOMUA4BJ3IeL8SkC2H3wDcvScYF6swzAWOXdwe67hEiq+yunwi WjpA2Oz6KPQVF77CcgzrJP4w+RlJrVverDH77ELBwRlb1pmi9RnbLOKuTSw6ShF86QSX tTyQ== 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=wr6Pj2ej3VRu76OkOG4J7O19R2q9ymstqkxuxIIHbec=; b=BgiuyICivFqrWLKmL7lwoocyqYov6Lu1m769onP6n6nMDHdObPnE6YegBzYK/BvGcX VP7vIWIn9Nw0TCmvsW6yu1T4y7n6/76Ac+DXJ2P+WZxDVpOZzEV9TkaUfT5nEQLFUVrT OM6dydU97cKzOiBljiKHKGgtnWoaL/no3e9rXFzWo0cjoj7mq00sZPS9LvYVvdbAukG5 vVm3ZjYs3xHdhmHJxz9OE6j2ONc/O+C7IG+kf4m3Qj97evCAm6Uu/RGhmmNvZRi5NtNK UIx1z1RL9AAO78t3gTiGUzipy8CO2FA5aI2dlFXw94Uog/aPxqh02uQP5AUGXpMv1fNY dZOA== X-Gm-Message-State: AHPjjUjuC947m51UbdFJMBsjlpLBoVlvcO44wX+o9knlld7fkyDxJAKi NOWy9G7tc1Sbsz/YtOgMe20McDMJuCSUahk= X-Google-Smtp-Source: AOwi7QBooZ2bVHvY5MhgayhSPK+3zBPzRBn2UvpfTRzoYbRzntd21odvDq50p7+1B9IqE5VgDdOJ6jG0ghvsBxZB28M= X-Received: by 10.233.232.8 with SMTP id a8mr2104870qkg.265.1504768059062; Thu, 07 Sep 2017 00:07:39 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Peter Thatcher Date: Thu, 07 Sep 2017 07:07:28 +0000 Message-ID: To: Christer Holmberg , Bernard Aboba Cc: ICE WG Content-Type: multipart/alternative; boundary="94eb2c034350a1dcb30558941dde" Archived-At: Subject: Re: [Ice] I updated PR 38 and I have a question about nomination/selection 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, 07 Sep 2017 07:07:42 -0000 --94eb2c034350a1dcb30558941dde Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Wed, Sep 6, 2017 at 11:43 PM Christer Holmberg < christer.holmberg@ericsson.com> wrote: > Hi, > > >Peter said: > > > >"And my question is this: Selection on the controlled side is only > SHOULD strength, meaning the controlled side can simply ignore nomination= s > from the controlling side. Does that mean that controlled side can choose > to never select a candidate pair?" > > > >[BA] "Ignoring nominations" might mean several things: > > > >a. Not being prepared to receive on the selected pair. > >b. Retaining resources outside the selected pair > >c. Choosing to send on a validated pair other than the selected pair > (presumably with consent) > > > >I would suggest that b) and c) are acceptable behaviors, but that a) is > not. > > I don=E2=80=99t think we should allow c). We can of course not prevent > implementations from doing so, but it should not be 5245bis-endorsed > behaviour. We select a pair, and then we use it. > The spec as currently written only says that the controlled side SHOULD select. It doesn't say it MUST. So I believe C is allowed, as currently written. > > > "And if an agent never selects a candidate pair, can it not always send > on any valid candidate pair of its choosing?" > > > >[BA] Without nomination *either* controlled or controlling sides can sen= d > on any valid candidate pair, and there is not even a requirement for > symmetry. It is even possible for either side to simultaneously send > streams on different valid candidate pairs (e.g. multi-path RTP). > > I am not sure whether the intent ever was to allow simultaneous streams. > > If it=E2=80=99s needed, I think some ICE-considerations-for-multipath-RTP= should > enhance ICE, and define how multiple pairs can be used both before and > after nomination (or specify that nomination is never done). As far as > 5245bis is concerned, I think we should say that only one pair is used at > any given time, and that the controlling endpoint MUST nominate within a > =E2=80=9Creasonable=E2=80=9D time. > I'm not talking about nomination. I'm talking about the controlled side selecting or not (which is currently SHOULD strength). But you're right that as currently written, the controlling side could also choose not to select. I don't know how you'd define a "reasonable" time. What if ICE candidates keep trickling in with trickle ICE? > > >Either side can release resources by refusing consent on a candidate > that they would prefer not to receive with, or by no longer requesting > consent for a candidate they no longer wish to send with. > > > >The downside is the potential for consent failures that RFC 7675 insists > results in pair invalidation. So if you don't want to keep a WWAN interfa= ce > up to save power, unless there is a way to explicitly "remove" and then > "add" it back, then candidates involving that > >interface will be released. TURN mobility offers a way to quickly bring > up media flow using an awakened interface, but if all other pairs involvi= ng > that interface have been invalidated, then you're stuck with the relay > candidate unless you do an ICE restart. Ugh. > > >"In other words, if an agent chooses to ignore all nominations and never > select a candidate pair, but instead to send on candidate pairs without > selecting them and switch between candidate pairs as its sees fit, is tha= t > agent still spec-compliant?" > > > >[BA] I think it's ok for the controlling side not to nominate a pair, bu= t > if it does, then the controlled side needs to be prepared to receive on > that pair. > > And if it isn=E2=80=99t, it shouldn=E2=80=99t reply to the nomination req= uest. Now, THAT > is not really covered in the spec =E2=80=93 > That's exactly my point. The spec does not outline any way for the controlling side to know that the controlled side honored its nomination or not by selecting. > the assumption seems to be that, as the nominated pair is in the valid > list, the nomination will always succeed. > But the spec says that the controlled side SHOULD honor the nomination, which means it might not! So that assumption is not correct (with the currently written text). > > Regards, > > Christer > > --94eb2c034350a1dcb30558941dde Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


On Wed= , Sep 6, 2017 at 11:43 PM Christer Holmberg <christer.holmberg@ericsson.com> wrote:
Hi,

>Peter said:=C2=A0
>
>"And my question is this: = =C2=A0Selection on the controlled side is only SHOULD strength, meaning the= controlled side can simply ignore nominations from the controlling side.= =C2=A0Does that mean that controlled side can choose to never select a candidate pair?"
>
>[BA] "Ignoring nominations&q= uot; might mean several things:=C2=A0
>
>a. Not being prepared to receive = on the selected pair.=C2=A0
>b. Retaining resources outside th= e selected pair
>c. Choosing to send on a validate= d pair other than the selected pair (presumably with consent)
>
>I would suggest that b) and c) ar= e acceptable behaviors, but that a) is not.=C2=A0

I don=E2=80=99t think we should allow c)= . We can of course not prevent implementations from doing so, but it should= not be 5245bis-endorsed behaviour. We select a pair, and then we use it.

The spec as currently written on= ly says that the controlled side SHOULD select.=C2=A0 It doesn't say it= MUST. =C2=A0 =C2=A0So I believe C is allowed, as currently written.
<= div>=C2=A0

> "And if an agent never sele= cts a candidate pair, can it not always send on any valid candidate pair of= its choosing?"
>
>[BA] Without nomination *either* = controlled or controlling sides can send on any valid candidate pair, and t= here is not even a requirement for symmetry. It is even possible for either= side to simultaneously send streams on different valid candidate pairs =C2=A0(e.g. multi-path RTP).

I am not sure whether the intent ever wa= s to allow simultaneous streams.=C2=A0

If it=E2=80=99s needed, I think some ICE-considerations-for-multipath-= RTP should enhance ICE, and define how multiple pairs can be used both befo= re and after nomination (or specify that nomination is never done). As far = as 5245bis is concerned, I think we should say that only one pair is used at any given time, and that the controlling= endpoint MUST nominate within a =E2=80=9Creasonable=E2=80=9D time.

I'm not talking about nomination.= =C2=A0 I'm talking about the controlled side selecting or not (which is= currently SHOULD strength). =C2=A0

But you're= right that as currently written, the controlling side could also choose no= t to select. =C2=A0 I don't know how you'd define a "reasonabl= e" time.=C2=A0 What if ICE candidates keep trickling in with trickle I= CE?
=C2=A0
>Either side can release resources= by refusing consent on a candidate that they would prefer not to receive w= ith, or by no longer requesting consent for a candidate they no longer wish= to send with.=C2=A0
>
>The downside is the potential for= consent failures that RFC 7675 insists results in pair invalidation. So if= you don't want to keep a WWAN interface up to save power, unless there= is a way to explicitly "remove" and then "add" it back, then candidates involving that
>interface will be released. TURN = mobility offers a way to quickly bring up media flow using an awakened inte= rface, but if all other pairs involving that interface have been invalidate= d, then you're stuck with the relay candidate unless you do an ICE restart.=C2=A0 Ugh.=C2=A0

>"In other words, if an agent= chooses to ignore all nominations and never select a candidate pair, but i= nstead to send on candidate pairs without selecting them and switch between= candidate pairs as its sees fit, is that agent still spec-compliant?"
>
>[BA] I think it's ok for the controlling side not to nominate = a pair, but if it does, then the controlled side needs to be prepared to re= ceive on that pair.=C2=A0

And if it isn=E2=80=99t, it shouldn=E2= =80=99t reply to the nomination request. Now, THAT is not really covered in= the spec =E2=80=93

That's = exactly my point.=C2=A0 The spec does not outline any way for the controlli= ng side to know that the controlled side honored its nomination or not by s= electing. =C2=A0
=C2=A0
the assumption seems to be that, as the nominated = pair is in the valid list, the nomination will always succeed.
<= /blockquote>

But the spec says that the controlled side = SHOULD honor the nomination, which means it might not!=C2=A0 So that assump= tion is not correct (with the currently written text).
=C2=A0

Regards,

Christer

--94eb2c034350a1dcb30558941dde-- From nobody Thu Sep 7 00:49:05 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 84233132EBC for ; Thu, 7 Sep 2017 00:49:04 -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 7MFzTSHgY4rp for ; Thu, 7 Sep 2017 00:49:02 -0700 (PDT) Received: from sesbmg22.ericsson.net (sesbmg22.ericsson.net [193.180.251.48]) (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 13E4F132EC1 for ; Thu, 7 Sep 2017 00:49:01 -0700 (PDT) X-AuditID: c1b4fb30-96f7a9c000005897-d0-59b0f9ebed03 Received: from ESESSHC010.ericsson.se (Unknown_Domain [153.88.183.48]) by sesbmg22.ericsson.net (Symantec Mail Security) with SMTP id 52.E1.22679.BE9F0B95; Thu, 7 Sep 2017 09:49:00 +0200 (CEST) Received: from ESESSMB109.ericsson.se ([169.254.9.194]) by ESESSHC010.ericsson.se ([153.88.183.48]) with mapi id 14.03.0352.000; Thu, 7 Sep 2017 09:48:59 +0200 From: Christer Holmberg To: Peter Thatcher , Bernard Aboba CC: ICE WG Thread-Topic: [Ice] I updated PR 38 and I have a question about nomination/selection Thread-Index: AQHTJ3IRYv+AapMhGE+46WiPlX+3FqKo0jyAgAA6OYD//9MNAIAAPz6A Date: Thu, 7 Sep 2017 07:48:58 +0000 Message-ID: References: In-Reply-To: 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.19] Content-Type: multipart/alternative; boundary="_000_D5D6D194211CAchristerholmbergericssoncom_" MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFtrCIsWRmVeSWpSXmKPExsUyM2K7ge6bnxsiDSb/ZbbYsO8/s8W3C7UW 15a/ZnVg9tg56y67x4JNpR5LlvxkCmCO4rJJSc3JLEst0rdL4Mo49WMbc8G85YwVU64vYG1g XNbL2MXIySEhYCJxZVkTWxcjF4eQwBFGie9vljJDOIsZJdasWsbSxcjBwSZgIdH9TxukQUQg ROL9r/PMIDazgKTE2s9L2UFKhAVCJR7sFwMxRQTCJJp320FUu0lcO7GFHcRmEVCRODH9EVgn r4C1RNeP5YwQmyYwSax+8YENJMEpEChxdvMzVhCbUUBM4vupNUwQq8Qlbj2ZzwRxs4DEkj0Q J0gIiEq8fPyPFWSvqICexLv9nhBhRYn2pw2MEK0JEm2Tr0LtFZQ4OfMJywRG0VlIps5CUjYL SRlE3EDi/bn5zBC2tsSyha+hbH2JjV/OMkLY1hLvH15mR1azgJFjFaNocWpxUm66kZFealFm cnFxfp5eXmrJJkZgXB7c8ttgB+PL546HGAU4GJV4eM/82BApxJpYVlyZe4hRgoNZSYS34jtQ iDclsbIqtSg/vqg0J7X4EKM0B4uSOK/jvgsRQgLpiSWp2ampBalFMFkmDk6pBsakHef5mi+8 t6/Jvi/B5D11Scov/5zY7Ud3d7sapOjmXwrgiXbqm+Ers8vgT6fVfLcHvxUuX3igIyHq0nyk Yob+Ka6miYwMqp+nevpP2SLhdm9CqtOrlq/JKttPTpnbWGD+OaO6qeijicqCa/PT0s+UW7HP 2Xdj9hW1DTXrHCX9LCtSw4zNVZVYijMSDbWYi4oTAcRDr1PHAgAA Archived-At: Subject: Re: [Ice] I updated PR 38 and I have a question about nomination/selection 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, 07 Sep 2017 07:49:04 -0000 --_000_D5D6D194211CAchristerholmbergericssoncom_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable Hi, >Peter said: > >"And my question is this: Selection on the controlled side is only SHOULD= strength, meaning the controlled side can simply ignore nominations from t= he controlling side. Does that mean that controlled side can choose to neve= r select a candidate pair?" > >[BA] "Ignoring nominations" might mean several things: > >a. Not being prepared to receive on the selected pair. >b. Retaining resources outside the selected pair >c. Choosing to send on a validated pair other than the selected pair (pres= umably with consent) > >I would suggest that b) and c) are acceptable behaviors, but that a) is no= t. I don=92t think we should allow c). We can of course not prevent implementa= tions from doing so, but it should not be 5245bis-endorsed behaviour. We se= lect a pair, and then we use it. The spec as currently written only says that the controlled side SHOULD sel= ect. It doesn't say it MUST. So I believe C is allowed, as currently wr= itten. The spec might currently be unclear. For example, section 2.6 says: "Once the STUN transaction with the flag completes, both sides cancel any f= uture checks for that media stream. ICE will now send media using this pair. The pair an ICE agent is using for= media is called the SELECTED PAIR." To me that sounds like both endpoints will use the nominated pair. > "And if an agent never selects a candidate pair, can it not always send o= n any valid candidate pair of its choosing?" > >[BA] Without nomination *either* controlled or controlling sides can send = on any valid candidate pair, and there is not even a requirement for symmet= ry. It is even possible for either side to simultaneously send streams on d= ifferent valid candidate pairs (e.g. multi-path RTP). I am not sure whether the intent ever was to allow simultaneous streams. If it=92s needed, I think some ICE-considerations-for-multipath-RTP should = enhance ICE, and define how multiple pairs can be used both before and afte= r nomination (or specify that nomination is never done). As far as 5245bis = is concerned, I think we should say that only one pair is used at any given= time, and that the controlling endpoint MUST nominate within a =93reasonab= le=94 time. I'm not talking about nomination. I'm talking about the controlled side se= lecting or not (which is currently SHOULD strength). I am not sure what you mean by =93the controlled side selecting=94. The sel= ection is done by the controlling side, when nominating. That is also written in the definition of =93controlled agent=94: "Controlled Agent: An ICE agent that waits for the controlling agent to select the final choice of candidate pairs." I assume you are talking about the controlled side not =93accepting=94 the = selection. But, as I said earlier, I don=92t think the scenario is covered = in the 5245bis. The text seems to assume that the selection done by the con= trolling endpoint will always succeed. I have to admit that, since the removal of aggressive nomination, I fail to= see the difference between =93nomination=94 and =93selection=94. Since you= are only going to nominate once, it=92s basically the same thing, isn=92t = it? But you're right that as currently written, the controlling side could also= choose not to select. I don't know how you'd define a "reasonable" time. = What if ICE candidates keep trickling in with trickle ICE? >Either side can release resources by refusing consent on a candidate that = they would prefer not to receive with, or by no longer requesting consent f= or a candidate they no longer wish to send with. > >The downside is the potential for consent failures that RFC 7675 insists r= esults in pair invalidation. So if you don't want to keep a WWAN interface = up to save power, unless there is a way to explicitly "remove" and then "ad= d" it back, then candidates involving that >interface will be released. TURN mobility offers a way to quickly bring up= media flow using an awakened interface, but if all other pairs involving t= hat interface have been invalidated, then you're stuck with the relay candi= date unless you do an ICE restart. Ugh. >"In other words, if an agent chooses to ignore all nominations and never s= elect a candidate pair, but instead to send on candidate pairs without sele= cting them and switch between candidate pairs as its sees fit, is that agen= t still spec-compliant?" > >[BA] I think it's ok for the controlling side not to nominate a pair, but = if it does, then the controlled side needs to be prepared to receive on tha= t pair. And if it isn=92t, it shouldn=92t reply to the nomination request. Now, THA= T is not really covered in the spec =96 That's exactly my point. The spec does not outline any way for the control= ling side to know that the controlled side honored its nomination or not by= selecting. If the controlling endpoint does not receive a reply to the STUN request wi= th the nomination flag set, it should assume that the controlled endpoint d= id not honour the nomination. But, again, I don=92t think the spec says any= thing about that. In fact, the text in section 7.1.1 seems to assume that n= omination will always work: "Once the controlling agent has selected a valid pair for nomination, it repeats the connectivity check that produced this valid pair (by enqueueing the pair that generated the check into the TRIGGERED CHECK QUEUE), this time with the USE-CANDIDATE attribute. The connectivity check should succeed (since the previous did), causing the nominated flag value of that and only that pair to be set to true." the assumption seems to be that, as the nominated pair is in the valid list= , the nomination will always succeed. But the spec says that the controlled side SHOULD honor the nomination, whi= ch means it might not! So that assumption is not correct (with the current= ly written text). I think we need to forbid that =96 either by saying that the controlled end= point MUST honour the nomination, OR by defining how the controlled endpoin= t can explicitly indicate that it didn=92t honour. Regards, Christer --_000_D5D6D194211CAchristerholmbergericssoncom_ Content-Type: text/html; charset="Windows-1252" Content-ID: Content-Transfer-Encoding: quoted-printable
Hi,

>Peter said: 
>
>"And my question is this: &n= bsp;Selection on the controlled side is only SHOULD strength, meaning the c= ontrolled side can simply ignore nominations from the controlling side.&nbs= p;Does that mean that controlled side can choose to never select a candidate pair?"
>
>[BA] "Ignoring nominations&q= uot; might mean several things: 
>
>a. Not being prepared to receive = on the selected pair. 
>b. Retaining resources outside th= e selected pair
>c. Choosing to send on a validate= d pair other than the selected pair (presumably with consent)
>
>I would suggest that b) and c) ar= e acceptable behaviors, but that a) is not. 

I don=92t think we should allow c). We can of course not prevent imple= mentations from doing so, but it should not be 5245bis-endorsed behaviour. = We select a pair, and then we use it.

The spec as currently written only says that the controlled side SHOUL= D select.  It doesn't say it MUST.    So I believe C is allo= wed, as currently written.

The spec might currently be unclear.

For example, section 2.6 says:

"Once the STUN transaction with the flag completes, both sides cance= l any future checks for that media stream.  
ICE will now send media using this pair. The pair an ICE agent is using for media = is called the SELECTED PAIR."

To me that sounds like both endpoints will use= the nominated pair.
 

> "And if an agent never sele= cts a candidate pair, can it not always send on any valid candidate pair of= its choosing?"
>
>[BA] Without nomination *either* = controlled or controlling sides can send on any valid candidate pair, and t= here is not even a requirement for symmetry. It is even possible for either= side to simultaneously send streams on different valid candidate pairs  (e.g. multi-path RTP).

I am not sure whether the intent ever was to allow simultaneous stream= s. 

If it=92s needed, I think some ICE-considerations-for-multipath-RTP sh= ould enhance ICE, and define how multiple pairs can be used both before and= after nomination (or specify that nomination is never done). As far as 524= 5bis is concerned, I think we should say that only one pair is used at any given time, and that the controlling= endpoint MUST nominate within a =93reasonable=94 time.

I'm not talking about nomination.  I'm talking about the controll= ed side selecting or not (which is currently SHOULD strength).  

I am not sure what= you mean by =93the controlled side selecting=94. The selection i= s done by the controlling side, when nominating.

That is also writt= en in the definition of =93controlled agent=94:

      &quo=
t;Controlled Agent:  An ICE agent that waits for the controlling agent
      to select the final choice of candidate pairs."

I assume you are t= alking about the controlled side not =93accepting=94 the selection. Bu= t, as I said earlier, I don=92t think the scenario is covered in the 5245bi= s. The text seems to assume that the selection done by the controlling endpoint will always succeed.

I have to admit th= at, since the removal of aggressive nomination, I fail to see the differenc= e between =93nomination=94 and =93selection=94. Since you are onl= y going to nominate once, it=92s basically the same thing, isn=92t it? 


But you're right that as currently written, the controlling side could= also choose not to select.  I don't know how you'd define a "rea= sonable" time.  What if ICE candidates keep trickling in with tri= ckle ICE?
 
>Either side can release resources= by refusing consent on a candidate that they would prefer not to receive w= ith, or by no longer requesting consent for a candidate they no longer wish= to send with. 
>
>The downside is the potential for= consent failures that RFC 7675 insists results in pair invalidation. So if= you don't want to keep a WWAN interface up to save power, unless there is = a way to explicitly "remove" and then "add" it back, then candidates involving that
>interface will be released. TURN = mobility offers a way to quickly bring up media flow using an awakened inte= rface, but if all other pairs involving that interface have been invalidate= d, then you're stuck with the relay candidate unless you do an ICE restart.  Ugh. 

>"In other words, if an agent= chooses to ignore all nominations and never select a candidate pair, but i= nstead to send on candidate pairs without selecting them and switch between= candidate pairs as its sees fit, is that agent still spec-compliant?"
>
>[BA] I think it's ok for the controlling side not to nominate a pa= ir, but if it does, then the controlled side needs to be prepared to receiv= e on that pair. 

And if it isn=92t, it shouldn=92t reply to the nomination request. Now= , THAT is not really covered in the spec =96

That's exactly my point.  The spec does not outline any way for t= he controlling side to know that the controlled side honored its nomination= or not by selecting.  

If the controlling= endpoint does not receive a reply to the STUN request with the nomination = flag set, it should assume that the controlled endpoint did not honour= the nomination. But, again, I don=92t think the spec says anything about that. In fact, the text in section 7.1.1 seem= s to assume that nomination will always work:
   "O=
nce the controlling agent has selected a valid pair for nomination,
   it repeats the connectivity check that produced this valid pair (by
   enqueueing the pair that generated the check into the TRIGGERED CHECK
   QUEUE), this time with the USE-CANDIDATE attribute.  The connectivity
   check should succeed (since the previous did), causing the nominated
   flag value of that and only that pair to be set to true." 
the assumption seems to be that, as the nominated pair is in the valid= list, the nomination will always succeed.

But the spec says that the controlled side SHOULD honor the nomination= , which means it might not!  So that assumption is not correct (with t= he currently written text).

I think we need to forbid that =96 either by s= aying that the controlled endpoint MUST honour the nomination, OR by defini= ng how the controlled endpoint can explicitly indicate that it didn=92t hon= our.

Regards,

Christer

 --_000_D5D6D194211CAchristerholmbergericssoncom_-- From nobody Thu Sep 7 00:50: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 83D46132EBC for ; Thu, 7 Sep 2017 00:50:40 -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 WWKi6ypF5w5Y for ; Thu, 7 Sep 2017 00:50:38 -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 D434B132D8E for ; Thu, 7 Sep 2017 00:50:37 -0700 (PDT) X-AuditID: c1b4fb3a-617ff700000051a3-af-59b0fa4b6f2c Received: from ESESSHC017.ericsson.se (Unknown_Domain [153.88.183.69]) by sessmg22.ericsson.net (Symantec Mail Security) with SMTP id 55.8E.20899.B4AF0B95; Thu, 7 Sep 2017 09:50:36 +0200 (CEST) Received: from ESESSMB109.ericsson.se ([169.254.9.194]) by ESESSHC017.ericsson.se ([153.88.183.69]) with mapi id 14.03.0352.000; Thu, 7 Sep 2017 09:50:35 +0200 From: Christer Holmberg To: Bernard Aboba , Peter Thatcher CC: ICE WG Thread-Topic: [Ice] I updated PR 38 and I have a question about nomination/selection Thread-Index: AQHTJ3IRYv+AapMhGE+46WiPlX+3FqKo0jyAgABM+AA= Date: Thu, 7 Sep 2017 07:50:35 +0000 Message-ID: References: In-Reply-To: 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.16] Content-Type: multipart/alternative; boundary="_000_D5D6D5CE211EFchristerholmbergericssoncom_" MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFlrPIsWRmVeSWpSXmKPExsUyM2K7q67Prw2RBkfecVts2Pef2eLbhVqL a8tfszowe+ycdZfdY8GmUo8lS34yBTBHcdmkpOZklqUW6dslcGW8PnCOvWCNQsXBuXfYGhiv SHcxcnBICJhIfLgm3MXIySEkcIRRYu6RoC5GLiB7MaPEhV9zWUBq2AQsJLr/aYPUiAiESLyb fogVxGYWkJRY+3kpO0iJsECoxIP9YiCmiECYRPNuO4hqK4nvTx+wgdgsAioSq+f+ZAKxeQWs JY50nWGF2DSdUWL2mU5mkASnQKBE88tTYA2MAmIS30+tYYJYJS5x68l8MFtCQEBiyZ7zzBC2 qMTLx/9YQfaKCuhJvNvvCRFWlNh5tp0ZojVB4tnE+YwQewUlTs58wjKBUXQWkqmzkJTNQlIG ETeQeH9uPjOErS2xbOFrKFtfYuOXs0D1HEC2tcTmCanIShYwcqxiFC1OLS7OTTcy0kstykwu Ls7P08tLLdnECIzGg1t+W+1gPPjc8RCjAAejEg/vrJ8bIoVYE8uKK3MPMUpwMCuJ8FZ8Bwrx piRWVqUW5ccXleakFh9ilOZgURLnddh3IUJIID2xJDU7NbUgtQgmy8TBKdXA6Jil+PDZnyuF gb8SWldx3e1l5Pgl/ejwRHXXPxtWBxXtNz3f1KbhbCPMq7XwwJaJX6rW+Li7bRBvWTpj5oHD SwujjBxmfrrEt6BfKaVRP1A/SLZsRrt/NXfHBfM91wrebwhL8ar5ZXZ+1usq5boZD+/3BMrz XJko9KvDYr3OnSUx8TvvebyLUGIpzkg01GIuKk4EAFWoCRDCAgAA Archived-At: Subject: Re: [Ice] I updated PR 38 and I have a question about nomination/selection 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, 07 Sep 2017 07:50:40 -0000 --_000_D5D6D5CE211EFchristerholmbergericssoncom_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable Hi, =85 [BA] Without nomination *either* controlled or controlling sides can send o= n any valid candidate pair, and there is not even a requirement for symmetr= y. It is even possible for either side to simultaneously send streams on di= fferent valid candidate pairs (e.g. multi-path RTP). In fact, the spec currently DOES forbid simultaneous steams: Selected Pair, Selected Candidate: The candidate pair selected by ICE for sending and receiving media is called the selected pair, and each of its candidates is called the selected candidate. Before a pair has been selected, any valid candidate pair can be used for sending and receiving media (only one candidate pair at any given time). Regards, Christer --_000_D5D6D5CE211EFchristerholmbergericssoncom_ Content-Type: text/html; charset="Windows-1252" Content-ID: <96FD81E258E7D34AAD305F1401BBDE82@ericsson.com> Content-Transfer-Encoding: quoted-printable
Hi,

=85

[BA] Without nomination *either* control= led or controlling sides can send on any valid candidate pair, and there is= not even a requirement for symmetry. It is even possible for either side t= o simultaneously send streams on different valid candidate pairs  (e.g. multi-path RTP). 

I= n fact, the spec currently DOES forbid = simultaneou= s steams:
      Sele=
cted Pair, Selected Candidate:  The candidate pair selected by
      ICE for sending and receiving media is called the selected pair,
      and each of its candidates is called the selected candidate.
      Before a pair has been selected, any valid candidate pair can be
      used for sending and receiving media (only one candidate pair at
      any given time).
Regards,

Christer

--_000_D5D6D5CE211EFchristerholmbergericssoncom_-- From nobody Thu Sep 7 00:52:53 2017 Return-Path: X-Original-To: ice@ietfa.amsl.com Delivered-To: ice@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7A4CC132EC4 for ; Thu, 7 Sep 2017 00:52:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.219 X-Spam-Level: X-Spam-Status: No, score=-4.219 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, 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 EaPT3EZSjgPL for ; Thu, 7 Sep 2017 00:52:50 -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 9E512132EBC for ; Thu, 7 Sep 2017 00:52:49 -0700 (PDT) X-AuditID: c1b4fb25-967ff70000005333-34-59b0facf18f2 Received: from ESESSHC019.ericsson.se (Unknown_Domain [153.88.183.75]) by sesbmg23.ericsson.net (Symantec Mail Security) with SMTP id 06.71.21299.FCAF0B95; Thu, 7 Sep 2017 09:52:48 +0200 (CEST) Received: from ESESSMB109.ericsson.se ([169.254.9.194]) by ESESSHC019.ericsson.se ([153.88.183.75]) with mapi id 14.03.0352.000; Thu, 7 Sep 2017 09:52:47 +0200 From: Christer Holmberg To: Peter Thatcher , ICE WG Thread-Topic: [Ice] I updated PR 38 and I have a question about nomination/selection Thread-Index: AQHTJ3IRYv+AapMhGE+46WiPlX+3FqKpBIwA///W0ICAAER0gA== Date: Thu, 7 Sep 2017 07:52:46 +0000 Message-ID: References: In-Reply-To: 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.16] Content-Type: multipart/alternative; boundary="_000_D5D6D647211F5christerholmbergericssoncom_" MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFprJIsWRmVeSWpSXmKPExsUyM2K7t+6FXxsiDS7pWny7UGtxbflrVgcm jwWbSj2WLPnJFMAUxWWTkpqTWZZapG+XwJWxsoWlYIlFxZllF1gbGNcbdDFyckgImEj86l3A 3sXIxSEkcIRR4uXXFkYIZzGjxKTJL5i6GDk42AQsJLr/aYOYIgIOEg1H40BMYYFQiQf7xSCi YRLNu+1AJooIOEncbdnLCmKzCKhILH9/ix3E5hWwllh48AArxPCTjBKXd+0GS3AKBEpM3vKA BcRmFBCT+H5qDROIzSwgLnHryXwmiDMFJJbsOc8MYYtKvHz8jxVkr6iAnsS7/Z4QYUWJnWfb mSFaEyRaP29nhNgrKHFy5hOWCYwis5BMnYWkbBaSMoi4gcT7c/OZIWxtiWULX0PZ+hIbv5xl hLCtJeacPsWCrGYBI8cqRtHi1OKk3HQjY73Uoszk4uL8PL281JJNjMAIO7jlt+oOxstvHA8x CnAwKvHwKv/YECnEmlhWXJl7iFGCg1lJhLfiO1CINyWxsiq1KD++qDQntfgQozQHi5I4r+O+ CxFCAumJJanZqakFqUUwWSYOTqkGRsXXdmlnT3F5G1j+ZP0YLfL7/3QT7YdvveWfXGlwvHzq 3e26R7O6jj+SVL2sKWm50pvja8yz+yX3gy91sEsyv/01q2o6201Wwc2MFT4For4LjvU/CeKc bvrlrSurS4/a5t4bNzTds08cvFawK+5jVMOVSL3W8A2Hw5yDf/gbVNxefXT360nFa5RYijMS DbWYi4oTAQfRMzysAgAA Archived-At: Subject: Re: [Ice] I updated PR 38 and I have a question about nomination/selection 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, 07 Sep 2017 07:52:51 -0000 --_000_D5D6D647211F5christerholmbergericssoncom_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable Hi, >The spec says nothing about accepting or rejecting a nomination. You are = correct that once a pair is selected, the spec says, but the spec does not = say that the controlling side needs to either accept or reject a nomination= . It can simply ignore it and still be compliant (according to my reading = of the document). IF we allow it to ignore it, I think the controlling endpoint needs to be i= nformed about it. Regards, Christer On Wed, Sep 6, 2017 at 11:15 PM Christer Holmberg > wrote: Hi, If the controlled side, for whatever reason, doesn=92t accept the nominatio= n, it should reject the nomination request. In my opinion, once a pair has = been selected, it must be used. Regards, Christer From: Ice > on behalf of = "pthatcher@google.com" > Date: Thursday 7 September 2017 at 03:41 To: "ice@ietf.org" > Subject: [Ice] I updated PR 38 and I have a question about nomination/selec= tion I updated https://github.com/ice-wg/rfc5245bis/pull/38/files from all of th= e comments at IETF 99. I think I have everything resolved except for the w= hole "when can you free a candidate" thing. Take a look for more details= . And my question is this: Selection on the controlled side is only SHOULD s= trength, meaning the controlled side can simply ignore nominations from the= controlling side. Does that mean that controlled side can choose to never= select a candidate pair? And if an agent never selects a candidate pair, = can it not always send on any valid candidate pair of its choosing? In other words, if an agent chooses to ignore all nominations and never sel= ect a candidate pair, but instead to send on candidate pairs without select= ing them and switch between candidate pairs as its sees fit, is that agent = still spec-compliant? --_000_D5D6D647211F5christerholmbergericssoncom_ Content-Type: text/html; charset="Windows-1252" Content-ID: <7ED173B55136C54B814E38AFEFA51EAC@ericsson.com> Content-Transfer-Encoding: quoted-printable
Hi,

>The spec says nothing about accepting or rejecting a n= omination.  You are correct that once a pair is selected, the spec say= s, but the spec does not say that the controlling side needs to either acce= pt or reject a nomination.  It can simply ignore it and still be compliant (according to my reading of the document)= .

IF we allow it to ignore it, I think the contr= olling endpoint needs to be informed about it.

Regards,

Christer



On Wed, Sep 6, 2017 at 11:15 PM Christer Holmberg <christer.holmberg@ericsson.co= m> wrote:
Hi,

If the controlled side, for whatever reason, doesn=92t accept the nomi= nation, it should reject the nomination request. In my opinion, once a pair= has been selected, it must be used.

Regards,

Christer

From: Ice <ice-bounces@ietf.org> on behalf= of "pthatch= er@google.com" <pthatcher@google.com>
Date: Thursday 7 September 2017 at = 03:41
To: "ice@ietf.org" <ice@ietf.org>
Subject: [Ice] I updated PR 38 and = I have a question about nomination/selection

I updated https://github.com/ice-wg/rfc5245bis/= pull/38/files from all of the comments at IETF 99.  I think I= have everything resolved except for the whole "when can you free a candidate" thing.    Take a look for more de= tails.

And my question is this:  Selection on the controlled side is onl= y SHOULD strength, meaning the controlled side can simply ignore nomination= s from the controlling side.  Does that mean that controlled side can = choose to never select a candidate pair?  And if an agent never selects a candidate pair, can it not always send on = any valid candidate pair of its choosing?   

In other words, if an agent chooses to ignore all nominations and neve= r select a candidate pair, but instead to send on candidate pairs without s= electing them and switch between candidate pairs as its sees fit, is that a= gent still spec-compliant?
 --_000_D5D6D647211F5christerholmbergericssoncom_-- From nobody Thu Sep 7 08:30: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 510E8132F78 for ; Thu, 7 Sep 2017 08:30:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=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=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 Y8iGc7N01XHW for ; Thu, 7 Sep 2017 08:30:36 -0700 (PDT) Received: from mail-qt0-x234.google.com (mail-qt0-x234.google.com [IPv6:2607:f8b0:400d:c0d::234]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id F3FA8132F4B for ; Thu, 7 Sep 2017 08:30:35 -0700 (PDT) Received: by mail-qt0-x234.google.com with SMTP id m35so179114qte.1 for ; Thu, 07 Sep 2017 08:30: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=nhG83a07ZkRvzaXAHO2TPbe3FsN7NfjguzW9p7glTIU=; b=extFLHMadMcd6/977JECMh55XfdYMHO0r0wxL6KaM4muapEQeJrNVqnCi4i3Eim0B4 X4Wj72+jPE6xle3wJFCebV9IAkDfIcDvPu1Uk2CiY6cxI1ngDxH5v1pFdh3EsVS5Tr/4 vuQRaIb+tkMDrb8o8Rck7UwOr+461K9GRbP3scv3LrCyWj8oN7SERzZm8cBJQjxiA8pv MEREEF2TgyXXY47rB2bZ/jQbRc9nb9MnPM2P7Q4OzurMz32ENNS1UTeAjUmrOQZgQQjP nZeLo3fxYWHohz/pjGJLE/bEcPrwBFofas5lqaSJKiqz2C3Crx6AHbPyQn4elq6PQACP 2v+Q== 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=nhG83a07ZkRvzaXAHO2TPbe3FsN7NfjguzW9p7glTIU=; b=evN0ngQMyVtgqo7hZlYKP9B5IdiMBcyalKm+OCOAVS46CiOspqQhP52t6Bncsj9whR EegNt1pa6wlckTJ5tG/Re6AYonDI/xPTeWBf8t4rgle+SbKxRiyMTddBzzkXZUmOyb8C DLNJyJaTOtiumwfT9l28/NR9KfPZqNbx/0sMO4iCBxXvwvBBae2kEO8DNMLnV9MaOqUC E5o+9dlAMrlaxosrSMPJqPj9gR6BmGkCGFQq938qC970IO1aARNhoIfs+9JF4BJDF4SI 3jXtTFfjz5TYYWuWzyFu3iTn+BUC2+pYkSpQF+UTAHO1hyJEhXKGnHASC/wBiLCuvQAj Rihw== X-Gm-Message-State: AHPjjUiyNcuanXugLcfwEE2XmlNO3Dv/WPfPljqM+ZSollWD3PlmZH81 ODNIAhEPop8NXH/luohqKAcf1LvUHGSQ X-Google-Smtp-Source: ADKCNb7ejoXx1H0edJnBMQeKFvjlzFevGKnsXnKh6gXMfNbuDMSOm/7t1R8o2uXLrGhY9Y/jLphctjJxUoL4Ptapuqg= X-Received: by 10.200.53.129 with SMTP id k1mr4133207qtb.243.1504798234894; Thu, 07 Sep 2017 08:30:34 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Peter Thatcher Date: Thu, 07 Sep 2017 15:30:24 +0000 Message-ID: To: Christer Holmberg , Bernard Aboba Cc: ICE WG Content-Type: multipart/alternative; boundary="001a113c294240738205589b243a" Archived-At: Subject: Re: [Ice] I updated PR 38 and I have a question about nomination/selection 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, 07 Sep 2017 15:30:38 -0000 --001a113c294240738205589b243a Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Thu, Sep 7, 2017 at 12:49 AM Christer Holmberg < christer.holmberg@ericsson.com> wrote: > Hi, > > >Peter said: >> > >> >"And my question is this: Selection on the controlled side is only >> SHOULD strength, meaning the controlled side can simply ignore nominatio= ns >> from the controlling side. Does that mean that controlled side can >> choose to never select a candidate pair?" >> > >> >[BA] "Ignoring nominations" might mean several things: >> > >> >a. Not being prepared to receive on the selected pair. >> >b. Retaining resources outside the selected pair >> >c. Choosing to send on a validated pair other than the selected pair >> (presumably with consent) >> > >> >I would suggest that b) and c) are acceptable behaviors, but that a) is >> not. >> >> I don=E2=80=99t think we should allow c). We can of course not prevent >> implementations from doing so, but it should not be 5245bis-endorsed >> behaviour. We select a pair, and then we use it. >> > > The spec as currently written only says that the controlled side SHOULD > select. It doesn't say it MUST. So I believe C is allowed, as current= ly > written. > > The spec might currently be unclear. > > For example, section 2.6 says: > > "Once the STUN transaction with the flag completes, both sides cancel any > future checks for that media stream. > ICE will now send media using this pair. The pair an ICE agent is using > for media is called the SELECTED PAIR." > > To me that sounds like both endpoints will use the nominated pair. > > Ah, you found it! I was looking for something like that and couldn't find it. That implies that a check response of a (non-aggressive) nomination implies that the controlled side has selected. OK, so that's a good answer to it. Except is that a MUST-level or a SHOULD-level behavior? Because elsewhere in the doc it's a SHOULD-level. So if it's MUST-level, there's a contradiction. >> > "And if an agent never selects a candidate pair, can it not always sen= d >> on any valid candidate pair of its choosing?" >> > >> >[BA] Without nomination *either* controlled or controlling sides can >> send on any valid candidate pair, and there is not even a requirement fo= r >> symmetry. It is even possible for either side to simultaneously send >> streams on different valid candidate pairs (e.g. multi-path RTP). >> >> I am not sure whether the intent ever was to allow simultaneous streams. >> >> If it=E2=80=99s needed, I think some ICE-considerations-for-multipath-RT= P should >> enhance ICE, and define how multiple pairs can be used both before and >> after nomination (or specify that nomination is never done). As far as >> 5245bis is concerned, I think we should say that only one pair is used a= t >> any given time, and that the controlling endpoint MUST nominate within a >> =E2=80=9Creasonable=E2=80=9D time. >> > > I'm not talking about nomination. I'm talking about the controlled side > selecting or not (which is currently SHOULD strength). > > I am not sure what you mean by =E2=80=9Cthe controlled side selecting=E2= =80=9D. The > selection is done by the controlling side, when nominating. > But elsewhere in the document, it says "The controlled agent SHOULD select the candidate pair", which means that the controlled side also selects. There are two selections. The flow is like this: 1. Controlling selects 2. Controlling nominates (although maybe #1 and #2 should be flipped?) 3. Controlled selects > That is also written in the definition of =E2=80=9Ccontrolled agent=E2=80= =9D: > > "Controlled Agent: An ICE agent that waits for the controlling age= nt > to select the final choice of candidate pairs." > > > I assume you are talking about the controlled side not =E2=80=9Caccepting= =E2=80=9D the > selection. But, as I said earlier, I don=E2=80=99t think the scenario is = covered in > the 5245bis. The text seems to assume that the selection done by the > controlling endpoint will always succeed. > That's my point: we have a SHOULD-level phrase for something that we expect to have happen. But if it's SHOULD-level, what happens if it doesn't happen. > > I have to admit that, since the removal of aggressive nomination, I fail > to see the difference between =E2=80=9Cnomination=E2=80=9D and =E2=80=9Cs= election=E2=80=9D. Since you are > only going to nominate once, it=E2=80=99s basically the same thing, isn= =E2=80=99t it? > > Nomination means "you SHOULD select this", so it's not the same. > > But you're right that as currently written, the controlling side could > also choose not to select. I don't know how you'd define a "reasonable" > time. What if ICE candidates keep trickling in with trickle ICE? > > >> >> >Either side can release resources by refusing consent on a candidate >> that they would prefer not to receive with, or by no longer requesting >> consent for a candidate they no longer wish to send with. >> > >> >The downside is the potential for consent failures that RFC 7675 insist= s >> results in pair invalidation. So if you don't want to keep a WWAN interf= ace >> up to save power, unless there is a way to explicitly "remove" and then >> "add" it back, then candidates involving that >> >interface will be released. TURN mobility offers a way to quickly bring >> up media flow using an awakened interface, but if all other pairs involv= ing >> that interface have been invalidated, then you're stuck with the relay >> candidate unless you do an ICE restart. Ugh. >> >> >"In other words, if an agent chooses to ignore all nominations and neve= r >> select a candidate pair, but instead to send on candidate pairs without >> selecting them and switch between candidate pairs as its sees fit, is th= at >> agent still spec-compliant?" >> > >> >[BA] I think it's ok for the controlling side not to nominate a pair, >> but if it does, then the controlled side needs to be prepared to receive= on >> that pair. >> >> And if it isn=E2=80=99t, it shouldn=E2=80=99t reply to the nomination re= quest. Now, THAT >> is not really covered in the spec =E2=80=93 >> > > That's exactly my point. The spec does not outline any way for the > controlling side to know that the controlled side honored its nomination = or > not by selecting. > > If the controlling endpoint does not receive a reply to the STUN request > with the nomination flag set, it should assume that the controlled endpoi= nt > did not honour the nomination. But, again, I don=E2=80=99t think the spec= says > anything about that. In fact, the text in section 7.1.1 seems to assume > that nomination will always work: > > "Once the controlling agent has selected a valid pair for nomination, > it repeats the connectivity check that produced this valid pair (by > enqueueing the pair that generated the check into the TRIGGERED CHECK > QUEUE), this time with the USE-CANDIDATE attribute. The connectivity > check should succeed (since the previous did), causing the nominated > flag value of that and only that pair to be set to true." > > the assumption seems to be that, as the nominated pair is in the valid >> list, the nomination will always succeed. >> > > But the spec says that the controlled side SHOULD honor the nomination, > which means it might not! So that assumption is not correct (with the > currently written text). > > I think we need to forbid that =E2=80=93 either by saying that the contro= lled > endpoint MUST honour the nomination, OR by defining how the controlled > endpoint can explicitly indicate that it didn=E2=80=99t honour. > I agree. We should either make it MUST-level or we should define what happens if the controlled side doesn't select. > > Regards, > > Christer > > --001a113c294240738205589b243a Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


On Thu= , Sep 7, 2017 at 12:49 AM Christer Holmberg <christer.holmberg@ericsson.com> wrote:
Hi,

>Peter said:=C2=A0
>
>"And my question is this: = =C2=A0Selection on the controlled side is only SHOULD strength, meaning the= controlled side can simply ignore nominations from the controlling side.= =C2=A0Does that mean that controlled side can choose to never select a candidate pair?"
>
>[BA] "Ignoring nominations&q= uot; might mean several things:=C2=A0
>
>a. Not being prepared to receive = on the selected pair.=C2=A0
>b. Retaining resources outside th= e selected pair
>c. Choosing to send on a validate= d pair other than the selected pair (presumably with consent)
>
>I would suggest that b) and c) ar= e acceptable behaviors, but that a) is not.=C2=A0

I don=E2=80=99t think we should allow c). We can of course not prevent= implementations from doing so, but it should not be 5245bis-endorsed behav= iour. We select a pair, and then we use it.

The spec as currently written only says that the controlled side SHOUL= D select.=C2=A0 It doesn't say it MUST. =C2=A0 =C2=A0So I believe C is = allowed, as currently written.

The spec might currentl= y be unclear.

For example, section 2.6 says:

"Once the STUN transact= ion with the flag completes, both sides cancel any f= uture checks for that media stream. =C2=A0
ICE will now send media using this p= air. The pair an ICE agent is using for media is called the SELECTED= PAIR."

To me that sounds like both endpoints will use= the nominated pair.
=C2=A0

Ah, you found it!=C2=A0 I was looking = for something like that and couldn't find it.=C2=A0 That implies that a= check response of a (non-aggressive) nomination implies that the controlle= d side has selected.=C2=A0 OK, so that's a good answer to it.=C2=A0

Except is that a MUST-level or a SHOULD-level behavio= r?=C2=A0 Because elsewhere in the doc it's a SHOULD-level.=C2=A0 So if = it's MUST-level, there's a contradiction. =C2=A0



> "And if an agent never sele= cts a candidate pair, can it not always send on any valid candidate pair of= its choosing?"
>
>[BA] Without nomination *either* = controlled or controlling sides can send on any valid candidate pair, and t= here is not even a requirement for symmetry. It is even possible for either= side to simultaneously send streams on different valid candidate pairs =C2=A0(e.g. multi-path RTP).

I am not sure whether the intent ever was to allow simultaneous stream= s.=C2=A0

If it=E2=80=99s needed, I think some ICE-considerations-for-multipath-= RTP should enhance ICE, and define how multiple pairs can be used both befo= re and after nomination (or specify that nomination is never done). As far = as 5245bis is concerned, I think we should say that only one pair is used at any given time, and that the controlling= endpoint MUST nominate within a =E2=80=9Creasonable=E2=80=9D time.

I'm not talking about nomination.=C2=A0 I'm talking about the = controlled side selecting or not (which is currently SHOULD strength). =C2= =A0

I am not sure what you mean by=C2=A0=E2=80=9Cthe co= ntrolled side selecting=E2=80=9D.=C2=A0The selection is done by the control= ling side, when nominating.

<= div>But elsewhere in the document, it says "The controlled agent SHOUL= D select the candidate pair", which means that the controlled side als= o selects.=C2=A0 There are two selections.=C2=A0 The flow is like this:

1.=C2=A0 Controlling selects
2.=C2=A0 Contr= olling nominates =C2=A0(although maybe #1 and #2 should be flipped?)
<= div>3.=C2=A0 Controlled selects


That is also writt= en in the definition of=C2=A0=E2=80=9Ccontrolled agent=E2=80=9D: 

      "Controlled Agent:  An ICE a=
gent that waits for the controlling agent
      to select the final choice of candidate pairs."

I assume you are t= alking about the controlled side not=C2=A0=E2=80=9Caccepting=E2=80=9D the s= election. But, as I said earlier, I don=E2=80=99t think the scenario is cov= ered in the 5245bis. The text seems to assume that the selection done by the controlling endpoint will always succeed.

That's my point: we have a SHOULD-level = phrase for something that we expect to have happen.=C2=A0 But if it's S= HOULD-level, what happens if it doesn't happen. =C2=A0
=C2=A0=

I have to admit th= at, since the removal of aggressive nomination, I fail to see the differenc= e between=C2=A0=E2=80=9Cnomination=E2=80=9D and=C2=A0=E2=80=9Cselection=E2= =80=9D. Since you are only going to nominate once, it=E2=80=99s basically t= he same thing, isn=E2=80=99t it?=C2=A0

<= /div>

Nomination means "you SHOULD sel= ect this", so it's not the same.
=C2=A0

But you're right that as currently written, the controlling side c= ould also choose not to select.=C2=A0 I don't know how you'd define= a "reasonable" time.=C2=A0 What if ICE candidates keep trickling= in with trickle ICE?
=C2=A0
>Either side can release resources= by refusing consent on a candidate that they would prefer not to receive w= ith, or by no longer requesting consent for a candidate they no longer wish= to send with.=C2=A0
>
>The downside is the potential for= consent failures that RFC 7675 insists results in pair invalidation. So if= you don't want to keep a WWAN interface up to save power, unless there= is a way to explicitly "remove" and then "add" it back, then candidates involving that
>interface will be released. TURN = mobility offers a way to quickly bring up media flow using an awakened inte= rface, but if all other pairs involving that interface have been invalidate= d, then you're stuck with the relay candidate unless you do an ICE restart.=C2=A0 Ugh.=C2=A0

>"In other words, if an agent= chooses to ignore all nominations and never select a candidate pair, but i= nstead to send on candidate pairs without selecting them and switch between= candidate pairs as its sees fit, is that agent still spec-compliant?"
>
>[BA] I think it's ok for the controlling side not to nominate = a pair, but if it does, then the controlled side needs to be prepared to re= ceive on that pair.=C2=A0

And if it isn=E2=80=99t, it shouldn=E2=80=99t reply to the nomination = request. Now, THAT is not really covered in the spec =E2=80=93

That's exactly my point.=C2=A0 The spec does not outline any way f= or the controlling side to know that the controlled side honored its nomina= tion or not by selecting. =C2=A0

If the controlling= endpoint does not receive a reply to the STUN request with the nomination = flag set, it should assume that the controlled endpoint did not=C2=A0honour= the nomination.=C2=A0But, again, I don=E2=80=99t think the spec says anything about that. In fact, the text in section 7.1.1 seem= s to assume that nomination will always work:
   "Once the controlling agent has=
 selected a valid pair for nomination,
   it repeats the connectivity check that produced this valid pair (by
   enqueueing the pair that generated the check into the TRIGGERED CHECK
   QUEUE), this time with the USE-CANDIDATE attribute.  The connectivity
   check should succeed (since the previous did), causing the nominated
   flag value of that and only that pair to be set to true."=C2=A0
the assumption seems to be that, as the nominated pair is in the valid= list, the nomination will always succeed.

But the spec says that the controlled side SHOULD honor the nomination= , which means it might not!=C2=A0 So that assumption is not correct (with t= he currently written text).

I th= ink we need to forbid that =E2=80=93 either by saying that the controlled e= ndpoint MUST honour the nomination, OR by defining how the controlled endpo= int can explicitly indicate that it didn=E2=80=99t honour.

I agree.=C2=A0 We should either make it = MUST-level or we should define what happens if the controlled side doesn= 9;t select.
=C2=A0

Regards,

Christer
--001a113c294240738205589b243a-- From nobody Thu Sep 7 08:35:53 2017 Return-Path: X-Original-To: ice@ietfa.amsl.com Delivered-To: ice@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 67479132C3F for ; Thu, 7 Sep 2017 08:35:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.699 X-Spam-Level: X-Spam-Status: No, score=-2.699 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, 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 QgWeFWGIGxga for ; Thu, 7 Sep 2017 08:35:48 -0700 (PDT) Received: from mail-qk0-x233.google.com (mail-qk0-x233.google.com [IPv6:2607:f8b0:400d:c09::233]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 95FE313219F for ; Thu, 7 Sep 2017 08:35:48 -0700 (PDT) Received: by mail-qk0-x233.google.com with SMTP id r141so160050qke.2 for ; Thu, 07 Sep 2017 08:35:48 -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=U+oc1ytq8ZVjIc3ZsT2dai0cYppYKf22KQyDt6iiYvk=; b=i9XB97QciRV5qUJOoccVC/X0sI/knLkWMhRpeRrCpMJScXfBQkQtyLv1A0d5pqsLw0 WWFulduOQurRJVkOI18VDj1wj81Vc2f11RW08qKd+8rvDcXmB52amunCNui+nV5+8Q/O ha3VaxXntrcRyvZzGxMjEMBfcYMJHzuwpMrxDhz671baogzjQuCX+hnyYhJbOzQg04QQ PX85+Kf/dmW08AKZ2XvUtX7FoyXFBtZo92+yCy4Uq1suaAXg24pywKvKEzaFkaqmyBPa dD1t0n4SJqDpMAt/ngoDPcHF+cPqRAg+ErTaQZWp2Gj7D17kC7cxMka5Ve/xEYYCbeP7 a5FA== 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=U+oc1ytq8ZVjIc3ZsT2dai0cYppYKf22KQyDt6iiYvk=; b=rhsgs2NEFFoSRvnTfIZZhezHWwTIHdiX8hdMifURXcJwpuTlojdR8EbWWOl+nvVGtR TCiUeVczwXP1NTNLXBvRmwWztNudznAp3Dl/a1NosIGJVrq8po8k2wAm4l/MfYcNcOIp n834BA+7JPfamzuKRcJotwo90ULfgp+8sbrrdry0aVP4rvCrJtsjgO6QOesgIiT76m1H yd2nPEszsdIGWItnDvKeyl4rK3fmMVqXDfNG1b/fIikw3sBnb3U8lOEeec76u19qI4tf pVQhrCOL96M1sQW5laathr+4DNddmXYkqfhcMY7Uxoa95P78eE8XHosU/voxdIpAiZPz PzmA== X-Gm-Message-State: AHPjjUgAWLANeJKfo1hHIaEE20MVBtfaBTvv0NUADcLVZjzRwv5uFBwo MzkGpusUOQd/3K9vj56yEPI5pIAnti5R X-Google-Smtp-Source: ADKCNb5SucrhfLam3w01ZSgoNAL7AW+OVGPsOV3Sw2Ql42yVLrQdqW2aAxNj1ypXx/+6MLVeK0pPYkivhNO4n/83Yb8= X-Received: by 10.55.109.66 with SMTP id i63mr3972038qkc.19.1504798547586; Thu, 07 Sep 2017 08:35:47 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Peter Thatcher Date: Thu, 07 Sep 2017 15:35:35 +0000 Message-ID: To: Christer Holmberg , Bernard Aboba Cc: ICE WG Content-Type: multipart/alternative; boundary="94eb2c05c2a6e3d40705589b36f3" Archived-At: Subject: Re: [Ice] I updated PR 38 and I have a question about nomination/selection 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, 07 Sep 2017 15:35:51 -0000 --94eb2c05c2a6e3d40705589b36f3 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable And a similar issue not covered: if the STUN transaction with the nomination flag doesn't succeed (say the network goes out for a while). Then what? I think it means we're in a "half-selected" state (the controlling side has selected but not the controlled side). Is that OK? On Thu, Sep 7, 2017 at 8:30 AM Peter Thatcher wrote: > On Thu, Sep 7, 2017 at 12:49 AM Christer Holmberg < > christer.holmberg@ericsson.com> wrote: > >> Hi, >> >> >Peter said: >>> > >>> >"And my question is this: Selection on the controlled side is only >>> SHOULD strength, meaning the controlled side can simply ignore nominati= ons >>> from the controlling side. Does that mean that controlled side can >>> choose to never select a candidate pair?" >>> > >>> >[BA] "Ignoring nominations" might mean several things: >>> > >>> >a. Not being prepared to receive on the selected pair. >>> >b. Retaining resources outside the selected pair >>> >c. Choosing to send on a validated pair other than the selected pair >>> (presumably with consent) >>> > >>> >I would suggest that b) and c) are acceptable behaviors, but that a) i= s >>> not. >>> >>> I don=E2=80=99t think we should allow c). We can of course not prevent >>> implementations from doing so, but it should not be 5245bis-endorsed >>> behaviour. We select a pair, and then we use it. >>> >> >> The spec as currently written only says that the controlled side SHOULD >> select. It doesn't say it MUST. So I believe C is allowed, as curren= tly >> written. >> >> The spec might currently be unclear. >> >> For example, section 2.6 says: >> >> "Once the STUN transaction with the flag completes, both sides cancel an= y >> future checks for that media stream. >> ICE will now send media using this pair. The pair an ICE agent is using >> for media is called the SELECTED PAIR." >> >> To me that sounds like both endpoints will use the nominated pair. >> >> > > Ah, you found it! I was looking for something like that and couldn't fin= d > it. That implies that a check response of a (non-aggressive) nomination > implies that the controlled side has selected. OK, so that's a good answ= er > to it. > > Except is that a MUST-level or a SHOULD-level behavior? Because elsewher= e > in the doc it's a SHOULD-level. So if it's MUST-level, there's a > contradiction. > > > >>> > "And if an agent never selects a candidate pair, can it not always >>> send on any valid candidate pair of its choosing?" >>> > >>> >[BA] Without nomination *either* controlled or controlling sides can >>> send on any valid candidate pair, and there is not even a requirement f= or >>> symmetry. It is even possible for either side to simultaneously send >>> streams on different valid candidate pairs (e.g. multi-path RTP). >>> >>> I am not sure whether the intent ever was to allow simultaneous streams= . >>> >>> If it=E2=80=99s needed, I think some ICE-considerations-for-multipath-R= TP should >>> enhance ICE, and define how multiple pairs can be used both before and >>> after nomination (or specify that nomination is never done). As far as >>> 5245bis is concerned, I think we should say that only one pair is used = at >>> any given time, and that the controlling endpoint MUST nominate within = a >>> =E2=80=9Creasonable=E2=80=9D time. >>> >> >> I'm not talking about nomination. I'm talking about the controlled side >> selecting or not (which is currently SHOULD strength). >> >> I am not sure what you mean by =E2=80=9Cthe controlled side selecting=E2= =80=9D. The >> selection is done by the controlling side, when nominating. >> > > But elsewhere in the document, it says "The controlled agent SHOULD selec= t > the candidate pair", which means that the controlled side also selects. > There are two selections. The flow is like this: > > 1. Controlling selects > 2. Controlling nominates (although maybe #1 and #2 should be flipped?) > 3. Controlled selects > > >> That is also written in the definition of =E2=80=9Ccontrolled agent=E2= =80=9D: >> >> "Controlled Agent: An ICE agent that waits for the controlling ag= ent >> to select the final choice of candidate pairs." >> >> >> I assume you are talking about the controlled side not =E2=80=9Cacceptin= g=E2=80=9D the >> selection. But, as I said earlier, I don=E2=80=99t think the scenario is= covered in >> the 5245bis. The text seems to assume that the selection done by the >> controlling endpoint will always succeed. >> > > That's my point: we have a SHOULD-level phrase for something that we > expect to have happen. But if it's SHOULD-level, what happens if it > doesn't happen. > > >> >> I have to admit that, since the removal of aggressive nomination, I fail >> to see the difference between =E2=80=9Cnomination=E2=80=9D and =E2=80=9C= selection=E2=80=9D. Since you are >> only going to nominate once, it=E2=80=99s basically the same thing, isn= =E2=80=99t it? >> >> > Nomination means "you SHOULD select this", so it's not the same. > > >> >> But you're right that as currently written, the controlling side could >> also choose not to select. I don't know how you'd define a "reasonable" >> time. What if ICE candidates keep trickling in with trickle ICE? >> >> >>> >>> >Either side can release resources by refusing consent on a candidate >>> that they would prefer not to receive with, or by no longer requesting >>> consent for a candidate they no longer wish to send with. >>> > >>> >The downside is the potential for consent failures that RFC 7675 >>> insists results in pair invalidation. So if you don't want to keep a WW= AN >>> interface up to save power, unless there is a way to explicitly "remove= " >>> and then "add" it back, then candidates involving that >>> >interface will be released. TURN mobility offers a way to quickly >>> bring up media flow using an awakened interface, but if all other pairs >>> involving that interface have been invalidated, then you're stuck with = the >>> relay candidate unless you do an ICE restart. Ugh. >>> >>> >"In other words, if an agent chooses to ignore all nominations and >>> never select a candidate pair, but instead to send on candidate pairs >>> without selecting them and switch between candidate pairs as its sees f= it, >>> is that agent still spec-compliant?" >>> > >>> >[BA] I think it's ok for the controlling side not to nominate a pair, >>> but if it does, then the controlled side needs to be prepared to receiv= e on >>> that pair. >>> >>> And if it isn=E2=80=99t, it shouldn=E2=80=99t reply to the nomination r= equest. Now, THAT >>> is not really covered in the spec =E2=80=93 >>> >> >> That's exactly my point. The spec does not outline any way for the >> controlling side to know that the controlled side honored its nomination= or >> not by selecting. >> >> If the controlling endpoint does not receive a reply to the STUN request >> with the nomination flag set, it should assume that the controlled endpo= int >> did not honour the nomination. But, again, I don=E2=80=99t think the spe= c says >> anything about that. In fact, the text in section 7.1.1 seems to assume >> that nomination will always work: >> >> "Once the controlling agent has selected a valid pair for nomination, >> it repeats the connectivity check that produced this valid pair (by >> enqueueing the pair that generated the check into the TRIGGERED CHECK >> QUEUE), this time with the USE-CANDIDATE attribute. The connectivity >> check should succeed (since the previous did), causing the nominated >> flag value of that and only that pair to be set to true." >> >> the assumption seems to be that, as the nominated pair is in the valid >>> list, the nomination will always succeed. >>> >> >> But the spec says that the controlled side SHOULD honor the nomination, >> which means it might not! So that assumption is not correct (with the >> currently written text). >> >> I think we need to forbid that =E2=80=93 either by saying that the contr= olled >> endpoint MUST honour the nomination, OR by defining how the controlled >> endpoint can explicitly indicate that it didn=E2=80=99t honour. >> > > I agree. We should either make it MUST-level or we should define what > happens if the controlled side doesn't select. > > >> >> Regards, >> >> Christer >> >> --94eb2c05c2a6e3d40705589b36f3 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
And a similar issue not covered: if the STUN transaction w= ith the nomination flag doesn't succeed (say the network goes out for a= while).=C2=A0 Then what?=C2=A0 I think it means we're in a "half-= selected" state (the controlling side has selected but not the control= led side).=C2=A0 Is that OK? =C2=A0

On Thu, Sep 7, 2017 at 8:30 AM Peter Thatcher <pthatcher@google.com> wrote:
<= blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px= #ccc solid;padding-left:1ex">
<= div dir=3D"ltr">On Thu, Sep 7, 2017 at 12:49 AM Christer Holmberg <christer.hol= mberg@ericsson.com> wrote:
<= div style=3D"word-wrap:break-word">
Hi,

>Peter said:=C2=A0
>
>"And my question is this: = =C2=A0Selection on the controlled side is only SHOULD strength, meaning the= controlled side can simply ignore nominations from the controlling side.= =C2=A0Does that mean that controlled side can choose to never select a candidate pair?"
>
>[BA] "Ignoring nominations&q= uot; might mean several things:=C2=A0
>
>a. Not being prepared to receive = on the selected pair.=C2=A0
>b. Retaining resources outside th= e selected pair
>c. Choosing to send on a validate= d pair other than the selected pair (presumably with consent)
>
>I would suggest that b) and c) ar= e acceptable behaviors, but that a) is not.=C2=A0

I don=E2=80=99t think we should allow c). We can of course not prevent= implementations from doing so, but it should not be 5245bis-endorsed behav= iour. We select a pair, and then we use it.

The spec as currently written only says that the controlled side SHOUL= D select.=C2=A0 It doesn't say it MUST. =C2=A0 =C2=A0So I believe C is = allowed, as currently written.

The spec might currentl= y be unclear.

For example, section 2.6 says:

"Once the STUN transact= ion with the flag completes, both sides cancel any f= uture checks for that media stream. =C2=A0
ICE will now send media using this p= air. The pair an ICE agent is using for media is called the SELECTED= PAIR."

To me that sounds like both endpoints will use= the nominated pair.
=C2=A0

Ah, you found it!=C2=A0 I was looking for something like = that and couldn't find it.=C2=A0 That implies that a check response of = a (non-aggressive) nomination implies that the controlled side has selected= .=C2=A0 OK, so that's a good answer to it.=C2=A0

Except is that a MUST-level or a SHOULD-level behavior?=C2=A0 Because el= sewhere in the doc it's a SHOULD-level.=C2=A0 So if it's MUST-level= , there's a contradiction. =C2=A0



> "And if an agent never sele= cts a candidate pair, can it not always send on any valid candidate pair of= its choosing?"
>
>[BA] Without nomination *either* = controlled or controlling sides can send on any valid candidate pair, and t= here is not even a requirement for symmetry. It is even possible for either= side to simultaneously send streams on different valid candidate pairs =C2=A0(e.g. multi-path RTP).

I am not sure whether the intent ever was to allow simultaneous stream= s.=C2=A0

If it=E2=80=99s needed, I think some ICE-considerations-for-multipath-= RTP should enhance ICE, and define how multiple pairs can be used both befo= re and after nomination (or specify that nomination is never done). As far = as 5245bis is concerned, I think we should say that only one pair is used at any given time, and that the controlling= endpoint MUST nominate within a =E2=80=9Creasonable=E2=80=9D time.

I'm not talking about nomination.=C2=A0 I'm talking about the = controlled side selecting or not (which is currently SHOULD strength). =C2= =A0

I am not sure what you mean by=C2=A0=E2=80=9Cthe co= ntrolled side selecting=E2=80=9D.=C2=A0The selection is done by the control= ling side, when nominating.

<= /div>
But elsewhere i= n the document, it says "The controlled agent SHOULD select the candid= ate pair", which means that the controlled side also selects.=C2=A0 Th= ere are two selections.=C2=A0 The flow is like this:

1.=C2=A0 Controlling selects
2.=C2=A0 Controlling nominates = =C2=A0(although maybe #1 and #2 should be flipped?)
3.=C2=A0 Cont= rolled selects


That is also writt= en in the definition of=C2=A0=E2=80=9Ccontrolled agent=E2=80=9D: 

      "Controlled Agent:  An ICE a=
gent that waits for the controlling agent
      to select the final choice of candidate pairs."

I assume you are t= alking about the controlled side not=C2=A0=E2=80=9Caccepting=E2=80=9D the s= election. But, as I said earlier, I don=E2=80=99t think the scenario is cov= ered in the 5245bis. The text seems to assume that the selection done by the controlling endpoint will always succeed.

That's my point: we have a SHOULD-level phrase for somethin= g that we expect to have happen.=C2=A0 But if it's SHOULD-level, what h= appens if it doesn't happen. =C2=A0
<= div class=3D"gmail_quote">
=C2=A0
<= div style=3D"word-wrap:break-word">

I have to admit th= at, since the removal of aggressive nomination, I fail to see the differenc= e between=C2=A0=E2=80=9Cnomination=E2=80=9D and=C2=A0=E2=80=9Cselection=E2= =80=9D. Since you are only going to nominate once, it=E2=80=99s basically t= he same thing, isn=E2=80=99t it?=C2=A0

<= /div>

Nomination means "you SHOULD select this", so = it's not the same.
=C2=A0

But you're right that as currently written, the controlling side c= ould also choose not to select.=C2=A0 I don't know how you'd define= a "reasonable" time.=C2=A0 What if ICE candidates keep trickling= in with trickle ICE?
=C2=A0
>Either side can release resources= by refusing consent on a candidate that they would prefer not to receive w= ith, or by no longer requesting consent for a candidate they no longer wish= to send with.=C2=A0
>
>The downside is the potential for= consent failures that RFC 7675 insists results in pair invalidation. So if= you don't want to keep a WWAN interface up to save power, unless there= is a way to explicitly "remove" and then "add" it back, then candidates involving that
>interface will be released. TURN = mobility offers a way to quickly bring up media flow using an awakened inte= rface, but if all other pairs involving that interface have been invalidate= d, then you're stuck with the relay candidate unless you do an ICE restart.=C2=A0 Ugh.=C2=A0

>"In other words, if an agent= chooses to ignore all nominations and never select a candidate pair, but i= nstead to send on candidate pairs without selecting them and switch between= candidate pairs as its sees fit, is that agent still spec-compliant?"
>
>[BA] I think it's ok for the controlling side not to nominate = a pair, but if it does, then the controlled side needs to be prepared to re= ceive on that pair.=C2=A0

And if it isn=E2=80=99t, it shouldn=E2=80=99t reply to the nomination = request. Now, THAT is not really covered in the spec =E2=80=93

That's exactly my point.=C2=A0 The spec does not outline any way f= or the controlling side to know that the controlled side honored its nomina= tion or not by selecting. =C2=A0

If the controlling= endpoint does not receive a reply to the STUN request with the nomination = flag set, it should assume that the controlled endpoint did not=C2=A0honour= the nomination.=C2=A0But, again, I don=E2=80=99t think the spec says anything about that. In fact, the text in section 7.1.1 seem= s to assume that nomination will always work:
   "Once the controlling agent has=
 selected a valid pair for nomination,
   it repeats the connectivity check that produced this valid pair (by
   enqueueing the pair that generated the check into the TRIGGERED CHECK
   QUEUE), this time with the USE-CANDIDATE attribute.  The connectivity
   check should succeed (since the previous did), causing the nominated
   flag value of that and only that pair to be set to true."=C2=A0
the assumption seems to be that, as the nominated pair is in the valid= list, the nomination will always succeed.

But the spec says that the controlled side SHOULD honor the nomination= , which means it might not!=C2=A0 So that assumption is not correct (with t= he currently written text).

I th= ink we need to forbid that =E2=80=93 either by saying that the controlled e= ndpoint MUST honour the nomination, OR by defining how the controlled endpo= int can explicitly indicate that it didn=E2=80=99t honour.

I agree.=C2=A0 We should either make it MUST-level or we sh= ould define what happens if the controlled side doesn't select.
=C2=A0

Regards,

Christer
--94eb2c05c2a6e3d40705589b36f3-- From nobody Thu Sep 7 09:42:32 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 40E08132F49 for ; Thu, 7 Sep 2017 09:42:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=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=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 04ZkeMAcacnO for ; Thu, 7 Sep 2017 09:42:28 -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 8D065132CE9 for ; Thu, 7 Sep 2017 09:42:28 -0700 (PDT) Received: by mail-qt0-x231.google.com with SMTP id m35so687126qte.1 for ; Thu, 07 Sep 2017 09:42:28 -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=cFMhR5h6gH35UxX5f5Aj7AYLoIjzWPcgPDgP5/MFt6c=; b=dRESz6sHpEl2Lc7PpTTr91+WgVMgrF10bBQPUj5AaWiKw8V3B3LLPSlXE89/CEvSxK jpsTU1BBI5OYDbbMaWezrWvZPp3j8FKTk5hu51WKwd2iS2PBILAXdh+1RUCM+v9YCHld ePA5pZsW84S04mmuS4ML9RQYQqgQVDFf3kESGEzkLX0gDxWKwfi9YtIxLByGL44xAqaY Owx3pEqWT5ATFUqi6Xwue13/S18kMGNsORb0s09TJ6bkgLlMtES2VGC8aSEbX8UxPRKJ z0u5MtN1WRplKOKzZNNMdMuWJOFRmYo1RrjmrHxZxG2/QC93dg8p9cw8t0/aLYArYyhA 0hDg== 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=cFMhR5h6gH35UxX5f5Aj7AYLoIjzWPcgPDgP5/MFt6c=; b=oA+/+SSJD4JJsT/rMWXELqBKiU6e31fMmDP3+KxM04cwcKeaE3Q9oQb0m8SjS3gnmU w6NrX+Tjygxeo3SoqlAN9FDEYd/YdYs0LniSTyW7mZ78QyVDAI868TUE0AY69PQJebvq j1CiQ3PBdt4K0v4rYNJuPemgSSmGXIdshBtILsQgiBSZrHHmA7QJXmGAR5nfmJfNNwht 4hxR0rxBiswYSy+6c1n1IL5NlVXvZrhr9cDdqfklXGcoSfXRcFBN7T//0ULOLLHnF2y/ X9t7fyXQ3OxpFEtzGibV43yjvnqcmHMCaMJUDD3A/Nr2/dWoZ8LDkcw2+FtCz7s4M+qO 6gBw== X-Gm-Message-State: AHPjjUhN7IiDhRQ8Mst8BWrkOWA9/jb9ZYvw+Y+LC1iZIGLknKMVqy61 dTyjJX2nJI93kq4eJkJvqyhVm57+kJgwCww= X-Google-Smtp-Source: ADKCNb5VvtqLP+cGm+kAoU5+hfYGReixTw97VolEMroO2vL/wvlBM7zt+UPE2WM2uupScNkU7fs+205BwgQ+JHzaQA4= X-Received: by 10.200.53.129 with SMTP id k1mr4460592qtb.243.1504802547292; Thu, 07 Sep 2017 09:42:27 -0700 (PDT) MIME-Version: 1.0 From: Peter Thatcher Date: Thu, 07 Sep 2017 16:42:15 +0000 Message-ID: To: ICE WG Content-Type: multipart/alternative; boundary="001a113c29424a5f3b05589c2552" Archived-At: Subject: [Ice] Changing the text for when we can free 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: Thu, 07 Sep 2017 16:42:30 -0000 --001a113c29424a5f3b05589c2552 Content-Type: text/plain; charset="UTF-8" At IETF 99, we discussed PR38 (https://github.com/ice-wg/rfc5245bis/pull/38/), which I just updated, and the only really unclear remaining is related to when an agent can free candidates. The decision at IETF 99 was that we would have something closer to the original text (which covers forking), but make the meaning of "Completed" more clear. So, I have updated the PR to be like that, and here is the updated paragraph (which is very close to the original, but with the improvements suggested): "Once a checklist has reached the Completed state, the agent SHOULD wait an additional three seconds, and then it can cease responding to checks or generating triggered checks on all local candidates other than the ones in the selected candidate pairs (one for each component). Once all ICE sessions have ceased using a given local candidate (a candidate may be used by multiple ICE sessions, e.g. in forking scenarios), the agent can free that candidate. The three-second delay handles cases when aggressive nomination is used, and the selected pairs can quickly change after ICE has completed. Freeing of server reflexive candidates is never explicit; it happens by lack of a keepalive. " And, for reference, here is the old paragraph: "Once ICE processing has reached the Completed state for all peers for media streams using those candidates, the agent SHOULD wait an additional three seconds, and then it MAY cease responding to checks or generating triggered checks on that candidate. It MAY free the candidate at that time. Freeing of server reflexive candidates is never explicit; it happens by lack of a keepalive. The three-second delay handles cases when aggressive nomination is used, and the selected pairs can quickly change after ICE has completed." Does this change cover what we were looking for at IETF 99? --001a113c29424a5f3b05589c2552 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
At IETF 99, we discussed PR38 (https://github.com/ice-wg/rfc5245bis/pu= ll/38/), which I just updated, and the only really unclear remaining is= related to when an agent can free candidates.=C2=A0 The decision at IETF 9= 9 was that we would have something closer to the original text (which cover= s forking), but make the meaning of "Completed" more clear.=C2=A0= So, I have updated the PR to be like that, and here is the updated paragra= ph (which is very close to the original, but with the improvements suggeste= d):


"Once a checklist has reac= hed the Completed state, the agent SHOULD wait an additional three seconds,= and then it can cease responding to checks or generating triggered checks = on all local candidates other than
the ones in the selected candi= date pairs (one for each component).
Once all ICE sessions have c= eased using a given local candidate=C2=A0
(a candidate may be use= d by multiple ICE sessions, e.g. in forking scenarios), the agent can free = that candidate.=C2=A0 The three-second delay handles cases when aggressive = nomination is used, and the selected pairs can quickly change after ICE has= completed. Freeing of server reflexive candidates is never explicit; it ha= ppens by lack of a keepalive. =C2=A0"


And, for reference, here is the old paragraph:

=
"Once ICE processing has reached the Completed state for all peer= s for
media streams using those candidates, the agent SHOULD wait= an
additional three seconds, and then it MAY cease responding to= checks or
generating triggered checks on that candidate.=C2=A0 I= t MAY free the
candidate at that time. Freeing of server reflexiv= e candidates is never
explicit; it happens by lack of a keepalive= .=C2=A0 The three-second delay
handles cases when aggressive nomi= nation is used, and the selected pairs
can quickly change after I= CE has completed."


Does this c= hange cover what we were looking for at IETF 99?

<= br>

--001a113c29424a5f3b05589c2552-- From nobody Thu Sep 7 09:50: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 7599D132CE9 for ; Thu, 7 Sep 2017 09:50:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.699 X-Spam-Level: X-Spam-Status: No, score=-2.699 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, 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 5iJ5KtRRu8n3 for ; Thu, 7 Sep 2017 09:49:58 -0700 (PDT) Received: from mail-qk0-x236.google.com (mail-qk0-x236.google.com [IPv6:2607:f8b0:400d:c09::236]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 928DD124207 for ; Thu, 7 Sep 2017 09:49:58 -0700 (PDT) Received: by mail-qk0-x236.google.com with SMTP id b82so649113qkc.4 for ; Thu, 07 Sep 2017 09:49:58 -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=1IAgwJImAtJA/vMuc6/D/+dFoc24DJ39guXY4E3Eyi0=; b=fLq6DI0pChfcjhrx1poMI9qGYFTiAmUfb4fMrnwd1vNtzFTpxbWfOFB8btJ1Q0yC52 43Gh1arFXA5HnSIxUdc1sdXg7UwKOMYX5YAbODHFZzMWufg0yMUoIgwdJa5vDOt72Qp0 ym7uGPv6L8sOQJelcg+35AEMSd57vMPZAuxMgevM0Xalvpi+yEMrmiKkhXA6HzJ/eaM4 BZDpn98KaLNP27GMvAmPQt3WTNG7FfTe0YfLRlP/wT7aIGzTZ3Q6CN9T7Cu+YJbElhUX hpDigxbloveREmHWCyyx25zjlW27cjb3Iq5/AltVxmqoyaIwwWddO+szihaiZRjmdwto Q3oQ== 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=1IAgwJImAtJA/vMuc6/D/+dFoc24DJ39guXY4E3Eyi0=; b=laJPHc089viSVafdo/nm7EnF7cDEX90RRWiinr42EFpw4HO2GkbHYbNq8QuDpKG1UU aBxhjvTYKqZinSwhKsgNc0OQ9pTXOXarfKhP1HMBPIi4r06vaqBRbpMUDGMOVvGCdHQM HyUnS/e7+TPIWkZbX2G1AggqyRhpiVXGlBXhAHnMg+N7QoGvOD8udj6RYQfkdAadeRfr guZQjdLOqzAspNBZAYWzY9tWCdQ1XJKZz8NWEAxzt/2V0uLj8AxxEXIiCjx1baajdEWz BrRSD6WLAgnntJ3YTVhpLa6UIEy5txDvG1ieeibevnWMJNbNcrZpTmYQVCrV6UAhhben AIeQ== X-Gm-Message-State: AHPjjUgnmTNbBQlolwBNBbc02Nu9dnYbiVh1Q17xR6gTOQd4KqOve3oG GDQqP+/W5bMFgRNrdrcjgx0pb+5Cwu0iYYw= X-Google-Smtp-Source: AOwi7QA7ONO8G3qRpHjpeejMrdGcifSpIJN0IKTAeNumcn6X+9IJbV6wYztcFphvi6hzuTI3SIpV+siz8dxrHS3dJNA= X-Received: by 10.55.54.13 with SMTP id d13mr4329650qka.218.1504802997338; Thu, 07 Sep 2017 09:49:57 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Peter Thatcher Date: Thu, 07 Sep 2017 16:49:46 +0000 Message-ID: To: ICE WG Content-Type: multipart/alternative; boundary="001a1147150e1d734005589c4026" Archived-At: Subject: Re: [Ice] Changing the text for when we can free 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: Thu, 07 Sep 2017 16:50:00 -0000 --001a1147150e1d734005589c4026 Content-Type: text/plain; charset="UTF-8" Here's a nicer view of the diff on github: https://github.com/ice-wg/rfc5245bis/pull/38/files#diff-2545e307f242412e07ae64a9f1e69222L2995 On Thu, Sep 7, 2017 at 9:42 AM Peter Thatcher wrote: > At IETF 99, we discussed PR38 ( > https://github.com/ice-wg/rfc5245bis/pull/38/), which I just updated, and > the only really unclear remaining is related to when an agent can free > candidates. The decision at IETF 99 was that we would have something > closer to the original text (which covers forking), but make the meaning of > "Completed" more clear. So, I have updated the PR to be like that, and > here is the updated paragraph (which is very close to the original, but > with the improvements suggested): > > > "Once a checklist has reached the Completed state, the agent SHOULD wait > an additional three seconds, and then it can cease responding to checks or > generating triggered checks on all local candidates other than > the ones in the selected candidate pairs (one for each component). > Once all ICE sessions have ceased using a given local candidate > (a candidate may be used by multiple ICE sessions, e.g. in forking > scenarios), the agent can free that candidate. The three-second delay > handles cases when aggressive nomination is used, and the selected pairs > can quickly change after ICE has completed. Freeing of server reflexive > candidates is never explicit; it happens by lack of a keepalive. " > > > And, for reference, here is the old paragraph: > > "Once ICE processing has reached the Completed state for all peers for > media streams using those candidates, the agent SHOULD wait an > additional three seconds, and then it MAY cease responding to checks or > generating triggered checks on that candidate. It MAY free the > candidate at that time. Freeing of server reflexive candidates is never > explicit; it happens by lack of a keepalive. The three-second delay > handles cases when aggressive nomination is used, and the selected pairs > can quickly change after ICE has completed." > > > Does this change cover what we were looking for at IETF 99? > > > > --001a1147150e1d734005589c4026 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Here's a nicer view of the diff on github:


On Thu, Sep 7, 2017 at 9:= 42 AM Peter Thatcher <pthatcher@= google.com> wrote:
At IETF 99, we discussed PR38 (https://github.com/ice-wg/rfc= 5245bis/pull/38/), which I just updated, and the only really unclear re= maining is related to when an agent can free candidates.=C2=A0 The decision= at IETF 99 was that we would have something closer to the original text (w= hich covers forking), but make the meaning of "Completed" more cl= ear.=C2=A0 So, I have updated the PR to be like that, and here is the updat= ed paragraph (which is very close to the original, but with the improvement= s suggested):


"Once a checklis= t has reached the Completed state, the agent SHOULD wait an additional thre= e seconds, and then it can cease responding to checks or generating trigger= ed checks on all local candidates other than
the ones in the sele= cted candidate pairs (one for each component).
Once all ICE sessi= ons have ceased using a given local candidate=C2=A0
(a candidate = may be used by multiple ICE sessions, e.g. in forking scenarios), the agent= can free that candidate.=C2=A0 The three-second delay handles cases when a= ggressive nomination is used, and the selected pairs can quickly change aft= er ICE has completed. Freeing of server reflexive candidates is never expli= cit; it happens by lack of a keepalive. =C2=A0"


And, for reference, here is the old paragraph:
=
"Once ICE processing has reached the Completed state fo= r all peers for
media streams using those candidates, the agent S= HOULD wait an
additional three seconds, and then it MAY cease res= ponding to checks or
generating triggered checks on that candidat= e.=C2=A0 It MAY free the
candidate at that time. Freeing of serve= r reflexive candidates is never
explicit; it happens by lack of a= keepalive.=C2=A0 The three-second delay
handles cases when aggre= ssive nomination is used, and the selected pairs
can quickly chan= ge after ICE has completed."


D= oes this change cover what we were looking for at IETF 99?



--001a1147150e1d734005589c4026-- From nobody Fri Sep 8 00:34:14 2017 Return-Path: X-Original-To: ice@ietfa.amsl.com Delivered-To: ice@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 16EB7133145 for ; Fri, 8 Sep 2017 00:34:13 -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 pqQUUyAhKfaV for ; Fri, 8 Sep 2017 00:34:11 -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 22FBF13313F for ; Fri, 8 Sep 2017 00:34:10 -0700 (PDT) X-AuditID: c1b4fb2d-4e93a9c0000057a4-88-59b247f14e7b Received: from ESESSHC017.ericsson.se (Unknown_Domain [153.88.183.69]) by sessmg23.ericsson.net (Symantec Mail Security) with SMTP id 55.7C.22436.1F742B95; Fri, 8 Sep 2017 09:34:09 +0200 (CEST) Received: from ESESSMB109.ericsson.se ([169.254.9.194]) by ESESSHC017.ericsson.se ([153.88.183.69]) with mapi id 14.03.0352.000; Fri, 8 Sep 2017 09:34:08 +0200 From: Christer Holmberg To: Peter Thatcher , ICE WG Thread-Topic: [Ice] Changing the text for when we can free candidates Thread-Index: AQHTJ/hOHtL68YdMTk20HYi0OlLaQqKpgScAgAEqwAA= Date: Fri, 8 Sep 2017 07:34:08 +0000 Message-ID: References: In-Reply-To: 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.146] Content-Type: multipart/alternative; boundary="_000_D5D8234C212DEchristerholmbergericssoncom_" MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFprDIsWRmVeSWpSXmKPExsUyM2K7q+5H902RBjP2S1t8u1BrcW35a1YH Jo8Fm0o9liz5yRTAFMVlk5Kak1mWWqRvl8CVMa11LmPBBJeKF+susjYwPrTsYuTkkBAwkdhz oI21i5GLQ0jgCKPEzFnXWCCcxYwSP2Z9Yeti5OBgE7CQ6P6nDWKKCDhINByNA+kVFnCROPTp BDOILSLgKnFr3wUWCNtK4vnnpYwgNouAisSLBb+ZQGxeAWuJ+6sPQ42fzihxrf8S2HhOgUCJ ueedQGoYBcQkvp9aA1bPLCAucevJfCaIOwUkluw5zwxhi0q8fPyPFaRVVEBP4t1+T4iwksSP DZdYIFoTJDZ/OQ21VlDi5MwnLBMYRWYhmToLSdksJGUQcQOJ9+fmM0PY2hLLFr6GsvUlNn45 ywhhW0scunGJHVnNAkaOVYyixanFxbnpRsZ6qUWZycXF+Xl6eaklmxiBcXZwy2/dHYyrXzse YhTgYFTi4WUExp8Qa2JZcWXuIUYJDmYlEd58V6AQb0piZVVqUX58UWlOavEhRmkOFiVxXod9 FyKEBNITS1KzU1MLUotgskwcnFINjEqJf/9sCttf3rzvD590Zd7ZHku2cJ2VZgvNVneHcrbs 5FsV90LftfDIP7WS789nd2y7OfPdQdVzH5U/dO723ZS5S6C7tOpt8HRD0e9JD2QjY7LWv54e fPrz2h3r7twNqjquxuZerO3zauav/6Jir0V6KmNe7lxbI8r0rSj+0sOkiWHJH7XkLZVYijMS DbWYi4oTAWqTuKOvAgAA Archived-At: Subject: Re: [Ice] Changing the text for when we can free 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: Fri, 08 Sep 2017 07:34:13 -0000 --_000_D5D8234C212DEchristerholmbergericssoncom_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable Hi, A minor nit. The text says: "The three-second delay handles cases when aggressive nomination is used, a= nd the selected pairs can quickly change after ICE has completed.=94 Earlier the text says that the three-second delay starts once the CHECKLIST= is Completed, so I think the text above should be aligned: "The three-second delay handles cases when aggressive nomination is used, a= nd the selected pairs can quickly change after a checklist has reached the = Completed state.=94 Regards, Christer From: Ice > on behalf of = "pthatcher@google.com" > Date: Thursday 7 September 2017 at 19:49 To: "ice@ietf.org" > Subject: Re: [Ice] Changing the text for when we can free candidates Here's a nicer view of the diff on github: https://github.com/ice-wg/rfc5245bis/pull/38/files#diff-2545e307f242412e07a= e64a9f1e69222L2995 On Thu, Sep 7, 2017 at 9:42 AM Peter Thatcher > wrote: At IETF 99, we discussed PR38 (https://github.com/ice-wg/rfc5245bis/pull/38= /), which I just updated, and the only really unclear remaining is related = to when an agent can free candidates. The decision at IETF 99 was that we = would have something closer to the original text (which covers forking), bu= t make the meaning of "Completed" more clear. So, I have updated the PR to= be like that, and here is the updated paragraph (which is very close to th= e original, but with the improvements suggested): "Once a checklist has reached the Completed state, the agent SHOULD wait an= additional three seconds, and then it can cease responding to checks or ge= nerating triggered checks on all local candidates other than the ones in the selected candidate pairs (one for each component). Once all ICE sessions have ceased using a given local candidate (a candidate may be used by multiple ICE sessions, e.g. in forking scenario= s), the agent can free that candidate. The three-second delay handles case= s when aggressive nomination is used, and the selected pairs can quickly ch= ange after ICE has completed. Freeing of server reflexive candidates is nev= er explicit; it happens by lack of a keepalive. " And, for reference, here is the old paragraph: "Once ICE processing has reached the Completed state for all peers for media streams using those candidates, the agent SHOULD wait an additional three seconds, and then it MAY cease responding to checks or generating triggered checks on that candidate. It MAY free the candidate at that time. Freeing of server reflexive candidates is never explicit; it happens by lack of a keepalive. The three-second delay handles cases when aggressive nomination is used, and the selected pairs can quickly change after ICE has completed." Does this change cover what we were looking for at IETF 99? --_000_D5D8234C212DEchristerholmbergericssoncom_ Content-Type: text/html; charset="Windows-1252" Content-ID: Content-Transfer-Encoding: quoted-printable
Hi,

A minor nit. The text says:

"The three-second delay handles cases when aggressive nomination = is used, and the selected pairs can quickly change after ICE has completed.= =94

Earlier the text says that the three-second delay starts once the CHEC= KLIST is Completed, so I think the text above should be aligned: 

"The three-second delay handles cases when aggressive nomination = is used, and the selected pairs can quickly change after a checklist has re= ached the Completed state.=94

Regards,

Christer


From: Ice <ice-bounces@ietf.org> on behalf of "pthatcher@google.com" <pthatcher@google.com>
Date: Thursday 7 September 2017 at = 19:49
To: "ice@ietf.org" <ice@ietf.= org>
Subject: Re: [Ice] Changing the tex= t for when we can free candidates


On Thu, Sep 7, 2017 at 9:42 AM Peter Thatcher <pthatcher@google.com> wrote:
At IETF 99, we discussed PR38 (https://github.com/ice-wg/rfc5245bis/p= ull/38/), which I just updated, and the only really unclear remaining i= s related to when an agent can free candidates.  The decision at IETF 99 was that we would have something= closer to the original text (which covers forking), but make the meaning o= f "Completed" more clear.  So, I have updated the PR to be l= ike that, and here is the updated paragraph (which is very close to the original, but with the improvements suggested):


"Once a checklist has reached the Completed state, the agent SHOU= LD wait an additional three seconds, and then it can cease responding to ch= ecks or generating triggered checks on all local candidates other than
the ones in the selected candidate pairs (one for each component).
Once all ICE sessions have ceased using a given local candidate <= /div>
(a candidate may be used by multiple ICE sessions, e.g. in forking sce= narios), the agent can free that candidate.  The three-second delay ha= ndles cases when aggressive nomination is used, and the selected pairs can = quickly change after ICE has completed. Freeing of server reflexive candidates is never explicit; it happens by la= ck of a keepalive.  "


And, for reference, here is the old paragraph:

"Once ICE processing has reached the Completed state for all peer= s for
media streams using those candidates, the agent SHOULD wait an
additional three seconds, and then it MAY cease responding to checks o= r
generating triggered checks on that candidate.  It MAY free the
candidate at that time. Freeing of server reflexive candidates is neve= r
explicit; it happens by lack of a keepalive.  The three-second de= lay
handles cases when aggressive nomination is used, and the selected pai= rs
can quickly change after ICE has completed."


Does this change cover what we were looking for at IETF 99?



 --_000_D5D8234C212DEchristerholmbergericssoncom_-- From nobody Fri Sep 8 00:50:13 2017 Return-Path: X-Original-To: ice@ietfa.amsl.com Delivered-To: ice@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9445813234B for ; Fri, 8 Sep 2017 00:50:11 -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 D0HQ6mDyKji8 for ; Fri, 8 Sep 2017 00:50:08 -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 432851241F3 for ; Fri, 8 Sep 2017 00:50:08 -0700 (PDT) X-AuditID: c1b4fb25-967ff70000005333-44-59b24bae561e Received: from ESESSHC021.ericsson.se (Unknown_Domain [153.88.183.81]) by sesbmg23.ericsson.net (Symantec Mail Security) with SMTP id B8.D1.21299.EAB42B95; Fri, 8 Sep 2017 09:50:06 +0200 (CEST) Received: from ESESSMB109.ericsson.se ([169.254.9.194]) by ESESSHC021.ericsson.se ([153.88.183.81]) with mapi id 14.03.0352.000; Fri, 8 Sep 2017 09:50:05 +0200 From: Christer Holmberg To: Peter Thatcher , Bernard Aboba CC: ICE WG Thread-Topic: [Ice] I updated PR 38 and I have a question about nomination/selection Thread-Index: AQHTJ3IRYv+AapMhGE+46WiPlX+3FqKo0jyAgAA6OYD//9MNAIAAPz6AgABNRwCAAAFzgIABQ+0A Date: Fri, 8 Sep 2017 07:50:04 +0000 Message-ID: References: In-Reply-To: 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_D5D826AB212E6christerholmbergericssoncom_" MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFlrPIsWRmVeSWpSXmKPExsUyM2J7oO46702RBgt3i1ts2Pef2eLbhVqL a8tfszowe+ycdZfdY8GmUo8lS34yBTBHcdmkpOZklqUW6dslcGUsX7afvaDrMWNF58EvbA2M nQcZuxg5OSQETCR2zt4AZgsJHGGUaF+YAGEvZpS42y3dxcjBwSZgIdH9TxskLCIQIvH+13lm EJtZQFJi7eel7CAlwgKhEg/2i4GYIgJhEs277SCqoyQaf/xnAbFZBFQkNjxtYAMp4RWwlmh/ q9LFyAW05wKzxN0nd5hA4pwCgRL7PxSAlDMKiEl8P7WGCWKRuMStJ/OZIO4VkFiyB+IACQFR iZeP/7GCtIoK6Em82+8JEVaU+PhqHyNEa4LElu1nwC7gFRCUODnzCcsERtFZSKbOQlI2C0kZ RNxA4v25+cwQtrbEsoWvoWx9iY1fzjLOAtrMDPTM9qkRyEoWMHKsYhQtTi1Oyk03MtZLLcpM Li7Oz9PLSy3ZxAiMxoNbfqvuYLz8xvEQowAHoxIP7xf3TZFCrIllxZW5hxglOJiVRHjzXYFC vCmJlVWpRfnxRaU5qcWHGKU5WJTEeR33XYgQEkhPLEnNTk0tSC2CyTJxcEo1MFaFaslwzOYs /LbW4UTPbfn9X7p69nw7GzqhpOb2q4bash+6fGvMJNdN+bfnU9SKlyol0+cvTd135bDhVT2B TcmB646zrl1i6Vx3pC/yyW6PnjdVd6NeJYWIvPcM55nWPcvJ4vu5qKXv9k3ezHjdYp6HYqny Hu4ZEvN75716y/15U0Hr2SvnXvxXYinOSDTUYi4qTgQAidOFA8ICAAA= Archived-At: Subject: Re: [Ice] I updated PR 38 and I have a question about nomination/selection 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, 08 Sep 2017 07:50:11 -0000 --_000_D5D826AB212E6christerholmbergericssoncom_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable Hi, >And a similar issue not covered: if the STUN transaction with the nominati= on flag doesn't succeed (say the network goes out for a while). Then what?= I think it means we're in a "half-selected" state (the controlling side h= as selected but not the controlled side). Is that OK? In my opinion the selection has completed once the STUN transaction has suc= ceeded. Before that, we=92re in the pre-selection state, where one can send= media on all candidates etc. We should make that more clear in the spec. T= hen, if it happens, the controlling endpoint can choose what to do, e.g., t= ry to nominate another pair in the valid list, or release the whole session= . The exact action should be an implementation issue, in my opinion. Regards, Christer On Thu, Sep 7, 2017 at 8:30 AM Peter Thatcher > wrote: On Thu, Sep 7, 2017 at 12:49 AM Christer Holmberg > wrote: Hi, >Peter said: > >"And my question is this: Selection on the controlled side is only SHOULD= strength, meaning the controlled side can simply ignore nominations from t= he controlling side. Does that mean that controlled side can choose to neve= r select a candidate pair?" > >[BA] "Ignoring nominations" might mean several things: > >a. Not being prepared to receive on the selected pair. >b. Retaining resources outside the selected pair >c. Choosing to send on a validated pair other than the selected pair (pres= umably with consent) > >I would suggest that b) and c) are acceptable behaviors, but that a) is no= t. I don=92t think we should allow c). We can of course not prevent implementa= tions from doing so, but it should not be 5245bis-endorsed behaviour. We se= lect a pair, and then we use it. The spec as currently written only says that the controlled side SHOULD sel= ect. It doesn't say it MUST. So I believe C is allowed, as currently wr= itten. The spec might currently be unclear. For example, section 2.6 says: "Once the STUN transaction with the flag completes, both sides cancel any f= uture checks for that media stream. ICE will now send media using this pair. The pair an ICE agent is using for= media is called the SELECTED PAIR." To me that sounds like both endpoints will use the nominated pair. Ah, you found it! I was looking for something like that and couldn't find = it. That implies that a check response of a (non-aggressive) nomination im= plies that the controlled side has selected. OK, so that's a good answer t= o it. Except is that a MUST-level or a SHOULD-level behavior? Because elsewhere = in the doc it's a SHOULD-level. So if it's MUST-level, there's a contradic= tion. > "And if an agent never selects a candidate pair, can it not always send o= n any valid candidate pair of its choosing?" > >[BA] Without nomination *either* controlled or controlling sides can send = on any valid candidate pair, and there is not even a requirement for symmet= ry. It is even possible for either side to simultaneously send streams on d= ifferent valid candidate pairs (e.g. multi-path RTP). I am not sure whether the intent ever was to allow simultaneous streams. If it=92s needed, I think some ICE-considerations-for-multipath-RTP should = enhance ICE, and define how multiple pairs can be used both before and afte= r nomination (or specify that nomination is never done). As far as 5245bis = is concerned, I think we should say that only one pair is used at any given= time, and that the controlling endpoint MUST nominate within a =93reasonab= le=94 time. I'm not talking about nomination. I'm talking about the controlled side se= lecting or not (which is currently SHOULD strength). I am not sure what you mean by =93the controlled side selecting=94. The sel= ection is done by the controlling side, when nominating. But elsewhere in the document, it says "The controlled agent SHOULD select = the candidate pair", which means that the controlled side also selects. Th= ere are two selections. The flow is like this: 1. Controlling selects 2. Controlling nominates (although maybe #1 and #2 should be flipped?) 3. Controlled selects That is also written in the definition of =93controlled agent=94: "Controlled Agent: An ICE agent that waits for the controlling agent to select the final choice of candidate pairs." I assume you are talking about the controlled side not =93accepting=94 the = selection. But, as I said earlier, I don=92t think the scenario is covered = in the 5245bis. The text seems to assume that the selection done by the con= trolling endpoint will always succeed. That's my point: we have a SHOULD-level phrase for something that we expect= to have happen. But if it's SHOULD-level, what happens if it doesn't happ= en. I have to admit that, since the removal of aggressive nomination, I fail to= see the difference between =93nomination=94 and =93selection=94. Since you= are only going to nominate once, it=92s basically the same thing, isn=92t = it? Nomination means "you SHOULD select this", so it's not the same. But you're right that as currently written, the controlling side could also= choose not to select. I don't know how you'd define a "reasonable" time. = What if ICE candidates keep trickling in with trickle ICE? >Either side can release resources by refusing consent on a candidate that = they would prefer not to receive with, or by no longer requesting consent f= or a candidate they no longer wish to send with. > >The downside is the potential for consent failures that RFC 7675 insists r= esults in pair invalidation. So if you don't want to keep a WWAN interface = up to save power, unless there is a way to explicitly "remove" and then "ad= d" it back, then candidates involving that >interface will be released. TURN mobility offers a way to quickly bring up= media flow using an awakened interface, but if all other pairs involving t= hat interface have been invalidated, then you're stuck with the relay candi= date unless you do an ICE restart. Ugh. >"In other words, if an agent chooses to ignore all nominations and never s= elect a candidate pair, but instead to send on candidate pairs without sele= cting them and switch between candidate pairs as its sees fit, is that agen= t still spec-compliant?" > >[BA] I think it's ok for the controlling side not to nominate a pair, but = if it does, then the controlled side needs to be prepared to receive on tha= t pair. And if it isn=92t, it shouldn=92t reply to the nomination request. Now, THA= T is not really covered in the spec =96 That's exactly my point. The spec does not outline any way for the control= ling side to know that the controlled side honored its nomination or not by= selecting. If the controlling endpoint does not receive a reply to the STUN request wi= th the nomination flag set, it should assume that the controlled endpoint d= id not honour the nomination. But, again, I don=92t think the spec says any= thing about that. In fact, the text in section 7.1.1 seems to assume that n= omination will always work: "Once the controlling agent has selected a valid pair for nomination, it repeats the connectivity check that produced this valid pair (by enqueueing the pair that generated the check into the TRIGGERED CHECK QUEUE), this time with the USE-CANDIDATE attribute. The connectivity check should succeed (since the previous did), causing the nominated flag value of that and only that pair to be set to true." the assumption seems to be that, as the nominated pair is in the valid list= , the nomination will always succeed. But the spec says that the controlled side SHOULD honor the nomination, whi= ch means it might not! So that assumption is not correct (with the current= ly written text). I think we need to forbid that =96 either by saying that the controlled end= point MUST honour the nomination, OR by defining how the controlled endpoin= t can explicitly indicate that it didn=92t honour. I agree. We should either make it MUST-level or we should define what happ= ens if the controlled side doesn't select. Regards, Christer --_000_D5D826AB212E6christerholmbergericssoncom_ Content-Type: text/html; charset="Windows-1252" Content-ID: <70B2B9EC08BC5A43932C5A9334B53AE9@ericsson.com> Content-Transfer-Encoding: quoted-printable
Hi,

>And a similar issue not covered: if the STUN transacti= on with the nomination flag doesn't succeed (say the network goes out for a= while).  Then what?  I think it means we're in a "half-sele= cted" state (the controlling side has selected but not the controlled side).  Is that OK?  

In my opinion the selection has completed once the STUN transaction ha= s succeeded. Before that, we=92re in the pre-selection state, where one can= send media on all candidates etc. We should make that more clear in the sp= ec. Then, if it happens, the controlling endpoint can choose what to do, e.g., try to nominate another pair in the = valid list, or release the whole session. The exact action should be an imp= lementation issue, in my opinion.

Regards,

Christer



On Thu, Sep 7, 2017 at 8:30 AM Peter Thatcher <pthatcher@google.com> wrote:
On Thu, Sep 7, 2017 at 12:49 AM Christer Holmberg <christer.ho= lmberg@ericsson.com> wrote:
Hi,

>Peter said: 
>
>"And my question is this: &n= bsp;Selection on the controlled side is only SHOULD strength, meaning the c= ontrolled side can simply ignore nominations from the controlling side.&nbs= p;Does that mean that controlled side can choose to never select a candidate pair?"
>
>[BA] "Ignoring nominations&q= uot; might mean several things: 
>
>a. Not being prepared to receive = on the selected pair. 
>b. Retaining resources outside th= e selected pair
>c. Choosing to send on a validate= d pair other than the selected pair (presumably with consent)
>
>I would suggest that b) and c) ar= e acceptable behaviors, but that a) is not. 

I don=92t think we should allow c). We can of course not prevent imple= mentations from doing so, but it should not be 5245bis-endorsed behaviour. = We select a pair, and then we use it.

The spec as currently written only says that the controlled side SHOUL= D select.  It doesn't say it MUST.    So I believe C is allo= wed, as currently written.

The spec might currently be unclear.

For example, section 2.6 says:

"Once the STUN transact= ion with the flag completes, both sides cancel any f= uture checks for that media stream.  
ICE will now send media using this p= air. The pair an ICE agent is using for media is called the SELECTED= PAIR."

To me that sounds like both endpoints will use= the nominated pair.
 

Ah, you found it!  I was looking for something like that and coul= dn't find it.  That implies that a check response of a (non-aggressive= ) nomination implies that the controlled side has selected.  OK, so th= at's a good answer to it. 

Except is that a MUST-level or a SHOULD-level behavior?  Because = elsewhere in the doc it's a SHOULD-level.  So if it's MUST-level, ther= e's a contradiction.  



> "And if an agent never sele= cts a candidate pair, can it not always send on any valid candidate pair of= its choosing?"
>
>[BA] Without nomination *either* = controlled or controlling sides can send on any valid candidate pair, and t= here is not even a requirement for symmetry. It is even possible for either= side to simultaneously send streams on different valid candidate pairs  (e.g. multi-path RTP).

I am not sure whether the intent ever was to allow simultaneous stream= s. 

If it=92s needed, I think some ICE-considerations-for-multipath-RTP sh= ould enhance ICE, and define how multiple pairs can be used both before and= after nomination (or specify that nomination is never done). As far as 524= 5bis is concerned, I think we should say that only one pair is used at any given time, and that the controlling= endpoint MUST nominate within a =93reasonable=94 time.

I'm not talking about nomination.  I'm talking about the controll= ed side selecting or not (which is currently SHOULD strength).  

I am not sure what= you mean by =93the controlled side selecting=94. The selection i= s done by the controlling side, when nominating.

But elsewhere in the document, it says "The controlled agent SHOU= LD select the candidate pair", which means that the controlled side al= so selects.  There are two selections.  The flow is like this:

1.  Controlling selects
2.  Controlling nominates  (although maybe #1 and #2 should = be flipped?)
3.  Controlled selects


That is also writt= en in the definition of =93controlled agent=94:

      "Controlled Agent:  An ICE a=
gent that waits for the controlling agent
      to select the final choice of candidate pairs."

I assume you are t= alking about the controlled side not =93accepting=94 the selection. Bu= t, as I said earlier, I don=92t think the scenario is covered in the 5245bi= s. The text seems to assume that the selection done by the controlling endpoint will always succeed.

That's my point: we have a SHOULD-level phrase for something that we e= xpect to have happen.  But if it's SHOULD-level, what happens if it do= esn't happen.  
 

I have to admit th= at, since the removal of aggressive nomination, I fail to see the differenc= e between =93nomination=94 and =93selection=94. Since you are onl= y going to nominate once, it=92s basically the same thing, isn=92t it? 


Nomination means "you SHOULD select this", so it's not the s= ame.
 

But you're right that as currently written, the controlling side could= also choose not to select.  I don't know how you'd define a "rea= sonable" time.  What if ICE candidates keep trickling in with tri= ckle ICE?
 
>Either side can release resources= by refusing consent on a candidate that they would prefer not to receive w= ith, or by no longer requesting consent for a candidate they no longer wish= to send with. 
>
>The downside is the potential for= consent failures that RFC 7675 insists results in pair invalidation. So if= you don't want to keep a WWAN interface up to save power, unless there is = a way to explicitly "remove" and then "add" it back, then candidates involving that
>interface will be released. TURN = mobility offers a way to quickly bring up media flow using an awakened inte= rface, but if all other pairs involving that interface have been invalidate= d, then you're stuck with the relay candidate unless you do an ICE restart.  Ugh. 

>"In other words, if an agent= chooses to ignore all nominations and never select a candidate pair, but i= nstead to send on candidate pairs without selecting them and switch between= candidate pairs as its sees fit, is that agent still spec-compliant?"
>
>[BA] I think it's ok for the controlling side not to nominate a pa= ir, but if it does, then the controlled side needs to be prepared to receiv= e on that pair. 

And if it isn=92t, it shouldn=92t reply to the nomination request. Now= , THAT is not really covered in the spec =96

That's exactly my point.  The spec does not outline any way for t= he controlling side to know that the controlled side honored its nomination= or not by selecting.  

If the controlling= endpoint does not receive a reply to the STUN request with the nomination = flag set, it should assume that the controlled endpoint did not honour= the nomination. But, again, I don=92t think the spec says anything about that. In fact, the text in section 7.1.1 seem= s to assume that nomination will always work:
   "Once the controlling agent has=
 selected a valid pair for nomination,
   it repeats the connectivity check that produced this valid pair (by
   enqueueing the pair that generated the check into the TRIGGERED CHECK
   QUEUE), this time with the USE-CANDIDATE attribute.  The connectivity
   check should succeed (since the previous did), causing the nominated
   flag value of that and only that pair to be set to true." 
the assumption seems to be that, as the nominated pair is in the valid= list, the nomination will always succeed.

But the spec says that the controlled side SHOULD honor the nomination= , which means it might not!  So that assumption is not correct (with t= he currently written text).

I think we need to forbid that =96 either by s= aying that the controlled endpoint MUST honour the nomination, OR by defini= ng how the controlled endpoint can explicitly indicate that it didn=92t hon= our.

I agree.  We should either make it MUST-level or we should define= what happens if the controlled side doesn't select.
 

Regards,

Christer

 --_000_D5D826AB212E6christerholmbergericssoncom_-- From nobody Mon Sep 11 06:09: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 9031F13307A for ; Mon, 11 Sep 2017 06:08:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.219 X-Spam-Level: X-Spam-Status: No, score=-4.219 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, 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 4jN3kD0YXoyT for ; Mon, 11 Sep 2017 06:08:57 -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 BFDB6132199 for ; Mon, 11 Sep 2017 06:08:56 -0700 (PDT) X-AuditID: c1b4fb2d-4e93a9c0000057a4-a5-59b68ae6cd08 Received: from ESESSHC001.ericsson.se (Unknown_Domain [153.88.183.21]) by sessmg23.ericsson.net (Symantec Mail Security) with SMTP id BD.DD.22436.6EA86B95; Mon, 11 Sep 2017 15:08:54 +0200 (CEST) Received: from ESESSMB109.ericsson.se ([169.254.9.194]) by ESESSHC001.ericsson.se ([153.88.183.21]) with mapi id 14.03.0352.000; Mon, 11 Sep 2017 15:08:53 +0200 From: Christer Holmberg To: "ice@ietf.org" Thread-Topic: Pull request: Candidate nomination rejection Thread-Index: AQHTKv8dds/hj0UYMk+bvgU9RIJWOA== Date: Mon, 11 Sep 2017 13:08:52 +0000 Message-ID: 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.17] Content-Type: multipart/alternative; boundary="_000_D5DC66C22142Achristerholmbergericssoncom_" MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFvrBLMWRmVeSWpSXmKPExsUyM2K7qO6zrm2RBnu6jSy+Xah1YPRYsuQn UwBjFJdNSmpOZllqkb5dAlfGl+8X2Ap6uSsevPBvYLzL2cXIySEhYCJx6+hEpi5GLg4hgSOM EtenTGGFcJYwSnw99p+5i5GDg03AQqL7nzZIg4iAosTMlmfMILawgKnEya1/2CDiVhIvGmZB 2XoSPQ92soLYLAKqEntefWQEGcMrYC1xqdUMJMwoICbx/dQaJhCbWUBc4taT+UwQ9whILNlz nhnCFpV4+fgfK0irKNDId/s9QUwJoAuW98tBdCZI/D50G6yaV0BQ4uTMJywTGIVmIRk6C0nZ LCRlEHEdiQW7P7FB2NoSyxa+Zoaxzxx4DNTLAWRbS9z6rYusZAEjxypG0eLU4uLcdCNjvdSi zOTi4vw8vbzUkk2MwPg4uOW37g7G1a8dDzEKcDAq8fBaF2+LFGJNLCuuzD3EKMHBrCTCq98K FOJNSaysSi3Kjy8qzUktPsQozcGiJM7rsO9ChJBAemJJanZqakFqEUyWiYNTqoFRZ2fNjp+y 6ftXb1jLHrjlrYXXDv08Y33dSw/43SYbzY4IuxDhfnL9mruvezvs183pvHvicVJe77Vr01pm /QndFN9WF7+Lb2M4E/Pm6FetqlPyf/gtmhK62vPLnT3Ft+aXLPNI3M/w8fYrO0W5TI6HRSbz zr38x8u755C987X8c9F8u3xiPnVsVGIpzkg01GIuKk4EAMkC0S6LAgAA Archived-At: Subject: [Ice] Pull request: Candidate nomination rejection 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, 11 Sep 2017 13:08:58 -0000 --_000_D5DC66C22142Achristerholmbergericssoncom_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi, I have created a PR, which adds procedure text (controlling agent) for when= a nomination request is rejected, and procedure text (controlled agent) fo= r rejecting a nomination. https://github.com/ice-wg/rfc5245bis/pull/44 Regards, Christer --_000_D5DC66C22142Achristerholmbergericssoncom_ Content-Type: text/html; charset="us-ascii" Content-ID: <07C68E8DA14B114E89F97BDCCE4865FF@ericsson.com> Content-Transfer-Encoding: quoted-printable
Hi,

I have created a PR, which adds procedure text (controlling agent) for= when a nomination request is rejected, and procedure text (controlled agen= t) for rejecting a nomination.


Regards,

Christer
--_000_D5DC66C22142Achristerholmbergericssoncom_-- From nobody Mon Sep 11 06:17: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 6D604133064 for ; Mon, 11 Sep 2017 06:17:03 -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, HTML_MESSAGE=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 26RPIm6Gxitj for ; Mon, 11 Sep 2017 06:17:01 -0700 (PDT) Received: from mail-qt0-x22f.google.com (mail-qt0-x22f.google.com [IPv6:2607:f8b0:400d:c0d::22f]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8125B133060 for ; Mon, 11 Sep 2017 06:17:01 -0700 (PDT) Received: by mail-qt0-x22f.google.com with SMTP id i50so18903789qtf.0 for ; Mon, 11 Sep 2017 06:17:01 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=jitsi-org.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to; bh=1SSUUmMVYLrzWxB7/bmekVQ+hHwtwGxT3J5zmh3AwMs=; b=miidKLYmX6o1tLnfG2P6W1heECQieEifo00cEpX2KQTWwYnmFthDJ6VvyA+nKPAh0O UZy9tybkSzg+QUeXx8v704in0ZUXKMnBV96ojlncnUMMVdiX53uSM5e18Wa6ekimCui1 6kO8tNUOg6I/ldIeK76jV+/CT27vi0TQV20M14DMRXRoJNumZpzby13Xl4B2zGdXAAqW HsF2jbgiwiu+3ujotamzFbs8M5OBp71twXsD4sG2K/E8MFAEuuuWblIne8Qnzsg0BI0a 6G7CjuWpGexC76OkQBhFtRmM3QYJwe2xTrjB1sFvUep1bNr4LCVyMPSYRTNtOwrdcTNk Cl2Q== 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=1SSUUmMVYLrzWxB7/bmekVQ+hHwtwGxT3J5zmh3AwMs=; b=HcTik/Sm1nBOuxPJnHTQOgwUe2fID75UTZNknRUH+bWBZm8kGa7IENPSgGBOHCrWKL dUq06qudJ51xBjfoCZsSy8v0uFe3e4HsSBXS/zz7OR316HJ8XdfazHU2E3Rj/HbDPCBT /PfO+fgMBRyno9Dvwhg4UYT2adTg2vUUvF0dqRHljaGBUqQVsSnvLH1RA7gnv55PsCYJ UepWcrZrSoWUxiABLhneAA0hnQG4h8bkQbxaecUp2bUn5fbg+g8LvSu8UQsTx/y4bR0k AAdGg0F1hCL1peIwnOJu7rSsBxkwwfE0c/VsJDbMMtijvW67VIeca4iLNnF+siLqU5Et e3HQ== X-Gm-Message-State: AHPjjUgnGJ94NfVo8sh2i+1kUMbkSu/s/QwIG4C/T2d33sSXoQiEH5lo AanpWYLETUwmUXU7Pd4fMXIgiedONhQ258E= X-Google-Smtp-Source: AOwi7QC9vm7XTiNLFDunoXkwuyeH7KooJgte8ECqGi1Usoe78OGh/19ei2UfAikJDtzNmML/0FLMdhEQiML4S58Iu24= X-Received: by 10.200.53.67 with SMTP id z3mr17051507qtb.145.1505135820606; Mon, 11 Sep 2017 06:17:00 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Emil Ivov Date: Mon, 11 Sep 2017 13:16:48 +0000 Message-ID: To: Christer Holmberg , "ice@ietf.org" Content-Type: multipart/alternative; boundary="001a114375e6ed5c8f0558e9bd62" Archived-At: Subject: Re: [Ice] Pull request: Candidate nomination rejection 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, 11 Sep 2017 13:17:03 -0000 --001a114375e6ed5c8f0558e9bd62 Content-Type: text/plain; charset="UTF-8" Could someone please remind what the larger goal is here? Emil On Mon, 11 Sep 2017 at 08:09, Christer Holmberg < christer.holmberg@ericsson.com> wrote: > Hi, > > I have created a PR, which adds procedure text (controlling agent) for > when a nomination request is rejected, and procedure text (controlled > agent) for rejecting a nomination. > > https://github.com/ice-wg/rfc5245bis/pull/44 > > Regards, > > Christer > _______________________________________________ > Ice mailing list > Ice@ietf.org > https://www.ietf.org/mailman/listinfo/ice > -- sent from my mobile --001a114375e6ed5c8f0558e9bd62 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Could someone please remind what the larger goal is = here?

Emil

On Mon, 11 Sep 2017 at 08:09, Christer Holmberg= <christer.holmberg@er= icsson.com> wrote:
Hi,

I have created a PR, which adds procedure text (controlling agent) for= when a nomination request is rejected, and procedure text (controlled agen= t) for rejecting a nomination.


Regards,

Christer
_______________________________________________
Ice mailing list
Ice@ietf.org
https://www.ietf.org/mailman/listinfo/ice
--
sent from my mobile
--001a114375e6ed5c8f0558e9bd62-- From nobody Mon Sep 11 06:21: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 6FACB132716 for ; Mon, 11 Sep 2017 06:21:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.219 X-Spam-Level: X-Spam-Status: No, score=-4.219 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, 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 45DCUgmmomqh for ; Mon, 11 Sep 2017 06:21:20 -0700 (PDT) Received: from sesbmg22.ericsson.net (sesbmg22.ericsson.net [193.180.251.48]) (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 525BD1326DF for ; Mon, 11 Sep 2017 06:21:19 -0700 (PDT) X-AuditID: c1b4fb30-57fff70000005897-0f-59b68dcd269c Received: from ESESSHC005.ericsson.se (Unknown_Domain [153.88.183.33]) by sesbmg22.ericsson.net (Symantec Mail Security) with SMTP id 56.C6.22679.DCD86B95; Mon, 11 Sep 2017 15:21:18 +0200 (CEST) Received: from ESESSMB109.ericsson.se ([169.254.9.194]) by ESESSHC005.ericsson.se ([153.88.183.33]) with mapi id 14.03.0352.000; Mon, 11 Sep 2017 15:21:17 +0200 From: Christer Holmberg To: Emil Ivov , "ice@ietf.org" Thread-Topic: [Ice] Pull request: Candidate nomination rejection Thread-Index: AQHTKv8dds/hj0UYMk+bvgU9RIJWOKKviOwAgAA084A= Date: Mon, 11 Sep 2017 13:21:17 +0000 Message-ID: References: In-Reply-To: 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.146] Content-Type: multipart/alternative; boundary="_000_D5DC699921445christerholmbergericssoncom_" MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFprHIsWRmVeSWpSXmKPExsUyM2K7ou653m2RBl9Pclus2TmBxeLbhVoH Jo8lS34yefx/ExjAFMVlk5Kak1mWWqRvl8CVcXn/QbaCtYoVtxe8ZmpgPCPbxcjJISFgIvHn 63O2LkYuDiGBI4wSeyaeYoFwljBKvJv3gqmLkYODTcBCovufNkiDiICdxLlJW5hAbGEBe4nu yW3sEHEHifnTp7BC2FYSU68tZAGxWQRUJaa17AGr4RWwlpjQdIIdYn4To8ShZ4fBEpwCgRIT 2+4xg9iMAmIS30+tAVvALCAucevJfCaISwUkluw5zwxhi0q8fPyPFeQ2UQE9iXf7PSHCShI/ NlxigWhNkLj/p5UJYq+gxMmZT1gmMIrMQjJ1FpKyWUjKIOI6Egt2f2KDsLUlli18zQxjnznw GKrXWuJxx0QWZDULGDlWMYoWpxYn5aYbGemlFmUmFxfn5+nlpZZsYgTG2sEtvw12ML587niI UYCDUYmHt6RkW6QQa2JZcWXuIUYJDmYlEV79VqAQb0piZVVqUX58UWlOavEhRmkOFiVxXsd9 FyKEBNITS1KzU1MLUotgskwcnFINjGHnkzZN+6B34NftvYVyQpuleOoWXVP3X9+4VcVHvOWD f9MR0a1HP0w+++8vB7/b7LqdgTum2EzMu/9ZR3Lnwci06Ki6zlO1n7dvT+NUvSqy3Pifd5At 47z+YxIz5k/k/xYVctLutefZzuXlebknMuT3uxQqrct3TJtkec/y+4FH04oF9rR8vq7EUpyR aKjFXFScCAAosX3MsQIAAA== Archived-At: Subject: Re: [Ice] Pull request: Candidate nomination rejection 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, 11 Sep 2017 13:21:22 -0000 --_000_D5DC699921445christerholmbergericssoncom_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Publication of the RFC. From: Emil Ivov > Date: Monday 11 September 2017 at 16:16 To: Christer Holmberg >, "ice@ietf.org" > Subject: Re: [Ice] Pull request: Candidate nomination rejection Could someone please remind what the larger goal is here? Emil On Mon, 11 Sep 2017 at 08:09, Christer Holmberg > wrote: Hi, I have created a PR, which adds procedure text (controlling agent) for when= a nomination request is rejected, and procedure text (controlled agent) fo= r rejecting a nomination. https://github.com/ice-wg/rfc5245bis/pull/44 Regards, Christer _______________________________________________ Ice mailing list Ice@ietf.org https://www.ietf.org/mailman/listinfo/ice -- sent from my mobile --_000_D5DC699921445christerholmbergericssoncom_ Content-Type: text/html; charset="us-ascii" Content-ID: Content-Transfer-Encoding: quoted-printable
Publication of the RFC.

From: Emil Ivov <emcho@jitsi.org>
Date: Monday 11 September 2017 at 1= 6:16
To: Christer Holmberg <christer.holmberg@ericsson.com>, "ice@ietf.org" <ice@ietf.org>
Subject: Re: [Ice] Pull request: Ca= ndidate nomination rejection

Could someone please remind what the larger goal is here?=

Emil

On Mon, 11 Sep 2017 at 08:09, Christer Holmberg <christer.holmberg@ericsson.com> wrot= e:
Hi,

I have created a PR, which adds procedure text (controlling agent) for= when a nomination request is rejected, and procedure text (controlled agen= t) for rejecting a nomination.


Regards,

Christer
_______________________________________________
Ice mailing list
Ice@ietf.org
https://www.ietf.org/mailman/listinfo/ice
--
sent from= my mobile
 --_000_D5DC699921445christerholmbergericssoncom_-- From nobody Mon Sep 11 06:24:13 2017 Return-Path: X-Original-To: ice@ietfa.amsl.com Delivered-To: ice@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3F39C133079 for ; Mon, 11 Sep 2017 06:24:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.219 X-Spam-Level: X-Spam-Status: No, score=-4.219 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, 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 HPpVQJO4rRhl for ; Mon, 11 Sep 2017 06:24:07 -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 49340133060 for ; Mon, 11 Sep 2017 06:24:07 -0700 (PDT) X-AuditID: c1b4fb3a-617ff700000051a3-c7-59b68e75530f Received: from ESESSHC015.ericsson.se (Unknown_Domain [153.88.183.63]) by sessmg22.ericsson.net (Symantec Mail Security) with SMTP id C2.E9.20899.57E86B95; Mon, 11 Sep 2017 15:24:05 +0200 (CEST) Received: from ESESSMB109.ericsson.se ([169.254.9.194]) by ESESSHC015.ericsson.se ([153.88.183.63]) with mapi id 14.03.0352.000; Mon, 11 Sep 2017 15:24:05 +0200 From: Christer Holmberg To: Christer Holmberg , Emil Ivov , "ice@ietf.org" Thread-Topic: [Ice] Pull request: Candidate nomination rejection Thread-Index: AQHTKv8dds/hj0UYMk+bvgU9RIJWOKKviOwAgAA084CAAADIAA== Date: Mon, 11 Sep 2017 13:24:04 +0000 Message-ID: References: In-Reply-To: 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.147] Content-Type: multipart/alternative; boundary="_000_D5DC69E421449christerholmbergericssoncom_" MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFprFIsWRmVeSWpSXmKPExsUyM2K7vW5p37ZIg9/PFS3W7JzAYvHtQq0D k8eSJT+ZPP6/CQxgiuKySUnNySxLLdK3S+DKOPrmGGPBcZOKGYs6mBsY9+l1MXJwSAiYSKza ydbFyMUhJHCEUaJ1+WEmCGcJo8SRGbfZQIrYBCwkuv9pdzFycogIlEjsPNjKBGILC9hLdE9u Y4eIO0jMnz6FFcJ2kvj37D4rSCuLgKrE9hUZICavgLXE0V8RENO3MEo8bfnMAlLOKWAjcX7Z QzCbUUBM4vupNWDjmQXEJW49mQ9mSwgISCzZc54ZwhaVePn4H9h4UQE9iXf7PSE+UZKYtjUN ojNB4l/XFrCJvAKCEidnPmGZwCgyC8nQWUjKZiEpg4jrSCzY/YkNwtaWWLbwNTOMfebAY6he a4nm/dMYkdUsYORYxShanFpcnJtuZKSXWpSZXFycn6eXl1qyiREYYwe3/LbawXjwueMhRgEO RiUeXoHibZFCrIllxZW5hxglOJiVRHj1W4FCvCmJlVWpRfnxRaU5qcWHGKU5WJTEeR32XYgQ EkhPLEnNTk0tSC2CyTJxcEo1MJZuqLnxfO8vs7WFa1/0fso7zjrzqfeX8sxsnbicpG2B/Eus 5l76v/Jqc+rtgNfyqitXXKr98p1deu3yQwc8GYTjGuZWu3t5ODwIO71e0ELdq/nW3qAoK/aO sLS7b1ozek/MXLZQNEBBQFls/bOpbbe8nvy3Cr67/fPiNxW2Eo8LmToUCq4WqCixFGckGmox FxUnAgCYZ+1hrQIAAA== Archived-At: Subject: Re: [Ice] Pull request: Candidate nomination rejection 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, 11 Sep 2017 13:24:12 -0000 --_000_D5DC69E421449christerholmbergericssoncom_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Seriously, these are two questions that have come up: 1) What if a nomination request fails? 2) How can the controlled agent explicitly reject a nomination? The PR suggests answers to those questions. Regards, Christer From: Ice > on behalf of = Christer Holmberg > Date: Monday 11 September 2017 at 16:21 To: Emil Ivov >, "ice@ietf.org" > Subject: Re: [Ice] Pull request: Candidate nomination rejection Publication of the RFC. From: Emil Ivov > Date: Monday 11 September 2017 at 16:16 To: Christer Holmberg >, "ice@ietf.org" > Subject: Re: [Ice] Pull request: Candidate nomination rejection Could someone please remind what the larger goal is here? Emil On Mon, 11 Sep 2017 at 08:09, Christer Holmberg > wrote: Hi, I have created a PR, which adds procedure text (controlling agent) for when= a nomination request is rejected, and procedure text (controlled agent) fo= r rejecting a nomination. https://github.com/ice-wg/rfc5245bis/pull/44 Regards, Christer _______________________________________________ Ice mailing list Ice@ietf.org https://www.ietf.org/mailman/listinfo/ice -- sent from my mobile --_000_D5DC69E421449christerholmbergericssoncom_ Content-Type: text/html; charset="us-ascii" Content-ID: <54FAFA4C504EA247914BD353FFA8F97B@ericsson.com> Content-Transfer-Encoding: quoted-printable
Seriously, these are two questions that have come up:

1) Wha= t if a nomination request fails?
2) How= can the controlled agent explicitly reject a nomination?

The PR suggests answers to those questions.

Regards,

Christer


From: Ice <ice-bounces@ietf.org> on behalf of Christer Holmb= erg <christer.holmberg= @ericsson.com>
Date: Monday 11 September 2017 at 1= 6:21
To: Emil Ivov <emcho@jitsi.org>, "ice@ietf.org" <ice@ietf.o= rg>
Subject: Re: [Ice] Pull request: Ca= ndidate nomination rejection

Publication of the RFC.

From: Emil Ivov <emcho@jitsi.org>
Date: Monday 11 September 2017 at 1= 6:16
To: Christer Holmberg <christer.holmberg@ericsson.com>, "ice@ietf.org" <ice@ietf.org>
Subject: Re: [Ice] Pull request: Ca= ndidate nomination rejection

Could someone please remind what the larger goal is here?=

Emil

On Mon, 11 Sep 2017 at 08:09, Christer Holmberg <christer.holmberg@ericsson.com> wrot= e:
Hi,

I have created a PR, which adds procedure text (controlling agent) for= when a nomination request is rejected, and procedure text (controlled agen= t) for rejecting a nomination.


Regards,

Christer
_______________________________________________
Ice mailing list
Ice@ietf.org
https://www.ietf.org/mailman/listinfo/ice
--
sent from= my mobile
 --_000_D5DC69E421449christerholmbergericssoncom_-- From nobody Mon Sep 11 07:23:55 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 465A713309E for ; Mon, 11 Sep 2017 07:23:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, 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 79xIxgLrM0x1 for ; Mon, 11 Sep 2017 07:23:50 -0700 (PDT) Received: from mail-qt0-x22d.google.com (mail-qt0-x22d.google.com [IPv6:2607:f8b0:400d:c0d::22d]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CF6BB1330A2 for ; Mon, 11 Sep 2017 07:23:48 -0700 (PDT) Received: by mail-qt0-x22d.google.com with SMTP id m35so19332091qte.1 for ; Mon, 11 Sep 2017 07:23:48 -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; bh=6YeQBQOgRqSB1mkSnSwinGZdCveJTq76FOfrgOZJ5yk=; b=WbZPG4mBgZkqfLMYbmCikkt3N8w5dQZDVSuHHKTaKczi765mAbpPybef6RddPkjY9U vMnDRVSFD1PcUCkHLjHkyf+11f31W2nDBauF8buwmrV6a5AlkCrrTCNrlDuOPq1waynh HFAIncAik0rXCM/+ytTSZvw5cmzc3SDlSl2PLBO3hOZ1U4JeuogoUvx4IZVei6tucxK2 WlKiGzW5ZK/zK5oJkyTEz4DBYJ4ZXgMrdmp2svvIh9vPIQ6o4RRpw3N7OXkVcApPfnoh 28eexcdTwZPK0o5ABH8Yyizn0yfJJVmOfjDJ1d2ghP0PLNvVSanXPpKPTt5eNW+fKONR HOFg== 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=6YeQBQOgRqSB1mkSnSwinGZdCveJTq76FOfrgOZJ5yk=; b=VCtYqeqqncJN8tHc9nBZTWJ9l9Nm6+ulWvTwA6TOtYmkdQo+Dq7YcekFsByI43DvFW 9Veq8HlbT9SF8shhqkCWuo9VfTt9Ht+GltSvBKTBT2OSf/TXEwpYxQwvCwiG0NryzLRM 7QjRGvhySxznxuvgQmfPqDsqTKQHK7x9NOMbqtAfQ7EhBuO4pCkCUzMtTY1kGF2YObNg bpn4WDOwv2DVVq/HlF7q3uzWigFbdx14konZFHjnvYPYpyttZoELuQ8FZOT4OUIA6qlm SkE0fIkttdIWV6Tqt0s1+LsBELad1i3DockZkBF2LVMygh92K3nq3YQ2jjGm4r2UNQ4I cMNA== X-Gm-Message-State: AHPjjUgLgemxmwbNT1N2nETSHswg8d1IKST5SAg5Sgsdpddu0qKAyh6e 8uxbeAGdHiXrbn8dmYprzpZyQ+WABv5l X-Google-Smtp-Source: AOwi7QBL4GOcJ4k7bwqfiiBQdjA+75E3iv4im2z8kZnKU8I7G3rAXXQEx/5K4EKtqmCS9DDTELGp7lTAeov9ZKjYdso= X-Received: by 10.200.40.117 with SMTP id 50mr10039051qtr.167.1505139827890; Mon, 11 Sep 2017 07:23:47 -0700 (PDT) MIME-Version: 1.0 Received: by 10.200.4.139 with HTTP; Mon, 11 Sep 2017 07:23:27 -0700 (PDT) In-Reply-To: References: From: Emil Ivov Date: Mon, 11 Sep 2017 09:23:27 -0500 Message-ID: To: Christer Holmberg Cc: "ice@ietf.org" Content-Type: text/plain; charset="UTF-8" Archived-At: Subject: Re: [Ice] Pull request: Candidate nomination rejection 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, 11 Sep 2017 14:23:53 -0000 Thanks Christer, I did gather that much, but I was just wondering why we are talking about rejecting nominations and then not saying why you would do it. In other words, as a controlling agent what am I supposed to do with a rejection? Without the current text I probably would have failed ICE processing because I don't want to guess the reasons the controlled had for doing it. The new text doesn't help me with this. Emil On Mon, Sep 11, 2017 at 8:24 AM, Christer Holmberg wrote: > Seriously, these are two questions that have come up: > > 1) What if a nomination request fails? > 2) How can the controlled agent explicitly reject a nomination? > > The PR suggests answers to those questions. > > Regards, > > Christer > > > From: Ice on behalf of Christer Holmberg > > Date: Monday 11 September 2017 at 16:21 > To: Emil Ivov , "ice@ietf.org" > Subject: Re: [Ice] Pull request: Candidate nomination rejection > > Publication of the RFC. > > From: Emil Ivov > Date: Monday 11 September 2017 at 16:16 > To: Christer Holmberg , "ice@ietf.org" > > Subject: Re: [Ice] Pull request: Candidate nomination rejection > > Could someone please remind what the larger goal is here? > > Emil > > On Mon, 11 Sep 2017 at 08:09, Christer Holmberg > wrote: >> >> Hi, >> >> I have created a PR, which adds procedure text (controlling agent) for >> when a nomination request is rejected, and procedure text (controlled agent) >> for rejecting a nomination. >> >> https://github.com/ice-wg/rfc5245bis/pull/44 >> >> Regards, >> >> Christer >> _______________________________________________ >> Ice mailing list >> Ice@ietf.org >> https://www.ietf.org/mailman/listinfo/ice > > -- > sent from my mobile -- https://jitsi.org From nobody Mon Sep 11 07:51: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 5AA411321C9 for ; Mon, 11 Sep 2017 07:51: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 VtnVAMFIsYwq for ; Mon, 11 Sep 2017 07:51:41 -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 14DED1321B6 for ; Mon, 11 Sep 2017 07:51:40 -0700 (PDT) X-AuditID: c1b4fb2d-11bff700000057a4-5f-59b6a2fa742a Received: from ESESSHC013.ericsson.se (Unknown_Domain [153.88.183.57]) by sessmg23.ericsson.net (Symantec Mail Security) with SMTP id 14.52.22436.AF2A6B95; Mon, 11 Sep 2017 16:51:39 +0200 (CEST) Received: from ESESSMB109.ericsson.se ([169.254.9.194]) by ESESSHC013.ericsson.se ([153.88.183.57]) with mapi id 14.03.0352.000; Mon, 11 Sep 2017 16:51:38 +0200 From: Christer Holmberg To: Emil Ivov CC: "ice@ietf.org" Thread-Topic: [Ice] Pull request: Candidate nomination rejection Thread-Index: AQHTKv8dds/hj0UYMk+bvgU9RIJWOKKviOwAgAA084CAAADIAP//3OSAgAAonAA= Date: Mon, 11 Sep 2017 14:51:37 +0000 Message-ID: <7594FB04B1934943A5C02806D1A2204B562AA63A@ESESSMB109.ericsson.se> References: 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-Transfer-Encoding: base64 MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFvrGLMWRmVeSWpSXmKPExsUyM2K7pe7vRdsiDf5NY7ZYs3MCi8W3C7UO TB5Llvxk8vj/JjCAKYrLJiU1J7MstUjfLoErY+63z0wFEyQrLrT3Mjcw7pHoYuTkkBAwkfjf 84YZxBYSOMIo8epyXRcjF5C9hFHi1puNTF2MHBxsAhYS3f+0QWpEBOQlutsWgYWZBRQlXu5V AwkLC9hLrJz9hBmixEFi/vQprBC2n8TPdUuZQcpZBFQlumazgIR5BXwl1vXvYYHYtJZJYt6i KUwgCU6BQIm7a6YxgtiMAmIS30+tAYszC4hL3HoynwniZAGJJXvOM0PYohIvH/9jhbCVJFZs v8QIcZqmxPpd+hCtihJTuh+yQ+wVlDg58wnLBEbRWUimzkLomIWkYxaSjgWMLKsYRYtTi4tz 042M9VKLMpOLi/Pz9PJSSzYxAmPj4JbfujsYV792PMQowMGoxMN7cOK2SCHWxLLiytxDjBIc zEoivB0LgUK8KYmVValF+fFFpTmpxYcYpTlYlMR5HfZdiBASSE8sSc1OTS1ILYLJMnFwSjUw LjzYvEX1qfbGpes9ZmXpFs0+7HFPz/0p+wq26dW8RQIVXF17tHclHAzb6jx/zrPrQtEnN/0M 38ycN3P6FOPinUxxB1boRJ8UlWbZxmW6x7zDZNXeqwdMWW5uF71UYKTzvZq1/KD8luTKI++P Pm+zla4K+rR39pY9G9d3pWsv2eUS8vRHSkHkFyWW4oxEQy3mouJEAIFq6ZOJAgAA Archived-At: Subject: Re: [Ice] Pull request: Candidate nomination rejection 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, 11 Sep 2017 14:51:43 -0000 SGksDQoNCj5JIGRpZCBnYXRoZXIgdGhhdCBtdWNoLCBidXQgSSB3YXMganVzdCB3b25kZXJpbmcg d2h5IHdlIGFyZSB0YWxraW5nIGFib3V0IHJlamVjdGluZyA+bm9taW5hdGlvbnMgYW5kIHRoZW4g bm90IHNheWluZyB3aHkgeW91IHdvdWxkIGRvIGl0Lg0KDQpXZSBkaWQgZGlzY3VzcyB3aGV0aGVy IG9uZSBzaG91bGQgYmUgYWxsb3dlZCB0byByZWplY3QgYSBub21pbmF0aW9uIGluIHRoZSBmaXJz dCBwbGFjZS4NCg0KUGVyaGFwcyB0aGUgcGFpciBpcyB1c2luZyBhIHZlcnkgYmFkL2V4cGVuc2l2 ZS9zbG93IGNvbm5lY3Rpb24uDQoNCj5JbiBvdGhlciB3b3JkcywgYXMgYSBjb250cm9sbGluZyBh Z2VudCB3aGF0IGFtIEkgc3VwcG9zZWQgdG8gZG8gd2l0aCBhIHJlamVjdGlvbj8gV2l0aG91dCA+ dGhlIGN1cnJlbnQgdGV4dCBJIHByb2JhYmx5IHdvdWxkIGhhdmUgZmFpbGVkIElDRSBwcm9jZXNz aW5nIGJlY2F1c2UgSSBkb24ndCB3YW50IHRvIGd1ZXNzID50aGUgcmVhc29ucyB0aGUgY29udHJv bGxlZCBoYWQgZm9yIGRvaW5nIGl0LiBUaGUgbmV3IHRleHQgZG9lc24ndCBoZWxwIG1lIHdpdGgg dGhpcy4NCg0KVGhlIG5ldyB0ZXh0IHNheXMgdGhhdCB0aGUgY29udHJvbGxpbmcgYWdlbnQgY2Fu IGNob29zZSBhbm90aGVyIHBhaXIsIG9yIHNldCB0aGUgY2hlY2sgbGlzdCBzdGF0ZSB0byBmYWls ZWQuIFRoZSBvbGQgdGV4dCBtb3JlIG9yIGxlc3MgYXNzdW1lZCB0aGF0IHRoZSBub21pbmF0aW9u IHdvdWxkIHN1Y2NlZWQuDQoNClJlZ2FyZHMsDQoNCkNocmlzdGVyDQoNCg0KT24gTW9uLCBTZXAg MTEsIDIwMTcgYXQgODoyNCBBTSwgQ2hyaXN0ZXIgSG9sbWJlcmcgPGNocmlzdGVyLmhvbG1iZXJn QGVyaWNzc29uLmNvbT4gd3JvdGU6DQo+IFNlcmlvdXNseSwgdGhlc2UgYXJlIHR3byBxdWVzdGlv bnMgdGhhdCBoYXZlIGNvbWUgdXA6DQo+DQo+IDEpIFdoYXQgaWYgYSBub21pbmF0aW9uIHJlcXVl c3QgZmFpbHM/DQo+IDIpIEhvdyBjYW4gdGhlIGNvbnRyb2xsZWQgYWdlbnQgZXhwbGljaXRseSBy ZWplY3QgYSBub21pbmF0aW9uPw0KPg0KPiBUaGUgUFIgc3VnZ2VzdHMgYW5zd2VycyB0byB0aG9z ZSBxdWVzdGlvbnMuDQo+DQo+IFJlZ2FyZHMsDQo+DQo+IENocmlzdGVyDQo+DQo+DQo+IEZyb206 IEljZSA8aWNlLWJvdW5jZXNAaWV0Zi5vcmc+IG9uIGJlaGFsZiBvZiBDaHJpc3RlciBIb2xtYmVy ZyANCj4gPGNocmlzdGVyLmhvbG1iZXJnQGVyaWNzc29uLmNvbT4NCj4gRGF0ZTogTW9uZGF5IDEx IFNlcHRlbWJlciAyMDE3IGF0IDE2OjIxDQo+IFRvOiBFbWlsIEl2b3YgPGVtY2hvQGppdHNpLm9y Zz4sICJpY2VAaWV0Zi5vcmciIDxpY2VAaWV0Zi5vcmc+DQo+IFN1YmplY3Q6IFJlOiBbSWNlXSBQ dWxsIHJlcXVlc3Q6IENhbmRpZGF0ZSBub21pbmF0aW9uIHJlamVjdGlvbg0KPg0KPiBQdWJsaWNh dGlvbiBvZiB0aGUgUkZDLg0KPg0KPiBGcm9tOiBFbWlsIEl2b3YgPGVtY2hvQGppdHNpLm9yZz4N Cj4gRGF0ZTogTW9uZGF5IDExIFNlcHRlbWJlciAyMDE3IGF0IDE2OjE2DQo+IFRvOiBDaHJpc3Rl ciBIb2xtYmVyZyA8Y2hyaXN0ZXIuaG9sbWJlcmdAZXJpY3Nzb24uY29tPiwgImljZUBpZXRmLm9y ZyINCj4gPGljZUBpZXRmLm9yZz4NCj4gU3ViamVjdDogUmU6IFtJY2VdIFB1bGwgcmVxdWVzdDog Q2FuZGlkYXRlIG5vbWluYXRpb24gcmVqZWN0aW9uDQo+DQo+IENvdWxkIHNvbWVvbmUgcGxlYXNl IHJlbWluZCB3aGF0IHRoZSBsYXJnZXIgZ29hbCBpcyBoZXJlPw0KPg0KPiBFbWlsDQo+DQo+IE9u IE1vbiwgMTEgU2VwIDIwMTcgYXQgMDg6MDksIENocmlzdGVyIEhvbG1iZXJnIA0KPiA8Y2hyaXN0 ZXIuaG9sbWJlcmdAZXJpY3Nzb24uY29tPiB3cm90ZToNCj4+DQo+PiBIaSwNCj4+DQo+PiBJIGhh dmUgY3JlYXRlZCBhIFBSLCB3aGljaCBhZGRzIHByb2NlZHVyZSB0ZXh0IChjb250cm9sbGluZyBh Z2VudCkgDQo+PiBmb3Igd2hlbiBhIG5vbWluYXRpb24gcmVxdWVzdCBpcyByZWplY3RlZCwgYW5k IHByb2NlZHVyZSB0ZXh0IA0KPj4gKGNvbnRyb2xsZWQgYWdlbnQpIGZvciByZWplY3RpbmcgYSBu b21pbmF0aW9uLg0KPj4NCj4+IGh0dHBzOi8vZ2l0aHViLmNvbS9pY2Utd2cvcmZjNTI0NWJpcy9w dWxsLzQ0DQo+Pg0KPj4gUmVnYXJkcywNCj4+DQo+PiBDaHJpc3Rlcg0KPj4gX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCj4+IEljZSBtYWlsaW5nIGxpc3QN Cj4+IEljZUBpZXRmLm9yZw0KPj4gaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5m by9pY2UNCj4NCj4gLS0NCj4gc2VudCBmcm9tIG15IG1vYmlsZQ0KDQoNCg0KLS0NCmh0dHBzOi8v aml0c2kub3JnDQo= From nobody Mon Sep 11 10:07:18 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 D0300133143 for ; Mon, 11 Sep 2017 10:07:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.699 X-Spam-Level: X-Spam-Status: No, score=-2.699 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, 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 0BHEm8vuSEgi for ; Mon, 11 Sep 2017 10:07:14 -0700 (PDT) Received: from mail-wm0-x230.google.com (mail-wm0-x230.google.com [IPv6:2a00:1450:400c: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 6E0F9132ED3 for ; Mon, 11 Sep 2017 10:07:14 -0700 (PDT) Received: by mail-wm0-x230.google.com with SMTP id f199so44811260wme.0 for ; Mon, 11 Sep 2017 10:07:14 -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=gIFAf6IT85gt0DNMgAgdCt/rFj90sWA4+n9PDdqVOv8=; b=eI6nt7pNzU2+hjBdYXjF+I06x3/knbN+s+5NPdDE348EugGZfrCl0FOUIGL+GSNqj+ tuoUbueGjnWd1BZ9B78QChFmYP9dTCuUYVSf2LIo/A+Vn8Q8z+xWFvmhacX9gs5CXWO5 GBF80WAQi9IP0kHXhWctPNTBrDz+osv1qah22ik00pIPOgknlKHT8pgsUEzZGLXt93GK +jPYFjqkrlxXxoO+GXeeodstA87qDmwpJmek4sKH77/xNQi+XkEcvyC3bI/c2QEcGBlz Z68YqQ8xClOy2h3UleoDyvVeUvhZWdzcGlYofTAOXapv2oHtMiOMsUxP/2tkXBMu1JRi SqEw== 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=gIFAf6IT85gt0DNMgAgdCt/rFj90sWA4+n9PDdqVOv8=; b=dC8dEfK/yXntNzJKx3f+M2K4EoSCPSdr2AAg6Z4BP7DJCx4eHpKPvstUeeT4DnD7sj sYcU+Uup5oEvxQyAlLfg3VAXmo6+kp7sjRdkpHxvEAueI06EBTGR0SRWWzoFQTPE4itT lreW9kjI0m3b51y2WhAX3J2sraRqv1xTlpsM7xHyBMiySIcRza2SdxtfPFK1OQwkjjc2 wliPQofJfKy+MVGJiCRCZkWtUEWN/9JP22bfpQ1CZK8QvfhkAHSTmiICAodBfuN+iFDE ga3IWa9CUFEis7CCC6P+PDz7/VRuJmHF9CPeXOZlVxJllSOIql0zPSgFPmo51cSoB224 /zEw== X-Gm-Message-State: AHPjjUjlSHPDM5ajH5xo8j1hJeoTMW0lTMR/J/xE4q6DzPrTevrsIy2Q lYrBvqbYg+g3JEsnwqf4IJiz8P4qS74F X-Google-Smtp-Source: AOwi7QBcnXRgBtpIFIS1NPoZj//+Q3B9f7sVyn6ffC5JKH8O5dSTpWUg6gYRdogVVilA2i9H5DAXC1MdI6Odco2SElI= X-Received: by 10.28.54.101 with SMTP id d98mr7949313wma.90.1505149632433; Mon, 11 Sep 2017 10:07:12 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Peter Thatcher Date: Mon, 11 Sep 2017 17:07:01 +0000 Message-ID: To: Christer Holmberg , "ice@ietf.org" Content-Type: multipart/alternative; boundary="001a11436bb22e3d490558ecf59e" Archived-At: Subject: Re: [Ice] Pull request: Candidate nomination rejection 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, 11 Sep 2017 17:07:17 -0000 --001a11436bb22e3d490558ecf59e Content-Type: text/plain; charset="UTF-8" I think the goal of first part of the PR is good, where we specify/clarify what to do when the nomination STUN transaction fails. But I think there is a problem with the option of "nominate another pair": if the transaction fails because the request is delayed on the network (such that the transaction times out) then the controlled side will see a nomination, but the controlling side won't know that it did. So the controlling side will then nominate a different pair, and the controlling side will see two nominations, possibly with the first arriving last, and the two sides will be out of sync. I think it might be better to just say the controlling side must set the check list to the failed state. It's probably a very rare situation anyway, and if we think we need better, there's always an ICE extension like renomination :). As for the "controlled side can reject the nomination" part of the PR: if we keep the "controlling side may nominate another pair" rule, but only if the controlled side rejected it (not because of STUN transaction timeout), then I could see the problem I pointed out above not being a problem any more. But I'm not sure we want to go down this path "controlling side keeps nominating until the controlled side accepts" thing. I think it would be more simple to just say the controlled side MUST accept the transaction or the check list goes to the failed state. On Mon, Sep 11, 2017 at 6:09 AM Christer Holmberg < christer.holmberg@ericsson.com> wrote: > Hi, > > I have created a PR, which adds procedure text (controlling agent) for > when a nomination request is rejected, and procedure text (controlled > agent) for rejecting a nomination. > > https://github.com/ice-wg/rfc5245bis/pull/44 > > Regards, > > Christer > _______________________________________________ > Ice mailing list > Ice@ietf.org > https://www.ietf.org/mailman/listinfo/ice > --001a11436bb22e3d490558ecf59e Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
I think the goal of first part of the PR is good, where we= specify/clarify what to do when the nomination STUN transaction fails. =C2= =A0

But I think there is a problem with the option of &q= uot;nominate another pair": =C2=A0if the transaction fails because the= request is delayed on the network (such that the transaction times out) th= en the controlled side will see a nomination, but the controlling side won&= #39;t know that it did.=C2=A0 So the controlling side will then nominate a = different pair, and the controlling side will see two nominations, possibly= with the first arriving last, and the two sides will be out of sync.=C2=A0=

I think it might be better to just say the contro= lling side must set the check list to the failed state.=C2=A0 It's prob= ably a very rare situation anyway, and if we think we need better, there= 9;s always an ICE extension like renomination :).

=
As for the "controlled side can reject the nomination&q= uot; part of the PR: if we keep the "controlling side may nominate ano= ther pair" rule, but only if the controlled side rejected it (not beca= use of STUN transaction timeout), then I could see the problem I pointed ou= t above not being a problem any more.=C2=A0 But I'm not sure we want to= go down this path "controlling side keeps nominating until the contro= lled side accepts" thing.=C2=A0 I think it would be more simple to jus= t say the controlled side MUST accept the transaction or the check list goe= s to the failed state.





On M= on, Sep 11, 2017 at 6:09 AM Christer Holmberg <christer.holmberg@ericsson.com> wrote:
<= /div>
Hi,

I have created a PR, which adds procedure text (controlling agent) for= when a nomination request is rejected, and procedure text (controlled agen= t) for rejecting a nomination.


Regards,

Christer
_______________________________________________
Ice mailing list
Ice@ietf.org
https://www.ietf.org/mailman/listinfo/ice
--001a11436bb22e3d490558ecf59e-- From nobody Mon Sep 11 12:47: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 8D7C0132F35 for ; Mon, 11 Sep 2017 12:46:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.219 X-Spam-Level: X-Spam-Status: No, score=-4.219 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, 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 mnN8gRbyVWJg for ; Mon, 11 Sep 2017 12:46:54 -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 EE8871331DD for ; Mon, 11 Sep 2017 12:46:53 -0700 (PDT) X-AuditID: c1b4fb2d-11bff700000057a4-8a-59b6e82b6ed2 Received: from ESESSHC010.ericsson.se (Unknown_Domain [153.88.183.48]) by sessmg23.ericsson.net (Symantec Mail Security) with SMTP id C1.A6.22436.B28E6B95; Mon, 11 Sep 2017 21:46:51 +0200 (CEST) Received: from ESESSMB109.ericsson.se ([169.254.9.194]) by ESESSHC010.ericsson.se ([153.88.183.48]) with mapi id 14.03.0352.000; Mon, 11 Sep 2017 21:46:51 +0200 From: Christer Holmberg To: Peter Thatcher , "ice@ietf.org" Thread-Topic: [Ice] Pull request: Candidate nomination rejection Thread-Index: AQHTKv8dds/hj0UYMk+bvgU9RIJWOKKvyT+AgABLcuA= Date: Mon, 11 Sep 2017 19:46:50 +0000 Message-ID: <7594FB04B1934943A5C02806D1A2204B562AAAD5@ESESSMB109.ericsson.se> References: 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: multipart/alternative; boundary="_000_7594FB04B1934943A5C02806D1A2204B562AAAD5ESESSMB109erics_" MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFmplkeLIzCtJLcpLzFFi42KZGbHdQFf7xbZIgz0X9C2+Xai1uLb8NasD k8eCTaUeS5b8ZApgiuKySUnNySxLLdK3S+DKuLCzn7lgWkXFnY+zWBoYf5R0MXJySAiYSFy8 8pKti5GLQ0jgCKPEup3TWUESQgJLGCV2Xa/uYuTgYBOwkOj+pw0SFhHwkNj8ZjkbiC0sYC+x cvYTZoi4g8T86VNYIWwriUlL7zKC2CwCqhIvtl4Fi/MK+Eq8OvQYalcTo8SpSadYQBKcAoES ixd/YQexGQXEJL6fWsMEYjMLiEvcejKfCeJQAYkle84zQ9iiEi8f/2OFsJUkGpc8YYWoz5fY 3XeXGWKZoMTJmU9YJjAKz0IyahaSsllIymYBvcksoCmxfpc+RImixJTuh+wQtoZE65y57Mji CxjZVzGKFqcWF+emGxnrpRZlJhcX5+fp5aWWbGIERs7BLb91dzCufu14iFGAg1GJh1f+1LZI IdbEsuLK3EOMEhzMSiK8Ig+BQrwpiZVVqUX58UWlOanFhxilOViUxHkd9l2IEBJITyxJzU5N LUgtgskycXBKNTCKG2Xsd+vKqnj/8sclDs5M08UFQcetNs9y0HdtD8pPPPDxW+n1bBtHT6v+ wG7zOXppUYxTH+TOUbMSP77m/+FghTXezGytx623nY6faXzz6Zt07urlRftT9KVNvrlePHem YLFN82Uek30VU3J/aE9veKc+Qzb6U6rIASdP90cLrzI6v7MMj1ZiKc5INNRiLipOBACW0P74 mAIAAA== Archived-At: Subject: Re: [Ice] Pull request: Candidate nomination rejection 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, 11 Sep 2017 19:46:56 -0000 --_000_7594FB04B1934943A5C02806D1A2204B562AAAD5ESESSMB109erics_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SGksDQoNCj5JIHRoaW5rIHRoZSBnb2FsIG9mIGZpcnN0IHBhcnQgb2YgdGhlIFBSIGlzIGdvb2Qs IHdoZXJlIHdlIHNwZWNpZnkvY2xhcmlmeSB3aGF0IHRvIGRvIHdoZW4gdGhlIG5vbWluYXRpb24g U1RVTiB0cmFuc2FjdGlvbiBmYWlscy4NCj4NCj5CdXQgSSB0aGluayB0aGVyZSBpcyBhIHByb2Js ZW0gd2l0aCB0aGUgb3B0aW9uIG9mICJub21pbmF0ZSBhbm90aGVyIHBhaXIiOiAgaWYgdGhlIHRy YW5zYWN0aW9uIGZhaWxzIGJlY2F1c2UgdGhlIHJlcXVlc3QgaXMgZGVsYXllZCBvbiB0aGUgbmV0 d29yayAoc3VjaCB0aGF0ID50aGUgdHJhbnNhY3Rpb24gdGltZXMgb3V0KSB0aGVuIHRoZSBjb250 cm9sbGVkIHNpZGUgd2lsbCBzZWUgYSBub21pbmF0aW9uLCBidXQgdGhlIGNvbnRyb2xsaW5nIHNp ZGUgd29uJ3Qga25vdyB0aGF0IGl0IGRpZC4gIFNvIHRoZSBjb250cm9sbGluZyBzaWRlIHdpbGwg dGhlbiA+bm9taW5hdGUgYSBkaWZmZXJlbnQgcGFpciwgYW5kIHRoZSBjb250cm9sbGluZyBzaWRl IHdpbGwgc2VlIHR3byBub21pbmF0aW9ucywgcG9zc2libHkgd2l0aCB0aGUgZmlyc3QgYXJyaXZp bmcgbGFzdCwgYW5kIHRoZSB0d28gc2lkZXMgd2lsbCBiZSBvdXQgb2Ygc3luYy4NCj4NCj5JIHRo aW5rIGl0IG1pZ2h0IGJlIGJldHRlciB0byBqdXN0IHNheSB0aGUgY29udHJvbGxpbmcgc2lkZSBt dXN0IHNldCB0aGUgY2hlY2sgbGlzdCB0byB0aGUgZmFpbGVkIHN0YXRlLiAgSXQncyBwcm9iYWJs eSBhIHZlcnkgcmFyZSBzaXR1YXRpb24gYW55d2F5LCBhbmQgaWYgd2UgdGhpbmsgPndlIG5lZWQg YmV0dGVyLCB0aGVyZSdzIGFsd2F5cyBhbiBJQ0UgZXh0ZW5zaW9uIGxpa2UgcmVub21pbmF0aW9u IDopLg0KDQpXZSBjYW4gZG8gdGhhdC4NCg0KPkFzIGZvciB0aGUgImNvbnRyb2xsZWQgc2lkZSBj YW4gcmVqZWN0IHRoZSBub21pbmF0aW9uIiBwYXJ0IG9mIHRoZSBQUjogaWYgd2Uga2VlcCB0aGUg ImNvbnRyb2xsaW5nIHNpZGUgbWF5IG5vbWluYXRlIGFub3RoZXIgcGFpciIgcnVsZSwgYnV0IG9u bHkgaWYgdGhlID5jb250cm9sbGVkIHNpZGUgcmVqZWN0ZWQgaXQgKG5vdCBiZWNhdXNlIG9mIFNU VU4gdHJhbnNhY3Rpb24gdGltZW91dCksIHRoZW4gSSBjb3VsZCBzZWUgdGhlIHByb2JsZW0gSSBw b2ludGVkIG91dCBhYm92ZSBub3QgYmVpbmcgYSBwcm9ibGVtIGFueSBtb3JlLiAgQnV0ID5JJ20g bm90IHN1cmUgd2Ugd2FudCB0byBnbyBkb3duIHRoaXMgcGF0aCAiY29udHJvbGxpbmcgc2lkZSBr ZWVwcyBub21pbmF0aW5nIHVudGlsIHRoZSBjb250cm9sbGVkIHNpZGUgYWNjZXB0cyIgdGhpbmcu ICBJIHRoaW5rIGl0IHdvdWxkIGJlIG1vcmUgc2ltcGxlIHRvID5qdXN0IHNheSB0aGUgY29udHJv bGxlZCBzaWRlIE1VU1QgYWNjZXB0IHRoZSB0cmFuc2FjdGlvbiBvciB0aGUgY2hlY2sgbGlzdCBn b2VzIHRvIHRoZSBmYWlsZWQgc3RhdGUuDQoNCkkgYXNzdW1lIOKAnGdvZXMgdG8gdGhlIGZhaWxl ZCBzdGF0ZeKAnSBpbmNsdWRlcyByZWplY3RpbmcgdGhlIHRyYW5zYWN0aW9uPw0KDQpOb3csIHRo ZSB0ZXh0IGRvZXMgc2F5IHRoYXQgdGhlIGNvbnRyb2xsZWQgc2lkZSBoYXMgdG8gYmUgcHJlcGFy ZWQgZm9yIG11bHRpcGxlIG5vbWluYXRpb25zLCBpbiBjYXNlIHRoZSBjb250cm9sbGluZyBlbmRw b2ludCBpcyBsZWdhY3kgZG9lcyBhZ2dyZXNzaXZlIG5vbWluYXRpb24uIFRoZSBzcGVjIHNheXMg dGhhdCB0aGUgY29udHJvbGxlZCBTSE9VTEQgc2VsZWN0IHRoZSBub21pbmF0ZWQgcGFpciB3aXRo IHRoZSBoaWdoZXN0IHByaW9yaXR5LCBidXQgYXNzdW1pbmcgdGhlIGNvbnRyb2xsZWQgZW5kcG9p bnRzIGFjY2VwdHMgYWxsIG5vbWluYXRpb24gdHJhbnNhY3Rpb25zIHRoZXJlIGlzIG5vIHdheSBm b3IgdGhlIGNvbnRyb2xsZWQgZW5kcG9pbnQgdG8gaW5kaWNhdGUgdG8gdGhlIGNvbnRyb2xsaW5n IGVuZHBvaW50IHdoaWNoIHBhaXIgd2FzIGZpbmFsbHkgc2VsZWN0ZWQuLi4gV2UgQ09VTEQgb2Yg Y291cnNlIHNheSB0aGF0IHRoZSBjb250cm9sbGVkIGVuZHBvaW50IHNob3VsZCByZWplY3QgYW55 IGFkZGl0aW9uYWwgbm9taW5hdGlvbiB0cmFuc2FjdGlvbnMsIGJ1dCBtYXliZSB0aGF0IGNvdWxk IGNhdXNlIHRyb3VibGUgd2l0aCBsZWdhY3kgZW5kcG9pbnRz4oCmPw0KDQpSZWdhcmRzLA0KDQpD aHJpc3Rlcg0KDQoNCg0KT24gTW9uLCBTZXAgMTEsIDIwMTcgYXQgNjowOSBBTSBDaHJpc3RlciBI b2xtYmVyZyA8Y2hyaXN0ZXIuaG9sbWJlcmdAZXJpY3Nzb24uY29tPG1haWx0bzpjaHJpc3Rlci5o b2xtYmVyZ0Blcmljc3Nvbi5jb20+PiB3cm90ZToNCkhpLA0KDQpJIGhhdmUgY3JlYXRlZCBhIFBS LCB3aGljaCBhZGRzIHByb2NlZHVyZSB0ZXh0IChjb250cm9sbGluZyBhZ2VudCkgZm9yIHdoZW4g YSBub21pbmF0aW9uIHJlcXVlc3QgaXMgcmVqZWN0ZWQsIGFuZCBwcm9jZWR1cmUgdGV4dCAoY29u dHJvbGxlZCBhZ2VudCkgZm9yIHJlamVjdGluZyBhIG5vbWluYXRpb24uDQoNCmh0dHBzOi8vZ2l0 aHViLmNvbS9pY2Utd2cvcmZjNTI0NWJpcy9wdWxsLzQ0DQoNClJlZ2FyZHMsDQoNCkNocmlzdGVy DQpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KSWNlIG1h aWxpbmcgbGlzdA0KSWNlQGlldGYub3JnPG1haWx0bzpJY2VAaWV0Zi5vcmc+DQpodHRwczovL3d3 dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL2ljZQ0K --_000_7594FB04B1934943A5C02806D1A2204B562AAAD5ESESSMB109erics_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 IkNhbWJyaWEgTWF0aCI7DQoJcGFub3NlLTE6MiA0IDUgMyA1IDQgNiAzIDIgNDt9DQpAZm9udC1m YWNlDQoJe2ZvbnQtZmFtaWx5OkNhbGlicmk7DQoJcGFub3NlLTE6MiAxNSA1IDIgMiAyIDQgMyAy IDQ7fQ0KLyogU3R5bGUgRGVmaW5pdGlvbnMgKi8NCnAuTXNvTm9ybWFsLCBsaS5Nc29Ob3JtYWws IGRpdi5Nc29Ob3JtYWwNCgl7bWFyZ2luOjBjbTsNCgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJ Zm9udC1zaXplOjEyLjBwdDsNCglmb250LWZhbWlseToiVGltZXMgTmV3IFJvbWFuIixzZXJpZjt9 DQphOmxpbmssIHNwYW4uTXNvSHlwZXJsaW5rDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCglj b2xvcjpibHVlOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0KYTp2aXNpdGVkLCBzcGFu Lk1zb0h5cGVybGlua0ZvbGxvd2VkDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgljb2xvcjpw dXJwbGU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQpzcGFuLkVtYWlsU3R5bGUxNw0K CXttc28tc3R5bGUtdHlwZTpwZXJzb25hbDsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsc2Fucy1z ZXJpZjsNCgljb2xvcjojMUY0OTdEO30NCnNwYW4uRW1haWxTdHlsZTE4DQoJe21zby1zdHlsZS10 eXBlOnBlcnNvbmFsLWNvbXBvc2U7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLHNhbnMtc2VyaWY7 DQoJY29sb3I6d2luZG93dGV4dDt9DQouTXNvQ2hwRGVmYXVsdA0KCXttc28tc3R5bGUtdHlwZTpl eHBvcnQtb25seTsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsc2Fucy1zZXJpZjsNCgltc28tZmFy ZWFzdC1sYW5ndWFnZTpFTi1VUzt9DQpAcGFnZSBXb3JkU2VjdGlvbjENCgl7c2l6ZTo2MTIuMHB0 IDc5Mi4wcHQ7DQoJbWFyZ2luOjcyLjBwdCA3Mi4wcHQgNzIuMHB0IDcyLjBwdDt9DQpkaXYuV29y ZFNlY3Rpb24xDQoJe3BhZ2U6V29yZFNlY3Rpb24xO30NCi0tPjwvc3R5bGU+PCEtLVtpZiBndGUg bXNvIDldPjx4bWw+DQo8bzpzaGFwZWRlZmF1bHRzIHY6ZXh0PSJlZGl0IiBzcGlkbWF4PSIxMDI2 IiAvPg0KPC94bWw+PCFbZW5kaWZdLS0+PCEtLVtpZiBndGUgbXNvIDldPjx4bWw+DQo8bzpzaGFw ZWxheW91dCB2OmV4dD0iZWRpdCI+DQo8bzppZG1hcCB2OmV4dD0iZWRpdCIgZGF0YT0iMSIgLz4N CjwvbzpzaGFwZWxheW91dD48L3htbD48IVtlbmRpZl0tLT4NCjwvaGVhZD4NCjxib2R5IGxhbmc9 IkVOLUdCIiBsaW5rPSJibHVlIiB2bGluaz0icHVycGxlIj4NCjxkaXYgY2xhc3M9IldvcmRTZWN0 aW9uMSI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBw dDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3 RDttc28tZmFyZWFzdC1sYW5ndWFnZTpFTi1VUyI+SGksPG86cD48L286cD48L3NwYW4+PC9wPg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8ZGl2Pg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+Jmd0O0kgdGhpbmsgdGhlIGdvYWwgb2YgZmlyc3QgcGFydCBvZiB0aGUg UFIgaXMgZ29vZCwgd2hlcmUgd2Ugc3BlY2lmeS9jbGFyaWZ5IHdoYXQgdG8gZG8gd2hlbiB0aGUg bm9taW5hdGlvbiBTVFVOIHRyYW5zYWN0aW9uIGZhaWxzLiAmbmJzcDs8bzpwPjwvbzpwPjwvcD4N CjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4mZ3Q7PG86cD4mbmJzcDs8L286cD48L3A+DQo8 L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4mZ3Q7QnV0IEkgdGhpbmsgdGhlcmUg aXMgYSBwcm9ibGVtIHdpdGggdGhlIG9wdGlvbiBvZiAmcXVvdDtub21pbmF0ZSBhbm90aGVyIHBh aXImcXVvdDs6ICZuYnNwO2lmIHRoZSB0cmFuc2FjdGlvbiBmYWlscyBiZWNhdXNlIHRoZSByZXF1 ZXN0IGlzIGRlbGF5ZWQgb24gdGhlIG5ldHdvcmsgKHN1Y2ggdGhhdCAmZ3Q7dGhlIHRyYW5zYWN0 aW9uIHRpbWVzIG91dCkgdGhlbiB0aGUgY29udHJvbGxlZCBzaWRlIHdpbGwgc2VlIGEgbm9taW5h dGlvbiwgYnV0DQogdGhlIGNvbnRyb2xsaW5nIHNpZGUgd29uJ3Qga25vdyB0aGF0IGl0IGRpZC4m bmJzcDsgU28gdGhlIGNvbnRyb2xsaW5nIHNpZGUgd2lsbCB0aGVuICZndDtub21pbmF0ZSBhIGRp ZmZlcmVudCBwYWlyLCBhbmQgdGhlIGNvbnRyb2xsaW5nIHNpZGUgd2lsbCBzZWUgdHdvIG5vbWlu YXRpb25zLCBwb3NzaWJseSB3aXRoIHRoZSBmaXJzdCBhcnJpdmluZyBsYXN0LCBhbmQgdGhlIHR3 byBzaWRlcyB3aWxsIGJlIG91dCBvZiBzeW5jLiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+ DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Jmd0OzxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0K PC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Jmd0O0kgdGhpbmsgaXQgbWlnaHQg YmUgYmV0dGVyIHRvIGp1c3Qgc2F5IHRoZSBjb250cm9sbGluZyBzaWRlIG11c3Qgc2V0IHRoZSBj aGVjayBsaXN0IHRvIHRoZSBmYWlsZWQgc3RhdGUuJm5ic3A7IEl0J3MgcHJvYmFibHkgYSB2ZXJ5 IHJhcmUgc2l0dWF0aW9uIGFueXdheSwgYW5kIGlmIHdlIHRoaW5rICZndDt3ZSBuZWVkIGJldHRl ciwgdGhlcmUncyBhbHdheXMgYW4gSUNFIGV4dGVuc2lvbiBsaWtlIHJlbm9taW5hdGlvbiA6KS48 bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+ Jm5ic3A7PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQt c2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmIj5X ZSBjYW4gZG8gdGhhdC48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPiZndDtBcyBmb3IgdGhlICZxdW90O2NvbnRyb2xsZWQgc2lkZSBj YW4gcmVqZWN0IHRoZSBub21pbmF0aW9uJnF1b3Q7IHBhcnQgb2YgdGhlIFBSOiBpZiB3ZSBrZWVw IHRoZSAmcXVvdDtjb250cm9sbGluZyBzaWRlIG1heSBub21pbmF0ZSBhbm90aGVyIHBhaXImcXVv dDsgcnVsZSwgYnV0IG9ubHkgaWYgdGhlICZndDtjb250cm9sbGVkIHNpZGUgcmVqZWN0ZWQgaXQg KG5vdCBiZWNhdXNlIG9mIFNUVU4gdHJhbnNhY3Rpb24gdGltZW91dCksIHRoZW4gSSBjb3VsZA0K IHNlZSB0aGUgcHJvYmxlbSBJIHBvaW50ZWQgb3V0IGFib3ZlIG5vdCBiZWluZyBhIHByb2JsZW0g YW55IG1vcmUuJm5ic3A7IEJ1dCAmZ3Q7SSdtIG5vdCBzdXJlIHdlIHdhbnQgdG8gZ28gZG93biB0 aGlzIHBhdGggJnF1b3Q7Y29udHJvbGxpbmcgc2lkZSBrZWVwcyBub21pbmF0aW5nIHVudGlsIHRo ZSBjb250cm9sbGVkIHNpZGUgYWNjZXB0cyZxdW90OyB0aGluZy4mbmJzcDsgSSB0aGluayBpdCB3 b3VsZCBiZSBtb3JlIHNpbXBsZSB0byAmZ3Q7anVzdCBzYXkgdGhlIGNvbnRyb2xsZWQgc2lkZQ0K IE1VU1QgYWNjZXB0IHRoZSB0cmFuc2FjdGlvbiBvciB0aGUgY2hlY2sgbGlzdCBnb2VzIHRvIHRo ZSBmYWlsZWQgc3RhdGUuPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPkkgYXNzdW1lIOKAnGdvZXMgdG8gdGhlIGZhaWxlZCBzdGF0ZeKAnSBpbmNs dWRlcyByZWplY3RpbmcgdGhlIHRyYW5zYWN0aW9uPzxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1 b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+ DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEu MHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZiI+Tm93LCB0aGUg dGV4dCBkb2VzIHNheSB0aGF0IHRoZSBjb250cm9sbGVkIHNpZGUgaGFzIHRvIGJlIHByZXBhcmVk IGZvciBtdWx0aXBsZSBub21pbmF0aW9ucywgaW4gY2FzZSB0aGUgY29udHJvbGxpbmcgZW5kcG9p bnQgaXMgbGVnYWN5IGRvZXMgYWdncmVzc2l2ZSBub21pbmF0aW9uLiBUaGUgc3BlYw0KIHNheXMg dGhhdCB0aGUgY29udHJvbGxlZCBTSE9VTEQgc2VsZWN0IHRoZSBub21pbmF0ZWQgcGFpciB3aXRo IHRoZSBoaWdoZXN0IHByaW9yaXR5LCBidXQgYXNzdW1pbmcgdGhlIGNvbnRyb2xsZWQgZW5kcG9p bnRzIGFjY2VwdHMgYWxsIG5vbWluYXRpb24gdHJhbnNhY3Rpb25zIHRoZXJlIGlzIG5vIHdheSBm b3IgdGhlIGNvbnRyb2xsZWQgZW5kcG9pbnQgdG8gaW5kaWNhdGUgdG8gdGhlIGNvbnRyb2xsaW5n IGVuZHBvaW50IHdoaWNoIHBhaXIgd2FzDQogZmluYWxseSBzZWxlY3RlZC4uLiBXZSBDT1VMRCBv ZiBjb3Vyc2Ugc2F5IHRoYXQgdGhlIGNvbnRyb2xsZWQgZW5kcG9pbnQgc2hvdWxkIHJlamVjdCBh bnkgYWRkaXRpb25hbCBub21pbmF0aW9uIHRyYW5zYWN0aW9ucywgYnV0IG1heWJlIHRoYXQgY291 bGQgY2F1c2UgdHJvdWJsZSB3aXRoIGxlZ2FjeSBlbmRwb2ludHPigKY/PG86cD48L286cD48L3Nw YW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4w cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmIj48bzpwPiZuYnNw OzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9u dC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWYi PlJlZ2FyZHMsPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNw YW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90 OyxzYW5zLXNlcmlmIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtD YWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWYiPkNocmlzdGVyPG86cD48L286cD48L3NwYW4+PC9wPg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1m YW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmIj48bzpwPiZuYnNwOzwvbzpwPjwv c3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEx LjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWYiPjxvOnA+Jm5i c3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ PG86cD4mbmJzcDs8L286cD48L3A+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi Pk9uIE1vbiwgU2VwIDExLCAyMDE3IGF0IDY6MDkgQU0gQ2hyaXN0ZXIgSG9sbWJlcmcgJmx0Ozxh IGhyZWY9Im1haWx0bzpjaHJpc3Rlci5ob2xtYmVyZ0Blcmljc3Nvbi5jb20iPmNocmlzdGVyLmhv bG1iZXJnQGVyaWNzc29uLmNvbTwvYT4mZ3Q7IHdyb3RlOjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+ DQo8YmxvY2txdW90ZSBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLWxlZnQ6c29saWQgI0NDQ0ND QyAxLjBwdDtwYWRkaW5nOjBjbSAwY20gMGNtIDYuMHB0O21hcmdpbi1sZWZ0OjQuOHB0O21hcmdp bi1yaWdodDowY20iPg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBz dHlsZT0iZm9udC1zaXplOjEwLjVwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNh bnMtc2VyaWY7Y29sb3I6YmxhY2siPkhpLDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0K PGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuNXB0 O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjpibGFjayI+ PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7 Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOmJsYWNrIj5JIGhhdmUgY3JlYXRlZCBhIFBS LCB3aGljaCBhZGRzIHByb2NlZHVyZSB0ZXh0IChjb250cm9sbGluZyBhZ2VudCkgZm9yIHdoZW4g YSBub21pbmF0aW9uIHJlcXVlc3QgaXMgcmVqZWN0ZWQsIGFuZCBwcm9jZWR1cmUgdGV4dCAoY29u dHJvbGxlZCBhZ2VudCkgZm9yIHJlamVjdGluZw0KIGEgbm9taW5hdGlvbi48bzpwPjwvbzpwPjwv c3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHls ZT0iZm9udC1zaXplOjEwLjVwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMt c2VyaWY7Y29sb3I6YmxhY2siPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0K PGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuNXB0 O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjpibGFjayI+ PGEgaHJlZj0iaHR0cHM6Ly9naXRodWIuY29tL2ljZS13Zy9yZmM1MjQ1YmlzL3B1bGwvNDQiIHRh cmdldD0iX2JsYW5rIj5odHRwczovL2dpdGh1Yi5jb20vaWNlLXdnL3JmYzUyNDViaXMvcHVsbC80 NDwvYT48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjVwdDtmb250LWZhbWlseTomcXVvdDtD YWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6YmxhY2siPjxvOnA+Jm5ic3A7PC9vOnA+PC9z cGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxl PSJmb250LXNpemU6MTAuNXB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1z ZXJpZjtjb2xvcjpibGFjayI+UmVnYXJkcyw8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4N CjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjVw dDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6YmxhY2si PjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuNXB0O2ZvbnQtZmFtaWx5OiZxdW90 O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjpibGFjayI+Q2hyaXN0ZXI8bzpwPjwvbzpw Pjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+X19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX188YnI+DQpJY2UgbWFpbGlu ZyBsaXN0PGJyPg0KPGEgaHJlZj0ibWFpbHRvOkljZUBpZXRmLm9yZyIgdGFyZ2V0PSJfYmxhbmsi PkljZUBpZXRmLm9yZzwvYT48YnI+DQo8YSBocmVmPSJodHRwczovL3d3dy5pZXRmLm9yZy9tYWls bWFuL2xpc3RpbmZvL2ljZSIgdGFyZ2V0PSJfYmxhbmsiPmh0dHBzOi8vd3d3LmlldGYub3JnL21h aWxtYW4vbGlzdGluZm8vaWNlPC9hPjxvOnA+PC9vOnA+PC9wPg0KPC9ibG9ja3F1b3RlPg0KPC9k aXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvYm9keT4NCjwvaHRtbD4NCg== --_000_7594FB04B1934943A5C02806D1A2204B562AAAD5ESESSMB109erics_-- From nobody Mon Sep 11 12:55: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 4303B13239C for ; Mon, 11 Sep 2017 12:55:14 -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, HTML_MESSAGE=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 WjNqlydxBWmG for ; Mon, 11 Sep 2017 12:55:12 -0700 (PDT) Received: from mail-qt0-x22c.google.com (mail-qt0-x22c.google.com [IPv6:2607:f8b0:400d:c0d::22c]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 32D9C132339 for ; Mon, 11 Sep 2017 12:55:12 -0700 (PDT) Received: by mail-qt0-x22c.google.com with SMTP id m35so21474881qte.1 for ; Mon, 11 Sep 2017 12:55:12 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=jitsi-org.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to; bh=eVY46zJznaa69jtuIRW0FozSXfOX+GNuFPvpi3aJNuE=; b=TlZlCeRX3jr/PFlATLqn0dkJvuLGDpyAnUKEbfbXsu5en+rQpS9LSOhSWj7HuCE01F SEzUlIVLCma13csxLGcRUWG8SMFqLxi1ayvkTg89IolOC8VBQRTzZhx9UxXy0KC5NNdm nYMrfCElZK0zY4xwfaWV8whsHWEZgBXs0DUlEUHwGqaGAxvy6JcG90o2FJogzSm7KOI6 bvNCZ8Ue6k1HQG68lH1N+qyz5ISvCuX2yr7ek8KONO3QhBoR/kdoLgjAu8Lo37ZGhsTJ Mm6ALzyMVJpktLYp9g0jaQp5P9IYYz6NgDKvBUIrpPACBx/AprasoOL19RZwQ2pHEWGb 19BQ== 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=eVY46zJznaa69jtuIRW0FozSXfOX+GNuFPvpi3aJNuE=; b=cJCNIxO2srgmAIKazQCZcBPxw4c5JTN1QiHw8OusH+AEYe/7O3AHEZFAb3ZXmdjDNA S+zkBprr5+FHktRvDehQzs5iqs9O4IjAP4wvR07lWnZNU02dru+GC/yHpEOx+gzmp5vD 658Xnd/Zqok4gLs4vVoWxx9BnYf70XxXDG0zeM67mA1BtOBQxy2JAIr9OuVgxM+L0+Gy Fttq3cn3c9pSyI5wm9NeKGJz6D3ExeaL65EStxM948DyyQuvFxm1v5LfRStg7SSxgMO3 fdR45uRs5syFCGmkDTqChyoPwoCH+o57Dw5VYMwQ7xFF9o+Zc4KCME+3ReuhcZCjmXse 44Vw== X-Gm-Message-State: AHPjjUgnPd1NqNVNujsPqzJQasgccDwy6JeMVWyy2GJ+mA4RHvLqXUqF cRovFyl6FdSqoWkhszkUhdifY4sMunkE X-Google-Smtp-Source: AOwi7QC63eXEeJdkmMBS4v9yNxSLQZMup51xXsIfPP9RhfW+pqVg2PHyKic6LgpJJBl9wVzXOVxA0M3ReFAfGee20KU= X-Received: by 10.200.53.67 with SMTP id z3mr18890532qtb.145.1505159711222; Mon, 11 Sep 2017 12:55:11 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Emil Ivov Date: Mon, 11 Sep 2017 19:55:00 +0000 Message-ID: To: Christer Holmberg , Peter Thatcher , "ice@ietf.org" Content-Type: multipart/alternative; boundary="001a114375e6eb001c0558ef4d80" Archived-At: Subject: Re: [Ice] Pull request: Candidate nomination rejection 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, 11 Sep 2017 19:55:14 -0000 --001a114375e6eb001c0558ef4d80 Content-Type: text/plain; charset="UTF-8" On Mon, 11 Sep 2017 at 12:07, Peter Thatcher wrote: > > I think it would be more simple to just say the controlled side MUST > accept the transaction or the check list goes to the failed state. > Yes, I am much more in favor of that! Emil > > > > > On Mon, Sep 11, 2017 at 6:09 AM Christer Holmberg < > christer.holmberg@ericsson.com> wrote: > >> Hi, >> >> I have created a PR, which adds procedure text (controlling agent) for >> when a nomination request is rejected, and procedure text (controlled >> agent) for rejecting a nomination. >> >> https://github.com/ice-wg/rfc5245bis/pull/44 >> >> Regards, >> >> Christer >> _______________________________________________ >> 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 > -- sent from my mobile --001a114375e6eb001c0558ef4d80 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable

On Mon, 11 Sep 2017 a= t 12:07, Peter Thatcher <pthatch= er@google.com> wrote:
<= br>
I think it would be more simple to just say the controll= ed side MUST accept the transaction or the check list goes to the failed st= ate.

= Yes, I am much more in favor of that!

Emil






On Mon, Sep 11, 2017 at 6:09 AM= Christer Holmberg <christer.holmberg@ericsson.com> wrote:
Hi,

I have created a PR, which adds procedure text (controlling agent) for= when a nomination request is rejected, and procedure text (controlled agen= t) for rejecting a nomination.


Regards,

Christer
_______________________________________________
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
--
sent from my mobile
--001a114375e6eb001c0558ef4d80-- From nobody Mon Sep 11 18:03:29 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 9684A124B18; Mon, 11 Sep 2017 18:03:22 -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.61.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <150517820257.4656.2937028713812576260@ietfa.amsl.com> Date: Mon, 11 Sep 2017 18:03:22 -0700 Archived-At: Subject: [Ice] I-D Action: draft-ietf-ice-trickle-14.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: Tue, 12 Sep 2017 01:03:22 -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 WG 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-14.txt Pages : 31 Date : 2017-09-11 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-14 https://datatracker.ietf.org/doc/html/draft-ietf-ice-trickle-14 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-ice-trickle-14 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Tue Sep 12 00:07: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 C2787132D40 for ; Tue, 12 Sep 2017 00:07:42 -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 SspLsc--wHRD for ; Tue, 12 Sep 2017 00:07:41 -0700 (PDT) Received: from sesbmg22.ericsson.net (sesbmg22.ericsson.net [193.180.251.48]) (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 003DE1321E6 for ; Tue, 12 Sep 2017 00:07:40 -0700 (PDT) X-AuditID: c1b4fb30-597ff70000005897-da-59b787b91934 Received: from ESESSHC017.ericsson.se (Unknown_Domain [153.88.183.69]) by sesbmg22.ericsson.net (Symantec Mail Security) with SMTP id AF.77.22679.9B787B95; Tue, 12 Sep 2017 09:07:37 +0200 (CEST) Received: from ESESSMB109.ericsson.se ([169.254.9.194]) by ESESSHC017.ericsson.se ([153.88.183.69]) with mapi id 14.03.0352.000; Tue, 12 Sep 2017 09:07:37 +0200 From: Christer Holmberg To: Emil Ivov , Peter Thatcher , "ice@ietf.org" Thread-Topic: [Ice] Pull request: Candidate nomination rejection Thread-Index: AQHTKv8dds/hj0UYMk+bvgU9RIJWOKKvyT+AgAAu7wCAAO+igA== Date: Tue, 12 Sep 2017 07:07:36 +0000 Message-ID: References: In-Reply-To: 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.146] Content-Type: multipart/alternative; boundary="_000_D5DD638A2148Bchristerholmbergericssoncom_" MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFlrGIsWRmVeSWpSXmKPExsUyM2K7q+7O9u2RBl2tNhZrdk5gsfh2odbi 2vLXrA7MHgs2lXosWfKTyeP/m8AA5igum5TUnMyy1CJ9uwSujDnd79gKbhhUzFi7lrWB8Y9W FyMnh4SAicTnE1PZuhi5OIQEjjBKnLyzgB3CWcIocWDKKcYuRg4ONgELie5/2iANIgLpEpNa lrKB2MIC9hLdk9vYIeIOEvOnT2GFsJ0k7u6cxgJiswioSixY0whWwytgLfHi2SxWiPknGSXO nbsGluAUCJSYcLQLrIFRQEzi+6k1TCA2s4C4xK0n85kgLhWQWLLnPDOELSrx8vE/VpDbRAX0 JN7t94QIK0n82HCJBaI1QeJP31RmiL2CEidnPmGZwCgyC8nUWUjKZiEpg4gbSLw/N58ZwtaW WLbwNZStL7Hxy1nGWUCbmYHe+Xw3DFnJAkaOVYyixanFSbnpRkZ6qUWZycXF+Xl6eaklmxiB sXdwy2+DHYwvnzseYhTgYFTi4XUv2R4pxJpYVlyZe4hRgoNZSYR3VwFQiDclsbIqtSg/vqg0 J7X4EKM0B4uSOK/jvgsRQgLpiSWp2ampBalFMFkmDk6pBkZvq2r2I188gh7MMWNj+3amyz/v jcZBbxMZVz61DdHVm00/f105486bzv9R//TLRIx33zsm3nmh0cdXeMOK8w9+KN1Q66z14gye fSrDfF/v4id9ap/U13DX5WS33qzO/TJPLzR11XnFe9ufbZy+SKNLNSBK5KbBqu0xF65dWclz eYtPe1k213IlluKMREMt5qLiRABMmvtXuQIAAA== Archived-At: Subject: Re: [Ice] Pull request: Candidate nomination rejection 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, 12 Sep 2017 07:07:42 -0000 --_000_D5DD638A2148Bchristerholmbergericssoncom_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable Pull request updated, based on Peter=92s and Emil=92s comments. Regards, Christer From: Emil Ivov > Date: Monday 11 September 2017 at 22:55 To: Christer Holmberg >, "pthatcher@google.com" >, "ice@ietf.org" > Subject: Re: [Ice] Pull request: Candidate nomination rejection On Mon, 11 Sep 2017 at 12:07, Peter Thatcher > wrote: I think it would be more simple to just say the controlled side MUST accept= the transaction or the check list goes to the failed state. Yes, I am much more in favor of that! Emil On Mon, Sep 11, 2017 at 6:09 AM Christer Holmberg > wrote: Hi, I have created a PR, which adds procedure text (controlling agent) for when= a nomination request is rejected, and procedure text (controlled agent) fo= r rejecting a nomination. https://github.com/ice-wg/rfc5245bis/pull/44 Regards, Christer _______________________________________________ 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 -- sent from my mobile --_000_D5DD638A2148Bchristerholmbergericssoncom_ Content-Type: text/html; charset="Windows-1252" Content-ID: Content-Transfer-Encoding: quoted-printable
Pull request updated, based on Peter=92s and Emil=92s comments.

Regards,

Christer

From: Emil Ivov <emcho@jitsi.org>
Date: Monday 11 September 2017 at 2= 2:55
To: Christer Holmberg <christer.holmberg@ericsson.com>, "pthatcher@google.com<= /a>" <pthatcher@google.com<= /a>>, "ice@ietf.org" <ice@ietf.org>
Subject: Re: [Ice] Pull request: Ca= ndidate nomination rejection


On Mon, 11 Sep 2017 at 12:07, Peter Thatcher <pthatcher@google.com> wrote:

I think it would be more simple to just say the controlled side MUST a= ccept the transaction or the check list goes to the failed state.

Yes, I am much more in favor of that!

Emil






On Mon, Sep 11, 2017 at 6:09 AM Christer Holmberg <christer.holmberg@erics= son.com> wrote:
Hi,

I have created a PR, which adds procedure text (controlling agent) for= when a nomination request is rejected, and procedure text (controlled agen= t) for rejecting a nomination.


Regards,

Christer
_______________________________________________
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
--
sent from= my mobile
 --_000_D5DD638A2148Bchristerholmbergericssoncom_-- From nobody Tue Sep 12 07:45: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 0CFBB132332 for ; Tue, 12 Sep 2017 07:45:15 -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 aJQIyAHBoBD1 for ; Tue, 12 Sep 2017 07:45:13 -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 08BDC127517 for ; Tue, 12 Sep 2017 07:45:12 -0700 (PDT) X-AuditID: c1b4fb3a-5ffff700000051a3-44-59b7f2f6b825 Received: from ESESSHC020.ericsson.se (Unknown_Domain [153.88.183.78]) by sessmg22.ericsson.net (Symantec Mail Security) with SMTP id C3.EE.20899.6F2F7B95; Tue, 12 Sep 2017 16:45:11 +0200 (CEST) Received: from ESESSMB109.ericsson.se ([169.254.9.194]) by ESESSHC020.ericsson.se ([153.88.183.78]) with mapi id 14.03.0352.000; Tue, 12 Sep 2017 16:45:10 +0200 From: =?utf-8?B?QXJpIEtlcsOkbmVu?= To: Christer Holmberg CC: Emil Ivov , Peter Thatcher , ICE WG Thread-Topic: [Ice] Pull request: Candidate nomination rejection Thread-Index: AQHTKv8dds/hj0UYMk+bvgU9RIJWOKKvyT+AgAAu7wCAAO+igIAATCEA Date: Tue, 12 Sep 2017 14:45:10 +0000 Message-ID: References: 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="utf-8" Content-ID: <0953662AACA8FE4182317E62BFB646E4@ericsson.com> Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFprFIsWRmVeSWpSXmKPExsUyM2K7n+73T9sjDeZc4rVYs3MCi8W3C7UW 15a/ZnVg9liwqdRjyZKfTB7/3wQGMEdx2aSk5mSWpRbp2yVwZTw4/IGloE+k4s+2TYwNjGeE uxg5OSQETCQuNr5mBrGFBI4wSuw6zNjFyAVkL2GUWLPtLytIgk3AVuJJ6z4wW0TATOL6514m EJtZIF7iV99KMFtYwF6ie3IbO0SNg8T86VOg6t0kHny6A1bDIqAqcXzlMbAaXqD65R+OMkMs +80osfv4dRaQBKeAjUTrlCdgRYwCYhLfT62BWiYucevJfCaIqwUkluw5zwxhi0q8fPyPFcJW kmhc8gTI5gCq15RYv0sfotVaYt+WI+wQtqLElO6HUDcISpyc+YRlAqPYLCQbZiF0z0LSPQtJ 9ywk3QsYWVcxihanFhfnphsZ6aUWZSYXF+fn6eWllmxiBMbYwS2/rXYwHnzueIhRgINRiYe3 4P32SCHWxLLiytxDjBIczEoivCceAYV4UxIrq1KL8uOLSnNSiw8xSnOwKInzOuy7ECEkkJ5Y kpqdmlqQWgSTZeLglGpgdLrXdfyovE9iyaWV797tWf4tt0Nks8OEz5/3fDrFqXGgmSUxTbno i+fR225L/05VUClcrBvjtvEX5781HTt6pp05mKDz70KjzLmJ4Qq9B5mYjU8seNXz+HKKo6wG r/XO9+G6amfmx3qoHfje8V7TTyq0T9LOQyuyT0NuxjK2t1pZSyP3Ki+wV2Ipzkg01GIuKk4E ABFPmV6tAgAA Archived-At: Subject: Re: [Ice] Pull request: Candidate nomination rejection 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, 12 Sep 2017 14:45:15 -0000 TG9va3MgZ29vZCB0byBtZS4gQWx0aG91Z2ggaW5zdGVhZCBvZiBzYXlpbmcgIk1VU1QgcmVwbHkg d2l0aCA0MDAiLCBJJ2Qgc3VnZ2VzdCBzZWxlY3RpbmcgbW9yZSBhcHByb3ByaWF0ZSBlcnJvciBj b2RlIGlmIG9uZSBpcyBhdmFpbGFibGUuIEZvciBleGFtcGxlOiAiTVVTVCByZWplY3QgdGhlIG5v bWluYXRpb24gcmVxdWVzdCB3aXRoIGFwcHJvcHJpYXRlIGVycm9yIGNvZGUgcmVzcG9uc2UgKGUu Zy4sIDQwMCkiLg0KDQoNCkNoZWVycywNCkFyaQ0KDQo+IE9uIDEyIFNlcCAyMDE3LCBhdCAxMC4w NywgQ2hyaXN0ZXIgSG9sbWJlcmcgPGNocmlzdGVyLmhvbG1iZXJnQGVyaWNzc29uLmNvbT4gd3Jv dGU6DQo+IA0KPiBQdWxsIHJlcXVlc3QgdXBkYXRlZCwgYmFzZWQgb24gUGV0ZXLigJlzIGFuZCBF bWls4oCZcyBjb21tZW50cy4NCj4gDQo+IFJlZ2FyZHMsDQo+IA0KPiBDaHJpc3Rlcg0KPiANCj4g RnJvbTogRW1pbCBJdm92IDxlbWNob0BqaXRzaS5vcmc+DQo+IERhdGU6IE1vbmRheSAxMSBTZXB0 ZW1iZXIgMjAxNyBhdCAyMjo1NQ0KPiBUbzogQ2hyaXN0ZXIgSG9sbWJlcmcgPGNocmlzdGVyLmhv bG1iZXJnQGVyaWNzc29uLmNvbT4sICJwdGhhdGNoZXJAZ29vZ2xlLmNvbSIgPHB0aGF0Y2hlckBn b29nbGUuY29tPiwgImljZUBpZXRmLm9yZyIgPGljZUBpZXRmLm9yZz4NCj4gU3ViamVjdDogUmU6 IFtJY2VdIFB1bGwgcmVxdWVzdDogQ2FuZGlkYXRlIG5vbWluYXRpb24gcmVqZWN0aW9uDQo+IA0K PiANCj4gT24gTW9uLCAxMSBTZXAgMjAxNyBhdCAxMjowNywgUGV0ZXIgVGhhdGNoZXIgPHB0aGF0 Y2hlckBnb29nbGUuY29tPiB3cm90ZToNCj4+IA0KPj4gSSB0aGluayBpdCB3b3VsZCBiZSBtb3Jl IHNpbXBsZSB0byBqdXN0IHNheSB0aGUgY29udHJvbGxlZCBzaWRlIE1VU1QgYWNjZXB0IHRoZSB0 cmFuc2FjdGlvbiBvciB0aGUgY2hlY2sgbGlzdCBnb2VzIHRvIHRoZSBmYWlsZWQgc3RhdGUuDQo+ IA0KPiBZZXMsIEkgYW0gbXVjaCBtb3JlIGluIGZhdm9yIG9mIHRoYXQhDQo+IA0KPiBFbWlsDQo+ IA0KPj4gDQo+PiANCj4+IA0KPj4gDQo+PiANCj4+IE9uIE1vbiwgU2VwIDExLCAyMDE3IGF0IDY6 MDkgQU0gQ2hyaXN0ZXIgSG9sbWJlcmcgPGNocmlzdGVyLmhvbG1iZXJnQGVyaWNzc29uLmNvbT4g d3JvdGU6DQo+Pj4gSGksDQo+Pj4gDQo+Pj4gSSBoYXZlIGNyZWF0ZWQgYSBQUiwgd2hpY2ggYWRk cyBwcm9jZWR1cmUgdGV4dCAoY29udHJvbGxpbmcgYWdlbnQpIGZvciB3aGVuIGEgbm9taW5hdGlv biByZXF1ZXN0IGlzIHJlamVjdGVkLCBhbmQgcHJvY2VkdXJlIHRleHQgKGNvbnRyb2xsZWQgYWdl bnQpIGZvciByZWplY3RpbmcgYSBub21pbmF0aW9uLg0KPj4+IA0KPj4+IGh0dHBzOi8vZ2l0aHVi LmNvbS9pY2Utd2cvcmZjNTI0NWJpcy9wdWxsLzQ0DQo+Pj4gDQo+Pj4gUmVnYXJkcywNCj4+PiAN Cj4+PiBDaHJpc3Rlcg0KPj4+IF9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fDQo+Pj4gSWNlIG1haWxpbmcgbGlzdA0KPj4+IEljZUBpZXRmLm9yZw0KPj4+IGh0 dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vaWNlDQo+PiBfX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KPj4gSWNlIG1haWxpbmcgbGlzdA0K Pj4gSWNlQGlldGYub3JnDQo+PiBodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZv L2ljZQ0KPiAtLSANCj4gc2VudCBmcm9tIG15IG1vYmlsZQ0KPiBfX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KPiBJY2UgbWFpbGluZyBsaXN0DQo+IEljZUBp ZXRmLm9yZw0KPiBodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL2ljZQ0KDQo= From nobody Tue Sep 12 07:59:36 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 B4EF21329AD for ; Tue, 12 Sep 2017 07:59:35 -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, 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 OP5hCrYdZcMG for ; Tue, 12 Sep 2017 07:59:34 -0700 (PDT) Received: from mail-wm0-x229.google.com (mail-wm0-x229.google.com [IPv6:2a00:1450:400c: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 D4DE11326F6 for ; Tue, 12 Sep 2017 07:59:33 -0700 (PDT) Received: by mail-wm0-x229.google.com with SMTP id a137so307295wma.0 for ; Tue, 12 Sep 2017 07:59:33 -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=mqewCH5nDoGCVBLxtVFL0MDlKSvoSV3cZ6RlkVmxk9w=; b=ViGnoVdCy+GLUMxgw20Y0Ww0dMJcttDHC9Ot7wTD/CqnCD9Nv5ta/ySSI8Xr6xpZG9 7IWww9ZRu2yqPRNR6WotS5jcRvXrRjnJhQ5qKzQQDj8sMgfn6uqOS4zijfridNwkFCb9 NaSE4BJolVGw5tOGVlrlxrAUEI7yuLq6DinHPqPzQiaRm9MHcSN8HvPZdb2nbOV5XVom wivqNJuRsZr8dWi6ZrJxkgNwzYOWrPOzoAFG7W1RX+0wnh2+xLNhnkwI6FF5dqKd1piL cqdaxcHfw56AnV6Exi+o7ySr7Dg/PqNDkuMS9PkW0R9tEtTzTeraPMKru7yksLCNXphl iMzg== 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=mqewCH5nDoGCVBLxtVFL0MDlKSvoSV3cZ6RlkVmxk9w=; b=qbs3qv7KW5fyiT/gcqrDztfUK03BPJWHqyhwDVgYU51wAjiymMaGRPQbioo4W12IOf Qx/wBsXPYGQIxa5h9pbOQ2z2i1r8j611r8qzxbGt+b/jdrpKSQCw+B0Jhte7WdQIAaI7 jkejUfa+nL+EV3jHMQoXQ8XKMhB4QVRw3JJtZ6nbYU1Hr82117Sx0oCNZdpBzF4scXLj QD+pmFrNVaqA9hK8C+aYaw8lhhQKLD8pKaksvvDNsE4MUr8uqOnmaF+xKdgI4g3laEk3 lRxfSL8FoZgfJ+TARaqaUF8YTOCsuSNsG00A/+4xNy45upaY5BIpH4hrD2qFTLXZJlDA SEZA== X-Gm-Message-State: AHPjjUhOsBW5dpbpWZBOxMSJukih3rsKnKw/YX2tJU6ZM5qJprzZ5Tkg 3F5Ikfc4LsiPeuf/jVrNUsZAEWRV+UjbF20= X-Google-Smtp-Source: AOwi7QAQe7O+/D9dP6otRb9psI4Efa1Zufg01y0kI30XTzC4m9m9xajT4DPlJNImeLMPu8WOSxJ3G9JBG0JB9PsOeB4= X-Received: by 10.28.54.101 with SMTP id d98mr89916wma.90.1505228371897; Tue, 12 Sep 2017 07:59:31 -0700 (PDT) MIME-Version: 1.0 From: Peter Thatcher Date: Tue, 12 Sep 2017 14:59:19 +0000 Message-ID: To: ICE WG Content-Type: multipart/alternative; boundary="001a11436bb26a1a0f0558ff4ab7" Archived-At: Subject: [Ice] Can we merge PR38? 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, 12 Sep 2017 14:59:35 -0000 --001a11436bb26a1a0f0558ff4ab7 Content-Type: text/plain; charset="UTF-8" We'd like to go to WGLC soon. Before doing so, we need to decide on PR 38 ( https://github.com/ice-wg/rfc5245bis/pull/38/). It was discussed at IETF 99 at length, and all the decisions made there are now reflected in the PR, which I updated recently. I believe we can proceed to merge the and then proceed to WGLC. If you have any remaining issues with the PR, please say so now. If no one objects, we will merge it and go to WGLC soon. Thanks, Peter --001a11436bb26a1a0f0558ff4ab7 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
We'd like to go to WGLC soon.=C2=A0 Before doing so, w= e need to decide on PR 38 (https://github.com/ice-wg/rfc5245bis/pull/38/).=C2=A0 It was discussed at IETF 99 at length, and all the decisions mad= e there are now reflected in the PR, which I updated recently.

I believe we can proceed to merge the and then proceed to WGLC. =C2= =A0 If you have any remaining issues with the PR, please say so now.=C2=A0 = If no one objects, we will merge it and go to WGLC soon.

Thanks,
Peter
--001a11436bb26a1a0f0558ff4ab7-- From nobody Tue Sep 12 08:03:18 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 008171326F6 for ; Tue, 12 Sep 2017 08:03:16 -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=aZY67j8k; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=nXE5jfbe Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LrFOoESZY7-p for ; Tue, 12 Sep 2017 08:03:09 -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 9C31D132335 for ; Tue, 12 Sep 2017 08:03:09 -0700 (PDT) Received: from compute2.internal (compute2.nyi.internal [10.202.2.42]) by mailout.nyi.internal (Postfix) with ESMTP id 0FDAA20BB9; Tue, 12 Sep 2017 11:03:09 -0400 (EDT) Received: from frontend2 ([10.202.2.161]) by compute2.internal (MEProxy); Tue, 12 Sep 2017 11:03:09 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=stpeter.im; h= 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=ShHqNRkrx5XWiOEbJ1NSjeF9LhFPtnY8iWkrzCUty Es=; b=aZY67j8kU7gbX9qdu9Vk8xzZsI/f4ZbgHYa9PoRhstCCIbaKm509+XawY ECcj5D37PtPHCrkhW3ILjOILKGmPicvoyx5YjMhOkE/P7ctINRT9hMjkJz+DxtqW 6bCehx5GPkr6RUnvckjA6qIMALxbat3WGPaVJfOPr0ZLFj4VHChTlBFbADEwNdV5 VNTbpjx9mfpNgcJckeh58g5+6nU4o0B+nVc0Mpg3/mFAJZvavIV4fedQx46wUjuF Qio+w9f/sQWcEazLkFQTUZkXFYvn/bpaSaSPnhC1um4XWAPPV3ztPQiGoeG9KGBp 0dan1BxTeIJFh7X8F4+sZaI273Jqg== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=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=ShHqNRkrx5XWiOEbJ1 NSjeF9LhFPtnY8iWkrzCUtyEs=; b=nXE5jfbe/gA7RGfSkQ/xe9sRvRYbYMIcZc YWmb4zNMpM1iSao1WwvrDwyn/5WoxZLMfiBCboN0+DnuWRF7PAyRkRNELKTsH4mA tPcCwkgRwVNIBeHCjRGxsOxcsOYJwya/cPDcUQxrhEwJ5O6VDrK9mOO9nK1Iq4wE YFb3CMisOMXJmV+iENGU04sJDfvaotvK02H6qMhPA4XHHJWaDhsamM67ydvP/5JZ Dz3SvhtPWakKJsl7VkN4nDBblgrdSFvCPCIci7PgkrWlP8+5rFEOQoSzr0HEG2rB RZMxp99nqiPJ9rIT3id3JXFCof9h50ZgJIWePdWkrkx8QtaWtp1g== X-ME-Sender: X-Sasl-enc: dxL/a/8gHJm0PKKrksy+6Hlh7Fkg6SYKxCNd/Ed1gDYf 1505228588 Received: from aither.local (unknown [76.25.3.152]) by mail.messagingengine.com (Postfix) with ESMTPA id 86C46248EC; Tue, 12 Sep 2017 11:03:08 -0400 (EDT) To: ice@ietf.org References: <150517820257.4656.2937028713812576260@ietfa.amsl.com> From: Peter Saint-Andre Message-ID: <157d7f92-4df8-3323-9abb-35363ba6ae82@stpeter.im> Date: Tue, 12 Sep 2017 09:03:08 -0600 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.12; rv:52.0) Gecko/20100101 Thunderbird/52.3.0 MIME-Version: 1.0 In-Reply-To: <150517820257.4656.2937028713812576260@ietfa.amsl.com> Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="Vb43rWIsrae5OaaSKtbCL5rkTusdUjjHP" Archived-At: Subject: Re: [Ice] I-D Action: draft-ietf-ice-trickle-14.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: Tue, 12 Sep 2017 15:03:16 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --Vb43rWIsrae5OaaSKtbCL5rkTusdUjjHP Content-Type: multipart/mixed; boundary="7581vWJnpTuECBIPKCAlu6R4At3ntHXTQ"; protected-headers="v1" From: Peter Saint-Andre To: ice@ietf.org Message-ID: <157d7f92-4df8-3323-9abb-35363ba6ae82@stpeter.im> Subject: Re: [Ice] I-D Action: draft-ietf-ice-trickle-14.txt References: <150517820257.4656.2937028713812576260@ietfa.amsl.com> In-Reply-To: <150517820257.4656.2937028713812576260@ietfa.amsl.com> --7581vWJnpTuECBIPKCAlu6R4At3ntHXTQ Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: quoted-printable A few small modifications to track changes to the core ICE spec... On 9/11/17 7:03 PM, internet-drafts@ietf.org wrote: >=20 > A New Internet-Draft is available from the on-line Internet-Drafts dire= ctories. > This draft is a work item of the Interactive Connectivity Establishment= WG of the IETF. >=20 > Title : Trickle ICE: Incremental Provisioning of Cand= idates for the Interactive Connectivity Establishment (ICE) Protocol > Authors : Emil Ivov > Eric Rescorla > Justin Uberti > Peter Saint-Andre > Filename : draft-ietf-ice-trickle-14.txt > Pages : 31 > Date : 2017-09-11 >=20 > 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. >=20 >=20 > The IETF datatracker status page for this draft is: > https://datatracker.ietf.org/doc/draft-ietf-ice-trickle/ >=20 > There are also htmlized versions available at: > https://tools.ietf.org/html/draft-ietf-ice-trickle-14 > https://datatracker.ietf.org/doc/html/draft-ietf-ice-trickle-14 >=20 > A diff from the previous version is available at: > https://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-ice-trickle-14 >=20 >=20 > Please note that it may take a couple of minutes from the time of submi= ssion > until the htmlized version and diff are available at tools.ietf.org. >=20 > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ >=20 > _______________________________________________ > Ice mailing list > Ice@ietf.org > https://www.ietf.org/mailman/listinfo/ice >=20 --7581vWJnpTuECBIPKCAlu6R4At3ntHXTQ-- --Vb43rWIsrae5OaaSKtbCL5rkTusdUjjHP Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Comment: GPGTools - http://gpgtools.org iQIcBAEBCAAGBQJZt/csAAoJEOoGpJErxa2py80P/iqp0x4eM1l741oTvfu3JQGF GuMT77t/8v/9f8VyyOACWv30AKUrvgFZzQJql/1QjeuaRGLzmwZSXd5A4ohNVRnr ixcfrtNWQhOcYtep7ZTb76MhVKUoRER/Qy4m35VtQspZBv/ijP7i9bk1udM9QdPF rUDUIox8W4r1b4RskJm+JHZ3I2iCLq49+v1oF7Phh6k+j+D2JsPvUTbsCGUr48vJ KEfkQvfcnsH7E6scVfLZ4+jffwzJZaH/mKxhWao5GaUYwKRk+e8WB+/SwLuVd9CP PUbG3xSnlQPyMoyGZkpvVxpHE4KckxQhv4pTqfP2kvUbOHBJHd8VowDULv/rTdXe kjnfUVVcSa5FtcjYUaZICbUP6K/h498hRt+NvkZefzKbdewjc14Rf7sYWpuuQ4AH x7mhBnJc+zVJMXnju09nIdH7k9ncCpjVjNqhFTjjgbDJWsPGBx9fj1wkmYcTSquO F7eEciHDhFGavCpxK4iK3k/fX10w+BovuQEfZlBTYTgxxnxfBelFZ3Jg4FEjWia9 uMD9prxkh+camKEqmQ13spZCop9tdWPxg7N+za8ynao9YAy3snVscqpxWIIbatIc /1IcC095bwi2QK+LYP3vcTUDoiRy/0QQ6VX7GI5DmNEde1Sb5X+gGwYCRPnkD0AB PIAV8lDkpW1C0AYilyUV =QaQm -----END PGP SIGNATURE----- --Vb43rWIsrae5OaaSKtbCL5rkTusdUjjHP-- From nobody Tue Sep 12 08:13:46 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 CFD8E132192 for ; Tue, 12 Sep 2017 08:13:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, 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 4QQ4FVlJ7s2C for ; Tue, 12 Sep 2017 08:13:43 -0700 (PDT) Received: from mail-wr0-x233.google.com (mail-wr0-x233.google.com [IPv6:2a00:1450:400c:c0c::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 34ABE133025 for ; Tue, 12 Sep 2017 08:13:43 -0700 (PDT) Received: by mail-wr0-x233.google.com with SMTP id o42so23449302wrb.3 for ; Tue, 12 Sep 2017 08:13:43 -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=FVrVIefxiFVSbLHyeuNTLp+S1vBeonyTkNQs4MiT1tw=; b=a0EJaS/h9pecgJY6UAFnS3RakeqK4FV84xIFFp21A0/8VlnbwBh9f3rYcfNyHbRgUf wfJf2u20tR2Lbr0T696+61i1v+RocT1iy51VGkdNIUzvkk0UyZpU22yp057kkUDwG0vA D384L3+WzByXTZsVPQWKKTRChKsUI0VI66SEMEcv8OeWgCzm3EUWGFuDPMa0GMpUFq6J hB9hu0Cj8bW4ZMIxLh3ztaH8VdEuYV/LMeTHtUwBLaaiUuFJdwpbZa5483pOJSwnhL1P qLGUGWZMVbGYxVa5RkeVUSSndbJwN+c6qjw3IQPTkfbPTm6Ppos++OVZCCynTidMcjbm M8GQ== 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=FVrVIefxiFVSbLHyeuNTLp+S1vBeonyTkNQs4MiT1tw=; b=PI7iznqKUbjHxfn8xyx04RJPMSzr2H8nzhVtWcKEnOrPjSArK5MVZvmP/Px+kZXvtw 2L7QMrM1zyPU7HyIAwPHPVFp4OWQmPES0xqbIILwAatY1fwIG8rDCBubm5BeftL6E/Pq LOboZEVvwZ9qNAlw4uy9MvMyvWSHEoWGt8Q1NkSYZUPhoFE6PatrIciR40eeo8c5GNG2 s0J/Q5pK+6tLFVEJNKGYoDWSkrHNpJd8EB8lke93NAv++Xl7/OvmgQh8Zj8cZlIcbi7D 5Di0myvdxBHQC6ua4y13Zrkey4YnyQqkdoqe6ORFzwRp3rixwn4hVfEOkeOlqCHnFjzu 1uzQ== X-Gm-Message-State: AHPjjUhX2tdRscdFtygEiQWDAAuO/lRz7uTyqjKIwWQr+Y5HfkOBPnTk ZRZo1lSQ6BAUt9O0kEOWrbGdy/hecNZY X-Google-Smtp-Source: ADKCNb7cwL63Lw0bABxANfdvnz7hsv1EQDXfHCYBxJ/CXxBcZhHtltIwLdMFMycGPjFESkmF7KseWkMuKptLmK6gmjc= X-Received: by 10.223.171.21 with SMTP id q21mr12576867wrc.125.1505229221502; Tue, 12 Sep 2017 08:13:41 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Peter Thatcher Date: Tue, 12 Sep 2017 15:13:29 +0000 Message-ID: To: Christer Holmberg , ICE WG Content-Type: multipart/alternative; boundary="94eb2c1b47a40e065a0558ff7d05" Archived-At: Subject: Re: [Ice] Changing the text for when we can free 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: Tue, 12 Sep 2017 15:13:46 -0000 --94eb2c1b47a40e065a0558ff7d05 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Good idea. I updated the PR to match that. On Fri, Sep 8, 2017 at 12:34 AM Christer Holmberg < christer.holmberg@ericsson.com> wrote: > Hi, > > A minor nit. The text says: > > "The three-second delay handles cases when aggressive nomination is used, > and the selected pairs can quickly change after ICE has completed.=E2=80= =9D > > Earlier the text says that the three-second delay starts once the > CHECKLIST is Completed, so I think the text above should be aligned: > > "The three-second delay handles cases when aggressive nomination is used, > and the selected pairs can quickly change after a checklist has reached t= he > Completed state.=E2=80=9D > > Regards, > > Christer > > > From: Ice on behalf of "pthatcher@google.com" < > pthatcher@google.com> > Date: Thursday 7 September 2017 at 19:49 > To: "ice@ietf.org" > Subject: Re: [Ice] Changing the text for when we can free candidates > > Here's a nicer view of the diff on github: > > > https://github.com/ice-wg/rfc5245bis/pull/38/files#diff-2545e307f242412e0= 7ae64a9f1e69222L2995 > > On Thu, Sep 7, 2017 at 9:42 AM Peter Thatcher > wrote: > >> At IETF 99, we discussed PR38 ( >> https://github.com/ice-wg/rfc5245bis/pull/38/), which I just updated, >> and the only really unclear remaining is related to when an agent can fr= ee >> candidates. The decision at IETF 99 was that we would have something >> closer to the original text (which covers forking), but make the meaning= of >> "Completed" more clear. So, I have updated the PR to be like that, and >> here is the updated paragraph (which is very close to the original, but >> with the improvements suggested): >> >> >> "Once a checklist has reached the Completed state, the agent SHOULD wait >> an additional three seconds, and then it can cease responding to checks = or >> generating triggered checks on all local candidates other than >> the ones in the selected candidate pairs (one for each component). >> Once all ICE sessions have ceased using a given local candidate >> (a candidate may be used by multiple ICE sessions, e.g. in forking >> scenarios), the agent can free that candidate. The three-second delay >> handles cases when aggressive nomination is used, and the selected pairs >> can quickly change after ICE has completed. Freeing of server reflexive >> candidates is never explicit; it happens by lack of a keepalive. " >> >> >> And, for reference, here is the old paragraph: >> >> "Once ICE processing has reached the Completed state for all peers for >> media streams using those candidates, the agent SHOULD wait an >> additional three seconds, and then it MAY cease responding to checks or >> generating triggered checks on that candidate. It MAY free the >> candidate at that time. Freeing of server reflexive candidates is never >> explicit; it happens by lack of a keepalive. The three-second delay >> handles cases when aggressive nomination is used, and the selected pairs >> can quickly change after ICE has completed." >> >> >> Does this change cover what we were looking for at IETF 99? >> >> >> >> --94eb2c1b47a40e065a0558ff7d05 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Good idea.=C2=A0 I updated the PR to match that.

=
Hi,

A minor nit. The text says:

"The three-second delay handles cases when aggressive nomination = is used, and the selected pairs can quickly change after ICE has completed.= =E2=80=9D

Earlier the text says that the three-second delay starts once the CHEC= KLIST is Completed, so I think the text above should be aligned:=C2=A0

"The three-second delay handles cases when aggressive nomination = is used, and the selected pairs can quickly change after a checklist has re= ached the Completed state.=E2=80=9D

Regards,

Christer


From: Ice <ice-bounces@ietf.org> on behalf= of "pthatch= er@google.com" <pthatcher@google.com>
Date: Thursday 7 September 2017 at = 19:49
To: "ice@ietf.org" <ice@ietf.org>
Subject: Re: [Ice] Changing the tex= t for when we can free candidates


At IETF 99, we discussed PR38 (https://github.com/ice-wg/rfc5245bis/p= ull/38/), which I just updated, and the only really unclear remaining i= s related to when an agent can free candidates.=C2=A0 The decision at IETF 99 was that we would have something= closer to the original text (which covers forking), but make the meaning o= f "Completed" more clear.=C2=A0 So, I have updated the PR to be l= ike that, and here is the updated paragraph (which is very close to the original, but with the improvements suggested):


"Once a checklist has reached the Completed state, the agent SHOU= LD wait an additional three seconds, and then it can cease responding to ch= ecks or generating triggered checks on all local candidates other than
the ones in the selected candidate pairs (one for each component).
Once all ICE sessions have ceased using a given local candidate=C2=A0<= /div>
(a candidate may be used by multiple ICE sessions, e.g. in forking sce= narios), the agent can free that candidate.=C2=A0 The three-second delay ha= ndles cases when aggressive nomination is used, and the selected pairs can = quickly change after ICE has completed. Freeing of server reflexive candidates is never explicit; it happens by la= ck of a keepalive. =C2=A0"


And, for reference, here is the old paragraph:

"Once ICE processing has reached the Completed state for all peer= s for
media streams using those candidates, the agent SHOULD wait an
additional three seconds, and then it MAY cease responding to checks o= r
generating triggered checks on that candidate.=C2=A0 It MAY free the
candidate at that time. Freeing of server reflexive candidates is neve= r
explicit; it happens by lack of a keepalive.=C2=A0 The three-second de= lay
handles cases when aggressive nomination is used, and the selected pai= rs
can quickly change after ICE has completed."


Does this change cover what we were looking for at IETF 99?



--94eb2c1b47a40e065a0558ff7d05-- From nobody Tue Sep 12 23:51: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 B6A6D134125 for ; Tue, 12 Sep 2017 23:51:13 -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 E2naFUh9F01z for ; Tue, 12 Sep 2017 23:51:12 -0700 (PDT) Received: from sesbmg22.ericsson.net (sesbmg22.ericsson.net [193.180.251.48]) (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 B705B13352A for ; Tue, 12 Sep 2017 23:51:11 -0700 (PDT) X-AuditID: c1b4fb30-597ff70000005897-ea-59b8d55d257e Received: from ESESSHC021.ericsson.se (Unknown_Domain [153.88.183.81]) by sesbmg22.ericsson.net (Symantec Mail Security) with SMTP id E3.2F.22679.D55D8B95; Wed, 13 Sep 2017 08:51:09 +0200 (CEST) Received: from ESESSMB109.ericsson.se ([169.254.9.194]) by ESESSHC021.ericsson.se ([153.88.183.81]) with mapi id 14.03.0352.000; Wed, 13 Sep 2017 08:49:53 +0200 From: Christer Holmberg To: =?iso-8859-1?Q?Ari_Ker=E4nen?= CC: Emil Ivov , Peter Thatcher , ICE WG Thread-Topic: [Ice] Pull request: Candidate nomination rejection Thread-Index: AQHTKv8dds/hj0UYMk+bvgU9RIJWOKKvyT+AgAAu7wCAAO+igIAATCEAgAFBQoA= Date: Wed, 13 Sep 2017 06:49:52 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.7.6.170621 x-originating-ip: [153.88.183.146] Content-Type: text/plain; charset="iso-8859-1" Content-ID: <97FDFBA48EA95A4FBD86260FDA9BCD29@ericsson.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFlrOIsWRmVeSWpSXmKPExsUyM2J7oG7s1R2RBqsPGFis2TmBxeLbhVqL a8tfszoweyzYVOqxZMlPJo//bwIDmKO4bFJSczLLUov07RK4Mt78ectYsFKwomf3BbYGxh18 XYycHBICJhLzl99n7mLk4hASOMIo8XF5FyOEs4RRYseteWxdjBwcbAIWEt3/tEEaRARsJdY1 TGQCsZkF4iV+9a0Es4UF7CW6J7exQ9Q4SMyfPoUVwvaT2LL8PVgNi4CqxOwFdxlBbF4Ba4k/ V96wQuzayCTxqXsLO8guTqDmW38LQWoYBcQkvp9aA7VLXOLWk/lMEEcLSCzZc54ZwhaVePn4 H9guUQE9idkbD7FAxJUkfmy4xALRqydxY+oUNgjbWuL/li1QM7Ulli18zQxxj6DEyZlPWCYw is9Csm4WkvZZSNpnIWmfhaR9ASPrKkbR4tTipNx0IyO91KLM5OLi/Dy9vNSSTYzA6Du45bfB DsaXzx0PMQpwMCrx8O7buiNSiDWxrLgy9xCjBAezkgiv7FmgEG9KYmVValF+fFFpTmrxIUZp DhYlcV7HfRcihATSE0tSs1NTC1KLYLJMHJxSDYylLQe+vV/gdnC+vcA575oDHjvyvwh78Yrm JQpvf6eb1+eza8WJV3cuPfwq9npjz4pftQt93uxZ4ngm30g3ZbWbc5CL9f71Ets+J0hsUF9h U7Vuv56f50q9Gy0/tP6KLj9Zn5TyWMKladGtUAZuJ5Nv/Zp8036KywukGc5TvmXRMHuKpufl rjolluKMREMt5qLiRABH7rfnugIAAA== Archived-At: Subject: Re: [Ice] Pull request: Candidate nomination rejection 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, 13 Sep 2017 06:51:14 -0000 Hi, PR updated based on Ari=B9s comment (also fixed the editorial nit you mentioned on GitHub). Regards, Christer On 12/09/17 17:45, "Ari Ker=E4nen" wrote: >Looks good to me. Although instead of saying "MUST reply with 400", I'd >suggest selecting more appropriate error code if one is available. For >example: "MUST reject the nomination request with appropriate error code >response (e.g., 400)". > > >Cheers, >Ari > >> On 12 Sep 2017, at 10.07, Christer Holmberg >> wrote: >>=20 >> Pull request updated, based on Peter=B9s and Emil=B9s comments. >>=20 >> Regards, >>=20 >> Christer >>=20 >> From: Emil Ivov >> Date: Monday 11 September 2017 at 22:55 >> To: Christer Holmberg , >>"pthatcher@google.com" , "ice@ietf.org" >> >> Subject: Re: [Ice] Pull request: Candidate nomination rejection >>=20 >>=20 >> On Mon, 11 Sep 2017 at 12:07, Peter Thatcher >>wrote: >>>=20 >>> I think it would be more simple to just say the controlled side MUST >>>accept the transaction or the check list goes to the failed state. >>=20 >> Yes, I am much more in favor of that! >>=20 >> Emil >>=20 >>>=20 >>>=20 >>>=20 >>>=20 >>>=20 >>> On Mon, Sep 11, 2017 at 6:09 AM Christer Holmberg >>> wrote: >>>> Hi, >>>>=20 >>>> I have created a PR, which adds procedure text (controlling agent) >>>>for when a nomination request is rejected, and procedure text >>>>(controlled agent) for rejecting a nomination. >>>>=20 >>>> https://github.com/ice-wg/rfc5245bis/pull/44 >>>>=20 >>>> Regards, >>>>=20 >>>> Christer >>>> _______________________________________________ >>>> 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 >> sent from my mobile >> _______________________________________________ >> Ice mailing list >> Ice@ietf.org >> https://www.ietf.org/mailman/listinfo/ice > From nobody Wed Sep 20 05:51:38 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 293D213306B for ; Wed, 20 Sep 2017 05:51:36 -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 lXbp4kKDlWRH for ; Wed, 20 Sep 2017 05:51:34 -0700 (PDT) Received: from sesbmg22.ericsson.net (sesbmg22.ericsson.net [193.180.251.48]) (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 214711342FF for ; Wed, 20 Sep 2017 05:50:21 -0700 (PDT) X-AuditID: c1b4fb30-a5d009c000007145-66-59c2640b447d Received: from ESESSHC012.ericsson.se (Unknown_Domain [153.88.183.54]) by sesbmg22.ericsson.net (Symantec Mail Security) with SMTP id 4C.31.28997.B0462C95; Wed, 20 Sep 2017 14:50:19 +0200 (CEST) Received: from ESESSMB109.ericsson.se ([169.254.9.6]) by ESESSHC012.ericsson.se ([153.88.183.54]) with mapi id 14.03.0352.000; Wed, 20 Sep 2017 14:50:19 +0200 From: Christer Holmberg To: Christer Holmberg , =?windows-1254?Q?Ari_Ker=E4nen?= CC: Emil Ivov , Peter Thatcher , ICE WG Thread-Topic: [Ice] Pull request: Candidate nomination rejection Thread-Index: AQHTKv8dds/hj0UYMk+bvgU9RIJWOKKvyT+AgAAu7wCAAO+igIAATCEAgAFBQoCAC2UfAA== Date: Wed, 20 Sep 2017 12:50:17 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.7.7.170905 x-originating-ip: [153.88.183.147] Content-Type: text/plain; charset="windows-1254" Content-ID: <6167B459842A0C4396DEEE5998CF3C59@ericsson.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFlrOIsWRmVeSWpSXmKPExsUyM2K7mS53yqFIg+6bNhZrdk5gsfh2odbi 2vLXrA7MHgs2lXosWfKTyeP/m8AA5igum5TUnMyy1CJ9uwSujL13Z7IUfBKr6FxygbWBcbJw FyMnh4SAicTxideYuhi5OIQEjjBK/P53iQ3CWcQocffcF8YuRg4ONgELie5/2iANIgKlEksW NbOD2MwC8RK/+lYygdjCAvYS3ZPb2CFqHCTmT5/CCmGHSexbdQbMZhFQldh4+yZYDa+AtcSM tUehdj1mkpi3/zUbSIJTwEbiyY2PYEWMAmIS30+tYYJYJi5x68l8JoirBSSW7DnPDGGLSrx8 /A9sgaiAnsSGE7fZQW6WEFCSmLY1DaLVQOLIuZusELa1RO/NCYwQtrbEsoWvmSHuEZQ4OfMJ ywRG8VlIts1C0j4LSfssJO2zkLQvYGRdxShanFqclJtuZKSXWpSZXFycn6eXl1qyiREYfQe3 /DbYwfjyueMhRgEORiUe3lmxByOFWBPLiitzDzFKcDArifAejzgUKcSbklhZlVqUH19UmpNa fIhRmoNFSZzXcd+FCCGB9MSS1OzU1ILUIpgsEwenVAPjmnBPDTXh2YI79DbqyD1Jm/6Zrdtp TuCNPOe2Tffnc5e+bS5Zd2R9yqLKsx8l37ifaV3sc1JI9E6ZubN3o03vvY4+fetq79i7hzfI lNezhml4vz+j+Mq52uv43U82n5x2tyqJuN4NWKCvsVgjbIr9XRG5BXOnS+5/bTy38Puvnbzr k1TD43qUWIozEg21mIuKEwGkzrqAugIAAA== Archived-At: Subject: Re: [Ice] Pull request: Candidate nomination rejection 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, 20 Sep 2017 12:51:36 -0000 Hi, I intend to merge the PR tomorrow, and submit a new version of the draft. If you have any issues, please raise those TODAY. In addition, I will merge Jonathan L=92s PR (https://github.com/ice-wg/rfc5245bis/pull/43), and include it in the new version. (Peter=92s PR will be merged into the following version after that.) Regards, Christer On 13/09/17 09:49, "Ice on behalf of Christer Holmberg" wrote: >Hi, > >PR updated based on Ari=B9s comment (also fixed the editorial nit you >mentioned on GitHub). > >Regards, > >Christer > > >On 12/09/17 17:45, "Ari Ker=E4nen" wrote: > >>Looks good to me. Although instead of saying "MUST reply with 400", I'd >>suggest selecting more appropriate error code if one is available. For >>example: "MUST reject the nomination request with appropriate error code >>response (e.g., 400)". >> >> >>Cheers, >>Ari >> >>> On 12 Sep 2017, at 10.07, Christer Holmberg >>> wrote: >>>=20 >>> Pull request updated, based on Peter=B9s and Emil=B9s comments. >>>=20 >>> Regards, >>>=20 >>> Christer >>>=20 >>> From: Emil Ivov >>> Date: Monday 11 September 2017 at 22:55 >>> To: Christer Holmberg , >>>"pthatcher@google.com" , "ice@ietf.org" >>> >>> Subject: Re: [Ice] Pull request: Candidate nomination rejection >>>=20 >>>=20 >>> On Mon, 11 Sep 2017 at 12:07, Peter Thatcher >>>wrote: >>>>=20 >>>> I think it would be more simple to just say the controlled side MUST >>>>accept the transaction or the check list goes to the failed state. >>>=20 >>> Yes, I am much more in favor of that! >>>=20 >>> Emil >>>=20 >>>>=20 >>>>=20 >>>>=20 >>>>=20 >>>>=20 >>>> On Mon, Sep 11, 2017 at 6:09 AM Christer Holmberg >>>> wrote: >>>>> Hi, >>>>>=20 >>>>> I have created a PR, which adds procedure text (controlling agent) >>>>>for when a nomination request is rejected, and procedure text >>>>>(controlled agent) for rejecting a nomination. >>>>>=20 >>>>> https://github.com/ice-wg/rfc5245bis/pull/44 >>>>>=20 >>>>> Regards, >>>>>=20 >>>>> Christer >>>>> _______________________________________________ >>>>> 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 >>> sent from my mobile >>> _______________________________________________ >>> 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 From nobody Tue Sep 26 04:16:13 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 8D9BF1331FF; Tue, 26 Sep 2017 04:16:07 -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.62.1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <150642456748.13801.5381194383684999230@ietfa.amsl.com> Date: Tue, 26 Sep 2017 04:16:07 -0700 Archived-At: Subject: [Ice] I-D Action: draft-ietf-ice-rfc5245bis-11.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: Tue, 26 Sep 2017 11:16:08 -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 WG of the IETF. Title : Interactive Connectivity Establishment (ICE): A Protocol for Network Address Translator (NAT) Traversal Authors : Ari Keranen Christer Holmberg Jonathan Rosenberg Filename : draft-ietf-ice-rfc5245bis-11.txt Pages : 97 Date : 2017-09-26 Abstract: This document describes a protocol for Network Address Translator (NAT) traversal for UDP-based multimedia. This protocol is called Interactive Connectivity Establishment (ICE). ICE makes use of the Session Traversal Utilities for NAT (STUN) protocol and its extension, Traversal Using Relay NAT (TURN). This document obsoletes RFC 5245. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-ice-rfc5245bis/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-ice-rfc5245bis-11 https://datatracker.ietf.org/doc/html/draft-ietf-ice-rfc5245bis-11 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-ice-rfc5245bis-11 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Tue Sep 26 04:22:29 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 7FF5D13293A for ; Tue, 26 Sep 2017 04:22:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.219 X-Spam-Level: X-Spam-Status: No, score=-4.219 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, 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 Gm8sahGXVUyJ for ; Tue, 26 Sep 2017 04:22:25 -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 4BF30120720 for ; Tue, 26 Sep 2017 04:22:24 -0700 (PDT) X-AuditID: c1b4fb3a-9e1d49c0000051a3-b1-59ca386f2e00 Received: from ESESSHC016.ericsson.se (Unknown_Domain [153.88.183.66]) by sessmg22.ericsson.net (Symantec Mail Security) with SMTP id 13.50.20899.F683AC95; Tue, 26 Sep 2017 13:22:23 +0200 (CEST) Received: from ESESSMB109.ericsson.se ([169.254.9.6]) by ESESSHC016.ericsson.se ([153.88.183.66]) with mapi id 14.03.0352.000; Tue, 26 Sep 2017 13:22:20 +0200 From: Christer Holmberg To: "ice@ietf.org" Thread-Topic: Draft new version: draft-5245bis-11 Thread-Index: AQHTNrm3IS8sq6tixkSRZ/yK/nZYSQ== Date: Tue, 26 Sep 2017 11:22:19 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.7.7.170905 x-originating-ip: [153.88.183.18] Content-Type: multipart/alternative; boundary="_000_D5F014582296Fchristerholmbergericssoncom_" MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFvrDLMWRmVeSWpSXmKPExsUyM2K7k26+xalIg4Z2WYtvF2odGD2WLPnJ FMAYxWWTkpqTWZZapG+XwJXR/XA6W8Fc/opLpxQbGNfzdjFyckgImEhsfXeRqYuRi0NI4Aij xNt1n1ghnEWMEuva3gE5HBxsAhYS3f+0QRpEBBQlZrY8YwaxhQV0JJpvTGSFiBtKvDu5iQ3C 1pPo2fmFHcRmEVCVWNreAGbzClhLPO6bzQhiMwqISXw/tYYJxGYWEJe49WQ+E8RBAhJL9pxn hrBFJV4+/gc2XxRo5oYTt9kh4ooSH1/tY4ToTZBYsW0eK8R8QYmTM5+wTGAUmoVk7CwkZbOQ lEHEDSTen5vPDGFrSyxb+BrK1pfY+OUsI4RtLXF2awsLspoFjByrGEWLU4uLc9ONjPRSizKT i4vz8/TyUks2MQLj5OCW31Y7GA8+dzzEKMDBqMTD2yBzKlKINbGsuDL3EKMEB7OSCO9dM6AQ b0piZVVqUX58UWlOavEhRmkOFiVxXod9FyKEBNITS1KzU1MLUotgskwcnFINjPFVtXf3O57/ mNhZ47M8t8brtOkOnr9Zl+281D1r7U7k/Wq5dsPfeaWK3x67b8v6ug7FKxz6tVJva12VTISk +ZrdMb23+kIeJ13PrJzNq8b4fEa310cZqzn5QvpLf5x/J6B3Xo1rR8ZsnT8cJTOq8/p+C3hL rldb+nvbjSuftBZrn/qbK7c7QImlOCPRUIu5qDgRAAdMtwOPAgAA Archived-At: Subject: [Ice] Draft new version: draft-5245bis-11 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, 26 Sep 2017 11:22:27 -0000 --_000_D5F014582296Fchristerholmbergericssoncom_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable Hi, I=92ve submitted a new version (-11) of ICEbis. The following PRs were merged into the new version: https://github.com/ice-wg/rfc5245bis/pull/44 https://github.com/ice-wg/rfc5245bis/pull/43 Note that the request to check Peter=92s PR still stands, because the idea = is to merge that PR in the near future. https://github.com/ice-wg/rfc5245bis/pull/38 Regards, Christer --_000_D5F014582296Fchristerholmbergericssoncom_ Content-Type: text/html; charset="Windows-1252" Content-ID: <17D468DCEED8BE4AAD9042DFBEF7C7EF@ericsson.com> Content-Transfer-Encoding: quoted-printable
Hi,

I=92ve submitted a new version (-11) of ICEbis.

The following PRs were merged into the new version:



Note that the request to check Peter=92s PR still stands, because the = idea is to merge that PR in the near future.


Regards,

Christer
--_000_D5F014582296Fchristerholmbergericssoncom_-- From nobody Wed Sep 27 07:59:51 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 48513134CC5 for ; Wed, 27 Sep 2017 07:59:50 -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 IAg07aXc5pKE for ; Wed, 27 Sep 2017 07:59:46 -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 A02D7134E0F for ; Wed, 27 Sep 2017 07:53:33 -0700 (PDT) X-AuditID: c1b4fb2d-a4dff700000019be-55-59cbbb6b02a2 Received: from ESESSHC008.ericsson.se (Unknown_Domain [153.88.183.42]) by sessmg23.ericsson.net (Symantec Mail Security) with SMTP id 95.08.06590.B6BBBC95; Wed, 27 Sep 2017 16:53:31 +0200 (CEST) Received: from ESESSMB109.ericsson.se ([169.254.9.6]) by ESESSHC008.ericsson.se ([153.88.183.42]) with mapi id 14.03.0352.000; Wed, 27 Sep 2017 16:53:31 +0200 From: =?utf-8?B?QXJpIEtlcsOkbmVu?= To: Peter Thatcher CC: Christer Holmberg , ICE WG Thread-Topic: [Ice] Changing the text for when we can free candidates Thread-Index: AQHTJ/hOH52nEDnIyUGc2zj/g2F05aKpgScAgAD3FwCABsmqgIAXjWEA Date: Wed, 27 Sep 2017 14:53:30 +0000 Message-ID: References: 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.149] Content-Type: multipart/alternative; boundary="_000_B725FF1CEBF24955ACACA920F889D6F3ericssoncom_" MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFprHIsWRmVeSWpSXmKPExsUyM2K7lm727tORBo86zSy+Xai1uLb8NasD k8eCTaUeS5b8ZApgiuKySUnNySxLLdK3S+DK2NkhULC4rOLMwwUsDYxtxV2MnBwSAiYSz/e1 snUxcnEICRxhlFj0v4UFwlnEKDH/3HlmkCo2AVuJJ637WEFsEQFNicmTm8FsZgFfiS+HnrOA 2MICLhKHPp1ghqhxlbi17wILhO0mcX3hJrA4i4CqRO+pS2wgNq+AvcSWf3+hlk1gkmj7v5Qd JMEpEChxd+pisCJGATGJ76fWMEEsE5e49WQ+E8TZAhJL9kAcJyEgKvHy8T9WCFtJYu3h7SwQ 9ckS3z7/Z4FYJihxcuYTlgmMIrOQjJqFpGwWkrJZjBxAcU2J9bv0IUoUJaZ0P2SHsDUkWufM hbKtJQ5tvs+CrGYBI8cqRtHi1OLi3HQjY73Uoszk4uL8PL281JJNjMBYO7jlt+4OxtWvHQ8x CnAwKvHwLtx4OlKINbGsuDL3EKMEB7OSCG/PDqAQb0piZVVqUX58UWlOavEhRmkOFiVxXod9 FyKEBNITS1KzU1MLUotgskwcnFINjO7PTX5MPd+ls69q5m4Zo4cOZzc9KEjaN29L9Z+J1zeG XBWKDVBoC21hKHU+/rZ7yx5TDpPI2Ua6h+I9S3dldHzbeXlC3pL0BfGM0jsv9DkuldLZFN/y NP/4tQvfelSy5LKCmx+/eRhzyPIWo9DbXXtqFU50XFdu+xnWvXaS4TtxySB5WwXediWW4oxE Qy3mouJEAOHSmcexAgAA Archived-At: Subject: Re: [Ice] Changing the text for when we can free 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, 27 Sep 2017 14:59:50 -0000 --_000_B725FF1CEBF24955ACACA920F889D6F3ericssoncom_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 TG9va3MgZ29vZCB0byBtZS4gVGhhbmtzIQ0KDQoNCkNoZWVycywNCkFyaQ0KDQpPbiAxMiBTZXAg MjAxNywgYXQgMTguMTMsIFBldGVyIFRoYXRjaGVyIDxwdGhhdGNoZXJAZ29vZ2xlLmNvbTxtYWls dG86cHRoYXRjaGVyQGdvb2dsZS5jb20+PiB3cm90ZToNCg0KR29vZCBpZGVhLiAgSSB1cGRhdGVk IHRoZSBQUiB0byBtYXRjaCB0aGF0Lg0KDQpPbiBGcmksIFNlcCA4LCAyMDE3IGF0IDEyOjM0IEFN IENocmlzdGVyIEhvbG1iZXJnIDxjaHJpc3Rlci5ob2xtYmVyZ0Blcmljc3Nvbi5jb208bWFpbHRv OmNocmlzdGVyLmhvbG1iZXJnQGVyaWNzc29uLmNvbT4+IHdyb3RlOg0KSGksDQoNCkEgbWlub3Ig bml0LiBUaGUgdGV4dCBzYXlzOg0KDQoiVGhlIHRocmVlLXNlY29uZCBkZWxheSBoYW5kbGVzIGNh c2VzIHdoZW4gYWdncmVzc2l2ZSBub21pbmF0aW9uIGlzIHVzZWQsIGFuZCB0aGUgc2VsZWN0ZWQg cGFpcnMgY2FuIHF1aWNrbHkgY2hhbmdlIGFmdGVyIElDRSBoYXMgY29tcGxldGVkLuKAnQ0KDQpF YXJsaWVyIHRoZSB0ZXh0IHNheXMgdGhhdCB0aGUgdGhyZWUtc2Vjb25kIGRlbGF5IHN0YXJ0cyBv bmNlIHRoZSBDSEVDS0xJU1QgaXMgQ29tcGxldGVkLCBzbyBJIHRoaW5rIHRoZSB0ZXh0IGFib3Zl IHNob3VsZCBiZSBhbGlnbmVkOg0KDQoiVGhlIHRocmVlLXNlY29uZCBkZWxheSBoYW5kbGVzIGNh c2VzIHdoZW4gYWdncmVzc2l2ZSBub21pbmF0aW9uIGlzIHVzZWQsIGFuZCB0aGUgc2VsZWN0ZWQg cGFpcnMgY2FuIHF1aWNrbHkgY2hhbmdlIGFmdGVyIGEgY2hlY2tsaXN0IGhhcyByZWFjaGVkIHRo ZSBDb21wbGV0ZWQgc3RhdGUu4oCdDQoNClJlZ2FyZHMsDQoNCkNocmlzdGVyDQoNCg0KRnJvbTog SWNlIDxpY2UtYm91bmNlc0BpZXRmLm9yZzxtYWlsdG86aWNlLWJvdW5jZXNAaWV0Zi5vcmc+PiBv biBiZWhhbGYgb2YgInB0aGF0Y2hlckBnb29nbGUuY29tPG1haWx0bzpwdGhhdGNoZXJAZ29vZ2xl LmNvbT4iIDxwdGhhdGNoZXJAZ29vZ2xlLmNvbTxtYWlsdG86cHRoYXRjaGVyQGdvb2dsZS5jb20+ Pg0KRGF0ZTogVGh1cnNkYXkgNyBTZXB0ZW1iZXIgMjAxNyBhdCAxOTo0OQ0KVG86ICJpY2VAaWV0 Zi5vcmc8bWFpbHRvOmljZUBpZXRmLm9yZz4iIDxpY2VAaWV0Zi5vcmc8bWFpbHRvOmljZUBpZXRm Lm9yZz4+DQpTdWJqZWN0OiBSZTogW0ljZV0gQ2hhbmdpbmcgdGhlIHRleHQgZm9yIHdoZW4gd2Ug Y2FuIGZyZWUgY2FuZGlkYXRlcw0KDQpIZXJlJ3MgYSBuaWNlciB2aWV3IG9mIHRoZSBkaWZmIG9u IGdpdGh1YjoNCg0KaHR0cHM6Ly9naXRodWIuY29tL2ljZS13Zy9yZmM1MjQ1YmlzL3B1bGwvMzgv ZmlsZXMjZGlmZi0yNTQ1ZTMwN2YyNDI0MTJlMDdhZTY0YTlmMWU2OTIyMkwyOTk1DQoNCk9uIFRo dSwgU2VwIDcsIDIwMTcgYXQgOTo0MiBBTSBQZXRlciBUaGF0Y2hlciA8cHRoYXRjaGVyQGdvb2ds ZS5jb208bWFpbHRvOnB0aGF0Y2hlckBnb29nbGUuY29tPj4gd3JvdGU6DQpBdCBJRVRGIDk5LCB3 ZSBkaXNjdXNzZWQgUFIzOCAoaHR0cHM6Ly9naXRodWIuY29tL2ljZS13Zy9yZmM1MjQ1YmlzL3B1 bGwvMzgvKSwgd2hpY2ggSSBqdXN0IHVwZGF0ZWQsIGFuZCB0aGUgb25seSByZWFsbHkgdW5jbGVh ciByZW1haW5pbmcgaXMgcmVsYXRlZCB0byB3aGVuIGFuIGFnZW50IGNhbiBmcmVlIGNhbmRpZGF0 ZXMuICBUaGUgZGVjaXNpb24gYXQgSUVURiA5OSB3YXMgdGhhdCB3ZSB3b3VsZCBoYXZlIHNvbWV0 aGluZyBjbG9zZXIgdG8gdGhlIG9yaWdpbmFsIHRleHQgKHdoaWNoIGNvdmVycyBmb3JraW5nKSwg YnV0IG1ha2UgdGhlIG1lYW5pbmcgb2YgIkNvbXBsZXRlZCIgbW9yZSBjbGVhci4gIFNvLCBJIGhh dmUgdXBkYXRlZCB0aGUgUFIgdG8gYmUgbGlrZSB0aGF0LCBhbmQgaGVyZSBpcyB0aGUgdXBkYXRl ZCBwYXJhZ3JhcGggKHdoaWNoIGlzIHZlcnkgY2xvc2UgdG8gdGhlIG9yaWdpbmFsLCBidXQgd2l0 aCB0aGUgaW1wcm92ZW1lbnRzIHN1Z2dlc3RlZCk6DQoNCg0KIk9uY2UgYSBjaGVja2xpc3QgaGFz IHJlYWNoZWQgdGhlIENvbXBsZXRlZCBzdGF0ZSwgdGhlIGFnZW50IFNIT1VMRCB3YWl0IGFuIGFk ZGl0aW9uYWwgdGhyZWUgc2Vjb25kcywgYW5kIHRoZW4gaXQgY2FuIGNlYXNlIHJlc3BvbmRpbmcg dG8gY2hlY2tzIG9yIGdlbmVyYXRpbmcgdHJpZ2dlcmVkIGNoZWNrcyBvbiBhbGwgbG9jYWwgY2Fu ZGlkYXRlcyBvdGhlciB0aGFuDQp0aGUgb25lcyBpbiB0aGUgc2VsZWN0ZWQgY2FuZGlkYXRlIHBh aXJzIChvbmUgZm9yIGVhY2ggY29tcG9uZW50KS4NCk9uY2UgYWxsIElDRSBzZXNzaW9ucyBoYXZl IGNlYXNlZCB1c2luZyBhIGdpdmVuIGxvY2FsIGNhbmRpZGF0ZQ0KKGEgY2FuZGlkYXRlIG1heSBi ZSB1c2VkIGJ5IG11bHRpcGxlIElDRSBzZXNzaW9ucywgZS5nLiBpbiBmb3JraW5nIHNjZW5hcmlv cyksIHRoZSBhZ2VudCBjYW4gZnJlZSB0aGF0IGNhbmRpZGF0ZS4gIFRoZSB0aHJlZS1zZWNvbmQg ZGVsYXkgaGFuZGxlcyBjYXNlcyB3aGVuIGFnZ3Jlc3NpdmUgbm9taW5hdGlvbiBpcyB1c2VkLCBh bmQgdGhlIHNlbGVjdGVkIHBhaXJzIGNhbiBxdWlja2x5IGNoYW5nZSBhZnRlciBJQ0UgaGFzIGNv bXBsZXRlZC4gRnJlZWluZyBvZiBzZXJ2ZXIgcmVmbGV4aXZlIGNhbmRpZGF0ZXMgaXMgbmV2ZXIg ZXhwbGljaXQ7IGl0IGhhcHBlbnMgYnkgbGFjayBvZiBhIGtlZXBhbGl2ZS4gICINCg0KDQpBbmQs IGZvciByZWZlcmVuY2UsIGhlcmUgaXMgdGhlIG9sZCBwYXJhZ3JhcGg6DQoNCiJPbmNlIElDRSBw cm9jZXNzaW5nIGhhcyByZWFjaGVkIHRoZSBDb21wbGV0ZWQgc3RhdGUgZm9yIGFsbCBwZWVycyBm b3INCm1lZGlhIHN0cmVhbXMgdXNpbmcgdGhvc2UgY2FuZGlkYXRlcywgdGhlIGFnZW50IFNIT1VM RCB3YWl0IGFuDQphZGRpdGlvbmFsIHRocmVlIHNlY29uZHMsIGFuZCB0aGVuIGl0IE1BWSBjZWFz ZSByZXNwb25kaW5nIHRvIGNoZWNrcyBvcg0KZ2VuZXJhdGluZyB0cmlnZ2VyZWQgY2hlY2tzIG9u IHRoYXQgY2FuZGlkYXRlLiAgSXQgTUFZIGZyZWUgdGhlDQpjYW5kaWRhdGUgYXQgdGhhdCB0aW1l LiBGcmVlaW5nIG9mIHNlcnZlciByZWZsZXhpdmUgY2FuZGlkYXRlcyBpcyBuZXZlcg0KZXhwbGlj aXQ7IGl0IGhhcHBlbnMgYnkgbGFjayBvZiBhIGtlZXBhbGl2ZS4gIFRoZSB0aHJlZS1zZWNvbmQg ZGVsYXkNCmhhbmRsZXMgY2FzZXMgd2hlbiBhZ2dyZXNzaXZlIG5vbWluYXRpb24gaXMgdXNlZCwg YW5kIHRoZSBzZWxlY3RlZCBwYWlycw0KY2FuIHF1aWNrbHkgY2hhbmdlIGFmdGVyIElDRSBoYXMg Y29tcGxldGVkLiINCg0KDQpEb2VzIHRoaXMgY2hhbmdlIGNvdmVyIHdoYXQgd2Ugd2VyZSBsb29r aW5nIGZvciBhdCBJRVRGIDk5Pw0KDQoNCg0KX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX18NCkljZSBtYWlsaW5nIGxpc3QNCkljZUBpZXRmLm9yZzxtYWlsdG86 SWNlQGlldGYub3JnPg0KaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9pY2UN Cg0K --_000_B725FF1CEBF24955ACACA920F889D6F3ericssoncom_ Content-Type: text/html; charset="utf-8" Content-ID: <407CD4A7E05A4B478531A2CB565C552D@ericsson.com> Content-Transfer-Encoding: base64 PGh0bWw+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIgY29udGVudD0i dGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjwvaGVhZD4NCjxib2R5IHN0eWxlPSJ3b3JkLXdy YXA6IGJyZWFrLXdvcmQ7IC13ZWJraXQtbmJzcC1tb2RlOiBzcGFjZTsgLXdlYmtpdC1saW5lLWJy ZWFrOiBhZnRlci13aGl0ZS1zcGFjZTsiIGNsYXNzPSIiPg0KTG9va3MgZ29vZCB0byBtZS4gVGhh bmtzIQ0KPGRpdiBjbGFzcz0iIj48YnIgY2xhc3M9IiI+DQo8L2Rpdj4NCjxkaXYgY2xhc3M9IiI+ PGJyIGNsYXNzPSIiPg0KPC9kaXY+DQo8ZGl2IGNsYXNzPSIiPkNoZWVycyw8L2Rpdj4NCjxkaXYg Y2xhc3M9IiI+QXJpPC9kaXY+DQo8ZGl2IGNsYXNzPSIiPjxiciBjbGFzcz0iIj4NCjxkaXY+DQo8 YmxvY2txdW90ZSB0eXBlPSJjaXRlIiBjbGFzcz0iIj4NCjxkaXYgY2xhc3M9IiI+T24gMTIgU2Vw IDIwMTcsIGF0IDE4LjEzLCBQZXRlciBUaGF0Y2hlciAmbHQ7PGEgaHJlZj0ibWFpbHRvOnB0aGF0 Y2hlckBnb29nbGUuY29tIiBjbGFzcz0iIj5wdGhhdGNoZXJAZ29vZ2xlLmNvbTwvYT4mZ3Q7IHdy b3RlOjwvZGl2Pg0KPGJyIGNsYXNzPSJBcHBsZS1pbnRlcmNoYW5nZS1uZXdsaW5lIj4NCjxkaXYg Y2xhc3M9IiI+DQo8ZGl2IGRpcj0ibHRyIiBjbGFzcz0iIj5Hb29kIGlkZWEuJm5ic3A7IEkgdXBk YXRlZCB0aGUgUFIgdG8gbWF0Y2ggdGhhdC48L2Rpdj4NCjxiciBjbGFzcz0iIj4NCjxkaXYgY2xh c3M9ImdtYWlsX3F1b3RlIj4NCjxkaXYgZGlyPSJsdHIiIGNsYXNzPSIiPk9uIEZyaSwgU2VwIDgs IDIwMTcgYXQgMTI6MzQgQU0gQ2hyaXN0ZXIgSG9sbWJlcmcgJmx0OzxhIGhyZWY9Im1haWx0bzpj aHJpc3Rlci5ob2xtYmVyZ0Blcmljc3Nvbi5jb20iIGNsYXNzPSIiPmNocmlzdGVyLmhvbG1iZXJn QGVyaWNzc29uLmNvbTwvYT4mZ3Q7IHdyb3RlOjxiciBjbGFzcz0iIj4NCjwvZGl2Pg0KPGJsb2Nr cXVvdGUgY2xhc3M9ImdtYWlsX3F1b3RlIiBzdHlsZT0ibWFyZ2luOjAgMCAwIC44ZXg7Ym9yZGVy LWxlZnQ6MXB4ICNjY2Mgc29saWQ7cGFkZGluZy1sZWZ0OjFleCI+DQo8ZGl2IHN0eWxlPSJ3b3Jk LXdyYXA6IGJyZWFrLXdvcmQ7IGZvbnQtc2l6ZTogMTRweDsgZm9udC1mYW1pbHk6IENhbGlicmks IHNhbnMtc2VyaWY7IiBjbGFzcz0iIj4NCjxkaXYgY2xhc3M9IiI+SGksPC9kaXY+DQo8ZGl2IGNs YXNzPSIiPjxiciBjbGFzcz0iIj4NCjwvZGl2Pg0KPGRpdiBjbGFzcz0iIj5BIG1pbm9yIG5pdC4g VGhlIHRleHQgc2F5czo8L2Rpdj4NCjxkaXYgY2xhc3M9IiI+PGJyIGNsYXNzPSIiPg0KPC9kaXY+ DQo8ZGl2IGNsYXNzPSIiPiZxdW90O1RoZSB0aHJlZS1zZWNvbmQgZGVsYXkgaGFuZGxlcyBjYXNl cyB3aGVuIGFnZ3Jlc3NpdmUgbm9taW5hdGlvbiBpcyB1c2VkLCBhbmQgdGhlIHNlbGVjdGVkIHBh aXJzIGNhbiBxdWlja2x5IGNoYW5nZSBhZnRlciBJQ0UgaGFzIGNvbXBsZXRlZC7igJ08L2Rpdj4N CjxkaXYgY2xhc3M9IiI+PGJyIGNsYXNzPSIiPg0KPC9kaXY+DQo8ZGl2IGNsYXNzPSIiPkVhcmxp ZXIgdGhlIHRleHQgc2F5cyB0aGF0IHRoZSB0aHJlZS1zZWNvbmQgZGVsYXkgc3RhcnRzIG9uY2Ug dGhlIENIRUNLTElTVCBpcyBDb21wbGV0ZWQsIHNvIEkgdGhpbmsgdGhlIHRleHQgYWJvdmUgc2hv dWxkIGJlIGFsaWduZWQ6Jm5ic3A7PC9kaXY+DQo8ZGl2IGNsYXNzPSIiPjxiciBjbGFzcz0iIj4N CjwvZGl2Pg0KPGRpdiBjbGFzcz0iIj4NCjxkaXYgY2xhc3M9IiI+JnF1b3Q7VGhlIHRocmVlLXNl Y29uZCBkZWxheSBoYW5kbGVzIGNhc2VzIHdoZW4gYWdncmVzc2l2ZSBub21pbmF0aW9uIGlzIHVz ZWQsIGFuZCB0aGUgc2VsZWN0ZWQgcGFpcnMgY2FuIHF1aWNrbHkgY2hhbmdlIGFmdGVyIGEgY2hl Y2tsaXN0IGhhcyByZWFjaGVkIHRoZSBDb21wbGV0ZWQgc3RhdGUu4oCdPC9kaXY+DQo8L2Rpdj4N CjxkaXYgY2xhc3M9IiI+PGJyIGNsYXNzPSIiPg0KPC9kaXY+DQo8ZGl2IGNsYXNzPSIiPlJlZ2Fy ZHMsPC9kaXY+DQo8ZGl2IGNsYXNzPSIiPjxiciBjbGFzcz0iIj4NCjwvZGl2Pg0KPGRpdiBjbGFz cz0iIj5DaHJpc3RlcjwvZGl2Pg0KPGRpdiBjbGFzcz0iIj48YnIgY2xhc3M9IiI+DQo8L2Rpdj4N CjxkaXYgY2xhc3M9IiI+PGJyIGNsYXNzPSIiPg0KPC9kaXY+DQo8c3BhbiBpZD0ibV84Mjg3NDcw MjkwMTE5NzgxNTEyT0xLX1NSQ19CT0RZX1NFQ1RJT04iIGNsYXNzPSIiPg0KPGRpdiBzdHlsZT0i Zm9udC1mYW1pbHk6IENhbGlicmk7IGZvbnQtc2l6ZTogMTFwdDsgdGV4dC1hbGlnbjogbGVmdDsg Ym9yZGVyLXdpZHRoOiAxcHQgbWVkaXVtIG1lZGl1bTsgYm9yZGVyLXN0eWxlOiBzb2xpZCBub25l IG5vbmU7IHBhZGRpbmc6IDNwdCAwaW4gMGluOyBib3JkZXItdG9wLWNvbG9yOiByZ2IoMTgxLCAx OTYsIDIyMyk7IiBjbGFzcz0iIj4NCjxzcGFuIHN0eWxlPSJmb250LXdlaWdodDpib2xkIiBjbGFz cz0iIj5Gcm9tOiA8L3NwYW4+SWNlICZsdDs8YSBocmVmPSJtYWlsdG86aWNlLWJvdW5jZXNAaWV0 Zi5vcmciIHRhcmdldD0iX2JsYW5rIiBjbGFzcz0iIj5pY2UtYm91bmNlc0BpZXRmLm9yZzwvYT4m Z3Q7IG9uIGJlaGFsZiBvZiAmcXVvdDs8YSBocmVmPSJtYWlsdG86cHRoYXRjaGVyQGdvb2dsZS5j b20iIHRhcmdldD0iX2JsYW5rIiBjbGFzcz0iIj5wdGhhdGNoZXJAZ29vZ2xlLmNvbTwvYT4mcXVv dDsgJmx0OzxhIGhyZWY9Im1haWx0bzpwdGhhdGNoZXJAZ29vZ2xlLmNvbSIgdGFyZ2V0PSJfYmxh bmsiIGNsYXNzPSIiPnB0aGF0Y2hlckBnb29nbGUuY29tPC9hPiZndDs8YnIgY2xhc3M9IiI+DQo8 c3BhbiBzdHlsZT0iZm9udC13ZWlnaHQ6Ym9sZCIgY2xhc3M9IiI+RGF0ZTogPC9zcGFuPlRodXJz ZGF5IDcgU2VwdGVtYmVyIDIwMTcgYXQgMTk6NDk8YnIgY2xhc3M9IiI+DQo8c3BhbiBzdHlsZT0i Zm9udC13ZWlnaHQ6Ym9sZCIgY2xhc3M9IiI+VG86IDwvc3Bhbj4mcXVvdDs8YSBocmVmPSJtYWls dG86aWNlQGlldGYub3JnIiB0YXJnZXQ9Il9ibGFuayIgY2xhc3M9IiI+aWNlQGlldGYub3JnPC9h PiZxdW90OyAmbHQ7PGEgaHJlZj0ibWFpbHRvOmljZUBpZXRmLm9yZyIgdGFyZ2V0PSJfYmxhbmsi IGNsYXNzPSIiPmljZUBpZXRmLm9yZzwvYT4mZ3Q7PGJyIGNsYXNzPSIiPg0KPHNwYW4gc3R5bGU9 ImZvbnQtd2VpZ2h0OmJvbGQiIGNsYXNzPSIiPlN1YmplY3Q6IDwvc3Bhbj5SZTogW0ljZV0gQ2hh bmdpbmcgdGhlIHRleHQgZm9yIHdoZW4gd2UgY2FuIGZyZWUgY2FuZGlkYXRlczxiciBjbGFzcz0i Ij4NCjwvZGl2Pg0KPC9zcGFuPjwvZGl2Pg0KPGRpdiBzdHlsZT0id29yZC13cmFwOiBicmVhay13 b3JkOyBmb250LXNpemU6IDE0cHg7IGZvbnQtZmFtaWx5OiBDYWxpYnJpLCBzYW5zLXNlcmlmOyIg Y2xhc3M9IiI+DQo8c3BhbiBpZD0ibV84Mjg3NDcwMjkwMTE5NzgxNTEyT0xLX1NSQ19CT0RZX1NF Q1RJT04iIGNsYXNzPSIiPg0KPGRpdiBjbGFzcz0iIj48YnIgY2xhc3M9IiI+DQo8L2Rpdj4NCjxk aXYgY2xhc3M9IiI+DQo8ZGl2IGNsYXNzPSIiPg0KPGRpdiBkaXI9Imx0ciIgY2xhc3M9IiI+SGVy ZSdzIGEgbmljZXIgdmlldyBvZiB0aGUgZGlmZiBvbiBnaXRodWI6DQo8ZGl2IGNsYXNzPSIiPjxi ciBjbGFzcz0iIj4NCjwvZGl2Pg0KPGRpdiBjbGFzcz0iIj48YSBocmVmPSJodHRwczovL2dpdGh1 Yi5jb20vaWNlLXdnL3JmYzUyNDViaXMvcHVsbC8zOC9maWxlcyNkaWZmLTI1NDVlMzA3ZjI0MjQx MmUwN2FlNjRhOWYxZTY5MjIyTDI5OTUiIHRhcmdldD0iX2JsYW5rIiBjbGFzcz0iIj5odHRwczov L2dpdGh1Yi5jb20vaWNlLXdnL3JmYzUyNDViaXMvcHVsbC8zOC9maWxlcyNkaWZmLTI1NDVlMzA3 ZjI0MjQxMmUwN2FlNjRhOWYxZTY5MjIyTDI5OTU8L2E+PGJyIGNsYXNzPSIiPg0KPC9kaXY+DQo8 L2Rpdj4NCjxiciBjbGFzcz0iIj4NCjxkaXYgY2xhc3M9ImdtYWlsX3F1b3RlIj4NCjxkaXYgZGly PSJsdHIiIGNsYXNzPSIiPk9uIFRodSwgU2VwIDcsIDIwMTcgYXQgOTo0MiBBTSBQZXRlciBUaGF0 Y2hlciAmbHQ7PGEgaHJlZj0ibWFpbHRvOnB0aGF0Y2hlckBnb29nbGUuY29tIiB0YXJnZXQ9Il9i bGFuayIgY2xhc3M9IiI+cHRoYXRjaGVyQGdvb2dsZS5jb208L2E+Jmd0OyB3cm90ZTo8YnIgY2xh c3M9IiI+DQo8L2Rpdj4NCjxibG9ja3F1b3RlIGNsYXNzPSJnbWFpbF9xdW90ZSIgc3R5bGU9Im1h cmdpbjowIDAgMCAuOGV4O2JvcmRlci1sZWZ0OjFweCAjY2NjIHNvbGlkO3BhZGRpbmctbGVmdDox ZXgiPg0KPGRpdiBkaXI9Imx0ciIgY2xhc3M9IiI+DQo8ZGl2IGNsYXNzPSIiPkF0IElFVEYgOTks IHdlIGRpc2N1c3NlZCBQUjM4ICg8YSBocmVmPSJodHRwczovL2dpdGh1Yi5jb20vaWNlLXdnL3Jm YzUyNDViaXMvcHVsbC8zOC8iIHRhcmdldD0iX2JsYW5rIiBjbGFzcz0iIj5odHRwczovL2dpdGh1 Yi5jb20vaWNlLXdnL3JmYzUyNDViaXMvcHVsbC8zOC88L2E+KSwgd2hpY2ggSSBqdXN0IHVwZGF0 ZWQsIGFuZCB0aGUgb25seSByZWFsbHkgdW5jbGVhciByZW1haW5pbmcgaXMgcmVsYXRlZCB0byB3 aGVuDQogYW4gYWdlbnQgY2FuIGZyZWUgY2FuZGlkYXRlcy4mbmJzcDsgVGhlIGRlY2lzaW9uIGF0 IElFVEYgOTkgd2FzIHRoYXQgd2Ugd291bGQgaGF2ZSBzb21ldGhpbmcgY2xvc2VyIHRvIHRoZSBv cmlnaW5hbCB0ZXh0ICh3aGljaCBjb3ZlcnMgZm9ya2luZyksIGJ1dCBtYWtlIHRoZSBtZWFuaW5n IG9mICZxdW90O0NvbXBsZXRlZCZxdW90OyBtb3JlIGNsZWFyLiZuYnNwOyBTbywgSSBoYXZlIHVw ZGF0ZWQgdGhlIFBSIHRvIGJlIGxpa2UgdGhhdCwgYW5kIGhlcmUgaXMgdGhlIHVwZGF0ZWQNCiBw YXJhZ3JhcGggKHdoaWNoIGlzIHZlcnkgY2xvc2UgdG8gdGhlIG9yaWdpbmFsLCBidXQgd2l0aCB0 aGUgaW1wcm92ZW1lbnRzIHN1Z2dlc3RlZCk6PC9kaXY+DQo8ZGl2IGNsYXNzPSIiPjxiciBjbGFz cz0iIj4NCjwvZGl2Pg0KPGRpdiBjbGFzcz0iIj48YnIgY2xhc3M9IiI+DQo8L2Rpdj4NCjxkaXYg Y2xhc3M9IiI+JnF1b3Q7T25jZSBhIGNoZWNrbGlzdCBoYXMgcmVhY2hlZCB0aGUgQ29tcGxldGVk IHN0YXRlLCB0aGUgYWdlbnQgU0hPVUxEIHdhaXQgYW4gYWRkaXRpb25hbCB0aHJlZSBzZWNvbmRz LCBhbmQgdGhlbiBpdCBjYW4gY2Vhc2UgcmVzcG9uZGluZyB0byBjaGVja3Mgb3IgZ2VuZXJhdGlu ZyB0cmlnZ2VyZWQgY2hlY2tzIG9uIGFsbCBsb2NhbCBjYW5kaWRhdGVzIG90aGVyIHRoYW48L2Rp dj4NCjxkaXYgY2xhc3M9IiI+dGhlIG9uZXMgaW4gdGhlIHNlbGVjdGVkIGNhbmRpZGF0ZSBwYWly cyAob25lIGZvciBlYWNoIGNvbXBvbmVudCkuPC9kaXY+DQo8ZGl2IGNsYXNzPSIiPk9uY2UgYWxs IElDRSBzZXNzaW9ucyBoYXZlIGNlYXNlZCB1c2luZyBhIGdpdmVuIGxvY2FsIGNhbmRpZGF0ZSZu YnNwOzwvZGl2Pg0KPGRpdiBjbGFzcz0iIj4oYSBjYW5kaWRhdGUgbWF5IGJlIHVzZWQgYnkgbXVs dGlwbGUgSUNFIHNlc3Npb25zLCBlLmcuIGluIGZvcmtpbmcgc2NlbmFyaW9zKSwgdGhlIGFnZW50 IGNhbiBmcmVlIHRoYXQgY2FuZGlkYXRlLiZuYnNwOyBUaGUgdGhyZWUtc2Vjb25kIGRlbGF5IGhh bmRsZXMgY2FzZXMgd2hlbiBhZ2dyZXNzaXZlIG5vbWluYXRpb24gaXMgdXNlZCwgYW5kIHRoZSBz ZWxlY3RlZCBwYWlycyBjYW4gcXVpY2tseSBjaGFuZ2UgYWZ0ZXIgSUNFIGhhcw0KIGNvbXBsZXRl ZC4gRnJlZWluZyBvZiBzZXJ2ZXIgcmVmbGV4aXZlIGNhbmRpZGF0ZXMgaXMgbmV2ZXIgZXhwbGlj aXQ7IGl0IGhhcHBlbnMgYnkgbGFjayBvZiBhIGtlZXBhbGl2ZS4gJm5ic3A7JnF1b3Q7PC9kaXY+ DQo8ZGl2IGNsYXNzPSIiPjxiciBjbGFzcz0iIj4NCjwvZGl2Pg0KPGRpdiBjbGFzcz0iIj48YnIg Y2xhc3M9IiI+DQo8L2Rpdj4NCjxkaXYgY2xhc3M9IiI+QW5kLCBmb3IgcmVmZXJlbmNlLCBoZXJl IGlzIHRoZSBvbGQgcGFyYWdyYXBoOjwvZGl2Pg0KPGRpdiBjbGFzcz0iIj48YnIgY2xhc3M9IiI+ DQo8L2Rpdj4NCjxkaXYgY2xhc3M9IiI+JnF1b3Q7T25jZSBJQ0UgcHJvY2Vzc2luZyBoYXMgcmVh Y2hlZCB0aGUgQ29tcGxldGVkIHN0YXRlIGZvciBhbGwgcGVlcnMgZm9yPC9kaXY+DQo8ZGl2IGNs YXNzPSIiPm1lZGlhIHN0cmVhbXMgdXNpbmcgdGhvc2UgY2FuZGlkYXRlcywgdGhlIGFnZW50IFNI T1VMRCB3YWl0IGFuPC9kaXY+DQo8ZGl2IGNsYXNzPSIiPmFkZGl0aW9uYWwgdGhyZWUgc2Vjb25k cywgYW5kIHRoZW4gaXQgTUFZIGNlYXNlIHJlc3BvbmRpbmcgdG8gY2hlY2tzIG9yPC9kaXY+DQo8 ZGl2IGNsYXNzPSIiPmdlbmVyYXRpbmcgdHJpZ2dlcmVkIGNoZWNrcyBvbiB0aGF0IGNhbmRpZGF0 ZS4mbmJzcDsgSXQgTUFZIGZyZWUgdGhlPC9kaXY+DQo8ZGl2IGNsYXNzPSIiPmNhbmRpZGF0ZSBh dCB0aGF0IHRpbWUuIEZyZWVpbmcgb2Ygc2VydmVyIHJlZmxleGl2ZSBjYW5kaWRhdGVzIGlzIG5l dmVyPC9kaXY+DQo8ZGl2IGNsYXNzPSIiPmV4cGxpY2l0OyBpdCBoYXBwZW5zIGJ5IGxhY2sgb2Yg YSBrZWVwYWxpdmUuJm5ic3A7IFRoZSB0aHJlZS1zZWNvbmQgZGVsYXk8L2Rpdj4NCjxkaXYgY2xh c3M9IiI+aGFuZGxlcyBjYXNlcyB3aGVuIGFnZ3Jlc3NpdmUgbm9taW5hdGlvbiBpcyB1c2VkLCBh bmQgdGhlIHNlbGVjdGVkIHBhaXJzPC9kaXY+DQo8ZGl2IGNsYXNzPSIiPmNhbiBxdWlja2x5IGNo YW5nZSBhZnRlciBJQ0UgaGFzIGNvbXBsZXRlZC4mcXVvdDs8L2Rpdj4NCjxkaXYgY2xhc3M9IiI+ PGJyIGNsYXNzPSIiPg0KPC9kaXY+DQo8ZGl2IGNsYXNzPSIiPjxiciBjbGFzcz0iIj4NCjwvZGl2 Pg0KPGRpdiBjbGFzcz0iIj5Eb2VzIHRoaXMgY2hhbmdlIGNvdmVyIHdoYXQgd2Ugd2VyZSBsb29r aW5nIGZvciBhdCBJRVRGIDk5PzwvZGl2Pg0KPGRpdiBjbGFzcz0iIj48YnIgY2xhc3M9IiI+DQo8 L2Rpdj4NCjxkaXYgY2xhc3M9IiI+PGJyIGNsYXNzPSIiPg0KPC9kaXY+DQo8ZGl2IGNsYXNzPSIi PjxiciBjbGFzcz0iIj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Jsb2NrcXVvdGU+DQo8L2Rpdj4NCjwv ZGl2Pg0KPC9kaXY+DQo8L3NwYW4+PC9kaXY+DQo8L2Jsb2NrcXVvdGU+DQo8L2Rpdj4NCl9fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fPGJyIGNsYXNzPSIiPg0K SWNlIG1haWxpbmcgbGlzdDxiciBjbGFzcz0iIj4NCjxhIGhyZWY9Im1haWx0bzpJY2VAaWV0Zi5v cmciIGNsYXNzPSIiPkljZUBpZXRmLm9yZzwvYT48YnIgY2xhc3M9IiI+DQpodHRwczovL3d3dy5p ZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL2ljZTxiciBjbGFzcz0iIj4NCjwvZGl2Pg0KPC9ibG9j a3F1b3RlPg0KPC9kaXY+DQo8YnIgY2xhc3M9IiI+DQo8L2Rpdj4NCjwvYm9keT4NCjwvaHRtbD4N Cg== --_000_B725FF1CEBF24955ACACA920F889D6F3ericssoncom_-- From nobody Thu Sep 28 12:19:32 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 0B21F1348DC; Thu, 28 Sep 2017 12:19:31 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: IETF Meeting Session Request Tool To: Cc: ari.keranen@ericsson.com, ben@nostrum.com, ice-chairs@ietf.org, ice@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.63.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <150662637100.27823.2266086305056011733.idtracker@ietfa.amsl.com> Date: Thu, 28 Sep 2017 12:19:31 -0700 Archived-At: Subject: [Ice] ice - New Meeting Session Request for IETF 100 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: Thu, 28 Sep 2017 19:19:31 -0000 A new meeting session request has just been submitted by Ari Keranen, a Chair of the ice working group. --------------------------------------------------------- Working Group Name: Interactive Connectivity Establishment Area Name: Applications and Real-Time Area Session Requester: Ari Keränen Number of Sessions: 1 Length of Session(s): 1 Hour Number of Attendees: 35 Conflicts to Avoid: First Priority: payload core rtcweb avtcore t2trg tls tsvarea tsvwg tram mmusic dispatch tcpm quic Second Priority: perc httpbis rmcat netvc sipbrandy stir Third Priority: ace 6lo lwig clue xrblock sipcore cbor People who must be present: Ben Campbell Ari Keranen Peter Thatcher Resources Requested: Special Requests: --------------------------------------------------------- From nobody Thu Sep 28 12:32: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 02CCE134885; Thu, 28 Sep 2017 12:32:21 -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 dYGydRbkoguf; Thu, 28 Sep 2017 12:32:19 -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 3695D1348A2; Thu, 28 Sep 2017 12:32:14 -0700 (PDT) X-AuditID: c1b4fb3a-5ffff700000051a3-57-59cd4e3c1704 Received: from ESESSHC008.ericsson.se (Unknown_Domain [153.88.183.42]) by sessmg22.ericsson.net (Symantec Mail Security) with SMTP id 75.45.20899.C3E4DC95; Thu, 28 Sep 2017 21:32:12 +0200 (CEST) Received: from ESESSMB109.ericsson.se ([169.254.9.6]) by ESESSHC008.ericsson.se ([153.88.183.42]) with mapi id 14.03.0352.000; Thu, 28 Sep 2017 21:32:11 +0200 From: =?utf-8?B?QXJpIEtlcsOkbmVu?= To: ICE WG CC: "ice-chairs@ietf.org" Thread-Topic: ice - New Meeting Session Request for IETF 100 Thread-Index: AQHTOI63PnN+BmLJs02E5WSOOpQqaqLKjlOA Date: Thu, 28 Sep 2017 19:32:11 +0000 Message-ID: References: <150662637100.27823.2266086305056011733.idtracker@ietfa.amsl.com> In-Reply-To: <150662637100.27823.2266086305056011733.idtracker@ietfa.amsl.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [153.88.183.149] Content-Type: text/plain; charset="utf-8" Content-ID: <61E34BAF594AF44480DE0FD12BD4F1AD@ericsson.com> Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFuphkeLIzCtJLcpLzFFi42KZGbFdS9fG72ykwbyf/BYXZ01ms/h2odaB yWPJkp9MAYxRXDYpqTmZZalF+nYJXBknjzUyFtzirbh29RhLA+Ma3i5GTg4JAROJXbvXsXYx cnEICRxhlJgyZxI7hLOIUeLaukusIFVsArYST1r3gdkiApISLX82gtnMAvoSpw8tYwKxhQWs Jd6dOMoEUWMjcefIA8YuRg4g20hi3lpmkDCLgKrE7v9X2UFsXgF7ifMzH4PFhQR8JabvOg1m cwr4SXTPOgBWwyggJvH91BomiFXiEreezGeCOFpAYsme88wQtqjEy8f/WCFsJYm1h7ezgKxl FtCUWL9LH6LVWuLsu83MELaixJTuh1AnCEqcnPmEZQKj2CwkG2YhdM9C0j0LSfcsJN0LGFlX MYoWpxYX56YbGemlFmUmFxfn5+nlpZZsYgTG0cEtv612MB587niIUYCDUYmH95vN2Ugh1sSy 4srcQ4wSHMxKIryTPYBCvCmJlVWpRfnxRaU5qcWHGKU5WJTEeR32XYgQEkhPLEnNTk0tSC2C yTJxcEo1MHbuL3vhZlBwtnO22oXAtMuXiyT9/eLVPwgv8gn8f7Lk3d/LOx1XOUrujWCs02YR qpl27MyXxc0ZV8/qP2xabvbg7XHOpS/e2+0vvb4uWPXA2gVcLxw/5E1nZsxV2RGaGjBvu4hk 7LHS180/jtbVbzQ5wt64oki59YVFas3+a+vc5fQ/qm5nbVBiKc5INNRiLipOBABvGJlwnwIA AA== Archived-At: Subject: Re: [Ice] ice - New Meeting Session Request for IETF 100 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, 28 Sep 2017 19:32:21 -0000 VGhpcyBpcyBhIGJhY2t1cCBib29raW5nIGZvciBhIHNsb3QgaW4gY2FzZSBpc3N1ZXMgd29ydGgg ZGlzY3Vzc2luZyBmMmYgYXJlIGRpc2NvdmVyZWQgZHVyaW5nIHRoZSAoc29vbiB0byBiZSBzdGFy dGVkKSBXR0xDIG9mIElDRS1iaXMuIFNvIGZhciB0aGVyZSBoYXMgYmVlbiBubyBvdGhlciByZXF1 ZXN0cyBmb3IgYWdlbmRhIHRpbWUuIElmIG5vIG1ham9yIGlzc3VlcyBhcmUgZGlzY292ZXJlZCBk dXJpbmcgSUNFLWJpcyBXR0xDLCB3ZSBleHBlY3QgdG8gY2FuY2VsIHRoaXMgc2Vzc2lvbi4NCg0K DQpDaGVlcnMsDQpBcmkNCg0KPiBPbiAyOCBTZXAgMjAxNywgYXQgMjIuMTksIElFVEYgTWVldGlu ZyBTZXNzaW9uIFJlcXVlc3QgVG9vbCA8c2Vzc2lvbi1yZXF1ZXN0QGlldGYub3JnPiB3cm90ZToN Cj4gDQo+IA0KPiANCj4gQSBuZXcgbWVldGluZyBzZXNzaW9uIHJlcXVlc3QgaGFzIGp1c3QgYmVl biBzdWJtaXR0ZWQgYnkgQXJpIEtlcmFuZW4sIGEgQ2hhaXIgb2YgdGhlIGljZSB3b3JraW5nIGdy b3VwLg0KPiANCj4gDQo+IC0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLQ0KPiBXb3JraW5nIEdyb3VwIE5hbWU6IEludGVyYWN0aXZlIENvbm5l Y3Rpdml0eSBFc3RhYmxpc2htZW50DQo+IEFyZWEgTmFtZTogQXBwbGljYXRpb25zIGFuZCBSZWFs LVRpbWUgQXJlYQ0KPiBTZXNzaW9uIFJlcXVlc3RlcjogQXJpIEtlcsOkbmVuDQo+IA0KPiBOdW1i ZXIgb2YgU2Vzc2lvbnM6IDENCj4gTGVuZ3RoIG9mIFNlc3Npb24ocyk6ICAxIEhvdXINCj4gTnVt YmVyIG9mIEF0dGVuZGVlczogMzUNCj4gQ29uZmxpY3RzIHRvIEF2b2lkOiANCj4gRmlyc3QgUHJp b3JpdHk6IHBheWxvYWQgY29yZSBydGN3ZWIgYXZ0Y29yZSB0MnRyZyB0bHMgdHN2YXJlYSB0c3Z3 ZyB0cmFtIG1tdXNpYyBkaXNwYXRjaCB0Y3BtIHF1aWMNCj4gU2Vjb25kIFByaW9yaXR5OiBwZXJj IGh0dHBiaXMgcm1jYXQgbmV0dmMgc2lwYnJhbmR5IHN0aXINCj4gVGhpcmQgUHJpb3JpdHk6IGFj ZSA2bG8gbHdpZyBjbHVlIHhyYmxvY2sgc2lwY29yZSBjYm9yDQo+IA0KPiANCj4gUGVvcGxlIHdo byBtdXN0IGJlIHByZXNlbnQ6DQo+ICBCZW4gQ2FtcGJlbGwNCj4gIEFyaSBLZXJhbmVuDQo+ICBQ ZXRlciBUaGF0Y2hlcg0KPiANCj4gUmVzb3VyY2VzIFJlcXVlc3RlZDoNCj4gDQo+IFNwZWNpYWwg UmVxdWVzdHM6DQo+IA0KPiAtLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0NCj4gDQoNCg== From nobody Fri Sep 29 11:33:47 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 5029F1330B3; Fri, 29 Sep 2017 11:33:46 -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.63.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <150671002628.24593.17168202312593339296@ietfa.amsl.com> Date: Fri, 29 Sep 2017 11:33:46 -0700 Archived-At: Subject: [Ice] I-D Action: draft-ietf-ice-rfc5245bis-12.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: Fri, 29 Sep 2017 18:33:46 -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 WG of the IETF. Title : Interactive Connectivity Establishment (ICE): A Protocol for Network Address Translator (NAT) Traversal Authors : Ari Keranen Christer Holmberg Jonathan Rosenberg Filename : draft-ietf-ice-rfc5245bis-12.txt Pages : 94 Date : 2017-09-29 Abstract: This document describes a protocol for Network Address Translator (NAT) traversal for UDP-based multimedia. This protocol is called Interactive Connectivity Establishment (ICE). ICE makes use of the Session Traversal Utilities for NAT (STUN) protocol and its extension, Traversal Using Relay NAT (TURN). This document obsoletes RFC 5245. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-ice-rfc5245bis/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-ice-rfc5245bis-12 https://datatracker.ietf.org/doc/html/draft-ietf-ice-rfc5245bis-12 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-ice-rfc5245bis-12 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Fri Sep 29 11:37:31 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 DE6EA134234 for ; Fri, 29 Sep 2017 11:37:28 -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 tp71o15CQhpP for ; Fri, 29 Sep 2017 11:37:27 -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 1A4E8134231 for ; Fri, 29 Sep 2017 11:37:26 -0700 (PDT) X-AuditID: c1b4fb25-a5fff700000060a2-7e-59ce92e4c1cb Received: from ESESSHC010.ericsson.se (Unknown_Domain [153.88.183.48]) by sesbmg23.ericsson.net (Symantec Mail Security) with SMTP id 3A.3C.24738.4E29EC95; Fri, 29 Sep 2017 20:37:25 +0200 (CEST) Received: from ESESSMB109.ericsson.se ([169.254.9.6]) by ESESSHC010.ericsson.se ([153.88.183.48]) with mapi id 14.03.0352.000; Fri, 29 Sep 2017 20:37:24 +0200 From: Christer Holmberg To: "ice@ietf.org" CC: "ice-chairs@tools.ietf.org" Thread-Topic: Draft new version: draft-5245bis Thread-Index: AdM5Uac7p2SCAAw6S0qIZVdBTLUhaA== Date: Fri, 29 Sep 2017 18:37:23 +0000 Message-ID: <7594FB04B1934943A5C02806D1A2204B56308BEE@ESESSMB109.ericsson.se> 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_7594FB04B1934943A5C02806D1A2204B56308BEEESESSMB109erics_" MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFvrJLMWRmVeSWpSXmKPExsUyM2K7ge7TSeciDaZ+Y7eY3TWX1eLbhVoH Jo8lS34yeXy5/JktgCmKyyYlNSezLLVI3y6BK2NV/yf2gs3iFc/exjQwfhPpYuTkkBAwkTg5 8TxTFyMXh5DAEUaJUz3zmCGcRYwSt8//AcpwcLAJWEh0/9MGaRARUJSY2fKMGSTMLGAtcfJV OkhYWEBT4sek7YwQJXoS3/efYYex5zZ2g9ksAqoSXc3zwWp4BXwl5ly9yQpiMwqISXw/tYYJ xGYWEJe49WQ+E8RtAhJL9pxnhrBFJV4+/scKYStJrNh+iRGiPl9i/t9z7BAzBSVOznzCMoFR aBaSUbOQlM1CUgYR15FYsPsTG4StLbFs4WtmGPvMgcdMyOILGNlXMYoWpxYn5aYbGeulFmUm Fxfn5+nlpZZsYgRGyMEtv1V3MF5+43iIUYCDUYmHd275uUgh1sSy4srcQ4wSHMxKIrz7JgKF eFMSK6tSi/Lji0pzUosPMUpzsCiJ8zruuxAhJJCeWJKanZpakFoEk2Xi4JRqYCyPm/HienTq Nv9Xs077qPP79HQo3cwvCnMPT/5zbQ/HhwIrxktPQ2pfP97D9XbL1An+1iVxKy1Vrjodzwmq uGb3ILAujmVjzpO8Fo6fgdPmXzAqO+Hvfr1tJssDozCbDfov3hnaHjr4//pRkcP34j7d5+nV Fvoy6fn0iAn7t51q4+zocHkZ9VCJpTgj0VCLuag4EQAZ8P2gjAIAAA== Archived-At: Subject: [Ice] Draft new version: draft-5245bis 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, 29 Sep 2017 18:37:29 -0000 --_000_7594FB04B1934943A5C02806D1A2204B56308BEEESESSMB109erics_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi, We've submitted a new version (-12) of 5245bis. The new version implements Peter's big PR: https://github.com/ice-wg/rfc5245bis/pull/38 Regards, Christer --_000_7594FB04B1934943A5C02806D1A2204B56308BEEESESSMB109erics_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi,

 

We’ve submitted a new version (-12) of 5245bis= .

 

The new version implements Peter’s big PR:

 

https://github.com/ice-wg/rfc5245bis/pull/38

 

Regards,

 

Christer

--_000_7594FB04B1934943A5C02806D1A2204B56308BEEESESSMB109erics_-- From nobody Sat Sep 30 13:57: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 56180134226 for ; Sat, 30 Sep 2017 13:57:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.099 X-Spam-Level: X-Spam-Status: No, score=-0.099 tagged_above=-999 required=5 tests=[DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=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=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 BZU23-YeVrWX for ; Sat, 30 Sep 2017 13:57:12 -0700 (PDT) Received: from mail-wr0-x22d.google.com (mail-wr0-x22d.google.com [IPv6:2a00:1450:400c:c0c::22d]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8F78F12EC30 for ; Sat, 30 Sep 2017 13:57:12 -0700 (PDT) Received: by mail-wr0-x22d.google.com with SMTP id b21so1597705wrg.7 for ; Sat, 30 Sep 2017 13:57:12 -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=MU4SegXvlH+abYWXJgH7PyXBK6Bz5vRT0ObE01ln+hk=; b=Cq+yJInUuWiapK5GskY2AhZIjmpSSQmzU9ykAhV7m+mWBK7hE/E4hQ9Q75vI72faiC yp+O1yGsEOt8eq++eMjjMIxAESePwv5IVdQ8NzYjC5nwDNbmj8nH6zWZ5Yq+IZemO3tw eppPQPgQZOuNYbScFp0AGKi4fA0IZSfCQFpOTAobqCl3VRBdlzXpQ2zmCLQCv1QP7Ez1 mr1pXZfibfw6pll9KS6ZKTLyCjB0++eDbxK7Pn0UJ+a1U03lnQe7d/Szu890dWMiMpg0 TnAIFcGxz+8UWV9dQFSGgG7PcWW/qJpmflxoxPpOKnwM0DLBTQnlakhwb0x8vDqzZ8aZ V0/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:from:date:message-id:subject:to; bh=MU4SegXvlH+abYWXJgH7PyXBK6Bz5vRT0ObE01ln+hk=; b=FmJh5PTsZudwPUvaIFzObdgjLUKOfmnB6+k7Xr/vq0wpmGij324p0zOOZLNHR1tHVG IxgbQc0J928NtBlKm5qQ8pV8WRw/0j4Z2zqNUxeOJXfZXxMj4rFxht5AKazyDac6fXzK lW0kwpCXP3Q+kn+h2OwxYSprSacehRKYqrm78NBBy0neWXtbmmTFdIVv4SwpYVNP26sB ddMlzHB7tSk8cLepX1UrUB56gggvq85YCaTXzkn05bbalioIP54IeoAn9hQU6Sfz5n4k kGAdQHOaYDEHMPurEn1KMQQ4X1qQeTghq7jFedVSFFcegwguHQUpV9JoGLBoicoaEiTm tbqQ== X-Gm-Message-State: AHPjjUhwZc4lPHVTlbGjDzE49EDCd1G2ar82rfP6Pg1DZr9GSNAoj2+Q enOAag+vdlI1p20CTdJYkkzYVvyZzSgAD/SRuoNG/Ymf X-Google-Smtp-Source: AOwi7QB+Ea5a+OQMxUDmi1a2MudJ+fucbumKd9zGQ88H5eHEGxhnu3tSYg0uKq7JvL2dLjGtPjLrJyaQ3cmND0MhFPc= X-Received: by 10.223.161.137 with SMTP id u9mr11910312wru.280.1506805030444; Sat, 30 Sep 2017 13:57:10 -0700 (PDT) MIME-Version: 1.0 From: Peter Thatcher Date: Sat, 30 Sep 2017 20:56:58 +0000 Message-ID: To: ICE WG Content-Type: multipart/alternative; boundary="f403045f2db2966101055a6e62a0" Archived-At: Subject: [Ice] WGLC for draft-ietf-ice-trickle-11 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: Sat, 30 Sep 2017 20:57:14 -0000 --f403045f2db2966101055a6e62a0 Content-Type: text/plain; charset="UTF-8" We are starting a 3-week Working Group Last Call for ICE bis: *https://tools.ietf.org/html/draft-ietf-ice-rfc5245bis-12 * Please review the draft and provide any comments you may have on the document by Oct 21, 2017. Comments should be sent to the document authors and to the ICE WG list. If you review the document but do not have any comments, please send a note to that effect as well. --f403045f2db2966101055a6e62a0 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable

We are start= ing a 3-week Working Group Last Call for ICE bis:

=C2=A0

https://tools.ietf.org/html/draft-ietf-ice-rfc5245bis-12


=

=C2=A0Please review the draft= and provide any comments you may have on the document by Oct 21, 2017.

=C2=A0

Comments sh= ould be sent to the document authors and to the ICE WG list. If you review = the document but do not have any comments, please send a note to that effec= t as well.




--f403045f2db2966101055a6e62a0-- From nobody Sat Sep 30 22:34: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 B0F63134218 for ; Sat, 30 Sep 2017 22:34:38 -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 60g8h15y8_0v for ; Sat, 30 Sep 2017 22:34:37 -0700 (PDT) Received: from sesbmg22.ericsson.net (sesbmg22.ericsson.net [193.180.251.48]) (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 C5AF613295C for ; Sat, 30 Sep 2017 22:34:36 -0700 (PDT) X-AuditID: c1b4fb30-e87ff7000000155f-d2-59d07e6a9e13 Received: from ESESSHC003.ericsson.se (Unknown_Domain [153.88.183.27]) by sesbmg22.ericsson.net (Symantec Mail Security) with SMTP id 7D.A3.05471.A6E70D95; Sun, 1 Oct 2017 07:34:34 +0200 (CEST) Received: from ESESSMB109.ericsson.se ([169.254.9.6]) by ESESSHC003.ericsson.se ([153.88.183.27]) with mapi id 14.03.0352.000; Sun, 1 Oct 2017 07:34:34 +0200 From: Christer Holmberg To: Peter Thatcher CC: ICE WG Thread-Topic: [Ice] WGLC for draft-ietf-ice-trickle-11 Thread-Index: AQHTOi60b2QM+VrlRkeCEuAyFclAAKLOWAYA Date: Sun, 1 Oct 2017 05:34:33 +0000 Message-ID: <216D6E48-657E-4A3F-A576-0F38E41ABB48@ericsson.com> References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: Content-Type: multipart/signed; boundary="Apple-Mail-98A45197-D62F-43E5-9886-4027760BC667"; protocol="application/pkcs7-signature"; micalg=sha1 MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFjrLIsWRmVeSWpSXmKPExsUyM2K7tG5W3YVIg4bL5hbfLtRaXFv+mtWB yWPBplKPJUt+MgUwRXHZpKTmZJalFunbJXBlPHy+ibngVHrFtpYVzA2MR5O7GDk5JARMJLr+ LWXqYuTiEBI4wigx48UKNpCEkMBCRonmqcJdjBwcbAIWEt3/tEHCIgKaEpMnN7OC2MwCkhJr Py9lB7GFBUwlNs56zgxRYyYxd/kVJgjbSGLxoRawOIuAisTUjwvYQUbyCthLXFxjALEpQKLz 8zqwMZwCgRKfPl8HsxkFxCS+n1rDBLFKXOLWk/lMECeLSDy8eJoNwhaVePn4HyvI+cwCkxkl Ok5cAiviFRCUODnzCcsERuFZSPpnIaubhaQOoiheYmrrBShbXmL72znMs4BuZRbQkZi8kBEi rC2xbOFrZghbQ6Lz20RWCFtRYkr3Q3YI21pixq+DbBC2qcTrox8ZkdUsYORZxShanFqclJtu ZKSXWpSZXFycn6eXl1qyiREYsQe3/DbYwfjyueMhRgEORiUe3gueFyKFWBPLiitzDzGqAM15 tGH1BUYplrz8vFQlEd5bVUBp3pTEyqrUovz4otKc1OJDjNIcLErivI77LkQICaQnlqRmp6YW pBbBZJk4OKUaGGflLLjwc1vHud9Tnsl9KFVUv1P94bpfq+/MOeazz39PP7ts9c3m/rTAn0dM GY3nRvu8kHuaMe3V34oqy7QjfXP3pp/LUbn389on7pC7pvqfNzlkvplja3tiX9Um/aIS8ZoQ iX7GvqUfGFgdfsjVP27JFXFSnLJH7OC69s5pzN2MyWVmpbpL3ZRYijMSDbWYi4oTARR+2vHg AgAA Archived-At: Subject: Re: [Ice] WGLC for draft-ietf-ice-trickle-11 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, 01 Oct 2017 05:34:39 -0000 --Apple-Mail-98A45197-D62F-43E5-9886-4027760BC667 Content-Type: multipart/alternative; boundary=Apple-Mail-8A1C8BF6-B8A4-4A08-9353-CF9FD8320295 Content-Transfer-Encoding: 7bit --Apple-Mail-8A1C8BF6-B8A4-4A08-9353-CF9FD8320295 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable The mail subject says trickle. Regards, Christer Sent from my iPhone > On 30 Sep 2017, at 23.57, Peter Thatcher wrote: >=20 > We are starting a 3-week Working Group Last Call for ICE bis: > =20 > https://tools.ietf.org/html/draft-ietf-ice-rfc5245bis-12 >=20 > Please review the draft and provide any comments you may have on the docu= ment by Oct 21, 2017.=20 > =20 > Comments should be sent to the document authors and to the ICE WG list. If= you review the document but do not have any comments, please send a note to= that effect as well.=20 >=20 >=20 >=20 > _______________________________________________ > Ice mailing list > Ice@ietf.org > https://www.ietf.org/mailman/listinfo/ice --Apple-Mail-8A1C8BF6-B8A4-4A08-9353-CF9FD8320295 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: base64 PGh0bWw+PGhlYWQ+PG1ldGEgaHR0cC1lcXVpdj0iY29udGVudC10eXBlIiBjb250ZW50PSJ0ZXh0 L2h0bWw7IGNoYXJzZXQ9dXRmLTgiPjwvaGVhZD48Ym9keSBkaXI9ImF1dG8iPjxkaXY+VGhlIG1h aWwgc3ViamVjdCBzYXlzIHRyaWNrbGUuPC9kaXY+PGRpdiBpZD0iQXBwbGVNYWlsU2lnbmF0dXJl Ij48YnI+PC9kaXY+PGRpdiBpZD0iQXBwbGVNYWlsU2lnbmF0dXJlIj5SZWdhcmRzLDwvZGl2Pjxk aXYgaWQ9IkFwcGxlTWFpbFNpZ25hdHVyZSI+PGJyPjwvZGl2PjxkaXYgaWQ9IkFwcGxlTWFpbFNp Z25hdHVyZSI+Q2hyaXN0ZXI8YnI+PGJyPlNlbnQgZnJvbSBteSBpUGhvbmU8L2Rpdj48ZGl2Pjxi cj5PbiAzMCBTZXAgMjAxNywgYXQgMjMuNTcsIFBldGVyIFRoYXRjaGVyICZsdDs8YSBocmVmPSJt YWlsdG86cHRoYXRjaGVyQGdvb2dsZS5jb20iPnB0aGF0Y2hlckBnb29nbGUuY29tPC9hPiZndDsg d3JvdGU6PGJyPjxicj48L2Rpdj48YmxvY2txdW90ZSB0eXBlPSJjaXRlIj48ZGl2PjxtZXRhIGh0 dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIgY29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04 Ij48ZGl2IGRpcj0ibHRyIj48cCBkaXI9Imx0ciIgc3R5bGU9ImNvbG9yOnJnYigzMywzMywzMyk7 Zm9udC1zaXplOjEzcHg7bGluZS1oZWlnaHQ6MS4zODttYXJnaW4tdG9wOjBwdDttYXJnaW4tYm90 dG9tOjBwdDttYXJnaW4tbGVmdDo0cHQiPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTpBcmlhbDtm b250LXNpemU6MTBwdDt3aGl0ZS1zcGFjZTpwcmUtd3JhcCI+V2UgYXJlIHN0YXJ0aW5nIGEgMy13 ZWVrIFdvcmtpbmcgR3JvdXAgTGFzdCBDYWxsIGZvciBJQ0UgYmlzOjwvc3Bhbj48YnI+PC9wPjxw IGRpcj0ibHRyIiBzdHlsZT0iY29sb3I6cmdiKDMzLDMzLDMzKTtmb250LXNpemU6MTNweDtsaW5l LWhlaWdodDoxLjM4O21hcmdpbi10b3A6MHB0O21hcmdpbi1ib3R0b206MHB0O21hcmdpbi1sZWZ0 OjRwdCI+Jm5ic3A7PC9wPjxwIGRpcj0ibHRyIiBzdHlsZT0ibGluZS1oZWlnaHQ6MS4zODttYXJn aW4tdG9wOjBwdDttYXJnaW4tYm90dG9tOjBwdDttYXJnaW4tbGVmdDo0cHQiPjxmb250IGNvbG9y PSIjMzM2N2Q2Ij48dT48YSBocmVmPSJodHRwczovL3Rvb2xzLmlldGYub3JnL2h0bWwvZHJhZnQt aWV0Zi1pY2UtcmZjNTI0NWJpcy0xMiI+aHR0cHM6Ly90b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0 LWlldGYtaWNlLXJmYzUyNDViaXMtMTI8L2E+PC91PjwvZm9udD48YnI+PC9wPjxwIGRpcj0ibHRy IiBzdHlsZT0iY29sb3I6cmdiKDMzLDMzLDMzKTtmb250LXNpemU6MTNweDtsaW5lLWhlaWdodDox LjM4O21hcmdpbi10b3A6MHB0O21hcmdpbi1ib3R0b206MHB0O21hcmdpbi1sZWZ0OjRwdCI+PGJy PjwvcD48cCBkaXI9Imx0ciIgc3R5bGU9ImNvbG9yOnJnYigzMywzMywzMyk7Zm9udC1zaXplOjEz cHg7bGluZS1oZWlnaHQ6MS4zODttYXJnaW4tdG9wOjBwdDttYXJnaW4tYm90dG9tOjBwdDttYXJn aW4tbGVmdDo0cHQiPiZuYnNwOzxzcGFuIHN0eWxlPSJmb250LWZhbWlseTpBcmlhbDtmb250LXNp emU6MTBwdDt3aGl0ZS1zcGFjZTpwcmUtd3JhcCI+UGxlYXNlIHJldmlldyB0aGUgZHJhZnQgYW5k IHByb3ZpZGUgYW55IGNvbW1lbnRzIHlvdSBtYXkgaGF2ZSBvbiB0aGUgZG9jdW1lbnQgYnkgT2N0 IDIxLCAyMDE3LiA8L3NwYW4+PC9wPjxwIGRpcj0ibHRyIiBzdHlsZT0iY29sb3I6cmdiKDMzLDMz LDMzKTtmb250LXNpemU6MTNweDtsaW5lLWhlaWdodDoxLjM4O21hcmdpbi10b3A6MHB0O21hcmdp bi1ib3R0b206MHB0O21hcmdpbi1sZWZ0OjRwdCI+Jm5ic3A7PC9wPjxwIGRpcj0ibHRyIiBzdHls ZT0iY29sb3I6cmdiKDMzLDMzLDMzKTtmb250LXNpemU6MTNweDtsaW5lLWhlaWdodDoxLjM4O21h cmdpbi10b3A6MHB0O21hcmdpbi1ib3R0b206MHB0O21hcmdpbi1sZWZ0OjRwdCI+PHNwYW4gc3R5 bGU9ImZvbnQtc2l6ZToxMHB0O2ZvbnQtZmFtaWx5OkFyaWFsO3ZlcnRpY2FsLWFsaWduOmJhc2Vs aW5lO3doaXRlLXNwYWNlOnByZS13cmFwIj5Db21tZW50cyBzaG91bGQgYmUgc2VudCB0byB0aGUg ZG9jdW1lbnQgYXV0aG9ycyBhbmQgdG8gdGhlIElDRSBXRyBsaXN0LiBJZiB5b3UgcmV2aWV3IHRo ZSBkb2N1bWVudCBidXQgZG8gbm90IGhhdmUgYW55IGNvbW1lbnRzLCBwbGVhc2Ugc2VuZCBhIG5v dGUgdG8gdGhhdCBlZmZlY3QgYXMgd2VsbC4gPC9zcGFuPjwvcD48cCBkaXI9Imx0ciIgc3R5bGU9 ImNvbG9yOnJnYigzMywzMywzMyk7Zm9udC1zaXplOjEzcHg7bGluZS1oZWlnaHQ6MS4zODttYXJn aW4tdG9wOjBwdDttYXJnaW4tYm90dG9tOjBwdDttYXJnaW4tbGVmdDo0cHQiPjxzcGFuIHN0eWxl PSJmb250LXNpemU6MTBwdDtmb250LWZhbWlseTpBcmlhbDt2ZXJ0aWNhbC1hbGlnbjpiYXNlbGlu ZTt3aGl0ZS1zcGFjZTpwcmUtd3JhcCI+PGJyPjwvc3Bhbj48L3A+PHAgZGlyPSJsdHIiIHN0eWxl PSJjb2xvcjpyZ2IoMzMsMzMsMzMpO2ZvbnQtc2l6ZToxM3B4O2xpbmUtaGVpZ2h0OjEuMzg7bWFy Z2luLXRvcDowcHQ7bWFyZ2luLWJvdHRvbTowcHQ7bWFyZ2luLWxlZnQ6NHB0Ij48c3BhbiBzdHls ZT0iZm9udC1zaXplOjEwcHQ7Zm9udC1mYW1pbHk6QXJpYWw7dmVydGljYWwtYWxpZ246YmFzZWxp bmU7d2hpdGUtc3BhY2U6cHJlLXdyYXAiPjxicj48L3NwYW4+PC9wPjxwIGRpcj0ibHRyIiBzdHls ZT0iY29sb3I6cmdiKDMzLDMzLDMzKTtmb250LXNpemU6MTNweDtsaW5lLWhlaWdodDoxLjM4O21h cmdpbi10b3A6MHB0O21hcmdpbi1ib3R0b206MHB0O21hcmdpbi1sZWZ0OjRwdCI+PHNwYW4gc3R5 bGU9ImZvbnQtc2l6ZToxMHB0O2ZvbnQtZmFtaWx5OkFyaWFsO3ZlcnRpY2FsLWFsaWduOmJhc2Vs aW5lO3doaXRlLXNwYWNlOnByZS13cmFwIj48YnI+PC9zcGFuPjwvcD48L2Rpdj4NCjwvZGl2Pjwv YmxvY2txdW90ZT48YmxvY2txdW90ZSB0eXBlPSJjaXRlIj48ZGl2PjxzcGFuPl9fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fPC9zcGFuPjxicj48c3Bhbj5JY2Ug bWFpbGluZyBsaXN0PC9zcGFuPjxicj48c3Bhbj48YSBocmVmPSJtYWlsdG86SWNlQGlldGYub3Jn Ij5JY2VAaWV0Zi5vcmc8L2E+PC9zcGFuPjxicj48c3Bhbj48YSBocmVmPSJodHRwczovL3d3dy5p ZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL2ljZSI+aHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1h bi9saXN0aW5mby9pY2U8L2E+PC9zcGFuPjxicj48L2Rpdj48L2Jsb2NrcXVvdGU+PC9ib2R5Pjwv aHRtbD4= --Apple-Mail-8A1C8BF6-B8A4-4A08-9353-CF9FD8320295-- --Apple-Mail-98A45197-D62F-43E5-9886-4027760BC667 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Disposition: attachment; filename="smime.p7s" Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIR8zCCBTgw ggMgoAMCAQICEQCVvhag9y5G8Xs5gnL6i82WMA0GCSqGSIb3DQEBBQUAMDcxFDASBgNVBAoMC1Rl bGlhU29uZXJhMR8wHQYDVQQDDBZUZWxpYVNvbmVyYSBSb290IENBIHYxMB4XDTA3MTAxODEyMDA1 MFoXDTMyMTAxODEyMDA1MFowNzEUMBIGA1UECgwLVGVsaWFTb25lcmExHzAdBgNVBAMMFlRlbGlh U29uZXJhIFJvb3QgQ0EgdjEwggIiMA0GCSqGSIb3DQEBAQUAA4ICDwAwggIKAoICAQDCvusn8CGj 82kmVX6dxVUWkVz97yG/U4B6LdKRjGMx8Owk8MOl0nJ8EG30N7fl5nx56oy1gouuSLasANxldewq TV/Bh/UgZSuBqEc+iSOVMBaQf+hXB0jnGa6/RWexNxsGKv7e+ax9g/teuuSPl2e+S46NZAdXOFVp NDY9E0jvT+LTZh6kzxq3XjYz1LQGvRgB/XeEUABF9Yxd6CO8fv414e1Qe6kwjRnTCY5oZ12/PJcY U7spYsXKXnLBx5bU2y2gtB9pA+zq4lDxDDzwrPNTLfAc9e1sOTlzgBbIUrAjzeA+3N08R6C7NYri mGiLvuW/cu7S+qXtEu38mBipJnbcKEsQIBzTfxZ3Le1vgPdJu1MFu11ox9TIdRY/iVqL9xdH1Ezx 0ol5Pk09mKhh3joe0vheA+DByRyM041N05U2szdfY2ObMxTwLSZrU3yJjDLCbuw9IQA5yaFo4lCD LrA6K/M2oKwv5G9hwlEJOT6LU7m7Z9rcU7l2WTadQ+Ug4D0yYIUiUbfHM7vdFS+keKYHe4FGNgSG 3Xk1x5UsO7CjFzXlcx+0XFnv2uoQZXt60H+fs7QqNztwi5tbuSu37LJREpdTKVrU8BIQ3E8CuxKS L2LUP2lDfA3W/Fh1AYidWBZL3rqQ/0cBiQZq9l+ykGqzAqYCiL+zR34q2dX6aHg1TQIDAQABoz8w PTAPBgNVHRMBAf8EBTADAQH/MAsGA1UdDwQEAwIBBjAdBgNVHQ4EFgQU8I9ZOACz9Y+algzV6/p7 qhfoExIwDQYJKoZIhvcNAQEFBQADggIBAL7kXGJOJPQMCP/w0wxo5JNJIj9EJ2+7bd6DZs6ozA38 9ZoG5XcUkeudQXuZKoTl//whwV3w5B9Xt3WpoV8CJv/Xx/dO3k/49xxGwHpPQCwiNfAZsdBrZyyw qODAQDc19oRcXOOvQnj+p8kNUOoNhHb2Ue+DU8Z6/w5WSS6PetYM5idU400KYHJizZEH1qW/yJlr 7cQZ5qtMETjFbzHibknIP3aAJgMmKeA29vYgU+MXcDQXnWNoHmvsw02GuBMwL11GDUdD1RuqWQ65 XI0GSK10h1/H/DFUQRPixyEOnuAeDeHAe0OFkMWKWMZlCnhX8sYjDwHZIEveD/uShXUqXHONbXsl kcruRa4GSwDM07FZUNo6iDspQ0ZelytUzlNvjUrnlvq/cQ5Ci3z9KKDQSMraxIFMu6JzkybI6wzW Joi2wCTPu71b63V96QiOhjMseXcJaaWJ/LNwkId2j9Miu0LOvXMLICYq0Js9cB4kbM2HdqkXlrfP DZL7jhipmEnRnv5gRHIhuRntwvUx8TlIiJAkdVQWrc70+GkUZDn7o7i6cEDHJxy/xFZT+mNl0PMc Dhb1a4ZYTRjU5A2OpZ1bkdx2JFA/xir72bectdbm0NnoGYsVcUitt+rYWYjUkL8Ws9nprFlhVMgc usrByuG5IEyPOpOJpaDMv9P2daR1lm1WMIIF+TCCA+GgAwIBAgIQMQ1yPcGTNYDzhYWhrkFQyDAN BgkqhkiG9w0BAQUFADA6MREwDwYDVQQKDAhFcmljc3NvbjElMCMGA1UEAwwcRXJpY3Nzb24gTkwg SW5kaXZpZHVhbCBDQSB2MjAeFw0xNDExMDQxMjI4MTlaFw0xNzExMDQxMjI4MThaMG8xETAPBgNV BAoMCEVyaWNzc29uMRowGAYDVQQDDBFDaHJpc3RlciBIb2xtYmVyZzEtMCsGCSqGSIb3DQEJARYe Y2hyaXN0ZXIuaG9sbWJlcmdAZXJpY3Nzb24uY29tMQ8wDQYDVQQFEwZMTUZDSEgwggEiMA0GCSqG SIb3DQEBAQUAA4IBDwAwggEKAoIBAQCMb7fHWIV9CIFYYov86NR/6ibdVV0I+ZqVLE21zQB7otFv 6DTKlVXE7iiC4HCvMhlGkg3/qFmAhAti5Z1Z7+5eEMEIP5JJEZ7fMm6BME33Bkdgg4EfJrq4FUG2 8Hw2//0qx3jZWvK2W751AmEuUJ5nkZ6F00GnzJmOhbveadC8E5keqwow9ria0/WazHiK3wxzjban oQaZIA+oCKj5YyCv8cCTaSk4pEAbXwxthJ97BaZPahsnb4EZEP08gxR5IE9NRi47Eqh6LtBjiWpa B42EmCEBxc2uIQ87tlJ0e2SvCo74rqxndXtUeaWauMjjt4DnhJdiXZY244D5J1gWssRFAgMBAAGj ggHEMIIBwDBIBgNVHR8EQTA/MD2gO6A5hjdodHRwOi8vY3JsLnRydXN0LnRlbGlhLmNvbS9lcmlj c3Nvbm5saW5kaXZpZHVhbGNhdjIuY3JsMIGCBggrBgEFBQcBAQR2MHQwKAYIKwYBBQUHMAGGHGh0 dHA6Ly9vY3NwMi50cnVzdC50ZWxpYS5jb20wSAYIKwYBBQUHMAKGPGh0dHA6Ly9jYS50cnVzdC50 ZWxpYXNvbmVyYS5jb20vZXJpY3Nzb25ubGluZGl2aWR1YWxjYXYyLmNlcjApBgNVHREEIjAggR5j aHJpc3Rlci5ob2xtYmVyZ0Blcmljc3Nvbi5jb20wVQYDVR0gBE4wTDBKBgwrBgEEAYIPAgMBARIw OjA4BggrBgEFBQcCARYsaHR0cHM6Ly9yZXBvc2l0b3J5LnRydXN0LnRlbGlhc29uZXJhLmNvbS9D UFMwHQYDVR0lBBYwFAYIKwYBBQUHAwQGCCsGAQUFBwMCMB0GA1UdDgQWBBRUo03/DrRAW2xpMmhN 2uGkvDgx6jAfBgNVHSMEGDAWgBSxDcrURrevhgLDL28Gyg52cX9LNzAOBgNVHQ8BAf8EBAMCBaAw DQYJKoZIhvcNAQEFBQADggIBALbwqG5inhl/xPxsuQWcH7GOUZIPAw0JlKltVQ/TlsF7ig0J1iyz ao6GsXItJ9H3WZPrCy5EQchJm7qcn2kKX8OGb+Yr53FisLR2gx+qkrQMDOdix9Was0cvIjDWjAQn EZbxz/a+dzdAP0TrwNvD8282bIy0fCt/3uoBfzMnvQG+4wG018bDunc+NCj1FkSKkSRb9fP2Z2li 65pfJcxtGIfb5zsXJZG4Gtbe0/hxlj3NccjB/zVPO7PQ+lnWmxtOiJQ2loA+62vQreUQr328XK4I HFnoU+zXiVfUN2urvvirQH7Ha70TBMa20J8Nn2aEvY6QYMEQJhAiVmNTiv4EGGv5heX5vb8yaj7p r4YIvb6D0r+pwpvfEE8YhAEWJgCZP7k5zQwhrpuSF/s+wEruXo59sq9bOCefghktc5fwDu8ved98 cifRPUnuT/c5slJJ8LjFn8d+LnGklUdFA9kLjIJVVx+TM4D/OTaRG+mPFbY2pTyR0V84PG7HLeku pNsFzcme7IBkQ+1zkb9hjz6pyiodf6rh7ph+8XHWNgzbC5PdGCANg8fVWrxqqOoEzvcUcPMy6XXJ s0JWhWas8mJdHq2kGDDEpA7BbBatmtEqziXRnYGJeQK3eMDXXtmOeBSA4y7YZ47y+CxvbknSQ5dy ghwkEq+a7ORPGVjsjtWJYJ6dMIIGtjCCBJ6gAwIBAgIRAKAMy8ybmZjs4jpw9HzBwFkwDQYJKoZI hvcNAQEFBQAwNzEUMBIGA1UECgwLVGVsaWFTb25lcmExHzAdBgNVBAMMFlRlbGlhU29uZXJhIFJv b3QgQ0EgdjEwHhcNMTQwNTI3MDc0NjIxWhcNMjQwNTI3MDc0NjIxWjA6MREwDwYDVQQKDAhFcmlj c3NvbjElMCMGA1UEAwwcRXJpY3Nzb24gTkwgSW5kaXZpZHVhbCBDQSB2MjCCAiIwDQYJKoZIhvcN AQEBBQADggIPADCCAgoCggIBANq6U+tfSJZTn4k46qN13HgaeXXsMmGSWShc6A5IEyFboXMZW3lF Hso+/6uO3ZilvB2ipZJhrhU+RL/va+5Chay/PZq9ZZeE9N03OsHfOzlwk7uwojJ34tHLiX/yQori I+b5DXxfIYXTFO5zlZLdaIxJwlLEQp0g4/zF6EGtodlpusaH07FAcLiIEeTMPRgXcn+8GoFOvtuV HNh/WHePlrupUgcI9/P54ITXvmZF6xcNBEjsu8yJm1VqqK0GXSgAmInJ4Ga8S6ME2wgSBRDolxAU bmfLQRrMvLC/tyXBvuLO8uChdzpIWt3QPtMYm2R2V1Um0zANhenIUwYCKNPq5/yHaS48jCsOBAU0 TIhBnirnZmlEbC6ALqwzGAcQMaMD8LFf1oLlWLUQxEmI4YXqBXdP5XnIcMdIEF5BtUBebzBJMMF9 dDB2uj8BeoRPSYbpGl7irYUYFpq4TyocQ7qpHdYASC+NV8VTaTrFnHWqa/CGRdp3GHpkgxfOBvpa mOK8udHQYQo2uA3YNd2+j7p4C3jkGG+Z6RrZOskPEwtaIHLxBiA141dhCy5EScOyNajrAXQupsDn vr2ib2ef+4nObPFvedPWIe57lyj0n3e1rTqTGIBIe9wjNnAA6MqeaTS9HchPtBvOrah/cTWzXzGj wMz0P3UJqTQ2r5EAu12/W5kpAgMBAAGjggG4MIIBtDCBigYIKwYBBQUHAQEEfjB8MC0GCCsGAQUF BzABhiFodHRwOi8vb2NzcC50cnVzdC50ZWxpYXNvbmVyYS5jb20wSwYIKwYBBQUHMAKGP2h0dHA6 Ly9yZXBvc2l0b3J5LnRydXN0LnRlbGlhc29uZXJhLmNvbS90ZWxpYXNvbmVyYXJvb3RjYXYxLmNl cjASBgNVHRMBAf8ECDAGAQH/AgEAMFUGA1UdIAROMEwwSgYMKwYBBAGCDwIDAQECMDowOAYIKwYB BQUHAgEWLGh0dHBzOi8vcmVwb3NpdG9yeS50cnVzdC50ZWxpYXNvbmVyYS5jb20vQ1BTMEsGA1Ud HwREMEIwQKA+oDyGOmh0dHA6Ly9jcmwtMy50cnVzdC50ZWxpYXNvbmVyYS5jb20vdGVsaWFzb25l cmFyb290Y2F2MS5jcmwwHQYDVR0lBBYwFAYIKwYBBQUHAwIGCCsGAQUFBwMEMA4GA1UdDwEB/wQE AwIBBjAdBgNVHQ4EFgQUsQ3K1Ea3r4YCwy9vBsoOdnF/SzcwHwYDVR0jBBgwFoAU8I9ZOACz9Y+a lgzV6/p7qhfoExIwDQYJKoZIhvcNAQEFBQADggIBAG4HIGyvrHc9kEKyYZtxJn9cv7S2dUxuUieg mAvUGHc+JGJyB2jyX7py9an8CsHAxg3BI3Ku9j0h7DJpXyfrlzmg36XYkNS7Ot0A1UqdjGFrtnII SI+Zj3ywHZudmDF8ktdBihHAjuk47B/Kg/Z8JhUJ37GGx/KxiIiXg5HMTdOl6mlDbJaTIEGagdRc mH3u57r5snZ+qdVSg5UxWdhgS2+zPru/vDbPd+91zLTj9GejKXFJ6fEAOLW1j2IjJ0cyDI67d1/O zFTwCK8wYbhopK2wJ9QTKDQuWRuGoyt2d6yzd7WoAS55JE0BIt+kXDJGbOaK42H2ifO6ERHbJiEr /oh4KzgdAes+GRjwlSaG2Z0va4Ss5lY6zfwVCEZYdZcjSDpKB0M5tTQYQeO7QyQPOI6Gb4FXA9ko 3sHvAPs4+Pq+UtWjp3y8sYr1vLCER9ePEsgLdCG27mUk9OAijkG6n5oEGOIn+70F+qvKpmm52dZ8 b7DELfbuuk0CrY4p0WxH3bBt6FJkPeZJIB6YNXAYHZi7RcdBjLJh+lawbIYTJFIcoWFHAl0g0/NY sjz3DLhZz4+CrJ6SQSYmp7qDhdJAWPiaq3C+qE/h2DZAJwoz9uHrZHB8zsZ5JL8sUZ7zgqYmNMN+ 9PxzasrycTJn96Y63AIZdDq1kIHIw0vF4PBTVMZtMYICljCCApICAQEwTjA6MREwDwYDVQQKDAhF cmljc3NvbjElMCMGA1UEAwwcRXJpY3Nzb24gTkwgSW5kaXZpZHVhbCBDQSB2MgIQMQ1yPcGTNYDz hYWhrkFQyDAJBgUrDgMCGgUAoIIBHTAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3 DQEJBTEPFw0xNzEwMDEwNTM0MzNaMCMGCSqGSIb3DQEJBDEWBBRd4diAD7I8zD5tZe61McCWchr8 4TBdBgkrBgEEAYI3EAQxUDBOMDoxETAPBgNVBAoMCEVyaWNzc29uMSUwIwYDVQQDDBxFcmljc3Nv biBOTCBJbmRpdmlkdWFsIENBIHYyAhAxDXI9wZM1gPOFhaGuQVDIMF8GCyqGSIb3DQEJEAILMVCg TjA6MREwDwYDVQQKDAhFcmljc3NvbjElMCMGA1UEAwwcRXJpY3Nzb24gTkwgSW5kaXZpZHVhbCBD QSB2MgIQMQ1yPcGTNYDzhYWhrkFQyDANBgkqhkiG9w0BAQEFAASCAQA1Y4QxDrCOB3IgRrHqz5Ew W3Wb83MlWTLa/iZtLPPYSXxwVXU/LkDxXywoTjydK/FVapCm8x9jljMwbmKyt0UZQktVWesRWjbr r0ETLzs6glRZThXjmMPC2ioZfvAy9Sc8cN1uXq8ejRU9AuixQIX81sCG56e0rENbFSJ7Q/I8ReFa m7ptHyRg/6ZLMXbH08FFJybiCxo0OjXqszEWHQcXDd/sdcWHV2FmhHwjCatdnXDhitKaLUGv0MNF Ns3p/GFEYLN91/QnumNQa3nbfj69GjgLXdYihwj0MlVPPwBNhuOdSe8AfyTQsZAG+djbk+gY3rJE m2m+wBZLXBYnUidOAAAAAAAA --Apple-Mail-98A45197-D62F-43E5-9886-4027760BC667-- From nobody Sat Sep 30 23:03:14 2017 Return-Path: X-Original-To: ice@ietfa.amsl.com Delivered-To: ice@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 37FA613447A for ; Sat, 30 Sep 2017 23:03:13 -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, 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 OXr-peSkOXYB for ; Sat, 30 Sep 2017 23:03:11 -0700 (PDT) Received: from mail-wr0-x22a.google.com (mail-wr0-x22a.google.com [IPv6:2a00:1450:400c:c0c::22a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0E476134475 for ; Sat, 30 Sep 2017 23:03:11 -0700 (PDT) Received: by mail-wr0-x22a.google.com with SMTP id 54so1900510wrz.10 for ; Sat, 30 Sep 2017 23:03:10 -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=UioJK4OXidMwkUHdAn9CzFI/ontIwUMjpECON1ctNEo=; b=L7yvp6X75Sm8IP0m4NlsDtQvpBbVU8KXJD0uWhb35JIqlOKPnhvR+8BDXPYDtWD0km 6AdqFW1yk1aoYfQLltE+2sS6mxH8UBZdxX/CAWH7bx3ZvTlRsBZgZCBowxMV+Dy81HwT c38K82k79bX257rdnunP7VNRXrJAeIau4CtD1k5hbnvDHH4gG4OOWqf77VQJPlPFvUYT A1mQVyLHkFyWrlo49UKJbP8u9IcHo02VoWyd+mFlXslDPWV2e3x/tMTXlyXjvD6OtbqL cI8uLMMqhu2FXN4pM9ENJjBoMcQ1i++IvZ++QxgH31c46jX+M1iAp+MyuFc59vFYQnkl blRw== 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=UioJK4OXidMwkUHdAn9CzFI/ontIwUMjpECON1ctNEo=; b=Z9Eu1wOWjL1Y7jmdJjUjidSI6zXFdcXuPq6Mt0rT8G+vlJ9AwfHK7SMFBKkhVBb6/2 HzWdaxN7WIAEyGn8uz8CsPsteyAiWFHc0FR/okMV6Bc22VjB45iFNhMZfzBewNGxpVbC R6BN1zFlc0+7kfKe1TDbfRZAQvxeM2BrSdL3JWagr2HRhg3khY9EDTcmr17Eu+Uxa3Js k5C1ds2aM30xiHQzLBIYlKTL73g+W4M+6XY2lSSIWY8y15XyRcmyxDyWRc+VqE5TgatP bYzS2DsHef9jkGOQ8+13qBNr0YFqxe+4JuXckI6J1DNajq7do/Jyj5lO8XHVSd8mEHZd nD9A== X-Gm-Message-State: AHPjjUj5N+4FfP91iHR9P57h+Lrf6mi4req5bh3wpyj6zBn34G0R4gwn lHfWEQK5d9VUWEPa/l3E88/XKBn6Y7YpwIgzEmJBmikW X-Google-Smtp-Source: AOwi7QCt/l1DgdJDKdTRZm0DlInTas2kf06fBWQl1W8aFhOeDbtEwtEvuuBMK056YsU9TNySXVtkV1BiYYY2Hkxyhpw= X-Received: by 10.223.161.137 with SMTP id u9mr12612651wru.280.1506837788882; Sat, 30 Sep 2017 23:03:08 -0700 (PDT) MIME-Version: 1.0 From: Peter Thatcher Date: Sun, 01 Oct 2017 06:02:56 +0000 Message-ID: To: ICE WG Content-Type: multipart/alternative; boundary="f403045f2db2249c07055a7603a9" Archived-At: Subject: [Ice] WGLC for draft-ietf-ice-rfc5245bis-12 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, 01 Oct 2017 06:03:13 -0000 --f403045f2db2249c07055a7603a9 Content-Type: text/plain; charset="UTF-8" (in case you ignore the last once because of the erroneous title) We are starting a 3-week Working Group Last Call for ICE bis: *https://tools.ietf.org/html/draft-ietf-ice-rfc5245bis-12 * Please review the draft and provide any comments you may have on the document by Oct 21, 2017. Comments should be sent to the document authors and to the ICE WG list. If you review the document but do not have any comments, please send a note to that effect as well. --f403045f2db2249c07055a7603a9 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable

(in case you ignore the = last once because of the erroneous title)


We are starting a 3-week Working Group Last Call for ICE bis:

=C2=A0

<= a href=3D"https://tools.ietf.org/html/draft-ietf-ice-rfc5245bis-12" target= =3D"_blank">https://tools.ietf.org/html/draft-ietf-ice-rfc5245bis-12


=

=C2=A0Please review the draft= and provide any comments you may have on the document by Oct 21, 2017.

=C2=A0

Comments sh= ould be sent to the document authors and to the ICE WG list. If you review = the document but do not have any comments, please send a note to that effec= t as well.

--f403045f2db2249c07055a7603a9--